Autonomous Transaction Processing(ATP)とAutonomous Data Warehouse(ADW)は、別々の製品ではありません。Oracle Autonomous AI Databaseを作成するときに選ぶ「ワークロードタイプ」の違いです。2025年10月14日の名称変更で、ATPはAutonomous AI Transaction Processingに、ADWの役割は後継のAutonomous AI Lakehouseに移りました。
この記事では、Oracleの公式ドキュメントと価格表(Global Price List 2026年10月8日版)をもとに、両者の違いを料金・実装・選び方の順で整理します。先に結論を言うと、ECPUの時間単価は両者で同額です。差がつくのはストレージの単価と最小単位、それに既定の表圧縮と並列度ヒントの扱いです。
まとめ
- ATPとADWは同じAutonomous AI Databaseのワークロードタイプです。2025年10月14日以降、ADWの後継はAutonomous AI Lakehouseです。
- ECPU単価はTransaction ProcessingもLakehouseも1 ECPUあたり52.08円/時(USD 0.336)で同じです。
- ストレージはTransaction Processingが30.2715円/GB月(最小20GB)、Lakehouseが4.6345円/GB月(1TB単位)。掲載単価でTPの確保容量とLakehouseの最小1TBのストレージ料金だけを比べると、約157GBで逆転します。実データ量だけで総費用は決まりません。
- Lakehouseは全表がハイブリッド列圧縮で、SQLの並列度ヒントは既定で無視されます。更新の多い表や、ヒントで性能を作り込んだSQLとは相性がよくありません。
- 小規模な機能確認にはAlways FreeやDeveloper版を選べます。ただし、本番規模の負荷試験やサイジングには通常の有償インスタンスを使います。
- 可用性99.995%はAutonomous Data Guardを有効にした場合の値です。無効なら99.95%です。
ATPとADW(Lakehouse)の関係と2025年の名称変更
略称の対応と選べる4つのワークロード
読み方は「オートノマス・データベース」です。ADBはAutonomous AI Database全体を指し、ADB-Sはそのサーバーレス版、ATPとADWはワークロードタイプの略称です。公式ドキュメントのワークロード解説によると、現在選べるのはLakehouse、Transaction Processing、JSON Database、APEX Serviceの4種類です。JSON Databaseは、JSONコレクション以外のデータを20GBまでしか置けない点を除けば、Transaction Processingと同じ機能を持ちます。
プロビジョニング、パッチ適用、バックアップといった運用の自動化は、どのワークロードでも共通です。違いが出るのは、データの持ち方と処理のさばき方、そして料金です。
選び直しもできます。ワークロードタイプを変えるクローンで、LakehouseからTransaction Processing、その逆の双方向に移れます。ただし、既存オブジェクトのデータディクショナリ、オプティマイザ統計、圧縮はそのまま引き継がれ、新しい既定値が効くのはクローン後に作った表だけです。既存表にも移行先の圧縮設定を適用したい場合は、対象表の再編成と性能検証を計画してください。
2025年10月14日の名称対応表
| 2025年10月13日まで | 2025年10月14日以降 |
|---|---|
| Oracle Autonomous Database | Oracle Autonomous AI Database |
| Oracle Autonomous Transaction Processing | Oracle Autonomous AI Transaction Processing |
| Oracle Autonomous Data Warehouse | Oracle Autonomous AI Lakehouse(後継として追加) |
| Oracle Autonomous JSON Database | Oracle Autonomous AI JSON Database |
ADWの行だけ変化の性質が違います。2025年10月のリリースノートは、他の3つを「AI」を挟んだ改称として書く一方、Lakehouseについては「Autonomous Data Warehouseの次世代として追加され、全機能を引き継ぐ」と書いています。Apache Icebergなどのオープン技術との統合を強化した後継製品という扱いです。他社クラウドのオブジェクトストレージを外部表で読む機能自体は、Lakehouseで初めて追加されたものではありません。
既存のデータベースを作り直す必要はありません。変わったのは表示名です。ただし、バージョン表記には食い違いがあります。同じリリースノートによると、APIで dbVersion に23aiを指定でき、REST APIも23aiを返しますが、OCIコンソールには26aiと表示されます。Oracle Database本体の23aiと26aiの関係はOracle 23aiは26aiへ:オンプレ版の提供状況・23cとの違い・Free版の制限で整理しています。
ATPとLakehouseの料金比較:ストレージ単価と課金単位の差
Global Price List(2026年10月8日版)の単価
用途の違いに加え、ここではECPUとストレージの単価を比較します。下の表は、Autonomous AI Databaseの価格ページが表示に使っている公開価格データ(2026年11月2日更新・同日取得)から、サーバーレスで使う品目を抜き出したものです。米ドルの値はGlobal Price List(PDF・2026年10月8日版)の23ページと一致します。品目と課金単位の対応は、公式ドキュメントのCompute Modelsで確認しました。
| 品目 | 品目番号 | 円 | USD | 単位 |
|---|---|---|---|---|
| Transaction Processing ECPU | B95702 | 52.08 | 0.336 | ECPU・時 |
| Lakehouse ECPU | B95701 | 52.08 | 0.336 | ECPU・時 |
| ECPU(BYOL、両方共通) | B95704 / B95703 | 12.5085 | 0.0807 | ECPU・時 |
| Transaction Processingのストレージ | B95706 | 30.2715 | 0.1953 | GB・月(最小20GB) |
| Lakehouseのストレージ | B95754 | 4.6345 | 0.0299 | GB・月(1TB単位) |
| バックアップ(両方共通) | B95754 | 4.6345 | 0.0299 | GB・月 |
| Developer版 | B110316 | 6.0605 | 0.0391 | インスタンス・時 |
コンピュートの単価は同じです。違うのはストレージで、Transaction ProcessingのGB単価はLakehouseの約6.5倍あります。ECPUの最小値は両者とも2で、1単位ずつ増やせます。なお、同じページでOracleはOCPUを「retired(退役済み)」と書いています。課金概要のページには「Legacy」という表記が残っていますが、新規作成でOCPUは選べません(2025年5月にプロビジョニングとクローンの選択肢から削除)。
月額の試算と約157GBの損益分岐
ライセンス込みの2 ECPU・月730時間稼働で比較します。表の「確保容量」は元データのサイズではなく、索引・作業領域なども考慮して確保する容量の想定です。TPはその容量をGB単位、LakehouseはTB単位で切り上げて課金される条件とし、バックアップ・自動スケーリング・税は含めません。圧縮率や必要なECPU数の差も計算対象外です。
| 確保容量 | TPのストレージ | Lakehouseのストレージ | 安い方 |
|---|---|---|---|
| 20GB | 605円 | 4,746円(1TB) | TP |
| 100GB | 3,027円 | 4,746円(1TB) | TP |
| 157GB | 4,753円 | 4,746円(1TB) | ほぼ同額 |
| 500GB | 15,136円 | 4,746円(1TB) | Lakehouse |
| 1TB | 30,998円 | 4,746円 | Lakehouse |
| 3TB | 92,994円 | 14,237円 | Lakehouse |
コンピュートは両者とも 2 × 52.08円 × 730時間 = 約76,037円/月で、ここは差がつきません。Lakehouseの1TB(1,024GB)は4,746円なので、Transaction Processingで同じ金額になるのは 4,746 ÷ 30.2715 = 約157GBです。確保する容量がこれより大きいなら、使わない領域が残っても1TB単位のLakehouseのほうがストレージ料金は安くなります。
Lakehouseの最小単位が1TBであることだけを見て「1TB未満ならATPが安い」と判断すると、GB単価の6.5倍の差を見落とします。もっとも、この試算でATPとLakehouseを入れ替えてよいのは、次章で見る実装上の差が問題にならない場合に限られます。
自動スケーリングとバックアップの追加料金
試算より請求が膨らむ要因は2つあります。1つ目はコンピュートの自動スケーリングです。自動スケーリングの解説によると、作成時の既定で有効になっており、基本ECPU数の最大3倍まで使い、使った分が課金されます。2 ECPUの構成なら、最大で6 ECPU相当の約22.8万円/月まで振れる計算です。
2つ目はバックアップです。保持期間の既定は60日(1〜60日で変更可)で、ECPUモデルではデータベースのストレージとは別に課金されます。保持期間の変更手順のページには、60日分でデータ容量の3〜4倍、30日分で2〜3倍、15日分で1〜2倍が目安とあります。バックアップの単価はどちらのワークロードも4.6345円/GB月なので、Transaction Processingの500GBを60日保持すると、バックアップだけで約7,000〜9,300円/月が加わります。復旧したい時点の範囲を決めて、保持期間を短くするのが一番確実な節約です。
実装の違い:既定の圧縮と並列度ヒント
既定の表圧縮とUPDATE・MERGEの扱い
Lakehouseワークロードの仕様では、全表にハイブリッド列圧縮が既定でかかり、Oracle AI Database Result Cacheも全SQL文で既定有効です。DBMS_CLOUDによるダイレクトパスロードで、圧縮率と読み取り性能の両方を取る設計です。一方、Transaction Processingの仕様では圧縮は既定で無効で、表に圧縮句を書いたときだけ従います。
Lakehouseで問題になるのは更新です。Oracleは、圧縮された表にUPDATEやMERGEを流すと対象行の圧縮率が下がって表が膨らみ、非圧縮の表より遅くなりうると書いています。表の大部分を頻繁に更新するなら、その表だけ非圧縮で作るよう案内しています。
CREATE TABLE sales (
prod_id NUMBER NOT NULL,
amount_sold NUMBER(10,2) NOT NULL
) NOCOMPRESS;
-- 後から圧縮し直す(参照中の問い合わせは止まらない)
ALTER TABLE sales MOVE COLUMN STORE COMPRESS FOR QUERY HIGH;
ロード用の中間表には FOR STAGING 属性が使えます。この属性を付けた表は圧縮が一切禁止され、統計は収集されずに動的サンプリングで代替され、DROPするとごみ箱を通らずに即時に消えます。
並列度ヒントの扱いと解除
データベース・サービスの解説によると、SQLに書いた並列度ヒントは、Lakehouseでは既定で無視され、Transaction Processing、JSON、APEXでは尊重されます。Lakehouseでヒントを効かせるには、セッション単位で解除します。
ALTER SESSION SET optimizer_ignore_parallel_hints = false;
エラーにならない点が厄介です。ヒントで実行計画を作り込んだアプリケーションをLakehouseへ載せると、想定と違う並列度のまま黙って動きます。データベース全体の設定を変更する場合は、ALTER SYSTEMでOPTIMIZER_IGNORE_PARALLEL_HINTSをFALSEに設定できます。
Oracle Database 19cを選んだ場合は、並列DMLにも制約があります。並列DMLを実行した表に、コミットかロールバックの前に再アクセスすると ORA-12838 か ORA-12839 になります。この制約はOracle AI Database 26aiでなくなりました。
5つの接続サービスと並列度・同時実行数
並列度は、どの接続サービスにつなぐかで決まります。サービスは両ワークロードともTPURGENT、TP、HIGH、MEDIUM、LOWの5つです。LakehouseでTPとTPURGENTが使えるようになったのは2025年10月からで、それ以前のADWにはHIGH・MEDIUM・LOWしかありませんでした。古いウォレットの tnsnames.ora にTPの接続先が見当たらないときは、ウォレットを取り直します。
| サービス | CPU配分 | 並列度(ECPU) | 同時実行(自動スケール無効/有効) |
|---|---|---|---|
| TPURGENT | 12 | 手動で指定 | セッション上限まで |
| TP | 8 | なし | セッション上限まで |
| HIGH | 4 | 基本ECPU数÷2(切り捨て) | 3 / 9 |
| MEDIUM | 2 | 4〜7 ECPUは÷2(切り捨て)、8以上は4 | 基本ECPU×0.25125 / ×0.75375(各切り捨て) |
| LOW | 1 | なし | セッション上限まで |
セッション上限は基本ECPU数の75倍で、最小の2 ECPUなら150です。この表が当てはまるのは4 ECPU以上の構成だけで、それ未満では手動で並列度を指定しない限り並列実行は使えません。また、並列問合せ・並列DDL・並列DMLが既定で有効なのはHIGHとMEDIUMだけです。夜間バッチをTPサービスに流したまま「並列が効かない」と悩むのは、典型的な設定ミスです。
ATPとLakehouseの選び方と、選んではいけない場面
判断の順番:更新の多さ、データ量、外部データ
最初に見るのは更新の多さで、容量はその次です。
- 同じ行を何度も更新する業務データ(受注、在庫、会員情報など)が中心なら、Transaction Processingを選びます。Lakehouseの既定の列圧縮と正面からぶつかります。
- データは追記が中心で一括ロードし、集計で読むなら、確保する容量を見ます。約157GBを超えるなら、ストレージ単価の安いLakehouseが有利です。下回る場合も、ストレージ料金の差は最大で月4,141円(20GBのとき)です。
- Icebergテーブルや他社クラウドのオブジェクトストレージ上のデータを参照する場合は、必要な形式・カタログへの対応を確認します。外部表による参照はATPでも可能なので、この要件だけではLakehouseに限定できません。Lakehouseの説明で新機能として挙がっているのは、Databricks Unity・AWS Glue・Snowflake Polarisのメタデータをまとめるカタログ、Icebergテーブルのキャッシュ、問い合わせ中に資源を広げるData Lake Acceleratorです。これらを使う設計なら、Lakehouseを選びます。
Transaction Processingは、トランザクション処理と分析の同時実行を想定範囲に含めています。小さな業務システムで集計クエリを流すこと自体は問題になりません。
Lakehouse移行とAlways Freeでの性能検証の失敗条件
1つ目は、並列度ヒントを埋め込んだ既存SQLを、そのままLakehouseへ移す場合です。前述のとおりヒントは黙って無視されます。移行するなら性能検証をやり直す前提で計画してください。オンプレミスのOracleから移すか、他のDBへ乗り換えるかの比較はOracleからPostgreSQLへの移行手順|互換性差分とora2pg・DMSの使い分け、移行可否の判断基準にまとめています。
2つ目は、Always Free環境で本番のサイジングをする場合です。Always Freeはリソースが固定でスケールできず、並列実行の条件(4 ECPU以上)も満たしません。そこで測った数値は本番の根拠になりません。既存システムのデータベース設計や移行計画まで含めて相談したい場合は、データベース設計・移行支援で受け付けています。
検証環境の選び方:Always FreeとDeveloper版
Always Freeの制限とリージョンの食い違い
Always Freeのページによると、1テナンシあたり最大2インスタンス、各20GB、同時30セッションまで使えます。4つのワークロードはどれも選べるので、ATPとLakehouseを1つずつ作り、既定の圧縮やサービス名を見比べる用途に向いています。APEXやDatabase Actionsへの同時アクセスは3〜6人程度が目安とされています。
制約もあります。手動バックアップ、長期バックアップ、過去時点へのリストア、Autonomous Data Guard、プライベート・エンドポイントは使えません。7日間操作がないと自動停止し、停止・非アクティブ状態が累計90日に達すると削除されることがあります。この計測は、停止したデータベースを起動するとリセットされます。有償に切り替えると、LakehouseもTransaction Processingも4 ECPU・1TBで払い出されます。前章の単価で計算すると、Transaction Processingの1TBはストレージだけで約3.1万円/月です。OCIの無料枠全体はOracle Cloud Free Tierの無料枠|A1は2 OCPU・12GBに半減、登録手順と容量不足の回避【2026年10月】で扱っています。
26aiでAlways Freeを作れるリージョンは、Oracleの文書の間で記述が食い違っています。Always Freeのページは東京(NRT)を含む8リージョンに限定していますが、26aiの注記ページは「Bogota、Saudi Arabia Central、Singapore Westを除く全商用リージョン」としています。東京はどちらの記述でも対象です。ホーム・リージョンが大阪のテナンシは、作成画面で26aiが選べるか先に確かめてください。Always Freeはホーム・リージョンにしか作れません。
Developer版の固定料金と開発・検証向けの制限
Always Freeの制約が厳しく、有償版の2 ECPUでは高すぎるという場合は、Autonomous AI Database for Developersがあります。4 ECPU・約20GBの固定構成で、ECPUとストレージ込みで6.0605円/時(730時間で約4,424円/月)です。バックアップとリストアは使えますが、バックアップストレージは別料金です。パッチ適用の日程は通常の有償版と同じです。
本番用途には推奨されません。Oracleが示すSLO(目標値)は99.5%、重大度1のサポート・リクエストも受け付けていません。同時セッションも30が上限で、スケールするには通常の有償インスタンスへのアップグレードが必要です。
バージョンと可用性の前提
19cと26ai、23aiが使えなくなる時期
作成時に選べるのはOracle Database 19cとOracle AI Database 26aiの2つです。OCI Python SDKのリファレンスには、2026年12月から db_version に23aiを指定できなくなると明記されています。TerraformやSDKのテンプレートに23aiを書いたままなら、11月中に19cか26aiへ書き換えてください。同じリファレンスは、新規作成では19cか26aiを使うよう勧めています。
99.995%の条件と、障害時の復旧時間の目標
Oracleが掲げる99.995%の可用性は、ATPの製品ページにも注記があるとおり、Autonomous Data Guardを有効にした場合のSLAです。無効なら99.95%です。
復旧時間の目標も構成で変わります。SLOのページによると、ローカルのスタンバイならRTO 2分・RPO 0、リージョンをまたぐスタンバイならRTO 10分未満・RPO 1分です。スタンバイを持たずバックアップから復旧する場合は「1時間+5TBごとに1時間」で、5TBのデータベースでは復旧時間の目標値が最大2時間です。実際の復旧時間の上限を保証する値ではありません。要件にRTOの数字があるなら、ワークロードタイプより先にスタンバイの有無を決めてください。
よくある質問
ATPとADWはどちらが安く始められますか?
掲載単価でATPの確保容量とLakehouseの最小1TBのストレージ料金を比べると、約157GBで逆転します。ただし総費用は必要なECPU数、圧縮後の容量、バックアップなどによって変わります。ECPU単価はどちらも52.08円/時で同じで、差はストレージ単価だけです。Transaction Processingは30.2715円/GB月で20GBから、Lakehouseは4.6345円/GB月で1TB単位です。
Autonomous AI Transaction Processingは以前のATPと別の製品ですか?
同じ製品です。2025年10月14日に名称へ「AI」が入っただけで、既存のデータベースを作り直す必要はありません。別物として扱われるのはADWで、後継のAutonomous AI Lakehouseが追加される形になりました。
LakehouseでOLTPのアプリケーションを動かせますか?
接続はできます。2025年10月からLakehouseでもTPとTPURGENTのサービスが使えるようになりました。ただし既定の列圧縮は更新に弱く、並列度ヒントも既定で無視されます。更新の多い表は NOCOMPRESS で作るなど、手当てが前提です。
選べるOracle Databaseのバージョンは?
Oracle Database 19cとOracle AI Database 26aiです。APIでは今も23aiを指定できますが、作られるのはコンソール上で26aiと表示されるデータベースです。2026年12月以降は23aiを指定できなくなります。
ADWだけで検索すると別の情報が出てくるのはなぜですか?
ADWという略称は、社名やTeradataのActive Data Warehouseなどにも使われているためです。Oracleのサービスを調べるときは「Oracle ADW」「Autonomous Data Warehouse」、または現行名の「Autonomous AI Lakehouse」で検索してください。