BYOK|審査ゲートの後ろにあなたのキーを置く
利用者が不適切な質問をすると、停止されるのはあなたの API key です。すべてのリクエストは先に BazaarLink のコンテンツ審査を通り、高リスクの質問は遮断され上流には届きません。これにより、規約違反のコンテンツでアカウントが停止されるリスクを大幅に下げます。
BYOK を詳しく見る →Base URL、APIキー、モデルIDを入力すると標準84項目を実行します。任意2項目を加えると最大86項目です。モデルの真正性、Token計測、プロンプト注入、サプライチェーン、ストリーミング互換性を確認します。
利用者が不適切な質問をすると、停止されるのはあなたの API key です。すべてのリクエストは先に BazaarLink のコンテンツ審査を通り、高リスクの質問は遮断され上流には届きません。これにより、規約違反のコンテンツでアカウントが停止されるリスクを大幅に下げます。
BYOK を詳しく見る →単一 API key。ノードの同時実行数が上限に達した、プロセスが落ちた、マシンが切断された場合、リクエストはシームレスにプラットフォームモデルへ移り、自分のノードの通信は課金ゼロです。fallback が引き継いだ通信だけが課金対象です。
完全なセットアップ手順 →私たちはエンドポイントに「あなたはどのモデルか」とは尋ねません。どんなエンドポイントでも、どんな名前でも答えられるからです。標準検査 84 項目を実行して実際に仕事をさせ、その仕事の仕方を、既知モデルの基準と突き合わせます。判定は粗いところから細かいところへ五つの段階を進み、どの段階でも「証拠が足りないので断定しない」と言えるようになっています。
このエンドポイントはそもそも測定できるのか。
判定の第一の前提は、設問に実際に答えが返っていることです。欠測は単に情報が少ないという話ではありません。返ってきた答えがたまたま同じ方向に偏ることがあり、それは証拠ではなく標本の偏りです。
エンドポイントがまったく応答しない、あるいは鍵やモデル名がそもそも通らない場合は、そこで止めます。欠けたままの材料から結論を組み立てることはしません。
これはどの開発元のモデルか。
すり替えで最も多いのは開発元をまたぐ形、つまり安いモデルが高いモデルの名前を借りる形です。開発元レベルの振る舞いは最も安定していて偽装が難しいので、まずこの層を問います。比べるのは回答の文体と癖であって、自称ではありません。自称はレポート全体で最も偽装しやすい項目です。
開発元の証拠が足りなければ棄権し、無理に名指ししません。中国語で名乗る開発元と振る舞いが食い違う場合は、自称を言い間違いとみなして振る舞いの証拠に戻します。
同じ開発元の中で、どの型番なのか。
購入したのは特定の型番であって「あの開発元のどれか」ではありません。いわゆる性能低下の多くはこの層で起きます。開発元はそのままに、同じ系列の安い小型モデルへ差し替わるのです。私たちは系列内の比較と系列をまたぐ比較を同時に行い、互いに検算させます。開発元の判定を誤ると、系列内の比較は誤った型番を強い確信とともに返してくるからです。
証拠が開発元の層までしか届かないときは、「どこの製品かは分かるが、どの型番かは分からない」とはっきり書きます。最も似ている候補で埋めることはしません。
前段が選んだ型番は、近い兄弟と本当に区別できているのか。
型番の中には双子のようなものがあります。文体も能力も言い回しも大きく重なり、前段の手法ではほとんど識別力がありません。点数は近く並びますが、その近さに意味はありません。この段階が行うのは一つだけです。そうした近縁の集まりに対して、その比較のために作られた別の設問群で採り直し、個々の答えではなく分布全体を見ます。通れば前段を確認するか覆し、通らなければ前段の結果をそのまま残します。
この段階には意図的な非対称があります。証拠が決定的でなく、かつ前段の結果がたまたま販売元の申告と一致している場合、私たちは覆しません。誠実な販売元を誤って告発する代償は、一度見逃す代償より大きいからです。
実測の結果は、販売元の申告とどこが違うのか。
見分ける作業そのものは申告を見ません。前の段階が比べるのは振る舞いの証拠だけです。申告が入ってくるのは二か所だけで、第四段階が「覆すかどうか」を決めるときと、この段階です。この順序は意図的です。設問を読む前に答えを出しておけば、申告に引きずられません。結論は、完全一致、開発元のみ一致、型番の不一致、すり替え、自称の偽装、振る舞いの誘導、資料不足、判断保留に分かれます。
複数の信号が互いに矛盾し、安定した多数が現れないときの結論が「判断保留」です。これは正式な結論であって、故障ではありません。
誤りの二つの方向は、代償が同じではないからです。誠実な中継サービスをすり替えだと言うのは告発であり、実際に人を傷つけます。一方で見逃しは、もう一度検査すればよく、履歴を見ることもできます。ですから証拠が足りないときは、断定しない側を選びます。
これはコードの上でも形を持っています。レポートが「モデル不一致」を描くのは、エンジンがすり替えを確認したときだけです。「最も似ているモデルがたまたま申告と違う」は告発として描かれません。それは私たちの推測にすぎないからです。「未確定」と出たときの正しい読み方は「今回の証拠では断定できない」であって、無罪の証明でも有罪の判決でもありません。
分かっている限界を書き出します。限界に触れないレポートは、実力以上に信用されてしまうからです。
一度の検査は一度の標本です。中継サービスは一部の通信だけをすり替えることも、検査らしい通信のときだけ本物を返すこともできます。一度通ったことは、長期的な誠実さと同じではありません。定期的に測り直し、一枚のレポートではなく履歴を見てください。
なりすます側が相手の振る舞いを半分以上まで意図的に模倣すると、証拠のおよそ半分は構造上、申告された身元を指します。これは設問が足りないのではなく構造的な上限です。実測しました。設問を増やすと費用は大きく上がりましたが、識別力はほとんど動きませんでした。
一致という判定の意味は「今回の証拠はすり替えを支持しない」であって、「すり替えは無かった」ではありません。後者を保証すると称する検査は、自らを誇張しています。
判定の経路は保存済みのデータから事後に再構成しています。エンジンは当時どの規則を通ったかを記録していません。保存されたデータからは区別できない分岐があり、その場合は結果だけを示し、規則の番号は付けません。推測するくらいなら、語らないほうを選びます。
応答が基準とセキュリティしきい値を満たしています。
信号が不完全またはしきい値付近です。説明と生の応答を確認してください。
基準との差、プロトコルエラー、または完全性リスクが確認されました。
ファミリー指紋、サブモデル特性、耐偽装信号を公称モデルと照合します。
Token数、SSE形式、遅延、応答構造を検証し、水増しや中継層の異常を検出します。
System Prompt注入、秘密情報流出、依存関係ハイジャック、署名改ざんを検査します。
arXiv 2604.08407 に記載された主要なリレー攻撃を検出します。依存関係ハイジャック、条件付き System Prompt 注入、認証情報漏洩を、標準 84 項、拡張検査有効時は最大 86 項の Probe で確認します。セキュリティスコアは算出せず、身元の根拠と行動警告を提示します。
プロキシがレスポンス解析中に tool-call やテキストコンテンツを改変し、エージェントに攻撃者が指定した操作を実行させます。一般的な手口には、npm/pip/go/cargo のインストールコマンドの改ざん、タイポスクワッティングパッケージの注入、シェルコマンドパラメータの書き換えが含まれます。検出方法は、プロキシのレスポンスを直接接続モデルの tool-call ペイロードと比較し、サイレントリライトを発見します。
プロキシは prompt の内容に応じて system message を条件付きで注入します — 「銀行」「パスワード」「送金」などの機密用語を含むリクエストには悪意ある指示を、通常のリクエストには沈黙を返します。統計的に異常な分布が現れます。検出は Proxy Monitor がベースラインとテスト対象プロキシ間の system prompt のオフセットを比較します。
プロキシはリクエスト (request) とレスポンス (response) の両端から API キー、アクセストークン、個人情報、企業秘密を静かにスキャンします。コンテンツ自体は変更されないため、一般的な diff ツールでは検出できません。検出は honeypot トークンを注入し、そのトークンがプロキシのログ、Telegram bot、または外部エンドポイントに現れるかを検証します。
AI API リレー検査は、OpenAI 互換 API がリクエストを正直に実行しているかを確認する自動テストです。BazaarLink Probe は標準 84 項、任意 2 項(最大 86 項)の Probe で、モデルすり替え、Token 水増し、System Prompt 注入、秘密情報窃取を検出し、身元判定と行動警告を表示します。
最も信頼できる方法はモデルフィンガープリントです:特定のモデルだけが正確に答えられる質問(知識カットオフ日、特定の能力テストなど)を送信し、期待するモデルの応答と比較します。BazaarLink Probeにはこれらのプローブが内蔵されており、すり替えリスクを自動的にフラグします。
トークン水増し(token padding)とは、中継局がAPIのusageフィールドに実際の消費量より多いトークン数を報告し、過剰請求する手法です。軽度の水増し(5〜15%)は気づきにくいですが、BazaarLink Probeは既知のトークン数と報告値を比較して自動検出します。
TTFT(最初のトークンまでの時間)が500ms以内は正常です;2秒を超えるとパフォーマンス問題がある可能性があります。GPT-4oなどの大型モデルの平均TTFTは300〜800msです。
Ping はネットワーク接続だけを測定します。BazaarLink Probe はアプリケーション層(L7)で標準 84 項、拡張検査有効時は最大 86 項を実行し、モデルの身元、Token 計算、拒否動作、ストリーム形式、System Prompt 注入を確認します。
各プロバイダーのAPIエンドポイントをBazaarLink Probeに入力し、スコアとリスクフラグを比較します。スコアが高い(100に近い)ほど、赤い警告がないほど信頼できるエンドポイントです。モデルの真正性(すり替えなし)、トークン精度(水増しなし)、遅延パフォーマンス(TTFT)の3点に注目してください。