Claude Codeに渡す構築プロンプトの書き方 〜機能一覧より先に「作らないもの・厳守ルール・未決事項・受け入れ基準」を書く〜

はじめに

日本株のAI銘柄スクリーニング＆継続学習端末「ALPHA FORGE（アルファフォージ）」を個人で開発・運用しています。開発には Claude Code を使っています。

第1話では、Markdown 1枚の構築プロンプトから約25時間・27コミットで一通り動くシステムが立ち上がった話を書きました。その間、私の入力はほとんど「次」「続行」でした。

今回は、その構築プロンプトの中身と構成の考え方をまとめます。AIエージェントに大きめのプロジェクトを最初から任せるときの、指示書の書き方の一例です。

【要約】

• 機能一覧より先に、次の4つを書く
  • Out of Scope（明示的に作らないもの）
  • 厳守ルール（ドメイン固有の決まりごと、設計の芯になる制約）
  • 未決事項（「計画時に人間へ確認」「決まるまではスタブで進める」と添える）
  • 受け入れ基準（Definition of Done、フェーズごとの完了条件）
• 作業の進め方（調査 → 計画 → TDD → レビュー → 検証 → コミット）と、人間の確認が必要な操作も明記する
• プロンプトは使い捨てにせず、運用で得た知見を追記して次の開発の原本にする

※本記事はnote連載［ALPHA FORGE 開発秘話 #03］ の技術的な部分を、エンジニア向けに再構成したものです。

1. 構築プロンプトの章立て

実際のプロンプト（約330行のMarkdown）の構成です。

章	内容	ねらい
0	エレベーターピッチ	何を作るかを一言で固定する
1	スコープ（In / Out of Scope）	作らないものを明示する
2	継続学習ループ（最優先で設計）	優先度をはっきりさせる
3〜8	可視化、データソース、アーキテクチャ、スコアリング、通知、UI	機能要件
9	ドメインルール（厳守）	破ってはいけないルール
10	非機能要件	テスト、セキュリティ、CI、Git運用
11	決定事項と残る未決事項	AIに勝手に決めさせない
12	運用フェーズで得た知見	後から追記して育てる
13	開発フェーズ計画	各フェーズに完了条件を付ける
14	受け入れ基準	「完成」の判定を固定する
15	作業指示	進め方と、人間の確認が必要な操作

冒頭には使い方として、「最初に調査 → 計画提示 → フェーズ分割を行い、plans/ に計画ドキュメント一式を生成してから実装に入ること」と書いています。実際、最初のコミットは計画ドキュメント（PRD／アーキテクチャ／システム設計／タスクリスト）でした。

2. Out of Scope：作らないものを明示する

AIエージェントは、頼まれていない機能まで気を利かせて作りがちです。先に線を引いておきます。

構築プロンプト §1（抜粋）

### Out of Scope（明示的に作らない）
- ブローカーへの実発注は一切行わない。アプリは提案と通知のみ。約定は人間が別途手動で行う。
- 米国株・暗号資産・FX・先物。
- 投資助言業に該当する「個別断定的な投資勧誘」。出力は必ず「分析結果・参考情報」として提示し、免責を UI に常設。
- 資金移動・入出金・自動売買・自動ポジション管理。

既存資産があるなら、「書き直さない」ことも明記します。

構築プロンプト 冒頭（要旨）

既存プロジェクト（前身ツール）は再利用元。ドメインロジック・データ取得層・スコアリングは
移植を第一選択とし、ゼロから書き直さない。

AIはゼロから書き直すのが速くて得意です。明記しないと、動いている部品まで作り直す方向に進みがちです。

3. 厳守ルール：ドメイン固有の決まりごとと設計の芯

一般的なひな形のままだと間違えるルールは、見出しに「（厳守）」と付けて独立した章にしました。

構築プロンプト §9（抜粋）

## 9. 日本株ドメインルール（厳守）
- 時刻はすべて JST。東証大引け 15:00。
- 銘柄コードは 4 桁（例 7203）。.T サフィックスを付けない。
- 騰落色 赤 = 上げ / 緑 = 下げ。

設計の芯になる制約も、検証方法まで含めて書きます。

制約	書き方のポイント
売買銘柄の提案には推奨買値／損切値／推奨売値の3値を必須	損切 < 現在値 < 売値 かつ 損切 < 買値 < 売値 をサーバ側で検証、と検証場所まで指定
外部由来テキストをLLMプロンプトへ注入しない	注入してよいのは構造化フィールドのみ、と許可側を明示
モデルの入れ替えは提案のみ	差し替えは人間の承認APIでのみ、と承認経路を指定
ブローカー発注をしない	Out of Scope と受け入れ基準の両方に書く

これらのルールは、後に Claude Code が毎セッション最初に読む CLAUDE.md にも移しています。構築プロンプトは初回の指示書、CLAUDE.md は常設のルールブック、という分担です。

4. 未決事項：AIに勝手に決めさせない

決めきれていないことは、正直に「未決」と書きました。

構築プロンプト §11（要旨）

### 残る未決事項（P0 の計画時にユーザーへ確認）
1. ペーパートレード期間 — 昇格ゲートに必要な最小日数（暫定 20 営業日で提案）
2. 移植 vs 新規 — どのモジュールを移植し、どこから新規設計とするか
3. Web Push の対象ブラウザ / PWA 化の要否
4. LLM プロバイダ / モデル構成、コスト上限

そして、扱い方を作業指示に書きます。

構築プロンプト §15（抜粋）

1. まず P0 を実行し、plans/ に計画ドキュメントを生成、§11 の未決事項をまとめてユーザーに確認する。
   未決事項が残る項目は feature flag OFF のスタブで進める。

結果として、計画フェーズで Claude Code からまとめて質問が来ました。回答は決定ログ（plans/05_決定ログと未決事項.md）に残しています。

未決事項	回答
ペーパー成績の最小日数	20営業日（暫定案どおり）。env で設定
Web Push / PWA	デスクトップ常駐のみ。Service Worker + VAPID だけ実装し、PWA化はしない
LLM構成・コスト上限	前身ツールと同一構成を踏襲

「未決」と書かれていない項目は、AIが妥当な仮定を置いて進めます。仮定が外れると、気づいて直すのは人間です。決めていないことを書いておくと、AIは決める前に聞いてくれます。また「決まるまではフラグOFFのスタブ」と決めておくと、確認待ちで全体が止まりません。

5. 受け入れ基準：「完成」の判定を固定する

Definition of Done は13項目のチェックリストにしました（抜粋）。

構築プロンプト §14（抜粋）

- [ ] 中長期・短期それぞれのピックが、根拠 + 確度 + 推奨買値 / 損切値 / 推奨売値 付きで生成される。
- [ ] `損切 < 現在値 < 売値` かつ `損切 < 買値 < 売値` がサーバ側で強制されている。
- [ ] すべての予測が台帳化され、決着後に評価指標が自動更新される。
- [ ] 再学習が定期 + ドリフトで発火し、challenger が shadow で並走、昇格は提案のみ。
- [ ] アプリはブローカー発注を一切行わない。
- [ ] backend / frontend の CI がローカルで全通し。テストカバレッジ 80% 以上。

フェーズ計画にも完了条件の列を付けています（抜粋）。

Phase	内容	完了条件
P0 調査 & 計画	再利用モジュールの棚卸し、計画ドキュメント生成、未決事項の確認	計画ドキュメント承認
P1 基盤	雛形、起動、CI、デザイントークン	next build / pytest 通過、ローカル起動確認
P3 スコアリング & ピック	4分析、3値算出 + サーバ側検証、ピックAPI	ピック生成 E2E、3値整合性テスト
P8 仕上げ	モデルラボUI、a11y、性能、ドキュメント	全 CI 通過、受け入れ基準充足

各フェーズの完了時にはコミットとローカルCI全通しを求めました。人間の「次」「続行」は、この基準に照らして次のフェーズへ進めてよいかを判断していただけです。

6. 作業指示：進め方と、止める場所

最後の章には、進め方と人間の確認が必要な操作を書きました。

構築プロンプト §15（抜粋）

2. 各フェーズは 調査 → 計画 → TDD 実装 → コードレビュー → 検証 → コミット & プッシュ の順。溜めない。
3. 新規実装の前に必ず前身ツールの該当モジュールを確認し、移植で足りるか判断。ゼロから書かない。
4. 可逆なリポジトリ内作業（コード編集・テスト・lint・ローカル検証・調査）は確認なしで自走。
5. コミット / push / PR / 外部送信 / 不可逆操作 / 認証情報入力 / 設定の恒常変更は確認または明示指示を必要とする。
6. セキュリティ上の懸念を見つけたら即停止して報告。

AIに任せる範囲（可逆な作業）と、人間が止める場所（不可逆・外部に出る操作）を最初に分けておくことで、「自走してほしいが、勝手に外へは出てほしくない」を両立しています。

7. プロンプトを育てる

構築プロンプトは使い捨てにしていません。運用で得た知見を §12 として後から追記しています。

• マルチLLMプロバイダの動的選択とシャドウ並走
• Point-in-Time（予測時点で確定していた情報のみ）のスナップショット保存
• note下書きの自動生成フロー
• 日次パイプラインログの自動集約
• 学習の並列化（ProcessPoolExecutor）
• celery-beat を安全に自動起動するための冪等ガード（休場日スキップ・当日生成済みスキップ）

2026-09-22 には、別に作っていた類似の構築プロンプト集をこの1ファイルに統合し、旧ファイルは削除しました。同種のシステムを次に作るときの原本にするためです。

8. 役割分担（Human in the Loop）

担当	やったこと
人間	作らないもの・厳守ルール・受け入れ基準を書く。未決事項を「未決」と書く。質問に答えて方針を決める
AI（Claude Code）	未決事項を質問として返す。計画ドキュメントに落とし込む。フェーズごとに実装・テスト・ローカルCIを通してコミット

まとめ

• 機能一覧より先に「作らないもの」「厳守ルール」「未決事項」「受け入れ基準」を書く
• 制約は「何をするか」だけでなく「どこで検証するか」「誰が承認するか」まで書く
• 未決事項には「計画時に確認」「決まるまではスタブ」と扱いを添える
• 任せる範囲と止める場所を作業指示に書く
• 運用の知見を追記して、プロンプトを次の開発の原本に育てる

次回は事件簿に戻り、ピック生成が23分半かかって寄り付きに間に合わなかった件の原因と対処を書きます。

☕ note.comで開発秘話とデイリーAIピックを連載中

note.comでは、ALPHA FORGE の開発秘話と、毎朝のAIピックの思考トレースを公開しています。

👉 元記事（note連載第3話）:
【ALPHA FORGE 開発秘話 #03】「作って」ではなく「約束」を書く ― 構築プロンプトの設計図

---

免責事項
本記事は個人開発およびAIエージェントを活用したシステム開発の技術記録です。特定の銘柄の売買推奨や投資助言を行うものではありません。本ツールは証券会社等への発注機能を持ちません。記事中のプロンプトは要旨・抜粋であり、パスや環境固有の値は省略しています。