全社リスク登録簿の作成にClaudeを使う手順 — 部門ヒアリングから評価基準をそろえる

全社のリスク登録簿(リスクレジスタ)づくりでつまずくのは、リスクを出す段階よりも、出てきたものを同じ物差しで並べる段階です。営業部門の「大きい」と製造部門の「大きい」は、同じ大きさではありません。この記事では、部門ヒアリングのメモをClaudeのProjectsに集め、抽出、重複の統合、採点を順に進める手順を説明します。先に採点の基準を固定し、その基準をClaudeに守らせるのが骨子です。

登録簿に残す列を先に決める

リスク登録簿は、全社のリスクを1枚の表に並べ、対応の優先順位を決めるための台帳です。会社法施行規則の第100条第1項第2号は、取締役会が整備する業務の適正を確保する体制の一つとして「損失の危険の管理に関する規程その他の体制」を挙げています。登録簿は、この体制を運用に落とすときの中心的な帳票になります。

ただし、規則が求めているのは体制の整備であって、登録簿の書式ではありません。列は自社で決めてかまいません。ヒアリングから作る場合は、次の列があると後の作業が楽になります。

「採点の根拠」の列は、規則には出てきません。あとで部門と採点を議論するとき、根拠がメモの発言まで辿れるようにするために足します。

採点基準をClaudeに渡す前に固定する

部門ごとにClaudeへ「リスクを採点して」と頼むと、会話のたびに物差しがぶれます。同じ種類の事象でも、ある日は影響度4、別の日は3になります。これを防ぐには、基準表を先に作り、毎回同じ表を参照させます。

影響度は金額と事業の言葉で定義する

影響度の区分は、「大」「中」「小」のような形容では決めません。数字と事象で書きます。次はあくまで架空の例で、金額の水準は自社の規模に合わせて置き換えます。

発生可能性も同じで、「ときどき起こる」ではなく「過去3年に1回以上」「10年に1回程度」のように頻度で区分します。

基準表は1つのファイルにして、部門の言い分で書き換えない

基準表を会話の中で口頭修正していくと、途中の採点と最後の採点が別の物差しになります。基準を変えたくなったときは、会話ではなくファイルを書き換え、版を残します。変更後は、それまでの採点を全件やり直します。ここを省くと、早く採点した部門が不利になります。

Projectsに採点基準とヒアリングメモを置く

Projectsは、プロジェクトごとにチャット履歴と知識ベースを持つ作業スペースです。文書や資料を知識ベースにアップロードすると、そのプロジェクト内のチャットが文脈として使います。無料アカウントを含む全ユーザーが使え、無料アカウントが作れるプロジェクトは5つまでです。

登録簿づくりはヒアリングを数週間かけて重ねる作業なので、材料を一か所に置いて毎回同じ前提で続けられるProjectsと合います。置くファイルは次の3種類です。

1. 採点基準表(上で固定したもの)
2. 部門別のヒアリングメモ(部門ごとに1ファイル、日付入り)
3. 登録簿の列定義と、記入例を2〜3行

会話をまたぐ情報は知識ベースに戻す

注意点が1つあります。プロジェクト内でも、チャット同士で文脈は共有されません。共有されるのは、知識ベースに追加した情報だけです。ある部門の整理結果が出たら、チャットに残さず、CSVかテキストに保存して知識ベースに追加し直します。ファイル名に日付と版を入れておけば、どの時点の登録簿かを後から追えます。

プロジェクト指示に作業ルールを書く

「Set project instructions」から保存した指示は、そのプロジェクトのすべてのチャットに効きます。登録簿づくりでは、基準の遵守と根拠の明示を最初に入れます。例えば次のような指示です。

あなたは全社リスク登録簿の整理を支援します。
- 採点は、知識ベースの「採点基準表」の区分だけを使う。基準に
  ない区分や、中間の点(3.5など)は付けない
- 影響度と発生可能性には、必ず根拠としてヒアリングメモの
  ファイル名と発言を引用する。引用できないときは「未確認」と書く
- ヒアリングメモに書かれていないリスクを、一般論から足さない
- 対策の有効性や担当者は決めない。「要確認」として質問に回す
- 出力は列を固定する: リスクID/リスク事象/原因/影響度/
  発生可能性/根拠/既存の対策/未確認事項

指示の中の「足さない」は重要です。リスク管理の一般論から思いついたリスクを混ぜると、部門が実感していない項目が登録簿に入り、ヒアリングの意味が薄れます。

ヒアリングの質問を部門共通にそろえる

メモの形が部門ごとにばらばらだと、抽出の段階で粒度がずれます。ヒアリングの前に、全部門に同じ質問を投げる様式を作り、メモをその順に書き起こしておくと、手順1の抽出が安定します。質問は次の5つで足ります。

1. 自部門の業務が止まる、または損失が出る場面はどんなときか
2. それが起きたとき、金額、納期、取引先、法令のどれに影響が出るか
3. 過去3年に、似た事象は実際にあったか。あったなら、いつ、どの程度か
4. いま、それを防ぐ、または軽くするために何をしているか
5. 他部門に依存している点、他部門に影響が及ぶ点はどこか

質問3の実績は発生可能性の、質問2の影響の種類は影響度の根拠になります。質問5は、手順2の重複統合で同根のリスクを見つける手がかりです。ヒアリング担当者が替わっても同じ様式で聞けば、メモの質が部門間で揃います。

手順1: ヒアリングメモからリスクを抽出する

部門ごとに、メモからリスクを事象の形で抜き出させます。メモには「あの取引先は危ない」「システムが古い」のような感想も混ざるので、事象と原因に分けて書き直させます。

知識ベースの「営業部_ヒアリング_1010.txt」から、リスクを抽出して
ください。
- 1件を「〜により、〜が起きる」の1文にし、原因を別列に分ける
- 根拠となる発言を、そのまま引用する(要約しない)
- 発言が感想にとどまり、事象にならないものは「事象未確定」として
  別表にし、部門に聞く質問を付ける
- まだ採点はしない

採点を同じ依頼に入れないのがコツです。抽出と採点を同時にやらせると、発言が曖昧な箇所を採点の段階で推測で埋めやすくなります。まず抽出だけを人が見て、事象の書き方に納得してから採点に進みます。

手順2: 部門をまたぐ重複を統合する

全部門の抽出が終わると、同じ事象が別の言葉で複数部門から出てきます。たとえば購買が「仕入先の倒産」、製造が「部材の供給途絶」、経理が「取引先への前払金の回収不能」と書いたものは、起点が同じ仕入先の経営悪化かもしれません。

統合は、Claudeに統合案を出させ、人が承認する形にします。

全部門の抽出結果を読み、重複または同根と思われるリスクを
グループにしてください。
- グループごとに「統合してよい」「別リスクとして残す」の案と、
  その理由を書く
- 統合する場合も、元の発言の出典(部門名とファイル名)は
  すべて残す
- 判断がつかないものは「統合保留」とし、関係する部門に聞く質問を出す

統合の判断は、人が決めます。同じ事象に見えても、対応する部署や対策が違うなら、別の行で持ったほうがよい場合があります。登録簿は一覧表であると同時に、対応の責任を割り振る帳票だからです。

統合した行には、出どころの部門をすべて残します。後で採点に異論が出たとき、どの部門の発言に基づく行かが辿れます。

手順3: 固定した基準で採点させる

統合が済んだら、基準表を使って採点します。このとき、行ごとに根拠を引用させ、基準表のどの区分に当たると判断したかも書かせます。

統合後のリスク一覧に、影響度と発生可能性を付けてください。
- 区分は採点基準表のものだけを使う
- 各行に「基準表のどの記述に当たると判断したか」を1文で書く
- ヒアリングメモに金額や頻度の記載がない行は、点を付けず
  「根拠不足」とし、部門に確認する質問を出す
- 最後に、影響度×発生可能性の積が大きい順に並べる

「根拠不足」を点数で埋めさせないルールが効きます。登録簿の信頼性は、データがない行を空欄のまま見せられるかにかかっています。推測で点を付けた行が混ざった登録簿は、会議で一つ疑われると全体が疑われます。

採点のずれを確かめる

同じ事象を、日を変えて採点させると、点が変わることがあります。基準が曖昧なほど、ずれは大きくなります。登録簿の上位20件ほどは、Claudeに2回採点させて、点が食い違った行を一覧にさせます。

上位20件について、先ほどの採点と、基準表だけを根拠にした
再採点を比べ、点が違う行を挙げてください。
違いが出た理由を、基準表の曖昧な箇所と対応づけて書いてください。

食い違った行は、リスクの問題ではなく基準表の書き方の問題であることが多く、基準表の記述を直す材料になります。直したら、手順3を全件やり直します。

手順4: 部門に返して、評価をすり合わせる

出来上がった登録簿は、案にとどまります。部門に返して確かめる点を、表にしておきます。

特に、既存の対策の列は注意が必要です。ヒアリングメモに「ルールがある」と書かれていても、守られているとは限りません。Claudeに書かせるのは「メモ上はこう言われている」までで、有効性の判断は人の仕事です。

事業の流れを図にして洗い出したい場合は、Claudeで業務フロー図を作成する手順が使えます。業務ごとの停止時の影響と復旧順序は、BCPの業務影響度分析をClaudeで進める手順で扱っています。

登録簿を共有するときの注意

登録簿には、不正の兆候や未公表の事案など、社内でも見せる範囲を絞りたい情報が入ります。ヒアリングメモにも、個人名が出る発言が含まれます。

Team・Enterpriseプランでは、プロジェクトの公開範囲として、組織全体に見せる設定と、招待したメンバーだけに限る設定を選べます。招待制にすると、チャット、知識ベース、アーティファクトを含め、招待されていないメンバーからは見えません。メンバーの権限は「Can view」(閲覧とチャットのみ)と「Can edit」(指示や知識ベースの編集を含む)の2段階です。

• 登録簿の作成チームだけを「Can edit」にする
• 部門の確認者には、必要な範囲の閲覧を渡す
• 公開範囲は組織全体ではなく、招待したメンバーだけにする選択肢がある

ただし、組織の管理者はプロジェクト共有そのものを無効にできます。共有が使えないときは、登録簿のファイルを別の手段で渡す運用になります。

知識ベースが大きくなったときは、有料プラン(Pro、Max、Team、Enterprise)でRAGモードが自動で有効になり、容量が最大10倍まで広がります。仕組みと使い分けは、Claude ProjectsのRAG検索の仕組みに詳しくあります。部門数が数十程度なら、ヒアリングメモは全文が収まる規模が多く、RAGの出番は多くありません。

更新のたびに版を残す

登録簿は一度作って終わりではなく、期をまたいで更新していきます。更新のときは、採点基準表の版、各行の採点日、前回からの変更点を列に持たせます。Claudeには、新しいヒアリングメモを知識ベースに足したうえで、前回の登録簿との差分を出させます。

前回版の登録簿と、今回追加したヒアリングメモを比べて、
次の3つに分けて一覧にしてください。
- 新しく出てきたリスク
- 前回から点が動いたリスク(動いた理由をメモの発言で示す)
- 今回のメモで触れられておらず、状況が確認できていないリスク

3つ目の「触れられていない」行は、リスクが消えたのではなく、聞けていないだけの可能性があります。消し込むのは、担当部門に確認が取れてからです。

同じ型で使える他の台帳

「メモから事象を抜き、固定した基準で点を付け、根拠を残す」型は、他の台帳づくりにも使えます。作業ごとの安全面のリスクならリスクアセスメント表の作成手順、管理策と社内規程を突き合わせるならISMSの適用宣言書の下書きがあります。

まとめ

全社リスク登録簿をClaudeで作るときは、採点基準表を最初に固定し、毎回その表だけを参照させます。抽出、統合、採点を別の依頼に分け、各段階で人が承認します。データがない行は、点を付けず「根拠不足」のまま部門へ返します。この3つを守れば、Claudeは部門ごとの言い方の違いを吸収する整理役として働きます。最終の評価値と対応の優先順位は、事業を知る人が決めます。