HOME/ビジネス/AIエージェント関連サービス/AIコードセキュリティ比較

AIコードセキュリティ比較
Microsoft MDASH・Claude Security・GitHub Advanced Securityの違いと多層防御

相次ぐ情報漏えいの多くは、既知の脆弱性や設定・管理の弱点を突かれたもので、攻撃の速さはAIによって増しています。穴を見つけてから直すまでの時間を縮める一案として、3製品を比較し、組み合わせによる多層防御を提案します。
方式、対象、提供条件、費用、データの扱いの違いを、同じ観点で並べて整理します。

PART 1基礎知識と比較3製品が何で、どう違うのかを、方式・対象・提供条件・立場ごとの観点から整理します。

01/注目される背景

相次ぐ情報漏えいの背景:「既知の穴」を突く攻撃の加速と、見つけてから直すまでの時間

2026年9月の終わりから、国内企業による不正アクセスや個人情報の漏えいの公表が続いています。原因が公表されている範囲では、新しい種類の脆弱性よりも、修正が公開済みの既知の脆弱性や、認証・設定・委託先の管理といった、以前から繰り返し警告されてきた弱点を突かれた例が目立ちます。複数の企業が共同で使うSaaSを経由して、複数社に被害が及んだ例も報じられています。

攻撃する側では、AIによって脆弱性を調べ、攻撃コードを書く作業が速く、簡単になりつつあります。脆弱性の公表から悪用までの期間は年々短くなっており、一過性ではなく今後も続く変化と捉える必要があります。守る側に求められるのは、全てを完璧に守ることより、穴を見つけてから直すまでの時間を短くすることです。

数字で見る、いま起きていること

上場企業の漏えい人数(2025年)3,063万人(前年比93%増)事故の件数は180件で4.7%減。件数より、1回の侵入で漏れる量が大きくなっている
脆弱性の公表から悪用まで(中央値)8.5日 → 5日修正が公開されてから、適用までに使える時間が短くなっている
ランサムウェア被害(2026年上半期)123件(半期で過去最多)侵入経路の約5割がVPN機器。被害組織の約6割は中小企業

2026年9月6日から10月6日までに公表された国内の事案を集計すると、件数が判明したものが76件(うちサイバー攻撃に起因するもの52件)、100万件を超える事案が9件ありました。漏れた情報の質も重要で、本人確認書類の画像のように後から変えられない情報ほど、件数が少なくても深刻になります。

AIについては、AIが見つけた脆弱性のうち実際に悪用が確認されたのは約1.3%にとどまり、今回の事案の多くも既知の脆弱性や盗まれた認証情報が原因です。AIは主な原因というより、昔からある原因に速さと規模を上乗せする要因と見るのが妥当です。言い換えれば、AIで攻撃が速くなるほど、基本対策の遅れが致命的になります。なお、2022年の改正個人情報保護法で漏えいの報告と本人への通知が義務になったことも、公表が増えて見える一因です。

数値は、公表情報をもとにした当社調べです(2026年10月時点)。

公表事例で指摘されている主な弱点

→公開機器・ソフトウェアの脆弱性の放置:VPN機器や公開しているソフトウェアの、修正済みの脆弱性が残っている
→推測されやすい管理者パスワード:管理者のアカウントが、簡単に突破される
→サポート終了のソフトウェアの継続利用:修正が提供されなくなった製品を使い続けている
→管理画面の外部公開:外部から到達できる管理画面やAPIが残っている
→委託先・共有SaaSの監督不足:自社のシステムが無事でも、委託先を経由して被害が及ぶ
→自社のソフトウェアの穴:自社のコードの欠陥や、依存ライブラリの既知の脆弱性が、修正されないまま残る

02/概要

Microsoft MDASH・Claude Security・GitHub Advanced Securityとは:AIと解析エンジンでコードの脆弱性に向き合う3つの選択肢

3製品はいずれも、ソースコードに潜む脆弱性を、開発の流れの中で見つけて直すための仕組みです。ただし、見つけ方(AIの推論か、定義したクエリか)、守る対象(コード、シークレット、依存関係)、提供する基盤(Microsoft Defender、Claude、GitHub)が異なります。どれか1つを選ぶ前に、それぞれが何を得意とし、何を対象にしていないかを知ることが、選び方の出発点です。

製品
提供元
一言でいうと
提供の状況
Microsoft MDASH
Microsoft
100を超える専門AIエージェントと複数のAIモデルで、コードの脆弱性を探索・検証・実証するスキャンシステム。Microsoft Defenderと連携する。
プレビュー(対象のDefender XDRライセンスを持つ組織)
Claude Security
Anthropic
Claudeがコードを研究者のように推論して脆弱性を探し、自ら反証して検証したうえで、修正パッチを提案する機能。
Claude Enterprise向けの公開ベータ。Claude Code向けプラグイン(ベータ)もある
GitHub Advanced Security(GHAS)
GitHub
シークレットの流出防止(Secret Protection)と、コード・依存関係の脆弱性対策(Code Security)を、GitHubの作業の流れの中で行う機能群。
一般提供。Team・Enterprise Cloud・Enterprise Serverで購入可能

3製品で対処できる範囲と、Microsoft製品などで補う範囲

3製品は、いずれもリポジトリにあるソースコードや依存関係の定義を調べる仕組みです。動作中のシステムへの診断、サーバーに入っているミドルウェアの管理、攻撃の遮断は対象外のため、別の製品で補います。Microsoftの製品で補う場合の例を並べます。

弱点
3製品でできること
3製品でできないこと
Microsoftで補う製品の例
自社のコードの脆弱性
GHASのcode scanningで毎回の変更を検査し、MDASHとClaude Securityで重要な資産を深く走査する
実行時の挙動や、本番環境の構成に起因する問題
Microsoft Defender for Cloud(GitHub Advanced Securityとの統合で、コードの指摘と実行環境のリスクを関連付ける)
依存ライブラリの既知の脆弱性
GHASのDependabotとDependency reviewで、リポジトリに定義されたライブラリの脆弱性を検出し、更新のプルリクエストを作る
リポジトリの外で、サーバーに直接インストールされたミドルウェアやOS
Microsoft Defender Vulnerability Management(サーバー・端末のソフトウェアの脆弱性)、Defender for Cloudのコンテナーイメージの脆弱性スキャン
動作中のシステムの脆弱性診断
対象外。3製品はいずれもソースコードを読む方式
動作中のWebアプリやAPIへの診断(DAST)、ペネトレーションテスト
Microsoft Defender External Attack Surface Management(外部からの公開資産の発見と、脆弱性・設定不備の検出)。本格的な診断は専門サービス
公開機器・ソフトの放置、サポート終了
対象外
VPN機器や公開サーバーのソフトウェアの、修正の適用状況
Microsoft Defender External Attack Surface Management(公開資産のソフトウェアのバージョンとCVE)、Microsoft Defender Vulnerability Management(サポート終了のソフトウェアの把握)
管理画面の外部公開・設定の不備
対象外
クラウドやネットワークの設定、公開範囲
Microsoft Defender External Attack Surface Management、Microsoft Defender for Cloud(設定の推奨事項)、Azure Bastion・Private Endpoint(管理経路の閉域化)
Webアプリへの攻撃の遮断
対象外。3製品は穴を見つけて直す手段で、攻撃を止める手段ではない
修正が済むまでの間の、攻撃の遮断
Azure Web Application Firewall(Azure Front Door または Application Gateway 上で動作)、Azure DDoS Protection
管理者パスワード・認証
GHASのpush protectionで、コードへのパスワードやキーの混入を止める
アカウントのパスワードの強度、多要素認証、不審なサインイン
Microsoft Entra ID(多要素認証、条件付きアクセス、パスワード保護)、Microsoft Entra ID Protection、Azure Key Vault(シークレットの保管)
委託先・共有SaaS
自社が権利を持つコードに限られる
委託先のシステムや、利用しているSaaSの安全性
Microsoft Defender for Cloud Apps(SaaSの利用状況の把握と監視)、Microsoft Purview(データの保護)。あわせて契約と監督
侵入の検知と初動
対象外
すでに侵入されていないかの監視、事故時の対応
Microsoft Defender XDR、Microsoft Sentinel(ログの集約と検知)

製品名は一例です。ライセンスと提供条件は、各社の公式情報で確認してください。Webアプリケーションの防御には、当社の業務提携先であるサイバーセキュリティクラウドのクラウド型WAFなども選択肢になります。本格的な動作中のシステムの診断には、専門の脆弱性診断サービスの利用もご検討ください。

3製品は、自社が作り、運用するソフトウェアの穴を、作る段階で見つけて早く塞ぐための手段です。インフラ、設定、委託先の対策と組み合わせて、初めて効果を発揮します。本ページでは、その一案として3製品を比較し、組み合わせ方を提案します。

03/分類の考え方

比較の前に押さえる3つの軸:見つけ方・守る対象・動くタイミング

3製品を同じ土俵で比べると、違いが見えにくくなります。次の3つの軸で整理すると、それぞれの役割がはっきりします。

軸 1見つけ方:推論型か、クエリ型か推論型は、AIがコードの文脈とデータの流れを読んで欠陥を探し、検証します。クエリ型は、脆弱性の特徴を定義したクエリで、コードを網羅的に調べます。3製品では MDASHとClaude Securityは推論型、GHASのcode scanning(CodeQL)はクエリ型です。
軸 2守る対象:コード・シークレット・依存関係自社のコードの欠陥、APIキーなどのシークレットの混入、利用しているライブラリの既知の脆弱性は、それぞれ別の対策です。3製品では 推論型の2製品は主にコード、GHASは3つ全てを対象にします。
軸 3動くタイミング:日常か、節目かpushやプルリクエストのたびに動く検査と、定期的に、または重要な資産に対して時間をかけて深く走査する検査があります。3製品では GHASは日常の全変更、推論型の2製品は非同期の深い走査に向きます。

04/一覧比較

3製品の比較表:方式・対象・入出力・修正・モデル・提供条件・課金・データ・監査

公表されている情報をもとに、同じ観点で並べます。プレビューやベータの製品は、条件が変わる場合があります。

観点
Microsoft MDASH
Claude Security
GitHub Advanced Security
提供元
Microsoft(Microsoft Security)
Anthropic
GitHub
方式
推論型。複数のモデルと100超の専門エージェントが、探索・討論・統合・実証を分担
推論型。Claudeが脅威モデルを作り、探索し、自ら反証して検証
クエリ型(CodeQL)と、パターン・AIによるシークレット検出、依存関係の照合
主な対象
自社のソースコード(メモリ安全性、論理の欠陥など)
自社のソースコード(インジェクション、認証、メモリ安全性、ロジックなど)
コード、シークレット、依存関係
動くタイミング
非同期の深い走査(長時間のスキャン)
手動・定期のスキャン。プラグインはPR差分も
push時、プルリクエスト時、マージ後の継続監視
入力
gitリポジトリのソースコード(バイナリ・JARは非対応)
GitHub.com・GHESのリポジトリ(プラグインは手元のリポジトリ)
GitHub(またはAzure DevOps)のリポジトリ
出力
検証・実証済みの指摘、信頼度、修正ガイダンス(SARIF・HTML)
信頼度・重大度・再現手順・推奨パッチつきの指摘(CSV・Markdown、プラグインはSARIF)
アラート(プルリクエスト、Securityタブ、security overview)
検証の方法
エージェント間の討論、重複の統合、再現による実証
多段階の敵対的検証
精度を重視した標準クエリ、AIによる誤検知の抑制
修正の扱い
読み取り専用。defender fixとGitHub Copilotで修正案を生成し、人が承認
全指摘に推奨パッチ。Claude Codeで開き、人が適用
Copilot Autofixが修正案を提示し、人が取り込む。Dependabotは更新PRを作成
AIモデル
顧客がMicrosoft Foundryでプロビジョニングしたモデル。持ち込み不可
Claude(現在の製品ページではMythos 5.1と案内)。プラグインは利用中のモデル
CodeQL自体はAIではない。AutofixとシークレットのAI検出にAIを利用
対応言語
Java、C/C++、C#、JS/TS、Pythonに専門エージェント。他は汎用エージェント
言語を限定しない推論(公表の対応表なし)
CodeQLの対応言語(C/C++、C#、Go、Java、Kotlin、JS/TS、Python、Ruby、Swift、Rustなど)
提供の状況
プレビュー
公開ベータ
一般提供
対象プラン
対象のMicrosoft Defender XDRライセンス
Claude Enterprise(Team・Maxは近日と案内)
GitHub Team、Enterprise Cloud、Enterprise Server、Azure DevOps
課金
Defender XDRのライセンスと、Foundryでの推論の消費
トークンの実費のみ。追加のプラットフォーム費用なし
active committerの数に応じた従量課金(2製品で別)
データの取り扱い
顧客のDefender XDRテナント内で暗号化保管。推論は指定リージョン
Zero Data Retentionの対象外。対象は自社が権利を持つコードに限る
GitHub上のリポジトリに対して動作
監査・記録
操作の監査ログ(ソースコードは記録しない)
却下理由の記録、エクスポート
アラートの対応履歴、push protectionの回避の承認
結果の一貫性
AIの分析は非決定的。ビルドの即時ブロックには不向き
確率的。同じコードでも結果が変わる場合あり
CodeQLのクエリは同じ設定なら再現性が高い

各社の公式情報(Microsoft Security Blog・Microsoft Learn、Anthropicの発表記事・Claude Help Center・Claude Code Docs、GitHubの発表・GitHub Docs)に基づきます。最新の条件は各社の公式情報で確認してください。

05/視点別の比較

経営・セキュリティ・開発・基盤管理・監査・AI推進、6つの立場から見た3製品の違い

立場
見るべき点
Microsoft MDASH
Claude Security
GitHub Advanced Security
経営・事業責任者
費用の構造と、守れる範囲
Microsoft環境の契約の延長で、深い監査を加えられる
Claude Enterpriseの延長で、トークン実費のみで始められる
全開発者の日常の変更を、従量課金で広く守れる
セキュリティ(CISO・AppSec)
優先度付けと、組織全体の可視化
Defenderで、脅威情報や実行時のシグナルと並べて優先度付け
信頼度と重大度で絞り、却下の理由を記録
security overviewとsecurity campaignsで組織全体を管理
開発者
指摘の届き方と、直しやすさ
GitHubやAzure DevOpsに、アラートや作業項目として届く
再現手順とパッチつきで、Claude Codeで直せる
プルリクエスト上で、Autofixの修正案とともに届く
基盤・GitHub管理
準備と設定の手間
Foundry接続、Entraのアプリ登録、許可ドメイン、リージョン
組織設定の有効化、GitHub App、SSO、IP許可、利用上限
組織・リポジトリ単位の有効化、security configurations
監査・リスク管理
記録と、データの扱い
操作の監査ログ、テナント内保管
却下理由の記録。ZDRの対象外に注意
対応履歴、回避の承認の記録
AI・DX推進
AI駆動開発との関係
マルチエージェントの設計の実例
Claude Codeとの一体的な修正
AI生成コードを、人のコードと同じ基準で検査する土台

06/メリット・デメリット

3製品それぞれのメリットとデメリット

どの製品にも、得意な領域と、対象にしていない領域があります。デメリットは、製品の欠点というより、その製品の役割の外側を示しています。

Microsoft MDASHメリット
  • 複数ファイルにまたがる深い欠陥を、討論と実証で裏付ける
  • Windows等での実発見と、公開ベンチマークの高い結果
  • Microsoft Defenderで、他のセキュリティ情報と並べて優先度付けできる
  • 新しいモデルを、仕組みを作り直さずに取り込める設計
デメリット・注意点
  • プレビューで、テナントあたり同時1スキャンなど容量に制約
  • シークレットと依存関係は主な対象ではない
  • スキャンが長時間で非決定的。ビルドの即時ブロックに不向き
  • Defender XDRとFoundryの準備が必要
Claude Securityメリット
  • APIの組み込みなしで、リポジトリを選ぶだけで始められる
  • 全ての指摘に、再現手順と推奨パッチが付く
  • 費用はトークンの実費のみで、利用上限を設定できる
  • プラグインで、GitLabや閉域のコード、PR差分にも使える
デメリット・注意点
  • マネージド版はGitHub.com・GHESのリポジトリのみ
  • Zero Data Retentionの対象外
  • 重大度の基準は変更できず、結果は確率的
  • シークレットと依存関係は主な対象ではない
GitHub Advanced Securityメリット
  • シークレット・コード・依存関係の3つをまとめて守れる
  • pushやプルリクエストのたびに、開発の流れの中で動く
  • 一般提供で、Teamプランから購入できる
  • 組織全体の可視化と、一括の是正(security campaigns)
デメリット・注意点
  • 定義したクエリの外にある、文脈依存の深い欠陥には届きにくい
  • GitHub(またはAzure DevOps)が前提
  • active committerの増加に応じて費用が増える
  • 指摘の受け手を決めないと、アラートが滞留する

07/得意・不得意

場面別の向き・不向き:シークレット・PRの検査・深い欠陥・依存関係・組織の是正

場面
Microsoft MDASH
Claude Security
GitHub Advanced Security
シークレットの混入を送信時に止める
対象外
対象外
得意(push protection)
プルリクエストごとの検査
不向き(長時間・非同期)
プラグインでPR差分を走査可能
得意(code scanning、Dependency review)
複数ファイルにまたがる深い欠陥
得意(討論と実証)
得意(推論と敵対的検証)
クエリの範囲内で対応
業務ロジックの欠陥
対応(論理の欠陥)
得意(ビジネスロジックの理解)
クエリで表現できる範囲
依存関係の既知の脆弱性
対象外
対象外
得意(Dependabot)
修正案の提示
修正案の生成(defender fix)
得意(全指摘にパッチ)
得意(Copilot Autofix)
組織全体の可視化と一括是正
Defenderで集約
エクスポート・Webhookで連携
得意(security overview・campaigns)
重要資産の定期的な深い監査
得意
得意(定期スキャン)
補助的
GitHub以外のリポジトリ
任意のgit(複製して走査)
プラグインで対応
Azure DevOps向けの提供あり

08/よくある誤解

AIコードスキャンにまつわる6つの誤解と、実際のところ

AIスキャナーがあれば、静的解析は不要になる実際は MicrosoftもAnthropicも、静的解析や既存のツールを置き換えるものではなく、併用する層と位置付けています。
3製品は、同じことをする競合製品だ実際は 見つけ方と守る対象が異なります。GHASは日常の全変更とシークレット・依存関係、推論型の2製品は深い欠陥を担い、組み合わせる関係です。
AIが修正まで自動でやってくれる実際は 3製品とも、修正は提案にとどまり、適用は人がレビューして承認する前提です。
一度スキャンすれば、同じ結果が得られる実際は 推論型のスキャンは非決定的で、同じコードでも結果が変わる場合があります。定期的に実行し、どの時点のコードの結果かを記録します。
最も性能の高いモデルを使う製品を選べばよい実際は MDASHの発表では、モデルは入力の1つで、モデルを取り巻く仕組みが成果を左右すると説明されています。検証や実証、運用への接続も比較の対象です。
導入すれば、脆弱性はゼロになる実際は どの製品も、脆弱性をゼロにするものではありません。検出と是正を早く回し、見逃しを別の層で受け止める多層防御が前提です。

09/用語集

比較の理解に役立つ用語集:推論型・クエリ型・シークレット・依存関係の基本用語

推論型スキャナーAIがコードの文脈とデータの流れを読んで、脆弱性を探し検証する方式。MDASHとClaude Security。
クエリ型(ルール型)脆弱性の特徴を定義したクエリやルールで、コードを網羅的に調べる方式。CodeQLなど。
多層防御1つの対策をすり抜けた問題を、別の層で受け止める考え方。
シフトレフト検査を、開発の後工程から前工程へ前倒しする考え方。
SASTプログラムを実行せず、コードを読んで問題を探す検査。
SCA利用している部品(ライブラリ)の既知の脆弱性を検査する手法。
シークレットAPIキー、トークン、パスワードなど、秘密にすべき認証情報。
push protectionシークレットを含むpushを、送信の時点で止めるGHASの機能。
CodeQLGitHubのセマンティックなコード解析エンジン。GHASのcode scanningの中核。
Copilot Autofixcode scanningのアラートに対する修正案を、AIが生成するGHASの機能。
敵対的検証結果に異議を唱える立場から、指摘が本物かを確認する検証。
実証(PoC)脆弱性を引き起こす入力を作り、実際に再現して存在を確かめること。
SARIF静的解析ツールの結果を表す標準のファイル形式。複数のツールの結果の集約に使う。
active committer直近の一定期間に変更を加えた開発者。GHASの課金の単位。
Zero Data Retention(ZDR)入力したデータを、提供元に保持させない契約。
非決定的同じ入力でも、実行のたびに結果が変わりうる性質。
PART 2選び方と多層防御1製品では足りない理由と、組み合わせによる多層防御の考え方、具体的なプランを示します。

10/1製品の限界

1製品では足りない理由:守る対象・タイミング・方式のすき間

3製品は、守る対象と動くタイミングが異なります。どれか1つだけでは、どこかにすき間が残ります。

守りたいもの
Microsoft MDASH
Claude Security
GitHub Advanced Security
シークレットの混入
対象外
対象外
push protection、secret scanning
依存関係の既知の脆弱性
対象外
対象外
Dependabot、Dependency review
日常の全変更の検査
容量と時間の制約
プラグインのPR差分で一部
code scanning
型に現れない深い欠陥
討論と実証
推論と敵対的検証
クエリの範囲に限られる
組織全体の状況把握
Defenderでの集約
エクスポート・Webhook
security overview
実行時の挙動
対象外(ソースのみ)
対象外(ソースのみ)
対象外(ソースのみ)
AIエージェントの権限と操作
対象外
対象外
対象外(別の統制が必要)
すき間の正体シークレットと依存関係は、推論型の2製品の主な対象ではありません。逆に、複数ファイルにまたがる深い欠陥は、定義したクエリだけでは届きにくい領域です。日常の全変更を見る層と、重要な資産を深く調べる層は、性格の異なる仕組みで分担するのが合理的です。

11/多層防御の考え方

コードセキュリティの6層:送信時・PR時・深い走査・集約・修正・統制

多層防御は、1つの層をすり抜けた問題を、別の層で受け止める考え方です。開発の流れに沿って、6つの層を重ねます。

層
目的
主な担い手
補完する仕組み
L0 AIエージェントの統制
開発に関わるAIエージェントを、許された範囲で動かす
Microsoft Agent 365(Entra・Purview・Defender)
Agentic Security、ハーネス設計
L-1 外周の防御
インフラと公開資産の既知の穴を塞ぎ、攻撃を遮断する
Defender EASM、Defender Vulnerability Management、Azure WAF、Microsoft Entra ID
Defender XDR・Sentinelによる侵入の検知
L1 送信時の防御
シークレットを、リポジトリに入れない
GHAS(push protection)
pre-commitの検査、開発者教育
L2 PR時の検査
コードと依存関係の脆弱性を、マージ前に止める
GHAS(code scanning、Dependency review)
Claude Securityプラグインの差分スキャン
L3 深い走査
型に現れない欠陥を、重要な資産から探す
Microsoft MDASH、Claude Security
専門家による監査
L4 集約と優先度付け
複数の結果を、1つの受け皿で扱う
GHASのアラート(SARIF)、Microsoft Defender
Webhook・チケット連携
L5 修正と承認
修正案を、人が確認して取り込む
Copilot Autofix、Claude Securityのパッチ、defender fix
プルリクエストのレビュー
L6 運用の統制
例外・却下・AIの操作を記録し、統制する
監査ログ、却下理由、回避の承認
ハーネス設計、Agentic Security

12/組み合わせプラン

多層防御の4つの組み合わせプラン:GitHub中心・Microsoft中心・重要資産の二重化・段階導入

組織の基盤と、守りたい資産の重さに応じて、組み合わせを選びます。いずれも、GHASを日常の全変更を見る土台に置き、推論型を重要な資産の深い走査に使う構成です。

プラン AGitHub中心型:GHAS+Claude Security向く組織 GitHubで開発し、Claude Enterpriseを利用している、または検討している組織構成 GHASで日常の全変更とシークレット・依存関係を守り、Claude Securityで重要なリポジトリを定期的に深く走査する。流れ push→PR(GHAS)→定期スキャン(Claude Security)→パッチをPRで承認注意 Claude SecurityのZDR対象外と、自社コードに限る利用範囲を確認する。
プラン BMicrosoft中心型:GHAS+MDASH+Defender向く組織 Microsoft Defender XDRとAzureを中心に、セキュリティ運用を行っている組織構成 GHASを日常の検査に置き、MDASHで重要な資産を深く走査し、Defenderで実行時の情報と並べて優先度を付ける。流れ push→PR(GHAS)→深い走査(MDASH)→Defenderで優先度付け→修正PR注意 MDASHはプレビューで、容量の制約がある。Foundryでのモデルの準備が必要。
プラン C重要資産の二重化:GHAS+MDASH+Claude Security向く組織 金融・基幹・製品のコアなど、見逃しの影響が大きい資産を持つ組織構成 性格の異なる2つの推論型スキャナーで、同じ重要資産を走査し、見逃しを減らす。結果はアラートとして集約する。流れ GHASの土台に、2種類の深い走査を重ね、重複を統合してトリアージ注意 結果の重複と費用が増えるため、対象の範囲を絞る。
プラン D段階導入型:GHASから始め、深い走査を追加向く組織 まず日常の検査の土台を整えたい組織構成 Secret ProtectionとCode Securityから始め、運用が定着した後に、重要な資産に推論型を追加する。流れ GHASの有効化→運用の定着→重要資産で推論型を試行→構成を決定注意 土台の運用(受け皿・承認)が整う前に、指摘の量を増やさない。

13/推奨構成

推奨構成:問題の捉え方で変わる、2つのリファレンスアーキテクチャ

多層防御の重心は、何を主な脅威と捉えるかで変わります。公表事例の多くは、インフラや公開ソフトウェアの既知の穴を突かれたものです。この捉え方に立つと、構成Aのように、外周の既知の穴を塞ぎ、直すまでの時間を縮めることが出発点になります。一方で、自社開発のソフトウェアが事業の中核を担い、AIによって未知の欠陥まで突かれることに備えたい組織には、3製品を主役にした構成Bが合います。2つは対立するものではなく、AからBへ段階的に広げられます。

観点
構成A:既知の穴を塞ぐ中心
構成B:3製品を主役にした深掘り
主な脅威の捉え方
インフラ、公開ソフトウェア、認証、自社コードの依存関係にある既知の穴
自社のソフトウェアに潜む、未知の深い欠陥
重心
外周の基本対策と、GHASによる毎回の検査
MDASHとClaude Securityによる、重要な資産の深い走査
主に縮めるもの
修正が公開されてから適用するまでの時間
欠陥が作り込まれてから見つかるまでの時間
3製品の役割
GHASが日常の主役。MDASHとClaude Securityは上乗せ
GHASが土台、MDASHが主力、Claude Securityが第二の目
向く組織
まず公表事例と同じ穴を塞ぎたい、多くの組織
自社開発のソフトウェアが事業の中核で、外周の対策が整っている組織
最初の一歩
公開資産と未適用の修正の棚卸し、GHASの有効化
重要なリポジトリを選び、深い走査を試行
構成A既知の穴を塞ぐ中心:外周の基本対策と、GHASによる毎回の検査で、直すまでの時間を縮める
統制面Microsoft Agent 365:開発や運用に関わるAIエージェントのID・権限・データ・脅威を統制
↓
① 外周:インフラと公開資産の既知の穴を塞ぐ(最優先)公表事例で多い侵入口。修正が公開されたら、すぐに適用できる状態をつくる
Defender EASM外部に公開している資産と、その脆弱性・設定不備を外側から見つける
Defender Vulnerability ManagementサーバーのミドルウェアやOSの脆弱性、サポート終了のソフトウェアを把握する
Microsoft Entra ID多要素認証、条件付きアクセス、推測されやすいパスワードの排除
Azure WAF修正が済むまでの間、Webアプリへの攻撃を遮断する
↓
② 内側:自社のソフトウェアの既知の穴を、毎回止めるすべての変更に対して動く土台
GHAS:依存関係Dependabotが既知の脆弱性を見つけ、更新のプルリクエストを自動で作る
GHAS:シークレットpush protectionが、APIキーやパスワードの混入を送信の時点で止める
GHAS:コードCodeQLとCopilot Autofixが、プルリクエストの上で指摘と修正案を示す
↓
③ 上乗せ:未知の深い欠陥を、定期的に探す重要な資産に絞って追加する層
Microsoft MDASH重要なリポジトリを定期的に深く走査し、討論と実証で裏付けた指摘を出す
Claude Security最重要の資産を、別の方式で走査し、見逃しを減らす
↓
直すまでの時間を縮めるループ(Microsoft Defenderで外周と内側の指摘を集約)
1 見つける外周と内側の両方EASM、Vulnerability Management、GHAS、深い走査
2 優先度を付ける悪用されやすさで並べるDefenderで、脅威情報や実行時の情報と並べる
3 直す修正を早く出すパッチの即時適用、Dependabotの更新PR、Autofixの修正案
4 確かめる塞がったかを確認する再スキャン、WAFのログ、Defender XDR・Sentinelでの監視

構成Aでは、3製品のうちGHASが日常の主役で、MDASHとClaude Securityは重要な資産に絞った上乗せの層です。公表事例で多い侵入口を先に塞ぎ、そのうえで自社のソフトウェアの穴を、作る段階で止めます。

構成B3製品を主役にした深掘り:GHASを土台に、MDASHを主力の深い走査、Claude Securityを第二の目に置く
Agent 365の役割についてMicrosoft Agent 365は、AIエージェントの登録、ID、権限、データ、脅威を管理する統制面(コントロールプレーン)です。コードを検査する製品ではなく、3つのスキャナーを直接操作するものでもありません。コーディングエージェントやMCPサーバーなど、開発に関わるAIエージェントが、許された範囲で動いているかを統制する層として位置付けます。
統制面(AIエージェントの統制)Microsoft Agent 365開発に関わるAIエージェント(コーディングエージェント、Foundryのエージェント、MCPサーバー、ローカルのエージェント)を登録し、ID・権限・データ・脅威を、既存のMicrosoftのセキュリティ製品で統制します。
Microsoft Entra(Agent ID・条件付きアクセス)Microsoft Purview(DLP・監査)Microsoft Defender(脅威の検知と対応)Intune(端末とローカルのエージェント)
↓
① 日常の検査(全リポジトリ)すべての変更に対して、毎回動く土台
開発者・AIエージェントコードを書き、pushする
↓
GitHub Advanced Security:送信時push protectionがシークレットを止める
↓
GitHub Advanced Security:プルリクエスト時CodeQL、Dependency review、Copilot Autofix
↓
人のレビューとマージ修正案を確認して取り込む
② 深い走査(重要リポジトリ)定期的に、時間をかけて深く調べる層
Microsoft MDASH:主力重要なリポジトリを、週次〜月次で深く走査。討論と実証で裏付けた指摘を出す
↓
Claude Security:第二の目最重要の資産を、四半期ごとやリリース前に、別の方式で走査し、見逃しを減らす
GitHub以外のコードMDASH(任意のgit)か、Claude Securityプラグインで補う
③ 集約と対応(SecOps)指摘を1つの流れに集め、優先度を付けて直す
GitHub:code scanningのアラートGHAS・MDASH・Claude Security(SARIF)の指摘を、開発者の作業の場に集約
↓
Microsoft DefenderMDASHの指摘を、脅威情報や実行時のシグナルと並べて優先度付け
↓
一括の是正と記録security campaigns、却下理由、回避の承認、監査ログ
↓
共通の原則:修正はすべてプルリクエストで、人が承認して取り込むCopilot Autofix、defender fix、Claude Securityのパッチは、いずれも提案です。出どころが異なる修正案を、同じレビューと承認の流れに統一します。

構成Bの頻度と役割の分担

頻度
何をするか
使う製品
主な受け手
毎回(push・PR)
シークレットの阻止、コードと依存関係の検査、修正案の提示
GitHub Advanced Security
開発者・AIエージェント
常時
開発に関わるAIエージェントの登録、ID、権限、データ、脅威の統制
Microsoft Agent 365(Entra・Purview・Defender)
IT管理・セキュリティ
週次〜月次
重要なリポジトリの深い走査と、優先度付け
Microsoft MDASH、Microsoft Defender
セキュリティ(AppSec)
四半期・リリース前
最重要の資産を、別の方式で走査し、見逃しを減らす
Claude Security
セキュリティ(AppSec)
随時
指摘の集約、一括の是正、却下と例外の記録
GitHub(code scanning、security campaigns)、Microsoft Defender
セキュリティ・開発責任者

Microsoft Defender XDRを利用していない場合は、GHASとClaude Securityを組み合わせるプランAを推奨します。いずれの場合も、まずGHASの土台と、指摘の受け皿・承認の流れを整えてから、深い走査を重ねます。

当社の推奨多くの組織には、構成Aから始めることを推奨します。外周の既知の穴と、GHASによる毎回の検査を整えたうえで、重要な資産から構成Bの深い走査を重ねていきます。自社開発のソフトウェアが事業の中核で、すでに外周の基本対策が整っている組織は、構成Bから検討できます。

14/選び方

条件別の選び方とDiscovery質問

この条件なら
選び方の目安
シークレットの事故を、まず防ぎたい
GHAS(Secret Protection)から始める。推論型の2製品は、シークレットを主な対象にしていない。
GitHubで開発し、日常の全変更を守りたい
GHAS(Code Security)を土台に置く。
Claude Enterpriseを使っていて、重要資産を深く調べたい
GHASに、Claude Securityを重ねる(プランA)。
Microsoft Defenderで、セキュリティ運用を一元化している
GHASに、MDASHを重ねる(プランB)。
見逃しの影響が大きい資産がある
性格の異なる推論型を重ねる(プランC)。
GitHub以外にコードがある
MDASH(任意のgit)や、Claude Securityプラグインを検討する。GHASはAzure DevOps向けもある。
データを保持しない契約が必須
Claude SecurityはZDRの対象外。MDASHはテナント内保管と推論リージョンを確認する。

導入検討のDiscovery質問

→ソースコードは、GitHub、GitHub Enterprise Server、Azure DevOps、その他のどこにありますか。
→Microsoft Defender XDR、Claude Enterpriseのどちらを、すでに利用していますか。
→シークレットの混入や、依存関係の脆弱性は、どう対応していますか。
→見逃しの影響が特に大きい、重要なリポジトリはどれですか。
→指摘を受け取り、優先度を決め、修正を承認する担当者は決まっていますか。
→複数のツールの結果を、どこに集約していますか。
→データの保管場所や保持について、満たすべき要件はありますか。
→AIコーディング支援による変更は、どの程度の割合ですか。

15/運用設計

組み合わせて使うときの6つの論点:集約・重複・承認・費用・データ・結果のぶれ

論点 1結果の集約GHASのアラート(SARIF)やDefenderを受け皿にし、複数の製品の指摘を1か所で扱います。
論点 2重複の扱い同じ欠陥が複数の製品から指摘される前提で、統合とトリアージの規則を決めます。
論点 3修正の承認修正案の出どころが複数になるため、取り込みはプルリクエスト単位で、人が承認する流れに統一します。
論点 4費用の把握active committerの課金と、トークン・推論の消費の両方を見て、深い走査の対象と頻度を決めます。
論点 5データの取り扱い製品ごとに、保管場所、保持、利用範囲の条件が異なります。資産の重要度に応じて、使い分けます。
論点 6結果のぶれ推論型は非決定的です。どの時点のコード・設定の結果かを記録し、定期的に実行します。
PART 3当社の支援多層防御の設計から、各層の導入、運用の定着までを支える当社のケイパビリティをご紹介します。

16/当社の強み

6つの層を横断して支える当社のケイパビリティ:GitHub・Microsoft・Claude・ハーネス設計

当社は、GitHubチャネルパートナーとしてGitHubソリューション(GHASを活用したDevSecOpsを含む)を提供し、MicrosoftのAgentic DevOps Specialization、Claudeを統制環境で運用するAI駆動開発、AIエージェントの統制を担うAgentic Securityに取り組んでいます。特定の製品に偏らず、3つの基盤を横断して層を組み合わせられることが、当社の特長です。AI駆動開発をチーム全体で推進している環境では、検査と修正もAIエージェントと同じ開発の流れに乗せられるため、セキュリティ対策のハードルが大きく下がります(Agentic DevSecOps)。当社は2026年8月末から、Claude Securityによる脆弱性診断を先行して検証し、有効性を確認しています。

層
当社のケイパビリティ
支援の内容
L0 AIエージェントの統制
Microsoft Entra ID統合開発、Copilot Studio、Agentic Security
Agent 365を前提にした、エージェントの登録、ID・権限、データ保護、監視の設計
L1・L2 GHASの土台
GitHubソリューション(GitHub Enterprise導入支援、DevOps伴走支援、GHASを活用したDevSecOps)、GitHubチャネルパートナー
Secret ProtectionとCode Securityの構成設計、security configurations、push protectionの例外運用
L3 深い走査(Microsoft)
Microsoft Foundry、Microsoft Entra ID、Agentic DevOps with Microsoft Azure and GitHub Specialization
MDASHの前提となるFoundryの推論環境、Entraのアプリ登録、CI/CD連携の準備
L3 深い走査(Claude)
Claudeを活用したガバナンス対応型AI駆動開発
Claude SecurityのGitHub連携、SSO・IP許可、利用上限、データ条件の確認
L4・L5 集約と修正
AI駆動開発/バイブコーディング CoE、AIエンジニアリングOS「SAIDDar」
指摘の集約とトリアージ、修正案をプルリクエストで承認する流れの標準化
L6 運用の統制
Agentic Security、ハーネスエンジニアリング(Physical AI Harness、コンテキストエンジニアリング)
例外・却下・AIの操作の記録と、検知から検証までの運用の自律化
全層の実装
フォワードデプロイ(FDE)、HWS Agent Camp
現場に入っての設計・導入・定着と、短期間での試作・検証

17/当社の支援内容

多層防御の支援:比較診断・構成設計・GHASの土台づくり・推論型スキャナーの併用・指摘の一本化・AI生成コードの検査

製品の比較から、構成の設計、各層の導入、運用の定着までを、フォワードデプロイ(FDE)で現場に入って進めます。MDASHとClaude Securityは各社が提供する製品で、利用には各社の提供条件が適用されます。

どれを選ぶか決めたい

3製品の比較診断

リポジトリの所在、利用中の基盤、重要な資産、データの要件、予算を棚卸しし、組み合わせのプランを提案します。

まず土台を整えたい

GHASの構成設計と運用

Secret ProtectionとCode Securityの有効化の範囲、security configurations、push protectionの例外運用、アラートの受け皿を設計します。

Microsoft環境で深く調べたい

MDASH併用の準備

Defender XDRの条件の確認、Foundryでのモデルの準備、Entraのアプリ登録、GitHub・Azure DevOpsとの連携を整えます。

Claudeで深く調べたい

Claude Security併用の準備

組織設定、GitHub App、SSO・IP許可、利用上限、データ条件を確認し、定期スキャンの対象と頻度を決めます。

指摘を一本化したい

集約・トリアージ・承認の設計

複数の製品の指摘を1つの受け皿に集め、重複の統合、優先付け、修正の承認、却下の記録を、ハーネスの考え方で業務フローに組み込みます。

組み合わせるサービスAgentic SecurityAI駆動開発(SAIDDar)
AI生成コードを安全に使いたい

AI駆動開発の検査ゲート

AIが書いたコードを、プルリクエストの流れで多層の検査に通し、人の承認を置く標準を作ります。

18/導入ステップ

比較診断から多層防御の定着までの5段階導入

STEP 1比較診断リポジトリ、基盤、重要資産、データ要件、現在の検査を棚卸し成果物:診断レポート、推奨プラン
STEP 2土台の整備GHASを有効化し、push protectionとcode scanningの運用を整備成果物:標準設定、運用ルール
STEP 3深い走査の試行重要なリポジトリで、推論型のスキャナーを試行し、指摘の質と費用を確認成果物:試行結果、対象範囲
STEP 4集約と承認の設計結果の受け皿、重複の統合、修正の承認、却下の記録を設計成果物:集約設計、承認フロー
STEP 5運用の定着定期の深い走査と、組織の是正の進捗を追い、構成を見直す成果物:運用手順、改善レポート

19/想定ROI

アラート対応・シークレット事後対応・重要資産の監査工数の削減効果

多層防御の効果は、日常の検査の自動化と、重要な資産の深い監査にかかる工数の削減に表れます。

指標
前提
導入前
導入後
削減
アラートの対応工数
月200件。1件60分を、修正案の提示とトリアージの一本化で40分へ
200時間/月
133時間/月
約33%
シークレット漏えいの事後対応
月4件。1件8時間の失効・調査を、送信時の阻止で2時間へ
32時間/月
8時間/月
75%
重要資産の深い監査
四半期に1回、重要リポジトリ5件の専門家による監査(1件40時間)を、推論型の事前走査で1件20時間へ
200時間/四半期
100時間/四半期
50%

代表的なリポジトリ1〜2件で、現行の工数を測定し、試算を実測値に置き換えてご判断いただけます。

20/当社について

認定バッジ

Claude Securityによる脆弱性診断の先行検証(2026年8月末〜)

当社は2026年8月末から、Claude Securityによる脆弱性診断を先行して検証し、有効性を確認しています。GHASを活用したDevSecOpsの実績とあわせて、推論型スキャナーを組み合わせた多層防御の設計に生かしています。

認定バッジ

GitHubチャネルパートナー認定とAgentic DevOpsソリューションの提供開始(2025年10月)

GitHubテクノロジーパートナー(2024年8月)に続いて、GitHubチャネルパートナーに認定されました。GitHub Copilot Coding Agentを用いたAI駆動開発、GitHub Copilotを活用したマイグレーションAIエージェント、Azure AI FoundryとGitHubを活用したAgent Opsなど、GitHubを活かしたサービスを、多くのエンタープライズ企業に提供しています。

認定バッジ

Microsoft Azure の AI Platform/Agentic DevOps Specialization取得

ヘッドウォータースは「Microsoft Solutions Partner for Digital & App Innovation(Azure)」の認定に加え、上位資格である「AI Platform on Microsoft Azure」「Agentic DevOps with Microsoft Azure and GitHub」の2領域のSpecializationを取得しています。Azure上のAI基盤構築から、GitHubを活用したエージェント駆動のDevOps自動化まで、Microsoftのエコシステムを横断してカバーします。

認定バッジ

GitHub Copilot for Businessの全社導入(2023年4月)とCopilot内製化支援

AIプログラミングアシスタント「GitHub Copilot for Business」を、2023年4月に全社導入しました。自社での利用で得たナレッジをもとに、2023年11月から「Copilot内製化支援サービス」を提供しています。

認定バッジ

Anthropic「Claude」を活用したガバナンス対応型AI駆動開発を本格推進(2026年3月)

GitHub Copilotを介してClaudeモデルを運用し、アクセス管理・変更管理・監査証跡を前提とした統制環境で、コーディング支援と設計書・仕様書の自動生成を行っています。大手事業者を含む複数の受注プロジェクトで実運用しています。

認定バッジ

Microsoft AI Innovation Partner of the Year 2024 受賞

「AI イノベーション パートナー オブ ザ イヤー アワード」は、マイクロソフト製品の活用によってAI分野で革新を起こしたパートナーに贈られるアワードとして2024年に新設され、ヘッドウォータースは初代受賞パートナーとなりました。日本航空(JAL)様のSLM活用や大和証券様のAIオペレーター、JR西日本様の「Copilot for 駅員」など、エンタープライズ企業向けの大規模AIエージェント開発を数多く手がけてきた実績が評価の背景にあります。

21/はじめ方

スタートプラン:重要リポジトリ1〜2件での多層防御PoC(約8〜12週間)

多層防御は、製品の設定だけでなく、指摘の受け皿、重複の統合、修正の承認、費用の確認までを含めて検証する必要があります。そのため当社は、対象を重要なリポジトリ1〜2件に絞った、約8〜12週間のPoC(概念実証)から始めることをおすすめしています。日常の検査の土台と、深い走査の試行、指摘の運用までを実データで確かめ、本格導入の構成と費用を判断していただけます。

STEP 1(2週間)診断と設計公開資産と未適用の修正を棚卸しし、対象リポジトリ、ライセンス、データ要件、現在の検査を確認して、PoCの構成と評価基準を決める成果物:PoC計画、評価基準
STEP 2(2〜3週間)土台の構築GHASのSecret ProtectionとCode Securityを有効化し、受け皿と承認の流れを整える成果物:設定、運用ルール案
STEP 3(3〜4週間)深い走査の試行MDASH、Claude Securityで対象を走査し、指摘の質・重複・費用を比べる成果物:比較結果
STEP 4(2週間)集約と修正の運用指摘を1つの受け皿に集め、修正をプルリクエストで承認する流れを実際に回す成果物:運用の記録
STEP 5(1週間)評価と判断結果をもとに、本格導入の構成、頻度、費用を判断する成果物:評価レポート、導入計画
PoCで確かめること
  • 各製品の指摘の質と量、重複の程度
  • 指摘から修正の取り込みまでの時間
  • 深い走査の費用と、適切な頻度
  • データの取り扱いと、社内の規程との整合
事前にご準備いただくもの
  • 対象のリポジトリと、その担当者
  • 利用中、または利用予定のライセンス(GitHub、Defender XDR、Claude Enterprise)
  • 指摘を受け取り、承認する担当者
  • データの保管と保持に関する社内の要件

22/関連ソリューション

GitHubソリューション

GitHub導入から、 Agentic DevOpsまで。

GitHubソリューション. GitHub Enterpriseの導入支援、DevOps伴走支援、GitHub Advanced Securityを活用したDevSecOps、GitHub Copilot Coding Agentを活用したAI駆動開発までを支援します。

Agentic DevOpsソリューション

AIエージェントがSDLC全体を 進化させる。

Agentic DevOpsソリューション. GitHubチャネルパートナーとして、Microsoft Azure、GitHub Copilot、当社のAIエージェントとAI駆動開発のナレッジを組み合わせた、Agentic DevOpsを提供します。

AI駆動開発

ソフトウェア開発を、 AIで進化させる。

AI駆動開発. GitHub CopilotやMicrosoft Azureを活用し、開発組織の生産性向上と内製化を支援します。

Claudeを活用したガバナンス対応型AI駆動開発

Claudeを、統制の効いた 開発環境で使う。

Claudeを活用したガバナンス対応型AI駆動開発. GitHub Copilotを介してClaudeを、アクセス管理・変更管理・監査証跡を前提とした統制環境で運用し、複数の受注プロジェクトで実運用しています。

Agentic Security

AIエージェントのID・権限・実行履歴を、 統制する。

Agentic Security. AIエージェントが利用するID・権限・データ接続・実行履歴を継続的に把握・保護し、検知から検証までのセキュリティ運用にもAIエージェントを活用する運用基盤です。

AI駆動開発(SAIDDar)

AI駆動開発を、 組織標準にする。

AI駆動開発(SAIDDar). 案件の改善を標準・テンプレート・エージェント定義へ還元し、人のレビューと責任者の確認を前提に、AI駆動開発を組織標準へ進めます。

Microsoft Foundry(Azure AI Foundry)エージェント

Azure上のエージェント基盤で、 Agent Opsを回す。

Microsoft Foundry(Azure AI Foundry)エージェント. モデルの選定・評価・デプロイ・運用の基盤を設計・導入し、Agent Opsによる継続的な改善を支援します。

HWS Agent Camp

最初の1業務を、 2日間で試作する。

HWS Agent Camp. 専門エンジニアが伴走する2日間の集中ハッカソン。約2週間の事前準備のうえで、AIエージェントの本格的なプロトタイプを構築します。

23/よくあるご質問

Q. 最近の情報漏えいは、3製品で防げますか。 A. 一部です。公表されている事例の多くは、VPN機器や公開ソフトウェアの脆弱性の放置、推測されやすいパスワード、管理画面の外部公開、委託先の管理など、インフラ・設定・運用の弱点を突かれたものです。3製品は自社が作るソフトウェアの穴を早く塞ぐ手段で、Microsoft Defender External Attack Surface Management、Microsoft Defender Vulnerability Management、Azure Web Application Firewall、Microsoft Entra IDなど、インフラ・設定・認証の対策と組み合わせて使います。
Q. 3製品の一番大きな違いは何ですか。 A. 見つけ方と守る対象です。MDASHとClaude SecurityはAIの推論で深い欠陥を探す方式で、主にコードが対象です。GHASは、定義したクエリによるコード検査に加えて、シークレットと依存関係も守ります。
Q. 結局、どの組み合わせを推奨しますか。 A. 多くの組織には、外周の既知の穴とGHASによる毎回の検査を中心にした構成Aから始め、重要な資産からMDASHとClaude Securityの深い走査を重ねる構成Bへ広げることを推奨します。自社開発のソフトウェアが事業の中核で、外周の対策が整っている場合は、構成Bから検討できます。
Q. Agent 365で、3つのスキャナーを管理できますか。 A. Agent 365は、AIエージェントの登録、ID、権限、データ、脅威を管理する統制面で、コードを検査する製品ではありません。スキャナーの指摘は、GitHubのcode scanningとMicrosoft Defenderに集約し、Agent 365は開発に関わるAIエージェントの統制を担います。
Q. どれか1つを選ぶなら、どれですか。 A. GitHubで開発しているなら、日常の全変更とシークレット・依存関係を守るGHASを土台にするのが基本です。そのうえで、重要な資産に推論型を重ねるかを判断します。
Q. MDASHとClaude Securityは、どちらが優れていますか。 A. 一概には言えません。MDASHはMicrosoft Defenderとの連携と、討論・実証の仕組みが特長で、Claude Securityは導入の手軽さとパッチの提示が特長です。利用中の基盤とデータの要件で選びます。
Q. GHASのCodeQLとAIスキャナーは、重複しませんか。 A. 一部の指摘は重なりますが、役割は異なります。CodeQLは定義した型を、毎回の変更に対して再現性高く調べ、推論型は型に現れない欠陥を探します。結果は、code scanningのアラートとして集約できます。
Q. 推論型のスキャナーを、CI/CDの合否判定に使えますか。 A. 向いていません。スキャンは長時間で、結果が非決定的なため、非同期のセキュリティレビューに向きます。毎回の合否判定には、GHASのcode scanningを使います。
Q. 費用はどう比べればよいですか。 A. 課金の単位が異なります。GHASはactive committerの数、Claude Securityはトークンの実費、MDASHはDefender XDRのライセンスとFoundryでの推論の消費です。深い走査の対象と頻度を絞ることで、費用を調整します。
Q. データの取り扱いで注意する点は何ですか。 A. Claude SecurityはZero Data Retentionの対象外で、対象は自社が権利を持つコードに限られます。MDASHは、顧客のDefender XDRテナント内での保管と、推論のリージョンを確認します。
Q. 修正は自動で行われますか。 A. 3製品とも、修正は提案にとどまり、人がレビューして取り込む前提です。
Q. GitHub以外にコードがある場合はどうなりますか。 A. MDASHは任意のgitリポジトリを複製して走査でき、Claude SecurityはプラグインでGitLabやBitbucketも扱えます。GHASには、Azure DevOps向けの提供があります。
Q. 多層防御にすると、運用が複雑になりませんか。 A. 結果の受け皿と承認の流れを1つにまとめれば、複雑さを抑えられます。当社は、集約・重複の統合・承認・記録の設計を支援します。
Q. 当社は何を支援できますか。 A. 3製品の比較診断、GHASの構成設計と運用、MDASHとClaude Securityを併用する準備、指摘の集約と承認の設計、AI生成コードの検査ゲートを支援します。MDASHとClaude Securityは各社の製品で、利用には各社の提供条件が適用されます。
Q. 最初は何から始めればよいですか。 A. 重要なリポジトリを1〜2件に絞った、約8〜12週間のPoCから始めることをおすすめしています。日常の検査の土台、深い走査の試行、指摘の運用までを実データで確かめ、本格導入の構成と費用を判断していただけます。

AIコードセキュリティの比較・多層防御に関するご相談

3製品の比較診断から、組み合わせの設計、各層の導入、指摘を扱う運用の設計まで、貴社の状況に合わせてご提案します。

お問い合わせ