OCI Autonomous Database実践Vol1 Always Free作成とAPEX

1. この記事について — なぜOCI Autonomous Databaseか

1-1. 本記事のゴール

本記事は、「OCI Autonomous Database実践」シリーズの第1弾として、Always Free枠でAutonomous AI Databaseを実際に作成し、接続してAPEX・Database Actionsまで一気通貫で触ることを目的としています。

本記事を読み終えると、次の状態になることを目指しています。

• Autonomous Databaseは、AWSのRDSやAuroraとの共通点・相違点を、AWS実務者の言葉で説明できる
• Always Free枠のAutonomous AI Databaseを実際に作成し、Database ActionsとAPEXへ接続できる
• Always Free枠特有の制約(オートスケール不可・home region限定・自動停止/削除ルール・HTTPインターフェースのレート制限)を把握し、無料枠のまま検証を続けるか有償枠へ切り替えるかを自分で判断できる

なお、本記事では「Always Freeでの作成・接続・APEX実践」に加え、有償枠でのオートスケール設定手順と課金試算(§5)も扱います。ただしAlways Free枠自体でのオートスケール実演は、後述する理由により行いません。

本記事の対象範囲を明確にするため、扱わない内容もあらかじめ整理しておきます。

• Terraform等のIaCによるAutonomous Databaseのプロビジョニング(別記事で扱う可能性があります)
• Autonomous Data Guardや専用インフラ(Dedicated Exadata Infrastructure)構成といった、Always Free枠では利用できない高度な構成

本記事はあくまで、Always Free枠の範囲でAutonomous Databaseの基本的な使い方と制約を押さえることに絞って解説します。

1-2. 読者像

本記事は、AWSでRDSやAurora、あるいはDynamoDBといったマネージド型データベースサービスの運用経験をお持ちの方で、OCIのデータベースサービスには初めて触れる方を主な読者として想定しています。

「Autonomous」という名前から、単に自動運用機能が強化されたRDSのようなものだろうと想像して読み進めると、Always Free枠特有の細かな制約に戸惑う場面が少なくありません。特に次のような疑問を持つ方に向けて、本記事は具体的な答えを用意しています。

• Autonomous DatabaseはRDSに近いのか、Auroraに近いのか、それとも全く別物なのか
• 「無料でオートスケールも試せる」と思って作成したら、実際には固定リソースだったという誤解をしていないか
• 東京リージョンで作成したいが、home regionの制約で思わぬ落とし穴にはまらないか
• APEXやDatabase Actionsという聞き慣れないツールが、実際どのような画面・操作感なのか

なお、本記事は「OCI入門シリーズ」のVol1(テナンシ・コンパートメント・Always Free枠の全体像)を読了済みであることを前提としていますが、該当記事の要点は本章および§2で必要な範囲を補足しますので、未読の方でも読み進めていただけます。

また、Oracle Databaseそのもの(オンプレミスでの利用経験やSQL*Plus等のツール)に詳しい必要はありません。本記事はAWSでのマネージドデータベース運用経験を出発点とし、Oracle Database固有の知識を前提とせずに読み進められるよう構成しています。

OCIアカウント自体をまだ持っていない方は、先にOCI入門シリーズVol1を参照し、テナンシのサインアップとホームリージョンの選択を済ませておくことをお勧めします。

1-3. Autonomous Databaseとは — AWSのRDS/Auroraとの違い

Autonomous Database(現行名称: Autonomous AI Database)は、Oracle Databaseをベースとした、パッチ適用・チューニング・バックアップ・スケーリングといった運用作業をOracle Cloud Infrastructure(OCI)側が自動化するマネージド型データベースサービスです。ワークロードタイプとして、Transaction Processing(旧称ATP: Autonomous Transaction Processing)、Lakehouse(旧称ADW: Autonomous Data Warehouse)、JSON、APEXの4種類が用意されています。

AWSのRDSやAuroraと比較する際にまず押さえておきたいのは、「自動化の範囲」の違いです。RDSはOSパッチやバックアップの自動化を提供しつつも、インスタンスクラスの選定やパラメータグループのチューニングは利用者側の責務として残ります。AuroraはRDSよりもストレージ層の自動スケーリングが進んでいますが、それでもコンピュートのインスタンスクラス選定やIndex設計・チューニングは利用者が担います。

一方Autonomous Databaseは、コンピュート/ストレージのオンライン・スケーリング、暗号化、脅威検知、パフォーマンスチューニング、パッチ適用までを自動化の対象としており、「マネージドの一段先」を志向したサービスです。言い換えれば、AWSでRDSの次にAuroraがあるとすれば、Autonomous Databaseはさらにその先にある、運用のほぼすべてを自動化する設計思想のデータベースサービスです。この設計思想は、RDS/Auroraには存在しない概念だといえます。

この表が示す通り、Autonomous Databaseの最大の特徴は「運用自動化の範囲の広さ」と「APEX・Database Actionsという開発ツールが標準搭載されている」という2点です。

具体的な場面を想定すると、この違いがイメージしやすくなります。例えば、AuroraでRDBを運用しているチームが「簡単な業務アプリのCRUD画面をすぐ作りたい」と考えた場合、AWSではAurora単体だけで完結せず、別途EC2やLambda、APIGatewayなどを組み合わせてアプリケーション層を構築する必要があります。一方Autonomous Databaseであれば、データベース作成と同時に有効化されるAPEXを使い、ブラウザ上でテーブル定義から簡単な画面まで、追加のコンピュートリソースを構築せずに作成できます。この「データベースに開発ツールが組み込まれている」という点も、RDS/Auroraにはない設計上の違いです。

もう一つの違いとして、Autonomous Databaseは「サーバーレス」という言葉が使われる場合でも、AWSのAurora Serverlessとは前提が異なる点にも触れておきます。Aurora Serverlessはコンピュートキャパシティを自動増減させる従量課金モデルですが、Autonomous Database Serverlessは、コンピュート・ストレージのプロビジョニングと管理をOCI側が肩代わりする「インフラ管理からの解放」を指す言葉として使われています。両者とも「サーバーレス」を名乗りますが、指し示す自動化の対象が異なる点は覚えておくとよいでしょう。

次節では、これらの特徴を踏まえた本記事の差別化軸を整理します。

1-4. 本記事の差別化軸

Autonomous Databaseを扱う入門記事の多くは、Always Free枠での作成手順のみを紹介して終わるか、逆に有償枠を前提としたオートスケールなどの高度な機能紹介に終始しがちです。本記事は、次の3つの軸で差別化を図ります。

1. AWSエンジニア向けのRDS/Aurora対比レンズ: §1-3で見た通り、Autonomous Databaseは「自動運用がRDS/Auroraより進んでいる」というだけでなく、そもそもRDS/Auroraには存在しない設計思想を持つサービスとして捉えます。
2. 作成→接続→Data Studio/APEXの一気通貫実践: Always Free枠でのインスタンス作成だけで終わらせず、実際にDatabase ActionsやAPEXへ接続し、簡単な操作まで実践します(§3〜§4)。
3. 無料枠制約の「落とし穴」としての明示: Always Free枠には、オートスケール不可・home region限定・自動停止/削除ルールといった、事前に知らないとハマりやすい制約が複数存在します。本記事はこれらを§2で正面から扱い、無料枠の限界を理解した上で有償枠へ進む判断材料を提供します。

1-5. 本記事の位置づけ — OCI入門シリーズからの接続

本記事は、「OCI入門シリーズ」Vol1(テナンシ・コンパートメント・リージョン・Always Free枠)が予告していた「次巻以降のハンズオン」を、Autonomous Databaseというサービスに絞って履行する記事という位置づけです。OCI入門シリーズVol1は、Always Free枠のデータベースリソースとしてAutonomous Databaseの存在を紹介するだけにとどまり、実際の作成手順やAPEXでの操作には立ち入っていませんでした。

本記事はその続きとして、Autonomous Databaseに特化した実践シリーズの第1弾に位置づけられます。OCI入門シリーズで学んだコンパートメントやホームリージョンの考え方は、本記事のAlways Free枠作成手順(§3)でもそのまま前提知識として使います。

1-6. 用語整理 — Autonomous AI Database・ADB・ATP・ADWの呼び方

Autonomous Databaseに関する用語は、Oracleの製品リブランディングにより短期間で変化してきた経緯があります。本記事および本シリーズでは、混乱を避けるため呼び方を次のように整理します。

• 現行の正式名称: Autonomous AI Database(ワークロードタイプとしてTransaction Processing・Lakehouse・JSON・APEXの4種類を持つ総称)
• 旧称ATP(Autonomous Transaction Processing): 現行のワークロードタイプ「Transaction Processing」に相当する旧呼称
• 旧称ADW(Autonomous Data Warehouse): 現行のワークロードタイプ「Lakehouse」に相当する旧呼称
• 総称としてのADB(Autonomous Database): リブランディング前から使われてきた総称で、公式ドキュメントでも文脈により引き続き使用されています

検索エンジンで情報を探す際は、依然として「ADB」「ATP」「ADW」といった旧称での検索ボリュームが大きく残っています。本記事では、本文中は現行名称のAutonomous AI Database(または単にAutonomous Database)を主に使用しつつ、読者が旧称で検索してきた場合にも迷わないよう、初出箇所で旧称を併記する方針を取ります。

なお、本記事が扱うデータベースエンジンの最新バージョンはOracle AI Database 26ai(2026年7月時点)です。バージョンの選択肢としては、従来のOracle Database 19cも引き続き選択可能です。

→ OCI入門 Vol1: テナンシ・コンパートメント・リージョンとAlways Free枠

それでは、まずAlways Free枠のAutonomous AI Databaseが具体的にどのような制約を持つのか、§2で詳しく見ていきましょう。

2. Always Free ADBの仕様と制約 — 無料枠の「落とし穴」を先に知る

Always Free枠のAutonomous AI Databaseは、無料である代わりにいくつかの重要な制約を持ちます。この制約を知らずに設計・検証を始めると、「オートスケールを試そうとしたらできなかった」「セッションが急に切れた」「気づいたらインスタンスが削除されていた」といったつまずきにつながります。本章では、公式ドキュメント(取得日: 2026年7月25日)に基づき、これらの制約を「落とし穴」として正面から整理します。

2-1. 固定リソース仕様 — CPU・ストレージ・同時セッション数

Always Free枠のAutonomous AI Databaseインスタンスは、次の固定リソースで提供されます。

公式ドキュメントには「Always Free Autonomous AI Databases cannot be scaled manually or automatically beyond the fixed resource restrictions described earlier.」と明記されており、Always Free枠のインスタンスは、手動・自動のいずれの方法でもスケールできません。「Always Freeで作成してから、必要に応じてオートスケールを試す」という発想はそもそも成立しない点を、作成前に押さえておく必要があります。

同時セッション数の上限についても補足します。公式ドキュメントには「Maximum of 30 simultaneous database sessions」と明記されています。過去の情報や一部の解説記事では上限を20セッションと紹介しているケースが見られますが、これは古い基準に基づく情報です。2026年7月時点の公式ドキュメントで確認できる最新の上限は30セッションです。検証時にセッション数を見積もる際は、この30セッションという値を基準にしてください。

なお、Always Free枠のコンピュート仕様は、公式ドキュメント上では現在も一貫して「1 OCPU固定」と表記されています。OCIの作成ダイアログには別途「Developer(Autonomous AI Database for Developers)」という選択肢があり、これは4 ECPU・ストレージ20GB固定という、開発・テスト用途向けの低額固定の有償オプションです(インスタンス単位の時間額課金で、停止中も課金が継続します)。Always Freeと名称・位置が似ていますが無料ではないため、無料枠のつもりで選び間違えないよう注意してください(コンソール実表示のスクリーンショットでの確認は本記事執筆時点では未実施のため、公式ドキュメントの表記を正としています)。

AWSのRDS無料利用枠と比較すると、制約の性質の違いが見えてきます。RDSの無料利用枠は、db.t3.microまたはdb.t4g.microインスタンスを月750時間まで、ストレージ20GBまでという「新規アカウント向け12か月間限定」の無料枠です。一方Autonomous AI DatabaseのAlways Free枠は、期限の定めなく使い続けられる代わりに、コンピュート・ストレージが完全に固定されるという設計です。「期間限定だが柔軟」なRDS無料枠と、「無期限だが固定」なAutonomous AI DatabaseのAlways Free枠、という対比で捉えると理解しやすくなります。

2-2. Home Region限定 — 東京は対象、大阪は現時点で26ai対象外

Always Free枠のAutonomous AI Databaseには、「home region限定」という制約があります。公式ドキュメントには「You can create Always Free Autonomous AI Databases only in this home data region. You cannot create an Always Free Autonomous AI Database in other data regions that you subsequently subscribe to.」と明記されており、Always Free枠のインスタンスは、テナンシのホームリージョンでしか作成できません。ホームリージョン以外の登録リージョンをサブスクライブしていても、そちらではAlways Free枠のインスタンスを作成できない点に注意が必要です。

さらに、最新のデータベースバージョンであるOracle AI Database 26aiについては、Always Free枠として利用できるリージョンが以下に限定されています(2026年7月時点)。

日本国内のリージョンでいうと、東京リージョン(Japan East、リージョン識別子NRT)はこの一覧に含まれており、26aiのAlways Free枠を利用できます。一方、大阪リージョン(Japan Central、リージョン識別子KIX)は、2026年7月時点でこの一覧に含まれていません。大阪をホームリージョンとするテナンシで26aiのAlways Free枠を利用したい場合は、公式ドキュメントで最新の対応状況を確認する必要があります。

なお、Autonomous AI Database自体のサービス提供(有償枠を含む一般的な利用)は、公式ドキュメントに「Autonomous AI Database is available in all regions of the commercial realm.」と明記されている通り、商用リアルムの全リージョンで利用可能です。今回の制約はあくまで「Always Free枠として無料で使える26aiインスタンスをどのリージョンで作成できるか」という話であり、有償枠でのAutonomous AI Database自体の可用性とは区別して理解してください。

本記事の§3では、ホームリージョンが東京(NRT)であるテナンシを前提にハンズオンを進めます。ホームリージョンの確認方法や変更不可の制約については、OCI入門シリーズVol1で解説済みです。ご自身のテナンシのホームリージョンが分からない場合は、OCIコンソール右上のリージョンセレクターを開くと、現在選択中のリージョンおよびサブスクライブ済みのリージョン一覧が表示されるので、そこで確認できます。ホームリージョンは、通常はリージョン一覧の先頭またはラベル付きで区別して表示されます。

2-3. 自動停止・削除ルール — 7日で停止、90日で削除される可能性

Always Free枠のAutonomous AI Databaseには、非アクティブ状態を理由とする自動停止・自動削除のルールが存在します。作成してそのまま放置すると、意図せずインスタンスを失う可能性があるため、必ず押さえておく必要があります。

公式ドキュメントの記載を整理すると、次の2段階のルールが定義されています。

1. 7日ルール(自動停止): 「After being inactive for 7 days, the database will be stopped automatically, preserving its stored data.」— 7日間非アクティブな状態が続くと、データを保持したまま自動的に停止します。
2. 90日ルール(自動削除の可能性): 「A database that is automatically or manually stopped and stays inactive for 90 days, cumulative, may be reclaimed and permanently deleted.」— 停止(自動・手動を問わず)状態が累積で90日続くと、永続的に削除される可能性があります。

この「非アクティブ」の判定には、リセットされる条件も定められています。公式ドキュメントには「Successfully making a SQL*Net or HTTPS connection and running SQL commands on your database resets these measurements to zero.」と明記されています。つまり、SQL*NetまたはHTTPS経由での接続とSQLコマンドの実行に成功すると、非アクティブ日数のカウントはゼロにリセットされます。

公式ドキュメントにはさらに「Starting a stopped database resets these measurements to zero.」とも記載されています。停止したデータベースを再起動した場合も、同様にカウントはリセットされます。

学習目的で継続的にAlways Free枠を使い続けたい場合は、7日に一度は実際に接続してSQLを実行するか、少なくとも停止から90日以内に再起動する運用を意識してください。特にAPEXアプリケーションの動作確認だけで満足し、データベースへ直接SQLを実行していない場合、意図した「アクティブ」判定になっていない可能性もあるため注意が必要です。

ここでAWSのRDSと比較すると、興味深い対比が見えてきます。AWS RDSでは、利用者が明示的に停止したインスタンスであっても、7日間停止し続けると自動的に再起動される仕様になっています。これは、パッチ適用など必要なメンテナンスをインスタンスに反映し続けるための仕組みです。つまりRDSは「7日間止まったままなら自動的に動かす」方向に働くのに対し、Autonomous AI DatabaseのAlways Free枠は「7日間非アクティブなら自動的に止める」という、正反対の方向に働きます。同じ「7日」という数字が登場していても、AWSでの経験則(止めたら7日後に勝手に動き出す)をそのままOCIに当てはめると、逆の結果(動いていたはずが7日後に止まっている)に驚く場合があるため、注意が必要です。

もう一つ、AWSで近い発想の機能としてAurora Serverless v1のオートポーズ(自動一時停止)が挙げられます。Aurora Serverless v1では、デフォルト5分(5分〜24時間の範囲で変更可能)の非アクティブでクラスターが自動的に一時停止し、接続リクエストが来ると自動的に再開する仕組みが提供されています。Always Free枠のAutonomous AI Databaseも「非アクティブで自動的に止まる」という考え方は共通していますが、決定的な違いは自動再開の有無です。Aurora Serverless v1は接続リクエストをきっかけに自動的に再開しますが、Autonomous AI Databaseは停止後、利用者が明示的にインスタンスを起動しない限り再開しません。「接続すれば勝手に起きる」というAurora Serverless v1の感覚のままAlways Free枠を扱うと、停止したインスタンスへの接続が単に失敗するだけに見えてしまうため、この違いも押さえておく必要があります。

2-4. HTTPインターフェースのレート制限 — APEX/ORDS/Database Actionsは429エラーに注意

Always Free枠には、APEX・Oracle REST Data Services(ORDS)・Database ActionsといったHTTPベースのインターフェース全体に対する、同時アクセス数のレート制限があります。

公式ドキュメントには「The HTTP interface for Always Free Autonomous AI Databases is rate limited to restrict the number of simultaneous service users.」と明記されています。具体的には「Approximately 3-6 simultaneous users can be supported across all of the APEX, Oracle REST Data Services, and Database Actions running on your Always Free Autonomous AI Databases.」とあり、APEX・ORDS・Database Actionsを合算して、同時に利用できるユーザー数はおおよそ3〜6人程度とされています。

この上限を超えると、「Additional simultaneous users beyond that may result in users encountering HTTP errors such as HTTP status code 429.」とある通り、追加のユーザーはHTTP 429(Too Many Requests)エラーに遭遇する可能性があります。個人の学習用途であれば問題になりにくい制約ですが、複数人でのチーム検証や、APEXアプリケーションを他者にデモとして共有する場面では、この同時アクセス数の上限を意識しておく必要があります。なお、公式ドキュメントには「This HTTP interface rate limit applies only for Always Free Autonomous AI Databases.」とも明記されており、有償枠のインスタンスにはこのHTTPインターフェース特有のレート制限は適用されません。

実際に起こりうる場面として、社内の勉強会でAPEXアプリケーションのデモを行い、参加者数名に同時にURLを開いてもらったところ、一部の参加者だけ画面が表示されずHTTP 429エラーになる、といったケースが考えられます。この場合、APEXアプリケーション自体のバグではなく、Always Free枠のHTTPインターフェース全体に対する同時アクセス数の制限に達したことによる可能性が高いといえます。デモの参加人数が多くなると事前に分かっている場合は、有償枠への切り替えを検討するか、参加者に順番でアクセスしてもらう運用でしのぐ必要があります。

なお、このレート制限はAPEX・ORDS・Database ActionsといったHTTPインターフェース経由のアクセスに対するものであり、SQL*NetによるDatabase接続(後述する§3のウォレット経由の接続など)には別途、同時セッション数上限(§2-1で触れた30セッション)が適用されます。「HTTPインターフェースの同時ユーザー数」と「SQL*Netの同時セッション数」は、それぞれ別の制限として管理されている点も押さえておいてください。

2-5. 非対応機能一覧 — オートスケール・長期バックアップ・Data Guard・プライベートエンドポイント

§2-1で触れたオートスケール不可に加えて、Always Free枠では次の機能が利用できません。公式ドキュメントの記載に基づき、一覧として整理します。

これらの非対応機能に共通するのは、いずれも「高可用性」「災害復旧」「ネットワーク分離」といった、本番運用で重視される観点に関わる機能であるという点です。Always Free枠は、あくまで学習・検証・PoC用途を想定した無料枠であり、本番運用を想定した構成には向いていません。本番相当の構成を検証したい場合は、有償枠への切り替えが前提になります。

AWSとの対比でいうと、Autonomous Data Guardが利用できないという制約は、RDSのMulti-AZ配置(自動フェイルオーバー用の待機系)に相当する機能が使えない、という理解に近いといえます。AWSでも無料利用枠のRDSインスタンスはMulti-AZ配置には対応していないことが一般的であり、この点は「無料枠では高可用性構成は組めない」という考え方自体はAWS・OCIで共通しています。

一方、プライベートエンドポイント(VCN内配置)が利用できないという制約は、AWS実務者にとってやや意外に感じられるかもしれません。AWSのRDSは、無料利用枠であっても基本的にVPC内に配置され、セキュリティグループで接続元を制御するのが一般的な構成です。これに対しAlways Free枠のAutonomous AI Databaseは、そもそもVCN内に配置すること自体ができず、パブリックエンドポイント(後述する§3のウォレットによる暗号化接続)経由でのみアクセスする構成になります。「データベースは基本的にプライベートサブネットに置くもの」というAWSでの経験則を、そのままAlways Free枠に当てはめることはできない点に注意してください。有償枠では、プライベートエンドポイントによるVCN内配置が可能になります。

2-6. Always Free枠が向いている用途・向いていない用途

ここまで整理してきた制約を踏まえ、Always Free枠が向いている用途と向いていない用途を整理します。

この向き不向きの整理から分かる通り、Always Free枠は「Autonomous Databaseというサービスの操作感を無料で体験する」ことに主眼を置いた無料枠であり、本番運用の代替にはなりません。この前提を理解した上で、§3では実際にAlways Free枠のインスタンスを作成していきます。

例えば、社内で新しいデータベースサービスの選定検討をしている場合、まずはAlways Free枠でAPEXの操作感やSQL実行時のレスポンスを個人検証し、実際に採用が見えてきた段階で有償枠に切り替えてチーム共有の検証環境を用意する、という2段階のアプローチが現実的です。最初から有償枠でチーム共有の検証環境を作ってしまうと、Always Free枠では気づけなかった制約(オートスケール不可などの誤解)を確認しないまま先に進んでしまうリスクもあるため、個人検証のステップを飛ばさないことをお勧めします。

2-7. よくある誤解 — AWS実務者が陥りやすいポイント

ここまでの内容を踏まえ、AWS実務者がAlways Free枠のAutonomous AI Databaseについて抱きやすい誤解を整理します。

誤解1: Always Freeでもオートスケールを試せる

「Autonomous」という名前や、有償枠での紹介記事に登場するオートスケール機能を見て、Always Freeでもオートスケールの動作を確認できると考えてしまうケースです。§2-1で見た通り、Always Free枠は手動・自動を問わずスケール不可のため、この誤解のまま構築を始めると、オートスケール関連の設定項目自体が存在せず戸惑うことになります。

誤解2: 登録リージョンをサブスクライブすれば、そこでもAlways Free枠を使える

OCIでは複数のリージョンを登録リージョンとしてサブスクライブできますが、Always Free枠のインスタンスを作成できるのはホームリージョンのみです。§2-2で見た通り、後から別リージョンを追加登録しても、そちらでAlways Free枠のインスタンスを新規に作ることはできません。

誤解3: 一度作成すれば、使わなくてもずっと残り続ける

無料である以上、放置していても永続的に残ると考えてしまいがちですが、§2-3で見た通り、7日間の非アクティブで自動停止し、停止が累積90日続くと削除される可能性があります。「無料=放置しても安全」ではない点に注意が必要です。

誤解4: RDSと同じ感覚でVPC(VCN)内に配置できる

AWSのRDSはVPC内への配置が一般的であるため、同様にAutonomous AI DatabaseもVCN内に配置できると考えてしまうケースがあります。§2-5で見た通り、Always Free枠ではプライベートエンドポイント・VCN内配置自体が利用できません。

誤解5: APEXのデモは何人が同時アクセスしても問題ない

APEXが標準搭載されているため、Webアプリケーションとして自由にスケールすると考えてしまいがちですが、§2-4で見た通り、HTTPインターフェース全体で同時3〜6ユーザー程度のレート制限があります。

誤解6: ADB/ATP/ADWという旧称の情報は、そのまま現行のAutonomous AI Databaseに当てはまる

§1-6で触れた通り、Autonomous Databaseは現行名称のAutonomous AI Databaseへとリブランディングされ、旧称のATP(Autonomous Transaction Processing)はTransaction Processing、ADW(Autonomous Data Warehouse)はLakehouseというワークロードタイプ名に整理されています。ウェブ検索では旧称のまま書かれた古い記事も多くヒットしますが、セッション数上限(旧20→現30)のように、数値が更新されている項目もあります。旧称の情報を参照する際は、本記事のように取得日を明記した最新の公式ドキュメントで裏取りすることをお勧めします。

これら6つの誤解に共通するのは、「AWSでの経験則、あるいはAutonomousという名称から連想されるイメージを、そのままAlways Free枠に当てはめてしまう」という点です。§1で述べた通り、Autonomous Databaseは運用自動化の範囲がRDS/Auroraより広いサービスですが、それは主に有償枠を前提とした話であり、Always Free枠はむしろ「固定リソースの中でどこまで体験できるか」を試す入り口だと捉えておくことが重要です。

2-8. Always Free枠を後から有償枠へ切り替える

ここまで見てきた制約に「もう少しリソースが欲しい」「オートスケールを試したい」と感じた場合でも、Always Free枠で作成したインスタンスを作り直す必要はありません。公式ドキュメントには「You can update an Always Free Autonomous AI Database to a paid instance to provide the instance with additional compute and storage resources.」と明記されており、既存のAlways Freeインスタンスをそのまま有償インスタンスへアップグレードできます。

アップグレード時の初期状態についても、公式ドキュメントには「When you update from an Always Free instance to a paid instance you get a paid instance of the same workload type with the minimum CPU and minimum storage available for that workload type.」と記載されています。つまり、アップグレード直後はそのワークロードタイプにおける最小構成のCPU・ストレージから始まり、そこから改めてスケールアップやオートスケールを設定する流れになります。

なお、Always Free枠のインスタンス数については、「Maximum of 2 Always Free Autonomous AI Database instances per Oracle Cloud Infrastructure tenancy.」と明記されており、1テナンシあたり最大2つまで、Lakehouse・Transaction Processing・JSON・APEX Serviceのいずれかのワークロードタイプを組み合わせて作成できます。本記事の§3で作成するインスタンスを含めて、この上限を踏まえて計画してください。

例えば、本記事の§3でTransaction Processingワークロードタイプのインスタンスを1つ作成した後、別途Lakehouseワークロードタイプのインスタンスをもう1つ、Always Free枠のまま追加作成できます。この2つ目の枠をどう使うかは、本シリーズの後続記事で改めて扱う予定です。

2-9. 作成前チェックリスト

§3のハンズオンへ進む前に、本章で整理した制約を踏まえて確認しておきたい項目を整理します。

• ホームリージョンが東京(NRT)など、26ai対応のhome region一覧に含まれているか確認したか(§2-2)
• オートスケールを試す目的であれば、Always Freeではなく有償枠が必要であることを理解したか(§2-1)
• 学習を継続する場合、7日に一度は接続してSQLを実行するか、90日以内に再起動する運用を意識できるか(§2-3)
• 複数人でデモを行う予定がある場合、同時3〜6ユーザー程度のレート制限を踏まえた人数調整ができるか(§2-4)
• 高可用性(Data Guard)やプライベートネットワーク構成が必要な検証ではないことを確認したか(§2-5)
• 既存のAlways Freeインスタンス数が、テナンシあたりの上限である2つに達していないか確認したか(§2-8)
• ADB/ATP/ADWといった旧称の情報を参照する場合、取得日付を確認し最新の公式ドキュメントで裏取りしたか(§2-7)

これらの項目にすべて問題がなければ、Always Free枠でのAutonomous AI Database作成に進む準備が整っています。

次章では、実際にOCIコンソールを操作してインスタンスを作成し、接続してAPEXの画面まで確認する手順を見ていきます。

3. Always Free Autonomous AI Database作成ハンズオン

本章では、§2で確認した制約を踏まえた上で、実際にOCIコンソールを操作してAlways Free枠のAutonomous AI Databaseを作成する手順を解説します。本章の手順は、OCI公式ドキュメントに記載されたコンソール操作フローを踏まえています。実際の画面レイアウトはOCIのアップデートにより変わる場合があるため、項目名や配置が本記事と異なる場合は、公式ドキュメントもあわせてご確認ください。

3-1. 作成前に準備するもの

作成を始める前に、次の項目を準備・確認しておきます。

• OCIアカウント(テナンシ)とホームリージョン(本記事では東京・NRTを前提とします。§2-2参照)
• リソースを作成するコンパートメント(OCI入門シリーズVol1で解説したコンパートメント設計に従い、検証用のコンパートメントを用意しておくことを推奨します)
• Always Free枠のインスタンス数がテナンシあたりの上限(2つ)に達していないこと(§2-8参照)
• 管理者(ADMIN)ユーザー用のパスワードとして使う、12〜30文字で大文字・小文字・数字を含む文字列

3-2. Autonomous Database作成ダイアログを開く

OCIコンソールにサインインしたら、左側のナビゲーションメニューからOracle Databaseの配下にあるAutonomous Database関連のサービス(ワークロードタイプに応じてAutonomous Data Warehouse、Autonomous JSON Database、Autonomous Transaction Processingのいずれか)を選択します。画面右上のリージョンセレクターで対象リージョン(ホームリージョンである東京)を選択します。あわせて、リソース一覧画面のコンパートメントセレクターから、§3-1で準備したコンパートメントを選択します。

対象リージョン・コンパートメントを選択した状態で、画面上部の「Create Autonomous Database」ボタンをクリックすると、作成ダイアログが開きます。

3-3. 基本情報とワークロードタイプの指定

作成ダイアログでは、まず基本情報を入力します。

• Compartment: §3-1で準備したコンパートメントを選択します
• Display name: コンソール上に表示される名前を入力します(例: adb-vol1-alwaysfree)
• Database name: データベース名を入力します。英数字のみ、先頭は英字、最大30文字という制約があります

続いて、「Choose a workload type」から、作成するインスタンスのワークロードタイプを選択します。選択肢はLakehouse・Transaction Processing・JSON・APEXの4種類です。本記事では、一般的なアプリケーション用途を想定し、Transaction Processingを選択して進めます。

3-4. Always Freeの選択と管理者パスワードの設定

ワークロードタイプを選択すると、データベース構成のセクションが表示されます。ここで「Always Free」のトグルを有効にします。

Always Freeを有効にすると、コンピュートとストレージの項目がグレーアウトし、固定値で表示されます。この時点で表示される値が、§2-1で解説した固定リソース(1 OCPU相当・ストレージ20GB)です。ECPU countやストレージ容量を手動で変更しようとしても、Always Freeが有効な間は変更できません。

「Choose database version」では、Oracle AI Database 26aiまたはOracle Database 19cのいずれかを選択します。本記事では、最新機能を前提として26aiを選択します。ホームリージョンが§2-2で確認した26ai対応リージョン(東京含む)に含まれていない場合、26aiが選択肢に表示されないか、作成時にエラーとなる可能性があるため、その場合は19cを選択するか、ホームリージョンの対応状況を確認してください。

管理者認証情報のセクションでは、Usernameが「ADMIN」に固定表示されます。「Password」と「Confirm password」に、§3-1で準備した条件を満たすパスワードを入力します。このパスワードは、後続の章でDatabase Actions・APEXへ接続する際にも使用するため、忘れないよう安全な場所に記録しておいてください。

3-5. ネットワークアクセスの選択と作成の実行

「Choose network access」では、次の3つの選択肢が表示されます。

• Secure access from everywhere(デフォルト): どこからでもTLS経由でアクセス可能にします
• Secure access from allowed IPs and VCNs only: 許可したIPアドレス・VCNからのみアクセスを許可します
• Private endpoint access only: VCN内にプライベートエンドポイントとして配置します

§2-5で確認した通り、Always Free枠のインスタンスはプライベートエンドポイントとしての配置に対応していません。そのため、Always Freeを有効にした状態では「Private endpoint access only」は選択できないか、選択してもAlways Freeのトグルが自動的に解除される可能性があります。本記事では、デフォルトの「Secure access from everywhere」を選択して進めます。

必要な項目を入力し終えたら、ダイアログ下部の「Create Autonomous AI Database」ボタンをクリックします。これにより、Always Free枠のAutonomous AI Databaseインスタンスの作成が開始されます。

3-6. プロビジョニング完了の確認

作成ボタンをクリックすると、コンソールはインスタンスの詳細ページへ遷移します。この時点で、画面上のLifecycle State(ライフサイクル状態)は「Provisioning」と表示されます。

プロビジョニングが完了するまで数分程度待つと、Lifecycle Stateが「Available」に変わります。この状態になれば、インスタンスの作成は完了です。詳細ページには、作成時に指定したDatabase name・Workload type・Always Freeの設定状況・OCID(Oracle Cloud Identifier)などの情報が表示されます。

Always Free枠のAutonomous AI Databaseインスタンスが作成できました。続く§4では、実際にDatabase ActionsやAPEXへ接続してSQLを実行し、簡単なアプリケーションを作成するまでの実践手順を見ていきます。

4. 接続とデータ操作 — Database ActionsとAPEXを実際に触る

§3でAlways Free枠のインスタンスがAvailable状態になったところから、本章では実際にDatabase ActionsとAPEXへ接続し、SQL実行からAPEXアプリ作成の入り口までを一気通貫で実践します。§1-3の対比表で触れた「組み込み開発ツール」という差別化ポイントを、実際の操作を通じて確認していきましょう。

4-1. Database Actionsへのアクセス

Autonomous AI Databaseインスタンスの詳細ページから、Database Actionsへアクセスします。詳細ページ上部にある「Database actions」のドロップダウンリストをクリックし、個別のツール(例: SQL)へ直接遷移するか、「View all database actions」を選択してすべてのツールが並ぶランチャー画面を開きます。コンソールがADMINとしてデータベースへ自動アクセスできない場合は、ADMINのユーザー名とパスワード(§3-4で設定したもの)の入力を求められます。

Database Actionsのランチャー画面には、次のようなツールがカテゴリ別に並びます。

AWSでAuroraやRDSを運用する場合、SQLクライアント・データロードツール・監視ダッシュボードは、それぞれ別のソフトウェアやサービス(DBeaver等のSQLクライアント、AWS DMS、CloudWatch)を個別に用意して組み合わせる必要があります。一方Autonomous AI Databaseでは、これらの機能がデータベースインスタンスの作成と同時に標準搭載されており、追加のセットアップなしにブラウザだけで完結する点が、RDS/Auroraにはない設計上の違いです。

4-2. SQL Worksheetでの実践 — テーブル作成からクエリ実行まで

Database Actionsのランチャー画面から「SQL」を選択すると、SQL Worksheetが開きます。画面上部の「Consumer Group」ドロップダウンリストで、SQLを実行する対象のコンシューマグループ(処理の優先度に応じたリソースプール)を選択したうえで、SQL文やPL/SQLコードをワークシートに入力し、実行ボタンで実行します。

簡単な動作確認として、次のようなSQLを順に実行してみます。

CREATE TABLE demo_items (
  item_id  NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  item_nameVARCHAR2(100) NOT NULL,
  created_at  TIMESTAMP DEFAULT SYSTIMESTAMP
);

INSERT INTO demo_items (item_name) VALUES ('AWSエンジニア向け動作確認レコード');

SELECT item_id, item_name, created_at FROM demo_items;

SQL Worksheetでは、1文ずつ実行するか、複数文をまとめてスクリプトとして実行するかを選択できます。実行結果はワークシート下部にグリッド形式で表示され、AWSのRDS Query Editor(Aurora Serverless向けのデータAPIベースのエディタ)に近い操作感で利用できます。

ここで§2の内容と接続しておくと、SQL WorksheetからのSQL*Net接続は§2-1で触れた同時セッション数上限(最大30セッション)にカウントされ、Database Actions自体はHTTPベースのツールであるため、§2-4で触れたHTTPインターフェースのレート制限(APEX・ORDS・Database Actions合算で同時3〜6ユーザー程度)の対象にも含まれます。個人での動作確認であれば問題になりにくい範囲ですが、チームで同時に触る場合はこの2つの制限を意識しておく必要があります。

また、SQL Worksheetで実行したSQLは、§2-3で触れた「非アクティブ判定のリセット」にも該当します。動作確認のためだけであっても、SQLを実行しておくことで7日ルールのカウントがリセットされる点は、学習を継続する上で覚えておくとよいでしょう。

4-3. APEXワークスペースの作成とアプリ生成の入り口

Autonomous AI Databaseインスタンスには、作成時点であらかじめ用意されたAPEXワークスペースは存在しません。APEXを使い始めるには、まずワークスペースを作成する必要があります。

なお、ADMINユーザー自体はワークスペースに関連付けることができない点に注意してください。ADMINはあくまでワークスペースを作成・管理するための管理者アカウントという位置づけで、実際にAPEXアプリを開発するデータベースユーザーとは分離されています。

ワークスペース作成後は、作成したワークスペースにサインインし直すことでApp Builderへアクセスできます。App Builderのホーム画面には、そのワークスペース内に作成済みのアプリケーション一覧が表示され、「Create App」から新規アプリを作成できます。本記事では、既存のテーブル(§4-2で作成したdemo_itemsテーブルなど)を選択し、一覧・登録・編集・削除の基本的なCRUD画面を自動生成する簡易アプリ作成までを、APEXの入り口として紹介するにとどめます。生成されたアプリを実際にカスタマイズしていく詳細な開発手順は、本記事の範囲を超えるため扱いません。

ここでAWSとの対比に戻ると、Auroraで同等の「テーブルからCRUD画面を作る」体験を得ようとすると、Amplify StudioやAppSyncなど、データベースの外側に別サービスを組み合わせる構成が必要になります。Autonomous AI DatabaseのAPEXは、データベースエンジンと同じインスタンス内で完結するため、追加のコンピュートリソースやAPIレイヤーを別途構築せずに、ブラウザだけでアプリのひな形まで到達できる点が特徴です。

4-4. RDS/Auroraにはない「DB内蔵開発環境」という差別化ポイント

§4-1〜§4-3を通じて実際に触ってみると、§1-3の対比表で触れた「組み込み開発ツール」というAutonomous AI Databaseの特徴が、単なるカタログ上の違いではなく、実際の操作フローの違いとして体感できたのではないでしょうか。RDSやAuroraでは、SQLクライアント・データロード・簡易アプリ作成のいずれも、データベースサービスの外側に別のツールやサービスを用意して組み合わせる必要があります。一方Autonomous AI Databaseでは、これらがすべてDatabase Actionsという単一の画面に集約されており、APEXによるアプリ作成までもがデータベースインスタンスの標準機能として提供されます。

この違いは、特に「まずデータベースを作って、そこから簡単な業務アプリのプロトタイプをすぐ試したい」という場面で効いてきます。AWSであれば複数のサービスを組み合わせる設計・構築の工程が必要になる一方、Autonomous AI Databaseであれば、データベース作成からアプリのひな形完成までを、追加のインフラ構築なしに完結できます。

次章では、Always Free枠では体験できないオートスケールについて、有償枠への切り替えを前提に、設定手順と課金試算の考え方を見ていきます。

5. 有償枠でのオートスケール設定と課金試算

§2-1で確認した通り、Always Free枠のAutonomous AI Databaseは「手動・自動を問わずスケール不可」という制約を持ちます。本章では、なぜAlways Freeではオートスケールを体験できないのかを改めて整理したうえで、有償枠でオートスケールを設定する手順と、課金がどのように試算されるのかを解説します。本章の内容は実際に課金が発生する有償枠の操作であるため、実機での実行までは求めず、設定画面の構成と試算の考え方の理解を目的とします。

5-1. なぜAlways Freeではオートスケールを体験できないか

§2-1で引用した通り、公式ドキュメントには「Always Free Autonomous AI Databases cannot be scaled manually or automatically beyond the fixed resource restrictions described earlier.」と明記されており、Always Free枠のコンピュート(1 OCPU固定)・ストレージ(20GB固定)は、オートスケールの設定項目自体が有効になりません。

§2-8で触れた通り、Always Free枠で作成したインスタンスは、作り直すことなくそのまま有償インスタンスへアップグレードできます。公式ドキュメントには「When you update from an Always Free instance to a paid instance you get a paid instance of the same workload type with the minimum CPU and minimum storage available for that workload type.」と記載されており、アップグレード直後はそのワークロードタイプの最小構成から始まります。つまり、オートスケールを体験するには、Always Free枠のまま設定を変更するのではなく、まず有償枠へアップグレードし、そこから改めてオートスケールを有効化する、という順序を踏む必要があります。

5-2. 有償枠でのコンピュート/ストレージオートスケール設定手順

有償インスタンスでのオートスケール設定は、OCIコンソールから次の手順で行います(公式ドキュメント記載・取得日: 2026年7月25日)。

公式ドキュメントには「With compute auto scaling enabled the database can use up to three times more CPU and IO resources than specified by the number of ECPUs」と明記されており、コンピュートのオートスケールを有効にすると、指定したECPU数の最大3倍までCPU・IOリソースを自動的に利用できます。例えば基準を2 ECPUに設定した場合、ワークロードが増加すると最大6 ECPUまで自動的にスケールします。ストレージのオートスケールについても、「the Autonomous AI Database can expand to use up to three times the reserved base storage」と、予約済みストレージの最大3倍まで自動拡張される仕組みです。

なお、ライセンスタイプによっては、ECPU countの上限が制限されます。公式ドキュメントには「Your license type determines the ECPU count maximum. For example, if your license type is Bring your own license (BYOL) with Oracle AI Database Standard Edition (SE), the ECPU count maximum is 32.」と記載されており、BYOL・Standard Editionの場合、オートスケールが有効でもECPU countは32が上限になります。

設定後の利用状況は、Database ActionsのDatabase Dashboardにある「Number of ECPUs allocated」グラフ(ストレージの場合は「Storage allocated」「Storage used」グラフ)から、実際に割り当てられているリソース量を時間帯ごとに確認できます。

5-3. 課金試算 — License IncludedとBYOLの比較

課金試算にあたっては、Oracle公式のAutonomous Database ECPU FAQ(取得日: 2026年7月25日)に基づく、米ドル建てのオンデマンド(Universal Credits)リストプライスを使用します。為替レートや契約形態(年間契約・Bring Your Own License要件など)によって実際の請求額は変動するため、あくまで試算の参考値として扱ってください。実際の見積もりは、OCIコンソールのCost Estimatorで最新の単価を確認することをお勧めします。

この単価をもとに、次の前提条件でLicense Includedの月額試算をしてみます。

• 基準ECPU count: 2 ECPU(最小構成)でオートスケール有効
• 稼働時間: 730時間/月(24時間×約30.4日で常時稼働と仮定)
• ワークロード想定: 通常時は基準の2 ECPUで稼働し、月間のうち約1割の時間帯(約73時間)でオートスケールにより最大3倍の6 ECPUまで利用したと仮定
• ストレージ: 基準20GBのまま(オートスケールなし)

同じ前提でBYOLの単価($0.0807/ECPU/時間)へ置き換えると、コンピュート費用部分だけで約4分の1程度まで下がる計算になります。ただしBYOLは、既存のOracle Databaseライセンスとサポート契約を保有している場合のみ選択できる点に注意してください。

この試算はあくまで、稼働時間・オートスケール発動率を仮定した一例です。実際の課金は、ワークロードの実際の負荷パターンやリージョンによる価格差、契約形態によって変動します。本番導入を検討する際は、必ずOCIコンソールのCost Estimatorで最新の単価と自身のワークロード想定に基づいた見積もりを取得してください。

5-4. オートスケールによる想定外課金の落とし穴

オートスケールは、ワークロードの増加に自動的に追従してくれる便利な機能である一方、「気づかないうちに最大3倍のリソースを使い続けていた」という想定外の課金につながるリスクも持ち合わせています。公式ドキュメントにも「your database may use and you may be billed for additional CPU consumption as needed by your workload, up to three times (3x) the number of base CPUs」と明記されている通り、オートスケール発動時の追加リソースは自動的に課金対象になります。

AWSのAuroraでも、Aurora Serverless v2のACU(Aurora Capacity Unit)がオートスケールする際に、想定より高いACUに張り付いたまま推移し、想定外の課金につながるケースがしばしば話題になります。Autonomous AI DatabaseのECPUオートスケールも同様の性質を持つため、有償枠でオートスケールを有効化した後は、Database Dashboardの「Number of ECPUs allocated」グラフを定期的に確認し、想定を超えたリソース利用が続いていないかを監視する運用を組み込んでおくことをお勧めします。

6. まとめ・落とし穴チェックリスト

本章では、§1〜§5で解説してきた内容を振り返り、Always Free枠のAutonomous AI Databaseを扱う際に陥りやすい落とし穴を、チェックリスト形式で整理します。

§1では、Autonomous Database(現行名称: Autonomous AI Database)が、RDS/Auroraの延長線ではなく、運用自動化の範囲とAPEX等の開発ツール標準搭載を特徴とする独自の設計思想を持つサービスであることを確認しました。§2では、Always Free枠特有の制約として、固定リソース・home region限定・自動停止/削除ルール・HTTPインターフェースのレート制限・非対応機能を整理しました。§3では実際にAlways Free枠のインスタンスを作成し、§4ではDatabase ActionsとAPEXへ接続してSQL実行とアプリ作成の入り口までを実践しました。そして§5では、Always Free枠では体験できないオートスケールについて、有償枠での設定手順と課金試算の考え方を解説しました。

Always Free枠のAutonomous AI Databaseは、無料でありながらAPEXやDatabase Actionsといった開発ツールまで一通り体験できる、学習・検証用途としては非常に強力な選択肢です。一方で、本記事で整理してきた通り、AWSでの経験則をそのまま持ち込むと戸惑う制約も少なくありません。まずはAlways Free枠でAutonomous Databaseの操作感を掴み、オートスケールや高可用性構成が必要になった段階で、既存インスタンスをそのまま有償枠へアップグレードする、という段階的なアプローチを検討してみてください。

→ OCI入門 Vol1: テナンシ・コンパートメント・リージョンとAlways Free枠