はじめに： 革命への期待と、早すぎた高揚
エンジニアの皆さん、AIコーディング、使っていますか？
今年（2025年）に入り、AIコーディングの世界はまさに「革命道中」です。GitHub Copilotはもはや標準装備となり、CursorのようなIDE組み込み型、さらには自律型エージェントとして話題をさらったDevin、そしてClaudeやCodexのような基盤モデルを活用した強力なAIコーディング支援ツールが次々と登場しました。
これらのツールが「生産性を爆上げする」「AIでレバレッジを効かせる」という甘美な言葉と共に紹介されるたび、私は熱狂し、とりあえず飛びつきました。
「AIでレバレッジ効かせて、生産性爆上げ！」
「従来できなかった複数のプロジェクトを一人で回してプルリクエストたくさん作ってやるぜ！」
そんな輝かしい理想を胸に、私はAIエージェントとの「ペアプログラミング」ならぬ「AIへの過度な依存」に近い開発スタイルにのめり込んでいきました。まさに、君に夢中。
この記事は、そんなAIコーディングにどっぷり浸かった数ヶ月の「気づき」と、「痛烈な反省」を共有するものです。
AIがもたらした「光」（天国）
導入当初、すべては順調でした。まさに「最強の相棒」を手に入れたのだと確信していました。
- とにかく便利で楽: 面倒なテンプレートコード（例えば、新しいAPIエンドポイントのためのコントローラー、サービスクラス、リポジトリの雛形）や、テストファイル、設定ファイル（Dockerfile, .eslintrc, tsconfig.json…）の記述。これらすべてを、AIはプロンプト一つで一瞬にして書き上げてくれます。
- 知識の補完: 自分が曖昧にしか覚えていなかったライブラリの使い方や、知らなかった正規表現のパターンも、いい感じに補完してくれます。
- 圧倒的な進捗感: プロンプト（指示）を投げると、一気に数十行、数百行のコードが生産されるため、「めちゃくちゃ進んでいる」感が得られます。
この「成功体験」は強烈でした。
一度この速度感と全能感を味わってしまうと、もう元には戻れません。私はAIの能力にすっかり魅了され、AIへの信頼（あるいは、今思えば依存）を急速に深めていきました。
気づかぬうちに迷い込んだ「影」（地獄）
しかし、その「光」が強ければ強いほど、「影」もまた濃くなることを、このときの私はまだ知りませんでした。
今振り返ると当然のことばかりですが、当時の私は高揚感の中でそれを見落としていました。
1. 初めての実装が「記憶」に残らない
最も深刻だったのがこれです。
「この実装、俺やったっけ…？」
「この関数の引数の型、何だっけ…？」
AIに丸投げして「初めての実装」を行った機能は、驚くほど記憶に残りません。自分が手を動かし、頭を悩ませ、エラーと格闘したプロセスがすっぽり抜け落ちているため、記憶が全く定着しないのです。
2. 気づいたら設計が「意図しないもの」になっている
AIは局所最適なコード生成は得意ですが、アプリケーション全体のアーキテクチャや設計思想（例えば、なぜこのディレクトリ構成なのか、なぜこの命名規則なのか）、ビジネスロジック、そして既存のコードとの整合性を理解しているわけではありません。
プロンプトで指示していない（あるいはAIが汲み取れなかった）暗黙の設計原則は容易に崩壊し、気づいたら設計が意図しないものになっていました。
3. レビューコストが爆増する
AIは「MVP（Minimum Viable Product）」で作るという概念を知りません。指示が曖昧だと、将来必要になるかもしれない機能まで「よかれと思って」実装し、過剰に複雑なコードを生成することがあります。
コードの生成量は圧倒的に増えましたが、コードを読むのは人間です。
AIが生成した「それっぽい」コードのレビューとデバッグに、結局、自分がゼロから書くよりも時間がかかる、という本末転倒な事態が発生しました。
4. そして、すべてを実装し直した
極めつけは、プロダクトへの「愛着の欠如」 でした。
AIが書いたコードは、どこか他人のコードのようです。デバッグも修正も億劫になる。
そして最大の悲劇が訪れます。
結果、AIが作ったプロダクトを参考に、自分で再度実装し直すはめに…
AIコーディングを意識しすぎたあまり、AIが生成したコードを解読し、レビューし、結局捨てて実装し直すという、とんでもなく遠回りな「余計に時間がかかっている事実」に直面したのです。
（余談ですが、AIに大量に指示する→AI実装中→人間の集中力が切れる→別の技術記事を読み漁る…というコンテキストスイッチの多発も、生産性を著しく下げていました。。）
なぜ自分は「AIを使いこなせる人」になれなかったのか？
なぜこんなことになってしまったのか。
私は「AIを使うのが上手い人」と自分との違いを考えました。
最近つくづく思うのは、結局AIを使うのが上手い人は、自分ならこうするというアウトプットと筋道が見えている人ということです。
執筆やコーディングなどでLLMやAIエージェントを使う際、元々の技術力や判断力がそのまま生成結果の品質に比例しています。
そうした人は、自分で実装したときの「完成形」がなんとなくイメージできています。そしてその場合、その完成形を形作っていくのは「思考」というよりは「作業」になります。
だからそうした「作業」をAIに代わりにやらせるのは非常に相性が良いし、理にかなっているのです。
一方で、当時の私はどうだったか。
昨年まではAIの精度もいまいちと感じていたため、一部の実装をChatGPTに相談する程度で、ほとんど自分で手を動かして実装していましたが、今年に入りAIエージェントの登場により、ざっくりとした仕様（命令）のみを与えて、伝えたいメッセージや文体が定まっていない中でAIに執筆をさせたり、仕様やアーキテクチャが詰まっていない中でAIにコードを書かせていました。
これは、「思考」のレイヤーの大部分もアウトソースしてしまっている状態なのです。
もちろん一定の確率で想定を上回るアウトプットが出てくることもありますが、あくまでガチャ。
これは、完成形のイメージが頭の中にある状態で部下に指示を出すのか、指示する側もよく分かっていない解像度の低い状態で部下に指示を出すのかの違いにもよく似ています。基本的に後者の指示は上手くいきません。
コードの成果物のゴールと道筋を自分でわかってないと、AIコーディングはただのギャンブルです。
しかし、一度成功体験（ガチャの成功）を得てしまうとそれに頼りたくなるのが、人間の弱さでした。
結論：「思考」は手放すな、「作業」を任せろ
この痛い失敗から、私はAIとの向き合い方について一つの結論に至りました。
それは、「思考」と「作業」を明確に区別し、AIには「作業」だけを任せるということです。
AIに任せていいのは「作業」だけ
任せていい「作業」：
- 自分が頭の中でイメージできている実装の具体化
- 定型的なボイラープレートコードの生成
- 既知のパターンの適用
- テストコードの雛形作成
手放してはいけない「思考」：
- アーキテクチャの設計判断
- 実装方針の決定
- 技術選定の理由付け
- コードの意図と設計思想
AIを使いこなせる人は、この区別が明確です。完成形が頭の中にあり、「どう実装するか」という思考は既に終わっています。だからAIに「作業」を任せても、意図しない方向に進むことはありません。
一方、思考までAIに任せてしまうと、自分が理解していないコードが量産され、設計は崩壊し、結局すべてを作り直すことになります。
プロンプトより大切なもの
AIを使いこなすために最も重要なのは、プロンプトのテクニックではありません。
その領域における自分の「地力」です。
- ドメイン知識
- 設計能力
- 自ら手を動かして実装できる技術力
これらがあって初めて、AIに的確な「作業の指示」ができます。
実践：AIとの正しい向き合い方
- まず自分で設計を考える：AIに聞く前に、自分なりの実装イメージを持つ
- 小さく区切って指示する：大きな機能を丸投げせず、明確な単位で指示する
- 生成されたコードは必ず理解する：わからないコードは採用しない
- 初めての実装は自分の手で：記憶に残すため、最初は自分で書く
お客さんに動くものをサッと見せる分にはAIによる「バイブコーディング」もアリかもしれません。しかし、プロダクションコードで「思考のアウトソース」を成功させるのは、夢のまた夢です。
プロダクションコードの主役は、あくまで自分。AIに乗っ取られたら、ジ・エンドです。
人間がAIをハンドリングできないと、すべてが狂い始めます。大切なコードの品質を守りたいなら、自分自身が主導権を握らなければなりません。
おわりに
AIコーディングの熱狂から一歩引いて、遠回りをした結果、私は「自分でコードを書くこと」「設計と向き合うこと」の重要性を再認識しました。
AIを使いこなすとは、AIに依存することではなく、AIを的確に「使う」自分自身の能力を高めることだったのです。
この記事が、AIとの向き合い方に悩むすべてのエンジニアにとって、何かのヒントになれば幸いです。
Discussion