階層型エージェント構成案の Phase 1。--parallel で同時に投げたとき、合計の生成速度が単発の何倍になるかを測る。 帯域律速のため N 倍にはならない見込みで、1.3 倍未満なら並列を諦めて逐次実行の構成に単純化する。

• 済--parallel 1 / 2 / 4 で同時リクエストを投げ、合計 tok/s と VRAM 使用量を測る（Qwen3-4B で 57 → 99 → 131 tok/s、8 本で 151 tok/s。VRAM は 3.7 GB のまま。tools\50_run\bench-parallel.cmd）
• 済結果を構成案に反映し、並列の採否を決める（4 本で 2.3 倍。判断は「並列に意味がある」）

関連: 階層型エージェント構成案

小さなドラフトモデルで先読みして生成を速める手法。本命とドラフトを同居させると VRAM の余裕は約 200 MiB と見積もっており、 帯域を使い切っている本PCでは効果が出ない可能性もある。

• 済使用中のビルドの llama-server --help で、ドラフトモデル指定のオプション名を確かめる（-md のほかに --spec-type draft-simple が要る。--draft-max は --spec-draft-n-max に替わった）
• 済本命と同系列のドラフトモデル（Qwen3-0.6B の GGUF）を取得する（unsloth の Q4_K_M・397 MB）
• 済調査の検証計画にある5構成を測り、結果を調査に反映する（どの構成も単体の 57 tok/s より遅く 29〜47 tok/s。見送る。tools\50_run\bench-spec.cmd）

関連: Speculative Decoding 調査

RAM を 32GB に増設し、画面表示を内蔵GPU に任せたところ、CPU 側に重みを置くモデルが大きく速くなった （Qwen3.5-9B 8.1 → 14.6 tok/s、gpt-oss-20b 5.9 → 19.0 tok/s）。KV を q8_0 にすればコンテキスト 16384 も使える。 実行計画の結論と方針は RAM 16GB の実測に基づいたままで、再測定と合わなくなっている。

• 済RAM と VRAM に左右されるものを 32GB で測り直し、実行計画・調査に追記する
• 済実行計画の結論と方針（gpt-oss-20b の位置づけ、コンテキストの上限）を見直す
• 済gemma-4-E4B を測り直す（CPU 側に置く PLE が速くなる可能性がある。生成は 45.23 → 46.87 tok/s でほぼ同じ、pp512 は 1149 → 1843 tok/s）
• 済Qwen3-30B-A3B を取得して測る（UD-Q4_K_XL・16.5 GB。Claude Code の読み書きの試験に合格。生成は -ncmoe 40 で 16.6 tok/s、39 以下は VRAM があふれて落ちる）
• 済Claude Code 用のモデルを gpt-oss-20b で試す（25 分でタイムアウト。10GB 未満の 13 本も試し、試験の経緯と全実行の記録に記録）

関連: ローカルLLM 実行計画（第10章の「32GB での再測定」）

Claude Code は共通ルールを読ませず思考を切れば、20GB 以下の 20 本中 15 本が 15 分以内に読み・書きの両方に合格した。 時間切れになったモデルは Pi・OpenCode・Aider でも試した。

• 済Claude Code（ルールなし・思考なし・テンプレート差し替え）で全モデルを試す
• 済時間切れの 3 本を Pi・OpenCode・Aider で試す
• 済時間切れだった問を 1 問 1 時間で試し直す（Qwen3-4B-Thinking の書きだけが約 20 分で合格）
• 済Codex CLI（ルールなし）で試す（gpt-oss-20b が両方合格。Windows では安全装置を外す必要がある）
• 済使える設定で cc1.cmd を作り直す（gemma-4-E4B・思考なし・ホーム W:\temp\cc1-home。読みの 1 問が 40 秒・2 ターンで正答）

関連: AI エージェント比較の検証計画／ローカルLLM で AI エージェントを使う — 試験結果

Pi は、Claude Code（ルールなし）で通らなかった 3 本でしか試していない。そのうち 2 本では Claude Code より良い結果だった。 Claude Code で速かったモデルを Pi でも試し、どちらを使うかを決める。

• 済gemma-4-E2B・gemma-4-E4B・gpt-oss-20b を Pi で試す（tools\50_run\test-agents.cmd -Agent pi。E4B と gpt-oss-20b は Claude Code の 2〜3 倍速く合格。E2B の読みは 3 回中 1 回だけ答えた）
• 済Claude Code の結果と比べ、試験結果の結論（どのエージェントを使うか）を見直す（Claude Code は推奨のまま、Pi を速さ重視に）

関連: ローカルLLM で AI エージェントを使う — 試験結果（第 3 章）

-ncmoe 40 で 16.6 tok/s 出たが、測ったのはプロンプトを入れない tg64 で、KV キャッシュはほぼ空だった。 39 以下では VRAM があふれて 7〜14 tok/s に落ちるため、コンテキストを使うと 40 でもあふれる可能性がある。

• 済実際に使うコンテキスト（例: 16384・65536）と KV の型（q8_0・-nkvo）で、-ncmoe を振って生成速度と VRAM を測る（深さ 16384・KV q8_0 で 40 は 0.35 tok/s、44 は 12.9 tok/s。-nkvo は 16384 で 4.4、65536 で 1.3 tok/s）
• 済結果を実行計画の「結論と方針（RAM 32GB）」の設定に反映する（16384 までは --n-cpu-moe 44、65536 は使えない）

関連: ローカルLLM 実行計画（第10章の「32GB での再測定」）

並列スロットは 4 本同時で 2.3 倍になったが、プロンプトは短い文 1 行で測った。 長い資料を渡すと読み込み（pp）が同時に走るため、倍率が変わる可能性がある。

• 済1 本あたり 1,000〜1,500 トークンのプロンプトで、--parallel 1 / 2 / 4 の合計 tok/s と所要時間を測る（tools\50_run\bench-parallel.cmd にプロンプトを渡す引数を足す。1,213 トークンで 47 → 74 → 90 tok/s）
• 済結果を構成案の Phase 1 に追記し、判断が変わるかを見る（4 本で 1.92 倍と基準の 2 倍の境目。サブに渡す量が決まってから判断する）

関連: 階層型エージェント構成案（第6章 Phase 1）

温度 0・同じ seed でも、ドラフトありの 4 構成はすべて単体と違う出力になった。仕組み上は一致するはずで、 まとめて検証するときの計算順の違いと推測しているが、確かめていない。採用は見送ったため急がない。

• 済どこから出力がずれるかを見る（先頭から何トークン目か。文章 224 文字目・コード 439 文字目で、どちらも候補が拮抗する単語）
• 済単体でも -ub・-b を変えると出力が変わるかを見て、計算順の違いで説明できるかを確かめる（-b ではなく同時に処理する本数を変えて確かめた。単体 5 本同時でもコードが同じ位置・同じ文言にずれ、ドラフト固有ではないと分かった）

関連: Speculative Decoding 調査（第5章の結果）

「1から10までの合計を表示するnode.jsプログラムをsum.jsに書く。node sumで実行する」を日本語のまま渡し、 書きの試験に 10 分以内で合格した 19 本を Claude Code・Pi・OpenCode・Aider で総当たりに試す。

• 済試験スクリプト 2 本の -Tests に sum・echo を足し、日本語が化けるとしたコメントを直す（判定は tools\50_run\sum-judge.ps1）
• 済確認用の 1 問（Pi・OpenCode・Aider に日本語が化けずに届くか）を流す（E4B で 4 エージェントとも化けずに往復した。sum も Claude Code・Pi・OpenCode は合格、Aider は書けたが実行も報告もしなかった）
• 済本番の 76 回を流す（合格は Claude Code 16・Pi 14・OpenCode 9・Aider 2 本。Claude Code は PowerShell の道具が加わっていた不具合を直して流し直した）
• 済結果を試験結果と全実行の記録に反映する（試験結果の第 4 章、全実行の記録の第 3 章）

関連: 初期プログラミングの検証計画

llama.cpp・エージェント・Node.js を最新にして、これまでの試験をやり直す。版が上がると結果が変わりうるため、閉域網へ持っていく前に、持っていく版で結果を取り直す。

• 済llama.cpp を b10612 から b11320（CUDA 12.4 版）にする。前の版は bin\llama.cpp-b10612 に残した
• 済Pi を 0.87.1 → 0.99.2、Codex CLI を 0.158.0 → 0.159.3、OpenCode を 1.18.33 → 1.18.34 にする（Claude Code 2.1.286・Aider 0.86.2 は最新のまま）。llama.cpp は日に何十もビルドが出るため b11320 で止める
• 済Node.js を v26.8.1 → v26.10.0 にする（利用者が msi を実行した。インストール先は C:\Tools\nodejs）
• 済試験スクリプトが結果ファイルに版を書き込むようにする
• 済画面表示の出力先を確かめる（内蔵 GPU が出していた。VRAM の空きは nvidia-smi で 3962 MiB で、前回の再測定と同じ。llama.cpp の --list-devices は CUDA から見た値で 3287 MiB と出るため、比べるときは同じ測り方にそろえる）
• 済E4B で 4 エージェントに日本語の確認と sum を流し、壊れていないことを確かめる（日本語は 4 つとも合格。sum は Claude Code・Pi・OpenCode が合格、Aider は実行したが結果を答えず、前回と同じ傾向）
• 済主な速度を llama-bench で新旧を交互に測る（pp512・tg64。Qwen3-4B・E4B・Qwen3-30B-A3B は誤差の範囲。gpt-oss-20b の pp512 だけ 138 → 128 tok/s と約 7% 遅い。記録は logs/bench-versions-20261001.txt）
• 済sum の残り 18 本 × 4 エージェントをやり直し、前の版と比べて資料に反映する（1 セット目は Claude Code 12/19・Pi 15/19。前回の 16・14 との差が揺れか版の影響かを見るため、tools/50_run/run-sum-sets.ps1 で 3 セット以上流す）
• 済3 セットの表を仕上げる（OpenCode の 3 セット目と Devstral を入れ、合格数を数え直し、サイズ順にしてモデルの横に x.xGB を書く。sum-table.ps1 -Sets で結果のファイルから作るようにした）
• 済実行の跡が無い合格を ☑️補欠合格 として表と判定（sum-table.ps1）に入れる（判定は sum-judge.ps1 の Get-SumMark・Format-SumCell。テスト 36 件）
• 済NVIDIA GPU で 10 分以内に終わった 55 組を、Intel GPU（Vulkan 版・30 分）と NVIDIA GPU（4 回目・10 分）で流し、10 分で ⏱️ があった 6 組を 40 分で流し直して、試験結果に書く（判定は標準出力だけで見るように直した。tools/50_run/run-sum-matrix.ps1）
• 済Aider に別の指示で実行させた結果と、CPU だけで流した結果を試験結果に書く（「Aider に別の指示で実行させた結果」「CPU で流した結果」「調査結果のまとめ」）
• 済時間切れの既定を、NVIDIA GPU 10 分・Intel GPU 15 分、名前に Thinking・Reasoning が入るモデルはその倍にする（run-sum-matrix.ps1・test-agents.ps1・test-cc-tools.ps1。決め方は試験結果の「これからの時間切れの決め方」。paths.ps1 の Get-LlmTimeout にまとめ、-TimeoutSec を渡せばそちらを使う。CPU 版は Intel GPU と同じ 15 分。テスト tests/paths.tests.ps1）
• 済読み書きの試験をやり直す（2026-10-05。前の版で両方合格の 16 本のうち 15 本が今回も合格。試験結果の「版を上げて流し直した結果」）

関連: 試験の経緯と全実行の記録（「試験した版」）

これまで LM Studio に向けていた接続先を、llama-server（127.0.0.1:8080）へ切り替える。 llama-server は Anthropic 形式の /v1/messages に直接応答するため、変換の層を挟まずに繋がる。

Claude Code は最初の要求だけで約 63,000 トークンある。VRAM 4GB には KV キャッシュが載らないため、 コンテキスト 65536・KV キャッシュを RAM 側（-nkvo）・q8_0 で起動する。 初回は 157 秒かかるが、2回目以降は共通部分が再利用されて 14 秒になる。

• 済llama-server が Anthropic 形式に直接応答することを確かめる
• 済サーバの起動（tools/50_run/run-server-cc.cmd）と Claude Code の起動（root の cc1.cmd）をスクリプトにする
• 済Claude Code から応答が返ることを確かめる

関連: ローカルLLM 実行計画（導入手順の Step 5）

共通ルールが改められ、コンソールのコードページを変えること（chcp・OutputEncoding・SetConsoleOutputCP 等）が禁止になった。 このリポジトリのスクリプトと資料に該当する記述がないかを調べる。

• 済追跡中の 35 ファイルを、cmd は SJIS・ほかは UTF-8 として読んで調べる。該当 0 件（ps1 は無く、cmd 7 本にも該当なし）

N: ドライブが廃止され、プロジェクトは W:、共有ツールは T: で参照することになった。 ソース・資料・設定に N: を書いている箇所がないかを調べ、あれば直す案を出す。

• 済追跡中の 35 ファイルを、cmd は SJIS・ほかは UTF-8 として読んで調べる。N: も W: も 0 件（パスはすべて %~dp0 からの相対指定か、PATH 上の名前で呼んでいる）。直す箇所はない

ネットに出られない別の PC（Intel の内蔵 GPU）で同じ試験を流せるように、モデル以外も含めて 1 つにまとめる。

• 済llama.cpp b11320 の Vulkan 版・CPU 版をそろえ、この PC の Intel GPU と CPU だけで sum を試す
• 済持っていく先の 3 台の構成と、現地の llama-bench の結果を集める
• 済Intel 第 11〜14 世代向けの GPU ドライバ（32.0.101.7092）を取る
• 済計画を書く
• 済試験スクリプトの場所を設定と引数で変えられるようにする
• 済zip 版 Node.js にエージェントを入れ、起動用の cmd を生成する
• 済配布物を組み立てるスクリプトを書き、別の場所に置いて 4 つのエージェントの試験が通ることを確かめる
• 済配布物を組み立て直す（2026-10-08。ポートの確認・窓を閉じたときの停止・Intel に載せる設定などを入れた。持ち込むものを、モデル以外の llm-bundle-20261008.7z（0.83 GB）・models（16.7 GB）・drivers（0.7 GB）の 3 つに分けた）
• 未ネットを切った状態で動くか、現地で確かめる（対話の cmd も使ってみる）
• 済Claude Code を社内の閉域網で使ってよいか、利用条件を確かめる（2026-10-06 決定: 会社の契約（Commercial Terms）のもとで、自己責任で使う。公式の Other LLM gateways は Claude 以外のモデルへのつなぎ方を「サポートしない」と書くが、禁止はしていない。公式の Legal and compliance では、npm 版もオープンソースではなく Anthropic の規約に従う。会社の契約があるので Commercial Terms が適用され、自社の利用者のために社内の環境へ入れて使うことは書きぶりから外れない。ローカルモデルだけ・閉域網での利用は書かれていない）

関連: 閉域網へ持っていく配布物

全体を見直して見つけた、start-agent.ps1・paths.ps1・make-offline-bundle.ps1 の弱いところ。現地でつまずく順に並べた。

• 済Claude Code の起動で CLAUDE_CODE_ATTRIBUTION_HEADER=0 を渡す（cc1.cmd は渡している。無いと遅くなるかを測ってから直す）（2026-10-06。E4B の読み書きを 2 回ずつ測った。切ると読み 37・35 秒、切らないと 380・36 秒で、10 倍遅い回があった。start-agent.ps1 と test-cc-tools.ps1 で切る。これまでの試験は、このセッションの .claude/settings.json から引き継いで切れていた）
• 済8080 番を別のプログラムが使っていても /health の確認が通ってしまう。起動前に空きを見て、使用中なら「使用中」と出して止める（paths.ps1 の Test-LlmPortFree。start-agent.ps1 は使用中なら使っているプログラム名を出して止める。テストは tests/paths.tests.ps1）
• 済ポートだけ ps1 を直さないと変えられない。config.cmd に LLM_PORT を足し、start-agent と試験のスクリプトの既定にする（現地で変えるのは config.cmd だけ、を保つ）（paths.ps1 の $LlmPort。start-agent.ps1・test-agents.ps1・test-cc-tools.ps1・test-aider-followup.ps1 は -Port を省くとこれを使う。配布物の config.cmd と使い方にも足した）
• 済cmd の窓を × で閉じると finally が走らず llama-server が残る。窓を閉じたとき・強制終了したときに、llama-server も一緒に止める（2026-10-06。① llama-server をエージェントと同じ窓で起動し、窓を閉じる知らせで一緒に終わらせる。A ジョブオブジェクトに入れ、PowerShell が終われば OS が止める。paths.ps1 の Add-LlmKillOnClose。実機で、窓を閉じたとき・PowerShell だけを強制終了したときのどちらも止まることを確かめた。テストは tests/paths.tests.ps1）
• 済3.2GB を超えるモデルに -ngl を付けないため、Vulkan でも 12B-QAT は CPU だけで動く。Vulkan のときは大きさに関わらず -ngl 99 にする（2026-10-06。この PC の 12B-QAT で、CPU 版はプロンプト 14.8・生成 3.8 tok/s、Intel に全部載せるとプロンプト 68.8・生成 3.4 tok/s。既定のままでは 49 層中 12 層が NVIDIA に、残りが CPU に載っていた。NVIDIA も見える PC では Intel だけを使う --device を付ける。paths.ps1 の Get-LlmGpuArgs）
• 済config.cmd を Encoding.Default で読むため、pwsh 7 では日本語のパスが化ける。CP932 と決めて読み、%USERPROFILE% などの %変数% も環境変数で展開する（paths.ps1 の Read-LlmConfig。テストは Windows PowerShell 5.1 と pwsh 7 の両方で流す）
• 済SHASUMS256.txt の取得に失敗したらその場で止める。npm の中に claude.exe が無ければ「置き場が変わった」と出す（make-offline-bundle.ps1。curl に -f を付けた。付けないと 404 でもエラーの HTML を保存して終了コード 0 になることを確かめた。取得に失敗したら途中のファイルを消して止める）
• 済配布物は約 20.4 GB で、12B-QAT は 1 ファイルで 4 GB を超える。運ぶ媒体が FAT32 なら書き込めないため、媒体と形式（exFAT・NTFS）を確かめる（利用者が確かめた。問題なし）

関連: 閉域網へ持っていく配布物

develop の内容を release・master へ取り込む。

• 未develop → release を --no-ff でマージする
• 未release → master を --no-ff でマージし、注釈付きタグを打つ

配布物には入らないが、開発用の PC の置き場を変えたときに取り残されるものと、確かめる手段が無いもの。

• 済モデルの置き場を現地と同じ C:\AI-models に改め、スクリプトと資料の C:\AI_Models をすべて書き換える
• 未start-agent・test-cc-tools と役目が重なる test-cc.ps1・run-server-*.cmd・bench.cmd を消し、資料に出てくる名前を書き換える（消す対象は作業のときに 1 つずつ示す）
• 未root の cc1.cmd は、いちばん使えそうな組み合わせを動かす入口として残す。start-agent を呼ぶ形に書き換え、サーバの起動から停止までを 1 本で済ませる（直接書いた W:\temp も無くなる）
• 未README と実行計画の「LM Studio と共用・移動しない」を、置き場を C:\AI-models に改めた今の形に直す
• 済tests/ を作り、sum-judge.ps1 の判定（✅・☑️・❌）をテストする。ランチャーは tools/40_test/（tests/sum-judge.tests.ps1 の 22 件。tools/40_test/run-tests.cmd で流す。表のマスを作る sum-table.ps1 の Format-Cell は、☑️ を入れるときにテストを足す）
• 済モデル置き場を整理する（2026-10-10。Ministral を Mistral にまとめ、フォルダ名を Hugging Face のリポジトリ名に大小まで揃えた。試験で使えなかった 6 本（Qwen2.5-Coder-14B・Muse-Glimmer-30B・Qwen3.8-27B・GLM-4.6V-Flash・Nemotron-3-Nano-4B・Qwen3-0.6B）と空のフォルダを消し、約 52 GB 空けた）
• 未どこにも書いていない bin/llama.cpp-b11302（1.1 GB）を消す（試験は b11320 で取り直した）
• 未tmp/ に残る 9/29 の試験の跡（agent-home・home-norules・sandbox）と、展開済みの llama.cpp の zip 2 本（0.6 GB）を全部消す