はじめに：コードを書かないという新常識
「エンジニアは自分でコードを書いて当たり前」──現役プログラマの多くが無意識にこう思っていないでしょうか。タイトルは一見過激ですが、言いたいことは業務においては自分で一行一行コードを書くのではなく、生成AI（例：ClaudeやChatGPTなど）を活用してコードを作成すべきということです。
また、プログラミングのすべてを否定するのではなく、あくまで仕事上の効率と品質を最大化するための意見であり、スキル習得や学習目的でのプログラミングはこの限りではありません。仕事とトレーニングは別物と割り切り、日々の開発業務では発想を転換して「コードはAIに書かせる」新常識を受け入れるべきという提案です。
モデルの性能向上に伴い「AIに向かないタスク」は日々減っています。初期のモデルでは難しかったことが、最新モデルでは難なくできるようになっている例も多いです。私自身も、この数か月で以前の考えが大きく変わり、この記事を書くきっかけとなりました。
「コードを書くのが当たり前」という思い込みを捨てる
プロのソフトウェア開発において本当に重要なのは、「問題を解決してユーザーに価値を届けること」です。決して「自分の手でコードを書くこと」自体が目的ではありません。かつてはコードを書かずにソフトウェアを生み出すことなど不可能でしたから、「プログラマはコードを書くのが本業」という意識が根付くのも無理はありません。しかし現在、生成AIという強力なツールの登場によって、その常識が崩れつつあります。
実際、Googleによればエンジニアの71%が既にコーディング業務でAIを利用しているとの報告があります。多くの開発者が既に「コードはまずAIに提案させる」というやり方に変えているということです。職業エンジニアは「キーボードを叩いてコードを書く人」から「AIを駆使してより速く価値を生み出す人」という役割であるという認識に変えていく必要があると思います。
生成AIがもたらす効率化と品質向上
生成AIを活用する最大のメリットは、生産性の飛躍的向上です。従来、何日もかかっていた実装が数時間で済み、テストコードやドキュメントの自動生成によって品質管理の効率も飛躍的に向上することは当たり前になってきています。
しかし、表面的にはAIの有用性を認めつつも、無意識に「エンジニアは自分でコードを書くことが必要」という前提を抱いている人を多く見かけます。よく見かけるのは、すべてをAIに任せることができずに、一部は自分でコードを書いているという例です。そして、経験がありスキルの高いプログラマほどコードの主導権を持ちたがり、自分でコードを書こうとする傾向があるように見受けられます。
さらに、自分がコードを書きながらスキルアップした経験を踏まえ、初心者や若手にも「最初は一からコードを書くべきだ」ということを必要だと強く主張することがよくあります。
しかし、AIの生成したコードはベストプラクティスに沿ったテンプレートや過去の知見を踏まえたコード提案を行えるため、初心者にとっても良いお手本になります。少なくともプログラムを入力する作業は不要になり、AIが生成したコードの内容をチェックして品質を担保することが、人間の重要な役割になります。これはAIが人間の作業を置き換えるというより、人間とAIが協働することで速度と品質の両立が可能になるというべきでしょう。
さらに生成AIは、開発者の負担を減らし創造的な作業に集中させてくれるという効果もあります。反復的で機械的なコーディング作業はAIに任せ、人間は設計や問題の本質的な部分に時間を割けます。例えば、煩雑なAPI連携コードや単純なCRUD処理はAIに書かせ、その間にエンジニアはビジネスロジックのブラッシュアップやユーザー体験の向上策を考える、といった具合です。 コードを書く作業そのものではなく、ユーザーに価値を届けるための付加価値部分にエンジニアの力を集中できるのです。
よくある懸念と批判
生成AIでコードを書くことについて、エンジニアからは様々な反対意見や不安の声が上がります。確かに疑問はもっともですが、それを乗り越えるだけの価値がAI活用にはあります。
「AIが作ったコードは誤りが多く、信用できないのではないか。」
確かに生成AIは時に誤った回答や筋違いなコードを書くことがあります。いわゆるハルシネーションと呼ばれる現象です。例えば存在しない関数を呼び出すコードを提案したり、微妙なバグを含むケースもゼロではありません。しかし、この問題は人間がレビューを行うことで十分に対処可能です。AIの生成したコードを、単体テストやレビューで検証すれば、誤りは大半検出できます。テストやレビューを行うことで責任を持つのが人間の役割です。 時間のかかるコーディングをAIに任せることによる生産性向上メリットの方が大きいのです。AIだってバグのないコードを書くのは難しく、結局レビューやテストは必要です。ただし、人間がコードを書くのではなく、AIが生成した結果を検証し、高度なロジックを判断するほうが品質向上につながるケースも多いのです。
「AI任せのコード読みにくく、スタイルや最適化がおかしいかもしれない。」
AIが生成したコードは読みにくく自分のスタイルに合っていない、という声もよく聞かれます。しかしこれは、コーディング規約を示したり、サンプルコードに従ったコードを書くように指示すれば、かなり洗練されたコードを出力できます。またAIはコメントやドキュメントも自動生成できるため、結果的にコードの可読性・保守性が向上するケースすらあります。実際、AI支援下で書かれたコードは、バグ検出や可読性の指標で人間の書いたのコードより良好だったという報告もあり、私自身もそう感じています。重要なのは、AIへの指示の仕方を考えて、出力物を人間が洗練させる意識です。そうすれば質の低下どころか、むしろ標準化された高品質なコードを短期間で揃えることができます。そして修正に関しても、AIへ指示して行うことで、その後のコード生成がより洗練されたものになり更なる品質の向上が望めます。
「AIに頼っていたら自分のスキルが伸びないのでは？コーディング力が落ち、成長できなくなるのが不安だ。」
先に、AIの生成したコードは初心者にとって良いお手本になると述べました。それでもなお、自分の手を動かしてコードを書かないと身につかない。という気持ちはあると思います。確かに最低限のコーディングの訓練は必要ですが、それは研修や学習で行うことであり、業務でのプログラミングはAIを利用したほうが効率・品質がよくなります。
さらに言えば、AIを使いこなすこと自体が新たなスキルセットになりつつあります。生成AIを適切にプロンプトし、出力を評価・修正する能力は今後のエンジニアに必須の技能です。AIを使って様々な実装例を見ることで、かえって自分一人では思いつかなかったテクニックを学べるという面もあります。要するに、AIとの協調も一種の修行なのです。「AIに頼ると成長しない」ではなく、「AIを使いこなせないと成長機会を逃す」時代になりつつある点も認識すべきでしょう。
「AIは過去のデータから一般解を出すだけだから、革新的なアイデアや創造的な実装は生まれないのでは？」
これは半分正解で半分誤解です。確かにAIは訓練データの範囲内でパターンを見つけるので、真に独創的なアルゴリズムをゼロから発明することは得意ではありません。そのため、特に研究開発的な未知の課題では人間の創造性が不可欠です。しかし日常の業務で書くコードの大部分は、既存のパターンや定石の組み合わせではないでしょうか？創造性が求められる場面は設計や要件の段階が多く、実装レベルでは「過去にもあったような処理」をいかにミス無く書くかが重要だったりします。そうした定型的なコーディングはむしろAIの十八番です。AIに任せておけば凡庸な実装は素早く上がり、人間はシステム全体のアイデア出しや斬新なUXの検討といった本当の意味でクリエイティブな仕事に時間を充てられます。
革新的なアイデアや創造的な実装も、そのロジックやアルゴリズムをAIに指示すれば実装そのものは大幅に早められます。それでも「コードを書く過程でひらめくこともあるから創造性を奪われたくない」という意見もあります。確かに、自分で手を動かす中で生まれるアイデアもあります。しかしAIを使う場合でも、プロンプトを工夫したり複数のアプローチを試す中で新たな発想を得ることは可能です。例えば「別の方法でも書いてみて」とAIに依頼すれば、違った切り口の実装が得られ比較検討できます。人間一人では一つの実装を書き上げるだけで精一杯だったものが、AIを使えば複数案を瞬時に用意できるので、かえって創造的な選択肢が広がるとも言えます。要するに、創造性が必要な部分まで無理にAIに任せる必要はなく、クリエイティブなコア以外をAIに任せることで人間の創造力を最大限発揮できるというのが本当の姿です。
職を失った職人にならないために
「プログラミングは自分で書いてこそ」という職人的プライドが損なわれるのでは、という声にも共感はできます。コードを書くこと自体に喜びを感じる──その気持ちは多くの開発者が共有するところです。
また、「AIがないとコードが書けない」という場合に不安を感じる人もいるでしょう。しかし、それにこだわってやり方を変えられない人は、どこか産業革命で職を失った職人のようにも思われます。産業革命のとき、職を失ったのは「技術に仕事を奪われた人」ではなく、「技術を使う側に回れなかった人」でした。現代でも伝統工芸の職人や、従来の工法を扱う専門職はしっかり必要とされているし、写真が生まれたからといって芸術家がいなくなったわけでもないでしょう。要は、仕事として開発しているソフトウェアが工業製品なのか、伝統工芸や音楽・スポーツのようなものなのかということです。
個人や趣味の開発でのプログラミングが無くなるわけではありません。AtCoderのような競技プログラミングでは、人間のプログラミングスキルが問われます。
考えてみるとエンジニアの仕事や作品の価値には、「結果」と「ストーリー」の二つがあると言えます。「結果」は製品や作品そのものの品質や機能のことで、「ストーリー」は作り手や制作過程に宿る物語です。工業製品のように「結果」が重視される世界もあれば、スポーツや芸術のように「ストーリー」が大切にされる世界もあるのです。
仕事としてのソフトウェア開発が、工業製品のように「結果」が重視される領域なのか、それとも伝統工芸や芸術のように「ストーリー」が重視される領域なのか──その違いによってAIとの向き合い方も変わってくるはずです。
（規約を見て本人のダブルポストなら問題ないという認識でZennの記事を投稿しています。）