そうすればハングルもいけそうだと、ふと思った……パズルは作れそうですね……

スクリーニング用途としてだけうまく使わせていただきます

売買注文の場合、プロンプトインジェクションなどによって意図しない注文が処理される可能性がありそうなので、注文対象や金額の制限といった追加機能は必須になりそうですね。

申し訳ありません;;

Kiro IDEを思い出しますね

ありがとうございます。

はい、私も同じ考えです。 しくしく

実験は楽しく拝見しました。

タイトル釣りがうまいですね..

ソーシャルメディアが時間の浪費であるという点では、ギャンブルや薬物のように『後悔』や『恥』という感覚のほうがしっくりくる。

面白いですね。理にかなっている気もします。

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

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回だけ行って比較されたのではないでしょうか？

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