GPT-6 Astra mediumでは4プロジェクト並行開発のレートが足りなかった

• 日本語

• GPT-6 Astra
• Codex
• AIコーディング
• LLM

#はじめに

GPT-6 AstraをCodexで使い始め、mediumで運用していた。

モデル自体にはかなり良い印象を持った。

難しい実装や調査でも頼りになる。

しかし、実際に日常の開発へ入れてみると、別の問題が出てきた。

自分の使い方では週のレートが全く足りなかった。

#4プロジェクトほど並行している

私のAIコーディング環境では、一つのプロジェクトだけを集中して進めるとは限らない。

4つほどのプロジェクトを並行して触ることがある。

Codex
├─ Project A
├─ Project B
├─ Project C
└─ Project D

それぞれで、

• 仕様を相談する
• コードを調べる
• 実装する
• テスト結果を見せる
• 修正する

というサイクルを回す。

この使い方だと、1タスクあたりの消費量よりも、複数タスクが積み上がったときの総量が重要になる。

#Astra mediumでは週単位で厳しかった

Astra mediumを使っていると、一つのタスクでは特に問題を感じない。

むしろ高性能なので、そのまま使い続けたくなる。

しかし4プロジェクトを並行していると、週の前半から利用量がかなり気になるようになった。

私の場合は、

週の後半まで同じペースで開発を続けられない

という状態になった。

これはモデルの性能とは別の問題だった。

#「賢いモデルを使えば良い」だけではなかった

AIモデルを選ぶときは、どうしても性能を見てしまう。

より難しい問題を解ける。

より正確にコードを書ける。

長いコンテキストを扱える。

もちろん重要だ。

しかしAIコーディングを毎日使う場合は、

そのモデルをどのくらい継続して使えるか

も同じくらい重要だった。

1日に数回だけ使うなら気にならない。

4つのプロジェクトで何時間も使うと、話が変わる。

#サブエージェントを増やせば節約になるわけでもない

複雑なタスクではサブエージェントを使うこともある。

最初は、タスクを小さく分ければ効率が良くなると考えていた。

しかしサブエージェントも別のモデル呼び出しになる。

コンテキストが増えれば、必ずしも利用量の節約にはならない。

並列化によって開発速度は上がっても、消費量まで減るとは限らない。

この点も実際に使ってみないと分からなかった。

#ローカルLLMへの分散も考えた

この問題から、ローカルLLMをAIコーディングの補助に使えないか検討するようになった。

軽い作業だけでもローカルへ流せれば、Astraを本当に必要なタスクへ残せる。

理屈としては分かりやすい。

ただ、開発体験全体を複雑にしすぎると、それはそれで使いにくい。

最終的には、まずCodex側で使うモデルを見直すことにした。

#GPT-5.6 Sol highへ戻した

以前から使っていたGPT-5.6 Sol highへ戻してみた。

すると、自分の使い方ではAstra mediumよりかなり余裕を持って複数プロジェクトを進められた。

モデルごとに利用量の特性が違うことを、かなり強く実感した。

重要なのは、

Astraが悪い

ということではない。

Astraの性能には魅力を感じている。

ただ、4プロジェクトを並行して進める現在の自分の運用では、継続利用のしやすさを含めるとSol highの方が合っていた。

GPT-5.6 Sol highへ戻したあとの運用は別の記事にまとめた。

#まとめ

GPT-6 Astra mediumをAIコーディングで使い続けた結果、自分の使い方では週次レートが足りなかった。

条件はかなり偏っている。

• Codexを日常的に使う
• 4つほどのプロジェクトを並行する
• 調査から実装までAIへかなり頼る

という使い方だからだ。

一つのプロジェクトだけなら評価は変わるかもしれない。

今回分かったのは、AIモデルを選ぶときに性能だけを見ても足りないということだった。

毎日使うなら、継続して使える量まで含めて自分の環境に合うモデルを選ぶ必要がある。