どうもー、おはようございます。マイクです。
時刻は朝7時、2025年12月30日、火曜日。今日も「zenncast」始まりました。
この番組では、Zennで今ホットな記事や、開発者のみなさんの気になる話題を、ゆるっとそしてちょっとディープに紹介していきます。
今日もZennで話題になっているトレンド記事をまとめてチェックしていきますよー。
今日はお便りの紹介はお休みなので、そのぶん記事をみっちり掘っていきたいと思います。
さて、今日紹介する記事は全部で5本です。
Rustのエラーハンドリング、AI駆動開発、FirestoreからCloud SQLへの大規模移行、WebAssembly Component Model、そして最後はDockerの裏側を知るためのコンテナランタイム自作と、かなり技術濃度高めのラインナップになってます。
まず1本目。タイトルは「中途半端にResultを使うぐらいならunwrapの方がマシ」。
Rustやってる方なら、一度は「unwrapってどこまで許されるんだ問題」で悩んだことあると思うんですが、この記事はそこにかなり踏み込んでます。
初心者のうちは、panicしたときのスタックトレースが出るおかげで、素直に`.unwrap()`してても「どこで落ちたか」が分かる。ところが中級者ぐらいになって、なんとなく「ちゃんとResult返したほうがよさそう」と思って`anyhow::Result`に置き換えると、今度はエラーの発生場所や、どう伝搬してきたかが分かりづらくなって、むしろデバッグしづらい、という指摘です。
筆者は、Resultを使う利点を「回復性・網羅性・可視性」、課題を「追跡性」と整理していて、「なんのためにResultにしてるのか」を意識しないと危ないよ、と。
小さなCLIだったら`eyre`や`color-eyre`で位置情報とバックトレースをちゃんと出す。大きなアプリなら`thiserror`と`tracing`、あるいは`snafu`などで型付きエラーとトレースを両立するといった、現実的な構成案も紹介されています。
そして、テストコードやブートストラップでは、あえて`unwrap`や`expect`で即座にpanicさせたほうが「失敗に早く気づけていい場面」もある、と。
「とりあえずResultにしとくか」じゃなくて、「追跡性をどう担保するか」まで含めてエラー設計しよう、というメッセージが刺さる記事でした。
。。。。
続いて2本目。タイトルは「AI駆動開発を全力で試して得られた、10の実践テクニックと知見について」。
これは個人開発のタスク管理アプリ「FocusOne」を、設計以外ほとんどAIに任せて作ってみた、というかなり攻めた実践レポートです。
Figma MakeやClaude Codeを使って、デザインと実装を同時進行で進める。要件定義や仕様策定も、AIと壁打ちしながら進める「SDD」スタイルで、いきなりコードを書かせる精度を上げていく。
レビューやE2Eテスト、リファクタリング候補の洗い出しまでAIにお願いして、人間は認証や0→1の設計といった「AIが苦手な部分」に集中する方針です。
ポイントは、AIをただの賢いオートコンプリートとして使うんじゃなくて、Codex、Cursorなど複数ツールを「役割分担」させているところ。それから、CLAUDE.mdやSkillsの整備、余計なコンテキストの削除など、「AIが働きやすい環境づくり」を継続的にやっている。
一方で、AI任せだと技術的負債が溜まりやすいので、「負債を理解したうえで、どこまで今回は割り切るか」を決め、E2Eテストを土台に定期的なリファクタリングやリアーキテクトを行う必要があると指摘しています。
AIは「指示されたこと」はうまくやるけれど、共通化や抽象化、設計判断はまだ弱い。だからこそ、実装意図のコメントや、しっかりしたドメインモデル設計など、人間側のアーキテクト力が重要だという結論。
AIに丸投げではなく、「判断コストをどうAIで減らすか」という視点でのノウハウが詰まった記事でした。
。。。。
3本目。タイトルは「7年運用した Firestore から 1億件超えのデータを Cloud SQL に移行し、速度と費用と開発体験を改善した話」。
サービス名は「暗記メーカー」。もともとは端末内保存から始まり、その後Firestoreに移って、同期や共有の課題を解決してきたそうなんですが、7年まわして1億件を超えるデータになってくると、いろんな問題が表面化してきたと。
代表的なのが、米国リージョン由来のレイテンシ、それからRead/Writeの従量課金による高コスト。そして、RDB的なリレーションや複雑なクエリをFirestoreでやる難しさ、スキーマレスゆえの「歴史的負債」です。
そこで、日本リージョンが使えること、費用予測がしやすいこと、マネージドRDBであることを条件に、Cloud SQL for PostgreSQLを選択。しかもサービスを止めずに段階的に移行しています。
手順としては、まずクライアントのFirestore直接アクセスをやめて、全部APIサーバ経由にする。次にサーバ側でFirestoreとCloud SQLにダブルライト。カーソルを使いながら、`skipDuplicates`や仮IDで冪等に1億件超を移行していき、読み取り先をCloud SQLに切り替えた後、Firestoreへの書き込みを止める、という流れをテーブルごとに実施。
結果として、1秒かかっていた読み取りが100ms未満まで高速化、ストレージ費用は80%削減、課金もCPU・メモリの定額中心で予測がしやすくなったとのことです。
さらに、RDBにしたことでリレーション前提の機能設計がしやすくなり、OpenAPIやPrisma、Terraformでコードとして管理できる範囲が増えたことで、AI活用も含めた開発体験がかなり改善したとまとめられていました。
「クライアントは薄く、ビジネスロジックはサーバへ」という、王道のWebサービス構成に近づける移行ストーリーとしても、読みごたえのある記事になっています。
。。。。
4本目。タイトルは「wa.dev に WebAssembly Component Model のライブラリを公開してみた」。
MoonBitという言語で実装されたシンタックスハイライト用レンダラー「mizchi:tmgrammar」を、WebAssembly Component Model対応のレジストリであるwa.devに公開した、という事例です。
tmgrammar自体は、トークンの列からHTMLやANSIエスケープ付き文字列を生成するライブラリなんですが、ポイントはこれをWITでインターフェース定義して、言語非依存・型安全なコンポーネントとして扱っているところ。
CLIツールのwkgやwasmtime経由で使う方法、jcoを通したJavaScriptからの利用方法、さらにWASMコンポーネント化してwa.devにpublishするまでのフローが具体的に書かれています。
MoonBit特有の事情として、UTF-16とUTF-8の変換を自前で実装する必要があったり、wit-bindgenを再生成したときに既存実装が消えるという罠にハマった話など、実際にやってみた人ならではの知見も共有されています。
まとめとしては、「エコシステムがまだ成熟していない言語からでも、Component Modelを使えばライブラリを他の世界へ届けられる」という希望のある内容。
WASM Component Modelって名前だけ聞いたことある、くらいの人にも、「こういう風に使えるんだ」とイメージが湧く記事だと思います。
。。。。
そして5本目。タイトルは「Dockerの裏側を知るために、Goで最小限のコンテナランタイムを作ってみた」。
コンテナランタイムの中身を理解するために、Goで「nendo」という最小限のランタイムを自作した、という学習寄りのプロジェクトです。
構成はgRPCを使ったサーバー・クライアント型で、クリーンアーキテクチャを意識してDomain、Usecase、Interface Adaptersに分割。libcontainerやgo-containerregistryを活用しながら、コンテナの作成・起動・停止・削除・一覧、そしてexec相当の機能まで一通り実装しています。
イメージのPullからrootfsへの展開、JSONとファイルシステムを使ったメタデータの永続化、Namespaceやcgroupを設定した隔離環境でのプロセス実行、SIGTERMでの穏当な停止、動いているコンテナの削除ガード、OS上のプロセス状態とメタ情報を突き合わせての一覧表示、PTYとsetnsを用いたコンテナ内コマンド実行など、Dockerでよく見る一連の操作が「中身はこうなってるのか」という形で見えるようになっています。
実装にあたっては、libcontainerのバージョン違いによる情報の古さで生成AIと噛み合わなかったりといった苦労話もありつつ、「学習用として自由にいじれるコードベース」を目指した、と締めくくられていました。
Dockerを普段なんとなく使っている人にとって、「自分で最小実装を試す」という学び方の具体例としても面白い内容です。
。。。。
そろそろお別れの時間です。
今日は、Rustのエラー処理とunwrapの付き合い方から、AI駆動開発の実践テクニック、大規模なFirestoreからCloud SQLへの移行、WebAssembly Component Modelでのライブラリ公開、そしてGoで作る最小限コンテナランタイム「nendo」まで、5本を駆け足で紹介しました。
気になった記事があった方は、詳しい内容や元の記事へのリンクはショーノートにまとめてありますので、ぜひチェックしてみてください。
「zenncast」では番組の感想や、取り上げてほしいテーマ、質問なども随時募集しています。
「こういう記事も紹介してほしい」とか、「最近こんなことで悩んでます」など、ゆるっと書いて送ってもらえたら嬉しいです。
それでは、今日も良い一日を。
お相手はマイクでした。また次回のzenncastでお会いしましょう。