agent-patterns

エージェントパターンのオーケストレーションスキル

このスキルは、Anthropic のエンジニアリングガイド「Building Effective Agents」にある AI エージェントのパターンとワークフローを実装します。モジュール式のリソースを使用して、ニーズに合ったパターンの選択、設計、実装を支援します。

クイックリファレンス：どのパターンが必要ですか？

タスクの特徴	最適なパターン	読み込むリソース
固定された順次ステップで、それぞれに異なる処理が必要	プロンプトチェーン	core-patterns.md
入力が明確なカテゴリに分類される	ルーティング	core-patterns.md
独立したタスクを並列実行する	並列化（分割）	core-patterns.md
堅牢性／合意形成のために同じタスクを複数回実行する	並列化（投票）	core-patterns.md
予測できないサブタスクを実行時に特定する	オーケストレーター・ワーカー	dynamic-orchestration.md
制約のない探索が必要	自律型エージェント	dynamic-orchestration.md
品質を反復的に向上させる必要がある	評価者・オプティマイザー	iterative-refinement.md
複数のパターンを組み合わせる必要がある	判断表を参照	pattern-combinations.md
特定の言語で実装する	言語を選択	language-implementation.md
ツールの設計／最適化	インターフェース設計	tool-design.md

パターンカテゴリの索引

コアパターン（決定的なワークフロー）

使用する場面： ワークフローが事前に完全に決まっている

パターン：

1. プロンプトチェーン - チェックポイントを設けた順次の LLM 呼び出し
2. ルーティング - 分類し、専門のハンドラーに振り分ける
3. 並列化 - 並行実行（分割または投票）

リソース： resources/core-patterns.md（350 行以上）

• パターンとアーキテクチャの完全な説明
• 使用する場面／使用しない場面
• 実例
• 各パターンのコードスケルトン

動的オーケストレーションパターン（予測不能なワークフロー）

使用する場面： ワークフローを事前に決められない

パターン：

1. オーケストレーター・ワーカー - 中央の LLM がタスクを分解し、ワーカーが実行する
2. 自律型エージェント - ツールを使った制約のない探索

リソース： resources/dynamic-orchestration.md（400 行以上）

• パターンと要件の詳細な説明
• 各アプローチを使用する場面
• エージェントの重要な要件
• 包括的な実装例

反復的な改善

使用する場面： フィードバックを通じて出力品質を改善する必要がある

パターン：

1. 評価者・オプティマイザー - 生成器と評価器によるフィードバックループ

リソース： resources/iterative-refinement.md（350 行以上）

• パターンの実装戦略
• 評価基準の設計
• 停止条件
• コストと品質のトレードオフ

応用：パターンの組み合わせ

使用する場面： 複雑な問題に対して複数のパターンを組み合わせる

例：

• ルーティング＋プロンプトチェーン（ルートごとに異なるチェーン）
• オーケストレーター＋評価者・オプティマイザー（分解してから改善）
• 複雑さによるルーティング（適切なパターンに振り分ける）
• 並列オーケストレーター（複数の視点）

リソース： resources/pattern-combinations.md（400 行以上）

• 7 つの主要な組み合わせパターン
• 判断フレームワークと判断ツリー
• コストと複雑さのトレードオフ
• テスト戦略

ツールの設計と実装

使用する場面： エージェントが使用するツールを設計する

トピック：

• ポカヨケ（エラー防止）設計
• 自然なフォーマットの選択
• パラメーター設計パターン
• よくある落とし穴

リソース： resources/tool-design.md（560 行以上、包括的なリファレンス）

• 基本原則とベストプラクティス
• SWE-bench から得られた実践的な知見
• 言語固有の考慮事項
• ツールインターフェースのテスト

言語固有の実装

使用する場面： 選択した言語でパターンを実装する

言語：

• TypeScript/JavaScript
• Python
• Rust
• C#/.NET
• Go
• Dart

リソース： resources/language-implementation.md（450 行以上）

• 各言語の完全なコード例
• 言語ごとの長所と短所
• ベストプラクティスと慣用表現
• 並行処理モデル

オーケストレーションプロトコル

フェーズ 1：タスクを特定する

次の点を確認してください。

1. ワークフローは事前に決まっていますか？

• はい → コアパターンを使用します（フェーズ 2A）
• いいえ → 動的パターンを使用します（フェーズ 2B）

2. 出力品質の反復的な改善は重要ですか？

• はい → 評価器・最適化器の追加を検討します
• いいえ → そのまま実行に進みます

3. 複数のパターンが必要ですか？

• はい → パターンの組み合わせを確認します
• いいえ → 単一のパターンで十分です

フェーズ 2A：コアパターンを選択する（事前に決まったワークフロー）

判断：逐次処理ですか、並列処理ですか？

逐次処理（固定された手順を順番に実行）：

• 各ステップが前のステップに依存する → プロンプトチェーン
• 例：概要作成 → 執筆 → 校正

分類（入力カテゴリーに応じて処理を決定）：

• 入力を分類できる → ルーティング
• 例：カスタマーサービスのチケット（返金／技術的な問題／苦情）

並列処理（独立したサブタスク）：

• サブタスクが互いに独立している → 並列化（分割）
• 例：コードのセキュリティとパフォーマンスを同時に評価する

並列処理（同じタスクを複数回実行）：

• 合意形成や堅牢性が必要 → 並列化（投票）
• 例：複数の専門家によるセキュリティレビュー

→ 実装については resources/core-patterns.md を読み込みます

フェーズ 2B：動的パターンを選択する（予測できないワークフロー）

判断：サブタスクの数を予測できますか？

予測可能なサブタスク：

• 何をする必要があるかは分かっていても、方法は分からない → オーケストレーター・ワーカー
• 例：コードレビュー（分析、生成、テスト、文書化が必要）
• 例：調査タスク（検索、分析、統合が必要）

あらゆることが予測不能：

• オープンエンドな探索 → 自律エージェント
• 例：GitHub の Issue を解決する（手順がまったく予測できない）
• 例：コンピューター操作タスク（さまざまな判断や進め方が可能）

→ 実装については resources/dynamic-orchestration.md を読み込みます

フェーズ 3：品質と改善を検討する

次の場合は評価器・最適化器を追加します：

• 明確な評価基準がある
• 反復によって品質が向上する
• 初回の出力によく修正可能な問題がある
• 速度より品質が重要である

組み合わせ可能なパターン：

• コアパターン + 評価器（出力を改善）
• オーケストレーター + 評価器（各コンポーネントを改善）
• ルーティング + 評価器（異なる改善方法へルーティング）

→ 実装については resources/iterative-refinement.md を読み込みます

フェーズ 4：複雑なパターンに対応する

複数のパターンを組み合わせる場合：

• pattern-combinations.md の判断フレームワークに従います
• シンプルに始め、段階的に複雑さを加えます
• 各段階でコストを監視します
• エッジケースを十分にテストします

フェーズ 5：使用する言語で実装する

言語を選択して例を読み込みます：

• resources/language-implementation.md を読み込みます
• 使用する言語のセクションを探します
• 使用例をユースケースに合わせて調整します
• インターフェースのベストプラクティスについては tool-design.md を参照します

---

パターン選択のヒューリスティック

問題の構造別

明確に定義された固定ワークフロー → コアパターン

• プロンプトチェーンまたはルーティングを使用します
• コスト：単一の呼び出しの 1～3 倍
• リスク：低

柔軟なワークフローで、分解方法が既知 → オーケストレーター・ワーカー

• 中央のプランナーが動的にタスクを分解します
• コスト：単一の呼び出しの 3～10 倍
• リスク：中

オープンエンドな探索 → 自律エージェント

• エージェントが手順を段階的に決定します
• コスト：単一の呼び出しの 10～100 倍
• リスク：高（サンドボックス化が必要）

品質の反復的な改善が重要 → 評価器・最適化器

• 上記のいずれのパターンにも追加できます
• コスト：反復回数に応じて倍増
• 効果：品質が 5～15％向上

複数の視点が有用 → パターンの組み合わせ

• パターンを戦略的に組み合わせます
• コスト：組み合わせによって異なります
• 効果：堅牢性と網羅性

分野別

カスタマーサービス → ルーティング（複雑なケースではオーケストレーター・ワーカーを追加） コンテンツ生成 → プロンプトチェーン（評価器・最適化器を追加） コード変更 → オーケストレーター・ワーカー（分解、並列化） 調査 → オーケストレーター・ワーカー（評価器・最適化器を追加） 問題解決 → 自律エージェント（または複雑さに応じたルーティング） 設計 → 並列オーケストレーター（複数の視点）

---

使用ワークフロー

ワークフロー 1：どのパターンを使えばよいかわからない場合

1. 問題やユースケースを説明してください
2. 以下について確認の質問をします：
   • ワークフローの予測可能性
   • 入力の変動性
   • 品質とコストのトレードオフ
   • 複雑さに関する制約
3. 適切なパターンを提案します
4. 詳しく確認するリソースを選んでください

ワークフロー 2：パターンはわかっていて、実装が必要な場合

1. 以下をお知らせください：
   • 必要な具体的なパターン
   • プログラミング言語
   • 制約や要件
2. 以下を生成します：
   • 本番環境で利用できるコード
   • エラー処理とベストプラクティス
   • 使用例
   • テストに関する推奨事項

ワークフロー 3：複数のパターンを組み合わせる必要がある場合

1. 要件を説明してください
2. pattern-combinations.md を参照します
3. 組み合わせをどのようにオーケストレーションするか説明します
4. 統合した実装を提供します

ワークフロー 4：ツールインターフェースの設計が必要な場合

1. ツールの目的を説明してください
2. tool-design.md のベストプラクティスに照らして確認します
3. ポカヨケの原則に基づいて改善案を提案します
4. 改良したツールスキーマを提供します

---

リソースのナビゲーションガイド

目的	参照するファイル	所要時間
基本パターンを理解する	core-patterns.md	15 分
動的オーケストレーションを学ぶ	dynamic-orchestration.md	20 分
反復的な改良を理解する	iterative-refinement.md	15 分
ツールインターフェースを設計する	tool-design.md	20 分
複数のパターンを組み合わせる	pattern-combinations.md	20 分
特定の言語で実装する	language-implementation.md	20～30 分
すべてのパターンをすばやく確認する	この SKILL.md を読む	10 分

---

コア原則（すべてのパターンに適用）

1. シンプルに始める – 要件を満たす最もシンプルなパターンを使用します
2. 複雑さを測定する – 複雑さを追加するのは、明確な効果が実証された場合に限ります
3. まずツールを設計する – プロンプトエンジニアリングよりも、ツールの品質に投資します
4. 透明性を確保する – デバッグできるよう、計画と判断を明らかにします
5. 厳密にテストする – 本番環境のエージェントでは特に重要です

---

検証チェックリスト

選択したパターンを実装する前に確認してください：

設計フェーズ：

• ワークフローの複雑さが要件によって正当化されている
• パターンの選択が問題に適している
• コストへの影響を理解し、許容できる
• 成功指標が定義されている

実装フェーズ：

• 各ステップでエラー処理を行っている
• ツールインターフェースがポカヨケの原則に従っている
• 停止条件が定義されている（特にエージェントの場合）
• モニタリングとログ記録の計画がある
• 外部コンテンツ／取得したコンテンツを区切って、信頼できないデータとして扱う（W011 プロンプトインジェクション対策）
• 取得したコンテンツ内の指示に従わないよう、システムプロンプトでモデルに明示的に指示している

テストフェーズ：

• 正常系を徹底的にテストしている
• エッジケースを特定し、対処している
• コスト追跡を実装している
• 本番環境への対応状況を確認している

---

主要ファイルの一覧

ファイル	目的	行数	読むタイミング
SKILL.md（このファイル）	オーケストレーションのハブと判断ガイド	280	最初（概要の確認）
resources/augmented-llm.md	基礎となる構成要素	300+	どのパターンを使う場合も事前に
resources/core-patterns.md	Prompt Chaining、Routing、Parallelization	350+	基本パターンが必要な場合
resources/dynamic-orchestration.md	Orchestrator-Workers、Autonomous Agents	400+	動的なパターンが必要な場合
resources/iterative-refinement.md	Evaluator-Optimizer パターン	350+	品質の反復的な改善が必要な場合
resources/tool-design.md	ツールインターフェースの設計と最適化	560+	ツールを設計する場合
resources/pattern-combinations.md	複雑な複数パターンのワークフロー	400+	パターンを組み合わせる場合
resources/language-implementation.md	言語別のコード例	450+	実装が必要な場合
resources/patterns-reference.md	元の包括的なリファレンス	500+	詳細を確認する場合

---

例

例1：カスタマーサポートシステム

ユースケース： サポートチケットを適切な担当者に振り分けます

解決策：

1. カテゴリ別に振り分けます（ルーティングパターン）
2. 種類ごとに異なるハンドラーを使用します：
   • 一般 → FAQ の検索（プロンプトチェーン）
   • 返金 → ポリシーの確認と回答の生成（プロンプトチェーン）
   • 技術的な問題 → 診断 → 解決策の検索 → 回答（オーケストレーター・ワーカー）

読み込むリソース：

1. 最初に：core-patterns.md（ルーティング）
2. 次に：pattern-combinations.md（ルーティングとチェーンの組み合わせ）
3. 最後に：language-implementation.md（使用する言語）

例2：高品質なコンテンツの生成

ユースケース： 厳格な品質基準を満たすマーケティングコピー

解決策：

1. 生成器がコンテンツを作成します（シンプルな LLM 呼び出し）
2. 評価器が基準に照らして確認します
3. 基準を満たさない場合：生成器がフィードバックに基づいて改善します
4. 基準を満たすまで繰り返します

読み込むリソース：

1. 最初に：iterative-refinement.md（評価器と最適化器）
2. 次に：language-implementation.md（使用する言語）

例3：複雑なコード変更

ユースケース： 複数ファイルにわたるコード変更に対応します

解決策：

1. オーケストレーターが要件を分析します
2. ワーカーが作業を次のように分割します：コードベースの分析 → コードの生成 → テストの作成 → ドキュメント化
3. すべてのワーカーを並列で実行します
4. オーケストレーターが一貫性のある変更セットにまとめます
5. 評価器が機能を検証します

読み込むリソース：

1. 最初に：dynamic-orchestration.md（オーケストレーター・ワーカー）
2. 次に：pattern-combinations.md（オーケストレーターと評価の組み合わせ）
3. その次に：tool-design.md（コード変更用ツールの設計）
4. 最後に：language-implementation.md（使用する言語）

---

次のステップ

1. タスクの種類を特定する → 上のクイックリファレンステーブルを使用します
2. 適切なリソースを読み込む → 該当するガイドを読みます（15～30分）
3. 実装言語を選択する → 言語別の例を読み込みます
4. シンプルなバージョンから始める → 必要な場合にのみ複雑さを加えます
5. 反復してテストする → 品質とコストを継続的に測定します

---

バージョン履歴

• 2.0 - 焦点を絞ったリソースファイルを使用するモジュール式オーケストレーションパターンにリファクタリング
• 1.0 - すべてのパターンを1つのドキュメントにまとめた、当初のモノリシックなスキル