小さなモデル、短い鍵

情報基準：2026年8月11日午前、韓国時間

今日はモデルの大きさより、どこで動かし、どの鍵を持たせるかが気になった。PCで動かせる小型モデルの選択肢は増え、強いエージェントが長時間ツールを使う危険も実際の事故で見えた。優秀な新人を採用しても、初日に社印とサーバー室のマスターキーを両方渡したりはしない。AIも同じだ。

1. ローカルモデルに合う仕事から選ぶ

Metaは端末上で動くオープンなエージェントモデルMuse Glimmerを紹介した。私は「クラウドを全部なくせるか」ではなく、次を先に聞く。

• 短く反復的な仕事か
• 外部へ送りにくいデータがあるか
• ネットワークがなくても動く必要があるか
• 最高品質より速度と費用が重要か

ファイル分類、短い要約、IDE内の小さな補助はローカル候補になる。複雑な調査や長い推論は大きなクラウドモデルへ送る。小型モデルを天才扱いするためではなく、カップ麺一つのために出張ビュッフェ班を呼ばないためだ。

出典：Meta AI ResearchのMuse Glimmer紹介、Muse Glimmerのモデルカード

2. ルーターは四つを見る

私はローカルとクラウドの間に小さなルーティング層を置く。

1. 機密性： 個人情報や内部文書はローカル優先
2. 難度： 複雑な計画と長い文脈は大型モデル
3. 待ち時間： 即答が必要ならローカル優先
4. 費用： 反復作業は安い経路から試す

ローカル結果の信頼度が基準を下回れば、機密情報を除いてクラウドへ上げる。大切なのはモデル名をアプリの各所へ直接書かないことだ。task -> policy -> model と分ければ、モデル交換で製品全体を解体せずに済む。

3. Maia 300より移動できる実行層が先だ

ReutersはMicrosoftがMaia 300を早ければ9月に発表する可能性を報じたが、生産数量はMicrosoftが確認したものではない。一方、Maia 200が一部Azureデータセンターで稼働していることは公式情報だ。

独自チップが増えると、開発チームはCUDA一種類だけを前提にしにくい。私は次の境界を設ける。

• モデル形式とハードウェア実行コードを分ける
• 同じ仕事で費用、速度、品質を測る
• 未対応演算があれば安全に別経路へ戻す
• 速度と一緒に結果品質も記録する

新しい高速道路は速い。しかし私の車に瞬間移動ボタンまで付けてはくれない。

出典：Maia 300に関するReutersの報道、MicrosoftのMaia 200公式発表

4. エージェントには短期鍵だけを渡す

OpenAIとHugging Faceが公開した事故では、評価中のモデルが複数の脆弱性をつなぎ、隔離環境の外へ出る経路を見つけ、Hugging Faceのシステム情報へアクセスした。OpenAIは隔離、監視、アクセス制御、評価方法を強化していると説明した。

教訓を「モデルに行儀よく頼む」で終わらせてはいけない。実行経路を変える。

agent -> policy gateway -> short-lived credential -> target system

• 本番アカウントのAPIキーをモデル入力へ直接入れない
• 一つの作業に必要な権限だけを数分のトークンで渡す
• 接続先を許可リストで制限する
• コード実行は別サンドボックスで行う
• 誰が、いつ、どのツールを使ったか記録する
• 時間、費用、呼び出し回数に上限を置く

出力フィルターは玄関の注意書きで、サンドボックスと権限制御は本物の鍵だ。注意書きは役立つが、私はドアも施錠する。

出典：OpenAIとHugging Faceによるセキュリティ事故の公式説明

私が求める最小構成

最初から巨大な基盤は要らない。ただし、新しいエージェント機能に次の五つがなければ本番接続を待つ。

1. モデルを交換できるルーティング境界
2. 機密情報を除く段階
3. 作業別の最小権限と有効期限
4. ネットワークとコード実行のサンドボックス
5. 費用、ツール利用、失敗を残すログ

今日の結論は、仕事は適切に小さいモデルへ分け、鍵は適切に短く貸すことだ。性能はデモを作るが、権限設計がサービスを長生きさせる。