本文へ移動
AIコーディングをはじめよう

第7章・実践の基本

頼み方と確かめ方

AI に頼むときに大事なのは、うまい言い回しを覚えることではありません。人に仕事を頼むときと同じように、何のために・何を・どこまでやってほしいのかを伝えることです。Anthropic・OpenAI・Google の公式の手引きも、言い方は違いますが、同じことを勧めています。

もう1つ大事なのが、出てきたものを確かめることです。AI が書いたコードは、それらしく見えても、正しく動くとは限りません。この章では、メールアドレスの形を確かめる小さなプログラムを例に、頼み方と確かめ方を順に見ます。図に出てくるコードと出力は、実際に動かして確かめたものです。

この章で見ること
伝わる頼み方の5つ（目的・前提・やってほしいこと・やってほしくないこと・終わりの条件）、例の見せ方、大きな作業の分け方、バイブコーディングという言葉と、出てきたものの確かめ方（動かす・テスト・差分を読む・出典を開く）を、図で順に見ます。
読み終わると
目的と条件をそえて頼み、出てきたコードを動かして確かめる流れを自分で組み立てられる
前の章までに知っていること
頼む文をプロンプトと呼ぶこと（第2章）、AI エージェントがファイルを書き換えたりコマンドを動かしたりすること（第4章）、ハルシネーション（第1章）。第6章の「頼む → 許可する → 確かめる」の流れを思い浮かべながら読むと分かりやすくなります。
読む時間の目安
15分ほど

この章で出てくる言葉

分かる言葉は読み飛ばして構いません。途中で分からない言葉が出たら、ここに戻ってくるか、用語集で探してください。

文脈（前提）
頼みごとの背景として AI に伝える情報。関係するファイル、いまの状態、使っているプログラミング言語、参考にする例など、AI がまだ知らないこと。英語では context と言います。
制約（せいやく）
「やってほしくないこと」「守ってほしい決まり」として頼む文にそえる条件。「ほかのファイルは変えない」「新しいライブラリは足さない」など。
完了条件（終わりの条件）
何ができたら作業が終わりかを決めたもの。「テストが全部通る」「このエラーが出なくなる」のように、確かめられる形で書きます。
例を見せる（few-shot）（フューショット）
頼む文に、入力とそのときの答えの組をいくつか並べて、ほしい答えの形を伝えるやり方。ふつうの例だけでなく、間違えやすい端の場合も入れます。
端の場合（エッジケース）
空の入力・ふだん来ない形の入力など、まちがいが起きやすい境目の場合。ふつうの例では正しく動くプログラムも、ここで間違えることがあります。
関数（かんすう）
決まった仕事をする、名前の付いたプログラムのまとまり。入力を受け取って、答えを返します。例: メールアドレスを受け取って、正しい形かどうかを返す is_valid_email。
バイブコーディング（vibe coding）
出てきたコードを読まずに、AI に任せきりで作り進めるやり方。2025年の初めに Andrej Karpathy が名付けた言葉で、vibe は「雰囲気・ノリ」のことです。試しに作るだけならよくても、使い続けるものは確かめてから受け入れます。
動作確認
作ったものを実際に動かして、思ったとおりに動くかを確かめること。「動作確認までやって」は、作るだけでなく、動かして確かめるところまで頼むという意味です。
テスト
決めた入力と、期待する答えの組をプログラムにして、正しく動くかを機械にまとめて確かめさせるもの。期待どおりなら「通る」、違えば「落ちる（失敗する）」と言います。
レビュー
変更の中身（差分）を読んで、間違いや、頼んでいない変更が無いかを確かめること。人がするほか、AI にさせることもできます。
ドキュメント（公式の説明書）
プログラミング言語や道具を作った側が出している説明書。関数の名前や使い方が本当にあるかを確かめるときに見ます。
エラーメッセージ
プログラムがうまく動かなかったときに出る文。何が起きたか・どこで起きたかが書いてあります。AI に直してもらうときは、全文をそのまま渡します。
再現手順（さいげんてじゅん）
どうすると問題が起きるかの手順。どのコマンドを動かしたか、何をしたらどうなったか、毎回起きるかときどきか、などを書きます。

下にスクロールすると、図が1つずつ動いて説明が進みます。見逃したら、スクロールを戻せば同じところが巻き戻ります。図は、しくみを説明するために描いた模式図です。実際のアプリの画面ではありません。

  1. 01 / 20

    AI は、あなたの頭の中にある事情を知りません。頼む文（プロンプト）があいまいだと、足りないところを推測で埋めます。

    Anthropic は AI を「優秀だけれど、あなたの職場の決まりや進め方をまだ知らない新人」にたとえています。何のための作業か、どこまでやるかは、言わなければ伝わりません。

    会話では：「その頼み方だとあいまいすぎる」「前提が足りないから、AI が推測で埋めている」のように言います。

    しくみの図あいまいな頼み方：AI が推測で埋める

  2. 02 / 20

    伝わる頼み方の1つ目は目的です。何のために、何をしたいのかを先に書きます。

    理由が分かると、AI は書いていない細かいところも目的に合わせて決めやすくなります。Anthropic は、指示に理由や背景をそえると、より狙いに合った答えになると説明しています。

    会話では：「何をしたいか（目的）を先に書いて」と言われたら、作業の中身より先に「何のためか」を1文で書きます。

    しくみの図伝わる頼み方：5つをそえる

  3. 03 / 20

    2つ目は前提（文脈）です。関係するファイル、いまの状態、使っているプログラミング言語など、AI がまだ知らないことを伝えます。

    Claude Code・Codex・Antigravity CLI では、@ に続けてファイルの名前を書くと、どのファイルの話かをはっきり指せます。場所を言葉で説明するより確かです。

    会話では：「@email_check.py を見て」「関係するファイルを指定して頼む」のように、前提をそえて頼みます。

    しくみの図伝わる頼み方：5つをそえる

  4. 04 / 20

    3つ目はやってほしいことです。何を作るのか、どう動けばよいのかを具体的に書きます。

    「いい感じに」では、何がよいかを AI が決めます。Anthropic は、ほしい結果の形と条件を具体的に書くよう勧めています。図では、作る関数（名前の付いたプログラムのまとまり）の名前と、返す答えまで書いています。

    会話では：「関数の名前は is_valid_email にして」「何を返せば正解かまで書いて」のように、作るものを具体的にします。

    しくみの図伝わる頼み方：5つをそえる

  5. 05 / 20

    4つ目はやってほしくないこと（制約）です。変えてはいけないもの、使ってはいけないものを書きます。

    頼んでいない所まで直されたり、よそで作られた部品のプログラム（ライブラリ）を足されたりすると、確かめる手間が増えます。OpenAI は、何を変えずに残すかを書くよう勧めています。

    会話では：「ほかのファイルは触らないで」「新しいライブラリは足さないで」と制約を付ける、のように使います。

    しくみの図伝わる頼み方：5つをそえる

  6. 06 / 20

    5つ目は終わりの条件（完了条件）です。何ができたら終わりか、それをどう確かめるかを書きます。

    Codex の手引きは「テストが通る」のような終わった状態を、Claude Code の手引きは AI が自分で走らせられる確かめ方を、頼む文にそえるよう勧めています。

    会話では：「終わりの条件を決めて頼む」「テストが全部通ったら完了にして」のように使います。

    しくみの図伝わる頼み方：5つをそえる

  7. 07 / 20

    3社の公式の手引きも、言い方や並べ方は違いますが、目的や前提・制約・例などをそえるよう勧めています。

    毎回5つ全部を書く必要はありません。OpenAI は、短い頼み方で足りることも多く、役に立つ部分だけを使えばよいと書いています。決まった書き方や公式があるわけではありません。

    会話では：「前提を知らない同僚が読んで分かるか」で頼む文を見直す。これは Anthropic の手引きにある見直し方です。

    しくみの図3社の手引きが勧めていること

  8. 08 / 20

    言葉で説明しにくいことは、例を見せると伝わります。入力と、そのときの答えの組を並べます。

    ふつうの例だけでなく、間違えやすい端の場合も入れます。3社の手引きとも、例を見せるやり方（few-shot）を取り上げています。すでにあるファイルを手本として指すのも同じ考え方です。

    会話では：「入力と答えの例をそえて頼む」「name_check.py と同じ書き方で」のように、例や手本を見せます。

    しくみの図例を見せる：入力と答えの組

  9. 09 / 20

    大きな作業は、一度に頼まず小さく分けます。調べる → 計画する → 1つずつ作って確かめる、の順に進めます。

    Claude Code の手引きは、いきなり作らせると違う問題を解いてしまうことがあるとして、調べる・計画する・作るを分けるよう勧めています。計画だけを先に出させるプランモードは第10章で見ます。

    会話では：「まず調べて、計画を出してから作って」。逆に、1文で言える小さな直しなら、分けずにそのまま頼みます。

    しくみの図大きな作業は、小さく分けて頼む

  10. 10 / 20

    1回で思いどおりにならなくてかまいません。結果を見て、ずれていたら早めに止め、どこをどう直すかを伝えます。

    Claude Code の手引きは、同じことを2回直してもうまくいかないなら、会話をやり直し、分かったことを入れた頼み方で始め直すほうがよいとしています。

    会話では：「違う方向に行ってたら早めに止めて直す」「2回直してもだめなら、頼み方から書き直そう」のように言います。

    しくみの図大きな作業は、小さく分けて頼む

  11. 11 / 20

    出てきたコードを読まずに、AI に任せきりで作り進めることを「バイブコーディング」と呼ぶことがあります。

    2025年の初めに Andrej Karpathy が、雰囲気（vibe）に任せ、コードがあることさえ忘れる作り方をこう呼びました。試しに作って捨てるものならよくても、使い続けるものは確かめてから受け入れます。

    会話では：「バイブコーディングでとりあえず動いた」——動いたように見えても、このあと見る確かめ方で中身を見てから使います。

    しくみの図バイブコーディングと、確かめてから受け入れる作り方

  12. 12 / 20

    AI が「できました」と言っても、それだけでは正しいとは限りません。それらしく見えることと、正しく動くことは別です。

    Claude Code の手引きは、AI は作業が終わったように見えたところで止まると説明し、それらしいのに端の場合を扱えていない実装に注意するよう書いています。

    会話では：「『できました』を信じる前に確かめる」「それ、本当に動く？」のように言います。

    しくみの図確かめる：動かす・テスト・差分

  13. 13 / 20

    確かめ方の1つ目は、動かしてみること（動作確認）です。実際に入力を入れて、思ったとおりの答えが出るかを見ます。

    この例では、形が正しくない [email protected] を入れると True（正しい）が返ってきました。それらしいコードでも、端の場合で間違えることがあります。

    会話では：「動作確認までやって」は、作るだけでなく、動かして確かめるところまで頼む、という意味です。

    しくみの図確かめる：動かす・テスト・差分

  14. 14 / 20

    2つ目はテストです。決めた入力と、期待する答えの組を、機械にまとめて確かめさせます。

    終わりの条件に書いた3つの例が、そのままテストになります。AI にテストを走らせ、どのコマンドで何が出たかを見せてもらうと、確かめるのが速くなります。

    会話では：「テストを走らせて、結果を見せて」「テストが落ちてる（失敗している）」のように使います。

    しくみの図確かめる：動かす・テスト・差分

  15. 15 / 20

    3つ目は差分を読むこと（レビュー）です。差分は変更の前と後の違いで、消した行に −、足した行に + が付きます。

    図は NG を直したあとの差分です。コードが読めなくても、頼んだファイルだけが変わったかは見られます。Claude Code・Codex・Antigravity CLI では、/diff で差分を見られます。

    会話では：「差分を見てから OK する」「頼んでないファイルまで変わってない？」「AI にもレビューさせる」のように使います。

    しくみの図確かめる：動かす・テスト・差分

  16. 16 / 20

    AI は、存在しない関数を、あるかのように書くことがあります（ハルシネーション。第1章）。

    図の re.is_email は説明のための例です。Python に付いてくる re という部品に、この名前の関数はありません。動かすと「そんな名前は無い」というエラー（AttributeError）が出ます。

    会話では：「存在しない関数をハルシネーションで書いてきた」「動かしたら AttributeError が出た」のように言います。

    しくみの図存在しない関数を見分ける

  17. 17 / 20

    見分けるには、動かしてみる・公式の説明書（ドキュメント）で名前を探す・どこに書いてあるかを示させる、の3つです。

    AI の返事もまた間違えることがあります。Anthropic の手引きは、開いていないコードについて推測で答えさせない頼み方を例に挙げています。最後は、動かすか説明書を自分で開いて確かめます。

    会話では：「その関数、本当にある？」「ドキュメントのどこに書いてあるか見せて」のように聞きます。

    しくみの図存在しない関数を見分ける

  18. 18 / 20

    事実を聞いたときは、出典（どこに書いてあるか）を付けてもらい、そのページを自分で開いて確かめます。

    Anthropic は、分からないときは「分からない」と言ってよいと伝えることと、主張ごとに出典を付けさせることを、ハルシネーションを減らす方法に挙げています。減らせても、無くなりはしません。

    会話では：「出典を付けて」「分からないなら分からないと言って」「そのリンク、開いて確かめた？」のように使います。

    しくみの図出典を付けてもらい、自分で開く

  19. 19 / 20

    うまく動かないときは「動きません」ではなく、どう動かして、どんなエラーの文（エラーメッセージ）が出たかをそのまま渡します。

    Claude Code の手引きは、エラーの全文を貼り、原因を直してから確かめるよう頼む例を挙げています。再現のしかた（どうすると起きるか）や、毎回か・ときどきかも伝えます。

    会話では：「エラーの全文を貼って頼む」「エラーを消すだけでなく原因を直して」「再現手順を書いて」のように使います。

    しくみの図うまくいかないとき：状況をそのまま渡す

  20. 20 / 20

    頼む → AI が作る → 確かめる → 結果をそえて直しを頼む。この小さなくり返しが、AI コーディングの基本の流れです。

    確かめ方を頼む文に入れておけば、AI 自身が動かして結果を読み、通るまで直すこともできます。それでも、最後に確かめるのは自分です。

    会話では：「頼んで確かめる、を小さく回す」「確かめられないものは出さない」のように言われます。

    しくみの図頼む・確かめるのくり返し

この章のまとめ

  1. 1

    頼むときは、目的・前提・やってほしいこと・やってほしくないこと・終わりの条件をそえます。言葉で伝えにくいことは例を見せ、大きな作業は小さく分けて、結果を見ながら直します。毎回全部を書く必要はありません。

  2. 2

    「できました」は、確かめてから信じます。動かしてみる（動作確認）・テストを走らせる・差分を読む（レビュー）の3つで確かめます。それらしく見えることと、正しく動くことは別です。

  3. 3

    ハルシネーションは、動かす・説明書を見る・出典を開くで見分けます。うまくいかないときは「動きません」ではなく、どう動かしたかとエラーの全文をそのまま渡して、原因を直してもらいます。

この章の内容を確かめた情報源

確認日: 2026年10月25日

次の章第8章 スラッシュコマンド「/」で始まる短い命令で、AI ツールそのものを操作する。よく使うものと、自分で作るもの。

章の一覧へ戻る