00:01
ちょっと想像してみてほしいんですけど、例えば、ものすごく優秀な新入社員を雇ったとしますよね。
なのに、その人が実際どんな仕事をして、どこでつまづいているかっていう中身を一世見ないで、ただ今日オフィスのゲートを何回通ったかっていう入隊室の回数だけで評価している状況ってどう思います?
それはちょっと現場のリーダーとしては耳が痛い話かもしれないですね。
ですよね。
実際、AIエージェントの導入を成功したかどうか評価するときに、ただのログイン回数とか、表面的な実行回数だけで測っちゃうケースってすごく多いですからね。
そうなんですよ。こんにちは。この番組では毎回一つのテーマを深掘りしていくんですが、今日はまさにその数字の裏側にそぶっていこうと思います。
はい、よろしくお願いします。
今、手元にある資料がですね、2026年6月19日版のAIエージェント日時速報なんですけど、ここ数日、AIにどこまで権限を持たせるかっていう設計の話とか、実際の切り替え、あとは導入後の研修といった、まあ怒涛のプロセスを追ってきましたよね。
そうですね。かなり濃い内容でした。
でも実は本当に重要なのって、システムが無事に動いたその後の話なんですよ。
ええ、導入して終わりなんていうふうには決してならないのがAIエージェントの現実ですから、むしろそこからが本番というか。
はい。なので今日のミッションは明確です。AIエージェントを導入した後に残る、この使われた痕跡をどう読み解いて、次の改善につなげていくか。よし、このあたりをちょっと紐解いていきましょうか。
はい。このロゴの読み方を少し変えるだけで、見えてくる課題の解像度ってもう劇的に変わるはずなんですよ。
そうですよね。まずシステムがどう使われているかっていう点について、6月16日と17日にリリースされたクロードコードのアップデートの資料を見たんですけど。
バージョン2.11179と181ですね。
はい、それです。これ見て正直ちょっと拍手抜けしたというか。
ああ、ほう。というのは?
なんていうか、巨大な新機能がバーンと追加されたのかなって思ったら、macOSのブラウザ認証で出るエラー高度-600の修正とか、
はいはい。
あと、ネットワークが不安定な時にターミナルが真っ白になっちゃう問題の解消とか、なんかすごく地味なバグ修正ばっかりだなって。これ、なぜ今これが重要視されているんでしょうか。
なるほど。そこを非常に鋭い視点だと思いますよ。実はその地味な修正こそが、AIが現場にちゃんと定着するかの最大の分かれ目なんです。
分かれ目?
ええ。ユーザーが、あ、このAIは使えないなって見切りをつけるのって、高度な推論機能が足りないからじゃないんですよ。
ああ、じゃあ何が原因なんですか。
例えば、認証の待ち時間が長すぎるとか、エラーで画面がフリーズして、これ自分の作業データ消えちゃったんじゃないかなって不安になった瞬間なんですよね。
03:01
ああ、分かりますそれ。あれこれ、クリックしたらダメだったやつかなって一瞬冷や汗をかくあの瞬間ですよね。
そうそう、それです。
一度あれ経験すると、なんか次から入るのが億劫になっちゃうんですよね。
ええ、その通りです。だからクロードコードの開発チームは、巨大な新機能を追加するよりも、ログからユーザーがどこで操作を諦めたかっていう、つまり止まり方を徹底的に洗い出して直すことを優先したわけです。
止まり方、なるほど。
はい。失敗したときにいかに安心して元の状態に戻れるか。これが定着の鍵なんですよね。
面白いですね。機能の凄さより失敗したときの安心感ってことか。だとしたら、翌日の6月18日に出たCodexのバージョン0.14120のアップデートは、少し毛色が違うように見えますね。
ああ、そうですね。
こっちはローカル環境での単独の作業から、複数の環境をまたぐような運用に進化してますよね。
MCPサーバー対応とか、ちょっと専門的な言葉も並んでますけど、これってどういうことなんですか?
簡単に言うと、MCP、モデルコンテクストプロトコルっていうのは、AIが社内のデータベースとか外部のツールにアクセスするための標準的な接続企画みたいなものなんですね。
はいはい。
Codexは、今回このMCPサーバーへの対応とか、遠隔実行するときの暗号化を強化したんです。
つまり、AIが安全に社内のいろんなシステムと連携して、横断的に作業できる基盤が整ったってことですね。
なるほど。AIがアクセスできる道具箱が一気に大きくなったわけですね。
そういうことです。
これ聞いててふと思ったんですけど、なんか新しいレストランを開店したときの状況に似てません?
レストランですか?へえ、どういうことでしょう?
開店する前って、どれだけ豪華なメニューを作れるかとか、厨房の設備が完璧か、みたいなことばっかり気にするじゃないですか。
ええ、気になりますね。
でも、いざオープンしてたくさんのお客さんが入るようになると、本当に見るべきなのって、実際にどのメニューが注文されて、お皿に何が食べ残されたかですよね。
ああ、なるほど。確かに。
だから、コーデックスみたいに高機能な道具箱を用意しても、どのツールが使われて、どの機能が現場で放置されているかをログから見ないと意味がないんじゃないかなって。
いや、まさにその通りですね。その例えをさらに進めるなら、優秀なシェフって食べ残しを見たときに、ただメニューを増やすようなことはしないじゃないですか。
はいはい。
もし、最高級の指定器が残されている理由が、実は提供されたナイフが切れにくかったからだとしたら。
ああ、必要なのは新しい料理じゃなくて。
そう、ナイフを研ぐことですよね。
なるほど。
AIの運用も全く同じで、使われない高機能なプラグインをいくら足しても、現場の負担は減らないんです。
どこでエラーが起きたか、どこで待ち時間が発生したかっていう、その食べ残しの理由をログから見つけ出さないといけないんです。
06:05
システムのどこで利用者がつまずいたかを見極めるってことですね。
でも、もしシステム自体は完璧に動いていて、つまずいている原因が人間側にあったとしたらどうですかね。
人間側ですか?
システムの進化に人間の習慣が全然追いついていないケースというか。
ああ、そこは運用の最も難しい部分ですね。
技術って一瞬で切り替わりますけど、人間の習慣ってすぐには変わらないですからね。
ですよね。
で、その象徴ともいえるのが同じく6月18日のアンティグラビティへの切り替えだと思うんです。
はいはい、ありましたね。
資料によると個人向けのGoogle AI Proとかウルトラ、あと無料枠の利用先がそれまでのGemini CLIからアンティグラビティ CLIへ一斉に切り替わりましたよね。
これなんでわざわざ別のシステムに移行したんですか。
これは簡単に言えばAIのインフラの根本的なアップグレードがあったからです。
アンティグラビティっていうのはテキストとか画像、コードなんかの複数の情報を同時に処理する、マルチモーダルなタスクをより高速に処理できる新しい基盤なんですよ。
なるほど、エンジンが新しくなったってことですね。
ええ、だから開発者がコードを書くときに使うIDAの拡張機能とか、コマンドを直接打ち込むCLIも新しいアンティグラビティ用のものにアップデートする必要があったわけです。
エンジンが新しくなったから操作パネルも新しくしたと。
でもここで問題が起きてるんですよね。
ユーザーが少なからずいるっていう。
これちょっと意地悪な見方かもしれないんですけど、新しい手順書があるのに古いコマンドを打ち続けるなら、それは単にマニュアルを読んでないユーザーの責任じゃないですか。
ああ、確かに。そう言いたくなる気持ちはすごくわかります。
ただ、ログを分析する運用のプロとしてはユーザーが悪いっていう結論では絶対に終わらせないんですよ。
ええ、そうなんですか。
はい。重要なのは、なぜその人は未だに古い動線に流れてしまうのかっていう根本原因を探ることなんです。
根本原因。対マン以外の理由があるってことですか。
ええ。例えばですね、社内のイントラネットで検索したときに未だに古いウィキの手順書がトップに表示されちゃってるのかもしれないですよね。
ありそう。
あるいは、新しいコマンド名が長すぎて無意識に手に馴染んだ古い短いコマンドを打っちゃってるのかもしれないですし。
なるほど。じゃあ、ログに残った古いコマンドを使ったっていうエラー履歴はユーザーを責めるための証拠じゃなくて、
社内ウィキの検索アルゴリズムを直すべきだとか、新しいコマンドの短いエリア数を登録すべきだっていうシステム側の道しるべを立て直すためのヒントなんですね。
その通りです。で、その人間とAIの関わり方っていう意味では、ジンスパークの新しい動きもログの読み方を大きく変える事例ですよね。
ジンスパークAIワークスペース4.0が打ち出したコンセプトですね。どこでも働く従業員ってやつ。
09:03
ええ。これまでのAIって個人の画面の中にあるプロンプト入力欄っていうなんか孤立した部屋で使うものだったじゃないですか。
はいはい。自分とAIが一対一で向かい合う感じでした。
でもワークスペース化するってことは、AIがチームの共有ファイルとかタスクの進行の流れそのものに入り込んでくるってことなんですよ。
ということは、私たちが観測すべきログも、個人の入力履歴からチームのタスクのバトンパスに変わるってことですか?
まさにそうです。Aさんが資料を集めて、BさんがAIにドラフトを作らせて、Cさんがそれを修正して承認するみたいな。
この一連のリレーの中で、どこでAIがタスクから外されたかとか、誰がAIの利用を諦めて手動に切り替えたかっていう仕事の流れ全体における離脱ポイントを
チーム単位で観測する必要が出てくるんです。
チームのインフラとしてAIを見るわけですね。
でも、人間がそこまで不完全で古い習慣から抜け出せなかったり、途中でバトンを落としたりするなら、
いっそのこと、AI自身がログを読み取って、自分で勝手に使い方を学習して改善してくれればいいのにって思いませんか?
それは非常に魅力的なアイディアですね。
そして、実はまさにその自己改善ループを実装しようとしているのが、6月5日に大規模なアップデートを行ったハーメスエージェントなんです。
バージョン060ですね。
資料を見ると、セッションをまたいで記憶を保持したり、自律的にスキルを作成したり改善したりできるってありますけど、
これ、自動で賢くなるなら最高じゃないですか。
人間がいちいちログを分析する手間は省けますし。
一見するとその通りなんですけど、ただここで自己改善型AI特有の罠に気をつける必要があるんですよ。
例えばお掃除ロボットで例を例えると、私が床に靴下を脱ぎ捨てる悪い癖があったとして、
AIが気を利かせて靴下を吸い込んで片付けるっていうことを標準的なスキルとして学習しちゃうみたいなことですか?
あー、それ素晴らしい例ですね。その例をさらに進めると、お掃除ロボットが靴下を吸い込むことこそが正しい掃除なんだって認識してしまって、
家中から積極的に靴下を探して吸い込むようになっちゃうってことです。
うわー、それは困る。
AIエージェントの運用において、これ笑い話じゃないんですよ。
ユーザーがエラーを回避するためにやった非効率な迂回手順とか、
たまたま成功した例外的な処理をAIが正しい手順として学習してしまうと、
はいはい。
システム全体にノイズがたまって、結果的に効率が著しく落ちちゃうんです。
つまり、自動で学習できるからこそ、使われた痕跡を何に学習させないかっていうフィルターの役割が運用者には求められるんですね。
そうです。どれが高級的なスキルにすべき改善点で、どれが単なるノイズだから捨てるべきか。
その選別が絶対に不可欠になります。
12:01
なるほどな。ただ、AIに何を学習させるかっていうログの選別の前に、
そもそもAIがどこまでログやデータにアクセスしていいのかっていう大前提の話も必要ですよね。
ええ、おっしゃる通りです。
ちょうど6月13日のテッククランチの報道で気になるニュースがありました。
これ番組として特定の政治的な立場を取るものでは全くないんですが、純粋に資料にある事実としてお伝えすると、
メタが約20億ドルとされるマナスとの契約を解消してデータ共有を止める方向に動いているという報道ですね。
理由は中国当局からのデータ要求に対する懸念だとされています。
この報道が実務レベルで私たちに突きつけているのは、データ協会の脆弱性という問題なんです。
データ協会、これはAIがアクセスできる社内システムとか連携先の情報の壁のことですよね。
ええ、AIエージェントって非常に強力で、社内の奥深いログとか機密データにもアクセスして学習する能力を持っているじゃないですか。
はい。
だからこそ今回のように、組織の所有権とか管轄、プラットフォームとの関係性みたいな組織の境界に変化があった際、
真っ先に確認すべきなのがこのデータ協会なんです。
ということは、AIがどんなログを残しているかなってのんきに分析する前に、まず今このAIはどこまで見に行っていい状態なのかを再確認しないと。
ええ。
ログを収集する行為そのものが致命的な情報漏洩につながりかねないってことですか。
完全にその通りです。
共有済みデータの扱いはどう変わったか、内部システムやなどアクセスは適切に遮断されているか。
この安全な壁の位置を確認する前に、自己改善ループを回すのは、ブレーキの壊れた車を走らせるようなものです。
安全な壁の位置を確認する、これが大前提ですね。
さて、データ協会の安全性を確保した上で、日々の失敗のログをどうやって安全に集めて次のアクションにつなげるか、これが今日の最後のパズルピースになります。
はい、ここで重要になってくるのが、6月16日にリリースされたオープンクローのバージョン2026.6.8と、それに先立つ6.6のアップデートで強調されているフェールクローズドっていう設計思想ですね。
フェールクローズド、直訳すると閉じて失敗するんですけど、これは例えば停電が起きたときにセキュリティドアが開いたままになるんじゃなくて、安全のためにロックされた状態になるみたいな考え方ですよね。
正確な理解です。AIエージェントにおけるフェールクローズドっていうのは、権限が曖昧なアクセスとか承認のタイムアウトが発生した際に、システムがとりあえず通してみるとか、無反応のまま放置するんじゃなくて、明確に処理を遮断して拒否したっていう事実をはっきりとログに残す設計のことを指します。
明確に止まることで、初めてなぜ止まったかがはっきりとわかるわけですね。
もしシステムが曖昧な挙動をしてしまうと、ログには何か失敗したっていうノイズしか残らないんですよ。
それじゃ分析しようがないですね。
15:01
そうなんです。でもフェールクローズドの設計で安全にバシッと止まってくれれば、このユーザーの権限設定が狭すぎたから止まったのか、ワークフローの承認者の反応が遅すぎたからタイムアウトしたのかっていう明確な自由がデータとして手に入ります。
なるほど。ただ動かなかったって不満じゃなくて、次にどうすればいいかがわかる実用的なデータに変わるんですね。
そうです。失敗を安全で有用なデータに変える。これが運用における最強の武器になります。
ここまでの話を総括すると、AIエージェントを導入した後、私たちってついグラフの利用回数とか成功率が右肩上がりになるのを見て安心しがちなんですけど、それは大きな間違いだっていうことですね。
はい。利用回数の数字を集めること自体が目的になっちゃいけないんです。ログを見るときはその数字やエラーの履歴を見て、次の一手として何を変えるか。
マニュアルの案内文を直すのか、設定画面のUIを変えるのか、それとも不要な権限を削るのか、それを決めるためにログを見るべきなんです。
失敗の痕跡を読み解いて、小さな修正を積み重ねる。そうやって初めてAIエージェントは単なる新しいソフトウェアから組織の血肉となる業務基盤へと進化していくわけですね。
いやー、導入してからが本当のスタートだっていうのが今日のお話で痛いほどよくわかりました。
そうですね。
さて、リスナーのあなたは今日のこの深掘りを聞いてどう感じたでしょうか。AIエージェントの運用って花々しい成功報告で終わるものじゃなくて、泥臭い失敗の痕跡を拾い集めるところから始まるんですよね。システムとの向き合い方が少し変わったんじゃないでしょうか。
ログの一つ一つがユーザーが発している声なきフィードバックですからね。それをどう受け止めるかが私たちの腕の見せ所だと思います。
では最後にあなたに一つちょっと挑発的な問いを投げかけてお別れしたいと思います。
何でしょうか。
今日学んだことを踏まえて想像してみてください。もし未来のAIエージェントがあなたの失敗ログを完璧に読み取って、あなたが今日AIを使わなかった本当の理由とか、めんどくさくて手動でやってしまった背景まで完全に察知して、
はいはい。
あなたが何も言わないうちに先回りしてワークフローの改善案を勝手に実行してくれたとしたら、
うわーすごいですねそれ。
それってまた私たちにとって究極の便利ツールでしょうか。それともせめてを見通してくるちょっとおせっかいすぎる同僚でしょうか。
それはまた非常に人間くさくて議論が分かれそうなテーマですね。
ですよね。便利さと心地よさの境界線、考え出すと夜も眠れなくなりそうです。あなたがどう感じるかぜひ考えてみてくださいね。
それでは今回の深掘りはこの辺で。引き続き良い一日をお過ごしください。
次回もまたこの場所でお会いしましょう。
