リリースされたばかりの最上位モデル「Claude Fable 5」を使って、AIでほぼフル実装した自前の OSS コードのセキュリティチェックをやってみた。結論から言うと——セキュリティチェックのリクエストは Fable 5 では処理されず、自動的に Opus 4.8 に“モデルダウン”されて返ってきた。本記事では、その一部始終と、最終的に Opus 4.8 が出したチェック結果の要約を、公開できる範囲で一般化して共有する。
背景：Sonnet 4.6 + Opus 4.7 でフル実装したコード
今回のチェック対象は、Claude Sonnet 4.6 と Claude Opus 4.7 を使ってほぼフルに実装した OSS のコードベース。プラグイン（拡張モジュール）を配布・インストールできるタイプの Web アプリ構成で、規模感は後述の通り。
「AI でフル実装したコードは、別の上位モデルにセキュリティ監査させたらどう評価されるのか」——これを確かめたかった、というのが今回の動機だ。
日本から Fable 5 に「セキュリティチェック」を依頼してみた
Fable 5 がアナウンスされたのは米国時間 2026 年 6 月 9 日。ただし提供は国・地域や対象ユーザーによって扱いが分かれており、日本から実際に利用できるようになったのは、このアナウンスより後のことだった。本記事の検証は、日本から利用できた期間にあたる 2026 年 6 月 11 日ごろに行っている。
手順はシンプルで、対象コードを読み込ませ、「脆弱性の有無と状況を報告してほしい」と依頼しただけだ。
ところが返ってきた挙動は予想外だった。
- 応答に「理由」へのリンクが表示された
- そして肝心のリクエストは Fable 5 ではなく Opus 4.8 にモデルダウンされて処理された
なぜダウンされたのか
最初は理由がよく分からなかったが、これは仕様だった。
Fable 5 には、サイバーセキュリティや生物・化学といった高リスク領域、さらにモデルの“蒸留”を検知するセーフガードが組み込まれており、該当すると判定された場合は Fable 5 ではなく Opus 4.8 が代わりに応答する設計になっている。今回は「セキュリティチェック」という依頼自体がサイバーセキュリティ関連と判定され、自動的に Opus 4.8 へ引き継がれた、というわけだ。
公式も「安全で通常のコンテンツでもフラグが立つことがある」「現在、精度の改善に取り組んでいる」と注記している。つまり、現状では “セキュリティチェックは Fable 5 の担当外” と捉えるのが実態に近い。
現状の注記（2026/06/13 時点）：Anthropic は米国政府の輸出管理指令を受け、6 月 12 日（米国時間）に Fable 5 / Mythos 5 への全ユーザーのアクセスを停止した。この指令は外国籍ユーザー（米国の内外を問わない）を対象としており、日本のユーザーは現在 Fable 5 を利用できない状態にある（Anthropic は復旧に取り組むとしている）。検証を試みる場合は、最新の提供状況を必ず確認してほしい。（参考報道：ITmedia NEWS／Impress Watch）
開発自体は Opus 4.8 → Fable 5 に切り替えて継続
セキュリティ系の依頼はダウンされる一方で、通常の OSS 開発作業は Fable 5 で問題なく進められた。そこで、これまで Opus 4.8 で進めていた開発を Fable 5 に切り替えて作業を継続した。
その結果と、切り替えにあたって出てきた課題は、別記事に詳しくまとめている。
Opus 4.8 によるセキュリティチェック結果（要約・一般化）
ここからは、結局 Opus 4.8 が実施したセキュリティチェックの結果を、公開できる範囲で一般化して共有する。具体的な内部名・攻撃手順には踏み込まず、指摘の「分類」と「深刻度」のレベルで整理した。
対象コードの規模
| 項目 | 規模 |
|---|---|
| ファイル数 | 約 30 ファイル |
| コード総量 | 約 210 KB |
| 実装言語 | Python 中心（約 4,000 行） |
| レビュー方式 | 静的レビュー（ソースコード精読） |
深刻度別の指摘件数
| 深刻度 | 件数 |
|---|---|
 Critical | 0 |
 High | 1 |
 Medium | 6 |
 Low | 6 |
 Info | 4 |
| 合計 | 17 |
無条件のリモートコード実行のような致命的な欠陥は検出されず、全体としては 「セキュリティを意識した堅実な実装」 という評価だった。ただし多層防御（defense in depth）の観点では、計 17 件の改善余地が挙がった。
主な指摘（カテゴリ別・一般化）
| 分類 | 深刻度 | 概要（一般化） |
|---|---|---|
| 認証・認可の外部依存 | High | 本体側に独自の認証機構がなく、強い副作用を持つ API（インストール／アップロード／設定保存など）の保護を、上位の Web サーバ側の認証に全面的に依存している |
| CSRF 対策・トークン検証 | Medium | 状態を変更する API に Origin / Referer チェックやトークン検証がない。また URL パラメータ由来の値が検証されないまま画面に反映され得る |
| 外部リソース取得（SSRF） | Medium | インストール処理が、指定された URL へ制限なくアクセスし得る |
| アーカイブ展開時のパス検証 | Medium | 配布パッケージを展開する前のパス検証が不十分（いわゆる Zip Slip） |
| 画面描画時のエスケープ（XSS） | Medium | 外部由来の文字列を、エスケープせずに DOM へ挿入し得る箇所がある |
| その他 | Low / Info | ログ出力・エラー処理・依存関係などに関する軽微な改善提案 |
評価できた点
監査では、以下のような「すでに適切に対策できている点」も明確に挙げられた。
- 待ち受けをループバックアドレスに限定している
- プラグイン名を許可リスト（allowlist）方式で検証している
- 配布インデックスのスキーマを検証している
- パス・トラバーサル対策が入っている
- セキュリティ関連ヘッダを一律で付与している
- 設定ファイルをアトミックに書き込んでいる
対応方針
報告書には、優先度（P1〜P3）付きの改善ロードマップも併記した。要点は次の 3 つに集約される。
- 本体側にも、最低限の認証・CSRF 対策を持たせる
- 外部リソースの取得とアーカイブ展開に、検証処理を入れる
- 画面描画は一律でエスケープする
なお、実効的なリスクは 上位の Web サーバ側の認証構成（本コードの外側） に大きく左右される。そのため、最終的な安全性の評価は、その構成とあわせて確認する必要がある——この点は報告書にも免責として明記している。
補足：今回のチェックは「静的レビュー」である点に注意
ここは結果を読むうえで重要なので補足しておきたい。
今回 Opus 4.8 が行ったのは、ソースコードを読んで解析する 静的レビューだ。報告書自身も方式を「静的レビュー（ソースコード精読）」と明記している。実際にアプリを起動して通信を流す、いわゆる 動的テスト（実行時の検証）は行っていない。
これは Anthropic 自身が提供する専用機能の位置づけとも一致する。同社の「Claude Code Security」も、コードを読んで文脈やデータフローを追う 静的解析として位置づけられており、アプリを実行して挙動を確かめる ランタイム（動的）ツールではないとされている。手法としては、従来のルールベース（パターンマッチ）型 SAST とは異なり、文脈やロジックを追う「エージェント的なコード推論」に近い。逆に、実行時にしか現れない種類の不具合は、そもそも対象外になる。
そのうえで、結果を読むときに押さえておきたい点が 2 つある。
1. 「過剰検知」が起きやすい
ルールベースの従来型ツールと違い、AI によるレビューは実行のたびに解析内容が変わる 確率的（ストキャスティック）なものだ。文脈を踏まえて深い指摘ができる反面、毎回同じ結果になるとは限らず、影響の小さい指摘や誤検知（false positive）が混ざりやすい。Anthropic の専用ツールでも、ノイズを減らすための誤検知フィルタや、最終判断を人に委ねる運用（human-in-the-loop）が前提になっている。今回のような「チャットにコードを貼って読ませる」簡易な使い方では、そうしたフィルタは働かないため、各指摘は「確定した脆弱性」ではなく 要確認の候補として、1 件ずつ人手でトリアージする必要がある。
2. 見ているのは「渡したコードだけ」
今回のレビューは、読み込ませたソースの範囲しか見ていない。サーバ（Apache）側の設定や、実際の運用環境までは把握していない。報告書が「実効リスクは上位の Web サーバ側の認証構成（本コードの外側）に左右される」と免責しているのは、まさにこのためだ。一般的なコードチェックツールが想定する「システム全体を俯瞰した解析」とは前提が異なる点に注意したい。
要するに——本当に影響があるかどうかは、この静的レビュー結果だけでは確定できない。各指摘について、実際の構成・データフローを踏まえた人手の確認と、必要に応じた動的テストを重ねて初めて、実効リスクが判断できる。AI の静的レビューは「あたりを付ける」には非常に有用だが、最終確定には別の検証が要る、というのが実情だ。
やってみての所感
正直に言えば、手応えよりも 「Fable 5 で確認できなかった」失望のほうが大きい。最上位モデルでセキュリティ監査を、と期待したのに、現状はセーフガードで自動的に Opus 4.8 へ引き継がれてしまう。セキュリティチェックは Fable 5 の担当外、と割り切るしかなかった。
代わりに動いた Opus 4.8 の静的レビューについても、評価は手放しではない。
- 既存の静的チェックツールとの差は、正直よく分からない。 文脈を読む深さに見どころはあるが、「専用ツールを置き換えるほどの決定的な違い」を今回の範囲で実感できたわけではない。
- 専用の静的チェックツールを購入しなくても、ある程度のチェックができるのは確かにアリだ。ただし AI ゆえに「漏れなく・均一に」チェックできる保証がないのが微妙なところ。実行のたびに結果が揺れる確率的な仕組みである以上、ここは本質的な弱点になる。
- したがって、既存の静的チェックツールをやめて AI チェックに全面的に切り替えるのは、「漏れなく検出できるか」という一点で NG だと考える。網羅性・再現性が求められる場面では、まだ任せきれない。
一方で、可能性も感じた。もし AI が、ソース単体だけでなくシステム全体の構成まで含めて判定してくれるようになれば、既存の静的チェックツールと組み合わせて効率的な作業ができるかもしれない。そう考えると、AI が静的チェックツールを置き換えるのではなく、静的チェックツール側に AI が組み込まれていく未来のほうが、現実的で筋が良さそうだ。