00:00
朝食のトーストを少し焦がしたからといって、こう、家ごと燃やして立て直す人っていませんよね?
え、まあ、普通はいませんね。
ですよね。でも、あの、AIに長時間の作業を任せて、最後の最後でエラーが出たとき、私たちって悲鳴でそれと同じことをしているんですよ。
ようこそ、あなたのための深掘りへ。
はい。
今回のミッションは、あの、AIが失敗したときに、私たちが陥りがちな全やり直しの罠から抜け出すことです。
7つのAIエージェントの公式資料から、安全で無駄のない、こう、復旧単位を見極める手法をあなたにお届けします。
そうですね。AIにおける最大の落とし穴って、その、頭の中で考えたことと、物理的に手を動かした結果が全くの別物だという事実なんです。
ああ、なるほど。別物ですか?
ええ、例えば、クロードコードや、Googleのアンティグラビティなんかには、AIとの会話の履歴を過去の時点に巻き戻す機能があるんですね。
はい、よく使います。便利ですよね。
でも、会話を戻したからといって、AIがすでにPC上で実行したバシコマンド、つまりファイルの削除ですとか、外部へ送信済みのメールまで取り消されるわけではないんですよ。
えっと、ちょっと待ってください。それって、記憶喪失になったのに、すでに送ってしまった手紙は相手に届き続けている状態ですよね?
まさにその通りです。
それ、すごく危険じゃないですか?画面上のチャット履歴では治っているように見えても、裏側の実際のファイル状態とはズレてしまうっていうことですよね?
はい、そのズレが致命的な事故を生むんです。だからこそ、コーデックスというエージェントのアプローチが非常に重要になってきます。
コーデックスですか?
ええ、彼らのシステムでは、AIが作った成果物を一つの巨大な塊として扱うのではなくて、ファイル単位や範区と呼ばれるさらに小さな差分単位で細かく元に戻せるように設計されているんです。
範区?ファイル単位ならわかりますけど、そこまで細かく切り刻むと、なんか逆に管理が難しくなったりしませんか?
確かにパッと見は複雑に見えるんですが、これが命綱になるんですよ。設定ファイルのたった1個だけが間違っていた場合、さっきの例えでいれば、家全体を凍すのではなくて…
焦げた部分だけをピンポイントで削り取るみたいな感じですか?
そうですそうです。成功している他の膨大なコードはそのまま残せるからです。
焦げを削り取るのはわかりました。でもそもそもエラーが出た時に、ただ再試行ボタン、リトライですね。それを押すだけじゃダメなんですかね?
それはですね、エラーの度にボタンを連打するのは非常に危険なんです。
ああ、やっぱりAIが勝手にやり直してくれそうな気もするんですけど。
再試行の度にAPIの利用料が課金されるので、単純にお金の無駄にもなりますしね。
全スパークの資料が警告しているのはまさにこの点でして、同じ場所で失敗が続くなら、再試行する前にそもそもAIへの最初の指示、つまりプロンプト自体が間違っていないかをまず疑うべきなんですよ。
03:02
レシピ自体が間違っているのに何度料理し直しても美味しくならないのと同じですね、それって。
まさにその感覚です。
でもAIが今どこまで作業を進めているのかって、どうやって正確に把握すればいいんですか?
そこでマーニュースのようなタスク管理手法が登場します。
マーニュースはAIの全作業にタスクIDという整理番号を割り振って状態を管理するんです。
タスクID、番号をつけるんですね。
ええ、このIDを追跡する仕組みがあるおかげで、AIがシステムエラーで止まっているのか、それとも次の操作のためにユーザーの確認待ちでただ一時停止しているだけなのかを判別できるんですよ。
なるほど。それを無視して頭から再実行してしまうと、すでに完成済みの成果物を二重に作ってしまうということですか?
その通りです。
二重作業は絶対に避けたいですね。
じゃあ実際にエラーが起きて立ち往生したとき、私たちはどう復旧させるべきなんでしょうか?
ハーメスというエージェントは、障害の種類によって復旧の道筋を明確に分けています。
分けている。どういうふうにですか?
自分の手元での文法ミスやローカル環境の破損なら、状態を少し前に戻すロールバックを使います。
一方で、外部のAPI制限などで一時的に接続できない場合は、別のAIモデルやプロバイダーに切り替えるフォールバックという手法を使うんです。
なるほど。つまり、手紙の誤字を修正液で直すのがロールバックで、いつもの郵便局が閉まっていたから、フェデックスに変えて送るのがフォールバックですね。
完璧な例えですね。全く違う対応になります。
さらに、オープンクローの使用では、完了済みの作業は絶対に再送しないように設計されています。
絶対に再送しない。
はい。エラーが起きた現在のHTTPリクエスト、つまりその瞬間のデジタルな通信のやり取りだけをピンポイントで再試行するんです。
ネットが途切れたからといって、ショッピングカートの最初からやり直したら、二重に決済されてしまうかもしれないですもんね。
そういう恐ろしい事故を防ぐためですね。
だから失敗した通信の一歩だけをやり直す仕組みなんですね。これ、明日の仕事からあなたも意識を変えないといけませんね。
AIが失敗したとき、盲目に再実行ボタンを押す前に一度立ち止まる。
大事なステップです。
どこまで作業が終わっているか、外部へのメール送信や決済は動いていないか、このチェックリスト、いわば復旧再実行カードを埋めてから再実行の最小単位を決める習慣をつけるべきですね。
そうですね。空欄のまま再実行するのは本当に目隠しで運転するようなものですから。
確かに怖いですね。
ただ、最後に一つ皆さんに考えてみてほしいんです。
何でしょうか。
今後、AIがさらに進化してユーザーを煩わせないために、中間の作業プロセスを完全に隠し、まるで魔法のように振る舞うようになったらどうなるでしょうか。
それは何か、便利になればなるほど、私たちが監査できる復旧単位が見えなくなるということですか。
その通りです。ブラックボックス化が進んだ時、その恐ろしい二重実行の事故を私たちは一体どうやって防げばいいのでしょうか。
06:05
うーん、なるほど。
次のAI作業を始める前に、あなたにもぜひ考えてみてほしい問いですね。
