Claude SecurityにMythos 5｜脆弱性検出を検証案件へ変える
Claude SecurityにMythos 5が採用されたと聞き、脆弱性を見つける力をそのまま顧客へ提案できるのか、迷っていないでしょうか。公式発信で確認できる範囲と未確認の留保を分け、指摘を人が検証し、範囲定義・報告・再確認までを成果物として受け渡す方法をまとめました。小さく測って見積もりへつなげる考え方と、価格の根拠をモデル名だけに置かない整理も紹介します。
2026年8月21日の公式発信で、Claude SecurityのスキャンがClaude Mythos 5で動き、Claude Enterprise顧客向けの公開ベータとして提供されたことが示されました。コード保管庫を指定し、複数ファイルとコンポーネントの関係を追う点が今回確認できる変更です。
ただし、公式発信だけでは検出率、料金、個人向け提供の有無、すべてのコードを安全と判断できる保証までは分かりません。見つかった指摘は仮説を含む検証対象とし、対象範囲・根拠・誤検知・未確認部分を人が記録します。
仕事として受けるなら、範囲定義、限定検証、結果報告、修正後の再確認を別々の成果物にします。確認時間と責任分担を見積もりに含めることで、モデルの名前ではなく顧客が判断できる成果に対して料金と納期を説明できます。
Contents (6)
Claude SecurityにMythos 5採用、8月21日の変更を実務でどう読むか
2026年8月21日、Claude公式アカウントは、Claude SecurityのスキャンがClaude Mythos 5で動くようになり、Claude Enterprise顧客向けの公開ベータで利用できると告知しました。公式告知から確定できるのは、採用モデルと提供対象が示されたことです。ここから検出率、費用、対応できる脆弱性の範囲まで推測することはできません。
別の公式投稿では、コード保管庫を指定し、複数ファイルをまたいで脆弱性を調べ、コンポーネント同士の関係を推論する使い方が説明されています。スキャン説明が示すのは、単一ファイルの表面的な検索だけではなく、コードのつながりを見ながら調べる利用イメージです。ただし、どの条件で見つかり、どの条件で見逃すかは、この投稿だけでは判定できません。
今回の変更を既存の製品紹介と分ける境目は、機能一覧を増やすことではありません。Enterprise顧客が使える対象なのか、依頼者がどの範囲のコードを渡せるのか、結果を誰が確認し、誰が顧客へ説明するのかを整理することです。8月21日の告知は案件検討の入口であり、導入や安全性を決める完成品ではありません。
このニュースを読むときは、次の順に確認すると事実と判断を混同しにくくなります。
- 公式発信に書かれた事実を、発表日、製品名、モデル名、提供対象に分けて記録します。
- 利用できる範囲を、Enterprise顧客向け公開ベータという説明から広げず、個人向けや他の契約形態を勝手に含めません。
- まだ確認できない事項を、検出率、料金、再現性、すべてのコードへの保証として別欄に置きます。
この三つを分けるだけで、「新しいモデルが採用された」というニュースを、「顧客のコードをどの条件で調べ、何を納品できるか」という実務の質問へ変換できます。
脆弱性を見つけることと、安全を保証することを分けて考える
脆弱性の検出は、コードの一部に問題がある可能性を見つける調査です。一方、安全の保証は、対象の範囲、想定する攻撃条件、運用設定、依存関係、未確認部分まで含めて、一定の基準を満たしたと説明する行為です。両者は似て見えても、証明する対象が違います。
Claude公式の説明では、Mythos 5が複数ファイルやコンポーネント間の関係を追って調べることが示されています。これは調査の視野が広がる材料ですが、広く見られることと、すべてを見つけられることは同じではありません。対象リポジトリの版、設定値、外部サービス、実行時の権限など、調査に含めなかった条件があれば、結果の意味も変わります。
報告では、指摘を三種類に分けると顧客が判断しやすくなります。コードと条件から問題が成立すると確認できたもの、調査材料だけでは判定できないもの、再現しないか問題に当たらないものです。いずれも「安全」と一語でまとめず、なぜその判定になったかを残します。誤検知を減らすことだけを目標にすると、未確認の指摘を消してしまう危険もあります。
最低限、各指摘には次の情報をそろえます。
- 対象範囲。リポジトリ名、確認した版、含めたディレクトリ、対象外にした部分を記録します。
- 指摘の根拠。該当箇所、成立すると考えた条件、関係するコンポーネントを、顧客が追える形で示します。
- 人の判定。成立、追加確認が必要、該当せずのどれかを選び、判定者と確認日時を残します。
- 残る不確実性。見ていない設定、再現できない条件、利用できなかった資料を明示します。
重大な指摘や外部公開に関わる案件では、結果をそのまま採否の根拠にせず、適切なセキュリティ専門家へ確認を渡します。顧客へ「問題なし」と伝える前に、どの範囲を人が確認したのか、どの範囲は確認していないのかを説明できる状態にしておくことが、検出結果を扱う側の責任です。
なお、今回の公式発信からは検出率、料金、個人向け提供の状況、すべてのコードに対する安全保証は判断できません。確認できない数字を見積もりや提案書へ足すのではなく、未確認として残すことが、短期的な受注よりも報告の信頼性を守ります。
検出結果を人の検証と顧客向け報告書へ変える方法
検出結果を顧客が使える資料へ変えるには、スキャン結果を貼り付けるだけでは足りません。先に「何を調べたか」と「何をもって確認済みとするか」を決め、結果の一件ごとに根拠と人の判断を結び付けます。担当者が変わっても読み直せるよう、調査の前提と判断の履歴を同じ記録に置くのがポイントです。
実務では、次の順で一つの確認記録にまとめます。
- 対象を決める。リポジトリの版、対象ディレクトリ、関連する設定や依存関係、調査から外す領域を顧客と合意します。
- 脅威の仮説を置く。認証、権限、入力処理、データの流れなど、今回の確認で優先するリスクと、合格とする条件を文章にします。
- 代表ケースを選ぶ。全範囲を一度に扱うのではなく、影響が大きく、構造を代表する少数のケースを選び、限定検証の前提を明らかにします。
- 指摘を根拠付きで記録する。ファイルや機能の位置、関連する処理、成立条件、確認できた証拠を、読み手が追える粒度で残します。
- 人が判定する。成立した指摘、誤検知、追加資料が必要な指摘を分け、判断理由と確認者を記入します。判断できないものを無理に二択へ押し込みません。
- 報告と再確認を分ける。初回の結果報告に修正案を添え、修正後は同じ条件で再確認して、解消、残存、別の影響が出た状態を記録します。
この順序にすると、顧客へ渡す資料は「問題が何件あったか」だけで終わりません。確認した範囲、優先順位、担当者が次にすべきこと、修正後に再び見なければならない箇所までを一つの流れで説明できます。調査の途中で対象範囲が変わった場合も、変更前後を記録すれば、結果の比較が可能です。
報告書の文章は、断定の強さをそろえることも大切です。「脆弱性がある」「条件付きで成立する」「現時点で再現しない」「確認材料が不足している」を使い分け、検出結果の確度を一律に見せないようにします。特に未確認部分を「問題なし」と書き換えると、顧客は確認済みと受け取るため、対象外として明示します。
Mythos 5の採用は、この確認を広げるきっかけになります。しかし、顧客にとって価値があるのはモデル名ではなく、指摘の根拠を読み、人が判定し、修正後の状態まで追える記録です。受託する側は、調査結果をそのまま納品物にせず、判断できる報告書へ整える時間を最初から見込む必要があります。
4つの成果物でセキュリティレビューを見積もり、範囲を伝える
セキュリティレビューを見積もるとき、モデルの利用費だけを中心に置くと、範囲を決める時間、指摘を読み直す時間、顧客への説明、修正後の再確認が抜けます。今回のような新しい調査手段を案件へ組み込むなら、作業を四つの成果物に分け、それぞれの完成条件と確認回数を伝えると、価格と納期の根拠を示しやすくなります。
- 範囲定義書。対象リポジトリ、版、機能、含める依存関係、対象外の領域、確認する脅威、顧客側で用意する資料を一枚にまとめます。ここが曖昧だと、結果報告の件数が増減したときに、追加作業か当初範囲かを判断できません。
- 限定検証記録。代表ケース、確認条件、指摘の根拠、人の判定、未確認の条件を記録します。全コードの安全を示す資料ではなく、合意した範囲をどの条件で確かめたかを示す成果物です。
- 結果報告書。優先順位、影響の説明、修正の方向、顧客が判断する期限、残る不確実性をまとめます。検出件数を大きく見せるより、重大度と次の行動が対応していることを重視します。
- 改善提案と再確認計画。修正の順番、確認担当、再確認する範囲、完了条件を示します。初回報告だけで終わらず、修正後に何をもって解消とするかまで合意できる状態にします。
四つを分けると、顧客が必要な部分だけを選べます。たとえば最初は範囲定義書と限定検証記録で現状を把握し、重大な指摘が見つかった場合に結果報告書と再確認を追加する形です。反対に、顧客が修正を自社で行う場合でも、確認担当や再確認の条件を曖昧にしないことで、納品後の認識違いを減らせます。
見積もりは、対象範囲、確認に使う時間、報告書の粒度、修正後の再確認回数から組み立てます。モデルの料金は一項目にすぎず、人が指摘を確認する時間、顧客と範囲をすり合わせる時間、報告資料を整える時間が別に必要です。具体的な料金額を断定できる公式情報は今回の発信にはないため、案件ごとの時間と責任範囲を根拠にするのが適切です。
提案書には、含むものと含まないものを明記します。含むものは対象版の確認、代表ケースの検証、報告書一式、定めた回数の再確認です。含まないものは対象外のリポジトリ、未提供の実行環境、修正作業そのもの、追加の再確認などです。追加が必要になったときの判断基準も書いておけば、調査の途中で作業範囲が膨らんでも、顧客へ説明できます。
価格をモデル名だけで説明しないことは、値下げを避けるためだけではありません。顧客が購入しているのは、指摘の一覧ではなく、何を確認し、誰が判断し、どこまで責任を持つかが明確な資料です。四つの成果物を基準にすると、モデルが変わっても同じ品質条件で見積もりを比較できます。
小さな実地検証から継続案件へつなぐ7日間の測定方法
いきなり大規模なコード保管庫を対象にすると、見つかった指摘が調査手段の効果なのか、対象範囲の広さによるものなのか分かりにくくなります。最初は顧客の許可を得た小さな範囲で、確認前の時間、指摘の判定時間、手直し時間、顧客が判断するまでの時間を測ります。7日間は契約上の固定日数ではなく、初回の比較条件をそろえるための例です。
測定例は次の順です。
- 1日目は基準を固定する。対象版、調査する機能、想定する脅威、合格条件、確認担当を決め、既存の確認に何時間かかっているかを記録します。
- 2日目は限定範囲を調べる。代表的な機能を少数選び、対象外を明示したうえで結果を集めます。最初から全体の品質を推定せず、今回の範囲だけを評価します。
- 3日目は人が判定する。指摘ごとに成立、誤検知、追加確認が必要の判定を行い、判定にかかった時間と確認できなかった条件を残します。
- 4日目は顧客向けに報告する。優先順位、根拠、残る不確実性、次に取れる対応を整理し、顧客が採否や修正順を判断できる資料にします。
- 5日目は修正条件をそろえる。顧客が修正する箇所と完了条件を確認し、修正作業そのものを誰が担当するかを記録します。
- 6日目は同じ条件で再確認する。初回の指摘が解消したか、別の影響が出ていないか、未確認のまま残る部分はどこかを比較します。
- 7日目は次回の範囲を一つ決める。確認時間、判定時間、手直し時間、顧客の判断時間を見直し、次に広げる機能や依存関係を一つだけ合意します。
測定で見る数字は、検出件数だけではありません。初回に人が確認できた件数、成立した指摘の割合、誤検知の割合、追加資料が必要だった件数、修正後に解消した件数、再確認にかかった時間を並べます。件数が多いことが常に良いとは限らず、顧客が判断できる指摘へ絞れたか、確認の負担が予算内に収まったかを合わせて評価します。
継続案件へつなげるときは、7日間の結果から次の範囲を一つに絞ります。たとえば認証機能を広げる、依存関係の確認を加える、修正後の再確認を月次で行う、というように、前回の記録から自然に説明できる提案にします。いきなり「すべてのコードを安全にする」と約束するのではなく、確認できた範囲とまだ見ていない範囲を示して、次の判断材料を納品することが重要です。
この方法なら、Mythos 5の性能を一般化せず、顧客のコードと条件に対する実測へ落とせます。公式発信にない検出率や料金を補うのではなく、自分の案件で確認した時間と結果を残すため、次回の見積もりにも使えます。小さな検証で記録の型を作り、結果が再利用できるようになったとき、単発の紹介ではなく継続的なレビュー相談として提案しやすくなります。
出典を確認し、公式の事実と補助材料を分けて読むためのリンク
速報の根拠は、2026年8月21日のClaude公式アカウントによる二つの発信です。本文では、採用モデル、Enterprise顧客向け公開ベータ、コード保管庫を横断して調べる説明を、確認できる範囲に限って引用しました。以下の動画は速報の根拠ではなく、モデル比較や料金への関心を知る補助材料です。動画タイトルだけから、検出性能や価格を断定していません。