現場が作ったAIエージェントを誰が管理するか｜野良AIを増やさない申請・棚卸し・停止の基準

非エンジニアがAIエージェントや業務用のチャットを自分で作れるようになると、作られたものの数は社内の想定より早く増えます。1人が1本作れば済む話ではなく、試した分だけ残るためです。半年ほど経つと、誰が作ったのか分からないまま動いているものや、作った本人が異動したあとも止まらずに動いているものが出てきます。ここでは、作られた数を減らすのではなく、把握できる状態を保つための最小限の決めごとを扱います。

把握できていないAIが増えていく流れ

社外のサービスを勝手に契約して使うことを指してシャドーITと呼んできましたが、生成AIの場合は少し形が違います。契約そのものは会社が正規に結んでいて、その上で個人が自由に作れる点です。契約の一覧を見ても、その中に何本作られたかは出てきません。

増え方には共通した流れがあります。

誰かが自分の業務で使うものを作る（この時点では本人しか使わない）
便利だったので同じ部署の数人へ共有する
使う人が増え、業務の手順に組み込まれる
作った本人が異動・退職する、または別の業務へ移る
動いているが誰も中身を説明できない状態になる

問題が表に出るのは4から5にかけてですが、手を打てるのは1の時点だけです。3まで進むと業務が依存しているため、止める判断そのものが難しくなります。だからこそ、管理の起点は作られたあとの調査ではなく、作る前の申請に置きます。

内製を広げること自体は続けたうえで管理の形を足す、という順序になります。内製で社内に持つ範囲の全体像は「生成AI・AIエージェントの内製化とは」を参照してください。

作る前に出す申請で何を書かせるか

申請を重くすると誰も出さなくなり、届け出のない状態に戻ります。判断に必要な項目だけに絞ります。目安は、書く側が5分から10分で埋められる量です。

書かせる項目	何を判断するために使うか	書けないときの扱い
対象の業務と、何を任せるか	業務の一部なのか、判断まで含むのか。人の確認を残す必要があるかを見る	業務が特定できていない段階なら、社内データを入れない試用として扱う
扱うデータの種類	個人情報や取引先の情報、未公開の社内情報が入るか。審査の要否がここで決まる	種類を書けない場合は、入れてよいデータを列挙する形に変えて書いてもらう
誰が使うか	本人だけか、部署内か、部署をまたぐか。配る範囲で必要な確認が変わる	本人だけの範囲に限って許可し、広げるときに再度出してもらう
出力をどう使うか	そのまま社外へ出るのか、人が確認してから使うのか	社外へ出る前提の場合は、確認する人を書けるまで許可しない
動かなくなったときの連絡先	業務側の責任者を決めるための項目	作った本人以外に書ける人がいない場合、その業務は個人依存として記録する
止まっても業務が回るか	停止の判断をどこまで急ぐ必要があるかを見る	回らないと答えた場合は、代替の手順を書いてもらう

このうち審査に時間がかかるのは「扱うデータの種類」だけです。他の項目は受け付けた側で判断できるため、データの種類が限定的であれば当日中に返せます。返答が遅いと申請を出さずに作る人が出るため、扱うデータによって審査の重さを分けておきます。使うサービス自体の審査観点は「生成AIのセキュリティ審査チェックリスト」で扱っています。

申請の対象をどこで区切るか

すべての試作を申請対象にすると数が多すぎて回りません。次の3つのどれかに当てはまるものだけを対象にします。

本人以外が使う、または使う予定がある
社内のデータを読み込ませる
他のシステムへ書き込む、または社外へ何かを送る

この3つに当たらないもの、つまり本人が公開情報だけを相手に試しているものは、申請なしで作れる範囲として明示します。作れる範囲を先に示しておくと、線を越えるときに申請が出てきます。

台帳に載せる項目と、更新のきっかけ

申請が通ったものを台帳へ登録します。台帳は監査のために作るのではなく、四半期の棚卸しで判断できる材料を揃えるために作ります。判断に使わない項目は入れません。

台帳の項目	入れる理由	更新のきっかけ
名前と、何をするものか	一覧を見た人が中身を推測できるようにする	作り直したとき
作った人と、業務側の責任者	止める・引き継ぐ判断の相手を特定する	異動・退職・担当替えのとき
使っているサービスと契約の種類	法人契約の範囲内か、個人アカウントかを見る	契約を切り替えたとき
扱うデータの種類	審査の再実施が必要かを見る	読み込ませる範囲を広げたとき
使う人の範囲	止めたときに影響する人数を見る	配る先を広げたとき
直近3か月の利用回数	使われているかを判断する	棚卸しのたび
最後に中身を確認した日	放置されている期間を見る	確認したとき
状態（稼働・停止・引き継ぎ待ち）	止めたものが残り続けないようにする	状態が変わったとき

利用回数は自己申告にすると精度が落ちます。使っているサービス側にログが残る場合はそこから取り、残らない場合は「この四半期に使ったか」の二択で業務側に答えてもらう形で足ります。回数の正確さより、使われていないものを拾えるかどうかが目的です。全社の利用状況を測る方法は「生成AIが社内でどれだけ使われているかを測る」で扱っています。

管理の起点は作られたあとの調査ではなく、作る前の申請に置きます。
棚卸しで分かれた結果は台帳へ戻し、次の四半期の判断材料にします。

四半期ごとの棚卸しで、止めるか残すかを決める

棚卸しは全件を見直す作業ではありません。台帳の中から条件に当てはまるものだけを抜き出し、それについて業務側と話します。全件を見ようとすると本数が増えたときに回らなくなります。

台帳で見る状態	抜き出す条件	既定の扱い
使われていない	直近3か月の利用が0、または使っていないと業務側が回答	停止。業務側が理由を出せば1四半期だけ延長
作った人が社内にいない	作成者が異動・退職し、引き継ぎ先が空欄	引き継ぎ先が決まるまで停止。使われているものは期限を切って探す
誰も中身を説明できない	何をしているかを業務側が説明できない	停止。必要なら作り直す
扱うデータが申請時より広い	読み込ませる範囲や配る先が申請と違う	申請をやり直す。それまでは範囲を申請時に戻す
個人アカウントで動いている	契約が法人のものでない	法人契約へ移す。移せないものは停止
条件に当たらない	使われていて、責任者と連絡先が埋まっている	そのまま継続。中身の確認日だけ更新する

既定の扱いを先に決めておくことが要点です。棚卸しのたびに一件ずつ協議すると時間が足りず、結局すべて残ります。既定を「停止」に置き、残す側が理由を出す形にすると、判断の数が減ります。

止める判断で迷いやすいのは、使われてはいるが本数の少ないものです。ここは利用回数ではなく、止まったときに業務が回るかどうかで見ます。回るなら止めても影響は小さく、回らないなら引き継ぎ先を決める話に移ります。

止めるとは何をすることか

「停止」の中身を決めておかないと、台帳の状態だけが変わって実際には動き続けます。停止のときに行う作業を並べておきます。

動かす設定を止める、または実行できる人を外す
使っていた人へ、代わりの手順を伝える
読み込ませていたデータへの接続を切る
台帳の状態を停止にし、停止した日を入れる
作ったもの自体は一定期間残す（復旧の依頼が来ることがある）

最後の項目を入れておくと、止める判断の心理的な負担が下がります。消すのではなく止めるという扱いにすれば、業務側も同意しやすくなります。

作った人が離れるときの引き継ぎ

異動や退職が決まってから探し始めると間に合いません。台帳に作成者が入っていれば、人事の異動情報と突き合わせて事前に抜き出せます。

引き継ぎで渡すものは3つです。動かし方（誰が何をすると動くか）、直し方（設定や指示文がどこにあるか）、止め方（止めるときに誰へ連絡するか）です。中身の詳しい作りまで引き継げるとは限らないため、動かす・止めるの2つが分かれば当面は回ります。

引き取る人がいない場合は、無理に割り当てません。使われていて代替がないものだけを対象に、作り直すか、既製のサービスへ移すかを検討します。引き取り手のいないまま台帳上の担当者だけを埋めると、次の棚卸しで同じ状態が見つかります。壊れたときに誰が直すかという運用側の設計は「内製したAIエージェントの運用・保守」で扱っています。

情報システム部門と業務側で分担する

止めるか残すかを情報システム部門だけで決めると、業務への影響が見えないまま判断することになり、現場との関係も悪くなります。かといって業務側だけに任せると、止める動機がないため何も止まりません。判断の材料と、判断そのものを分けます。

決めること	情報システム部門が持つ	業務側の責任者が持つ
作ってよい範囲	扱ってよいデータの種類、使ってよいサービス	その範囲内で何を作るか
申請の可否	データとサービスに関する可否	業務として必要かどうか
台帳の維持	一覧の管理、利用状況の収集	自部署の行が実態と合っているかの確認
棚卸しでの停止	条件に当たるものを抜き出す、管理できないものの停止	業務として残す理由の提示、代替手順の用意
引き継ぎ先	引き継ぎ先が空欄のものを通知する	引き取る人を決める

この分け方だと、情報システム部門は「管理できないから止める」までを持ち、業務側は「業務として要るから残す」を出す形になります。どちらも相手の領分を代わりに決めないため、話が止まりにくくなります。全社での推進体制と決裁の流れを整理する場合は「社内のAI推進体制をどう作るか」が使えます。

自社の規模に合わせて減らす

ここまでの内容をすべて備えるのは、作られたものが数十本ある場合の形です。本数が少ない段階で同じ仕組みを入れると、管理の作業だけが先に増えます。段階に応じて残す部分を変えます。

本数が10本に満たない段階では、台帳と申請を1つの表にまとめ、棚卸しは半期に1回で足ります。この段階で重要なのは、作成者と業務側の責任者が全件埋まっていることだけです。

数十本の段階で、申請と台帳を分け、四半期の棚卸しを始めます。既定の扱いを停止側に置くのはこの段階からです。本数が増えると、一件ずつ協議する時間が取れなくなります。

部署をまたいで使われるものが出てきたら、配る範囲の申請を分けます。作った部署以外の人が使い始めると、止めるときの影響が作った部署の外へ広がるためです。この段階では、利用状況を自動で集める仕組みを検討する価値が出てきます。

どの段階でも、決めたことを社内へ示す文書は1つにまとめておきます。利用のルールと作るときのルールが別々の場所にあると、現場は両方を読まないまま作り始めます。文書の作り方は「生成AIの社内利用ルール・利用規定」を参照してください。

まとめ：作られたAIを把握し続けるための要点

把握できなくなるのは作られたあとではなく、作る前に届け出る道が無いときに起きる。管理の起点は申請に置く
申請は5分から10分で書ける量に絞る。対象の業務、扱うデータ、使う人、連絡先、止まったときの影響があれば判断できる
台帳には棚卸しで判断に使う項目だけを入れる。作成者と業務側の責任者、利用の有無、状態が中心になる
棚卸しは全件を見ず、条件に当たるものだけを抜き出す。既定の扱いを停止側に置き、残す理由を業務側が出す形にする
停止の中身（設定を止める、代わりの手順を伝える、台帳を更新する、一定期間は残す）を先に決めておく
情報システム部門は管理できないものを止めるところまで、業務側は業務として残す理由を出すところまでを持つ
本数が少ない段階では台帳と申請を1つの表にまとめる。仕組みを先に増やさない

Augueでは、非エンジニアの担当者が自分でAIを作れる状態を社内に作る支援を行っており、作る範囲を広げることと、作られたものを把握し続ける仕組みづくりを同時に進めています。内製を広げながら管理の形を決めたい方は、是非ご相談ください。

まずは現状をお聞かせください

弊社では具体的な要件が固まっていない段階でも、無料相談で現状をお聞きしていますので、お困りの際はご相談ください。

無料相談を予約する →

よくある質問

現場が勝手に作ることを禁止にすれば済むのではないですか？

禁止は把握できない状態を悪化させることがあります。作ること自体を止めても業務の困りごとは消えないため、個人のアカウントや申請の要らない手段へ移り、記録に残らない形で使われます。止めるかどうかより、届け出れば使えるという道を先に用意するほうが、結果として見える範囲が広がります。禁止するなら、扱うデータの種類など範囲を限った禁止にして、それ以外は申請で通す形にします。

台帳は専用のツールを入れないと運用できませんか？

数十本の規模までは表計算ソフトや社内で使っている情報共有ツールで足ります。専用ツールが要るのは、利用回数の記録を自動で集めたい場合や、本数が増えて手作業の更新が追いつかなくなった場合です。先にツールを選ぶと項目が製品の都合で決まってしまうため、まず手元の表で数四半期回し、何が更新されず放置されるかを見てから検討する順序が取れます。

既に生成AIの利用ルールがある場合、別に決めることはありますか？

利用ルールは主に「何を入力してよいか」を決めたもので、作られたものが残り続けることまでは扱っていないことが多いです。追加で決めるのは、誰が作ったかを記録すること、止める判断の基準、担当者が離れるときの扱いの3点です。既存のルールに章を足す形でも成立するため、別文書を新設するかどうかは社内の管理のしやすさで決めます。

棚卸しの結果、業務側が止めることに同意しない場合はどうしますか？

止める理由が「使われていない」なのか「管理できない」なのかで分けます。使われていないだけなら、次の四半期まで期限を切って残し、それでも使われなければ止めるという扱いが取れます。管理できないことが理由の場合は、引き取る担当者が決まらない限り期限を延ばしても状況は変わらないため、停止の判断は情報システム部門が持つ形にしておきます。