生成AIの社内ルール設計｜禁止事項だけにしない許可範囲・権限・承認・人間確認の決め方

生成AIの社内ルールは、「何を禁止するか」だけを決めても、利用者が日々の業務で判断する基準にはなりません。どの業務で、どの情報を入力し、出力をどこまで使え、どの操作で承認を受けるかを、実際の仕事に沿って明確にすることが重要です。

たとえば「生成AIの利用は禁止」とだけ決めても、社員が必要性を感じたときに、会社が管理していない個人契約・未承認サービスを使う可能性があります。こうした未承認の利用に関するリスクや管理方法は、[シャドーAIの記事]でも解説しています。

この記事の許可レベル、判定表、承認フロー、テンプレートは、Mojiによる実務上の設計提案です。個人情報保護法上の取扱い、契約、著作権、業界規制などの判断は、各社の法務・情報セキュリティ・個人情報保護担当者と確認してください。本文中の公的資料は2026年10月時点の内容です。

結論：社内ルールは「禁止リスト」ではなく、判断できる運用表にする

利用ルールは、少なくとも次の5軸で整理すると、利用者、業務責任者、管理部門が同じ基準で判断しやすくなります。

1. 用途：下書き、要約、調査、分析、意思決定支援、顧客対応など
2. 入力データ：公開情報、社内情報、営業秘密、個人情報、認証情報など
3. 出力利用：個人の検討用、社内共有、顧客提出、公開
4. 外部操作：文章生成のみ、下書き保存、システム更新、メール送信、発注・決済など
5. 利用者・権限：全社員、特定部門、管理者、承認者、システム管理者

NISTのAI RMF 1.0は、AIリスク管理をGOVERN、MAP、MEASURE、MANAGEの4機能で整理しています。このうちGOVERNは、他の3機能に横断的に適用される機能と位置付けられています。（出典：NIST AI RMF 1.0）

社内ルールも、公開時に一度決めて終わりにはしません。利用文脈の把握、リスクの測定、管理、見直しをつなげる運用として設計します。

ルール作成前に確認する3つの前提

1. 「生成するだけ」と「外部に影響を与える」は分ける

会議メモの要約や文章の下書きと、顧客台帳の更新、外部メールの送信、採用候補者の評価、発注の確定は、同じ生成AI利用として扱うべきではありません。後者は、誤りが生じたときの影響範囲、取り消しの難しさ、説明や記録の必要性が大きくなり得ます。

外部ツールを操作するAIエージェントを利用する場合は、通常のチャット利用ルールに加え、委任する操作、承認のタイミング、停止条件を定めます。詳しくは「AIエージェントはどこまで任せるべきか｜委任範囲・人の承認・停止条件を設計する実務ガイド」を参照してください。

2. 入力可否は、AIサービス名だけでなく「情報の分類」から決める

「特定のサービスだけ可」と製品名だけで線を引くと、契約プラン、管理機能、データ利用条件、接続構成が変わった際にルールが実態とずれることがあります。まず自社の情報分類に沿って、入力してよい情報、条件付きで扱う情報、入力しない情報を定義します。

個人情報保護委員会は、個人情報取扱事業者が個人情報を含むプロンプトを入力する場合、利用目的の達成に必要な範囲内であることを確認するよう示しています。また、本人同意なしに個人データを入力し、回答出力以外の目的で扱われる場合には、提供事業者がそのデータを機械学習に利用しないことなどを確認するよう注意を促しています。

一般利用者向けには、入力した個人情報が機械学習に利用される可能性や、不正確な個人情報が出力されるおそれが示されています。利用規約やプライバシーポリシー等を確認することも求められています。（出典：個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」）

入力可否は、情報の種類だけでは完結しません。利用するサービスの契約、学習利用に関する設定、アカウント管理、接続先、ログや保存先も合わせて確認します。

IPAが2026年4月に公開した利用者向け資料では、クラウドAIへの営業秘密の入力を避けることなどが、利用時の対策例として紹介されています。（出典：IPA「AI利用者のためのセキュリティ豆知識」）

3. 人間確認は「読むこと」ではなく「何を確認し、誰が責任を持つか」を決める

「人が確認する」とだけ書いても、確認対象と責任者が不明確なら、確認は形だけになりかねません。顧客向け文書なら、事実の根拠、数値、固有名詞、契約条件、引用・権利、会社として約束する表現などを確認対象にします。

総務省・経済産業省の「AI事業者ガイドライン（第1.2版）」は、2026年3月31日に公表されました。第1.2版では、AIエージェントへの対応や、人間の判断を介在させる仕組みが重要な論点として整理されています。人間確認の対象と責任者を決める際の、公的な参照先として使えます。（出典：総務省・経済産業省「AI事業者ガイドライン（第1.2版）」）

許可範囲を決める5軸の判定表

次の表は、個別の生成AI利用を社内ルールへ落とし込むためのMojiによる設計例です。自社の情報資産分類、業界規制、利用サービスの契約条件、接続するシステム、許容できない失敗に合わせて調整してください。

4段階の利用レベルを定義する

全利用を「可・不可」の二択にせず、利用条件の異なるレベルを設けると、現場の判断と統制を両立しやすくなります。以下はMojiによる区分例です。

レベル3を単に「面倒な申請」にしないためには、満たすべき条件と提出すべき情報を申請フォームに明記します。利用希望者が、必要な情報をそろえたうえで相談できる状態を作ることが目的です。

よくある失敗パターン

社内ルールが運用されなくなる原因は、文面の不備よりも、現場の動きと合っていないことにある場合が多くあります。策定時に次の4つを避けられているか確認してください。

社内ルールを作る実務手順

手順1：利用したい業務を先に棚卸しする

ルール作成をツール選定から始めると、製品の機能に業務を合わせることになりがちです。最初に「誰が、何のために、どの工程で、何を入力し、どの成果物に使いたいか」を集めます。

全社で一度に集められない場合は、営業、管理、開発、カスタマーサポートなど代表部門から始めます。業務の選び方、限定試行、KPIの置き方は、「生成AI導入前の業務棚卸しと現場定着の進め方」も参考にしてください。

手順2：各業務を5軸で分類する

棚卸しした業務ごとに、「用途・入力データ・出力利用・外部操作・利用者・権限」を記入します。この段階では「AIを使うか」ではなく、失敗した場合に誰へどのような影響があり、戻せるかを確認します。

• 誤った出力が社外へ出た場合、訂正・撤回できるか
• 入力情報に個人情報、営業秘密、未公開の顧客情報が含まれるか
• 出力が契約、採用、評価、価格、健康・安全などに影響するか
• AIが外部システムを更新・送信・削除するか
• 利用履歴、承認履歴、実行ログを後から確認できるか

NISTのGenerative AI Profileは、生成AI向けのAI RMFの横断的なプロファイルです。組織の目標、法令・規制上の要件、リスク許容度、資源を踏まえて、生成AIのリスクをどう管理するかを検討するための資料として位置付けられています。（出典：NIST AI 600-1：Generative AI Profile）

手順3：許可レベルと人間確認の条件を決める

各業務をレベル1〜4へ仮置きした後、「人間が確認する」を具体的な確認条件へ分解します。

手順4：役割と承認経路を分ける

承認者を一人に集約すると処理が滞り、部門ごとに任せすぎると基準がばらつくことがあります。次の4役を分ける方法は、Mojiによる実務上の設計例です。

• ルール所有者：全社方針、許可レベル、例外基準、教育内容を管理する
• 業務責任者：利用目的、成果物、人間確認の品質に責任を持つ
• 情報システム・セキュリティ担当：ID、権限、ログ、接続、データ保護、インシデント対応を担う
• 利用者：ルールの範囲で使い、出力を検証し、誤りや漏えい懸念、不審な挙動を報告する

個人情報、契約上の秘密保持、知的財産が関わる利用では、この4役に加えて法務・個人情報保護担当が審査に加わります。

AIリスクを全社的に扱う考え方は、「AIのリスク管理・マネジメントとは？対応方法や費用について」も参照してください。接続、権限、ログ、プロンプトインジェクションなどの技術面は、「AIのセキュリティ対策とは？運用・開発方法や費用について」と合わせて整理できます。

手順5：限定試行で、ルールが守れるかを検証する

ルールは文面が正しくても、現場の手順に合わなければ運用されません。比較的影響が小さい業務から試行し、利用者が迷った箇所、申請時に不足した情報、確認にかかった負荷、発生した誤りを記録します。

NIST AI RMF 1.0は、AIリスクをAIライフサイクルを通じて扱う考え方を示しています。試行の結果を基に、許可範囲、承認条件、教育内容、再評価条件を更新してください。

承認フローのテンプレート

以下は、レベル2・3の利用を想定したMojiによる提案テンプレートです。社内ポータル、チケット管理、申請フォームなど、既存の運用に合わせて実装してください。

1. 利用者が申請する：利用目的、対象業務、入力データ区分、利用サービス、出力の利用先、外部操作の有無、想定件数、確認者を記載する
2. 業務責任者が確認する：AIを使う目的、出力の使い方、人間確認の手順、誤りが起きた場合の影響を確認する
3. 情報システム・セキュリティ担当が確認する：契約、アカウント、アクセス権、接続先、ログ、データ保持、入力制限、停止方法を確認する
4. 必要に応じて法務・個人情報保護担当が確認する：個人情報、契約上の秘密保持、知的財産、業法・社内規程との関係を確認する
5. 許可条件を記録して利用開始する：許可レベル、利用者、対象業務、入力条件、確認者、期限、再審査条件を残す
6. 定期見直しまたは変更時に再評価する：モデル、サービス規約、接続先、扱うデータ、外部操作の範囲が変わる場合は再評価する

そのまま使える「利用申請」の記入項目

次は申請フォームの最小構成です。記入例はすべて架空の例です。

社員向け短縮版ガイドラインのテンプレート

詳細規程とは別に、利用直前に確認できる短縮版を用意します。以下はMojiによる提案文です。

生成AIを業務で使う前の5確認

1. 会社が承認したアカウント・環境を使う。
2. 認証情報、営業秘密、未承認の個人情報は入力しない。入力可否が不明なら、入力前に相談する。
3. AIの出力を事実として扱わず、数値・固有名詞・引用元・契約条件を確認する。
4. 顧客への送信、公開、システム更新、購入・発注・削除は、定められた承認なしに実行しない。
5. 誤入力、誤出力、意図しない共有、不審な指示を見つけたら、隠さず所定の窓口へ報告する。

短縮版には、社内の相談窓口、利用申請への導線、承認済みツール一覧、よくある質問も併記します。問い合わせ先は個人のメールアドレスや電話番号で固定せず、担当変更に追随できる社内ポータルの窓口ページへ案内する方法も検討できます。

例外申請とインシデント報告を、最初からルールに含める

新しい利用方法が出てくることを前提に、例外申請の入口を用意します。例外を申請できるようにしたうえで必要な追加統制を決めることで、利用実態とリスクを確認しやすくなります。

例外申請で確認する項目

• 通常ルールでは許可できない理由
• 業務上の便益と、代替手段では足りない理由
• 対象データ、対象者、利用期間、利用量
• 追加する安全策：匿名化、閲覧権限、承認、ログ、実行上限、手動確認
• 終了条件と、例外終了後のデータ・アカウントの扱い

インシデント報告で確認する項目

• いつ、どの承認済み環境で、誰が利用したか
• 何が入力・出力・送信・更新された可能性があるか
• 外部共有、権限外アクセス、誤操作の有無
• すでに実施した停止・取消・隔離などの初動
• 影響範囲を確認するために必要なログ、画面、関連チケット

IPAはAIセキュリティ上の課題として、サプライチェーン攻撃、学習データ改ざん・汚染、個人情報・営業秘密の漏えい、偽情報・誤情報などを挙げています。（出典：IPA「AIセキュリティ」）AI利用時の報告を通常の情報セキュリティインシデント対応から分離せず、既存の初動、記録、連絡フローへ接続してください。

公開前チェックリスト

• 承認済みツール・アカウントと、未承認サービスの扱いを明記したか
• 入力可否を、情報分類と契約・設定の両方で決めたか
• 用途、入力データ、出力利用、外部操作、利用者・権限の5軸を記載したか
• 可・不可だけでなく、条件付き許可と個別審査の経路を用意したか
• 対外公開、重要な判断、データ更新・送信・削除に対する人間確認を定義したか
• 確認者が何を確認するかを、成果物・操作ごとに具体化したか
• 役割、承認権限、利用ログ、権限の付与・剥奪を決めたか
• 例外申請、インシデント報告、利用停止の入口を用意したか
• モデル、利用規約、接続先、データ、用途の変更時に再評価する条件を決めたか
• 社員向けの短縮版と、詳細規程へのリンクを用意したか

まとめ：使わせないための規程ではなく、安全に使い続けるための設計へ

生成AIの社内ルールは、禁止事項を並べるだけでは、利用者が日常業務で判断するための基準になりません。現場が使える許可範囲と、影響が大きい利用を統制する承認・権限・人間確認をセットで設計します。

まずは、公開情報の要約や一般的な下書きなど、比較的影響を限定しやすい業務を明確に許可します。そのうえで、機密性の高い入力、対外公開、外部システム操作を伴う利用は、条件付き許可または個別審査へ分けてください。

試行中の迷い、誤り、例外申請を記録し、ルールを更新することで、統制と利用定着を両立しやすくなります。

出典

• NIST AI RMF 1.0
• NIST AI 600-1：Generative AI Profile
• 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」
• 総務省・経済産業省「AI事業者ガイドライン（第1.2版）」
• IPA「AI利用者のためのセキュリティ豆知識」
• IPA「AIセキュリティ」