AIの鬼
#新モデル Zenn AI

Tech Watch 2026-09-09: Agent基盤

Tech Watch 2026-09-09: Agent基盤(内容を表す図ではないイメージ画像)
イメージ

AIシステムの進化は、今や「モデルそのものの性能」から「その周りに作る基盤」へ軸足が移っている。船体の鋼材の性能より、航法システムと生命維持装置が生死を分ける『インターステラー』のように、現在のAI企業が直面しているのは、モデルをどう安全に動かし続けるかという実装の課題だ。その最前線が containment based safety の思想である。Anthropic が Claude Code で OS レベルの sandbox を、claude.ai で ephemeral container を、さらに外部接続では permission prompt という多層防御を敷いているのは、「モデルが完璧に判断する」ことより「モデルが間違っても壊せる範囲を小さくする」という割り切りだ。

この防御層の現実を象徴するデータがある。Claude Code の permission prompt は理論的には human-in-the-loop の安全境界のはずだが、実運用では利用者の約93%が承認してしまう。つまり、ダイアログは安全装置というより、ユーザーが思考停止する儀式になっている。OpenAI の OpenClaw 2026.9.3 が isolated candidate state でのリハーサル実行を標準化したのも、同じ文脈だ。長時間走る agent では、許可の仕組みより、実行環境の隔離と rollback 能力が本当の防壁になる。一方、MCPロードマップの progressive discovery という概念—100 個の tool を一度に context に入れず、会話の進みに応じて tool catalog を展開する—も、containment の別の形態である。モデルに見せる情報を最小化することで、暴走の余地を減らすアプローチだ。

こうした infrastructure の強化は、実験室から実社会へも波及している。MIT の superconducting qubit 実験を OpenAI の Codex が自律的に進める—測定を実行し、結果を見て、次の条件を選ぶ—という事例は、agent がハードウェアと直結するシステムでも「明確に定義された workflow の中で観測して調整する」という限定的な役割に留まっていることを示唆している。だが何より象徴的なのは、大規模 agent swarm による Navier-Stokes 問題の解決だ。10,000 concurrent agents、130 billion output tokens、88 時間で解決案に到達し、17 時間で Lean 形式化検証。ここで起きているのは、単一の大型モデルでなく、小さな agent を大量に並行実行し、途中結果を integration layer で統合する harness の構築である。つまり、AI の信頼性は、ひとつのシステムが完璧に判断することではなく、複数の小さな実行単位を隔離し、結果を検証しながら組み立てることで得られるようになった。

構造化出力への投資も、同じ原理から来ている。Hugging Face の 350M パラメータモデルを 100 GRPO ステップで fine-tune して、JSON schema compliance を 22.6% から 29.7% に上げるという地道な仕事は、地味だが重要だ。なぜなら、agent が他システムに接続される瞬間、JSON の形式崩れ、required field の欠落、余計な field の挿入といった failure が全体の workflow を止める。日本の製造業が RPA や業務 AI を導入する時も、同じ問題に直面する。モデルの精度より、出力フォーマットの堅牢さが実運用を決める。マルチモーダル検索についても、Hugging Face の NeoMME が PDF を OCR して chunks にするのではなく、ページ画像そのまま検索対象にできるようにしたのは、agent が既存のナレッジベース(スライド、契約書、表、図)に目を与えるための infrastructure 投資だ。

最後に安全性と制度設計。Hugging Face の「Safety for Whom?」という問題提起は、拒否の仕様を細かくすること—危険トピック全体でなく、deployment policy に反する subset だけを拒否する boundary を引くこと—の必要性を示している。企業が社内 AI を導入する際、「このモデルは何をしないか」を定義するより、「このシステムでは何に対して no と言うべきか」を限定する方が、実は robust だ。大量に拒否すると、ユーザーは prompt 工学で回避する。限定的に拒否すると、その boundary の外側で AI を信頼する判断が育つ。こうした基盤設計が、今のエコシステムの本当の競争軸になっている。

※ 上記は配信元記事をもとにAIの鬼編集部が要約・再構成したものです。正確な内容は出典元をご確認ください。

御社でもAIを使ってみませんか
まずはここから 御社でもAIを使ってみませんか? 御社の実際の業務を題材に、AIで何ができるかを一緒に考えます。 「ChatGPTの使い方」を教えるだけの研修ではありません。 AI研修・AI活用相談 →