AWS Continuum拡大で問われるAmazonとAnthropicの関係、OpenAIが試金石に
AWSがContinuumをClaude CodeおよびOpenAI Codexと連携させたと報じられ、AmazonとAnthropicの関係は新たな局面に入った。両コーディングエージェントは直接競合しているにもかかわらずだ。この動きにより、コードを生成、変更、実行できるツールの内部に、独立したセキュリティ層が置かれることになる。また、AmazonがAnthropicと緊密な商業関係を維持するなかで、AWSがモデル中立性を保てるかどうかも試される。
報じられたCodexとの接続については、Claude CodeおよびAWS独自のKiro環境に対するサポートほど詳細な公開文書は出ていない。AWSの公開資料では、Claude Code統合、シミュレートされたエクスプロイト検証、複数のコードホスティングプラットフォームへの対応が明確に説明されている。この検証上の隔たりは重要だ。より大きな戦略上の主張は、Continuumが競合するエージェント環境をまたいで機能することを前提としているためである。
これは開発パイプラインの終盤に追加される、また一つのスキャナーではない。AWSはContinuumに、脆弱性を発見から検証、優先順位付け、修復まで追跡させようとしている。このアプローチが機能すれば、コーディングエージェントが変更を作成する一方、別のエージェントがその変更によって悪用可能なリスクが生じたかを判断することになる。
AWS Continuum、セキュリティをコーディングセッションへ
AWSはセキュリティレビューを独立したチェックポイントから、AIエージェントがコードを書き換えるワークスペースへ移そうとしている。
AWSは2026年6月17日、ニューヨークで開催したサミットで、コード脆弱性向けContinuumを発表した。このサービスは、検出、優先順位付け、検証、緩和、修復を継続的に行うワークフローとして、限定プレビューに入った。
同社はContinuumをモデル非依存型と説明している。つまり、異なるセキュリティタスクを異なる最先端モデルに割り当て、新しいモデルが利用可能になれば取り込めるということだ。この設計により、セキュリティプロセス全体を単一のモデルプロバイダーに縛らない。
AWSはAWS Security Agentの機能もContinuumファミリーに統合した。これにはコードスキャン、ペネトレーションテスト、脅威モデリングが含まれ、ソースコードや設計文書を、想定される攻撃の構造化モデルへ変換する。
最も明確に文書化されている開発者統合はClaude Codeだ。AWSによれば、開発者は別のセキュリティコンソールへ切り替えることなく、コーディング環境からセキュリティ作業を開始できる。このワークフロー内で脅威モデルを作成し、リポジトリをスキャンし、検証済みの検出事項に対処できる。
Claude Code pluginは、ソースコード管理システムやコラボレーションツールとも連携する。AWSは、対応統合としてGitLab.com、セルフマネージドGitLab、GitHub Enterprise、Bitbucket、Confluenceを挙げている。
AWS独自のKiro環境も、AIエージェントに特化機能へのアクセスを与える拡張機能であるKiro Powerを通じて、同様の扱いを受ける。どちらの統合も、エージェントがコード変更を提案する瞬間に、より近い場所でセキュリティフィードバックを提供する。
VentureBeatの8月の報道は、この戦略をOpenAI Codexにも拡張している。ただし、本分析で確認したAWSの6月のリリース資料には、KiroとClaude Codeは記載されているものの、同等のCodex pluginは示されていない。AWSはCodex接続を別途、あるいはより新しい統合レイヤーを通じて展開している可能性がある。
この違いは、より大きな転換を否定するものではない。AWSが公に文書化した内容と、報道されている内容との境界を定めるものだ。企業の購入担当者は、3つすべてのコーディング環境で機能が同等だと想定する前に、製品文書を求めるべきである。
それでも、直近の変化は大きい。Continuumは、孤立したコード断片以上のものを観察するよう設計されている。インフラ、権限、ネットワークトポロジー、文書、コミュニケーション、事業上の優先事項を参照し、検出事項が意味のあるリスクを示すかを評価する。
この広範な文脈が、本記事の中心的な緊張関係を生む。AWSは開発者が好みのコーディングエージェントで迅速に作業できるようにしつつ、どの変更が信頼に値するかを決めるセキュリティの権威としてAWSを位置付けようとしている。
AmazonとAnthropicの関係が排他的なスタックを生まない理由
戦略上の意外性は、Claude Codeが勝てばAWSも利益を得る一方、ContinuumはClaude Codeの競合相手もサポートするほど価値を増す点にある。
AmazonはAnthropicに多額の投資を行い、Claudeを同社の生成AI提供の中核に据えている。AnthropicもAWSインフラに依存しており、ClaudeモデルはAmazon Bedrock内で引き続き有力な選択肢となっている。
この関係により、AmazonはAnthropicの成長に直接的な利害を持つ。Claude Codeは、計画、編集、テスト、繰り返しのコマンド実行を要するリポジトリ全体のタスクでClaudeを使う開発者にとって、重要な入口となっている。
Claude Codeに限定されたAWSセキュリティ製品は、この提携を強化するだろう。しかし同時に、Continuumの対象市場を狭め、複数の開発環境を運用する企業にとってサービスの有用性を下げることにもなる。
大半の大規模組織は、すべての開発者を単一のコーディングエージェントに統一していない。チームは、言語、リポジトリ、リスク水準、可用性、社内ポリシーに応じてモデルを評価する。また、一部の開発者は、実装とレビューのために同じ変更を複数のエージェントに渡す。
したがって、AWSにはAmazonの投資上の動機とは異なるプラットフォーム上の動機がある。どのモデルがコードを書いたかにかかわらず、ワークロード、セキュリティコンテキスト、修復活動がAWSを通過すれば、プラットフォーム事業は利益を得る。
これが、OpenAI Codexが戦略に含まれる理由だ。Codexは開発者インターフェースでClaude Codeと競合するが、そのユーザーはContinuumにとって、リポジトリ、検出事項、セキュリティ判断の新たな供給源となる。
その結果は、よく知られたクラウドのパターンである。プロバイダーは、自社インフラ上で競合するソフトウェアをサポートする。顧客の選択肢が増えることで、プロバイダーの下位レイヤーのサービス利用も増えるためだ。
このパターンは、AmazonとAnthropicの関係が重要でないことを意味しない。Anthropicのセキュリティ研究は、推論に基づく脆弱性発見の緊急性を示す一助となった。AWSは、従来のセキュリティ運用が追随できない理由を説明する際、Claude Mythosを含む特化型セキュリティモデルを具体的に挙げている。
Claude Mythosは、サイバーセキュリティ推論に特化したモデルとして提示されている。AWSによれば、このカテゴリーのモデルは、従来のチームが生じるバックログを処理するより速く、脆弱性を発見し、複雑な攻撃経路を推論できる。
これにより、二方向からの圧力が生じる。より優れたモデルは防御側による欠陥の特定を助けるが、攻撃者も同様の能力を使って欠陥を発見し、悪用できる。自動化された発見が改善されるたびに、迅速な検証と修復の価値は高まる。
OpenAIもCodex Securityを通じて同じ機会を追求している。VentureBeatは、OpenAIのベータ版が120万件超のコミットをスキャンし、重大度の異なる数千件の検出事項を明らかにしたと報じた。これらの数値は独立した比較ではなく、依然として同社公表の結果である。
Anthropicも、パターン指向の静的解析に代わる推論ベースの選択肢としてClaude Code Securityを推進している。Anthropicによれば、その発表は、既存のオープンソースプロジェクトで数百件の高深刻度脆弱性を発見した研究に続くものだった。
AWSは、こうしたセキュリティの物語のどちらかを選んでいるわけではない。Continuumをそれらの上位に位置付けている。コーディングモデルは、最も難しい欠陥を誰が発見または修正できるかを競える一方、AWSはコンテキスト、検証、制御、企業ワークフローを管理する。
AmazonとAnthropicの戦略、モデル中立のセキュリティ層と交差
Continuumの最も重要な仕組みは脆弱性の発見ではなく、コード生成とセキュリティ判断を分離することにある。
コーディングエージェントは開発プロセスの中で特異な位置を占める。リポジトリを読み、ツールを呼び出し、ファイルを変更し、テストを実行し、プルリクエストを開き、ときにはデプロイメントシステムとやり取りできる。
このアクセスがエージェントの生産性を高める。同時に、その認証情報と実行権限をセキュリティ上の標的に変える。
VentureBeatは、コーディングエージェントに関する複数のインシデントを文書化している。そこでは攻撃者が、モデルの重みではなく認証情報や実行経路を標的にした。悪意ある入力はモデルの知能を打ち破る必要がなかった。エージェントが認可済みツールを使う方法を操作するだけでよかった。
報告されたCodexの脆弱性の一つは、細工されたGitブランチ名の安全でない処理に関するものだった。研究者らは、その値がセットアップスクリプトに到達し、OAuthトークンを露出させ得ることを示した。OpenAIはこの問題を社内で最高優先度に分類し、修正を展開したと報じられている。
Claude Codeも、パッケージ内容やコマンド制御の挙動に関して別の精査を受けた。これらのインシデントは技術的原因が異なるものの、同じアーキテクチャ上の問題を露呈した。エージェントは、認証情報を保持し、受動的なチャットウィンドウの外で行動するようになると、攻撃対象領域になり得る。
coding-agent exploitsは、従来のアイデンティティ監視にも課題を突き付ける。有効なトークンは、根底にある要求が信頼できないリポジトリ内容によって操作されていた場合でも、エージェントの行動を認証できる。
Continuumは、このリスクの別の部分に対処しようとしている。環境および事業上のコンテキストを用いてコード脆弱性を評価し、その後、隔離されたサンドボックス内で疑わしいエクスプロイトを検証する。
サンドボックスは、通常の本番アクセスを与えることなく、潜在的に危険なコードを実行できる隔離環境である。AWSによれば、Continuumはこの環境を用いて、報告された脆弱性が悪用可能であることを再現可能な証拠として示す。
コードスキャンシステムは、本番環境で到達可能なリスクを示さない検出事項を生みがちなため、このステップは重要である。脆弱なコンポーネントが実行されない、外部入力を受け付けない、あるいは機密データへの経路上にない可能性もある。
Continuumの優先順位付けプロセスでは、影響を受けるコンポーネントがデプロイされているか、到達可能か、本番環境に接続しているかを考慮する。修復作業の順位付け前に、潜在的な事業影響も評価する。
システムはその後、ネットワーク制御、ポリシー、検知メカニズムなど、既存の保護策を評価する。検証済みの検出事項については、コードパッチ、ポリシー変更、ネットワーク変更を推奨できる。
AWSによれば、提案されたパッチは元の問題の確認に使われたのと同じ検証メカニズムを通過する。詳細が利用可能な場合、システムは予想される影響とロールバックの経路も示すことができる。
このループにより、AWSにはClaude CodeとCodexの両方を統合する理由が生まれる。パッチを書くモデルが、そのパッチが安全かどうかを判断する唯一の権威である必要はない。
チームはClaude Codeに機能を作成させ、Continuumに結果として生じる攻撃経路をテストさせ、修復時には別のモデルを使うことができる。同じプロセスは、Codexが最初の変更を作成した場合にも適用できる。
このアーキテクチャは、単一のモデルベンダーへの依存も抑える。特化型モデルがエクスプロイト構築やパッチレビューでより優れたものになれば、AWSは開発者が好むコーディングエージェントを置き換えることなく、そのモデルを追加できる。
AmazonとAnthropicの提携にとって、モデル中立性は利点であると同時に制約でもある。Claudeは特化した推論に貢献できるが、AWSはオーケストレーション、ポリシー、監査履歴、周辺のクラウドコンテキストに対する制御を維持する。
セキュリティの約束はコンテキストと制御にかかっている
Continuumは、より多くのコンテキストを把握し、やがてより多くの行動を取れる一元化されたセキュリティシステムと引き換えに、開発者の自律性の一部を差し出す。
AWSは、過去10年間に使われてきたセキュリティ運用モデルが時代遅れになりつつあると主張している。そのモデルでは、テレメトリーを収集・保存し、クエリを構築し、ダッシュボードを通じてアラートを提示して人間がレビューする。
これに対しContinuumは、テレメトリーをコンテキスト、推論、アクションに結び付ける。この違いは重要だ。ダッシュボードをもう1つ増やしても、すでに過密なキューに検出結果を追加するだけだからである。
このサービスは、4つの継続的なフェーズで動作する。まず、既存の脆弱性バックログを取り込み、独自のスキャンを実行する。次に、技術的な到達可能性とビジネスコンテキストを用いて検出結果を順位付けする。
3番目に、Continuumはサンドボックス内でエクスプロイトの再現を試みる。4番目に、コード、ネットワーク、またはポリシーの変更を通じて緩和策を推奨、あるいは実行する。
Continuum architectureは、人間が管理するlearn modeから始まる。推奨にはシステムの推論に関する説明が含まれ、チームはより広範な権限を与える前に判断内容を確認できる。
組織は後に、選択したリスクカテゴリをenforce modeへ移行できる。このモードでは、Continuumは顧客が定義した境界の範囲内で、より自動化された修復を適用できる。
この段階的な設計は、エンタープライズにおける根本的な懸念に対応している。セキュリティリーダーが、新しいエージェントに初日から本番システム全体への無制限な変更を任せたいと考えることはほとんどない。
権限が拡大するにつれ、監査可能性が不可欠になる。AWSは、すべての判断は説明可能であり、すべてのアクションは監査可能だとしている。また、ユーザーはContinuumがなぜアクションを推奨したのか、ロールバックが何を行うのかを確認できるとしている。
これらは企業側の主張であり、限定プレビューでは、多様な本番環境における性能を示す公開証拠はほとんどない。購入者は、インターフェースが説明を生成するかどうかだけでなく、その説明の品質を検証すべきである。
読みやすい説明であっても、重要な前提が省かれている可能性がある。監査可能なアクションであっても、不完全なコンテキストに基づいている可能性がある。変更が分散サービスや永続データに影響する場合、ロールバック計画は失敗することがある。
コンテキストの品質も別の課題となる。Continuumがソースコード、権限、トポロジー、ドキュメント、コミュニケーション、優先度を横断して推論できるのは、それらの入力が正確でアクセス可能な場合に限られる。
インフラストラクチャのインベントリは乖離する。ドキュメントは古くなる。権限グラフには例外が含まれる。特にインシデント発生時には、ビジネス上の優先順位がチーム間で衝突することがある。
こうした入力を一元化すればセキュリティ判断を改善できる一方、それらを扱うシステムの機密性も高まる。アクセス制御は、1つのリポジトリやチームが別のリポジトリやチームの情報を露出させないようにしなければならない。
開発チームは、リポジトリのコンテンツがいつセキュリティエージェントに影響を与え得るのかも理解する必要がある。脅威モデル、コメント、ドキュメント、issueの説明には、信頼できないテキストが含まれている場合がある。エージェントシステムは、そのテキストがセキュリティポリシーやツールの動作を密かに変更しないよう防がなければならない。
これらの懸念は、エージェント型セキュリティに反対する論拠ではない。執行はマーケティングへの信頼ではなく、測定可能な検証の後に行うべき理由を説明している。
Continuumを評価するチームは、その判断を既存のペネトレーションテストや手動レビューと比較すべきである。確認済みの検出結果、誤検知、見逃し、修復の品質、ロールバックの成功、トリアージで節約された時間を測定すべきだ。
有用なengineering knowledge baseも、人間によるレビューを支援できる。チームには、検出結果をアーキテクチャ上の判断、所有者、過去のインシデント、受容済みのリスクに結び付ける、検索可能な記録が必要だ。
真の試金石は、Continuumがエージェントのインターフェースの背後に判断を隠すことなく、その判断を改善できるかどうかである。チームが本番環境の変更がなぜ発生したのかを再構築できなければ、修復の高速化に価値は限られる。
Claude Code、Codex、そして従来型スキャナーは依然として競合する
AWS Continuumは、モデル提供者、セキュリティベンダー、クラウドプラットフォームが同じ修復判断の主導権を握ろうとする市場に参入する。
一般にSASTと呼ばれる従来型の静的アプリケーションセキュリティテストは、危険なパターンや既知の欠陥クラスをソースコードから探す。アプリケーションを実行せずに機能し、確立された開発パイプラインに適合する。
推論モデルは異なる方法でこの問題に取り組む。ファイルをまたいでデータフローを追跡し、開発者の意図を推定し、複数の弱点を結び付け、一連のアクションが悪用可能な経路を生み出すかどうかを検討できる。
AnthropicとOpenAIはいずれも、推論ベースのスキャナーがパターンベースのシステムでは見逃される脆弱性を検出できると主張している。両社の発表は、既存のアプリケーションセキュリティベンダーに対し、より深いコンテキスト分析を追加する圧力を高めた。
この比較は、単純な置き換えの話ではない。従来型スキャナーは、決定論的なルール、成熟したポリシー制御、幅広い言語サポート、使い慣れたコンプライアンスレポートを提供する。繰り返しのスキャンにおいて、その動作は再現しやすい場合がある。
モデルベースのシステムは、より曖昧な関係を検討できる一方、出力が変動することがある。また、独自のソースコード、プロンプト、実行ツール、生成されたエクスプロイト証拠を慎重に扱う必要がある。
独立したテストでは、すでに限界も見つかっている。Checkmarxの研究者は、評価中に中程度に複雑な脆弱性がClaude Code Securityから漏れることがあったと報告した。この結果は普遍的な順位を確立するものではないが、推論がスキャナーの盲点を解消するという主張には疑問を投げかける。
scanner comparisonも、企業が複数の制御を維持する理由を示している。推論エージェントは、決定論的なスキャン、依存関係分析、テスト、手動レビューを直ちに置き換えるのではなく、補完できる。
Continuumは単にスキャンするだけではないため、さらに別の競争レイヤーを加える。検出結果をAWS環境のコンテキストと組み合わせ、修復へ至る経路を管理する。
顧客がインフラストラクチャの大部分をすでにAWS上で運用している場合、これは独立系セキュリティベンダーに圧力をかけ得る。クラウドプロバイダーは、外部ツールでは顧客によるエクスポートや再構築が必要となる可能性がある構成関係にアクセスできる。
独立系ベンダーには重要な利点が残る。1つの環境を優遇せず、複数のクラウドをサポートできる。また、クラウドプロバイダーが自社サービス内のリスクを評価する際に、中立的な評価を提供できる場合もある。
OpenAIとAnthropicは、関連する選択に直面している。ネイティブのセキュリティ製品を深めることも、外部のオーケストレーションレイヤーと統合することも、両方の戦略を追求することもできる。
Claude Code Securityは、Anthropicに開発者およびセキュリティチームとの直接的な関係をもたらす。Continuumとの統合はClaude Codeのエンタープライズでの到達範囲を広げるが、AWSがポリシーと修復履歴を所有することも可能にする。
Codex Securityは、OpenAIに同じ緊張関係を生む。統合により、AWS中心の組織内でCodexは承認しやすくなる可能性がある。一方で、そのエージェントを取り巻くセキュリティワークフローに対するOpenAIの制御は低下する可能性がある。
AWSのモデル中立的な立場が機能するのは、顧客が同社を信頼し、これらのツールを一貫して扱うと考える場合に限られる。Kiro、Claude Code、Codexの間に機能格差があれば、その約束は弱まる。
そのため、報じられたCodex統合をめぐる公開情報の不足は注目に値する。購入者は、CodexがClaude Code向けに文書化されているものと同じ脅威モデリング、スキャン、エクスプロイト検証、修復機能をサポートするか確認すべきである。
また、各タスクがどこで実行されるのか、どのモデルがリポジトリのコンテンツを受け取るのか、成果物がどれだけ長く保存されるのか、検出結果が各提供者のモデルを改善するかどうかも問うべきだ。
AmazonとAnthropicの関係は、これらの問いをさらに重要にする。AWSは、あるモデル企業との密接な関係が、モデル中立性を単なるブランディング上の主張に変えていないことを示さなければならない。
AWSが開発者の信頼を得られるかを示す3つのシグナル
次の段階は、統合の同等性、独立した検証、顧客がContinuumに意味のある権限を与えるという証拠にかかっている。
最初のシグナルは、報じられたOpenAI Codex接続に関する完全な技術ドキュメントである。AWSは、サポート対象の環境、利用可能なアクション、必要な権限、リージョンカバレッジ、Claude CodeやKiroとの違いを明示すべきだ。
同等のドキュメントがあれば、モデル中立性の主張は強化される。より限定的なCodexコネクターであれば、Continuumが依然としてAmazon Anthropic圏内で最も機能することを示すだろう。
2番目のシグナルは、シミュレーションによる検証の独立テストである。セキュリティ研究者は、現実的なアプリケーションを対象に、Continuumのエクスプロイト証拠を手動ペネトレーションテストと比較する必要がある。
強い結果には、有効な検出結果に対する高い再現率と、誤検知の測定可能な減少が含まれる。研究者は、生成されたエクスプロイト試行がサンドボックス内にリスクを導入したり、機密コンテキストを漏えいさせたりしないかも検証すべきである。
結果が芳しくなくても、アーキテクチャが無意味になるわけではない。Continuumは助言的な役割にとどまり、learn modeからenforce modeへの移行は遅くなるだろう。
3番目のシグナルは、限定プレビュー期間中の顧客の行動である。AWSは、金融サービス、自動車、テクノロジー分野の組織と協力しながら製品を形作ってきたとしている。
実名の導入事例、測定された成果、より長い運用履歴は、ローンチ時のデモンストレーションよりも重みを持つ。最も示唆的な指標は、顧客が実際にこのサービスにどれだけの修復権限を与えるかである。
Continuumを推奨のみに限定するチームも、優先順位付けと検証から価値を得ている。しかし、その行動は信頼がAWSの自動アクションというビジョンにまだ達していないことを示すだろう。
enforce modeへの移行は、より強い証拠となる。それでも購入者は許可される範囲を検証すべきである。低リスクの依存関係アップデートを自動化することと、ネットワークポリシーや本番コードを変更することは大きく異なるからだ。
より広範なagent security launchは、ContinuumをAWS Context、DevOps Agent、Kiro、Transform、Bedrock AgentCoreに結び付けている。これらのサービスは合わせて、エージェントによって管理されるソフトウェアライフサイクルの拡大を描き出す。
あるエージェントはコードを書ける。別のエージェントはリリース準備状況を評価できる。さらに別のエージェントは、老朽化した依存関係をモダナイズできる。Continuumは脆弱性を評価し、スタック全体にわたる変更を推奨できる。
この役割分担は、単一のコーディングモデルへの依存を減らせる可能性がある。また、本来なら激しく競合する企業のエージェントを接続するコントロールプレーンとして、AWSを位置付けることもできる。
開発者は、このビジョンを採用する前に実務的な問いを投げかけるべきだ。どのエージェントが別のエージェントの仕事を判断することを許され、その権限はどのような証拠によって支えられるのか。
セキュリティリーダーは、権限、評価データ、可逆的なワークフローを通じて答えを定義すべきである。すべてのツールが見慣れたベンダー名を掲げているという事実に頼るべきではない。
AmazonとAnthropicの提携により、AWSは重要なモデルと急成長する開発者プラットフォームへアクセスできる。OpenAI Codexをサポートすることは、AWSがClaudeの配布以上に広い役割を望んでいることを示すだろう。
今後数カ月間は、ドキュメント、独立したエクスプロイトテスト、enforce modeの採用状況に注目すべきだ。これらのシグナルは、Continuumが信頼されるセキュリティレイヤーとなるのか、野心的なプレビューにとどまるのかを明らかにする。
チームでClaude Code、Codex、Kiroを利用しているなら、現在これらのエージェントが利用できるすべての認証情報と本番アクションをマッピングしてほしい。その上で、独立した検証ステップがどこでワークフローを中断すべきかを判断する。この作業は、Continuumが広く利用可能になる前であっても、すぐに価値をもたらす。
