agency-agents徹底解説：Markdownで“専門家チーム”を呼び出すAIエージェント集の正体と使い方
- agency-agentsは、多数の「専門家AIエージェント定義」をMarkdownファイルとして配布するOSSです（いわゆる“プロンプト集”の上位版）。
- 目的は、AIに毎回ゼロから役割を説明する手間を減らし、成果物の品質・手順・判断基準を“再現可能な形”で固定することです。
- Claude Codeのサブエージェント、CursorやCopilot系のエージェント機能、Gemini CLIなど、複数の環境に「定義ファイルを置いて呼び出す」発想で使えます。
- 便利になるのは、深掘り観点の抜け漏れ防止、チームの作法統一、レビュー観点の固定、役割分担（設計→実装→テスト→ドキュメント）をAI側で回しやすくなる点です。
agency-agentsとは何なのか？
agency-agents（The Agency / Agency Agentsと呼ばれることもあります）は、**“専門分野ごとに作り込まれたAIエージェント人格（役割・口調・思考手順・成果物・評価基準）を、Markdownファイルとしてまとめたリポジトリ”**です。最大の特徴は、単なる「あなたは◯◯の専門家です」といった短いロール指定ではなく、次の要素が最初から構造化されている点にあります。
- そのエージェントの使命（何を達成する役か）
- 判断基準（何を優先し、何を避けるか）
- 仕事の進め方（調査→設計→実装→検証などの手順）
- 具体的な成果物（コード、テスト、チェックリスト、仕様、レビューコメントなど）
- 成功指標（何ができたら合格か）
公式の説明でも、各エージェントは「専門性」「個性（スタイル）」「成果物へのフォーカス」「プロダクション利用を意識したワークフロー」を備える、とされています。これは“汎用プロンプト”よりも、手順と品質の型を強く持つ設計だと捉えると分かりやすいです。
さらに、コミュニティ記事では「144個のエージェント定義をMarkdownで提供し、複数ツールに対応」として紹介されており、ツール横断で同じ“専門家の型”を再利用する思想が広がっています。
「普通のプロンプト」と何が違うの？
agency-agentsが刺さりやすいのは、次の“現場あるある”をまとめて解決しやすいからです。
1) 抜け漏れが減る（観点のテンプレが埋め込まれている）
たとえばフロントエンド開発だと、見た目が動いた時点で「はい終わり」に見えがちですが、実務ではCore Web Vitals、アクセシビリティ、状態管理、エラーハンドリング、i18n、計測、E2Eなど観点が多いですよね。汎用プロンプトだと、AIの“その場の想起”に頼るので、抜け漏れが起きます。agency-agentsは、各領域のチェック観点が最初から含まれていることが多く、思考の土台を固定できます。
2) 再現性が上がる（人による指示の差が縮む）
「AIへの指示が上手い人だけ成果が出る」状態は、チームでは辛いです。エージェント定義を共有資産にすると、最低限の品質の型がそろいやすく、レビュー基準も揃えやすくなります。
3) “成果物の形式”が安定する（レビューしやすい）
「コードだけ貼られても困る」「影響範囲が分からない」「テスト観点がない」みたいな問題が減ります。エージェント側が“成果物として出すもの”を決めているからです。
どう使うのか？基本の考え方
agency-agentsの使い方はとてもシンプルで、発想としては次の2段です。
- エージェント定義（Markdown）を、自分が使うAIツールが参照できる場所に置く
- 作業中に「この役割で動いて」と呼び出し、成果物を出させる
「インストール」といっても、ライブラリを組み込むというより、定義ファイルの配置が中心です。実際、Claude Code向けにはユーザーディレクトリの所定フォルダへコピーしてサブエージェントとして使う手順が、コミュニティで広く共有されています。
以下は、代表的な利用パターンを“ツール別”に整理します（細部はツールの更新で変わるため、概念として押さえるのがおすすめです）。
Claude Codeでの使い方（サブエージェントとして呼ぶ）
Claude Codeはサブエージェント（役割を切り替えて並走させる）運用と相性が良く、agency-agentsはそこにピタッとはまります。典型的な運用は次の通りです。
- リポジトリに対して、エージェント定義を読み込ませる
- たとえば「Frontend Developer」「Backend Developer」「QA Engineer」「Tech Writer」などを、必要に応じて呼ぶ
- それぞれが「自分の成果物」を返し、人間は統合する
サンプル：1つの機能を“役割分担”で仕上げる
あなたがやりたいことが「ログインの二要素認証を追加」だとします。ここでの理想は、AIが一気に全部書くことではなく、段階ごとに品質を固めることです。
- Product/PM系エージェント
- 受け入れ条件（失敗パターン含む）
- 画面遷移
- セキュリティ要件（リカバリ、ロックアウト）
- Backend Developerエージェント
- API設計（エンドポイント、エラーコード、レート制限）
- DB設計（トークンの寿命、無効化）
- 監査ログの方針
- Frontend Developerエージェント
- UI実装（状態、ローディング、エラー表示）
- アクセシビリティ（フォーカス、読み上げ）
- 既存フォームとの整合
- QA Engineerエージェント
- テスト観点（ユニット、統合、E2E）
- 異常系（タイムアウト、再送、端末変更）
- 回帰リスク
- Tech Writerエージェント
- 設定方法
- トラブルシュート
- 運用手順
こうして“専門家の型”で返させると、人間側の作業は「統合と意思決定」に寄りやすくなります。
Cursor / Copilot / Gemini CLIなどでの使い方（エージェント定義を“指示資産”として使う）
CursorやCopilot系、Gemini CLIのような環境では、ツールごとにエージェントの仕組みが微妙に違いますが、agency-agentsは次の2方式で活きます。
方式A：ツールの“エージェント機能”に登録して、名前で呼ぶ
ツールが「カスタムエージェント」や「サブエージェント」をサポートしている場合、定義ファイルを所定の場所に置くことで、一覧から呼び出せるようになります。コミュニティ記事でも、複数ツールに対応することが言及されています。
方式B：定義Markdownを“参照ドキュメント”として貼り、役割を固定する
ツール側の登録機能が弱い場合でも、定義Markdownをプロンプトに貼り込み、作業の冒頭で「この定義に従って振る舞って」と固定するだけで効果が出ます。長文を扱えるモデルが増えたことで、こうした“役割ドキュメント運用”が現実的になりました。
何が便利になるのか？効くポイントを現場目線で
ここからは、agency-agentsを入れることで実務がどう変わるかを、もう少し具体的に説明します。
1) 仕様の曖昧さが減る（AIが“質問すべきこと”を知っている）
良いエージェント定義は、作業開始前に「不足情報の確認」を組み込んでいます。たとえばQAエージェントなら、テスト環境、対象ブラウザ、データ規模、既存のCIなどを聞きにきます。これが、後半の手戻りを大きく減らします。
2) レビュー観点が固定される（“何を見るか”が同じになる）
チーム開発で辛いのは、レビューが属人化して「人によって指摘が違う」ことです。agency-agentsのような定義をベースにすると、たとえば「セキュリティ観点」「パフォーマンス観点」「アクセシビリティ観点」が毎回同じ粒度で出やすくなります。結果として、PRの品質が安定します。
3) “人間が考えるべきところ”が浮き彫りになる
エージェントに任せると、逆に人間の仕事が明確になります。たとえば次の部分です。
- 方針の決定（トレードオフ、優先順位）
- リスクの受容（何を捨てるか）
- プロダクト判断（UX、法務、ブランド）
- 最終承認（リリース可否）
AIが得意な「作業」を押し出すほど、人間が担う「決断」が見えるようになります。
4) 分業が“非同期”で回る（小さな会社でもチームっぽくなる）
一人開発でも「PM→設計→実装→QA→ドキュメント」を一人で頭の中で切り替えるのは大変です。agency-agentsは、その切り替えを“人格と手順”で補助してくれます。小規模でも、チームっぽい進め方がしやすくなります。
5) オンボーディングが楽になる（新人に“型”を渡せる）
新しく入った人に、「うちのプロジェクトはこう考える」を口頭で伝えるのは難しいですよね。エージェント定義＋自社ルール（命名、例外、ログ、監視、PRルール）を組み合わせると、AIが新人の補助輪として動きやすくなります。
具体的な使い方の型：失敗しにくい3ステップ
agency-agentsは便利ですが、使い方を誤ると「それっぽい資料だけ増える」こともあります。おすすめは、次の順番です。
ステップ1：目的と受け入れ条件を先に固定する
エージェントに丸投げする前に、あなたが決めるのはこれだけで十分です。
- 目的：何を達成したいか
- 範囲：どこを変更してよいか（ファイル/モジュール/機能）
- 受け入れ条件：テスト、互換性、性能、UXの最低条件
ここが曖昧だと、エージェントは“賢く迷子”になります。
ステップ2：役割を2〜3つだけ使って、小さく回す
最初から10人分のエージェントを呼ぶと、統合が大変です。おすすめは、
- 実装担当（Frontend/Backendどちらか）
- QA担当
- Tech Writer（必要なら）
この3つで、まず1機能を完成させることです。
ステップ3：成果物のフォーマットを固定する
たとえば、エージェントには毎回これを出させます。
- 変更の要約（3行）
- 影響範囲（箇条書き）
- リスクと対策（箇条書き）
- 追加/更新したテスト（一覧）
- ロールバック手順（必要なら）
これだけで、レビューがとても楽になります。
実践サンプル：エージェント定義を“自社仕様”に寄せる
agency-agentsはそのままでも便利ですが、真価は「自社の作法」を混ぜたときに出ます。たとえば、次のような“追記ルール”を別ファイルで用意し、どのエージェントにも前提として読ませます。
サンプル：自社共通ルール（例）
- 例外：APIはエラーコードとメッセージを必ず返す
- ログ：個人情報はマスクし、相関IDを必須にする
- テスト：新規機能は必ずユニットテスト＋統合テストのどちらかを追加
- パフォーマンス：一覧APIはN+1禁止、SQLの説明（EXPLAIN）を残す
- UI：フォームはキーボード操作とフォーカス遷移を確認
- ドキュメント：READMEに実行手順を追記
この「共通ルール」と、agency-agentsの「専門家の型」を組み合わせると、AIが“あなたの会社の専門家”に近づきます。
注意点：便利だけれど、万能ではありません
最後に、安心して使うための注意点もまとめます。
1) エージェント定義は“正しさ”を保証しない
定義が良くても、モデルが誤った前提を置いたり、コードが動かなかったりは普通に起きます。必ず、テスト・Lint・型チェック・レビューで受け入れ条件を満たす形に収束させてください。
2) 情報の持ち出しと権限設計
エージェントに何を読ませるかは、情報管理そのものです。機密情報、個人情報、顧客データ、鍵、社内限定仕様は、渡し方とログの残し方を決めてから運用するのが安全です。
3) “成果物の山”を作らない
エージェントが出すドキュメントが増えすぎると、人間が読めなくなります。成果物は「レビューと運用に必要な最小限」に絞り、必要があればテンプレを削ってください。
まとめ：agency-agentsは、AIを“チームの型”として使うための仕組み
agency-agentsは、AIモデルそのものではなく、**AIがどう考え、どう進め、何を成果物として出すかを固定するための“役割資産”**です。
だからこそ便利になるのは、単なる自動化ではなく、次のような“開発の質”の部分です。
- 抜け漏れが減り、観点が揃う
- 仕様→実装→検証→ドキュメントがつながる
- レビューしやすい成果物が出る
- 一人でもチームのように分業できる
- 新人や非エンジニアも同じ型で進めやすい
もしあなたが「AIに頼むと浅い」「毎回指示がぶれる」「レビューが大変」と感じているなら、agency-agentsはかなり相性が良いはずです。まずは、あなたの現場で一番頻度が高い作業（例：小さな機能追加、バグ修正、テスト追加）を1つ選び、2〜3役だけで回してみてください。そこから、自社ルールを少しずつ混ぜていくと、使い心地が安定していきますよ。