【Oracle Cloud Free & DB】第5回：作成直後の「表領域」はどうなっている？PaaSのストレージ状態をSQLで確認する

前回、私たちがブラウザから触っているデータベースが、クラウド全体の巨大なコンテナ（CDB）の中に切り出された「316番目の個室（PDB）」であることを突き止めました。今回は、その個室の中に視点を移してみましょう。データベースが作成された直後の初期状態において、内部にはどのような「表領域（Tablespace）」が確保されているのでしょうか？システム管理者（ADMIN）の視点から、データ・ディクショナリ・ビューを叩いてその中身を暴いてみます。

1. 初期状態の表領域を一覧確認するSQL

Oracleにおいて、データベース全体の表領域の全容を掴むための大本命ビューといえば、やはり DBA_TABLESPACES です。Autonomous Database（PaaS）でも、ADMIN権限でログインしていればオンプレミスと同様にこの管理者用ビューにアクセスできます。さっそく、表領域名とそのステータス、物理的な特性を一覧で取得してみましょう。

★ 表領域を確認するSQL：
SELECT tablespace_name, block_size, status, contents, bigfile FROM dba_tablespaces;

【実行結果（クラウド実機での測定値）】
"TABLESPACE_NAME","BLOCK_SIZE","STATUS","CONTENTS","BIGFILE"
"SYSTEM",8192,"ONLINE","PERMANENT","YES"
"SYSAUX",8192,"ONLINE","PERMANENT","YES"
"UNDOTBS1",8192,"ONLINE","UNDO","YES"
"DATA",8192,"ONLINE","PERMANENT","YES"
"DBFS_DATA",8192,"ONLINE","PERMANENT","YES"
"TEMP",8192,"ONLINE","TEMPORARY","YES"
"SAMPLESCHEMA",8192,"READ ONLY","PERMANENT","YES"
"UNDO_8",8192,"ONLINE","UNDO","YES"

経過時間: 00:00:00.005
8行が選択されました。

2. 実行結果から読み解くクラウド（PaaS）の4つの特徴

この生々しい8行の結果には、オンプレミスのOracleを長年触ってきたインフラエンジニアほど「おや？」と膝を打つ、クラウド特へ特有の設計思想が隠されています。

① すべてが「BIGFILE」＝「1表領域＝1ファイル」の極太設計
注目すべきは、右端の BIGFILE のステータスが全て「YES」になっている点です。
従来のOracle（Smallfile）のように「容量が足りなくなったら、2号ファイル、3号ファイルを追加していく」という泥臭いファイル単位の運用はここにはありません。BIGFILE表領域は「1つの表領域＝1つの超巨大なデータファイル（ブロックサイズ8KBなら最大32テラバイト！）」として管理する仕様です。最初からこの設定に統一することで、ファイル追加の手間を排除し、クラウド側で容量を全自動拡張（オートスケール）させるためのスマートなインフラ設計が行われている証拠です。

② アプリケーション用データはすべて「DATA」に一元集約
オンプレミスであれば、設計時にユーザーデータ用（USERS）、インデックス用（INDX）などと物理的な表領域を細かく分けるのが定石でした。しかし、ここには伝統の「USERS」ら存在せず、あるのは「DATA」表領域だけです。インフラ内部（Exadata基盤）が自動でストレージを最適化・ストライピングしてくれるため、人間がディスクの配置設計に頭を悩ませる必要がなくなっています。

③ クラウド（PaaS）特有の隠れキャラクターたち
基本5セット以外に見つかった3つの領域が、いかにもクラウド環境らしくて面白いポイントです。

• DBFS_DATA：データベースをOSのファイルシステムのように見せる機能（Database File System）のための領域。クラウドの内部連携などで使われます。
• SAMPLESCHEMA：Oracleお馴染みのサンプルデータ（SHスキーマなど）が最初から入っている領域。容量を食わないように親切にも「READ ONLY（読取専用）」に固定されています。
• UNDO_8：デフォルトの「UNDOTBS1」とは別にある謎のUNDO（変更履歴）領域。Autonomous Databaseはバックグラウンドで複数のサービスやインスタンスが協調して動いているため、システムが自動で切り出した追加のUNDO領域と推測できます。

3. 各表領域の役割まとめ

今回あぶり出した全8つの表領域の役割を、管理者の視点で整理しておきます。

表領域名	STATUS / CONTENTS	役割とPaaSでの見所
SYSTEM	ONLINE / PERMANENT	データベースの心臓部。データ・ディクショナリ（メタ情報）が格納される領域。
SYSAUX	ONLINE / PERMANENT	SYSTEMの補助領域。AWR（パフォーマンス統計）などが自動格納される。
DATA	ONLINE / PERMANENT	★ 本番データ領域。私たちが作るテーブルやインデックスはすべてここに集約される。
DBFS_DATA	ONLINE / PERMANENT	DBFS（Database File System）用。クラウドのシステム管理用領域。
SAMPLESCHEMA	READ ONLY / PERMANENT	学習用のサンプルスキーマ用領域。書き換えられないよう読取専用状態。
TEMP	ONLINE / TEMPORARY	一時領域。大規模なソートやハッシュ結合でメモリが足りない時に使われる。
UNDOTBS1	ONLINE / UNDO	読取り一貫性やロールバックのための主要な変更履歴（UNDO）領域。
UNDO_8	ONLINE / UNDO	システムによって自動追加されたマルチインスタンス用の予備UNDO領域。

4. まとめ：運用フリーの思想が表領域にも現れている

サーバーパラメータの制限に続き、表領域の構成を見ても「データベース管理者の面倒な作業（データファイルの容量追加や、断片化を防ぐための配置設計）を1つでも減らす」というAutonomous（自律型）の強い思想が感じられる結果となりました。

★ 本日の表領域チェックリスト：
1. 管理者権限（ADMIN）から全体の表領域を俯瞰するには「DBA_TABLESPACES」を使う。
2. 面倒なファイル追加・監視を排除するため、全表領域が最大32TBまでいける「BIGFILE」構成。
3. ユーザーデータは細かく分けない。クラウドの最適化を信じて「DATA」表領域に一元集約するのがPaaSの作法。

ストレージの内部構造までバッチリ把握できました。これで現在の環境（26ai）の仕様理解は完璧です！次回第6回は、このクラウド完全管理型（PaaS）の環境と比較するために、「もう一つの無料枠（Compute VM）」を立ち上げて、あえて自分ですべてを管理する「IaaS型の19c Express Edition」の自作構築に挑戦します。PaaSとIaaSでどれだけ世界が変わるのか？インフラエンジニア必見の回となります。どうぞお楽しみに！

【Oracle Cloud Free & DB】第4回：ブラウザから繋いでいるのはCDB？PDB？実機SQLで暴くマルチテナントの裏側と「同居」の仕組み

前回までで、言語設定（NLS）や時刻（タイムゾーン）を「日本仕様」に完全自動化し、ストレスのない検証環境を整えることができました。基礎固めが終わったところで、今回は少しアーキテクチャの深い部分に踏み込んでみましょう。Oracle Databaseといえば「マルチテナント・アーキテクチャ（CDB/PDB）」が標準ですが、私たちが今ブラウザ（データベース・アクション）から触っている環境は、一体どちらに接続しているのでしょうか？実機での検証ログを交えて解説します。

1. 結論：私たちが接続しているのは100%「PaaSのPDB」

結論から言うと、データベース・アクションからログインして操作している領域は、100%「PDB（プラガブル・データベース）」側です。

Oracle CloudのAlways Free枠で構築されるAutonomous Database（ADB）は、ユーザーがインフラの管理（CDBレベルの保守や全体設定）を意識しなくて済むように徹底して隠蔽されています。最初から独立した1つのPDB（アプリケーション用の仮想的なデータベース部屋）として切り出され、提供されているのが特徴です。

2. 【実機検証】SYS_CONTEXTで現在地を暴く

本当にPDBに接続しているのか、データ・ディクショナリではなくセッション情報を保持する「SYS_CONTEXT」関数を叩いて、内部的なコンテナ名とIDを引っ張り出してみましょう。

★ 現在地を確認するSQL：
SELECT SYS_CONTEXT('USERENV', 'CON_NAME') AS CONTAINER_NAME, SYS_CONTEXT('USERENV', 'CON_ID') AS CONTAINER_ID FROM DUAL;

【実行結果（セキュリティのため固有識別子はマスクしています）】
"CONTAINER_NAME","CONTAINER_ID"
"XXXXXXXXXXXXXXX_DB19C","316"

経過時間: 00:00:00.002
1行が選択されました。

注目すべきは、CONTAINER_ID に出力された「316」という非常に大きな数値です。Oracleのマルチテナント仕様では、このIDの数値によって居場所が厳密に定義されています。

• CON_ID = 1：CDB$ROOT（システム全体・全コンテナを統括する親玉）
• CON_ID = 2：PDB$SEED（新しいPDBを自動生成するための型枠）
• CON_ID >= 3：ユーザーが個別に作成した独立運用の PDB

実機ログで「316」という大きな番号が出ているということは、クラウドの巨大な共有基盤（CDB）の中で、自分の環境が「316番目の独立した個室（PDB）」としてきっちり区切られてホストされているという、何よりの証明になります。

3. 図解で見るCDBとPDBの「同居」アーキテクチャ

この関係性を分かりやすくイメージ図にすると、以下のようなマンション構造になっています。クラウド（PaaS）ならではの「同居」の形が視覚的に理解できると思います。

【 Oracle Cloudの巨大なインフラ基盤：CDB（コンテナ・データベース） 】

■ CDB$ROOT (CON_ID: 1) ── Oracleのクラウド管理部隊が統括（ユーザーは立ち入り禁止）

PDB (CON_ID: 3)
世界中の誰かの無料枠

PDB (CON_ID: 4)
また別の誰かの無料枠

★ PDB (CON_ID: 316)
あなた専用の部屋
（いま接続している場所）

このように、親となる巨大なCDBの中に、世界中のユーザーのPDBがマンションの部屋のように並んでいます。私たちがブラウザからログインした瞬間、この「316号室」へ直接ワープして接続しているわけです。

4. アーキテクチャから納得する「PaaSの制限」

この構造が頭に入ると、第2回や第3回で直面した「PaaSならではの制限や不思議な挙動」の理由が、パズルのピースがハマるようにスッキリと納得できます。

① サーバー全体の初期化パラメータを変更できない理由
もし私たちがADMIN権限を使って、CDB全体のパラメータ（`ALTER SYSTEM`）を勝手に書き換えてしまうと、同じCDBマンションに同居している「他のユーザーの部屋（PDB）」にまで設定が波及し、大混乱を引き起こしてしまいます。そのため、クラウド側で厳重にブロックされているのです。

② 前回のログオン・トリガーが安全に動く理由
前回、接続時にタイムゾーンを自動適用させるために AFTER LOGON ON DATABASE というトリガーを仕込みました。「DATABASE（全体）」と書くので他人に迷惑がかからないか一瞬ヒヤッとしますが、PDB環境下においてはこのコマンドは自動的に「自分がいるPDB（316号室）の中だけ」に適用範囲が限定されます。隣の部屋を汚すことなく、安全に自分好みの部屋（JST環境）にカスタマイズできていたわけです。

5. まとめ：ブラックボックスを暴くとクラウドはもっと面白い

一見すると完全にカプセル化されていて中身が見えないクラウド（PaaS）のOracleですが、標準的なSQL関数（SYS_CONTEXT）を一本叩くだけで、その裏側にある精緻なマルチテナントの同居構造が綺麗に見えてきます。インフラの仕組みを正しく把握することこそ、トラブルに強いエンジニアへの第一歩です。

★ 本日のアーキテクチャチェックリスト：
1. Autonomous Databaseは最初から「PDB」として切り出されて提供されている。
2. SYS_CONTEXTで「CON_ID」を確認し、3以上の大きな数値が出ればそれがPDB同居の証拠。
3. CDB全体に影響が及ぶ操作は、他ユーザーの保護（マルチテナントの安全）のために制限されている。

自分たちの「現在地」とクラウドの仕組みが完璧に腑に落ちたところで、環境構築の章はいよいよフィナーレです。次回第5回は、もう一つの無料枠の権利をフルに使い、「19c」のインスタンスを実際に追加して、今回作った最新「26ai」環境との本格的な並走比較（機能・挙動の違い）に突入します。新旧Oracleの最大の違いはどこにあるのか？どうぞお楽しみに！

【Oracle Cloud Free & DB】第3回：JSTに変えても時間が違う？都度切断の罠を「ログオン・トリガー」で根本から美しく解決する

前回、ツール側の地域設定を「日本」に変更しました。これで画面の見た目は日本仕様になりましたが、ここで最大級の罠が立ちはだかります。お馴染みの SELECT SYSDATE FROM DUAL; だけでなく、セッションに従うはずの SELECT CURRENT_DATE FROM DUAL; を実行しても、返ってくるのは相変わらず9時間遅れの「世界標準時（UTC）」のままなのです。ネットにある『ALTER SESSIONを使おう』という泥臭い方法ではなく、データベースの機能を活かして「最もエレガントに根本解決する」現場の定石を解説します。

1. なぜ「ALTER SESSION」を実行しても時間がズレるのか？

Autonomous Database（PaaS）において、SYSDATEがクラウド基盤のOS時刻（UTC）に固定されているのは仕様ですが、なぜ画面上で ALTER SESSION SET TIME_ZONE = 'Asia/Tokyo'; を実行した後に CURRENT_DATE を叩いても時間が戻してしまうのでしょうか？

その原因は、ブラウザ上の開発ツールである「データベース・アクション」の挙動にあります。このツールは、SQLを実行するたびに内部でセッションを一度切断・再接続するような挙動（ステートレスな制御）をとっています。そのため、画面上で手動でALTER SESSIONを実行しても、次のSQLを実行した瞬間にはその効果がリセットされ、初期状態（UTC）へと戻ってしまうのです。

2. 【最高にエレガントな解決策】「AFTER LOGONトリガー」で自動化する

毎回SQLに足し算（+9/24）を書いたり、実行手順を工夫したりするのはスマートではありません。一番エレガントな解決策は、「誰が、どのツールから、いつ接続してきても、ログインした瞬間に自動でタイムゾーンを日本（JST）に書き換える仕組み」をデータベース側に仕込むことです。

Oracleの標準機能である「AFTER LOGONトリガー（ログオン後トリガー）」をADMIN権限で1回作成しておくだけで、システムが自動的にセッションをコントロールしてくれます。

★ タイムゾーン自動変更トリガーの作成SQL：
ワークシートで以下のSQLを1度だけ実行します（※この時だけはF5などのスクリプト実行で流します）。

CREATE OR REPLACE TRIGGER SET_JST_AFTER_LOGON
AFTER LOGON ON DATABASE
BEGIN
    EXECUTE IMMEDIATE 'ALTER SESSION SET TIME_ZONE = ''Asia/Tokyo''';
END;
/

3. 実機での検証ログ：普通に叩くだけで完璧な日本時間に！

トリガーの作成が完了したら、もう面倒な前処理やF5キーでの一括実行すら不要です。ブラウザをリロードし、ただ普通にいつもの標準関数を通常の実行ボタン（▶）で1行ずつ叩いてみましょう。ツール特有の揮発性に邪魔されることなく、見事に正真正銘の「正しい日本時間」が一発で返ってきます。

★ 実際の検証SQLと実行結果：

SELECT CURRENT_DATE FROM DUAL;

CURRENT_DATE
------------------
2026/05/17 19:48:06
経過時間: 00:00:00.002
1行が選択されました。

--------------------------------------------------

SELECT LOCALTIMESTAMP FROM DUAL;

LOCALTIMESTAMP
---------------------------
2026-05-17T19:48:06.502281Z
経過時間: 00:00:00.002
1行が選択されました。

4. まとめ：インフラの仕組みで解決するのがプロの定石

開発者が個別にワークアラウンド（回避策）を講じるのではなく、データベースというインフラ側の仕組み（トリガー）で縛る。これこそが、複数人での開発や、将来的なアプリケーション接続も見際据えた、最もスムーズでエレガントなアーキテクチャの形です。

★ 本日の日付処理チェックリスト：
1. ツール側でセッションが都度切断される特性をデータベースの機能でカバーする。
2. ADMIN権限を活かし、「AFTER LOGONトリガー」を仕込んでセッション初期化を完全自動化。
3. 環境が整えば、以降は「CURRENT_DATE」を叩くだけで常にスムーズに日本時間を取得可能。

これで言語、日付書式、そして最も難所だった「自動での日本時間取得」まで、クラウド特有の罠をすべてエレガントに攻略し、完璧な開発ベースが整いました！ストレスが一切なくなったところで、次回第4回は、いよいよもう一つの無料枠を使って「19c」インスタンスを追加し、この最新26aiとの本格的な並走比較検証に入っていきます。どうぞお楽しみに！

【Oracle Cloud Free & DB】第2回：初期状態の「世界標準時」を「日本仕様（NLS）」へ変更・保存する設定の定石

前回、無料枠を活用して最新の「26ai」環境を無事に立ち上げることができました。しかし、初期状態のままで言語や通貨の書式、日付の表示形式を確認すると英語仕様になっていたりと、日本の開発環境としては少々使いづらい状態です。今回は、これらの環境を使いやすい「日本仕様」へ変更し、設定を維持する方法を実機検証のログを交えて解説します。

1. クラウド（PaaS）における設定の制限と2つのアプローチ

従来のオンプレミス環境であれば、サーバー側の初期化パラメータ（init.oraやSPFILE）を直接書き換えてシステム全体のNLS設定を「日本仕様」に固定するのが一般的でした。しかし、Autonomous DatabaseのようなフルマネージドなPaaS環境では、クラウド側が基盤を管理しているため、サーバー側の初期化パラメータをユーザーが直接変更することはできません。

そのため、PaaS環境で日本仕様（日本語NLS）を適用・保存するには、以下の2つのアプローチのいずれかを採用するのがクラウドの作法となります。

★ 方法A：開発ツール（接続クライアント）側で設定を保存する
ブラウザ上の「データベース・アクション」自体の機能として、ログイン時に自動で地域・言語設定を適用するようUI上で固定する方法です。
★ 方法B：データベースの「ログオン・トリガー」で自動変更する
データベース内部に「ユーザーがログインした瞬間にセッション設定を書き換える」トリガーを仕込み、永続化（自動化）する方法です。

2. 現在の地域・言語設定（NLS）を確認する

まずは現在のデータベースセッションがどの地域を向いているのか、データ・ディクショナリを叩いて確認してみましょう。

★ 初期状態の確認SQLと結果：
SELECT parameter, value FROM v$nls_parameters WHERE parameter IN ('NLS_LANGUAGE', 'NLS_TERRITORY', 'NLS_DATE_FORMAT');

【実行結果】
PARAMETER VALUE
------------------------
NLS_LANGUAGE JAPANESE
NLS_TERRITORY AMERICA
NLS_DATE_FORMAT DD-MON-RR

※初期状態では言語こそ「JAPANESE」になっているものの、領域（TERRITORY）が「AMERICA」のため、日付書式が西欧風の「DD-MON-RR」になっています。

3. SQL（ALTER SESSION）の実行と、ツール特有の挙動

次に、セッションレベルでの変更コマンドを動かして、動的に日本仕様へ切り替わるか検証します。

★ セッション変更のコマンド群：
ワークシートで以下のSQLを実行します。
ALTER SESSION SET NLS_LANGUAGE = 'JAPANESE';（エラーメッセージ等の日本語化）
ALTER SESSION SET NLS_TERRITORY = 'JAPAN';（通貨や曜日を日本基準に）

★ 実行後の再確認結果：
"PARAMETER" "VALUE"
"NLS_LANGUAGE" "JAPANESE"
"NLS_TERRITORY" "AMERICA"
"NLS_DATE_FORMAT" "DD-MON-RR"

★ 【検証のポイント】値が変わらない理由とは？
実機でALTER SESSIONを実行しても、v$nls_parameters上は「AMERICA」や「DD-MON-RR」のまま変化しないように見えます。これは、ブラウザ上の開発ツールであるデータベース・アクション（SQLワークシート）が、内部で独自のセッション制御（プロキシ接続）を行っているためです。ツール側が接続のたびに設定を上書きしてしまうため、SQLによる動的なALTER SESSIONが一部表面化しないという、クラウドツール特有の挙動（罠）があります。

4. 【解決策】データベース・アクションの機能で日本仕様を固定する

上記のようにツール側の制御が強いため、データベース・アクションを使う場合は、ツールそのものの設定機能を使って地域設定を保存させてしまうのが最も確実で安全なアプローチになります。

★ 設定手順：
1. データベース・アクションの画面右上にある「ユーザー設定（歯車マークやユーザーアイコン）」を開きます。
2. 「ナビゲーション」または「グローバリゼーション（地域設定）」の項目を探します。
3. 言語を「日本語」、地域を「日本」に変更し、日時の書式（NLS_DATE_FORMAT）に YYYY-MM-DD HH24:MI:SS を指定して「保存」します。
★ 効果：ツール側のグローバリゼーション設定を直接書き換えることで、次回以降のログイン時も自動的に設定が引き継がれ、常に日本時間や見慣れた日本の日付フォーマットで結果が返るようになります。

5. まとめ：環境の基礎が整ったら、次は「時刻」の深い罠へ

サーバー側のパラメータを直接いじれないPaaS、そして特有の挙動を持つクラウドツールだからこそ、仕様を正しく把握しておくことが無駄なトラブルを避ける鍵になります。

★ 本日の設定チェックリスト：
1. パラメータを直接変更できないPaaS特有の制限を理解できたか？
2. ツール側のユーザー設定で言語や地域を固定できたか？
3. 今後アプリケーションから接続する際は、AFTER LOGONトリガーの活用を検討できているか？

言語や日付のデフォルト書式といった基礎の土台はこれで完成です。しかし、実はこれだけでは解決しない、クラウド環境における最大の罠が「時刻（SYSDATE）」の挙動に隠されています。次回第3回は、『なぜタイムゾーンを変えてもSYSDATEが日本時間にならないのか？』その理由と解決策に迫ります。どうぞお楽しみに！

【Oracle Cloud Free & DB】第1回：最新26ai環境構築と最初のSELECT文

Oracle Databaseの最新機能を試してみたいけれど、環境構築のハードルが高いと感じていませんか？今回は、すでにOCI（Oracle Cloud）のログインIDをお持ちの方向けに、無料枠（Always Free）をフル活用して最新の「26ai」環境を立ち上げ、ブラウザ上でSQLを実行するまでの最短ルートを整理しました。

1. データベース・インスタンスを作成する

【 現場の感触 】 OCIのメニューは日々進化しています。最新のUIに対応した「迷わない」作成手順を踏むことが、スムーズな環境構築の第一歩です。

★ ナビゲーションの選択：コンソールメニューから「Oracle AI database」＞「Autonomous Database」へ進みます。
★ 「Always Free」のトグルスイッチ（最重要！）：画面中央のスイッチを必ず「ON」にします。これで無料枠のスペックに固定され、課金の心配がなくなります。
★ バージョンの選択：最新のAI機能を試すなら「23ai」（自動的に26aiがプロビジョニングされます）、従来版なら「19c」を選択します。
★ ADMINパスワードの構成：管理者ユーザー用のパスワードを設定し、必ずメモしておきます（※OCI自体のログインパスワードとは異なります）。

2. データベース・アクション（SQL実行画面）を開く

【 現場の感触 】 クライアントツールをPCにインストールする必要はありません。ブラウザだけで完信・完結する強力な開発環境「データベース・アクション」を活用します。

★ ステータスの確認：作成実行後、アイコンが「プロビジョニング中（オレンジ）」から「使用可能（緑）」に変わるまで2〜5分ほど待ちます。
★ ツールの起動：詳細画面上部の「データベース・アクション」ボタンをクリックし、メニューから「SQL」を選択します。
★ 認証のパス：ユーザー名「ADMIN」と、インスタンス作成時に設定した管理用パスワードを入力してログインします。

3. SQLワークシートで一括実行を試す

【 現場の感触 】 SQLの実行ボタンには「1文実行」と「スクリプト実行」があります。複数の検証用SQLをまとめて流すときは、ボタンの使い分けが肝心です。

★ 検証用SQLの記述：バージョン確認用の「v$version」と、現在日時確認用の「dual」からデータを引く2つのSQLをワークシートに貼り付けます。
★ スクリプトの実行（F5キー）：通常の再生ボタン（▶）ではなく、「紙に小さな再生マークが付いたボタン」をクリックすることで、すべてのSQLの結果をまとめて出力できます。

4. まとめ：無料枠で広がる「新旧Oracle」の検証環境

Oracle Cloud Free（Always Free）の素晴らしい点は、この自律型データベース（Autonomous Database）を同時に最大2つまで無料で維持できる点にあります。

★ 本日の検証ログ（スクリプト出力例）：
・Oracle AI Database 26ai Enterprise Edition Release 23.26.2.1.0 - Production
・現在日時：2026-05-16 08:44:46

今回、最新の「26ai」環境が手に入ったことで、話題のベクトル検索やJSON連携などの新機能を自由に試せるようになりました。無料枠はもう1つ残っているため、同じ手順で「19c」を追加すれば、新旧の挙動や実行計画の違いを実機で比較検証する最強の学習環境が整います。さっそく、次の一手を試してみましょう！