💻 システム開発
AI開発依頼の原則
最終更新 2026年05月03日 ／ 31_システム開発部/_AI開発依頼の原則.md
AI開発依頼の原則（大串の現場経験則）
「依頼の質 = 開発スピードの上限」
46+システムを内製してきた現場で得た、AI開発を効率化する 6 原則。
新規開発を始める前に必ずこのノートを読み返す。
30秒で全体像
| 観点 | 一言 |
|---|---|
| 核心 | AI開発（Claude Code 等）で時間を浪費しないための、依頼者側の6原則 |
| キーワード | 初期依頼の質 / 具体性 / まとめて指示 / 動作チェック / 設計想定 / 選択肢比較 |
| 使う人 | 大串（依頼者）/ Claude（受け手の文脈把握用） |
| 読了目安 | 3分 |
6 原則
01. 初期の依頼を適当にしない
ここで時間削減のほとんどが決まる。
- 開発時間の 80% は 最初の依頼内容で決まる
- 適当な依頼 → AIが推測 → ズレた実装 → 修正ループ → 時間倍増
- 依頼を10分多く考えれば、開発時間が3時間減る
- 「とりあえず作って」は最も高くつく
チェック：
- [ ] 何を作るか・何のためにかが1行で言えるか
- [ ] 完成したら「動いた」と言える定義は明確か
- [ ] スタック・配置場所・既存システムとの関係は明示したか
02. 超具体的な指示は必須
抽象度が高い = 自由度が高い ＝ ズレるリスクが大きい。
- 「いい感じに」「適切に」「うまく」は禁止用語
- 「ボタンの色は #ff6b2b」「フォントサイズは clamp(1.6rem, 3vw, 2.2rem)」レベルまで具体的に
- 数字・固有名詞・色コード・サイズ・スタックを徹底的に書く
- 例外は「比較してほしい」ときのみ（→ 原則 06）
良い例：
×: 「カードを並べてください」
○: 「カードを 2x2 グリッドで配置。各カードは padding 24px、
border-radius 12px、背景 var(--surface)、ホバーで
border-color: var(--orange) に変化」
03. まとめて修正依頼を出す（並列化）
1つずつだと時間が線形に伸びる。まとめると並列処理される。
- 「ここ直して」→ 修正 → 「次ここ」→ 修正 → ... は最悪パターン
- 修正点を5個まとめて出す → AIが1ターンで全部対応
- 関連ない修正でも、まとめた方が早い
- ただし不可逆操作（削除・デプロイ）が混じる場合は分ける
理想フロー：
1ラウンド目：見直し時間を取って修正点を5-10個リストアップ
2ラウンド目：まとめて指示
3ラウンド目：再度見直し → 残った修正点をまとめて指示
04. 最終チェック・動作チェックは必須
「実装した」と「動いた」は別物。
- AI が「完了しました」と言っても 必ず自分で動作確認
- ローカル開発サーバ起動 → 全機能を手で触る
- デプロイ後も本番URLで触る
- 「型チェックOK」「ビルドOK」だけでは不十分。実際の挙動を確認
チェック観点：
- [ ] 主要なユーザーフローが全部動くか
- [ ] エラー時の挙動はどうか
- [ ] モバイル表示は崩れていないか
- [ ] 既存機能を壊していないか（退化検知）
04b. 1依頼1完成1デプロイ1バックアップ（容量オーバー対策・2026-05-03 追加）
複数依頼でも 1つずつ完結させて常に保存。セッション容量オーバーで消える事故を防ぐ。
5ステップ完結（1依頼ごと）
1. 実装 → 2. ビルドOK → 3. デプロイ → 4. tar.gz バックアップ → 5. commit
→ 5全部やってから次の依頼に進む。途中で次の依頼に走るのは禁止。
NGパターン
- 全部実装→まとめてデプロイ → 容量オーバーで全消失
- バックアップ後回し → デプロイ失敗で復元不可
- changelog 後でまとめて → セッション切れて消失
大串から「復元して」と言われたら
- 確認なし・即実行
- 最新バックアップから tar -xzf → rsync → ビルド → デプロイ
05. 丸投げせず、最初の設計を想定して依頼する
頭を使うコストを払うほど、AIの暴走を抑えられる。
- 「どう作ろうか」を 依頼前に自分で5分考える
- ファイル構成・データ構造・画面遷移を仮置きする
- 既存のどれを流用するかを思い浮かべる
- これを依頼に 「想定としては〜」 と書き込む
目的：
- AIが筋違いの設計に走るのを防ぐ
- 既存パターンとの整合を取る
- 後から「やっぱりこの構造変えて」を減らす
06. 常により良い形を検討し、AIにもアイデアを出させて意思決定する
「選択肢が複数あるものから常に良いものを選ぶ」感覚を持つ。
- 一発で「これ作って」ではなく、「3案出して比較」を挟む
- AI が出す案を取捨選択するのが 依頼者の本質的な仕事
- 良い形が見つかったら、それを基準に既存も再評価する
- 妥協しない。「Make It Well = 業界 No.1 の品質」
実践テンプレ：
「◯◯を作りたい。Aパターン / Bパターン / Cパターン
を提案して、メリデメ比較してから推奨を出して」
6原則の要約マトリクス
| # | 原則 | 効果 | 使うフェーズ |
|---|---|---|---|
| 01 | 初期依頼の質 | 開発時間 大幅削減 | プロジェクト開始時 |
| 02 | 超具体的指示 | ズレ防止 | 全工程 |
| 03 | 修正まとめ依頼 | ターン数削減 | 修正期 |
| 04 | 動作チェック必須 | 退化・バグ防止 | デプロイ前後 |
| 05 | 設計想定して依頼 | 設計暴走防止 | 依頼書作成時 |
| 06 | 選択肢比較で意思決定 | 質の最大化 | 重要判断時 |
アンチパターン（やってはいけない）
| アンチパターン | 損失 |
|---|---|
| 「いい感じに作って」 | AI推測 → ズレ → 修正ループ |
| 1つずつ修正依頼 | ターン数倍増・キャッシュ切れ |
| ビルドOKだけで完了報告 | 本番でバグ発覚 → 信頼失墜 |
| 「とりあえず動かして」 | 設計負債が後々爆発 |
| 案を1つしか考えない | 業界 No.1 の品質に届かない |
関連ノート
- 31_システム開発部/_SCALE_全システム実装ルール — 退化禁止フロー（実装中の絶対ルール）
- 31_システム開発部/_SCALE_全システム配置マップ — パス・スタック早見表
- 31_システム開発部/_SCALE_全プロダクト一覧 — 内製46+の実績
- 22_AI運用ルール/Claude_開発依頼書テンプレート — 依頼書フォーマット
- 22_AI運用ルール/Claude_動き方ガイド — Claude側の動き方
使い方
- 新規システム開発を始める前に必ず読む
- 開発依頼書を起こすときに 6 原則をチェック
- 修正依頼が増えてきたら 03 の「まとめて」を意識
- デプロイ前に 04 の動作チェックを必ず実行
- 重要判断のたびに 06 の「選択肢比較」を挟む
更新履歴
| 日付 | 内容 |
|---|---|
| 2026-05-01 | 初版作成（大串の現場経験則 6 原則） |