はじめに
生成AIを勉強に使うとき、最初は何でも質問していました。
Dockerについて教えて
SQLのインデックスについて説明して
このエラーを直して
もちろん、AIはそれっぽい答えを返してくれます。
しかし、しばらく使っていると、ある問題に気づきました。
読んだ直後は分かった気がするのに、翌日にはほとんど覚えていない。
生成AIは非常に便利ですが、使い方によっては「理解した気分を高速で作る装置」になってしまいます。
そこで最近は、AIに答えを聞くのではなく、自分が考えないと先に進めない形で使うようにしています。
この記事では、実際に使いやすかった方法をいくつか紹介します。
AIに「説明して」と頼まない
例えば、SQLのインデックスを勉強するとします。
最初から次のように聞くと、AIはきれいな解説を返してくれます。
SQLのインデックスについて初心者向けに説明してください
ただし、この方法ではAIがほとんど全部考えてくれます。
そこで、質問を少し変えます。
SQLのインデックスについて勉強しています。
まず私に3問質問してください。
私が答えたあと、間違っている部分だけ指摘してください。
最初から正解は説明しないでください。
こうすると、AIは先生というよりクイズ出題者になります。
例えば、次のような質問が返ってきます。
1. インデックスがあると、なぜ検索が速くなるのでしょうか？
2. インデックスを増やしすぎると、どんな問題がありますか？
3. WHERE DATE(created_at) = '2026-07-01' は、
インデックスを使いやすい書き方でしょうか？
ここで一度、自分の言葉で答えます。
正解を読むより、自分で一度間違えたほうが記憶に残ります。
AIに「惜しい答え」を作らせる
個人的に面白かったのが、AIにわざと間違った説明を作らせる方法です。
SQLのインデックスについて、
初心者が信じそうな「少しだけ間違った説明」を3つ作ってください。
ただし、まだどこが間違っているかは説明しないでください。
例えば、次のような文章が出てきます。
インデックスを追加すると、SELECTだけでなく
INSERTやUPDATEも必ず高速になります。
これは一見もっともらしいですが、間違っています。
インデックスが増えると、データの追加や更新時にインデックス側も更新する必要があります。
そのため、書き込み処理はむしろ遅くなることがあります。
普通の解説を読むよりも、
どこがおかしいのだろう？
と考えるほうが、頭を使います。
技術記事、論文、設計レビューなどにも使いやすい方法です。
自分の説明をAIに採点させる
勉強した内容を、自分の言葉で説明します。
インデックスは、本の索引のようなものです。
データを最初から全部確認しなくても、
目的の行がありそうな場所を探せます。
この説明をAIに見せて、単に添削してもらうのではなく、評価基準を指定します。
次の説明を100点満点で採点してください。
評価基準：
- 技術的に正しいか
- 初心者にも分かるか
- 誤解を生む表現がないか
説明文を書き直す前に、
不足している点を箇条書きで示してください。
ポイントは、いきなり完成版を書かせないことです。
AIにすぐ文章を書き直させると、完成した文章を読んで終わってしまいます。
先に問題点だけ出してもらい、自分でもう一度書き直します。
AIに次の問題を決めてもらう
勉強していると、何を次に調べればよいか分からなくなることがあります。
そんなときは、AIに学習ロードマップ全体を作らせるより、次の一歩だけ決めてもらいます。
私はPythonでpytestの基本を使えます。
現在できること：
- 単純な関数のテスト
- pytest.raises
- fixtureの基本
次に30分で試すとよいテーマを1つだけ選んでください。
説明だけでなく、小さな実験課題も付けてください。
「Pythonのテストを完全に理解するロードマップ」のような巨大な計画は、だいたい途中で読まなくなります。
一方で、30分程度の課題ならすぐ試せます。
例えば、次のような課題です。
一時ファイルを使う関数を作り、
pytestのtmp_pathを使ってテストしてください。
これなら、その日のうちに手を動かせます。
AIは壮大な計画を作るのが得意ですが、人間は壮大な計画を放置するのが得意です。
そのため、AIには「次の一歩」だけ聞くようにしています。
別のAIにプロンプトを書かせる
あるAIへの質問文を、別のAIに作らせる方法も意外と便利です。
例えば、コードレビューを頼みたい場合です。
まず、AI Aに相談します。
次のPythonコードをAIにレビューしてもらいたいです。
レビューで確認したい点：
- 例外処理
- テストしやすさ
- ファイル操作の安全性
- 過剰な抽象化がないか
レビュー用のプロンプトを作ってください。
そのプロンプトをAI Bに渡します。
この方法の利点は、回答の精度が魔法のように上がることではありません。
自分が何を確認したいのか整理されることです。
「コードを見て」だけでは曖昧だった依頼が、次のように具体化されます。
以下のPythonコードをレビューしてください。
特に次の観点を確認してください。
1. 例外発生時に一時ファイルが残らないか
2. 入力パスを誤って削除する可能性がないか
3. 外部依存をモックしやすい構造になっているか
4. 単体テストで確認すべき境界条件は何か
問題点ごとに、
重要度・理由・修正例を示してください。
プロンプトを書かせる過程そのものが、問題整理の練習になります。
AIの回答を信じず、小さく実験する
AIを使った勉強で最も重要だったのは、AIの説明をそのまま信じないことでした。
例えば、次のような回答が来たとします。
このSQLではインデックスが使用されます。
この説明を読んで終わるのではなく、実際に確認します。
EXPLAIN ANALYZE
SELECT *
FROM logs
WHERE DATE(created_at) = '2026-07-01';
書き方を変えて比較します。
EXPLAIN ANALYZE
SELECT *
FROM logs
WHERE created_at >= '2026-07-01 00:00:00'
AND created_at < '2026-07-02 00:00:00';
実際の実行計画を見ると、AIの説明が正しいか確認できます。
Pythonでも同じです。
def divide(a: float, b: float) -> float:
return a / b
AIに「この関数は問題ありません」と言われても、テストを書きます。
import pytest
def test_divide() -> None:
assert divide(6, 3) == 2
def test_divide_by_zero() -> None:
with pytest.raises(ZeroDivisionError):
divide(1, 0)
AIの説明より、実際に動いた結果のほうが強いです。
最近は、AIから知識を受け取るというより、
- AIに仮説を出させる
- 自分で小さな実験を作る
- 結果をAIと一緒に確認する
という流れで使っています。
便利だったプロンプト集
最後に、そのまま使いやすい形でまとめます。
クイズ形式で学ぶ
〇〇について勉強しています。
初心者向けの問題を1問ずつ出してください。
私が回答するまで正解は説明しないでください。
回答後は、間違っている部分だけ指摘してください。
自分の理解を確認する
これから私が〇〇について説明します。
次の観点で採点してください。
- 技術的な正確さ
- 説明の分かりやすさ
- 抜けている重要事項
- 誤解を生みそうな表現
すぐに模範解答を出さず、
最初は改善点だけ教えてください。
間違い探しをする
〇〇について、
初心者が信じそうな少し間違った説明を3つ作ってください。
どこが間違っているかは、まだ説明しないでください。
小さな実験を作る
〇〇という説明が本当に正しいか確認したいです。
10〜30分程度で実行できる、
最小構成の検証方法を考えてください。
必要なコード、観測する値、
正しい場合と間違っている場合の結果を示してください。
次の勉強内容を決める
現在の理解状況は次の通りです。
できること：
- 〇〇
- 〇〇
分からないこと：
- 〇〇
次に30分で試すべきテーマを1つだけ選んでください。
小さな実装課題も付けてください。
まとめ
生成AIを使うと、分からないことの答えをすぐに得られます。
ただし、答えを読むだけでは、理解した気分で終わることがあります。
そこで私は、AIを次のように使うようになりました。
- 答えではなく、問題を作らせる
- 自分の説明を採点させる
- わざと間違った説明を作らせる
- 次の小さな課題だけ決めてもらう
- AIの回答をコードや実験で確認する
AIに全部教えてもらうのではなく、自分が考えるための面倒な部分をAIに用意してもらうイメージです。
AI時代の勉強法というと、特別なプロンプトや高度なツールが必要に見えます。
しかし、実際に効果を感じたのは、
すぐに答えを教えないでください
という、かなり単純な一言でした。