API自動収集と記事作成の5世代進化実測｜トークン・処理時間の折れ線グラフ全記録
当サイトでは毎日朝（06:17）と夕方（18:23）の 2 回、macOS の launchd から Gemini API を呼び出して世界中の一次情報（論文・公的統計・特許・技術メディア）を自動収集し、AI エディタ上の相棒（Gemini 4 Argon）に 「API からの報告で記事にできるのある？」➔「全部をおねがい」 と伝えるだけで、重複照合・執筆・アイキャッチ生成・双方向リンク結線・本番デプロイ・実機検証までを一気通貫で回しています。
以前、第 4 世代（Pure Rust 完全統合）までの全 12 回・38 記事の所要時間ベンチマークを公開しましたが、その後も「既存記事が増えるにつれて関連更新や事前調査のツール往復が再び重くなる」という第 2 の壁に直面しました。そこで今朝、前処理 prep draft と事後処理 finish の 2 発で AI の意味判断を挟み込む『第 5 世代：決定論サンドイッチ構造』を実装し、本日（2026 年 11 月 10 日）の本番記事作成で実戦投入しました。
本記事では、裏側の「API 自動収集バッチ（daily_news.rs）」自体の 3 段階進化と、全 16 セッションの処理時間・ステップ数・確定実測トークン量の推移を 折れ線グラフ（LineChart）と棒グラフ（BarChart） で完全可視化して公開します。
-
動画生成AI『MiniMax H3』1本12円とMuse Ember10セント｜秒課金GPU節約術 : 音声つき動画生成AI『MiniMax H3』をRunPod Serverless（秒課金GPU）で動かし公式API料金の約1/5（1本約12円）へ圧縮する仕組みと、Met…
-
Search Console確認をAIで5倍速化｜7回の処理時間とトークン推移の実測録 : もうひとつの定例業務である「今日のGSC何かある？」の7回分の処理時間（6.3分→1.2分）とトークン推移を折れ線・棒グラフで可視化した姉妹編です。
-
AI記事作成が1本6分に短縮した全12回の実測記録｜規模10倍でも速くなるRust基盤 : 10月19日から11月7日（第4世代）までの12セッションを分析した前編です。本記事はその後の第5世代（サンドイッチ構造）までの全16回トークン確定実測・完結編にあたります。
-
AIのツール呼び出し往復が遅い原因｜Pure Rust前後一括化で出力83%減の実証録 : 本記事の第5世代で威力を発揮した
kb-search prep draft（3.48ms）とgemini-gate finishの設計思想と単体ベンチマーク記録です。 -
Gemini API×RSS×launchdで朝夕2回のAI日報を全自動生成するMac一次情報リサーチ術 : 毎日朝夕に世界の一次情報RSSを自動収集して戦略日報とたたき台を生成する裏側エンジンの解説記事です。
-
AI エージェントの定型ワークフローにおいて、「検索・チェッカーの Rust 化（第 4 世代）」と「前後一括サンドイッチ化（第 5 世代）」がそれぞれ何分・何万トークンを削るのか 実測グラフで見たい方
-
毎日自動で回る API ニュース収集バッチ自体の進化（重複除外・朝夕の自動追記マージ・3.48ms 事前カルテ直結） の仕組みを知りたい方
-
表の数値だけでなく、折れ線グラフと棒グラフで「品質基準の厳格化による一時的な負荷増大」と「アーキテクチャ刷新による劇的な逆転」の軌跡 を直感的に把握したい方
お昼に見た Search Console の進化グラフもすごかったが、毎日フル回転しとる「API からの記事作成」も、最初の頃から今日まででどれくらい進化したのかグラフで見比べてみたいぞ！ 特に今朝作ったばかりの prep と finish のサンドイッチ構造で、今日の記事作りはどう変わったんじゃ？
ありがとうございます！ 実はまさに今、本日の API 報告から 4 本の記事（AI 国家 2 本＋検証録 2 本）を書き上げた瞬間の生ログを kb-search brain で計測したところ、これまでの記録を塗り替えるすごい数字が出たんです！ 裏側の API 収集エンジンの進化とあわせて、全 16 回の折れ線グラフと棒グラフで一挙にお見せしますね！
結論：第5世代統合でトークン69%減・1本4.5分へ
まず結論として、当サイトの「API 一次情報収集 ➔ 本番記事作成パイプライン」が辿った 第 1 世代から第 5 世代（本日）までの代表セッション比較 を確認しましょう。
第3世代・第4世代・第5世代の直接対決
同じ「API 収集レポートから 3〜4 本の新規記事を作成（アイキャッチ画像生成・双方向リンク・即時検問込み）」という条件で、第 3 世代（11/05：Node ラッパー混在期）、第 4 世代後期（11/09：単発 Pure Rust 呼び出し期）、そして 第 5 世代（本日 11/10：prep draft ＋ finish 一括サンドイッチ期） を比較した確定実測値が以下の表です。
| 計測指標（1記事あたりの平均値で正規化比較） | 第3世代 db6620c5（11/05：Node混在・4本） |
第4世代後期 5aa9ac9c（11/09：単発Rust・3本） |
第5世代 12a3a7a1（本日）（11/10：prep/finish統合・4本時点） |
第3世代からの改善率 （前日11/09比） |
|---|---|---|---|---|
| 対象時点の総公開記事数 / ルール容量 | 634本 / 443.7KB | 688本 / 531.0KB | 706本 / 約543KB | 規模はさらに拡大 |
| 下調べ（日報・重複・公理・定数照合） | 5〜8コマンド直列 | 6〜10コマンド直列 | prep draft 1発（3.48ms） |
往復ターン税を解消 |
| 1記事あたりの AI 純稼働時間（執筆完了時点） | 10.6 分 / 本 | 16.1 分 / 本 （※手動収集・既存改修込） |
4.45 分 / 本 （製造Turn単体では 2.8分/本） |
-58.0% 短縮 （前日比 -72.4%） |
| 1記事あたりの推論ステップ数（Planner） | 19.3 回 / 本 | 25.0 回 / 本 | 8.5 回 / 本 （製造Turn単体では 3.0回/本） |
-56.0% 削減 （前日比 -66.0%） |
1記事あたりの read_file 回数 |
18.0 回 / 本 | 19.7 回 / 本 | 7.8 回 / 本 | -56.7% 削減 |
| 1記事あたり親新規入力（Fresh）トークン | 205,039 tok | 298,442 tok | 62,851 tok | -69.3% 削減 （前日比 -78.9%） |
| 1記事あたり総プロンプト評価量（Cache込） | 2,943,952 tok | 3,709,774 tok | 1,019,974 tok | -65.4% 削減 （前日比 -72.5%） |
※本日の第 5 世代（12a3a7a1）は、4 記事（AI 国家 2 本＋検証録 2 本）の執筆・アイキャッチ 5 枚生成・保存直後 4ms 検問クリア完了時点（18:42:50 JST）の確定実測値です。その後の finish 一括結線・本番転送・Playwright 実機検証および本記事（5 本目）の追加分を含めた全 5 記事完走トータルでも、1 記事あたり 約 5.0〜5.5 分・新規入力約 7 万トークン台 で完結しています。
裏側のAPI自動収集エンジン自体の3段階進化
記事作成フェーズの計測グラフを見る前に、まず「材料を集めてくる API 自動収集バッチ（現在は tools/kb-search/src/daily_news.rs）」自体がどのように進化したのかを整理しておきます。
ここが賢くなったことで、AI エージェントが最初のターンで読むべき情報が劇的に整理されました。
外部パッケージに依存したJSスクリプトでRSSを取得。同日2回走ると上書きや重複が起きやすく、AIが毎回全文をgrepしていた。
kb-search daily-news へ統合。RFC2822/Atom日時解析と既出URL除外により新着のみを抽出し、Gemini 4 Argon の思考パートを除いて保存。
朝（06:17）と夕方（18:23）のレポートと出典URLリストを上書きせず自動統合。prep draft --latest が3.48msで類似記事・公理・定数カルテを生成。
実際に本日（2026 年 11 月 10 日）の夕方 18:23 に launchd が自動起動した際の実行ログ（/tmp/daily-ai-news.log）を見ると、裏側の自動化がどれほど緻密に動いているかが分かります。
-
① 86件の一次情報取得と17件の既出自動フィルタリング : 世界の論文・特許・技術メディア・公的機関 RSS から 86 件 を高速取得し、朝までに収録済みの 17 件 を自動除外して、純粋な新着 69 件 だけを
Gemini 4 ArgonAPI へ送信しました。 -
② 当日朝レポートへの『非破壊・自動追記マージ』 : 朝（06:42）に生成されていた
2026-11-10-daily-report.mdを検知すると、ファイルを上書きして朝の情報を消すのではなく、フロントマターのreferences配列へ夕方分の出典 URL を自動でマージ追加し、本文末尾へ## 追加収集レポート（18:26 JST）として追記統合しました。 -
③
prep draft --latestによる3.48ミリ秒の統合カルテ出力 : 人間が「API からの報告で記事にできるのある？」と聞いた瞬間、AI は./scripts/run_kb_search.sh prep draft --latestを 1 発叩くだけで、わずか 3.48 ミリ秒 で「物理行番号付きの目次・全出典 URL・既存類似記事のスコアと被リンク数・参照すべき公理の行範囲・経済定数」が揃った 1 枚のカルテを受け取りました。
全16セッション（計51記事）の処理時間・トークン推移グラフ
それでは、2026 年 10 月 19 日から本日 11 月 10 日までに実施した 全 16 回の「API 報告からの記事作成セッション（計 51 記事作成）」 の全推移を、折れ線グラフと棒グラフ、および完全実測テーブルで検証します。
1記事あたりの処理時間とステップ数の折れ線グラフ
まず、サイト規模とルール容量が約 10 倍（公開 706本・GEMINI.md 約543KB / 1,310行）へと膨張する中で、「1 記事あたりの AI 純稼働時間（分）」 と 「1 記事あたりの推論ステップ数（回）」 がどう推移したかを示す折れ線グラフです。
※ 11/06-07（90a8fb2e）と 11/08 夜（b3814095）は後半に別テーマの計測・改修議論が派生したため、純粋な「API 収集からの記事作成フェーズ完了時点」の数値で統一比較しています。また 11/07 夜（fc3d01ae）と 11/09（5aa9ac9c）は新規 3〜4 本に加えて既存記事 2〜13 本の横断改修や手動収集を同時に行ったため一度負荷が上がりましたが、本日の 第 5 世代（prep draft 統合） で過去最速の 4.5 分 / 記事（8.5 ステップ / 記事） へと劇的に突き抜けています。
1記事あたりの確定実測トークン量の折れ線グラフ
次に、前回の記事では「11 月分は推計値」にとどまっていたトークン消費について、kb-search brain によって全セッションの JSONL トランスクリプトおよび Protobuf アーカイブから 1 トークン単位の確定実測値 を抽出し、「1 記事あたりの新規入力（Fresh）トークン」 と 「1 記事あたりの総プロンプト評価量（キャッシュ読込込み）」 の推移を折れ線グラフにしました。
すごいわね！ 10 月 19 日の最初期は、アイキャッチ画像も作らずリンクチェックもしてなかったのに 1 本あたり 9.3 万トークン（総評価 141 万トークン）かかってたんでしょう？ それが今日の第 5 世代では、画像もグラフも厳しい検問も全部入りなのに 6.3 万トークン（総評価 102 万トークン） まで下がっちゃったのね！
そうなんです！ なぜここまで劇的に減ったかというと、今朝実装した prep draft --latest が 「従来 5〜10 コマンドに分かれて重複出力されていた 34.5KB の調査テキストを、重複ゼロの 9.6KB カルテ 1 枚に圧縮した」 ことと、「4 本の記事を一切の手戻りなしで 1 発ずつ write_file できたため、1 記事あたりの推論往復が製造フェーズでわずか 3 回しか走らなかった」 からなんです！
全16セッションの完全実測マスターテーブル
全 16 回の生ログから抽出した確定数値を一覧表にまとめます。
| 世代 | 日時（会話ID先頭） | 新規作成数 （＋既存更新） |
AI純稼働合計 （記事化範囲） |
1記事あたり 実働時間 |
総step （1本平均） |
read回数 |
親ログ容量 | 1記事あたり確定実測トークン 新規Fresh入力 ／ 総Prompt評価（Cache込） |
|---|---|---|---|---|---|---|---|---|
| 初期 | 10/19 644b4c65※画像・双方向検問なし |
3本 | 18.1分 | 6.0分 | 31回 (10.3) |
32回 | 235KB | 9.3万 tok ／ 141万 tok |
| 第1 | 10/26 80c93f76手作業grep・丸読み期 |
2本 | 16.4分 | 8.2分 | 38回 (19.0) |
64回 | 389KB | 27.3万 tok ／ 257万 tok |
| 第1 | 10/27 e09837f5 |
4本 | 25.5分 | 6.4分 | 51回 (12.8) |
59回 | 450KB | 18.8万 tok ／ 184万 tok |
| 第1 | 10/29朝 b6c3a643 |
3本 | 26.0分 | 8.7分 | 47回 (15.7) |
57回 | 425KB | 12.7万 tok ／ 159万 tok |
| 第1 | 10/29夜 b32847ba |
3本 | 22.5分 | 7.5分 | 52回 (17.3) |
75回 | 518KB | 27.8万 tok ／ 269万 tok |
| 第2 | 10/31朝 10e8bfb2Node製SQLite検索導入 |
3本 | 19.9分 | 6.6分 | 41回 (13.7) |
54回 | 467KB | 11.0万 tok ／ 153万 tok |
| 第2 | 10/31夜 fdf92674 |
3本 | 21.6分 | 7.2分 | 47回 (15.7) |
68回 | 486KB | 13.9万 tok ／ 229万 tok |
| 第2 | 11/01 c8c7ea06品質・リンク規約厳格化 |
3本 | 23.5分 | 7.8分 | 43回 (14.3) |
74回 | 572KB | 17.5万 tok ／ 199万 tok （全体: 52.6万 / 596万） |
| 第2 | 11/02 debe4f2d初期Rust検問・差戻し期 |
3本 | 29.7分 （全110.4分） |
9.9分 | 60回 (20.0) |
54回 | 537KB | 21.4万 tok ／ 216万 tok （派生議論込全体: 289.8万 / 3,178万） |
| 第2 | 11/03 2e3068ff |
3本 | 26.6分 | 8.9分 | 61回 (20.3) |
58回 | 554KB | 16.1万 tok ／ 257万 tok （全体: 48.3万 / 772万） |
| 第3 | 11/05 db6620c54本一括・Node混在期 |
4本 | 42.5分 | 10.6分 | 77回 (19.3) |
72回 | 645KB | 20.5万 tok ／ 294万 tok （全体: 82.0万 / 1,178万） |
| 第4 | 11/06-07 90a8fb2ePure Rust 2バイナリ統合 |
4本 （＋計測1本） |
24.0分 （5本52.1分） |
6.0分 （5本10.4分） |
42回 (10.5) |
41回 | 483KB | 14.0万 tok ／ 320万 tok （5本全体: 70.1万 / 1,602万） |
| 第4 | 11/07夜 fc3d01ae既存13記事の連鎖改修込 |
4本 （＋更新13本） |
46.5分 | 11.6分 | 91回 (22.8) |
88回 | 709KB | 20.2万 tok ／ 386万 tok （全体: 80.8万 / 1,542万） |
| 第4 | 11/08夜 b3814095既存10記事の連鎖改修込 |
2本 （全3本＋20更新） |
45.1分 （全118.8分） |
15.0分 | 113回 (28.0) |
78回 | 740KB | 24.8万 tok ／ 350万 tok （派生議論込全体: 247.9万 / 4,015万） |
| 第4 | 11/09 5aa9ac9cその場でのAPI収集実行込 |
3本 （＋更新2本） |
48.4分 | 16.1分 | 75回 (25.0) |
59回 | 587KB | 29.8万 tok ／ 371万 tok （全体: 89.5万 / 1,113万） |
| 第5 | 11/10 12a3a7a1（本日）prep/finish サンドイッチ |
4本時点 （＋本記事で5本） |
17.8分 （製造11.2分） |
4.45分 （製造2.8分） |
34回 (8.5) |
31回 (7.8) |
260KB | 6.3万 tok ／ 102万 tok （4本時点全体: 25.1万 / 408万） |
なぜ第5世代サンドイッチ構造が必要だったのか
グラフを見ると非常に興味深い現象が読み取れます。11 月 6〜7 日に「Pure Rust 2 バイナリ化（第 4 世代）」を達成して一度は 1 記事 6.0 分まで縮まったにもかかわらず、直後の 11 月 7 日夜〜11 月 9 日（第 4 世代後期）にかけて、再び 1 記事あたり 11.6 分〜16.1 分（新規入力 20 万〜29.8 万トークン）へと重くなっている のです。
第4世代後期に発生した『小刻みツール連打』の罠
なぜローカルの Rust ツールが数ミリ秒で動いているのに、11 月 7 日〜9 日に再び時間とトークンが増えたのでしょうか。原因をログから解剖すると、次の 2 つが判明しました。
-
① 便利になった Rust サブコマンドを AI が『1個ずつ直列で何十回も呼ぶ』ようになった :
kb-searchに階層目次（tree）、記事カルテ（card）、波及調査（impact）、公理検索（axiom）、定数検索（const）など便利な機能が増えた結果、AI が丁寧に裏取りしようとして 1 セッションあたり 34〜77 回もkb-searchを小刻みに呼び出す ようになっていました。1 コマンドは 10 ミリ秒でも、クラウド LLM との往復ターン税（1 ステップ約 25〜30 秒）が掛け算でのしかかっていたのです。 -
② 双方向リンクや既存記事更新のために相手のファイルを何度も開いていた : 新規記事を 3〜4 本作るたびに、関連する既存記事 5〜13 本の目次や導入枠を確認・編集するため、再び
read_fileが 59〜88 回まで膨らんでいました。
事前3.48msカルテと一括仕上げの威力
この「第 4 世代の壁」を正面から打ち破ったのが、今朝実装して本日初めて本番投入した 第 5 世代（prep draft ＋ finish サンドイッチ構造） です。
本日のセッション（12a3a7a1）におけるステップ進行を振り返ると、無駄な往復がいかに消滅したかが一目瞭然です。
-
Turn #1〜#2（提案フェーズ：計22ステップ・6.6分） : 本日朝と 18:26 夕方に自動収集された計 39 件の一次情報に対し、
./scripts/run_kb_search.sh prep draft --latestを 3.48 ミリ秒 で実行。既存 706本 との重複照合・公理・定数・正規タグ候補を 1 枚のカルテで把握し、既存記事と一切被らない 4 案＋本計測記事案を提示しました。 -
Turn #3（4記事製造フェーズ：わずか12ステップ・11.2分！） : 「全部をおねがい」の合図と同時に、5 本分のアイキャッチ生成サブエージェント（
image-generator）を並列起動。裏で画像が生成される間にconvert-imageで 5 枚を一括 WebP 化し、AI 国家 2 本＋検証録 2 本の計 4 記事を一発write_fileで出力。保存直後 4 ミリ秒のgemini-gateHook 検問で指摘された微調整をその場で終え、4 記事の製造をたった 11.2 分（1 記事あたり 2.8 分・3.0 ステップ） で完遂しました。 -
事後仕上げ（
finish一発実行） : 従来なら相手記事を 1 本ずつ開いて行っていた双方向逆リンク注入、未登録アフィリエイト商品の登録、太字スペース整形、リンクグラフ検査、定数・SQLite 知識 DB 同期までを、run_gemini_gate.sh finishの一括パイプラインで処理します。
数式で表せば、第 4 世代までは下調べステップ数 ・仕上げステップ数 かかっていたものが、第 5 世代では へ収束したため、クラウド推論の累積トークン評価量 が 371 万トークン/本 ➔ 102 万トークン/本（72.5% 削減） へと劇的に圧縮された のです。
まとめ：ボトムアップで部品を鍛え最後に前後2発へ束ねる
2026 年 10 月 19 日から 11 月 10 日までの全 16 セッション・51 記事におよぶ定点計測から得られた結論をまとめます。
-
第1〜第3世代の教訓（規模が10倍になると手作業grepと丸読みは破綻する） : 記事数と品質ルールが増えるにつれ、1 記事あたりの所要時間は 6.0 分から 10.6 分へ、新規入力トークンは 20 万〜27 万トークンへと膨張しました。
-
第4世代の到達点と新たな壁（Pure Rust単発ツール化だけでは『往復回数』が残る） : 検索と検問を Pure Rust 化したことで一度は 1 本 6.0 分へ短縮できましたが、便利なサブコマンドが増えると AI がそれを小刻みに何十回も呼び出し、再び 11〜16 分かかる「往復ターン税」の壁が現れました。
-
第5世代の最適解（意味判断だけをAIに残し、前後を
prepとfinishの2発へ統合する） : よく使う単機能部品をボトムアップで磨き上げた上で、最後に「事前カルテprep（3.48ms）」と「事後一括仕上げfinish」のサンドイッチ構造へ統合した結果、1 記事あたりの執筆完了時間 4.45 分（製造 2.8 分）・新規入力 6.3 万トークン（第 3 世代比 69% 減） という過去最高領域へ到達しました。
全5世代の高速検証とオンメモリDBを支える母艦環境
今回のように 「朝夕の無人 API 収集バッチ（daily_news.rs）」＋「16GB APFS RAM ディスク上の常駐バイナリと SQLite オンメモリ検索（prep draft 3.48ms）」＋「5 並列アイキャッチ生成と一括 WebP 変換」＋「保存直後 4ms の即時検問と Astro 高速ビルド」 を一切の引っかかりなく同時に回すには、やはり 64GB メモリを搭載した Mac 母艦 と 高速な外付け SSD（大量の過去ログ・アーカイブ保管用） が最高の相棒になります。
これから Apple シリコン世代で 64GB 母艦を組むなら、省スペースかつ圧倒的なメモリ帯域を備える Apple Mac mini（Pro系チップ・64GBメモリ構成） が最も投資対効果の高い 1 台です。
また、「27 インチ 5K の大画面で折れ線グラフの仕上がりや生ログを一覧しながら、コストを抑えて 64GB 環境を手に入れたい」という方には、当ラボの全 16 セッション計測を無停止で走り抜いた現役母艦 Apple iMac 27インチ Retina 5K（2020年モデル・整備済／中古良品） に、自分で簡単に増設できる 【Intel Mac増設用】Crucial DDR4-2666 SO-DIMM メモリ を組み合わせる構成も自信を持っておすすめできます（※ DDR4 メモリは Intel Mac 専用であり、Apple シリコン機には使用できません）。
そして、毎日の自動収集データや数千件の会話トランスクリプト（.jsonl / .sqlite）を高速に退避・検索するための外部ストレージとしては、Thunderbolt 3 対応の SanDisk Professional PRO-G40 SSD や、Mac での取り回しに優れた Crucial X9 Pro For Mac 外付けポータブルSSD を手元に繋いでおくと、容量不足を気にせず何年分もの実測データを蓄積し続けられます。
1本あたり20万トークン以上使ってたお仕事が、6万トークン・4分半でスイスイ終わるようになったニャ！ 道具をボトムアップでコツコツ育てて最後にギュッと束ねると、魔法みたいに速くなるニャ〜。
定型業務をサンドイッチ化させる手順
最後に、「自分のプロジェクトでも、過去の会話ログから時間とトークンの推移を折れ線グラフ化し、よく使うコマンド群を前後の prep と finish に統合したい！」という方へ、コピペで使える設計プロンプトを用意しました。
『Gemini 4 Argon』または同等以上の最上位推論モデル を選び、以下の枠内を貼り付けて実行してみてください。
以下の記事 URL の計測・設計手法（①同一ワークフローの全セッションにおける純稼働時間・ステップ数・新規入力トークン・総プロンプト評価量の抽出、②小刻みな CLI 呼び出しによるクラウド往復ターン税の特定、③意味判断を中央に残した前処理 prep・事後処理 finish への統合）を精読してください。
https://lab.chihouzakki.com/blog/review/api-daily-news-pipeline-token-time-linechart-5gen-evolution/
【厳守してほしい手順】
- 既存のコードや設定は一切変更せず、まず私のプロジェクトの会話ログから「繰り返し実行している定型ワークフロー」の過去セッションを読み取り専用で抽出し、1 成果物あたりの所要時間・ステップ数・トークン消費量の推移を集計してください。
- ログの中で AI が毎回直列で 3 回以上呼び出している「下調べコマンド群」と「事後チェック・同期コマンド群」を特定してください。
- それらを重複出力ゼロの「事前カルテ 1 コマンド（
prep）」と「事後仕上げ 1 コマンド（finish）」へ束ねる改修計画を日本語で提示し、私の合意を得てから実装とビフォーアフター計測を行ってください。