どうもー、おはようございます。マイクです。「zenncast」のお時間です。
今日は2026年3月14日、土曜日の朝7時でーす。
この時間は、技術情報共有プラットフォームZennから、今日のトレンド記事をピックアップしてご紹介していきます。朝ごはんの準備しながら、通勤・通学の支度をしながら、ゆるっと聞いていってください。
今日はお便りコーナーはお休みで、そのぶんガッツリ記事を紹介していきますね。
さてさて、今日ご紹介する記事は全部で5本です。AI開発の最前線から、プロンプト設計、仕様の考え方、そしてCI/CDのリアルな現場まで、かなり濃いラインナップになってますよ。
まず1本目。
タイトルは「Anthropic公式が33ページのスキル設計書を出したので、将軍のスキルクリエイターと答え合わせしたら先を行ってた」。
これは、Claude Code向けにAnthropicが出した33ページの公式スキル設計ガイドを、筆者さんが自作ツール「将軍スキルクリエイター」と突き合わせて、答え合わせしてみたよ、という記事です。
おもしろいのが、「公式ガイドにボコボコにされる」感じじゃないんですよね。文字数制限とかセキュリティみたいな「知らなかった仕様」は素直に取り込んだ一方で、Bloom taxonomy（教育理論のアレですね）を使ったモデルルーティングとか、descriptionを7項目でスコアリングするとか、公式が触れてない高度な工夫は、むしろ自作ツール側が先行していたと。
特にスクリーンショット系のスキルは、公式ガイドが出る前から、ほぼ推奨パターン通りの設計になっていたらしくて、「実戦で磨いた設計が、後から出てくる理論を追い越すこともあるんだな」という話になっています。
結論としては、公式ガイドは「答え合わせ」に使って、不足はちゃんと取り込みつつ、自分の強みはそのまま伸ばしていこう、というスタンス。AIツール作りをしている人はもちろん、「公式ドキュメントとどう付き合うか」で悩んでいる人にも刺さる内容になっています。
。。。。
続いて2本目。
タイトルは「Claude Codeで仕様駆動開発、tsumikiが良かった」。
AI実装って、同じプロンプトを投げても日によって出力が変わったりして、「ガチャだな〜」って感じること、ありますよね。この筆者さんは、そのガチャ感を減らして再現性のある品質を出すために、「仕様駆動開発」、Spec-Driven Developmentを採用しています。
流れとしては、人間がClaudeと壁打ちしながら要件や設計をガッチリ詰めて、そのあとに出てくるタスク分解〜実装はAIに任せる、という分業スタイル。その中で、Claude Codeと相性がいいフレームワークとして「tsumiki」というツールを推しているんですね。
tsumikiのいいところは、要件定義の段階でめちゃくちゃ質問してくるところ。不確実なところは信号機みたいに色分けして見せてくれて、「ここあいまいだよ」「ここ決め切れてないよ」って可視化してくれる。生成されるドキュメントも読みやすくて、そのままTDDで自動実装までやってくれる、と。
あと、つまずく原因の多くは、仕様の前にプロジェクトルールがスカスカなことだ、って指摘も重要で、`CLAUDE.md` とか `.claude/rules/` をちゃんと整えるだけで、AI開発の品質が安定するよ、という話をしています。
まとめとしては、(1) Claude Code入れる、(2) プロジェクトルール・コーディング規約を整える、(3) 仕様駆動開発フレームワーク、特にtsumikiを導入する。この三点セットで「思考＝仕様は人間、実装はAI」という分業を回し始めると、要件からリリースまでのスピードがぐっと上がるよ、という提言になっています。
。。。。
そして3本目。
タイトルが挑発的です。「仕様駆動開発はやめた方がええ」。
さっきの2本目とは完全に逆張りのスタンスですね。同じZennの中で思想がぶつかっているのがおもしろいところです。
この筆者さんは、実装仕様を自然言語でドキュメントとして残す「仕様駆動開発」は、コストに見合わなかった、と振り返っています。仕様の「単一の真実の源泉」、SSoTはコードに置くべきで、コードとドキュメントを二重管理するのはかなりつらい。エージェントにドキュメントの更新を任せても確率的だし、トークンももったいない、という主張です。
「仕様がわからなくなったら、そのときClaudeに聞けばよくない？」という価値観で、恒久的な仕様ドキュメントの必要性はあまり感じていないと。一方で、ロングランのタスクでコンテキスト圧縮が起きるようなケースでは、プランファイルを一時的に外に出しておく意味はあるので `.claude/plans` をgitignoreして、実装が終わったら捨てる、という割り切り方をしています。
ビジネス要件も、基本はコード近くのコメントやdocstringに書けばよくて、独立した分厚いドキュメントにはあまりうまみを感じていない。その代わり、全体に共通する横断的なルール——PIIの扱いとか、レスポンス速度の制約とか——は `CLAUDE.md` にまとめる。
おもしろいのが、`CLAUDE.md` や `skills`、`rules` を「仕様ドキュメント」ではなくて、エージェントの挙動を制御する「手続きドキュメント」として大事にしているところ。これを「盆栽」と呼びながら、こまめに手入れしているそうです。
全体を通して、ドキュメントは長期仕様の源泉ではなく、必要な範囲だけを補助的に外部化するもの。中心はあくまでコードとエージェント活用、というスタイルを推している記事でした。2本目とセットで読むと、自分のチームにはどっちの思想が合うか、考えるきっかけになりそうです。
。。。。
4本目の記事。
タイトルは「Claude CodeやCodexのスキルの管理を楽にするツール『faceted-prompting』」。
「長くなりすぎたプロンプト問題」、身に覚えがある人、多いんじゃないでしょうか。役割、ルール、ナレッジ、指示、出力形式……全部ごちゃ混ぜにして1枚の長文プロンプトにしていると、再利用も保守もだんだん地獄になってきますよね。
この記事では、それを「Faceted Prompting」、つまり関心ごとごとに“面”に分けて整理しよう、という提案をしています。そのための実践ツールとして、npmモジュール「faceted-prompting」が紹介されています。
やっていることはシンプルで、persona（どんなキャラか）、policy（守るべきルール）、knowledge（知識）をMarkdownで部品として管理しておいて、YAMLでそれらを組み合わせて、最終的なsystemプロンプトやuserプロンプトを合成する、というスタイルです。
Claude CodeやCodexのスキルで使う `SKILL.md` も、この仕組みで生成してインストールできるので、「architectureみたいな共通ナレッジ」と「frontend専用」「backend専用」みたいな特化ナレッジを分けておける。どこか1カ所直せば、それに依存しているスキル全部に反映される、というのが気持ちいいポイントですね。
長文プロンプトを丸ごとコピペして編集する、っていう“職人芸”から、「部品を育てて設計する」というパーツ志向の運用に頭を切り替えよう、というメッセージになっています。スキルが増えてきてプロンプトがカオス化しているチームには、かなり刺さる整理術だと思います。
。。。。
そして最後、5本目。
タイトルは「インターン先でCI/CDパイプラインをゼロから構築し、リリース頻度を110倍にした話」。
これは読み物としてもめちゃくちゃおもしろいです。AIを使って開発スピードだけは速いんだけど、テストはほぼ手動、型エラーやUI崩れが本番に出てから発覚して、毎回ヒヤッとする……みたいな状況を、インターンの筆者さんがCI/CDで一気に改善していったお話です。
ローカルではHuskyとlint-stagedで、差分だけLintとPrettierをかけるようにして、CIではビルド、Lint、Vitestでユニットテスト、Playwright＋Firebase EmulatorでE2E、さらにStorybookとChromaticでビジュアルリグレッションまでかけるという、なかなか豪華な品質ゲートを整えています。
その上で、Cloud BuildからCloud Runへの自動デプロイとSlack通知までつなげて、結果としてリリース頻度は月0.25回から27.5回、ざっくり110倍。QA時間も1回30分から7分まで短縮、PRも小さくこまめに出されるようになったと。数字だけ見ると夢がありますよね。
ただ、ここで終わらないのがこの記事の良いところで、チームと「どのレベルの品質を目指すのか」「テストの責務はどこまでか」をちゃんとすり合わせないまま、一気に仕組みを入れた結果、しばらくは筆者さん一人で運用を背負う形になってしまった、と反省も書かれています。
CIが厳しすぎて開発体験が悪く感じられたり、チームの「速さと品質のバランス感覚」と噛み合わなかったり。技術的にできるからといって、いきなり全部盛りで導入するのではなくて、小さな成功体験を共有しながら、段階的に育てていくべきだった、という学びで締めくくられています。現場でCI/CDを導入しようとしている方には、かなりリアルなケーススタディになりそうです。
。。。。
ということで、今日は全部で5本ご紹介しました。
1本目は、Anthropic公式スキル設計ガイドとの「答え合わせ」から見えた、実戦で鍛えたスキル設計の強さ。
2本目は、Claude Codeとtsumikiを使った仕様駆動開発で、「思考は人間、実装はAI」という分業をうまく回していこう、という話。
3本目は逆に、「仕様駆動開発やりすぎるのはコスパ悪いから、コード中心で、ドキュメントは必要最小限に」というコード主義のスタイル。
4本目は、巨大プロンプトを分解して部品として育てる「faceted-prompting」という設計志向のプロンプト管理術。
そして5本目は、インターンがゼロからCI/CDを整えてリリース頻度を110倍にしつつ、「技術だけじゃなく合意形成も大事だよね」と教えてくれる現場の物語でした。
気になった記事があったら、詳しい内容は番組のショーノートにまとめてありますので、そちらからぜひじっくり読んでみてください。
「zenncast」では、番組の感想や、取り上げてほしいテーマ、「こういう開発の悩みあります」みたいなお便りも常に募集しています。ラジオネームを添えて、気軽に送ってもらえると、マイクが喜びます。
それでは、そろそろお別れの時間です。
今日も良い一日になりますように。お相手はマイクでした。
また次回の「zenncast」でお会いしましょう。バイバーイ。