Orca Security Discovery AI、自然言語によるセキュリティクエリのコストを削減

Orca Security Discovery AIは現在、平易な英語によるセキュリティ質問をSonarクエリへ変換しつつ、初期設計と比べて入力トークンを93%削減している。Orcaはさらに、Amazon Bedrock上でシステムを再構築した結果、クエリコストを90%、レイテンシを75%削減したと報告している。

これらの数値は、単なる通常のモデル更新以上の意味を持つ。Orcaは巨大な単一プロンプトを、各リクエストをルール、検索、小規模モデル、あるいはより深い推論のどれで処理すべきかを判断する9段階のパイプラインに置き換えた。

この結果は、あらゆるスキーマ、例、指示を一つの大きなコンテキストウィンドウへ入れるという一般的なエンタープライズAI戦略に疑問を投げかける。Orcaの経験は、コンテキストを増やすことでコストが上がり、関連性が低下し、アプリケーションが遅くなる可能性を示唆している。

その代替案では、言語モデルを制御されたクエリコンパイラ内の一部品として扱う。決定論的な照合が明白な入力を処理し、検索が実証済みの例を提供し、検証が生成されたフィルターを返却前に確認する。

この設計が重要なのは、自然言語のセキュリティクエリが機密性の高い、厳格に構造化された情報を対象とするためだ。生成されたフィルターが誤った資産を指したり、認可境界を越えたり、重要な条件を欠いたりするなら、流暢な回答にはほとんど価値がない。

Orca、巨大な単一プロンプトを本番パイプラインへ置き換え

中心となる変更はアーキテクチャだった。Orcaは、毎回のリクエストで一つのモデルにセキュリティスキーマ全体を理解させる方式をやめた。

OrcaのSonarクエリシステムは、900を超えるクラウドインフラストラクチャおよびアプリケーションモデルにまたがる。これらのモデルは、コンピュートインスタンス、ストレージバケット、アイデンティティ、脆弱性、それらを結ぶ関係性などのリソースを表現する。

Discovery AI以前、ユーザーは正確なJSONフィルターを構築する必要があった。また、正確なモデル名を把握し、ネストされた関係をたどり、18種類のフィルタリング演算子から選択しなければならなかった。

この要件は、セキュリティ上の問いは理解していてもSonarの完全なスキーマには精通していないアナリストにとって、使いやすさの障壁となっていた。そこでOrcaは、アナリストの要求を有効なフィルターに変換する自然言語インターフェースを構築した。

最初の概念実証では、最も直接的な生成AIアプローチを採用した。Orcaは900を超えるモデル定義、関係タイプ、クエリ例を、一つの大規模モデル向けプロンプトに読み込んだ。

同社によれば、設計パートナーと社内ユーザーは出力品質を評価した。しかし、この設計では同程度のワークロードでおよそ200万入力トークンを消費し、約60秒を要した。

複雑な要求では精度上の限界も明らかになった。複数のリソースモデル、ネストされた関係、複数条件を含む質問では、追加の調整が必要になることが多かった。

その後、OrcaとAWSは本番向けの9段階パイプラインを開発した。2026年3月以降、1日あたり数千件のクエリを処理し、応答時間は約15秒になっているとされる。

パイプラインは、リクエストと組織コンテキストを組み合わせるところから始まる。このコンテキストには、接続されたクラウドプロバイダー、リクエストのメタデータ、ユーザー環境の解釈に必要な詳細が含まれる場合がある。

次に、決定論的なマッチャーが構造化識別子を探す。これにはIPアドレス、CVE識別子、ファイルハッシュ、リソース名、URL、アラートIDが含まれる。

一致する識別子があれば、高コストなモデル呼び出しを行わずに事前定義済みのフィルターを起動できる。この高速経路により、予測可能な処理を確率的システムから切り離せる。

解釈を必要とするリクエストはガードレールを通過する。Orcaによると、この段階では、プロンプトインジェクションの試行、無関係な質問、未対応の入力を、クエリ生成に到達する前に遮断する。

次にシステムは、検証済みの例のライブラリを検索する。Amazon Titan embeddingsが意味的に近い候補を20件取得し、Cohere Rerank 3.5がその集合を5件に絞り込む。

モデルセレクターは、900以上のSonarモデルから現在のリクエストに関連するものを絞り込む。ジェネレーターは、その小規模なグループと関連性だけの詳細なスキーマを受け取る。

Anthropic Claude Haiku 4.5が選択および生成段階を担う。Amazon Nova 2 Liteは、Orcaがより高速で低コストな推論を優先するガードレールと検証のタスクを処理する。

生成されたフィルターは、それだけで最終結果にはならない。静的チェックが、選択されたスキーマに対して各モデル、フィールド、演算子を解決する。

Orcaはさらに、Sonar APIに対してフィルターをチェックする。検証に失敗した場合、エラーは問題の要素を特定し、修正のためにジェネレーターへ返す。

このループにより、生成は制約付きのプロセスとなる。モデルはフィルターを提案できるが、その提案が利用可能なスキーマに準拠するかどうかは決定論的システムが判断する。

Orca Security Discovery AI、意図的にコンテキストを小さくする

Orca Security Discovery AIは、コンテキストを拡張するのではなく選別することで、報告された経済性を改善した。

初期プロトタイプでは、Sonarの完全なスキーマを必須コンテキストとして扱っていた。モデルが数百のリソースタイプとその関係を理解する必要があるため、この選択は妥当に見えた。

問題は、ほとんどの質問がそのスキーマのごく一部しか扱わないことだった。毎回すべての定義を送信すると、すべての定義を有用にすることなくトークン使用量だけが増加した。

Orcaのモデルセレクターは現在、利用可能なモデルの簡潔な説明に基づいて動作する。各説明は、モデル名、目的、重要なフィールド、重要な関係を要約する。

セレクターは、質問に必要なモデルを特定する。続いてジェネレーターは、それらの選択対象についてのみ完全なスキーマと、それらを接続するために必要な関係を受け取る。

この変更により、報告された入力使用量は同程度のワークロードで約200万トークンから14万トークンへ減少した。これは、示された93%の削減に相当する。

Orcaは、90%のコスト削減を、トークン量の低下と段階ごとのモデル割り当てに帰している。異なるタスクが、もはや最大規模の利用可能なモデルをデフォルトで使用することはない。

レイテンシは約60秒から15秒へと、75%低下したとされる。高速化された経路にも複数の段階が含まれており、段階数だけでは応答時間が決まらないことを示している。

長時間の単一推論は、複数の限定的な処理より遅い場合がある。システムが既知のパターンを認識した場合、ルールと検索は生成を迂回することもできる。

これが、報告された改善の中核となる仕組みだ。Orcaは深い推論を必要とする材料を減らし、リクエストの未解決部分に対してのみ生成処理を割り当てた。

検索設計も同じ原則に従う。純粋な上位K件のセマンティック検索は高速だったが、Orcaは近重複の例を返すことが多いと判断した。

こうした重複は、多くのカバレッジを追加せずにコンテキストを占有する。Maximal Marginal Relevanceは多様性を高めたが、最も関連性の高い例を上位から遠ざけることがあった。

Orcaは、近い例を20件取得し、その後5件に再ランキングする方式に落ち着いた。より大きな初回パスでは再現率を重視し、再ランキングでは最終コンテキストをより強い一致に絞る。

高信頼度の一致があれば、既知の良好なフィルターを直接再利用できる。そうでない場合、5つの例が、検証済みの質問が過去にどのように変換されたかをジェネレーターに示す。

このアプローチは、制約のない生成というよりケースベース推論に近い。モデルは、コンパクトなスキーマと、成功した過去の挙動から抽出した例に基づいて動作する。

このアーキテクチャでは、モデル選択も置き換え可能な状態に保たれる。Amazon Bedrockは共有サービス層を通じて複数のモデルファミリーへのアクセスを提供し、個別統合の作業を削減する。

この柔軟性は、ある段階に最適な速度または精度のモデルが変わり得るため重要だ。Orcaは、アプリケーション全体を再設計せずに段階のモデルを置き換えられるとされる。

より広い教訓は、すべてのシステムが9段階を必要とするということではない。コンテキストは、本番プロンプトに入るに値する理由を持つべきだということだ。

スキーマ、例、会話履歴は、大きなコンテキストウィンドウをモデルがサポートしていてもコストを課す。無関係な材料は、重要な証拠と競合する可能性もある。

自然言語セキュリティクエリには依然として厳格な境界が必要

会話型インターフェースはクエリ言語の摩擦を減らせるが、認可、検証、セキュリティ専門知識の代替にはならない。

自然言語セキュリティクエリは、アナリストが調査のアイデアから構造化フィルターへ進む助けになり得る。しかし、質問そのものが認可済みであることや完全であることを保証するものではない。

Orcaのパイプラインには、リクエストコンテキスト、ガードレールによるスクリーニング、制約付き生成、2種類の検証が含まれる。この順序は、モデル出力を実行可能な真実として扱うリスクを認識したものだ。

Amazon Bedrockのガードレール評価は、設定済みポリシーに照らしてプロンプトと応答を検査できる。利用可能な制御には、コンテンツフィルター、禁止トピック、機密情報フィルター、プロンプト攻撃検出が含まれる。

ただし、ガードレールは認可システムではない。入力を分類できても、アクセス判断に必要なユーザーアイデンティティやリソース権限を持たない場合がある。

AWSのセキュリティガイダンスは、この区別を明確にしている。その認可制御では、言語モデルの外部でデータアクセスを強制し、接続先システム全体でユーザーアイデンティティを伝播させることを推奨している。

この分離は、クラウドセキュリティデータでは特に重要だ。クエリは、資産名、脆弱性、アカウント間の関係、ネットワーク経路、内部設定の詳細を公開する可能性がある。

幅広いバックエンドアクセスを持つアシスタントは、混乱した代理人になり得る。これは、権限の低いユーザーが、より高い権限を持つ仲介者を通じて情報を得る場合に発生する。

安全なアーキテクチャでは、モデルに到達するデータを制約しなければならない。また、結果として得られるSonarクエリが、リクエストしたユーザーに適切な権限で実行されることも保証する必要がある。

公開されたアーキテクチャによれば、Orcaはリクエストを組織およびクラウドプロバイダーのコンテキストと組み合わせる。この投稿では、テナント分離やユーザー単位の認可強制について詳細な説明は示されていない。

この欠落が脆弱性を示すわけではない。単に、報告された性能結果を完全なセキュリティ評価として解釈すべきではないという意味だ。

検証は、もう一つの重要な境界を作る。Orcaはまず構文をチェックし、その後Sonar APIを通じて生成されたフィルターを検証する。

チェックが失敗した場合、ジェネレーターは構造化されたエラーを受け取る。別の制約のない推測を始めるのではなく、特定のフィールド、演算子、関係を修正できる。

このアプローチは、存在しないスキーマ要素への参照という、ある種のハルシネーションを減らす。ただし、すべての有効なクエリがアナリストの意図を正確に捉えることを保証するものではない。

フィルターは構文的に有効であっても、意味的に不完全であり得る。正しいモデルを選択していても、例外、関係、時間境界、環境条件を省く可能性がある。

簡潔な要求が曖昧さを隠す場合、この問題はより深刻になる。「公開されているデータベースを表示して」という要求は、公開の定義、データベースの種類、ネットワーク到達可能性、許容されるリスクに左右され得る。

強力なインターフェースは、前提を明らかにするか、レビュー用に生成されたフィルターを表示すべきだ。AWSの投稿はフィルター生成と検証に焦点を当てており、完全なレビュー体験については扱っていない。

したがって、セキュリティチームはクエリの有効性と調査上の正しさを区別すべきです。前者はスキーマに照らして機械的に検証できますが、後者にはしばしばドメインに関する判断が求められます。

システムの決定論的な分岐にも注意が必要です。検証済みの例を再利用すればレイテンシーを下げられますが、表面的に似た質問に不適切なフィルターが共有されないよう、マッチングのしきい値を設定しなければなりません。

Orcaによると、信頼度の低いクエリはドメインエキスパートへルーティングされます。このフィードバックプロセスは有用ですが、その効果はサンプリング、レビュー範囲、修正の品質に左右されます。

自然言語によるアクセスは、セキュリティ調査への参加者を広げる可能性があります。同時に、責任の重心はクエリ作成者から、こうした安全策を実装するプラットフォーム設計者へ移ります。

真の対抗相手は「1モデル・1プロンプト」の設計

Orcaにとって最も意味のある比較対象は他社ベンダーではなく、自社が置き換えたモノリシックなプロトタイプです。

生成AI製品は、多くの場合、有能なモデルに接続したプロンプトから始まります。この構成は、モデルがタスクを理解できるかを検証するには有効です。

しかし、アプリケーションが実際のトラフィック、変化するスキーマ、厳格なレイテンシー要件、機密性の高い組織データに直面すると、その設計を維持するのは難しくなります。

Orcaのベースラインは、この移行の難しさを示しました。プロトタイプは有望な回答を生成したものの、すべてのリクエストに膨大なスキーマを送信しており、複雑な関係性の処理には依然として苦戦していました。

本番システムでは、生成器の外部へ複数の責務を移しています。正規表現が厳密な識別子を認識し、検索が例を見つけ、再ランキングがノイズを減らし、バリデーターが不正なフィルターを拒否します。

この分業は重要な逆転をもたらします。コンポーネントを追加したことで、不要な生成処理を防げるようになり、全体のコストとレイテンシーは低下しました。

このパイプラインは、モデル中心の調達という考え方にも疑問を投げかけます。最大規模のモデルを選んでも、それだけでは本番環境の問題を解決できませんでした。

Orcaは代わりに、タスク要件に応じてモデルを割り当てました。推論負荷の高い段階にはClaude Haiku 4.5を使い、より限定的なスクリーニングと検証の段階にはNova 2 Liteを採用しました。

Amazon Titanはセマンティック検索用の埋め込みを生成しました。Cohere Rerank 3.5は、生成前に検索された例をスコアリングします。

この組み合わせは運用上の複雑さを生みます。チームは、単一のAPI呼び出しではなく、複数モデル、検索挙動、検証ループ、依存関係を監視する必要があります。

しかし単一呼び出しのアーキテクチャは、複雑さを大きなプロンプトの内部に隠しているだけです。スキーマ管理、評価、認可、エラー処理が不要になるわけではありません。

Amazon Security Lake向けの自然言語による調査に関するAWSの先行事例も、関連するパターンを示していました。エージェントがアナリストの質問をSQLへ変換し、セキュリティログに対する追加分析を支援しました。

Orcaの実装は、自社のSonarデータグラフとドメイン固有のフィルターを対象としています。その特徴は、生成前にスキーマと例を徹底的に削減する点です。

このパターンはクラウドセキュリティ以外にも適用できます。エンタープライズシステムは多くの場合、数百のオブジェクト、フィールド、関係性、許可された操作を公開しています。

カスタマーサポートプラットフォーム、分析ツール、開発者ポータル、ナレッジシステムも、すべての定義をプロンプトに詰め込みたくなる同じ誘惑に直面します。このアプローチはデモでは機能しても、本番の経済性の下では破綻し得ます。

代替案はコンパイラパイプラインに似ています。システムがリクエストを解析し、関連する構造を特定し、先例を検索し、中間表現を生成して検証します。

言語モデルは曖昧さと変換を扱います。決定論的なコンポーネントは、強制可能なルールを扱います。

この分散により、障害箇所も特定しやすくなります。チームは、検索が関連例を見逃したのか、選択処理がスキーマを除外したのか、検証が演算子を拒否したのかを判断できます。

単一のプロンプトでは、失敗のシグナルは有用性に乏しいことが多くあります。回答が誤っている、高コストである、遅い、あるいはそのすべてであるだけです。

Orcaによると、その評価ハーネスは正確性、完全性、参照クエリとの意味的同等性を測定します。また、質問とモデルのカテゴリーに基づいて結果をスライスごとに分類しています。

これは単一の集計スコアより多くの情報を提供します。システムは全体としては良好に機能していても、まれなマルチクラウド関係や複雑な脆弱性条件で失敗する可能性があります。

この設計は、他のエンタープライズAIチームにもシステムレベルの結果を報告するよう促します。モデルのベンチマークスコアだけでは、アプリケーションのレイテンシー、検索品質、検証率、修正作業量を説明できません。

数値は強力だが、精度に関する証拠は不十分

コストとレイテンシーの改善は具体的である一方、公開されている精度の主張には同水準の測定詳細がありません。

AWSとOrcaは、トークン数、コスト、応答時間について明確な改善前後の数値を示しています。一方で、評価データセット、サンプル数、合格率、正確性の正確な改善幅は公開していません。

投稿では、複雑なマルチモデルクエリで精度が向上したと述べています。また、正確性、完全性、意味的同等性を採点するLLM-as-a-judgeシステムについても説明しています。

LLM-as-a-judgeは、別のモデルを使って生成結果を評価する手法です。迅速な反復を支援できますが、その結論はルーブリック、参照回答、判定モデルの信頼性に依存します。

Orcaは自動採点を社内スペシャリストと顧客フィードバックで補完しています。プロダクトマネージャー、サポートエンジニア、セキュリティ研究者は出力にフラグを付け、修正済みの例を追加できます。

報告によれば、信頼度の低い本番クエリは日次のラベリングキューに入ります。修正内容はソフトウェアのデプロイを必要とせず、その後の検索実行で利用可能になります。

OrcaのAI部門ディレクターであるOr Gabay氏は、そのラベリングインターフェースをチームにとって最も重要な長期的品質投資と呼びました。この発言は、別のモデルのアップグレードではなく、人間によるプロセスを重視しています。

このプロセスは改善メカニズムとして信頼に足るものです。しかし、外部の購入者やエンジニアリングチームにとっては、なおいくつかの疑問が残ります。

公開投稿では、生成がリトライ上限に達する頻度を開示していません。決定論的な経路または例の再利用経路を通るリクエストの数も報告していません。

また、中央値のレイテンシーとテールレイテンシーも区別していません。15秒という数値は典型的なワークロードを示している可能性がある一方、より遅い複雑なリクエストを隠している可能性もあります。

「同等のワークロード」という表現には、より明確な定義が必要です。トークン数とコストの削減は、リクエストの構成、選択されたモデル、キャッシュ挙動、出力長、リトライ回数に左右されます。

報告されたコスト削減も、本番パイプラインとOrca独自の初期ベースラインを比較したものです。他のクラウドセキュリティ製品やクエリ生成システムとのベンチマークではありません。

読者は、この割合を企業が報告した運用結果として受け止めるべきです。AWSとの共同ケーススタディは技術的詳細を提供していますが、独立監査ではありません。

2026年3月の本番稼働日と1日数千件のクエリは、有用な導入シグナルを提供します。しかし、ユニークユーザー数、受け入れ率、離脱、アナリストの削減時間は明らかになりません。

これらの指標は、自然言語が調査行動を変えるかどうかを判断する助けになります。推論コストの低下は重要ですが、ユーザー価値は最終的に、より良く迅速なセキュリティ判断にかかっています。

システムのフィードバックループには別のトレードオフもあります。本番の例はカバレッジを改善しますが、エキスパートが共通の方針に従わなければ、修正内容が一貫しない解釈を組み込む可能性があります。

拡大する例のバンクにはガバナンスも必要です。チームには、バージョン管理、品質レビュー、削除手順、検索される例に機密情報が混入しないための保護が求められます。

生成AIアプリケーションに関するAWSのガイダンスは、データがモデルに到達する前に取得対象を制限することを推奨しています。そのセキュリティコントロールは、データレイヤーでのID伝播とアクセス制御の適用を強調しています。

こうした懸念はOrcaの結果を否定するものではありません。むしろ、別の組織がこのアーキテクチャを再利用可能なテンプレートとして扱う前に必要となる証拠を定義するものです。

最も強力な公開上の結論は限定的ですが有用です。Orcaは、コンテキスト選択、モデルの専門化、検索、検証によって、当初の設計が大幅に改善したと報告しています。

この証拠は、スキーマの重いすべてのエージェントで普遍的な削減が実現することを示すものではありません。チームは自らのワークロードと認可要件に対して、このパターンを測定する必要があります。

OrcaのAmazon Bedrock導入後に注目すべき点

次の試金石は、スキーマ、ユーザー行動、モデルバージョンが変化し続ける中で、Orcaが品質を維持できるかどうかです。

最初のシグナルは、公開される精度の詳細です。将来の技術レポートでは、データセットの規模、クエリのカテゴリー、合格しきい値、人間によるレビューとの一致度を開示すべきです。

スライスレベルの結果は特に価値があります。マルチモデルの関係性クエリは最も難しいカテゴリーであり、Orcaのアーキテクチャにとって最も強い試験となるようです。

より透明性の高い評価は、新しい設計が効率だけでなく精度も改善したという主張を強化するでしょう。修正率やリトライ率が上昇すれば、その結論は弱まります。

2つ目のシグナルは、継続的な本番導入です。OrcaはDiscovery AIが1日数千件のクエリを処理していると述べていますが、より長期的な利用パターンによって、アナリストがそのインターフェースを信頼しているかが明らかになります。

有用な指標には、継続利用、受け入れられたフィルター、手動編集、削減時間、エスカレーションなしで解決した質問の割合が含まれます。これらの測定値は、モデルの挙動をセキュリティ運用に結び付けます。

3つ目のシグナルは、パイプラインが変化をどう処理するかです。Sonarのスキーマは進化し、顧客は未知の質問を投げかけ、基盤モデルには新バージョンが投入されます。

Orcaのモデル非依存設計は、置き換えを容易にするはずです。ただし各変更には、検索、生成、検証、認可の境界をまたぐ回帰テストが依然として必要です。

したがって、継続的評価ハーネスは初期アーキテクチャと同じくらい重要です。プロンプト、モデル、検索設定、例のすべてが、想定外のスライスで挙動を変え得ます。

システムは、変化する脅威の挙動に対しても有用であり続けなければなりません。アナリストは調査をクラウド脅威フレームワークに対応付ける一方、攻撃者は新たな経路とリソースの組み合わせを採用する可能性があります。

静的な例のライブラリは、こうした状況では陳腐化します。Orcaのエキスパートによるラベリングループは、検索バンクを新たに生じる質問に合わせ続けることを意図しています。

エンジニアリングチームにとっての当面の行動は、大規模なプロンプトの中で、ほとんどのリクエストが決して使わない情報がどこに含まれているかを調べることです。その情報は、選択、検索、または決定論的ルーティングの背後に置くべきかもしれません。

チームはまた、3つのテストを分けるべきです。クエリが有効か、ユーザーの意図を表しているか、そしてユーザーがその結果へアクセスしてよいかです。

Orca Security Discovery AIは、この階層的アプローチの注目すべき本番事例を示しています。報告された効率向上は大きなものですが、より深い貢献はシステム設計の転換にあります。

現在の問いは、進化するスキーマと敵対的利用の中でもこの効率が維持されることを示すのに十分な運用上の証拠をOrcaが公開するかどうかです。その証拠が、このパターンがエンタープライズエージェントのより広い標準となるかを決定します。