会議が終わるたびに、議事録を整え、決定事項を抜き出し、宿題を担当者・期日付きでJIRAやGitHubに起票し、関連メンバーへ通知する。慣れたPMでも、これに30分から1時間は溶かしているはずです。
「AIで議事録要約はやっています」という声はよく聞きますが、要約止まりだと結局アクションアイテムを自分で読み返して転記することになり、PMの会議後タスクは思ったほど減りません。本当に効くのは、議事録の構造化からIssueトラッカーへの自動起票までを、ひとつの流れに繋ぐことです。
この記事では、Claude CodeのSkill機能とMCP(Model Context Protocol)を組み合わせて、議事録テキストを渡すだけで「決定事項・宿題・論点未決」に分解し、そのままGitHubやJIRAにIssueを起票するところまでを自動化する実装手順を、現場で動かせる粒度でまとめます。
なぜ「議事録要約」だけでは時短にならないのか
ChatGPTやNotebookLMで議事録を要約するチームは増えました。ただ、PMの会議後タスクの内訳を分解すると、要約はその一部にすぎません。
- 議事録の体裁を整える
- 決定事項・宿題・論点未決の3区分に分けて記録する
- 宿題を担当者・期日・親エピック付きでIssue化する
- 関係者に通知し、課題管理表とリンクを張る
- 次回会議のアジェンダ候補に積み直す
時間を食うのは中段の2つです。AIで要約だけ作っても、転記とIssue起票という「コピペ作業」は人間に残ります。Claude Codeは、ここを丸ごと巻き取れる位置に立っています。
Claude Codeを「PMの会議後アシスタント」にする全体像
Claude Codeはコード生成ツールという印象が強いですが、本質はファイルを読み書きでき、外部ツール(MCP)を呼べる自律エージェントです。議事録処理に必要なのは次の3要素だけです。
- 議事録の構造化ルールを、Skillとして登録する
- GitHub/JIRA/SlackをMCPで接続する
- 誤起票を防ぐためのガードを運用ルールとして固定する
順に設定していきます。
ステップ1:議事録構造化のSkillを作る
.claude/skills/meeting-to-actions/SKILL.md に、議事録を処理するための指示を1ファイルにまとめます。Skillはファイル名がそのままスラッシュコマンド(/meeting-to-actions)になり、必要なときだけ読み込まれるので、CLAUDE.mdを膨らませずに済みます。
---
name: meeting-to-actions
description: 議事録テキストを「決定事項・宿題・論点未決」に分解し、宿題はIssue起票候補としてJSON出力する。会議後の整理・宿題転記・Issue起票を一気通貫で扱うときに使う
disable-model-invocation: true
---
入力は議事録テキスト(Markdownまたはプレーンテキスト)。
以下の手順で処理する。
1. 本文を読み、次の3区分に分類する
- decisions: 決定事項(合意済み)
- actions: 宿題(誰がいつまでに何を)
- opens: 論点未決(次回以降に持ち越し)
2. actions の各項目には次のフィールドを必ず埋める
- title: 30文字以内のIssueタイトル
- assignee: 議事録に名前があれば抽出、なければ "TBD"
- dueDate: 議事録の表現を YYYY-MM-DD に正規化、なければ null
- context: 背景3行以内
- parentEpic: 議事録上の文脈から類推、なければ null
3. 出力は次の3つを生成する
- tmp/meetings/{date}-summary.md(人間レビュー用の整形済み議事録)
- tmp/meetings/{date}-actions.json(Issue起票候補のJSON配列)
- tmp/meetings/{date}-opens.md(論点未決リスト)
4. 自動起票はしない。Issue起票はユーザーが /issue-from-actions を明示的に呼んだときだけ実行する。
ポイントは disable-model-invocation: true を入れていることです。これがないとClaude Codeが議事録らしきテキストを見るたびに勝手にこのSkillを発火させかねません。起動条件を人間が握るのが、業務系Skillの基本姿勢です。
ステップ2:GitHub/JIRAをMCPで接続する
Issue起票はMCP経由で外部ツールに任せます。Claude Codeのプロジェクト直下に .mcp.json を置き、必要なMCPサーバーを登録します。GitHub公式のMCPサーバーや、JIRA向けのコミュニティ実装が利用できます。
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
}
}
}
}
トークンは .env か OS のキーチェーンに置き、リポジトリにはコミットしません。MCPで何が呼べるか、何が呼べないかは、Claude Code自身が /mcp コマンドで一覧化してくれます。
セキュリティ面では次の3点を必ず押さえてください。
- PATは fine-grained で発行する:対象リポジトリと「Issues: write」「Contents: read」など最小権限に絞る。Classic PAT で全権限を渡すのは避けます
.envを.gitignoreに登録する:.env.env.local.mcp.local.jsonなどをコミット対象から外し、リポジトリ作成時にテンプレ化しておきます- トークンの有効期限を短く設定する:90日程度で切れる設定にしておくと、漏洩時の被害範囲を時限的に抑えられます
ここで重要なのは、Issue起票そのものは別Skillに分けることです。議事録構造化と起票を1つのSkillに混ぜると、起票だけ取り消したい・差し戻したいといった運用要望に対応できなくなります。
ステップ3:起票専用のSkillを切り出す
.claude/skills/issue-from-actions/SKILL.md に、actions.jsonを読んでGitHub IssueやJIRAチケットを起票するSkillを別ファイルとして用意します。
---
name: issue-from-actions
description: tmp/meetings/{date}-actions.json を読み、GitHub/JIRAにIssue起票する。タイトル・本文・担当者・期日を埋めて起票し、起票結果のURL一覧を返す
disable-model-invocation: true
allowed-tools: Read, Bash, mcp__github__create_issue
---
入力: tmp/meetings/{date}-actions.json のパス。
手順:
1. JSONを読み、各 action を Issue 1件として組み立てる
2. 起票前に、件数・タイトル一覧・宛先リポジトリを表示し、ユーザーの確認を待つ
3. 確認が取れたら、mcp__github__create_issue を順次呼ぶ
4. 起票したIssueのURLを Markdown 表で出力する
5. 失敗したものは別ブロックでまとめ、再試行可能にする
禁止事項:
- ユーザー確認なしで起票しない
- 重複Issueを検出した場合は新規作成せず、既存にコメント追記する
allowed-tools で利用ツールを明示し、disable-model-invocation: true で勝手な起動を封じる。この2つで、誤起票事故はほぼ防げます。
ステップ4:運用ルールをCLAUDE.mdに刻む
Skillを置いただけでは、AIは状況依存で判断を変えてしまいます。プロジェクトの CLAUDE.md に、次の3行だけ書き足してください。
## 議事録処理ルール
- 議事録の処理は /meeting-to-actions を使う。要約だけ書き出すような独自処理はしない
- Issue起票は /issue-from-actions を使い、起票前にユーザー確認を必ず取る
- 起票したIssueは tmp/meetings/{date}-issues.md にURL一覧で残し、人間がレビュー可能にする
CLAUDE.mdは毎セッションで自動的に読み込まれるので、誰がClaude Codeを起動しても同じ運用ルールに揃います。チーム全員に「使い方を周知する」のではなく、プロジェクトメモリにルールを置いて、Claude Codeに守らせる発想です。
実際の使い方:会議後5分の流れ
ここまで仕込めば、会議後の作業は次のように圧縮されます。
- オンライン会議の文字起こしを
tmp/meetings/2026-04-30-raw.mdに保存 - Claude Codeで
/meeting-to-actions tmp/meetings/2026-04-30-raw.mdを実行 - 生成された
summary.mdactions.jsonopens.mdを3分でレビュー、担当者や期日の補正を口頭でClaude Codeに指示 /issue-from-actions tmp/meetings/2026-04-30-actions.jsonを実行- 起票結果のURL一覧を確認し、Slack共有
文字起こしの精度や議事録のクセに慣れさせる初期設定の手間はありますが、定常運用に乗ると会議1本あたりの会議後タスクは5分前後に収束します。
期待できる効果と落とし穴
導入したチームから出てくる効果は、典型的に次の3つです。
- 会議後の整理時間が1/4〜1/6に短縮:30分〜1時間が、5〜10分にまとまる
- 宿題の取りこぼしが減る:機械的に拾うので、人間の記憶に依存しない
- 論点未決が見える化される:opensに溜まる項目が、次回アジェンダの自動候補になる
一方で、運用に乗せる前に必ず潰しておくべき落とし穴も3つあります。
- 文字起こしの質を最初に上げる:話者識別が崩れていると、担当者抽出が破綻する。録音設定とツール選定にひと手間かける価値があります
- 起票前の人間確認を絶対に外さない:「便利だから自動起票したい」という誘惑が必ず来ますが、誤起票はチーム信頼を一度で削ります
- 議事録AIの限界を認める:曖昧な合意、ニュアンスを含む結論、政治的配慮はAIが拾えません。最終判断は人間に残す前提で運用設計してください
まとめ
Claude Codeで議事録処理を自動化するときの肝は、次の4点に集約されます。
- 議事録構造化と起票を別Skillに分け、それぞれ手動起動にする
- GitHub/JIRA連携はMCPに任せ、Skill側はロジックに専念させる
- 運用ルールはCLAUDE.mdに書き、誰が起動しても同じ動きになるようにする
- 起票前の人間確認ゲートを絶対に外さない
この設計に乗せると、PMの「会議後30分」が「会議後5分」に変わり、その時間がそのまま設計検討や1on1に回せるようになります。AIで議事録要約しているだけのチームと、議事録から課題管理まで自動連携しているチームでは、半年後の運用負荷がまったく別物になります。
議事録・報告書・仕様書といった文書業務をAIで体系的に加速したい方は、AIX-101 生成AI実践:仕様書・報告書・議事録を半分の時間で仕上げる技術 で文書タイプ別のプロンプト設計とレビュー運用を扱っています。さらに、進捗・課題・リスク管理まで含めた運用設計を学びたい方には、AIX-102 生成AI実践:進捗・課題・リスク管理をAIで加速する運用設計 をあわせておすすめします。Claude Codeで動かす実装と、運用設計の体系の両輪を揃えると、AI活用は一段上のレベルに到達します。