agency-agents-zh レビュー: 277 体の中国市場向け AI 役割定義をどう運用するか
🎭 277 个即插即用的 AI 专家角色 — 支持 Claude Code/Cursor/Copilot 等 20 种工具，覆盖工程/设计/营销/金融等 20 个部门。含 64 个中国市场原创智能体（小红书/抖音/微信/飞书/钉钉/Qt 上位机/机械设计）。搭配编排器 agency-orchestrator，一句话即可让多位专家按 DAG 自动协作。
ひと目でわかる
- これは何？
- Claude Code、Cursor、Copilot など 20 種のツール向けに用意された 277 個のエージェント定義と、DAG で複数エージェントを連携させる agency-orchestrator の関係を整理する。導入判断で確認すべきは、定義ファイルの実体とメンテナンス負荷である。
- 誰に向いている？
- 中国市場向けの業務文脈（小紅書、抖音、微信、飛書、釘釘、Qt 上位機など）をプロンプトに落とし込みたいチーム、および Claude Code や Cursor に役割定義を追加したい個人には向く。汎用的な英語圏の役割定義で足りる場合や、上流の agency-agents をそのまま追従したい場合は、このリポジトリを選ぶ理由が薄い。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Shell です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
このリポジトリが埋めるのは「役割定義の翻訳と中国語圏向けの追加」という隙間
上流の agency-agents は英語で書かれた AI 役割定義の集合体である。agency-agents-zh はその中国語コミュニティ版と位置づけられ、README によれば上流の完全翻訳 213 体に加えて、中国市場向けの独自エージェントを 64 体追加している。合計 277 体、部門数は 20、対応ツールは 20 種という内訳が README の表で示されている。
対象読者は二種類に分かれる。ひとつは Claude Code や Cursor を使っていて、汎用のシステムプロンプトではなく職種ごとの振る舞いを定義したファイルをそのまま置きたい開発者。もうひとつは、小紅書、抖音、微信、B站、飛書、釘釘といったプラットフォーム運用や、越境 EC、政務 ToG、医療コンプライアンス、Qt 工業上位機、機械設計、畜産の記録照合といった垂直領域の業務を、プロンプトとして再利用したい実務者である。後者の 64 体は上流には存在しないため、英語版を追うだけでは得られない。
注意すべきは、これがモデルやランタイムではなく、テキスト資産の配布物だという点である。README は「即插即用」と表現するが、実際に動かすのは利用者が選んだ AI ツール側であり、このリポジトリ自体は推論を行わない。
277 体はどう配置され、orchestrator がどこで効くのか
リポジトリの主言語は Shell と記載されており、中身は各ツールが読み込む形式のエージェント定義ファイル群と、それらを配布・検証するスクリプトで構成されていると推測できる。README が示す構造上の要点は、20 種のツールそれぞれに対応する配置先があるという点だ。Claude Code、Cursor、Copilot が代表例として挙げられているが、ツールごとに定義の読み込み規約が異なるため、単一のファイルを全ツールで共有する設計にはなっていない。
連携の仕組みは姉妹プロジェクトの agency-orchestrator が担う。README の説明では「一句话即可让多位专家按 DAG 自动协作」とあり、複数のエージェントを有向非巡回グラフとして並べ、依存関係に沿って順に実行する。つまり単体のエージェント定義はあくまで役割と成果物の記述であり、実行順序や受け渡しは orchestrator 側の責務である。ここは設計上の分離点として明確で、定義だけを導入しても複数エージェントの協調は得られない。
orchestrator は GitHub Releases で macOS、Windows、Linux 向けのネイティブアプリとして配布され、「免装 Node」と明記されている。Node 環境を用意せずに試したい層を想定した配布形態だと言える。
導入は npm とリポジトリ直下のコピー、二つの経路がある
README には npm バッジがあり、パッケージ名は agency-agents-zh である。npm 経由で取得する場合の具体的なインストールコマンドや配置手順は、与えられた README の範囲では記載が確認できない。したがって「npm install agency-agents-zh を実行すれば各ツールに自動配置される」といった手順は、この記事では断定しない。
確実に読み取れる経路は二つある。ひとつはリポジトリを clone し、自分のツールに対応するディレクトリの定義ファイルを、そのツールが定める場所へコピーする方法。もうひとつは agency-orchestrator の Releases からネイティブアプリを取得する方法で、こちらは Node のインストールが不要と明記されている。オンラインで試す場合は README が示す ao.aiolaola.com/experts が案内されている。
設定キーや環境変数についても、README には具体的な記述が見当たらない。導入前に自分の環境で確認すべきは、対応ツール一覧の中に自分が使うものが含まれているか、そしてそのツール向けのディレクトリがリポジトリ内に実在するかである。20 種対応という数字だけを見て進めると、自分のツール向けの定義が薄いという結果になり得る。
定義ファイルの品質は上流と追加分で差が出る
213 体は英語からの翻訳である。翻訳物に共通する問題として、元のプロンプトが前提としていたツール名、規制、商習慣がそのまま残る可能性がある。README は完全翻訳と述べているが、翻訳のレビュー体制や更新追従の頻度については記載がない。上流が更新されたとき、この中国語版がどの程度の遅延で追随するのかは、リポジトリの情報だけでは判断できない。
一方の 64 体は中国市場向けの独自追加であり、上流には存在しない。小紅書や抖音の運用、飛書や釘釘の連携、Qt 工業上位機、機械設計、畜産の記録照合といった領域は、英語圏の汎用エージェント定義では代替しにくい。ここがこのリポジトリを選ぶ最大の理由になる。
ただし垂直領域の定義は、対象業務の変化に弱い。プラットフォームの仕様変更や規制の改定が起きたとき、定義ファイルの中身が古いまま残るリスクがある。README には更新ポリシーやレビュー手順の記載がないため、採用するなら自分たちで差分を追う前提で臨むほうがよい。
向かないケース: 汎用で足りる場合と、上流を直接追う場合
第一に、英語の役割定義で業務が回るチームには不要である。翻訳を挟む分、用語の揺れや原文との差異を検証する手間が増える。上流の agency-agents を直接参照したほうが、更新の即時性と原文のニュアンスを保てる。
第二に、特定のツールに強く依存した運用をしている場合。20 種対応と謳われていても、ツールごとに定義の形式や読み込み規約が異なるため、対応の厚さは均一とは限らない。自分のツール向けのディレクトリを実際に開いて、定義の本数と記述の密度を確認するほうが早い。
第三に、エージェント同士の協調を定義ファイルだけで完結させたい場合。README が示すとおり、協調は agency-orchestrator 側の機能であり、定義群だけを導入しても DAG による自動連携は得られない。orchestrator を別途導入するかどうかは、別の判断になる。
ライセンスは MIT と明記されている。MIT は一般的に寛容な条件だが、同梱されるスポンサー画像や第三者由来のプロンプト、プラットフォーム名などの商標が同じ条件で扱えるかは別問題である。ここは法的助言ではなく、確認事項の指摘として挙げておく。
比較対象としての上流 agency-agents と、自作プロンプト運用
最も自然な比較対象は上流の msitarzewski/agency-agents である。違いは翻訳の有無だけではない。上流は英語圏の職種と商習慣を前提にした役割定義を提供し、中国語版はそこに中国市場向けの 64 体を足している。したがって、必要な役割が中国市場向けの追加分に含まれるなら中国語版、含まれないなら上流、という切り分けになる。両方を併用する場合は、同じ職種の定義が二重に存在することになるため、どちらを優先するかを決めておかないと、ツール側の読み込み順で挙動が変わる。
もうひとつの比較対象は、自前でプロンプトを書いてリポジトリ内で管理する運用である。自作の利点は、自社の用語、成果物のフォーマット、レビュー手順をそのまま埋め込めること。欠点は、職種の数だけ書き手が必要になることだ。277 体という規模は、この執筆コストを外部化するための数字だと捉えると判断しやすい。逆に言えば、自社固有の業務フローが強い領域では、既製の定義をそのまま使うより、雛形として読んで書き換える使い方のほうが現実的である。
メンテナンス負荷とバージョンの追い方
リリース履歴を見ると、v1.2.4 は「计数补齐 216 + 计数守卫」、v1.2.5 は「README 在线展示区 + 精简」、v1.2.6 が最新で 2026-06-16 付。注目すべきは v1.2.4 の「计数守卫」で、エージェント数の表記が実態とずれることを防ぐ仕組みを入れたと読める。定義ファイルを大量に抱えるリポジトリでは、README の数字と実ファイル数が乖離しやすい。それを検証するスクリプトを置いた判断は妥当である。
ただし、この種のリポジトリのメンテナンスコストは、コードのビルドではなく定義の鮮度に現れる。上流の翻訳追従、プラットフォーム仕様の変更、モデル側の挙動変化の三つが同時に効く。v1.2.5 と v1.2.6 が同日付である点からは、README 周辺の整備が短期間に集中して行われたことがうかがえる。
採用するなら、導入時にエージェント総数と自分のツール向けディレクトリの本数を数え、README の表と突き合わせておく。そのうえで、上流の更新をどの頻度で取り込むかを決めておくと、後から差分の把握が楽になる。デスクトップクライアントを使う場合、更新は orchestrator 側の Releases を追うことになるため、定義群とアプリのバージョンを別々に管理する必要がある。
編集部の結論
中国市場向けの業務文脈（小紅書、抖音、微信、飛書、釘釘、Qt 上位機など）をプロンプトに落とし込みたいチーム、および Claude Code や Cursor に役割定義を追加したい個人には向く。汎用的な英語圏の役割定義で足りる場合や、上流の agency-agents をそのまま追従したい場合は、このリポジトリを選ぶ理由が薄い。導入前に確認すべきは、自分のツールに対応するディレクトリが実際に存在するか、定義ファイルがどの形式（Markdown か設定ファイルか）で置かれているか、そして v1.2.4 のリリースノートにある「計数ガード」が何を検証しているかである。ライセンスは MIT と明記されているが、同梱される第三者提供のプロンプトや商標の扱いは別途確認が必要になる。
コミュニティノート