AIコーディングエージェントは、ソフトウェア開発のあり方を変えつつあります。
しかし、AIエージェントを効果的に活用することは、単にClaude CodeやCodex、その他のコーディングエージェントを開いてコードを書くよう依頼するだけではありません。
より重要な問いは次のとおりです：
「製品の方向性と品質に対する人間のコントロールを維持しながら、複数のAIエージェントが独立して長時間にわたって機能できるワークフローをどのように構築するか？」
これが**エージェントエンジニアリング（Agentic Engineering）**の根底にある考え方です。
AIを高度なオートコンプリートツールとして考えるのではなく、各エージェントをエンジニアリングチームのメンバーとして考えることができます。
あなたは**船長（Captain）です。
AIエージェントはあなたの乗組員（Crewmates）です。
そして、チームが十分に大きくなったら、全員を調整する一等航海士（First Mate）**が必要になります。
この記事では、そのワークフローを段階を追って説明します。
1. 船を造る：適切な環境から始める
効果的なエージェントのワークフローは、開発環境から始まります。
ここで説明するワークフローは、GUI中心ではなく、ターミナル中心です。
これには主に2つの理由があります。
キーボードから手を離さない
エージェントと連携する際、常に次のような作業が必要になります：
- セッション間の切り替え
- コマンドの実行
- 出力の検査
- 新しいエージェントの起動
- 進捗の監視
- プロジェクト間の移動
キーボードとマウスの間を行き来するたびに、摩擦とコンテキストスイッチが発生します。
ターミナルアプリケーションはキーボード操作を中心に設計されているため、一貫したフローを維持しやすくなります。
どこでも同じワークフローを維持する
ターミナル中心のワークフローのもう1つの利点は、ポータビリティです。
同じワークフローを異なるマシンで使用でき、別のデバイスからリモートでアクセスすることも可能です。
ターミナルマルチプレクサと組み合わせると、これは特に強力になります。
2. ターミナル + Tmux + Neovim
このワークフローでは、主に3つのコンポーネントを使用します：
- ターミナルエミュレータ
- Tmux
- Neovim
Tmux：複数のエージェントセッションの管理
Tmuxはターミナルマルチプレクサです。
単一のターミナルセッションを持つ代わりに、ターミナルを複数のペインやウィンドウに分割できます。
例：
┌──────────────────────┬──────────────────────┐
│ │ │
│ Agent 1 │ Agent 2 │
│ │ │
├──────────────────────┼──────────────────────┤
│ │ │
│ Agent 3 │ Terminal │
│ │ │
└──────────────────────┴──────────────────────┘
これにより、複数のエージェントを同時に実行することが可能になります。
あるエージェントが機能開発に取り組んでいる間、別のエージェントがバグを調査し、自分用のコマンドラインとして別のペインを確保しておくことができます。
永続的なセッション
Tmuxセッションは永続的です。
セッションからデタッチ（切断）し、後で状態を失うことなく戻ってくることができます。
別のデバイスから同じセッションに接続することさえ可能です。
長時間稼働するエージェントのワークフローにおいて、これは非常に便利です。
3. Neovimとキーボードファースト開発
テキストエディタとしてNeovimを使用します。
VimとNeovimの背後にある哲学はシンプルです。マウスへの依存を最小限に抑え、開発者が主にキーボードを通じてエディタを制御できるようにすることです。
キーバインドが筋肉の記憶（マッスルメモリ）になれば、以下のような操作が極めて高速になります：
- ナビゲーション
- 検索
- 編集
- 削除
- 元に戻す（Undo）
- ファイルの検索
- コードベース全体の検索
ただし、エージェントエンジニアリングにおいてNeovim自体は必須条件ではありません。
重要な原則は**「Neovimを使わなければならない」**ということではありません。
それは：
「エージェントと対話する際の摩擦を最小限に抑える環境を構築する」
ということです。
4. エージェントハーネスの選択 — ただしエージェントに依存しないこと
現在、以下のような多くのコーディングエージェントが利用可能です：
- Claude Code
- Codex CLI
- Pi coding agent
- OpenCode
それぞれに独自の哲学、機能セット、そしてトレードオフがあります。
重要な原則の1つは、全体的なワークフローを**エージェント非依存（agent-agnostic）**に保つことです。
単一のエージェントを中心にすべてを構築するのではなく、メモリ、スキル、ツール、プロセスを、異なるエージェント間で機能するように設計します。
なぜでしょうか？
AIを取り巻く状況は非常に速く変化しているからです。
今日の最高のモデルやエージェントが、数ヶ月後にも最高であるとは限りません。
したがって、特定のツールに深く依存するよりも、優れたワークフローに投資する方が価値があることが多いのです。
5. メモリによるAIエージェントのオンボーディング
新しく起動されたエージェントは、あなたのプロジェクトについてほとんど何も知りません。
以下のようなことを自動的に知っているわけではありません：
- リポジトリの構造
- コーディング規約
- チームの働き方
- アプリケーションのテスト方法
- 過去のエージェントが犯したミス
- 特定の技術的決定が下された理由
そのため、エージェントにはオンボーディングプロセスが必要です。
シンプルで効果的な解決策は、**メモリファイル（memory files）**を使用することです。
一般的に2つのレベルがあります：
グローバルメモリ (Global Memory)
│
└── 複数プロジェクト間で共有
プロジェクトメモリ (Project Memory)
│
└── 特定の1プロジェクト専用
6. グローバルメモリ vs プロジェクトメモリ
グローバルメモリ
グローバルメモリには、プロジェクト横断的に適用される一般的なルールが含まれます。
例：
- 個人的なコーディングの好み
- コミュニケーションの好み
- 技術的な意思決定の原則
- 一般的なデバッグのルール
- エージェントが避けるべきこと
重要な原則は以下の通りです：
グローバルメモリを小さく保つこと。
グローバルメモリは多くのエージェントセッションにロードされます。
大きくなりすぎると、現在のリクエストに関係のない情報にトークンを消費してしまう可能性があります。
プロジェクトメモリ
プロジェクトメモリには、特定のコードベース固有の情報が含まれます。
例：
- プロジェクトの目的
- リポジトリの構造
- 用語集
- アーキテクチャ
- 重要なコンポーネント
- テストの実行方法
- コーディング規約
- よくある間違い
プロジェクトメモリは、そのプロジェクトにおける過去のすべてのエージェントセッションの集合的な学習結果と考えることができます。
7. メモリを時間とともに進化させる
初日から完璧なメモリファイルを書く必要はありません。
代わりに、プロジェクトと一緒に進化させてください。
エージェントがミスをした場合は常に：
- 問題を特定する。
- エージェントを修正する。
- エージェントにその教訓を記憶するよう求める。
- その学習をプロジェクトメモリに保存する。
時間が経つにつれて、メモリは生きたナレッジベースになります。
新しいエージェントは、過去のセッションで得られたミスや教訓から利益を得ることができます。
これは重要な考え方につながります：
「エージェントはコードを書くだけでなく、プロジェクト内での働き方も学習すべきである。」
8. すべてをメモリに入れない：スキルを活用する
やがて、プロジェクトメモリは大きくなりすぎます。
すべての知識がすべてのリクエストに関連するわけではありません。
たとえば、詳細なエンドツーエンド（E2E）テストの手順は、エージェントがアプリケーションを変更する際には役立ちます。
しかし、単に：
「このコンポーネントはどう機能しますか？」
と尋ねる場合、それらのテスト手順は無関係です。
ここで**スキル（Skills）**が役立ちます。
シンプルな構造は次のようになります：
メモリ (Memory)
├── プロジェクト概要
├── アーキテクチャ
├── 規約
└── 一般ルール
スキル (Skills)
├── E2Eテスト
├── リリース
├── データベースマイグレーション
├── コードレビュー
└── デプロイメント
9. スキルと段階的開示 (Progressive Disclosure)
スキルには専門的な知識や手順が含まれています。
エージェントは、すべてのリクエストに対してすべてのスキルを完全にロードする必要はありません。
代わりに、最初はどのスキルが存在し、それが何のためのものかを知っておくだけで済みます。
タスクがそのスキルを必要とする場合、エージェントはその詳細な指示をロードすることができます。
これが**段階的開示（progressive disclosure）**という考え方です。
これは以下のことに役立ちます：
- コンテキストサイズの縮小
- トークン使用量の削減
- 不要な情報の削減
- システムプロンプトをクリーンに保つ
- すべてを常にロードすることなく、より専門的な知識を保存する
これを理解する簡単な方法は次のとおりです：
メモリは「一般的にどのように機能するか？」に答え、スキルは「この特定の状況にどう対処するか？」に答える。
10. スキルのインストールは慎重に
もう一つの重要な教訓は、インターネットからランダムなスキルを盲目的にインストールしないことです。
スキルは、エージェントにあなたのマシンでアクションを実行するよう指示できます。
したがって、信頼できないスキルはセキュリティリスクをもたらす可能性があります。
また、人気があることが有効性の証明にはなりません。
スキルが何千ものGitHubスターを持っていたとしても、以下のようなことが起こり得ます：
- トークン使用量が増加する
- 不要なコンテキストが導入される
- エージェントのステップ数が増える
- 全体的なパフォーマンスが低下する
したがって：
人気 ≠ 有効性
スキルを評価する際は、以下を考慮してください：
- 誰が作成したか
- 実際に何をするのか
- 情報源は信頼できるか
- その主張は証拠に裏付けられているか
- 現実的なタスクで評価されているか
11. エージェントとのコミュニケーション方法を変える：音声入力
もう一つの興味深い最適化は、タイピングから音声入力への移行です。
長いプロンプトを打ち込む代わりに、単に声に出して伝えることができます。
例：
「このリポジトリを簡潔に説明し、最近のプルリクエストでどのような作業が行われたか要約してください。」
長いプロンプトの場合、音声入力はエージェントとのコミュニケーションに必要な労力を大幅に削減できます。
ただし、以下のようなものには依然としてタイピングが便利です：
- URL
- ファイルパス
- コマンド
- コード
- 正確な識別子
そのため、最適なワークフローは必ずしも音声のみではありません。
代わりに、音声とキーボードを、それぞれが最も理にかなっている場面で使い分けます。
12. ツールはモデルと同じくらい重要
エージェントは孤立して働くわけではありません。
以下のようなことを行うために、外部ツールに依存しています：
- GitHubへのアクセス
- コードベースの検索
- ブラウザとの対話
- コマンドの実行
- アプリケーションの検査
- 情報の取得
したがって、エージェントのパフォーマンスはモデルだけで決まるわけではありません。
システムを次のように考えることができます：
エージェントのパフォーマンス
│
├── モデル
├── プロンプト
├── メモリ
├── スキル
└── ツール
不十分に設計されたツールは、エージェントに以下を強いる可能性があります：
- ツール呼び出しの増加
- トークン消費の増加
- 時間の浪費
- タスクでの苦戦
これは、**ツールのエルゴノミクス（使い勝手）**がエージェントシステム設計の重要な一部として扱われるべきであることを意味します。
13. プランニング：「テキストの壁」を避ける
エージェントに複雑な機能の実装を依頼する場合、従来のワークフローは次のようなものでした：
ユーザーのリクエスト
↓
エージェントの分析
↓
長文の計画
↓
開発者が読む
↓
開発者のフィードバック
↓
エージェントが修正
問題は、計画がしばしば大きなテキストブロックとして提示されることです。
開発者は、頭の中で以下を再構築しなければなりません：
- どのような選択肢があるか
- UIがどのように見えるか
- どの部分が異なるか
- どのアプローチを選択すべきか
より良いアプローチは**視覚的プランニング（visual planning）**です。
14. アーティファクトを使った視覚的プランニング
単にMarkdownの計画を作成するだけでなく、エージェントはHTMLアーティファクトを生成してコンセプトを視覚化することができます。
例：
┌──────────────────────────────────────┐
│ Progress │
├──────────────────────────────────────┤
│ │
│ 🏆 Achievements │
│ │
│ Current Level: 12 │
│ │
│ [ Option A ] [ Option B ] │
│ │
├──────────────────────────────────────┤
│ Decisions │
│ │
│ ○ Use Option A │
│ ○ Use Option B │
└──────────────────────────────────────┘
視覚的プランニングにより、コンセプトのレビューがはるかに簡単になります。
また、よりインタラクティブなフィードバックが可能になります：
- 特定の領域に注釈を付ける
- 個々の要素にコメントする
- 選択肢を比較する
- 直接決定を下す
プランニングは、AIが生成した「テキストの壁」を単に読むことから、インタラクティブな設計プロセスへと変わります。
15. プランニングと実装を分離する
強力なエージェントワークフローでは、プロセスを明確なフェーズに分離できます：
プランニング (PLANNING)
│
▼
要件の明確化
│
▼
コンセプトのレビュー
│
▼
人間の決定
│
▼
実装 (IMPLEMENTATION)
│
▼
検証 (VALIDATION)
人間は初期段階により多くの時間を費やし、以下を確認すべきです：
「私たちは正しいものを作っているか？」
要件が明確になれば、エージェントは実装の大部分を独立して処理できます。
16. 最大の問題：コードレビューがボトルネックになる
AIは人間がレビューするよりもはるかに速くコードを生成できます。
このワークフローを考えてみてください：
エージェントがコードを書く
↓
人間が差分（Diff）をレビューする
↓
エージェントが問題を修正する
↓
人間が再度レビューする
↓
...
やがて、人間がボトルネックになります。
1日に数十回の変更を生成できるかもしれませんが、無制限の数の差分を手動でレビューすることはできません。
したがって、エージェントエンジニアリングをスケールアップさせたい場合は、開発者の役割を再考する必要があります。
17. 開発者はAIのエンジニアリングマネージャーになる
すべてのコード行を手動でチェックする代わりに、開発者は以下に焦点を当てるべきです：
- 要件
- アーキテクチャ
- 品質基準
- リスク
- 製品の振る舞い
- 最終決定
エージェントは以下についてより大きな責任を負うことができます：
- 実装
- テスト
- ドキュメンテーション
- 検証
- プルリクエストの準備
概念的には：
人間 (HUMAN)
船長 (Captain)
│
┌─────────┴─────────┐
│ │
方向性 (Direction) 品質 (Quality)
│ │
└─────────┬─────────┘
│
AIエージェント (AI AGENTS)
│
┌───────────┼───────────┐
│ │ │
コーディング テスト ドキュメント
開発者がいなくなるわけではありません。
役割が**「すべてのタスクを実行する」ことから、「それらのタスクを実行するシステムを管理する」**ことに変わるのです。
18. パイプラインで検証を自動化する
エージェントが実装を終えたら、差分をすぐにレビューするのではなく、変更を自動化された検証パイプラインに通すことができます。
完全なパイプラインには以下が含まれる可能性があります：
- ブランチを作成する。
- 変更をコミットする。
- 隔離されたWorktreeで検証を実行する。
- 元の意図を理解する。
- 最新のmainブランチに対してリベースする。
- マージコンフリクトを解決する。
- 敵対的レビュー（Adversarial review）を実行する。
- 明らかな問題を自動的に修正する。
- エンドツーエンド（E2E）テストを実行する。
- 証拠（エビデンス）を収集する。
- 関連するドキュメントを更新する。
- リンクの問題を確認する。
- ブランチをプッシュする。
- プルリクエストを作成する。
- CIとマージコンフリクトを監視する。
特に価値のある部分の1つは**証拠（エビデンス）**です。
単に：
「テストに合格しました。」
と言う代わりに、パイプラインは次のような証拠を提供できます：
- スクリーンショット
- ビデオ
- ログ
- テスト結果
これにより、開発者は実装が実際に機能していることを直接的に確認する方法を得ることができます。
19. リスクベースのレビューを活用する
すべての変更が同じ量の人間による注意を必要とするわけではありません。
有用なアプローチは以下の通りです：
低リスク (Low Risk)
↓
自動検証
↓
最小限の人間によるレビュー
一方で：
高リスク (High Risk)
↓
自動検証
↓
詳細な人間によるレビュー
たとえば、以下に影響を与える変更は、小さなUIの調整よりもはるかに多くの人間による精査を必要とする場合があります：
- 認証
- 支払い
- データベース
- セキュリティ
- コアなビジネスロジック
これにより、開発者は人間の判断が最も価値を提供する場所に時間を費やすことができます。
20. 長時間稼働するエージェント：寝ている間にAIを働かせる
次のステップは、エージェントがはるかに長期間機能できるようにすることです。
次のようにする代わりに：
タスク
↓
エージェント
↓
完了
ループを構築できます：
目的 (Objective)
↓
エージェント
↓
結果の確認
↓
次の改善点の発見
↓
実装
↓
テスト
↓
繰り返し
↓
停止条件 (Stop Condition)
これは、**検証可能（verifiable）**な目的に対して特によく機能します。
例：
- ページのロード時間を短縮する
- エンドツーエンド（E2E）テストのカバレッジを増やす
- ユーザビリティの問題を見つける
- 異なる仮説を実験する
- 測定可能な指標を改善する
21. エージェントにタスクだけでなく「目的」を与える
これはプロンプティングにおける重要な変化を表しています。
「このボタンを修正して。」
という代わりに、次のような目的をエージェントに与えることができます：
「新規ユーザーとしてアプリケーションを使用し、混乱したり次に何をすべきか分からなくなったりする最初のユーザビリティの問題を見つけてください。問題を見つけたら、それを修正し、修正をテストし、次の問題を探し続けてください。」
これで、エージェントは単一のタスクを実行するだけではなくなります。
停止条件付きの目的を追求しているのです。
これは長時間稼働するエージェントワークフローの基盤の1つです。
22. 並行エージェント：1つのエージェントではもはや不十分
エージェントが長期間独立して機能できるようになれば、複数のエージェントを並行して実行し始めることができます。
例：
開発者 (Developer)
│
┌─────────────┼─────────────┐
│ │ │
エージェントA エージェントB エージェントC
│ │ │
機能 A バグ B 機能 C
しかし、新たな問題が発生します。
複数のエージェントが同じリポジトリを変更しようとする可能性があります。
同じディレクトリで直接作業すると、互いに干渉し合う可能性があります。
23. Git Worktrees：各エージェントを分離する
Git worktreesを使用すると、同じリポジトリに対して複数の作業ディレクトリを存在させることができます。
例：
project/
project-agent-a/
project-agent-b/
project-agent-c/
各エージェントは自身のWorktreeで作業できます。
これにより、複数のセッションが互いの作業ディレクトリに直接干渉することなく、並行して動作できるようになります。
しかし、Worktreeは別の問題を引き起こします：
**認知的負荷（Cognitive overhead）**です。
開発者は以下のことを覚えておく必要が出てきます：
- どのWorktreeが使われているか
- どのエージェントが実行中か
- どのWorktreeが終了したか
- どのWorktreeが待機状態か
- どのブランチがどのタスクに属しているか
24. Worktreeの管理を自動化する
自動化レイヤーがこの問題を解決できます。
手動でWorktreeを作成・削除する代わりに、Worktreeマネージャーが以下を行うことができます：
- 必要な時にWorktreeを作成する
- そのステータスを追跡する
- どれがアクティブかを表示する
- 待機状態のWorktreeを検出する
- 既存のWorktreeを再利用する
開発者は単に次のようにリクエストするだけです：
「新しいワークスペースをちょうだい。」
システムが基盤となるGit操作を処理します。
25. エージェントが増えすぎたら、一等航海士 (First Mate) が必要になる
これは次のレベルにつながります。
最初は：
人間 → エージェント
次に：
人間 → エージェント A
→ エージェント B
→ エージェント C
しかし、エージェントの数が増えるにつれて、開発者は絶えず以下のことを行わなければならなくなります：
- セッションの切り替え
- コンテキストの記憶
- 進捗の監視
- Worktreeの作成
- 検証の確認
- プルリクエストの管理
- タスクの割り当て
再び開発者がボトルネックになります。
ここでオーケストレーションが重要になります。
26. 一等航海士：他のエージェントを管理するエージェント
一等航海士（First Mate）は、AIエンジニアリングマネージャーと考えることができます。
すべてのエージェントと直接話す代わりに、開発者は一等航海士とコミュニケーションをとります。
概念的には：
船長 (Captain)
│
▼
一等航海士 (First Mate)
│
┌───────────┼───────────┐
▼ ▼ ▼
エージェントA エージェントB エージェントC
│ │ │
Worktree Worktree Worktree
│ │ │
└───────────┼───────────┘
▼
検証 (Validation)
│
▼
PR (プルリク)
一等航海士は以下を行うことができます：
- リクエストの分析
- 並行して実行できるタスクの特定
- Worktreeの作成
- エージェントの起動
- 進捗の監視
- 検証の実行
- プルリクエストの準備
- 複数のタスクの調整
開発者は方向性を提供します。
一等航海士がオーケストレーションの大部分を処理します。
27. タスク管理から目的管理へ
一等航海士が効果的に機能するようになると、開発者はもはや技術的な手順を1つ1つ管理する必要がなくなります。
次のように指示する代わりに：
ターミナルを開く → Worktreeを作成する → エージェントを起動する → テストを実行する → 検証する → PRを作成する...
開発者は次のように言うことができます：
「これらの3つの問題を処理し、レビュー用のプルリクエストを準備して。」
オーケストレーションレイヤーが基盤となるワークフローを処理します。
これは次のような進化を表しています：
ツール利用 (Tool Usage)
↓
エージェント管理 (Agent Management)
↓
エージェント・オーケストレーション (Agent Orchestration)
28. 開発者の役割の変化
AIがより多くの実装作業を処理できるようになるにつれて、ボトルネックは移動します。
最初は：
開発者
↓
コードを書く
次に：
開発者
↓
コードをレビューする
その後：
開発者
↓
PRをレビューする
そして最終的には：
開発者
↓
方向性を定義する
↓
品質の基準を定義する
↓
ユーザーを理解する
↓
市場を理解する
↓
製品の意思決定を行う
これが、エージェントエンジニアリングがもたらす最大のパラダイムシフトの1つです。
29. 船長には宝の地図が必要
エージェントと一等航海士が実装作業のほとんどを処理するようになると、開発者は最終的に割り当てるタスクが尽きてしまうかもしれません。
これは実は重要なシグナルです。
それは、ボトルネックが実装から移動したことを意味します。
開発者は今、以下のことにより多くの時間を費やす必要があります：
- ユーザーの理解
- 実際の問題の特定
- 市場の調査
- 競合他社の分析
- 製品の方向性の定義
- ロードマップの構築
- 機会の特定
言い換えれば：
「AIがより速く構築できるようになると、何を構築すべきかを知ることがさらに重要になる。」
30. エージェントエンジニアリングの完全なワークフロー
全体のワークフローは6つのレベルに要約できます：
レベル 1
船を造る
ターミナル + Tmux + エディタ
↓
レベル 2
乗組員を募集する
メモリ + スキル
↓
レベル 3
1つのエージェントと働く
音声 + ツール + プランニング
↓
レベル 4
品質をスケールさせる
自動検証 + E2E + 証拠
↓
レベル 5
複数のエージェントを実行する
Worktrees + 並行タスク
↓
レベル 6
一等航海士を募集する
エージェント・オーケストレーション
↓
船長 (CAPTAIN)
製品の方向性 + 品質 + 戦略
31. 最も重要な原則
全体のワークフローをいくつかのコアな原則に絞り込むと、以下のようになります：
1. モデルだけでなく、ワークフローを最適化する
強力なモデルは重要ですが、メモリ、ツール、スキル、テスト、オーケストレーションも生産性に同様の大きな影響を与えます。
2. メモリを小さく保つ
多くのリクエストにわたって純粋に役立つ情報のみを、グローバルメモリおよびプロジェクトメモリに入れます。
3. 条件付きの知識をスキルに移動する
情報が特定のタスクにのみ必要な場合は、すべてのリクエストでコンテキストを消費する必要はありません。
4. 実装する前に計画する
エージェントに大量のコードを書かせる前に、要件を明確にする時間をとってください。
5. 人間をボトルネックにしない
AIが非常に速くコードを生成できる場合、すべての行を手動でレビューすることは、最終的にシステム全体を制限することになります。
6. 検証を自動化する
エージェントは、人間の手に渡す前に自分自身の作業をテスト、レビュー、および検証すべきです。
7. 並行エージェントを分離する
複数のエージェントが同時に作業する場合は、Worktreeなどの分離形式を使用します。
8. エージェントに目的を与える
明確な目的と停止条件により、エージェントは絶え間ない人間の介入なしに、はるかに長く作業することができます。
9. チームの成長に合わせてオーケストレーションを追加する
多数のエージェントを持つようになったら、すべてのセッションを手動で管理することは非効率的になります。
10. 方向性に焦点を当てる
実装が主要なボトルネックではなくなったとき、開発者はユーザー、製品、市場、そして優先順位の理解により多くの時間を費やすべきです。
結論
エージェントエンジニアリングは、単にAIを使ってより速くコードを書くことではありません。
それは、AIエージェントが以下のことができる新しいエンジニアリングワークフローを設計することです：
- プロジェクトのコンテキストを理解する
- 過去のミスから学ぶ
- 専門的なスキルを使用する
- 効率的なツールと対話する
- 作業を計画する
- 機能を実装する
- 変更をテストする
- 結果を検証する
- 長期間働く
- 並行して動作する
- そして最終的に他のエージェントと連携する
依然として人間が最も重要な役割を果たします。
しかし、その役割は変化します。
コードを最も速く書く人になろうとする代わりに、開発者はますます方向性を設定し、品質を定義し、何を構築する価値があるかを決定することに長ける必要があります。
システムを船として考えてください：
開発者は船長（Captain）です。
一等航海士（First Mate）は運用を調整します。
AIエージェントは乗組員（Crew）です。
メモリとスキルは乗組員の知識です。
ツールは装備です。
自動検証は品質管理システムです。
そして、製品の方向性（Product Direction）は宝の地図です。
これらすべてのピースが連携して機能するとき、AIは単なるコーディングアシスタントであることをやめます。
それは継続的かつ並行して働くことができるエンジニアリングチームとなり、人間は人間の判断を必要とする意思決定に集中し続けることができます。
それこそが、エージェントエンジニアリングの真の約束です。