あなたのコーディングエージェントには、デフォルトの人格がひとつだけ備わっている。有能なジェネラリストだ。認証フローのレビューを頼めば、もっともらしいけれど印象に残らない助言が返ってくる。脅威モデルとチェックリストを備えたセキュリティレビュアーに頼めば、ちゃんとした指摘が返ってくる。この違いはマークダウンファイル1枚以外に何のコストもかからない。だからこそ agency-agents は149,312スターに到達した。
このライブラリは本当に役に立つ。だが同時に、それは1台のマシン上のファイル群にすぎない。複数の人間が「役割」に意味を持たせようとした瞬間、それが限界になる。本記事では、何が得られるのか、必要な部分だけをインストールする方法、そして「役割定義」とチームが仕事を割り当てられるエージェントの違いを解説する。
TL;DR
これは、コーディングエージェントを拡張するオープンソースツールのまとめに含まれる5本の深掘り記事のうちの1本だ。
agency-agentsは、約20カテゴリ、300を超えるエージェント役割定義のコレクションで、MITライセンスの下、Claude Code、Cursor、Codex、Gemini CLI、OpenCode、および他10数種類のツールへコマンド1つでインストールできる。各ファイルには、アイデンティティ、作業プロセス、成果物、完了条件が記述されている。役割はエージェントのタスクの捉え方を変えるが、エージェントが持っていない情報を与えるわけではないし、セッションをまたいで持続するわけでもない。1つのディビジョンをインストールし、自分のスタックに合わせてファイルを編集し、週に何度も使うようになったものを、チームが割り当てられる保存済み構成に昇格させよう。
何をインストールするのか
2026年9月1日時点でリポジトリツリーを数えると、20のトップレベルカテゴリフォルダに312個のマークダウンファイルがある。リポジトリのREADMEにはいまだに「230+」と書かれているが、これは古い情報だ。
| ディビジョン | ファイル数 | ディビジョン | ファイル数 |
|---|---|---|---|
| engineering | 59 | testing | 9 |
| specialized | 58 | paid-media | 7 |
| marketing | 36 | project-management | 7 |
| game-development | 21 | academic | 6 |
| integrations | 18 | spatial-computing | 6 |
| strategy | 16 | support | 6 |
| gis | 13 | finance | 5 |
| security | 12 | product | 5 |
| design | 10 | healthcare | 3 |
| sales | 9 | examples | 6 |
多くのチームが最初に手を付けるのはengineeringディビジョンで、その具体性は通常のプロンプト集が到達する水準より高い。Frontend DeveloperやBackend Architectに加えて、Cisco IOS-XEとJuniper Junosに焦点を絞ったNetwork Engineer、ESP32やSTM32ターゲット向けのEmbedded Firmware Engineer、ポストモーテムとオンコール体制のためのIncident Response Commander、そしてリポジトリを読み取り専用で探索し、変更を提案するのではなく事実を述べるように書かれたCodebase Onboarding Engineerなどがある。
この最後の例は、このパターンが機能していることを示している。編集禁止を明示した読み取り専用の役割は、デフォルトのエージェントとは別のツールであり、そのコストはファイル1枚分だ。
必要なものだけをインストールする
git clone https://github.com/msitarzewski/agency-agents.git
cd agency-agents
./scripts/install.sh # interactive
./scripts/install.sh --tool claude-code --division engineering,security
./scripts/install.sh --tool cursor --agent frontend-developer
./scripts/install.sh --list teams
./scripts/install.sh --tool opencode --division engineering --dry-run
リポジトリには記載されているものの、ほとんどの解説記事が飛ばしている警告がひとつある。OpenCodeのランタイムは約119個のエージェントを登録し、残りは警告なしに捨ててしまうのだ。--divisionでサブセットをインストールすれば上限内に収まり、選択が上限を超える場合はインストーラーが警告を出す。サイレントな切り捨ては、起こりうる中で最悪の失敗モードだ。なぜなら、欲しかった役割が存在しないのに、そのことを何も教えてくれないからだ。
このバグがなくても、300個すべてをインストールするのは間違いだ。覚えられない名簿は、使われない名簿でしかない。自分の携わるディビジョンをインストールし、5つのファイルを読み、チームの運営方法に合わないものは削除しよう。
役割定義が立ち止まる地点
役割とはフレームだ。エージェントが何に注目するか、どんな形式で出力するか、何をもって完了と見なすかを定める。これは言葉の印象以上に価値がある。なぜならエージェントの出力が弱くなる理由の多くは、モデルが間違っていることではなく、モデルが間違った形の答えに向けて最適化してしまうことにあるからだ。
役割にできないことが2つある。
1つ目は、モデルが持っていない情報を与えることはできない。Backend Architectの役割は、推測したインターフェースに対して整ったコードを生成する。役割は構造を改善したのであって、結果を正しくしたわけではない。
2つ目は、セッションをまたいで生き残ることができない。役割を有効化し、タスクをこなし、ターミナルを閉じる。翌日また有効化のコマンドを打ち込む。このリポジトリにあるディビジョンのうち9つは、組織の中でしか存在しない職務を記述しているのに、それらをインストールするツールには組織という概念がない。割り当てはなく、先週の火曜日にセキュリティレビュアーが何を見つけたかの記録もなく、同僚がそれを目にすることもできない。
役割定義から、割り当て可能なエージェントへ
役割定義は、毎回打ち直すプロンプトだ。Sharklyにおけるエージェントは保存済みの構成である。つまり、指示、ランタイム、スキル、リポジトリ、環境だ。それは、~/.claude/agents/内のファイルが到達しようとしているものの、持続可能な形だ。
各要素にはそれぞれの役割がある。エージェントは作業をどう扱うべきかを定義する。Computerはホストとローカルリソースを提供する。Runtimeは、チームがすでにインストールしているコーディングツールを使って実際のエージェントセッションを実行する。Taskは共有された記録として残る。
SharklyはClaude Code、Codex、あるいはこのリポジトリの役割に取って代わるものではない。それらの周囲に、共有タスク、Computer、コンテキスト、制御、レビューのレイヤーを追加するものだ。モデルの利用は、それらのツールで設定されたサブスクリプションやAPIキーを通じて引き続き行われる。
ディビジョンという概念はそのまま対応する。Crewは、1人のリーダーエージェントによって調整される、PeopleとAgentsの再利用可能なグループだ。Crewはリーダー主導で動く。リーダーがタスクのコンテキストを読み、どのメンバーを関与させるかを決め、その結果を1つのTaskに集約する。すべてのスペシャリストが一斉に動き出すのではない。これこそ、agency-agentsが8つのディビジョンで示唆しながら実行できていないものだ。なぜなら、ファイルのフォルダにはリーダーも、戻る先の共有タスクもないからだ。
実行、ブロッカー、結果、フォローアップの議論はタスクのタイムラインに戻ってくる。セキュリティレビュアーが何を見つけたのかと誰かが尋ねれば、答えはTaskの中にある。
リポジトリはチームとしてではなく、ライブラリとして使う
agency-agentsは、あなたが1人で、ローカルで作業し、今日の仕事の枠組みをより良くしたいときに、そのまま使うのがよい。ディビジョンをインストールし、ファイルを読み、20分で価値を得よう。
保存済みのAgentsを使うのは、その役割を複数の人間が再利用する必要があるとき、出力が正式なものになる前にレビューを要するとき、あるいは3か月後にその役割が何を生み、なぜそうなったのかを誰かが尋ねるときだ。そのしきい値はチームの規模ではない。「その役割がセッションを超えて生き残る必要があるかどうか」だ。
実践的なワークフローは、リポジトリを素材として扱うことだ。本当に再利用可能な部分であるファイル構造を取り出し、汎用的な中身を自分のスタックと自分の完了条件に置き換え、週に2回手を伸ばすものは保存済み構成に昇格させよう。優れたファイルはどれも同じ形をしている。アイデンティティ、ミッション、順序立てられたプロセス、形式を伴う成果物、成功基準だ。7段階のプロセスを持つレビュー役割は、セッションをまたいで一貫した出力を生む。それがなければ、その日のモデルの気分次第の出力になる。
エージェントは調査し、実行し、テストし、報告する。人間は方向性を定め、権限を与え、結果を受け入れる。
よくある質問
agency-agentsはClaude Code以外のツールでも動きますか? はい。変換スクリプトがツールごとの統合ファイルを生成し、install.sh --toolで対象を指定します。Claude Code、Cursor、Codex、Gemini CLI、OpenCode、Copilot、Windsurf、Aider、Kimi Codeなどがサポート対象です。macOS、Linux、Windows向けのデスクトップアプリもあります。
300個の役割をすべてインストールすべきですか? いいえ。OpenCodeではできません。約119個が登録され、残りは警告なしに捨てられるからです。他のツールでは可能ですが、そのほとんどを使うことはないでしょう。ディビジョン単位でインストールしてください。
役割はエージェントをより高性能にしますか? より適切に方向づけます。一貫性と出力形式は改善します。モデルが一度も持ったことのない事実に関する知識は変わりません。
これはエージェントフレームワークと同じものですか? いいえ。フレームワークはコードによるランタイムオーケストレーションを提供します。agency-agentsは、既存のエージェントの振る舞いを変えるマークダウンファイルを提供します。レイヤーが異なり、重複はありません。
これはSharkly Skillsとどう関係しますか? Skillは、エージェントの構成に紐づける能力であり、マシンごとに再インストールするのではなく、そのエージェントとともに再利用されます。このリポジトリの役割定義は、それらを書くための良い素材になります。
まとめ
agency-agentsは、あるひとつのアイデアの、入手可能な中で最良の形だ。すなわち、エージェントは自分がどんな役割を演じているかを知っているとき、より良い仕事をする。ディビジョンをインストールし、ファイルを読み、チームに合うものへと編集しよう。
そのうえで、境界線をはっきりさせておこう。役割は、あなたのモデルが一度も与えられなかった事実を知っているわけではないし、チームが見たりレビューしたりできる何かに持続するわけでもない。名簿は良い出発点だ。だが組織ではない。Sharklyがもう半分を担う。Taskは共有された記録であり、実行はすでに料金を払っているランタイムを通じて接続したComputers上で行われ、結果は人間がレビューして受け入れられる場所へと戻ってくる。



