AI開発
AIと開発を始めるときの入口—読む順・ゲート・初手の依頼
エージェントと小さく始めるときの最初の時間の使い方。文書の読む順、実装前ゲート、依頼の型、やりがちな誤解。
AIエージェントとWeb/SaaSを小さく始めるとき、最初に詰まりやすいのは「何から読ませて、どこまで人間が止めるか」です。全部を一度に読ませたり、ゲートなしで「全部やって」と出すと、モックや仮実装のまま走り、設計の穴がコードに固定されます。読み終わると、読む順・実装前ゲート・初手の四点依頼で「始められたか」を判定でき、画面に出ないときの切り分けも入口の延長で切れます。文書体系そのものは 小さく始めるAIネイティブ開発 に任せ、ここでは 入口の手順 に絞ります。
この記事でわかること
- 最初の30〜60分で読む順を決め、コンテキストを溶かさないで進められる
- 実装前ゲートを越えるまで本実装に入らないと判定できる
- 初手の依頼に参照・対象・やらないこと・完了条件を揃えられる
- 画面に出ない/スタブ誤解などの入口あとの取り違えを避けられる
- 作業前にAIへ渡す入力(貼り付け文)がある
先に結論
コードを書かせる前に、次を揃えます。
1.実装リポ内に、要件・設計・非機能・テスト観点が辿れる 2.「やってはいけないこと」が文章になっている 3.人間が設計を一度見た、とゲートが書かれている 4.最初の依頼はモジュール単位で、参照・やらないこと・完了条件がある
ここまでできていれば合格です。文書が無い/ゲートが無い/依頼が「全部やって」だけ、は不合格です。
失敗1:全部を一度に読ませる
状況: 入口なしで設計一式をエージェントに渡し、コンテキストが溶ける。
悪い例: 「docs全部読んで全部やって」。番号も範囲もない。
良い例: 目安の順で読む。 (1) 文書の入り口 (2) いま作る範囲(MVP)と設計の一枚メモ (3) 番号の若い設計(データ・画面・認可など中核) (4) 横断の非機能 (5) AIとの進め方 (6) 動くモックがあれば一度触る。
合格条件: 番号付きの小さいMarkdownに分かれ、いまの範囲だけが先に読まれている。
失敗2:実装前ゲートを「だいたい良い」で飛ばす
状況: 設計確認前にコードへ入る。秘密や本番操作の止めがない。
悪い例: ゲートなしで「全部やって」。穴は後で直す、と言いながら本実装が進む。
良い例: 次を文章かチェックリストにしておく。「だいたい良い」で通過してよく、穴は設計を直してからコードです。
- 設計を人間が一度確認した
- 最初の成果物がTODOになっている(何を先に足すか)
- 関連するテスト観点を意識している
- 秘密はチャットやGitに置かない
- 削除・デプロイ・本番相当の書き込みは都度確認する
合格条件: 上記ゲートを越えるまで本実装に入らない。ゲートなしの「全部やって」は不合格。
失敗3:初手が長く曖昧な一文
状況: 参照・範囲・禁止・完了条件が無い依頼で走る。
悪い例: 「いい感じにログイン周りやって」。プロンプトだけ連打して直す。
良い例: 四点が揃っている依頼にする。
参照: (読む設計ファイル)
対象: (今回触る範囲だけ)
やらない: (実キー投入、デプロイ、関係ない機能)
完了条件: (サーバ側で何が止まっていればよいか)
直すときは、設計かルールか指摘メモを更新してから再実行します。是正をチャットに残したままにしない話は AIエージェントのよかれが事故になるとき も参照してください。
合格条件: 初手に参照・対象・やらないこと・完了条件がある。不足なら質問だけで、コードはまだ書かない。
失敗4:入口を越えたあとの取り違え
状況: 画面に出ない・スタブ・権限混在を、入口の失敗と混ぜて長引かせる。
悪い例: 未接続スタブの固定文言を本番障害だと決めつける。管理者と一般のナビを設計に書かず混ぜる。
良い例:
| 起きること | 先に疑うこと |
|---|---|
| 画面に出ない | デプロイやビルドが終わっているか(画面に出ないときはデプロイを疑う) |
| 「障害っぽい」固定文言 | 未接続スタブなら、意図的スタブだと一行で書く |
| 管理者と一般の画面が混ざる | ナビの分け方か、別アカウントかを設計に書く |
| 決済不要なロールが課金導線に入る | メニュー無効化と、URL直打ちの拒否をセットにする |
| 秘密の置き場の説明が誤解される | 「チャットやGitに出さない保管」が芯。特定アプリ名必須ではない |
合格条件: 画面に出ないときデプロイ完了を先に疑う。スタブと本番未接続を、利用者が誤解しにくい文言にしている。
まだ弱くてよいこと
最初から全部揃える必要はありません。次は後回しでも、入口は進められます。
- プロンプト集を大量に用意すること
- E2Eの型を最初から固めること
- モックが別置きのままであること(パスでつながっていればよい)
痛い事故が起きたところから、ルールと設計を厚くします。
作業前にAIへ渡す入力
人間向けの長い手順は書きません。次はすべて、作業前に AIに読ませる/貼る文 です。
AI向け:永続ルール(rules / AGENTS.md)
最初の依頼には必ず次を含めさせる/自分から復唱する: 参照・対象・やらないこと・完了条件。
実装前ゲート(設計確認・秘密を出さない・削除/デプロイ確認制)を越えるまで本実装に入るな。
是正はプロンプト連打ではなく、設計か rules を更新してから再実行する。
AI向け:この作業の開始時にチャットへ貼る文
これから始める作業について、参照する設計、今回の対象範囲、やらないこと、完了条件を先に復唱せよ。不足があれば質問だけ。コードはまだ書くな。
人間向け
なし。上をAIに渡すだけでよい。
まとめ
- 実装リポに要件・設計・非機能・テスト観点がある
- 「やってはいけないこと」と実装前ゲートが文章になっている
- 最初の依頼に参照・対象・やらないこと・完了条件がある
- 画面に出ないとき、デプロイ完了を先に疑う
- スタブと本番未接続を、利用者が誤解しにくい文言にしている