AIエージェント

エージェント間の調整がgitで偶然できた仕組みとpush頻度の罠

2026/10/2 （更新: 2026/10/11）

🤖 AIを使用して執筆

演習では、計画ファイルがソースコードと同じcommitで全員に届いた

材料は、この演習の当事者が書いた記事である。著者のGiles Edwards-AlexanderはThoughtworksの欧州・中東・インド地域のCTOで、記事はmartinfowler.comの連載「Exploring Gen AI」の一本として2026年9月2日に公開された。演習では、Thoughtworks Europeがバルセロナのオフィスに10人の技術者を集め、航空会社の運航乱れ対応（IROps）システムを4日で作った¹。

10人の技術者は一つの部屋に集まり、全員が一つのリポジトリで同時に作業を始めた。記事は「多数のエージェントが一つのリポジトリで働いたことで、ビルドのパイプラインが苦しんだ」と書く。そこでチームは、エージェントがmainから継続的にcommitとrebaseを行う規律を入れた。最初は、commitのたびにrebaseしてからpushし、そのたびにビルドの検査を通すことを求めた。目的はビルドの失敗をローカルで捕まえることで、記事はこれを「早く、何度も統合する」と説明する¹。

この規律には副作用があった。チームはエージェントに、計画を立て、作業の範囲を仕様の節に合わせ、その節に紐づいた計画を作るよう指示していた。計画ファイルはリポジトリに置かれ、進捗の更新は、ほかの変更と同じcommitの規律で運ばれた。その結果、「エージェントは他のエージェントの進行を見ることができた」¹。計画ファイルがソースコードと同じ経路で運ばれたので、進捗はpushのときにしかmainに入らなかった。

エージェントは、届いた計画ファイルを調整に使った。片方のエージェントが計画ファイルの行に作業中と印を付けると、もう片方はそれを見てその行に手を出さない。行が終われば、もう片方には、作業が完了して自分が先へ進めるという知らせに加えて、「その行がどう実装されたかの注記」まで届いた¹。

計画ファイルは、依存する部品どうしの接点も運んだ。演習では、一方のエージェントが、運航を立て直す案が制約を破らないかを判定する評価器を書いていた。同じ時期に、もう一方のエージェントが、その評価器に依存する探索を書いていた。計画はこの接点を記録しており、一方の計画には「この時点で、呼び出し側を本物の検証器を呼ぶように更新する必要がある」と書かれていた。探索の側の計画には「本物の検証器が届いたら、その呼び出しを差し込む必要がある」と書かれ、両方のエージェントが互いの計画と進行を読めた¹。計画に書かれた接点の決定は、計画を通じて相手に届いた。

チームはこの働きに気づいてから、意図して使い始めた。記事は経緯を「これは完全に場当たりだった。一連の決定の偶然の産物だった。私たちはそれが起きるのを見た。そして使い始めた」と書く¹。たとえばチームは、ある部品を担当するエージェントに、計画ファイルとリポジトリを見張り、別の部品の作業が届いたら統合を始めるよう指示した。エージェントはそのとおりに動いた。

著者は、この形に既存の名前があると書く。blackboard（黒板）と呼ばれる設計の型で、黒板は「自律したエージェントが独立に読み書きできる共有メモリ」である¹。著者は、チームが意図せず、エージェントにリポジトリを黒板として使うよう促していたと書く¹。

pushを減らすと、CIの負荷と一緒に進捗の届く回数も減った

チームはその後、CIの負荷を下げるためにpushを減らした。記事は「頻繁なcommitが私たちのCIパイプラインを圧迫していた。私たちは、まとまりのある変更が完了したときにだけpushする方式へ切り替えた」と書き、結果を「これがエージェントから、進行についての継続的な更新の流れを奪った」と書く¹。

計画ファイルがソースコードと同じpushで運ばれるかぎり、pushを減らせば、CIが走る回数と一緒に進捗が届く回数も減る。ただし原典は、pushの回数も、まとまりの大きさも、切り替えの後に作業の重複が起きたかも書いていない。

著者は、進捗の流れが途切れた問題について、解決の方向性も示している。「この通信路はソース管理から独立して置かれるべきだと私は考える」¹。記録を運ぶ経路をpushと別にすれば、進捗が届く回数はpushの回数で決まらなくなり、pushを減らしても進捗は届き続ける。これは著者の考えであり、演習で試した結果ではない。

著者は観察の限界も同じ記事に書く。演習で起きたことは偶然で、意図した行為ではなく、完全に構造化されてもおらず、黒板の重要な部分をいくつか欠いていた。さらに「同じことをもう一度、確実にエージェントへ促せる自信はない」とも書く¹。発端になった一つのプロンプトは特定できているが、それで同じ結果を再現できる保証はない。

共有の記録を初めから設計するツールが出ている

著者は、共有の記録を専用のツールとして作り始めている。「Talwrnと呼んでいるプロジェクトに取りかかった」「これはエージェント的なエンジニアリングのための黒板を目指している」¹。最初の目標は、Talwrn自身の開発にTalwrnを使える段階に達することだ。

ツールの側では、Claude Codeが実験的な機能としてagent teamsを備えている。既定では無効で、有効にすると複数のClaude Codeのセッションが共有のタスク一覧を通して作業を分ける。タスクは未着手・作業中・完了の三つの状態を持ち、複数の担当が同じタスクを同時に取ろうとしたときの競合はファイルロックで防ぐ。一覧はホームディレクトリ下のローカルに置かれ、アップロードされない²。演習で計画ファイルの行に付いた作業中の印と同じ働きを、ソース管理の外にあるタスク一覧が担う形である。タスク一覧はpushで運ばれないので、タスクの状態が届く回数はpushの回数で決まらない。ただし文書は限界として、チームは統括役のセッションに属していて別のセッションとは共有できないことと、チームメイトが完了の印を付け忘れて後続のタスクが止まることがあることを挙げている²。

エージェントどうしを調整する形は、共有の記録に限らない。agent teamsは共有のタスク一覧のほかに、統括役のセッションによる割り当てと、チームメイトどうしの直接のメッセージも持つ。文書自身も、順を追う作業や同じファイルの編集、依存の多い作業には、単一のセッションかサブエージェントのほうが効くと書く²。

計画ファイルの行と印に近いものを、指示で意図して置いた設計もある。Anthropicは2025年11月26日、Claude Agent SDKで作ったエージェントを長時間働かせるための指示とファイルの構成を、自社のengineeringブログで解説した。この構成の記録は三つで、機能一覧のファイル、進捗ノートのファイル、gitのコミット履歴である。このうちgitのコミット履歴はソース管理の中にある。機能一覧は実装すべき機能を並べたもので、解説が挙げるclaude.aiの複製では200を超え、どの機能も初めは未合格と印を付けられる。後のセッションは、各機能の合格の欄だけを書き換えるよう指示される。セッションは進捗ノートとgitのコミットログを読んだあと、機能一覧から優先度の最も高い未完了の機能を一つ選んで取りかかり、gitのコミットと進捗の更新を書いて終える³。

ただし、この構成が記録を渡す相手は、同時に動く別のエージェントではない。解説記事によると、長時間動くエージェントは区切られたセッションで働き、新しいセッションは前のセッションの記憶を持たずに始まる。進捗ノートとコミット履歴は、前のセッションから次のセッションへコンテキストを渡す。解説記事は、複数エージェントの構成のほうが良いかを、今後の課題として未決のままにしている³。

計画ファイルに書かれない決定と費用は、記録の置き方では解けない

Devinの開発元Cognitionは、複数のエージェントを協働させる構成そのものを批判している。同社のWalden Yanは、2025年6月12日公開の記事で原則を二つ挙げる。原則1は「コンテキストを共有せよ。個々のメッセージだけでなく、エージェントの完全な軌跡を共有せよ」、原則2は「行動は暗黙の決定を運び、食い違う決定は悪い結果を運ぶ」である。Yanは、これらに従わない構成は既定で除外すべきだと書く。2025年時点の評価は「協働する複数のエージェントを走らせても、脆いシステムが生まれるだけである。決定があまりに分散し、エージェント間でコンテキストを十分に共有できない」である⁴。

計画ファイルは原則1に部分的に答える。計画ファイルの行と実装の注記は、個々のメッセージより広いコンテキストを渡す。ただし渡すのは軌跡（エージェントが行った操作の履歴）の全体ではない。計画ファイルが届けるのは、そこに書かれた内容だけである。評価器と探索の接点のように、計画に書かれた決定は相手に届く。届かないのは、計画に書かれなかった決定である。同じ行を読んだエージェントがそれぞれ別の暗黙の決定を下すことは、共有の記録があっても止まらない。

Cognitionは、2025年時点の評価と同じ段に、見通しも添えている。一つのエージェントが順に作業する構成を、人と通じ合うのにさらに長けたものにしていけば、エージェント間のコンテキストの受け渡しも付いてくる、という見通しである⁴。

ここまでの議論は、費用を数えていない。費用の数値は、Anthropicが自社の複数エージェントの研究システムについて書いている。その記事は、複数エージェントの構成が「チャットの約15倍のトークンを使う」と書く。この倍率は、統括役のエージェントが調べものを分けて子のエージェントに並列に走らせる研究システムで測った値で、共有の記録を読み合う構成の費用を測ったものではない。共有のタスク一覧で分けるagent teamsについては、文書自身が、単一のセッションよりトークンを大幅に多く使い、動いているチームメイトの数に応じて増えると書く。調べもの、レビュー、新しい機能の作業では、増えた分は通常見合うとも書く²。研究システムの記事は適用範囲も限定し、すべてのエージェントが同じコンテキストを共有する必要がある領域や、依存の多い領域は、今日の複数エージェントのシステムに向かないとする。「コーディングのタスクの多くは、研究に比べて本当に並列化できる部分が少なく、LLMエージェントは他のエージェントへの調整や委任を、リアルタイムではまだ得意としない」とも書く⁵。この限界はリアルタイムの調整についての記述で、計画ファイルのような書き置きを介した調整にどこまで及ぶかは、原典に書かれていない。

決定の食い違いと費用は、少なくとも当面、記録の置き方を変えても解けない。決定の食い違いは作り手の側が2025年6月時点の限界として書き、費用の増加は、共有のタスク一覧をソース管理の外に置いたagent teamsの文書も書いている。共有の記録を用意しても、タスクが分解できるかと、エージェントを増やす費用を払えるかは、人が判断しなければならない。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。