【第7回】認証基盤における生成AI（ChatGPT/Claude/Gemini）を活用したIaCと運用自動化

これまでの全6回の連載を通じて、Windows Server 2025をベースとした「ADDS（ディレクトリ）」「ADFS/WAP（認証・境界防御）」、それを支えるLinuxの「LVS（超高可用性負荷分散）」、そしてクラウドと結ぶ「Entra ID Connect」、さらにはパケットレベルでのトラブルシューティング手法に至るまで、M365ハイブリッド認証基盤の「設計・構築・保守」のすべてを網羅してきました。

これでインフラ基盤としては完成ですが、プロのインフラエンジニアの仕事は「作って終わり」ではありません。日々のログ監視、証明書の更新、パッチ適用によるノードの切り離しなど、運用フェーズのタスクが延々と続きます。特にLinux（Bash/sysctl）とWindows（PowerShell/WMI）という全く異なるOSアーキテクチャが混在するこの環境において、手動での運用はヒューマンエラー（オペレーションミス）による大規模障害の引き金となります。

連載第7回となる今回は、この複雑なハイブリッドインフラの運用を劇的に効率化し、コードベースで管理（IaC：Infrastructure as Code）するための最強のパートナー、「生成AI（Generative AI）」の戦略的活用法にフォーカスします。ChatGPT（GPT-4o）、Claude 3.5 Sonnet、Gemini 1.5 Proといった代表的なモデルをインフラエンジニアの視点で比較し、現場でそのまま使える高度なプロンプトエンジニアリングと自動化スクリプトの生成手法を徹底解説します。

---

1. ハイブリッドインフラ運用における自動化の壁とIaCの重要性

これまで構築してきたM365ハイブリッド認証基盤は、堅牢性が高い反面、運用フェーズにおいてインフラエンジニアに高度なスキルセットを要求します。
例えば、「ADFSサーバー（Windows）にパッチを当てるため、LVS（Linux）のロードバランシングから一時的にノードを切り離す」という単純な運用作業を考えてみましょう。これらを手動で行う場合、以下の手順を踏むことになります。

1. Linuxサーバー（LVSマスター）にSSHログインし、keepalived.conf を編集して該当のADFSノードの重み（weight）を 0 にする。
2. systemctl reload keepalived を実行し、ipvsadm -L -n で既存のコネクション（パーシステンス）がドレイン（排出）されるのを待つ。
3. Windows Server（ADFSノード）にRDPログイン（またはWinRM接続）し、Windows Updateを実行して再起動する。
4. 再起動後、ADFSサービスが正常に稼働しているか Get-AdfsProperties 等で確認する。
5. 再びLinuxサーバーに戻り、keepalived.conf を元に戻す。

このような「OSを跨いだオペレーション」は、手順書（ExcelやWiki）に頼った人間による手作業では必ずミスが発生します。ノードの切り離しを忘れて再起動すれば、ユーザーの認証セッションが強制切断され、M365へのログイン障害を引き起こします。

IaC（Infrastructure as Code）による解決

この問題を解決するのが IaC（インフラのコード化） です。AnsibleやTerraformを用いて、これらの手順をすべてコード（YAMLやHCL）として記述し、Gitでバージョン管理を行い、CI/CDパイプラインからワンクリックで実行する状態を目指します。
しかし、Linuxに強いエンジニアが、WindowsのWMIやPowerShellの深いモジュール仕様まで把握してAnsible Playbookを記述するのは学習コストが極めて高くなります。ここで最大のブレイクスルーをもたらすのが「生成AI」の活用なのです。

2. インフラエンジニアのための生成AI徹底比較（GPT/Claude/Gemini）

一口に「生成AI」と言っても、LLM（大規模言語モデル）ごとに得意・不得意があります。エンタープライズのインフラ構築・運用において、プロのエンジニアは用途に合わせてモデルを使い分けます。ここでは代表的な3つのモデルの比較と、インフラエンジニアにとっての「強み」を解剖します。

1. GPT-4o (OpenAI / Microsoft Azure OpenAI)

【得意領域：Microsoftエコシステムのコード生成とIaC全般】
Microsoftとの強力なパートナーシップにより、Windows Server、Active Directory、M365の公式ドキュメントやPowerShellコマンドレットの仕様を最も深く学習しているモデルです。
Ansibleの win_shell や win_command モジュールを用いたWindows Server 2025の構成管理コードや、Terraformプロバイダの記述において、圧倒的な安定感を誇ります。「PowerShellでTry-Catchを含めた堅牢なエラーハンドリングを書いて」と指示すると、本番環境でそのまま動くレベルの堅牢なスクリプトを生成します。

2. Claude 3.5 Sonnet (Anthropic)

【得意領域：ログの相関解析と複雑なトラブルシューティング】
Claude 3.5 Sonnetは、推論能力（コーディングや論理パズル）において非常に高いベンチマークを叩き出しています。インフラエンジニアにとって最大の魅力は「ログの文脈を読み取る力」です。
前回の第6回で扱ったような、「Linuxの tcpdump の出力結果（テキスト）」と「WindowsのXMLイベントログ」という異なるフォーマットのデータをプロンプトに同時に入力し、「この2つのログの時系列からネットワークレイヤーの矛盾点を指摘して」と指示した際の回答精度は、現状のAIモデルの中で群を抜いています。

3. Gemini 1.5 Pro (Google)

【得意領域：超大容量コンテキストを用いたアーキテクチャ全体のレビュー】
Gemini 1.5 Proの最大の武器は、最大200万トークンという「異常なまでに巨大なコンテキストウィンドウ」です。
自社の「M365認証基盤のネットワーク構成図（PDF）」「LVSの keepalived.conf の全文」「ADFSの全エクスポート設定（XML）」をすべてプロンプトに投げ込み、「このアーキテクチャ全体におけるSPOF（単一障害点）と、ARPフラックス対策の漏れがないかレビューして」といった、従来のAIではトークン溢れで不可能だった「システム全体のコンサルティング」を依頼することができます。

3. IaC生成実践：AnsibleとPowerShell DSCの自動生成プロンプト

生成AIから高品質なインフラコードを引き出すためには、プロンプトに「前提条件」「制約事項」「出力フォーマット」を厳密に定義する「プロンプトエンジニアリング」が不可欠です。

ここでは、前述した「ADFSノードのパッチ適用に向けたLVSからの切り離しと再投入」を自動化するAnsible Playbookを、GPT-4oに生成させるためのプロフェッショナルなプロンプト例を紹介します。

インフラエンジニア向け・高品質プロンプトの型

# 命令
あなたは熟練のインフラ・自動化エンジニアです。以下の要件と制約事項に従い、LinuxのLVS(Keepalived)とWindowsのADFSを連携して操作するAnsible Playbookを作成してください。

# 目的
ADFSサーバー（Windows Server 2025）へのパッチ適用のため、LVS（Ubuntu）のトラフィック割り当てを安全に解除（ドレイン）し、パッチ適用後に再投入する自動化フローを構築する。

# 環境・前提条件
- 実行環境: Ansible Core 2.15 以上
- ターゲット1 (Load Balancer): Ubuntu 22.04, Keepalived稼働, インベントリグループ名: [lvs_servers]
- ターゲット2 (ADFS Node): Windows Server 2025, インベントリグループ名: [adfs_servers]
- 認証: Windows側はWinRMを利用。

# 処理のステップ要件
1. [LVS側] 対象のADFSノードのIPアドレスを `keepalived.conf` の設定からコメントアウト、または weight を 0 に変更する（lineinfileモジュール等の冪等性を担保した手法を使用）。
2. [LVS側] `systemctl reload keepalived` を実行。
3. [LVS側] 既存のTCPセッションが切れるまで 60秒待機（pauseモジュール）。
4. [ADFS側] win_updates モジュールを用いてWindows Updateを実行し、必要に応じて自動再起動（reboot）させる。
5. [ADFS側] 再起動後、WinRMが応答するまで待機し、ADFSサービス（adfssrv）が "Running" 状態になるのを確認する。
6. [LVS側] 1で変更した `keepalived.conf` を元の状態（有効）に戻し、再度リロードする。

# 出力制約
- AnsibleのYAMLフォーマットとして、そのまま実行可能な完全なPlaybookを出力すること。
- 各タスクには日本語で詳細な name (コメント) を付けること。
- 余計な解説は不要。コードブロックのみを出力すること。

このように、「OS・ミドルウェアのバージョン」「ステップごとの具体的なモジュール指定」「冪等性（何度実行しても同じ結果になること）の担保」をプロンプトに含めることで、AIは一般的なサンプルコードではなく、実業務で即戦力となる高品質なIaCを出力してくれます。これにより、LinuxエンジニアがWindowsの構成管理を行う学習コストは10分の1以下に圧縮されます。

4. 運用自動化の実装：ADFS証明書「爆弾」を回避する監視スクリプト

連載第3回および第6回で警告した「ADFS証明書爆弾」。トークン署名証明書の有効期限が切れ、Entra IDとのメタデータ同期が失敗すると、全社規模のログイン障害が発生します。
この大惨事を未然に防ぐため、「ADFSの証明書の残り日数を毎日チェックし、30日を切ったらTeams（またはSlack）のWebhookにアラートを飛ばす」監視スクリプトを作成しましょう。これも生成AIを利用すれば数秒で記述可能です。

生成AIが作成したPowerShell監視スクリプトの例

AI（Claude 3.5 Sonnet）に「ADFSのトークン署名証明書の有効期限を取得し、TeamsへJSON形式でWebhook通知するPowerShellスクリプト」を要求して生成された、実践的なコードの一部です。

# ADFS証明書有効期限監視スクリプト (毎日のタスクスケジューラで実行)

# TeamsのWebhook URL
$WebhookUrl = "https://linuxkoubou.webhook.office.com/webhookb2/..."
$AlertDays = 30

# ADFSのトークン署名証明書（Token-Signing）を取得
$Certs = Get-AdfsCertificate -CertificateType Token-Signing

foreach ($Cert in $Certs) {
    $ExpiryDate = $Cert.Certificate.NotAfter
    $RemainingDays = ($ExpiryDate - (Get-Date)).Days

    if ($RemainingDays -le $AlertDays) {
        $Message = "⚠️ [緊急アラート] ADFSトークン署名証明書の有効期限が近づいています！`n"
        $Message += "証明書Thumbprint: $($Cert.Thumbprint)`n"
        $Message += "有効期限: $($ExpiryDate.ToString('yyyy/MM/dd')) (残り $($RemainingDays) 日)`n"
        $Message += "至急、Entra ID側(MsolService)のフェデレーションメタデータ更新を実施してください。"

        # Teamsへ送信するJSONペイロードの構築
        $Payload = @{
            text = $Message
        } | ConvertTo-Json

        # WebhookへのPOST送信
        Invoke-RestMethod -Uri $WebhookUrl -Method Post -ContentType "application/json" -Body $Payload
    }
}

このスクリプトをADFSサーバーの「タスクスケジューラ」に登録しておく（この登録作業自体もAnsibleの win_scheduled_task でIaC化できます）ことで、インフラエンジニアは「毎朝サーバーにログインして証明書の期限を指差し確認する」という苦痛なルーチンワークから完全に解放されます。

5. セキュリティとコンプライアンス：生成AI利用時の機密情報マスキング

生成AIをインフラ運用に活用する際、プロとして絶対に守らなければならない鉄則があります。それは「機密情報（クレデンシャルや社内トポロジ）を絶対にプロンプトに入力しないこと」です。

ChatGPTなどのパブリックなLLMモデルは、入力されたデータをAIの学習に利用する可能性があります（※API経由やEnterprise版を除く）。そのため、LVSの keepalived.conf や ADFSのイベントログをコピペしてAIに解析させる前に、以下の情報を必ずマスキング（サニタイズ）しなければなりません。

• 実在するグローバルIPアドレス・プライベートIPアドレス（例: 10.0.10.11 → IP_ADDRESS_1）
• 実際のドメイン名とホスト名（例: sts.linuxkoubou.local → sts.example.com）
• パスワード、APIキー、証明書の秘密鍵や拇印（Thumbprint）
• ログに含まれる実在のユーザーIDやUPN

Linuxエンジニアであれば、sed や awk コマンドを用いて、ログファイルからこれらの機密情報を機械的に置換・マスキングしてからAIに投入するワンライナースクリプトを用意しておくべきです。

# ログファイル内のドメイン名とIPアドレスをマスキングするsedコマンドの例
cat /var/log/messages | sed -e 's/linuxkoubou\.local/example.com/g' -e 's/10\.0\.10\.[0-9]\{1,3\}/10.x.x.x/g' > sanitized_log.txt

「利便性」と「セキュリティ」のバランスを保つことこそが、エンタープライズで活躍するインフラエンジニアの必須スキルです。

6. 第7回の総まとめと次回予告

本記事では、M365ハイブリッド認証基盤の運用を劇的に近代化する「生成AIを活用したIaCと運用自動化」について、プロのインフラエンジニアの視点で解説しました。

• 自動化の必然性： LinuxとWindowsが混在する認証インフラにおいて、手動オペレーションはSPOF（単一障害点）を生む原因となる。IaC（Ansible等）によるコード化が不可欠。
• 生成AIモデルの使い分け： IaCのコード生成にはGPT-4o、ログの相関解析にはClaude 3.5、全体アーキテクチャのレビューには大容量コンテキストを持つGemini 1.5 Proを適材適所で使い分ける。
• プロンプトエンジニアリング： インフラのコードを生成させる際は、OSバージョン、対象モジュール、冪等性の担保といった「制約事項」を厳格に指定することで高品質な出力を得る。
• セキュリティの鉄則： AIにログや設定ファイルを投入する前に、必ずIPアドレスやドメインなどの機密情報をマスキングする。

AIはインフラエンジニアの仕事を奪うものではなく、私たちを「単純作業」から解放し、アーキテクチャ設計という「より高度でクリエイティブな仕事」へ引き上げてくれる最強の武器です。

さて、全8回にわたる長大な連載も、次回の【第8回】がいよいよ最終回となります。
最終回では、これまでに構築した強固なハイブリッド認証基盤に対して、ゼロトラスト時代に必須となる「条件付きアクセス（Conditional Access）」と「MFA（多要素認証）」の統合を行い、強固なセキュリティ要塞を完成させます。ADFSのクレームルールとEntra IDのポリシーがどのように連携してサイバー攻撃を弾き返すのか、総まとめとして解説しますので、最後までお見逃しなく！