はじめに
LLMを使って開発していると、こんなことが増えてきませんか？
- 無限プロンプト地獄： 最初の出力で80%はできているのに、細かい仕様の調整やバグ修正のために、20回以上もやり取り（微調整）を繰り返すことになる。
- パターンの重複： 似たような機能を作るたびに、同じような修正プロンプトを何度もLLMに送り直す必要があり、効率が悪い。
- コンテキストの肥大化とコスト増： やり取りが増えるほどプロンプトの消費トークンが増え、APIコストやChatGPTの利用制限が跳ね上がる。
この問題を解決するために、Redditのある投稿者は
機能を直接作らせるのではなく、まず再利用可能なモジュールを作る
という進め方を試し、その結果、
LLMへの指示のブレが減り、新規機能の実装も安定しやすくなった
という効果が得られたとのことです。
本記事では、投稿者の許可を得たうえで、そのワークフローの概要について、実例を交えながら整理します。
💡 提案：2ステップに分離する新ワークフロー
投稿者が採用したのは、まず再利用可能なモジュールを作り、その後で個別機能を実装するという2段階のアプローチです。
具体的には、プロセスを以下の2つのフェーズに分離します。
-
フェーズ1： 「Verdentのプランニング機能」 ＋ 「Codex」で、汎用的に使い回せる 「再利用可能なモジュール」 をまず作成する
-
フェーズ2： 完成したモジュールをコンテキストとして与え、具体的な個別機能を実装する
🛠 具体的な検証例：ワークフロー実行ツールの作成
投稿者が検証した例を紹介します。
バックエンド（API/K8s）からフロントエンド（UI）までを含む、少し複雑な「非同期ワークフロー実行モジュール」を実装するケースです。
既存のReddit分析ツール（reddit-post-analyzer）のコードを参考にしつつ、以下のプロンプトを投入しました。
1. Verdentへのプロンプト入力
please combine the code from /en/tools/reddit-post-analyzer and the doc docs/workflow/ASYNC_WORKFLOW_GUIDE.md generate a demo tool, contain preview logic and async execute logic preview return some test information execution sleep 10 seconds then return test information
（訳：
/en/tools/reddit-post-analyzerのコードとdocs/workflow/ASYNC_WORKFLOW_GUIDE.mdのドキュメントを組み合わせて、デモツールを生成してください。プレビュー論理と非同期実行論理を含める必要があります。プレビュー時はテスト情報を返し、実行時は10秒間スリープした後にテスト情報を返すようにしてください）
2. Verdentによるプランニング
ここで「Verdentの真価が発揮されます。
Verdentはこの曖昧な要求を噛み砕き、厳密なアーキテクチャ計画へと分解しました。
3. Codexでのコード生成・適用
Verdentが作成した精緻なプランをCodexに読み込ませたところ、なんと
- Reactコンポーネント（UI）
- APIルーティング（Backend）
- Kubernetesマニフェストファイル（Infrastructure）
などを含む計21個のファイルを一度に修正・生成したそうです。
あとは、この完成したモジュールを今後の開発の「基準（リファレンス）」としてストックしておくだけです。
なぜ、モジュール化を挟むと結果が安定するのか？
投稿者は
「最初からVerdent＋Codexで最終的な機能を作ろうとした時よりも、間にモジュール化を挟んだ方が遥かに結果が安定した」
と述べ、明確な理論的根拠がわからないが、次のような理由が考えられるのではないかと推測しています。
①関心事の分離（Separation of Concerns）によるLLMの集中
プロセスを分けることで、LLMのタスクがシンプルになります。
- モジュール作成時： LLMは「汎用的な設計パターン（アーキテクチャ）」を正しく組むことだけに集中すればいい。
- 機能実装時： 既に目の前にある設計パターンをコンテキスト（手本）として見ながら、「固有の業務ロジック」を実装することだけに集中できる。
人間が難解なシステムを設計する時と同じで、LLMにとっても「設計」と「実装」を同時にやらせない方が、圧倒的に精度が高くなります。
② 大幅なトークン削減（低コスト化）
「Verdentで「プランニング」を行うフェーズは、最もトークンを消費する部分です。
しかし、このワークフローなら 重いプランニングセッションは「最初の1回（モジュールの設計）」だけで済みます。
類似の機能を作る際は、そのモジュールをコピーして使い回せばいい。これによって開発コストを大幅に抑えることができます。
おわりに
投稿者の事例では、Verdentでplanningを行い、Codexでモジュール実装と機能展開を進めることで、複雑な機能でも安定性と再利用性を両立しやすくなったとのことです。
特に、似た種類の機能を継続的に開発している場合、この「モジュール先行」の考え方はかなり相性が良いように感じました。
もし、LLMを使った開発フローの中で要件整理や設計分解をもう少し自然に組み込みたい場合は、planningの選択肢としてVerdentを見てみるのもよいかもしれません。