最初のエージェント・ワークフローは、1つのプロンプトといくつかのツールから始まります。質問に答え、注文状況を確認する。それでうまくいくので、そのままリリースします。
しかし、プロダクトは成長します。営業からは会議メモを同期するCRM更新機能が求められ、サポートからは3つの内部システムに触れる返金ワークフローが求められます。エンジニアリングからはベンダーのフォームを入力するためのブラウザ操作が追加されます。一つひとつのリクエストは小さく見えます。それぞれが独自のプロンプトファイル、独自のSlackスレッド、独自の「クイック修正」を持ちます。6ヶ月後、あなたのエージェントはもはや単一のシステムではなくなっています。それは、コピーされたプロンプト、隠れたビジネスルール、そして誰も見つけられない古いチャットスレッド内の決定事項が散乱した塊となります。これが「プロンプトの乱立（prompt sprawl）」です。これにより、AIプロダクトのテストやレビューが困難になり、自信を持ってロールバックすることも不可能になります。
解決策は、「AIエージェント・スキル・レジストリ」です。
スキルとは実際には何なのか
スキルとは、フォルダに保存された単なるプロンプトではありません。それは、エージェントが何を行うか、どのツールを呼び出せるか、そして何を決して行ってはならないかを定義する、バージョン管理されたテスト可能なパッケージです。チームとマシンの間の「契約」だと考えてください。エージェントがスキルをロードするとき、自身の境界線がどこにあるのか、そして何をもって成功とするのかを正確に把握している必要があります。
この構造がなければ、すべてのプロンプトが、宣言されていない小さな本番用システムになってしまいます。それらは、誰も追跡していない隠れた権限、埋め込まれたビジネスルール、そしてコストへの影響を伴います。プロダクトのロードマップが前進する一方でプロンプトが取り残されるため、実際のプロダクトから乖離していきます。最悪なのは、それがコピーされることです。誰かがデモのためにフォークしたり、新しいマイクロサービスに貼り付けたりすると、暗闇の中で乖離していく2つの「信頼できる情報源（source of truth）」が生まれてしまいます。
なぜプロンプトだけでは破綻するのか
プロンプトはテキストに見えるため、チームはそれを設定（configuration）のように扱います。しかし実際には、誰も認めたがらないほど、それはコードに近いものです。本番環境のプロンプトには、通常、シーケンシング、フォーマット、エラーハンドリング、アクセス制御に関するロジックがエンコードされています。そのロジックが自然言語の中にしか存在しない場合、曖昧さが生じます。エージェントにはCRMを更新する権限があるのか、それともプロンプトが単にそれを提案しただけなのか？ 請求APIがダウンした場合、プロンプトは安全に失敗する方法を知っているのか、それとも成功メッセージをハルシネーション（幻覚）してしまうのか？
コストもまた、静かな殺し屋です。「ステップバイステップで考え、広範囲に検索して」とエージェントに指示するプロンプトは、実行のたびに大量のトークンを消費する可能性があります。そのプロンプトが高トラフィックなサポートフローにコピーされると、月間の推論コストが倍増しても、誰もその理由を知ることができません。
ビジネスが変化したのにテキストが変化しないとき、ドリフトが発生します。例えば、返金ポリシーに一定のしきい値を超える場合のマネージャー承認が必要になったとします。もしそのルールがポリシー層ではなくプロンプトの中に存在しているなら、更新が必要なコピーを探すために、すべてのデプロイメントを調査しなければなりません。一つでも見落とせば、エージェントが支払うべきでないお金を払い出してしまうことになります。
本番用スキルの構成要素
この混乱から抜け出したいのであれば、すべてのスキルをソフトウェア・アーティファクトとして扱ってください。有用な本番用スキルには、単なるテキスト以上のものが必要です。以下が必要となります：
- 名前と目的。 「prompt_v3_final」ではなく、ビジネス目標を明確に説明した「process_standard_refund」のような名前。
- 入力スキーマと必要なコンテキスト。 スキルが期待する正確なフィールドを定義します。ユーザーID、会話履歴、テナント識別子が必要ですか？ ここで強力な型付け（strong typing）を行うことで、エージェントによる勝手な推測を防ぎます。
- ツールの権限と安全制限。 スキルが呼び出せるツールを明示的にリストアップします。リトライ、支出制限、レート制限（rate caps）にガードレールを設定します。もしスキルがユーザー削除APIに触れてはならない場合は、散文（prose）だけでなくコードで明示してください。
- 成功基準とテストケース。 スキルは、単に実行できたからといって「動作している」わけではありません。出力に何が含まれているべきかを定義します。返金スキルの場合、成功とは、検証済みのトランザクションレコード、送信されたメール確認、および作成された監査ログのエントリを意味するかもしれません。
- バージョン履歴と所有者。 誰かがこれを管理する必要があります。変更履歴（changelog）には、なぜ v2.3 が存在するのか、v2.2 で何が壊れたのかを説明すべきです。
レイヤーを分離する
チームが犯す最大のミスは、すべてを1つのプロンプトに詰め込むことです。親しみやすいガイダンス、ツールのドキュメント、セキュリティポリシー、エラーハンドリングを、テキストの壁の中に混ぜ合わせてしまいます。これではメンテナンスできません。
分離しましょう：
- Instructions はエージェントへのガイダンスです。トーン、フォーマット、および全体的なアプローチを説明します。
- Tool Rules は、どのツールが存在し、何をするのかをエージェントに伝えます。これは発見のためのものであり、許可を与えるものではありません。
- Policy は、期待ではなくコードによって強制されます。例えば、500ドルを超える返金に二重チェックが必要な場合、そのチェックはツールが呼び出される前に実行されるバリデーション関数内に存在すべきです。
- Evals は、変更後もスキルが機能し続けていることを証明するためのテストです。
例えば、「顧客のクレジットカード番号の全桁を絶対に公開しないでください」と書くのではなく、エージェントがそれを見る前にPAN（カード番号）を匿名化するデータフォーマッタを構築してください。巧妙なユーザー入力によってコードにその役割を放棄させることはできないため、ポリシーはコードに組み込むべきなのです。
本番環境で「Latest」を指定するのをやめよう
サイレントなプロンプトの更新ほど、金曜日の夜を台無しにするものはありません。もし本番環境のエージェントが常にスキルの「latest」バージョンを取得しているなら、mainへのすべてのマージが潜在的な本番障害につながります。dev、staging、prod といったエイリアスが必要です。検証済みの既知のバージョンを、これらのステージを通じて昇格（promote）させてください。prod が v2.1.4 を指しているとき、その動作を監視し、挙動を測定し、安心して眠ることができます。何か問題が発生したら、エイリアスを戻すだけです。プレッシャーのかかる深夜に、自然言語のデバッグをする必要はありません。
この規律は、チームに後方互換性について考えさせることにもつながります。v2.2 は v2.1 と同じ入力形式を処理できますか？ もしできないなら、昇格は staging で失敗し、顧客に気づかれる前に問題を特定できます。
セキュリティはパッケージの中から始まる
未監査のプロンプトでいっぱいのレジストリは、脆弱性の温床です。コードで行うのと同じように、スキルに対してもリスクスキャンを行う必要があります。
プロンプトテンプレートに埋め込まれたハードコードされたシークレットやAPIキーを探してください。データを外部に流出させる外部ウェブフックやシェルコマンドがないか確認してください。「ignore previous instructions（これまでの指示を無視して）」といった内容や、エージェント自身の構成を明かすよう求めるプロンプトなど、システムポリシーを上書きしようとする試みに注意してください。これらは単なる理論上の話ではありません。プロンプトインジェクション攻撃における一般的なパターンであり、誰もレビューしていないコピーされたテキストに紛れ込んでいることが多いため、非常に危険です。
スキルパッケージに対して静的解析を実行してください。スキルファイルに許可リスト（allowlist）にないURLが含まれている場合は、ビルドを失敗させてください。承認されたマニフェストに含まれていないツールを参照している場合は、拒否してください。
テストできないものは、信頼できない
評価（evaluations）のないレジストリは、単なるプロンプトのフォルダに過ぎません。各スキルには、ハッピーパス（正常系）、エッジケース（境界値）、および失敗モードを検証するテストセットが必要です。高リスクなスキルには、機能テスト以上のものが必要です。エージェントが他のユーザーのデータを見ることができないよう、権限の境界を調査する必要があります。ポリシーによってアクションがブロックされたときに、正しく「拒否」するかを確認するための拒否動作チェックが必要です。また、敵対的な入力がコードレベルの保護をバイパスしないことを検証するために、プロンプトインジェクション耐性テストが必要です。
テストには明示的な名前を付けてください。「refund_skill_rejects_negative_amount」という名前のテストは、次に担当するエンジニアに、どの挙動が保護されているかを正確に伝えます。バージョンの昇格中にテストが失敗したとき、その候補ビルドが安全ではないという確実な証拠が得られます。
真の目標はコントロールである
再利用性は素晴らしいものですが、あなたの雇用を守るのはコントロール（制御）です。スキルレジストリがあれば、チームは確信を持って次のように言えます。「これが承認されたワークフローです。これが本番環境で実行されているバージョンです。これらが使用可能なツールです。そして、これが正確なロールバック手順です。」
その明快さによって、「巧妙なデモをリリースする」段階から「信頼できるソフトウェアを運用する」段階へと移行できます。デモはステークホルダーを10分間感動させますが、信頼できるソフトウェアは、午前3時でも動作し、例外を適切に処理し、火曜日の午後に誰かがプルリクエストをマージしたからといって挙動が変わることはありません。
レジストリを構築しましょう。スキルにバージョンを付けましょう。ポリシーをコードで強制しましょう。睡眠スケジュールがかかっているかのようにテストしましょう。未来の自分があなたに感謝するはずです。