コードが書けなくても大丈夫？ 生成AI×MCPで「インフラ構築自動化」を実現する方法：ITインフラ担当者のための生成AI活用術（2）
ITインフラの構築・運用フェーズでの生成AI活用法をITインフラ担当者に向けて解説する本連載。今回は、構築フェーズにおける具体的な活用例を紹介します。
ITインフラの構築・運用フェーズで生成AI（人工知能）がどう役立つのかを解説する本連載。前回は「インフラ構築における生成AIの活用」と「インフラ運用における生成AIの活用」を概観しました。今回は、前者の「インフラ構築における生成AIの活用」を具体例とともに解説していきます。
コードが書けなくても大丈夫？ 「GitHub Copilot」で始めるIaC
前回は、IaC（Infrastructure as Code）を活用することで、インフラ構築がどのように効率化できるかを紹介しました。これまでのように、GUI（グラフィカルユーザーインタフェース）やCLI（コマンドラインインタフェース）を使って手作業で構築するのではなく、構成をコードとして管理することで、同じインフラ環境を簡単に再現したり、大規模な環境を自動的に展開したりすることができます。その結果、人為的なミスを減らし、安定したインフラ運用が可能になります。
一方で、IaCには「コードを書く手間がかかる」という課題もあります。IaCを実現する各種ツール（「Terraform」や「Bicep」）は、プログラミング言語のように独自の記法を持ち、それを学習する必要があります。記法の習得には時間がかかり、構成ファイルの作成にも一定の労力を要します。
そこで、生成AIを活用することでこの労力を削減できます。「Visual Studio Code」と「GitHub Copilot」を使って実践してみましょう。Visual Studio CodeでGitHub Copilotを使うには、まず機能を有効化する必要があります。
GitHub Copilotの準備
Copilotの設定画面を開く
Visual Studio Codeのステータスバー（右下）にあるCopilotアイコンをクリックし（1）、「Copilotの設定」をクリックして、Copilotの設定画面を開きます（2）。
GitHubにログインする
「GitHubで続行」をクリックすると、GitHubへのログイン画面が表示されるので、手順に従いGitHubにログインしてください。
これで準備は完了です。
GitHub Copilotによるインフラのコード作成
ではここで、GitHub Copilotを使ってインフラコードを生成してみましょう。
今回は、「Microsoft Azure」（以下、Azure）で仮想マシン（VM）を作成するためのTerraformコードを作成してみます。対象となるインフラ要件は以下の通りです。
Azureの既存OSマネージドディスクからWindows 仮想マシンをTerraformで作成してください。
これは「Azure上で新しい仮想マシンを一から作る」のではなく、既にOSがインストールされた状態の既存ディスクを利用してVMを作成するという意味です。
つまり、OSイメージを指定してVMを作成する一般的な方法とは異なり、手元にあるディスクをそのままVMのOSディスクとして使いたいケースを想定しています。なお、マネージドディスクとは、Azureが提供するディスク管理サービスであり、ユーザーがストレージアカウントを意識せずにディスクを扱える仕組みです。
ここでは例としてAzureを取り上げていますが、考え方は他のパブリッククラウドでも同じです。これ以降、Azureに関する説明やインフラ構築用のコードが登場しますが、Azureの詳細を理解していなくても問題ありません。
前置きが長くなりましたが、では実際にコードを作成してみましょう。
Agentモードに設定する
Visual Studio Codeを起動し、Copilotを「Agent」モードに設定します。Agentモードとは、Copilotがコードの自動生成を積極的に提案してくれるモードです。
GitHub Copilotには「Ask」というモードもあります。Askモードは、ユーザーが明示的に質問やリクエストを入力したときにのみコードを提案します。一方、Agentモードは、ユーザーのコードコンテキストを理解し、積極的にコードを提案します。今回はAgentモードを使用します。
（1）の部分をクリックして、「Agent」を選択して有効化します（2）。
プロンプトを入力する
先ほどのインフラ要件を自然言語で入力します。Copilotのチャットウィンドウで、以下の文章を入力して（1）、（2）の送信ボタンをクリックします。
Azureの既存OSマネージドディスクからWindows 仮想マシンをTerraformで作成してください。
生成されたコードを確認する
Agentモードでは、プロンプトに応じてコードが自動生成され、そのままエディタに反映されます。今回も大量のTerraformコードが生成されましたが、その一部を見てみましょう。
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~> 3.0"
}
}
}
provider "azurerm" {
features {}
}
# 既存のリソースグループへの参照
data "azurerm_resource_group" "existing" {
name = var.resource_group_name
}
# 既存の OS マネージドディスクへの参照
data "azurerm_managed_disk" "existing_os_disk" {
name = var.existing_os_disk_name
resource_group_name = data.azurerm_resource_group.existing.name
}
# 既存の仮想ネットワークへの参照
data "azurerm_virtual_network" "existing" {
name = var.vnet_name
resource_group_name = data.azurerm_resource_group.existing.name
}
# 既存のサブネットへの参照
data "azurerm_subnet" "existing" {
name = var.subnet_name
virtual_network_name = data.azurerm_virtual_network.existing.name
resource_group_name = data.azurerm_resource_group.existing.name
}
# ネットワークインタフェース
resource "azurerm_network_interface" "main" {
name = "${var.vm_name}-nic"
location = data.azurerm_resource_group.existing.location
resource_group_name = data.azurerm_resource_group.existing.name
ip_configuration {
name = "internal"
subnet_id = data.azurerm_subnet.existing.id
private_ip_address_allocation = "Dynamic"
}
}
# 既存の OS ディスクから Windows VM を作成
resource "azurerm_virtual_machine" "main" {
name = var.vm_name
location = data.azurerm_resource_group.existing.location
resource_group_name = data.azurerm_resource_group.existing.name
network_interface_ids = [azurerm_network_interface.main.id]
vm_size = var.vm_size
# 既存の OS ディスクをアタッチ
storage_os_disk {
name = data.azurerm_managed_disk.existing_os_disk.name
managed_disk_id = data.azurerm_managed_disk.existing_os_disk.id
caching = "ReadWrite"
create_option = "Attach"
os_type = "Windows"
}
}
一見すると問題なさそうで、このままでも動作します。しかし実は、このコードは最新仕様を一部取りこぼしています。
Terraformでは、既存のマネージドディスクをOSディスクとして利用する場合、os_managed_disk_idという属性が利用できます。これは2025年8月25日リリースのTerraform AzureRM Provider v4.42.0で追加された比較的新しい機能です。この属性を使うと、既存OSディスクの指定をよりシンプルに記述できます。
ところが、先ほど生成されたコードではこの新しい属性が使われていません。これは、生成時に使用されたモデルの「知識カットオフ」が2024年6月であり、その時点ではos_managed_disk_idがまだ存在していなかったためです。
このように、LLM（大規模言語モデル）が持つ知識が古い場合、最新仕様を反映できないという問題が発生します。Terraformに限らず、技術は日々アップデートされ続けているため、このままでは実用に困ります。
そこで登場するのがMCP（Model Context Protocol）です。
MCPを利用することで、モデルに「最新仕様を動的に参照させる」ことが可能になります。次章では、この仕組みについて詳しく説明します。
AIエージェントとMCPの役割
MCPを理解する前に、まずAIエージェントについて説明します。
「ChatGPT」をはじめとする生成AIは、非常に便利な存在です。質問を入力するだけで、人間と会話しているかのような自然なやりとりができ、瞬く間に世界中で話題になりました。現在では日常生活やビジネスの場面でも欠かせないものになりつつあります。
しかし、生成AIも万能ではありません。LLMが「知っていること」であれば、すぐに回答してくれます（もちろん、ハルシネーションと呼ばれる誤回答をすることもあります）。ところが、LLMが「知らないこと」については、どんなに優秀でも答えることができません。先ほど紹介したTerraformのケースがまさにそうです。
私たち人間と同じです。知っていることならすぐ答えられますが、知らないことは調べないと答えられないというわけです。
では、私たちは知らないことに直面したらどうするでしょうか？ さまざまなツールを使って情報を集め、その情報が正しいかどうかを確認し、自分の答えを組み立てていきます。このような思考の流れをAIにもできるようにすれば、生成AI以上の能力を発揮できるのではないか──そんな発想から生まれたのがAIエージェントです。
AIエージェントは、LLMが知らない情報であっても、与えられたツールを使って自ら調べ、必要な情報を取得し、問題を解くことができます。
AIエージェントを⽤いることで、LLMは、問題を解決するための思考プロセスを段階的に分解します。そして、それぞれのステップに対して外部ツールを活用することで、LLMが持っている知識に加えて、より正確で信頼性の高い回答を導き出すことができるというわけです。
MCPとは？
AIエージェントの仕組みを理解したところで、MCPについて説明します。
AIエージェントは、ツールが与えられていなければ実行することができません。どれだけ高い思考能力を持っていても、必要な情報にアクセスできなければ問題を解決できないのと同じです。
そのため、AIエージェントが利用するための「ツールを渡す仕組み」が必要になります。ここで登場するのがMCPです。MCPは、そのための標準的な仕組みを提供します。
従来、LLMが外部ツールを扱う場合、ツールごとに通信方法がバラバラでした。例えば、あるAIエージェントはWeb検索ツールとHTTP APIで通信し、別のエージェントは計算処理をPython関数として直接呼び出す──といった具合です。ツールごとに異なる方式を使っていたため、新しいツールを追加するたびに個別対応が必要になり、AIエージェント間でツールを共有することも困難でした。
この問題を解決するために提案されたのがMCPです。MCPは「AIエージェントとツールの通信方法を統一するためのプロトコル」です。これにより、MCPに準拠したツールであれば、どのAIエージェントからでも同じ方法で利用できるようになります。
MCPがない場合
次の例では、2つのAIエージェントが登場し、どちらも同じ2つのツールを利用しています。
1つはWeb検索をする「ツールA」、もう1つはクラウドストレージにファイルを保存する「ツールB」です。
ここで「ツールBが便利なので、AIエージェントBでも使いたい」と考えたとします。しかし、ツールBはUNIXドメインソケット（ファイルを介した通信方式）を利用する設計になっています。一方で、AIエージェントB側のLLMアプリはTCP/IP通信を前提に実装されているため、そのままではツールBを扱うことができません。
AIエージェントBでツールBを使うには、LLMアプリの通信方式をUNIXドメインソケット対応に書き換える必要があるのです。
これはつまり、AIエージェントAとAIエージェントBの間でツールBをそのまま共有できないということを意味します。
このような状況では、ツールの再利用性が低く、非常に不便です。
MCPがある場合
では、MCPが導入された場合はどうなるのでしょうか。
MCPがない場合は、各エージェントが「ツール」と直接通信していましたが、図6ではそれらのツールがMCPサーバに置き換えられています。
さらに、LLMアプリはツールと直接通信するのではなく、MCPクライアントを介してMCPサーバと通信する形に変更されています。
ここで重要なのは、MCPクライアントとMCPサーバの間は、共通規格であるMCPで通信するという点です。つまり、
- LLMアプリがMCPクライアントに対応している
- ツール側がMCPサーバとしてMCPに準拠している
この2つが成立していれば、どのAIエージェントからでも同じツールを利用できるようになるということです。通信方式の違いを意識する必要はなくなり、ツールを横断的に共有できるようになるというわけです。
MCPを使ったIaCコードの生成
それでは、本稿のメインテーマであるMCPを使ったIaCコード生成に戻りましょう。
先ほどの章では、GitHub Copilotを使ってTerraformコードを生成しました。しかし、生成されたコードは最新仕様を反映していませんでした。これは、使用されたモデルの知識カットオフが2024年6月であり、その時点では最新仕様が存在していなかったためです。
MCPを使うことでこの問題を解決することが可能です。第1回でも紹介したように、「Terraform MCP Server」を利用することで、最新のクラウドサービスや新機能に関する情報をMCPサーバから取得し、生成AIに提供することで、より正確で最新のコード生成が可能になります。つまり、Terraform MCP Serverは、生成AIが最新の情報を活用してIaCコードを生成できるようにするためのブリッジの役割を果たします。
それでは、MCPを使ってTerraformコードを生成してみましょう。
本作業を進めるに当たり、PCに「Docker」がインストールされている必要があります。Dockerのインストール方法については割愛するので、公式サイトをご参照ください。
設定ファイルを作成する
まずは、MCPサーバに接続するための設定ファイルを作成します。Visual Studio Codeのワークスペースフォルダ配下に`.vscode`フォルダを作成し、その中にmcp.jsonという名前で以下の内容のファイルを作成します。
{
"servers": {
"terraform-mcp-server": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"hashicorp/terraform-mcp-server"
]
}
}
}
MCPサーバを起動する
次に、MCPサーバを起動します。先ほど作成したmcp.jsonファイルを開き（1）、「起動」ボタンをクリックします（2）。
MCPサーバを追加する
MCPサーバが起動したら、GitHub Copilotが回答をする際、MCPサーバを参照するように設定します。Copilotのチャットウィンドウを開き、「コンテキストの追加」をクリックします。
「ツール」をクリックします。
「terraform-mcp-server」を選択して追加します。
プロンプトを入力する
では、再度プロンプトを入力してみましょう。Copilotのチャットウィンドウで、terraform-mcp-serverが追加されていることを確認し（1）、以下の文章を入力して（2）、（3）の送信ボタンをクリックします。
Azureの既存OSマネージドディスクからWindows 仮想マシンをTerraformで作成してください。
Terraform MCP Serverが参照されていることを確認する
Terraform MCP Serverが参照されていることを確認します。Copilotのチャットウィンドウに、MCPサーバからの応答が表示されていることを確認してください。
生成されたコードを確認する
再度、生成されたコードを確認します。MCPサーバが参照されたことで、最新仕様が反映されたコードが生成されているはずです。その一部を見てみましょう。
⋯略⋯
# Windows仮想マシン（既存のOSディスクを使用）
resource "azurerm_windows_virtual_machine" "vm_from_existing_disk" {
name = "vm-from-existing-disk"
resource_group_name = azurerm_resource_group.vm_rg.name
location = azurerm_resource_group.vm_rg.location
size = "Standard_D2s_v3"
network_interface_ids = [
azurerm_network_interface.vm_nic.id,
]
# 既存のOSマネージドディスクを使用
os_managed_disk_id = data.azurerm_managed_disk.existing_os_disk.id
# os_diskブロックでキャッシング設定を指定
os_disk {
caching = "ReadWrite"
}
⋯略⋯
ここで注目すべきは、azurerm_windows_virtual_machineリソースの中で、os_managed_disk_id属性が使用されている点です。これは、Terraform AzureRM Provider v4.42.0で追加された最新仕様であり、既存のOSマネージドディスクを指定するための推奨方法です。
Terraform MCP Serverを参照しない場合は、この属性は生成されませんでしたが、MCPサーバを利用することで、最新の仕様が反映されたコードが生成されました。
まとめ
本稿では、MCPを活用して最新仕様を反映したIaCコードをGitHub Copilotで生成する方法を解説しました。MCPを利用することで、生成AIが最新の情報を取得し、より正確で信頼性の高いコード生成が可能になります。積極的にこれらの技術を活用し、インフラ構築の効率化と品質向上を図っていきましょう。
次回は、インフラ運用における生成AIの活用を具体例とともに解説します。
筆者紹介
武井宜行
サイオステクノロジーに所属し、AzureやAI領域でのシステムインテグレーションや製品開発に取り組むエンジニア。Microsoft MVPとして認定され、YouTubeなどのメディアで「わかりみ深い」Azureの情報を日々発信している他、執筆活動（書籍『世界一やさしいRAG構築入門』）を通じて知識を広く共有している。
Copyright © ITmedia, Inc. All Rights Reserved.