AI利用申請フローの設計方法｜実効性ある承認プロセスの作り方

2026.04.07 XIMIX Google Cloud チーム

【この記事の結論】
AI利用申請フローは「禁止事項リスト」を作るだけでは形骸化する。リスク等級の分類（Grade）→承認プロセスの設計（Approve）→利用状況の追跡（Track）→定期的なルール改善（Evolve）の4段階「GATEモデル」で設計し、技術的な統制と組織的な運用改善を両輪で回すことが、利活用推進とガバナンスを両立させる鍵である。

はじめに

生成AIの業務活用が急速に広がる中、多くの企業が直面しているのが「どのように社内のAI利用を管理するか」という課題です。ChatGPTやGeminiといった生成AIツールを従業員が自由に使い始めた結果、機密情報の意図しない外部送信やハルシネーション（AIがもっともらしい虚偽情報を生成する現象）に基づく誤った意思決定といったリスクが顕在化しつつあります。

AI利用にあたってのガイドライン整備と利用申請・承認プロセスの重要性は広く強調されており、AIガバナンスの確立は優先度の高い経営課題として認識され始めています。

しかし、実際に「AI利用申請フロー」を導入してみたものの、申請の手間を嫌った現場が非公式にAIを使う「シャドーAI」が横行する、あるいは申請フロー自体が形骸化するといった問題が少なくありません。

本記事では、こうした課題を根本から解決するために、AI利用申請フローを実効性のある仕組みとして設計・運用するための具体的な方法を、独自の「GATEモデル」に沿って解説します。

なぜAI利用申請フローが必要なのか

放置が招くリスクの実態

AI利用申請フローの整備を後回しにする企業が抱えるリスクは、大きく3つに分類できます。

リスク分類	具体例	影響度
情報漏洩リスク	従業員が機密データを外部AIサービスに入力し、学習データに取り込まれる	極めて高い
品質・正確性リスク	AIの出力を検証なく業務判断に使用し、誤った契約条件や技術仕様が流通する	高い
コンプライアンスリスク	著作権侵害コンテンツの生成、個人情報保護法への抵触	高い

特に深刻なのは情報漏洩リスクです。過去発生した事例のように、エンジニアが社内ソースコードをChatGPTに入力したことで機密情報が外部に流出する事態は、どの企業でも起こり得ます。

「禁止」では解決しない構造的な問題

リスクを恐れてAI利用を全面禁止にする企業もありますが、これは長期的には逆効果です。

全面禁止は競争力低下を招くだけでなく、従業員が個人デバイスで非公式にAIを使う「シャドーAI」を助長し、かえってリスクを見えにくくします。

つまり、求められるのは「禁止」ではなく、リスクを可視化・統制しながら利活用を推進する仕組みとしての申請フローです。

関連記事：
【入門】シャドーAIとは？意味・リスク・対策ステップを解説

AI利用申請フローが形骸化する3つのパターン

申請フローを導入しても機能しなくなるケースには、共通するパターンがあります。

パターン1：一律審査の過負荷

全てのAI利用を同じ審査基準・同じ承認者で処理しようとすると、承認待ちが常態化します。議事録の要約と、顧客の個人情報を含む分析では、当然リスクの大きさが異なります。にもかかわらず同一フローで処理すれば、低リスクな利用まで滞留し、現場のフラストレーションがシャドーAIへの動機となります。

パターン2：ルールの陳腐化

生成AIの進化速度は極めて速く、数か月単位で新サービスや新機能が登場します。初期に策定したルールが半年後には実態と乖離し、「ルールに書いていないから問題ない」という抜け道が生まれます。

パターン3：利用実態の不可視

申請時点では管理できても、承認後の実際の利用状況を追跡する仕組みがなければ、当初の申請内容と異なる使い方が広がっても気づけません。申請フローが「入口だけの門番」になり、運用全体の統制力を失います。

これら3つのパターンに共通するのは、申請フローを「一度作れば完成する静的なルール」として捉えている点です。次のセクションでは、この問題を構造的に解決するフレームワークを紹介します。

形骸化しないAI利用申請フローの設計フレームワーク

申請フローの形骸化を防ぎ、ガバナンスと利活用推進を両立するために、本記事では独自の「GATEモデル」を提案します。

GATEとは、4つのフェーズの頭文字を取ったものであり、同時に「AI利用の門（Gate）をどう設計するか」という本質を表しています。

フェーズ	名称	目的	主なアクション
G	Grade （等級分類）	リスクに応じた利用区分の設定	AI利用ユースケースをリスクレベルで3〜4段階に分類
A	Approve （承認設計）	等級に応じた承認プロセスの最適化	承認者・審査基準・SLAを等級ごとに定義
T	Track （追跡・監視）	承認後の利用実態の可視化	ログ収集・利用状況のモニタリング・逸脱検知
E	Evolve （改善・進化）	ルールと運用の継続的アップデート	定期レビュー・ルール改訂・新ツール評価

以降、各フェーズの具体的な設計方法を解説します。

Grade（等級分類）：リスクに応じた利用区分を設計する

リスク等級の分類基準

最初のステップは、自社で想定されるAI利用ユースケースを洗い出し、リスクの大きさに応じて等級を分類することです。等級分類の軸は以下の3つが基本となります。

取り扱うデータの機密性：公開情報のみか、社内機密を含むか、個人情報や顧客データを含むか
AIの出力が影響する意思決定の重大性：内部の参考資料か、顧客への提出物か、法的・財務的な判断に直結するか
利用するAIサービスのデータ取り扱いポリシー：入力データが学習に利用されるか、データの保管場所はどこか

等級分類の設計例

等級	リスクレベル	ユースケース例	承認要件
Level 1	低	公開情報の要約、ブレスト支援、メール文面の推敲	事前申請不要（包括承認）
Level 2	中	社内文書の要約、議事録作成、コード補助（機密性の低いもの）	部門長承認
Level 3	高	顧客データを含む分析、契約書ドラフト作成、外部公開コンテンツ生成	情報セキュリティ部門 + 法務承認
Level 4	極めて高い	個人情報・医療情報・金融データの処理、自動化された意思決定	CISO/DPO承認 + 個別リスクアセスメント

ここで重要なのは、Level 1（低リスク）を明確に定義し、包括承認とすることです。低リスクな利用にまで個別申請を求めると、前述の「一律審査の過負荷」に陥ります。「ここまでは自由に使ってよい」という線引きを明示することが、現場の利活用推進とガバナンスの両立につながります。

Approve（承認設計）：等級に応じた審査プロセスを構築する

承認フローの設計原則

等級分類ができたら、次は各等級に対応する承認フローを設計します。設計にあたっては、3つの原則を意識してください。

比例原則：リスクの大きさに承認の厳格さを比例させる。低リスクには軽い手続き、高リスクには厳格な審査を
SLA（承認期限）の明示：承認にかかる日数の目標を各等級で定める。期限が曖昧だと申請者の不満がシャドーAI化の温床になる
判断基準の明文化：承認者の個人的判断に依存しないよう、チェックリスト形式で審査基準を標準化する

承認フロー設計の具体例

Level 2の承認フロー例：

□申請者がフォームを提出
→ 利用目的・対象データ・使用ツールを記載
→ 部門長がチェックリストに基づき審査（目標：申請から2営業日以内）
→ 承認
→ 利用開始（有効期間：6か月、更新時に再申請）

申請フォームの設計も重要です。自由記述だけのフォームでは申請内容のばらつきが大きくなり、審査が属人化します。以下のような選択式の項目を含めることで、審査の効率と品質を両立できます。

利用するAIサービス名（選択式 + その他自由記述）
入力するデータの種類（公開情報／社内一般／社内機密／個人情報等から選択）
AI出力の用途（社内参考資料／社内正式文書／顧客提出物／外部公開物等から選択）
出力の人的レビュー体制（セルフチェック／ピアレビュー／専門家レビュー）

Google Workspaceを活用している企業であれば、GoogleフォームとAppSheetを組み合わせることで、申請フォームの作成から承認ワークフローの自動化まで、比較的短期間で構築できます。

Track（追跡・監視）：承認後の利用実態を可視化する

なぜ「承認後」の監視が不可欠なのか

申請・承認のフローが整っても、承認後の利用実態を追跡しなければ、フローは「入口の門番」に過ぎなくなります。実際には、承認時の申請内容と実際の利用方法が乖離するケースは珍しくありません。

「社内文書の要約」として承認を得たツールで、いつの間にか顧客データを含む分析を行っていた、という事態を防ぐ必要があります。

技術的な監視手段

利用実態の追跡には、技術的な統制を組み合わせることが効果的です。Google Cloudのサービスを例に挙げると、以下のような組み合わせが考えられます。

監視目的	Google Cloudサービス	活用方法
機密データの外部送信検知	Cloud DLP（Data Loss Prevention）	AIサービスへの入力データをスキャンし、個人情報やクレジットカード番号等の機密情報を含む場合にアラートまたはブロック
APIアクセスの制御とログ収集	VPC Service Controls / Cloud Audit Logs	Vertex AI等のAI APIへのアクセスをプロジェクト単位で制御し、全リクエストのログを記録
利用状況のダッシュボード化	Cloud Monitoring / Looker	API呼び出し数、利用部門、データ量等を可視化し、異常な利用パターンを検知

特にCloud DLPは数百のデータ検出器（infoType）を備えており、日本のマイナンバーや運転免許証番号といった国内固有の個人情報も検出対象に含まれます。AI利用申請フローの技術的な裏付けとして、非常に有効な手段です。

また、自社でVertex AIを利用している場合、Cloud Audit Logsを通じて「誰が、いつ、どのAPIを、どのプロジェクトで呼び出したか」を記録・追跡できます。Gemini for Google Workspaceの利用状況についても、Google Workspace管理コンソールのログイベントから確認が可能です。これにより、承認済みの利用範囲内で運用されているかどうかをエビデンスベースで確認できます。

Evolve（改善・進化）：ルールの陳腐化を防ぐ仕組みを組み込む

定期レビューサイクルの設計

生成AI領域の変化速度を考慮すると、AI利用申請フローのルールは最低でも四半期に一度の見直しが必要です。レビューにおける確認事項は以下のとおりです。

等級分類の妥当性：新たに登場したAIサービスやユースケースが既存の等級に適切にマッピングされるか
承認フローの効率性：承認SLAは守られているか、ボトルネックはないか
インシデント・ヒヤリハットの分析：期間中に発生したAI関連のインシデントやヒヤリハットを分析し、ルールに反映すべき改善点はないか
シャドーAIの実態調査：ネットワークログやSASE（Secure Access Service Edge）の情報をもとに、未承認のAIサービスへのアクセスがないか確認

現場フィードバックの吸い上げ

ルールの改善において最も貴重な情報源は、現場の声です。申請フローが煩雑すぎるという不満も、想定外のユースケースが生まれているという報告も、フロー改善のヒントになります。

四半期レビューの際に、各部門のAI利用推進担当者（AI Champion）からフィードバックを収集する仕組みを設けることを推奨します。これにより、経営層・情報システム部門の視点だけでなく、現場の実態に即したルール改訂が可能になります。

新ツール・新サービスの評価プロセス

Evolveフェーズで特に重要なのが、新しいAIツールやサービスの評価プロセスです。従業員から「このAIツールを使いたい」というリクエストがあった際に、どのように評価・判断するかを事前に定めておく必要があります。

評価の主要チェック項目は以下のとおりです。

サービス提供者のデータ取り扱いポリシー（入力データの学習利用有無、保管場所、削除ポリシー）
セキュリティ認証の取得状況（SOC 2、ISO 27001等）
既存の社内システムとの連携可否
自社のGrade（等級分類）のどのレベルに該当するか

XIMIXによる支援

AI利用申請フローの設計は、情報セキュリティ、法務・コンプライアンス、IT基盤、そして各事業部門の業務理解が交差する領域です。社内の情報システム部門だけで推進しようとすると、特定の視点に偏ったルールになりやすく、現場との摩擦が生じがちです。

私たちXIMIXは、Google Cloud・Google Workspaceの導入支援を通じて培ったガバナンス設計の知見と、多くの中堅・大企業を支援してきた実績をもとに、AI利用申請フローの設計から技術実装、運用定着までを一貫して支援しています。

AI利用の申請フローは、一度作れば終わりではなく、組織と技術の進化に合わせて育てていく仕組みです。自社だけで試行錯誤を繰り返すよりも、多数の企業支援で得た知見を持つパートナーと共に設計することで、手戻りを最小限にしながら、利活用推進とガバナンスを両立するフローを構築できます。

AI利用のガバナンス設計にお悩みの方は、ぜひお気軽にご相談ください。

XIMIXのGoogle Workspace 導入支援についてはこちらをご覧ください。
XIMIXのGoogle Cloud 導入支援についてはこちらをご覧ください。

よくある質問（FAQ）

Q: AI利用申請フローとは何ですか？

AI利用申請フローとは、従業員が業務で生成AIツールを利用する際に、事前に利用目的・対象データ・使用ツール等を申請し、所定の承認を得るためのプロセスです。情報漏洩やコンプライアンス違反を防ぎつつ、組織としてのAI利活用を推進するために設計します。リスクレベルに応じて承認の厳格さを段階的に設定することが、形骸化を防ぐポイントです。

Q: AI利用申請フローを作らないとどうなりますか？

申請フローが未整備のままAI利用が広がると、従業員が個別判断で機密データを外部AIサービスに入力するリスクが高まります。加えて、誰がどのツールをどう使っているか把握できない「シャドーAI」の状態となり、インシデント発生時の原因特定や影響範囲の把握が困難になります。事後対応のコストは、事前のフロー設計コストを大幅に上回るのが一般的です。

Q: シャドーAIとは何ですか？どう防げばよいですか？

シャドーAIとは、企業のIT部門や情報セキュリティ部門の承認・管理を受けずに、従業員が個人判断で業務にAIツールを利用している状態を指します。防止策としては、低リスクな利用については包括承認で手続きのハードルを下げつつ、ネットワークレベルでの未承認サービスへのアクセス検知、および定期的な利用実態調査を組み合わせることが有効です。

Q: Google Cloudを使ったAI利用の監視にはどのサービスが使えますか？

Cloud DLP（Data Loss Prevention）による機密データの検出・マスキング、VPC Service ControlsによるAPIアクセスの境界制御、Cloud Audit Logsによる操作ログの記録が主要な手段です。これらを組み合わせることで、AIサービスへの入力データの安全性確認と、利用状況のエビデンスベースの追跡が実現できます。Cloud Monitoringでダッシュボードを構築すれば、利用状況の異常検知も可能になります。

Q: AI利用申請フローはどの程度の頻度で見直すべきですか？

生成AI領域の変化速度を考慮すると、最低でも四半期に一度の定期レビューを推奨します。レビューでは、等級分類の妥当性、承認フローの効率性、発生したインシデント・ヒヤリハットの分析、新しいAIサービスの評価を行います。現場のフィードバックを吸い上げる仕組みも合わせて設けることで、ルールの陳腐化を防ぎ、実態に即した運用を維持できます。

まとめ

本記事では、AI利用申請フローの設計方法を、独自のGATEモデル（Grade／Approve／Track／Evolve）に沿って解説しました。要点を改めて整理します。

AI利用の「全面禁止」は逆効果であり、リスクを統制しながら利活用を推進する仕組みが必要
申請フローが形骸化する主な原因は、一律審査、ルールの陳腐化、利用実態の不可視の3つ
GATEモデルの4フェーズ（等級分類→承認設計→追跡・監視→改善・進化）で設計することで、形骸化を構造的に防止できる
特にGrade（等級分類）で低リスク利用を包括承認とすることが、シャドーAI防止と利活用推進の両立の鍵
Google CloudのDLP、VPC Service Controls、Audit Logs等を活用した技術的統制との組み合わせが実効性を高める

生成AIの進化は止まりません。フローの整備が遅れるほど、シャドーAIの浸透は進み、後からガバナンスを整える難易度とコストは増大します。逆に、今この段階で実効性ある申請フローを構築できれば、AIの恩恵を安全に享受しながら競争優位を確立する基盤となります。

自社のAI利用申請フローの設計・見直しを検討されている方は、GATEモデルの各フェーズを自社の状況に当てはめるところから始めてみてください。そして、技術的な統制の実装や組織横断的なフロー設計に課題を感じた際には、XIMIXのようなパートナーの活用もぜひご検討ください。

執筆者紹介

XIMIX Google Cloud チーム

監修：増谷謙介（クラウドインテグレーション部テクニカルエキスパート）。2018年よりGoogle Cloudビジネスに携わり、営業からマーケティング、ビジネス立ち上げまで幅広い業務を通じてGoogle Cloudの導入・活用を推進。Google Cloud専業パートナー、コンサル系パートナー企業を経て現職。Google Cloud Partner Tech Influencer Challenge 2025受賞。Google Cloud Next Tokyo 2025に登壇(ITmedia掲載)。保有資格はGoogle Cloud Digital Leader、生成AIパスポート、情報セキュリティマネジメント、GAIQ、Google教育者レベル1など。

この執筆者の記事一覧