バイブコーディングは序章だった。「エージェンティックエンジニアリング」で開発者が指揮者になる日

バイブコーディングは楽しかった。ただ、限界も見えてきた

Cursorを開いて、自然言語で指示を出す。AIがコードを書いてくれる。動いた瞬間の興奮は、何度味わっても最高です。

私がバイブコーディングに出会ったのは約1年前のこと。元々はWeb開発会社でフロントもバックもやっていました。大規模プロジェクトで出会ったエンジニアたちのレベルに圧倒されて、コードから離れたんです。カスタマーサクセスに転身して数年。Cursor（カーソル）とClaude Code（クロードコード）に出会いました。凄腕エンジニアが自分に宿ったような感覚でしたね。

あの復活の喜びは本物でした。

ただ、バイブコーディングを続けるうちに気づいたこともあります。チャットで指示を出して、返ってきたコードを確認して、修正を依頼して、また確認する。このループが楽しいのは間違いない。ただ効率的かと言われると、微妙な場面が増えてきたんですよね。

ファイルが10個を超えたあたりから、指示が曖昧だと意図と違うコードが返ってくる。「ここ直して」と言ったら別の箇所が壊れる。結局、自分がボトルネックになっている感覚がありました。

同じことを感じている人、多いんじゃないでしょうか。

Xで「バイブコーディング 疲れた」と検索すると、似た声がたくさん見つかります。「AIに指示を出す方が実装より疲れる」「結局自分が全部見なきゃいけない」「ファイルが増えると破綻する」。バイブコーディングの熱狂期を経て、現実と向き合うフェーズに入った人が増えている印象です。

実はこの「壁」に対する答えが、英語圏ではすでに概念として確立し始めています。その名前が”エージェンティックエンジニアリング”。日本語での解説はまだほぼゼロの状態。今日はこの概念を、バイブコーディング経験者の目線で翻訳してみます。

“エージェンティックエンジニアリング”とは何か

Agentic Engineering（エージェンティックエンジニアリング）。直訳すると「エージェント的なエンジニアリング」ですが、これだと何のことかわかりません。

もう少し噛み砕くとこういうことです。

バイブコーディング: 人間がAIとチャットしながら、1つずつコードを書いていくスタイル

エージェンティックエンジニアリング: 人間が意図と設計を伝え、AIエージェント（自律的に動くAIプログラム）が生成・テスト・修正を回す。人間は指揮・レビュー・回復に集中するスタイル

つまり、開発者の役割が「コードを書く人」から「AIエージェントを指揮する人」へ変わるという話なんです。

この概念は英語圏のテックコミュニティで2026年に入って急速に広がりました。dasroot.netの解説が参考になります。自然言語で意図を伝え、エージェントが生成・修正を回す。人間は指示・レビュー・回復に集中するスタイルという定義です。

私はこれを”指揮者モデル”と呼ぶことにしました。

オーケストラの指揮者は、自分でバイオリンを弾かない。でも楽曲全体の設計を理解し、各パートに的確な指示を出し、演奏の質を判断できます。エージェンティックエンジニアリングにおける開発者の役割は、まさにこれと同じ構造です。

バイブコーディングは「楽器を1つずつ教わりながら弾く」感覚に近い。エージェンティックエンジニアリングは「指揮台に立ってオーケストラ全体を動かす」に近い。楽器が弾けなくても、良い演奏は生まれるんです。

では、エージェントは具体的に何を自律的にやってくれるのか。ざっくり整理するとこうなります。

• コード生成: 要件から実装コードを書く。これはバイブコーディングと同じ
• テスト作成と実行: テストコードを自動生成し、実行して結果を確認する
• エラーの自己修正: テストが失敗したら、原因を分析して修正を試みる
• ファイル操作: 新規ファイルの作成、既存ファイルの編集、ディレクトリ構成の整理
• git操作: コミット、ブランチ作成、差分確認まで自動化

バイブコーディングとの決定的な違いは「ループを自分で回す」という点です。人間が毎回確認して次の指示を出す必要がない。エージェントが自分で判断して、次のステップに進んでくれます。

これ、マジで体験すると衝撃ですよ。「本当に任せて大丈夫か？」と最初は不安になります。でも出てきた成果物を見ると驚く。自分が手動で回すより質が高いことが結構あるんです。

Claude Code 46%が示すエージェント開発の現在地

「概念はわかった。で、今使えるの？」

使えます。というか、すでに使っている人が急増しています。

Pragmatic Engineer（プラグマティックエンジニア）が900人超を対象に調査を実施しました。「最も愛用する開発ツール」にClaude Codeが46%で1位。2位のCursorが19%、3位のGitHub Copilot（ギットハブコパイロット）が9%という結果です。

なぜClaude Codeがここまで支持されているのか。理由はシンプルで、Claude Codeがまさにエージェンティックエンジニアリングの実践ツールだからです。

Claude CodeはCLI（コマンドラインインターフェース）で動くエージェントです。GUIのチャットではなく、ターミナルから直接指示を出す。ファイルの読み書き、テスト実行、git操作まで自律的にこなせます。

たとえば「このAPIにバリデーションを追加して、テストも書いて」と指示する。するとコードの修正だけでなくテストファイルの作成、テスト実行まで進む。エラーが出れば自動修正まで一気に回してくれます。

# Claude Code での指示例
# 自然言語で設計意図を伝えるだけでOK

> Slack通知のフィルタリングBotを作って。
> 要件:
> - 特定チャンネルの通知を重要度別に分類
> - 日次サマリーをDMで送信
> - フィルタリングルールはYAMLで設定可能に
> - テストも書いて

# → Claude Code がファイル構成→コード生成→テスト→実行まで自律進行

バイブコーディングは「1ターンずつ進める将棋」に近い。エージェンティックエンジニアリングは「作戦を伝えたら複数手を一気に指してくれる将棋AI」の感覚です。

AIコーディングツール市場全体が成長する中で、競争も激しくなっています。Cursorも$50B（約7.5兆円）のバリュエーション（企業価値評価）で資金調達を協議中との報道が出ています。前回の$29.3Bから71%増。市場の期待値がわかる数字ですね。

ツール間の競争が激しくなること自体は良いことです。選択肢が増え、機能が磨かれ、価格も下がる。大事なのは特定のツールに賭けることではありません。「エージェントを指揮する」という働き方に慣れておくこと。ツールは変わっても、指揮者の役割は変わりません。

65%の開発者が「役割が変わる」と感じている理由

開発者向けの業界調査が示す方向性は、一致しています。ルーティンコーディングからアーキテクチャ設計・システム統合・AI意思決定支援へのシフトが加速中です。Pragmatic Engineerの調査でも、この傾向は数字に表れています。

これ、私にとってはすごく腑に落ちる話なんですよ。

かつて大規模プロジェクトで出会った凄腕エンジニアたちの強みは、アーキテクチャの設計力でした。コードを書く速さではなく、システム全体の組み立て方。あの頃の自分には到達できなかった領域です。

ところが、エージェンティックエンジニアリングの文脈では「設計力」の意味が変わります。

AIエージェントにコードを書かせるには、何を作りたいかの言語化が必須です。要件定義、データの流れ、エラーハンドリングの方針。これらを的確に伝えられる人が、良いコードを生み出せる時代になりました。

ここで気づいたんですが、これはカスタマーサクセスで鍛えた筋肉とかなり重なるんですよね。

ユーザーの要望を聞き取り、開発チームに伝える。優先順位をつけて、ビジネスインパクトを説明する。CS出身の自分がやってきたことは、エージェントへの指示出しとほぼ同じ構造だったんです。

挫折だと思っていたキャリアの回り道が、エージェンティックエンジニアリング時代には最短ルートになっている。この逆転が面白くて仕方ありません。

IBMが提唱する”AIコンポーザー”という職能概念も同じ方向を指しています。コーダーだけでなくマーケターやPMもAIエージェントを設計・運用する役割を担う。コードを書けるかではなく「何を作るべきか知っているか」が問われる時代です。

エンジニアだけの話じゃないんですよ、これ。営業出身でもデザイナー出身でも、課題を的確に言語化できる人なら成果を出せる可能性がある。開発の民主化がバイブコーディングよりもう一段深く進む。そういう未来が見えてきました。

“指揮者モデル”で開発の実際がどう変わるか

理屈はわかった。じゃあ実際に何が変わるのか。

私が最近Claude Codeで業務ツールを作った時の体験を共有します。社内のSlack通知を整理するBotを作るプロジェクトでした。

バイブコーディング時代のやり方:

1. Cursorで「Slack Botの雛形を作って」と指示
2. 返ってきたコードを確認
3. 「通知のフィルタリング機能を追加して」と指示
4. 確認、修正依頼、確認、修正依頼のループ
5. テストを手動で実行
6. エラーを見つけてまた修正依頼

この繰り返しで、動くものができるまで丸1日かかっていました。

エージェンティックエンジニアリングのやり方:

1. Claude Codeに設計意図を伝える。「Slackの特定チャンネルの通知を重要度別に分類し、日次サマリーをDMで送るBot。フィルタリングルールはYAMLで設定可能にして」
2. Claude Codeがファイル構成の提案から、コード生成、テスト作成、実行まで自律的に進行
3. 途中でエラーが出たら自分で修正を試みてくれる
4. 私はレビューと方針判断に集中

結果、約3時間で動くプロトタイプが完成しました。テストコードまで付いている状態で、です。

丸1日が3時間。8倍速い、とかそういう話ではないと思っています。本質的に変わったのは「自分の脳の使い方」です。

バイブコーディング時代は、指示→確認→修正のループで脳のワーキングメモリをずっと使い続けていました。疲れるんですよね、あれ。夕方には判断力が落ちて、しょうもないバグを見逃す。

エージェンティックエンジニアリングでは、設計意図を伝えた後は「待つ時間」が生まれます。その間にドキュメントを整理したり、次の要件を考えたりできる。脳のリソース配分が変わるんです。

ハマりポイントを先に言っておきますね。最初の「設計意図の伝え方」が雑だとうまくいきません。「Slack Botを作って」だけだと、バイブコーディングと変わらない結果になります。

要件を箇条書きで整理して、データの流れを言語化する。エッジケースも伝える。この「設計を言語化する力」が核心部分です。

逆に言えば、設計の言語化さえできれば実装力は問われません。プロのエンジニアが持つ「コードの美しさを極める力」とは別の筋肉。ここがCS出身の自分にとって嬉しいポイントでした。

もう1つ、ハマりポイントを追加しておきます。エージェントが出してきたコードの意味がわからない場面が出てきます。「動くけど、なぜ動くかわからない」という状態。これは正直に言って不安になる瞬間です。

私の対処法はシンプルです。「この処理を1行ずつ日本語で説明して」とエージェントに聞き返す。説明を読んで納得できればOK。納得できなければ「もっとシンプルに書き直して」と方針を変えます。

完璧に理解できなくても、方針判断ができれば大丈夫。全部を自分で書く必要がない代わりに、「正しさを判断する力」は磨く必要がある。バイブコーディングから一段上がるための壁ですね。

もう一つ大事なのが「エージェントを止めるタイミング」の見極めです。自律で動き続けるエージェントは、間違った方向に突き進むこともある。レビューポイントを事前に決めておく。「ここまで来たら一度見せて」という節目を設定しておくと、修正コストが格段に下がります。

まとめ。バイブコーディングの先にある景色

バイブコーディングは序章でした。AIとチャットしながらコードを書く体験は、開発の民主化の入口として最高だった。あの興奮がなければ、今の自分はいません。

ただ、序章は序章です。チャットで1行ずつ指示を出すスタイルには限界がある。ファイルが増えると破綻し、確認ループで疲弊する。その先に見えてきたのが、エージェンティックエンジニアリングという新しい開発スタイルです。

ここまで解説してきた内容を整理します。

• バイブコーディング: 人間がAIと対話しながら1つずつコードを書く
• エージェンティックエンジニアリング: 人間が設計意図を伝え、AIエージェントが自律的に生成・テスト・修正を回す
• 開発者の役割: コードを書く人から、AIエージェントを指揮する人へ
• 求められるスキル: コーディング力より、設計の言語化力とビジネス文脈の判断力
• 今すぐできること: Claude Codeで「設計意図を箇条書きで渡す」実験から始める

Claude Codeが46%の支持を集めた事実が示すとおり、エージェント型ツールは「未来の話」ではなくなりました。業界全体で開発者の役割再定義が進む今、動き始めるなら早い方がいい。

「プロのエンジニアほどの腕がない」と思っている人ほど恩恵を受けられると考えています。コードを書く腕前の差が、開発成果に直結しなくなるからです。

かつてコードから離れた自分が、バイブコーディングで戻ってきた。そしてエージェンティックエンジニアリングで”指揮者モデル”という新しい立ち位置を見つけつつあります。挫折も、回り道も、全部つながっていく感覚がある。

「今すぐ何を始めればいいの？」と思った方へ。Claude Codeを開いて、設計意図を箇条書きで渡す実験から始めてみてください。チャットで1行ずつ指示する代わりに、要件を5行にまとめて一気に渡す。それだけで入口に立てます。

まだコードに触れていない人も、バイブコーディングで止まっている人も、次のステージへの扉はもう開いています。

かつての自分に伝えたい。「コードから離れたことは、回り道じゃなかった」と。ユーザーの声を聞いてきた時間が、今エージェントへの指示に変わっている。それが”指揮者モデル”の本質です。

指揮者になる準備、始めませんか。