Simon Willison、安価なLLMリレーアクセスの裏にある対立を暴く

Simon Willisonは、割引価格のLLMアクセスが、プールされた認証情報、露出したボット、決済詐欺に依存しうるリレー市場に注目を集めた。7月26日の投稿で彼は、ソフトウェアエンジニアのMatt Lenhardによる調査を紹介している。その調査は、主に中国語圏のコミュニティを通じて、開発者、スタートアップ、その他の購入者にサービスを提供する商業的なサプライチェーンを描いている。

この対立は、公式APIとより安価な競合サービスの間にあるだけではない。正当なゲートウェイ技術と、計算能力の出所を隠している可能性がある再販市場との間にある。購入者に見えるのは、互換性のある単一のエンドポイントと便利な請求体系だ。上流のアクセスが正当に購入されたものなのか、別のアプリケーションから取得されたものなのか、不正なアカウントを通じて得られたものなのかを、容易には確認できない。

この不確実性は、3つの層に同時に圧力をかける。モデル提供者は不正利用とチャージバックの負担を負う。アプリケーション開発者は、露出したエンドポイントがリレーの在庫になるリスクに直面する。購入者は、身元やデータ取り扱いが不明確な仲介者を介して、プロンプト、ソースコード、業務データを送ることになる。

Simon Willisonが隠れたリレー経済を可視化した

重要な変化は可視性にある。散発的な不正利用の問題が、専門化した供給者、インフラ、顧客を持つ組織的な市場として見えるようになった。

Willison自身が基礎となる現地調査を行ったわけではない。彼のリレーに関する警告はLenhardの発見を広め、アプリケーション開発者が直面する実務的な問題と結び付けた。露出したLLM機能は、もはや日和見的な不正利用だけを招くものではない。不正アクセスを収益化するために設計された下流のビジネスに供給できてしまう。

Lenhardは、リレー関連の用語や手法を運営者たちが議論していた中国語フォーラムを調査した後、6月28日にその調査を公開した。彼によれば、この関心は、無料クレジットの不正利用とサポートボットへの攻撃が繰り返されるAIゲートウェイに取り組んでいた際に生まれたという。他社との会話を通じて、このパターンが単一のサービスを超えて広がっていると確信したとしている。

報告書の主要なフォーラム情報源は、3月5日から6月23日まで運営されていた。Lenhardによれば、その議論には約35,000回の閲覧と190件の返信が集まった。これらの数字は一つのコミュニティ内での関心を示すが、より広い市場全体の規模を確定するものではない。

リレーは、ときにトランスファーステーションとも呼ばれ、主要なモデル提供者のインターフェースに似たAPIエンドポイントを顧客に提供する。顧客はアプリケーションのベースURLを変更し、リレーが発行した認証情報を送信する。リレーはその後、各リクエストを上流のアカウントまたは別の仲介者へ転送する。

この設計はかなりの複雑さを隠している。顧客には、馴染みのあるモデル名、利用残高、リクエスト形式が見える。そのインターフェースの背後で、運営者は認証情報をローテーションし、レート制限を回避し、失敗した呼び出しを再試行し、要求されたモデルを別のモデルにマッピングできる。

Lenhardは、大きく4つの層を説明している。カードおよびアカウントの販売業者が決済手段や登録済みアカウントを調達する。アカウントプールが認証情報を集約し、制限を管理する。消費者向けリレーがその能力を使いやすいサービスとしてパッケージ化する。開発者や商用ユーザーが、そこで生まれたアクセスを購入する。

これらの役割は重なることがある。一人の運営者がアカウントプールと販売フロントの両方を管理する場合もある。別のリレーは、各認証情報の出所をすべて把握せずに、独立したプールから容量を購入する場合もある。この分離により、提供者が不正利用を検知した際の責任追跡は難しくなる。

市場には、個々の販売者を超えた消費者向けインフラも存在するようだ。Lenhardは、価格比較サイト、アフィリエイトプログラム、カスタマーサポートグループ、専門的なゲートウェイ製品を報告している。彼によれば、チームが追跡した最も利用の多い10のリレーは、月間合計360万件の訪問を受けていた。

このトラフィック推計はLenhardの調査に基づくものであり、帰属付きの測定値として扱うべきだ。訪問者のうち何人が有料顧客になったかは示していない。また、正当なアクセスと、最終的に不正行為によって供給されたアクセスも区別できない。

それでも、周辺インフラは重要だ。比較サイトやアフィリエイトプログラムは、リレーを見つける手間を減らす。標準化されたソフトウェアは、その運営に必要な労力を減らす。アカウントプールは、上流の認証情報のいずれか一つが使えなくなった際の損害を抑える。

これが、Willisonの介入が注目に値する理由だ。彼はリレー市場を、単なるモデル価格や地域的な利用可能性をめぐる争いではなく、アプリケーションセキュリティの問題として捉え直した。高コストな推論を公開するあらゆる製品は、意図せず供給者になり得る。

最も重要な教訓は、最も単純でもある。LLMエンドポイントは、提供者のキーを公開しなくてもリスクを生み出す。外部者がそれを通じて無制限のリクエストを送れるなら、そのエンドポイント自体が実質的に再利用可能な認証情報となる。

安価なトークンがAIサプライチェーン全体に圧力をかける

リレー需要は、脆弱な支出管理、公開チャットボット、保護の不十分なアプリケーションを、すべて潜在的な在庫へと変える。

最も直接的な圧力を受けるのは、モデル提供者とその請求を支払う企業だ。無料トライアルは顧客獲得の経路を生むが、自動登録によって、そのクレジットが再販用の容量に変換される可能性がある。チャージバックは、すでに消費された推論コストを提供者や販売業者に押し戻すことがある。

盗難カードは、より直接的な損失を生む。アカウントは、リレーが利用可能な容量を消費するのに十分な期間、有効なままである可能性がある。カード保有者や発行会社が取引に異議を申し立てる頃には、モデル出力はすでに下流へ配信されている。

プリペイドカードやバーチャルカードは、それ自体が不正行為の証拠ではないものの、リスク判断を複雑にする。正当な顧客の多くも両方の製品を利用している。そのため提供者は、決済シグナルを、アカウント年齢、リクエストの挙動、デバイス情報、ネットワークパターンと組み合わせる必要がある。

アプリケーション企業は別の問題に直面する。公開されたサポートアシスタント、文章作成機能、文書分析エンドポイントは、企業が管理するアカウントを用いてリクエストを転送している場合がある。そのエンドポイントに認証や厳格な制限がなければ、攻撃者はそれを別のサービスとして包み込める。

攻撃者は基盤となるキーを抽出する必要はない。代わりに、アプリケーションのリクエスト形式を再現し、無関係なプロンプトをそのバックエンド経由で送信する。アプリケーションはプロキシとなり、その所有者に請求が届く。

Willisonは、この可能性が、自身のLLM搭載アプリケーションを公開することにより慎重になる理由だと述べている。開発者が定義したしきい値に支出が達した際、アプリケーションを停止する提供者側の制御を求めている。アラートは有用だが、急増の後に届くアラートでは損失を防げない。

AIエージェントがリクエスト量と並行性を高めるにつれ、この懸念は大きくなる。対話型チャットボットは、ユーザー操作の後に1回のリクエストを送るかもしれない。コーディングエージェントは、繰り返し呼び出しを行い、大量のコンテキストを添付し、限られた監督のもとで作業を継続できる。

並行性は、基本的な残高チェックも無効にしうる。複数のリクエストが、アカウントが制限を下回っている間に開始される可能性がある。システムが完了後にのみコストを記録する場合、合計利用量は意図した上限を超えることがある。

より安全な設計では、進行中の各リクエストに予算を予約する。また、アカウント、認証情報、エンドポイント、時間枠ごとに制限を適用する。これらの制御は、リレーの不正利用とdenial-of-wallet攻撃の両方による損害を抑える。

Denial of walletは、他者が支払ったAPI利用枠を消費することを目的としたリクエストを指す。再販とは異なり、攻撃者には下流の顧客がいない場合もある。とはいえ、標的が十分な認可や制限なしに高コストな処理を受け入れるという技術的な弱点は似ている。

その圧力は、より小規模なアプリケーションチームへと移る。大手モデル提供者は、決済リスクシステム、不正対策チーム、広範な行動テレメトリを維持できる。一つのAIサポート機能を追加するスタートアップには、その3つすべてが欠けていることがある。

開発者は、公開するAI機能をそれぞれ、従量課金される金融インターフェースとして扱う必要がある。攻撃者が多数のアカウントを作成できる場合、認証だけでは不十分だ。リクエストが単一の組織予算を共有する場合、ユーザー単位の制限だけでも不十分だ。

入力制限は役立つが、サーバー側で強制する必要がある。サポートに関する質問だけを受け付けるブラウザーインターフェースでも、任意のテキストを処理できるバックエンドを呼び出している可能性がある。攻撃者はインターフェースを迂回し、基盤となるリクエストを直接実行できる。

チームは、実験用の認証情報と本番アカウントも分離すべきだ。テスト用ルートの漏えいが、組織の全支出能力を露出させてはならない。狭い権限、モデル制限、独立した予算により、見落とされた制御の影響を減らせる。

この取り組みは、正当なユーザーに摩擦を生む。厳格な本人確認は、対応する書類や決済手段を持たない顧客を阻害する可能性がある。積極的なネットワークフィルターは、旅行者、共有オフィス、プライバシーを重視するユーザーに不利益を与えうる。

このトレードオフは、リレー需要が持続する理由の一端を説明している。一部の購入者は運用コストの削減を望む。別の購入者は、地域の公式チャネルを通じて利用できないモデルを求める。既存の開発者ツールで動作するOpenAI互換エンドポイントを探している人もいる。

こうしたニーズが、すべての購入者を上流の不正行為に加担させるわけではない。しかし、所有者が不明確で異常に安価なサービスは、顧客に大きなリスクを移転する。利便性は、不安定なアクセス、代替されたモデル、保護されていないデータを隠しうる。

1つのAPIエンドポイントが数百の認証情報を隠せる

リレーの仕組みが機能するのは、標準的なゲートウェイ機能が、顧客体験を各上流リクエストの出所から切り離せるためだ。

Lenhardによれば、彼が調査したリレーの大半はone-apiまたはnew-apiを利用していた。どちらも、複数のモデル提供者を単一の互換インターフェースの背後に配置できるオープンソースのゲートウェイだ。一般的な社内利用や企業利用に適した正当な製品である。

ゲートウェイソフトウェアは、複数の提供者、トークン管理、チャネルグループ、モデルマッピング、再試行動作、ロードバランシングをサポートしている。企業はこれらの機能を使い、従業員にはより限定的なアクセストークンを付与しながら、認証情報を一元管理できる。

そのドキュメントは、提供者の利用規約と適用法を順守するよう利用者に求めてもいる。したがって、このソフトウェア自体は不正行為の証拠ではない。重要なのは、運営者がチャネル内に配置する上流アカウントをどのように取得しているかだ。

New APIは同じ一般的なアーキテクチャを拡張している。このプロジェクトは、集約、組織認証、利用分析、プライベートデプロイメントのためのゲートウェイであると説明している。そのゲートウェイフォークには、認可されたサービス運営者に有用な決済、会計、権限、ルーティング機能が追加されている。

New APIも、上流のキーとアカウントは合法的に取得されなければならないとしている。公開サービスや再販サービスの運営者に対し、認可、ライセンス、ログ記録、本人確認、決済、規制上の義務を満たすよう警告している。こうした注意書きは、ソフトウェアが意図する用途と、不正な展開を区別している。

リレー運営者は、まずチャネルを設定する。各チャネルは、モデル提供者、アプリケーションサービス、または別のプールを指す。ゲートウェイは、それらのチャネルに認証情報を割り当て、顧客がリクエストを送信した際に一つを選択する。

ルーティングは、不安定な認証情報をより安定した製品へと変える。あるアカウントがレート制限に達したり停止されたりした場合、システムは別のチャネルを試行できる。重み付きルーティングでは、より安価または信頼性が高いと見られるソースを優先できる。

ゲートウェイは次に、顧客のリレー残高に対して利用量を計上する。この会計レイヤーでは、上流プロバイダーが実際に請求した金額は明らかにならない。反映されるのは、運営者自身のルール、係数、モデルマッピングだけである。

この分離が、中心的な情報格差を生む。指定した最先端モデルを要求する顧客は、どの上流アカウントが呼び出しを処理したのかを独自に確認できない。要求したモデルが実際に応答を生成したことの確認も難しい場合がある。

モデルマッピングは、正当な導入環境でも有用だ。企業は互換性のあるシステム間でトラフィックを移動させたり、安定した社内モデル名を提供したりできる。不正な運営者は同じ機能を使い、プレミアムなラベルを維持したまま、より安価なモデルにすり替えることができる。

単純な出力テストでは、この問題を完全には解決できない。近縁のモデルは、一般的なプロンプトに対して似た回答を返すことがある。プロバイダーは公開ラベルをすべて変更せずにモデルを更新することもある。リレー運営者は、選別したリクエストだけを約束されたモデルに送ることも可能だ。

プロキシはリクエストを上流へ転送する必要があるため、リクエスト全体を確認する。コーディングツールでは、ペイロードにリポジトリのファイル、アーキテクチャに関するメモ、デバッグログ、システム指示が含まれる場合がある。業務アプリケーションでは、顧客記録や社内文書が含まれる可能性がある。

正当な企業ゲートウェイは、組織の管理下でセキュリティポリシーに従って運用される。未知のリレーは、その境界の外に新たなデータ処理者を生み出す。購入者は、保持、アクセス、暗号化、インシデント対応、削除に関するその主張を信頼する必要がある。

リレーは複数のプロバイダーにまたがってリクエストを転送する場合もある。フェイルオーバーは可用性を向上させるが、プロンプトを受信し得るシステムの数を増やす。正確なルーティングとデータ処理に関する開示がなければ、顧客はその露出を評価できない。

この区別は、オープンソースをめぐる政策論争において重要である。one-apiやnew-apiを非難するのは、能力と行為を混同することになる。Webサーバー、決済システム、ロードバランサーもまた、合法的な事業と不正な運用の双方を支えている。

より良い対応は、認証情報の来歴、認可、観測可能な行動に焦点を当てることだ。プロバイダーは、関連アカウント、異常なリクエストパターン、決済上の異常、登録直後の急速な消費を検出できる。アプリケーションの所有者は、自らのエンドポイントが受け入れる内容を制限できる。

オープンソースのメンテナーは、あらゆる導入を取り締まろうとせずに、防御的な管理運用を支援できる。安全なデフォルト、目立つセットアップ警告、監査ログ、支出制御、明確なモデルルーティング記録は、正当な運用をより安全にする。ただし、強い意図を持つ不正利用をなくすことはできない。

このソフトウェアの中立性こそが、この話を重要にしている。リレー運営者は、特殊なアンダーグラウンドのインフラを必要としない。企業がガバナンスとコスト管理に使うものと同じゲートウェイのパターンで、販売窓口を組み立てられる。

割引は不正、すり替え、データ露出を覆い隠し得る

リレーの顧客が購入しているのは不確かなキャパシティだけではない。モデルの同一性、稼働時間、送信するすべてのプロンプトを仲介者に託している。

Lenhardは、報告されているリレー在庫の供給源をいくつか挙げている。大量作成されたトライアルアカウント、チャージバック活動、盗難された決済カード、プリペイドアカウント、公開されたアプリケーションエンドポイントなどだ。この組み合わせは、運営者や時期によって異なる可能性が高い。

彼の調査は、追跡したすべてのリレーがそうした手法を使っていることを独自に証明するものではない。また、割引が存在することだけで不正が立証されるわけでもない。認定再販業者、地域プロバイダー、交渉済みのキャパシティを持つ企業は、正当な節約を提供できる。

それでも、一部で報告されている割引の規模は、来歴に関する疑問を生む。持続可能なサービスでは、誰かがコンピューティング資源の費用を負担するか、より低い利益率を受け入れるか、特別な契約を通じてキャパシティを確保する必要がある。購入者は、どの説明が当てはまるのかを問うべきだ。

信頼できる仲介者は、自らの法人を明示し、明確なサービス条件を提供すべきである。どのプロバイダーがモデルを供給するのか、再販が認可されているのかを説明すべきだ。プロンプト保持、再委託先、インシデント報告、アカウント停止についても文書化すべきである。

購入者は信頼できるモデル検証も求めるべきだ。リレーのダッシュボード内にある表示ラベルだけでは不十分である。運営者がより小さなモデルにすり替えたり、過負荷のチャネルへルーティングしたり、通知なしにプロバイダーを変更したりすれば、出力品質は低下し得る。

モデルのすり替えは、パフォーマンス上の問題にとどまらない。チームはあるモデルでアプリケーションを評価しながら、知らないうちに別のモデルでデプロイする可能性がある。その結果、安全性の挙動、コンテキスト処理、ツール利用、構造化出力が、コード更新なしに変化することがある。

可用性にも同様の不確実性がある。認証情報プールは、トラフィックを生き残ったアカウントへ移せるため、しばらくの間は障害を隠せる。しかし、プロバイダーによる協調的な執行は、多数の関連アカウントを同時に無効化し得る。

リレーは、顧客残高と運用履歴を抱えたまま消滅する可能性もある。とりわけ法域をまたぐ場合、購入者が利用できる契約上の救済は限られるかもしれない。そうなると、表面的な節約を中断や移行のコストと比較することは難しくなる。

プライバシーは最も深い懸念をもたらす。すべてのプロンプトは、リレーまたはその上流プールが管理するインフラを通過する。暗号化は通信中のトラフィックを保護するが、プロキシはリクエストを転送または変換するために、その内容へアクセスしなければならない。

コーディングエージェントを使う開発者は、孤立した断片以上のものを露出させる可能性がある。エージェントセッションには、完全なファイル、依存関係情報、内部URL、データベース構造、認証ロジックが含まれる場合がある。無害に見えるデバッグ要求であっても、システムの構成を明らかにし得る。

2026年の学術的な認証情報漏洩に関する研究は、LLM接続アプリケーションをめぐるより広範な弱点を示している。研究者らは444本のiOSアプリを調査し、そのうち282本で悪用可能な認証情報を発見した。

研究者らは3つの漏洩パターンを特定した。JWTベースのトークン露出が48％、認証されていないバックエンドプロキシが33％、平文のAPIキーが19％を占めた。これらの分類は、攻撃者が従来型のプロバイダーキーを見つけなくてもキャパシティを取得できることを示している。

責任ある開示の後、研究者らは3か月後に脆弱なアプリケーションを再確認した。報告された問題を修正していたのは28％にすぎず、72％は依然として悪用可能な状態だった。バックエンドとトークン設計における根強い問題が、修正を遅らせた。

この研究は、Lenhardの報告に登場するリレー運営者が、それらの特定アプリを悪用したことを証明するものではない。ただし、技術的に悪用可能なLLMキャパシティが相当数存在することは示している。認証されていないプロキシは、生のキーを露出させずに呼び出せるため、特に関連性が高い。

購入者は法的・契約上の不確実性にも直面する。顧客は、自分のリクエストが上流プロバイダーの規約に違反していることを知らない可能性がある。それでも、元々誰が契約に違反したかにかかわらず、中断の影響は顧客に及び得る。

地理的な制限は状況を複雑にする。一部のユーザーは、所在地域で直接のモデルアクセスが利用できないため、リレーを利用する。リレーは満たされていない需要を機能するエンドポイントへ変換するが、輸出、契約、規制上の制約を取り除くわけではない。

モデル蒸留は、もう一つの議論を呼ぶ側面を加える。Lenhardは、一部の商業購入者がリレー経由の出力を使って国内モデルを学習させていると主張したフォーラム参加者を引用している。これらのコメントは運営者コミュニティから翻訳されたものであり、独自に検証されたものではない。

蒸留そのものは、広く行われている技術的な手法だ。より小さなモデルが、別のシステムの出力や関連する学習シグナルからパターンを学ぶ。特定の利用が許可されるかどうかは、アクセス条件、データの権利、正確な手法に依存する。

最も擁護可能な結論は、最も劇的な主張よりも限定的だ。リレーはユーザーとモデルプロバイダーの間に不透明な制御点を生む。その不透明性は、顧客が不正に加担する意図をまったく持っていなかった場合でも、複数のリスクを可能にする。

主な争点は正当なアクセスと隠された来歴の対立

リレー市場を特徴づける対立は、オープンソース対クローズドソースではない。利便性の高いアクセス対、検証可能な認可である。

公式APIは、顧客にモデルプロバイダーとの直接的な契約関係を与える。その関係がすべてのプライバシーや信頼性の懸念をなくすわけではない。しかし、請求、モデルアクセス、セキュリティ文書、サポートに関する責任をより明確にする。

リレーは、少なくとも1つの追加当事者を挿入する。アカウント販売者やプールが加われば、さらに増える。各レイヤーは可用性や地域での使いやすさを改善し得るが、各レイヤーが来歴と説明責任を検査しにくくする。

この対立構造は、価格だけの比較が不十分である理由を説明する。公式エンドポイントと不透明なリレーは、構文上は似た応答を返すかもしれない。しかし、認証情報、プロンプト、モデルの同一性、顧客資金について、同じ管理連鎖を提供しているわけではない。

認可されたゲートウェイは、正当な中間領域を占める。企業は承認済みアカウントを一元化し、予算を適用して利用状況を監視できる。地域プロバイダーは、文書化された契約のもとでキャパシティを再販できる。エンタープライズプラットフォームは、顧客が選択したモデル間でルーティングできる。

差別化要因は証拠である。認可された運営者は、上流との関係、契約上の役割、セキュリティ制御、データ慣行を開示できる。顧客は、契約、監査報告書、文書、サポートチャネルを通じて、これらの主張を評価できる。

不透明な運営者は、購入者に稼働時間やコミュニティでの評判から正当性を推測するよう求める。どちらのシグナルも認可を証明しない。大規模な認証情報プールは、個々のアカウントが繰り返し停止されていても、可用性を維持できる。

コミュニティレビューは明白な詐欺を特定できるが、レビュー担当者はすべての上流リクエストを観測できない。リレーはテスト中には誠実に運用され、その後に調達方法を変える可能性がある。認可されたキャパシティと、疑わしいフォールバックチャネルを組み合わせる可能性もある。

そのため、プロバイダーは難しい執行上の選択に直面する。積極的なアカウント制御は、不正利用のコストを引き上げられる。同時に、共有ネットワーク、国際的な決済手段、自動化ワークフローを使う正当な開発者を排除する可能性もある。

本人確認は、別の移行効果を生む。直接アカウントの作成が難しくなると、攻撃者は露出したアプリケーションエンドポイントや既存アカウントを探す可能性がある。Lenhardは、プロバイダーの検証強化が不正利用をアプリケーション層へ押しやると予測している。

この予測を確実なものとして扱うべきではない。プロバイダーがシグナルを共有し、支出制限を改善すれば、より良い制御は全体的な不正利用を減らし得る。ある経路の収益性が下がれば攻撃者は依然として移動するため、転位は深刻な可能性として残る。

アプリケーション所有者は、自らのエンドポイントが試行されることを前提とした防御を必要とする。リクエストを認証し、限定的なスキーマを適用し、同時実行数を制限し、進行中の支出を予約し、想定したタスクと無関係なプロンプトを拒否すべきだ。

行動監視では、アカウント年齢、リクエストのタイミング、モデル選択、ネットワークシグナル、急激なボリューム変化を確認すべきである。単一の指標だけで決定づけることはできない。複数のシグナルを組み合わせれば、通常の利用と自動化された抽出・再販トラフィックを区別できる。

チームは、影響を受けたアプリケーションの外部に緊急制御を維持すべきである。侵害されたサービスは、管理者が支出を停止する前にオンラインであり続ける必要があってはならない。プロバイダーレベルのロックと独立した予算制御は、最後の境界を提供する。

組織には検索可能な運用記録も必要だ。不審な利用を調査するエンジニアは、デプロイ変更、アラート、請求書、エンドポイントログを迅速に結び付けなければならない。構造化されたエンジニアリング・ナレッジベースは、セキュリティテレメトリに取って代わることなく、この調査を短縮できる。

購入者にも並行した責任があります。どのアプリケーションがリレーエンドポイントを利用しているか、またそれらのアプリケーションがどのようなデータを送信しているかを棚卸しすべきです。シークレット、独自コード、個人データ、顧客文書を、検証されていないプロキシ経由で送ってはなりません。

また、移行できるよう設計する必要があります。互換性のあるエンドポイントは導入を容易にしますが、モデルの挙動や認証の詳細は依然として異なる可能性があります。直接のプロバイダーまたは認可済みの代替手段をテストすることで、単一の仲介事業者への依存を減らせます。

目標はゲートウェイをなくすことではありません。ゲートウェイは、認証、予算、ルーティング、可観測性に関する実際の課題を解決します。目標は、購入者がインフラと、不正利用を基盤とした裁定取引とを区別できる程度に、出所と認可を可視化することです。

市場が成長を続けるかを示す3つのシグナル

次の段階を左右するのは、強制力のある支出管理、アプリケーションエンドポイントへの移行、そしてモデルの出所を示すより明確な証拠です。

1つ目のシグナルは、主要なモデルプロバイダーが厳格かつ即時に機能する支出ロックを導入するかどうかです。有用なロックは、定めた予算を使い切った時点で新規リクエストを停止しなければなりません。また、すでに実行中のリクエスト向けの容量も確保すべきです。

Willisonは特に、開発者が選択したしきい値で機能を停止するキーが必要だと主張しています。この機能があれば、アプリケーションの漏えいがもたらす最悪の結果を軽減できます。また、denial-of-wallet攻撃や、意図しないエージェントループも抑制できます。

アラートだけでは、この要件を満たせません。プロバイダーには、プロジェクト、キー、モデル、時間枠など、有用な粒度でのハードリミットが必要です。顧客は、別途請求管理システムを構築せずに、それらを設定できるべきです。

厳格なロックが標準になれば、防げたはずの損失を巡る主張は弱まるでしょう。リレー事業者は依然として無料アカウントや盗まれた認証情報を悪用できるかもしれませんが、各アカウントから利用できる容量は減少します。プールを維持するには、より多くの在庫と大きな運用負荷が必要になります。

2つ目のシグナルは、アプリケーション層エンドポイントに対する攻撃の増加です。プロバイダーは、直接アカウントを巡る本人確認、決済、行動分析の管理を強化しています。攻撃者は、サポートボット、モバイルバックエンド、公開AI機能が依然として狙いやすい標的かどうかを試すでしょう。

研究者は、開示情報、ハニーポット、認証情報のテレメトリー、不正利用レポートを通じて、この変化を測定できます。アプリケーション企業も、無関係なプロンプト、異常な同時実行数、継続的なトラフィック、登録直後に到着するリクエストなどを観測する可能性があります。

明確な増加が見られれば、Lenhardの移行に関する警告を裏付けることになります。特にプロバイダーが不正アカウントの減少も報告する場合、アプリケーション不正利用が横ばいまたは減少すれば、その警告は弱まるでしょう。多くの被害者が損失の公表を避けるため、公開データは引き続き不完全なままです。

3つ目のシグナルは、購入者が検証可能なルーティングと認可を求めるかどうかです。現在、リレーディレクトリはアクセス性と信頼性を中心に激しく競争しています。エンタープライズ顧客が、署名済みのプロバイダー関係、モデルの証明、監査可能なデータポリシーを求めるようになれば、市場は変わる可能性があります。

モデルの出所を示すツールは、すべての秘密認証情報を公開する必要はありません。署名済みのルーティング記録、安定したモデル識別子、または顧客が確認できる監査証跡を提供できます。独立した評価により、事業者が公表したルーティングポリシーに従っていることを検証することも可能です。

こうした慣行が広がれば、正当なアグリゲーターと不透明なリレーを区別しやすくなります。購入者が出所の確認なしにエンドポイントを選び続けるなら、低摩擦の再販事業者は情報面での優位性を維持するでしょう。

開発者は、これらの市場シグナルが明確になる前に行動すべきです。サポートツールやモバイルバックエンドを含め、すべての公開LLMエンドポイントを見直してください。プロバイダーが許す限り、厳格な同時実行制限と独立した支出管理を適用してください。

エンタープライズの購入者は、各AIリクエストの経路をユーザーインターフェースから最終的なモデルプロバイダーまで追跡すべきです。ある仲介事業者が自らの役割を説明できない場合、その不確実性をセキュリティ上の発見事項として扱ってください。

Simon Willisonの警告は、遠いグレーマーケットの物語を、直接的なエンジニアリング上の問いへと変えます。自社アプリケーションは、認証情報、プロンプト、予算が誰かの在庫になる前に、不正利用を止められるでしょうか？