18年の現場経験で分かった！インフラエンジニアの生成AI活用術｜スクリプト作成から障害対応まで

「深夜のアラート対応で起こされ、膨大なエラーログと格闘する……」
「定型的なシェルスクリプトや環境構築コードの作成に何時間も取られる……」

日々の運用保守や構築作業で、このような泥臭い作業に追われていませんか？

最近では「ChatGPTなどの生成AIを使えば作業がラクになる」と言われていますが、一般的な使い方（雑な質問）のまま実務で使うと、存在しないコマンドや嘘の設定値を出力する「ハルシネーション（誤回答）」が発生し、かえって本番障害を引き起こすリスクがあります。

私は18年間、大手SIerで大規模基幹システムのインフラ運用・設計に携わってきました。

その経験から確信しているのは、「インフラ特有の制約やコンテキスト（前提情報）を正しくAIに与えれば、生成AIは事故を起こさない最強の相棒になる」ということです。

本記事では、18年の現場知見をもとに、本番事故を防ぎながらインフラ実務（スクリプト作成・ログ解読・手順書レビュー）で生成AI（ChatGPT/Claude等）を100%使いこなすための実践手法をわかりやすく解説します。

以前、私は以下の記事で、AIを利用する際の「マインドセット」と「鉄の掟」についてまとめていますので、合わせて確認してみてください。

💡 今すぐ現場で使えるプロンプトをお探しの方へ

本記事で解説している「インフラ特有の制約・背景を組み込んだプロンプト」を、要件定義から障害対応までコピペで即使える30パターンの型（テンプレート）としてNoteにまとめました。

現場作業の効率化・手戻り防止にそのまま活用したい方は、ぜひあわせてご覧ください。

なぜインフラエンジニアに今、生成AI（ChatGPT/Claude）が必要なのか

泥臭い作業の限界と、AI活用で変わる現場

インフラエンジニアの業務は、OS・ネットワーク・クラウド・ミドルウェアが複雑に絡み合っています。 パラメータシートの作成、ログの解析、Cronスクリプトの作成、手順書のダブルチェックなど、手作業で行うには時間がかかる「泥臭いデスクワーク」が山積みです。

生成AIを活用することで、こうした定型作業にかかる時間を50%〜80%削減できます。浮いた時間を「より洗練されたシステムアーキテクチャの設計」や「サービス品質の向上」といった、人間しかできない付加価値の高い業務に投入することが可能になります。

「AIに丸投げ」は危険！インフラならではのハルシネーションリスク

しかし、アプリケーション開発とは異なり、インフラ領域における設定ミスやコマンドの打ち間違いは、システム全体の停止やデータ消失に直結します。

ChatGPTなどのAIは、前提条件を与えないと「一般的な回答」や「一見正しそうだが実在しないオプション」を悪気なく出力します。AIを安全に使うためには、「AIのアウトプットを評価・判断できる人間の技術力」と「適切な前提条件（コンテキスト）を与える指示技術」が絶対に不可欠です。

【実践】ChatGPTに障害対応・スクリプト作成をさせる「コンテキスト（背景情報）」の与え方

AIが使いものにならない原因＝「前提条件（コンテキスト）」の不足

「ChatGPTに質問しても、使えない回答しか返ってこない」と感じる最大の理由は、AIに対して「あなたのシステム環境や制約」を何も教えていないからです。

AIに正解を出させるためには、以下の5つの要素（コンテキスト）をプロンプトに組み込む必要があります。

• 役割（Role）: AIにどのような立場で回答させるか（例: Linux管理者、AWSアーキテクト）
• 目的（Goal）: 何を達成したいのか
• 環境情報（Context）: OSバージョン、クラウド環境、ミドルウェアの構成
• 制約事項（Constraints）: やってはいけないこと、セキュリティルール、冪等性の確保
• 出力フォーマット（Format）: コードのみ、Markdownテーブル、解説付きなど

【Before / After】プロンプトの出し方でここまで差が出る！

❌ 悪いプロンプト例（コンテキストなし）

ログのクリーンアップをするシェルスクリプトを書いて。

【AIの回答リスク】

rm -rf /var/log/* のような危険なコマンドを提案されたり、ログローテーション中やプロセス掴み中のファイルを削除してシステムを停止させるリスクがあります。

⭕ 改善されたプロンプト例（コンテキストあり）

# 役割
あなたはLinuxシステム管理者です。

# 目的
/var/log/app/ 内の古くなったログファイルを安全に圧縮・削除するShellスクリプトを作成してください。

# 環境情報
- 対象OS: AlmaLinux 9
- 対象ディレクトリ: /var/log/app/ (*.log)

# 制約事項
- 過去30日以上更新されていないログのみを対象とし、削除前に.gz形式で圧縮すること。
- 実行時にログファイルが存在しない場合でもエラー終了しない冪等性を確保すること。
- 削除実行前に、処理対象のファイル一覧を標準出力にログとして記録すること。

# 出力フォーマット
実行可能なBashスクリプト（コメント解説付き）

【効果】

安全装置（ログ出力、条件判定、冪等性）が最初から組み込まれた、本番環境でそのまま使える高品質なスクリプトが一発で出力されます。

🔧 現場の制約・文脈を組み込んだプロンプトを「型」として手に入れませんか？

毎回イチからプロンプトを組み立てるのは時間がかかります。

そこで、私が18年の現場経験をもとに作成した「要件定義・設計構築・運用保守・障害対応」の全30シーン対応プロンプトテンプレートを有料Noteで公開しています。

あなたの環境（AWS/オンプレ/Linux等）に合わせて [ ] を書き換えるだけで、即座にプロ品質のアウトプットが得られます。手作業の工数を劇的に減らしたい方はチェックしてみてください。

※Note記事内で1パターン無料お試しプロンプトも公開中です！

AI活用事例：深夜2時の「作業中止」を回避したAIとの対話

インフラ実務において、AIが最も価値を発揮するのは「未知のエラー」への一次対応です。

【ケーススタディ：夜間アップデート作業】

ある日の深夜2時、基幹システムのソフトウェアアップデート中に、検証環境では発生しなかった未知のエラーに直面しました。綿密に計画を立て、関係各所と調整を重ねてやっと確保したメンテナンスウィンドウです。解決できなければ、その場で「作業中止・切り戻し」を判断し、再調整に奔走しなければなりません。

夜間は保守ベンダーへの即時連絡も難しい中、私はAIを「思考の壁打ち相手」として活用しました。単にエラー内容を投げるのではなく、インフラ構成、直前の操作手順、出力されたエラーログの全文を提示。さらに、結論だけを求めず「解決策に至る思考ロジックをステップバイステップで説明すること」を条件としました。

AIが提示したロジックから、特定のライブラリ競合の可能性が浮上。それをヒントに公式ドキュメントで裏取りを行い、その場で修正を適用することで、計画通り作業を完遂できました。

論理的な教訓：

AIは「答え」を出す装置ではなく、人間が「判断」するための「仮説」を高速に生成するツールです。

---

深夜の呼び出し中にAIという「相談相手」がいるだけで、孤独な戦いの心理的ハードルはぐっと下がります。

ツールを駆使して作業時間を短縮するのと同時に、深夜対応特有の「心を削るプレッシャー」とどう付き合っていくか。 18年この現場を生き抜いてきた私のメンタル管理術も、あわせて読んでみてください。

自動化：スクリプト作成の「安全な検証サイクル」

運用スクリプトやマクロを生成する場合、AIが書いたコードをそのまま本番環境で実行することは厳禁です。私は、以下の「三段階の検証プロセス」を必ず経るようにしています。

インフラ自動化の検証プロセス

フェーズ	実施内容
1. 構造理解	生成されたコードの各行の意味をAIに解説させ、挙動を100%理解する。
2. 開発環境検証	独立した小規模環境で、構文エラーや基本的な戻り値を確認する。
3. 検証環境検証	本番同等の構成で、異常系（エラー時に安全に停止・ログ出力するか）を確認する。
4. 本番適用	実行ログを記録し、万が一の切り戻し手順を確保した上で実施する。

AIに対し「結論の根拠となった参照元と考え方」を提示させることで、コードの意図が明確になり、エンジニア自身のスキル向上にも繋がります。

事例：AIの「嘘」から学んだリスク管理

AIは時に、極めてもっともらしい「嘘（ハルシネーション）」をつきます。特に「事実（Fact）」の確認において、この傾向は顕著です。

【ケーススタディ：EOSL調査の落とし穴】

ハードウェアの保守期限（EOSL）を調査するためにAIを利用した際のことです。提示された日付を鵜呑みにしてリプレース計画の策定を進めていましたが、後に保守ベンダーへ正式な確認を行ったところ、AIの回答が数ヶ月間違っていることが判明しました。

危うく誤ったスケジュールで各所への調整を完了させてしまうところでしたが、最終決定前のダブルチェックで修正が間に合いました。

論理的な教訓：

AIは「情報のインデックス（目次）」としては優秀ですが、確定的な日付や仕様、リリース情報の「エビデンス（証拠）」にはなり得ません。最終的な事実は、必ず公式サイトや保守契約に基づくベンダー回答から取得する必要があります。

役割分担：判断の責任は常に人間にあり

インフラエンジニアとして、AIに任せる領域と、人間が堅持すべき領域を明確に定義することが、長期的なシステムの安定稼働に繋がります。

AIと人間の役割分担表

項目	生成AIの役割	エンジニア（人間）の役割
情報処理	膨大なログの要約・パターン抽出・一次解析	提示された情報の正誤判断とリスク評価
アウトプット	スクリプトの雛形作成、Markdown構成案の生成	実環境への最適化、脆弱性の排除、最終テスト
意思決定	複数の解決策・仮説の提示	最終的なGo/No-Goの判断と結果への責任
説明責任	回答に至る論理プロセスの提示	顧客や組織に対する納得感のある説明と合意形成

おわりに：AIを使いこなし、プロとしての判断力を磨く

若手エンジニアの皆さんに最後に伝えたいのは、「AIが出した答えが、本当に自社のインフラ構成に合致しているか」を常に問い続けてほしいということです。

「AIがこう言ったので」という報告は、プロの現場では通用しません。AIに思考ロジックを提示させ、それを自分の知識や外部ソース（ベンダー回答、公式ドキュメント）と突き合わせる。その「答え合わせ」のプロセスこそが、AIに代替できないエンジニアとしての「現場力」を育てます。

AIという強力な副操縦士を賢く使いこなし、浮いた時間を「より堅牢なシステム設計」や「将来の技術への投資」に充てていきましょう。

---

生成AIという強力な武器を手にしたことで、私たちの働き方は大きく変わろうとしています。

変化の激しいAI時代に、私たちインフラエンジニアがSIerという土俵でどう価値を出し、生き残っていくべきか。 ツールを使いこなしたその先にある「エンジニアとしての生存戦略」を、一度真剣に考えてみませんか。