【クラウド法務】「一覧にある＝管理できている」と誤解される瞬間― “エクスポートしただけの一覧”が、監査・取引先・経営の場で「統制できている前提」に化ける ―

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

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

はじめに

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

情シス・クラウド担当の方ほど、こういう場面に心当たりがあるはずです。

「大丈夫です。一覧はあります」

「全部、Excelに出してあります」

「ポータルからエクスポートできます」

この時点では、現場は“安心材料”として言っています。

ところが、監査・親会社統制・取引先審査・事故対応の局面では、相手が同じ言葉を別の意味で受け取ります。

“一覧がある＝管理できている（統制されている）”

“つまり、責任者も、期限も、是正も、証跡も揃っているはず”

そして、質問が変わります。

「その一覧の各項目は、誰がオーナーですか？」

「期限切れはどう検知して、誰がいつ直すんですか？」

「例外は台帳で管理していますか？承認者と期限は？」

「事故が起きたら、保全（削除停止）できますか？提出は何営業日以内？」

ここで、“一覧はある”のに説明できない状態が発生します。

この瞬間が、「一覧にある＝管理できている」と誤解される瞬間です。

本記事では、なぜこの誤解が起きるのか、どこが法務・説明責任の地雷なのか、そして「一覧」を「管理できる台帳」に変えるための整理方法をまとめます。

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

技術構成の“事実整理”：現場が言う「一覧」と、外部が求める「管理」は別物

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

まず、技術現場で言う「一覧」は、だいたい次のどれかです。

よくある「一覧」例（クラウド運用で頻出）

・NSGルール一覧（許可/拒否、ポート、送信元/宛先）

・条件付きアクセスのポリシー一覧／除外対象一覧

・RBACロール割り当て一覧（誰がどの権限を持つか）

・PIMのアクティベーション履歴一覧

・Key VaultのSecrets/Keys/Certificates一覧

・バックアップ対象一覧（Azure Backup）／保護ポリシー一覧

・ログ設定一覧（診断設定、SIEM転送設定、保持期間）

・委託先アカウント一覧（MSP/SOC作業者）

・サブスクリプション／リソース一覧（棚卸しエクスポート）

これらは「今の状態」を写したスナップショットです。

技術的には極めて重要で、無いと話になりません。

しかし、監査・取引先・経営が求める「管理（統制）」は、次の要素を含みます。

外部が求める「管理（統制）」の中身

・誰が責任者か（主語）

・いつまでにどうするか（期限と是正）

・例外はどう扱うか（承認・期限・補償統制）

・変更はどう決めるか（承認・記録）

・事故時に何ができるか（保全・提出・復旧）

・委託が絡むなら、義務として担保されているか（SOW）

つまり、

一覧＝状態（State）

管理＝状態＋運用＋責任＋証跡（Governance）

です。

（ここまでは技術の話。ここからが法務・説明責任の話です。）

「一覧はあります」は、外部から見ると

「統制できています」

に勝手に変換されます。

この変換が起きた瞬間、説明の要求レベルが上がり、詰みやすくなります。

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

2. 「一覧にある＝管理できている」と誤解される“瞬間”はいつ来るか

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

誤解は、いきなりは起きません。だいたい次の場面で一気に発生します。

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

瞬間①：監査・親会社統制で「根拠資料をください」と言われたとき

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

監査は「一覧」を“証跡の入口”として見ます。

一覧が出た瞬間に、次の質問が来ます。

・この一覧は誰が維持していますか

・更新頻度は？最終更新日は？

・差分（変更）は追えますか

・例外はどこにありますか

・期限切れはどう検知しますか

一覧は「ある」ことが評価ではなく、維持・是正・証跡の説明がセットで求められます。

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

瞬間②：取引先のセキュリティチェックで「運用は回っていますか？」に変わったとき

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

成熟した取引先ほど、構成より運用を見ます。

・権限の棚卸しは何ヶ月ごと？

・例外（除外ユーザー、暫定開放）は期限管理してる？

・事故時のログ提出は何営業日以内？

・委託先が触るなら、特権アクセス統制は？

一覧を出した瞬間に「運用してる前提」に入るため、説明が壊れやすいです。

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

瞬間③：事故後に「その設定は誰が決めたのか？」と問われたとき

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

事故後は、一覧が“犯人探し”の材料になるのではなく、

「意思決定と統制があったか」を問う材料になります。

・誰が承認した例外だったか

・期限はあったか

・補償統制は実施されていたか

・是正のフローが回っていたか

一覧だけだと、ここが説明できません。

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

瞬間④：委託先・ベンダーが絡み、「誰が何をする義務なのか？」に変わったとき

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

一覧を出すと、相手はこう解釈します。

「じゃあ、その一覧にある項目について、委託先も含めて運用責任は回っているはず」

しかし実務では、委託契約（SOW）が薄いと、

・棚卸しは契約外

・是正は別料金

・期限管理はしない

・提出協力はベストエフォート

などで詰まります。

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

3. 「一覧」が“管理”になっていない組織の共通点（6つ）

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

一覧があるのに管理できていない組織には、共通する欠落があります。技術の弱さではなく、運用の設計不足です。

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

共通点①：一覧に「オーナー（責任者）」の列がない

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

一覧が“資産の羅列”になっている状態です。

誰も責任を持たないものは、直されません。

例

・Key VaultのSecretが100件あるが、所有者不明

・RBACの権限が割り当てられているが、付与理由が不明

・条件付きアクセス除外があるが、承認者が不明

ここがあると「台帳」になり始めます。ないと「ただの一覧」です。

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

共通点②：期限（有効期限・レビュー期限・解除期限）が入っていない

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

期限がない項目は、必ず恒久化します。

恒久化すると、監査・取引先・事故で説明が破綻します。

例

・暫定開放、暫定除外、暫定常設権限が残り続ける

・証明書やシークレットが期限切れして障害になる

・ログ保持期間が“なんとなく”で、提出要求に耐えない

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

共通点③：一覧に「例外」が統合されていない（例外台帳が別にない）

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

一覧に載っているのは“正規の状態”で、例外はチャットや口頭に残る。

これが一番危険です。

・NSGの暫定開放

・条件付きアクセス除外

・PIMを使わない常設特権

・ベンダー作業の抜け道

例外を台帳化していない組織は、一覧が立派なほど「抜け道」が見えず、事故の芽になります。

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

共通点④：一覧は作るが、「NOの是正」が運用として存在しない

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

棚卸ししても直らない組織です。

・期限切れが見つかっても、担当が決まらない

・危険な権限が見つかっても、誰も剥奪しない

・例外が残っていても、解除の計画がない

チェックはあるのに事故が起きる組織は、だいたいここです。

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

共通点⑤：変更が速いのに、一覧が“スナップショット”のまま固定される

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

クラウドは変化が速いです。

月次で一覧を更新しても、週次・日次で変わる環境では追いつきません。

必要なのは、一覧そのものではなく、

・変更が起きたときに更新が走る仕組み

・差分が残る仕組み

・承認と記録の仕組み

です。

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

共通点⑥：委託先が関与するのに、SOWに「台帳維持・棚卸し・是正」が義務化されていない

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

委託先が実行できても、義務でないと最後は残りません。

・棚卸しは契約外

・是正は別見積

・例外管理は想定外

・提出期限は確約しない

これだと、一覧はあっても「管理」は成立しません。

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

4. 整理のフレーム：「一覧」を「管理できる台帳」に変える3つの軸

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

ここからが実務の解き方です。

一覧を否定しません。むしろ一覧は必要です。

ただし、一覧を“台帳”に変換します。

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

整理軸①：一覧に「主語（Owner/RACI）」を足す

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

最低限、次のどれかを入れます。

・Owner（資産の責任者：誰が最終的に説明するか）

・Custodian（運用担当：誰が手を動かすか）

・Approver（例外/変更の承認者：誰がリスクを受けるか）

さらに強くするなら、RACIで固定します。

（R=実行/A=最終責任/C=相談/I=共有）

“誰がやるのか問題”が解けると、一覧が管理に変わります。

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

整理軸②：期限と「終わらせ方」を足す（Expiry＋Review＋Exit）

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

台帳が台帳になる最短ルートは、期限です。

必須にしたい期限

・有効期限（証明書、シークレット、例外除外など）

・レビュー期限（四半期ごとの棚卸し日など）

・解除期限（暫定をいつ終わらせるか）

さらに「解除条件（終わらせ方）」も必須です。

・何が終われば元に戻すか

・戻した証跡（いつ誰が解除したか）

ここが入ると、例外の恒久化が止まります。

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

整理軸③：「是正」の運用を台帳に埋め込む（発見→判断→修正→証跡）

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

台帳に、NOが出たときの動線を埋め込みます。

・状態（OK/要是正/例外申請中/廃止予定）

・是正期限（いつまでに）

・是正チケットID（根拠）

・是正内容（何をどう直すか）

・完了証跡（誰が、いつ、何をしたか）

これがあると、台帳が“棚卸しで終わらない”仕組みになります。

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

5. そのまま使える：台帳に最低限入れる「列」テンプレ

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

「台帳にする」と言っても、最初から完璧を目指すと止まります。

まずは最低限の列で回すのが現実的です。

（汎用：台帳の最小列）

・ID（チケット番号など）

・対象（例：NSG名/CAポリシー名/Secret名/ロール名）

・分類（原則/例外/暫定、または資産種別）

・目的（何のために必要か）

・Owner（最終責任者：役割名でOK）

・承認者（例外・変更の承認）

・開始日

・期限（必須）

・解除条件（どうなったら終わるか）

・補償統制（例外中の守り：監視強化、送信元限定等）

・次回レビュー日

・ステータス（OK/要是正/例外延長申請中など）

・是正チケットID（変更・是正の根拠）

・完了証跡（解除/是正の実施日・実施者）

「一覧にある」から「管理できている」に寄せるなら、まずこの形が効きます。

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

6. ケーススタディ（匿名化）：「一覧はあるのに説明できない」が起きたA社

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

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

背景

・Azure＋M365運用

・権限一覧、NSG一覧、条件付きアクセス一覧、Key Vault一覧はエクスポート済み

・監視はSOC、運用はMSPに委託

取引先審査で詰まった質問

・条件付きアクセスの除外は「誰が承認し、期限管理していますか？」

・委託先の特権アクセスは「期限付きで剥奪証跡がありますか？」

・ログ提出は「何営業日以内に、どの形式で提出できますか？」

・事故時のログ保全は「誰が削除停止をやりますか？」

なぜ詰んだか

・一覧にOwner/承認者/期限がなく、「管理」になっていなかった

・例外（除外・暫定）が台帳化されておらず、解除計画がない

・SOWに台帳維持・是正・提出協力が期限付き義務として落ちていない

立て直し（方向性）

・一覧に責任者と期限を足して「台帳化」

・例外台帳を作り、除外は期限必須・延長は再承認へ

・ログ提出と保全を「期限付き成果物」として定義（抽出者記録含む）

・委託契約（SOW）に、台帳更新・棚卸し・是正・提出協力を明記

結果

・「一覧はあります」ではなく「統制しています」と言えるようになり、審査の質疑が収束した

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

7. いまの「一覧」が危ないか分かるチェックリスト

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

あなたの一覧が「管理できている台帳」になっているか、これで判定できます。

□ 各行にOwner（最終責任者）がある

□ 例外・暫定が同じ台帳で追える（または例外台帳が別で存在する）

□ 期限が必ず入っている（期限なし例外は原則作らない）

□ 解除条件と解除担当が決まっている

□ 期限切れ・要是正が出たときの是正期限がある

□ 是正チケットID（根拠）が紐づく

□ 解除・是正の完了証跡（実施日・実施者）が残る

□ 台帳の更新頻度と責任者が決まっている

□ 委託先が関わる場合、台帳更新・是正・提出協力がSOWで義務化されている

□ 取引先・監査に「この台帳で統制しています」と説明できる

YESが少ない場合、一覧は“存在”しても、管理（統制）は成立していない可能性が高いです。

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

8. まとめ：一覧は「入口」。管理は「主語・期限・是正・証跡」で決まる

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

「一覧にある＝管理できている」と誤解される瞬間は、

相手が一覧を“統制の証明”として扱い始めた瞬間です。

一覧は必要です。

ただ、一覧のままだと「状態の説明」しかできません。

管理（統制）として説明するには、次が必要です。

・主語（Owner/RACI）

・期限（Expiry/Review/Exit）

・是正の動線（NOを直す仕組み）

・証跡（承認・変更・解除の記録）

・委託が絡むならSOWで義務化

これが揃うと、一覧は“守りの資料”ではなく、“説明できる運用の武器”になります。

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

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

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

山崎行政書士事務所では、Azure / M365 / Entra ID 等の運用において、

「一覧はあるが管理できていない」状態を、責任分界（RACI）・期限付き台帳・例外運用・委託契約（SOW）まで含めて整理し、監査・取引先・事故対応で説明が通る形に整えるクラウド法務支援を行っています。

・棚卸しの一覧はあるが、Ownerと期限がなく恒久化している

・例外（NSG暫定開放、CA除外、常設特権）が増えて説明が危ない

・委託先が絡むと、是正や提出が「契約外」になりがち

・ログ提出・保全を“期限付き成果物”として固めたい

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

お問い合わせの際に「一覧＝管理の誤解の記事を見た」と書いていただけるとスムーズです。