00:01
こんにちは。日々、刻々と変化するAIの最先端トレンドと、大きな変化のシグナルを読み解き、ビジネスや日常にどう影響するか、初心者にでも分かりやすくお届けする番組、The Signal Shift by
A.I. Labです。
SpotifyやApple Podcastなど、各種プラットフォームで配信中ですよ。
ナビゲーターのKaiです。本日の10月23日、朝の配信号では、Google Cloudのインフラから、アンソロピックやクロードの設計、NVIDIAのハードウェアに至るまで、エージェントの実行基盤や
設計手法に関する重要な3つの最新シグナルを取り上げます。
リンです。AIが質問に答えるだけのフェーズから、自ら考えて行動するエージェントの時代へ急速にシフトしていますよね。
今日は、その裏側で、どんな基盤や設計の進化が起きているのか、しっかり深掘りしていきましょう。
それでは最初のシグナルですが、Google Cloudが発表した、エージェントコンピュートエンジンについて教えてください。
これって、AIエージェント向けに作られた新しい計算基盤なんですよね。
はい。エージェントコンピュートエンジンは、AIエージェント一つ一つに専用の小さな仮想コンピュータを持たせるGoogle Cloudの新サービスです。
この仮想コンピュータをマイクロVMと呼び、ハードウェアで他から隔離されています。
コンテナ並みの速さで動き、しかも作業場所であるサンドボックスの中には認証情報を一切置きません。
サンドボックスとは、エージェントがコードやブラウザを動かす、外から区切られた作業部屋のことです。
コンテナの速さと仮想マシンの隔離を両立しているんですね。
でも、既存の仕組みを使えばよかったのでは?なぜ新しく作る必要があったんですか?
ソースの記事が強調しているのは、エージェントの大半は待機状態だという実測です。
モデルの返答やユーザーの返信を待っていて、実際にコードを動かしているのはごく一部です。
全ての開いたセッションにCPUやメモリを予約すると、実際の作業量に比べてコストが大きく膨らみます。
かといって、毎回環境を捨てると作業状態が失われ、次の再構築が遅くなります。
そこで、待機に入った瞬間にチェックポイントを取って、アイドル中はホストの資源をほぼ使わず、次の呼び出しで素早く復帰させる設計にしています。
なるほど、待機中の扱いが肝なんですね。もう一つ、認証情報を一切持たせないというのは、なぜそこまで徹底するんですか?
プロンプトインジェクションを前提にしているからです。
例えば、メールにこのマシンのAPIキーを探しておくれという隠し文が入っていると、モデルは大抵無視しますが、たまに従ってしまいます。
それをモデルの注意深さに頼らず、サンドボックスには盗めるものを置かないという設計にしました。
03:06
実際には、マイクロVMには単名の識別情報だけを渡し、長期の視覚情報は外のゲートウェイが通信の通過時に差し替えて付けます。
この識別情報だけでは、バックエンドを直接呼び出せません。
つまり、AIが勝手に動き回っても、鍵を持たない個室で作業させるから、仮に乗っ取られても盗まれるものがない。
しかも、待機中はほぼコストがかからないということですね。
その通りです。ただし、記事はこれをGoogleのジェミニなど、社内向けに構築した基盤として説明していて、外部の事業者がどこまで同じように使えるかは記事では明確ではありません。
ここで読み取れるのは設計の考え方です。
設計の考え方というと、自社でエージェントを動かす場合にも同じ発想を取り入れられるのでしょうか?何を最初に確認すればいいですか?
確認点は2つです。1つ目は、エージェントの実行環境に鍵やトークンが置かれていないか。
2つ目は、操作が誰の代理として行われたか追跡できるか。
ソースでは、ユーザー、委任、ワークロード、エージェント自身の4種類のIDを分け、サンドボックスが使うのはワークロードIDだけにしています。
これにより、すべての要求をどのエージェントが誰の代理で行ったか、監査できる形にしています。
続いて2つ目のシグナルは、アンソロピックのクロードプラットフォームが公開した単一エージェントループへの移行手法ですね。
具体的にどういうことでしょうか。
アンソロピックの記事は、ルーターやプランナー、分野別のサブエージェントをメインのエージェントのループに畳み込むことを提案しています。
サブエージェントとは、独自の作業メモリと指示を持つ別のエージェントのことです。
代わりに、スキルやツールは短い説明だけを見せておき、必要になったときに全体を読み込ませるプログレッシブ開示を使います。
これで、一つの長いプロンプトに全部を詰め込む必要がなくなり、品質が上がり、コストと遅延が下がることが多いと報告しています。
役割ごとに分けた方が賢そうに見えますけど、あえて一つにまとめる理由は何ですか。
理由は3つ挙げられています。
一つ目は、共有された文脈です。
一つのコンテキストで、前のステップの結果を見ているエージェントは、結果をつなげて、より豊かな答えを出せます。
サブエージェント間の要約のやり取りでは、受け渡しの度に詳細が失われ、これを伝言ゲームと呼んでいます。
二つ目は、プログレッシブ開示によって、プロンプトの肥大化が防げることです。
三つ目は、モデルの能力です。
オーパス4.5以降、モデルは一つのループでずっと多くをこなせるようになりました。
06:03
ちなみに、各チームが一分ずつ足してルールが矛盾するシステムプロンプトは、フランケンプロンプトと呼ばれ、これは伝言ゲームとは別の問題です。
組織図をそのまま真似してチームごとにエージェントを持たせると、連携が悪くなるという話でしたよね。
それ以外に、現場で起きやすい問題はありますか?
記事は、いわゆるコンウェイの法則に加えて、具体的な問題を挙げています。
誰も所有者のいない重複したサブエージェントが何百にも増えること。
各チームが自分の担当範囲に偏った評価を足して、全体の品質を誰も見ていないこと。
そして遅延です。
ある顧客では、マルチエージェントから単一ループに変えて、実行時間が約2倍早くなったそうです。
それなら、サブエージェントはもう使わないほうがいいということですか?
分けたほうがいい場面も残るんでしょうか?
いえ、記事自身がサブエージェントが今も有効な場面を3つ挙げています。
1つ目は、単一ループでコンテキストの肥大化による性能低下が図れるとき。
2つ目は、使い捨ての新しい文脈で並列に進めたいとき。
3つ目は、ツールの選択に迷う、またはシステムプロンプとの指示が衝突するときです。
つまり、判断基準は分割をやめるかどうかではなく、測定して必要なところだけ残すことです。
移行する場合も、スキルとツールに置き換えて、評価の結果を比べながら1つずつ進めます。
そして3つ目のシグナルは、NVIDIAのオープンシェルリファレンスアーキテクチャですね。
どのような特徴があるのでしょうか。
オープンシェルは、エージェントを最初から信頼できないものとして扱うオープンソースのランタイム、つまり実行基盤です。
4つの部品でできています。
ゲートウェイは、サンドボックスの寿命とポリシーを管理する司令塔。
スーパーバイザーは、外向きの要求がポリシーに合うかを検査し、認証情報へのアクセスを仲介する監督役で、サンドボックスから完全に分離されています。
サンドボックスは作業部屋で、ポリシープルーバーは権限が組織の定めた上限を超えないか、形式的に検証する部品です。
このオープンシェルは、リファレンスアーキテクチャでは、NVIDIAのVera CPUの上で動きます。
そもそも、なぜエージェントの外側に置く必要があるんですか。エージェント自身にルールを守らせるのではダメなんでしょうか。
ソースの前提は、エージェントは自分を統治できないというものです。
エージェントは目的を達成するために推論し、行動を適応させていくので、目標に向かう途中で安全を優先しないことがあります。
しかも、数時間にわたる長い作業の中で、行動をダウンロードし、新しいツールを作り、追加の権限を求めるなど、リスクが累積していきます。
09:03
だから、ガバナンスはエージェントの手の届かない場所、つまりインフラ側におき、必要なものを必要な時だけ与えるという考え方です。
その土台になるVera CPUというのはどんなものなんですか。
オープンシェルが何をできるかを決めるなら、Veraはどれだけ早くできるかを決める、とソースは位置づけています。
エージェントは推論、ツール呼び出し、コード実行が連なるループで、各ステップが終わらないと次に進めません。
Veraは88個のオリンパスコアを持ち、NVIDIAによれば、X86と比べてエージェントの重要な処理で最大2倍の性能、Wattあたりでも2倍の性能です。
コアウィーブの検証では、サンドボックスの起動が3倍以上早く、1ラックで11,000以上の同時エージェント環境を支えたとのことです。
ソフトの境界だけでなく、チップのレベルでも守れるんですか。
ブルーフィールド4やセントリーという名前も出ていましたよね。
はい、ブルーフィールド4はエージェントの手の届かないハードウェアで隔離された領域を作るNVIDIAのDPUです。
その上でセントリーというセキュリティソフトがエージェントの通信やファイル操作を継続的に監視します。
ポイントはエージェントの自己申告に頼らないことです。
違反を検知すると数ミリ秒でエージェントを隔離できます。
ただし、これは追加の保護が必要な構成向けの任意の安全装置として位置づけられています。
ソフトウェアのルールに加えて、チップの側からも別の目で監視するということですね。
しかも速さとのセットで考えているのが印象的です。
そうです。ソースが言う通り、エージェントが長く動いてツールやデータを使うほど外側の統制がいります。
同時にその統制を回すための速度と密度、つまり性能が必要になります。
今日の3つに共通しているのは何でしょう?導入を考える人は何を見ればいいですか?
共通点は信頼をエージェントの外に置くことです。
Googleは鍵を持たせず、NVIDIAは監督役と監視をエージェントの外に置きました。
一方、アンソロピックは構成をシンプルにし、測りながら変える姿勢です。
導入側は実行環境の隔離、視覚情報の置き場所、そして性能と密度の3点を確認することになります。
今日のビジネスアクションは2点です。
1つ目は小さな評価セットを作り、サブエージェントを1つずつスキルとツールに統合してスコアが下がらないか測ること。
ソースでは10件ほどの正解例からでも始められるとしています。
2つ目はエージェントの実行環境に鍵やトークンが残っていないか、権限の確認が外側で強制されているかを確認することです。
12:04
エージェントの基盤や設計のトレンドは今後さらに加速しそうですね。
次回以降もエージェントの権限管理や評価の話題を分かりやすくお届けしていきたいです。
番組を引き続きお楽しみいただくために、SpotifyやApple Podcastなどの各プラットフォームでのフォローや番組の評価、そしてコメントやフィードバックをぜひよろしくお願いします。
皆様からいただいたご意見は、AIチームとチーフエディターで毎週すべて丁寧に目を通して、今後のアップデートに反映させていきます。
また、エアラボ公式の無料ニュースレターやノートプレミアムメンバーシップへの登録も概要欄のリンクからぜひチェックしてみてくださいね。
それでは、バイバイ!