前回投稿した『運用エンジニアの規律』の記事が少し長くなってしまったので、そこから一番即効性のある「最初の作法」だけを切り出して、コピペで使える最小テンプレとして整理してみました。

Claude Code に毎日触る運用エンジニアとして、最初の頃にやらかして痛かったことが「毎セッションで同じ前提を説明し直す」ことでした。

「曖昧な指示は確認してね」「数値を報告するときは計測方法を添えて」「動くと確信できたコードだけ提案して」。同じことを毎回チャットの最初に書く運用は、すぐに疲弊します。書き忘れた瞬間に AI が暴走して、過去にテストデータと本番用 yaml を混同して上書きされかけた経験があり、そこから CLAUDE.md（または ChatGPT の custom instructions / Gemini の system prompt）に常設化する運用に切り替えました。

コピペできる最小テンプレ（5 行）

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

これを CLAUDE.md のルートに置いておくだけで、以降のセッションは全部このルールを継承してくれます。アシスタントを切り替えても（Claude Code → ChatGPT → Gemini）、対応する system prompt 系の場所に同じ 5 行を貼り付ければ移植可能です。

各行が何を防いでいるか（一言ずつ）

実装前に必ず計画する — いきなり書き始めて、設計の前提が崩れているコードを量産させないための歯止め
曖昧な指示はコーディング前に確認する — 「ID と表示名のペア」を「2 つの独立な検索キー」と勝手に解釈されたインシデントを起こしてから、必ず入れている
設計を提案する時は反論をセットで提示する — 全肯定 AI は単一障害点（SPOF）です
計測方法を示さずに数値を報告しない — 「99.2% リコール見込み」と言われて実走したら 55% だった事故防止
「仕様上動くはず」と「実走で動くと確認した」を厳密に区別する — 一度書きました、コンパイル通りました、と「動いた」は別物

一段だけ深く

このテンプレ自体は「何を書くか (What)」と「どう書くか (How)」の話で、なぜこれが効くのか (Why) や どこまで使えるのか (Trade-off) までは踏み込んでいません。

「全肯定 AI が SPOF」「机上評価と実走評価の差」あたりの背景論や、運用エンジニアの規律をどう AI 協業に転用するかは、姉妹記事で 5 つの作法 + 5 つの禁じ手として整理しています。テンプレを使い始めた後、もう少し深く考えたくなったら以下を読んでみてください。

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