バイブコーディングからエージェントエンジニアリングへ：本当に何が変わったのか

2025年2月、Andrej Karpathyは一つの時代を定義するツイートを投稿しました：“There’s a new kind of coding I call vibe coding, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

その13ヶ月後、No Priorsポッドキャストで、彼は自ら作った言葉を引退させました。

“I went from 80/20 of writing code myself versus delegating to agents to like 2/98. I don’t think I’ve typed a line of code since December.”

「バイブコーディング」という言葉を生み出した本人が、それを時代遅れと呼んでいます。彼の新しい言葉：エージェントエンジニアリング。AIがコードを生成する能力が落ちたからではありません——コードを生成すること自体が、元々難しい部分ではなかったからです。

Karpathyが実際に言ったこと

No Priorsのインタビューは全編見る価値がありますが、特に三つの変化が際立っています。

1. 比率が逆転した。 Karpathyは自分でコードを書く割合を80%から2%に減らしました。残りはエージェントが担います。ボトルネックはタイピングの速さからオーケストレーションのスキル——並列で動く複数のエージェントをいかに上手く指揮するか——に移りました。

2. 「コードはもはや正しい動詞ですらない。」 ソフトウェア開発はマクロアクションのオーケストレーションになりました。関数を書くのではなく、機能を委任します。行ごとにデバッグするのではなく、アーキテクチャレベルでレビューします。Peter Steinbergerは複数のリポジトリにまたがる20分タスクを担う数十のエージェントを同時に動かしています。

3. AutoResearchは人間をループから完全に排除する。 Karpathyはnanoのハイパーパラメータを夜通し最適化する自律型研究ループを構築しました。長年の手作業によるチューニングにもかかわらず、エージェントは彼が見落としていた改善点を発見しました——value embeddingsへの忘れられたweight decay、不十分に調整されたAdam betaなど。彼の結論：“To get the most out of the tools, you have to remove yourself as the bottleneck.”

共通する糸：価値は実行から判断へと移りました。バイブコーディングは実行についてでした——プロンプト、生成、リリース。エージェントエンジニアリングは判断についてです——アーキテクチャ、検証、オーケストレーション。

次に来るもののエンジニアリングマニュアル

同じ週、Tw93——Pake、Moleの作者であり多作なオープンソースエンジニア——が”You Don’t Know AI Agents”を公開しました。これは本番でエージェントを信頼性の高いものにするために実際に何が必要かを網羅した深い技術ガイドです。Karpathyがビジョンを提供するとすれば、Tw93はエンジニアリングマニュアルを提供しています。

彼の中心的な主張：ハーネスはモデルよりも重要です。

“Using a more expensive model doesn’t always yield the massive improvements you’d expect. Instead, the quality of your harness and validation tests has a far greater impact on success rates.”

これは理論ではありません。OpenAI自身のエンジニアリングチームが実証しました：3人のエンジニアが5ヶ月で100万行のコードを書いた——従来の10倍のスピードです。鍵はより良いモデルではありませんでした。制約、検証、エージェントインフラについての正しい工学的決定でした。

バイブコーディングとエージェントエンジニアリングを分ける5つの原則

1. プロンプトエンジニアリングではなくコンテキストエンジニアリング

Transformerのアテンション複雑度はO(n²)です。コンテキストが長くなるほど、重要なシグナルが薄まりやすくなります。最も一般的な失敗モードは「モデルにできない」ではありません——それはコンテキストロットです：無関係なコンテンツが蓄積し、エージェントの判断品質が目に見えて劣化します。

解決策は階層化されたコンテキスト管理です：

• 永続層：アイデンティティ、規則、ハードな制約。短く、安定して、常にロードされる。
• オンデマンド層：スキルとドメイン知識。ディスクリプタは常駐し、フルコンテンツはトリガー時のみロード。
• ランタイム注入：タイムスタンプ、ユーザー設定、動的状態。ターンごとに追記。
• メモリ層：セッション間の経験。関連する時だけ読み込み、すべてのプロンプトに詰め込まない。

重要な洞察：決定論的なロジックをコンテキストに入れないこと。コードルール、リンター、フックとして表現できるものはすべて外部システムに任せる。モデルは考えるべきであって、ルールブックを読むべきではありません。

2. ACI原則に基づくツール設計

ツールの失敗のほとんどは、モデルが間違ったツールを選ぶことが原因ではありません——ツールがエンジニアのために設計されており、エージェントのためではないことが原因です。エージェントコンピュータインターフェース（ACI）フレームワークは設計の視点を変えます：

側面	悪いツール設計	良いツール設計
粒度	APIエンドポイントにマップ	エージェントの目標にマップ
返却値	完全な生データ	次の判断に関連するフィールド
エラー	汎用文字列	修正提案付きの構造化エラー
説明	何をするか	いつ使うか、いつ使わないか

具体的な例：get_post + update_content + update_titleを別々のツールとして提供するのではなく、update_yuque_postとして完全なアクションを一つの呼び出しで表現します。ツールの説明に反例を加えると、精度が53%から85%に上がります。

エージェントをデバッグする際は、まずツール定義を確認してください。ツール選択のエラーのほとんどは、モデルの能力ではなく不正確な説明が原因です。

3. 後付けではなくインフラとしてのメモリ

エージェントにはネイティブな時間的継続性がありません。セッションが終わると、コンテキストは消えます。4種類のメモリがそれぞれ異なる問題を解決します：

• ワーキングメモリ（コンテキストウィンドウ）：現在のタスク状態。能動的に管理。
• 手続き記憶（スキル）：物事のやり方。オンデマンドでロード。
• エピソード記憶（セッションログ）：何が起きたか。永続化され、検索可能。
• 意味記憶（MEMORY.md）：安定した事実。起動時に注入。

重要な設計上の選択：メモリの統合は可逆的でなければなりません。長い会話を圧縮する際、生のメッセージを削除せず——アーカイブしてください。ポインタを移動させ、データを破棄しないこと。統合が悪い要約を生成した場合、エージェントはまだ生の履歴にフォールバックできます。

4. 最適化の前に評価

エージェントの評価は従来のテストよりも根本的に難しいです。入力空間は無限で、LLMはプロンプトの表現に敏感であり、同じタスクが実行ごとに異なる結果を生む場合があります。

2つのメトリクス、2つの目的：

• Pass@k：k回中少なくとも1回正解。能力の限界をテスト。開発中に使用。
• Pass^k：k回すべて正解。信頼性をテスト。デプロイ前に使用。

最も危険なアンチパターン：評価が壊れているときにエージェントをチューニングすること。採点が欠陥があれば、歪んだシグナルに対して最適化しています。パフォーマンスが落ちたとき、エージェントを修正する前にまずインフラを確認してください——クラッシュを引き起こすリソース制限、バグのある採点者、または現実から切り離されたテストケース。

5. マルチエージェント連携にはプロトコルが必要

複数のエージェントを動かすことは並列処理についてではありません——隔離と連携についてです。サブエージェントはサマリーのみを返すべきです；彼らの検索、試行錯誤、デバッグプロセスは自分自身のコンテキストに留まります。メインエージェントのコンテキストは結論のみを受け取ります。

順序が重要です：まずプロトコルを定義し、次に隔離を確立し、それから協調について話す。構造化された通信（JSONLメッセージキュー、タスクグラフ、ワークスペースの隔離）なしでは、エラーがエージェント間で増幅されます。エージェントAが逸脱し、エージェントBがバイアスを強化し、エージェントCがそれを積み重ね、3つ全てが高い確信を持って誤った結論に収束します。

一つの表で見る進化

フェーズ	開発者の役割	コード品質	検証	スケール
手動コーディング	書き手	高い（自分のコード）	自分でテスト	一人
バイブコーディング	プロンプター	可変	自分で確認	一つのエージェント
エージェントコーディング	アーキテクト	構造化	エージェントが自己テスト	複数エージェント
エージェントエンジニアリング	オーケストレーター	ハーネス化	自動評価	エージェントチーム

各フェーズは前のフェーズを置き換えたのではなく——包含しました。センス、アーキテクチャ的思考、コードの理解、これらはまだ必要です。しかし実行層はあなたの指先からどんどん遠ざかっています。

実践上の意味

Karpathyは「Dobby the House Elf」というホームオートメーションエージェントを構築しました——3つのプロンプトがローカルネットワークをスキャンし、スマートデバイスのAPIをリバースエンジニアリングし、6つの別々のアプリをWhatsAppコマンドに置き換えました。“Dobby, sleepy time”ですべてがオフになります。

ソフトウェアについての彼の結論：“These apps shouldn’t even exist. Shouldn’t it just be APIs and agents are the glue of intelligence that tool-calls all the parts?”

これが軌跡です。ソフトウェアはあなたが操作する製品から、あなたの代わりに製品を操作するエージェントへと移行します。インターフェースはGUIから自然言語へと収縮します。複雑さは消えません——それはハーネス、ツール、評価、エージェントを信頼性の高いものにするメモリシステムへと移動します。

バイブコーディングは、AIがコードを書くという考えに私たちを慣れさせました。エージェントエンジニアリングは、AIが書いたコードを信頼性があり、保守可能で、自律的なものにするインフラを構築することです。

バイブはステップ1でした。エンジニアリングはその後のすべてです。

---

TeamdayはクラウドでAIエージェントを自律的に運用しています——SEO、コンテンツ、ソーシャルメディア、アナリティクスなど。KarpathyとTw93が説明するエージェントエンジニアリングの原則がわたしたちのAI人材を動かしています。エージェントチームの構築を始める。