🎃

すぐに使える仕様書駆動開発のテク~深掘り戦略~

に公開
ChatGPT
LLM
生成 AI
Claude
zennfes2025ai
tech

はじめに（雑談）

こんにちは、私はここ一年くらいずっとC向けアプリを開発しています。
LLM時代真っ只中で、開発過程でBoltなどでのバイブコーディングが流行り、Claude Codeの波が来てローカルでの開発が本格的にLLMを使ってできるようになり、最近では仕様書駆動開発、Codex Cliなども流行ってますね。
流れが早すぎて、ぶっちゃけ１ヶ月前に書いた記事の情報がもう役立たずです。
できるだけ情報鮮度が低くならない、テクニックの記事を書きたいと思っています。

今回は、仕様書駆動開発を試している時に発見した良きアウトプットを得られるLLMへの指示方法を共有します。この手法は何時間も時間を節約してくれると思います。

深掘り戦略

それは納期3日前の深夜、AIが生成したコードが全くの見当違いで、絶望の淵に立たされた時のことでした。もうAIに任せるのはやめようと思った瞬間、ふと閃いたのです。「こいつに答えさせるんじゃなく、質問させればいいんじゃないか？」と。いわば、AIをプログラマーから敏腕インタビュアーに転職させるような発想の転換でした。

仕組み:

  1. まず、解決したい問題の断片をAIに投げつけます。
  2. AIは「承知しました！」と見切り発車するのをぐっとこらえ、「お客様、もう少し詳しく…」と優秀なコンサルタントのように質問を返してきます。
  3. あなたは刑事ドラマの取り調べのように、AIからの質問に答えていきます。
  4. すべてのピースが揃った時、AIはあなたが本当に欲しかったオーダーメイドの解決策を提示します。

利点:

  • AIの危険な「たぶんこうだろう」という憶測を防ぐ。
  • 「あ、それ言うの忘れてた！」という自分のうっかりミスをAIが炙り出してくれる。
  • 最終的に、手戻りの少ない精度の高い回答が得られる。
  • （AIとの間に「我々はチームだ…」という謎の連帯感が生まれる。）

使用例:

ECサイトのレコメンド機能を実装して
こんな雑な指示を出す代わりに、深掘り戦略を使います。

ECサイトにユーザー向けのレコメンド機能を実装する必要があります。コードを書く前に、私に特定の要件や制約について関連する質問をしてください。

すると、LLMは次のような質問をします:

LLM:

レコメンド内容はどのくらいの頻度で更新される必要がありますか？
A) リアルタイム: ユーザーの直近のアクション（クリックなど）が即座に反映される。
B) 準リアルタイム: 数分〜数十分程度の遅延で反映される。
C) バッチ処理: 1日に1回など、定期的にまとめて計算・更新する。
D) その他

ユーザー:

B

LLM:

ユーザーの行動（商品のクリック、カート追加など）を、どのように収集・記録していますか？
A) Webサーバーのアクセスログ: Webサーバー（例: Apache, Nginx）のログに記録している。
B) アプリケーションログ: ECサイトのアプリケーション自体が、ユーザー行動をデータベースやファイルに記録している。
C) 専用のトラッキングツール: Google AnalyticsやAdobe Analyticsのような外部サービス、または自社開発のトラッキング基盤を利用している。
D) これから実装する必要がある: まだ明確な収集基盤はない。

このヒアリングを繰り返すことにより、あなたが本当に必要としているものを正確に理解し、期待以上のアウトプットを生み出します。

おまけ: 技術選定を終わらせに来たAI

フロントエンドフレームワーク選定という、開発チームを二分する聖戦が勃発した時のことです。React主義者、Vue派、そしてSvelte派が三つ巴となり、会議室は混沌と化していました。ネットの比較記事はどれもポジショントークばかり。我々は、公平な第三者、つまり感情を持たないAI審判を召喚することにしました。

使用例:

どのフロントエンドフレームワークを使うべきですか？

このように尋ねる代わりに
技術選定終わらせ戦略を使います:

リアルタイムでデータを可視化する、インタラクティブなダッシュボードアプリケーションを開発しています。
このアプリケーションのフロントエンドにReact、Vue、Svelteを使用する場合の長所と短所を公平な立場で徹底的に分析・報告してください。
将来性、学習コスト、パフォーマンス、エコシステムの成熟度、状態管理の容易さなどの要素を考慮してください。

利点:

  • 「俺はこれが好きだから」という宗教戦争を回避できる。
  • 潜在的な欠点を強制的に考慮させる。
  • 構造化された比較フレームワークを提供する。
  • 事前に制約を考慮することで、コストのかかる間違いを避けるのに役立つ。
  • （不毛な会議を終わらせ、開発に集中できる時間を取り戻せる。）

客観的な分析が、あなたのチームを技術選定の泥沼から救い出す一筋の光となるはずです。

おわり

Discussion