【クラウド法務】PoCが終わった瞬間に、説明責任が宙に浮く構造― “検証は成功”なのに、いざ本番で「誰が決めた？」「何を根拠に言い切る？」が消える理由 ―
- 山崎行政書士事務所
- 2025年12月26日
- 読了時間: 12分
※本記事は一般的な情報提供であり、個別案件の法的助言ではありません。
────────────────────────────
はじめに
────────────────────────────
PoC（概念実証）って、終わった瞬間は気持ちいいんです。
「動いた」「効果が見えた」「ユーザーの評判も良い」「ベンダーも前向き」。
情シスとしては、次は本番導入に向けて進めたい。
ところがPoCが終わって数週間〜数ヶ月後、取引先照会・親会社統制・監査・経営会議の場で、突然こう詰まります。
「その設計、誰が承認したの？」
「例外（暫定・除外）は期限管理している？」
「ログは何営業日以内に提出できる？保全（削除停止）は誰がやる？」
「委託先が触るなら、契約上どこまで義務？」
PoCのときは“うまく回っていた”のに、説明責任だけが宙に浮く。
本記事では、PoCが終わった瞬間に説明責任が宙に浮く構造を分解し、PoC→本番の間で「必ず橋をかけるべき成果物」を、実務で使える形に落とし込みます。
────────────────────────────
技術構成の“事実整理”：PoC環境で起きていること（そして本番では起きないこと）
────────────────────────────
PoCが説明責任を宙に浮かせやすいのは、PoCが「技術検証として合理的」な作り方をするほど、統制の要素が削られるからです。
典型的なPoCの構造を、あえて言語化します。
（PoCの典型構成：テキスト図）
【PoCスコープ】
・対象ユーザー：情シス＋一部部門（10〜100名）
・対象データ：ダミー／限定データ／一部本番データが混入しがち
・期間：2〜8週間
・運用：ベンダー同席／“その場で直す”が許される
↓
【環境】
・別テナント／別サブスク／検証用リソース
・権限：広め（検証速度優先）
・例外：多め（暫定開放・除外が許される）
↓
【ログ】
・集約はするが、提出期限・形式・保全手順は未定
・保持期間は短めでも困らない（“検証だから”）
↓
【資料】
・構成図／検証結果レポートはある
・責任分界（タスク別RACI）、例外台帳、証跡目録は無いことが多い
PoCは「速く学ぶ」ために、意図的に省くものが多い。
だからPoCでうまくいっても、本番でそのまま使えるとは限りません。
そして、PoCと本番の決定的な違いはここです。
PoC：動けば勝ち（仮説検証）
本番：動いて“説明できて”勝ち（契約・監査・事故対応を含む）
（ここまでは技術の話。ここからが法務・説明責任の話です。）
PoCは「動いたか」を証明する場で、
本番は「会社としてその運用を引き受けたこと」を説明する場です。
この差を埋める資料（成果物）が無いと、PoCが終わった瞬間に説明責任が宙に浮きます。
────────────────────────────
2. PoCが終わった瞬間に説明責任が宙に浮く“構造”（7つ）
────────────────────────────
PoCが終わった瞬間に起きる“説明責任の空白”は、だいたい次の7つで説明できます。
どれも担当者の頑張り不足ではなく、PoCの仕組み上そうなりやすいポイントです。
────────────────────────────
構造①：PoCの契約は「NDA止まり」で、運用の義務（通知・提出・保全）が存在しない
────────────────────────────
PoCは、契約が軽いことが多いです。
NDA（秘密保持）だけで走り、DPA（データ処理契約）や運用SOWが未整備なケースも珍しくありません。
その結果、PoCでは通ってしまう会話が、本番では通りません。
「ログ出せます」→ 何営業日以内？形式は？義務？
「24/7対応できます」→ 一次通知期限は？確約？ベストエフォート？
「保全できます」→ 削除停止は誰が実施し、抽出者記録は誰が残す？
PoCは“できるかどうか”の話で進みますが、
本番は“義務としてやるかどうか”が問われます。
義務の線引きが無いと、説明責任が宙に浮きます。
────────────────────────────
構造②：PoCは「ベンダー同席の現場最適」で回り、意思決定の主語が残らない
────────────────────────────
PoCでは、スピード優先でこうなります。
その場で設定変更
Teams/Slackで「一旦これで」
会議で「暫定で開けましょう」
ベンダーが“うまくやってくれる”
PoC中はそれで良い。
でも本番で問われるのは「誰が決めたか」です。
例外（除外・暫定開放）を承認したのは誰？
そのリスクを受ける意思決定は誰？
いつまでの期限で、解除条件は？
PoCで“意思決定の主語”を成果物化していないと、終了と同時に主語が消えます。
────────────────────────────
構造③：PoCは「例外が許される」ので、例外が制度化されずに恒久化する
────────────────────────────
PoCは例外を使って検証速度を上げます。
これは合理的ですが、本番で最も危険な置き土産になります。
典型例
条件付きアクセスの除外（PoCユーザーのため）
NSG/Firewallの暫定開放（切り分けのため）
常設に近い特権付与（検証が止まるから）
break-glassの運用が緩い（PoCだから）
PoCで許された例外が、そのまま本番に持ち込まれると、
「構成は正しいのに運用が危ない」状態になります。
例外台帳（期限・解除条件・補償統制）が無いと、説明責任は必ず崩れます。
────────────────────────────
構造④：PoCは「ログを集める」までで止まり、提出・保全・承認が決まらない
────────────────────────────
PoCの成果として「ログが取れた」「SIEMに入った」はよく出ます。
しかし本番で問われるのは、ログの“存在”ではなく“提出能力”です。
本番で必ず聞かれる質問
何営業日以内に提出できる？
提出形式は？（項目、時刻基準、マスキング）
誰の承認で外部提出する？
事故時にログ保全（削除停止・隔離）できる？
抽出者記録（いつ誰がどう取得したか）は残る？
PoCは「取れる」ことを証明し、本番は「出せる」ことを証明します。
この差が埋まらないと、説明責任が宙に浮きます。
────────────────────────────
構造⑤：PoCのスコープが曖昧なまま“本番の約束”に拡張される
────────────────────────────
PoCのスコープは本来小さいはずです。
しかし社内では、PoC成功＝本番でも同じ、と誤解されがちです。
対象ユーザーは？（PoCは一部、本番は全社）
対象データは？（PoCは限定、本番は個人情報・機微情報が混ざる）
拠点は？（PoCは国内、本番は海外拠点・子会社を含む）
委託範囲は？（PoCは同席、本番は遠隔・再委託含む）
PoCの範囲と本番の範囲が曖昧なまま走ると、
説明する側は「どこまで言い切って良いか」が分からず、回答が遅れます。
これも説明責任の空白です。
────────────────────────────
構造⑥：PoCの成果物が「構成図と結果レポート」だけで、監査・照会の“部品”がない
────────────────────────────
PoCの納品物は、だいたい次です。
構成図
検証項目と結果
効果（改善点、期待値）
しかし監査・取引先照会で必要なのは別です。
タスク別RACI（誰が何をするか）
例外台帳（期限・解除・補償統制）
証跡目録（どこに何があるか）
ログ提出・保全パック（提出期限・形式・承認）
委託管理サマリ（SOW要点：義務の所在）
この“説明の部品”が無いと、PoC終了と同時に説明責任が宙に浮きます。
────────────────────────────
構造⑦：PoC終了後に「データ・権限・設定の後片付け」が未定義
────────────────────────────
意外と見落とされるのがここです。
PoC終了後、次が曖昧なまま残りがちです。
PoC環境に残ったデータは削除されるのか（証明は？）
ベンダーのアクセス権は剥奪されるのか（いつ？証跡は？）
PoCテナント／サブスクの資産はどう扱うのか（本番移管？廃棄？）
検証で作った例外設定は戻すのか（期限・解除条件は？）
PoCが終わった瞬間に「次の管理者」がいないと、説明責任は完全に宙に浮きます。
────────────────────────────
3. 法務・説明責任の地雷：PoC成功が“後で効く”3つのポイント
────────────────────────────
PoC成功が後で地雷になるのは、次の3箇所です。
ここだけ押さえると、PoC→本番の移行がかなり安全になります。
────────────────────────────
地雷①：「対応可能」という言葉が“約束”として引用される
────────────────────────────
PoCの場では「対応可能」「できます」は前向きな言葉です。
しかし本番では、それが“約束”として扱われます。
いつまでに？
誰が？
何を成果物として？
義務？ベストエフォート？
PoC資料に曖昧語が多いほど、本番で苦しくなります。
────────────────────────────
地雷②：SLAとRTO/RPOが混ざり、復旧説明が崩れる
────────────────────────────
PoCは「SLAがあるから大丈夫」と言いがちです。
しかし本番で必要なのは、復旧の約束（RTO/RPO）と、その根拠（手順・テスト記録）です。
SLA＝稼働率
RTO/RPO＝復旧目標（自社の設計・運用の話）
ここを混ぜると、経営・取引先・監査への説明が崩れます。
────────────────────────────
地雷③：委託・再委託が絡むと材料が集まらず、期限内に答えられない
────────────────────────────
PoCではベンダーが近くにいて、材料がすぐ集まります。
本番では、SOC/MSP/再委託（海外SOC含む）から材料を集める必要が出ます。
SOWで成果物（通知・提出・保全・記録提供）が義務化されていないと、
「期限内に答えられない」＝説明責任が崩れる
になります。
────────────────────────────
4. 対策のフレーム：PoC→本番で“説明責任を宙に浮かせない”ための6点セット
────────────────────────────
PoCが終わった瞬間に説明責任が宙に浮くのは、橋が無いからです。
橋を作るための最小セットを「6点セット」として提示します。
（これがある会社は、本番導入が荒れにくいです）
────────────────────────────
① PoCスコープシート（1枚）＋本番想定スコープ（1枚）
────────────────────────────
PoCの範囲と本番の範囲を、別紙で切り分けます。
PoC：対象ユーザー、対象データ、対象拠点、期間、委託関与
本番：対象範囲の増分（海外拠点、子会社、個人情報、重要業務）
「PoCの成功」を「本番の約束」に誤変換させないための土台です。
────────────────────────────
② タスク別RACI（1枚）
────────────────────────────
レイヤー（Microsoft/ベンダー/自社）ではなく、タスクで主語を固定します。
最低限入れるタスク
一次通知（検知から何分以内、誰が誰へ）
封じ込め（権限剥奪・通信遮断：判断者と実行者）
ログ保全（削除停止・隔離・抽出者記録）
ログ提出（期限・形式・承認・提出者）
復旧判断（BCP発動、切替の決裁）
対外説明（文面承認）
例外承認／延長／解除
委託先管理（再委託含む）
A（最終責任）を個人ではなく役割名で固定するのがコツです。
────────────────────────────
③ 例外台帳（Exception Register）
────────────────────────────
PoC中に出た例外は、必ず台帳化して本番へ持ち込むか廃止するか決めます。
必須項目
例外ID（チケット）
対象（CAポリシー名、NSG名、ロール名等）
例外内容（何を緩めたか）
理由（当時の事情：一文でOK）
承認者（役割）
期限（必須）
解除条件（何が終われば戻すか）
補償統制（例外中の守り）
解除完了証跡（いつ誰が戻したか）
PoCの“暫定”は、台帳が無いと100%恒久化します。
────────────────────────────
④ 証跡目録（Evidence Index）＋ログ提出・保全パック
────────────────────────────
「ログが取れる」から「出せる・保全できる」に変換します。
ログ提出・保全パックの最小項目
対象ログ一覧
保持期間（監査・契約要件との整合）
提出期限（何営業日以内）
提出形式（項目、時刻基準、マスキング）
外部提出の承認者（役割）
抽出者記録（いつ誰がどう取得したか）
保全手順（削除停止・隔離・アクセス制限）
これがあると、PoC成功が「説明可能な運用」になります。
────────────────────────────
⑤ Decision Log（判断ログ）
────────────────────────────
PoCで行った重要判断を、短くていいので残します。
最低限の書き方
何を決めたか
なぜそうしたか（代替案も一言）
誰が承認したか（役割）
期限と見直し条件
影響範囲
関連する証跡・台帳
“当時の判断”が思い出のままだと、本番で必ず詰みます。
────────────────────────────
⑥ PoC終了時の「出口パック」（データ・権限・環境の後片付け）
────────────────────────────
PoC終了時に必ず決めることを成果物化します。
PoC環境のデータの扱い（削除／移管／匿名化、証明の有無）
ベンダーアクセスの剥奪（いつ誰が、証跡は）
PoC環境の資産（廃棄／本番移管／隔離保管）
PoC例外の戻し（いつ、誰が、解除証跡）
これが無いと、PoC終了後に「管理されない領域」が生まれます。
説明責任が宙に浮く最大要因です。
────────────────────────────
5. ケーススタディ（匿名化）：PoC成功後に監査で詰んだA社の話
────────────────────────────
（よくある構図を匿名化しています）
背景
業種：製造業
拠点：日本＋海外
テーマ：M365/Entra ID の強化＋ログ統合（SIEM）PoC
PoC結果：技術的には成功、現場評価も高い
PoC後に起きたこと
親会社監査で「ログ提出は何営業日以内？」「保全は？」「例外は期限管理？」の質問
取引先照会で「委託先が触る範囲と義務は？」を要求
PoC中に作ったCA除外や暫定設定が残っていたが、理由・期限が追えない
ログは集約していたが、提出形式・承認・抽出者記録が未整備
委託先はPoC中は協力的だったが、本番の義務（SOW）が薄く材料が集まらない
結果
技術は動いているのに、「説明が通らない」状態になり、会議が増え、回答が遅れた
立て直し（方向性）
PoCと本番のスコープを分離し、説明の前提を固定
タスク別RACIで主語を固定（提出・保全・例外・承認）
例外台帳とDecision Logで“当時の判断”を成果物化
ログ提出・保全パックを定義（期限・形式・承認・証跡）
SOWを更新し、通知・提出・保全協力・記録提供を義務化
PoC環境の出口（アクセス剥奪、データ取扱い、環境廃棄）を確定
結果として
本番移行後の監査・照会で、質問が深掘りされにくくなり、対応が安定した
という流れです。
────────────────────────────
6. 自社で検討するときのチェックリスト（PoC後に説明責任が宙に浮く兆候）
────────────────────────────
PoCが終わった後、次のYESが増えているほど危険です。
【スコープ】
□ PoCの対象範囲（ユーザー・データ・拠点・期間）が1枚で説明できない
□ PoC成功がそのまま本番の約束として扱われ始めている
【主語（責任分界）】
□ 一次通知・封じ込め・保全・提出・対外説明の主語が決まっていない
□ レイヤー説明（Microsoft/ベンダー/自社）で止まり、タスク別RACIがない
【例外】
□ PoC中に入れた除外・暫定開放・常設権限が残っている
□ 例外に期限・解除条件・補償統制が無い
□ 「忙しいから後で」が恒久化している
【ログ（提出・保全）】
□ 「ログは取れている」が「何営業日以内に提出できる」に変換されていない
□ 提出形式（項目・時刻基準・マスキング）と承認者が決まっていない
□ 保全（削除停止・隔離）と抽出者記録が整っていない
【委託・契約】
□ PoCは協力的だったが、本番SOWで通知・提出・保全協力が義務化されていない
□ 再委託（国外・海外SOC）の範囲と監督責任が説明できない
【出口（後片付け）】
□ PoC環境のデータ削除・権限剥奪・資産廃棄のルールが決まっていない
□ 「PoCは終わったのに、誰が管理者か分からない領域」が残っている
YESが多い場合、PoCの成功と同時に“説明責任の負債”が増えています。
本番導入を進める前に、橋（成果物）を置いた方が安全です。
────────────────────────────
7. まとめ：PoC成功の次に必要なのは「PoC→本番の橋（主語・期限・証跡）」
────────────────────────────
PoCが終わった瞬間に説明責任が宙に浮くのは、PoCが悪いからではありません。
PoCが「速く学ぶ」ために、意図的に統制要素を省いているからです。
だから本番に進むときは、PoCの勢いのまま構成を固めるのではなく、
次の橋をかける必要があります。
PoCスコープと本番スコープの分離
タスク別RACI（主語の固定）
例外台帳（期限・解除・補償統制）
証跡目録＋ログ提出・保全パック（言い切りの根拠）
Decision Log（当時の判断を成果物化）
出口パック（データ・権限・環境の後片付け）
これが揃うと、PoC成功が「説明できる運用」へ変換され、
監査・取引先照会・経営説明で詰まらなくなります。
────────────────────────────
8. 全国からのご相談について
────────────────────────────
山崎行政書士事務所では、Azure / M365 / Entra ID 等の技術構成と、契約・規程・監査対応をセットで整理し、
PoC成功後に説明責任が宙に浮かないよう、PoC→本番の橋（RACI／例外台帳／証跡パック／Decision Log／SOW整合／出口パック）まで落とし込む「クラウド法務支援」を行っています。
PoCは成功したが、監査・取引先照会の説明が不安
ベンダー同席の運用から抜けた途端、主語が割れそう
ログ提出・保全を期限付きで言い切れる形にしたい
例外（暫定・除外・常設）がPoCの置き土産になっている
本番SOWに通知・提出・保全協力を義務として落としたい
といったお悩みがあれば、オンライン（全国対応）でご相談を承っております。
お問い合わせの際に「PoCが終わった瞬間の記事を見た」と書いていただけるとスムーズです。
コメント