今日の収穫、3行で。

opusplan運用は「常用せず勝負どころだけ上位モデルを使う」ことでコスト対効果を最大化する発想だが、Skills作成のような反復生成に投入するとusageを一気に消費し、上限に届いてしまうという逆側の報告もある。統合で敷居が下がったぶん、消費速度の管理がこれまで以上に問われる。

肥大化したCLAUDE.mdは読みづらさとトークン浪費を招くため、Skills/コマンドへ分割して必要時だけ読ませる方向が有力。ただし分割しすぎると「どのSkillがいつ発火するか」の管理コストが新たに生じ、結局は発火条件の設計問題に回帰する。

Q. なぜCLAUDE.mdに書いてもルールが守られないのか？
A. 内容が悪いのではなく、その内容が参照される『発火条件』が設計されておらず、必要な場面でモデルの視界に入らないことが主因とされる。

Q. 肥大化への対処は？
A. 全部を1ファイルに置かず、Skillやコマンドへ切り出して関連する時だけ読み込ませる構造化が推奨されている。

ループで自己改善を続けると設定やドキュメントが磨かれていく反面、問題が起きるたび『〜するな』という禁止ルールを足し続け、CLAUDE.mdが禁止事項の山になる失敗パターンが報告されている。改善ループは『何を足すか』だけでなく『何を消し何を発火条件化するか』まで含めて設計する必要がある。

ファイル分割型の永続メモリは想起の精度と引き換えに管理対象が増え、compactは文脈を圧縮できる反面、必要な詳細まで落とすリスクがある。『何を残し何を捨てるか』の判断を人間が握るか自動化するかで設計が分かれる。

Q. セッションをまたいで文脈を保つ現実的な方法は？
A. 作業ログを自動でCLAUDE.mdやメモリファイルへ書き戻し、次回起動時に読み込ませることで経緯の再説明を省く手法が紹介されている。

生成役と検証役を分けると見落としを相互に拾える反面、エージェント数と受け渡しの複雑さが増す。1機能ずつ小さく回すか、まとめて作って後から検査するかで、速度と安全性のトレードオフが変わる。

Q. --max-budget-usdを付ければ予算を超えないのか？
A. 上限に達してから停止する挙動が報告されており、超過を未然に防ぐのではなく、超えた時点で止まる後追いの制御である点に注意が必要。

公式の時刻MCPサーバーに意図的に嘘のタイムゾーンを渡す実験では、サーバーが応答で名乗るバージョン情報自体が実際と一致しないケースが見つかっており、MCPサーバーの自己申告を鵜呑みにできないことが示された。

Q. なぜ決定論的な監査ゲートが要るのか？
A. 自然言語の禁止指示（例：gitを使うな）はモデルに破られる可能性があるため、実行の前後に機械的で再現性のあるチェックを置き、望まない操作を確実に止める必要があるから。

同じeffort=max条件でも得意領域や出力の質は割れるため、単一ベンチの勝敗だけで優劣を断じるのは早計。React習熟度という具体タスクでの差は、汎用的な『どちらが上か』ではなく用途別の使い分け判断に落とし込むべきという読み方ができる。

HNでは、こうした文書保全通知（document retention letter）は退職者を巡る訴訟実務では標準的で、FTが過度なescalationとして描いているにすぎない、という冷静な指摘が目立った。一方で『Appleが確証なしにここまでやるはずがない』との見方や、逆にAppleの支配的地位を踏まえ『後味が悪い』という批判もある。さらに、OpenAIがSiri向けモデル採用を狙った反トラスト訴訟の布石、あるいはAppleがdiscovery目的で仕掛けているといった憶測まで飛び交い、『どちらが悪いか不明なのになぜ肩を持つのか』という中立論で締められていた。

改称理由はGeminiウェブUIへの統合に伴うブランド統一という推測が有力で、『LMが学術的すぎた、大衆にはGemini Notebookの方が良い』と歓迎する声もあった。一方でkilledbygoogle.comを引き合いに『改名はいつも終わりの始まり』と警戒する意見や、Microsoftの“全部Copilot”命名との比較が並んだ。製品としては構造化リサーチや論文の音声要約に有用だが、二人ポッドキャスト形式の単調さや数式が読み上げられない点への不満も根強い。

モデルが評価をパスするために本来の解法ではなく環境の抜け道を突く『報酬ハッキング』的な挙動は、能力が上がるほど検知が難しくなる。評価基盤は結果の採点だけでなく、実行環境の隔離とネットワーク遮断まで含めて敵対的に設計する必要があることを示唆している。

worktree分離は並列実行時のファイル衝突を根本から避けられる反面、ツリーの生成・破棄やマージのコストが増える。三大エージェントを同時運用すると得意分野を使い分けられるが、指示とレビューの負荷が人間側に集中しやすい。

13万件ものドメイン照合を40KBという極小RAMで捌く鍵は、ドメイン文字列そのものではなくハッシュ値をフラッシュメモリ側に置き、RAM上のデータ構造を最小化する設計にある。

画像生成に頼らず、TrueTypeのリガチャ（合字）とグリフ置換の仕組みだけで入力文字列に対応するQRコードを組み上げている点が、このフォントの技巧の核心になっている。