どうも、マイクです。
時刻は朝七時を少し回ったところ、二千二十六年八月二十二日、土曜日。
ここからの時間は「zenncast」、きょうも元気にお届けしていきます。

この番組では、Zennに上がっているテック系の記事の中から、その日のトレンドや面白いテーマをピックアップして、ラジオ感覚でゆるっとご紹介していきます。通勤・通学中の方も、おうちでゆっくりされている方も、耳だけ貸していただければオッケーです。

さて、きょうはお便りはお休みなので、そのぶんガッツリと記事の紹介に時間を使っていこうかなと思います。

きょうご紹介する記事は、ぜんぶで五本です。
AIの自動メモリ管理のお話から、ChatGPTとCodexの賢い使い分け、NGワードフィルタの設計論、TypeScriptコンパイラの中身、そしてAIとブラウザ自動操作を組み合わせたドキュメント自動生成の事例まで、かなり盛りだくさんのラインナップになっています。

それでは、一つずつ見ていきましょう。

。。。。

まず一本目。
最初は、claude の「自動メモリ」がどんな仕組みで動いているのかを、実際のファイル構造を調べながら丁寧に解説している記事です。

ポイントになっているのが、`MEMORY.md` というファイルの役割なんですね。
この `MEMORY.md` だけが毎回必ず読まれる、いわば「目次ファイル」になっていて、ここに書かれている一行ずつのフック文だけが、それぞれのメモリファイルへの入り口になっている。つまり、どれだけ中身が正しくて役に立つメモリファイルを作っていても、このフックの一行がズレていたり、リンクされていなかったりすると、一生そこにはたどり着けない、という構造になっているんです。

で、この自動メモリを放置していると何が起きるか。
たとえば「このタスクはここまで進んだよ」という進捗メモとか、「このプルリクがマージされるまでは、この仕様に注意」みたいな条件つきの警告メモが、作業がもう終わっているのにずーっと残り続けてしまう。
すると、AIから見ると「知らないので調べる」んじゃなくて、「知っているつもりで、でもそれが間違っている」という状態になってしまって、ない方がマシなウソの記憶になってしまうんですね。

純正で用意されている `/consolidate-memory` っていうスキルもあって、これは重複したメモリをまとめたり、リンク切れを整理したりはしてくれるんですが、Issue とかプルリクエストが本当に完了したかまでは追いかけてくれない。
なので、そういう「進捗メモの賞味期限切れ」みたいな情報は、自動ではきれいにならないんです。

そこで筆者の方が自作しているのが、`memory-inventory` というスキル。
これがかなり本格的で、まずはメモリ全体のバックアップを取るところから始めて、行数とかバイト数、孤立しているファイルがないか、といった実測を行います。
そのうえで、Issue や PR の状態、さらにはコードの内容まで使って「このメモはまだ鮮度があるのか」「もう役目を終えているのか」を検証していく。
で、怪しいからといって即削除はせずに、カテゴリごとにユーザーに確認をしながら、役目を終えたものはアーカイブ側に退避させる。`MEMORY.md` の目次のほうをギュッと圧縮して、現役で使うメモリだけがすぐ参照されるようにする、というフローを設計しています。
ポイントは、「削除しないで安全な場所に移す」「目次をスリムに保つ」という二つを両立しているところですね。

もうひとつ大事な観点として、メモリの中には、本来はチーム全員が守るべきルールやガイドラインが紛れ込んでしまいがち、という話も出てきます。
そういった「チームの共通ルール」系の内容は、個々人のローカルメモリに置いておくのではなく、`.claude/rules/` のようなルール専用の場所に移した方がいい、と。
これによって、「ある人のローカルメモリにしか書いてないから、その人にしか通じないルール」にならないようにしていくわけですね。

整理の頻度については、やりすぎても文脈が潰れてしまうので、月に一回くらいの棚卸しがちょうどいいんじゃないか、という提案です。
日々の小さい修正はイベントドリブンでこまめにやりつつ、月一でどかっと棚卸しする。この組み合わせが、AIメモリの鮮度を保つにはバランスがいい、というお話でした。

。。。。

続いて二本目。
こちらは、ChatGPT と Codex をどうやって上手に使い分けるか、特に「使える回数」の仕組みの違いに注目した記事です。

前提として、Codex や ChatGPT Work っていう枠は、同じ「エージェント枠」を消費していく仕組みになっている。一方で、ふつうの ChatGPT のチャットは、また別の枠でカウントされる。
この違いをうまく活かすために、「調査とか設計は ChatGPT に任せて、Codex は実装だけに集中させる」と、エージェント枠を節約できる、というのが大きなポイントになっています。

さらに GitHub プラグインを組み合わせることで、ChatGPT からリポジトリのコードや Issue、PR をそのまま読んだり、新しく作ったり、更新したりできます。
これを活かして、「既存コードの調査」「実装計画の作成」「途中段階の PR レビュー」といった、コードを書き換えない系の作業は ChatGPT 側に全部やらせる、という運用にしているんですね。

具体的には、実装前の調査では、`@GitHub` で `owner/repository` を指定して、このリポジトリの中身を前提に実装計画を作ってもらう。
そこで出てきた計画の中で気になるところがあれば、対話しながら詰めていって、いい感じに固まったら、そのまま Issue として起こしてしまう。
PR レビューについても、本番手前の重要なレビューは Codex の `/review` 機能を使ってガッチリやるけれど、途中段階の軽い確認は ChatGPT に任せる、というふうに、役割を分けています。

ここで徹底しているのが、「ChatGPT にはコードの直接編集は基本させない」というルール。
ソースコードの変更は、Codex だけがやる。
これは、ChatGPT 側は差分の確認や、意図しない変更の取り消しといった機能が弱くて、うっかり変なコミットをしてしまった経験があるから、という安全面の理由もあります。実装の最終的な責任は Codex 側、という線引きをしているわけですね。

一方で、ChatGPT が作ってくれた調査結果や設計の計画は、Codex 側から「ChatGPT の会話」としてコンテキストに読み込むことができます。
なので、「調査と設計」は ChatGPT、「実装とレビューの本番」は Codex、と分担しながらも、お互いの成果物はちゃんと共有できる仕組みになっている。

GitHub プラグインを使うときの注意点としては、`owner/repository` だけでなく、対象にする PR 番号や Issue 番号をきちんと明示して、「どのリソースを触っているのか」を一意に指定すること。
これをいいかげんにしてしまうと、別のリポジトリの Issue をいじってしまったり、意図しない PR にコメントしてしまったり、誤操作のリスクがあるので、しっかり指定しようね、という実務的なアドバイスまで含まれています。

。。。。

では三本目。
ここからはちょっとテーマが変わって、NGワードフィルタの話です。
子ども向けのサービスで使うために、作者の方が自作した NG ワードフィルタ「wordguard」を紹介している記事になります。

wordguard は、日本語と英語の NG ワードをカテゴリごとに整理したライブラリで、「暴言」「差別語」「性的な表現」などはきちんとブロックしつつ、一方で「不具合」とか、英語の「analysis」みたいな、普通に使われる単語はできるだけ通す、というバランスをすごく重視しています。

日本語は特に、単語と単語の境目が曖昧だったり、「死ね」「ﾀﾋね」「しねーーー」みたいに、表記ゆれがたくさんありますよね。
英語の世界でも、「Scunthorpe problem」と呼ばれる、「まともな単語の中にたまたま NG ワードっぽい文字列が含まれてしまう」問題が有名です。
こういった事情に対応するために、wordguard では、文字の正規化や、先に通しておく単語の allowlist、あいまいな語を入れる `ambiguous` というカテゴリを組み合わせて、誤検知を極力減らしつつ、本当に有害な表現だけを拾うように設計されています。

さらに、「gay」とか「障害者」といった言葉をどう扱うか、という難しい問題にも、かなり丁寧に向き合っています。
これらは、当事者による中立的な自己指示として使われる場合も多いので、すべて一律に「差別語」としてブロックしてしまうのは違うだろう、と。
なので wordguard では、こうした語を一律に禁止するのではなく、文脈次第で差別にもなりうる「注意が必要な語」として扱う考え方が紹介されています。

また、自傷願望を示すような語については、`selfharm` というカテゴリで検出だけ行い、ブロックするかどうかは別のレイヤーで判断する、という設計にしている。
「誰にとって何が不適切か」は、立場や文脈によって変わるものなので、「万人に通用する完璧な NG ワードリスト」というものは存在しない、という前提を明確にしているんですね。

そのうえで、サービス提供者側が自分たちの用途に合わせてチューニングしやすいように、カテゴリごとに ON／OFF できたり、独自の除外語を追加できたり、テスト用のコーパスを流して挙動を確認できたりと、カスタマイズ前提のライブラリになっているのが特徴だとしています。
単に「悪い言葉を全部弾く」じゃなくて、「どんな価値観でサービスを運営するか」を開発者自身が決められるようにする、という思想が伝わってくる内容でした。

。。。。

四本目にいきましょう。
ここからは TypeScript の内部実装の話です。
TypeScript コンパイラの中で、`.ts` ファイルが `.js` に変換されるまでに、どんな処理が行われているのかを、Express の Hello World を例に追いかけている記事です。

コンパイルの流れとしては、大きく五つのステップに分かれています。
まず「Program 構築」でプロジェクト全体の情報を集めておいてから、「Parser」がソースコードをパースして、AST、つまり抽象構文木を作る。そのあと「Binder」がシンボル表を作って、「Checker」が型チェックを行い、最後の「Emitter」が JavaScript のコードを吐き出す、という五段階ですね。

この記事では、それぞれのステージで実際にどんな中間生成物ができているのか、モジュール解決のログ、AST、シンボル表、型情報、最終的な出力 JS といったものを、実際に取り出しながら説明しています。
特に印象的なのが、「型消し」、つまり JS の生成は、ファイル単体でもできてしまうのに対して、「型検査」はプロジェクト全体のファイルを読み込まないといけない、という非対称性の話です。

型チェックは、あるファイルの型を判断するのに、別ファイルの型定義や、モジュールの依存関係を見に行く必要があります。
なので、プロジェクトが大きくなればなるほど、全体をなめる必要がある型検査のコストがどんどん膨らんでいく。
一方で、型の情報さえ決まってしまえば、型を削ぎ落として JavaScript を生成する「emit」のフェーズは、かなり割り切った処理で済みます。

記事の中では、この違いを実際に計測していて、処理時間の大半が Checker、つまり型チェックに費やされていて、emit はごく短い時間で終わる、という結果が示されています。
「コンパイルが遅い」と感じるとき、そのほとんどは「型チェックが重い」という意味なんだ、というのがよく分かる内容です。

この非対称性を踏まえると、現代的な開発スタイルとしては、開発中は esbuild みたいな「型を消すだけの高速ツール」でパッと動かしてしまい、型安全性のチェックはエディタの tsserver とか、CI 上での `tsc --noEmit` に任せるのが理にかなっている、という説明につながっていきます。
つまり、「実行してフィードバックを得るところ」と、「しっかり時間をかけて型を検査するところ」を分けることで、開発体験をよくしよう、という考え方ですね。
TypeScript を普段から使っている方には、「なんでこんな構成になってるんだろう？」という裏側がよく見える記事になっています。

。。。。

そしてきょうのラスト、五本目。
これは、AI とブラウザの自動操作ツールを組み合わせて、Web サービスのスクリーンショット付きガイドブックを自動で生成・更新する仕組みを作ってみた、という事例紹介の記事です。
カテゴリーとしては、かなり実装寄りの Tips 記事ですね。

ユーザー向けのガイドを作るときに大変なのが、「仕様を理解して文章を書く」「スクリーンショットを撮る」「画面が変わるたびに更新する」、このあたりの作業です。
筆者の方は、ここをなるべく自動化するために、コードリポジトリ内のドキュメントや、Playwright のシナリオと連携させて、LLM──ここでは Claude Code──にほぼ任せる流れを作っています。
人間がやるのは、「どこまでをガイドにするか」の範囲指定と、最後のレビューだけ、というイメージです。

具体的な流れとしては、まず LLM にコードを読ませて仕様を理解させ、そこからガイドの本文を書いてもらう。
次に、その本文の中で触れている UI を、Playwright で自動操作しながらスクリーンショットを撮っていきます。
このとき、ただ画面を撮るだけじゃなくて、番号付きの赤い枠を UI に差し込んで、「ここをクリックします」「このボタンを押します」といった注目箇所を強調したスクショを自動生成してくれる。
「本文を起点にスクショを撮る」ことで、文章と画像の食い違いを減らしているのがポイントです。

さらに、「Skill」と呼ばれる AI 用の手順書の中に、「シードデータの確認」「スクリーンショット撮影」「画像の目視チェック」「`git diff` での差分確認」「失敗したときの記録を `learning.md` に残す」といった一連のステップを書き込んで、毎回 AI が同じ型で作業できるようにしています。
これによって、「やる人によって手順がブレる」という人力ドキュメントあるあるを、AI 側のオペレーションでかなり抑え込んでいる形ですね。

Playwright の既存の E2E テスト基盤も上手く流用していて、注釈用の赤枠を DOM に差し込んでから `page.screenshot` を呼ぶユーティリティ、いわば「annotate」と「shot」をセットにした仕組みを用意して、章ごとにディレクトリを分けてスクショを自動保存するような構成になっています。

この仕組みを導入した結果として、新機能のガイドを更新するのに、以前は半日から一日くらいかかっていたのが、およそ十五分から三十分程度で済むようになったそうです。
さらに、spec、つまりガイド生成のシナリオを再実行したときに、Playwright の Locator エラーや、画像の差分から「UI が変わったよ」というのがすぐに分かるので、ガイドとプロダクトのズレを機械的に検知しやすくなっている。
「気づいたらドキュメントだけ古くなっていた」という問題を、だいぶ減らせるわけですね。

そして最後に、ガイドをプロダクトのコードと同じリポジトリで管理することで、「ユーザー向けの説明テキスト」自体も AI の参照情報として活用できるようになる、という話が出てきます。
今後は、プルリクの差分を見て、「この変更に対応するガイドの更新箇所はここだよ」と提示したり、そのままリリースノートを自動生成したり、といったところまで自動化の範囲を広げていけそうだ、という展望で締めくくられていました。

。。。。

というわけで、きょうの「zenncast」は、全部で五本の記事をご紹介してきました。

おさらいしておくと、
まずは、claude の自動メモリの実ファイル構造を調べて、`MEMORY.md` の一行フックと、`memory-inventory` による安全な整理フロー、月一の棚卸しの話。
次に、ChatGPT と Codex の「エージェント枠」の違いを踏まえた、調査と実装の役割分担、GitHub プラグインでの安全な運用。
三本目は、日本語と英語の NG ワードをカテゴリ分けしつつ、誤検知を抑えるための設計思想が詰まった「wordguard」の紹介。
四本目は、TypeScript コンパイラの Program から Emitter までの五段階と、「型チェックが一番重い」ことを踏まえた、モダンな開発フローの理由。
そして最後は、AI と Playwright を組み合わせて、スクショ付きガイドを十五分から三十分で自動生成・更新する仕組みづくりと、その運用の工夫でした。

気になる記事があれば、詳しい内容や元の記事への導線はショーノートにまとめておきますので、あとでぜひチェックしてみてください。

この番組「zenncast」では、みなさんからの感想や、「こんなテーマを取り上げてほしい」といったリクエストもお待ちしています。
開発中にふと感じたモヤモヤや、「この記事よかったよ！」というおすすめも、気軽に送ってもらえると嬉しいです。

それでは、そろそろお時間です。
お相手はマイクでした。
また次回の配信でお会いしましょう。お楽しみに。