Claude Codeサブエージェントにagency-agentsが選ばれる理由

Claude Code のサブエージェント機能を本格活用したい場面で、多くのエンジニアが最初にぶつかるのが「自作するか、既存コレクションを流用するか」という選択です。自作は柔軟性が高い一方で、専門領域ごとにプロンプトを設計・調整する手間が大きく、片手間ではなかなか完成度が上がりません。

その解決策として近年 GitHub 上で存在感を増しているのが、既存のサブエージェント集を丸ごと導入するアプローチです。なかでも 12 万を超えるスターを集めている msitarzewski/agency-agents は、232 体・16 部門というスケールで話題になっています。ただ、規模が大きいがゆえに「本当に自分の用途に合うのか」「他のコレクションとどう違うのか」を判断しにくいのも事実です。

とりわけ Claude Code を軸に AI コーディングツールを使い分けているエンジニアにとって、選択肢は agency-agents 一つではありません。プラグイン方式で軽量な wshobson/agents、Claude Code 特化で小回りが利く contains-studio/agents に加え、実行モードまで含めたオーケストレーション型プラグイン、ドメイン説明文からエージェント定義を自動生成するファクトリー型など、思想の異なる OSS がすでに複数存在します。

本記事では、msitarzewski/agency-agents の設計思想・部門構成・対応ツールを整理したうえで、代表的な類似リポジトリ2件との定量・定性比較と、構造の異なる OSS（オーケストレーション型・ファクトリー型）との位置関係もあわせて提示し、「どんなケースなら agency-agents を選ぶべきか」を判断するための材料をまとめます。動作検証は行わず、公式リポジトリ・公式サイト・公開ドキュメントの記載に基づく整理を目的とします。

agency-agentsとは何か

msitarzewski/agency-agents は、AI エージェントによる仮想エージェンシー（代理店）を1つのリポジトリに集約した OSS プロジェクトです。開発は継続中で、記事執筆時点（2026年7月）でアーカイブされておらず、他リポジトリのフォークでもない独立プロジェクトとして公開されています（msitarzewski/agency-agents）。

プロジェクト概要と主要指標

まずは判断の入り口として、リポジトリの規模と勢いを客観指標で押さえておきます。

スター数 12.6 万は OSS 全体でも上位に入る規模で、AI エージェント関連リポジトリのなかでも突出しています。直近プッシュも2026年7月と新しく、継続的にメンテナンスされている点は「導入後に放置されるリスクが低い」という判断材料になります。

ライセンスは MIT で、表示要件を満たせば商用利用・改変・再配布が可能です。会社のプロダクトに組み込む場合でも、ライセンス起因のブロッカーは基本的に発生しません。

「AI Agency」設計思想の4要素

README では、各エージェントが以下の4要素で設計されていると明示されています（README.md）。

• Specialized: 汎用プロンプトではなくドメインに特化した専門家として設計
• Personality-Driven: 独自の口調・コミュニケーションスタイルを持つ
• Deliverable-Focused: 抽象的なアドバイスではなくコード・プロセス・成果物にフォーカス
• Production-Ready: 実運用で使われたワークフローをベースにしている

「AI Agency（AI エージェンシー）」というネーミングが示す通り、単なるプロンプト集ではなく「一人ひとりに個性と持ち場を持たせた専門家チーム」として構成されている点が特徴です。汎用アシスタントとは異なる思想であり、後述する類似リポジトリとの差別化ポイントにもつながります。

生い立ちとコミュニティ

もともとは Reddit スレッドから始まったプロジェクトで、数ヶ月のイテレーションを経て現在の規模に発展したと README に記載されています。個人発のプロジェクトから始まり、コミュニティに揉まれて拡張された経緯は、GitHub 上で多くの支持を集める理由の1つです。

さらに、コミュニティ主導で 8 言語のローカライズ版が公開されており、日本語版として sscodeai/agency-agents-ja が存在します。日本語圏で利用する場合、UI 翻訳ではなくプロンプト自体の日本語化が用意されている点は判断材料になります。

16部門232体のエージェント構成

agency-agents 最大の特徴は、232 体という規模と、その内訳が「開発系のみに閉じていない」ことです。README では 16 部門に整理されており、開発系だけでなく業種横断・地域特化まで含みます（Agency Roster）。

開発系部門（コアな開発ワークフロー）

まず、多くのエンジニアが日常的に利用する開発ワークフローをカバーするのが以下の部門です。

• Engineering Division: フロントエンド・バックエンド・DevOps・データエンジニアリング等（34 体以上）
• Design Division: UI/UX・ブランドデザイン・ビジュアル設計
• Testing Division: テスト戦略・E2E・回帰テスト
• Security Division: セキュリティレビュー・脆弱性チェック
• Product Division: プロダクトマネジメント・要件整理
• Project Management Division: プロジェクトマネジメント・スケジューリング

コード生成・レビュー・リファクタリングに閉じず、プロダクト企画からセキュリティレビューまで、開発ライフサイクルを横断できる構成になっています。

ビジネス・専門職系部門（業種横断カバー）

agency-agents が他コレクションと大きく異なるのは、開発系以外の業種横断カバーです。

• Marketing Division: SNS・コンテンツマーケティング（微信・微博・小红书・Bilibili・Douyin など中国系プラットフォームを含む地域特化エージェント多数）
• Sales Division: 営業戦略・提案書作成
• Paid Media Division: 広告運用・PPC・クリエイティブ制作
• Finance Division: 財務分析・キャッシュフロー・資金調達
• Specialized Division: Business Strategist、CFO、Legal など業種特化エージェント多数
• Support Division: カスタマーサポート・エスカレーション設計

「開発だけでなくビジネスサイドの意思決定にも AI を活用したい」というニーズを持つチームには、他コレクションにない強みが提供されます。

特殊領域部門（一般コレクションでカバーされない領域）

さらに、開発系汎用コレクションではカバーされない特殊領域も含まれます。

• Game Development Division: エンジン別（Unity / Unreal / Godot / Blender / Roblox）に分岐した専門家群
• Spatial Computing Division: visionOS・XR・WebXR 向け
• GIS Division: 地理情報システム特化（13 体）
• Academic Division: Anthropologist・Historian・Narratologist などワールドビルディング系

ゲーム開発・GIS・アカデミック系のエージェントは、wshobson/agents や contains-studio/agents にはほぼ含まれない領域です。「業界特化のプロジェクトで AI を活用したいが、既存の汎用エージェント集ではカバーされない」というケースでは、agency-agents が最初の選択肢になり得ます。

対応ツールと導入手順

agency-agents の実務的な強みの1つが、対応ツールの広さです。README には 14 種類のツールに対する統合が記載されており、複数の AI コーディングツールを使い分けているチームでも、環境ごとに別コレクションを探す必要がありません。

対応する 14 ツール一覧

README に記載されている統合対象は以下の 14 種類です。

• Claude Code（native）
• GitHub Copilot（native）
• Antigravity（Gemini）
• Gemini CLI
• OpenCode
• Cursor
• Aider
• Windsurf
• OpenClaw
• Qwen Code
• Kimi Code
• Codex
• Osaurus
• Hermes

複数ツールにまたがる導入を検討する場合、各ツール向けの変換スクリプトが用意されているため、リポジトリ1つで環境を揃えられます。

導入手順の全体像

README では、変換とインストールの2ステップに整理されています。以下は README のインストール手順の抜粋です。

./scripts/convert.sh
./scripts/install.sh

（出典: msitarzewski/agency-agents README）

convert.sh で対象ツール向けにエージェント定義を変換し、install.sh で対話式にインストール先を選択します。並列実行オプション --parallel も用意されており、大量エージェントの変換時間を短縮できると README に記載されています。

Claude Code に特化した導入手順や補足情報は、Claude Code 統合 README にまとめられています。Claude Code のみを対象とする場合はこちらから確認するのが早道です。加えて、.claude/agents/ へのサブエージェント定義そのものやフロントマターの書き方、複数エージェントの並列発火といった Claude Code サブエージェントの一般的な扱いについては Claude Code SubAgentで並列処理を実装 に基礎から実装手順までまとめているため、agency-agents 側のインストール前に一読しておくと詰まりにくくなります。

デスクトップアプリ Agency Agents

CLI 経由の導入とは別に、macOS / Windows / Linux 対応のデスクトップアプリ「Agency Agents」も提供されています（agencyagents.app）。Tauri 2（Rust）と Svelte 5 で構築された別リポジトリのプロダクトで、以下の機能を備えると公式サイトで案内されています。

• エージェントカタログの GUI 閲覧
• インストール状態の追跡
• ドリフト検出（本家との差分検知）
• ダッシュボード表示
• プロジェクト単位のスコープ管理
• 自動更新

テレメトリなし・アカウント不要・ローカルファーストの設計となっており、CLI 操作を減らしたいユーザーや、複数プロジェクトでエージェント構成を切り替えたいケースで有用です。デスクトップアプリの対応ツールは執筆時点で 8 種（Claude Code / Codex / Gemini CLI / GitHub Copilot / Qwen Code / Cursor / opencode / Osaurus）と、CLI 経由よりも狭くなっている点は把握しておく必要があります。

部門単位インストールと OpenCode 119 制限

232 体すべてを一括投入する必要はなく、--division オプションで部門単位のインストールが可能である旨が README に記載されています。特に OpenCode には 119 体のエージェント上限があり、それを超えるとサイレントに切り捨てられるという実務上の注意点が明記されています。全部門を入れると 119 体を超えるため、OpenCode ユーザーは部門を絞る前提で運用する必要があります。

類似リポジトリ（wshobson/agents・contains-studio/agents）との違い

Claude Code サブエージェント集を選ぶうえで、比較対象になりやすい大規模コレクションが2件あります。それぞれ設計思想が異なるため、agency-agents との差分を押さえておくと選定が楽になります。加えて、同じ「Claude Code にエージェント群を導入する OSS」というくくりでは構造の異なる選択肢もあるため、そちらとの位置関係もあわせて整理します。

wshobson/agents との比較

wshobson/agents は、「Multi-harness agentic plugin marketplace for Claude Code, Codex CLI, Cursor, OpenCode, GitHub Copilot, and Gemini CLI」と自称するプラグインマーケットプレイスです。公式説明によると、88 プラグイン・194 agents・158 skills・106 commands で構成されており、agents 単体では agency-agents より若干少ないものの、skills / commands という別軸の資産を持ちます。

最大の違いは導入モデルです。wshobson/agents は Claude Code のプラグインコマンドを使い、必要なプラグイン単位でインストールするコンポーザブル設計を採用しています。トークン消費を抑えたい・軽量に保ちたいというニーズに向いています。

一方、agency-agents は「16 部門を1つのエージェンシーとして揃える」思想が強く、部門単位・一括インストールが主となります。「幅広い専門家を最初から揃えておき、必要な時に呼び出す」使い方が中心です。

contains-studio/agents との比較

contains-studio/agents は、Claude Code に特化した特殊化エージェントの包括的コレクションです。導入は ~/.claude/agents/ へ手動コピーし、Claude Code を再起動する形で、シンプルなワークフローが特徴です。

「Rapid development」向けにフォーカスされており、Engineering / Design / Marketing / Product などの部門構造は agency-agents と似ていますが、エージェント数は 8 部門合計 約 37 体（README の Complete Agent List 実測値）にとどまり、地域特化・GIS・ゲーム開発などの特殊領域はほぼ含まれません。マルチツール対応も弱く、基本的に Claude Code 単独運用が前提です。

「Claude Code 単独で、開発向けの少数精鋭コレクションを速く導入したい」というケースでは contains-studio/agents が有利です。一方、複数ツール・幅広い業種をカバーしたい場合は agency-agents に軍配が上がります。

定量比較表

3 コレクションを主要観点で並べると以下のようになります。

数字だけを見ると agency-agents が最大規模ですが、「大きい＝優れている」ではなく、それぞれ思想が異なるコレクションであることを踏まえて選ぶ必要があります。

オーケストレーション型・生成ファクトリー型 OSS との構造差

上記の2件はいずれも agency-agents と同じ「ペルソナ定義ファイルのカタログを配布する」タイプの OSS です。ただし Claude Code のサブエージェントを増やす OSS には、実行モードやモデルルーティングまで含めたオーケストレーション基盤として設計されたタイプ、ドメイン説明文からエージェント定義自体を自動生成するファクトリー型もあり、選択軸を整理しておくと agency-agents の位置づけがより鮮明になります。

• オーケストレーション型プラグイン: Claude Codeを19の専門エージェントに分割するoh-my-claudecode は、分析・QA・専門家の3カテゴリに整理された19の専門エージェントと、5つの実行モード・モデルルーティングをセットで提供します。エージェント同士の呼び出しや制御まで基盤側で担うため、少数精鋭のワークフローを最短距離で組みたいケースに向いています。agency-agents が「幅広いペルソナのカタログ」であるのに対し、oh-my-claudecode は「実行モードまで含めたオーケストレーションプラグイン」という点が構造上の大きな違いです
• 自動生成ファクトリー型: Claude Codeのエージェントチームを自動設計するOSS「Harness」 は、ドメイン説明文から .claude/agents/ と .claude/skills/ を自動生成するメタスキル型 OSS です。既製のカタログを流用するのではなく、自社ドメインに合わせてエージェント構成を都度作りたい場合の起点になります

整理すると、「実行制御まで揃った少数精鋭で始めたい」ならオーケストレーション型、「自社固有のエージェントをゼロから設計したい」ならファクトリー型、「既製の 232 体で幅広くカバーしたい」なら agency-agents、という3つの軸で使い分けるのが実務的です。

Claude Codeサブエージェントとしてagency-agentsを選ぶべきケース

3 コレクションの違いを踏まえ、agency-agents が向いているケースと、別選択肢を検討すべきケースを整理します。

agency-agents が向いているケース

以下のいずれかに当てはまるチーム・個人には、agency-agents が有力な選択肢になります。

• 複数の AI コーディングツールを併用している: Claude Code だけでなく Cursor・Codex・Gemini CLI・Copilot など複数ツールを行き来している場合、14 ツール対応の広さが利く
• 業種横断でエージェントを揃えたい: エンジニア以外にマーケティング・営業・法務・財務のワークフローも AI で回したい場合、開発系汎用コレクションでは不足する
• 地域特化コンテンツを扱う: 中国系 SNS（微信・微博・小红书 等）、韓国市場、フランス市場、日本市場向けのマーケティング施策を持つチームには、地域特化エージェントが揃っている点が強み
• ゲーム開発・GIS・XR など特殊領域を扱う: これらの領域は wshobson/agents・contains-studio/agents ではほぼカバーされないため、agency-agents が数少ない選択肢になる
• パーソナリティ強めのアウトプットを許容できる: 「Evidence Collector」など、独自の口調・スタンスを持ったエージェント設計を活かせる
• 日本語ローカライズ版を活用したい: sscodeai/agency-agents-ja により日本語プロンプトを利用できる

別の選択肢を検討したほうがよいケース

一方、以下のケースでは別コレクションのほうが適しています。

• トークン節約を最優先したい: 常時大量のエージェントを読み込むよりプラグイン単位で軽量に運用したい場合、wshobson/agents のコンポーザブル設計が有利
• Claude Code 単独で、少数精鋭を速く導入したい: 開発ワークフローに絞って最短距離で導入したい場合、contains-studio/agents の手動コピー方式のほうが素早い
• 実行モードやモデルルーティングも一体で欲しい: 呼び出し制御まで基盤側に持たせたい場合はオーケストレーション型プラグイン、自社固有のエージェント構成を自動生成したい場合はファクトリー型 OSS のほうが目的に合う
• 完全にカスタム定義したい: 自社ドメイン固有の要件・社内用語・独自ワークフローに完全適合させたい場合は、既存コレクションをベースにするよりも自作サブエージェントを組む選択肢が残る

実運用の注意点

導入を決めた場合でも、以下の点は押さえておく必要があります。

• パーソナリティ強めのスタイル: 各エージェントは口調・スタンスが濃く定義されているため、社内のトーン&マナーによっては違和感が出る場合がある。プロンプトの上書きや無効化を検討する余地がある
• OpenCode の 119 体上限: 前述の通り、OpenCode ユーザーは部門を絞る前提で運用する
• 232 体を全て使う必要はない: 一括インストールできるからといって全員を常時稼働させる必要はない。プロジェクト単位で必要なエージェントを選ぶ運用が現実的
• デスクトップアプリの対応ツールは 8 種: CLI 経由の 14 ツール対応と異なる点は事前確認が必要

agency-agents 導入前に押さえておくべきこと

意思決定の最後の詰めとして、法務・継続性・言語対応の観点を整理しておきます。

ライセンスと商用利用

agency-agents のライセンスは MIT で、GitHub リポジトリ の LICENSE ファイルで確認できます。表示要件（著作権表示とライセンス条文の同梱）を満たせば、商用利用・改変・再配布が可能です。社内システムやクライアント案件への組み込みでも、ライセンス起因のブロッカーは通常発生しません。

比較対象の wshobson/agents・contains-studio/agents もいずれも MIT ライセンスであるため、ライセンス面で agency-agents 特有の制約はありません。

メンテナンス状況

記事執筆時点でのメタデータでは、直近プッシュが 2026年7月1日、アーカイブ状態は非アーカイブ（archived=false）、フォーク元も存在しない独立リポジトリ（fork=false）です。スター数 12.6 万・フォーク数 2 万超という規模もあり、直近でメンテナンスが止まる兆候は現時点で見当たりません。

とはいえ OSS 全般に言えることですが、依存として組み込む場合は「フォークして自組織で管理する」「特定バージョンをピン留めして使う」といったフォールバックプランを用意しておくと安心です。デスクトップアプリの機能である「ドリフト検出」は、本家との差分を把握するうえで有用な仕組みと言えます。

日本語ローカライズ版と派生プロジェクト

日本語圏で利用する場合、コミュニティ翻訳版として sscodeai/agency-agents-ja が公開されています。README の Stats テーブル（2026年7月3日時点）によれば、合計 347 エージェント（上流由来 adapted 版 233 + 日本市場オリジナル 114）と 27 ワークフローで構成されており、単なる翻訳ではなく日本市場向けの独自エージェントが上乗せされている点が特徴です。

他にも中国語（zh-CN・2 リポジトリ）、ポルトガル語、ロシア語、インドネシア語、アラビア語、韓国語のコミュニティ翻訳が README にリストアップされており、多言語チームでの利用にも配慮された構成になっています。

以上を踏まえ、agency-agents は「複数ツール・広い専門領域・地域特化までカバーしたい」ケースに強く、「軽量なコンポーザブル運用が必要」なケースでは wshobson/agents、「Claude Code 単独で速く導入したい」ケースでは contains-studio/agents、「実行制御や自動生成まで含めた基盤が欲しい」ケースではオーケストレーション型・ファクトリー型 OSS が候補になります。自分のプロジェクトの目的・環境に照らして、この判断軸を出発点に選定を進めることをおすすめします。