honb.in

テストが通ることと、修正が正しいことは別

Mon, 19 Oct 2026 05:06:13 GMT

OSS に不具合修正の PR を出そうとして、実装もテストも用意した。ビルドが通ることも確認した。

ところが、あとから調べ直すと、修正そのものが不要だった。それどころか、仮に採用されていたら、別の問題を隠してしまう可能性もあった。

ビルドエラーを直そうとした

Void というフレームワークで、Markdown だけで構成された静的サイトをビルドすると、クライアントビルドで UNRESOLVED_ENTRY が発生する、という問題に取り組んだ。原因を調べると、このケースではクライアントビルドの入力が空になっていた。一方、クライアントビルド自体は静的ページの prerender に必要なので、ビルド処理は実行される。

そこで、入力が空の場合にだけ、空の仮想モジュールをエントリーとして追加する方法を考えた。実装を追加し、Markdown だけの playground と integration test も用意した。既存のクライアント入力がある場合には影響しないことも確認する方針にした。修正の説明も書き、あとは PR を出すだけ、というところまで進んだ。

検証した環境と対象ブランチのずれ

最初に問題になったのは、検証した環境と PR の対象ブランチが一致していなかったことだ。手元で確認していたのは、公開済みの Void のパッケージに修正相当の変更を加えた環境だった。PR の対象ブランチそのものではなかった。

さらに調べると、対象ブランチでは、関連する問題がすでに上流の変更によって解消されていた。つまり、このブランチで修正が必要であることを確認できていなかった。

手元の環境で仮想モジュールが解決され、ビルドが成功すること自体は事実だった。問題は、その結果を、修正が必要であることの根拠として扱ってしまったことだった。検証した環境で何が確認できたのかと、対象ブランチで何が必要なのかは、別の話だった。

空のエントリーが代替できなかったもの

上流の実装を確認すると、修正の捉え方自体にも問題があることが分かった。既存の変更は、単にクライアントビルドの入力を用意するためのものではなかった。アイランドページや Markdown ページからコンポーネント経由で参照される CSS を収集し、HTML にリンクする役割も担っていた。

一方、自分が追加しようとしていたのは、何も import しない空のモジュールだった。これなら空入力によるビルドエラーは回避できるが、本来のクライアントエントリーが担っていた CSS の収集まで代替できるわけではない。仮にこの修正が採用されていたら、ビルドは成功しても、必要な CSS が成果物に含まれない可能性があった。表面上のエラーを解消することと、フレームワークが必要とする成果物を正しく生成することを、同じものとして扱ってしまっていた。

本来確認すべきだったのは、入力が空になるという現象だけではない。クライアントエントリーがなぜ必要で、どのような役割を担っているのか、ということだった。

テストが緑であることは何を保証するか

テストで確認できたのは、仮想モジュールの resolveId と load が動作すること、Markdown だけのサイトがビルドされて HTML が生成されること、そしてページからクライアント JavaScript が読み込まれないことだった。どれも事実として意味がある。ただし、これらはこの修正が必要であることや、成果物が本来の要件を満たしていることまでは証明しない。

テストは、設定した条件を満たすかどうかを確認するものだ。その条件が問題の本質を捉えていなければ、テストが緑でも、間違った修正を正しいと思い込むことがある。ビルド成功とゼロ JS は確認した。しかし、クライアントエントリーが担う CSS の収集という役割は、テストの確認条件に含まれていなかった。テストが通ることと、問題が解決していることの間には、まだ確認すべきことが残っていた。

AI と開発して、自分で判断すること

今回の作業では、AI を使って調査や実装を進め、テストを考え、PR の説明を整理した。作業を進めるうえで役に立った一方、検証結果から何を結論づけられるかについては、自分で判断する必要があった。

失敗は、テストが足りなかった、というだけの話ではない。テストは通り、仮想モジュールの読み込みやビルドが成功することも確認できていた。それでも、そのモジュールが本来の役割を代替できるのか、という視点が抜けていた。

最終的に、修正本体は取り下げることにした。

何を確認できたのかと、何が正しいと言えるのか。その間には、まだ自分で考えなければならないことが残っていた。

開発の過程を、あとから振り返る

Sat, 17 Oct 2026 06:18:43 GMT

AIと開発していると、実装だけでなく、設計の検討や問題の調査など、さまざまなやり取りがセッション履歴に残る。コードやコミットを見れば変更内容は追えるけれど、なぜその方針にしたのか、どんなことを検討したのかは、あとから確認しにくいことがある。

こうした開発の過程を、あとから振り返りやすくしたいと思った。

そこで、Claude Code と Codex のセッション履歴をまとめて読める TUI、dtrail を作った。セッション一覧と会話を並べて表示し、過去のやり取りを読み返せる。

その後、Cursor のセッション履歴にも対応した。

何かを検索して答えを見つけるというより、セッションをざっと眺めながら、そのとき何を考え、どう進めていたのかを振り返る。そんな使い方を想定している。

個人サイトとアイコンを新しくした

Tue, 13 Oct 2026 00:00:00 GMT

以前から使っていた個人サイト honb.in を作り直した。もともとはプロフィールといくつかのリンクを載せただけのシンプルなサイトで、長い間ほとんど手を入れていなかった。今回はプロフィールを整理するのとあわせて、ブログもこのサイトに移すことにした。

自分の記録を置く場所

これまで記事は、はてなブログに書いていた。自分にとってブログは、考えたことや試したことを残しておいて、あとから振り返るための場所でもある。はてなブログには長くお世話になっているけれど、以前の記事を読み返すときに、どうしても広告が気になるようになってきた。せっかく自分の記録を残すなら、もう少し落ち着いて読み返せる場所に置いておきたい。それで今回、以前からあった個人サイトを作り直すのにあわせて、ブログも自分のサイトに置くことにした。直近の記事は新しいサイトに移して、はてなブログ側は下書きに戻した。古い記事はそのまま残して、これからは新しいサイトに書いていくつもり。

Astroで作り直す

サイトの構築にはAstroを使った。他にもいろいろ選択肢はありそうだったけれど、ひとまずこれにした。今回必要だったのは、プロフィールを表示するページと、Markdownで記事を公開する仕組みくらい。動的な機能は特に必要ないので、静的なHTMLを生成できれば十分だった。 AstroはHTMLに近い形でページを書けるし、Markdownの記事も扱いやすい。 CSSもできるだけシンプルにした。凝ったデザインにするより、文章が読みやすくて、必要なリンクが見つかればいい。細かい余白や見出しの扱いは調整したけれど、基本的には余計なものを増やさない方針にした。

プロフィールも整理する

プロフィールも、これまでの経験を振り返りながら、これからどんな仕事をしていきたいかを踏まえて書き直した。バックエンドを中心に、必要に応じてフロントエンドやインフラにも取り組んできたこと。新しい機能を作るだけでなく、サービスが使われ続ける中で見つかる課題を調べたり、改善したりする仕事が好きなこと。これまでの経験を整理しつつ、今後の活動にもつながるような内容にした。

アイコンも新しくする

長く使っていたプロフィール画像も変えることにした。以前の顔写真には馴染みもあって少し迷ったけれど、そろそろ変えてみたいと思っていた。まったく別のものにするのではなく、元の写真から色を取り出して、幾何学的なアイコンにしてみた。赤橙、茶色、ベージュ、クリーム色。顔の輪郭や表情はなくなったけれど、色だけは残っている。形や色の配置をいくつか試して、中心を少し上にずらしたデザインに落ち着いた。できあがったアイコンを眺めていると、夕方の光が差し込むようにも、折り紙を組み合わせたようにも見えてくる。暖色の柔らかさと、直線で区切られた幾何学的な形。中心が少し上にあることで、どこか動きも感じられる。最初からそういう意味を込めて作ったわけではないけど、眺めているうちに、そんなふうにも見えてきた。以前の画像から何かを残しながら、新しいものにできたのはよかったと思う。

これからは、この場所に少しずつ記録を残していこうと思う。

AIとの対話を振り返って、改善の種を探す

Sun, 11 Oct 2026 03:36:31 GMT

最近、Claude Codeとの対話を振り返るための小さなスキルを作って試している。

普段、AIは目の前の問題を解決するのに便利だけれど、作業が終わると、そのとき何をしていたかをあまり振り返らずに次へ進んでしまう。でも、仕事をしていると、同じような確認や調査を何度も繰り返していることがある。

以前、ログを使った調査で、取得したデータが意図した範囲をカバーしているか、何度も確認していたことがあった。そこを少し楽にできないかと考え、取得結果を検査する小さなツールを作った。一方、最近はAIに作業を任せることも増え、以前なら面倒に感じていた繰り返しも、それほど負担ではなくなっている。でも、負担が減ったことで、同じような作業を繰り返していること自体に気づきにくくなっているのかもしれない。だったら、AIとの対話を後から振り返ることで、そういう繰り返しも拾えるんじゃないか。

作ったスキルはシンプルで、現在のセッションを振り返り、その中で繰り返していた具体的な作業を拾い出す。何度も確認していたことや、同じような調査・比較を繰り返していたことなどが対象になる。そこから、何か改善できることはないかを考える。ただし、AIに改善案を自由に考えてもらうわけではない。実際の対話に根拠がある作業だけを対象にして、次の3つを分けるようにした。

Observed — 実際に繰り返していた作業
Inferred — その背後にありそうな問題
Opportunity — そこから考えられる改善の問い

改善の問いは最大3件。根拠がなければゼロ件でもいい。また、繰り返しているからといって、必ずツール化するわけではない。既存の方法で十分なこともあるし、仕組みを増やすことでかえって複雑になることもある。今のところ自動実行はせず、調査やレビューが一区切りしたところで手動で呼び出している。

まず、小さな開発ツールを作っていたセッションを振り返った。整形チェックやテストの実行、編集後の再インストール、公開前の確認など、繰り返していた作業はいくつか見つかった。その中から、公開前の確認をもう少し機械的にできないか、という問いが出てきた。ただ、これはもともと意識して確認していたことでもある。今の手作業でもそれほど困っていないし、仕組みを作ることで確認漏れがなくなるわけでもない。改善の問いは出たものの、今すぐ何かを作りたいとは思わなかった。

次は、ログを使った調査のセッションを振り返った。こちらでは、もう少し具体的な改善の問いが見つかった。一つは、データを取得する際に、取得結果が十分かどうかを確認し、必要に応じて取得条件を調整する作業。もう一つは、以前と同じ条件で調査をやり直すために、取得条件を手作業で組み立て直していたことだった。どちらも、調査そのものではなく、その準備や確認に関わる作業だった。そこから、取得結果に応じた作業をもう少し簡単にできないか、同じ調査条件を再利用できないか、という問いが出てきた。一つツールを作って終わりではなく、作業を振り返ることで、その周辺に残っている別の改善機会が見えてきた。

もう一つは、UIの見た目や動きを比較するために、単体のモックを作っていたセッション。候補を追加するたびに、複数の箇所を手で揃えたり、編集後の確認作業を繰り返したりしていた。そこから、候補の定義を一箇所にまとめることで、試行錯誤をもう少し楽にできないか、という問いが出てきた。これは独立したツールを作るほどの話ではないかもしれない。モックの構造を少し変えるだけでも、改善できる可能性がある。一方、実際に起きた問題でも、繰り返した根拠が弱いものはあった。そうしたものは、今回の目的とは少し違うので、いったん保留にした。

異なるセッションで試してみて、繰り返していた作業から改善の問いがいくつか見つかった。ただ、繰り返しているからといって、必ず改善する必要があるとは思っていない。今のままで十分なこともあるし、仕組みを増やすことでかえって複雑になることもある。AIには改善の問いを考えるところまで手伝ってもらい、実際に取り組むかどうかは自分で判断する。

まだ試した回数は少なく、見つかった問いが実際の改善につながるかは分からない。今は一つのセッションを振り返っているだけだけれど、いずれは複数のセッションで見つかった改善の種を持ち寄って、共通する問題がないかも探してみたい。しばらく、この使い方を続けてみようと思う。

集計の前提を確かめる

Sat, 10 Oct 2026 09:44:15 GMT

ログを取得して集計するとき、計算自体は正しくても、その前提になるデータや集計方法によって、結果の解釈が変わってしまうことがある。最近の分析で気になったことが2つあったので、それぞれ小さなツールとして切り出してみた。

取得したデータを確認する

障害調査などでCloudWatch Logs Insightsからログを取得するとき、結果が10,000件の上限に達していないかを、その都度確認していた。指定した時間範囲のログを取得しても、その範囲のデータがすべて取れているとは限らない。件数の上限に達していれば、クエリのソート順によっては、時間範囲の一部に偏っている可能性もある。そこで、Rustで作っている tskit に window-audit を追加した。

jq -r .time alb.jsonl |
  incident-window-audit \
    --from 2026-09-03T10:20:00+09:00 \
    --to 2026-09-03T10:30:00+09:00 \
    --limit 10000

指定した時間範囲と、実際に観測された最初と最後の時刻を比較し、両端の差や取得件数を表示する。例えば、入力件数が指定した上限に達していれば LIMIT_REACHED を出す。ただし、上限に達したからといって、実際にデータが打ち切られたとは限らない。逆に、観測範囲が指定した時間範囲の両端に届いていても、途中のデータがすべて取得できている保証はない。あくまで取得したデータから確認できることを表示して、原因の判断はクエリの条件やソート順と合わせて考える。

集計単位を確認する

もう一つは、イベントログをセッション単位で集計していたときのこと。セッションという単位は、もともとのイベントログに存在しているわけではない。一定時間イベントがなければ別のセッションとして扱う、というルールをこちらで決めている。例えば、30分空いたら別のセッションとするのか、90分空いたら別のセッションとするのか。それによってセッション数も変わるし、セッションを分母にした指標も変わってくる。

そこで、セッション化の処理を sessionize というCLIツールとして切り出した。

sessionize --key user_id --time timestamp --gap 30m < events.tsv

キーとタイムスタンプを持つイベントに対して、指定したアイドルギャップに基づいてセッションIDを付ける。入力はTSVで、出力もTSV。元の行順を維持したまま session_id 列を追加する。やっていることはそれだけ。例えば、アイドルギャップを30分から90分に変えて、それぞれの結果を集計すれば、セッションの区切り方によって数字がどのくらい変わるのかを確認できる。もちろん、どちらの区切り方が正しいかを、このツールが判断するわけではない。指定したルールに従ってセッションIDを付けるだけで、集計や比較は後段の処理に任せている。

今回作った2つのツールは、どちらも集計結果の正しさを保証するものではない。取得したデータがどの時間範囲を表しているのか。イベントをどんなルールで区切っているのか。集計された数字を見る前に、そうした前提を確認するためのもの。

やっていることは単純だけれど、実際の分析で使いながら、少しずつ検証していきたい。

サービスを育てるのが好きなんだと思う

Tue, 06 Oct 2026 12:14:42 GMT

年月が経つのは早く、あっという間に時間がすぎる。

最近はAIの進化も早い。できることがどんどん増えて、自分自身もかなり使うようになった。以前なら時間をかけて調べたり、考えたり、実装していたことが、驚くほど短い時間でできるようになった。便利になった一方で、今後自分がやっている仕事はどうなっていくんだろう、という不安も少しある。

コードを書くことがなくなるとは思っていないけれど、これまでと同じように技術を身につけて、コードを書けるようになっていけばいい、というだけでもない気がしている。そんなことを考えながら、最近はいろいろなものを作ったり、新しい技術を触ったりしている。何か次につながるものがないかな、と少し模索しているところもある。ただ、次に何をやりたいのかを改めて考えてみると、まったく新しいことを探したいわけでもないことに気づいた。

自分はやっぱり、サービスを育てることが好きなんだと思う。新しい機能を作るのも好きだけど、作って終わりではなく、その後も見ていたい。実際にユーザーに使われて、使いにくいところがあれば直す。問題が起きれば原因を調べる。運用して初めて見えてきた課題があれば改善する。ときには仕様を見ながら、そもそもこれでいいんだろうか、と考える。そうやって一つのサービスに関わりながら、少しずつ良くしていく仕事が、自分は好きなんだと思う。

振り返ってみると、自分は昔から一つの技術だけをひたすら掘るタイプではなかった。フロントエンドもやるし、バックエンドもやる。必要ならインフラも見る。その時々で問題になっているところに入っていって、どうすればよくなるかを考える。以前は、そうやっていろいろなことをやってきたことを、「一つの専門に特化していない」と少し弱みに感じていた。でも最近は、それもそんなに悪くないのかもしれないと思っている。

特にAIによって実装すること自体のハードルが下がっていくなら、どの技術を使えるかだけではなく、何が問題なのかを見つけて、必要なものを使って解決していくことは、これまで以上に大事になるのかもしれない。何をAIに任せるのか。何を自分で確かめるのか。何を作るのか。そして、作ったものが本当に良くなったのか。そういうことを考えながら仕事をするのは、やっぱり面白い。だから次のキャリアを考えるときも、「AIに代替されない仕事は何だろう」と考えるより、自分がこれからもやっていたいことを軸にしたい。次の現場はまた、自社サービスの開発に重きを置いて探してみたいと思っている。

AIに判断させる前に、事実を取り出す

Tue, 06 Oct 2026 05:58:32 GMT

最近、AIが書いたコードをどう理解するかについて、何本か記事を書いた。

AIは日常的にかなり使っている。設計について相談したり、コードをレビューしてもらったり、知らないことを調べてもらったりしている。一方で、少し前から、AIに頼りすぎているんじゃないかという感覚もあった。要件を伝えて、設計してもらって、実装してもらって、レビューまでしてもらう。便利ではあるけれど、全部をそのまま渡していると、自分がどこで考えたのかが分からなくなる。それで最近は、少し使い方を変えている。

こういう考え方の種は、以前からあったのかもしれない。障害調査では、想像で数値を埋めず、まずログやメトリクスから事実を取ることを大事にしていた。そのあと、Rustの勉強をきっかけに、調査で使う小さなツール群を作った。ログの発生数を数えたり、時間で切り出したり、2つの時系列が近い時間に発生しているかを調べたり、複数の時系列を同じ時間軸に並べたりする。作っていて気づいたのは、これらのツールは原因を判断してくれないということだった。「CPUが上がったからエラーが増えた」とは言わない。ただ、いつ何が起きたのかを数えたり、揃えたり、並べたりする。事実を見やすくするだけだ。

そのあと、コードレビューでも似たようなことを考えるようになった。大きなdiffをAIに渡して「重要なところを教えて」と聞くことはできる。でも、その前に、変更されたシンボルは何か、参照箇所はいくつあるか、分岐がどれくらい増えているか、といったことは機械的に調べられる。そこで、git diffからそういう情報だけを取り出す小さなツールを作り始めた。ここでも、ツールには「この変更は危険だ」と判断させないことにした。どこから読むかを決めるための材料だけを出す。前の記事では、これを signals → prioritize → interrogate と書いた。コードレビューのために考えた流れだったけれど、もう少し広く捉えると、自分のAIの使い方にも同じことが言えそうだった。大事なのは、どこまでが観測された事実で、どこからが解釈なのかを見失わないことだと思う。

AIは、曖昧な情報から意味を考えたり、複数の可能性を出したりするのが得意だ。でも、何件あったのか、どこが変わったのか、どのシンボルが参照されているのか、といったことまで推論してもらう必要はない。機械的に取れるものは、小さなプログラムで取り出せばいい。もちろん、そこで取れる事実も完全ではない。実際、参照数が名前の一致を拾いすぎたり、変更していない関数を変更箇所として扱ってしまったこともあった。だから、出てきたものをそのまま正解とはせず、必要なら元のコードやログに戻って確かめる。全部を自動化したいわけではない。人間が判断するために必要な事実を、できるだけ安く取り出したい。その面倒なところを小さなツールに任せる。AIには、その先を一緒に考えてもらう。

Rustの勉強をきっかけに始めた小さなツール作りだったけれど、思っていたより広い話になった。 AI時代にどういう技術を身につければいいのか、まだよく分からない。でも少なくとも今は、事実を取り出す道具を作り、その事実をもとにAIと考え、最後は自分で判断する。このくらいの距離感が、自分にはちょうどよさそうだと思っている。

大きなdiffを、どこから読むか

Tue, 06 Oct 2026 04:23:20 GMT

最近、AIが書いたコードをどう理解するか、ということを何度か書いていた。コードについて問い直す仕組みを作ってみたり、AIの説明をそのまま信じず、前提や失敗条件を確認するようにしたりしている。ただ、実際の変更が大きくなると、その前に別の問題がある。そもそも、どこから読めばいいのか。

git diff を上から全部読めばいいのだけど、変更が複数のファイルや関数に散らばっていると、それだけでもそれなりに負荷がかかる。かといって、AIに全部読ませて「重要なところだけ教えて」とすると、今度はその判断自体をAIに預けることになる。

そこで、change-signals という小さなCLIをRustで作った。やっていることはかなり単純で、git diff から変更されたシンボルを拾って、いくつかの粗い情報を付ける。

src/cache/store.ts
  getOrFetch        refs=14, branch+5, cache
  evictExpired      refs=6, branch+1

src/db/records.ts
  loadRecord        refs=12, db

refs はその名前がリポジトリ内に何行あるか、branch は変更で増減した分岐の数、cache などは境界らしき文字列が変更に含まれていたことを表している。branch は符号つきで、減っていれば簡素化や移設の手がかりになる。どれもかなり粗い。参照解析をしているわけではないし、構文を正確に解析しているわけでもない。リスクスコアも出さないし、「これは読まなくていい」とも言わない。 git diff --stat でもファイルごとの変更量は分かる。ただ、そこはファイル単位で止まるし、行数しか見ていない。変更したシンボルがリポジトリのどこからどれだけ参照されているか、といったdiffの外側の情報までは出ない。そこを、粗くてもシンボル単位で足したかった。目的は、変更を理解することではなく、どこから読むかを決める材料を作ることにした。

考えている流れはこんな感じになる。

signals → prioritize → interrogate
  ↓           ↓             ↓
事実を集める   読む順を決める   実際に理解する

途中、実際のコードに使ってみたら、変更していない関数に別の変更が紐づいてしまい、その関数を「読むべき場所」として選んでしまうことがあった。これはまずかった。情報が粗いことより、違う場所へ誘導することの方が問題だった。そこで関数の範囲を追跡するようにして誤った帰属は直した。一方で、細かい構文まで正確に解析するところまではやらなかった。そこまでやるなら、Tree-sitterのようなちゃんとしたパーサーを使う話になってくる。今回はそこには行かず、誤誘導は直す。粗さは残す。くらいで止めることにした。

AIを使えば、コードの説明はいくらでも増やせるようになった。でも、説明が増えるほど理解できるとは限らない。全部を自動化するのではなく、自分が判断する場所は残したまま、読むための負荷だけを少し減らしたい。 change-signals は、そのためのかなり小さな道具になった。まだ v0.1.0 なので、しばらく実際の変更に使いながら試していこうと思う。

コードを問い直すための仕組み

Mon, 05 Oct 2026 12:21:06 GMT

前の記事で、「AIが書いたコードに、自分は何を問えるか」という話を書いた。AIが書いたコードを理解するには、ただ読むだけではなく、「なぜこうなっているんだろう」と自分から問いを返す必要があるんじゃないかと。

最近、そのための質問を interrogate という小さなskillにまとめて使っている。きっかけになったのは、kawasimaさんの「Generation-then-comprehension」という記事だった。たとえば、

このコードが前提としている条件は何か
その前提は誰が保証しているのか
前提が崩れたらどうなるのか
もっと単純な実装ではだめなのか
この条件分岐を消したら何が起きるのか
正常系のテストだけでは見つからない問題は何か

といったことを聞く。

前にも触れたRustのコードでは、ある処理が「入力はソート済み」という前提で動いていた。実装を読むだけなら、それで終わる。でも、「なぜソート済みである必要があるのか」「誰がそれを保証するのか」「ソートされていなかったらどう壊れるのか」と聞いていくと、コードの見え方が変わってくる。コメントに書いておけば十分なのか。debug_assert! を入れるのか。それとも型で表現するのか。

ただ、質問の内容以上に意識したのが、AIにどう答えさせるかだった。「なぜこの実装にしたの？」と聞けば、AIは今ある実装をうまく説明してくれる。でも、それだけだと、あとからもっともらしい理由を付けているだけなのか、本当に他の選択肢より良かったのかが分からない。

そこで、このskillでは「正当化ではなく反証から組む」というルールを入れた。今の実装が正しい理由を並べる前に、正しく動かない条件、採用を見送るとしたらどこか、もっと単純な方法で十分ではないか、テストで確認できていない前提はないか、という方向から考えてもらう。正しさを説明してもらうより、まず壊しにいく。

もちろん、これで自分がコードを理解できるようになる、という話でもない。skillが質問して、AIが答えて、それを読んで「なるほど」で終わったら、結局やっていることはあまり変わらない。答えそのものより、そこで「本当に？」「じゃあこの入力なら？」「その前提はコードのどこにある？」と自分がもう一度引っかかれることのほうが大事なんだと思う。

だからこのskillには、ライブラリの挙動や呼び出し箇所のように確認できるものは実際に確認すること、より単純な実装で十分ならそう認めること、自分が書いたコードを自分でレビューするときはそのバイアスを意識すること、といったルールも入れた。AIに説明させるためというより、AIの説明をそのまま信じないための仕組みに近い。

以前、「AIに何を教えるべきか」を考えていたとき、AIに知識だけでなく「問い」を持たせるのがいいんじゃないかと書いた。その問いが、最近は少し違う使い方になってきた。AIに良いコードを書かせるためだけではなく、AIが書いたコードを自分が理解するためにも使う。問いをskillにしたことで理解を自動化できるわけではない。むしろ、自動化しすぎて通り過ぎそうになるところで、一度立ち止まるための仕組みなのかもしれない。

AIが書いたコードに、自分は何を問えるか

Mon, 05 Oct 2026 08:22:19 GMT

6月に「実装が速くなるほど、理解の価値は上がる」という記事を書いた。そのあと「AIに何を教えるべきか」で、AIに渡すのは知識と問いなんじゃないか、と考えていた。最近になって、この二つが自分の中で少しつながってきた。

AIに細かいルールをたくさん与えるより、その背景にある知識を渡したほうがいい。「indexをkeyに使わない」みたいなルールだけではなくて、なぜそうするのかを伝える。さらに、知識を渡すだけではなく、「この要素のidentityは何だろう？」「この責務はここでいいんだろうか？」みたいな「問い」も大事なんじゃないか、と。ルールは品質を安定させる。知識は判断を支える。問いは、その知識を引き出す。当時はそんなふうに考えていた。

それから3か月くらい、かなりAIと一緒にコードを書いた。設計を相談して、そのまま実装してもらって、レビューして、また直してもらう。便利だし、速い。ただ、AIが書いたコードを見て「なるほど、これでよさそう」と思っているけど、本当に自分はこのコードを理解しているんだろうか、と思うことが増えた。AIに良いコードを書いてもらうことと、自分がそのコードを理解することは、たぶん別なんだと思う。

最近、Rustを勉強しながら小さなツールを書いている。たとえば、ある関数が「入力はソート済み」という前提で動いていた。コードとしては正しく動いている。でも、なぜソート済みである必要があるんだろう。誰がそれを保証するんだろう。前提が崩れたらどうなるんだろう。コメントだけでいいのか。debug_assert! くらい入れたほうがいいのか。それとも型で表現するのか。

こうやって一度立ち止まると、AIが書いたコードが少しずつ自分の言葉になっていく感じがする。以前の記事では「AIに何を問わせれば、より良いコードを書けるか」を考えていた。今は「AIが書いたコードに、自分は何を問えるか」を考えている。前に書いたことが間違っていたとは思っていない。ただ、それだけでは足りなかった。

最近は、要件や設計をAIと一緒に考えて、実装は一度自分で軽く書き、AIにレビューしてもらうくらいが自分には合っているのかもしれない。もちろん、AIに実装してもらうこともある。どちらが書いたかは、そんなに重要じゃない。最終的に「なんでこうなっているの？」と聞かれたときに、自分の言葉で答えられるか。書いてみると、ずいぶん当たり前の話をしている気もする。でも、AIがかなりのところまでコードを書いてくれるようになって、この当たり前を意識することが以前より難しくなった。

AIに何を教えるかを考えていたら、いつの間にか、自分が何を問えるかを考えるようになっていた。

ぜんぶ timestamp value にする

Sun, 04 Oct 2026 08:00:12 GMT

Rustで作った障害調査用の小さなツール群を、過去の障害を題材に試している。

前回は incident-timeline を使って、いくつかの時系列データを同じ時間軸に並べてみた。数字だけ眺めていたときより、かなり分かりやすかった。「ある時間帯にエラーが増えたとき、ほかの指標はどう動いていたか」といったことが、形として見える。こういうグラフを見るだけなら、AWSのダッシュボードでもできる。では、わざわざ手元で見るツールを作った意味はなんだろう。

AWSのダッシュボードは、CloudWatchにあるメトリクスを見るのには当然よくできている。一方で、障害調査では、それ以外の数字も一緒に見たくなることがある。たとえば、ログから数えた502の発生数。CloudWatch Logs Insightsで1秒ごとに数えた結果も、時系列データとして見れば、

2026-01-01T10:00:00+09:00 2
2026-01-01T10:00:01+09:00 5
2026-01-01T10:00:02+09:00 3

という、ただの timestamp value になる。CPUも同じ形にできる。レイテンシもタスク数も同じ。さらに、既存のデータから自分で計算した値も同じ形にできる。incident-align で2つの系列を時刻で揃えて、awk で計算する。その結果も timestamp value にすれば、CloudWatchから取ってきたメトリクスと同じように扱える。ログなのか、メトリクスなのか、自分で計算した値なのかは、そのあとのツールにとってはあまり重要ではない。ぜんぶ timestamp value の形で扱えばいい。

振り返ると、これは途中で incident-timeline の入力を種類ごとに分けず、全部 --series にした判断ともつながっていた。取得元をツールが知る必要はない。必要なデータを手元に持ってきて、同じ形にしてから、切ったり、並べたり、計算したりする。

window | burst
align | awk | series

障害調査では、「この時間だけ見たい」「この2つを揃えたい」「ここから別の値を計算したい」ということを何度も繰り返す。そういう作業には、小さな処理をパイプでつないでいく形が合いそうだと思っている。もうひとつ、手元に持ってくることでできることがある。調査に使った入力ファイルと、incident-timeline が出力したHTMLを残しておけば、「そのとき何を見て判断したか」も残せる。これは生のログやメトリクスをずっと保存しておきたい、という話ではない。必要になったら元の場所からまた取ってくればいい。でも、ひとつの障害を調べたときに使ったデータと、そのとき見ていたグラフは、ひとまとまりの成果物として残せる。incident-timeline のHTMLをJavaScriptや外部のライブラリに依存しない形にしたのも、結果的にはここにつながっていた。

こうして見ると、このツール群はAWSのダッシュボードを置き換えるものではなさそうだ。普段の観測は、AWSのダッシュボードでいい。調査が必要になったときに、必要なデータを手元に持ってくる。出どころの違うデータを同じ形にして、切ったり、並べたり、重ねたりする。そして必要なら、そのとき見ていたものを残す。

最初からこういう設計を考えていたわけではない。入力を --series に揃えたり、HTMLをself-containedにしたり、表示する時刻だけoffsetを変えられるようにしたり、そのとき必要だったことをひとつずつ決めていった。あとから並べてみると、それらが同じ方向を向いていた。実際の障害調査で必要になったとき、どこまで使えるか試してみたい。

完成してから、使う側に戻る

Sun, 04 Oct 2026 07:10:50 GMT

Rustで作っていた小さなツール群が、ひとまず完成した。

障害調査で使うためのもので、ログの発生数を眺めたり、時間で切り出したり、分布を見たり、複数の系列を並べたりする。最後に作った incident-timeline は、たとえば502の発生数、CPU、レイテンシ、タスク数みたいな時系列データを、同じ時間軸に並べてHTMLにしてくれる。過去の障害を題材に試してみると、数字だけ眺めていたときより、かなり分かりやすかった。「ある時間帯にエラーが増えたとき、ほかの指標はどう動いていたか」といったことが、形として見える。よし、完成。 ……と思ったのだけど、使っていてひとつ面倒なことに気づいた。時刻がUTCだった。

CloudWatchから取ってきたデータがUTCなので、ツールもそのoffsetをそのまま使って表示している。これは仕様としては正しい。ただ、自分が見たいのは日本時間なので、「05:45だから、14:45か」と毎回頭の中で9時間足していた。地味だけど面倒だった。そこで --display-offset +09:00 というオプションを足した。これを指定すると、データそのものやグラフ上の位置は変えず、軸とツールチップの時刻だけを +09:00 で表示する。内部の値には触らない。表示だけ変える。実装も小さかった。

タイムゾーンを扱うなら、Asia/Tokyo みたいな名前を指定できたほうがいいかもしれない。DSTも考えたほうがいいかもしれない。そう考え始めると、いくらでも機能は増やせる。でも今回、実際に困ったのはそこではなかった。UTCをJSTに読み替えるのが面倒だった。それだけだった。日本にはDSTがないので、今の自分の用途なら固定offsetを指定できれば十分だった。新しい依存もいらない。なので、そこまでで止めた。

以前だったら、完成度を上げようとして先回りでいろいろ考えていたかもしれない。でも今回は、いったん完成とする。実際に使って、面倒を踏んだら、その面倒だけ取る。という順番になった。これは、今回Rustでツールを作りながら何度か意識していたことでもある。「あとで必要になるかもしれない」では作らない。実際に必要になってから考える。もちろん、最初から考えておいたほうがいいものもある。でも、小さな道具を自分で作っていると、使う前に想像していた不便と、実際に使って感じる不便はけっこう違う。今回も、完成したあとに機能を追加した。でも、それは完成していなかったからではない気がする。

完成というのは、もう何も足さないという意味ではないのかもしれない。一度そこで終わりにして、使う側に戻る。使ってみて、不便だったら直す。ただし、そのとき困った分だけ。今回は、それくらいがちょうどよかった。

理解した前提をコードに戻す

Sat, 03 Oct 2026 07:21:06 GMT

前回、AIと一緒に書いたコードを読み直して、別々の場所にあるコードが、実はひとつの設計になっていた、という話を書いた。

題材にしたのは、2つのイベントが近い時間に起きているかを調べる処理だった。両方のイベントをあらかじめソートしておくことで、2つの列を前から順番に見るだけで判定できる。コードを読んでいて面白かったのは、「ソートする処理」と「ソート済みであることを前提にした処理」が、別の場所にあったことだった。

nanos.sort_unstable();

この一行があるから、その後の count_matched では一度通り過ぎたところに戻らなくていい。そこまで理解して、ひとつ気になった。この「ソート済みである」という前提は、コードのどこに書いてあるんだろう。

count_matched にはコメントがあった。

/// Both slices must be sorted ascending.
pub fn count_matched(events: &[i64], others: &[i64], window: i64) -> usize {
    // ...
}

ちゃんと書いてある。でも、関数のシグネチャだけを見ると、普通の &[i64] なので、ソートされていない値を渡すこともできる。同じようなところが、別のツールにもあった。

pub fn percentile(sorted: &[f64], p: f64) -> f64 {
    debug_assert!(!sorted.is_empty(), "percentile of empty slice");
    // ...
}

こちらは引数名が sorted になっている。コメントにもソート済みであることが書かれていた。でも、それをコードでは確認していなかった。しかも percentile は、空の配列については debug_assert! で確認している。空ならその後かなりわかりやすく壊れるのに、ソートされていない場合は、それっぽい間違った値を返してしまう可能性がある。考えてみると、確認したいのはむしろこっちかもしれない。じゃあ、どうするか。最初に考えたのは、型にすることだった。たとえば Sorted<T> のような型を作って、生成時にソートし、ソート済みの値しか count_matched や percentile に渡せないようにする。そうすれば未ソートの値はそもそも渡せなくなるので、関数側は前提を信頼できる。でも、少し考えてやめた。今のコードでは、ソート済みのデータが、多くの場所を経由して持ち回されるわけではない。ソートして、すぐ使う。こういう前提を持つ関数もまだ少ない。ここで Sorted<T> を作ると、型の定義だけでは終わらない。どう作るか、どう借用するか、i64 と f64 のソートをどう扱うか、と考えることが増えていく。もちろん、それが必要になることもあると思う。でも、今はそこまでではなさそうだった。結局、追加したのはこれだった。

debug_assert!(events.is_sorted(), "events must be sorted ascending");
debug_assert!(others.is_sorted(), "others must be sorted ascending");

percentile にも追加した。

debug_assert!(
    sorted.is_sorted(),
    "percentile requires an ascending-sorted slice"
);

追加したassertは3つ。 debug_assert! なので、debugビルドでは前提が破られたら気づける。一方、デフォルトのreleaseビルドではチェックされないので、is_sorted() のために毎回配列を走査することもない。型ほど強い保証ではない。でも、今のコードにはこれくらいでよさそうだった。さらに「このassert自体のテストも書くべきか」と考えた。でも、それもやめた。debug_assert! と is_sorted() の動作を確認するだけのテストになりそうだったし、assertのためにテストコードのほうが大きくなるのも少し違う気がした。

前回は、AIが書いたコードの「なぜ」を追いかけて、ソートとTwo Pointersのつながりを理解した。今回は、その理解したことを、どこまでコードに戻すかを考えた。コメントだけでも伝わる。assertにすれば実行時にも確認できる。型にすれば、もっと強く守ることもできる。強くできるなら、強くしたほうがいいようにも思える。でも、型にできることと、型にすべきことは別なんだと思う。必要になったら、そのとき型にすればいい。今回はassertを3つ追加して止めた。

AIとコードを書いていると、生成されたコードを理解することに目が向きがちだけど、そのあとに「理解したことをコードにどう戻すか」を考えるのも面白い。そして、戻しすぎないことも、たぶん設計のひとつなんだと思う。

AIが書いたコードを自分の言葉にする

Sat, 03 Oct 2026 06:22:17 GMT

前回、O’Reillyのサブスクに登録して「作る → AIに聞く → 気になったら本を読む」でやってみる、と書いた。

最近、Rustの勉強を兼ねて、業務でも使えそうな小さなCLIツールを作っている。基本的には自分で考えつつ、わからないところはAIに聞きながら進めている。今回は、AIと一緒に書いたコードをあとから読み直してみた。

題材にしたのは、2つのイベントが近い時間に起きているかを調べる処理。自分だったらどう書くだろう、と考えてみると、最初に浮かんだのは二分探索だった。片方のイベントをソートしておいて、もう片方の各イベントについて、近くにあるものを探す。たぶんそれでも書ける。でも、実際のコードはそうなっていなかった。

両方のイベントをあらかじめソートして、2つの列を前から順番に見ていく。片方の位置を示すポインタは前に進むだけで、一度通り過ぎたところには戻らない。いわゆるTwo Pointers（2ポインタ）のやり方だった。最初は「なるほど、こっちのほうが速いのか」くらいに思った。でも、もう少しコードを追ってみると、面白かったのはアルゴリズムそのものではなかった。なぜ「戻らなくていい」のか。調べる側のイベントがソートされていて、時刻が順番に大きくなっていくから、一度通り過ぎたところには戻らなくていい。もう片方もソートされているから、前から順番に見ていけば判定できる。当たり前といえば当たり前なんだけど、この「ソートされている」という前提が、コードの別の場所にあった。

nanos.sort_unstable();

最初に読んだとき、この一行は単に入力を整えているだけだと思っていた。でも、ここでソートしているから、その後の処理では「もう見たところには戻らない」と決められる。別々の場所にあるコードが、実はひとつの設計になっていた。

AIとコードを書いていると、こういうことが結構ある気がする。コードは動く。テストも通る。実装としても悪くない。だから、そのまま次に進めてしまう。でも、自分がそのコードを理解しているかというと、また別の話なんだと思う。今回も、Two Pointersという名前を覚えたことより、「なぜこの実装が成立するのか」を追いかけたことのほうが収穫だった。コードを読んでいると、一見すると独立して見える処理が、別の場所の実装を成立させていることがある。さっきのソートが、まさにそれだった。設計を理解するというのは、コードを一行ずつ説明できることより、こういう処理同士のつながりを見つけることなのかもしれない。

AIはかなりいいコードを書いてくれる。だから最近は、「自分で全部書けたか」だけを気にしても、あまり意味がない気がしている。それより、「自分だったらどう書くか」を一度考えて、AIが書いたものと比べる。違っていたら「なんでこっちなんだろう」と調べる。そこで本を読む。今回も、二分探索だと思っていたものがTwo Pointersだった、という小さな違いから、ソートと計算量の話を調べて、最終的には「この処理とこの処理は、どうつながっているんだろう」というところまで戻ってきた。

こういう寄り道なら、悪くない。「動いた。よし次」で進めるのも速いけど、たまには立ち止まって、AIが書いたコードの「なぜ」を自分なりに追いかけてみる。しばらくは、そんな感じでやってみようと思う。 O’Reillyのサブスクも、たぶんこういう使い方なら元が取れる。

たぶん。

O’Reillyのサブスクに登録した

Sat, 03 Oct 2026 05:16:31 GMT

前からちょっと気になってはいたんだけど、まあまあいい値段するし、本なら必要なときに買えばいいかなと思っていた。ただ最近Rustを触り始めて、読みたい本がちょこちょこ出てきたので、試しに入ってみることにした。

今はRustの勉強も兼ねて、業務で使えそうな小さいCLIツールを作っている。ログのタイムスタンプを集計したり、時間で絞ったり、2つのイベントが近い時間に起きているか調べたり。もともと仕事でシェルスクリプトや awk、sort あたりを組み合わせてやっていたことを、Rustで少しずつ道具にしている感じ。これが思ったより楽しい。

ただ、Rustはまだ全然わからない。AIに聞けばコードは出てくるし、それを見ながらなら結構先まで進める。でも、せっかくRustを勉強するためにやっているのに、「動いた。よし次」だけだと、ちょっともったいない。実際に作っていると、標準入力を1行ずつ読む BufRead や、時刻順にデータを扱う BTreeMap みたいなものが、AIと一緒に書いているうちに自然とコードに入ってくる。でも「動いているからOK」ではなくて、「なんでここではこれを使うんだろう」はちゃんと理解しておきたい。

ちょうどO’ReillyはMCPも提供されているので、Claudeから書籍を検索できるようにもしてみた。実装中に気になったことが出てきたら、そのまま関連する本や読むところを探せる。「このコードを書いているなら、このへんを読んでおくとよさそう」みたいな使い方ができるのは結構よさそうだ。最初はRustの本を一冊ちゃんと読もうかとも思ったけど、たぶん自分は途中で飽きる。なので、無理に最初から読まないことにした。コードを書く。わからないことが出てくる。AIに聞く。気になったら、その場でO’Reillyから関連する本を探して読む。

最近、AIを使ってコードを書くことがかなり増えたけど、本を読まなくてよくなった感じはあまりしない。むしろAIで先に進めるようになったぶん、「これ、なんでこうなってるんだ？」というところを本であとから埋めるのは、結構相性がいい気がする。作る → AIに聞く → 本で掘る。しかも、その本を探すところもAIからできる。しばらくこれでやってみる。問題は、O’Reillyのサブスク代の元を取ろうとして、読まなくていい本まで読み始めないかどうか。

AIに教えるべきものは何だろう

Sat, 04 Jul 2026 08:08:06 GMT

最近、AIエージェントを活用する現場では、「Skill」やプロンプトを整備し、AIの振る舞いを細かくルール化する取り組みをよく目にする。命名規則を書く。実装手順を書く。レビュー観点を書く。AIが安定して期待どおりに振る舞うよう、ルールを積み重ねていく。

この取り組みは、とても重要だと思う。現時点のAIは、ガードレールがあるほど品質が安定する。チーム開発でも、共通のルールは欠かせない。だから、ルールを書くこと自体を否定したいわけではない。

ただ、その様子を見ているうちに、私はある疑問を抱くようになった。本当に育てているのはAIなのだろうか。それとも、私たちは「設定ファイル」を育てているだけなのだろうか。

正直に言うと、私はこのルール整備に、どうも乗り気になれずにいる。なぜだろうと、しばらく考えていた。

気になっていたのは、ルールを書くことではない。ルールをどれだけ充実させても、AIの判断を支える知識を育てている感覚が、どうにも持てなかったのだ。

ソフトウェア開発では、新しいライブラリが登場し、設計手法が変わり、ドメインへの理解も深まっていく。変化は、まずルールではなく、その背景にある知識の側で起きる。そして、新しい状況に出会っても、ルールは知識から導き直せる。だとすれば、長期的に価値を持つのは、ルールそのものよりも、判断を支える知識のほうではないだろうか。

ルールと知識は似ているようで違う。例えば、「Reactでは index を key に使わない。」というのはルールだ。一方で、「なぜ安定した識別子が必要なのか。」という理解は知識である。また、「この層にビジネスロジックを書く。」というのもルールだが、「なぜその境界で責務を分けるのか。」という設計思想は知識である。

知識があれば、新しい状況でも判断できる。ルールしかなければ、ルールの外側に出た瞬間に立ち止まってしまう。ルールは知識から生まれる。しかし、知識はルールだけでは生まれない。

では、その知識をAIにどう活かしてもらえばよいのだろう。知識をそのままルールに書き換えてしまえば、結局は答えを列挙することになる。もちろん、それも必要だ。しかし、それだけでは知識は使われない。知識は、必要な場面で引き出されて初めて価値を持つ。だから最近は、AIに与えるべきものは答えではなく、「問い」なのではないかと思うようになった。

例えば、「この設計は変更しやすいだろうか」「この責務は本当にここに置くべきだろうか」「ドメインを正しく表現できているだろうか」「他の選択肢は検討しただろうか」。これらは答えを固定するルールではない。AIが知識を引き出し、状況に応じて判断するための問いである。

優れた設計者は、膨大なルールを暗記しているわけではない。設計原則や経験をもとに、その場に応じた問いを立てながら判断している。AIにも同じことが言えるのではないだろうか。

ルールは品質を安定させる。知識は判断を支える。問いは、その知識を引き出す。この三つは対立するものではなく、それぞれ役割が違う。

それでも、もし「AIに何を育てるべきか」と問われたら、私はまず判断を支える知識に時間を使いたい。そして、その知識を必要な場面で引き出せる問いを、一緒に育てていきたい。それが、今の私にとっての「AIを育てる」ということなのだ。

実装が速くなるほど、理解の価値は上がる

Thu, 18 Jun 2026 08:53:24 GMT

「AIが設計して、AIが実装する未来」の話をよく見かける。

AIによる実装支援は素晴らしいし、自分も日々その恩恵を受けている。
それでも時々、ソフトウェア開発とは設計を実装へ変換する作業なのだろうか、と考える。

現場での開発は、設計してから作るというより、作りながら学ぶことのほうが多い。
実装して、気づいて、設計を変える。その繰り返し。

だとすれば、開発は正解を作る活動というより、学習する活動だということになる。

Peter Naur の theory building と近い話かもしれない。
プログラミングとはコードを書くことではなく、そのシステムについての理論を築く活動だという考え方。

AIが加速しているのは主にコードを書く工程である。
一方で、その理論を作る工程は、作りながら気づき、理解を深める過程そのものなので、そう簡単には短縮できない。

もちろん、自分も例外ではない。

AIのおかげで以前よりずっと速くコードを書けるようになった一方で、その速度に理解が追いついているかと聞かれると、自信はない。実装が速くなること自体は歓迎している。そのうえで、速くなるほど「なぜこうなっているのか」を説明できることの価値は、むしろ上がるのだと思う。

開発が学習する活動なのだとすれば、最後に希少なのはコードではなく、その背後にある理論なのかもしれない。

観測者は割り込まない ― WebView 向け dev コンソールを作って見えてきたこと

Fri, 12 Jun 2026 12:44:59 GMT

自前の WebView 用 dev コンソールを作っていて、何度も同じ失敗をした。

レスポンスを観測したつもりが、body を壊す。
エラーを拾ったつもりが、framework の制御フローまで赤く表示する。
デバッグツールが、アプリと一緒に落ちる。

原因はどれも同じだった。観測者が、対象に割り込んでいた。

補足すると、オンデバイスで使える定番として eruda / vConsole があり、実装からは多くを学んだ（後で出てくる技法のいくつかは、ソースを読んで参考にしたもの）。ただ自分の用途とは前提が噛み合わない部分があって、最終的に fetch / console を patch する自前のコンソールを vanilla（依存ゼロ）で作ることにした。

この記事は「ツールの紹介」ではなく、そこで得た「割り込まない観測」の知見をまとめたもの。

fetch のレスポンスは clone() で裏読みすると壊れることがある → Proxy 観測
既存 OSS は「利用する」だけでなく「ソースを読む」ことで得られるものがある（技法を参考にし、設計上のトレードオフを理解する）
dev ツールは対象から独立させる（vanilla + shadow DOM + global patch）
「見えてるこの要素は DOM のどこ？」を一発で解決する（Pick）
エラーバッジの精度は preventDefault を尊重して保つ

1. fetch のレスポンスは clone で読むと壊れることがある

ネットワークを覗くには window.fetch を patch して body を記録したい。Response.body は一度しか読めないストリームなので、clone() して裏で読むのが定石に見える。

window.fetch = async (...args) => {
  const res = await origFetch(...args)
  res.clone().text().then(body => record(body)) // 裏で body を読む
  return res
}

ところが fetch を使うライブラリ（自分の場合は connect-web + React Query）は、レスポンスを読み終えると AbortController.abort() で後片付けをする。これ自体は正しい振る舞い。問題は裏で走らせていた clone().text() の方で、まだ読んでいる最中に中断され、AbortError で失敗する。body が取れないどころか、誰も catch しない rejection としてコンソールに残る。

Proxy 観測

「裏で先読みする」のをやめて、原本の Response を Proxy で包み、消費側が text()/json()/arrayBuffer() を呼んだ“結果”を観測する。差し替えないので透過で、先読みしないので abort レースも起きない。

const proxyResponse = (res) =>
  new Proxy(res, {
    get(target, prop) {
      if (prop === 'json') {
        return async () => {
          const v = await target.json()
          record(JSON.stringify(v)) // 消費側が読んだ瞬間に観測
          return v
        }
      }
      // text / arrayBuffer も同様にフック
      const value = Reflect.get(target, prop, target)
      return typeof value === 'function' ? value.bind(target) : value
    },
  })

window.fetch = async (...args) => proxyResponse(await origFetch(...args))

肝は「観測者は割り込まない」こと。消費側から見ると返ってくる Response は本物と区別がつかない（フックしないメソッドは全部 Reflect.get + bind で素通し）。フックしたメソッドだけ薄く包んで、実際に読まれた値を記録する。先読みしないので、誰も読まなければ何も起きない＝壊れない。res.url / redirected / body ストリーム / bodyUsed も保たれる。

振り返ると、clone() 自体が悪かったわけではなく、問題は「観測のために、対象を読む“もう一人の消費者”を増やした」こと。観測者が消費者として振る舞った瞬間に、もう割り込んでいる。Proxy 観測は「消費者を増やさず、本来の消費者が読んだ結果に相乗りする」という、その一点を守るための道具。

ちなみに XHR（axios 等）は responseText がそのまま読めるので、Proxy も abort 対策も不要。fetch だけが特殊だった。

2. 既存 OSS は「利用する」だけでなく「ソースを読む」

オンデバイス dev コンソールには eruda / vConsole といった定番がある。最初はそのまま使えばと思っていたが、自分の用途（API が connect-web、データ取得が React Query）では噛み合わない点があり、結局 vanilla で自作することにした。

その過程で効いたのが、既存 OSS を「利用する」だけでなく「実装のリファレンスとして読む」ことだった。読むと、採用したい技法もあれば、自分の用途では前提が合わない実装も見つかる。たとえば 1 の Proxy 観測は既存実装から参考にした技法だし、一方で「レスポンスを clone で先読みする」アプローチは、自分のケースでは abort レースの原因になり得ると分かった。どちらも、自分の設計判断に根拠を与えてくれる。

ソースを読む過程で気づいた点は、実際に upstream へ修正提案として送ったりもした。車輪の再発明をしながらでも、読む習慣があると各所の「なぜ」が埋まっていく。

3. dev ツールは対象から独立させる

dev ツールを React コンポーネントとしてアプリのツリーに載せると、アプリが壊れた時にツールも一緒に死ぬ。一番ツールが欲しいのは「アプリが壊れた時」なのに、だ。

なので UI も含めて vanilla DOM + global patch（fetch/console の差し替え）+ shadow DOM で組み、アプリのフレームワークに一切依存させない。shadow DOM はアプリの CSS と相互汚染しないための隔離でもある。eruda / vConsole が vanilla なのも、突き詰めると同じ理由だと思う。

4. 「見えてるこの要素は DOM のどこ？」を一発で

小画面で DOM ツリーを手で展開して目的の要素を探すのは苦痛だ。DevTools の inspect（要素ピック）が効く。

実装は意外と素直：inspect モード中、ページのタップを capture phase で横取りして（document.addEventListener('click', handler, true) ＋ preventDefault でアプリの onClick を抑制）、event.target の要素を取り、その getBoundingClientRect() で枠を被せるだけ。eruda はこれをリッチな overlay でやっているが、ただの枠なら数十行で済む。

「画面で見えてるこれ → DOM のどこ？」を一発で解決できると、モバイルの DOM デバッグは一気に楽になる。

そしてこれも、突き詰めると観測者の話。DOM ツリーを書き換えて目的の要素を探すのではなく、ユーザーが見ている要素を観測するだけに留めている。ハイライトの枠も pointer-events: none でページ操作を邪魔しない。inspect 中だけはタップを preventDefault で借りるが、これは恒常的な副作用ではなく「その瞬間だけの明示的な横取り」で、DOM には手を入れない。「探す」ために対象をいじらない、という意味で 1・3・5 と地続きな気がしている。

5. エラーバッジの精度は preventDefault を尊重して保つ

コンソールに「エラー件数バッジ」を出すと、window.error / unhandledrejection を拾って数えたくなる。が、そのまま数えるとフレームワークの制御信号まで赤くカウントしてしまう。

たとえば Next.js の redirect() は内部的に NEXT_REDIRECT を throw する。これは制御フローであってエラーではない。framework 側は event.preventDefault() でこれを「handled」扱いにし、ネイティブのコンソールには出さない。

ところが自前のリスナは preventDefault されても発火するので、何もしないと「ネイティブには出ないのに自前ツールにだけ赤いエラーが出る」状態になる。

対処は、event.defaultPrevented（先に別ハンドラが handled 扱いにしたか）を見て、handled なら warn に格下げ＝エラー件数に数えない。「見せる」自体は残す（dev コンソールの価値は「ネイティブが隠すものを見せる」ことなので）が、赤いバッジ＝本当に未処理の異常、という線をはっきりさせる。

まとめ

レスポンスを覗くなら clone より Proxy 観測（透過・abort レースを踏まない）
既存 OSS は「利用する」だけでなく「ソースを読んで技法を参考にし、設計上のトレードオフを理解する」対象にできる
dev ツールは対象から独立（vanilla + shadow DOM + global patch）させると、アプリが壊れても死なない
inspect（Pick）は click capture + getBoundingClientRect で素直に作れる
エラーバッジは preventDefault を尊重すると「未処理の異常」アラートとして信頼できる

冒頭の三つの失敗は、結局ひとつの原則に還元できた。観測者は割り込まない。

対象を壊さない ── body を消費しない（Proxy 観測）
運命を共にしない ── アプリと一緒に死なない（vanilla + shadow DOM + global patch）
意味を上書きしない ── 対象が handled とした信号を再解釈しない（preventDefault を尊重）

この三つを守ると、観測ツールは「アプリが壊れた時にこそ使える」道具になる。逆に言えば、ブラウザを patch して観測する footgun は、たいてい「どこかで対象に割り込んでいる」に還元できた。その一つ一つに「なぜ割り込んではいけないか」を詰めるのが、そのまま勉強になった。

面白かったのは、この原則を意識する前は、全部が個別のバグに見えていたこと。fetch の AbortError、Next.js の redirect が赤く出ること、DevTools の UI をアプリから分離すること──最初はバラバラの問題として、その都度パッチを当てていた。

個別の対処を覚えるより、「観測者は割り込まない」という原則を持っておく方が応用が利く。今回の三つの問題は、結局その一文に還元できた。