「メンバー全員がChatGPTもCopilotも使っているのに、チームとしてはなぜか速くなっていない」——2026年に入ってから、現場のPMやマネージャーから一番よく聞くようになった悩みがこれです。
要件整理はAさんがChatGPTでやり、議事録はBさんがGeminiで作り、コード補完はCさんがCopilotで動かしている。一人ひとりは確かに楽になっているのに、ノウハウは個人のチャット履歴に閉じ込められたまま、チーム全体としては前と同じ速度で走っている。
Atlassianは2025年から「AI is a team sport（AIはチーム競技だ）」という言い方で、AI活用の主戦場が個人効率化からチーム協働基盤へ移ったと繰り返し打ち出しています。本記事では、その論を受託・SES現場の文脈に置き直し、情報・判断・タスクの3層でチームのAIを共通基盤として設計する考え方を整理します。
なぜ「個人がAIを使う」だけではチームは速くならないのか
個人レベルのAI活用が進んでも、チーム全体のスループットが上がらないのには、はっきりとした構造的な理由があります。
知識が個人のチャット履歴に閉じ込められる
メンバーがそれぞれ別の生成AIを使っていると、調査した内容、整理した要件、検討した選択肢のすべてが個人のチャット履歴に残ります。後から別のメンバーが同じテーマに取り組むとき、その履歴は参照できません。
結果として、似たような検討を別の人がもう一度AIにやらせる、という二重作業が静かに増えていきます。AIが速い分、再生産のコストが見えにくくなっているのが、むしろ厄介な点です。
判断基準が個人最適化される
AIに「この設計、どう思う？」と聞くと、それなりに筋の通った答えが返ってきます。問題は、そのプロンプトに含まれる前提（顧客名、契約形態、品質基準、過去の経緯）が人によってバラバラだということです。
同じ案件の同じ論点でも、PMが投げるプロンプトとリーダーが投げるプロンプトでは、AIの返答が微妙にズレます。気づかないうちに、判断の根拠がチーム内で食い違っていく状態が生まれます。
タスクの依頼形式が個人芸になる
AIへのタスク依頼（プロンプト）を上手く書けるメンバーと、そうでないメンバーの差は、想像以上に大きく開いています。上手い人は要件定義書の下書きを30分で出し、不慣れな人は同じ作業に半日かける。チームとして見ると、一番速い人と一番遅い人の差が、AI導入前より広がっているケースが珍しくありません。
属人化したプロンプトは、退職や異動と一緒に消えます。これは技術的負債と同じ構造で、しかも目に見えにくい分だけ厄介です。
チーム協働基盤としてのAI｜3層モデルで設計する
ここからが本題です。チームでAIを共通基盤として使うなら、情報・判断・タスクの3層に分けて設計するのが扱いやすい、というのが現場で何度も検証してきた結論です。
第1層：情報層 — 「何を見せるか」を共通化する
情報層は、AIに渡す前提情報を共通化する層です。具体的には次のようなものを指します。
- 案件の背景・契約形態・品質基準
- 顧客固有の用語集・略語集
- 過去の決定事項とその理由
- 進行中のリスクと未決着の論点
これらをチームの共有スペース（Notion、Confluence、リポジトリのCLAUDE.md など）に集約し、誰がAIに質問しても同じ前提が読み込まれる状態を作ります。
ポイントは、個人のチャット履歴に閉じている情報を、チームの参照可能なドキュメントに引き上げることです。最初は地味な作業ですが、ここが整わないと2層目以降がすべて崩れます。
すでに Claude Codeに同じ前提を毎回書くのをやめる｜CLAUDE.mdで渡すプロジェクトメモリの設計 で触れた「プロジェクトメモリ」の発想は、この情報層をチーム単位に拡張したものと考えると整理しやすくなります。
第2層：判断層 — 「何を基準に決めるか」を共通化する
判断層は、AIに判断の型を共有する層です。情報層に前提が揃っても、それをどう評価するかの軸がバラバラだと、AIの返答もバラバラになります。
たとえば次のような判断軸を、チームで明文化します。
- 仕様変更を受けるか断るかの判断軸（コスト・品質・関係性）
- リスクを上申するか自部署で吸収するかの線引き
- 顧客に出す前に通すべきレビュー観点
- 撤退判断・延期判断のしきい値
これらをチェックリストやテンプレート、サブエージェントの指示書として整備し、AIに「この案件のこの論点を、この基準で評価して」と頼める状態にします。
判断軸が揃うと、AIの出力が「個人の好み」ではなく「チームの方針」を反映するようになります。これは 2026年のPMは作業管理者ではなく判断の統合役になる｜5つの判断軸の見取り図 で論じた、PMが「判断の統合役」になるという議論を、チーム単位の運用に落とし込む作業でもあります。
第3層：タスク層 — 「どう動かすか」を共通化する
タスク層は、AIに実際の作業を任せる層です。情報と判断が揃って初めて、ここがチームの資産になります。
具体的には次のような形で標準化します。
- 議事録要約・WBS下書き・テスト観点抽出などの定型タスクをプロンプトテンプレートで配布する
- 要件レビュー・コードレビュー・障害一次切り分けをサブエージェントとして共有する
- レビュー結果の出力フォーマットを揃え、PR・チケットに貼り付けやすくする
ここで効いてくるのが、Slash CommandsやSKILL.md、サブエージェント定義といった**「タスクの形をファイルに固める」**仕組みです。属人化したプロンプトをチームの資産に変える具体的な手順は、Slash Commandsを組織知に変える運用｜Claude Codeの便利コマンドをチームに配る手順 でも詳しく扱っています。
3層モデルを現場に落とすときの順序
3層を一度に整えようとすると、ほぼ確実に頓挫します。現場では次の順序で進めるのが現実的です。
ステップ1：情報層の「最低限の共有スペース」を1つ決める
まずチームで1つの共有ドキュメントを決めます。Notionでも、リポジトリ直下のCLAUDE.mdでも構いません。重要なのは、「AIに前提を渡すときは、まずここを更新してから使う」というルールを徹底することです。
最初の2週間は、情報層を整える作業そのものに時間が取られます。ここを乗り越えないと先に進めないので、PMはこの立ち上げコストを意識的に許容する必要があります。
ステップ2：判断軸を3つだけ言語化する
判断層は欲張らず、チームで一番揉めている論点を3つだけ選んで言語化します。仕様変更の受け入れ基準、レビューで止める観点、リリース判定の最低ライン、といった粒度で十分です。
3つで運用が安定したら、少しずつ増やしていきます。最初から10個書いても誰も使わない、というのが何度も繰り返してきた失敗パターンです。
ステップ3：定型タスクを3つだけテンプレート化する
タスク層も同じく、頻度の高いタスクを3つだけ選んでテンプレート化します。議事録要約、WBS下書き、テスト観点抽出あたりは、ほとんどの受託・SES現場で共通して効きます。
テンプレートはチームの共有リポジトリやSlash Commandsとして配布し、**「個人が編み出したプロンプトを、チームに戻す動線」**を作ります。
3層モデルが機能しているチームの兆候
設計がうまく回り始めると、現場には次のような変化が出てきます。
- 新しいメンバーがアサインされても、AIに同じ前提を読み込ませるだけで戦力化が早い
- 「Aさんに聞かないと判断できない」が減り、判断の根拠がドキュメントとAI上で再現できる
- プロンプトの上手い・下手による差が縮まり、チーム全体の底が上がる
- AIが出した一次案を、PMが最終承認の1ラインだけで確定させられる場面が増える
逆に、ここまで来ても「AI生成物をそのまま顧客に渡してよいか」という最終承認の責任は、依然としてPMの仕事として残ります。この線引きは AI生成物をそのまま顧客に渡してはいけない｜PMが残すべき4つの承認ライン で詳しく整理しているので、3層モデルとあわせて確認してください。
まとめ｜AIをチーム競技として設計するPMへ
個人がAIを使う段階から、チームの情報・判断・タスクを共通基盤に流す段階へ。この移行は、ツールの問題ではなく設計の問題です。
今日からPMが手をつけられるのは、次の3つです。
- 情報層の共有スペースを1つに決め、AIに渡す前提をそこに集約する
- チームで揉めている判断論点を3つ言語化し、AIに評価軸として渡せるようにする
- 頻度の高い定型タスクを3つ選び、プロンプトテンプレートとしてチームに配布する
ここまで設計できると、AIは「速い個人」を量産する道具ではなく、チームの判断と運用を底上げする共通基盤になります。これが、2026年のPMに求められているAI活用の新しい標準です。
チームのAI協働基盤を本格的に設計したい方へ
テックエイドでは、AIを業務フローと組織運用に組み込むための実践講座を提供しています。
- AIX-102 / AIX-103：生成AIを業務に運用として組み込むための、情報設計・判断設計・運用設計の実務
- PJM-102：受託・SES現場で、チーム運用と進行管理にAIを組み込むPM実務
3層モデルを「自分のチームで動く形」に落とし込みたい方は、まずは関連講座の詳細をご確認ください。