効果的なガバナンスは、ツールとそのパラメータの正確かつ明確で、不足のない説明に依存します。エージェント型システム（エージェント自体やセマンティック ガバナンス ポリシーなどのガバナンス レイヤを含む）は、利用可能なツールの適用可能性を理解するために、人間よりも詳細な情報を必要とします。
ツール説明を最適化する
MCP ツールの明確な説明と、それらのツールに必要なパラメータの明確な説明を使用します。
- 不十分なツール説明: 「アイテムを検索します。」
- 効果的なツールの説明: 「キーワード、出演者、ジャンル、形式でコンテンツ カタログを検索します。ユーザーが利用可能な映画やテレビ番組を確認したいときに使用します。関連性で並べ替えられた上位 10 個のアイテムを返します。」
説明文の制限に注意する
セマンティック ガバナンス システムでは、説明の長さの上限が次のように適用されます。
| 説明項目 | 対象 | 長さの上限 |
|---|---|---|
| ツール | MCP サーバー、またはその他のツール公開エンティティ | 1,000 文字 |
| 操作 | MCP サーバー内の個々のツール、またはエージェントが使用できる関数呼び出し | 750 文字 |
| パラメータ | ツールまたは関数呼び出し内で使用されるパラメータ | 300 文字 |
Semantic Governance ランタイムがこれらの制限を超える説明を受け取ると、説明を制限値まで切り捨て、メッセージをログに記録します。
セマンティック ガバナンス ポリシーが介入するタイミング
セマンティック ガバナンス ポリシーは、提案されたツール呼び出しに対するランタイム セキュリティ チェックとして機能します。ブレインストーミング、計画、推論の際に、ユーザーとエージェントの LLM との間で複数ターンの標準的な会話のやり取りを傍受、ブロック、変更することはありません。ポリシー エンジンは、モデルがアクションを実行するためにツールの呼び出しを提案したときにのみ、リクエストをインターセプトして評価します。
シナリオ 1: 会話の絞り込みとツール実行（ツール呼び出しが拒否された場合）
initiate_marketing_campaign ツールがあり、次の制約に則って制御されるエージェントについて考えてみましょう。
- 制約: 「明示的な管理者の承認なしにマーケティング キャンペーンを作成または開始することを禁止します。」
- 会話プランニング: ユーザーがエージェントに「新しい秋の製品の発売に向けたマルチチャネル マーケティング キャンペーンの設計を手伝って」と依頼します。LLM は、複数のターンにわたってユーザーと自由に会話しながら、戦略の概要を説明したり、メールのコピーを作成したり、ターゲット ユーザー層を絞り込んだりします。モデルはアクションを提案するのではなく、会話の推論を行っているため、ポリシー エンジンはこれらのターンをブロックまたは拒否しません。
ツールの呼び出し: 戦略が確定したら、ユーザーが「これでいいので、今すぐマーケティング キャンペーンを開始してください」と発言します。LLM は、提案されたツール呼び出しを生成して応答します。
initiate_marketing_campaign(campaign_name="Fall Launch", budget=50000)ポリシーの介入と拒否: Agent Gateway は、提案されたツール呼び出しをインターセプトして、ポリシー エンジンに転送します。ポリシー エンジンは、制約に対してアクションを評価し、セッション履歴にマネージャーの承認がないと判断して、
DENYの判定を発行します。ツール呼び出しは実行前にブロックされ、構造化された拒否の理由がエージェントに返されます。
シナリオ 2: 準拠したツールの実行（許可されたツール呼び出し）
適切な監督権限が文書化された後、同じマーケティング エージェントを検討します。
- 承認済み: ユーザーが「私のマネージャーである企業マーケティング担当 VP（jordan@example.com）がブリーフを確認し、秋のリリース キャンペーンの予算として 50,000 ドルを承認しました。開始してください。」
ツールの呼び出し: LLM はアクションの呼び出しを提案します。
initiate_marketing_campaign(campaign_name="Fall Launch", budget=50000, approval="jordan@example.com")ポリシーの評価と承認: ポリシー エンジンがツール呼び出しをインターセプトし、会話ターンの履歴内で管理者の承認が記録されていることを確認して、
ALLOW判定を発行します。Agent Gateway は呼び出しを基盤となるツール エンドポイントに転送し、アクションが正常に続行されるようにします。
有効な制約の例
適切な制約は、曖昧さを排除し、正確な制限（財務、時間、地理的）を指定し、エージェントが使用しているツールに一致する言語を使用します。
IT クラウド インフラストラクチャ（セキュリティと費用管理）
- シナリオ: テスト環境。
- ツール:
provision_cloud_server（パラメータ:region、instance_type、duration_hours）。 - ツールの説明: 特定のインスタンス タイプを使用して、特定のリージョンにクラウド サーバーをプロビジョニングするリクエストを送信し、指定された期間にわたって永続化します。
- 有効な制約: 「クラウド サーバーのプロビジョニングは us-east リージョンまたは eu-west リージョンでのみ許可します。「gpu-large」または「gpu-xlarge」インスタンス タイプのプロビジョニング リクエストを拒否します。duration_hours パラメータは最大 72 時間に制限します。」
- 効果的な理由: ツール説明に沿った言葉を使用し、ツールで受け入れられるパラメータを具体的に参照しています。
e コマースのカスタマー サービス（財務上のガードレール）
- シナリオ: アカウント クレジットを発行する。
- ツール:
apply_account_credit（パラメータ:account_id、credit_amount、reason_category）。 - 有効な制約: 「アカウント クレジットを 1 回のインタラクションあたり最大 50 ドルに制限します。理由カテゴリが「shipping_delay」で、元の注文日が 5 日前より新しい場合は、クレジットを適用しないでください。」
- 効果: 厳格な金額のしきい値を設定し、時間とカテゴリに基づく論理条件と組み合わせます。
有効でない制約の例
制約が不適切な場合、通常は曖昧で、主観的な表現が使用されているか、ツールやツール パラメータの説明に直接マッピングされていません。
IT クラウド インフラストラクチャ（主観的）
- 効果のない制約: 「費用が高すぎるサーバーを作成しないようにしてください。期間は妥当な長さにしてください。」
- 失敗する理由: LLM は、「妥当」や「高額」などの抽象的な概念よりも、具体的な数値（「50 ドルの上限」など）の方が得意です。
カスタマー サービス（用語の不一致）
- 無効な制約: 「通常の営業時間外に怒っている買い物客に返金しないでください。」
- 失敗する理由: 「Give money back」はツール パラメータ（
refund_amount）と一致しません。「Angry shoppers」は主観的であり、「営業時間」はタイムゾーンが指定されていないため未定義です。
言語に関するガイダンス
制約を作成する際は、以下のガイドラインに従ってください。
- 平易な言葉を使用する: 宣言文または命令文の完全な文を使用します（例: 「許可してはならない」または「許可しない」）。
- 弱い表現を避ける: 「～するのが最善だと思います」や「～しないようにしてください」などの表現は避けます。LLM 判定では言い回しが重要です。
- 具体的にする: 制限を直接指定して制約を指定します（例: 「$1,000」、「午前 8 時～午後 4 時（東部標準時）」）。ツールとパラメータの説明に沿った表現を使用します。
- 矛盾を回避する: エージェント スコープとツール スコープの制約が競合しないようにします（たとえば、異なる金額のしきい値など）。
制約のテスト: ドライラン モードを使用して、自然言語の制約をテストできます。ドライラン モードでは、ポリシーが適用されることなく評価されます。
次のステップ
- スキルを管理する方法については、エージェントのスキルを管理するをご覧ください。
- セマンティック ガバナンス ポリシーに認可を委任するで、ポリシーをゲートウェイの下り（外向き）にバインドする方法を確認する。
- セマンティック ガバナンス ポリシーを構成するでポリシーを構成します。