AIを「なんとなく動かす」フェーズは、そろそろ終わりに近づいています。OpenAIの元研究ディレクターであるAndrej Karpathyが「エージェントエンジニアリング」という言葉を使って整理した概念に、Googleがついにまとまったツールセットをぶつけてきました。この記事では、その背景と何が変わるのかを整理します。
「バイブコーディング」の何が問題だったか
Karpathyが「バイブコーディング（vibe coding）」という言葉を使うとき、それは批判ではなく現状描写です。感覚で指示を出してAIに書かせ、なんとなく動いたら完成とする開発スタイルのことで、プロトタイプには十分機能します。問題は、それを仕事の現場に持ち込もうとしたときに起きます。動作の基準がなく、誰かが確認したわけでも、セキュリティを考慮したわけでもない。バイブコーディングで作ったものを本番環境に出すのは、感覚だけで設計した橋を渡るようなもので、壊れるまで壊れたと分からない。
Karpathyが「エージェントエンジニアリング」として提唱した概念は、この曖昧さに構造を与えようとするものです。具体的には、仕様設計（spec design）、評価ループ（eval loops）、セキュリティ監視（security oversight）の3つを軸にした規律として定義されました。「AIに任せる」のではなく、「AIが正しく動いているかを人間が設計・検証する」という発想の転換です。
ツールが分散していた、という本質的な課題
エージェントエンジニアリングの考え方自体はすでに数年前から議論されていました。では、なぜ普及しなかったのか。理由の一つは、実践しようとすると必要なツールがフェーズごとにバラバラだったことです。
コードを書くためのエディタ、環境を立ち上げるターミナル、動作確認のためのブラウザ、デプロイのためのクラウドコンソール、評価のための別フレームワーク――これらをつなぎ合わせながら作業するのは、エンジニアリングというより道具の管理に近い状態でした。30代の開発チームリーダーが部下にAIエージェントの評価作業を依頼しようとしても、「どのツールを使えばいいか」から説明しなければならない状況が続いていたわけです。
GoogleがまとめたツールセットのPOINT
今回Googleが提供したのは、このフェーズ分断を解消しようとするツールチェーンです。仕様設計から評価ループまでを一つの環境で回せる設計になっており、それぞれのフェーズで別のインターフェースを開き直す手間がなくなります。
以下に、フェーズごとの対応を整理します。
| フェーズ | 従来の対応 | Googleのアプローチ |
|---|---|---|
| 仕様設計 | ドキュメントツール（Notion等）+ エディタ | 統合環境内でのspec定義 |
| コード生成 | Copilot等 + ターミナル | エージェント実行環境と統合 |
| 動作確認 | ブラウザ + 手動テスト | 自動評価ループ（eval）が内蔵 |
| デプロイ | クラウドコンソール（別ログイン） | 同一環境からデプロイ可能 |
| セキュリティ確認 | 別ツール or 手動チェック | モニタリングと統合 |
このまとまりが重要な理由は、「できること」が増えたからではなく、「つなぐコスト」が下がったからです。ツールを切り替えるたびに文脈が途切れ、確認が漏れ、手順が形骸化するのが現場の実態です。一つの環境で完結できると、評価ループのような「やるべきだが後回しにしやすい」ステップが実際に回るようになります。
ChatGPTをどう仕事に組み込むかについて書いたこの記事でも触れましたが、AIの活用で本当に差がつくのは使い始めの段階ではなく、「使い続けられる仕組みがあるか」という段階です。今回のツール整備はまさにその「続ける仕組み」を作るためのものと言えます。
会社員にとって何が変わるか
「自分はエンジニアじゃないから関係ない」と思った方は、少し待ってください。エージェントエンジニアリングの影響は、コードを書く職種以外にも及び始めています。
例えば、経理部門で月次の集計作業をAIエージェントに自動化させているチームを想像してください。エージェントが正しい数字を出しているかを確認する「評価ループ」が整備されていなければ、間違いが静かに蓄積していきます。誰も確認しないまま3ヶ月が過ぎ、決算前に矛盾が噴出する――これはバイブコーディング的なAI活用の典型的な失敗パターンです。仕様を決めて、評価の基準を作って、定期的に確認する。Karpathyが言っていることは、実はこれだけです。
営業チームでリード分析をAIに任せている場合も同じです。「なんとなくAIに分析させていた」状態から「分析精度を定点観測する仕組みがある」状態に変わるだけで、業務の信頼性がまったく変わります。プロンプトの書き方ガイドで整理した「AIへの指示の品質」だけでなく、「AIの出力をどう検証するか」まで設計することが、これからのAI活用の標準になっていきます。
「エンジニア以外」が今から意識しておくべきこと
技術的な話は開発チームに任せるとして、管理職やビジネス側の担当者が今から考えておくと差がつくのは、評価基準の言語化です。
AIエージェントに何かを任せるとき、「うまくいったかどうか」をどう判断するかを先に決めておく必要があります。これはツールの話ではなく、業務設計の話です。「営業レポートのAI要約が使える品質かどうか」を判断する基準を自分たちで持っていなければ、どんな優れたツールを渡されても評価ループは回りません。
Karpathyが提唱した概念がなぜ重要かというと、それが「AIに何をさせるか」より「AIが正しくやっているかをどう確認するか」という問いを中心に置いているからです。この問いは、エンジニアだけが答えられるものではありません。むしろ、業務の中身を知っているビジネス側の人間が答えを持っていなければ、エンジニアも設計のしようがない。AI副業や社内AI活用の第一歩として整理したこの記事でも書いたことですが、AIを道具として使いこなすためには、使う側が「何が正解か」を持っている必要があります。
まとめ
Karpathyが整理した「エージェントエンジニアリング」という概念は、AIを感覚で動かすフェーズの次に来る規律です。Googleのツール整備によって、その規律を実践するための環境がようやく整い始めました。ただ、ツールが揃っても「評価の基準を持つ人間」がいなければ動きません。あなたの職場でAIエージェントが動いているとして、その出力が正しいかどうかを誰が何をもって判断しているか――その問いが、今すぐ立てられる最初の一手です。
