Work IQ × Copilot CLI × SkillsでMTGからPRを作るワークフローを作ってみた
定例MTGが終わったらターミナルでコマンドを1つ打つ。すると会議で話した課題がGitHub
Issueになって、気づいたらCopilotがPRを出しているみたいなワークフローを作ってみました
MTG→PR作成までの流れ
-
Microsoft TeamsでMTG設定してMTG！（レコーディングを忘れずに！）
-
skillsを実行！
MTG終わったらスキル実行 -
MTGの内容からcopilotが自動でissue作成
-
issueからcopilotがPRも作成
使う技術
今回のフローを支える4つの技術をざっくり紹介
| 技術 | 役割 | 概要 |
|---|---|---|
| Work IQ | 情報源 | Microsoft 365のメール・会議・ドキュメント・TeamsメッセージをAIに渡すMCPサーバー/CLI |
| Copilot CLI | 実行エンジン | ターミナルで動くAIコーディングエージェント。プラグイン・スキルで拡張できる |
| Agent Skills | ワークフロー定義 | SKILL.mdファイルでCopilotの振る舞いをカスタマイズする仕組み |
| Coding Agent | 自動実装 | GitHubのIssueにアサインすると、自律的にコードを書いてPRを作成してくれるクラウドエージェント |
前提環境
必要なもの
- GitHub Copilot Pro以上のプラン（Coding Agent利用に必要）
- Microsoft 365 + Microsoft 365 Copilotライセンス（Work IQ利用に必要）
- テナント管理者によるWork IQアプリの承認
- Node.js（Work IQのインストールに必要）
- GitHub CLI（
gh）
セットアップ
1. Copilot CLIのインストール
brew install github/gh-copilot/copilot
2. Work IQプラグインの追加
Copilot CLIを起動して、プラグインをインストールする。
copilot
> /plugin install workiq@copilot-plugins
初回実行時にブラウザが開いて、Microsoft Entra IDでの認証を求められる。組織アカウントでサインインすればOK。
カスタムスキルの設計
ワークフロー全体像
/meeting-triage を実行すると、以下のフローが走る。
ポイントは、青いステップはAIが自律的に実行して、紫のステップで人間が判断するという分担。全自動じゃなくて、要所で人間がコントロールする設計にしてある。
登場するツールとデータの流れ
Work IQへの問い合わせが2段階あるのがミソ。最初は一覧取得（広く浅く）、課題選択後に詳細深掘り（狭く深く）。これで、Issueに必要な情報を漏れなく取得できる。
スキルの配置
.github/skills/meeting-triage/
└── SKILL.md
SKILL.md
SKILL.md 全文（クリックで展開）
name: meeting-triage
description: |
会議の内容からGitHub Issueを作成し、Copilot Coding Agentにアサインするスキル。
Work IQを使って会議のトランスクリプトから課題を抽出し、ユーザーとの対話で実装詳細を詰めた上で、
仕様書レベルのGitHub Issueを作成する。タスクが大きい場合はサブIssueに分割する。
トリガー: "会議からIssue", "MTGトリアージ", "定例の課題をIssueにして", "会議の決定事項をコードに落とす"
Meeting Triage: 会議 → 対話 → 仕様書Issue → Copilot アサイン
会議で決まった課題を、ユーザーとの対話を通じて仕様書レベルのGitHub Issueに変換し、Copilot Coding Agentにアサインするワークフロー。
基本方針
- Issue は「そのまま実装に着手できる」仕様書レベルの品質にする
- 各課題を1つずつ完結させてから次の課題に進む（逐次型）
- Work IQ への問い合わせはフェーズに応じて使い分ける（一覧抽出 / 詳細深掘り）
- 対象リポジトリは常に現在のリポジトリを使用する
ワークフロー
以下の7ステップを順番に実行する。Step 4〜7 は選択した課題の数だけループする。
Step 1: 会議情報の取得
ユーザーから以下の情報を確認する（未指定の場合のみ質問する）:
- 会議名: どの会議か（例: "定例"）
- 日付: いつの会議か（例: "2026/04/11"）
Step 2: Work IQ で課題を抽出
ask_work_iq ツールを使い、一覧性を重視した問い合わせを行う:
「{日付}に行われた{会議名}の会議内容から、解決するべき技術的課題・アクションアイテムを箇条書きでリストアップしてください。各項目には課題の概要と優先度の目安を含めてください」
結果をユーザーに提示する。
Step 3: ユーザーに課題を選択させる
抽出された課題を番号付きで一覧表示し、ユーザーに以下を確認する:
- どの課題をIssueにするか（番号で選択、複数可、"all"で全選択）
Step 4: 1課題ずつ実装詳細を詰める
選択した課題について、1つずつ以下のサブフローを実行する。
4-a: Work IQ で議論の詳細を深掘り
ask_work_iq ツールを使い、課題ごとに詳細を取得する:
「{日付}の{会議名}で議論された『{課題名}』について、以下を詳しく教えてください:
- この課題が挙がった経緯と背景
- 会議中に出た具体的な要件や仕様
- 議論された技術的アプローチや制約
- 決定事項と未決事項
- 関連する他の課題との依存関係」
4-b: ユーザーと対話して実装方針を詰める
Work IQ から取得した情報をベースに、ユーザーに以下を1つずつ確認する:
- 影響するファイル・モジュール: どのファイルを変更する必要があるか
- アプローチ: 既存パターンに合わせるか、新規アプローチか
- 技術的な制約・リスク: 見落としやすい依存関係や注意点はあるか
- 受入条件: 何が満たされたらDoneとするか（具体的かつ検証可能な条件）
ユーザーの回答を受けて、不明点があれば追加で質問する。十分な情報が揃うまで対話を続ける。
4-c: サイズ判定（必須・自動）
実装方針が揃ったら、必ず以下の判定をする。1つでも該当すれば「分割が必要」と判断する:
- 変更対象のファイル数が 3ファイル以上
- 独立した関心事が複数含まれる（例: 型変更 + UI変更 + ライブラリ追加）
- 受入条件が 4つ以上
- 新規コンポーネント・モジュールの作成と既存コードの修正が混在する
判定結果は必ずユーザーに明示する。 分割が必要な場合は Step 4-d に進み、Issue下書きよりも先に分割を確定させる。
4-d: サブIssueへの分割（分割が必要な場合は必須）
分割が必要と判断したら、Issue下書きを作る前に分割案をユーザーに提示する。
ユーザーの承認を得てから、親Issue + 各サブIssue それぞれについて Step 5 に進む。
分割案の提示フォーマット:
この課題は1つのPRには大きすぎるため、以下のサブIssueに分割することを提案します:
親Issue: 〇〇機能の実装（トラッキング用）
├─ サブIssue 1: 〇〇（変更ファイル: X, Y）
├─ サブIssue 2: 〇〇（変更ファイル: A, B）
└─ サブIssue 3: 〇〇（変更ファイル: C）
この分割でよいですか？変更があれば教えてください。
- 各サブIssue には個別に受入条件・影響ファイル・実装方針を記載する
- サブIssue 間の依存関係（実行順序）がある場合は、本文に明記する
- ユーザーが「分割不要」を明示した場合のみ、そのまま Step 5 に進む
Step 5: Issue 下書きを提示してユーザー承認
以下のテンプレートに従って Issue 本文の下書きを作成し、ユーザーに提示する。
ユーザーの修正要望があれば反映してから Step 6 に進む。
通常 Issue テンプレート
## 概要
{1-2文で何をするか}
## 背景・経緯
{なぜこの課題が発生したか。会議での議論の要約、ビジネス上の動機}
## 現状の挙動
{今どうなっているか。該当コードのパスや挙動}
## 期待する挙動
{完了後にどうなっていてほしいか}
## 実装方針
- **変更対象ファイル**: {ファイルパスのリスト}
- **アプローチ**: {どう実装するか}
- **既存パターンとの整合性**: {合わせるべきパターンがあれば記載}
## 受入条件
- [ ] {条件1}
- [ ] {条件2}
- [ ] {条件3}
## 技術的な制約・注意点
{見落としやすいリスクや依存関係}
## 参考情報
{関連Issue、ドキュメント、会議での決定事項など}
---
> この Issue は Work IQ × Copilot CLI の meeting-triage スキルにより自動作成されました。
親 Issue テンプレート（サブIssue 分割時）
## 概要
{全体として何を達成するか}
## 背景・経緯
{課題の背景}
## サブIssue
- [ ] #{number} {サブIssue 1のタイトル}
- [ ] #{number} {サブIssue 2のタイトル}
## 全体の受入条件
{全サブIssueが完了した上での最終確認}
---
> この Issue は Work IQ × Copilot CLI の meeting-triage スキルにより自動作成されました。
サブIssue は通常テンプレートと同じ構造で、参考情報に親 Issue へのリンクを追加する。
Step 6: GitHub Issue を作成
gh issue create コマンドで Issue を作成する。
サブIssue がある場合の作成順序:
- 各サブIssue を先に作成し、Issue番号を記録する
- 親 Issue を作成する（サブIssue の番号をリンクとして含める）
Step 7: Copilot Coding Agent にアサイン
Issue作成後、ユーザーにGitHub UIからCopilotをアサインするよう案内する:
Issue #{issue-number} を作成しました。
GitHub UIからCopilotをアサインしてください:
https://github.com/{owner}/{repo}/issues/{issue-number}
→ 右側の「Assignees」→「Copilot」を選択
サブIssue がある場合は、サブIssue のみアサインする（親 Issue はトラッキング用）。
Step 4〜7 を選択した課題の数だけ繰り返す。
完了サマリー
全課題の処理完了後、以下のサマリーを表示する:
## 完了サマリー
| # | Issue | タイトル | サブIssue | Copilot |
|---|-------|---------|----------|---------|
| 1 | #XX | ... | - | アサイン済 |
| 2 | #YY | ... | #AA, #BB | 親のみ |
元の会議: {会議名}（{日付}）
注意事項
- Copilot Coding Agentへのアサインにはリポジトリでcloud agentが有効化されている必要がある
- Copilotはアサイン時点のIssue内容のみを参照する（後からコメントを追加しても反映されない）
- そのため、Issue本文には実装に必要な全情報を含めること
- 1課題ずつ完結させるため、途中で中断しても作成済みのIssueは成果として残る
設計のポイント
1. 「全自動」にしない設計
上のフローチャートで紫のステップが3箇所ある通り、課題の選択・実装方針の決定・Issue下書きの承認は人間がやる。会議で出た話題が全部Issueにすべきとは限らないし、実装方針はコードベースを知ってる人間が判断すべきだよね。
2. サブIssue分割
Coding Agentは1つのIssueに対して1つのPRを作る。課題が大きすぎる場合にサブIssueへの分割を提案することで、PRが巨大になりすぎないように制御してる。
3. 仕様書レベルのIssue
Coding Agentはアサイン時点のIssue本文しか読まない（後からコメント追加しても反映されない）。だからIssue本文に「概要・背景・現状・期待する挙動・実装方針・受入条件」を全部詰め込む構造にしてある。
実践デモ: 会議から課題を抽出する
デモ用に、シンプルなTODOアプリを用意して、このアプリの改善点をTeamsでMTGで話し合った。
スキルの発動
copilot-demo-todo のディレクトリでCopilot CLIを起動して、スキルを呼び出す。
> /meeting-triage
スキルが発火すると、まず会議名と日付を聞かれる。
Work IQが会議データを検索
会議名と日付を伝えると、ask_work_iq ツールが呼び出される。
ask_work_iq が呼び出されて、Microsoft365の会議データを検索している
ここが今回のフローの核心部分。Work IQはSharePointに保存された会議の録画トランスクリプトを自動的に検索・分析してくれる。Loopの議事録に「フォローアップタスク」が未記入でも、録画の発言内容から課題を抽出できます
抽出された課題一覧
会議のトランスクリプトから、技術的課題が構造化されて返ってくる
実践デモ: Issue作成 & Copilotアサイン
対話で実装詳細を詰める
選択した課題について、Work IQで会議の議論詳細を深掘りした上で、実装方針を対話で詰めていく。
影響するファイル、アプローチ、受入条件を確認して、Issue本文の下書きが提示される。
Issue作成
OKが出たら、gh issue create でIssueが作成される。
Copilot Coding Agentにアサイン
作成されたIssueのページを開いて、右側の「Assignees」からCopilotを選択するだけ。
IssueのAssigneesからCopilotを選択
アサインすると、Copilotが自律的に：
- リポジトリをクローン
- コードベースをRAGで分析
- 変更を実装
- テストを実行
- ドラフトPRを作成
してくれる。
結果: CopilotがPRを作成
Copilot Coding AgentがIssueの内容を基に自動作成したPR
会議で話してた内容が、数分後にはPRとして形になってる。
まとめ
Teams会議 →PR作成
この一連のフローを、Work IQ × Copilot CLI × Skillsで行えるようにしました！
本番導入を考えるのであれば
- skillの詳細な作り込み、分割
- Coding Agent用のハーネスの強化
あたりを作り込めば本番導入もできるのではないかと思っています
Discussion