皆さま、こんにちは!y.takanashiです。
本記事はOracle Cloud Infrastructure Advent Calendar 2025 シリーズ1 のDay 1 を担当しています!
今回はクラウド・シェルについて紹介します。
OCIのアドベントカレンダーには、これで4年連続の参加🎉となりました。
これまでに書いた記事はこちら👇
「【Oracle Cloud】オブジェクト・ストレージ対応のストレージ管理サービスについて」(2022年)
「GitHub リポジトリをOCI DevOpsと連携」(2023年)
「OCI DRGの構成要素について解説してみる」(2024年)
今年(2025年)は 10本の記事投稿を目標としていましたが、今年も忙しさに追われ、以下の記事(6本)のみで目標を達成できませんでした…。
「OCI モニタリングを詳しく解説する」(2025/1/21 投稿)
「OCI モニタリングでイベントベースのアラームを作成する」(2025/2/4 投稿)
「OCI IAM ポリシー 基本」(2025/2/21 投稿)
「OCI IAM ポリシー 詳細」(2025/4/9 投稿)
「OCI上のRHELサーバにOracle Linux Premier Supportを適用する」(2025/10/7 投稿)
「Oracle AI World 参加レポート:新戦略とAI関連サービスの最新動向」(2025/10/21 投稿)
来年(2026年)こそは目標の10本達成🔥 を掲げつつ、わかりやすいOCI記事をお届けしていきます!💪✨
クラウド・シェルとは?
クラウド・シェル(Cloud Shell)とは、OCIコンソール上で利用可能なターミナル環境です。
2025年3月のアップデートにより、クラウド・シェルのOSはOracle Linux 7 → 8 に更新されました。(2025年12月時点)
クラウド・シェルには以下のツールがあらかじめインストールされており、追加のパッケージインストールなしで利用できます。
- Git
- Java
- Python
※複数のバージョンがクラウド・シェルに含まれているため、`csruntimectl python list`を実行して使用可能なPythonバージョンのリストを取得し、`csruntimectl python set <python-alias>`を実行してPythonバージョンを切り替えます。 - OCI SDK(Java,Python,Go,TypeScriptおよびJavaScript)
- Podman
- Terraform
- Ansible
- kubectl 等
特に、OCI CLIはセットアップに認証情報の登録が必要なため、クラウド・シェルで即利用できる点は非常に便利で、筆者も日常的に活用しています。
クラウド・シェルを使用する際の注意点
ネットワーク構成
クラウド・シェルはユーザごとに割り当てられたプライベート環境で動作しており、ユーザのテナンシ内に存在するわけではありません。
このインスタンスはユーザのテナンシ内には存在せず、パブリック / プライベートIPアドレスのいずれも公開されていないため、pingでのネットワーク疎通確認はできません。
ただし、ncコマンドなどを利用したポートスキャンでの疎通確認は可能です。
永続ストレージは5GBのみ
クラウド・シェルには1ユーザにつき、5GBの永続ストレージが提供されます。
外部ストレージのマウントはサポートされていないため、大容量ファイルの保存には向きません。
そのため、クラウド・シェルは開発・検証用途で使用、本番利用時は別途コンピュート・インスタンスの利用を推奨します。
また、6ヶ月以上利用がない場合はテナンシ管理者に通知メールが届き、60日後に自動削除されます。
回避策として、クラウド・シェルのセッションを一度起動すればタイマーがリセットされ、削除を防ぐことができます。
アップロードファイルのマルウェアスキャンは非対応
クラウド・シェルでは、アップロードしたファイルに対するウイルススキャン機能は提供されていません。
安全性を確保するため、事前にローカル環境でスキャンしたファイルのみアップロードすることを推奨します。
Podmanベースのコンテナ管理
「クラウド・シェルとは?」でも記載した通り、2025年3月のアップデートにより、クラウド・シェルのOSは Oracle Linux 7から8へ更新され、新たにPodman が採用されました。
※従来利用されていたDocker Engineは削除されています。
Podmanはデーモンレスのコンテナ管理ツールで、より軽量・安全に動作します。
なお、互換性確保のために docker コマンドのエイリアスも用意されているため、従来の操作方法のままでも利用可能です。
ブラウザとサービス間通信にWebSocketを使用
クラウド・シェルでは、ブラウザとサービス間の通信にWebSocketを使用しています。
そのため、ブラウザ側でWebSocketが無効になっている場合や、WebSocketを無効している企業プロキシ経由でアクセスしている場合、コンソールからクラウド・シェルを起動しようとすると、「予期しないエラーが発生しました」といったエラーメッセージが表示され、正常に利用できません。
利用環境によっては注意が必要です。
sudoの操作は不可
クラウド・シェルでは root権限やsudoコマンドは使用できません。
そのため、root権限が必要なパッケージのインストールは行えませんが、代替としてユーザ権限で利用できる主要ツールがすでに導入済みです。
また、ユーザ権限でインストール可能なパッケージは、ホームディレクトリに配置して使用可能です。
ホーム・リージョン上に配置
クラウド・シェルのインスタンスは、ユーザの テナントのホーム・リージョン に作成されます。
OCIコンソール上でリージョンを切り替えても、クラウド・シェル環境は変わりません。
ただし、ネットワークタイプによってはホームリージョン外のリソースにアクセスできない場合があります。
(詳細は後述の「4.クラウド・シェルのネットワーク」を参照)
セッション時間
クラウド・シェルの1セッションあたりの最大利用時間は24時間です。
また、60分間操作が行わない場合は非アクティブ状態となり、自動的にタイムアウトします。
CPUアーキテクチャの確認(OCI ファンクション実行時のみ)
クラウド・シェルは ARM / x86_64 のいずれかのアーキテクチャで動作しています。
アーキテクチャを変更する方法として、OCIコンソール画面の「Cloud Shell」を選択します。
初回起動時は、以下のような表示が出力され、クラウド・シェルのインスタンス起動に最大で 10分程度要する場合があります。
※2回目以降は30秒程度でインスタンスが立ち上がります。

「アクション」から「アーキテクチャ」を選択します。
画面では「ARM (aarch64)」となっていますが、デフォルトでは現在のアーキテクチャは「プリファレンスなし」と表示されます。
任意のアーキテクチャ(ここでは「X86_64」)を選択し、「再起動」を選択します。
再起動は1分程度要します。
完了後、再度アーキテクチャの確認画面を表示すると、「現在のアーキテクチャ」が選択したタイプとなっています。
OCI FunctionsなどでCPUアーキテクチャを統一していない場合、アプリケーションが動作しない可能性があるため注意が必要です。
また、アーキテクチャを切り替える際はローカル環境ファイルが切り替わり初期化される場合もあるため、こちらも注意が必要です。
※ホームディレクトリ内のファイルは保持されます。
操作方法
ここでは、OCIクラウド・シェルを利用するための操作手順と必要なIAMポリシーについて説明します。
必要なIAM ポリシー
クラウド・シェルを使用するには、対象のグループに以下のポリシーを付与する必要があります。
Allow group <ドメイン名>/<グループ名> to use cloud-shell in tenancy
※`Default`ドメインを使用する場合、<ドメイン名>/ は省略可能です。
このポリシーは テナンシ・レベルのみ でサポートされており、コンパートメント・レベルでの設定はサポートされていません。
そのため、文末の in tenancy は固定となります。
ポリシーが付与されていないユーザーがクラウド・シェルを利用しようとした場合、
以下のようなポップアップが表示されます。
利用制限(拒否)設定
特定のグループやユーザーに対して クラウド・シェルの利用を一律で禁止したい場合は、IAMポリシーではなくコンパートメント割り当て(Quota/Assignment)機能 を使用して利用を制限することを推奨します。
設定手順について、「ガバナンスと管理」→「割当て制限ポリシー」を選択します。
「割当て制限の作成」から以下を入力、「作成」を選択し以下の割当て制限ポリシーを定義します。
- 名前:任意(ここでは「cloud-shell-policy」)
- 説明:任意(ここでは「クラウド・シェルの利用制限ポリシー」)
- 割当て制限ポリシー:Zero cloud-shell quotas in tenancy
割当て制限ポリシーはホーム・リージョンでのみ設定可能です。
割当ての詳細については、以下のOCI公式ドキュメントをご覧ください。
OCI公式ドキュメント - 「コンパートメント割当て制限の概要」
クラウド・シェル上のファイルのアップロード
クラウド・シェルは、ローカル環境にあるファイルをクラウド・シェルのホームディレクトリへアップロードできます。
手順は以下の通りです。
クラウド・シェルを起動し、右上の歯車アイコンから「アップロード」を選択します。
表示されたポップアップから、任意の方法でローカルファイル(ここでは「text.txt」を選択します。
「アップロード」を選択すると、画面右上に進捗ステータスが表示され「完了済」となるとクラウド・シェルへのアップロードが完了します。
注意点として、クラウド・シェルはホームディレクトリのみアップロード先として指定でき、他のパスは選択できません。
また、一度に1つのファイルのみ、アップロードすることが可能です。
クラウド・シェル上のファイルのダウンロード
クラウド・シェル上にあるファイルを、ローカル環境にダウンロードすることも可能です。
右上の歯車アイコンから「ダウンロード」を選択します。

表示されたポップアップに、ダウンロードしたいファイル名(ここでは「test2.txt」)を入力、「ダウンロード」を選択します。

ステータスが表示され、「完了済」となればダウンロードは完了です。

注意点として、ダウンロード対象に指定できるのはホームディレクトリにあるファイルのみです。
サブディレクトリや他パスのファイルはダウンロードできません。
クラウド・シェルのネットワーク
ここではクラウド・シェルによって提供される以下3つのネットワーク・モードについて解説します。
- OCIサービス・ネットワーク
- パブリック・ネットワーク
- プライベート・ネットワーク
OCIサービス・ネットワーク
OCIサービス・ネットワークはクラウド・シェルがデフォルトで利用する専用ネットワークであり、パブリック・インターネットを経由せずにOCIサービスへアクセスできる点が特徴です。
このネットワークを利用することで、セキュアかつ安定したアクセスを実現できます。
例として、ホーム・リージョンに作成したオブジェクト・ストレージ・バケット内のファイルを確かめるとします。
以下のように実行すると、バケット内のオブジェクト情報(メタデータ)が取得できます。
oci os object list -bn <バケット名> -ns <ネーム・スペース名>
注意としてOCIサービス・ネットワークには制約があり、アクセス可能なのはホーム・リージョン内のリソースに限られます。
パブリック・ネットワーク
パブリック・ネットワークとは、その名の通りクラウド・シェルからパブリック・インターネットを経由してアクセス可能なサービスを利用する際に使用されるネットワークです。
OCIサービス・ネットワークではアクセスできないホーム・リージョン外のリソースにもアクセスできる点が特徴です。
例として、ホーム・リージョン外に作成したオブジェクト・ストレージ・バケット内のオブジェクト情報を取得してみます。
以下のようにパブリック・ネットワーク使用時は、問題なくオブジェクト情報(メタデータ)が取得できます。
注意点として、パブリック・ネットワークを利用するためには、対象ユーザが所属するグループに以下のポリシーを付与する必要があります。
ポリシー付与後は、既存のセッションは切断し、再度起動する必要があります。(新しいセッションでポリシーが有効化されます。)
Allow group <ドメイン名>/<グループ名> to use cloud-shell-public-network in tenancy
※`Default`ドメインを使用する場合、<ドメイン名>/ は省略可能です。
上記のポリシーが付与されていない場合、以下のポップアップが表示され、パブリック・ネットワークの使用はできない仕様となっています。
なお、管理者はOCIの「セキュリティ・ゾーン」を利用することで、パブリック・ネットワークを使用することを制限できます。
セキュリティ・ゾーンの詳細については以下ドキュメントをご覧ください。
Cloudiiブログ - 「OCI セキュリティ・ゾーン + クラウド・ガードで可用性を高める」
プライベート・ネットワーク
プライベート・ネットワークを利用することで、クラウド・シェルからパブリック・ネットワークを経由せずに、VCN内のコンピュート・インスタンスへ直接アクセスできます。
これにより、閉域網経由でのよりセキュアな接続が可能になります。
尚、アクセス対象となるのはホーム・リージョン内のVCNおよびサブネットに限られます。
ホーム・リージョン外のサブネットへアクセスしたい場合、OCIの「VCNクロスリージョン・ピアリング」を使用します。
VCNクロスリージョン・ピアリングについて、本記事の主題から逸れるため、ここでの詳細な説明は割愛します。
詳細は以下のドキュメントをご覧ください。
OCI公式ドキュメント - 「クラウド・シェルのネットワーキング」
プライベート・ネットワークを利用するために、対象グループへ以下のIAMポリシーを付与する必要があります。
※管理者権限(Administrators グループ)に所属するユーザーの場合、デフォルトで設定されている全操作許可のポリシーに包含されているため、設定は不要です。
Allow group <ドメイン名>/<グループ名> to use subnets in compartment <compartment>
Allow group <ドメイン名>/<グループ名> to use vnics in compartment <compartment>
Allow group <ドメイン名>/<グループ名> to use network-security-groups in compartment <compartment>
Allow group <ドメイン名>/<グループ名> to inspect vcns in compartment <compartment>
また、注意点として、プライベート・ネットワークは対象のサブネット内に擬似的なSSH接続用のコンピュート・インスタンスが一時的に作成され、そのインスタンス経由でクラウド・シェル・セッションが確立されます。
そのため、サブネット内に最低1つの未使用IPアドレスが確保されている必要があります。
サブネット内に空きIPが1つも存在しない場合、クラウド・シェルはそのサブネットにアタッチできず、プライベート・ネットワークを利用することはできません。
クラウド・シェルで利用できるプライベート・ネットワークは以下の2種類があります。
- プライベート・ネットワーク定義リスト
- エフェメラル・プライベート・ネットワーク
プライベート・ネットワーク定義リスト
プライベート・ネットワーク定義リストは、事前に作成したネットワーク定義リストを基に、クラウド・シェルからVCN内のコンピュート・インスタンスへアクセスできるサービスです。
プライベート・ネットワーク定義リストの設定手順について、クラウド・シェルの起動後「ネットワーク」→「プライベート・ネットワーク定義リスト」を選択します。
「プライベート・ネットワーク定義の作成」から以下の項目を入力、「作成」を選択します。
- 名前:任意(ここでは「My private network 1」)
- VCN、サブネット:対象コンピュートが存在するVCNとサブネット
- ネットワーク・セキュリティ・グループ:必要に応じて選択
- アクティブなネットワークとして使用:チェックすると、作成後クラウド・シェルが自動でこの定義に接続
作成が完了すると、プライベート・ネットワーク定義がリストに追加されます。
クラウド・シェル起動時に自動でプライベート・ネットワークへ接続させたい場合は、デフォルト・ネットワークをプライベート・ネットワーク定義に変更します。
定義リストは最大5個まで「お気に入り」を設定でき、お気に入りの定義リストは上位表示されます。
(添付画像はお気に入りが無効で、有効にすることで星型のアイコンが青色に変更されます。)

試しに、定義リスト内のコンピュート・インスタンス(10.0.1.96)にアクセスしてみます。
すると、SSH接続できるのがわかります。
エフェメラル・プライベート・ネットワーク
エフェメラル・プライベート・ネットワークは、その名の通り一時的に有効であるプライベート・ネットワークで、定義リストを作成せずに、VCNを選択するだけで作成できるのが特徴です。
エフェメラル・プライベート・ネットワークの作成方法について、「ネットワーク」から「エフェメラル・プライベート・ネットワーク」を選択します。
接続するコンピュート・インスタンスがあるVCN、サブネットを選択して「アクティブなネットワークとして使用」を選択します。
ネットワークが「エフェメラル・プライベート・ネットワーク」に切り替わります。
再度同じコンピュート・インスタンスに接続が成功します。

比較
ここまで紹介した4つのサービスについて、それぞれの特徴を比較してみます。
| 機能 / ネットワーク | OCIサービス・ネットワーク | パブリック・ネットワーク | プライベート・ネットワーク定義リスト | エフェメラル・プライベート・ネットワーク |
|---|---|---|---|---|
| 説明 | デフォルトで利用する専用ネットワーク。 パブリックを介さずにOCIサービスへアクセス可能 | パブリック経由でOCI サービスにアクセスするネットワーク | パブリックを介さず、VCN 内のコンピュートへ永続的に接続できるプライベートネットワーク | パブリックを介さず、VCN 内のコンピュートへ一時的に接続できるプライベートネットワーク |
| メリット | セキュアにホームリージョンの OCI サービスへアクセス可能 | ホームリージョン外の OCI サービスにもアクセス可能 | 定義リスト設定により、永続的で安定したプライベートアクセスを実現 | 定義リスト不要で手軽にプライベートアクセスを実現 |
| デメリット | ホームリージョン外のリソースにはアクセス不可 | パブリックに出るため追加 IAM ポリシーが必要でセキュリティ制約が増える | 事前にプライベート・ネットワーク定義の作成が必要 | エフェメラル(一時)であるため、セッション終了時に再作成が必要 |
| ユースケース | ホーム・リージョン内のOCIサービスにアクセスする場合 | 他リージョンのOCIサービスへアクセスが必要な場合 | SSH 相当の操作を クラウド・シェル経由で安定して行いたい場合 プライベートサブネットのコンピュートを継続的に管理したい場合 | 単発作業でプライベートサブネットに接続したい場合 定義リストを作らず素早くプライベート接続したい場合 |
まとめ
クラウド・シェルは、OCIコンソール上からすぐに利用できるターミナル環境で、GitやPython、OCI CLIなど多くの開発ツールがあらかじめインストールされているため、追加セットアップなしで作業開始できるのが大きな特徴です。
また、Oracle Linux 8 ベースの環境で提供され、Podmanによるコンテナ管理にも対応しています。
一方で、永続ストレージが 5GB に限定されていることや、root 権限が使用できない点、6ヶ月間未使用の場合に自動削除対象となる点など、利用時に注意すべき事項もあります。
さらに、ネットワークは「OCIサービス・ネットワーク」「パブリック・ネットワーク」「プライベート・ネットワーク」に分かれており、アクセス可能なリソースや必要な IAM ポリシーが異なります。
特にプライベート・ネットワークを利用する場合は、サブネット内に未使用 IP が必要となる点にも注意が必要です。
これらの特性を理解することで、クラウド・シェルを開発・検証用途で効率的かつ安全に活用できるようになります。
以上となります。
この記事を通じて読者の皆様の問題解決の一助となれば幸いです。
どうぞ良い年末年始をお過ごしください~!



























