2026.10.24 セキュリティ

AWS Continuumとは？コード脆弱性の検出・検証・修正PRの仕組みと料金・導入手順

AWS Continuumは、コードの脆弱性を見つけ、AWS上の構成から本当に悪用できるかを確かめ、修正のプルリクエストまで作るAWSのセキュリティサービスです。2026年6月17日に発表され、中核のコード脆弱性機能（AWS Continuum for code vulnerabilities）は2026年10月22日に一般提供（GA）となりました。旧AWS Security Agentの侵入テストも、いまはContinuumの一機能です。本記事では、構成、修正PRが届くまでの流れ、初回スキャンまでの手順、料金の計算方法、採用と見送りの条件を公式ドキュメントに沿って説明します。侵入テストの料金と実行手順はAWS Security Agentのペネトレーションテスト｜$50/task-hourの料金と実行手順・外部診断との使い分けで扱っています。

まとめ：AWS Continuumの正体とコード脆弱性機能を試す前の判断材料

AWS Continuumは、脆弱性の「検出」で止まらず、「本番で届くか」「実際に悪用できるか」「どう直すか」までを1つの流れで扱うサービスです。静的解析ツールが出す大量の指摘を、AWS環境の構成情報と突き合わせて絞り込む役割を担います。

採用の判断で先に見るべきは3点です。提供リージョンは2026年10月時点で米国東部（バージニア北部）と米国西部（オレゴン）の2つだけで、東京はありません。料金はコード行数に応じた月額と、脆弱性1件ごとの推論料金の合算で、公式の試算では推論料金が総額の8割以上を占めます。修正はすべて人がプルリクエストを確認してマージする必要があり、自動で本番に入ることはありません。

本番がAWS上にあり、指摘の多さに対してトリアージの人手が足りない開発組織なら、リポジトリを絞った試験導入から始める価値があります。コードを米国リージョンに置けない、または第三者の診断報告書が必要な場合は、現時点では見送るのが妥当です。

AWS Continuumの定義と旧AWS Security Agentを含む3機能の構成

名前が新しいので混乱しやすいのですが、Continuumは単一の機能ではなく、複数のセキュリティ機能をまとめた製品の名前です。

発見・優先順位付け・検証・修復の4段階で脆弱性を扱うサービスの定義

ユーザーガイドの「What is AWS Continuum?」は、Continuumを脆弱性・脅威・悪用の動きを突き合わせて優先度を付け、ビジネス上のリスクに応じて修復まで進めるサービスと説明しています。背景にあるのは、生成AIで攻撃コードが短時間に作れるようになり、検出結果の量にセキュリティ担当の手が追いつかないという問題意識です。

AWSの日本語の紹介ブログによると、処理は4段階です。既存の脆弱性の一覧を取り込みつつ自前でもスキャンする「発見」、デプロイの有無や本番の経路上にあるかで並べる「優先順位付け」、サンドボックスで再現して誤検知を除く「検証」、そしてネットワーク・ポリシー・コードの変更を提案する「緩和と修復」です。運用は人が判断に関わるlearnモードから始め、信頼できる範囲だけを自動化するenforceモードへ移る設計になっています。

旧AWS Security Agentの侵入テストと脅威モデリングとの関係と提供状況

AWS Continuumの製品ページは、侵入テスト機能を「Continuum for penetration testing (f.k.a. AWS Security Agent)」と表記しています。2025年12月にプレビュー公開されたAWS Security Agentは、Continuumの一機能として組み込まれました。2026年10月24日時点の各機能の状態は次のとおりです。

機能	状態	課金
コード脆弱性	GA（2026年10月22日）	行数と推論の従量
侵入テスト（旧Security Agent）	提供中	50ドル/task-hour
コードレビュー	プレビュー	無課金・月1,000件
設計レビュー	プレビュー	無課金・月200件
脅威モデリング（STRIDE）	プレビュー	無課金

プレビュー機能の件数は公式FAQの記載です。注意したいのは、検索で上位に出るニュース記事の多くが6月の発表時点の内容で、コード脆弱性機能を「限定プレビュー」と書いたままになっている点です。GAの告知は10月22日のAWS公式ブログで出ています。侵入テストの課金単位や実行手順はAWS Security Agentのペネトレーションテストの解説を参照してください。

コード脆弱性機能がGitHubのコードから修正PRを作るまでの処理の流れ

ここからは、GAとなったコード脆弱性機能に絞って、内部で何が行われるかを見ていきます。

AWS環境のコンテキストグラフで到達可能性と影響範囲を判定する仕組み

Continuumは、コードのリポジトリとAWSアカウントの構成情報から「コンテキストグラフ」を組み立てます。AWSコンテキストの追加手順によると、コードが動くアカウントに置いたコレクター（collector）が、AWS ConfigのリソースからAPI Gateway、EC2のセキュリティグループやルートテーブル、IAMのロールとポリシー、ECS、EKS、RDS、Lambda、Secrets Manager、WAFなどを集めます。GitHub連携の場合は、ワークフローとActionsの定義もCIの文脈として読み込む対象です。

答えようとしている問いは「ネットワーク越しに届くか」「そのコードはデプロイされているか」「侵害されたら次に何へ届くか」で、顧客データや決済処理に近い経路ほど優先度が上がります。ただし公式は、到達可能性を形式的な証明ではなく優先度の目安として扱うよう明記しています。Go向けのgovulncheckの到達可能性解析と同じ発想を、インフラの層まで広げたものです。依存パッケージの一覧を先に整えるならAmazon InspectorでSBOMを出力する手順が役立ちます。

サンドボックスでの悪用検証とProof欄に出る証拠の読み方と限界

検出した脆弱性ごとに、Continuumは証拠の強さ（evidence level）を付けます。GAブログが挙げる例は「脆弱なコード経路の静的解析で証明された」という判定です。再現できるものについては、隔離されたサンドボックスで実際に悪用を試み、概念実証（PoC）のコードと再現手順を添えます。

コンソールでは、課題（Issue）の詳細画面にSynopsis、Risk assessment、Proof、Remediation summaryなどが並びます。課題の確認手順には、単体テストや実行可能な証明が付かない課題もあると書かれています。Proofが静的解析だけの課題は、PoC付きより一段疑って読むのが実務的です。なおスキャナーの生の検出結果はFindingsタブに分かれて表示されます。

修正パッチの配信先と人の承認が必須になっている現時点の運用範囲

修正案はコードのパッチ、依存パッケージの更新、設定変更のいずれかで作られます。パッチの確認手順によると、環境の設定で「Automatically deliver remediation patches」を有効にしておけば、GitHubではプルリクエストが作られ、S3連携ではバケットの continuum-patches/ 配下にパッチファイルが置かれます。コンソールから .patch ファイルとして手元にダウンロードすることも可能です。

GAブログは「Every fix requires human approval」と書いており、2026年10月時点では修正をすべて人が確認してマージします。条件を満たす修正の自動適用は将来の予定で、時期は示されていません。「PRを作ってくれる担当者」と考え、レビューの工数は自社で確保してください。

S3連携のIAMロール作成から初回スキャンまでをAWS CLIで進める手順

コードの置き場所はGitHubかAmazon S3の2択です。GitHub連携はコンソールでGitHub Appを入れるだけなので、ここでは権限の設計が要るS3連携を例に進めます。

GitHub連携とS3連携の選び方とリポジトリ10件までのクォータの確認

GitHubで管理しているならGitHub連携が手早く、CIの定義もコンテキストとして読まれます。GitLabや社内のGitサーバーのコードはzipにしてS3へ置く方式で、バケットはContinuumと同じアカウント・同じリージョンに作ります。

始める前にクォータの一覧を確認してください。既定値は1リージョンあたり連携10件、環境10件、1環境あたりのリポジトリ10件、コレクター1件です。公式は引き上げの窓口をAWSのアカウントチームとしているため、数十のリポジトリを一度に載せる計画なら早めに相談が必要です。

continuum.amazonaws.comへの信頼設定とCLIによるIAMロール作成

利用開始の手順に沿って、Continuumがバケットを読むためのロールを作ります。まず必要なのは、信頼ポリシーを trust-policy.json として保存する作業です。外部ID（ExternalId）は、後でコンソールの連携作成画面に入れる値と一致させます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ContinuumAccess",
      "Effect": "Allow",
      "Principal": { "Service": "continuum.amazonaws.com" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "sts:ExternalId": "my-continuum-external-id" }
      }
    }
  ]
}

権限ポリシー integration-permissions.json には、バケットの一覧取得、code/ と context/ 配下の読み取り、continuum-patches/ 配下への書き込みを入れます（全文は公式手順にあります）。そのうえで、パスを /continuum/integrations/ に固定してロールを作ります。

aws iam create-role \
    --role-name ContinuumIntegrationRole \
    --path /continuum/integrations/ \
    --assume-role-policy-document file://trust-policy.json

aws iam put-role-policy \
    --role-name ContinuumIntegrationRole \
    --policy-name ContinuumIntegrationAccess \
    --policy-document file://integration-permissions.json

aws iam get-role \
    --role-name ContinuumIntegrationRole \
    --query 'Role.Arn' --output text

最後のコマンドで返るARNに role/continuum/integrations/ が含まれていれば成功です。パスを付け忘れると、連携の作成時にアクセス検証で失敗します。連携を作る側の利用者には iam:PassRole が要りますが、公式は条件キー iam:PassedToService を continuum.amazonaws.com に限定するよう求めています。

環境の作成とスキャン頻度4種類の選び方と初回スキャンの確認方法

連携ができたら、スキャン対象・頻度・パッチの届け先を決める「環境（environment）」を作ります。対象はGitHubなら owner/repository、S3ならプレフィックス（既定は code/）で指定します。

スキャンの実行手順によると、頻度はEvery day、Every 2 days、Every 7 days、Manual onlyの4種類で、既定は毎日です。Manual onlyを選んでも、環境を作った時点で初回のスキャンは必ず走ります。手動でキューに入れたスキャンは取り消せません。推論料金は検出件数に応じてかかるので、試験導入の段階ではManual onlyにして、スキャンの回数を自分で管理するほうが費用を読みやすくなります。

ビルドに社外のレジストリが要るなら、詳細設定の「Allowed dependency domains」に足しておく。StatusがSucceededになった後も課題の整理とパッチの生成は続くので、Issuesタブは時間をおいて更新してください。

コレクターでAWS Configのリソースを取り込むときの権限設計の注意点

コードだけでもスキャンはできますが、優先度付けの精度を左右するのはAWSのコンテキストです。コレクターはコードが動くアカウントとリージョンでコンソールから有効にし、環境側のアカウントで AssociateCollector を呼んで関連付けます。

複数アカウントで運用するなら、コレクターのリソースポリシーを更新する PutResourcePolicy に注意が要ります。このAPIはポリシー全体を置き換えるため、1文だけ送ると他のアカウントへの許可が消える。GetResourcePolicy で現在のポリシーと revisionId を取り、文を足してから送ってください。

コード行数と推論単位CIUで決まる料金の計算方法と見積もりの落とし穴

料金は「守るコードの量」と「処理した脆弱性の量」の2軸です。前払いや最低料金はありません。

月額は100万行あたり200ドルの段階制と1CIU10ドルの推論料金の合算

公式の料金ページの単価は、次の2種類に分かれています。コンテキスト料金（ContinuumContext-Code）は、保護するコードの最初の1,000万行が100万行あたり200ドル、次の9,000万行が180ドル、1億行から10億行が160ドル、10億行から100億行が130ドル、それを超える分が100ドルです。推論料金（ContinuumInference）は、脆弱性の調査や修正に使った推論単位（CIU）1つあたり10ドルです。

料金ページの例を再現する計算を、Pythonで書くと次のようになります。区間ごとの単価はその区間の行数だけに掛かります。

# 料金ページの段階単価（百万行あたりのドル）。各区間の単価はその区間の行数だけに掛かる
TIERS = [(10, 200), (90, 180), (900, 160), (9000, 130), (float("inf"), 100)]
CIU_PRICE = 10  # 1 CIU あたりのドル


def context_fee(million_lines):
    fee, rest = 0, million_lines
    for size, price in TIERS:
        used = min(rest, size)
        fee += used * price
        rest -= used
    return fee


def monthly(million_lines, issues, ciu_per_issue):
    ctx = context_fee(million_lines)
    inference = issues * ciu_per_issue * CIU_PRICE
    return ctx, inference, ctx + inference


# 料金ページの例1〜3（百万行, 脆弱性の件数, 1件あたりのCIU）
for case in [(1, 100, 1), (10, 1000, 1), (100, 10000, 2)]:
    print(case, monthly(*case))

実行すると、100万行・100件・1件1CIUで月1,200ドル、1,000万行・1,000件で12,000ドル、1億行・1万件・1件2CIUで218,200ドルとなり、料金ページの例1から例3と一致します。自社のコード行数と、既存のスキャナーが出している月あたりの指摘件数を入れれば、桁の見当が付きます。

推論料金が総額の8割超を占める構造と導入予算を読むときの注意点

上の例1と例2では、総額に占める推論料金の割合はどちらも約83%、例3では約92%です。つまり費用を決めるのはコードの行数より、処理させる脆弱性の件数と1件あたりのCIUです。料金ページ自体が「実際の推論量は脆弱性ごとの作業内容で変わる」と注記しており、例の1〜2CIUは保証値ではありません。

見積もりで外しやすいのは2点です。古い依存パッケージを大量に抱えたリポジトリは、初回スキャンで件数が膨らむ。そして毎日スキャンしたとき同じ課題の再処理がどう数えられるかは、料金ページから読み切れません。まずリポジトリを絞ってManual onlyで1回走らせ、請求に出たCIUの実数を見てから広げる順序をおすすめします。

Amazon InspectorやGitHubのコードスキャンとの違いと役割の分担

「既に静的解析ツールを入れているのに、さらに必要か」は導入検討で必ず出る疑問です。

静的解析ツールとの違いは検出ではなく悪用可能性の検証と優先順位付け

CodeQLのようなコードスキャンは、ソースコードの中にある危険なパターンを指摘するところが主な役割です。設定や対応言語はGitHub Code ScanningとCodeQLの解説にまとめています。指摘に対する修正案を出す機能もGitHub Copilot Autofixのように既にあります。

Continuumが上乗せするのは、その指摘が本番のAWS環境で外から届くかの判断と、サンドボックスでの再現です。既存の検出結果を取り込む前提の設計なので、静的解析ツールの置き換えではなく、後段のトリアージ層と考えるのが正確です。AWS純正のコードレビュー機能だったCodeGuruの後継を探している場合は、Amazon CodeGuruの終了後の代替サービスの選び方と合わせて比較すると、役割の違いが見えます。

Claude CodeやCodex、Kiroとの連携発表と2026年10月時点の提供状況

2026年8月5日のAWS Security Blogの発表で、AWSはAnthropic、OpenAIと組み、Continuumを Claude Code、OpenAI Codex、Kiro の中から使えるようにすると発表しました。コーディング環境からスキャンを起動し、結果をAWS環境の文脈で優先度付けし、サンドボックスで検証したうえで、エージェントへ返す流れです。新規に書くコードには、各ツール向けのContinuumプラグインで検証済みの提案を返すとしています。

ただし連携は「coming soon」とされ、10月22日のGAブログにも提供開始の記載はありません。プラグインを前提にした導入計画は、提供開始の告知を待ってから組むほうが安全です。AWS製のAI IDEについてはKiroとは？AWS製の仕様駆動AI IDEの特徴で解説しています。

AWS Continuumを採用する条件と見送るべき場面・外部の診断との使い分け

立場をはっきりさせておきます。2026年10月時点では、全社で一斉に入れる段階ではなく、条件の合うチームが試験的に使う段階です。

本番がAWS上にあり米国リージョンにコードを置ける組織は試験導入から始める

次の条件がそろうなら、試験導入を勧めます。本番のワークロードがAWS上で動いている、静的解析の指摘が溜まっていて優先順位を付ける人手が足りない、コードを米国東部か米国西部のリージョンで処理することに社内の合意が取れる、の3つです。

強みはAWSの構成情報を読んで優先度を付ける点なので、ECSやEKS、Lambdaで公開APIを運用しているチームほど効きます。試験導入は外部公開しているサービスのリポジトリ1〜2本で始め、Proofの質とCIUの実数を2〜3回分見てから広げてください。

東京リージョン必須や第三者の診断報告書が要る場合は見送る判断

見送るべき場面もはっきりしています。1つは、ソースコードや構成情報を国内のリージョンから出せない場合です。2026年10月時点で東京リージョンでは提供されておらず、S3連携でもバケットはContinuumを有効にした米国のリージョンに置く必要があります。

もう1つは、取引先や監査に出す第三者の診断報告書が必要な場合です。Continuumの結果は自社の開発プロセスの中で使う情報で、外部の専門家が作る診断報告書の代わりにはなりません。侵入テストと脆弱性診断の違いはペネトレーションテストと脆弱性診断の違いで整理しているため、両者の使い分けを確認できます。リリース前や監査の節目に報告書付きの診断が要る場合は、一創の脆弱性診断・セキュリティ診断がご相談の窓口です。日常の検出とトリアージはツールに任せ、節目の診断は人が行う、という分担を前提に診断範囲の設計からお手伝いします。

よくある質問

AWS Continuumの検討段階で出やすい質問に答えます。

AWS ContinuumとAWS Security Agentは別のサービスですか？

別のサービスではありません。AWS Security Agentは、いまはContinuumの侵入テスト機能（Continuum for penetration testing）という位置づけです。Continuumはそれに加えて、コード脆弱性機能やプレビュー中の脅威モデリングを含む、より広い製品の名前にあたります。

AWS Continuumは東京リージョンで使えますか？

2026年10月24日時点では使えません。コード脆弱性機能の提供は米国東部（バージニア北部）と米国西部（オレゴン）だけで、S3連携のバケットも同じリージョンに置きます。国内での処理が条件なら、リージョンの追加を待つ判断になります。

AWS Continuumの料金はいくらかかりますか？

コード行数に応じたコンテキスト料金と、推論単位（CIU）ごとの推論料金の合算です。公式の例では、100万行で脆弱性100件を処理すると月1,200ドルで、その約83%が推論料金にあたります。侵入テストは別料金で、1task-hourあたり50ドルです。

見つかった脆弱性は自動で修正されますか？

修正案は自動で作られますが、本番への反映は自動ではありません。GitHubではプルリクエスト、S3ではパッチファイルとして届き、レビューとマージは自社の担当者が行います。条件を満たす修正の自動適用は将来の予定で、時期は未定です。

GitHub以外のリポジトリやAWS外のシステムでも使えますか？

GitHub以外のコードは、zipにしてAmazon S3へ置けばスキャンできます。ただ、優先度付けの材料はAWSアカウントの構成情報なので、本番がオンプレミスや他のクラウドにあるシステムでは到達可能性の判定が効きにくくなる。AWS外のアプリケーションへの侵入テストは、侵入テスト機能の側で対応しています。