結論：単発CLIが速くても往復回数で時間は溶ける

手元の CLI ツールをどれだけ高速化しても AI エージェントの体感速度が頭打ちになる理由は、処理時間の主戦場がすでに「ローカル PC の CPU」から 「クラウド上の大規模言語モデル（LLM）との通信・推論往復」 へ移っているからです。

真犯人は1往復24秒のクラウド推論ターン税

当サイトのローカル計測基盤（token-dashboard および kb-search brain）で、直近 1 ヶ月間（2026 年 10 月 10 日〜11 月 10 日）の全 951 会話・37,614 回の API コール を集計したところ、驚くべき実態が浮かび上がりました。この 1 ヶ月間で AI エージェントは知識検索バイナリ（kb-search）を 5,469 回、憲法監査・整形バイナリ（gemini-gate）を 2,807 回、合計 8,276 回 も呼び出していたのです。

Google AI for Developers の Function Calling 仕様が示すとおり、AI エージェントがローカルのツールを 1 回呼び出して結果を受け取るたび、裏側では必ず「これまでの全会話・ツール出力履歴の再評価（Prefill）➔ 深い思考トークンの生成（Thinking）➔ 次のツール呼び出し JSON の生成」という 1 ターン分のクラウド推論が発生します。コンテキストキャッシュ（Context Caching）が 90.94% 効いている当サイトの環境でも、1 回の API コールあたり平均 約 118,520 トークン（総プロンプト量 44.58 億トークン ÷ 37,614 回）の評価が走っています。

実際に直近の記事作成・改修セッション 3 件（7bfea34b・9aa9be47・c8686318）のログから、AI が 1 ステップ（1 回の推論＋ツール実行往復）に要している実時間を割り出した結果が以下の通りです。

計測セッションID（先頭8桁）	作業内容	AI純稼働時間	推論ステップ数（Planner）	ツール総呼出数	1ステップあたりの平均所要時間
7bfea34b	新規検証録の執筆・検証（1本）	8.8 分（528秒）	22 回	45 回	24.0 秒 / ステップ
9aa9be47	既存記事群のデータ補強・改修	9.5 分（570秒）	20 回	72 回	28.5 秒 / ステップ
c8686318	検証録の連続作成・検証（2本）	9.6 分（576秒）	17 回	33 回	33.9 秒 / ステップ

つまり、ローカルの Pure Rust バイナリが 0.02 秒（20 ミリ秒） で結果を返したとしても、AI が「まず検索コマンドを叩く ➔ 結果を見て記事カルテを叩く ➔ 次に影響範囲コマンドを叩く ➔ 行番号アウトラインを叩く」と 4 ステップ直列に小刻みな呼び出しを行うだけで、クラウド往復の「ターン税」として約 1.5〜2 分もの待ち時間 が無条件に消えてしまいます。編集後の仕上げ工程でも同様に 4〜5 ステップ刻めば、前後だけで 1 記事あたり 計 3〜4 分 をピンポン通信に費やしていた計算になります。

なぜパラメータ1発の全自動書き換えは危険か

ここで必ず浮かぶのが、「それならパラメータを 1 つ入れたら、下調べから記事の EDIT（書き換え）、仕上げ検査まで全部 1 本のプログラムで全自動実行させれば 1 ターンで終わるのでは？」という疑問です。しかし、ここには絶対に踏み越えてはならない境界線があります。

当サイトの日々の記事運用を整理すると、入り口は大きく以下の 4 パターンに分かれます。

これらの真ん中にある「どう書くか・どう直すか」まで機械的なルールや正規表現で自動化しようとすると、既存のユーモアや実体験の熱量を削り落としたり、主力クエリを改悪して検索順位を飛ばしたり、文脈上の隠れた個人情報を残したりする大事故につながります。「不確定要素（文脈・意味・価値判断）」は最上位 AI（Gemini 4 Argon）の脳に任せ、「確定要素（データ収集・物理行番号の特定・リンク注入・整形・検査・DB 同期）」だけを 1bit の狂いもない Pure Rust パイプラインへ押し出すこと が、品質と速度を両立する唯一の解でした。

小刻み単発呼び出し・無謀な全自動化・決定論サンドイッチ構造の比較

安全だが往復税が重い

従来：小刻みな単発CLI呼び出し

• 下調べで4〜10コマンド、仕上げで4〜6コマンドをAIが1個ずつ直列実行
• ローカル実行は合計0.5秒でも、LLM往復ターン税で毎回3〜4分を浪費
• 各コマンドが同じ見出しやリンク情報を重複出力しコンテキスト窓を圧迫

今回実装した最適解

新方式：決定論サンドイッチ構造

• 前処理 prep 1発で重複ゼロの「物理行番号付き統合カルテ」を生成
• 中央ではAIが意味判断・匿名化・熱量保護に集中して edit_file 等を実行
• 事後処理 finish 1発で商品登録・逆リンク・整形・検査・DB同期を完遂

解決策：AIの意味判断を挟むサンドイッチ設計

この設計思想に基づき、既存の Pure Rust 2 大バイナリへ 前処理一括カルテコマンド prep（kb-search 側） と 事後仕上げ一括パイプライン finish（gemini-gate 側） を新設しました。全体の処理フローは次の 3 ステップだけで完結します。

Pure Rust 前後一括サンドイッチ・パイプラインの3段階フロー

Step 1：前処理（1発）

kb-search prep

4つの入り口（draft / gsc / convo / edit）別に、必要な根拠・類似記事・物理行番号を1枚のカルテへ集約出力。

統合カルテ

Step 2：非決定論（AI）

意味判断と執筆・編集

AIがカルテの行番号とクエリ制約を見て、カニバリ回避・匿名化・熱量100%保全で write_file / edit_file を実行。

MDX反映

Step 3：事後処理（1発）

gemini-gate finish

商品登録・双方向逆リンク注入・太字整形・SHA-256証明・グラフ＆URL検査・定数＆知識DB同期を直列完遂。

前処理4パターンを束ねるprepサブコマンド

./scripts/run_kb_search.sh prep（NPM スクリプト名：npm run 事前カルテ）には、SQLite の FTS5 全文検索エンジンと物理行番号スキャナをインメモリで直結した 4 つの専用モードを実装しました。

事後6工程を直列実行するfinishパイプライン

一方、AI が原稿を書き終えた後に走る ./scripts/run_gemini_gate.sh finish（NPM スクリプト名：npm run 記事仕上げ）は、Rust 標準ライブラリの std::process::Command による外部同期呼び出しとインプロセス関数呼び出しを組み合わせ、以下の Step 0〜6 を単一コマンド内で直列実行します。途中のステップで 1 件でもエラーが出れば即座に後続処理を遮断（フェイルファスト）するため、壊れた状態のまま知識 DB が汚染されることがありません。

実機計測：出力最大83%削減と隠れ6秒罠の発見

実装完了後、自己回帰テスト全 62 項目（rustc -D warnings によるコンパイル警告完全ゼロ検証を含む）の合格を確認した上で、従来の「単発コマンド個別呼び出し」と新方式「prep / finish 一括実行」の実機比較ベンチマークを実施しました。

全4パターンの出力容量と実行時間の比較結果

まず、外部ネットワーク通信や Git 変更状態の交絡因子を完全に排除した純粋なローカル処理条件（ウォームキャッシュ・--no-git・--no-verify-urls 統一）で、下調べ 4 パターンと事後仕上げの「コマンド呼び出し回数」「標準出力バイト数」「ローカル実行時間」を計測した結果が次の表です。

ワークフロー工程	従来方式（個別CLI直列）	新方式（一括統合）	標準出力サイズの比較（削減率）	純ローカル実行時間の比較
① API日報・下書き調査	5 コマンド個別起動	prep draft 1 発	34,543 B ➔ 9,680 B（72.0%減）	59 ms ➔ 27 ms（2.2倍速）
② GSC改善（上位3本）	10 コマンド個別起動	prep gsc 1 発	36,288 B ➔ 9,742 B（73.2%減）	431 ms ➔ 195 ms（2.2倍速）
③ 壁打ち履歴の記事化	5 コマンド個別起動	prep convo 1 発	28,111 B ➔ 4,629 B（83.5%減）	183 ms ➔ 152 ms（1.2倍速）
④ 既存記事の手直し調査	4 コマンド個別起動	prep edit 1 発	25,380 B ➔ 4,727 B（81.4%減）	68 ms ➔ 146 ms（※全体走査込）
⑤ 事後仕上げ・同期一式	5 コマンド個別起動	finish 1 発	898 B ➔ 1,419 B（順位表示付）	6,486 ms ➔ 509 ms（12.7倍速）

※④の prep edit のみ単体実行時間が 68ms から 146ms（+0.078秒）となっていますが、これは内部で全公開記事のリンクグラフ整合まで同時に検査しているためです。0.08 秒のローカル差と引き換えに、AI のクラウド往復 3 ステップ分（約 70〜90 秒）と出力テキスト 81.4%（20.6KB 分） を丸ごと削減できています。

下調べ4大パターンにおける標準出力テキスト量の比較（バイト数）

各枠とも上段『従来（個別CLI直列）』・下段『新方式（prep 1発）』の順で密着配置（小さいほど省燃費）

最大出力削減率:83.5% 削減下調べツール呼出:4〜10回 → 1回

従来：個別コマンド直列出力の合計新方式：prep 1発の統合カルテ出力

GSC上位3記事の下調べ従来：10コマンド合計（gsc-fetch×3 + card×3 + outline×3 + files） ➔ 新方式：prep gsc 1発

36,288 B→9,742 B73.2% 削減

従来

現在

API日報・下書き調査従来：5コマンド合計（outline×2 + search + axiom + const） ➔ 新方式：prep draft 1発

34,543 B→9,680 B72.0% 削減

従来

現在

壁打ち履歴からの記事化従来：5コマンド合計（convo + search + affiliate×2 + const） ➔ 新方式：prep convo 1発

28,111 B→4,629 B83.5% 削減

従来

現在

既存記事の手直し・連鎖調査従来：4コマンド合計（card + impact + outline + files） ➔ 新方式：prep edit 1発

25,380 B→4,727 B81.4% 削減

従来

現在

計測であぶり出した未コミット時の6秒重複検査

さらに今回のベンチマーク計測中、思いがけない「隠れボトルネック」が見つかりました。最初に --no-git オプションを付けない普段通りの呼び出し方で従来の手直し調査（4 コマンド）と GSC 調査（10 コマンド）を計測したところ、純粋なローカル処理のはずが 6,018 ミリ秒〜6,453 ミリ秒（約 6.0〜6.5 秒） もかかっていたのです。

1 コマンドずつミリ秒単位で犯人を切り分けたところ、原因は gemini-gate --files の裏側で毎回走っていたシステム憲法監査（verify_system_constitution）にありました。当サイトでは Rust コードの品質を守るため、Git の未コミット変更に .rs ファイルが含まれていると、自動的に rustc --emit=metadata -D warnings を呼び出してコンパイル警告ゼロを検証する仕組みを入れています。

そのため、「Rust ツールを改良しながら、その検証記事を執筆・チェックするセッション」では、AI が記事の書式確認で --files を叩くたびに毎回裏で 2 クレート分の rustc 型・警告チェック（約 6.0 秒）が重複発火していた ことが判明しました。単体検査を --no-git にすれば 18ms で終わる処理に、毎回 340 倍もの時間を払っていたわけです。

新設した prep と finish では「記事コンテンツとサイトグラフの検問」と「デプロイ直前のシステム全体・Rust 警告検問（--diff）」の責務を明確に分離したため、ツール開発と並行する記事作成でも 6,018ms ➔ 146ms（約 41 倍高速）・事後処理 6,486ms ➔ 509ms（約 12.7 倍高速） へとローカル待ち時間も劇的に短縮されました。

また、もし最初の計測値（6,018ms 対 153ms）だけを見て裏取りを怠っていたら、「どんな時でもローカル処理が 40 倍速くなった！」と誤った結論（実験の交絡因子見落とし）を記事に書いてしまうところでした。異常に遅い数値が出たときに必ず内訳を分解して真因を突き止めることの大切さを、改めて痛感した瞬間です。

実装の急所：自己デッドロックと文体境界の防御

複数の CLI 処理を 1 つのバイナリ実行へ束ねるにあたっては、単に順番に呼び出すだけでは動かない低レイヤーおよびドメイン固有の罠が 3 つありました。これから同様の統合パイプラインを作る方のために、実装で対策したエッジケースを共有します。

同一プロセスflock競合を防ぐ再入ガード

当サイトの gemini-gate では、複数のサブエージェントが同時にアフィリエイト辞書（index.ts）や記事ファイルを書き換えて破損させるのを防ぐため、content-ops という名前付きロックファイルに対して OS カーネルの排他ロックをかけています。

今回 finish パイプラインを実装する際、finish の外枠で content-ops の排他ロックを取得した状態で、内部から商品登録（run_add_affiliate_cmd）や逆リンク注入（run_add_related_link_cmd）の関数をインプロセスで呼び出したところ、同じプロセスのはずなのに自分自身のロック解放を待ち続けて止まる現象 に直面しました。

Linux man-pages の flock(2) 公式仕様を確認すると理由は明快です。プロセス ID（PID）単位で管理される fcntl(2) ロックとは異なり、flock(2) のロックは 「オープンファイル記述（Open File Description：すなわち File::open ごとにカーネル内で作られる構造体）」 に紐づきます。そのため、同一プロセス・同一スレッド内であっても、内側の関数がもう一度ロックファイルを File::open して flock(LOCK_EX) を呼ぶと、カーネルからは「別のファイル記述子からの競合要求」と判定されて 自己デッドロック（Self-Deadlock） に陥るのです。

そこで mutex_lock.rs に unsafe コードを 1 行も増やすことなく、プロセス内で現在保持しているロックキーの集合（Mutex<HashSet<String>>）を管理する再入保護（Re-entrant Guard）を実装しました。

• 外側の finish 開始時 : OS の flock(LOCK_EX) を物理取得し、同時にプロセス内の保持セットへ "content-ops" を登録する。
• 内側の各ステップ呼び出し時 : すでに同一プロセス内で "content-ops" を保持していれば新規 File::open と flock をスキップして ReusedInProcess ガードを返し、最外殻の finish がスコープを抜ける（Drop される）までカーネルロックを確実に維持する。

これにより、他プロセス（別エージェント）からの割り込みをカーネルレベルで 100% 遮断しつつ、同一プロセス内の多段パイプラインをミリ秒で通過させられるようになりました。

敬体と常体の逆リンク自動振り分けとスラッシュ境界

もう 1 つの急所が、finish --related-from で相手記事へ双方向リンクを自動注入する際の「文体と配置場所の境界」です。当サイトには親しみやすい 「です・ます調（敬体）」の検証録（review/） と、冷徹なシステム工学論文調である 「である調（常体）」の AI 国家構想（ai-nation-concept/） の 2 領域が同居しています。

もし検証録用の自動リンク注入ロジックをそのまま AI 国家構想の記事へ流してしまうと、厳格な常体記事の冒頭に「〜を解説しています。」という敬体文と検証録用の枠タイトルが混入し、次の瞬間に憲法監査ゲートでエラー停止してしまいます。そこで toolkit_create.rs と workflow_finish.rs に以下の境界ガードを組み込みました。

実際に本記事自体も、執筆前の骨格・WebP アイキャッチ生成を prep convo --scaffold（358.1ms）で起こし、執筆後の逆リンク 5 本注入・整形・URL 死活検査・DB 同期までを finish 1 発で仕上げる「ドッグフーディング」によって公開しています。

最初から一括で作らずボトムアップで連携させた勝因

すべての実装と本番公開が一発で通った直後、今回の開発を振り返って次のような対話になりました。

これからご自身の環境へ導入される際も、もしまだ個別の検索・整形・検査部品が固まっていない段階であれば、いきなり巨大な一括パイプラインから書き始めるのではなく、まずは目の前の手作業を 1 つずつ小さな確定動作ツールへ切り出すボトムアップ手順から始めるのが確実です（この設計原則の深掘りと全 7.1 万行の進化内訳は、続編『AI自動化をトップダウンで作ると失敗する理由｜ガルの法則とボトムアップ開発の実証録』にまとめました）。

母艦マシンの1日単価とAI実装プロンプト

最後に、数万行規模の Pure Rust 2 バイナリと 963MB のローカル SQLite データベース、そして Astro 7 の高速ビルドを RAM ディスク上で軽快に回している開発母艦のコスト感と、読者の方がご自身のプロジェクトへ「前後一括サンドイッチ構造」を導入するためのプロンプトをまとめます。

5年稼働のMac母艦とRust定番書の快適コスト

クラウド上の AI 推論往復（1 ステップ約 24〜34 秒）を最小限に抑えるには、手元のマシン側で SQLite 全文検索や全記事グラフ走査、ネイティブコンパイル（rustc -O）を一瞬で片付けられるメモリ帯域と容量が大きな武器になります。特に 64GB クラスのメモリを積んでコンパイル一時領域やキャッシュを RAM ディスク（メモリ上の仮想ドライブ）へ逃がすと、内蔵 SSD の寿命を削らずに済みます。

たとえば 64GB ユニファイドメモリ構成の Apple Mac mini（M4 Pro 等） や、筆者が現役で愛用している 27 インチ iMac 5K（2020 年 Intel 最終世代の整備済品＋Crucial DDR4 メモリ 64GB 増設） を母艦にする場合、初期費用が仮に 20万〜35万円前後であっても、毎日 5 年間（1,825 日）使い続ければ 1 日あたりの快適コストは約 110円〜192円（推論・単純日割り試算） です。自分は手を汚さず AI に安全・高速なパイプラインを回させ、1 記事あたり数分ずつ確実に自由時間を生み出せる「タイム・イズ・マネー」の投資として非常に合理的だと感じています。

また、今回の flock(2) 再入ガードや Drop によるリソース解放、エラー型の伝播など、AI が実装した Rust パイプラインの安全性を人間側でも確信を持ってレビューしたい方には、手元に 1 冊あると何年も引ける『プログラミングRust 第2版』が定番の良書です（5 年使えば 1 日あたり約 3 円です）。

最上位AIに前後一括パイプラインを組ませる指示文

ブログ執筆に限らず、Web アプリ開発や業務自動化でも「AI が毎回同じような調査コマンドと事後チェックコマンドを何個も直列で叩いているな」と感じたら、本記事のサンドイッチ構造がそのまま応用できます。軽量モデルではなく 必ず『Gemini 4 Argon』または同等以上の最上位推論モデル を選択し、以下のプロンプトを貼り付けて現状のワークフロー棚卸しから始めさせてみてください。

参考記事（https://lab.chihouzakki.com/blog/review/ai-tool-roundtrip-tax-pure-rust-sandwich-pipeline/）の「決定論サンドイッチ構造（prep ＋ AI意味判断 ＋ finish）」を踏まえて、このプロジェクトでAIエージェントが毎回小刻みに呼び出しているコマンド群を整理・一括化する設計案を提示してください。

【厳守ルール】
1. いきなりコードを書き換えたり既存コマンドを削除したりせず、まず直近の作業パターン（機能追加・バグ修正・データ更新・記事作成等）を3〜4種類に分類し、各パターンで毎回直列に呼ばれている「前処理（検索・構造把握・影響範囲調査）」と「事後処理（整形・リンタ・テスト・索引更新）」を洗い出して合意を得ること。
2. 文脈理解や設計判断、既存コード・文章の意図保護など「不確定要素（非決定論領域）」まで無理に自動書き換えスクリプトへ押し込まず、そこは中央のAI編集ステップとして明確に残すこと。
3. 前処理（prep）では複数ツールの出力を単純連結するのではなく、重複情報を剥がして物理行番号付きのコンパクトな1枚のカルテ（＋必要に応じ `--json` 出力）へ集約し、コンテキスト消費量を削減すること。
4. 事後処理（finish）では途中ステップで1件でもエラーが出たら即座に停止（フェイルファスト）させ、同一プロセス内でファイルロック（flock等）が再入競合しないよう安全ガードと `--dry-run` モード、自己回帰テストを必ず実装すること。
5. もしまだ個別の単機能部品が未整備または未テストの場合は、いきなりトップダウンで全体統合パイプラインを作らず、まず各部品単体の実戦動作確認と自己テスト合格をボトムアップで済ませてから統合へ進むこと。

まとめ：小刻みなピンポンを断ち人間の判断へ集中

今回の「前後一括サンドイッチ・パイプライン（prep ＆ finish）」の実装と実機ベンチマークから得られた結論を整理します。