Skip to Content
Docs09. ビジネス実務AI 時代のチームトポロジー
中級organizationteam-topologyplatform-teamcoe更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

AI 時代のチームトポロジー

この記事の目的

AI 活用を組織のどこに置くか(集中・分散・プラットフォーム)を、規模と成熟度に応じて設計できるようになります。役割の定義・配置の類型と移行順序・プラットフォームチームの責務・兼任と専任の判断を、組織設計の判断として持ち帰れる状態を目指します。

対象読者

  • AI 活用を組織にどう配置するかを設計する立場のエンジニアリング責任者・CTO・組織設計担当
  • 「各チームが勝手に AI を使い始めた」状態を、意図した構造へ整えたい人

前提知識

本文

概要: AI 活用を組織のどこに置くか

AI 活用が広がると、「誰が・どこで・何に責任を持つか」を組織として決める必要が出てきます。放っておくと各チームがばらばらに使い始め、品質・コスト・セキュリティのばらつきが生じます。本記事は、AI 活用を組織のどこに置くか——集中させるか、分散させるか、プラットフォームとして提供するか——を、規模と成熟度に応じて設計する視点を扱います。

個人のスキル軸は スキルマップ が正本で、本記事はそれを組織図に落とす側を扱います。唯一の正解はなく、組織の規模・成熟度・目的で配置は変わります。

役割の定義(組織図に落とす)

まず、AI 活用に必要な役割を定義します。スキルマップの役割像を、組織の職掌に落とします。

配置の類型と移行順序

AI 活用の配置には、代表的な 3 つの型があります。どれを採るかは、専門人材、チームの自律性、既存基盤、統制要件で判断します。以下は本記事の設計上の分類です。

型概要向く段階
中央 CoE 型Center of Excellence(専門組織)に集約し、知見を集中導入初期・専門人材が少ない
各チーム分散型各プロダクトチームが自律的に AI を活用成熟し、素養が組織に広がった段階
プラットフォーム + 利用チーム型基盤チームが共通機能を提供し、各チームが利用規模が大きく、再利用と統制を両立したい段階
  • 中央 CoE から始める: 専門人材が少ない初期は、中央に集約して知見を貯め、標準を作るのが効率的です。ただし CoE がボトルネックにならないよう注意します
  • 分散へ広げる: 素養が組織に広がると、各チームが自律的に使えるようにします。中央が全部やる形は、規模が増えると詰まります
  • プラットフォーム型が両立解: 規模が大きい組織では、共通機能を基盤チームが提供し、各チームがそれを使う形が、再利用と統制を両立します。共通需要が少ない段階では、基盤の維持負担が便益を上回る可能性もあります。
  • 移行順序を設計する: CoE で標準を作り、共通部分を基盤へ移すのは一案です。既に基盤や専門性がある組織では、プラットフォーム型や分散型から始める選択もあります。

プラットフォームチームの責務

プラットフォーム型では、基盤チームの責務設計が要になります。各チームが再発明せずに済む共通機能を提供します。

  • 共通機能を提供する: LLM ゲートウェイ・評価基盤・ガードレール・共通テンプレート・MLOps/LLMOpsの基盤を提供します。各チームがこれを使うことで、品質・コスト・セキュリティの標準が揃います
  • 統制と自由のバランス: プラットフォームは「使わせる」ためのもので、「縛る」ためのものではありません。各チームの自由を過度に奪うと、迂回(シャドー利用)を招きます。使いやすさで選ばれるプラットフォームを目指します
  • 利用チームの声を反映する: プラットフォームは利用チームの需要から作ります。基盤チームの理想だけで作ると、使われないものになります

兼任と専任の判断

役割を専任にするか兼任にするかは、規模と負荷で判断します。

  • 小規模は兼任で始める: 専任を置くほどの負荷がないうちは、既存メンバーが兼任します。役割は明確にしつつ、人は兼ねます
  • 律速になったら専任化: ある役割(評価・プラットフォームなど)が兼任では回らなくなったら、専任化を検討します。専任化のタイミングは、その役割が律速になったときです
  • 属人化を避ける: 兼任・専任いずれでも、知見が 1 人に偏らないよう、文書化と分担を設計します

外部パートナーとの分担

すべてを内製する必要はありません。外部パートナーとの分担も設計の一部です。

  • 内製と外注の線引き: コアの差別化に関わる部分は内製し、汎用的な部分は外部を使う、という線引きをします
  • 知見の残し方: 外部に任せる場合も、知見が組織に残る形(文書・引き継ぎ)を設計します。丸投げで知見が残らないと、依存が固定化します

実務での注意点

アンチパターン

  • 各チームが無統制にばらばらに使う → 品質・コスト・セキュリティがばらつく → 配置の型を意図的に選び、標準を作る
  • 中央 CoE に集約したまま規模を増やす → CoE がボトルネックになる → 素養が広がったら分散・プラットフォーム型へ移行する
  • 需要や既存能力を確認せず基盤を作る → 利用されない基盤ができる → 需要・専門性・統制要件に応じて開始形態と移行条件を選ぶ
  • プラットフォームで各チームを過度に縛る → 迂回(シャドー利用)を招く → 使いやすさで選ばれる基盤にし、利用チームの声を反映する
  • 役割を肩書きで固定する → 規模に合わない → 役割を責任として定義し、兼任・専任を負荷で判断する
  • 外部に丸投げして知見が残らない → 依存が固定化する → コアは内製し、外注でも知見が残る形にする

チェックリスト

  • AI 活用に必要な役割(アプリ・プラットフォーム・評価運用)を責任として定義したか
  • 配置の型(中央 CoE / 各チーム分散 / プラットフォーム + 利用)を規模・成熟度で選んだか
  • 需要・既存能力・統制要件に基づいて開始形態を選び、必要な移行条件を設計したか
  • プラットフォームを「使いやすさで選ばれる」設計にし、利用チームの声を反映したか
  • 役割の専任化を、律速になったタイミングで判断する方針にしたか
  • 内製と外注の線引きをし、外注でも知見が残る形にしたか

関連トピック

参考資料

  • CNCF Platforms White Paper  — プラットフォームと利用チームの分担、需要起点の設計。本文の AI 向け役割分類は独自整理で、組織の普遍的な移行順序ではありません(アクセス日: 2026-09-10)

TODO・未確認事項

なし

AI 前提の開発プロセス再設計プロンプト・エージェント資産の組織共有