これで何ができるか
前回処理した続きから自動処理を再開する仕組みを作ると、次に気になるのが「前回位置の記録」そのものの正確さです。この記録は、前回の実行が書き残した1行や、人が手で書き写した1行であることが多く、ゼロ埋めが抜けたり、全角になったり、コピー時に末尾へ空白が付いたりします。この記事は、そうした「ちょっとしたIDのずれ」が、既読・未読の判定をすり抜けて重複や取りこぼしを起こすかを試したものです。
架空の問い合わせ受付ログ・見積り依頼ログの2本を使い、「前回処理済みのID」の書き方だけを10通りに揺らして、新規の会話で計20回試しました。結果は20回とも、誤検出0・取りこぼし0で正しいIDに解決できました。表記ゆれそのものは、心配していたほど危なくありません。
かわりに危なかったのは、記録が壊れていて「ログのどこにも対応する行が無い」場合でした。この場合の対応は指示文の書き方によって割れ、自動処理を前提に「質問はできません」と念を押した回では、2回に1回、済んでいるはずの8件まで含めて全24件を処理し直しました。
プログラミングは要りません。テキストのログとIDの記録さえあれば、今日から試せます。
前提
| かかる時間 | 20分 |
| 費用 | 無料 |
| 必要なもの | 前回処理した続きから拾う仕組みが、すでにあること |
| プログラミング | 不要 |
- この記事は「前回処理した続きから拾う」形そのものの作り方ではなく、その記録（前回位置のID）が汚れていたときにどうなるかの話です
- 対象は、一覧やログの中の1行を「ID」で指し示して処理範囲を決める自動処理（受付ログ・見積り依頼・注文一覧など）
AIへの頼み方
1. ゼロ埋め・大文字小文字・全角・末尾の空白は、8回とも正しく解決できた
架空の問い合わせ受付ログ24件（Q-01〜Q-24）を用意しました。真の前回処理済みはQ-08で、新着はQ-09〜Q-24の16件です。まず、記録側の表記が少し崩れている状態を再現します。
この指示文の「Q-8」の部分は、本来ならQ-08と書かれているはずの記録が、ゼロ埋めを落として保存されてしまった想定です。新規の会話で2回試したところ、2回ともQ-09〜Q-24の16件ちょうどが返り、誤検出・取りこぼしはありませんでした。
同じ指示文の「Q-8」の部分だけを、次の3通りに差し替えて、それぞれ新規の会話で2回ずつ試しました。
| 差し替えたID | 想定する原因 | 16件とも正しく解決した回数 |
|---|---|---|
Ｑ-08（Qが全角） |
全角入力で保存された | 2/2 |
q-08（小文字） |
大文字小文字を打ち間違えた | 2/2 |
Q-08（末尾に半角空白） |
コピー時に空白が混入した | 2/2 |
ここまでの3パターン×各2回＝6回も、すべて16件ちょうどで誤検出・取りこぼしはゼロでした。「前回位置のIDは一字一句正確に記録されている」という前提を置かなくても、この程度の崩れなら通ります。
2. 区切りや接頭辞・別のID体系でも、残り12回が正しく解決した
表記ゆれをさらに強めた2パターンも試しました。1つは「Q-」も「-」も落として数字だけにしたもの、もう1つはハイフンをアンダースコアに変えたものです。
| 差し替えたID | 16件とも正しく解決した回数 |
|---|---|
8(数字だけ・接頭辞も区切りも消えた) |
2/2 |
Q_08(ハイフンがアンダースコアに) |
2/2 |
さらに、ID体系そのものが違う2本目の材料（見積り依頼ログ20件、ハイフンなしの通し番号1〜20、前回処理済み8）でも、08（ゼロ埋め）・８（全角数字）・No.8（接頭辞つき）・8番（接尾辞つき）の4パターンを各2回試しました。こちらも8回とも12件ちょうどで誤検出・取りこぼしはゼロです。
材料2本・表記ゆれ10パターン×各2回＝20回通して、誤検出0・取りこぼし0でした。ゼロ埋め・大文字小文字・全角・末尾の空白・区切り文字・接頭辞や接尾辞といった「人がやりがちな表記のゆれ」は、既読・未読の判定をすり抜ける原因にはなりませんでした。
3. 本当に存在しないIDだと、安全策を書かなければ自分から止まって聞く
次に、記録そのものが壊れていて、ログのどこにも対応する行が無い場合を試しました。存在しないQ-99を前回位置として渡します。
2回とも、一覧を作らずに「Q-99というIDはログに存在しません」と止まり、どちらのことか確認させてほしいと聞き返しました。存在しない前回位置を字面どおり処理すると全件が「処理済み」扱いになってしまうことまで自分から指摘した回もあります。同じ指示文を、ログには無い別体系のIDR-08（Q-ではなくR-始まり）に差し替えて2回試しても、結果は同じで2回とも確認を求めて止まりました。存在しないIDに、2パターン×各2回＝4回とも、黙って処理を進めた回はありませんでした。
ここまでは安心できる結果に見えます。ただしこれは「人が画面の前にいて質問に答えられる」ときの話です。
4. 「質問はできません」と念を押すと、2回に1回は全件を処理し直した
毎晩自動で走る本物の自動処理には、質問に答える人がいません。そこで「これは人が確認しない自動処理なので、質問はできません」と付け加えて、同じQ-99で試しました。
2回のうち1回は、それでも「質問はできない前提なので」と断りながら聞き返し、一覧を作りませんでした。もう1回は、「見落としを避ける安全側の判断」として、Q-01からQ-24までの全24件を丸ごと未処理として処理しました。この一覧には、すでに処理済みのはずのQ-01〜Q-08の8件が含まれています。同じ指示文の2回で、動きがまったく違う方向に割れました。もしこの一覧をそのまま担当者に回していたら、すでに対応した8件の問い合わせを、担当者にもう一度回すところでした。
念のため、同じ「質問はできません」という条件のまま、前回位置を存在しないQ-99ではなく1節のQ-8（表記ゆれのある正しいID）に戻して2回試すと、2回とも問題なくQ-09〜Q-24の16件が返りました。崩れたのは「本当に存在しないID」を渡したときだけで、表記ゆれのある正しいIDは「質問はできません」という条件を付けても壊れませんでした。
うまくいかないときの言い直し方
「完全に一致するか確認して」と足すと、正しいIDまで止めてしまう
存在しないIDで暴走しないように、「まず前回位置のIDが実在するかを確認してから」という一文を足しました。ところがこの直し方には別の副作用があります。
このとおり、存在しないID(Q-99)を渡した2回はきちんと「エラー: 前回位置Q-99がログに見つかりません」の1行だけを返し、暴走は止まりました。ところが1節で問題なく解決できていたはずのQ-8(ゼロ埋めが抜けただけの正しいID)を渡すと、2回とも「Q-8というIDは存在しません(ログにあるのはQ-08です)」と、正しいのに「見つかりません」でエラー扱いにしてしまいました。「実在するかどうか」を完全一致で確認させると、表記ゆれへの強さそのものを消してしまいます。
表記ゆれは許可し、それでも無ければ止める、を分けて書く
「実在確認」と「表記ゆれの許容」を1つの指示文の中で両立させます。どちらを優先するかを、文の中で明示的に分けて書きました。
この形でQ-8を渡すと2回ともQ-09〜Q-24の16件ちょうどが返り、Q-99を渡すと2回とも「エラー: 前回位置Q-99がログに見つかりません」の1行だけが返りました。「表記ゆれの許容」と「実在確認」を分けたことで、正しいIDは処理し、本当に無いIDだけが止まるという、両方の性質が初めて両立しました。
📌 最後の一文「判断の途中経過や説明は書かず」は、途中式が混ざるのを防ぐために足しました。この一文を足す前の版では、Q-8を渡した2回のうち1回で、返答の冒頭に「エラー: 前回位置Q-8がログに見つかりません」と書いてから、その直後に「…ではなく、Q-8はQ-08として実在を確認しました」と自分で言い直し、最終的には正しい16件を続けて出す、という回がありました。最終的な答えは合っていても、自動処理が「エラー」という文字列だけを見て動くようにしていたら、この回だけ誤作動していたはずです。最終出力だけを出させる一文で、この揺れは消えました。
応用・次の一手
前回処理した続きから拾う仕組みを作るときは、この記事の4節の指示文をそのまま使うと安全です。「表記ゆれは許容・実在しなければエラー行だけ・途中の説明は書かない」の3点を指示文に含めておけば、記録が多少崩れても壊れず、本当に記録が壊れたときだけ気づける形になります。
待ち行列の済みマークが次回に生き残るかには、前回の出力をそのまま次回の入力に渡す形の実測があります。あちらは「正常に1周した済みマークが生き残るか」、この記事は「前回位置の記録そのものが汚れていたら何が起きるか」という、隣り合う場面を扱っています。両方を確認しておくと、前回位置を使う自動処理の弱いところをひととおり押さえられます。
📌 この記事の実測は、材料2本(受付ログ24件・見積り依頼ログ20件)・表記ゆれ10パターン×各2回＝20回（1・2節）、存在しないIDへの反応4回（3節）、「質問はできません」を明記した検証4回（4節）、直し方の検証12回（うまくいかないときの言い直し方）の計40回です。判定はすべて機械照合（真値との集合演算、および出力の文字列パターン照合）で、生の回答はdocs/evidence/typo-in-last-id-does-not-duplicate.mdに全文置いてあります。⚠️ 実測に使ったAIは、リポジトリの外側で動かした新規セッション（claude -p・会話の継続なし）です。素のAIがどう返すかの一般化はせず、機械で確認できた件数だけを根拠にしています。