AIコーディングはプログラマの終わりの始まりか？

 こんにちは。横井です。

AIコーディングに関する記事の4回目となる今回は、ややショッキングなタイトルかもしれません。これまでさまざまなAIコーディングを試してきましたが、その経験の中で感じたことを書きたいと思います。

AIに仕事を任せる場合、大きな課題となるのはアウトプットの精度と再現性、すなわち何度実行しても同じ結果が得られるかという点です。この二点を考えると、まだ仕事を安心して任せられる段階ではないと考える方も多いでしょう。では、AIコーディングという観点ではどうでしょうか。ここまで取り組む中で、私自身が少し驚いた事例がありますので、いくつか紹介します。

まず一つ目は、APIなどのインターフェースを呼び出すロジックに関することです。APIに対してはインターフェース仕様が公開されていれば、AIはその使い方を認識できるため、要件──つまりどのような機能を実装したいか──を伝えるだけで、具体的なコーディング指示をしなくとも、それに合わせたコードを書いてくれます。

少し昔話になりますが、2000年前後に「Webサービス」という言葉が登場した頃、技術に詳しくないマーケティング系の人が「Webサービスを使えば自由に自動的に呼べるようになるよね」と言っていたことがありました。当時、現場のエンジニアだった私には「いやいや、そんなのは無理でしょう。結局は人がロジックをコーディングする必要があるのだから、自動でできるわけがない」としか思えなかったのです。しかし、それから約25年を経て、生成AIの能力を目にすると、当時は夢物語のように感じられたことが、いまや現実化しているのだと実感しています。

今回私が作成したアプリは、実はLINEのボットアプリです。具体的には、ユーザーがボットに質問すると、ボットアプリがFAQデータをもとにLLMへ最適な回答を生成するよう依頼するという仕様になります。APIという観点では、LINEメッセージAPIの使用方法とLLMのAPIの使用方法、この二つがポイントでした。私自身、どちらの知識も経験もなかったにもかかわらず、実現したい内容をAIに伝えるだけで、その後の設計やコーディングはAIが行ってくれました。やりたいことを具体的なゴールとして設定するだけで、実際のコーディングはすべて任せることができたのです。

LLMベースのFAQ応答ボット 設計ドキュメント

もう一つ興味深かったのは、アーキテクチャやデザインパターンなど、システムやプログラミングにおける標準的な技術知識も、LLMがすでに学習しているのであれば、人が一から調べて試行錯誤する必要がないという点でした。具体例を挙げると、最初のバージョンではアプリが問い合わせを行うLLMはOpenAIのみ固定で使用していました。それを機能拡張として、Google Geminiも使えるようにしたい。さらに、環境変数によってどちらを使うか動的に切り替えられるようにしたい、という要件をAIに伝えたところ、インターフェースの継承やファクトリパターンを活用する設計を提案してきたのです。継承のクラス図やシーケンス図といったドキュメントまでもアウトプットしてくれましたので、私はそれをレビューし、要件どおりかどうか確認したうえでコーディングを依頼しました。その結果、LLMをパラメーターにより動的に切り替えられる、汎用性の高いアプリが出来ました。

LLMプロバイダーアーキテクチャ設計

このように、すでに学習されている技術的な知識の広さや深さは、私個人の情報量や経験値をはるかに超えています。こうした分野では、人間が時間をかけて自力でコーディングを行うこと自体に、もはや大きな価値を見いだしにくくなりつつあるのかもしれません。もちろん、学ぶことや経験を積むこと自体はかけがえのない大切な行為であり、私自身もそれを否定する気はまったくありません。ただし、仕事としてアウトプットを素早く正確に出すという観点においては、もはやAIには太刀打ちできないのではないかと感じてしまいました。

もっとも、私たちが扱っている業務システムは、以前にも述べたとおり、LLMが学習していない情報が多く含まれています。業界特有の商習慣や企業モデル（企業情報やビジネスモデル、業務内容）、そしてそれを支える組織形態などをLLMへインプットするのは現時点では難しい面があります。そのため、業務ロジックをAIに完全にコーディングさせるのはまだ難しいというのが実情です。しかし、これはあくまでも現時点での話にすぎません。業務知識を事前学習以外の形でLLMに渡す方法が確立され、実現したい業務内容を正しく伝えられるようになれば、将来的には業務ロジックのコーディングさえもAIでまかなえる可能性があるのではないか、と感じています。

では。