Agency Agentsは役割、手順、成果物を持つAIエージェント集
Agency Agents は、エンジニアリング、設計、マーケティング、製品、およびコミュニティのタスクに対する役割固有のエージェントの定義と作業手順を提供します。
ひと目でわかる
- これは何？
- msitarzewski/agency-agentsは、エンジニアリング、デザイン、マーケティング、プロダクト、コミュニティの役割別エージェント定義を配布します。アプリとスクリプトの使い分けを確認します。
- 誰に向いている？
- Agency Agentsは、汎用的な一つの指示文ではなく、Frontend Developer、Backend Architect、AI Engineer、UX Designerなど役割別の定義を選び、作業の観点と成果物の形をそろえたい人に向く資料集です。アプリからクリックで導入する方法と、スクリプトやMarkdownを自分で確認する方法が併存しているため、チームの変更管理には後者が扱いやすい場合があります。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 3 日前です。
- 何の言語で書かれている？
- 主に Shell です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
役割をプロンプトではなく作業定義にする
Agency Agentsは、AIエージェントを役割別の専門家として組み立てるリポジトリです。READMEが挙げる領域はエンジニアリング、デザイン、マーケティング、プロダクト、コミュニティで、各定義には名前、性格、使命、作業フロー、技術的な成果物、成功指標、コミュニケーション方法が含まれます。Frontend DeveloperならReact、Vue、AngularやUI実装、Backend ArchitectならAPI、データベース、拡張性という具合に、依頼の焦点を選びやすくします。
この構成の利点は、依頼のたびに長い指示を作り直さず、役割ごとの前提を参照できることです。一方、ファイルに書かれた役割が実際の担当者の判断を置き換えるわけではありません。成果物のレビュー基準、リポジトリへの権限、機密情報の扱い、失敗時の人間の承認は利用側で定める必要があります。メタデータでは主言語をShell、ライセンスをMITとしています。
デスクトップアプリと手動導入の二つの入口
READMEにはAgency AgentsというmacOS、Linux、Windows向けネイティブアプリが紹介されています。アプリは全ロスターを閲覧し、Claude Code、Cursor、Codex、Gemini、Osaurusなどへエージェントをクリックで導入し、自動更新も扱うと説明されています。クローンやスクリプトを使いたくない人には分かりやすい入口ですが、アプリがどのファイルをいつ変更するかは、チームの変更管理で確認すべき対象です。
手動経路ではscripts/install.sh --tool claude-codeが案内され、engineering/*.mdを~/.claude/agentsへコピーする例があります。必要な部門だけを選ぶこともでき、--division engineering,securityや--agent frontend-developer,ui-designerの形で範囲を限定できます。ファイルを直接読む場合は、役割、指示、コード例、成功指標をレビューしてから使えるため、社内の承認フローと相性があります。
複数ツールへの変換とOpenCodeの上限
他の環境へ配るときはscripts/convert.shで統合ファイルを作り、scripts/install.shで対話式に導入します。対象としてGitHub Copilot、Antigravity、Gemini CLI、OpenCode、OpenClaw、Cursor、Aider、Windsurf、Kimi、Codex、Osaurus、Hermes、Mistral Vibeなどが並びます。ツールごとのホームディレクトリとエージェント形式が異なるため、変換後のファイルを差分で確認する工程を省けません。
OpenCodeには約119エージェントしか登録されず、残りを静かに落とす上流の問題があるとREADMEは注意しています。--divisionで一部門だけを入れ、選択が上限を越える場合はインストーラーの警告を確認します。全ロスターを導入することが目的でないなら、プロジェクトに必要な担当だけをリスト化する方が、エージェント選択とコンテキスト量の両方を管理しやすくなります。
部門別ロスターを採用単位にする
EngineeringにはFrontend Developer、Backend Architect、Mobile App Builder、AI Engineer、DevOps Automator、Network Engineer、Rapid Prototyper、Senior Developerなどが記載されています。ほかの部門にも専門領域を持つ役割があり、READMEは汎用的なテンプレートではなく、固有の声と手順を持つエージェントとして説明します。実装、設計、運用、コミュニティ対応を同じ人格へ詰め込まないことが、この分割の意図です。
採用時は、まず依頼の種類と必要な成果物を一対一で対応させます。たとえばUI実装ではFrontend Developer、ネットワーク設定ではNetwork Engineerのように候補を絞り、出力を人間がレビューします。複数エージェントを同時に有効化すると、どの役割の判断で変更されたか追いにくくなるため、最初は一部門だけをインストールし、指示の重なりと矛盾を点検するのが安全です。
成果物と成功指標は別途検証する
各エージェントのファイルには、技術的なdeliverable、コード例、成功指標、連絡方法が含まれるとされています。これによって、単に会話を続けるのではなく、実装、設計書、調査、運用手順などを成果物として要求しやすくなります。ただし、リポジトリがいうmeasurable outcomesやproduction-readyという表現は、利用者の案件での結果を示す測定記録ではありません。
導入後は、入力した仕様、エージェントが参照したファイル、変更差分、レビュー結果を残します。成功指標がコードのテスト、画面のアクセシビリティ、応答時間、調査の出典など何を指すのかを案件ごとに具体化してください。エージェント定義の人格的な文体をそのまま信頼性の根拠にせず、出力の事実、権限、再現性を確認することが必要です。
MITライセンスと更新の扱い
リポジトリはMITライセンスで、READMEにはアプリ版のリリースページも案内されています。MITは条件の範囲でエージェント定義の使用、複製、改変、配布を認めますが、記載された指示の正しさ、導入後のサポート、更新の安全性を保証しません。社内で改変した定義を配る場合は、元版との差分と著作権表示を残す必要があります。
アプリの自動更新は便利ですが、スクリプトとMarkdownを固定版で管理する場合とは統制が違います。チームで利用するなら、採用したエージェント名、版、導入先、許可したツール、更新前後の差分を記録し、変更された役割を再レビューします。スター数やロスターの広さは選定の手掛かりであって、個々のエージェントが自社の開発規約や機密管理を満たす証拠ではありません。
編集部の結論
Agency Agentsは、汎用的な一つの指示文ではなく、Frontend Developer、Backend Architect、AI Engineer、UX Designerなど役割別の定義を選び、作業の観点と成果物の形をそろえたい人に向く資料集です。アプリからクリックで導入する方法と、スクリプトやMarkdownを自分で確認する方法が併存しているため、チームの変更管理には後者が扱いやすい場合があります。READMEのproduction-readyや実績に関する表現はプロジェクト側の説明であり、案件への適合性を証明しません。まず一部門、一つのツール、一つの作業で出力をレビューし、エージェントの権限と参照ファイルを固定してから広げるべきです。
コミュニティノート