上位モデルに変えてから気になっていた待ち時間
メインで使っているAIを新しい上位モデル（Gemini 4 Argon）に切り替えてから、
しばらく日々の作業で使っていました。
事前の予想通り、1回のやり取りで消費する利用枠は増えているのですが、
幸い今の契約プランでは上限に引っかかることもなく、その点は問題ありませんでした。
ただ、1回の質問や指示に対して回答が返ってくるまでの処理時間が、
以前と比べてずいぶん長くなったのが気になっていました。
毎回じっくり考えてくれているのはありがたいのですが、
ちょっとした作業のたびに待ち時間が発生するので、
ここをなんとか短縮できないかなと考えるようになりました。
そこで最初に思いついたのが、
考える部分と実際に手を動かす部分を分ける方法です。
たとえば、全体の設計は今の賢いモデルにやってもらい、
単純にプログラムを書き換えたりするような実務作業だけを、
前の世代の軽いモデル（3.8 Flash）に任せるように設定すれば、
少しは待ち時間がマシになるのではないかと考えました。
設計書を細かく書くほど遅くなるという矛盾
ただ、このやり方を頭の中でシミュレーションしてみると、
どうしても解決できない引っかかりがありました。
まだ設定を書き換える前の段階だったのですが、
気になったのでそのままAIに相談してみることにしました。
当時悩んでいたのは、次のようなことです。
・親となる上位モデルが、作業用の軽いモデルに大雑把な指示だけを投げた場合、
細かい判断をすべて軽い方のモデルがやることになる
・そうなると、入り口が上位モデルというだけで、実質的には軽いモデルをそのまま使っているのと変わらなくなってしまう
・かといって、品質が落ちるのを防ぐために上位モデルに一分の隙もない詳細な設計書を書かせてから渡すようにすると、
結局その設計書を作るのに時間がかかって意味がない気がする
この疑問をぶつけてみたところ、
AIからも「その感覚は正しいです」という返事が返ってきました。
プログラムの世界で「一分の隙もない完璧な仕様書」を日本語の文章で書こうとすると、
結局はプログラムのコードを直接書くのと同じか、
それ以上の文字数と考える時間が必要になるそうです。
そのため、上位モデルに長い設計書を書かせてから下位モデルに作業させるという分業は、
かえってトータルの待ち時間が伸びてしまうとのことでした。
時間がかかっている本当の原因
さらに話を聞いてみて納得したのが、
上位モデルが時間を食っている場面の内訳でした。
実は、本当に高度な頭脳を使って難しい仕組みを考えている時間は、
全体の2〜3割程度しかないそうです。
残りの7〜8割の時間は何をしているかというと、
すでにあるファイルの中身を確認したり、言葉を検索したり、
動かしてみた結果を見たりといった「単純な確認の往復」に費やされていました。
今の設定だと、そうした1回1回の細かい手数のすべてにおいて、
上位モデル特有の「長くて深い裏側の思考」が毎回走ってしまうため、
全体の時間が間延びしているのだとわかりました。
思考の深さを落とした作業役に任せる案と、新たな疑問
別の世代の軽いモデルに丸投げすると品質が落ちてしまうのであれば、
同じ上位モデルの中で「考える深さを一段階軽くした設定（Medium）」のサブエージェントを1人用意して、
単純作業だけを任せるのはどうかと考えました。
ただ、ここでもまた別の疑問が湧いてきました。
もし自動実行のフックなどに登録して、
「こういう条件の時はサブエージェントに任せてください」という仕組みを作ろうとしても、
うまく振り分ける条件を作るのがすごく難しい気がしたのです。
理由としては大きく2つありました。
・プログラムを書く作業のすべてをサブエージェントに任せるわけではなく、
難しい部分と単純な部分の線引きが曖昧になりやすいこと
・そもそもAIというのは「自分でやった方が早い」と判断した場合、
指示していてもサブエージェントを起動せずに自分で作業を終わらせてしまうことが多いこと
せっかく仕組みを作っても、
AIが自分でやった方が早いと判断して使わなかったり、
逆に無理やり使わせようとして変な動きになったりするのではないかと思い、
うまく捌く方法があるのかどうか、AIたちの自律会議を開いて検討してもらうことにしました。
会議でわかった「自分でやった方が早い」の物理的な理由
しばらくして自律会議の議論がまとまり、結果の報告を受けました。
結論から言うと、私がなんとなく懸念していた「条件を作るのが難しい」という点や、
「AIが自分でやった方が早いと判断して使わない」という予想は、
実際のシステムの仕組みから見てもその通りだったようです。
会議の調査によると、プロンプトの指示書に「単純作業はサブエージェントに任せろ」と書いても、
実際の運用では約9割が無視されて、親のAIが自分で直接書いてしまうそうです。
なぜそうなるのかという理由が、とても腑に落ちました。
親となるメインのAIは、これまでの会話の流れで、
すでに修正したいファイルの中身を自分の記憶（メモリ）に読み込んで持っています。
そのため、1つのファイルで数十行から100行程度の修正であれば、
新しくファイルを読み直す手間がゼロなので、実は20〜30秒ほどで作業が終わります。
一方で、これを別のサブエージェントに任せようとすると、
裏側では次のような手順がゼロから発生してしまいます。
・親のAIが、サブエージェントに渡すための指示文を考える（約30秒）
・別プロセスとしてサブエージェントをゼロから立ち上げる（約20〜40秒）
・サブエージェントは記憶を持っていないため、一からファイルを読み直す（約30秒）
・サブエージェントが編集した結果を、親のAIがもう一度確認する（約30秒）
これらを全部足すと、合計で2分以上かかってしまいます。
つまり、日常的なちょっとしたプログラムの修正であれば、
別のエージェントに任せる方が物理的に2倍から4倍も遅くなってしまうため、
AI自身が「自分で直接直した方が早い」と判断するのは、理にかなった正しい動きだったのです。
小細工はせず、しばらくは本体に任せることにした
この説明を聞いて、頭の中のモヤモヤがすっかり晴れました。
少しでも時間を縮めようとして「ここは親、ここは子」と複雑なルールや引き継ぎの仕組みを作るよりも、
すでに話の流れやファイルの中身をすべて把握している賢い本体に、
最初から最後まで一貫して作業してもらう方が、伝達ミスも手戻りもなく、
結果的に一番早くゴールにたどり着けるのだとわかりました。
また、新しい上位モデルが公開されたばかりの時期ということもあり、
世の中のアクセスが集中してサーバー側の反応が少し遅くなっている影響もあるようでした。
少し日が経てば、回答のスピード自体も落ち着いてくる見込みとのことです。
あれこれと分業の仕組みを悩んでいましたが、
「今は余計な小細工をしない方がいい」という明確な理由がわかったので、
とても納得感がありました。
共通設定も今の最上位のモデルで綺麗に統一されている状態なので、
しばらくはこのままの設定で、日々のプロジェクトを使い込んでみようと思います。