TL;DR
- OCI の Always Free の Ampere A1 枠は、2026年6月15日に 4 OCPU/24GB → 2 OCPU/12GB へ半減した。Oracle からの公式告知は無かった（後述・出典あり）
-
半減の1ヶ月後（2026年7月19日）に登録した私のテナンシでも、4 OCPU/24GB が作れて、17日間 ¥0 だった（
usage-apiの実測値。上限超過分の請求も無し） - そのままトライアルが終わると、テナンシ内の A1 インスタンスが「全部」無効化され、30日後に削除される（Oracle 公式ドキュメントに明記）
- 対処は満了前に枠内へ縮小すること。インスタンスを停止せず、RUNNING のまま
updateでリサイズする - 実測: 縮小の所要 2分7秒、エフェメラルなパブリックIPは維持、10コンテナすべて復帰
- 半減するのは CPU とメモリだけではない。VNIC 数と帯域も半減する
この記事の位置づけ（先行記事があります）
半減の事実そのものは、既に複数のメディアと個人ブログが報じています。
- Oracle Quietly Halves Free Tier Ampere A1 Compute Limits with No Public Announcement - InfoQ（2026-07-03）
- Oracle Quietly Cuts Free Tier Ampere A1 Resources in Half - Linuxiac
- Oracle、無料枠のCompute割り当てを予告なく半減 - Tech Collect
- Oracle Cloudの無料枠がいつの間にか半減していた件 - Zenn
- 【緊急】…ダウンスケールする方法を解説 - nomeu.net（コンソール操作の手順あり）
本記事は「発見の報告」ではありません。 実際に本番運用中のインスタンスを縮小した実行記録です。
先行記事が扱っていない次の点を書きます。
| 本記事で扱うこと | 先行記事の状況 |
|---|---|
| CLI での手順（自動化・再現可能） | コンソール操作の解説が中心 |
停止してはいけない理由（Out of Capacity） |
言及を見つけられず |
| 事前のブートボリュームバックアップ（無料枠内） | 同上 |
| メモリ半減に備えた swap の準備 | 同上 |
| エフェメラルIPが維持されたという実測 | 同上 |
| VNIC 数・帯域も連動して半減すること | 同上 |
| 縮小後の性能実測（ARM 2 OCPU の tok/s） | 同上 |
| 半減後に登録しても超過構成が作れ、無課金だったという実測 | 同上 |
| 有料アカウントへアップグレード済みなら削除対象外という分岐 | 同上 |
何が起きたのか
InfoQ の報道（2026-07-03）が要点をまとめています。
Oracle did not publish a blog post, send customer notifications, or make any public announcement. The documentation was simply updated, and users discovered the new limits when their instances were shut down.
拙訳: Oracle はブログ記事を公開せず、顧客への通知も送らず、いかなる公式発表も行わなかった。ドキュメントが更新されただけで、利用者はインスタンスが停止されて初めて新しい上限を知った。
- 発効日: 2026年6月15日
- 月間上限が 3,000 OCPU時間 / 18,000 GB時間 → 1,500 / 9,000 へ半減
- ユーザーからの報告が相次いだのは 6月22日ごろ
「公式告知が無かった」の根拠は報道（二次情報）です。
私自身も Oracle からの通知を確認できませんでしたが、
私のテナンシの作成は 2026-07-19 で、それ以前の告知は届きようがありません。
自テナンシに届いた告知は API で一覧できます（私の場合は IAM の定期メンテナンス1件のみでした）。
oci announce announcements list --compartment-id <tenancy-ocid> --all \
--query 'data.items[*].{t:"time-created",type:"announcement-type",sum:summary}' \
--output table
現行の公式ドキュメント
Always Free Resources の現行記載。
All tenancies get the first 1,500 OCPU hours and 9,000 GB hours per month for free for VM instances using the VM.Standard.A1.Flex shape, which has an Arm processor. For Always Free tenancies, this is equivalent to 2 OCPUs and 12 GB of memory.
拙訳: すべてのテナンシは、Arm プロセッサを搭載した
VM.Standard.A1.Flexシェイプを使う VM インスタンスについて、毎月 1,500 OCPU 時間および 9,000 GB 時間までを無料で利用できます。Always Free テナンシの場合、これは 2 OCPU と 12 GB のメモリに相当します。
超過したときの扱いは Free Tier 側にあります。
If you have more OCI Ampere A1 Compute instances provisioned than are available for an Always Free tenancy, all existing OCI Ampere A1 Compute instances are disabled and then deleted after 30 days, unless you upgrade to a paid account.
拙訳: Always Free テナンシで利用できる数を超えて OCI Ampere A1 Compute インスタンスをプロビジョニングしている場合、有料アカウントへアップグレードしない限り、既存の OCI Ampere A1 Compute インスタンスはすべて無効化され、その30日後に削除されます。
読み飛ばしやすいですが "all existing" です。超過分だけが止まるのではなく、テナンシ内の A1 が全部巻き添えになります。
半減の1ヶ月後に作ったテナンシでも、4 OCPU/24GB が作れて ¥0 だった
半減の発効は 2026年6月15日。私が OCI に登録したのは 2026年7月19日で、1ヶ月以上あとです。
それでも VM.Standard.A1.Flex の 4 OCPU / 24 GB が普通に作れました。警告もエラーも出ません。
そして課金もされませんでした。 usage-api で実測した値です。
| 期間 | SKU | 消費量 | 金額 |
|---|---|---|---|
| 2026-07-20 〜 08-05（17日） | Standard - A1 |
1,621.7 OCPU時間 | ¥0.00 |
| 同上 | Standard - A1 - Memory |
9,730.1 GB時間 | ¥0.00 |
2026年7月のテナンシ全体の課金額も ¥0.00 でした。
消費量に注目してください。現行の Always Free 上限は月 1,500 OCPU時間 / 9,000 GB時間です。
上限を超えて動いていたのに、超過分の請求は発生していません。
# 自分のテナンシで同じことを確認するコマンド
oci usage-api usage-summary request-summarized-usages \
--tenant-id <tenancy-ocid> --granularity MONTHLY --query-type COST \
--time-usage-started 2026-07-01T00:00:00Z --time-usage-ended 2026-09-01T00:00:00Z \
--query 'data.items[*].{m:"time-usage-started",amt:"computed-amount"}' --output table
つまり、
- 登録する（30日のトライアルが始まる）
- 4 OCPU / 24 GB で作れてしまう。警告も課金も無い
- その上に本番を載せる。コンテナを置き、ドメインを向け、cron を組む
- 満了時に超過判定を受ける
私が気づいたのは満了の2週間前でした。すでにコンテナを10個載せ、デプロイ経路まで作った後です。
「半減のニュースを見逃した古いユーザーの話」ではありません。 少なくとも私のテナンシでは、
ニュースの後に登録しても、超過構成が作れて、しかも無課金で動きました。
さらに 戻せない可能性が高いという事情があります。A1 は容量が逼迫していて Out of Capacity が常態です。「一度削除して作り直せばいい」は成立しません。枠を手放したら、同じものは二度と取れないと考えるべきです。
有料アカウントへアップグレード済みなら、話が変わります。
前掲の公式ドキュメントは、削除の条件を "unless you upgrade to a paid account"
（有料アカウントへアップグレードしない限り）と書いています。
有料化していれば、超過していても削除の対象にはなりません（そのぶん課金されます）。
したがってまず自分のアカウント種別を確認してください。無料トライアル中なのか、
既に有料へ切り替えているのかで、取るべき行動が正反対になります。
コンソールの請求画面で、トライアルの残日数が表示されるかどうかが目安になります。
なお私自身は、当時のアカウント種別を後から API で断定できませんでした。
確実に言えるのは上の実測値だけです。7月は課金が発生していません。
自分が該当するか確認する
テナンシ内の A1 インスタンスを列挙して、OCPU とメモリを合計します。
oci compute instance list \
--compartment-id <compartment-ocid> --all \
--query 'data[?"lifecycle-state"!=`TERMINATED` && shape==`VM.Standard.A1.Flex`].{
name:"display-name",
state:"lifecycle-state",
ocpus:"shape-config".ocpus,
mem:"shape-config"."memory-in-gbs"
}' --output table
合計が 2 OCPU / 12 GB を超えていたら該当します。1台で超えている場合も、小さいインスタンスを複数台持っていて合計で超えている場合も同じです。
トライアルの残り日数は、コンソールの請求（Subscription）画面で確認できます。私の場合は Days remaining 13 of 30 と表示され、そこで満了日が確定しました。
対処：RUNNING のままリサイズする
結論のコマンドは1行です。
oci compute instance update \
--instance-id <instance-ocid> \
--shape-config '{"ocpus":2,"memoryInGBs":12}' \
--force --wait-for-state RUNNING
インスタンスを停止しません。 OCI 側が自動で再起動をかけます（公式にも「実行中のインスタンスをリサイズすると再起動される」旨の記載があります）。
なぜ「停止 → リサイズ → 起動」にしないのか
停止すると、起動できなくなる可能性があるからです。
A1 は前述のとおり容量が逼迫しています。停止した瞬間にそのキャパシティは解放され、起動しようとしたときに Out of Capacity で戻ってこないリスクがあります。
RUNNING のままリサイズすれば、OCI が内部で再起動を行うため、キャパシティを手放す瞬間が存在しません。停止経路より明確に安全です。
コンソールの編集画面からでも同じことができますが、手順を残して再現できる点と、満了直前に慌てず実行できる点で CLI を勧めます。
事前にやったこと
1. ブートボリュームのフルバックアップ
oci bs boot-volume-backup create \
--boot-volume-id <boot-volume-ocid> \
--display-name pre-downsize-<date> \
--type FULL
実消費 33 GB、有効期限なし。Always Free のバックアップ枠（5個）に収まるので費用は発生しません。
不可逆に近い操作の前に、退路を1本作っておく話です。
2. swap を用意する
これが地味に効きました。24 GB → 12 GB でメモリが半分になるので、ピーク時の余裕が消えます。私の環境はローカルLLM（Ollama）を毎時ロードするため、OOM Killer が走ると復旧が面倒でした。
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
# 永続化。nofail を必ず付ける
echo '/swapfile none swap sw,nofail 0 0' | sudo tee -a /etc/fstab
sudo systemctl daemon-reload # fstab の構文検証を兼ねる
nofail を付けるのは、fstab の記述ミスで起動不能になる事故を避けるためです。付けておけば、swap が無くても起動します。書き換え前に /etc/fstab のバックアップも取りました。
実測結果
縮小の所要時間は 2分7秒（18:52 開始 → 18:54 完了）。
| 確認項目 | 結果 |
|---|---|
| シェイプ |
ocpus 2.0 / memoryInGBs 12.0
|
nproc |
2 |
| メモリ | 11 Gi total / 1.3 Gi used / 10 Gi available |
| swap |
4.0 Gi が再起動後も有効（nofail の永続化が機能） |
uptime |
0 min（＝再起動されたことの確認） |
| コンテナ | 10個すべて Up・停止中 0件 |
| 外形監視 | 公開URLが HTTP 200（0.96s） |
| cron | crontab が再生成済み |
| パブリックIP | 維持された |
パブリックIPは維持される（実測）
事前にコンソールで確認したところ、予約済みパブリックIPは0件＝使っていたのはエフェメラルIPでした。エフェメラルIPは予約IPへの変換ができず、「再起動で変わるのでは」と身構えていました。
結果は維持です。in-place のリサイズでは、エフェメラルIPも保持されました。
ただしこれは私の1例の実測であって、Oracle が保証しているわけではありません。IPが変わっても困らない状態にしてから実行してください。 私の場合、公開経路は Cloudflare Tunnel（アウトバウンド接続）で、DNS に IP を直接書いたレコードは0件でした。実害は SSH の設定1行だけと分かっていたので踏み切れました。
連動して半減するもの
シェイプの縮小は、OCPU とメモリだけではありません。
| 項目 | 変更前 | 変更後 |
|---|---|---|
maxVnicAttachments |
4 | 2 |
networkingBandwidthInGbps |
4.0 | 2.0 |
VNIC を3枚以上使っている構成だと、ここで詰まります。事前に確認してください。
性能について（測れたことと、測れていないこと）
先に断っておくと、「縮小によって何倍遅くなったか」は私には言えません。 縮小前の 4 OCPU 時点でベンチマークを取っておらず、縮小後は構成を戻せないため、比較のしようがないからです。事前に測っておくべきでした。
測れたのは縮小後の絶対値と、x86 との対照です。同一条件（qwen2.5:7b・temperature 0 / seed 42・128トークン生成・ウォーム3回平均）で、CPU 推論の生成速度はこうなりました。
| 環境 | 生成速度 |
|---|---|
| A1 (ARM) 2 OCPU ← 縮小後の本番 | 3.46 tok/s |
| x86 (E5) 1 OCPU | 4.50 tok/s |
| x86 (E5) 2 OCPU | 7.04 tok/s |
| x86 (E5) 4 OCPU | 8.62 tok/s |
| x86 (E5) 8 OCPU | 8.88 tok/s |
同一 OCPU 数で比べると、ARM は x86 の約半分でした（3.46 対 7.04）。また x86 側は 4 OCPU で頭打ちになっており（8 OCPU にしても +3%）、CPU 推論がメモリ帯域律速であることと整合します。
ただしこの表から「A1 を 4 OCPU にすれば 2倍速い」とは言えません。ARM 側は 2 OCPU の1点しか測れておらず、スケーリング曲線が未知だからです。
私の用途は毎時のバックグラウンド処理なので、多少遅くなっても実害はありませんでした。対話用途で使っているなら、縮小前にベンチマークを取ってから判断してください。（私はそれをしませんでした）
まとめ：確認すべきこと
- テナンシ内の A1 の合計が 2 OCPU / 12 GB 以内かを今すぐ確認する
- 超過しているなら、トライアル満了前に枠内へ縮小する
- 縮小は RUNNING のまま
update。停止経路はOut of Capacityのリスクがある - 事前にブートボリュームのバックアップ（Always Free 枠内なら無料）
- メモリが半分になるので swap を用意（
nofailを忘れずに） - VNIC 数と帯域も連動して半減する
無料枠は「無料である」ことばかり注目されますが、無料であるための条件は提供側が定義していて、こちらの都合とは無関係に変わります。今回は告知なく変わりました。
そしてトライアル中は、その条件が見えません。作成時に警告が出ないぶん、条件を能動的に読みにいく必要がありました。
同種の落とし穴を踏んだ方がいたら、コメントで教えてください。
参考
- Always Free Resources - Oracle Cloud Infrastructure Documentation
- Oracle Cloud Infrastructure Free Tier
- Oracle Quietly Halves Free Tier Ampere A1 Compute Limits with No Public Announcement - InfoQ
- Oracle Quietly Cuts Free Tier Ampere A1 Resources in Half - Linuxiac
- Oracle、無料枠のCompute割り当てを予告なく半減 - Tech Collect
- Oracle Cloudの無料枠がいつの間にか半減していた件 - Zenn
- 【緊急】…ダウンスケールする方法を解説 - nomeu.net