リポジトリ監査283件の修正計画に回答し、Codexの容量不足エラーは聞かずにやり直す運用にした日(戦術ボードのシーン分割とWorkersの確認つき)

開発mdx-playground

リポジトリ監査283件の修正計画に回答し、Codexの容量不足エラーは聞かずにやり直す運用にした日

修正計画書のセクション17には、選択肢が2つ書いてあった。 非公開サイトを Access アプリケーションの対象に加えるか、該当ブランチのデプロイを削除するか。 ただ、削除しても、デプロイし直せば同じ穴がまた開くという。 「そうなんだ。じゃあ Access の対象に加えますか」と返して、緊急対応がほかに何が残っているかを聞いた。

この日は、前日にリポジトリのデューデリジェンス(DD)で出た283件を修正計画に仕立て、自分が答えるところまで進めた。

SEC-17は、dry-runを見てから本番へ

Access アプリの今の設定を読ませ、変更内容の dry-run を作ってもらった。 本番の Cloudflare 設定を書き換えるので、実行の前に OK を求められた。 緊急対応は、SEC-17 のほかに4件あった。

y と返すと更新が通り、未認証の GET で確かめてもらった。 続く SEC-03 は、devtools を無効にして、dev で 404 が返るところまで進んだ。

SEC-02 だけは進まなかった。 Claude Code の自動許可判定が、Claude 自身による権限設定の書き換えを止めたからだ。 この件は、あとで自分の手で片付けることになる。

「コミットして」と頼むと、2件入った。 devtools を止める変更と、DD のレポート本体および観点別のファイルである。 コミットのゲートは OpenAI のキーらしき文字列に反応したが、中身は sk-hynix で始まるパスで、秘密ではなかった。

283件を14本の計画書にする

レポートから283件の ID 一覧を作らせ、修正計画を書くワークフローを、同時に5体までに絞って起動し直してもらった。 途中で返事が英語で続いたので、「ごめん、日本語で返して」と頼んだ。

計画書は観点ごとに14本できた。 計画書の ID 見出し、Claude の判定ファイル、Codex の最終回答の3つが、それぞれ283/283そろうことを数えて確かめてもらった。 顧問先名や非公開 URL の検査も通した。 非公開の IP が見つかったが、どれもテストの例示値だった。

Codexが「モデルの容量不足」で止まった

14本を束ねる全体計画書と、自分が決める事項の選択フォームを作ってもらった。 全体計画書は、自分に見せる前に Codex のレビューを通す。

1回目は、計画書を読んでいる途中で止まった。

ERROR: Selected model is at capacity. Please try a different model.

OpenAI 側の、モデルの容量不足である。 最終判定まで届かなかったので、issue に記録して再実行してもらった。 2回目は、14本の計画書を全文まとめて出力させず、必要な箇所だけを読むよう指示を変えている。

OpenAI 側のこのエラーは、よくツイートされている。 だから「そのエラー出たらちょっとやり直してほしいですね」と伝えた。 容量不足なら聞かずにやり直す運用にして、Codex レビューの手順書にも書き足してもらった。 issue には、再試行は最大3回、1本ずつと残っている。 これで、次のセッションからも同じように動く。

2回目のレビューは最後まで通った。 283件に記載漏れはなかった。 ただし重大な指摘が5件あり、判定は「要修正」だった。 根拠の行を Claude に確かめさせると、5件とも妥当という判断だった。

一つはタイムライン画像の経路である。 画像は、絞り込んだログを通らずに元の履歴を直接読む。 そのため、許可リストにない名前がそのまま画像に出る。 最低限の匿名化を、第1波へ前倒しした。

直したあとの全体計画では、決める事項が45件あり、そのうち D1〜D5 が第1波を止めている。 Codex の再レビューで、5件とも解消した。

選択フォームと、止められたサーバー

8899番ポートは別のセッションが使っていたので、止めずに別のポートで起動してもらった。 45件すべてに3択のカードが描かれていることを DOM で確かめてから、Chrome に開いてもらった。

ここで「一旦計画書の進捗を更新しといてください」と頼んだ。 私が回答する、という段階の進捗である。 全体計画書の冒頭に進捗の節を作ってもらい、コミットも頼んだ。 2件入り、push はしていない。 1件は、修正計画14本と判定14本、全体計画の md と HTML、決裁の JSON を合わせた31ファイルだった。

そのあと、フォームのサーバーが止まった。 PC のメモリが足りなくなり、Claude Code が裏のサーバーを止めたのだという。 回答はまだ送っていなかったので、失ったものはなかった。

45件のうち、推奨と違ったのは1件

コンテキストが尽きてセッションが引き継がれたあと、45件に答えた。 「これ一応答えたんで、見てください」と渡すと、44件が推奨どおりだった。

推奨と違ったのは D29 だけである。 図2点を、記事と同じ非公開の置き場へ戻す B を選んだ。 9月17日の「公開用フォルダーに置いてよい」という指定は、この回答で置き換わる。 図は次の本番デプロイで R2 から消え、それまでは今と同じく公開されたままになる。

自由記述を書いたのは D35 だけだった。 推奨の A は、本番の死活と公開待ちの監視を GitHub Actions で毎朝回す案である。 そこに「GitHub Actionsは、今ね、全部エラーになってんすよね。リミットが出てて。」と書いた。

課金の利用量 API で裏を取ってもらうと、こうだった。

  • 個人アカウントの private リポジトリは、Actions の無料枠(Linux で月2,000分)を全リポジトリで共有している
  • 9月と10月は、それぞれ別のリポジトリ1本が枠を使い切っていた。mdx-playground はどちらの月も0分だった
  • mdx-playground の直近の赤は pnpm/action-setup の失敗で、枠切れとは別の原因だった

推奨の A は、無料枠に収まることを前提にしていた。 D35 はもう一度決めることになり、手元の朝の処理に足す B に決め直した。 毎朝の /make-diary に Step 8.7 として監視を足す形である。

書き直した節は Codex に再レビューさせた。 1回目は、Codex の実行ファイルを古い版(5月版)と取り違えて呼んでいた。 正しい版でやり直し、致命的な指摘はなかった。 観点別の計画書の冒頭には「決裁の結果は全体計画が正」と1行ずつ入れてもらった。

許可ルール11件は自分の手で外した

先に止まった SEC-02 は、ここで片付けた。 Claude は、Claude 自身の権限設定を書き換えられない。 そこで、許可を外すスクリプトを用意してもらい、私が手で実行した。

removed 11 of 11 [] allow 245 deny 10 ask 17

allow から11件が外れ、設定は allow 245件、deny 10件、ask 17件になった。 結果は、Claude に設定ファイルで確かめてもらった。 Bash(git *) のような包括許可はまだ残るので、その絞り込みは第2段に回る。

このあと第1波の実装に入った。 手元でできる作業はコミットまで済んだが、本番デプロイは保留にした。

並行セッション:戦術ボードのシーン4-7を分けた

別のセッションでは、サッカーの戦術書にある図96点を動く戦術ボードにする、dev 限定のページを作っていた。 116ファイルのコミットが入ったところで、「分割してレビュー回してくれませんか」と頼んだ。 コミットを6つのまとまりに分け、Codex に1つずつ順にかける段取りで、20〜40分の見込みだった。

1回目は失敗した。 作業用フォルダの置き場所のパスが長すぎて、Windows のパス長の上限(260文字)を超えたのだ。 短い場所に、レビューするファイルだけを出す方式に直してもらった。

レビューを待つあいだ、シーン4-7 の画面を眺めていて引っかかった。 展開1、2、3のあいだで、ディフェンダーがボールを持ちながら入れ替わっている。 展開としてはあり得ない。 連続させる必要がないなら分けませんか、と頼んだ。

画面を確かめてもらうと、表示が崩れていた。 サーバー側の描画が古いコードのままで、画面の描き分けが食い違っていた。 開発サーバーの状態を確かめたうえで、シーン1、2、3に分けてもらった。 続いている展開は、今までどおり1本でつながっている。 たとえば 4-7 のシーン2は、展開3に当たる。

分割レビューの指摘は、まとまりごとに直していった。 A(処理の本体とテスト)の2件は、連続パスの重なりと、長い距離の移動の速さだった。 直したあと、テスト770件が通った。 最後に全テスト(276ファイル、22,036件)を通し、シーン分割と一緒に 106a1f36 でコミットしてもらった。

Workersの容量は問題なし、ただしそのままでは出せなかった

最後に聞いた。 「Workersのその容量とかって問題ないですか?これデプロイしちゃっても問題ないやつですか?」

容量は問題なかった。 ただ、直す前のページは、そのままデプロイしてよい形になっていなかった。 ページを本番に出ない作法に書き換え、dev では今までどおり動くことを確かめて、134c05a2 でコミットしてもらった。

その後、起動し直してもらった開発サーバーも、メモリ不足で Claude Code に止められた。 止まったのはサーバーだけで、コードとコミットには影響がなかった。

学び

  • 外部 AI の容量不足は一時的に起きる。出たら聞かずにやり直す、と手順書に書いておけば、次のセッションでも同じように動く
  • 推奨案を並べた選択フォームでも、自由記述欄が前提の崩れを拾った。D35 の推奨は無料枠に収まる前提だったが、別のリポジトリの消費でその前提が崩れていた
  • 自動許可判定は、Claude 自身による権限設定の書き換えを止める。権限を絞る変更は、スクリプトを用意してもらい自分の手で流す

セクション17は、Access の対象に加えた。 D29 の図2点は、次のデプロイまでは公開されたままだ。

#Claude Code#Codex#Cloudflare Access#セキュリティ#修正計画#権限設定