00:00
あの、AIの返答が急にフリーズしたことってありませんか? えー、よくありますね。
で、とりあえずもう一回同じ指示を送ってみたら、あの、すでに終わっていたファイル編集とかデータ送信まで二重に実行されて大惨事に、なんていうヒヤッとする経験、あなたにもあるんじゃないでしょうか?
いやー、あれは本当に心臓に悪いですよね。今回はですね、リスナーのあなたから共有いただいた、
AIエージェントの作業管理に関する生々しい実務ノートをベースに深掘りしていきます。
はい。今日のミッションは、ズバリ、途切れたAIの作業をいかに安全に再開するかです。さあ、紐解いていきましょうか。
えー、まあ正直なところ、会話の続きを再開することと、作業状態が元通りであることって同じだと思いがちじゃないですか?
いや、完全に同じだと思ってましたよ。違うんですか?
そこが一番の落とし穴なんですよ。ここで興味深いのがですね、コーダックスやクロードコードのようなツールでの挙動です。
はいはい。
過去の会話セッション自体は呼び戻せるんです。でも、会話が復元されたからといって、裏側にあるファイルの変更履歴、いわゆるGitの作業ツリーまで当時の状態に巻き戻るわけではないんですよ。
ちょっと待ってください。クロードコードって開発者向けのツールですよね?そういう環境のズレを防ぐ安全装置みたいなものは入ってないんですか?
それがですね、完全には同期されないんです。AIとの会話を止めている間に、別の端末から誰かがコードを書き換えている可能性もありますからね。
なるほど。
Googleのアンチグラビティにあるフォーク機能も同じですね。チャットの会話スレッドを複製するだけで、手元のローカルコード自体が都合よく分岐してくれるわけじゃないんです。
つまり、しおりを挟んだ本を途中から読み直そうとしたら、誰かに前の章を勝手に書き換えられていたみたいな状態ですよね?
そうそう、まさにそんな感じです。
その状態でAIに続きを書かせたら、それは物語の辻褄が合わなくなって崩壊しますよ。
なので、再開するときは単にチャットを開き直すだけじゃなくて、現在のファイルの差分を自分の目で確認しないと危険なんです。セッションIDと作業場所の称号が必須なんですね。
なるほど。物理的な作業環境がずれる理由はよくわかりました。でも、そもそもAIの画面上でステータスがはっきりと停止、つまりストップドになっていたらどうですか?
と言いますと?
いや、AI自身の作業が止まっているんだから、そこは安心して再開ボタンを押していいんじゃないかなと。
あー、そこもすごく騙されやすいポイントですね。
え、ダメなんですか?
はい。マナスのような非動機API、つまり裏側で複数の処理を並行して行うシステムだと、表向きのステータスが停止でも、実は見えないところで処理が続いていたりするんです。
止まってるのに動いてるってことですか?
そうなんです。レストランの厨房に例えるとわかりやすいかもしれません。
ほう。
ウェイター、つまり画面上では注文待ちで止まって見えても、厨房というバックグラウンドではまだ前の料理を煮込んでいる最中かもしれないんですよ。
03:05
うわ、それは怖い。表面上のステータスだけ見て同じ注文を通したら、料理が二つ来ちゃうわけですね。
まさにそれです。詳細なタスクデータを確認しないと二重実行になります。それに、ゲンスパークのように長く複雑な作業を行う場合も要注意ですね。
ゲンスパークですか?
ええ。作業が80%完了しましたっていうAIの報告を信じて再開地点を決めるのも、実はNGなんです。
どうしてですか?進捗ゲージがあるなら、残り20%から再開すればいい気がしますが。
なぜならですね、AIには本当の意味での体内時計とか進捗計算機がないからです。
ええ、そうなんですか?
はい。AIが言う80%というのは、単に次に来る確率の高い言葉を予測して最もらしい数字を出力しているだけなんですよ。実際の作業の進み具合とは無関係なんです。
なんだって。じゃあ何を基準に再開すればいいんですか?
確実に確認できる成果物です。
成果物?
ええ。調査資料のテキストとか書きかけの走行ファイルなど、人間が実際に開いて検査できる物理的なファイルが存在する地点まで戻って、そこを区切りとして再開すべきですね。
なるほど。AIの自己申告じゃなくて、かくたる証拠ベースで動けということですね。でも、AIの記憶についてはどうですか?
記憶ですか?
はい。長時間作業しているAIなら、自分はさっきこのファイルを書き換えたっていうチャットのログを記憶していますよね。
ああ、ここでさらに面白くなるんですが、実はそこにもAIならではの記憶の圧縮という資格が潜んでいるんです。
記憶の圧縮?
ええ。例えば、ハーメスエージェントのマイクロコンパクションやオープンクロードの要約機能ですね。頭の中のジップファイルみたいなものだと考えてください。
頭の中のジップファイル?
はい。会話が長くなると処理が重くなるので、AIは過去のやり取りを圧縮して要約を作るんです。
なるほど。
ただ、全体像に結びつけて考えてみると、そのテキストを圧縮する過程で、いつどのファイルに実際に書き込みを完了したかという厳密な実行記録のタイムスタンプが欠落してしまうんですよ。
ああ、わかった。要約された荒い記憶を読んだAIが、あれ、まだ書き込んでないかもと勘違いして、もう一回ツールを使っちゃうわけですね。
その通りです。外部へのデータ送信とかファイルの書き込みといった副作用が完了したかを確認せずに再実行すると、致命的な二重送信につながります。
いや、恐ろしいですね。要約は記憶の代わりにはなっても実行記録ではないと。
ええ、そのメカニズムをしっかり理解しておく必要がありますね。
面白いですね。ここまでの7つのツールの仕様や裏側の仕組みを統合すると、AIを盲信することの恐ろしさが見えてきます。
では、私たちが明日からすべき具体的なアクションは何でしょうか?
06:02
作業の中断や終了時に、人間側でアナログな再開確認カードを残すことですね。
ほう、カードですか。何を書くんですか?
はい、現在の作業ディレクトリ、ファイルの変更差分、最後に確認した成果物、未完了のタスク、そして外部への送信などの副作用の有無、この5つをメモしておくんです。
なるほど。つまり、これはどういうことか?
あなたに必要な最初の一手は、止まったAIに慌てて、もう一回やってと拍手の再依頼を投げることじゃないんですね?
ええ、現状の読み取り確認から始めるべきだということです。
画面上のAIの言葉じゃなく、手元の事実を検証するステップこそが、第三次を防ぐ唯一の防波堤になるわけですね。
はい、まさにその通りです。
では最後に、リスナーのあなたに少し考えてみてほしいパラドックスがあります。
何でしょう?
私たちは、AIがすべてを自律的に記憶し、完璧に管理してくれる未来を目指して最先端のツールを使っているはずですよね?
ええ、もちろんです。
それなのに、なぜ私たちは以前にも増して、綿密でアナログな人間用の作業メモをしおりのように挟み続けなければならないのでしょうか?
この効率化の矛盾について、ぜひ一度ご自身で考えてみてください。
