2026-08-17 公開 ／ サーバー・インフラ

Oracle Cloud無料枠で小さなサーバーを始める前に決める6項目と、1年運用して分かった落とし穴

クラウドの無料枠で個人のサーバーを立てるとき、詰まるのは作成手順ではありません。作ったあと数か月してから効いてくる設定を、作成前に決めていなかったことです。この記事では、作る前に決めておく6項目と、実際に1年以上運用して初めて分かった3つの落とし穴を分けて書きます。

前提：無料枠でどのくらいのものが動くか

2026年8月時点で、Arm系のインスタンスは合計 2 OCPU / メモリ 12GB、ブロックストレージはブート領域を含めて合計 200GB が無料枠の対象です。個人が使う範囲では、静的サイトの配信、小さなWebアプリ、定期実行のバッチ、VPN の終端くらいまでは十分に動きます。

逆に言うと、この規模で足りない用途（動画のエンコード、大きなデータベース、常時高負荷の処理）を無料枠でやろうとすると、途中で必ず行き詰まります。用途を先に決めて、足りるかどうかを判断してから作るのが結局いちばん早いというのが、6項目の出発点です。

作成前に決める6項目

1. 用途を1つに絞る

「とりあえず立てて、あとで考える」で作ったサーバーは、公開設定とストレージが少しずつ増えていきます。増えたぶんを後から削るのは、最初に絞るより難しい。静的サイトの配信なのか、自分専用のツール置き場なのか、検証環境なのか、用途を1つ書き出してから作成に進みます。

用途が2つ以上あるなら、無料枠の範囲で2台に分けるほうが後が楽です。1台に同居させると、片方を作り直したいときにもう片方が人質になります。

2. ホームリージョンを決める

ホームリージョンは、後から変えられる前提で選ばないほうがよいものの代表です。決めるときに見るのは次の3つです。

• 利用する場所からの距離（そのまま応答速度に出ます）
• 使いたいサービスがそのリージョンで提供されているか
• 無料枠のインスタンスが実際に取得できるか（人気のリージョンは容量が空くまで待つことがあります）

3つ目は見落としがちですが、実務上いちばん詰まります。作成ボタンを押した瞬間に容量不足で弾かれることがあるので、「取れなかったときにどこを第2候補にするか」まで先に決めておくと、その場で悩まずに済みます。

3. 小さい構成から作る

無料枠の上限まで最初から割り当てず、用途に足りる最小構成で作ります。後から増やすほうが、減らすより簡単だからです。

このとき必ず確認したいのが Arm 対応 です。無料枠で枠が大きいのは Arm 系のシェイプですが、使いたいソフトウェアが Arm 版を配布していないことがあります。公式が x86 のバイナリしか出していない、コンテナイメージが Arm に対応していない、といったケースです。作ってから気づくと、OS ごと作り直しになります。入れる予定のソフトを一覧にして、Arm 対応を先に調べてください。

4. ストレージを使い切らない

200GB はアカウント全体の枠であって、1台あたりの枠ではありません。ブート領域と追加ボリュームの合計で数えます。1台目で使い切ると、2台目が作れなくなります。

初回は既定の容量のまま作り、空きを残しておくのが安全です。あとで2台目を立てたくなったとき、あるいは一時的にバックアップ用のボリュームが必要になったときに、枠が残っているかどうかで打てる手が変わります。

5. 公開範囲を最小にする

外部に公開する必要がないなら、パブリックIPも受信ルールも増やさないのがいちばん安全です。公開する場合は、次を最初にやります。

• 必要な通信だけを許可する（80/443 を開けるなら、それ以外は開けない）
• 管理用の接続はパスワードを使わず、鍵認証だけにする
• OS の更新、管理者アカウントの保護、バックアップの確認を、公開する前に済ませる

公開してすぐ実感するのは、個人の小さなサイトでも自動化されたスキャンは常時来るということです。実際、当サイトのアクセスログの上位には、設置してもいない WordPress の管理画面や、既知の脆弱性を持つプラグインのパスへのリクエストが並びます。これは特定の誰かに狙われているわけではなく、公開IPを持っている全ホストに対して機械的に投げられているものです。「小さいから狙われない」は成り立ちません。公開する前に閉めるべきものを閉めておく、という順序だけが効きます。

6. 料金と稼働を見張る

無料対象のラベルが付いているかを作成画面で確認し、予算通知を設定します。ただし予算通知は自動停止ではありません。超えたら知らせてくれるだけなので、「そもそも超えない構成にしておく」が前提になります。

あわせて、稼働状況を定期的に見る仕組みを最初に作っておくことを勧めます。理由は次の落とし穴3に書きます。

ここからが本題：1年運用して分かった落とし穴

ここまでは作成前の話です。ここからは、動き始めて数か月してから効いてくるものです。作成手順を紹介する記事にはあまり書かれていませんが、実際に困るのはこちらでした。

落とし穴1：自動更新を入れても、更新は「適用」されるだけで「有効化」されない

Ubuntu 系で unattended-upgrades を有効にしておけば、セキュリティ更新は自動で当たります。ここまでは期待どおりです。問題はその先で、更新されたパッケージを掴んで動いているサービスは、自動では再起動されません。

つまり、共有ライブラリに脆弱性の修正が入っても、そのライブラリを起動時に読み込んだプロセスは古いままのコードで動き続けます。ファイル上は新しいのに、メモリ上は古い、という状態です。

「再起動が必要なら教えてくれるはず」と思うところですが、再起動要求のフラグは一部のパッケージしか立てません。実際に手元のサーバーを調べたところ、フラグが立っていない状態で、10以上のサービスが古い共有ライブラリを掴んだまま動いていました。

対策として検査を増やす方向もありますが、個人で運用する規模なら定期的に再起動してしまうのがいちばん確実です。月に1回、アクセスの少ない時間帯に再起動する設定を入れておけば、この問題はまとめて解消します。検査を足すと、検査そのものが壊れていないかを確認する手間が増えます。

落とし穴2：タイムゾーンが UTC のまま、定期実行を日本時間の感覚で書いてしまう

クラウドのインスタンスは、初期状態でタイムゾーンが Etc/UTC になっていることがあります。この状態で定期実行（cron やタイマー）を設定すると、書いた時刻は UTC として解釈されます。

日本時間は UTC+9 なので、「深夜3時に走らせるつもり」で書いた設定は昼の12時に動きます。バックアップや再起動のような、負荷がかかる処理や一瞬止まる処理を仕掛けていた場合、いちばん見られたくない時間帯に動くことになります。

対処は2つあり、どちらでも構いませんが混ぜないことが重要です。

• サーバーのタイムゾーンを日本時間に変更して、設定も日本時間で書く
• タイムゾーンは UTC のままにして、設定を UTC に換算して書く（この場合、設定ファイルにコメントで「これは UTC」と明記する）

私は後者にしています。ログの時刻とサーバー間の突き合わせが UTC のほうが揃うためです。ただしその代わり、時刻を書いた全ファイルに「UTC」と注記するのを運用ルールにしています。半年後の自分はまず間違いなく日本時間で読みます。

落とし穴3：使っていない無料インスタンスは回収されることがある

無料枠のインスタンスは、一定期間ほとんど使われていないと「アイドル」と判定され、通知のうえで停止・回収の対象になりうるとされています。公開されている条件は、おおむね7日間にわたって CPU・ネットワークの利用率が継続して低い状態が続いた場合です。

これが効いてくるのが、「作ったけれど誰も来ないサイト」を置いているケースです。個人サイトの立ち上げ期はまさにこの状態なので、順調に育てている途中で足元のインスタンスが消える、ということが起こりえます。

対策は、負荷を偽装することではありません（それは規約の趣旨に反しますし、根本的な解決になりません）。「消えたらどう戻すか」を先に決めておくほうが実用的です。具体的には次の3つです。

• 設定ファイルと配信内容を、サーバーの外（Git リポジトリなど）に必ず置いておく
• 新しいインスタンスに一から組み直す手順を、文書として1本用意しておく
• その手順を、実際に一度だけ通しで試しておく（読むだけでは必ず抜けが見つかりません）

無料枠は、可用性の保証があるものではありません。「いつ消えてもよい前提で使う」と決めてしまえば、無料枠は非常に扱いやすい道具になります。逆に、消えたら困るものを載せた瞬間に、無料であることの意味がなくなります。

作成前チェックリスト

• 用途を1つに絞った
• ホームリージョンを決め、取れなかったときの第2候補も決めた
• 入れる予定のソフトウェアが Arm に対応しているか調べた
• 無料対象のラベルと割り当て量を作成画面で確認した
• ストレージの枠を使い切らず、空きを残した
• 公開する通信を必要最小限にし、管理用の接続を鍵認証だけにした
• 予算通知とバックアップを設定した
• 月次の定期再起動を設定した（落とし穴1）
• タイムゾーンを確認し、定期実行の時刻表記を統一した（落とし穴2）
• 再構築の手順書を作り、一度通しで試した（落とし穴3）

まとめ

無料枠でサーバーを立てること自体は、画面の指示に従えば30分で終わります。難しいのはそこではなく、数か月後に効いてくる設定を、作成前に決めておけるかどうかです。この記事の前半6項目は作る前の話、後半3つは動かしてからの話ですが、後半3つも結局は「最初に決めておけば防げたもの」でした。

特に落とし穴1と2は、問題が起きていることに気づきにくいという共通点があります。更新が効いていないことも、定期実行が想定と違う時刻に動いていることも、エラーにならないので何も知らせてくれません。動いているように見えている、というのがいちばん厄介な状態です。