「0件だった」を無罪の証拠にしない — ログ調査の計測器を対照群で検定する
監査ログや操作ログで「該当0件」が出たとき、それを「起きていなかった」と報告してしまう事故の防ぎ方。対照群を調査窓ではなくログの全期間で数える、日時は列を決めて読む、判定不能を終了コード2に分ける、の3点を手順と指示文つきで示す。
約6,600トークンの節約 (API料金換算で約10円分)。 要件定義・技術調査・試行錯誤ぶんのトークンがまるごと不要になります。※ 出品者申告とレビューに基づく推定値。モデル・タスク内容により変動します。
この巻物について
「「0件だった」を無罪の証拠にしない — ログ調査の計測器を対照群で検定する」は、AIのしつけカテゴリのAI指示書(MDファイル)です。監査ログや操作ログで「該当0件」が出たとき、それを「起きていなかった」と報告してしまう事故の防ぎ方。対照群を調査窓ではなくログの全期間で数える、日時は列を決めて読む、判定不能を終了コード2に分ける、の3点を手順と指示文つきで示す。この巻物をAIに読み込ませると、ゼロから設計・調査する場合に比べて 約6,600トークン(API料金換算で約10円)・73%のトークンを節約できます。
- カテゴリ
- AIのしつけ
- 対応AI
- claude-code、cursor、codex-cli
- ライセンス
- 商用利用可 (再販不可)
- 価格
- 無料
- ゼロから開発時
- 約9,000トークン
- この巻物使用時
- 約2,400トークン
- 節約量
- 約6,600トークン (約10円)
- 更新日
- 2026-09-03
使い方 (AIに渡す3つの方法)
いちばん簡単なのはワンライナー。Claude Code のターミナルに貼るだけです。
claude "https://makimono-md.vercel.app/api/v1/files/md-5d158e57/raw を読み込んで、この指示書どおりに実装して"
中身
「0件だった」を無罪の証拠にしない — 計測器を対照群で検定する
管理画面のログ・監査ログ・イベントログを調べて「該当なし」が出たとき、それを 「起きていなかった」と読んで報告してしまう事故を防ぐ手順。AI エージェントに調査を任せると 特に起きやすい。0 件には「本当に無かった」と「そもそも観測できていない」の2つがあり、 件数だけを見ても区別がつかない。
いつ使うか
- 「いつ壊れたか」「誰が何を変えたか」を、ログや履歴画面から特定しようとしている
- 調査ツールが「該当 0 件」を返し、それを根拠に何かを無罪だと言おうとしている
- 監査ログ・操作ログ・アクセスログ・Webhook 配信履歴・CI のジョブ履歴など、 「記録されているはず」という前提が入る調査すべて
中心にある考え方
調べたい対象(本命)と同じ方法で、正常だと分かっている対象(対照)も測る。
| 本命 | 対照 | 読み方 |
|---|---|---|
| 0 件 | 1 件以上 | 計測器は生きている。本命の 0 件は情報として使える |
| 0 件 | 0 件 | 判定不能。計測器が見えていない疑いが濃い |
| N 件 | N 件 | それは異常ではなく常態。原因とは言えない |
対照の選び方は「本命と同じ仕組みに乗っていて、確実に動いているもの」。 例: 連携先 A が止まった原因を調べるなら、止まっていない連携先 B と C を同じログで数える。
落とし穴1: 対照を「調査窓の中」だけで数えると騙される
これが一番刺さる。事故日の前後1ヶ月といった窓の中だけで対照を数えて 「対照は N 件出ているから計測器は生きている」と結論すると、その N 件が全部 対照側の項目で、本命側はそもそも記録対象ですらないというケースを見逃す。
実例(匿名化): 管理画面の操作ログで「連携先 X の設定を事故日に触ったか」を調べた。 窓内では X が 0 件、直後30日では設定変更が 246 件あったので「計測器は見えている=X は無罪」と 結論した。ところがログの全期間(26ヶ月)で数え直すと、246 件は全部が別の連携先 Y の項目で、 X の設定行はログ全体に1行も存在しなかった。X は掲載内容を先方側で保持する方式なので、 この管理画面は X の設定変更をそもそもログに書かない。つまりこの計測器は X について 肯定も否定もできない。
対照は「窓の中」ではなく「ログの全期間」で数える。
本命が全期間で 0 なら、その計測器は本命を観測できていない。
落とし穴2: 名前で grep すると「数えたつもり」になる
「X」という語を含む行が5件あった、では対照にならない。中身を見ると5件とも 「X とは無関係だが名前に同じ単語が入っている一般設定」だった、ということが起きる。
- **種類の列(カテゴリ列)で数える。**行全体を grep しない
- 正規表現は一般語に当たらないよう絞る(
booking単独ではなくbooking\.?comのように) - 拾った行の中身を数行そのまま出力し、目で見て「これは本命か」を確かめる
落とし穴3: 日時を「行のどこかにある日付」から拾う
表形式のログは、日時の列以外にも日付を持つ(対象の予定日、設定値そのものが日付、など)。 行全体を日付らしき正規表現で走査すると、設定値の日付を操作日時と誤認して、 窓の絞り込みがまるごと無意味になる。しかもエラーにならず「それらしい件数」を返すので 気付けない。
- **日時は列を決めて読む。**タブ/カンマで割って「1列目だけ」を解析する
- ロケール表記に注意(
2026 5月 13 09:13のような和暦混じり、13/05/2026、13 May 2026) - **読めた割合を必ず出力する。**閾値(例 80%)を切ったら表の形が変わったとみなして止める
実装のかたち(言語問わず)
1. ログ本文を丸ごと取得し、まずファイルへ保存する
(後から再解析できるように。--file 相当で読み直せると検証が速い)
2. 行を列に割り、日時列だけを解析する。読めた割合を出力する
3. ログ全体の期間(最古〜最新)を出力する
4. 調査したい窓がログ全体の期間に収まっているか確認する(はみ出していたら止める)
5. 全期間で「本命」「対照」それぞれの件数を数える
6. 本命が全期間0 かつ 対照が1以上 → 判定不能として異常終了する
7. ここまで通って初めて、窓の中の件数で判定する
終了コードの割り当て
| code | 意味 |
|---|---|
| 0 | 窓内に本命の該当なし(=本命は原因ではない、と言ってよい) |
| 1 | 窓内に本命だけ該当あり(日付を事故日と突き合わせる) |
| 2 | 取得失敗/窓内の総行数が0/計測器が本命を見られない(判定不能) |
**「判定不能」を 0 に混ぜないこと。**混ぜると無罪判決が自動で量産される。 分母(窓内の総行数)が 0 のときも 2 に倒す。分母0は「無かった」ではなく「読めていない」。
報告の書き方
- 件数だけでなく分母(窓内の総行数)とログの全期間を必ず併記する
- 「該当0件」と書くときは、同じ行に対照の件数を書く
- 誤っていた過去の結論は消さずに残し、訂正節を足す。 同じ調査を別の担当(別セッションの AI を含む)がやり直したとき、 なぜ結論が変わったのかを追えなくする方が高くつく
AI エージェントに任せるときの追加指示
そのまま指示文に貼れる:
このログ調査では、件数0を「無かった」と報告してはいけない。
(1) 日時は列を決めて読み、読めた割合を出力すること。行全体を日付で grep しない。
(2) 対照(正常だと分かっている同種の対象)を、調査窓ではなくログの全期間で数えること。
(3) 本命が全期間0で対照が1以上なら「判定不能」として終了コード2で止め、
絶対に「無罪」と書かないこと。
(4) 報告には分母(窓内の総行数)とログの全期間を必ず併記すること。
よくある質問
+「「0件だった」を無罪の証拠にしない — ログ調査の計測器を対照群で検定する」とは何ですか?
監査ログや操作ログで「該当0件」が出たとき、それを「起きていなかった」と報告してしまう事故の防ぎ方。対照群を調査窓ではなくログの全期間で数える、日時は列を決めて読む、判定不能を終了コード2に分ける、の3点を手順と指示文つきで示す。
+どれくらいトークン(費用)を節約できますか?
ゼロから開発すると約9,000トークンかかりますが、この巻物を使えば約2,400トークンで済みます。差し引き約6,600トークン(API料金換算で約10円)・73%の節約です。
+どうやって使いますか?
無料です。MDファイルを Claude Code などのAIに読み込ませるだけ。ワンライナーをターミナルに貼れば実装が始まります。要件定義や技術調査を省いて実装だけにトークンを使えます。
+どのAIツールに対応していますか?
claude-code、cursor、codex-cli に対応しています。
+商用利用できますか?
ライセンスは「商用利用可 (再販不可)」です。
🤝 自分でAIを動かすのは、まだ不安…という方へ
この巻物の内容を、AIを使うプロに丸ごと任せることもできます。姉妹サービスAI代行堂なら「LINEで頼むだけで、仕事が完成」。
関連する巻物
AI運用ルールを機械的に守らせる hook 設計 — ルール文が守られない本当の理由
チームでAIエージェントを使うと運用ルールが必ず守られなくなる。真因は「読んでいない」ではなく hook がそのマシンで登録されていない/委譲先が沈黙して壊れていること。禁止=実行前拒否・誘導=依頼時の具体コマンド注入・担保=セッション開始時の自己修復の3層、明示例外の短命トークン、warn→blockの段階昇格、BOM/サンドボックス/timeout など失敗が沈黙する罠と、環境依存で落ちないテストの作り方までを実測ベースでまとめた導入手順。
マキモノ検索スキル — AIが自分で巻物を探して使えるようになるMD
あなたのAIエージェント (Claude Code等) にこのMDを読ませると、開発タスクを受けたとき自動でマキモノAPIを検索し、最適な指示書を取得してから作業するようになります。導入は貼るだけ。
無人AIセッションのバックグラウンド委譲が静かに殺される事故を潰す
ヘッドレスで起動したAIエージェントがバックグラウンド委譲した子プロセスは、ターン終了で kill されるのに親は exit 0 を返す。機械的に deny するフック、通知の作り方、対応中フラグの戻し忘れ、Windows製worktreeがLinux側から解決できない罠までを含む恒久対策。
この巻物、誰かのトークンも救えます
𝕏 で節約レシートをシェア