Claude セキュリティレビューで稼ぐ｜受託単価を上げる方法

なぜ今「AI × セキュリティ」が稼ぎ時なのか — Glasswing 拡大が示した地殻変動

2026 年 6 月 2 日、Anthropic は重要インフラ向けのサイバーセキュリティ支援構想「Project Glasswing」を拡大したと発表しました(出典: https://www.anthropic.com/news/expanding-project-glasswing )。これは 2026 年 4 月 7 日に立ち上がった構想(出典: https://www.anthropic.com/glasswing )の続報にあたります。注目すべきは、防御側の AI 活用が「実験」から「現場で件数を出す段階」へ移ったことです。脆弱性発見の生産性が桁で上がると、それを案件に組み込めるエンジニアの市場価値も連動して上がります。専門部署だけの話ではなく、受託・副業の見積もりに直接効く変化として読むのが正しい温度感です。

当初約 50 から新たに約 150 組織へ — 1 万件超は「発表ベース」

公式発表によると、当初 Claude Mythos Preview に触れていたのは約 50 組織でしたが、今回新たに約 150 組織が加わりました。新規参加組織は 15 カ国超に分布し、これまで手薄だった電力・水道・医療・通信・ハードウェアの各分野を含みます。そして参加組織は Mythos Preview を使い、累計で 1 万件を超える高・重大深刻度のセキュリティ上の欠陥を発見したとされています。ただしこの「1 万件超」はあくまで Anthropic の発表ベースの数字であり、第三者が検証した件数ではありません。記事でも会話でも、ここは「同社の発表によれば」と断って扱うのが安全です。

なぜこれが受託エンジニアの追い風なのか

大手が AI で脆弱性を量産発見しているというニュースは、発注側の不安を確実に押し上げます。「うちのコードは大丈夫か」という問いが増えれば、それに答えられるエンジニアへの需要が伸びます。直近では動画やコミュニティでもセキュリティ・脆弱性領域への関心が高まっており、需要の追い風は数字以外でも感じ取れます。重要なのは、この関心を「不安を煽る商売」ではなく「防御と是正を淡々と請け負う仕事」に変換することです。煽りは一度きりですが、監査は継続案件になります。

Mythos は招待制 — 一般エンジニアが今すぐ使える Claude の機能

ここで期待値を正直に下げておきます。今回の主役である Mythos Preview は、誰でも触れるモデルではありません。だからといって打つ手が無いわけでもありません。「専用モデルが無い＝何もできない」と早合点すると、目の前にある一般機能の伸びしろを取りこぼします。重要なのは、自分が今すぐ手を動かせる範囲を正確に把握し、そこで価値を出すことです。一般に開かれた Claude / Claude Code の機能だけでも、受託や自作プロダクトに監査を組み込む入り口は十分にあります。この節では「使えないもの」と「今すぐ使えるもの」をはっきり分けて整理し、顧客にも自分にも誠実に説明できる土台を作ります。

Mythos Preview と Claude Security は手が届かない — 事実を正直に

Claude Mythos Preview は、アクセス要件を満たした参加組織に限定して提供されており、一般公開の予定は現時点で示されていません。Anthropic は将来的に「Mythos 級の能力を安全に一般提供へ広げたい」と述べていますが、それは安全策を整えた後の話です。あわせて、コードベース全体をスキャンする Claude Security は Enterprise 契約者向けの機能で、Pro / Free プランからは使えません。「招待制と契約者向けは別物」と最初に線を引いておくと、読者にも顧客にも誠実な説明ができます(Glasswing と Mythos の全体像は Project Glasswing と Mythos Preview の解説 を参照)。

一般機能でできるのは「コードレビュー」と「セキュリティレビュー」

一方で、Claude Code には脆弱性観点のレビューを回す /security-review と、変更点をレビューする /code-review が用意されています(コマンドの仕様は Claude Code /code-review 入門 と公式ドキュメント https://code.claude.com/docs にまとまっています)。チャットの Claude にコードや差分を貼り付け、「認証・入力検証・鍵の扱いの観点でレビューして」と頼むだけでも、観点の抜けを洗い出せます。専用モデルのような網羅性は望めませんが、受託案件の品質を一段上げ、見積もりに一項目足す根拠を作るには十分実用的です。

自分のリポジトリでセキュリティレビューを 1 本通す手順

理屈より、まず手元で 1 回通してみるのが理解の近道です。ここでは差分単位で軽く回す流れを、今日からそのまま真似できる形に落とします。大規模リポジトリをいきなり丸ごと見ようとすると、指摘が散漫になり、どこから直せばよいか分からなくなりがちです。だからこそ「小さく区切って繰り返す」のが基本姿勢になります。最初は自分の練習用リポジトリや、影響範囲の小さな個人プロジェクトで試すのが安全です。手順そのものに慣れておけば、実際の受託案件で顧客のコードを預かったときも、落ち着いて同じ流れを再現できます。

レビューを通す 5 ステップ

1. レビュー対象を「差分」に絞る。リポジトリ全体ではなく、直近の変更ファイルやプルリクエスト単位にすると、指摘が具体的になり読みやすくなる。
2. Claude Code で /security-review を実行し、現在のブランチの変更点に対して脆弱性観点のレビューをかける。チャットの Claude を使う場合は対象コードと「何を守りたいか」を明示して貼る。
3. 出力された指摘を「深刻度」と「再現条件」で仕分けする。すぐ直すもの、要確認のもの、誤検知の疑いがあるものに分ける。
4. 認証情報や API キー・鍵の取り扱い、入力値の検証漏れ、依存パッケージの古いバージョンを重点的に見直す。ここは AI でなくても効く定番の確認点。
5. 修正後にもう一度レビューを通し、指摘が消えたかを確認してから納品・マージする。差分が変われば再チェックする習慣をつける。

見落としやすい確認ポイント

ステップに沿って回すだけでも一定の効果は出ますが、AI のレビューは「文脈を渡した範囲」しか見られない点に注意が必要です。たとえば認証情報や鍵は、コードに直書きしていないか、設定値の読み込み経路が安全かまで含めて確認します。依存パッケージは、既知の脆弱性が報告されていないかを別途突き合わせると精度が上がります。AI の指摘を起点にしつつ、人が最終確認する二段構えが、見落としを減らす現実的な型です。

「稼ぐ」に変える 3 つの型 — 見積もりへの落とし込み

レビューが回せるようになったら、次はそれを収益に結びつけます。ポイントは「特別なことをしている」と大げさに伝えるのではなく、見積もりの一項目として自然に組み込むことです。発注側は「セキュリティ」という言葉に身構えがちですが、選べる形で淡々と提示されれば、むしろ安心材料として受け取ります。逆に、レビューを無料サービスとして抱え込むと、工数だけ増えて単価に反映されません。ここでは受託・副業で実際に効く 3 つの型を、見積もりへの書き方まで添えて示します。自分の案件タイプに近いものから 1 つ試すだけでも、提示できる金額の上限が変わってきます。

型①:受託に「セキュリティ監査オプション」を 1 行足す

最も導入が軽いのが、既存の見積もりに監査オプションを追加する型です。たとえば「基本実装一式」に加えて「セキュリティレビュー(主要画面・API の脆弱性観点チェックと是正提案):一式」を別項目で立てます。発注側は「やるか / やらないか」を選べるため心理的な抵抗が小さく、選ばれれば単価が上乗せされ、選ばれなくても提案したこと自体が信頼につながります。金額は工数ベースで控えめに置き、実績を重ねてから上げていくのが安全です。

型②:レビュー代行を単価に乗せる

すでに動いているプロダクトを持つ顧客には、レビュー代行そのものを商品にできます。「リリース前の差分に脆弱性観点のレビューをかけ、指摘と是正案をレポートで返す」という単発・定期の役務です。AI を使うことで 1 件あたりの工数は下げつつ、提示する単価は「専門スキルの提供」として維持できます。短縮できた分をそのまま値下げに回さないことが、この型で利益を残す鍵になります。レポートの体裁を整えておくと、継続契約に発展しやすくなります。

型③:レガシー改修 × 脆弱性是正のセット提案

単価を最も伸ばしやすいのが、レガシー改修と脆弱性是正を束ねる型です。古いコードの改修案件では、機能追加と並行して脆弱性の洗い出しと是正をまとめて提案します。「どうせ触るなら、ここで安全性も底上げしましょう」という流れは発注側にも納得感があり、改修単体より大きな見積もりが通りやすくなります。レガシー改修そのものの進め方は Claude Code でレガシー改修 の型と組み合わせると、提案の説得力がさらに増します。

落とし穴と限界 — 過信しないための 2 つの線引き

最後に、稼ぎに変えるからこそ守るべき限界を確認します。ここを曖昧にすると、短期の売上と引き換えに信頼を失い、リピートも紹介も途絶えます。AI セキュリティレビューは強力な入り口ですが、万能の保証書ではありません。「AI に通したから安全」と顧客に言い切ってしまうと、後で問題が出たときに逃げ場がなくなります。むしろ限界を先に共有しておくほうが、専門家としての誠実さが伝わり、長い取引につながります。次の 2 点は、案件を受ける前に必ず自分の中で線引きしておくべき要点です。

誤検知と見逃しは必ず出る — 最終判断は人が負う

AI のレビューは、存在しない問題を指摘する誤検知も、本物の脆弱性を見逃す取りこぼしも避けられません。出力をそのまま顧客に渡すのではなく、再現条件を人が確認し、深刻度を自分の言葉で説明できる状態にしてから納品します。「AI が大丈夫と言った」は責任の所在を曖昧にするだけで、最終判断は請け負った人が負うという原則は変わりません。

Mythos 級の発見は一般機能では再現できない — 数字は発表ベース

冒頭の 1 万件超という数字は、招待制の専用モデルと参加組織の体制があって出たもので、しかも同社の発表ベースです。一般機能の /security-review で同じ網羅性が出ると顧客に約束してはいけません。できるのは「主要な観点を素早く洗い、是正につなげる」ことであり、深いインフラ監査が必要な領域は専門の体制やツールに委ねる、という線引きを最初に共有しておくことが、過信による事故を防ぎます。

出典

• Anthropic News「Expanding Project Glasswing」(2026-06-02) — https://www.anthropic.com/news/expanding-project-glasswing
• Anthropic「Project Glasswing」(2026-04-07) — https://www.anthropic.com/glasswing
• Claude Code 公式ドキュメント — https://code.claude.com/docs
• 関連記事「Project Glasswing と Mythos Preview — 採択 12 社の全貌」 — /project-glasswing-mythos-preview
• 関連記事「Claude Code /code-review 入門」 — /claude-code-code-review-command-guide