【クラウド法務】経営説明と監査説明を同じ資料でやってはいけない理由― “同じ事実”でも、求められるのは「決裁の材料」と「統制の証明」。混ぜると両方が壊れる ―

※本記事は一般的な情報提供であり、個別案件の法的助言ではありません。

────────────────────────────

はじめに

────────────────────────────

クラウド運用（Azure / M365 / Entra ID など）を回している情シスほど、こういう状況に心当たりがあるはずです。

・経営会議で「結局、今のリスクは何？投資はどれくらい必要？」と聞かれる

・監査で「統制が回っている証跡は？例外は期限管理してる？」と聞かれる

・どちらも同じ環境の話なのに、質問の角度がまるで違う

・資料作る時間がないので「同じ資料」でいける気がする

そして、こうなります。

経営向けに作ると…

「細かすぎて分からない」「結論は？何を決めればいい？」

監査向けに作ると…

「根拠と証跡が足りない」「その説明は“運用している”と言い切れない」

結論から言うと、経営説明と監査説明は、同じ資料でやってはいけません。

同じ資料にすると、だいたい「経営にも刺さらない」「監査にも通らない」中途半端なものになります。

さらに厄介なのは、“善意で書いた一文”が、後から説明責任（契約・監査・事故対応）を壊すことがある点です。

本記事では、なぜ同じ資料でやってはいけないのかを、

「技術的な整理 → 法務・説明責任の地雷 → 整理のフレーム → ケース → チェックリスト」

の順で、実務目線で整理します。

────────────────────────────

技術構成の“事実整理”：同じシステムでも「聞きたいこと」が違う

────────────────────────────

まず大前提として、経営と監査は「同じクラウド環境」を見ていても、見ているポイントが違います。

ここを混ぜると資料が崩れます。

典型的なクラウド環境（テキスト図）

【ID/IAM】Entra ID

・条件付きアクセス、MFA、PIM、監査ログ

　↓

【Azure/M365】

・VNet/NSG/Firewall/WAF

・VM/PaaS/Storage/Key Vault

・Backup/Site Recovery（BCP）

　↓

【ログ・証跡】

・Sign-in / Audit / Activity / Resource logs

・SIEM（Sentinel等）

　↓

【体制】

・自社（情シス/CSIRT/法務/経営）

・委託（SIer/MSP/SOC、再委託・海外SOC含む）

この環境について、経営と監査が知りたいことはこう分かれます。

経営が知りたいこと（意思決定の材料）

・事業インパクト：止まると何が起きるか、影響額や影響範囲

・優先順位：何から直すべきか（リスクの大きさ順）

・投資判断：コスト、体制、スケジュール、代替案

・責任：誰が最終的に説明する体制か（役割）

・約束：復旧は何時間で戻るのか（RTO/RPO）、外部要求への耐性

監査が知りたいこと（統制の証明）

・統制の存在：ルールがあるか（規程、手順）

・統制の運用：実際に回っているか（証跡、ログ、記録）

・例外の管理：期限・承認・解除の証跡があるか

・変更管理：承認と記録が残るか

・委託管理：再委託を含めて統制できているか（契約と監督）

・説明の裏付け：提出できる証跡があるか（提出期限や形式まで）

つまり、同じ事実を扱っていても、

経営＝「決めるための説明」

監査＝「証明するための説明」

です。

ここまでは技術の話。

ここからが法務・説明責任の地雷です。

“同じ資料”でやろうとすると、資料の中に

・決裁のための「結論」

・統制のための「根拠と証跡」

・運用のための「手順」

が混ざって、誰も必要な情報に辿り着けなくなります。

────────────────────────────

2. 経営説明と監査説明を同じ資料でやってはいけない理由（7つ）

────────────────────────────

ここから本題です。実務で破綻しやすい理由を7つにまとめます。

────────────────────────────

理由①：目的が真逆（経営＝意思決定、監査＝立証）

────────────────────────────

経営説明は「結論→判断材料→選択肢→意思決定」です。

監査説明は「根拠→証跡→運用→結論（適合/不適合）」です。

同じ資料にすると、

・経営：結論が見えない、長い、細かい

・監査：証跡が薄い、具体性がない、運用が証明できない

になります。

────────────────────────────

理由②：言葉の精度要求が違う（経営＝ざっくり、監査＝厳密）

────────────────────────────

経営向けには、分かりやすさのために表現を丸めがちです。

例（経営向けでは分かりやすいが、監査では危ない）

・「基本的に対応できています」

・「だいたい大丈夫です」

・「安全です」

・「SLAがあるので復旧できます」

監査では「基本的」「だいたい」が許されません。

何を、誰が、いつまでに、どの証跡で、が必要です。

同じ資料にすると、経営向けの“丸めた表現”が監査では弱点になります。

────────────────────────────

理由③：出す相手（配布範囲）と情報の危険度が違う

────────────────────────────

経営資料は、配布範囲が広がりがちです。

役員・経営企画・関連部門・親会社に回ることもあります。

監査資料も外部に出ることがありますが、ここで重要なのは逆で、

監査資料は「証明できる範囲」に絞って書ける一方、

運用の手順や例外の抜け道まで入れると危険です。

同じ資料にすると、どちらかが起きます。

・経営資料に、運用の抜け道・緊急手順など機密情報が混ざる（情報管理が危ない）

・監査資料に、経営向けの抽象表現が混ざる（証明として弱い）

────────────────────────────

理由④：時間軸が違う（経営＝今期/来期、監査＝過去の運用実績）

────────────────────────────

経営は「これからどうするか」を決めます。

監査は「過去に回っていたか」を確認します。

経営向けに必要なもの

・今の状態と、次の打ち手

・投資額と体制と期限

・判断が必要な論点（選択肢とトレードオフ）

監査向けに必要なもの

・すでに回っている証跡（棚卸し記録、承認記録、例外台帳、変更履歴など）

・例外が期限管理されている証明

・委託先が統制されている証明（SOW等）

同じ資料にすると、未来と過去が混ざって、説明がブレます。

────────────────────────────

理由⑤：責任の置き方が違う（経営＝最終責任、監査＝統制責任の分担）

────────────────────────────

経営説明では、「最終責任（Accountability）」が明確になっていることが重要です。

監査説明では、「統制の分担（RACI）」が明確になっていることが重要です。

同じ資料にすると、

・経営：誰が最終責任かが薄い（分担が細かすぎる）

・監査：分担が曖昧（最終責任者しか書いてない）

というズレが出ます。

────────────────────────────

理由⑥：更新頻度が違う（経営＝節目で更新、監査＝証跡が積み上がる）

────────────────────────────

経営資料は、四半期や投資判断の節目で更新が多いです。

監査資料は、運用の証跡が日々積み上がり、版管理が必要です。

同じ資料にすると、

・経営資料を更新するたびに監査の証跡部分が破綻

または

・監査の版管理が重くて経営資料がタイムリーに出せない

という矛盾が起きます。

────────────────────────────

理由⑦：一文が「約束」や「表明」になり、後から自社を縛る

────────────────────────────

これはクラウド法務の地雷です。

経営説明でよく書きがちな表現が、監査や取引先・事故対応の局面で「約束」「義務」扱いになることがあります。

例

・「24/7対応可能」

・「ログ提出対応可能」

・「復旧可能」

・「問題ありません」

経営会議での説明は“社内向けの理解促進”のつもりでも、

資料が回覧・転送・監査資料化すると、

「その前提で意思決定した」「書面で言っている」

になりやすい。

同じ資料にすると、言葉の扱いが危険になります。

「経営向けの分かりやすさ」と「監査向けの厳密さ」は、両立しません。分けるべきです。

────────────────────────────

3. 整理のフレーム：資料は「二つ＋橋渡し1枚」が最も事故りにくい

────────────────────────────

同じ資料で両方やるのではなく、役割を分けて“連携”させるのが現実解です。

おすすめは次の3点セットです。

・経営説明パック（Executive Pack）

・監査説明パック（Audit Pack）

・橋渡しシート（Bridge 1枚）

────────────────────────────

3-1. 経営説明パック（Executive Pack）に入れるべきもの

────────────────────────────

目的：経営が「何を決めればよいか」を最短で理解できること

構成（例：10〜15枚程度で十分）

結論（今期の論点と意思決定ポイント）

対象範囲（どの事業・どのシステム・どのクラウドか）

リスクの上位3〜5件（事業影響ベース）

現状とギャップ（何が足りないかを“言い切れる範囲で”）

選択肢（A案/B案、コスト・期間・リスクの比較）

投資額・体制（人、委託、運用負荷）

BCPの約束（RTO/RPOの目標と根拠の所在）

取引先・規制対応の観点（説明に必要な最低ライン）

決裁事項（承認してほしい事項を箇条書き）

次のアクション（期限と責任役割）

経営向けの書き方のコツ

・結論を先に書く（3行で）

・「SLA」と「復旧の約束（RTO/RPO）」を混ぜない

・“対応可能”など曖昧語を使わず、「前提条件つき」で書く

・詳細手順や例外の具体設定は入れない（必要なら別紙で管理）

────────────────────────────

3-2. 監査説明パック（Audit Pack）に入れるべきもの

────────────────────────────

目的：「統制が存在し、運用され、証明できる」ことを示す

構成（例：文章＋証跡目録でOK）

スコープ定義（対象システム、対象期間、委託範囲）

統制一覧（コントロールマトリクス）

タスク別RACI（通知・封じ込め・保全・提出・対外説明まで）

例外管理（例外台帳の運用ルール、期限、延長の再承認）

変更管理（承認・記録・緊急変更の事後追認）

ログ管理（対象ログ、保持期間、提出プロセス、抽出者記録）

委託管理（SOWの要点、再委託の範囲、監督の仕組み）

証跡目録（どの証跡をどこに、どの期間保管し、誰が提示するか）

監査向けの書き方のコツ

・「運用している」の根拠（記録）を必ず示す

・例外には必ず期限・承認・解除証跡がある前提にする

・“ふんわり表現”を避け、主語と期限を固定する

・監査資料に、危険な運用詳細（抜け道・緊急操作手順）を入れすぎない

　※監査資料は「統制の証明」、事故対応資料は「実行」。ここも混ぜない方が安全です

────────────────────────────

3-3. 橋渡しシート（Bridge 1枚）の役割

────────────────────────────

目的：経営の言葉と監査の言葉を繋ぎ、説明が割れないようにする

橋渡しシートに入れるもの（例）

・経営資料の各結論（例：ログ提出を強化する／特権を期限付きにする）

　→ 監査資料のどの統制項目に対応するか

　→ 証跡目録のどれが根拠になるか

・「経営向けに丸めた表現」を「監査で言い切れる表現」に変換した文言集

・用語の統一（SLA vs RTO/RPO、対応可能 vs 期限付き義務 など）

橋渡しがあると、

・経営には短く言える

・監査には厳密に言える

を両立できます。

────────────────────────────

4. ケーススタディ（匿名化）：同じ資料で説明しようとして両方で詰まったA社

────────────────────────────

（よくある構図を匿名化しています）

背景

・製造業A社：Azure＋M365運用

・監視はSOC、運用はMSP

・取引先審査と親会社監査が同時期に重なり、資料作成が逼迫

・情シスが「共通資料」を作成し、経営会議にも監査にも同じ資料を使用

起きたこと（経営側）

・詳細なログ種別や設定の話が多く、経営は「結論は何？何を決めればいい？」となる

・投資判断のポイント（リスク優先順位、コストと期限）がぼやける

・“対応可能”などの表現が残り、期待値が上がる

起きたこと（監査側）

・「対応可能」「運用している」など抽象表現が多く、証跡が不足

・例外の期限管理が資料上は語られているが、台帳と解除証跡が追いついていない

・委託先範囲が資料上は大きく見えるが、SOW上の義務が薄く整合しない

立て直し（方向性）

・経営説明パックを作り直し、意思決定ポイントに集中（結論・選択肢・投資・RTO/RPO）

・監査説明パックを作り直し、統制と証跡に集中（例外台帳、RACI、証跡目録、SOW要点）

・橋渡しシートで用語と主張を一致させる

・“対応可能”を、範囲・期限・成果物で言い換える（提出・保全・通知）

結果

・経営は「何を決めるか」が明確になり、投資判断が進む

・監査は「根拠と証跡」が揃い、指摘が収束する

・同じ事実を、別の目的で説明できる状態になった

────────────────────────────

5. 自社で確認できるチェックリスト

────────────────────────────

経営説明と監査説明を同じ資料で回してしまっている兆候は、次で判定できます。

□ 経営会議で「結局、何を決めればいい？」と言われる

□ 監査で「証跡は？」「例外の期限は？」が繰り返し聞かれる

□ 資料に“対応可能”“基本的に”“概ね”が多い

□ SLAの話と復旧の約束（RTO/RPO）が混ざっている

□ 例外（暫定開放、CA除外、常設特権）の台帳がない／期限がない

□ 委託（SOC/MSP）が絡むのに、SOWの義務と資料の説明がズレている

□ 経営資料に運用の危険情報（抜け道、緊急手順、連絡網）が載っている

□ 監査資料に意思決定の主張（安全です、問題ありません）が多く、根拠が薄い

□ 更新が追いつかず、最新版がどれか分からない

□ 経営・監査で言っていることが微妙に食い違う（用語・主語・期限）

YESが多い場合は、

「経営パック」「監査パック」「橋渡し1枚」

に分けるだけで、説明がかなり安定します。

────────────────────────────

6. まとめ：同じ資料にすると「決裁の材料」も「統制の証明」も失う

────────────────────────────

経営説明と監査説明を同じ資料でやってはいけない理由は、根本的に次が違うからです。

・目的（決める vs 証明する）

・言葉の精度（分かりやすさ vs 厳密さ）

・配布範囲と機密度（広く回る vs 証跡中心）

・時間軸（今後 vs 過去の実績）

・責任の示し方（最終責任 vs 統制の分担）

・更新の仕方（節目 vs 証跡の積み上げ）

・一文が「約束・表明」になって自社を縛るリスク

だから、

経営パック（意思決定）

監査パック（統制と証跡）

橋渡しシート（用語と主張の整合）

の3点セットが、最も事故りにくい現実解です。

────────────────────────────

7. 全国からのご相談について

────────────────────────────

山崎行政書士事務所では、Azure / M365 / Entra ID 等の技術構成と、契約・規程・監査対応をセットで整理し、

「経営には決裁の材料として」「監査には統制と証跡として」

同じ事実を矛盾なく説明できる形（経営パック／監査パック／橋渡しシート）に落とし込むクラウド法務支援を行っています。

・経営には短く説明したいが、監査では厳密に問われる

・“対応可能”が約束になってしまい、説明が怖い

・例外台帳、RACI、証跡目録、SOWの整合を取りたい

・取引先審査や親会社統制で、説明が割れ始めている

といったお悩みがあれば、オンライン（全国対応）でご相談を承っております。

お問い合わせの際に「経営説明と監査説明の記事を見た」と書いていただけるとスムーズです。