「公開募集 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 にも同じ内容を掲載しています。