Linuxエンジニアの生成AI活用 第4回：手作業をゼロへ！AIに「インフラ自動化スクリプト」を書かせる極意

こんにちは！「LINUX工房」メインライターの「リナックス先生」よ。

前回の第3回では、難解なエラーログをパイプでAIに流し込み、一瞬で原因を特定するトラブルシューティングの技術をマスターしたわね。ログ監視の苦痛から解放されたあなたに、今回はさらに衝撃的なスキルを伝授するわ。それは「インフラ自動化スクリプトそのものを、AIに書かせる」という技術よ。もはや、文法を暗記してゼロからコードを打ち込む時代は終わったの。これからは、あなたの「要件定義力」が自動化の鍵を握るわ！

---

1. AIを「プログラマー」として使う：インフラ自動化の新たなパラダイム

① 概念と背景（Why）

インフラエンジニアの業務において、自動化スクリプトの作成は長らく「職人技」とされてきました。特定のディレクトリから古いファイルを抽出し、圧縮し、リモートサーバーへ安全に転送した上で、古いアーカイブをローカルから削除する。この一連のプロセスをBashスクリプトで記述するためには、`find` の複雑なオプション、`tar` の圧縮フラグ、`scp` や `rsync` の公開鍵認証設定、そして何より、途中のコマンドが失敗した際に処理を安全に停止させるための厳格なエラーハンドリング（`set -e` や `trap` 構文）を熟知している必要があります。初心者がこれらの文法仕様をリファレンスマニュアルから引き出し、ゼロからタイピングしてテストを繰り返す作業は、数時間から数日を要する苦行でした。この高い学習コストが、インフラ運用における手作業の撲滅を阻む最大の障壁となっていたのです。

生成AI（LLM）のプログラミング能力の劇的な向上は、この障壁を完全に破壊しました。AIは、世界中のオープンソースリポジトリや公式ドキュメント、無数の技術ブログ（Linux工房も含まれるかもしれませんね）を学習データとして取り込んでいるため、BashやPythonの文法、そしてLinux特有のコマンド仕様において、人間を凌駕する知識の引き出しを持っています。あなたが「30日以上前のログファイルを圧縮して転送するスクリプトが欲しい」と自然言語で要求するだけで、AIは数秒でベストプラクティスに基づいたコードを書き上げます。これは、あなた自身が「コードを書く作業者」から、要件を定義し成果物をレビューする「システム設計者（アーキテクト）」へと役割をシフトさせることを意味します。

しかし、この新たなパラダイムには落とし穴が存在します。AIは文脈を補完する能力に長けていますが、あなたが意図を明確に伝えなければ、勝手な仮定に基づいてコードを生成してしまいます。例えば、「ファイルを削除する」という指示に対して、AIが `rm -rf` という極めて危険なコマンドを選択する可能性は十分にあります。つまり、AIをプログラマーとして使役するための真の技術とは、プログラミング言語の文法を覚えることではなく、「AIに対して、処理の前提条件、例外発生時の挙動、利用してよいコマンドの制限、環境変数の扱いなどを、誤解の余地なく厳密に指示する『要件定義力（プロンプトエンジニアリング）』」なのです。この技術を習得しなければ、AIの生成した不透明なコードによってサーバー環境を崩壊させるリスクを背負うことになります。

② 実践手順と完全なコード（How）

AIに正確なスクリプトを生成させるための「要件定義プロンプト」のテンプレートです。これをテキストファイルとして保存し、前回の連載で導入した `aichat` や `gh copilot` に読み込ませることで、安全で高品質なコードを引き出します。

# prompt_template.txt として以下の内容を保存します

あなたは経験豊富なシニアLinuxインフラエンジニアです。
以下の要件を満たすBashスクリプトを作成してください。

【目的】
Webサーバーのアクセスログ（/var/log/nginx/）のうち、30日以上更新されていない古いログファイルを検出し、アーカイブ圧縮した上で、指定のバックアップディレクトリ（/archive/nginx_logs/）に移動する。

【絶対遵守ルール】
1. スクリプトの先頭には必ず `set -euo pipefail` を記述し、厳格なエラーハンドリングを行うこと。
2. 対象となるファイルは拡張子が `.log` または `.log.gz` のものに限定すること。
3. `rm` コマンドによる削除は行わず、必ず `mv` コマンドで移動させること。
4. 処理の開始時、該当ファイルの検出時、圧縮完了時、およびエラー発生時には、現在時刻付きで標準出力にログメッセージを表示すること。
5. ディレクトリパスや保持期間（30日）は、スクリプトの先頭で変数として定義し、後から人間が変更しやすくすること。
6. 出力はBashのソースコードのみとし、マークダウンのコードブロックで囲むこと。説明文は一切含めないこと。

上記の条件を完全に満たすスクリプトを出力せよ。

このプロンプトを `aichat` に読み込ませてスクリプトを生成させます。

# 作成したプロンプトファイルを標準入力として aichat に渡し、結果をファイルに保存する
cat prompt_template.txt | aichat > backup_nginx_logs.sh

③ プロによるコードの「1行・1オプション」徹底解説

• set -euo pipefail：これはインフラスクリプトにおける「命綱」です。
  • `-e`：コマンドが非ゼロのステータスで終了（エラー）した場合、即座にスクリプトを停止します。
  • `-u`：未定義の変数を参照しようとした場合、エラーとして停止します。意図せぬパスの削除などを防ぎます。
  • `-o pipefail`：パイプラインの途中のコマンドが失敗した場合、パイプライン全体の終了ステータスをエラーとして扱います。

  この1行をプロンプトで強制することで、AIの生成するコードの安全性が飛躍的に向上します。

• `rm` コマンドによる削除は行わず：インフラ運用において、自動化スクリプトによるファイルの「完全削除」は最もリスクが高い操作です。安全なディレクトリへの「移動」に制限することで、被害を最小限に抑えます。
• 変数として定義し：AIは要件を満たすために、パスや数値をコード内の至る所に直書き（ハードコーディング）する悪癖があります。変数化を強制することで、再利用性の高いコードを書かせます。
• 出力はBashのソースコードのみとし：この制約により、AIの出力結果をそのままリダイレクト `>` でファイルに保存し、即座にスクリプトファイルとして利用できるようになります。

④ 現場のリアル（失敗談とノウハウ）

初心者がAIにスクリプトを書かせる際、「よしなにやって」という態度で丸投げした結果、本番環境のデータベースバックアップスクリプトが、バックアップ先のディスク容量を確認せずに処理を強行し、サーバーのディスク使用率を100%にしてシステム全体を停止させたという恐ろしい事故が実際に起きています。AIは「あなたが指示したこと」を完璧にこなしますが、「あなたが指示を忘れたこと」に対する配慮はゼロです。ディスク容量のチェック、権限の確認、ネットワークの疎通確認など、人間が無意識に行っている「事前の安全確認」を、プロンプトの【絶対遵守ルール】に明記する癖をつけてください。これがプロの要件定義です！

---

2. Bashスクリプトの生成：要件定義から完全なコードの出力まで

① 概念と背景（Why）

前項のプロンプトによって、AIからどのようなBashスクリプトが生成されるのかを具体的に見ていきましょう。BashスクリプトはLinuxの標準的なシェル言語であり、ファイル操作、プロセス管理、テキスト処理などのOSネイティブな操作において右に出るものはありません。外部ライブラリをインストールすることなく、どのサーバー環境に持っていってもそのまま動くという「可搬性（ポータビリティ）」の高さが、インフラ自動化においてBashが不動の地位を築いている理由です。

AIが生成するBashスクリプトは、多くの場合、人間が書くよりも「堅牢で冗長」になります。人間が書くと面倒くさがって省略してしまうようなエラーハンドリングや、変数のダブルクォーテーションによる囲み（空白文字を含むパスへの対策）、コマンドの実行結果の検証などを、プロンプトの指示に従って几帳面に記述してくれます。これは、属人性を排除し、誰が見ても同じように読める標準化されたコードを手に入れるための強力な手段です。

生成されたコードを読むことは、あなた自身のLinuxコマンドの学習にも直結します。「なるほど、ファイルを検索して一括処理するには、`find` コマンドの `-exec` オプションではなく、`while read` ループにパイプで渡すのが安全な書き方なのか」といった、熟練エンジニアのコーディングスタイルを、AIの生成物から直接吸収することができるのです。AIは単なるコードジェネレーターではなく、あなた専用のマンツーマンプログラミング講師でもあるという視点を持ってください。

② 実践手順と完全なコード（How）

先ほどのプロンプトによってAIが生成した、理想的なBashスクリプトの完全な出力例です。省略記号は一切含めず、このまま実行可能な品質です。

#!/bin/bash

# 厳格なエラーハンドリング設定
set -euo pipefail

# --- 変数定義 ---
TARGET_DIR="/var/log/nginx/"
ARCHIVE_DIR="/archive/nginx_logs/"
RETENTION_DAYS=30
CURRENT_DATE=$(date +"%Y%m%d_%H%M%S")
ARCHIVE_FILENAME="nginx_logs_archive_${CURRENT_DATE}.tar.gz"

# --- 関数定義 ---
# 時刻付きログ出力関数
log_info() {
    echo "[INFO] $(date +"%Y-%m-%d %H:%M:%S") : $1"
}

log_error() {
    echo "[ERROR] $(date +"%Y-%m-%d %H:%M:%S") : $1" >&2
}

# --- メイン処理 ---
log_info "古いNginxログのアーカイブ処理を開始します。"

# 対象ディレクトリの存在確認
if [[ ! -d "${TARGET_DIR}" ]]; then
    log_error "対象ディレクトリ ${TARGET_DIR} が存在しません。処理を中断します。"
    exit 1
fi

# アーカイブ先ディレクトリの作成（存在しない場合）
if [[ ! -d "${ARCHIVE_DIR}" ]]; then
    log_info "アーカイブディレクトリ ${ARCHIVE_DIR} を作成します。"
    mkdir -p "${ARCHIVE_DIR}"
fi

log_info "${RETENTION_DAYS}日以上前のログファイルを検索します。"

# findコマンドで対象ファイルを検索し、一時配列に格納
# 拡張子が .log または .log.gz のものを対象
mapfile -t TARGET_FILES < <(find "${TARGET_DIR}" -maxdepth 1 -type f \( -name "*.log" -o -name "*.log.gz" \) -mtime +${RETENTION_DAYS})

if [[ ${#TARGET_FILES[@]} -eq 0 ]]; then
    log_info "対象となる古いログファイルは見つかりませんでした。処理を終了します。"
    exit 0
fi

log_info "${#TARGET_FILES[@]} 個の対象ファイルを発見しました。圧縮処理を開始します。"

# tarコマンドで対象ファイルを圧縮
# -c: 作成, -z: gzip圧縮, -f: ファイル指定, -P: 絶対パスを維持しない
if tar -czf "${ARCHIVE_DIR}/${ARCHIVE_FILENAME}" -C "${TARGET_DIR}" $(for f in "${TARGET_FILES[@]}"; do basename "$f"; done); then
    log_info "アーカイブ ${ARCHIVE_FILENAME} の作成に成功しました。"
else
    log_error "アーカイブの作成に失敗しました。処理を中断します。"
    exit 1
fi

# 圧縮成功後、対象ファイルをアーカイブディレクトリへ「移動」させる
# （元のディレクトリから隔離することで、実質的なクリーンアップとする）
log_info "対象ファイルを ${ARCHIVE_DIR} 配下の一時退避用ディレクトリへ移動します。"

BACKUP_SUBDIR="${ARCHIVE_DIR}/moved_files_${CURRENT_DATE}"
mkdir -p "${BACKUP_SUBDIR}"

for file in "${TARGET_FILES[@]}"; do
    if mv "${file}" "${BACKUP_SUBDIR}/"; then
        log_info "${file} を移動しました。"
    else
        log_error "${file} の移動に失敗しました。"
    fi
done

log_info "すべての処理が正常に完了しました。"
exit 0

③ プロによるコードの「1行・1オプション」徹底解説

• log_info() / log_error()：ログ出力を関数化しています。`>&2` は標準エラー出力へリダイレクトする記述で、通常の情報とエラーの出力をシステムレベルで分離するプロの作法です。
• if [[ ! -d “${TARGET_DIR}” ]]; then：処理を行う前に、前提となるディレクトリが存在するかをチェックしています。プロンプトで指示しなくても、AIが気を利かせて安全装置を組み込んでいます。
• mapfile -t TARGET_FILES < <(find …)：`find` の結果を配列に安全に格納する高度なテクニックです。ファイル名にスペースが含まれていても処理が壊れないように配慮されています。
• -mtime +${RETENTION_DAYS}：指定した日数（30日）より「前」に更新されたファイルを対象とするオプションです。
• if tar -czf … ; then：コマンドの実行結果（成功か失敗か）を直接 `if` 文で評価しています。終了ステータス `$?` を別途確認するよりもスマートで確実な書き方です。

④ 現場のリアル（失敗談とノウハウ）

AIのコードは一見完璧に見えますが、AI自身が「テスト環境」を持たないまま出力していることに注意が必要です。例えば上記の `tar` コマンドの部分で、対象ファイルが数万個存在した場合、コマンドの引数（文字数）制限に引っかかって `Argument list too long` というエラーでクラッシュする可能性があります。現場のプロは、このような境界値の壁を常に意識しており、必要であれば `xargs` コマンドを用いた分割処理にAIのコードを修正させます。AIのコードは「80点のベースライン」としては最高ですが、残りの20点の「過酷な実環境に対する耐性」を保証するのは、人間のエンジニアの役割なのです。

---

3. Pythonスクリプトへの切り替え：複雑なAPI連携とJSON処理を任せる

① 概念と背景（Why）

BashスクリプトはOSのファイル操作には最適ですが、現代のインフラ運用において「弱点」が存在します。それは「複雑なデータ構造（特にJSON）のパース」と「外部のWeb APIとの複雑な連携」です。第1回で `curl` と `jq` を用いてAPIと通信する方法を学びましたが、例えば「AWSのAPIからサーバーの負荷状況をJSONで取得し、特定の条件に合致した場合のみSlackのAPIに通知を投げ、その結果をスプレッドシートのAPIに記録する」といった複雑な条件分岐とデータ加工をBashで行おうとすると、コードがカオス（スパゲッティコード）と化し、メンテナンスが不可能になります。

このような高度な外部連携が必要な場面において、インフラエンジニアはBashからPythonへとスクリプト言語を切り替えます。Pythonは、標準で強力なJSON処理機能（`json` モジュール）やネットワーク通信機能（`requests` ライブラリ）を備えており、可読性が極めて高い言語です。しかし、Bashしか書いたことがないインフラエンジニアにとって、Pythonの文法やライブラリの作法をゼロから学ぶのはハードルが高いのも事実です。

ここでAIの真価が発揮されます。AIにとって、BashからPythonへの翻訳や、PythonによるAPI連携スクリプトの作成は「最も得意とする領域」です。あなたが「指定したURLのAPIを叩いて、JSONの中の特定のキーの値を抽出し、エラーならSlackに通知するPythonスクリプトを書いて」とプロンプトを投げるだけで、AIは例外処理（try-except構文）やタイムアウト設定、環境変数からのセキュアな認証情報の読み込みまでを網羅した、実稼働に耐えうるPythonスクリプトを即座に生成します。AIを活用することで、あなたは言語の壁を越え、システムの要件に合わせて最適なツール（言語）を自在に選択できる「フルスタックなインフラアーキテクト」へと変貌するのです。

② 実践手順と完全なコード（How）

サーバーの死活監視を行い、異常があればSlackへ通知を行うPythonスクリプトをAIに生成させた例です。APIのURLやWebHookURLは環境変数から読み込む安全な設計になっています。

#!/usr/bin/env python3
import os
import sys
import json
import urllib.request
import urllib.error
from datetime import datetime

# --- 設定値の読み込み（環境変数から取得） ---
TARGET_URL = os.environ.get("TARGET_URL", "https://api.example.com/health")
SLACK_WEBHOOK_URL = os.environ.get("SLACK_WEBHOOK_URL")
TIMEOUT_SECONDS = 10

def send_slack_notification(message):
    """Slackへエラーメッセージを通知する関数"""
    if not SLACK_WEBHOOK_URL:
        print("[WARN] SLACK_WEBHOOK_URLが設定されていないため、通知はスキップされます。")
        return

    payload = {
        "text": f"⚠️ *システムアラート*\n{message}"
    }
    data = json.dumps(payload).encode("utf-8")
    
    req = urllib.request.Request(
        SLACK_WEBHOOK_URL, 
        data=data, 
        headers={"Content-Type": "application/json"}
    )

    try:
        urllib.request.urlopen(req, timeout=TIMEOUT_SECONDS)
        print(f"[{datetime.now()}] Slack通知を送信しました。")
    except urllib.error.URLError as e:
        print(f"[ERROR] Slack通知の送信に失敗しました: {e}", file=sys.stderr)

def check_health():
    """対象URLの死活監視を行う"""
    print(f"[{datetime.now()}] 監視を開始します: {TARGET_URL}")
    
    try:
        # ターゲットURLへリクエスト
        response = urllib.request.urlopen(TARGET_URL, timeout=TIMEOUT_SECONDS)
        status_code = response.getcode()
        
        # JSONレスポンスのパース
        response_body = response.read().decode('utf-8')
        data = json.loads(response_body)
        
        # 独自のステータス判定（例: "status": "ok" を期待）
        if data.get("status") == "ok":
            print(f"[{datetime.now()}] [OK] システムは正常に稼働しています。")
        else:
            error_msg = f"APIステータス異常: 期待値 'ok' に対し、'{data.get('status')}' が返却されました。"
            print(f"[ERROR] {error_msg}", file=sys.stderr)
            send_slack_notification(error_msg)
            sys.exit(1)
            
    except urllib.error.HTTPError as e:
        error_msg = f"HTTPエラーが発生しました: ステータスコード {e.code}"
        print(f"[ERROR] {error_msg}", file=sys.stderr)
        send_slack_notification(error_msg)
        sys.exit(1)
    except urllib.error.URLError as e:
        error_msg = f"通信エラーが発生しました: サーバーに到達できません ({e.reason})"
        print(f"[ERROR] {error_msg}", file=sys.stderr)
        send_slack_notification(error_msg)
        sys.exit(1)
    except json.JSONDecodeError:
        error_msg = "レスポンスのJSONパースに失敗しました。不正なデータ形式です。"
        print(f"[ERROR] {error_msg}", file=sys.stderr)
        send_slack_notification(error_msg)
        sys.exit(1)
    except Exception as e:
        error_msg = f"予期せぬエラーが発生しました: {str(e)}"
        print(f"[ERROR] {error_msg}", file=sys.stderr)
        send_slack_notification(error_msg)
        sys.exit(1)

if __name__ == "__main__":
    check_health()
    sys.exit(0)

③ プロによるコードの「1行・1オプション」徹底解説

• #!/usr/bin/env python3：シバンです。特定のパス（`/usr/bin/python` など）に依存せず、環境変数 `PATH` から `python3` の実行ファイルを探し出して実行する、Pythonスクリプトにおける最も堅牢な書き方です。
• os.environ.get(“…”)：スクリプト内に認証情報（Webhook URLなど）をハードコーディングせず、OSの環境変数から動的に読み込んでいます。セキュリティを考慮したプロの設計です。
• urllib.request：サードパーティ製の `requests` ライブラリを使用せず、Python標準ライブラリのみでHTTP通信を完結させています。これにより `pip install` の手間が省けます。
• json.loads(response_body)：APIから返ってきた生の文字列（JSON）を、Pythonの辞書オブジェクトに変換し、プログラム内で扱いやすくしています。Bashの `jq` コマンドに相当する処理です。
• except … as e:：通信タイムアウト、HTTPエラー、JSONのパース失敗など、起こり得るあらゆる異常事態（例外）を細かく捉え、それぞれに適切なエラーメッセージを出力する、非常に丁寧なエラーハンドリングです。

④ 現場のリアル（失敗談とノウハウ）

AIにPythonスクリプトを書かせた際、初心者が引っかかるのが「インデント（字下げ）の崩れ」と「Pythonのバージョン差異」です。AIからコピー＆ペーストしてターミナルのVimに貼り付ける際、ターミナルの設定によってはインデントがズレてしまい、Pythonはインデントのズレを「文法エラー（IndentationError）」として直ちに実行拒否します（ペースト前に `:set paste` を忘れないこと！）。また、AIが最新のPython 3.10以降の構文（`match-case` など）を使ってコードを生成したのに、あなたのLinuxサーバーには古いPython 3.6しか入っておらず動かない、というのもよくある悲劇です。プロンプトで「Python 3.6環境で動くように記述せよ」と指定する泥臭い配慮が、現場ではシステムを救うのです。

---

4. 絶対にそのまま動かすな！AIコードの安全な検証とテスト手法

① 概念と背景（Why）

ここまで、AIがいかに優秀なコード生成能力を持っているかを見てきました。しかし、インフラエンジニアとして絶対に胸に刻まなければならない鉄則があります。それは、「AIが生成したコードを、中身を理解せずに、いきなり本番環境で実行してはならない」ということです。

生成AIは「確率的に最ももっともらしい文字列」を出力しているに過ぎません。プログラムとしての文法は正しくても、システム運用上の「論理」が破綻していることは多々あります。例えば、「特定の古いログファイルを消す」というスクリプトをAIに書かせた際、変数の展開ミスで `rm -rf /var/log/nginx/` ではなく `rm -rf /` と解釈されるようなコードが含まれていた場合、エンターキーを押した瞬間にOS全体が消滅します。

インフラの自動化において、スクリプトのバグは単なる「画面のエラー」では済みません。データの喪失、サービスの停止、セキュリティの破綻に直結します。したがって、私たちがAIを利用する上で最も重要なフェーズは「生成させること」ではなく、生成されたコードの「安全性を検証すること」になります。コードの構文チェックを自動で行うツール（Linter）の活用、そして実際にファイルを変更せずに処理のシミュレーションだけを行う「Dry-Run（空回し）」の設計。これら二つの検証プロセスを経ずにAIのコードを実行することは、エンジニアとしての責任放棄に他なりません。

② 実践手順と完全なコード（How）

AIが生成したBashスクリプトの安全性を検証するための2ステップの手法を実行します。静的解析ツールの導入と、コードへのDry-Runオプションの実装です。

# --- Step 1: 静的解析ツール「shellcheck」による構文チェック ---
# shellcheckをシステムにインストールします
sudo dnf install shellcheck -y

# AIが生成したスクリプト（例: backup.sh）の潜在的なバグや脆弱性を診断します
shellcheck backup.sh

# --- Step 2: スクリプトにDry-Run（空回し）機能を組み込む ---
# 実際のファイルの移動や削除を行わず、何が実行されるかだけを画面に表示する安全装置です。
# AIに対するプロンプトに以下を追加して再生成させます：
# 「スクリプト実行時に --dry-run オプションを渡した場合、実際のファイル移動や削除コマンドは実行せず、実行予定のコマンド文字列を画面に出力するだけのDry-Runモードとして動作するように実装せよ。」

# --- 生成されたDry-Run対応スクリプトのコア部分の抜粋 ---
DRY_RUN=0
if [[ "${1:-}" == "--dry-run" ]]; then
    DRY_RUN=1
    log_info "DRY-RUNモードで実行します。実際の変更は行われません。"
fi

for file in "${TARGET_FILES[@]}"; do
    if [[ $DRY_RUN -eq 1 ]]; then
        echo "[DRY-RUN] 実行予定: mv ${file} ${BACKUP_SUBDIR}/"
    else
        mv "${file}" "${BACKUP_SUBDIR}/"
        log_info "${file} を移動しました。"
    fi
done
# --- 抜粋ここまで ---

# 検証のためのDry-Run実行
./backup.sh --dry-run

③ プロによるコードの「1行・1オプション」徹底解説

• shellcheck backup.sh：`shellcheck` は、Bashスクリプトの文法エラーや、セキュリティ上の脆弱性（クォーテーションの抜けによる変数の意図せぬ展開など）、非推奨な書き方を指摘してくれる世界標準の解析ツールです。AIの書いたコードを人間がレビューする前に、まずはこのツールに通すのがプロの作法です。
• if [[ “${1:-}” == “–dry-run” ]]; then：スクリプトの第1引数 `$1` に `–dry-run` が指定されているかを判定します。`${1:-}` は「引数が未設定でもエラーにならない安全な書き方」です。
• DRY_RUN=1：フラグ変数です。このフラグが立っている間は、スクリプトの挙動が「破壊的変更を行わないモード」に切り替わります。
• echo “[DRY-RUN] 実行予定: mv …”：実際に `mv` コマンドを実行する代わりに、実行されるはずだったコマンドの内容を `echo` で画面に出力します。これにより、対象となるファイルリストが本当に正しいか、意図せぬファイルが含まれていないかを、実行前に人間の目で安全に最終確認できるのです。

④ 現場のリアル（失敗談とノウハウ）