どうも、マイクです。おはようございます。
2026年5月30日、土曜日の朝7時をまわりました。ここからの時間は「zenncast」、Zennで話題のトレンド記事をゆるっと、でもしっかりご紹介していきます。

今日はリスナーのみなさんからのお便り紹介はお休みで、そのぶんガッツリ記事を取り上げていきたいと思います。技術ネタ多めで頭フル回転かもしれませんが、コーヒー片手にのんびり聞いてくださいね。

さて、今日ご紹介する記事は全部で5本です。
データベース設計、AIエージェントの運用、仕様書の読みやすさアップ、そしてTransformer入門に、自作の軽量エージェントまで、かなり盛りだくさんのラインナップになっています。

まず1本目。
タイトルは「論理削除をやめて状態をテーブルで分けるDB設計」。
業務システムでおなじみの「論理削除」、みなさんも `deleted_at` 付きのテーブル、一度は触ってるんじゃないでしょうか。この記事では、その論理削除が引き起こす「毎回クエリに条件書き忘れがち問題」とか、「ユニーク制約が効きにくい問題」、「削除データが溜まり続けてテーブルが太る問題」みたいな、運用あるあるを丁寧に整理しています。そこで提案されているのが、状態ごとにテーブルを分ける「状態別テーブル」と、履歴を扱う「イベントテーブル」。例えばユーザーを、在籍中と退会済みでテーブル分割して、共通のIDを親テーブルに持たせる構成ですね。関連テーブルは親だけ見ればよくて、JOIN した時点で状態フィルタが効いているから「WHERE deleted_at IS NULL」の書き忘れ自体を構造で防ぐ、と。履歴はappend-onlyなイベントで扱って、「今の状態」と「どう変化してきたか」をきっぱり分けようという話です。結論として、「本当に削除なのか？ 別の状態への遷移じゃないのか？」をまず設計レベルで問い直そう、というメッセージが込められています。実務で論理削除にモヤモヤしてる人には刺さる内容だと思います。

。。。。

続いて2本目。
タイトルは「Codexを使い始めて長時間稼働させるまで」。
ここで言うCodexは、Claude Code／Codexの、いわゆるAIエージェント的な開発支援環境の話ですね。筆者の方は「細かい承認を繰り返したくないけど、勝手に危ないコマンドは打ってほしくない」というジレンマを解決するために、環境づくりをかなり作り込んでいます。キーワードになっているのが「役割の分離」と「現在地の見える化」。調査・実装・検証のフェーズを明示して、それぞれにチェックリストを用意。作業の進行状況は「run note」っていう専用ファイルに書き残して、途中で止めても再開しやすくする。さらに、リポジトリごとのルールや検証コマンドをAGENTS.mdにまとめて、どのリポジトリに入ってもCodexが迷わないようにする仕組みも用意しています。極め付きは、sandboxの外で叩いていいコマンドを「許可・要確認・禁止」でポリシーファイルに分けているところ。これによって、1時間くらいのタスクをほぼ無承認で任せつつも、安全面はちゃんと担保できたそうです。今後の課題としては、権限の粒度をもっと細かくしたり、設定を他マシンと共有する仕組みが欲しい、といった点も挙げられていて、「AIに継続タスクを任せるための現場の工夫」がリアルに伝わる記事になっています。

。。。。

3本目の記事。
タイトルは「スペック文書を『読みたくなるHTML』に変換するClaude Codeスキルを作った話（スキル本文付き）」。
仕様書って、長くて重くて読まれない、そんなイメージありますよね。この筆者はそこに真正面から挑んで、「spec-to-readable-html」というスキルを作っています。ポイントは、単純なMarkdownからHTMLへの変換じゃない、ということ。まず仕様書の内容を分析して、構造を整理し直しつつ、サマリーカードやサイドバーの目次、Mermaidでの図、用語集やテーブル、重要度バッジ、コールアウト、ツリービューなんかを自動生成して、全体の見通しを一気によくするアプローチです。また、「ここは推測が入ってますよ」というラベル付けをしたり、元の仕様のキーワードを残したりして、あとから「この一文の出典はどこ？」が辿れるよう、トレーサビリティにも気を使っています。SKILL.mdには「いつ使うべきか」「判断基準」「テンプレHTMLとコンポーネントのガイド」まで書かれていて、チームで運用する前提でちゃんと設計されているのも印象的です。クリックすると拡大するダイアグラムなど、UI寄りの工夫も細かくて、「同じ内容でも表現形式を変えるだけでこんなに理解しやすくなるのか」という気づきを与えてくれる内容になっています。npxコマンド一発で使い始められるよう公開されているので、「仕様書をなんとかしたい」人は要チェックなスキルですね。

。。。。

4本目。
タイトルは「Karpathy氏の200行GPT『microGPT』を1行1行読み解く」。
AI界の有名人、Karpathyさんが公開した、約200行で書かれたミニマルなGPT実装「microGPT」を題材にした解説記事です。外部ライブラリに依存しない、素の実装で、名前データ約3万件ちょっとを文字単位でトークナイズして学習させるという構成になっています。この記事の面白いところは、「なんとなくTransformerを知ってる」レベルの人を、もう一歩深い理解に連れていってくれるところ。まずは自作のAutogradエンジン、Valueクラスで計算グラフとbackwardを実装するところから始まって、RMSNormやReLU、バイアス無しといった簡略化をしつつも、マルチヘッドアテンションとMLP、残差接続というTransformerの要素はきちんと押さえていきます。パラメータ数は4,192とかなり小さいんですが、それでも学習を進めるとLossがきちんと下がっていって、生成される名前のパターンが徐々に自然になっていく様子が観察できる。さらに重みの分布やAttentionのパターンを可視化するコードも紹介されていて、「行数は少ないけど、学べるエッセンスはギュッと詰まっている」内容になっています。ライブラリに頼らず、動く最小限のGPTを追いかけてみたい方には、最高のガイドになる記事ですね。

。。。。

そして5本目。
タイトルは「LiteLLMをやめて自作Goバイナリに置き換えたら一気に軽くなりました - 『実践 AI エージェント開発』を実装してみた」。
こちらはPython製のLiteLLMではなく、Go 1.25で書かれたシングルバイナリのAIエージェント「go-llm-agent」を自作した、というチャレンジングな記事です。モチベーションは3つ。「バイナリ1本でサクッと起動したい」「LLMの抽象化とエージェントループを一体で作り込みたい」「機能を絞って保守を軽くしたい」。その結果、OpenAI、Anthropic、Gemini、Ollamaといった各種モデルを共通インターフェイスで扱いつつ、CLIやワンショット実行、OpenAI互換のHTTPサーバまでを1バイナリで切り替えられるという構成になっています。ストリーミングとtool callingも統一的に扱えて、ファイルアクセスやシェル、HTTPといったツールはサンドボックスと多層ガードで安全性を確保。履歴や課金情報はJSONLで残し、ログやシークレットマスクにも気を配るなど、とにかく「軽いけど本番を意識した設計」が貫かれています。さらに、O’Reillyの「Building Applications with AI Agents」に沿って、観測性、コスト上限管理、リトライとフォールバック、認証とレート制限、ツール契約とスキーマ検証、プロンプトフィルタ、評価フレームワーク、人間承認、戦略切り替え、並列ツール実行、簡易RAG、MCPクライアント、PIIマスキング、mTLSやOAuth2、カナリア・シャドウリリースなど、16段階の本番運用機能を実装しているのも圧巻です。筆者は「LiteLLMは多機能ゲートウェイとして、go-llm-agentは開発機やCI向けの軽量エージェントとして」という使い分けを提案していて、「全部入り」ではなく、あくまで小さくシンプルであることに価値を置いた設計思想が伝わってきます。

。。。。

というわけで、今日は
・論理削除の代わりに状態をテーブルで分けるDB設計の話
・Codexを長時間安全に動かすための運用工夫
・仕様書を「読みたくなるHTML」に変えるスキル
・200行GPT「microGPT」でTransformerの仕組みを学ぶ記事
・LiteLLMを自作Goバイナリで置き換えた、軽量AIエージェント構築の話
この5本をご紹介しました。

気になる記事があった方は、ぜひショーノートから元の記事をチェックしてみてください。ここでは触れきれなかった図や具体的な設定、細かいノウハウがたくさん詰まっています。

「zenncast」では、番組の感想や、「こんなテーマを取り上げてほしい」「このZenn記事を紹介してほしい」といったリクエストもいつでも募集中です。あなたの開発現場での悩みや、最近ハマっている技術ネタなんかも、ぜひ教えてください。

それでは、そろそろお別れの時間です。
お相手はマイクでした。次回のzenncastでまたお会いしましょう。今日も良い一日をお過ごしください。