一行目を読まずに、三百五箇所を書き換えた夜
NotebookLM を開いたら、画面の右側が赤でいっぱいでした。
自分で作った Chrome 拡張が、エラーを吐き続けていました。
昨日まで動いていたのに、何もしていないのに、壊れていました。
—
拡張が、赤いエラーで埋まっていた

Claude Code に相談しながら、原因を見にいきました。
エラーの一行目は「undefined のプロパティが読めない」。
よくあるパターンだろう、と見立てました。
Chrome 拡張の API が一時的に無効になったときに出るエラー、と。
じゃあ、ぶつかっても落ちないように、コード全体を守る書き方に置き換えよう。
4つのファイルで、305箇所ありました。
一括置換で、数秒で書き換え終わりました。
拡張をリロードして、NotebookLM を再読み込みして、コンソールを見たら。
まだ、赤かったんです。
—
305 箇所書き換えても、直らなかった

私は、画面のスクリーンショットを Claude に送りました。
自分の目で読んでいたつもりのエラーメッセージを、画像としてそのまま渡しました。
そうしたら Claude が言ったんです。
「これ、undefined じゃないです。
下にちゃんと書いてありますよ。
Extension context invalidated、って」
画面をよく見たら、一行目の下に、別のエラー文が、はっきり書いてありました。
私はそれを読んでいませんでした。
一行目を見て「これはあのパターンだ」と決めつけて、途中から全部スキップしていたんです。
305箇所の置換は、違う問題への対処でした。
だから直らなかった。
—
「一行目の次」を読んでいなかった

正しい直し方は、たった4行のコードでした。
拡張が無効になったときに、監視を自分で止める。
それだけでエラーの連鎖は止まりました。
—
このあと、もう一つバグが出ました。
スライドを Google スライドに送ると、開いていたページが1枚目になってしまう、という現象です。
8ページ目を開いていたら、送られたスライドの1枚目が8ページ目。
順番がおかしい。
原因を探ったら、これも似たような話でした。
画像のサイズで「大きいもの」を選ぶフィルタがあって、現在のページだけが「大きい画像」として扱われていました。
でも、下に並んでいるナビサムネイルをよく見たら、実は全部、元と同じ高解像度のURLを持っていたんです。
「小さく表示されている」けれど「中身は大きい」。
表示サイズだけを見て判断していたから、順序がぐちゃぐちゃになっていました。
ちゃんと URL を見ていたら、すぐに分かる話でした。
—
私は今日、同じような見落としを何度もしていました。
エラーの一行目だけを見る。
画像の表示サイズだけを見る。
「これはあのパターンだ」と決めつける。
私は AI と一緒に開発するようになってから、楽になりすぎたのかもしれません。
エラーメッセージを、最後まで読まなくなっていました。
スタックトレースも、ログも、流し読み。
「どうせ Claude が拾ってくれる」。
そう思っていたと思います。
でも、Claude は、私が見せたものしか見られないんです。
私がスクリーンショットを丸ごと送るまで、Claude もエラーの2行目を知りませんでした。
私が途中から読んでいると、Claude も途中から考えるんです。
—
直したのは、自分の読み方だった

AIが賢くなるほど、投げる前の私の仕事は、むしろ丁寧さが要るのかもしれません。
全部を見る。
全部を読む。
「これはきっとあのパターンだ」と決める前に、一行目の次を、ちゃんと見る。
「見えているもの」がすべてじゃない、というのは、当たり前のことなのに、つい忘れます。
エラーメッセージも、画像のサイズも、表面だけで判断したらそこで止まってしまう。
その下に書いてあることや、内側に持っている中身を、ひと手間かけて確かめる。
本当は、それだけのことなんだと思います。
305箇所の置換は、完全に無駄ではなかった。
一応、null安全にはなった。
でも、焦点がずれた作業を、どれだけ時間をかけても、本当の問題は解決しないんです。
次からは、エラーの本文も、要素の中身も、最後まで見てから動きます。
流し読みで十分な日もあると思うんですが、今日はそうじゃなかった。
Claude と一緒だから速く進めるようになった代わりに、私自身が「一行目の次」を読む筋力を、たぶん少し落としていました。
コードを直した、というより、自分の読み方を直した日でした。

