2026.09.23
生成AI利用申請を安全な業務運用につなげる方法
IT関連
生成AI利用申請は、単なる稟議ではなく、社員が生成AIを安全かつ継続的に業務へ使うための統制の入口です。禁止一辺倒では未申請利用を招き、申請が重すぎれば現場の改善意欲を失わせます。
生成AIの導入・導入予定は全体の69.5%に達する一方、導入に課題を感じる企業は97％とされています。業務利用を拡大するほど、入力情報、出力物、契約条件、アカウントを一貫して管理する仕組みが必要になります。
本記事では、申請対象の決め方、実務で使える申請項目、承認フロー、生成AI社内ポリシーと規程のつなげ方、権限・ログ・未申請利用への対処までを、運用に落とし込める形で解説します。
生成AI利用申請で最初に決めるべき範囲
申請制度の目的を業務利用の促進に置く
結論として、生成AI利用申請の目的は利用を止めることではなく、業務目的とリスクに応じた安全な利用条件を明確にすることです。目的が監視だけに見える制度は、個人契約や無料版への流出を招きやすくなります。
申請では、どの作業を効率化したいのか、誰が生成物を確認するのか、外部へ渡す可能性があるのかを整理します。これにより、情シス・法務・現場が同じ前提で判断でき、承認後の責任所在も曖昧になりません。
たとえば提案書の構成案作成、議事録の要約、公開済み資料の言い換えは、用途を限定すれば導入しやすい領域です。一方で採用判定、人事評価、与信、医療判断などは、人間による最終判断を必須にした上で個別審査すべきです。
- 申請の狙いを「禁止」ではなく「条件付きで使える状態」にする
- 業務目的と最終確認者を必ず結び付ける
- 高リスク業務は通常業務の申請と分けて審査する
事前申請が必要な利用を情報区分で線引きする
申請対象は、ツール名ではなく入力する情報と出力の使い道で線引きする方法が実務的です。公開情報のみを使い、社内閲覧にとどめる軽微な用途は簡易申請にし、顧客情報や機密情報を扱う用途は審査を厚くします。
特に個人情報、営業秘密、未公開の財務情報、認証情報、ソースコード、取引先から預かった資料は、入力可否を明文化してください。法人契約であっても、契約条件、学習利用の設定、保存場所を確認しないまま入力してよい理由にはなりません。
AIとのやり取りの39.7%に機密情報が含まれていましたという調査結果は、現場が情報を細分化して認識していない実態を示します。利用者の記憶や善意だけに任せず、選択式の情報区分と入力前チェックを制度へ組み込みましょう。
- 公開情報：定型の簡易申請または自己判断の対象
- 社内資料：保存先と利用範囲を確認して承認
- 個人情報・機密情報・認証情報：原則入力禁止または個別審査
サービスの契約形態と連携機能を確認する
申請時には、無料版、個人契約、法人契約、API、社内構築型を同一視しないことが重要です。データの学習利用、管理者機能、退職者アカウントの停止、請求責任、監査ログの取得可否は、契約形態によって大きく変わります。
ブラウザ拡張機能、外部プラグイン、MCP、クラウドストレージ連携は、生成AI本体の設定が安全でも別経路の情報流出を起こし得ます。申請書には利用する連携先、読み取り権限、書き込み権限を記載する欄を設けましょう。
通信や認証の条件も承認基準に含めます。たとえば機密性の高い環境では、TLS1.3以上＋クライアント認証のように、接続要件を具体化すると判断がぶれません。技術要件は情シスが定期的に更新します。
- 利用サービスの名称、契約者、プラン、管理者を申請に記載する
- 拡張機能・API・外部連携は生成AI本体とは別に評価する
- データ学習設定と保存地域は契約書・管理画面で確認する
通る申請書と承認フローを設計する
申請書は判断に必要な六つの情報に絞る
申請書は、承認者が判断できる情報を過不足なく集めることが原則です。特に、業務目的、入力データ、出力用途、保存先、公開有無、責任者の6項目が揃っていると、判断の土台が整いやすくなります。
運用開始時は、「業務名（自由記述）」「入力データ種別（選択：公開情報 / 社内資料 / 個人情報含む）」「出力の送付先（選択：社内のみ / 顧客共有 / 外部公開）」「保存先フォルダのURL（必須）」「最終確認者の氏名（必須）」の5項目に絞る方法も有効です。
設問を増やしすぎると、申請者は形式的に記入し、承認者も読み切れなくなります。まず頻出業務で最低限の項目を検証し、差し戻し理由を見ながら選択肢や補足欄を改善する方が、実用的な申請制度になります。
- 自由記述は業務目的と例外事情に限定する
- 情報区分と公開範囲は選択式にする
- 保存先と最終確認者は必須項目にする
リスクに応じて承認経路を分ける
承認フローは一律ではなく、リスクに応じて分岐させるべきです。公開情報だけを扱う社内文書の下書きまで、法務・情シスの個別承認を必須にすると、承認待ちが増え、制度そのものが利用されなくなります。
標準的には、低リスクは自己判断と利用記録、中リスクは上長承認、高リスクは法務・情シス・情報セキュリティを含む審査とします。対外公開、個人情報、顧客データ、コードの外部送信、外部連携は高リスクへ寄せるのが安全です。
承認後も無期限の許可にせず、利用目的・ツール・連携先が変わったら再申請とします。条件付き承認では、入力禁止データ、利用期限、レビュー担当、保存先を承認コメントに残し、現場が守るべき条件を明確にしてください。
| 区分 | 代表的な用途 | 承認者 | 主な条件 |
|---|---|---|---|
| 低リスク | 公開情報の要約 | 本人・上長 | 社内限定 |
| 中リスク | 社内資料の下書き | 上長 | 保存先指定 |
| 高リスク | 顧客情報・外部公開 | 法務・情シス | 個別審査 |
- 低リスク：自己判断または簡易登録
- 中リスク：上長による目的・範囲の確認
- 高リスク：法務・情シス・セキュリティの合同審査
差し戻しと例外申請にも期限を設ける
申請が滞る主因は、判断そのものより記載不足です。「保存先が未記入」「入力データの種別が不明」「最終確認者が空欄」という3項目は、差し戻し理由として分類し、申請画面で未入力を防ぐ設計にします。
承認者の対応期限も決めます。軽微な申請、個別確認が必要な申請、法務判断を伴う申請で受付窓口を分け、申請者には受付・差し戻し・承認・条件変更の状態を通知します。属人的なチャット承認は避けましょう。
例外申請は、事業上の必要性と代替策を比較して判断します。例外を認めた場合でも、対象者、期間、データ範囲、監督者を記録し、期限終了時に自動失効または再申請となる運用が望まれます。
- 差し戻し理由を定型化してフォーム改善へ使う
- 例外は対象・期間・条件・承認者を記録する
- 口頭や個人チャットのみの承認を正式記録にしない
ポリシーと規程を申請制度の根拠にする
ポリシー、規程、ルールブックの役割を分ける
生成AI社内ポリシーは、会社として何を守り、どのように活用するかという原則を示す文書です。一方、生成AI社内規程は、対象者、禁止事項、承認権限、違反時の扱いを定める実務上のルールとして位置付けます。
現場向けには、規程全文だけでなく社内AIルールブックを用意してください。入力してよい情報、確認すべき点、申請が必要な場面、相談窓口を一枚ずつの短いガイドにすると、利用者が作業の直前に判断しやすくなります。
この三層を分けることで、技術的な設定変更はルールブック、承認フローの変更は規程、経営方針の変更はポリシーで扱えます。改訂の影響範囲を小さくでき、制度の更新が現場利用を止める事態も避けられます。
- ポリシー：利用に関する経営原則と責任
- 規程：義務、禁止、申請、違反対応の正式ルール
- ルールブック：現場が迷わないための具体例と手順
規程には入力・出力・責任の三点を明記する
生成AI社内規程で最優先すべきなのは、入力できる情報、出力物を利用する前の確認、最終責任者です。生成物はもっともらしい誤り、第三者の権利侵害、偏見を含む可能性があるため、生成AIを責任主体として扱うことはできません。
経営者が最低限決めておくべき7項目として、目的、適用範囲、対象サービス、入力制限、出力確認、ログ、事故対応を基準にすると、規程の骨格を作りやすくなります。就業規則や情報セキュリティ規程との矛盾も確認してください。
生成AIを業務で活用している企業は34.5%でしたという状況では、制度を完成させてから使わせるより、明確な禁止事項を先に定めて試行する方法が現実的です。2〜4週間あれば初版を作れます。試行中の例外は改訂候補として記録します。
- 入力禁止情報を情報区分と業務例の両方で示す
- 対外利用する生成物は人間が根拠・権利・表現を確認する
- 利用者、上長、管理部門の責任分担を規程に書く
社内AIルールは教育と改訂で定着させる
社内AIルールは、公開しただけでは守られません。申請時の短い学習、部門別の事例演習、理解度確認を組み合わせ、利用者が自分の業務に置き換えて判断できる状態を作る必要があります。
社員の96.4%が「週3回以上」AIサービスを利用する水準まで浸透しました（2025年10月調査）という事例もあります。利用頻度が上がるほど、年1回の周知だけでは変化の速いツールや連携機能に追い付けません。
半期ごとのルール見直しの実施を基本にし、重大な仕様変更、事故、法令改正、利用件数の急増時には臨時改訂します。版番号、施行日、変更理由を残し、旧版のルールブックを参照し続けない仕組みも必要です。
- 申請者教育は入力情報・出力確認・事故報告を中心にする
- 部門別にOK例とNG例を示す
- 改訂履歴と最新版への導線を一元化する
AI権限管理と利用ログで許可を運用する
承認後はアカウント発行までを一続きにする
申請の承認だけでは安全な利用は始まりません。AI権限管理では、承認内容に合わせて法人アカウントを発行し、利用可能なモデル、共有範囲、外部連携、管理者権限を設定して初めて統制が機能します。
個人メールアドレスでの登録や、退職・異動後に残るアカウントは統制外になりやすい領域です。人事情報やID管理と連携し、入社、異動、休職、退職に応じて付与・変更・停止を行うライフサイクルを設計してください。
権限は最小権限を原則とします。全社員に管理機能や外部コネクタの作成権限を配るのではなく、一般利用者、部門管理者、全社管理者に役割を分け、特権操作には追加承認を求める構成が有効です。
- 承認結果をID発行・権限設定の作業票へ連携する
- 個人契約から法人管理アカウントへの移行を促す
- 異動・退職時にはAIアカウントも必ず棚卸しする
生成AI利用ログは監視ではなく説明責任の基盤にする
生成AI利用ログは、誰が何を入力したかを無制限に収集するためのものではありません。申請された用途で使われているか、未許可の連携がないか、事故時に事実関係を確認できるかという説明責任のために必要です。
記録対象は、利用者ID、サービス名、利用日時、申請番号、モデル、共有設定、管理操作、エラーやブロックの発生などを基本にします。プロンプト本文の保存は、個人情報や営業秘密を含む可能性を踏まえ、必要性・保存期間・閲覧権限を限定します。
ログを取得するだけでは価値になりません。月次で申請済み利用との一致、利用量の急増、外部共有設定、退職予定者のアクセスを確認し、検知結果を教育、権限見直し、規程改訂へつなげることが重要です。
- ログの目的、対象、保存期間、閲覧者を規程に明記する
- 申請番号とアカウントを結び付けて追跡可能にする
- 監査で見つけた傾向をルール改善へ戻す
AIシャドーITを責めずに申請へ誘導する
AIシャドーITへの最初の対応は、即時の処罰ではなく事実把握と安全な代替手段の提示です。約5人に1人が、会社が承認していないツールを使っていましたという状況では、禁止だけで実態をなくすことは困難です。
ネットワークのアクセス記録、経費精算、ブラウザ拡張機能、SaaSのSSOログ、部門ヒアリングを組み合わせると、未申請の利用兆候を把握できます。ただし、調査の目的と範囲を事前に周知し、私的利用との境界にも配慮してください。
発見後は、利用停止、データ削除の確認、影響評価、申請への移行を段階的に行います。業務上の需要が明確なら、個人利用を責めるだけで終えず、法人ツールの追加や申請フォームの簡素化を検討することが再発防止になります。
- 未申請利用の背景にある業務ニーズを確認する
- 発見後は情報漏えいの有無を優先して評価する
- 安全な代替ツールと簡易申請の導線を提示する
申請制度を測定し改善し続ける方法
小さな対象業務から試行を始める
申請制度は、全業務・全ツールを対象に一度で完成させる必要はありません。「営業部門の提案書作成」と「マーケ部門のメール文面生成」という2つの頻出業務だけを対象にした申請書を作り、1か月運用してから汎用化する方法は有効です。
試行では、申請者が迷った項目、承認者が追加確認した内容、利用後に発生した問題を記録します。現場の実例から選択肢や注意文を直すことで、抽象的な規程を実際の業務判断に使える仕組みへ変えられます。
記入時間は平均2〜3分に収まり、提出件数が整備前の2.5倍に増えましたというケースもあります。申請件数が少ないことを安全性の証拠と決め付けず、申請しやすさと未申請利用の兆候を併せて確認してください。
- 頻出かつ低〜中リスクの業務で試行する
- 申請・差し戻し・利用後の声を一つの台帳へ集める
- フォーム改善の前後で申請件数と記入負荷を比較する
運用KPIで安全性と業務効果を両立させる
制度の有効性は、承認件数だけで判断できません。承認率、平均リードタイム、差し戻し率、未申請ツール数、利用停止件数、教育受講率、事故件数、業務時間削減を組み合わせて見ることで、過度な統制や統制不足を発見できます。
申請件数が月10件を超えてきた段階は、手作業の転記や個人依存の承認から、ワークフロー・ID管理・ログ分析の連携を検討する目安です。件数増加はリスク増大だけでなく、制度が現場に受け入れられている兆候でもあります。
KPIは部門を比較して評価するためではなく、改善対象を見つけるために使います。ある部門で差し戻しが多ければ、担当者を責めるのではなく、情報分類の説明、テンプレート、教育内容が業務実態に合っているかを点検します。
- 安全性：未申請利用、ブロック、事故、権限棚卸し率
- 効率性：申請時間、承認時間、差し戻し率
- 効果：利用継続率、削減時間、生成物レビュー率
事故対応と継続改善の責任者を明確にする
事故が起きたときは、利用者が隠さず報告できることが最も重要です。誤入力、誤送信、権利侵害のおそれ、生成物の誤情報、未許可連携を発見した場合の連絡先と初動手順を、社内AIルールに明記してください。
初動では、利用停止、証拠保全、影響範囲の確認、関係部署への連絡を行います。その後に、顧客・取引先への対応、法務判断、再発防止、必要に応じた再申請を進めます。原因分析では個人だけでなく、権限設定や教育不足も検証します。
制度改善の前には、AI導入の優先度や業務課題を整理しておくと、申請の対象範囲を過不足なく定められます。導入前の整理には、AI導入診断の進め方：現状評価から課題抽出、導入優先度の決め方までを解説もあわせて参照してください。
- 事故報告は懲罰より早期封じ込めを優先する
- 初動、法務確認、再発防止の責任者を分ける
- 事故・変更・監査結果を次回改訂へ反映する
まとめ
生成AI利用申請を機能させる鍵は、申請書だけを整えることではありません。生成AI社内ポリシー、生成AI社内規程、社内AIルールブックを根拠に、承認後のAI権限管理、生成AI利用ログ、AIシャドーIT対策までを一つの運用として設計することが重要です。
要点
- 申請書は業務目的、入力データ、出力用途、保存先、公開有無、責任者を中心に簡潔に設計する
- 情報区分と外部公開の有無で承認経路を分け、条件付き承認を活用する
- 承認後はアカウント発行、最小権限、ログ、棚卸し、停止まで連携させる
- 未申請利用は処罰だけで終えず、実需を把握して安全な利用ルートへ移す
- 申請・差し戻し・事故・利用効果を測定し、ルールを継続的に改訂する
まずは頻出する2業務を選び、簡易な生成AI利用申請を1か月試行してください。申請者の迷い、差し戻し理由、未申請利用の兆候を集めれば、自社に合う承認基準と運用改善の優先順位が見えてきます。
よくある質問
Q1. 生成AI利用申請は、無料版を使う場合も必要ですか？
必要です。無料版はデータ利用条件、管理機能、アカウント停止手順が法人契約と異なる場合があります。会社の情報を扱うなら、契約形態を問わず申請対象に含めるのが安全です。
Q2. 生成AIに社内資料を入力してもよいですか？
自社の情報区分、利用サービスの契約条件、学習利用設定、承認条件によります。社内資料を一律に許可せず、保存先と出力用途を確認したうえで条件付き承認にする運用が有効です。
Q3. 申請を毎回行うと業務が遅くなりませんか？
定型かつ低リスクの用途は包括承認や簡易登録にし、データ種別・公開範囲・連携先が変わる場合だけ再申請にすると、統制とスピードを両立できます。
Q4. 生成AI利用ログにはプロンプト本文まで保存すべきですか？
一律保存は推奨されません。個人情報や機密情報が再びログに残るためです。目的、必要性、保存期間、閲覧権限を定め、申請番号や利用日時など最小限の記録を基本にしてください。
Q5. AIシャドーITを見つけた場合、ただちに処分すべきですか？
まず利用状況、入力データ、外部送信、業務上の必要性を確認します。情報漏えいの封じ込めを優先しつつ、必要な利用なら承認済みツールや申請制度へ移行させることが、再発防止につながります。
参考文献・出典
[](/) [全国無料講演](/lectures)[お問い合わせ](/contact) [x3d AIX 総合研究所…
x3d.jp
…
exawizards.com
[](https://ai-keiei.shift-ai.co.jp/)…
ai-keiei.shift-ai.co.jp