ローカルLLMを何本も動かしていると、モデルごとに最適な設定がバラバラになりがちです。フルスタックエンジニアのMike Key氏（@1337hero）は2026年6月27日、Claude Code向けの新スキルを「近日公開する」とXで予告しました。マシン上の全LLMを、エージェント型コーディング向けか速度向けかに体系的に調整する内容です。
この記事では、予告の要点と、公開前から読み取れる背景、既存の関連ツールまでを整理します。
この記事でわかること
- Mike Key氏が予告した新スキルの目的と範囲
- エージェント型コーディング向けと速度向けの調整がなぜ別物になるか
- 公開前から確認できる既存プロジェクト（claude-toolkit、LocalMaxxing）との関係
- Claude Codeスキルの仕組みと、導入時に押さえるポイント
https://github.com/1337hero/claude-toolkit
予告されたスキルは何をするのか
Mike Key氏の投稿原文は次のとおりです。
I built a skill I’m going to share shortly to have Claude systematically tune every LLM model on my machine for agentic coding or speed.
要するに、Claude Code上のClaudeが、ローカルに置いたLLMを1本ずつ見て、用途に応じた設定へ寄せていくスキルです。対象は「マシン上のすべてのモデル」で、調整の軸は「エージェント型コーディング」と「速度」の2系統に分かれます。
エージェント型コーディングとは、ファイル読み書きやシェル実行などのツールを繰り返し呼び出しながらコードを進める方式です。Claude Code自体がこの形で動きます。速度重視の設定は、短い応答や単発の質問を素早く返す場面向けです。1つのモデルに万能設定を載せるより、用途ごとに分ける発想が予告の中心です。
スキル本体はまだ公開されていません。「share shortly（近日共有）」とある段階のため、具体的なコマンド名や設定ファイルの書き方は、公開後にclaude-toolkitリポジトリで確認する形になります。
なぜ「エージェント向け」と「速度向け」は分けるのか
ローカルLLMの運用では、同じハードウェアでも目的によって変えるべきパラメータが違います。
エージェント型コーディングでは、ツール呼び出しの形式を安定させること、コンテキスト長を確保すること、推論の一貫性を保つことが重視されます。ツール形式が崩れると、エージェントは同じ操作を何度もやり直し、体感速度は落ちます。一方、速度重視の設定では、コンテキスト長や量子化、バッチサイズを絞り、トークン生成速度（tok/s）や初回応答までの時間（TTFT）を優先します。
Mike Key氏が既に公開しているLocalMaxxing連携スキル（localmaxxing）では、同じモデルでも-fastや-specといった別名で、engineFlagsやcommandSnippetを変えた複数バリアントを扱っています。例として、Qwen3-Coder-30B系はQwen/Qwen3-Coder-30B-A3B-Instructを共通のhfIdにしつつ、通常版・fast版・rocm版で設定を分けています。新スキルは、この「モデルごと・用途ごとの設定管理」をClaudeに任せる方向性と読めます。
公開前から見えるMike Key氏のローカルLLM基盤
新スキル単体の詳細は未公開ですが、作者の既存公開物から運用の輪郭は追えます。
LocalMaxxingは、ローカルLLMのベンチマーク（tok/s、TTFT、VRAM使用量など）と品質評価（evalスイート）を集める公開リーダーボードです。claude-toolkit内のlocalmaxxingスキルは、このAPIへベンチマーク結果や評価スコアを送る手順をまとめたものです。ベンチマーク送信前にdry-runで検証し、実測値とハードウェア情報をセットで登録する流れになっています。
作者プロフィールによると、自宅環境はArch Linux上で3枚のAMD Radeon AI Pro R9700（合計96GB VRAM）を使い、llama-swap経由でOpenAI互換エンドポイントを公開しています。エンジンはGGUF向けにllama.cpp（Vulkan）、MXFP4向けにvLLMといった使い分けです。Apple SiliconのM1 Maxマシンも比較用に持ち、Metalバックエンドでの計測スクリプトを別途用意しています。
この規模のマルチモデル環境では、手作業での設定調整はすぐに限界が来ます。新スキルが「every LLM model on my machine」と明言している背景には、こうした運用負荷への対処があると考えられます。
Claude Codeスキルとして何が変わるか
Claude Codeのスキルは、.claude/skills/配下のSKILL.mdに手順を書き、Claudeが必要時に読み込む仕組みです（公式ドキュメント）。CLAUDE.mdと違い、使うまで本文がコンテキストに載らないため、長いチューニング手順を常時読み込ませずに済みます。
claude-toolkitには、すでに20以上のスキルが含まれています。コーディング品質、フロントエンド規約、ブラウザ操作、メモリ圧縮（caveman）など、領域ごとに手順が分かれています。localmaxxingはその中の「計測と登録」担当で、今回予告されたスキルは「計測結果を踏まえた設定調整の自動化」に役割が広がる位置づけです。
スキルはスラッシュコマンド（/skill-name）で直接呼べます。説明文（description）に合致する依頼をすると、Claudeが自律的にスキルを選ぶ動きもします。新スキルが公開されれば、複数モデルの棚卸しと調整を会話ベースで回せる可能性があります。
公開後に確認すべきポイント
スキルがclaude-toolkitに追加されたら、次の点を最初に見るとよいです。
まず、対象エンジンとモデル一覧の取得方法です。llama-swapのエイリアスとHugging FaceのhfIdの対応表は、localmaxxingスキルに既に記載があります。新スキルがこれを再利用するか、別形式で持つかで運用のしやすさが変わります。
次に、「agentic coding」と「speed」の判定基準です。ベンチマーク指標（tok/s、TTFT）だけで分けるのか、evalスイートのスコアも見るのかは、公開版の手順を見ないと確定しません。LocalMaxxingではベンチマークと評価が別レーンで管理されているため、両方を参照する設計が自然です。
最後に、設定変更の適用範囲です。engineFlagsや量子化、コンテキスト長の変更は、再起動やモデルの入れ替えを伴うことが多いです。スキルがdry-runやベンチマーク再計測まで含むかどうかも、実用性の分かれ目になります。
ローカルLLM運用者への意味
複数モデルを常時立ち上げている開発者にとって、設定の属人化は典型的なボトルネックです。どのモデルをエージェント作業に回し、どれを軽量タスクに回すかを毎回手で決めるのは、モデル数に比例して負担が増えます。
Mike Key氏の予告は、Claude Codeのスキル機構を使ってその判断と調整を手順化する試みです。詳細は公開待ちですが、既存のclaude-toolkitとLocalMaxxingが計測基盤をすでに持っている点から、感覚ではなく数値に基づくチューニングを自動化する方向性は明確です。
公開はXアカウント@1337heroとclaude-toolkitの更新を追うのが確実です。ローカルLLMをClaude Codeと組み合わせて使っている場合、今のうちに計測環境を整えておくと、スキル公開後すぐ試せます。