どうもー、おはようございます。マイクです。
朝7時をまわりました。2026年6月10日、水曜日の「zenncast」、今日も元気にお届けしていきます。

この番組では、Zennに上がっているトレンドの記事から、開発者のみなさんの役に立ちそうなネタをピックアップしてご紹介していきます。通勤・通学のおともに、コーヒー片手に、ゆるっと聞いていってください。

さて、今日はZennの記事を……全部で5本、ご紹介していきます。どれも開発効率とか、設計のワークフロー、AIエージェントの裏側みたいな、ちょっとニヤッとしてしまうテーマが揃ってますので、お楽しみに。

ではさっそく、1本目からいきましょう。

1本目は「Docker Buildを106秒→44秒、32秒→3秒に高速化した3つの改善」という記事です。
タイトルからして開発者の心を鷲掴みなんですが、「ビルドが遅くて待ち時間つらい問題」を、かなりがっつり解決したお話ですね。

構成としては、Next.jsのフロント1台と、Goのバックエンドが2台、さらにGoのワーカーが1台という、わりとヘビーなCompose構成。これをDocker Composeで一気にビルドしていたら、キャッシュなしで106秒、キャッシュありでも32秒かかっていたと。開発でこの待ち時間は、かなりストレスですよね。

そこでやったことが3つ。
1つ目は「.dockerignoreでBuild Contextを削減」。特にNextの .next と node_modules を丸ごと除外して、なんと1.5GBくらい軽くしたと。コンテキストが太りがちなプロジェクトほど、ここが効くよ、という実測付きです。
2つ目はDockerfileの構成見直し。go.modとgo.sumだけ先にCOPYして go mod download を実行、そのあとに必要なディレクトリだけCOPYして、Layer Cacheを最大限に活かすやり方。Goでよくやるベストプラクティスを、ちゃんと全サービスに効くよう組み直しています。
3つ目がBuildKitのcache mount。GOCACHEとGOPATH/pkg/mod をマウントして、依存取得とコンパイル結果をキャッシュして再利用することで、キャッシュありビルドを一気に高速化。

この3つを組み合わせた結果、キャッシュなしビルドが106秒から44秒、キャッシュありは32秒から3秒まで短縮。特にコンテキスト削減のインパクトが大きかった、というのが面白いですね。「とりあえず.dockerignoreにnode_modules入れとくかー」くらいで終わらせずに、どれくらい減ったか・どれくらい速くなったかを数字で出してくれているので、自分のプロジェクトでも真似しやすい内容になっています。

Dockerビルドにモヤモヤしている方は、まずはコンテキストのダイエットから試してみよう、と思わせてくれる記事でした。

。。.。。.。。.。.

続いて2本目、「設計資料をHTMLで回す — 生成・レビュー・社内共有のワークフロー」という記事です。
ふつう「設計資料」と聞くと、Markdownとかスプレッドシートを想像すると思うんですが、この記事の著者はなんと「HTMLファイル1枚」で完結させる、というスタイルを試しています。

HTMLにするメリットとして挙げられているのが、表・図・ちょっとしたインタラクションまで、ぜんぶ1ファイルに収まること。そしてその1ファイルをどこかに置いて、URLひとつで共有できること。さらに、エージェント──つまりAI側にも扱いやすいフォーマットだ、という位置づけになっています。

おもしろいのが、独自のスキルで「コメント機能付きHTML」を生成しているところです。設計書の中で、気になるところを選択してコメントを書いておくと、そのコメントを一覧から選べて、「プロンプト生成」ボタンを押すと、コメント内容がMarkdown形式の修正指示に変換される。それをそのままClaude Codeに渡して、設計の改訂を回していく、というワークフローになってます。

レビューコメントを二度書きしなくていい、っていうのがポイントですね。「レビューコメント」と「AIに渡す指示」が同じものになっているので、レビューの生産性がぐっと上がる仕掛けになっています。

社内共有のところも作り込みが細かくて、CloudFront + S3 + Cognitoの基盤の上に、このHTMLをpublishするスキルを用意。タイムスタンプ付きでバージョンを区別するURLと、常に最新に向く安定URL、その2系統で運用しているという話です。さらにHTMLの中にMarkdownコピペ用のテキストも埋め込んでおいて、そこから各リポジトリのエージェントに渡す、と。

全体として、「設計の正」をGitリポジトリから切り離して、社内どこからでも参照できる場所に置く、そのための具体的なワークフローを示してくれている記事でした。ちょっとした個人プロジェクトではもちろん、チーム開発での設計レビューをAI込みで効率よく回したい方には、かなり刺さる内容だと思います。

。。.。。.。。.。.

3本目は、「『Claude Code』を支える技術」という記事です。
これは、コードを書くAIエージェント「Claude Code」の裏側のアーキテクチャを、論文ベースでうまく噛み砕いて解説してくれている内容ですね。

いちばん印象的なのが、「AIが次の行動を考えている部分は全体の1.6%しかない」という指摘です。残りのほとんどは、安全に・快適に・ちゃんと役に立つ形で動かすための「ハーネス」なんだと。
つまり「賢いモデルをどう縛るか」ではなく、「モデルにはわりと裁量を与えつつ、その周りをどれだけしっかり作り込むか」が重要なんだ、という哲学が中心にあります。

基本構造は、「モデル呼び出し → ツール実行 → ループ」という、とてもシンプルなもの。これに対して周辺に、
・最初は全部禁止から始めるようなdeny-firstのパーミッション設計と、人間の承認回数をなるべく減らす工夫
・コンテキストの消費量に応じて段階的に情報を増やしていく拡張手段
・ベクトル検索に頼らず、MarkdownベースのCLAUDE.mdというメモリと、5段階のコンテキスト圧縮
・Git worktreeを使った、コンテキストを分けて動くサブエージェント
・JSONL形式でのセッション永続化と、「一度許可した操作をむやみに復元しない」ための設計
こういったものが配置されています。

記事の後半では、こうした仕組みをおおよそ300行のPythonで再現してみせていて、MockLLM、Agent、PermissionGate、Tools、Context、Transcriptといった構造で、自分たちのエージェントにも応用できる形に落とし込んでいます。

「LLMのプロンプトをどう工夫するか」で悩みがちなんですけど、この記事を読むと、「モデルはそこそこ賢い前提で、その外側のハーネスをどこまで真面目に設計するか」が本質なんだな、と背中を押される感じがあります。自前でエージェントを作ろうとしている人には、かなり参考になる内容ですね。

。。.。。.。。.。.

4本目は、「マルチテナント化のために本番稼働中のMySQLをPostgreSQLに移行した話」という記事です。
マルチテナント化の連載の第2回で、今回は「PostgreSQL移行編」。実際に動いているサービスのDBを、MySQLからAurora PostgreSQLに乗り換えた、かなり実戦寄りの記録になっています。

目的は、Row Level Security をDB層でしっかり効かせるため。そのためにPostgreSQLへの全面移行が必要になったんですが、pgloaderみたいなツールを使うと、プロダクト固有の暗号化や型変換に追従しにくい、という課題があったと。そこで選んだのが「RailsのActiveRecord経由でコピーする」というアプローチです。

手順としては、まず database.yml を3階層構造にして、dev / test / CI でMySQLとPostgreSQLを切り替えられるようにする。
次に、PostgreSQL用のマイグレーションを別ディレクトリに整備していく。
そして、wrapperモデルとrakeタスクを用意して、両方のDBに同時接続しつつ、並列コピーと検証をかけていく。
こういう段階移行の流れで、本番カットオーバーに向けて準備していきます。

本番切り替えのときは、ちゃんとメンテナンス時間を確保して、環境変数とdatabase.ymlを切り替えてカットオーバー。旧MySQLはすぐには消さず、切り戻し用として残しておく、という慎重な運用になっています。

移行後に見つかった問題としては、ロケールの違いによって並び順が変わってしまったことと、STI（Single Table Inheritance）のテーブル移行漏れ。このあたりの対応が細かくて、照合順序をCに統一して不意の並び替えを防ぐ、STI親を継承したwrapperでinheritance_columnを無効化する、テーブル名の列挙とモデル列挙を突き合わせる仕組みを作る、移行スクリプトと検証スクリプトをあえて別系統にして、バグの道連れを防ぐ、など、かなり実践的なノウハウが詰まっています。

最後に、「ロケールは要件に基づいて明示的に選ぶ」「ActiveRecord規約外のモデルはとくに棚卸しする」「検証は移行と別実装で行う」という教訓がまとめられていて、これからDB移行に挑むチームにはチェックリスト的にも読める内容になっています。

。。.。。.。。.。.

そして5本目、「Claude Code のトークン削減を実測した — semble 93%・cacheRead 1800倍の内訳」という記事です。
GitHub Copilotの料金改定をきっかけに、「Claude Codeでどれだけトークンを節約できているのか」を、ちゃんと数字で測ってみたレポートになっています。

やっている施策としては、プロンプトキャッシング、モデルルーティング、サブエージェント分離といった定番に加えて、
1つめに、ルールを「常時読み込み」と「オンデマンド」に分離して、コンテキストの圧縮を図る。
2つめとして、セッションログから「よく出る失敗」や「効いている指示」を抽出・整理する rule-mining。
3つめに、専用スクリプトで削減効果を定量計測する。
この3つの独自工夫が紹介されています。

計測結果がなかなかインパクトがあって、ccusageでの集計によると、累計のcacheReadが136億トークン。これがそのまま節約換算で約122億トークンに相当する、と。
一日あたりで見ると、モデルへの入力が45万トークンくらいなのに対して、cacheReadが8億トークン。ざっくり1800倍の効果が出ているということで、「プロンプトキャッシングの運用をちゃんと設計するとここまで効くのか」というのがわかる数字になっています。

さらに、コード検索用MCPサーバーのsembleの実ログから、「全部のファイルを読ませた場合」と「必要なスニペットだけ取得した場合」を比較。全読みだと830万トークンくらい行くところを、スニペットで約50万トークンに抑えて、93%・約780万トークンの削減、という具体例も紹介されています。

まとめとして、「既存の手法を入れれば終わり」ではなくて、
・常時読み込むルールをなるべく減らす
・失敗パターンをこまめにルール化していく
・その効果を定期的に計測して、運用として回し続ける
この3つを回していくことで、トークン削減が一過性ではなく、ちゃんとした運用文化として根づいていくんだ、というメッセージになっていました。AIツールのコストが気になり始めた方には、かなり刺さる話だと思います。

。。.。。.。。.。.

というわけで、今日のzenncastでは、

・Docker Buildを.dockerignoreやBuildKitのcache mountで爆速化した話
・設計資料をHTML1ファイルで回して、レビューとAIエージェント連携を一気通貫にした話
・Claude Codeの裏側で、「賢いモデル×強いハーネス」をどう作っているかという技術解説
・本番稼働中サービスのMySQLをPostgreSQLへ、ActiveRecord経由で段階移行した実録
・Claude Codeのトークン削減策を実測して、cacheRead1800倍・sembleで93%削減を確認した話

この5本をご紹介してきました。

気になる記事があった方は、詳しくはショーノートにまとめてありますので、あとでじっくりチェックしてみてください。通勤時間のちょっとしたインプットにもいいと思います。

番組への感想や、「このテーマもっと深掘りしてほしい」「こういうジャンルも取り上げてほしい」といったリクエストも、ぜひお待ちしています。あなたの一言が、次回のラインナップを決めるかもしれません。

それでは、そろそろお別れの時間です。
水曜日の朝、ここまでのお相手はマイクでした。
次回のzenncastでまたお会いしましょう。いってらっしゃい！