> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/ja/2026/w33-five-steps-toward-the-future-work-paradigm-seen-through-agent-teams.md). # W33-Agent Teamから見る、これからの働き方の5つの段階 最近、Claude Codeの責任者Boris Chernyが、[Steps of AI Adoption](https://docs.google.com/document/d/1R91ayvj7uvlxgNi--__2-Bf3w8x5r1nF-xIBN7ds8Ns/edit)という表を公開した。 [元の投稿](https://x.com/bcherny/status/2077929379661844559)では、繰り返し見られる現象に触れている。チームの1人がClaudeによって桁違いの生産性を得ても、組織のほかの人たちは追いついていないというものだ。 これは、最近の私の実感に近い。AIが生む差は、もはやツールの習熟度だけではない。人によって、まったく異なる働き方をしている。 BorisはAIの導入をL0からL4までの5段階に分けた。より正確には、5つの状態と4回の移行である。私はこれを、これからの働き方を示す5つの段階として捉えたい。 ## 5つの段階 | 段階 | 人の役割 | 働き方 | 主なボトルネック | | ---------- | --------- | ------------------------------------------- | ----------- | | L0 制約下 | 傍観者 | AIを使いたいが、十分な能力を持つモデルを仕事に使えない | アクセス権限 | | L1 補助 | ペアの相手 | 1つのAgentと組み、Agentが実行し、人が逐次確認する | 人の注意力 | | L2 並列 | オーケストレーター | 複数のAgentを同時に編成し、Agentが実行と自己確認を行い、人が結果を受け入れる | レビュー能力 | | L3 監督下の自律 | 管理者を管理する人 | 定期タスクやイベントが自発的に仕事を起動し、人が例外を承認する | 信頼と意思決定の処理量 | | L4 AIネイティブ | 意図を定義する人 | 数百から数千のAgentが目標に沿って動き、人が異常を管理する | 価値判断とガバナンス | Borisの表では、Agentの数は0、1、10、100、そして1000以上となっている。この数字は規模感を示すもので、昇格条件ではない。本当に重要なのは、人の役割の変化だ。 L1では、人が依然としてすべてのタスクを操縦している。Agentは、とても速い助手に近い。 L2になると、人は分担を設計し、コンテキストを制御し、受け入れ基準を定める。複数のAgentが作業を並列に進め、人の注意は主に結果と例外に向けられる。 L3では、さらに一歩進む。すべてのタスクを、人が1つずつ起こす必要はなくなる。システムがイベントを監視し、計画に沿って動き、問題を見つけて自ら仕事を作る。人が管理するのは個々のAgentではなく、Agentで構成された仕事のシステムになる。 ## Agentが複数いても、Agent Teamとは限らない これまで私たちは、単独のAgentをどう強くするか、どうすればもっと長く複雑なタスクを完遂できるかを考えてきた。単独のAgentの能力には限界があるため、複数のAgentを同時に使う人が増えている。 Agentが増えると、新しい問題も生まれる。個々のAgentの能力だけが制約ではなくなり、組織の仕方が全体の上限を決め始める。 仕事のたびに人が入口を選び、背景を整理し、Contextを運び、あるAgentの成果を別のAgentに渡す必要があるなら、それらは本質的には独立したツールの集まりにすぎない。システム内で唯一のRouterは依然として人であり、事実上のボトルネックでもある。 私が考えるAgent Teamには、3つの特徴がある。 第一に、各Agentが自分のDomainを継続して担当する。何を処理すべきか、境界はどこか、何が自分の担当外かを理解している。 第二に、協働の責任の一部が人からAgentへ移る。明確な責任関係の中で、振り分け、引き継ぎ、結果の返却を行い、人がすべての手順をつなぐ必要はなくなる。 第三に、人はTeamに残る。ただし、立ち位置が変わる。方向性、事実、選択、Review、承認が必要な場面で戻り、実行過程のすべてを見張ることはなくなる。 しかし、人が各工程に関与しなくなると、すぐに別の問題が生まれる。このTeamが実際にどう動いているのか、どうすれば分かるのか。 だからAgent Teamは、観察でき、理解でき、継続して調整できる必要がある。そうでなければ、個々のAgentを自分で動かす状態から、何をしているか見えない状態へ移っただけになる。 ## 初めてAgent Teamを実感したとき L2を最も強く体験したのは、Multicaだった。 最初にMulticaでEngineering Squadを作り、社内のコードホスティング基盤につなぐMCPを開発した。初期構成では、Claudeが方針、分解、振り分けを担当し、Codexが実装、Geminiが探索と独立した検証を担った。製品の意図、優先順位、トレードオフ、最終承認は私が持った。 この組み合わせで、初めて強くチームを感じた。目標と境界を明確に伝えると、Leaderがさらにタスクを分け、探索、実装、検証に適したAgentを選ぶ。判断が必要なことに出会ったときだけ通知が届き、私はタスクに戻って決める。 あるタスクの開始時、2つの資料でインターフェースの形式と認証方式の説明が食い違っていた。LeaderはすぐにCodexへ実装を指示せず、範囲を限定したSpikeを先に行わせた。答えるのは数個の事実上の疑問だけとし、実際のリクエストを証拠にすること、MCPを実装しないことを明示した。数分の探索で、誤った実装を丸ごと作る事態を避けられた。 その後の検証でも、Agent Teamの価値が明らかになった。ある報告では、無効なTokenで401が返ったことを、ある認証方式が存在しない証拠としていた。結論は偶然正しかったが、推論は成立していなかった。別の検証では全テストが通ったものの、実際のfixtureは空配列が1つだけで、データが存在するときのフィールド構造をまったく検証していなかった。 これらの報告は捏造ではない。正しいが、不完全だった。Leaderは別の評価目的から証拠を見直す必要がある。実装者と検証者も、同じ自己正当化のロジックを共有してはいけない。 このタスクから、いくつかの安定したルールが生まれた。範囲を限定した探索を、実装より先に行う。高リスクの変更で、作者を唯一のReviewerにしない。証拠には、何を証明し、何を証明していないかを併記する。外から見える操作、不可逆な操作、本人の信用を伴う操作は止めて人に渡す。 これがL2で得た直接の実感だ。1人が、調整コストの低いデリバリーチームを持ち始める。 ## 一度の設定から、運用モデルへ その後、Multicaの使い方を一時的な設定から保守できる運用モデルへ変え、Gitリポジトリに整理し始めた。 最も重要だったのは、4つの対象を分けることだ。 | 対象 | 担うもの | 変化の速さ | | ------------------ | -------------------------- | ----------------- | | Profession Profile | 役割の責務、判断の境界、ツールと証拠の契約 | 安定しており、バージョン管理できる | | Agent Instance | 具体的なRuntime、モデル、権限、並列数 | 交換できる | | Squad | 継続する使命、振り分けルール、メンバー関係 | 継続的な作業キューに応じて調整する | | Issue Run | 1回のタスクの目標、Context、証拠、残るリスク | タスクごとに異なる | その中核的な価値は、安定した契約と変更可能な配置を分ける点にある。 役割の責務は安定しているべきだ。Delivery Leadは継続して、分解、振り分け、対立の裁定、証拠の取りまとめを担う。Implementation Engineerは実装とテストを担う。Challengerは反例を探し、読み取り専用のReviewを行う。Explorer-Validatorは大きなコンテキストの探索、影響範囲の分析、独立した検証を担う。 具体的なRuntimeとモデルは変えられる。今日のDelivery LeadをClaudeに、Implementation EngineerをCodexに配置し、ChallengerにはGrok、Explorer-ValidatorにはAntigravity経由のGeminiを使える。将来モデルが変わっても、Instanceを交換すればよく、Teamの責任関係まで同時に書き直す必要はない。 これは、モデルを無コストで交換できるという意味ではない。Runtimeごとに、権限、ツール、セッション、失敗の仕方を再検証する必要がある。交換可能とは、組織の契約を特定のモデルブランドに縛らないという意味であり、配置後の検証を省くことではない。 ## 現在のMultica構成 執筆時点で、私はMultica上で8つのAgent Instanceと4つの常設Squadを管理している。 Squadを横断する主力の4役は、Delivery Lead、Implementation Engineer、Challenger、Explorer-Validatorである。ほかにProduct Architect、Market Researcher、Ops Engineer、Data Analystを置き、研究、アーキテクチャ、信頼性のタスクに対応している。 4つのSquadは、継続的な作業キューに沿って分けている。 | Squad | 受け入れる仕事 | 標準の流れ | | ----------------------- | -------------------------------------- | ----------------------------------------------------- | | Engineering | 日常の機能開発、リファクタリング、通常のbug、エンジニアリングの成果物 | Claudeが振り分け、Codexだけが書き込み、Geminiが検証し、必要ならGrokが反証する | | Reliability & Incident | 根本原因不明、複数モジュールにまたがる問題、再現困難な問題、本番の信頼性問題 | 複数経路で読み取り専用の証拠収集、Claudeが仮説を絞り、Codexだけが修正し、作者以外が回帰確認する | | Research & Architecture | 技術選定、製品のトレードオフ、移行、限定したSpike | Geminiが証拠収集、Grokが仮説を攻撃、Codexは範囲を限定した実験のみ行う | | Frontend Experience | ユーザーフロー、見た目、レスポンシブ、アクセシビリティ、ブラウザ検証 | Geminiが基準を作り、Codexが実装、Geminiが実ページで検証する | Squadはリポジトリ単位で分けず、新しいモデルが出たという理由でも増やさない。新しいリポジトリは、新たなProjectリソースにすぎない。担当者が明らかな仕事は、該当Agentへ直接Assignする。複数の能力が必要で、Issue作成時に具体的なOwnerを決められない仕事だけをSquadへ入れる。 この構成には明確な制約もある。各タスクの現在のOwnerは1人。各WorktreeのWriterも1人。書き込むAgentの並列数は1、書き込まない役割は2まで、ローカルDaemon全体の同時実行上限は3。本番、認証情報、公開、外部送信、不可逆な操作は、常に私が承認する。 ## 毎回、必要最小限の役割だけを呼び出す Agent Teamは、毎回すべてのモデルを一緒に働かせるものと誤解されやすい。しかし、それでは通常、Context、Token、調整コストが増えるだけだ。 MulticaのSquad自体は、振り分け先を表す対象にすぎない。IssueがSquadに割り当てられると、システムはまずLeaderを起こす。LeaderがContextを読み、次に誰へ渡すかを決める。Squadが全メンバーを自動実行したり、並列数を増やしたりするわけではない。 だから私の標準ルールは、タスクを完了できる最小限の役割だけを、その都度呼び出すことだ。 範囲の明確な小さな修正は、Squadを起動せずCodexに直接渡せる。未知の大きなリポジトリやUIのタスクでは、まずGeminiに影響範囲と受け入れ基準を整理させ、その後Codexに渡す。再現しにくい障害や高リスクのDiffで初めて、Grokの対抗的なReviewを追加する。 標準では、実行メンバーを同時に2つまでしか動かさない。並列化するのは、互いに依存しない調査、同じ固定Commitに対する独立したReview、またはファイル範囲が完全に重ならないWorktreeだけだ。複数のAgentが同じ状態を同時に変更すると、一見速くても、最後には衝突や手戻りになることが多い。 Agentの数はTeamの成熟度ではない。適切な時点で適切な役割を起こせるかどうかが、編成の能力である。 ## DoDはAgent間のインターフェース Agent同士が直接協働できても、「続きをやって」とだけ言えばよいわけではない。 私は委派のたびに、4つの項目を明記するよう求めている。 ``` outcome: 最终可观察结果 evidence: 证明结果的测试、命令、截图、数据或链接 verification: 由谁、用什么方式验收 max_rounds: 最多返工轮数，默认 2 ``` これがDefinition of Doneだ。結果を受け入れる前に満たすべき、証拠の契約を定める。 Implementation Engineerはコードだけでなく、変更範囲、Commit、テストコマンド、生の結果も返す。独立したReviewerが読むのは、目標、Diff、テストであり、作者の完了宣言を証拠としては受け入れない。Leaderは最後に、実際の結果、未検証の項目、残るリスク、人が判断すべき事項を挙げる。 `max_rounds`も同じくらい重要だ。Agentは互いにMentionできるが、協働をいつ終えるべきかまでは、システムは私に代わって判断できない。2回やり直しても証拠の食い違いが残るなら、Teamはループを止め、対立点を人に渡さなければならない。 MulticaでTaskが `completed` と表示されても、それは今回のAgent Runが正常に終わったことしか意味しない。Issueの目標達成を示すものではない。Reviewへ進めるかを決めるのは、DoDと証拠だ。この区別によって、Agentの実行状態と仕事の完了状態が切り離される。 ## Agent Teamにも設定のエンジニアリングが必要 役割のPromptがどれほどよく書かれていても、実環境でTeamが動く証明にはならない。 私はGitリポジトリを設定の正本にしている。`config/agents/` に役割の契約、`config/squad-*.md` に振り分けルール、`config/topology.json` にAgent、Runtime、権限、並列数、Squadのトポロジーを保存する。Multica上のオブジェクトは、この宣言を実行に移したコピーにすぎない。 同期ツールは、標準では変更計画を出力するだけだ。人が確認してから適用し、もう一度実行した結果が必ず `No changes.` になることを求める。管理対象外のオブジェクトは報告だけにとどめ、自動削除しない。Workspace ID、Agent ID、Token、Webhook、ローカルのパスは、すべてリポジトリ外に置く。 この仕組みが解決するのは、設定のドリフトだ。役割や振り分けが変わればDiffを確認し、Reviewし、稼働中の状態を期待する状態と再照合できる。 実際の接続作業からも、Agent Teamは数個のPromptだけではないと分かった。LeaderはMulticaの制御系を操作する必要があるが、プロジェクトのファイルを書いてはならない。Grokには読み取り専用のReviewが必要だが、過大なネットワーク権限や書き込み能力を継承させてはならない。デスクトップのRuntimeは、プロキシ、サンドボックス、コマンド引数、ローカル環境の影響も受ける。 問題が順に明らかになり、私は制御系への直接接続、サンドボックスの境界、CLIのサブコマンド照合を続けて修正した。設定に「許可」と書いてあっても、実行環境が正常とは限らない。重要な役割には、それぞれ実際の許可・拒否のスモークテストが必要だ。 ## Agent Teamから、5つの段階を見直す Agent Teamの視点から見ると、これからの働き方の5つの段階は、振り分け、協働、検証の責任が人からシステムへ少しずつ移る過程である。 | 段階 | Agentの組織の仕方 | 人の主な仕事 | | -- | ------------------------------ | -------------------------- | | L0 | Agentを実際の仕事に入れられない | 従来の手順を使い続ける | | L1 | 複数の独立したツールで、人だけがRouter | Contextを逐次渡し、すべての結果を確認する | | L2 | 役割とSquadが常設され、Leaderが最小チームを選ぶ | 目標とDoDを定義し、証拠を検証し、重要な選択を行う | | L3 | 予定やイベントがAgent Teamを自発的に起動する | 例外、権限、予算、停止条件を管理する | | L4 | 複数のTeamが意図に沿って動き、組織構成を動的に調整できる | 方向、価値、委ねられない境界を決める | 私は現在、L2とL3の間にいる。今のMultica構成は、役割、振り分け、証拠、可観測性の問題を解決したが、大半のタスクは依然として私が自分で作っている。 L3での重要な変化は、起動する権限だ。Multicaの[Autopilot](https://multica.ai/docs/autopilots)は、定期タスクやWebhookイベントからIssueを自動作成し、AgentやSquadに渡せる。以前、[「BuilderのMacにもSweeperが必要だ」](https://weekly-essay.mikey.wang/ja/2026/w32-a-builders-mac-also-needs-a-sweeper)で、毎日のSkills管理と毎週のMac環境点検のRoutinesについて書いた。この種の仕事は、L3に近い。 ただし、起動する権限を検証能力より先に進めてはいけない。DoD、証拠、権限、停止条件、観察可能な記録がなければ、より多くのAgentを自動で起こしても、誤りを早く発生させ、見つけにくくするだけになる。 チーム全体はまだL1が中心で、大半の人はL1からL2へ移る途中にいる。Agentはすでに使える。次は、役割、振り分け、検証、権限を、共通の仕事のシステムにする段階だ。