AIに作らせた社内ツールは使ってよい？｜広がる前に決める線引き

「集計用の小さな道具をAIに作らせたら思ったより便利で、いつの間にか部内の全員が使っています」「作った本人が異動すると聞いて、誰も中身を読めないことに気づきました」——生成AIでコードが書けるようになった現場で、同じ時期に出てきはじめた二つの声です。作れるかどうかは、もう論点ではありません。問われているのは、出来上がったものを業務に載せてよいかどうかを、誰がどの基準で決めるのかのほうです。この記事では、AIに作らせた社内ツールについて、使ってよい範囲の3段階、載せてよいデータ、保守と引き継ぎ、台帳と棚卸し、外部に頼む境目までを整理します。

現場でいま、何が作られているのか

最初に、実際に何が作られているかを押さえます。マーケティングの現場でよく出てくるのは、広告の管理画面から落とした数字を毎週ひとつの表にまとめる集計、複数の申込フォームから来た名簿の重複をそろえる名寄せ、問い合わせの本文を内容ごとに仕分ける分類、定例の報告書を決まった形に流し込む自動生成、それに部内だけで使う小さな入力画面です。どれも以前なら情報システム部門か外部の会社に依頼し、数週間かけて作ってもらう類のものでした。

変わったのは、依頼せずに自分で作れるようになった点です。対話しながらAIにコードを書かせるやり方はバイブコーディングと呼ばれ、名前がついてから2年たたないうちに企業の現場まで下りてきました。2026年に公表された米国企業の調査では、毎週作られるコードの51%から75%をAIが生成しているか大幅に書き換えていると答えた回答者が67%にのぼっています。対象は従業員500名以上の企業が88%を占める、IT・エンジニアリング部門の意思決定者200名です。開発の現場ですらこの割合なのですから、業務部門で生まれる小さな道具はもっと軽い気持ちで作られています。

同じ調査では、本番環境に関する社内方針の中にこのやり方を織り込んでいる企業が88%、検証用の環境に限定しているのが5%、完全に禁止しているのは0%でした。禁止という選択肢は、実務の上ではすでに消えています。だとすれば決めるべきなのは、作ってよいかどうかではなく、作ったものをどこまで業務に載せてよいかのほうです。線を引かないまま数だけ増えると、あとから戻すのが難しくなります。

レビューでは高く評価され、本番では壊れている

同じ調査に、読み方の注意が要る対比が出ています。AIが生成したコードの品質について、人が書いたものより高いと評価した回答者は94%（やや高いが61%、大幅に高いが33%）でした。ところが同じ人たちの78%が、本番に入れたあとにインシデントが増えたと答え、82%が過去6か月のうちに本番の障害を経験しています。見た目の出来がよいことと、動かし続けられることは別だ、という結果です。

障害の原因として挙がったのは、他の仕組みとのつなぎ目の失敗が30%、法令や社内規程との抵触が30%、データの整合性の問題が29%、セキュリティ上の弱点が28%でした（複数回答）。並びに意味があります。上位の2つは、道具そのものの出来ではなく、周りとの関係で起きています。単体では正しく動くのに、つないだ先が変わった日に壊れる、という壊れ方です。

マーケの現場に翻訳すると、こうなります。広告の管理画面から落とした表の列名が変わった週に、集計の道具は止まらずに0を返す。名寄せの道具は、全角と半角が混ざった住所を別人として扱い、同じ相手に2通送ってしまう。止まってくれるならまだ気づけますが、動いたまま静かに間違うのがいちばん厄介です。エラーが出ないので、誰も確かめに行きません。

最初に来るのは事故ではなく、静かな依存

いずれ大きな情報漏えいが起きるのではと身構える人が多いのですが、実際に先に来るのは依存のほうです。便利な道具は、作った本人の想定を超えて使われます。最初は自分の週報のためだった集計が、翌月には部署の定例資料の元データになり、半年後には他部署がその数字を引用して会議に出している。どこかの時点で、その道具は「あると便利なもの」から「ないと困るもの」に変わっています。

変わった瞬間に誰も気づかないのが問題です。同じ調査では、人の手による行単位の確認をしないまま本番に入れることが頻繁にあると答えた回答者が62%、AIが生成したコードの25%以上に大幅な手直しが必要だと答えた回答者が74%、経験のある技術者の手直し時間が増えたと答えた回答者が86%ありました。作る時間は減っても、直す時間は消えず、別の人の手元に移っているという構図です。

業務部門で作られた道具の場合、その別の人が社内にいないこともあります。作った本人が異動したあと、残された道具の中身を読める人が一人もいない。動いている間は誰も困りませんが、動かなくなった日にはじめて、その道具が何をしていたのかを誰も説明できないと分かります。困る人の数と、直せる人の数が釣り合っていない状態が、いちばん危ういところです。

「下ごしらえ」と「業務システム」の境目はどこか

ここからが原因の整理です。まず、AIに作らせたものを全部同じ扱いにすると身動きが取れません。線を引く道具として、次の4つの問いを使います。1つでも当てはまるなら、それはもう下ごしらえではありません。

• その道具の出力は、社外の相手（顧客・取引先・広告の配信先）に届くか
• 作った本人以外が動かすか、あるいは本人がいない日にも動く必要があるか
• 読み書きする先に、あとから消せない記録が残るか
• それが止まったとき、締め日や納品日が動くか

4つとも当てはまらないなら、それは下ごしらえです。手元の表を整えるだけの処理、自分が読むために要約させる作業、案を10個出させて自分で選ぶ使い方。ここに重い手続きを持ち込むと、現場は申請を避けて隠れます。軽いものを軽く扱えることが、重いものを申告してもらうための条件になります。禁止の範囲を広げるほど見えなくなる、という逆転がここで起きます。

迷いやすいのは、自分しか使わないのに締め日に効く道具です。月次の請求データを整える処理を自分だけが動かしている場合、使う人は1人でも、止まれば請求が遅れます。この場合は4つ目に当てはまるので、下ごしらえではありません。人数ではなく、止まったときの影響で判断します。

作った本人しか中身を読めない

原因の中心はここにあります。AIに書かせると、動くものが先にできます。中身を読んで理解する工程を飛ばしても結果が出てしまうからです。バイブコーディングの安全対策として公開されている25項目の整理でも、運用後の項目の筆頭に責任者と保守の担当を決めることが置かれ、AIに書かせたので中身を理解していない状態そのものをリスクとして認識すべきだと書かれています。本番で使うものには人の主担当を置く、という考え方です。

読める人がいない状態は、3つの形で効いてきます。ひとつは直せないこと。エラーが出ても、どこを触ればよいか分かりません。ふたつめは影響範囲が見積もれないこと。仕様を少し変えたいときに、どこまで壊れるかが読めません。みっつめは、消してよいかどうかすら判断できないことです。使われていないように見えても、月に一度だけ動く処理かもしれないと思うと、誰も手を出せなくなります。

対処の芽は、作った時点にあります。完成したコードだけを残すのではなく、どういう指示で作らせたか、何を諦めたか、どこが怪しいと思っているかを数行のメモにして一緒に置く。作った本人にしか書けない情報で、しかも作った直後にしか書けません。半年後の自分と、次の担当者の両方がこのメモに助けられます。

扱うデータの線引きが、後回しになる

もうひとつの原因は、道具づくりが最初から本番のデータで始まることです。手元の名簿を読み込ませ、実際の売上の表を貼り付け、動くかどうかを確かめる。試作の段階から、扱っているものが本物です。外部のツールを導入するときには審査があるのに、自分で作るときには誰も見ていないという非対称が、ここで生まれます。

先ほどの25項目の整理では、生成中の運用として、接続情報や認証の鍵、個人情報を指示文にそのまま貼らず、テスト用のダミーに置き換えてから渡すことをルール化する、と挙げられています。あわせて、本番のデータベースに直接つないで書き換えの操作をさせないこと、読み取り専用の複製や開発用の環境に権限を分けることも項目に入っています。参照させる範囲を最小にする、という考え方も同じ列にあります。

業務部門向けに言い直すと、読むのはよいが、書き換えはさせないが最初の線です。集計や名寄せは元のデータを読むだけで足りますし、結果は別のファイルに出せば済みます。読みと書きの両方を許した瞬間に、失敗が取り返せなくなります。取り返せる作業と取り返せない作業を分けることが、データの線引きの実務です。

増えていること自体が、誰にも見えない

3つめの原因は、数が把握されていないことです。外部のサービスは契約が発生するので、少なくとも経理には痕跡が残ります。自分で作った道具にはそれがありません。名前もなく、置き場所は個人の領域で、成果として報告される機会もない。存在しないことになっている道具が、業務を支えている状態が積み上がっていきます。

見えなくなる理由は4つあります。作った本人が大したものではないと思っていること、申請の仕組みが重くて出す気にならないこと、そもそも道具に名前がついていないこと、そして作ったことを評価する場がないので、わざわざ言う理由がないことです。最後の1つは軽く見られがちですが、いちばん効いています。褒められる仕組みがあれば、道具は自分から名乗り出ます。

情報処理推進機構が公表した情報セキュリティ10大脅威の2026年版では、AIの利用をめぐるサイバーリスクが組織向けの項目に初めて入り、3位に置かれました。世の中の関心は明らかに高まっている一方で、社内で作られた道具の一覧を持っている会社はまだ多くありません。対策の前に、いくつあるのかを数えるところから始まります。

使ってよい範囲を、3段階で決める

ここから対策です。最初にやるのは、使ってよい範囲を段階に分け、段階ごとに条件を変えることです。全面禁止も全面自由も現場では機能しません。次の3段階で配ると、現場が自分で判断できるようになります。

段階	どこまでの範囲か	認めるための条件	読ませてよいデータ
第1段階 自分だけ	自分の手元で動かし、出力も自分だけが見る	手続きなし。元のデータを書き換えないことだけ守る	自分が業務で正規に扱っている範囲の写し
第2段階 チーム内	同じ部署の数人が使い、定例の作業に組み込まれる	保守の担当を1人決める。止まったときの代替手順を書く。台帳に登録する	部署が扱ってよい範囲。氏名や連絡先は伏せてから渡す
第3段階 社外に影響	出力が顧客や取引先に届く、他の仕組みにつながる、記録が残る	情報システム部門の確認と責任者の承認。保守の体制を正式に決める	既定の手続きに従う。個人情報や決済に関わるものは単独で判断しない

この表の要点は、第1段階に手続きを一切課さないことです。ここを重くすると、第2段階に上がったものまで申告されなくなります。逆に第3段階は、自分たちだけでは決められない領域として明確に閉じます。迷ったら1つ上の段階として扱う、という原則も一緒に配っておくと、判断のばらつきが減ります。

どの段階でも共通で守ってもらう条件が3つあります。ひとつはAIに判断させないこと。集計や整形はさせても、送ってよいか、出してよいか、良いか悪いかの判定は人が行います。ふたつめは根拠を書かせること。出した数字が、どのファイルのどの列をどう計算した結果なのかを、必ず出力の横に残す形にします。みっつめは人が確認する範囲を先に決めること。全部を疑うと確認に時間がかかりすぎて使われなくなるので、件数と合計と対象期間の3つだけを毎回照らす、というように狭く決めておきます。

載せてよいデータを、書類の名前で決める

データの線引きは、抽象的な言葉で書くと守られません。機密情報は入れない、と書いても、目の前の名簿が該当するのかを現場は判断できないからです。手元にある書類の名前で列挙するのが実務的です。順番はこうなります。

1. そのまま渡してはいけないものを、書類名で書き出す：顧客の氏名と連絡先が入った名簿、未公表の売上や予算の表、人事や評価の記録、他社との契約書、各種の接続情報
2. 渡すなら、伏せてから渡す：氏名は連番に、会社名は記号に置き換える。並び順と件数がそのままなら、道具づくりには十分足りる
3. 読みと書きの権限を分ける：元のデータは読むだけにして、結果は別の場所に出す。書き換えが必要な処理は第3段階として扱う

保存先も1か所に決めます。個人の端末の中に結果が散ると、棚卸しのときに追えなくなりますし、退職や異動でそのまま消えます。共有の場所にフォルダを1つ置き、そこに出すことを条件にすると、あとから数えられます。数えられない場所に置かれたものは、管理の対象にできません。

迷ったときの目安として、この画面をそのまま社外の人に見せられるか、と自分に聞く方法があります。見せられないものが映っているなら、伏せてから渡す。単純ですが、書類名の一覧を作る前でも判断が早くなります。伏せる作業を面倒に感じるうちは、まだ扱ってよい段階に来ていない、と考えることもできます。

作ってよい人と、守ってもらう条件

誰でも作ってよいことにすると管理が破綻し、限られた人だけに絞ると現場が隠れて作ります。現実的なのは、権限を3層に分けたうえで、条件つきで広く開くやり方です。公開されている25項目の整理でも、提案を読むだけの層、手元で動かす層、正式なものに反映できる層、という3層で権限を整理することが最小限の対応として挙げられています。

• 自分がその業務を実際にやっていて、出てきた結果の正しさを自分で見分けられる
• うまくいかなかったとき、AIに作らせる前の手作業にいつでも戻せる
• 出てきた結果をそのまま信じず、元の数字と照らす習慣がある
• 会社が契約したアカウントで作る（個人の契約では設定も記録も追えない）

最後の1つは見落とされがちです。個人向けの契約と法人向けの契約では、入力した内容が学習に使われるかどうか、操作の記録が残るかどうか、管理者が設定を変えられるかどうかが違います。同じサービスでも、契約の種類で扱いがまったく変わります。作ってよい人を決める前に、使ってよいアカウントを決めるのが順番です。

条件を満たさない人が作りたいと言ってきたときは、禁止ではなく組み合わせで対応します。業務を知っている人と、中身を読める人を2人1組にする。片方が作り、もう片方が結果の確かめ方を決める。1人で完結させないことが、そのまま引き継ぎの準備になります。人を増やせない場合は、作る本数のほうを絞ります。

申請は1枚・5項目まで軽くする

段階と条件が決まったら、第2段階以上のものを登録してもらいます。ここで申請を重くすると、必ず潜ります。書式を作る側は網羅したくなりますが、現場が3分で書けない申請は出てきません。台帳に必要な項目は5つで足ります。

• 何をする道具か（1行。広告の週次の数字を1つの表にまとめる、程度で十分）
• 誰が、いつ作ったか
• いま誰が使っているか（人数と部署）
• どのデータを読むか（書類の名前で）
• 止まったときに誰へ言えばよいか

登録すれば使ってよい、という関係を明示することも大切です。審査ではなく登録であると伝えないと、止められることを恐れて出てきません。第3段階に該当するものだけが登録の時点で情報システム部門に回る、という設計にしておけば、現場の負担は変わらないまま重いものだけを拾えます。

• 登録の呼びかけは取り締まりではなく、困ったときに助けられるようにするため、と伝える
• 過去に作ったものを遡って責めない。最初の1回は不問にして集めきる
• 台帳は全員が見られる場所に置く。他部署が同じ道具を作り直す無駄が減る
• 登録が集まらないときは現場ではなく台帳を疑う。項目が多すぎないかを見直す

止まったときに誰が困るかを、先に書く

台帳に載せたら、次は止まったときの備えです。作った直後にここまでやっておくと、引き継ぎの資料がほぼそのまま揃います。順番は次のとおりです。

4つのうち、いちばん効くのは2つ目です。代替手順を1行書けない道具は、業務がその道具に丸ごと依存している証拠になります。書けないと分かった時点で、正式なものに引き上げるか、使う範囲を狭めるかの判断ができます。逆に代替手順がある道具は、多少乱暴に扱っても事故になりません。

正式なものに昇格させる合図

便利な道具は、放っておくと第1段階のまま第3段階の仕事をするようになります。上がる合図を先に決めておくと、その日に気づけます。合図と、そのときにやることを並べます。

昇格の合図	その時点でやること
使う人が部署をまたいだ	台帳の段階を上げ、情報システム部門に共有する
週次以上の定例業務に組み込まれた	代替手順と確認日を文書にして、業務の手順書に載せる
出力が社外の相手に届くようになった	出す前に人が確認する工程を1つ入れ、確認する項目を決める
個人情報や決済に関わるデータを読み始めた	いったん止めて、扱ってよいかを確認してから再開する
止まると締め日が動くようになった	保守の担当を業務分掌に載せ、代わりの人を1人決めておく

昇格したときにやることの中身は、突き詰めると人の言葉で説明できる状態にすることです。何を入力にして、何をして、何を出しているのかを1枚に書き直す。中身のコードを読める人がいなくても、この1枚さえあれば外部に相談できますし、必要なら作り直すこともできます。

逆に、昇格させないと決める判断もあります。使う人が増えても、間違っても誰も困らない道具はそのままでよい。全部を正式にしようとすると手が回らなくなるので、上げるものと上げないものを分ける割り切りが要ります。判断の材料は、やはり止まったときに誰が困るか、の一点です。

捨てる基準と、棚卸しのやり方

増えたものは減らさないと管理できません。公開されている25項目の整理でも、使い捨てとして作ったものについて、用途が終わった時点で廃棄するか正式に移管するかを選ぶ流れを制度として決めておくことが挙げられています。作るときに、終わり方も一緒に決めておくという考え方です。

棚卸しは四半期に1度で足ります。台帳を開き、次のどれかに当てはまるものへ印をつけます。90日以上動かしていない、作った人がすでに異動した、同じことができる正式な仕組みができた、読んでいた元のデータがなくなった。印がついたものは使っている人に1週間だけ確認し、返事がなければ止めます。止めてから消すまでに1か月置くと、本当に使われていたものだけが手を挙げます。

• 棚卸しをせずに台帳だけ増やす：数年で誰も見ない一覧になり、登録そのものの意味がなくなる
• 使われていないものを消さずに残す：本当に使われている道具が埋もれ、確認の手が回らなくなる
• 捨てる判断を作った本人だけに任せる：自分の作ったものは捨てにくい。第三者が期限で切る
• 止める連絡をせずにいきなり消す：一度やると、次からは台帳に登録されなくなる
• 異動の引き継ぎ資料に道具を書かない：人が抜けた瞬間に、持ち主のない道具が生まれる
• 動いているから触らない、で放置する：動いたまま静かに間違っている場合に気づけない

外部に頼むべき境目

最後に、自分たちで作らずに外へ頼むべき線です。判断の軸を増やすときりがないので、止まったときの影響と、中身を読める人がいるかどうかの2つに絞ります。次のどれかに当てはまるなら、社内で作り続けるより外部に相談したほうが早く、結果として安く済みます。

• 壊れた日に、売上や納品そのものが止まる
• 個人情報や決済、契約に関わるデータを扱う
• 複数の部署が同時に使い、それぞれ違う使い方をしている
• 3年以上使い続ける前提で、作り替えの予定がない
• 社内に中身を読める人が1人もおらず、育てる予定もない

頼むときに効くのは、自分たちで作った試作をそのまま渡すことです。何をしたいかを言葉で説明するより、動くものを見せたほうが早く正確に伝わります。ここは、AIに作らせた道具のいちばん健全な使い道かもしれません。試作は捨てる前提で作り、要件を伝えるための道具として使う。そう位置づけると、社内で作る作業と外に頼む作業のどちらにも無駄が出ません。

外に頼むと決めたあとも、社内に残しておくべきものがあります。何を入力にして何を出すかという業務そのものの理解と、出てきた結果を確かめる手順の2つです。この2つを手放すと、頼む先が変わるたびに一から説明することになります。

よくある質問

部署の中だけで共有するなら、登録は不要ですか

使う人が自分以外に1人でも増えたら、登録の対象にするのが目安です。理由は管理のためではなく、あなたが休んだ日に誰かが困るからです。逆に、出力を自分だけが見て、自分の作業を速くするだけの道具なら、登録は不要にしておいたほうが全体はうまく回ります。軽いものまで登録させると、肝心の重いものが埋もれます。

中身を読める人が社内に1人もいません

まず、その道具を第3段階として扱います。次にやるのはコードを読むことではなく、何を入力にして何を出しているかを日本語で1枚に書くことです。これは作った本人でも書けます。1枚あれば、外部に相談することも、別の形で作り直すこともできます。読める人を育てるのは、その次の話です。

AIに作らせた道具が出した数字は、どこまで信じてよいですか

作った直後に1度だけ、手作業の結果と突き合わせて一致を確認します。そのうえで、毎回確認する項目を件数・合計・対象期間の3つに絞ります。全部を疑うと使われなくなり、何も疑わないと静かな間違いに気づけません。確認の範囲を狭く決めることが、使い続けるための条件です。

情報システム部門に相談すると止められそうで、言い出しにくいです

相談の内容を、使ってよいですかではなく、この段階のものをこの条件で使いたい、に変えると通りやすくなります。読むだけで書き換えはしない、扱うデータはこれ、止まったときの代替手順はこれ、という3点を先に示す。判断の材料が揃っていれば、止める理由のほうがなくなります。

何個までなら管理できますか

個数の上限より、台帳に載っていない道具の割合のほうが指標として使えます。棚卸しのたびに、台帳になかったものが新しく見つかった数を数える。この数が回を追って減っていれば、仕組みは働いています。増えているなら、登録が重すぎるか、登録する利点が現場に伝わっていません。

まとめ

AIに作らせた社内ツールを業務で使ってよいかは、出来のよさでは決まりません。決めるのは、それが止まった日に誰が困るかです。出力が社外に届くか、本人以外が動かすか、消せない記録が残るか、締め日が動くか。この4つで下ごしらえと業務システムを分け、自分だけ・チーム内・社外に影響するの3段階で条件を変えます。どの段階でも共通なのは、AIに判断させないこと、根拠を書かせること、人が確認する範囲を先に決めることの3つです。そのうえで、申請は1枚5項目に軽くして台帳に集め、止まったときの代替手順と保守の担当を作った直後に書き、昇格の合図と捨てる基準を決めておく。壊れると事業が止まるもの、個人情報に触れるもの、読める人が社内にいないものは、外部に相談する側へ寄せます。まずは、いま自分の部署で動いている道具がいくつあるかを、5分で数えてみるところから始まります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。