エンジニアの仕事の比重が実装から検証に移ったなーと思ってます。
LLMの実装能力はすでに実用水準を超えていますが、モデル成長速度は昨年よりもさらに加速しています。
この状況で我々がやるべきことはコードを書くことではなく、LLMが出力したものを読み、理解し、検証し、説明することに変わりつつあるなと思っていて、要件定義から設計、実装、テスト、レビュー、ドキュメント作成まで、一気通貫でLLMを使うフローを構築していく必要があります。
今回はこういったLLMを使った開発フローについて、具体的な開発手法の紹介！というよりはどちらかというと心構えやスタンスが中心の話にしてみようかなと思います。
LLMの能力はどこまで来たか
LLMのコード生成能力は3ヶ月以下の単位で状況が変わるほど速く進化しています。定型的な実装やパターンに沿った開発では、速度も品質も人間を上回る場面が増えてきました。
例えばClaude Opus 4.5がリリースされてからわずか3ヶ月でSonnet 4.6がリリースされました。
性能は同程度と言われてますが、コストは下がっています。
今後、これ以上の速度で新モデルがリリースされ続けることを想定すると、定型的なWebアプリケーション開発やデータ処理パイプラインの構築といった、パターンが確立した領域はほぼ自動化される気がしますし、ほぼ自動化されているプロダクトもすでに存在していますね。
- Claude Opus 4.5：2025年11月24日
- Claude Sonnet 4.6：2026年2月17日
ここで「自動化」と言っているのは、部分的に使うのではなく全面的に使うということで、要件定義、設計、調査、実装、レビュー、テスト、ドキュメント作成、デプロイ、運用。この全段階でLLMを軸に据えます。
チャットで質問を投げる程度だと、この能力は引き出せないと思います。
LLM中心の開発フローを試す
実際にLLM中心の開発フローがどこまで通用するか、具体例を示します。
壁打ちと情報収集 — 人間が問いを立てる
あるAPIのPoCを作ることになりました。まずClaude Codeで壁打ちを始めます。
何を作るべきか、何がわからないかを対話しながら洗い出していきます。並行してAgent Teamsで技術的な情報収集を走らせ、関連する技術仕様や既存実装のパターンを集めます。
この過程で引っかかる箇所が出てくると思います。
この引っかかりを言語化できるかどうかが、今後のエンジニアにとって一番求められる力になるんじゃないかなと思っています。
今回の例では地理空間情報に関するプロジェクトの例なので、たとえばこういうコメントを書きます。
- このエンドポイントのレスポンス、冗長じゃね？パフォーマンスきつそう
- 入力として範囲指定を受け付けるって書いてるけど、BBOX？ポリゴン？それともマルチポリゴンまで許容するん？
- 入力データは何件まで許容するの？1000件くらいにしないと空間解析のパフォーマンスやばそう
- 認証と認可に関する記述がない。どうなってんの？
- デプロイ先はどこ？
- そもそもいつまでに完成すれば良い？
ちょっと引っかかること、具体的な実装が想像できないこと、全部ツッコミ対象で、この疑問はmdで書き溜めていきます。
「人間が主導すること」と「コンテキストはMarkdownなどの外部ファイルに保持する」ことを意識していきましょう。
要件の精査 — 多角的に潰す
書き溜めた疑問をClaude Codeに投げて、多角的かつ並列にチェックさせます。自分が気づかなかった粗い箇所も出てくると思います。
疑問は二種類に分かれていて、技術的に解決できるものはLLMに聞くと良いですし、仕様の方針判断のように誰かが決めなければ進まないものは、関係者に即座に投げます。
あらかた疑問が解決されたら、回答群をLLMに整理させ、この段階で要件定義はおおむね完了とします。要件を定義してから実装に進むので、バイブコーディングとは違いますね。
計画と実装 — mdで設計し、Agent Teamsで回す
僕はよくSvelteKit/HonoでWebアプリケーションを実装します。
SvelteKit/Honoで構築した既存プロジェクトや実装テンプレートなどを参照として（Context7 MCPや/add-dirコマンド）LLMに渡していきます。
要件と参照プロジェクトをもとに、フォルダ構造やモジュール分割、API仕様などの計画をmdで作成させます。
ツール組み込みのPlanモードはなるべく使わず、カスタムのmdファイルで管理します。mdにしておけばエディタで自由に編集できるし、人間がインラインで注釈を書き込んで差し戻すのが楽です。
さらにCodexなど別のツールに渡すときもそのままコンテキストとして使えるので、ツール間で設計意図が途切れません。
その後、人間は計画内容を見て、自分の認識と概ね一致しているか確認します。意図の読めないモジュールや不明点があれば全部LLMに追求していきます。
mdとして明文化されていない暗黙の前提がある場合、LLMは人間の意図と違う提案をしてくるので、そこは注意が要りますが、計画に納得できれば、実装前にTodoリストを作らせます。フェーズごとの個別タスクを列挙させ、計画ドキュメントに追加していくのが良いです。
（もしくは、AIエージェントのTask機能）
このチェックリストが進捗トラッカーになり、LLMがタスクを終えるたびに完了マークを付けるので、長いセッションでも今どこまで進んでいるか一目でわかります。
Todoリストが揃ったらAgent Teamsで実装、テスト、レビューを回します。必要に応じてCodexにも精査させます。
実装が終わったら/simplifyコマンドや独自のレビュー用コマンドなどで冗長な箇所や品質の問題を潰します。
ひとつの作業に集中したい場合はこれで良いですが、自動化重視でいくつかの機能をまとめて実装したい場合はgit worktreeを作成し複数のPRを作らせるようにしましょう。
これらを自動で実行する/batchコマンドも便利です。
検証と完了
実装内容のドキュメント化は必須で、まずこれを読んでいきます。
計画を読み込んでいるはずなので、実装内容が全く理解できないということはないはずですが、それでも何度かエージェントと質問のやり取りをすることになるでしょう。
理解できたらテストのドキュメントも読んでいきます。テスト内容を確認して、問題なければ自分で動作確認し、デプロイまで持っていきます。
なんだかんだで完了し、今回の検証では、情報収集からPoC完成まで数時間程度の超短期間で終わりました。
もちろん本番にするには要件定義の精査、テストの拡充、デプロイや運用の設計、セキュリティ対応、保守体制の構築、リスクバッファが必要になります。
ただ、技術的な実現可能性を先に確認できているので、実体に基づいた計画が立てられます。作る前に見積もるよりも、関係者にとっても自分たちにとっても合理的だと思っています。
エンジニアの役割を再定義する
ここまでの実例を踏まえて、じゃあエンジニアはどうしていけば良いでしょうか。
コードを書く比重を下げ、検証の比重を上げよう
コードを一切書くなと言いたいわけではないです。実際にLLMよりも圧倒的に生産力が高いエンジニアも世にはたくさんいることでしょう。
ただ、LLMの方が速く正確に書ける領域が広がっている以上、人間がそこに時間を使う意味は薄れてきています。
その時間を、LLMの出力の検証や要件の精査、設計判断に振り向けたほうがいいと思っています。
PRのレビューもLLMに任せられる部分が増えています。仕様の意図を汲んだ設計判断や、ビジネスロジックの妥当性確認のように、コンテキストに深く依存する判断はまだ人間がやる領域です。
ですが、定型的なコードレビューについては既にAIの方が網羅的で正確な指摘をしているなーと思っていて、LLMに任せるのが良いでしょう。
少人数で大きな成果を出せる構造にする
LLMを使えば少ない人数でより大きく複雑なシステムを実装できます。例えば、個人でのAI開発はオーバーヘッドがほぼゼロだから極めて速いです。
一方、チーム開発になるとコミュニケーションコスト、レビュー待ち、コンテキスト共有の負荷がかかります。
この差を埋めるにはチーム全体でガードレールを整備する必要があると思っていて、個々のエンジニアの努力だけでは速度は上がりません。コーディング規約、テスト基準、レビュー自動化の仕組みをチームとして敷いて、LLMによる自動化の精度を組織で高めていくことが必要です。
業界の構造変化にも備える
LLMの発達で、技術リテラシーのある企業が内製に動く流れは現実的です。作って終わり、分析して終わりの仕事は、自分たちでLLMを使って片づけられるようになります。
ただし、複雑な要件、長期の保守運用、コンプライアンス対応、関係者との調整…これらは技術の問題ではなく責任の問題で、外部にシステム開発を委ねるという構造自体がなくなることはないです。
SaaSも同じで、運用コストがSaaSの利用コストを上回る限りは使われ続けるのだろうと思います。
自分たちが備えるべきは、簡単な仕事が減ることだけではないです。
ただ高速化して大規模なシステムを作れるようになっても、それ自体に大きな価値はありません。
機能を絞り込み、使う人がちゃんと使いこなせる状態になるまで伴走します。大きく作ることより、必要なものを届けきることだと思っています。使われないシステムをいくら速く作れても仕方がないので。
Forward Deployed Engineerを目指す
顧客のドメインに興味を持ち、本当に欲しかったものを引き出し、自ら実装していける。これが目指す姿だと思っています。
リーダーが要件を噛み砕いてタスクに落とし、メンバーはそれを消化するだけという構造は、LLM時代には不要な気がします。タスクを消化するだけならLLMのほうが速いです。指示待ちの人員にはきっともう居場所はないですよね。
参照すべきはForward Deployed Engineer、FDEという働き方だと思っていて、顧客の現場に入り込み、課題を直接聞き、その場で解決策を提示し、自分で手を動かして見せます。
AIで開発を自動化できるようになった今、自動化だけで満足していては足りません。自分自身の知識と判断力を常に鍛え続けなければ、顧客との会話の中で反射的に「この要件ならこのアーキテクチャでいける」と返すことができないです。
LLMはその場での実装を加速してくれます。
だけど何を作るべきかの判断は、ドメインへの理解と技術の引き出しの多さで決まります。AIによる自動化と自己強化は車の両輪で、片方だけでは走れないです。
Agentic Engineeringとは
ここまで述べてきたLLM中心の開発スタイルはAgentic Engineeringと呼ばれている気がします。
バイブコーディングとの違いは明確で、AIが書いたコードを読んで、理解して、検証して、説明できる力を前提にしています。
バイブコーディングはなんとなく動くものを作ります。
Agentic Engineeringは要件を定義し、設計を確認し、出力を検証し、品質を説明できる状態にします。主導権は人間にあります。
二つの路線を使い分ける
LLMの活用には二つの路線があると思っています。
一つは稼ぐ力をつけるための自動化路線です。
ガードレールを整備し、実装、テスト、レビューを自動化します。設計からPoC、フィードバックのループを高速で回します。既知の技術領域や繰り返しのパターンに向いています。
もう一つは正しい知識をつけるためのSDD、仕様書駆動開発の路線です。
コード生成はLLMに任せ、説明もLLMにさせます。しかし、不明点がなくなるまで読み込み、理解を深めます。未知の技術領域や学習が必要な場面で使います。
二者択一ではないです。既知なら自動化、未知ならSDD。どちらもやります。
ワークフローの実際
先ほどの検証で示したフローを一般化すると、こういう手順になります。
- 作業用ディレクトリを作り、VS Codeで開く
- Claude Codeで壁打ちしながら、何を作るべきか・何がわからないかを洗い出す。並行してAgent Teamsで技術的な情報収集を走らせる。引っかかる箇所はmdに書き溜める
- 書き溜めた疑問をClaude Codeで多角的にチェックさせる。仕様判断は関係者に投げる
- Context7 MCPや
/add-dirで参照プロジェクト・最新ドキュメントをLLMに渡す - 要件と参照をもとに計画をカスタムのmdで作成させる。ツール組み込みのPlanモードは使わず、mdファイルで管理する。エディタで自由に編集でき、他ツールへのコンテキスト引き継ぎも途切れない
- 計画内容が自分の認識と概ね一致しているか確認し、不明点や暗黙の前提があればLLMに追求する
- 計画が固まったら、フェーズごとの個別タスクを列挙したTodoリストを計画mdに追加させる。実装の進捗トラッカーとして使う
- Agent Teamsで実装、テスト、レビューを回す。必要に応じてCodexにも精査させる。まとめて実装する場合はgit worktreeで複数PRを並列に作らせる
-
/simplifyコマンドや独自のレビュー用コマンドなどで冗長な箇所や品質の問題を潰す - 実装内容をmdでドキュメント化させ、なぜそうなっているかを確認する
- 自分で動作確認し、問題があれば再作業
- デプロイし、PoCとして完成させ、実体に基づいた計画を立てる
このフローを回すには、LLMツール側の設定整備が前提になります。
CLAUDE.mdによるプロジェクトルールの定義、MCPサーバの接続設定、セキュリティ制約、カスタムスキルの整備など、やることは多いです。
ベストな設定かどうかはわかりませんが、これで事足りるな、という設定ファイル一式はclaude-code-settingsとして公開しています。
具体的な設定手順はそちらを参照してください。
すべての中間成果物はmdで蓄積します。知見が再利用できる形で残ります。
チーム間で技術の横断的継承がうまくいかない、Tipsを共有しても結局使われないという、といった問題はままあると思いますが、今後はmdで蓄積してLLMのコンテキストとして活用するフローで解決できると思っています。
/add-dirのように他プロジェクトをLLMが直接参照できるようになったため、テキストとして残っていればLLMが必要な場面で参照してくれます。
将来展望と心構え
将来のことは正直わからないですが、考えておくべきことはあります。
設計力
世間では設計力が大切だと言われています。直近1年は確かに必要だろうと思います。
ただそれは形式的な設計スキルというより、経験から来る直感かもしれません。これは筋が悪い、ここは後で問題になる、と嗅ぎ取れるかどうか。
モデルの性能が上がるにつれてLLMが担える設計判断の範囲は広がるだろうとは思いますが、そもそも何を作るべきか、どのトレードオフを取るかといった上流の判断はまだ人間の仕事で、この境界は今後動いていきます。
市場を想像する力
新しいビジネスを生み出す力はいつの時代も強いです。
ただしSaaSを自分で作って市場を取りにいくのでなければ（つまり、受託業務などであれば）、直接的には求められないスキルかもしれないです。
もっとも、そういう受動的な立場の人間自体が不要になっていく可能性はあったりするのかもしれませんが。
顧客折衝とマネジメント力
直近1年では重要だと思っています。
顧客要望のとりまとめ、仕様や実装方針の整理、社内外の合意形成、説明、報告、運用。全員が身につけておくべきスキルだと思います。
先に述べたFDEの話と直結しますが、顧客の前で「持ち帰ります」ではなく、その場で筋の良い方向性を出せるかどうか。この反射速度は、日頃から技術とドメインの両方を鍛えていなければ身につかないです。
好奇心
好奇心がなければ何も始まりません。
問いを立てる力はドメイン知識と経験に裏打ちされた好奇心から生まれます。
LLMがどれだけ賢くなっても、何を聞くべきかを知っているのは対象に興味を持ち、使い倒し、不満を感じてきた人間が強いのだろうと思います。
コードを読む姿勢
コードは書かない、読まない、それでいいと慢心すると、外注に丸投げして足元を掬われる構造になります。
LLMはいわゆるオフショア開発と違い、日本語でしっかりと対話でき、何度でも質問できる。だからこそ有効活用して品質を引き上げる余地があります。
実装を見なければ、その技術がどう動いているかはわからないです。
品質が高い状態を当たり前にしていきたいですね。
自分自身、もうLLMなしの開発に戻れるとは思っていないです。
これは一時的なブームではなく、不可逆の変化だと感じています。LLM中心の開発スタイルは、もう定番になってしまいました。
おわりに
もし、まだClaude CodeのようなAIエージェント触ったことない人がいれば、まずは次のプロジェクトで、今回示したワークフローを一通り試してみてほしいです。
Claude CodeやCodexの基本操作を覚え、中間成果物をmdで蓄積する習慣をつける。LLMに任せた出力を読んで、理解して、説明できる状態にしてからPRを出す。担当プロジェクトのドメインを自分の言葉で説明できるまで理解する。打ち合わせの場で、解決策の仮説をその場で出す訓練をする。
個人としてやれることはすぐに始められます。
チームとして取り組む場合には、ガードレールの整備に着手するのがいいでしょう。
コーディング規約やテスト基準、レビュー自動化の仕組みを検討する。既存プロジェクトのリポジトリを参照資産として整理し、LLMへの入力に使える状態にする。蓄積したmdの資産を/add-dir等で共有し、チーム横断で知見が再利用される仕組みを作る。
全メンバーが関係者と直接やりとりする機会を設け、指示待ちではなく自走できる体制を前提としたプロジェクト運営に切り替えていくのが良いのかもしれませんね。
具体的な設定例も参考にして見てください。
一昔前まではAIによってエンジニアが不要になると言われていましたが、直近では採用が回復しているようです。
僕もほぼ丸1年AIエージェントを使い倒してみましたが、それなりに考えることも多く「あ、これはエンジニアリングだ。エンジニアはまだまだ必要かもしれない」と何度も思いました。
うまく波に乗ってエンジニアリングもなんでも楽しめるEMを目指していきたいですね。