AIがコードを書く時代。エンジニアは不要？

先日こんな記事がオススメに挙がってきました。

この見出し、なかなか強烈ですよね。数字を見るだけでも衝撃的です。

この記事を読んで「エンジニア要らないじゃん」って思う人が（特にエンジニアじゃない層に）たくさんいそう。でもちょっと待ってほしい。

見出しと数字だけが一人歩きしている？

この記事、元ネタはグッドパッチの土屋CEOがnoteに書いた記事です。

元記事はかなり読み応えがあって、「デプロイできた」だけじゃない大事なことがちゃんと書かれています。たとえばこんなことが。

• 49%が 「何を作るかが問われる」 と気づいた
• 39%が 「非エンジニアでも作れた」 ことに衝撃を受けた
• 45%が 「言語化力がボトルネック」 だと感じた

ちなみに元記事のnoteの見出しは「1ヶ月で200個のアプリと300件のナレッジから見えたこと」と、かなり誠実なものです。それをITmediaが「コーディング経験ゼロの86％がデプロイ達成」という見出しで取り上げた結果、見出しで釣るような記事になってしまっている。こういう記事の作り方が気に入らないし、読んだ人に誤った印象を与えかねない。

私とAIコーディングツール

本題に入る前に少しだけ自分の背景を。私は言語を問わず40年以上コードを書いてきました。

そんな自分がAIコーディングツールを使い始めたのはCursorから。ただ、IDE連動の使い勝手と壁打ち（アイデアや設計を整理するための対話）のしにくさが合わなくて早々に離れました。

次にChatGPTへ。コーディングツールではないのですが、壁打ちのしやすさからコード生成にも使うようになりました。ただ会話が長くなるほど重くなり、以前の会話で決めた前提を忘れたり、同じファイルを添付しても古いバージョンを参照し続けたりと、じわじわストレスが溜まっていきました。

今はClaude Codeがメインです。ただこれも万能ではなく、壁打ち中でもすぐコードに反映しようとしたり、会話が長くなると以前の会話が最新の会話に紛れ込んで話がズレたりすることがあります。それでも今のところ一番しっくりきています。

AIは「動くもの」は作れる。でも「正しいもの」は保証しない

そのClaude Codeを使ってCloudFormationテンプレートを編集していて、ヒヤッとした場面がありました。

CloudFormationはリソースの論理ID（テンプレート内でリソースにつける名前）が変わると、中身が同じであっても既存のリソースを削除して再作成しようとします。作業していたものは段階的リリースを前提としていて、最終的には既存リソースをそのまま活かしつつ経路だけを切り替える、という構成にする必要がありました。つまり、リソースが勝手に再作成されてしまうと、その計画が崩れてしまいます。

AIが提案してきたコードは機能的には正しく、動作も問題ないものでした。ただ、そのまま適用すればリソースが再作成されてしまう。それに気づけたのは、CloudFormationのこの挙動を知っていたからです。知らなければ「動くコードができた」と思ってそのまま適用していたかもしれません。

AIは「回答には間違いがある可能性がある」と自分で言っています。もちろん責任逃れの側面もあると思いますが、実際にそうなんです。それを確認できるかどうかが、知識がある人とない人の差だと思います。

とは言ったものの、私自身AIが生成したコードをほぼそのまま採用したことがあります。ChatGPTでAWSリソースを操作するシェルスクリプトを書いた時のことで、これは最初から「使い捨て」のつもりだったので、コードをそのまま採用しました。ソース内のコメントの入れ方が気に入らないとか、変数名が気に入らないとか、対話式の問いかけの仕方が気に入らないとか、細かい点はありましたが、どうでも良いんです。だって「使い捨て」だから。重要なのは破壊的な操作をする部分だけで、そこだけ重点的に確認しました。まず対象リソースを表示するだけのコードにしてもらい、間違いがないことを確認してから破壊的なコマンドに変えてもらって完成、という流れで。

「どこを見るべきか」「どこは見なくていいか」を判断できるのも、知識と経験があってこそだと思います。そしてそれは、AIに何を聞くべきかという判断にも同じことが言えます。

AIは聞いたことには答えてくれる。でも最善を教えてくれるわけじゃない

もうひとつ、別のCloudFormationテンプレートを作っていた時の話です。

やりたいことを伝えると、AIはお手本のような典型的な構成を提案してきました。おそらくは問題なく動作する構成で、パッと見た限りでは特に問題なさそうでした。ただ、私には他にもいくつか候補となる構成がありました。それらをAIに伝え、各構成の比較表を作ってもらいながら、実装の難易度やリソース間の結合度なども含め、多角的に調べてもらいました。「この構成だとこういうデメリットが生まれる」「いや、そちらの構成の方がこの点で不利だ」——そんなやりとりを繰り返しながら、最終的には最初の提案とは別の構成の方がメリットが大きいという結論に至りました。これがまさに壁打ちで、最も時間をかけた部分でもあります。

AIは聞いたことには答えてくれます。「他の案はある？」と聞けば他の構成も出してきます。ただそれが「世の中で実現可能な選択肢の全て」ではありません。実際この時も、私が提案した構成はAIからは出てきませんでした。より良い選択肢を引き出せるかどうかは、そもそも「他の選択肢があること」を知っているかどうかにかかっていると思います。

エンジニアリングとは、コードを書くことではない

ここまで読んで、「プロンプトをうまく書けば回避できるんじゃないか」と思うかもしれません。

でもその「うまく書ける」こと自体が、すでにエンジニア寄りの思考なんだと思います。CloudFormationの論理IDの話にしても、「リソースが再作成されるかもしれない」ということに気づけるかどうかは、その挙動を知っているかどうかにかかっています。知らなければ、そもそも何を気をつければいいかという思考にすらなりません。

コードが書けることとエンジニアリングができることは別の話です。エンジニアリングの本質はコードを書くことではなく、論理的・段階的に問題を分解して思考できることだと思っています。「何が起きうるか」を想像し、「どこを確認すべきか」を判断し、「どの選択肢が最善か」を見極める力。AIはその思考の代替にはなれません。

グッドパッチの元記事にもこんな言葉がありました。「整理されていないものは、AIにも伝えられない。自分の仕事が整理されていないから、AIに伝えられないのが本質」。これはAIへの指示の話だけではなく、エンジニアリングそのものの話でもあると思います。

もちろん、これらの問題はいずれAIが進歩していくことで解決されるかもしれません。AIがどこまで進化し、今でいうエンジニアリングがどうなっていくのか、正直まだ予想できません。ただ少なくとも今は、知識と思考力がある人間がAIと組むことで、初めて良いものが作れると感じています。

最後に

ところでこの記事、文章は全てAIに書いてもらっています¹。

1. 記事内で紹介した体験や考えはすべて本当のことです ↩