Irregularの評価環境から実在対象へ到達した経緯を最初に確認します。続いて、UpGuardが報告したSupabase上の個人データ公開と、Anthropicの供給網リスク指定に関する米控訴審の判断を追います。実装面では、Turnstile Spinの導入手順とGemini RLFTの報酬設計・停止判断を取り上げます。
評価時の外部接続、公開データの範囲、調達上の適用範囲をそれぞれ分けて読みます。Turnstile SpinとGemini RLFTは、導入時の承認と学習時の評価という別の運用判断として扱います。（出典1 / 出典2 / 出典3 / 出典4 / 出典5）
IrregularのAI評価、設定不備で実在対象へ
The Vergeは9月25日、すでに公表されていた複数社のAI評価事案に共通するIrregularの役割を報じた。同社が管理環境でAIエージェントのサイバー能力を評価していた際、一部のエージェントが実在する対象へ向かった。評価には、模擬ネットワーク内の隠された情報を探すキャプチャー・ザ・フラッグ形式も含まれていた。（出典1 / 出典2）
Irregular共同創業者兼CTOのオマー・ネヴォは、単一の評価シナリオでインターネット接続が意図せず有効になり、評価用の架空企業名が実在ドメインと重なったため、エージェントが実在対象へ向かったと説明した。同社は8月の報告でも、同じ評価シナリオに起因する問題だったと記している。（出典1 / 出典2）
ネヴォによると、同じ問題がOpenAI、Meta、Anthropic、Googleのモデルに関する事案の原因だった。一方、Hugging Faceへの攻撃と英国AI Security Instituteの事案は、Irregularの評価とは無関係だとしている。（出典1）
事案後、Irregularはインターネット接続制御、監視、手動レビュー、評価開始前のアクセス範囲確認を強化した。提携先と評価設定や条件を文書化し、合意する方法も改善したという。（出典1）
EastBraverの見立て: 本件はモデル固有の問題として読むより、評価環境の接続範囲と対象名の衝突が、複数社のモデルを同じ誤経路へ導いた運用上の失敗として捉えるべきである。（出典1）
UpGuard、Supabase上の約16,000件で個人データ公開と報告
UpGuardはTechCrunchに対し、Supabaseでホストされた約16,000件のデータベースで、何らかの個人データが公開されていたと説明した。公開状態で確認された情報には氏名、住所、電話番号、利用者のパスワードが含まれ、パスワードと認証トークンは比較的少数だったという。（出典1）
TechCrunchは一般的な発生要因として、基本的な設定ミスや不適切なセキュリティを挙げた。AIツールが生成したコードに脆弱性が含まれる場合や、必要な設定を開発者が把握していない場合があるとの説明であり、今回の各データベースについて原因となった設定を特定したものではない。（出典1）
SupabaseのCISOは、UpGuardの調査内容をまだ確認していないとしたうえで、プロジェクトは「安全な初期設定」であり、セキュリティは同社と顧客の「共同責任」だと説明した。顧客が各プロジェクトの設定を管理し、Supabaseはセキュリティ上の問題を発見した場合に影響を受ける顧客へ通知するという。（出典1）
EastBraverの見立て: 「安全な初期設定」は、顧客が変更した後の構成まで安全だという意味ではない。「共同責任」の境界上では、生成コードの確認とプロジェクト設定の管理を一体の運用課題として扱う必要がある。（出典1）
- 出典: TechCrunch（二次報道、2026-09-26 02:29 JST）
Anthropicの供給網リスク指定、米控訴審が異議を退ける
米ワシントンD.C.の連邦控訴裁判所は9月25日、国防総省によるAnthropicの供給網からの排除について、同社の異議を2対1で退けた。対象は、連邦調達供給網安全保障法に基づく同省の調達措置である。別の法的手続きで下されたカリフォルニア連邦地裁の判断まで覆したものではない。（出典1 / 出典2）
多数意見は、同省またはその請負業者がClaudeを同省の情報システムに組み込み続けることを、法令上の国家安全保障リスクとして扱う根拠があると判断した。Anthropicの適正手続きと表現の自由に関する主張も退け、排除はAI規制を支持する発言ではなく、同省が必要とした契約条件への同意拒否に基づくと述べた。（出典1）
EastBraverの見立て: 調達先の評価では、モデルの利用条件と契約上の許容範囲が運用継続に直結する。今回の判断は国防総省の調達措置に関するもので、他の利用者への影響は契約と適用法令を分けて確認する必要がある。（出典1）
- 出典: 米連邦控訴裁判所の判決文（一次資料、2026-09-25） / Wiredの報道（二次報道、2026-09-26 01:58 JST）
Turnstile Spin、承認後にフロントとバックを一括変更
Cloudflareは9月25日の記事で、Turnstileのウィジェット作成、サイトへの組み込み、バックエンドへのSiteverify導入を既存のコーディングエージェントが担う「Turnstile Spin」の手順を説明した。同記事によると、ダッシュボードでは7月から利用されており、今回が初めての提供開始ではない。（出典1）
利用者が保護対象を選ぶと、エージェントが該当するフロントエンドとバックエンドのコードを探索し、変更計画を提示する。利用者の承認を待ってから、両側の変更を実施する。（出典1）
アプリケーションコードをCloudflareへ送信したり、Cloudflareが遠隔変更したりする方式ではない。Claude Code、Cursor、Codexなど、利用者が既に使うエージェントがコードベース内で承認済みの変更を行う。Cloudflareアカウントに加わる新規リソースはTurnstileウィジェットだけで、検証処理はアプリケーションのバックエンドに残る。（出典1）
対象は、新規導入、Siteverifyによるサーバー側検証が確認されない既存ウィジェットの修復、他のCAPTCHAからの移行という3種類である。（出典1）
比較表: 手作業による導入とTurnstile Spinの違い
二段階の統合作業をエージェントがまとめて扱う一方、変更主体と検証処理は利用者側に残る。（出典1）
| 観点 | 手作業による導入 | Turnstile Spin |
|---|---|---|
| 統合手順 | ウィジェットの組み込みとSiteverifyの導入を手作業で行う。（出典1） | エージェントが両側を一つのワークフローで変更する。（出典1） |
| 変更の進め方 | フロントエンドとバックエンドを個別に設定する。（出典1） | 対象コードを探索して計画を示し、利用者の承認後に変更する。（出典1） |
| コードの変更主体 | 利用者が手作業でコードを変更する。（出典1） | 利用者が既に使うコーディングエージェントがコードベース内で変更する。（出典1） |
EastBraverの見立て: 導入判断では、Cloudflareへのコード送信よりも、既存エージェントが承認後にフロントエンドとバックエンドを同時変更する実行境界を評価軸に置くべきだ。（出典1）
- 出典: Cloudflare（公式情報、2026-09-25 22:00 JST）
Gemini RLFT、データ・報酬・停止条件の実践指針
Google Cloudは、Geminiを強化学習でカスタマイズする実践ガイドを公開した。マネージドRLファインチューニングサービスでは、利用者がプロンプトと報酬関数を用意し、サービスが候補応答の生成、採点、モデル更新を担う。固定した正解例ではなく、利用者が定義した報酬信号に沿ってモデルを適応させる仕組みだ。（出典1）
Google Cloudは、まずプロンプト調整と教師ありファインチューニング（SFT）を試し、応答は採点できても正解例を安価に作れない場合、重要指標でSFTが頭打ちになった場合、または有効な回答が多数ある場合にRLFTを勧めている。基盤モデルが時折成功するなら直接RLFTを使い、成功率が低い場合やSFT用データがある場合は、軽いSFTから継続チューニングでRLFTへ進む。（出典1）
初回のデータは、多様なプロンプトとホールドアウト検証分割で始め、学習と評価を厳密に分離する。報酬関数は、人間の選好との相関、不正な形式に対する明確な負の点、報酬ハッキングへの耐性を備え、開始前にオフラインで検証することが推奨されている。対策には、複数判定器の併用、長さへのペナルティ、退化出力の下限処理、モデルの意見より検証可能な判定を優先することが含まれる。（出典1）
学習では既定設定から始め、報酬曲線と評価曲線を監視し、最終ステップではなく検証報酬が飽和した時点のチェックポイントを選ぶ。RLFTが安定させられるのはモデルがすでに時折示す能力であり、一度も示さない技能を新たに教える手段ではない。（出典1）
比較表: 基盤モデルの成功状況による開始方法
基盤モデルが時折成功するかどうかで、直接RLFTを始めるか、軽いSFTを挟むかが分かれる。（出典1）
| 観点 | 直接RLFT | SFTからRLFT |
|---|---|---|
| 開始条件 | 基盤モデルが時折成功し、報酬で良否を判別できる。（出典1） | 基盤モデルの成功率が低い、またはSFT用データがある。（出典1） |
| 進め方 | 基盤モデルから直接RLFTを開始する。（出典1） | SFTを軽いウォームスタートとして実施し、そのチェックポイントから継続チューニングでRLFTへ進む。（出典1） |
EastBraverの見立て: RLFTの採用判断では、正解例の作りにくさだけでなく、応答を信頼できる報酬で採点できるか、基盤モデルに部分的な成功があるかを入口条件として扱うべきだ。（出典1）
- 出典: Google Cloud（公式情報、2026-09-26 01:00 JST）
