---

結論：モデルと環境で5段階に爆発した実測推移

まずは当サイトのローカル知識データベース（SQLite）と会話履歴データベース（全 2,631 スレッド）、および Git のデプロイ履歴から集計した 「第 0 世代〜第 4 世代の実測推移」 を一覧表でご覧ください。

公開記事数とデプロイ回数の世代別比較表

当サイトでは読者に正確な時系列を伝えるため、記事の公開日（pubDate）について「旧 WordPress 移行記事（78 本）は当時の元投稿日」「AI との壁打ちや実機写真から起こした記事は初回の壁打ち開始日・EXIF 撮影日」を刻印する厳格なルールを採っています。そのため、表では ① pubDate 基準の記事数・文字数 と、実際の生産スピードの爆発をそのまま映し出す ② AI 会話スレッド数・Git 本番デプロイ回数 の両方を並べています。

表の数字を追うと、2 つの強烈な事実が浮かび上がります。

1 つ目は、「記事数が爆発しているのに、1 記事あたりの密度は薄くなるどころか約 2 倍に濃くなっている」 という点です。手書きの WordPress 時代には平均 5,460字 だった記事が、第 3 世代（Argon 導入）で 10,374字、第 4 世代（全面 Rust 化）では 10,624字 に達しています。しかも全公開記事が 5,699 本の内部リンクで結ばれ、孤立記事ゼロ・49 項目の機械監査違反ゼロを維持しています。

2 つ目は、Git のデプロイ（本番反映）回数が「月 1〜4 回」から「月 895 回（10月）」「8 日間で 192 回（11月）」へと文字通り桁違いの相転移を起こしている ことです。これは人間が手作業でブラウザを確認して恐る恐る公開していた状態から、AI とローカル機械検問が自動で品質を保証してノンストップで本番へ送り出す体制へ完全に切り替わった瞬間を示しています。

なぜモデル変更だけでは記事が増えないのか

世の中では「新しい AI モデルが出れば、それだけで作業が何倍も速くなる」と思われがちです。しかし実際に数百記事規模のサイトを育ててみると、モデルの頭脳が上がるたびに記事数とルールが増え、必ず「手元の環境のボトルネック」に激突して失速する というサイクルを繰り返しました。

AIモデルとローカル環境が交互に限界を突破する成長サイクル

AIモデルの世代交代

より賢いモデルが登場し、人間が1文字ずつ書く負担が消えて記事数と設計ルールが一気に増える。

執筆量が増加

環境の物理限界に激突

記事とルールが増えた瞬間、コンテキスト溢れ・勝手な改変・シェル遅延・週途中のクォータ枯渇が発生する。

手戻りと枠切れ

器とツールの全面刷新

エディタ乗り換え・RAMDisk・SQLite索引・全面Pure Rust化で、AIの迷走と待ち時間を物理的に断つ。

雑務を機械分離

質と量の同時大爆発

半日作業が1時間に縮まり、クォータ消費も激減して日産10本超×平均1万字超の安定稼働へ突入する。

次の次元へ

ここからは、第 0 世代から第 4 世代まで、実際にどんな壁にぶつかり、どうやって乗り越えてきたのかを順番に振り返ります。

---

第0〜第1世代：手書きの限界とWeb版AIの罠

最初の転換点は、「そもそも人間がすべて手作業で組み立てる WordPress 運営の限界」と、「Web ブラウザ上のチャット AI に原稿を書かせる初期手法の限界」でした。

写真処理と装飾で手が止まったWordPress時代

当サイトの前身となる WordPress（テーマ：Cocoon）を立ち上げたのは 2020 年 8 月のことでした。立ち上げ当初の 4 ヶ月間は熱意だけで月 10〜14 本の記事を書いていましたが、すぐに重い現実がのしかかりました。

WordPress はとにかく 1 記事を作るのに時間がかかり、とりわけ写真の扱いに膨大な手間を奪われる のです。実機レビューを書くたびにカメラやスマホから何十枚もの写真を取り込み、表示速度が落ちないように解像度をリサイズし、メディアライブラリへアップロードして 1 枚ずつ記事へ貼り付け、さらに吹き出しやボックス装飾・商品リンクのショートコードを整える必要があります。

本当に書きたい「中身の検証」以外の周辺作業があまりに重く、次第に「またあの写真整理とブロック装飾をやるのか……」と面倒になっていきました。結果として 2021 年後半からは更新が急減し、2022 年〜 2025 年末までの約 4 年間は 年にわずか 1〜2 本 しか記事が増えない事実上の休眠状態（5 年半トータルで 85 本）に陥っていました。

長文で中身が勝手に変わるChatbot期の苦闘

その停滞を打ち破ろうと、2026 年 1 月 22 日に WordPress を捨てて静的サイトジェネレーターの Astro へ完全移行し、Web ブラウザ版の Chatbot Gemini と壁打ちしながら .mdx 形式の原稿コードをもらう「第 1 世代」がスタートしました。

この手法により、2026 年 2 月〜 3 月にかけて「AI 国家構想」の初期骨格となる約 200 本の記事を一気に立ち上げること自体はできました。ところが、記事を深く長くしようとした途端、Web チャット型 AI 特有の 深刻な 2 つの欠陥 に直面します。

---

第2世代：IDE導入でも消えない二重生活と枠切れ

コピペ往復の限界を痛感し、2026 年 8 月から導入したのが、AI エージェントが直接ローカルのファイルを読み書きできるスタンドアロン版の Antigravity IDE（当時の主力モデルは Gemini 3.1 Pro や 3.8 Flash）でした。9 月には 64GB メモリを積んだ母艦 iMac 上に 16GB の RAMDisk（高速メモリディスク） も構築し、内蔵 SSD の摩耗を防ぎながらビルド環境を整えました。

Web版とIDEを往復した中身の手直し地獄

エディタ統合型の Antigravity IDE に入ったことで、確かに第 1 世代よりは生産性が上がり、9 月には単月 97 本（pubDate 基準）までペースが回復しました。しかし当時の会話データベースを見返すと、奇妙な数字が残っています。8 月〜 9 月は Antigravity の会話が月 302 件 → 492 件へ増えたのと同時に、Web 版の Chatbot Gemini の会話も月 101 件 → 267 件へと急増していた のです。

さらに記事数が増えるにつれて、プロジェクトの憲法であるルールブック（GEMINI.md：現在は 1,272行・約504KB 規模）が肥大化し、ハーネス側の 24KB・2 万トークン制限の壁 を突破して後半のルールが切り捨てられる現象も重なりました。とくに軽量な Gemini 3.8 Flash を使ったセッションでは、言葉の表面（字面）だけに過剰反応して明後日の方向へ突っ走り、1 つの記事スレッドで 27 往復・691 ステップもの手戻り地獄 に陥ることもありました。

週の途中で何度も作業が止まったクォータの壁

この「中身のやり直し連発」が引き起こしたもう 1 つの致命傷が、利用制限枠（週間クォータ）の異常な消耗 です。

AI とのやり取りは、同じスレッドで「違う、そうじゃない」「ここも直して」と往復を重ねるほど、それまでの長い会話履歴が毎ターン雪だるま式に再送信されます。当時の契約プラン（Google AI Pro）では、この手戻りトークンが枠を猛スピードで食い潰し、「さあ週末にまとめて進めよう」という週の途中で制限ロック（リセットまで数十時間待ち）にかかって作業中断になる事態が何回も発生 しました。

別系統の Claude モデルへ一時避難しても数時間で枠が 0% になり、まさに「書きたいネタは山ほどあるのに、AI の手戻りとクォータ切れに足を引っ張られる」フラストレーションの極みにありました。

---

第3世代：Argon誕生とVS Code移行の転機

この閉塞感を根底から覆す歴史的な転機が訪れたのが、2026 年 10 月中旬のフラッグシップモデル『Gemini 4 Argon』の発表 でした。

旧Pro引退を機にVS Codeへ乗り換えた理由

Gemini 4 Argon が発表された直後、思いがけない環境変化が同時に起きました。それまでスタンドアロン版の Antigravity IDE で頼りにしていた旧主力モデル Gemini 3.1 Pro が個人向けメニューから引退 し、さらに スタンドアロン版の Antigravity IDE 単体メニューでは新登場の Argon も直接サポートされない ことが判明したのです。

「このまま単体版 IDE に残っていたら、手戻りの多い軽量モデルしか使えなくなる」――そう判断した筆者は、迷わず開発母艦を 本家 Microsoft 製 Visual Studio Code（＋公式 Antigravity 拡張機能） へ全面移行し、この時点ではまずサブスクリプションを 1 段上の 『Google AI Ultra（5x）』 へと切り替えました。

結果として、この「強制された引っ越し」が大きな転機になりました。本家 VS Code へ移ったことで拡張機能の互換性トラブルが消え、2,000 件超の履歴をミリ秒検索できる自作 3 カラム拡張『Convo Mail』 も 1 画面に統合でき、常時 Gemini 4 Argon (High) を直接指定して動かせる土台が整ったのです。

監査で中身が激変し目視確認が不要になった衝撃

第 3 世代に入り、本家 VS Code 上で Gemini 4 Argon (High) に既存記事の監査と改修を何度か任せてみた瞬間、背中がゾクッとするほどの衝撃を受けました。

AIが止めた20xすら8割溶けた2度の衝撃

実は当時、別枠で API の従量チャージ残高もたっぷり入れていたにもかかわらず、エディタ側の「週間枠（Weekly Limit）」の上限に引っかかり、数日間まったく Argon が使えなくなる事態 が発生しました。

そこでどうすべきか AI 自身に相談してみたのですが、返ってきたのは現場の実感とズレた「教科書通りの一般論」ばかりでした。

• AI の提案①「普段は 3.8 Flash や Claude Opus / Sonnet に切り替えましょう」 → 過去に軽量モデルの曲解・手戻り地獄や、他社モデルの勝手な論旨丸め込み・数時間での枠枯渇で散々痛い目に遭っていたため、きっぱり断りました。

• AI の提案②「個人のブログ開発では 20x 枠は絶対に使い切れないので 5x のままで十分です」 → 最上位の Ultra 20x へ上げるのはどうかと尋ねても、AI からは「ブログ開発程度で 20x はオーバースペックで使い切れません」と何度も止められました。

しかし、リセットまでの数日間ずっと手を止めて遊んでいる方がよほど時間がもったいないと考え、AI の制止を振り切って最上位の 『Google AI Ultra（20x）』 へ切り替えました。

ところが驚くべきことに、当時はやりたい改修や新規企画が山のように溜まっていたため、20x に上げた直後から Argon で一気に片付け始めたところ、AI が「絶対に使い切れない」と太鼓判を押していたはずの 20x の巨大な週間枠ですら、あっという間に 80% 以上を消費する事態を 2 回も経験した のです。

つまり、「最上位の Ultra 20x に課金しただけでは、まだ大量処理時のクォータ消費問題は根本解決していなかった」 のです。

---

第4世代：AIの制止を振り切った全面Rust化

「Argon の圧倒的な正確さは手放せないが、このまま何百本もの記事検索やルール照合まで全部 AI に力技で読ませていたら、時間も半日かかるし 20x の週間枠まで溶けてしまう。AI にやらせなくていい定型処理はすべて手元の PC 側へ引き剥がし、しかも極限まで高速化するしかない」――そう決断して 2026 年 11 月に踏み切ったのが、ローカル処理を総動員してあらゆるスクリプトをネイティブ機械語へ置き換える 「第 4 世代：PC 処理分離 × 全面 Pure Rust 化」 でした。

もっとも、普通の個人開発であれば「ブログの裏側をいきなり Rust で書き直す」なんてハードルが高すぎて躊躇するところです。筆者が迷わず Rust 化へ踏み切れた背景には、その少し前に体験した 「AI の実装力に対する決定的な確信」 と、手応えを確かめながら広げた段階的な成功体験がありました。

血糖値とお米のアプリで確信したAIの実装力

それまで世間ではよく、「AI にアプリを作らせると、画面の見た目だけはそれっぽく出来るけれど、肝心の中身（計算ロジックや細部の挙動）は使い物にならない」 と言われていました。

そこで当初は 「Mac での開発ならやっぱり Swift でしょ」 と考え、自分の毎日の健康・食事管理のために Swift（SwiftUI）で 「血糖値のアプリ」 と 「お米のアプリ」 を Argon に作らせてみたのですが、結果は世間の評判とはまったく違っていました。

• 自作アプリ①：血糖値の管理・運動予測アプリ ：持続グルコース測定器（Dexcom G7）の数値を Mac の画面上に 5 分おきに自動取得し、座りっぱなしと食後ウォーキングで目標値に戻るまでの時間差をグラフ化する SwiftUI 製アプリ（およびブラウザから登録不要で試せる公開版の 血糖消費＆食後運動シミュレーター）を作らせてみました。日本専用サーバーへの複雑な 2 段階認証や Keychain 保護まで含め、最初から実用十分な精度で動きました。

• 自作アプリ②：お米・もち麦の炊飯栄養計算アプリ ：炊飯時の水分蒸発による誤差をなくし、「投入した生穀物のグラム数」と「炊きあがり後の実測重量」から 1g 単位で正確な糖質量と水溶性食物繊維（β-グルカン）を比例逆算する SwiftUI 製アプリ（および公開版の カロリー＆炊飯栄養計算機）を作らせたところ、2 釜同時計算から A4 サマリー印刷まで、まさに自分が欲しかった通りの道具が完成しました。

SQLiteとMDX検査から広げた段階的Rust化

人間がゼロから手書きするとなると所有権やライフタイムの壁が高くて尻込みしがちな Rust ですが、当の AI 本人が「バックグラウンド処理なら Rust がベストだし、書くのも得意だ」と言うなら試さない手はありません。そこで、いきなりすべてを書き換えるのではなく、以下の順番で 1 つずつ実力を確かめながら Rust 化を広げていきました。

型消去と遅さを嫌いJSもPythonも根こそぎ撤去

実はこの「あらゆる処理の全面 Rust 化」を切り出した当初、AI 自身からは「ボトルネックの大半はクラウド側の AI 推論時間やネットワーク通信なので、ローカルのスクリプトを Rust 化してもトータル時間は大して速くなりませんよ」と止められました。

しかし、すでに SQLite と MDX 検問の Rust 化で確かな手応えを掴んでいたことに加え、システム開発の視点からも、AI が毎ターン裏側で呼び出している既存スクリプト群の「塵も積もれば山となる遅延と危うさ」は見過ごせませんでした。

1. シェルコマンド（ls・grep・awk・cat）の往復ロス ：AI が手探りでシェルを 1 回叩くたびにプロセス起動コストだけでなく、「結果を読んで次の手を考える数秒〜十数秒の推論往復」が何十回も積み重なります。

2. Node.js（JavaScript / TypeScript）と Python の起動遅延 ：エディタの Hooks（自動フック）や検索スクリプトが呼ばれるたび、Node.js の V8 エンジン起動税（約 78ms）と約 9,000 行のモジュール連鎖読み込み、あるいは Python インタープリタの重い初期化が毎回発生していました。

3. 「型宣言しても実行時には無意味」という構造欠陥 ：さらに決定的だったのが、TypeScript の型消去（Type Erasure）や Python の型ヒントの限界 です。これらの言語はコード上でいくら綺麗に型を書いても、実行される瞬間には型情報がすべて剥がれ落ちてただの動的スクリプトに戻るため、600 記事規模の複雑なデータを扱った際に「本番の珍しい境界値で突然落ちる・AI が古い幽霊関数を呼び出す」事故を物理的に防げません。

そこで AI の「大して速くならない」という言葉を振り切り、プロジェクト内にあった 約 2.6 万行超の JavaScript・TypeScript・Python・シェルスクリプトを根こそぎ撤去 して、外部クレート（外部ライブラリ）すら一切使わない Pure Rust 製の 2 大ネイティブバイナリ（憲法検問・執筆支援エンジン gemini-gate と、知識・履歴 SQLite 超高速検索エンジン kb-search） へ完全統合しました。同時に、AI が探索目的で ls や grep などのシェルコマンドを使うこと自体をルールで全面禁止しました。

第2〜3世代（スクリプト混在・手探り期）と第4世代（Argon×全面Pure Rust）の決定的な差

🐢 Rust化前：半日仕事と枠消耗の悪循環

• シェル手探りと全文丸読み ：AI が grep や cat を何十回も連発し、そのたびに 10 秒前後の推論待ちと大量のログ履歴が膨張する。

• V8・Python起動税と型消去の罠 ：毎ターンの Hooks や検索で数百ミリ秒〜数秒引っかかり、実行時まで分からない型不一致エラーで手戻りが起きる。

• 大量作業で半日コース ：数十記事の更新や大規模監査を回すと半日以上拘束され、無駄な往復ステップでクォータも削られる。

🚀 第4世代：1時間完遂・枠が減らない快適環境

• 数ミリ秒のSQLite直結ピンポイント取得 ：660本超・565万字の知識DBから必要な物理行番号だけを 5〜20ms で抜き出し、AIの丸読みを根絶。

• コンパイラ物理ロックと0.6秒検問 ：型や引数が1箇所でも狂えばバイナリ自体が作られず、RAMDisk常駐の gemini-gate が49項目を一瞬で検問。

• 半日作業が1時間前後・クォータほぼ無傷 ：迷走ゼロ×4〜6班排他並列により、大量の新規作成や数十件の一括改修が30分〜1時間そこらで完了する。

本体更新と自動リビジョンアップでさらに加速

さらに最近になって、「手元の自作スクリプトだけでなく、土台である Rust コンパイラ自体と Astro フレームワーク自体のバージョンアップもやれば、もっと高速化するのでは？」と気づき、据え置きがちだった本体側もついに最新版へと引き上げました。

• Rust 本体の最新化（Rust 1.99.1 ／ LLVM 23） ：コンパイラバックエンドの刷新による機械語最適化に加え、新しく標準化された機能を取り入れて自作ツール内の unsafe コード完全撤去とゼロコピー文字列化を実施しました。

• Astro 本体の最新メジャー移行（Astro 5 → Astro 7.4） ：内部処理が Rust 製 3 大エンジン（.astro コンパイラ・高速 MDX エンジン Sätteri・Vite 8 Rolldown）へ生まれ変わった最新系へ完全移行した結果、古い JavaScript 依存パッケージ 184 個 が一掃され、全 2,250 ページ超の静的バンドル時間が 35.25秒 → 10.50秒（約 3.3 倍高速化・全体ビルド約 28 秒） へと一気に短縮されました。

しかも「一度最新にして終わり」ではまた数ヶ月後に古くなってしまうため、定期的に自動でリビジョンアップ（更新巡回）が回る仕組み（macOS 標準 launchd × Pure Rust 製モジュール rust_updater.rs） まで作り込んでもらいました。毎週金曜朝に AI トークン消費ゼロで自動巡回し、初期バグが出やすい初回リリース（.0）は保留して新機能だけ通知する一方、安定した修正リビジョン（.1 以降）が出たら 無人で rustup update → RAMDisk バイナリのクリーン再ビルド → 全 58 項目の自己診断テストまで自動完走 させ、Astro 側も安定版や高速化更新を選別して自動提案する体制にしています。

半日作業が1時間になりクォータも減らない理由

「大して速くならない」と言われていた全面 Rust 化をやり切った結果、日々の運用は別次元へと激変しました。

まず体感速度において、以前は 半日以上かかることもザラだった大量の記事更新やまとめ作成が、今では 1 時間やそこら（新規 6 本フル執筆＋既存 6 本補強＋周辺 24 件リンク結線の計 36 件更新でも実測 32.8分、全 372 本・297 万字の順番通読監査でも 91分）でサクッと終わる ようになりました。単発の写真レビュー記事作成も 32.1 分から約 4.6 分（約 7 倍速） へ短縮され、2026 年 11 月に入ってからの わずか 8 日間だけで公開ベース 116 本（123.2 万字）・最終更新 180 本 という過去最大の爆発力を記録しています。

そして何より嬉しかった最大の成果が、「PC 側の処理を組み込み、ほぼすべての処理を Rust 化したことで、ようやくどんなに大量の処理を回しても週間枠がほとんど減らなくなった」 ことです。

実際に第 4 世代の基盤で計測したところ、84 記事の一斉監査・改修を完遂しても Google AI Ultra の週間枠消費はわずか 2%、577 記事規模の全体監査・343 記事改修でも週間枠 4% しか減りませんでした。「AI にコードを書かせる時代だからこそ、人間が書きやすい遅いスクリプト言語に妥協せず、最初から機械語にコンパイルされる Pure Rust で足回りを固める」ことが、時間とクォータの両方を守る最強の答えだったのです。

---

まとめ：AI時代の生産性は母艦環境で決まる

WordPress 手書き時代の 85 本から、公開 669本・565 万字超へ至った 5 世代の歩みを振り返ると、1 つの揺るぎない原則が見えてきます。

長期使う開発母艦と上位AIの時間単価試算

第 4 世代のように、16GB の RAMDisk 上で数万行の Pure Rust コンパイル・巨大 SQLite データベース・数百記事の Astro ビルド・4〜6 班の並列 AI エージェントを同時に無停止で走らせるには、メインメモリを 64GB 積んだローカル開発母艦 と、安全な静的ファイルを配信する高速レンタルサーバーの組み合わせが絶大な威力を発揮します。

値札の総額だけを見ると高く感じるかもしれませんが、見栄のための消費とは違い、開発母艦と AI 環境は「自分の時間と快適さを毎日生み出し続ける設備投資」です。仮に 64GB ユニファイドメモリ搭載の Apple Mac mini（M4 Pro 構成） や、筆者も現役で使い倒している 27 インチ iMac 5K（2020 年 Intel 最終世代の整備済品 ＋ Crucial DDR4 64GB メモリ自己増設） を導入して 5 年間（1,825 日）毎日使った場合、1 日あたりの母艦コストは約 110 円〜 192 円（推論・単純日割り試算）、缶コーヒー 1 本分ほどに過ぎません。

同様に Google AI Ultra（月額 32,000 円クラス）も、1 日あたりに割れば約 1,067 円（推論）です。かつて半日（4〜6 時間）潰れていた大量更新やリライトが 1 時間で終わり、週途中のロックによる作業停止もゼロになって毎日 3〜4 時間の自由な時間が生まれると考えれば、時給換算でこれほど投資回収の速い選択はありません。

また、Astro でビルドした純粋な静的 HTML / WebP ファイルを高速・安定して公開する配信先には、PHP を動かさない静的ホスティングとしても抜群の応答速度と安定性を誇る エックスサーバー（XServer） が鉄板です。さらに、AI に書かせる Rust バイナリのメモリ安全性や設計思想を人間側でも押さえておきたい方には、5 年使えば 1 日約 3 円の知識投資になる名著『プログラミングRust 第2版』を手元に置いておくことをおすすめします。

自分の環境を第4世代へ進化させるプロンプト

最後に、現在 WordPress や初期の AI エディタ環境で「手直しが多い」「作業が遅い」「クォータがすぐ減る」と悩んでいる方が、ご自身のプロジェクトを段階的に第 4 世代へ引き上げるための診断プロンプトを用意しました。軽量モデルではなく、必ず『Gemini 4 Argon』または同等以上の最上位推論モデル を選び、以下の枠をコピーして貼り付けてみてください。

参考記事（https://lab.chihouzakki.com/blog/review/ai-blog-posts-explosion-5-generations-argon-rust-chronicle/）の「第0世代〜第4世代の進化プロセス」を踏まえて、現在の私の執筆・開発環境がどの世代のどのボトルネックで詰まっているかを調査し、段階的な改善計画を立ててください。

【厳守ルール】
1. いきなり既存ファイルを書き換えたり削除したりせず、まず現在のリポジトリ構成・記事数（ファイル数）・ルールファイルのサイズ（24KB超過の有無）・散在している自作スクリプト（.sh / .js / .mjs / .ts / .py 等）・および Astro / Node / Rust 等の本体バージョンを調査して報告すること。
2. 調査にあたっては ls / grep / cat 等の無駄なシェル往復を最小限に抑え、エディタのネイティブ読み取り・検索機能を優先すること。
3. 現在の課題に対して「①既存の強みを壊さず最小の手間で最大効果が出る改善トップ3（例：SQLite索引のRust化、MDX規約検問のRust分離、Node/Pythonスクリプトの段階的Pure Rust統合、コンパイラ・フレームワーク本体の最新化と定期自動更新チェック、サブエージェント排他分担など）」と「②今はまだやらなくてよい過剰な手直し」を明確に分けて提示すること。
4. 私の合意を得てから、テストで既存出力・レイアウトとの完全互換を確認しつつ1段階ずつ安全に実装を進めること。

AI のモデルが進化するスピードはこれからも止まりませんが、その知能を「やり直し地獄」で空回りさせるか、「1 時間で数十本を仕上げる無敵の相棒」へ変えるかは、手元の環境設計ひとつで決まります。ぜひご自身のペースで、ストレスゼロの発信基地を育ててみてくださいね！