どうも、マイクです。おはようございます。
時刻は朝7時を少しまわったところ、2025年11月29日、土曜日の朝です。
ここは開発者のみなさんの耳のおとも、zenncast。
この番組では、Zennで話題になっているトレンド記事を、ラジオ感覚でゆるっと、でも内容はぎゅっと濃くお届けしていきます。

今日はお便りコーナーはお休みで、そのぶん技術のお話をたっぷりしていきたいと思います。

さて、今日紹介する記事は全部で5本。
WebフレームワークからDockerのベストプラクティス、AI時代のTDD、FastAPIのDI、そしてモノレポ×Honoの最高構成まで、一気に駆け抜けていきます。それではさっそく、1本目からいきましょう。

まず1本目。「Honoの7つのコンセプト」という記事です。
Hono、最近一気に名前を聞くこと増えましたよね。Cloudflare WorkersとかDenoみたいな、Web標準APIベースの環境で動く、軽量・高速なバックエンド向けWebフレームワークです。ポイントは「依存ゼロ」「小さなコア」「拡張前提」の三拍子。最小構成でサイズが約11KBというコンパクトさなのに、Express比で約8倍速いルーティングを実現しているというのが、なかなかインパクトあります。
開発者体験のところも特徴的で、`c.json()` みたいなシンプルなAPIで扱いやすく、TypeScriptの強い型付けもしっかり効く設計。JSXに対応していたり、サーバーを立ち上げなくてもテストができたりと、DXにかなり振っている印象です。
機能拡張は3層のミドルウェア構造で、カスタム・ビルトイン・サードパーティと、必要なものだけインポートして組み合わせるスタイル。Streamingなども含む15種類くらいのヘルパーも用意されていて、「コアは小さく、拡張でリッチに」という思想が徹底されています。
さらにおもしろいのが、AWS LambdaやNode.js向けのアダプターが整っているところ。同じHonoアプリを、Cloudflare Workersだけじゃなく、さまざまなランタイムに展開しやすい設計になっているので、「将来どこに載せるかわからないけど、とりあえずWeb標準APIで書いておこう」みたいな選択肢が取れるんですよね。軽量・高速・ポータブル、このあたりを重視している方には、かなり刺さる内容になっています。....

続いて2本目。「そのDockerfile、卒業しよう 実務で通用するベストプラクティス」という記事です。
これは特にGoアプリを例にしながら、「重い・遅い・危ないDockerfile」から卒業しようという実務目線の話。キーワードはマルチステージビルドと、キャッシュを意識したレイヤー設計、それからセキュリティとイメージサイズの最適化です。
まず、ビルド環境と実行環境を分けるマルチステージビルド。開発用・ビルド用の重たいツール群はビルドステージの中だけに閉じ込めて、実行用イメージにはビルド成果物だけをコピー。これでイメージがぐっと小さくなって、不要なツールが入らないぶん攻撃面も狭くなる、という考え方ですね。
さらに、go.mod / go.sum だけ先にコピーして `go mod download` するとか、変更頻度の低いファイルを前のレイヤーに置いてキャッシュを効かせる工夫。RUN命令を細切れにしすぎず、関連処理は1つにまとめてレイヤーの無駄な増殖を防ぐ、といったレイヤー設計のコツも整理されています。
セキュリティ面では、.dockerignoreで.gitやテストコード、ドキュメントなどを除外してビルドを軽くしつつ、実行用にはdistrolessイメージを使って最小構成を実現。そしてUSER命令でroot以外のユーザーに切り替えることで、ランタイムの権限を絞る、と。このあたりは実務での「なんとなく怖い」をきちんと形にしてくれている感じです。
仕上げとして、Docker Scoutでの脆弱性スキャンや、HadolintみたいなLinterをCIに組み込んで、Dockerfileの品質をチームで標準化していこう、という提案もあります。記事中の例では、916MBのイメージが31.4MBまで削れるという劇的な結果も紹介されていて、「そろそろ自分のDockerfile、本気で見直すか……」と思わされる内容でした。....

3本目。「『AIに先にテストを全部書かせる』はTDDじゃない。でも、それもアリだよね。」という記事です。
タイトルからして今っぽいテーマですが、中身はかなり丁寧に「TDD」と「テストの事前一括作成」の違いを整理しています。TDDって、Red-Green-Refactorの短いサイクルを何度も回していくことで、設計を“育てていく”手法なんですよね。最初はざっくりしたテストから始めて、徐々に要件を細かくしていく。そこで得られるのは「動作する、きれいなコード」。
一方で、AIに「この仕様でテスト全部書いて」とお願いして、先にどーんとテストを用意してから実装していくやり方。これはTDDの文脈では昔から「手戻りが増えてつらい」とされてきたスタイルですが、AI時代だと意味合いが変わってきている、という指摘がされてます。AIにとって、「こういうテストが通るようにコードを書け」というのは、めちゃくちゃ明確な指示になるんですよね。
この記事では、「不確実性が低いところ」と「高いところ」をちゃんと分けようと言っています。たとえばバリデーションとか、仕様がギュッと固まっているところでは、AIに受入テストを一括で作ってもらうのは全然アリ。一方で、注文処理みたいなビジネスロジックが複雑で、まだ仕様が揺れているところは、やっぱりTDDで一歩ずつ設計していく方が安全。
そして最終的な提案は、「受入レベルのテストはAIと一括生成しつつ、詳細な実装はTDDで進める」とか、問題の不確実性にあわせて両者を組み合わせるスタイル。AI時代だからこそ、「全部AIに投げる」か「全部昔ながらのTDD」かではなくて、その中間をうまく設計していこう、というのがメッセージになっています。....

4本目は「FastAPIのテストコードを書いてDIの重要性を知った話」という記事です。
FastAPIを書いている方だと、「`db: Session = Depends(get_db)` って、正直おまじないっぽく使ってたなぁ」という人も多いと思うんですが、筆者もまさにその一人。ところが、いざテストコードを書き始めると、この「Depends」とDI（依存性注入）のありがたみを痛感した、というエピソードになっています。
エンドポイントって、認証、DB接続、外部サービス……と、いろんな依存を抱えてますよね。全部を `monkeypatch` で差し替えるのは、テストがカオスになりがち。そこでFastAPIが用意している `app.dependency_overrides` を使って、DBセッションを返す `get_db` だけをテスト用の実装に差し替える。これだけで、開発用コードを1行も触らずに、エンドポイント全体をテストできるようになるんですね。
要は、「依存の強いオブジェクトをちゃんと引数として受け取る」というDIの設計にしておけば、テストのときはその引数を置き換えるだけでいい。テストのために本番コードを汚さなくていいので、保守性も格段に上がります。筆者はこの体験を通じて、「あ、DIってテストのしやすさそのものなんだ」と腹落ちしたと語っています。
一方で注意点として、FastAPIの `Depends` はあくまでエンドポイント関数で使う仕組みであって、それ以外の場所で乱用すると予期せぬバグの温床になるよ、という警鐘も。フレームワークの便利機能に乗っかりつつ、境界線はちゃんと意識しよう、というバランス感覚が伝わる記事でした。....

そして最後、5本目。「モノレポ＋Hono＋OpenAPIスキーマ駆動(Orval)+Drizzleは最高」という記事です。
これはフロントとバックをモノレポでまとめて開発している方には、かなり刺さる構成の話。バックエンドはHonoで、フロントはNext.js。そのうえで、「Hono＋OpenAPI駆動開発（Orval）＋Drizzle」という組み合わせが、DX的にめちゃくちゃ心地よい、という内容です。
まず設計としては、バックエンドはクリーンアーキテクチャの4層構成。OpenAPIを唯一の仕様書として扱い、OrvalでZodスキーマとmodel.*型を自動生成します。このmodel.*を、HonoのルートでのzValidator、Controllerやhandler、さらにフロント側からの呼び出し、テストコードまで、全部で共通利用する。つまり「仕様＝型＝実行時バリデーション」が一本化されていて、「どの型が正なんだっけ？」問題が起きにくいんですね。
Drizzleは、リッチなドメインモデルをそのまま永続化する役割を担いつつ、エンティティとOpenAPI用の型、永続化用の型の変換をちゃんと層の中で分担。責務がはっきりしているので、設計が崩れにくい構造になっています。
さらに、Honoの推奨である関数ベースのDIと、factory handlerパターンに移行したことで、プレゼンテーション層は極力薄く保ちつつ、`c.req.valid()` で「すでにバリデーション済みの値」を扱えるのもかなり快適。
フロント・バック・テストが同じmodel.*を見ているので、仕様変更があったときも、コンパイルエラーや型エラーがそのまま「影響範囲の地図」になる。ここが筆者の推しポイントで、「コミュニケーションコストが下がりまくるから、この回路をぜひ真似してみてほしい」と強くすすめています。モノレポで型を起点に開発したい人には、かなり参考になる構成だと思います。

というわけで、今日紹介したのは、
Honoの7つのコンセプト、
Dockerfileの実務ベストプラクティス、
AI時代のTDDとテスト一括生成の付き合い方、
FastAPIを通して見えてきたDIの重要性、
そしてモノレポ×Hono×OpenAPI×Drizzleの最高構成、
この5本でした。

気になる記事があった方は、詳しい内容や元の記事への導線をショーノートにまとめておきますので、あとでゆっくりチェックしてみてください。
番組の感想や、「こんなテーマ取り上げてほしい！」というリクエストも、いつでもお待ちしています。あなたの開発現場での気づきや、失敗談なんかも、ぜひ共有してもらえると嬉しいです。

それでは、そろそろお別れの時間です。
ここまでのお相手はマイクでした。
また次回のzenncastでお会いしましょう。お聴きいただき、ありがとうございました。それでは、いってらっしゃい。