プロトタイプ：破棄可能なコードで設計上の疑問に答える

プロトタイプは「とりあえず書いてみる」ではない

/prototype の最初の定義は重要です。

プロトタイプは、質問に答えるために書かれた、破棄可能なコードです。

この一文は、プロトタイプと「手抜き実装」を切り離します。プロトタイプは本番コードの前身ではなく、後で正式版に修正していく途中段階のものでもありません。最初から破棄可能（throwaway）であるべきだと明記されています。

したがって、/prototype の鍵は速く書くことではなく、まず明確にすることです。

このプロトタイプは何を明らかにしたいのか？

2つのブランチ

Matt はプロトタイプを 2 つのタイプに分け、出力は全く異なります。

これは非常に実用的です。多くのチームが「プロトタイプを作ろう」と言いますが、インタラクションの外観を検証したいのか、ステートフローを検証したいのかを明確にしません。両者は全く異なるものを必要とします。

Logic prototype：ステートをターミナルに展開する

質問が「このステートマシンは正しいか」「このビジネスルールは実行可能か」である場合、プロトタイプは非常に小さなコマンドラインプログラムであるべきです。

その特徴：

• メモリ上で動作し、実際のデータベースに依存しない
• 1 つのコマンドで起動
• 各操作後に、関連する完全なステートを出力する
• 紙の上では推演しにくい分岐を網羅する
• テストは書かない、例外処理はしない、フレームワークに抽象化しない

例：サブスクリプションのステートフローを設計したい場合。

本番コードを直接変更しないでください。まず subscription-prototype.ts を書き、ユーザーがターミナルで以下を選択できるようにします。

1. start trial
2. pay
3. cancel
4. expire
5. refund
6. print state

各ステップで、現在のエンタイトルメント、トライアルクォータ、支払い済みステート、次の更新日などを表示します。これにより、一部のステートの組み合わせを全く考えていなかったことにすぐに気づくでしょう。

このタイプのプロトタイプの価値は、「抽象的なルールを実行可能なオブジェクトにする」ことです。

UI prototype：ルート内に複数の大胆なソリューションを配置する

質問が「インターフェースのデザインはどうあるべきか」である場合、プロトタイプは、同じソリューションを 3 回微調整するのではなく、十分に異なる複数の UI セットを生成すべきです。

/prototype の UI ブランチの要件：

• 1 つのルート内に複数のバリエーションを配置する
• URL の検索パラメータまたは下部のフローティング切り替えバーで切り替える
• ソリューション間には明確な違いを持たせる
• プロトタイプコードは将来の本番ページに近いものにするが、命名はプロトタイプであることを明確に示す
• 早すぎる段階で実際のデータや永続化に接続しない

これは通常の AI による UI 生成との違いです。「最適なソリューション」を一度に AI に求めるのではなく、実際のブラウザでいくつかの方向性を比較できるようにします。

例えば、ダッシュボードの空の状態について、AI に文言だけを変更させるのではなく、以下のようなものを作成させます。

• A：表形式、高密度、次の操作を強調
• B：タスク指向、左側にチェックリスト + 右側にプレビュー
• C：ガイド付き、主要な CTA と過去の例を強調

そして、チャットで 3 枚のスクリーンショットを見て想像するのではなく、同じルートで切り替えます。

すべてのプロトタイプは削除可能でなければならない

/prototype の一般的なルールの中で最も重要なのは「削除可能」であることです。

• ファイル名またはパスで、これがプロトタイプであることを示す
• デフォルトで本番データベースに接続しない
• 一般的な抽象化をしない
• 過度なエラー処理をしない
• 完了したら削除するか、学んだ結論を正式なコードに吸収する

もしプロトタイプが削除できない場合、それはすでに本番コードの負債になっています。

これは AI プログラミングにおいて特に重要です。AI はプロトタイプを「動作するように見える」ように書くのが得意ですが、人間は削除するのを怠り、最終的に誰も触りたがらない一時的なコードの山がプロジェクトにできてしまいます。

プロトタイプ完了後に残すべきもの

プロトタイプコード自体は保存する価値はありませんが、その答えは保存する価値があります。

Matt は以下のことを永続的な場所に書き留めることを推奨しています。

• プロトタイプが明らかにしようとした質問
• 観察された結論
• 選択した方向性
• 却下した方向性
• 必要であれば、ADR、issue、PRD、またはコミットメッセージに変換する

つまり、/prototype の成果物はコードではなく、意思決定です。

使用すべきでない場合

/prototype を使用すべきでないシナリオ：

• 要件が明確で、実装のみが必要な場合
• バグが再現可能で、/diagnose を使用すべき場合
• リファクタリングの方向性が明確で、/tdd で保護して実施すべき場合
• UI の微調整のみで、複数のソリューションを作る価値がない場合
• 削除または吸収する時間が取れない場合

プロトタイプのコストは書くことではなく、後処理にあります。後処理がなければ、始めないでください。

便利なプロンプト

以下のように呼び出すことができます。

/prototype

このチェックアウトのステートマシンが妥当かどうか検証したいです。logic ブランチでお願いします。
破棄可能なターミナルプロトタイプのみを作成し、実際の DB には接続しないでください。
各操作後に完全なステートを出力してください。

または：

/prototype

プロジェクト詳細ページの 3 つの情報アーキテクチャを比較したいです。UI ブランチでお願いします。
既存のルート体系内の prototype ルートに配置し、下部に切り替えバーを提供してください。
本番コンポーネントは変更しないでください。

ここで最も重要なのは、「明らかにしたい質問」を明確にすることです。この質問が明確であれば、プロトタイプが迷走することは少なくなります。

Grill Me との関係

/grill-me は質問を通じて意思決定を収束させるのに適しており、/prototype は試用を通じて意思決定を収束させるのに適しています。

質問で解決できる問題もあります（例：「匿名コメントは承認が必要か」）。触ってみないとわからない問題もあります（例：「このドラッグ＆ドロップ並べ替えステートマシンは使いにくいのではないか」）。後者はプロトタイプを使うべきです。

そのため、ワークフローの分岐点に配置します。

アイデアが曖昧
  ↓
/grill-me
  ↓
それでも体験や検証が必要な場合
  ↓
/prototype
  ↓
結論を保持し、プロトタイプを削除
  ↓
/to-prd または /tdd

参考資料

次の記事：Improve Codebase Architecture：shallow を deep modules にリファクタリングする。