🤖 AI運用ルール
Claude_開発依頼書テンプレート
最終更新 2026年05月01日 ／ 22_AI運用ルール/Claude_開発依頼書テンプレート.md
Claude 開発依頼書 標準テンプレート
大串が「このクオリティを標準にしたい」と認定したフォーマット（2026-04-28認定）
新規システム・機能開発を Claude（または別セッション）に依頼するときに使う標準テンプレ。
これに沿って書けば、前提共有不要で、依頼文を渡すだけで Claude が動ける。
依頼を出す前に必読
依頼書を書く前に、必ず 31_システム開発部/_AI開発依頼の原則 を読む。
6原則：① 初期依頼の質 / ② 超具体的指示 / ③ まとめて修正 / ④ 動作チェック必須 / ⑤ 設計想定 / ⑥ 選択肢比較
開発時間の 80% は最初の依頼で決まる。
なぜこの形式が標準か
- 依存関係が一発でわかる（読むべき書類リスト）
- 環境情報が完備（パス・URL・DB・スタック）
- ゴールが明確（ユーザー目線の目的＋評価軸）
- 守るべき制約が明文化（退化禁止・命名・コミット・デプロイルール）
- 実装順序が Phased（Phase 1 から動ける）
- 完了報告フローまで内蔵（Slack報告先・スクリプトパス）
→ Claude は「何から読めばいい？」「どこにデプロイ？」を聞き返さずに着手できる。
テンプレ全文（コピペ用）
[システム名]（[新規 or 既存改修]・[1行説明]）の開発を進めます。
【依頼書】
[依頼書のフルパス（Vault内）]
【新規リポジトリ作成パス（推奨）】
[/Users/oogushiyuuki/株式会社SCALE/プロジェクト名/]
【公開URL（予定）】
[https://xxx.pages.dev/]
（独自ドメイン: [候補ドメイン] 検討中）
【データベース】
[Supabase / Cloudflare KV / D1 / 不要]
- [テーブル名] [用途]
【作業前に読むべきもの】
1. この依頼書全文
2. [関連依頼書1]
3. [関連依頼書2]
4. CLAUDE.md (~/Obsidian/SCALE-Brain/CLAUDE.md)
5. [関連ナレッジ・競合分析など]
【ゴール】
[1〜3行で「誰の・何の問題を・どう解決するか」]
[品質基準があれば併記]
【評価軸／機能リスト】
[カテゴリ別 or 機能別に明示。点数制があれば点数も]
1. ...
2. ...
【超厳しい/譲れないポイント】
[ある場合は具体的に。プロンプト全文や評価基準まで含めてOK]
【守るべきこと】
- [品質基準を妥協しない]
- [既存システム（具体名）と API 連携]
- [スタック指定: Cloudflare Workers + Pages Functions など]
- [コスト/パフォーマンス制約]
- 編集前に git commit、変更後は npm run build && npx wrangler pages deploy
- 関数を消さない・退化禁止（実装ルール準拠）
【実装順序】
依頼書「N. 実装順序」に従って Phase 1 から進める:
- Phase 1（X営業日・最小動作）: [機能ID列挙]
- Phase 2（追加X営業日）: [機能ID列挙]
- Phase 3（追加X営業日）: [機能ID列挙]
完了したら、依頼書の「N. 完了状況」をチェックし、Slackで報告してください。
slack_post.sh は /Users/oogushiyuuki/株式会社SCALE/scale-company/slack_post.sh にあります。
（司令名義: ./slack_post.sh shirei "メッセージ"）
依頼書本体（リンク先MD）の必須セクション
依頼文だけでなく、参照先のMD依頼書本体にも以下のセクションを揃える：
| # | セクション | 内容 |
|---|---|---|
| 1 | 概要 | プロジェクト名・目的・1行サマリ |
| 2 | スコープ | 含む機能 / 含まない機能 |
| 3 | アーキテクチャ | スタック・依存関係・データフロー図 |
| 4 | データベース設計 | 全テーブルのカラム定義・インデックス |
| 5 | API仕様 | 全エンドポイント・I/O・認証 |
| 6 | UI/画面設計 | 全画面のワイヤー・遷移図 |
| 7 | 実装順序 | Phase 1〜3 ごとの機能ID列挙 |
| 8 | 機能一覧（IDマップ） | A1, A2, B1... の機能リスト |
| 9 | 評価基準 / 受け入れ条件 | 「動いた」と言える定量条件 |
| 10 | 完了状況 | チェックリスト（Phase別） |
| 11 | 特殊要件・プロンプト等 | 必要なら全文掲載 |
ハマりがちなNG例
| NG | 原因 | 直す |
|---|---|---|
| 「いい感じに作って」 | スコープ・評価軸不在 | ゴール・評価軸を書く |
| 「過去の実装参考に」+ パスなし | 依存先不明 | 全パスを明記 |
| 「終わったら教えて」だけ | 報告経路不明 | Slack投稿コマンド明示 |
| 「APIで連携」 | 連携先のURL/認証不明 | 連携相手のシステム名・URL・認証方式まで書く |
| Phase分けなし | 一気に作って事故 | 必ず最小動作 Phase 1 を切る |
良い実例
- TERASU Lens 開発依頼:
40_新規事業/TERASU/TERASU_Lens_開発依頼書.md - 全11セクション完備・評価10カテゴリ × 各100点・3視点プロンプト全文掲載・Phase 1〜3 明示
運用ルール
- このテンプレに従わない依頼が来たら、Claude側から「テンプレに沿って書き直すと精度上がります」と提案してOK
- 「【】見出し + 箇条書き」の構造を必ず維持（パース性のため）
- 既存システム改修の場合は
31_システム開発部/_SCALE_全システム配置マップ.mdのリンク を必ず読むべきものに含める - 退化リスクのある改修は
_SCALE_全システム実装ルール.mdも必読リストに入れる
最終更新: 2026-04-28