前回との接続——間違いは渡す情報で減らせる
前回のA-06では、AIがもっともらしく間違える理由を五つに分けて見ました。そのうち情報不足・曖昧な仕様・文脈欠落の三つは、こちらが渡す情報しだいで大きく減らせるものでした。ではどんな情報を、どんな順で渡せばよいのでしょうか。この講義では、渡すべき情報を七つの種類に整理し、毎回同じ型で用意できるようにします。
このスライドのポイント
- A-06: AIがもっともらしく間違える理由を5分類で見た
- そのうち情報不足・曖昧な仕様・文脈欠落は、渡す情報しだいで減らせる
- この講義の役割: 何を渡すかを7種類の型にする
AIに渡す7種類の情報
AIに渡す情報は、目的・制約・現状コード・エラー・期待結果・変更禁止範囲・受入条件の七種類に分けられます。目的は何のために作るのか、制約は守るべき条件で、使う技術や期限、費用などがこれにあたります。現状コードはいまの実物のことで、エラーは実際に出た文言そのものです。期待結果はどうなれば正しいか、変更禁止範囲は触ってはいけない箇所、受入条件は完成と認める判定条件を指します。まずはこの七つの名前と役割を、ひとつずつ押さえてください。
このスライドのポイント
- 目的＝何のために作る／直すか
- 制約＝守るべき条件（使う技術・期限・費用など）
- 現状コード＝いまの実物
- エラー＝実際に出た文言そのまま
- 期待結果＝どうなれば正しいか
- 変更禁止範囲＝触ってはいけない箇所／受入条件＝完成と認める判定条件
なぜ必要か——一行依頼が誤りを招く
この七種類を意識しないと、依頼はどうしても「動きません、直して」という一行になりがちです。すると、A-06で見た誤りのうち、前提が足りない情報不足、どうなれば正解か決まっていない曖昧な仕様、いまのコードを見せていない文脈欠落を、自分から招いてしまいます。AIは足りない部分を勝手に補って生成するため、こちらの意図とずれた答えが返ってきます。つまり、間違いの多くは渡す情報の不足から生まれているのです。
このスライドのポイント
- 7種類を意識しないと「動きません、直して」の一行依頼になりがち
- それはA-06の①情報不足・②曖昧な仕様・⑤文脈欠落を自分で招くこと
- AIは足りない部分を勝手に補うため、意図とずれた答えが返る
7種類の構造——3つのかたまりで捉える
七種類は、上から順に並べて表にすると使いやすくなります。目的から受入条件まで、種類・役割・書き方の例を一行ずつ並べておき、依頼のたびに上から埋めていきます。前半の目的・制約は「何を目指すか」を決め、現状コード・エラーは「いまどうなっているか」を伝え、後半の期待結果・変更禁止範囲・受入条件は「どうなれば終わりか」を決めます。この三つのかたまりで見ると、七種類が覚えやすくなります。全部をいきなり完璧に書く必要はなく、型として手元に置くことが大切です。
このスライドのポイント
- 7種類は表にして、依頼のたびに上から埋める
- 目的・制約＝何を目指すか
- 現状コード・エラー＝いまどうなっているか
- 期待結果・変更禁止範囲・受入条件＝どうなれば終わりか
具体例——一行依頼を7項目に書き直す
具体例として、「フォームの送信ボタンが反応しない」という困りごとで考えます。改善前は、その一行をそのままAIに送るだけの依頼です。これでは、どの画面のどのボタンか、どんなエラーが出ているか、何が正しい動きかが何も伝わりません。改善後は、目的から受入条件までの七項目を埋めて渡します。目的は問い合わせを受け付けること、現状コードは該当箇所、エラーは画面に出た文言そのまま、期待結果は送信後に完了表示が出ること、といった具合です。同じ困りごとでも、渡す情報の量でAIの答えは大きく変わります。
このスライドのポイント
- 題材:「フォームの送信ボタンが反応しない」
- before: その一行をそのまま送るだけ
- after: 目的〜受入条件の7項目を埋めて渡す
- 同じ困りごとでも、渡す情報の量で答えが変わる
技術サンプルカード——7項目テンプレート
サンプルは、七項目をそのまま埋められるプロンプトの雛形です。目的、制約、現状、エラー、期待結果、変更禁止、受入条件の見出しを並べ、それぞれに自分の状況を書き込みます。読み方のポイントは二つあります。ひとつは、エラーは自分で要約せず、出た文言を原文のまま貼ること。もうひとつは、変更禁止範囲を書いておくと、直してほしくない場所まで書き換えられる事故を防げることです。AIには「この依頼に不足している情報があれば、作業前に質問してください」と添えると、抜けを先に指摘してもらえます。
このスライドのポイント
- 種別: prompt
- 目的: AIへの依頼に7種類の情報を漏れなく渡すための雛形
- サンプル本体:
混同しやすい概念——期待結果と受入条件
混同しやすいのが、期待結果と受入条件です。期待結果は「送信したら完了表示が出てほしい」という望む動きの説明で、進む方向を示します。受入条件は「空欄のまま送信するとエラーメッセージが出る」「送信後に一覧へ一件増える」のように、OKと判定できる具体的なチェック項目です。期待結果が方向だとすれば、受入条件は合否を分ける線だと考えてください。両方そろって初めて、AIも自分も、完成したかどうかを同じ基準で確かめられます。
バイブコーディングでの確認点
バイブコーディングで確認したいのは、依頼を送る前に七項目を上から順に埋めているか、という一点です。埋めていくと、書けない項目が出てくることがあります。それは準備不足ではなく、自分の要件がまだ曖昧だというサインです。たとえば受入条件が書けないなら、自分自身がゴールを決めきれていない、ということになります。書けない項目こそ、AIに頼む前に自分で考えるべき場所だと受け取ってください。
このスライドのポイント
- 依頼前に7項目を上から順に埋めているか確認する
- 埋まらない項目は準備不足ではなく、自分の要件が曖昧なサイン
- 例: 受入条件が書けない＝ゴールを決めきれていない
一問一答とまとめ
最後に一問一答です。触ってほしくない箇所を伝える項目は、七種類のうちどれでしょうか。答えは、変更禁止範囲です。ここを書いておくことが、直してほしくない場所を守る最後の盾になります。三十秒でまとめます。AIに渡す情報は目的・制約・現状コード・エラー・期待結果・変更禁止範囲・受入条件の七種類で、依頼のたびに上から埋めるのが基本です。次回のA-08では、依頼を書くさらに手前、そもそもコードを作らせる前に決めておく八項目へ進みます。関連資料は「要件定義プロンプト100」「開発プロンプト100選」「Claude Code初回指示テンプレート」です。
このスライドのポイント
- 一問一答:「触ってほしくない箇所を伝える項目は？」→ 変更禁止範囲
- 30秒まとめ: 渡す情報は7種類、依頼のたびに上から埋める
- 次回A-08: コードを作らせる前に決めておく8項目へ
- 関連資料:「要件定義プロンプト100」「開発プロンプト100選」「Claude Code初回指示テンプレート」
