Oracle Cloud無料枠は2026年も使えるのか — 登録で弾かれる問題の突破法と半減後のスペック

「永久無料でARM 4コア・24GB RAMのサーバーが使える」——Oracle CloudのAlways Free枠は長らく個人開発者の間で伝説的な存在だった。しかし2026年の今、状況は2つの意味で変わっている。

1. 登録審査が厳格で、そもそもアカウントが作れない人が続出している
2. 2026年6月、Oracleが無告知でARM無料枠を半減した

この記事では、登録で弾かれる問題の突破法と、半減後の最新スペック、それでもなお無料枠で何ができるのかを整理する。

そもそも登録で弾かれる問題

Oracle CloudのAlways Free登録は、開発者の間で「最初の登竜門」と呼ばれるほど失敗報告が多い。クレジットカード情報を入力した直後に「トランザクションを処理できません」と表示され、理由の説明もなくアカウント作成が拒否される。

原因はOracleの不正アカウント作成防止（アンチフラウド）システムだ。無料枠を悪用したマイニングやスパム用アカウントの大量作成が横行した結果、リスクスコアが少しでも高いと判定された申請は自動で弾かれるようになっている。つまり、弾かれたのは運が悪かったわけでも、信用情報に問題があるわけでもない。

審査を突破するための5つの対策

日本で直近（2025年末〜2026年）に登録を成功させた人たちの報告を総合すると、鍵は以下の5点に集約される。

1. ネットワーク環境を変える（最重要）

自宅の固定回線、特にIPアドレスが共有されるIPv4 over IPv6環境は、過去のスパム履歴などでブラックリストに載っているケースがある。スマートフォンのテザリング（キャリアのモバイル回線）に切り替えて登録すると、あっさり通るという報告が非常に多い。VPNやプロキシ経由は一発で弾かれるので論外。

2. 決済カードを変える

JCBブランドは弾かれやすい傾向がある。VISAかMastercardのクレジットカードが推奨。意外なことに、一部のデビットカード（三菱UFJデビットのVISAなど）で一発通過したという直近の成功事例もある。

3. 住所を英語表記で入力する

バリデーションが海外ベースのため、日本語の全角・半角混じり住所でエラーが起きることがある。1-2-3, Minato-ku, Tokyo のように英語表記で入力し、カード会社に登録している住所と完全に一致させること。

4. ブラウザをクリーンな状態にする

uBlock Originなどの広告・トラッキングブロッカーが決済代行会社とのバックグラウンド通信を遮断し、エラーの原因になる。シークレットウィンドウか、拡張機能をすべてオフにしたブラウザで登録する。

5. フリーメールを避ける（可能なら）

Gmailでも通過はするが、独自ドメインやプロバイダのメールアドレスがあればそちらを使う方が信用スコアを下げずに済む。

一度弾かれても、環境を変えて再挑戦すれば通ることは多い。ただし短期間に何度も失敗を繰り返すとスコアがさらに悪化するとの報告もあるため、対策を揃えてから再挑戦するのが賢明だ。

実録: アカウント作成〜インスタンス作成でハマったポイント

筆者自身、過去に一度登録で弾かれた身だが、上記の対策で再挑戦したところ無事にアカウントを作成できた。ここからは実際に手を動かして気づいた、ガイド記事にあまり書かれていないポイントを共有する。

ログインにはMFAアプリが必須

アカウント作成後の初回ログインで、多要素認証（MFA）の設定を求められる。スマートフォンに Oracle Mobile Authenticator アプリをインストールし、PCブラウザに表示されるQRコードを読み取ると完了。Google Authenticatorではなく専用アプリな点に注意。以降のログインはこのアプリで承認する。

ARMを選ぶとOSイメージの選択肢が激減する

インスタンス作成でイメージを選ぼうとすると、Ubuntuの場合ARM（aarch64）対応は「Canonical Ubuntu 24.04 Minimal aarch64」（と22.04 Minimal aarch64）しか表示されない。

「Minimalしかないのか」と不安になるが、問題ない。Minimalは通常版からsnapや一部ツールを削った軽量版で、apt は普通に使える。必要なパッケージは後から入れればよく、12GB RAMを節約できる分むしろ好都合だ。

なおOCIのUIは、先にShapeをA1.Flexに変更してからイメージを選ぶと互換イメージだけにフィルタされる仕様。イメージから先に選ぶと、x86用イメージも混在した一覧から自力でaarch64を探すことになる。

Shape選択画面の「1 (80 max)」に惑わされない

Shape選択で「Browse all shapes」を開くと、Ampereカテゴリに VM.Standard.A1.Flex（Always Free-eligible） が1つだけ表示される。ここで「OCPU: 1 (80 max) / Memory: 6 (512 max)」と表示されるため、「2 OCPU / 12GBの選択肢がない？」と混乱しやすい。

これはデフォルト値と上限の表記であって、選択肢がないわけではない。「Select shape」を押して作成画面に戻ると、OCPU数とメモリのスライダーが現れるので、そこで 2 OCPU / 12GB に設定する。

注意点として、スライダー自体は80 OCPU / 512GBまで動かせてしまう。無料枠の上限は2 OCPU / 12GB（Free Tierアカウントの場合）なので、超えないように設定すること。画面上部の「Don't see the shape you want? → Upgrade」の案内も、無料枠だけ使うなら無視してよい。

……と書きたかったのだが、筆者の環境（2026年7月に作成した新規Free Tierテナンシー）では、スライダーが1 OCPU / 6GBまでしか動かなかった。ドキュメント上の上限は2 OCPU / 12GBのはずだが、新規Free Tierアカウントはさらに絞られている可能性がある。半減が無告知で行われた前例を考えると、この辺りの実際の上限は「自分のテナンシーのLimits画面で確認する」しかない。

Networking設定の罠が多い

インスタンス作成ウィザードのNetworkingステップは、初見殺しのポイントが集中している。

• デフォルトが「Select existing virtual cloud network」になっている。 新規アカウントにはVCNが存在しないので、ドロップダウンは空のまま。「Create new virtual cloud network」に自分で切り替える必要がある
• VNIC nameとVCN nameは別物。 一番上の入力欄はNICの名前で、VCNの名前はラジオボタン切り替え後に出る「New virtual cloud network name」に入れる
• VCN名・subnet名は空だとwarningが出るので入力必須
• 「Automatically assign public IPv4 address」のトグルが反応しないことがある。「Create new public subnet」を選んでいても「You must select a public subnet」の警告が出続け、トグルがオンにできない。これはウィザードのバグ的挙動で、無視して進めてよい。public subnetとして作られていれば、インスタンス作成後に「Attached VNICs → IPv4 Addresses → Edit → Ephemeral public IP」で後付けできる

そして「Out of host capacity」へ

設定を終えてCreateを押した結果がこれだ。

Out of capacity for shape VM.Standard.A1.Flex in availability domain AD-1. Create the instance in a different availability domain or try again later.

噂通りの在庫切れ。しかもエラーメッセージは「別のavailability domainで試せ」と言うが、東京リージョンにはAD-1しか存在しないので、この助言は無意味だ。取れる手段は「空くまでリトライ」の一択となる。

なお、エラーが出てもリソースは何も作成されないので、Createボタンは何度押しても安全。手動リトライなら、インスタンス整理が走った直後とされる日本時間の早朝（4〜7時）が狙い目という報告が多い。本命はOCI CLIでの自動リトライで、これは後述する。

【重要】2026年6月、ARM無料枠が無告知で半減された

登録の話の前に、まず知っておくべき最新ニュースがある。

2026年6月15日、OracleはAlways FreeのAmpere A1（ARM）枠を4 OCPU / 24GB RAMから2 OCPU / 12GB RAMに半減した。 公式アナウンスは一切なく、ドキュメントが静かに書き換えられただけ。多くのユーザーは自分のインスタンスが突然シャットダウンされて初めて変更を知った。

• 旧: 月3,000 OCPU時間 + 18,000 GB時間（= 4 OCPU / 24GBを常時稼働）
• 新: 月1,500 OCPU時間 + 9,000 GB時間（= 2 OCPU / 12GBを常時稼働）

なお、この半減は無料アカウント（Free Tier）が対象で、Pay As You Go（従量課金）にアップグレードしたアカウントは従来の4 OCPU / 24GBを引き続き無料で使えるという報告がある。ただしOracleのサポート回答は錯綜しており、ドキュメント上は「全テナンシー対象」と書かれている。PAYGへのアップグレードはカード審査を再度通す必要があるが、Always Free枠内の利用なら課金は発生しない。確実に4 OCPU構成を維持したいならPAYG化が現実的な選択肢だ。

半減後のAlways Free枠スペック（2026年7月時点）

半減されたとはいえ、2 OCPU / 12GB RAM + 200GBストレージ + 月10TB転送が永久無料というのは、依然として他社と比較にならない水準だ。AWSやGCPの無料枠（t2.micro / e2-micro、1GB RAM前後、12ヶ月限定または常時1台）と比べると桁が違う。

無料枠でできること

2 OCPU / 12GB RAMのARMサーバーで現実的に運用できるものを挙げる。

Webサービスの本番運用

• FastAPI / Node.js / Goなどのアプリケーションサーバー。個人開発レベルのトラフィックなら余裕
• リバースプロキシ（Caddy / Nginx）+ 複数サービスの同居
• 月10TBの転送量は個人サイトではまず使い切れない

データベース・ストレージ系

• PostgreSQL / MySQL / SQLiteの運用。12GB RAMならそれなりのデータ量も捌ける
• NextcloudやMinIOでプライベートクラウドストレージ
• 別枠のAutonomous Database（20GB×2）も併用可能

自動化・常駐系

• cron / systemdによる定期バッチ、スクレイピング、データ収集
• Discord / Slack / LINE Bot の常駐
• GitHub Actionsのセルフホストランナー
• Uptime KumaやHealthchecksでの監視

開発・検証

• Docker / Docker Composeでの検証環境（ARM64イメージは今やほぼ揃っている）
• VPN（WireGuard / Tailscale exit node）
• Minecraftサーバー（12GB RAMなら小規模コミュニティは十分）

厳しくなったもの

• ローカルLLMの運用。旧24GB RAMなら7B〜13Bクラスの量子化モデルが動いたが、12GBだと7Bの量子化が限界ライン。実用速度を求めるなら用途を絞る必要がある
• Kubernetes（k3s）のマルチノードクラスタ。旧枠では4ノード構成が定番だったが、現枠では窮屈

実録・後編: OCI CLIで自動リトライ2週間 → 全敗

「空くまでリトライ」を実行に移した。手動で押し続けるのは非現実的なので、OCI CLIで自動化する。

セットアップの要点

brew install oci-cli

認証はAPIキー方式。openssl genrsa で鍵ペアを作り、~/.oci/config にユーザーOCID・テナンシーOCID・リージョン・鍵のfingerprintを書き、公開鍵をコンソール（My profile → Tokens and keys → Add API key）に登録するだけ。

ここで面白い発見があった。CLIでテナンシーのサービス上限を引くと:

oci limits value list --service-name compute --name standard-a1-core-count
# → value: 41

A1のサービス上限は41 OCPU / 277GBもある。コンソールのスライダーが1 OCPU / 6GBで止まるのはサービス上限ではなく、Free Tierアカウントに対するUI側の制御ということだ。実際、CLIから2 OCPU / 12GBを直接リクエストすると受理される（返ってくるのは在庫切れエラーのみ）。

リトライスクリプト

要点だけ抜き出すとこうなる（VCN・subnetは事前にCLIで作成しておく）:

while true; do
  oci compute instance launch \
    --shape VM.Standard.A1.Flex \
    --shape-config '{"ocpus":2,"memoryInGBs":12}' \
    --image-id "$IMAGE" --subnet-id "$SUBNET" \
    --assign-public-ip true \
    --ssh-authorized-keys-file ~/.ssh/id_ed25519.pub 2>&1 \
    | grep -q '"lifecycle-state"' && break   # 成功したら抜ける
  sleep 300   # 5分間隔（これ以上詰めるとレート制限を食らう）
done

Macで回すなら nohup caffeinate -i ./retry.sh & でスリープを防いで放置する。実際、間隔5分×2サイズ試行を数日続けたところOracleのAPIスロットリング（429 TooManyRequests）を食らったので、間隔は5〜10分が現実的な下限だ。

結果: 2週間・約1,500回・成功ゼロ

• 2 OCPU / 12GB: 約800回 → 全て「Out of host capacity」
• フォールバックの1 OCPU / 6GB: 160回超 → 最小構成ですら一度も空きなし
• 深夜・早朝の「狙い目時間帯」も全滅

俗説の「リトライすればそのうち取れる」は、少なくとも2026年夏の東京リージョンでは通用しなかった。Free Tierアカウント向けのA1在庫は、実質的に存在しないと結論づけざるを得ない。

最終手段: PAYGアップグレード → 一発で確保

残された手段がPay As You Go（従量課金）へのアップグレードだ。重要なのは、PAYG化してもAlways Free枠は消えず、無料範囲内なら請求ゼロという点。変わるのは:

• 在庫の優先度が有料顧客扱いになる
• ARM無料枠が旧来の4 OCPU / 24GBに戻る（半減は Free Tier のみ）
• アイドルインスタンスの回収対象から外れる
• 代わりに「無料枠を超えたら普通に課金される」ようになる（Free Tierは超過作成自体がブロックされる）

アップグレードは Billing & Cost Management → Upgrade and Manage Payment から。カード審査は登録時と同じ仕組みなので、登録突破時と同じ環境（テザリング+同じカード）でやるのが安全だ。筆者は申請から翌日に完了メールが届いた。

課金事故が怖いので、先にBudgets（予算アラート）を仕込んでおく:

oci budgets budget budget create --amount 500 --reset-period MONTHLY ...
oci budgets budget alert-rule create --type ACTUAL --threshold 10 ...
# 月500円予算、50円使った時点でメール警告

そして、PAYG切り替え完了後に4 OCPU / 24GBを投げた1回目:

"lifecycle-state": "PROVISIONING"

一発で通った。 2週間1,500回の全敗が、アップグレード直後の1回で終わった。数分後にはSSHで入れる状態になり、nproc=4、メモリ23Gi、Ubuntu 24.04 aarch64。コンソールUIで悩まされたpublic IPトグル問題も、CLI経由なら --assign-public-ip true で素直に付与された。

おまけ: 確保した4コアARMでローカルLLMはどこまで動くか

せっかくの4 OCPU / 24GBなので、ローカルLLMの実力を測ってみた。Ollamaはaarch64にワンライナーで入る:

curl -fsSL https://ollama.com/install.sh | sh
ollama pull qwen2.5:7b   # 4.7GB
ollama run qwen2.5:7b --verbose "AIについて200字程度で説明してください。"

実際の様子がこれだ（コールドスタートからリアルタイム速度のまま録画。前半のスピナーがモデルロード待ち約9秒、その後ストリーミング生成、最後に--verboseの統計とtimeの実測が表示される）:

数字を拾うと: モデルロード9.3秒 + プロンプト処理2.9秒 + 生成7.7秒（49トークン） = 質問から回答完了まで約20秒（コールドスタート込み、time実測25秒はSSH接続込み）。2回目以降はロードが不要になるので、体感はぐっと軽くなる。

モデルサイズ別の実測。比較対象は筆者の自宅サーバーで、スペックは以下の通り:

自宅側はOllamaが自動でGPUにオフロードする（VRAM 4GBに収まらない分はCPUで実行）。結果:

この表には明確なパターンがある。VRAM 4GBに収まる小型モデルでは自宅サーバーが4倍速で圧勝。しかしVRAMから溢れるサイズになると、差はほぼ消える（14Bで4.3 vs 3.3 tok/s）。CPU推論はメモリ帯域勝負なので、GPUを持っていても溢れた瞬間に土俵が同じになるわけだ。

つまり無料ARMの立ち位置は「VRAMに収まらないサイズのモデルを、自宅サーバーとほぼ同速で、電気代ゼロで回せるマシン」。7Bの6 tok/sは対話にはやや遅いが、1000トークンの出力が約3分——夜間バッチ（要約・タグ付け・分類など）なら一晩で100件以上を処理できる計算で、十分実用圏だ。RAMは24GBあるので14Bクラスも余裕で載る。

運用上の注意を一つ。複数モデルを同時にロードすると速度が激減する（3Bが12.9→2.2 tok/sまで落ちた）。CPU推論はメモリ帯域勝負なので、モデルは1つずつ動かすのが鉄則だ。

まとめ

• 登録で弾かれるのは日常茶飯事。テザリング + VISA/Mastercard + 英語住所 + クリーンなブラウザで再挑戦する価値は十分ある
• 2026年6月にARM枠は無告知で半減（4 OCPU/24GB → 2 OCPU/12GB）。さらに新規Free TierはUI上1 OCPU / 6GBまでしか設定できなかった
• 「リトライすれば取れる」はもう俗説。 実測2週間・約1,500回で成功ゼロ。最小の1 OCPU構成すら空きがなかった
• 本気で使うならPAYG化が実質必須。 在庫は一発で確保でき、4 OCPU / 24GBに戻り、アイドル回収もされない。Always Free範囲内なら請求ゼロだが、Budgetsアラートは必ず設定すること
• 無告知で枠が削られた前例がある以上、消えたら困るワークロードはバックアップと移行手段を常に確保しておくこと

「タダより高いものはない」を地で行くクセの強さは健在だが、仕組みを理解して段取りを踏めば、4コア24GB・転送10TB/月のARMサーバーが月0円という結果は今でも手に入る。この記事がその段取りの地図になれば幸いだ。

参考リンク

• Oracle Cloud Free Tier（公式）
• Always Free Resources（公式ドキュメント）
• InfoQ: Oracle Quietly Halves Free Tier Ampere A1 Compute Limits