レッスン3：利用申請と承認フロー

このレッスンで学ぶこと

利用申請様式に必要な項目を、用途・データ区分・出力の使途・想定リスク・責任者の観点から設計できる
決裁ラインをどこで切るかを、リスクの大きさに応じて判断できる
部門別の利用範囲マトリクスを、許可・条件付き・禁止の3段階で設計できる
事前申請と事後届出を、場面に応じて使い分けられる

前回のレッスンでは、AI利用規程を目的・適用範囲・定義・禁止事項・承認・違反時対応の6部構成で組み立てる方法を学びました。今回のレッスンでは、規程の「承認」の部分を具体化し、利用申請の様式設計から決裁ラインの引き方までを、実務レベルで組み立てます。

なぜ申請フローの設計が難しいのか

規程を書き終えた企業が次に直面するのが、「申請の器」を作る難しさです。申請様式を複雑にしすぎると、現場は面倒に感じて申請せずに使い始めてしまいます。逆に簡単にしすぎると、審査に必要な情報が集まらず、審査担当者が判断できません。この2つの失敗の間で、ちょうどよい設計を見つける作業が、申請フローの設計です。

レッスン1で紹介した中核メッセージの1つ、「ほかの部門に配れない様式は、運用されない」は、この申請フローの設計にもっとも強く当てはまります。法務や情報システムの担当者にとって使いやすい様式ではなく、初めてAIを使いたいと思った営業や人事の担当者が、迷わず埋められる様式を作ることが目標です。

申請様式の項目設計——5つの観点

利用申請の様式には、次の5つの観点を盛り込むと、審査に必要な情報をおおむね過不足なく集められます。

1つ目は、用途です。 「何のためにAIを使うのか」を、できるだけ具体的に書いてもらいます。「業務効率化のため」といった抽象的な記述ではなく、「顧客向け提案資料のたたき台を作成するため」のように、業務の場面が思い浮かぶ粒度で記述してもらうことが重要です。

2つ目は、データ区分です。 AIに入力する予定のデータが、どのような性質のものかを申請者自身に選んでもらう項目です。公開情報のみを扱うのか、社内限定の情報を扱うのか、個人情報や機密情報を扱う可能性があるのかを、選択式で答えられるようにしておくと、申請者の負担が減ります。データの区分そのものの分類基準は、AI活用関連の入門コースが扱う領域であり、本コースではその分類を申請様式にどう落とし込むかという設計の側面を扱います。

3つ目は、出力の使途です。 AIが生成した内容を、どこでどう使うのかを記述してもらいます。社内資料の下書きとして使うのか、顧客向けに直接出すのか、意思決定の参考にするのかによって、必要な確認プロセスの重さが変わります。

4つ目は、想定リスクです。 申請者自身に、この用途で想定されるリスクを一言でも書いてもらう項目です。専門的なリスク分析を求めるのではなく、「顧客の個人情報を扱う可能性がある」「生成内容をそのまま外部に発信する可能性がある」といった、申請者の目線での気づきを記録してもらうことに意味があります。

5つ目は、責任者です。 申請の内容に責任を持つ人物を明記してもらいます。多くの場合、申請者本人の直属の上長が責任者となりますが、部門を横断するプロジェクトでは、プロジェクトの責任者を明記してもらう運用も考えられます。

項目	記入してもらう内容	審査での使い方
用途	具体的な業務場面	妥当性の一次判断
データ区分	扱うデータの性質（選択式）	リスクの重さの判定
出力の使途	生成内容の使われ方	確認プロセスの重さの判定
想定リスク	申請者自身が気づいたリスク	見落としの補足材料
責任者	内容に責任を持つ人物	事後のフォローアップ先

💡 ポイント 5つの項目すべてを自由記述にすると、申請者の負担が増え、記入内容にもばらつきが出ます。データ区分や出力の使途のように選択肢で答えられる項目は選択式にし、用途や想定リスクのように個別性が高い項目だけ自由記述にすると、申請しやすさと情報の質を両立できます。

申請から承認までの全体フロー

個別の項目や決裁ラインを見る前に、申請から承認までの流れを、1つの図として押さえておきます。

flowchart TD
  A[申請者が様式に記入] --> B[リスクの大きさを機械的に判定]
  B -->|低| C[直属の上長が承認]
  B -->|中| D[上長 + 事務局が確認]
  B -->|高| E[事務局 + AI委員会で審議]
  C --> F[AI台帳へ登録]
  D --> F
  E --> F
  F --> G[利用開始]

この図が示すとおり、申請の入口は1つでも、リスクの判定結果によって通る経路が分岐し、最終的にはすべての経路がAI台帳への登録という同じ出口に合流します。この「入口は1つ、出口も1つ、途中の経路だけが分岐する」という構造を保つことが、申請フローをわかりやすく保つ鍵です。経路が増えるたびに別々の出口を作ってしまうと、どの申請がどこまで進んでいるのか、事務局が把握しにくくなります。

決裁ラインをどこで切るか

申請様式が固まったら、次に決めるのは「誰が承認するか」という決裁ラインです。すべての申請を同じ重さで扱う必要はありません。リスクの大きさに応じて、決裁ラインを段階的に分ける設計が実務的です。

多くの企業で採用されている考え方は、リスクの大きさを申請内容から機械的に判定し、それに応じて決裁ラインの階層を変える方式です。次の表は、その一例です。

リスクの大きさ	典型的な申請内容	決裁ライン
低	公開情報のみを扱い、出力も社内限定で使う	直属の上長の承認のみ
中	社内限定の情報を扱う、または出力を顧客向けに使う	上長に加え、事務局の確認
高	個人情報・機密情報を扱う、または新規のAIサービスを初めて導入する	事務局に加え、AI委員会での審議

この階層設計の狙いは、低リスクの申請にまで重い決裁を求めて現場の負担を増やさないことと、高リスクの申請には確実に専門的な目を通すことの、両立です。AI委員会という体制については、レッスン5で詳しく扱います。

📝 補足 決裁ラインを設計する際、既存の稟議規程が定める決裁権限との整合を必ず確認してください。稟議規程で「一定額以上の契約は役員決裁」と定められている場合、AIサービスの契約金額がその基準に該当すれば、AI利用規程側の決裁ラインとは別に、既存の稟議フローも並行して通す必要があります。

部門別の利用範囲マトリクス——許可・条件付き・禁止の3段階

個別の申請を一件ずつ審査する仕組みに加えて、あらかじめ「この部門はこの用途までなら申請不要で使ってよい」という範囲を定めておくと、日常的な小さな用途で申請が滞留することを防げます。この範囲を示すのが、部門別の利用範囲マトリクスです。

マトリクスは、部門を縦軸に、用途の類型を横軸に置き、それぞれのマスを「許可」「条件付き」「禁止」の3段階で色分けする形式が扱いやすいとされています。

許可：申請不要で利用してよい範囲。公開情報を使った下書き作成など、リスクが明確に低い用途
条件付き：一定の条件を満たせば利用してよい範囲。例えば「上長の確認を経ること」「出力を対外的に公表しないこと」といった条件付きで許可する用途
禁止：申請の有無にかかわらず利用してはならない範囲。個人情報を含むデータをそのまま外部サービスに入力する用途など

部門	社内資料の下書き作成	顧客向け提案資料の作成	個人情報を含む分析
営業部門	許可	条件付き（上長確認）	禁止
人事部門	許可	—	禁止（別途、個別の申請と審査を要する）
情報システム部門	許可	—	条件付き（AI委員会の事前確認）

このマトリクスはあくまで一例であり、企業の業種や業務内容によって適切な区分は変わります。重要なのは、マトリクスを見れば、自分の部門がどの用途まで申請なしで動けるのかが一目でわかる状態を作ることです。

🔰 初学者の方へ マトリクスは、規程本則ではなく別表として位置づけると、レッスン2で学んだとおり、機動的に更新できます。新しい用途が生まれるたびに、事務局がマトリクスを見直し、必要な区分を追加していく運用が現実的です。

具体例で見る——マトリクスの読み方

先ほどのマトリクスを、実際の場面に当てはめて確認しておきます。営業部門の担当者が、顧客向けの提案資料を作る際に、生成AIで文章のたたき台を作りたいと考えたとします。

まず、部門別の利用範囲マトリクスを確認します。営業部門の「顧客向け提案資料の作成」は「条件付き」に区分されており、条件は「上長確認」です。この場合、担当者は個別の申請様式を提出する必要はなく、上長に一声かけて確認を得たうえで利用を始め、事後届出でAI台帳に反映する、という流れになります。

一方で、同じ担当者が、顧客の購買履歴データを分析してAIに提案内容を考えさせたいと考えた場合は、マトリクス上「個人情報を含む分析」に該当し、営業部門ではこの用途が「禁止」に区分されています。この場合は、マトリクスを理由に利用を見送るか、個別の事前申請として事務局に相談し、高リスクの経路でAI委員会の審議を経る必要があります。

この2つの例からわかるとおり、マトリクスは「申請するかどうか」を担当者自身が最初に自己判定するための道具です。マトリクスがあることで、事務局に相談すべき案件と、部門内で完結できる案件を、担当者自身で仕分けられるようになります。

💡 ポイント マトリクスの価値は、審査の手間を減らすことだけではありません。「この用途は相談が必要らしい」と担当者自身が気づける状態を作ることこそが、シャドー的な利用（組織が把握しないままAIが使われる状態）を防ぐ、もっとも効果の高い施策です。

事前申請と事後届出の使い分け

すべての利用を事前申請の対象にすると、日常的な軽微な利用まで申請の負担がかかり、現場の不満が高まります。一方で、すべてを事後届出にすると、リスクの高い利用まで見過ごされる可能性があります。実務では、この2つを使い分ける設計が有効です。

事前申請は、先ほどのマトリクスで「条件付き」や個別審査が必要な用途に適用します。利用を始める前に、審査を経て承認を得る仕組みです。

事後届出は、マトリクスで「許可」に区分された、日常的でリスクの低い用途に適用します。利用を始めた後、一定期間内に「この用途で使い始めた」という情報を台帳に反映するための届出です。事後届出の主な目的は、審査ではなく、レッスン4で扱うAI台帳の網羅性を保つことにあります。

事前申請と事後届出を、リスクの大きさに応じて使い分けることで、審査の負荷を高リスクの案件に集中させながら、低リスクの日常利用についても台帳から漏れさせない、という両立を図れます。

⚠️ 注意 事後届出を導入する際によくある失敗は、「届出さえ出せば何でも使ってよい」という誤解が現場に広がることです。事後届出の対象は、あくまでマトリクスで「許可」に区分された低リスクの用途に限られることを、周知の段階で明確に伝える必要があります。

申請が滞留する典型パターンと対処

申請フローを整えても、実際に運用を始めると申請が滞留する場面に必ず遭遇します。よく見られる典型パターンと、その対処を整理します。

パターン1：審査担当者の判断待ちで止まる。 審査担当者がAIの技術的な内容を理解できず、判断に時間がかかるケースです。対処としては、審査の観点をあらかじめチェックリスト化しておき、専門知識がなくても機械的に確認できる項目と、専門家の判断が必要な項目を分けておくことが有効です。

パターン2：決裁者が不在で止まる。 決裁者の出張や休暇で承認が止まるケースです。対処としては、決裁者が不在の場合の代理決裁のルールを、あらかじめ規程または細則に定めておくことが有効です。

パターン3：申請内容が不十分で差し戻しが繰り返される。 申請様式の記入例やFAQが整備されておらず、申請者が何を書けばよいかわからないまま提出してしまうケースです。対処としては、申請様式に記入例を添えることと、よくある差し戻し理由をFAQとして公開しておくことが有効です。

パターン4：新しいAIサービスの評価に時間がかかる。 初めて社内で使われるAIサービスの場合、ベンダー審査を含めた確認に時間がかかり、申請者を長く待たせてしまうケースです。ベンダー審査の詳細はレッスン6で扱いますが、あらかじめ標準的な審査期間の目安を申請者に伝えておくことで、不満を軽減できます。

📖 もっと詳しく 申請の滞留状況は、レッスン8で扱うモニタリング指標の1つとして継続的に把握しておくことをおすすめします。「申請から承認までの平均日数」を定点観測しておくと、フローのどこにボトルネックが生じているかを、感覚ではなくデータで把握できます。

既存の稟議フローに載せるか、独立させるか

最後に、実務上よく議論になる論点として、AI利用の申請を、既存の稟議システムに載せるべきか、独立した申請の仕組みとして作るべきかを整理します。

既存の稟議フローに載せる利点は、申請者にとって使い慣れたシステムで完結できることです。新しいツールの操作を覚える必要がなく、導入の障壁が低くなります。一方で、稟議システムの項目設計を自由に変更できない場合、レッスン3で扱った5つの観点をすべて反映しきれないことがあります。

独立した仕組みとして作る利点は、AI固有の項目を過不足なく設計できることです。一方で、申請者にとっては新しいツールを覚える負担が生じ、既存の稟議とAI利用申請の二重管理になるリスクもあります。

どちらを選ぶべきかは、企業が既に持つ稟議システムの柔軟性と、想定される申請件数によって変わります。申請件数が少ない企業では、既存の稟議フローにAI固有の項目を追加する形で対応できることが多く、申請件数が多く見込まれる企業では、専用の仕組みを設けたほうが、審査担当者の負担を軽くできます。

実務では、両者を組み合わせるハイブリッドな設計もよく見られます。契約金額が一定以上のAIサービス導入は既存の稟議フローに載せ、日常的な用途の申請だけを専用の仕組みで扱う、という切り分けです。この場合、契約に関する意思決定は既存のガバナンスの枠組みに委ね、日常利用の管理はAI固有の仕組みに任せることになり、それぞれの得意な範囲を活かせます。どちらの設計を選ぶ場合でも、申請者から見て「どちらに出せばよいかわからない」という状態を作らないよう、申請の入口を案内する簡単なフローチャートを用意しておくと、混乱を防げます。

まとめ

このレッスンでは、以下のことを学びました。

利用申請様式は、用途・データ区分・出力の使途・想定リスク・責任者の5つの観点で設計する
決裁ラインは、リスクの大きさに応じて段階的に分けることで、現場の負担と審査の質を両立できる
部門別の利用範囲マトリクスを許可・条件付き・禁止の3段階で設計すると、日常的な利用での申請滞留を防げる
事前申請と事後届出を使い分け、審査の負荷を高リスクの案件に集中させる
申請が滞留する典型パターンには、審査基準・代理決裁・記入例・審査期間の目安を整えることで対処できる
既存の稟議フローに載せるか独立させるかは、稟議システムの柔軟性と申請件数の見込みで判断する

次のレッスンでは、承認されたAIサービスを継続的に管理する「AI台帳」と、利用開始前に確認すべき「AI影響評価」を扱います。

確認クイズ

このレッスンの理解度をチェックしましょう。