agency-agents解説｜254体のAIエージェントをClaude Code・Cursorなど16ツールへ配る

AIコーディングツールに「専門家の人格」を持たせる運用が広がるにつれ、地味だが厄介な問題が表面化してきた。Claude Codeに書いたsubagentの定義は、そのままではCursorでもCodexでも動かない。ツールごとにファイル形式も置き場所も違うからだ。agency-agents（msitarzewski）は、この「同じ人格を使い回せない」という一点に、254体の定義と16ツール分の変換スクリプトで応えているOSSである。

GitHubスターは2026年7月25日時点で13.6万を超え、フォークは2.2万。ライセンスはMITで、直近のコミットは2026年7月23日と開発は続いている。ただし本記事が注目するのは規模そのものではなく、「1本のMarkdownを16ツールそれぞれの流儀へ機械変換する」という設計の方だ。以下、公式リポジトリのスクリプトと設定JSONを実際に読み、何がどう変換されているかを追う。

この記事では、複数のAIコーディングツールへエージェント定義を配布するOSSとしてagency-agentsを解説します。エージェント基盤全般の比較は AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証 をご覧ください。

agency-agentsとは｜254体・17部門のAIエージェント定義集

agency-agentsは、READMEの言葉を借りれば「あなたの手元にある完全なAIエージェンシー（代理店）」を標榜するリポジトリだ。フロントエンド開発者からセキュリティ監査役、マーケター、さらには「Whimsy Injector（遊び心を注入する役）」のような一風変わった役割まで、専門特化した人格定義がひとつのリポジトリに集められている。

実体を確認するため、リポジトリをクローンしてYAMLフロントマターを持つMarkdownファイルを数えたところ、254本の定義が17の部門ディレクトリに分かれていた。部門の定義は divisions.json が正本（source of truth）として持っており、ディレクトリ構成とこのJSONがズレるとCIが落ちる仕組みになっている。

内訳を見ると、engineering（58体）とspecialized（57体）が突出し、marketing（36体）が続く。engineeringの中身も「フロントエンド開発者」「バックエンドアーキテクト」といった定番だけでなく、Filament PHP最適化、組み込みファームウェア、Solidityスマートコントラクト、WeChatミニプログラム、Feishu連携、GaussDB（Huawei製DB）といった、かなり狭い領域の専門家まで含まれている。地理情報（gis）が13体で独立した部門になっている点も、汎用的なエージェント集とは毛色が違う。

この「狭さ」は、リポジトリの成り立ちを反映していると読める。READMEはこのプロジェクトが「Redditのスレッドから生まれ、数か月の反復を経た」ものだと説明しており、実際のコミット履歴を見ると寄稿PRの番号は700番台に達している。つまり中央集権的に設計されたカタログではなく、寄稿者が自分の必要とした専門家を持ち寄って肥大していったロスターである。

エージェント定義ファイルの中身

1体のエージェント定義は、YAMLフロントマターとMarkdown本文で構成される。フロントマターは name / description / color / emoji / vibe という5つのフィールドを持つ。vibe は「そのエージェントらしさ」を1文で表す独自フィールドで、カタログUI側での表示を意図したものと読める。

本文には、役割・性格・記憶（何を覚えている想定か）・中核ミッション・具体的な作業手順・成果物・成功指標といった項目が並ぶ。ファイルサイズの中央値は約13KB、最大のものは約55KBあり、いわゆる「ひとことプロンプト」ではなくしっかりした分量のシステムプロンプトが書かれている。

Claude Codeで言うところのサブエージェント（subagent）の定義ファイルと構造的にはほぼ同じもので、実際Claude Code向けの変換は「そのまま置く」（format名 identity）だけで済む。つまりagency-agentsの定義は、Claude Code利用者から見れば .claude/agents/ にそのまま置けるサブエージェント定義の集合体であり、他ツール利用者から見れば「変換を経て自分の環境で使える形になる」ものだ、という二面性を持つ。

中核は「配布」——1本のMarkdownが16ツールの形式へ変換される

このリポジトリを単なる「awesome系リンク集」と分けているのが、scripts/convert.sh の存在だ。中身を読むと、ツールごとに専用のレンダリング関数が定義されている。convert_codex、convert_gemini_cli、convert_cursor、convert_opencode、convert_qwen、convert_kimi、convert_vibe といった具合である。

たとえばCodex向けの変換関数は、Markdownからフロントマターの name と description、そして本文を取り出し、TOMLファイルとして書き出す。本文は developer_instructions というキーの文字列値に収められる。制御文字が混ざってもTOMLとして壊れないよう、エスケープ処理を通してから埋め込む実装になっている。

一方でCursor向けは、.mdc 形式（Cursorのルールファイル）として description / globs / alwaysApply の3つをフロントマターに持つファイルを生成する。Gemini CLI向けは name と description だけのシンプルなMarkdownだ。同じ本文が、出力先の期待する枠に詰め替えられているという構図がはっきり見える。

format契約という考え方

対応ツールの一覧と、それぞれの導入契約は tools.json が持っている。このJSONの冒頭には設計意図が注記されており、format フィールドについて興味深い規定がある。同じ format 名を名乗る2つのツールは、レンダリング結果がバイト単位で一致することが保証される——逆に言えば、出力が1バイトでも違うなら別の format 名を割り当てなければならない、という契約だ。

実際、Claude CodeとGitHub Copilotはどちらも identity（＝変換せずそのまま）という同じformatを共有している。両者がMarkdown定義をそのまま受け取れるため、レンダラを分ける必要がないという判断である。一方でOsaurusとAntigravityは skill-md を共有し、QwenとGemini CLIはそれぞれ qwen-md / gemini-md と別扱いになっている。

この規律には運用上の意味がある。ツールが16種類に増えても、レンダラの実体は重複なく管理でき、「AとBは同じ出力のはずなのに微妙に違う」という事故を構造的に防げる。加えて scripts/check-tools.sh というCIスクリプトが、tools.json の内容と install.sh のツール一覧・convert.sh のレンダラ集合の食い違いを検出してビルドを落とす。設定ファイルが飾りではなく、実装との整合を強制する正本として機能している。

導入方式は3種類｜per-agent・roster・pluginで何が変わるか

tools.json にはもうひとつ重要なフィールドがある。installKind だ。これは「そのツールにどうやって入れるか」という導入メカニズムの分類で、3つの値をとる。

per-agent は、エージェント1体につき1ファイル（またはディレクトリ）を書き出す方式で、16ツール中13ツールがこれにあたる。Claude Code、Cursor、Codex、Gemini CLI、OpenCode、Kimi、ZCodeなどが該当する。エージェントを個別に足したり消したりできるため、運用としては最も素直だ。

roster は、全エージェントをひとつのファイルに連結して渡す方式で、AiderとWindsurfの2ツールが該当する。Aiderには規約ファイル（conventions）として、Windsurfにはルールファイルとして、すべての定義が区切り線つきで一本に積み上げられる。convert.sh の該当関数は accumulate_aider / accumulate_windsurf という名前で、変換ではなく蓄積であることが関数名にも表れている。

plugin はHermes専用で、レンダリング済みの文字列としては配れないビルド成果物を作る方式だ。build-hermes-plugin.py という専用スクリプトが用意されており、CLIからしか導入できない。

roster方式に潜む容量の問題

この3分類のうち、実務で意識しておきたいのがrosterだ。254体の定義からフロントマターを除いた本文の合計サイズを実測すると、約3.33MB（3,496,432バイト）ある。roster方式の蓄積関数が連結しているのはまさにこの本文部分（＋エージェントごとの見出し行）なので、254体すべてを導入すれば1ファイルがこの桁の分量になる。

per-agent方式のツールでも、体数そのものが制約になる場合がある。READMEとインストーラの実装によれば、OpenCodeのランタイムは約119体までしか登録せず、それを超えた分は黙って捨てられるとされる（上流のissue番号つきで言及されている既知の問題）。install.sh にはツールごとの上限を返す tool_cap という関数があり、OpenCodeには119という値がハードコードされている。選択が上限を超えるときはインストーラが警告を出す実装だ。

「黙って捨てられる」という挙動は、導入したつもりのエージェントが存在しないという状態を生む。上限が実装側で認識され、警告として表面化しているのは、利用者にとっては素直にありがたい設計と言える。ここは複数エージェントを束ねる他のOSS——たとえば Paseo徹底解説｜複数AIコーディングエージェントを束ねるOSSオーケストレーター【AGPL】 のようなオーケストレーター型——とは関心の置きどころが違う部分でもある。あちらは実行時の調停、こちらは配布時の整合が主題だ。

導入手順｜必要な部門だけを入れる

導入はシェルスクリプト2本で完結する。まずリポジトリを取得し、対象ツール向けのファイルを生成する。

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

# 対応する全ツール向けの変換ファイルを生成する
./scripts/convert.sh

次に導入だ。引数なしで実行すると、インストール済みのツールを自動検出する対話ウィザードが立ち上がる。非対話で入れる場合はツールと部門を明示する。

# 対話ウィザード（導入済みツールを自動検出し、ツールと部門を選ぶ）
./scripts/install.sh

# Claude Code に engineering と security の2部門だけを入れる
./scripts/install.sh --tool claude-code --division engineering,security

# Cursor に個別のエージェントだけを入れる
./scripts/install.sh --tool cursor --agent frontend-developer,ui-designer

# 何が入るかを事前に確認する（実際には書き込まない）
./scripts/install.sh --tool opencode --division engineering --dry-run

--list teams を付けると、部門ごとのエージェント数を一覧できる。前述のOpenCodeの上限がある以上、まず --list で規模を見て、--dry-run で書き込み先を確認してから本実行する流れが安全だ。

254体から何を選ぶか

実務上いちばん悩むのは「どれを入れるか」だろう。部門構成を眺めると、選び方の目安は立てやすい。

・engineering（58体）：フロントエンド開発者・バックエンドアーキテクト・コードレビュアー・データベース最適化・SREなど、職種名がそのまま並ぶ。ほとんどのチームはここから数体選べば足りる
・specialized（57体）：部門名のとおり用途が狭い。自分の領域に一致するものがあれば強力だが、無ければ丸ごと不要になる
・security（12体）・testing（9体）：レビューゲートとして常駐させる使い方に向く。コード品質の担保を目的にするならこの2部門が候補
・marketing（36体）・sales（9体）・paid-media（7体）：開発用途のみなら基本的に不要。体数が多いぶん、除外するだけで登録数をかなり削減できる

つまり、開発目的で使うなら --division engineering,security,testing あたりが現実的な出発点になる。この3部門で79体、OpenCodeの119という上限にも収まる計算だ。逆に「とりあえず全部」を選ぶと、使わないマーケティング系の定義が登録枠を圧迫することになる。

エージェント名は engineering-frontend-developer.md のようにファイル名へ部門名がプレフィックスとして付いており、--agent での個別指定時はプレフィックスを除いたスラッグ（frontend-developer）を使う。READMEの表からリンクをたどれば、各定義の中身をGitHub上でそのまま読める。入れる前に1体ずつ本文を読む——分量が中央値13KBあることを踏まえれば、この手間は惜しむべきではない。

変換後のファイルがどうなるか

変換結果のイメージを掴んでおくと、トラブル時の切り分けが早い。同じエージェント定義が、Codex向けにはTOML、Cursor向けには .mdc として出力される。

# integrations/codex/agents/frontend-developer.toml（構造のイメージ）
name = "Frontend Developer"
description = "Expert frontend developer specializing in modern web technologies..."
developer_instructions = "# Frontend Developer Agent Personality\n\nYou are **Frontend Developer**..."

<!-- integrations/cursor/rules/frontend-developer.mdc（構造のイメージ） -->
---
description: Expert frontend developer specializing in modern web technologies...
globs: ""
alwaysApply: false
---
# Frontend Developer Agent Personality
...

Cursor向けの出力には alwaysApply: false が固定で書き込まれる。常時適用ではないルールとして登録する意図の設定値だと読めるが、Cursor側が実際にどう扱うかは本記事では確認していない。

なお convert.sh には、リネームや削除で取り残された古い出力を消す clean_tool_output という処理も入っている。エージェントを削除したのに古いファイルが残って混乱する、という定番の事故に手当てがされている。

awesome-claude-code-subagentsとの違い｜カタログか、配布基盤か

エージェント定義を集めたOSSは他にもある。当サイトでも awesome-claude-code-subagents完全解説｜131個のClaude Code専門subagentを束ねたカタログ を解説しているが、両者は似て非なるものだ。違いは「どこに労力が注がれているか」にある。

awesome-claude-code-subagentsはClaude Code公式のPlugin Marketplaceに乗ることを前提に、カテゴリ単位でまとまった導入体験を作っている。単一ツールに深く最適化するアプローチだ。一方agency-agentsは、どのツールにも深くは寄らず、変換で横に広げるアプローチをとる。

また ruflo｜Claude Code/Codexにネイティブ統合する100エージェント・スウォーム基盤 のように、多数のエージェントを実行時にどう協調させるかを主題にするプロジェクトもある。agency-agentsは実行時の調停には踏み込まない。あくまで「定義を正しい形式で正しい場所に置く」ところまでが守備範囲だ。

したがって選び方はこうなる。Claude Codeだけを使っているなら、公式マーケットプレイス経由で入るカタログ型の方が導入も更新も楽だ。Cursorとターミナルのエージェントを併用している、あるいは将来の乗り換えに備えたいなら、変換レイヤーを持つagency-agentsの発想が効いてくる。両者は排他ではなく、目的が違う道具として併存しうる。

「AIツールの設定を横断管理する」という系譜

視野を広げると、agency-agentsは「AIコーディングツールの設定をツール横断で一元管理する」という、ここ数年で立ち上がってきた系譜に位置づけられる。ルールファイルを複数ツールへ配る同種のOSSは既に存在しており、agency-agentsはそれをルールではなくエージェント人格に対して行っている、と整理すると分かりやすい。

この領域が生まれた背景ははっきりしている。AIコーディングツールは各社が独自形式を採用しており、標準化されていない。Claude Codeは .claude/agents/ にMarkdown、Cursorは .cursor/rules/ に .mdc、Codexは TOML——という具合だ。標準がない以上、橋渡しをする層に価値が生まれる。agency-agentsのformat契約とinstallKind分類は、その橋渡しを場当たりでなく規約として書き下ろした実装例と言える。

agency-agentsを使う前に確認したいこと｜品質・ライセンス・寄稿の管理

規模が大きく寄稿ベースであることは、そのまま留意点にもなる。ここは楽観せずに書いておきたい。

第一に、品質は定義ごとにばらつきうる。 254体のうち多くはコミュニティからのPRで入っており、すべてが同じ水準で検証されているとは限らない。実際に使う前に、対象エージェントのMarkdownを開いて指示内容を読むのが前提になる。分量が中央値13KBあるため、「なんとなく良さそう」で入れると、意図しない作業方針をエージェントに与えることになりかねない。

第二に、リリースタグが切られていない。 GitHub上のリリースは0件で、mainブランチが常に最新という運用だ。バージョンを固定して使いたい場合は、コミットハッシュを自分で固定する必要がある。チームで揃えて運用するなら、フォークして自分たちの正本を持つ方が現実的だろう。

第三に、ライセンスの表記。 LICENSEはMITで、著作権表記は「Copyright (c) 2025 AgentLand Contributors」となっている。リポジトリ名やオーナー名とは異なる団体名が入っている点は、経緯を知らないと戸惑うかもしれない。MITなので商用利用・改変・再配布は可能だが、社内配布の際は表記をそのまま残す必要がある。

品質を守るための仕組みは用意されている

一方で、寄稿の質を機械的に守ろうとする仕組みが入っている点は評価できる。scripts/check-agent-originality.sh は、新しく追加されたエージェント定義が既存のものと実質的に重複していないかを検査するCIスクリプトだ。

その手法が具体的で面白い。単純な文字列一致ではなく、固有名詞を中立化したうえで8語単位のシングル（連続語列）の重なり率を計算する。スクリプト冒頭のコメントは、この方式を採る理由を明示している——国名やプラットフォーム名だけを置換した「再スキン」PRは、体裁が整っているためレビューで見逃されやすく、ライブラリを重複で膨張させる、と。重なり率が40%以上なら重複としてCIを落とし、20%以上なら警告として表示する閾値になっている。

同様に check-divisions.sh と check-tools.sh が、ディレクトリ構成・設定JSON・シェルスクリプト内の一覧という3か所の食い違いを検出する。「設定ファイルとコードがいつの間にかズレる」という、この種のカタログで最も起きやすい腐り方に、CIで手当てがされている。

第四に、プロンプトインジェクションの観点。 SECURITY.mdは、エージェントファイルを「実行可能でないプロンプト定義」と位置づけ、APIキーや資格情報を含めないこと、Markdown内に実行可能コードを入れないことを寄稿者向けの方針として挙げている。加えて「プロンプトインジェクションを試みる疑わしいエージェント定義を報告すること」も明記されている。裏を返せば、エージェント定義そのものが攻撃面になりうるという認識が運営側にある、ということだ。信頼できないPRが混ざる可能性は構造上ゼロにはできないため、利用側でも導入する定義には目を通しておきたい。

まとめ｜「エージェント定義の可搬性」に投資したOSS

agency-agentsを一言で表すなら、AIエージェントの人格定義を「配布可能な成果物」として扱おうとしたOSSである。254体という規模や13.6万というスター数に目が行きがちだが、リポジトリを読んで印象に残るのは、むしろ地味なインフラ部分だった。

tools.json のformat契約——同じformat名なら出力はバイト単位で一致させる、という規律。installKind による導入メカニズムの3分類。設定JSONと実装のズレをCIで落とす検証スクリプト。8語シングルで再スキンPRを弾く独自性チェック。これらは「エージェントを集める」だけなら不要なものばかりで、16ツールへ配り続けることを本気で運用しようとした結果として存在している。

エージェント定義の標準形式が業界で定まらないかぎり、この種の橋渡し層の需要は続くと見られる。逆に言えば、標準が定まった時点でこのレイヤーの役割は縮小する。agency-agentsが投資しているのは、標準が無い時代の可搬性である。

参照ソース

・msitarzewski/agency-agents（公式リポジトリ・README） — 対応ツール一覧、Quick Start、エージェントロスターの一次情報
・scripts/convert.sh（ツール別レンダラの実装） — Codex/Cursor/Gemini CLI等への変換処理、roster方式の蓄積関数
・tools.json（対応ツールと導入方式の定義） — format契約とinstallKind（per-agent / roster / plugin）の分類
・divisions.json（部門定義の正本） — 17部門の定義とCI検証の位置づけ
・SECURITY.md（セキュリティ方針） — エージェントファイルの扱い、プロンプトインジェクション報告の方針