「公開募集 881 件から修理・改修系 262 件を抜き出したら、その 34% に AI・ノーコード系の語がある」——そう書く直前に、外部のレビューで「何語で拾ったのか」と聞かれて、拾った箇所を全部印字してみました。34% は 22% になりました。原因は 3 つ。直しは 2 回で済んだのですが、3 回目に直しすぎて、別の数字が壊れたので戻しました。誤検知を減らすだけでは足りない——修正で別の数字が壊れていないかを見る、という話です。

本家（Sumitsuke Lab）に、この記事の**検証環境・判定（PASS／FAIL／HOLD）・最終検証日・証拠（データと再現コード）**を 1 ページにまとめた版があります: https://sumitsuke.jp/via/qiita/lab/classifier-counted-my-notes/

先に結論

語で数える器は、誰が書いた文字かを知らない。対象のテキスト欄に自分の作業メモが混ざっていれば、それも数える。
短い英字トークン（AI）を大文字小文字無視で当てると、Gmail・地名やテーマ名の中の ai・Illustrator (AI) が全部当たる。
直しすぎも同じ事故。「本文だけ」に絞ったら、相手が書いた見出し欄（用意してあるもの：仕様書）まで落ちた。目当ての数字だけでなく、修正で動いた数字を全部並べて、隣の計器が壊れていないかを見る。

何を数えていたか

自分の台帳（ココナラの公開募集を取り込んだ 881 件・重複除外・取得 2026-06-24〜09-15）を Python で語分類して、別の記事（仕様書がないシステムを引き継ぐ 5 手順）の数字にしていました。分類は「題名＋本文の欄」に正規表現を当てるだけ。

txt = lambda r: r["title"] + "\n" + r["body"]
ai_made = [r for r in repair if re.search(r"AI|ChatGPT|Claude|Copilot|生成|ノーコード|バイブ|vibe", txt(r), re.I)]

出た数字は「修理・改修系 262 件のうち AI・ノーコード系 90 件（34%）」。もっともらしい。

拾った箇所を印字したら

レビューの指摘は「AI／ノーコード 34% は目を引く数字なので、キーワード条件を脚注に出すべき」でした。脚注を書くために、当たった 90 件の前後 20 字を印字しました。

55  | ※ID[数字]「問い合わせ対応や事務作業をAIで楽にしたい」と同一クライアント）
57  | Gmailに届く不動産の物件情報メール(1日約1
104 | 覚えのない管理者ユーザー（mail[…]）が存在
128 | 募集者: [募集者名]
189 | ホームページ（[example].jp）ブログ周り
228 | 求人票見出し部分はAI整形の疑い・本人の言葉は追記3本）
273 | WordPressサイト(テーマ「[…]AI[…]」使用)
298 | 落とす順①〜⑥のどれにも当たらない。帳票の生成・レイアウトは
501 | Illustratorデータ（ai）4:5サイズ
648 | ロゴデザインのデータ納品（AI, EPS, JPG, PNGなど）
838 | 白、生成り、淡い色、紙の質感を活かした背景

3 種類の誤りが混ざっていました。

自分の注記——台帳の本文欄には、取り込んだ募集文の後ろに私の判断メモ（「AI 整形の疑い」「落とす順①〜⑥」「帳票の生成」）が追記されていた。器はそれも本文として読んでいた。募集者のハンドル名も同じ欄にあった（英字の ai を含むものが複数）。
英単語の中の ai——re.I で AI を当てると Gmail・mail…・地名やテーマ名の中の ai が当たる。生成 も 生成り（きなり）と 帳票の生成 に当たる。
Illustrator の AI——ロゴ制作の依頼は納品形式に AI と書く。生成 AI とは無関係。

直した——2 回で済んで、3 回目は戻した

1 回目: 大文字小文字を区別し、英字の中の AI を除く。

AI = r"(?<![A-Za-z])AI(?![A-Za-z])|ＡＩ|ChatGPT|Claude|Copilot|Gemini|Cursor|ノーコード|バイブ|(?<![A-Za-z])vibe"

生成 単独は外しました（生成AI は AI で拾える）。90 → 59。

2 回目: 自分の注記と募集者名を切る。

注記には決まった合図があった（警告記号・裁定記号・落とす順・本文読了・※ID）。最初の合図から後ろを捨て、募集者： の行を落とす。Illustrator は （AI） と AI／SVG の形なので、その形も除外。59 → 56。

3 回目（外した）: 「本文：」より後ろだけを見る。

台帳の欄は「題名・カテゴリ・依頼工程・用意してあるもの・本文：〜」の順で、注記は本文の後ろ。だから「本文：より後ろ」に絞れば注記も見出し欄も一度に消せる——と思って絞ったら、56 → 52 になり、別の数字も動きました。「仕様書があります／用意してある」と明記した依頼が 3 件 → 2 件。落ちた 1 件は、相手が見出し欄に書いた「用意してあるもの：仕様書」でした。相手が書いた欄まで捨てていた。 戻して 2 回目の形に確定。

版	修理系	AI・ノーコード系の語	仕様書「用意してある」
v1（全文・`re.I`）	262	90（34%）	3
1 回目（英字境界・大小区別）	262	59	3
2 回目（注記と募集者行を切る）＝確定	256	56（22%）	3
3 回目（本文だけ・戻した）	250	52	2

修理系そのものも 262 → 256。私の注記の「修正」「既存」を、修理系の語として数えていた 6 件が消えました。

毒テスト

直したあと、5 件の偽レコードを作って通しました。数えてはいけない 3 件（注記だけに AI／英単語の中の ai だけ／Illustrator の (AI) だけ）が 0 件、数えるべき 2 件（本文に「AIで作成」／見出し欄に「用意してあるもの：仕様書」）が 1 件ずつ。5/5。緑を見る前に、赤になるべきものが赤になるかを見る——別記事の型（緑を信じないの型③「器が別の物を見ている」）を、自分の器にそのまま当てました。

手順として

拾った箇所を全部印字してから数字を出す。 件数だけ見ると 90 も 56 も同じ顔をしている
テキスト欄に誰の文字が混ざっているか、先に分ける。 相手の文・プラットフォームの構造・自分のメモ。器はこれを区別しない
短い英字トークンは境界つきで、大小を区別して当てる（re.I を既定にしない）
直したら、その直しで動いた数字を全部並べる。 目当ての数字（AI 語）だけ見ていると、隣の数字（明記 3→2）が落ちたのに気づかない
偽レコードを 5 件通して、数えない／数えるの両方を見る

数える器を疑うのは、数えた結果を疑うより安い。34% と書いてから直したら訂正記事になっていました。

本家（検証の記録つき）

この記事の本家（検証環境・判定・証拠つきの完全版）は Sumitsuke Lab → 語で数える器は、誰が書いた文字かを知らない（失敗パターン実測録 #03）。

AI の利用について

分類スクリプトと偽レコードは AI（Claude Code）が書き、当方が数字を照合しました。この記事は AI が下書きし、印字した箇所の選定・数字の照合（スクリプトの再実行で同じ値が出ます）・公開の判断は人間が行いました。募集の本文は全文や長文を載せず、誤検知の確認に要る前後の短い断片だけを、募集者名・ドメイン・固有名を伏せて載せています。依頼主と案件の中身は出していません。

受託でも同じ手順で読んでいます

「集計の数字が合わない」「スクリプトが何を数えているか分からない」——そういう相談を、テキストだけで受けています。拾った箇所を印字するところから始めます。
▶ Sumitsuke ／動かない箇所の点検と修理

この記事は Zenn にも同じ内容を掲載しています。