Oracle AI Security Meshとは？機能・導入条件・料金と安全に試す手順
AI新規事業
AI新規事業のPoC・立ち上げ、何から始めるべきかご相談ください
要件定義からリリースまで、Mojiがワンチームで伴走します。
Oracle AI Security Meshは、アプリケーションとインフラの脆弱性をAIで探索・検証し、優先順位付け、修正案の準備、修正後の再テストまでを支援するOracleの管理型セキュリティテストサービスです。Oracleは2026年10月27日に発表しました。
結論から言うと、導入を検討しやすいのは、複数のクラウド・オンプレミス・既存アプリケーションにまたがる攻撃経路を調べたい一方で、AIを使う攻撃シミュレーション基盤を自社だけで構築・運用することが難しい組織です。ただし、公開情報ではセルフサービスの申込み画面、API仕様、料金表、必須のOracle契約、対応リージョンは確認できません。導入可否と費用は、Oracleへの問い合わせ時に個別確認が必要です。
また、AIが見つけた「可能性のある弱点」は、そのまま修正・本番反映の根拠にはできません。Oracle自身も、別のエージェントによる再現確認、顧客チームによる修正内容のレビュー、再テストという流れを案内しています。導入時は、AIの発見能力だけでなく、検証、承認、変更管理、監査証跡までを評価対象にしてください。
Oracle AI Security Meshとは
Oracle AI Security Meshは、Oracleの説明では、OpenAI Cyber modelsを含むサイバーセキュリティ向けのフロンティアAIモデルと、Oracleのセキュリティ専門性・テスト基盤・運用上の安全策を組み合わせた管理型サービスです。OCIだけでなく、他クラウドやオンプレミス環境にあるアプリケーション・インフラの脆弱性を対象にする構想が示されています。Oracleの発表
ここでいう「Mesh」は、一般的なネットワーク製品名としてのサービスメッシュを指すものではなく、接続されたシステムを把握し、弱点どうしの関係や攻撃経路を調べるための製品名です。
公式に確認できる主な機能
工程 | Oracleが案内する内容 | 導入側が確認すること |
|---|---|---|
対象把握 | 顧客が提供・承認したアクセスと既存の文脈情報を使い、システムと接続関係をマッピングする。 | 対象資産、接続先、利用アカウント、除外範囲が正しいか。 |
探索・テスト | 専門エージェントが弱点と攻撃経路を調べる。 | 本番影響があり得るテストの可否、実行時間帯、停止条件。 |
検証 | 別のエージェントが結果を再現し、問題が実在するかを確認する。 | 再現条件、証跡、誤検知時の扱い、担当者による最終判定。 |
優先順位付け | 確認済みの弱点から、事業への影響が大きいものを優先する。 | 自社の重要度、規制、顧客影響、復旧可能性を優先度に反映できるか。 |
修正支援 | コーディングエージェントが修正用コードの準備を支援し、チームがレビューする。 | コード変更を誰が承認し、どのCI/CD品質ゲートを通すか。 |
再テスト | 修正後、脆弱性が閉じ、通常利用も継続できるかを確認する。 | 回帰テスト、ロールバック、例外承認、完了判定の記録方法。 |
この流れは、Oracleの製品ページと発表で説明されています。特に、発見内容は企業ごとのプライベートなナレッジベースに蓄積され、将来の評価に利用されると案内されています。Oracle AI Security Meshの製品ページ
何ができるか：単なる脆弱性スキャンとの違い
公開情報から読み取れる中心機能は、既知の脆弱性一覧を出すことだけではなく、「弱点を起点に、どの資産・データへ到達し得るか」をテストし、再現可能な問題を優先して修正までつなげることです。
- システム関係の可視化：アプリケーション、API、インフラ、既存システム間のつながりを対象にする。
- 攻撃経路の調査：単体の設定不備だけではなく、複数システムをまたぐ潜在的な経路を調べる。
- 独立した確認：検出担当とは別のエージェントが再現を試み、根拠を示す設計を案内している。
- 修正の優先順位付け：確認済みの問題のうち、業務影響が大きいものへ対応を集中させる。
- 修正後の確認：チームがレビューした修正案を適用後、問題の解消と通常動作を再テストする。
たとえばOracleは、認可チェックの欠落によって、ある顧客が別の顧客の注文情報へアクセスできるケースを例示しています。この例で重要なのは、AIが「認可不備らしい」と指摘するだけでなく、実際にアクセス可能かを確認し、修正後も通常の注文閲覧が壊れていないことまで確かめる点です。Oracle公式ブログの具体例
対応環境と導入条件：公開情報で分かること・分からないこと
公式に確認できる対象
- OCI、他クラウド、オンプレミス環境にまたがるアプリケーションおよびインフラ。
- インフラ、レガシーシステム、アプリケーション、APIを含むテスト対象。
- 顧客が承認したアクセス範囲と、顧客が提供するシステム情報・文脈を使った評価。
Oracleは、顧客がテストを認可する対象範囲を定義し、Oracleがテスト中の障害や業務中断のリスクを抑える安全策を管理すると説明しています。Oracleの公式発表
公開情報だけでは確定できない項目
- OCI契約が必須か、既存のOracle製品契約が必要か。
- OpenAIとの個別契約が必要か。
- 利用可能な国・リージョン、業種別の提供条件。
- 対応する認証方式、接続方式、詳細な権限設計、ログ保管条件。
- セルフサービス利用の可否、API・SDK、SLA、サポート条件。
- 価格体系、最低利用額、PoC料金、テスト対象・頻度・資産数ごとの課金条件。
Oracleの公開導線は「Contact us（問い合わせ）」です。発表資料には将来の製品方針に関する免責もあり、機能、提供時期、価格は変更され得ると記載されています。したがって、発表日である2026年10月27日時点では、公開ページの説明だけを根拠に購入・導入可能と判断しないでください。Oracle AI Security Meshの問い合わせページ
料金：公開価格は確認できない
2026年10月27日に確認したOracle AI Security Meshの製品ページ、発表、問い合わせページには、料金表、従量単価、無償トライアル条件、最低契約額は掲載されていませんでした。そのため、「月額いくら」「OCIクレジットで使える」といった金額は現時点で断定できません。
見積もりを依頼する際は、総額だけではなく、少なくとも次の単位を分けて確認してください。
- 初期導入・対象環境のマッピングにかかる費用
- テスト対象のアプリケーション、API、クラウドアカウント、拠点などの課金単位
- 評価の実行頻度、継続監視、再テストの費用
- Oracle側の専門家支援、運用、レポート、サポートの含有範囲
- ログ、証跡、保持期間、データ保管場所に関連する追加条件
- 修正コードの準備支援、CI/CD連携、追加のセキュリティテストに関する費用
これは公開価格を推定するための項目ではなく、見積もりを比較可能にするためのMojiによる確認テンプレートです。対象資産の数だけでは比較せず、テスト範囲、実行回数、検証・再テスト、サポートの範囲をそろえてください。
導入を判断する基準
Oracle AI Security Meshの適合性は、製品名やAIモデル名だけでは決まりません。対象システムの棚卸し精度、許可できるテスト範囲、発見結果を再現できる割合、修正の承認速度、業務停止の許容度によって結論は変わります。次は一般的な設計上の目安であり、Mojiによる導入判断の提案です。
判断項目 | 導入を進めやすい状態 | 先に整備したい状態 |
|---|---|---|
対象資産 | アプリ、API、クラウドアカウント、重要データの所在を一定程度把握している。 | 所有者不明のシステムや、接続関係不明のSaaSが多い。 |
テストの認可 | 対象、禁止操作、時間帯、緊急停止権限を定義できる。 | 本番テストの承認者や、障害時の連絡経路が決まっていない。 |
検証体制 | 再現手順と証跡をもとに、開発・セキュリティ担当が判断できる。 | AIの検出結果を確認する担当者・期限が決まっていない。 |
修正経路 | コードレビュー、テスト、リリース、ロールバックの工程がある。 | 緊急修正が直接本番へ入る、または修正を担当できるチームが不明確。 |
計測 | 再現済み重要課題数、修正リードタイム、再テスト合格率を追える。 | 検出件数だけを成果指標にしている。 |
AIを使ったセキュリティテストでは、実行前に目的、範囲、制約、リスク低減策を定義することが重要です。NIST SP 800-115は、情報セキュリティテストの計画・実施・分析・緩和策のための実践的なガイドを示しており、テスト前のRules of Engagement（実行に関する詳細な制約・権限設定）の考え方も説明しています。NIST SP 800-115
安全に始めるためのPoC手順
以下は、Oracle AI Security Meshの公開機能を前提にしたMojiによるPoC設計案です。Oracleが提供を約束する標準手順ではありません。
- 対象を1業務・1経路へ絞る：最初から全社ネットワークや全アプリを対象にせず、重要だが影響範囲を把握しやすいWebアプリ、API群、またはクラウドアカウントを選びます。
- 正本を棚卸しする：対象の構成図、資産一覧、データ区分、認証方式、既知の例外、変更凍結日を準備します。不正確な構成情報では、AIによる経路分析の前提も崩れます。
- 実行ルールを文書化する：許可するテスト、禁止する操作、実行時間、レート制限、連絡先、緊急停止、顧客データへの扱いを決めます。
- 検出ではなく再現済み重要課題を評価する：候補件数ではなく、再現できた重要課題、誤検知、再現に要した時間、証跡の十分性を記録します。
- 修正案を既存の開発工程へ通す：AIが準備したコード変更を自動反映しません。既存のコードレビュー、秘密情報スキャン、単体・結合・回帰テスト、承認を通します。
- 修正後に攻撃経路と通常機能の両方を確認する：脆弱性の再現が止まったことだけでなく、正規利用者の操作が壊れていないことを確認します。
- 継続可否を判断する：検証済み課題の重要度、修正までの時間、テストによる業務影響、運用負荷、見積もり費用を、導入前に定めた基準と照合します。
AIエージェントが外部システムやコードへ影響し得る場合の、権限・承認・停止条件の設計は、AIエージェントのガードレール設計も参考にしてください。
PoCで使える評価シート
次の項目は、ベンダー比較と継続判断に使うためのMojiによる記録テンプレートです。目標値は、対象業務の重要度、入力情報の品質、許容誤差、運用体制によって設定してください。
評価軸 | 記録する内容 | 判断のポイント |
|---|---|---|
発見品質 | 検出件数、再現済み件数、誤検知件数、見逃しが判明した件数 | 件数ではなく、重要課題を再現可能な証跡とともに出せたか。 |
優先順位 | 提示順位と、社内の重要度判定との差分 | 事業影響・データ区分・露出範囲を反映できたか。 |
修正支援 | 提案数、採用数、レビュー差し戻し理由、修正後のテスト結果 | AI提案を採用することではなく、安全な変更を速く作れたか。 |
運用安全性 | 中断回数、予期しない負荷、権限逸脱、停止手順の実行結果 | 定めた範囲・時間帯・権限で実行できたか。 |
費用対効果 | 見積もり、担当者工数、再現・修正までの時間、未対応リスク | 単純な検出単価ではなく、確認・修正・再テストまでの総工数で比較できるか。 |
AIエージェントを含む仕組みは、最終回答や検出結果だけを採点すると、検索・ツール実行・権限・停止条件などの失敗を見逃します。評価対象を処理全体へ広げる考え方は、AIエージェント評価の実務手順で解説しています。
Oracleへの問い合わせ前チェックリスト
- 対象にしたい環境は、OCI、他クラウド、オンプレミスのどれか。
- 対象アプリ、API、クラウドアカウント、重要データ、システム所有者を説明できるか。
- 本番テストの許容範囲、禁止操作、実行可能な時間帯、緊急停止の担当者を決めたか。
- テストに使うアクセス権限を最小化し、発行・失効・監査の担当を決めたか。
- 検出結果を再現確認し、重要度を確定するセキュリティ・開発・業務側の責任者はいるか。
- 修正案を本番へ反映する前のレビュー、テスト、承認、ロールバック手順はあるか。
- ログ、発見内容、証跡、ナレッジベースに含まれ得る情報の保管先・保持期間・閲覧者を確認するか。
- 見積もりでは、初期費用、対象範囲、実行頻度、再テスト、サポート、契約期間を分けて提示してもらうか。
- PoCの合格条件と、停止・継続・拡大の判断者を開始前に決めたか。
まとめ
Oracle AI Security Meshは、AIを使って弱点を探すだけでなく、攻撃経路の調査、別エージェントによる再現確認、修正支援、再テストまでを管理型サービスとして扱う製品です。公開情報では、OCI・他クラウド・オンプレミスにまたがるアプリケーションやインフラを対象にする方針が示されています。
一方で、2026年10月27日時点では、価格、契約条件、セルフサービス利用、詳細な技術仕様は公開ページから確定できません。導入検討では、AIの検出件数を追うだけでは不十分です。認可範囲、再現確認、人による修正承認、再テスト、監査ログまでを含めたPoCを設計し、費用と運用負荷を比較してください。