内容とは別に、「たった一行のプロンプト」というタイトルのせいで、期待していた内容と本文の中身が違って見えて、なおさらそう感じる気がします

k9s - ターミナルUIでKubernetesクラスターを管理するツール

記事の途中にあるSDDの詳細紹介リンクは内容が良いですね。以下はAIで要約してみたものです。

仕様駆動開発（Specification-Driven Development, SDD）

The Power Inversion

• コード中心でPRD・設計文書が補助していた流れを反転させ、仕様が原本であり、コードは特定の言語・フレームワークで実装される表現物とみなす
  • 仕様と実装の間にある恒久的なギャップは、文書補強や手順強化では解消しにくかったという診断を示す
  • 実行可能な仕様と実装計画がコードを生成すれば、ギャップは消え、変換だけが存在する
• AIは複雑な仕様解釈と実装計画の策定を可能にするが、構造のない生成は混乱を招くため、SDDは精密な構造とガードレールで品質を確保する
• 保守は仕様を進化させる行為であり、開発意図は自然言語・デザイン資産・中核原則で表現され、コードはラストマイルの位置づけとなる
• デバッグは誤ったコード修正よりも仕様・実装計画の修正を優先し、リファクタリングは明確さの再構成という意味に再定義される

The SDD Workflow in Practice

• アイデアをAIとの対話的な相互作用でPRDへと洗練し、AIは質問・エッジケース・受け入れ基準を具体化する
  • 要求と設計を連続した活動へ変換し、チーム単位のブランチベースの仕様作業とレビュー・バージョニングを支援する
• リサーチエージェントがライブラリ互換性、性能、セキュリティ、組織上の制約（DB標準・認証・デプロイ方針）を調査し、仕様へ自動反映する
• PRDから実装計画を生成して要求と技術判断を追跡可能にマッピングし、AIが矛盾・曖昧さ・欠落を継続的に検証する
• 仕様・計画が十分に安定したらコード生成を開始するが、初期には探索的生成で実現可能性を検証する
  • ドメイン概念はデータモデルに、ユーザーストーリーはAPIエンドポイントに、受け入れシナリオはテストへと変換される
• 運用段階のメトリクス・インシデントは仕様を更新して次の再生成に反映され、性能ボトルネックは非機能要件に、脆弱性は全体制約へと昇格する

Why SDD Matters Now

• AI能力の臨界点: 自然言語仕様から動作するコードを信頼性高く生成でき、実装翻訳の機械的な部分を自動化することで探索と創造性の増幅を支援する
• 複雑性の爆発的増大: 多数のサービス・フレームワーク・依存関係により意図と実装の整合性維持が難しくなり、SDDの仕様駆動によるアラインメントが必要になる
• 変化の加速: 頻繁なピボットが起きる状況で、SDDは変更を文書・設計・コードへの手作業伝播ではなく体系的な再生成で処理する
  • 例としてwhat-ifシミュレーションや並行実装を可能にし、意思決定の俊敏性を提供する

Core Principles

• 仕様=共通言語: 仕様が第一級成果物であり、コードは特定スタックの表現、保守は仕様進化の行為である
• 実行可能な仕様: 正確・完全・非曖昧なレベルの仕様から動作するシステムを生成する
• 継続的洗練: 一度きりのゲートではなく常時一貫性検証を行う
• リサーチに基づくコンテキスト: 性能・セキュリティ・組織制約を継続的に収集して仕様へ注入する
• 双方向フィードバック: 運用の現実が仕様更新の入力になる
• 探索のためのブランチング: 同一仕様から性能・保守性・UX・コストなど最適化目標ごとの複数実装生成を支援する

Implementation Approaches

• 今日の実践では既存ツールの組み合わせと規律の維持が中核であり、次の要素で実装できる
  • 仕様の反復洗練用AIアシスタント
  • 技術コンテキスト収集用リサーチエージェント
  • 仕様→実装変換用コード生成ツール
  • 仕様優先ワークフローに合わせたバージョン管理
  • 仕様文書のAI一貫性分析ベースのチェック
• 共通原則は仕様を単一の真実の源とし、コードを仕様が要求する成果物として扱う姿勢である

Streamlining SDD with Commands

• /specify: 機能説明を構造化された仕様へ変換し、自動採番、ブランチ作成、テンプレートベースのディレクトリ構成を自動化する
• /plan: 仕様分析 → 憲法準拠レビュー → 技術翻訳 → データモデル・API契約・テストシナリオ文書化 → クイックスタート検証を生成する
• /tasks: plan.mdと関連設計を読み、実行可能なタスクリストを出力し、並列可能タスクの表示と安全な並列グルーピングを提供する
• 例: チャット機能
  • 従来アプローチで約12時間かかる文書作業を、仕様・計画・タスクの自動化で約15分の構成へ短縮する流れの例を示す
  • 成果物として仕様、実装計画と根拠、API契約・データモデル、クイックスタートシナリオ、tasks.mdがブランチでバージョン管理される

The Power of Structured Automation

• 抜け漏れ防止: テンプレートが非機能要件・エラー処理まで包含する
• 意思決定の追跡可能性: すべての技術選択が具体的要件と接続される
• 生きた文書: 仕様がコードを生成するため同期維持が容易になる
• 迅速な反復: 要求変更時に計画再生成で分・時間単位の対応が可能になる

Template-Driven Quality

• 実装詳細の早すぎる流入防止: WHAT/WHYに集中し、HOWを排除するルールで抽象化レベルの維持を促す
• 不確実性マーカーの強制: [NEEDS CLARIFICATION]マーカーで推測禁止と明示的な質問を促す
• チェックリストベースの自己点検: 完全性・明確性・測定可能な受け入れ基準の確認で品質ゲートを実装する
• 憲法ゲート: 単純性ゲート（≤3プロジェクト）、反抽象化ゲート（フレームワークを直接使用）、**統合優先ゲート（契約・契約テスト先行）など事前段階（-1）**のチェックを適用する
• 階層化された詳細管理: 過度なコードや詳細はimplementation-details/へ分離して可読性を維持する
• テスト優先性: 契約→統合→E2E→単体順のファイル生成・テスト優先ルールで検証可能性を確保する
• 仮定・推測機能の抑制: 推測的機能の禁止と段階別の前提条件明示でスコープ管理を強化する

The Constitutional Foundation

• memory/constitution.mdの不変原則により、すべての実装を一貫・単純・高品質に保つ開発憲法を採用する
  • Article I: Library-First — すべての機能は独立ライブラリとして始め、モジュール性を確保する
  • Article II: CLI Mandate — すべてのライブラリはテキスト入出力・JSONをサポートするCLIインターフェースを公開し、可観測性とテスト容易性を保証する
  • Article III: Test-First — テスト承認・失敗（red）確認前の実装禁止、振る舞い定義優先原則を適用する
  • Articles VII & VIII: 単純性・反抽象化 — プロジェクト数の最小化とフレームワークへの直接的信頼で過剰設計を抑制する
  • Article IX: 統合優先テスト — 実環境に近いテストを優先し、契約テストを実装前提として強制する
• テンプレートのPhase -1ゲートで憲法準拠をチェックリスト化し、例外はComplexity Trackingに明示的な根拠を記録する
• 改訂手続きを通じて原則の適用方法は進化可能だが、中核哲学は維持される

The Transformation

• 目標は開発者の置き換えではなく、機械的な翻訳の自動化による人間能力の増幅と意図-実装整合性の維持である
• SDDは仕様がコードを生成するようにし、仕様・リサーチ・コードが密接なフィードバックループで共進化する継続的変換を実践する

ビッグブラザーのソースコード流出！

また、プロンプトの連結回数の実験に関する内容についてもご質問いただきました。

実のところ、これは逆に言えば、著者が俗にいうところのごまかしをしやすい要素でもあります。

開発という行為そのものには、進める方向に非常に多くの選択肢が存在しており、トークン使用量がより大きく開く方向にプロンプトを積み重ねてしまえば、その数値は雪だるま式にさらに大きく膨れ上がってしまうでしょう。

研究には「Cumulative Science」という哲学があります。

少なくとも私の基準では、1回の命令に対するトークン使用量に関する研究をこれまで一度も見つけたことがなかったため、

いきなりN回の研究をするのではなく、確実な1回分のテストと結論を扱うことに集中したのであり、

N回の研究は、この実験に続いて研究が進めばよいでしょう。

土木のような分野をやるなら、大学の授業でもすでに使われていますね

また別の記事として、コードベースの違いによるAIの挙動の差を扱ったことがあります。
（これもこのGeekNewsで紹介されたことがあります: https://modgo.org/aineun-hyeonjae-kodeu-gujoyi-byeoge-maghyeoissda/）

簡単に説明すると、AIに入力されるコードベースによって出力物の品質が変わる、というテストと結果を扱っています。

初期コードベースの品質や方向性によって、その後のコード品質が維持されることもあれば、継続的に悪化していくこともある、という意味です。

つまり、プロジェクト初期段階でのリファクタリングコストと、かなり進行したプロジェクトでのリファクタリングコストは大きく異なりうる、ということです。

もし質問者の方が開発者であれば、「帆船の上の空母」という言葉を一度くらい聞いたことがあるかもしれませんが、

リファクタリングをどの時点で行うべきか、あるいはプロジェクト初期に塗られる思想や設計によってコストが莫大に変わる、という深遠なテーマです。

これを変数として含めて結論を不安定にするより、

「なるほど、コードベースの品質が良ければトークン使用量が減るのだな」という点だけは確実に説明できるテストを行った、ということです。

改めて説明します。

バイブコーディングの実践者は、非開発者から熟練開発者まで幅広く存在します。彼らが持つ知識の状態によって、この文章の内容とはまったく無関係に、出力物の品質は大きく異なります。
ある人は、Cursor の利用を前提に .cursorrules に基本的な OOP 規約やクラス／メソッド分離ルールを入れて、ほとんどリファクタリングが不要な形で運用できているかもしれませんが、
また別の人は、あまりにも基本的な主要内容の把握不足によって、低水準のコードを大量生産してしまっているかもしれません。

そもそも、プロジェクトルールの設定によってコード品質を高く保つべきだという記事や経験談は、以前から多くあります。

• ファイルサイズを小さく保つこと : https://medium.com/realworld-ai-use-cases/…
• コードベースの実行速度を速く保つ方法 : https://forum.cursor.com/t/…
• Windsurf のベストプラクティスとガイドライン : https://gist.github.com/muratkeremozcan/…

これは、明示的なリファクタリングをしなくても、トークン使用量の観点で利益を得ている人がいる可能性を示唆しています。

ただし、上記のケースでは、そのルール定義によって実行単位ごとの明確なトークン使用量削減までは整理されていません。そこで本稿では、コードベースの品質によるトークン使用量の差をテストし、その結果を整理しました。

つまり、ユーザーによっては、明示的リファクタリングの回数そのものが再び 0〜n 回という変数になり、

この文章の本質的な意図は、『なぜ品質の高いコードベースを気にかけるべきなのか？』を説明している、と捉えていただくのがよいと思います。

コメントでおっしゃっていることが何なのか、正直よく理解できません。私は、2つの方法を公平に比較するなら、消費される総トークン数を比較すべきではないか、というのが私のコメントでした。リファクタリングもやはりトークンを消費するのではありませんか？

加えて、ご返信いただいた内容は記事にも書かれておらず、実験も行われていない内容のように思えます。1回の問い合わせあたりのトークン比較ではなく、複数回問い合わせた場合にはリファクタリングのオーバーヘッドが低くなり、各問い合わせあたりの期待トークン数が減るため、総トークン数で得になるだろう、というお話のように見えます。これは、複数回の問い合わせでも筆者のお考えどおりにコストダウンが維持される場合に限って言えることで、かなり理想的な状況を想定した話のように思います。リファクタリングによるコストダウンが、その後の問い合わせ回数に関係なく維持される保証はありませんし、実験なしに仮定することもできません。意図された主張をされるのであれば、1回を超える問い合わせに対するコストダウンを実験で示していただければよいと思います。しかし、実験は1回だけ行って比較されたのではないでしょうか？

付け加えると、これはあくまで私の仮定にすぎませんが、同じ目標（理想的な最終出力物）のために問い合わせを無限に繰り返していくなら、理想的な状況ではリファクタリングの有無に関係なく、コードは同じ形に収束していくはずです。（理想的な最終出力物は一意）
この仮定が合理的であるなら、問い合わせが繰り返されるほどリファクタリングの有無による差は小さくなるため、トークンのコストダウンによる利得も次第に小さくなるように思います。したがって、巨視的に考えたとき、このコストダウンによる利得が十分に持続しないのであれば、問い合わせに使われる総トークン数の差は有意ではない可能性もあるのではないでしょうか

この記事は『実験』研究に近い性格のものであるため、

この記事に含まれるすべての数値は、この記事を読むすべての人が『再現』できるようにすることに重点を置いています。

そのため、使用した元のソースコードと、テストに使用したすべての手順をすべて記録し、

すべての実験者が同じ結果を得られるよう、情報を提供することに内容の重点を置いています。

コメント欄の雰囲気を見て感じたのですが、

今後は3行要約寄りの記事を1本と、
詳細を知りたい人向けの記事を分けて2本にして書くべきかとも考えています。

この記事のどの部分が過度に複雑に感じられたのか、そして冗長だったのかを教えていただけると、
今後の記事執筆にあたって大いに助けになると思います。

3. より多様な実験が必要

全面的に同意します。このような形の批判は大いに歓迎します。

世の中は一人で生きているわけではなく、個々人の能力や状況も異なります。

私もまた一介の開発者にすぎず、個人の費用ですべてのテストを実行することはできません。

この記事が種となって、多くの人々に良い影響を与え、そして続く多くの研究の出発点になればと願っています。

2. 前処理の前後でソースコードを比較する必要があります。

サブタイトルが内容と合っていませんね。整理し直すなら、「トークン削減を引き起こす、より明確な要因分析が必要だ」がサブタイトルとしてふさわしく見えます。

この内容には同意できる部分が多いです。ただし、本稿の性格としては、「この記事を見る人たちに現実的な適用方法を提案する」という要素を含んでいます。

すでに、この記事についたコメントを見るだけでも雰囲気は分かるのですが、私も最近知ったことではあるものの、AIユーザーの中には非開発者のバイブコーダーの方々も多いと推測されています。

AIを介さず、著者が直接調整したコードから大きな成果を生み出すことになった場合、

それは著者が開発力を誇示し、AIの能力を軽視している結果だと受け取られやすいです。

そのため、さまざまなバイブコーダーが活用できる「プロンプト」という要素として、その結果を誰もが体感できる例を扱うことになりました。

この研究に続いて、AIのトークン使用量に影響を与える要素を細分化できる研究が続くとよいと思います。

1. 公平な比較に関連して

• バイブコーディングでは、1回のプロンプトで成果物が完成するわけではありません。
  1回の構造修正によって、n回のプロンプトにおけるトークン消費率を下げる効果が生じる場合、トークン削減量は同様に行われるn回全体にわたって反映されます。
  nはプロジェクトの目的と機能数、そしてそのためのコード量と複雑さによって決まる数値であり、
  また最近の Cursor / Claude Code agent では、無限反復実行やAIの無分別なトークン使用の問題を解決するため、実行単位を小さくするアップデートが行われていることから、

プロジェクトの複雑度に関するnの値の研究は、別途行うのが適切だと考えます。

• できるだけ理解しやすくするため、別途指示がない場合にAIが作成しがちな、構造上の問題を持つコードからコード改善の例を挙げました。
  ここで見落としてはならないのは、構造の改善は決してコード開発と独立して起こる行為ではないという点です。
  最初のプロンプト、あるいはAI ruleset（.cursorrules）のような制約を通じて、base context として影響を与えられる部分であり、
  プロジェクト開発サイクルの途中で1回の構造改善だけですべてがうまくいくわけではありません。
  つまり、一定周期でコード改善を計画するよりも、base context として正しい構造へ導くほうがより良い方向です。

また、base context として構造誘導の指示ルールがある場合とない場合に関する研究は、別途行うのが適切に思われます。

1番の項目について整理すると、

• base context として構造誘導の指示ルールがある場合、全体のトークン使用量が減少する可能性もあり、
• n回のプロンプト命令を通じて最終成果物を得るという変数があるため、
  1回の構造改善プロンプト命令のトークン使用量を加算して計算すべきだという主張には語弊があります。

私も似たように感じました。
書かれた方の意図はわかるのですが、されていることに比べて文章がやや複雑すぎる気がします。
できるだけ実験に使われたディテールを文章に溶け込ませたくてこのように書かれたのだと思いますが、
核心だけを簡潔に抜き出しても、このテーマに関心のある方ならおそらく理解できると思います。
思い切ってディテールを削り、要点だけに絞ればもっと良くなるのではないかと思います。

私は、書き手の意図や結果自体は面白いと感じました。
より良いソースコードがより少ないトークン消費につながる、というのが主な論旨であり、
それに関連した実験設計をして実施されたように見えます。

実験について私が理解した部分だけを並べると、

1. AIに問い合わせるソースコードと、そのソースコードをプロンプトで前処理（？）したソースコードの2種類を準備
2. GPT5、Sonnetでそれぞれ5回ずつ2つのソースコードを実行させ、トークン消費量を比較
   ということのようです。
   そして私の理解が正しければ、プロンプトで前処理したソースコードのほうが全体的にトークン消費量が少ない、という結論のようです。

面白い結論ではありますが、実験に対する私の意見は次の通りです。

1. 公平な比較ではない
   数値上は下がっているように見えますが、ソースコードを処理するための総トークン数で比較するのが正しいと思います。
   言い換えると、前処理のために使われたトークン数も考慮されるべきだと思います。
   前処理に使われたトークン数が過度に大きければ、実質的にはトークンをより多く消費していて無意味になりますし、少なかったとしても、実際のトークン消費量の差は文章で示されたものよりかなり小さいのではないかと思います。

2. 前処理前後のソースコードを比較する必要がある
   前処理に使われたトークンを除外するなら、問い合わせ時のトークン消費量は有意に減少しているように見えます。
   ただし、ソースコードのどのような違いによってこうした差が出るのかを分析すれば、文章の意味はより大きくなると思います。
   そうした差を最大化するための前処理プロンプトの最適化が可能だという話になりますから。
   書き手の方はコード構造のリファクタリングがこの結果をもたらしたとおっしゃっていますが、私は同意しておらず、まだわからないと考えています。
   AIに対して、リファクタリング以外の部分を改善した場合でもトークン消費量の減少が起こりうるかもしれないからです。

3. もう少し多様な実験が必要
   現在のコードだけでなく、別のコードベースでも同じ実験を回してみるべきだと思います。
   これが一貫して良い結果になるのかどうかを判断する必要があるからです。
   ただ、現実的にはこれはテストが難しいかもしれないという点は理解できるので、参考程度に受け取るのがよいと思います。

役に立たないプレゼントを贈るのが人気みたいですし……新しい役に立たないプレゼントを発掘するには良さそうですね

追加で使用したプロンプトに関連する内容を整理してお伝えします。

どちらかといえば、開発者の方が構造改善用のプロンプト作成に向いています。プログラムごとに性質が異なるため、効率の高い改善を行うには、ある程度の開発知識が必要です。

とはいえ、非開発者のバイブコーダーの方々がこの方法を使えないという意味ではありません。効率には差が出るかもしれませんが、"プロジェクトのコードを整理して。使っていないコードは削除して。" のようなシンプルな命令だけでも、AIはファイルやクラスを分離・整理する動きをします。

ただし、構造改善の細部の違いが効率の差を生みうる点については、参考資料の扱いに注意が必要です.

空間情報を活用する機会があるなら、良い選択肢です。

この記事に多くの関心をお寄せいただき、ありがとうございます。海外向けの配布を主な目的としていたため英語で記事を作成しましたが、そのためにいろいろな問題が発生しているようです。

そこで、韓国語で整理したポストを共有します。

https://modgo.org/tokeun-sayongryang-37-91-reul-gamsosikin-dan-hanjuly…

AIにコード構造のリファクタリングを指示した後、消費されるトークン量が減ったというのが核心です。
逆に言えば、コードに構造的な欠陥がある状態で指示を続けると、トークン使用量が増えるとも説明できそうです。

要するに、ソースコードの構造改善が必要だという内容であり、プロンプトを要点だけに絞って論理的に書くべきだという意味ではありません。

プロンプトには要点だけを論理的に盛り込むべきだ。つまり、プロンプトにあれこれ多く付け加えるほどノイズが増え、結果として出てくるコードも複雑になり、ノイズも多くなる、ということですか？