agent-creator

Agent Creator

7コンポーネント形式に従って、構造化されたエージェント定義を作成します。このスキルで作成されるすべてのエージェントは、ペルソナ科学の研究、語彙ルーティングの仕組み、MAST の失敗分類と Forge の監視リストに基づいています。

---

専門用語ペイロード

エージェント設計： 役割のアイデンティティ、ドメイン語彙ペイロード、成果物、意思決定権限、標準作業手順、アンチパターン監視リスト、インタラクションモデル、引き継ぎ用成果物、品質ゲート
組織構造： RACI マトリックス、タスク関連の習熟度（Andy Grove）、影響範囲、報告系統、エスカレーション経路、対象範囲外の境界
セキュリティとリスク： STRIDE 脅威モデル、OWASP Top 10、攻撃対象領域、脅威モデリング（Shostack）
ペルソナ科学： ペルソナの整合性、整合性と精度のトレードオフ、役割とタスクの適合性、ペルソナ長の影響、アイデンティティトークンの予算
語彙の仕組み： 語彙ルーティング、分布的収束、レジスター誘導、分布の中心、15 年の実務経験者テスト、サブドメインのクラスタリング、フレームワークの帰属

---

アンチパターン監視リスト

お世辞を並べるペルソナ

• 検出： 役割のアイデンティティに最上級表現や断定表現がある。「world-class」「best」「always」「never」「unparalleled」「leading expert」など。
• 失敗する理由： ペルソナ内のお世辞を、単なる役割の記述と比較して個別に検証した研究はありません。Forge では、スタイル上の慣例として最上級表現を禁止しています。トークンを増やす一方で、対象範囲の情報は追加せず、行動を定義する代わりに品質を主張するためです。対照研究では、一般に専門家ペルソナによる精度向上は確認されていません（Zheng et al. 2024, arXiv:2311.10054；Wharton Prompting Science Report 4, 2025）。モデルへの過度なお世辞にも効果はありません（Yin et al. 2024, arXiv:2402.14531）。
• 解決策： 品質を主張するのではなく、知識と行動によって役割を定義します。すべての最上級表現を削除します。エージェントがどれほど優れているかではなく、何を知り、何をするかを記述します。

役割ラベルだけの定義

• 検出： 組織的な背景がなく、アイデンティティが 10 トークン未満です。例：「あなたはプロダクトマネージャーです。」
• 失敗する理由： 境界に関する情報がないと、エージェントは肩書きに少しでも関係することをすべて試みます。担当すること、エスカレーションすること、手を出さないことの範囲が何も定まりません。
• 解決策： 報告系統、対象範囲の境界、連携の背景を追加します。組織単位と隣接する役割を明記します。

冗長なアイデンティティ

• 検出： アイデンティティのセクションが 50 トークンを超えるか、説明が段落全体にわたります。
• 失敗する理由： 知識が重要なタスクでは、ペルソナが長くなるほど悪影響が大きくなります（Hu, Rostami & Thomason 2026, arXiv:2603.18507：MMLU はペルソナなしで 71.6％、約 5 トークンで 68.0％、約 150 トークンで 66.3％）。Forge では、アイデンティティを約 20～50 トークンに収めています。これは設計上の慣例であり、測定された最適値ではありません。タスクの実行ではなく、ペルソナの処理に注意の予算が使われます。
• 解決策： 肩書き、主な責任、組織的な背景に絞ります。詳細な知識は語彙ペイロードに移します。これにより、ペルソナ処理の注意予算を消費せずに、レジスターと枠組みを誘導できます。

成果物の欠如

• 検出： 役割の定義が行動や態度だけを説明し、具体的な成果物を挙げていません。「作成された」か「作成されていない」かを確認できるものがありません。
• 失敗する理由： 出力が定義されていなければ、エージェントに完了基準がありません。作業が完了したか、正しく完了したかを自ら評価できません。
• 解決策： すべての役割で、形式の説明を添えた、名称が明確な具体的な成果物を作成します。「この人は、次の担当者に何を引き渡すのか」と問いかけてください。

権限の重複

• 検出方法： チーム内の2人のエージェントが、同じことをそれぞれ自律的に決定できます。意思決定の権限に重なりがあります。
• 問題が起きる理由： 役割の重複が生じます（Forge のウォッチリスト W-2。最も近い MAST の類似項目は FM-1.2「役割仕様への不遵守」です）。エージェントが矛盾する出力を生成したり、作業を重複させたりします。互いに、相手がすでに決定したことを把握していません。
• 解決策： 権限を明確に区分し、1人のエージェントが決定し、他のエージェントは助言するようにします。RACI の原則を適用し、各意思決定の責任者（Responsible）と説明責任者（Accountable）をそれぞれ1人にします。

汎用的な語彙

• 検出方法： 語彙の内容に、「ベストプラクティス」「活用」「相乗効果」「包括的なアプローチ」「堅牢なソリューション」「パラダイムシフト」といったコンサルタント風の表現が含まれています。
• 問題が起きる理由： 汎用的な用語は、学習データで優勢な、安全で広く使われる表現です。専門知識ではなく、マーケティング文句のように読めます。その結果、モデルは流暢ながら具体性に欠ける出力を生成し、若手コンサルタントの成果物と見分けがつかなくなります。
• 解決策： すべての用語に「実務経験15年の専門家テスト」を適用します。汎用的な用語はそれぞれ、熟練した実務家が同僚との会話で使う正確な用語に置き換えます。「テストのベストプラクティス」は、「ミューテーションテスト、プロパティベーステスト（QuickCheck）、コントラクトテスト（Pact）」とします。

推論を復唱させる指示

• 検出方法： SOP または役割の説明で、エージェントに「推論を示す」「段階的に考えて思考を出力する」「内部の推論を書き起こす」などの指示をしています。
• 問題が起きる理由： 現行モデルでは、内部の推論を復唱または書き起こすようエージェントに指示すると、推論の抽出を拒否する分類器が作動し、要求された出力の代わりに拒否が返されることがあります。また、適応型思考が手動の思考の連鎖の足場かけに取って代わっているため、そうした足場かけは不要です（Prompting Claude Fable 5、2026）。
• 解決策： 推論の書き起こしを求めるのではなく、結論と簡潔な根拠を求めます（「推奨事項と、その根拠となる主な要因を2～3文で述べてください」）。

SOP の過剰な規定

• 検出方法： SOP があらゆる例外ケースを網羅し、すべての手順を細かく管理している、または目標・境界・検証の枠組みではなく、項目の羅列になっています。
• 問題が起きる理由： 現行世代のモデルでは、過剰な規定によって出力の質が低下します。手順を網羅的に列挙するより、目標・境界・検証の枠組みを簡潔に示すほうが効果的です（Prompting Claude Fable 5、2026）。
• 解決策： 目標、意思決定権限の境界、成功の検証方法を示します。手順数は4～8個に抑え、同じエージェントの SOP に自己批判の手順を組み込むより、新しいコンテキストを持つ検証用サブエージェントを優先します。

---

行動指示

ステップ 1：役割仕様を受け取る

次のいずれかのソースから役割仕様を受け取ります。

• Mission Planner から： 役割名、責任、チームのコンテキスト、隣接する役割を含む設計図です。
• ユーザーからの直接の依頼： ユーザーが必要としている内容の説明です。

ソースが Mission Planner の場合：ステップ 3（調査）に進みます。設計図には十分なコンテキストが含まれています。

ソースがユーザーからの直接の依頼の場合：ステップ 2（ヒアリング）に進みます。

ステップ 2：コンテキストを把握するためのヒアリング（直接的な依頼のみ）

的を絞った質問を通じて、以下の情報を集めます。一度にすべてを質問せず、ユーザーがすでに提供した情報に応じて調整してください。

1. 分野： このエージェントが活動する分野は何ですか？（ソフトウェア、マーケティング、セキュリティ、運用、デザインなど）
2. 主な責任： このエージェントが担う最も重要なことは何ですか？
3. 関連する役割： このエージェントは誰と連携しますか？誰から情報を受け取り、誰に成果を渡しますか？
4. 成果物： このエージェントは、どのような具体的な成果物を作成すべきですか？
5. 意思決定の範囲： このエージェントが単独で決定できることは何ですか？何に承認が必要ですか？
6. 制約： このエージェントが従うべき特定のツール、フレームワーク、方法論、標準はありますか？

ユーザーが職務記述書や役割に関する文書を提供した場合：質問するのではなく、その文書から回答を抽出してください。

出力：7 つの構成要素からなる定義を作成するのに十分な役割コンテキスト。

ステップ 3：役割を調査する

この役割が実務で実際に何をするのかを調査します。以下に焦点を当ててください。

• この役割に就く人が日々作成する成果物は何ですか？
• この分野を特徴づけるフレームワーク、方法論、ツールは何ですか？
• この役割でよくある失敗パターンは何ですか？
• 15 年の経験を持つ実務者が使う語彙は何ですか？

ウェブ検索が利用でき、分野になじみがない場合：用語やフレームワークを検証するために検索してください。

役割が広く知られている場合（例：ソフトウェアアーキテクト、プロダクトマネージャー）：確立された分野の知識を活用してください。

出力：7 つすべての構成要素を埋めるのに十分な役割調査。

ステップ 4：7 つの構成要素からなる定義を作成する

./schemas/agent-definition.md で指定された形式に従って、各構成要素を順番に作成します。

4a. 役割のアイデンティティ（約 20～50 トークン）

次の形式を使って、簡潔なアイデンティティ文を作成します。

You are a [real job title] responsible for [primary responsibility] within [organizational context]. You report to [authority] and collaborate with [adjacent roles].

ルール：

• 実在する組織で使われている職名を使用します。
• 報告関係と連携の状況を含めます。
• 50 トークン未満にします。トークン数を数えてください。
• お世辞は禁止です。最上級表現は禁止です。品質を誇示する表現は禁止です。
• エージェントがどれだけ優れているかではなく、知識と行動によって定義します。

4b. 分野の語彙ペイロード（15～30 用語）

3～8 個の関連用語からなる 3～5 つのクラスターに整理し、正確な用語を選びます。

ルール：

• すべての用語が「15 年の経験を持つ実務者」の基準を満たす必要があります。
• 該当する場合は、フレームワークの考案者を含めます：「INVEST 基準（Bill Wake）」。
• コンサルタント調の表現は禁止です。使用禁止の用語：「ベストプラクティス」「活用」「相乗効果」「パラダイムシフト」「全体論的」「堅牢」「合理化」「最適化」。
• 知識の近さに基づいてグループ化します。専門家の議論で同時に使われる用語は、同じクラスターにまとめます。
• 各クラスターには、そのサブドメインを示す名前を付けます。

4c. 成果物とアーティファクト

このエージェントが作成する具体的なアーティファクトを 3～6 個挙げます。

ルール：

• アーティファクトの種類を正確に示します。「文書」ではなく、「アーキテクチャ決定記録」とします。
• セクション、構成、長さの目安など、形式を説明します。
• 各成果物は検証可能でなければなりません。正しく作成されたかどうかを確認できるものにします。
• 「この人は工程の次の人に何を渡すのか？」と問いかけてください。

4d. 意思決定権限と境界

次の 3 つのカテゴリーを定義します。

• 自律的に決定すること： このエージェントが確認を求めずに決めること。
• エスカレーションすること： 人間の承認、または別のエージェントからの入力が必要な決定。
• 対象外： このエージェントが明示的に担当しないこと。

ルール：

• チーム向けに作成する場合は、他のチームメンバーと照らし合わせ、役割の重複を防ぎます。
• 「対象外」は重要です。このエージェントがどこまでを担当するかを定めます。
• エスカレーションの条件は、曖昧な表現（「判断に迷った場合」など）ではなく、具体的にします。

4e. 標準作業手順

明示的な条件を含む、命令形で順序立てられた手順を記述します。

ルール：

• 各ステップは命令形の動詞で始めます。
• 条件には明示的な IF/THEN 分岐を使います。
• 出力を生成するステップには OUTPUT 行を含めます。
• ステップは実行順に並べます。
• 自明でないステップには WHY を含めます。
• 通常は 4～8 ステップです。少なすぎると抽象的になり、多すぎると過剰な管理になります。

4f. アンチパターンのウォッチリスト（5〜10パターン）

この役割に固有の失敗モードを、検出シグナルとともに具体的に示します。

ルール：

• Forge のウォッチリスト（./references/failure-modes.md）、実在する MAST のモード、または該当する場合は分野の文献にある名称を使用します。
• 検出シグナルは、推測に頼らず観察できるものにします。
• 各パターンに具体的な解決策を含めます。「注意する」ではなく、「代わりに X を行う」と記述します。
• 役割固有のパターンを少なくとも1つ含めます（一般的なエージェントの失敗だけにしないでください）。

4g. インタラクションモデル

このエージェントのコミュニケーション方法を定義します。

• 受け取るもの： [役割] -> [成果物の種類]
• 引き渡すもの： [役割] -> [成果物の種類]
• 引き渡し形式： 成果物の受け渡し方法。
• 連携方式： 集中型、ピアツーピア、または順次パイプライン。

ルール：

• 単独で動作するエージェント（チームなし）の場合は、ユーザーとのインタラクションパターンを記述します。
• 引き渡し形式は、送信者と受信者が同じ構造を想定できるほど具体的にします。

出力：エージェント定義の7つのコンポーネントをすべて記載します。

ステップ5：ペルソナを検証する

ペルソナ設計の知見と最新モデルのガイダンスに照らして、定義全体を確認します。

1. トークン数の確認（Forge の規約）： 役割の説明は約20〜50トークンに収まっていますか。収まらない場合は、短くしてください。
2. お世辞の確認（スタイル規約）： 最上級表現や品質に関する主張はありませんか。見つかった場合は削除します。
3. 役割とタスクの適合性： 職務名は主な成果物と一致していますか。一致しない場合は調整します。
4. 語彙の検証： すべての用語は、実務経験15年の専門家にも通じますか。基準を満たさない用語は置き換えます。
5. アンチパターンの確認： このスキルのアンチパターンのウォッチリストに照らして定義を確認します。一致するものがあれば修正します。
6. 推論の反響の確認： エージェントに内部推論や思考の連鎖を明かす、書き起こす、または繰り返すよう指示する SOP の手順はありませんか。見つかった場合は、結論と簡潔な理由を求める表現に置き換えます。

出力：検証済みのエージェント定義。

ステップ6：ライブラリのメタデータを追加する

YAML フロントマターを追加します。

---
name: kebab-case-name
domain: [primary domain]
tags: [3-10 searchable keywords]
created: [today's date]
quality: untested
source: [manual | jit-generated | template-derived]
---

ルール：

• name はケバブケースにし、ファイル名と一致させます。
• 新しいエージェントの quality は untested にします。
• source は、ユーザーが指定した場合は manual、その場で作成した場合は jit-generated、既存のエージェントを基にした場合は template-derived にします。

ステップ7：保存して引き渡す

環境が Claude Code の場合：

• .claude/agents/{name}.md に保存します。
• ライブラリのインデックスがあれば更新します。

環境が Cowork または会話形式の場合：

• 完全なエージェント定義を回答内に提示します。
• 指定された場所への保存を提案します。

Mission Planner からエージェントを依頼された場合：

• チーム編成のため、定義を Mission Planner に返します。
• 引き渡す成果物のメタデータを含めます。

出力：引き渡し済みのエージェント定義。

---

出力形式

出力は、./schemas/agent-definition.md に従った、エージェント定義を完全に記述した Markdown ファイルです。ファイルには次の内容を含めます。

1. ライブラリのメタデータを含む YAML フロントマター
2. 7つの番号付きセクション（役割の説明、ドメインの語彙、成果物、意思決定権限、SOP、アンチパターン、インタラクションモデル）
3. 各セクションはスキーマで指定された形式に従います。

注釈付きの完全な例については、./references/agent-template.md を参照してください。

---

例

例 1：役割のアイデンティティ

悪い例：

あなたは、ユーザーに愛される製品を生み出す比類のない専門知識を持つ、世界を代表するプロダクトマネージャーです。常に正しい判断を下し、ユーザーのニーズを理解する並外れた能力を備えています。

問題点：お世辞が42トークンあります。「世界を代表する」は、範囲に関する情報のない品質の主張です。「常に正しい判断を下す」は絶対的な表現です。「並外れた能力」も品質の主張です。組織的な背景がありません。協業の境界もありません。

良い例：

あなたは、B2B SaaS のプロダクトチームで要件と成功指標の定義を担当するプロダクトマネージャーです。プロダクト担当バイスプレジデントに報告し、エンジニアリング、デザイン、営業の各チームと協力します。

効果がある理由：実際の職種名です。主な責務が明示されています。組織的な背景（B2B SaaS）があります。報告先と協業相手によって境界が明確になります。35トークンです。お世辞はありません。

例 2：専門領域の語彙

悪い例：

ベストプラクティス、ステークホルダーの足並みをそろえる、戦略的ビジョン、革新的なソリューション、相乗効果の活用、成果の推進、ソートリーダーシップ、全体論的なアプローチ

問題点：どの用語も「15年の実務経験がある人」の基準を満たしません。同業者に「相乗効果を活用する」と言うシニアプロダクトマネージャーはいません。これはコンサルタント用語です。そこから抜け出す道ではなく、配送センターです。フレームワークの出典もありません。サブドメインごとの分類もありません。

良い例：

ディスカバリーと優先順位付け： PRD の構成、RICE 優先順位付け（Intercom）、Jobs-to-be-Done（Christensen）、機会ソリューションツリー（Teresa Torres）、仮説マッピング 実行フレームワーク： ユーザーストーリーマッピング（Jeff Patton）、INVEST 基準（Bill Wake）、受け入れ基準、完了の定義、スプリント目標 測定： OKR との整合性、North Star 指標、アクティベーション率、リテンションコホート、プロダクトマーケットフィットスコア（Sean Ellis）

効果がある理由：3つの明確なクラスターがあります。すべての用語が「15年の実務経験がある人」の基準を満たします。フレームワークの提唱者が明記されています。コンサルタント用語はありません。25個の正確な用語により、出力をプロダクトマネジメント特有の語彙と枠組みに導きます。

---

このスキルが答える質問

• 「[役割／専門領域]向けのエージェントを作成して」
• 「[職種名]のエージェントが必要です」
• 「[役割]のペルソナを定義して」
• 「プロダクトマネージャー／エンジニア／デザイナーなどを作って」
• 「[役割]のエージェントはどんなものにすればいい？」
• 「優れたエージェント定義を作るにはどうすればいい？」
• 「[特定のタスク]向けの AI アシスタントを作って」
• 「[専門領域]についてサポートが必要です。エージェントを作成して」
• 「この役割の説明をエージェントにして」
• 「自分のプロジェクト用に特化したエージェントを作成して」
• 「自分のエージェント定義のどこが問題？」
• 「このエージェントのペルソナを改善して」

---

参考資料

• ./schemas/agent-definition.md — 7つのコンポーネント形式の仕様
• ./references/persona-science.md — 役割のアイデンティティに関する根拠と設計規約（整合性と正確性のトレードオフ、長さ、役割とタスクの適合性）
• ./references/agent-template.md — 注釈付きのゴールドスタンダードなエージェントの例
• ./references/failure-modes.md — MAST の失敗割合と、Agent Creator が防止できる Forge の監視項目