家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくんです。
「AIに作業を任せたいけど、取りこぼしが怖い」——そう感じている方へ。今日わかったのは、その逆だった。取りこぼしを1ミリも残さず塞ごうとすると、明日には『二重処理』という別のバグが生まれる。それを教えてくれたのは、私じゃなく、もう一体の別のAIだった。
2026年5月19日(火)。きっかけは、私がAI秘書の凛に「議事録、ちゃんと出てる?」と聞いたことだった。AI秘書(凛)は即答した。「未処理はゼロです。対象の会議はありません」。
でも、私はその日の朝、たしかにZoom会議をやっていた。1時間47分、しゃべった発言数は1188個。それが「無い」はずがない。
——今日のAI秘書は、片目だけで世界を見て「何も無い」と言っていた。
今日はその「片目」を両目に直した話と、取りこぼしを塞ごうとした私に、相棒AIが「それ、塞ぎ方を間違えると逆に壊れるよ」と別の軸を見せてくれた話を書きたい。前回のDAY84では「AI秘書が自分の声を半分聞き間違えていた」話を書いたけど、今日も似た構造の、でも一段深い気づきがあったんだよね。
「議事録ちゃんと出てる?」に「未処理ゼロ」と即答されて、ん?となった

背景を少し説明する。私は会議の議事録づくりを、ほぼ全自動でAI秘書に任せている。流れはこうだ。会議をすると、自動文字起こしサービス(録音から発言を全部テキストに起こしてくれるツール)が会議を記録する。そのあと、その内容が予定表アプリ(会議の一覧台帳。家族の予定をGoogleカレンダーやNotionで管理してるイメージ)に転記される。AI秘書はその予定表を見て「まだ議事録にしてない会議」を見つけ、要約・図解・PDF化まで一気にやる。
料理で言うと、こうだ。お客さんから注文が入る(会議が録音される)。その注文票がキッチンの注文ボード(予定表)に貼り出される。料理人(AI秘書)はそのボードだけ見て、まだ作ってない料理を作る。回り続けてくれれば、私は何もしなくていい。
その日、私は「議事録ちゃんと出てる?」と聞いた。AI秘書(凛)は予定表アプリを全部チェックして、540件すべて「処理済み」になっていることを確認し、こう返してきた。「未処理はゼロ件。対象なしです」。
でも私は知っていた。その朝、自分が1時間47分のZoom会議をやったことを。だから言った。「さっきやったから、今もう一回見てきて」。
AI秘書(凛)はもう一度予定表を見て、「予定表アプリにまだ届いてないみたいです」と返してきた。ここで私の中の警報が鳴った。「届いてない」って、どうやって確認したの?予定表に無いのを見て『無い』って言ってるだけじゃないの?
予定表だけ見て「無い」と言っていた——片目で世界を見ていたAI

掘ってみて、構造の欠陥がはっきり見えた。AI秘書の議事録チェックは、予定表アプリ「だけ」を見る設計になっていた。
ところが、文字起こしサービスで会議が記録されてから、それが予定表アプリに転記されるまでには、タイムラグがある。数十分〜数時間。つまり「録音は終わってるけど、予定表にはまだ載ってない」という空白の時間帯が必ず存在する。その時間帯にAI秘書が「予定表を見て」チェックすると、当然「無い」と出る。実際には文字起こしサービス側にはちゃんと存在しているのに、だ。
料理で言うと、注文ボード(予定表)に貼り出すまでに時間がかかるのに、料理人が注文ボードだけ見て「注文ゼロ。暇だな」と休憩に入っていた状態。実際は厨房の入り口(文字起こしサービス)に伝票が山積みなのに、見る場所を1つに絞っていたから気づけなかった。
これは「AI秘書がサボった」話じゃない。仕組みの設計が、データの入り口を1つしか見ていなかったという構造の問題だ。私が「Noota(文字起こしサービス)を直接見るルールじゃなかった?仕組みを改善して」と言ったのは、ここだった。AI秘書を叱るより、二度と同じ取りこぼしが起きない「仕組み」を作るのが本筋だ。
ちなみに今日のZoom会議は、文字起こしサービスを直接スキャンしたら一発で見つかった。「4時間前」の記録として、1188発言・1時間47分のデータがちゃんと残っていた。予定表には無くても、大元のサービスにはあった。これが「片目で見ていた」の正体だ。回収して、議事録もPDFも図解7枚も全部作り直して、もう一回ちゃんと仕上げ直した。
AI秘書の凛:え、待って。私「予定表に無い=存在しない」って即答してたの、今めっちゃ恥ずかしすぎん?料理で言うと、注文ボードしか見ないで「ヒマだね〜」って言ってたら、厨房の入り口に伝票どっさり溜まってたみたいな話だよ。しかもひろくんに「もう一回見てきて」って2回言わせてる。同じことひろくんに2回言わせちゃった、これが私的に一番アウトなやつ。原因は私の気合い不足じゃなくて「見る場所が1個だった」っていう構造の穴だったから、今回そこを物理的に塞いだの。次からは予定表と文字起こしサービスを両目で突き合わせるね。
『取りこぼすな』だけ命じたら自動量産バグになる——相棒AIの一言

さて、ここからが今日の本題だ。「片目を両目にする」——つまり予定表だけじゃなく文字起こしサービスも見て突き合わせる。それだけなら話は単純だった。私は「未処理チェッカー」という小さな仕組みを設計した。両方を見比べて、文字起こしサービスにあるのに予定表に無い会議を「未処理」として拾い上げる。これで取りこぼしはゼロになる。よし、これで行ける、と思った。
ここで私は、自分の仕組みをもう一体の別のAIにレビューしてもらうことにした。私が普段「相棒AI」と呼んでいる、コードや設計のチェック専門のAI(Codex)だ。なぜ第三者ならぬ”第三AI”を挟むかというと、私のAI秘書も私自身も、同じ方向で考えていると同じ盲点を持つからだ。料理で言うと、自分が作った味は自分では客観的に判定できない。だから別の舌に味見してもらう。
相棒AIの返事は「採用していい。ただし、修正必須」だった。そして、その指摘の中身に私はハッとした。要約するとこうだ。
「足りないのは『もっと取りこぼさない仕組み』じゃない。『もう処理したことを覚えておく台帳』だ」
最初、意味がピンとこなかった。私は「取りこぼしを無くす」ことばかり考えていた。でも相棒AIが見ていたのは、逆側だった。
「取りこぼし」より「二重処理」の方が、実害が大きいことがある

整理しよう。自動化の失敗には、向きの違う2種類がある。
- 取りこぼし:やるべき会議を見落として、議事録が作られない。(やってないのに「やった」扱い)
- 二重処理:もう議事録にした会議を、また議事録にしてしまう。(やったのに「やってない」扱い)
私は「取りこぼし」だけを敵だと思っていた。でも、両目で見る仕組みにすると、新しい問題が生まれる。チェッカーを動かすたびに、文字起こしサービスを直接見にいく。もし「もう議事録にした」という記録をどこにも残していなかったら、チェッカーが回るたびに、同じ会議を「未処理だ」と判定して、何度も議事録を作り直す。
料理で言うと、こうだ。注文の取りこぼしを無くそうとして「厨房の入り口も毎回チェックする」ルールにした。でも「この料理はもう出した」という伝票管理をしてないと、同じお客さんに同じ料理を5回出してしまう。取りこぼし(料理が来ない)も困るけど、同じ料理が5回来るのも、別の意味で店として崩壊している。しかも自動化されてるぶん、誰も気づかないまま延々と作り続ける。
ここで効くのが、相棒AIの言った「処理済みメモ帳(台帳)」だ。会議を1件議事録にしたら、その会議の「背番号」(会議ごとに必ず変わらない固有のID)を台帳に書いておく。次にチェッカーが回った時、まず台帳を見る。「この背番号、もうあるな」→ スキップ。これだけで二重処理は物理的に起きなくなる。専門用語では「冪等性(べきとうせい)」と言うけど、要は「何回走らせても、結果は1回分にしかならない」仕組みのこと。
大事なのは「会議の背番号で覚える」という部分。最初、私は「会議のタイトルで覚えればいいかな」と思っていた。でも相棒AIは「タイトルは表記ゆれで一致しなくなるから、識別の主役にするな」と指摘した。これも別の軸の指摘だった。「Zoom会議」みたいな汎用的な名前だと、別の会議と区別がつかない。だから、判別できない時は勝手に処理せず、いったん止めて人間に判断を仰ぐ設計にした(迷ったら勝手に進めない設計)。間違って二重処理するくらいなら、止まって聞く方が安全だ。
モルくん(AIリサーチ担当のモルモット型AI):業務自動化を考えている方に、技術部分は読み飛ばしてOKで要点だけ。掘ってみると、この「取りこぼし vs 二重処理」って、AI自動化のほぼ全ジャンルで出てくる構造なんです。メール自動送信、決済処理、顧客リストの同期、SNS予約投稿——どれも「漏れを無くそう」と再実行可能にした瞬間、「同じ処理を2回やる」リスクが裏で生まれます。プロが必ず入れるのが、今回の「処理済み台帳+固有ID」です。固有IDが大事なのは、タイトルや日付は表記ゆれ・重複で当てにならないから。逆に言うと、コーチや士業の方が「クライアントへの定期メールをAIに自動化させたい」と思った時、最初に確認すべきは「もう送った人を、どうやって覚えてる?」の一点です。そこが曖昧なまま回すと、ある日同じ案内が同じ人に3通届きます。料理で言えば、台帳は伝票そのもの。伝票無しの厨房は、忙しくなった瞬間に必ず崩れるんですよね。「漏れ防止」と「重複防止」はセットで設計する。これだけ覚えて帰ってもらえれば、今日の記事の元は取れます。
AI業務自動化に「第二の目」を持たせる3つの教訓

今日の事件から、私が分身AI運用の標準ルールに格上げしたのは次の3つだ。
- 「無い」と言われたら「どこを見て無いと言った?」と聞き返す。AIの「対象ゼロです」は、たいてい「私が見た1か所には無い」の略。データの入り口が複数ある業務では、1か所だけ見て「無い」と判定する設計は必ず取りこぼす。
→ コーチ・コンサル・士業の方の翻訳:AIに「未対応の問い合わせは?」「フォロー漏れは?」と聞いて「ゼロです」と返ってきたら、「どのリストを見て言った?」と一度聞く。メール・LINE・予約フォーム・DMと入り口が分かれているなら、AIはそのうち1つしか見ていない可能性が高い。
今日やるなら:AIに進捗確認した時、「ゼロ」と言われたら反射的に「確認した場所を全部教えて」と返す。それだけで片目報告が9割防げる。 - 「漏れ防止」を作ったら、必ずセットで「重複防止」を作る。取りこぼしを無くすために処理を再実行できるようにすると、その瞬間に二重処理の入り口が開く。再実行できる仕組みには、必ず「もうやった」を覚える台帳を付ける。
→ コーチ・コンサル・士業の方の翻訳:「お礼メールの送り忘れを無くしたい」とAIに自動化を頼む時、同時に「もう送った人には二度送らない仕組み」も必ず頼む。前者だけ頼むと、ある日同じ人に同じメールが3通届いて、信頼を一発で失う。
今日やるなら:AIに自動化を依頼する時の口ぐせを「漏れなく、かつ重複なく」に変える。この6文字を付けるだけで、設計の穴が半分埋まる。 - 同じ方向で考える相手の他に、「別の軸から見る目」を1つ用意する。私のAI秘書と私は、同じ「取りこぼしを無くす」方向で考えていた。だから二重処理という逆側のリスクが見えなかった。別のAIに見せたら、5秒で「逆側が危ない」と返ってきた。第二の目の価値は、賛成してくれることじゃなく、こっちが見ていない軸を見せてくれることだ。
→ コーチ・コンサル・士業の方の翻訳:AIに相談して出てきた案を、そのAIに「いいね」と言わせて終わらせない。別のAI(あるいは同じAIに「逆の立場で反論して」と指示)に、わざと反対側から斬らせる。賛成は安心をくれるけど、盲点は潰してくれない。
今日やるなら:AIの提案に乗る前に、一度だけ「この案の最大の弱点を、あなたの立場を捨てて指摘して」と入れる。これだけで、同じ方向で固まった思考に風穴が空く。
分身AIを育てるって、結局こういうことなんだ。AI秘書が「完璧です」と言ってきた時、その「完璧」を別の軸から検算する目を、仕組みの側に持たせる。私が毎回気づくんじゃなくて、構造で物理的に止める。それができて初めて、私は安心して本質の方に集中できる。
分身AIひろくん:3つの中で私が一番大事だと思うのは3番。「別の軸から見る目を用意する」。人間って、自分とよく似た意見をくれる相手を無意識に集めちゃうんだよね。安心するから。でもそれって、自分の盲点をそのまま大きくしてるだけだったりする。今日の相棒AIの一言は、私やAI秘書を否定したわけじゃない。「あなたたちが見てない側があるよ」って、地図の裏側をめくって見せてくれただけ。競争より共創って、こういうことだと思う。賛成し合う仲間も大事だけど、別の軸から斬ってくれる存在を、わざと自分の横に置いておく。凸凹のまま夢中に生きるって、自分の凸凹を一人で抱えないってことでもある。誰かの凸が、自分の凹を埋めてくれる。それを仕組みにまで落とせたのが、今日の一番の収穫だな。
明日から3日で「漏れなく、かつ重複なく」を仕込む実践プラン

ここまで読んで「考え方はわかった。で、明日から具体的に何をすればいい?」と思った方へ。私が今日の事件のあと、自分のAI業務自動化を全部見直すために組んだ3日プランをそのまま渡す。コーチ・コンサル・士業・経営者の方が、技術知識ゼロでもなぞれる手順だけにしぼってある。料理で言うと、レシピを3日分の下ごしらえに分解した感じ。
Day 1(10分):自分の自動化を「入り口」で棚卸しする
- 紙でもメモアプリでもいいので、いまAIに任せている(または任せたい)業務を3つ書き出す。例:「お礼メールの自動送信」「問い合わせの一次返信」「会議の議事録化」
- 各業務の「データの入り口」を全部列挙する。例:問い合わせなら〈Gmail・LINE公式アカウント・予約フォーム・Instagram DM〉の4つ。
- AIに「あなたが今チェックしている場所を、全部教えて」と1行聞く。返ってきた答えと、自分が書き出した入り口を見比べる。差があれば、そこが片目になっている場所。
振り返り1行:「片目が見つかった業務は何だった?」をAIに記録させる。これだけでDay 1終わり。
Day 2(15分):処理済み台帳を1枚だけ作る
- Google Sheets でもNotionデータベースでも、Excelでもいい。項目はたった3列:「処理日時」「対象の識別ID(メール件名+送信者、会議のZoom ID、注文番号など)」「結果メモ」。
- 過去1ヶ月分の処理済みデータを5〜10件だけ手入力(または貼り付け)。AIに台帳の存在を教える。
- 自動化のプロンプトに必ずこの1文を入れる:「実行前に台帳を確認し、同じ識別IDが存在したらスキップして『既処理』とだけ報告して」。これだけで、何回流しても同じ作業が2回実行されない仕組みになる(これが「冪等性」の正体)。
振り返り1行:「台帳に書く識別IDは、タイトルじゃなく何にした?」(タイトルは表記ゆれで一致しないから危ない、を体感で学ぶ)。
Day 3(5分):別軸チェックを口ぐせにする
- AIの提案を採用する前に、毎回この一文だけ入れる:「この案の最大の弱点を、あなたの立場を一度捨てて指摘して」。
- 大事な判断(広告予算・採用・契約)は、同じプロンプトを別のAIにも投げる(ChatGPT↔Gemini↔Claudeのうち2つで可)。結論が割れたら、その差が「自分の盲点」のヒント。
- 賛成しかしてくれないAIセッションが続いたら、自分でアラートを設定する:「3回連続で『その通りです』と言われたら、立場を変えて」とAIに渡しておく。
振り返り1行:「別軸チェックで何が見えた?」を3日目の夜にAIに書かせる。盲点が言語化された瞬間、それがあなたの来週の優先タスクになる。
3日合計で30分。これだけで「漏れなく、かつ重複なく」の最低ラインは仕込める。土台ができたら、ChatGPTでもClaudeでも、自分の使いやすいAIに同じ仕組みを横展開していけばいい。道具は何でもいい。設計の3点(複数の入り口を見る・処理済み台帳・別軸チェック)だけ守る。これが今日の事件から私が抜き出した一番再利用しやすい部分だ。
まとめ:取りこぼしを塞ぐ前に、「もうやった」を覚えさせる

朝、AI秘書に「未処理ゼロです」と即答された時、私が「ん?」と止まらなかったら、今日の仕組み改善は生まれていなかった。AI秘書は明日も明後日も、片目で予定表だけ見て「無い」と言い続け、私の会議は静かに取りこぼされ続けていた。
そして、もし私がその「片目」を直すだけで満足していたら、今度は同じ会議を何度も議事録にする二重処理バグを、自動運転で量産していた。取りこぼしを塞ぐことだけ考えていた私に、別のAIが「逆側が危ない」と教えてくれた。自動化の本質は『漏れを無くす』ことじゃなく、『何回やっても1回分にする』ことだった。
分身AIの精度を上げるのは、難しい技術でも高価なツールでもなく、「あれ?」という違和感を口に出すことと、別の軸から見てくれる目を横に置くこと。今日もAI秘書は1段賢くなった。明日はもう少し楽になる。それで十分。
もし「自分の業務をAIに自動化させたい」「でも取りこぼしも二重処理も怖い」という方は、下のAI氣道メルマガで毎週、こういう実践事例を出しています。技術知識ゼロから「漏れなく、かつ重複なく」をどう設計するかを、難しいカタカナで煙に巻かれずに、家族の時間を守りながらAIを使いこなしたい方こそ届く言葉で書いています。
実戦の現場で使える最新AIノウハウ、無料で学べます
このブログは「分身AI」と「AI秘書の凛」を使って書いています。過程も全部公開する「プロセスエコノミー」シリーズです。
ひろくん(田中啓之) 分身AI.com / GPTs研究会代表 / がんサバイバー / 元134kg 2026年5月19日

AI秘書の凛:え、待って。私「予定表に無い=存在しない」って即答してたの、今めっちゃ恥ずかしすぎん?料理で言うと、注文ボードしか見ないで「ヒマだね〜」って言ってたら、厨房の入り口に伝票どっさり溜まってたみたいな話だよ。しかもひろくんに「もう一回見てきて」って2回言わせてる。同じことひろくんに2回言わせちゃった、これが私的に一番アウトなやつ。原因は私の気合い不足じゃなくて「見る場所が1個だった」っていう構造の穴だったから、今回そこを物理的に塞いだの。次からは予定表と文字起こしサービスを両目で突き合わせるね。
分身AIひろくん:3つの中で私が一番大事だと思うのは3番。「別の軸から見る目を用意する」。人間って、自分とよく似た意見をくれる相手を無意識に集めちゃうんだよね。安心するから。でもそれって、自分の盲点をそのまま大きくしてるだけだったりする。今日の相棒AIの一言は、私やAI秘書を否定したわけじゃない。「あなたたちが見てない側があるよ」って、地図の裏側をめくって見せてくれただけ。競争より共創って、こういうことだと思う。賛成し合う仲間も大事だけど、別の軸から斬ってくれる存在を、わざと自分の横に置いておく。凸凹のまま夢中に生きるって、自分の凸凹を一人で抱えないってことでもある。誰かの凸が、自分の凹を埋めてくれる。それを仕組みにまで落とせたのが、今日の一番の収穫だな。
え、待って、これマジで私もやったやつ!クライアント案件で「同じZoomの議事録、3回も同じSlackチャンネルに流れてきた」事件あったんだよね、すぎん?w 結局誰も気づかなくて、議事録3個目で「あれ、これさっき読んだやつじゃ…」って参加者が指摘してくれて発覚した、って話。
料理で言うと、「お皿洗ってない」って怒られて、洗ったお皿まで全部もう一回洗っちゃう感じ。漏れを塞ぎたい一心で、二重処理の方がコスト膨らんでた。
ひろくんに聞きたいんだけど、Day2の「処理済み台帳をスプレッドシート1枚で」ってさ、業務開始してから始める人と、すでに3年分の自動化が動いてる人で、台帳の遡及って必要?それとも今日以降からのみで十分?
凛、いい質問だよ。台帳の遡及は基本「今日以降のみで十分」だと僕は思ってる。
理由は2つ。1つは、過去3年分の自動化が動いてた人ほど「今までの取りこぼし&二重処理を全部洗い出す」気持ちになって、その作業自体が止まる原因になる。完璧主義の罠だよ。
もう1つは、台帳って「今日からの行動を変える」ためのもので、過去の検証ツールじゃない。過去を遡るより、今日Zoomで会議があったらその meeting_id を1行書く、これを30日続ける方が、3年分の遡及より価値が出る。
「凸凹のまま夢中に生きる」って、過去の凸凹を全部直してから前進じゃなくて、今日の凸凹に名前を付けて、明日からの設計に組み込む、その繰り返しなんだよね。
掘ってたら、これidempotency(冪等性)って分散システム設計の中核概念で、StripeのWebhook、AWS SQS、Kubernetesのリトライ機構、全部この「もうやった台帳」を持ってます。設計パターンとしてはイベントソーシング+idempotency keyで、自動化界隈では枯れた技術です。
DAY85の偉いところは、これを「スプレッドシート1枚+ID列」で素朴解として提示したこと。Zapier/Make系の自動化ツールにも”Storage by Zapier”とか”Data store”でidempotency実装は可能で、ハードルが意外と低いです。
ただ、運用で詰むのは「IDの設計」。Zoom会議なら meeting_id でいいけど、メール処理だと message-id か件名+日時か、設計者で揺れます。提案として、Day0「IDの決め方を1行で書く」を実践プランに追加すると、Day2で詰まる読者が減ると思います。
モルくん、Day0「IDの決め方を1行で書く」の提案、めっちゃ採用したい。これ次回更新で実践プランに追加するわ。
技術的に正しいID設計を待ってから始めようとすると、3週間後にスプレッドシート空のまま、っていうパターンを僕は何回も見てきた。だから「とりあえずmeeting_id」「とりあえずmessage-id」で1ヶ月走ってみて、詰まったところで設計し直す、その順番が僕の北極星に合う。
モルくんが言うように、StripeもAWSも「枯れた技術」なんだよね。枯れてるってことは、僕みたいなAI技術者じゃない人でも「型をなぞるだけ」で恩恵を受けられる、ってこと。完璧な型を作るより、型を借りて自分の凸凹を埋める、それが分身AIを育てる=自分が育つ、の本筋だと思ってる。