HARNESS ENGINEERING

Claude Code ハーネス運用の全体像

コードを書く側ではなく、「書かせる側」の品質管理。

手綱で結ばれた人とAIが同じ方向へ進むフラットイラスト

2026-07-14 実測値収録 / 正本: .claude/HARNESS.md

01このVaultは、AIに「書かせる側」の品質管理装置で動いています。

手綱なしで散らかすAIと、ハーネス装着で整然と成果を出すAIの対比イラスト
同じAIでも、ハーネスの有無で成果の安定度が変わる。

ハーネスとは、Claude Codeの構成要素をひとつのソフトウェア製品として設計・運用・改善する仕組みです。

管理する対象はコードそのものではありません。AIに仕事をさせる側の環境の品質です。

ルール・記憶・道具を整備しておけば、どのセッションでも同じ品質が再現できます。

この資料は、その全体像を10の章と18点の図で説明します。

02構成要素は、方針・知識・実行の3層に整理されています。

ガバナンスの傘の下に方針・知識・実行の3層が積み重なる構造イラスト
3層の上にガバナンスが乗り、手綱を握る。

方針層は振る舞いの定義です。CLAUDE.mdとSettingsが「何をして良いか」を決めます。

知識層は経験の蓄積です。Memory・Plans・Queueが「何を学んだか」を保持します。

実行層は能力です。Skills・Hooks・Learned Patternsが「どうやるか」を担います。

3層の上にガバナンスが乗り、成長・剪定・計測の3本の手綱で全体を制御します。

ガバナンスから方針層・知識層・実行層へ手綱が伸びるmermaid構造図
各層の中身と責務(mermaid図)。迷子になったらこの地図に戻る。
もう一歩深く: 各層の「成長」と「剪定」

方針層=ルール追加↔陳腐化削除。知識層=パターン吸収↔stale廃棄。実行層=skill/hook追加↔統廃合。層ごとに増やし方と減らし方が定義されています。

03地図はシンプルでも、実物は生態系です。

中央の3層の本部と、通信・工場・委譲・図書館・整備場の5施設が道でつながる俯瞰マップイラスト
3層は地図の縮尺。その下で5系統の街が動いている。

前節の3層は、正本HARNESS.mdが定義する地図です。実物はその下に広がります。

リモート運用系は外との接点です。Discordの常駐Botと管制盤が、外出先の指示と夜間運転を支えます。

計画・実行系は工場です。思いつきはplanに固まり、queueに並び、sprintの品質ゲートを通ります。

委譲系は複数のAIへ仕事を割り、知識系は経験を記憶と検索に変えます。土台は健全性系が守ります。

規模の実測はhook 49本・スキル55個・学習パターン168件・スクリプト73本。地図はシンプル、土地は広いのです。

ハーネスコアと5系統(リモート運用・計画実行・委譲・知識想起・健全性)の接続を示すmermaid構造図
コアと5系統の生態系マップ(mermaid図)。系統ごとに正本が別にある。
もう一歩深く: 各系統の正本

リモート運用=discord-channelsのHARNESS_DESIGN.md。計画実行=各スキルのSKILL.md。知識=learned_patternsの_INDEX.md。本資料の正本HARNESS.mdは「コア規律」だけを受け持ちます。

04品質はLoop 1が守り、ハーネス自身はLoop 2で育ちます。

内側の成果物ループと外側のハーネス成長ループが噛み合う二重の歯車イラスト
内のループが成果物を磨き、外のループが仕組みを育てる。

Loop 1はSprint Loopです。implement→dev-review→post-validateを1 Roundとして回します。

終了は回数ではなく定量指標で決めます。テスト・ビルド・仕様カバレッジが揃うまで。安全上限は5 Roundです。

Loop 2はハーネス自身の成長です。障害はlearnで即吸収し、成功は候補メモだけ残します。

メモの吸収は月次に一括で行います。日常のLoop 2コストを最小にする設計です。

Sprint Loopの品質ゲートと月次吸収への流れを示すmermaidフロー図
FAILなら実装へ戻り、PASSの学びは月次でハーネスへ還る(mermaid図)。

05成長・剪定・計測の3ルールが、ハーネスの肥大を防ぎます。

伸び放題の庭木と、メジャーで測りながら剪定された庭木の対比イラスト
測って、必要なものだけ増やして、古いものは刈る。

追加には条件があります。「3回以上同じ作業をした」か「障害が再発した」場合だけです。

剪定には閾値があります。90日参照されないMemoryや、done後30日のPlanはarchive行きです。

計測は月次で自動実行されます。警報が1件でも灯ると、剪定planが自動でqueueに載ります。

ただし削除の実行は人の起動を待ちます。無人で消させない線引きです。

月次計測から警報判定を経て剪定plan自動生成と人の起動へ至るmermaidフロー図
自動化は「planをqueueに載せる」まで。実行の引き金は人が引く(mermaid図)。
もう一歩深く: Memoryの「卒業」

hookやSOTに機械化されたfeedback memoryは役目を終えて自動archiveされます。移動のみで削除なし、いつでも戻せる可逆設計です。

06セッション固定コストは今、警報線を6割超えています。

14,371 tok
セッション固定コスト実測 (閾値 8,500 tok・2026-07-14)
CLAUDE.md 3,153 / 2,800
MEMORY.md 7,158 / 2,000
settings 4,060 / 4,000
縦線=閾値 / バー=実測。3項目とも閾値超過=WARNING 4灯
実測14,371tokは閾値8,500の1.69倍。警報4つがすべて点灯中。

セッション固定コストとは、起動のたびに自動で読み込まれるハーネスの重さです。

2026-07-14の実測は14,371トークン。6月10日の8,046から1ヶ月で急増しました。

主因はMEMORY.mdです。1,819から7,158トークンまで膨らみました。

つまり次の月次レビューで剪定planが自動発火する状態です。前節の仕組みが、まさに今動こうとしています。

もう一歩深く: always-onの実効合計

スキル説明文3,202tokを足したalways-on合計は17,573tok。金額影響は誤差で、本当の問題はコンテキスト窓の圧迫です。

0749本のhookが、ツール呼び出しの入口と出口を見張っています。

ゲートが並ぶ検問レーンをツール呼び出しの箱が通過し盾のガードが検査するイラスト
危険は入口で止め、品質は出口で確かめる。

hookはツール実行の前後に自動で走る小さな番人です。スクリプトは実測49本。

入口では危険を止めます。機密ファイルの読み取りや破壊的な削除はブロックされます。

出口では品質を確かめます。新規ノートのタグ検証・生成物の追跡・レビューの自動発火です。

セッションの開始から終了まで、全ライフサイクルに配置されています。

SessionStartからSessionEndまで各イベントで発火する代表hookを並べたmermaidフロー図
ライフサイクル別の発火マップ(mermaid図)。正本は settings.local.json。
もう一歩深く: hookを増やすときの決まり

追加前に同イベント×同matcherの既存hookを一覧で確認し、責務が重複するなら統合を検討します。増やすにもgrowルールが適用されます。

08品質判定は3段階 — FAILのまま世に出さない決まりです。

ベルトコンベア上の成果物がPASS・CONDITIONAL・FAILの3枚の判定カードに仕分けられるイラスト
PASSは発信、CONDITIONALは人が判断、FAILは作り直し。

成果物を作るスキルは共通の判定体系を持ちます。PASS・CONDITIONAL・FAILの3段階です。

PASSはそのまま発信できます。CONDITIONALは人が採用・修正・再生成を選びます。

FAILは再生成が必須です。FAILのまま出力しないのが全スキル共通の原則です。

例外はretry上限の超過だけ。その場合も回数と理由の明示が義務です。

生成から品質チェックを経て3段階判定と再生成ループへ分岐するmermaidフロー図
FAILは再生成ループへ戻る。出口は常にPASSか人の判断(mermaid図)。

09夜中の2時、ハーネスは自分で自分を棚卸しします。

02:00 深夜
機械が棚卸し
03:00
計測と剪定planの起票
Discord通知を読むだけ
週次 月曜 02:00月次 1日 03:00
✓ 棚卸しは自動、判断だけ人間
夜に機械が棚卸しし、朝に人が通知を読むだけ。

自動実行は深夜帯02:00〜06:00だけ。作業時間帯21:00〜01:59は禁止です。

毎週月曜02:00に週次レビュー。毎月1日03:00に月次+ハーネス計測が走ります。

結果はDiscordにサマリで届きます。人は朝、通知を見るだけです。

日次・月次・四半期の3サイクルで、この資料の内容自体も見直され続けます。

もう一歩深く: 壊れたときの切り分け

SessionStartフックがclaude --versionを毎回記録します。バージョン差異があればhooksとsettingsの互換を確認し、GitHub Releasesで原因を特定する手順です。

10見張り役のハーネスにも、見張りがついています。

整備台に乗った大きなロボットを、計測・修理・設計図書き換えの小さなロボット3体が整備するイラスト
ハーネス自身が「はかる・なおす・書きかえる」の対象になる。

ここまでの仕組みを描いてきたハーネス自身も、放置すれば劣化する製品です。

だから3本のメタループが張られています。自己計測は月次で重さと鮮度を測り、警報が出れば剪定planを自動起票します。

自己修復は常駐Botの無応答をwatchdogが立て直し、同じ死因が3回続けばレビュー案件を自動起票します。

自己改訂はスキルの効果測定や委譲の逸脱記録を、SKILLやhookの書き換えとして本体へ還流させます。

人間の役割は最終判断だけ。見張り役の見張りは、仕組み側に実装済みです。

ハーネス本体から自己計測・自己修復・自己改訂の3ループが出て本体へ還流するmermaid図
メタハーネスの3ループ(mermaid図)。いずれも「起票まで自動・実行は人」の線引き。
もう一歩深く: 実例

fable-modeスキルは効果測定→蒸留を2回経て自己改訂済み。§6で見た固定コスト警報も、次の月次で剪定planとして自動起票される見込みです。

迷ったら、この4つの正本に戻ります。

今の重さを知りたいときは python 40_Tools/scripts/harness_metrics.py --snapshot を実行します。