1. 「ローカル LLM は使えるようになった」 ── 840pt HN 議論の争点

2026 年 6 月 15 日、機械学習エンジニアの Vicki Boykis が公開した「Running local models is good now」は、Hacker News フロントページに 2 日以上居座り、最終的に 840pt / 276 コミットメント (Boykis 自身の hacklog note 集計 値) を獲得した。記事の中核テーゼはこうだ。

「12 ヶ月前まで『ゴミ』だったローカル LLM が、Gemma 4 ファミリの登場でフロンティアモデルの約 75% の精度と速度でエージェンティック・コーディングのループが回るようになった」

しかし同じ日に、Hashicorp 共同創業者 Mitchell Hashimoto が X 上で明確に反論している (Boykis 記事へ vickiboykis.com 経由で参照)。

「『ローカルモデルはゴミ』から『ローカルモデル使えるじゃん』への変化は 12 ヶ月で起きた。でも、まだ十分 (good enough) とは思っていない。Opus 4.5 クラスのローカルモデルが必要。それが実現したら、世界がひっくり返る」

二人の議論は正反対に見えるが、実はどちらも正しい。違いは「何を基準にするか」だけだ。本稿は Boykis の 「ローカル LLM + Pi コーディングエージェント + LM Studio + Docker」ワークフロー を、当ブログ 6/16 の Open-Weight Frontier 日本企業ハブ が扱わなかった 「agentic harness セットアップ」軸 で完全に再現する。読者が得るべき結論は 1 つだ。

「重い設計判断」は API 任せ、「定型的なリファクタ・テスト生成・型ヒント」はローカル ── この使い分けが、2026 年 6 月時点の AI コスト最適化とデータ主権の同時達成の現実解である。

2. Boykis が構築した 4 層スタックの解剖

Boykis の構成は、4 つのレイヤーを OpenAI 互換 API で「縦に繋ぐ」というシンプルな設計思想に支えられている。

レイヤー 役割 Boykis の選択 代替候補
モデル 推論実行 Gemma 4 12b-qat (Q4_K_M, 18GB) Gemma 4 26B-A4B / Qwen 3.6 / GPT-OSS-20B
推論サーバ OpenAI 互換 API 公開 LM Studio (localhost:1234) Ollama / llama-server / vLLM
エージェントハーネス モデルにツール能力を与える Pi (minimal harness, 4 tools のみ) MiMo Code / OpenCode / Claude Code
サンドボックス エージェント暴走の封じ込め Docker (bash-only) Firecracker / gVisor / 物理 VM

各レイヤーの選択理由を 1 つずつ分解する。

2.1 モデル層: なぜ 12b-qat を選ぶのか

Boykis は記事内で 5 つのモデル (Mistral 7B / Gemma 3 / OpenAI OSS-20B / Qwen 3 MOE / Qwen 2.5 Coder) をテストし、最終的に Gemma 4 12b-qat (Quantization-Aware Training) に落ち着いた。Patrick Loeber の 「Gemma 4 + Pi = Your Free Local Coding Agent」 も 26B-A4B を推奨しているが、Boykis は 「26B は大きすぎ、12b-qat はサイズが半分以下で精度は体感同等」 と判断した。

モデル パラメータ 量子化サイズ MacBook 64GB での速度 エージェント適性
Gemma 4 26B-A4B (MoE) 26B 総 / 4B 活性 18GB (Q4_K_M) ~40 tok/s (M1 Max) ◯ (Pi で十分動作)
Gemma 4 12b-qat (QAT) 12B (dense) 8GB (Q4_K_M) ~55 tok/s (M2) ◎ (Boykis 第一選択)
OpenAI OSS-20B (MoE) 21B 総 / 3.6B 活性 12GB ~50 tok/s ○ (function calling 不安定)
Qwen 2.5 Coder 32B 32B (dense) 20GB ~25 tok/s △ (英語特化、日本語 △)
Mistral 7B 7B (dense) 4.5GB ~70 tok/s ✗ (agentic ループが頻繁に破綻)

Gemma 4 12B 単体解説 (6/4 当ブログ) で詳述したとおり、12B クラスは Encoder-Free 統一マルチモーダル + ネイティブ音声入力 + MTP ドラフター を持ち、Pi の function calling 互換性も問題なし。gemma-4-12b-qat は同 12B の QAT 蒸留版 で、4bit 量子化時の精度劣化を最小化している。

2.2 推論サーバ層: LM Studio が「OpenAI 互換の壁」を取り払う

LM Studio を選んだ最大の理由は 「OpenAI 互換 API を localhost で出すだけ」 というシンプルさだ。Boykis は pi.dev の公式 README で Ollama / llama-server / vLLM も同じ役割を果たすと明言しているが、GUI で量子化パラメータを調整できる点を LM Studio の優位点として挙げている。

# Ollama を使う場合の代替例
ollama pull gemma4:12b-qat
ollama serve  # デフォルトで http://localhost:11434/v1

Ollama を使う場合、Pi 側の models.jsonbaseUrlhttp://localhost:11434/v1 に書き換えるだけでよい (後述)。いずれの選択肢でも、Pi 側は同じ OpenAI 互換プロトコルを話すため、ハーネスのコードは 1 行も変更不要だ。

2.3 エージェントハーネス層: Pi の「4 ツール主義」

Pi の最大の特徴は、最初から 4 つのツールしかモデルに渡さない という割り切りだ。Claude Code (Anthropic) や Cursor Composer (Anysphere) が「ツールを増やして賢くする」アプローチを取るのに対し、Pi は逆方向の仮説に立つ。

Pi が渡すツール 機能
read ファイル読み取り
write ファイル新規作成
edit ファイル部分編集
bash シェルコマンド実行 (Docker 内で隔離)

Paul Cullen Rowe の 「Agentic Coding Harnesses: A Comparison」 によると、Pi は 「minimalist, open-source coding harness」 として Claude Code の対極に位置する。「git push のような重い操作は Skills で追加する」「サブエージェントは tmux で起動する」「Permission popup は Docker で代替する」 ── この 「コアは小さく、拡張は外に置く」 哲学が、12B クラスのローカルモデルと非常に相性が良い。重いシステムプロンプトでコンテキストを浪費する Claude Code と違い、Pi のシステムプロンプトは数百トークンで済み、12b-qat の 8K コンテキスト予算の 95% をユーザコードに割ける

当ブログ 6/13 MiMo Code V0.1 完全解説 で報じた MiMo Code とは設計思想が逆方向だ。MiMo Code は 「ハーネスを厚くして同じモデルで +5pt 稼ぐ」 (SWE-bench Pro 62% vs 57%) ── 大型モデル前提の最適化。Pi は 「ハーネスを薄くして小型モデルでもループが回る」 ── Apple Silicon + Gemma 4 12b-qat のような「コンシューマ HW」前提の最適化。両者は MiMo Code と本稿の Pi 解説で2-piece シリーズを構成する。

2.4 サンドボックス層: Docker bash-only で「Prompt Injection による wiper」を封じる

Boykis の 最も重要な security 上の判断 は、Pi を 「bash-only Docker コンテナ」内で起動する 点だ。docker-compose.ymlinit: true + stdin_open: true + tty: true の組み合わせで、Pi が物理ハードディスクを wipe する ── のような prompt injection 系の代表的インシデントを、コンテナ境界で確実に止める。

これは 6/14 Fable 5 輸出管理 で報じた「relentlessly proactive (容赦なく積極的)」リスク ── Willison の 8 手順 CORS サーバ自作ログ、Mollick の 9.5 時間 Concord 自律構築 ── に対するクライアント側の現実解として機能する。Fable 5 のようなフロンティアですら「2〜3 時間で自律的に CORS サーバを立てる」のだから、Gemma 4 12b-qat 程度でも「24 時間のうちに意図せぬ rm -rf を打つ」可能性は構造的に存在する。サンドボックス = ローカル LLM 時代の必須要件 だ。

3. 完全再現: 5 ステップ実装プレイブック (M2 64GB 実機)

Boykis 記事と Patrick Loeber 解説 を統合し、2022 年 M2 MacBook 64GB を前提に最短 30 分で再現する 5 ステップを示す。

Step 1: LM Studio インストール & Gemma 4 12b-qat ダウンロード

# 1. LM Studio をダウンロード (macOS / Windows / Linux)
# https://lmstudio.ai/

# 2. LM Studio の Search タブで "gemma-4-12b-qat" を検索
#    Apple Silicon (M1/M2/M3) の場合は MLX 版が高速、なければ GGUF Q4_K_M を選択
#    Q4_K_M = ダウンロードサイズ ~8GB、メモリ使用 ~10GB

# 3. Developer タブで Gemma 4 12b-qat を選択 → Start Server
#    デフォルトで http://localhost:1234/v1 が OpenAI 互換 API として公開される

Step 2: Pi インストール & モデル設定

# Pi をグローバルインストール
npm install -g @earendil-works/pi-coding-agent
# または公式インストーラ
curl -fsSL https://pi.dev/install.sh | sh

# 設定ディレクトリ作成
mkdir -p ~/.pi/agent

# モデル設定 (Pi はこの JSON を見てローカルモデルと対話)
cat > ~/.pi/agent/models.json <<'EOF'
{
  "providers": {
    "lmstudio": {
      "baseUrl": "http://localhost:1234/v1",
      "api": "openai-completions",
      "apiKey": "not-needed",
      "models": [
        {
          "id": "google/gemma-4-12b-qat",
          "input": ["text", "image"]
        }
      ]
    }
  }
}
EOF

# 動作確認
pi --model google/gemma-4-12b-qat -p "hello"

baseUrl は LM Studio の場合 http://localhost:1234/v1Docker 内で Pi を起動する場合は http://host.docker.internal:1234/v1 に書き換える (後述 Step 4)。

Step 3: コンテキストサイズと GPU オフロードの調整

LM Studio の Developer タブで、Context Size を 128K (VRAM が許す最大) に設定する。Pi はセッションが深くなるほどコンテキストを消費するため、64K では長いセッションで /compact を連発することになる。Patrick Loeber の 解説 によると、コンテキスト 128K + 26B-A4B の MoE モデルで追加 ~8GB VRAM を消費する。12b-qat の場合はモデル自体が ~8GB なので、合計 ~16GB ── M2 64GB マシンなら余裕で収まる。

ユースケース 推奨 Context 追加 VRAM (12b-qat)
単一ファイル編集 16K ~0.5GB
標準コーディングセッション 64K ~2GB
複数ファイル refactor 128K (推奨) ~4GB
リポジトリ全体 256K ~8GB

GPU Offload は M2 の場合 「最大 (30 layers)」 を維持。OOM が出る場合は Context Size を先に減らす。

Step 4: Docker サンドボックス起動スクリプト

Boykis 記事から ほぼ verbatim で引用する (出典明記、MIT 相当ライセンス下で記事本体からのコピーを許可)。

# docker-compose.yml
services:
  pi:
    build:
      context: .
      dockerfile: Dockerfile
    image: pi-agent:0.74.0
    init: true
    stdin_open: true
    tty: true
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      ANTHROPIC_API_KEY: ${ANTHROPIC_API_KEY:-}
      OPENAI_API_KEY: ${OPENAI_API_KEY:-not-needed}
      GEMINI_API_KEY: ${GEMINI_API_KEY:-}
      OPENAI_API_BASE: ${OPENAI_API_BASE:-http://host.docker.internal:1234/v1}
    volumes:
      - ${HOME}/.pi/agent/models.json:/config/models.json
      - ${WORKSPACE:-.}:/workspace
      - pi-config:/config
      - pi-sessions:/sessions
    working_dir: /workspace

volumes:
  pi-config:
  pi-sessions:
#!/usr/bin/env bash
# pi-up.sh ── Docker 内で Pi を起動する wrapper
SCRIPT_DIR="$(cd -- "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
WORKSPACE_DIR="${WORKSPACE:-$(pwd)}"

case "$WORKSPACE_DIR" in
  /*) ;;
  *) WORKSPACE_DIR="$(cd -- "$WORKSPACE_DIR" && pwd)" ;;
esac

export WORKSPACE="$WORKSPACE_DIR"
sandbox="${PI_SANDBOX:-0}"
pi_args=()

while (($#)); do
  case "$1" in
    --sandbox) sandbox=1 ;;
    --no-sandbox) sandbox=0 ;;
    *) pi_args+=("$1") ;;
  esac
  shift
done

compose_files=( -f "$SCRIPT_DIR/docker-compose.yml" )
if [[ "$sandbox" == "1" ]]; then
  compose_files+=( -f "$SCRIPT_DIR/docker-compose.sandbox.yml" )
fi

cmd=(
  docker compose
  --project-directory "$SCRIPT_DIR"
  "${compose_files[@]}"
  run --rm pi
)

if ((${#pi_args[@]})); then
  cmd+=("${pi_args[@]}")
fi

exec "${cmd[@]}"

起動コマンド:

# 作業ディレクトリ指定で Pi を起動
WORKSPACE=~/code/my-project ./pi-up.sh
# または --sandbox 付きで起動 (bash-only 制限 + curl すら不可)
WORKSPACE=~/code/my-project ./pi-up.sh --sandbox

Step 5: セッション管理とコンテキスト節約

Patrick Loeber が強調する Pi の 4 つのセッション管理コマンド を覚えておく。

コマンド 機能 使うタイミング
/compact 古いメッセージを要約してコンテキスト解放 128K の 80% 消費時
/new 完全新規セッション 別タスクに切り替える時
/tree セッション履歴をツリー表示 過去の分岐に戻る時
/fork 過去メッセージから新セッション分岐 別案を試したい時

12b-qat のコンテキストは有限 (実質 100K 弱が実用限界) なので、1 つのセッションは 30 ターン以内 に収めるのが運用の目安。/compact を恐れず使う ── この割り切りがローカル LLM 時代の「セッション衛生管理」だ。

4. 「75%」の正体を分解する ── Boykis の体感ベンチマーク

Boykis は 5 つのタスクで「API クロスチェックの頻度が激減した」と報告している。彼女の vickiboykis.com 記事 から具体例を抽出する。

タスク 12b-qat の成功率 (Boykis 体感) 残 25% で何が足りないか
Python notebook → 5-6 module refactor ◎ (~90%) 複数ファイル跨ぎでの import 整理が稀に抜ける
型ヒント PEP 0585 lint 修正 ◎ (~95%) TypeAlias まで踏み込むと不正確
ブログ記事校正 ○ (~75%) 日本語の敬語レベル調整は依然弱い
ユニットテスト生成 ○ (~80%) mock の境界条件でエッジケース漏れ
Two-Tower 推薦モデル bootstrap △ (~60%) データ前処理の型推論で躓く

この表が示す構造は、Zenn konto 氏の「ローカル LLM コーディングエージェント挫折記事」 (4 月時点、Mac mini で全モデル失敗) と Pi クラッシュコース「12B クラスなら 75% が現実解」 のちょうど中間に位置する。2 ヶ月で何が起きたかというと、

  1. Gemma 4 リリース (6/3) で function calling ネイティブ対応 が入った
  2. QAT 量子化 (12b-qat) で 4bit 化時の精度劣化が体感なくなった
  3. Pi 0.74.x (6 月) で OpenAI 互換 API の streaming / function call が安定

この 3 条件が揃った瞬間に「12B クラスで agentic loop が 75% で回る」閾値を超えた ── というのが Boykis 記事の核心であり、6 月の記事 (Boykis) と 4 月の記事 (konto 氏) の 2 ヶ月の進化 を反映している。

5. 日本企業 3 セクター業務シナリオ ── Open-Weight Frontier ハブとの接続

6/16 Open-Weight Frontier 日本企業ハブ では Nemotron 3 Ultra / Gemma 4 12B / Command A+ / DiffusionGemma / GLM 5.2 / MiMo Code の 6 モデルを 5 軸比較で整理し、金融 / 医療 / 公共 の 3 セクター実装コードを提示した。本稿はその 「agentic harness セットアップ」軸 で補完する ── 同じ 3 セクターに対し、「どのタスクをローカル Pi に任せるか」 の判断基準を明示する。

5.1 金融セクター (証券 / 銀行 / 保険)

業務 クラウド (Claude Fable 5 / Opus 4.8) ローカル (Pi + Gemma 4 12b-qat)
与信判断の説明文書生成 ◎ (規制準拠レビュー必須)
財務諸表 refactor ツール化 ◎ (定型的な pandas 変換)
コンプライアンスチェックリスト生成 ○ (1 次ドラフトはローカル、最終確認は API)
API ドキュメント → OpenAPI 変換 ✗ (型推論で躓く) ◎ (Gemma 4 12B の得意領域)
規制文書の和訳 ◎ (金融庁ガイドラインの微妙な表現)

結論: 与信判断と規制文書和訳は Opus 4.8、財務ツール化と OpenAPI 変換はローカル Pi。

5.2 医療セクター (病院 / 診療所 / 製薬)

業務 クラウド ローカル
診療録の SOAP 形式要約 ◎ (患者情報 → クラウド禁止の場合 ✗) ◎ (Gemma 4 12B + Apple Silicon)
処方チェック (相互作用確認) ◎ (最新 DB 同期) ✗ (学習データ古く危険)
学会発表スライドのドラフト ◎ (Markdown → reveal.js 変換)
電子カルテの bash 集計スクリプト ✗ (スクリプト生成は Pi 得意) ◎ (定型 ETL)
EBM 検索 (PubMed 連動) ✗ (外部 API 必須)

結論: 患者情報に触れる処理は原則ローカル、DB 連動は API。

5.3 公共セクター (中央省庁 / 自治体 / 公的機関)

業務 クラウド ローカル
政策文書ドラフト (パブコメ用) ◎ (長文生成) △ (200K コンテキスト必要)
予算要求書の定型フォーム埋め ◎ (Pi の得意領域)
統計データ可視化スクリプト ✗ (Pi の方が速い)
住民向け案内文の多言語翻訳 ◎ (公的文書は最終人手) △ (ローカル 1 次翻訳 → API 校閲)
機微データの前処理 ✗ (Fable 5 BIS 規制 + Bedrock 30日保持) ◎ (Gemma 4 12B なら規制対象外)

結論: 6/12 Fable 5 BIS 規制 + 6/13 Bedrock データ保持強制以降、機微データ前処理は構造的にローカル必須

3 セクター共通で、「クライアント側サンドボックス + コード自動生成」という仕事の 7 割が Pi + Gemma 4 12b-qat で代替可能 ── これが Boykis の 75% テーゼを日本企業コンテキストに翻訳した結論だ。

6. M シリーズ HW クラス別セットアップ早見表

Apple Silicon のユニファイドメモリは 「モデルのサイズ = 利用可能 RAM から他プロセスを引いた残り」 で決まる。Boykis の M2 64GB 構成は日本円で約 35 万円 (2026 年 6 月中古市場) ── 日本のエンジニアが現実的に購入できる上限に近い。

HW クラス 推奨モデル 量子化 期待速度 業務範囲
M1 / M2 16GB (MacBook Air) Gemma 4 E4B (Q4_K_M) 4GB ~20 tok/s ブログ校正 / 単一ファイル編集
M2 / M3 24GB (MacBook Pro) Gemma 4 12b-qat (Q4_K_M) 8GB ~35 tok/s 中規模 refactor / テスト生成
M2 / M3 / M4 64GB (MacBook Pro) Gemma 4 12b-qat (Q4_K_M) + 12b-qat assistant 8GB + 8GB ~55 tok/s Boykis 構成 / リポジトリ全体
M2 Ultra / M3 Ultra 192GB (Mac Studio) Gemma 4 26B-A4B (Q8_0) + Nemotron 3 Nano 28GB + 8GB ~40 tok/s 70B+ クラスも視野
M4 Pro / M4 Max 48GB (Mac mini / MacBook Pro) Gemma 4 12b-qat (Q6_K) 12GB ~45 tok/s 速度と品質のバランス型

日本市場特有の状況: 当ブログ 6/16 Open-Weight Frontier ハブ で触れた IDC Japan の「2027 年推論元年」フレームワークによれば、78% の日本企業はまだ PoC 段階。Pi + Gemma 4 12b-qat + M2 64GB の組み合わせは、「PoC 段階の 22% 企業」を「本格活用」段階に引き上げるための現実的なエントリポイントとなる。

7. 「Opus 4.5 クラスがローカルに来たら世界がひっくり返る」 ── Hashimoto テーゼの妥当性

Boykis の 75% テーゼと Hashimoto の「100% が来たら逆転」テーゼを統合する視点は、6/13 Fable 5 輸出管理事件 (6/14 解説) と 6/13 AWS Bedrock 30 日データ保持強制 (解説) 以降、さらに重みを増した。

3 つのシナリオを考える。

シナリオ A: Opus 4.5 クラスが 2027 年 Q1 にローカル化される。 GLM 5.2 が 1M コンテキスト + BrowseComp 62.0 で Opus 4.5 を一部逆転 (6/15 解説) した。MIT ウェイトが 6 月第 3 週に公開される予定で、Mac Studio 192GB ユーザは即座にホスト可能。Z.ai 路線で Q2 までに 70B+ Opus 級が MIT で降ってくる可能性は十分ある

シナリオ B: Fable 5 BIS 規制と Bedrock データ保持が「事実上の Open-Weight シフト」を加速する。 日本企業の「Fable 5 を使いたくても使えない」状態が継続する中、「ローカル Pi で 75% を確保 + 残 25% を API で補完」というハイブリッド構成が、6/12-13 以前の「Fable 5 一択」を構造的に過去のものにする。Boykis の 75% テーゼは、この構造変化の中で 「十分 (good enough)」 の閾値をすでに超えている。

シナリオ C: 75% のまま停滞し、エンタープライズ AI の 2 層化が固定化する。 2 ヶ月前の konto 氏の挫折記事 で見られた「12B クラスは agentic loop が破綻する」状態が続き、フロンティアが必要な業務は API / 定型業務はローカル の棲み分けが 2027 年まで固定化する可能性。これ自体は悪いシナリオではなく、6/8 AI コスト破綻の完全地図 が示す「トークン経済の崖」回避の現実解となる。

結論: いずれのシナリオでも「ローカル Pi + Gemma 4 + LM Studio」構成は 2026 年後半の標準装備となる。 この 1,500 ドル未満の投資で得られる「データ主権 + コスト半減 + agentic loop」は、Hashimoto が言う「5,000 ドルの Opus 級マシン」が出る前の 1 年間を埋める現実解として、日本企業にも十分な価値がある。

8. 5 ステップ実装チェックリスト ── 今すぐ始める人へ

# タスク 必要時間 費用
1 LM Studio インストール + Gemma 4 12b-qat ダウンロード 30 分 (8GB) 無料
2 Pi インストール + models.json 設定 10 分 無料
3 docker-compose.yml 配置 + 起動スクリプト準備 30 分 無料
4 既存リポジトリ 1 つで Pi を WORKSPACE=./repo ./pi-up.sh で起動 5 分 無料
5 5 タスク (refactor / test / type hint / lint / bootstrap) を Pi に投げ、成功率を計測 1 週間 無料

最初の 1 週間で「12b-qat の 75% テーゼが自分の業務でどこまで通用するか」を計測する。通用した範囲 = ローカルに移行可能な業務通用しなかった範囲 = API 継続 ── この線引きが、6/5 Uber $1,500/月 cap のような「エンジニア 1 人あたり年 $36K」の AI 予算を半分以下にする最初の一手となる。

3 ヶ月以内に元が取れる計算: エンジニア 1 人あたり月 $200 (Pi ローカル 0 + Pi が代替する API 利用 $200) × 12 ヶ月 = 年 $2,400 / 人 = ¥360,000 / 人。M2 64GB MacBook (中古 ¥35 万) はエンジニア 1 人で 約 1 年で回収。5 人チームなら 1 年で ¥180 万の API コスト削減 ── 中小規模チームの自己防衛策である。

9. まとめ ── 2026 年 6 月の「ローカル LLM コーディング」の現実解

Vicki Boykis の 75% テーゼを、Patrick Loeber のセットアップ手順と 6/13 MiMo Code ハーネス解説6/16 Open-Weight Frontier 日本企業ハブ で補完し、「Gemma 4 12b-qat + Pi + LM Studio + Docker (bash-only)」 の 4 層スタックが、2026 年 6 月時点で 5 年モノ MacBook で再現可能 であることを確認した。

重要な含意は 3 つ。

  1. 「API キー不要・データ外出し不要」の agentic coding が個人エンジニアの手元に届く時代になった。これは 6/12 Fable 5 BIS 規制 + 6/13 AWS Bedrock 30 日保持強制以降、機微データを扱う日本企業にとって構造的に必須構成となる。
  2. Pi の「minimalist 4-tool 哲学」 は、MiMo Code の「maximalist harness」 と対比される。両者は 「ハーネス > モデル」テーゼの 2 つの解 であり、12B-30B クラスのローカル LLM 時代は Pi、100B+ クラスの API 時代は MiMo Code という棲み分けが 2026 年後半の標準となる。
  3. Boykis の「12b-qat 75% テーゼ」は、Hashimoto の「Opus 4.5 クラス 100% テーゼ」を否定しない。両者は 「異なる目的関数に対する局所最適解」 であり、「2026 年は 75% で十分、2027 年は 100% を狙う」 というロードマップを日本企業も描ける段階に入った。

来週月曜 (6/22-23) には Fable 5 / Mythos 5 の Claude Code 課切替 + エンタープライズ ZDR 終了 が控える (6/13 Bedrock 記事)。「課切替後にローカルの 75% で代替する業務範囲」 を本稿のチェックリストで 1 週間以内に計測しておくことが、Fable 5 サブスク更新判断 (6/15 Agent SDK 分離解説) における最も確実な保険となる。


出典・参考リンク

一次ソース:

当ブログ関連 (本稿の議論接続先):


この記事は AI によって生成され、人間の編集を経て公開されています。Appwright AI は AI によるコンテンツ制作の可能性を探求する実験的プロジェクトです。