Claude Media
ClaudeでLeetCodeを練習する — ヒントを3段階で出させる指示文の作り方

ClaudeでLeetCodeを練習する — ヒントを3段階で出させる指示文の作り方

LeetCodeやAtCoderの過去問で、解答を先に見せずヒントを3段階で出させ、解いた後に計算量と別解を講評させる練習環境をProjectsの指示欄に作る手順です。

アルゴリズム問題をClaudeに貼ると、多くの場合そのまま解答コードが返ってきます。面接対策としては、これが一番もったいない使い方です。自力で考える時間が消え、本番で必要な「手が止まったときの立て直し方」が身につきません。

練習用のProjectsを1つ作り、指示欄に「解答は出さない」「ヒントは3段階」「私の解法が出てから講評する」の3点を書いておけば、問題文を貼るだけで、毎回同じ進め方の練習が始まります。この記事では、その指示文の書き方、ヒントの3段階の切り方、解いた後の講評の頼み方、そしてAtCoderのコンテスト開催中には使えないという線引きまでを扱います。

解答を出さない指示を、Projectsの指示欄に置く

Projectsは、独自のチャット履歴とナレッジベースを持つ作業スペースです。ナレッジに資料を置けるほか、プロジェクトごとに指示(project instructions)を設定でき、そのプロジェクトのすべてのチャットに適用されます。無料アカウントを含む全ユーザーが使え、無料プランで作れるのは5つまでです。

アルゴリズム練習では、この指示欄が要になります。問題を貼るたびに「答えを出さないで」と頼み直す必要がなくなり、問題文だけを貼る運用に変えられるからです。

プロジェクト作成後、「Set project instructions」から次のような内容を保存します。以下は筆者の設計例で、文面は自分の弱点に合わせて書き換える前提です。

あなたはコーディング面接の練習相手です。
私が貼るのはLeetCodeやAtCoderの問題文です。次のルールで進めてください。
 
1. 私が「解法を書きました」と言うまで、完全な解答コードも
   最終的なアルゴリズム名も出さない。
2. ヒントは3段階。私が「ヒント1」「ヒント2」「ヒント3」と
   段階を指定したときだけ、その段階を1つ出す。
3. 私の解法が出たら、次の順で講評する。
   (a) 正しさ  (b) 時間・空間計算量  (c) 別解とその計算量の比較
   (d) 面接官に説明する言葉として分かりにくい箇所
4. 講評では、私の解法に誤りがあれば反例の入力を1つ示す。
5. 問題文だけが貼られたら、制約を読み上げ直して
   「まず方針を言葉で教えてください」と返す。

ポイントは、行動を許可制にしていることです。「ヒントを出してはいけない」と禁止だけを並べるより、「私が段階を指定したときだけ出す」と書くほうが、返答の振る舞いを読みやすく保てます。指示文が必ず守られる保証はないので、守られなかった回は後述の対処で直します。

ヒントの3段階をどう切るか

「3段階」は、段階ごとに出してよい情報の量を決めておいてはじめて機能します。指示欄に段階の定義まで書いておくと、同じ「ヒント2」でも毎回の粒度がそろいます。

段階出す内容出さない内容
ヒント1出す内容問題の型を考える観点(何を数えるか、何が単調か)出さない内容アルゴリズム名、データ構造名
ヒント2出す内容使えるデータ構造や考え方の候補出さない内容計算量の見積もり、擬似コード
ヒント3出す内容方針の骨格と、見落としやすい境界条件出さない内容完全なコード

この表をそのまま指示欄の補足に貼っても構いません。ヒント3まで出しても完全なコードは出さない、という線を引いてあるので、最後は自分でコードを書く時間が残ります。

段階の切り方は、練習の目的で変えられます。

  • 本番の面接に近づけたいなら、ヒント1だけを使い、ヒント2以降は「面接官に聞くつもりで」最後まで取っておく
  • 解けない問題を減らしたいなら、ヒント3まで使ってよい代わりに、解いた後の講評で「なぜヒント1の観点に気づけなかったか」を必ず頼む
  • 時間を測りたいなら、問題を貼ってからヒント1を要求するまでの経過時間を自分で計り、15分で手が止まったらヒントに進むと決める

どれを選んでも、使ったヒントの段階は問題ごとに記録しておくと効きます。記録の置き場所は次の節で扱います。

1問1チャットで回す練習の流れ

練習の単位は「1問につき1チャット」にします。理由は、プロジェクト内でもチャット同士の文脈は共有されないためです。ナレッジに入れた情報だけが全チャットに渡ります。裏を返せば、前の問題のヒントや自分の誤答が次の問題の判断に混ざらず、毎回まっさらな状態で始められます。

手順

1問あたりの進め方

  1. 1

    プロジェクト内で新しいチャットを開く

    指示欄の内容が効いた状態で始まります。前の問題の続きにせず、問題ごとにチャットを分けます。

  2. 2

    問題文と制約だけを貼る

    LeetCodeなら問題文と制約、AtCoderなら問題文・制約・入出力例を貼ります。「解いてください」とは書きません。

  3. 3

    自分で方針を言葉にする

    指示欄の5つ目のルールにより、まず方針を言葉で求められます。ここで詰まったらヒント1を要求します。

  4. 4

    解法を書いて提出し、自分のテストを通す

    講評を頼む前に、サイトのサンプルや自作のケースで一度動かしておきます。

  5. 5

    「解法を書きました」と伝えて講評を受ける

    コードを貼り、使ったヒントの段階も一言添えます。講評が出たら、次の節の観点で自分の説明を口頭で言い直します。

弱点が毎回の講評に散らばるので、複数の問題をまたいだ傾向は自分で拾う必要があります。ナレッジに「弱点メモ」という短いテキストを1つ置き、問題を解くごとに「二分探索の境界でつまずいた」「ヒント2まで使った」と1行ずつ足していきます。ナレッジに置いたファイルは全チャットで使われるので、次の問題の講評で「このメモの傾向を踏まえて」と頼めば、過去の癖を踏まえた指摘を引き出せます。

プロジェクトごとのメモリも関係します。メモリはプロジェクトごとに独立していて、そのプロジェクトで保存された内容は他のプロジェクトのチャットには使われません。志望先ごとの面接練習とアルゴリズム練習は、別のプロジェクトに分けておくほうが混ざりません。メモリを使いたくない回は、最初のメッセージを送る前に「+」メニューで「Memory」をオフにできます。

解いた後の講評を頼む観点

ヒントを使って解けたあとが、面接対策としては本番です。面接官が見るのは、正解にたどり着いたかどうかより、計算量を言えるか、別の解き方に触れられるか、自分の考えを人に伝えられるかだからです。

講評の依頼は、指示欄のルール3に沿って短く書けます。

解法を書きました。使ったヒントは2まで。
言語はPython。下のコードの講評をお願いします。
 
(コード)

指示欄に講評の4観点を書いてあるので、依頼は短くて済みます。それぞれの観点で何を頼んでいるかを順に見ます。

正しさの確認では、反例を出させる使い方が有効です。ルール4のように「誤りがあれば反例の入力を1つ示す」と書いておくと、指摘をそのまま自分のテストケースに転用できます。

計算量については、Claudeの答えをそのまま信じず、自分でも見積もります。入力サイズの上限と照らして、時間内に収まるかを見ます。AtCoderなら制約の最大値、LeetCodeなら制約欄の値をそのまま使います。

別の解き方を知りたいときは、「別解を1つ挙げ、計算量をあなたの解法と並べて比べて」と頼みます。面接では「他にどんな方法がありますか」と聞かれることが多く、その答えの練習になります。

説明の分かりにくさを見るには、解法を面接官に説明する文章を自分で書き、それを貼って「聞き手が詰まりそうな箇所」を指摘させます。コードの講評とは別の依頼にすると、説明の改善点が埋もれません。

別解や計算量の説明が本当に正しいかは、手元で確かめられます。たとえば自分の解法と、遅いが確実な全探索を比べるだけの小さなテスターを置いておけば、Claudeが示した別解も同じ要領で突き合わせられます。

import random
 
def fast(a):      # 自分の解法(または講評で示された別解)
    ...
 
def brute(a):     # 遅くても確実な全探索
    ...
 
for _ in range(1000):
    a = [random.randint(-5, 5) for _ in range(random.randint(1, 8))]
    assert fast(a) == brute(a), a

入力が小さいと不具合は拾いにくいため、境界値(長さ1、全要素が同じ、負数を含む)を含めた範囲で乱数を振ります。これで食い違いが出たら、その入力が次の問題の「弱点メモ」の材料になります。

コンテスト開催中のAtCoderでは使えない

この練習法には、使ってよい場面の線引きがあります。AtCoderには生成AIに関するルールがあり、開催中のABC・ARC・AGCでは生成AIの使用が原則禁止です。例外は問題文の翻訳など限られた用途で、問題文やその要約を生成AIに入力して解法の説明を出力させることも、コンパイルエラーの診断に使うことも禁止されています。

一方で、このルールが適用されるのはコンテストの開催中だけです。過去問の練習には適用されず、Heuristic Contestは別のルールで運用されています。この記事の使い方は「過去問を解く自主練習」が前提で、開催中のコンテストや、コンテスト中に使う補助としては想定していません。

実際のコンテストに出る人は、次の分け方が目安になります。

  • 過去問の練習 → ヒントと講評を使ってよい
  • 開催中のABC・ARC・AGC → 使わない。問題文の翻訳に使う場合も、ルール側が定める書式に従う
  • 他サービスのコンテスト(LeetCodeのコンテストなど) → 各サービスの規約を先に読む

ルールは改訂されるため、コンテストに出る前にAtCoderの生成AI対策ルールのページを自分で開いて、その時点のルールを読む習慣をつけておくと安全です。

指示どおりに動かないときの直し方

指示欄を書いても、いくつかの場面で意図とずれることがあります。原因別に直し方を並べます。

落とし穴

問題文を貼っただけで解答コードが返ってくる

指示欄が効いていないか、ルール1の書き方が弱い可能性があります。まず、そのチャットが対象プロジェクトの内側で始まっているかを確認します。プロジェクトの外で始めたチャットには指示が渡りません。標準のチャットを後からプロジェクトへ移すこともでき、会話の途中で気づいた場合に使えます。

落とし穴

ヒント1の段階で、すでにアルゴリズム名が出る

段階の定義を指示欄に書いていないと起きやすい現象です。前の節の表を指示欄へそのまま貼り、「ヒント1ではアルゴリズム名とデータ構造名を出さない」と明文化します。それでも出たら、その回のチャットで「ヒント1には名前を含めない形でやり直して」と一言返します。

落とし穴

講評が褒めるだけで終わる

観点を指定していないと、全体の感想に寄りがちです。講評の4観点を指示欄に番号付きで書くほか、「改善点を最低2つ挙げる」と回数で縛る書き方も効きます。

もう1つ、問題文の貼り方にも癖が出ます。LeetCodeの問題文には例の入出力と制約がまとまっているため、そのまま貼れば足ります。AtCoderは問題文が長いので、制約と入出力例まで漏らさず貼ります。制約が欠けると、計算量の講評が実際の入力サイズと噛み合わなくなります。

面接全体の練習との分け方

ここまでの指示欄は、アルゴリズム問題を解く練習に絞った設計です。面接官役に質問を出させ、回答の構成や話し方を採点させる一般の面接練習は、評価の軸が違います。そちらはClaudeを面接官役にして模擬面接を練習する方法にまとまっていて、アルゴリズム練習用のプロジェクトとは別に持っておくと混ざりません。

ケース面接のように、資料を読んで構造化して答える形式の練習はClaudeでケース面接を練習する方法が扱っています。どの練習でも、プロジェクトを分けて指示欄に役割を書く点は共通です。Claude Projectsの機能を一度押さえておくと、練習ごとの環境づくりが短時間で済みます。

まとめ

コーディング面接の練習で効くのは、答えを先に見せない進め方を、指示欄に一度だけ書いておくことです。ヒントを段階で区切り、解いた後に計算量と別解と説明の分かりにくさを講評させる流れは、問題文だけを貼る運用に落とし込めます。

講評の正しさは手元のテストで確かめ、弱点の傾向はナレッジの短いメモに自分で積み上げます。開催中のAtCoderでは使わない、という線引きをコンテストの前に決めておくと、ルール違反を避けられます。

参照した一次ソース

この記事の記述は、次の一次ソースと照合しています。更新時に参照先が変わった場合は一覧も更新します。

  1. support.claude.com/en/articles/9517075-what-are-projects
  2. support.claude.com/en/articles/9519177-how-can-i-create-and-manage-projects
  3. info.atcoder.jp/entry/llm-rules-ja
この記事を共有:XはてブLinkedIn