ゼスト Tech Blog

ゼストは「護りたい。その想いを護る。」をミッションに、在宅医療・介護業界向けのSaaSを開発しています。

OpenSpec好きかもしれない

ゼストでPEM(プロダクトエンジニアリングマネージャー)兼バックエンドエンジニアをやっている今井です。

この記事は、ゼスト Advent Calendar 2025(https://adventar.org/calendars/12198)の15日目の記事です。

普段は主にClaude Codeを使っていますが、昨今のAI活用ビッグウェーブに乗るべく試行錯誤する中で、OpenSpecを導入して「仕様駆動開発」なるものをやってみました。

触ってみた感じ、

  • 実装だけじゃなく上流の一部も任せられて手間が減る
  • よくある「ちゃんと指示が伝わってるかわからない」というストレスも減る

みたいなところで自分的には結構やりやすかったので、その辺りの所感を書いていこうと思います。

なお、「仕様駆動開発とは」とか「OpenSpecとは」とか、その辺りは先人の皆様がたくさん情報を発信してくれていると思うので、本記事ではざっくり説明に留めます。


これまでの我流

別に「仕様駆動開発」とは呼んでなかったですが、「仕様を細かく固めてから渡す」というやり方自体は以前からやっていました。これより我流!仕様駆動と呼びましょう。

我流!では、

  • やりたいことの概要
  • 細かい仕様などの詳細
  • 留意点
  • 参考にできそうな実装

というような情報をMarkdownでファイルに書いておき、それを実装指示として渡していました。

実装はこれでそこそこ助けられてました。


我流!のここがダメ

書き出しが重い

我流!は結局のところ、仕様を頑張って言語化するのは人間です。

順序立てて抜け漏れなく情報を渡さないとあらぬ方向に進んでいくので、この工程を割と丁寧にやります。

普通に自分で実装しててもMP使う部分ではありますが、感覚的にわかっているものを文字に起こそうとするとさらにMP使うので、場合によっては「これもう自分で実装し始めた方が早いのでは?」という気分になります。

そうでなくても、大枠を実装して道筋を作ってあげてから指示したり、逆にリライト前提でざっくり作らせてから自分で細かいところ詰めていったりしてました。

ここはAI駆動にいまいち気乗りしない人たちにこそめんどくささをわかってもらえるはず。

どうやって出来上がってくるかわからない

指示出した後「なんか長いこと頑張ってんな」と思って確認しにいくとわけわかんないことやってたり(これはプロンプトが悪いかもしれない)。

多分一般的には正しいけどうちのプロジェクトでは微妙にファイルの作成単位とか実装場所違うんだよ、ってことが起こったり。

これらはあるあるですが、これが起きないように頑張って情報を渡しても、それがどれくらい正しく伝わってるかわからないのがストレスだと思ってます。

最後は「大丈夫だよな?これだけ書いてるんだから流石にわかるよな?」とヒヤヒヤしながら実装指示を出すのです。そして時に、すべてが無に帰ります。


OpenSpecを使った仕様駆動開発

細かい仕様は割愛しますが進め方はだいたいこんな感じ。

  • まずはざっくり指示を出す
  • すると仕様案が出てくる
  • それをレビューして細かいところ擦り合わせる
  • 仕様が固まったら実装

以降はいつもと同じです。 この「ざっくり指示で実装前の仕様案が出てくる」がよいです。


OpenSpecのここがいい

冒頭で書いた、

  • 実装だけじゃなく上流の一部も任せられて手間が減る
  • よくある「ちゃんと指示が伝わってるかわからない」というストレスも減る

の部分です。

まず、最初にざっくりとやりたいことを伝えるだけで、今まで人間がMP削って言語化していた作業をやってくれます。

「あれこれ伝えないと何が出てくるかわかったもんじゃない」という恐れは捨てて、「あの辺りはパッと軽めで、そっちはこうガッ!って感じで、まぁいい感じに頼むよ」と投げましょう。

流石にそこまで雑だと無理そうですが、私が最近投げた最初のプロンプトはこんな感じでした。

URL Shortenerの仕組みを作りたい。
URLを短縮してマッピングを保存しておく関数(service)と、短縮URLがリクエストされたときにリダイレクトされるエンドポイント(router or
usecase)が必要になる。

ChatGPTとかGeminiとか使って壁打ちしながら仕様を書いていってもいいですが、現状の実装を確認しながら仕様を詰めてくれるのが強いと思います。

むしろ人間が認知できる範囲を超えて広く見てくれるので、出てきた仕様を見て「あー!確かにそこ考えられてなかった!」と気づくこともあります。 自分で実装してたら、しばらく実装進めた後に考慮漏れに気づいて手戻り、とかあると思います。

そしてもう一つ、最初のざっくり指示ですべてが伝わっていることは無いとしても、「わたしここまで理解してますよ」が仕様として書き起こされるのが良いです。

どのファイルをどう直す、まで出してくれるので、明らかに方針が違っていたらその部分を修正するか、場合によっては一旦クリアして、少々親切めに最初のプロンプトからやり直してもいいです。

そんな感じで細かいところを仕様書ベースで修正しながら、最後は自信を持ってレッツ実装です。


総評

総じて、個人的には結構好きでした。

元々感じていた課題感が解消されるのもそうですが、考慮漏れに気付けるのは普通に役立ってます。

あと地味に助かってるのは、大きめの開発でも一度仕様書に出してさえおけば、中断して別の開発を進められるところです。

今後もいろいろ試していこうと思います。