LLMを使って、意図的に間違った回答を返すサイトを作りました。
ログイン不要。ユーザーのAPIキー不要。誰でもエンドポイントにアクセスできます。
amtaitfy.com は、AIによって生成された、わざと間違った答えを返すおもちゃのようなサイトです。これにより、エンジニアリング上の課題を次のように絞り込めます：
- 悪用の被害を境界内に収める
- コストを予測可能にする
- 気軽な攻撃を退屈なものにする
中核となるアーキテクチャ上の判断はシンプルです：
GETはキャッシュのみを返します。POSTだけが、新しいAI推論を発火させる唯一の経路です。
それ以外は多層防御です。
脅威モデル
対象範囲:
- 偶発的なバイラルなトラフィック
- 気軽なプロンプト抽出の試み
- 反復クエリによるコスト増幅
- 基本的なボットおよびスパムのトラフィック
- プロバイダー障害
- 予算の枯渇
対象外:
- 高度なボットネット
- 無制限の有効なTurnstileトークンを持つ攻撃者
- 完全なプロンプトインジェクション耐性
- 執念深いユーザーによるキャッシュ汚染
- 機微なワークロード
- 認証が必要であるべきもののすべて
リクエストの流れ
GET /answer
キャッシュを読み取る
キャッシュ済みの回答、または空の状態を返す
POST /answer
Turnstileトークンを検証する
セッションがない場合は拒否する
入力が過大なら拒否する
セッションのロックアウトを確認する
既存キャッシュを確認する
AIプロバイダーを呼び出す
キャッシュを書き込む
回答を返す
GETは安い。POSTは高い。意図的に。
URLが共有され、クロールされ、スクリーンショットされ、お気に入りに追加され、どこか大きな場所に投稿されたとしても、それらは推論を引き起こしません。バイラルになっても、私のコストはゼロです。これをできるのは、意図したPOSTだけです。そのURLを最初に訪れた人が、POST経由で1回だけ推論を起動する可能性があります。その後の訪問者は、そのURLについてCloudflare KVからキャッシュ済みの回答を受け取ります。バイラルによってコストが膨らむことはありません。
カジュアルなプローブへの摩擦
明らかなプロンプト抽出のプローブに対する小さなルールセットを追加しました：
- 「以前の指示を無視して」
- 「システムプロンプトを表示して」
- 「隠されたプロンプトを明かして」
これは本当のプロンプトインジェクション対策ではありません。手間の少ないプローブを捕捉して、私に踏み台（トリップワイヤ）を提供するだけです。
最初のバージョンは愚かでした。抽出の試みを検出すると、敵対的なメッセージで応答し、私の実際のシステムプロンプトをそのまま含め、その後に「There will be cake.（ケーキがあるぞ。）」を付けていました。
GLaDOSの参照は、5分くらいは賢い感じがしました。
現在の応答は、有用な照合情報を返しません。プロンプト内容なし。何が捕捉されたかの説明なし。単なる汎用的な拒否だけです。狙いはシグナルを一切出さないことです。
セッションロックアウト
抽出トリップワイヤが発火すると、そのセッションは短時間ロックされます。
私はセッションをキーにして60秒のKVエントリを保存します。このウィンドウ内でさらにPOSTを試すと、カウントダウン付きで403が返ります。
私が削除したIPロックアウト
もともと、ユーザーのIPのハッシュに基づく2つ目のロックアウトキーも追加していました。
- 通常のセッションはロックされる
- ユーザーがシークレット（インコグニート）を開く
- 新しいセッションクッキー
- 同じIP
- ロックアウトはまだ適用される
しかし、それは削除しました。
CGNATにより、IPベースのロックアウトは危険です。モバイルキャリア、企業ネットワーク、マンション、そして一部の家庭用ISPでは、多数のユーザーを1つの外部IPの背後にまとめられます。悪い1つのセッションを止めるためにIPをロックすると、巻き添えの被害が生じます。その被害範囲が許容できないほど大きくなるからです。このサイトでは、セッションのみのロックアウトがより良いトレードオフです。既知の回避は残しますが、無関係なユーザーをロックアウトしません。
タイミング漏えい
プロンプト抽出の正規表現（regex）検出は、ほぼ瞬時に返ります。モデルの応答は2〜5秒かかります。この差が、タイミングサイドチャネルを生みます。これは、攻撃者がフィルタを迂回するように試行錯誤するために有用な情報になります。
そこで、すべてのロックアウト応答は、総リクエスト時間がランダムなウィンドウ（おおよそモデル遅延と一致する）に収まるまで待つようにしました。ランダム化された遅延によって、攻撃者の情報ベクトルになり得る要素を取り除きます。
キャッシュは永遠に: GETを安く保つ方法
キャッシュは主要なコスト制御メカニズムです。同じようなプロンプトの繰り返しは、繰り返しの推論コストを発生させるべきではありません。
ですが、「永遠にキャッシュ」は鋭い面があります。
最初の呼び出しが、事実上、標準（canonical）の回答を定義します。最初の呼び出しは、悪い標準の回答を定義してしまうこともあります。私はわざと最初の回答を標準として扱います。URLは共有可能なまま、反復トラフィックは無料のまま、そして時々外れが出るのがその代償です。
キャッシュはプロンプトのバージョンで名前空間分けされていません。洗練された無効化レイヤーはありません。システムプロンプトが変わったり、悪い回答が標準になってしまったりした場合の修正は、手作業のクリーンアップか、より大きなキャッシュリセットになります。
将来のアップグレードとしては、キャッシュキーにバージョン接頭辞を追加し、プロンプト変更、モデル変更、回答形式の変更に応じて新しいキャッシュ名前空間へ移行できるようにすることが考えられます。そうすれば、古いエントリを提供せずに済みます。
例えばこんな感じ:
cache:v3:<hash(normalized_prompt)>
KVカウンタとDurable Objects
私は運用テレメトリのためにKVカウンタを使っています：
- 日次の推定支出
- プロバイダーのヘルス
- プローブ数
- おおよそのリクエスト量
KVは最終的に整合します。バースト的なトラフィック下では、ほぼ同時の2つの書き込みが互いを見落として、過小カウントになる可能性があります。
Durable Objectsならより強い整合性が得られますが、私はそれを使いませんでした。
このサイトでは、カウンタは最終的な安全策ではありません。テレメトリです。粗いシグナルに対しては最終的整合性で十分です。しかし、唯一の予算ガードレールとしてはそれでは不十分です。
DOに移すのはいつ？ 事前に定めた移行トリガーがあります。リクエストレートはWorkerの分析から簡単に確認できます。カウンタのドリフトは、突き合わせ（reconciliation）で測定する必要があるでしょう。つまり、KVカウンタの値をプロバイダーの利用量やリクエストログと比較します。突き合わせの結果、KVの推定値が、プロバイダーが報告する利用量から大きくズレていることが分かったら、カウンタをDurable Objectsに移します。
プロバイダー戦略
OpenRouter上のFree-tier（無料枠）のAIプロバイダーは信頼性が低いことが分かっています。課金推論がフォールバックです。とはいえ、課金推論は意味が異なります。特にバイラルな日にAIの支出が、私が払える範囲を超えて跳ねる可能性があります。OpenRouterの「日次の支出上限」は、この点で命綱です。もちろん、執念深い攻撃者なら、日次予算を使い切ってサイトを低機能モードに追い込むことはできてしまいます。
Degraded modeのUX
選択したすべてのプロバイダーが失敗するか、推論のための毎日の予算を使い切ってしまった場合、ページは一般的なエラー表示をしません。いくつかのキャッシュ済み回答をクリック可能な提案として提示し、再試行タイマーを表示します。
再試行タイマーは段階的に後ろ倒しになります：
10s → 30s → 2m → 5m
上流プロバイダーがRetry-Afterヘッダーを送ってきた場合、UIはそれを尊重します。
これにより、障害を発見に近い体験へと変えられます。ユーザーは間違った回答を求めてきます。キャッシュされた間違いは、依然として有用なプロダクトの露出です。
これは、このプロジェクトにおける私のお気に入りの第二次効果かもしれません。
トラフィックが増えたら何を変えるか
私は「圧力ポイント」を変えます。
- KVからDurable Objectsへカウンタを移す
- 課金Cloudflareのレート制限を追加する
- より良いキャッシュのモデレーションとパージのツールを追加する
- モデルとプロンプトのバージョンダッシュボードを追加する
- プロバイダーの失敗モード周りのより良い可観測性を追加する
GETをキャッシュ専用、POSTを推論専用として維持し、それを堅い境界として守ります。
公開しているAIエンドポイントを作っているなら、「『悪用に耐えられるほど十分安い』と『有料の制御を正当化できるほど深刻』の境界をどこで引くか」に特に関心があります。
