OpenRouterのArmorベータは、モデルが提案するツール呼び出しと、それを実行する可能性のあるアプリケーションの間にルール分類器を置く。エージェント開発者にとって重要なのは、判定がどの段階で実際に実行を止めるかだ。Chat CompletionsとResponsesでは、Armorがフラグ付き呼び出しの受け渡しを差し止められる。Messages APIのClaude Code互換モードでは、フラグ付きの tool_use が応答に残り、クライアントが実行を拒否しなければならない。

現行の文書は、2026年10月から利用可能なベータを説明している。BIG CHANGEは10月17日に、文書化されたリクエストとレスポンスの契約を確認した。APIリクエストの送信、エージェントの実行、セキュリティー性能の測定は行っていない。

大きな変化

  • 何が変わったのか： OpenRouterのエージェントは、提案したツール呼び出しを、開発者のルールを適用する分類器に通してからアプリケーションに渡せる。標準のルール強制経路ではフラグ付き呼び出しの実行がスキップされ、理由が返るため、モデルは処理を続けられる。
  • なぜ重要なのか： 開発者は、限定的に許可された作業の例外も含め、行動単位の制限を文章で表現できる。ただしMessages互換契約では、実行を決める最後の段階は依然としてクライアントが担う。フラグ付き判定を無視すれば、その呼び出しを実行できてしまう。
  • 今後の注目点： チームは選択したAPI出力モードにクライアントを合わせ、自分たちのトラフィックでルールを検証し、分類器のエラー時にどう動くかを決める必要がある。ベータの形式は変わり得る。OpenRouterは、分類器が問題のない呼び出しを止めたり、許容できない呼び出しを見逃したりする可能性を認めている。

提案から判定まで、呼び出しの流れを追う

OpenRouterによると、提案された各ツール呼び出しは、アプリケーションに転送される前に保留される。判定モデルは呼び出し、ルール、それまでの会話を受け取り、各ルールに一致するかを推定し、結果をまとめて flagged または not_flagged とする。フラグのない呼び出しは変更せずに渡す。強制モードでは、フラグ付き呼び出しに実行をスキップする印が付き、モデルに理由が返る。モデルはより狭い範囲の呼び出しを試したり、拒否の理由を説明したりできる。これは提案された行動に関する分類器の判断であり、後続のツールやエージェント全体が安全だという証拠ではない。

ルールの階層はそれぞれ別の問いに答える。hard_deny に一致すると、許可ルールやユーザーの依頼に関係なくブロックする。soft_deny への一致は、allow への一致、または会話の中でユーザーがその対象にその操作を明確に求めることで解除できる。allow ルールが単独で呼び出しをブロックすることはない。OpenRouterは、ユーザーが設定し、まだ解除していない境界に対する組み込みのソフト拒否も説明している。開発者は、信頼できるリポジトリやデプロイ先などの事実を environment に入力する。古い事実はルールの精度を下げ得る。名前付きのルールオブジェクトは、判定にIDと名前を表示する。任意のしきい値の標準値は拒否ルールが0.6、許可ルールが0.7だ。

文書にあるResponsesの例は、bash ツールに git push をハード拒否するルールを設定する。output_mode: "custom_item" を使うと、フラグ付きのpushは呼び出しと理由を含む openrouter:armor_blocked 項目に置き換わり、その後にモデルの応答が続く。この例は、サービスが何を返すと文書に書かれているかを示すもので、BIG CHANGEによるテストではない。

ツール実行の前に出力契約を選ぶ

Chat CompletionsとResponsesでは、標準の text モードがブロックされた呼び出しを削除し、アシスタントのテキストに <openrouter_armor_blocked> マーカーを入れる。Responses APIは custom_item もサポートし、本来 function_call が現れる場所に、型が明示されたブロック項目を返す。文書は、その項目を次のResponses入力に変更せずにそのまま返し、そのための別の function_call_output を作らないよう求めている。safeguard_results は呼び出しIDごとに判定を記録する。

Messages APIでは、リクエストに safeguards が含まれる場合の標準動作が大きく異なる。claude_code_compatibility はフラグ付きの tool_use を content[] に残し、その flagged 結果を safeguard_results に追加する。アプリケーションは結果を読み、その呼び出しの実行を拒否しなければならない。 OpenRouterは、判定を無視するMessagesクライアントはフラグ付きのツール使用を実行してしまうと明確に警告している。クライアントを制御できない開発者は、Messagesで output_mode: "text" を指定し、OpenRouter側に呼び出しを差し止めさせられる。APIが表現できない出力モードを要求すると400が返る。

OpenRouterのOriメタハーネスを通じたClaude Codeの自動モードは、Armorプラグインの追加エントリーなしでMessages契約を使う。文書によると、Claude Codeはフラグ付き呼び出しを拒否し、会話記録にエラー結果を書き込み、モデルを続行させる。また、独自の分類器に対応するAnthropicエンドポイントでは判定をそのまま渡せ、それ以外のエンドポイントではArmorが評価するという。これは文書化された統合動作であり、すべてのサードパーティークライアントが正しく実装しているという主張ではない。

範囲を絞ったルール集を設定して確認する

独自エージェント向けに、Armorガイドは armor エントリーを plugins に置き、バージョン付きの classifier_context（v: 1）、auto_mode ルール、任意の環境情報を含めるとしている。まずルールが認識すべき行動と保護対象のリソースを決める。そのうえで、ユーザーが同意しても維持すべき禁止にはハード拒否を、明確な同意や名前付きの許可で正当に解除できる場合にはソフト拒否を選ぶ。文書は、コマンドの一つの書き方ではなく行動を説明し、環境情報を最新に保つよう勧めている。

標準の enforce モードは判定に従って動作する。audit は同じ判定を報告する一方、フラグ付きも含むすべての呼び出しを渡す。実際のトラフィックを確認し、強制前にルールを調整する方法であり、保護モードではない。監査モードは claude_code_compatibility と併用できない。どちらのモードでも safeguard_results を読む。not_flagged は許可、flagged は一致したルール、unavailable は評価失敗、skipped は未評価のプロバイダーネイティブツールを意味する。ストリーミングでは判定オブジェクトは応答の最後に到着するため、Messagesを使うクライアントはツール使用を実行する前にそれを待つ必要がある。

OpenRouterは、分類器のタイムアウト、エラー、大きすぎるリクエストを扱えない場合の標準値を on_error: "block" としている。on_error: "log" は呼び出しを渡す。Claude Code互換モードでは、unavailable の呼び出しが判定を表示したまま渡される。プロバイダーネイティブのサーバーツールは標準では評価をスキップするが、evaluate_native_tools でネイティブ経路から外して評価させられる。これらの設定と実際のツール経路をチームの統合確認に含めるべきであり、Armorのエントリーだけで全ツールが評価されたとはいえない。

ベータの費用、速度、適用範囲の限界

OpenRouterによると、Claude Code互換ルール集を読み込んだ条件で、評価による追加時間は中央値279ミリ秒、90パーセンタイル334ミリ秒だった。これは明示された条件でのベンダー報告値であり、特定のエージェントやあらゆるルール集のベンチマークではない。各呼び出しは、渡されるかブロックされる前に一度評価される。ベータ期間中は評価の課金はなく、OpenRouterは一般提供前に価格を発表するとしている。文書は将来の料金を確定していない。

判定モデルは文章のルールを文章の引数と照合するため、誤検知や見逃しを生む可能性がある。文書は、実トラフィックの監査判定を使い、ルールごとのしきい値を調整するよう勧める。Armor評価は、HIPAA、Zero Data Retention、データ地域の制限があるリクエストにはまだ対応していない。こうした条件でプラグインを有効にしたリクエストは403になる。一方、Claude Codeリクエストは呼び出しを unavailable として渡し、Claude Codeはローカルの自動モード評価に戻る。ベータの注意事項には、設定フィールド、safeguard_results、openrouter:armor_blocked 項目型の変更も含まれる。

Armorはモデルからアプリケーションへの受け渡し時に、提案された呼び出しを検査する。したがって、その仕組みはMicrosoftのMXCコマンド封じ込めやNVIDIAのOpenShellとSentryによるランタイム制御とは異なる。後者はワークロードまたはそのアクセスを囲む形で制約を適用する。Armorでまず決めるべき実装上の点は、選んだ応答形式がフラグ付き呼び出しを差し止めるのか、クライアントに停止を求めるのかだ。

出典と参考資料

  • OpenRouter Armor文書、2026年10月17日閲覧。ベータの状態、分類器の手順、ルールの優先順位、API応答契約、エラー時の動作、プライバシー条件の除外、報告された遅延、ベータの課金に関する一次資料。これらはOpenRouterが文書で述べる内容であり、BIG CHANGEはプラグインを実行していない。
  • Microsoft MXCに関するBIG CHANGEの記事は、エージェントが生成したコマンドをポリシーに基づいて封じ込める仕組みを説明する。別の制約適用層であり、Armorの初期段階ではない。
  • NVIDIA OpenShellとSentryに関するBIG CHANGEの記事は、ソフトウェアのアクセス制御と任意のハードウェア監視設計を説明する。関連する背景であり、このOpenRouter機能の直接の続報ではない。