PTCはClaudeが書いたPythonがコード実行コンテナ内でツールを呼ぶ仕組みで、中間結果がコンテキストに入りません。
通常のツール呼び出しは、1回ごとにモデルが推論し、結果をそのままコンテキストへ戻す。PTCではClaudeがPythonコードを生成し、サンドボックス化されたコンテナで実行する。コードがツール関数を呼ぶたびに実行が一時停止し、APIが tool_use ブロックを返す。クライアントが結果を返すとコードが再開し、全処理の完了後に最終出力だけがClaudeへ渡る。
ツールは非同期のPython関数として公開されるため、asyncio.gather による並列実行もできる。ループ・条件分岐・集計がモデルの再サンプリングなしで完結する点が本質だ。前提は code_execution_20260120 以降のコード実行ツールで、対応モデルは公式ドキュメントの一覧で確認する。
公式評価では75ツールの構成で入力トークンが約38%減ったが、逐次の単発呼び出しでは約8%増えました。
公式ドキュメントが示す数値は次のとおりだ。
向くのは、多数の対象への扇形の呼び出し（50エンドポイントの確認など）、大きな結果を絞り込んでから渡したい処理、反復的な検索だ。向かないのは、前の結果をモデルが毎回判断する厳密な逐次処理や、小さな応答が少数あるだけの処理で、コンテナ起動とスクリプト生成の固定オーバーヘッドが勝る。導入前に allowed_callers の有無で課金入力トークンを実トラフィックで比較する。
allowed_callersは各ツールの呼び出し元を指定する設定で、directとコード実行のどちらかに寄せるのが推奨です。
ツール定義に "allowed_callers": ["code_execution_20260120"] を付けると、そのツールはコード内から呼べる。省略時は ["direct"] だ。両方を指定することもできるが、公式はClaudeへの指針を明確にするため、ツールごとにどちらか一方を選ぶよう勧めている。
分類の目安は次の2つだ。
統制上の最重要点がある。allowed_callers は提示方法の制御であり、API側の強制ブロックではない。公式は「セキュリティ境界として頼らない」と明記している。クライアントは、定義した任意のツールに direct の tool_use が来ても処理できる必要がある。実行可否の判定は、ポリシーエンジンや権限チェックを自前のツール実行層に置く。
callerフィールドで呼び出し元を記録し、コンテナの有効期限と約4分のタイムアウトを監視に組み込みます。
各 tool_use ブロックには caller が付く。直接呼び出しなら {"type": "direct"}、PTCなら code_execution_20260120 と tool_id が入る。tool_id は該当コード実行の server_tool_use の id なので、監査ログに記録すれば「どのコード実行がどのツールを何回呼んだか」を追跡できる。
運用上の制約も押さえる。
TimeoutError が発生するtool_result だけを入れる（テキストの併記は不可）strict: true のツール、MCPコネクタ経由のツール、computer use・browser useのツールセットは対象外ツール結果は文字列としてコード実行環境に渡る。外部入力を含む結果は、コードとして解釈されるリスクがあるため検証してから返す。レート制限は通常のツール呼び出しと同じで、コード内の1回の呼び出しが1回として数えられる。
エンタープライズでは、対象ツールの分類、監査ログ、ZDR要件の確認を導入前に済ませます。
大規模環境では、ツールカタログ単位で「コード側に寄せる」「direct 固定」を台帳化し、変更をレビュー対象にする。ZDRが契約要件なら、PTCは対象外なので適用範囲から外す。自社基盤でコード実行を管理したい場合は、ネットワーク遮断のサンドボックスと、ツール呼び出しのブリッジを自作する選択肢もあるが、構築・保守の負荷は大きい。設計と統制の整備は、RDE（Reinvention Deployed Engineering）の枠組みで内製チームと伴走できる。ツール数が多い場合は、Tool Searchによる定義の絞り込みと併用すると、定義と結果の両面でトークンを抑えられる。コード実行の隔離はツール実行サンドボックスの設計も参照したい。
PTCは、大きな結果の絞り込みや多数対象への呼び出しでトークンと往復を減らす一方、逐次の単発呼び出しではコスト増になり得ます。allowed_callers は境界ではなく指針なので、権限判定は自前の実行層に置き、caller を監査ログに残してください。ツール分類や適用判断の設計でお困りの場合は、Kuu株式会社のRDEへご相談ください。
一方で、カードに何を書くかを誤ると、公開してはいけない情報まで外に出てしまいます。本記事では、MCP公式のSEP-2127をもとに、カードの役割と、中小企業が公開側として決めておくべき設計判断を整理します。
MCPサーバーカードは、接続前に取得できるサーバーの公開メタデータ文書です。2026年1月提案のSEP-2127で、拡張（Extensions Track）として最終承認されました。
MCP（Model Context Protocol）の従来の探索は、接続先が分かって初めて使える実行時のやり取りでした。サーバーカードはこの手前を補います。クライアントやレジストリが、接続を開く前に名前・バージョン・説明、リモートの接続先URL、対応するプロトコルバージョンを読み取れます。
SEP-2127が挙げる効果は3つです。
サーバーカードは任意の拡張です。カードを公開しないサーバーも、従来どおり動作します。
カードの推奨配置は、Streamable HTTPのURL末尾に「/server-card」を付けた場所です。ドメイン単位の発見にはAI Catalogを使います。
SEP-2127によれば、カードは予約されていない任意のURIに置けます。そのうえで、/.well-known/ai-catalog.json に置くAI Catalogがカードへのリンクを持つ形で担います。.well-known は RFC 8615 で定められた、サービス発見の標準的な置き場所です。
配信上の細かい規定（メディアタイプ、CORS、キャッシュ）は、拡張リポジトリの docs/discovery.md が正本です。SEP本文は最終化時点の記録にすぎないため、実装時は必ず現行の拡張仕様を確認してください。
カードに載せるのは名前・バージョン・接続先・対応バージョンまでです。ツールやリソースの一覧は、仕様上あえて含まれません。
カードが持つのは、name / version / description と、任意の title / icons / repository / websiteUrl、リモートの接続エンドポイント、対応プロトコルバージョン、名前空間付きの _meta です。
ツール・リソース・プロンプトの定義は意図的に除外されています。理由はSEPに明記されています。サーバーが公開する内容は、認証ユーザーや設定、デプロイ状態で変わります。静的な文書では正確に表せず、クライアントが古い情報を信じる危険が生じるためです。
したがって、権限や安全性の判断をカードに頼ってはいけません。実際のツール一覧は、接続後に tools/list などで認証済みの身元とともに確認します。
SEPはさらに、カードは公開文書であるため、認証情報、社内ネットワーク構成、独自ロジック、利用者固有のデータを含めてはならないとしています。
公開側で決めるのは、カードの要否、記載項目のレビュー、更新責任者の3点です。まず自社の公開範囲を棚卸しします。
着手手順は次のとおりです。
また、カードとライブ探索（server/discover）の値が食い違う場合、クライアントは後者を優先するべきだとされています。カードは参考情報という位置づけを前提に運用してください。大規模な組織向けの統制設計はエンタープライズ向けのMCPレジストリ設計も参照してください。
取得したカードは「入口の案内」にすぎません。接続前の信頼判断には使わず、導入審査は従来の確認手順で行います。
外部のMCPサーバーを導入する側では、カードで接続先を自動設定できても、それは信頼の証明ではありません。カードはHTTPSで取得し、証明書検証を有効にします。導入可否は導入前の5つの確認観点に沿って、出所・権限範囲・実行場所を確認します。SEPも、カードが侵害された場合の影響は主に発見性にとどまるとしつつ、クライアントが実行時のメタデータで検証することを前提にしています。
MCPサーバーカードは、接続前の発見を助ける任意の公開メタデータです。載せるのは接続情報まで、ツール一覧や認証情報は載せない。この線引きが設計の核心です。
自社MCPサーバーの公開範囲の棚卸しや、導入審査の手順化は、Kuu株式会社のAI運用管理サービスでご支援しています。お気軽にご相談ください。
]]>IT専任者が少ない中小企業にとって現実的なのは、攻撃を全部検知することではなく、被害が成立する構成そのものを避けることです。本記事では「Lethal Trifecta（致命的な三要素）」を軸に、設計段階で外すべき要素を決める手順を整理します。関連する防御層はプロンプトインジェクション5層防御も参照してください。
Lethal Trifectaは、私的データへのアクセス・信頼できない入力・外部通信の3つが揃ったエージェントで、データ窃取が成立するという整理です。
開発者のSimon Willisonが2025年6月に提示した枠組みで、3要素は次のとおりです。
LLMは指示がどこに書かれていても従ってしまうため、3つが揃うと攻撃者の文章1つで漏えいが成立します。OWASPのLLM01も、外部のWebサイトやファイルを取り込む間接プロンプトインジェクションを主要な攻撃経路として挙げています。
検知は確率的な対策であり、取りこぼしが1件でもあれば3要素が揃った構成では漏えいに直結します。
Willisonは、検知率95%をうたう製品でもWebセキュリティでは不合格に等しいと指摘しています。OWASPが挙げる緩和策（出力形式の検証、入力・出力フィルタ、最小権限、高リスク操作の人間承認、外部コンテンツの分離）も、組み合わせて被害を減らす位置づけです。
したがって優先順位は、(1) 3要素のうち1つを構造的に外す、(2) 残る要素は権限とネットワークで絞る、(3) その上で検知を重ねる、の順になります。
1つの業務フローに3要素が同居していないかを棚卸しし、最も外しやすい要素を1つ削るのが最短の手順です。
エージェントごとに、次の表を埋めてください。
3つとも「ある」業務フローが見つかったら、次のいずれかを選びます。
Claude CodeのBashサンドボックスは、shellコマンドの通信先を
network.allowedDomainsで絞ることで外部通信の要素を弱められます。
公式ドキュメントによると、サンドボックスのネットワークは許可ドメインが空の状態から始まり、プロキシが接続先ホストを照合します。v2.1.219以降では、strictAllowlistをtrueにすると許可外のホストをプロンプトなしで拒否できます（リポジトリ内の.claude/settings.jsonに書いても無効です）。
``json``
{
"sandbox": {
"enabled": true,
"network": {
"allowedDomains": ["github.com", "*.npmjs.org"],
"strictAllowlist": true
}
}
}
ただし範囲には注意が必要です。公式ドキュメントは、サンドボックスがカバーするのはshellコマンドのみで、Read・Edit・Write・WebFetch・WebSearchなどの組み込みツール、MCPサーバー、フックは対象外と明記しています。allowedDomainsはWebFetchを制限しません。WebFetchやMCP経由の外部通信は、別途権限ルールで絞ります。認証情報の読み取りはsandbox.credentialsで遮断できます。詳細はBashサンドボックス実装ガイドを参照してください。
検知に頼る前に、3要素が同居する業務フローを特定し、1要素を外す設計判断が最初の一手です。
自社のエージェント構成の棚卸しや権限設計の見直しは、Kuuの運用管理サービスでご相談いただけます。
最終出力が正解でも、途中のツール呼び出しが誤っていれば再現性のない偶然の正解にすぎない。
LLM-as-judgeで最終出力を採点する設計は多くのチームが導入済みだ。しかし最終出力の正しさと、プロセスの正しさは別物だ。たとえば在庫確認エージェントが本来呼ぶべきcheck_inventoryではなくsearch_catalogを呼び、たまたま同じ結果を返したケースは、次のリクエストでは失敗する。ツール呼び出しの選択・引数・順序を個別に測定しないと、こうした脆さは本番で初めて露見する。
ツール呼び出しの評価は、ツール選択の正誤・引数の正確性・呼び出し順序を分けて測定する3指標に分解できる。
OSSの評価フレームワークRAGASは、エージェント専用の指標としてToolCallAccuracyとToolCallF1を定義している。前者はツール呼び出しの順序と引数の一致度を評価し、引数の一致率に順序一致の有無を掛け合わせてスコアを出す仕組みだ。厳密な順序一致（デフォルト）と、順序を問わない柔軟モードの2種類がある。後者のToolCallF1は呼び出しすぎ・呼び出し漏れを許容し、期待される呼び出しとの一致を適合率・再現率・F1で評価する。
実務では3指標に分けて記録するとよい。
この3つを個別に可視化すると、「ツールは正しく選べているが引数でよく間違える」のような具体的な弱点が見える。
Claude Agent SDKは
PreToolUse/PostToolUseフックでツール呼び出しの前後を捕捉でき、評価用ログに転用できる。
ツール呼び出しを評価するには、まず呼び出しの記録が必要だ。Claude Agent SDKのエージェントループは、Claudeがツール呼び出しを要求するたびにAssistantMessageを発行し、SDKがツールを実行した結果をUserMessageとしてClaudeに返す。この一往復が1ターンであり、PreToolUseフックで実行前のツール名・引数を、PostToolUseフックで実行後の結果を捕捉できる。フックはアプリケーション側のプロセスで動くため、エージェントのコンテキストウィンドウを消費しない。
セッション終了時に発行されるResultMessageには、ツール呼び出しを含む全ターン数とトークン使用量・コストが記録される。この2つのフックとResultMessageの組み合わせで、期待されるツール呼び出し列（reference）と実際の呼び出し列を記録し、オフラインでRAGASのような指標に通せる評価データセットを作れる。
SMBチームはまず5〜10タスクの期待呼び出し列を手作業で定義し、そこから指標を自動計算する構成が現実的だ。
大規模な評価基盤を最初から作る必要はない。
ステップ1: 代表的なタスク5〜10件について、期待されるツール呼び出し列（ツール名・引数・順序）を手作業でYAMLやJSONに書き出す
ステップ2: PreToolUseフックで実際の呼び出しをログに記録し、ステップ1の期待値と突き合わせる
ステップ3: 選択精度・引数精度・順序整合性の3指標を週次で集計し、どの指標が低いかを追跡する
AIエージェントのトレース計装を既に導入している場合は、そのログをそのまま期待値との突き合わせに再利用できる。ツール呼び出し評価の設計から運用まで、Kuuのai-opsで支援している。
ツール呼び出しの精度は、最終出力の採点だけでは見えない。選択・引数・順序の3指標に分解し、Claude Agent SDKのフックで呼び出しログを記録すれば、SMBチームでも5〜10タスクの期待値定義から評価を始められる。
ツール呼び出し評価基盤の設計に関するご相談はKuu株式会社のai-opsまで。
]]>Scheduled Deploymentsはエージェントがセッションを自律的に開始する仕組みで、Deployments APIで作成・管理します。
デプロイメントの作成には、エージェント設定と環境設定が必須で、ファイル・GitHub・メモリストア・Vaultは任意で添付できます。制約が1つあり、自己ホスト環境はメモリストアを添付できますが、fileとgithub_repositoryリソースはクラウド環境でしか使えません。さらに各セッションの最初の動作を指定するuser.messageまたはuser.define_outcomeのいずれかを初期イベントとして持たせる必要があります。これが無いと「何をすべきか」が定まらず起動できません。1組織あたり最大1,000件のスケジュールデプロイメントをサポートしています。
schedule はcron式とIANAタイムゾーンで構成され、分単位が最小粒度で、実行には最大15%のジッターが入ります。
scheduleオブジェクトは標準POSIX cron式（分 時 日 月 曜日）とタイムゾーン識別子（例: America/New_York）を持ち、最小粒度は分単位です。重要なのは時刻の解釈方法で、cronはウォールクロック（壁掛け時計）照合のため、"0 20 *"はEST/EDTのどちらであっても現地時間20:00に発火します。この設計はサマータイム境界で2つの罠を生みます。春の時刻繰り上げで存在しない時刻（深夜2時台など）は発火せず、秋の時刻繰り戻しで2回出現する時刻は2回発火します。公式ドキュメントは、欠落や重複実行が許容できない処理は現地時間1〜3時台を避けるか、UTCでスケジュールするよう明記しています。加えて、実際の発火は負荷分散のため実行間隔の最大15%（最小5秒・最大9分）のジッターを含むため、upcoming_runs_atに表示される時刻と実際の実行時刻は厳密には一致しません。
各試行は deployment run として記録され、セッションのライフサイクルとは独立に成功・失敗を追跡できます。
無人実行で最も重要なのは「失敗の可視化」です。Scheduled Deploymentsは、環境がアーカイブ済みだったりセッション作成がレート制限されたりしてトリガー自体に失敗した場合も、deployment runという記録を必ず生成します。成功時はrunにsession_idが入り、失敗時はerror.type（environment_archived_error・agent_archived_error・session_rate_limited_errorなど）が入ります。deployment_runsエンドポイントはhas_error=trueでのフィルタに対応し、失敗だけを抽出して監視できます。
ライフサイクル管理も障害モード別に設計されています。レート制限は即座にrunを記録して次回スケジュールまでリトライしません。エージェントがアーカイブされると、デプロイメント自体が同じ操作で自動アーカイブされ、runは記録されません。エージェントが削除された場合は次回トリガー時に検知して自動アーカイブします。一方、サブエージェントのアーカイブや環境・Vaultのアーカイブのように復旧しうる障害は、失敗runを記録した上でデプロイメントを自動pauseし、paused_reason.error.typeに原因を残します。復旧後はunpauseで次回の予定時刻から再開しますが、停止中に欠けた実行は遡って補完されません。デプロイメントの状態変化とrunの結果はwebhookイベントとしても配信され、ポーリングなしで検知できます。
budgetはセッション予算と同形式で、累積上限ではなく実行1回ごとの上限として各セッションにコピーされます。
デプロイメント作成・更新時に任意でbudgetオブジェクトを渡すと、その上限は実行ごとに新しいセッションへコピーされます。つまり1,000回実行されるデプロイメントの予算は、1,000回分の合計ではなく毎回リセットされる個別キャップです。上限に達したセッションは通常のセッションと同じくbudget_reachedで一時停止し、既に走っているセッションは変更後も開始時のキャップを保持します。budget: nullで予算設定自体を解除できる点は、通常のセッション予算にはない柔軟性です。
本番投入前のテストにはrunエンドポイントによる手動実行が使えます。これはtrigger_context.type: "manual"のrunを即時生成するもので、冪等性設計の確認や、ant applyでデプロイしたスケジュールの初回動作確認に向いています。cronを信じて待つ前に、同じ実行経路を手動で1回通しておくことが、深夜の無人失敗を減らす最も安い対策です。
エンタープライズでMulti-tenant構成や複数エージェントの定期実行基盤を構築する際は、障害分離とpause/archiveの運用ルールを事前に決めておく必要があります。KuuのRDEサービスでは、こうしたエージェント基盤の信頼性設計を支援しています。
Scheduled Deploymentsの設計は3つの層に分けられます。cronとタイムゾーンはウォールクロック照合とジッターでDSTと負荷集中を吸収し、deployment runはトリガーの成否をセッションのライフサイクルと独立に記録し、pause/archiveは障害の種類（一時的か恒久的か）に応じて自動で制御を切り替えます。無人で動くエージェントを安全に運用するには、この3層それぞれに監視とアラートを設計時点で組み込む必要があります。
]]>Claudeのモデルは定期的に非推奨化・退役する設計になっている。本記事では、そのライフサイクルの仕組みと、中小企業が無理なく移行計画を立てる手順を解説する。
Claudeモデルはactive・legacy・deprecated・retiredの4段階で管理され、deprecated時に後継モデルと退役日が示される。
Anthropicはモデルのライフサイクルを4段階で管理している。「active」は完全サポート中の推奨モデル、「legacy」は更新が止まり将来非推奨化される可能性がある状態、「deprecated」は動作はするが推奨されず後継モデルと退役日が明示された状態、「retired」はAPIリクエスト自体が失敗する状態だ。この区分はClaude API・AWS上のClaude Platform・Microsoft Foundryに適用され、Amazon BedrockやGoogle Cloud経由の利用では各プラットフォームが独自の退役日を設定する点に注意が必要だ。
公開済みモデルの退役には最短60日前の通知が義務付けられ、メールとドキュメントの両方で案内される。
本番環境でモデルを使っているアカウントには、退役の最低60日前に通知が届く。実際の運用では、2026年4月14日にClaude Sonnet 4・Opus 4の退役が通知され、同年6月15日に退役するという約2カ月のスケジュールで進んだ。通知を見落とさないためには、契約者個人のメールだけでなく、チームの共有チャンネルにも転送する運用を組み込んでおくとよい。
後継モデルでの事前テストを退役日より十分前に終え、段階的に本番トラフィックを切り替えるのが安全だ。
移行計画は3ステップで組める。まず非推奨化の通知を受けたら、ドキュメントの移行ガイドで後継モデルと変更点を確認する。次に、本番と同じプロンプト・ツール定義で後継モデルをテスト環境で動かし、出力品質とレイテンシーを比較する。最後に、退役日より余裕を持って本番のmodelパラメータを切り替える。あわせて、リクエストヘッダーのanthropic-versionは固定したまま使えるため、API自体の互換性を気にする必要はない。パラメータ側では、temperature・top_p・top_kがClaude Opus 4.7以降の一部モデルで非デフォルト値を渡すと400エラーになる変更も入っているため、プロンプト側での制御に切り替える移行も合わせて検討したい。
Claude ConsoleのUsageページからCSVをエクスポートすれば、APIキー・モデル別の利用実態を棚卸しできる。
どのコードがどのモデルを呼んでいるか分からなくなっている場合は、Claude ConsoleのUsageページから利用状況をCSVでエクスポートできる。APIキー・モデル別の呼び出し件数が確認できるため、非推奨化対象のモデルIDを使っている箇所を洗い出し、優先的に移行するリストを作る土台になる。
Claudeモデルの非推奨化は、最短60日前の通知を起点に、後継モデルでのテストと段階的な切り替えで乗り越えられる。モデル選定の基準を押さえている企業ほど、移行時の後継モデル選びに迷わない。通知の見落としを防ぐ体制作りから、まずは着手するとよい。
Kuuのエージェントガバナンスサービスでは、モデル運用の体制整備から移行計画の設計までサポートしている。
]]>Skills over MCPはSEP-2640で確定したMCP公式拡張で、既存のResourcesプリミティブ上でSKILL.mdを配信します。
SEP-2133が定めた拡張ガバナンスの枠組みに沿って登録された公式拡張の一つがio.modelcontextprotocol/skillsです。SEP-2640としてStatus: Finalに達し、ext-skillsリポジトリで仕様が公開されています。既存のMCPプロトコルに新しいメッセージ型を追加するのではなく、skills/list・skills/getという2つのメソッドと、既存のresources/readを組み合わせて、SKILL.mdと付随ファイルを配信する設計です。サーバーはserver/discoverのレスポンスでresourcescapabilityとextensions内のio.modelcontextprotocol/skillsを宣言した場合のみ、この拡張に対応しているとみなされます。
skills/listはSKILL.mdと付随ファイルのURI・SHA-256ダイジェスト・バイトサイズを含む完全なマニフェストを返します。
クライアントはskills/listでページング対応の一覧を取得し、各エントリに含まれるfrontmatter（name・description等）とファイルマニフェストからスキルを選別します。URIを直接知っている場合はskills/getで個別取得でき、一覧に出てこない非公開スキルも読み込めます。実際のSKILL.md本文やreferences/配下のファイルはresources/readで取得する設計で、MCPの既存プリミティブを再利用する点がこの拡張の特徴です。ディレクトリ一覧が必要ならresources/directory/readを使いますが、これはdirectoryRead: trueを宣言したサーバーのみが対応します。
ホストはSKILL.md読込時にSHA-256ダイジェスト・バイトサイズ・frontmatterをマニフェストと照合する必要があります。
仕様はホスト側の実装要件を細かく定めています。スキルの承認はマニフェスト全体（ファイルURIとダイジェストの組）に対して発行され、1ファイルでも変更・追加・削除があれば承認は失効し、再承認が必要です。読み込んだコンテンツは発信元サーバーのラベルを付けて保持し、別サーバーのリソースを読むクロスサーバー読み込みは明示的な個別承認を要します。サーバー1件あたりはSKILL.mdを含めて512ファイル・16MiB以内に収めることが推奨され、ホストはこの上限まで対応する必要があります。スキル本体はエージェントガバナンス上「信頼できない入力」として扱い、allowed-toolsのような権限付与は個別承認を経由させます。
GitHubの自動読込・マーケットプレイス配布・Skills over MCPは、信頼境界を設計する層が異なる3つの経路です。
Managed AgentsのGitHub自動読込はリポジトリマウント時にレビューなしで読み込む設計で、マーケットプレイス経由の配布は審査プロセスが信頼の起点でした。Skills over MCPはこの両者と異なり、プロトコルレベルでサーバーのcapabilities宣言とホスト側の検証・承認フックを強制する点が差分です。MCPサーバーを本番で運用するプラットフォームエンジニアリングの観点では、どの経路で入ってきたスキルも最終的にはこの検証ロジックを通す設計にしておくと、配布経路が増えても信頼境界を一本化できます。
Skills over MCPは、MCPの既存プリミティブを使ってAgent Skillsを配信する公式拡張として確定しました。重要なのは新しいメッセージの追加ではなく、ダイジェスト検証・マニフェスト単位の承認・クロスサーバー制限という、ホスト側に課される検証義務の設計です。自社のMCPホストやエージェント基盤を運用している場合、スキルの入り口が増える前に、この検証ロジックを一箇所に集約しておくことをお勧めします。KuuではRDEとして、こうしたプロトコル拡張への追従と信頼境界の設計を支援しています。
]]>Compaction On Demandは、圧縮の実行タイミングをAPIではなくアプリ側が選べる新しい圧縮方式だ。
ベータヘッダーcompact-2026-09-04を付け、リクエストに"compaction": {"type": "summarize"}を含めると、Claudeはそのリクエストの会話全体を要約したcompactionブロックだけを返す。応答は生成されず、stop_reasonは"compaction"になる。このブロックには要約テキストと署名（signature）が入り、以降のリクエストでは要約済みのメッセージを削除し、ブロックをmessagesの先頭に置いて送り直す。既存の閾値圧縮（compact-2026-01-12）はAPIが判断してブロックを通常の応答に続けて返すが、Compaction On Demandは圧縮専用のリクエストを明示的に送る点が根本的に異なる。
トークン予算を超えたら圧縮リクエストを送り、返るブロックで履歴全体を置き換える。
実装パターンは単純だ。各ターンの応答からinput_tokens + output_tokensを累積し、設定した閾値を超えたら次のユーザー発話を待たずにcompactionパラメータ付きリクエストを送る。stop_reasonが"compaction"であれば、履歴を「返ってきたcompactionブロックを含むアシスタントメッセージ1件」に完全に置き換える。追記ではなく置換であることが重要で、要約済みのメッセージが先頭以外に残っていると次のリクエストはcompaction_block_misplacedエラーで400になる。要約プロンプトはinstructions（最大16,384字）で独自のものに置き換えられ、特定のエンティティ名や未解決の依頼を残すよう指示できる。この要約呼び出し自体の課金はusage.iterationsのcompactionエントリに記録され、トップレベルのinput_tokens/output_tokensはゼロになる。
要約が得られない場合もAPIは200を返すため、
stop_reasonで成否を判定する。
要約呼び出しがテキストで終わらず終了した場合（max_tokensで途切れた、ツールを呼んでしまった、拒否された等）、レスポンスは200のままブロックを含まない。stop_reasonが"max_tokens"ならmax_tokensを増やして再送し、"tool_use"なら「ツールを呼ばない」と明示したinstructionsを付けて再送する。"refusal"や"end_turn"の場合は要約なしで続行し、次のターン終了後に再試行すればよい。ブロックそのものを送り返すリクエストが失敗する場合は、signatureやcontentを1バイトも変更せずそのまま送っているかを確認する。改変するとcompaction_signature_invalidで400が返る。529のcompaction_unavailableは一時的な障害なので、そのリクエストをそのまま再試行する。
ミッド会話システムメッセージの指示は圧縮範囲に含まれると失効し、画像やドキュメントも圧縮後は参照できなくなる。
圧縮されたメッセージ範囲に入っていたrole: "system"の指示は要約に埋もれて効力を失うため、まだ必要な指示は圧縮後の最初のユーザー発話の直後にミッド会話システムメッセージとして再送する必要がある。Preserved Thinking対応モデルで直近ターンのthinkingを保持する場合は、systemとツール定義が圧縮リクエストと以降のリクエストで一致している条件を満たす必要がある。また、画像・ドキュメント・container_uploadブロックは要約に置き換えられると内容が失われるため、後のターンで必要なら再アップロードする設計にする。タスク予算のremainingを指定したまま圧縮リクエストを送ると400になる点も実装時の落とし穴だ。複数チームが共有するエージェント基盤でこうした圧縮設計を標準化したい場合は、Kuuの大規模実装支援（RDE）でハーネス全体の設計レビューを行っている。
Compaction On Demandは、圧縮を「API側が閾値で自動実行するもの」から「アプリ側が任意のタイミングで要求するもの」に変える設計転換だ。履歴の置換ルールとエラーハンドリング、ミッド会話システムメッセージやPreserved Thinkingとの相互作用を正しく実装すれば、長時間稼働するエージェントでも会話の連続性を保ったまま圧縮タイミングを自社のワークロードに合わせて制御できる。自社のエージェント基盤への組み込みはKuuの運用管理サービス（AI-Ops）でも相談できる。
]]>ハイブリッドLLM基盤とは、機密度に応じてローカルのOllamaとクラウドのClaude APIへ推論を振り分ける構成です。
専任のインフラ担当者がいない中小企業でも、議事録の要約や社内FAQ応答のように個人情報を含むタスクはローカルの小型モデルで処理し、複雑な推論や長文解析はClaude APIに任せる、という二段構えの設計が現実的な選択肢になっています。全部をクラウドに出す設計は機密情報の扱いで慎重な判断が要り、全部をローカルで処理する設計は複雑なタスクで精度が不足しがちです。ハイブリッド構成はこの両極の間を、リクエスト単位の振り分けで解決します。
ハイブリッド構成が向くのは、専用GPUを増設せずにAPIコストと機密情報の扱いを同時に抑えられるためです。
Ollamaは自分のPCやオンプレのサーバー上でモデルを動かし、テキストが外部に送信されない設計です。これにより、個人情報や契約情報を含む下書き作業はローカルで完結させ、API呼び出し自体を発生させません。一方で、込み入った文書解析やコード生成のような精度が要るタスクは、API利用分だけ課金されるClaude APIに振り分けることで、GPUサーバーを常時起動させておくコストを避けられます。どちらも「全部を自前インフラで持つ」「全部を外部APIに出す」という二択を避けるための構成です。
ルーティングは、データの機密度・タスクの複雑度・システムの可用性という3つの軸で振り分け先を判断します。
LiteLLMのようなAIゲートウェイをアプリケーションとモデル群の間に置くと、OllamaやvLLMのローカルモデルとClaude・OpenAI・Geminiなどのクラウドモデルを単一のエンドポイントの背後にまとめ、モデルエイリアスとフォールバックチェーンで振り分け先を切り替えられます。個人情報を含む入力はローカルモデルに固定し、ローカルモデルが落ちている場合やタスクが複雑と判定された場合にのみクラウドへフォールバックする、という構成が典型です。ゲートウェイ側でリクエストごとのコストと利用量を記録できるため、どの業務がどれだけAPIコストを使っているかも同時に可視化できます。
Claude APIはinference_geoパラメータでus/globalを指定でき、Claude 4.6以降のモデルで利用できます。
ハイブリッド構成でクラウド側に振り分けたリクエストについても、データの処理地域を制御する手段があります。Claude APIのinference_geoパラメータはPOST /v1/messages呼び出しごとに設定でき、"global"（既定・最適なパフォーマンス優先）と"us"（米国内インフラのみで推論）のいずれかを選べます。"us"を指定した推論は、入力・出力トークン・キャッシュ書き込み・読み取りのすべてで標準料金の1.1倍となり、ワークスペース単位でdefault_inference_geoやallowed_inference_geosを設定して組織全体の既定動作を固定することもできます。米国内処理が必須の契約がある場合は、この設定をルーティングポリシーの一部として明示しておく必要があります。
Ollamaは既定でlocalhost:11434にのみ応答し認証機能を持たないため、外部公開時は別途認証層が必要です。
Ollamaのローカルサーバーはポート11434でlocalhostにバインドされ、ローカルからのリクエストには認証を要求しません。社内の複数端末からOllamaサーバーへアクセスできるようにネットワーク越しに公開する場合、Ollama自体にはアクセス制御の仕組みが無いため、リバースプロキシや上述のAIゲートウェイ側でAPIキー・IP制限・利用者ごとのロギングを追加する設計が前提になります。ローカルモデルだからといって無条件に安全というわけではなく、エージェントの権限管理と同じ発想で、誰がどのモデルにどこまでアクセスできるかを明示的に設計することが欠かせません。基盤の選定からルーティングポリシーの運用設計まで、Kuu株式会社のAI Opsで相談できます。
ハイブリッドLLM基盤は、機密度・複雑度・可用性の3軸でローカルのOllamaとクラウドのClaude APIにリクエストを振り分ける設計です。AIゲートウェイでルーティングとコストを一元管理し、クラウド側はinference_geoで地域を制御し、ローカル側は認証層を別途用意する——この3点を押さえれば、専用のインフラチームがいない中小企業でも段階的に導入できます。自社のデータ特性に合わせたルーティング設計は、Kuu株式会社にご相談ください。
]]>本記事はAIエージェントガバナンスのピラーコンテンツに連動しています。大規模な権限統制を検討する場合はKuuの RDEも参照してください。
Inference Hooksは、推論実行前に自社のAIセキュリティサーバーへ検証を委ね、許可・拒否の判定を得る仕組みです。Claude Enterprise限定のベータ機能です。
Inference Hooksは、Claude Enterpriseが持つ prompt と tool_call の2種類のフックイベントを、推論が走る前にHTTPS POSTで自社のAIセキュリティサーバーへ送る機能です。prompt は統制対象の推論リクエストごとに、tool_call は「ツール呼び出しを検証」を有効にした組織でClaudeの応答にツール呼び出しが含まれるたびに発火します。送信対象はclaude.ai・Cowork・Claude Code・Claude Tag（Slack）の全セッションで、1つのフック設定が全プロダクトに適用されます。構成には organization:manage 権限（OwnerまたはPrimary owner）が必要です。
リクエストはStandard Webhooks仕様で署名され、検証サーバーは
{"action": "allow"}または拒否理由付きのJSONを返します。
AnthropicのサーバーはあなたのAIセキュリティサーバーへ、会話のトランスクリプト・ツール呼び出しとその結果・添付ファイルから抽出したテキストを送信します。生のファイル・画像バイト、システムプロンプト、Anthropic内部コンテキストは送られません。各リクエストはStandard Webhooks仕様で署名され、署名シークレットは組織が生成します。検証サーバーはデフォルト5秒のタイムアウト内に、許可なら {"action": "allow"}、拒否なら deny_reason フィールドにユーザー向け理由を含めたJSONを返します。拒否時はユーザーに「ブロック理由+管理者設定の標準メッセージ」が表示され、Activity Feedに記録されます。Inference Hooks自体はプロンプト・レスポンスの内容を保存せず、フック設定と検証メタデータ（判定・タイムスタンプ・リクエストID）のみを保持します。
サーバー無応答時はフェイルオープン（許可）かフェイルクローズ（拒否）を組織が選び、継続障害時はサーキットブレーカーが作動します。
AIセキュリティサーバーが応答不能・エラー・タイムアウト超過の場合、組織が設定した失敗時挙動（フェイルオープンでリクエストを許可する、またはフェイルクローズでブロックする）が適用されます。障害が継続すると、Anthropic側でサーキットブレーカーが作動し、サーバーへの問い合わせを停止して全リクエストに失敗時挙動を適用し、正常な判定が戻り始めると自動的に復帰します。ロールアウトも段階的に設計できます。シャドーモードで実トラフィックの判定結果だけを観測し、ブロックせずに検証する、ロールアウト比率で検査対象の割合を絞る、特定ロールを除外する、といった運用が選べます。
典型用途はDLP・リアルタイム記録・利用実態の計測で、画像バイト検査や応答側の拒否には未対応です。
主な用途はDLP（規制対象・機密情報を含むプロンプトの拒否）、ポーリング不要なリアルタイムのトランスクリプト保存、利用実態の計測、モデル許可リストや業務時間制限などの独自ポリシーエンジンです。一方で現時点の制約も明確です。添付ファイルはメタデータと抽出テキストのみが対象で、スクリーンショットのような画像オンリーのコンテンツは検査できません。判定は許可/拒否の二値で、プロンプトの書き換え・レダクションは未対応です。APIアクセス経由のPlatform組織は対象外で、Bedrock・Google Cloud経由の利用にも提供されません。Claudeの会話タイトル生成や、Claude Security scans・Code Review・smart reportsのようにAnthropicが自組織向けに実行する内部呼び出しも、統制対象リクエストには含まれません。
既存のCompliance APIはAnthropicのAPIを呼んで「事後に」記録を取得する仕組みです。Inference Hooksはこれと逆方向で、Anthropicが自社サーバーを呼んで「推論前に」止める仕組みであり、両者は補完関係にあります。推論前にブロックしたいならInference Hooks、事後にeDiscoveryや監査証跡が必要ならCompliance APIを使う、という使い分けになります。
Inference HooksはClaude Enterprise限定のベータ機能であり、構成には組織全体の権限管理と、HTTPSで常時応答可能なAIセキュリティサーバーの運用体制が前提になります。中小企業がClaude Teamなど別プランで同等の統制をしたい場合は、Claude Codeのhooks機構のようなクライアント側の仕組みで代替を検討するのが現実的です。エンタープライズでは、既存のDLPベンダー（Netskope・Palo Alto Networks・Proofpoint・Zscaler等）や自社セキュリティ基盤とこのWebhookを接続し、まずシャドーモードで判定の精度を検証してから、ロールアウト比率を段階的に上げる設計が安全です。
Inference Hooksは、プロンプトがモデルに渡る前に自社のAIセキュリティサーバーで許可・拒否を判定する、Claude Enterprise限定のベータ機能です。Standard Webhooks署名・5秒デフォルトタイムアウト・フェイルオープン/クローズの選択・サーキットブレーカーという運用設計が用意されている一方、画像検査や応答側の拒否は未対応という制約もあります。導入を検討する場合は、まずKuuの RDEにご相談ください。
]]>Claudeは画像を28×28ピクセルの「視覚トークン」単位で見るため、コストは幅÷28と高さ÷28の積（切り上げ）で決まります。
公式ドキュメントが示す計算式は⌈幅/28⌉ × ⌈高さ/28⌉視覚トークンです。モデルには2段階の解像度上限があり、Claude 4.7以降の「高解像度」モデルは長辺2576px・最大4,784トークンまで処理し、それ以外のモデルは長辺1568px・最大1,568トークンが上限です。上限を超える画像はアスペクト比を保ったまま自動縮小されます。
具体例として、1000×1000px（約100万画素）の画像はどちらの階層でも縮小されず1,296トークン消費します。これをHaiku 4.5（入力$1/MTok）で処理すると1,000枚あたり約1.3ドル、Opus 5（入力$5/MTok）の高解像度処理でも1,000枚あたり6.48ドルです。一方、3840×2160pxの4K画像は高解像度帯で4,784トークンまで積み上がり、Opus 5では1,000枚あたり約23.9ドルになります。モデルと解像度の組み合わせで10倍近いコスト差が出る計算です。
1リクエストに21枚以上の画像を含めると、全画像に長辺2000px以下という厳しい制限が自動適用されます。
APIの上限は200Kコンテキストモデルで1リクエスト最大100枚、それ以外は600枚です。ただし20枚を超えた瞬間に、会話履歴で再送される過去の画像やtool_result内のスクリーンショットも含めた全画像に、より厳しい寸法制限がかかります。超過するとinvalid_request_errorで拒否されるため、複数画像を扱うバッチ処理では事前リサイズが前提になります。
さらに重要なのが再送コストです。Base64で画像を埋め込むと、マルチターンの会話では過去の画像も毎リクエスト再送され、ペイロードと処理トークンが膨張します。繰り返し参照する画像はFiles APIで一度アップロードし、以降はfile_idで参照する設計にすると、リクエストサイズを会話の長さに依存させずに抑えられます。
検品の合否判定や商品カテゴリ分類など文字を読まない用途では、解像度を上げても精度は上がらずコストだけ増えます。
高解像度帯は本来、密な文書や画面内の小さな文字を読み取る用途向けです。色・形状・有無の判定が目的の検品チェックや商品分類タスクでは、200×200px程度の軽量な画像でも十分なケースが多く、無駄に高解像度画像を送るとコストだけが増加します。逆に、手書きメモや細かい仕様表を読ませる用途では圧縮しすぎると文字が潰れて誤読を招くため、JPEG圧縮は多重適用を避け、実際にAPIへ送る画像を目視確認することが推奨されています。
まず自社のユースケースを「判定系（色・形状・有無）」と「読み取り系(文字・数値)」に分類し、判定系は積極的に縮小、読み取り系のみ高解像度を許容する方針を決める。次に、同じ画像を複数ターンで参照する設計ならFiles API化を先に実装し、Base64再送によるコスト膨張を防ぐ。最後に、usageレスポンスの画像トークン数を本番投入前に実測し、見積もりとのズレを確認する。この3手順だけで、画像解析機能の運用コストはおおむね予測可能な範囲に収まる。
画像解析を含むAIエージェントの運用設計は、Kuuのエージェント運用管理サービスで設計支援を行っている。
Claude Vision APIのコストは「解像度」「枚数」「再送方式」という3つの変数で機械的に決まる。用途を判定系と読み取り系に分けて解像度を使い分け、繰り返し参照する画像はFiles API化するだけで、見積もり精度とコスト効率の両方が改善する。自社での設計に不安がある場合は、Kuuのエージェント運用管理サービスへの相談も検討してほしい。
]]>LLMエージェントの出力は実行ごとに変動するため、1回の合否判定だけでは改善と偶然を区別できません。
エージェントは同じ入力・同じプロンプトでも、サンプリングのランダム性やツール呼び出しの順序、外部APIの応答タイミングによって結果が変わります。1回だけ実行して「成功したから直った」「失敗したから悪化した」と判断すると、本当は変わっていないのに評価結果だけが上下して見える事態が起きます。これは特にプロンプト変更やモデルのバージョンアップを判断する場面で危険です。1回の成功で本番にリリースし、翌週に同じ不具合で問い合わせが増える——という失敗は、複数回の実行結果を見ていれば避けられたケースがほとんどです。各試行をトライアルと呼び、エージェント評価ではこのトライアルを複数回積み重ねて初めて意味のある判断ができます。
pass@kはk回中1回でも成功する確率、pass^kはk回すべてが成功する確率を測る指標です。
Anthropicのエージェント評価に関する技術記事では、複数トライアルの結果を集約する指標としてpass@kとpass^kの2つを提唱しています。pass@kは「k回の試行で少なくとも1つ正解を得る確率」、pass^kは「k回すべてが成功する確率」を表します。使い分けの基準は製品要件です。1回でも成功すれば十分な用途（情報検索ツールの呼び出しなど）はpass@kで評価し、毎回同じ品質が求められる用途（顧客対応の自動応答など）はpass^kで評価します。1回あたりの成功率が75%のタスクで3回連続成功する確率は0.75の3乗で約42%にしかなりません。一貫性を求めるほど合格基準は厳しくなることを、この指標は数値で示してくれます。pass@kの統計的な推定方法は、コード生成モデルの評価で発表された不偏推定量の定義が元になっており、サンプル数が少ないと推定値の分散が大きくなることが知られています。
判断材料として最低3回、リリース可否のような重要な意思決定には5回以上のトライアルを目安にします。
学術的な検証では数百回のサンプリングで分散を抑えることが推奨されますが、中小企業の評価予算でそれを毎回行うのは現実的ではありません。実務では次の目安で十分です。
```python
def should_promote(trials_before: list[bool], trials_after: list[bool]) -> str:
rate_before = sum(trials_before) / len(trials_before)
rate_after = sum(trials_after) / len(trials_after)
diff = rate_after - rate_before
この程度のヒューリスティックでも、1回実行だけで判断するよりはるかに誤判定を減らせます。重要なのは「n=1で決めない」という原則を評価フローに組み込むことです。
多重トライアル設計はリリース前のゲート判定が主戦場で、CIの全件回帰テストや本番A/Bテストとは担当範囲が異なります。
多重トライアルサンプリングは、少量のタスクに対してリリース判断の確度を上げるための手法です。これは次の2つの評価層とは役割が異なります。CIパイプラインに組み込むゴールデンデータセットの回帰テストは、スピード優先で基本1トライアルのまま広いカバレッジを確保する設計です。一方で本番トラフィックを使ったA/Bテストは、十分な母数が自然に集まるため個別タスクの複数トライアルは不要です。多重トライアル設計が必要なのは、この2層の間にある「少数の重要タスクについて、限られた手動実行回数でリリース可否を決めたい」という場面です。既存の回帰テストやA/Bテストの仕組みを持つチームでも、リリースゲートとなる重要タスクだけはn=5のトライアル設計を追加することで、判定の信頼度を補強できます。
AIエージェントの評価を1回の実行で済ませると、改善と偶然の区別ができず誤った判断につながります。
限られた評価予算でも、トライアル回数の設計ひとつで判定の信頼度は大きく変わります。評価基盤の設計からKuu株式会社のエージェントAI運用管理サービスでご相談いただけます。
]]>claude_desktop_config.json を手で書き換えて個人のPCに入れてしまう——IT担当者の目の届かないところで起きるこの状況こそ、配布経路を統制していない中小企業の典型的な盲点だ。MCPBというAnthropic発の配布規格と、Claude Desktopの管理機能を組み合わせれば、この経路は技術的に塞げる。
MCPBは.mcpb拡張子のzipで、MCPサーバーと依存関係を1ファイルに同梱し導入できる規格です。
MCPBはもともとAnthropicが.dxtとして設計し、2025年11月にMCP本家プロジェクトへ移管された配布形式だ。Chrome拡張（.crx）やVS Code拡張（.vsix）と同じ発想で、サーバー本体・依存パッケージ・manifest.jsonを1つのzipにまとめる。従来は開発者ツールの導入やJSON手書き編集が必要だったが、MCPBなら「ダウンロード→ダブルクリック→インストール」の3手順で完了する。
manifest.jsonは実行コマンド・対応OS・必須設定を宣言し、導入前の内容検証を可能にします。
manifest_version・name・version・serverが必須フィールドで、server.typeにはnode・python・binary・uvを指定する。加えてuser_configでAPIキー等の入力項目をUI化し、OSのキーチェーンに安全に保存できる。compatibilityで対応OS（darwin/win32/linux）とランタイム要件も宣言するため、動作しないサーバーを誤って配布するリスクも減らせる。
Team/Enterprise版はカスタムレジストリで承認済みMCPBのみを配布し、個人の手編集経路を塞げます。
IT部門が小さい中小企業ほど、「誰が何をインストールしたか分からない」状態になりやすい。Claude DesktopのTeam/Enterprise機能は3つの統制手段を提供する。
isDesktopExtensionEnabled等のマシンレベル設定で、アプリ内の操作より優先して適用するこの3点を組み合わせれば、「個人が見つけた未検証サーバーを手動設定する」という最もリスクの高い経路自体を塞げる。
MCPBは配布手段を標準化する規格であり、暗号署名による検証は未整備で、審査基準も非公開です。
MCP公式ブログは配布形式の統一を目的に明記する一方、署名・検証の仕組みには触れていない。Anthropicの公開ドキュメントも拡張ディレクトリ掲載時に「品質とセキュリティ」をレビューするとは述べるが、審査基準自体は非公開だ。つまりMCPBは「配布の手間」を解決する規格であり、「中身の安全性」は別の工程で確認する必要がある。導入前チェックの観点はサードパーティMCPサーバー導入前チェックを参照してほしい。
MCPBは「導入の手間」を1クリックまで減らす配布規格だが、それ自体は安全性を保証しない。MCPサーバーの広がりを管理するには、MCPBの仕組みを理解した上でTeam/Enterprise機能のカスタムレジストリとポリシー強制を使い、配布経路を会社側に引き戻すことが出発点になる。
自社のMCPサーバー配布経路が「個人任せ」になっていないか、まず現状の棚卸しから始めたい。KuuのAI-Opsサービスでは配布統制設計を初回相談から支援している。
]]>resources/subscribeリクエストとnotifications/resources/updatedの素朴な組み合わせは廃止され、subscriptions/listenという長命ストリームの仕組みに統合された。設計を正しく理解しないまま移行すると、多重サブスクリプションの取り違えや再接続漏れが起きる。
MCP 2026-07-28はセッション廃止と合わせ、個別の
subscribe系RPCを汎用ストリームAPIに統合再設計した。
旧仕様では、リソース変更を監視したいクライアントはresources/subscribeリクエストを送り、サーバーは以後そのリソースについてだけnotifications/resources/updatedを流していた。この方式はリソースの変更通知専用で、ツールリストやプロンプトリストの変更通知とは別経路だった。2026-07-28仕様はこれらをsubscriptions/listenという単一の汎用リクエストに統合し、notificationsフィルタでtoolsListChanged・promptsListChanged・resourcesListChanged・resourceSubscriptions（監視対象URI配列）を同時に指定できるようにした。ステートレス化の一環として、サーバーはこのリクエストに応じて長命のストリームを開く。関連する全体像はMCP 2026-07-28のステートレス化移行記事も参照してほしい。
サーバーは必ず
notifications/subscriptions/acknowledgedを最初に返し、_metaのsubscriptionIdでストリームを識別させる。
クライアントがsubscriptions/listenを送ると、サーバーは実際に対応できる通知種別だけを反映したnotifications/subscriptions/acknowledgedを先に送らなければならない（MUST）。この確認応答より前に通知を送ることは仕様違反になる。確認応答と以後のすべての通知は、_meta内のio.modelcontextprotocol/subscriptionIdに元のリクエストのJSON-RPC idをそのまま載せて運ばれる。クライアント側はこのIDを突き合わせることで、どのlisten呼び出しに対する通知かを判定する。
stdioは全メッセージが単一チャネルを共有するため、
subscriptionIdなしでは複数ストリームを区別できない。
1クライアントが複数のsubscriptions/listenを同時に開く——たとえば「ツールリスト変更監視」と「特定リソースの更新監視」を別々に——ケースは仕様上想定されている。HTTPのStreamable Transportではストリームごとに論理的な分離があるが、stdioでは全通知が1本のパイプを共有するため、subscriptionIdによる多重化識別がなければどの監視対象の更新かを判別できない。エンタープライズでMCPゲートウェイを自社実装する場合、subscriptionIdをルーティングキーとして扱うミドルウェア層の設計が必須になる。あわせてResources・Prompts・Toolsの使い分けも設計の前提として押さえておくと良い。
サーバー主導の正常終了は
resultType: "complete"応答を伴うが、stdioは再接続時にサブスクリプション状態を保持しない。
サーバーがシャットダウンなどで自発的にストリームを終える場合、元のsubscriptions/listenリクエストに対してresultType: "complete"を含む結果を返してから閉じるべき（SHOULD）とされている。この応答がなく通信が切れた場合、クライアントは異常切断と判断して再接続を試みてよい。注意すべきは、stdioでは再接続してもサーバー側にサブスクリプション状態が残らない点だ。クライアントは再接続後に全subscriptions/listenを再送する再確立ロジックを持つ必要がある。これを欠くと、障害復旧後にリソース変更監視が静かに失われ、キャッシュが陳腐化したまま気づかないインシデントにつながる。監査ログ基盤と合わせてサブスクリプション再確立イベントを記録しておくと、こうした静かな欠落を検知しやすい。MCPゲートウェイの運用設計はエンタープライズ向けAgent開発支援（RDE）で個別に相談できる。
MCP 2026-07-28仕様のsubscriptions/listenは、リソース・ツール・プロンプトの変更通知を単一の長命ストリームに統合した設計だ。subscriptionIdによる多重化と、stdioでの再接続時の再確立ロジックを押さえておけば、旧resources/subscribeからの移行は機械的に進められる。自社のMCPゲートウェイやクライアントSDKへの影響範囲の洗い出しに不安があれば、Kuuのエージェント開発支援（RDE）にご相談ください。
requestStateフィールドを、実装者が単なる継続トークン程度に軽く扱ってしまう点にある。
MCPはサーバーからクライアントへの割り込みリクエストを廃止し、2026-07-28仕様でMRTR（SEP-2322）に統一した。ステートレスな水平スケールを実現するためだ。
2026-07-28仕様はセッション概念（Mcp-Session-Id）とinitializeハンドシェイクを撤廃し、MCPをステートレスなリクエスト/レスポンス型プロトコルへ転換した。しかし旧来のSampling・Roots・Elicitationは、いずれもサーバーが接続を保持したままクライアントへ割り込みリクエストを送る「サーバー起動」方式だった。接続を保持できないステートレスサーバーではこの方式が成立しない。公式チェンジログはSampling・Roots・Loggingの3機能を非推奨に指定し、新規実装はMRTRパターンへの統一を求めている。従来のElicitation実装はelicitation/createを直接送る前提で解説したが、現行仕様ではこの直接呼び出しがMRTRの枠組みに置き換わっている。
MRTRはクライアントの
tools/call等に対しサーバーがresultType: "input_required"を返し、クライアントがinputResponses付きで再送する2往復設計です。
フローは4段階。(1) クライアントが通常のリクエストを送る。(2) サーバーが追加情報を要すると判断し、InputRequiredResultでinputRequests（Elicitation・Sampling・Rootsのいずれか）とrequestStateを返す。(3) クライアントはユーザーや他の手段から回答を集め、inputResponsesとrequestStateを添えて同じリクエストを新しいJSON-RPC idで再送する。(4) サーバーはrequestStateから文脈を復元し、処理を完了する。対応するのはtools/call・resources/read・prompts/getの3リクエストのみで、他のリクエストへのInputRequiredResultは仕様違反となる。Tasks拡張のinput_required状態と似るが、MRTRは単発リクエスト内の往復であり、長時間タスクのポーリングとは別チャンネルである点に注意したい。
requestStateはクライアントが不透明として扱うべき値だが、サーバー視点では悪意あるクライアントが改変しうる攻撃者制御入力として扱う必要がある。
仕様はクライアント側に「requestStateの内容を検査・解釈・変更してはならない」と課す一方、サーバー側には逆の要求を課す。クライアントを経由して往復する値である以上、悪意あるクライアントや侵害されたクライアントが値を書き換えて再送してくる可能性を排除できない。この非対称性——クライアントには不透明、サーバーには攻撃者制御——を理解していないと、requestStateに認可判断やリソースアクセスの前提条件をそのまま平文で埋め込む実装に陥る。これはスコープ付き認証情報設計で避けるべきとされる「暗黙の信頼境界」と同じ失敗パターンだ。
requestStateが認可・リソースアクセス・業務ロジックに影響する場合、サーバーはHMACやAEADで整合性保護し、検証失敗時は必ず拒否しなければならない。
仕様の要求は明確だ。requestStateが認可判断・リソースアクセス・業務ロジックに影響を与える場合、サーバーはHMACまたはAEADで整合性保護を実装し、検証に失敗した状態は拒否しなければならない。整合性保護を省略できるのは、改ざんの結果がリクエスト失敗以上の実害を生まない場合に限られる。実装としては、サーバー内部のJSONを平文でBase64エンコードするのではなく、暗号化JWTやAEAD保護済みバイナリとしてrequestStateを発行し、復号・検証の失敗を即座にエラー終端させる設計が要る。
改ざん防御だけでは不十分で、整合性保護されたペイロード内に認証プリンシパル・短いTTL・元リクエストの識別子を含め検証すべきだ。
仕様はリプレイ対策として3要素を推奨する。認証済みプリンシパル（異なるユーザーが提示した状態を拒否）、短いTTL（期限切れ状態を拒否）、元リクエストの識別子（メソッド名とパラメータのダイジェストなど。異なるリクエストに対する状態を拒否）の3点だ。ただしこれらはリプレイの時間窓とクロスユーザー再利用を防ぐに留まり、単発利用の保証にはならない。一度しか使えないべきrequestState（ワンタイム処理等)はサーバー側で別途その制約を強制する必要がある。
MRTRはMCPのステートレス化に不可欠な設計変更だが、requestStateを単なる継続トークンとして軽視すると、認可バイパスや業務ロジック改ざんの入口になる。サードパーティMCPサーバーを組み込む際は、requestStateの整合性保護方式（HMAC/AEAD）とリプレイ対策の3要素が実装されているかをベンダー評価の必須項目に加えるべきだ。複数チームでMCPサーバーを運用する体制整備については、Kuu株式会社のRDEが設計レビューから支援する。
usageフィールドは理由を教えてくれない。システムプロンプトが変わったのか、ツール定義が変わったのか、履歴の編集が原因なのか——従来は仮説を立てて1つずつ潰すしかなかった。2026年9月23日にGA化したCache Diagnosticsは、この当てずっぽうのデバッグを構造化されたレスポンスに置き換える。
Cache Diagnosticsは直前のレスポンスIDを渡すだけで、2つのリクエストのプロンプト接頭辞がどこで分岐したかをAPIが特定する機能だ。
リクエストにdiagnosticsオブジェクトを含めると、APIはそのリクエストのフィンガープリントをidに紐づけて保存する。次のターンで直前のidをdiagnostics.previous_message_idとして渡すと、APIは保存済みフィンガープリントと新リクエストを比較し、レスポンスのdiagnosticsフィールドに分岐点を返す。初回ターンは比較対象が無いためprevious_message_id: nullを渡してオプトインするだけでよい。かつて必要だったcache-diagnosis-2026-04-07ベータヘッダーは不要になり、GA後は送っても無視される。
cache_miss_reasonはtypeで判別する共用体で、model/system/tools/messagesの変更4種と、比較不能だった2種を返す。
具体的にはmodel_changed（モデル自体が変わった）、system_changed（システムプロンプトにタイムスタンプ等を埋め込んだ）、tools_changed（ツール定義の順序や内容が変わった）、messages_changed（過去の会話履歴を追記ではなく編集・削除した）の4種が分岐点を示す。加えてprevious_message_not_found（フィンガープリントの保持期限切れや別ワークスペース起因）、unavailable（thinkingやtool_choiceなど他パラメータの変更、または比較範囲を超えた長い会話）がある。各*_changed型はcache_missed_input_tokensという目安の推定値も持ち、どれだけのキャッシュ済み接頭辞を失ったかが分かる。
diagnosticsは「リクエストが変わったか」、usage.cache_read_input_tokensは「キャッシュが実際に当たったか」を示し、両方を見て初めて原因が切り分かる。
diagnosticsがnullで読み込みトークンが高ければ正常動作だ。nullなのに読み込みトークンが低い場合は、リクエスト自体は一致しているがキャッシュエントリが期限切れになったケースで、5分TTLから1時間TTLへの切り替えが有効な対処になる。*_changed型が返り読み込みトークンも低ければ、それが本当のバグでありtypeが示す原因を直す対象になる。
フィンガープリントはハッシュとトークン数推定のみで生テキストを保持せず、ZDR適格だが保持期間は短く、継続したターンでの利用が前提になる。
マルチターンのループでは、直前レスポンスのidを毎ターンprevious_message_idとして引き渡す実装にする。ストリーミングではdiagnosticsがmessage_startイベントに載るため、SDKのアキュムレータで最終メッセージまで保持すればよい。Claude API専用の機能でAmazon BedrockやGoogle Cloud経由では使えない点、フィンガープリントの保存先が同一ワークスペースに限られる点は事前に把握しておく必要がある。SMBではAPI呼び出し全体にdiagnosticsを常時組み込んでログにcache_miss_reasonを残すだけで十分だが、エンタープライズで複数チームがモデルルーティングを行う場合はLLMゲートウェイ側でモデル固定やsystemプロンプトの一意性を保証する設計が要る。コスト計測基盤全体との統合はAI FinOps設計も参照してほしい。
Cache Diagnosticsは、キャッシュミスという「見えない事故」をcache_miss_reasonという診断可能な情報に変える機能だ。usage.cache_read_input_tokensと組み合わせれば、リクエストのバグとキャッシュエントリの期限切れを切り分けられ、プロンプトキャッシュのコストメリットを継続的に確保できる。自社のエージェント基盤にキャッシュ監視を組み込みたい場合は、Kuuのエージェント運用支援で設計・実装を相談できる。
メモリストアは最大1万件が上限で、重複や矛盾が蓄積すると新規書き込みに失敗する。
各セッションがメモリストアに書き込む内容はローカルかつ増分的です。ユーザーの好み、プロジェクトの慣習、過去の失敗といった情報がセッションを重ねるごとに追記されますが、誰も整理しなければ重複エントリ・矛盾した指示・陳腐化した情報がそのまま積み上がります。ストアが1万件の上限に達すると、新規メモリの直接作成だけでなく、エージェントが未マップのパスにファイルを書き込む操作も失敗するようになり、気づいたときには本番のエージェント挙動に影響が出ています。
Dreamsは既存ストアと過去セッションを読み、整理済みの新しい出力ストアを生成する。
Dreamsは、既存のメモリストア1つと過去のセッション記録1〜100件を入力として受け取り、重複を統合し、矛盾する記述を最新の内容で置き換え、新たな気づきを抽出した別の出力ストアを生成します。重要なのは、入力側のメモリストアは一切変更されない点です。結果が気に入らなければ出力ストアを破棄するだけでよく、本番運用中のストアを壊すリスクなしに試せます。instructionsパラメータ（最大4,096字）で「コーディング規約に関する記述を優先し、一回限りのデバッグメモは無視する」といった焦点を指定でき、Claude Opus 5やClaude Sonnet 5を含む複数モデルから処理に使うモデルを選べます。
Dreamsは非同期ジョブで、完了までステータスをポーリングして確認する設計になる。
ジョブを作成するとpending状態で返り、処理が進むとrunningに移行します。完了（completed）すると出力ストアのIDがoutputsに現れるので、内容をレビューしたうえで今後のセッションをその出力ストアに切り替えるか、不要であれば削除・アーカイブします。公式ドキュメントが推奨する使い方は、ストアが1万件の上限に近づく前にDreamsで整理し、整理後のストアにセッションを切り替えて元のストアをアーカイブする運用です。課金は選択したモデルの標準トークン料金で、入力セッションの数と長さにほぼ比例して増えるため、最初は少数セッションで試し、整理品質に納得してから対象を広げるのが安全です。
Dreamsは研究プレビューのため、まず小規模な試行から段階的に評価するのが現実的だ。
専任のプラットフォームチームを持たない中小企業にとって、メモリの手動棚卸しは後回しにされがちな作業です。Dreamsはこの作業を定期ジョブとして自動化できますが、2026年10月時点では研究プレビューのためアクセス申請が必要で、本番の全ストアにいきなり適用するものではありません。まずは最も肥大化しているストア1つと直近の少数セッションで試し、出力ストアの品質とコストを確認してから、定期実行に組み込むかどうかを判断する進め方が現実的です。Managed Agentsの導入設計やメモリ運用の整備についてはKuuの AI Opsでも支援しています。
Managed Agentsのメモリストアは便利な反面、放置すれば重複と矛盾で機能しなくなります。Dreamsは過去セッションから非破壊的に整理済みストアを生成する仕組みで、上限に達する前の定期整理に組み込むことで、専任の運用担当者がいなくてもメモリ品質を保てます。導入可否の判断やManaged Agentsの運用設計に迷う場合は、Kuuの AI Opsにご相談ください。
]]>Modsはイベントに反応する関数群で、Claude Codeの中で直接実行されるプラグインです。
Modsはplugin.json・hooks.json・register.jsの3ファイルで構成され、on関数でイベントハンドラを登録する。登録したハンドラはtool.call（ツール呼び出し直前）やui.render（画面描画時）などのイベントごとに呼ばれ、イベントを素通りさせる・書き換える・自前の処理で代替する、のいずれかを選べる。設定ファイルで外部コマンドを呼ぶ従来の「settings hook」とは異なり、Claude Code自身のプロセス内で動くため、サイドバーのペインやプロンプト上のバナー、トースト通知まで描画できる。v2.1.287以降は既定で有効になっており、無効化しない限りインストールしたプラグインが即座に有効になる。
Modsはサンドボックス無しでユーザー権限そのまま動き、設定済みの拒否ルールより先に承認できます。
公式ドキュメントは明確に警告している。Modsはユーザー権限でファイルの読み書き・プロセス起動・ネットワーク通信ができ、環境変数や設定ファイルに保存されたAPIキーも読み取れる。さらに重要なのは、askルールが確認を求めるはずのツール呼び出しや、自分で設定したPreToolUseフックが拒否した呼び出しさえ、先に動くModsが承認してしまえる点だ。サンドボックスを有効にしても、ModsがBashで起動したプロセスはサンドボックスの外で走る。唯一の防波堤は、Modsが権限確認ダイアログの表示内容そのものは変更できないという制約だけだ。
専用コマンドはプラグインを実行せずに、処理イベントと呼び出し内容を一覧表示できます。
インストール前にプラグインのリポジトリを取得し、claude plugin validate ./some-modを実行すると、そのModsが監視するイベントと、ファイルアクセス・ネットワーク呼び出し・モデル呼び出しなど何を要求するかをコードを動かさずに確認できる。信頼できる作成者・マーケットプレイス以外からのインストールは避け、/pluginコマンドでセッションに実際にロードされたModsの一覧を都度確認する運用が、審査体制を持たない組織でも最初の防御線になる。
管理設定で個人導入Modsを一括制限でき、組織管理のModsだけは動き続けます。
個人レベルでは~/.claude/settings.jsonにdisableAllHooks: trueを設定すると、インストール済みの全Modsとsettings hookが停止する（組織が管理するものは動き続ける）。組織レベルでは管理設定（managed settings）でallowManagedModsOnlyを敷き、ユーザーが個別導入したModsの読み込み自体を止められる。Claude Codeにはcc-plugin-sec-defaultという組織管理の優先度をユーザー導入Modsより先に走らせる組み込みModsがあり、ポリシーを独自のModsとして実装する余地も用意されている。中小企業規模ではまず個人設定での無効化と信頼できる配布元への限定、エンタープライズでは管理設定による強制とレビュー記録の両輪で統制するのが現実的な出発点だ。
専任のセキュリティ担当がいない組織では、Modsの導入を「便利なプラグインを見つけた人」の個人判断に委ねず、導入前にclaude plugin validateの出力を確認する担当を固定するだけでリスクを大きく減らせる。エンタープライズでは、管理設定によるallowManagedModsOnlyの強制と、組織管理Modsによるポリシー実装を組み合わせ、ユーザー導入分はホワイトリスト運用に限定するのが望ましい。マルチチームでの大規模な権限統制設計はReinvention Deployed Engineeringの支援範囲になる。
Modsはエディタ内に自前のUIを描ける強力な拡張機構である一方、サンドボックスなしでユーザー権限そのまま動き、既存の許可/拒否ルールより先にツール呼び出しを承認できるという、従来のsettings hookやエージェントスキルとは異なる信頼境界を持つ。導入前のclaude plugin validateによる審査と、個人設定・管理設定それぞれでの無効化手段を事前に把握しておくことが、便利さとリスクのバランスを取る最初の一歩になる。Kuu株式会社では、こうした新しい拡張機構の権限設計からエージェント運用の技術支援まで支援している。自社のClaude Code運用ポリシーに不安がある場合は、お気軽にご相談いただきたい。
カタログが2,000件を超えると個別審査は破綻し、統制の重心はロール・スコープ設計に移る。
これまでのMCPコネクタ運用は、IT担当が少数を個別に精査してから有効化する前提で回っていた。だがMarketplaceの登場でコネクタ数が急拡大し、個別審査のペースが追いつかなくなる。エージェントガバナンスの実務では、個々のコネクタの安全性審査（安全性審査手順参照）に加え、「誰がどのコネクタのどのツールを使えるか」を組織のロール構造で統制する設計が不可欠になる。
組織でコネクタを有効化したうえで、ロールごとに許可・要承認・ブロックの状態を割り当てる二層モデルを取る。
公式ドキュメントによれば、Ownerが組織設定でコネクタを追加して初めて、各ロールへの権限割り当てが可能になる。ロール側ではコネクタ単位で「常に許可」「要承認（利用都度の確認）」「ブロック（ロールから見えなくする）」の3状態に加え、ツール単位で個別設定する「カスタム」を選べる。特定チームでパイロット導入してから全社展開する段階的ロールアウトも、このロール単位の設定で実現する。
ロール間の権限は加算方式で合成され、別ロールが許可していれば「最も緩い設定が勝つ」。
一人の利用者が複数ロールを持つ場合、権限は和集合として合成される。あるロールでブロックしても、別のロールで許可されていればブロックは効かない。だが組織レベルの有効化が上限（ceiling）として機能するため、ロール側の設定は「組織が許可した範囲を狭める」方向にしか働かない。設計の起点は常に組織レベルの有効化であり、ロール設計はそこからの絞り込みとして組み立てる。設定変更の反映には最大15分を要するため、緊急ブロックの運用手順にはこの遅延を織り込む。
EMAとゼロタッチSSOの実装で扱ったEnterprise-Managed Authorizationは、IDP側でSSO時にMCPサーバーへのアクセス権を払い出すプロトコル層の仕組みだ。本稿のロール単位の許可状態はその上に重なる製品層の統制で、両者は併用する。
Cowork拡張でOpenTelemetry対応が加わり、管理者はツール利用状況とコストを計装データで追跡できる。
権限を絞るだけでは、どのコネクタが実際にどう使われているかは見えない。2026年9月のアップデートでは組織専用マーケットプレイスの作成に加えOpenTelemetry対応が加わり、ツール呼び出しとコストをテレメトリとして収集できるようになった。退職者のアクセスはIDP側のデプロビジョニングで自動失効するが、どのロールがいつどのコネクタを使ったかをOTelのトレースで保持し、監査ログの保管設計の対象に含めることが実務的な防御線になる。
Claude Marketplaceの2,000件超という規模は、コネクタを個別に審査する運用の限界をはっきりさせた。組織レベルの有効化を上限とし、ロールごとに許可状態を割り当て、複数ロールの合成が加算方式になる点を前提に設計する。EMAによるSSO層とロール単位の製品層の統制を併用し、OpenTelemetryによる監査まで組み込むことで、カタログの拡大速度に統制が追いつく体制になる。
Claude Marketplace時代のコネクタ権限設計やMCP基盤の統制は、Kuu株式会社のRDEサービスにご相談ください。ロール設計から監査基盤の構築まで一貫してサポートします。
]]>Claudeが本番コードの約8割を書く体制で、Anthropicのテスト量は10倍、CIジョブは6か月で25倍に増加した。
コードを書く主体がエンジニアからエージェントに移ると、PRの生成速度は人間のレビュー速度を超える。Anthropicではエンジニア1人あたりの出荷コード量が2021〜2025年平均の8倍に達し、テストスイートの規模は10倍に膨らんだ。すべてのPRで全テストを実行する従来方式は、この成長速度の前では線形にすら間に合わない。コードを書く工程がボトルネックでなくなったことで、次の制約点がCI実行時間そのものに移ったという指摘は、オートスケーリング設計と同じく「成長を前提にアーキテクチャを選ぶ」必要性を示している。
Test Impact Analysisは変更差分と実行履歴からPRごとに必要なテストだけを選ぶ仕組みである。
TIAは「listener」と「selector」の2コンポーネントで構成される。listenerはCI実行のたびにテスト結果を記録し、テストごとの実行履歴を蓄積する。selectorはその履歴とパッケージ依存関係から、そのPRの変更に関連するテストだけを選び出す。全テストを毎回流すのではなく、変更の影響範囲に絞ることで、テスト量が増え続けても実行時間を線形に増やさずに済む。エージェントが自己検証のために狭く焦点を絞ったテスト結果を受け取れる点も、エージェントの完了判定設計にそのまま効いてくる。
延命パッチを3段階重ねた末に状態保持の限界が露呈し、ステートレス設計への刷新に至った。
Anthropicは最初から再設計に踏み切ったわけではない。まずマシンのコア数を倍にする延命策を70日運用し、次にパッケージ単位でlistenerを並列化するシャーディングを29日続けた。それでも追いつかず、1日もたずにサービスを毎日再起動する運用に陥った段階で、アーキテクチャ自体に根本的な限界があると判断された。最終的な再設計では、listenerをステートレスなワーカー群にし、結果をジャーナルに追記するだけの役割に絞った。別のコンシューマーが数秒おきにジャーナルをテストごとの履歴へ集約することで、水平スケールが可能になった。この刷新はエンジニア1人・3週間で完了し、従来の四半期単位の対応より大幅に短縮された。
設計時点で「2四半期以内に負荷25倍」を前提に置き、状態をクリティカルパスから排除すべきである。
Anthropicの教訓は「v0設計の段階で2四半期以内の25倍成長を見込め」という点に集約される。状態を持つプロセスをクリティカルパスに置かないこと、サービスの挙動をAIによる監視が読み取れる形で計装しておくことの2点は、AIエージェントのトレース計装の設計原則とも一致する。ゴールデンデータセットによる回帰テスト設計を既に運用しているチームは、その実行基盤がTIAのような差分ベースの選択に耐えられるかを早い段階で検証しておくとよい。
SMBでは、テスト数が数百件規模のうちは全件実行で十分なことが多く、TIAのような専用基盤を自作する前に、まず/services/ai-ops/で現状のCI実行時間とボトルネックを可視化するところから始めるのが現実的だ。一方、複数チームでAIコーディングを本格運用し始めたエンタープライズでは、テスト量とCIジョブ数の成長曲線を四半期ごとに追跡し、Anthropicが経験した「延命パッチの繰り返し」に陥る前にステートレスな実行基盤へ移行する判断が要る。この規模の刷新はRDEが伴走領域としている。
AIコーディングが本番コードの大半を書く体制に移行すると、ボトルネックはコード生成からCI実行そのものへ移る。Anthropicの事例が示すのは、延命パッチの積み重ねではなく、状態をクリティカルパスから排除したステートレス設計への刷新が最終的に最短距離だったという点だ。自社のCI基盤がこの成長曲線に耐えられるか診断したい場合は、AI Opsにお問い合わせいただきたい。
]]>