エージェント間の調整を、4日間の演習ではgitの規律が担った

Giles Edwards-Alexander, “An Accidental Blackboard”, martinfowler.com 連載「Exploring Gen AI」, 2026年9月2日公開。「今週、Thoughtworks Europe 全体で、私たちは10人の技術者を集め、バルセロナのオフィスの一室に入れた」(“This week, across Thoughtworks Europe, we took 10 engineers and put them in one room in our Barcelona office.”)、「狙いは、エージェント的なエンジニアリングに本気で寄りかかったら、どこまで速く、どこまで遠くへ行けるかを見ることだった」(“The goal was to see how far and how fast we could go if we really leant into agentic engineering.”)、「私たちは4日で一つを作り上げた」(“We managed to build one in four days.”)、「多数のエージェントが一つのリポジトリで働いたことで、ビルドのパイプラインが苦しんだ。これに対処するため、私たちは規律を導入した。エージェントはmainから継続的にcommitとrebaseを行うこと」(“With lot of agents working in one repo, build pipelines suffered. To deal with this we introduced a discipline: our agents were to continually commit and rebase from main.”)、「最初は、commitの後にrebaseし、それからpushすることを、ビルドの検査と統制を一通り効かせたうえで求めた」(“At first, we required a rebase after commit and to then push, with all of the build checks and controls in place.”)、「私たちがこの変更を入れたのは、ビルドの失敗をローカルで捕まえるためだった。早く、何度も統合する。しかし、副作用があった」(“We introduced this change to catch build failures locally: integrate early and often. But, there was a side-effect.”)、「エージェントは他のエージェントの進行を見ることができた」(“Agents were able to see other agents’ progress.”)、「一方のエージェントは、たとえば評価器に取り組んでいた」(“So, one agent was, say, working on the evaluator”)、「探索の部品は評価器に依存する」(“The search component depends on the evaluator.”)、「計画は、これらの統合点を記録していた。一方の計画は、この時点で呼び出し側を本物の検証器を呼ぶように更新する必要がある、と書いていた。探索の側では、この時点で本物の検証器が届いたらその呼び出しを差し込む必要がある、と書いていた。両方のエージェントが、それぞれの計画と進行を見ることができた」(“The plans recorded these integration points. One plan said at this point I’m going to need to update the callers to call the real verifier. And on the search side, it said, at this point I need to insert the call to the real verifier when it arrives. Both agents could see each plan, and the progress.”)、「一方のエージェントが計画の行を作業中と印を付け、もう一方のエージェントはそれを見てその行には取り組まない」(“One agent would mark a line of the plan as in progress, the other agent would see that and not work on that line.”)、「作業が完了し、それゆえ先へ進むことを許されたことだけでなく、その行がどう実装されたかの注記も直接届けられる」(“not only that the work was complete and thus it was released to proceed, but would also be directly delivered notes on how the line had been implemented”)、「これは完全に場当たりだった。一連の決定の偶然の産物だった。私たちはそれが起きるのを見た。そして使い始めた」(“This was entirely ad hoc. It was an accident of a series of decisions. We saw it happen. And then started to use it.”)、「黒板あるいはタプル空間は、自律したエージェントが独立に読み書きできる共有メモリである。彼らは最小限の構造を持つタプルを読み書きし、そこに望むだけ追加のフィールドを足す。スキーマはない」(“A blackboard or tuple space is a shared memory that autonomous agents can read and write from independently. They read and write tuples with a certain minimum structure, and then as many extra fields as you want: no schema.”)、「これは自律した問題解決者を単一の目標へ向けて調整するのに、とても有効な技法である」(“It’s a very effective technique for coordinating autonomous problem solvers towards a single goal.”)、「これは以前、1980年のHearsay-IIシステムの開発で発見されていた。それはその後、1986年にGelernterらによって、より形式的なタプル空間の概念へ発展させられた」(“This had previously been discovered in the development of the Hearsay-II system in 1980. It had been subsequently been developed into the more formal tuple space concept by Gelernter et al. in 1986.”)、「しかしそれは偶然だった。意図した行為ではなかった。完全に構造化されてもいなかった。黒板がどう働くかの重要な部分をいくつか欠いていた」(“But it was an accident. It wasn’t an intentional act. It wasn’t fully structured. It was missing some of the key parts of how blackboards operate.”)、「私たちのエージェントを、もう一度確実にそれへ促せる自信はない」(“I’m not convinced I would be able to reliably prompt our agents into doing it again.”)、「この通信路はソース管理から独立して置かれるべきだと私は考える」(“I believe you want this communication channel to be sitting independently of source control.”)、「頻繁なcommitが私たちのCIパイプラインを圧迫していた。私たちは、まとまりのある変更が完了したときにだけpushする方式へ切り替えた。これがエージェントから、進行についての継続的な更新の流れを奪った」(“The frequent commits were overloading our CI pipeline. We switched to only push when a more coherent chunk of change was complete. This deprived the agents of the continuous flow of updates on progress.”)、「Talwrnと呼んでいるプロジェクトに取りかかった」(“I’ve started working on a project I’m calling Talwrn.”)、「これはエージェント的なエンジニアリングのための黒板を目指している」(“This is aiming to be a blackboard for agentic engineering.”)と書く。演習の手順については「私たちはエージェントに、計画を立てること、作業の範囲を仕様の節に合わせること、その節に紐づいた計画を作ることを指示していた」(“We were directing the agents to plan, to scope work to sections in the spec and to create plans linked to those sections.”)、「エージェントが計画を使って調整していることに、私たちは気づいた」(“We realised that the agents were using the plans to coordinate.”)と書く。立ち位置: 著者紹介は「GilesはThoughtworksの欧州・中東・インド地域のCTOである」(“Giles is CTO for Europe, Middle East and India at Thoughtworks.”)と書く。Hearsay-IIとGelernterらのtuple spaceは、この記事が挙げる由来として引く。https://martinfowler.com/articles/exploring-gen-ai/an-accidental-blackboard.html ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²

Anthropic, “Orchestrate teams of Claude Code sessions”, Claude Codeの公式ドキュメント, 2026年9月25日取得。「agent teamsは実験的な機能で、既定では無効である」(“Agent teams are experimental and disabled by default.”)、「共有のタスク一覧がチーム全体の作業を調整する」(“The shared task list coordinates work across the team.”)、「タスクは三つの状態を持つ。未着手、作業中、完了である」(“Tasks have three states: pending, in progress, and completed.”)、「タスクの取得にはファイルロックを使い、複数のチームメイトが同じタスクを同時に取ろうとしたときの競合状態を防ぐ」(“Task claiming uses file locking to prevent race conditions when multiple teammates try to claim the same task simultaneously.”)、「タスク一覧のディレクトリはローカルに残り、アップロードされることはない」(“The task list directory persists locally and is never uploaded”)、「一つのセッションが統括役となり、作業を調整し、タスクを割り当て、結果をまとめる。チームメイトはそれぞれ自分の文脈窓で独立に働き、互いに直接やり取りする」(“One session acts as the team lead, coordinating work, assigning tasks, and synthesizing results. Teammates work independently, each in its own context window, and communicate directly with each other.”)、「順を追うタスク、同じファイルの編集、依存の多い作業には、単一のセッションかサブエージェントのほうが効果的である」(“For sequential tasks, same-file edits, or work with many dependencies, a single session or subagents are more effective.”)と書く。立ち位置: 機能を提供する側の文書である。https://code.claude.com/docs/en/agent-teams ↩ ↩²

Anthropic, “Effective harnesses for long-running agents”, engineeringブログ, 2025年11月26日公開。「長時間動くエージェントの中心的な難しさは、離散したセッションで働かなければならず、新しいセッションのそれぞれが、前に何があったかの記憶を持たずに始まることである」(“The core challenge of long-running agents is that they must work in discrete sessions, and each new session begins with no memory of what came before.”)、「交代制で働く技術者たちが担当するソフトウェアプロジェクトを想像してほしい。新しく来た技術者はそれぞれ、前の勤務で何が起きたかの記憶を持たずにやって来る」(“Imagine a software project staffed by engineers working in shifts, where each new engineer arrives with no memory of what happened on the previous shift.”)、「私たちは、Claude Agent SDKが多数の文脈窓をまたいで効果的に働けるようにするため、二重の解を作った。最初の実行で環境を整える初期化エージェントと、毎回のセッションで漸進的な進捗を作ることを任され、その間、次のセッションのために明確な成果物を残すコーディングエージェントである」(“We developed a two-fold solution to enable the Claude Agent SDK to work effectively across many context windows: an initializer agent that sets up the environment on the first run, and a coding agent that is tasked with making incremental progress in every session, while leaving clear artifacts for the next session.”)、「セッションを、進捗ノートのファイルとgitのコミットログを読むことから始める」(“Start the session by reading the progress notes file and git commit logs”)、「セッションを、gitのコミットと進捗の更新を書いて終える」(“End the session by writing a git commit and progress update.”)、「機能をpassingと印を付けるのは、注意深くテストした後だけにする」(“Only mark features as “passing” after careful testing.”)、「claude.aiの複製の例では、200を超える機能になった」(“In the claude.ai clone example, this meant over 200 features”)、「これらの機能はすべて、初めは”failing”と印を付けられた」(“These features were all initially marked as “failing"")、「コーディングエージェントには、passesの欄の状態を変えることによってのみ、このファイルを編集するよう促す」(“We prompt coding agents to edit this file only by changing the status of a passes field”)、「機能一覧のファイルを読み、まだ終わっていない機能のうち優先度の最も高いものを選んで取りかかる」(“Read the features list file and choose the highest-priority feature that’s not yet done to work on.”)、「これはgitの履歴と並べたclaude-progress.txtのファイルで実現される」(“which is accomplished with the claude-progress.txt file alongside the git history.”)と書く。脚注1は「ここでこれらを別々のエージェントと呼ぶのは、初期のユーザープロンプトが異なるからにすぎない」(“We refer to these as separate agents in this context only because they have different initial user prompts.”)と断り、今後の課題として「単一の汎用コーディングエージェントが文脈をまたいで最もよく働くのか、マルチエージェントの構成でより良い性能が得られるのかは、まだはっきりしない」(“it’s still unclear whether a single, general-purpose coding agent performs best across contexts, or if better performance can be achieved through a multi-agent architecture.”)と書く。https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents ↩ ↩²

Walden Yan（Cognition）, “Don’t Build Multi-Agents”, 2025年6月12日公開。「原則1 文脈を共有せよ。個々のメッセージだけでなく、エージェントの完全な軌跡を共有せよ」(“Principle 1 Share context, and share full agent traces, not just individual messages”)、「原則2 行動は暗黙の決定を運び、食い違う決定は悪い結果を運ぶ」(“Principle 2 Actions carry implicit decisions, and conflicting decisions carry bad results”)、「原則1と2は極めて重要で、破る価値があることは稀なので、これらに従わないエージェント構成は既定で除外すべきだと私は主張する」(“I would argue that Principles 1 & 2 are so critical, and so rarely worth violating, that you should by default rule out any agent architectures that don’t abide by them.”)、「サブエージェント1とサブエージェント2は互いが何をしているかを見られず、その結果、両者の作業は互いに食い違うものになる」(“subagent 1 and subagent 2 cannot not see what the other was doing and so their work ends up being inconsistent with each other”)、「2025年において、協働する複数のエージェントを走らせても、脆いシステムにしかならない。決定はあまりに分散したものになり、エージェント間で文脈を十分に共有できない」(“in 2025, running multiple agents in collaboration only results in fragile systems. The decision-making ends up being too dispersed and context isn’t able to be shared thoroughly enough between the agents.”)、「原則に従う最も簡単な方法は、単線で直列なエージェントを使うことだ」(“The simplest way to follow the principles is to just use a single-threaded linear agent”)と書く。同じ段は「エージェントどうしが協働する長期的な可能性には楽観的だが」(“While I’m optimistic about the long-term possibilities of agents collaborating with one another”)と始まり、「私個人は、単線のエージェントを人と通じ合うのにさらに長けたものにしていけば、それは付いてくると考えている」(“I personally think it will come for free as we make our single-threaded agents even better at communicating with humans.”)とも書く。立ち位置: 著者はDevinを開発するCognitionの側にある。https://cognition.ai/blog/dont-build-multi-agents ↩ ↩² ↩³

Anthropic, “How we built our multi-agent research system”, 2025年6月13日公開。「私たちの研究システムは、統括役と作業役の型によるマルチエージェントの構成を使う。主導するエージェントが過程を調整しながら、並列に動く専門のサブエージェントに委任する」(“Our Research system uses a multi-agent architecture with an orchestrator-worker pattern, where a lead agent coordinates the process while delegating to specialized subagents that operate in parallel.”)、「欠点がある。実際のところ、これらの構成はトークンを速く燃やす。我々のデータでは、エージェントはチャットでのやり取りの約4倍のトークンを使い、マルチエージェントのシステムはチャットの約15倍のトークンを使う」(“There is a downside: in practice, these architectures burn through tokens fast. In our data, agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats.”)、「すべてのエージェントが同じ文脈を共有することを要する領域や、エージェント間の依存が多く絡む領域は、今日のマルチエージェントのシステムには向かない」(“some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today”)、「コーディングのタスクの多くは、研究に比べて本当に並列化できる部分が少なく、LLMエージェントは他のエージェントへの調整や委任を、リアルタイムではまだ得意としない」(“most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time”)、「複数のエージェントを持つシステムは、エージェントの調整、評価、信頼性に新しい難しさを持ち込む」(“Systems with multiple agents introduce new challenges in agent coordination, evaluation, and reliability.”)と書く。https://www.anthropic.com/engineering/multi-agent-research-system ↩