MCPとSnowflakeで始めるIaC ─ Terraform × GitHub Actionsの可能性

はじめに

Snowflakeを利用する中で、ユーザーやロール、データベース、スキーマといったリソースをどのように管理していますか？コンソールやSQLクライアントから直接コマンドを実行しても、確かに同じことは実現できます。

しかし、環境が増え、プロジェクトが横断し、関わるメンバーが多様になるにつれ、次のような課題に直面することは少なくありません。

• 誰が・いつ・どのリソースを変更したのか追いづらい
• 環境ごとの設定差分が増えて管理が煩雑になる
• 再利用できるコード資産として残らず、毎回手作業が発生する

こうした課題を解決する有力なアプローチがTerraformを用いた「Infrastructure as Code（IaC）」です。さらに、TerraformをGitHubリポジトリに格納し、GitHub Actionsで自動的にデプロイできるようにすれば、「コードレビュー → マージ → 自動反映」という開発フローに組み込むことができます。

今回は、この仕組みをMCP（Model Context Protocol）と組み合わせ、自然言語でClaude Desktopから指示を出すだけで、Terraformコードの生成・GitHubへのPush・ActionsによるSnowflakeへのデプロイまでを一気通貫で実行できるかを検証しました。

なお、本検証では「SnowflakeとTerraformで作るデータ基盤入門」の内容を多く参考にさせていただきました。TerraformやGitHub Actionsの詳細な使い方については、同書を適宜ご参照ください。

https://zenn.dev/mnagaa/books/3d668d2dfc657e

1. 環境準備

本章では、今回の自動化ワークフローを実現するために必要な全体構成と、利用ツール、環境設定の手順を解説します。

1.1 全体構成

今回の構成では、Terraform × GitHub ActionsにClaude Desktop（MCP）を組み合わせることで、インフラ構成のコード生成からデプロイまでを自然言語による指示とレビューのみで完結できるフローを構築しています。

ステップ	フェーズ	実行者	アクション
1️⃣	自然言語での指示	人間	「SALES_DBという新しいデータベースを作成して」
2️⃣	Claude Desktop（MCP）自動処理	Claude Desktop	- feature/add-sales-db ブランチ作成 - main.tfにSALES_DBリソース追加 - PR作成「Add SALES_DB database」
3️⃣	Plan検証フェーズ	GitHub Actions	terraform plan実行
4️⃣	人間による確認	人間	PR内容とplan結果をレビュー
5️⃣	承認・実行	人間	マージボタンをクリック
6️⃣	自動デプロイ	GitHub Actions	terraform apply実行
7️⃣	自然言語での指示	人間	「SALES_DBが作成されたか確認して」
8️⃣	Claude Desktop（MCP）結果確認	Claude Desktop	Snowflake MCPでデータベース一覧を取得・検証
9️⃣	完了	Claude Desktop	作成結果をユーザーに報告

---

1.2 必要なツール・サービス

本検証で利用したサービス・ツールは以下の通りです。

カテゴリ	必要なサービス・ツール	用途
クラウドサービス	Snowflakeアカウント	データウェアハウス環境
	AWS（Amazon Web Services）アカウント	Terraform State管理（S3）
	GitHubアカウント	コード管理・CI/CD
ローカル環境	Claude Desktop	MCP経由での自動化

---

1.3 MCPの設定

Claude DesktopからSnowflakeおよびGitHub MCPを操作するために、以下の設定ファイル（claude_desktop_config.json）を作成・登録します。

{
  "globalShortcut": "Ctrl+Cmd+C",
  "mcpServers": {
    "snowflake": {
      "command": "uvx",
      "args": [
        "--from",
        "mcp-snowflake-server",
        "mcp_snowflake_server"
      ],
      "env": {
        "PATH": "/Users/username/.local/bin:/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin",
        "SNOWFLAKE_ACCOUNT": "your-account-identifier",
        "SNOWFLAKE_USER": "your-username",
        "SNOWFLAKE_ROLE": "ACCOUNTADMIN",
        "SNOWFLAKE_WAREHOUSE": "your-warehouse",
        "SNOWFLAKE_DATABASE": "your-database",
        "SNOWFLAKE_SCHEMA": "your-schema",
        "SNOWFLAKE_PASSWORD": "your-password"
      }
    },
    "github": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-github"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "your-github-token"
      }
    }
  }
}

設定後、Claude Desktop上からSnowflakeやGitHubの操作が可能になります。

---

1.4 GitHubリポジトリの初期設定

Claude Desktop（GitHub MCP）経由でリポジトリを作成し、以下のような構成を準備します。

Claude_Repo/
├── terraform/
│   ├── environments/
│   │   └── dev/
│   ├── modules/
│   │   └── snowflake/
│   └── backend-config/
├── .github/
│   └── workflows/
├── scripts/
└── docs/

---

1.5 AWS S3バックエンドの設定

Terraformの状態管理にはAWSのS3を使用します。

• S3バケットを作成し、Terraformバックエンドとして設定
• 今回は学習目的のため、DynamoDBによるState Lockingは省略

---

1.6 GitHub Secretsの設定

GitHub Actionsで使用する認証情報を、以下のように GitHub Secretsに登録します。

AWS関連（S3バックエンド用）

Name	Value	用途
AWS_ACCESS_KEY_ID	AWSアクセスキーID	S3バックエンド接続
AWS_SECRET_ACCESS_KEY	AWSシークレットアクセスキー	S3バックエンド接続
AWS_REGION	us-east-1	AWSリージョン

Snowflake関連

Name	Value	用途
SNOWFLAKE_ACCOUNT_NAME	アカウント識別子	Snowflake接続
SNOWFLAKE_ORGANIZATION_NAME	組織名	Snowflake接続
SNOWFLAKE_USER	ユーザー名	Snowflake認証
SNOWFLAKE_PASSWORD	パスワード	Snowflake認証
SNOWFLAKE_ROLE	ACCOUNTADMIN	実行ロール

2. 実行：DB・Schema・Roleを作ってみる

この章では、実際にClaude Desktopを用いて、Snowflake環境に対し以下の構成をIaCで作成・デプロイしていく流れを紹介します。

2.1 シナリオ

新しいプロジェクト「SALES_ANALYTICS」に向けて、以下の構成要件を満たすSnowflake環境を整備します。

• SALES_DBデータベースの作成
• RAW_DATA、TRANSFORMED_DATAの2スキーマ作成
• SALES_ANALYST、SALES_VIEWERの2ロール作成と適切な権限付与

---

2.2 フェーズ1: データベース作成

• 👤指示
  Claude Desktopに以下の自然言語を入力します。

「SALES_DBという新しいデータベースを作成して」

• 🤖 Claude Desktopの自動処理
  Claude Desktopが指示を受け取り、以下の操作を自動で実行します：
  • feature/add-sales-db ブランチを作成
  • Terraformコードを生成（main.tf に SALES_DB を定義）
  • GitHub上にPull Request（PR）を作成

• 👤 実行結果の確認
  GitHub上でPRとterraform planの結果を確認します。
  • PRタイトル：「Add SALES_DB database」
  • plan結果： SALES_DB が新規作成されることを確認

• 👤 承認:
  PRをレビューし、内容に問題がなければマージ → GitHub Actionsによりterraform applyが自動実行されます。

• 👤指示

「意図したDBが作成されているか、Snowflake上から確認してください」

• 🤖 Claude Desktopの自動処理:
  Snowflake上で SALES_DB が存在していることを確認し、結果を返してくれます。
  

---

2.3 実行フェーズ２: スキーマ作成

スキーマ作成も同様のフローで進めます。

• 👤指示

「次は、SALES_DBにRAW_DATAとTRANSFORMED_DATAの2スキーマを作成してください」

• 👤 実行結果の確認
  Claudeが自動でPRを作成し、plan結果から以下のスキーマが作成予定であることが確認できます。

  • SALES_DB.RAW_DATA
  • SALES_DB.TRANSFORMED_DATA
    

• 👤指示：

「対象のスキーマが作成されたことを確認してください」

• 🤖 Claude Desktopの自動処理:
  Snowflake上にスキーマが存在していることを確認し、結果を返してくれます。
  

---

2.4 実行フェーズ２: ロール作成

最後に、必要なロールとその権限を設定します。

• 👤指示

「SALES_ANALYST と SALES_VIEWER ロールを作成して、各スキーマに適切なUSAGE権限を付与してください」

• 👤 実行結果の確認:
  ClaudeがPRを作成し、以下のような権限構成がplan結果として出力されました。

  項目	SALES_ANALYST	SALES_VIEWER
  SALES_DB	USAGE ✅	USAGE ✅
  RAW_DATA	USAGE (読取) ✅	アクセス不可 ❌
  TRANSFORMED_DATA	詳細権限 ⬇️	USAGE (読取のみ) ✅
  └ USAGE	✅	✅
  └ CREATE TABLE	✅	❌
  └ CREATE VIEW	✅	❌
  └ CREATE STAGE	✅	❌
  └ CREATE FILE FORMAT	✅	❌
  └ CREATE SEQUENCE	✅	❌
  └ CREATE FUNCTION	✅	❌
  └ CREATE PROCEDURE	✅	❌
  WAREHOUSE	USAGE ✅	USAGE ✅

🧠Claudeは「スキーマのUSAGE権限をつけて」というシンプルな指示から、ロール名や文脈を読み取り、WAREHOUSEやCREATE TABLEなどの追加権限まで自動で付与しています。確かに非常に賢い挙動ではありますが、最小権限原則の観点からは、意図しない権限が含まれていないかを事前に確認することが重要です。

そのためにも、terraform planの出力を人間がレビュー（RV）する工程は欠かさないようにすべきでしょう。

• 👤指示：

「Snowflake上でロールとその権限が正しく設定されているか確認してください」

• 🤖 Claude Desktopの自動処理:
  ロールと各種権限が正しく作成されたことを確認し、結果を返してくれます。
  
  Snowsightからも「SALES_ANALYST」の権限を確認しましたが、うまく作成されているようです。
  

まとめ

本検証では、Claude Desktop（MCP）を活用して、自然言語によるSnowflakeインフラの自動構築を試みました。その結果、従来の手動運用と比較して、効率化と再現性の向上が可能であることを確認しました。

特に、Terraform × GitHub ActionsによるCI/CD基盤とMCPを組み合わせることで、

自然言語での指示 → コード生成 → レビュー・承認 → 自動デプロイ → 結果確認

という一連のフローを、開発者がコードを直接書かずに実現することができました。

✨ 実用性と利点

MCPを活用したインフラ自動化は、CI/CD環境が整備された後の運用フェーズで特に効果を発揮します。技術的な障壁を下げることで、運用担当者や非専門エンジニアも安全にインフラ変更に関与できる可能性が見えてきました。

⚠️ 注意点と今後の課題

一方で、以下のような注意点も明らかになりました：

• Claudeの自動生成結果には、過剰な権限付与が含まれる可能性がある
• 最小権限原則に基づき、ロール設計やアクセス制御の検討が必須
• terraform plan の出力に対する、人間によるレビュー（RV）は不可欠

つまり、MCPを用いた自動化は「すべてを任せて完結する仕組み」ではなく、設計や確認といった重要な判断は人間が担いながら、作業そのものを効率化するツールとして活用するのが現実的です。

🚀 今後の展望

今後は、組織ポリシーやベストプラクティス（例：最小権限設計・命名規約・セキュリティルール）と連携させることで、さらに安全でスピーディなIaC運用が実現できると考えられます。

参考リンク

Snowflake MCP Server を試してみた（Classmethod）
GitHub MCP サーバーのチュートリアル（Zenn）
mcp-snowflake-server - PyPI