公式の学習サイト「Claudeアカデミー」のClaude Code 101（全12レッスン）、7本目のメモです。

これまでと同じく、公式レッスンをClaude Codeに渡し、日常のたとえで説明し直してもらいました。今回も台所のたとえで、できあがった料理を出す前に確かめる話です。レッスン本文はこちら：Claude Code 101 レッスン7「コードレビュー」（Claudeアカデミー公式）

レッスン6のメモはこちら：Claude Code 101 レッスン6｜「コンテキスト管理」を台所の作業台のたとえで整理

この記事の要点

• Claude Codeの「できました」という報告は、うそではなくても、全部とは限らない。/diff で変更そのものを見る
• 別の目で確かめるなら /code-review。作業台がまっさらな別のClaudeが点検して、見つけたことを報告する
• 指摘は「今すぐ直す・理由を聞く・そのままにする」の3つに分け、直してもらうときは証拠も見せてもらう

ポイント① 報告メモ：うそではなくても、全部とは限らない

コードレビューとは、Claude Codeがファイルをどう書き換えたかを点検することです。点検してから、その変更をそのまま使うか、やり直すかを決めます。

Claude Codeは、頼まれた作業を終えると短く報告してくれます。ただ、その裏では、小さなものから大きなものまで、いくつものファイルが書き換わっていることがあります。報告に書かれたことがうそではなくても、書かれていない変更が混ざることがある。

しかも、変更を書いて説明した本人（同じセッション。セッションは、Claude Codeとのひと続きの会話のこと）は、その変更を判断するのに一番向いている審査役ではない、とレッスンにあります。料理でいえば、作った本人は自分の料理に甘くなりがち、ということです。

そこで、報告メモではなく、台所そのものを見ます。

/diff：前と後を並べて見る

diff（ディフ）は、変更の「前」と「後」の差のことです。ファイルごとに、消えた行と増えた行を並べて見せます。料理でいえば、作る前と後の台所の写真を並べて、何が減って何が増えたかを1か所ずつ見比べる感じです。

/diff は、入力欄に打ちこむ合図です。まだ記録（コミット。レッスン5のメモで出てきました）していない変更が、ファイルごとに表示されます。

/diff と、あとで出てくる /code-review は、git（ファイルの変更の記録をつける道具）の記録を読んで動きます。何も表示されないときは、gitの準備がまだなのかもしれません。その場合は、次の作業の前に、Claude Codeにgitの準備と最初のコミットを頼んでおきます。

ポイント② 見どころは3つ：頼んでいない変更・ゆるくなった味見・新しい道具と直書き

レッスンでは、毎回必ず見ておきたい場所が3つ挙げられています。

頼んでいない変更

カレーを頼んだのに、調味料の棚まで並べ替えてある。Claude Codeでいえば、作業のついでに設定の値が変わっていたり、頼んでいない部分が書き換えられていたりすることです。

ゆるくなった味見（テスト）

アプリを作るときは、「ちゃんと動くか」を自動で確かめる仕組みを一緒に用意しておくことがあります。これをテストと呼びます（レッスン5のメモでは「チェックリスト」として紹介しました）。料理でいう味見です。

テストがある作業では、Claude Codeが「テストに合格しました」と報告することがあります。困るのは、合格しやすいように、テストのほうが飛ばされたり、消されたり、甘くされたりしていることです。「塩が効いているか」を確かめていた味見が、「何か味がするか」に変わっていたら、合格しても安心できませんよね。テストを用意していないなら、ここは飛ばしてかまいません。

新しい道具と直書き

1品のためだけに、鍋を買い足してきた。Claude Codeでいえば、1つの働きのためだけに、外から出来合いの部品（パッケージと呼びます）を足すことです。

もう1つは、直書き（ハードコードと呼びます）です。たとえば、アプリが情報を送る先の宛先。本当は「試しに動かすとき用」と「本番用」を切り替えられるように、プログラムとは別の場所に置いておくものです。それをプログラムの中に直接書きこんでしまうのが、直書きです。

レッスンの例では、試しに動かすとき用の宛先が直書きされたままでした。これだと、本番でお客さんが登録しても、その情報が試し用の宛先に送られてしまいます。料理でいえば、出前の届け先が、試作のときに書いた「自分の家」のままになっているようなもの。お客さんに届くはずの料理が、全部自分の家に届いてしまいます。パスワードのような大事な文字を直接書きこむのも、同じ仲間です。

全部だめなら /rewind

変更がまるごと間違っていたら、/rewind で巻き戻せます（入力欄が空のときにEscキーを2回押しても同じ）。その変更を生んだ頼みごとを選び、「Restore code and conversation」（コードと会話を元に戻す）を選ぶと、頼む前の状態に戻ります。

ただし、Claude Codeがパソコンに直接打ちこんだ命令（部品のインストールなど）で変わったファイルは戻りません。買ってきた鍋は、時間を巻き戻しても家に残る、ということです。

ポイント③ /code-review：台所にいなかった人に味見してもらう

レッスン5のメモで、コミットの前に別のClaudeに点検してもらう、と書きました。その点検役が /code-review です。

長く作業したセッションの作業台（レッスン6のメモで出てきたコンテキスト）には、ここまでの経緯がたくさん乗っています。「玉ねぎは30分炒めた」「途中で水も足した」。作業中は役に立つ記憶ですが、点検のときには先入観になってしまいます。

/code-review は、作業してきたのと同じセッションの入力欄に打ちこむ合図です。すると裏で、作業台がまっさらな別のClaudeが変更を点検し、終わると結果がその会話に届きます。台所にいなかった家族に、スプーン1本で味見してもらうようなもの。経緯を知らないので、「ちょっとしょっぱいよ」と気づいたことをそのまま言ってくれます。

家族は言うだけで、頼まない限り鍋に水を足したりはしません。/code-review も、見つけたことを報告するだけ。頼まない限り、ファイルは書き換えません。

点検には数秒から数分かかり、ふつうの作業と同じように使用量にも数えられます。なので、二度見する価値のある変更のときに使います。

合図を覚えていなくても、「さっきの変更をレビューして。問題を報告して。まだ何も直さないで」のように、ふつうの言葉で頼めます。Claude Codeが点検を始めずにその場で答えてしまったら、自分で /code-review を打ちます。

どこまで念入りに確かめるか

1行だけの小さな変更なら、/diff をさっと見れば十分なことがほとんどです。念入りにするのは、変更が大きすぎて頭に入りきらないとき。パスワードのような大事なものや、消すと戻らない作業に関わるとき。それから、人に作業を渡す前です。こういうときは、自分の目と /code-review の両方で確かめます。

ポイント④ 指摘は3つの山に分ける

点検から指摘がいくつか返ってきても、全部をすぐ直す必要はありません。レッスンでは、3つの山に分けることをすすめています。

今すぐ直す

本当に困る問題です。レッスンの例では、テストが飛ばされていて、入力欄が空のまま送っても合格してしまう状態になっていました。ポイント②の、出前の届け先が「自分の家」のまま（直書き）も、この山です。

直してもらうときは、「直したよ」の言葉だけで終わらせず、証拠も見せてもらいます。「味見の基準を元に戻して。そのあともう一度味見して、結果を見せて」という頼み方です。直しが大きくなったら、もう一度 /code-review をかけます。

理由を聞く

「え、そう？」と思う指摘です。点検する側は変更を初めて見るので、見落とすこともあります。レッスンの例では「メールアドレスの前後の空白を取り除いていない」という指摘が出ましたが、コードを見ると、ちゃんと取り除いていました。

こういうときは、指摘をそのまま引用して、もう一度確かめてもらいます。「塩を入れ忘れていると言ったけど、2回目の味つけで入れているよ。もう一度確かめて、その指摘が正しいか教えて」という頼み方です。

そのままにする

本当だけど小さいことです。料理でいえば、お皿の色がそろっていない、くらいの話。レッスンの例では、文字の色の指定がプロジェクトで決めた書き方になっていない、という指摘でした。急がなくて大丈夫です。あとで、ほかの小さな直しとまとめて直せます。

同じ指摘が何度も出るなら、レッスン6のメモで触れたCLAUDE.md（冷蔵庫の扉に貼っておくメモ）に、ルールとして書いておく手もあります。

学び：Claude Codeの報告は、うそではなくても全部とは限らない。/diff で変更そのものを見て、大事な変更は /code-review で別の目にも見てもらい、指摘は3つの山に分けて扱う。

それでは、また次の記事で。六弦ライダーでした。

---

執筆時点の環境：Claude Code（モデルはClaude Opus 5.5）／2026年10月