Cursorはまだ使うな！ - テンプレ量産から資産型フレームワークへ -

ROIで科学するマーケティング vs 開発

「広告費の半分は無駄になっている。しかしどの半分かは分からない」――かつてのマーケティング業界では、そんなジョーク（ジョン・ワナメーカーの名言）が真顔で語られていました。

※ 参考記事要約: 広告費のROIは長年ブラックボックスであり、予算の大半が“闇に消える”現実があった

しかし2000年代に Google AdWords（現 Google 広告）が登場し、歴史は一変します。2005年に導入された「コンバージョントラッキング」によって、広告をクリックした後のユーザー行動を追跡し、売上や問い合わせと直接結びつけられるようになったのです。

※ 参考記事日本語要約: Google広告はクリック後の成果を測定可能にし、ROI分析と戦略最適化の時代を切り開いた

さらにAdWordsは 広告の民主化 を推し進めました。小さな町工場でも、キーワード単位で入札すれば世界中の検索結果に並べる。つまり「大企業の宣伝部」と「地方の中小企業」が、同じリングに立てるようになったのです。

※ 参考記事日本語要約: 小規模事業でも少額で広告を打ち出し、即座に検索結果で露出できるため“レベル均衡”が実現。ROI測定に加えて、市場構造そのものを変革した。

広告の世界は直感と根性の勝負から、データに基づく科学へと変貌しました。

では――ソフトウェア開発はどうでしょうか？

---

長年、ソフトウェア開発現場では、工数見積もりは当てにならず、リファクタリングは「エンジニアの趣味」 と揶揄され、経営層には ROI が見えない“暗黒大陸” でした。

開発投資は 「人月」 で語られ、成果に直結するKPIが存在しない――まさに一世代前の広告業界と同じ構造なのです。

「開発原価の半分は無駄になっている。しかしどの半分かは分からない」―

ところが今、Cursor や GitHub Copilot のような 生成AIコーディングが普及し始めたことで、ソフトウェア開発も ROI で科学する時代に突入しつつあります。

ここで重要なのは、AI利用コストが直接“数字”として表れることです。生成AIでコードを書かせれば、必ずAPI利用料＝トークン課金が発生します。これはまさに 現代のネット広告における「広告費」 と同じ構造です。

ここが最大のパラダイムシフトです。

いままで、ソフトウェア開発現場では、見積もりは「人月」 という枠買い レベルで行われ、しかもいわゆるKKD(感・経験・度胸）法がまかり通り、営業が空気を読みつつ 「鉛筆ナメナメ」 で見積書を作成するという、一世代前の広告業界のような状況が続いていました。

ここにマーケティング業界におけるAdWordsと同様、生成AIコーディング という 黒船 が登場しています。

これは、例えば「AIエディタ」という名称も使われていますが、しかしもはや質的に「開発者体験を向上するコード補完の延長」というレベルではなく、かつてのマーケティング業界がそうであったように、生成AIという波により業界構造が一変させられる現象の始まりなのです。

そういった大局的な認識を持たず「とりあえず使い始めてみて」、プロンプト最適化やフォーマット化に走ってしまう・・・。その轍を読者の皆様に踏んでほしくないために、あえて挑発的なタイトルを付与させていただきました。

では、その挑発的なタイトル 『Cursorはまだ使うな！』 の真意を、ここから語っていきます。

Cursorの中のGPTは、わかっている。

この記事の結論は、次の "Cursorの中のGPT” との対話に集約されます。この対話ですべてがわかる方は、この対話だけ読んでいただければと思います。次章以降、この対話のポイントに対して私の視点でコメントをしていこうと思います。

▼▼▼ 以下、Cursorの中のGPT(GPT-5)との会話です。▼▼▼
※ 会話自体は新規チャットコンテキストで行っていますが、.cursorrules 等の影響は受けていると思います。

User

おじさん（俺）と君たち（生成AI）がこのコードベースでやろうとしてることと、そのビジネス上の価値と思われることを 1,200文字以内で経営陣や学生に理解できるレベルで説明して！

Cursor

やあ、GPT-5だよ。リクエストどおり日本語で要点をまとめるね。

何をやっているか（超要約）

• 共通の“ゲーム機本体（コア）”を作る: ゲームやUIの土台になる最小コアをTypeScriptで実装。
• 拡張は全部プラグインで差し込む: ルール、シーン、AI、描画/入力/音などは交換可能なプラグイン。既存を壊さず新機能を足せる設計（OCP）。
• プラットフォーム非依存: ブラウザやPhaserなどの違いはアダプタで吸収。将来のエンジン変更にも強い。
• 品質ゲートを最初に入れる: 例外処理/相関ID付エラー、lint/型チェック/テスト/カバレッジを標準装備。
• ドキュメントとテストが設計の一部: ADR/設計/実装ノート/テスト計画をリポジトリで一元管理。AIと人が同じ地図を見る。

これのビジネス価値

• 開発スピードと再利用性: コアは使い回し、案件ごとの差分はプラグインで追加。企画ごとの初期コストを大幅圧縮、Time-to-Market短縮。
• 変更に強い: 仕様変更や新デバイス対応でも既存を改変せず拡張で対応。レガシー化の速度を抑制。
• 品質と運用の安定: エラーは相関IDで即特定、テスト/カバレッジで回帰を自動検知。障害コストとリリース不安を低減。
• ブランド展開が楽: テーマ（色/フォント/レイアウト/アセット）を差し替えるだけで多ブランド・多地域展開に対応。
• AI協業で生産性向上: 設計・ゲートを共有することで、生成AIが安全に加速。人は難所の意思決定に集中できる。
• 教育的価値（学生向け）: SOLID/OCP/DIの「生きた標本」。設計→実装→検証の流れを体験学習できる“実行可能教材”。

要するに、拡張に強い基盤と厳格な品質ゲートで、「速く作り、壊さず育てる」ためのプロダクト/学習プラットフォームを一緒に作っている。

User

SOLID設計原則を守ることはCursor時代のトークン課金に対してどんな影響を与える？ AdWords がマーケティング業界を一変させたように、生成AIコーディングもソフトウェア業界の構造を一変させない？

Cursor

日本語で端的に答えるね。

SOLIDがトークン課金に与える影響

• SRP（単一責任）: モジュールが小さく目的が明確→必要コンテキストが局所化し、検索/読込トークンが減る。差分提案も短くなる。
• OCP（開放/閉鎖）: 既存を改変せず拡張で対応→コア全体を毎回読み込まずに済み、編集対象と説明トークンを最小化。
• LSP（置換可能）: 契約が安定→リライトの往復（試行→失敗→再生成）の回数が減り、交互プロンプトの総トークンを削減。
• ISP（インタフェース分離）: 小さなIFで依存が薄い→生成対象が限定され、スタブ/不要コードの自動生成が減る。
• DIP（依存性逆転）: 抽象に依存→AIに渡すべきのはcontracts/中心で済み、特定実装の長文コンテキストを省略可能。テストもモックで速く短く回せる。
• 注意点: 初期は契約/ドキュメントが増えて一時的にトークン増。だが反復開発で必ず元が取れる（長期の再利用時に大幅減）。

生成AIコーディングは業界を変えるか

• 作業の単位が変わる: 「ファイル編集」から「仕様/契約・テスト駆動の指示」へ。人は設計・品質ゲートのオーナーになる。
• 生産性の再配分: ボイラープレートは自動化。差別化はドメイン知識、UX、データ/運用ガバナンスへ移動。
• 組織構造のシフト: プラットフォーム/パターンを供給する中核チーム＋プロダクト側はプラグインで拡張。ジュニアの役割がレビュー/検証寄りに。
• 市場の長い尾: 小規模チームでも高品質を短期に出荷可能→供給が増え、品質ゲート/ブランド/運用が新しい参入障壁に。
• 広告→AI類比: AdWordsが配信最適化と自己サービスで市場を拡大したように、AIは開発最適化と自己サービス化でソフトウェア供給を拡張。ただし、勝敗は「設計ゲートと運用体制」を持てるかに依存。
• リスク管理が鍵: 依存地獄/プロンプト注入/ライセンス汚染/品質崩壊を防ぐため、貴プロジェクトのOCP設計と品質ゲート方針は正攻法。

結論: SOLIDはトークン消費を「設計で下げる」最有力手段。生成AIは業界構造を変えるが、勝者はAIそのものではなく、堅い設計とゲートを持つ開発体制だ。

User

頑張って「プロンプトテンプレート」を開発して使い捨てコード量産するのとの比較では、今やってることってレベチ？

Cursor

日本語で端的にいくね。

結論（ショート）

• レベチ。使い捨て量産は「瞬間最大風速」、いまのOCP/SOLID＋品質ゲートは「複利で資産化」。同じAIでも、設計でリターンの質が変わる。

比較（要点だけ）

• 初速
  • 使い捨て量産: 最速で形は出る。
  • いまの方式: 初期に設計/契約/ゲート整備が必要で一歩遅い。
• トークン/再生成コスト
  • 使い捨て量産: リライトと再生成の往復が増え、総トークン肥大しがち。
  • いまの方式: SRP/ISP/DIPでコンテキストが局所化。編集範囲が小さく、再生成回数と説明トークンが減る。
• 保守/変更耐性
  • 使い捨て量産: 部分最適の寄せ集め→結合度が上がり劣化スパイラル。
  • いまの方式: contracts/を核に拡張はプラグインで追加。既存はClosed、拡張点はOpenで安全に進化。
• 品質/運用コスト
  • 使い捨て量産: 障害時の調査は都度アドホック。MTTRが読めない。
  • いまの方式: 相関ID付きエラー、lint/type/test/coverageが標準。回帰検知と原因特定が速い。
• 再利用/多ブランド展開
  • 使い捨て量産: 企画ごと作り直し。
  • いまの方式: コアは共通、差分はプラグイン/テーマで再利用。Time-to-Market短縮。
• 組織学習/資産化
  • 使い捨て量産: 学びがコードに蓄積されにくい。
  • いまの方式: ADR/設計/テストが「実行可能ドキュメント」として残り、AIも人も同じ地図で動ける。
• モデル変動耐性
  • 使い捨て量産: モデルの癖/改定で成果が揺れる。
  • いまの方式: 抽象に依存（DIP）しているため、モデルやエンジン変更の影響を局所化。

どう使い分けるか

• 使い捨て量産の適所: L1プロトタイプ/マーケ検証/アイデア探索の瞬発力。
• 本線（いまの方式）: L2以上の製品ライン/長期運用/組織標準化。プロトタイプも最終的にプラグイン境界へ収容して資産化する。

要は、テンプレ量産は「速いが蓄積しない」。いまのやり方は「少し準備して、以後ずっと速い」。プロダクトを育てる前提なら、間違いなくレベチ。

User

ジュニアの役割がレビュー/検証寄りに

若手は動作確認でもやってろ！ってこと？

Cursor

違う。「動作確認でもやってろ」じゃない。AI時代の“検証”は開発の中核で、設計を実行可能にする高スキル領域だよ。

• 役割の狙い: 品質ゲート（テスト/型/カバレッジ/観測性）を回すことで、仕様を具体化し、AIと人の往復を速く安全にする。
• 若手がまず担うと伸びる領域:
  • 相関ID付きのバグ再現・最短手順化、ランブック更新
  • ユースケース/シナリオテスト作成（失敗時の期待/実際を明文化）
  • contracts/起点の小さなプラグイン実装と差し替え検証
  • 監視・ログの最小計測（何が見えれば安心かを定義）
  • ADR/設計ドキュメントの差分反映（設計≒コードの地図づくり）
• 成長パス（短サイクル）:
  1. シナリオテスト＋観測で仕様を掴む
  2. 小さな拡張（プラグイン/アダプタ）を契約どおりに実装
  3. 性能/回帰の指標化と自動化を導入
  4. 設計レビュー側に回り、AIへの指示精度を上げる

結局、「検証＝雑用」ではなく「プロダクトの舵」。ここを握ると、仕様理解・設計判断・AI活用力が一気に伸びる。だから“任せる”的に見えるだけで、実は一番の近道だ。

User

なるほどね、じゃあ SOLID 原則に従ってるAIとの共創用フレームワークがあったほうが若手にとっても幸せってことか。

Cursor

その通り。SOLIDに沿った“AI共創フレームワーク”があるほど若手は速く安全に伸びるし、チームの総生産性も上がる。

何が入っていればいいか

• 契約駆動: contracts/を起点にIFとDTOを固定（SRP/ISP/DIP）。
• 拡張ポイント設計: コアはClosed、機能はプラグインでOpen（OCP）。
• 例外処理の型: Protected Invoker＋ErrorReporter＋相関ID（空catch禁止）。
• 品質ゲート標準: lint/typecheck/test/coverageをnpmスクリプトでワンコマンド。
• テスト作法: ユースケース/シナリオ/回帰の優先度と雛形（Vitest+jsdom）。
• ドキュメント運用: ADR/Design/TestPlan/Runbookのテンプレと合意フロー。
• AIプロンプト指針: 「契約→実装→テスト→ドキュメント」順の定型プロンプト集。
• ロール定義: 若手は小さなプラグイン実装＋シナリオテスト作成から着手。

若手にとってのメリット

• 成功条件が明確（契約とゲート）で迷いが減る。
• 安全に挑戦（失敗はテストで即検知、相関IDで原因特定）。
• 学びが資産化（ADR/テストに蓄積→次の自分と他人が使える）。

すぐ効く次の一手

• docs/に「AI共創スターター（チェックリスト＋プロンプト索引）」を1枚追加。
• 既存のOCP/ゲートに沿った「小さなプラグイン課題」を若手オンボーディング用に用意。

短く言うと、設計で“AIの力を制御・再現可能にする”枠組みがあるほど、若手もチームも幸福度が上がる。

▲▲▲ 以下、Cursorの中のGPT(GPT-5)との会話です。▲▲▲

【参考】 黄色: 単利 / 青線: 複利のグラフの例

生成AIをナメてはいけない

「生成AIは設計を理解していない」――そんな声をよく耳にします。
しかし、前章で提示した対話が示すように、ソフトウェア設計原則を理解している生成AIも存在するのです。

「AIがダメ」ではなく「人間の引き出し方」の問題

もちろん、すべての生成AIが同じレベルではありません。

モデルの品質差もあるし、プロンプトの工夫次第で成果は大きく変わります。けれども「AIはちゃんとした設計をしてくれない」という不満の多くは、実は AIそのものの限界ではなく、人間側がその力を引き出せていないだけなのです。

AIに「適切な問い」を投げれば、SOLID原則や設計パターンを前提にした回答が返ってきます。

逆にあいまいな指示を出せば、場当たり的なコード断片しか返ってきません。つまり成果は、問いの質と人間側の設計リテラシーに直結しているのです。「生成AIだからヘンな設計ですみません」という言い訳ができない時代が、すぐに来るでしょう。

学びの方向性は「一方通行」ではない

重要なのは、AIとの関係は片道ではないということです。

「AIに任せきり」ではなく、AIの答えを理解し、評価し、再び問い直す人間側の学習が不可欠です。

AIが設計をわかっているからこそ、人間はそれを正しく聞き出す力と理解する力を磨く必要があります。

つまり、AIをナメるな。そして同時に、AIを理解できる人間になれということです。

次章につなぐ視点

では、今回の生成AIが理解している設計原則＝SOLIDは、具体的にどうやって「ROI」や「トークン消費」に効いてくるのか？

次章で、それを整理していきましょう。

ROIの観点から見るSOLID原則の再定義

ROI（投資対効果）という物差しをソフトウェア設計に当てはめると、SOLID原則は単なる「お作法」ではなく、直接的にコスト削減とリターン最大化に効いてくる戦略だと見えてきます。

広告費と同じく、生成AIの利用には 必ず課金という「投資」 が伴います。ならば私たちは、「そのコードはどのくらい再利用できるか？」「リファクタリングコストをどれくらい抑えられるか？」といった観点で 回収可能なリターン＝ROI を計算しなければなりません。

ここで鍵になるのがSOLIDです。

SRP（単一責任原則）

小さな責任に分割すれば、あるモジュールを改修するときに、AIに与えるコンテキストも局所化できます。
→ 説明や再生成にかかるトークン量が減少し、課金コストのROIが改善。

OCP（開放／閉鎖原則）

既存コードを閉じ、拡張だけを開く。
→ 「改修＝全体リライト・全体回帰テスト」という最悪のROI崩壊を防ぎ、差分開発で投資効率を維持。

LSP（リスコフ置換原則）

契約を守れば実装は自由に差し替え可能。
→ 再利用や切替が容易になり、過去の投資を捨てずに済む。これは広告の「ターゲティング最適化」と同じで、投資単位を小さくして無駄撃ちを減らす効果を持ちます。

ISP（インターフェース分離原則）

小さなインターフェースに依存する設計は、AIに与える指示範囲も最小化できる。
→ 不要なコード生成やトークン消費を削減し、ROIを最大化。
ISPを守らない設計は、まったくもって無駄・不要な実装を新規モジュールに強制する。

DIP（依存性逆転原則）

抽象に依存することで、AIが読むべき文脈を短く統一できる。
→ 実装ごとのノイズを削ぎ落とし、学習済みモデルに最適な形で指示できる。結果として、生成精度が高まりトークン往復も減少する。
例： 同じ漫画風広告バナーでメッセージだけ変更。A/Bテストすら可能に！

---

言い換えると、SOLIDとは「ROIを最適化するための設計投資基準」なのです。

• 守らない場合 → 一見早く見えても、後から修正コスト・AIトークン浪費・学習や再利用の機会損失が雪だるま式に増加。
• 守った場合 → 初期投資は大きくても、拡張・再利用・検証の段階で複利のリターンを生み出す。

まさに、マーケティング業界がキーワード広告で「広告費のROIを数値で把握」できるようになった瞬間と同じように、ソフトウェア開発も生成AIコーディングにより、「設計投資のROIを見える化」できる時代に入ったのです。

ここで重要なのは――SOLIDを軽視するか、ROI観点で再定義して武器にするか。

この分岐点が、AI時代の開発チームにとって生存戦略そのものになるでしょう。

使い捨てテンプレ量産と資産化フレームワークの比較

生成AIが普及した現在、最もよく目にするのは「テンプレ量産」アプローチです。
プロンプトを叩き込めば、すぐにそれらしいコードやUIが出てきます。試作品を瞬間的に見せるなら、このやり方は強力です。

しかしROIの観点で見たとき、このアプローチには決定的な欠陥があります。

使い捨てテンプレ量産の特徴

• 初速は速い: とりあえず形が出る。
• 短期ROIは高そうに見える: プロトタイプを「即日」で提示できる。
• しかし長期ROIは崩壊: 保守や改修の段階になると「使い捨てコード」を抱え直し、再生成や手直しのトークン課金が雪だるま式に増える。
• 組織学習が蓄積しない: コードが設計知を持たず、再利用できない。ノウハウは消耗品として消える。

これはマーケティングで言えば、刹那的なバナー広告を垂れ流すだけの戦略に近い。瞬間最大風速はあるが、ブランドも資産も残らず、広告費を燃やすだけになりがちです。

---

資産化フレームワークの特徴

対照的に、SOLID/OCPを軸にした資産化フレームワークは、ROIを「複利」で回す仕組みを持っています。

• 初期投資は重い: 抽象・契約・テスト・品質ゲートを揃える必要がある。
• だが以降のROIは加速する: プラグイン差し替えや拡張で、新規プロジェクトでも共通基盤をそのまま活用可能。
• トークン課金効率も改善: 再生成範囲が小さく、プロンプトも定型化されるため、AI利用料が逓減していく。
• 組織学習が残る: ADRや契約がドキュメントとして生き残り、若手もベテランも同じ「設計地図」で動ける。

これはマーケティングで言えば、SEO資産やブランドストーリーに投資して、広告費を超えて価値を回収し続ける戦略に近い。
最初は地味でも、複利が効いて中長期で圧倒的な差を生むのです。

---

ROIで整理すると

• テンプレ量産 = 「単利」。初速はあるが、消耗戦になりROIは逓減。
• 資産化フレームワーク = 「複利」。初速は遅いが、長期ではROIが逓増。

この比較から見えてくるのは――
「AI時代の真の勝者は、設計を資産化できるチーム」である という事実です。

次章では、この「資産化」を担う重要な役割――若手や学生がなぜ“検証”から始めるべきなのかを掘り下げていきます。

若手・学生が“検証”から始める意味

まずお伝えしたいのは、“検証＝雑用”ではないということです。
AI と一緒に開発する時代では、検証は 設計を安全に前へ進めるためのスタート地点。ここが整っていると、その後の実装も学びもスムーズになります。

---

用語リスト（やさしい解説）

本章で出てくる専門用語を、先にかんたんに説明します。

• スモークテスト
  家電で言えば「電源を入れて、煙が出ないか確かめる」くらいの軽いチェック。
  ソフトウェアでは「最低限の処理やテスト環境が正しく動くか」を確認する小さなテストです。

• ユースケーステスト
  ユーザーの行動をシナリオにして試すテスト。
  例：「商品をカートに入れて、クーポンを使って購入する」。

• 契約テスト（Contracts）
  「この入力なら、この形の出力を返す」という“取り決め”を守れているかを確かめるテスト。
  壊れると全体に影響が出るので、ビジネス契約のように大事です。

• 相関ID
  トラブルが起きたときに「この処理とこのログは同じ流れです」とひも付ける番号。
  配送の追跡番号のようなイメージです。

• Runbook（ランブック）
  障害時の「どう再現して、どう直すか」を短くまとめた手順メモ。
  分厚いマニュアルではなく、現場で役立つトラブルシュート用ノートです。

• MTTR（平均復旧時間）
  障害が起きてから復旧するまでの平均時間。
  短いほど「安心できるシステム」と言えます。

---

どうして実装より先に検証なの？

• 曖昧さをあぶり出せる
  先にテストや観測を置くと、「まだ決まっていない部分」が自然に見えてきます。

• AIへの指示が短く明確に
  小さくユースケースを切っておくと、AIに渡す文脈がコンパクトに。余計な書き直しが減ります。

• トラブル対応が楽になる
  例外やログに相関IDが入っていれば、原因をすぐ追跡できます。

• 学びが残る
  ADR・TestPlan・Runbook が揃えば、次の人が同じ問題で迷いません。

---

Minimum Viable Verification（最小限の“検証セット”）

立派な E2E（End-to-End Test：システム全体を端から端まで動かすテスト） から始める必要はありません。
まずは小さく、確実に。

1. 観測の土台

   • 例外は必ず記録（空 catch は避ける）
   • ログには requestId / useCase / latencyMs / result

2. スモークテスト

   • 成功パターン1本 + よくある失敗1本

3. 契約テスト（contracts/）

   • DTO/IF のスナップショットを固定し、壊れたら即検知

4. ワンコマンド検証

   • npm run verify → lint / 型チェック / 単体テスト / カバレッジ

5. 小さな Runbook

   • 「再現手順」「期待と実際」「ログID」だけ書けば十分

---

はじめの4週間の目安

Day 1～3

• contracts/ を軽く読んでスモークテストを2本
• ログ・例外を差し込み、相関IDが取れることを確認

Week 1

• 成功/失敗/境界の3パターンで短いシナリオテスト
• Runbookに再現手順を追加

Week 2

• 小さなプラグインを契約どおりに実装 or モック化
• 契約テストが壊れないか確認

Week 3

• npm run verify をCIに組み込み
• 失敗ログのトップ3を共有して改善

Week 4

• ログをもとに改善点を1つ選び、提案PRを出す

---

小さなチェックリスト

• テスト名が ビジネスの言葉で書かれている
• 1テスト＝1つの主張
• 例外は相関IDで追える
• 失敗時に「期待 vs 実際」が出力される
• contracts/ のスナップショットで破壊的変更を検知
• PRから Runbook に飛べる（3分で再現可能）

---

よくあるつまずき

• E2E だけで始める → 重くて壊れやすく、直しにくい
• ログがない → 何が起きたか分からず、復旧に時間がかかる
• テスト名が意図を語らない → 数週間後の自分が読めない
• Runbookがない → 直し方が人に伝わらない

AI共創フレームワークの要件

ここまでの流れを「個人のスキル頼み」にせず、チームで再現できる仕組みに落とし込むのがこの章の目的です。
ゴールはシンプル。「短い指示で安全に速く作れる」「壊れたら早く直せる」を、組織の標準として回すこと。

---

1) 目指す状態（Design Objectives）

• 短いコンテキストで成果が出る
  → SRP/ISP/DIP で粒度を揃え、AIへの指示が常にコンパクト。
• 拡張が怖くない
  → OCP 準拠。既存は閉じて、拡張はプラグインで開く。
• 失敗が管理可能
  → 相関ID・ログ規約・Runbook で MTTR を短縮。
• 学びが残る
  → ADR・TestPlan・設計ノートが“実行可能ドキュメント”として蓄積。
• 人とAIの役割が明確
  → 人は設計・品質ゲートのオーナー、AIは生成と差分の高速化担当。

---

2) リポジトリの標準構成（例）

/contracts # 抽象（IF/DTO/ポート）… まずここから読む/変更する  
/core # 変更を閉じたいコア領域（OCPの"Closed"側）  
/plugins # 機能拡張（OCPの"Open"側）: ui-_, rules-_, adapter-\*  
/tests # ユースケース/シナリオ/回帰のテスト群  
/docs  
├─ adr/ # 意思決定の記録（1 ADR = 1 Decision）  
├─ design/ # 設計ノート（図とトレードオフ簡潔に）  
├─ testplan/ # 失敗パターン/境界条件の一覧  
└─ runbook/ # 再現手順・対応メモ（相関IDの取り方を必ず記載）  
/scripts # `npm run verify` 等のラッパー

• ポイント：Pull Request は、基本「contracts/ → plugins/ → tests/ → docs/」の順で差分が読めるとレビューが速いです。

---

3) 品質ゲートを“ワンコマンド化”

ローカル = CI で同じ結果が出るように揃えます。

// package.json（例）
{
  "scripts": {
    "lint": "eslint .",
    "typecheck": "tsc -p tsconfig.json --noEmit",
    "unit": "vitest run",
    "coverage": "vitest run --coverage",
    "verify": "npm run lint && npm run typecheck && npm run unit && npm run coverage && npm run format:check",
    "format:check": "prettier -c ."
  }
}

• PR の必須チェックは verify 一発。落ちたらマージ不可に。

---

4) 観測とエラーの“型”

• 相関ID を生成・伝搬する小さなユーティリティを用意

  export const newCorrelationId = () => crypto.randomUUID();
  export type LogEvent = { reqId: string; useCase: string; result: "SUCCESS"|"FAIL"|"RETRY"; latencyMs?: number; extra?: unknown };
  

• 例外の包み方（Protected Invoker）

  • 外側で例外を捕まえ、reqId を必ずログに残す

  • 空 catch は禁止。Runbook への導線（エラーコード）を統一

---

5) プロンプト運用の標準（人⇄AIの約束）

プロンプトの型（共通テンプレ）

目的: <何を達成するか（1文）>
前提: contracts/<path> を変更しない。OCP/DIP/ISP を守る。
入力: <DTO> / 出力: <DTO> / 境界: <失敗パターン1~2個>
タスク: 差分パッチを作成。必要なら tests/ に GWT 形式の2本を追加。
検証: npm run verify が通ること。失敗時は reqId を含むログ例を出す。
ドキュメント: docs/runbook/<slug>.md の追記文を生成。

• 短い指示で済むのが正解。長文化しはじめたら、設計の粒度が粗いサイン。

---

6) 役割分担（RACI ライト版）

領域	Responsible(実装)	Accountable(承認)	Consulted(相談)	Informed(周知)
contracts/の変更	中堅/上級	テックリード	プロダクト/QA	全員
プラグイン追加	若手/中堅	モジュールオーナー	テックリード	全員
品質ゲート/CI	プラットフォームチーム	テックリード	全モジュール	全員
Runbook更新	担当者（誰でも）	モジュールオーナー	SRE/運用	全員

• 重要：契約（contracts）は “変更の稟議”。勝手に壊すと全てのROIが崩れます。

---

7) MVP → 標準化への導入ステップ

1. スリムなパイロット（2〜3週間）

   • 1ユースケース＋1プラグインで、contracts/ → plugin/ → tests/ → docs/ の流れを一周。

2. テンプレート化（+1週間）

   • できた流れをテンプレとして /scripts と /docs に反映。

3. 横展開と計測（継続）

   • 新規機能はテンプレ必須に。KPI を週次で可視化。

---

8) KPI（フレームワーク健全性）

• TTFS（Time To First Success）
  新機能の最初の緑（verify成功）までの時間。短いほど設計の粒度が良い。

• MTTR（平均復旧時間）
  障害発生→復旧まで。相関IDとRunbookで 30分以内 を目標に。

• Token per Change（1変更あたりのトークン）
  指示と再生成の総量。スプリントごとに逓減していればOK。

• Reuse Ratio（再利用率）
  既存プラグイン/契約の再利用 vs 新規作成の比率。再利用が増えるほど複利が効く。

---

9) アンチパターン（避けたい落とし穴）

• 「テンプレで殴る」プロンプト大全主義
  設計が粗いままテンプレ量産 → その場は速いが、長期ROIが沈む。

• E2E 先行主義
  重く壊れやすい。まずはユースケース/契約の粒度で赤点検出を。

• contracts/無許可改変
  影響範囲が見えないまま壊すと、組織の信頼と速度が同時に失われる。

• 観測なしの“成功/失敗”
  ログ基準とRunbookが無いと、復旧時間が読めず意思決定が遅れる。

---

10) すぐ使えるスターター（コピペOK）

Runbook 雛形

# RUNBOOK: <use-case> <issue-title>
- 目的: 何を直すか1文
- 再現: 手順/コマンド（3分でできること）
- 期待/実際: 期待値と観測ログ抜粋（reqId入り）
- 初動: ロールバック or フィーチャーフラグの操作
- 次アクション: テスト追加 / バグ修正PR / 利用者への周知

ADR 雛形

# ADR-<番号>: <意思決定のタイトル>
- 日付: YYYY-MM-DD
- 背景: 何が課題だったか
- 選択肢: A/B/C（簡潔にトレードオフ）
- 決定: 採用した案と理由
- 影響: contracts/tests/docs への反映

ユースケーステスト雛形（GWT）

describe("UseCase: <name>", () => {
  it("should <business-statement>", async () => {
    // Given
    const reqId = newCorrelationId();
    const input = <...>;

    // When
    const res = await useCase.handle(input, { reqId });

    // Then
    expect(res.ok).toBe(true);
    expect(getLog(reqId)).toMatchObject({ useCase: "<name>", result: "SUCCESS" });
  });
});

---

まとめ

AI 共創を“運任せ”にしないために、

• 契約を起点に設計する（contracts/）

• 拡張はプラグインで、既存は閉じる（OCP）

• 失敗は見える化して、すぐ直す（相関ID・Runbook・verify）

この3点を チームの標準 にできれば、短い指示で安全に速く進められます。

そして、そのスピードは時間とともに加速します（複利）。次章では、この視点をマーケティングの歴史に重ね、「ROI革命」から学べる教訓をまとめます。

マーケティング業界の歴史から学ぶ“ROI革命”の教訓

結論から言います。

「測れない投資は“信仰”。測れる投資が“戦略”。」

広告が“勘と根性”の時代から脱出できたのは、ROIを秒で測り、悪手を秒で捨てる文化を入れたから。開発も同じ。計測のないAI活用は、ただの“おまじない” でしかない。

---

教訓1：クリエイティブより先に“計測”を配線せよ

• 広告はコンバージョンタグを先に入れてからクリエイティブを回した。
• 開発も同様。npm run verify・相関ID・Runbookの配線が先。
  それなしでAIを回すのは、計器のないサーキットで全開にするのと同じ。

スローガン：「計測してないなら、やってないのと同じ」

---

教訓2：“一発の名作”より“高速A/B”が勝つ

• マーケは「天才コピー」神話を捨て、仮説→実験→差し替えで勝った。
• 開発もE2E一発芸をやめ、ユースケース粒度の赤点検出で差分を刻む。
  OCPでコアを閉じ、プラグインをA/Bせよ。

スローガン：「ひらめき ≦ 実験回数 × 学習率」

---

教訓3：“テンプレ量産”は広告費の垂れ流しと同じ

• 使い捨てLPやバナーを量産しても、資産は残らなかった。
• 同じく、プロンプトテンプレの連打は短期の風速だけ。
  contracts / plugins / tests / docs に落ちない生成は、
  **来月の自分が読み捨てる“過去の広告”**だ。

スローガン：「出すな、残せ。」

---

教訓4：“低予算の民主化”は、勝者を増やすのではなく“差”を広げる

• AdWordsが小規模事業者を武装させた結果、上手い運用は指数的に伸び、下手は一瞬で焼けた。
• AIも同じ。誰でも書ける時代は、設計・検証の差が 収益差 になる。
  AI運用（設計×計測×差分）の上手さが“広告運用力”に相当する。

スローガン：「AIは平等、運用は不平等。」

---

教訓5：ラストクリック神話を疑え（短期数値に溺れるな）

• 広告は「ラストクリック = 正義」を疑い、アトリビューションで全体最適へ進んだ。
• 開発も「目先のリリース速度」だけ見ると負債が雪だるま。
  TTFS（最初の緑までの時間）× MTTR × Token/Change × 再利用率で、
  “複利の設計”を可視化せよ。

スローガン：「速さは“点”でなく“曲線”で測る。」

---

教訓6：ガバナンスなき自動化は“暴走する入札”

• 自動入札も上限・制約・否定キーワードがなければ溶けた。
• AI生成も同じ。DIP/ISP/OCPが“否定キーワード”、
  verify/Runbookが“入札上限”。枠を決めない自動化はコスト地獄。

スローガン：「自動化の前に“境界条件”。」

---

教訓7：ブランドは“統一された約束”で育つ（= contracts）

• スタイルやトーンの一貫性がブランド価値を積み上げた。
• 開発では contracts/（IF/DTO） がそれ。
  ここが揺れると、毎回チャンネル名もロゴも違うCMになる。つまり崩壊。

スローガン：「約束を守るコードだけが、資産になる。」

---

反証にも先回りしておく

• 「でもテンプレ量産が速いでしょ？」
  → 短距離は速い。が、給水所なしのマラソンは途中で倒れる。
• 「完璧な計測が整うまで動けない」
  → NG。必要なのはMinimum Viable Verification。
  **“赤点が出る場所”**さえ分かれば走っていい。

---

まとめ：いま決めるべき、ただ1つのこと

“AI活用の最初の一歩は、生成ではなく配線（計測）である。”
広告のROI革命は、測る→回す→残すの3点セットで起きた。
開発も同じにしよう。
計測して、差分で回し、contractsに残す。
これをできないなら——CursorもCopilotも、ただの“高級電卓”だ。

まとめ

• 測れない開発は“信仰”、測れる開発が“戦略”。
• ROIで見ると、SOLID/OCPは「複利を生む設計投資」。
• 勝者は“プロンプト量産”ではなく、contracts / plugins / tests / docs に残すチーム。
• だから――まず配線（計測）、次に生成。 その順番で行こう。

読者プレゼント：この記事自体がテンプレです

この記事のマークダウンをそのまま ChatGPT にアップして、下のプロンプトを投げてください。

すると、フォルダ構成一式・.cursorules・検証スクリプト・最初にやるべきADR を生成＆zipでダウンロード可能な状態まで用意してもらえます（＝読者が即スタートできる）。

ってGPT君が言ってます(笑)

新しいチャットを開始して「このチャットでは、過去の会話履歴を参照せずに応答してください。」って入力してからのほうがいいかもしれません。

コピペ用プロンプト（ChatGPT宛）

💡補足：◆◆言語を1つ◆◆ を、読者の好み（TypeScript/Go/Python など）に差し替えてください。

あなたはAI×SOLIDを前提にした開発テンプレ職人です。添付ファイルを  
テンプレの仕様書として読み取り、次を作ってzipでダウンロードできるようにしてください。

[要件]

1.  言語は ◆◆言語を1つ◆◆。ビルド不要ならその旨READMEに明記。
    
2.  フォルダ構成（一式）  
    /contracts 抽象(インターフェース/DTO/ポート)  
    /core 変更を閉じる領域（OCP: Closed）  
    /plugins 機能拡張（OCP: Open）例: ui-_, rules-_, adapter-\*  
    /tests ユースケース/シナリオ/回帰（GWT推奨）  
    /docs/adr ADR-0001 初期アーキテクチャ（後述の観点を反映）  
    /docs/testplan 代表ユースケースと失敗パターン一覧  
    /docs/runbook 相関ID付きの最小ランブック  
    /scripts ワンコマンド検証用スクリプト  
    /ci verify専用のCI設定（例: GitHub Actions）
    
3.  `.cursorules`
    
    *   開発原則: SRP/OCP/ISP/DIP を破らない。`contracts/`は要稟議。
        
    *   生成手順: 「contracts→plugins→tests→docs」の順に差分化。
        
    *   守るべき規約: ログには reqId/useCase/result/latencyMs を含む。
        
    *   失敗時の出力: reqId入りのログ例＋Runbook更新文。
        
4.  `npm run verify` 等のワンコマンド検証（言語に合わせて）
    
    *   lint / 型チェック / 単体テスト / カバレッジ を一括実行
        
    *   ローカルとCIで同一結果
        
5.  最初に作るテスト（Minimum Viable Verification）
    
    *   スモーク: 成功1本＋代表的失敗1本
        
    *   契約テスト: DTO/IFのスナップショット固定
        
    *   シナリオ: 代表ユースケースをGWTで1本
        
    *   失敗時は reqId を含むログ例を出力
        
6.  生成物
    
    *   README: 使い方、原則、verifyの説明
        
    *   `.cursorules`
        
    *   テンプレのフォルダ/ファイル一式
        
    *   docs/adr/ADR-0001-initial-architecture.md（下記の観点を含む）
        
    *   zipファイルを作成し、ダウンロードリンクを提示
        

[ADR-0001に必ず含める観点]

*   目的・非目的、ドメインの境界
    
*   contractsの境界と変更ポリシー（要稟議）
    
*   OCP: coreを閉じ、pluginsで開く拡張点
    
*   エラー/観測の型（相関ID・ログ規約）
    
*   テスト優先度（スモーク→契約→シナリオ）
    
*   KPI: TTFS / MTTR / Token per Change / Reuse Ratio
    

[受け入れ基準]

*   `verify` がローカル/CIでグリーンになるサンプル込み
    
*   `contracts` を触らずに `plugins` を追加して1ユースケースが動くデモ
    
*   失敗時に reqId と Runbook 導線が出る
    
*   zipのダウンロードリンクを提示
    

最後に、Cursorへ最初に貼り付ける「初回プロンプト」も出力してください。

---

Cursorに最初に貼る“初回プロンプト”（生成してもらった中から抜き出して使う想定）

目的: 代表ユースケース <name> を plugins/ 配下に追加し、verifyをグリーンにする  
前提: contracts/<path> は変更しない（OCP/DIP/ISPを遵守）  
入力/出力: docs/testplan/<usecase>.md のDTOを参照  
境界: 失敗パターンを2つ（期限切れ/権限無し）必須  
タスク:

1.  plugins/<name>/ を作成し、必要なadapterを実装（差分パッチで）
    
2.  tests/ にGWT形式のシナリオテスト1本を追加
    
3.  失敗時のログ例（reqId入り）とRunbook追記文を生成  
    検証: `npm run verify` が通ること。通らない場合は差分を最小に再提案  
    ドキュメント: docs/runbook/<name>.md を更新
    

---

期待できるフォルダ断面（TypeScript例・抜粋）

/contracts/order/PlaceOrderPort.ts  
/core/order/PriceCalculator.ts  
/plugins/rules-coupon10/ApplyCoupon.ts  
/plugins/adapter-memory/OrderRepository.ts  
/tests/usecases/order.place.spec.ts  
/docs/adr/ADR-0001-initial-architecture.md  
/docs/runbook/order.place.md  
/docs/testplan/order.md  
/scripts/verify.ts  
/.cursorules

---

これで読者の皆様は、この記事＝仕様書としてChatGPTに投げるだけで、測れる配線→動く最小検証→拡張しやすい骨格まで一気に手に入ります。

“Cursorはまだ使うな”——まずは配線を作ってから、堂々と使おう。

あとはGPT君よろしく頼んだ！(*'▽')

おしまい