AIエージェントについての考察
この記事はChatgptと一緒に書きました。私の観察では、Chatgptは論理能力が非常に強いのですが、中国語の表現がどうにも不自然で、誰から学んだのかわからない奇妙なものです。
深夜のアラートが私をベッドから引きずり起こした時、今夜の結末はわかっていました：アラートは役に立つが、ログはゴミ同然になる。画面に表示されたCPUのピークは針のように、システムの「まあまあ動いている」という幻想の泡を突き刺しました。そして、原因究明ができないログの山を見つめながら、私は心にまた一つ覚えを刻みました——可用性は祈りで積み上げられるものではない、と。
その瞬間から、私はあることを確信しました。私が今やっているのは「AIを使ってより多くのコードを書く」ことではなく、AIを使って自分自身をスケールさせることです。まず、自分を実行者の立場から外し、指揮・検収・そしてこのシステムを反復改善する責任者へと変える。それから、そのシステムを使って他者をスケールさせようと試みるのです。
この随筆はそのテーマから始めます。私はマルチエージェントを起動し、トークンを消費し、創造主のような楽しさを感じました。そしてすぐに、プロジェクトの「暗黙知の壁」にぶつかり、評価、報告、記憶といった「あまり魅力的に見えないもの」を一つ一つ拾い上げざるを得なくなりました。その合間に、風邪をひき、料理をし、ボードゲームをし、エディタを変えました——これらは脱線ではなく、私のこのシステムの真の制約条件です：私は脳を一つしか持たず、一日は24時間しかなく、そして本当に疲れるのです。
スケールの甘い点を初めて味わう
この日、私はopencodeのマルチエージェントモードを実際に使い始めました：5つのエージェントが同時に5つの問題を修正します。その2時間の体験は、6.824の最初の課題で分散MapReduceシステムをローカルで動かした初めての時によく似ていました——ログが猛烈な勢いで流れ、タスクが同時に進行し、私の生産性は「手作業の農耕」から「機械化された収穫」へと変わりました。
この過程で、私のCodex Plusプランの週間トークン制限も、初めてこれほど速く使い切られました。
並列処理は簡単に人を夢中にさせます。なぜなら、あまり監視しなくてもよく、自分がボトルネックから解放されたと一時的に信じさせてくれるからです。しかし、並列処理の代償も明白です：コストは線形的に増加し、エラーは拡大されます。最初の方向性が間違っていれば、マルチエージェントは「複数の道を試す」ことではなく、「5台の車が一緒に溝に落ちる」ことになります。
ですから、私の「自律」の定義は、すぐにスローガンから3つの具体的な目標へと変わりました——私はそれをSLIのように書きました：
- できるだけ私を邪魔しない（中断コストの低減）
- できるだけ多く働く（有効なアウトプットの向上）
- できるだけ信頼性を高める（方向性の逸脱、クラッシュ、手戻りの泥沼に私を引きずり込まない）
この3つの目標はその後も繰り返し現れ、LegionMindのすべての設計判断の指針（北極星）となりました。
ボトルネックは私自身
実行作業をできるだけエージェントに任せた後、人間の理性と欲望が作業を進めるボトルネックになりました。
私のワークフローはおおよそ次の通りです：開発、日常のスケジューリング、思考とアウトプット——私はせいぜい2、3のコンテキストを同時に安定して実行できます。この範囲を超えると、私のスケジューリングは機能しなくなり、疲労はメモリリークのように徐々に蓄積していきます。マルチエージェントシステムはこの問題を解消したわけではなく、「実行負荷」を移しただけです。しかし、コンテキスト管理、検収、意思決定は依然として私が行わなければならず、しかもAIの実行が本当に速いため、他の面での負荷はより重くなりました。
その後、私は「作業ログ」というものをより正直に見るようになり、この2026年作業日誌を書くに至りました。その中でも述べたように、これを書くのは将来の詳細な思い出のためではなく、コンテキストを頭の中からアンロードするためです。記録すること自体が思考の連鎖を整理する行為であり、メモリ内のダーティページを整理してディスクに書き戻すようなものです。
私はさらに、ログが「30分座って書かなければならない」儀式になってしまうと、恐怖を感じることに気づきました。恐怖を感じると、更新が止まります。数日更新を止めると、どんどん溜まっていき、最後には書くのがさらに難しくなります。システム設計がどれほど美しくても、人間の習慣に落とし込む段階で、現実に打ち砕かれるのです。この点については、まだ探求中です。以下では、本題に戻ってAIについて話しましょう。
「暗黙知の壁」：AIに指示を出す時、私たちは何を期待しているのか？
エージェントを実際に複雑なプロジェクト——特にmonorepoや複数のパッケージにまたがるプロジェクト——に投入すると、典型的な事故は非常に速く発生します：
私はエージェントに、ある類似の実装（例えばvendor-okx）を参考にして新しいモジュールを統合するよう指示しました。結果、エージェントは正しい書き方を学んだだけでなく、時代遅れの慣行も学び取ってしまいました：私自身のケースでは、その時代遅れの慣行とは、アカウントフローをすでに使われていないエントリーポイントに書き込むことでした。私にとってこれは「プロジェクトがすでに進化した常識」ですが、新しいエージェントにとって、これらの進化は見えません。
その瞬間、私は気づきました：エージェントの「学習」は、組織の記憶から歴史を理解するというより、見えるサンプルからのフィッティングに近いのです。エージェントは「現在の標準」が何かを知りません。
こうして「外部化された脳」は、錦上添花（良いものにさらに良いものを加えること）から必需品へと変わりました。しかし、外部化された脳にも残酷な代償があります：それを維持すること自体が注意力を消耗し、注意力はまさに私が最も不足している資源なのです。
かつて私は一連のAGENT.mdをプロジェクトの記憶として使おうと試みましたが、すぐに難点にぶつかりました：ノイズと、定着させる価値のある経験とをどう区別するか？これはドキュメント作成の問題ではなく、評価の問題です——何がエージェントの失敗を招き、何がその成功率を著しく向上させるかを知らなければ、「記憶」に書き込む価値はありません。
AIに指示を出すとき、私たちは一体何を期待しているのでしょうか？この構造を「指示/知識の階層化」の図式に整理すると、以下のような結果が得られます：
┌────────────────────────────┐
│ ① 今回のタスク指示（明確に説明できるもの） │
├────────────────────────────┤
│ ② プロジェクトの技術的決定/局所的なベストプラクティス │ ← 最も「暗黙的」になりやすく、最も失敗しやすい
├────────────────────────────┤
│ ③ ドメイン背景（問題は何か） │
├────────────────────────────┤
│ ④ エンジニアリング常識/スタイルの好み/経験の蓄積 │
├────────────────────────────┤
│ ⑤ 世界の背景知識 │
└────────────────────────────┘
一つの会話の中で、AIに明確に伝えられるのは、最上層だけです。
結論：コンテキストが小さく、指示が明確で、歴史的負債が少ないほど、AIは高品質にタスクを完了しやすい。暗黙の背景が多ければ多いほど、「不可解な作業」が発生しやすくなります。
これがLegionMindが生まれた理由でもあります。指示を出す人に「完璧なプロンプトを書ける」ことを要求するのではなく、第二層の暗黙知を、ロード可能で再利用可能なものに変えることです。
意図の整合 + 階層的検証
現在のバージョンのLegionMindは、エージェントに対し、ユーザーの指示に基づいてプロジェクト関連情報を収集し、詳細なRFC形式のドキュメントを作成することを強制し、最初の段階でユーザー要求との整合を最大限に図ります。理由は単純です：
マルチエージェントシステムが失敗し始めると、人間の第一反応は往々にして、より長いRFCを書き、より厳格なレビューを行い、リスクを最も前の段階で押し込めることです。人間とAIの協業は、ウォーターフォールに近い形態に押し戻されてしまいます：直線的に進行し、柔軟性に欠け、致命的なことに、私に大きな精神的負担をもたらします。
人間の組織は、どのようにして上位の意思決定者が情報に溺れないようにしているのでしょうか？人間の意思決定者は、どのようにして部下に任せてやらせているのでしょうか？これについてCZはいくつかの考察をしています。
本質的には以下の2点です：
- 意図の整合：エージェントが方向性を逸脱しないようにする。
- 階層的検証：エラーを早期に発見し、簡単にロールバックできるようにする。最後になって方向性が間違っていたと気づくのではなく。
これは空論ではありません。私は自分自身とエージェントの相互作用を制約するために、「生産ライン」式のフローチャートを用意しました：
┌──────────┐
│ 意図 │ 目標/制約/やらないこと
└────┬─────┘
│
┌────▼─────┐
│ 計画 │ 分解、マイルストーン、仮定
└────┬─────┘
│
┌────▼─────┐
│ 実行 │ コード記述/設定変更/ドキュメント生成
└────┬─────┘
│
┌─────────▼─────────┐
│ 検証 │ 階層的検証（安価なものほど先に実行）
│ - ビルド/lint/テスト │
│ - e2e/ベンチマーク │
│ - モデル評価 │
│ - 人間によるレビュー │
└─────────┬─────────┘
│
┌────▼─────┐
│ 報告 │ 結論 + 証拠 + リスク
└────┬─────┘
│
┌────▼─────┐
│ 記憶 │ 「記録する価値がある」差異点を定着化
└────┬─────┘
└──(意図/計画へのフィードバック：フィードバックループ形成)
このプロセスの肝は「より複雑にする」ことではなく、検証を前倒しし、フィードバックをループ化することです。これは最も一般的な2種類のロスに対抗できます：
- 方向性が間違っているのに並列推進を続けること（トークンの大出血）
- 方向性は合っているが詳細が信頼できず、繰り返しの手戻りを招くこと（心力の摩耗）
評価の2つの言語：pass@k と pass^k
AIエージェントのパフォーマンスをどのように評価するかについての記事は、私に大きな示唆を与えました。
AIを使ってタスクを完了させる場合、一般に2つの全く異なる作業タイプに分けられます：
- 能力探索型：一度で正解であることは気にせず、「それが可能かどうか」を知りたい。この場合、焦点は
pass@k——k回の試行で少なくとも1回成功する確率——です。 - 生産回帰型：「たまにできる」は受け入れず、「毎回確実」である必要がある。この場合、焦点は
pass^k——k回の試行がすべて成功しなければならない確率——です。
同じシステムでも、段階によって異なる指標で語るべきです。能力探索段階では、AIエージェントがその豊富で博識な世界背景知識を十分に発揮できるよう、少なめに指示し、多くを聞くことができます。回帰段階では、一貫性に注目しなければなりません。
┌────────────────┐
│ 人間による評価 │ 設計/リスク/境界条件の確認（最も高価）
├────────────────┤
│ モデルによる評価 │ ルーブリック/整合性/一貫性チェック（中程度）
├────────────────┤
│ 静的/ツール評価 │ ビルド/lint/単体テスト/e2e（最も安価）
└────────────────┘
原則は単純です：ツールで判断できるものは、認知的負荷をできるだけ減らす。
「報告インターフェース」は過小評価されているエンジニアリング問題
前の章では「エージェントにどうやって作業させるか」について話しました。それ以外にもう一つの重要な点は「私がどうやって低コストで検収するか」です。この部分はまだ考え中ですが、いくつか簡単な考えがあるので、ここでついでに話しておきます。
核心的な考えは：AIの報告は、平らなMarkdownやコード差分のままに留めてはいけない、ということです。人間の組織では、部下の報告にはしばしばPPTが必要で、場合によっては中間管理職が「高価な伝声筒」となって、複雑な情報を意思決定可能な結論、証拠、リスクに圧縮します。
では、AIのレポートは何であるべきでしょうか？
非常に具体的な考え：すべての結論は、何らかの成果物（artifact）にリンクされるべきです。例えば：
- 「この機能は完了しました」 → e2eテストレポート、重要な差分、再現実験スクリプトへのリンク
- 「この選択肢の方が優れています」 → ベンチマーク比較、ログ証拠、設定変更へのリンク
- 「ここにリスクがあります」 → 既知の不確実性リスト、ロールバック案へのリンク
引用エージェント（Citation Agent）を専用に設けることさえ可能かもしれません：コードは書かず、ただ一つのこと——結論と証拠を結びつけること——だけを行います。
報告インターフェースが改善されて初めて、人間はより安心でき、真の自律が成立します。そうでなければ、エージェントのコーディング能力がどれほど優れていても、私は依然として「エージェントが書いたものを読み、エージェントが実際に何をしたのかを推測する」ことに大量のエネルギーを費やさなければなりません——これは私が望む「摩耗の少なさ」と矛盾します。
エンジニアリング的イテレーション
2月になると、Chatgpt codex 5.3がリリースされ、体験上、非常に賢いと感じさせられました。それゆえに、一つの懸念が生まれました：ワークフローをあまりに厳格に規定しすぎると、かえってAIの可能性を無駄にしてしまうのではないか？
LegionMindがこれまで試みてきたのは、確固たるフレームワークと、あるドメインにおける比較的成熟したSOP（上の図の3、4層）を与え、エージェントが与えられたレールの中で走り、方向性の逸脱を減らすことです。しかし、モデルがより賢くなった時、より合理的な方法は——私が目標、制約、評価メカニズムだけを与え、AI自身に最適なパスを設計させることかもしれません。
これはまた、別のことが起こらなければならないことを意味します：感覚的に「このバージョンの方が賢い」と言うのではなく、異なるバージョンのシステムのパフォーマンスをより科学的に比較する方法を取らなければなりません。
こうして「ベンチマーク」は、私の頭の中で一つの考えから必須要件へと変わりました：私は複雑なコーディングタスクの回帰テスト一式を必要とし、同じ一連のタスクを使って以下を定量化します：
pass@k（能力探索）pass^k（生産信頼性）- コスト（トークン/時間）
- 手戻り率（人間の介入回数、修正ラウンド数）
- カバレッジ（プロジェクト間、パッケージ間での安定性）
これによって初めて、私は「気分をイテレートする」のではなく、本当に「システムをイテレートする」ことができるのです。
この方面に関して、私は次に2つのことを行う予定です：
- 市販のLLMコーディングベンチマークを調査し、そのまま使えるものがあるか確認する。
- 私たちの実際のシナリオに基づいて、異なるバージョンのLLMとLegionがタスクを完了するためのベンチマーク（LLM面接問題）一式を設計する。360度評価さえも可能かもしれない。
8. マイルストーン
ある夜、私はこのLegionMindシステムを使って、ついに複数のプロジェクトにまたがるhttp-proxyタスクを完了させました。過程はエレガントとは言えず、現在のシステムの限界に触れることさえありました——サブエージェントが時折クラッシュし、パッケージをまたがるコンテキストがマルチエージェントの協業を脆弱にしました。
しかし、結果は私が気にかけるマイルストーンでした：私は基本的にコーディングから離脱できるようになったのです。ほとんどの場合、私は設計ドキュメントへの少量のレビューコメントを残すだけで済みます。
このような変化は、私に非常に心地よさをもたらしました：キーボードの実行者から、審査者、意思決定者、システムのイテレーターへと変わること。つまり、最初に言った「自分自身をスケールさせる」ことです。
同時に、私はある現実的な原則をより進んで認めるようになりました：波に簡単に押し流される車輪を作ってはいけない。私は、ある能力プラットフォーム自体が進化している（例えばopencodeが既にある種のbridgeの機能を実装しつつある）ことに気づき、むしろ保留にしてでも、エネルギーを「海面の上昇と共に上昇する」システムレイヤーの能力——評価、記憶、報告、信頼性——に投じるべきだと考えています。
私とAIエージェントの相互馴化
ここまで書いて、私はこの1ヶ月以上、私とAIエージェントは実は互いに馴化し合っていたことに気づきました：
- 私がエージェントを馴化：SOP、検証、報告インターフェースを使って、「コードを書けるモデル」から「納品可能なシステム」へと押し上げる。
- エージェントが私を馴化：人間のボトルネック、評価の重要性、組織とプロセスこそが問題の核心であることを認めざるを得なくさせる。
この経験を一言で圧縮すると、今の私はおそらく次のように信じています：
- 自律は賢さだけで十分ではなく、邪魔が少なく、アウトプットが多く、検証可能であること。
- 最も高価なのはトークンではなく、手戻りと注意力の漏洩である。
- 暗黙知はコードよりもエージェントを失敗させやすい。外部化された脳は必須だが、維持管理可能でなければならない。
- 検証は階層化し、目標は段階分けする：まずpass@k、次にpass^k。
- AIの報告インターフェースはエンジニアリング化されなければならない：結論は証拠を伴い、できればワンクリックで成果物を参照できることが望ましい。
- モデルが強力になれば、プロセスはAIに権限を委譲する必要があるかもしれない。しかし、委譲の前提はベンチマークを持つことである。
次に私が行うことは、おそらく2つです：1つはベンチマーク体系を構築し、「legion/マルチエージェントシステムをイテレートする」ことを測定可能なものにすること。もう1つは、report/citation/artifactの連携を補完し、私がより楽に、より安定して仕事を任せられるようにすることです。
そして、最も素朴な願い——「できるだけ摩耗を少なく」——について、今の私はそれを願望ではなく、システムの非機能要件であるべきだと考えています。私がまだコードを書き、アラートで起こされ、ボードゲームや料理を楽しんでいる限り、この要件は永遠に成立するのです。