生成AIがかなり普通に使われるようになった。

「こんなものを作りたい」と伝えれば、HTMLもJavaScriptもPythonもSQLも書いてくれる。エラーを貼れば原因を調べて修正案まで出してくれるので、以前なら数日かかっていたような小さな業務ツールが、数時間で形になることもある。

自分もCodexをはじめ、AIをかなり使って開発している。便利なのは間違いないし、今さらAIを使わずに全部手作業へ戻ろうとも思わない。

ただ、実際の開発現場で使っていると、「コードが書ける」という部分だけが先に進みすぎているようにも感じる。

その結果として増えているのが、いわゆる「野良アプリ」だ。

ここでいう野良アプリとは、正式な開発プロセスやシステム管理の外側で、個人や一部の担当者が作った業務用ツールやアプリのことを指している。

ExcelマクロやAccess、個人で作ったスクリプトなど、この問題自体は昔からあった。しかし生成AIによって、作れる人の範囲と作られる速度が一気に広がった。

以前はある程度プログラムを書ける人しか作れなかったものが、今ではAIに日本語で指示するだけでもかなりのところまで完成する。

問題は、アプリを作るために必要な知識まで一緒に身につくわけではないことだ。

「作れる」と「業務で使える」はかなり違う

AIに頼めば、とりあえず動くものは簡単に作れる。

しかし業務システムとして使うなら、コード以外にも確認しなければならないことが大量にある。

誰が保守するのか。ソースコードをどこで管理するのか。障害が起きたら誰が対応するのか。バックアップはどうするのか。認証や権限は適切か。入力値の検証はしているか。ログには何を残すのか。個人情報や機密情報を扱っていないか。

もっと手前の話として、画面レイアウトすら十分に確認されていないケースもある。

作った本人のPCで一度表示されたので完成。別の解像度では確認していない。スマートフォンでは崩れている。ブラウザが変わるとボタンがはみ出す。それでも個人判断でそのまま公開したり、業務で使い始めたりする。

生成AIによって実装そのものが簡単になったことで、本来その前後にあった確認工程まで簡単になったような錯覚が起きている。

ここはかなり危ない。

AIは顧客のことを理解しているわけではない

受託開発なら、さらに事情が違う。

AIに仕様書やソースコードを渡したとしても、その顧客の業務を本当の意味で理解しているわけではない。

仕様書には書かれていない運用ルールもあるし、「この部署だけはこの操作をする」「古い端末が一台だけ残っている」「この時間帯だけ別システムとの連携が走る」「ここは過去の経緯があって変更してはいけない」といった、その現場でしか分からない事情もある。

実際のシステム開発では、こういう細かい条件が障害や事故につながる。

AIがコード上の仕様を満たしているように見えても、顧客環境で本当に問題がないかは別問題だ。

これはCodexを使っていても感じる。

こちらが一連の実装を依頼して、完了したように見えていたのに、確認すると途中の処理が止まっていて、一部が実装されていなかったことがある。

セキュリティ対策についても同様で、「当然ここまで実装されているだろう」と思って確認すると、実際には入っていないことがある。こちらから具体的にチェックして指摘すると、そこで初めて追加される。

もちろん人間の開発者でも実装漏れは起こす。

ただ、AIの場合は生成速度が非常に速いため、確認する側まで同じ速度で流してしまうと、抜けたものがそのまま残りやすい。

自分の周囲でも、これは机上の話ではなく、すでに実害が出ている。

だから「AIが実装したから大丈夫」という確認方法は成立しない。

むしろAIを使えば使うほど、確認する側には実装内容を見抜けるだけの知識が必要になる。

OpenAI自身もCodexについて、生成されたコードを統合・実行する前に人間がレビューし、検証することが重要だとしている。Codex Securityでも、実際のデプロイ環境に合わせて人間が脅威モデルの前提を確認・修正できる設計になっている。AIだけで現場固有の事情まで完全に判断させることを前提にはしていない。

個人開発とチーム開発では前提が違う

自分だけが使うアプリなら、多少コードが荒くてもどうにかなる。

作った本人が構造を覚えていればいいし、問題が起きても影響を受ける範囲は限られる。

チーム開発ではそうはいかない。

複数の開発者が同じコードを扱い、担当者が入れ替わり、数年後にも機能追加や修正が行われる。そのため、命名規則、ディレクトリ構成、例外処理、DBアクセス、ログ出力、APIの形式などをある程度統一しておく必要がある。

コードレビューやテスト、Gitによる変更管理、ドキュメント作成もそのために行う。

ところがAIは、そのプロジェクトに存在する暗黙のルールまでは知らない。

「DBアクセスは必ずこの層を通す」「共通処理はここに置く」「このライブラリは使わない」「エラーはこの形式で返す」といったルールを教えなければ、AIは普通に別の方法で実装する。

単体では動くので、それがさらに厄介だ。

結果として、開発者ごとにAIへ違う指示を出し、それぞれ違う設計思想のコードを生成して、一つのシステムに混在させるようなことも起こり得る。

それではチーム開発としての統一性がなくなる。

「よく分からないけど動いています」は出せない

AI生成コードで特に危険なのは、作った本人が処理を理解していない状態だ。

なぜこの処理が必要なのか。このSQLは何を取得しているのか。この認証処理で何を防いでいるのか。この例外を握りつぶして本当にいいのか。

そこを説明できないまま「AIが書いて動いたので使っています」では、業務システムとしては扱えない。

障害が発生したときも、セキュリティ問題が発覚したときも、最終的に調査するのは人間だからだ。

AIが書いたコードであること自体は問題ではない。

問題なのは、誰も中身を理解せず、誰も責任を持てない状態で使われることだと思う。

では、AIにどこまで任せるのか

最近は、チーム開発ではAIの使い方そのものを設計した方がいいのではないかと思っている。

例えば、プロジェクト開始時のフレームワークやディレクトリ構成、認証方式、DBアクセス方法、例外処理、ログ、テスト方針、セキュリティ対策などは、経験のあるSEが設計する。

そこでAIを使うのはまったく問題ない。

むしろ上級SEがAIを使って初期フレームワークを作り込み、プロジェクト全体の実装ルールまで整備する使い方はかなり相性がいいと思う。

AIには大量のコードを書かせられるので、人間側が正しい方向を指定できるなら非常に強い。

逆に各開発者がそれぞれ自由にAIへ指示し、好きな構成、好きなライブラリ、好きな実装方法で機能を追加していく運用は危険だ。

共通基盤を最初に固め、その枠組みの中でAIを使わせる方がいい。

経験の浅い開発者がAIを使う場合も、いきなり設計から大きな機能を丸ごと任せるのではなく、既存コードのバグ修正、テストコード作成、決められたパターンに沿った小規模な実装などから使う方が安全だと思う。

要するに、

「AIを誰に使わせるか」ではなく、「何をAIに任せてよいか」を決めておく。

という考え方だ。

OpenAI自身もCodexを社内で運用する際、低リスクの操作と高リスクの操作を分け、高リスクな操作には明示的な確認を設ける考え方を採っている。AIエージェントを導入するなら、こうした権限と作業範囲の切り分けは参考になる。

野良アプリ問題は昔からあった。でも今回は量が違う

野良システムの問題自体は昔からある。

Excel VBAで作られた謎の業務ツールが、作った本人の退職後も10年以上動いている、という話は珍しくない。

ただ、昔はそれを一本作るにも一定の知識と時間が必要だった。

今は「CSVを読み込んで検索できる画面を作って」「ログイン機能を追加して」「データベースに保存して」と頼めば、かなりのところまでAIが作る。

つまり、野良アプリを作るための技術的なハードルだけが急激に下がった。

ところが、レビュー、テスト、セキュリティ、保守、運用に必要な知識まで簡単になったわけではない。

むしろコードが大量に生成されるようになったことで、それを確認する仕事の方が増えている。

これから必要になるのは、「AIでどうやってアプリを作るか」だけではない。

誰が設計するのか。どこまでAIに任せるのか。誰がレビューするのか。どの条件を満たせば本番環境へ出せるのか。誰がその後の面倒を見るのか。

そこまで含めてAI開発だと思う。

コードを書くコストだけが急激に下がった結果、今まで見えにくかった設計やレビュー、運用の重要性が逆に目立つようになってきた。

野良アプリ問題は昔からあった。

ただ、今回は作られる速度と数が違う。

AIを使うこと自体を止める必要はない。

しかし、AIが作れるからといって、誰でも好きなものを好きな方法で作ってよい、という話でもない。

現場では、そろそろ「AIを使わせるかどうか」ではなく、「AIを使った開発をどう管理するか」まで決める時期に来ているのだと思う。