00:00
あのちょっと想像してみてください。朝一番で、あなたがAIにものすごく時間のかかる複雑なデータ処理とか、リサーチのタスクを頼んだとしますよね。
はい、よくあるシチュエーションですね。 で、よしよしこれで重たい仕事が一つ片付くぞって思って、一旦席を立つじゃないですか。
それで数十分後に画面に戻ってくる。すると、なぜかブラウザが予期せず閉じていたりとか、無機質な通信エラーの画面だけが表示されているんですよ。
ああ、あれは本当に心臓に悪いですよね。
ですよね。あなたが頼んだあの長時間の作業が最初からまるっきりなかったことになっている。この瞬間、仕事の効率化っていう魔法が完全に解けてしまいますよね。
まさにその通りです。どれほど背後にある大規模言語モデル自体が優秀だったとしてもですね、
ユーザーインターフェースとかシステムの実装がその現実に追いついていないと、ユーザー体験としては非常にフラストレーションがたまるものになってしまうんです。
本当にそう思います。それで今週のAIエージェントに関する開発者向けのアップデートとか一時情報ですね。
例えば、コーデックスとかクロードコード、マヌースといった各社の2026年7月27日版のリリースノートを読み込んでいたんですが、
実はある明確な共通のテーマが浮かび上がってきたんです。それはですね、AIに長い仕事を任せる際に、私たちが本当に注視すべきなのは、完了しましたという結果の画面ではないということなんです。
なるほど。完了画面ではないと。
一番重要なのは、途中で止まった後、どこから、そしてどうやって再開できるかというシステムの状態管理なんですよね。
それは非常に重要な視点ですね。
よし、これを紐解いていきましょう。今回の深掘りでは、このテーマを徹底的に解剖していきます。
えーと、状態管理、技術的な言葉で言うと、ステートフルな処理の実装ということになりますね。
ステートフルですね。
はい。
今回の資料を見ていくとですね、各社が単なる知能の向上から、より泥臭い、実務での回復性へと開発の打上を大きく切っていることが非常によくわかります。
回復性ですか?
そうなんです。これは単なる新機能の紹介というレベルの話ではなくてですね、AIがいかにして人間の不確実な作業環境に適応しようとしているかというアーキテクチャの進化の過程でもあるんです。
確かに言われてみればそうですよね。そもそもAIの処理が止まる理由って、必ずしも先ほどのようなシステム側のエラーとかクラッシュだけじゃないじゃないですか。
もちろんです。実務の中だと、私たち人間側が意図的に介入するケースが多々ありますよね。
あ、ちょっと待って、そのアプローチは違うとか。
はいはい、やっぱりこっちのデータを優先してくれとかですね。
そうそう、それです。だからこそ、実行前と実行中に人間がどう介入できるかという計画と分岐の仕組みが最初の鍵になってくると思うんです。
本当にその通りですね。
そして、その介入を視覚的かつ構造的に解決しようとしているのが、今回の資料にあるマニュースのアプローチなんです。
03:03
マニュースですね。7月22日に発表された機能ですか?
はい、プランモードと呼ばれる機能ですね。これはエージェントがいきなり自律的な行動を開始してしまうのを防ぐための機能なんです。
いきなり動き出さないと。
そうなんです。ユーザーのプロンプトを受け取った後、マニュースはまず実行可能性を評価して、これから行うアクションの構造化された計画書を生成します。
なるほど、先に計画書を見せてくれるんですね。
ええ。人間がそれをレビューして、必要に応じて編集を加えてから初めて実際のAPIコールとかファイル操作といった物理的な処理が走る仕組みなんです。
ああ、それは安心感がありますね。さらにマニュースって少し前の7月9日にもブランチ、ブランチっていう機能を発表していますよね。
はい、発表していますね。
これ、ある時点までの指示とか生成されたファイル、文脈の履歴を全部保持したまま、別のセッションとして分岐させることができる機能じゃないですか。
ええ、まさにそれです。
これを見た時、カーナビのルート案内にすごく近いものを感じたんですよね。
カーナビですか?面白い例えですね。
つまり、最短ルートで突っ走っている途中で、元のルートの情報を消さずに、ここから海沿いの道へ行くルートを新しくシミュレーションするような。
ああ、なるほど。
もし、海沿いが通行止めだったり、時間がかかりすぎるなら、すぐに元の最短ルートの地点に戻れるわけですよね。そういうことですよね。
まさにその通りです。
ここで非常に興味深いのは、システムアーキテクチャーの観点から見ると、これがAIとの対話を一本道の会話から、戻れる作業場へと引き上げているというパラダイムシフトなんです。
一本道から作業場へですか?
はい。これまで、チャットベースのAIとのやり取りって、基本的に非可逆だったんですよ。
ああ、やり直しが効かないってことですね。
そうなんです。一度文脈が汚染されたり、間違った方向に進んだりすると、ユーザーはプロンプトを最初から打ち直すしかありませんでしたから。
確かに最初からやり直すのって本当に面倒なんですよね。
ええ。でもこのブランチ機能は、特定のタイムスタンプにおけるエージェントの状態、つまりメモリ内の変数とか、それまでの履歴、中間ファイルなんかのスナップショットを取って、そこから新しい実行ツリーを派生させているんです。
なるほど。単なるテキストのコピーじゃなくて、システムの状態そのもののスナップショットを取っているんですね。
そういうことです。
そう考えると、オープンAIのコーデックスの開発者向けドキュメントで強調されている実行の境目という概念、あれも全く同じ文脈で理解できますね。
ええ。エクセキューションバウンダリーですね。コーデックスの運用において、表面的なモデルのバージョン番号よりも、実はこの実行の境目の設計の方が重要視されているんです。
バージョンアップよりも重要なんですか?
はい。エージェントが自律的に複数のステップを実行する際、どこまでが完了していて、どの権限、パーミッションですね、それが有効であり、手元にどの中間成果ボツが残っているのか。
06:03
ええ。
このチェックポイントが明確に定義されていなければ、そもそも安全な再開って不可能なんですよ。
つまり私たちがAIに仕事を任せる時って、ただブラックボックスの中にデータを放り込むんじゃなくて、どこまで進んだら一度状態をセーブするのかという区切りを意識する仕組みが、今まさに必要になってきているわけですね。開始時の目的とか、最後に成功した処理を記録しておくような。
ええ。それが透明化されて初めて、人間はエージェントの作業から安全に目を離すことができるようになるんです。
なるほど。意図的な介入とか、計画的なセーブポイントについては、各社のアプローチがよく見えてきました。でもここからが本当に面白いというか厄介なところなんですが。
ほう、なんでしょう。
もし計画通りに進んでいて、人間も何も操作していない。それなのに背後のクラウドインフラの都合でコンテナが落ちたり、処理が強制終了されたり場合って、裏側の挙動はどうなるんでしょうか。
ああ、それは非常に前述的かつ、開発者を現在進行形で悩ませているディープな技術的課題ですね。
ですよね。
資料にあるクロードコードの事例がまさにその問題の確信をついています。クロードコードのバージョン2.1.216のパッチノートを見るとですね、
クラウド上のセッションコンテナがターンの途中で予期せず再起動してしまった際の挙動、これが修正されているんです。
ターンの途中で落ちた場合ですね。
ええ、具体的には、処理が途中で落ちて応答不能、いわゆるハング状態になるのを防ぐためにですね、再開時にその中断されたターンをもう一度実行する、つまり再実行するという仕様が組み込まれました。
なるほど。クラッシュしたらそのステップを頭からやり直すことで止まらないようにしたってことですよね。
そういうことです。
ちょっと待ってください。それってエージェントが単に文章を考えている途中ならともかくですよ。
もし外部のデータベースに書き込みをしている最中とか、メールの送信APIを叩いている瞬間にクラッシュして、それを自動で再実行されたら、これ外部サービスへの送信とかファイル編集も二重にやっちゃう危険があるってことですよね。
まさにそこなんです。そこがエージェント型AIにおけるべき等性という極めて重要な概念の欠如が引き起こす問題なんですよ。
べき等性ですか?
はい。べき等性というのは同じ操作を何度繰り返しても結果が同じになるというシステム設計の原則のことです。
なるほど。
単なるチャットAIであれば何度同じプロンプトを投げてもテキストが返ってくるだけなので無害なんですよ。
でもエージェントは現実のシステムに対して副作用、サイドエフェクトを持ちますから。
ファイルを削除したり外部サービスにアクセスしたりする力を持っているからですね。
いやこれAIに気を使っているわけじゃなくて、単に二重処理の事故が怖いからいきなり続きよろしくとは言えないじゃないですか。
そうなんです。だからこそ再開、レジュームと再実行、リトライは技術的に全く異なる処理として厳密に区別されなきゃいけないんです。
09:00
確かに。
中断した時点の正確な状態を復元して続きを行うのか。それともそのターンの最初から処理をやり直すのか。
システム側がエラーリカバリのために良かれと思って自動で再実行をかけると、ユーザーの意図しない二重処理が発生するリスクがあるわけです。
うわー怖いですね。システム側のクラッシュでさえそれだけのリスクがあるなら、私たちユーザー側の無意識な行動の裏側ではもっと恐ろしいことが起きていそうです。
と言いますと?
例えば、ブラウザーのタブを閉じるといった装置です。画面を閉じたら当然AIの処理もそこで止まっているって、私たちは普通思い込んでいるんじゃないですか?
あーそれは非常に危険な思い込みですね。その認識のズレが引き起こすのが、いわゆるゾンビプロセスの問題です。
ゾンビプロセス。名前からして不穏ですね。
Googleのアンティグラビティの修正事例がそれを明確に示しています。
アンティグラビティのチェンジログにはですね、会話を閉じた際やアーカイブした際に、バックグラウンドで走り続けていた再思考のプロセスを確実に停止させる修正が含まれていました。
えー、それってフロントエンドの画面上では終了したように見えていても、裏側では無限にエラーを吐きながらループを回し続けていたかもしれないってことですか?
ええ、その可能性があったということです。ユーザーのブラウザーと裏側で動いているエージェントの処理って、多くの場合非動機で動いていますから。
なるほど、繋がっていないんですね。
はい。ウェブソケットの接続が切れた時に、バックグラウンドのプロセスに対して適切な終了シグナルを送る実装が漏れているとですね、エージェントは主人がいなくなったことに気づかないまま、最後の命令を延々と実行し続けてしまうようとしてしまうんです。
これは重要な問いを投げかけていますね。リスナーの皆さんも、普段使っている便利な自動処理、画面を閉じた後、本当に止まっていますか?
そうですね。実務での確認事項として、アーカイブ後の挙動などは一度チェックしてみた方がいいかもしれませんね。見えないところで走り続けるエージェントほど恐ろしいものはありませんから。
まったくです。さて、ここまでは処理の停止と再開、つまりアクションそのものの状態管理について見てきましたが、もう一つクリアしなければならない層がありますよね?
はい。ルーティングとコンテクストの問題ですね。
処理が正しく再開して完了したとして、その結果が一体どこに返ってくるのかという出力先の管理です。資料にあったオープンクローのリリースノートに非常に生々しい実務の課題が書かれていましたね。
はい、ありましたね。テレグラムとかWhatsApp、Webチャットなんかで複数のチャンネルを跨いだ会話のセッションが移動した際の修正ですね。
そうですそうです。エージェントの変身や生成物が正しい元の会話にちゃんと結びつくような修正が行われたっていう。
ええ。エージェントが長時間稼働するということは、その間にユーザーがデバイスを変えたり、プラットフォームを移動したりする可能性が非常に高いということですから。
パソコンからスマホに変えたりとかですね。
ええ。非同期処理の裏側では、エージェントはコールバックURLとか特定のスレッドIDを頼りに結果を返してくるんです。
12:06
でも、システムが一度停止して再開する際に、この宛先データがちゃんと保存されていなかったりすると、再起動時に古いIDを参照してしまって結果が迷子になってしまうんですよ。
これ、仕事としては致命的な失敗ですよね。いわゆる配送事故みたいなもので、もし機密性の高いデータ処理を頼んでいて、エージェントが再開後に、なぜか現在の個人のチャットじゃなくて、チーム全体の古いスレッドに結果をご送信してしまったら。
処理自体は成功していても、セキュリティの観点からは大事故ですね。AIの出力結果にとって、何を生成したかと同じくらいどこに配置したかが重要だということです。
そして、その宛先と同じくらい厄介なのが、再開時にどの記憶を引き継ぐべきかというコンテキストの扱いです。
そうですね。長期記憶の管理アプローチとして、ジェネスパークのバーゾン6.0の事例を見てみましょうか。
彼らはセカンドブレインと呼ばれる記憶層を導入しました。
セカンドブレイン、第2のノーですね。
はい。これはユーザーの過去のメール、会議の書き起こし、文書なんかを継続的に参照し続ける仕組みです。
毎回ゼロからプロジェクトの前提を説明しなくて済むなら、再開する時の摩擦はかなり減りそうですね。
ユーザー体験としては非常にスムーズになりました。しかし、システムアーキテクチャとしては新たなリスクを抱え込むことになるんです。
資料にある巨大な倉庫の例えが非常に的確なんですが、
巨大な倉庫、はい。
記憶の容量が増えるということは、それだけ検索空間にノイズが増えることを意味します。
AIにとって、情報を覚えることはデータベースに追加するだけで済みますが、
一度覚えた情報を忘れる、あるいは無効化することは技術的に非常に難しいんですよ。
ああ、なるほど。例えば、あるプロジェクトをAIに任せていて、途中で1週間くらいタスクを止めたとしますよね。
はい。
で、その1週間の間にチーム内で大きな方針転換があったとするじゃないですか。
はい。
今日タスクを再開したとき、AIのセカンドブレインの中には、
1週間前の古い方針と今日の新しい方針が両方混在してしまっている状態になるわけですよね。
その通りです。記憶が豊富なAIほど、再開前に、
先月の前提は今日も有効か?と問い直す、いわば棚下ろしが必要になるんです。
棚下ろしですか?
はい。
AIが古い前提と新しい指示を同時に検索してしまうと、
矛盾だらけの出力を生成する原因になります。
人間なら、あ、先週の話はもうなしね、で済みますが、
エージェントにはそのキャッシュを無効化するプロセスが不可欠なんですよ。
つまり、覚えていることと再開して良いことは別だと、
巨大な記憶を持たせて全部自動でやらせようとすると、
かえって状態管理が複雑になって破綻しそうですね。
じゃあ、複雑になりすぎたときはどうすればいいんでしょうか?
そこに対するシンプルで強力なアプローチを採用しているのがハーメスエージェントです。
ハーメスエージェントですね。
ええ、彼らはブラックボックス化された複雑な自動復旧に頼るのではなく、
15:04
CLI、つまりコマンドラインベースの明示的なコマンドを提供しているんです。
資料によると、
スラッシュニューとか、スラッシュリセット、スラッシュリトライ、
それにスラッシュアンドゥなんていうコマンドがあるみたいですね。
特にこのスラッシュアンドゥ、
直前のアクションを取り消すコマンドの存在が
極めて重要な解決策の一つになっています。
なるほど、エージェントが間違った経路を進み始めた時、
システム全体を再起動したり、プロンプトを書き直したりするんじゃなくて、
エージェントの内部状態を
一つ前の安全な状態へとロールバックさせるんです。
つまりこれって結局どういうことなんでしょう?
パソコンのコントロールZみたいに最後の一手だけを取り消せるってことですよね?
そうですね。
ユーザーの手によって明示的に状態を一つ戻す権限を与えることは、
複雑な自動称号システムを作るよりも、
はるかに確実で透明性の高いエラーリカバリの手法なんです。
巨大な復旧システムよりも、結局そういう小さな機能こそが
仕事を最初からやり直さないための最高の使い勝手を生む場合があるんですね?
ええ、まさにその通りです。
いや、ここまで各社の最新動向を見てきましたが、
AIに実務を任せる上で、
私たちが確認すべきポイントがはっきりと見えてきましたね?
はい。
これをさらに大きな視点と結びつけてみるとですね、
今日紐解いたソース資料から再開できるAIを選ぶための
4つのメモが見つ引き出せます。
4つのメモ、教えてください。
第一に、実行前に計画を事前編集できるか?
第二に、既存のコンテキストを破壊せずに
途中分岐させることができるか?
はい。
第三に、システムエラーの際、再実行される内容の透明性が担保されているか?
そして第4に、結果の正しい返却先とコンテキストを
ユーザーがコントロールできるか?です。
リスナーの皆さん、これらは非常に強力な評価基準になるはずです。
今日からできる小さなテストとして、
あえて1つの仕事を途中で止め、
会話を閉じ、再開させてみてほしいんです。
いいテストですね。
ええ。
AIが何を覚え、何を忘れ、
どこに返事を出してくるかを見ることで、
初めてそのAIを仕事相手として信用できるかが分かるはずですから。
そうですね。
最後に、今回の議論を踏まえて、
新しい視点を1つ投げかけたいと思います。
お願いします。
私たちはこれまで、AIをどれだけ賢いか、
あるいはどれだけ早いかで測ってきました。
しかし、人間の予定は電話1本で崩れますし、
気分もコロコロ変わります。
ええ、本当にそうです。
これから私たちが本当に評価すべきAIの究極の指標とは、
その賢さではなく、
私たち人間の気まぐれや割り込みをどれだけ優雅に許容し、
リカバリーしてくれるかという、
回復力、リカバリリティなのかもしれません。
回復力ですか?
はい。
あなたのAIは、あなたの気まぐれについてこられますか?
あなたのAIは、気まぐれについてこられるか?
深い問いですね。
今回はここまでとなります。
18:00
皆さんもぜひ、ご自身のAI環境を見つめ直してみてください。
