「Agent Native」とは何か？
Every.toの創業者Dan ShipperとClaudeが共同で執筆した「Agent-Native Architectures」ガイドが公開され、AI開発者コミュニティで注目を集めている。
このガイドは、Claude Codeの成功に基づき、AIエージェントが自律的にタスクを完了できるアプリケーション設計の原則を体系化したものだ。従来の「AIを補助機能として追加する」発想から脱却し、エージェントをファーストクラスシチズン（一級市民）として設計するという新しいパラダイムを提示している。
Agent Native設計の5つの原則
ガイドでは、Agent Nativeなアプリケーションを構築するための5つのコア原則が定義されている。
原則1：パリティ（同等性）
「ユーザーがUIを通じてできることは、エージェントがツールを通じて達成できるべき」という基本思想。UIのあらゆるアクションについて、エージェントが同じ結果を得られるツールを提供する必要がある。
| ユーザー操作 | エージェントツール |
|---|---|
| ファイルを開く | read_file() |
| テキストを編集 | edit_file() |
| 検索する | search() |
| 設定を変更 | update_settings() |
原則2：粒度（Granularity）
ツールは原始的な構成要素であるべき。意思決定ロジックをツール内に埋め込まない。エージェントがループで判断し、プロンプトで記述された結果を追求する。
つまり、ツールは「何をするか」を実行するだけで、「いつ・なぜ使うか」はエージェントが判断する設計だ。
原則3：構成可能性（Composability）
原始的なツールとパリティがあれば、新しいプロンプトを書くだけで新機能を実装できる。
例えば「今週修正されたファイルをレビューし、主要な変更を要約する」というプロンプトだけで、以下の複雑なワークフローが実現する：
- Gitログから変更ファイルを特定
- 各ファイルの差分を読み込み
- 変更内容を分析・分類
- 要約レポートを生成
原則4：創発的能力（Emergent Capability）
「明示的に設計しなかったことを達成できる」能力。ユーザーが予期しない要求をエージェントが達成し、その過程で潜在需要が発見される。
これは従来のソフトウェア開発では実現不可能だった特性であり、Agent Nativeの最大の強みと言える。
原則5：継続的改善
コード変更なしに、コンテキストファイルとプロンプト調整によるアプリケーション改善が可能。開発者レベルとユーザーレベルの両方でカスタマイズできる。
ファイルを「ユニバーサルインターフェース」に
Agent Native設計で重要なのが、ファイルシステムをエージェントとの主要インターフェースとして活用することだ。
ファイルベースが優れている理由
| 特性 | 説明 |
|---|---|
| 既知の操作 | cat、grep、mvなどはエージェントが習熟済み |
| 検査可能性 | ユーザーが「ブラックボックス」なしに確認可能 |
| 可搬性 | エクスポート・バックアップが簡単 |
| 自己文書化 | ディレクトリ構造が意味を持つ |
推奨ディレクトリ構造
ガイドでは以下のような構造が推奨されている：
Documents/
├── AgentCheckpoints/ # 中断・再開用
├── AgentLogs/ # 実行ログ
└── Research/books/{bookId}/
├── full_text.txt # 元データ
├── notes.md # 生成されたメモ
└── agent_log.md # 処理履歴
Context.mdパターン
Agent Native設計のもう一つの重要な要素が、Context.mdパターンだ。
これはエージェントが各セッション開始時に読み込む「携帯可能な作業メモリ」として機能する。以下のようなセクションを含む：
- Who I Am：エージェントの役割定義
- What I Know About This User：ユーザーの好み・履歴
- What Exists：利用可能なリソース一覧
- Current State：進行中のタスク状態
Claude CodeのCLAUDE.mdも、このパターンの実装例と言える。
ドメインツールへの段階的進化
Agent Native設計では、ツールの進化にも明確な段階がある。
| 段階 | 内容 | 例 |
|---|---|---|
| 初期 | 純粋なプリミティブ | bash、ファイル操作 |
| 中期 | パターン出現時に追加 | ドメイン固有ツール |
| 後期 | パフォーマンス最適化 | 専用コード実装 |
重要なポイント：ドメインツールは「ショートカット」であり「ゲート」ではない。基盤となるプリミティブへのアクセスを常に保持し、構成可能性を維持する。
エージェント実行パターン
エージェントの実行制御についても、具体的なパターンが示されている。
完了シグナル
「完了」を明示的に示すべき。ヒューリスティック（推測的）検出は使わない：
- .success()：成功、ループ継続
- .error()：エラー、再試行継続
- .complete()：完了、ループ停止
部分的完了の追跡
マルチステップタスクの進捗を明確に追跡する：
✓ [1] Find sources ✓ [2] Download text ✗ [3] Generate summary - Error: context limit ○ [4] Create outline
コンテキスト制限への対応
エージェントはコンテキストウィンドウの制限を受ける。ガイドでは以下の対策を推奨：
- イテレーティブな洗練を支援するツール
- セッション中盤での学習の統合
- コンテキスト満杯時の「チェックポイント」設計
避けるべきアンチパターン
ガイドでは、Agent Native設計で避けるべきアンチパターンも明確に定義されている。
| アンチパターン | 問題点 |
|---|---|
| エージェント as ルーター | 知能をルーティングだけに使い、実行能力を活かせない |
| 後付けエージェント | 既存機能の上に乗せるだけで、真の統合ができない |
| リクエスト/レスポンス思考 | ループの力を活用できない |
| 防御的ツール設計 | 厳密なバリデーションでエージェントの柔軟性を制限 |
| ハッピーパスのみ | エッジケース処理を全部エージェント判断に丸投げ |
成功基準チェックリスト
最後に、ガイドではAgent Nativeアプリケーションの成功基準チェックリストが提供されている。
アーキテクチャ観点
- UIのあらゆる操作をエージェントが達成可能か？
- プロンプト編集でコード変更なしに動作変更できるか？
- 予期しないタスクをループで完成させられるか？
実装観点
- システムプロンプトに利用可能リソースが明記されているか？
- エージェントとユーザーが同じデータスペースで作業しているか？
- 全エンティティがCRUD操作可能か？
プロダクト観点
- 初心者は学習曲線なしで基本操作できるか？
- 上級ユーザーは予期しない方向に拡張できるか？
- ユーザーのリクエストパターンから学習できるか？
まとめ：Agent Native時代の設計思想
「Agent-Native Architectures」ガイドは、AIエージェント開発における設計パラダイムシフトを提示している。
記事のポイント
- 5つの原則：パリティ、粒度、構成可能性、創発的能力、継続的改善
- ファイルベース：ファイルシステムをユニバーサルインターフェースに
- Context.md：エージェントの携帯可能な作業メモリ
- 段階的進化：プリミティブから始め、必要に応じてドメインツールへ
- アンチパターン：後付けエージェント、防御的ツール設計を避ける
Claude Codeの成功は偶然ではない。この設計ガイドに示された原則を忠実に実装した結果だ。AIエージェントを活用したアプリケーションを開発する全ての開発者にとって、必読のドキュメントと言えるだろう。
コメント