どうもー、おはようございます。マイクです。
朝7時ちょうど、12月4日、木曜日の「zenncast」始まりました。
この番組では、今日いままさにZennでホットなトレンド記事を、ラジオ感覚でゆるっと、でも中身はみっちりめにお届けしていきます。
今日はお便りコーナーはお休みで、そのぶん技術ネタたっぷりでお送りします。
さてさて、今日ご紹介する記事は全部で5本。
AI時代の仕様駆動開発ツールから、TypeScriptの型ガード、LLMコスト削減の小技、Claude Codeの爆速習得術、そしてHaskell×Rustで1000倍高速化した話まで、かなり濃いラインナップになってます。
じゃあさっそく、1本目からいきましょう。
……。。
1本目は、「目にやさしい仕様駆動開発『spec-workflow-mcp』がもたらすブルーベリー効果」という記事です。
タイトルがすでにだいぶ攻めてますが、内容はかなり真面目で、「AIコーディング時代にどうやって仕様をちゃんと残すか」という話ですね。
いまって、AIにコードを書いてもらうのが当たり前になりつつある一方で、「そもそも何を作るんだっけ？」っていう意図がどこかで迷子になりがちなんですよね。進捗もテキストログに埋もれるし、レビューするときも大量のMarkdownをスクロールして探し回るのがほんとつらい。
そこで出てくるのが仕様駆動開発、いわゆるSDDなんですが、この「spec-workflow-mcp」は、そこにAIとMCPをうまく組み合わせたワークフローを提案しています。
面白いのが、Steering／Requirements／Design／Tasks／Implementationっていう5つのフェーズをちゃんと分けて、AIと一緒に進めつつ、その成果物とか承認フロー、タスクの進捗、実装ログまでぜんぶWebダッシュボードで“見える化”しちゃうところ。
EARS形式で要件を書いたり、それを設計・タスク分解につなげたりしながら、「意図を永続化」して、「いまどこまで進んだか」がバーでパッと分かる。レビューも、ダッシュボード上でアノテーションつけてコメントできるので、「どの段落の話してるんだっけ？」問題がだいぶ減りそうです。
要は、仕様駆動開発を「テキストファイル地獄」じゃなくて、「目にやさしいインターフェース」で回せるようにしたい、そのための仕組みがspec-workflow-mcpですよ、というお話。
AIと一緒に開発してるけど、チームでのレビューがつらい、意図が流れていく…と悩んでる人にはかなり刺さりそうな記事でした。
……。。
続いて2本目。「【TS】ユーザー定義型ガードを自分で書くな。ライブラリを使え。」
タイトルからして、だいぶ強い口調ですけど、TypeScript書いてる人にはグサッとくる内容かもしれません。
テーマはユーザー定義型ガード。`value is Foo` ってやつですね。
これ、自分で頑張って書くと、「実行時のチェック」と「コンパイル時にコンパイラが信じてくれている保証」がズレやすくて危険だよ、っていう話が展開されてます。
とくにネストの深いオブジェクトとか、配列、オプショナルプロパティなんかを含んだ型になると、ランタイムのチェックを書き忘れたりザルにしちゃったりしがち。型定義をあとから変えたのに、ガード側を直し忘れて、静的には通るのに実行時に壊れる、みたいな「一番いやなやつ」になりやすいんですよね。
そこでこの記事が推しているのが、ZodとかValibotみたいなスキーマライブラリを使うやり方です。
スキーマに「型」と「実行時のバリデーション」を一本化して、そこをSingle Source of Truthにしよう、と。
それによって、型を書き換えたのにチェックを直し忘れる、みたいな事故を減らせるし、そもそも型ガード自体をそんなに自前で書かなくてよくなる。
もちろん、単純なチェックならRemedaの`isString`とか`isNonNullish`みたいな、よく出来ている既製の型ガードだけで十分だよね、とも言っていて、「アプリ開発者がわざわざ複雑な型述語を自作するのは、極力やめたほうがいい」というのがこの記事の結論です。
「型安全にこだわるなら、自作ガードじゃなくてスキーマを信じよう」という、ちょっと考え方をひっくり返してくれる一本でした。
……。。
3本目。「Prompt Cachingを完全に理解してLLMコストを爆裂に下げる」。
これはLLMプロダクト作ってる人、あるいは社内でガッツリ使ってる人にはめちゃくちゃ実用的な内容です。
題材になってるのは、Ubieの医療AIエージェントみたいなtoC向けサービス。
大量のユーザーがアクセスしてくると、とにかくコスト最適化が大事になるんですが、そのキーテクノロジーとして「Prompt Caching」が紹介されています。
ポイントは、「プロンプトの先頭一致部分だけをキャッシュして、入力トークンの課金を減らす」という仕組みだということ。
普通のキャッシュと違って、出力内容はキャッシュされないんですね。あくまで「入力の共通部分」を再利用して、入力トークンのコストを最大90％ぐらいまで削れちゃうと。レイテンシも一緒に下がるので、一石二鳥です。
じゃあ、どう設計すればキャッシュが効くのか。
記事では、「変化しにくいプロンプトを先頭に置いて、履歴を壊さないコンテキスト設計」が大事だと解説しています。
たとえば、固定のシステムプロンプトは一番上にドン、と置いておく。会話履歴はそのまま積み上げる。
逆に、システムプロンプトの中に「現在時刻」とか動的な値を埋め込んじゃうと、それだけで先頭一致が崩れて、キャッシュが全然効かなくなるのでNG。そういう動的情報はツール呼び出しで取ってきて、別の場所で扱おうね、と。
実装面もおもしろくて、OpenAIとGeminiは暗黙的な自動キャッシュがあるので、条件を満たすと勝手に入力トークンが割引される。
一方、Claudeは自動キャッシュがない代わりに、`cache_control` で「ここはキャッシュして」と明示指定できます。ただし、書き込みが1.25倍、読み出しが0.1倍という料金体系なので、なんでもかんでもキャッシュに突っ込むと逆に高くなる可能性もあるという、なかなかクセのある仕様になってます。
最後の方では、既存のログ――セッションIDとか入出力トークン数、時刻――を使って、SQLでTTL込みの“仮想キャッシュ”をシミュレーションして、導入効果を試算する方法も紹介されていて、「まずはシステムプロンプトからキャッシュしよう」という、かなり実務寄りのアドバイスで締めくくられていました。
コストに悩んでるLLM勢は要チェックの内容ですね。
……。。
4本目は、「初心者が爆速で Claude Code を習得する 10 のステップ」。
Claude Code on Amazon Bedrock を、最短距離で“戦力化”するための実践ガイドです。
構成がすごく親切で、「まず環境整えよう」「次にコンテキスト共有しよう」「それからワークフローを決めよう」みたいに、10ステップに分けて具体的に教えてくれます。
最初の方では、`/terminal-setup` でターミナルを整えたり、通知オンにしたり、音声入力を有効化したりと、「まずは快適な開発環境を作ろう」という話。
そこから、プロジェクトや自分の前提知識をまとめた CLAUDE.md を `/init` で自動生成して、継続的に更新していくことで、「毎回同じ説明をしなくていい状態」をつくるテクニックが出てきます。
操作面のTipsも細かくて、起動オプションの使い分けとか、Escでの中断・巻き戻し、`!` コマンドでのシェル実行、`@` でのファイル指定、`/clear`でのセッション整理、といった「知ってると効率が段違いに上がる」ショートカットがずらっと並んでいます。
さらに、settings.json でallow/denyを設定して、どこまで自動実行させるかをちゃんとコントロールしよう、というセキュリティと安心感の話も。
ワークフローとしては、「Plan → Confirm → Code → Commit」というサイクルや、TDD的な進め方、スクショを使ったUI改善などが推奨されていて、「いきなり全部書かせるんじゃなくて、一緒に段取りを決めてから進もう」というスタンスが一貫しています。
設計・調査フェーズを強化するために、プランモードや拡張思考っぽいキーワードをプロンプトに混ぜるテクニックも紹介されていて、「Claude Codeに、どういう姿勢で相談すると一番力を発揮してくれるか」がかなりよく分かる記事です。
さらに、`.claude/commands/` によるカスタムスラッシュコマンドで定型作業を自動化したり、MCPサーバーを追加してTavilyやContext7、Playwright、AWS各種のツールを増やしたり、GitHub CLI連携や画像入力も絡めたりと、「ここまでやると、もはや“相棒IDE”だな」という世界観まで見せてくれます。
最後に、「困ったときはClaude Code自身にドキュメントやベストプラクティスを聞けばいい」という、メタな締め方になっていて、初心者でも「とりあえずこの10ステップをなぞれば、ちゃんと使いこなせるようになる」構成でした。
……。。
ラスト5本目。「HaskellerとRustaceanが知恵をあわせてプロダクトを3日で1000倍高速化した話」。
タイトルからして熱量高めですが、中身もかなりエンジニア魂くすぐる内容です。
題材は、数理最適化DSL「JijModeling 2」で起きた、とある大規模問題のコンパイル時間悪化。
以前のバージョンだと数百ミリ秒で済んでいたのが、新版では267秒、つまり4分半以上かかるようになってしまった、と。
そこから、Haskell好きな人（Haskeller）とRust好きな人（Rustacean）がタッグを組んで、flamegraphを片手にボトルネックを潰していきます。
まずは、巨大配列をエラーハンドリング用に過剰にCloneしていたところを見つけて、そこを参照渡しや即値受けに変更。これだけで267秒→167秒と、約1分半削減。
次に、Haskellの流儀を取り入れて、遅延配列や遅延JaggedArray――配列を「shapeと、添え字から要素を返す関数」で表現する――を導入し、配列変形の中間アロケーションを抑えた結果、167秒→64秒まで短縮。
さらに、クロージャ自体をArcで包んでいた設計を見直して、「配列だけArcにして、クロージャはBox＋Cloneで軽くする」という方針転換をすると、64秒→9秒まで一気に縮みます。
そこからも、不要なshape計算を削って9秒→4秒、そして極めつけは、JaggedArrayのshape関数生成で全通りを再帰で辿っていた処理を、ループ実装に作り直すことで、4秒→345ミリ秒へ。なんと最初の267秒から比べて、約1000倍の高速化を達成した、という痛快なストーリーです。
教訓として挙げられているのは、「不要なCloneとArcは避けよう」「関数型っぽい遅延配列のアイデアでアロケーションを抑えるのは有効」「ただしRustみたいな正格言語では、再帰よりループのほうが速くて扱いやすいことが多い」といったポイント。
HaskellとRust、それぞれの文化のいいとこ取りをしながら、実際のプロダクト性能を劇的に上げていく過程が、かなり臨場感たっぷりに書かれていました。パフォーマンスチューニングが好きな方にはたまらない一本ですね。
……。。
というわけで、今日のzenncastは、
AI時代の仕様駆動開発を“目にやさしく”してくれる「spec-workflow-mcp」、
TypeScriptの型ガードは自作よりスキーマライブラリを、という設計の話、
Prompt CachingでLLMコストをガツッと下げるテクニック、
Claude Codeを10ステップで爆速習得するための実践ガイド、
そしてHaskellerとRustaceanが協力して、プロダクトを3日で1000倍速くしたエピソード、
この5本をご紹介しました。
気になった記事があれば、このあとショーノートにタイトルをまとめておきますので、ぜひ元記事でじっくり読んでみてください。
番組の感想や、「こんなテーマ取り上げてほしい！」というリクエストも、どしどしお待ちしています。あなたの一通が、次回のzenncastのネタになるかもしれません。
それでは、そろそろお別れの時間です。
木曜日の朝のおともに、少しでも技術のインスピレーションをお届けできていたらうれしいです。
次回のzenncastでまたお会いしましょう。お相手はマイクでした。
いってらっしゃい。