コード生成AIは開発部門だけの話ではない｜配る前に決める体制

会社が承認していないAIを業務で使っている人の割合は、課長以上の管理職で46.5パーセント。国内の調査機関が2026年4月下旬に実施し、上場企業または従業員300人以上の非上場企業に勤める経営者と従業員310人に聞いた調査の数字です。利用の規則を整えた会社に限っても46.9パーセントで、ほとんど下がりません。配る側に回った立場から見ると、この2つの数字は順番の問題を突きつけてきます。解禁するかどうかを検討している間に、すでに使われているからです。しかもコードを書く道具は、開発部門の外側にも広がっています。集計を回す小さな仕掛け、名簿を整える仕掛け。作った本人は道具のつもりでも、業務が乗った時点でそれは仕組みです。この記事では、配ったときに起きる課題を4つに分けて原因まで下ろし、権限、置き場所、入力の範囲、受け入れ基準、止め方の5つを配る前に決める形で整理します。

配る前から使われている。まず数字で現在地を確かめる

体制の話を始める前に、現在地を確かめておきます。先の調査では、承認外のAIを業務で使っている割合は、係長や主任以下の一般社員で38.1パーセント、課長以上の管理職で46.5パーセントでした。止める側にいるはずの層のほうが、使っている割合が高いという結果です。禁止の通達を出す側が使っているので、通達だけでは止まりません。

同じ調査で目を引くのは、利用の規則を整えた会社に限っても46.9パーセントという数字です。規則の有無で利用率がほぼ動いていない。別の年次報告でも、コードを書く道具の利用を禁じている企業のうち76パーセントが、規則に反する利用を把握していると報告されています。規則を配ることと、使われ方が変わることは別の話です。

公的な整理でも位置づけは上がっています。情報処理推進機構が公表した「情報セキュリティ10大脅威 2026」では、組織向けの3位に「AIの利用をめぐるサイバーリスク」が入り、2026年で初めての選出となりました。つまり、配るかどうかを決める段階はすでに過ぎています。決めるべきなのは、すでに動いているものを、どう見える場所に移すかです。

「開発部門だけの話」という線が、引けなくなった理由

以前は線が引けました。コードを書くのは開発部門で、他の部署はできあがった仕組みを使う側。だから道具の管理も開発部門の中で完結しました。この前提が崩れたのは、書ける人の範囲が広がったからです。ある調査会社は2028年までに開発者の75パーセントがコードを書く補助の道具を使うと予測し、開発基盤を提供する大手の事業者は、現時点で全体の2割5分程度のコードがAIによって書かれており、2030年には9割を超えるという見通しを示しています。

しかし、実務で線が引けなくなった理由はもっと手前にあります。マーケティングや情報システムの担当者が、日々の面倒な作業を片づけるために小さな仕掛けを自作し始めるからです。名簿の重複を消す、複数の管理画面から数字を集めて1枚にまとめる、問い合わせの内容を分類する。どれも、以前なら申請して作ってもらっていた類のものです。

ここで問題が部門をまたぎます。作ったのは事業部門、動かしているのは事業部門の端末、しかし止まったときに呼ばれるのは情報システム部門です。入っている情報の扱いを問われるのは法務です。作る人と、直す人と、責任を負う人が別々になった瞬間に、これは体制の問題になります。道具を配る前に決めておくべきなのは、この3者の線引きです。

何を配ることになるのか。道具の範囲と、部門をまたぐ役割

配る対象を曖昧にしたまま議論を始めると、話が噛み合いません。実際に社内で使われる形は3つに分かれます。1つ目は、開発の作業画面に組み込まれて補助をする形。2つ目は、対話の画面にやりたいことを書くとひとまとまりの処理が返ってくる形。3つ目は、画面上の操作を組み合わせて仕掛けを作る道具に、AIの生成が付いている形です。

3つのうち、体制の設計で見落とされるのは2つ目と3つ目です。1つ目は開発部門の中に閉じるので、既存の検査や審査の流れに載せられます。ところが2つ目と3つ目は、事業部門の担当者が自分の端末で完結させてしまうため、できあがった仕掛けが誰の目にも触れないまま業務に乗ります。障害が起きて初めて存在が知られる、という順番になります。

役割の分担は、配る前に紙にしておきます。実務で回る分け方は、事業部門が「何を作りたいか」と「動かなくなったときに困る範囲」を書く、情報システム部門が「どこで動かすか」と「何に接続してよいか」を決める、法務や管理部門が「何を入力してはいけないか」を決める、という3分割です。誰が決めるかを空欄にしたまま配ると、全部が情報システム部門に戻ってきます。

課題①：レビューが追いつかない。原因は量ではなく、読む理由が消えたこと

最初に出てくる課題は、確認の作業が追いつかないことです。ただし、原因を「量が増えたから」と置くと対策を外します。2026年に公表された調査では、94パーセントの技術者が「AIが書いたコードは人が書いたものと同等だ」と評価していました。ところが実際に確かめると、61パーセントが問題を見つけ、33パーセントが致命的な欠陥を指摘しています。評価と実測が、これだけずれています。

このずれが意味しているのは、読む量の問題ではなく、読む理由が消えたということです。人が書いたコードは、書いた人の癖や迷いが表面に出ます。読み手は違和感を手がかりに掘れる。機械が書いたコードは、体裁が整っていて読みやすく、違和感が出ません。読みやすいことが、疑わない理由になってしまいます。だから通読しても見落とします。

対策の方向は2つです。1つは、人の目の前に、機械の検査を必ず挟むこと。ある解説では、静的な解析を継続的な検査の流れに組み込み、AIが書いたものも人が書いたものも同じ基準で自動的に検査する形が勧められていました。もう1つは、人が読む範囲を「全部」から「あらかじめ決めた場所だけ」に絞ることです。全部読む建前は、実際には何も読まれない状態を作ります。

課題②：作った人しか直せない。原因は、指示の履歴しか残らないこと

2つ目の課題は、作った本人が異動すると誰も直せなくなることです。これは以前からある問題ですが、AIに書かせる形では悪化します。理由は、設計の意図が文書として残らず、対話の履歴だけが残るからです。履歴には「こうしてほしい」の連なりはありますが、なぜそう決めたのかは書かれていません。

残っていないと何が困るか。直そうとした人が、その処理が意図的なのか、たまたまそう書かれただけなのかを判定できません。判定できないので触れない。触れないので、動かなくなったときに作り直すしかなくなります。ある調査では、本番の環境で問題が起きた要因のうち、規約とガバナンスに関わるものが3割を占めていました。直せない仕組みは、動いているうちは問題として数えられません。

対策は文書ではなく、受け入れの条件に置きます。作った仕掛けを業務で使ってよいことにする条件として、意図を書いた紙を1枚求めるのが現実的です。長い設計書は書かれません。何をするものか、動かなくなったら誰が困るか、止まったときに手作業で代替できるか。この3行があれば、次の人が触れます。書けない仕掛けは、業務に乗せる前に止めます。

課題③：社外に出せない情報が入る。原因は、禁止の書き方にある

3つ目は情報の持ち出しです。よく引かれる事例として、ある大手の電機メーカーが利用を解禁したところ、20日ほどの間に機密の漏えいが3件発生し、技術者がソースコードの全文を貼り付けていた例が報告されています。先の調査でも、個人の契約で使ったために社外に出してはいけない情報を入力してしまう懸念が挙げられていました。

原因は「禁止と書いていないから」ではありません。ほとんどの会社の規則には、機密情報の入力を禁じる文言が既に入っています。問題は、その文言が業務の言葉になっていないことです。「機密情報」と書かれていても、目の前のコードが機密情報に当たるのかは、書いた本人にも判断がつきません。判断がつかないものは、判断されずに貼られます。

ある解説では、入力してはいけないものを具体例で文書化することが勧められ、取引先の企業名、未公開のソースコード、人事評価の記述という例が挙げられていました。類型ではなく、実物の名前で書くのが要点です。加えて、技術的な制御も併用します。同じ解説では、検知して知らせる、警告の画面を出す、遮断する、という段階を踏む運用が示されていました。いきなり遮断すると、抜け道を探す動きが起きます。

課題④：依存する部品の素性が分からない。原因は取り込みの経路

4つ目は、外から取り込む部品の素性です。AIが書いたコードは、たいてい外部の部品を前提にしています。名前を挙げて「これを使う」と書かれると、そのまま取り込まれる。ここで2つの問題が起きます。1つは、その部品自体の欠陥。もう1つは、実在しない部品の名前が返ってくる場合があることです。

後者は、それらしい名前が返ってくるために気づきにくく、同じ名前の部品を悪意のある側が用意して待ち構える手口が指摘されています。取り込みの経路が野放しだと、この手口が通ります。ある解説では、依存している外部の部品にも既にAIが書いたコードが入り込んでいると指摘されており、自社がAIを使わない選択をしても、外から入ってくる経路は残ります。

対策は取り込みの入口を1本に絞ることです。使ってよい部品の置き場所を決め、そこを経由しないと取り込めない形にする。新しい部品を足すときは、名前が実在するか、更新が続いているか、誰が管理しているかを確かめる手順を挟みます。確かめる手順は3項目で足ります。長い審査は必ず飛ばされます。事業部門が作る仕掛けでも、この入口は同じにします。

本番で壊れる場所は、コードの中だけではない

ここが、この記事でいちばん伝えたい部分です。対策の議論は「AIが書いたコードは安全か」に集まりがちですが、実際に本番で起きている問題は、コードの中の欠陥だけではありません。2026年に公表された調査では、本番の環境でAIが関わったコードに由来する問題を確認した割合が78パーセント、直近6か月で問題を経験した割合が82パーセントに達していました。

本番で問題が起きた要因	割合	どこで起きるか	コードの検査だけでは防げない理由
連携とつなぎ込み	およそ3割	他の仕組みとの受け渡し、項目の食い違い	つなぐ相手の仕様は自社のコードの外にある。単体では正しく動く
規約とガバナンス	およそ3割	決まりへの適合、利用条件の扱い	検査の道具は決まりを知らない。何を守るべきかは人が書いておく必要がある
データの質	およそ3割弱	前提が足りない、渡された値が想定と違う	コードは正しくても、入ってくる値が違えば結果は壊れる
安全上の欠陥	およそ3割弱	認証や権限の扱いの抜け	ここだけは検査の道具で機械的に減らせる。ただし全体の一部にすぎない

表のとおり、要因は4つにほぼ均等に散っています。安全上の欠陥は最も小さい山で、連携と規約のほうが大きい。ここを取り違えると、検査の道具を導入して安心し、本番の障害は減らないという結果になります。あわせて、86パーセントが上級の技術者の緊急対応が増えたと答え、74パーセントが4回に1回以上の反映で大がかりな復旧が必要になったと答えていました。

実務への意味は単純です。配るときに決めるべきなのは、コードの検査だけではなく、つなぐ相手の一覧と、守るべき決まりの一覧です。この2つは自社の外からは持ってこられません。どの仕組みにつないでよいか、どの決まりに触れるかを先に書いておけば、事業部門が作る仕掛けでも同じ基準で判定できます。つなぎ先の一覧が無いまま配ると、確認する手立てそのものがありません。

賢いモデルに替えることは、対策にならない

よくある期待に、性能の高いモデルに替えれば安全になるというものがあります。これは実測で否定されています。2025年10月に、100を超える大規模言語モデルを対象に4つの言語でコードを書かせた調査では、全体の45パーセントの作業で、差し込み型の欠陥や、閲覧者の画面で意図しない処理が動く欠陥といった致命的なものが混入していたと報告されました。

さらに示唆的なのは、同じ系統の新しい版を比べた別の解析です。推論の能力を測る指標では前の版から31.2ポイント向上していたにもかかわらず、欠陥の密度は55.0パーセント増え、想定外のファイルやフォルダに到達されてしまう類型の危険度に至っては278パーセント増えていた、と報告されています。賢くなることと、安全になることは、別の軸で動いています。

この事実は、体制の設計を変えます。モデルの更新は対策ではなく、変更として扱うべきものになります。使うモデルを新しくしたら、書かれるコードの傾向が変わる可能性があるので、受け入れの基準はそのままにして、検査の結果がどう動いたかを見る。基準のほうを緩めてはいけません。配る前に基準を決めておくのは、更新のたびに基準が揺れないようにするためでもあります。

配る前に決める5つ。全体像と、決める順番

ここから対策に移ります。決めるのは5つで、順番があります。順番を入れ替えると、後ろの工程が決められません。権限が決まっていないと置き場所が決まらず、入力の範囲が決まっていないと受け入れの基準が書けないからです。

この5つを、ある解説が示していた3段階の流れに重ねると理解しやすくなります。まず可視化して、どのサービスがどの部署でどの頻度で使われているかを把握する。次に、許可、条件付きの許可、禁止の3段階で線を引く。最後に、技術的な制御、教育、法人向けの環境の整備、監視の4つを組み合わせて定着させる。この順で見ると、5つのうち最初の2つが可視化に、後の3つが線引きと定着に当たります。

対策①：権限と環境。誰に、どこまで、どこで使わせるか

最初に決めるのは権限です。ここで陥りやすいのが、全社に一斉に配って様子を見る形です。使われ方が読めない段階で全体に配ると、可視化の作業だけが膨らみます。実務では、部署と用途を区切って始め、そこで出た困りごとを見てから広げます。区切る単位は、部署よりも「作った仕掛けが止まったときに困る範囲」で切るほうが実態に合います。

環境の指定も同時に決めます。個人の契約で使わせないこと、法人向けの契約に寄せること、入力した内容が学習に使われない条件が契約で担保されていることの3つが最低線です。先の調査でも、個人の契約を業務に使う形が漏えいの経路として挙げられていました。個人の契約で使われた履歴は、会社が後から回収できません。

接続してよい相手も、権限の一部として決めます。どの社内の仕組みに触れてよいか、外部のどの先に情報を送ってよいか。ここを空欄にすると、作る人が善意で便利につないでいきます。つないだ経路は、つないだ本人以外には見えません。だから、つないでよい相手の一覧を先に配り、そこに無い相手につなぐ場合は申し出る形にします。

対策②：置き場所と記録。作った道具を、個人の手元に残さない

2つ目は置き場所です。事業部門が作った仕掛けは、放っておくと作った本人の端末か、個人の保存領域に置かれます。この状態が、直せない仕組みを生む最大の原因です。置き場所を1か所に決め、そこに置かれていない仕掛けは業務で使わない、という線を引きます。技術的な制約ではなく、運用の約束として書きます。

置き場所と一緒に、残す記録も決めます。項目は4つで足ります。誰が作ったか、何をするものか、動かなくなったら誰が困るか、止まったときに手作業で代替できるか。前の2つは作った人しか書けず、後の2つは業務を知らないと書けません。4項目が埋まらない仕掛けは、業務に乗せる前に一度止めます。

記録を集める仕組みは、管理側が聞いて回る形にすると必ず古びます。作る側の手順の中に組み込みます。具体的には、置き場所に置く操作と、4項目を書く操作を1つの流れにしてしまう。後から書いてもらう形は、例外なく形骸化します。あわせて、月に1回、置き場所の一覧を見て、半年以上更新されていない仕掛けに印を付けます。

対策③：入力してよい情報の範囲を、業務の言葉で書く

3つ目は入力の範囲です。前述のとおり、類型で書かれた禁止は判断につながりません。書くべきなのは、自社の業務に出てくる実物の名前です。取引先の企業名と担当者名、未公開のソースコードと設計の資料、人事評価や採用に関する記述、契約書の条文、まだ公表していない価格や数量。この一覧は、部署ごとに違って構いません。

作り方には順番があります。先に「入れてはいけないもの」を並べるのではなく、「その部署が日常的に扱っている情報」を全部並べてから、3段階に振り分けます。入れてよい、条件を満たせば入れてよい、入れてはいけない。この順で作ると、抜けが出にくくなります。先に禁止から書くと、書いた人が思いつくものしか並びません。

運用の形も決めておきます。ある解説では、月に1回ログを確認し、半年から1年でガイドラインを改訂する周期が示されていました。改訂の材料になるのは、検知された入力の内容です。止めた件数ではなく、止めた中身のほうを見ます。同じ種類の入力が繰り返し止められているなら、それは規則の問題ではなく、業務のやり方が規則と噛み合っていない合図です。

対策④：受け入れ基準。人が読む範囲を先に決める

4つ目が、この記事の要になります。AIの出力をそのまま採用しないという原則は、多くの会社が既に書いています。しかし「そのまま採用しない」は運用できません。運用できる形にするには、人が読む範囲を、あらかじめ場所で指定します。全部読むという建前は、実際には何も読まれない状態を作るからです。

読む範囲の決め方には基準があります。外から触れる入口、権限や認証を扱う部分、お金や個数を計算する部分、外部の仕組みに情報を送る部分。この4か所は、人が必ず読みます。それ以外は機械の検査に任せる。4か所を決めておけば、読む時間は現実的な量に収まります。読む人は、作った本人以外にします。作った本人は、動く前提で読むためです。

受け入れの条件は、読むこと以外にも要ります。機械の検査を通っていること、意図を書いた3行があること、止まったときの代替手段が書いてあること。4つのうち1つでも欠けたら、業務には乗せません。この線を最初に引いておけば、急ぎの案件が来たときに交渉の余地がなくなります。基準を後から作ると、最初の急ぎの案件で必ず崩れます。

対策⑤：止め方と、配布前の確認表

5つ目は止め方です。配る話の中で最も飛ばされますが、飛ばすと後で効きます。決めるのは3つ。使わなくなった仕掛けをどう止めるか、退職や異動のときに権限をどう回収するか、そして問題が起きたときに誰の判断で全体を止めるかです。3つ目は、決裁の順番まで含めて書いておきます。夜間に止める判断を求められたときに、誰に電話するかが決まっていないと止まりません。

最後に、配る前に埋める確認表を置きます。表の右端が空欄のまま配ると、その空欄が後で全部、情報システム部門の仕事として戻ってきます。埋める順番は、先に示した5つの順と同じです。

決めること	決める人	配る前に書いておく中身	決まっていないと起きること
誰に配るか	事業部門と情報システム部門	部署と用途の範囲。広げる条件も一緒に書く	全社に一斉に配られ、可視化の作業だけが膨らむ
どの環境で使うか	情報システム部門	法人向けの契約に寄せる。個人の契約を業務に使わせない	個人の契約で使われ、履歴も情報も会社が回収できない
何につないでよいか	情報システム部門	接続してよい社内の仕組みと外部の先の一覧	善意でつながれ、経路が本人以外に見えなくなる
何を入力してよいか	法務と管理部門	実物の名前で3段階に振り分けた一覧。部署ごとに作る	判断がつかないまま貼られる。規則があっても止まらない
どこに置くか	情報システム部門	置き場所1か所と、残す記録の4項目	個人の端末に残り、作った人しか直せない仕組みになる
何を満たせば使ってよいか	事業部門と情報システム部門	人が読む4か所、機械の検査、意図の3行、代替手段	急ぎの案件が来た時点で基準が崩れる
どう止めるか	情報システム部門と事業部門	停止の手順、権限の回収、止める判断をする人と順番	止める判断が夜間にできず、被害の範囲が広がる

実務仕様と、よくある失敗の型

最後に、運用の形と、実際に起きる失敗をまとめます。この体制は始めるより続けるほうが難しく、続かない理由はほとんど設計の側にあります。使う人の意識の問題ではありません。

• 配る範囲は部署ではなく「止まったときに困る範囲」で区切る。広げる条件を最初に書いておく
• 置き場所への登録と、記録の4項目の記入を1つの操作にまとめる。後から書いてもらう形は形骸化する
• 月に1回、検知された入力の中身を見る。件数ではなく中身を見ないと、規則の直しどころが分からない
• 半年から1年で規則を改訂する。改訂の材料は、現場が困った実例だけにする
• モデルを新しくするときは変更として扱う。基準は動かさず、検査の結果がどう動いたかを見る
• 止める判断をする人と連絡の順番を、配る前に紙に書く。夜間に決められない体制は止められない

• 規則を配って解禁とする——規則を整えた会社でも承認外の利用は46.9パーセントで、ほぼ下がらない
• 全社に一斉に配って様子を見る——使われ方が読めないまま可視化の作業だけが膨らむ
• 禁止する情報を類型の言葉で書く——目の前のものが当たるか判断できず、判断されないまま貼られる
• いきなり遮断だけで止める——抜け道を探す動きが起き、見えない利用に潜る
• 検査の道具を入れて対策が終わったことにする——本番の失敗要因のうち安全上の欠陥は一部にすぎない
• 性能の高いモデルに替えて安全になったとみなす——推論の指標が上がった版で欠陥の密度が増えた実測がある
• 全部を人が読む建前にする——実際には何も読まれない。読む場所を4か所に指定する
• 止め方を決めずに配る——問題が起きた夜に、誰の判断で止めるかが決まっていない

失敗の型を並べると、共通点が見えます。どれも、配ることを1回の意思決定として扱った結果として起きています。解禁するか禁止するかを決めれば終わり、という形です。実際には、配った後に決め続ける項目のほうが多い。だから配る前に決めておくのは、答えそのものではなく、誰がどの順番で決めるかという枠組みのほうになります。

まとめ

コードを書くAIは、開発部門に配る道具として設計すると、必ず開発部門の外で問題が出ます。承認していないAIを業務で使っている割合は管理職で46.5パーセント、規則を整えた会社でも46.9パーセントで、規則の有無で利用率はほとんど動いていません。だから最初の問いは「解禁するか」ではなく「すでに動いているものを、どう見える場所に移すか」になります。

課題は4つに分けられました。確認が追いつかないのは量の問題ではなく、体裁が整っていて疑う手がかりが消えたこと。作った人しか直せないのは、意図が残らず指示の履歴しか残らないこと。出せない情報が入るのは、禁止が類型の言葉で書かれていて判断につながらないこと。部品の素性が分からないのは、取り込みの入口が絞られていないこと。そして本番で壊れる要因は、連携と規約が各3割で、安全上の欠陥より大きい。コードの検査だけでは減りません。

配る前に決めるのは5つです。権限と環境、置き場所と記録、入力してよい情報の範囲、受け入れ基準、そして止め方。順番があり、権限が決まらないと置き場所が決まらず、入力の範囲が決まらないと受け入れ基準が書けません。受け入れ基準では、人が読む範囲を場所で指定します。外から触れる入口、権限を扱う部分、金額や個数を計算する部分、外部に情報を送る部分の4か所です。性能の高いモデルに替えることは対策になりません。基準を先に決め、モデルの更新は変更として扱う。決め続ける枠組みを配る前に作ることが、この道具を社内に置くということです。

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