【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、そして特有の挙動を持つクラウドツールだからこそ、仕様を正しく把握しておくことが無駄なトラブルを避ける鍵になります。

★ 本日の設定チェックリスト：

パラメータを直接変更できないPaaS特有の制限を理解できたか？

ツール側のユーザー設定で言語や地域を固定できたか？

今後アプリケーションから接続する際は、AFTER LOGONトリガーの活用を検討できているか？

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