NISHIO Hirokazu[Translate]
計画ではなく探索面
2026-09-18
AIに「計画」を立てさせたりしがちだが、その「計画」とは何か
多くの場合「ゴール」に向けて1直線に引かれた線だが、
環境に不確実性があって前半に予期しない観測があった場合、後半は「観測前の妄想」になる
grasp
目標は修正してもよい 遠い目標は到達点ではなく「進む方向」を聞いている

作るべきなのは「計画」ではなく「探索面」みたいなものではないか?
進みたい方向・達成されると嬉しい状態群をあいまいに言語化した上で
「その方向に進むために何をやるべきか?」を考える。これは多くの場合複数になり、しばしば並列実行可能。
ここのエージェントがそれぞれを並列実行して知見をLLM Wikiに書き、「探索面」に「これはもうやらなくていい」「次はこれを調べることが必要」と書いていく
この探索面の各要素は planned / doing / done の3つの状態を持てる必要があり、例えばGithubのIssuesとかKanbanとか多くの複数人チームのマネジメントツールが共通してこの構造を持っている
grasp
探索的タスクとカンバンボード 2024年の自分は「高速に変化する世界における探索的タスクにおいてカンバンボードを使うことはミスリード」と書いていた

file backを繰り返して「もう書くことがない!」と言い出してから
「何回file backした?file back毎の書き出し内容の変化は?」と聞いてみた結果
だんだん抽象度が上がっていったりしているみたい
一晩実験を回したみたいな「経験」がリッチな状況では5回くらいfile backしてもまだ書くことが見つかったりする
逆に序盤のfile backでは実験結果の記録だけで考察が足りてなくて、file backのタイミングで関連記事を読むことで「お?自分の解釈と矛盾する観察結果があるぞ?」と気付いたりする
研究作業ばっかりしてないでじっくりと研究ノートを読み返して思考することが大事というメタファー
grasp
時間を置いて再度触れることの価値 Scrapboxではリンクの結合が読み返しをトリガーする

あっ僕がやってるのこれ一種のビームサーチでは?(唐突)

>ビームサーチ(Beam Search)とは、コンピュータサイエンスやAIの分野で、すべての可能性をしらみつぶしに調べるのではなく、有望な候補を一定の数(ビーム幅)だけ残しながら効率よく最適解を探す探索アルゴリズムです。

AIとの会話チャンネルが1本だと一番有益なところを掘って行って深さ優先探索になりがちで、迷子になりがち
AIに現時点での案出しをさせてそれぞれを別チャットで進行するのは幅優先探索
grasp
探索範囲を狭める ビーム幅を絞るのはここで挙げた「幅優先探索+早めの枝刈り」そのもの
探索を加速する抽象度の設計勉強会「全体像がまだ無い → エスキース: 安い試行を並列に多数、認識で選ぶ」「3案3歩」= ビーム幅3の探索

ところが人間が並列で使えるチャット数に限界があり(今の瞬間は7つで、14とかだとしんどいのでたたむ圧力がかかる)
結果として人間の平行チャット処理能力がボトルネックとなったビームサーチになっている
grasp
AI Agentをたくさん並列で使うと効率よく頭がパンクする ボトルネックが人間側にあることの系譜

"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]