キックオフ時に張り切って作ったリスク登録簿が、3ヶ月後にはほぼ更新されていない。発生したリスクは事後で書き加え、新しい兆候はSlackや議事録に散らばったまま。経営報告で「リスクは特になし」と言わざるを得ず、その2週間後に火を吹く——多くのPMが経験のある景色です。
「AIでリスク管理を効率化したい」とよく言われますが、リスクの実態は「兆候の早期検出」と「定期的な棚卸し」の2点に尽きます。要約AIだけでは追いつきません。本当に効くのは、Skill+MCPでJIRA・Slack・議事録から兆候を毎週自動抽出し、PMが棚卸しに集中できる運用です。
この記事では、Claude Codeでリスク登録簿を毎週育てる早期警戒システムを、現場で動かせる粒度で実装します。
なぜリスク登録簿は形骸化するのか
リスク登録簿が機能しないのは、PMの怠慢ではなく構造的な問題です。
- 兆候が分散している：JIRAのコメント、Slackの雑談、議事録の発言、それぞれを横断して拾うのが大変
- 更新タイミングが曖昧：「気づいたとき」では結局更新されない
- 報告フォーマットが定まらない：登録簿を見ても「何が変わったか」が分からない
Claude Codeは、MCPで3経路のデータを定期取得し、Skillで「兆候→登録簿への反映候補」を自動生成し、PMが週次で棚卸しする運用を素直に組めます。AIに判断させるのではなく、AIを「兆候収集アシスタント」として使うのが鍵です。
Claude Codeを「早期警戒システム」にする全体像
必要な要素は次の3つです。
- データ取得MCP：JIRA・Slack・議事録レポジトリの3経路（読み取り専用）
- リスク兆候抽出Skill：過去7日のデータから既存リスクの状況更新と新規兆候を抽出する
- CLAUDE.mdリスク運用ルール：兆候のスコアリング軸、棚卸しの頻度、エスカレーション基準を明記
毎週月曜にSkillを叩けば、登録簿の更新候補が自動で揃い、PMは判断と意思決定にだけ時間を使えるようになります。
ステップ1：リスク登録簿のYAML構造を決める
docs/risks/register.yaml にリスク登録簿を構造化保存します。
risks:
- id: R-001
title: "結合テスト工程で他システム連携の不整合が頻発する可能性"
category: "技術"
probability: 3 # 1-5
impact: 4 # 1-5
score: 12
status: "open" # open / mitigating / closed
owner: "PM-Suzuki"
last_reviewed: "2026-04-23"
signals:
- source: "slack:#proj-dev"
date: "2026-04-22"
excerpt: "他社API側のレートリミットでテスト中に頻繁に詰まる"
mitigation: "週1で他社APIチームと連携テスト計画を共有"ポイントは、signalsに「どこで発見された兆候か」を必ず記録すること。これがあると、登録簿が単なる予測リストではなく「現実の観測ログ」として機能します。
ステップ2：リスク兆候抽出Skillを定義する
.claude/skills/risk-scan/SKILL.md を作ります。
---
name: risk-scan
description: 過去7日間のJIRAコメント・Slack議論・議事録から、docs/risks/register.yaml の既存リスク更新候補と新規リスク兆候を抽出し tmp/risks/{date}-update.yaml に出力する
disable-model-invocation: true
allowed-tools: Read, Write, Bash, mcp__github__*, mcp__jira__*, mcp__slack__*
---
# リスク兆候抽出Skill
## 入力
- なし（実行日から過去7日を自動算出）
## 処理
1. `docs/risks/register.yaml` を読み、既存リスクの`title`と`category`をベクトル化
2. 過去7日のJIRAコメント・Slack（指定チャンネルのみ）・議事録を取得
3. 既存リスクと意味的に近い言及を抽出 → `existing_risk_updates`
4. 既存リスクに該当しないが「期日遅延」「品質不安」「人員逼迫」「外部依存」を含む発言を抽出 → `new_risk_candidates`
## 出力フォーマット
- ファイル名：`tmp/risks/{YYYY-MM-DD}-update.yaml`
- 章立て：
- existing_risk_updates: [{risk_id, signals, suggested_status}]
- new_risk_candidates: [{title, category, evidence_excerpts, suggested_score}]
- low_confidence: [...] # 判断に迷ったもの
## 厳守
- 既存リスクへの紐づけは「キーワード一致」ではなく文脈一致で判断
- 新規候補のスコアは「probability × impact」で計算し、根拠を必ず併記
- 不確実な抽出はlow_confidenceに分類し、PM判断に回す「low_confidence」を必ず設けるのが重要です。AIが自信を持てない兆候を強制的にPM判断に回すことで、過剰な自動分類によるリスク取りこぼしを防げます。
ステップ3：CLAUDE.mdにリスク運用ルールを書く
## リスク管理運用ルール
### スコアリング軸
- probability: 1=ほぼ起きない / 5=今月中にほぼ確実
- impact: 1=軽微 / 5=スケジュールまたは予算が30%以上ぶれる
- score = probability × impact
### 棚卸しタイミング
- 毎週月曜にrisk-scan Skill実行 → tmp/risks/に更新候補が出る
- 火曜のリスク会議で棚卸し → docs/risks/register.yamlを更新
- score≥12 のリスクはステアリング会議でエスカレーション
### AIに任せて良いこと・任せてはいけないこと
- AIは「兆候の収集」「既存リスクとの紐づけ候補出し」までを担当
- 「リスクのopen/closeの判定」「経営報告に乗せるかどうか」はPMが必ず判断
- score算出はAIが叩き台を出し、PMが最終決定するCLAUDE.mdの「AIに任せて良いこと・任せてはいけないこと」が運用の柱です。リスク管理は最終的にはPMの責任なので、AIはあくまで補助に徹する設計にします。
ステップ4：実際の運用フロー
毎週の運用は次の通りです。
- 月曜朝：PMが
claudeを起動し/risk-scanを実行 →tmp/risks/{date}-update.yaml生成 - 月曜午後：PMが更新候補を確認、low_confidenceを判断、merge候補を確定
- 火曜のリスク会議：チームで棚卸しし、
docs/risks/register.yamlに確定反映 - 金曜の経営報告：score≥12のリスクをサマリーに追加、Skillの履歴を添付
慣れれば、月曜午後の30分で棚卸し前準備が完了します。火曜のリスク会議は「議論」に集中でき、データ整理に時間を取られなくなります。
期待効果と運用上の注意点
導入チームから報告される効果は次の3点です。
- リスク登録簿が放置されない：毎週兆候候補が湧くため、更新インセンティブが続く
- 早期警戒の精度が上がる：JIRA・Slack・議事録の3経路を横断するため、人間では追いきれない兆候を拾える
- 経営報告のリスク章に説得力が出る：「先週はこの兆候があり、今週このように動いた」と語れる
一方で、運用の落とし穴も3つ。
- 登録簿のYAML構造を変えるなら全員に通知する：構造変更でSkillが壊れることが多い
- AIに「open/close判定」をさせない：リスクのclose判断は事業影響を理解した人間がやる
- low_confidenceを放置しない：判断に迷う兆候こそ重要な場合が多いため、毎週必ず目を通す
まとめ
- リスク登録簿の形骸化は兆候収集の手間と棚卸しのきっかけ不在が原因
- Skill+MCPで兆候収集を自動化し、PMの仕事を「棚卸しと判断」に集中させる
- CLAUDE.mdに「AIに任せない領域」を明記すると、過剰自動化による事故を防げる
- 毎週育つ登録簿が手元にあると、経営報告に説得力が出て、炎上の前に手を打てる
ここまでで「動く早期警戒システム」は作れます。ただし実務でリスク管理を“経営の意思決定材料”に育てるには、リスク戦略の策定、ステアリングエスカレーション設計、コンティンジェンシー予算化といった上位設計が必要です。
IPJ-101『プロジェクトリスク設計』 と AIX-102『進捗・課題・リスク管理をAIで加速する運用設計』 を組み合わせると、本記事のSkillをベースに、リスクの戦略化・経営連携・組織横断運用までを体系で学べます。「リスク登録簿を作っては形骸化させる」のループから抜け出したいPMには、最短の導線です。