NISHIO Hirokazu[Translate]
一人用Cartographer

2025-11-14
青山くんのCartographerを一人で使うのをやっている、質問されることによって曖昧だったことが言語化されてとても良い
ただ、このシステムは本来複数人で使うことを想定してるから、やりにくいところがいくつかあり
一人で使えるようにしていくことはあんまりユーザ増えなさそうなので要望することではないな〜と思っている
むしろ自分のKeichobotの方にYes/No質問をしてくるモードをつけるのがいいかも
Keichobotもいっそ今のLLMの状況を前提に作り直したほうがいいものができそうな気はする

2025-11-18
Q: "Keichobot 軽く試してみたが作り直した方がいいかもと思っている"について
A: いちどDevinに改善させようとした。元々LLM以前に作ったものなので形態素解析して重み付けして〜と複雑な仕組みになっているため、AIが混乱してしまった。レガシーコードの改善という点では、まずテストをしっかり書いてやるのがよいが、LLMに本質的に再現性がないため「再現性のないLLMシステムをどうテストするか」という難問に正面衝突してしまう。
それよりはvibe codingでプロトタイプを新しく作るほうが良さそうだと考えている。

2025-11-23
keicho-serverとkeicho-webclientがある
keichobot-gptとkeichobot_newがある
後者はGit repoになってない

全部CLAUDE.mdを作ってからGPT5にまとめさせる
GPT5
keicho-server(旧バックエンド本体)
Python + Flask + Firestore のKeichobot頭脳&状態管理モノリス
キーフレーズ抽出・フェーズ遷移・special mode など全部入り
Heroku 上で一応まだ動いているが、仕組みが重くて大改造には向かないレガシー核

keicho-webclient(旧Webフロント)
React + TypeScript + Netlify のオリジナルWebクライアント
API は https://keicho.herokuapp.com/api/web/ に接続
会話一覧・共有URL・Scrapbox出力などUI機能は充実
ただし ReactN や古い構成で、2025年基準ではレガシーUI

keichobot-gpt(Next.js版フロント試作)
Next.js 13 + Pages Router の新フロント候補
index.tsx / chatroom.tsx など UI の骨格だけあり
主要API /api/messages は未実装で、見た目だけのプロトタイプ

keichobot_new(TypeScript CLI版コア)
TypeScript 単体で動く Clean Language 質問エンジンのミニマム版
LLM(or簡易ヒューリスティック)でキーワード抽出 → クリーンランゲージ質問を生成
CLIのみ・永続化なし・HTTPなしだが、「新しい頭脳」の実験用コアとして良い状態

関係性の一行まとめ
旧世代: keicho-server (頭脳)+ keicho-webclient (フロント)
新世代候補: keichobot_new (新しい頭脳コア)+ keichobot-gpt (新しいWebフロント案)

nishio
旧バージョンはkeicho-*、新バージョンはkeichobot*で試作していたが、モノレポ化したい(Devinに使いやすいように)
keichobot を新しいrepoとすることにする
当面は他人に使わせない(費用感を見てから考える)
ここもう少し考えたほうがよくて、自分一人が使うとしてもスマホから使いたいからAPIキーを入力してローカルストレージに入れる的な形がいいかなぁ
いったんローカルのサーバがfsでデータをいじる形の設計になっている
GPT5と話して構造の案を練ったので、Claude Codeにそれを読ませている
CLAUDE.mdとPLAN.mdを作る
「背景情報を追加する」ボタンをつけて、Scrapbox / Gist / その他のURL / ペースト ぐらいをサポートしたい
Claude Code的なコンテキスト可視化もつけたいな
従来の質問タイプに追加で「YesかNoかの回答を期待している」タイプが追加される
質問タイプによってUIを変える機能は実装済みだ
このタイプが来た時に「はい、わからない、いいえ、その他(自由記述)」を出す
Strong Yes/Noを足してもいいが、「どちらかといえばyes」はいらない(それは自由記述すべきだ)
まずはkeicho-webclientのUIを参考にして見た目を作ってもらう
技術スタックがいけてないだけで、UI自体は悪くないと思う
サーバサイドは、いまkeicho-serverが形態素解析とかsklearnでの独自の処理とかをしているのを、一旦はそれらの重たいモジュールを使わずにルールベースとLLMの組み合わせで実現する
legacyのすでにある4つは更新もしないで読むだけだからsubmoduleにする必要もないしgitignoreしたらいいと思う
音声入出力とかつけたくなる


最初に何がどうなると良いかを聞いた後、「語りたいことがあるか」という趣旨のyesno質問をして、
あるなら従来実装の「あいづちモード」みたいにユーザの言いたいことを一通り聞くようにしよう。
この「あいづちモード」は質問をするのではない
これをどう実装するか考えてPLANに書いて

語りたいことがないなら、まずはクリーンな質問をする
ユーザの言語化があまり進んでなさそうならyes/noの質問をしていく


yes/noをつけたら「答えやすい質問をする」と解釈された
:
**4-3. yesno質問モードへの切り替え**: 言語化が進んでいない場合、より答えやすいyesno質問を使う。 **答えやすいyes/no質問の原則**: - 複雑な判断を求めない - 自分の内側(体験・感覚・気持ち)を見るだけで答えられる - 二者択一ではなく、自然にyes/noで答えられる **答えやすい質問の3つのタイプ**: 1. **体験・記憶の有無を確認する**(事実確認) ``` 「それを経験したことがありますか?」 「そのような状況になったことがありますか?」 「「〇〇」を見たことや聞いたことがありますか?」 ``` 2. **感覚・イメージの有無を確認する**(内的体験の確認) ``` 「「〇〇」について、イメージが浮かびますか?」 「「〇〇」を感じることがありますか?」 「その感覚は、身体のどこかで感じられますか?」 ``` 3. **方向性・関心を確認する**(意向の確認) ``` 「「〇〇」について、もっと話したいですか?」 「「〇〇」は、あなたにとって重要だと感じますか?」 「「〇〇」について、もっと知りたいですか?」 ``` **避けるべき質問**: - 関係性の判断: 「〇〇は、△△に関係していますか?」→ 関係の定義が曖昧、判断が必要 - 評価・分析: 「それは正しいと思いますか?」→ 基準が不明確 - 抽象的概念の判断: 「それは本質的ですか?」→ 解釈の幅が広すぎる
答えやすいことが大事なのではなく、質問が思考の発展に繋がるのが大事

ユーザが背景情報を追加した時、それはあいづちモードで語りおわったのと近い状況

"Engineer's way of creating knowledge" the English version of my book is now available on [Engineer's way of creating knowledge]

(C)NISHIO Hirokazu / Converted from [Scrapbox] at [Edit]