Oracle Cloud Infrastructure Blog(翻訳)

プラットフォーム管理と共有責任によるAIエージェントの保護 (2026/07/31) https://blogs.oracle.com/cloud-infrastructure/ai-agent-security-shared-responsibility 投稿者： Giulio Faini  | Master Principal Technologist, EMEA SaaS Security and Privacy, Oracle   Reshma Sivakumar  |  Principal Technical Product Manager, AI Security   Miranda Jimenez  |  Product Marketing Manager   SaaS Cloud Security AIエージェントは、文書作成、要約、質問への回答といった従来の業務にとどまらず、企業ワークフローをサポートするようになってきています。Oracle AI StudioやOracle SaaSのカスタム構築型エージェントアプリケーションなど、エージェントアプリケーションでは、エージェントがデータの取得、ツールの呼び出し、アプリケーションプログラミングインターフェースとの連携、ビジネスプロセスの開始支援などを行うことができます。こうした状況は、重要なセキュリティ上の課題を生み出します。ソフトウェアがワークフローに代わって動作できる場合、アクセス、アクション、承認、監視をどのように管理すべきでしょうか？ 責任あるAIは、ガバナンス、倫理、プライバシー、透明性、コンプライアンス、および人間の監視を通じて議論されることが多い。しかし、その最も重要な運用基盤の1つはAIセキュリティである。ISO/IEC 42001は、ISO/IEC 27001などのISOマネジメントシステム規格に準拠したマネジメントシステム構造を採用しており、組織がAIガバナンスとセキュリティを相互に関連する企業規律として扱う傾向が強まっていることを反映している。AIが実運用環境に移行するにつれて、この焦点はますます重要になっている。 マッキンゼーが 1,993人の参加者を対象に実施した2025年のAIの現状に関する調査で...

#1158 - OIC 26.07 - Async Queue Depth の新しいサービス制限 (2026/07/30) https://niallcblogs.blogspot.com/2026/07/1158-oic-2607-new-service-limit-for.html はじめに Oracle Integration Cloud (OIC) では、非同期リクエストは、ファイア・アンド・フォーゲット型のメッセージキューイングメカニズムを使用して、クライアントとバックエンドプロセスを分離します。このパターンにより、スループットが最大化され、下流システムがトラフィックの急増から保護され、統合リソースが効率的に使用されます 。 貴重な情報ありがとうございます！ただし、サービス制限を導入いたしました。26.07リリース以降、この制限はOICインスタンスに割り当てられたメッセージパックの数に基づいています。 また、最近、新しいサービス指標である非同期キュー深度を導入しました。 これがあなたの監視ツールになります。 さて、新しいサービス制限に戻りましょう。実際の計算式は次のように構成されています。 1時間あたりのメッセージ数を10倍してください。それが、非同期キューの潜在的なサイズの上限値となります。 簡単な例を挙げると、私のOICインスタンスには1つのメッセージパックが割り当てられているので、これは5000×10に相当します。つまり、キューサイズの上限は5万となります。これは、通常の10倍のリクエストが急増しても対応できる、言い換えれば10時間分のバックログがある、ということです。 この上にバッファを追加することで、1メッセージパックのOICインスタンスの場合、50001番目のメッセージが拒否されないようにします。ただし、バッファに頼るのではなく、割り当てたメッセージパック数の制限に注意してください。 ご覧のとおり、上限は60万ですが、必要に応じて引き上げることも可能です。そのためには、Oracleに問い合わせ、サービスリクエスト（SR）を起票するなどの手続きが必要になります。 限界に達する OIC 26.07インスタンスでテストを実行しますが、その前に、 そのインスタンスの 非同期キュー深度サービスメトリックを確認しましょう。 ご覧のとおり、キューには何も入...

CISOは機械速度で責任を共有 (2026/07/30) https://www.ateam-oracle.com/ciso-perspectives-shared-responsibility-at-machine-speed 投稿者： Marcus D'Andrea AIが発見と活用の間のギャップを縮めると、共同責任はガバナンス上の課題ではなくなり、実行上の試練となる。 クラウド環境におけるセキュリティ対策の責任分担は依然として共通しているが、そのスピードは変化している。機械並みのスピードで脅威が迫る環境において、CISOはプロバイダーと顧客に対し、可視性、パッチ適用、制御、および回復力計画を、より迅速にビジネスリスクの低減へと結びつけることを求めている。 かつては、責任の分担は権限配分のモデルであった。しかし、機械的なスピードで処理されるようになると、それは信頼を維持するためのモデルへと変化する。 かつては責任の分担は境界線だった。今やそれはスピードテストだ。 長年にわたり、共同責任はアーキテクチャ図上の線として扱われてきた。プロバイダーは基盤となるサービスを保護し、顧客はそのサービスの構成、統合、運用方法を保護する。このモデルは今でも重要ではあるが、リスクの全体像を完全に表すものではなくなった。 AIは、脆弱性の発見、エクスプロイト分析、攻撃経路のマッピング、セキュリティテストを、ほとんどの組織が運用モデルを適応させるよりも速いスピードで加速させています。CISOにとって真の課題は、脆弱性が存在するかどうかだけではありません。企業がリスクを把握し、責任の所在を明確にし、迅速に対応し、機械のスピードで進行する脅威が技術的な弱点をビジネスの混乱に発展させる前に、自信を持って復旧できるかどうかが重要なのです。 この変化により、共有責任は静的な制御モデルから、リアルタイムの連携モデルへと移行する。もはや問題は、誰が制御権を握っているかだけではなくなる。攻撃者が発見した情報をインシデントに発展させる前に、両者が迅速に対応してリスクを軽減できるかどうかが問われるのだ。 オラクルと顧客の間の境界線は依然として重要である。 Oracleが提供するマネージドクラウドサービスにより、Oracleは堅牢なインフラストラクチャ、プラットフォーム保護、およびセキュリティ機能を...