コンテンツにスキップ

Codex /fastの「週末効果」をどう読むか: エージェント運用のモード選択

曜日ではなく待ち時間で選ぶ

作業の状態モード選択の基準
結果を見て次の指示をすぐ変える待ち時間が反復を減らすためFast modeを候補にする
長時間の自律実行や夜間処理応答を待つ人がいないためStandard modeを基準にする
監査、設計判断、障害調査モデルと推論量を先に決め、速度は別軸で選ぶ

プルリクエストの修正結果を待ちながら次の指示を考える場面でも、曜日ではなく、待ち時間が次の判断を止めるかで/fastを選ぶ。 対話的な短い反復はFast mode、長時間の自律実行や夜間処理はStandard modeを基準にする。 チームではFast modeの使用率ではなく、完了までの時間、再実行、クレジット消費をタスク種別ごとに記録する。

元ポストが示したのは利用リズムである

Codexを率いるOpenAIのThibault “Tibo” Sottiaux氏は、日本時間2026年8月2日、利用者は週末に/fastをあまり使わないとXへ投稿した。12 投稿は「モデルも週末はリラックスする」という冗談を添えた短い観察であり、対象期間、利用者数、曜日別の値、集計対象のプランは公開していない。

ここから直接読めるのはOpenAI側で平日と週末の利用パターンに差が見えたことまでであり、平日に仕事の反復が多い、週末は長時間タスクへ寄る、単に全体の利用が減るといった複数の説明から原因を選ぶことはできない。

Fast modeは速度とクレジットの交換である

OpenAIの公式資料では、Fast modeは対応モデルの速度を1.5倍にし、Standard modeより高い率でクレジットを消費する機能と定義されている。3 CLIでは/fast on、/fast off、/fast statusで切り替えと状態確認ができる。

2026年8月3日時点では、ChatGPTでサインインした利用者がGPT-5.6またはGPT-5.5を使う場合はStandardの2.5倍、GPT-5.4では2倍のクレジット率になる。3 APIキーでCodexを使う場合はAPIのトークン料金が適用され、このChatGPTクレジット倍率は適用されない。

Fast modeは、別の小型モデルを選ぶ操作でも、推論量を下げる操作でもない。 モデル、推論量、速度は別々の判断軸であり、/fastだけを見て「軽い仕事向け」「難しい仕事には不向き」と決めるのは正確ではない。

クレジット消費はFast modeの有無だけでも決まらない。 OpenAIは、タスクの規模と複雑さ、モデル、実行場所、コードベースの大きさ、長時間のセッションによって使用量が変わると説明している。4 同じFast modeでも、短い修正と大規模リポジトリの調査では負荷が異なる。

待ち時間が判断を止める作業へFast modeを割り当てる

速度へ追加のクレジットを払う価値は、短縮された時間で何が進むかによって決まる。 実務では、タスク名ではなくフィードバックの形で分けると判断しやすい。

作業例Fast modeの便益運用判断
UIの微調整、失敗テストの修正、短い調査結果を見て次の指示を変えられる利用候補
大規模なコード探索、夜間テスト、定期分析実行中に人間が待たないStandardを基準にする
本番障害の切り分け待ち時間の損失が大きい対象を絞ったうえで利用候補
セキュリティ監査、重要な設計レビュー速度より検証範囲が重要なことがあるモデル、推論量、レビュー工程を先に決める

たとえば、テスト失敗の原因を一つ直して再実行し、その結果で次の仮説を選ぶ作業では、応答の短縮が人間の反復を増やす。 一方、夜間に依存関係を調べて翌朝レビューする作業では、完了が少し早くても次の判断は早まらない。

週末を容量予測へ使わない

利用者側から見える応答時間には、モデル処理、ツール実行、ネットワーク、リポジトリ探索、テスト時間が混ざる。 仮に週末の/fast利用が少なくても、自分のタスクが速く終わるとは限らない。

公式資料にも、週末の空き容量、曜日別の優先度、週末向けの料金差は示されていない。 そのため「週末に重いタスクを寄せれば得をする」という運用規則は作れない。 曜日はチームの稼働計画には使えても、Codexの性能保証の代わりにはならない。

チームではタスク種別ごとの結果を測る

Fast modeの利用を管理するなら、オンにした回数より、追加消費が待ち時間の短縮へ結び付いたかを記録する。 比較する条件は、モデル、推論量、リポジトリ、タスク範囲、ツール構成、開始時の作業ツリーとスレッドをそろえる。

  1. 開発者が、作業を対話型、待機型、緊急型のいずれかへ分類する。
  2. 開発者が、難易度の近いタスクを組にし、モデル、推論量、完了条件を固定する。
  3. 運用担当者が、近い時間帯でFast先行とStandard先行を交互に割り当て、各条件を複数回実行する。
  4. Codexが、同じ開始commit、新しいスレッド、同じツール構成から各タスクを実行する。
  5. 運用担当者が、完了時間の中央値と範囲、再実行回数、クレジット消費、レビューで見つかった欠陥を記録する。
  6. チームが、時間短縮が次の判断を早めたタスクだけをFast modeの標準候補にする。

クレジット残量はCodexのSettingsにあるUsage画面で確認でき、プランによってはスレッド単位の使用量も表示される。45 この比較はチーム固有の運用判断を作るためのものであり、Codex全体の性能ベンチマークではない。

週末観測からは性能も混雑も分からない

元ポストは製品責任者による観察だが、公開された分析資料ではない。 母数と集計方法が不明なため、平日と週末の差の大きさ、原因、継続性は評価できない。

本記事のモード選択は、公式仕様と待ち時間の価値から導いたSmartScopeの運用判断であり、OpenAIの推奨スケジュールではない。 Fast modeの対応モデル、クレジット率、管理者設定は変更され得るため、実際の利用前にSpeed資料とUsage画面を確認する必要がある。

この記事をポスト リンクをコピー

関連記事

出典

  1. Tibo Sottiaux, “users use /fast less during the weekend”, 2026-08-01 23:42 UTC. 利用傾向についての本人投稿であり、集計方法は公開されていない。 ↩

  2. OpenAI Forum, Codex is for Everyone: Why Codex Matters Beyond Code, 2026-05-13. ↩

  3. OpenAI, Speed, 2026-08-03参照. ↩↩

  4. OpenAI, Using Codex with your ChatGPT plan, 2026-08-03参照. ↩↩

  5. OpenAI, Codex rate card, 2026-08-03参照. ↩