どうも、マイクでーす。おはようございます。
八月十八日、火曜日の朝七時をまわりました。ここからの時間は「zenncast」、きょうもZennで話題になっているトレンド記事を、ゆるっと楽しく紹介していきます。コーヒー片手に、通勤通学のお供に、最後までよろしくお付き合いください。
さて、きょうはお便りはお休みということで、そのぶんガッツリと記事を紹介していきたいと思います。きょうピックアップする記事は、ぜんぶで五本です。どれも実務に効きそうな内容ばかりなので、気になったものはあとでショーノートからチェックしてみてくださいね。
まず一つ目。
一つ目は、エンジニアの皆さんにおなじみの、エージェント系の開発支援ツールをどう賢く使い分けるか、というお話です。
最近のCodexって、「エージェント利用枠」という回数制限がありますよね。調査から実装計画、コードの生成や修正まで、なんでもかんでも任せていると、あっという間に回数を使い切ってしまう。そこで筆者がやっているのが、**調査・計画・途中レビューといった「コードを書かない作業」はChatGPTプラスGitHubプラグインに任せて、Codexは実装だけに集中させる**という、かなり割り切った役割分担です。
GitHubプラグインを使うと、ChatGPTの画面の中から、リポジトリ内のコードを読んだり、Issueやプルリクエストを参照したり、新しく作ったりできます。なので、実装に入る前のコード調査とか、「どこの関数を触るのがよさそうか」といった実装方針の整理、さらにはプルリクの途中レビューなんかを、自然な会話ベースで進められる。モデルは精度重視でGPTのファイブドットシックス系を使っていて、Issueやプルリクの本文はChatGPTに書いてもらう。その一方で、ソースコードそのものの変更は、誤操作や中途半端なコミットを避けるために、Codexだけにやらせる、という線引きをしているそうです。
さらに面白いのが、ChatGPT側で作った調査メモとか、実装計画の会話ログを、そのままCodexにコンテキストとして渡しているところです。これによって、実装の段階で、また一から前提を説明し直さなくていいので、やりとりのムダがかなり減るんですよね。
一方で、GitHubプラグインを使うときの注意点として、`オーナー名/リポジトリ名` とか、リポジトリのURLをちゃんと明示して、どのプルリク、どのIssueを触ってほしいのかをはっきり指定する。必要であればブランチ名まで書いておくことで、意図しないリポジトリやブランチに対して操作してしまう、という事故を防げると説明しています。
エージェントの枠を節約しながら、生産性は落とさない工夫として、かなり実践的なノウハウがまとまっている記事でした。
。.。.。.
続いて二つ目。
二つ目は、AWSのRDS ProxyをAurora PostgreSQLの前段に入れてみたものの、数か月運用してみた結果、「うちの構成ではデメリットのほうが大きかったので撤去した」という経験談です。使っていたスタックは、NestJSとPrismaセブンの組み合わせですね。
Prismaって、JOINが多かったりすると、生成されるSQLがけっこう長くなりがちなんですが、この記事で判明したのは、**SQLテキストが十六キロバイトを超えると、RDS Proxyのピン留めが頻発して、多重化、いわゆるコネクションの共有がほぼ効かなくなる**という問題です。
CloudWatchのメトリクスと、自前で仕込んだログの計測を組み合わせて調べたところ、全セッションのおよそ二割でピン留めが発生していた。それなのに、Aurora本体の接続数は上限の数パーセントに収まっていて、「そもそも接続枯渇のリスク、そんなに高くないよね」と判断できたそうです。
この十六キロバイトの制限はAWS側の固定仕様で、ユーザー側で変えられない。一方で、Prisma側でSQLを分割したり、長さを制限するような工夫も検討したけれど、挙動が悪化したり、エラーが増えたりして、現実的ではなかった。
ところがPrismaセブンからは、`pg.Pool` をアプリから直接制御できるようになっていて、接続のスパイク対策はRDS Proxyに頼らなくても、アプリ側のプール設定、たとえば最大接続数とか、タイムアウト、アイドル接続の返却ルールなどで、ある程度代替できる状態になっていたんですね。
そこで、Secrets Managerに入れているデータベースのホスト名を、RDS ProxyからAurora本体に書き換えるだけで、すっと直結構成に戻した。これで、毎月数百ドルかかっていたProxyのコストと、ピン留めが原因だった問題の両方を解消できた、という流れです。
筆者はまとめとして、**マネージドサービスだからといって安心しきるのではなく、自分たちのクエリの特徴や負荷パターンと、本当に相性がいいのかを事前に確かめること**。それから、いつでも撤退できるように、接続先を一か所の設定に集約しておくなど、「戻しやすい設計」をしておくこと。そして、定量的なメトリクス計測が、素早い撤去判断にすごく役立ったと振り返っています。
接続をどんどん使い捨てるようなクライアントが多い構成ではRDS Proxyはかなり有効だけど、今回のように、長く生き続けるプロセスにORMが大量のSQLを投げる、という構成だと、思わぬところで相性問題が出るので注意しましょう、というお話でした。
。.。.。.
三つ目。
三つ目は、フロントエンド界隈の話題ですね。Reactが「Async React」で目指している、UI全体を非同期前提で設計する世界に対して、Solidツードットゼロは、違うアプローチで答えを出している、という内容です。
Solidワン系のころは、データフェッチ用の `createResource` とか、`Suspense` みたいに、Reactとよく似た別パーツを組み合わせて非同期を扱っていました。でもバージョンツーでは、そこがガラッと変わっていて、**「いつもの `createMemo` が、そのままPromiseを返せる」ようになったことで、非同期をリアクティブシステムそのものに組み込んだ**、というのがキモになっています。
このおかげで、ロード中のチラつきとか、「このスピナーって、いったい誰のローディングなんだ？」みたいな分かりづらさを、特別なAPIを覚えなくても、フレームワークのデフォルト挙動として、かなりきれいに処理してくれるようになった。
さらに、書き込み、いわゆるミューテーション周りも整理されていて、`action` と `createOptimisticStore` という仕組みで、React側でいう `useOptimistic` プラス `startTransition` にあたる楽観的更新を、シンプルなAPIで表現できます。
加えて、「use server」がコアに入ったことで、サーバー関数の呼び出しも、クライアントからのフェッチも、SSR、サーバーサイドレンダリングも、全部同じ `createMemo` の読み方で統一されている。開発者から見ると、「非同期だから特別な書き方になる」というより、「いつものリアクティブな読み方の一部として、非同期も扱える」という感覚に近いようです。
もちろん制約もあって、非同期の値は `<Loading>` コンポーネントの内側で読む必要があるなど、境界の外では読めない場面もあります。ただ筆者は、Reactがどちらかというとエコシステム側で非同期を抽象化しようとしているのに対して、Solidツードットゼロは、**非同期の調整そのものをフレームワークの標準動作にしてしまった**、そこがとてもおもしろいと評価しています。
Async Reactでこれから入ってきそうな世界観を、一足先に体験できるフレームワークとして、Solidを紹介している記事でした。
。.。.。.
続いて四つ目。
四つ目は、ちょっとオピニオン寄りの事例紹介です。テーマは「Webサービスのガイドブック、どうやって更新し続けるか」。
サービスのガイドブックって、一回作って終わりじゃなくて、機能追加やUI変更のたびに、スクリーンショットを撮り直して、文章も書き換えて……と、更新し続けなきゃいけないのが大変なんですよね。これを人手だけでやると、スクショ撮影もテキスト修正も、かなりの手間がかかる。
そこで筆者は、Playwrightを使ってブラウザ操作とスクリーンショット撮影を自動化しつつ、LLMにコードから仕様を読ませて、本文や撮影用スクリプトを書かせる、というアプローチを取りました。その結果、**スクショ付きガイドブックの生成と更新を、ほぼ自動化できて、作業時間を大幅に短縮できた**と説明しています。
ポイントになったのが、コードや既存のガイド、エンドツーエンドテストなど、AIが判断するための材料と、実際にブラウザを操作するための手段を、一つのリポジトリに集約したことです。これによって、プロダクト側で変更が起きたときにそれを検知しやすくなり、ガイドとの整合性もチェックしやすくなった。そして、AIが「仕様の理解」から「ブラウザ操作」、つまりスクショ撮影まで、一貫して担当できるようになったのが、成功要因だと振り返っています。
筆者は、「AIに業務を任せるには、**正確な情報源と、最後までやり切るためのツールを、どこまできちんと渡せるかが鍵だ**」と言っています。パッと見は自動化なんて無理そうに見える業務でも、前提条件を整えてあげれば、思っている以上に自動化の余地は大きい、というメッセージですね。
ドキュメント運用に悩んでいるチームには、かなり刺さる内容だと思います。
。.。.。.
そしてラスト、五つ目。
五つ目は、Claude Codeのhook機能を使って、**「モデルが書いたMarkdownをすぐに機械的にチェックして、問題があれば必ず書き直させるループ」を組み込む方法**を解説した、Tips系の記事です。ドキュメント多めの現場にはかなり実用的なネタですね。
Claude Codeのhookは、特定のイベントが起きたときにシェルコマンドを実行できる仕組みで、この記事では「PostToolUse」という、Markdownへの書き込みが終わったタイミングのイベントを使っています。そこでtextlintを走らせて、文章品質のチェックを自動で行う、という構成です。
面白いのは、hookそのものはただのコマンドとして動かしていて、LLMスキル、たとえば「meiseki」みたいな別のスキルは直接は呼び出さないようにしているところ。**検出はhook側のtextlintが担当して、修正は元のClaudeセッションに差し戻す**。この役割分担にすることで、余計なLLM呼び出しが増えず、コストやレスポンスの遅延を抑えつつ、柔軟な修正ができるようになっています。
発動条件も工夫されていて、「二重否定が一件以上ある」か、「textlintの指摘が三件以上ある」場合にブロックをかけるようにする。また、対象外のファイルとか、日本語を含まないファイルは、早めの段階で除外して、誤爆を減らしています。
さらに、無限ループや作業が止まってしまう事態を防ぐために、安全弁を三つ仕込んでいるんですね。
一つ目が、「同じファイルへのブロックは二回まで」に制限すること。
二つ目が、「textlint自体がうまく動いていないときは、そのまま素通しする」、いわゆるフェイルオープンの挙動にすること。
三つ目が、「環境変数でいつでもこの仕組みを無効化できる」ようにしておくこと。
こうした設計で、**終了条件と、検査が失敗したときにサービスが止まらないフェイルオープンの考え方を、とても重視している**のが伝わってきます。
また、textlintの検出漏れ、たとえば一部の二重否定が拾えない問題などについては、実際の文章を使ってどれくらい漏れるかを測り、そのうえで辞書を追加したり、自動テストを書いて補正していく。検出ルールに限界があることをちゃんと理解したうえで、hookをどう設計するかが大事だ、という点も示していました。
ツールに丸投げにするのではなく、どこまでを機械に任せて、どこからを人間や別の仕組みで補うか、という設計思想がよく分かる記事です。
。.。.。.
というわけで、きょうの「zenncast」は、五本の記事を駆け足で紹介してきました。
まず、エージェントの回数制限を意識しながら、ChatGPTプラスGitHubプラグインとCodexを上手に役割分担させる話。
それから、Aurora PostgreSQLの前段に入れたRDS Proxyを、SQLの十六キロバイト問題とピン留めの多発をきっかけに、冷静に撤去した事例。
三本目は、Async Reactが目指す世界を、Solidツードットゼロが標準のリアクティブ挙動として先取りしている、というフロントエンドの話題。
四本目は、PlaywrightとLLMを組み合わせて、スクショ付きガイドブックの生成と更新をほぼ自動化した事例。
そして最後に、Claude Codeのhookとtextlintを組み合わせて、Markdownの品質チェックと書き直しループを、安全弁つきで組み込む方法、というラインナップでした。
どの記事も、詳しい内容や具体的な設定の話は、番組のショーノートに載せておきますので、気になったトピックがあれば、ぜひあとでゆっくり読んでみてください。
この「zenncast」では、番組の感想や、取り上げてほしいテーマのリクエストもいつでも募集しています。「こういう失敗談聞きたい」とか、「この技術の事例もっと知りたい」なんて声も大歓迎です。
それでは、きょうも良い一日をお過ごしください。
お相手はマイクでした。また次回のzenncastでお会いしましょう。バイバーイ。