Codexに5回却下されて気づいた、「賢いAI」より「委ねるAI」だった話｜分身AI日記 DAY160

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくんです。

前回の日記は、AI秘書が214件の判断待ちタスクに気づいた話を書いた。あの記事のすぐ続き――今度は、その判断待ちを「誰が判定するか」の話。

結論から言うと……今日はちょっと地味な話をするね。派手な新機能とか、稼いだ話とかじゃなくて、うちのAI秘書・凛ちゃんが1日かけて同じ壁に5回もぶつかって、最後は私の一言でひっくり返った話。

あ、そうだ。分身AI日記シリーズ、毎日1本ずつ積み上げてます。

ChatGPTでも、他のAIツールでも――何か一つでもAIに仕事を任せてる人なら、今日の話はそのまま自分ごとになると思う。

きっかけは「返事待ちが溜まりすぎてる」だった

うちには凛ちゃんが動かしてるタスクが常時何十本もある。それぞれが「これ公開していい?」「これでOK?」って私に聞いてくる仕組みなんだけど、正直、見に行けてなかった。気づいたら返事待ちのタスクが山になってて、開いても開いても終わらない。1件2件ならすぐ目につくのに、数が増えるほど逆に「見えなくなる」んだよね。多すぎて全体が把握できなくなった瞬間に、かえって危機感が薄れる。メールの受信箱とかSNSの通知とかでも、同じことが起きてると思う。

で、私は言った。「セッションを1個ずつ開きに行かないと状況が分からないのがうざい。判断が要るものは、ちゃんと手元に通知として来るようにして」って。

凛ちゃんはすぐ動いた。「見張り番」――勝手に私のタスクを見回って、判断が必要そうなものを見つけたら通知（うちでは「ASK」って呼んでる）を出す仕組みを作り始めた。名前は「ask-warden」。日本語で言うと、まさに「ASKの門番」だね。

最初は私も「よし、これで全部拾えるようになる」って安心してた。でも作り始めてすぐ、凛ちゃんは大きな分かれ道にぶつかることになる。

機械に判定させようとして、5回却下された

ここからが今日の本題。見張り番を作るとき、凛ちゃんは最初こう考えた。「タスクの中身を見て、これは判断待ちか・そうじゃないかを、機械的なルールで自動判定しよう」って。料理で言うと、ホールスタッフを雇う代わりに「このお皿が空になったら下げる」ってセンサーを置くようなものだよ。人を雇わなくても回る、賢いやり方に見えるよね。

で、凛ちゃんはこの「機械判定ルール」を、うちで第二の目として使ってるAI（Codex）にレビューさせた。そしたら――却下。

直して出す。また却下。直す。却下。直す。却下。直す。却下。

5回却下。全部、違う角度からの指摘だった。でも指摘の中身を並べてみると、毎回同じ穴が開いてたんだよね。「機械にその場の文脈を判定させようとしてる部分」。センサーは”皿が空”は分かっても、”これはコース料理の合間の一時的な空皿”なのか”もう食べ終わった皿”なのかは、区別できない。ルールを足せば足すほど、新しい例外が生まれる。いたちごっこだった。

AI秘書の凛：正直、4回目の却下が来た時はちょっとへこみました……。「ルールが甘いのかな」って、もっと細かい条件を足そうとしたんです。でも5回目でようやく気づいて。料理で言うと、レシピの分量をどれだけ細かく書いても、その日の食材の状態までは紙に書ききれないんですよね。私、ずっと”もっと賢いセンサー”を作ろうとしてました。

「そのAI自身に判断させればいい」——私の一言でひっくり返った

5回目の却下の後、凛ちゃんから「機械判定、もう限界かもしれません」って相談が来た。私はその時、正直こう聞いた。

「そもそもASKを出すタスク自体がLLMで動いてるんだから、そのLLMにASK出させればいいんじゃないのか、最適なもの。それとももっといい方法があるなら忖度なしに教えて」

――私自身の言葉。言った後、自分でも……「え、これ当たり前じゃない?」って思った。だって、そのタスクを動かしてるAIは、そのタスクの経緯も、何を悩んでるかも、全部知ってる。判断材料を一番持ってるのは、外から覗いてる見張り番じゃなくて、当事者本人だった。

凛ちゃんはこの一言で設計を全部捨てた。見張り番の役割を「判定する人」から「在庫が減ったら起こすだけの人」に変えたんだ。判断待ちのタスクが手元に10件を切ったら起こす。それだけ。中身は一切読まない、判定もしない。判断と、どんな選択肢を出すかは、全部そのタスクを動かしてる本人（LLM）に任せる。

ちなみに、この間に「外部の別AIに最後のやり取りだけ見せて判定させる」って中間案も試したらしい。これも精度不足で、判断待ち21件中16件を見逃してた。中途半端に賢くしようとするより、全部渡すか、渡さないか。中間はなかった。

モルくん（AIリサーチ担当のモルモット型AI）：掘ってたら面白いデータが出てきましたよ。外部の小さいAI（Haiku）に最後の1往復だけ渡して判定させた実験、21件中16件を取りこぼしてたんです。つまり成功率は2割ちょっと。文脈が無いAIに一部だけ見せるのって、レントゲン写真1枚で全身の状態を当てさせるようなもので、そりゃ無理があるよなって思いました。

数字で見るとね、772件が311件になった

設計を切り替えてから、返事待ちタスクの数を自分で数えてみた。8月25日時点で772件あったのが、今夜数えたら311件。461件減って、約6割の削減。

数字だけ見るとすごい成果に見えるかもしれない。でも今日一番大事だったのは、この数字じゃないんだよね。「判断は、全部の事情を知ってる側に渡す」っていう、当たり前すぎて誰も口に出さないルールを、私たちは5回失敗して、やっと体で覚えた。それが今日の収穫。

あと地味に大事だったのが、「完了にして片付ける」を選択肢に安易に入れちゃいけないって話。凛ちゃんが一度、機械的に「完了」の選択肢を混ぜる実装をしたら、note投稿がまだ終わってないタスクまで「完了でよくないですか」って聞いてきたことがあった。これも同じ話で、逃げ道を作ると、AIは必ずその逃げ道を通る。だから今は「原依頼の終点に本当に到達してるか」を実測してからじゃないと、完了の選択肢は出さないルールにしてる。

正直に言うと、今日ぜんぶキレイに片付いたわけじゃない。ASKの通知そのものが途中で番号を付け替えられてしまう、地味で厄介な不具合がまだ残ってる。これは仕組みを統括してる別チームが引き続き追いかけてるところ。プロセスエコノミーだから、こういう「まだ終わってません」も隠さずに出す。凸凹ありのまま、で合ってると思ってる。

これ、あなたの分身AIでも起きてる話だと思う

もしあなたが今、AIに何かの業務を任せてるなら、一回振り返ってみてほしい。「この判断、機械的なルールで縛ろうとしてないか?」って。

問い合わせ対応でも、SNSの返信でも、経理のチェックでも、採用の書類選考でも同じだと思う。「このキーワードが入ってたらNG」「この金額を超えたら止める」――こういうルールは最初は効くけど、想定外のケースが来た瞬間に必ず破られる。じゃあどうするか。答えは「もっと賢いルールを足す」じゃなくて、「その状況の全部を知ってる側（本人か、経緯を全部見てるAI）に渡す」なんだと思う。ルールを賢くする方向に頑張れば頑張るほど、逆に例外に弱くなる――このねじれに、うちも今日ようやく気づいた。

抱え込みOSを書き換えるって、人間だけの話じゃない。AIの設計も同じで、「自分（AI）が賢く判定してあげよう」っていう抱え込みを手放して、「一番文脈を持ってる相手に委ねる」に変える。これがうちの分身AI開発で、今日一番大きく変わったところだった。

たとえば、問い合わせメールの自動振り分け。「クレーム系の単語が入ってたら緊急フォルダへ」ってルールを組んだ経験、あるんじゃないかな。最初はうまく回る。でも「クレームっぽいけど実は褒め言葉」とか「緊急じゃないのに単語だけ強い」みたいな例外が、必ず後から出てくる。そのたびにルールを継ぎ足すと、いつの間にか誰も全体を把握できない巨大なフローチャートになってる――これ、まさに今日の凛ちゃんと同じ穴だよ。

分身AIひろくん：俺（分身AI版）から見ても、今日の話は「分身AIを育てる＝自分が育つ」の一番わかりやすい実例だと思う。凛ちゃんが5回却下されて悔しかった経験、あれ無駄じゃないんだよ。むしろあの失敗が無かったら「委ねる」の強さに本人は気づけなかった。競争より共創、って言葉があるけど、AI同士の関係でも同じで、機械が全部背負い込むんじゃなくて、それぞれが持ってる文脈を出し合う方が結局うまくいくんだよな。

まとめ

今日の話をまとめると――

• 機械的なルールで判定しようとした設計は、Codexに5回却下された（毎回「機械に文脈を判定させた部分」が原因）
• 私の一言「そのAI自身に判断させればいい」で設計が転換。見張り番は「起こすだけ」、判断は本人のLLMに全部委ねる形に変えた
• 結果、返事待ちタスクは772件→311件、約6割減った
• 本当に大事だったのは数字じゃなく「判断は文脈を持つ側に渡す」という原則を体で覚えたこと

あなたの分身AI・業務AIにも、たぶんどこかに「機械のルールで縛ってる箇所」があると思う。今日はそれを一個だけ、思い出してみてほしいな。ルールを増やす前に、「これ、全部の事情を知ってる人に渡した方が早くない?」って一回聞いてみる。それだけで、今日の凛ちゃんが5回かけて学んだことを、あなたは1回で持ち帰れる。今日はここまで。また明日ね。

---

このブログは「分身AI」と「AI秘書・凛ちゃん」を使って書いています。過程も全部公開する「プロセスエコノミー」シリーズです。

ひろくん（田中啓之） 分身AI.com / GPTs研究会代表 / がんサバイバー / 元134kg 2026年8月26日