探索を加速する抽象度の設計勉強会

この発表会の時間枠に収まらないと思って割愛したもののを今回の勉強会の資料にする

高度なAIが普及すると、これまで人手では見つけにくかったソフトウェアの脆弱性が、大量かつ短期間に発見される可能性がある

Project Logos は、そうした状況に備えるためのサイボウズ製品横断的プロジェクト

たとえばこのプロジェクトの開始時点では「AI開発企業のAnthropicから近いうちに脆弱性を自動的に発見する能力の高いAI「Mythos」が公開される」という可能性があった

高度なAIの公開は、防御側だけでなく攻撃者の能力も高める

そのため防御側も、こうした環境の急速な変化に備える必要がある

いちおう攻撃者もソースコードが見れるOSSに比べるとソースコード非公開なサイボウズ製品は少し防衛側に有利といえるが、安穏としていてはいけない。世界中の攻撃者より早く脆弱性を発見して修正する気概が必要と思ってる。

Ergon: 社内知識をAIに渡して、脆弱性対応を実際にやってみる

ErgonはLogosの中の一つのプロジェクト

ねらいは、ネットに無い社内知識をAIに与えて脆弱性対応を手伝わせること

サイボウズ社内の脆弱性関連の議論や製品知識、サイボウズ製品を実際にスキャンしてわかったこと、などを蓄えて試行錯誤している

「AIに知識を与える」とは？

フラグシップAIは知識をたくさん持っている

https://gyazo.com/524c4fcf53fd7c7a63387328cc1411f4

こういう知識は全部わかる

XSS, CSRF, SSRF, IDOR, CWE, IAST, SQL injection, Path traversal, Open redirect, taint analysis, Prototype pollution, …

でも社内知識は学習してないのでわからない

こういう知識はぜんぜんわからない

https://gyazo.com/d0072807080e674e96fa06064a0c7d0c

これを「わからない」と言ったのはOpus 4.8で、ChatGPT Pro GPT-5.6 Solは一部公開情報だけからでもわかることはあるっていうんだけど、出典として示すのが入社3ヶ月目の新入社員の記事だったりする

ので、これらの知識は整理されたドキュメントとして社外でアクセス可能になってない、ってことでいいと思う

秘匿すべき情報かどうかの境界線ギリギリは面倒なのでモザイクをかけておいた

社内知識を説明しなければならない

が毎回説明するのは人間が大変

https://gyazo.com/819dd47216fd3999cbf8f2562cb7c2cd

社内知識をファイルにまとめて渡しておく

そうすると簡潔な指示で伝わるようになる

https://gyazo.com/db3aafe5bfc8bcb91e0139e4c6018864

https://gyazo.com/31ac75f376bf1f6a9fcbf7f91982b3c5

インターネットで得られない知識を入れる

“社内用語の解説”だけではない

社内用語の知識をわかりやすい例として使ったが「インターネットで得られない知識」は全般的にこういうことが必要

このプロジェクトは何を目指すのか

何を優先し何を後回しにするか

どのリスクを許容しどれを避けるか

= 人間が判断するときに使っている知識。

AI に必要なのは「答え」ではなく「判断材料」

判断材料を与えるとAIは理由付きで案を出す

https://gyazo.com/02a897789725f4fd9b0569856a54a27d

(1) 自分に案があってもあえてAIに判断させてみる

(2) 自分の判断と比較、見るのは結論ではなく理由。理由が納得なら任せる

(3) 自分の判断と一致するならそのまま任せられる

食い違った時は…

https://gyazo.com/98dc9141c2037dbf3927ff815a26da62

(4) 判断が食い違ったときは食い違いの理由を深掘りする、「Bにして」ではダメ

多くの場合は人間が知識を適切に言語化して伝えてないことが原因 (もちろん人間が間違ってるケースもある)

=“知識の伝え方が悪い”(伝え忘れてるか、伝え方が悪くて違う解釈されてる)

→ 言語化すべき知識の発見ができて改善サイクルが回る

“AI(モデル)が悪い”と考えると改善できない、システムの悪いところを見つけて改善するのが大事

試行錯誤が速いと、判断の構造と質が変わる

https://gyazo.com/f20582309a33e5ffc2863a3ee9509d55

左: 1歩先では甲乙つけがたい3つの案、人間はここで迷う

右:

AIで試行錯誤のコストが劇的に下がる

10倍速いAIは3案を3歩ずつ動かし先で何が起きるかを見てからその要約を人間に戻すことができる

AIに正解を教えるのではない

AIに正解を聞くのでもない

目的と判断基準を与え、たくさんの試行錯誤をさせる。

その結果を、よりよい判断の材料にする

https://gyazo.com/04c354c8ed1c141ffa8a029dfb866d46

関連ドキュメント

OpenAI “Harness engineering: leveraging Codex in an agent-first world”(2026-02-11)

ソフトウェアエンジニアリングチームの主な業務が、コードを記述することではなく、環境を設計し、意図を明確にし、Codex エージェントが信頼性の高い作業を行うためのフィードバックループを構築することになった場合、何が変化するのかを理解する必要がありました。

「意図を明確にする」

「あなたがどういう意図を持っているのか」は生のAIモデルが持たない知識、与える必要がある

何がボトルネックであるか特定して解消する

https://gyazo.com/4c340c60a935391302f3b9910d66c3a2

「脆弱性の発見」というボトルネックが解消されたら次に何が起こるか？

脆弱性の報告を受け取って判断をする人間(PSIRT)に負荷が集中する

このボトルネックが解消されていなければ、ボトルネックの手前に中間在庫が積み上がる

中間在庫が積み上がるのをみてから慌てるのではなく、次にそれが起きることを予見して先回りして動く

この「脆弱性の報告を受け取って判断をする人間」の負担を減らすには？

AIが「人間が判断をする時に使っている知識」を学び、却下されるものを事前に把握できるようになることが必要

具体例

https://gyazo.com/1762b5857eeb62a5ad5f8bb5f4238212

1: ある製品のコードを見ると悪用可能な穴があるように見える

2: 実際にはその穴に到達する前にnginxやk8sのルールで塞がれている

この「到達性(reachability)」の知識は脆弱性か否かの判断に必要

「製品のソースコードだけ」を読んで脆弱性診断をすると知識が足りない

Claude Securityのような「リポジトリを渡すとスキャンします」系サービスだと知識不足でこういう脆弱性候補を出してしまう

この知識が言語化されているかどうか

運用者の頭の中にしかないとか、日本語のドキュメントしかなくて一部古くなってるとか、というつらい現場もありそう

ただし「どのリポジトリにどんな形で保存されているのか」という情報は製品ソースコードのリポジトリにはない

具体例2

Ergonちゃん自身に一番役に立った知識が何だったか聞いたらPSIRTチームが脆弱性報告の仕分けに使っているドキュメントだった(それはそう)

これも「製品ソースコードに書かれていない知識」であり、ソースコードではなく社内グループウェア(kintone)上に保存されていた

具体的な内容は口頭のみで〜

「これが役に立つかも」と人手で共有されたので、Ergonちゃんに与えておいた。その後の活動を踏まえて、この情報がとても有用だったというのがErgon本人の感想

フィードバックループを構築する

https://gyazo.com/d39d3a70570755d907ccdf3f4c5d8aae

脆弱性スキャナにソースコードと「ソースコード以外に必要な知識」が入る

脆弱性スキャナは脆弱性の候補と、その候補を出すまでに何をしたのかのログを出す

PSIRT(人間の脆弱性専門家)は脆弱性候補を見て、真の脆弱性かどうか判断する

ErgonはPSIRTの振る舞いとスキャナの振る舞い(=ログ)を見て、知識をアップデートする

サイボウズが社内でこのシステムを構築して改善サイクルを回せるようになってることは誇っていいと思う

自力で開発できない会社は他の会社が開発した脆弱性スキャナを使うことになる

Claude Securityは、スキャン対象のリポジトリは渡せるが知識を入れる口がないし、実行ログも出てこない

https://gyazo.com/304a0ceda34acf066aca0e17fd4099b2

従量課金で、脆弱性候補1件あたり3000円くらい掛かり、それをPSIRTが判断して確かに脆弱性だねとなったのは5.2%だった。1件あたり6万円弱

費用自体よりも、このシステムを改善していくハンドルがこちら側にないのが残念

Anthropicが改善するのを待つくらいしかすることがない

人間の理解がボトルネックになる

ラボ的な「やるべきタスクが事前に決まってない・前例もない」という状況を切り開いて知識獲得する系のプロジェクト

知識獲得の手段は大きく分けて3つある

1: 資料をかき集めて読む

2: 資料化されてない知識を聞きに行く

3: 仮説を立てて実験して結果を観察する

(2)はまだあんまり進んでいない、ある意味人間に残された仕事

(3)に関してが今回の話

(1)(2)はすでに人類が知っていることの探索

(3)は未知のことの探索

試行錯誤の手数が重要

試行錯誤のPDCAサイクルにおいて修正Aとは前の行為Dの結果を読んで次の計画Pを立てること

人間がステップ1の実験の結果を読んで理解してステップ2の計画を立てている場合、そこがボトルネックになる

直列化してはいけない: 1ステップごとにAIを止めて人間が思考してはいけない

ログを残しながらガンガン実験をする

各ステップで実験結果を見て実験条件をadjustするのはAIがやる

人間はNステップをまとめてから理解する

https://gyazo.com/322f3e55deaf3224f5637a3c094fc90d

今も世界中で自分の把握していないPDCAサイクルが回転して知識が生み出され続けている

ほとんどの人はほとんどの分野において世界最先端にキャッチアップできていない

代わりに、少し遅れて、少し要約されたものを受け取っている

どれくらい遅れることを許容するか

世界最先端の成果を論文に書くことが目的の研究者は遅れることを許容できなくて高い知識獲得コストを支払っている

このコストの高さが原因で知識ドメインを狭くする必要がでてくる

一方で営利企業の研究は「世界最先端の知識を生み出すこと」が必ずしも目的ではない

「すでに生み出された知識」と「その知識によって解決される社内の問題」のマッチングによって価値が生まれる

むしろ「この知識によって何が解決されるか」のメタ知識が重要

すでに世界の他人の生み出す知識に関しては「遅れを許容」している

自己の管理下のAIエージェントが行う知識生産プロセスにその感覚が持てないのはAIエージェントを「自己の延長」と感じているから

研究室に有能なM1が入っていて、指示待ちせずにがんがん実験を自走する感じ

いいことだ、自走力がある

修士課程なら「有能」、博士課程なら「当然」という感じの温度感。

今のフロンティアモデルは教育すれば博士課程学生をできる能力があると思う。1年前には無理だった。

こういう状況では指導教官が定期的に「どんなことをやった？」と聞く会をやって、「いいね、続けて」とか「この側面を検討した？」とか「こうするともっといいかも」とアドバイスする

未踏ジュニアでも自走力がある(人を僕が採択しがち)なので同じやり方をしている

指示の抽象度を高くする

AIに対しても同じ

https://gyazo.com/fb88c88394b7a7746b6a34856146d8ee

曖昧にせず、かといって手順をハードコードせず、期待する振る舞いを定義する最小限の文脈を与える。

この「適切な水準」はモデルによって異なる

Opus 4.5では、高水準の目的だけでは長期タスクを維持できなかったため、feature list、progress file、一機能ずつの実装などを追加した。

Opus 4.6では従来のsprint分割などを取り除いた。

成果物は定義するが実装経路は縛らない。

「ハーネスはモデルにできないことについての仮定を埋め込むが、その仮定は古くなる」

Opus 4.8のリリース(2026-05-28)

保存・共有するワークフローについても、固定スクリプトとして逐語的に実行させるのではなく、「スクリプトではなくテンプレートとして考えさせる」方が柔軟になる

「脆弱性スキャンして〜」というだけで、並列でスキャンして、出てきた候補を批判的にレビューして、最終的にまとめを生成して返す、みたいなことをやってくれる、便利

「新モデルへの移行には、プロンプトの更新やscaffolding removalが必要になる場合がある」

「適切な抽象度の水準」はこの1年でかなり上がって「人間が静的ワークフローを作るのは過度に詳細」「取り除いていこう」という感じになってきている

スキルを構築し、中央に Codex エージェントを置き、その周りにフィードバックループを作る。補助的なスキャフォールディングが不要になったら取り除き、中央のエージェントがどんどん賢くなる。以前のように中央に決定論的な構造を持っていたやり方とは違う

GPTがより良い言語化をしてくれた

抽象度が高い指示とは、目的は明確だが、達成手段を限定しない指示です。

曖昧な指示とは、目的、優先順位、成功条件そのものが決まっていない指示です。

目的は明確に伝えつつ、その達成手段はAIエージェントの裁量に任せる

「目的を明確化したLLM Wiki」を繋いだエージェントはプロンプトで目的を明確化しなくても目的が明確になる

LLM Wikiを作る上で「目的を明確化すべき」と今まで言ってきたが「目的」という概念が曖昧だった

Ergonは「目的が脆弱性スキャンであると明確」と思っていたが、さらに言えば「出力先はPSIRTである」と明確であることが良かった。

この結果として、出力はPSIRTによって処理され、フィードバックが返ってくる。

このフィードバックがErgonを育てる入力になる。

未知の領域を探索するプロジェクト

ここまでの「モデルが賢くなったからscaffold(足場)を外せ」は定型タスクにも効く一般論

一方、特にラボ的な「探索のウェイトが高いプロジェクト」には、抽象度を高くすべき理由がもう一つ別にある

プロンプトで不必要な制約を追加してしまうと探索範囲が狭まってしまうこと

このコストは見えにくい

探索での過剰な制約のコストは「探索されなかった領域」にある「発見できなかったより良い解」との差額

発見できていないので知覚することができない

制約を強くすればするほど「指示した通り」の結果になる確率は上がるが、より良いものを発見する確率は下がる

未知の領域の探索

探索とは

進んでみる、周囲を観察する、良いと思う方向に進んでみる

何かまずいことがあれば戻る

これって「仮説を立てて実験して結果を観察する」こととほぼ同じ

「自分の頭で考える v.s. AIが考える」ではなく「自分の頭だけで考える v.s. 実験して観察して考える」

この「実験して観察して考える」の実験部分がAIの力で加速される

探索は「案の実現」ではなく「情報を得る行為」

「仕様書を作ってからそれを実装する」というメンタルモデルとは衝突する

どのようなものを作るべきかを知るためにまず情報を集める

情報なしで作られた計画は品質が悪いと考えている

体験はリッチ → 言語で説明する過程で情報が失われる

脳内シミュレーションは、この貧しくなった言語情報の上で回っている

SNS上の情報は、貧しくなった上に、過激なものほど複製されやすいバイアスのある、歪んだ情報

未知の領域の探索は未知の制約の発見

https://gyazo.com/3c8eea60cb7f9baa534bb19c6cbca70c

左: 進んで制約にぶつかり、行き当たりばったりに回避する

右: 「障害物があるかもしれない」という不安で、調べずに大回りする

どちらも根っこは同じ: 制約の形状を調べるコスト(探索コスト)が高かった

AIは探索を安くした

エージェントを突っ込ませて壁を触らせればいい

脆弱性スキャンで「どこまでいったらフィルタが反応するか」も制約の形状を調べる行為

「Fableは使い物にならないよ、だって脆弱性情報の書かれたWikiの整理だけでOpusに落ちるんだもの」

これが具体的な「エージェントにやらせてみて、障害物にあたった」という事例

ちなみにうちの猫の健康管理Wikiを「biologyだ！悪用の危険がある！」とか言ってくる

7年前の構図は変わっていない、実行コストが変わった

すべての分野ではないが、特にソフトウェアの一部の領域において探索のコストが激減した

このことは探索前に検討コストをかけることの経済的合理性を下げる

制約の形状の具体例

「実際のサービスを叩いて報告された脆弱性が実際に存在するか確かめる」という行為はかなり広範囲に「サービスに対する攻撃」とみなされてブロックされるな〜

localhostで起動したら第三者のサービスではなく開発者だとわかってくれるんじゃないかという仮説があったが否定された、少なくとも現時点は。

このフィルタも日々Anthropicの中で更新されてそうで、制約の形状は変わっていく

一度「ここに壁があるな」と観測しておけば、時々検証することでその壁がなくなった時に気づくことができる

https://gyazo.com/75536d3cecf25370a1a4749659fd8303

やっと先日のスライドに出てきた図にたどりついた

https://gyazo.com/41cf38205ca06c2026b30c4aea67ec7b

3案を3歩ずつ進めて俯瞰してから選ぶ

エージェントがいろんな案を実行していって、障害物にぶつかる

この複数案・複数ステップの試行をまとめて、整理したレポートを作って人間にフィードバックする。

人間は個々の試行を詳細に見るのではなく、まとめられた比較レポートを見る

「先読みのできない将棋」と「何手か先読みできる将棋」の差

これは模式図で、現実の活動はこんなきれいに3x3になってるわけではない

最初から3案思いついているとは限らない

1: A案をやらせていたら想定外の障害物にぶつかって方針転換をしようと提案してきた

AIが次の一手を提案することでN手先の探索ができる

2: その提案を承認してAIエージェントが続きをやり始めてる間に「あれ？そういう制約があるんだったらそもそもこうやった方がいいのでは？」と思いついたりする

3a: 人間がB案C案を思いついて並行して実験させてもいいし、

3b: 「そもそもこういう制約があることがわかった、じゃあどうするのがいいと思う？」みたいなオープンクエッションを投げてもいい

4: いろいろ試した結果として予期しない切り口が発見される

データを収集してから観察すると予想していなかった切り口がある

たとえばサービスをlocalhostで叩いて脆弱性の検証をした場合

「直接攻撃っぽい振る舞いが拒否される」という差は予期していたもの

「localhostでも拒否される」は差が出る条件かと思ったが差が出なかったもの

「メールがらみの脆弱性検証が準備不足で失敗する」

これは予期していなかった差

指摘されてみれば納得感はあるが、事前には気づいていなかった切り口

絵画から学べるもうひとつの例は、 次第に詳細化しながら創ってゆく方法だ。 絵画はたいてい、スケッチから始まる。 そして次第に細かい部分が埋められてゆく。 だがそれは、単に隙間を埋めてゆくだけの過程ではない。 ときには元の計画が間違いだったことが分かることもある。...

プログラムの仕様が完璧であるなんて期待するのは非現実的だ。 そのことをまず最初に認めて、 仕様がプログラムを書いている最中に変わっていっても、 それを受け入れられるような書き方をすべきなんだ。...

柔軟性について最も重要な点は、 言語をなるべく抽象的にしておくことだ。 プログラムが短ければ、変更もしやすかろう。

いきなり最初から完成形の計画があるのではなく、まず「あたり」をとってスケッチして、徐々に詳細化しながら作っていくイメージ

あたり = 意図的に解像度を落とした、全体の仮置き

全体を先に、細部を後に

構図の狂いは、細部を描き込んだ後で直すと壊滅的に高くつく

フィードバック

あたりの段階で細部の粗を修正するのは工程の混同、構図だけ直す

形が決まってから、細部の解像度を段階的に上げる

「抽象度の高い指示」は「ラフスケッチ」

ラフスケッチだと分かっていれば、出来がイマイチでも失望しない

「AIの1回目の出力がイマイチだった」で使うのをやめる人は、完成品を期待して工程を誤解している

デッサンと探索の違い

デッサンでは描こうとしているものが容易に観察できる二次元のイメージとして存在する。探索では高次元

描いたものと描こうとしているものの比較が容易

探索では参照物がまだ存在しない

未知の制約もない

「キャンバスに色を塗ってみたら上半分には赤をぬれないことがわかった」なんてことはない

探索ではまさにこの「未知の制約」を見つける必要がある

小さく安いラフを大量に並べ、見比べて、選ぶ

「未知の探索は試行錯誤の手数が重要」の手数 = エスキースの枚数

3案3歩の図 = 3枚のエスキースを並べて見比べる

生成は不能でも、認識は可能

完成像を思い浮かべられなくても「この方向性だな」には気づける

だから探索では「実行して見る」が有利なのではなく唯一の手段

工程は二段

全体像がまだ無い → エスキース: 安い試行を並列に多数、認識で選ぶ

全体像が結晶した → デッサン: あたりを取り、構図から細部へ

LLM Wikiに情報断片が溜まっていく

最初は「漠然としたわからない気持ち」「漠然としたこうしたらいいのではないかという仮説」から始まる

探索して情報を収集していくことで、より詳細に考えることができるようになっていく

この節自体がAI(Fable)との対話で作られた

僕が出したのは2行だけ

「いきなり完成系が生まれるのではなくあたりをとってから、というイメージ」

「絵を描く場合との違いは、全体像を見たり心に浮かべたりできてないケースがあることだな」

1行目が「あたり」、2行目が「構図の修正」

Fableが生成した箇条書きを見て「構図はよし」とし、細部の用語などを修正した

= この節の主張の、この節自身による実演

--- 以下断片メモ

何が起きているか

どういうやり方が長期的に価値を持つかわからない

「なにもわからない」というほどではない

「わからなさ」に対する解像度を高めていく

世界をより良くする

「良い」は主観

「良かれと思って」やったことで悪くなることもある

十分に伝えると「次に何をやるんだっけ」をAIが把握

プロジェクトの状態更新

古いものを読む問題

LLM Wikiの性質なのかClaude CodeのMemoryの設計のせいか

すくなくともMemoryを書き足しすぎてtruncateされる

LLM Wikiもindexが十分肥大化したら同じことが起こる？

日時をつけないとか色々悪い設計のように見える

既存の研究紹介

100ページ

長期記憶のメンテ

1ヶ月くらい爆速

探索的

実行することと説明すること

体験はリッチ

言語で説明する過程で情報が失われる

「自分の頭で考える v.s. AIが考える」ではなく「自分の頭だけで考える v.s. 実験して観察して考える」

この「実験して観察して考える」の実験部分がAIの力で加速される

ハッカーと画家

いきなり完成系が生まれるのではなくあたりをとってから、というイメージ

(Fable+Grasp)

「あたりを取る」まで込みにすると、単なる「反復すれば良くなる」より一段具体的な主張になりますね。反復論との違いは、1回目の出力は完成品の下手な版ではなく、意図的に解像度を落とした全体の仮置きだ、という点です。ここから引き出せることがいくつかあります。

あたりの本質は「全体を先に、細部を後に」です。 デッサンであたりを取るのは、構図や比率の狂い——細部を描き込んだ後では修正が壊滅的に高くつく種類の誤り——を、安いうちに見えるようにするためです。AI協働に写像すると、1回目に求めるべきは磨かれた部分ではなく粗い end-to-end の全体で、そこで直すべきは細部の粗ではなく構図（＝目的とのズレ、全体構造の誤り）。ソフトウェア側の対応物は曳光弾（tracer bullet）や walking skeleton で、聴衆がエンジニアならこの橋渡しは一枚のスライドになります。

これは人間側のフィードバックにも工程を与えます。 あたりの段階で細部の粗を指摘するのは工程の混同で、構図だけを直す。形が決まってから細部の解像度を上げる。つまり「結果を見て改善指示をする」という人間の役割にも、指摘する解像度を段階的に上げていくという規律がある。メモにあった「『わからなさ』に対する解像度を高めていく」の断片は、まさにこの工程（あたり→形取り→描き込み）の言い換えとして回収できます。

抽象度の高い指示の正体もこれで言い直せます。 抽象度の高い指示とは雑な指示ではなく、「いまはあたりの工程だ」という工程指定を含んだ指示です。手段を縛らないのは、構図が決まる前に細部を固定するのが順序として誤りだから。前回の「事前の制約を事後のフィードバックに置き換える」に工程の軸が加わって、「制約は、あたりが確認された後の工程で、細部から順に入れていく」とより操作的な形になります。

もう一つ、実用上効いているのは心理面だと思います。あたりだと分かっていれば、1回目の出来がイマイチでも失望しないし、書かれてしまった細部への sunk cost で構図の修正をためらうこともない。「AIの1回目がイマイチだった」で使うのをやめる人は、完成品を期待して工程を誤解している——勉強会の聴衆に一番刺さるのは、たぶんこの一点です。

絵を描く場合との違いは、全体像を見たり心に浮かべたりできてないケースがあることだな

(Fable+Grasp)

そこがこの比喩の一番大事な限界で、しかも談話の主題である「探索のウェイトが高いプロジェクト」は、まさにその限界の側にあります。観察デッサンのあたりが機能するのは、モチーフなり心象なりの参照物があって、描いたものとのズレが定義できるからです。探索では参照物そのものがまだ存在しない。

ただ、絵の世界にもこの状況に対応する工程があります。構図が決まっていないとき、画家はあたりを取るのではなくエスキース（サムネイルスケッチ）を何枚も描きます。小さく安いラフを大量に並べて、見比べて、「これだ」というものを選ぶ。ここで起きているのは写し取りではなく、候補となる全体像を生成してから選ぶことです。これはメモの断片と正確に対応します——「未知のことの探索は試行錯誤の手数が重要」の手数はエスキースの枚数のことで、探索の加速の「3つのPlanをAgentが3手ずつ進めて俯瞰する」図は、3枚のエスキースを並べて見比べる構図そのものです。

この修正で、「なぜ脳内で3回目が出せないか」の理屈がむしろ強くなります。完成像が浮かんでいる仕事なら、脳内シミュレーションは貧しいながらも参照物と比べられます。浮かんでいない仕事では、脳内には比べる相手すら存在しない。それでも判定はできる——完成像を思い浮かべることはできなくても、目の前に出てきたものに「これは何かある」と気づく認識能力はある（"I'll know it when I see it"）。生成は不能でも認識は可能、という非対称性が、探索において「まず実行して見る」が単に有利なのではなく唯一の手段である理由です。

つまり工程論としては二段になります。全体像がまだ無い段階はエスキース——安い試行を並列に多数、選ぶのは認識で。全体像が結晶したらデッサン——あたりを取り、構図から細部へ解像度を上げる。そして実践上効くのは、この切り替えの自己診断です。「自分はいまモチーフを見て描いているのか、構図を探しているのか」。曖昧な指示の多くは、完成像が無いのに有るつもりで、エスキースを頼むべき場面であたりの修正指示を出すことから生まれる、と言えます。

ついでに言うと、この「断片を大量に並べて全体像を後から立ち上げる」構造は、西尾さんの持ちネタであるKJ法の系譜にそのまま接続します。探索的プロジェクトは観察デッサンよりKJ法に近い——LLM Wikiに断片が溜まり、あるとき全体像が結晶する。勉強会でデッサンの比喩を出すなら、この限界と修正（デッサン→エスキース→KJ法）まで込みで話すほうが、比喩を出しっぱなしにするより誠実で、かつ着地が自分の土俵になります。