インフラ領域では、AIに本番環境を直接操作させるのではなく、構成設計レビュー、設定ファイルレビュー、IaCレビュー、作業手順書レビュー、ログ要約、障害一次切り分けに使うのが安全で効果的である。
9.0b PMO AIPC — 社内ノウハウ蓄積 MCP Server（インフラ観点）
PMO AIPC はセキュリティ担保エリア内の Hermes + Ollama MCP Server — 組織の社内ノウハウ蓄積地。Skill · 手順 · 観点 · プロンプト型 · 失敗パターンを非機密の範囲で集約し、開発 PC は MCP Client として参照・依頼するだけ。Hermes を開発 PC 直置きしない。詳細は 第20章 Hermes / PMO AIPC と dev_docs_guide 第10章。
| 層 | 推奨 | メリット | デメリット・注意 |
|---|
| サンドボックス | Docker / リモート（本番で local 禁止） | blast radius 封じ込め | 「入れ子 Docker」だけでは不十分な場合あり |
| 秘密情報 | sops / マネージドシークレット（dotfile 直置き禁止） | 漏洩経路の削減 | エージェントが読めるパスに置かない |
| ツール | MCP で明示・権限付き・ログ付き | 統合の標準化 | ad hoc シェルは監査不能 |
| 可観測性 | OTel · 全ツール呼び出しトレース | インシデント時の再現 | トレースなしは「3時の謎動作」になる |
| 予算 | トークン上限 · ループ検知 | 請求サプライズ防止 | cron + 常時稼働は積み上がる |
| 承認 | 送信・削除・本番書込は人間ゲート | 精度保証の最終関門 | 全自動は PoC 範囲外 |
インフラスキル（第17章 9.15）と同様、Hermes 型も監査官・下書き役に限定。本番変更は既存変更管理＋人間承認（第13章）。
9.1 インフラAI活用の目的
| 目的 | 内容 |
|---|
| 設定ミス削減 | OS、ミドルウェア、ネットワーク、権限、FW、証明書、監視設定の漏れを減らす |
| 構築手順の標準化 | 人による手順差、手順書の古さ、作業証跡不足を減らす |
| IaC品質向上 | Terraform、Ansible、CloudFormation、Bicep、Kubernetes YAMLなどをレビュー |
| セキュリティ強化 | 不要ポート、過剰権限、暗号化漏れ、公開設定ミス、秘密情報混入を検出 |
| 運用保守の安定化 | ログ調査、アラート要約、障害一次切り分け、暫定対応案作成 |
| 属人化防止 | 熟練者の確認観点をチェックリスト化する |
| 引き継ぎ品質向上 | 構成情報、設定根拠、障害対応履歴を文書化する |
9.2 公開事例
| 事例 | 概要 | 提案への使い方 |
|---|
| AWS Bedrock + SCP準拠IaC生成 | Service Control Policiesに準拠したIaC生成を支援する考え方。 | 会社のガードレールに沿ったIaC生成・レビューの根拠にする。 |
| Azure SRE Agent | 本番運用の診断・解決支援、MTTR低減を狙うAI-powered reliability assistant。 | AIOps/運用支援の方向性として使う。 |
| HashiCorp Sentinel | Terraform plan/applyにPolicy as Codeを組み込む。 | AI生成IaCの危険変更を止める仕組みとして使う。 |
| Checkov | Terraform、Kubernetes、Dockerfile等をスキャンするIaCセキュリティツール。 | AI生成IaCの機械検査レイヤーとして使う。 |
| AidAI研究 | 過去オンコール経験から障害診断を支援する研究。 | 障害票・運用ログのRAG活用の根拠にする。 |
9.3 インフラエンジニア向け活用マップ
| 業務 | AI活用 | 品質安定化への効果 |
|---|
| サーバ設計 | 構成レビュー、非機能要件チェック | 可用性・性能・運用漏れの削減 |
| OS設定 | パラメータレビュー、ハードニング確認 | 設定ミス・セキュリティ漏れ削減 |
| ミドルウェア設定 | Apache/Nginx/Tomcat/PostgreSQL等の設定レビュー | 性能・セキュリティ・運用性向上 |
| ネットワーク設定 | ポート、FW、SG、ルーティング確認 | 通信不備・過剰公開の防止 |
| IaC | Terraform/Ansible/YAML生成・レビュー | 再現性・差分管理・レビュー性向上 |
| CI/CD | デプロイ手順、ロールバック手順レビュー | リリース事故防止 |
| 監視 | アラート設計、閾値レビュー | 検知漏れ・過検知の削減 |
| 障害対応 | ログ要約、原因候補、対応案作成 | MTTR短縮 |
| セキュリティ | CIS、脆弱性、秘密情報、権限レビュー | 侵害リスク削減 |
| DR/バックアップ | RPO/RTO、復旧手順レビュー | 復旧不能リスク削減 |
9.4 構築前レビュー
あなたはインフラ設計レビュー担当のシニアエンジニアです。
以下のサーバ構成案をレビューしてください。
観点：
1. 可用性
2. 性能
3. セキュリティ
4. ネットワーク
5. OS設定
6. ミドルウェア設定
7. 認証・認可
8. ログ
9. 監視
10. バックアップ
11. 復旧手順
12. 運用引き継ぎ
13. 構築作業時のリスク
出力形式：
| No | 分類 | 指摘内容 | リスク | 推奨対応 | 確認先 |
9.5 サーバ構築手順書作成・レビュー
| 項目 | 内容 |
|---|
| 作業目的 | 何のための作業か |
| 前提条件 | OS、権限、接続先、メンテナンス時間 |
| 事前確認 | バックアップ、疎通、空き容量、依存サービス |
| 作業手順 | コマンド、設定ファイル変更 |
| 確認手順 | systemctl、curl、ログ、ポート、画面確認 |
| 切り戻し | 設定戻し、サービス再起動、スナップショット復元 |
| 影響範囲 | 停止するサービス、利用者影響 |
| 証跡 | 実行結果、ログ、スクリーンショット |
| 完了条件 | 何をもって完了とするか |
手順書作成プロンプト
あなたはLinuxサーバ構築手順書の作成担当です。
以下の要件に基づき、作業手順書を作成してください。
必ず含めること：
1. 作業目的
2. 前提条件
3. 事前確認
4. バックアップ取得
5. 作業手順
6. 確認コマンド
7. 正常時の期待結果
8. 異常時の確認箇所
9. 切り戻し手順
10. 作業証跡として残すもの
注意：
- 危険なコマンドは理由と影響を説明する
- rm、chmod 777、firewall無効化などは原則禁止として代替案を示す
- 本番作業前提で、安全側に倒す
9.6 設定ファイルレビュー
あなたはサーバ設定レビュー担当です。
以下の設定ファイルをレビューしてください。
重点観点：
- セキュリティ上危険な設定
- 過剰権限
- 不要な公開
- 暗号化不足
- ログ不足
- 性能上の懸念
- 冗長性・可用性の懸念
- 運用時に障害になりやすい設定
- 推奨値から外れている可能性のある設定
出力形式：
| No | パラメータ | 現在値 | 懸念 | 推奨値 | 理由 | 影響 | 変更時の注意 |
9.7 AI + IaC 品質ゲート
要件整理
↓
AIでIaC案生成
↓
人間が一次確認
↓
terraform fmt
↓
terraform validate
↓
tflint
↓
checkov / terrascan / tfsec
↓
terraform plan
↓
Policy as Code
↓
レビュー承認
↓
検証環境へapply
↓
疎通・監視・ログ確認
↓
本番反映
Terraform生成プロンプト
あなたはTerraformに強いクラウドインフラエンジニアです。
以下の要件を満たすTerraformコードを作成してください。
前提：
- 本番利用を想定
- セキュリティ優先
- 最小権限
- 暗号化有効
- ログ有効
- タグ付け必須
- 破壊的変更を避ける
- 変数化できる値はvariables.tfへ分離
- 出力すべき値はoutputs.tfへ分離
出力：
1. main.tf
2. variables.tf
3. outputs.tf
4. terraform.tfvars.example
5. README
6. セキュリティ上の注意
7. terraform plan前に確認すべき事項
IaCレビュー用プロンプト
あなたはIaCレビュー担当です。
以下のTerraformコードをレビューしてください。
観点：
1. 構文・構成
2. 命名規則
3. 最小権限
4. 公開範囲
5. 暗号化
6. ログ
7. バックアップ
8. タグ
9. 破壊的変更リスク
10. コスト増加リスク
11. 運用監視
12. セキュリティスキャンで検出されそうな点
出力形式：
| No | 重要度 | 該当箇所 | 指摘 | リスク | 修正案 |
9.8 OS・ミドルウェア確認観点
| 対象 | チェック項目 |
|---|
| OS共通 | アカウント、SSH、パッチ、時刻同期、ログ、監査、ファイル権限、不要サービス、FW、ディスク、バックアップ、監視 |
| Webサーバ | TLS、不要メソッド、ディレクトリリスティング、ヘッダ、証明書、ログ、worker、keepalive、timeout |
| DBサーバ | listen範囲、接続元、認証方式、権限、暗号化、バックアップ、リストア、slow query、監査ログ、レプリケーション |
| Windows Server | Administrator、RDP、Firewall、Windows Update、イベントログ、AD/GPO、バックアップ |
9.9 監視・障害対応
あなたはSRE兼インフラ障害対応担当です。
以下のアラート、ログ、メトリクスをもとに、障害の一次切り分けを行ってください。
出力形式：
1. 事象の要約
2. 影響範囲
3. 時系列
4. 原因候補
5. 可能性が高い順のランキング
6. 追加で確認すべきログ・コマンド
7. 暫定対応案
8. 恒久対応案
9. 切り戻し案
10. 顧客・利用者への報告文案
注意：
- ログにないことを断定しない
- 推測は推測と明記する
- 本番影響のある操作は「要承認」と明記する
9.10 インフラ向けエージェントスキル（公開・人気）
skills.sh 掲載のインフラ・IaC・クラウド向けスキル。第17章の開発向けスキルと併せて、インフラPoCの「型」として使える。
| スキル | 提供元 | 週次Installs（概算） | リポStars | 主な用途 |
|---|
| azure-prepare → azure-validate → azure-deploy | microsoft/azure-skills | 各156K前後 | 1.2K | Azureデプロイ前準備・検証・実行の3段ゲート |
| azure-validate | microsoft/azure-skills | 387K | 1.2K | Bicep/Terraform/CLIのデプロイ前検証、RBAC確認 |
| terraform-best-practices | terramate-io/agent-skills | 203+ | 33 | Terraform 37ルール・10カテゴリのレビュー基準 |
| terramate-best-practices | terramate-io/agent-skills | — | 33 | スタック分割・ドリフト・CI/CD orchestration |
| InsideOut | luthersystems/insideout-agent-skills | — | — | AWS/GCP設計、コスト見積、Terraform生成・ドリフト検知 |
| systematic-debugging | obra/superpowers | 143K | 227K | 障害・ログ調査の根本原因分析（インフラ障害にも転用） |
| supabase-postgres-best-practices | supabase/agent-skills | 231K | 2.2K | DBサーバ設定・SQL・RLSレビュー |
| playwright-best-practices | currents-dev | — | — | 監視付きWeb/APIのE2E・CIパターン |
| VMware-AIops | zw008/VMware-AIops | — | — | vCenter/ESXiの運用支援（要厳格ガバナンス） |
Microsoft Azure Skillsは1リポジトリ内に174+スキル。週次Installs合計はskills.sh上で数百万規模。案件がAzure中心なら azure-prepare → azure-validate → azure-deploy の順序固定が参考になる。
9.10.1 Microsoft Azure Skills — 3段ゲート（詳細）
思想：AIにいきなり terraform apply させない。計画書→検証→デプロイの状態機械。
npx skills add https://github.com/microsoft/azure-skills --skill azure-prepare
npx skills add https://github.com/microsoft/azure-skills --skill azure-validate
npx skills add https://github.com/microsoft/azure-skills --skill azure-deploy
| スキル | メリット | デメリット・注意 |
|---|
| azure-prepare | deployment-plan.md を残し、属人化した「頭の中の構成」を文書化 | Azure/Azure DevOps前提。オンプレのみ案件には不向き |
| azure-validate | Bicep build、Terraform validate、RBAC/IDの事前チェック。第9.7節IaCゲートと整合 | validate通過＝本番安全、ではない。人間承認必須 |
| azure-deploy | エラー回復・デプロイ後検証手順がスキル化されている | 387K installsでも、本番は変更管理・承認とセットでないと危険 |
9.10.2 terramate-io — terraform-best-practices
npx skills add https://github.com/terramate-io/agent-skills --skill terraform-best-practices
37ルールを優先度付きで参照。AI生成Terraformの「人間レビュー観点表」として第9.7節のIaCレビュープロンプトと併用する。
| メリット | デメリット・注意 |
|---|
| state管理・モジュール設計・セキュリティを体系化 | リポStarsは小さめ（33）。内容はTerramate社保守のルール集 |
| checkov/tfsec指摘の「なぜダメか」説明に使える | マルチクラウドでもAWS/GCP/Azure個別の社内標準は追記要 |
9.10.3 インフラ向けスキル選定（社内提案用）
| 環境 | 最初に試すスキル | 機械チェックとセット |
|---|
| Azure案件 | azure-validate（prepare/deployment-planとセット） | Bicep build、Policy、Sentinel相当 |
| Terraform全般 | terraform-best-practices | fmt, validate, tflint, checkov, plan |
| Linux/ミドルウェア | 第9章プロンプト（手順書・設定レビュー） | ansible-lint、CIS benchmark手動確認 |
| Kubernetes | 第9.7節＋checkov/conftest | kubectl dry-run, kube-score |
| DB（Postgres） | supabase-postgres-best-practices | EXPLAIN、監視メトリクス |
| 障害対応 | systematic-debugging | ログ保全、変更履歴、ロールバック手順 |
9.11 Before / After 事例（インフラPoC想定）
数値定義・月次スケジュールは 第11章 11.3 と整合。全事例は3か月PoC内で計測（I-2は1〜2か月目、I-1は2〜3か月目、I-3は3か月目が主）。
Before / After事例I-1：Terraform PRレビュー＋checkov＋AIレビュー
| 項目 | Before | After（3か月PoC終了時） |
|---|
| 本番反映前の設定ミス指摘 | 月2件（うち1件はロールバック） | 月0件（検証環境で事前検出） |
| checkov High指摘の放置日数 | 中央値 5日 | 中央値 1日 |
| AI指摘採用率（IaC） | — | 58%（公開SG、タグ不足、暗号化漏れ等） |
| planレビュー時間/PR | 45分 | 25分（機械＋AI一次、人間は差分判断） |
使ったスキル：terraform-best-practices ＋ 第9.7節IaCプロンプト ＋ checkov/tflint。
Before / After事例I-2：サーバ構築手順書のAIレビュー
| 項目 | Before | After（PoC 1〜2か月目で効果、3か月終了時に確定） |
|---|
| 作業中の手順漏れ（切り戻し・確認） | 四半期3件 | 四半期0件 |
| 手順書レビュー工数 | 上級 2h/件 | 上級 1h/件 |
| 新人作業時の確認質問 | 平均8件/作業 | 平均3件/作業 |
使ったスキル：第9.5節手順書プロンプト。PoC成功後は第9.14の導入用指示を標準化。
Before / After事例I-3：障害ログの一次切り分け（AI＋systematic-debugging）
| 項目 | Before | After（PoC 3か月目・模擬訓練含む） |
|---|
| 一次切り分けまでの時間 | 中央値 90分 | 中央値 45分 |
| 原因候補の網羅性（事後評価） | — | 上位3候補に真因含む率 78% |
| 誤った本番操作（暫定対応） | 年1件 | 0件（要承認ルール徹底） |
使ったスキル：第9.9節障害プロンプト ＋ systematic-debugging。AIは「候補」、復旧判断はオンコール担当。
9.12 インフラエンジニア向け：最初の1週間
| 日 | 実施内容 | 成果物 |
|---|
| 月 | AI利用ガイドライン・禁止事項（第13章）確認。対象は「レビューのみ」に限定 | チーム合意メモ |
| 火 | 直近の構築手順書1件を第9.5プロンプトでレビュー | 指摘一覧、採否記録 |
| 水 | Terraform/Ansible PR 1件に第9.7ゲート＋checkov | scan結果、AIレビュー結果 |
| 木 | 公開スキル1本試用（terraform-best-practices または azure-validate） | 試用所感 |
| 金 | 週次振り返り：有効だった指摘・誤指摘・工数 | PoC週次メモ |
9.13 オンプレ・VMware・Windows向け
| 領域 | AI活用（安全側） | スキル・ツール例 | 禁止・注意 |
|---|
| VMware | 構成図・変更手順のレビュー、ログ要約 | VMware-AIops（要社内承認・読取中心） | 本番vCenter操作の自動実行 |
| Windows Server | GPO/FW/パッチ手順書レビュー | 第9.8節チェックリスト＋社内SKILL | ドメイン管理者権限での自動変更 |
| ネットワーク | FWルール表、変更影響の整理 | 第9.4構築前レビュープロンプト | FW開放の自動判断 |
| バックアップ/DR | RPO/RTO・復旧手順の抜けチェック | 第9.1目的表＋手順書プロンプト | リストア実行の自動化 |
9.14 インフラスキル導入用指示
terraform-best-practices 等と併用。詳細一覧は 第19章。
【PoC担当者への導入指示】
1. npx skills add https://github.com/terramate-io/agent-skills --skill terraform-best-practices
2. 対象：次のIaC PR。checkov/tflint結果とplan要約を添付してレビュー依頼
3. 出力：指摘一覧（重要度・修正案）。採否を変更申請に記録
4. 人間：本番apply・ロールバック判断。第9.15禁止事項を遵守
9.15 インフラAI活用の禁止事項
- AIに本番環境を直接変更させる
- 権限付与の自動判断
- FW/SG開放の自動判断
- データ削除
- バックアップ削除
- 証明書・秘密鍵のAI投入
- セキュリティ例外承認
- 障害原因の断定
