はじめに
本記事では、Oracle Cloud Infrastructure(OCI)のコアサービスであるComputeを運用していく中で、 OCI公式ドキュメントでは見落としがちで私自身が実務でハマったポイント、運用上で考慮が必要なポイントの中から特に注意すべき3つをピックアップして解説します。
今回ピックアップしたものは以下になります。
- Computeの課金対象
- Computeの自動起動/停止設定
- Computeの複製手順(カスタムイメージ)
1.Computeの課金対象
Standard shape、VM.GPU.A10系、およびVMのOptimizedの場合、Computeは停止状態であれば課金がされず、起動状態であれば課金がされるのはご存じかと思います（※Dense I/O・HPC・その他GPU・BM Optimizedは停止中も課金が継続される点にご注意ください）。 ここで1つ注意しなくてはならないのが、起動/停止状態はコンソール（またはAPI/CLI）の表示によるという点です。
つまり、Windows OSであればRemote Desktop Protocol(RDP)を使用したリモートデスクトップ接続、 Linuxの場合はTera Termなどを使用したSSH接続を行い、OS側からのシャットダウンを行ったとしても、 起動状態と認識されてしまい課金がされ続けてしまいます。
※コンソール側では起動状態、実機側では停止状態という乖離が起きてしまいます。
※2026年9月時点において、OSからシャットダウンしても課金は停止しないことが公式ドキュメントに明記されています。そのため、OS側で停止した場合も必ずコンソール/CLI/APIから停止する必要があります。
1.1.回避策
OSから停止した場合も、必ずコンソール、CLI、またはAPIを用いてOCI上から停止処理を行うことが回避策になります。（アプリケーションの停止に15分以上かかる場合は、OS側で先に停止することが公式でも推奨されています。）
OCI CLIを利用する場合、Cloud Shellや管理端末から実行が可能です。コンソールを直接触らせたくないなどの要件がある場合には、別の管理用サーバや端末にCLIを配置して実行することが有効な手段になります。
停止コマンド例：oci compute instance action --instance-id <instance_OCID> --action SOFTSTOP
2.Computeの自動起動/停止設定
運用していく上でComputeの自動起動/停止は必須機能であると思うのですが、 Compute自体に自動起動/停止の設定項目はないため、別のComputeからOCI CLIを利用したスケジュール機能の実装、もしくはOCIネイティブのサービスであるリソース・スケジューラ（Resource Scheduler）を用いた実装の2種類が一般的です。
今回注意すべきなのはリソース・スケジューラを用いた手法で、特にリソース・スケジューラのターゲットを静的に「個別のリソースID」で複数指定している場合に、 その内の1台のComputeを終了（削除）してもリソース・スケジューラ側の設定からは自動で削除されず、残り続けてしまいます。
その結果、存在しないComputeに対しても起動/停止を行おうとするため、リソース・スケジューラ内の存在しているComputeに対しては処理が成功していても、 リソース・スケジューラ全体としての最終実行ステータスが「Error」になってしまいます。
2.1.回避策
リソース・スケジューラに自動起動/停止を設定したComputeを終了する場合は、リソース・スケジューラ側での除外設定も行う必要があります。
【動的指定を利用する】 リソース・スケジューラのターゲット指定を「動的」（タグやコンパートメントでの実行時条件評価）に設定しておけば、終了済みのリソースが残る問題は発生しません。
【静的指定時の対応】 Compute終了後も、インスタンス一覧には「終了(Terminated)」状態で12時間以上残るため、コンソール上からリソース・スケジューラの設定を変更して該当Computeを除外することができます。 一定期間を超えてコンソールから確認・除外できなくなってしまった場合は、以下のCLIコマンド等を用いて、残すリソースのみをJSON形式で指定して更新することで除外が可能です。
更新コマンド例：oci resource-scheduler schedule update --schedule-id <OCID> --resources <JSON>
3.Computeの複製手順(カスタムイメージ)
特に管理エージェントを導入しているComputeに関してですが、管理エージェントを導入したままカスタムイメージによる複製を行ってしまうと 同じOCIDを持つ管理エージェントが複数存在するようになり、OCI内部では同じOCIDを持つ管理エージェントから複数のComputeの情報が送られてくるため、正常な情報を取得することができず、動作不良の原因となってしまいます。
※つまり、2台分の情報が1台としての情報として扱われてしまう。
3.1.回避策
カスタムイメージによる複製後のComputeから管理エージェントをアンインストールし、そこでさらにカスタムイメージを取得して本来のCompute作成を行うという手順が推奨されます。
※リストアをする際に元Computeを完全に終了（削除）する場合であれば考慮不要になります。
ただし、複製後のComputeで通常のアンインストール手順を実行すると、OCI側のManagement Agentサービスから「元のComputeのエージェント」の登録まで解除されてしまい、元のComputeの監視が停止してしまう懸念があるため、注意が必要です。
エージェントの導入方式により手順が異なります。
【A. Oracle Cloud Agentのプラグインとして導入している場合 (Linuxのみ対応)】
公式トラブルシューティングに記載されている以下の手順で、ローカルの状態ディレクトリを削除します（登録解除APIは呼ばれません）。
- sudo systemctl stop oracle-cloud-agent
- (任意) /var/lib/oracle-cloud-agent/plugins/oci-managementagent をバックアップ
- /var/lib/oracle-cloud-agent/plugins/oci-managementagent/polaris と同階層の download ディレクトリを削除
- sudo systemctl start oracle-cloud-agent
【B. スタンドアロン版として導入している場合】
Linuxの場合: 登録解除を伴うアンインストールスクリプトの実行を避けるため、RPMのスクリプトを実行せずにパッケージを削除し、手動でディレクトリを削除します。
- sudo systemctl stop mgmt_agent
- sudo rpm -e oracle.mgmt_agent --noscripts （※複数登録時は --allmatches を付与）
※検証環境で元エージェントがActiveのまま残ることを確認のうえ実施してください。 - /opt/oracle/mgmt_agent および /etc/systemd/system/mgmt_agent.service を手動で削除します。
（ZIP導入の場合は sudo bash /opt/oracle/mgmt_agent/agent_inst/bin/uninstaller.sh を使用しますが、登録解除が走るため実機検証を推奨します。）
Windowsの場合: ZIP導入では OCI への登録解除を避けるため、uninstaller.batを使用せずに、以下の手順で手動削除します。
- サービスの停止（管理者権限の PowerShell またはコマンドプロンプトで実行）
Stop-Service mgmt_agent（または sc stop mgmt_agent）
2.サービスの削除
sc.exe delete mgmt_agent
3.インストールフォルダの削除
インストール先ディレクトリ（デフォルト例: C:\oracle\mgmt_agent）を手動で削除します。
まとめ
本記事では、Computeの運用面において考慮すべきポイントを3つピックアップして解説しました。 OCI公式ドキュメントから読み取りづらい仕様が多々あるため、OCIでの運用をしていく方の参考になれば幸いです。
