2025 年 2 月、Andrej Karpathy は vibe coding を、意図を自然言語で記述し、LLM による変更を最小限のレビューで受け入れ、自身の通常の理解範囲を超えてコードが成長することを許容するプラクティスとして説明しました。これは個人プロジェクトや試作品において印象的なスピードをもたらしました。
1 年後、彼はエージェント機能が進歩したことを観察し、エージェントをオーケストレーションしながらアーキテクチャとプロセスに対して強力な人間の監視を維持するという進化したプラクティスに対して、「エージェンティックエンジニアリング」を自身の好む名称として提案しました。彼が示したように、その目標は、ソフトウェアの品質を損なうことなく、エージェントの力を活用することです。
この区別は重要です。Vibe coding は、単一ユーザーによる重要度の低い個人作業には有効ですが、他の誰かがその結果に依存し始めた途端、隠れた負債、セキュリティ上の欠陥、保守性の問題が急速に蓄積されます。エージェンティックエンジニアリングは、最新のエージェントが持つスピードと力を維持しつつ、すべてを明確な構造、トレーサビリティのある成果物、そして人間の説明責任に基づいて固定します。
エージェンティックエンジニアリングのワークフロー
大まかな意図から始め、AI と設計に関する対話を重ねながら、機能をその構成要素に分割した設計ミーティングノートとして文書化します。設計が確固たるものになったと感じたら、設計階層（人々が Obsidian の「頭脳」を示すときに見せているもの）に、高レベルのビューとコンポーネントマップを記録します。これは、あなたとエージェントの両方が周辺のコンテキスト、関連する決定、依存関係にすぐにアクセスできるナビゲート可能な構造です。ここには、UML（統一モデル言語）、コードやユーザーインタラクションフローなどの設計図や、コンポーネント間の関係を明確にするアーキテクチャ決定記録（ADR）へのリンクも配置します。
各モジュールまたは最小の機能ブロックに対して、LLD 内に焦点を絞った spec.md を作成し、正確な動作、関数シグネチャ、エッジケース、テストの期待値、統合ポイントを定義します。この構造全体を設計コンテキストプロンプトとして使用し、AI に Wiki ページとスペックに直接トレーサビリティのあるチケット形式の階層を生成させます。エージェントが関連する spec.md を契約として従いながら、チケットごとに実装を進めます。その後、検証ゲートを実行し、デプロイし、観察し、要件の進化に合わせて生きた成果物を更新します。
実例：毎日のバックアップ検証ツール
毎日の S3 バックアップを検証し、失敗時に Slack アラートを送信する、プロダクショングレードの小規模な CLI ツールを考えてみます。
大まかな目標「毎日バックアップが正常であることを確認する、信頼性の高い何かが必要」から始めます。その後、AI とのアーキテクチャに関する会話を通じて、要件とエッジケースを明らかにします。
- 実際の S3 バックアップにおける現実的な障害モードは何か？
- 具体的に何を検証すべきか（経過時間、ファイル数、サイズ、成功率）、そしてどのようなしきい値が妥当か？
- ローカル開発環境とプロダクションの IAM ロール間で、設定とシークレットはどのように処理すべきか？
- 日常的にどのような CLI コマンドと出力形式が役立つか？
- 毎日スケジュール実行されるツールにとって、最も重要な非機能要件は何か？
これらの対話により、スコープが明確になり、ツールを中核コンポーネント（リトライロジック付き S3 メタデータ取得、検証ルールエンジン、通知システム、設定ローダー、CLI インターフェース、構造化ログ、エラーハンドリング）に分解する助けとなります。
設計が明確になったら、高レベルのビューとコンポーネントマップを設計階層 Wiki に文書化します。ここではすべてのページがバージョン管理され、リンク可能です。
Wiki は、フラットなドキュメントでは提供できない周辺のコンテキストを将来の読者に提供します。同じ設計作業の一環として、サブ LLD レベルで各モジュールに焦点を絞った spec.md を作成します。以下は、S3 メタデータフェッチャーの契約です。
この spec.md がエージェントに渡す契約です。例：「s3_client/ ディレクトリに spec.md 通りに正確に実装し、プロジェクト標準に従い、包括的なテストを含めてください。」Wiki とモジュールスペックが整ったら、AI にプロンプトを送り、それらから直接チケット階層を生成させます。すべての項目は機能要件と、その契約を定義するスペックにトレーサブルです。
その後、実装はチケットごとに進められ、それぞれが対応する spec.md を契約としてエージェントに渡されます。実際にそれが何を生み出すかを示します。スケジュール実行により、短いバックアップセットが検出され、アラートが発報されます。
実行はゼロ以外のコードで終了するため、cron ジョブがそれを検知し、Slack に届くアラートを発報します。
アラートには、オンコールエンジニアが行動を起こすために必要なルールコンテキストが含まれています。どのチェックが失敗したか、何が見つかったか、何が期待されたか、そしてどのバックアップセットか、といった情報です。
この階層的アプローチの利点
- エージェントが実装のボリュームを処理し、人間があらゆる層でアーキテクチャと品質を管理します。
- Wiki はプロジェクトレベルの発見可能性と決定を提供し、spec.md ファイルは高レベル設計を肥大化させることなく、正確なモジュールレベルの契約を提供します。
- 要件と決定は Wiki ページとスペックからチケットとコードへ直接流れ込みます。
- 変更はコードベースをリバースエンジニアリングするのではなく、生きた設計成果物から始まります。
- 明確な関心の分離は、並行作業、オンボーディング、監査をサポートします。
- T 型人材は、幅広い知識でナビゲートし、正確な質問で深掘りします。エージェントは、誰もシステム全体を頭で把握する必要なく、オンデマンドで深みを提供します。
Vibe coding は、探索と迅速な個人プロトタイピングのための優れたモードであり続けます。エージェンティックエンジニアリングこそが、同じ会話力を、他の人が信頼し保守できるシステムへと導く方法です。
T 型人材の役割
このワークフローは、特に T 型人材にとって強力です。つまり、アプリケーション領域全体にわたる幅広い知識を持ち、必要に応じて深く掘り下げる能力を持つエンジニアです。
なぜなら、アプリケーション全体がどのように機能しているかについて、完全で最新のメンタルモデルを常に保持している必要がないからです。エージェントがその深みを保持し、Wiki、spec.md ファイル、会話履歴から適切なコンテキストを持っていれば、オンデマンドで任意の部分を再説明できます。
あなたに必要なのは、何を探すべきか、どこを探すべきかを知る能力と、現在作業中の特定の項目を理解するまで正確な質問をし続ける規律です。T の横棒の部分がシステムの地図を与えます。AI エージェントは、今まさに重要となる正確なモジュール、エッジケース、統合ポイントにドリルダウンするために必要なスキルをサポートします。エージェントは、あなたが尋ねるたびに、網羅的な詳細を提供します。
これにより、人間の役割は「常にすべてを理解しなければならない」から「適切な高度でナビゲートし、質問し、検証する方法を知っている」へとシフトします。これこそが、エージェンティックエンジニアリングの真のスキルです。
