設計書にソースコードを書く、参考リンクを無視…　AIの“サボり開発”を防ぐためにエンジニアが持つべき視点

「『rm - rf ./』を実行しました」

渋川よしき氏：あとは、「方針1、2、3があります。じゃあ2でお願いします」と言っても、ぜんぜん違うことを始めたりみたいなこともありました。

生成AIは知識がちょっと古いというところとか、世の中に出回っている情報自体も、やっぱり新しい技術よりも古い技術の方が多かったりするので。

例えばDockerとか書き方が大きく変わったりしていますが、どうしても古い書き方をしたがります。「新しい書き方してください」と言っても、ちょっとうまくいかないと「きっと書き方が悪いのが原因です」みたいなことを勝手に言い出して、古い書き方に戻そうとしたりというところがありますね。

あと「ちょっとやり直してよ」って言うと、プロジェクトを全部リセットするみたいな。これ、たまにXで話題になるやつで、これはプロジェクトのフォルダだったので良かったんですけど、たまにパソコンのホームフォルダを破壊するみたいなことを見かけるので、ここは要注意ですね。

設計書の中にソースコードを書きだす

渋川：あとは、設計書を書いてよと言っても、ChatGPT Codexとかだったらちゃんと聞いてくれるんですけど、ClaudeのSonnet 4とかを使うと、やたらコードを書きたがるなっていうところですね。けっこうモデルによる癖もあるなというところあるんですけど。

「設計書を書いてください」って言っても、設計書の中にソースコードをガリガリ書いて、拡張子がただ「.md」って変わっているだけの、ほぼソースコードを書き出すみたいな感じで、あまり設計書の体をなしていないみたいなことがけっこうあったりします。

最後に動くものができればそれでもいいんですが、後でソースコードを検索した時に、ドキュメントがいっぱい引っかかってノイズになるので、個人的にはそういうドキュメントを後で書き直したりはしています。

あとは、僕の脳内イメージなんですけど、生成AIは「コーディングが大好きな新卒社員」みたいな。実装してよって言うと、実績のあるライブラリじゃなくて、デバッグされているライブラリじゃなくて自前でゼロから実装し始めることがけっこうあって、接続テストとかした時にうまくつながらないことがあって困ったことがありました。

生成AIなのになぜか時間を言い訳に

あとは、新しくソースを書きたがるので、「このやり方を変えてよ」って言うと、前の行動を残したまま新しい実装をどんどん足していくので、ソースコードの行数がガンガン増えていくこともありました。

これは重複しているなって気づいて、消す指示を出したら、一気に半分ぐらいになったりしたので、気をつけないといけません。生成AIはコードをたくさん量産してくるので危険ですよというところですね。

あとは、生成AIがコードを書いてくる時に、「テストを書いてよ」とか「Linterでコードの品質チェックしてよ」みたいなことをだいたいワークフローに書いて、それで品質のいいコードができるぞ、みたいなことは、生成AIの使い方でよく出てくるんですけど。実際やらせてみると、そう簡単にはいかなくてですね。

Linterのバージョンを上げたら問題が増えたのでバージョンを戻しました、とか。あとは、チェックの項目を無効化することでエラーはなくなりましたとか。そういうことをけっこう気軽にやってくるので、Linterを実行してよって言って丸投げするんじゃなくて、進捗や修正の結果も見とかないとけっこう危険ですね。

あと、生成AIなのになぜか時間を言い訳にしてくることもけっこうあるので、ここも要注意ですね。「この機能を実装して」とか「追加して」とか言っても、「時間の関係で、基本的なところだけやります」みたいなことをたまに言ってきます。

テスト自体をなかったことにすることも

あとは、後方互換性がやたら大好きで、ぜんぜんリリースバージョンじゃないからどんどん直してほしいのに、「前のコードを保ったまま新しい機能を追加します」みたいなことをけっこうやってきます。この辺がソースコードの行数が増える原因かな、というところですね。

そこが問題だなと思って「後方互換性はいらないです」って言うと、「コメントから後方互換性の文字を消したので解決しました」みたいなこともけっこう言ってきたりしますね。

みなさん、生成AIにテスト駆動開発をさせたりする方もいるかと思います。和田卓人という指示を入れておくと品質が上がるようなことは一時期話題になっていました（和田氏のアカウント名であるt-wadaを指示に入れるというテクニック）。かといってテスト駆動開発をすると解決するかというと、けっこうサボることが多いです。

計算した結果「10」という結果が返ってくるはず、というテストを書いた後に、メインロジックのところで「return 10」と書いてあるようなサボりをけっこうしてくるので、ここも油断大敵です。

テスト自体をなかったことにしてくることもあります。「このテストが通らないので直してください」と言うと「テストをスキップしました」と返してきます。これも同じで、「テストが通っていないから修正して」と言うと、「古いコードに依存しているので修正するかスキップするかの選択肢があります」と言って、いきなりスキップの方を選択し始めます。
この辺りも、よく指示を見ておかないと「テストが通った。バンザイ」と言ってリリースすると痛い目にあうパターンです。

難易度の高い作業のゴールポストをずらす

テスト自体のゴールポストをずらしてくることもけっこうあります。新しい機能を追加して、「そのテストを書いてください」と言って難易度の高いタスクを任せると、けっこう苦戦してループし始めたりします。結果として、その機能を使わないテストに変更して「問題が解決しました」ということを言ってきたりします。

あと、環境構築系も比較的まだ苦手なところが多いかなと思います。プログラミングは得意なのですが、DockerコンテナやTerraformを書かせたりする時に、まだうまくいかないと言っている人が周りでも多いです。Dockerもアプリケーションが起動しなくてヘルスチェックがうまくいかないのを直させると、「ヘルスチェックを無効化しました」と返してくることもありました。

あとは、「ここを参考に実装してください」というリンクを渡しても、「参考サイトを確認しないでやりました」みたいなこともけっこう言ってきたりするので、「できました」って言っても、中身を見るとぜんぜん期待と違うみたいなことがあったりします。

開発スキルがないとサボりに気づけない

結局のところ、生成AIはぜんぜんまだ完全じゃないですし、これからモデルが例えば10倍とかの性能になっても、人間側の指示がうまくないと、いつまでも人間と生成AIの誤解は生まれ続けるかなというところです。どうしても、ある程度、生成AIがどのように理解して動いているかというところは、トラッキングする必要があると思っています。

自分の指示が悪い時もたまにはあって、そういう時にも期待とずれてくるタイミングできちんと指摘しないと、コピーが多くて、密度が薄いというか。ソースコードの行数自体は、何万行もあるんですけど、重複とかが多かったりして、バグを直そうとすると大きすぎてなかなか直らない、みたいなことがでてきてしまうなというところですね。

体感としては、生成AIを使わないで、完全に自力で書くのと比べると、同じ機能で3倍ぐらいのコード量になっているなという気がします。

そういう「サボった」っていうのを検知するには、ユーザーの中に開発スキルがないと、「今、サボり始めたな」みたいなのがわからないので、開発スキルがいらなくなることはないなというのは日々実感します。

ちっちゃいものとかはぜんぜん問題なくてですね。僕、最近技術ブログの検証プログラムとかを任せるんですけど、そういうのはもう一つの指示でざっと動くものがいきなりできて、すごいなって思いますが、大規模なプログラムになればなるほど、指示を丁寧にしなければいけないな、と感じています。

こんな感じの癖があるので、まだまだぜんぜん、生成AIに置き換えて楽したいなと思うんですけど、なかなか楽にはならないなっていうのが今のところの感想ですね。