はじめに
こんにちは、NTT東日本の樋口です。
デジタル革新本部 デジタルデザイン部で、内製開発組織のCoEとしてOutSystemsの開発標準化や共通機能の整備をやっています。
OutSystems Developer Cloud（ODC）のランタイムDBはAmazon Aurora PostgreSQLなのですが、2026年3月にOutSystemsから PostgreSQL 13→16へのメジャーバージョンアップ のお知らせが来ました。
今回はこのアップグレードを実際にやってみたので、その記録を残しておきます。
弊社の環境にはミッションクリティカルな商用ワークロードがなく、最悪何か起きても許容できるので、ある程度割り切って進めました。
本番で重要なシステムを動かしている方は、もっと慎重にやる必要があると思います。あくまで一例として読んでいただければと思います。
ODCのインフラアップデート管理は、O11時代からだいぶ変わった
PostgreSQLバージョンアップの本題に入る前に、そもそもODCのインフラアップデートの仕組み自体がO11（OutSystems 11）からかなり変わっているので、先にそこから見ていきましょう。
O11時代：何をするにもサポートチケット
O11のCloud環境だと、インフラ周りの作業は基本的にサポートとチケットでやり取りするしかありませんでした。プラットフォームのアップグレードのスケジュール調整なども、基本的にはチケットを経由する必要がありました。
そうなると、スケジュールをちょっとずらしたいだけでも、チケット起票 → 返信待ち → 日程調整…のラリーが発生するので、複数環境を持っているとしんどいところがありました。
ODC時代：ポータルで全部できる
ODCでは、2026年3月にセルフサービスのインフラメンテナンススケジューリング機能がリリースされて、この辺の運用がかなりやりやすく変わりました。
ODC Portalの 「Maintain → Platform updates → Infrastructure」から、こんな感じで全部セルフサービスでいけます。
| できること | 説明 |
|---|---|
| スケジュール確認 | 予定されているアップデートの一覧・影響範囲・タイムフレームを確認 |
| リスケジュール | ステージ（Dev/Test/Prod）ごとに、決められた期間内で好きな日時に変更できる |
| ステータス追跡 | アップデートの進行状況（User scheduled → In progress → Updated など）をリアルタイムで確認できる |
| Breaking Changesの確認 | ドキュメントへのリンクから事前に影響を確認できる |
なお、リスケジュールを行えるのは Administrator ロールを持つユーザーのみ です（公式ドキュメントより）。
チケットを切る必要がなくなり、管理者ロールがあればポータル上でポチポチするだけで良いので、O11と比べると格段に楽になりました。O11時代にサポートとの日程調整で消耗した経験がある人ほど、この変化はありがたいと思います。調整のリードタイムがほぼゼロになったのは嬉しいポイントです。
やってみた：PostgreSQL 13→16 アップグレード
アップデート内容の確認
ODC Portalの Maintain → Platform updates → Infrastructure を開くと、PostgreSQL 16へのアップグレードが来ているのが見えます。
※このスクリーンショットは、アップグレード完了後に取得したものです。
View details をクリックすると、こんな情報が出てきます：
- 影響: 最大1時間の更新作業、最大30分のダウンタイム
- Breaking Changes: 破壊的変更の有無や内容
- タイムフレーム: リスケジュール可能な期間
- 各ステージの状態: Dev / Test / Prod それぞれのスケジュール状況
ちなみに、、、
- アップデートは 必須（mandatory） なので、スキップはできません
- リスケジュールできるのは 決められたタイムフレーム内 だけです
- 何もしなければ、OutSystemsが設定した日時で自動的に実行されます
（公式ドキュメントより）
実際にやったこと
Step 1: 破壊的変更を受ける箇所のチェック
公式からアナウンスされているBreaking Changesの情報をもとに、破壊的変更の影響を受ける箇所がないかをチェックします。今回、私たちのアプリケーションでは該当する箇所はありませんでした。
もし破壊的変更の影響を受けるものがある場合は、計画を立てて修正していく必要があります。
Step 2: まずDev環境のアップグレード
- ODC Portalで Development ステージの
Rescheduleをクリック - 深夜帯（業務影響が少ない時間）を選択
-
Reschedule updateをクリック → ステータスがUser scheduledに - 指定した時間になったら、OutSystems側でアップデートが実行される
Step 3: アップグレード後の動作確認
ステータスが Updated に変わったら、アプリの動作確認を行いました。
今回は破壊的変更がなかったため、机上では影響がないと判断していましたが、念のため、SQLを直接記述している箇所や、アプリケーションの主要な業務ルートの動作確認を行いました。
結果として、特に影響はないことを確認できました。
Step 4: 残りのステージも同様に
Devで問題なしを確認したうえで、同じ手順でTest → Prodも順次やりました。特に問題なし。
Breaking Changesについて
PG13→PG16はPG14・PG15の変更も巻き取るので、以下のBreaking Changeが公式からアナウンスされていました（公式ドキュメント参照）。
いくつかありましたが、一例として、EXTRACT関数の戻り値の精度が変わるといったものがありました。他にもあるので、詳細は公式ドキュメントを参照しながら進めてみてください。
EXTRACT関数の戻り値精度が変わる
-- 例：タイムスタンプ 2024-06-01 00:00:01 に対して
SELECT EXTRACT(EPOCH FROM {Entity1}.[Timestamp]) / 3600 AS hours_since_epoch
FROM {Entity1}
| バージョン | 結果 | 小数桁数 |
|---|---|---|
| PG13 | 477000.000277778 |
9桁 |
| PG16 | 477000.000277777778 |
12桁 |
OutSystemsの標準的なAggregate（ビジュアルクエリ）だけ使っている分には、まず影響ないと思いますが、Advanced QueryでEXTRACTを直接書いている場合 は注意が必要です。
自分の環境では該当クエリがなかったので影響ゼロでしたが、OutSystemsのコミュニティフォーラムでは、10万件超のテーブルで クエリのパフォーマンスが落ちて、インデックスの追加が必要になった という報告が上がっていました。（ OutSystems Forum より）
バージョンアップで実行計画が変わるのはPostgreSQLにおいてはよくあるので、特に大きめのテーブルを持っている環境では、先行環境でしっかり確認しておいた方がいいと思います。
気になりそうなところ
Q1: ロールバックはできる？
A. PostgreSQLのバージョン自体を戻す手段は、ユーザー側にはありません。
ODCのインフラアップデートはOutSystems側が管理・実行しているので、DBを元のバージョンに巻き戻すような操作は提供されていません。
アップデート中にエラーが起きた場合は、ステータスが Error になり、自動で再スケジュールされます。
ただし、アプリレベルのロールバック はODC Portalの Deployments から可能です。特定のリビジョンを選んで再デプロイすれば、アプリのコードは以前の状態に戻せます。
| レベル | ロールバック | 方法 |
|---|---|---|
| インフラ（DB） | ❌ 不可 | OutSystems管理。エラー時は自動再スケジュール |
| アプリケーション | ✅ 可能 | ODC Portal → Deployments からリビジョンを選んで再デプロイ |
Q2: 環境間でバージョンが違う期間、どうする？
ODCは各ステージ（Dev / Test / Prod）で個別にスケジュールできるので、タイミング次第で Dev=PG16、Prod=PG13 みたいな状態が一時的に発生します。
今回はこうしました。
- 意図的にDevを先行 させて、PG16固有の問題がないか確認
- 問題なければ 数日〜1週間くらいで Test → Prodも順次アップグレード
- バージョンが違う期間を、なるべく短くすることを意識
この期間は、基本的に商用環境へのデプロイは極力控えるようにしました。もし改修や機能追加を行う際は、以下のポイント、特にSQLを実装するときに注意して進めました。
- Dev=PG16で開発した新しいSQLが、まだPG13のProd環境でも動くかどうかを頭に入れておく
- PG14〜16で新しく使えるようになった機能（例：MERGE文〔PG15で追加〕など）をうっかり使うと、まだPG13のままのProdでエラーになりうる
- 逆に、PG13で動いていたクエリがPG16で遅くなる可能性もあるので、先行環境での確認は大事
まとめ
ODCのインフラアップデート管理は、O11時代と比べて本当に楽になりました。 チケットのやり取りなしで、スケジュール調整からステータス追跡までポータル上で完結できるのは、開発者/運用者体験としてかなり良くなったと感じます。
一方で、PostgreSQLのメジャーバージョンアップそのものは、操作がセルフサービス化されても中身はしっかり見ておく必要があります。今回は影響がありませんでしたが、Advanced Queryで直接SQLを書いている場合や、大きめのテーブルを持っている環境では、Breaking Changesの確認と先行環境での動作確認を怠らないのがポイントです。
※記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。