AIが作ったプログラムがクソすぎた話

先日、とある知り合いから連絡をいただいた。 どうやら会社の作業員の手が足りていないので、エンジニアとして作業してもらえないか？と言う内容。 知り合いというのは、その会社の社長をやっていて、ユゲタの昔の会社の同僚（後輩）でもある。 可愛い後輩の頼みなので、快諾してあげたいところだけど、要するにこれは「炎上案件」というヤ〜ツ。 炎上案件は迂闊に足を踏み入れると、火傷したり、とんでもないバックファイヤーに見舞われてしまうという、 火事現場よりも恐ろしい、エンジニア界隈で、「できれば近づくな」と言われているデンジャラス地帯なのだ。 そして、渋々手伝ってあげることにした（正確には現時点でまだ確認段階ということで、こちらの返答待ち状態）のだが、 その対象のシステムというのがとんでもない危険地帯でした。 AIを使って作られたそのシステムなのだが、最近のAIプログラミングの実情（このシステムに鍵ってかもしれないが）をブログに書き綴ってみたいと思います。

前担当者はウツダウン

少し背景の話をしておくと、今回の対象システムは、とある会社の社内ツールで、後輩の会社はその会社のお手伝いをしている、いわゆるクライアントと業務委託（案件委託）的な関係です。 元々そこにアサインされていたエンジニアというのが1人いて、そのシステムをIDE系のブラウザ型AIプログラミングの「Vibeコーディング」で作られたシステムとのことらしいです。 ※Vibeコーディングは、人が音声やテキストでAIに指示して、プログラミングを作ってもらう手法です。 そしてその唯一の担当エンジニアは、元々ウツ体質だったらしく、仕事に復帰してこれまでなんとかやってきたのだが、最近それがまた復活してきて、あえなく今回もダウンしたとのこと。 そのため、後任エンジニアがなかなか採用でも見つからないため、システム納期の期日が迫ってきていることもあり、自分に泣きついてきたという背景があったらしい。 （正直、知らんがな・・・と思うし、そんな危ない奴、雇うなよ・・・とおもた）

とにかくシステムをCloneしてみる

まあ、何もせずにブーブー言っていても仕方がないので、とりあえずそのWeb系システムをGithubからCloneして内容を確認してあげようと思う。 Githubで管理されているシステムとしては、通常の会社の一般的な管理体制で、 AWSにデプロイして、テストサーバーと本番サーバーが存在する、極めてフツーの構成でした。 そして、ローカル環境はDockerで動作する構成で、さほど構えていなかったんですが、 GithubからCloneして、READMEに書かれている手順通り進めて、DockerをUPしてみたところ・・・ Error!!! どうやら起動時にpythonコードでエラーになっているようで、コードを辿って読んでみると、 ローカル環境に、Pythonがインストールされていないとエラーになるらしい ということがわかった。 なんで？？？ Dockerの中でPython使えばええやん！！！ その後わかったことですが、MySQLもインストールしないといけないという仕様でした。 でもまあ、これまでこれを使って開発を行なっていたらしいので、この状態で我慢してインストールをすることにして、とりあえずインストールしてブラウザに初期画面を表示するところまでは成功しました。

モジュール修正の罠

次に、内部のモジュールや、各コンポーネント（表示などの素材等）を確認するために、表示している画面のソースであろうファイルを見つけて修正してみた。 多くのWebフレームワークの場合は、HTMLコンポーネントがファイルであって、それで大体の表示修正場所などを確認しようと思ったワケです。 でも、・・・あれ？？？・・・ 文字を変更して、ブラウザで何度リロードしても画面が変更されない・・・ なんで？・・・ もしかして、何かしらコンパイルして表示するようなスタイルなのか？（Webフレームワークではあまり考えられないけど） とりあえず、dockerを再起動してみても、やっぱり表示はそのまま・・・ 色々調べてみて、やっと原因に辿り着いた。 以下コマンドを実行することで、内容が変更された。 docker-compose build --no-cache 解説すると、どうやら、中のコンポーネントなどは、Dockerfile内で、COPYコマンドで、コンテナ内にコピーされているので、いくらローカルのファイルを修正しても、再度コピーしないと修正されないというオチでした。 こんな非効率な開発環境ある？？？ そもそも、ちょっと修正したら、毎回dockerをリビルドして、リスタートする・・・めちゃくちゃなシステムです。 効率バカ悪です。 普通に、COPYせずに、compose.yamlファイルで、Volumeでインスタンスリンクしてあげるだけでいいのに、今までどんな開発してたんや！！！ もしかしてAIにコードを書かせて、それをいちいちDockerビルドして表示するような工程だったとか・・・（そうとしか思えない）

レスポンシブデザイン不足

どうやらこのシステム、会社の社内ツールなのですが、営業などの人が社外でスマホでアクセスすることを前提のツールらしいのですが、 スマートフォンで表示してみると、画面がまるでレスポンシブデザイン対応できていませんでした。 こいつは不具合レベルのシステムトラブルだと思うんだけど、開発工程の中にこの不具合対応は後回しになっているので、もはや、このシステム誰がどういう風に使っているのか、摩訶不思議すぎて、1人で笑ってしまいました。 AIに対して、レスポンシブのブレイクポイントなどの指示が不足していたんだろうか？ それとも、AIがまだそうした見た目対応というのが苦手なのか・・・ 今となっては分かりませんが、少なくても、初期開発員が、そうした見た目チェックすらまるで行なっていなかったということが露呈したという事ですね。 オーマイガ！

あとがき

そして、この案件、誰からもサポートを受けられない、地獄の案件になりそうなので、それ相応の対価を頂こうかと見積書をこれから作成する予定。 確かに、炎上案件は、高値の売上につながるが、精神的な疲労につながることも否めない。 そして、何より、AIに任せっきりになっていると、こんな単純な対応すらできていないことがよくわかった。 もちろん、AIに対する指示の仕方、プロンプトの書き方、それに対するちゃんとした確認などの、AIマネジメントをしっかりと行えば、なんの問題もないはずなのだが、 AIが全部まるっとやってくれると、アグラを書いているエンジニアは、こうした結果から、自己評価を下げることにつながってしまいそうですね。 「それAIがやりましたから・・・」と言い訳をしても、AIの責任ではなく、AIを使った人の責任になるということは明確ですよね。 でも、これからはAIコーディングが主流になることは間違いないので、こうした失敗例もちゃんと理解してエンジニアとしてのスキルを磨いていくことが重要ということがわかった今回の案件でした。 以上、愚痴にも近い、AI時代幕開けの、イチエンジニアの気付きでした。 ※今回のそれぞれの事象を画面キャプチャして見せてあげたいけど、B2B案件なので、迂闊にキャプチャできないので、文章のみでお送りしました。 このブログでは、こうした失敗談、ダメシステム、苦労話などを募集しております。 ブログで採用させてもらった際には、何かしらのご返礼を差し上げたいと思います。