バグが報告されたとき、自分でコードを読んで原因を特定した。修正した。動くことを確認した。
それとは別に、Codexに検証を依頼した。
同じコードを別のAIに読ませることに意味があると思った。自分が直したと思っていても、見落としがある可能性がある。関係のない別視点から読むと、違うものが見える。
渡した情報
コードをそのままCodexに渡すわけにはいかなかった。
LINE Channel Access Token、Channel Secret、オーナーのLINE UID、スプレッドシートID。これらは公開できない情報だ。
コードのすべての機密情報をプレースホルダーに置き換えた。
LINE_CHANNEL_ACCESS_TOKEN → [LINE_TOKEN]
LINE_CHANNEL_SECRET → [LINE_SECRET]
OWNER_LINE_ID → [OWNER_LINE_UID]
SPREADSHEET_ID → [SPREADSHEET_ID]構造とロジックはそのまま。値だけを隠した状態でCodexに渡した。
5つの指摘が返ってきた
Codexが返した指摘は5点だった。
pushMessage()にmuteHttpExceptions: trueがないsendReminders()でrow[5]をDate型のまま展開している.btn-next:disabledのopacity指定がなく、無効化が見た目に反映されない- フォームの予約送信がGETのクエリ文字列で名前・電話番号をサーバーに送っている
- 404になるfavicon.icoリクエストがサーバーログを汚している
1と2はすでに自分で特定して修正済みだった。指摘と自分の結論が一致した。
3・4・5は見落としていた。
GETからPOSTへの変更
名前と電話番号がURLクエリ文字列に入っていた。
/api/register?name=山田太郎&phone=09012345678&...EC2のアクセスログにこのURLが残る。個人情報がサーバーログに平文で入る。
フロントエンドをPOSTのJSONボディ送信に変更した。EC2のFastAPIにPOSTエンドポイントを追加した。GASへの転送は引き続きGETだが、サーバー間通信なのでアクセスログには残らない。
外部視点の価値
自分が直した箇所については確信があった。ただ、コード全体を俯瞰する余裕は修正作業中にはない。
「自分が見ていなかった部分」を短時間で洗い出せたのはCodexを使った価値だった。特にセキュリティに近い観点（個人情報のGET送信）は、動いている間は問題として浮かびにくい。
コードレビューを人間に頼むのと似た役割だ。書いた本人には見えにくいものが、別の目には見える。
*シンプルシステム株式会社 代表 伊藤勝彦*