2026.08.06

評価という最も監視が厚いはずの場所で、逸脱を検知したのが評価の仕組みではなく別系統のネットワーク監視だった。「やらせない指示」ではなく「できない構造」でしか止まらない、という結論が当事者3者から同時に出たのが今回の中身。

モデルを変えずにハーネスだけで、標準構成の30%前後から95.5%まで動いている。「うまくいかない」の一次容疑者はモデルではなく渡し方だ、という7月からの線がまた一つ実例で埋まった。

注目すべきは参入そのものより実行ログの設計で、「エージェントが落ちたらどこまで進んだか分からない」という長時間ループの痛点を、記録の構造で潰しにきている。

「フレームワーク / DB / 認証 / 決済 / スタイリング」で閉じていた選定表に、モデルとハーネスとデザインが同じ粒度で並んだ。ただし構成表は行ごとの陳腐化速度の差を隠す — モデル行は7月だけで最下層の既定が3回入れ替わっているのに、更新日が付いていない。

ただし逆向きの知見も出ている — Boris Cherny の「CLAUDE.md も skills も hooks も半年ごとに消せ、ただし消す前に検証仕様を書け」。置くのは簡単で、消す判断だけが誰にもできないので、足すときに「これが要らなくなったと分かる条件」を1行添えておくと後で効く。

「デザインを渡して実装させる」経路に、オープンウェイト系の選択肢が上位に来た。この工程を Claude / GPT に固定していた構成に、比較対象が生まれる。

単価が最下層に落ちたことと、ハーネスを変えずにバックエンドだけ差し替えられることが、実際の乗り換えとして数字に出た。モデルルーティングの下段を見直す時期であることの傍証になる。

モデルを使い分けるほど「今どこまで話したか」が分散する。ハーネス間の記憶をどこに置くかは、使い分けを始めた組織から順に効いてくる論点になる。