記事一覧この記事の内容
AI でコードを書いていて、公開前に誰もそのコードを確認していないなら、この記事はあなたのためのものです。チームのジュニア開発者から届いた変更を、私たちがどうレビューしているかをまとめました。確認作業のほとんどは Claude Code が行います。全体の流れは 45 秒の動画で、真似できる細かい部分はこの記事で紹介します。
最近の例です。正社員の求人だけに出すはずのキャンペーンバナーを追加した変更で、1 回目のレビューがパートの求人にも表示されていることを見つけました。修正後、Claude はサイト上の求人 169 件すべての雇用形態を約 2 秒で数えました。正社員が 94 件、パートが 75 件です。続けて、正社員とパートの求人ページを 3 つの画面幅で開き、バナーがそのルールどおりに出ているかを確かめました。人の手で開いたページは 1 つもありません。
面白いのは、AI がコードを読めることではありません。コードを読むだけでは分からないこと、つまりページの見た目は正しいか、動きは正しいか、クライアントの依頼どおりかを確かめられることです。
始める前に、正直に一つ書いておきます。何を公開するかを AI が決めることはありません。AI は確認してまとめるだけで、それを読んで判断するのはシニア開発者です。Claude がマージを実行するのは、私たちがそう指示したときだけです。
レビューの最後に手に入るもの
リンクが 1 つ。その先のページには、変更を公開できる状態か、デスクトップとスマホで何が変わったか、それぞれの問題の平易な説明、そして開発者が直すためのプロンプトがまとまっています。
平均で約 12 分。 直近 9 件のレビューで、Claude に頼んでからレポートが公開されるまでの時間です。変更の内容によって変わり、小さな変更は 3 分、7 つの PR をまとめて確認したときは 19 分、5 つの画面幅と録画つきの一番大きな変更は 29 分でした。
私たちのハンドブックでは、すべての変更に AI レビューを行うことが標準です。届く変更の多くはジュニア開発者からのものなので、レビューには 2 つの役割があります。クライアントの目に触れる前に問題を見つけること、そして開発者が修正から学べるくらい丁寧に説明することです。
ステップ 1 · 読み込んで、動かす
Claude Code は変更されたファイルをすべて読み、サイトを起動して動作確認（サニティテスト）をします。ビルドできるか、ページが表示されるか、エラーが出ないか。そのあとは訪問者と同じように、デスクトップ幅とスマホ幅で、変更に関係するところをクリックしながらコンソールを確認します。プロジェクトにテストがあれば、それも実行します。
「変更前」がベースブランチとは限りません。 古い問題が新しい変更のせいにされないよう、変更前のバージョンでも同じ確認をします。ある修正ではステージングでバグを再現できなかったため、本番サイトを「変更前」として使いました。
ステップ 2 · クライアントの原稿と照らし合わせる ― 急ぎがちな工程
クライアントからいただいた内容を表示するページなら、Claude は名前、住所、リンクまで 1 項目ずつ照らし合わせます。あのバナーのようにデータによって表示が変わる変更では、いくつかを抜き出すのではなく、すべてのデータを確認します。
ステップ 3 · 変更を見せる
見た目が変わるものは、変更前後のスクリーンショットをデスクトップとスマホで撮ります。フィルター、検索ボックス、ログインの流れなど、操作するものが変わったときは、両方のバージョンで同じ手順を録画します。
見るものはスクリーンショットで。使うものは録画で。
ステップ 4 · 開発者向けにまとめる
すべてを日本語と英語で切り替えられる 1 枚の Claude アーティファクトにまとめます。冒頭に判定を置き、指摘ごとにスクリーンショットを添えて説明します。ほとんどの指摘には Claude Code にそのまま貼れるプロンプトを付け、どのレポートの最後にも、次の PR の前に使い回せるプロンプトを載せています。実際に使っているものを、そのまま載せます。
PR を作る前に、この変更をセルフレビューしてください。次を確認して、結果を表で見せてください:1. dev サーバーで変更したページをブラウザで開き、コンソールに新しい Hydration 警告やエラーが出ていないか（Playwright などで確認）2. URL を直接開くだけでなく、ボタンやリンクをクリックしても期待どおり動くか3. リンクやボタンに、スクリーンリーダーで区別できる名前（テキストや aria-label）が付いているか4. 不正な HTML（p の中に p、a の中に a など）や、h1 が 2 つ以上になっていないか5. npm run lint:css-js と npm run lint:html で、新しいエラーが出ていないか問題があれば、直す前に説明してください。
修正が届いたら、すべての確認をもう一度実行し、同じページを更新します。何往復しても、リンクは 1 つのままです。
AI がしないこと
何を公開するかは決めません。判断してその責任を持つのはシニア開発者です。そのページがクライアントの望んだものかどうかも、AI には判断できません。そして、確認していないことは確認していないと書きます。新しいセクションの内容がまだ CMS に入っていなかったときは、レポートにそのことを明記し、代わりに 5 ケースのテスト手順を残しました。
それに、AI は間違えることもあります。ある変更を「マージしてはいけない」と判定したとき、私たちが反論すると、AI は判定を取り下げました。空のセクションは合意済みの仕様で、バグではなかったからです。だからこそ、すべてのレポートをシニア開発者が読みます。
同じエージェント、別の仕事
始まりは、1 人のジュニア開発者の PR でした。今では同じ仕組みで、ほかにもいくつかの仕事をしています。
- マージのあと。 マージした複数の変更をまとめてステージングで確認し、本番サイトと比べます。リリース前に 22 項目すべてが合格しました。
- 複数の PR をまとめて。 Claude はまずテスト用のコピーですべてをマージして PR 同士の衝突がないか確かめ、PR ごとに開発サーバーを立ち上げました。同時に 7 つです。
- バグ修正。 修正前のコードでは失敗し、修正後は成功する新しいテストに加えて、ユーザーが実際にたどった手順を変更前と変更後で録画しました。
- クライアント向けのレポート。 新しい内容をクライアントの資料と一字一句照らし合わせ、変更前後のスクリーンショットを添えて、コードを読まない人に向けて書きました。
形はいつも同じです。動かせる本物の環境、確認する項目のリスト、そして書く相手が 1 人。
ほかのチームは、また別の方向に進めていて、これからどうなっていくのか楽しみです。Anthropic の Claude Code の Code Review では、複数のエージェントが差分を読みます。Builder.io の Quality Review Agent は PR ごとにブラウザでテストし、見つけたバグを動画で再生できます。alexop.dev の AI QA エンジニアは、PR にラベルが付くと Playwright で確認を走らせます。私たちのやり方の特徴は、まだほかではあまり見かけない 2 点です。ページをクライアント自身の原稿と照らし合わせること、そしてレポートを、変更した開発者が学べるように書くことです。
ツールよりも大事なこと
信じる前に動かす。 読んで問題なさそうなコードでも、間違ったページにバナーを出すことがあります。
変更を見せる。 文章では長くなる説明も、変更前後のスクリーンショットなら数秒で伝わります。
修正をプロンプトとして書き残す。 直す人には、理由のすぐ下に、そのまま貼れるものを渡しましょう。
どれも、ベテランエンジニアがすべての行を見張る必要はありません。必要なのは、確認する習慣と、飽きない AI です。
開発者向け
- AI レビューは Impl Review の段階で、Claude Code の
/code-reviewプラグイン（セキュリティに関わる変更にはasvs-auditも）を CI と並行して実行します（コードレビュー基準）。 - Playwright でデスクトップ幅と 390px、コンソールの Hydration 警告、Biome、markuplint、
git merge-treeを、すべて基準となるバージョンと比べて確認します。 - リポジトリにある場合は、ユニット・結合・E2E テスト、
tsc --noEmit、本番ビルドも実行します。バグ修正の新しいテストは、まず修正前のコミットで動かしてバグを再現します。