📖

No-Vibe Coding 実践編：Loggerを生成AIに作らせる

に公開
AI
アーキテクチャ
設計
生成 AI
tech

前回、「ログは表示ではなく契約だ」という話をしました。

ただ、ここで一つ問題があります。
「ルールだ」と言っただけでは、誰も守ってくれない という点です。
　「ログは JSON で書くこと」
　「start と end を必ず出すこと」
・・守れないですよね。面倒ですもん。

ログ契約を「仕様」として定義する

No-Vibe Coding では「人の善意で守られる設計」は最初から失敗すると考えます。
そこで今回、私はログの仕様を YAML で定義しました。
ぜひ生成AIに貼って試してみて下さい。

https://raw.githubusercontent.com/VCDesign-org/architecture-yaml-protocols/refs/heads/refactor/split-by-role/legacy/collection/logger/prompts/prompts.md
https://raw.githubusercontent.com/VCDesign-org/architecture-yaml-protocols/refs/heads/refactor/split-by-role/legacy/collection/logger/specs/logging-design-template.v1.yaml
上記を読み込んでください

リポジトリ

  • logger.info("文字列") を許さない
  • 関数名ログを許さない
  • start と end を対にしないと完結しない

つまり「自由にログを書けないロガー」を最初から作る、ということです。

start / end がペアである理由

運用で本当に欲しいのは、こういう情報です。

  • どの処理が
  • いつ始まり
  • いつ終わり
  • どれくらい時間がかかったか

なので、

startProcess()
...
endProcess()

を 必須構造 にします。
duration_ms は人が書きません。ロガーが計算します。

INFO と DEBUG を分ける理由

INFO は 運用ログ です。

  • スタックトレースは禁止
  • 状態と結果だけを書く
  • 毎回必ず出る

DEBUG は 調査用ログ です。

  • サンプリングする
  • 通常は出ない
  • 本番では絞る

この分離をしないと、ログが多すぎて誰も見ないという最悪の状態になります。

ログローテーションは「後付け」では破綻する

ログは必ず増えます。

  • ローテーション
  • 圧縮
  • 退避
    を 最初から責務として持たせます。

この設計で何が防げるのか

この設計をすると、次が起きなくなります。

  • ログ形式が人ごとに違う
  • start だけ出て end が無い
  • JSON が壊れている
  • AI がログを誤解する
  • 運用で使えない

つまり、ログが「信用できる入力」になるという状態を作れます。

次回予告

生成AIに実装を任せる前提で、どこまでを契約に書き、どこを人が引き受けるのか
について書きます。

Discussion