1. Google Cloud CLI のインストールと認証

Google Cloudを操作する基盤となるCLI（gcloud）をセットアップします。 2026年現在の実務では、手動管理による「属人化」を防ぐため、OSのパッケージ管理システム（apt）を利用したインストールが標準です。

STEP 1：既存環境の「健康診断」（現状確認）

まずは、あなたの環境が現在どのような状態でインストールされているかを確認します。ターミナルで以下のコマンドを実行してください。

[bash]現在の状態を確認

which gcloudn

which gcloudn

判定結果の確認

• 【合格：公式ルート】 /usr/bin/gcloud と表示された場合
  OSのパッケージ管理下にあり、理想的な状態です。そのまま [STEP 4：動作検証と認証設定] へ進んでください。
• 【要修正：手動ルート】~/google-cloud-sdk/bin/gcloud 等と表示された場合
  過去に tar 形式で展開し、ホームディレクトリ等に直接配置してパスを通した「野良インストール」の状態です。長期運用ではアップデート漏れのリスクがあるため、[STEP 2：旧環境のクリーンアップ] で整理しましょう。
• 【未導入】 何も表示されない、または not found の場合
  [STEP 3：最新の apt 方式による構築] へ進んでください。

STEP 2：旧環境のクリーンアップ

判定結果が /usr/bin/gcloud 以外（例：~/google-cloud-sdk/bin/gcloud）だった方は、新環境を導入する前に以下の整理を行います。

1. インストールディレクトリの削除

[bash]1. 念のため、削除対象のディレクトリが存在するか確認

ls -d ~/google-cloud-sdk

ls -d ~/google-cloud-sdk

[bash]2. ディレクトリを丸ごと削除

rm -rf ~/google-cloud-sdk

rm -rf ~/google-cloud-sdk

2. シェル設定ファイルに追記されたパスの削除

手動インストールの際、gcloud コマンドを使えるようにするために .bashrc や .zshrc に書き込まれた設定（環境変数）を掃除します。これを忘れると、新しくインストールした後も「ファイルが見つからない」というエラーの原因になります。

[bash]1. 設定ファイルを開く（Ubuntu標準の nano エディタを使用）

nano ~/.bashrc

nano ~/.bashrc

[bash]2. ファイルの末尾付近にある、以下のような記述を探して削除（または行頭に # を入れてコメントアウト）

　　　　　例: export PATH=”~/google-cloud-sdk/bin:$PATH”
　　　　　例: source ~/google-cloud-sdk/path.bash.inc

[bash]3. 修正を保存して閉じる（Ctrl+O -> Enter -> Ctrl+X）

[bash]4. 設定を現在のターミナルに反映

source ~/.bashrc

source ~/.bashrc

STEP 3：最新の apt 方式による構築

OSの更新フローに統合し、セキュリティアップデートを自動化する最新の手順です。

[bash]パッケージリストの更新と必要なツールの導入 ※ Ubuntu 24.04/26.04では apt-transport-https は不要です

sudo apt-get update
sudo apt-get install ca-certificates gnupg curl -y

sudo apt-get update
sudo apt-get install ca-certificates gnupg curl -y

[bash]公開鍵のインポート ※ URLは将来変更される可能性があるため、エラー時はGoogle公式ドキュメントを確認してください

curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/cloud.google.gpg

curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/cloud.google.gpg

[bash]リポジトリ情報を追加

echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list

echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list

[bash]インストールの実行

sudo apt-get update && sudo apt-get install google-cloud-cli -y

sudo apt-get update && sudo apt-get install google-cloud-cli -y

Technical Note:
Ubuntu 24.04以降では apt-key は完全に非推奨です。本手順では /usr/share/keyrings を使用する、セキュリティ要件を満たした最新の方式を採用しています。

STEP 4：動作検証と認証設定

本手順により、gcloud は OS の更新フローに統合され、個人の手作業に依存しない「運用可能な状態」になりました。最後に、Google Cloud への接続を有効化します。

[bash]パスの再確認（/usr/bin/gcloud になっていれば成功）

which gcloud

which gcloud

[bash]1. ブラウザ経由でのログイン認証

gcloud auth login

gcloud auth login

[bash]2. 操作対象プロジェクトの設定

gcloud config set project [PROJECT_ID]

gcloud config set project [PROJECT_ID]

[bash]3. 【重要】Terraform や Ansible 等を利用する場合は以下を実行 ※ gcloud CLI 単体での利用時は不要です

gcloud auth application-default login

gcloud auth application-default login

2. Terraform のインストールと GCS による状態管理（State）の確立

Terraformは、Google Cloud上のネットワークやVMといった「インフラの箱」をコードで定義するツールです。
本体（CLI）の導入以上に、作成したインフラの「状態（State）」をどう管理するかが、実務における成否を分けます。

ここでは、Terraform本体の導入に加え、実務で必須となる「設計図の保管場所（GCS）」を構築し、Stateをクラウドへ移行するまでを手順化します。

STEP 1：既存環境の「健康診断」（現状確認）

Terraformは特に手動バイナリ配置（tar）が行われやすいツールです。まず、現在の管理状態を正しく把握しましょう。

[bash]1. 実行パスを確認

which terraform

which terraform

[bash]2. リポジトリの登録状況を確認

apt policy terraform

apt policy terraform

判定結果の確認

• 【合格：最強の状態】 which が /usr/bin/terraform で、かつ apt policy の出力に https://apt.releases.hashicorp.com が含まれている。
  公式リポジトリ経由で導入されています。そのまま [STEP 4：【実務の核心】GCS バケットの作成と State 移行] へ進んでください。
• 【要修正：野良ルート】 which の結果が /usr/local/bin/terraform や ~/.local/bin/terraform である。
  手動でバイナリを配置した状態です。バージョン更新が手動になり、事故の元となるため、[STEP 2：旧環境のクリーンアップ]で整理しましょう。
• 【要修正：更新遅延ルート】 apt policy の出力が ubuntu.com 系のみで、HashiCorp公式が含まれていない。
  Ubuntu標準リポジトリ版です。動作はしますが、最新機能の追従が遅いため、[STEP 3：最新の apt 方式による構築]で公式リポジトリに乗り換えましょう。

STEP 2：旧環境のクリーンアップ

手動ルートだった方は、新しい apt 方式と競合しないよう、既存のバイナリを削除します。

[bash]STEP 1 の which で表示されたパスを削除します ※ 一般的な手動配置パスの例（sudoが必要な場合があります）

sudo rm /usr/local/bin/terraform

sudo rm /usr/local/bin/terraform

[bash]STEP 1 の which で表示されたパスを削除します ※ 個人のローカルディレクトリに置いていた場合（sudo不要）

rm ~/.local/bin/terraform

rm ~/.local/bin/terraform

STEP 3：最新の apt 方式による構築

HashiCorp社の公式リポジトリをOSのパッケージ管理に統合します。

[bash]1. 必要なツールの導入

sudo apt update
sudo apt install -y gnupg curl

sudo apt update
sudo apt install -y gnupg curl

[bash]2. 公式 GPG 鍵のインポート（セキュリティ要件を満たす最新方式）

curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg

curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg

[bash]3. 公式リポジトリの追加）

echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list

echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list

[bash]4. インストールと動作検証

sudo apt update && sudo apt install -y terraform

sudo apt update && sudo apt install -y terraform

[bash]5. 結果確認 ※パスが /usr/bin/terraform になれば成功です

which terraform
terraform --version

which terraform
terraform --version

STEP 4：【実務の核心】GCS バケットの作成と State 移行

ローカルに tfstate を置いたままにせず、即座にクラウド管理へ切り替えます。

[bash]1. 初期設定ファイルの作成 terraform ディレクトリで、まずバケットを作るための最小構成を書きます。

cd ~/Projects/gc/[PROJECT-ID]/terraform
nano main.tf

cd ~/Projects/gc/[PROJECT-ID]/terraform
nano main.tf

[HCL] 初期設定ファイル main.tf

# main.tf
provider "google" {
  project = "[PROJECT-ID]"
  region  = "us-west1"
}

# State保存用のバケット定義
resource "google_storage_bucket" "tf_state" {
  name          = "[PROJECT-ID]-tfstate" # 世界で一意の名前
  location      = "US"
  versioning { enabled = true } # 履歴管理を有効化
}

# main.tf
provider "google" {
  project = "[PROJECT-ID]"
  region  = "us-west1"
}

# State保存用のバケット定義
resource "google_storage_bucket" "tf_state" {
  name          = "[PROJECT-ID]-tfstate" # 世界で一意の名前
  location      = "US"
  versioning { enabled = true } # 履歴管理を有効化
}

[bash]2. バケットのデプロイ

terraform init
terraform apply  # ここで「yes」と入力

terraform init
terraform apply  # ここで「yes」と入力

[HCL] 初期設定ファイル main.tf ※ Backend の有効化（State のクラウド移行） バケットができたら、main.tf の冒頭に以下を追記します。

terraform {
  backend "gcs" {
    bucket = "[PROJECT-ID]-tfstate"
    prefix = "terraform/state"
  }
}

terraform {
  backend "gcs" {
    bucket = "[PROJECT-ID]-tfstate"
    prefix = "terraform/state"
  }
}

[bash]3. 追記後、再度 terraform init を実行します。

terraform init

terraform init

[bash]4. Do you want to copy existing state to the new backend? と聞かれるので yes と回答。

これでローカルから GCS へ State 移行が完了し、インストールが「実務レベル」で完了しました。

STEP 5：【重要】確立後の疎通・正常性確認

移行が成功したことを、以下の3つの観点で確認します。

① ローカルファイルの「中身」を確認

移行が成功すると、ローカルにある terraform.tfstate は空（またはバックアップのみ）になります。

[bash]1. ローカルにある terraform.tfstate の中身を確認

cat terraform.tfstate
# 何も表示されない、または「"version": 4」などの最小限の記述になっていればOK

cat terraform.tfstate
# 何も表示されない、または「"version": 4」などの最小限の記述になっていればOK

② Google Cloud 上のオブジェクトを確認

実際に GCS バケット内に State ファイルが転送されているかコマンドで確認します。

[bash]2. Google Cloud 上のオブジェクト gs://[PROJECT-ID]-tfstate/terraform/state を確認

gcloud storage ls gs://[PROJECT-ID]-tfstate/terraform/state
# 「default.tfstate」が表示されれば成功です

gcloud storage ls gs://[PROJECT-ID]-tfstate/terraform/state
# 「default.tfstate」が表示されれば成功です

③ Terraform によるロック確認

現在、GCS 経由で正しく State が読み込まれているかを確認します。

[bash]3. Terraform によるロックを確認 ※クラウド上のStateを読み込めていることを確認

terraform state list
# 「google_storage_bucket.tf_state」が表示されれば、クラウド上のStateを読み込めています

terraform state list
# 「google_storage_bucket.tf_state」が表示されれば、クラウド上のStateを読み込めています

アドバイス: gcloud storage ls でファイルが見えたとき、初めて「自分のインフラ設計図はクラウドに守られた」と確信できます。
この確認作業を怠ると、万が一設定をミスしてローカル管理に戻った際、チーム開発で事故に繋がります。

3. Ansible のインストールと IAM / OS Login による接続基盤の確立

Ansibleは、Terraformが作成した「箱（インフラ）」に対し、OS設定やミドルウェアの導入といった「中身」を構成します。 2026年現在のUbuntu環境では、システム保護（PEP 668）により pip での不用意なインストールは制限されています。OSと調和した「壊れない」管理手法を確立しましょう。

【事前条件】Google Cloud 設定の確認

本ガイドの手順は、対象のプロジェクトおよびインスタンスで OS Login が有効化されていることを前提としています。

STEP 1：既存環境の「健康診断」（現状確認）

AnsibleはPython環境に依存するため、インストール先によって安定性が激変します。まずは現状を診断しましょう。

[bash]現在の ansible のパスを確認

which ansible

which ansible

判定結果の確認

• 【合格：安定ルート】 /usr/bin/ansible と表示された場合
  OSのパッケージ（apt）として管理されています。そのまま[STEP 4：IAPトンネル経由のセキュア接続設定]へ進んでください。
• 【要注意：地雷リスク】~/.local/bin/ansible や /usr/local/bin/ansible の場合
  過去に pip や手動ビルドで導入された状態です。OSアップデート時に突然動かなくなるリスクがあるため、[STEP 2：旧環境のクリーンアップ]を推奨します。
• 【未導入】 何も表示されない場合
  [STEP 3：最新の方式による構築] へ進んでください。

STEP 2：旧環境のクリーンアップ

pip で入れた古い Ansible が残っていると、新しく入れる apt 版と競合し、複雑なエラーの原因になります。

1. 隠れた環境変数のチェック

アンインストール前に、Pythonの挙動を強制変更する環境変数が残っていないか確認します。これらが設定されていると、apt 版の導入後もトラブルの元になります。

[bash]Python/Ansible 関連の環境変数を表示

env | grep -E 'PYTHONPATH|PYTHONHOME|ANSIBLE_CONFIG'

env | grep -E 'PYTHONPATH|PYTHONHOME|ANSIBLE_CONFIG'

• 何も表示されない場合: 健全な状態です。
• 表示された場合: ~/.bashrc や ~/.zshrc を確認し、これらの設定行を削除またはコメントアウトしてください。修正後は、シェルを再起動するか source コマンドで反映させます。

2. アンインストールの実行

[bash]※ pip で導入していた場合のみ実行

python3 -m pip uninstall ansible ansible-core

python3 -m pip uninstall ansible ansible-core

STEP 3：最新の方式による構築（2026年・PEP 668準拠）

現代の運用では、「OS管理のパッケージ（apt）」を利用するのが最も安定します。

[bash]1. OS標準のパッケージマネージャーからインストール

sudo apt update
sudo apt install -y ansible

sudo apt update
sudo apt install -y ansible

[bash]2. 動作確認（ここが重要！）

ansible --version

ansible --version

動作確認のチェックポイント

出力結果の以下の項目が正しいか確認してください。

• executable location = /usr/bin/ansible: ここが /usr/bin であることが、OSと調和した環境の証です。
• python version = 3.x: システム標準のPythonが使用されていることを確認します。

STEP 4：IAP経由のセキュア接続とインベントリ設定

2026年の運用において、VMにパブリックIPを付与してSSHを全世界に開放するのは、重大な地雷リスクとなります。 Identity-Aware Proxy (IAP) を活用し、踏み台サーバーなしでセキュアに接続する基盤を確立します。

0. プロジェクトのディレクトリ構造

作業を開始する前に、構成ファイルを配置するディレクトリ構造を以下のように整えます。Ansible関連のファイルは ansible/ ディレクトリ内に集約し、見通しを良くします。

my-gcp-project/            # プロジェクトルート
├── terraform/             # インフラ定義（Terraform関連）
└── ansible/               # 構成管理（Ansible関連）
    ├── ansible.cfg        # Ansible全体の動作設定
    ├── inventory.yml      # 接続先サーバーの定義（YAML形式）
    └── playbook.yml       # 実行する構成内容（後述）

my-gcp-project/            # プロジェクトルート
├── terraform/             # インフラ定義（Terraform関連）
└── ansible/               # 構成管理（Ansible関連）
    ├── ansible.cfg        # Ansible全体の動作設定
    ├── inventory.yml      # 接続先サーバーの定義（YAML形式）
    └── playbook.yml       # 実行する構成内容（後述）

1. 初回接続（鍵登録の儀式）

以下のコマンドを実行し、「SSH鍵の生成・OS Loginへの登録・トンネル開通」を一度に行います。

[bash]初回接続

gcloud compute ssh gcta-server-01 \
    --project=<project-id> \
    --zone=us-west1-a \
    --tunnel-through-iap
    

gcloud compute ssh gcta-server-01 \
    --project=<project-id> \
    --zone=us-west1-a \
    --tunnel-through-iap
    

※初回実行時は Y を入力し、パスフレーズは空（Enter）で進めます。接続できたら exit でログアウトします。

2. インベントリの定義（INI または YAML）

事業規模や組織のフェーズに合わせて形式を選択してください。どちらの形式でも、inventory.yml（または inventory.ini）内に ansible_host として VM名を明示することで、将来的なホスト名変更やIP併用にも耐える堅牢な設計にします。

[YAML形式]中規模以上の組織向け: 推奨

all:
  children:
    # フロントエンド：Webサーバー群
    # Google Cloud の外部アプリケーション ロードバランサから
    # トラフィックを受け取るバックエンド インスタンス
    web_servers:
      hosts:
        web-01:
          ansible_host: gcta-web-01
        web-02:
          ansible_host: gcta-web-02

    # ミドルウェア：アプリケーションサーバー群
    app_servers:
      hosts:
        app-01:
          ansible_host: gcta-app-01
        app-02:
          ansible_host: gcta-app-02

    # バックエンド：データベースサーバー群
    db_servers:
      hosts:
        db-master:
          ansible_host: gcta-db-master
        db-slave:
          ansible_host: gcta-db-slave

all:
  children:
    # フロントエンド：Webサーバー群
    # Google Cloud の外部アプリケーション ロードバランサから
    # トラフィックを受け取るバックエンド インスタンス
    web_servers:
      hosts:
        web-01:
          ansible_host: gcta-web-01
        web-02:
          ansible_host: gcta-web-02

    # ミドルウェア：アプリケーションサーバー群
    app_servers:
      hosts:
        app-01:
          ansible_host: gcta-app-01
        app-02:
          ansible_host: gcta-app-02

    # バックエンド：データベースサーバー群
    db_servers:
      hosts:
        db-master:
          ansible_host: gcta-db-master
        db-slave:
          ansible_host: gcta-db-slave

[INI形式]スモールビジネス向け

[web_servers]
gcta-server-01 ansible_host=gcta-server-01

[web_servers]
gcta-server-01 ansible_host=gcta-server-01

3. ansible.cfg（「壊れない」接続ルールの確立）

ansible.cfg の ssh_args に、IAP経由で接続するためのマジックコマンドを記述します。

[ansible.cfg]Ansibleの共通設定

[defaults]
# インベントリファイルの指定（YAML形式なら .yml に変更）
inventory = ./inventory.yml
remote_user = <あなたのOS Loginユーザー名>

# IAP経由では接続のたびに経路が変わるため、厳密なホストチェックをオフにする
host_key_checking = False
private_key_file = ~/.ssh/google_compute_engine

[ssh_connection]
# ProxyCommand を使用して gcloud 経由で IAP トンネルを確立する
# %h は inventory.yml で定義した VM 名に置換されます
ssh_args = -o ProxyCommand="gcloud compute ssh %h --project=<あなたのproject-id> --zone=us-west1-a --tunnel-through-iap --quiet -- -W %h:%p"

# 接続のパイプライン化を有効にして速度を向上（推奨）
pipelining = True

[defaults]
# インベントリファイルの指定（YAML形式なら .yml に変更）
inventory = ./inventory.yml
remote_user = <あなたのOS Loginユーザー名>

# IAP経由では接続のたびに経路が変わるため、厳密なホストチェックをオフにする
host_key_checking = False
private_key_file = ~/.ssh/google_compute_engine

[ssh_connection]
# ProxyCommand を使用して gcloud 経由で IAP トンネルを確立する
# %h は inventory.yml で定義した VM 名に置換されます
ssh_args = -o ProxyCommand="gcloud compute ssh %h --project=<あなたのproject-id> --zone=us-west1-a --tunnel-through-iap --quiet -- -W %h:%p"

# 接続のパイプライン化を有効にして速度を向上（推奨）
pipelining = True

[bash]<あなたのOS Loginユーザー名>を確認するコマンド

gcloud compute os-login describe-profile --format="value(posixAccounts[0].username)"

gcloud compute os-login describe-profile --format="value(posixAccounts[0].username)"

[bash]<あなたのproject-id>を確認するコマンド

gcloud config list

gcloud config list

4. 自動構成管理の実践（Ansible Playbook）

接続基盤が確立できたら、次は「中身」の構築です。 にある「業務内容／成果」の質をさらに高めるため、構成管理を自動化します。

疎通確認：勝利の「pong」

作成した設定が正しいか、Ping モジュールで確認します。

ansible web_servers -m ping

ansible web_servers -m ping

判定結果の確認

• SUCCESS: "ping": "pong" と返ってくれば、ゼロトラスト接続基盤の開通です！
• UNREACHABLE: IAM 権限（IAP 受信者権限）や OS Login のユーザー名に誤りがある可能性があります。

補足：Google Cloud の「無料」には2つの種類がある

Google Cloud の「無料枠」という言葉には、性質の異なる2つのプログラムが含まれています。本ガイドでは主に「常に無料」の範囲内で構成を組んでいます。

1. 90日間の無料トライアル（Free Trial）

新規アカウント作成時に付与される 300ドル分のクレジット です。

• 特徴: 90日間、ほぼすべての有料サービスをこのクレジットで支払えます。
• 注意: 90日が経過するか、300ドルを使い切ると、手動で「有料アカウント」へアップグレードしない限りリソースが停止します。

2. 無期限の「常に無料」枠（Always Free）

特定のリージョンとリソース制限内であれば、期間に関わらず無料で提供される枠です。

• 本ガイドの対象: Compute Engine の e2-micro インスタンスなどがこれに該当します。
• 条件: 米国リージョン（us-west1, us-central1, us-east1）のいずれかを使用し、1ヶ月あたりの総使用時間が1インスタンス分（約744時間）に収まっている必要があります。

実務的なチェックポイント：なぜ「課金」が発生するのか？

「常に無料（Always Free）」の範囲で運用していても、以下の場合は課金が発生するため注意が必要です。

• パブリックIPの保持: 静的外部IPを予約し、それをVMに割り当てていない時間は課金対象となります。
• ディスク容量の超過: 無料枠の上限は合計 30GB です。
• リージョン間違い: 日本（asia-northeast1）で e2-micro を立てると、Always Free の対象外となり課金されます。

アドバイス: 本ガイドの Terraform 構成で region = "us-west1" かつ access_config {}（外部IP付与）を削除しているのは、これらの「うっかり課金」を物理的に防ぐためです。

実務上の重要事項：Terraform と Ansible の「責務境界」

「どちらのツールで何をするか」という迷いは、後のトラブルの種になります。2026年の実務設計では、以下の境界線を明確に引きます。

接続の前提（SSH）

Ansibleは対象サーバーへSSH接続します。Terraform側で以下の準備が整っていることが前提となります。

• SSH鍵: Terraformのメタデータ経由で公開鍵がVMに配置されていること。
• インベントリ: Terraformが出力したIPアドレスをAnsibleに渡す仕組み（詳細は次回【連携編】で解説）。