No-Vibe Coding 実践編：ログを「表示」から「契約」に変える

ノレない優等生なコーディング。
ノレない、でも、たぶん正しい。

私はそれをノーバイブ コーディングと呼んでいます。
（※ ノー・バイブコーディングではありません）

そのログ、本当に「ログ」でしたか？

少し、身に覚えのある話から始めます。

• とりあえず print() をログに置き換えた
• フレームワーク標準の logger をそのまま使っている
• ログは出ているし、動いているから問題ない

でも、ふと振り返るとこうなっていませんか？
今までのログ実装って、print の代わり以上の役割を持っていただろうか？

ロギングのパッケージは山ほどあります。
どれも優秀で、どれも汎用的です。

でも逆に言えば──
あなたの運用に最適化されたログではない。

ここで一度、こう考えてみませんか？
「専用のロガー」を持つ、という選択肢。

今回やること：ログの要件を固定する

ここで言う「要件」は、ログを頑張って読むためのものではありません。

目標はただ一つ。
読まなくても、運用できる状態を作ること
そのために必要な、最低限の要件です。

要件（運用が本当に欲しいもの）

1) ファイル名やテーブル名に意味があっても読まない

ファイル名やテーブル名に意味があっても、それを人間が解釈する前提にしない。
ログは「画面」ではなく、機械が扱う事実として出力する。

2) 開始と終了が必ず分かる

• start と end が必ず対応する。
• duration を機械的に計算できること。

ここが曖昧なログは、事故対応で必ず詰む。

3) アーカイブ処理は必須

実行環境にログを置き続けない。
ローテーション・圧縮・退避が必ず回ること。
保存先は S3 / NAS など抽象IFでよいが、退避しない構成は不可。

4) 関数名ログは、運用では使えない

「どの関数で落ちたか」では足りない。
必要なのはどの業務イベントが失敗したか。
event_name は関数名ではなく、業務語彙で固定する。

なぜ、毎回これを確認してしまうのか？

多くの現場で、この4要件を毎回レビューで確認することになります。

では、逆に考えてみる
「表示・記録」ではないロガーを作ったらどうなるか。

例えば：

• start / end を IFとして強制する
• INFO では スタックトレースを出せない
• DEBUG は サンプリングして負荷で捨てる
• tick で ローテーション・圧縮・退避を必ず回す
• PII / Secrets は 自動マスクする
• 反パターンは 仕様として禁止する

つまり──
ログの仕様そのものを責任境界（RCA）として凍結する。

ログは「作法」ではなく「契約」になる

こうすると、ロギングは「実装者の流儀」ではなく、守られるべき契約になります。
そして、ここからが面白いところです。

この契約（logger_spec.yaml）があれば、
あなたのシステムと生成AIは、自然に繋がる。

「この仕様を厳密に満たすロガーを作れ」
と、はっきり依頼できるからです。

次は、実際にそれを作ってみる話をします。