Googleが5つのエージェントSkill設計パターンを公開しました。
これはGoogleのエンジニアがSkill開発エコシステム全体を研究し、そこから抽出した5つの黄金律です。
本記事は原文の翻訳と整理を忠実に行ったものです。開発者の皆さん、ぜひ学んでください。
𝚂𝙺𝙸𝙻𝙻.𝚖𝚍に言及すると、開発者は往々にしてフォーマットに注目しがちです。YAML形式が正しいか、ディレクトリ構造を構築し、仕様に従っているかどうかに焦点を当てます。
しかし、Claude Code、Gemini CLI、Cursorなど、30を超えるエージェントツールが同一のレイアウトで標準化されるにつれ、フォーマットの問題は実質的に解決されました。
現在の課題はコンテンツの設計にあります。
仕様はSkillのパッケージ化方法を説明していますが、その内部ロジックの構築方法については一切のガイダンスを提供していません。
例えば、FastAPIの規約をカプセル化したSkillと、4つのステップを持つドキュメント処理パイプラインは、𝚂𝙺𝙸𝙻𝙻.𝚖𝚍ファイルの外見は全く同じに見えますが、動作方法は全く異なります。
エコシステム全体（AnthropicのコードベースからVercelやGoogleの内部ガイドラインまで）でこれらのSkillがどのように構築されているかを研究することで、開発者がより良いエージェントを構築するのに役立つ5つの反復的な設計パターンを発見しました。
各パターンには、実行可能なADK（Agent Development Kit）コードが付属しています：
ツールラッパー（Tool Wrapper）：エージェントを瞬時にあらゆるコードベースのエキスパートにする
ジェネレーター（Generator）：再利用可能なテンプレートから構造化ドキュメントを生成する
レビュアー（Reviewer）：重大度に基づいてチェックリストに対してコードを評価する
インバージョン（Inversion）：エージェントが操作を実行する前にユーザーにインタビューを行う
パイプライン（Pipeline）：チェックポイントを持つ厳格なマルチステップワークフローを強制実行する
パターン1：ツールラッパー（The Tool Wrapper）
ツールラッパーは、特定のコードベースに関するオンデマンドのコンテキストをエージェントに提供します。
API規約をシステムプロンプトにハードコードする代わりに、それらをSkillとしてパッケージ化します。エージェントは、その技術を実際に使用する場合にのみ、このコンテキストをロードします。
これは最も実装が簡単なパターンです。𝚂𝙺𝙸𝙻𝙻.𝚖𝚍ファイルはユーザープロンプト内の特定のコードベースのキーワードを監視し、𝚛𝚎𝚏𝚎𝚛𝚎𝚗𝚌𝚎𝚜/ディレクトリから内部ドキュメントを動的にロードし、それらのルールを絶対的な真理として適用します。
これは、チームの内部コーディングガイドラインや特定のフレームワークのベストプラクティスを開発者のワークフローに直接配信するために使用されるメカニズムです。
以下は、エージェントにFastAPIコードの書き方を教えるツールラッパーの例です。指示には、エージェントがコードのレビューや作成を開始する場合にのみ𝚌𝚘𝚗𝚟𝚎𝚗𝚝𝚒𝚘𝚗𝚜.𝚖𝚍ファイルをロードするよう明確に記載されていることに注意してください：
パターン2：ジェネレーター（The Generator）
ツールラッパーは知識の適用に焦点を当てていますが、ジェネレーターは一貫した出力を強制するために使用されます。
エージェントが実行するたびに異なるドキュメント構造を生成することに悩んでいる場合、ジェネレーターは綿密に計画された「穴埋め」プロセスを通じてこの問題を解決できます。
これは2つのオプションディレクトリを利用します：𝚊𝚜𝚜𝚎𝚝𝚜/は出力テンプレート用、𝚛𝚎𝚏𝚎𝚛𝚎𝚗𝚌𝚎𝚜/はスタイルガイド用です。
指示はここでプロジェクトマネージャーの役割を果たします。エージェントにテンプレートをロードし、スタイルガイドを読み、不足している変数をユーザーに尋ね、ドキュメントを埋めるよう指示します。
これは予測可能なAPIドキュメントの生成、標準化されたコミットメッセージ、またはプロジェクト構成に非常に役立ちます。
この技術レポートジェネレーターの例では、Skillファイル自体には実際のレイアウトや構文ルールは含まれていません。これらのアセットの取得を調整し、エージェントにそれらを段階的に実行させるだけです：
パターン3：レビュアー（The Reviewer）
レビュアーパターンは、「何をチェックするか」と「どのようにチェックするか」を分離します。
各コードスメル（code smell）を詳細に説明する冗長なシステムプロンプトを書く代わりに、モジュール式の評価基準を𝚛𝚎𝚟𝚒𝚎𝚠-𝚌𝚑𝚎𝚌𝚔𝚕𝚒𝚜𝚝.𝚖𝚍ファイルに保存します。
ユーザーがコードを送信すると、エージェントはこのチェックリストをロードし、提出内容を体系的に評価し、発見事項を重大度別にグループ化します。
PythonコードスタイルチェックリストをOWASPセキュリティチェックリストに置き換えると、全く同じSkillインフラストラクチャを使用して、全く異なり高度に専門化された監査プロセスを得ることができます。
これは、PRコードレビューを自動化したり、人間がコードを見る前に脆弱性を捕捉するのに非常に効果的な方法です。
以下のコードレビュアーSkillは、この分離メカニズムを示しています。指示は静的なままですが、エージェントは外部チェックリストから特定のレビュー基準を動的にロードし、重大度に基づいた構造化された結果を強制的に出力します：
パターン4：インバージョン（Inversion）
エージェントは、しばしば直感的にすぐに推測して結果を生成しようとします。
インバージョンパターンは、この動的なロジックを逆転させます。ユーザーがプロンプトを駆動し、エージェントが実行するのではなく、エージェントが面接官（インタビュアー）の役割を果たします。
インバージョンパターンは、明確で妥協のないゲート指令（例：「すべての段階が完了するまで、構築を開始してはならない」）に依存して、エージェントにまずコンテキストを収集させることを強制します。
構造化された質問を順番に提示し、次の段階に進む前に回答を待ちます。
ニーズとデプロイメントの制約を完全に把握するまで、エージェントは最終的な出力結果の合成を拒否します。
実際の効果を理解するには、以下のプロジェクトプランナーSkillを見てください。ここでの重要な要素は、厳格な段階分けと明確なゲートプロンプトであり、すべてのユーザー回答が収集される前にエージェントが最終計画を合成するのを防ぎます：
パターン5：パイプライン（The Pipeline）
複雑なタスクでは、ステップを見落としたしたり、指示を無視した場合の結果に耐えることはできません。
パイプラインパターンは、ハードチェックポイントを持つ、厳格に順序付けされたワークフローを強制実行します。
指示自体がワークフローの定義となります。明確なダイヤモンドゲート条件（例：ドキュメント文字列の生成から最終組み立て段階に進む前にユーザーの承認を必要とする）を実装することで、パイプラインはエージェントが複雑なタスクをバイパスして十分に検証されていない最終結果を直接出力することを防ぎます。
このパターンは、すべてのオプションディレクトリを利用し、必要な特定のステップでのみ対応する参照ファイルとテンプレートを抽出することで、コンテキストウィンドウをきれいに保ちます。
このドキュメント処理パイプラインの例では、明確なゲート条件に注意してください。ユーザーが前のステップで生成されたドキュメント文字列を確認しない限り、エージェントが組み立て段階に入ることを明確に禁止しています：
各パターンは異なる問題を解決します。以下のデシジョンツリーを使用して、ユースケースに適したパターンを見つけてください：
これらのパターンは相互排他的ではありません。組み合わせることができます。
パイプライン（Pipeline）Skillの最後にレビュアー（Reviewer）ステップを含めて、自身の作業を再確認させることができます。
ジェネレーター（Generator）は、最初にインバージョン（Inversion）パターンを使用して必要な変数を収集し、その後テンプレートを埋めることができます。
ADKの𝚂𝚔𝚒𝚕𝚕𝚃𝚘𝚘𝚕𝚜𝚎𝚝とプログレッシブディスクロージャー（progressive disclosure）メカニズムのおかげで、エージェントは実行時に実際に必要な特定のパターンに対してのみコンテキストトークンを消費します。
複雑で脆弱な指示をすべて単一のシステムプロンプトに詰め込もうとするのはやめましょう。
ワークフローを分割し、適切な構造の設計パターンを適用し、信頼性の高いエージェントを構築してください。
Agent Skills仕様はオープンソースであり、ADKエコシステム全体でネイティブにサポートされています。
フォーマットのパッケージ化方法はすでに学びました。今、そのコンテンツの設計方法も習得しました。さあ、Google Agent Development Kitを使用して、よりスマートなエージェントを構築しましょう。
参考資料：