チボ祭り、本気の消費はどんなもの？――Astraウルトラと4担当で、週間残量を燃やしてきた🔥🔥

2026年10月16日 00:00

こんにちは黒パグです🐾

「緊急ウルトラたすくかいし！！！」

2026年10月15日。私のチャットに、非常に落ち着きのない業務命令が残っている。

まず、チボって誰？

「チボ」は、OpenAIのThibault “Tibo” Sottiaux氏のこと。Codexの開発を率いてきた人物で、現在はOpenAI公式の紹介で「Head of Product & Platform」とされている。Codexは、コードの読み書きや修正など、ソフトウェア開発の作業を手伝うAIエージェントだ。

利用枠のリセットでも知られる人で、私にとっては、その予告を見たら残タスクを確認する合図になっている。今回の「祭り」は、その予告をきっかけに私が勝手に始めた作業実況で、公式イベント名ではない。

ここでいうリセットは、利用枠を回復させること。会話履歴や制作したファイルを消す話ではない。残量計が満タンに戻るなら、その前に重い仕事を進めよう――という、たいへん都合のよい祭りである。

なお、添付イラストの白髪キャラは案内役。チボ氏ご本人の似顔絵ではありません。

きっかけは、チボ氏のリセット予告だった。利用枠が回復するなら、その前に残っている重い作業を進めておきたい。普段なら慎重に割り振る計算資源を、いま必要な仕事へまとめて投入する。

こうして、私のところで勝手に始まったのが「チボ祭り」である。

何を祭っているのか。
週間利用残量である。

しかも今回は、Astraのウルトラ設定。エージェントの使用も許可し、独立4担当と司令塔で鑑識プロジェクトの残件を回した。

会話ログをたどると、主催者はたいへん元気である。

「エージェント使用許可　回せ！！！」

「よし次のタスクを回せ！」

「燃やせ燃やせ」

現場に必要なのは、まず落ち着いた人間なのではないか。
私しかいない。困った。

残量メーターを見てみよう

まず、消費の勢いから。

画面と会話の記録を並べると、次のようになる。時刻はすべて日本時間。残量は、その時点で画面に表示されていた値である。

14:09　74%　ホーム画面のCodexウィジェット
14:13　66%　アプリの利用状況画面
14:17　64%　アプリの利用状況画面
14:32　57%　ホーム画面のCodexウィジェット
14:55　49%　作業チャット内の本人報告
15:11　39%　アプリの利用状況画面
15:16　100%　アプリの利用状況画面

14時09分から15時11分まで、62分で35ポイント減った。

別の表示面をまたぐので、反映のずれもあり得る。アプリの利用状況画面同士で比べても、14時13分の66%から15時11分の39%まで、58分で27ポイント減っている。

だいたい1時間で、週間枠の4分の1以上が動いた。

しかも、当日の私の契約は利用枠5倍のProである。小さな残量計を必死に削っていた、という話でもない。

とはいえ、この数字を「何億トークン」「API料金なら何円」と機械的に変換することはできない。ここで見ているのは利用枠の残量表示だ。

わかるのは、私の画面で青い棒がかなりの勢いで短くなっていたことと、それを見ている私が妙に楽しそうだったこと。

「46%ちゅうちゅうすってるなー」

利用者の感想として、どうなのか。

何をそんなに回していたのか

仕事は、制作中の「鑑識5.1」の残件整理と修復である。文章の特徴を調べる仕組みについて、プロンプト、実装、測定、証拠の対応を詰めていた。

たとえば、二つの改稿候補がある。

一方には「簡易モードで余計なツールを起動しない」という改善が入り、もう一方には「原文を変えず、古い根拠が読めない場合は保留する」という改善が入っている。

両方とも必要だ。しかし、片方の全文をもう片方へ貼れば終わり、とはいかない。ある条文を直すと、別の場所に古い指示が残る。過去に成功した記録を保存することと、その値を今回の採点へ使うことも違う。

そこで、起動とモード、長さと入口、原文と根拠、独立した反証レビューに担当を分け、司令塔が突き合わせる。

初段でできたのは設計文書5本。保存と独立した再取得の照合は6件中6件一致。この段階では、製品コードの変更も、製品試験も、実チャットへの送信も行っていない。

ここを混ぜると、「試験案ができました」が、いつのまにか「試験に合格しました」になる。

AIを使う仕事で、かなり嫌な変身である。

さらに、測定器が時刻の逆転を通してしまわないか、対象の本文が違っても正常扱いされないか、処理後にログ保存が失敗したときに単なる失敗として再実行してしまわないか、といった箇所を詰める。

読めば地味だが、作業は重い。仕様を読むだけで済まず、コードの分岐と期待する記録を行ったり来たりするからだ。

その間、私の実況はこうである。

「残り49% あと1時間！回せ！！」

人間だけ、だいぶ仕様が雑。

祭りの最中に、証拠の不一致が出る

続く工程では、オフライン側の隔離した修復候補を実装し、18ケースを初回実行した。

ここで、景気よく全件成功とはならなかった。総合判定はPARTIAL。部分完了である。

問題になったのは、あるケースの親側ログだった。

保存受領の記録では32,741バイト。
残っている現物は7,563バイト。

長さもハッシュも一致していない。

鑑識を作っている最中に、鑑識の証拠を確認する仕事が増えた。まあ、そういうところまで含めて作っているわけだが、祭りの演目としてはなかなか渋い。

ここで期待値を現物に合わせれば、帳簿だけはきれいになる。しかし、それでは確認したかったことが消える。

不一致は不一致として残す。原因は未確定。足りないイベントを想像して埋めない。修復を進めても、古い結果のPARTIALを成功へ書き換えない。

次は、保存した証拠を受け入れる前に照合する仕組みと、別に読み直すための検証側を準備した。新しい17ケースの計画を固定し、関連する14ファイルを保存・再取得して一致を確認するところまで進めた。

ただし、その17ケースは、停止時点では未実行である。

祭りだからといって、未実行のものまで打ち上げてはいけない。

「本気で使う」の中身

今回の作業では、長い文脈を持つAstraウルトラに、複数担当の独立作業を組み合わせていた。

最終的にチャットへ出てくる受領票は、そこまで長くない。だが、その前には仕様の照合、修復案の作成、反例の検討、実装、有限試験、保存物の再確認がある。

画面に表示された回答の文字数だけでは、作業量は見えにくい。

一方で、「ウルトラだから何倍」「担当4人だから正確に4倍」とも、この記録からは言えない。条件を一つずつ分けて測った実験ではないからだ。

今回わかったのは、この構成で実作業を進めていたら、約1時間で残量表示が大きく減った、ということ。そして、担当を増やせば、返ってきた結果の矛盾を確かめる仕事も増えるということだ。

四つの報告が届いたら、四つとも正しいことにして採用する。
それでよければ、司令塔はずいぶん楽である。

現実には、何を読んだのか、どの版なのか、設計なのか実行結果なのか、保存した現物と合うのかを確かめる必要がある。

残量を消費する能力と、成果を確定する能力。
両方が要る。

累計表示も、なかなかおかしい

同日のスクリーンショットには、別の数字も残っていた。

12時14分。プロフィールの累計トークン表示は94.7億。
14時39分。同じ項目が96.9億になっている。

表示上の差は2.2億である。

ただし、これは累計値の二時点比較。集計の反映遅延や含まれる作業の範囲までは、この画面からわからない。先ほどの62分の祭りで、ちょうど2.2億トークンを消費したと認定する数字ではない。

それでも、週間残量の横でこれが増えていると、なかなかの景色になる。

12時14分の画面では55日だった連続利用日数も、14時39分には56日になっていた。集計側には集計側の時間が流れているらしい。

犬は青い棒を見ている。
別の画面では、桁の大きい数字が増えている。

忙しい。

祭りは、39%を残して終わった

15時11分、残り39%。

15時16分、残り100%。

リセットの反映を画面で確認できるのは、この5分間のどこかだ。15時16分ちょうどに処理された、とまでは言えない。

ともあれ、祭りは終わった。

使い切ったわけではない。
39%を残したところで、残量計が満タンに戻ったのである。

私のログには、こう残っている。

「一旦停止リセかかった」

このあと作業を止め、未実行の17ケースと、証拠ログの不一致を残したまま、dotへ渡す引継ぎ指示書を作った。

勢いよく回した一方で、最後に確定したのは「どこまで終わり、どこから終わっていないか」だった。次の担当が最初から掘り直さずに済むよう、固定した資料と一度だけ実行する手順を渡す。

残量の数字だけを見れば、62分で35ポイント。
仕事の中身を見れば、設計から隔離実装、初回試験、不一致の発見、次の検証準備、停止と引継ぎまで。

そして、15時16分の画面には、青い棒が端まで伸びていた。

残り100%。