どうも、おはようございます。朝7時をちょっと過ぎたところでしょうか。6月8日、月曜日の朝、いかがお過ごしでしょうか。マイクです。今日も「zenncast」、元気にお届けしていきます。
この番組では、エンジニアのみなさんに向けて、Zennで話題になっているトレンド記事をゆるっと、でも中身はしっかりめに紹介していきます。

さて今日は、お便りコーナーはお休みで、そのぶんガッツリ記事を紹介していきたいと思います。

今日は全部で5本の記事をご紹介します。AI時代の仕様書の書き方から、LLMツールの設計思想の違い、Rustへのサーバーサイド移行、E2Eテスト自動化、そしてRustのエラー設計の話まで、かなり濃いラインナップです。コーヒー片手に、ゆるく耳を傾けてもらえたら嬉しいです。

まず1本目。
タイトルは「Claude Codeで仕様書をMarkdown/HTMLで記述を比較」。
これは、AI駆動・仕様駆動開発が当たり前になっていく中で、「仕様書ってどうやって書くのがいいの？」を、ガチで計測しながら比べたという記事です。題材はアカウント管理システムの実装コードだけをClaude Codeに渡して、「Markdownで仕様書を書かせる場合」と「HTMLで、図やインタラクティブ要素まで盛り盛りで出させる場合」を比較しています。おもしろいのが、HTML化して図やインタラクティブ要素を増やしていくほど、実行時間とトークンが段階的に約2倍ずつ増えていって、最大で33分・11万トークンくらいまで膨らんだという点。数字で見ると「リッチな仕様書って、ちゃんとコスト払ってるんだなぁ」と実感しますよね。一方で、HTML仕様書は本文デザインや表、構成図・ER図がすごく見やすくて、インタラクティブな要素もあるから、読む側・理解する側にはめちゃくちゃ優しい。結論としては、「HTMLかつインタラクティブな仕様書が一番よくわかる。でも、更新コストが高くて現実運用はキツい」というジレンマが浮き彫りになっています。AIで仕様書を量産したい人ほど、一度読んでおきたい内容ですね。
。。。。

続いて2本目。
タイトルは「Claude Code と Codex を使い比べて見えた設計思想の違い」。
同じ「LLM＋ツール実行」でコードを扱うプロダクトでも、振る舞いの思想がだいぶ違うよ、という話です。筆者は、Opus 4.7で少しモヤっとする体験があって、それをきっかけに、普段メインで使っているClaude CodeとOpenAI Codexをじっくり比較しています。Claude Codeは「Explore → Plan → Code」というワークフローを強く意識していて、最初に立てた作業仮説、いわゆるplanとの整合性を守ろうとする傾向が強い。そのため、最初に誤った前提を飲み込ませると、その前提を丁寧に説明し続けちゃう、という危うさも見えてきます。一方でCodexは、goalとかcompletion criteriaを重視しつつ、コード読み取りやテスト実行を通して前提を疑い、コードや結果を根拠に推論を更新していくスタイルが強い。筆者はこの違いを踏まえて、「調査・技術検討・情報整理・PR本文生成はClaude Code」「既存コードの理解・修正・リファクタリング・検証はCodex」という役割分担をしています。問題空間を整理するのがClaude、解空間をちゃんと埋めていくのがCodex、みたいな感じですね。「どのLLMが最強？」じゃなくて、「どう組み合わせてチームにするか」という視点がすごく参考になります。
。。。。

3本目。
タイトルは「AI時代のサーバーサイド開発を考えて、Next.jsフルスタックからRustへ移行した話」。
これは、美容サロン向けのAIエージェントなどを作っている会社の、かなりリアルな技術選定ストーリーです。最初はNext.jsフルスタックで一気に開発していたんですが、ユーザーもユースケースも増えてくると、サーバーサイドの責務が肥大化してきてしまった。そこで、性能というより「保守性」と「安全に変更するための構造」を重視して、Rust製のAPIサーバーに段階的に移行していった、という話です。Rust側ではAxum＋SQLxでapi/domain/db層をきっちり分離して、Prisma schemaはあくまでスキーマ管理にだけ使い続ける構成に。さらにOpenAPIを「人間とLLMの共通仕様」として扱っていて、クライアント実装やテスト追加をAIコーディングエージェントに小さい粒度で頼みやすい形にしています。その結果、リファクタリングやテスト設計がやりやすくなり、「サーバーサイドを変えても怖くない」という状態に近づいているそうです。一方でRust採用には採用面のハードルもあるけれど、「Rust経験そのものより、設計や型・責務分離を大事にできる姿勢のほうが重要」と語っていて、AIとRustを組み合わせて高速に、しかも安全側に振った開発をしたいチームには刺さる内容になっています。
。。。。

4本目。
タイトルは「E2Eテストを民主化したら、朝には失敗の分析も再実行も修正PRも終わっていた」。
オンライン・対面診療システムのE2Eテストを題材に、「民主化」と「カオス」と「AIで再整理」を味わった話です。最初はPlaywrightでE2Eテストを自動化しつつ、QAチームが一括で回していたんですが、失敗時の原因切り分けが遅くなったり、テスト内容がブラックボックス化したりする課題が出ていました。そこで、各開発チームにE2Eテスト運用を「民主化」したところ、今度は「誰の責任？」「どのチームが見るの？」みたいな混乱が発生してカオスに。そこでまずやったのが、Slack通知にシナリオごとの担当チームを明示して見える化すること。そして次のステップでClaudeを導入して、失敗結果やGitHub Actionsのログをチームごとに集約・分析させる仕組みを作っています。これによって、「環境が悪いのか」「仕様変更なのか」「単純なバグなのか」をAIが判定し、必要に応じて自動再実行をかけたり、修正PRを自動で作って担当チームに通知したりできるようになった。結果として、朝になったら分析も再実行もPRも終わっていて、人間はレビューなど本質的な判断に集中できるようになった、というわけです。もちろん、判定精度やチーム分類、テストの安定性といった課題は残っていますが、「AIに任せられるところは最大限任せて、人間はできるだけ楽をする」というスタンスが、これからのテスト運用の一つのモデルになりそうです。
。。。。

そしてラスト、5本目。
タイトルは「Rustでエラー原因をsourceとDisplayの両方に書いてはいけない理由」。
Rustを書いている人、特に`thiserror`や`anyhow`を使っている人にはぜひ読んでほしい記事です。Rustの`Error`型はエラーチェーンの概念を持っていて、「自分のレイヤーの文脈を`Display`で説明する責務」と、「原因を`source()`でつないでいく責務」がきれいに分かれています。ところが、`thiserror`で`#[error("...: {0}")]`みたいに内側のエラーをメッセージに埋め込みつつ、同じフィールドを`#[source]`でもつないでしまうと、`anyhow`などのreporterがチェーンをたどって表示する時に、同じ原因メッセージが二重三重に出てしまう、という問題が起きるんですね。基本の考え方としては、「文脈を持つエラーは、自分のレイヤーの説明だけを`Display`に書く。原因は`source()`に任せる」。文脈のない単なるラッパーは`#[error(transparent)]`で内側に素直に委譲する。`#[from]`はsourceだけを持つvariant向けで、文脈フィールドがある場合は`#[source]`を使う、といった役割分担が整理されています。最終的に「どう見せるか」、たとえばチェーンを1行にflattenするかどうかは、reporter側や自前のフォーマッタの責務であって、エラー型の`Display`側で原因まで詰め込まないのが大事だよ、というメッセージです。小規模アプリや文字列しか取れない外部エラーを扱う場合などの例外も触れつつ、「ライブラリエラーではやめておこうね」と締めていて、現場で迷いがちなポイントをかなりスッキリ言語化してくれています。

というわけで、今日は
1本目：AIで生成する仕様書をMarkdownとHTMLで比較した話、
2本目：Claude CodeとCodexの設計思想の違いと使い分け、
3本目：Next.jsフルスタックからRust APIサーバーへ移行した理由、
4本目：E2Eテストを民主化して、AIで分析からPR作成まで自動化した事例、
5本目：Rustのエラー設計で`Display`と`source`をどう分けるべきか、
この5本を駆け足でご紹介しました。

気になった記事があれば、ぜひショーノートから元の記事をじっくり読んでみてください。番組で触れられなかった細かい工夫やコードの断片、図なんかも含めて、かなり学びが深まると思います。

「zenncast」では、番組の感想や、取り上げてほしいテーマ・技術スタックなども募集しています。「このツールとこのツールの使い分けを知りたい」とか、「うちのチームのAI活用事例も紹介してほしい」なんてお便りも大歓迎です。

それでは、そろそろお時間です。月曜日の朝、無理しすぎず、でもちょっとワクワクする一日になりますように。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。いってらっしゃい。