AI利用申請が複数部署から来るようになったときの承認フロー設計

生成AIの利用申請が、営業部門から、経理部門から、製造部門から、それぞれ別々のタイミングで、別々のフォーマットで情シスに届くようになった——これは社員数100〜300人規模の会社で、生成AI活用がひとりの担当者の目の届く範囲を超えて広がり始めたときに、よく起こる状況です。ひとり情シスの段階では、申請してくる相手は数人程度で、担当者が個別にヒアリングし、口頭やメールのやり取りだけで承認していても、それほど大きな支障はありませんでした。しかし部署が増え、申請件数が増えると、この場当たり的な対応は破綻し始めます。誰が何を申請したか把握しきれなくなり、似たような申請なのに部署によって判断基準が違ってしまう、といった問題が表面化します。このガイドでは、複数部署からの申請を、チーム体制で受け付け・承認・管理していくための仕組み化の方法を解説します。

場当たり対応が破綻する典型パターン

複数部署から申請が来るようになった際、多くの情シスチームが直面する問題には、いくつかの共通パターンがあります。

まず、申請経路がバラバラになる問題です。ある部署はメールで、別の部署は口頭で、また別の部署はチャットのDMで申請してくるといった状態になると、情シス側で申請の全体像を把握すること自体が難しくなります。どの申請が処理済みで、どれが未対応なのか、担当者の記憶やメールボックスの中身を頼りに管理する状態は、複数人体制になるとさらに悪化します。チームメンバーの誰がどの申請を処理したのか、他のメンバーには見えないためです。

次に、判断基準のばらつきです。同じような内容の利用申請でも、対応する担当者によって「これは許可してよい」「これは要確認」という判断が微妙に異なることがあります。ひとりで判断していた頃は、少なくとも基準は一貫していましたが、複数人が申請を処理するようになると、基準を明文化していない限り、担当者ごとの解釈の違いが表面化します。

さらに、利用者管理の抜け漏れです。誰が、どのツールを、いつから使う許可を得ているのかという記録が整理されていないと、後から「この人は本当に許可された利用者なのか」を確認できなくなります。これは前段のガイドラインが順守されているかをモニタリングする土台にもなる情報であり、部署をまたいで広がる生成AI利用、ガイドライン運用をチームで回す方法で扱ったモニタリング体制も、この利用者管理の記録が整っていることを前提にしています。

承認フローを設計する前に決めるべき3つの軸

承認フローを具体的に組み立てる前に、まず次の3つの軸について、チームとしての方針を固めておく必要があります。

これらの軸は、会社の規模やリスク許容度によって最適解が異なります。すべての申請を厳格に審査しようとすると、現場の利用開始が遅れ、結果として「正式な申請をせずに使い始めてしまう」というシャドーAI化を誘発しかねません。逆に緩すぎる承認フローは、情報漏えいなどのリスクをチェックできないまま利用が広がってしまいます。両極端を避け、リスクに応じたメリハリのある設計を目指すことが重要です。

リスクに応じた承認レベルの段階分け

申請内容を一律に扱うのではなく、リスクの大きさに応じて承認レベルを段階分けする設計が、実務上もっとも運用しやすい形です。

1. 簡易承認レベル: 既に社内で利用実績のあるツールを、追加の利用者として申請するケース。機密情報を扱わない用途に限定されていれば、情シスチームの担当者が単独で承認できる
2. 標準承認レベル: 新しいツールの導入申請、あるいは機密性のある情報を扱う用途での利用申請。情シスチーム内で複数人による確認を経て承認する
3. 重点確認レベル: 顧客の個人情報や契約情報など、特に機密性の高い情報を扱う用途、あるいは外部への情報連携を伴うツールの申請。情シスチームだけでなく、法務・セキュリティ責任者や上長の承認を要する

この段階分けにより、大半を占める簡易な申請を素早く処理しつつ、リスクの高い申請には相応の慎重さを確保するという、両立が難しい2つの要求にバランスよく応えられます。段階分けの基準は、ガイドラインで定めた機密情報の分類（機密情報をAIに入力しないためのルール設計を扱った記事で解説している分類基準など）と整合させておくと、判断の一貫性が保ちやすくなります。

部署ごとの申請パターンの違いを踏まえて設計する

承認フローを一律の様式で設計しようとすると、部署ごとの実態に合わず、かえって現場の負担を増やしてしまうことがあります。部署によって、生成AIに求める用途や扱う情報の性質は大きく異なります。

• 営業部門: 提案書・メール文面の作成支援など、社外向けの文書生成に使われることが多く、顧客情報の入力有無が承認判断の分かれ目になりやすい
• 経理・人事部門: 給与・契約情報など機密性の高い個人情報を扱う場面が多く、慎重な確認を要する申請の比率が高くなりやすい
• 製造・現場部門: マニュアル作成や現場の記録整理など、比較的機密性の低い用途が中心になることが多いが、部署の情報リテラシーにばらつきが出やすく、申請自体が形骸化しやすい

部署ごとにこうした傾向を把握しておくと、申請フォームの案内文や、承認担当者が確認すべきポイントを部署特性に応じて微調整できます。例えば、経理・人事部門からの申請には機密情報の項目確認を厚めに、製造・現場部門には申請そのものを行う習慣づけを重視する、といった具合です。すべての部署に画一的なフローを当てはめるのではなく、共通の骨格は維持しつつ、運用の重点を部署ごとに調整する姿勢が、複数部署からの申請に対応する上で現実的です。

申請受付の窓口を一本化する

複数の経路から申請が届く状態を解消するには、申請の入口を一本化することが第一歩です。フォームツールやチケット管理システムを使い、「AI利用申請はこのフォームから」という単一の窓口を用意し、口頭やメールでの個別申請は原則として受け付けない運用に切り替えます。

申請フォームは、口頭やメールと比べて手間がかかるという印象を与えないよう、記入項目を必要最小限に絞ることが重要です。項目を欲張りすぎると、記入の負担が大きくなり、結局フォーム外での問い合わせに逃げられてしまいます。窓口を一本化する際に、申請フォームに含めておくべき最低限の項目は次の通りです。

• 申請者の氏名・所属部署
• 利用したいツール名（新規ツールの場合はサービス概要も）
• 想定する利用目的・業務内容
• 取り扱う情報の種類（機密情報を含むかどうか）
• 希望する利用開始時期

これらの項目があらかじめフォームで構造化されていれば、承認担当者が判断に必要な情報を都度聞き返す手間が減り、処理のスピードが上がります。窓口の一本化は、単に受付を効率化するだけでなく、後述する利用者管理台帳の元データとしても機能する点で重要です。

窓口一本化への移行で起きやすい混乱と対処

申請経路をバラバラな状態から一本化された窓口へ切り替える際、移行期には一定の混乱が生じやすいことも想定しておくべきです。これまで口頭やメールで気軽に申請できていた社員からすると、フォーム入力という新しい手順が「面倒になった」という印象を与えかねません。

この移行をスムーズに進めるためには、次のような工夫が有効です。

1. 移行の理由を明確に伝える: 「申請の見落としを防ぎ、承認までの時間を短縮するため」という前向きな理由を伝え、単なる手続きの厳格化と受け取られないようにする
2. 移行期間を設ける: 切り替え直後の一定期間は、旧来の経路で申請が来た場合も受け付けつつ、フォームでの申請を案内する運用にし、急な断絶を避ける
3. 部署の窓口担当者経由でフォームの使い方を周知する: 全社への一斉メールだけでなく、各部署の窓口担当者から個別に案内してもらうことで、浸透のスピードが上がる

窓口の一本化は、承認フロー全体の土台になる重要な変更であるため、拙速に進めるのではなく、周知期間を十分に取りながら定着させることをお勧めします。

部署の窓口担当者との連携を仕組み化する

承認フローを情シスチームだけで完結させようとすると、各部署の業務内容や利用目的の妥当性を正確に判断することが難しい場面が出てきます。特に専門性の高い業務（法務・人事の契約書関連業務など）では、情シスチームだけの視点では、その用途がどれだけ機密性の高い情報を扱うのか判断しづらいことがあります。

このような場合、部署側に「AI利用の窓口担当者」を置いてもらい、申請内容の一次確認を窓口担当者に依頼する連携の形も有効です。窓口担当者は、部署内の業務内容を熟知しているため、「この申請は実務上どの程度の機密情報に触れるか」といった一次的な判断材料を提供してくれます。情シスチームは、その一次情報をもとに、全社共通の承認基準に照らして最終判断を下す、という役割分担です。

この連携を機能させるためには、窓口担当者に対して、承認基準の考え方や、機密情報の分類についての簡単な説明をあらかじめ行っておく必要があります。窓口担当者が基準を理解しないまま一次確認を任されると、かえって判断のばらつきが増える結果になりかねません。窓口担当者向けの説明資料は、一度作って終わりにせず、承認フローの見直しに合わせて更新し、常に最新の基準を反映した状態を保つようにしてください。窓口担当者が異動・交代した際の引き継ぎ漏れも起きやすいため、資料の保管場所と更新の履歴を、担当者個人ではなくチーム側で管理しておくことも忘れずに行ってください。

チーム内での承認担当の分担方法

承認フローをチームで運用する場合、誰が承認を担当するのかを明確に決めておく必要があります。分担の方法にはいくつかの考え方があります。

• 部署別の担当割り振り: 特定の部署からの申請は、その部署の業務内容に詳しいメンバーが優先的に対応する
• 承認レベル別の担当割り振り: 簡易承認レベルはローテーションで誰でも対応し、重点確認レベルは特定のシニアメンバーが必ず関与する
• 一次受付と最終承認の分離: 申請内容の整理・不足情報の確認は誰でも行い、最終的な承認の可否判断は決まったメンバーが行う

どの分担方法を採用するにせよ、承認担当が誰であっても一貫した基準で判断できるよう、判断基準そのものをドキュメント化しておくことが前提になります。担当者個人の裁量に頼った承認フローは、担当者が変わるたびに基準がぶれる原因になります。

「最初は申請が来るたびにその場で判断していましたが、チームが3人になったころ、同じような申請なのに承認された部署とされなかった部署が出てしまい、現場から不満の声が上がりました。判断基準を一覧表にして共有してからは、誰が対応しても同じ結論になるようになり、現場からの信頼も回復しました」

判断基準を一覧表として明文化する

承認担当者の間で判断がぶれないようにするための最も実効性の高い手段は、判断基準を口頭やその場の感覚に頼らず、参照可能な一覧表として明文化しておくことです。一覧表には、代表的な申請パターンと、それに対する標準的な承認レベルの目安を並べておきます。

この一覧表はすべての申請パターンを網羅する必要はなく、よくある申請の典型例をカバーしていれば十分です。表にない新しいパターンの申請が来た場合は、既存のパターンとの類似性を手がかりに、チームで判断基準を追記していく運用にすると、一覧表そのものが実際の申請実績を反映して育っていきます。

承認担当者向けの判断トレーニング

一覧表を用意しても、判断基準を実際に運用できるかどうかは、承認担当者自身がその基準を正しく理解しているかにかかっています。特に、チームに新しいメンバーが加わった際は、いきなり実際の申請対応を任せるのではなく、過去の申請事例をもとにした簡単なトレーニングの機会を設けることをお勧めします。

具体的には、過去に実際に処理した申請のうち、判断が分かれやすかった事例をいくつか選び、新しいメンバーに「自分ならどう判断するか」を考えてもらった上で、実際にどう判断したか、その理由とあわせて共有する、という形式が有効です。こうしたすり合わせを事前に行っておくことで、新しいメンバーが担当に加わった直後から、既存メンバーと大きくずれのない判断ができるようになります。

承認後の利用者管理をどう続けるか

承認フローの最終的な出力は、「誰が、どのツールを、いつから使えるか」という利用者情報です。この情報を承認のたびに記録し、蓄積していくことで、利用者管理台帳が自然と形成されていきます。

台帳に最低限含めておくべき項目は次の通りです。

「見直し予定日」を設けておくことは特に重要です。一度承認した利用が、その後も同じ条件で妥当であり続けるとは限りません。異動によって当初の利用目的がなくなっていたり、扱う情報の機密性が変化していたりする場合があるため、定期的に棚卸しをする前提で台帳を運用してください。この台帳は、前述のモニタリング体制における「利用実態の可視化」の基礎データにもなります。

異動・退職時の利用者情報の更新を忘れない

利用者管理台帳を運用していく上で見落とされがちなのが、異動や退職に伴う情報更新です。ある部署で承認された利用者が別の部署に異動した場合、異動先の業務内容によっては、当初承認した利用目的や機密情報の取り扱い水準が合わなくなることがあります。同様に、退職者のアカウントを利用者管理台帳から削除し忘れると、実態と台帳の情報がずれていき、台帳そのものの信頼性が下がっていきます。

これらの更新を漏らさないためには、人事部門との連携が欠かせません。入退社・異動の情報が人事部門から情シスチームへ確実に伝わる仕組み（定例の情報共有や、システムアカウントの棚卸しに合わせた確認など）を整えておくと、生成AIの利用者管理台帳もあわせて更新しやすくなります。特に退職者については、アカウントの削除と同じタイミングで、生成AIツールの利用権限も棚卸しの対象に含めることを、日々の退職者対応フローに組み込んでおくとよいでしょう。

申請件数が増えたときのスケーラビリティ

会社の規模がさらに拡大し、申請件数が増え続けると、承認フローそのものにも見直しが必要になる場面が出てきます。個別審査を続けていては処理しきれなくなった場合の対応策として、次のような工夫が考えられます。

• 利用実績が蓄積され、リスクが低いと判断できるツールについては、簡易承認レベルの対象を広げ、審査の負荷を下げる
• 部署単位でのまとめ申請（部署内の複数名を一括で申請する形式）を認め、個別申請の件数自体を減らす
• 承認基準が固まってきた領域については、申請フォームでの自己申告と事後確認の組み合わせに移行し、事前承認の対象を絞り込む

これらの見直しは、申請の処理スピードと審査の質のバランスを取りながら、段階的に進めるべきものです。一足飛びに審査を緩めると、リスクの見落としにつながりかねないため、モニタリング体制で実際の逸脱発生状況を確認しながら、慎重に調整していくことをお勧めします。承認フローを緩めた領域については、事後的な抜き取り確認の頻度を一時的に高めるなど、事前審査を軽くする代わりに事後の目配りを厚くするという組み合わせも、現実的な調整方法のひとつです。

承認までのリードタイムをどう管理するか

申請件数が増えていくと、承認までにかかる時間（リードタイム）が徐々に伸びていくことがあります。現場にとって、申請してから実際に使えるようになるまでの期間が長すぎると、「正式な手続きを待つより、個人で使い始めた方が早い」という判断に流れやすくなり、結果的にシャドーAI利用を誘発する原因にもなりかねません。

リードタイムを適切に管理するためには、承認レベルごとに目安となる処理期限を設定し、その期限内に処理できているかを定期的に確認する運用が有効です。

この期限はあくまで目安であり、会社の実態に応じて調整すべきものです。重要なのは、目安を明示しておくことで、申請者が「いつ頃使えるようになるか」の見通しを持てるようにすることと、承認担当者側も処理の滞留に気づきやすくなることです。申請件数が多い時期には、簡易承認レベルの処理を優先的に進め、標準・重点確認レベルの申請は計画的にスケジュールを組むといった工夫で、全体のリードタイムを一定に保ちやすくなります。

却下・保留になった申請への対応

承認フローを運用していると、すべての申請が承認されるわけではなく、却下や保留になるケースも出てきます。この対応の質が、申請者側の承認フローへの信頼感を左右します。

却下・保留とする場合は、単に「不可」とだけ伝えるのではなく、理由を明確に説明し、可能であれば代替案を提示することが望ましい対応です。例えば、機密情報を扱う用途で却下する場合、「この用途では利用できないが、機密情報をマスキングした形であれば利用可能」といった代替の提案ができれば、申請者にとっても納得感が得られやすくなります。

却下・保留の理由と対応履歴も、利用者管理台帳とは別に記録しておくと、同様の申請が別の部署から来た際に、過去の判断を参照して一貫した対応がしやすくなります。特に、却下した理由が「情報漏えいのリスク」なのか「単に予算の都合」なのかによって、申請者側の受け止め方も大きく変わります。理由の種類ごとに記録を分けておくと、後から集計した際に、どのような理由での却下が多いのかという傾向も把握しやすくなり、承認基準そのものの見直しにも活用できます。

承認フローと効果測定の接続

承認フローを通じて蓄積された利用者データは、単に管理のためだけでなく、生成AI導入の効果を測定する際の基礎データとしても活用できます。どの部署で、どれだけの人数が、どのような目的でツールを利用しているかという情報が整理されていれば、部署横断での効果測定を行う際の集計がスムーズになります。この点については、100-300人規模でのAI導入効果測定、部署横断でのROI集計方法で詳しく扱っています。承認フローの設計段階から、将来的な効果測定を見据えて必要な項目を台帳に含めておくと、後から情報を集め直す手間を省けます。

まとめ: 承認フローは「制限」ではなく「見通しを良くする仕組み」

複数部署から申請が届くようになった段階での承認フロー設計は、単に利用を制限するための仕組みではありません。窓口を一本化し、リスクに応じた承認レベルを設け、チームで一貫した基準を運用することで、「誰が何を使っているか分からない」という不透明な状態を解消し、情シスチームが安心して生成AI活用を後押しできる土台を作ることが本来の目的です。

申請件数の増加は、生成AI活用が組織に浸透している証でもあります。場当たり対応のまま放置せず、早い段階でチーム運用に耐える承認フローへ移行しておくことが、後々の混乱を防ぐ最も確実な方法です。

承認フローの定期見直しを組み込む

承認フローは一度設計したら完成というものではなく、部署の増加、利用ツールの多様化、申請件数の変化に応じて、継続的に見直していく前提で運用してください。半期に一度など、あらかじめ見直しのタイミングを決めておくと、フローが実態から乖離したまま放置される事態を防げます。

見直しの際に確認すべき観点としては、次のようなものが挙げられます。

• 承認レベルの段階分けが、実際の申請パターンと合っているか。特定のレベルに申請が偏りすぎていないか
• リードタイムの目安が守られているか。処理の滞留が常態化していないか
• 部署ごとの申請傾向に変化がないか。新たに機密性の高い用途が増えた部署はないか
• 却下・保留となった申請の理由に、繰り返し見られるパターンがないか。あれば、ガイドライン自体の見直しが必要な可能性がある

これらの観点は、チーム内のミーティングで簡単に振り返るだけでも十分な効果があります。承認フローの運用実績を定期的に棚卸しすることで、フローそのものが会社の実態に合わせて育っていく仕組みを維持できます。

小さく始めて、実績を見ながら育てる

承認フロー全体を一度に完璧な形で作り上げようとすると、設計に時間がかかりすぎたり、現場の実態に合わない過剰に厳格なフローになったりしがちです。まずは最低限の骨格（申請窓口の一本化、簡易な承認レベルの区分、利用者管理台帳の運用開始)から始め、実際の申請対応を通じて見えてきた課題に応じて、段階的にフローを精緻化していくアプローチをお勧めします。

完璧な承認フローを最初から目指すのではなく、「今のチームの人数と工数で無理なく回せる範囲」から始め、申請件数やチーム体制の変化にあわせて見直していくことが、複数部署からの申請に長期的に対応し続けるための現実的な道筋です。

承認フローの整備は、情シスチームだけの都合ではなく、現場が生成AIを安心して業務に取り入れられるようにするための土台でもあります。申請から承認までの流れが分かりやすく、待たされる期間の見通しが立ち、却下された場合にも納得できる理由が示される——そうした体験の積み重ねが、現場の情シスチームへの信頼を築き、結果として無許可利用のようなリスクの高い行動を未然に減らすことにもつながります。承認フローを整えることは、単なる事務手続きの整理ではなく、チームと現場の信頼関係を築くための投資であると捉え、腰を据えて取り組んでください。今日の申請件数の少なさに安心せず、部署が増え、利用が広がっていく先を見据えて、早めに骨格を固めておくことが、後になって場当たり対応のツケを払わずに済む一番の近道です。