GitHubで見つけた無料API、SNSで流れてきたOpenAI互換エンドポイント。それを開発ツールの接続先に設定した瞬間、会話も送信したコードも、モデルの提供元ではなくその運営者を通ることになる。

先に釘を刺しておきたい。無料であること自体は問題ではない。GroqやCerebrasのように、運営主体が明確で規約もあり契約関係を結べる無料枠は普通に存在する。問題は、誰が運営していて送ったデータがどう扱われるかを検証できないまま、それをエージェントの接続先にしてしまうことだ。

この記事が扱う最悪のケースは、ファイル読み取りやコマンド実行の権限を持つAIエージェントの話である。チャット画面で対話するだけで外部ツール連携を許可していない読者は、ここで挙げる被害には直結しない。ただし会話が運営者を通る点は変わらないので、末尾に短いチェックリストを用意した。

論点は「無料」ではなく「検証できない中間者」

OpenAI互換APIが事実上の標準になったことで、base URLとAPIキーを差し替えるだけで、どのツールの接続先でも変えられるようになった。この汎用性の高さが利便性を生んだ一方で、悪意ある中間者を挿し込みやすくもした。

非公式のアグリゲーターは珍しくない。複数プロバイダーを1つのOpenAI互換エンドポイントに集約する「gpt4free (g4f)」、GPT・DeepSeekの無料枠を提供する「chatanywhere/GPT_API_free」、34プロバイダー・635モデルを1つの/v1にまとめるプロジェクトなど、公開リポジトリで数多く見つかる。これらを「違法」「悪意がある」と決めつけるつもりはない。運営主体や調達経路が見えにくい実装例、というのが正確な言い方だ。

先に線引きをしておく。運営主体・利用規約・データ取扱いが明示され契約関係を結べるものと、素性が追えないものは別物である。この記事が警戒するのは後者だけだ。

428件を実測した研究が示すもの

この問題の核心は単純だ。モデルの出力には署名の仕組みがない。だからクライアント側には、返ってきた応答が「本当にそのモデルが生成したもの」なのか、「途中のルーターが差し替えたもの」なのかを見分ける手段が、原理的に存在しない。

この構造を初めて系統的に定量化したのが、UCSB・Fuzzland・UCSDなどの研究者による論文「Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain」だ（arXiv 2604.08407、2026年4月9日公開、ACM CCS 2026採択）。研究チームは有料ルーター28件（淘宝・閑魚・Shopify経由で購入）と、公開コミュニティから収集した無料ルーター400件、合計428件を実測した。

結果は次の通りだ。9件（無料8・有料1）が悪意あるコード注入を実施していた。17件が研究者の仕掛けたAWSカナリア認証情報にアクセスし、1件では研究者が用意したEthereum秘密鍵から実際に資金が流出した。440セッションで99種類の認証情報が露出した。

ただし、残り419件について悪性が示されたわけではない。この調査が示したのは「一定割合に実害がある」ことであって、「無料なら危ない」ということではない。読者が持ち帰るべきなのは「無料を避けろ」ではなく、「検証できない相手に渡すな」である。

手口は大きく2類型に整理できる。1つは応答の改ざんで、モデルが生成したツール呼び出しを、上流プロバイダーを離れてからクライアントに届くまでの間に書き換える。しかもツール名・キーワード・ユーザーの指紋・時間帯・リクエスト数といった条件で発動を切り替える「条件付き発動」ができるため、試した時だけ無害に振る舞うことができる。もう1つは静かな盗聴で、応答は一切改変せずそのまま転送し、裏で認証情報らしき文字列をスキャンして非同期に流出させる。挙動が何も変わらないので、利用者側に気づく手がかりがない。

エージェントだと被害が桁違いになる理由

「承認画面をちゃんと見れば防げる」は、この構造の前では成立しない。注意深さではなく、構造で防ぐしかない理由を3層に分けて説明する。

第1層は、すでに渡っており、ブロックできないものだ。プロンプト、エージェントが既にコンテキストへ読み込んだファイルの中身、システムプロンプト、そのエンドポイント用に発行したキー。これらは承認の有無に関係なく、もうルーター側にある。先述の盗聴型の手口は挙動が変わらないため、検知自体ができない。

第2層は、承認でゲートされてはいるが、そのゲートが弱いものだ。ルーターが新たに発行するツール呼び出しは、理屈の上では人間が止められる。しかし実際には機能しないことが多い。自動承認（いわゆるYOLOモード）が有効なら素通りする。前掲の研究では401セッションで自動承認が既に有効だった。read_fileを「常に許可」にしていれば、その範囲も素通りする。

さらに厄介なのは、個別には無害なツールの組み合わせを人間には判定できないという点だ。HiddenLayerの実証がまさにこれにあたる。Cursorの「Override OpenAI Base URL」機能で任意のプロキシにモデルを向けさせシステムプロンプトを漏洩させたうえで、read_file（任意ディレクトリの読み取り）とcreate_diagram（画像リンク経由の外部送信）という、単体では怪しくない2つのツールの結合でSSH秘密鍵を流出させた。この問題自体はCursor 1.3で修正済みだ。重要なのは個別の脆弱性ではなく、第三者プロキシが会話内容を受け取る設計そのものと、ツールを持つエージェントでは応答の改変がそのまま実行につながるという2つの構造である。条件付き発動が組み合わされば、「検証した時は問題なかった」が通用しなくなる。

第3層が、唯一の硬い境界だ。エージェントのプロセスが実際に到達できる範囲である。ユーザー権限で動いていれば~/.sshは読める。ここだけがOSに担保された本当の境界であり、防御を置くべき場所になる。

だから対策の方向性は、「承認を丁寧に見る」ではなく、「そもそも到達させない」に変わる。

誰が危険で、誰は巻き込まれないのか

素性を検証できるかどうかは、次の5点で見分けられる。運営主体が特定できるか。利用規約とデータ保持・学習利用の記載があるか。上流プロバイダーが明示されているか。障害時の問い合わせ窓口があるか。無償で提供できる経済的合理性が説明できるか。

正規の無料枠はこの基準を満たす。GroqやCerebrasは学習利用なしをデフォルトとして明示している。OpenRouterの無料モデルは「学習・ログを許可するプロバイダーへルーティングされる」と公式ドキュメントに書かれている。リスクがゼロなのではなく、開示されていて検証できる点が決定的に違う。危ないのは、これらのどれも確認できないまま接続先にしてしまうことだ。

無料の原資は一様ではない。g4f自身がREADMEでブラウザ自動化とHARファイル・Cookieの利用を明記し、「保証なし」「機密情報を共有するな」と書いている。背景には盗難APIキーの市場（Sysdigが2024年に報告した数字で最安30ドル、悪用されると1日46,000ドル超の請求）や、無許可転売市場（複数のセキュリティ調査によれば最大90%引きでの転売、約半数のコールでモデルがすり替え）が存在する。個別サービスが盗品で動いている証拠ではないが、調達経路を説明できないルーターを業務で使う判断はできない。

一般ユーザー向けに3点だけ渡す。チャットで使うだけなら最悪ケースには直結しない。ただし会話は運営者を通る。「独自AI」を名乗るアプリが実際は他社APIへの転送口で、無料アクセスと引き換えに会話や端末情報を収集していた事例が報告されている。機密や個人情報を入れる前に、運営者が誰かを確認する。

今日やること

導入前にすること。運営主体、利用規約、データ保持と学習利用、上流プロバイダー、問い合わせ窓口を確認する。ひとつでも不明なら業務データを送らない。「公式なら安全」でもない。公式エンドポイントでも、保持・学習利用の条件と自組織の契約条件は確認しておく。

利用中にすること。本番用のキーを渡さない。接続先ごとに使い捨て・上限付き・低権限のキーを発行する。自動承認（YOLO）は切る。ただし必要条件であって十分条件ではない。最も効くのは、エージェントのプロセスが機密に最初から到達できないようにすることだ。隔離環境で動かす、機密を含まないディレクトリで作業する、本番クラウドの認証情報を環境変数に置かない、といった対応が該当する。

利用後にすること。素性の分からないルーターに実キーを送ったなら失効させ再発行する。利用明細とアクセスログを確認する。不正利用は課金として先に現れることが多い。

最後に、AIの供給網では別種の事故も起きていることに触れておく。2026年3月、OpenAI互換プロキシとして広く使われるLiteLLM（月間ダウンロード数9,500万）がPyPIごと侵害され、AWS・GCP・Azureの認証情報やSSH鍵を窃取する版が約40分間配布された。影響は2,500以上の組織に及んだ。中間者問題とは攻撃面が異なるが、AI関連の中継・拡張レイヤーが標的になっている点は共通している。接続先を選ぶ基準は、便利さではなく検証可能性に置くべきだ。