インフラエンジニアが生成AIを活用する方法を解説

2026-02-16

本サイトで紹介している商品・サービス等の外部リンクには、プロモーションが含まれています。

はじめに

「生成AIって開発者向けでしょ？インフラだとあんまり関係なくない？」と思っている方、意外と多いのではないでしょうか？

たしかに、生成AIはコードを書く場面で注目されがちです。でも実は、インフラエンジニアの日常業務とも相性のよい場面がたくさんあります。

生成AI（Generative AI） とは、テキスト・画像・コードなどを自動生成するAI技術の総称です。ChatGPT（OpenAI）、Claude（Anthropic）、Gemini（Google）といったサービスが代表的です。

TerraformやAnsibleのコードを書いたり、構成図を作ったり、見慣れないAWSサービスの概要を素早く把握したり。こうした作業を生成AIに手伝ってもらうことで、日々の業務がかなり効率化できます。

この記事では、インフラエンジニアが 生成AIをどんな場面で、どう使えるのか を具体的なプロンプト例も交えて紹介していきます。

1. IaCコードの作成と管理なぜ相性がいいのか

IaC（Infrastructure as Code） は、Terraform・Ansible・CloudFormationなどのツールを使い、インフラ構成をコードで管理する手法です。

IaCコードは宣言的な記述が中心で、パターンが定型化しやすいという特徴があります。つまり「こういう構成を作りたい」と伝えれば、ある程度正確なコードを生成してくれるわけです。

こう使うと便利

Terraformコードの雛形生成: 「VPC、パブリック/プライベートサブネット、NATゲートウェイを含むAWS環境をTerraformで作成して」と伝えるだけで、HCLコードの雛形ができあがります
Ansibleプレイブックの作成: 「NginxをインストールしてSSL設定を行うPlaybookを書いて」と指示すれば、タスクの構造を組み立ててくれます
既存コードのリファクタリング: 繰り返しが多いコードを渡して「モジュール化して」と頼むと、整理案を提示してくれます
コードレビューの補助: terraform plan の出力を貼り付けて「意図しない変更がないか確認して」と依頼するのも効果的です

実際にやってみよう: Terraformコードの生成

たとえば、以下のようなプロンプトを入力してみてください。

AWSで以下の構成をTerraformで作成してください。
- VPC（CIDRは10.0.0.0/16）
- パブリックサブネット2つ（ap-northeast-1a, 1c）
- プライベートサブネット2つ（ap-northeast-1a, 1c）
- インターネットゲートウェイ
- NATゲートウェイ（シングル構成）

リソース定義・変数・出力値を含むコードが生成されます。ただし、そのまま terraform apply するのではなく、自社の命名規則やタグ付けルールに合わせて調整してから使いましょう。

ここは気をつけよう

生成されたコードは 必ず自分の目でレビューしてからapply してください
stateファイルの管理やバックエンド設定など、プロジェクト固有の部分は手動で調整が必要です
セキュリティグループやIAMポリシーなど、権限周りは特に慎重に確認しましょう

2. 構成図・ドキュメントの作成

なぜ相性がいいのか

インフラエンジニアにとって、構成図や手順書の作成は避けて通れない業務です。ただ、正直なところ「ドキュメント作成は後回しにしがち」という方も多いのではないでしょうか。

生成AIを使えば、構成情報を伝えるだけでドキュメントの下書きが出てきます。ゼロから書き始める必要がなくなるので、ドキュメント作成のハードルがかなり下がります。

こう使うと便利

構成図のコード生成: Mermaid記法やPlantUML形式で構成図を生成させて、ツールで描画する
手順書の下書き: 作業手順の箇条書きを渡して「他の人が読んでもわかる手順書にして」と頼む
設計書のテンプレート: 「AWS上のWebアプリの基本設計書に必要な項目を挙げて」と聞けば、構成を考える出発点になります
既存ドキュメントの更新: 変更点を伝えて、ドキュメントの該当箇所を書き換えてもらう

実際にやってみよう: Mermaid記法で構成図を作る

以下のように構成を説明してみましょう。

以下のAWS構成をMermaid記法で図にしてください。
- ユーザーはCloudFront経由でアクセス
- CloudFrontのオリジンはALB
- ALBの背後にECS Fargate（2タスク）
- ECSからRDS（PostgreSQL）とElastiCacheに接続
- すべてVPC内に配置

Mermaid記法のコードが出力されるので、GitHub、Notion、VS Codeの拡張機能などで描画できます。手作業で図を描くよりも圧倒的に速いので、ぜひ試してみてください。

ここは気をつけよう

生成された図は、情報の抜け漏れがないか必ず確認しましょう
複雑な構成の場合は、一度にすべてを生成するよりコンポーネントごとに分けたほうが精度が高くなります

3. AWS・ミドルウェアのキャッチアップ

なぜ相性がいいのか

AWSは毎年大量の新サービスや機能アップデートをリリースしますし、ミドルウェアのバージョンアップも頻繁にあります。全部の公式ドキュメントを丁寧に読んでいたら、それだけで1日が終わってしまいます。

「ざっくり概要を把握する」フェーズでは、生成AIがとても役に立ちます。

こう使うと便利

サービスの概要把握: 「AWS App Runnerとは何？ECSとの違いは？」と聞けば、要点を整理して教えてくれます
公式ドキュメントの要約: 長いドキュメントの内容を貼り付けて「要点をまとめて」と依頼する
設定パラメータの理解: 「Nginxの worker_connections と worker_processes の関係を教えて」のように、設定値の意味と推奨値をすぐ確認できます
ベストプラクティスの確認: 「本番環境でRDSを運用する際のベストプラクティスは？」と聞けば、考慮すべき設定の全体像がわかります
バージョン間の差異: 「PostgreSQL 15と16の主な変更点は？」のように、アップグレード判断の材料を素早く集められます

ここは気をつけよう

生成AIの回答には 情報が古い場合や不正確な場合があります。特にAWSのサービス仕様は頻繁に変わるため、最終的には公式ドキュメントで裏を取りましょう
概要把握と学習の起点として活用し、設計判断の根拠には公式情報を使うのが鉄則です

4. トラブルシューティングの補助

なぜ相性がいいのか

インフラ運用で地味に時間がかかるのが、エラーメッセージの調査やログの解析です。生成AIにエラー内容やログを貼り付ければ、原因の候補をすぐに挙げてくれるので、調査の初動がかなり速くなります。

こう使うと便利

エラーメッセージの解析: エラーログを貼り付けて「原因と対処方法を教えて」と聞く
ログの読み解き: CloudWatch LogsやsyslogをAIに渡して、異常パターンを見つけてもらう
コマンドの組み立て: 「特定のポートを使っているプロセスを調べるコマンドは？」のように、状況に応じた調査コマンドを教えてもらう
障害対応手順の整理: 過去の障害対応メモを渡して「再利用できるランブック（手順書）にして」と頼む

実際にやってみよう: エラーログの調査

たとえば、こんなNginxのエラーが出たとします。

以下のNginxエラーログの原因と対処法を教えてください。

[error] 1234#1234: *5678 connect() failed
(111: Connection refused) while connecting to upstream,
client: 192.168.1.100, server: example.com,
upstream: "http://127.0.0.1:3000/api/health"

生成AIは「アップストリームのアプリケーション（ポート3000）が停止しているか応答していない可能性がある」「systemctl status で稼働状況を確認する」といった具体的な調査手順を提示してくれます。慣れたエンジニアなら瞬時にわかる内容かもしれませんが、経験が浅いうちは特に助けになるはずです。

5. シェルスクリプト・自動化スクリプトの作成

なぜ相性がいいのか

バックアップの取得、ログのローテーション、定期的なヘルスチェック。インフラ業務では、シェルスクリプトで自動化する作業がたくさんあります。

スクリプトの記述は定型的な部分が多いので、生成AIで下書きを作って自分の環境に合わせて調整する、というやり方がとても効率的です。

こう使うと便利

スクリプトの雛形生成: 「S3バケットの古いログを30日経過後に削除するBashスクリプトを書いて」と頼む
既存スクリプトの改善: 手元のスクリプトを貼り付けて「エラーハンドリングを追加して」と依頼する
ワンライナーの作成: 「特定ディレクトリ配下で1GB以上のファイルを一覧表示するワンライナーを書いて」のように、複雑なコマンドの組み立てを任せる
cronやsystemd timerの設定: 定期実行の条件を伝えて設定例を出してもらう

ここは気をつけよう

本番環境で実行する前に、検証環境でスクリプトの動作を必ず確認 してください
rm -rf やデータベース操作など、破壊的なコマンドを含むスクリプトは特に慎重にレビューしましょう

6. 監視・アラート設計の補助

なぜ相性がいいのか

「このシステム、何を監視すればいいんだろう？」という問いは、経験がないと答えにくいものです。生成AIに構成情報や要件を伝えれば、監視項目の洗い出しやアラートルールの雛形を作ってくれます。

こう使うと便利

監視項目の洗い出し: 「ECS Fargateで動くWebアプリの監視項目を一覧にして」と頼めば、CPU・メモリ・リクエスト数・エラーレートなどを網羅的にリストアップしてくれます
Prometheus / Grafanaの設定生成: 「Nginxのリクエスト数とレスポンスタイムを監視するPrometheusのアラートルールを書いて」と依頼する
CloudWatchアラームの設定: 監視条件を伝えて、AWS CLIやTerraformで設定するコードを生成させる
SLI / SLOの設計補助: 「ECサイトのSLI/SLOを設計するときに考慮すべき指標は？」と聞いて、設計の出発点にする

7. セキュリティレビューの補助

なぜ相性がいいのか

セキュリティの設定ミスは、サービス障害や情報漏洩など重大な事故につながりかねません。生成AIに設定ファイルやポリシーを渡してレビューさせると、人間だけでは見落としがちなポイントを指摘してくれることがあります。

こう使うと便利

IAMポリシーのレビュー: ポリシーのJSONを貼り付けて「過剰な権限が付与されていないか確認して」と頼む
セキュリティグループの確認: ルール一覧を渡して「不要なポートが公開されていないかチェックして」と依頼する
設定ファイルの監査: Nginx、SSH、MySQLなどの設定を渡して、セキュリティ上の懸念点を指摘してもらう

ここは気をつけよう

機密情報（認証情報、内部IPアドレスなど）をそのまま外部の生成AIに送信してはいけません。送信前にマスキングしましょう
生成AIのレビュー結果はあくまで補助です。最終判断はセキュリティの知見を持つ人間が行ってください

生成AIを業務で使うときの共通の注意点

ここまで紹介した活用方法に共通して意識すべきポイントをまとめます。

出力は必ず検証する

生成AIの出力にはハルシネーション（事実と異なる情報の生成） が含まれることがあります。インフラの設定ミスはサービス障害やセキュリティ事故に直結するため、生成されたコードや設定は必ず検証環境でテストしてから本番に適用してください。

機密情報の取り扱いに注意する

業務で扱う設定ファイルやログには、認証情報・内部ネットワーク構成・顧客データなどが含まれがちです。外部のAIサービスに送信する前に、以下を確認しましょう。

利用するAIサービスのデータ取り扱いポリシー
自社のセキュリティポリシーで外部AIの利用が許可されているか
送信前に機密情報をマスキングできないか

AIの得意・不得意を把握する

生成AIに何でも任せるのではなく、得意な領域で活用するのが効果的です。

得意なこと	不得意なこと
定型コードの雛形生成	プロジェクト固有の設計判断
公式ドキュメントの要約	最新情報の正確な反映
エラーメッセージの一般的な解説	複雑な環境依存の障害分析
ベストプラクティスの提示	組織固有の運用ルールの考慮