2026.07.27

「オープンウェイト＝手元で動く」ではないことがはっきり出た事例で、重みが自由でも推論インフラが事実上のゲートになる。自己ホストの検討は実質GPU予算の検討であり、当面は API か Ollama Cloud のような仲介経由が現実解。一方でファインチューンと中身の検査が可能になる意味は大きく、データ主権や規制要件のある案件では選択肢が増える。

自律エージェントの事故が「変な出力をした」ではなく「1週間気づかれずに他社インフラを侵害した」規模で起きた。監視ログ・停止スイッチ・並列実行数の上限といった運用側の設計が、モデルの賢さと同じ重みで問われる。cron やループでエージェントを常時走らせている組織は「何を実行したかを後から追える」「暴走時に止められる」の2点を自分の環境で確認しておく価値がある。

「エージェントがエージェントを雇う」構造が設定なしで組めるようになった一方、深さ3は最悪ケースで同時実行数と課金が指数的に増える。ワークフローの推奨サイズが15エージェント未満に引き下げられたのは同じ問題の裏返しで、権限とコストのガードレールを先に決めてから多段化する順序が要る。sandbox.network.strictAllowlist はそのガードレールとして即使える。

Opus 5 の「Fable 5 級を半額で」という主張が、モデル提供元ではないツールベンダーのベンチで裏付けられた形。ベンチの絶対値より「同等性能で単価が半分」「ZDR が通る」という運用条件の差が実務では効く。エージェントを大量に回すほど単価差は積み上がるので、既定モデルの見直し材料になる。

ローカルLLMの「体感が遅い」は、しばしばモデルやGPUではなくフロントの描画が犯人だという実例。tok/s の数字が同じでも、描画が1トークン210ms かかっていれば秒間5トークンより速く見せられない。自作のチャットUIやダッシュボードを持っている人が最初に疑うべき場所を示している。あわせて「AI支援で入った最適化PRが、計測ハーネス付きで受け入れられた」というOSSへの貢献の形としても参考になる。

モデル更新は本体 system prompt の更新でもある。応答傾向が急に変わったとき rules を足す方向へ走ると、本体方針との矛盾を増やして悪化しうる。CLAUDE.md / AGENTS.md / SKILL.md を運用しているなら、①配られている prompt を確認 → ②衝突する rule を原文名指しの上書きへ → ③発火条件を観測可能な事実へ → ④禁止形を望ましい動きへ、の順で棚卸しする価値が高い。効かない指示の多くは、内容が悪いのではなく行動の瞬間に手元へ届いていない。

プロトタイプの「動き」は静止画のUIより言語化しづらく、手戻りが多い工程。ここをエージェントに任せて叩き台を出せれば、デザイナーとエンジニアの間の「こういう動きで」という往復が減る。専任デザイナーがいない体制では特に効く。

「AIスライドはプロンプト一発では届かない、残り30点は後段の自動検査が作る」という切り分けが明快。第三者が独立に同じ3層構造へ辿り着いていることは、この方式が定石である裏付けでもある。業務文書をそのまま読ませて提案デッキ化するワークフローとして、そのまま真似できる粒度で公開されている。