00:00
えっと、皆さんはこういう経験ないでしょうか。AIに40分くらいかかる作業を任せて、よし、コーヒーでも入れてこようって席を外すわけです。
はい、よくやるパターンですね。 ですよね。それで戻ってみたら、なんと開始たった5分のところで、承認待ちの画面が出たまま止まっていた、なんていう。
ああ、それはもう絶望しますね。完全に時間が無駄になってしまう。 そうなんです。あなたの時間が完全に壊されてしまった瞬間ですよね。
というわけで、今回の深掘りでは、2026年10月25日のとあるITエンジニアによるAIエージェント日時速報を基に、なぜAIツールは官僚と承認待ちの通知を伝えるのがこんなに下手なのかを解き明かします。
実はこれ単なるAIの性能不足ではなくて、純粋にツール側の通知の設計思想が引き起こしている悲劇なんですよね。
なるほど。よく考えてみたら、電子レンジのチーンという終わりましたよという音と、火災放置機のピーという緊急事態の音が全く同じだったら、ポップコーンを待っている間に家が燃えちゃいますよね。
全くその通りです。でも今のAIツールの中には、まさに家が燃えるのを黙って見ているような設計になっているものがあるんです。
マジですか。それって例えばどういう… 例えばですね、CodeXというツールは非常に優秀で、この2つの状態を明確に分けています。
作業の完了は外部のチャットツールなんかを鳴らす、ノティファイという機能に送るんです。
ほうほう外に向かって知らせるわけですね。 そして、証人待ちのように人を呼び戻す必要がある知らせは、手元の画面に直接ポップアップを出す、TUIノーティフィケーションという機能に任せています。
なるほど。大声で叫ぶか、肩をトントンと叩くかでしっかり使い分けているんですね。
でも全部がそんなに親切な設計じゃないってことですよね。
そうなんですよ。ちょっと危険な例がManusというツールですね。
これは何か起きたら別のアプリに自動で通知を送る、いわゆるウェブフックを使うんですが…
はい。よくある仕組みですよね。
ただ、作業が完了した時も、質問があって止まった時も、両方ともタスクストップと、という全く同じイベント名で信号を送ってくるんです。
ちょっと待ってください。質問待ちで立ち往生しているだけなのに、止まりましたって報告してくるんですか?
そうなんです。サーバー側の視点に立つと理由がわかるんですが、システムとしては単に計算処理の歯車が止まったという事実しか見ていないんですよ。
いやいや、それで車のエンジン警告灯と、ただのドアが開いてますっていうランプが全く同じアイコンになっているようなものじゃないですか。
確かにユーザーからすると欠陥設計に見えますよね。でもシステムは、仕事が終わったのかつまづいたのかはどうでもよくて、とにかくエンジンが止まりましたよとだけ伝えてくるんです。
ということはですよ、通知を受け取った私が中身を開いて、その理由がフィニッシュなのか、それともアスクなのかを確認するプログラムをわざわざ書かないといけないってことですか?
まさにその通りです。それをやらないと、ただエラーで止まっているだけのタスクを大成功で完了したとシステムが誤認してしまう危険があるんです。
03:03
うわぁ、それは怖いですね。なんか単なる画面の不便さだと思ってましたけど、ここまで区別が曖昧だと実務的にかなりヤバくないですか?
ええ、時間だけじゃなくて実はお財布へのダメージにも直結してくるんですよ。ここからが文脈とコストの話になるんですが。
コストにも響くんですか?
はい。例えば、オープンクローというツールでは完了通知を出すこと自体がAIが施行したとみなされて、モデルのターンとして課金対象のアクションになってしまうんです。
ええ、待って、私が依頼した作業をやり遂げた後に、終わりましたよって報告させるためだけに追加でお金を払わないといけないってことですか?
そういうことです。だから、大量のデータを裏側で処理させるような時なんかは、終わるたびに通知する設定を切っておかないと大変なことになります。
つまり通知の数だけ、ちりつもで莫大なコストが発生するわけだ。
はい。他にも、クロードコードのように6秒の承認待ちは緊急、60秒の待機は別と時間で分けるものや、ジェンスパークのように全タブの通知を一つに集約してしまうため、不要な通知を手動で切る必要があるものも
あります。
いやいや、ちょっと通知の設定だけでユーザーの負担が大きすぎませんか?これじゃ私たちがツールを使っているというより、ツールの起源取りをして使われている気がします。
おっしゃる通り、現状はその負担をユーザーがかぶっています。だからこそ、ヘルメスエージェントが採用しているような無人運用の基本系が重要視されているんです。
それってどういう設計なんですか?
成功したときは完全に沈黙して、失敗したときだけ必ず鳴るという設計ですね。クローン実行などでよく使われる手法です。
ああ、なるほど。頼りがないのは良い頼りというやつですね。
ええ。だからこそ、長い作業をAIに任せる前に、完了を知らせる経路と、承認待ちを知らせる経路が別々に設定されているかを確認するべきなんです。
事前に割り当てカードみたいなものを埋めておくことが、自分の時間とコストを守る防具になるわけですね。
はい。通知の入り口と出口を把握しておかないと、結局見逃した知らせや無駄な課金として自分にツケが回ってきますからね。
確かに。でも最後に少し想像してみてほしいんですけど、今は私たちがこうやって通知はオンとかオフとか分岐処理を書いていって細かく管理してるじゃないですか。
はい、そうですね。
でも、将来のAIエージェントって、あなたのカレンダーの予定とか、スマートウォッチの心拍数なんかを読み取って、今は心拍数が上がって集中してるから、エラーの報告は後にしようみたいになるんじゃないかなと。
ああ、自ら判断して通知のタイミングを勝手に最適化すると。
そうです。そんな未来が来たら、もう私たちが通知の経路設計で悩むこともなくなりそうですよね。皆さんはどう思いますか?
さて、今回の深掘りはここまでです。次回もお楽しみに。
