Codex Plusで使い方を見ていて特に面白いと感じたのは、プロンプトの書き方よりも、むしろ使うタイミングのほうだった。
5時間枠や週間上限の残りが3〜5％くらいになると、私はもう小さな依頼には使わない。むしろ逆で、事前に準備してある複数のプロジェクトに対して、いちばん大きなエンジニアリング作業を走らせるようにしている。
たとえば、TypeScriptへの全面移行、リポジトリ全体のESLint整理、コードベース全体にわたる深いバグレビュー、大規模なリファクタリングなどだ。普段なら気軽に投げるには重すぎると感じる種類の作業である。
この使い方に変わった理由
理由は単純だ。可視上の上限が尽きたように見えたあとでも、Codexが作業を続けているように見える場面を、私は一度ではなく何度か経験した。セッションは終わったように見えても、タスクは前に進み、場合によってはそのまま完了する。
もちろん、これを製品仕様として断言したいわけではない。あくまで、何度か繰り返し体験したことで、自分の使い方が変わるほど印象に残ったという話だ。このパターンに気づいてからは、残り数％を守るべき余力として見ることがなくなった。むしろ、最もコストの高い仕事を起動するベストな瞬間だと考えるようになった。
今は残りをどう使っているか
以前のように、安全で軽いプロンプトに最後の枠を使うのではなく、今は高負荷の開発作業を開始するための時間帯として使っている。具体的には次のようなものだ。
- TypeScriptへの全面移行
- リポジトリ全体のESLint整理
- 大規模コードベースの深いバグレビュー
- 構造レベルの大きなリファクタリング
大事なのは準備ができていることだ。このやり方は、プロジェクト側の準備が整っていて、やるべき作業が明確なときほど効果がある。そういう状態なら、残りの枠を小さな依頼に使うほうが、むしろもったいなく感じる。
なぜ重要だと感じるのか
Codex Plusのようなツールは、単に性能が高いかどうかだけで決まるものではない。どのタイミングで労力を投下するかでも、実際の価値はかなり変わる。少し時間の使い方を変えるだけで、同じ上限から得られる実用的なリターンが変わることがある。
私にとっては、製品に対する感覚そのものが変わった。残り数％は、もうセッションの終わりではない。迷いをやめて、いちばん重い仕事をツールに渡すべき瞬間になった。
正直に言えば、可視上の上限が切れたあとでも、Codexがまだこちらの代わりに働いてくれているように感じることがある。これが意図された挙動なのか、単に一部のタスクが実運用上そう完了するだけなのかは分からない。それでも、十分に有用だったので、今ではこの前提でワークフローを組んでいる。
開発者にとっての実践的な示唆
もしCodex Plusをソフトウェア開発に使っているなら、残り上限の使い方を一度自分で試してみる価値はあると思う。最後の数％は慎重に使うべきだと決めつける必要はない。少なくとも私の場合は、逆の発想のほうがうまく機能した。
特に、移行作業、lintの整理、大規模レビュー、複数リポジトリにまたがるリファクタリングの場面で、ほかの開発者も同じ傾向を感じているのかはかなり気になっている。