Akira

Posted on Sep 1 Originally published at apidog.com

300以上のAIスペシャリストをClaude CodeとCursorにインストールする方法

agency-agentsを実務で使う：AIエージェントの専門化と限界

要するに： agency-agentsは、2026年9月1日時点でGitHubスター数149,312を獲得している、AIエージェント用ペルソナの最大級の厳選コレクションです。約20のカテゴリに300以上のエージェント定義ファイルを収録し、Claude Code、Cursor、Codex、Gemini CLI、OpenCode、Windsurf、Aiderなどへワンコマンドでインストールできます。ただし、これはフレームワークではなく能力そのものでもありません。ペルソナは作業方法を変えますが、モデルにない事実を与えず、セッションをまたいで永続化することもありません。

今すぐApidogを試す

本記事は、2026年にインストールする価値のある5つのオープンソースAIエージェントツールの中から、agency-agentsを掘り下げたものです。

多くのコーディングエージェントは、「役立つジェネラリスト」という一つの個性しか持ちません。認証フローのレビューを依頼すると、一般的で忘れやすいアドバイスが返ってきます。一方、脅威モデルとチェックリストを備えたセキュリティレビューアに依頼すれば、より具体的な調査結果を得られます。

agency-agentsは、この差を埋めるペルソナライブラリです。エージェント専門化に関するRedditのスレッドから始まり、現在では非常に大規模な名簿に成長しました。本記事では、収録内容、必要な部分だけを安全にインストールする方法、そしてペルソナライブラリだけでは解決できない2つの限界を説明します。

実際にインストールするもの

各エージェントはMarkdownファイルです。1行のシステムプロンプトでも、コード付きプラグインでもありません。主に次の内容で構成されています。

アイデンティティとパーソナリティ
核となるミッション
作業プロセス
具体的な成果物の形式
成功指標

2026年9月1日時点でリポジトリツリー内のMarkdownファイルを数えると、20のトップレベルカテゴリに312個あります。examples/を除くと306個です。構築系のカテゴリに多く分布しています。

部門	エージェントファイル
エンジニアリング	59
専門	58
マーケティング	36
ゲーム開発	21
統合	18
戦略	16
GIS	13
セキュリティ	12
デザイン	10
営業	9
テスト	9
有料メディア	7
プロジェクト管理	7
学術	6
空間コンピューティング	6
サポート	6
金融	5
製品	5
ヘルスケア	3

READMEには現在も「230以上のエージェント」とありますが、これは古い記述です。実際のツリーは300を超えています。

多くの開発者はエンジニアリング部門から始めるでしょう。内容は一般的なプロンプト集より具体的です。フロントエンド開発者やバックエンドアーキテクトだけでなく、次のようなペルソナもあります。

Cisco IOS-XE、Juniper Junos、Palo Alto PAN-OSに特化したネットワークエンジニア
ESP32、STM32、Nordic向けの組み込みファームウェアエンジニア
事後分析とオンコール体制を担当するインシデント対応指揮官
リポジトリを読み取り専用で調査し、提案ではなく事実を報告するコードベースオンボーディングエンジニア

特に最後の例は、この方式の価値をよく示しています。編集禁止を明示した読み取り専用ペルソナは、デフォルトのエージェントとは異なるツールになります。しかも必要なのは1つのファイルだけです。

セットアップを壊さずにインストールする

まずはリポジトリを取得してインストーラーを実行します。

git clone https://github.com/msitarzewski/agency-agents.git
cd agency-agents
./scripts/install.sh

ただし、最初から全ペルソナを入れるより、ツールと部門を絞る方が安全です。

# すべてをClaude Codeへ
./scripts/install.sh --tool claude-code

# 2つの部門のみ
./scripts/install.sh --tool claude-code --division engineering,security

# 指定されたエージェントのみ
./scripts/install.sh --tool cursor --agent frontend-developer,ui-designer

# コミットする前に何が存在するか確認
./scripts/install.sh --list teams
./scripts/install.sh --tool opencode --division engineering --dry-run

サポートされているターゲットには、Claude Code、Cursor、Codex、Gemini CLI、OpenCode、GitHub Copilot、Windsurf、Aider、Kimi Code、Hermes、Antigravity、Osaurus、Mistral Vibeがあります。

また、macOS、Linux、Windows向けに、名簿の閲覧、クリック操作でのインストール、自動更新に対応したネイティブデスクトップアプリ（agencyagents.app）と、Homebrew caskも提供されています。

OpenCodeでは全件インストールしない

すべてをインストールする前に注意してください。 OpenCodeのランタイムは現在、約119個のエージェントしか登録できず、残りをサイレントに破棄します。この問題はリポジトリでもアップストリームのバグとして記録されています。

--divisionでサブセットを選べば制限内に収まり、選択数が上限を超えそうな場合はインストーラーが警告します。必要なエージェントが失われても通知されない、というのが最悪の障害モードです。

OpenCode以外でも、300個のペルソナを入れるのはおすすめしません。覚えられない名簿は、使われない名簿です。まず普段働く2つの部門を選び、4〜5個のファイルを読み、チームの実態に合わないものを削除してください。

ペルソナが変えるもの、変えないもの

ペルソナは、エージェントの「フレーム」を設定します。

何を確認するか
どの形式で出力するか
何を完了とみなすか

これは想像以上に有効です。悪い出力の多くは、モデルの能力不足ではなく、誤った回答形式に最適化されていることが原因だからです。

一方、ペルソナはモデルにない情報を追加できません。特にAPI作業で、この限界がはっきり現れます。

バックエンドアーキテクトをロードし、社内請求サービス用のクライアントを作成させてみてください。レスポンス形式を推測し、きれいで慣用的なコードを生成するでしょう。しかし、次のようなサービス固有の仕様は知りません。

冪等キーが重複したとき、異なるエラーエンベロープで409を返す
ページネーションカーソルがオフセットではなく不透明な値である

ペルソナはコードを整理しますが、コードを正しくするとは限りません。

同じ問題はテストにもあります。QAペルソナは、APIについて自分が持つメンタルモデルに対しては徹底的なテストを作れます。そのテストが通っても、実際のAPIを証明しているとは限りません。詳しくは非決定性AIエージェントのテストと、API変更がAIエージェントを壊すときに何が起こるかを参照してください。

ペルソナではなくコントラクトを与える

解決策は、ペルソナが仕様を補完することを期待するのではなく、エージェントに実際のコントラクトを与えることです。

APIをApidogで設計している場合、OpenAPI仕様を真の情報源にできます。エージェントはコールサイトから推測するのではなく、次の情報を仕様から読み取ります。

実際のスキーマ
実際のステータスコード
実際のエラーエンベロープ

同じ仕様からモックも生成できるため、ペルソナが想像しにくいエラーブランチもテストできます。実装と仕様が乖離すれば、CIでテストスイートが失敗します。

この組み合わせを、次のように考えると分かりやすくなります。

ペルソナはエージェントの動作方法を決め、仕様は何が真実かを決める。

関連資料として、OpenAPI仕様をエージェントツールとして使用すると、エージェント向けのAPIツールスキーマ設計も参考になります。ライブ仕様をエージェントのコンテキストに組み込みたい場合は、Apidogをダウンロードして既存のプロジェクトに接続してください。

2番目の限界：ペルソナはチームではない

agency-agentsは「完全なエージェンシー」を想像させますが、実際には1セッションにつき1つのペルソナを有効化してタスクを実行する仕組みです。翌日には、再びペルソナを有効化する必要があります。

次のようなチーム機能はありません。

タスクの割り当て
前回のセキュリティレビュー結果の記録
他のメンバーが結果を確認する仕組み

リポジトリの部門は組織内の役割を表しますが、ペルソナをインストールするツールには組織の概念がありません。

名簿を単一のターミナルセッションを超えて維持したいなら、必要なのはワークマネジメント層です。Sharklyはそのために作られており、agency-agentsとの対応関係も明確です。

エージェントは保存された設定である Sharklyのエージェントは再入力するプロンプトではありません。指示、ランタイム、スキル、リポジトリ、環境を保持します。一度調整したペルソナを再利用でき、~/.claude/agents/内の.mdファイルが目指している永続版に相当します。
クルーがチームを構成する クルーはリーダーエージェント、他のエージェント、人で構成されます。リーダーがタスクのコンテキストを読み、必要なメンバーを招集し、結果を一か所にまとめます。各スペシャリストが同時に開始して競合する方式ではありません。
作業は割り当てる エージェントには、チームメイトと同じようにタスクを割り当てます。作業はスペース、プロジェクト、スプリント内に記録され、必要に応じてJiraとも同期できます。
実行環境は自分で用意する ラップトップ、サーバー、コンテナなどを接続すると、Sharklyはそこにインストール済みのランタイムを使用します。作業を行うのは自分のClaude CodeまたはCodexのサブスクリプションであり、トークンを転売する仕組みではありません。
出力をレビューできる 進捗、ツール呼び出し、結果はタスクにストリーミングされます。エージェントの出力は返信可能なコメントとして表示されます。バックログ内のタスクは実行を開始しないため、実行前に準備できます。

つまり、agency-agentsは職務記述を提供し、Sharklyは仕事を割り当て、実行し、レビューする場所を提供します。agency-agentsを「インストールして忘れるフォルダ」ではなく、エージェントの役割定義を育てるライブラリとして使うのが効果的です。

既存のペルソナをテンプレートにする

このリポジトリで最も長く使える資産は、ファイルの形式です。数個のファイルを読めば、自分の技術スタックに合わせたペルソナを約15分で作れます。特定の環境に合わせたペルソナは、一般的なものより有用です。

優れたファイルには、次の構造があります。

アイデンティティと声：誰で、どのように話すか
核となるミッション：成功の定義を1文で示す
作業プロセス：エージェントが従う順序付きの手順
成果物：具体的な出力形式
成功指標：完了を判断する基準

API作業用なら、たとえば次のように書けます。

# API Contract Reviewer

## Mission
Verify that new or changed endpoints match the OpenAPI spec in this
repository before they reach review. Report mismatches. Do not edit code.

## Process
1. Read the spec for every endpoint touched by the current diff.
2. For each one, compare the handler against the spec: status codes,
   response schema, error envelope, required headers, pagination style.
3. Run the contract tests. Record failures verbatim.
4. Check that new endpoints were added to the spec, not just to the router.
5. Flag any response field present in code and absent from the spec.

## Deliverables
A table: endpoint, method, mismatch type, spec line, code line, severity.
No prose summary. No suggested fixes unless asked.

## Done when
Every endpoint in the diff appears in the table with a verdict, and the
contract test output is included as evidence.

これは、リポジトリにある59個のエンジニアリングペルソナのどれよりも、バックエンドチームに貢献する可能性があります。自分の仕様、テスト、完了条件が明記されているからです。

特に重要なのは、ペルソナに意見ではなく証拠を生成させることです。これが、行動につながるレビューと、安心させるだけの文章を分けます。

同じ方法は、インシデント対応、移行、依存関係のアップグレード、オンボーディングにも適用できます。ファイル構造を使い、プロセス規律を保ち、一般的な内容を自分の環境向けに置き換えてください。人や別のエージェントに引き渡す必要があるなら、フォーマット契約が大部分の品質を決めます。詳しくはエージェントの引き渡しとコンテキストの受け渡しを参照してください。

スター数はどこまで意味があるか

149,312スターは非常に多い数字ですが、注意して解釈すべきです。ペルソナリポジトリは、理解しやすく共有しやすく、試すコストも低いため、他のカテゴリよりスターを集めやすい傾向があります。スターは「良いアイデアだと思われた」ことを示しますが、「現在も使われている」ことまでは示しません。

agency-agentsを評価するときに重要なのは、スター数よりも作業の形です。

2025年10月以降の実績あるコントリビューション履歴
MITライセンス
OpenCodeの登録上限を含む制約の文書化
一般的な役割名だけでなく、具体的なドメイン知識を含むエージェントファイル

よく使う部門から3つのファイルを開いて判断してください。フロントエンド開発者のファイルに、優秀なフロントエンド開発者が実際に言いそうな内容があれば、他のファイルも期待できます。求人広告のように読めるなら、採用しない方がよいでしょう。

実際に価値を引き出すワークフロー

1つの部門をインストールする 日常業務に合う部門を選びます。多くの読者にはエンジニアリングが適しています。
ファイルを読む 4〜5個を最初から最後まで読み、再利用したいプロセスを探します。
編集する 自分のスタック、規約、完了条件を追加します。一般的なReactショップの説明より、実際のテストルールが入ったペルソナの方が有用です。
実際の入力を与える OpenAPI仕様を持つセキュリティレビューアは、具体的なコントラクト問題を発見できます。仕様がなければ、単なるチェックリストを作るだけです。
定着したペルソナを昇格させる 週2回使うペルソナは、マシン間でコピーするファイルではなく、ワークマネジメントシステムに保存したエージェントにします。

この最後のステップが、チームでスケールするか、静かに使われなくなるかの分岐点です。

よくある質問

agency-agentsはCursorやCodexでも動作しますか？

はい。convert.shはツールごとの統合ファイルを生成し、install.sh --toolで特定のツールを対象にできます。Claude Code、Cursor、Codex、Gemini CLI、OpenCode、Copilot、Windsurf、Aider、Kimi Codeなどをサポートしています。

API作業用のエージェントクライアントを比較する場合は、CursorとCopilotにおけるAPIクライアントの考察も参照してください。

300個すべてのエージェントをインストールすべきですか？

いいえ。OpenCodeではランタイムが約119個しか登録せず、残りをサイレントに破棄します。他のツールでは技術的に可能でも、ほとんど使わないでしょう。部門単位でインストールしてください。

ペルソナはエージェントを賢くしますか？

エージェントの方向性は改善しますが、事実に関する精度は変わりません。APIが何を返すかを正しく判断するには、実際の仕様が必要です。この点については、AIエージェントの時代にAPIツールはまだ必要かで詳しく説明しています。

インストールスクリプトを実行しても安全ですか？

スクリプトは、エージェント定義ファイルを各ツールの設定ディレクトリに書き込みます。それが目的です。ソースはすべて公開され、MITライセンスで提供されています。実行前に--dry-runを使い、何が変更されるか確認してください。

エージェントに触れさせる対象を管理する一般的な原則については、AIエージェントのガードレールを参照してください。

エージェントフレームワークとは何が違いますか？

複数のペルソナを同時に実行したいなら、Orcaのような仕組みが必要です。StrandsやAgentKitは、コードからランタイムをオーケストレーションするフレームワークです。

agency-agentsが提供するのは、既存エージェントの動作を変えるMarkdownファイルです。両者は異なるレイヤーであり、競合しません。

まとめ

agency-agentsは、「エージェントが役割を理解しているほど、より良い仕事をする」という考え方を、実用的な形にしたものです。まず部門を選び、ファイルを読み、チームに合わせて編集してください。約20分のセットアップで、実際に使えるペルソナを作れます。

ただし、2つの限界は明確です。

ペルソナは、APIが何を返すかを知りません。これはApidogの役割です。
ペルソナは、チームが共有・レビューできる形で永続化しません。これはSharklyの役割です。

agency-agentsは優れた出発点ですが、組織そのものでも、真実の情報源でもありません。

DEV Community