Posts

Cloudflare のブログに「How we built a software factory to drive Astro’s GitHub issue count to zero」という記事が出ました(Matthew Phillips、2026-08-04 公開、2026-08-21 取得)。Astro のリポジトリで自動トリアージを数か月回して、未解決 issue を 200 件超から約 30 件まで減らした話です。 仕組みの話として読めますが、私が持ち帰ったのは別のところでした。エージェントが繰り返し失敗した箇所を、エージェントの成績ではなく、そのコードが人間にとっても読みにくい場所の印として扱っている点です。 自分の保守しているコードベースにエージェントを入れていて、失敗が積み上がっている人向けです。先に要点だけ: エージェントが同じ箇所で繰り返し間違えたとき、原文はそれを3つのうちどれかの印として読む。境界が不透明な抽象、説明の無いコード、足りないテスト。どれも人間にとっての読みにくさと同じもの 直し方は命令ファイルに規則を足すことではなく、コードにコメントとテストを足すこと。原文には、ある if 条件の意味を説明するコメントを足したら、エージェントがその場所で誤った書き換えをしなくなった、という例がある この直し方だと、次に来る人間も同じだけ楽になる。命令ファイルを育てる直し方では、次のエージェントしか得をしない 記事が書いていること 以下はすべて上記 URL、2026-08-21 取得。 数字はこうです。「未解決 issue を 200 件超から約 30 件に減らし、来月中にはゼロになる見込み。そうなれば 5 年を超えるこのリポジトリの歴史で初めて」。「issue 破産」を宣言したわけでも、古いチケットを自動で閉じたわけでもない、と明記しています。この数字は私には追試できないので、出典つきの引用として扱います。 パイプラインは4段で、人間がバグを追うときの段取りをそのまま写したものです。 段 やること Reproduce 報告に添えられた再現リポジトリを clone して、報告どおりに起きるか確かめる Diagnose コードにログを仕込み、根本原因の場所を特定する Verify テスト・コメント・ドキュメントを読み、それがバグなのか意図した挙動なのかを判定する Fix 再現を失敗するユニットテストに変換し、アーキテクチャガイドに沿って解を選び、修正する 各段は隔離されたサブエージェントが実行し、発見を report.md に書き出して次の段に渡します。段を分けるのは「バグが実在しないかもしれない場面で解を捻り出そうとする LLM の偏り」を防ぐためだ、と原文は書いています。 修正に至ると pkg.pr.new でプレビュー版を作って issue に投稿し、報告者本人が自分のプロジェクトで動いたと確認したときに初めて pull request が開きます。状態は issue のラベル(triage needed と fix verified)だけで持ち、実装は triagebot-action として切り出されています。設定例ではトリアージ用と検証用に別のモデルが指定されていますが、分けた理由は原文に書かれていません。 ...

Shin | Decision-OS さんの X の記事「なぜ同じAIを使っているのに、差が開いていくのか」(2026-08-13 投稿、2026-08-21 取得)を読みました。AI のトークン消費を減らすツールを4本並べた記事ですが、ツールの優劣ではなく「それぞれが AI の仕事の別の場所にある摩擦を減らしている」という並べ方をしています。 コーディングエージェントを日常的に使っていて、使用量の表示が気になる人向けです。先に要点だけ: 削減ツールは「書く・読む・毎回読まされる・やり直す」のどの無駄を削るかで分類できる。別の分類のツールは効果が足し合わさり、同じ分類に2本入れても重なるだけ 4本のうち1本(シェル出力を圧縮する RTK)を手元に入れて測ったら、253 コマンドで 142.6K トークン削減(80.3%)。ただしその 96% はファイル読み取り1種類が稼いでいた 自分の運用にどの分類の手当てが無いかを見ると、次に入れるものが決まる。人気(スター数)は分類の重要度とは別に動く 4つの無駄と、それぞれを削るツール 以下は上記 URL、2026-08-21 取得。記事が挙げている摩擦は「不要なコードを書く。不要な出力を読む。今の仕事とは関係ないルールまで毎回読む。前回どこまで終わったのか分からず、次の AI がもう一度調べ直す」の4つです。ツールとの対応を表にするとこうなります。 摩擦 ツール 何をするか(記事の説明) GitHub スター(2026-08-21) 不要なコードを書く Ponytail 不要な実装をそもそも作らせない 106,742 不要な出力を読む RTK ツール出力が AI のコンテキストへ入る前に小さくする 76,832 関係ないルールを毎回読む AGENTS.md Compactor 毎回読み込む必要のない指示を常時領域から外す 2 前回の探索をやり直す Output Surface Integrity (OSI) 仕事を終えた後、次の AI が同じ探索をしなくて済むよう完了・再開状態を整理する 6 後ろの2本は投稿者自身の自作です。記事にも「優劣を比較しているのではない」と断りがあります。Compactor については、自分の AGENTS.md で毎回読み込む部分を 20,664 文字から 14,284 文字(30.9% 減)にした、ただし「情報を 30.9% 捨てたわけではない」、条件付きの規則を外に出して必要なときに読ませる形にした、と書かれています。 シェル出力の圧縮で減ったのは、ファイル読みだけだった 4本のうち RTK と Ponytail は 2026-08-20 に手元の環境(Claude Code)へ入れました。RTK は rtk gain で削減量が取れるので、その出力を貼ります(2026-08-21 実行、rtk 0.45.0)。 ...

.NET のブログに「Instructions Hygiene: What Frontier Models Still Need You to Say」という記事が出ました(Wendy Breiding、2026-08-12 公開、2026-08-21 取得)。copilot-instructions.md や AGENTS.md、CLAUDE.md のような、エージェントに毎回読ませる指示ファイルをどう手入れするか、という話です。 エージェントハーネスを使っていて、指示ファイルが育ちすぎた覚えのある人向けです。先に要点だけ: 指示ファイルに残す基準は「モデルが自分で発見も推論も取得もできないこと」かどうか。短さは目標ではなく、この基準で選んだ結果として出てくる 手入れは1行ずつ keep / remove / move / verify の4択で判定する。手元の CLAUDE.md 13項目に当てたら keep 10・verify 1・remove 1・move 1。別の共通ファイル(15項目)では remove が 6 出た 消しやすいのは「丁寧に」「step by step で」のような一般論と、lint が既に強制している規則。残すのはコードから読み取れない境界の意図と、動くことを確かめたコマンド 何が書かれているか 以下はすべて上記 URL、2026-08-21 取得。 問いの立て方を変えろ、というのが記事の軸です。「モデルに何を伝えられるか」ではなく、「モデルが自力で発見・推論・取得できないものは何か」を問う。目標は「結果を確実に変える、高信号の情報の最小集合を保つこと」だとしています。 書くべきものとして挙げているのは5種類です。 システムについての自明でない事実。例として、Billing.Api と Billing.Worker の境界、legacy/ ディレクトリがまだ本番で使われていること、src/Clients/Generated は手で編集しないこと 検証までの最短経路。ただし「動くことを確かめたコマンドだけ残す。自信ありげに繰り返される間違ったコマンドは、無いより悪い」 コードベースだけでは決まらない選択。テストフレームワーク、API スタイル、エラーの返し方など、複数の案からチームが選んだもの 絶対的な制約と高くつく失敗。always / never / must は本当に絶対のものにだけ使う 正本の所在。詳細はリンク先に置き、必要なときだけ読ませる 消すべきものは6種類です。「古い指示ファイルを改善する最速の方法は、たいてい引き算である」としています。 一般的なソフトウェア工学の助言(「きれいで保守しやすいコードを書け」) リポジトリの網羅的な目録 ツールが既に強制している情報。20個のフォーマット設定を列挙する代わりに dotnet format --verify-no-changes を走らせろ、と書く 既存ドキュメントの複製 プロンプトの民間伝承とモデルへのおだて。「深呼吸して」「step by step で考えて」「世界最高のシニアエンジニアとして振る舞え」「完璧になるまで止まるな」 過去の失敗の日記 手入れの手順は、1行ずつ4択で判定するレビューです。 ...

VS Code のブログに「MAI-Code-1-Flash: early results from real developer workflows」という記事が出ました(2026-07-29 公開、2026-07-30 取得)。新しいコーディングモデルのローンチ記事なのですが、目を引いたのはモデルの性能ではなく、性能の測り方のほうでした。 AI が書いたコードの評価に、受け入れたかどうかではなく、後から見てまだ残っているかを使っています。言いたいことを先に図にすると、こうです。 提案 受け入れる その後さわる コミット 受容率 ここで測定が終わる。材料は差分と、読んだ数十秒だけ 残存率 残存率は、動かして落ちた・読み返して消した … 受容の時点には無かった材料で決まる 測る区間が違うから、2つは逆を向くことがある 元記事の実測: 受容率 −6% のモデルが、残存率 +4% / コミット時残存率 +6%（baseline 比） 受容率は「読んで通したか」、残存率は「後から消さなかったか」。判定する材料も、判定する時点も違います。 ...

0xMovez AI さんの「Graph Engineering with Claude: 14-Step roadmap from 0 to graph architect」(2026-07-25 公開、2026-07-30 取得)を読みました。直線的に走らせているエージェント運用を、処理の単位(節点)とデータが流れる経路(辺)からなるグラフとして設計し直す、という記事です。 主張のうち2つを手元の環境で実際に動かして確かめたので、その結果まで書きます。 記事が言っていること 14段の構成です。前半は基礎(節点は1エージェント1ジョブ、辺は実際にデータが流れる依存だけ)、中盤は型(並列展開、全部揃ってから進む待ち合わせ、展開→縮約→統合のダイヤモンド、辺の上に検証者を置く)、終盤が今回試した2つです。 Step 12(節点ごとにモデルを階層化する): Not every node needs your best model. (中略) Run the boring nodes on a cheaper model and spend your expensive tokens where judgment actually lives. 〔訳〕すべての節点に最良のモデルが要るわけではない。退屈な節点は安いモデルで走らせ、高価なトークンは判断が実際に住んでいる場所に使え。 Step 14(良い実行を再実行可能な定義として保存する): When a run is good, press s to save its script into .claude/workflows/ - version-controlled, re-runnable by name, a graph anyone who clones the repo can launch. ...

エージェントが妙な変更をしたとき、「なんでこうしたの？」と聞いている人向けです。返ってくる答えが何なのか、代わりにどこを読めばよいのかを書きます。あわせて、手元の Claude Code のセッションログに思考の中身が残っているかを数えたので、そのコマンドと出力をそのまま載せます。 きっかけは X の投稿です。そこで挙げられていた理由（thinking が直近ターンしか文脈に入らない）は、公式ドキュメントに当たるとモデルによって違いました。ただし、どちらのモデルでもやることは変わりません。なぜ変わらないのかまで書きます。 まとめ エージェントに「なんで？」と聞くのをやめます。代わりに、依頼するときに「変更ごとに、その根拠を1行で添えて」と書いておいて、あとでその記録を読みます。理由は、聞いてから作らせるのではなく、作業した時点で書かせるほうが確かだからです。 聞いて返ってくる説明は、そのとき作られたものです。ヒントを与えて答えを変えさせた実験で、そのヒントを使ったと自分で書いたのは 25% でした（Claude 3.7 Sonnet での測定。新しいモデルで同じ数字になるとは限りません）。 Claude Code を使っているなら、自分のセッションログを開いてみてください。既定では、考えた形跡だけがあって中身が空です（数えたら 6,319 個すべてが 0 文字でした）。設定を入れると、画面で対話しながら進めた分は残ります。-p を付けて実行した分は残りません。 ⚠ 「セッションログ」「思考」「対話モード」が何を指すかは、本文で順に説明します。まとめだけで分からなくても、読み進めれば分かるようになります。 きっかけの投稿 もとは、LLM に理由を尋ねたときの応答についての投稿です（@golden_lucky、2026-07-30 投稿、2026-08-15 取得）。 「なんでこうしたの？」ってLLMに言うと「すみません考えが足りませんでした」みたいなこと言ってくるけど、そうじゃなくて理由を聞いてるんだよ、理由を答えてくれよ、人間になるなよ これを引用して、原因と対策を述べた投稿がこちらです（@Hi_Noguchi、2026-07-31 投稿、2026-08-15 取得）。長いので要点だけ引きます。 少なくとも Claude についていうと、「なんで」かは Claude 側も「知らない」。というのも thinking の内容が直近ターンのものしかコンテクストウィンドウに入っていないため。 なので Claude は過去の自分のアウトプットだけを見て、事後推測するしかないというわけ。だからそれっぽい「ウソ」ついたりする。 対策として、showThinkingSummaries を有効にしてセッションログ（jsonl）に記録される thinking summary を振り返らせること、その自動投入先として DuckDB や hooks が挙げられています。 言っていることには納得しました。理由を聞く相手を、エージェント本人から記録へ移すという話です。そのうえで、記録に何がどう入るのかを確かめました。 エージェントとのやりとりで、思考はどう扱われているのか 1回目と2回目に、何が行き来しているのか 先に用語を分けます。この記事で「説明」と呼んでいるのは、あとから「なんで？」と聞いたときに返ってくる文章のことです。モデルが答える前に内部でやっている推論のほうは「思考」と呼び、API では thinking ブロックとして扱われます。別物です。 以下は Anthropic の Extended thinking（2026-08-15 取得）に書かれている API の挙動です。Claude Code のようなハーネス越しに使っているときも、下ではこのやりとりが起きています。 ...

エージェントに調べ物をさせて、その結果を信じてよいか確かめている人向けです。 「原文を取ってきて、この語句を grep して件数を報告せよ」という指示は、裏取りのやり方としてかなり筋がよく見えます。実際、私はそれを規約に書いて1週間ほど運用していました(明文化したのは 2026-07-26 です)。その規約が破れたので、破れ方と直し方を書きます。手元で最小再現まで取れたので、コマンドと出力をそのまま載せます。 先にまとめです。 エージェントハーネスは、あなたが呼んだつもりのコマンドを別物に差し替えていることがあります。 私の環境で grep を呼ぶと、それは GNU/BSD の grep ではなくシェル関数で ugrep -I に差し替わっていました(Claude Code 2.1.220 / macOS / zsh、2026-08-02 時点)。-I はバイナリ扱いのファイルを飛ばすオプションで、NUL バイトが1個でもあると、何も出力せず終了コード1 を返します。grep -c が出すはずの 0 すら出ません そして grep -c が数えているのは行数であって出現回数ではありません。圧縮された1行の HTML では、何を探しても件数が 1 になります この2つが重なった結果、サブエージェントが「本文は取得できていません(ヒット0件)」と報告してきました。実際には本文が全文入っていました 差し替えの中身はハーネスごとに違うはずですが、「自分が指定したコマンドが、その名前どおりのものとは限らない」という形は、どのハーネスでも同じだと思います。以下、私の環境での実測です。 なぜ「件数を報告せよ」にしていたか 先に背景を書きます。読み飛ばして構いません。 エージェントに文章を書かせると、もっともらしい嘘が混ざります。厄介なのは、書いた本人にそれが検出できないことです。自分の出力を自分で検算しても、生成したときと同じ経路をたどって同じ結論に戻ります。 そこで「書く人」と「原典に当たり直す人」を分けて、後者には次の形で報告させていました。 該当句を生 HTML に対して grep -c し、ヒット数を報告せよ。バイト数は同一性の証明にならない(動的サイトはリクエストごとに揺れる)。 バイト数を退けているのは、それが証拠にならないからです。同じ URL でも日をまたぐと変わります。 $ U=https://x.com/kimuai08/status/2082428727401869753 $ curl -sL -A 'Mozilla/5.0' "$U" -o x.html -w '%{size_download} bytes\n' 362384 bytes 2026-08-02 取得です。前日 2026-08-01 に同じコマンドで取ったときは 362,678 バイト、同日に User-Agent を Chrome のものに変えたときは 367,448 バイトでした。どれも「取れた」のに、数字は一致しません。 だから「その語句が原文に在るか」という形の証拠、つまり grep の件数に寄せていた、という経緯です。 ...

CLAUDE.md や AGENTS.md、copilot-instructions.md が膨らんできて、削りたいが怖くて削れない人向けです。 削ってよい行を、勘ではなく CI の終了コードで判定する方法を書きます。手元のリポジトリで9通り実測したので、その手順と結果をそのまま載せます。 以下、規則違反を検出して CI を落とす自動検査（lint、ビルド時の検査、生成物の検査など、種類は問いません）を 「ゲート」 と呼びます。この記事の話は結局のところ、文書に書いた規則と、ゲートが見ている規則の、重なりを測るというだけのことです。 ⚠ もう1つ先に読み方を。この記事の RED/GREEN は、いつもの「ビルドが通った/落ちた」ではありません。 わざと違反を仕込んだ状態で CI を回すので、向きが裏返ります。 いつもの CI この記事 RED まずい ゲートが仕事をした GREEN よい 誰も見ていない TDD で、実装を書く前にテストを一度 RED にして「このテストはちゃんと落ちる」と確かめるのと同じ向きです。赤くならないテストが無意味なのと同様に、破っても GREEN のままの規則は、機械には存在していません。（コードの世界では mutation testing——わざと壊したコードにテストを当てて、ちゃんと落ちるか確かめる手法——と呼ばれているものを、命令文書に当てているだけです。） たとえるなら、CLAUDE.md の一行は「ドアを閉めること」という張り紙で、ゲートは開けっぱなしを検知する警報装置です。この記事でやるのは、張り紙を剥がしてみて様子を見ることではありません。 張り紙（文書の規則）を1つ選ぶ。まだ剥がさない 張り紙が禁じていることを、コードのほうでわざとやってみる（確かめたら元に戻します） 警報（CI）が鳴れば RED。機械が見張っているので、張り紙は剥がせる 鳴らなければ GREEN。見張りは張り紙しかないので、剥がせない。先に警報装置を作る 順序が肝心です。先に張り紙を剥がしても警報の配線は何も変わらないので、鳴るかどうかの確かめにはなりません。剥がすのは、鳴ると確かめたあとです。 まとめ 判定はこれだけです。「その規則をわざと破ったとき、CI は気づくか」。 気づく（RED）なら機械が同じことを言っているので、文書の行は消せます（ただし、その規則を破る頻度が低いときに限ります。理由は後半に）。 気づかない（GREEN）は「文書に残す」ではありません。「ゲートの積み残し」です。 まずゲートを書けないか考え、書けないものだけを文書に残します。 手元では GREEN 4件のうち3件を実際に書けたので、CLAUDE.md から削除しました。最終的に 9件中8件が文書から消え、残ったのは1件です。 削れる行の割合は、文書の質ではなくゲートの本数で決まります。 8割削りたければ、先に8割を捕まえる機械が要ります。順序は逆にできません。 なぜこれを測ったか 「Claude Code のプロンプトの 80% を削った」と題した Claude Code 作者の動画が公開されました（YouTube、2026-08-07 取得）。ページの HTML には "uploadDate":"2026-07-27T10:00:30-07:00"、itemprop="duration" content="PT35M52S" とあります。同ページの説明文によれば、出演は Boris Cherny と Diana Hu、収録は Startup School 2026 です。 ...

MCP の新しい仕様 2026-07-28 が出ました。告知の一文が「MCP is now stateless, making it easier to deploy and scale remote servers」です（@ClaudeDevs、2026-07-29 取得）。 リモート MCP サーバを自分で運用する側から読むと、これは仕様の話というより配置の話でした。実際に最小のサーバを書いて確かめたので、その結果まで書きます。 何が変わったか ステートレス化は3層にまたがっている changelog（2026-07-29 取得）を読むと、「ステートレス」が指しているものは1か所ではありませんでした。 セッション管理 — Mcp-Session-Id ヘッダがプロトコルレベルで削除されました。さらに initialize / notifications/initialized のハンドシェイク自体が無くなり、各リクエストが _meta に自分でプロトコル版とクライアント capability を載せます（io.modelcontextprotocol/protocolVersion、io.modelcontextprotocol/clientCapabilities）。 トランスポート — GET のストリームエンドポイントが削除されました。サーバが公開するのは POST を受ける単一エンドポイントだけです。SSE は「そのリクエストにスコープされたストリーム」としてのみ残り、Last-Event-ID による再開機能も削除されています。切れたら新しい request ID で送り直す、という規定になりました。 双方向性 — roots/list や sampling/createMessage のようなサーバ起点のリクエストは Multi Round-Trip Requests（MRTR）に置き換わりました。サーバは resultType: "input_required" を返し、クライアントが元のリクエストをリトライする際に応答を添えます。常時開いた双方向ストリームが要らなくなる、という形です。 かわりに server/discover が追加され、こちらはサーバの実装が MUST です。 図にするとこうです。左が従来、右が 2026-07-28 です。 従来(〜2025-11-25) 2026-07-28 クライアント サーバ initialize / initialized Mcp-Session-Id を発行 以後の全リクエストに Session-Id GET の常時 SSE ストリーム サーバ起点の要求(sampling 等) 両端が「どのセッションか」を 覚えている必要がある クライアント サーバ POST(単一エンドポイント) _meta に版と capability を自己記述 resultType: complete resultType: input_required 元リクエストをリトライ+応答添付 (MRTR: サーバ起点の代替) 接続をまたいで覚えるものがない。 SSE はリクエスト内のみ ハンドシェイク・セッション・GET ストリームがある 各リクエストが自己完結する ステートレス化「だけ」ではない ここが読み違えていたところです。changelog の major change は9件あって、破壊的なものが並んでいます。 ...

AI! AI! AI! という感じでしたね。Microsoft Ignite 2023 Book of Newsから気になったところをピックアップしました。 Azure Machine Learning プロンプトフロー 大規模言語モデル（LLM）を利用したアプリケーションの開発ライフサイクル全体を合理化 モデルカタログ Hugging Face、Meta、OpenAIのような有名なプロバイダーから基盤モデルを発見、評価、微調整、展開 MetaのLlama 2などのモデルをAPIエンドポイントとして統合 Microsoft FabricのOneLakeとの統合プレビュー Azure AI Studio 最先端のAIツールと機械学習モデルを使用してAIソリューションをシームレスに探索、構築、テスト、展開するためのワンストップ Customer Copyright Commitment Azure OpenAI Serviceも商用利用している顧客を著作権侵害の訴訟から守り、補償するコミットメント基準を設定 Azure AI Vision Liveness機能 顔認識なりすまし攻撃の防止 *Vision SDK 開発者がモバイル・アプリケーションに顔認識とライブ性を簡単に追加 画像解析 4.0 強化された OCR モデルは、画像内のタイプされたテキストと手書きテキストの両方に対する精度の向上 フローレンス基盤モデル 何十億ものテキストと画像のペアで訓練 Azure OpenAI Service 16Kトークンのプロンプト長を持つGPT-3.5 TurboモデルとGPT-4 Turbo 2023/11末パブリックプレビュー予定 ビジョン付きGPT-4ターボ（GPT-4V） Azure AI Visionと統合されたGPT-4Vは、テキストと一緒に画像や動画を含めることを可能 ビデオ解析のようなAzure AI Vision強化の恩恵を受け、体験を強化 2023年末までにプレビュー開始予定 Bing SearchとAdvanced Data Analyticsプラグイン Bing Searchとの統合により、Azure OpenAI Serviceから直接アクセス可能 Azure AI Language 英語での翻訳を仲介することなく、ある言語から別の言語への翻訳が可能 独自のインフラストラクチャ上でAIサービスを実行可能 パーソナルボイス 60秒間の音声サンプルを使って、企業がユーザー向けにカスタムニューラルボイスを作成 ...