第4章 組織のポリシーと統制

学習目標

• AI利用状況登録簿を作成し、それを出発点として、ポリシー・標準・手順・案内を階層別に設計する。
• データ等級、ツール、用途の影響、実行権限を組み合わせ、許可・条件付き・禁止の区分を設計する。
• リスクに比例する承認手続きと、有効期限のある例外手続きを作成する。
• 規程の条件を管理者による制御（アカウント、保持、フィードバック、組織部門、Web検索、エージェント）で実装し、動作を確認する。
• エージェントと接続機能の権限を分け、教育と代替ツールによってシャドーAIを減らす。

はじめに

セキュリティチームがプロキシの記録を調べ、多くの従業員が未承認のAIサイトにアクセスしていることを発見したとします。最も速い対応は遮断です。ところが翌週には、従業員が個人の携帯電話で同じサイトを使い始め、会社はその利用を把握することさえできなくなります。従業員が望んでいたのは規程違反ではなく、締め切りを守ることでした。しかし会社は、そのニーズに応える承認済みの経路を用意していませんでした。問題は人ではなく設計にあったわけです。本章はその設計を扱います。

組織のAI利用規程は、禁止事項を並べた一覧ではなく、「このようにすればよい」と分かる手引書であるべきです。利用できるツールとその使い方を明確に示し、リスクの大きい箇所に限って利用のハードルを高くします。そして、その条件を、人の記憶に頼るのではなく、システムの設定によって守れるようにすることが目標です。

本章は、ガバナンスの第一歩である利用状況の把握から始めます。続いて規程の階層と骨格、区分の設計、承認と例外、責任体制を扱い、管理者による制御、権限の整理、エージェントの統制、教育、供給網管理へ進みます。第1章で読んだベンダーの条件と、第2・3章の法的要件が、ここで規程の材料になります。例はそのまま写して使うのではなく、組織のデータ等級と業務に合わせて修正するために用意しています。

重要な概念

ガバナンスの第一歩：AI利用状況登録簿

何を使っているか分からなければ、規程は作れません。NIST AI RMFは、AIシステムを一覧化する仕組みを備え、組織のリスクの優先順位に合わせて資源を配分するよう求めています（GOVERN 1.6）。AI利用状況登録簿は、組織が使っているAIを1か所にまとめた表です。

登録簿の作成では、新しく購入したAIツールだけでなく、すでに利用しているSaaSに追加されたAI機能も探す必要があります。業務ツールの更新でひそかに有効になった要約・生成機能が、最もよくある盲点です。最初から完璧である必要はありません。部門別アンケート、購買記録、ネットワーク記録を重ね合わせて埋めていき、申請手続きと登録簿の更新を結び付ければ、自然に最新の状態を保てます。

ポリシー、標準、手順、案内

すべての内容を1つの文書に入れると、変更するのも読むのも難しくなります。階層を分ければ、原則を長く維持しながら製品の変化には速く対応できます。

例えば「個人情報は承認済みのツールだけで処理する」はポリシーです。「承認ツールは、学習不使用・所定の保持期間・フィードバック制限を備える」は標準です。「新しいツールは申請後5営業日以内に審査する」は手順、「顧客の名前を消してから貼り付けてください」は案内に当たります。

AI利用規程の骨格

AI利用規程には、最低限、次の5つの部分が必要です。

1. 目的と適用範囲：誰に適用するか（役職員、派遣・協力会社の従業員を含むか）、どのツールと業務に適用するかを定めます。
2. データ等級：公開、内部、機密、個人情報、センシティブ情報などです。既存の情報セキュリティ規程の等級をそのまま使うとよいでしょう。
3. 承認ツール一覧：データ条件を確認した製品とプラン、許可する機能を示します。
4. 利用区分：データ等級、ツール、用途の組み合わせごとに、許可・条件付き・禁止を定めます。
5. 責任と手続き：出力物のレビュー責任、申請・例外承認、事故報告、違反時の措置を定めます。

規程の各条項に理由と代替策を添えると、遵守率が高まります。「顧客情報を入力しないでください」の後に、「会話が学習に使われる可能性があるためです。必要な場合は承認ツールAを使ってください」と付ける方法です。

許可・条件付き・禁止の区分設計

本章のスキル目標は「許可・禁止・条件付き利用のカテゴリを設計する」です。ツール名だけで区分を決めると統制に抜け穴が生じます。同じツールでも、入力するデータと使う用途によってリスクが違うためです。次の4つの軸を併せて見ます。

まず、データとツールの組み合わせで基本区分を決めます。

その後、用途と実行権限によって区分を1段階ずつ引き上げます。結果がそのまま顧客に届く場合には、人によるレビューを条件にします。採用・評価・融資のように人に関する判断に使う場合は、事前リスク評価と第2章の高影響の検討、第3章の自動化された決定の検討を条件に加えます。AIが外部に送信したり、取り消しにくい行動をしたりする場合には、行動前の承認を条件にします。区分が変わる条件を例とともに記せば、従業員が自ら判断できます。

リスクに比例する承認手続き

すべての申請を同じ書面決裁で処理すると、単純な依頼まで数週間かかり、その遅れがシャドーAIを増やします。よく使われるのは、経路を3つに分ける方法です。

承認の各段階は、前の結果が次の入力になるよう設計します。目的とデータ等級を定め、等級に合わせてベンダーの条件とリスクを評価し、その結果から承認条件を決め、管理者設定で実装し、利用者を教育してから展開し、運用記録で再評価します。承認書には承認範囲（業務、データ、ユーザー、機能、期間）を記し、一度の承認が他のデータや用途へひそかに広がらないようにします。

例外管理

規程に合わなくても必要な利用は必ず生じます。例外を認めなければ隠れて使われ、簡単に認めれば規程が崩れます。よい例外手続きには4点があります。

1. 申請内容：申請者、目的、データ等級、期間、代替策の検討結果を記します。
2. 補完統制：例外によって増えたリスクを抑える措置を設けます。マスキング、利用者の限定、ログ点検などです。
3. 期限と回収：終了日、期限到来時のアカウント・データの回収方法、延長審査の条件を定めます。
4. 反復例外の反映：同じ例外が繰り返される場合、規程や承認ツール一覧を改めるべき兆候と捉えます。

期限のない例外は例外ではなく、規程の外にある恒久的な許可です。

責任体制：誰が決定し、誰が検討するか

関係部門が多いほど責任は曖昧になります。NIST AI RMFは、リスクのマッピング・測定・管理の役割と責任、連絡経路を文書化し（GOVERN 2.1）、AIシステムの開発・展開によるリスク判断に経営陣が責任を負うよう求めています（GOVERN 2.3）。

実務では、2つの原則を守ります。第1に、作成者とリスクを受容する人を分けます。 開発チームはシステムについて最もよく知っているため、評価資料は開発チームが作成します。しかし、そのリスクを受け入れるかどうかは、独立したレビューを経て、上位の権限を持つ人が決めます。第2に、リスク等級に応じて受容権限を上げます。 低いリスクは部門長、中程度のリスクは委員会、高いリスクは経営陣というように定めておくと、判断が速くなり、記録も残ります。法務・個人情報保護・情報セキュリティの各検討部門は意見を述べます。そして、決定の内容とその根拠は、承認権者の名前で記録に残します。

管理者による制御

規程の条件は、可能であれば管理者設定で実装します。人の記憶よりシステム設定の方が確実だからです。公式文書に示された例は次のとおりです。

設定を変更した後には、一般ユーザーのアカウントで実際の動作を確認し、変更した日時と変更した人を記録します。Geminiアプリのように、グループ単位と組織部門単位の設定が重なる場合には、優先順位の規則によって意図とは異なる結果が生じることがあります。管理者権限そのものについても、付与する相手を必要最小限の人数に限定し、管理者の操作ログを定期的に確認します。

権限整理と過剰共有

社内データを検索して回答するAIは、ユーザーが閲覧できるものをすべて探し出します。Microsoftは、Copilotが表示するのは、そのユーザーに少なくとも閲覧権限がある組織データだけであると説明し、SharePointのようなサービスの権限モデルを正しく使うよう勧めています。問題となるのは、「権限はあるものの、これまで誰も探していなかった」ファイルです。誤って全社共有として公開されたフォルダーは、今までは見つからずにいただけです。AIによる検索を導入すれば、その中身がすぐに回答に現れるようになります。

そのため、AI検索ツールの展開前には権限整理を前提条件とします。全社共有リンクや「全ユーザー」権限のある場所を探し、機密性の高い場所には秘密度ラベル（文書に等級を付けてアクセス・暗号化を適用する表示）やアクセス制限を適用します。検索インデックスが原本の権限に従うことも確認し（第3章「さらに深く」）、展開後も定期点検します。これはAI統制であると同時に、過去に蓄積した情報セキュリティ上の負債を解消する作業です。

エージェントと接続機能の統制

エージェントは回答の生成にとどまらず、ツールを呼び出して照会・修正・送信・決済などを行うAIです。OWASP Top 10 for LLM Applications（2025）は、プロンプトインジェクション（LLM01）と過剰なエージェンシー（Excessive Agency、LLM06）を主要リスクに挙げています。外部文書やメールの隠れた指示がAIの行動を変える、間接プロンプトインジェクションが代表例です。必要以上の権限があれば、その被害は拡大します。

統制は5つに整理できます。

1. 最小権限：業務に必要なツールと範囲だけを接続し、読み取りと書き込みを分けます。
2. 行動前の確認：外部送信、決済、削除、権限変更など取り消しにくい行動は、人が承認してから実行します。
3. 上限：金額、件数、対象範囲の上限を、モデルとは独立したシステムが強制します。
4. 記録：どの入力で、どのツールを、どの引数で呼び出したかを残します。
5. 停止と復旧：異常な行動を発見したら直ちに止めるスイッチと、元に戻す手順を設けます。

ベンダーの利用ポリシーも、同じ方向を示しています。Anthropicの現行の利用ポリシーでは、エージェント型の利用でもポリシーを遵守しなければならないと定めています。さらに、2026年11月12日に施行される改訂版では、エージェントを作成または展開するユーザーが、ツール、ブラウザー、接続されたシステムを通じた行動まで含めて責任を負うことを明らかにしています。

教育とシャドーAI

シャドーAIは、未承認のAIアカウント・ツールで業務データを処理する現象です。その理由は通常、悪意ではなく利便性です。承認ツールがない、申請手続きが遅い、何が許可されるか分からない、といった事情があります。

効果的な対応は、4つの取り組みを組み合わせることです。承認済みのツールを容易に使えるようにし、短く具体的な基準を知らせ、職種ごとの事例を使って教育し、その後で利用状況をもう一度測定します。教育には、データの等級の見分け方、承認済みのツールとそれを承認した理由、出力物の検証に関する責任、フィードバックボタンの意味、ミスをしたときの報告方法を含める必要があります。自発的に申告したミスに対する不利益を軽減する方針を設けておけば、事故を早期に把握できます。ツールや規約は頻繁に変わるため、年1回の集合教育よりも、導入や変更のたびに行う短い教育のほうが効果的です。利用状況を調査するときには、従業員のプロンプトの内容まで過剰に収集しないよう、調査の範囲を定めてください。それ自体も個人情報の処理に当たるからです。

供給網と第三者の管理

AIの大半は外部から調達します。モデル、API、データセット、SaaSに組み込まれたAI機能まで、すべて供給網です。NIST AI RMFは、第三者関連のAIリスクを扱うポリシー・手順を置き（GOVERN 6.1）、第三者資源のリスクと利益を定期監視するよう求めます（MANAGE 3.1）。

供給者のデューデリジェンス（適格性の調査）で確認する項目は、第1章の5つの問い、セキュリティ認証、事故の通知条件、サブプロセッサーの変更通知、モデルの変更やサポート終了を知らせる方法、契約終了時のデータの返却・削除です。供給者がISO/IEC 42001のようなマネジメントシステムの認証を取得しているという事実は、あくまで供給者の管理体制に関する情報です。それによって、自社の組織が、自らのユースケースのリスクを評価する責任を果たしたことにはなりません（第5章）。

さらに深く

形式的承認と自動化バイアス

「人が最終レビューする」という条件は多くの規程にありますが、本当に機能しているかは別途確認が必要です。AIの提案を過度に信頼し、レビューせず受け入れる傾向を**自動化バイアス（automation bias）**と呼びます。NIST生成AIプロファイルは、過信、自動化バイアス、過度の依存を、人とAIの相互作用に生じる「人間とAIの構成（Human-AI Configuration）」リスクとして挙げています。

実効性のあるレビューでは、レビュー担当者が判断に必要な情報と時間を持ち、結果を変更する権限と責任も持っていることが必要です。また、レビューが実際に行われているかを測定します。修正せずに承認された割合、レビューにかかった時間、レビュー後に見つかった誤りの割合に異常がある場合には、リスクの大きい案件を重点的に確認したり、無作為に抽出したサンプルを二重にレビューしたりするよう、仕組みを設計し直します。形式的にクリックするだけの確認は、第3章の自動化された決定においても、実質的な人の関与とは認められにくいものです。

AIシステムの変更と終了

AIシステムは導入時よりも、変更・終了時に事故が起きやすいものです。ベンダーがモデルのサポート終了を通知したり、新しいモデルへ自動更新されたり、サービスを終了したりする場合です。NIST AI RMFは、安全に廃止する手順を置き（GOVERN 1.7）、意図と異なる性能・結果を示すシステムを代替・分離・無効化する仕組みと責任を定めるよう求めています（MANAGE 2.4）。

変更時には、既存の評価が新しい版でも有効かを問います。公開ベンチマークは自社業務の性能を保証しないため、高リスクのシステムは自社の業務データで再検証します。終了時には、接続権限の回収、利用者への案内、保管と廃棄の区別（他法令で保管が必要な記録は分離保管）、代替の業務手順をチェックリストで管理します。

実務の場面

セイラン大学：教職員のAI利用規程を作るとき

学生1万2,000人規模の「セイラン大学」は、教職員向けのAI利用規程を作ることにしました。教務部は成績処理とシラバスの作成に、研究部は研究課題の報告書に、入試部は入試案内の相談対応に、AIを使いたいと考えていました。情報部門が1か月間調査したところ、大学が契約した業務用プランのほかに、個人アカウントも広く使われていることが分かりました。一部の講師は、学生の課題ファイルを丸ごと貼り付けて、採点に関する所見を得ていました。

タスクフォース（TF）は、既存の情報セキュリティ規程で使っているデータの等級をそのまま取り入れ、4段階に整理しました。学生の成績や相談記録は、個人情報の等級に分類しました。利用区分の表では、学生の課題の採点補助を、「承認済みのプランで学籍番号・名前と本文中の識別情報を削除し、最終的な点数は教員が決める」という条件付きの利用としました。名前だけを消しても、課題の内容から学生を識別できるためです。入試部の相談チャットボットは、外部の利用者に直接回答するサービスなので、詳細審査ルートに引き上げました。さらに、AIによる相談対応であることを知らせる文言、回答範囲の制限、有人対応への引き継ぎ経路を、利用の条件に加えました。

研究部は、海外の共同研究課題ごとに契約条件が異なると主張し、一律に規則を適用することに反対しました。TFは、研究データを課題ごとの例外手続きで扱うこととし、承認書には契約条件と有効期限を記載させました。個人アカウントの利用を全面的に禁止する案は取り下げました。まず、大学のアカウントで使える承認済みツールを全教職員に開放し、1学期が経過した後に、個人アカウントの利用率を再び調べることにしました。

管理者設定ではSSO連携、保持期間、フィードバック送信の無効化を適用しました。入試チャットボットはWeb検索を無効にし、公式案内だけを参照させました。施行初月には、学科ごとに10分の事例教育を行いました。

どんぐりゲームズ：返金する相談エージェント

オンラインゲーム会社「どんぐりゲームズ」は、顧客からの問い合わせに答える相談エージェントに、決済履歴の照会、返金の実行、ゲーム内アイテムの付与という機能を追加しようとしています。カスタマーサポート部門は、相談の待ち時間を短縮したいと考えていました。一方、セキュリティチームは、エージェントが誤った指示を受けて、大量の返金やアイテム付与を実行してしまう状況を懸念していました。

情報セキュリティの担当者は、機能を行動の単位に分け、権限表を作成しました。決済履歴の照会は、質問した顧客本人のアカウントに限り、読み取り専用で許可しました。返金については、規程上、自動返金の対象とされる少額の案件だけをエージェントが実行することにしました。それ以上の金額の返金や、返金を拒否するかどうかは、相談員が判断します。顧客に不利益な決定を、人間の関与なしに行わないためです（第3章の自動化された決定）。アイテムの付与は、システム障害時の補填など、あらかじめ定めた一覧の範囲内に限りました。1日当たりの件数と、アカウントごとの数量の上限は、決済システムが直接強制するようにしました。上限をモデルの指示文にだけ記すという方法は採用しませんでした。指示文は、プロンプトインジェクションによって無効化される可能性があるためです。

顧客が送った添付画像や外部リンクの内容によって、エージェントの行動が変わらないようにしました。そのような入力が含まれる会話では、アクション実行ツールを使わず、オペレーターに引き継ぐことにしたのです。すべてのツール呼び出しは、入力、呼び出したツール、引数、実行結果とともに記録します。また、返金件数が通常の3倍を超えた場合には、エージェントの行動ツールを自動的に無効にするスイッチを設けました。顧客には、会話を開始する画面で、AI相談員であるという事実を知らせました。

公開前にTFは、悪意ある指示を混ぜた試験会話で権限表が実際に遮断するか確認しました。結論は「照会は許可、少額返金は条件付き許可、それ以外の金銭的行動は人の承認」で、3か月後に記録から範囲を再検討することにしました。

間違えやすいポイント

1. 「全面禁止が最も安全だ」 代替策のない禁止は、見えない場所での利用を増やします。
2. 「全利用を同じ条件付きにすれば公平だ」 リスクに比例しない統制は、止めるべきものを見逃し、許可してよいものを止めます。
3. 「規程を先に書き、現状は後で見る」 利用状況が分からなければ現実とずれます。登録簿が先です。
4. 「最も詳しい開発チームがリスク受容も決める」 評価資料は開発チームが作り、受容は独立したレビューを経た上位権限者が決めます。
5. 「組織部門で無効にすれば必ず遮断される」 Geminiアプリでは構成グループの設定が優先します。
6. 「AIは権限内しか示さないので権限整理は不要だ」 誤って公開されたファイルがすぐ回答に現れます。展開前に整理が必要です。
7. 「エージェントの禁止事項は指示文に書けばよい」 上限と承認は、モデル外のシステムが強制する必要があります。
8. 「人が承認ボタンを押せばレビューだ」 情報、時間、権限がなく、測定もしない承認は形式にとどまります。

ひと目でわかるまとめ

• ガバナンスはAI利用状況登録簿から始めます。SaaSに追加されたAI機能も探します。
• ポリシー・標準・手順・案内を分け、原則はゆっくり、案内は速く変更します。
• 区分は、データ等級×ツール条件×用途の影響×実行権限で決めます。
• 承認は簡易・通常・詳細に分け、範囲を明記します。例外には期限と補完統制を設けます。
• 作成者と受容者を分け、等級別に受容権限を定めます。
• 条件を管理者設定で実装し、一般ユーザーのアカウントで動作を確認します。
• AI検索の展開前に権限を整理します。
• エージェントには最小権限、行動前の確認、システムによる上限、記録、停止スイッチを設けます。
• シャドーAIは、承認ツールの提供、短い基準、職種別教育、再測定で減らします。
• 供給者の認証は、自社のリスク評価を代替しません。

公式ドキュメントで確認する

• Google Workspace Admin Help — Turn the Gemini app on or off：組織部門・グループ設定と優先順位、会話履歴の保持。
• Anthropic — Configure custom data retention controls for Enterprise plans：カスタム保持期間と権限。
• Microsoft Learn — Data, privacy, and security for web search in Microsoft Copilot：Web検索の管理ポリシーとユーザーの切り替え。
• Microsoft Learn — Data, Privacy, and Security for Microsoft Copilot：権限モデル、エージェント管理、Purviewの保持。
• NIST AIRC — AI RMF Core：GOVERN 1.6、1.7、2.1、2.3、6.1、MANAGE 2.4、3.1。
• OWASP — Top 10 for LLM Applications：プロンプトインジェクション、過剰な権限。

セルフチェック

4-1. AI利用状況登録簿に設ける列を5つ以上書き、作成時に最も見落としやすいAI利用は何かを書いてください。

4-2. ポリシー、標準、手順、案内の違いを、1つの例（顧客個人情報の入力など）で、それぞれ1文ずつ示してください。

4-3. 同じ承認ツールでも利用区分を1段階上げるべき場合を、用途と実行権限の観点から2つ書いてください。

4-4. 例外承認書の必須項目を5つ以上書き、同じ例外が繰り返されるとき担当者が行うことを書いてください。

4-5. 管理者の設定変更後、一般ユーザーで再確認する必要がある理由を、設定が重なる場合を例に説明してください。

4-6. エージェントの行動のうち、人の事前承認が必要なものの特徴と、上限を指示文ではなくシステムに置く理由を書いてください。

4-7. （設計）従業員300人の架空会社を定め、4段階のデータ等級と2種類のツールで区分表を作り、条件付きセルごとに管理者設定で実装できるかを示してください。

実習課題