検査ツールを作って回したら、検査ツールが先に間違えました
脚注ルールが守られているか検査ツールを作って回し、その結果を記録に残しました。その後、原稿を開いてみると間違っていたのは検査ツールでした。自動検査が見逃す部分に関する記録です。
検査ツールを作って回したら、検査ツールが先に間違えました
Pillar: P1 ビルダー探求ログ (Bトラック · 一人称) · ファネル: TOFU slug 候補:
blog-p1-checker-failed-first作成: 2026-07-27 · 分量: 約4,300字🔵 話者·route 確定 (2026-08-11 · §0-0-1-C 二重 route)
operating_track:INDEPENDENT_EDITORIAL— 本文一人称 11回 実測。会社話者に変えると文章が成立しない(自己誤り告白が論旨)。cta_route:FOUNDER_AI_READINESS— CTAを付けるので§0-0-1-Aに従い明示選択。entry:content_buildlog_checker← 旧content_evergreenは 22編が共有するバケットであり帰属不可だった。- 測定分離: 保存·プロフィール訪問·対話 = ビルダーログ学習指標(MKT OS 合算 ❌) / CTA通過
funnel_lead_submit_success= MKT OS リード(合算 ⭕)。
1. 原稿12編に検査ツールを回しました
私たちは外部に出す文章ごとに脚注3つを付けることに決めていました。参考資料と確認した日付、この文章に使わなかった数値、そして作成方法です。
2番目の項目が少し特異です。使ったことを明らかにするのではなく、使わなかったことを明らかにする項目です。確認できなかったために除外した数値が何であり、なぜ除外したのかを記します。「確認できなかったものは載せない」という言葉は誰でも言えますので、実際に除外したリストを見せる方が良いと考えました。
問題はこのルールを決めておきながら、原稿ごとに守られているか数えていなかった点でした。そこで検査ツールを一つ作りました。原稿フォルダを見渡して脚注3つがすべてあるかを表示する、非常に単純なものでした。
結果はこうでした。原稿12編中2編だけが3つを備えており、6編は1つもありませんでした。
私はこの数値をそのまま記録に残しました。ゲートを通過したと表示された原稿にも脚注がないと付け加えました。ゲートが脚注を捕まえていないという結論まで出しました。
2. 原稿を開いてみると脚注がありました
その結論を記してから、脚注を埋めるために原稿を一つずつ開きました。
3編には脚注がすでにすべてありました。
私の検査ツールが見つけられなかった理由はこうでした。一つは「この文章に使わなかった数値」の代わりに「この文章で使わなかったもの」と書かれていました。一つは「参考資料」ではなく「参考した資料」でした。スペース一つの違いでした。残りの一つは全く「数値関連告知」という別のタイトルを使っていました。
3編とも内容はルール通りでした。形式だけがそれぞれでした。
ゲートは私の仕事をしていました。間違っていたのは私が作った検査ツールでした。
この順序が私は少し痛かったです。検査ツールを回して、数値を得て、その数値で結論を出し、結論を記録に刻んだ後に原稿を開いたからです。原稿を先に開いていれば検査ツールのエラーは5分で明らかになったでしょう。
3. しかし原稿を開いてみると他のものが出てきました
脚注を埋めるために原稿を読み続けていたところ、検査ツールがそもそも見ることができなかったものを発見しました。
ある原稿の本文にこんな文がありました。
「○○研究結果が警告する:AI使用頻度が高いほど批判的思考が低下する。○○○名の研究で統計的に有意な逆相関関係が出た。」
機関名があり、サンプル数があり、統計的有意性まで言及されています。読む人の立場では確認された研究に見えます。
私たちには引用しても良い外部研究を別途記載したリストがあります。原文を実際に開いて数値と文脈まで対照したものだけを載せるリストです。そのリストでこの研究は**「機関名だけ知っている状態」**として分類されていました。引用してはいけない方でした。サンプル数もリストにない数字でした。
正直その瞬間、「出典:○○研究」とだけ書いて済ませたくなりました。脚注欄だけ埋めれば形式は整うからです。
その誘惑の前でリストを再び開いてみたところ、そこには「未確認」等級と書かれていました。脚注に出典を記すことと引用する資格を持つことは別のことだということを、今回また一度経験しました。脚注で覆うとむしろ確認されたように見せてしまいます。
文を丸ごと削除しました。その場所には私たちが直接観察したことを入れました。インタビュー要約本には人が言葉尻を濁した地点が残らないという話です。数値は入れず、除外した事実と理由をその文章の脚注に記しました。
同じ日に他の原稿2編では内部ストレージ名とツール名が本文にそのまま記載されていることも出てきました。これも検査ツールが見ることができる種類ではありませんでした。
4. 自動は「あるか」を見て、人は「資格があるか」を見ます
整理するとこうです。
| 自動検査が見たもの | 人が開いて初めて出たもの | |
|---|---|---|
| 脚注 | タイトル文字列があるか | 内容がルール通りか |
| 引用 | — | この出典を引用しても良いか |
| 識別子 | — | 外に出てはいけない名前か |
自動検査はあるかないかを見ます。速く、全数で見て、疲れません。
人が見るべきは資格があるかです。この出典が引用可能な等級か、この名前が外に出ても良いか、この数値が例示か測定値か。これは文字列検査で作れる判断ではありません。
そして今日私はその順序を間違えました。自動検査結果を事実として確定した後に人が確認する順序で行きました。反対であるべきでした。
5. だから何を変えたか
三つのことをしました。
第一に、間違って書いた結論を消さずに訂正履歴として残しました。「ゲートが脚注を捕まえていない」と書いていた場所に、それが間違っていたことと、なぜ間違っていたのかをそのまま付けました。消すと次にまた同じ方法で間違えます。
第二に、脚注を手直ししました。9編です。6編は脚注が全くなく新たに書き、3編は内容はルール通りなのにタイトルがそれぞれなので形式だけ整えました。スキャンした12編中発行候補11編が今や規格を整え、残り1編は発行しないことにした原稿なので対象から外しました。
埋めながら各原稿の「使わなかった数値」に実際に除外したものを記しました。例えばこんなものです。
- インタビュー10名中8名が拒否するという比率は実測ではなく説明用例示であること
- コーチングした人数は規模を示す表現であり、サンプルを定めて実施した分析ではないこと
- デザイン改善の成果を測定しなかったこと
第三項目が特にそうです。改善したという文章に改善数値がないと物足りません。だから入れたくなります。測定しなかったので入れることができず、しなかったという事実を記す方が正しいです。
第三に、検査ツールを修正しました。ただし今回は検査ツールが見えない領域が何かも一緒に記しました。引用資格と識別子露出は人が見るべきだと。
6. 似た話を聞きました
最近私たちと規模も分野も異なるチームの公開セッションを一つ聞きました。
長く残った部分は、結局到達した場所が似ていたということでした。自動化をどこまで押し進めても人が直接確認しなければならない場所が残るという話でした。
私はこれを私たちが自ら転がり落ちていきながら学んだと思いました。他の所でも似た場所に到達したことを知って、これが私たちの事情が特別で生じたルールではなかったのだと思いました。
(この段落は私が聞いた内容に関する記憶です。発言をそのまま移しておらず、会社名·発言者·時点·数値は記していません。理由は下記脚注②に記しました。)
7. 今日一つだけするなら
検査ツールを回しているなら、その検査ツールが一度でも間違えたことがあるか確認してみると良いでしょう。
方法は簡単です。検査ツールが「通過」としたもの一つだけ選んで直接開いてみると良いです。逆に「失敗」としたもの一つもです。10個を見る必要はありません。一つで検査ツールが何を見て何を見逃すかが明らかになります。
私は今日その順序を逆に行き、間違った結論を記録に一度残しました。
脚注
① 参考資料(確認日2026-07-27)
- 外部研究·統計引用なし。この文章の叙述は2026-07-27 自社原稿監査作業ログ(R0·1次経験)に基づきます。検査結果·訂正履歴·措置内容は私たちの発行キュードキュメントと実行元帳に残っています。
- 3節で言及した「引用しても良い外部研究リスト」は私たちの内部運用ルールです。外部に公開された標準ではありません。
② この文章に使わなかった数値
- 🔴 3節で除外した研究の機関名·サンプル数·研究年度 — その研究が私たちの引用リストで「未確認」等級であり、原稿から除外したものですが、この文章に再び記すと同じことを繰り返すことになるので○○で隠しました。原文を確保して対照したらその時に明らかにします。
- 🔴 6節公開セッションの会社名·発言者·発言原文、そして時点(具体的時期) — 自動文字変換記録しか持っておらず、原本をまだ対照できていません。原本未対照状態なので実名と引用文を載せませんでした。代わりに私が聞いたことに関する記憶という層でのみ記し、数値と時期は入れませんでした。
- 原稿編数 — 本文の編数はすべて私たちの原稿フォルダの実際のファイル数です。スキャン対象12編(発行候補11編 + 発行しないことにした1編)、検査ツールが完備と判定した2編、直接開いて追加で出た3編、手直しした9編(新規6編 + 形式だけ整えた3編)。ただしこれは私たちのフォルダ事情であり業界指標ではないので比率(%)に換算しませんでした。
- 🔴 この編数も一度間違えました。草案でタイトルは「11編」、本文は「12編」、5節は「11編」で分かれていました。数字を確定する前に再度数えろという文章が自分の数字を合わせていないことになり、発行前検証で指摘されて修正しました。
③ 作成方法
AIで草案を作成し、人が検証·編集しました。本文に記述した検査·訂正·除去作業は実際に行われたものであり、その記録が私たちの元帳に残っています。生成型画像·音声·映像は使用しませんでした。
CTA
外に出す文章に検査ルールを一つでも設けているなら、そのルールが実際に何を捕まえ何を見逃すかを2分診断で確認できます。お好きなだけお答えいただければ結構です。 https://www.star-t.io/ko/ai-readiness?entry=content_buildlog_checker&utm_source=blog&utm_medium=organic&utm_campaign=buildlog_2026&utm_content=blog-p1-checker-failed-first
Engagement
閲覧数とリアクションは内部コンテンツ運用指標として保存されます。
よくある質問
自動検査ツールを作ると脚注ルールが守られますか?
検査ツールは脚注が「あるか」だけを見ます。この文章では12編を通過させた検査ツールが実際には脚注の資格を見ておらず、原稿を直接開いてみて初めて間違っていたのが検査ツールだったと分かりました。自動検査は存在の有無を、人はそれが根拠として資格があるかを見ます。
脚注に何を記しますか?
参考資料と確認した日付、この文章に使わなかった数値、そして作成方法の3つです。2番目が特異で、使ったことではなく「使わなかったこと」を明らかにする項目です。確認できずに除外した数値が何であり、なぜ除外したのかを記します。
検査結果をどう扱うべきですか?
検査ツールが通過としたものを結果として記録する前に原稿を一度開いてみる順序をお勧めします。この文章のきっかけは正にその逆の順序でした — 結果を先に記し、後で原稿を開いたら記録が間違っていました。
STAR-T
STAR-T代表コンサルタント
ITサービス企画・デザイン専門家として、様々なスタートアップと企業の成功事例を研究・共有しています。
今すぐ実行へ
読んで終わらず、今すぐ実行できるサービスや相談へ。
インサイトで課題を理解したら、次のステップは実行構造を決めることです。関連サービスや無料ミーティングへすぐに進めます。