インフラ実務の属人化を防ぐ！生成AIで行う設計書レビュー＆障害対応OJT術

現場の若手・中途メンバーの育成において、以下のような課題に直面していないでしょうか。

• 「手順書通りには動けるが、システム全体における位置づけを理解しておらず作業者目線から抜け出せない」
• 「過去に何度も指摘したパラメータの不整合やフォーマット崩れを繰り返し、レビュー工数が圧迫される」
• 「障害対応の初動や切り分けの勘所が身につかず、アラートが鳴るたびにベテラン頼みになってしまう」

インフラエンジニアの育成は、座学や手順書のなぞり書きだけでは「全体を俯瞰して自走する力」が育ちにくいのが実情です。一方で、多忙な現場リーダーやプレイングマネージャーが付きっきりで教え続ける体制には限界があります。

そこで有効なのが、「生成AIをOJTのセカンドオピニオン（壁打ち相手・事前レビュー係）として組み込む」アプローチです。

リーダーの育成負荷を抑えつつ、若手の「視座の引き上げ」と「自走力」を同時に育てる実践的なトレーニング術とレビュー設計を解説します。

なぜインフラのOJTは「作業者止まり」になりやすいのか？

従来のOJTで若手が伸び悩む最大のボトルネックは、「自分の担当業務しか見えず、作業がシステム全体・業務全体の中でどう位置づけられているかを俯瞰できないこと」にあります。

手順書を渡して「この通りに設定を入れて」と指示するだけの教育では、次のような壁にぶつかります。

担当作業しか見えない「部分最適の罠」

コマンドが正常に通ることだけが目的化し、「このパラメータ変更が他システムや後続処理にどう波及するか」「障害時にどこがボトルネックになるか」という設計思想やリスクへの想像力が育ちません。

初歩的ミスによる「レビュー手戻りループ」

構文エラー、命名規則違反、CIDRの重複といった「機械的に弾ける初歩的なミス」の指摘にリーダーの時間が奪われ、本来指導すべき「アーキテクチャの妥当性」や「現場の運用設計」に時間を割けなくなります。

自走するエンジニアへ育てるためには、「作業前に背景と波及影響を深く考えさせる仕組み」を日常のOJTフローに組み込む必要があります。

【障害対応OJT】過去ログ×生成AIで行う「AI壁打ちトラブル演習」

障害対応の初期判断力を養うには、過去の実事例を活用した「AI壁打ち演習」が効果的です。

単なるアラートログだけでなく、「当時のインシデント対応履歴」や「問題管理（根本原因・恒久対応）の記録」を活用し、AIを疑似トラブルのトレーナーに仕立てます。

インシデント・問題管理履歴を活用した3ステップ

1. シチュエーション提示： AIから「特定のアラートが発生した」という状況を出題させる
2. 若手による仮説立案と壁打ち： 若手は「このアラートの場合、〇〇プロセスの停止かネットワーク瞬断が疑われます。影響範囲はWeb層全体と推測しますが合っていますか？」とAIに初期判断を提示する
3. AIからのフィードバック： 当時の対応履歴をベースに、「影響範囲の推測は妥当。ただしDBコネクションプール枯渇の二次影響も考慮すべき。次に確認すべきログやメトリクスは何か？」といった問いかけを返し、思考を深めさせる

※ 実践時の注意（セキュリティ・機密情報の保護）

社内の実ログや構成情報をAIに投入する際は、ホスト名、IPアドレス、アカウント名、顧客情報などを必ずダミー値へマスキングしてください。また、利用するAI環境が「入力データの学習利用をオプトアウト（除外）している設定」であることを必ず確認の上で運用してください。

【コピペ可】インシデント初動判断の壁打ちプロンプト

あなたは経験豊富なシニアインフラアーキテクトです。
以下の「過去のインシデント対応記録（マスキング済み）」をもとに、若手エンジニアの障害対応トレーニングを行ってください。

# 前提条件
- まず「発生したアラート事象」のみを私に提示してください。
- 私はそのアラートに対する「初期判断（推定原因・影響範囲・一次切り分けの確認手順）」を回答します。
- 私の回答に対し、以下の観点でフィードバックと追加の問いかけを行ってください。
  1. 影響範囲の想定に抜け漏れ（他システムや二次影響）がないか
  2. 既存システムへの負荷を考慮した確認手順になっているか
  3. 次に確認すべきメトリクス・ログの優先順位は妥当か

# 過去のインシデント情報（ダミーデータ）
[インシデント概要・発生アラート・根本原因・対応履歴を貼り付け]

実機を壊すリスクなく、過去事例をベースにした「初期判断のシミュレーション」を一人で反復できるため、場数を踏みながら一段高い視座で全体影響を捉える初動スキルが定着します。

【品質担保】レビュー効率を劇的に上げる「事前AIセルフチェック」ルール

リーダーのレビュー工数を圧迫する最大の要因は、フォーマット崩れや構文ミスといった「初歩的な手戻りの繰り返し」です。

これを解消するために、「リーダーへ設計書やコードを提出する前に、指定プロンプトによるAIセルフチェック結果の添付を必須化」します。

パラメータ・IaCコードでAIに検知させる8つの観点

パラメータシートやIaCコード（Terraform、Ansible、CloudFormation、各種スクリプト）に対し、機械的に検知できる項目を網羅させます。

カテゴリ	チェック項目	具体的な確認・検知内容
品質・整合性	構文・書式・命名規則	文法エラー、インデント崩れ、プロジェクト命名規約の遵守
	パラメータ整合性	CIDRブロック/IP重複、サブネット・ルーティング・ポートの矛盾
セキュリティ	アクセス制御・通信保護	不要な全開放（0.0.0.0/0）、過剰権限、暗号化設定の有無
	秘匿情報の混入	APIキー、パスワード、接続文字列などのハードコード検知
安全性・運用性	破壊的変更（Destroy）	パラメータ変更に伴うリソース再作成・データ消失リスクの検知
	既存影響・負荷	実行時の通信断リスク、CPU/メモリ・帯域への一時的負荷集中
	冪等性・再実行性	複数回実行や途中失敗時のリカバリ安全性
	運用メタデータ	環境識別タグ（Prod/Dev）、コスト管理・オーナータグの付与漏れ

【コピペ可】IaC・設計書セルフチェックプロンプト

あなたはシニアインフラアーキテクトです。
以下のインフラ構成定義（またはパラメータシート）について、提出前セルフチェックを実施してください。

# レビュー観点
1. 【構文・規約】文法エラー、フォーマット崩れ、命名規則違反はないか
2. 【整合性】CIDRブロック、IPアドレス、ポート等の設定値に矛盾や重複はないか
3. 【セキュリティ】意図しないポート開放（0.0.0.0/0）、過剰な権限、パスワードや秘密情報の直書きがないか
4. 【破壊的変更】適用によって既存リソースの再作成（Destroy）や意図しないデータ消失が起きるリスクはあるか
5. 【既存影響・負荷】稼働中システムへの通信断やリソース枯渇を引き起こす要因はないか
6. 【冪等性・運用】再実行時の安全性、および必要なタグ（環境名・管理用）の付与漏れはないか

# 指摘フォーマット
- 判定（OK / 要修正 / 要確認）
- 指摘箇所と理由
- 推奨される修正案

# 対象コード / パラメータ
[ここにコードや設定値を貼り付け（秘匿情報はマスキングすること）]

初歩的なミスやセキュリティの抜け漏れを若手自身がAIとの対話で解消してから提出させることで、リーダーの手戻りストレスは劇的に削減されます。

AI任せは危険？現場リーダーが担保すべき「5つの責任分界点」

AIセルフチェックを導入しても、「現場の文脈」「業務制約」「最終的な安全性と責任」はAIには代替できません。

コードの文法チェックをAIに委ねた分、リーダーは「現場の泥臭い運用調整とリスク管理」に100%のリソースを集中させます。

リーダーが確認すべき網羅的チェックリスト

観点	リーダーがチェックすべき具体項目
1. 業務制約・事前調整	・アプリ開発チーム、業務部門、外部ベンダーへの事前告知と合意は完了しているか ・決算期、夜間バッチ、他システムの大規模リリースと重なっていないか
2. 作業段取り・要員配置	・メンテナンス時間枠内に余裕をもって収まるタイムラインか ・作業者、確認者（ダブルチェック）、統括者（判断者）の役割分担が明確か
3. 切り戻し設計（最重要）	・判断基準（クライテリア）： 何分遅延、またはどんなエラーが出たら中止するか ・限界点（PoNR）： 不可逆な変更に入る直前の「引き返せる限界地点」はどこか ・復旧手順： バックアップからのリストア手順と所要時間は検証済みか
4. 監視体制・エスカレーション	・作業中および作業直後に注視すべきメトリクス（レイテンシ、エラー率等）と監視担当者 ・トラブル時の即時連絡先（上位マネージャー、ベンダーサポート等）と判断権限
5. 事後処理・原状復帰	・一時的に迂回・停止させた監視アラートやFWルールの戻し手順 ・作業完了後のドキュメント・構成管理台帳の更新計画

技術的な整合性は「若手×AI」の段階で担保させ、リーダーは「想定外の事態が起きたときに、チームとシステム、そしてサービスを守り切れるか」という本質的な防波堤の役割を果たします。

まとめ：明日からチームで試せる「AI事前レビュー必須化」

インフラ教育の属人化を解消し、若手を自走させるための第一歩は非常にシンプルです。

明日から試せるワンアクション：

「設計書やコードをリーダーに提出する前に、指定プロンプトによる『AIレビュー結果』の添付をルール化する」

1. 若手の変化： AIの指摘を通じて「なぜこの設定が必要なのか」「何がリスクなのか」を自発的に調べる習慣がつき、作業者目線から一段視座が上がる
2. リーダーの変化： 初歩的なミスの指摘から解放され、段取り・調整・切り戻しといった「現場マネジメントの本質」に注力できる
3. チームの変化： 属人化していたナレッジがプロンプトやチェックリストとして標準化され、組織全体の品質が底上げされる

まずは明日のチームミーティングで、本記事で紹介した「セルフチェック用プロンプト」を1つ共有し、実際のパラメータシートで試してみることから始めてみませんか？