--- title: "Agent Skill の五つの設計パターン（ADK）| TauX" description: "Tool Wrapper、Generator、Reviewer、Inversion、Pipeline。Google Cloud Tech が示した五つのパターンと、それぞれが実際に解いている問題。" url: "https://taux.io/ja-JP/adk-skill-patterns" locale: "ja-JP" alternates: en-US: "https://taux.io/en-US/adk-skill-patterns" ko-KR: "https://taux.io/ko-KR/adk-skill-patterns" zh-Hans-CN: "https://taux.io/zh-Hans-CN/adk-skill-patterns" zh-Hant-TW: "https://taux.io/zh-Hant-TW/adk-skill-patterns" --- # Five Skill Patterns — ADK を使うなら押さえておきたいこと Google Cloud の《5 Agent Skill Design Patterns Every ADK Developer Should Know》をもとに整理 ### なぜ設計パターンが要るのか `SKILL.md` の YAML さえ書ければよい、と思われがちですが、あれは器にすぎません。 難しいのは**中身の設計**です。手順を飛ばさせない、当て推量をさせない、毎回ばらばらの形で出させない——どうするか。 その答えが、この五つのパターンです。 01 ## 五つのパターン、ひと目で | # | パターン | ひとことで | 向いている場面 | | -- | ------------ | ------------------- | --------------------- | | 01 | Tool Wrapper | 必要になったときだけ専門知識を読み込む | 特定のフレームワークやライブラリへの対応 | | 02 | Generator | テンプレートで出力の形をそろえる | レポート、ドキュメント、API 仕様の生成 | | 03 | Reviewer | チェックリストで品質を見る | コードレビュー、セキュリティ監査 | | 04 | Inversion | 十分に聞いてから手を動かす | 要件がはっきりしない仕事 | | 05 | Pipeline | 段階を崩さないパイプライン | デプロイ、承認、込み入った業務フロー | 02 — Tool wrapper ## Tool Wrapper その場で専門家になる ### 困りごと フレームワークの資料（FastAPI の作法、React の規約、SQL のスタイル指針…）をぜんぶシステムプロンプトに詰め込むと、トークンは膨れ上がり、注意も散ります。 ### やり方 `SKILL.md` に「この語が出たら」という引き金を書いておきます。 利用者がそのフレームワークに触れたときだけ、`references/` から対応する作法を読み込みます。 SKILL.md → Tool Wrapper pattern ``` # 引き金 when: 利用者が "FastAPI" または "API endpoint" に触れたとき load: references/fastapi-conventions.md # エージェントの動き then: 読み込んだ作法にしたがって開発する トークンを使うのは、必要になったときだけ ``` 効くところ コンテキストを散らかさずに済みます。関係のあるときだけ専門知識を入れるので、無関係な情報に引っぱられません。 03 — Generator ## Generator テンプレートで形をそろえる ### 困りごと 自由に書かせると、レポートの形が毎回変わります。目次があったりなかったり、三段落だったり三十段落だったり。 ### やり方 あらかじめテンプレートを用意し（`assets/` に置きます）、ゼロから組み立てさせるのではなく、空欄を埋めさせます。 assets/report-template.md ``` # {{title}} ## Executive Summary {{summary: 要点を 2〜3 文で}} ## Key Findings {{findings: 箇条書きで 3〜5 項目}} ## Risk Assessment | リスク | 深刻度 | 打つ手 | |---|---|---| {{risks: 表に入れる}} ## Next Steps {{actions: 優先順に並べる}} ``` 効くところ 形と中身を切り離します。モデルは中身に集中し、形はテンプレートが保ちます。 04 — Reviewer ## Reviewer チェックリストで見る ### 困りごと 出てきたものは「合っているように見える」のに、穴があることがあります。端の条件、セキュリティの確認、チームの取り決めが抜けている。 ### やり方 別立てのレビュー用スキルを用意し、`references/` から専用のチェックリストを読み込みます。 一項目ずつ確かめさせ、深刻度で分けて報告させます。 Critical セキュリティの穴、情報の漏れ Warning 性能、手入れのしやすさ Info 書き方の提案、定石 効くところ つくる筋道と、見る筋道を分けます。一方が手を動かし、もう一方が検める——コードの PR レビューと同じ形です。 05 — Inversion ## Inversion 十分に聞いてから、動く ### 困りごと 「サイトをつくって」の一言で、いきなりコードを書き始める。出てきたものは求めていたものとかけ離れている。モデルはもともと、まず動こうとするからです。 ### やり方 **ふるまいを反転させます。**実行役ではなく、まず聞き手をやらせます。 飛ばせない関門（non-negotiable gates）を置き、必要な条件がそろうまで着手させません。 Inversion の流れ ``` ✕ ふつうのエージェント 利用者：「サイトをつくって」 Agent → いきなり React の作業を始める… ✓ Inversion の場合 利用者：「サイトをつくって」 Agent → Phase 1：聞き取り 「どういう種類のサイトですか」 「誰に向けたものですか」 「参考にしたい見た目はありますか」 → Phase 2：すり合わせ 「整理するとこうなります。これで合っていますか」 → Phase 3：着手 開発を始める ``` 効くところ 先に聞くことで、埋め合わせの作り話を減らせます。手元の情報がそろっているほど、出てくるものはよくなります。 06 — Pipeline ## Pipeline 段階を崩さないパイプライン ### 困りごと 手数の多い仕事では、段階を飛ばす、まとめてしまう、途中の肝心なところを忘れる——とくに扱う情報が長くなるとそうなります。 ### やり方 スキルを**崩せないパイプライン**として設計します。段階（phase）をはっきり決め、 その間に関門（gate）を置きます。いまの段階を終え、人の確認を得るまで次へ進めません。 Phase 1 Research → Gate → Phase 2 Plan → Gate → Phase 3 Execute → Done Verify 効くところ 読めない文章生成を、制御でき、繰り返せ、あとから追える状態機械に変えます。 07 ## 押さえどころ #### Progressive Disclosure（段階的に開く） ADK の SkillToolset は、必要になったときだけ指示と文脈を読み込ませます。トークンを節約し、焦点も保てます。 #### 形と中身を分ける `SKILL.md` は決まった器を用意し、これらのパターンが決めるのは「どう考え、どう動くか」という内側の筋道です。 #### 組み合わせて使う 混ぜて使えます。パイプラインの最後にレビューを置く。ジェネレータの前に Inversion を挟んで条件を集める。 08 ### あわせて読む [プロンプト設計ガイド →](https://taux.io/ja-JP/agent-prompting-guide) [Claude Skills 実践ガイド →](https://taux.io/ja-JP/claude-skills-guide) [GEO 入門ガイド →](https://taux.io/ja-JP/geo-guide)