ローカル環境では完璧だった自作アプリ。しかし、Azure（App Service + PostgreSQL）にデプロイした途端、データの登録日時が「9時間前」を指している……。
「プログラムのバグか？」「PostgreSQLのタイムゾーン設定をSQLで直すべきか？」と焦って調査を開始しましたが、実は解決策はAzureポータル上の「環境変数」を1行足すだけでした。
今回は、知っているだけでトラブルを秒速で解決できる、クラウドサービスを使いこなすことの重要性について共有します。
1. 迫りくる「9時間の壁」
AzureのApp Service（Linux）やデータベースは、デフォルトでは世界標準時（UTC）で動いています。日本（JST）との時差はちょうど9時間。
未設定のままデプロイすると、アプリが「いま何時？」とサーバーに聞いた際にUTCが返ってきてしまい、そのままDBに「9時間前の過去」が刻まれてしまうのです。
2. 解決策：コード修正不要。Azureの環境変数を追加するだけ
当初は「プログラム内で AddHours(9) するか？」とも考えましたが、それは悪手です。Azureというプラットフォーム側で解決するのがスマートな方法でした。
実際に行った手順はこれだけです：
1. Azure Portalで対象の App Service を選択。
2. [設定] ＞ [環境変数] を開く。
3. アプリケーション設定に以下の設定を追加して保存。
• 名前: WEBSITE_TIMEZONE
• 値: Asia/Tokyo
これだけで、App Service上のLinux OSの時間が日本時間に切り替わり、プログラムが吐き出す時刻も、DBに保存される時刻も一発で正常化しました。
3. 「調査」も大事だが「クラウドの仕様」を知る方が早い
今回の件で痛感したのは、「クラウドサービスを使いこなす」ことの威力です。
• プログラムの調査: コードを追い、テストし、再デプロイする（数時間〜）。
• DBの調査: パラメータを調べ、再起動の影響を考える（数十分〜）。
• Azureの設定: 環境変数を1行足すだけ（わずか30秒）。
「何かがおかしい」と思ったとき、まずは「Azure側で用意されているスイッチはないか？」と疑ってみる。この視点を持つだけで、開発効率は劇的に変わります。
4. 知ればすぐ対応できる。それがAzureの便利さ
クラウドのトラブルは「難しい」と思われがちですが、実は「知っているか、知らないか」だけの違いであることも多いです。
今回のように、WEBSITE_TIMEZONE というキーワードさえ知っていれば、余計な工数を使わずに済みます。プログラミングスキルと同じくらい、「クラウドという道具をどう使いこなすか」という知識をアップデートし続けることの重要さを改めて実感しました。
まとめ：トラブルを「仕様の理解」でねじ伏せる
Azure App Service + PostgreSQLの構成で日時のズレに遭遇したら、まずはポータルへ向かいましょう。
1. WEBSITE_TIMEZONE = Asia/Tokyo を設定する。
2. 動作確認する。
3. 浮いた時間で、より本質的な開発に集中する。
これこそが、現代のエンジニアにとっての「最短ルート」です。