モデル小型化が新たなエッジになる

今エージェントアーキテクチャで最も興味深い変化は、より大きなモデルではない。エージェントが実際に動作する場所で動く、小型で専門特化したモデルの実用性が高まっていることだ。予測モデルが500万パラメータまで4サイズで提供され、CPU効率とゼロショット対応を明確に設計方針としている時点で、開発者へのメッセージは明白だ。狭いタスクで最先端の挙動を得るためにデータセンターはもう必要ない [1]。

これはエージェントの定義を変える。この2年間、意味のある能力はすべて大規模なフロンティアモデルを経由しなければならないという前提が標準だった。レイテンシ、コスト、プライバシーのトレードオフを受け入れていたのは、代替手段がなかったからだ。CPUで動く500万パラメータのモデルは、その前提を壊す。エージェントの予測コンポーネントがアプリケーションの他の部分と同じプロセス内に存在でき、ネットワーク呼び出しもトークン課金もデータの外部送信も不要になることを意味する。

ガバナンスの観点

これは、一見しただけでは分からない形でガバナンスに影響する。モデルがローカルで動く場合、評価のあり方が変わる。デプロイ前に自分のデータで、自分の環境でテストできる。正確なバージョンを固定できる。モデルが何を見て何を出力するかを監査できる。モデルが勝手に変わりうるリモートAPIの場合、こうしたことはどれも容易ではない。

Googleが最近公開したGemini 4 Argonの安全性ドキュメントは、大規模モデルを広く公開できるほど安全にするためにどれだけの作業が必要かを改めて示している [2]。その作業は必要だが、同時に思い出させてくれる。フロンティアモデルに委託する能力の一つひとつに、自分では制御できないガバナンス面が付いてくる。小型でローカル、監査可能なモデルに移行すればするほど、その面は小さくなる。

エージェント境界としてのブラウザ

ChatGPTのChrome拡張機能に関するニュースは、反対側から同じ方向を指している。この拡張機能は開いているタブを読み取り、表示中のページにチャットを持ち込めるようになった [3]。これは利便性の機能だが、エージェントのコンテキストがどこにあるかについての表明でもある。ブラウザはエージェント支援作業の主要インターフェースになりつつあり、重要なデータはすでにそこにある。開いているタブ、読んでいるページ、進行中のタスクだ。

開発者にとって、これは警告だ。エージェントのコンテキストがタブを読むブラウザ拡張機能から来るなら、同意、データ最小化、ユーザー理解にとってそれが何を意味するかを慎重に考える必要がある。ある機能のために拡張機能をインストールしたユーザーは、自分の閲覧内容すべてが見えるようになることに気づいていないかもしれない。これはブラウザ統合を避ける理由にはならない。境界を明示し、挙動を検査可能にする理由だ。

今何を構築すべきか

実践的な教訓は、自分のエージェントのアーキテクチャを見て、どの能力が本当にフロンティアモデルを必要とするかを問うことだ。予測、分類、抽出、ルーティング——これらは、正直に評価でき、ネットワーク依存なしでデプロイできる小型ローカルモデルとしてますます利用可能になっている。大規模モデルは、コストとガバナンス負担に見合う、真にオープンエンドな推論タスクのために取っておく。

1つのコンポーネントから始める。現在リモートAPIを経由している単一の能力を取り上げ、小型モデルがローカルで処理できるか試す。自分のデータに対してレイテンシ、コスト、精度を測定する。十分なら、攻撃面、請求額、制御できないベンダーへの依存を減らしたことになる。これは妥協ではない。この分野が進んでいる方向だ。