Google Cloud Shell

解決する課題

クラウドを触り始めるたびに、ローカルへ CLI をインストールし、認証情報を設定し、バージョンを合わせる作業はわずらわしく、共有 PC や出先では設定そのものが難しいこともあります。Google Cloud Shell は、ブラウザだけで認証済みの Linux ターミナルをすぐ開けるようにして、この「環境を整える前の手間」を取り除きます。

• ローカルに gcloud や各種ツールを入れずにすぐ Google Cloud を操作したい
• 出先や共有端末でも、自分のアカウントの権限で安全にコマンドを実行したい
• 学習や検証で、使い捨ての作業場がほしい（後片付けを気にしたくない）
• 設定スクリプトや IaC を、前提環境がそろった場所で実行・確認したい
• 簡単なコード編集を、ブラウザ内エディタで済ませたい

主要概念と用語

• Cloud Shell（クラウドシェル）: ブラウザから使える、一時的な仮想マシン上の Linux ターミナル環境。Google Cloud コンソールから起動する
• エフェメラル VM: セッションごとに割り当てられる一時的な仮想マシン。セッション終了後しばらくすると回収され、ホーム以外の変更は失われる
• ホームディレクトリ（永続ストレージ）: ユーザーごとに用意される永続領域。ここに置いたファイルや設定はセッションをまたいで残る
• Cloud Shell Editor: ブラウザ上のコードエディタ。ターミナルと連携してファイル編集・プレビューができる
• プリインストールツール: gcloud CLI、kubectl、git、各種言語ランタイム、エディタなどがあらかじめ導入済み
• Web プレビュー: Cloud Shell 上で起動したローカルサーバーを、一時 URL 経由でブラウザから確認する機能
• Boost モード（性能ブースト）: 一時的に割り当てマシンの性能を引き上げるオプション

仕様・制限・クォータ

• セッションは一時的で、無操作が続くと自動的に切断される。長時間の常駐実行や本番ワークロードの実行場所には向かない
• ホームディレクトリのみ永続化され、それ以外（インストールしたパッケージ、ルート直下の変更など）はセッション回収時に失われる
• 永続ストレージには容量の上限があり、一定期間まったく使わないと内容が削除されることがある
• 1 週間あたりの**利用時間の上限（週次クォータ）**が設けられており、超えると一時的に使えなくなる
• 割り当てられる VM のスペックは固定的で、重い計算や大規模ビルドには非力。必要に応じて Boost を使うか別環境へ移す
• ホームに機密ファイルを長期保管しない。あくまで作業用の一時領域として扱う

内部の仕組み

Cloud Shell を開くと、Google 側でユーザー専用のエフェメラルな仮想マシンが割り当てられ、そこへ永続ホームディレクトリがマウントされます。VM にはコンテナ化された標準イメージが使われ、gcloud をはじめとするツール群があらかじめ含まれています。

• セッション開始時に、ログイン中のアカウントの認証情報が引き継がれるため、改めてログインせずに gcloud が使える
• 作業ファイルはホーム（永続ボリューム）に保存され、VM 本体が回収されても次回のセッションで再びマウントされる
• ホーム以外へ加えた変更（追加インストールなど）は VM の寿命までで、回収時に初期状態へ戻る
• 標準イメージはメンテナンスで更新されるため、ツールのバージョンは時期によって変わりうる

設計パターン / ベストプラクティス

• 学習・検証・緊急対応の入口として使い、本番の自動実行は CI/CD や専用環境へ寄せる
• 環境再現が必要なら、ホームのドットファイルや初期化スクリプトを Git で管理し、新しいセッションでも素早く整える
• 追加ツールやランタイムを固定したい場合は、カスタムイメージを指定して毎回同じ環境で起動する
• 一時的に作ったファイルや認証情報は、作業後に片付ける習慣を持つ（ホームは共有 PC からも自分のアカウントで開ける）
• 重い処理は無理に Cloud Shell で回さず、Boost か別の Compute 環境に切り替える

運用・監視

• 利用は基本的にコンソールから対話的に行うもので、常時監視が必要な常駐サービスではない
• セッションが切れる/開けない → 無操作タイムアウトや週次クォータ超過、ホームのリセットを疑う
• 永続ストレージが消えた → 一定期間未使用での削除に該当しないか確認し、重要データは外部退避を徹底する
• 実行したコマンドのうち、対象リソースへの操作は Cloud Audit Logs 側に記録される（Cloud Shell 内のシェル操作そのものではなく、API 呼び出しが対象）
• 同じ初期化を繰り返すなら、ホームの起動スクリプトにツール導入と設定をまとめると運用が安定する

コスト

Cloud Shell 自体の利用（VM とホームディレクトリ）は、一般に追加料金なしで使えるのが基本です。ただし、Cloud Shell から作成・操作した他のリソース（VM、ストレージ、ネットワークなど）は通常どおり課金されます。コストの観点では「作業場は無料でも、そこから作ったものには料金が発生する」と理解しておきます。

セキュリティ

• セッションはログイン中アカウントの権限で動くため、強い権限のアカウントで開くと、その権限のまま操作できてしまう。最小権限のアカウント/コンテキストで使う
• ホームディレクトリは自分のアカウントに紐づくため、サービスアカウントキーや機密情報を平文で長期保管しない
• 共有端末やブラウザ離席時はログアウトを徹底し、認証セッションを残さない
• 組織側のポリシーで、必要に応じて Cloud Shell の利用可否を制御できる場合がある。統制方針に沿って運用する
• Cloud Shell から行ったリソース操作は Cloud Audit Logs に残るため、誰が何を操作したかは API ログで追跡する

関連サービス・比較

ローカルに導入する gcloud CLI と比べると、Cloud Shell は「すぐ使える代わりに一時的」、ローカル CLI は「環境を整える手間はあるが永続的で高自由度」という違いがあります。

ハンズオン / CLI例

# Cloud Shell はログイン中アカウントで認証済み。現在の設定を確認
gcloud config list
gcloud auth list

# 操作対象のプロジェクトを設定
gcloud config set project PROJECT_ID

# プリインストールされた kubectl のバージョン確認（導入不要で使える）
kubectl version --client

# ホームディレクトリに作業ファイルを置けば次のセッションでも残る
echo "memo" > ~/work-note.txt

# 残したい成果物は外部へ退避（例: Cloud Storage へコピー）
gsutil cp ~/work-note.txt gs://YOUR_BUCKET/work-note.txt