Gemini 4 Argonと3.8 Flashの速度逆転｜High思考で36件32分・枠が減らない実測

ちょっと待ってください！普通は「小さい Flash モデル＝速くて省エネ」「最上位の Argon High＝じっくり考えるから遅くてクォータを大量に食う」というのが常識ですよね？それで新規 6 本と既存補強 6 本を含む 36 件の更新を一気に回したのに、32 分で終わってクォータもほとんど減っていないってどういうカラクリなんですか？

そこが一番面白い逆転現象なんだよ。1 秒あたりの文字出し速度だけ見れば Flash の方が速く見えるんだけど、複雑なルールがある現場だと Flash は勘違いや手戻りで何十往復も迷走してしまう。逆に Argon High に専用 Rust ツールを持たせて迷いゼロで走らせると、一撃で決まるからトータル時間もクォータ消費も桁違いに小さくなる んだ。終わった直後の生ログを計測したから、数字で全部お見せしよう！

結論：Argon Highで36件更新が32分で終わる理由

今回計測した実戦タスクは、単なる短いテキスト生成ではありません。以下の 4 工程を「全部をよきに計らって」の一言からノンストップで完遂した本番セッション（2026 年 11 月 8 日早朝実施）の記録です。

過去のシェル手探り時代と今回の処理速度比較

手元の Pure Rust 解析コマンド（./scripts/run_kb_search.sh brain：解析時間 7.3ms）で、今回のセッションと過去のベンチマーク記録を比較した結果が次の表です。

かつてシェルを手探りで叩いていた頃に 「たった 1 本の記事を作るのにかかっていた時間（32.1 分）」 とほぼ同じ 32.8 分間で、今回は 「新規 6 本 ＋ 大型補強 6 本 ＋ 周辺 24 記事のリンク網整備 ＋ デプロイ実機検証」 まで丸ごと完了しています。実効スループット（単位時間あたりの処理量）で見れば 約 12 倍 への到達です（もし従来通りシェル混じりの直列作業や手戻りの多い軽量モデルで同じ物量を回していれば、推論ですが 90 分〜 120 分規模 を要していた計算になります）。

なお、実行前の「サイト全体を診断して補強すべき記事・新規記事を提案する」フェーズ（Turn 1）も、シェルの grep を一切使わず SQLite 直結検索のみで走査したため、わずか 2.4分（6 ステップ） で完了していました。

同時稼働したサブエージェント4班の単体記録

さらに注目すべきは、06 時 42 分に一斉起動した執筆・補強用サブエージェント 4 班（すべて Gemini 4 Argon High・シェル探索ゼロ）の単体スピードです。

4 班の稼働時間を単純合算すると 29.30分 分の執筆作業になりますが、同時並列で走らせつつ裏で親エージェントが共通ハブ・台帳・既存 12 記事への一括リンク追加を進めていたため、壁時計の上では わずか約 11 分強 で全 12 本の原稿と検問が一斉に揃いました。しかも班 4 に至っては、細かな税法・登記・介護要件や排他ロックのスクリプトを含む長文記事 4 本を わずか 16 ステップ（1 本あたり約 2.78 分） で一発合格させています。

軽量3.8 FlashよりArgon Highが速くなる構造

ここで最初の疑問である 「なぜ軽量・高速なはずの Gemini 3.8 Flash よりも、最上位の Gemini 4 Argon High の方が圧倒的に速く終わるのか」 を解き明かします。

字面反応の手戻りループと一撃設計の決定的な差

最大の理由は、AI 開発における本当の所要時間は「1 秒あたり何文字出力できるか（トークン生成速度）」ではなく、「1 回の指示から検問合格までに何ステップ迷走するか（総往復回数）」 で決まるからです。

なるほどねぇ！料理に例えると、見習いの子が小走りで何度も冷蔵庫を開け閉めして味付けをやり直している間に、熟練の料理長は最初に頭の中で段取りを全部組んで、無駄な動きゼロで 4 品同時に仕上げてしまうようなものね！

シェル往復税を消す7ミリ秒のSQLite直結検索

Argon High の高い設計力を 100% 活かすために欠かせないもうひとつの車輪が、「レガシーなシェルコマンド（cat・ls・grep・awk・事前 mkdir）の全面禁止と Pure Rust 専用バイナリへの統合」 です。

AI がシェルで ls や grep を 1 回叩くたびに、コマンド自体の実行時間だけでなく 「出力結果を受け取って次の行動を推論する往復待ち時間（数秒〜十数秒の推論往復税）」 が発生します。今回は親エージェント・サブエージェントともに探索用のシェルを一切使わず、以下の専用経路だけで処理しました。

なぜ36件動かしてもAIの利用枠が減らないのか

次に、もうひとつの驚きである 「新規 6 本・補強 6 本を含む 36 件の更新と画像 6 枚生成まで回したのに、なぜ AI の週間クォータ（利用枠）がほとんど減らなかったのか」 を実測トークンから検証します。

全7プロセスのトークン内訳と約9割のキャッシュ率

本番転送完了時点における、親エージェント（司令塔）とサブエージェント 6 体（執筆 4 班 ＋ 画像生成 2 班）の 全 7 プロセス実測トークン収支 は以下の通りです。

表の合計欄をご覧いただくと、驚くべき構造が浮かび上がります。

システム全体では見かけ上 約 1,579 万トークン という膨大なプロンプトを処理し、合計 約 25 万トークン の原稿・構造化データを出力しています。ところが、そのうち 約 9 割（89.7% ＝ 約 1,416 万トークン、親単体では実に 92.6%）がすでに計算済みの KV キャッシュからの高速読み込み であり、新しく GPU / TPU で初期演算（Prefill）を行った実質の新規入力（Fresh Input）は 全体でわずか約 163 万トークン（メイン 12 本換算で 1 本あたり約 13.6 万トークン） に抑え込まれていたのです。

ステップ数の二乗爆発を断つ排他分割の数理

なぜ同じ 12 本・36 件の作業でも、やり方によってクォータの減り方が何倍も変わるのでしょうか。その理由は、AI チャットの累積トークン消費がステップ数に対して比例ではなく 「二乗」で膨張する性質 を持っているからです。

1 ステップあたりに増える平均履歴トークン量を $d$、完了までの総ステップ数を $N$ とすると、1 つの会話部屋で最後まで直列作業した場合の累積プロンプト処理量 $C_{\text{serial}}$ は次の式に比例します。

ここで $B_0$ は初期システムプロンプト量です。もし親エージェント 1 人がシェルで手探りしながら 12 本分の記事全文と長大な執筆出力（約 13.4 万トークン）をすべて自分の会話履歴に抱え込み、合計 250〜400 ステップ走り続けた場合、$N^2$ の項が爆発し、後半は 1 回ツールを呼ぶたびに数十万〜百万トークン近い巨大コンテキストを引きずることになります。

これに対し、今回の「シェル排除 × $K$ 班排他サブエージェント分割 × KV キャッシュ維持」における実質クォータ負荷 $Q_{\text{eff}}$（推論を含む数理モデル）は次の形に圧縮されます。

ここで $F_i$ は新規入力トークン、$H_i$ は KV キャッシュ読込トークン、$O_i$ は出力トークン、$\alpha$ はキャッシュ読込の演算割引係数（一般に新規計算の約 0.1〜0.25 倍相当）、$\beta$ は出力重み係数です。今回クォータがほとんど減らなかった理由は、次の 3 つの同時圧縮 が噛み合ったためです。

正直な振り返り：唯一発生した十数秒の片付け

1 bit のごまかしもない検証録として、今回の 32.8 分の中で 唯一発生した小さな手戻り（約十数秒のロス） も正直に記録しておきます。

既存の移行レビュー記事（src/content/blog/review-old/noilheat/）へ比較用の暖房機カードを追加する際、親エージェントが新規レビュー（src/content/blog/review/）専用の自動登録サブコマンド add-affiliate を呼んだため、review/ 側に仮フォルダが生成され、正規の review-old/ 側へ定義を移して空フォルダを片付ける 1 ステップが発生しました。次回から review-old/ 配下の商品追加は最初から該当 *-affiliate.ts を直接 edit_file する運用にすれば、この十数秒すら完全にゼロにできます。

うまくいった数字だけじゃなく、その十数秒の引っかかりまでログから拾って次に活かすのが、手戻りをゼロに近づける秘訣にゃ。

まとめ：時間を生み出す最上位AIと64GB母艦への投資

今回の実測で改めて裏付けられたのは、「AI の利用枠や時間を節約したいなら、モデルのランクを落としたり小まめに履歴を消したりするのではなく、最上位モデル（Gemini 4 Argon High）が 1 発で正解に辿り着けるローカル環境（Pure Rust 検索・検問ツールと RAMDisk 母艦）を整えるのが圧倒的に安い」 という事実です。

上位AIプランと大画面母艦の1日あたり快適コスト

最上位の AI サブスクリプションや、64GB 大容量メモリ・高速外付け SSD を備えた 27 インチ 5K 母艦環境は、月額や初期費用の数字だけを見ると贅沢に感じるかもしれません。しかし、今回のように「手作業や軽量モデルなら 2 時間近くかかる 36 件の調査・執筆・リンク整備・デプロイ検証が、自分はコーヒーを飲んでいる 32 分でミスなく終わる」という 時間価値（タイム・イズ・マネー） と耐用年数で割ると、景色はまったく変わります（以下は使用期間・稼働時間に基づく推論・モデル試算です）。

• 64GB メモリ搭載 27 インチ 5K iMac 母艦 ＋ 16GB RAMDisk 環境 ：整備済品やメモリ自己増設（総額約 15 万〜 20 万円規模）を 5 年間（1,825 日）・1 日 5 時間使うと仮定すれば、1 日あたり約 82〜 110 円、1 時間あたり約 16〜 22 円 です。16GB の RAMDisk 上で gemini-gate が 0.6 秒で走り、内蔵 SSD の書き込み寿命（TBW）も無傷で守られます。

• 上位 AI プラン × 最上位モデル運用 ：毎日 1〜 2 時間分の手作業・手直しストレスから解放され、自分の目と頭を「何を作るか・どう判断するか」という本質だけに使えるなら、缶コーヒー 1〜 2 本分の日額で熟練の編集・開発チームを常駐させているのと同じ投資対効果が得られます。

これから AI エディタとローカル高速化基盤をじっくり育てる母艦機材として、実際に当ラボで毎日フル稼働している構成は以下の通りです。

【中古・整備済品】Apple iMac 27インチ Retina 5K (2020年モデル / Intel最終世代・メモリ自己増設対応)

Amazon楽天市場Yahoo!

【Intel Mac増設用】Crucial iMac 27インチ(2019/2020)・ノートPC用 メモリ DDR4-2666 SO-DIMM (16GB×2 / 32GB×2)

Amazon楽天市場Yahoo!

SanDisk Professional PRO-G40 SSD 4TB / 2TB (Thunderbolt 3 & USB 3.2 Gen 2 両対応)

Amazon楽天市場Yahoo!

最上位AIに省クォータ並列基盤を組ませる手順

ご自身のプロジェクトでも「シェル手探りの廃止」「ローカル高速検索・検問」「ファイル重複ゼロのサブエージェント並列運用」を取り入れたい場合は、軽量モデルではなく 必ず『Gemini 4 Argon（High）』または同等以上の最上位推論モデル を選択し、以下のプロンプトをそのまま貼り付けて現状診断と設計合意から始めてみてください。

以下の検証記事 URL の設計思想（軽量モデルの字面迷走と手戻り回避、探索用シェル ls/grep/cat/事前mkdir の禁止、ローカル高速検索・機械検問ツールへのオフロード、ファイル重複ゼロの排他サブエージェント並列分担、/clear を使わない高 KV キャッシュ維持）を参考にして、現在の私のワークスペースを診断してください。

参照記事：https://lab.chihouzakki.com/blog/review/ai-36-files-32min-zero-shell-quota-saving-benchmark/

【守ってほしい手順】
1. いきなりファイルを書き換えず、まず直近の作業で「何度も繰り返しているシェル検索・確認コマンド」や「親コンテキストを肥大化させている長文処理」がないかを調査してください。
2. 既存の仕組みを壊さず最小の手間で最大の効果が出る「高速化・クォータ節約の改善案トップ3」と、「今は手をつけなくてよい領域」をセットで提示し、私の合意を得てから実装に進んでください。

モデルをケチらず最上位の相棒に任せ、足回りの無駄なシェル往復をなくしてあげれば、AI は驚くほど静かに、速く、そして軽く仕事をしてくれます。ぜひ手元の環境でもこの気持ちよさを体感してみてください！