AIコーディングに「運用エンジニアの規律」を持ち込む話 — 5つの作法と5つの禁じ手

TL;DR

ネットワークやインフラの運用エンジニアとして20年近く働いてきた身が、AI協業をきっかけにソフトウェア開発の領域へ踏み込んだ過程で得た、実務で使える作法をまとめてみました。
5つの作法と5つの禁じ手。ベースは「インフラ運用エンジニアの視点」になっていますが、ソフトウェアエンジニアやデータエンジニアの現場にもそのまま転用できる内容だと思っています。
よくある「AI活用Tips」とは少し毛色が違います。AIとのセッションを「変更管理票」「運用手順書」「設計レビュー」と同じ枠組みで扱ってみると、自然に見えてくる作法だけを抽出してみました。
作法のいくつかは、私自身が実際にやらかしたインシデント（失敗）とセットで紹介しています。

なぜ「運用エンジニア視点」というレンズか

我々運用エンジニアは、キャリアを通じて、おおむね次の4つの習慣を体に染み込ませていきます。

作る前に計画する — 設計書、運用手順書、変更管理票の作成。
完了宣言の前に検証する — 検証手順書による確認、変更後の実機チェック。
状態をドキュメント化する — Configの保存、設計書の更新、振り返りレポートの作成。
数字を疑う — 監視データの数値には、常にノイズや誤検知が混じっている前提で画面を見る。

これらの習慣は、AIコーディングアシスタントとの協業にもそのまま適用できると感じています。ルーターの障害切り分けや、変更申請、Configレビューで身につけてきた「規律」は、AIとのセッションが予期せぬ方向へ脱線するのを防ぐための、ちょっとした防波堤になってくれるはずです。

「運用エンジニア視点」と銘打っているのは、単に私のキャリアの出発点がそこだったからというだけで、ここで紹介するパターンの多くはソフトウェアエンジニアやSREの現場でも通用するものだと思います。運用エンジニアという文脈のほうが、私にはこれらの作法をタイトに梱包して説明しやすかった、ただそれだけのことなのかもしれません。

第1部: 5つの作法

作法1 — `CLAUDE.md`(または system prompt) を「変更管理票の前提宣言部」として扱う

インフラ運用の世界では、変更手順書を作成する際、必ず冒頭に前提宣言部を設けます。前提条件、適用範囲、切戻し手順、そして検証項目。AIとの作業でも、この基本姿勢は裏切らないと感じています。

CLAUDE.md は Claude Code に対する永続的な指示ファイルです（他のAIアシスタントにも同様の仕組みがあります）。これを、運用手順書の前提宣言部と同じ感覚で記述してみます。

## Operating principles
- 実装前に必ず計画する
- 曖昧な指示はコーディング前に確認する
- 設計を提案する時は反論をセットで提示する
- 計測方法を示さずに数値を報告しない
- 「仕様上動くはず」と「実走で動くと確認した」を厳密に区別する

これを一度定義しておけば、以降のセッションはすべてこのルールを継承してくれます。毎回前提をイチから説明し直す手間が省けるのは、地味ですが助かるポイントだと思います。「定型テンプレートを作って使い回す」というのは、変更管理票の作成で我々が何度もやってきた、おなじみの運用パターンですよね。

作法2 — 毎回必ず「悪魔の代弁者」を要求する

厳しい設計レビューが存在する理由は、現場の集団思考（予定調和）が本番システムを静かに殺してしまうからだと思っています。AIに対しても、提案を出させるたびに、自分自身の案へ反論させる仕組みを組み込んでおきたいところです。

私が重要な設計議論の際に、必ずAIへ投げかけている3つの問いがあります。

この設計が引き起こす最悪の障害モードは何ですか？
考慮から漏れているエッジケース（想定外のユースケース）は何ですか？
悪魔の代弁者として、この設計を棄却すべき理由を3つ挙げてください。

これを CLAUDE.md に仕込んでおくと、AIから「全面同意します」という思考停止の応答は返ってこなくなります。全肯定しかしないAIは、システムアーキテクチャにおける明確な単一障害点（SPOF）になりかねないと感じています。

作法3 — 曖昧な指示は実装前に必ず確認させる

要件定義の現場において、「ゆるいスペックのまま実装に走る」のは、明確なインシデントの火種です。AIセッションでも事情はだいたい同じで、指示が曖昧な場合、AIは黙ってどれか一つの解釈を勝手に選び取り、意図とは全く違うコードを実装してしまうことがあります。

実例を一つ。私がAIツールを開発していた際、「IDと表示名はペアとして扱い、どちらかがあれば同じグループとして処理してください」と指示したことがあります。しかしAIはこれを「2つの独立した検索キー」と解釈して実装を進めてしまい、マッチング処理の半分を後から作り直すことになりました。

このインシデントの教訓として、CLAUDE.md に次の一文を追加しています。

指示に複数の解釈があり得る場合、コードを書き始める前に必ず私の意図を確認すること。

これは、ファイアウォールに新しいルールを追加する前、後輩に「その処理対象のパケットは、インバウンドですか？アウトバウンドですか？」と念押しして確認させる、ベテランネットワークエンジニアの習慣と全く同じだと思っています。

作法4 — 「机上評価」と「実走評価」を厳密に区別する

運用エンジニアであれば、「仕様書通りなら動くはず（机上評価）」と「実際にLEDが点滅するのを見た（実走評価）」の間に、どれほど残酷な差があるかを骨の髄まで知っているはずです。AIとの作業においてもこの差は確かに存在し、私の感覚では、皆が思っている以上にその溝は深いです。

実例として、AIが「過去データのパターン分析の結果、約99.2%のリコールが見込めます」と申告してきたことがありました。しかし、実データを使って実走評価させたところ、実際のリコールは55%に留まりました。

ここから得られる教訓は「AIは嘘をつく」ということではないと思っています。「パターン分析に基づく予測（机上評価）」と「実際の実行結果（実走評価）」は全くの別物である、という事実があるだけです。計測を示唆する数値が出力されたら、毎回こう問いただすようにしています。

「それは実際に計測した数値ですか？それとも推定値ですか？」

推定値ならそう明記してもらいます。計測値だと言い張るなら、実走した証跡（ログ出力）を提示してもらうようにしています。

作法5 — 検証手順書（スクリプト）をAI自身に書かせる

AIが「このコードは99%のリコールを達成します」と豪語してきたら、そのリコールを計測するための検証スクリプトもセットで書かせるようにしています。そして、それを実際に実走させてみます。

このプロセスを経ることで、AIの出力は次のように変換されていきます。

単なる主張 → 検証スクリプト
検証スクリプト → 監査証跡
監査証跡 → 再現性の担保

これは運用手順書の文化と全く同じ構造だと感じています。「変更手順書と検証手順書は常にペアで作成する」というのは、インフラ運用の基本作法ですよね。検証スクリプト自体が永続的な成果物となり、次の運用担当者へ引き継ぐこともできます。あるいは、数ヶ月後に構成が回帰してしまった、未来の自分自身を助けてくれることになるのかもしれません。

第2部: 5つの禁じ手

禁じ手1 — 要件定義なしの「いい感じにツール作って」

インフラ現場でありがちな「なんかネットワーク遅いから、いい感じに直しといて」という丸投げ依頼の、AI版のようなものです。スコープを明確にせずに投げ渡してしまうと、AIは勝手にスコープを捏造してしまいます。さらにタチの悪いことに、その捏造したスコープに向かって自信満々に突進していくため、間違った方向へ全力で実装を進めてしまうことがあるのです。

セッションの開始は、厳格な要件定義の場として扱うのが安全だと思っています。大まかな目標、絶対に守るべき主要な制約、そして明示的に「スコープ外（やらないこと）」とする範囲の定義。最初に5分かけてスコープを定義しておくだけで、後で5時間かけて切戻しをする羽目になるのを防げる気がします。

禁じ手2 — ヘッドラインの数字を中身の検証なしで信じる

「99%のリコール達成」という報告は、素晴らしく聞こえます。しかし裏を見ると、都合のいい行だけを抽出して計測していた、テストセットがトレーニングデータに混入していた、計測した数値が実際のユーザー体験を全く反映していなかった、ということが多々あります。

数値を報告されたら、鵜呑みにせず、必ず以下を問うようにしています。

具体的にどうやって計測したのか？
どのデータを対象にしたのか？
どのような条件下で実行したのか？
その計測手法にどんなバイアスが潜んでいるのか？

これは、アラートが一件も鳴っていない「オールグリーンの監視ダッシュボード」を見たときに抱くべき疑念と、ちょうど同じ種類のものだと思います。「本当にシステムは正常なのか？それとも監視エージェント自体が死んでいて、報告が上がっていないだけなのか？」

禁じ手3 — 生のエラーテキストを文脈なしで丸投げする

「動かないんですけど」 → 「どうしてですか？」

実際の運用現場で、ルーターの障害を「なんかdownしてます」という一言だけで起票してエスカレーションすることは、まずないですよね。Configの差分、ステータス出力、syslogのエラー行、周辺の接続機器の挙動など、すべての文脈を添えてチケットを切るはずです。

AIに対しても全く同じだと思っています。AIはあなたのローカル環境をエスパーして推測することはできません。実行したコマンド、実際の出力ログ、本来期待していた挙動、そして実際のズレ。これらすべてを提示する。一回のやりとりを「ベンダーの保守窓口に出すバグレポート」と同じ粒度で扱ってみてください。

禁じ手4 — 業務データをコンプライアンスの確認なしにAIへ投げる

デフォルトの想定として、 「プロンプトに入力したデータは、ベンダー側で保存・索引化され、学習に利用される可能性がある」 と考えておきたいところです。ベンダーのマーケティング部門が何と言っていようと、インフラエンジニアとしては最悪のケースを想定しておくほうが安全だと思います。

業務データを取り扱う際の運用の習慣は、極めてシンプルです。マスキング、機密情報の削除、あるいは合成データへの置換。Stack Overflowの質問掲示板に、顧客の生IPアドレスや本番DBの認証情報を貼り付けないのと同じ防衛本能で、プロンプトに顧客の生レコードを貼り付けないようにしたいですね。

禁じ手5 — 「とりあえず動いた」で検証を止める

「コードがエラーを吐かずに走った」ことと、「なぜそのコードで正しく走るのかを論理的に理解している」ことは、全く別の状態だと思っています。

これをインフラ運用の言葉に翻訳すると、こうなるのかもしれません。「一度は偶然動いたが、なぜ動いているのか誰も説明できない構成は、未来に必ず爆発する時限爆弾（インシデント）である」。

とりあえず動いたソリューションに対して、「なぜこれで動くのか」をAIに説明させる。1ラウンドの追加質問を行ってみて、人間側とAI側の双方がその設計の妥当性を説明できないのであれば、それは「青信号」ではなく「黄色信号」として扱うのが安全だと思います。論理的に説明可能なコードだけを本番へ出荷する。説明できないブラックボックスのコードは、本番環境が壊れたその日に、あなた自身の首を絞めることになるかもしれません。

まとめ

10個のパターン全体を貫くコアな考え方は、こんな感じになります。

AIとのセッションに、インフラ運用の厳格な規律を適用してみる。
AIの主張は「外部ベンダーからのセールストーク」として扱い、必ず自分の手元（実機）で検証する。
AIとの対話を「変更管理ウィンドウ」として扱う。前提宣言から始まり、スコープ定義、検証、そして振り返りレポートの作成まで。
AIの出力を「Configの差分」として扱う。追加された行の意味を説明できないなら、その変更はリジェクトする。

ここで、明示的に主張していないこと（誤解してほしくないこと）にも触れておきたいと思います。

これらは運用エンジニアの専売特許ではないと思っています。他領域にも一般化できるはずです。単に「運用」というレンズを通したほうが、私の経験上、パッケージングしやすかっただけのことなのかもしれません。
これらが「唯一絶対の作法」でもないと思っています。5つという数字は、あくまで説明のために情報を削ぎ落とした（損失のある圧縮をした）結果です。あなたの現場で本当に必要な10の作法は、細部で異なっているかもしれません。
これらの規律がカバーしているのは、あくまでAI協業の 構築フェーズ（Day 1） についてです。 運用フェーズ（Day 2） については、全く別の規律が求められると思っているので、また別の記事で語るべきテーマなのかもしれません。本番投入後のAI生成コードの継続監視、サイレントドリフトの検知、AI由来の変更が障害を引き起こした際の切戻し対応。これらは別次元の話になりそうです。本記事のパターンは、本番運用に耐えうる基盤を作るためには必要なものだと思いますが、それだけでは十分ではないとも感じています。

これらの規律は、AIのアジリティ（俊敏性）を殺すためのものではなく、その圧倒的な速度を「監査可能で安全な進行」に変換するための安全装置なのだと感じています。

最後に伝えたい大きな考え方があります。AIは人間のエンジニアリング判断を「置き換える」ものではなく、「増幅」するためのツールなのだと思います。怠惰な判断を増幅させてしまえば、より多くのゴミのようなコードが、より高速に量産されるだけです。規律ある判断を増幅させて初めて、意図が明確で、監査可能で、論理的に説明可能な「プロの仕事」を生み出すことができるのではないでしょうか。

おわりに

この記事もまた、本職の現場経験と個人の主観的観察に基づく、ある種のポエム的な文章です。「これが業界の正解です」と押し付けるつもりはなく、「もし同じような状況で、同じように頭を抱えている人がいたら、私はこんなふうに整理して乗り切ってみましたよ」という、ささやかな共有のつもりで書いてみました。

コメントや指摘は大歓迎です。特に以下のような視点からのフィードバックを期待しています。

あなたの現場なら追加するであろう「6つ目の作法」「6つ目の禁じ手」。
全く異なる異領域からAIコーディングに参入した経験（過去のバックボーンがどう活きたか、あるいは活きなかったか）。
運用エンジニアの規律が、AIワークにどうしてもきれいに転用できなかった失敗ケース。
AIが環境を壊してしまった状態から、どうやって安全に巻き戻すか（切戻し・ロールバック戦略）。
本番運用フェーズ（Day 2）における、AI生成コードの保守への向き合い方。