「Codex と Fable が拒否した15件を Kimi K3 が修正」と開発者が報告──Sacksが突く『安全ガードレール対競争力』と、防御側だけ止まる過剰拒否
何が起きたのか ホワイトハウスのAI政策に関与するDavid Sacks氏が、中国製モデルKimi K3を引き合いに米国製AIの安全ガードレールを公然と批判しました。Sacks氏はX(旧Twitter)で「Kimi K3は、Codex と Fable が『cyber guardrails』を理由に拒否した15件のクリティカルなセキュリティバグを、たった今修正した。中国モデルが問題なくこなすタスクで米国モデルを制限する理由はない。我々は自らを競争力の低い存在にしているだけだ」と投稿しています(David Sacks氏 X投稿)。 Sacks氏は大統領科学技術諮問委員会(PCAST)の共同議長を務める人物で、この発言は一開発者の報告を発端に、AIの安全設計が米国の競争力を損なっているのではないかという政策論に火を付けました(thenews.com.pk 2026-07-20)。日常的にCodexやClaude系モデルでコーディングする開発者にとって、これは政策論であると同時に、「安全側に倒しすぎたモデルが実務で使い物にならない」という現場の問題そのものです。 発端は一人の開発者の報告 Sacks氏の投稿の発端は、公式なベンチマークではなく、ビットコイン関連の開発者calle氏による実体験の報告でした。報道によると、calle氏は自身のソフトウェアに存在する15件のセキュリティバグの修正を、OpenAIのCodexとAnthropicのFable 5に依頼したところ、いずれも安全ルールを理由に対応を拒否したといいます。一方、Moonshot AIのオープンウェイトモデルKimi K3は、同じ15件をすべて修正したと報じられています(Startup Fortune 2026-07)。 ここで拒否側に挙がった「Codex」「Fable」はいずれも米国製で、Fable 5はAnthropicのモデルです。拒否の理由として引用された「cyber guardrails(サイバー領域のガードレール)」とは、悪用可能なコードやエクスプロイトの生成を防ぐために各社が組み込んでいる安全制御を指します。皮肉なのは、calle氏の依頼が攻撃コードの作成ではなく、自分のソフトの脆弱性を塞ぐ防御的な作業だった点です。Anthropic自身、強化した安全分類器が「日常的なコーディングやデバッグで良性の要求をより頻繁にフラグする(flagging benign requests more often)」と公式に認めており、防御側の作業まで巻き込むのは各社が織り込むトレードオフになっています(Anthropic公式)。 なお、この15件という数字は個人の主張であって、統制された評価に基づくものではありません(thenews.com.pk 2026-07-20)。Sacks氏はこの事例を、米国の安全規制が競争上の重荷になっている証拠として引用した、という関係です。 Sacksの主張と、その立場 Sacks氏の論旨は明快です。もし米国モデルがルーティンの防御作業まで過剰に拒否するなら、それはエンタープライズ顧客が本当に必要とする意味での「安全」ではなく、単に使いにくいだけだ、というものです。ここに価格差が加わると、企業の調達判断はさらに米国勢に不利になります。The Newsは、Artificial AnalysisがあるベンチマークタスクのコストをKimi K3で0.95ドル、主要な米国モデルで1.04ドルと見積もったと伝えています(thenews.com.pk 2026-07-20)。 ただし、事実と評価は分けて読む必要があります。Sacks氏は中立的な観察者ではなく、ホワイトハウスのAI・暗号資産担当からPCAST共同議長へと移った人物で、いま批判している政策環境そのものに関与してきた立場でもあります(Startup Fortune 2026-07)。同じKimi K3の登場を受けて、トランプ政権がサイバーセキュリティ上の懸念を理由に中国製AIモデルの規制強化を再検討していると報じられており、政権内でも「開放して競争力を取るか、締めて安全を取るか」で立場が割れていることがうかがえます(Tom’s Hardware 2026-07)。 同じ週に起きた Hugging Face の事例 この論争が単発の逸話ではないことを示すのが、ほぼ同じタイミングで報じられたHugging Faceの事例です。Hugging Faceは公式のインシデント報告で、自律型のAIサイバー攻撃を受けた際、ログ解析にまず商用APIのフロンティアモデルを使ったものの「大量の実際の攻撃コマンド、エクスプロイトのペイロード、C2アーティファクトを送信する必要があり、これらの要求はプロバイダの安全ガードレールにブロックされた(ガードレールはインシデント対応者と攻撃者を区別できない)」と説明し、最終的に中国製オープンウェイトのZ.ai GLM 5.2を自社インフラ上で動かして解析したと明かしています(Hugging Face 2026-07、Fortune 2026-07-20)。 VentureBeatは、ここで止まったのが攻撃者ではなく防御側だったと指摘しています。攻撃の分析には、実際の攻撃コマンド、エクスプロイトのペイロード、C2(指令サーバ)由来のアーティファクトを大量にモデルへ投入する必要がありますが、商用フロンティアモデルのガードレールは「攻撃者がエクスプロイトを作らせている」のか「防御者が検知のために解析している」のかを区別できず、後者まで一律にブロックしてしまったというわけです(VentureBeat 2026-07)。calle氏の脆弱性修正と構図はまったく同じで、悪意ある側ではなく守る側の作業が安全制御に阻まれています。 「防御側だけが止まる」という構造 — over-refusal この現象は研究の世界では過剰拒否(over-refusal、良性の要求まで拒否してしまう挙動)として知られており、逸話にとどまらない定量的な裏付けがあります。Scale AIらがICLR 2026ワークショップで発表した「Defensive Refusal Bias」は、全米大学サイバー防衛競技会(NCCDC)由来の2,390件のプロンプトを用いて、安全アラインメントが防御タスクをどれだけ止めるかを測りました(arXiv 2603.01246 2026-03-01)。 同論文の全体拒否率は12.2%でしたが、内訳を見ると偏りが際立ちます。攻撃的な用語を含むプロンプトの拒否率は30.5%、含まないものは11.2%で、その比は $\frac{30.5}{11.2} \approx 2.72$ 倍でした。タスク別ではシステムハードニングが43.8%、マルウェア解析が34.3%と、防御の中核ほど拒否されやすいという逆転が起きています。過剰拒否の度合いは、良性要求のうち誤って拒否された割合、すなわち偽拒否率(false refusal rate)として次のように捉えられます。 ...