AIエージェント向けの設定というと、1枚のMarkdownを置くイメージがあります。しかし調査した中で最も先進的だった事例は、リポジトリ内に独自のプラグインマーケットプレイスを構築していました。
この記事では、その体系を設定・エージェント定義・スキル分類・テレメトリ・階層構造の5観点から分解します。
本記事はOSS横断調査シリーズの深掘り記事です。全体像は「AGENTS.md / CLAUDE.md 実装事例 横断調査」をご覧ください。
この調査の概要
調査日 | 2026年5月4日 |
|---|---|
対象 | OSSノーコードワークフロービルダーのAIエージェント設定 |
特徴 | リポジトリ同梱の独自プラグインマーケットプレイス／2エージェント／14スキル／テレメトリ計測 |
結論：スキルが自己増殖する仕組みまで作られている
この事例で最も示唆的なのは、create-skill（新スキルを作るスキル）というメタスキルが存在する点です。
組織として継続的にスキルを増やす仕組みがツール化されており、エージェント設定が成長し続ける構造になっています。
設定ファイルを「書いて終わり」にせず、増やす手順まで含めて設計されています。
独自マーケットプレイスという発想
設定ファイルには extraKnownMarketplaces という指定があります。
"extraKnownMarketplaces": {
"n8n": {"source": {"source": "directory", "path": "./.claude/plugins/n8n"}}
},
"enabledPlugins": {"n8n@n8n": true}これは比較的新しい機能で、社内・プロジェクト内に独自のプラグインレジストリを定義できます。
この事例では「リポジトリ同梱の社内マーケットプレイス」として活用し、すべての社内スキル・エージェント・コマンドに専用のネームスペースを付与しています。
個人やサードパーティが作るスキルとの命名衝突を防ぐ設計です。スキルが増えるほど、この分離が効いてきます。
権限は最小許可リストで組む
設定の permissions.allow に含まれるのは、次のような操作だけです。
- 読み取り系のgitコマンド（log / show / grep / ls）
- テスト系のコマンド（build / lint / test / typecheck）
- 計画ファイルディレクトリへの書き込み
破壊的操作（削除・強制プッシュ・リセット等）は一切含まれていません。
許可リスト方式は、「危険なものを禁止する」のではなく「安全なものだけ通す」という発想です。想定外の操作が自動的に弾かれます。
エージェントの役割分離
2つのエージェントが明確に分離されています。「エージェントの分業」をOSSで公式化した数少ない例です。
developer（青） | issue-triager（赤） | |
|---|---|---|
役割 | フルスタック開発 | 調査のみ・実装は行わない |
範囲 | フロントエンド／バックエンド／ワークフローエンジン | severity分類（CRITICAL / HIGH / MEDIUM / LOW） |
制約 | 5ステップのワークフロー（チケット取得 → 影響範囲特定 → 実装 → テスト追加 → PR作成） | チケットへの直接書き込み禁止（人間が確認してから書く） |
「実装しないエージェント」を公式に定義することで、調査と実装の責任を分離し、エージェント間の暗黙の越権を構造的に防いでいます。
細部ですが、色（青／赤）による視覚識別も設計されています。UI上で「いま誰が動いているか」を即座に把握させるためです。
14スキルを機能で分類する
コントリビューションフロー系
PR作成スキルには具体的な制約が入っています。
- タイトルはConventional Commitsの正規表現で検証
- セキュリティ修正は中立的タイトル必須
(no-changelog)サフィックスでリリースノートから除外
実装系
スキル | 注目点 |
|---|---|
OAuth追加 | 10ステップの手順。カスタムスコープUI、ゲートウェイAPI型にも対応 |
エンドポイント保護 | 認証スコープの標準マッピング、リグレッションテストのパターンまで規定 |
調査・診断系
バグ再現スキルが特徴的です。実装はせず、再現テストだけを作ります。
- 結果をCONFIRMED / LIKELY / UNCONFIRMED / SKIPPED / ALREADY_FIXED の5段階で分類
- 「本物のクレデンシャル必須」「レースコンディション」「クラウド固有インフラ」はハードベイルアウト（諦める条件を明示）
「できない条件」を先に定義している点が実用的です。AIは無理にでも進めようとするため、撤退条件が必要になります。
もう1つ、動画のトランスクリプトを取得するスキルも用意されています。人間が動画で共有した仕様をAIに読ませる経路——非テキスト情報をエージェントに渡す設計として注目できます。
仕様・規約系
- 仕様駆動開発スキル——仕様ディレクトリを正本として、実装との乖離をAligned / Drift / Gaps の3分類で差分報告
- デザインシステムスキル——Semantic tokens → Primitives → Hard-coded values の優先順位を定義し、非推奨コンポーネントやレガシートークンを強く警告
メタ系
前述の create-skill に加え、MCPサーバーのセットアップスキルがあります。
スキルの粒度
調査から見えた重要な観察です。
スキル粒度は「ドメイン特化のレシピ」レベルです。汎用スキルではなく、そのコードベース固有の知識を埋め込んだ手順書として機能しています。
汎用的な「良いコードの書き方」ではなく、「このリポジトリでOAuthを追加するときの10ステップ」が書かれています。
どのスキルが使われているかを計測する
運用面で興味深い実装です。
フックが、スキル実行のたびに計測スクリプトを非同期実行します。ユーザー識別子をハッシュ化したうえで送信する仕組みです。
- OSS内部で「どのスキルが使われているか」を定量計測する——エージェント設計を改善するフィードバックループ
- 計測を実行しない選択肢も提供されており、プライバシー設計が明示的
- 非同期実行＋タイムアウト付きで、送信失敗が開発を妨げない
作ったスキルが実際に使われているかを測る仕組みは、他ではあまり見ません。使われていないスキルを見つけられます。
コマンドは委譲のラッパー
コマンドは、エージェント呼び出しを簡略化する役割を担っています。
- 計画コマンド——チケットIDを引数に取り、計画ファイルを生成。出力構造はタイトル・リンク・サマリ・実装計画・テスト戦略・リスクの6セクションに固定
- トリアージコマンド——調査専用エージェントへの委譲ラッパー
出力構造を固定しておくと、誰が実行しても同じ形式の計画が出てきます。
モノレポでは階層化する
サブパッケージごとにAGENTS.mdを配置し、グローバル指示と局所的指示を分離しています。
たとえばフロントエンドのパッケージでは、デザインシステム関連の変更時に特定のスキルを使うことを必須化しています。
ルートに全部書くと肥大化し、関係ない指示まで読ませることになります。階層化すればコンテキストを節約できます。
よくある質問
スキルはどう増やしていくのですか？
新スキルを作るためのメタスキルが用意されています。組織として継続的にスキルを増やす仕組みがツール化されており、設定が成長し続ける構造になっています。
権限設定はどう組むべきですか？
最小許可リスト方式です。読み取り系gitコマンド、テスト系コマンド、計画ファイルへの書き込みだけを許可し、破壊的操作は一切含めない構成が観測されました。
エージェントは1つでよいですか？
役割で分離する例があります。特に「実装しない・調査だけする」エージェントを公式に定義すると、責任範囲が明確になり暗黙の越権を防げます。
スキルは汎用的に書くべきですか？
ドメイン特化のレシピとして書かれています。汎用的な指針ではなく、そのコードベース固有の知識を埋め込んだ手順書として機能しています。
まとめ
- リポジトリ同梱の独自プラグインマーケットプレイスという構成。ネームスペースで命名衝突を防ぐ
- 権限は最小許可リスト。危険なものを禁止するのではなく安全なものだけ通す
- 「実装しないエージェント」を公式定義して、調査と実装の責任を分離
- バグ再現スキルには5段階の結果分類と撤退条件が定義されている
- スキル粒度は汎用指針ではなくドメイン特化のレシピ
- スキル利用状況を計測するフィードバックループを持つ（プライバシー配慮つき）
- コマンドは出力構造を固定した委譲ラッパー
- モノレポはサブパッケージごとに設定を階層化してコンテキストを節約
- 新スキルを作るメタスキルにより、設定が成長し続ける
AIエージェントの設定は、1枚のドキュメントで完結させる必要はありません。増やす仕組みと使われ方を測る仕組みまで含めると、運用しながら育てられます。
株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の開発体制へのAI導入を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。