人間とエージェントが共に働くチームのためのチームトポロジー：エージェントは実際にどこに収まるのか

著者: Victor Hoang · 更新日: 2026年9月22日

チームトポロジーは、Matthew SkeltonとManuel Paisが提唱するフレームワークで、4つのタイプ（ストリームアラインド、イネーブリング、コンプリケイテッド・サブシステム、プラットフォーム）を軸にチームを編成し、調整のオーバーヘッドを最小限に抑えて仕事が流れるようにするものです。仕事の一部をAIエージェントが担うチームに適用しても、同じ4つのタイプは通用します。ただし、変わる点が2つあります。認知負荷に新しいカテゴリー（自分が生み出していない成果物を引き受けること）が加わること、そして、仕事をする「チーム」の一部が人ではなくソフトウェアであるシステムにもコンウェイの法則が当てはまることです。本記事は、仕事の未来とは何かで扱う大きな変化の、構造面にあたる半分です。

重要なポイント

• チームトポロジーは、4つの基本的なチームタイプを定義しています。ストリームアラインド（事業価値の流れに沿ったチーム）、イネーブリング（ストリームアラインドチームの障害克服を支援し、不足している能力を検知する）、コンプリケイテッド・サブシステム（深い専門知識や数学的知識を要する仕事を担う）、プラットフォーム（ストリームアラインドチームを加速する魅力的な社内プロダクトを提供する）です。出典：Team Topologies, "Key concepts and practices"
• Melvin Conwayの1968年の論文は、元となる命題を述べています。「システムを設計する組織は、必ず、その組織のコミュニケーション構造をコピーした構造の設計を生み出すことになる」。彼はまた、集団内で起こりうるコミュニケーション経路の数が、おおむね人数の2乗に比例して増えることも指摘しました。出典：Melvin Conway, "How Do Committees Invent?" (Datamation, 1968)
• DORAの2025年の調査では、90%の組織が少なくとも1つの社内プラットフォームを導入しており、プラットフォームの品質の高さと、AI導入から価値を引き出す組織の能力との間に直接の相関があることが確認されました。出典：Google Cloud, announcing the 2025 DORA Report
• Microsoftの2026年Work Trend Indexは、組織要因（文化、マネージャーの支援、人材施策）が、AIの成果に与える影響として測定された値で、個人要因の2倍超を占めることを確認しました。また、個人の能力と組織の準備態勢が互いを強め合う「フロンティア」人材は、調査対象のAI利用者のおよそ19%だと特定しています。出典：Microsoft WorkLab, "2026 Work Trend Index"

チームトポロジーが実際に述べていること

SkeltonとPaisは、特定の問題を解決するためにチームトポロジーを作りました。組織図は通常、仕事が実際にどう流れるかではなく報告ラインに沿って描かれ、そのずれが、遅いデプロイ、不明確な責任の所在、他の3チームの承認なしにはリリースできないチームとして表れる、という問題です。彼らの答えは、ちょうど4つのチームタイプを軸に編成し、チーム間の相互作用のパターンを偶然に任せず、意図的に設計することです。

ストリームアラインドチームは、事業価値の一部をエンドツーエンドで担い、引き継ぎを最小限にして提供できるよう編成されます。イネーブリングチームは、他のチームの能力ギャップを埋めるために、意図的かつ一時的に存在し、ギャップが埋まれば身を引きます。コンプリケイテッド・サブシステムチームは、深く狭い専門知識が本当に必要なシステムの一部（決済エンジン、レコメンデーションモデル、価格設定アルゴリズムなど）を担い、ストリームアラインドチームがそれぞれ専門家を抱える必要がないようにします。プラットフォームチームは、共有インフラ、ツール、セルフサービスの機能といった社内プロダクトを構築し、ストリームアラインドチームが同じ配管を5回も作り直すことなく素早く動けるようにします。

仕事の一部を人ではなくAIエージェントが担うチームを説明するために、この用語を変える必要はありません。足す必要があるのは、SkeltonとPaisが想定していなかった2つの問いへの明確な答えです。エージェントの仕事はこの4つのタイプの中で実際にどこに収まるのか。そして、自分で生み出していない成果物に人が責任を負うとき、認知負荷はどうなるのか。

本当の制約は、常に認知負荷だった

チームトポロジーは、チームの規模と範囲を、1つの変数の下流にあるものとして扱います。認知負荷、つまり品質と速度がともに低下する前にチームが維持できる精神的努力の総量です。無関係な5つ目の責任を押しつけられたストリームアラインドチームは、能力が高まるのではなく、5つすべてで遅く、雑になります。だからこそこのフレームワークは、広い責任ではなく、狭く境界の明確な責任をチームに求めています。

エージェントは、その予算を埋めるものを変えますが、必ずしも総量を減らすわけではありません。以前は成果物を作ることに認知負荷を費やしていたチームは、今ではその一部を、エージェントが試みられる程度にタスクを正確に指定することに、また別の一部を、正しいかどうかにかかわらず自信ありげに見える出力を検証することに費やします。実行者からオーケストレーターへは、この変化を1人の仕事のレベルで扱っています。チームのレベルでは、同じ変化が、チームの認知負荷に新しい項目を加えることを意味します。説明責任の負荷、つまりチームメイトではなくエージェントが実際に生み出した判断や成果物を引き受け続けるコストです。チームの規模を決めるときにこの項目を無視すると、紙の上では人員が少なく見えるのに、レビューされていないエージェントの出力に静かに溺れているストリームアラインドチームができあがります。

各チームタイプにおけるエージェントの位置づけ

正直な答えは、エージェントは5つ目のチームタイプを生み出さない、ということです。すでにある4つのタイプの内部構成と、相互作用の負荷が変わります。

ストリームアラインドチーム：エージェントは流れの中で働き、成果の責任は人が持ち続ける

エージェントの利用の大半が今あるのはここで、今後もこれが標準であり続けるべきです。エージェントがコード、キャンペーンのコピー、サポートの返信、最初の分析を下書きし、チームの特定の人がリリースされるものに引き続き責任を負います。チームの範囲は変わらず、変わるのはその内部の分業です。逆方向の範囲の拡大には注意してください。本来のプロダクト業務に加えて、自前のエージェント基盤（プロンプトライブラリ、評価ハーネス、ツールコネクタ）を静かに構築し保守し始めたストリームアラインドチームは、引き受けた覚えのない、際限のない2つ目の仕事を抱え込んだことになります。それは自動化ではなく拡張というパターンが意図どおりに機能している状態ですが、基盤の仕事がチームの認知予算に収まらなくなるまでの話です。

イネーブリングチーム：エージェントはスキル移転を速めるが、自動化はしない

SkeltonとPaisは、イネーブリングチームを本来一時的なものとして設計しました。特定の能力ギャップを埋めるために存在し、ギャップが埋まれば解散するか、別の役割に移ります。人間とエージェントが共に働く文脈では、これは他のストリームアラインドチームに、使えるエージェントへの指示書の書き方、評価基準の設定の仕方、もっともらしいが誤っている出力をリリース前に見つける方法を教えるチームです。陥りやすいのは、イネーブリングチームが、スキルを移転するのではなく仕事を代行する、恒久的な影のプラットフォームに静かに変わってしまうことです。それでは目的が失われ、フレームワークに照らして誰も追跡していないチームの中に、本当の認知負荷が隠れてしまいます。

コンプリケイテッド・サブシステムチーム：専門家が置き換えられることはまれで、その及ぶ範囲が広がる

コンプリケイテッド・サブシステムチームが存在するのは、システムのある部分に、深く、分散させにくい専門知識が本当に必要だからです。エージェントがそのサブシステムを丸ごと所有するのには向いていません。そのチームが存在する理由が、まさにそこでの誤りが高くつき、専門知識がなければ見つけにくいことだからです。ここでエージェントが役立つのは、及ぶ範囲を広げることです。価格設定モデルの変更について、AIが下書きした10件の初稿を専門家がレビューすることは、同じ専門家が10件すべてをゼロから手作業で作ることとは別の、しばしばより良い、希少な専門知識の使い方です。これがヒューマンインザループが意図どおりに機能している状態です。専門家は最終チェックの役目を保ち、形だけの承認印にはなりません。サブシステムチームの人数が減る、あるいはアウトプットが増えることはあっても、その責任の境界と検証の基準は動かすべきではありません。

プラットフォームチーム：社内のAIプラットフォームチームがほぼ即座に現れる理由

2つか3つを超えるストリームアラインドチームがそれぞれ独立してエージェントを使い始めると、最も急速に拡大するのがこのチームタイプです。放っておくと、各チームが同じ問題を別々に解こうとします。どのモデルを呼び出すか、認証情報とコスト上限をどう扱うか、監査のためにエージェントの動作をどう記録するか、社内のデータやツールにどう安全に接続するか、といった問題です。DORAの2025年の調査は、このパターンがAIに固有のものではないことを示しました。90%の組織が、まさにこの理由で少なくとも1つの社内プラットフォームをすでに導入しており、プラットフォームの品質は、AI導入が現実のパフォーマンス向上になるか、それとも分散した重複する取り組みにとどまるかを直接予測していました。

社内のAIプラットフォームチームは、共有のDevOpsプラットフォームチームが生まれるのと同じ理由で形成されます。配管を一度、きちんと作り、セルフサービスの機能として提供するほうが、すべてのストリームアラインドチームが自前で作るより優れているのです。通常このチームが担うのは次のものです。モデルプロバイダーへの共有接続、エージェントが5つの個別連携ではなく一貫した方法で社内のツールとデータに到達できるようにするMCPベースの相互運用レイヤー、コストと利用量のガードレール、そして「この出力は十分に良いとどうやって判断するのか」を誰もゼロから考え直さずに済むようにする、共有の評価とログの標準です。また、複数のエージェントがタスクで連携するものはすべて、このチームが担うのが自然です。単一のストリームアラインドチームが単独で所有すべきではない、共有されるリスクの高い配管だからです。Reworkもプロダクト側で同じ扱いをしています。エージェント向けのワークフローとMCPの相互運用の標準化はWork Opsの領域です。その配管は、それに触れるすべてのチームの中に重複して存在すべきではないからです。

チームの一部がソフトウェアである場合のコンウェイの法則

Conwayが1968年に行った元の観察は、人についてのものでした。システムを設計する組織は、自らのコミュニケーション構造を映した設計を生み出しがちだ、というものです。モジュール間のインターフェースが、それを作ったチーム間のインターフェースと一致するようになるからです。彼は、あまり引用されないものの同様に有用な指摘もしています。集団内で起こりうるコミュニケーション経路の数は、おおむね人数の2乗に比例して増えます。だからこそ、大規模で緩やかにしか調整されない集団は、広がりすぎた、統合の悪い設計を生み出すのです。

この論理は、エージェントが仕事の一部を担うようになっても当てはまらなくなるわけではありません。エージェントのツール接続とアクセス境界は、それ自体がインターフェースであり、構造的には2つの人間のチーム間のAPI境界と変わりません。5つのストリームアラインドチームが、それぞれ「CRMを読んでメールを下書きできるエージェント」の独自バージョンを組み上げれば、わずかに異なる5つの連携、5つの障害モード、そしてセキュリティレビューが個別に確認すべき5か所ができあがります。これは、エージェントのツールアクセスがコミュニケーション経路の代わりを務めているだけで、コンウェイの法則が予測どおりに展開している状態です。

ここでの有用な動きは、チームトポロジーがConwayの元の洞察から借りているものと同じです。逆コンウェイ戦略、つまり組織図がすでに決まった後で偶然アーキテクチャを発見するのではなく、望むシステムアーキテクチャを得るために、望む組織構造を意図的に形づくることです。エージェントが社内システムに接続する方法を一貫した監査可能な1つにしたいのなら、5つのストリームアラインドチームにそれぞれ独自に作り直させ、結果として生じた混乱を「柔軟性」と呼ぶのではなく、組織がそのインターフェースを所有する明確な境界（通常はプラットフォームチーム）を引く必要があります。

人間とエージェントの仕事のための4つのチームパターン

これらは、そのまま真似るべき処方箋ではありません。見分けのつく形であり、多くの組織は成熟段階の違いに応じて、同時に複数を運用することになります。

役に立つ診断を挙げます。あるエージェントの仕事が、現在この4つの形のどれに収まっているのかを言えないなら、それこそが実際の問題であることが多く、使っているモデルや誰かが書いたプロンプトの問題ではありません。

トポロジーが追いついていないサインを見抜く

チームの構造を見直さずにワークフローへエージェントを加えた組織では、いくつかの症状が確実に表れます。

• 静かな重複。 一度だけ提供するプラットフォームチームがないために、複数のストリームアラインドチームがそれぞれ同じエージェント機能の独自版を構築している。これは上で述べた分断されたコンウェイのパターンで、通常は最初に、エージェントが同じ顧客データベースに触れる5つの異なる方法を見つけるセキュリティレビューの指摘として表面化します。
• 見えない説明責任の負荷。 チームの人員計画が依然として「このチームはどれだけの仕事を生み出せるか」を反映したままで、エージェントの出力の検証にいま費やしている時間が考慮されていない。これはAIの生産性パラドックスのチームレベル版です。活動量は増えるのに、信頼できるスループットは、活動の指標が示唆するようには動きません。
• 去らないイネーブリングチーム。 一時的なスキル移転のはずが、他のすべてのチームの代わりにエージェントの仕事をするチームに静かに変わり、イネーブリングチームの意味が失われ、実際の範囲に照らして誰も追跡していないチームの中に、本当の人員ニーズが隠れている。
• 越えられたサブシステムの境界。 専門チームの外にいる誰かが、かつてサブシステムチームの承認を要した領域で、エージェントを使ってアウトプットを生成し始めたのに、結果に実際に誰が責任を負うのかを誰も更新していない。

適用を始める方法

順序よりも、偶然に任せず意図的に行うことのほうが重要です。

1. 現在のチームを4つのタイプに対応づける。 理想ではなく、正直に行います。ほとんどの組織は、2つか3つのストリームアラインドチームの内側で、ラベルも調整もなく、すでに非公式のプラットフォーム業務が行われていることに気づきます。
2. 説明責任の負荷がどこへ移ったかを問い、実際の人員配置と照らし合わせる。 検証の時間が増えたのに人数が変わっていないなら、そのチームの本当の認知負荷は、組織図が示すよりも高いということです。
3. プラットフォームチームを立ち上げる価値があるのはいつかを、意図的に決める。 プラットフォームの品質がAIの組織的な見返りを予測するというDORAの知見は、有用な直感的チェックです。チーム間で重複が目に見えているなら、通常はその投資が元を取れます。
4. イネーブリングチームには、始める前に終了条件を与える。 「ギャップが埋まった」とはどういう状態かを最初に定義しておけば、チームは恒久的で誰にも説明責任のない機能になるのではなく、自然に解散する時点を持てます。
5. コンプリケイテッド・サブシステムの境界を明示的に守る。 最初の下書きを何が生成したかにかかわらず、どの判断に専門チームの承認が引き続き必要かを書き出し、その境界を飛ばすことを、効率化の成果ではなくインシデントとして扱います。

これらはどれも1回限りの組織再編ではありません。Microsoft自身による「エージェントボス」の役割とフロンティア企業の捉え方は、人間とエージェントの構造を、一度描いて仕舞い込む図ではなく、継続的な運営上の問いとして扱っています。また、AI対応の文化を築くことは、それが1四半期のうちに古い習慣へ逆戻りするのを防ぐものです。人間とエージェントのチームは、この変化の規範と信頼の側面、つまり人が日々エージェントとどう仕事上の関係を築くかをすでに扱っています。本記事は同じ問題の構造面にあたる半分であり、この2つが機能するのは、各チームが独自の答えをその場で作り出すのではなく、誰かが組織設計の判断を実際に所有している場合に限られます。

エージェントが登場した後も描き直されないチーム図は、中立ではありません。重複、計上されない検証時間、不明確な責任の所在は、誰も意図的にその問いを立てようと思わないうちに、以前から存在していた構造の内側で、静かに起こり続けます。