いち受託開発現場での生成AI活用の現在地: 2026年上期 「AIで作ったのでシステム化お願いします」編

この記事は Qiita Tech Festa 2026 の投稿記事かつ いち受託開発現場での生成AI活用の現在地: 2025年版 の続編になります。

はじめに：「昔から変わっていない」問題が加速・膨張した話

LLM によって昔からずっと存在していた 「システム開発・運用経験の浅い方が（プロトタイプ的に）作ったものを、システム化(本番運用)できるように何とかしてくれ」 という内容を 「やる人の数」 と 「案件の件数」 が爆発的に増えました。

本記事では、システム開発・運用経験の浅い方が Vibe Coding で作り上げたものと向き合うことになった2つの苦労した事例を通じて、変わらない事/変わった事について振り返りました。

事例1：「デモが動いたから本番に載せてほしい」というご相談

最初の事例は、「AIを使っていい感じのデモが動いたので、あとはこれをWebにリリースして欲しい」とご相談いただいた案件です。

昔から変わらない「ローカルと本番の壁」

ご依頼の方からすれば「手元で動いているものがあるのだから、その後は大したことがないだろう」というご認識でした。しかし、コードを確認するとローカルでしか動かない仕組みになっていました。

• ローカルファイル・メモリでの状態管理(データ永続化に対する考慮不足)
• ローカル端末だから許されるセキュリティ水準(フロントへの認証情報埋め込みなど)
• 開発者一人しかアクセスしない前提(認証・認可の不足)

新しめの課題：関心のあるなしでの完成度の落差

昔と違うのは、 「AIが作るプロトタイプの表面上の完成度が高すぎること」 です。見た目は完璧に動くため、「もう完成している」という誤解が強くなっています。

しかし、デモは「手元で動かす」という目的に対して最小の構成で作成されています。例えば、運用に必要な内容(例：ログの出力など)は省かれていますし、規模や内容によりますが、コンテナ化されてなかったり、CI/CDもなかったりするので「今動いている」以上の保証のない要素が多かった印象です。

結果として、「もうできている」というご依頼の方の期待に反して作り直す要素が多かったです。転用できるものもありましたが、作られてない要素は作らないといけないですし、予算・工期的共にご期待に添わない内容になることが多かったです。

事例2：「既にリリース済みのシステムを保守してほしい」というご相談

次の事例は、作られたシステムが 既にリリースされており、その保守運用を何とかして欲しい というご相談でした。

※こちらは、リスクが高くサポート体制を提供できないと判断し、お見送りとなりました

昔から変わらない「構成管理のなさ」「非機能要件の考慮不足」

依存関係管理ファイルはあるものの実際の本番環境との対応が不明確だったり、エラーで止まったまま放置されたCD(シェルスクリプトだったりしますが)など、構成管理やデプロイ周りが運用に乗っていないという課題は、昔からよくある光景です。

非機能要件は考慮不足のケースが多く、ちょっとした条件でやたら遅くなるなとか、認可大丈夫なのだろうかとか、セキュリティは......局所局所ではおそらく LLM に聞いたか「セキュリティを考慮して」などというプロンプトを書いたんだろうなと思うところはありましたが、詳しくは書けない内容もがありました。

新しめの課題：「整合性」と「作りすぎ」の罠

しかし、厄介な問題が山積していました。特に既にあるシステムなので LLM のモデルも昔のモデルで作られているため、より困難さが際立っていたのかなという印象です。

1. ドキュメントが「多すぎて」ノイズが多い
   • ドキュメントがないのではなく、ありすぎて人間はまず読めないという状態でした
   • また、フォーマットやサマリの形式は人間が読むことは前提とされておらず、原則AIの要約を通してしか内容の把握が難しい状態でした
   • 今のソースコードに対して何が正なのかを判定するにはかえってノイズになる情報もありました(仕様が変わった plan 、更新されていないコードコメントなど)
2. 存在するテストコード、だが......
   • AIが書いた単体テスト群はあるものの、強制実行される仕組みがなく、最初にテストを実行してみてというところからスタートでした
   • 単体テストが妥当なものかという保証がない。流石に return true のようなテストコードはなかったですが、作りこみモックで埋まっているものの妥当性は判別に苦労しました
3. 状況に合わないベストプラクティス採用
   • ネット上の「ベストプラクティス」を採用した結果、用途や規模にしては不適当ではないかと思う内容がありました
   • 多分そのあたりは「いい感じに作って」という粒度のプロンプトで作られたのではないかなと思います

おわりに

Pre LLM 時代1万行程度(コメントアウトされたコードもかなり残っていたりする)の1つの Lambda 関数から成るシステムの移行を担当したことがあります。その時には「ドキュメントや単体テストがあれば......」と思っていました。

今回はその「あれば」と渇望したものがあったのですが 適切にハンドリングされていないとあんまり変わらないな という悲しい感想になりました。むしろある方が 「あるからできるでしょ」と言われてやり辛さを感じる 原因にすらなっていた気がします。

特に長期的なシステム運用は、教科書的に体系化された知識というよりは、現場ごとに異なるコンテキストと個別のナレッジの個別最適解を考えながら進める要素が少なからずあります。LLM によってある程度体系化されていたり、環境が限定されている箇所でのできる幅は広がっているように思いますが、人やチームにないものを何とかしようというのは結構難しいのだろうなという印象です。

逆に言うとそのあたりのナレッジを実施していっている環境であれば LLM の活用によるブースト幅も大きいのだろうな、と環境の差がかなりありそうだなと思いました。