コードを「バグ探し」ではなく「読み味・責務分離」の観点だけで AI（Codex 目線）にレビューさせた回のメモ。勉強のため。
レビューというとバグ指摘を想像するけど、今回は別の角度を試した。「壊れている所」ではなく「今後の自分が読み返すとき、もっと楽にできる所」だけを挙げてもらった。
バグじゃなく「読み味」を見てもらう
守るべき所（owner scope・公開 API ゲート・署名 URL・アップロード検証）は既に入っている前提で、そこは触らない。代わりに「責務がにじんでいる所」「同じ処理が散っている所」を出してもらった。
10 個ほど挙がって、並べてみると論点はほぼ一つに集約された。同じ小さな判断が、複数箇所に散っています。
「同じ判断が散ってる」の具体例
たとえば画像 URL の組み立て。photo.image.url を見て、完全 URL ならそのまま、相対 URL なら request.build_absolute_uri() で絶対 URL にします。
# 散っていた頃（4つの serializer に同じ分岐が書かれていた）
url = photo.image.url
if url.startswith(("http://", "https://")):
return url # 完全 URL ならそのまま返す
return request.build_absolute_uri(url) # 相対 URL なら絶対 URL に変換こう散っているのを、helper を1つ作って各 serializer から呼ぶ形に寄せられます。ただし画像 URL のほうは、まだこの形には直していない（直すならこうなる、という案だ）。
# 寄せるなら、こういう helper に集約する（画像 URL はまだ未対応の案）
def build_media_url(file_field, request=None):
if not file_field: # ファイルが空なら None を返して終わり
return None
url = file_field.url
if url.startswith(("http://", "https://")): # ← URL 判定の本体。この分岐が当時4箇所に散っていた
return url
return request.build_absolute_uri(url) if request else url # 相対 URL → 絶対 URLログイン処理のほうは、これを実際にやってある側だ。ログインが成功したあとに「ログイン済みの証明書」（JWT）を作って返す組み立ては、ログイン手段（Google・Apple）ごと、さらに紡Book（Web）とアプリごとに散りがちになります。
token_json() / set_token_cookies() に寄せてあるので、認証レスポンスの仕様を変えても直すのは1箇所で済みます。さっきの画像 URL が「散らしてから寄せ直した側」なら、こっちは最初から寄せてあった側だ。
どれから着手するか
挙がった指摘を全部やる必要はありません。挙動を変えずに済んで、読みやすさの効果が大きいものから優先度を絞るのが基本の考え方です。画像 URL や OAuth レスポンスのような helper への集約は、出力はまったく変わらないのに、読み返したときの負荷が下がります。逆に「表示テンプレートが4種類以上に増えたら、振り分けを一覧表にまとめる」みたいな指摘は、今が3種類であれば保留で構いません。
大きく作り替えるより、重複している小さな判断を1箇所に寄せていきます。レビューを上から順に潰すのではなく、効くものを選びます。
学びポイント
「同じ判断が散る」は、機能を縦に追加していくほど起きやすいです。
直す判断基準は「仕様が変わったとき、何箇所を直す必要があるか」です。1箇所を変えるだけでよいなら helper に出す価値があります。今は3箇所でも、増える見込みがあれば早めに寄せます。
レビューを上から全部直すより、変更コストの高い重複から先に潰すのが実際的な順序です。
この記事は2026年6月時点の自分の理解で書いています。仕様や認識が変わってる可能性があります。