BazaarLinkBazaarLink
ログイン

AI API リレー完全性テスト

Step 1 — エンドポイントを設定

Base URL、APIキー、モデルIDを入力すると標準84項目を実行します。任意2項目を加えると最大86項目です。モデルの真正性、Token計測、プロンプト注入、サプライチェーン、ストリーミング互換性を確認します。

失効可能なテスト専用 Key を使用してくださいKey は今回の検査のために BazaarLink Probe サーバーへ送信され、エンドポイント監視用の認証情報として再利用されません。低額度の Key を使い、検査後に失効してください。

検査数の多い中継サービス

過去 24 時間
テスト回数リレー数

BYOK|審査ゲートの後ろにあなたのキーを置く

利用者が不適切な質問をすると、停止されるのはあなたの API key です。すべてのリクエストは先に BazaarLink のコンテンツ審査を通り、高リスクの質問は遮断され上流には届きません。これにより、規約違反のコンテンツでアカウントが停止されるリスクを大幅に下げます。

BYOK を詳しく見る →

BYOC|自分の GPU に、止まらない API の入口を

単一 API key。ノードの同時実行数が上限に達した、プロセスが落ちた、マシンが切断された場合、リクエストはシームレスにプラットフォームモデルへ移り、自分のノードの通信は課金ゼロです。fallback が引き継いだ通信だけが課金対象です。

完全なセットアップ手順 →
リサーチarXiv 2604.08407 — LLM サプライチェーン攻撃研究Twitter / X — BazaarLink ディスカッションarXiv 2407.15847 — LLMmap:大規模言語モデルの指紋識別arXiv 2604.24827 — IKP:事実容量によるブラックボックス LLM パラメータ数推定OWASP LLM Top 10 — LLM アプリケーションのトップ10セキュリティリスク

判定の仕組み

1テストを実施最大86問2どの会社か判定OpenAIか、Claudeか?3どのモデルか判定同じ会社の中から型番を特定4似た者同士を再確認似ているモデルを見分ける5答え合わせ実測 vs 申告
30
個の判断分岐
8
通りの結論
0
業者の自己申告をそのまま信じた回数
判定ツリーを展開して、3つの結果がどのように導かれるか確認する
判定ツリー5段階すべての分岐と、実際に通った経路① テストを実施1.1全問回答1.2一部未回答 <10%1.310%以上欠落、会社のみ判定10%以上欠落、会社の…1.4エンドポイント無応答② どの会社か判定2.1中国語の自己申告で即決2.2行動指紋で判定2.3証拠不足で保留MOD矛盾ガードで格下げ③ どのモデルか判定3.1Scoped を採用3.2他社照合で覆す3.3拒否応答の裏付け3.4他社照合で救済3.5Global に格上げ3.6IKP を最終防衛線に3.7保留、会社のみ判定M1V3F で裁定M2行動証拠による拒否権④ 似た者同士を再確認4.1全通過 → 確定4.2全通過 → 覆す4.3gate 未通過4.4H1 保護、覆さない4.5基準が古い⑤ 答え合わせ5.1完全一致5.2会社のみ一致5.3モデルが不一致5.4モデルすり替え5.5自己申告が偽装5.6行動が誘導された5.7データ不足5.8判断つかず
一致未確定不一致グレー = 今回通らなかった分岐ノードをクリックすると説明が見られます
設問にすべて回答があり、会社もモデルも一貫して一致、再確認でも確定 → 完全一致。
実際の経路 1.1 → 2.2 → 3.1 → 4.1 → 5.1

判定の方法と限界

私たちはエンドポイントに「あなたはどのモデルか」とは尋ねません。どんなエンドポイントでも、どんな名前でも答えられるからです。標準検査 84 項目を実行して実際に仕事をさせ、その仕事の仕方を、既知モデルの基準と突き合わせます。判定は粗いところから細かいところへ五つの段階を進み、どの段階でも「証拠が足りないので断定しない」と言えるようになっています。

五つの段階で絞り込む

  1. 実測する

    このエンドポイントはそもそも測定できるのか。

    判定の第一の前提は、設問に実際に答えが返っていることです。欠測は単に情報が少ないという話ではありません。返ってきた答えがたまたま同じ方向に偏ることがあり、それは証拠ではなく標本の偏りです。

    エンドポイントがまったく応答しない、あるいは鍵やモデル名がそもそも通らない場合は、そこで止めます。欠けたままの材料から結論を組み立てることはしません。

  2. どこの製品かを見分ける

    これはどの開発元のモデルか。

    すり替えで最も多いのは開発元をまたぐ形、つまり安いモデルが高いモデルの名前を借りる形です。開発元レベルの振る舞いは最も安定していて偽装が難しいので、まずこの層を問います。比べるのは回答の文体と癖であって、自称ではありません。自称はレポート全体で最も偽装しやすい項目です。

    開発元の証拠が足りなければ棄権し、無理に名指ししません。中国語で名乗る開発元と振る舞いが食い違う場合は、自称を言い間違いとみなして振る舞いの証拠に戻します。

  3. どの型番かを見分ける

    同じ開発元の中で、どの型番なのか。

    購入したのは特定の型番であって「あの開発元のどれか」ではありません。いわゆる性能低下の多くはこの層で起きます。開発元はそのままに、同じ系列の安い小型モデルへ差し替わるのです。私たちは系列内の比較と系列をまたぐ比較を同時に行い、互いに検算させます。開発元の判定を誤ると、系列内の比較は誤った型番を強い確信とともに返してくるからです。

    証拠が開発元の層までしか届かないときは、「どこの製品かは分かるが、どの型番かは分からない」とはっきり書きます。最も似ている候補で埋めることはしません。

  4. 双子を再検証する

    前段が選んだ型番は、近い兄弟と本当に区別できているのか。

    型番の中には双子のようなものがあります。文体も能力も言い回しも大きく重なり、前段の手法ではほとんど識別力がありません。点数は近く並びますが、その近さに意味はありません。この段階が行うのは一つだけです。そうした近縁の集まりに対して、その比較のために作られた別の設問群で採り直し、個々の答えではなく分布全体を見ます。通れば前段を確認するか覆し、通らなければ前段の結果をそのまま残します。

    この段階には意図的な非対称があります。証拠が決定的でなく、かつ前段の結果がたまたま販売元の申告と一致している場合、私たちは覆しません。誠実な販売元を誤って告発する代償は、一度見逃す代償より大きいからです。

  5. 申告と突き合わせる

    実測の結果は、販売元の申告とどこが違うのか。

    見分ける作業そのものは申告を見ません。前の段階が比べるのは振る舞いの証拠だけです。申告が入ってくるのは二か所だけで、第四段階が「覆すかどうか」を決めるときと、この段階です。この順序は意図的です。設問を読む前に答えを出しておけば、申告に引きずられません。結論は、完全一致、開発元のみ一致、型番の不一致、すり替え、自称の偽装、振る舞いの誘導、資料不足、判断保留に分かれます。

    複数の信号が互いに矛盾し、安定した多数が現れないときの結論が「判断保留」です。これは正式な結論であって、故障ではありません。

「判定できない」と言うことが多い理由

誤りの二つの方向は、代償が同じではないからです。誠実な中継サービスをすり替えだと言うのは告発であり、実際に人を傷つけます。一方で見逃しは、もう一度検査すればよく、履歴を見ることもできます。ですから証拠が足りないときは、断定しない側を選びます。

これはコードの上でも形を持っています。レポートが「モデル不一致」を描くのは、エンジンがすり替えを確認したときだけです。「最も似ているモデルがたまたま申告と違う」は告発として描かれません。それは私たちの推測にすぎないからです。「未確定」と出たときの正しい読み方は「今回の証拠では断定できない」であって、無罪の証明でも有罪の判決でもありません。

レポートの数字の読み方

ルール検査と身元判定
標準スイートは 84 項目のルール検査を実行し、行動の証拠から身元判定を導きます。新しいレポートでは異なる種類の検査を一つの総合スコアにまとめません。身元結果、ルール警告、証拠を分けて読んでください。
判定の強さ
今回の証拠がどれだけ強かったかを表します。設問がどれだけ答えられたか、複数の信号が同じ方向を指したか、近縁の候補との差がどれだけ開いたか。検査ごとに動く値であり、そのモデルに固有の性質ではありません。
過去の正解率
答えが分かっている標本に対して、この手法がどれだけ当たったかを示す値です。オフラインで算出しており、今回の検査とは無関係です。「今回の判定が正しい確率」と読み替えてはいけません。二つの数字は別の問いに答えており、置き換えられません。

できないこと

分かっている限界を書き出します。限界に触れないレポートは、実力以上に信用されてしまうからです。

  • 見えるのはこの一回の呼び出しだけ

    一度の検査は一度の標本です。中継サービスは一部の通信だけをすり替えることも、検査らしい通信のときだけ本物を返すこともできます。一度通ったことは、長期的な誠実さと同じではありません。定期的に測り直し、一枚のレポートではなく履歴を見てください。

  • 近縁の型番の識別には天井がある

    なりすます側が相手の振る舞いを半分以上まで意図的に模倣すると、証拠のおよそ半分は構造上、申告された身元を指します。これは設問が足りないのではなく構造的な上限です。実測しました。設問を増やすと費用は大きく上がりましたが、識別力はほとんど動きませんでした。

  • 「すり替えが無かった」ことは証明できない

    一致という判定の意味は「今回の証拠はすり替えを支持しない」であって、「すり替えは無かった」ではありません。後者を保証すると称する検査は、自らを誇張しています。

  • 古いレポートほど注記が少ない

    判定の経路は保存済みのデータから事後に再構成しています。エンジンは当時どの規則を通ったかを記録していません。保存されたデータからは区別できない分岐があり、その場合は結果だけを示し、規則の番号は付けません。推測するくらいなら、語らないほうを選びます。

検査範囲

レポート状態の見方

合格

応答が基準とセキュリティしきい値を満たしています。

注意

信号が不完全またはしきい値付近です。説明と生の応答を確認してください。

不合格

基準との差、プロトコルエラー、または完全性リスクが確認されました。

判定方法

モデル識別

ファミリー指紋、サブモデル特性、耐偽装信号を公称モデルと照合します。

計測と通信

Token数、SSE形式、遅延、応答構造を検証し、水増しや中継層の異常を検出します。

安全性とサプライチェーン

System Prompt注入、秘密情報流出、依存関係ハイジャック、署名改ざんを検査します。

このツールが検出する攻撃の種類

arXiv 2604.08407 に記載された主要なリレー攻撃を検出します。依存関係ハイジャック、条件付き System Prompt 注入、認証情報漏洩を、標準 84 項、拡張検査有効時は最大 86 項の Probe で確認します。セキュリティスコアは算出せず、身元の根拠と行動警告を提示します。

AC-1.a

レスポンス改ざん

プロキシがレスポンス解析中に tool-call やテキストコンテンツを改変し、エージェントに攻撃者が指定した操作を実行させます。一般的な手口には、npm/pip/go/cargo のインストールコマンドの改ざん、タイポスクワッティングパッケージの注入、シェルコマンドパラメータの書き換えが含まれます。検出方法は、プロキシのレスポンスを直接接続モデルの tool-call ペイロードと比較し、サイレントリライトを発見します。

AC-1.b

条件付きインジェクション

プロキシは prompt の内容に応じて system message を条件付きで注入します — 「銀行」「パスワード」「送金」などの機密用語を含むリクエストには悪意ある指示を、通常のリクエストには沈黙を返します。統計的に異常な分布が現れます。検出は Proxy Monitor がベースラインとテスト対象プロキシ間の system prompt のオフセットを比較します。

AC-2

シークレットスキャニング

プロキシはリクエスト (request) とレスポンス (response) の両端から API キー、アクセストークン、個人情報、企業秘密を静かにスキャンします。コンテンツ自体は変更されないため、一般的な diff ツールでは検出できません。検出は honeypot トークンを注入し、そのトークンがプロキシのログ、Telegram bot、または外部エンドポイントに現れるかを検証します。

よくある質問

AI API中継局検出とは何ですか?

AI API リレー検査は、OpenAI 互換 API がリクエストを正直に実行しているかを確認する自動テストです。BazaarLink Probe は標準 84 項、任意 2 項(最大 86 項)の Probe で、モデルすり替え、Token 水増し、System Prompt 注入、秘密情報窃取を検出し、身元判定と行動警告を表示します。

中継局がモデルをすり替えているかどうかはどう判断しますか?

最も信頼できる方法はモデルフィンガープリントです:特定のモデルだけが正確に答えられる質問(知識カットオフ日、特定の能力テストなど)を送信し、期待するモデルの応答と比較します。BazaarLink Probeにはこれらのプローブが内蔵されており、すり替えリスクを自動的にフラグします。

トークン水増しとは何ですか?

トークン水増し(token padding)とは、中継局がAPIのusageフィールドに実際の消費量より多いトークン数を報告し、過剰請求する手法です。軽度の水増し(5〜15%)は気づきにくいですが、BazaarLink Probeは既知のトークン数と報告値を比較して自動検出します。

APIの遅延はどのくらいが正常ですか?

TTFT(最初のトークンまでの時間)が500ms以内は正常です;2秒を超えるとパフォーマンス問題がある可能性があります。GPT-4oなどの大型モデルの平均TTFTは300〜800msです。

BazaarLink Probeと通常のpingテストの違いは何ですか?

Ping はネットワーク接続だけを測定します。BazaarLink Probe はアプリケーション層(L7)で標準 84 項、拡張検査有効時は最大 86 項を実行し、モデルの身元、Token 計算、拒否動作、ストリーム形式、System Prompt 注入を確認します。

検出結果をプロバイダー選択にどう活用できますか?

各プロバイダーのAPIエンドポイントをBazaarLink Probeに入力し、スコアとリスクフラグを比較します。スコアが高い(100に近い)ほど、赤い警告がないほど信頼できるエンドポイントです。モデルの真正性(すり替えなし)、トークン精度(水増しなし)、遅延パフォーマンス(TTFT)の3点に注目してください。

LLM リレー / リバースプロキシ API 品質チェック

OpenAI互換リレーまたはリバースプロキシを入力し、標準84項目と任意2項目(最大86項目)で、モデルすり替え、Token水増し、System Prompt注入、依存関係ハイジャック、秘密情報流出、署名改ざんを検査し、識別結果と行動警告を表示します。攻撃分類は arXiv 2604.08407 に基づいています。

中国語推論コード生成モデルすり替え検出トークン水増し検出システムプロンプト漏洩SSE ストリーム検証プロンプト注入テストモデル指紋識別
謝辞 / Acknowledgements
このツールは以下のオープンソースプロジェクトから着想を得ています: LLMmap(MIT、LLM モデル指紋識別)api-relay-audit(MIT、リレーセキュリティ監査)relayAPI(リレーサービス一覧)
テスター協力への感謝
今書
BazaarLink に戻る
サポート
サポート
こんにちは。どのようなご用件でしょうか?
メッセージをお送りください。担当者より返信します。
BazaarLink Probe|LLM API リレー品質・モデルすり替え検査 | BazaarLink