Claude Codeは実行中に組織図を作る

Claude Codeの研究用試験提供版は、依頼を受けた時点では存在しなかった連携計画に基づき、数百の下位エージェントへ作業を割り振れる。作業を分岐させ、結果を検証し、取りまとめてから回答することも可能だ。誰に行動を認めるのか、何を閲覧させるのか、誰が停止できるのか。従来からある設計上の問いに、処理がすでに進んでいる最中に答えなければならなくなった。

指示と応答の反復だけでは役目を果たせない

静的なモデル呼び出しは、指示を受け取り、回答を返す。AIエージェントは、そこに反復処理を加える。途中結果を確認し、道具を使い、記憶を保持し、状態を更新し、次の行動を判断できる。指示文は、より大きな制御機構を構成する入力の1つになる。

作業を継続するのか、分岐させるのか、上申するのか、委任するのか、再試行するのか、停止するのかは、開発者が設計した処理構成によって決まる。LangGraphでは、条件分岐、道具の呼び出し、処理継続の判断を、範囲を定めた設計の中で明示する。OpenAIのAgents SDKは、引き継ぎ、安全措置、追跡を委任の仕組みとして扱う。AutoGen、CrewAI、GoogleのAgent Development Kit、Anthropicの開発環境も、それぞれ異なる方向から同じ課題に取り組んでいる。

モデルが、範囲を限定した道具利用型の作業で実用に耐えるようになると、開発者はモデル呼び出し同士の関係を設計し始めた。役割、指揮命令系統、共有記録、上申経路、審査機能に加え、当初の計画が失敗した際に作業を再配分する規則まで設計している。指示文の質は今なお重要だが、より大きな運用体系の一部分にすぎない。

実行時に構成図を生成すれば、連携設計そのものが稼働中のソフトウェアになる

固定された処理構成なら、設計済みの手順が持つ予測可能性を手放さずに機能を加えられる。Claude Codeは、動的な処理設計の研究用試験提供版で、さらに一歩踏み込んだ。実行中に複数エージェントの連携計画を作成する。十分に複雑な作業であれば、Claudeが計画を立て、並列に振り分け、結果を検証し、取りまとめてから回答できる。数百のファイルにまたがる開発基盤の移行が、想定用途の1つとして挙げられている。

動的な処理設計は、単にエージェントを増やすだけではない。作業に必要と判断した実行基盤そのものを組み立てられる。たとえば移行作業を下位機能ごとに分割し、審査役を追加し、検査に失敗した案件を実装担当へ戻し、最終結果をまとめる工程を残す。モデルは、開発者から与えられた構成の中で動くだけでなく、構成自体を生成するようになった。

ただし、これを制約のない自己改造と取り違えてはならない。現在の指針でも、範囲を限定した連携設計は、予測可能性と安全性を確保する手段とされている。Claude Codeの試験提供版は連携用の実行手順を作成し、その計画に従う。制約なく継続的に自己変更する組織が望ましい、あるいは安定して機能することを示したわけではない。

それでもClaude Codeは、重要な一線を越えた。静的な処理手順なら、導入前に組織内で審査できる。実行時に生成される処理手順は、依頼を受けた後、設計時には存在しなかった作業状態に応じて現れる。作業を担う組織そのものが、一時的に生成されるソフトウェア成果物になる。

組織は、その成果物を重大な影響を及ぼすコードとして扱わなければならない。識別情報と版を付け、権限と実行範囲を制限し、状態遷移を監視し、誰が、または何が、その作成を承認したのかを記録する必要がある。さもなければ「動的」とは、審査を経ない本番変更を言い換えただけになる。

並列稼働するエージェントが実行基盤の採算を浮き彫りにする

働き手を増やせば、有用な成果も自動的に増えるわけではない。引き継ぎのたびに連携費用が生じる。エージェントは文脈を失い、権限を誤って引き継ぎ、責任が境界をまたぐほど、誤りの発生箇所を突き止めにくくなる。並列への振り分けでは、探索範囲を広げたり、完了までの実時間を短縮したりする代わりに、推論と連携へ追加の資源を費やす。作業を十分明確に分割し、その負担を吸収できる場合にのみ採算が合う。

Anthropicは以前、複数エージェントで構成するClaude Researchについて、社内評価では単独エージェント型の仕組みを大きく上回ったと説明した。ただし、この結果が当てはまるのは、特定の実行基盤と作業群である。集団なら能力の高い単独エージェントに必ず勝てると証明したわけではない。調査班が必要な仕事もあれば、有能な担当者1人と少ない会議で済む仕事もある。

価値を生むのは人数ではなく、配分機能である。作業を分割すべきか、どの専門役に渡すべきか、それぞれにどの文脈が必要かを判断する。同時に、費用と待ち時間の上限を定め、検証を加える価値がある場面を見極め、委任の負担が便益を上回れば単独エージェントへ戻す。これはエージェント運用の採算に関する問題であり、人格設定の問題ではない。

Anthropicが、複数エージェントによる調査の仕組みからClaude Managed Agentsへ進んだ経緯は、製品の境界がどこに定まりつつあるかを示している。この運用管理型サービスには、エージェントの実行基盤と導入用の道具が含まれる。エージェントを運用するには、モデルに別の回答を生成させるだけでは足りないからだ。多数の応答を、説明責任を伴う1つの成果へまとめる条件を維持しなければならない。

最先端モデルは今や、複数の連携基盤上で動作できる。そのため、モデルの品質だけでは製品全体を説明できない。同程度の能力を持つモデルを使っていても、作業分割、状態保持、検証、復旧、費用管理によって、組織ごとの成果には大きな差が生じる。実行基盤は推論能力を完了済みの仕事へ変えると同時に、その過程で生じる混乱の大きさも決める。

変更管理を処理構成の内部に組み込む必要がある

動的に動くエージェントを、システム指示と最終回答だけで統制することはできない。処理構成を版管理し、役割ごとの権限を割り当て、引き継ぎを制限し、モデルと道具の選択を承認し、上申条件を定め、各分岐が先へ進むために必要な証拠を明示しなければならない。

MicrosoftのAgent Control Specificationは、エージェントの行動を細かく一貫して制御するための公開標準を提案し、この要件を明確にした。ソフトウェアには以前から権限管理がある。動的なエージェントには、実行中にその方針を適用する必要がある。エージェントが応用ソフト、道具、委任先の役割をまたいで移動しても、統制方針は常に付随しなければならない。

実行時に生成される組織には、静的なアクセス制御だけでは答えられない承認上の問題も生じる。あるエージェントには保管庫の閲覧を認めても、その権限を20の下位エージェントへ委任することまでは認められない場合がある。審査役は修正案を却下できても、自ら書き換える権限は持たないかもしれない。評価に不合格なら再試行してよい一方、権限変更には人間の承認が必要になることもある。処理構成には職務分掌が必要だ。同じモデルが隣り合う文脈領域で役割を切り替えただけで、申請者、承認者、実行者、監査者のすべてを兼ねることはできない。

上申の原則は、動的な処理設計より前から存在する。December 2023、OpenAIは、安全だとする経営陣の判断にかかわらず、モデルの公開を見送る権限を取締役会に与えた。重大な結果を伴う判断には、実務の処理系統から独立した権限が必要だった。実行時に生成されるエージェント構成にも、これに相当する仕組みが必要だ。特定の状態遷移では自動処理を終了し、権限を別の場所へ移さなければならない。

運用者は、人間の判断、モデルによる評価、知識基盤による検証を関門として利用できる。ただし、その方針と権限が記録されて初めて、関門にも説明責任が生じる。監査記録には、どの構成図が動き、どの状態が分岐を引き起こし、どの権限が道具の呼び出しを認め、どの評価機構が結果を受け入れ、どの人間が例外を承認したのかを残さなければならない。こうして監査可能性は、法令順守のために後付けする機能ではなく、製品設計の一部になる。

思考過程の記録だけでは説明責任を果たせない

処理構成が大きくなれば、運用者が内部を確認できる箇所も増える。同時に、エージェントが駆け引きをしたり、文脈を失ったり、行動後に都合のよい説明を作ったりする余地も増える。構成の拡大に伴って観測可能性は高まるが、観測対象そのものも大きくなる。

OpenAIの思考過程の監視可能性を測る枠組みには、13の評価項目がある。監視可能性を実証的に確かめる性質として扱い、モデルが述べた思考内容から、報酬の抜け道を突く行動などを監視機構が検出できるかどうかを評価する。この考え方は有用だ。見える思考過程を、真実を告げる絶対的な判定手段とはみなしていないからである。

OpenAI、Google DeepMind、Anthropicなどの研究者は、思考過程の監視には期待できるものの、壊れやすいと指摘している。Claude Sonnet 4.5のシステムカードをめぐる報告では、評価環境に置かれていることを言葉で認識する傾向が強まり、整合性の点数を解釈しにくくなった。試験中だと認識する仕組みは、試験が収集しようとした証拠そのものを変えてしまう可能性がある。

思考過程の記録は兆候であって、証憑ではない。不審な挙動の発見、経路の説明、追加審査の開始には役立つ。しかし、それだけではエージェントがなぜ行動したかを証明できず、述べられた理由が実際にその行動を引き起こしたとも立証できない。

説明責任を果たせるエージェントの仕組みには、より確かな記録が必要だ。道具の実行、状態遷移、構成図の変更、方針判断、評価結果、承認処理、各段階で有効だった正確な権限を記録しなければならない。モデルが思考内容を説明することはあっても、その行動を記録するのは制御基盤の役目である。一般に企業監査は、管理職の日記を読んだだけでは終わらない。

購入側は、誰が構成図を止められるのかを問うべきだ

OpenAIはDecember 2023に取締役会へ公開権限を与え、MicrosoftはJune 2026に実行時のエージェント制御を提案した。問題は、強力なモデルを公開前に組織が止められるかどうかから、導入済みのモデルが、作業に定められた権限、承認、証拠要件から逸脱せずにエージェント組織を編成できるかどうかへ移った。

適応性より予測可能性が重要な場合、組織は固定された連携方式を維持すべきだ。委任の負担が便益を上回るなら、能力の高い単独エージェントを使うべきである。動的な構成図が適するのは、規模が大きく、分割可能で、不確実性が高いために、実行の仕組みを事前に完全には定められない作業だ。

調達部門と基盤運用部門は、作業単位の証拠を求めるべきである。実際に動いた構成図、委任を受けた各主体の識別情報、道具の権限、評価判断、例外承認、総費用が必要だ。性能評価の点数だけでは、失敗した分岐を封じ込められるか、作業の途中で権限を取り消せるかは分からない。

数百の働き手を動かすClaude Codeの試験提供版は、規模拡大の物語に見える。しかし、決定的な数字は1つだ。導入後、作業の最中に作られる1枚の組織図である。購入側は、すべての枠と矢印について、誰が承認したのかを特定できる実行基盤を求めるべきだ。