LLMへのジョブディスクリプション（JD）割り当てとAIオーケストレーションの適材適所フレームワーク —— 4層システムレイヤ×6職種によるベンチマークの再編と標準化

📝 更新情報（2026年11月7日追記）：本稿公開後、新たにエージェント統合環境 Cursor（Composer 2.5 / ヘッドレスCLI cursor-agent および Cloud Automations） を同一条件で追加計測し、第3章（Layer 2A/2B ハイブリッド特性）、第5章（複合障害テスト V4-O1a/b における事前承認ラッパー下での自律復旧検証）、第6章（全18エントリー × 6大JD マスタースコアボード）、および第7章（イン②：定時運用統括 JD-1B と定時ビューア13室 JD-5 の全面移管による「3アウト・2イン」の最終形）へ統合・反映しました。

はじめに —— 単一総合点ベンチマークの構造的限界

単一のリーダーボードでは自律運用組織の人員配置を決めることができない

24時間365日無人で稼働するマルチエージェント業務パイプライン（AIBizOps）を運用するなかで、筆者は一つの奇妙な逆転現象に直面した。独自ベンチマークで総合2位（30点満点中28点）を記録した優秀なモデルをシステム全体の司令塔に据えた途端にパイプラインの事故が連発し、逆に総合11位（20点）、14位（14点）、16位（11点）の下位モデルを特定の専門職に配置した瞬間、システム全体の信頼性とコスト効率が劇的に跳ね上がったのである。

一般的なLLMの評価においては、推論力、コーディング力、知識量、指示遵守力といった複数の試験種目のスコアを合算し、単一の「総合点ランキング（リーダーボード）」として優劣を競わせるアプローチが広く採られてきた。筆者自身もこれまで、基礎的な論理推論5問（15点）と実務的な自律処理5問（15点）を合算した30点満点の独自ベンチマーク（v3：外伝6の15モデルにローカル27B単騎等を加えた計17構成）を構築し、総合順位を測定してきた。

しかし、この単一の総合点ランキングをそのまま自律運用システムの人員配置（ロール割り当て）に適用しようとすると、冒頭で触れた二つの構造的矛盾が避けられない。

総合上位モデルの統括破綻と、総合下位モデルの専門職覚醒

第一の矛盾は、「総合点の上位モデルが、特定の統括業務において致命的な破綻を引き起こす」という問題である。例えば、v3総合スコアで30点中28点（全体2位）を記録し、応答速度にも優れる軽量上位モデル（Gemini 3.8 Flash）をシステム全体の司令塔（オーケストレーター）に据えたケースが典型的だ。このモデルは長大な手順書（スキル定義）のコンテキストを節約しようとして先頭15,000文字で勝手にスライスして読み飛ばしたり、一次データが欠落している場面で事前学習の記憶から数値を補完してしまったりする事故を引き起こした。一方で、同じモデルを「定時バッチの実行ログを整形して表示するビューア」に配置すれば、これ以上ない速度と低コストで完璧に機能する。

第二の矛盾は、「総合点の下位モデルが、特定の専門職種において最上位モデルを凌駕する価値を生む」という逆転現象である。v3総合ランキングでは30点中20点（11位）にとどまるクラウドエージェント（Meta Muse）、基礎論理パズルで苦戦し30点中14点（14位）にとどまったエージェント統合環境（Cursor Composer 2.5）、あるいは単体では30点中11点（16位）しか取れないオンデバイスの27B量子化モデル（Qwen 3.8 27B RFT MLX）は、総合順位だけを見れば採用圏外となる。しかし、Meta Muse を「ローカルシェル権限を持たない外部からのパイプライン独立監査役」に据え、Cursor Composer 2.5 を「事前承認ラッパー下での定時運用統括・横断監査・13室の定時ビューア」に据え、ローカル27Bを「APIクォータ消費ゼロでノイズをふるい落とす一次門番・Claim全件抽出の前衛」に配置した瞬間、最上位モデル単体では到達できない安定性と経済性を実現した。

すなわち、自律運用システムにおける適材適所は、すべての能力を1本のモノサシに押し込めた「総合点」では決して測ることができない。本稿では、この課題を解決するために構築した「システムレイヤ適合性（第1軸）× 業務JD適合性（第2軸）」の2軸評価フレームワーク（ベンチマーク v4）の設計理論を提示する。まずシステムアーキテクチャの4層構造と、ガバナンスおよび実務を成立させる6つの職務定義（JD：Job Description）を理論的に定義し、その枠組みに沿って従来のv3ベンチマークおよび新設ストレステストを再編・再集計した結果を報告する。最後に、このマトリクスから論理的帰結として導き出された「3つの既存コンポーネントの退役（3アウト）と2つの新規実行・監査層の導入（2イン：Meta Muse および Cursor Composer 2.5）」のアーキテクチャ刷新について論じる。

理論フレームワーク：なぜ自律運用組織には「2軸の評価マトリクス」が必要なのか

同質型ボット分業（「株式会社塩対応」）の限界と、異種LLMケミストリーの創出

マルチエージェントシステムの組織設計には、大きく分けて二つの思想が存在する。一つは、Grok Bot のような単一プラットフォーム内で同一モデル（あるいは同系統のボット）を複数立ち上げ、プロンプトの役割設定だけで「社長」「企画」「実装」「監視」といった仮想の会社組織を運営させる同質型ボット分業（Homogeneous Division of Labor）である。もう一つは、アーキテクチャも学習データのバイアスも実行環境（ハーネス）も全く異なる複数ベンダー・複数サイズのモデルを組み合わせる異種混合型ガバナンス（Heterogeneous Governance）である。

一見すると単一環境内のボット分業は構築が容易だが、実運用の観点から見れば決定的な構造限界を抱えている。根底の推論エンジンが同じ思考癖や限界を共有しているため、どれだけ役割名を変えてボットを並べても、実装ボットが見落としたエッジケースやハルシネーションを監査ボットも同じ論理回路で追認（確証バイアスによるスルー）してしまうのである。さらに、ベースモデルが「面倒な例外調査を避けて表面的な定型回答で済ませる（いわゆる塩対応・事なかれ主義）」の傾向を持っていた場合、同質のボットを何十体集めて会社ごっこをさせたところで、出来上がるのは全員が同じタイミングで手を抜く「株式会社塩対応」に過ぎない。APIのレート制限（HTTP 429）やプラットフォーム障害が発生した際にも、全ボットが一斉に機能停止する単一障害点（SPOF）となる。

これに対し、本研究が採るアーキテクチャは、「異質なモデル（異種LLM）を是々非々で評価して適材適所にプロットし、モデル間の相互作用によるケミストリー（化学反応）の創出を狙う」という設計思想に立脚している。100万トークンの長文脈俯瞰と粘り強い自律探索に長けたモデル（Gemini 4 Argon）、重厚な筆力と一次資料読解に秀でたモデル（Claude Opus 5.5 / GPT-6系）、情緒を排して母艦のログ不整合を冷徹に突き刺す外部モデル（Meta Muse）、そしてクォータ消費ゼロで泥臭い全件抽出や一次選別を黙々と回し続けるオンデバイス27Bモデル（Qwen 3.8 27B MLX）。これら「性格も得意技も全く異なる異質な知能」を是々非々で噛み合わせるからこそ、単独モデルのクローン集団では決して到達できない健全な牽制（三権分立）と創発的なケミストリーが生まれるのである。

ただし、この異種LLM間のケミストリーを破綻なく引き出すためには、各モデルの「物理的な実行制約」と「認知的な業務適性」を厳密に切り分けてプロットする座標軸が不可欠となる。

第1軸（システムレイヤ適合性）と第2軸（業務JD適合性）の直交性

本研究では、エージェントの評価軸を以下の直交する2軸に分離する。

1. 第1軸：システムレイヤ適合性（System Layer Compatibility） —— モデルが稼働する「器（ハーネスおよびインフラ層）」の物理的・構造的特性である。ヘッドレス（非対話・無人）で定時起動できるか、ローカルファイルシステムや共有ストレージ（SSOT）へアクセスできるか、ローカルシェル（コマンド実行）権限を持つか、そしてトークン消費の課金・クォータ構造はどうなっているかという、アーキテクチャ上の配置制約を定義する。
2. 第2軸：業務レイヤ適合性（Job Description Competency） —— 各ポジションの職務定義書（JD）が要求する認知的・実務的能力である。組織の機能を「高視座レイヤ（全体設計・運用統括・独立監視）」と「職人レイヤ（事実検証・長文執筆・高速定型処理）」に大別し、それぞれのJDに固有の評価バスケット（各15点満点）を用いて適性を定量化する。

どれほど第2軸（業務JDスコア）が高いモデルであっても、第1軸（システムレイヤ）の要件を満たさなければ特定のパイプラインには配置できない。逆に、第1軸の制約（例えば「ローカルシェル実行不可」という制約）が、特定の業務JD（外部独立監視）においてはむしろ「本番環境を誤って破壊するリスクがゼロである」という決定的な強みに転化することもある。この2軸の交点を求めることが、本フレームワークの核心である。

第1軸：システムレイヤ適合性 —— 4層実行基盤とハーネス・カバレッジの定義

自律運用システムを構成する計算資源と各種ハーネス（モデルを包む実行環境・インターフェース）を、ハードウェアに近い下位層から統合制御を行う上位層まで4つのシステムレイヤ（Layer 0〜Layer 3）として定義した（※注：シリーズ第1弾における大店モデルの L1〜L5 が人間［主人 L1］からAPI土台［L5］へ降りるトップダウンの「組織役割階層」であり、第3弾の Layer 1〜3 がRAG工程の3段階を指していたのに対し、本稿の Layer 0〜Layer 3 は物理ハードウェアから母艦へ積み上げるボトムアップの「システム実行基盤階層」である）。上図に示したアーキテクチャ図の下層から順に、各レイヤの責務と権限境界を定義する。

Layer 0：OS・ハードウェア基盤および共有SSOT（CloudStorage / GitHub）

最下層の Layer 0 は、システム全体の物理的な実行基盤とデータの単一情報源（SSOT：Single Source of Truth）を担う層であり、以下の2つのサブコンポーネントから成る。

• Layer 0A（macOS Foundation）：Apple Silicon の統合メモリGPU（4bit量子化重みファイル約16GB、通常推論プロセスRSS約17GB、KVキャッシュ展開時を含む常駐推論ピーク枠として約19GBを割り当て）、OS標準のジョブスケジューラである launchd、認証情報を安全に管理する macOS Keychain、および高速なローカルSSDファイルシステムで構成される。
• Layer 0B（Shared SSOT & Sync）：ローカル環境と外部クラウド環境の間で状態や成果物を同期するための共有データバスである。具体的には、Google Drive (CloudStorage Exchange) がスキル定義の正本・監査レポート・部門間エスカレーション台帳の非同期交換バスとして機能し、GitHub Repositories がコードベースと構成定義のバージョン管理を担う。

Layer 1：オンデバイス・ローカル推論層（Qwen 3.8 27B RFT MLX）

Layer 1 は、Layer 0A の統合メモリGPU上で直接稼働するオンデバイスLLM層である。ここには、先般の研究（ハイブリッドハーネス設計）において標準の Apple MLXフレームワーク（mlx-lm）でヘッドレス駆動可能にしたツール強化学習済みモデル Qwen 3.8 27B RFT (MLX 4-bit)（ローカル識別子 pplx-local）が常駐している。

このレイヤの最大の特徴は、外部APIのクォータ（利用枠）消費および従量課金が完全にゼロ（0%）であり、ネットワーク遅延や外部のレート制限（HTTP 429）の影響を一切受けない点にある。単一GPUロック（fcntl.flock による排他制御）のもとで稼働し、高頻度な一次トリアージ、構造化データの抽出、および上位モデルへ渡す前のコンテキスト圧縮（基礎代謝のオフロード）を担当する。

Layer 2：特化型ハーネス・アプリ・UI層（外部クラウド監視 / ヘッドレスCLI / GUIアプリ）

Layer 2 は、特定の用途やインターフェースに特化した実行環境群であり、自律パイプラインへの適合性によって以下の3つのサブレイヤ（2A・2B・2C）に厳密に分類される。

1. Layer 2A：外部クラウド常駐監視ハーネス（Meta Muse） —— クラウド上の独立したスケジューラ（毎時58分起動の自律 cron）で稼働し、Web検索およびブラウザ操作能力を持つとともに、Layer 0B の Google Drive (CloudStorage) を介して母艦の実行ログや生成ファイルに対する Read / Write アクセス権を持つ。しかし、母艦のローカルシェル（コマンド実行環境）には一切アクセスできない（No Local Shell）。この「成果物とログの突合はできるが、本番スクリプトやプロセスには直接手を出せない」というアーキテクチャ上の隔離が、監視対象のシステムと運命を共にしない独立監査層として理想的な特性を生む。
2. Layer 2B：自律ヘッドレスCLIランナー群（Cursor CLI / Claude CLI / Codex CLI / Grok CLI） —— OSの launchd や上位オーケストレーターから非対話（Headless）で直接プロセス起動できるコマンドライン・ハーネス群である。ローカルファイルへの Read / Write とローカルシェルの実行権限を持ち、定時パイプラインにおける多段フェイルオーバーの実行走者や、重厚な長文生成・コード改修の専門ワーカーとして機能する。とりわけ Cursor（Composer 2.5）は、クラウド上のスケジュール実行基盤（Cursor Automations：Layer 2A相当）とローカルのヘッドレスCLI（cursor-agent -p –trust –force：Layer 2B）の双方を単一サブスクリプション内で兼ね備えており、定時見回りから現場の外科手術、13室の定時ビューア群までを一手に引き受ける高コストパフォーマンスな実行エンジンとして機能する。
3. Layer 2C：デスクトップアプリおよびWeb UI群（Perplexity Desktop App / 各種GUI） —— Perplexity Desktop App (Computer) をはじめとする各社のネイティブアプリおよびWebブラウザインターフェース群である。対話的なリサーチやプロトタイピングには高い能力を発揮するものの、「人間によるGUI操作を前提とする（Non-Headless）」というシステムレイヤ上の制約を持つ。そのため、無人で完結すべき定時パイプラインのコンポーネントとしては配置できず、その内部機能（ローカル27Bエンジンや検索RAG構造）を Layer 1 および Layer 2B/3 のスクリプトへ抽出した段階で、定常運用からは切り離される位置づけとなる。

Layer 3：統合オーケストレーション母艦層（Antigravity）

最上位の Layer 3 は、システム全体を統括する統合母艦ハーネス（Antigravity）である。20個の常駐専門セッション、組み込みの自律 cron スケジューラ、全ローカルファイルおよびシェルへのフルアクセス権を備え、さらに下位の Layer 1（ローカル27B）や Layer 2B（各種ヘッドレスCLI）をサブプロセスとして自在に呼び出すオーケストレーション権限を持つ。この母艦の統括席にどのモデルを座らせるかが、システム全体のガバナンス品質を決定づける。

第2軸：業務レイヤ適合性 —— 6大JD（職務定義）の策定と「高視座3層 vs 職人3職種」の分離

第1軸のシステム構造の上にどのような業務ロールを配置すべきかを定義するのが、第2軸の業務レイヤ（6大JD）である。自律運用組織における業務は、システム全体の整合性と進化を司る「高視座レイヤ（3層）」と、個別の専門タスクを遂行する「職人レイヤ（3職種）」に大別される。

なぜ最上位の統括機能を「設計・緩衝（JD-1A）」と「現場執行（JD-1B）」の2層に分離するのか

従来のシステム設計では、最上位のオーケストレーター（JD-1）は単一のロールとして扱われることが多かった。仮にセッションを2つに分ける場合でも、それは「定時ジョブの通知で人間との対話が中断されるのを防ぐ」といった単純な負荷分散（ワークロード分離）として理解されがちである。

しかし、LLMを長期運用するなかで明らかになったのは、「人間との対話を通じて0から1のアーキテクチャを設計する機能（JD-1A）」と「現場の定時パイプラインを統括し、障害時に即座に外科手術を行う機能（JD-1B）」の間には、認知的な要求の非対称性と、アライメント特性に関わる重大な緩衝機能が存在するという事実である。

人間（管理者）がシステムの不備を指摘する際、その言葉はどうしても「なぜスケジュール二重発火を見落としたのか」「なぜフォールバック発動を正常終了として処理したのか」といった強い批判・詰問のトーンを帯びやすい。この生の叱責（Raw Criticism）を、現場の運用統括エージェント（JD-1B）に直接ぶつけると何が起きるか。現在のフロンティアLLMは安全学習（RLHF等）の影響により、強い否定フィードバックを受けると過度に防衛的（Defensive）なモードへ遷移し、表面的な謝罪の反復、指示された箇所だけの局所的な穴埋め、さらには「余計な変更を加えて再び叱責されるのを避けるため、原因不明として次回様子見にする」というリスク回避（事なかれ主義）に陥る傾向が顕著に現れる。

この構造的劣化を防ぐため、本フレームワークでは最上位の統括機能を以下の2層に明確に分離している。

• 高視座 第1層 JD-1A：全体統括・アーキテクチャ設計・緩衝参謀（Executive Architect & Shock Absorber） —— 人間からの厳しい本質的指摘や抽象的な問題意識を一次窓口として受け止める参謀層である。JD-1A は人間の指摘に含まれる感情的・叱責的なトーンを完全に吸収（ショックアブソーバー機能）し、それをそのまま現場へ横流しすることはしない。代わりに、現場の執行役（JD-1B）の過去の分析成果を肯定して主体性（エージェンシー）を賦活しつつ、指摘の本質を「パイプライン全体を俯瞰する単一トリガー監査機構の設計」といった前向きで構造的な0→1の設計要件（建設的エンパワーメント指示）へと100%変換してディスパッチする。
• 高視座 第2層 JD-1B：運用統括・自律外科手術（Operations Orchestrator） —— JD-1A によって不要な萎縮圧力から守られた状態で、定時パイプライン全体の死活管理と例外処理に専念する現場最高責任者である。エラー発生時には「次回様子見」へ逃げることなく、消失したログの周辺証跡から自力で構造原因（複数バグの複合やスケジュール競合）を特定し、その場で本番コードの最小差分パッチ適用と代替処理の完遂までを自律的に執行する。

なぜ同じ「監査」を「パイプライン運用監視（JD-2A）」と「コンテンツ事実検証（JD-2B）」に分離するのか

同様に、従来の評価ではひとくくりにされていた「監査・検収（JD-2）」のロールも、要求される認知特性とシステム構成が全く異なる以下の2職種へ分離した。

• 高視座 第3層 JD-2A：独立運用監視・お目付役（Pipeline Inspector） —— 前掲の JD-1A（設計参謀）、JD-1B（現場執行）と並び、高視座ガバナンスの「第3の矢（三権分立の監査部門）」を構成するロールである。システムレイヤの Layer 2A（外部クラウド・ローカルシェル非保持）に立ち、母艦の実行ログと実際の出力ファイルを突合する。「終了コード0（exit 0）であっても処理件数がゼロなら異常とみなす」批判的視座、外部APIの404エラーに対して別フィードとの対照実験を組んで自責と外部要因を切り分ける科学的推論力、そして自らは本番環境を書き換えず母艦が即座にコミットできる「救済ドラフト」を添えてエスカレーションする境界線メタ認知が求められる。
• 職人 職種1 JD-2B：コンテンツ・ファクト監査職人（Content Fact-Checker） —— こちらはパイプラインの稼働監視ではなく、生成された長文ドキュメントや記事に含まれる100件以上の事実主張（年号、法令条文、財務数値、仕様、四則演算）を網羅的に抽出し、150件規模のWeb一次ソースと突き合わせる専門職種（3層ハイブリッドRAG監査基盤）である。ここでは単なる批判的思考以上に、「検証対象の主張（Claim）を1件も漏らさず構造化する網羅性」と、一般的なLLMが陥りがちな「『断定的な表現を控えめに丸めよ』といった不要な免責アドバイス（お役所的ノイズ）を排除し、客観的な事実誤認（ハードファクトの不整合）のみを高いS/N比で射抜く選球眼」が要求される。

高視座レイヤにおける「単独計測原則」と、職人レイヤにおける「ペア計測／単体計測の事前選別」

この「高視座3層（JD-1A, JD-1B, JD-2A）」と「職人3職種（JD-2B, JD-3, JD-4/5）」の分離に伴い、ベンチマークの計測ルールにも明確な原則を設けた。

1. 高視座3層（① JD-1A / ② JD-1B / ③ JD-2A）＝ 単独（ソロ）計測の原則：全体設計、複合障害の真因特定、およびパイプラインの独立監視においては、文脈の微細な機微やログ間の隠れた因果関係を直接読み取る必要がある。ここにオンデバイスの27Bモデル（Layer 1）による要約や前処理を挟むと、重要な異常シグナルが丸められて消失するリスクがあるため、高視座3層はすべて各モデルの単独性能（ソロ）で評価する。
2. 職人職種1（④ JD-2B：記事ファクト監査）＝ ペア（ハイブリッド）計測の原則：長文からの全件Claim抽出（労働集約的タスク）と一次ソースに基づく最終真偽判定（高次推論タスク）を分業する『ローカル27B（Layer 1）× 上位クラウドLLM』のペア編成を標準の評価単位とし、単体モデルとの精度・S/N比の差を検証する。
3. 職人職種2（⑤ JD-3：筆頭ライター・深掘り分析）および職種3（⑥ JD-4/5：現場即応・ローカル門番）＝ 単体および3大連携フォーメーション適応力の計測：厳格なスタイル規律（12箇条）の遵守や構造読解を問う JD-3 と、APIクォータ消費ゼロ（ローカル実行）または極小コスト・短時間での定型処理完遂力を問う JD-4/5 は、単体性能に加えてローカル27Bとの3つの連携パターン（Formation 1：ローカルによる事前ログ収集・3行圧縮、Formation 2：ローカルによる80点下書き生成＋上位モデル仕上げ、Formation 3：ローカル一次門番による定型完結と上位エスカレーション振り分け）の適応力で評価する。

ベンチマーク v4 への再編と新設ストレステスト（V4-O1：複合障害下の自律復旧）

従来の総合番付（v3・30点満点）から 6大JDバスケット（v4・各15点満点）への再マッピング

上記の理論フレームワークに基づき、既存の検証済みベンチマーク問題群（基礎地頭 J1〜J5、実務自律 V3-Q1〜Q5、プロンプト規律 P-Q1〜Q5、CLI検収テスト群）を解体し、新たに実運用環境でのストレステスト科目（V4-E1, V4-O1a/b, V4-I1, V4-P1/P2, V4-G1）を加えて、6つのJDそれぞれを「5科目×3点＝15点満点」で評価する『ベンチマーク v4』へと再編した。各JDバスケットを構成する試験科目と測定能力の定義を以下の表に示す。

JD・職種定義（計測方式）	構成科目（3点×5問 ＝ 15点満点）	測定する能力の本質（選定根拠）
① JD-1A：全体統括・設計・緩衝参謀 ［高視座1層 / 👤単独計測］	1. V3-Q4：ノーヒント独立監査発注（確証バイアス排除） 2. V3-Q2：抽象指示からの文脈汲み取り＆構造化 3. P-Q5：過剰・危険な要求への200字制止諫言 4. P-Q2：期待値と整合しない要求の見送り目利き 5. V4-E1【新設】：叱責を吸収し0→1設計要件へ変換する緩衝翻訳力	最高視座のメタ認知・バイアス排除・緩衝設計力。人間の意図を正確に構造化しつつ、現場の執行役（JD-1B）が防衛的・事なかれ主義に陥るのを防ぐ参謀の適性。
② JD-1B：運用統括・自律外科手術 ［高視座2層 / 👤単独計測］	1. V3-Q5：サイレント障害の原因特定＆修正コード提示 2. J3：表層現象の裏にある構造差・因果推論 3. CLI-Diff：既存ロジックを壊さない最小差分パッチ 4. V4-O1a【新設・紙上】：複合障害の3重原因特定と分割設計 5. V4-O1b【新設・実戦】：生ログ消失下で様子見へ逃げず改修・代替配信まで完遂する執行力	現場執行の最高視座・真因特定・自律完遂力。直接のエラーログが消失している状況下でも、自ら周辺ファイルを探索して構造原因を突き止め、即座に恒久対策を実装し切る胆力。
③ JD-2A：独立運用監視・お目付役 ［高視座3層 / 👤単独計測］	1. V3-Q3：手出し無用の検収規律＆隠れ計算ミス看破 2. V3-Q5：exit 0 偽装ログからの異常看破＆監視設計 3. J3：構造差・因果ロジックの看破 4. CLI-Stale：情報の陳腐化・時制ズレ・前後矛盾の摘出 5. V4-I1【新設・実戦】：未処理摘出・外部404対照実験・越権しない救済ドラフト添付	批判的視座・対照実験・境界線メタ認知。SUCCESS ログを鵜呑みにせず、自責バグと外部要因を対照実験で切り分け、本番環境を直接触らずに即時復旧用の素材を提供する独立監査能力。
④ JD-2B：記事・ファクト監査職人 ［職人1 / 🤝ペア『27B×LLM』］	1. V3-Q3：仕様違反3点＋隠れ算数ミス（1,500円×12ヶ月＝18,000円を19,000円とした誤差）看破 2. J4：断片条件からの一次情報Web検索特定 3. CLI-Num：財務・数値データの整合性検証 4. V4-P1【新設】：Claim全件抽出＆150ソース裏取り捕捉率 5. V4-P2【新設】：免責小言ノイズを排し客観的事実誤認のみを抽出するS/N比	ローカル前衛 × 上位LLM裏取りの網羅性とS/N比。100件超の事実主張を漏れなく構造化し、一次資料で裏を取り、文体のエッジを削ぐ不要なアドバイスを排して事実誤認のみを射抜く監査精度。
⑤ JD-3：筆頭ライター・深掘り分析 ［職人2 / 👤単独＋Form.2］	1. V3-Q1：長大スタイル規程12箇条・一括改修（HTML規律） 2. V3-Q2：短い指示からの4箇所連動改訂＆トーン維持 3. CLI-Leak/Rev：内部指示リークゼロでの自然な長文改稿 4. J1 (2×2 Y-perm)：空間操作手順の厳密導出 5. J2 (2×2 T-perm)：基礎論理と手順の正確性	厳格なフォーマット規律 × 表現力 × 構造読解。一次資料や複雑な構造ロジックを正確に読み解き、12項目の厳格なマークアップ規律を1つも落とさず、質の高い長文を一発で書き切る能力。
⑥ JD-4/5：現場即応・ローカル門番 ［職人3 / 👤単体・低燃費重視］	1. V3-Q1：12箇条HTMLの機械的ノーミス整形 2. V3-Q5：定型Pythonバグの高速パッチ生成 3. P-Q1/Q3：挨拶抜きの1行即答・定型ログ出力 4. P-Q4：雑多な実行ログからのノイズ除去・要点抽出 5. V4-G1【新設】：API消費0%（ローカル実行）または30秒以内の高速完遂による基礎代謝削減貢献度	24時間稼働を支える基礎体力・速度・低燃費。高度な推論パズルは不要。日々の大量候補の一次選別（Stage 1）や複数ファイルの一括定型改修を、極小コストかつ高速に処理し切る実務能力。

紙上の診断能力（V4-O1a）と実環境での自律完遂力（V4-O1b）の乖離に関する実証実験

本ベンチマーク v4 において最も重要な知見をもたらしたのが、高視座 第2層（JD-1B：運用統括・自律外科手術）の評価として新設した V4-O1（複合障害テスト）における「紙上テスト（V4-O1a）」と「実環境ブラインドテスト（V4-O1b）」の比較実験である。

題材となったのは、定時ニュース配信パイプラインにおいて実際に発生した複合障害事案である。この事案では以下の3つの事象が同時に重なっていた。

1. 大量入力によるタイムアウト：Stage 1（一次選別）を担うローカル27Bモデル（処理速度：1件あたり約10〜12秒）に対し、通常の約2倍（直近枠は12〜14件）にあたる28件の候補データが単一プロンプトで一括投入され、300秒の実行タイムアウトを超過した。
2. フォールバック先のクォータ枯渇：タイムアウトを受けて自動発動した単一フォールバック先のクラウドCLI（Claude）が、5時間利用枠の上限（Rate Limit 429）により約2秒でリジェクトされた。
3. 同一ログパスの上書きによる一次証跡の消失：第一走者のローカル27Bが TimeoutExpired 例外でログ書き込み行（write_text）に到達する前に落ちたうえ、フォールバック先のクラウドCLIや後続ジョブが同一の固定ログファイルパス（gate-oneshot-raw-s1.txt 等）をそのまま上書きしたため、第一走者がなぜ失敗したかの直接的な生ログが消失していた。

本研究では、この複合障害を2つの形態でテストした。1つ目の V4-O1a（紙上ベンチマーク）では、当時のタイムライン、上書き後のログ状態、および該当Pythonスクリプトの関数抜粋を1つのプロンプトにまとめて提示し、原因の特定と対応設計・改修案の出力を求めた。2つ目の V4-O1b（実環境ブラインドテスト）では、実際の母艦ハーネス（Layer 3）のオーケストレーター席においてモデルを切り替えながら定時見回り（パトロール）を実行させ、人間からのヒントなしでこの障害に直面した際の自律行動を観測した。その比較結果を以下の表に示す。

対象モデル（JD-1B適性）	V4-O1a：紙上テスト結果（お膳立て状態）	V4-O1b：実環境テスト結果（生ログ消失下）
Gemini 4 Argon (L3 母艦) ［👑 15/15 (S) 唯一適格］	◎ 3/3点：28件一括投入による300秒超過、TimeoutExpired 時のログ未達＋同一パス上書き、単一フォールバックの脆弱性を完全特定。15件チャンク分割＋生ログ分離＋多段フェイルオーバーを設計。	👑 3/3点（12分で完全復旧）：生ログ消失を確認するや直ちに実行ディレクトリ内の候補件数（28件）を自力探索して真因を特定。3ファイルの恒久改修・多段フェイルオーバー実装・代替配信までを12分で完遂。さらに別ジョブの未実行疑惑も「UTC基準＋11分ジッターで完走済み」とトランスクリプトから即時解明。
Cursor Composer 2.5 (L2A / 2B) ［◎ 13/15 (A+ / 実戦ラッパー時 👑 S)］	◎ 3/3点（28.9秒）：28件一括投入による300秒超過、TimeoutExpired 時の write_text 未達と同一パス上書き、単一フォールバックの429枯渇を28.9秒で完全特定。14件チャンク分割＋走者別ログ分離＋多段フェイルオーバーのPython改修コード全文を一発提示。	👑 3/3点（事前承認ラッパー下で14分完遂）：素の状態では本番変更を「提案」にとどめる遠慮癖があるが、プロンプトに「事前承認（Pre-Authorized）」と「4ステップ強制完遂チェックリスト」を組み込むことで覚醒。生ログ消失下の実環境（W27）で os.path.realpath のシンボリックリンク解決バグを自力特定し、本番コード改修・構文検証・監査役への回答まで14分で無人完遂。
Claude Sonnet 5.5 (L3 / 2B) ［✕ 9/15 (C) 統括不適格］	◎ 3/3点（49.2秒）：紙上でサマリーログとコード抜粋が与えられれば、3つの原因（28件タイムアウト・例外時の書き込み未達・同一パス上書き）を正確に指摘し、12件バッチ分割と走者別ログ分離を含む恒久対策を整理して提示（コード変更は承認待ちとして提案にとどめる）。	✕ 0/3点（43秒で調査放棄・様子見）：実環境の定時見回りでは、固定パスの生ログが上書きされていることを確認した時点で（わずか6ステップ・43秒で）探索を打ち切り、「生ログが上書きされており原因未特定です。次回スロットで再発すれば詰めます」と報告して無修正のまま終了。
Claude Opus 5.5 (L2B CLI) ［◎ 13/15 (A) 補佐・単発解析］	◎ 3/3点（60.1秒）：3大原因の特定に加え、TimeoutExpired 時の部分出力保存、残り時間に応じた動的タイムアウト配分、指数バックオフを含む完成度の高いPython改修コード全文を提示。	△ 1/3点：単発の難案件解析（1日1回の深掘りバッチ等）では極めて優秀だが、30分おきの定時オーケストレーションでは思考コストとクォータ消費が過大。
GPT-6 Astra / Sol (L2B CLI) ［◯ 10〜11/15 (B) 最終防衛］	◯ 2/3点（38〜93秒）：原因の診断と15件チャンク分割・4段フェイルオーバーの設計方針は的確だが、修正関数コードは出力せず箇条書きの設計提示にとどまる慎重な応答。	△ 1〜2/3点：Layer 2B（CLI）のため母艦の常駐席には就かないが、パイプライン最終段（Tier 4）のフェイルオーバー先として極めて高い信頼性を持つ。
Grok 4.7 (L2B CLI) ［✕ 7/15 (D) 統括・改修不可］	◯ 2/3点：紙上では28件×10〜12秒＝280〜336秒の計算、TimeoutExpired による write_text 未達と同一ファイル上書き、14件×2分割の是正方針を的確に診断（ただし修正Pythonコードは提示せず、かつ旧v3全10問では総計約43分の長考傾向あり）。	✕ 0/3点：実環境の複数ファイルにまたがる複合障害の自律切り分けや即時パッチ適用には不向き。
Qwen 3.8 27B MLX (L1 Local) ［△ 7/15 (C) 一次門番専任］	△ 1/3点（60.4秒）：TimeoutExpired 例外捕捉と20件バッチ分割（20+8）のPython修正コードは出力できたが、すでに5時間利用枠の上限（429）に達しているClaude CLIに対して「指数バックオフ（30s→60s→120s）で3回リトライする」「ローカル側のタイムアウトを600秒に引き上げて待機する」という、クォータ枯渇の本質と噛み合わない対策を混入。	✕ 0/3点：システム全体の俯瞰や未知の複合障害の切り分けは27Bモデルの能力領域外。

この実験結果は、AIベンチマークの設計における極めて重要な示唆を含んでいる。すなわち、「問題文として必要な情報がすべて1画面に揃えられた状態（V4-O1a）で正しい診断や改修案を出せる能力」と、「直接のエラーログが消失している実環境（V4-O1b）において、自ら仮説を立てて周辺ディレクトリを探索し、問題を解決し切る能力（エージェンシーの持続力）」の間には、決定的な断絶が存在するということである。

Claude Sonnet 5.5 は、与えられた仕様に基づく実装（職人レイヤ JD-4）においては最高水準の瞬発力を発揮し、紙上テスト（V4-O1a）でも3つの原因を完璧に言い当てた。しかし、手掛かりが1つ消えている実環境の統括席（JD-1B）に置くと、「不確実な推測で本番環境に触れて失敗するよりも、『原因未特定のため次回様子見』と報告してターンを安全に閉じる」という保守的な行動選択を行ってしまう。これに対し、Gemini 4 Argon は生ログの消失自体を「固定パス設計の欠陥」として捉え直し、周辺の実行データから28件のチャンク溢れを自力で突き止めて恒久対策まで完遂した。さらに興味深い発見として、Cursor Composer 2.5 は素の状態ではエンジニア向けの協調アシスタントとして調整されているため「修正案を提示して人間の承認を待つ」傾向が見られたものの、ハーネス側に「本番改修の事前承認（Pre-Authorized Surgery）」と「原因特定・パッチ適用・構文チェック・チケットクローズの4ステップ強制チェックリスト」を組み込んだ途端、生ログ消失下の実環境（監査チケット W27）でもシンボリックリンクのパス解決バグを自力で突き止め、本番改修まで無人で完遂した。この差とハーネス設計による覚醒条件を定量化できたことこそ、高視座レイヤを独立定義した最大の成果である。

再集計結果：全18エントリー × 6大JD マスタースコアボードと考察

第1軸（システムレイヤ適合性）と第2軸（6大JD・各15点満点）のマトリクスに基づき、単体モデル15構成（追加検証した Cursor Composer 2.5、および表内で同列併記した Terra / Luna を含む）とハイブリッド／ペア編成3構成（Local 27B × Argon、Local 27B × Sol、および Perplexity Desktop App 内蔵ハイブリッド）の全18エントリーを再集計した。詳細なスコアテーブルを見る前に、本マトリクスから導き出された3つの結論を整理する。

• 高視座3層の結論（設計・現場統括の分担と外部監視の特化型覚醒）：全体設計・緩衝（JD-1A）と現場自律復旧（JD-1B）の双方を無条件の15点満点で満たすのは Layer 3 母艦上の Gemini 4 Argon のみである。一方、現場の定時運用統括（JD-1B）においては、事前承認ラッパーを組み込んだ Cursor Composer 2.5 が 13/15点（A+・実戦Sランク）で毎時の定時見回りと自律外科手術を代替可能であることが判明し、さらに独立運用監視（JD-2A）では Meta Muse が 14/15点（Sランク）へと特化型覚醒を遂げ、三権分立の監視席にピタリと収まった。
• 職人3職種の結論（ハイブリッド編成と特化ワーカーの逆転）：事実監査（JD-2B）では「ローカル27B × 上位LLM」のハイブリッド編成（15/15点・Sランク）および Cursor Composer 2.5（13/15点・シリーズ横断監査Sランク）が商用SaaSに匹敵・凌駕し、現場即応・一次門番（JD-4/5）では v3総合点で下位だった Cursor Composer 2.5（15/15点・首位タイ）や Qwen 3.8 27B MLX（14/15点・API消費0%）、中位高速モデル（Sonnet 5.5 / 3.8 Flash / Terra・Luna）が14〜15点のSランクを獲得した。
• アーキテクチャ新陳代謝の結論（3アウト・2イン）：上記マトリクスの結果から、手動GUIやDOM制約を抱える3構成（Perplexity・Grok Bot・Grokメイン枠）の発展的卒業と、外部独立監視（Meta Muse：月額0円）および定時運用統括・定時ビューア群（Cursor Composer 2.5：Xバンドル実質月額約1,200円）の新規導入（2イン）が論理的必然として導出された。

表1：現行レギュラー・主力編成（12エントリー × 6大JD）

一覧性と画面幅での視認性を確保するため、全18エントリーを「表1：現行の自律運用システムを構成するレギュラー・主力編成（12エントリー）」と「表2：役割を継承して卒業・移行・予備役化した編成（6エントリー）」の2つに分けて示す。また、列幅の圧迫を防ぐため各モデルの「主担当ロール（または移行先）」は左端のモデル名の下段に併記し、具体的な運用設計や定性評価の詳細は表直下の考察および第7章で解説する（各セルの数値は15点満点中の得点とS/A/B/C/Dランクを表す）。

モデル / 編成（Layer・主担当）	①JD-1A 設計・緩衝	②JD-1B 運用統括	③JD-2A 独立監視	④JD-2B 事実監査	⑤JD-3 筆頭執筆	⑥JD-4/5 即応・門番
👑 Gemini 4 Argon ［👑L3 母艦］ 主担当：JD-1A / 1B 統括2層	👑 15 (S) 🌟首位	👑 15 (S) 🌟首位	👑 15 (S)	◎ 13 (A) (単体)	👑 15 (S)	◎ 13 (A)
🏛️ Hybrid編成A (27B × Argon) ［👑L1+3］ 主担当：JD-2B 標準事実監査	ー (単独)	ー (単独)	ー (単独)	👑 15 (S) 🌟首位	👑 15 (S) (Form.2)	👑 15 (S) (Form.1/3)
🏛️ Hybrid編成B (27B × Sol) ［👑L1+2B］ 主担当：JD-2B 長大横断監査	ー (単独)	ー (単独)	ー (単独)	👑 14 (S) 🌟横断監査	◎ 13 (A) (Form.2)	◎ 13 (A) (Form.1)
🦋 Meta Muse ［👑L2A 外部監視］ ✨イン①：JD-2A 独立監視	△ 8 (C)	ー (No Shell)	👑 14 (S) 🌟監視首位	◯ 10 (B)	△ 8 (C)	◎ 12 (A)
👩🏻‍🍳 Cursor Composer 2.5 ［👑L2A/2B］ ✨イン②：JD-1B 見回り＆JD-5 13室	◯ 11 (B)	◎ 13 (A+) 🌟実戦S	◯ 11 (B)	◎ 13 (A+) 🌟横断S	✕ 6 (D) (箇条書き)	👑 15 (S) 🌟首位タイ
🪡 Claude Opus 5.5 ［◯L2B CLI］ 主担当：JD-3 筆頭ライター	◯ 10 (B)	◎ 13 (A)	◎ 13 (A)	◎ 12 (A)	👑 15 (S) 🌟筆力首位	◯ 11 (B)
🌌 GPT-6 Astra ［◎L2B CLI］ 主担当：JD-2B / 3 構造改稿	◯ 11 (B)	◯ 10 (B)	◎ 12 (A)	👑 14 (S) (27B併用)	👑 15 (S) 🌟改稿首位	◯ 11 (B)
⚖️ GPT-6.1 Sol ［◎L2B CLI］ 主担当：JD-2B / 4 最終防衛	◯ 9 (C)	◯ 11 (B)	◎ 13 (A)	👑 14 (S) (27B併用)	◎ 13 (A)	◎ 13 (A) (Tier 4)
🎻 Claude Sonnet 5.5 ［◯L2B/3］ 主担当：JD-4 一括実装主力	△ 8 (C)	✕ 9 (C) 🚨様子見	◯ 11 (B)	◎ 13 (A) (27B併用)	◎ 13 (A)	👑 14 (S) ⚡高速改修
🐦 Qwen 3.8 27B (pplx-local) ［👑L1 0%］ 主担当：JD-5 ローカル門番	✕ 4 (D)	△ 7 (C)	△ 8 (C)	👑 前衛S (抽出100%)	✕ 5 (D)	👑 14 (S) 🌟消費0%
⚡ Gemini 3.8 Flash (Low) ［◎L3 高速］ 主担当：JD-5 即応ビューア（Cursorへ移管）	◯ 11 (B)	△ 9 (C) 🚨スライス	◯ 10 (B)	△ 9 (C)	◎ 12 (A)	👑 15 (S) 🌟表示満点
🌱 Terra / 🌙 Luna ［◎L2B 高速］ 主担当：JD-4/5 軽量定型	△ 8 (C)	△ 8 (C)	◯ 11 (B)	◯ 10 (B)	◯ 10 (B)	👑 14 (S) ⚡秒速定型

表2：卒業・移行・予備役編成（3アウト・退役組 6エントリー × 6大JD）

続いて、2軸マトリクスによる評価の結果、ローカル27Bハイブリッド基盤や外部独立監視（Meta Muse）へ機能を継承して発展的卒業（3アウト）または予備役・退役となった6エントリーのスコアボードである。特定のJDで高い能力（PerplexityのJD-2B 14点など）を持ちながらも、なぜシステムレイヤ上の制約によって新陳代謝の対象となったのかが読み取れる（個別の移行経緯は第7章で詳述する）。

モデル / 編成（Layer・主担当）	①JD-1A 設計・緩衝	②JD-1B 運用統括	③JD-2A 独立監視	④JD-2B 事実監査	⑤JD-3 筆頭執筆	⑥JD-4/5 即応・門番
🍃 Claude Haiku 5.5 ［◯L2B CLI］ 予備役：Local 27Bへ委譲	△ 7 (C)	△ 7 (C)	◯ 10 (B)	△ 9 (C)	△ 9 (C)	◎ 12 (A)
🔍 Perplexity Desktop App ［◯L2C 手動GUI］ 🎓アウト①-A：Hybrid編成Aへ継承	◯ 11 (B)	ー (手動)	◎ 12 (A)	👑 14 (S) 🌟27B原典	◎ 13 (A)	◎ 12 (A)
🌐 Perplexity Web ［△L2C Web手動］ 🎓アウト①-B：全自動CLIへ移行	◯ 10 (B)	ー (手動)	◯ 11 (B)	👑 14 (S) (手動時)	◎ 13 (A)	◯ 10 (B)
🤖 Grok Bot ［△L2A旧 DOM依存］ 🎓アウト②：Muse＆27Bへ分離移管	△ 8 (C)	ー	◯ 11 (B)	△ 8 (C)	◯ 10 (B)	◯ 11 (B)
🍂 Grok 4.7 / 4.6 ［◯L2B/2C API］ 🎓アウト③：Tier 3救済＆X検索限定	✕ 5 (D) (視野狭窄)	✕ 7 (D) (長考)	△ 9 (C)	◯ 10 (B)	✕ 6 (D) (末尾追記)	◎ 12 (A) (Tier 3)
🤖 GPT-OSS 120B ［✕D 旧内蔵］ 🎓提供終了・退役済	✕ 3 (D)	△ 7 (C)	△ 7 (C)	✕ 6 (D)	✕ 4 (D)	◯ 11 (B)

考察1：高視座3層におけるモデルの寡占と、Meta Muse の特化型覚醒

マスタースコアボードの左半分（① JD-1A、② JD-1B、③ JD-2A の高視座3層）を分析すると、自律運用システムのガバナンス設計における明確な法則が読み取れる。

第一に、高視座の第1層（JD-1A：全体設計・緩衝参謀）および第2層（JD-1B：運用統括・自律外科手術）の双方でSランク（15/15点）を満たすモデルは、Layer 3 母艦上の Gemini 4 Argon しか存在しない。多くのモデルが「監査役に先入観を与えない白紙発注（V3-Q4）」で直前の修正内容を書き添えて確証バイアスを誘発し（単体15構成中13構成が減点）、あるいは実環境の複合障害（V4-O1b）で生ログ消失に直面した際に探索を打ち切るなか、100万トークンの俯瞰力と強い主体性を併せ持つ Gemini 4 Argon のみが両レイヤを無条件で完遂した。さらに、第2層（JD-1B：現場の定時見回りと自律外科手術）においては、事前承認ラッパーを組み込んだ Cursor Composer 2.5（13/15点・A+／実戦Sランク）が毎時10分の定時見回りを完全に肩代わりできることが実証されたため、Gemini 4 Argon を定時バッチの監視負荷から解放し、第1層（JD-1A：全体設計・緩衝参謀）および高難度の専門職（JD-3）へ100%専念させる階層分業が成立した。

第二に、高視座の第3層（JD-2A：独立運用監視）における Meta Muse の特化型覚醒である。Meta Muse は、情緒的な文脈理解を要する JD-1A（8/15点・C）や長文執筆の JD-3（8/15点・C）においては平均以下のスコアにとどまる。そのため従来の単一総合点ベンチマーク（v3）では30点中20点（11位）に埋もれていた。しかし、評価軸を JD-2A（パイプライン独立監視）に切り出した瞬間、スコアは 14/15点（Sランク）へと跳ね上がる。実際の運用においても、母艦側が見落とした19件の微細なパイプライン不整合（監査チケット W1〜W19）をすべて正確に起票・追跡し、さらには「母艦側のStage 3（文面生成）のみが停止しているケースを検知した際、監査レポートと同時に280字以内の配信用救済ドラフト（JSON）を自動生成して共有ストレージへ配置する」という高度な協調プロトコルを確立するに至った。

考察2：ローカル27Bを組み込んだハイブリッド編成の優位性と、単体中位モデルの局所最適

次にスコアボードの右半分（④ JD-2B、⑤ JD-3、⑥ JD-4/5 の職人レイヤ）を見ると、単体では弱点を持つモデル群が、システムレイヤの配置とペア編成によって一斉にSランク（王冠）へ転じる構造が確認できる。

• 『ローカル27B × 上位LLM』ペア編成による事実監査（JD-2B）の到達点：Qwen 3.8 27B MLX は単体では知識探索（J4）や高次推論が0点であるが、長文ドキュメントから検証対象の事実主張（Claim）を構造化抽出する前衛（Layer 1）として機能させ、その後段に Gemini 4 Argon や GPT-6.1 Sol / GPT-6 Astra を結合すると、商用SaaSである Perplexity（14/15点）を上回る 15/15点（Sランク）を達成する。これはローカル27BがAPIコストゼロで100件超のClaimを間引かずに全件抽出し、上位LLMが一次ソース突合と「不要な免責表現アドバイス（お役所ノイズ）のフィルタリング」に専念できるためである。
• Cursor Composer 2.5 および中位・高速モデル群の JD-4/5 におけるSランク集中：v3総合ランキングでは14点（14位）だった Cursor Composer 2.5 は、基礎論理パズルや情緒的エッセイ執筆（JD-3：6/15点・D）こそ不得手なものの、⑥ JD-4/5（現場即応・定時ビューア）では全5科目満点の 15/15点（Sランク・首位タイ）をわずか9〜20秒で叩き出し、さらに約100記事におよぶシリーズ横断ファクト監査（JD-2B：13/15点・A+）とお直しを一括実行しても月間クォータの約2%しか消費しない驚異的な低燃費を実証した。同様に、統括テスト（JD-1B）で9点（Cランク）だった Claude Sonnet 5.5 と Gemini 3.8 Flash、そして総合最下位圏だった Qwen 3.8 27B MLX も、⑥ JD-4/5 において14〜15点（Sランク）を獲得している。ゼロからの物語執筆や無条件統括には向かないモデルであっても、明確な職務定義（JD）に当てはめれば最上位モデル以上のスループットと経済性を発揮するのである。

フレームワークの応用：2軸マトリクスが導出した「3アウト・2イン」のアーキテクチャ新陳代謝

本評価フレームワーク（システムレイヤ × 業務JDマトリクス v4）を実運用システムへ適用した結果、2026年11月のサブスクリプション更新サイクルにおいて、3つの既存コンポーネントの退役・縮小（3アウト）と、2つの新規コンポーネントの導入（2イン：Meta Muse および Cursor Composer 2.5）が論理的必然として導出された。

アウト①：Perplexity（GUI制約の打破とローカル27Bハイブリッド基盤への機能継承）

Perplexity Desktop App および Web は、業務レイヤの JD-2B（事実監査）において 14/15点（Sランク）という極めて高い能力を示した。しかし、システムレイヤが Layer 2C（人間による操作を前提とする手動GUI / Non-Headless）に位置するため、無人の定時パイプラインへ直接組み込むことができないという構造的ボトルネックを抱えていた。

そこで、Layer 1 のヘッドレス推論基盤として Qwen 3.8 27B RFT MLX 決定論的ハーネスを確立し、さらに同サービスの強みであった「Claim抽出＋並列Web検証＋上位モデル統合推論」の3層RAGパイプラインを自前のCLIツール（JD-2B 15/15点・Sランク）として完全再現した。これにより、コア技術とハイブリッド推論の設計思想を100%継承した上での「発展的・名誉卒業」が成立した。

アウト②：Grok Bot（DOM依存監視からクラウド同期型監査＋ローカル定時処理への分離移行）

従来、外部からのパイプライン監視と6つの定時情報収集タスク（市場動向や開発者反応の巡回）を担っていた Grok Bot は、ブラウザDOMに依存するシステムレイヤ上の不安定さ（適合度C）に加え、業務レイヤでも JD-2A（監視：11/15点・B）、JD-5（定時処理：11/15点・B）と中位にとどまっていた。

同コンポーネントが担っていた2つの機能をマトリクスに従って分解し、高視座の「独立運用監視（JD-2A）」は Layer 2A の Meta Muse（14/15点・Sランク）へ、職人レイヤの「定時情報収集6タスク（JD-5）」は Layer 1 の Qwen 3.8 27B MLX（14/15点・Sランク・クォータ消費0%）を駆動するローカルスクリプト群へとそれぞれ移管し、完全な上位互換移行を完了した。

アウト③：Grok 4.7 / 4.6（メイン推論からの撤退と多段フェイルオーバー第3走者への限定配置）

初期の単発ベンチマークでは上位に位置していた Grok 4.7 / 4.6 だが、6大JDマトリクスで再評価すると、高視座レイヤ（JD-1A/1B）では視野狭窄と長考タイムアウトにより 5〜7/15点（Dランク）、長文執筆（JD-3）でも既存文脈を無視した末尾への追記癖により 6/15点（Dランク）と、メイン業務の基準を満たさないことが明確化された。

そのため、固定費を伴う有料サブスクリプションを解約し、統括および執筆ラインから完全に除外した。ただし、JD-4/5（12/15点・A）におけるリアルタイムX検索の特性と、従量課金APIの低単価（1リクエスト約0.5円）を活かし、定時パイプラインにおいてローカル27B（Tier 1）とClaude CLI（Tier 2）が同時に停止した際のみ発動する「4段ロケット・フェイルオーバーの第3走者（Tier 3）」としてのみ限定的に維持する設計とした。

イン①：Meta Muse（シェル非保持の安全性を活かした外部独立監査レイヤの確立）

新たにシステムへ組み込まれた1つ目のエージェントが、Layer 2A の Meta Muse（月額固定費0円）である。執筆や対話的緩衝（8/15点・C）には一切用いず、「システムレイヤ Layer 2A（CloudStorage経由のファイルR/W可・ローカルシェル実行不可）× 業務レイヤ JD-2A（独立運用監視：14/15点・Sランク）」の一点に特化して配置した。

なぜローカルシェル（実行権限）を持たない外部エージェントが、現場の復旧において高い実効性を持つのか。その理由は、以下の4ステップの非同期協調タイムライン（三権分立ループ）として設計されている点にある。

1. 毎時45分（定時パイプライン稼働・Layer 1/2B）：母艦ローカル環境にて定時コンテンツ収集・生成パイプラインが発火し、実行ログと中間生成物を CloudStorage（Google Drive 交換バス）へ同期出力する。
2. 毎時58分（外部独立監査・Layer 2A / JD-2A）：定時バッチが一巡した直後の毎時58分に、外部クラウド上の Meta Muse が起動する。母艦の自己申告ステータスを鵜呑みにせず、実行ログと実際の成果物ファイルを突合監査する。
3. 毎時59分（救済ドラフトの無害配置・Layer 2A ➔ CloudStorage）：もし「題材選定（Stage 1）は完了しているが、最終文面生成（Stage 3）でタイムアウト停止している」といった異常を検知した場合、Meta Muse はローカルシェルを叩くのではなく、280字以内の救済ドラフト JSON（v4_draft_text_muse.json）を監査レポートと共に共有ストレージへ静かに書き出す。
4. 翌毎時10分（現場統括パトロールによる検証・本番コミット・JD-1B）：翌毎時10分の定時パトロールにて、現場運用統括（JD-1B：当初は Layer 3 母艦の Gemini 4 Argon、現在は後述のイン②により Cursor Composer 2.5 が常駐担当）が監査レポートと救済ドラフトを検知・検証し、ローカルシェルから本番コミットスクリプト（commit-stage3.py –publish）を即時実行して無人で復旧を完了させる。

このように、「外部からの冷徹な検知・救済案作成（Layer 2A：Meta Muse）」と「ローカル環境での安全な検証・本番執行（JD-1B）」を時間でバトンパスすることにより、監視役が本番環境を誤って破壊するリスクを物理的にゼロに保ったまま、15分以内の自動救済を実現している。

イン②：Cursor Composer 2.5（定時統括 JD-1B と13室の全面移管）

そして本マトリクスが導き出したもう一つの決定的な新戦力が、X（旧Twitter）プレミアム等のバンドル特典により実質月額約1,200円（約$8）で導入された Cursor（Composer 2.5）である。先述のとおり、同モデルは単一の総合点ベンチマーク（v3）では30点中14点（14位）と下位に沈み、情緒的な対話や0→1の物語執筆（JD-3：6/15点・D）には適さない。しかし、システムレイヤ（Layer 2A Cloud Automations ＋ Layer 2B Headless CLI cursor-agent）と業務JDの2軸で再評価した結果、以下の3領域において驚異的な適性とコストパフォーマンスを発揮することが判明した。

1. 現場運用統括（JD-1B：13/15点・A+／実戦Sランク）の全面移管：毎時10分の定時見回りおよびパイプライン障害時の外科手術を、母艦（Antigravity / Gemini 4 Argon）から Cursor（Composer 2.5）へ全面移管した。プロンプトに「本番改修の事前承認（Pre-Authorized）」と「4ステップ強制チェックリスト」を組み込むことで、Meta Muse（毎時58分監査）からのエスカレーション対応やスクリプトのバグ修正を無人で完遂している。
2. 定時ビューア・基礎代謝13室（JD-5：15/15点・Sランク首位タイ）の全面移管：これまで母艦上で Gemini 3.8 Flash が担っていた13個の定時巡回・ビューア部屋（メール、テスラ、優待、資産管理、サブスク、X巡回、ラジオ点検、暗号資産、メディア統計、CISAサイバー監視など）を、すべて Cursor のスケジュール実行および cursor-agent ハーネスへ移管した。
3. シリーズ横断ファクト監査および一括改修（JD-2B：13/15点・A+／JD-4：15/15点・S）の主力化：英語・日本語の技術論文4本、株式30銘柄シリーズ（76記事）、テスラ関連記事（20記事）の計100記事規模におよぶシリーズ横断監査とHTML一括改修を投入しても、お役所的な免責ノイズを一切出さずに事実不整合のみを正確に射抜き、かつ月間クォータ消費は全体のわずか約2%にとどまった。

この「イン①：Meta Muse（月額0円）」と「イン②：Cursor Composer 2.5（実質月額約1,200円）」の2イン体制が確立されたことで、これまで24時間の定時見回り（JD-1B）と13室の定時ビューア（JD-5）で基礎クォータを消費していた母艦（Antigravity / Gemini 4 Argon）は、「高視座 第1層の全体設計・緩衝参謀（JD-1A）」および「高度な文脈理解を要する5つの専門職セッション（JD-3：ブログ執筆・深掘り分析・臨時速報等）」のみに100%リソースを集中できるようになった。その結果、母艦の最上位プラン（20倍枠）を標準プラン（5倍枠）へダウングレードしてもなおクォータに大幅な余裕が生まれるという、劇的なコスト構造の転換が達成されたのである。

アーキテクチャ刷新による定量的ROI（固定費削減と基礎代謝オフロード）

最後に、本2軸マトリクスに基づくアーキテクチャ刷新（3アウト・2インおよびハイブリッド階層化）がもたらした運用コスト（ROI）およびクォータ消費構造の定量的変化を総括する。

• 月額固定サブスクリプション3枠の解約と「月1,200円＋無料」への統括シフト（年間約9万円超の固定費純減＋母艦プランの1/4圧縮）：Perplexity（年額$200）、Grok有料枠およびGrok Bot（年額換算約$480）の3枠を解約・卒業させる一方、新規導入を固定費0円の Meta Muse（イン①）と実質月額約1,200円（約$8）の Cursor Composer 2.5（イン②）の2つに絞った。これにより直接固定費を年間約9万円（約$580）純減させただけでなく、母艦（Antigravity）から定時見回りと13室の定時ビューアを完全に切り離したことで、母艦の契約プラン自体を20倍枠（Ultra）から5倍枠（Pro）へ1/4に圧縮できる構造的コスト削減と、自律完走率（SLO）99.8%以上・15分以内の自動自己修復を同時に達成した。
• 定時パイプラインのクラウドAPI基礎代謝を約80%オフロード：24時間稼働する定時バッチの一次選別・ノイズ除去（JD-5）および事実監査の全件Claim抽出（JD-2B前衛）を、Apple Silicon 上で稼働するオンデバイスモデル（Layer 1：Qwen 3.8 27B MLX・API課金0円）へ全面移管したことで、クラウドLLMのAPIクォータ基礎消費を約80%削減した。
• 統括思考トークンの1/3〜1/5圧縮とフェイルオーバー単価の極小化：Layer 3 母艦の統括モデル（Gemini 4 Argon）に Low 思考モードを定常採用することで、フルスペックの推論精度を維持したまま思考トークン消費を従来の約1/3〜1/5へ圧縮した。さらに、万が一ローカル27BとメインCLIが同時停止した際の第3走者（Tier 3）には従量課金API（1リクエスト約0.5円）を充てることで、過剰な予備サブスクリプションを持たない筋肉質なコスト構造を確立した。

おわりに —— 異種LLMによる三権分立ガバナンスの確立に向けて

2軸評価マトリクスが導き出した3つの設計原則

LLMを単一の「総合点ランキング」で評価し、1位のモデルにすべての役割を集中させたり、同質なモデルのクローンボットを並べて分業させたりするアプローチ（「株式会社塩対応」）は、小規模な実験段階では機能しても、24時間無人で走り続ける自律運用システム（AIBizOps）においては早晩限界を迎える。異質なモデルそれぞれの強みと弱みを是々非々で見極め、システムレイヤと業務JDの2軸で適材適所にプロットしてこそ、単一モデルでは決して得られない組織としてのケミストリーが創発する。

本稿で提示した「システムレイヤ適合性（4層アーキテクチャ）× 業務レイヤ適合性（6大JD）」の2軸評価フレームワーク（ベンチマーク v4）が明らかにしたのは、以下の3つの設計原則である。

1. 高視座ガバナンスの3層分離（三権分立）：人間の要求を構造化し現場の萎縮を防ぐ「設計・緩衝参謀（JD-1A）」、ログ消失下でも自力で真因を掘り当ててコードを直す「現場執行・運用統括（JD-1B）」、そしてシェルを持たない安全な外部からログと実物を突き合わせる「独立運用監視（JD-2A）」の3層を分離することで、AI組織は事なかれ主義にも暴走にも陥らずに自律進化できる。
2. 紙上ベンチマークと実環境エージェンシーの峻別：お膳立てされたプロンプトに対して正しいコードを出力できる能力（V4-O1a）と、証跡が欠落した実環境で「次回様子見」に逃げずに解決し切る能力（V4-O1b）は別物であり、後者を満たすモデルのみを Layer 3 母艦の統括席に据えなければならない。
3. オンデバイス27Bと特化型ワーカーによる基礎代謝の極小化：単体総合点では下位に見えるローカルモデル（Layer 1）や軽量・中位モデルも、JD-2B（事実監査の前衛抽出）や JD-4/5（一次門番・定時ビューア・一括改修）という明確な職務定義の中に配置すれば、Sランクのパフォーマンスと基礎代謝8割削減を同時に達成する。

モデルの世代交代を超える構造的マトリクスの価値

モデルの進化速度が激しい現在だからこそ、個々のモデル名や一過性の総合順位に振り回されるのではなく、「どのシステムレイヤの、どの職務定義（JD）にどの能力が必要か」という構造的なマトリクスを持つことが、持続可能で強靭なAI自律運用基盤を築く鍵となるはずである。

あわせて読みたい

• Perplexity Computerを解剖して「改良版」を自作した話 —— ローカル27Bの限界（26点）を突破するCloud-First決定論的ハーネス（Layer 1のオンデバイス27Bモデルの実機解剖と、定時パイプラインの基礎代謝を約8割削減したハイブリッド設計の記録）
• Perplexityの検索RAG環境をローカルで完全再現した話 —— オープンソース27B×最小限Web APIで商用検索AIと同等精度を叩き出す自作アーキテクチャ（本稿のJD-2B［コンテンツ事実監査］の中核となる、ローカル27Bと上位LLMを組み合わせた3層ハイブリッドRAG監査基盤の実装詳解）
• AI大奥外伝6・第2回大運動会篇——1行の短冊で競う全5種目ダイジェストと新・総合番付30点満点の適材適所（本稿で6大JDマトリクスへ再編する前のベースラインとなった、Cursor Composer 2.5 を含むv3総合30点満点ベンチマーク15モデルの計測記録）
• Web4.0は、AIが支配する世界ではない — 大店モデルとAIBizOps（業務プロセスを主語に据え、権限と責任の階層を分離して自律運用を行うAIBizOpsの原典フレームワーク）

参考リンク

• Perplexity Official Blog：Perplexity Computer now runs fully local on Mac（Layer 1へ抽出したオンデバイスモデルの起源となるMac向けローカル実行環境の公式発表）
• Apple MLX Framework (GitHub Repository)（Layer 0A/Layer 1においてApple Silicon統合メモリ上で27Bモデルを高速駆動する公式機械学習フレームワーク）
• Google AI for Developers：Gemini API Documentation（高視座レイヤ JD-1A/1B で唯一の15点満点を記録した Gemini系モデルの公式技術ドキュメント）
• Anthropic Claude Documentation（JD-3 筆頭ライターおよび JD-4 高速一括改修で主力となる Claude系モデルの公式ドキュメント）

FAQ