Claude Codeのスキルは、人が書いて人が整理するのが前提だった。autoharness（tigerless-labs/autoharness・★10.9k・MIT）は、その手入れを自動化すると掲げる第三者製のプラグインだ。実セッションからスキルを学習し、同種を1つに統合し、使われなくなったものを剪定する。「スキル層を自分で保つ」という発想である。本記事では★数・ライセンス・版をソースまで実測し、仕組みと「未検証の範囲」を切り分けて、autoharnessが何をするツールなのかを宣伝抜きで整理する。

WHAT IT REPLACES何を代替するか

スキルの手入れを誰がやるか

これまで

人が書いて人が整理

  • 学びは毎回流れて消える
  • 似たスキルが積み上がる
  • 使われない定義が残る

autoharness

実セッションから自動学習

  • 作業から自動で抽出
  • 同種はマージして1つに
  • 使われねば剪定
出典: README（2026-10-28時点）

30秒でわかるautoharness（2026-10-28時点）

  • ・正体：Claude Code向けの「自己学習スキル層」プラグイン（第三者製・Tigerless Labs）。フック＋MCPサーバー＋/learnで動く
  • ・何ができる：実セッションからスキルを学習・統合・剪定し、.claude/skills/へネイティブ形式で書き込む
  • ・実測：★10.9k／MIT／Python 3.11+・依存ゼロ。版はplugin.jsonでv0.5.3（後述の未検証範囲あり）
  • ・注意：効果の主張の多くはREADME基準。実環境での動作は本記事では未検証

Claude Codeそのものの導入・設定・運用はClaude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きにまとめている。本記事はその拡張エコシステムの1つとしてautoharnessを扱う。

autoharnessとは何をするプラグインか

autoharnessは、Claude Codeのスキル（Claude Skills）の層を自動で維持することを目的にした外部プラグインだ。スキルは従来、人がSKILL.mdを書き、増えたら人が整理する。autoharnessはこの「書く・まとめる・捨てる」を、実際の作業セッションを材料にして回そうとする。

読者の3つの問いに沿って整理すると、こうなる。

何ができるか：会話を記録し、使えそうな教訓をスキルとして抽出・更新する。同じ場面のスキルは積み増さずに統合する。使われないものは剪定する。何を解決するか：スキルが散らかる・重複する・腐る問題を、手作業から外す。何を代替するか：人手によるスキルの棚卸しを、使用実績に基づく自動整理に置き換える、とREADMEは主張する。ここは効果の裏取りができていないため、主張として読むべき点だ。

実測した基本情報は次のとおり。★10.9k・fork 629（GitHubのページ表示、2026-10-28時点）。ライセンスはLICENSE実体がMIT。Python 3.11+で動き、サードパーティ依存はゼロ。対応はLinuxとmacOS。既定ブランチmainは同日もコミットが入る活発な状態だった。版は.claude-plugin/plugin.jsonのversionがv0.5.3で、READMEのreleaseバッジもこの値を読む。一方でGitHubのリリースタグはv0.2.5までしか無く、両者に差がある。導入時に実際に入るのはplugin.jsonの版である点に注意したい。

仕組み：捕捉・反省・検証・索引

autoharnessは、ホスト（Claude Code）の隣で学習パイプラインを回す。スキル自体は独自形式ではなく、人が書いたのと同じネイティブのSKILL.mdとして.claude/skills/に置かれ、ホスト本来の名前と説明による想起はそのまま使う。その上に、セッション冒頭で「autoharnessが書いたスキルの索引」を注入する。

HOW IT WORKSホストの隣で学ぶ

セッションを捕捉し、提案を検証して着地させる

  1. 捕捉 CAP

    ツール呼び出しを数える

  2. 反省 REF

    追加/統合/修正を提案

  3. 検証 promoter

    唯一の書き手

  4. .claude/skills

    ネイティブ形式で着地

  5. 次回 索引

    冒頭に一覧を注入

出典: README「How it works」（2026-10-28時点）

流れはフックで起動する。hooks.jsonはSessionStart／Stop／PreToolUse／SessionEndの4つを同じディスパッチャに繋ぐ。捕捉（CAP）は各ターンの入出力を記録し、持ち出し時にマスキングする。学習の引き金は内容の良し悪しではなく、ツール呼び出しの回数だ（既定AUTOHARNESS_REFLECT_EVERY_N=50。この値を超えたターンの終わりに背後で反省が走る）。反省（REF）はその場面を既存スキルの索引と突き合わせ、追加・統合・修正・削除のいずれかを提案する。検証役のpromoterは、autoharnessのなかで唯一ディスクに書き込む存在だ。安全性や構造、ledgerの整合を点検し、通ったものだけをアトミックな改名で着地させる。

この「提案と書き込みの分離」はソースでも確認できた。reflectorエージェントの定義はtools: Read, Grep, Glob, mcp__plugin_autoharness_stage_skill__stage_skillで、Write・Edit・Bashを持たない。書き込みはpromoter.pyに集約され、検証に通らない提案はディスクに残らない。提案の受け口はstage_skillというMCPサーバーで、プラグイン名前空間ではmcp__plugin_autoharness_stage_skill__stage_skillという完全修飾名になる。

「学習」と「剪定」をどう判断するか

autoharnessの中心は「何を残すか」の判断だ。READMEは3つの信号を区別する。load（モデルがスキルを実際に呼んだ）だけが生存率の分母を動かし、view（ディレクトリを読んだ）は想起価値の証拠だが遵守ではなく、patch（改善が着地した）はその後のloadを「改善後の再利用」として読む。browseされただけのスキルが、従われたスキルに見えないようにする仕切りだ。

剪定は時計ではなく機会で決まる。新しいスキルはまず試用期間に入り、一定数のリクエストが来るまでは想起されても淘汰されない（既定AUTOHARNESS_MATURITY_PROJECT=100）。卒業審査で消えるのは「loadもviewも一度も無かった」ものだけ。成熟後は容量超過だけが死因で、プロジェクト層の上限（既定AUTOHARNESS_CAPACITY_PROJECT=50）を超えたときに使用率の低い順から外れる。しかも削除ではなくアーカイブで、フォルダを戻せば履歴ごと復活する。ライブラリ全体を見渡して近い重複を1つに畳むのは、より稀に走るcuratorの仕事だ。1スキルごとの来歴は.ledger.jsonlに追記で残り、根拠となった会話の断片もreferences/に保存される。

設計の前提

  • ・対象はautoharnessが生成したスキルだけ。ledgerマーカーの無い手書き・インストール済みのスキルは触らないとREADMEは説明する
  • ・既定のしきい値は「暫定の目安（placeholder）」と明記されており、実運用での最適値は未確定

ベンチマークの数字をどう読むか

READMEの冒頭には「Same model, different harness — 42% → 78% on CORE-Bench」という一文がある。ここは誤読されやすいので、はっきり分けて書く。この42%→78%は、autoharnessが出したスコアではない。 HAL（Holistic Agent Leaderboard、arXiv:2510.11977）が示す数値を、「同じモデルでもハーネスが違えば成績が変わる」という一般論の例として引いたものだ。続けてswyxの「Big Model vs Big Harness」を援用し、ハーネスが成果の多くを担うのに毎世代手で作り直されている。その一部であるスキル層を自己維持できないか、というのがautoharnessの賭けだと述べている。

autoharness自身は、保持したスキルを「ベンチの点数」ではなく「その後のセッションでどれだけ従われたか（adherence）」で評価する設計を取る。つまりCORE-Benchの数字は背景の文脈であって、autoharnessの効果を示す実測値ではない。本記事の計測でも、この改善幅をautoharnessの成果として扱える根拠は見つからなかった。導入効果を判断するなら、READMEの看板数値ではなく、自分の.claude/skills/と.ledger.jsonlに何が残ったかを見るのが筋だ。

導入と設定（実測の範囲）

導入はClaude Codeの入力欄にスラッシュコマンドを打つ。マーケットプレイスを追加し、プラグインを入れ、再読み込みする、という手順だとREADMEは示す。

/plugin marketplace add tigerless-labs/autoharness
/plugin install autoharness@autoharness
/reload-plugins

導入後は設定ゼロで動き、学習したスキルを背後で.claude/skills/に書くとされる。速度や寿命のしきい値はAUTOHARNESS_*環境変数で変えられ、AUTOHARNESS_INDEX_SUSPENDED=1で索引注入だけを止める、AUTOHARNESS_DISABLE_GLOBAL=1でプロジェクト層に限定する、といった切り分けもできる。/learnはその場のセッションを今すぐ蒸留する手動の入口で、背後の自動反省と同じ検証経路を通る。

ここが本記事の限界だ。上のコマンドはClaude Codeの内部コマンドで、通常のシェルからは実行できない。プラグインの実動作（フックの発火、反省の生成、スキルの着地、剪定の判定）は、Claude Codeランタイム上でしか再現できないため、本記事では未検証とする。確認できたのは、リポジトリの構成・ライセンス・版・コンポーネントの実体ファイルと、提案と書き込みが分離されているという設計上の事実までだ。効果そのものを測ってはいない。

類似ツールとの比較・採用判断

READMEは3つの方式と自身を並べている。要点だけ表に落とすと、分かれ目は「何で淘汰を決めるか」と「常駐が要るか」だ。

観点 無制限に増やす オフライン採点で自己編集 タイマー＋常駐 autoharness
スキル層に上限 なし あり あり あり
生存の判断材料 なし ベンチの点数 経過時間・放置 使用実績（adherence）
学習の引き金 — オフラインの一括処理 アイドル時間 セッション内の作業
ベンチ／オラクルが要る 不要 必要 不要 不要
常駐プロセスが要る 不要 不要 必要 不要

TRADE-OFFS導入前に見る

自動で保つ利点と、文脈コスト・制御性の引き換え

得るもの

  • スキルの整理を自動化
  • 使用実績で生き残る設計
  • 自作スキルには触れない

払うもの

  • 毎セッション索引で文脈を消費
  • 挙動の予測が難しい
  • 既定値は暫定の目安

支点は「作業量が多く、同じ型を繰り返すか」

出典: README「Configuration」「How it works」（2026-10-28時点）

採否は好みではなくトレードオフで決まる。得るのはスキル整理の自動化と、使用実績で生き残る仕組み、そして自作スキルに触れない安全側の設計。払うのは、毎セッションの索引注入で消費する文脈と、挙動の予測しにくさ、そして「既定値は暫定」という未成熟さだ。作業量が多く、同じ型の問題を繰り返し解く使い方ほど効きやすい。逆に、スキルを厳密に自分で管理したい、あるいは文脈を1トークンでも惜しむ場面では、AUTOHARNESS_INDEX_SUSPENDEDで索引を止めるか、導入を見送る判断もある。スキルとCLAUDE.mdの設計そのものを詰めたい人は、Andrej Karpathyが語るスキルとCLAUDE.mdの指針やハーネスエンジニアリング入門も合わせて読むと位置づけがはっきりする。

まとめ

この記事の結論

  • ・向いている人：反復の多い作業でスキルが散らかりがちで、整理を自動に委ねたいClaude Codeユーザー。設計がソースまで追える点を評価できる人
  • ・待った方がよい人：効果の裏取りを重視する人（既定値は暫定・効果はadherence前提で未検証）、文脈コストや挙動の予測性を優先する人

autoharnessは「スキル層を自分で保つ」という発想を、提案と書き込みの分離・使用実績での淘汰・アーカイブ主義といった具体的な設計に落とし込んでいる。一方で、看板のベンチ数値は自身の成績ではなく、効果は本記事では未検証だ。導入するなら、READMEの主張ではなく手元の.claude/skills/と.ledger.jsonlで判断するのがよい。

参照ソース

・tigerless-labs/autoharness（公式リポジトリ） — README・LICENSE・hooks/hooks.json・agents/reflector.md・src/autoharness/（★数・MIT・コンポーネント実体を2026-10-28に確認）
・plugin.json（プラグインの版・MCPサーバー定義） — version v0.5.3・stage_skillサーバー（2026-10-28時点）
・HAL: Holistic Agent Leaderboard（arXiv:2510.11977） — READMEが引くCORE-Benchの数値の一次出典