生成AIの利用申請と承認フローの作り方｜誰が何を記録するか

生成AIを社内で正式に使えるようにしたい。けれど「禁止」のままでも困るし、「自由にどうぞ」とも言えない。この間を埋めるのが利用申請と承認フローです。規程の文面を立派に作っても、申請の出し方と承認の順番が決まっていなければ、現場は黙って個人アカウントを使い続けます。

この記事は、規程の中身ではなくプロセスの設計だけを扱います。誰が申請し、誰が何を見て承認し、何を記録して、どう棚卸しするか。中小企業で実際に回る最小構成まで落とします。

結論：承認フローは4つの部品でできている

生成AIの利用申請と承認フローは、次の4つを決めれば動き出します。逆に、どれか1つでも空白のままだと止まります。

• 申請の要否の線引き：全部を申請対象にすると回らない。会社が契約した標準ツールの通常利用は申請なしにする
• 申請書の記載項目：用途・入力するデータの種類・ツール名とプラン・学習利用の有無・外部送信先の5点が核
• 承認者と承認の階層：低リスクは届出だけで通し、高リスクだけ個別審査に回す二層にする
• 承認後の記録と棚卸し：台帳1枚に残し、プラン変更と退職者を定期的に突き合わせる

承認者が見るべき核心は実のところ1点に集約できます。個人情報保護委員会は2023年6月2日の注意喚起で、個人データを含むプロンプトを入力する場合、そのサービス提供事業者が「当該個人データを機械学習に利用しないこと等」を十分に確認することを求めています（個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」）。つまり承認フローの実体は、「その入力データで、そのツールのそのプランを使って大丈夫か」を誰かが確認した証拠を残す仕組みです。

まず全体像を1枚で押さえてください。

この表の3列目と4列目が、この記事の中身です。1列目の「どこまでがセーフか」という判断基準そのものは規程側の仕事なので、生成AIの社内ルールの作り方とテンプレートで入力禁止情報の決め方を先に固めておくと、申請フローは驚くほど軽くなります。

申請がいる場合といらない場合の線引き

最初に決めるのはここです。多くの会社がここを飛ばして「生成AIを使うときは申請」と書いてしまい、現場が「ChatGPTに誤字を直してもらうのも申請ですか」と聞いてきて止まります。

申請がいらないもの：標準ツール×低リスク入力

次の2条件をどちらも満たすなら、申請は不要にしてよい領域です。

• 会社が契約し、情報システムが条件を確認済みのツールを使っている（アカウントも会社が払い出している）
• 入力するのが公開情報、または自分が書いた文章・一般的な調べものである

この領域を広く取れるかどうかが、フロー全体の成否を決めます。「会社が1〜2本のツールを決めて全員に配り、その範囲内なら自由」という形にすれば、申請が必要な件数は体感で10分の1になります。何人に配るかで迷っているなら、生成AIを全社員に配るか部署に絞るかの判断を先に見ておくと、配布範囲と申請範囲をセットで決められます。

申請が必要なもの：4つのトリガー

申請を必要とする条件は、ツール名で列挙するのではなくトリガーで書くのがコツです。ツール名で書くと新しいサービスが出るたびに改訂が必要になりますが、トリガーなら書き換え不要で済みます。

1. 標準ツール以外を使う（新しいサービス、ブラウザ拡張、無料のオンラインツールを含む）
2. 入力するデータの機密度が上がる（顧客情報・個人情報・未公開の価格や契約条件・ソースコード・人事情報）
3. 出力を人の確認なしで使う（自動返信、自動投稿、自動での判定・採点）
4. 社外に見える形で使う（顧客向け文章の生成、チャットボット、AIが書いた記事の公開）

とくに3番目と4番目は見落とされがちです。経済産業省・総務省のAI事業者ガイドライン（第1.1版）では、AI利用者が取り組む事項として「AIの出力結果を特定の個人又は集団に対する評価の参考とする場合は、人間による合理的な判断のもと、説明責任を果たす」ことが挙げられています。採用・評価・与信のように人を評価する用途は、たとえ標準ツールでも個別審査に回す設計が妥当です。AIエージェントが自分で手を動かす構成を申請させる際の論点は、政府の生成AIガイドライン改定2026とAIエージェント対応の要点で整理しています。

無料アカウント・個人利用の持ち込みはどう扱うか

社員が自分のGoogleアカウントで無料の生成AIを使い、業務の資料を貼り込む。いわゆるシャドーAIです。ここを「禁止」と書いて終わりにすると、見えないまま続きます。

実務で効くのは、禁止と同時に「使いたい理由の届出」窓口を開けておくやり方です。届出は審査ではなく受付で、内容はたった3行で構いません。

• どの業務で使いたいか
• いま何に困っていて、会社の標準ツールでは何が足りないか
• どんな情報を入力することになりそうか

これを集めると、禁止の見回りではなく標準ツールの選定材料になります。「議事録の文字起こしができないから個人アカウントを使っていた」という届出が3件来たら、それは取り締まる話ではなく、会社が文字起こしを含むプランに切り替えるべきという話です。見つけ方の具体策はシャドーAIの見つけ方と整え方にまとめています。

無料プランと法人プランで何が変わるのかを押さえておくと、この窓口での会話が早くなります。契約形態ごとの差は生成AIの個人契約と法人契約の違いで比較しています。

申請書に書かせる項目

申請書は長くするほど通らなくなります。核になるのは5項目で、ここに書かれた内容がそのまま承認者のチェック項目と台帳の列になります。

1. 用途：どの業務の、どの工程か

「業務効率化のため」と書かせてはいけません。承認の判断材料にならないからです。「月次レポートの下書き作成」「問い合わせメールの返信案づくり」「議事録の要約」のように、工程の名前で書かせます。

この粒度にしておくと、後から効果を測れます。半年後に「この用途は本当に続いているか」を聞ける形になっているかどうかが、台帳が生きるか死ぬかの分かれ目です。

2. 入力するデータの種類

ここが審査の本体です。自由記述ではなく選択式にしてください。選択式なら、承認者が迷わず判定でき、申請者も「これは選びにくいな」と自分で気づきます。

• 公開情報のみ（自社サイト・公開資料・一般的な調べもの）
• 社内限りの文書（議事録・社内マニュアル・原稿）
• 取引先の情報（社名・担当者名・やりとりの内容）
• 個人情報（氏名・連絡先・応募書類・健康情報など）
• 未公開の数値（価格・原価・契約条件・未発表の計画）
• ソースコード・設計情報

下の3つにチェックが入った時点で、自動的に個別審査へ振り分けます。どの情報が危ないかの具体例はAIに入力してはいけない情報7つに図解であります。入力してしまった後の扱い、とくに個人情報が報告義務の対象になるかどうかは生成AIへの個人情報の入力は漏えい報告の対象かどうかで解説しています。

3. ツール名とプラン（一番抜ける欄）

申請書で最も抜けやすいのがプラン名です。「ChatGPTを使います」では審査できません。同じブランドでも、無料プランと法人プランではデータの扱いが変わります。

• OpenAI：ChatGPT Business / Enterprise / Edu と API のビジネスデータは、既定でモデルの学習に使わないとしています（Enterprise privacy at OpenAI）。一方、個人向けプランは設定でモデル改善への利用をオフにする操作が必要です
• Anthropic：「By default, we will not use your inputs or outputs from our commercial products (e.g. Claude for Work, Anthropic API, Claude Gov, etc.) to train our models.」と明記しています（Anthropic Privacy Center）。消費者向けプランは別ポリシーです
• Google：Google Workspace のGemini（Gmail・ドキュメント・ドライブ等）について「Gemini やその他の生成 AI モデルのトレーニングと改良にコンテンツが使用されることはありません」と案内しています（Google ドライブ ヘルプ「Gemini でのデータ保護の仕組み」）。個人アカウントで使う無料のGeminiアプリは扱いが異なります

ブランド名が同じでも結論が逆になる。だから申請書にはツール名・プラン名・アカウントの種類（会社払い出しか個人か）の3つを分けて書かせます。各社のポリシーは改定されるので、承認時点の日付と確認したページを台帳に残してください。

4. 学習利用の有無とオプトアウトの状態

3番の裏返しですが、欄として分けます。申請者に次の3択を選ばせます。

• 契約条件により既定で学習に使われない（＝法人プラン・API）
• 設定でオフにした（いつ・どの設定をオフにしたかを書かせる）
• わからない

「わからない」を選べる形にしておくのが肝です。選択肢から外すと、申請者は適当に当たりをつけて埋めてしまい、審査が成立しません。「わからない」が来たら情報システムが規約を見て埋める、という運用にします。

5. 外部送信先と保存先

生成AIの申請で見落とされるのが、入力データがどこを通るかです。確認したいのは3点だけです。

• どの事業者のサービスに送られるか（再販・OEMの場合は実際の処理事業者まで）
• 処理や保存がどの国・リージョンで行われるか
• 入力した内容や履歴が、どこに・どれだけ残るか（会社側のログに残るか、個人のチャット履歴にだけ残るか）

ブラウザ拡張や無料の「AI要約ツール」は、裏側で別の事業者のモデルに投げていることがあります。申請書に「処理している事業者名」を書かせるだけで、調べた結果として申請者自身が取り下げるケースが実務では少なくありません。

申請書は8項目まで。記載例つきにする

上の5項目に加えて、申請者名・所属・希望開始日を入れた8項目が上限の目安です。これ以上増やすと、申請率が落ちます。

そして各欄に記載例を1つずつ添える。これだけで差し戻しが激減します。例：「用途（例：月次の営業レポートの下書き作成。数字は自分で入れ、文章だけAIに書かせる）」。情報漏洩の観点でどこまで書かせるべきかは、生成AI業務利用の情報漏洩対策と社内ガイドライン雛形のチェック項目と照らすと抜けが見つかります。

誰が承認するか

承認者を「上司」とだけ書くと、上司がツールの契約条件を判断できず止まります。逆に全部を情報システムに集めると、情報システムが業務の必要性を判断できず止まります。分けるのが正解です。

情報システム・法務・事業部門の分担

経営層を個別案件の承認者に入れないのが実務のコツです。AI事業者ガイドラインも、経営層の役割は個別の可否ではなく「経営層のコミットメントによる、各組織の戦略や企業体制への落とし込み／文化としての浸透」だとしています。経営層が1件ずつ承認する設計にすると、判断が遅れるだけでなく、基準が属人化します。

承認者が実際に見るチェック項目

承認者に「良さそうか判断してください」と渡しても機能しません。Yes/Noで答えられる項目に落とします。以下は個別審査用の最小セットです。

7項目のうち、現場でいちばん効くのは5番と6番です。5番は申請の半分を「既存ツールで足りる」に変えてコストを止めます。6番は、止め方を書けない申請＝誰も全体を把握していない申請を見つけます。

情シスも法務もいない会社はどうするか

社員20〜30人の会社に専任の情報システム担当はいません。現実的な形は次のどちらかです。

• 1人を「AI窓口」に指名する：総務か、PCに詳しい社員1人。専門家である必要はなく、「規約のデータ利用の項を読んで、わからなければ外に聞く」役です
• 月1回の場で一括判断する：常時受付ではなく、月1回まとめて見る。待ち時間が読める方が、現場の不満は小さくなります

どちらも「担当を決める」ことが前提です。担当がいない状態で進めるときの役割分担は、社内AIの運用担当がいない会社の進め方で3つの役割に分けて整理しています。

承認の階層：低リスクは届出、高リスクは個別審査

全件を同じフローに流すと、どちらかが壊れます。重いフローに揃えれば誰も申請しなくなり、軽いフローに揃えれば本当に危ない案件も素通りします。二層に分けるのが答えです。

どちらに振るかは、申請フォームで自動的に決める

層の振り分けを人間に判断させないのがポイントです。申請フォームで「入力するデータの種類」と「ツール名」を選んだ時点で、第2層に該当する選択肢が1つでも選ばれていたら個別審査と機械的に決めます。

Googleフォームなら分岐、スプレッドシートなら数式1本で判定できます。「この申請はどっちだろう」と考える時間をゼロにすると、フローは目に見えて回り始めます。

返す期限を先に決める（しかも短く）

申請フローが死ぬ最大の理由は「出したのに返ってこない」です。だから回答期限をフローの設計時に決めて、申請フォームの画面に書いておく。第1層は3営業日、第2層は10営業日が目安です。

第1層については「3営業日たっても回答がなければ利用してよい（みなし可）」まで決めておくと、承認者の不在が業務を止めません。ただし、みなし可を第2層に適用してはいけません。危ない案件が無言で通る穴になります。

AI導入の初期は、申請の中身より「誰が判断するのか」が決まっていないことがボトルネックになりがちです。Mihataでも、独自AIの開発やAI導入支援のご相談を受ける中で、ツール選びの前にこの承認フローの整理から始めることが少なくありません。月1回のAIミーティングで、申請の振り分け基準をその会社の言葉に直し、台帳の見方まで含めて社内に残す進め方をしています。記事の途中で恐縮ですが、同じところで止まっている方のお役に立てるかもしれないので、よろしければご覧ください。

承認後の記録と棚卸し

承認して終わりにすると、半年後に誰が何を使っているか誰もわからなくなります。記録の目的は管理のためではなく、前提が変わったときに気づくためです。

台帳に持たせる列

台帳はスプレッドシート1枚で足ります。列はこの11個から始めてください。

1. 申請ID（連番でよい）
2. 申請日／承認日
3. 申請者・所属
4. 用途（工程名）
5. 入力データの種類（選択式の値そのまま）
6. ツール名
7. プラン名
8. 学習利用の扱い（既定オフ／設定オフ／不明）
9. 確認した規約・ポリシーのURLと確認日
10. 承認者（層ごとに列を分ける）
11. 次の見直し日

7番と11番を絶対に省かないでください。プラン名がなければ、プランが変わったときに影響範囲を特定できません。見直し日がなければ、棚卸しは「気がついたとき」になり、やがて来なくなります。

利用者一覧：台帳とは別に持つ

申請台帳は「何を・どう使うか」の記録、利用者一覧は「いま誰にアカウントがあるか」の記録です。混ぜると壊れます。

利用者一覧は台帳から作るのではなく、ツール側の管理画面からエクスポートするのが正解です。法人プランには管理コンソールがあり、メンバー一覧を出せます。台帳と突き合わせると「台帳に無いのに使っている人」「台帳にあるのにアカウントが無い人」が出てきます。前者はシャドーAIの入口、後者は払い出し漏れです。

契約プランの変更を追跡する（最も見落とされる）

承認の前提は「そのプランでは学習に使われない」という契約条件です。ところがプランは変わります。

• トライアルが終わって無料プランに落ちた
• 人数が増えて別プランに切り替えた
• 事業者がポリシーを改定した
• 管理者が「モデル改善への利用」設定を戻してしまった

どれが起きても、承認時の前提は崩れます。そこで台帳に「確認した規約URLと確認日」を残し、棚卸しのたびに同じURLを開き直す運用にします。これは手間のようでいて、10分で終わる作業です。

加えて、支払いの明細を見る担当者に「プラン名が変わったら台帳の担当に伝える」とだけ頼んでおくと、変更の見逃しが減ります。請求額の変化は、プラン変更の一番わかりやすい信号です。

退職者・異動者のアカウント

退職時のチェックリストに生成AIのアカウントが入っていない会社が、まだ多くあります。確認するのは3点です。

• 会社が払い出したアカウントの停止（＝ライセンスの回収。コストにも直結します）
• 個人アカウントで業務の資料を扱っていなかったか（届出の記録と突き合わせる）
• その人の申請に紐づく自動処理が残っていないか（APIキー、連携、自動投稿）

3番目が曲者です。担当者が辞めた後もAPIキーが生きていて、誰も内容を把握していない自動処理が動き続ける。だから申請書の「止め方」欄が要るのです。

棚卸しは半年に1回・30分で終わる形にする

棚卸しでやることは4つだけです。

1. 見直し日が過ぎた行を抽出する（台帳をその列で並べるだけ）
2. 各行の申請者に「まだ使っていますか」をチャットで聞く（返事がなければ停止扱い）
3. 利用者一覧をエクスポートして台帳と突き合わせる
4. 規約URLを開いて、データの扱いが変わっていないか見る

件数が20行程度なら30分で終わります。逆に、第1層を広く取らずに全件を個別審査にしていると、台帳が200行になって棚卸しが不可能になります。申請を軽くすることは、棚卸しを可能にすることと同じです。

フローを軽くしないと、誰も申請しなくなる

ここまでの設計が全部正しくても、運用で崩れるパターンがあります。現場で多いのは次の6つです。

1. 申請書が長い

項目が15個あるフォームは、現場から見れば「使うな」というメッセージです。8項目に削り、記載例を添える。削れないなら、第1層の3項目版を別に用意します。

2. 返事が来ない

最初の数件で「出したのに2週間音沙汰なし」が起きると、その後は誰も出しません。回答期限を画面に書き、第1層にはみなし可を入れます。

3. 却下の理由が「リスクがあるから」

これを言われた申請者は、次からは申請せずに個人アカウントを使います。却下するときは代替案を必ず添える。「このツールは条件が確認できないので不可。同じことは標準ツールのこの機能でできます」まで書けば、却下は嫌われません。

4. 申請の前例が共有されていない

同じ用途の申請が何度も出るのは、前例が見えないからです。台帳の「用途」と「結果」の2列だけを社内に公開すると、申請件数そのものが減ります。「議事録の要約は承認済み」と見えていれば、同じ申請は出ません。

5. 承認者が1人で、その人が忙しい

第1層を所属長に分散させる設計が効くのはここです。情報システムに全件集めると、その1人の繁忙期にフロー全体が止まります。

6. 承認したのに使われていない

これも失敗です。承認＝導入完了ではありません。棚卸しで「使っていない」と出た申請は、ツールが悪いのではなく使い方が社内に残っていないことが多い。申請の承認条件に「使い方を1枚にまとめて共有する」を入れておくと、ここが埋まります。

中小企業で現実的に回る最小構成

情報システム部門がない20〜50人規模の会社なら、必要なのは次の3つだけです。

• 申請フォーム1枚（Googleフォーム。8項目、分岐で第1層／第2層を自動判定）
• 台帳1枚（スプレッドシート。フォームの回答シートに列を4つ足すだけ。承認日・承認者・結果・次の見直し日）
• 月1回の判断の場（既存の定例に15分足す。第2層の案件をまとめて見る）

導入の順番はこうです。4週間で形になります。

4週目の「現状申請」が肝です。新規の申請だけを受け付けると、すでに動いているものが永久に台帳に乗りません。「今使っているものを、咎めずに全部出してください」と1回やる。ここで出てきたものが、そのまま棚卸しの最初の対象になります。

そして忘れずに、申請フローの文書に「この基準はいつ・誰が見直すか」を1行入れてください。AI事業者ガイドライン自体が「Living Document」として更新を重ねる前提で作られており、各社の運用も同じです。環境・リスク分析からゴール設定、運用、評価を回し続ける形が、ガイドラインが示すAIガバナンスの姿です。

まとめ

生成AIの利用申請と承認フローは、規程を立派にすることではなく、軽い申請を広く通し、重い案件だけ止めて、記録を腐らせないという設計の問題です。

• 申請の要否はトリガーで書く（標準ツール外／機密度が上がる／人の確認なし／社外に出る）
• 申請書は8項目まで。プラン名と「学習利用の扱い」を必ず欄にする
• 承認は二層。第1層は所属長・3営業日・みなし可、第2層は情報システム＋法務・月1回の定例
• 台帳にはプラン名・確認した規約URLと確認日・次の見直し日を入れる
• 棚卸しは半年に1回・30分。利用者一覧はツールの管理画面からエクスポートして突き合わせる

この形を作るのに、特別なツールは要りません。フォーム1枚と台帳1枚、月15分の場があれば回ります。むずかしいのは、自社の言葉で「どこまでなら申請なしでよいか」を決めきることです。

Mihataでは独自AIの開発とあわせて、こうした社内の決めごとづくりもAI導入支援の中でお手伝いしています。月1回のAIミーティングで、申請の線引きや台帳の運用をその会社の実情に合わせて整え、担当の方の手元に残る形にしていきます。社内で誰が判断するかから詰まっているようでしたら、現状をうかがったうえで進め方だけお伝えすることもできますので、気軽にご相談ください。