「リスク管理表を出しておいて」と上司やクライアントから急に依頼された、あるいはプロジェクトが始まって「そろそろ作らないとまずい」と気づいたものの、社内に流用できる過去のフォーマットがなく、白紙から列項目を考える時間もない——リスク管理の実務を任されている立場なら、一度は経験する場面ではないでしょうか。
この記事では、実際にそのまま自案件へ流用できる「セルが埋まったリスク管理表の実物サンプル」を最初に提示し、続いてそのままコピペしてテンプレートとして使う手順、各列の書き方、業種・文脈別（システム開発／委託先／情報セキュリティ／内部監査）4種の記入例、運用のツボ、そしてExcel運用が限界を迎えたときに検討したいGRCツールまでを順に解説します。
各列項目の根拠には、PMBOK 第6版、JIS Q 31000（ISO 31000）、経産省「サイバーセキュリティ経営ガイドライン Ver3.0」、IPA「情報セキュリティ10大脅威 2026」などを参照しています。社内で「なぜこの列項目なのか」と問われたときに、そのまま出典を示せる形になっています。
今日中にリスク管理表を形にする必要のある方も、既存の表を見直したい方も、そのまま参考にしてください。
目次
一括ダウンロードする
リスク管理表の実物サンプル（列項目＋記入例）
まずは、実際に使えるリスク管理表の現物を見てください。以下は、システム開発プロジェクトを想定したサンプル行（4件）です。列項目はPMBOK 第6版のリスクマネジメント計画・JIS Q 31000（ISO 31000）で示される標準的な要素に、実務でよく使われる「対応期限」「担当者」「ステータス」「更新日」を加えた12列構成です。
| No. | リスク内容 | リスクカテゴリ | 発生確率 | 影響度 | スコア | 対応方針 | 対応内容 | 対応期限 | 担当者 | ステータス | 更新日 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| R-001 | 要件定義フェーズ後の仕様変更が3回以上発生 | スコープ | 高（3） | 大（3） | 9 | 軽減 | 変更管理プロセスを明文化。影響度の大きい変更は運営委員会承認を必須化 | 2026-09-15 | PM 田中 | 対応中 | 2026-09-01 |
| R-002 | 協力会社の主要要員1名が急な離任 | 要員 | 中（2） | 大（3） | 6 | 軽減 | バックアップ要員を副担当として任命。ドキュメント整備を並行実施 | 2026-10-01 | PMO 佐藤 | 未着手 | 2026-09-01 |
| R-003 | 本番稼働直前のパフォーマンス不足発覚 | 技術・品質 | 低（1） | 大（3） | 3 | 軽減 | 結合テスト段階での負荷試験を必須化。基盤ベンダーへ性能要件を再確認 | 2026-11-30 | 技術リード 鈴木 | 計画中 | 2026-09-01 |
| R-004 | 個人情報を含むファイルの誤送信 | 情報セキュリティ | 中（2） | 大（3） | 6 | 回避 | 誤送信防止ツールを全社導入。宛先確認プロセスを二重化 | 2026-09-30 | 情シス 山田 | 対応中 | 2026-09-01 |
この表を土台に、自案件でよく起きるリスクを「リスク内容」欄に書き出し、発生確率・影響度・対応方針を1行ずつ埋めていく——これがリスク管理表運用の起点になります。各列に何を書けばよいかは「リスク管理表の各列の書き方」で列ごとに詳しく解説しています。業種別の記入例は「業種・文脈別のリスク管理表 記入例」で4種類を並べていますので、自案件に近い文脈を参考にしてください。
Excel／Google Sheetsテンプレートとして流用する
上記の実物サンプルは、そのままExcel／Google Sheetsに貼り付けて自案件用のテンプレートとして流用できます。手順は次のとおりです。
- 上のサンプル表（見出し行＋4行）を範囲選択してコピー
- ExcelまたはGoogle Sheetsの新規シートに貼り付け（貼り付け先で表として認識される）
- 「スコア」列に
=D2*E2（発生確率×影響度）の数式を入れて、以降の行にコピー - 「発生確率」「影響度」「対応方針」「ステータス」列に入力規則（プルダウン）を設定
- スコア列に条件付き書式（7〜9=赤／4〜6=黄／1〜3=緑）を適用
サンプル行を自案件で識別されるリスクに書き換え、担当者・対応期限・ステータスを埋めれば、その日のうちにチームへ共有できる形になります。各列の書き方は「リスク管理表の各列の書き方」で解説していますので、埋めながら参照してください。
一括ダウンロードする
リスク管理表とは — 背景とPMBOK／JIS Q 31000での位置づけ
実物を見た後で、リスク管理表がなぜこの形で使われているのかを短く裏付けておきます。リスク管理表は、プロジェクトや業務で発生し得るリスクを一覧化し、発生確率・影響度を分析・評価し、対応方針を明確にする管理ツールの総称です。
PMBOK（Project Management Body of Knowledge）第6版、JIS Q 31000:2019（ISO 31000:2018 と一致）といった国際的なリスクマネジメント規範において、リスクマネジメント計画・リスクの特定・分析・対応・監視を回すための中核ドキュメントとして位置づけられています。
PMBOK・JIS Q 31000・ISO 31000での位置づけ（フレームの由来）
PMBOK 第6版では、プロジェクトのリスクマネジメントを次の7つのプロセスで体系化しています。「リスクマネジメント計画」「リスクの特定」「リスク分析（定性）」「リスク分析（定量）」「リスク対応策の計画」「リスク対応策の実行」「リスクの監視」の7段階で、うち「リスク対応策の実行」は第6版で新設されたプロセスです。
出典・参考資料（1件）
一方、JIS Q 31000:2019「リスクマネジメント―指針」は、ISO 31000:2018 と技術的内容・構成・文言が一致（IDT）する日本産業規格です。
同規格ではリスクを「目的に対する不確かさの影響」と定義し、リスクマネジメントの意義として「価値の創出および保護」を大原則に据え、統合・体系化および包括・組織への適合・包含・動的に繰り返し行う・利用可能な最善の情報を使う・人的および文化的要因を考慮する・継続的改善の促進、の8原則を提示します。
JIS Q 31000:2019 リスクマネジメント―指針
出典：JIS Q 31000:2019 書誌｜一般財団法人 日本規格協会（JSA）
発行年月日：2019-01-21／確認年月日：2023-06-20
対応国際規格：ISO 31000:2018（IDT）
規格概要：組織が直面するリスクのマネジメントを行うことに関して，適用可能な指針を示す。
ISO 31000:2018 のプロセス構成は、「コミュニケーションおよび協議」「適用範囲、状況基準」「リスクアセスメント（リスク特定→リスク分析→リスク評価）」「リスク対応」「モニタリングおよびレビュー」「記録作成および報告」を包括してPDCAを回す形になっています。リスク管理表は、このリスクアセスメント（特定・分析・評価）とリスク対応の記録媒体として機能します。
出典・参考資料（1件）
リスク管理表を作成する目的（複雑化リスクへの対応・PDCA・属人化解消）
リスク管理表を作成する目的は、リスクを「発生してから対応する」状態から「発生する前に想定・予防・軽減する」状態に転換することにあります。プロジェクトが複雑化するほどリスクは相互に絡み合い、担当者の頭の中だけで管理しきれなくなります。一覧化してチーム全体で共有することで、複数のリスクを並行して監視でき、対応漏れを防ぎます。
加えて、リスク管理表はPDCAサイクルの起点になります。定期的にリスクの発生状況・対応の進捗を見直し、想定になかった新規リスクを追記し、既存リスクの評価を更新することで、プロジェクトの実態に即した管理を継続できます。担当者交代や監査対応の場面でも、リスク管理表があれば「なぜこの対応方針を選んだか」の判断過程を第三者が追跡できるため、属人化の解消にもつながります。
リスク管理表と課題管理表・インシデント管理台帳の違い
リスク管理表を作成する際、実務でよく混同されるのが「課題管理表（Issue List）」と「インシデント管理台帳」です。3つはいずれもプロジェクト・業務での問題を記録するツールですが、対象とする事象の時制と管理主体が異なります。用途を取り違えると、上長・クライアントから「これはリスク管理じゃなくて課題管理じゃないか」と指摘されることになるため、以下の識別を押さえておきます。
| ツール | 対象事象の時制 | 記録タイミング | 管理主体 | 使う場面 |
|---|---|---|---|---|
| リスク管理表 | まだ発生していないが、発生する可能性のある事象 | プロジェクト計画時／リスク識別会議／定期見直し | PM／PMO／リスク管理担当 | 予防・軽減の計画立案、優先順位付け |
| 課題管理表 | すでに発生している、解決を要する事象 | 課題が発覚した時点で即時 | PM／各タスクリード | 解決策の検討、担当者アサイン、進捗管理 |
| インシデント管理台帳 | すでに発生した、業務・サービスに影響を及ぼした事象（障害・事故・情報漏えい等） | インシデント発生後の記録 | 情シス／セキュリティ担当／サービスマネージャ | 原因分析、再発防止、報告書作成、監査対応 |
3表は独立して同時に運用します。リスク管理表で監視中のリスクが顕在化して復旧を要する事象になれば課題管理表に「解決を要する課題」として起票され、業務・サービスに実害を及ぼす事象が起きた場合は同時にインシデント管理台帳へ即時記録されます。
したがってリスク管理表は「予防・監視」、課題管理表は「解決」、インシデント管理台帳は「原因分析・再発防止」の役割分担で使い分けます。
リスク管理表の各列の書き方
ここからは、リスク管理表の各列に何を書けばよいかを実務目線で解説します。冒頭の実物サンプルを開きながら、または自案件のテンプレートを埋めながら参照してください。
リスク内容・リスクカテゴリの洗い出し方（粒度の目安）
「リスク内容」欄には、想定されるリスクを具体的な文で記述します。粒度は「1つのリスクに対して1つの対応方針が決められる」レベルが目安です。「スケジュールの遅延」「品質不良」といった抽象的な粒度では対応方針が発散するため、「協力会社の主要要員1名が急な離任することによる、要件定義フェーズの2週間遅延」のように、原因と影響が読み取れる粒度まで具体化します。
「リスクカテゴリ」欄では、複数のリスクを分類軸で整理して見通しを良くします。PMBOK 第6版ではプロジェクトの分野別（技術・スケジュール・コスト・品質・要員・調達・法務・外部要因）で分類する方法が示されており、実務ではこれに「情報セキュリティ」「コンプライアンス」を加えることが多くあります。組織で共通の分類軸を決めておくと、複数プロジェクトを横断してリスクの傾向を集計できます。
発生確率の見積もり方（3段階／5段階の閾値と選び方）
発生確率は、そのリスクがプロジェクト期間内に発生する可能性を段階評価します。実務では3段階（高・中・低）または5段階（非常に高い〜非常に低い）を選択します。判断基準の一例は次のとおりです。
| 段階 | 3段階（実務でよく用いられる目安） | 5段階（NIST SP 800-30 Rev.1 Table G-5 準拠） |
|---|---|---|
| 非常に高い | — | 96〜100%（Very High） |
| 高い | 60%以上（高、スコア=3） | 80〜95%（High） |
| 中程度 | 30〜59%（中、スコア=2） | 21〜79%（Moderate） |
| 低い | 30%未満（低、スコア=1） | 5〜20%（Low） |
| 非常に低い | — | 0〜4%（Very Low） |
3段階の「高／中／低」には、リスクスコア算出のため 3／2／1 の数値を割り当てます（冒頭サンプル表の「発生確率」「影響度」「スコア」の対応関係もこの割当）。5段階も同様に 5／4／3／2／1 で数値化します。
両者の関係は、5段階が上下端に「Very High／Very Low」を足して3段階を拡張したもの、と捉えると分かりやすくなります。ただし閾値の区分は連続的につながらない（3段階「中」＝30〜59% と 5段階 Moderate＝21〜79% は範囲が異なる）ため、社内で運用するときはどちらかに揃え、混在させないことを推奨します。
3段階と5段階の選び方は、リスクの数と要求される精度で判断します。プロジェクト単位（リスク数20〜50件）なら3段階で十分見通せます。全社リスク管理・情報セキュリティのISMS運用など、リスク数が数百件になり優先順位を細かく仕分けする必要がある場面では5段階を採用します。
5段階の閾値定義はNIST SP 800-30 Rev.1「Guide for Conducting Risk Assessments」の付録Iに例示があり、行政機関・金融機関のリスク管理でも同様のスケールが広く用いられています。
出典・参考資料（1件）
影響度の見積もり方（コスト・スケジュール・品質・信頼への影響）
影響度は、そのリスクが発生したときにプロジェクト・業務に及ぼす影響を段階評価します。単一軸で「大・中・小」と評価する方法と、複数軸（コスト・スケジュール・品質・信頼／評判）で個別評価し合成する方法があります。プロジェクト初期は単一軸から始め、規模が大きくなれば複数軸に切り替える段階的な運用が現実的です。
複数軸で評価する場合、たとえば「スケジュール影響：クリティカルパスに2週間以上」「コスト影響：予算の5%超過」「品質影響：ユーザ受入基準未達」「信頼影響：顧客への説明を要する事象」を各軸の「大」の閾値とし、いずれか1軸でも「大」に該当すれば全体を「大」と評価する方式が一般的です。組織で軸と閾値を統一しておくと、複数プロジェクト間のリスク比較が可能になります。
リスクスコアと優先順位付け
リスクスコアは、発生確率と影響度を掛け合わせて算出します。3段階同士なら1〜9、5段階同士なら1〜25の値になり、値が大きいほど優先度が高くなります。
この「リスクスコア＝発生確率×影響度」の考え方は、国内では金融庁が「主要行等向けの総合的な監督指針」（システム統合リスク管理の項）で次のように明確に位置づけているほか、NIST SP 800-30／ISO 31000 でも定性分析の基本枠組みとして採用されています。
システム統合リスクのリスク量は、事象（イベント）の発生確率と発生した場合の影響度（インパクト）の積で認識すべきものである。
出典：主要行等向けの総合的な監督指針（令和8年8月）｜金融庁
優先順位は、スコアだけで機械的に決めず、対応の緊急性（対応期限までの残日数）と、影響の性質（クリティカルパス上のリスクか否か、法令違反を伴うか否か）も加味して判断します。実務では、スコアが高い順に対応リストの上位に並べ、月次または隔週のリスクレビュー会議で見直します。
対応方針の4分類（回避・軽減・移転・受容）とその使い分け
対応方針は、リスクに対して取る戦略を分類する列です。実務では「回避・軽減・移転・受容」の4分類で運用することが一般的で、経産省「サイバーセキュリティ経営ガイドライン Ver3.0」でもリスク対応の考え方として「低減（軽減）」「回避」「移転」の3種を示しています（同ガイドラインは「受容」に明示的に触れておらず、状況に応じた実務判断として補完的に使われます）。
- 回避：リスクの発生原因そのものを取り除く。例：セキュリティリスクが高い機能を実装しない、法令リスクを避けるため対象国での事業を行わない
- 軽減（低減）：発生確率または影響度を下げる対策を取る。例：バックアップ要員を副担当として任命、変更管理プロセスの強化、テスト自動化による品質確保
- 移転（転嫁）：リスクを第三者に移す。例：外部保険への加入、業務の外部委託、契約による責任限定
- 受容：リスクを認識したうえで、対策コストが便益に見合わないため対応せず受け入れる。例：発生確率・影響度ともに低いリスクで、コンティンジェンシー予算（想定外の事象に備えて確保する予備予算）のみ確保
PMBOK 第6版では、脅威（マイナスのリスク）に対する対応戦略として上記4分類に加え「エスカレーション」を含めた5分類を示しています。プロジェクトレベルで対処できないリスクを上位層へ判断委譲する場合は、この「エスカレーション」を採用します。
機会（プラスのリスク）に対しては別途「活用・共有・強化・受容」の4戦略が定義されていますが、リスク管理表では脅威の管理を主眼とするため、実務では上記4〜5分類で運用することがほとんどです。
出典・参考資料（1件）
担当者・対応期限・ステータスの運用
対応方針と対応内容を決めたら、必ず「担当者」「対応期限」「ステータス」を埋めます。担当者は個人名または役割名で明記し、「チーム全員」のような曖昧な指定は避けます。対応期限は具体的な日付を入れ、月次レビューのタイミングと連動させます。ステータスは「未着手・計画中・対応中・完了・受容（対応せず監視）」の5段階が最小構成で、色分けと組み合わせてチーム内で共有します。
リスクマトリクス図で優先順位を視覚化する
リスクの数が多くなると、表形式だけでは優先順位が直感的に把握しづらくなります。そこで、縦軸に影響度・横軸に発生確率をとった「リスクマトリクス」を作成すると、リスクの全体像を一目で見渡せるようになります。マトリクスのセル数は、3段階同士なら3×3（9セル）、5段階同士なら5×5（25セル）が標準的な構成です。
3×3マトリクスの標準的な色分けは次のとおりです（数字はリスクスコア＝発生確率×影響度）。
| 影響度 ＼ 発生確率 | 低（1） | 中（2） | 高（3） |
|---|---|---|---|
| 大（3） | 3（監視強化） | 6（早期対応） | 9（即時対応） |
| 中（2） | 2（受容/低優先） | 4（監視強化） | 6（早期対応） |
| 小（1） | 1（受容/低優先） | 2（受容/低優先） | 3（監視強化） |
スコア7〜9は「即時対応が必要な高優先度」、4〜6は「監視強化と早期対応」、1〜3は「受容または低優先度」というゾーニングが一般的です。冒頭サンプル表の R-001（スコア9）は右上ゾーン、R-002・R-004（スコア6）は中央帯、R-003（スコア3）は左上（影響度は大だが発生確率が低い象限）に位置します。
3×3マトリクスの例では、右上（発生確率・影響度ともに高）に位置するリスクは「即時対応が必要な高優先度」、右下・左上に位置するリスクは「監視強化と早期対応」、左下は「受容または低優先度」といったゾーニングで色分けします。5×5マトリクスは金融機関・情報セキュリティ・ISMS運用など、リスクの数が多い領域で採用されます。
NIST SP 800-30 Rev.1 の付録I でも、5×5マトリクスに基づくリスク評価表が例示されています。
マトリクスは、月次のリスクレビュー会議で経営層・プロジェクトオーナーに報告する際にも有効です。表形式では30件のリスク行を追う必要がありますが、マトリクスなら「右上のリスクが3件、対応方針を検討中」と一言で報告できます。
業種・文脈別のリスク管理表 記入例
ここからは、自案件に近い文脈で流用できるよう、4つの業種・文脈別に記入例を並べます。紙面の都合上、以下の記入例は列を7列（No.／リスク内容／カテゴリ／発生確率／影響度／対応方針／対応内容）に縮約しています。実運用時は冒頭サンプルと同じ12列（＋スコア／対応期限／担当者／ステータス／更新日）で埋めてください。
システム開発プロジェクトの記入例
システム開発プロジェクトでは、要員・仕様変更・技術・品質・スケジュールが主要なリスクカテゴリになります。PMBOK 第6版のリスクカテゴリ分類（要員・技術・スケジュール・コスト・品質・調達・法務・外部要因）に沿って列を埋めます。
| No. | リスク内容 | カテゴリ | 発生確率 | 影響度 | 対応方針 | 対応内容 |
|---|---|---|---|---|---|---|
| 1 | 要件定義後の仕様変更が繰り返し発生 | スコープ | 高 | 大 | 軽減 | 変更管理プロセス明文化、運営委員会承認の必須化 |
| 2 | 協力会社の主要要員の急な離任 | 要員 | 中 | 大 | 軽減 | バックアップ要員任命、ドキュメント整備 |
| 3 | 本番稼働直前のパフォーマンス不足発覚 | 技術・品質 | 低 | 大 | 軽減 | 結合テストでの負荷試験必須化、基盤ベンダーへ性能要件再確認 |
| 4 | 基盤ベンダーの障害でスケジュール遅延 | 外部要因 | 低 | 大 | 移転 | SLAで補償条項を明記、代替ベンダーを事前選定 |
委託先・サプライヤーリスク管理（TPRM）の記入例
委託先リスク管理（Third Party Risk Management：TPRM）は、業務委託先・SaaS事業者・サプライチェーン上の取引先に関わるリスクを一元管理するものです。
経産省「サイバーセキュリティ経営ガイドライン Ver3.0」の指示9「ビジネスパートナーや委託先等を含めたサプライチェーン全体の状況把握及び対策」で対応が要求されており、金融庁・IPAガイドラインでも同様のサプライチェーンリスク管理が求められています。
| No. | リスク内容 | カテゴリ | 発生確率 | 影響度 | 対応方針 | 対応内容 |
|---|---|---|---|---|---|---|
| 1 | 主要SaaS事業者のセキュリティインシデント発生（顧客データ漏えい） | 情報セキュリティ | 低 | 大 | 軽減 | 年次セキュリティチェックシート回収、SOC2/ISMS認証確認、代替SaaSの事前評価 |
| 2 | 委託先の法令違反による契約解除 | コンプライアンス | 低 | 中 | 軽減 | 反社チェック年次更新、コンプライアンス誓約書取得 |
| 3 | 委託先の経営破綻・事業撤退 | 継続性 | 低 | 大 | 軽減 | 与信情報の四半期モニタリング、代替委託先の事前選定 |
| 4 | 再委託先の把握漏れによる管理不能リスク | ガバナンス | 中 | 中 | 回避 | 再委託時の事前承認プロセス、再委託先一覧の四半期報告義務 |
出典・参考資料（1件）
委託先数が数十社を超えるフェーズになると、リスク管理表の1シートだけでは把握しきれなくなり、契約管理・セキュリティチェックシート回収・再委託先の可視化などを含めた体制設計そのものが論点になります。個人情報保護委員会ガイドラインへの対応も含め、委託先管理の実務フローとチェックリストをより深く押さえたい方は、以下の記事もあわせてご参照ください。
情報セキュリティ・ISMS運用の記入例
情報セキュリティ運用では、JIS Q 27001:2023 附属書A の管理策（組織的管理策・人的管理策・物理的管理策・技術的管理策の4分類）に沿ってリスクを識別し、IPA「情報セキュリティ10大脅威 2026」を参照して当面の重点リスクを組み込みます。
| No. | リスク内容 | カテゴリ | 発生確率 | 影響度 | 対応方針 | 対応内容 |
|---|---|---|---|---|---|---|
| 1 | ランサムウェアによる業務停止 | 技術的 | 中 | 大 | 軽減 | バックアップの3-2-1ルール徹底、EDR導入、復旧手順の年次演習 |
| 2 | 取引先を狙った攻撃を経由した侵入 | 技術的 | 中 | 大 | 軽減 | 取引先の年次セキュリティ調査、ネットワーク分離 |
| 3 | 内部不正による情報漏えい | 人的 | 低 | 大 | 軽減 | アクセス権限の四半期棚卸、退職者アクセス即時削除 |
| 4 | 個人情報を含むファイルの誤送信 | 人的 | 高 | 中 | 回避 | 誤送信防止ツール全社導入、宛先確認プロセス二重化 |
出典・参考資料（2件）
内部監査・コンプライアンス対応の記入例
内部監査・コンプライアンス対応では、法令改正・監査指摘事項・内部統制の運用不備がリスクとして識別されます。J-SOX（金融商品取引法に基づく内部統制報告制度）対応や、上場準備企業の内部統制構築の場面で活用されます。
| No. | リスク内容 | カテゴリ | 発生確率 | 影響度 | 対応方針 | 対応内容 |
|---|---|---|---|---|---|---|
| 1 | 個人情報保護法改正への対応漏れ | コンプライアンス | 低 | 大 | 軽減 | 法改正の四半期モニタリング、社内規程の年次見直し |
| 2 | 前年度監査指摘事項の是正未完了 | ガバナンス | 中 | 中 | 軽減 | 指摘台帳の月次進捗管理、期日超過時のエスカレーション |
| 3 | 職務分掌違反（承認者と実行者の兼務） | 内部統制 | 中 | 大 | 回避 | ロール見直し、システム側の権限分離、承認ワークフロー整備 |
| 4 | ハラスメント・不正申告の未検知 | 人的 | 低 | 大 | 軽減 | 内部通報窓口の周知徹底、外部窓口の並行運用 |
一括ダウンロードする
リスク管理表を形骸化させない運用のツボ
リスク管理表は「作って終わり」にしてしまうと、数か月後には実態と乖離した過去の記録になり、いざリスクが顕在化しても参照されない資産になってしまいます。形骸化を防ぐには、レビュー頻度・担当者割当・ステータス管理の運用ルールを最初に決めて回すことが要点です。
レビュー頻度と担当者割当のルール化
レビュー頻度は、プロジェクトの規模とフェーズによって設定します。短期プロジェクト（3〜6か月）なら隔週レビュー、中長期プロジェクト（1年以上）なら月次レビューが目安です。加えて、マイルストーンの通過時（要件定義完了・設計完了・結合テスト完了など）にリスクを棚卸するタイミングを組み込みます。PMBOK 第6版の「リスクの監視」プロセスに沿った運用の実装例です。
担当者は、リスク管理表全体の運用責任者（多くの場合PMまたはPMO）と、各リスク行の対応担当者を明確に分けます。運用責任者はレビュー会議の開催・記録・エスカレーションを担い、対応担当者は割り当てられたリスクの対応進捗を報告します。役割の重複や兼務は形骸化の温床になるため、リスク行1つに対して主担当1名を必ず指定します。
ステータス管理とチーム共有のワークフロー
ステータスは「未着手・計画中・対応中・完了・受容（対応せず監視）」の5段階を基本とし、Excel／Sheetsの条件付き書式で色分けします。緑（完了）・青（対応中）・黄（計画中）・赤（未着手で対応期限が近い）・グレー（受容）といった配色を統一しておくと、大量の行があっても状態が瞬時に把握できます。
更新責任は「対応担当者が週次で更新、PMOが月次でレビュー」といった役割分担を明文化します。共有ルールは、レビュー会議の議事録テンプレートに「今月新規識別されたリスク」「クローズしたリスク」「進捗遅延中のリスク」の3項目を必ず入れ、経営層・プロジェクトオーナーへの月次報告と連動させます。
PDCAと定期見直しで形骸化を防ぐ
リスク管理表は、PDCAサイクルの中で継続的に見直すことで実効性が保たれます。Plan（計画）ではリスクの識別・評価・対応方針の策定を、Do（実行）では対応の実施を、Check（点検）では対応結果と新規リスクの把握を、Act（改善）では対応方針の更新と類似リスクの水平展開を行います。
ISO 31000:2018 のプロセス構成でも、「モニタリングおよびレビュー」がすべてのプロセスを横断する要素として位置づけられています。
プロジェクト終了時には、必ず振り返りを実施し、「識別しておくべきだったが漏れていたリスク」「評価を誤っていたリスク」を組織のナレッジとして残します。次プロジェクトのリスク識別会議でこのナレッジを参照することで、同じ失敗を繰り返さないPDCAが回り始めます。
Excel運用の限界とGRCツールへの移行タイミング
プロジェクト単位でのリスク管理はExcel／Google Sheetsで十分回りますが、全社規模・複数拠点・複数事業のリスクを一元管理するフェーズに入ると、Excel運用は複数の場面で破綻します。ここでは破綻ラインの実務指標と、次に検討する選択肢としてのGRCツールを紹介します。
Excel運用が破綻する典型パターン
Excel運用が限界を迎える典型パターンは次のとおりです。自組織のリスク管理がいずれかに該当し始めたら、GRCツール導入の検討タイミングです。
- 委託先・サプライヤーが10社を超える：TPRMの対象が増え、各社のセキュリティチェックシート回収・評価履歴・契約書・監査記録をExcelファイル単位で管理するとバージョン混在・更新漏れが多発
- 複数拠点・複数事業のリスクを本社で集約する：拠点ごとにExcelファイルが分散し、本社集約時に列項目・評価基準の統一が困難。集約集計の工数が月単位で発生
- 外部監査・内部監査への対応が定期化：監査人にExcelでリスク管理台帳を提出する際、証跡（判断過程・承認履歴）の追跡ができず、追加説明の工数が繰り返し発生
- ISMS認証・Pマーク・J-SOX対応が始まる：管理策と統制活動の対応表・是正措置の記録・年次見直しの証跡が必要になり、Excelでは監査要件を満たしにくくなる
- 複数部門から同時にリスクを更新する運用：Excelの同時編集や履歴管理が限界となり、誰がいつどのリスクを更新したかの追跡が困難になる
委託先の数が数十〜数百規模に膨らんだ場面での従来型管理の実態については、TPRMサービスを提供する立場からも同様の観察が語られています。
従来、大手の製造業の企業様がグループ会社や取引先のサイバーセキュリティ状況を把握しようとすると、セキュリティのガイドラインを作って周知し、守れているかどうかは年に1回、設問数の多いアンケートを取る、というアンケート依存の管理手法しかありませんでした。グループ会社まではそれでやれていても、そこから先の取引先数百社・数千社をどう見ればいいのか、というところで手詰まりになっている企業様が非常に多い状況でした。
経産省「サイバーセキュリティ経営ガイドライン Ver3.0」の指示9では、サプライチェーン全体の状況把握および対策が求められており、委託先が増えるほど「状況把握」の運用負荷が高まります。デジタル庁の資料でも、サプライチェーン・リスクの体系的な管理の重要性が示されており、Excelでの手作業運用には限界があることが背景として指摘されています。
出典・参考資料（1件）
GRCツール移行の判断チャート
GRCツール（Governance, Risk, Compliance ツール）は、ガバナンス・リスク管理・コンプライアンスを統合的または個別的に管理するSaaS／オンプレミス製品の総称です。以下の判断チャートで、Excelから移行すべきタイミングを見極めます。
| 判断項目 | Excel継続で十分 | GRCツール検討 |
|---|---|---|
| 管理対象のリスク件数 | 50件未満 | 100件以上 |
| 委託先・サプライヤー数 | 10社未満 | 10社以上 |
| 拠点・事業部数 | 1〜2拠点 | 3拠点以上 |
| 監査対応の頻度 | 年1回以下 | 年2回以上 |
| 認証・法規制対応 | 特になし | ISMS／Pマーク／J-SOX等 |
| 更新参加者数 | 1〜2名 | 3名以上（多部門） |
右列に該当する項目が3つ以上ある場合、Excel運用のコスト（更新工数・監査対応工数・情報の分散リスク）がGRCツールの導入コストを上回っている可能性が高くなります。移行を検討する際は、リスク管理単体のツールか、統合GRCプラットフォームか、委託先管理（TPRM）特化ツールか、といったカテゴリを整理して選定します。
次項では実務でよく選ばれる3タイプを短く紹介しますが、GRCツールはリスク管理単体・統合GRC・TPRM特化・ISMS運用支援など製品カテゴリが幅広く、選定段階では横並びで比較したほうが自社のフェーズに合う候補を絞り込みやすくなります。カテゴリ全体の比較・選び方・料金相場は、以下の記事に整理していますので、本格的な選定に進む際にご参照ください。
主要GRCツールのスポット紹介
Excelからの移行候補として、実務で選ばれることが多い3つのタイプ別に代表サービスを短く紹介します。詳細な機能比較・料金比較は次に配置した「GRCツールを導入検討中の方へ」のリンクカードからGRCツール比較記事を参照してください。
以下は、これから紹介する3サービスの位置づけを一覧化した比較表です。
| サービス名 | 委託先リスク管理サービス｜VendorTrustLink | Oracle NetSuite GRC | SecureNavi |
|---|---|---|---|
| 提供会社 | 株式会社アトミテック | 日本オラクル株式会社 | SecureNavi株式会社 |
| 主な適合フェーズ | TPRM（委託先リスク管理）を新たに立ち上げるフェーズ | ERP刷新に伴う統合リスク・コンプライアンス管理／IPO準備・上場後の内部統制強化 | ISMS認証／Pマーク取得・運用 |
| 対応領域 | 委託先セキュリティ評価 契約・監査記録の一元管理 変更アラート | 職務分掌ベースのアクセス管理 常時有効な監査証跡 SOC1/2・ISO27001・PCI DSS認証取得済みクラウド基盤 | JIS Q 27001 附属書A の管理策対応 リスクアセスメント支援 審査書類管理 |
| 想定組織規模 | 中小〜大手（20名未満からの導入実績あり） | 中堅〜大手（ERP刷新の判断が伴う規模） | 中小〜中堅（IT導入補助金対象、1,200社超の導入） |
| 詳細情報 | 公式資料を見る | 公式資料を見る | ミーティング予約 |
※上記は各サービスの一般的な適合フェーズと対応領域の傾向です。実際の機能搭載の有無や提供形態については各社の公式情報をご確認ください。
1. 委託先リスク管理サービス｜VendorTrustLink（株式会社アトミテック）
株式会社アトミテックが提供する、委託先リスク管理（TPRM）に特化したSaaSです。委託先へのセキュリティチェックシートの配布・回収・スコアリング、契約書・監査記録・是正措置の一元管理、変更発生時のアラートまでを1つのプラットフォームで運用できます。中小企業1,000名未満部門で導入実績のある国内サービスで、20名未満企業でも導入されており、TPRMを新たに立ち上げるフェーズに適しています。
2. Oracle NetSuite GRC（日本オラクル株式会社）
Oracle NetSuite ERPプラットフォームに標準付帯する、統合型リスク・コンプライアンス機能群です（独立したGRC専用SaaSとしての単独販売はなく、NetSuite ERP契約に含まれる形で提供されます）。
NetSuite基盤は SOC1／SOC2・ISO/IEC 27001・PCI DSS などの第三者監査認証を取得しており、職務分掌に基づくアクセス管理、常時有効な監査証跡、SAF-T・GDPdU・IAF 等の海外監査ファイル形式対応など、内部統制の証跡管理と監査対応の仕組みが業務システムに一体化されている点が特徴です。
ERPと会計・購買を同じ基盤で運用する組織や、IPO（新規株式公開）準備・上場後の内部統制強化に取り組む組織で選ばれます。
業務データと統制を別基盤に分けて運用する場合の現場負荷については、開発側からも次のような認識が示されています。
統制のためのツールを別で持っていると、業務システム側のデータをエクスポートして、突き合わせて、チェックして、という作業がどうしても発生します。ここがかなり労働集約的で、ミスも起きやすいんです。
NetSuiteの場合は、取引が発生したその瞬間のデータがそのまま統制の対象になります。ワークフローによる承認や、不正につながりかねない操作の検知も、業務の流れの中で自動的に回っていきます。
3. SecureNavi（SecureNavi株式会社）
ISMS認証（ISO/IEC 27001）およびPマーク取得・運用支援に強みを持つSaaSで、GRC領域へ拡張しています。JIS Q 27001 附属書A の管理策と自社の統制活動を対応付けるテンプレート、リスクアセスメント表の作成支援、審査に必要な文書の管理までをカバーしています。ISMS認証取得から運用へ移行するフェーズや、認証の年次更新の運用負荷を下げたい組織で導入されます。
IT導入補助金の対象製品にも選定されています。
まとめ
本記事では、リスク管理表の実物サンプルとExcel／Google Sheetsテンプレートを起点に、各列の書き方（発生確率×影響度の見積もり、対応方針の4分類、リスクスコアと優先順位付け）、業種・文脈別4種の記入例、形骸化を防ぐ運用のツボ、そしてExcel運用が限界を迎えたときのGRCツール移行タイミングまでを解説しました。
実務での運用は「テンプレートをダウンロード→自案件のリスクを識別・記入→月次または隔週でレビュー→形骸化の兆候が出たら見直し」というPDCAサイクルで回します。委託先が10社を超える、複数拠点で集約が必要、監査対応が定期化する、といったフェーズに入ったら、Excel運用から次のステップとしてGRCツール導入を検討してください。
カテゴリの全体像から比較検討したい方は、以下のフォームからGRCツールの資料をまとめて取得いただけます。
一括ダウンロードする
よくある質問（FAQ）
Q. リスク管理表とは何ですか？
A. リスク管理表とは、プロジェクトや業務で発生し得るリスクを一覧化し、発生確率・影響度・対応方針を記録して継続的に監視するための管理ドキュメントです。
PMBOK 第6版のリスクマネジメント7プロセス（計画・特定・定性分析・定量分析・対応策計画・対応策実行・監視）と、JIS Q 31000:2019（ISO 31000:2018 と一致）で定義されるリスクアセスメント（特定・分析・評価）およびリスク対応の内容を、一枚の表として記録・共有できる形にしたものです。
プロジェクト単位ではExcel／Google Sheetsで運用され、全社規模になるとGRCツールで統合管理されます。
出典・参考資料（1件）
Q. リスク管理表と課題管理表・インシデント管理台帳は何が違いますか？
A. リスク管理表は「まだ発生していないが起こり得る事象」、課題管理表は「すでに発生し解決を要する事象」、インシデント管理台帳は「すでに発生し業務・サービスに影響を及ぼした事象」を扱う点が異なります。3表は独立して同時に運用し、リスクが顕在化すれば課題管理表へ、業務・サービスに実害が生じれば同時にインシデント管理台帳へ即時記録されます。
リスク管理表は「予防・監視」、課題管理表は「解決」、インシデント管理台帳は「原因分析・再発防止」という役割分担で使い分けます。用途を取り違えて上長・クライアントから「これは課題管理じゃないか」と指摘されないよう、対象事象の時制で識別してください。
Q. リスク管理表の発生確率と影響度は3段階と5段階のどちらを選ぶべきですか？
A. プロジェクト単位でリスク数が20〜50件程度なら3段階、全社リスク管理・ISMS運用などリスク数が数百件になる場面では5段階を選ぶのが実務上の目安です。3段階（高・中・低）は判断が速く軽量に回せる一方、5段階（非常に高い〜非常に低い）は優先順位を細かく仕分けできます。
5段階の閾値定義はNIST SP 800-30 Rev.1「Guide for Conducting Risk Assessments」の付録Iに例示があり、行政機関・金融機関のリスク管理でも同様のスケールが広く用いられています。プロジェクト初期は3段階で始め、規模拡大や認証運用への移行に合わせて5段階へ切り替える段階的な運用が現実的です。
Q. PMBOKとJIS Q 31000（ISO 31000）のリスク管理表に違いはありますか？
A. 両者はスコープが異なり、PMBOKはプロジェクト単位のリスクマネジメントを7プロセスで規定するのに対し、JIS Q 31000（ISO 31000）は組織全体のリスクマネジメントの原則・枠組み・プロセスを規定する汎用指針です。
リスク管理表の列項目（リスク内容・リスクカテゴリ・発生確率・影響度・対応方針・対応内容・担当者・ステータス等）自体はどちらのフレームでも共通で、実務ではPMBOKのプロセスを土台に列を設計し、JIS Q 31000の8原則（統合／体系化および包括／組織への適合／包含／動的に繰り返し／利用可能な最善の情報／人的および文化的要因の考慮／継続的改善）を組織全体の運用ポリシーとして重ねる形が一般的です。
プロジェクト向けはPMBOK、全社リスク管理・ISMS・BCM統合はJIS Q 31000という切り分けが目安になります。
出典・参考資料（1件）
Q. リスク管理表が形骸化しないためのコツは何ですか？
A. レビュー頻度（短期プロジェクトは隔週・中長期は月次＋マイルストーン通過時）、リスク1行あたり主担当1名の指定、ステータスの色分けと更新責任の明文化、この3点を最初に決めて回すことが要点です。
「作って終わり」を防ぐには、対応担当者が週次で更新しPMOが月次でレビューする役割分担を決め、議事録テンプレに「今月新規識別されたリスク」「クローズしたリスク」「進捗遅延中のリスク」の3項目を必ず入れて経営層・プロジェクトオーナーへの月次報告と連動させます。
プロジェクト終了時の振り返りで「識別漏れリスク」「評価を誤ったリスク」を組織ナレッジとして残せば、次案件のリスク識別会議でPDCAが回り始めます。ISO 31000:2018 のプロセス構成でも「モニタリングおよびレビュー」がすべてのプロセスを横断する要素として位置づけられています。
出典・参考資料（1件）
Q. リスク管理表のExcel運用が回らなくなったら次に何を検討すべきですか？
A. 委託先が10社を超える／複数拠点で本社集約が必要／監査対応が年2回以上定期化する／ISMS・Pマーク・J-SOX等の認証対応が始まる、といったフェーズに入ったらGRCツール（Governance, Risk, Compliance ツール）の導入を検討する段階です。
用途に応じて、委託先管理特化（TPRM）、統合GRCプラットフォーム、ISMS運用支援などのカテゴリに製品が分かれるため、自組織の第一のボトルネック（サプライチェーン管理か／内部統制か／認証運用か）で選定軸を定めます。
経産省「サイバーセキュリティ経営ガイドライン Ver3.0」の指示9でもサプライチェーン全体の状況把握および対策が求められており、委託先が増えるほどExcelの手作業運用の負荷が実務指標として顕在化します。カテゴリ全体の比較はGRCツール比較記事「GRCツールおすすめ26選」を参照してください。
出典・参考資料（1件）
出典・参考資料（12件）
- 出典：JIS Q 31000:2019 リスクマネジメント―指針 書誌｜日本規格協会（JSA）
- 出典：JIS Q 27001:2023 情報セキュリティ,サイバーセキュリティ及びプライバシー保護 書誌｜日本規格協会（JSA）
- 出典：JIS Q 22301:2020 セキュリティ及びレジリエンス―事業継続マネジメントシステム 書誌｜日本規格協会（JSA）
- 出典：第78回セミナー ISO31000−2018年版：リスクマネジメント―指針の経営への活用｜JIPDEC
- 出典：PMBOK ガイド 第6版概要解説｜PMAJ
- 出典：NIST Special Publication 800-30 Rev.1「Guide for Conducting Risk Assessments」｜NIST
- 出典：主要行等向けの総合的な監督指針（令和8年8月）｜金融庁
- 出典：サイバーセキュリティ経営ガイドライン Ver3.0｜経済産業省・IPA
- 出典：情報セキュリティ管理基準 令和7年改正版｜経済産業省
- 出典：情報セキュリティ10大脅威 2026｜IPA
- 参考資料：実務者のためのサプライチェーンセキュリティ手引書 Ver1.0｜IPA
- 参考資料：DS-203 サプライチェーン・リスクの課題整理｜デジタル庁
GRCツール・委託先リスク管理サービスの料金・手数料を一括チェック
MCB FinTechカタログでは、GRCツール・委託先リスク管理サービスの最新資料を一括でダウンロードいただけます。
Excel運用から次のフェーズに進みたい方、自社のフェーズに合うサービスを比較検討したい方は、以下から必要なサービスの資料をまとめて取得してください。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
