【クラウド法務】「その人しか触れない設定」が増えたときの危険信号― “属人化”は技術課題ではなく、監査・事故対応・委託管理で一気に表面化する「説明責任の爆弾」 ―

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

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

はじめに

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

クラウド運用（Azure / M365 / Entra ID）を回していると、いつの間にか増えてくるものがあります。

それが「その人しか触れない設定」です。

・ネットワークの肝（NSG/Firewall/WAF）はAさんだけが分かる

・条件付きアクセスの例外はBさんが“暗黙で”調整している

・Key Vaultの中身はCさんの頭の中にしかない

・緊急時のbreak-glassはDさんしか開け方を知らない

・委託先とのやり取りはEさんのTeamsにしか履歴がない

普段は「詳しい人がいて助かる」で済みます。

しかし、担当者交代・監査・取引先審査・事故対応のタイミングで、一気に空気が変わります。

「その設定は誰が決めたんですか？」

「なぜその例外を許したんですか？期限は？」

「事故のとき、誰が止める判断をしますか？」

「ログ保全（削除停止）は誰がやるんですか？」

「委託先に任せているなら、契約上の義務は？」

この質問に、技術資料では答えられません。

属人化の怖さは「作業が遅れる」ではなく、説明責任が崩れることです。

本記事では、「その人しか触れない設定」が増えたときの危険信号を、

「共感 → 技術的整理 → 法務の地雷 → 対策フレーム → 具体例 → チェックリスト → 相談導線」

の順で整理します。

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

技術構成の“事実整理”：「その人しか触れない」とは何が起きている状態か

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

まず、「その人しか触れない設定」と言ったとき、実務では大きく3パターンあります。

ここを混ぜると対策がズレます。

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

パターンA：権限が一人にしかない（アクセスできない属人化）

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

例

・特定のロールが一人にしか割り当てられていない

・PIMの承認者が一人しかいない

・緊急アカウントの管理が一人だけ

・鍵/証明書の更新権限が一人だけ

これは「物理的に触れない」状態です。

一番分かりやすい危険です。

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

パターンB：権限はあるが、手順や影響が分からない（運用知識の属人化）

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

例

・NSGルールを触ると何が落ちるか分かるのが一人

・CAポリシーを変えたらどの部署が止まるか分かるのが一人

・Key VaultのどのSecretが何に使われているか分かるのが一人

・ログ提出のやり方（どこから何を出すか）が一人

「触れるけど怖くて触れない」状態。

これが一番多いです。

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

パターンC：意思決定が一人に寄っている（承認・責任の属人化）

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

例

・例外を出す／延長する判断が一人に集中

・緊急変更の事後追認が一人だけ

・委託先への依頼や優先順位の判断が一人だけ

・事故時の封じ込め（止める/止めない）判断が一人だけ

ここが属人化すると、監査・事故対応で致命傷になります。

なぜなら、これは「作業」ではなく 会社としての意思決定（リスク受容） だからです。

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

「その人しか触れない設定」が増えている状態は、

単に“スキルが偏っている”のではなく、

責任の所在（主語）・期限・証跡が、個人に張り付いている状態です。

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

2. よくある“法務・説明責任”の地雷：属人化が事故に変わる3つの瞬間

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

属人化が本当に危険になるのは、次の3つの瞬間です。

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

瞬間①：担当者が不在になった瞬間（異動・退職・長期休暇・病欠）

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

この瞬間に起きるのは「作業が止まる」だけではありません。

・例外の期限切れが来ても延長/解除できない

・証明書/シークレット更新で詰まる

・委託先が「承認者がいないと動けない」と止まる

・事故時に「止める判断」ができない

結果として、

“技術的には軽微な事象”が、

“経営案件（信用・取引・監査）”に化けます。

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

瞬間②：監査・取引先が「体制」を見に来た瞬間

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

技術の説明ではなく、こう聞かれます。

「その設定変更の承認プロセスは？」

「職務分掌（分離）はできていますか？」

「権限の棚卸しは？誰が是正しますか？」

「例外（暫定・除外）は台帳で期限管理していますか？」

ここで「その人がやってます」と言った瞬間、

相手の頭の中では「統制できていない」に近い評価になります。

属人化は“統制不備”として扱われやすいからです。

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

瞬間③：事故が起きて「誰が決めたか」を問われた瞬間

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

事故後は設定の良し悪しより、次が問われます。

・誰が、何を、なぜ、いつ決めたか

・どんな代替案を検討したか

・例外なら、期限と解除条件はあったか

・証跡（ログ・保全記録）は残っているか

・委託先を含めた責任分界は明確か

ここで「当時の担当が…」が通らなくなります。

“当時の判断”が台帳と証跡になっていないと、説明が破綻します。

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

3. 「その人しか触れない設定」が増えたときの危険信号（実務で効く10項目）

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

ここからが本題です。

次のうち3つ以上当てはまったら、属人化は“危険域”に入っています。

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

危険信号①：変更の前に「その人に聞かないと怖い」が常態化している

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

権限がなくて触れないのではなく、影響が分からず触れない。

運用知識が一人に寄っています。

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

危険信号②：PIMの承認者が固定の1名、または実質1名になっている

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

承認者が一人しかいないと、

不在＝特権が出せない／緊急対応できない

という単純な事故になります。

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

危険信号③：break-glassが“緊急用”ではなく“便利な近道”になっている

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

緊急アカウントが日常運用に混ざり始めると、

統制の説明が一気に難しくなります。

（しかも、その運用を知っているのが一人になりがちです。）

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

危険信号④：例外（NSG暫定開放、CA除外、常設特権）が「台帳なし」で増えている

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

属人化の最終形態は「例外の恒久化」です。

例外を把握している人がいなくなった瞬間に、爆弾化します。

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

危険信号⑤：Key VaultのSecrets/Keys/Certificatesの棚卸しが「一覧」止まり

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

一覧はあるが、

・所有者（Owner）

・用途

・重要度

・期限

・更新手順

が紐づいていない。

結果、「触れない設定」の温床になります。

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

危険信号⑥：ログは集約しているのに「提出・保全」の手順が担当者依存

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

事故や取引先照会で必要な、

・削除停止（保全）

・抽出者記録

・提出形式

・提出期限

が“その人のやり方”になっている状態です。

この属人化は説明責任を直接壊します。

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

危険信号⑦：委託先の作業が「その人の関係性」で回っている

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

旧担当の「お願い」が通っているだけで、

契約（SOW）上の義務として固まっていない。

担当が変わると突然「契約外です」になります。

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

危険信号⑧：緊急変更の事後追認が“形式”になり、承認者が実質1名

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

緊急変更は属人化しやすいです。

「結局いつも同じ人が判を押す」状態は、

意思決定の属人化＝責任の属人化です。

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

危険信号⑨：設定の根拠が「当時の事情」でしか語れない

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

「当時はこうだった」

「移行中で」

が口癖になり、台帳や記録がない状態。

時間が経つほど説明不能になります。

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

危険信号⑩：障害・事故の初動で「その人に連絡しないと始まらない」

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

初動30分で、指揮・封じ込め・保全が動かない。

これは属人化が“事業リスク”に変わっているサインです。

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

4. 対策のフレーム：属人化を「悪」ではなく「統制できる形」に変える

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

属人化をゼロにするのは現実的ではありません。

重要なのは、属人化が事故にならない形に“変換”することです。

おすすめは次の3つです。

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

フレーム①：「触れる人」を増やすのではなく「主語（責任）」を役割に固定する（タスク別RACI）

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

誰が触れるかより先に、誰が責任者かを固定します。

最低限作るべきRACI（事故対応まで）

・一次通知（検知から何分以内、誰が誰へ）

・封じ込め（権限剥奪・通信遮断：判断者と実行者）

・ログ保全（削除停止・隔離・抽出者記録）

・ログ提出（何営業日以内、形式、承認者）

・復旧判断（BCP発動、切替の決裁）

・対外説明（文面承認者）

・例外の承認・延長・解除

・委託先管理（再委託含む）

ポイント

A（最終責任者）を個人名ではなく役割名で置く。

担当者が変わっても主語が残ります。

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

フレーム②：「その人しか分からない」を台帳に落とす（例外台帳＋資産台帳）

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

属人化は、だいたい台帳がない場所に生まれます。

台帳は“一覧”ではなく、次を含む必要があります。

台帳に必須の列

・Owner（所有者）

・用途

・重要度

・期限（有効期限／レビュー期限）

・変更/更新の手順（どこを触るか）

・例外なら、承認者・期限・解除条件・補償統制

・完了証跡（いつ誰が更新/解除したか）

「一覧にある＝管理できている」ではありません。

「Ownerと期限と是正がある＝管理できている」です。

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

フレーム③：「委託先に任せている」を“義務として担保”する（SOWの更新）

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

属人化が委託先に寄っている場合、技術で解けません。契約です。

SOWで固めたい項目（例）

・一次通知：重大度基準と通知期限

・ログ提出：対象、形式、提出期限（何営業日以内）

・保全：削除停止・隔離への協力、実施記録の提供

・特権アクセス：期限付き、付与理由、剥奪証跡

・台帳更新：例外台帳/資産台帳の更新と棚卸し

・再委託（国外）の範囲と監督責任

・契約終了時の出口：アクセス剥奪証明、ログ引継ぎ、削除証明

属人化の根は「お願い」と「関係性」です。

それを「義務」に変えると、担当者が変わっても説明が崩れにくくなります。

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

5. ケーススタディ（匿名化）：その人しか触れないKey Vaultが、障害と説明崩壊を起こした例

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

背景（匿名化）

・Azureで複数アプリを運用

・Key VaultでSecrets/Certificatesを管理

・更新作業は「詳しい担当者」一人が実施

・台帳は一覧（エクスポート）止まりで、所有者・用途・重要度・更新手順が弱い

起きたこと

・証明書の期限切れで一部サービスが停止

・夜間で担当者に連絡がつかず、復旧が遅延

・翌日、取引先から「停止時間」「再発防止」「管理体制」を照会される

・社内でも「なぜ期限管理ができていないのか」「誰の責任か」が割れる

・“設定ミス”ではなく、“統制（体制）”として説明が崩れた

立て直し（方向性）

・Secrets/Keys/Certificatesを用途・重要度・Ownerで分類し、更新手順と期限を台帳化

・更新作業を個人から役割へ（RACI化、バックアップ担当）

・例外（緊急更新や暫定措置）は台帳＋期限＋解除条件

・委託先が絡む部分はSOWに更新協力・記録提供を明記

・障害時の初動30分（指揮官、封じ込め、保全、第一報）を事故対応パックとして整備

結果

・「その人しか触れない」状態が減り、担当者不在でも復旧と説明が回る状態に寄せられた

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

6. 自社で確認するときのチェックリスト

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

最後に、今すぐ使えるセルフチェックです。

YESが少ないほど、「その人しか触れない設定」が事故や説明崩壊に直結しやすい状態です。

【権限と体制】

□ 特権作業の承認者が複数いる（不在時の代替がある）

□ break-glassの運用（利用条件・記録・点検）が整っている

□ 事故対応の指揮官（役割）が決まっている

【台帳（一覧ではなく管理）】

□ Key Vault等の重要資産にOwner・用途・重要度・期限が紐づいている

□ 例外（暫定開放、CA除外、常設特権）が台帳で期限管理されている

□ 例外延長は再承認になっている（理由更新＋補償統制確認）

□ 解除完了の証跡（いつ誰が戻したか）が残る

【証跡（提出・保全）】

□ ログの提出期限（何営業日以内）と形式が固定されている

□ 保全（削除停止・隔離）手順があり、担当が役割で決まっている

□ 抽出者記録（いつ誰がどう取得したか）を残せる

【委託（SOW）】

□ 委託先の一次通知・提出・保全協力が期限付きで義務化されている

□ 台帳更新や棚卸しが委託範囲に入っている

□ 再委託（国外）がある場合、範囲と監督責任が説明できる

【引き継ぎ】

□ 引き継ぎパック（RACI、台帳、証跡パック、SOW要点）が定義されている

□ 担当者が変わっても1週間で説明できる状態に戻せる

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

7. まとめ：「その人しか触れない」は、技術の話ではなく“説明責任の構造”の話

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

「その人しか触れない設定」が増えたときの危険信号は、

単に“忙しい”とか“人手不足”ではありません。

それは、

・責任（主語）

・期限（いつまで）

・証跡（出せる/保全できる）

・委託の義務（SOW）

が個人に張り付いているサインです。

対策は、触れる人を増やすことだけでは足りません。

責任を「人」から「役割＋成果物」に移すことが本質です。

・タスク別RACI

・例外台帳／資産台帳（Owner＋期限＋解除）

・証跡パック（提出・保全）

・SOW更新（義務化）

これで、担当者が変わっても説明が崩れない運用に近づきます。

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

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

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

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

「その人しか触れない設定」が増えて説明が崩れる状態を、RACI・台帳・証跡パック・委託契約（SOW）まで含めて整えるクラウド法務支援を行っています。

・属人化が進み、担当者交代が怖い

・例外（暫定開放、CA除外、常設特権）が台帳化されていない

・ログ提出・保全の手順が担当者依存

・委託先（SOC/MSP/再委託含む）の責任分界と義務を固めたい

・監査・取引先に“体制として説明できる”形にしたい

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

お問い合わせの際に「その人しか触れない設定の記事を見た」と書いていただけるとスムーズです。