今日の収穫、3行で。

タスク管理を厚くする立場は「エージェントは指示の粒度に比例して精度が上がる」と見る。一方でループ実測の記事は、粒度をどれだけ細かくしても判断そのものは人間に残り、そこが直列のボトルネックになると指摘する。前者は投資先を仕組み化に、後者は判断の事前決定（何を選ぶかを先に決めておく）に置いており、同じ問題への処方が分かれている。

Q. タスクを細かく割れば割るほど良いのか？
A. そうとは限らない。41件の実測では、割った先で「どちらの実装を採るか」の判断が都度発生し、その待ち時間が支配的になった。分割の副作用として判断の回数も増える。

Q. 中〜大規模で最初に整えるべきものは？
A. タスクの受け渡し形式（何を入力に、何を完了条件とするか）。これが曖昧だと、エージェントは途中で自分の解釈を足しにいく。

評価が真っ二つに割れた。「cringe（寒い）」「ふざけているだけなのに何故これほど注目されるのか」という否定側に対し、擁護側は「同時に多数のことが起きているとき、それを全部テキストで伝えようとするのは間違い。空間マップで示すのは賢い」と実用面を評価している。最も具体的だったのは数時間使った上での批判で、「agentではなくpipelineとroleが欲しい。プロンプト付きの固定エージェントを定義するのではなく、roleを定義してN体を立て、Plan→Review Planのようなパイプラインを組ませたい」という指摘。作者は「ほぼすべてのハーネス／コーディングエージェントに対応する」ラッパーであることを強調して答えている。

名前の Munder Difflin は、米ドラマ『The Office』の架空の製紙会社 Dunder Mifflin のもじり。コメント欄では「次はクローンの人事部と、自分自身にチケットを切り続けるクローンの情シスが追加される」と応酬が続いた。

Q. PlaywrightとAIの組み合わせが効くのはなぜか？
A. Playwrightは実行結果がスクリーンショットとトレースという確認可能な形で残るため、エージェントが自分の出力を検証して直すループを回せる。生成して終わりにならない点が大きい。

Q. どこまで任せられるのか？
A. この記事の範囲ではチケット管理まで到達している。ただし「何をテストすべきか」の決定は依然として人間側にあり、任せているのは決定の下流の工程である。

疑問が集中したのは新規性。「プロンプトの書き方とセッションの共有という2つを混同している。疑似コードは今日でも使えるし、共有はgit notesやリンクのコミットで足りる。差別化はセッション管理の側にあるはずだ」という指摘や、「ハーネスのシステムプロンプトに『疑似コードを渡したら意図を言語化してから実コードを書いてテストせよ』と書けば済むのでは」という反応がある。肯定側は「人間が書いた永続的なドキュメントを、チャット窓ではなく指示のインターフェースにする発想は良い。skill.md程度の仕組みで実現できるのでは」と、方向性は支持しつつ実装の重さを疑っている。複数ファイルにまたがる変更やimport／exportの表現をどうするかは未回答のまま。

「散文は遠すぎ、IDEでの共同編集は近すぎる」という問題設定自体には賛同が多い。割れているのは、その中間を新しい記法として立てるのか（Huzzahの立場）、既存の仕様駆動開発やskillファイルで足りるのか（Kiroやspec-driven developmentを挙げる側）という点。前者は表現力を、後者は学習コストの低さを取っている。

可視化側は「PRの数は減らせないので、構造を見せて人間の処理効率を上げる」という発想。理解基準側は「全部を同じ深さで読むのをやめ、変更の性質ごとに要求する理解度を変える」という発想で、こちらは意図的に一部を浅く読むことを許容している。後者は速い代わりに、基準を誤って設定すると危険な変更が浅いレーンを通る。

Q. PRをグラフで見ると何が分かるのか？
A. どのPRが他のPRの上に積まれているか（依存）と、どれが独立してマージできるかが一目で分かる。エージェントが並列に作業すると、この積み重なりが手作業では追えなくなる。

symlink共用は「一箇所を直せば両方に効く」という保守性の利点がある一方、解決規則が違う以上、同じ内容が同じ優先度で効く保証はない。検証ハーネス側の主張は、この不確かさを議論で解くのではなく、守られているかどうかを毎回テストして観測に落とすというもの。片方は設計で、片方は計測で対処している。

Q. 「解決規則が逆」とは具体的に何が違うのか？
A. どのディレクトリから探し始め、複数見つかったときにどれを優先するかの向きが異なる。結果として、リポジトリ直下とサブディレクトリに両方置いた場合に、効くファイルが入れ替わりうる。

Q. 指示が効いているかをどう確かめる？
A. 指示に反する振る舞いをしたら落ちるチェックを用意し、通常のセッションで回す。指示文を読み返すのではなく、出力を観測する。

MCPを増やす利点は機能の追加だが、実測記事が示すのは、接続しただけで通信と資格情報の露出が増えるというコスト側の事実。可用性についても、MCPが1つ落ちるとセッション全体が止まるなら、繋ぐ数がそのまま故障点の数になる。hookでのヘルスチェックはこれを局所化する対処にあたる。

Q. ツールを使っていないのに通信が発生するのはなぜか？
A. 接続の確立とツール一覧の取得が、実際の呼び出しとは独立に走るため。セッションの開始時点で、サーバーが何を提供しているかを問い合わせる必要がある。

Q. 資格情報が毎回流れることの何が問題か？
A. 露出の回数が使用頻度ではなく接続の有無で決まってしまう。使っていないサーバーを繋ぎっぱなしにするだけでリスクが積み上がる。

「Codexは可能な限り複雑にしたがり、指示や既定のskillすら無視する。Claudeの方がずっと実用的だ」という、記事とちょうど逆の報告が複数ある。過剰設計の具体例として、サイトのスクレイピング結果をSQLiteに入れたいだけなのに、事実を採用する前に3つの独立ソースの合意を要求する仕組みとenum群を作り始めた、という話が挙がった。逆にCodex支持側は「速いこと」と「無駄な文章を吐かないこと」を理由にしている。スレッドの結論めいたものは「様々なモデルについて、まったく矛盾する体験談が並ぶのが興味深い」というコメントで、別の参加者は「エージェントごとに性格が違い、望む動きを引き出すには学習が要る。自分はCodexで訓練されたのでClaudeが全部『間違って』見えた」と、評価の非対称性を自分の慣れの問題として説明している。

コメント欄で最も支持された比喩は「CodexはStar TrekのData」。当初は冷たく感じたが数週間使ううちに事務的な距離感が長所に見えてきた、という感想が続いた。

並列化の利点は明快に速度だが、3本が示す代償は3種類ある。統合の失敗（書いたのに繋がっていない）、検証の共倒れ（同じ文脈は同じ間違いを見逃す）、そしてトークン消費の増大。速度を取るなら、統合の確認と検証の分離にコストを払い直す必要がある。

Q. 「書いたのに動いていない」バグが多いのはなぜか？
A. 各エージェントは自分の担当範囲では完成させているが、呼び出し側の配線は誰の担当でもない。並列に分けた境界そのものが抜け落ちる。

Q. 検証を別セッションに出すと何が変わるか？
A. 実装時の前提を共有していないため、実装セッションが自明とみなした部分を疑える。同一セッションでのセルフレビューは、その前提ごと素通りする。

抽象化レイヤーの記事が指摘するのは、多くの人が期待する「プロバイダを乗り換えられる自由」は実際にはほとんど行使されず、価値は別のところ（呼び出しの一元的な計測と制御）にあったという点。コスト最適化を目的に抽象化を入れると、乗り換え可能性より観測可能性の方が先に効いてくる。

Q. Query-aware Compressionは効いたのか？
A. 記事はBedrockでトークン数とコストを実測して判定している。圧縮は入力トークンを減らすが、圧縮処理自体の呼び出しコストと精度低下を差し引いた正味で見る必要がある、というのがこの手の検証の要点。

Q. AI Gatewayを挟む意味は？
A. 複数プロバイダへの呼び出しを1箇所に集め、キャッシュ・レート制御・利用量の計測をアプリ側のコードから切り離せること。費用の可視化はここに載せると一気に楽になる。

チャンネル上での実行は、途中経過が最初から共有され、他の人が割り込める点が利点。一方で作業ログが会話に混ざるため、集中した長時間の作業には向かない可能性がある。ターミナル側の「静かだが1人でしか見えない」という性質と、真逆のトレードオフになっている。

Q. オープンに開発するとは具体的に何か？
A. エージェントへの指示と、その実行結果・生成物が、専用のチャンネルに順に流れる状態。誰でも経過を追え、途中で方向を修正できる。

コスト削減の定石はサンプリングと保持期間の短縮だが、どちらも障害時に見たいデータを事前に捨てる賭けになる。OTel批判記事の側は、そもそも仕様の実装が言語やシグナルごとに揃っていないため、ベンダー中立を理由に選んでも移行の自由が実際には得られていないと指摘している。

hookを重くする案は、人間の開発体験を犠牲にしてエージェントの安全性を取る。人間とエージェントが同じリポジトリで作業する場合、この犠牲は無視できない可能性がある。仕様書側の2本は逆に、実行時の強制ではなく事前の記述で範囲を絞る方針で、こちらは守られたかどうかを機械で確認できない弱さがある。

Q. なぜAI相手ならhookが重くてよいのか？
A. 待ち時間の心理的コストがなく、失敗した理由がテキストで返れば自分で修正して再試行するため。人間なら「重いからスキップする」となる箇所が、そうならない。

Q. 「作らないリスト」とは何か？
A. エージェントに実装させない領域を明示的に列挙したもの。決済のような領域では、何を作るかより何を作らせないかを先に決めた方が事故が減るという判断。

Q. キャッシュがあるのになぜ費用が跳ねたのか？
A. キャッシュはリクエストが似ている前提で効く。多様なパスを総当たりするスキャン群が来ると命中率が落ち、ほぼ全件が新規の推論になる。

galah はLLMでHTTPレスポンスを動的に生成するハニーポット。静的な偽サイトと違い、リクエストごとに応答を作るため、スキャンの物量がそのまま推論コストに変換される。

この数字を「だからプロンプトは重要でない」と読むのは早い。0.6%の人間の入力が残り99.4%の内容と量を決めている可能性があり、比率と影響力は別である。ただし、ツール出力の整形やシステム注入の削減が未着手であれば、そちらの方が改善余地は大きい。

Q. 残りの99.4%は何なのか？
A. ツールの実行結果、システムリマインダーの注入、hookからのメッセージ、サブエージェントの返却など、ハーネス側が生成してモデルに渡すテキスト。

TRONは消えていない。組み込み向けのITRON系は現在も家電・自動車・工業機器に広く生き残っており、一時は世界で最も多く出荷されたリアルタイムOSと言われた。潰れたのはPC向けのBTRONの側である。

同じ加算でも `add eax, ebx` と `addss xmm0, xmm1` は別命令で、オペランドの取り違えはアセンブラが弾く。つまり型検査は存在しており、ないのは型の名前と抽象化の方である。