「Copilotは導入された。でも開発現場で何に使えばいい？」という状態から、会議・要件整理・週次報告・リスク管理へつなげる考え方をまとめます。
※本記事では公開可能な一般例のみを扱い、社内会議、顧客情報、実案件の画面・データなどは掲載していません。機能や利用条件は変更されることがあるため、実利用時はMicrosoft公式ドキュメントと組織の設定を確認してください。
はじめに
Microsoft 365 Copilotというと、メール作成や文章要約を思い浮かべる方が多いかもしれません。
しかし、開発プロジェクトにおいて特に面倒なのは、「文章を書くこと」よりも、Teamsの会議、Wordの仕様書、Outlookのメール、タスク情報などに散らばった情報を集め、現在の状況を再構成することではないでしょうか。
PM・PLの仕事に置き換えると、たとえば次の作業です。
- 前回の会議で何が決まったか確認する
- 要件の確定事項と未確定事項を分ける
- 担当者や期限が抜けていないか確認する
- タスク情報から週次報告を作る
- 遅延やブロッカーを整理する
Microsoft 365 Copilotを使うときは、いきなり仕事全体をAIへ任せるのではなく、こうした「探す・まとめる・比較する・伝える」作業のプロトタイプを任せるところから始めるのがおすすめです。
この記事では、そのための具体的な使い方を紹介します。
1. まず「どの仕事に使うか」を決める
Copilot活用で最初に悩みやすいのがプロンプトです。
しかし、先に決めるべきなのはプロンプトではありません。
どの業務を短くしたいのかです。
開発プロジェクトで最初に試しやすいのは、次の3つです。
- 会議の整理
- 要件の抜け漏れ確認
- 週次報告の下書き
これらは日常的に発生し、入力となる情報と期待する出力が比較的はっきりしています。
最初から「プロジェクト管理をAI化する」と考えると範囲が広すぎます。
まずは、
会議が終わったら決定事項とTODOを整理する
くらいの小さな用途から始める方が、実務へ定着させやすくなります。
2. Microsoft 365 CopilotとGitHub Copilotを分けて考える
開発現場では、Microsoft 365 CopilotとGitHub Copilotを混同しないことも重要です。
大まかには、次のように役割を分けて考えると分かりやすくなります。
Microsoft 365 Copilot
プロジェクトの業務上の文脈を整理する仕事で利用します。
- 会議内容の整理
- 文書の要約・比較
- メールの整理
- 要件の確認
- タスクや進捗情報の整理
- 報告資料の下書き
GitHub Copilot
ソースコードに近い開発作業を支援します。
- コードの作成・補完
- コードに関する質問
- テストやデバッグの支援
- IssueやPull Requestに関連した開発作業
両者を「どちらが優れているか」で比較する必要はありません。
会議や要件で整理された内容を実装へつなぎ、実装状況を再び報告や合意形成へ戻す、と考えると自然です。
ただし、品質、セキュリティ、要件承認、リリース判断などの責任までAIへ渡すわけではありません。最終判断は人が行いましょう。
3. PM・PLで使いやすい4つの仕事
開発工程全体で見ると、Microsoft 365 Copilotを試しやすい作業は大きく4種類に整理できます。
3.1 会議を前へ進める
会議は「議事録を作ること」がゴールではありません。
本当に必要なのは、会議の結果を次の行動につなげることです。
整理したい情報は次のとおりです。
- 論点
- 決定事項
- 保留事項
- 意見が分かれている点
- 担当者
- 期限
- 依存関係
- 次回確認事項
特に「担当者」「期限」を一緒に確認するだけで、議事録がタスク管理につながりやすくなります。
3.2 要件を整える
要求一覧や議事内容から、次の候補を洗い出します。
- 重複
- 矛盾
- 曖昧な表現
- 受入条件がない要求
- 外部依存のある要求
- 決まっていない項目
AIに「正しい要求へ直して」と任せるのではなく、人に確認すべき質問を作らせることがポイントです。
3.3 進捗を伝える
タスク情報が揃っていても、報告資料を毎週作るのは意外と手間がかかります。
そこで、タスク情報などを材料として、
- 完了
- 進行中
- 遅延
- 今後のマイルストーン
- リスク
- ブロッカー
- 意思決定が必要な事項
に整理させ、週次報告のプロトタイプを作ります。
3.4 リスクを見える化する
リスク整理では、AIにリスクを断定させるより、次の3つを分ける方が有効です。
- 資料に書かれている事実
- 事実から考えられる懸念
- 判断するために不足している情報
事実と推測が混ざらないようにすることが重要です。
4. 一番おすすめなのは「会議 → 次の行動」
最初のユースケースとしておすすめなのが、会議情報の整理です。
会議前、会議中、会議後を別々の作業にせず、一つの流れとして考えます。
会議前
- 前回の決定事項
- 未完了事項
- 今回確認するテーマ
を整理します。
会議中・直後
- 何が決まったか
- 何が決まっていないか
- 誰が何をするのか
- いつまでなのか
を確認します。
会議後
整理した内容をタスクや報告資料へつなげます。
使えるプロンプト例はこちらです。
この会議を次の項目で整理してください。
- 決定事項
- 保留事項
- 担当者
- 期限
- 依存関係
- 次回確認事項
担当者または期限が明示されていない場合は「未設定」としてください。
資料や発言にない内容は推測しないでください。
ここで大切なのは、きれいな議事録を作らせることではなく、決まっていないことを発見することです。
「担当が未設定」「期限が未設定」と出てきたら、それ自体が次に確認すべき項目になります。
5. プロンプトは4要素で作る
プロンプトを難しく考える必要はありません。
実務では、次の4要素を揃えると扱いやすくなります。
① 目的
何の判断・作業に使用するのか。
次回の顧客確認事項を整理したい
② 材料・範囲
どの情報を根拠にするのか。
今回の要件会議と要求一覧だけを対象にする
③ 出力形式
最終的に使いたい形を指定します。
確定要求、候補、制約、決定事項、保留事項を表形式で整理する
④ 確認ルール
AIが勝手に補完しないための条件です。
根拠を示し、資料にない内容は「要確認」とする
全部つなげると、次のようになります。
次回の顧客確認事項を整理したいです。
今回の要件会議と要求一覧を対象に、
確定要求、候補、制約、決定事項、保留事項、担当者、期限を表形式で整理してください。
各項目の根拠を示し、資料にない内容は推測せず「要確認」としてください。
最初から完璧なプロンプトを一発で作る必要はありません。
出力を見る → 足りない条件を追加する、というやり方で十分です。
6. 要件整理では「ツッコミ役」にする
要件定義でCopilotを使う場合、仕様を勝手に作らせるより、レビュー観点を増やす用途が向いています。
たとえば、要求一覧を対象に次のように依頼します。
この要求一覧を確認し、次の観点で確認が必要な項目を表にしてください。
- 重複している要求
- 矛盾している可能性のある要求
- 曖昧な表現
- 受入条件が記載されていない要求
- 外部システムや別担当への依存がある要求
仕様の修正内容は断定せず、それぞれに確認質問を付けてください。
出力された質問をそのまま採用する必要はありません。
そこへSEや開発者自身の知識を足し、顧客へ確認する質問リストへ仕上げます。
この使い方なら、AIを「要件を決める人」にするのではなく、レビューの観点を増やす補助者として扱えます。
社内デモでは、自社サイトをCopilotに分析させ、あえてあいまいな改善要求一覧を作らせてこのプロンプトを試しました。
自社サイトを題材に使ってみると、面白い知見が得られるかもしれません。
7. 週次報告はゼロから書かない
週次報告もCopilotを使いやすい作業です。
今週のタスク情報を基に、次の内容を1ページでまとめてください。
- 完了
- 進行中
- 遅延
- 今後2週間のマイルストーン
- リスク
- ブロッカー
- 意思決定が必要な事項
情報が不足している項目は推測せず「要確認」としてください。
重要なのは、文章生成そのものより、複数のタスクを報告する観点へ再分類することです。
MicrosoftのPlannerエージェントは、Copilotからタスクやプランの作成・更新・管理に利用できます。利用可否はライセンスやテナントの管理設定にも左右されるため、自分の環境で使える機能を確認してください。
余談ですが、筆者の現場ではMS Projectしか使ったことがなく、Plannerは今回初めて触りました。
TeamsやWordのようにアプリ画面内に直接起動ボタンが常駐しているタイプと異なり、PlannerエージェントはCopilot側のエージェント一覧から明示的に選択して呼び出す導線になっています。
手軽に全体サマリを確認したいだけならPlanner画面右下のAIレポート機能、観点を指定して細かく指示出ししたいならCopilotチャットからPlannerエージェント経由でプロンプトを入力する、と使い分けるのが良さそうです。
8. Copilotの回答は「プロトタイプ」と考える
Copilotがもっともらしい文章を出しても、正しいとは限りません。
そこで、共有前に筆者が意識している確認の4観点（SVCR）で確認します。
Source
原典と一致しているか。
会議の発言、要件書、タスクなど、元情報まで戻って確認します。
Verified
固有の値を確認したか。
特に次は要チェックです。
- 人名
- 日付
- 期限
- 数値
- バージョン
- 担当者
Context
前提・例外・依存関係が抜けていないか。
たとえば「この機能は全利用者が対象」と見えても、実際には権限や契約条件などの前提があるかもしれません。
Resilient
条件や読み手が変わったときにも誤解を招かないか。
顧客向け、開発者向け、経営層向けでは必要な説明が変わります。
特に、
- 顧客への正式回答
- 要件承認
- セキュリティ判断
- リリース判定
などは、人が根拠を確認して判断します。
9. 1案件・3用途から小さく始める
導入時に、全員へ「Copilotを使ってください」とだけ伝えても、なかなか定着しません。
まず一つの案件を選び、次の3用途だけで試します。
- 会議
- 要件整理
- 週次報告
そのうえで、使えたプロンプトをテンプレート化します。
目的：
対象資料・期間：
出力形式：
必ず確認する項目：
推測してはいけない項目：
チームで効果を確認するときは、「Copilotを何回使ったか」だけではなく、業務そのものがどう変わったかを見る方が実践的です。
たとえば、
- 議事録を確定するまでの作業
- 週次報告を作る作業
- 要件レビューで発見できた未確認事項
- 後工程で発生した認識違い
など、導入前後で比較できる指標を決めます。
10. 開発現場で忘れてはいけないセキュリティ
便利だからといって、業務データを任意のAIサービスへ入力してよいわけではありません。
開発現場では、特に次の情報を扱う可能性があります。
- 顧客情報
- 顧客固有の要件
- ソースコード
- 障害情報
- アカウント情報
- 非公開の設計情報
利用するAIサービス、入力してよい情報、保存・共有ルールは、必ず自社および参画プロジェクトのルールに従ってください。
「普段個人で使っているAIだから」という理由で業務情報を入力しないことが重要です。
判断できない場合は、プロジェクト責任者や情報セキュリティ担当へ確認しましょう。
明日試せる3プロンプト
最後に、すぐ試せる形でまとめておきます。
1. 会議後
この会議を、決定事項、保留事項、担当者、期限、依存関係、次回確認事項に整理してください。
担当者または期限が不明な場合は「未設定」としてください。
資料や発言にない内容は推測しないでください。
2. 要件レビュー
要求一覧を比較し、重複、矛盾、曖昧表現、受入条件がない要求、外部依存がある要求を表にしてください。
修正内容を断定せず、それぞれに確認質問を付けてください。
3. 週次報告
今週のタスク情報を基に、完了、進行中、遅延、今後2週間のマイルストーン、リスク、ブロッカー、意思決定依頼を1ページでまとめてください。
根拠となるタスクを示し、不明な項目は「要確認」としてください。
まとめ
Microsoft 365 Copilotを開発プロジェクトで使うとき、最初からプロジェクト管理そのものをAIへ任せる必要はありません。
まず任せるのは、
探す → まとめる → 比較する → 次の行動へ変換する
という部分です。
特にPM・PLであれば、
- 会議から決定事項と未決事項を取り出す
- 要件一覧から確認質問を作る
- タスクから週次報告のプロトタイプを作る
- リスク整理で事実と仮説を分ける
という使い方から始められます。
そして、Copilotの出力は完成品ではなくプロトタイプとして扱い、出典元の確認と最終判断は人が行います。
Microsoft 365 Copilotは「仕事を完全に代行するAI」というより、散らばった情報を整え、人の判断と合意形成を速くする「副機長（Co-pilot）」です。
航空業界のCRM（クルー・リソース・マネジメント）と同じく、操縦桿を握り最終判断を下す機長（人間）に対して、状況を的確にモニタリング・整理して補佐してくれる存在として捉えると、開発現場での健全な使いどころが見えてくるはずです。
次の定例会議で、まずひとつ試してみてください。