毎月の業務の変更記録から、内部統制の業務記述書とリスクコントロールマトリクスの直すべき箇所を探し、改訂の案を作る

処理の起点を決める

月初に、前月分の変更記録をまとめて処理します。 変更記録は月の途中にも届きますが、規程管理の台帳もシステムの変更管理も月次で締めるので、締めた後の一覧を起点にするほうが漏れが出ません。 1日では終わらない量になっても、月初の数日で全件を案にできれば足ります。

ただし、重要な変更は月初を待ちません。 基幹システムの入れ替え、決裁の権限の大きな変更、新しい事業の開始のように、推進室が「重要」と印を付けた変更記録は、届いた時点で個別に処理します。 実施基準は、組織の変更やITの開発など、財務報告の信頼性に重要な影響を及ぼす可能性のある変化が起きるたびにリスクを再評価する仕組みがあるかを、全社的な内部統制の評価項目の例に挙げています。

処理の順は、プロセスの順です。同じプロセスに関係する変更記録を続けて流すことで、文書のキャッシュが効きます。

入力データを集める

質を決めるのは、対応表です。 「この規程はこのプロセスに効く」「このシステムはこのプロセスで使う」が表になっていないと、変更記録を渡す先が決まりません。実施基準は、業務プロセスで使われているシステムの一覧を作ることが有用だとしています。対応表は、その一覧を推進室の用途に合わせて広げたものです。

RCMの列はそのまま渡します。 実施基準の参考の「リスクと統制の対応（例）」は、業務・リスクの内容・統制の内容・要件（実在性、網羅性、権利と義務の帰属、評価の妥当性、期間配分の適切性、表示の妥当性）・評価内容の列を持っています。自社のRCMの列名をプロンプトで説明し、AIが列の意味を取り違えないようにします。

データの取得方法を決める

業務記述書は、節の番号を付けて文字にします。 「1．受注（3）」のような節の番号が付いていれば、AIは箇所を番号で指せ、推進室の担当は文書の該当箇所をすぐ開けます。番号が無い文書は、段落ごとに通し番号を振ってから渡します。

候補プロセスが対応表で1つも引けない変更記録は、AIに渡しません。 「対応表に無い」こと自体が、対応表の見直しか、評価の範囲外の変更かのどちらかなので、推進室の担当が直接見ます。

AIへ渡す前に整形する

1. 変更記録の正規化 … 3つの経路の書式を、種類・件名・内容・施行日・所管部署の項目にそろえます
2. 重複の統合 … 同じ改定が規程の台帳と稟議の写しの両方で届いたら、1件にまとめます
3. 文書の文字化 … 業務記述書を節の番号つきの文字に、RCMを統制IDつきの行にします
4. 版の確認 … 渡す文書が文書管理の最新の版かを確かめ、版の番号を記録します
5. 処理の並べ替え … 候補プロセスごとにまとめ、プロセスの順に並べます
6. キャッシュの区切り … 業務記述書とRCMを前置き（キャッシュの対象）に、変更記録をその後ろに置きます

4番目を軽く見ないでください。 前月に直したはずの文書の古い版を渡すと、直した箇所をもう一度「直すべき」と挙げてきます。 推進室の担当が二度手間をかけるだけでなく、どちらの版が正しいかの混乱を生みます。

6番目は費用と速さのためです。 公式の説明では、キャッシュできる前置きには最小の長さがあり、それより短いとキャッシュされず、エラーにもならないとされています。業務記述書とRCMは十分に長いので、前置きに置けばキャッシュの対象になります。 応答の cache_read_input_tokens で、実際に読まれたかを確かめます。

AIに処理させる

させるのは、変更記録と現行の文書を読み比べて、直すべき箇所の案と、統制への影響の有無の案を書くことです。

「改訂案」の決まりが、この構成でいちばん大事です。 変更記録が「決裁の金額の基準を500万円から1,000万円に変更」なら、改訂案はその数字を変えるところまでです。「あわせて承認の手順も見直すのが望ましい」のような、変更記録に無い改善をAIが書き足すと、案が業務の実態から離れます。

最後の行の「影響なしの理由」も、必ず書かせます。 第1章で書いたとおり、影響なしの判断にも根拠を残すことが、この構成の目的の1つです。

1行目がいちばん起きやすい失敗です。 統制の担当や頻度が変わる変更を渡すと、AIは「重要な変更に該当するため、整備状況の再評価が必要です」と書きがちです。その一文が推進室の判断の前に担当部署へ渡ると、判断が済んだように読まれます。 変わる要素を挙げるところまでにさせます。

指示内容を固定する

あなたは上場会社の内部統制推進室で、業務の変更記録を内部統制の文書に反映する案を作る補助をします。
渡された変更記録と文書に書かれていることだけをもとに案を作ってください。推測で補わないでください。

【文書の説明】
- 業務記述書：プロセスごとの文書。各段落の先頭に節の番号がある
- RCM：1行が1つの統制。列は 統制ID／リスクの内容／統制の内容／種類（予防・発見）／
  頻度／担当／勘定／要件／統制上の要点（Yes/No）

【やること】
1. 変更記録の内容が、渡された業務記述書のどの節、RCMのどの統制IDに関わるかを探す
2. 関わる箇所ごとに、現行の文面、改訂案、理由を書く
3. RCMの統制について、統制の内容・担当・頻度・種類のうち変わるものを挙げる
4. 変更記録だけでは決められない点を、担当部署への確認事項にする
5. 関わる箇所が無い場合は、その理由を書く

【厳守事項】
- 節の番号と統制IDは、渡された文書にあるものだけを使ってください。新しい番号やIDを作らないでください。
- current には、文書の文字列をそのまま写してください。言い換え・要約をしないでください。
- 改訂案は、変更記録に書かれた変更の範囲だけを反映してください。
  変更記録に無い改善、望ましい手順、追加の統制を書かないでください。
- 「重要な変更に該当する」「再評価が必要」「統制は有効」など、評価や判断の結論を書かないでください。
  変わる要素を挙げるだけにしてください。
- 統制上の要点（Yes/No）の列を変える案を書かないでください。
- 変更記録の施行日・稼働日は、そのまま写してください。
- 文書に関わる箇所が見つからない場合に、無理に箇所を挙げないでください。

【変更記録】{change_record}
【過去の同種の変更記録と判断】{past_decisions}

（業務記述書とRCMの本文は、この指示の前に、キャッシュの対象となる前置きとして置きます。）

「変更記録に無い改善を書かない」を明記しないと、親切な改善案が混ざります。 内部統制の文書を渡すと、AIは文書を良くしようとして、手順の追加や統制の強化を提案します。禁じるのは、変更記録の外から案を作ることそのものです。

「無理に箇所を挙げない」も同じ理由です。 候補プロセスを渡されると、AIは何かしら関係のある箇所を探してきます。影響なしも正しい答えの1つだと、指示で認めておきます。

出力形式を固定する

Claude API の構造化出力で、次の形のJSONを受け取ります。

{
  "change_id": "CHG-2026-10-017",
  "process_id": "P05",
  "edits": [
    { "doc": "description | rcm",
      "location": "3.(2) | C05-012",
      "current": "",
      "proposed": "",
      "reason_quote": "",
      "control_changes": ["content | owner | frequency | type"] }
  ],
  "questions": [ "" ],
  "no_impact_reason": ""
}

1つ目の理由は、current を原文と照らせることです。 プログラムが current の文字列が渡した文書に含まれるかを確かめ、含まれなければ「引用不一致」の印を付けます。 公式の説明では、構造化出力は Citations と併用できず、両方を指定すると 400 のエラーになるとされています。引用の正しさは、プログラムの照合で担保します。 location の節の番号と統制IDも、文書に実在するかを同じく照らします。

2つ目は、control_changes で推進室の確認の順番を決められることです。 RCMの行で control_changes があり、その統制が統制上の要点（Yes）なら、推進室の確認の一覧の先頭に置きます。 統制上の要点かどうかはRCMの列から機械的に引き、AIには判断させません。

3つ目は、no_impact_reason で影響なしの根拠が残ることです。 edits が空なら no_impact_reason が必須、という規則をプログラムで確かめます。

公式の説明では、スキーマでは additionalProperties を false にする必要があり、オブジェクトの必須でない項目は必須の項目の後に並ぶとされています。並び順を固定したいので、全項目を必須にし、空のときは空の文字列や空の配列を返させます。 また、スキーマの複雑さには上限があるとされているので、edits の中を深く入れ子にしません。

システムへ連携する

文書そのものには書き込みません。 改訂は、担当部署の確認を経て推進室が行い、版を上げます。この構成が書くのは確認の一覧だけです。

変更記録の台帳にも書き戻しません。 「推進室で検討済み」の記録は、推進室の判断の記録の側に残します。

Claude API のデータの扱いは、公式の説明では、ゼロデータ保持（ZDR）の取り決めを結べば、応答の返却後にプロンプトと応答を保存しないとされ、Messages API はその対象です。文書は未公表の内部の情報なので、取り決めを結んだ組織で使い、ZDR の対象外の機能（バッチ処理、Files API など）は使いません。

人が確認する

全件を推進室の担当が確認します。 見る順番は、プログラムが付けた印で決めます。確認の一覧は、たとえば次の形にします。

一覧の1行目のような案が、推進室の時間を使うべきところです。 2行目以降は、案と理由を読んで採るか捨てるかを決めるだけで済みます。

1. 統制上の要点に効く案 … control_changes があり、RCMの統制上の要点が Yes のもの。整備状況の再評価の要否を、推進室の責任者と決めます
2. 引用不一致の案 … current や location が原文と合わないもの。原文で確かめ、案を直すか捨てます
3. 改訂案のある案 … 文面が変更記録の範囲に収まっているか。改善の書き足しが無いか
4. 影響なしの案 … no_impact_reason を読み、納得できれば影響なしとして判断の記録に残します

4番目を流さないでください。 影響なしの理由が「関係がない」の一言なら、AIが文書のどこも見ていない可能性があります。 理由が変更記録の具体的な記述に基づいているかを確かめます。

業務の担当部署の確認は省きません。 改訂案は文書の上での整合で、実際の業務がそう変わったかは担当部署にしか分かりません。

目標は、60件をならして1件20分です。 探す作業と書き起こす作業が案の確認に変わり、判断と担当部署とのやり取りが残ります。

例外に対処する

上の2行が大半を占めます。 どちらもAIの問題というより、対応表と文書の番号の整い方の問題です。対応表に無い変更記録が多い月は、評価の範囲の見直しのきっかけにもなります。

記録を残す

• 変更記録の一覧（経路、件名、施行日、所管部署）と、統合した重複
• 渡した文書の版の番号と、候補プロセス
• Claude API が返したJSONの全文、使ったモデル、cache_read_input_tokens
• 引用の照合の結果と、付けた印
• 推進室の判断 … 案を採ったか、直したか、捨てたか。影響なしとしたか。統制上の要点に効くとして再評価の要否をどう決めたか
• 担当部署の確認の日付と、改訂後の文書の版の番号

5つ目が、この構成で最も大事な記録です。 実施基準は、内部統制の整備及び運用状況を適切に記録・保存することを求めており、前年度の評価結果を継続して使う扱いも、前年度の整備状況と重要な変更が無いことを記録したうえでのものです。毎月の判断の記録が、その「重要な変更が無い」ことを示す材料になります。

最後の行は、いつから統制が変わったかを追うためのものです。 変更記録の施行日と文書の改訂の日を並べておけば、期中の評価のあとに変わった統制がどれかを、期末に一覧で出せます。