AIプロジェクトのリスク登録簿テンプレート：判断を支える15の項目群

テンプレートをダウンロードし、登録する情報を決める

15項目群の編集可能なリスク記録と、6件の事例・証拠説明パケットを利用できます。どちらもプレーンテキストのMarkdownファイルです。承認済みの文書、業務管理システム、表計算ファイルに必要な項目を転記してください。Excelブックではなく、自動採点マクロも含みません。15項目群は論理的なまとまりなので、一つの群を複数のデータベース項目に分けて構いません。

最初のリスクを入力する前に、登録簿全体の前提を記録します。試行範囲、許可する操作、影響を受ける利用者、評価期間、証拠の保存先、評価方針の版、受容権限、見直しの契機を明示してください。本稿の架空例は、2026年1月31日までの社内サポート支援AIの試行です。集計時点は1月15日00:00 UTCとします。日付は記録の整合性を説明するためのもので、OpenMaxの実際の導入ではありません。

リスク、課題、仮定、作業を混ぜると、作業完了がリスク解消として報告されやすくなります。次の区別により、誰が何を判断するかを整理します。

一つのインシデントから複数の将来リスクが分かることも、一つのリスクに複数の作業が必要になることもあります。その関連を保持し、作業を追加するたびに同じリスクを複製しないでください。登録簿は毎週作り直す報告表ではなく、継続した記録です。NISTのリスク登録簿の用語説明にも、時間を通じた情報の保持と、受容済みリスクを含む説明があります。

15の項目群に何を書くか

1. 固定IDと対象業務

変わらないID、短い名称、対象業務を設定します。システムや設定の版が評価に影響する場合は、それも記録します。「R03：サポート試行v0.4における機密情報のプロンプト入力」は、「データリスク」より対象が明確です。後でモデルや接続先が変わったとき、同じリスクを新しい条件で評価した履歴を追えるようにします。

対象外も書いてください。読み取り専用で返信案を作る支援AIと、返金を実行できるエージェントでは、想定すべき事象が異なります。返信案の評価を、取引実行の承認として扱ってはいけません。操作権限を広げる前に、対象範囲と再評価を明示します。

2. 原因、不確かな事象、結果

「期限切れの価格文書が検索可能なため、支援AIが古い見積もり案を作り、担当者が履行できない条件を顧客に約束する可能性がある」のように、つながりのある文を書きます。原因は対策候補を、事象は検知対象を、結果は誰が影響を受けるかを示します。

異なる結果をすべて「評判の悪化」にまとめないでください。誤解を招く回答、個人情報の開示、無権限の返金は同じモデルに関係していても、必要な証拠、担当者、対応が違います。表を長くするためではなく、判断が変わる場合に記録を分けます。

3. 分類と影響を受ける人

情報品質、機密性、無権限操作、可用性、人と手順、プロジェクト遂行など、少数の定義済み分類を使います。必要であれば副分類も付けます。分類は絞り込みのための補助であり、リスク記述の代わりではありません。「機密性」だけでは、何がどの経路で誰に見えるのか分かりません。

影響を受ける集団ごとに、考えられる結果を記録します。同じ遅延でも、社内分析者にとっての短い不便と、緊急の対応を待つ顧客の損害は同じではありません。社内での修復費が小さいことだけを理由に、外部の人に生じる重大な影響を小さく扱わないでください。

4. 証拠と参照位置

日付付きの試験結果、設定確認、インシデント記録、依存関係の説明などを関連付けます。版と、該当する段落や結果の位置まで示してください。確認者が参照できない場合は、アクセス不足として記録します。確認不能な要約を検証済み事実として扱ってはいけません。

機密性のある原文は、承認済みの制限された保管場所に残します。登録簿には必要最小限の説明と、アクセス制御された証拠IDがあればよく、個人情報や秘密情報を含むプロンプト全体を複写する必要は通常ありません。リンク切れは再確認の契機であり、リスクが消えた証拠ではありません。

5. 評価期間と仮定

期間、処理量、利用者、運用条件を明記します。「1月の限定試行で、社内担当者がすべての返信案を確認する」と「顧客向け本番で無制限に自動応答する」は別の評価です。知識ベースが更新されることや、手作業の代替手段を利用できることなども依存条件として記録します。

重要な仮定には確認担当者と再評価の契機を付けてください。「供給者の変更がない」は永久的な事実ではありません。確認できなければ不確実性を残し、より限定した利用判断を検討します。不明な情報を最低の発生可能性に変換しないことが重要です。

6. 対策がない仮定での固有リスク

組織の方法で固有リスクを扱う場合、仮定上どの対策を除外したのかを明示します。現在の評価と同じ結果・期間で比べるか、差がある理由を説明してください。アクセス制限や人の確認がすでにあるなら、「対応前」という表現だけでは基準が分かりません。

固有リスクは分析上のシナリオであり、実際の保護策を解除して測ることではありません。点数を得るために本番の対策を止めてはいけません。この基準を組織が要求しない場合は、理由付きで未評価にできます。改善を大きく見せるためだけに高い初期値を作らないでください。

7. 現在運用されている対策

実際に有効になっている対策、責任者、範囲、証拠の日付を書きます。設定による権限境界と、利用者に注意を求める方針を区別してください。両方が意味を持つ場合でも、失敗の仕方は異なります。方針の公開、機能の設定、有効性の検証を、一つの「対応あり」にまとめないようにします。

重要な対策については、どの条件で保護が効かなくなるかも記録します。承認を必須にしていても、確認者が根拠を見られなかったり、別経路で承認を迂回できたりすれば意味が変わります。「人が関与する」だけでは不十分で、実際の判断点と操作を止める能力が必要です。

8. 現在の発生可能性、影響、優先度

いま動いている対策を前提に評価します。可能性、影響、優先度、理由、評価者、日付、評価方針の版を記録してください。証拠への確信と結果の重大さは別の属性です。証拠が弱いから影響が小さいわけでも、影響が大きいから確率が分かるわけでもありません。

本稿では後述の小さな参照表を使いますが、これは確率モデルでもNIST指定の尺度でもありません。評価がなければ未評価とします。調査中に対象機能を保留する必要はあり得ます。数値がないことを、潜在的に重大な事象を無視する理由にしてはいけません。

9. 対応方針と変更範囲

どの対応を提案し、業務をどう変えるかを書きます。回避なら取引実行機能を外す、低減なら機能を制限して承認境界を試験する、といった具体性が必要です。契約や保険は一部の費用負担を変える可能性がありますが、影響を受ける人の損害そのものを必ず除くわけではありません。

受容は権限者による別の判断です。「開発担当者に余裕がない」と同義ではありません。残るリスクと他の選択肢を説明します。代替手順によってサポート担当者が過負荷になるなど、新しいリスクが生じる場合は追加・関連付けを行い、無条件の改善として報告しないでください。

10. リスクの説明責任を負う担当者

一人の責任者、または現任者が明確な役割を指定し、上位への連絡経路も記録します。「IT部門」のような集合名では、見直しが遅れたとき誰が対応するか分かりません。本人が役割を引き受け、必要な根拠を取得できることを確認してください。

リスク責任者がすべての作業を行う必要はなく、受容を決める権限を持っているとも限りません。これらを区別して記録します。責任者が未定なら割当が必要な例外として扱い、誰の担当一覧にも表示されないまま放置しないようにします。

11. 対応作業、担当者、期限

各作業に固有ID、成果物、担当者、期限とタイムゾーン、状態、完了証拠を設定します。「安全性を改善する」は検証できませんが、「期限切れの価格コレクションを外し、検索試験の結果を添付する」は確認できます。複数の作業を、責任境界のない一文にまとめないでください。

作業完了と有効性検証は別です。予定どおり完了しても、その後の試験で対策が迂回される場合があります。リスクが中程度でも、期限超過の作業は見える必要があります。元の期限を変更する場合は理由と承認を保持し、遅延の履歴を消さないようにします。

12. 計画した対策後の目標評価

目指す評価と、実現に必要な仮定を書きます。「目標」と明示し、「現在」や「検証済み」にしないでください。これにより、提案された作業で十分なのか、より単純な機能制限の方が適しているかを判断できます。

目標は実装と検証の成功を条件とするもので、安全性の約束ではありません。現在のリスク集計に混ぜないでください。導入承認を得るためだけに目標を低く設定すると、登録簿は判断を支えるのではなく、隠す道具になってしまいます。

13. 対策の検証と残留リスクの再評価

試験条件、結果、限界、証拠位置、確認者を記録します。「未実施」「明示した範囲で合格」「失敗」「結論不明」などの状態を使い、その後に根拠付きの再評価を残してください。一つの試験に合格しても、評価を下げることが自動的に正当化されるわけではありません。

R03の例では、プロンプトフィルター変更は完了していますが、別の入力経路から架空の機密テストマーカーが通過します。検証は失敗です。低い計画値は目標のままで、現在の高い評価を維持します。この証拠が支持するのは、対策をやり直す判断であって、有効性の宣言ではありません。

14. 受容権限と条件

リスクを受容する場合は、判断者、権限の根拠、範囲、理由、制限、有効開始日、期限または見直し条件を記録します。判断記録にもリンクしてください。リスク責任者の「受容を推奨する」という提案は、権限者の承認そのものではありません。

受容しても重要なリスクは残ります。現在の評価と監視要件を維持します。受容期限が過ぎたら組織の方針に従って再判断し、新しいコメントがないだけで利用許可を自動延長しないでください。担当者の変更や受容条件の変化で、期限前の見直しが必要になる場合もあります。

15. 状態、履歴、次回の見直し

状態は深刻さではなく、ライフサイクルを表します。たとえば対応中、条件付き受容、特定の対象について終了です。次回日付、事象による契機、過去の評価、変更理由を残します。発生済みの事象を課題記録で扱いながら、再発リスクを対応中として保持できます。

終了には理由、証拠、権限を持つ確認者が必要です。古い定期エクスポート処理を削除すれば、その処理に限定したリスクは終了できるかもしれません。しかし、組織全体のデータ開示リスクがゼロになったことにはなりません。処理の再導入や別経路の追加など、再開条件も記録してください。

五つの手順で登録簿を運用する

1. 採点前に判断の境界を決める。 試行範囲、評価期間、方針の版、権限を記録します。機能の制限・停止・再開を誰が決めるかを確認し、チーム間の尺度が違う場合は統合前に調整します。
2. 少数の証拠付きリスクを作る。 想定動作、権限、依存関係、既知の事象、利用者の懸念を確認します。生成AIの提案は候補として扱い、無関係な定型文を除き、証拠不足なら未評価を残します。
3. 現在の状態を評価し、作業を割り当てる。 責任者と関連分野の専門家が仮定と結果を検討します。独立した作業、担当者、期限、検証条件を決め、将来の目標を現在の集計から分けます。
4. 対策を検証し、人の判断を残す。 実装内容と証拠が示す範囲を照合します。失敗や結論不明の結果を隠さず、受容、例外、利用開始の判断を所定の権限者に上げ、理由を保存します。
5. 日付と変化の両方で見直す。 モデル、権限、参照データ、業務の変更、対策の失敗、インシデント、責任者の交代、受容期限を契機にします。定期見直しの間隔は組織のリスクに合わせ、一律の週次・四半期という約束にしません。

NIST AI RMF CoreのMEASURE 1.2は既存対策の有効性評価を扱い、MANAGEは対応と残留リスクの記録を扱っています。同資料が本テンプレートや参照表を指定しているわけではありません。具体的な運用は、組織の適格なリスク担当者や業務専門家による確認が必要です。

六つの記録例：入力、作業完了、有効性は別の進捗

以下の記録、証拠ID、役割はすべて架空です。1月の試行向けに演示方針v1を設定しており、OpenMaxの性能測定でも、すべての組織に通用する推奨評価でもありません。ダウンロード資料には仮定、証拠説明、判断履歴があり、同じ条件で例を追えます。

発生可能性の「低め」は、明示した対策下では通常と異なる条件が必要なこと、「起こり得る」は試行条件で現実的な経路があること、「発生を見込む」は評価期間中の発生に備えるべき条件があることを示します。これは定性的な説明であり、パーセントを割り当てていません。「不明」は選択に十分な証拠がない状態です。影響は、局所的に戻せる不便、顧客や運用への実質的損害、架空方針上で専門判断に上げる重大な結果に分けます。実務では組織と用途に適した境界を定義してください。

この参照表は序数ラベルを掛け算しません。入力が不明なら未評価にし、ゼロにはしません。重大な結果は、発生可能性がまだ分からなくても上位判断の対象です。優先度は注意と作業を振り分けるもので、承認を与えるものではありません。低だから自動公開してよいわけでも、追加証拠なしにラベルを変えるだけで高を中にしてよいわけでもありません。

1月15日00:00 UTCの集計では、6件すべての記録を保持します。現在も対象リスクがあるのはR01からR05の5件です。そのうち現在評価があるのは4件なので、評価記録のカバー率は 4/5＝80% です。「80%安全」という意味ではありません。R06は履歴として残しますが、この現在リスクの分母からは除きます。

未完了作業は、責任者割当A01と参照元是正A02の2件です。そのうち1件が期限超過なので、未完了作業に占める超過割合は 1/2＝50% です。完了したA03はこの分母に入りません。一方、A03は別の集計に入ります。有効性検証が必要な完了済み対策作業は1件、そのうち合格は0件で 0/1 です。完了件数だけを見ると、対策が検証に失敗したことを見落とします。

R04は受容済みですが終了ではありません。中の現在評価と期限付きの判断を維持します。R05には返金が実際に起きたため課題リンクがあり、その課題の解決だけで再発リスクが消えるとは言えません。R06は限定的な終了例です。記録された特定の原因は取り除かれましたが、別の場所に関連するデータリスクが残る可能性があります。

手作業、ルール、エージェント支援を選び分ける

小さな試行なら、承認済みの共有記録と指名した確認者から始められます。参照元が少なく、変化が少ない場合は、この方が管理しやすいこともあります。見落としを防ぐため、見直し担当者と、未割当・期限超過・受容期限接近の一覧を用意します。ソフトウェアを増やしても、判断権限の対立は解決しません。

既存の業務管理システムに必須項目、権限、変更履歴、通知があれば、合意した手順に合わせて設定し、試験用の記録で確かめてください。親リスクを受容した後も期限超過の作業が見えるか、期限を編集しても旧値が残るかを確認します。機能名だけで期待どおりの動作を推定しないことが重要です。

ルールやスクリプトは、担当者不足、無効な日付、受容期限切れ、ID不整合、目標値の現在欄への混入などの機械的確認に向きます。評価方針の版を明示してください。証拠がないことは検出できても、確認できない対策が有効だとは判断できません。不確かな記録はレビューに送り、初期値の低で埋めないようにします。

多数の承認済み参照元から更新候補を集める必要がある場合は、エージェント支援を評価する理由が生まれます。まず読み取り専用にし、出典付きの提案から始めます。正式記録の置換前に人が確認し、架空の証拠ID、担当者の推測、依頼していない評価変更を監視してください。規模を広げるなら、受容・利用開始の権限分離、変更履歴、アクセス制御、更新停止の試験も必要です。これらは実装の受入条件であり、特定製品がすでに満たしている証明ではありません。

OpenMaxの役割と、先に確認すべきこと

本稿はOpenMaxのコンテンツチームによる記事です。OpenMaxは、人とエージェントの協働を製品の位置付けとして示しています。この業務では、エージェントが証拠付きの更新案を用意し、人が評価と受容を決める用途を検討できます。ただしこれは提案する用途であり、標準のリスク登録簿、認証された採点、プロジェクトツールとの自動同期、法令順守機能を検証した主張ではありません。

実際のプロジェクト資料を接続する前に、6件の架空例で実演を求めてください。R01は未評価のまま、A02は期限超過、R03は検証失敗を保持し、R04には受容期限、R05には課題リンクが必要です。R06は関連する変更なしに再開してはいけません。制限された証拠を見られる人、評価を書き換えられる人、受容を承認する人、以前の版を復元する人も確認します。一般的な製品説明から推測せず、提案された設定で動作を確かめます。

リスク件数が少ない、参照元の権限を確定できない、更新案を確認する権限者がいない場合は、単純な共有記録を選ぶ方が適切です。次の一歩は、架空資料を使って限定した協働手順をOpenMaxに相談することであり、エージェントにリスク受容を任せることではありません。受容理由は意思決定ログ、発生した事象はインシデント振り返りに関連付けます。プロジェクト状況報告は確認済み記録の要約にし、根拠の代用にはしません。

限界、機密情報、専門家の確認

リスク登録簿は調整のための記録であり、完全な安全性評価や法令順守の証明ではありません。有用性は各項目の範囲、証拠、専門性、判断に依存します。丁寧に維持しても、重大なリスクを見落とす可能性はあります。重要な結果を伴う導入では、業務、セキュリティ、プライバシー、法務の専門家を関与させてください。本稿は実名付きの独立した専門家レビューを受けたものではありません。

表を埋めるためだけに、機密プロンプト、個人情報、認証情報、インシデント詳細をアップロードしないでください。責任部署と承認済みの保存場所、アクセス、保持方針を決めます。判断に必要な最小限の根拠を共有し、確認者の役割で実際にアクセスできるか試します。広く共有する登録簿では、制限された証拠の内容を公開せず、その存在と参照先を記録できます。

例の行列、日付、しきい値、状態は教育用の設計であり、業界共通の要件ではありません。NIST AI RMFの概要は任意利用を説明しており、2026年9月4日の確認時点では1.0の改訂が進行中としています。正式な手順に採用する前に、使用する版、組織の方針、該当する地域の要件を確認してください。

よくある質問

ダウンロードはExcel形式ですか？

いいえ。編集可能なMarkdownの記録と事例パケットであり、XLSXブックではありません。15の論理的な項目群を表計算に移す場合は、担当者、日付、評価の種類、検証状態を別の列にします。表を簡単にするために目標を現在の評価として扱わないでください。

すべてのAIプロジェクトに五段階の行列が必要ですか？

あらゆるプロジェクトに適した単一の行列はありません。判断と結果に合う、組織で承認された方法を使います。本稿の三段階の例は明示的な参照表で、確率推計ではありません。証拠不足は未評価とし、可能性が不明でも重大な結果には注意が必要です。

残留リスクを現在より低く評価できるのはいつですか？

実装した変更と、対象範囲に対する記録済みの再評価が、その結論を支持する場合です。作業完了や限定的な試験合格だけでは、自動的な低下を正当化できません。現在のリスクも既存対策に対する残留リスクであり得るため、日付と基準を明確にします。

受容したリスクを登録簿から削除してよいですか？

受容した対象リスクが残っている間は削除しません。現在の評価、権限者の判断、条件、見直し日、期限を維持します。受容はガバナンス上の判断で、リスクの除去ではありません。終了には別の理由と証拠が必要です。

人の確認なしでエージェントに維持を任せられますか？

出典付きの更新案を用意するような限定支援は評価できますが、結果の重大さの判断、リスク受容、導入承認の能力や権限を持つと仮定してはいけません。確認の境界を設定して試験してください。本稿はOpenMaxや他製品の具体的な対応能力を検証したものではありません。

出典と証拠の範囲

2026年9月4日に確認した出典は、NISTの固有リスク、残留リスク、リスク登録簿、AI RMF Core、フレームワーク概要です。各資料は近接する記述の概念を支えるもので、本登録簿の有効性やOpenMaxの推奨を意味しません。OpenMaxのウェブサイトは第一者の位置付けを示す資料であり、独立した製品検証ではありません。

15の項目群、6件の記録、証拠説明、参照方針、計算は独自の教育用資料です。顧客成果、実証研究、NIST公式テンプレート、試験済みのOpenMax自動化ではありません。実務に使う前に、説明責任を負う専門家が範囲、評価方法、証拠規則、判断権限を承認する必要があります。