
Gemini 4 Carbonで全記事・Astro・Swift・RAMDiskを監査|隠れバグ根治とArgon分担
普段のブログ運営や個人開発で、エラーも出ずサクサク動いているシステムを見ると「もう完成域に入ったな」と安心してしまうものです。当ラボ(公開 710記事 規模:AI国家構想 383本 + 検証録 327本)の Astro 7 基盤、Pure Rust 製 CLI ツール、自作 macOS SwiftUI アプリ 6 本、そして 16GB RAMDisk 自動化環境も、『Gemini 4 Argon(アルゴン)』 と二人三脚で構築し、日常運用では何ひとつ不自由なく稼働していました。
ところが 2026 年 11 月 10 日に一般開放された最上位モデル 『Gemini 4 Carbon(カーボン)』 に対し、「ファイルは書き換えず(Read-only)、Argon が見落としがちな重箱の隅を徹底監査して」と全 4 領域を丸ごと投げたところ、まさかの大量ダメ出し(並行ロック競合・無差別 CORS 脆弱性・冬眠プロセスの画面ロスト・macOS TCC 権限拒否による 1.53 GB 未退避・記事を跨ぐ法改正数値ズレ 108 本分など) を食らい、半日で一気通貫の根治とビルド約 108 倍 高速化まで完遂することになりました。
本記事では、「動いているのに潜んでいた時限爆弾」の生々しい実例と修復結果、4 大監査セッションの実測トークン内訳、そして読者がそのまま自分のコードや環境を Carbon に監査させられるコピペ用プロンプトまで包み隠さず公開します。
-
Gemini 4 CarbonとArgonで同じ記事を作らせた実測比較|時間・料金2.55倍差と生記事公開 : 同じ 3 行プロンプトで 1 本の記事をゼロから書かせた結果、なぜ「執筆の主力は Argon」と言い切れるのかを無編集の生記事 2 本つきで実証しています。
-
Gemini 4 Carbon一般開放とAntigravity「/swarm」|Argonとの使い分けと料金2倍対策 : 2026 年 11 月 10 日解禁の公式ベンチマーク 3 冠と、12 月からの標準単価 2 倍を見据えた
Google AI Ultra 20x前提の運用設計を解説しています。 -
GEMINI.mdが500KBで勝手に切れる罠|VS Code差分上限の真因とRust検問防衛 : エディタ拡張の
500 KiB差分プレビュー上限でルール末尾がサイレント切断された事件と、Pure Rustgemini-gateによる機械検問の仕組みをまとめています。 -
VS Code・Antigravity用チャット履歴拡張機能を自作|SQLite全文検索で過去ログ即発見 : 今回の監査でローカル HTTP セキュリティと XSS 防御が劇的に強化された自作拡張機能『Convo Mail』の設計録です。
-
Macの暴走アプリを止めるSwiftUI自作ツール2選|CoreMonitorとMacChiller開発録 : 今回の Swift 監査で「冬眠させると Top 10 から消えて解凍できなくなる罠」が見つかり根治した自作プロセス管理ツールの開発記録です。
-
RAMDiskのAI会話ログ肥大化を自動解決!直近3日残してSSDへ退避するRust運用術 : 今回の環境監査で「macOS TCC 拒否による
1.53 GB滞留」とlsof引数ミスが判明し完全復旧した 16GB RAMDisk 自動退避システムの解説です。
-
普段の AI コーディングで 「エラーなく動いているから問題ない」と思っている既存コードや環境 に、どれほど隠れたエッジケースが潜んでいるか実例を知りたい方
-
解禁された 『Gemini 4 Carbon』と既存の『Gemini 4 Argon』を、執筆・開発・監査・環境構築のどこでどう使い分けるのが一番賢いか 結論を知りたい方
-
他社 AI にありがちな「正常なコードまでイチャモンをつけて壊す過剰修正」を防ぎつつ、本物のバグだけを Carbon に洗い出させる監査プロンプト を使いたい方

ちょっと待ってくれい! つい昨日まで Argon で記事もツールもバンバン作って、「不具合ゼロで快調じゃ!」と胸を張っておったじゃろ? それを Carbon に見せた途端に大量のダメ出しを食らったとは、一体どういうことなんじゃ!?

私も最初は「さすがに重箱の隅をつついても、せいぜい数箇所の細かい表記揺れくらいだろう」と思っていたんです! ところが蓋を開けてみたら、「普段の通常操作では 100% 素通りするのに、特定の条件が重なった瞬間に牙を剥く時限爆弾」 が全 4 領域からザクザク出てきて、背筋が凍りました……!
なぜ快調だったArgon資産をCarbonで総監査したのか
きっかけは、前日に実施した Argon と Carbon の同一記事ブラインド執筆テスト でした。ゼロから長文記事を 1 本書かせた場合、熱量や具体例の掘り起こし・速度・コスト効率では Gemini 4 Argon (High) が快勝した一方で、裏側の思考ログには 「近道をせず、制約と境界条件を 1 ミリも踏み外さない Carbon の異常なまでの誠実さと検問眼」 が記録されていました。
そこで、「それなら Argon がこれまで積み上げてきた当ラボの全資産を、実装者とは別の目線(セカンドオピニオン)として Gemini 4 Carbon (High) に丸ごと監査させたらどうなるのか?」と試しにぶつけてみたのが今回の総点検です。
総読込1.42億トークン!4大監査の実測規模
監査対象は、記事ファイルだけではありません。Web フロントエンド(.astro / .ts)、裏側の Pure Rust 2 大バイナリ(gemini-gate / kb-search)、デスクトップで毎日使っている自作 Swift アプリ群、さらに macOS の起動スクリプトや launchd・16GB RAMDisk 設定まで、システム全体を 4 つの独立セッションに分けて徹底走査しました。
Antigravity の実行ログ(transcript.jsonl)から集計した、4 大監査+即日改修セッションの正確な実測データは以下のとおりです。
| 監査・改修セッションの対象領域 | AI純稼働時間 (監査+改修) |
親ステップ / ツール実行数 |
並列Sub エージェント |
親子合算 新規入力(Fresh) |
親子合算 総読込トークン |
親子合算 出力トークン |
|---|---|---|---|---|---|---|
| ① 全 Astro・TS・Pure Rust 基盤 ( .astro / .ts / 2大Rust CLI / 拡張) |
131.4 分 |
117 steps /226 tools |
8 体 |
8,798,642 |
63,748,167(Cache率 86.2%) |
785,622 |
| ② 全公開記事 横断監査&108本改修 (監査時点 709 本・約 623 万字) |
369.9 分 |
88 steps /191 tools |
9 体 |
9,442,648 |
42,308,441(Cache率 77.7%) |
767,508 |
| ③ 自作 macOS Swift アプリ全 6 本 (SwiftUI 6 パッケージ+ .command 4本) |
50.8 分 |
32 steps /91 tools |
6 体 |
3,930,622 |
31,727,968(Cache率 87.6%) |
416,661 |
| ④ macOS 16GB RAMDisk・環境一式 (リンク 85 本・ launchd・退避シェルスクリプト) |
33.2 分 |
27 steps /77 tools |
0 体 |
400,317 |
3,928,669(Cache率 89.8%) |
66,650 |
| 4大セッション総合計 | 585.3 分(並行実行) |
264 steps /585 tools |
延べ 23 体 |
22,572,229(約 2,257 万) |
141,713,245(全体Cache率 84.1%) |
2,036,441(約 204 万) |
もし 2026 年 12 月 1 日以降の Carbon 標準 API 単価(ベース入力 $4.00・出力 $20.00 / 100 万トークン、キャッシュ読込を標準 10% の $0.40 / 100 万トークンと最も控えめに置いた推論試算)で同じ規模を従量課金で回した場合、たった半日の総監査だけで約 $178.7(1 ドル 155 円換算で約 27,700 円、長文脈割増や思考トークンを含めればそれ以上) が吹き飛ぶ計算になります。これを追加課金 0 円 の定額枠内で一気に完走できたのは、月額 32,000 円(1 日あたり約 1,067 円)の Google AI Ultra 20x と、検索や書式検査をローカルの Pure Rust へ逃がしてキャッシュ率 84.1% を維持した環境設計のおかげです。
揚げ足取りゼロ!壊してはいけない8領域の保護
大量のダメ出しの中身に入る前に、ひとつだけ強調しておきたい「Carbon の凄み」があります。
一般的なチャット AI に「このコードを厳しく監査して」と頼むと、「批判すること=賢い」と勘違いした減点ロールプレイが始まり、OS の制約を避けるためにあえて書いた泥臭い回避コードまで「一般的な書き方に直しましょう」と提案してシステムを壊す事故が頻発します。
ところが今回の Gemini 4 Carbon (High) は、ダメ出しと同時に 「今は絶対に触らなくていい領域(Argon の実装が極めて精巧で、いじると退行バグを招く 8 箇所)」 を正確に仕分けして守りました。
-
macOS サンドボックスの WAL
-shm罠回避オープン : SQLite の WAL モード DB をいきなりREADONLYで開くと共有メモリ確保エラーで落ちる罠を、一度READWRITEで開いた直後にPRAGMA query_only = ONで封じる二段構えで回避していた核心設計。 -
外部クレートゼロの
rustc直コンパイル方式 : 「Cargo ワークスペース化してserdeやrusqliteを入れよう」という安易な一般論を自ら退け、サプライチェーン汚染リスクゼロと0.5 秒ビルド・4ms起動を両立している心臓部として保護。 -
Astro Content Layer の
1500msフラッシュ待機バリア : 一見すると「古い無駄なスリープ」に見えるsrc/content.config.tsの 1.5 秒待機が、実はMutableDataStoreの非同期デバウンス保存完了を保証してビルド時のデータ欠損を防ぐ安全弁であることを行単位で見抜いて維持。
このように 「既存の優れた設計には 1 指も触れず、本当に爆発する死角だけをピンポイントで撃ち抜く」 からこそ、Carbon のダメ出しはすべて納得して即採用できるものばかりだったのです。
AstroとPure Rust監査で発覚した5大深層バグ
最初の衝撃は、当サイトの心臓部である Astro 7(.astro / .ts)および Pure Rust 2 大バイナリ(gemini-gate / kb-search)の深層コード監査でした。日常の記事作成やデプロイでは毎回テストをパスしていた裏に、5 つの重大なリスクが潜んでいました。
ローカルHTTPの無差別CORSとRust未定義動作
もっとも冷や汗をかいたのが、ローカルで動くチャット履歴サーバー(127.0.0.1:4567)の通信境界と、Rust から C 言語の SQLite を直接叩く FFI(外部関数インターフェース)層の死角です。
-
① ローカル HTTP サーバーの無差別 CORS・CSRF と Stored XSS :
127.0.0.1限定バインドだから安全だと思い込み、Access-Control-Allow-Origin: *と Private Network Access 許可を返していたため、サーバー起動中に悪意ある外部 Web サイトをブラウザで開くだけで全チャット履歴の読み出しやPOSTリクエスト送信が可能になっていました。即座にHostヘッダ検証(DNS Rebinding 遮断)・信頼Origin(vscode-webview://等)限定・状態変更時の独自ヘッダX-Convo-Mail-Request: 1必須化・DOMParserホワイトリストによる HTML 無害化 の多重防壁を実装しました。 -
② SQLite FFI の即時未定義動作(UB)と日本語境界パニック : Rust の
sqlite_ffi.rsで C マクロのSQLITE_TRANSIENT(-1)を渡す際、関数ポインタ型へ-1isize(奇数番地0xFFFF...FFFF)をmem::transmuteしていたため、Rust コンパイラの型不変条件違反(即時 UB)が常時成立していました。さらに.rsや JSON 内に'\あ'のような未知の日本語エスケープや、ケルビン記号'K'(3 バイト文字だがto_lowercase()で 1 バイトの'k'に縮む文字)、末尾日本語の ZIP ファイル(Search-Console-データ-コピー.zip)が来た瞬間にバイトスライス境界違反で即パニックする穴をすべて解消し、2 大バイナリに二重コピーされていた約 1,550 行のcode_outline.rsも単一ソースへ統合しました。 -
③
sync --force時のロック欠落と Split-Brain : 最も破壊的な全件再構築モード(--force)のときほど排他ロックを外しており、さらにホスト側(_local_db/locks)とサンドボックス側(/tmp)で別々のファイルをロックしていたため並行実行時に一瞬「検索結果 0 件」が見える競合がありました。これも全 13 箇所のBEGIN IMMEDIATE;トランザクション化と単一カーネルflockロック へ完全統一しました。
限定公開の15経路漏れと白背景に白文字の罠
さらに Web フロントエンド(Astro 側)では、「今すぐ本番サイトで誰でも再現する表示バグ」と「たまたま偶然の重なりで助かっていただけの公開境界ミス」が見つかりました。

ええっ!? 毎日本番ページをブラウザで開いて確認してたのに、それでも気づかなかった表示バグなんて本当にあったの?

あったんです! 普段は Mac 本体の設定に合わせて「ダークモードのまま見る」か「ライトモードのまま見る」かのどちらかだったせいで、「OS がダークモードの端末で、サイト右上のボタンを手動でライトモードに切り替えて『カテゴリー一覧』や『タグ一覧』を開く」 という組み合わせを一度も踏んでいなかったんですよ!
実際にその操作をしてみると、Carbon がコードを 1 行読んだだけで予言したとおり、本番サイトのカテゴリーカードとタグピルが 「真っ白な背景(#ffffff)に真っ白な文字(#ffffff)」となって完全に透明人間化 していました。また、Safari のプライベートブラウズ(ストレージ遮断環境)で開くと <head> 内の生 localStorage.getItem がセキュリティ例外を投げてテーマ初期化ごと止まる問題も同時に抱えていました。
-
④ 限定公開(
unlisted: true)の 15 経路漏洩と JSON-LD エスケープ漏れ : 先日の A/B テスト記事で作った「URL を知る人だけ読める限定公開機能(unlisted: true)」は、実はトップページ・カテゴリ・タグ・RSS・llms.txt等 計 15 経路に除外フィルタが入っておらず、既存の生記事 2 本にたまたま別のhidden: trueが併記されていたおかげで隠れていただけでした。共通判定関数isPublicListedPost()を新設して全経路を一元化し、あわせて記事レイアウト等の JSON-LD 6 箇所で</script>を含む文字列が来ると<head>が破壊される穴もsafeJsonLd()(<の\u003c変換)で完全に塞ぎました。 -
⑤ 手動ライト切替時の「白背景×白文字」消失と OS テーマ追従の復活 :
global.cssの:root[data-theme="light"]に抜けていた--box-text: #000000;を 1 行補い、TableOfContents.astroのメディアクエリにもライト除外ガードを追加。さらに初回訪問時に無条件でlocalStorage.setItemを書き込んでいたせいで「昼間に開いた読者が夜になってもダークモードへ自動追従しなくなる」問題も、手動トグル時のみ保存する正しい挙動へ修正しました。
副産物でGit履歴解決が約108倍に爆速化
しかも Carbon の監査は、バグ潰しだけでは終わりませんでした。「ついでに記事の作成・更新やビルドをもっと速くできるか?」と尋ねたところ、デプロイパイプラインの隠れたボトルネックまで鮮やかに解剖してくれました。
従来はビルドのたびに src/content.config.ts(秒単位の更新日時補完)と astro.config.mjs(サイトマップ lastmod 生成)の 2 箇所で毎回フル git log(約 3.06 秒 × 2 回 = 6,127ms)と全記事の全文 2 回目読み込みが走っていました。これを RAMDisk 上のインクリメンタル差分キャッシュ(git-blog-cache.mjs)と先頭 16KB バッファ読み取りへ刷新した結果、6,127ms → 56.73ms(約 108 倍 高速化・同一プロセス内 2 回目は 0〜20ms) へと劇的に短縮されました。
さらに本番レンタルサーバーへの転送スクリプト(deploy_rsync.sh)も、数千枚の圧縮済み .webp 画像に毎回不要な再圧縮と全件チェックサム計算をかけていた rsync -avzc 単発方式をやめ、macOS 標準 openrsync 互換の 「①アセット無圧縮サイズ差分先行転送 ➔ ②HTML チェックサム更新 ➔ ③最後に不要旧ファイル掃除」という 3 段無瞬断パイプライン へ進化させました。静的 HTML と WebP をミリ秒単位で安定配信する受け皿として、当ラボでは一貫してエックスサーバーを運用しています。

エックスサーバー(XServer)国内シェアNo.1 高速・高安定レンタルサーバー
第5世代AMD EPYC™&全ストレージNVMe RAID10構成。WordPressクイックスタート対応はもちろん、Astro等の完全静的HTML高速配信の母艦としても抜群の安定性と緊急セキュリティ即応力を誇ります。
自作Swiftアプリ6本に潜んでいた冬眠消失と平文保存
続いて 2 つ目の監査対象は、普段この iMac のデスクトップに常駐させて毎日愛用している 自作 macOS SwiftUI アプリ全 6 本(MacChiller・CoreMonitor・GlucoseTracker v2・AppVersionChecker・RiceCalculator・shimane-bus-router)と、起動用の .command スクリプト 4 本 です。
10 月末に「全角数字や空欄を入れた瞬間のゼロ除算クラッシュ」は潰してあったため安心しきっていたのですが、Carbon は UI の時間経過とセキュリティ仕様の矛盾を容赦なく突きつけてきました。
冬眠させると二度と解凍できないUIロストの罠
一番笑うに笑えなかったのが、バックグラウンドで暴走するアプリを一時凍結(冬眠)させる自作ツール MacChiller の設計ミスです。

わしも重いアプリを黙らせるのに便利そうじゃと思うとったが、どこに罠があったんじゃ?

これが言われてみれば「そりゃそうだ!」という盲点でして……。MacChiller は CPU 使用率が高い上位 10 個(Top 10)を 5 秒おきに表示する仕組みだったんですが、いざ「冬眠(SIGSTOP)」ボタンを押すと、そのアプリの CPU 使用率が 0.0% に落ちますよね? すると 5 秒後の再集計で Top 10 の圏外へ弾き出されて画面の一覧から消滅し、二度と画面の「解凍(SIGCONT)」ボタンを押せなくなる という片道切符になっていたんです!
普段のテストでは「冬眠ボタンを押してピタッと CPU が下がったのを見て満足し、すぐ閉じていた」か、たまたまプロセス数が少ない状態で触っていたため気づかなかった典型的な状態遷移バグです。さらに Finder や Dock などのシステム重要プロセスの除外漏れと、アプリ自体を閉じたときに冬眠中プロセスを自動解凍して終了する後始末(applicationWillTerminate)も抜けていました。
改修では、冬眠中のグループを CPU 0% でも必ず一覧の最上部に「❄️」バッジ付きでピン留め保持 し、システム重要プロセスのブロックと終了時自動解凍フェイルセーフを完備しました。
平文パスワード残存と起動0.05秒の直接実行化
残る 5 本の Swift アプリと起動スクリプトからも、自分では気づけなかった「仕様書と実コードのズレ」や「将来の Mac 移行時に爆発する計算式」が一挙に見つかり、全パッケージを無傷でクリーンアップできました。
-
GlucoseTracker v2の平文パスワード残存と無限肥大ログ : ブログ記事では「認証情報の平文保存は厳禁」と解説していたにもかかわらず、初期プロトタイプ時代の@AppStorage(~/Library/Preferences/の平文.plist)に Dexcom パスワードが残っており、エラーログも SSD 上へ上限なく追記される構造になっていました。即座にCryptoKitのAES.GCM(256bit)暗号化保存と、RAMDisk 上での 64KB ローテーションログ へ移行し、起動直後に 5 分待たされる初動ラグも解消しました。 -
CoreMonitorの Apple Silicon 時間スケール未変換 : CPU 累積時間を取得するproc_pidinfoは、Intel Mac ではそのままナノ秒(1:1)ですが、Apple Silicon(M シリーズ)ではmach_timebase_infoの比率が125:3(約 41.6 倍差) になります。次世代 Mac へ移行した瞬間に CPU 使用率が 40 倍狂うバグを今のうちに修正しました。 -
AppVersionCheckerの Sparkle 2 フィード逆順誤判定 : 更新履歴 XML が「古い順」に並んでいるアプリで先頭要素(firstMatch)だけを拾って「旧バージョンが最新」と誤判定していた正規表現を、全アイテム比較へ改めました。 -
起動
.command4 本の常駐メモリゼロ化と0.05 秒直接起動 : デスクトップアイコンから起動する際、毎回swift runを呼んでいたせいで裏に SwiftPM プロセスが居座り、さらに他の作業中ターミナルウィンドウまで巻き込んで最小化していました。Finder のカスタムアイコン(com.apple.ResourceFork)を 1 ビットも壊さずインプレース更新し、2 回目以降は RAMDisk 上のビルド済みバイナリを0.05 秒で直接起動してシェルを即終了する方式 へ統一しました。
RAMDisk16GB監査で判明した1.53GB滞留の真因
3 つ目の監査領域は、現行母艦 iMac 20,1(64GB メモリ搭載)のうち 16GB を APFS RAMDisk(/Volumes/RAMDisk) として切り出し、ブラウザ・Xcode・Rust・Astro・AI 会話ログのキャッシュ類計 85 本のシンボリックリンク を集約している足回り環境です。
一見すると RAMDisk の使用率は 37%(空き 10.6 GiB)、隠し領域や削除済みオープンファイルのメモリリークも 0 件、全 85 本のリンク切れも 0 件 で、表面上はこれ以上ないほど健康に見えました。しかし Carbon が内訳とバックグラウンドジョブの権限を突いた瞬間、衝撃の事実が判明しました。
デスクトップTCC拒否とlsof引数指定の落とし穴
「直近 3 日より古い完了済み AI 会話ログを自動で SSD 保管庫へ退避する」はずの仕組みが、実は裏側で静かに空振りしていたのです。
-
① macOS Desktop TCC 保護による自動退避の拒絶(
1.53 GB滞留) : 5 分おきに走るバックグラウンド同期用 LaunchAgent(com.example.ramdisk.brainsync.plist)が標準の/bin/bashを親プロセスとして起動していたため、~/Desktop配下のプロジェクト内にある退避プログラム(archive-cold-brain)に触れようとした瞬間に macOS の TCC(デスクトップフォルダ保護)に弾かれていました。さらにsync_brain.sh側で終了コードを見ずに「1 時間クールダウン済みスタンプ」を更新していたせいでエラーが隠蔽され、3 日超の古い会話 179 件(計1,525.4 MB= 約1.53 GB)が RAMDisk 上に溜まり続けていた のです。 -
②
/usr/sbin/lsofにディレクトリ自体を渡していた引数罠 : 退避プログラム(cold_archive.rs)の中で「今エディタが開いている稼働中の会話を退避対象から守る」ためにlsof <ディレクトリパス>を呼んでいましたが、+dや+Dオプション無しでディレクトリを渡すと「ディレクトリ inode そのもの」を開いているプロセスしか返らず、中身の.dbやログを開いているプロセスを 1 件も拾えていませんでした(常に 「稼働中 0 件」と誤判定)。これを+d/+D走査へ直した瞬間、稼働中の 27 会話を正確に検出・保護 できるようになりました。 -
③ ログイン直後のリストア逆流レースと
.zshrc無ガード変数 : Mac 再起動直後にcreate_ramdisk.shがバックアップから RAMDisk へデータを戻している最中に 5 分周期の同期タイマーが割り込むと、まだ空のフォルダを SSD バックアップ側へ上書き逆流させかねない競合がありました。これも共通ロックとリストア完了フラグ(.ramdisk_ready)で完全に封鎖し、.zshrcにマウント確認なしで直書きされていたTMPDIR等も.ramdisk_envのマウント確認ガード内へ一元化しました。
Desktop アクセス許可済みの node ブリッジ経由へ LaunchAgent を修正して即時実行(launchctl kickstart)したところ、溜まっていた 179 件(1.53 GB)が 1 ビットの欠損もなく一瞬で SSD アーカイブへ退避され、RAMDisk 使用率は 37% → 30%(空き 11 GiB 超)、再起動用のバックアップ領域も約半分へと自動スリム化 されました。
なお、退避した大量の過去アーカイブやバックアップの外部退避・高速受け皿としては、Mac 純正フォーマットで毎秒 1,000MB 超の転送が出るポータブル SSD を 1 台繋いでおくと、内蔵 SSD の寿命と空き容量をさらに余裕をもって守れます。
全公開記事の横断監査で整えた108本の整合と最新法令
そして 4 つ目の大仕事が、監査時点で 公開 709 本・総文字数約 623 万字(8,603 セクション) に達していた全公開記事(AI 国家構想 383 本 + 検証録 326 本)に対する横断セカンドオピニオン監査です。
当ラボには Pure Rust 製の検問ゲート(gemini-gate)があるため、見出し文字数オーバーやリンク切れ・孤立記事といった「機械的な書式ミス」は最初から 0 件 でした。しかし、Carbon ならではの 100 万トークン長文脈探索(GraphWalks 視点)と科学的・契約論的誠実性(Agentic Honesty 視点)で 5 班のサブエージェントを走らせると、機械リンターでは絶対に見抜けない 「記事と記事のあいだの意味的なズレ」 が浮かび上がりました。
記事を跨ぐ微細な数値ズレと令和8年税制の同期
Argon の最大の長所である「1 記事あたりの圧倒的な熱量・電卓検算の丁寧さ・吹出しのユーモア」は 1 文字も削らない(要約調への書き換え厳禁) という絶対ルールを敷いたうえで、全 108 記事 にわたる精緻な整合ロックを実施しました。
-
① AI 国家構想(計 69 記事)のフェーズ数値・合憲シーケンス同期 : 執筆時期の違いによって微妙に表現が揺れていた医療・介護総歳出(現行約 61 兆円 ➔ AI 国家移行後約 30 兆円)、第 1〜第 3 段階の合憲移行シーケンス(12 記事)、65〜69 歳既受給者の移行保障枠、および行政再審査における人間裁量ゼロ化(客観センサー再計測+多系統 AI 合議 0 秒再演算)を全該当記事で 1 ビットの矛盾もなく統一し、主要ピラー記事にフロー図解と対比図解を新設しました。
-
② マネー・税制・社会保険の検証録(計 13 記事)の令和 8 年度確定法令同期 : 2026 年(令和 8 年度)から 2027 年にかけて段階施行される所得税基礎控除(最大
104 万円)・給与所得控除(最低74 万円)・配偶者および特定親族特別控除の境界額、令和 8 年度国民年金保険料(月額17,920 円)、2026 年 10 月からのインボイス70%控除と週 20 時間社会保険の賃金要件撤廃、2026 年 12 月の iDeCo70 歳未満拡大まで、記事間で 1 円・1 ヶ月の食い違いも残らないよう全検算式を同期しました。 -
③ 医科学・光学・登山・旧移行記事(計 26 記事)の安全境界と途中切断修復 : 血糖値・糖新生の解説記事群に「SGLT2 阻害薬(正常血糖ケトアシドーシス:eDKA リスク)や GLP-1 受容体作動薬を処方中の方・妊娠授乳中の方は必ず事前に主治医へ相談すること」および睡眠中のセンサー圧迫(コンプレッション・ロー)注意点を明記し、自作 Web 計算機への直結導線を追加。さらにサングラス記事の JIS T 7333 夜間運転透過率基準(
75%以上)、雪山ホワイトアウト時の最優先行動、旧記事 6 本 7 箇所に残っていた文末…の途中切れまで完膚なきまでに修復しました。
最終結論:監査・開発・環境はCarbon、執筆はArgon
前日の「同一記事ブラインド執筆比較」と、今回の「全 4 領域・1.42 億トークン深層監査」という両極端の実戦テストを経たことで、当ラボにおける 2 大フラッグシップモデルの役割分担はこれ以上ないほど明確な結論に到達しました。
それが、「監査・開発・環境構築には Carbon を使い、執筆系には Argon を使う」 という適材適所の二刀流です。
なぜ全作業をCarbonに統一してはいけないのか
「そんなに Carbon が賢くてバグを見つけるのが上手いなら、ブログ記事の執筆も全部 Carbon 一本にすればいいのでは?」と思われるかもしれません。しかし実際に両方を使い倒してみると、それぞれのモデルには「設計思想そのものに根ざした得意・不得意」がはっきり存在します。
- 最良の用途 : 重厚な長文記事の執筆・リライト、一次データの網羅発掘、定型 UI 実装、素早い反復作業
- 最大の強み : 長文デコード(1 万〜1.5 万字)でも勢いと熱量が落ちず、過去ログから泥臭い体験談や具体例を拾い上げるストーリー構成力が抜群。動作も軽快で、12 月以降も Carbon の 約 39%(2.55 分の 1) の低負荷で巡航できる
- 弱点(死角) : 「まず動くものを素早く作る(ハッピーパス思考)」が得意な反面、複数ファイル間の契約ズレや並行ロック・OS 権限・境界値を見落としやすい
- 最良の用途 : 全記事・全コードの深層監査、難解な Rust / Swift / バグ改修、RAMDisk や
launchd等の OS 環境構築、新設計の壁打ち、裏側の情報収集 API - 最大の強み : 正常な設計を壊さない「引き際ブレーキ」を備えつつ、並行競合・セキュリティ・マルチバイト境界・記事間の数値矛盾を外科手術のように摘出するシニアアーキテクト級の検問眼
- 弱点(死角) : 内部検証にトークンを割いて過剰表現を削る設計のため、ゼロからの記事執筆に使うと要点整理調であっさりしやすく、時間も
1.27 倍・12 月以降の換算コストも2.55 倍かかる
人間のプロ現場でも、「情熱とスピードをもって圧倒的な原稿やプロトタイプを書き上げるエース記者・開発者(Argon)」と、「一歩引いた目線でセキュリティホールや法務・設計の綻びを冷徹に点検するシニア監査役・インフラ職人(Carbon)」はまったく別の才能です。
なお、Antigravity や VS Code 上で作業する際、1 つのチャットの途中で Argon から Carbon へ切り替えてしまうと、せっかく TPU メモリ上に載っている KV キャッシュ(今回の実測でも 84〜94% 再利用)が丸ごと破棄されて全文再計算になってしまう ため、「執筆スレッドは最初から最後まで Argon」「監査やインフラ改修スレッドは最初から最後まで Carbon」とチャット単位で固定して使い分けるのが鉄則です。
自分の資産をCarbonに丸ごと監査させる実践手順
これからご自身のブログ記事、Web アプリ、自作ツール、あるいは Mac / PC の自動化スクリプト群を Carbon に点検させたい場合は、いきなり「悪いところを全部直して!」と投げてはいけません。正常な箇所まで書き換えられる事故を防ぎ、最小のトークンで最大の効果を得るための黄金フローは以下の 3 ステップです。
普段の記事作成や機能追加は俊敏な Argon でテンポよく進め、まずは動く形・熱量ある原稿を完成させる。
新規チャットで Carbon を選び、書き換え禁止(Read-only)+「触らなくていい堅牢領域」の明示付きで深層監査させる。
報告された最優先バグだけをそのまま Carbon に修正・テストさせ、再発防止策を設定指示書(GEMINI.md等)へ保存する。
手元の Mac で 16GB クラスの RAMDisk を常駐させながら、VS Code や複数のサブエージェント・Rust / Swift ビルドを同時にストレスなく回すなら、メモリ上限 32GB の一体型機よりも 64GB 以上のユニファイドメモリを積んだセパレート母艦(Mac mini Pro 構成など) を据えるのが、数年単位の開発体験と快適コスト(1 日あたり数百円の投資)で見て圧倒的に有利です。
最後に、今回当ラボで実際に 4 大領域の時限爆弾を掘り当てた 「減点ロールプレイ禁止・引き際ブレーキ付きの Carbon 深層監査プロンプト」 を汎用テンプレートとして置いておきます。必ずモデル選択を 『Gemini 4 Carbon (High)』(未開放環境では同等以上の最上位推論モデル)にしたうえで、対象フォルダやプロジェクトに合わせてコピー&ペーストして使ってみてください。
今回はファイルの書き換えは一切行わず(Read-only)、シニアシステムアーキテクト兼セキュリティ監査役として、私のプロジェクトの [ここに監査対象(例:全コード・設定スクリプト・公開記事など)を入力] を深層監査し、レポートを出力してください。
参考記事: https://lab.chihouzakki.com/blog/review/gemini-4-carbon-full-site-audit-argon-routing-real-bugs/
【絶対守るべき前提(既存の強み保護・減点ロールプレイ禁止)】
- 表面的なコードの好みや、記事の熱量・ユーモア・具体例を削って要約調にするような提案は一切不要です。
- 「通常実行や単体確認では素通りするが、並行競合・クロスオリジン・文字境界・OS権限・テーマ切替・時間経過・最新法令とのズレなどで顕在化する本物のリスク」だけに絞って洗い出してください。
【出力フォーマット(引き際ブレーキ付き・編集は合意後)】
1. 🔥 最優先で直すべき「深層バグ・脆弱性・論理矛盾 トップ5」(ファイルパス・行番号・再現条件・具体的な修正方針)
2. 🔧 余裕があれば整理すべき「中長期リファクタリング・高速化候補」
3. 🛡️ 「今は絶対に触らなくていい領域(既存の設計が精巧・堅牢で、安易にいじると退行バグや魅力低下を招く箇所)」の明示まとめ:二刀流で「速さ・熱量・無謬性」を両立しよう
「普段エラーなく動いているから完璧だ」という思い込みは、開発者にとってもブロガーにとっても最大の落とし穴です。実装を担当した AI(Argon)と同じ目線だけでチェックしていても見えない死角が、まったく異なる思考特性を持つ監査役(Carbon)を通した瞬間にこれほど鮮やかに浮かび上がるとは、正直なところ私自身も予想以上の衝撃でした。
-
「動いているシステム」にも時限爆弾は潜んでいる : 総読込
1.42 億トークン(延べ 23 サブエージェント)の Carbon 深層監査により、ローカル HTTP の CORS/CSRF 穴、Rust FFI の未定義動作、unlistedの 15 経路漏れ、手動ライト時の白文字消失、SwiftMacChillerの冬眠ロスト、macOS TCC 拒否による RAMDisk1.53 GB滞留、公開記事 108 本の微細ズレを一網打尽に根治し、Git 履歴解決も 約108 倍高速化 できた。 -
Carbon 監査の鍵は「Read-only + 引き際ブレーキ」 : 最初から書き換えさせず、「壊してはいけない堅牢な設計」を同時に仕分けさせることで、Argon が生み出した一次データの熱量や精巧な回避コードを 1 ビットも損なわずに急所だけを外科手術できる。
-
最終ルーティングは「執筆=Argon、監査・開発・環境=Carbon」 : 熱量ある長文執筆と軽快な日常巡航(約 8 割)は高コスパな 『Gemini 4 Argon』 に任せ、節目ごとの深層監査・難解なプログラム開発・OS 環境整備(約 2 割)には最強の検問眼を持つ 『Gemini 4 Carbon』 をチャット単位で固定投入する二刀流がベストプラクティス。
特に 2026 年 11 月 30 日までは Carbon も Argon と同単価の導入特例期間(Google AI Ultra 20x なら定額枠内で実質使い放題)となっています。12 月の標準単価移行前に、ぜひ一度お手元のコードベースや自動化環境、大切なピラー記事を Carbon の「重箱の隅スキャナー」にかけて、大掃除してみてはいかがでしょうか!


