エンジニアのAIエージェントとの付き合い方

「山手線 3D ジオラマ」の技術ブログをこれまで 20 本書いてきました。地図ライブラリの座標変換、Three.js のメモリリーク、PLATEAU の重さに泣かされた話など、いずれも自分の手でコードを書きながら積み上げてきた経験です。
ところが、ここ半年で私の開発スタイルは劇的に変わりました。きっかけは Claude Code（Anthropic 社が提供する AI コーディング支援ツール）を、仕事と個人開発の両方で本格的に使い始めたことです。

正直に告白すると、このシミュレーターの後半に追加した機能 ― おいかけモードのカメラ補間、メモリリーク修正、GitHub Actions のデプロイワークフロー、いくつかのバグ修正 ― これらの実装の大半は、私自身が直接コードをタイプしていません。AI エージェントに「こういう挙動にしたい」「こういう構造にしたい」と指示し、出てきたコードを読んで、必要に応じて差し戻す。そういう開発スタイルに完全に切り替わりました。

本記事では、AI エージェント時代にエンジニアはどう生きるべきか、現場感覚で感じている変化を書き残しておきます。技術ブログとは少し趣が違いますが、個人開発を続けてきた一人のエンジニアの「現在地」として読んでもらえれば嬉しいです。

1. Claude Code を使い始めて起きた変化

私が Claude Code を本格的に使い始めたのは 2025 年の後半です。最初の印象は「コード補完がやけに賢いな」程度でした。ところが、何日か触っているうちに、これは「補完」ではなく「もう一人の開発者」だと気づきました。

例えば、メモリリークを追いかけたときの話（teckblog13 で書いた件）も、最初に「1 時間プレイするとブラウザが落ちる」とエージェントに伝えると、ヒープスナップショットの取り方、Detached DOM の見方、Three.js の dispose() 漏れの典型例まで、私が思い出す前に提示してくれました。

もちろん、エージェントが提示した内容が常に正しいわけではありません。実際、序盤は的外れな修正もありました。しかし、こちらが「いや、原因は GLTFLoader 側のキャッシュかもしれない」と返すと、それを起点にさらに深掘りしてくれます。会話の往復で問題を解いていく感覚は、これまでの開発体験とは明らかに別物でした。

2. これからのエンジニアは「手動でコードを書く」ことが激減する

断言してもいいと思っています。これからのエンジニアは、手動でコードをタイプする量が劇的に減ります。

もちろん、ゼロにはなりません。しかし、今まで「フォームのバリデーション処理を 200 行書く」とか「型定義を地道に並べる」とか「典型的な CRUD API を一通り実装する」といった作業は、AI エージェントに委ねたほうが圧倒的に速くて正確です。実際、私自身がこの 3 ヶ月、業務でも個人開発でも「自分で書くより、エージェントに指示して書かせる」のがデフォルトになりました。

これは脅威でしょうか。私はそう思いません。むしろ、エンジニアが本来やるべき仕事 ― 「何を作るべきか」を考えること、「どう設計すべきか」を判断すること ― にようやく時間を割けるようになった、と感じています。タイピングや syntax の暗記から解放され、設計と判断にエネルギーを集中できる時代が来た、と捉えるべきだと思います。

ただし、これは「楽になる」という話とは少し違います。後述しますが、設計と判断の責任は今までより重くなります。指示がブレると、AI は迷わず大量のダメコードを生成してくれます。

3. 必要なスキルは「プロンプトエンジニアリング」

では、これからのエンジニアに必要なスキルは何か。プロンプトエンジニアリングです。

プロンプトエンジニアリングとは、ざっくり言えば「AI に対して的確な指示を組み立てる技術」のことです。「ログイン機能を作って」と雑に投げるのと、「Next.js App Router、認証は Auth.js の Email Magic Link 方式、セッションはサーバー側で管理、CSRF 対策と Rate Limit を入れて、既存の Prisma スキーマに User と Session テーブルを追加する形で」と投げるのとでは、出てくる成果物のクオリティが天と地ほど変わります。

良いプロンプトを構成する 4 要素

私が業務と個人開発で意識している要素は次の 4 つです。

文脈（Context）：このプロジェクトの構成、使用技術、既存コードの設計思想、避けたいこと。
期待する出力形式（Output Format）：コード全体が欲しいのか、差分だけか、テストも書いてほしいのか、説明文も付けてほしいのか。
制約条件（Constraints）：パフォーマンス要件、セキュリティ要件、既存 API との互換性、依存ライブラリを増やさない、など。
段階的指示（Step-by-step）：複雑な機能は一気に出させず、設計 → 骨格 → 実装 → テストと段階的に区切る。一括投げは精度が落ちる。

言ってしまえば、仕様書を書くスキルとほぼ同じです。違うのは、人間相手のドキュメントよりも厳密で、かつ機械的に読まれることを前提にしている点。曖昧な表現は曖昧なまま実装され、「いい感じに」と書けば「いい感じ」とは限らないコードが返ってきます。

具体例として、私がシミュレーターのおいかけモード（teckblog5）の改修をエージェントに依頼したときのプロンプトの一部を以下に示します。

# プロンプト例（一部）
役割: あなたはMapLibre GL JSとThree.jsに精通したシニアフロントエンド
エンジニアとして振る舞ってください。

文脈:
- 山手線3DジオラマというSPA型のWebアプリで、地図上を走る電車を
  カメラが自動追従する「おいかけモード」を実装しています。
- 既存実装は map.easeTo を毎フレーム呼んでおり、ピッチ・ベアリング・
  ズームを同時に変化させると「酔う」とユーザー報告がありました。
- 既存コードの抜粋を以下に貼ります（省略）

依頼:
- ピッチ/ベアリング/ズームを別の周期で滑らかに補間する案を提案
- 候補を3つ出し、それぞれメリット・デメリットを併記
- 採用案については疑似コードレベルで実装イメージを示す
- TypeScriptで、既存のクラス構造（CameraFollower）に組み込む形

制約:
- 60fps を維持できること（重い計算はしない）
- 依存ライブラリは追加しない
- iOS Safari 15 以降で動作すること

これくらい書いておくと、出てくる成果物の精度が一気に上がります。逆に、「カメラ追従を直して」だけだと、何度も会話のキャッチボールが必要になり、結果的に時間を浪費します。

4. AI エージェントは「ものすごく優秀なシニアエンジニア」として扱う

これが、私がこの半年で得た一番大きな学びかもしれません。AI エージェントは「便利なツール」ではなく、「ものすごく優秀だが、命令されたこと以外はやらないシニアエンジニア」として扱うのが正解です。

シニアエンジニアに「ログイン機能作って」と頼んだら、彼/彼女は「どんな認証方式？」「セッション管理は？」「CSRF 対策必要？」と聞き返してくるはずです。AI エージェントもそう振る舞ってくれることはありますが、多くの場合、こちらの言い回しからエージェントが「妥当そう」と判断した実装を返してきます。質問してこないからといって、すべての論点を AI が考慮しているとは限りません。

「命令する側の引き出し」が成果を決める

結局のところ、AI エージェントは命令されたこと以上のことはしません。だから、命令する側にどれだけの知見があるか、どれだけ「あの観点も忘れずに指示できるか」が成果物の質を決めます。

例えば、私がメモリリーク調査をエージェントに依頼したとき、最初は「メモリが増え続けるんだけど」とだけ伝えました。返ってきたのは「const を使わずに大量にオブジェクトを生成していませんか」程度の浅い回答でした。一方、「Three.js のジオメトリ・マテリアル・テクスチャの dispose、MapLibre のレイヤー・ソースの remove、addEventListener の removeEventListener 漏れ、AbortController の付け忘れ、これらを順に確認したい」と書くと、それぞれを丁寧にチェックして具体的な修正案を出してくれました。

つまり、「あー、こういうことも起きうるよな」という引き出しを持っているかどうかで、AI から引き出せる成果がまったく変わってきます。これは、何年もコードを書いてきたエンジニアにとって、引き続き武器になります。

5. これからのエンジニアに必要なのは「実装力」より「引き出し」

少し挑発的な物言いになりますが、これからのエンジニアは「自分でゼロからコーディングする力」はそれほど重要ではないと思っています。重要なのは「こういうことができたよな」という過去の経験の引き出しです。

具体的には、以下のような知識が引き出しになります。

「この要件は、過去にやった〇〇のパターンで解決できそう」と思い出せる経験値
「この設計は、後から〇〇という問題を生む」と先回りできる失敗経験
「この技術と、あの技術を組み合わせれば、要件をスマートに満たせる」というアーキテクチャ感覚
「セキュリティ的に、ここは絶対に外してはいけない」というセンサー
「パフォーマンス的に、ここがボトルネックになる」という勘所

これらは、AI エージェントに「コードを書いてもらう」だけでは身につきません。何度も実装し、何度も失敗し、何度も「あの時こうしておけば」と後悔した経験から得られるものです。引き出しの多さは、依然として人間の強みであり、商品価値です。

逆に、引き出しが空のエンジニアが AI エージェントに「いい感じにシステム作って」と投げても、出てくるのは「動くがメンテできない」「動くが本番で破綻する」「動くがセキュリティガバガバ」のいずれか、もしくはすべてです。

6. お客さんは自分でシステムを作れない

「AI エージェントが普及したら、お客さん自身がシステムを作れるようになって、エンジニアは要らなくなるのでは？」という議論をよく聞きます。私の答えは NO です。

確かに、簡単な問い合わせフォームや、社内向けの小さなツールなら、お客さん自身が AI に投げて作れる時代が来ています。実際、業務でも「これくらいなら自分たちで AI に書かせます」と言われるケースは増えました。

しかし、本当に業務で使うシステムになると話は別です。たとえば次のような観点は、ほぼ確実にお客さん自身では拾い切れません。

セキュリティ要件：認証・認可、CSRF / XSS / SQLi 対策、秘密情報の扱い、ログの取り方。
運用要件：監視、アラート、バックアップ、災害時の復旧、デプロイ戦略。
パフォーマンス要件：負荷想定、キャッシュ戦略、DB のインデックス設計、N+1 の検出。
法務・規約要件：個人情報保護法、特商法、利用規約、GDPR、外部 API の利用規約。
変更耐性：要件は必ず変わる前提で、何を抽象化し何を具体化しておくか。

お客さんが AI に「会員管理システム作って」と投げて出てくるのは、表面的には動くものの、パスワードを平文保存していたり、認可チェックが抜けていたり、ログに個人情報を垂れ流していたりするシステムです（業界用語で言う「バカシステム」がこれにあたります）。本人たちはそれが危険だと気づきません。気づくのは、攻撃を受けて漏洩した後です。

つまり、「要件を正しく捉え、AI に正しく指示を出し、出力をレビューできる人間」はこれからも必要であり続けます。むしろ需要は増えるとすら思っています。

7. これからのエンジニア像：PM × プロンプトエンジニア

では、私たちは何になればよいのか。私の現時点での答えは、「お客さんの要望を聞き出し、整理して、AI に的確に伝えてコーディングさせる人」です。乱暴に言えば PM とプロンプトエンジニアのハイブリッドです。

必要な動き方

要望のヒアリング：お客さんは「何が欲しいか」を正確には言えません。雑談・観察・現場視察を通じて、本当に欲しいものを掘り起こす力が要ります。これは AI には真似できません。
要件の整理：曖昧な要望を、設計の出発点になるレベルまで整理する力。エッジケース・例外処理・将来の拡張性まで言語化する力。
AI への指示出し：上で書いたプロンプトエンジニアリングのスキル。「文脈・出力形式・制約・段階」の 4 要素を抑えて指示する。
成果物のレビュー：AI が出したコードを、自分の引き出しと照らして「これは妥当か」「ここに穴はないか」を判定する。これも AI には任せきれません。
運用責任：本番で何かあったとき、原因を切り分け、修正を指示し、再発防止策を打つ。最終責任を負う人間として立ち回る。

これらの力は、コーディングスキルとは別物です。むしろ、コミュニケーション力、整理力、判断力、責任感といった「人間らしい総合力」に近い。だから私は、AI 時代になっても、エンジニアの仕事は無くならないどころか、もっと「人間らしい仕事」になっていくと思っています。

8. 個人開発者として、AI エージェントとどう向き合っているか

最後に、個人開発者の視点で書き残しておきます。

「山手線 3D ジオラマ」のような趣味プロジェクトは、もともと「土日の数時間で、自分のペースで進める」性格のものでした。AI エージェントを使うようになってからは、同じ時間で 2〜3 倍のことができる感覚があります。逆に言えば、これまで「やりたいけど時間が足りなくて諦めていた」機能が、ぐっと現実的になりました。

ただし、AI に頼り切ると自分の引き出しが枯れていく感覚もあります。何でも AI に聞いて、自分で考えなくなると、徐々に「こういうこともできたよな」という勘が鈍る。これはエンジニアとして致命的です。

私は意識して、ときどき「これは AI に任せず、自分で書いてみる」「AI が出した実装を、なぜそうなっているのか自分で説明できるまで読む」という時間を作っています。AI を使い倒しつつも、自分の引き出しを増やし続ける ― この両輪が、これから 5 年・10 年エンジニアを続けていくうえで欠かせないと思っています。

まとめ

長くなったので、最後に要点を整理します。

これからのエンジニアは 手動でコードを書く量が激減する。設計と判断に時間を使えるようになる。
必要なスキルは プロンプトエンジニアリング。文脈・出力形式・制約・段階の 4 要素を意識する。
AI エージェントは 「ものすごく優秀なシニアエンジニア」として扱う。命令された以上のことはしない。
命令する側に必要なのは 「引き出し」。経験から得た仕様の幅と勘所がそのまま価値になる。
お客さんは 自分ではシステムを作れない（作れてもセキュリティ要件度外視のバカシステムになる）。要件を整理して AI に指示できる人は引き続き必要。
これからのエンジニア像は PM × プロンプトエンジニア。要望のヒアリング、要件の整理、指示出し、レビュー、運用責任までを通しでやる。

「コードを書く」だけがエンジニアの仕事だった時代は、もう終わりつつあります。でも、私はこの変化を悲観していません。むしろ、エンジニアという仕事が、ようやく「考える人」「設計する人」「責任を取る人」になれる時代が来た、と前向きに捉えています。

このサイト「山手線 3D ジオラマ」も、今後の機能追加は AI エージェントとの二人三脚で進めていく予定です。新機能リリース時には、また裏側の話を書きます。お楽しみに。