AIがコードを書くようになったとき、エンジニアは成長し続けられるのか？
私はその問いと向き合うことになった。
※本記事は英語で執筆し、日本語訳にChatGPTを使用しています。
ツールより、コンテキストが重要
IDEでAIアシスタントを使い始めたとき、正直かなり驚いた。周囲のコードを読み取り、コンテキストに沿った提案をしてくれる。その体験は、まるで魔法のようだった——もちろん、常に正しいわけではなかったが。
前職では、AI支援開発を本格的に試した。GitLab DuoやClaude Codeを使ってみたが、結果は正直に言って厳しかった。
問題はAIではなかった。コードベースにあった。
対象のプロダクトは約12年前に作られたもので、PHP 5と古いフレームワークの上に成り立っていた。問題は明確だった：
- ドキュメントのない社内製コンポーネント
- 混乱を招く命名規則
- ほぼ存在しないテストカバレッジ
- 非常に遅いE2Eテスト（CIに数時間）
さらに悪いことに、レガシーコードは直接テストできなかった。
加えて、PHP 5 + レガシーフレームワークからPHP 8.3 + ヘキサゴナルアーキテクチャへの移行が進行中であり、新機能開発・バグ修正・移行作業が同時に走っていた。
コードベースは常に 「移行途中」 の状態だった。この状態がAIを混乱させ、提案の精度を下げていた。
Claude Codeはこれらすべてをコンテキストとして取り込もうとしたが、アーキテクチャ自体が一貫していないため、しばしば迷い込んでしまった。
設計の相談やアイデア出しには役立ったが、実際のコード生成においては信頼できるものではなかった。
クリーンな土台がすべてを変える
現職では状況が大きく異なる。
アプリケーションはゼロから構築され、コードベースはクリーンで整理されており、多くは開発から1年以内のものだ。この違いは、Claude Codeの活用度に大きく影響している。
現在では、開発プロセス全体を通してClaude Codeを活用している。チームで定義したルールやスキルを与えながら、問題分析、アプローチ設計、設計判断、ドキュメント作成、実装までを一緒に進めている。
たとえば、API設計の案を複数出させ、それぞれを比較した上で最終判断は自分で行う。
さらに、生成されたコードに対しては、単に全体を見るだけではない。
実際のコードの細かい部分——1行ごとの小さな判断や実装の意図——にまで踏み込んで向き合う。
そこから学ぶこともあれば、自分の考えで再定義（リフレーム）することもある。
もはやすべてのコードを書くことはしていない。その代わりに、ロジック、構造、トレードオフを徹底的にレビューし、プロセスのオーナーシップは自分が持ち続けている。
この働き方によって開発スピードは大きく向上した。それ以上に重要なのは、学びが止まっていないことだ。
特に不慣れな言語では、質の高い生成コードを読み、批評することで、独学では出会えなかったような考え方やパターンに触れることができている。
不都合な問い
ひとつの問いが頭から離れない。
今、私はほとんどコードを書いていない。これは以前とは根本的に異なる働き方だ。では、自分はエンジニアとして成長し続けているのだろうか？それとも、これまで積み上げてきたスキルを少しずつ失っているのだろうか？
正直な答えはこうだ。
私は成長している——ただし、その形が変わった。
以前は、仕事の約70%がコードを書くことだった。今ではその大部分をAIに任せている。しかし残りの30%は大きく広がった。
設計の意思決定、アーキテクチャの思考、コードの批判的レビュー、そしてユーザーが本当に必要としているものを理解することに、より多くの時間を使っている。
私は以前よりも考えている。しかも、より深く。
トレードオフについて、より深く考えるようになった。システムの見え方も変わった。そして 「なぜそれが良くないのか」を言語化する力が確実に伸びている。
AIのコードをレビューするには、直感ではなく、思考を言葉にする必要があるからだ。
エンジニアリングは変わりつつある。これは無視できない変化だ。
この働き方を機能させるもの
前職について、もうひとつ重要な点がある。それは技術的負債だけではなく、チームの抵抗感だった。
AI生成コードに対する懐疑的な見方があり、それが無視できない摩擦になっていた。
この摩擦は重要だ。たとえコードベースが良くても、チームが実験する意欲を持っていなければ、AIから価値を引き出すことはできない。
現職ではその逆だ。チーム全体がAIの可能性を積極的に探っている。この違いは非常に大きい。
両方の環境を経験して、次の結論に至った。
Claude Codeから本当の価値を得るには、次の2つが必要だ：
-
クリーンな技術的土台
- 明確なルール・スキル・ドキュメント
- AIが理解できるコードベース
-
批判的で開かれた思考
- ワークフローを見直す意欲
- AIのアウトプットを評価する力
- 自分の価値を自覚すること
結論
現時点では、思考するエンジニアをAIが置き換えることはできないと思っている。
なぜなら、最終的な意思決定と結果に対する責任、オーナーシップを持つ必要があるからだ。
しかし、その力を劇的に増幅することはできる。
もはや問われているのは「コードを書けるか」ではない。
「それを判断できるか」だ。