00:00
えーと、今日が2026年の6月17日なんですけど、 リスナーの皆さん、日々のお仕事とかニュースのチェックでお忙しいとは思うんですが、
今日だけは少しちょっと立ち止まって、この話題に向き合ってほしいんですよね。 そうですね、明日が本当に大きな節目になりますからね。
はい、そうなんです。 AI業界において、明日、つまり6月18日が極めて重要なXデーになるからなんですよね。
世間では、新しいAIエージェントの花々しい新機能とか、すごいアップデートの話ばかりで持ちきりなんですけど、
えー、まあ目立ちますからね、そういう話題は。 ですよね。でも、私たちが今回のディープダイブでフォーカスするのは、そこじゃないんです。
機能の裏側に隠れた、一番厄介で、しかも最も重要なミッションについて、しっかり紐解いていきたいなと。
つまり、移行した後の残骸の処理ということですよね。 その通りです。
なんかみんな、新しい家への引っ越しばかり気にして、古い家の取り壊しをすっかり忘れちゃうじゃないですか。
えー、本当にそうですね。 システム運用において、そこが最大の盲点になりがちなんですよ。
これ、例えるなら、最新のピカピカなスマートフォンを買って、データ移行も完了して、よし完璧だぞって思ってるのに、
なぜか毎朝、部屋の隅の段ボールの奥から古いスマホのアラームが鳴り響いてるみたいな、そういう状態ですよね。
あー、その古いスマホのアラームっていう例え、システム運用の本質をすごくついてますね。
やっぱりそうですか。新しいシステムが動くことばかりに気を取られて、この古い前提がシステム内に残ったままになるのが、本当に恐ろしいなと思っていて。
えー、人間って移行の直後は、どうしても新しいAPIが通ったかとか、新しいツールがちゃんと動くかっていうところに視界がロックされちゃうんですよ。
はいはい。とりあえず動けばOKみたいな。
そうなんです。でも、実務で後々、それこそ致命的なセキュリティーインシデントとかシステム障害を引き起こす原因って、新機能のバグじゃないんですよね。
というと、やっぱりその残骸の部分ですか。
はい。ディスクの奥に残された旧CLIの手順書だったり、権限を持ったまま放置されちゃってる古い認証情報だったり、あるいはシステム内にひっそりと残る、使われなくなった環境変数だったりするわけです。
うわ、耳が痛い話ですね、それ。じゃあ、まさに明日その移行を強制されるケースから具体的に見ていきたいんですが。
はい。Googleの話ですね。
そうです。Googleデベロッパーズブログの情報なんですけど、明日6月18日にGoogle AIProとかUltra、あと無料ユーザー向けのGemini CLIとGemini CodeAssistのIDE拡張ですね。これがリクエスト提供を停止します。
いよいよですね。
はい。で、移行は、アンティグラビティCLIへの移行が公式ルートになるわけですよね。エンタープライズ版とかは継続されるみたいですけど、多くのユーザーにとっては強制的な切り替えになります。
ここで読み取るべきなのは、明日は単なるアンティグラビティのロンジ記念日ではないということなんですよ。
03:03
なるほど。運用担当者からすると別の意味を持つと。
ええ。切り替えの後に旧Gemini CLIを呼び出そうとする古いスクリプトがどこかに残っていないかとか、IDEの拡張機能から既に存在しない古い動線へデータが流れていないかとか、そういうのを確認する非常にシビアな研修の初日になるんです。
ちょっと待ってください。そこでお聞きしたいんですけど、もし古いルートが残っていたらどうなるんですか?呼び出しが勝手にエラーになって、あちこちでシステムがクラッシュして大惨事になるみたいな、それって最悪の事態じゃないですか?
それがですね、実は必ずしも最悪の事態とは言えないんですよ。
え、そうなんですか?クラッシュするのに?
ええ。むしろ明確にエラーになってシステムが止まってくれる方が運用上は遥かに安全なんです。
へえ、それはちょっと意外ですね。
ここで、オープンクローの2026.6.6のリリースを見てみましょうか。
彼らは今回のアップデートでフェイルクローズドという概念を極めて重視しているんです。
フェイルクローズド、異常を検知した際にシステムを安全側に倒して閉じる、つまり停止させる動きのことですよね?
その通りです。以前のAIシステムって処理が途切れることを極めて嫌がっていたんですよ。
ああ、何とかして答えを出そうとするみたいな。
ええ。もしAPIの接続先が死んでいたら、AIが勝手に別の不正確な情報を引っ張ってきて処理を続けようとしたり、
エラーを隠してダミーデータを出力したりと、いわゆるハルシネーションの温床になっていたんです。
ああ、なるほど。エラーで止まるより間違ったままできたふりをして静かに進んでしまうことの方が本当の大惨事ってわけですね。
まさにそういうことです。だからこそオープンクローは、AIがコードをテストする隔離環境のサンドボックスとか、
AIが外部ツールと連携するための標準規格であるMCPにおいて、古い経路や異常を検知したら即座にシステムを遮断する設計にしたんです。
なるほど。
一見すると面倒なんですけど、このフェイルクローズドによるクラッシュって、
どこに古い前提が残っているかを教えてくれる強力な発言頭の役割を果たすんですよ。
ああ、エラーで止まった場所がここを掃除してくれって叫んでいるわけですね。
ええ、残った失敗は後始末のための道しるべになるということです。
いや、すごく納得しました。ただ、エラーで古いものを見つけるのも大事だと思うんですけど、
そもそも新しい環境に何を持っていくか、そこも悩ましいところですよね。
はい、まさに次の課題ですね。
ソースにあるコーデックスのアップデートが結構面白いアプローチをしていて、
クロードコードからセットアップ情報とか最近のチャット履歴を選択して取り込むインポート機能が追加されたんです。
ええ、スラッシュインポートですね。
そうです。それに加えて、ベッドロック API キー、
これ、AWS の強力な AI サービスにアクセスするための鍵ですけど、
この認証情報とか CLI の設定を暗号化してローカル保存する機能も追加されていて。
設定とか会話のコンテキスト、それに認証状態をシームレスに新環境へ移せる、
06:04
非常に強力な機能ですよね。
でもこれ、ちょっと突っ込みたいというか危険な気もするんですよ。
と言いますと。
いや、一見すごく便利そうですけど、過去の会話履歴とか API キーの束を、
それこそエイヤーッと丸投げでインポートしたら、
結局古い環境に溜まっていたゴミとか、不要な権限も一緒に新居に持ち込むことになりませんか?
ああ、そう懸念されるのも無理はないですね。
ただ、このインポート機能って単なる引っ越しトラックというより、
厳格な税関のように機能するんですよ。
税関ですか?
はい。過去の設定をそのまま無秩序に持ち込むのではなくて、
ローカルでの暗号化保存を強制することで、
これまで開発者のパソコン内に散らばっていたキーや設定が、
一つの管理されたフォーマットに集約されるんです。
あ、なるほど。あちこちにあったものが一旦まとまると?
ええ。つまり、インポートの過程でどんな古いキーが存在しているかが可視化されるため、
逆に棚卸しがしやすくなるんですよ。
ああ、そういうことですか。ただ持ち込むんじゃなくて、
リスト化されるからこそ不要なものを弾きやすくなるわけですね?
その通りです。そして、この持ち込むものの監査において、
人間が設定したキーの確認よりも遥かに厄介な課題が待ち受けています。
え、まだあるんですか?
はい。それがAI自身が過去の環境で作ったものの研修なんです。
AI自身が作ったもの。
ああ、ここでソースにあるハーメス・エイジェントの話につながるわけですね?
ええ、まさにそこです。
今回のバージョン0.16.0のリリースでは、デスクトップアプリへの対応なんかが追加されてますけど、
最大の特徴は自己改善型である点ですよね。
経験から独自のスキルを作り出して、利用しながら自分自身をオクティマイズしていくっていう。
はい。エイジェントが自律的に成長するということは、移行の際に確認すべき対象が、
エイジェントのプログラム本体だけではなくなるということを意味します。
と言いますと、中身のスキルも確認しないといけないと?
そうです。例えば、旧環境のAPIの癖に合わせて、
AIが勝手に編み出した裏技的なスキルがあったとしますよね。
はいはい、AIなりの工夫みたいな。
ええ。新しい環境に移行した際、AIの本体はアップデートされても、
AIが保持しているその古い記憶やスキルが残っていれば、
新環境で深刻な誤作動を引き起こす可能性があるんですよ。
なるほど。それって、AIの筋肉の記憶みたいなものですよね。
古いルールで覚えたスポーツのフォームを、
新しいルールの試合で無意識に出しちゃうような。
ええ、まさにそんな感じです。
自分が教えた設定だけじゃなくて、
AIが勝手に学んだ癖まで監査しないといけないとは、
いや、なかなかハードですね。
さらに話を進めましょうか。
AIの記憶やスキルを正しく移行できたとして、
次はエイジェントが実際に新しい環境で仕事をした後のフェーズに入ります。
09:03
ああ、ここからが本当に面白いところなんですよね。
ええ、アントロピックのクロードオープス4.8と
クロードコードのダイナミックワークフローの発表ですね。
はい、これによって単なる一問一答じゃなくて、
大規模なタスクを長時間、複数のエイジェントを連携させて
進められるようになったんですよね。
スラッシュワークフローで進行状況の確認ができたり、
エンタープライズ向けに細かいカスタムロールも設定できるみたいで。
素晴らしい進化ですよね。
ただ、運用側からすると、この長時間の自律的なワークフローは
非常に神経を使う部分なんです。
やはり管理が難しくなるんでしょうか。
ええ、短いチャットなら結果を画面で見て、それで終わりです。
でも、AIが数時間、あるいは数日間に渡って
裏側で自律的にシステムを操作し続けるようになると、
作業が終わったかどうかを確認するだけでは全く不十分になるんです。
終わった後の確認作業が変わってくるわけですか。
はい。完了した後の回収です。
成果物は社内ネットワークのどこに保存されたのかとか、
途中で失敗して放置されたサブタスクはないかとか。
ああ、なるほど。
あとは実行のためにAIに付与した広範な権限が
そのまま開きっぱなしになっていないかですね。
これらを確実にトレースして後始末をしなければなりません。
なんかそれ、すごく優秀なインターンに
大規模な市場調査プロジェクトを頼んだ状況に似てますね。
インターンですか?
ええ。完璧にやっておきましたって笑顔で報告してくれたのはいいけど、
その100ページもある超重要な書類を
オフィスのどこの引出しに入れたか教えてくれずに
帰っちゃったみたいな状況というか。
ああ、それは困りますね。
探すのに丸1日かかったら本末転倒じゃないですか。
まさにその状態です。
そしてその引出しがどこかわからない問題をさらに複雑にするのが
ゲンスパークが提唱するAIワークスペース4.0のようなコンセプトなんです。
ああ、資料にありましたね。
デスクトップとかオフィスアプリ、クラウドのドライブ、画像生成、コード環境とか
あらゆるプラットフォームを横断して動くAI従業員の世界。
はい。AIが一つのチャット画面に閉じこもっている時代は終わりましたからね。
そうですね。もうあちこち動き回ってますよね。
ええ。ワークスペース型のAIがあらゆるツールをまたいで作業するようになれば
AIがタスクを完了したかというステータスよりも
成果物がどこに、どんなフォーマットで残されたかの方がはるかに重要になるんです。
確かに。
ユーザーが後から見つけて再利用できる状態で保存されていなければ
業務としては未完了と同じことなんですよ。
なるほどな。ここまではパソコンの中とか
社内システムでの失われたファイルの話をしてきたんですけど
ここからはもっとスケールの大きな組織やルールの変化によって
強制的に後始末が必要になるケースに踏み込みたいと思います。
はい。組織協会の変化ですね。
これから取り上げるマナスに関する話題は
テッククランチなどの報道に基づく事実関係の確認です。
12:04
私たちはこの報道の背後にある政治的な対立とか
各局の知性学的な主張を評価したり支持する立場にはありません。
あくまでシステム運用にどのような影響を与えるかという
ITの観点に絞って見ていきます。
冷静に運用上のファクトだけを追いましょう。
はい。報道によれば当初メタに参加すると発表されていたマナスなんですが
中国当局の圧力によりメタとマナスの協力関係が分離
つまり巻き戻しの方向に動いているとのことなんです。
具体的にはデータの共有停止や
内部システムからの遮断といったプロセスが進められていると報じられています。
この事例はですねAIエージェントの運用が単なるソフトウェアの機能や
性能だけで完結するものではないという非常に厳しい現実を示しています。
というと?
つまりAIエージェントのデータは
組織の境界線の変更に極めて脆弱だということです。
脆弱というのは具体的にどういうことなんでしょうか?
企業間の提携解消とかあるいは社内での部署の投配号でも同じですが
組織の境界線が書き換えられた瞬間
機能まで普通にアクセスできていたサーバーが
法的にあるいは物理的にアクセスしてはいけない場所に変わるんです。
ああなるほど。ルールが一変してしまうわけですね。
その時エージェントが学習に使っていた作業履歴とか
共有していた生成物、内部システムとのAPI連携なんかを
どう切り離して片付けるのか?
それって単にケーブルをポンと抜けばいい
みたいな簡単な話じゃないんですよね。
はい、全く違います。
代替ルートに移すべき安全なデータと
完全に破棄、遮断すべきデータを瞬時に切り分ける
古い場所からの切り離し作業が発生するんです。
それは大変そうだ。
移行というのは新しい家への引越しであると同時に
古い家を完璧な形にして
すべての権利関係を生産するという
本当に途方もない作業でもあるわけですね。
そういうことになります。
さてここまでいろんな切り口で後始末の重要性を
ひも解いてきたわけですが
じゃあリスナーの皆さんは明日具体的に何をすればいいのか?
今回のソースから導き出された重要なアクションを
明日から使えるサバイバルガイドとして
3つのフェーズに分けて一気に整理してみましょうか。
はい、お願いできますか。
まずはフェーズ1、徹底的な削除、パージですね。
古いCLIや手順書、使えなくなったリンクを完全に削除すること。
そして不要になったAPIキーや認証情報を無効化すること。
ここで先ほどのフェールクローズドでシステムが止まった箇所があれば
そこが隠れた危険な動線です。
見逃さずに潰してください。
続いてフェーズ2は監査と更新ですね。
ハーメスエージェントのような自己改善型エージェントを使っている場合
その記憶とスキルが新しい運用方針に合致しているかを
必ず点検してください。
はい、記憶の点検ですね。
また移行作業のために一時的に広く設定した権限が
そのまま放置されていないかの再確認。
そして当然ですが、社内のユーザー向け案内を
15:01
最新の状態に更新することも忘れてはいけません。
そして最後のフェーズ3、探索と確認です。
新しいルートでログインできるかだけじゃなくて
実際の最小タスクが最後まで貫通するかのテストを行うこと。
さらに長時間に及ぶワークフローが
裏でひっそり動いたままになっていないか。
そしてAIが作った成果物が迷子にならず
正しい置き場所に保存されているかを確認してください。
これで旧のアクションが出揃いましたね。
はい、でも一番重要なルールがもう一つあるんですよね。
ええ、最後の一つ。これが最も重要です。
それは翌日の再研修を必ず行うこと。
翌日の再研修。
はい、どれだけ完璧に移行したつもりでも
移行当日には見えない問題が必ずあります。
古いキャッシュが切れた翌日、
あるいはバッチ処理が走った翌朝にこそ
本当の残骸が姿を表すんですよ。
デジタルな大掃除は
ホコリが完全に舞い落ちた翌日に
もう一度確認しろということですね。
まさにその通りです。
さて今回は人間がAIエージェントの移行と
後始末をいかに完璧に行うべきか
という視点でお話ししてきたんですけど
ちょっと最後に皆さんに少しだけ
試行実験を投げかけたいなと思いまして。
おっ、なんでしょうか。
ちょっと考えてみて欲しいんですけど
もし先ほど登場したような
自己改善型のAIエージェントがさらに進化して
自分自身で新しいAIモデルへの移行と
古い自分のデータの削除まで
完全に自動で行うようになったらどうなるでしょう?
ああ、それは驚異深いですね。
果たして彼らは自分にとって不都合な失敗履歴とか
おかしな挙動の残骸を意図的に確認することなく
正しく人間に報告してくれるんでしょうか?
私たちはAIが自分自身のミスを
なかったことにしてしまわないって
本当に信じられるんでしょうか?
自分のシステムを自分で掃除するわけですからね。
ええ、あなたのAIは
一体誰のために後始末をするんでしょうか?
明日のXデー、あなたのAIが何を新しい家に持ち込み
何をゴミとして捨てようとしているのか?
ぜひそんな視点でも観察してみていただければと思います。
ええ、ぜひ。
というわけで今回の徹底解説はこの辺で
皆さんまた次回お会いしましょう。
