「ITニュース」｜Anthropic — 自社コードをLLMで守る手順書が公開された
はじめに
2026年5月27日、Anthropic は Claude 公式ブログで Using LLMs to secure source code を公開しました。大規模言語モデル（LLM）を使って自社のソースコードを守るための実務ガイドです。
公式が強調している核心は、脆弱性の「発見（discovery）」は並列化しやすくなった一方、ボトルネックは「検証・トリアージ（仕分け）・パッチ」に移った、という整理です。これは 5月22日の Project Glasswing: An initial update（1万件超の検出 vs パッチ75件）と同じ論点を、開発者が自分のコードベースで再現できる手順として落とし込んだ記事、と読めます。
あわせて、Claude Code 向けの security-guidance プラグイン（全プラン無料、CLI 2.1.144 以降）の公式ドキュメントも整備されています。編集セッションのなかで、パターンマッチとモデルレビューの3層を回す仕組みです。
前提稿: 「ITニュース」｜Glasswing 1か月後 — 1万件見つけて75件パッチ（なぜ「見つける vs 直す」のギャップが話題になったか）
読みどころは次の3点です。
6段階の find-and-fix ループ——脅威モデルからパッチまで、Anthropic がパートナーと得た運用知を手順化した点
発見エージェントと検証エージェントを分ける——同一 AI に「探して自分で採点」させると見落としが増える、という公式の教訓
GitHub 参照実装 + Claude Code プラグイン——Mythos Preview を一般公開しない方針のなか、公開 Opus で防御側を動かす二層メッセージ
※本記事は Anthropic 公式・Claude Code ドキュメントをもとにした一般的な整理です。CVE 対応・パッチ判断・無許可の侵入テスト・投資・法務の助言ではありません。Anthropic への取材は行っていません。
この記事での用語
1. 何が起きたのか（結論）
先に結論です。
2026年5月27日、Anthropic が LLM によるソースコード防衛の方法論ブログを公開した
6段階ループ（脅威モデル → サンドボックス → 発見 → 検証 → トリアージ → パッチ）を説明し、各段階用の Skills とデモ harness を GitHub で公開した
ブログ執筆時点（5月22日）の Anthropic 自身の OSS スキャンでは、1,596件を開示、パッチ済み97件（知見ベース）——Glasswing 更新の 530 / 75 とは母集団が異なる
Claude Code security-guidance プラグインは、編集のたび・ターン終了時・Claude 経由の commit 時の3層レビュー（詳細は後述）
同日、エンタープライズ向けに Zero Trust for AI agents も公開——エージェント実行環境とコード防衛の両輪
忙しい方向けに一言でいうと、
「AI で脆弱性は大量に見つかる時代。次に詰まるのはスキャンではなく、検証と直すパイプライン」——Anthropic が手順書として示した、というニュースです。
2. なぜ今か — Glasswing から5日後の「実装編」
時系列を短く並べます。
5月22日の更新では、skills・harness・脅威モデル builder を資格を満たす顧客へ要請ベースで提供すると書かれていました。5月27日のブログは、参照実装を GitHub で公開し、Mythos なし（公開 Claude Opus） でも同型のパイプラインを試せる位置づけです。
公式の言い方をそのまま要約すると、「discovery は straightforward to parallelize（並列化しやすい）」、「the bottleneck has shifted to verification, triage, and patching（ボトルネックは検証・トリアージ・パッチに移った）」 です。
3. 6段階 find-and-fix ループ（公式の骨格）
Anthropic がパートナー・顧客と得た知見を、次の6段階に整理しています。
3-1. 脅威モデル（Threat model）
何を脆弱性とみなすかを、スキャンの前に決めます。モデルが「クライアント入力を信頼できない」と誤解すると偽陽性が増え、逆に「内部専用」と誤解すると見逃しが増えます。
公式の推奨:
アーキテクチャ文書、過去の CVE、git 履歴から下書きを bootstrap
システムを知る人へのインタビュー（Shostack の4問など）で補完
リポジトリに `THREAT_MODEL.md` を置き、発見・トリアージの両方で参照
Skill: `threat-model`（bootstrap + interview）
3-2. サンドボックス（Sandbox）
2つの目的があります。
エージェントを隔離——本番 credentials（`~/.aws`、`.env` 等）をエージェントから切り離す
PoC で悪用可能性を証明——静的解析だけでは「コード上は怪しいが本番では無害」が残りやすい
gVisor / Firecracker 等、本番相当の依存関係を pin した環境が推奨されています。サンドボックス構築が難しい場合は、発見から始め、検証に人手時間を多めに見積もる、と公式は書いています。
3-3. 発見（Discovery）
並列エージェントで探索します。意外な公式の教訓は、長いチェックリスト型プロンプトは discovery を悪化させる、という点です。ゴールと文脈を渡し、「どう探すか」はモデルに任せる方が、新しいバグを見つけやすい、と説明されています。
コードベースを攻撃面・コンポーネントなどで分割し、並列化
可能なら PoC を添付（再現できなくても「未証明」として報告は残す）
Skill: `vuln-scan`
3-4. 検証（Verification）
発見エージェントとは別の verifier が、共有履歴なしの新しいコンテナで動きます。discovery と verification を同一エージェントに任せると、本当の脆弱性を自分で除外してしまう（self-censor）——Anthropic はこれを「hard way」で学んだ、と書いています。
verifier には PoC または finding + コードベースだけ渡す
「偽陽性だと仮定して反証せよ」 とプロンプトする
複数 verifier の多数決も有効、とパートナー事例が引用されています
3-5. トリアージ（Triage）
検証を通過した候補を、根本原因で dedupし、reachability（到達可能性）・認証・前提条件・影響範囲で severity を付け直します。
公式の警告: 重複や過大評価の報告を送りすぎると、開発者が報告を読まなくなる。OSS メンテナは低品質 AI 報告の洪水で既に逼迫している、というのが Glasswing 更新の文脈です。
Skill: `triage`（検証 + トリアージを兼ねる）
3-6. パッチ（Patching）
テストを先に書き（TDD 的）、修正し、PoC が効かなくなることを確認、敵対的再スキャンで抜け穴を探します。パッチは人間が最終責任——生成パッチは「症状だけ直す」「正当な通信を遮る」などの失敗パターンがある、と公式は事例を挙げています。
Skill: `patch`
4. 公開アセット — GitHub と PR レビュー
ブログ末尾で案内されている主なリソースです。
読み分け: 本ブログの harness は自前運用の参照実装、Claude Security はマネージド製品、Mythos Preview は限定提供——3つは別物です。
関連記事: 「ITニュース」｜Claude Security 公開ベータ — 防御AIがコードレビューに入る日（Enterprise 製品線の整理）
5. Claude Code security-guidance プラグイン（編集セッション内の3層）
公式ドキュメント に沿った要点です。ブログ本体とは別ページですが、5月27日前後に整備された、開発者向けの近接防御です。
前提: Claude Code CLI 2.1.144+、Python 3.8+、git リポジトリ。
重要な制約（公式）:
書き込みも commit もブロックしない——所見は同一セッション内で Claude に修正させる
Claude が書いた変更が主対象。手元シェルからの commit は 3 層目の対象外
Windows では venv 自動構築がスキップされ、agentic commit review は Claude Agent SDK が既に import 可能な場合のみ（それ以外はフォールバック）
拡張: プロジェクトに `.claude/claude-security-guidance.md`（脅威モデル・チェックリスト）や `.claude/security-patterns.yaml`（カスタムパターン）を置ける。
多層防御の位置づけ（公式）:
プラグインは完全なセキュリティ保証ではない——公式も defense in depth（多層防御）の一層と明記しています。
6. 混同しやすい点
7. 誰に何が効くか（実務メモ）
8. これからどうなりうか（観察の整理）
時間軸: 短期＝0〜3か月、中期＝3か月〜1年、長期＝1年以上（目安）。
8-1. 短期（0〜3か月）
予想される動き — Claude Code ユーザーで security-guidance の試験導入増。AppSec コミュニティで 「verifier 分離」「triage dedup」 が引用されやすい。Glasswing の 1万件 vs 75パッチ とセットで、社内 SecOps に 「AI スキャン導入＝リスク低減ではない」 議論が起きやすい。
不確実性 — プラグイン 2・3 層は usage 課金。コストが見えにくいと無効化される可能性。Windows では agentic 層が弱い。
効果が出ない条件 — threat model 未整備のまま discovery だけ増やす。triage リソースを増やさない。
8-2. 中期（3か月〜1年）
予想される動き — PR Action + セッションプラグイン + 定期 harness の3段スタックが、Anthropic 利用企業の参考構成になりうる。Claude Security と OSS harness のマネージド vs 自前が調達の軸に。
不確実性 — OSS パッチは ボランティア maintainer 依存。Enterprise 内（Glasswing: Claude Security 3週間で2,100超パッチ）との速度差は構造的。
効果が出ない条件 — AI 生成パッチを人間レビューなしで適用し続ける（過剰制限で依存サービス断、など公式事例）。
8-3. 長期（1年以上）
予想される動き — Mythos 級の一般公開（Glasswing: safeguards 強化後）で discovery が再跳躍——verification / triage / patching の産業インフラがないと 「発見→悪用」ウィンドウが問題化、という Glasswing narrative の検証。`THREAT_MODEL.md` が AI スキャン時代の標準ドキュメントになりうる。
不確実性 — AI 生成パッチの責任分界、低品質 CVE 報告への maintainer 反発、規制・地政学。
効果が出ない条件 — 業界がパッチサイクル短縮・更新強制に投資しない——discovery だけが安くなる 「脆弱性ストック増加」 均衡。
9. まず何を確認するか（行動ベース）
負担の小さい順の例です。
Using LLMs to secure source code で 6段階ループと discovery / verification 分離の原文を読む
defending-code-reference-harness で `/quickstart` のデモを試す（自社コード投入は threat model から）
Claude Code 利用者なら security-guidance ドキュメント で3層の限界（ブロックしない・手元 commit 対象外）を確認
数字の文脈が必要なら、5/22 Glasswing 更新 に戻る
まとめ
2026年5月27日の Anthropic ブログは、Glasswing が示した 「見つけるは速い、直すが遅い」 課題を、6段階 find-and-fix ループとして開発者向けに手順化した記事です。
発見と検証は別エージェント——同一 AI に兼務させない
スキャン予算より検証・triage・パッチの予算——公式が繰り返し強調
GitHub 参照実装 + security-guidance プラグイン——Mythos 一般公開を見送るなか、公開 Opus で防御側を動かす二層
「AI 脆弱性スキャンを入れた」で終わらせず、脅威モデル・検証・仕分け・人間のパッチ責任までセットで設計する——それが本稿の整理です。
主な参照
Anthropic — Using LLMs to secure source code（2026-05-27・本件の中核）
Claude Code Docs — Catch security issues as Claude writes code
Anthropic — Project Glasswing: An initial update（2026-05-22）
Anthropic — Zero Trust for AI agents（2026-05-27・同日関連）
免責
本記事は一般向けの情報整理であり、特定の製品導入、CVE 対応方針、無許可の侵入テスト、投資、訴訟対応、契約条項の解釈を推奨するものではありません。脆弱性探索は Cyber Verification Program 等の公式枠と自社ポリシーに従ってください。必要に応じて専門家に相談してください。
【PR】
私も転職エージェントを利用して転職しました。
