結論：規模10倍でも1記事6分へ半減した理由

当サイトでは毎日朝と夕方の 2 回、macOS の launchd から Gemini API を呼び出し、海外論文（arXiv）や公的機関・技術メディアの一次情報 RSS を自動収集して内部資料フォルダへ蓄積しています。

そして数日に 1 度、AI エディタ上の相棒（Gemini 4 Argon）に 「API が収集したので記事にできるのある？」→「全部お願い」 の 2 言だけを伝え、重複チェック・一次ソース裏取り・執筆・アイキャッチ画像生成・双方向リンク接続・本番転送・Playwright 実機確認までを一気通貫で実行させています。

同一タスク『4記事一括作成〜本番実機検証』の直近ビフォーアフター

前回（Nodeラッパー混在期：11/05）

• AI 実働時間合計 : 42.5 分（1 記事あたり 10.6 分）
• うち執筆〜検証フェーズ : 38.1 分（65 ステップ）
• 総 LLM 推論コール数 : 77 回（19.3 回 / 記事）
• read_file 読込回数 : 72 回（既存記事や規約を多読）
• 親会話ログ肥大度 : 650.3 KB（後半ほど応答が鈍化）

今回（Pure Rust完全統合後：11/06-07）

• AI 実働時間合計 : 約 24.0 分（1 記事あたり 約 6.0 分）
• うち執筆〜検証フェーズ : 約 20.5 分（31 ステップ・46% 短縮）
• 総 LLM 推論コール数 : 42 回（10.5 回 / 記事・45% 削減）
• read_file 読込回数 : 41 回（ピンポイント取得で 43% 減）
• 親会話ログ肥大度 : 482.5 KB（デプロイ手戻り 0 回）

同じ「検証録 2 本 ＋ AI 国家構想 2 本 ＝ 計 4 記事」を一括作成して本番検証まで終えるのに、わずか 1 日前の構成では 42.5 分（77 ステップ） かかっていたものが、Pure Rust 2 バイナリ直結とゼロコピー SQLite 索引が完全稼働した今回は 約 24.0 分（42 ステップ） で一発完走しました。

品質チェックや画像生成を省略したわけではなく、むしろチェック項目が過去最多になった状態で、1 記事あたり約 6 分という過去最速タイの領域へ突入した のが最大のポイントです。

---

なぜAI記事作成は記事が増えるほど遅くなるのか

実測表を見る前に、なぜ普通に AI エディタを使っていると「サイトやコードベースが育つほど作業が遅くなるのか」という構造的な罠を整理しておきます。

全文丸読みとデプロイ直前の手戻り地獄

記事数が 300 本から 600 本超へ増え、品質を維持するためのルールブック（GEMINI.md）も 40KB 台から 約484KB へと成長すると、素のままの AI エージェントには 2 つの大きなブレーキ がかかります。

実務上の総所要時間 $T_{\text{total}}$ を数式で分解すると、なぜステップ数の削減が効くのかが直感的にわかります。

ここで $N_{\text{step}}$ は推論ステップ数、$C_i$ は $i$ ステップ目の累積コンテキスト長、$N_{\text{rework}}$ は検問落ちによる手戻り回数です。つまり、「手元でミリ秒検索して $C_i$ を小さく保つこと」と「保存した瞬間に機械検問して $N_{\text{rework}} = 0$ にすること」 を同時に達成すれば、全体の時間は掛け算で劇的に縮まります。

---

全12回・38記事の4世代パイプライン実測比較

それでは、2026 年 10 月 19 日から 11 月 7 日までに実施した全 12 回の「API 収集レポートからの本番記事化セッション（計 38 記事作成）」の実測データを並べて検証します。

返答待ちを除いた公平な計測ルール

読者の方から「途中で人間が席を外していた待ち時間が混ざっていたら不公平では？」という疑問が出ないよう、以下の厳密な条件で全 12 セッションの生ログ（transcript.jsonl および SQLite アーカイブ .db）を集計しました。

前回4本と今回4本の直接対決データ

まず、作成記事数（検証録 2 本 ＋ AI 国家構想 2 本 ＝ 4 本）も品質基準（アイキャッチ生成・双方向リンク・出典死活照合・8 大ペルソナ監査・PC／スマホ実機確認）も完全に同一である 前回（11/05）と今回（11/06-07） の詳細比較です。

計測指標（4記事一括作成セッション同士）	前回 db6620c5（11/05）	今回 90a8fb2e（11/06-07）	増減・改善率
対象時点の総公開記事数 / GEMINI.md 容量	634本 / 443.7KB	637本 / 464.8KB	規模はさらに拡大
① 提案フェーズ（裏取り調査〜4案提示）	4.5分（12 step）	3.5分（11 step）	-1.0分（-22%）
② 製造・転送・Playwright検証フェーズ	38.1分（65 step）	約20.5分（31 step） ※本計測集計込みで21.9分	-17.6分（-46%）
AI 実働時間 合計	42.5分	約24.0分（集計込み25.4分）	-18.5分（-43%）
1記事あたりの平均 AI 実働時間	10.6分 / 記事	約6.0分 / 記事	1本4.6分短縮
総 LLM 推論ステップ数（APIコール）	77回（19.3回/記事）	42回（10.5回/記事）	-35回（-45%）
read_file 実行回数	72回（18.0回/記事）	41回（10.2回/記事）	-31回（-43%）
親会話トランスクリプト容量	650.3 KB	482.5 KB	-167.8 KB（-26%）
1記事あたり新規TPU送信トークン（推論）	約15.3万 tok / 記事	約10.5万 tok / 記事	約31%削減

第1世代から第4世代までの推移一覧

さらに視野を広げ、10 月 19 日の初回から今回までの 全 12 セッションすべての実測値 を時系列で並べたものが以下のマスターテーブルです。

世代	日時（会話ID先頭）	作成数	AI実働合計 （うち製造）	1記事あたり 実働時間	総step （1本平均）	read 回数	親ログ容量 （1本平均）	1記事あたり新規tok / 累積tok （10月は実測・11月は推論）
初期	10/19 644b4c65 ※画像・双方向検問なし	3本	18.1分 (15.3分)	6.0分	31回 (10.3)	32回	235KB (78KB)	実測: 9.3万 / 141万 tok
第1	10/26 80c93f76 手作業grep・丸読み期	2本	16.4分 (13.1分)	8.2分	38回 (19.0)	64回	389KB (194KB)	実測: 27.3万 / 257万 tok
第1	10/27 e09837f5	4本	25.5分 (21.6分)	6.4分	51回 (12.8)	59回	450KB (112KB)	実測: 18.8万 / 184万 tok
第1	10/29朝 b6c3a643	3本	26.0分 (22.8分)	8.7分	47回 (15.7)	57回	425KB (142KB)	実測: 12.7万 / 159万 tok
第1	10/29夜 b32847ba	3本	22.5分 (20.4分)	7.5分	52回 (17.3)	75回	518KB (173KB)	実測: 27.8万 / 269万 tok
第2	10/31朝 10e8bfb2 Node製kb_query導入	3本	19.9分 (16.7分)	6.6分	41回 (13.7)	54回	467KB (156KB)	実測: 11.0万 / 153万 tok
第2	10/31夜 fdf92674	3本	21.6分 (18.8分)	7.2分	47回 (15.7)	68回	486KB (162KB)	実測: 13.9万 / 229万 tok
第2	11/01 c8c7ea06 品質・リンク規約厳格化	3本	23.5分 (19.3分)	7.8分	43回 (14.3)	74回	576KB (192KB)	推論: 約10.4万 / 192万 tok
第2	11/02 debe4f2d 初期Rust検問・差戻し増	3本	29.7分 (26.3分)	9.9分	60回 (20.0)	54回	537KB (179KB)	推論: 約21.4万 / 216万 tok
第2	11/03 2e3068ff	3本	26.6分 (20.9分)	8.9分	61回 (20.3)	58回	558KB (186KB)	推論: 約18.1万 / 218万 tok
第3	11/05 db6620c5 4本一括・Node混在期	4本	42.5分 (38.1分)	10.6分	77回 (19.3)	72回	650KB (163KB)	推論: 約15.3万 / 215万 tok
第4	11/06-07 90a8fb2e Pure Rust完全統合後	4本	約24.0分 (約20.5分)	約6.0分	42回 (10.5)	41回	483KB (121KB)	推論: 約10.5万 / 148万 tok

---

作業時間とステップ数を4割削った5つの仕組み

なぜ品質ゲートを一切緩めずに、4 記事の製造フェーズを 38.1 分 → 約 20.5 分 へと一気に短縮できたのか。効いた仕組みはプロンプトの言い回しではなく、Mac 側に実装した 5 つの決定論的ツール（Skillware） でした。

1記事6分・手戻りゼロを実現した『Pure Rust 2バイナリ』生産ライン

ゼロコピー SQLite 全文検索（kb-search）

既存 650本 の記事・公理・定数・過去チャットを数十ミリ秒で横断検索。read_file による全文丸読みを約 3 分の 1 に圧縮し、親コンテキストを常に身軽に維持します。

4並列 image-generator × WebP 自動変換

4 本分のアイキャッチ生成サブエージェントを同時起動し、完了と同時に gemini-gate convert-image が 1 秒で 1200×670 WebP へ変換・配置します。

一発 Created × 保存直後 4ms の自動 Hook 検問

ファイルを書き出した瞬間にエディタ Hook から gemini-gate が 4 ミリ秒で自動起動。見出し文字数・数式記法・未使用 import をその場で即座に摘み取り、デプロイ時の差し戻しをゼロにします。

add-related-link 一括双方向結線 × RAMDisk ビルド

既存関連記事への逆リンク注入もコマンド 1 発で完結。RAM ディスク上の高速 Astro ビルドと rsync 差分転送により、約 95 秒で本番公開まで完了します。

ゼロコピーSQLite索引で丸読みを3分の1へ

1 つ目の勝因は、シェルの grep や既存記事の当てずっぽうな read_file をやめ、Pure Rust 製の ゼロコピー SQLite 検索バイナリ（kb-search） に一本化したことです。

たとえば「直近で似た論文を記事にしていないか」「関連する既存記事のスラッグと正確なタイトルは何か」「GEMINI.md の該当公理は何行目にあるか」を調べたいとき、以前はファイルを 1 本ずつ開いて確認していました。現在は ./scripts/run_kb_search.sh search や axiom を叩けば 20〜60 ミリ秒で該当行番号と要約だけが返るため、クラウド側の TPU へ不要な長文を送らずに済みます。

保存直後4ミリ秒のRust検問で手戻りゼロ

2 つ目の最大の勝因が、.agents/hooks.json に仕込んだ 保存直後（Post-Tool）の即時 4 ミリ秒検問 です。

第 2 世代〜第 3 世代（11/02〜11/05）でステップ数が 60〜77 回まで膨らんでいた最大の原因は、4 記事すべてを書き終えて npm run 本番環境転送 を実行した最後の段階で「見出しが 29 文字を超えている」「段落が長すぎる」「片方向リンクが残っている」といったエラーが見つかり、そこから何往復も修正ループを回していたことでした。

今回は記事ファイルを write_file で出力したその瞬間に RAM ディスク常駐の gemini-gate が走り、わずか 1 ステップの微調整だけで 4 記事すべてが 100% クリーンな状態（重大違反 0 件・片方向リンク警告 0 件・孤立タグ 0 件） に仕上がりました。その結果、本番転送コマンドは 1 回目で無停止通過 しています。

4並列画像生成と双方向リンクの一括注入

さらに地味ながら大きく時間を削ってくれたのが、周辺作業のバッチ化と並列化です。

• アイキャッチ画像の 4 本同時バックグラウンド生成 : 1 枚ずつ順番に生成を待つのではなく、執筆に入る直前に 4 つの image-generator サブエージェントを並列起動し、原稿を書いている裏で 4 枚すべてを同時完成させました。
• 双方向リンク注入（add-related-link）の自動化 : 以前なら関連する既存記事を 1 本ずつ read_file で開いて導入枠を探し、edit_file を 10 回以上繰り返していた工程を、run_gemini_gate.sh add-related-link の一括処理へ置き換えたことで、リンク切れや自己リンクのミスなく数秒で双方向結線が完了しました。

---

裏側のAPI自動収集から公開までの全体タイムライン

参考として、「そもそも材料となる一次情報を Gemini API が裏側で集めている時間」も含めた、当サイトのニュース記事生産ライン全体の所要時間を時系列でまとめます。

一次情報の無人収集から4記事同時公開までの実測タイムライン

朝夕の無人収集（約1〜2分）

macOS launchd が 476 件の一次情報 RSS を取得。Gemini API を 2 回だけ呼び、日報と下書きを自動保存します。

自動蓄積

裏取りと4案提示（3.5分）

「記事にできるのある？」の 1 言で、既存 650本 との重複照合と原典 Web 裏取りを行い 4 案を提示します。

合意1言

4本執筆・検問・転送（17分）

「全部お願い」で 4 記事執筆・4 枚画像生成・12 記事双方向結線・Rust 検問・本番転送まで一気に完走します。

一発通過

実機ブラウザ検証（3.5分）

Playwright で本番 4 URL の PC・スマホ表示、目次 1 行収まり、画像・数式描画を自動確認して完了します。

人間の作業は、文字通り 「API が収集したので記事にできるのある？」と聞いて提案に目を通し、「全部お願い」と返すだけ（実働 1〜2 分） です。その裏で Mac と AI が約 24 分間フル回転し、一次ソースの裏取りからスマホ実機での表示確認まで終えた 4 本の記事が本番サイトに並びます。

---

まとめ：AIを速くするのはプロンプトより手元の道具

全 12 回・計 38 記事にわたる定点観測から得られた結論を整理します。

毎日数十分の待ち時間を消す母艦投資の試算

今回のように 「16GB の APFS RAM ディスク」＋「約 390MB の SQLite 知識 DB オンメモリ検索」＋「Pure Rust の 12 スレッド並列検問」＋「4 並列画像生成と高速 Astro ビルド」 を SSD スワップゼロで軽快に回し続けるには、やはり 64GB メモリを積んだ Mac 母艦 と 高速な Thunderbolt 外付け SSD（会話アーカイブ退避用） の組み合わせが抜群の威力を発揮します。

一見すると大容量メモリ機の導入や最上位 AI プランの契約は贅沢に見えるかもしれません。しかし推論（試算）として、たとえば約 24 万円クラスの 64GB メモリ搭載 Mac を 5 年間（1,825 日）毎日使い倒した場合、1 日あたりの母艦コストは約 131 円（缶コーヒー 1 本分） です。今回実証された通り、4 記事作るたびに 約 18.5 分の待ち時間とクォータ消費の約 3〜4 割 が毎回浮き続けることを考えれば、自分の時間を設計や意思決定だけに集中させる投資としてこれほど回収の早い道具はありません。

これから新しく Apple シリコン世代の母艦を組むなら、購入後のメモリ増設ができないため、最初から 64GB ユニファイドメモリを搭載した Apple Mac mini（Pro系チップ・64GBメモリ構成） が最もコストパフォーマンスに優れた本命機になります。

また、「27 インチ 5K の広い画面で記事のレイアウトやログを見比べながら、予算を抑えて 64GB 環境を手に入れたい」という方には、今回の全 12 セッション計測を無停止で支えている現役母艦 Apple iMac 27インチ Retina 5K（2020年モデル・整備済／中古良品） に、背面ハッチから自分で簡単に増設できる 【Intel Mac増設用】Crucial DDR4-2666 SO-DIMM メモリ を組み合わせる構成も非常に実用的な選択肢です（※ DDR4 メモリは Intel Mac 専用であり、Apple シリコン搭載 Mac には使用できません）。

そして、数千件規模に育っていく会話トランスクリプトや SQLite アーカイブを SSD やハードディスク（記憶装置）へ安全・高速に退避させる保管庫としては、Thunderbolt 3 対応で毎秒最大 3,000MB クラスの転送速度を持つ SanDisk Professional PRO-G40 SSD が 1 台あるとバックアップ待ちのストレスが消えます。あわせて、AI に書かせた Rust 製検索・検問ツールの構造を自分の目でもしっかり理解したい方には オライリー・ジャパン『プログラミングRust 第2版』 を手元に置いておくのがおすすめです。

最上位AIに自分の作業履歴を計測させる手順

最後に、「自分の AI エディタでも、同じ定型タスクが以前と比べてどれくらい速くなったか（あるいはどこで時間を食っているか）をログから計測してみたい！」という方へ、そのまま使える調査プロンプトを用意しました。

会話ログの JSONL 解析や人間の返答待ち時間の分離集計は、軽量モデルに曖昧に頼むと壁時計の経過時間をそのまま出してしまったり、別テーマの雑談まで合算してしまうことがあります。必ず 『Gemini 4 Argon』または同等以上の最上位推論モデル を選び、以下の枠内をコピー＆ペーストして「読み取り専用の事前調査と集計ルールの合意」から始めてみてください。