個人的によく使う学習効率化のプロンプトを3つ、
実際のやり取り例とあわせてメモしてみます。

1. 横展開プロンプト：「〇〇という概念と同等の重要度の概念を3つ教えて」

用途

言語・フレームワーク・アーキテクチャなど、新しい概念を一つ学んだタイミングで横展開するためのプロンプト。

同等レベルの概念を提示してもらうことで、自分の理解度に合ったまま知識を広げられる。「初心者向けに全部教えて」と頼むと粒度がバラバラになりがちだが、このプロンプトは学習している概念をアンカーにして難易度を揃えるのがポイント。

やり取り例

User: React の useEffect という概念と同等の重要度の概念を3つ教えて

Claude: useEffect と同レベルで押さえておきたい概念を3つ挙げます。

useState — コンポーネントのローカル状態を管理するフック。useEffect が「副作用」を扱うのに対し、こちらは「状態」を扱う。両者はセットで使われることが多く、React の関数コンポーネントの根幹です。

useContext — propsを介さずにツリーをまたいで値を共有するフック。「状態管理」と「副作用」の次に来る、データフロー設計の基礎概念です。

useMemo / useCallback — レンダリング結果や関数をメモ化するフック。useEffect の依存配列と同じ思考モデル（依存関係の明示）を使うため、セットで理解しておくと再レンダリング最適化の議論についていけます。

もう一段深掘りするなら「カスタムフック」「useReducer」あたりが次の階層ですが、まずはこの3つを押さえると React の Hooks API の地図がだいたい描けます。

ポイント

「初心者向けに」「上級者向けに」と粒度を指定する必要がない
「次に何を学ぶべきか」を自分で考える前に、地図を提示してもらえる
学習中の概念名を変えるだけで、あらゆる領域に転用可能（例：「Kubernetes の Pod と同等の重要度の概念を3つ」「OAuth 2.0 の Authorization Code Grant と同等の…」）

2. クイズ駆動理解プロンプト：「xxx について、私の理解度が95%になるまでクイズを出し続けて」

用途

コードベースの理解、実装した処理のコードリーディングのお供に。「読みっぱなしでわかった気になっているポイント」を強制的に潰せる。

%（理解度）はお好みで。70% でゆるく確認、95% でガッツリ詰める、といった使い分けができる。

やり取り例

User: Prisma の $transaction API について、私の理解度が95%になるまでクイズを出し続けて。1問ずつ出して、私の回答を評価してから次に進んでください。

Claude: 了解しました。1問目です。

Q1. Prisma の $transaction には2つの使い方があります。「シーケンシャルAPI（配列を渡す方式）」と「インタラクティブAPI（コールバックを渡す方式）」の違いを、ユースケースの観点から説明してください。

User: シーケンシャルは複数のクエリをまとめてアトミックに実行したいとき。インタラクティブは途中の結果を使って次のクエリを組み立てたいときに使う。

Claude: 正解です。本質を捉えています。補足すると、シーケンシャルは「クエリ間に依存関係がない」場合のシンプルなパターン、インタラクティブは「条件分岐や中間結果の利用」が必要なケースで使います。後者は柔軟な代わりに、コールバック内が長くなるとロック保持時間が伸びるので注意が必要です。

Q2. インタラクティブトランザクションには maxWait と timeout という2つのオプションがあります。それぞれ何を制御していますか？

User: timeout はトランザクション全体のタイムアウト。maxWait は……トランザクションが始まるまでの待ち時間？

Claude: 正解です。より正確に言うと maxWait は「Prisma がトランザクション用のコネクションを取得するまでに待つ最大時間」、timeout は「トランザクションが開始してから完了するまでの最大時間」です。本番環境でデッドロックや長時間ロックが疑われるときは、まずこの2つのデフォルト値（それぞれ 2秒、5秒）を疑うのが定石です。

Q3. 次のコードには問題があります。何が問題でしょうか？
await prisma.$transaction(async (tx) => {
  const user = await tx.user.findUnique({ where: { id } });
  await fetch('https://api.example.com/notify', {
    method: 'POST',
    body: JSON.stringify({ userId: user.id }),
  });
  await tx.user.update({ where: { id }, data: { notified: true } });
});

User: トランザクションの中で外部API呼んでる。これだと外部APIが遅いとトランザクションがずっと開きっぱなしになる。

Claude: 完璧です。これは「ロングランニングトランザクション」のアンチパターンの典型例です。外部API呼び出しはトランザクションの外に出すか、Outbox パターンを使ってDBに「通知タスク」を書き込み、別プロセスで処理するのが定石です。

（以下、続く……）

ポイント

「1問ずつ」「評価してから次へ」と明示するのが重要。まとめて10問出されると答えるのが面倒で続かない
自分が答えに詰まった時点で、その概念の理解が不完全だったとわかる
実装直後のコードに対して「このコードの設計判断について95%までクイズして」も効果的
終了条件は「95%」「もう新しい論点が出ない」「飽きるまで」など曖昧でOK。Claude が出題ネタを使い切ったあたりで自然に収束する
一問一答の想定問答集を吐かせてみても面白い

3. ドキュメント再構成プロンプト：「----.md を読んで、通読しやすい構造に再構成した資料を作成して」

用途

社内ドキュメント、OSS の README、自分が書いた実装仕様書……「読まなきゃいけないけど構成がしんどい」ドキュメントの理解負債を効率的に解消するためのプロンプト。

人間が読みやすい構成への再構成を明示することで、認知負荷を下げた状態で内容にアクセスできる。

やり取り例

User: 添付の xxx-mcp-spec.md を読んで、通読しやすい構造に再構成した資料を作成してください。元の情報は落とさず、ただし以下の観点で整理してほしいです：

「全体像 → 詳細」の順

前提知識（用語定義）を先頭にまとめる

設計判断の「なぜ」がある箇所は強調する

実装者が読む順に並べる

Claude: 承知しました。以下の構成で再構成しました。

xxx MCP Remote Connector 仕様書（再構成版）

0. この資料の読み方

実装者向け：§1 → §3 → §5 の順で読むと最短で実装に取りかかれます

レビュワー向け：§2（設計判断の根拠）を中心に

1. 前提：登場する用語

用語定義補足

MCP Model Context Protocol。LLM に外部ツールを公開するプロトコル …

AgentCore Gateway AWS が提供する MCP ホスティング …

RFC 8707 Resource Indicators for OAuth 2.0 audience 検証で利用

2. 全体アーキテクチャ

（図と1段落のサマリ）

3. なぜこの構成なのか（設計判断）

重要：AgentCore Gateway を第一選択、ALB+ECS をフォールバックとした理由は…

4. コンポーネント詳細

…

5. 実装手順

…

元のドキュメントで散らばっていた「設計判断の根拠」を §3 に集約し、用語定義を §1 に前出ししました。実装手順（§5）は元ドキュメントの順を尊重しています。

削った情報はありません。必要なら「§2 をもっと図中心に」など追加の指示をください。

ポイント

観点を箇条書きで指定すると、Claude が「何を優先するか」迷わない
「元の情報は落とさず」は明示しておく（要約と勘違いされないように）
元ファイルが長い場合は「章ごとに出力して」と分割指示するとよい
アウトプットを Markdown にしておけば、そのまま社内 Wiki に貼れる

応用

「読む順を、初心者 / 中級者 / 設計レビュアーの3パターンで提案して」
「この仕様書を読む前に押さえるべき前提知識のリストを作って」
「セクションごとに『この章で何がわかるか』の1行サマリを冒頭に追加して」