--- title: リスク登録簿・ヒートマップ・RAIDログの違いと使い分け description: リスク登録簿・リスクヒートマップ・RAIDログは同じ資料ではない。ステアリングコミッティにはどれを出すべきか、PMO実務の基準で整理する。 image: https://www.advis-io.com/hubfs/blog-key-visuals/219-risk-register-vs-raid-log-vs-heat-map.ja.kv.png --- [![logo\_transparent-Apr-12-2025-09-23-39-9623-AM-1](https://www.advis-io.com/hubfs/logo_transparent-Apr-12-2025-09-23-39-9623-AM-1.svg)](https://www.advis-io.com/en/?hsLang=ja) - [BLOG](https://www.advis-io.com/blog?hsLang=ja) - [ABOUT](https://www.advis-io.com/about?hsLang=ja) [今すぐはじめる](https://marketplace.microsoft.com/en-us/product/advisioinc1760912844242.advisio-202604?tab=Overview) コンサル仕事術 # リスク登録簿・ヒートマップ・RAIDログの違いと使い分け リスク登録簿・リスクヒートマップ・RAIDログは同じ資料ではない。ステアリングコミッティにはどれを出すべきか、PMO実務の基準で整理する。 [Advisio編集部](https://www.advis-io.com/ja/blog/author/advisio-editorial) 11月 13, 2026 --- 月曜の午後、水曜のステアリングコミッティ資料の締め切りが迫るなか、Jiraからリスク一覧を40行書き出したところだとする。PMがそれを見て「リスクのスライド」を求め、別のチャットではスポンサーが「RAIDログにはどう反映されるのか」と聞いてくる。PMOからは「先月分のヒートマップ、まだでしたよね」という催促も届く。3つの名前が出てくるが、中身は同じものの言い換えなのではないかと疑いたくなる。**実際は違う。リスク登録簿はオーナーとステータス付きの全件台帳、リスクヒートマップは発生確率×影響度を4分間で見せるための絵、RAIDログはその登録簿を前提・課題・依存関係まで含めたプロジェクト全体像に組み込んだものだ。**どれをスライドに出すかは、手元にどれがあるかではなく、その部屋に誰がいて何を決めに来ているかで決まる。 ## 3つの資料は、そもそも答えている質問が違う 混同が起きやすいのは、3つとも同じ材料——「起こりうる悪いこと」の一覧とその確率・影響度——から作られているからだ。だが材料が同じことと、資料として置き換え可能なことは別の話で、財務モデルと投資家向けデッキが同じ数字を使っているからといって同一の資料にならないのと同じだ。リスク登録簿が答えるのは「今の全体像はどうなっていて、誰が何を持っているか」。リスクヒートマップが答えるのは「この部屋はこの先60秒、どこに注意を向けるべきか」。RAIDログが答えるのはもっと広い質問で、「リスクだけでなく、課題・依存関係・前提条件まで含めて、計画を狂わせうるものは何か」だ。この3つを取り違えると、登録簿がそのままステアリングコミッティのスライドに貼られて10ポイントの文字の壁になったり、ヒートマップを渡された監査担当者が日付入りの全件リストを求めて困ったりする。 ![リスク登録簿を唯一のデータ源とし、そこからリスクヒートマップとRAIDログという2つの異なる出力ビューが生成される構造を示す図](https://www.advis-io.com/hubfs/blog-figures/219-risk-register-vs-raid-log-vs-heat-map-fig1.ja.png) 図: データを持つのは登録簿だけ。ヒートマップとRAIDログは、そこから生成される2つの異なるビューであり、別々に手で更新する文書ではない。 ## リスク登録簿:オーナーとステータス付きの全件台帳 登録簿は台帳そのものだ。識別されたリスクはすべて1行になる——ワークショップに参加していない人が読んでも分かる具体性のある記述、発生確率、影響度、算出または設定された深刻度、オーナー名、緩和策、期限、ステータス。どの項目も「ひと目で見る」設計にはなっておらず、検索・フィルタ・監査にかける前提で作られている。リスクが15件の登録簿も60件の登録簿も、構造としては同じで行数が違うだけだ。だからこそ登録簿単体はスライドとして機能しにくい——60行を会場の後ろからでも読める文字サイズでページに載せようとした時点で、それはスライドではなく文書になっている。 登録簿がスライドの中で本来居場所を持つのは付録だ。「23番のリスクの詳細を見せてほしい」と聞かれたときに掘れる場所であり、その詳細が会議本編で扱うべき3件のリスクを押しのけない位置に置く。登録簿がJiraやExcelの中だけに存在し、デッキにはフィルタ済みの抜粋としてしか出てこない、という運用は正しい使い方だ。 ## リスクヒートマップ:まずどこを見るべきかを示す絵 ヒートマップは登録簿と同じ発生確率・影響度のスコアを、グリッド上にプロットする——典型的には4×4か5×5で、一方の軸に確率、もう一方に影響度を取り、深刻度を「読むべき数字」ではなく「見るべき位置」に変換する。右上の象限に座っているリスクは、なぜ今日の議題なのかをそれ以上説明する必要がない。位置そのものが説明になっているからだ。この圧縮こそがヒートマップの価値のすべてであり、同時に限界のすべてでもある。ヒートマップは「どこを見るべきか」を示すが、「それをどうするか」は示さない。緩和策・オーナー・期限は依然として登録簿側にあり、その詳細までヒートマップに詰め込もうとすると(セルの中にラベルを詰め込む、アクション項目のサイドバーを足す)、たいていヒートマップ本来のひと目で分かる明快さの方が先に失われる。 多くのヒートマップ解説記事が飛ばす構築上の問題は、同じセル付近に名前付きのリスクが6〜7件を超えて集まったときに何が起きるかだ。ラベルが重なり始め、バブル同士が積み重なり、本来は会場の後ろからでも読めるはずだったものが、ノートパソコンを開いて目を細めないと読めなくなる。これはヒートマップ固有のレイアウト問題で——登録簿やRAIDログは表形式なので起きない——会議本番ではなく、事前に解決しておく価値がある。バブルの位置をずらす、近接するリスクを1つのラベル付きクラスタに件数と共にまとめる、といった対応は、リスクの数がある程度を超えると実際に何度も試行錯誤が必要になる。 ## RAIDログ:リスクを、動いている他の全てと一緒に見る RAIDログは登録簿のリスク行をそのまま保持しつつ、さらに3つのカテゴリを足す。前提条件(Assumptions、まだ確認が取れていない計画の土台)、課題(Issues、すでに起きてしまったリスク)、依存関係(Dependencies、自分たちの直接コントロール外にある、計画が頼っているもの)だ。この4分割スライドを、週によってリスク8件・依存関係1件のように偏っても崩れないよう組む具体的な手順は、[RAIDログスライドの作り方の記事](https://www.advis-io.com/ja/blog/raid-log-powerpoint-ja?hsLang=ja)で別途扱っている。ここでの論点はもっと狭い——RAIDログが適しているのは、部屋がリスクの詳細ではなくプロジェクト全体の健全性を知りたいときだ。月次で「このプログラムは順調か」を確認するスポンサーには、リスク登録簿スライド+課題スライド+依存関係トラッカーを別々に渡すより、RAIDログ1枚の方が伝わる。RAIDの本質は、これら4つが互いに影響し合っていることにあり、依存関係の遅延がそのまま前提条件を課題に変えてしまう、という連鎖こそが見せたいものだからだ。 トレードオフは解像度にある。4つのカテゴリを1枚に収めなければならない分、登録簿1行やヒートマップの1セルに比べて、各リスクに割ける面積は小さくなる。RAIDログに緩和策の詳細まで全リスク分詰め込もうとすると、たいてい登録簿単体が辿るのと同じ「会場で読めないほど過密なスライド」という失敗に、逆方向から行き着く。 ## では、ステアリングコミッティにはどれを出すべきか 同じ元データが、場面によってどう3つの資料に化けるかを具体例で見てみる。あるCRM移行プロジェクトが抱えるリスク:「データ移行ベンダーがテスト環境の稼働開始日を確定できておらず、2週間遅延すればUATが年末の変更凍結期間にかかる」。確率:中、影響度:大。登録簿では、オーナー(インテグレーションリード)・緩和策(「金曜までにベンダーPMへエスカレーション、バックアップ要員を確保」)・期限が付いた1行になる。ヒートマップでは、グリッドの中段やや上に座る1つのバブルになり、同程度の深刻度を持つ他の3〜4件のリスクと並んで、「今日議論すべき数件のうちの1つ」だとラベルと数字だけでひと目で伝わる。RAIDログでは、同じリスクがRisksの区画に収まるが、隣には関連するDependencyの行(「ベンダーのテスト環境提供——\[期日\]までに必要」)と、先週すでに発生したIssueの行(「ベンダーが最初の環境引き渡し期限を守れなかった」)が並ぶ——この3行が揃って初めて、スポンサーは「これは単発のリスクではなく、このベンダーのパターンだ」と読み取れる。 実際の判断基準はこうなる。全体像と担当の棚卸しをする部屋には登録簿(たいていは付録扱いで、本編のトップスライドではない)。4分間でどこを見るべきかを伝える部屋にはヒートマップ。リスク単体では意味を成さず、課題や依存関係と合わせて初めて読める状況を扱う部屋にはRAIDログ。週次の実務チーム会議は、チーム自身が詳細を使いこなせる距離感にいるので登録簿を求めることが多い。月次のステアリングコミッティは、ヒートマップを本編に置き、登録簿はワンクリックで開ける付録に回すのが定番だ。RAIDログが本領を発揮するのは、上のベンダー例のようにリスク・課題・依存関係が絡み合っている場面で、これはプログラムが進み、外部の関係者が増えるほど起きやすくなる。 **現場メモ:**外資系コンサル時代に担当した案件で、同じベンダーリスクが同じ週のうちに3つの形式で3者に渡り、それぞれ違う質問が返ってきたことがある。PMOへは登録簿の行として渡り、戻ってきたのは「期限はいつに更新されたか」。ステアリングコミッティへはヒートマップのバブルとして渡り、戻ってきたのは「先月からなぜ位置が動いたのか」。スポンサーへはRAIDログの行として渡り、戻ってきたのは「このベンダーとの関係自体をエスカレーションする段階ではないか」という質問だった。どれも、その形式だからこそ出てきた質問で、特にスポンサーの質問は、依存関係と課題がリスクの隣に並んで初めて意味を持つ——RAIDログでなければ出てこない問いだった。 | 観点 | リスク登録簿 | リスクヒートマップ | RAIDログ | | --- | --- | --- | --- | | 答える質問 | 全件は何で、誰が持っているか | 今、どこに注意を向けるべきか | 動いている全体を含め、順調か | | 形式 | 表——件数に比例して行が増える | 2軸グリッド——深刻度を位置で示す | 4分割の表——リスクは4区画の1つ | | 向いている相手 | 実務チーム、監査、PMO | ステアリングコミッティ、時間の限られた経営層レビュー | 全体の健全性を追うスポンサー・プログラムボード | | 更新頻度の目安 | 随時——リスクが動くたびに | 各ステアリングコミッティの直前、登録簿から再生成 | 週次または月次のプログラム確認時 | | 弱点 | 10行を超えるとスライドとして読めなくなる | 緩和策の詳細がない。1セル6〜7件を超えると重なる | 3つの中で1リスクあたりの面積が最も狭い | ## 3つすべてを崩す1つのミス:「絵」を直して「台帳」を直さない 最も多い失敗は、資料の選び間違いではなく、登録簿が変わった後にヒートマップやRAIDログのスライドを手作業で直すことだ。本来は登録簿だけをデータの入力場所にして、それ以外は登録簿から生成されるビューとして扱うべきなのに、そうなっていない。火曜に登録簿でリスクのスコアが見直されても、木曜のステアリングコミッティではヒートマップのバブルが先月の位置のまま、ということが起きる。誰もドラッグし直すのを覚えていなかったからだ。バブルの位置もRAIDログの行も、登録簿が変わるたびに連動して動かなければならないという前提に立つと、「絵を手で直す」という工程こそが、精度が一番問われる会議の直前に限って同期ズレを起こす最初の犯人になる。この部分こそ[Advisio](https://www.advis-io.com/?hsLang=ja)が埋めているPowerPoint上の隙間で、現在の登録簿を渡せば、ヒートマップのバブル配置とRAIDログの4区画をそれに合わせてパワポファイルの中で直接組み直せる——スライドが先月のレイアウトではなく今週の登録簿を反映するようになる。 今週どのスライドを作るとしても、根底にある規律は同じだ。登録簿を唯一の正とし、登録簿からヒートマップへ、登録簿からRAIDログへという工程を、毎サイクル思い出して手直しする作業ではなく、再生成として扱うこと。 ## FAQ ### RAIDログは、リスク登録簿に名前を付け替えただけのものか 違う。RAIDログは登録簿のリスク行をそのまま保持しつつ、登録簿にはない3つのカテゴリ——まだ確認が取れていない前提条件、すでに発生した課題(リスクはまだ起きていないものを指す)、プロジェクトの直接コントロール外にある依存関係——を加えたものだ。この3つを足さずに「RAID」と名前だけ変えたものは、実質はRAIDログになっていない。 ### RAIDログがあれば、別にヒートマップは要らないのでは 対象にステアリングコミッティや時間の限られた経営層レビューが含まれるなら、たいていは両方必要になる。RAIDログのリスク区画はあくまで表であり、2軸のヒートマップのように深刻度をひと目で分かる位置に圧縮してはくれない。実務チームと経営層の両方に報告するプログラムでは、実務チーム向けにRAIDログ、同じ登録簿から生成した経営層向けのヒートマップ、という二本立てで運用していることが多い。 ### それぞれ、どのくらいの頻度で更新すべきか 登録簿は随時更新すべきで、これが唯一の原本になる。ヒートマップとRAIDログのスライドは、使う会議の直前に登録簿から再生成するのが望ましく、独立して手で編集すると、まさにそこから同期ズレが始まる。 ### 付録に回すべきなのはどれで、本編に置くべきなのはどれか ステアリングコミッティではヒートマップがほぼ常に本編のトップスライドになる。数秒で読めるように作られているからだ。登録簿全体は付録に置き、特定のバブルの詳細が聞かれたらリスク番号で参照する。RAIDログは単独で、ステアリングコミッティ資料というよりはプログラムステータス資料に収まることが多い。対象が通常、リスクそのものを審査する委員会ではなく、全体の健全性を追うスポンサーやプログラムボードだからだ。 [コンサル仕事術](https://www.advis-io.com/ja/blog/tag/コンサル仕事術) [コンサル資料作成](https://www.advis-io.com/ja/blog/tag/コンサル資料作成) ## Similar posts ![logo\_white-1](https://www.advis-io.com/hubfs/logo_white-1.svg) Transform your business data into actionable insights with AI-powered analytics. Get consultancy-grade presentations in minutes, not weeks. N&E Building, 6th Floor 1-12-4 Ginza, Chuo-ku Tokyo 104-0061 Japan [contact@advis-io.com](mailto:contact@advisio.com)   - [Blog](https://www.advis-io.com/en/blog?hsLang=ja) - [About Us](https://www.advis-io.com/en/about?hsLang=ja) - [問い合わせ](https://www.advis-io.com/contact?hsLang=ja) - [特定商取引法に基づく表記](https://www.advis-io.com/jacommercialtransaction?hsLang=ja) - [利用規約](https://www.advis-io.com/terms?hsLang=ja) - [プライバシーポリシー](https://www.advis-io.com/privacy-policy?hsLang=ja) © 2026 Advisio Inc. All rights reserved. [Powered by Atlas - a B2B SaaS HubSpot theme](https://www.kalungi.com/atlas-hubspot-theme-for-b2b-saas-software) ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Advisio編集部", "url" : "https://www.advis-io.com/ja/blog/author/advisio-editorial" }, "dateModified" : "2026-11-13T05:15:38.091Z", "datePublished" : "2026-11-13T05:15:38.000Z", "headline" : "リスク登録簿・ヒートマップ・RAIDログの違いと使い分け", "image" : [ "https://www.advis-io.com/hubfs/blog-key-visuals/219-risk-register-vs-raid-log-vs-heat-map.ja.kv.png" ], "mainEntityOfPage" : { "@id" : "https://www.advis-io.com/ja/blog/risk-register-vs-raid-log-vs-heat-map-ja", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://www.advis-io.com/hubfs/logo.svg" }, "name" : "Advisio株式会社" } } ```