公開後にセルフコードレビューをして、10件の指摘を直した話
ポートフォリオサイトを公開したあと、Claude Code（Anthropic製のコーディングエージェント）の/code-reviewコマンドを使って、コード全体（初回コミットから現在まで）を対象にセルフコードレビューを行いました。レビューの観点設計・上がってきた指摘の取捨選択・実際の修正判断は自分で行い、実行部分にAIエージェントを使う形です。この記事では、どんな観点でレビューを組み立てたか、実際に見つかった指摘とその判断・修正内容をまとめます。
なぜ公開後にレビューをしたか
見た目が動いていることと、実装として正しく・安全に動き続けることは別の話です。特に今回のサイトは、記事本文をそのままHTMLとして描画する箇所（X/Instagramの埋め込み変換）や、静的書き出し前提の一覧・ページネーションなど、入力や件数の変化で壊れやすい箇所がいくつかありました。公開して終わりにせず、実装済みのコードに対して一度レビューの目を通す工程を挟むことにしました。
レビューの進め方
/code-reviewコマンドには、1回のレビューで複数の観点それぞれを独立したエージェントに担当させ、候補となる問題点を並行して洗い出させる機能があります。今回は次の8つの観点を指定しました。
- 差分の全行読解 — 変更した行すべてについて、どんな入力・状態・タイミングなら誤動作するかを検討する
- 削除された処理の追跡 — 消えた処理が守っていた前提条件を、新しいコードのどこかで引き継げているか確認する
- 呼び出し元・呼び出し先の整合性 — 変更した関数の呼び出し元・呼び出し先で、新しい前提や返り値の変化に対応できているか確認する
- 車輪の再発明チェック — 既存の共通処理を使わず似た処理を再実装していないか
- 過剰な複雑さのチェック — 不要な分岐、コピペ、深いネストが残っていないか
- 無駄な処理のチェック — 重複した計算や、直列にする必要のない処理がないか
- 実装の深さのチェック — その場しのぎの特別扱いになっていないか
- プロジェクトのルール順守 — このリポジトリで決めているルール（CLAUDE.md）に反していないか
各観点で上がってきた候補は、さらに別のエージェントに1件ずつ「本当に問題として成立するか」を検証させ、最終的に10件の指摘に絞り込みました。ここから先は自分の作業です。10件それぞれについて実際にコードを読んで内容を裏取りし、直すもの・保留するもの・仕様変更が必要なものを判断したうえで、修正を実装しました。
見つかった指摘と対応
10件のうち、実装上のリスクが大きかったものをいくつか紹介します。
URL判定の正規表現が意図しないドメインにマッチする
本文中のURLをX（旧Twitter）やInstagramの埋め込みカードに変換する処理で、URLに「x.com」という文字列を含むかどうかで判定していました。このままだと、たとえば "flex.com" のような無関係なドメインの一部分にも一致してしまいます。ドメインの直前を「文字列の先頭」「//」「www.」のいずれかに限定する形に直し、無関係なURLを誤って変換対象にしないようにしました。
取得件数の上限と総件数の取り違え
実績一覧の取得処理で、1回のAPIリクエストで取れる上限件数（100件）を、そのまま「全件数」として一覧のページ数計算に使っていました。この作りだと、実績が100件を超えた時点で101件目以降が一覧やsitemapから静かに漏れる状態になります。APIが返す実際の総件数を使うように直しました。
個別記事の取得失敗がビルド全体を止めてしまう
記事詳細ページの本体側に、記事取得が失敗した場合の処理が入っておらず、1記事でも取得エラーになるとビルド全体が失敗する作りになっていました。その記事だけを404として扱い、他の記事のビルドに影響しないようにしました。
メール送信の一部失敗で通知メールが重複する
お問い合わせフォームは、問い合わせ通知（自分宛）と自動返信（送信者宛）の2通を送っています。この2通を1つのエラー処理でまとめて扱っていたため、自動返信だけが失敗した場合も「送信失敗」としてユーザーに再送信を促してしまい、既に届いている通知メールが再送信のたびに重複する状態でした。通知メールが届いた時点で送信成功として扱い、自動返信の失敗はユーザーへの再送信を発生させない形に直しました。
AIの提案をそのまま採用しなかった例
指摘の一つに、パブリックリポジトリのデプロイ設定ファイルに、実際の案件名を示唆しうる記述が残っているというものがありました。Claude Codeはこれを一般的な表現に置き換える形で対応しましたが、実際には該当案件は実績として名前を出す許可を得ているものだったため、匿名化はむしろ不要な判断でした。逆に、別の運用ドキュメントに残っていた案件名は、修正案の中で「詳細は別ファイル参照」という注記が付けられましたが、その参照先ファイルにも同じ情報がそのまま残っていることが後から分かり、この注記自体が矛盾していました。どちらも、案件ごとの公開可否という自分しか把握していない情報を踏まえて判断し直す必要があり、機械的な処理では対応しきれない部分だと感じました。
直してみて
今回の指摘はどれも、普段の開発の流れの中では気づきにくいものでした。特にURLの正規表現や件数の取り違えは、実装時点では想定した入力でしか動作確認をしていないため、想定外の入力（無関係なドメイン、100件を超える件数）が来て初めて表面化する種類の問題です。一度立ち止まって、実装した本人とは別の視点でコードを読み直す工程には意味があると感じました。
一方で、何を直すべきか・直さなくていいかの最終判断は、案件の背景や許可関係を知っている自分にしかできない部分でした。AIエージェントに任せたのは「決められた観点で漏れなく候補を洗い出す」作業で、その候補をどう扱うかは自分の役割として残しておく、という分担が今回はうまくいったと思います。
ソースは公開しています
今回の指摘・修正を含め、このサイトのコードはGitHubで公開しています。サイトのリニューアル自体の経緯は「ポートフォリオサイトを Next.js + microCMS + Xserver でリニューアルしました」にまとめています。