リスク登録簿とは？何のために作る？
リスク登録簿（risk register）は、プロジェクトのリスクについての情報を1か所にまとめた一覧です。特定したリスクごとに、分析の結果、決めた対応策、責任者、現在の状況を記録します。現場では「リスク管理表」「リスクレジスター」とも呼ばれます。
目的は3つあります。1つ目は、リスクの情報をチームと関係者で共有すること。2つ目は、対応策と責任者を書いて実行される状態にすること。3つ目は、リスクが起きたときにすぐ対応策を引けるようにすることです。
2026年版のECOは、Business5（リスクを計画し管理する）のイネーブラーに「リスク登録簿を維持する」を挙げています。例は「IT セキュリティの不備」です。旧版（2021年版）では、リスクは Process3 で、イネーブラーに登録簿の語はありませんでした。作って終わりではなく、維持し続けることが明記された点が新しいところです。
リスク登録簿に書く項目は？
決まった様式はありません。組織のテンプレートがあればそれを使い、プロジェクトの規模に合わせて調整します。よく使う項目は次のとおりです。
| 項目 | 書き方の例 |
|---|---|
| 番号 | R-012 |
| リスクの内容（原因・事象・影響） | 認証の仕組みが古いため（原因）、不正アクセスが起きると（事象）、顧客情報が漏れ、公開が延期になる（影響） |
| 区分 | 技術・セキュリティ |
| 発生確率・影響・優先度 | 確率：中、影響：高 → 優先度：高 |
| トリガー（兆候） | 脆弱性の診断で重大な指摘が出る |
| 対応策の型と内容 | 軽減：多要素認証を追加し、公開前に第三者の診断を受ける |
| リスクオーナー | 情報セキュリティ担当のリーダー |
| 期限・費用 | 第2スプリントの終わりまで。診断の費用はコンティンジェンシー予備から |
| 状況 | 対応中 |
| 残存リスク・二次リスク | 利用者の手間が増え、問い合わせが増える（二次リスク：R-013 として登録） |
リスクの内容は「原因 → 事象 → 影響」の形で書くと、何に手を打てばよいかがはっきりします。「セキュリティが心配」のようなあいまいな書き方では、対応策を考えられません。分析の方法は定性的リスク分析と定量的リスク分析の違いで扱います。
リスクオーナーはどう決める？
リスクオーナーは、そのリスクの状況を見守り、対応策を進める責任者です。決め方のポイントは次のとおりです。
- そのリスクに一番詳しく、手を打てる人を選ぶ。技術のリスクなら技術の担当、調達のリスクなら調達の担当。
- 1つのリスクに1人。複数にすると、だれも動かないことがある。
- 本人の合意を得る。一方的に割り当てるだけでは動かない。
- PM が全部持たない。PM は全体を見守り、オーナーが動けるよう支える。
対応策を実際に行う人（リスクアクションオーナー）を、オーナーとは別に決めることもあります。
リスク登録簿を更新するのはいつ？
リスク登録簿は、プロジェクトの間ずっと使います。更新する主な場面は次のとおりです。
計画の初め
最初のリスクを特定して記録する
定例の見直し
確率・影響・状況を見直す（例：隔週）
変更の承認後
変更で生まれた・消えたリスクを反映する
課題の発生時
起きたリスクの状況を更新し、似たリスクを探す
フェーズの区切り
次のフェーズのリスクを洗い出す
プロジェクトの終結
閉じて、教訓として組織に残す
当サイトの整理
リスクが起きた場合も、記録を消さずに状況を「発生」「課題へ移行」などに更新します。何が起き、対応策が効いたかは、次のプロジェクトにとって貴重な教訓です（プロジェクトの教訓の残し方）。
予測型とアジャイルで登録簿の使い方はどう違う？
リスクを記録して追いかける目的は同じです。違うのは、置き場所と見直しの間隔です。
| 観点 | 予測型 | アジャイル |
|---|---|---|
| 置き場所 | 表計算などの登録簿を1つ持ち、計画書とひも付ける | ボードやバックログに載せ、対応を項目として並べることが多い |
| 見直しの間隔 | 定例会や月次の見直しで更新する | スプリント計画・デイリースクラム・ふりかえりで短く見直す |
| 対応策の入れ方 | 対応の作業をスケジュールに組み込み、費用はコンティンジェンシー予備で備える | スパイクや試作をバックログに入れ、価値と並べて優先順位を付ける |
| 上への報告 | 登録簿の上位リスクを状況報告に載せる | 全体の予算・規制に関わるものは、登録簿などにまとめて報告する |
どちらの場合も、リスクごとにオーナーがいて、状況が最新であることが大事です。形式が違っても、問題文では「リスクが見えていて、誰かが追いかけているか」を確かめます。
「まずリスク登録簿を見る」問題とは？
PMP の状況問題でよく出るのが、「特定済みのリスクが起きた。PM がまずすべきことは？」という型です。この場合の基本の答えは、リスク登録簿を見て、決めておいた対応策を実行することです。
理由は、対応策はすでに検討され、合意され、オーナーも決まっているからです。会議を開いて一から考えたり、スポンサーに指示を仰いだりするのは、準備を無駄にすることになります。
ただし、次の場合は別の動きになります。
- 登録簿に無い出来事：影響を評価して、その場の対応（ワークアラウンド）を決めます。
- 対応策が効かない：代替の計画（フォールバック計画）を使います。
- 影響が PM の権限を超える：決められた経路で上げます。
対応策の費用は、多くの場合コンティンジェンシー予備から出します（コンティンジェンシー予備とマネジメント予備の違い）。リスクの全体の流れはリスクマネジメントの流れで確かめられます。
問題文に「リスク登録簿」の語が出なくても、「計画時に特定していた」とあれば同じ考え方です。無料模試30問で、この読み取りを試してみてください。
リスク登録簿でよくある誤答パターンは？
登録簿の問題で選びがちな誤りと、その理由です。
- 起きたリスクを登録簿から消す：状況を「発生」などに更新して残します。対応の記録が教訓になります。
- 転嫁したリスクを消す：保険や委託で影響を移しても、相手が責任を果たすかを見守る必要があり、登録簿に残します。
- オーナーをすべて PM にする：PM が抱えると対応が進みません。詳しい人を合意のうえで決めます。
- 作った後は終結まで開かない：変更の承認後、課題の発生時、フェーズの区切りなどで更新します。
- 脅威だけを書く：好機（よい影響のリスク）も登録し、活用・強化などの対応を決めます。
- 「〜かもしれない」を課題ログに書く：未来の不確かな出来事はリスク登録簿、起きたことは課題ログです。
確認問題1
特定していたリスクが起きた
（当サイトの独自問題）アプリの公開前の診断で、第三者の検査会社から、認証の仕組みに重大な脆弱性があると報告されました。このリスクは計画時に特定されており、対応策とオーナーも決まっています。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：3。特定済みのリスクが起きたので、リスク登録簿の対応策をオーナーとともに実行します。そのうえで状況を記録し、関係者に伝えます。
1：すでに決めた対応策があるので、一から考える必要はありません。2：対応策があるのに指示を待つのは遅すぎます（公開の延期が権限を超えるなら、対応策を実行しつつ上げます）。4：事実を曲げようとするのは不適切です。
確認問題2
リスクのオーナーが決まっていない
（当サイトの独自問題）新しく PM を引き継いだあなたがリスク登録簿を見ると、どのリスクもオーナーの欄が「PM」になっていました。前任の PM は忙しく、ほとんどの対応策が進んでいません。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：1。リスクオーナーは、そのリスクに一番詳しく手を打てる人が適しています。本人と話して合意を得て決めれば、対応策が動き始めます。
2：前任と同じ状況が繰り返されます。3：起きてからでは手遅れになるものがあります。4：スポンサーは個々のリスクの対応に向いていません。
確認問題3
承認された変更の後
（当サイトの独自問題）CCB が、データの保存先を社内のサーバーから外部のクラウドサービスに移す変更を承認しました。チームは移行の準備を始めています。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：4。変更は新しいリスク（データの保存場所、事業者の障害、情報の扱いなど）を生み、既存のリスクも変えます。承認の後、リスク登録簿を更新します。
1：変更によるリスクを見落とします。2：移行の途中で起きるリスクに備えられません。3：外部に任せても、リスクは消えません。