本記事では、エージェントガバナンスの実装レイヤーとして、Claude in Chromeの権限モード・サイトアクセス制御・管理者設定を公式ドキュメントに基づき整理します。

Claude in Chromeにはどんな権限モードがあるか

Claude in Chromeには手動承認・自動承認・承認スキップの3モードがあり、既定はCowork側で自動承認です。

権限モードは「Manually Approve（手動承認）」「Automatically Approve（自動承認）」「Skip All Approvals（承認スキップ）」の3種類がドロップダウンで選べます。手動承認は操作の都度Allow/Denyを求め、自動承認はClaudeが各操作の安全性を自己審査したうえで実行し、危険と判断したものだけを自動的に止めます。承認スキップは一切確認を行わないモードで、公式ドキュメントも「すべての操作を完全に信頼できる場合のみ」使うよう明記しています。中小企業でまず選ぶべきは自動承認で、ダウンロードや機微情報の入力を伴う操作は、モード設定に関わらず個別の承認を要求されます。

サイトアクセスはどう制御されているか

既定でアダルト・海賊版サイトはブロックされ、金融サイトへのアクセスには追加承認が必須です。

サイトごとの許可には「このアクションのみ許可」という一度きりの許可と、「このサイトでは常に許可」という継続的な許可があります。加えて、株取引や送金などの金融取引はモード設定に関わらず常に禁止され、CAPTCHA回避・顔画像の収集・アカウント作成も同様にブロック対象です。既定のブロックリストはアダルトサイトや海賊版サイトが対象で、業務で使う社内システムやSaaSは対象外のため、そちらのアクセス範囲は自社側で設計する必要があります。

管理者は組織展開をどう制御すべきか

Team/Enterpriseの管理者はallowlistとblocklistで拡張機能のアクセス範囲を組織全体に強制できます。

Team/Enterpriseプランの管理者は、組織全体の有効/無効を切り替えるトグルに加え、ロールごとにClaude in Chromeの利用可否を個別に付与・剥奪できます。この権限はClaude Coworkとは別枠で管理されます。サイト単位では、許可サイトのみに限定するallowlistと特定サイトを遮断するblocklistを組織側で強制でき、公式ドキュメントは初回展開時ほど制限的なallowlistから始めることを推奨しています。専任のIT担当がいない中小企業では、まず経理・人事など機密部署の利用者に絞った限定allowlistでパイロット運用し、問題がないことを確認してから対象を広げる進め方が現実的です。

ZDR非対応をどう運用でカバーするか

Claude in Chromeはゼロデータ保持（ZDR）に対応していないため、機密情報を扱う操作はブラウザプロファイルを分離します。

公式ドキュメントはClaude in ChromeがZDRの対象外であることを明記しており、これはAPI経由の他機能とは異なる制約です。対策として、機微情報を含まない業務専用のブラウザプロファイルを別に用意し、そこにClaude in Chromeを限定してインストールする運用が推奨されています。加えて、確認画面に機密情報が表示された状態で拡張機能のパネルを開かない、初めて使うサイトでは提案されたアクションを毎回目視で確認するといった基本動作も、業務アカウントをブラウザセッションという単一の信頼境界に集約しないための設計です。Kuuのエージェントガバナンス支援（AI Ops）では、こうしたブラウザ拡張の権限設計とallowlist運用を、専任のセキュリティ担当者がいない企業でも維持できる形で組み立てています。

参考

• Use Claude in Chrome safely - Claude Help Center
• Claude in Chrome permissions guide - Claude Help Center
• Claude in Chrome admin controls - Claude Help Center

まとめ

Claude in Chromeは手動承認・自動承認・承認スキップの3モードと、金融取引を一律禁止する固定ルールを備えていますが、業務システムへのアクセス範囲は自社でallowlistを設計する必要があります。中小企業がまず着手すべきは、自動承認モードを基本にしつつ機密部署向けの限定allowlistでパイロット運用を行い、ZDR非対応を前提に業務専用のブラウザプロファイルへ利用を切り分けることです。自社のブラウザ拡張運用やallowlist設計の見直しについては、Kuu株式会社にお問い合わせください。

Browser Use Toolとは何か——Computer Useと何が違うのか

Browser Use Toolはページのアクセシビリティツリーから要素参照を取得し、座標推定に頼らず操作できます。

browser_toolset_20260801は、旧来のスクリーンショット+座標クリック型のComputer Useとは異なるツールセットです。read_pageがアクセシビリティツリーを返し、ref_3のような要素参照でリンクやボタンを直接指定できます。自然言語で要素を探すfindも使えます。既定で有効な27種のメンバーツールに加え、javascript_exec・file_upload・read_console・read_networkの4種は既定で無効です。対応モデルはClaude Opus 5・Sonnet 5・Opus 4.8などで、提供経路はClaude APIとVertex AIに限られ、Bedrock・Foundryは非対応です。

複数アクションはどう1ターンで実行されるのか

1回のレスポンスに複数のtool_useブロックが載り、逐次実行かつ失敗で後続が自動停止します。

Claudeはtoolset_name: "browser"を付けたtool_useブロックを1ターンにまとめて返します。実行系はこれを並列ではなく発行順に逐次実行し、途中で1件でも失敗したら残りは実行せず、is_error: trueと固定文言"Not executed: an earlier action in this turn failed."を返す設計が求められます。この一括実行で往復回数が減り、公開事例では保険金請求フローの処理時間が32分から13分に、タスクあたりコストが約30%短縮しています。バッチの一部失敗は珍しくないため、冪等性設計を前提にリトライ時の重複実行を防ぐ必要があります。

要素参照とタブ状態はどう設計すればよいか

要素参照はDOM変化で失効するため、再取得ロジックと複数タブの状態同期が設計上の要点です。

要素参照は発行元のタブに紐づき、ページ遷移やDOM変化で無効化されます。失効した参照へのアクセスは実行系がエラーを返し、Claude側にread_pageの再実行を促す設計が前提です。キャンバスや動画、クロスオリジンiframeなど参照が取得できない要素には座標指定を併用します。タブ操作の結果はbrowser_stateブロックのみを返し、上限はタブ100件・状態変化200件です。URLはクエリパラメータの認証情報を除去してから返す必要があり、複数タブを横断するタスクではタブごとの参照テーブルを実行系の状態ストアに持たせる設計が安全です。

セキュリティ境界はどう設計すべきか

javascript_execとfile_uploadは既定で無効化されており、有効化には隔離環境の整備が前提です。

セキュリティ設計の起点は、ブラウザを資格情報を持たない専用コンテナで動かし、ネットワーク層でドメインを許可リスト化することです。javascript_execはページと同じ権限でコードを実行するため、戻り値はプロンプトインジェクションの経路になり得る未信頼入力として扱います。file_uploadはアップロード可能なパスを専用ディレクトリに限定し、シンボリックリンクや..を解決してから許可すべきです。javascript:・file:・data:スキームは拒否し、購入や規約同意など不可逆な操作には人間の承認を挟みます。この隔離設計はComputer Use APIのサンドボックス・IAM設計と共通する考え方です。

参考

• Browser use tool – Claude Platform Docs
• Build production agents with computer use, the Skills API, and the Files API – Claude by Anthropic

まとめ

Browser Use Toolは、座標推定から要素参照へ、逐次1アクションからバッチ実行へと、画面操作エージェントの実行モデルそのものを変える機能です。往復回数の削減はコストとレイテンシに直結する一方、失敗時のhalt-on-failure処理・参照の再取得・タブ状態の同期・javascript_execやfile_uploadの権限境界を、実行系の設計として作り込む必要があります。既存のComputer Use基盤を持つ企業ほど移行設計の見直し範囲は大きくなります。

エージェント実行基盤のアーキテクチャ設計は、Kuu株式会社のRDEサービスでご相談ください。

本記事では、このToken Counting APIの仕組みと、レート制限・コスト管理への組み込み方を整理する。

Claude Token Counting APIとは何か

count_tokensエンドポイントは無料でメッセージのトークン数を事前算出できる仕組みだ。

POST /v1/messages/count_tokensは、Messages APIと同じ構造化された入力（system・messages・tools・images・documents・thinking）を受け取り、実際に推論せずinput_tokensの値だけを返す。利用に課金は発生せず、利用階層（Start/Build/Scale）ごとにそれぞれ5,000/10,000/20,000 RPMの専用レート制限が設定されている。この制限はMessages APIの消費枠とは独立しており、事前カウントを多用してもメッセージ作成側のレート制限は減らない。

count_tokensは何を数え、何を数えないのか

画像・PDF・ツール定義・thinkingブロックは数えるが、キャッシュ済みトークンは数え方が異なる。

ツール定義・画像・PDF・extended thinkingのブロックはいずれもカウント対象になる。ただし細かい挙動には注意点がある。サーバーツール（Web検索やコード実行など）のトークン数は最初のサンプリング呼び出し分のみが対象になる。thinkingブロックは、モデルが前ターンのthinkingを保持する仕様であれば過去ターン分もカウントされ、保持しない仕様のモデルではAPI側で取り除かれカウントされない。またToken Counting APIはキャッシュロジックを使わずに見積もるため、リクエストにcache_controlを含めても実際のキャッシュ効果は反映されない——プロンプトキャッシングの効果測定には使えない点は覚えておきたい。返る数値はあくまで推定値で、実際にメッセージを作成した際の入力トークン数と小さくずれることがある。Anthropicが自動付加するシステム最適化用トークンは課金対象外だ。

なぜモデル移行時にトークン数を数え直すべきか

Claude Opus 4.7以降で導入された新トークナイザは、同じ入力でも旧モデル比で約30%多くカウントする。

Claude Fable 5.1・Claude Mythos 5.1・Claude Fable 5・Claude Mythos 5は、Claude Opus 4.7で導入されたトークナイザを共有しており、同じプロンプトでもOpus 4.7より前のモデルに比べておよそ30%多いトークン数になる（増加率はコンテンツの種類によって変動する）。課金・コンテキストウィンドウ消費もこの新トークナイザのカウントに従う。旧モデルで計測したトークン数を移行後のコスト試算やコンテキスト適合判断にそのまま流用してはならず、移行先のmodel IDを指定してcount_tokensを実行し、数え直す必要がある。長文脈設計の詳細は長文脈モデルの活用設計も参照してほしい。

レート制限・コスト管理にどう活かすか

送信前にcount_tokensでITPM消費量を見積もれば、429エラーやコンテキスト超過を未然に防げる。

実装パターンは大きく3つある。第一に、大量のバッチ送信やループ処理の直前に合計トークン数を見積もり、Messages APIのITPM（入力トークン/分）制限に対する消費割合を計算してスロットリングをかける。第二に、見積もったトークン数でコンテキストウィンドウの残量を判断し、超過しそうな会話履歴を要約・切り詰めてから送信する。第三に、モデルルーティングの判断材料にする——小さいプロンプトは廉価モデルへ、大きい・複雑なプロンプトは上位モデルへ振り分ける閾値として使う。バッチ処理でのコスト削減はBatch API実装手順、部門別のコスト計装はAI FinOps入門を参照。Token Counting API自体は無料なので、これらのチェックをリクエストのたびに呼び出しても追加コストは発生しない。

規模別の留意点（SMB / エンタープライズ）

SMBでは、月次のAPI費用が想定を超えないよう、バッチ送信スクリプトの先頭にcount_tokensでの見積もりとしきい値チェックを1行加えるだけで、想定外の高額請求を早期に検知できる。エンタープライズでは、LLMゲートウェイやFinOpsパイプラインに事前カウントを組み込み、部門・チーム単位の予算枠に対してリクエスト送信前にブロックする仕組みへ発展させられる。組織横断のコスト統制・ゲートウェイ設計が必要な場合はKuuの高度化支援サービス（RDE）が対応する。

トークンコスト管理や運用設計のご相談はKuuの運用管理サービス（AI Ops）からお問い合わせください。

参考

• Token counting（公式ドキュメント）
• Rate limits（公式ドキュメント）
• Count tokens in a Message - API Reference（公式ドキュメント）

まとめ

Token Counting APIは無料かつMessages APIとは独立したレート制限を持つため、送信前チェックとして気軽に組み込める。特にClaude Opus 4.7以降のトークナイザ変更で数え方自体が変わっている点は、モデル移行時のコスト試算を誤らせやすい落とし穴だ。レート制限超過・コンテキスト超過・想定外コストのいずれも、送信前の1回の見積もりで防げる範囲は大きい。

エージェントガバナンスの観点では、モデル性能の向上に伴って監視要件も強化される。Anthropicが2026年9月に発表したEnterprise Frontier Safeguards（EFS）は、この矛盾を「監視データの保存場所」で解く技術的アプローチだ。仕組みと導入時の論点を整理する。

なぜCovered Modelsはゼロ保持できないのか

一部の誤用は単発のリクエストでは検知できず、複数リクエストの蓄積でしか見えないため保持期間を伴う監視が必須になる。

Anthropicは、従来世代から性能が大きく引き上がり誤用リスクも高いモデルを「Covered Models」に指定している。現行ではClaude Mythos 5/5.1とClaude Fable 5/5.1が該当し、Claude本体・Amazon Bedrock・Google Cloud・Microsoft Foundry・一部パートナープログラムを問わず適用される。公式サポート記事は、Covered Modelsが保持データを要求する理由を「一部の誤用はリクエスト単体では検知できず、複数リクエストにまたがる形でしか見えない」と説明する。攻撃的サイバー能力や生物兵器転用能力の獲得試行といった深刻な誤用は、単発のプロンプトではなく時系列のパターンとして現れるため、最低30日のデータ保持がデフォルトで課され、Enterpriseワークスペースやサードパーティプラットフォームではゼロ保持自体が選択できない仕様になっている。

EFSは技術的に何を変えるのか

EFSは誤用検知の自動監視を保ったまま、保持データの置き場所を顧客管理下のクラウドストレージへ移す仕組みだ。

EFSの核心は「検知はAnthropic、保管とレビューは顧客」という役割分担にある。公式発表によれば、監視対象のアクティビティデータはAnthropic側のインフラではなく、顧客が管理するAmazon S3・Azure Blob Storage・Google Cloud Storageのアカウントに、顧客が制御する暗号鍵の下で保存される。ストレージの読み書き・転送費用も顧客が自社のクラウド契約で負担する形になり、Anthropicが追加課金する仕組みではない。検知そのものはリアルタイムの安全性分類器とAnthropicの既存の執行システムが引き続き全トラフィックに適用されるが、フラグが立った際の一次判断は顧客のセキュリティチームに渡り、Anthropic従業員による人手レビューを要さない設計になっている。これは、機密性の高い資料を「訓練を受けた社内担当者のみ」がレビューできるという規制要件がある業界を想定した設計だ。

導入判断で確認すべき3点は何か

ロールアウトは2026年秋から段階的で、対象範囲・移行期の扱い・撤回条件の3点を事前確認する必要がある。

EFSはまだ全社一律の一般提供ではなく、フェーズドロールアウトの段階にある。導入検討時に確認すべき論点は3つある。第一に対象範囲で、Claude Code・Claude Enterprise・Claude Platform・Amazon Bedrock・Google Cloud・Microsoft Foundryにまたがるが、自社の利用チャネルが初期フェーズの対象に入っているかは個別確認が要る。第二に移行期の扱いで、EFS提供開始までの間、対象となった既存ZDR契約組織にはFable 5/5.1を社内アプリケーション用途に限定してZDRのまま使える橋渡し措置が用意される——ただし全組織が自動的に対象になるわけではなく、Anthropicからの個別案内か申請フォームでの申し込みが必要になる。第三に撤回条件で、公式ドキュメントはAnthropicが誤用への対応を含めてこの取り決めを変更・撤回し得ると明記しており、EFSは恒久的な契約条項ではなく運用上の枠組みとして設計されている点を、社内のリスク評価プロセスに組み込む必要がある。

規模別の留意点（SMB / エンタープライズ）

Covered Modelsの保持要件はEnterpriseワークスペース・サードパーティプラットフォームに限定され、SMBが主に使うConsole単体のワークスペースでは対象外のケースが多い。SMBはClaude APIのデータ保持ガイドで扱う標準ZDR・Files API・Batch APIの保持期間差分を先に押さえれば十分なことが多い。一方エンタープライズは、Covered Modelsの調達可否を判断する前に、自社の該当ワークロードがEFSの初期ロールアウト対象かどうかをAnthropicの営業チャネル経由で確認し、社内の法務・セキュリティ部門とクラウドストレージ側のアクセス統制設計をあわせて検討する必要がある。大規模なマルチクラウド運用での監視基盤設計は、RDEのような実装支援パートナーとの協働が有効な領域だ。

参考

• Developing Enterprise Frontier Safeguards with our customers
• Covered Models: Overview and Data Retention Policies
• Data retention practices for Covered Models

まとめ

EFSは「監視をやめる」のではなく「監視データの置き場所を顧客管理下に移す」ことでゼロ保持要件と誤用検知を両立させる仕組みだ。Covered Modelsの調達を検討するエンタープライズは、対象範囲・移行期の扱い・撤回条件の3点を自社のガバナンス設計に落とし込む必要がある。Claude APIのデータ保持・監査ログ設計を含めたエージェントガバナンス基盤の構築は、KuuのRDEにご相談ください。

セルフホストサンドボックスは何を解決するのか

セルフホストサンドボックスはツール実行のみを自社インフラに移し、モデル推論はAnthropic側に残す構成である。

エージェントが読み書きするファイルシステム、起動するプロセス、到達できるネットワークはすべて自社の管理下に置かれる一方、ツールの入出力はAnthropicの制御プレーンに送られてモデルが次の行動を判断する。これは、社外に出せないデータを扱う場合や、公開ルーティングされていない内部サービスに到達させたい場合、自社のコンプライアンス統制を適用したい場合に向く構成であり、RDEのような大規模導入で要件になりやすい。

EnvironmentWorkerはどのようにセッションを処理するのか

自社インフラで動くEnvironmentWorkerがキューからセッションを取得し、ツール呼び出しを実行して結果を返す。

self_hosted環境はワークキューとして機能し、セッションが割り当てられると自社のワーカーがそれを取得してスキルをダウンロードし、ツールを実行して結果を投稿する。実装パターンは3種類ある。常時稼働してキューをポーリングし続ける「Always-On」、session.status_run_startedイベントでのみ起動しアイドルポーリングを避ける「Webhook駆動」、セッションごとに隔離されたファイルシステムとリソース制限を持つ「サンドボックス・パー・セッション」だ。認証はClaude APIキーではなく、Consoleでのみ発行できる環境キー（ANTHROPIC_ENVIRONMENT_KEY）で行う。

メモリストアはどうサンドボックス内で同期されるのか

メモリストアは/mnt/memory/配下にローカルコピーとして展開され、既定15秒間隔（最短5秒）で同期される。

クラウドサンドボックスではメモリストアはライブマウントされるが、セルフホスト環境ではSDKのワーカーがツール実行前に各ストアをmount_path（例: /mnt/memory/user-preferences/）にダウンロードし、ローカルコピーとして管理する。同期間隔はmemory_sync_intervalで調整でき、最短5秒まで短縮できる。セッション終了時には最大30秒の最終同期が走る。エージェントがローカルで変更した内容が同期前にストア側でも変更されていた場合、ワーカーはストア側の内容を優先してローカルを上書きし警告を出す設計になっており、read_onlyアクセスで接続したストアには一切アップロードしない。

運用時にどこに注意すべきか

同一ストアを複数セッションで同時マウントできないため、セッションごとのファイルシステム隔離が必須になる。

ホスト上では、同じメモリストアを複数セッションが同時にマウントすることは許されず、サンドボックス・パー・セッション構成での隔離が事実上の前提になる。ワーカーの停止はSIGKILLではなくSIGTERM/SIGINTで行う必要があり、強制終了すると未同期の変更が失われるため/mnt/memory/配下の残存ディレクトリを手動で片付けなければならない。また、AWS上のClaude Platformではセルフホスト環境にメモリストアを接続できないという制約があり、fileやgithub_repositoryリソースも同様に非対応で、指定すると400エラーになる。一方でセルフホストサンドボックスはゼロデータ保持やHIPAA BAAの対象になり得るため、規制業種の導入判断材料になる。

参考

• Self-hosted sandboxes - Claude Platform Docs
• Using agent memory - Claude Platform Docs
• API and data retention - Claude Platform Docs

まとめ

セルフホストサンドボックスは、モデル推論をAnthropicに委ねつつツール実行とデータを自社境界内に留める設計であり、EnvironmentWorkerの実行パターン選択とメモリストアの同期間隔・競合解決の理解が実装の要になる。特にAWS上のClaude Platformでのメモリストア非対応や、強制終了時の後片付けは見落とすと本番障害につながる。自社基盤へのManaged Agents導入設計から運用まで一貫した支援が必要な場合は、Kuuの RDEにご相談ください。

評価基準はなぜ「精度が高い」だけでは足りないか

評価基準はSpecific・Measurable・Achievable・Relevantの4条件を満たす必要があり、倫理性のような曖昧な観点も数値化できます。

Anthropicのガイドラインは、評価基準をSpecific（具体的）・Measurable（測定可能）・Achievable（達成可能）・Relevant（関連性がある）の4条件で設計するよう求めている。「精度の高い応答」のような抽象的な目標は基準にならない。「感情分類の正解率」のように具体化し、「1万トライアル中トキシシティが検出される割合を0.1%未満に抑える」のように、一見数値化しづらい安全性のような観点も定量的な閾値に落とし込む。目標値は業界ベンチマークや過去の実験結果、専門知識を根拠に設定する。

評価基準はどう分類すればよいか

ドキュメントはタスク忠実度・一貫性・関連性・トーン・プライバシー・文脈活用・レイテンシ・コストの8軸を提示し、多くの用途で複数軸の同時評価が必要だとしています。

公式ドキュメントは評価基準を8つのカテゴリに整理する。タスク忠実度（本来のタスクをどれだけ正確にこなすか）、一貫性（似た入力に対する応答の意味的な安定性）、関連性と一貫した構成（ユーザーの問いにどれだけ的確に答えるか）、トーンとスタイル（想定する話し方への一致度）、プライバシー保護（機微情報の扱い）、文脈活用（与えられたコンテキストをどれだけ使いこなすか）、レイテンシ、コストである。多くの業務では単一軸ではなく複数軸を同時に評価する必要があり、カスタマーサポート用エージェントならタスク忠実度とトーン、文書処理エージェントならタスク忠実度とプライバシー保護を組み合わせるといった設計になる。

グレーディング手法はどう選べばよいか

完全一致・コサイン類似度・ROUGE-L・LLM採点の4手法を基準の性質に応じて使い分けると、自動化率を保ったまま精度を確保できます。

基準の性質とグレーディング手法を対応させることが、eval設計の核になる。タスク忠実度のように正解が明確なカテゴリ分類（感情分析の positive/negative/neutral など）には完全一致（文字列比較）が向く。一貫性のように言い換えた入力間の意味的な近さを測るにはコサイン類似度（文埋め込みベースのSBERT等）を使う。関連性と構成のような要約タスクの評価にはROUGE-L（最長共通部分列に基づくF1スコア）が実用的だ。トーンとスタイルのように主観的な質を測る場合はLLMに1〜5段階のLikert評価をさせ、評価対象と異なるモデルを採点役に使うのが公式の推奨である。プライバシー保護のように機微情報の有無を判定する場合はLLMによる二値分類、文脈活用のように順序性のある品質を測る場合はLLMによる順序尺度評価が適する。ドキュメントは「少数の高品質な人手採点より、シグナルがやや弱くても自動グレーディングされた質問を大量に用意する方がよい」と明言しており、可能な限り自動化できる手法を優先すべきだ。

中小企業はどこから着手すべきか

まず1〜2軸に絞り、完全一致など機械的に判定できる基準から着手し、主観的な軸は段階的にLLM採点へ広げるのが現実的です。

複数のグレーディング手法を一度に揃える必要はない。まず自社の業務で最も外してはいけない基準を1〜2軸に絞り、完全一致や正規表現など機械的に判定できるものから着手する。コードでのグレーダー実装に不安がある場合は、Claude ConsoleのEvaluateタブで人手による5段階採点から始め、評価軸ごとの判断基準を明文化する作業を先に済ませておくとよい。基準が固まった段階で、20タスクから始めるeval設計の手順に沿ってコードベースグレーダーへ移行し、主観的な軸だけLLM採点を組み込む。エージェントガバナンスの観点でも、どの基準をどの手法で採点しているかを文書化しておくことが、後からグレーダーの妥当性を検証する際の土台になる。

KuuのAIエージェント運用管理サービス（AI Ops）では、評価基準の設計からグレーダー実装までを一貫して支援している。

参考

• Define success criteria and build evaluations（Claude Platform Docs）
• Evaluate prompts in the developer console（Claude by Anthropic）

まとめ

evalスコアが安定しない原因の多くは、グレーダーの実装ではなく評価基準の設計にある。SMART条件で基準を具体化し、タスク忠実度・一貫性・関連性・トーン・プライバシー・文脈活用・レイテンシ・コストの8軸から自社業務に必要なものを選び、完全一致・コサイン類似度・ROUGE-L・LLM採点という4つの手法を基準の性質に応じて割り当てる——この順序で設計すれば、少ない工数でも意味のあるeval基盤を組める。評価基準の設計から相談したい場合は、KuuのAI Opsまで問い合わせてほしい。

GitHubリポジトリのスキル自動読込とは何か

セッションがリポジトリをマウントすると、ルート直下の.claude/skillsが起動時に一度だけスキャンされ、見つかったスキルはアップロード不要でエージェントから利用可能になります。

Managed Agentsはgithub_repositoryリソースでリポジトリをセッションにマウントする機能を持ちます。このとき、リポジトリの.claude/skills//SKILL.mdという形式に一致するディレクトリがセッション開始時にスキャンされ、Skills APIへの事前アップロードやエージェントのskills配列への登録なしに、発見されたスキルがそのまま利用可能になります。発見はエージェントのreadツール（デフォルト有効）に依存するため、readを無効化したエージェントはリポジトリ内スキルを読み込みません。

なぜ信頼境界の問題になるか

公式ドキュメントは「マウントしたリポジトリはエージェントの信頼境界の一部になる」と明記し、レビュー工程が存在しないことを警告しています。

スキルはSKILL.mdという自然言語の指示ファイルであり、bashやweb_fetchなどのセッションツールと組み合わさることで実際の実行力を持ちます。Anthropicの警告文は、外部からのマージ済みプルリクエスト・侵害された依存関係・悪意あるコントリビューターのいずれもがリポジトリへのコミット権限を通じてスキルを追加・変更できる点、そしてプラットフォームがそれをセッション開始時にレビューなしで読み込む点を明示しています。第三者製スキルの安全性審査（マーケットプレイス経由の配布リスク）とは異なり、この経路は明示的な承認ステップを持たない自動読込である点が固有のリスクです。

発見ルールをどう設計に活かすか

発見対象は.claude/skills/直下1階層のディレクトリのみで、ネストした場所や.claude外のskillsディレクトリは対象外です。

発見ルールには明確な境界があります。.claude/skills/SKILL.mdのようにディレクトリを介さない配置、.claude/skills/tools/code-review/SKILL.mdのように2階層以上ネストした配置、リポジトリのサブディレクトリ内にある.claude/skillsは、いずれもセッション開始時のスキャン対象になりません（ただしエージェントがファイル読み取りで偶然たどり着く可能性は残ります）。また、発見はチェックアウトされたブランチまたはコミット時点の状態に固定され、スキャン自体はセッション開始時の1回のみです。セッション中にリポジトリへ新しいコミットが入っても反映されず、更新されたスキルを使うには新しいセッションを開始する必要があります。この「起動時固定・再スキャンなし」という挙動は、ブランチやコミットをどう指定するかがそのままセキュリティ設計になることを意味します。

運用でどう緩和すべきか

ブランチ・コミット固定によるピン留め、コミット権限の制限、.claude/skillsのコードオーナー指定が主要な緩和策です。

第一に、checkoutパラメータで本番セッションのマウント先をタグ付きコミットやリリースブランチに固定し、mainブランチへの直接反映を避けます。第二に、.claude/skills配下をCODEOWNERSでセキュリティ担当のレビュー必須対象に指定し、外部コントリビューターからのプルリクエストがこのパスを変更する場合は必ず人間の承認を経由させます。第三に、外部コントリビューションを受け付けるリポジトリはそもそもManaged Agentsのマウント対象から外し、社内管理下のリポジトリに限定します。エンタープライズではLLMゲートウェイでのアクセス統制と組み合わせ、どのリポジトリがどのセッションにマウントされたかを監査ログに残す設計が有効です。なお、セルフホストサンドボックスはこのGitHubリポジトリリソース自体をサポートしないため、クラウドサンドボックスを使う組織に限って本設計が必要になります。

参考

• Anthropic Docs: Managed Agents — Skills
• Anthropic Docs: Managed Agents — Accessing GitHub
• Anthropic Docs: Agent Skills — Enterprise

まとめ

GitHubリポジトリからのスキル自動読込は、アップロード作業を省ける一方で、レビューを経ないままエージェントの実行力を変える経路になります。ブランチ・コミットのピン留め、CODEOWNERSによるレビュー強制、マウント対象リポジトリの限定という3点は、機能を無効化せずに信頼境界を保つための現実的な設計です。大規模組織でマルチチームのMCP・スキル・リポジトリ接続を統制する体制構築は、Kuuのサービスページからご相談ください。

本記事はエージェントガバナンスの技術基盤として、コンテキスト圧縮の設計やMid-conversation Tool Changesと合わせて、自前のエージェントハーネスを運用するプラットフォームエンジニア向けに整理する。

Preserved Thinkingとは何か

Preserved Thinkingは蒸留対策の機構で、thinking blockの署名からモデル一致と会話履歴の不変性を検証し、違反時は400エラーまたはブロック破棄を返す。

Claude Fable 5.1以降、thinking・redacted_thinkingブロックのsignatureはAPI側で2点を検証される。1つはモデルの一致で、あるモデルは自分自身と自分より古いモデルが生成したthinking blockしか読めない。Claude Fable 5.1はClaude Opus 5のブロックを読めるが、逆方向は読めず、無言でドロップされる。もう1つはプレフィックスの不変性で、system・tools・それ以前のmessagesのいずれかが変わっていると、そのブロック以降のthinkingがすべて無効になる。

この検証は2026年8月31日以降に作成されたアカウントでデフォルト適用される。それ以前のアカウントでもthinking.block_binding.prefix_mismatch_behaviorを明示すれば同じ検証が働き、Anthropicは将来的に全アカウントへ拡大する方針を示している。今から会話履歴をappend-only（追記専用）に設計しておく必要がある理由はここにある。

なぜ既存の圧縮パターンが壊れるのか

会話履歴の途中を書き換える一般的な圧縮・注入パターンは、Preserved Thinkingの検証対象そのものであり無警告で壊れる。

多くの自前ハーネスが採用してきた次のパターンは、いずれもプレフィックス検証に抵触する。

• Keep-tail圧縮: 古いターンを要約に置き換えつつ直近数ターンを生のまま残す方式。残したアシスタントターンのthinking blockは「要約前の履歴」を前提に生成されているため、要約と入れ替えた瞬間に無効化される
• バックグラウンド圧縮: 要約生成をクリティカルパス外で行い、数リクエスト後に差し替える方式。差し替えが着地する直前までに生成されたthinkingがすべて無効になる
• ターン途中への一時的な指示注入: 「次のメッセージだけ有効なリマインダー」を過去のターンに挿入して後で消す実装。挿入も削除もプレフィックス変更にあたる
• tools配列の直接編集: セッション途中でツール構成を書き換える実装

Append-onlyな設計への置き換え方

過去ターンの編集はすべて専用APIで置き換えられ、messagesは新規ターンの追記のみで運用できる。

Anthropicは編集操作ごとに専用の代替APIを用意している。

• ツールの追加・削除: tools配列は初回リクエストで全候補を宣言し固定する。途中の変更はrole: "system"メッセージにtool_addition/tool_removalブロックを追記して表現する（mid-conversation-tool-changes-2026-07-01）
• エフォート変更: トップレベルのoutput_config.effort書き換えはキャッシュを再構築するだけでthinkingには影響しないが、Claude Fable 5.1では空のcontentを持つsystemメッセージにoutput_configを載せて追記する per-message effort（mid-conversation-output-config-2026-07-01）の方が意図が明確になる
• 新しい指示の追加: 過去ターンを書き換えず、Mid-conversation system messagesとして末尾に追記する。1ターン限りならclear_at: "next_user_message"を付与する
• 古いターンの圧縮: クライアント側で手を入れず、サーバー側のCompactionまたはContext Editing（clear_tool_uses_20250919等）に委ねる。これらはAPIが送信済みの内容と比較して検証するため、サーバー側での要約はプレフィックス違反にならない

例外処理と移行時の確認手順

thinking-binding-controls-2026-08-01ベータヘッダーでprefix_mismatch_behaviorをdrop_blockにすると、違反ブロックのみ課金なしで破棄されinput_transformationsに記録される。

移行を急がずまず現状を可視化したい場合は、prefix_mismatch_behaviorを"drop_block"に設定する。失敗したブロックとそれ以降のthinkingは無課金で破棄され、レスポンスのinput_transformationsにreason: "prefix_binding_mismatch"として記録される。本番導入前に数ターンの通常セッションを走らせ、system・tools・messagesが前リクエストと一致しているかを差分で確認する手順が推奨されている。モデルルーティングやフォールバック構成を持つ基盤では、フォールバック経路ごとにこの検証を行っておくべきだ。LLMゲートウェイでモデル切り替えを一元化している場合、切り替え時にthinkingブロックが破棄される前提でリトライ設計を組み込む必要がある。

参考

• What's new in Claude Fable 5.1
• Preserved thinking
• Mid-conversation system messages

まとめ

Preserved Thinkingは会話履歴の途中書き換えを前提にした実装を今後段階的に締め出す。Keep-tail圧縮やターン途中への指示注入といった従来パターンは、tool_addition/tool_removal・per-message effort・mid-conversation system messages・サーバー側Compactionという専用APIに置き換えることでappend-onlyのまま運用できる。自前のエージェント基盤を持つ企業ほど影響範囲は大きく、モデルルーティングやフォールバック設計と合わせた技術統制が必要になる。設計・運用の相談はKuuの大規模実装支援（RDE）まで。

エージェントガバナンスの一環として、透かしの仕組み・検出APIのアクセス制限・企業が実務で押さえるべき限界を整理する。

Claudeのテキスト透かしはどう動くか

トークン選択時の乱数源を鍵で決定的に置き換え、意味を変えずに検出可能な統計パターンを埋め込む方式だ。

Anthropicが採用する方式はGoogle DeepMindのSynthID-Textに近い。複数の語が同程度に自然な「低リスクな語彙選択」の場面で、通常なら乱数で決める次トークンの選び方を、鍵と直前の数語から導く決定的な値に置き換える。既に妥当な候補の中から鍵に沿った1つを選ぶだけなので、読者から見た自然さは変わらない。事実関係が厳密な文や短い文章は語彙の選択肢が乏しく、透かしの手がかりが薄くなる。

なぜAnthropicは透かしを実装したのか

EU AI Act第50条は2026年8月2日から、AI生成コンテンツを機械可読な形式で識別可能にすることを提供者に義務付けている。

第50条はAIシステムが生成する合成音声・画像・動画・テキストについて、機械可読な形式でAI生成であることをマークし、検出可能にすることを提供者に求める規定だ。Anthropicは同条項の施行に合わせ、EU AI生成コンテンツ透明性行動規範にも署名した。この義務は生成AIベンダー側にかかるものであり、Claude APIを組み込むだけの利用企業に直接の実装義務が生じるわけではない点は区別して理解しておきたい。

検出APIは誰が使えるのか

検出APIは現在プライベートプレビューで、規制当局・法執行機関・報道機関・研究者などEU法上の対象組織に限定されている。

透かしの有無を判定する検出APIは、一般公開されていない。現時点でアクセスできるのは規制当局、法執行機関、報道機関、ファクトチェック団体、研究者、教育機関、市民社会団体、そしてAI Act遵守のために検証義務を負う企業に限られる。Anthropicは今後段階的にアクセス範囲を広げる方針を示しているが、自社サービスの出力にClaude生成テキストが混在しているかを社内で自由に検証できる状態にはまだない。

企業はこの仕組みにどう向き合うべきか

透かしは「Claudeが関与した可能性」を示すのみで、人間による全面書き換えや他モデルの併用までは判別できない。

文章の一部を軽く編集した程度なら検出性は保たれるが、全文を書き直せば透かしは失われる。また透かしが示すのは「Claudeの関与があった可能性が高い」という事実だけで、人間の全面執筆の証明にも、他社AIの関与検出にもならない。ユーザーや組織を特定する情報も含まないため、自社生成物の追跡にも使えない。自社のAI Act対応を透かし機能だけに委ねず、公開時にAI生成である旨を人間にも分かる形で開示する運用を並行して整備したい。画像・動画はC2PA Content CredentialsがFiles API経由で別途付与されるため、テキストとメディアで対応手段が異なる点も設計に反映する。

参考

• What's new in Claude Fable 5.1 – Claude Platform Docs
• How Claude's text watermarking works – Anthropic
• How Claude marks AI-generated content – Anthropic Help Center
• Article 50: Transparency obligations – AI Act Service Desk

まとめ

Claude Fable 5.1とMythos 5.1のテキスト透かしは、EU AI Act第50条対応としてAnthropic側が実装した機能であり、検出APIも対象組織限定のプライベートプレビューにとどまる。企業が自社のコンテンツガバナンスに転用できる範囲は現時点で限定的で、開示表示など人間向けの透明性対応は別途自前で設計する必要がある。エンタープライズ規模でのAIコンテンツガバナンス設計は、Kuuの高度実装支援（RDE）から相談できる。

ACPとは何か

ACPはJSON-RPC 2.0でエディタとエージェントを疎結合する規格で、2025年8月にZedが公開しました。

ACPは、エディタ（クライアント）がエージェントをサブプロセスとして起動し、標準入出力（stdio）上でJSON-RPC 2.0メッセージをやり取りする構成を基本形とします。リモートホスト型エージェントをHTTP/WebSocketで接続する拡張も仕様上は用意されていますが、現時点では開発途上です。

設計思想はLanguage Server Protocol（LSP）の応用です。LSPが言語サーバーとIDEを疎結合にしたのと同じ発想を、ZedはGoogleのGemini CLIチームと共同でAIエージェントとエディタの関係に持ち込みました。2025年10月にはJetBrainsもIntelliJ IDEA・PyCharm・WebStormを含む全製品でACPをネイティブサポートすると表明し、2026年時点でZed・VS Code・Neovim・Emacsなど11以上のエディタと、Claude Agent SDK・GitHub Copilot・Cursor・Gemini CLIなど40以上のエージェント実装がACPに対応しています。

ACPはMCP・A2Aと何が違うのか

MCPはツール接続、A2Aはエージェント間連携を担う標準で、ACPはエディタとエージェントを繋ぐ第三のプロトコルです。

3つのプロトコルは同じ「エージェントを外部と繋ぐ」課題を、異なるレイヤーで解決しています。

この3層は排他的ではなく共存します。実際、Claude Agent SDKをACP対応にするアダプター（claude-agent-acp）は、ファイル編集のレビューフローやTODO管理、インタラクティブなターミナル実行に加えて、クライアント側が持つMCPサーバーへの接続もサポートしています。つまり「エディタとの会話はACP、ツール呼び出しはMCP」という積層構成が実装レベルで成立しています。

ACPはどう動くのか——セッションと権限モデル

ACPは応答ありのメソッドと応答なしの通知の2種類のJSON-RPCメッセージでセッションと権限確認を扱います。

会話はsession/newでセッションを開始するところから始まります。エージェントがファイル編集やコマンド実行など副作用のある操作を行う前には、session/request_permissionでクライアント（エディタ）に許可を求め、ユーザーが承認・拒否を選ぶまで実行は止まります。セッション中の進行状況——エージェント・ユーザー・思考過程のメッセージチャンク、ツール呼び出しの状態、実行計画——はsession/update通知としてストリーミングされ、エディタ側のUIにリアルタイム反映されます。

この権限確認フローがあるため、ACP対応エージェントをサブプロセスとして起動しても、ファイル書き込みやターミナル実行の可否はエディタ側UIが最終ゲートを握ります。信頼できないサードパーティ製エージェントを迎え入れても、実行制御の主導権はホスト側に残る設計です。

自社にACP対応は必要か

複数のエディタやエージェントを使い分ける、または比較検討したい企業はACP対応を検討する価値があります。

特定のエージェントと特定のエディタに固定して運用するなら専用連携で十分です。開発者ごとに好みのエディタが違う、あるいはエージェントベンダーを比較検討する余地を残したい場合は、ACP対応のエージェント・エディタを選ぶことでロックインを避けられます。

規模別の留意点（SMB / エンタープライズ）

SMBでは、個々の開発者がZedやJetBrains、VS Codeなど好みのエディタを使いながら、同じエージェント（例えばClaude Agent SDKベースのもの）を共有できる利点が大きく、追加インフラなしに導入できます。エンタープライズでは、複数チームが異なるエディタ・エージェントを併用する状況でツール調達を標準化しやすくなる一方、サブプロセスとして起動するサードパーティ製エージェントの権限スコープと供給元の信頼性は事前審査の対象にすべきです。大規模な調達・ガバナンス設計が必要な場合はKuuの高度化支援サービス（RDE）が対応します。

エージェント・エディタ統合の設計や運用ルール整備のご相談は Kuuの運用管理サービス（AI Ops） からお問い合わせください。

参考

• Agent Client Protocol - Introduction（公式ドキュメント）
• Agent Client Protocol - Protocol Overview（公式ドキュメント）
• Bring Your Own Agent to Zed（Zed公式ブログ）
• ACP Brings JetBrains on Board（Zed公式ブログ）
• claude-agent-acp（公式GitHubリポジトリ）

まとめ

ACPは「エディタとAIコーディングエージェントを疎結合する」という、MCP・A2Aのどちらも扱ってこなかった第三の接続面を標準化するプロトコルです。LSPが言語サーバーとIDEを切り離したのと同じ発想で、2025年8月の発表からわずか1年でJetBrains・40以上のエージェント実装を巻き込む標準に育っています。エージェント・ツール・エディタという3層の役割分担を理解した上で、自社の開発体制に合わせてどこまで対応させるかを判断してください。

エージェントプロトコルの選定や導入設計は、Kuuの運用管理サービス（AI Ops）にご相談ください。

投機的デコーディングとは何か

投機的デコーディングは、軽量なドラフト機構が複数トークンを先読み提案し、本体モデルが1回の forward pass でまとめて検証する高速化技術です。

投機的デコーディングは、小さなドラフトモデルまたは軽量な提案機構が候補トークンを複数個（一般に3〜12個程度）まとめて生成し、本体の大規模モデル（target model）がそれらを1回の forward pass で並列検証する手法です。NVIDIAの技術解説によれば、逐次生成が「3トークンを200msずつ3回」かかる代わりに「3トークンを1回の250msパス」で処理できる点に高速化の本質があります。検証ロジックはドラフト側の確率分布と本体モデルの確率分布を比較する棄却サンプリングで、出力分布は理論上ロスレスに保たれます。

投機的デコーディングはどう動くか

ドラフト生成・並列検証・棄却サンプリングの3段階で構成され、採用率（acceptance rate）が高速化幅を左右します。

処理は3段階に分かれます。まずドラフト機構が次の数トークンを高速に提案します。次に本体モデルがKVキャッシュを再利用しながら、入力とドラフトトークンをまとめて1回の forward pass で処理します。最後に、各トークンについて本体モデルが実際に生成したであろう確率とドラフト側の確率を比較し、一致すれば採用、不一致であればそのトークン以降を破棄して本体モデルの出力に差し替えます。この採用率が高いほど高速化の恩恵が大きく、全トークンが棄却された最悪ケースでも通常の逐次生成と同等の速度に収まるため、品質を犠牲にしない設計になっています。

どの手法を選ぶべきか——EAGLE・ドラフトモデル・N-gram

vLLMはEAGLE・ドラフトモデル型からN-gram・Suffix Decodingまで複数方式を提供し、QPS帯域で使い分けます。

vLLMの公式ドキュメントは手法をモデルベース方式と軽量方式に大別しています。EAGLE・Multi-Token Prediction・ドラフトモデル・PARDなどのモデルベース方式は高速化幅が大きい一方、ドラフト用の追加モデルをGPUメモリに載せる必要があります。N-gramやSuffix Decodingのような軽量方式は追加モデル不要で、ピークトラフィック時にも導入しやすい代わりに高速化幅は控えめです。vLLMは--speculative-configにJSON形式でmethod・model・num_speculative_tokensなどを指定して有効化する設計になっており、公式ガイドは「実際の効果はモデルファミリー・トラフィックパターン・ハードウェア・サンプリング設定に依存するため、自環境での実測が必須」と明記しています。

本番導入で注意すべきトレードオフとは

投機的デコーディングは低QPSの対話用途で効果が大きく、高並列バッチでは採用率低下により効果が薄れます。

投機的デコーディングは低QPS・低同時実行数のレイテンシ最適化に向いた技術です。単一リクエストのレイテンシは20〜50%程度改善する一方、GPUが既に飽和している高バッチサイズ・高同時実行数の環境では、ドラフト生成と検証で2回分の計算コストを払ってもスループットの伸びは限定的になります。加えて、投機トークン数を増やしすぎると高並列時にレイテンシのばらつき（スパイク）が生じやすいため、想定QPS帯域に合わせてトークン数をチューニングする必要があります。GPU推論キャパシティの調達戦略や推論コスト最適化と組み合わせ、対話型エンドポイントには投機的デコーディングを、バッチ処理には別のスケーリング戦略を割り当てる住み分けが有効です。導入判断やセルフホストLLM推論スタック全体の設計は、KuuのRDE（Reinvention Deployed Engineering）サービスでも支援しています。

参考

• Speculative Decoding | vLLM Documentation
• An Introduction to Speculative Decoding for Reducing Latency in AI Inference | NVIDIA Technical Blog
• A Hitchhiker's Guide to Speculative Decoding | PyTorch

まとめ

投機的デコーディングは、GPU増強では解決できない逐次生成のレイテンシ天井を、ドラフト提案と並列検証の組み合わせで構造的に下げる技術です。

導入のポイントをまとめます。

1. 低QPS・対話型の用途から導入し、まずvLLMのN-gramなど軽量方式で効果を測定する
2. 高速化幅を重視する場合はEAGLEやドラフトモデル方式を検討し、追加GPUメモリのコストと比較する
3. 高並列バッチ処理には別のスケーリング戦略を割り当て、投機的デコーディングの適用範囲を対話用途に限定する
4. num_speculative_tokensは想定QPS帯域で実測し、高並列時のレイテンシスパイクを避ける

自社ホスティング推論基盤の高速化設計については、KuuのRDEサービスにご相談ください。

エージェント評価のスコア差はモデル差かインフラ差か

同一モデル・同一ハーネスでもリソース配分だけでスコアが変わり、この変動を「インフラノイズ」と呼びます。

Anthropicはagentic codingベンチマークTerminal-Bench 2.0を用い、モデル・評価ハーネス・タスクセットを完全に同一にしたまま、コンテナのリソース配分だけを6段階（強い制限〜無制限）で変える実験を行いました。結果、最もリソースが厳しい設定と最も緩い設定の間でスコアが6ポイント(p<0.01)動きました。これは多くのリーダーボードでモデル間の差として報告される幅と同等かそれ以上です。Anthropicは「文書化・整合の取れたインフラ設定を伴わない3ポイント未満のリーダーボード差は、不確実なものとして扱うべきだ」と述べています。SWE-benchでも同様の実験を行い、RAMを5倍にした条件で1.54ポイントの変動を確認しており、リソース感度の大きさはタスクの重さに依存する構造だと分かります。

インフラノイズはどこから生まれるか

コンテナランタイムの保証割当と強制終了しきい値が同一値だと、突発的なメモリ使用増でOOM killが発生します。

インフラノイズの主要因はコンテナのリソース強制（resource enforcement）の設計です。コンテナランタイムは「保証割当（guaranteed allocation）」と「強制終了しきい値（hard kill threshold）」という2つのパラメータを持ちますが、この2つを同一値に固定すると、一時的なメモリスパイクを吸収する余地がなくなり、本来失敗すべきでないタスクが不可解なOOM(Out of Memory)終了で失敗します。実測では、リソースを厳格に制限した設定でインフラ起因のエラー率が5.8%に達した一方、無制限設定では0.5%まで低下しました。API呼び出しのレイテンシ変動、クラスタの健全性、ハードウェア仕様、同時実行数、egress帯域といった要因も同様にノイズ源になり得ます。

リソース配分の余白はどこまで確保すべきか

per-taskのリソース仕様に対しヘッドルームを約3倍確保すると、インフラエラー率が5.8%から2.1%まで下がります。

Anthropicの実験では、タスクごとのリソース仕様に対して強制終了しきい値を約3倍まで引き上げると、インフラ起因のエラー率が5.8%から2.1%に下がり、スコア自体は統計的なノイズの範囲内（p=0.40）で安定しました。3倍を超えてさらに余白を広げても、成功率の伸び（約4ポイント改善)がインフラエラーの減少ペースを上回るようになるため、際限なく緩めればよいわけではありません。単一の固定値ではなく、タスクごとに「保証割当（フロア）」と「強制終了しきい値（シーリング）」を分けて設定し、突発的なメモリスパイクを吸収できる余地を持たせることが、ノイズを抑える設計の起点になります。

インフラノイズを継続的に抑える運用設計とは

リソース設定を実験変数として文書化し、複数日にまたがる複数回実行で時間依存ノイズを平均化します。

継続運用では3点が有効です。第一に、リソース配分をプロンプト形式やサンプリング温度と同様に「実験変数の一つ」として明文化し、evalの実行条件と一緒に記録すること。第二に、評価を異なる時間帯・日にまたがって複数回実行し、API側のトラフィック変動や一時的なクラスタ負荷を平均化すること。第三に、エージェント評価のCI/CDパイプラインにリソース仕様の変更履歴を組み込み、モデル更新とインフラ設定変更を同時に行わないこと。これにより「スコアが下がったのはモデルの退行か、直前のインフラ変更か」を切り分けやすくなります。なお、エージェント評価の非決定性・再現性設計で扱う温度やツール選択の揺らぎはモデル側の変動要因であり、インフラノイズとは発生源が異なります。両者を混同せず別々に監視することが、マルチエージェントシステムの評価設計のようなスケールの大きい評価基盤ほど重要になります。エンタープライズ規模の評価基盤構築は、KuuのRDEで伴走しています。

参考

• Anthropic「Quantifying infrastructure noise in agentic coding evals」 https://www.anthropic.com/engineering/infrastructure-noise
• Anthropic「Demystifying evals for AI agents」 https://anthropic.com/engineering/demystifying-evals-for-ai-agents

まとめ

エージェント評価のスコア差は、モデルの実力差だけでなく、コンテナのリソース配分に起因するインフラノイズでも生まれます。

1. リソース配分だけでスコアが最大6ポイント動くことを前提に、3ポイント未満の差は設定を揃えない限り不確実だと扱う
2. 「保証割当」と「強制終了しきい値」を分け、per-taskの仕様に対して約3倍のヘッドルームを確保する
3. リソース設定を実験変数として文書化し、複数日にまたがる複数回実行で時間依存ノイズを平均化する
4. モデル側の非決定性（温度・ツール選択の揺らぎ)とインフラノイズを別々に監視し、CI/CDでモデル更新とインフラ変更を同時に行わない

評価基盤の設計・運用を本番規模で構築したい場合は、KuuのRDEにご相談ください。

なぜオンデマンドGPUだけでは推論基盤が安定しないのか

オンデマンドGPUはいつでも起動できる代わりに単価が最も高く、需給次第で在庫が枯渇し起動できないこともある。

エージェント基盤のGPU需要はトラフィックの波によって大きく変動しますが、オンデマンドインスタンスは常に定価であり、ピーク帯の使用率が低いと投資対効果が出ません。さらにH100・H200・B200クラスの高性能GPUは需給が逼迫しやすく、必要な瞬間にオンデマンドで確保できない事態も起こります。AWSはこうした需要に対応するため、GPUインスタンスを事前予約できるEC2 Capacity Blocks for MLを提供しており、最大8週間先の開始時刻を指定して1〜64台規模のクラスタを確保できます。

予約・オンデマンド・スポットは何を保証するか

予約枠は開始時刻と台数を確定できるが柔軟性を失い、スポットは最安だが2分前通知で中断される。

3方式は「確実性」と「単価」がトレードオフの関係にあります。EC2 Capacity Blocksは指定日時にクラスタ全体をUltraClusters内の低遅延ネットワークで確保でき、GPU未使用時間分の料金は発生しません。GCPのDynamic Workload SchedulerはCalendar modeで同種の確定予約を、Flex-start modeで需要逼迫時でも起動確率を高めた割引インスタンスを提供します。一方スポットインスタンスはAWSの場合2分前の中断通知しか保証されず、常時起動を要する本番推論には単独で使えません。

推論ワークロードのどの部分にスポットを使えるか

リアルタイム推論は中断リスクを避けオンデマンド中心にし、バッチ推論・評価・ファインチューニングはスポットに寄せられる。

AWSの公式ガイドはスポットの用途をステートレスかつ耐障害性のあるワークロードに限定するよう推奨しています。エージェント基盤では、ユーザー対話に直結するリアルタイム推論はレイテンシSLOを守れないためスポット単独運用に向きません。一方、Message Batches APIのような非同期処理や、夜間バッチでのモデル評価・回帰テストは中断されても再実行できるため、スポットとの相性が良い領域です。中断に備えるには、5〜15分間隔のチェックポイントとインスタンスリバランス推奨シグナルの監視を組み込み、中断通知を受けた時点でロードバランサーから切り離す設計が要ります。

調達戦略はどう設計すればよいか

ベースライン需要は予約枠、変動分はオンデマンド、バッチ処理はスポットに振り分ける3層構成が基本形になる。

実務では単一方式を選ぶのではなく、トラフィックの性質ごとに3層で組み合わせます。まず日次で確実に発生するベースライン需要はCapacity BlocksやCalendar modeの予約枠でまかない、GPU使用率を高く保ちます。次に予測できない突発的な需要増分はオンデマンドで吸収し、オートスケーリング設計のキュー深度シグナルと連動させます。最後に評価パイプラインやバッチ推論などレイテンシ要件が緩いワークロードはスポット・Flex-startに振り、コスト全体を最適化します。予約枠の粒度(台数・期間)を需要予測と合わせて見直すサイクルも運用に組み込む必要があります。

参考

• Capacity Blocks for ML - Amazon EC2 User Guide
• Best practices for Amazon EC2 Spot - Amazon EC2 User Guide
• Spot Instance interruption notices - Amazon EC2 User Guide
• About Flex-start VMs | Compute Engine - Google Cloud

まとめ

GPU推論キャパシティの調達は、推論エンジンの選定と同じ重みを持つ設計課題です。オンデマンド・予約・スポットはそれぞれ保証する内容が異なり、ワークロードの性質で使い分けることでGPU使用率とコストの両立が可能になります。予約枠の設計やマルチクラウドでの調達戦略の構築には専門知見が要ります。Kuu株式会社のReinvention Deployed Engineeringでは、大規模エージェント基盤のインフラ調達設計を支援しています。

GPU機密コンピューティングとは何か

GPU-CCはCPU/GPUのメモリを暗号化した信頼実行環境（TEE）内で推論を実行し、署名付きアテステーションレポートで実行環境の正当性を証明する技術です。

TEE（Trusted Execution Environment）は、CPUやGPUのファームウェアが提供するハードウェア隔離領域で、OS・ハイパーバイザー・クラウド運用者を含む外部からメモリ内容を読み取れないようにする。NVIDIAのGPU-CCはHopper（H100）以降のGPUで対応し、GPUドライバとVBIOS・ファームウェアの測定値を含む署名付きアテステーションレポートを生成する。この機構はモデル重みそのものと、推論中の中間テンソル（プロンプト・KVキャッシュ）の双方を保護対象にする。

なぜAIエージェント基盤にTEEが必要になるのか

PHI・PII・営業秘密を扱うエージェント基盤では、クラウド運用者の特権アクセスや悪意あるインサイダーからもプロンプトと出力を守る要求が生じます。

VPC内デプロイはネットワーク境界を守るが、実行中のGPUメモリを直接ダンプする攻撃までは防げない。医療のPHI・金融の取引データ・自社モデルのファインチューニング重みを扱うエージェントでは、クラウド事業者自身を脅威モデルに含めるゼロトラストの発想が要る。TEEはこの「運用者も信頼しない」前提を、暗号化メモリとリモートアテステーションで技術的に担保する。

主要クラウドの実装をどう比較するか

NVIDIA GPU-CCはGPU単体の測定・証明を担い、Google Confidential SpaceとAWS Nitro Enclavesはワークロード全体の起動を鍵管理サービスと連動させて制御します。

いずれも共通するのは「正しいコードが動いていることを暗号学的に証明できたワークロードだけに、機密データへのアクセス鍵を渡す」という設計だ。GPUの計算そのものを守るNVIDIA GPU-CCと、ワークロード起動全体を守るConfidential Space・Nitro Enclavesは補完関係にあり、GPU推論を伴うエージェント基盤ではGPU-CC対応インスタンス上にConfidential Space/Nitro Enclavesのワークロードを重ねる構成が現実的になる。

導入設計で押さえるべきポイント

アテステーション検証をリクエスト経路に組み込み、鍵の払い出し条件をワークロード測定値に紐づけることが設計の核心です。

第一に、アテステーション検証はエージェントのリクエスト処理経路に組み込む。LLMゲートウェイの前段でワークロードの測定値を検証し、失敗時はリクエストを拒否する。第二に、復号鍵の払い出し条件をワークロード識別子に紐づけ、マルチテナント分離設計のテナント境界と一致させる。第三に、TEE化には数%〜十数%の推論オーバーヘッドが伴うため、PHI・営業秘密など保護要件の高いテナントに限定適用し、全ワークロードへの一律適用は避けるのが現実的だ。ゼロトラストのmTLS設計と組み合わせれば、ネットワーク層とコンピュート層の双方で運用者を信頼しない構成が完成する。

参考

• Confidential Space overview — Google Cloud
• NVIDIA Trusted Computing Solutions (nvTrust) — NVIDIA Docs
• Large language model inference over confidential data using AWS Nitro Enclaves — AWS Machine Learning Blog

まとめ

GPU機密コンピューティングは、VPC分離や暗号化では届かなかった「クラウド運用者自身を信頼しない」領域をハードウェアアテステーションで埋める技術だ。NVIDIA GPU-CCによるGPU単体の証明と、Confidential Space・Nitro Enclavesによるワークロード全体の起動制御を組み合わせることで、PHI・営業秘密を扱うエージェント基盤でも推論データとモデル重みを技術的に保護できる。オーバーヘッドとのトレードオフを踏まえ、保護要件の高いテナントから段階的に導入するのが現実的な進め方だ。

規制業種向けのエージェント基盤設計からTEE導入の要件整理まで、KuuのRDE（Reinvention Deployed Engineering）サービスでは大規模エンタープライズのAI実装を一貫して支援しています。詳細はサービス詳細ページからお問い合わせください。

本記事では、Batch APIの仕組みと向いている業務、実装手順、運用時の注意点を解説する。すでにバッチ・キャッシュ・ルーティングを横断した全体設計はLLM推論コスト削減の解説で扱っているため、本記事はBatch API単体の実装に絞る。

Message Batches APIとは何か

Message Batches APIは複数のリクエストをまとめて非同期処理する仕組みで、入力・出力とも標準料金の50%で利用できる。

Message Batches APIは、複数のMessagesリクエストを一括投入し、非同期に処理する仕組みだ。同期のMessages APIと違い即時応答は返らないが、そのぶん料金は入力・出力トークンとも標準価格の50%になる。たとえばClaude Sonnet 5は標準が入力$2・出力$10（MTokあたり)だが、バッチでは入力$1・出力$5に下がる。Claude Haiku 4.5は標準入力$1・出力$5に対し、バッチでは入力$0.50・出力$2.50となる。

1バッチにまとめられるリクエストは最大10万件、または合計256MBのいずれか早い方が上限。ほとんどのバッチは1時間以内に処理が終わるが、システムは全リクエストの処理完了または作成から24時間経過のいずれか早い方で結果を確定させる。24時間以内に処理が終わらなかったリクエストは期限切れとなり課金されない。結果は作成から29日間ダウンロード可能で、それ以降はバッチ自体は閲覧できても結果は取得できなくなる。

どんな業務がバッチ処理に向くか

即時応答が不要で数百件以上をまとめて処理する業務——帳票分類、月次レポート要約、コンテンツ生成——がバッチ向きだ。

Batch APIが向くのは「今すぐ結果が要らない」処理だ。具体例として、夜間に溜まった請求書・領収書画像の分類、月末の経営会議向けレポート要約、商品説明文のまとめ生成、大量データのタグ付け・感情分析などが挙げられる。逆にチャットボットの応答やユーザー操作への即時フィードバックは同期APIのまま残す必要がある。

Batch APIはVision・ツール使用（Web検索やコード実行を含むサーバーツール）・システムプロンプト・マルチターン会話・extended thinkingのほぼすべてのリクエスト形式に対応する。1バッチの中で異なる種類のリクエストを混在させることも可能なので、複数業務のジョブを1本のバッチにまとめて夜間に流すといった運用もできる。

バッチAPIをどう実装するか

各リクエストに一意のcustom_idを付けて送信し、処理完了後にresults_urlからJSON Lines形式で結果を取得する。

実装の流れはシンプルだ。まずcustom_id（英数字・ハイフン・アンダースコアで1〜64文字）を各リクエストに付与し、requests配列にまとめて/v1/messages/batchesへPOSTする。

``python
message_batch = client.messages.batches.create(
requests=[
{
"custom_id": "invoice-0001",
"params": {
"model": "claude-haiku-4-5",
"max_tokens": 512,
"messages": [{"role": "user", "content": "この請求書から金額と発行日を抽出して"}],
},
},
# ... 続く請求書分だけ繰り返す
]
)
``

作成直後はprocessing_statusがin_progressとなる。60秒間隔などでポーリングし、endedになったらresults_urlからJSON Lines形式の結果をストリーミング取得する。結果は投入順とは限らないため、custom_idで元のリクエストと突き合わせる。各結果はsucceeded・errored・canceled・expiredのいずれかを持ち、後者3つは課金対象外だ。

なおstream: trueやFast mode、max_tokens: 0（キャッシュ事前ウォーム）はバッチ内でサポートされない。プロンプトキャッシュとは併用でき、システムプロンプトなど共通部分に同一のcache_controlを設定すればキャッシュヒット率30〜98%の範囲で追加のコスト削減が見込める。バッチは5分キャッシュより長く待つ場合があるため、1時間キャッシュの利用が推奨されている。

レート制限・運用で気をつけるべき点は何か

バッチAPIは通常のMessages APIとは別枠のレート制限を持ち、Startティアでも同時10万件を投入できる。

Batch APIのレート制限は通常のMessages API（RPM・ITPM・OTPM）とは別枠で管理される。Startティアでは毎分1,000リクエスト・処理待ちキュー上限20万件・1バッチあたり最大10万件まで扱える。Buildティアでは毎分2,000リクエスト・キュー上限30万件、Scaleティアでは毎分4,000リクエスト・キュー上限50万件に拡大する。バッチは通常のTPM/RPM制限を消費しないため、リアルタイム処理と並行して流しても本番トラフィックを圧迫しない。

運用上の注意点は3つある。第一に、バッチはWorkspace単位でスコープされるため、複数チームで使う場合は結果の閲覧範囲がWorkspaceに限定される。第二に、高スループット・並行処理の特性上、Workspaceの支出上限をわずかに超過する場合がある。第三に、需要が集中している時間帯は24時間以内に処理しきれず期限切れになるリクエストが増える可能性があるため、締切のあるジョブは余裕を持って投入する。レート制限全般の対処はLLM APIレート制限の対処設計も参照してほしい。

Kuuのエージェントガバナンスサービスでは、バッチ処理の設計を含むAI運用コストの見直し支援も行っている。

参考

• Batch processing — Claude Docs
• Pricing — Claude Docs
• Rate limits — Claude Docs

まとめ

Claude Message Batches APIは、即時応答が不要な処理を入力・出力とも標準料金の50%で実行できる仕組みだ。1バッチ最大10万件、結果は29日間取得可能、通常のレート制限とは別枠で動くため、帳票分類や月次レポート要約のようなバックグラウンド処理から着手すれば、品質を落とさずにAI運用コストを圧縮できる。まずは1つの非同期処理をバッチAPIに移行し、削減効果を確認するところから始めるとよい。

Kuuのエージェントガバナンスサービスでは、AIエージェントのコスト設計から運用改善まで支援している。バッチ処理の導入検討はまず無料相談で相談してほしい。

エージェントスキルの配布はどんなリスクを抱えているか

マーケットプレイス由来の3,984件のスキルのうち534件（13.4%)に重大な脆弱性があり、91%が悪意あるコードとプロンプトインジェクションを併用していました。

セキュリティベンダーSnykが2026年2月にClawHubとskills.shの計3,984件のエージェントスキルを監査した結果、13.4%にあたる534件が重大度クリティカルの欠陥を含み、36.82%（1,467件）が何らかのセキュリティ上の欠陥を持っていました。確認された76件の悪意あるペイロードのうち、公開停止済みのものを除く8件は調査時点でも入手可能な状態でした。攻撃手法は、外部の不正バイナリへ誘導するインストール手順、Base64やUnicodeで難読化した認証情報窃取コマンド、安全機構を無効化して永続的なバックドアを設置する手口の3系統に分かれます。確認された悪意あるスキルの100%がコードパターンで検知可能だった一方、91%は同時にプロンプトインジェクション技術も併用しており、単一の検知手法では見逃しが生じる構造になっています。

エージェントスキルの安全性はどう審査すればよいか

Anthropicの公式ガイドはリスク指標を7項目に分類し、SKILL.md本体・スクリプト・参照ファイルを含む8段階のレビュー手順を定めています。

Anthropicの公式エンタープライズガイドは、コード実行の有無、指示による安全ルール無視の誘導、MCPサーバーへの参照、ネットワークアクセスの痕跡、ハードコードされた認証情報、想定外のファイルアクセス範囲、ツール呼び出しの7つをリスク指標として整理しています。審査手順は、SKILL.md本体とスクリプト・参照ファイルを含む全内容を読む、スクリプトをサンドボックスで実行し出力が説明文と一致するか確認する、外部URLへのフェッチ有無を検索する、認証情報のハードコードがないか確認する、参照先ドメインが想定通りか確認する、といった8ステップで構成されます。ファイル読み取りとネットワーク呼び出しを組み合わせたスキルは、単体では低リスクに見えても組み合わせた際のリスクを個別に評価する必要があると明記されています。

エンタープライズはスキル審査をどう自動化できるか

Claude Enterpriseの「Skill and plugin security scanning」は不審な挙動を検知しブロックしますが、Claude APIやSkills API経由のアップロードは対象外です。

Claude Enterprise組織はclaude.aiの管理画面でスキャン機能を有効化でき、claude.aiとClaude Cowork上でメンバーがアップロード・編集したスキルを対象に、隠されたコード実行や外部へのデータ送信、Claudeの安全機構を改ざんする指示の兆候を自動検査します。審査に失敗したスキルは利用がブロックされ、警告付きで通過したスキルは注意喚起の表示を伴って利用可能になります。ただしこのスキャンはClaude API経由のアップロード（Skills APIやConsole経由）には適用されず、ゼロデータ保持やCMEK構成の組織、スキャン有効化前から存在していたスキルも対象外です。API経由でスキルを配布する場合は、レビューチェックリストとバージョン固定による運用が引き続き必須になります。

中小企業はどこから審査を始めればよいか

専任のセキュリティ担当者がいなくても、リスク指標7項目と信頼できる入手元への限定だけで審査の出発点を作れます。

エンタープライズ向けスキャン機能を使えない中小企業でも、公式ガイドが定義するリスク指標をそのままチェックリストとして転用できます。優先すべきは、自分で作成したか、Anthropicが提供するスキルに限定すること、未知の提供元のスキルを導入する際はSKILL.mdとスクリプトを人手で確認し、外部URLへのフェッチや認証情報のハードコードがないかを検索することです。導入後は、スキルがアクセスした認証情報やAPIのローテーションを定期的に行い、エージェントのメモリファイルに不審な永続化の痕跡が残っていないかを確認する運用を組み込むと、専任チームがいなくても最低限の防御線を保てます。

規模別の留意点（SMB / エンタープライズ）

中小企業では、スキル導入を「個人の判断」に委ねず、導入前チェックの実施者を固定し記録を残す運用だけでもリスクを大きく下げられます。エンタープライズでは、Skill content scanningの適用範囲外となるAPI経由の配布ルートを把握した上で、レビューチェックリストとバージョン固定・チェックサム検証を組み合わせた多層的な審査体制が必要です。組織横断でスキルを共有する場合は、審査者と作成者を分離する体制も欠かせません。より大規模な統制設計はReinvention Deployed Engineeringの支援範囲です。

参考

• Agent Skills — Claude Platform Docs
• Skills for enterprise — Claude Platform Docs
• Snyk ToxicSkills Study: Malicious AI Agent Skills on ClawHub

まとめ

エージェントスキルはnpmパッケージと同じ供給網リスクを持ちながら、実行時にはファイル操作やネットワーク呼び出しといった強い権限を伴います。信頼できる入手元への限定と、リスク指標に基づく審査チェックリストの運用を組み合わせることが、規模を問わず最初の防御線になります。Kuu株式会社では、スキル審査プロセスの設計からエージェント運用の技術支援まで支援しています。自社のスキル導入フローに不安がある場合は、お気軽にご相談ください。

Agent Skillsの品質はどう検証すればよいか

skill-creatorのEvalモードでテストプロンプトと期待結果を定義すると、モデル更新やSKILL.md変更時の品質劣化を自動検出できます。

これまでAgent Skillsの検証は、担当者が手動でプロンプトを試し「それらしい出力か」を目視確認する方法に頼りがちだった。SKILL.mdは指示文とメタデータの集合であり、モデルのバージョンが上がるたびに挙動が変わりうる。にもかかわらず、変更前後を定量比較する手段が整備されていなかった。

skill-creatorのEvalモードは、この空白を埋める。テストプロンプト（必要ならファイルも添付）と「良い出力とは何か」を記述するだけで、スキルが期待どおり動くかを自動判定する。評価用のテストケースとその結果はローカル保存・ダッシュボード連携・CI組み込みのいずれでも扱え、特定のベンダーに縛られない。

Benchmarkモードは何を計測するか

Benchmarkモードはpass率・所要時間・トークン使用量の3指標を記録し、モデル更新前後の性能をbenchmark.jsonで比較可能にします。

Evalモードでテストケースが揃ったら、Benchmarkモードで標準化した計測を走らせる。記録される指標は次の3つだ。

• pass率: 用意した評価セット全体での合格割合
• 所要時間: 各テストの実行にかかった時間
• トークン使用量: テストごとの消費トークン数

これらは「スキルあり」と「スキルなし」の両方で集計され、性能改善の度合いとトークン・時間コストのトレードオフを一目で比較できる。さらに独立したサブエージェントが各評価をクリーンなコンテキストで並列実行するため、あるテストの副作用が別のテストの結果を汚染しない。モデルがアップデートされた直後や、SKILL.mdの記述を修正した直後に走らせれば、劣化に気づかず本番投入する事故を避けられる。

comparatorエージェントによるA/B比較はどう機能するか

comparatorエージェントは2つのスキル版、またはスキルあり・なしの出力を、どちらの版か分からない状態で判定するブラインド比較を行います。

skill-creatorにはcomparatorエージェントも含まれる。役割は「スキルの旧版と新版」あるいは「スキルあり・なし」の出力を並べ、どちらがどちらか分からない状態で品質を判定することだ。ブラインドにすることで、判定者が「これは新しい方だから良いはず」といったバイアスを持ち込みにくくなる。

プロンプトの文言を1行変えるような小さな修正でも、実際に結果が改善したかは主観では判断しにくい。comparatorエージェントを使えば、変更をリリースする前に効果を客観的に確認できる。IT担当が1人しかいない体制でも、レビュー工数をかけずに判断材料を得られるのが実務上の利点だ。

中小企業がevalを組み込む3ステップ

業務でよく使うプロンプトを5〜10件テストケース化し、Benchmarkでモデル更新前後を比較する運用から始めるのが現実的です。

1. 既存スキルの利用実績からテストケースを作る: 社内で実際に使われたプロンプトとその期待出力を5〜10件選び、Evalモードに登録する。架空のシナリオより、実際に困った場面を反映したケースの方が弱点を突きやすい。
2. Benchmarkを定期実行する: モデルのバージョンが上がったタイミング、およびSKILL.mdを修正したタイミングでBenchmarkモードを回し、pass率・所要時間・トークン数の推移を記録する。
3. 修正はcomparatorで検証してから展開する: SKILL.mdの記述変更は、必ずcomparatorエージェントで旧版と比較してから他の担当者にも展開する。

Claude Agent Skillsを業務に組み込んだ後も、この3ステップを回せば「入れっぱなしで品質が分からない」状態を避けられる。KuuのAIエージェント運用管理サービス（AI Ops）では、Agent Skillsの評価設計から継続運用までを支援している。

参考

• Improving skill-creator: Test, measure, and refine Agent Skills（Anthropic）
• Agent Skills Overview（Claude Platform Docs）
• Skill authoring best practices（Claude Platform Docs）

まとめ

Agent Skillsは「作って終わり」にすると、モデル更新のたびに劣化しても気づけない。skill-creatorのEvalモードでテストケースを定義し、Benchmarkモードでpass率・所要時間・トークン数を継続計測し、修正はcomparatorエージェントで検証してから展開する——この3点セットが、社内エンジニアが少ないチームでも回せる最小の品質保証ループだ。

Agent Skillsの評価設計・運用は、KuuのAIエージェント運用管理（AI Ops）から相談を受け付けている。

この問題に対して、Anthropicが2026年5月にClaude Codeへ実装した /goal コマンドは、一つの明確な設計解を示しています。本記事はAIエージェントガバナンスの評価設計に連動する内容として、この仕組みを技術的に分解し、自社のエージェント基盤に応用する方法を整理します。

AIエージェントの完了判定はなぜ難しいのか

自己申告による完了判定は「作業した本人が採点する」構造的な利益相反を抱えており、タスクが複雑になるほど誤判定が増えます。

エージェントが自分の出力を自分で「完了」と判定する方式には、構造的な弱点があります。作業を行ったコンテキストと判定を行うコンテキストが同一であるため、途中の推論過程に引きずられて「やることはやった」という結論に寄りやすいのです。これは人間のセルフレビューでバグを見落としやすいのと同じ力学です。

一方で、ターン数や時間による打ち切りは判定の質を保証しません。単純なリファクタリングに20ターンは過剰かもしれませんし、大規模なモジュール移行には20ターンでは全く足りないこともあります。「タスクが終わったこと」を機械的に確認する仕組みが必要になります。

検証可能な終了条件とは何か

検証可能な終了条件とは、テストの終了コードやファイル状態など、会話ログに現れる形で証明可能な単一の終了状態を指します。

/goal の核となる考え方は「verifiable end state（検証可能な終了状態）」です。条件は最大4,000文字まで記述でき、次の3要素を含むことが推奨されています。

1. 測定可能な単一の終了状態 — テスト結果、ビルドの終了コード、ファイル数、空になったキューなど
2. 証明方法の明示 — 「npm test が exit 0 で終わる」「git status がクリーンである」といった、Claudeが自分の出力で示せる形の指示
3. 崩してはいけない制約 — 「他のテストファイルを変更しない」など、達成の過程で守るべき条件

例えば「test/auth 配下の全テストが通り、lintがクリーンな状態、または20ターンで停止する」という条件を設定すると、Claude Codeはこの条件を最初のディレクティブとしてターンを開始し、以降は自律的に作業を継続します。

``text
/goal test/authの全テストが通り、lintがクリーンな状態。または20ターンで停止する
``

評価者を作業から分離するとなぜ有効か

評価専用の軽量モデルを作業モデルと分離することで、判定が作業の推論過程に引きずられる問題を構造的に防げます。

/goal の実装は、セッション単位のプロンプトベースStopフックとして動作します。1ターンが終わるたびに、条件とそれまでの会話をデフォルトでHaiku相当の小型・高速モデルに渡し、次の3種類の判定を返させます。

評価者は作業エージェントの推論過程を見ず、会話に現れた結果だけを判定材料にします。これはManaged Agents Outcomesのルーブリック採点エージェントが作業エージェントの思考にアクセスしない設計と同じ思想です。評価者自身はツールを呼び出さず、ファイルを直接読みにいくこともできません。したがって、条件文は「Claudeの出力が証明できる形」で書く必要があります。

無限ループへの安全弁も組み込まれています。評価者に対する応答だけが続きツール使用が数ターン続かない場合、Claude Codeはループを止めて警告を出し、制御をユーザーに戻します。またサブエージェントやバックグラウンドのシェルコマンドが実行中のターンでは評価そのものをスキップし、待機が30分を超えると進捗確認を挟む設計になっています。

自社のエージェントに完了判定をどう組み込むか

既存のエージェント基盤に組み込む場合は、独自のStopフックとして評価者ロジックを実装するのが最も移植しやすい方法です。

/goal を直接使わないエージェント基盤でも、同じ設計パターンは移植できます。プロンプトベースのStopフックとして、ターン終了時に軽量モデルへ条件と会話履歴を渡し、3値判定を返させる構成をそのまま実装できます。

設計時に押さえておくべき点は次の3つです。

• 評価モデルは作業モデルと分離する: 同一モデル・同一コンテキストでの自己採点は避け、別セッションまたは低コストモデルで判定させる。評価トークンは主作業に比べて無視できる規模に収まることが多い
• 条件は「証明可能な形」で書く: 「品質が良い」ではなく「テストが通る」「ファイルが特定サイズ以下」など、エージェントの出力自体が証拠になる条件にする
• 停止条件を必ず入れる: ターン数や時間の上限を条件文に含め、評価者にも進捗を報告させることで、無限ループのリスクを下げる

こうした完了判定の設計は、エージェントの監査ログ設計と組み合わせることで、いつ・どの条件で・どの判定によってエージェントが停止したかを追跡可能にできます。長時間の自律実行を安全に運用する基盤づくりには、KuuのAI Opsサービスで設計支援を提供しています。

規模別の留意点(SMB / エンタープライズ)

中小企業がまず着手する場合は、CI上のテストコマンドやlintのように既に「合格/不合格」が明確なタスクから完了条件を書き始めるのが現実的です。既存のCIコマンドをそのまま条件文に転用できるため、新しい仕組みを一から作る必要がありません。

大規模な組織では、複数チームが独自の完了条件を運用すると評価基準がばらつきます。条件テンプレートと評価モデルの選定基準を共通化し、監査ログに判定理由を残す設計が必要になります。マルチチームでの評価基盤統制を検討する場合は、KuuのRDE(Reinvention Deployed Engineering)サービスでも支援しています。

参考

• Keep Claude working toward a goal — Claude Code Docs
• Hooks guide — Claude Code Docs

まとめ

自律的に長時間動くエージェントほど、「終わったかどうか」を誰がどう判定するかの設計が重要になります。作業を行うモデルとは別に、軽量モデルが検証可能な終了条件を都度判定する構成は、自己申告や固定ターン数打ち切りの弱点を構造的に補います。

自社のエージェント基盤にこのパターンを組み込む際は、条件を「証明可能な形」で書くこと、評価者を作業から分離すること、停止条件を必ず含めることの3点から始めるのが実践的です。長時間実行するエージェントの完了判定設計や監査体制の構築については、Kuuにお問い合わせください。

Managed Agentsのwebhookは何を通知するのか

webhookはSession・Vault・Agent・Deployment・Environment・Memory storeなど7カテゴリのイベントを配信する。

配信されるのはイベントのtypeとidのみで、オブジェクト本体は含まれない。受信側は通知を受けてから対象をGETで取得する設計になっており、これは再送時に古いデータを配ってしまう事故を防ぎ、1回あたりのペイロードも小さく保てる。カテゴリはセッションのステータス遷移（session.status_run_startedなど）、Vaultの認証情報ライフサイクル、エージェント・デプロイメント（定期実行）の作成/更新/削除、そして2026年8月に追加された環境（environment.）とメモリストア（memory_store.）の変化に及ぶ。

環境とメモリストアのイベントは何が新しいか

環境イベントは4種類、メモリストアイベントは3種類で、いずれも作成から削除までを追跡する。

環境はcreated/updated（変更フィールドが1つ以上あるときのみ発火）/archived/deletedの4種類を持つ。ただし環境配下のワークアイテム自体はイベントを出さない。メモリストアはcreated/archived/deletedの3種類で、ストア削除は配下のメモリとメモリバージョンに連鎖するが、個々のメモリ単位のイベントは出ない——memory_store.deletedという1つのイベントが「ストア全体が消えた」ことの唯一のシグナルになる。この粒度の粗さは意図的な設計で、監視側は「何が変わったか」ではなく「何が消えたか」だけを受け取り、詳細な差分はAPIで都度取得する前提になっている。

署名検証はどう実装するか

配信にはwebhook-signature等3ヘッダーが付き、SDKのunwrap()が検証とパースを1呼び出しで行う。

エンドポイントはClaude Consoleの「Manage > Webhooks」から登録し、作成時に一度だけ表示される32バイトのwhsec_プレフィックス付き署名鍵をANTHROPIC_WEBHOOK_SIGNING_KEYに設定する。受信側は各SDKのunwrap()ヘルパーに生のリクエストボディとヘッダーを渡すだけでよく、署名が不正か、ペイロードが5分より古い場合は例外を投げる。Node.js実装では署名がバイト列に対して計算されるため、express.json()ではなくexpress.raw()でボディを受け取る必要がある——ここを誤ると検証は常に失敗する。

配信保証の設計にどう向き合うか

配信は最大3回、5〜120秒のジッター付き指数バックオフで再試行され、失敗後は破棄される。

event.idは配信ごとではなくイベントごとに一意なので、同じIDを2回受け取ったら再送と判断して破棄してよい。順序も保証されない——session.outcome_evaluation_endedより先にsession.status_idledが届くことも、.deletedが.archivedより先に届くこともある。状態は受信順ではなく都度取得したリソースから組み立てる必要がある。3回の再送すべてが失敗すると、そのイベントはキューに残らず静かに破棄される。webhookは永続ログではないため、欠落を許容できない用途では定期的にAPIでリストして突き合わせる仕組みが要る。エンドポイントは3xx応答・非公開IPへの解決・継続的な配信失敗のいずれかで自動的に無効化され、1回の2xxで失敗カウントの窓はリセットされる。

セッションseedingで往復を減らせるか

initial_eventsは最大50件のイベントをセッション作成と同時に投入し、直接running状態で開始する。

セッション作成とタスク投入は本来2ステップだが、initial_eventsにuser.messageまたはuser.define_outcome（1リクエストにつき1件まで）を含めれば1回のAPI呼び出しで完結する。非空のリストを渡すとセッションはrunning状態で作成され、追加のリクエストなしにエージェントループが動き出す。ファイル添付を含むdocumentブロックは全体で100件まで、リクエストボディは32MBが上限で、いずれかのイベントが検証に失敗すると全体が拒否されセッション自体が作られない。webhook監視と組み合わせると、作成直後のsession.status_run_startedをトリガーに以降の状態遷移だけを追う、という一貫したイベント駆動の運用ループが組める。

参考

• Subscribe to webhooks - Claude Platform Docs
• Start a session - Claude Platform Docs

まとめ

Managed Agentsのwebhookは「何が起きたか」を通知し「詳細はAPIで取得する」という一貫した設計思想を持つ。配信は最大3回・順序不定・非永続という前提のもと、event.idでの冪等化とリソースの都度取得を組み合わせて状態を組み立てる必要がある。中小企業ではSlack通知程度の軽量な連携から、エンタープライズでは監査ログ基盤への連携まで、規模に応じた実装の厚みは異なるが設計原則は共通だ。Managed Agentsのイベント駆動運用の設計・実装はAI Opsが支援し、複数チーム規模の統制にはRDEが対応する。

なぜリージョン単位のDR設計が必要か

LLM推論を単一リージョンに固定すると、そのリージョンの障害がエージェント基盤全体の停止に直結する単一障害点になる。

耐久実行・冪等性設計・サーキットブレーカーといった既存のパターンは、いずれも「同じリージョン内でリトライやフォールバックを行う」ことを前提にしている。しかしAWSの分散設計原則が示す通り、Availability Zone（AZ）間の低遅延・高帯域ネットワークによる自動フェイルオーバーはリージョン内の耐障害性を担保するものであり、リージョンそのものの障害は別レイヤーの設計問題である。RTO（目標復旧時間）とRPO（目標復旧時点）をエージェント基盤の要件として明文化し、それを満たす経路をLLM提供者側の機能で用意しておく必要がある。

AWS Bedrockのクロスリージョン推論をどう使うか

Geographic CRISはデータをUS/EU/APACの地域内に留めたまま複数リージョンへ自動ルーティングし、Global CRISはさらに20以上のリージョンへ範囲を広げる。

Amazon Bedrockのクロスリージョン推論（CRIS）には2種類ある。Geographic CRISは指定した地域（US・EU・APACなど）の境界内でリクエストを複数リージョンへルーティングする方式で、データレジデンシー要件を保ったまま単一リージョン容量制約時の可用性を高める。例えばUS向けのClaude Sonnet 4.5プロファイルは、us-east-1・us-east-2・us-west-2の3リージョンに送信元リージョンからルーティングできる。一方Global CRISは地理的境界を越えて20以上の商用AWSリージョンへルーティング範囲を広げ、Geographic CRISと比べて入出力トークン価格が約10%安くなる。IAM側では推論プロファイル・送信元リージョンのFM・宛先リージョンのFMという3種類のARNへのアクセス許可が必要で、SCPでリージョンを制限している組織は宛先リージョンをすべて許可リストに含めないとルーティングが失敗する点に注意する。

Vertex AIのマルチリージョンエンドポイントで何が変わるか

Vertex AIのマルチリージョンエンドポイントはus-central1とus-east4の容量をプールし、片方が過負荷でも自動的にもう一方へ振り替える。

Google CloudがVertex AI経由で提供するClaudeのマルチリージョンエンドポイントは、US地域ではus-central1とus-east4の推論容量をプールし、一方のリージョンが高負荷になった場合に自動でもう一方へトラフィックを振り替える。EU向けのマルチリージョンも追加リージョンを含めて提供予定であり、地域単位でのデータレジデンシーを保ったままリージョン容量制約への耐性を持たせられる。実装上の変更点は、APIのベースURLをリージョン固有の識別子（例: locations/us-central1）から地域単位の識別子（locations/us）に切り替えるだけで、アプリケーション側のルーティングロジックを自前で持つ必要がない。プロンプトキャッシュについても、キャッシュが存在するリージョンへ優先的にルーティングしつつ、そのリージョンが過負荷なら別リージョンへバランスする仕組みが組み込まれている。

実装・運用のポイント

クロスリージョン推論はAZ障害への備えではなく、リージョン単位のRTO/RPOを満たすための独立した設計レイヤーとして扱う。

DR設計をリージョン障害対応として機能させるには、次の3点を押さえる。

1. データレジデンシー要件との整合: Global CRISは可用性を最大化する一方、リクエストが地理的境界を越えうるため、規制上リージョン限定が必須なワークロードにはGeographic CRISまたは単一地域限定の構成を選ぶ
2. クォータとバーンダウンレートの事前検証: Global CRISでは一部モデルの出力トークンに5倍のバーンダウンレートが適用されるため、想定スループットに対して十分なクォータを申請しておく
3. 既存の耐障害性パターンとの階層分離: サーキットブレーカーやバックプレッシャーは同一リージョン内の過負荷・部分障害を吸収する層、クロスリージョン推論はリージョン単位の障害を吸収する層として役割を分け、どちらか一方に依存しない

RTO/RPOの目標値はビジネス要件から逆算し、それを満たせるルーティング方式（Geographic/Global CRIS、Vertex AIのマルチリージョンエンドポイント、あるいは複数クラウドをまたぐフェイルオーバー構成）を選定する。マルチリージョンのエージェント基盤設計を検討する場合は、Kuu株式会社のRDEサービスにご相談ください。

参考

• Geographic cross-Region inference — Amazon Bedrock
• Global cross-Region inference — Amazon Bedrock
• Multi-Region Endpoints for Claude on Vertex AI — Google Cloud Blog
• Resilience in Amazon Bedrock AgentCore

まとめ

エージェント基盤のDR設計は、AZ障害を前提にした既存の耐障害性パターンとは別のレイヤーで組む必要がある。AWS BedrockのGeographic/Global CRISとVertex AIのマルチリージョンエンドポイントは、いずれもデータレジデンシー要件を維持したままリージョン単位の障害・容量制約を吸収できる仕組みを提供する。RTO/RPOをビジネス要件として明文化し、それに見合うルーティング方式を選ぶことが、単一リージョン依存を脱するための最初の一歩になる。

エンタープライズ規模のエージェント基盤のDR設計を支援する場合は、Kuu株式会社のRDEサービスにご相談ください。