Oracle Cloud Infrastructure Blog(翻訳)

AzureへのOracle Exascaleのデプロイ (2026/05/01) https://www.thatfinnishguy.blog/2026/05/01/deploy-oracle-exascale-in-azure/ 投稿者： Simo Oracle Exascaleについて既にご存知ですか？あるいは、既にどこかに導入済みでしょうか？Oracleのマルチクラウドソリューションを使えば、AzureにもExascaleを導入できます！ Exascale技術には非常に期待しているのですが、普及の遅さにはがっかりしています。導入を躊躇する要因の一つはサポート体制にあると思います。確かにOracleはExascaleで19cのサポートを開始しましたが、19cで使用するとストレージ機能の多くが失われてしまいます。 ですから、より多くのユーザーがOracle Databaseの26aiバージョンにアップグレードするにつれて、近い将来、エクサスケールクラスタやストレージを利用するユーザーが増えることを期待しています。 Exascaleの詳細については、こちらをご覧ください： https://docs.oracle.com/en/engineered-systems/exadata-database-machine/exscl/what-is-oracle-exascale.html 私の意見では、Exascaleは、共有Exadataインフラストラクチャ上のExadata VMクラスタのようなもので、特にストレージ面でいくつかの優れた新機能が追加されていると考えることができます。Exascaleテクノロジーを使えば、データベースのクローン作成が非常に高速になります！ また、Exadata Infrastructureをお持ちの場合は、Exascaleストレージを使用したクラスタをデプロイできます。 OCIやAzureにExadata VMクラスターをデプロイした経験があれば、前提条件の面からExascaleクラスターのデプロイはほぼ同じプロセスです。 この記事では、既にプライベートオファーを承諾し、OCIテナンシーをリンク済みであるAzureサブスクリプションにおけるAzure側からのデプロイに焦点を当てます。ドキュメントに記載されているすべての前提条件タスクは完了...

研究コンプライアンスにおけるOCI生成AIエージェントの大学のユース・ケース (2026/05/01) https://blogs.oracle.com/ai-and-datascience/oci-ai-research-compliance 投稿者： Chris Rach  | Principal Cloud Architect 研究大学は、IRB（治験審査委員会）のプロトコル、利益相反の開示、輸出管理、研究セキュリティ、スポンサー管理など、コンプライアンスに関する業務量がますます増加している。多くの場合、必要なガイダンスは既に存在している。より難しい問題は、研究者や管理者が適切なポリシーを、適切な情報源から、適切なタイミングで見つけられるように支援することである。 NIHの助成金更新を準備している主任研究者を例に考えてみましょう。彼女は最近、あるスタートアップ企業の株式を少額取得しました。そのため、申請前にその株式保有が開示義務を生じさせるのか、関連する管理手順が必要なのか、そしてその変更が有効なIRBプロトコルに影響を与えるのかを知る必要があります。その答えは、機関の利益相反に関する方針、IRBの手続き、スポンサーのガイダンス、そして各部署固有のワークフローなど、様々な情報源に存在する可能性があります。そして、実際に役立つほど迅速にその答えを見つけることが、しばしば真の課題となるのです。 このアクセス上の問題は、業務運営の大きな負担となっている。コンプライアンス部門や研究管理部門は、人員増を伴わないまま、より多くの業務をサポートするよう求められている一方、研究者は依然としてタイムリーで使いやすいガイダンスを必要としている。問題は、単にポリシーの内容の量にあるのではなく、その内容がハンドブック、ウェブページ、PDF、スポンサー通知、部署固有の手順書など、様々な媒体に分散していることにある。 これは、検索機能を強化した生成機能の、高等教育における実用的なユースケースです。OCI生成AIエージェントを使用することで、教育機関は引用文献に基づいたアシスタントを構築し、機関の方針と承認された出典資料をあらゆる回答の中心に据えながら、ユーザーがより迅速に回答を見つけられるように支援できます。 研究者が実際に尋ねるコンプライアンスに関する質問 現代の大学は、複数の...

エンタープライズAIのエビデンスと制御レイヤー (2026/05/01) https://blogs.oracle.com/ai-and-datascience/evidence-control-layer-enterprise-ai 投稿者： Kishore Pusukuri モデルへのアクセスから統制された生産まで 生成AIの第一期は、モデルへのアクセスによって特徴づけられました。 企業は、スケーラブルな推論、管理されたモデルエンドポイント、基盤モデルへの安全なアクセス、そして迅速な開発者による実験パスを必要としていました。この時代は重要な点を証明しました。それは、組織が大規模な言語モデルを企業ワークフローに取り込み、大規模な推論を実現できるということです。 しかし、モデルへのアクセスだけではもはや十分ではない。 チームがデモや概念実証の段階を過ぎると、別の壁にぶつかります。成功した概念実証と実運用レベルのエージェントとの間のギャップは、モデルのパラメータにあるのではなく、モデルを取り巻くエビデンスおよび制御レイヤーの欠如にあるのです。 その層は、何が起こったのか、なぜ起こったのか、それは正しく安全だったのか、この行動は許可されていたのか、そして、影響が出る前に故障を防ぐことができたのか、という4つの生産上の疑問に答えるものです。 明確な答えがない限り、エージェント型AIの信頼性、運用性、拡張性は依然として低いままである。 企業が質問に答えるだけのAIアシスタントから、ツール呼び出し、ワークフロー実行、記録更新、エージェント調整、予算の動的な消費といったアクションを実行するAIシステムへと移行しているため、この問題への対応は喫緊の課題となっています。もはや、モデルが能力を備えているかどうかだけが問題ではありません。実行が進行中であっても、プラットフォームがエージェントの行動を観測可能、評価可能、管理可能、コスト制約付き、監査可能にできるかどうかが重要なのです。 プロトタイプと製品版の間の確率的ギャップ 従来のソフトウェアは概ね決定論的です。つまり、同じコードパスと入力が与えられれば、エンジニアは通常、次に何が起こるかを推論できます。本番運用はこの前提に基づいて構築されており、ログ、メトリクス、アラート、テスト、SLO、デプロイメントゲート、インシデント対応などが...