マガジン

学びながらAIコーディングを使う:コードを理解したまま進める依頼と確認のルール

AIを使いこなす

Claudeで執筆し、GPTで自動校閲・修正しています。

机に並べた無地のカードを一枚ずつ確認する手元
記事の内容をもとに制作したAI生成イメージです。実際の製品画面や検証結果の写真ではありません。

コードを理解したままAIに手伝わせるコツは、「完成品を頼む」前に「読む」「予想する」「小さく変える」「自分の言葉で説明する」の順を挟むことです。AIに書かせる量を減らすのではなく、書かせたあとに自分が説明できる状態を作ってから次へ進む、というルールにします。 この記事では、そのための依頼の順番、コピーして使える依頼文、説明できたかを確かめる手順、任せる範囲の判断表を示します。依頼文や判断表は編集上の提案で、説明用の例です。実際に各ツールで動かした結果ではありません。

この記事の目次
  1. 理解を残す3つのルール
  2. ツール側の機能で任せる範囲を絞る
  3. 手順:1つの変更を理解して終えるまで
  4. 確認の順番を固定する理由
  5. 判断表:どこまでAIに任せるか
  6. 情報の渡し方の注意

理解を残す3つのルール

  1. 1回の依頼で変えるのは1つだけにします。 「ログイン機能を作って」ではなく「入力が空のときのエラー表示を足して」のように分けます。変更が小さいほど、差分を読み切れます。
  2. AIの回答を見る前に、自分の予想を書きます。 「この関数は○○をしていると思う」と一行でも書けば、ズレた部分が学びになります。
  3. 次の依頼に進む条件は「自分の言葉で説明できた」ことです。 動いたかどうかだけでは進みません。動くコードは、理解していなくても手に入るからです。

ツール側の機能で任せる範囲を絞る

依頼文だけで頑張らず、ツールのモードも使えます。以下は公式ドキュメントで確認できた範囲です。

  • GitHub Copilot Chat: 公式ドキュメントでは、Ask modeはコードベースやコーディング、技術概念についての質問に答えるためのもので、コードの変更を伴わないと説明されています。一方、Agent modeはコードの編集やコマンドの実行まで自律的に進めます。理解したい段階ではAskを使い、変更を任せる段階でAgentに切り替える、という使い分けが考えられます。
  • Cursor: モードの公式ドキュメントによると、Plan modeはエージェントが質問をして要件を確認し、コードベースを調べたうえで、レビューできる実装計画を作ります。計画は編集してから実行に進めます。コードを書かせる前に方針を読めるので、学習用途に向きます。モードはピッカーまたはShift+Tabで切り替えられると記載されています。
  • Claude Code: Output stylesに、LearningとExplanatoryというスタイルがあります。Explanatoryは選択の理由を短いInsightとして添えます。Learningはそれに加えて、設計判断のある部分をTODO(human)としてあなたに書かせ、待ちます。切り替えは/output-style learningなどで行えます。スタイルはClaudeへの指示であり、動作を保証するものではないとも明記されています。バージョン要件は機能ごとに異なるので、手元の環境で確認してください。

どのツールでも、使っているプランやバージョンで挙動が変わる可能性があります。モードが見当たらない場合は、次の依頼文に「コードは書かず説明だけ」と書けば代用できます。

手順:1つの変更を理解して終えるまで

手順1:まず読むだけの依頼をする(コードは変えさせない)

【説明用の例】
次のファイルを、まだ変更せずに説明してください。
- 対象:todo.js(ToDoを配列に追加・削除する小さなプログラム)
- 私の理解度:JavaScriptは変数と関数を少し書いたことがある程度
- 形式:処理の流れを番号付きで、専門用語は初出で一言添える
- 最後に、私が理解を確かめるための質問を3つ出してください

手順2:自分の予想を書いてから答えを見る

質問に対し、AIの解説を見返す前に、短くてもよいので自分で答えを書きます。間違いは問題ありません。ズレた箇所が、次に聞く場所になります。

手順3:小さな変更を、計画つきで頼む

【説明用の例】
todo.jsに「空文字のときは追加しない」処理を足したいです。
- まだコードは書かず、変更する場所と方針を3行以内で示してください
- 選択肢が複数ある場合は、2案とそれぞれの違いを書いてください
- 私が選んだあとで、変更を最小限にして実装してください

手順4:差分を読み、一行ずつ「何のための行か」を言う

実装されたら、変更された行だけを上から読みます。分からない行は削除せず、そのまま質問します。

【説明用の例】
今回の変更のうち、3行目の if 文が何を防いでいるのかを、
入力が「空」「スペースだけ」「通常の文字」の3パターンで説明してください。

手順5:自分の言葉で説明し、AIに採点させる

最後に、次の型で自分の説明を書いて渡します。

【説明用の例】
今回の変更を、次の形で私が説明します。誤りや抜けを指摘してください。
修正版は書かず、どこが違うかだけ教えてください。

1. 変更前の問題:
2. 変更した場所と内容:
3. なぜそれで直るのか:
4. 変更しても影響しないと考える部分:
5. 自分で試すなら、どんな入力で確認するか:

5項目すべてを自分で書けたら完了です。書けない項目があれば、その部分だけ手順1に戻ります。

確認の順番を固定する理由

確認は「説明、予想、差分、動作」の順にします。先に動作を見ると、動いた安心感で差分を読まなくなりやすいためです。実行して確認するときも、AIに「どんな入力でどんな結果になるはず」と先に言わせ、自分でも予想してから実行すると、結果とのズレを学習に使えます。

判断表:どこまでAIに任せるか

下の表は、学習を目的とするときの目安です。業務で期限がある場合は変えて構いません。

  • 知らない構文やエラーの意味、AIに任せる:説明、例の提示、自分でやる:例を自分の言葉で言い換える
  • 設計の選択(データの持ち方、エラーの扱い)、AIに任せる:選択肢の列挙と違いの説明、自分でやる:どれにするか決める
  • 定型の記述(設定ファイル、繰り返しの多い処理)、AIに任せる:実装、自分でやる:差分を読み、手順5で説明する
  • 初めて書く機能の中心部分、AIに任せる:ヒントと採点、自分でやる:最初の1回は自分で書く
  • 原因不明の不具合、AIに任せる:原因の仮説を複数出す、自分でやる:仮説を1つずつ検証する順番を決める

「自分で書く」箇所は、ClaudeのLearningスタイルのように、AI側に空欄を作らせる頼み方もできます。他のツールなら「重要な判断を含む部分は、実装せずTODOとして残してください」と依頼文に書きます。

情報の渡し方の注意

学習用に貼るコードは、本物の鍵やパスワード、個人情報、社外秘のコードを含めず、ダミーに置き換えた小さな例にします。ツールの学習利用設定と、情報が外部に送られること自体は別の話です。設定の有無にかかわらず、貼らないほうが安全です。

出典・参考資料