はじめに

エンタープライズクラウド事業部の高橋です。

Oracle AI World 2026にて、「Accelerate Your AI Apps with Oracle True Cache [LRN6039]」のセッションに参加しましたので、その内容を紹介します。

セッション概要

Traditional caching improves performance but often shifts consistency, invalidation, and cache management into application code. Oracle True Cache eliminates this complexity with a SQL and object cache that remains automatically synchronized with Oracle Database. Learn how True Cache accelerates read-intensive workloads through automated data loading, continuous refresh, elastic scalability, and enterprise-grade security. Deploy it in OCI, other public clouds, hybrid environments, or on-premises to keep frequently accessed data close to applications. Explore how semantic caching with Oracle AI Vector Search can accelerate RAG and AI inference while keeping data fresh and consistent across multicloud environments.

従来のキャッシュ手法はパフォーマンスを向上させる反面、データの整合性維持、無効化、キャッシュ管理といった複雑な処理をアプリケーションコード側に持ち込んでしまうことが少なくありません。Oracle True Cacheは、Oracle Databaseと自動的に同期されるSQLおよびオブジェクトキャッシュを提供することで、こうした複雑さを解消します。Oracle True Cacheは、データの自動読み込み、継続的なリフレッシュ、柔軟なスケーラビリティ、そしてエンタープライズレベルのセキュリティを通じて、読み取り負荷の高いワークロードを高速化します。OCI、その他のパブリッククラウド、ハイブリッド環境、あるいはオンプレミス環境に導入することで、頻繁にアクセスされるデータをアプリケーションの近くに配置することが可能です。また、Oracle AI Vector Searchを活用したセマンティック・キャッシュ（意味的キャッシュ）により、マルチクラウド環境全体でデータの鮮度と整合性を保ちつつ、RAG（検索拡張生成）やAI推論を高速化する方法についてもぜひご確認ください。

セッション内容

本セッションは、汎用キャッシュ製品が開発者に課していた整合性維持・無効化・ウォームアップといった実装負担を、データベース自体にキャッシュ機能を統合することで解消するOracle True Cacheの仕組みを紹介するものでした。

従来のキャッシュが抱える課題

RedisやMemcachedのような汎用キャッシュをデータベースの前段に置く場合、キャッシュのウォームアップ、キャッシュミス時のデータベースへの再取得、キャッシュとデータベースの整合性維持を、いずれもアプリケーション側のコードで実装する必要があります。

また、こうした汎用キャッシュは文字列・数値・JSONなど単純なデータ型が中心で、リレーショナル・空間・グラフといったデータベース本来の多様なデータ型や、行レベルのセキュリティをそのまま引き継げない点も課題として挙げられていました。

Oracle True Cacheの仕組み

これらの課題に対応する機能として紹介されたのがOracle True Cacheです。

Oracle True Cacheは、ディスクを持たない特殊なデータベースインスタンスとして動作する、Oracle Database向けの読み取り専用（read-only）キャッシュです。プライマリデータベースの変更内容を物理レプリケーション（redo apply）によって自動的に反映するため、データ型・セキュリティ機能・スキーマ変更をキャッシュ側に個別実装することなく引き継げる点が特徴です。

Oracle公式ドキュメントでも「ほぼディスクレスな、プライマリデータベースの完全な読み取り専用レプリカ」と説明されています。

Oracle True Cacheへの接続は、プライマリデータベースに接続する場合と同じAPI・ドライバを使用します。そのため、アプリケーション側のコードを変更せずに導入できる点が強調されていました。

データの保存先はメモリだけでなく、ローカルのフラッシュストレージも利用できます。これにより、アプリケーションサーバーと同じ場所やネットワークの端、プライマリデータベースとは別のリージョンやクラウドなど、利用者が用途に応じて様々な場所にOracle True Cacheを配置できます。

技術的には、整合性維持というキャッシュ導入で最も苦労する部分をデータベース側に引き戻すという設計思想が明確で、既存のOracle Databaseユーザーであればキャッシュ専用の学習コストやAPIの差異を負わずに導入できる点は、大規模なOracle環境を持つ利用者にとって検討しやすい選択肢だと感じました。

残る課題：強い整合性が求められるワークロードへの対応

一方で、決済処理のように、更新直後のデータを別の参照先から読んだ際に古い値が返ってくることが許容できないワークロードでは、プライマリデータベースとOracle True Cache間にわずかなレプリケーション遅延があるだけでも問題になり得る、という課題が挙げられていました。

この課題に対しOracle側からは、変更内容を通知する「notification directive」という仕組みや、キャッシュへの同期書き込み、SCN（System Change Number）の差分といった追加メタデータの提供といった対応策が議論されていました。これらはいずれも開発中または検証段階の機能であり、本番環境での採用はまだ先になる見込みであると説明されていました。

今後の拡張予定

Oracle True Cacheのウォームアップについては、プライマリデータベースのバッファキャッシュのスナップショットを取得してOracle True Cache側に転送し、起動時に読み込ませる仕組みが実装・検証済みとのことです。また、リモートリージョンのキャッシュミスを近隣リージョンのOracle True Cacheから解決する仕組みや、Oracle True Cache同士をカスケード接続する構成、Oracle True Cacheをシャーディングする機能なども、開発中の取り組みとして紹介されていました。

まとめ

本セッションは、キャッシュ導入に伴う整合性・無効化・ウォームアップの実装負担をアプリケーション側からデータベース側に引き戻すOracle True Cacheの設計思想を、開発者自身の説明をもとに紹介するものでした。

決済処理のような強い外部整合性が求められる領域では、現時点のOracle True Cacheでも数秒未満のレプリケーション遅延が残り、同期書き込みなどの対応策は開発中・検証段階にとどまっている点は、導入を検討する際に踏まえておくべき留意点だと感じました。

なお、同期書き込みや通知機能などの対応策は、セッション内で述べられていたとおり開発中・検証段階の内容であり、提供時期や仕様は今後変更される可能性がある点に留意が必要です。

今後の発表を楽しみに待ちたいと思います！