Claude Codeを Plan→Work→Review で自律運用するOSS「claude-code-harness」の仕組みと特徴

Claude Code をはじめとする AI コーディングエージェントは、対話的に使う分には便利です。しかし、いざ実作業に組み込もうとすると、別の不安が顔を出します。立てたはずの計画がチャットの流れに埋もれて残らない、テストが「やってもやらなくてもいいもの」になる、レビューが手遅れのタイミングでしか入らない、リリース時に「何を根拠に出すのか」を記憶から再構築する羽目になる——こうした「逸脱」をどう抑えるかが、エージェント活用の最大の壁になりがちです。

個人で使ううちは、その都度止めて軌道修正すればよいかもしれません。けれども品質を一段引き上げ、再現性のある形で回そうとすると、「エージェントが計画なしに走り出さない仕組み」「レビューを必ず挟める仕組み」が欲しくなります。プロンプトの工夫だけでは、毎回ぶれない運用には届きません。

この課題に対して、エージェントの作業を「Plan（計画）→ Work（実装）→ Review（レビュー）→ Release（リリース）」という型に沿わせることで律しようとするのが、本記事で扱う OSS「claude-code-harness」です。harness（ハーネス）という語のとおり、暴れがちなエージェントに「制御の枠」をかぶせる発想のツールです。

本記事では、claude-code-harness が解決しようとしている課題、その仕組みの核心である Plan→Work→Review→Release サイクルと5つの動詞、設計上の特徴、類似 OSS との違い、そして採用・見送りの判断基準までを、初めてこのリポジトリを見たエンジニアの視点で整理して解説します。なお本記事は実際の動作検証・インストールを行わず、公式リポジトリのドキュメントに基づいて記述しています。

claude-code-harness とは — Claude Codeの「逸脱」を1本の運用経路に変えるOSS

claude-code-harness は、Claude Code 専用の開発ハーネス（Dedicated Development Harness）として公開されている OSS です。リポジトリは Chachamaru127/claude-code-harness にあり、ライセンスは MIT です。リポジトリの説明文では「自律的な Plan→Work→Review サイクルを通じて高品質な開発を実現する」と位置づけられています。

一言でいうと何をするOSSか

一言でいえば、claude-code-harness は「Claude Code のエージェント作業を、計画・実装・レビュー・リリースという決まった経路に沿わせるための枠組み」です。エージェントに自由に書かせるのではなく、「次に何をするか」をあらかじめ定めたレールの上で動かすことで、振る舞いに再現性を持たせようとします。

リポジトリのタグラインには、次のように記されています。

"Plan. Work. Review. Ship. A disciplined delivery loop for Claude Code, with bounded paths for Codex and OpenCode."

出典: claude-code-harness README

「disciplined delivery loop（規律ある配信ループ）」という言葉が、このツールの狙いを端的に表しています。Claude Code を主対象としつつ、Codex や OpenCode にも「境界を定めた経路（bounded paths）」を用意している点も読み取れます。

解決しようとしている課題

なぜこうした「型」が必要なのか。README の "Why" にあたる説明が、解決対象の課題を明快に言語化しています。

"Claude Code is powerful, but raw agent work drifts: plans live in chat, tests become optional, review happens too late, and release evidence gets rebuilt by memory. Harness turns that into one repeatable operating path."

出典: claude-code-harness README

要約すると、Claude Code は強力だが「素のエージェント作業」は drift（逸脱・形骸化）しやすい、という指摘です。具体的には次の4つの症状が挙げられています。

• 計画がチャットの中だけに存在し、ドキュメントとして残らない
• テストが「やってもやらなくてもよいもの」になる
• レビューが手遅れのタイミングで行われる
• リリース時の根拠（evidence）を記憶から再構築する羽目になる

claude-code-harness は、これらを「1本の反復可能な運用経路（one repeatable operating path）」に変えることを目的に据えています。冒頭で挙げた検索者の悩みと、ほぼそのまま重なる課題設定です。

リポジトリの基本情報

公式リポジトリの主要な属性は次のとおりです（数値は 2026年5月時点の取得値）。

Stars が 2,000 を超え、forks も 200 を上回っていることから、一定の関心と試用が集まっているリポジトリだと読み取れます。最終更新が直近である点も、現在もメンテナンスが続いていることを示す材料です。主要言語が Shell で、後述するように Go ネイティブのコアを併用している点は、このツールの設計思想を理解する手がかりになります。

仕組みの核心 — Plan→Work→Review→Release サイクルと5つの動詞

claude-code-harness の核心は、エージェントの作業を一連の決まったサイクルに沿わせることにあります。仕組みの詳細は公式の How it works セクションにまとまっています。ここでは、その骨格を初見でも追えるように整理します。

ステージとゲート

README の "How It Works" では、作業が次のステージに分けられ、各ステージに「ゲート（次へ進む条件）」が設けられています。

出典: claude-code-harness README（How It Works）

このステージ表が示す思想は明確です。たとえば最初の Investigate には「観測していないデータを主張に昇格させない（Do not promote unobserved data into claims）」というゲートが置かれ、エージェントが憶測を事実のように扱うことを構造的に防ごうとします。PR と Release を分け、「PR ready is not release ready（PRが整ったこと=リリースしてよいこと、ではない）」と明示している点も、リリース時の品質を軽視させないための歯止めです。

この型の利点は、「計画なしの実装」「レビューなしの反映」といった逸脱が、サイクルの構造上そもそも起きにくくなることです。エージェントの賢さに任せるのではなく、進行のレールをあらかじめ敷いておく、という発想です。

5つの動詞の役割

claude-code-harness では、上記サイクルを回すための操作が「動詞」として整理されています。表面（コマンド面）をあえて最小限に保つ設計で、コアとなるのは plan / work / review / sync / release の5つです。それぞれの役割は次のとおりです。

• plan: 意図を spec.md と Plans.md に変換します。スコープ・受け入れ基準・依存関係・未知事項・停止条件を書き出し、計画を文書として固定します。
• work: 承認済みのスライス（作業単位）を、TDD と検証付きで実装します。作業は承認済み計画の境界に制約されます。
• review: 実装から分離した独立レビューを行います。重大な指摘は完了のブロッカーとして扱われます。
• release: readiness チェックを行い、CHANGELOG やタグの境界を検証し、検証済みの evidence だけをパッケージします。
• sync: セッションをまたいだ整合を維持します。

動詞という単位で操作が分かれていることで、「いま自分はサイクルのどの段階にいるのか」が明確になり、フェーズの飛ばしや混在を避けやすくなります。とりわけ「work が承認済み計画の境界に縛られる」「review が実装から分離される」という2点は、冒頭で挙げた「計画なしに走り出す」「レビューが手遅れになる」という症状への直接的な回答になっています。

spec.md / Plans.md という source-of-truth

サイクルを支えるのが、spec.md（仕様）と Plans.md（計画）という成果物です。plan の段階で生成されるこれらのファイルは、単なるメモではなく、後続ステージの入力として機能する source-of-truth（信頼できる唯一の情報源）です。

重要なのは、Plan ステージのゲートが「ユーザーが生成された契約を承認・修正する」となっている点です。エージェントが立てた計画をそのまま実行するのではなく、人間が一度「契約」として承認するワンクッションが構造に組み込まれています。これにより、計画がチャットに埋もれて消えることがなくなり、実装とレビューの基準が常にこのファイルに紐づきます。

コマンドの流れ

実際の操作は、Claude Code のプラグインとして導入したうえで、スラッシュコマンドで動詞を呼び出す形になります。README に記載された導入から最初のタスクまでの流れは次のとおりです。

claude
/plugin marketplace add Chachamaru127/claude-code-harness
/plugin install claude-code-harness@claude-code-harness-marketplace
/harness-setup

出典: claude-code-harness README

セットアップ後、最初のタスクは計画から始めます。

/harness-plan Improve the README onboarding flow

出典: claude-code-harness README

計画が承認されたら、スライス単位で実装を進めます。

/harness-work 1.1.1

出典: claude-code-harness README

このように、/harness-plan で計画を文書化し、承認を経てから /harness-work で番号付きのスライスを実装する、という流れが基本形です。コマンドの並びそのものが、Plan→Work というサイクルを利用者に強制する作りになっていることが分かります。

単なるコマンド集ではない設計上の特徴

5つの動詞が中心ではあるものの、claude-code-harness は単なるコマンドの寄せ集めではありません。「自分の環境に当てはまるか」を判断するうえで見ておきたい特徴がいくつかあります。

Go ネイティブのガードレールと検証ゲート

claude-code-harness のコアには、Go ネイティブのガードレールエンジンが採用されており、Node.js を必要としません。重厚なランタイムを前提とせず、Go で実装されたコアがガードレール（逸脱を防ぐ仕掛け）を担う構成です。

前のセクションで見た「ステージごとのゲート」は、この設計の上に成り立っています。TDD の強制（指定時）、実装から分離した独立レビュー、PR・リリースに向けた evidence のパッケージングといった検証の仕掛けが、サイクルの各所に配置されています。賢いエージェントに広い裁量を与えるほど逸脱の余地も広がる、というトレードオフに対し、claude-code-harness は裁量を構造的に制限する側へ振っているわけです。

なお、既存ユーザー向けには移行レポートを出す仕組みも用意されています。

bin/harness doctor --migration-report

出典: claude-code-harness README

マルチツール対応マトリクス

claude-code-harness は Claude Code を主対象としつつ、他の AI コーディングツールにも対応しています。README には、ツールごとの対応状況（Tier）と導入経路を示すマトリクスが掲載されています。

出典: claude-code-harness README

注目すべきは、対応が一律ではなく Tier で区別されている点です。Claude Code が「supported（サポート対象）」なのに対し、Codex CLI・OpenCode・Cursor は「internal-compatible（内部互換）」、Codex app や GitHub Copilot CLI は「candidate（候補）」という位置づけです。複数のツールを横断して使うチームにとっては、自分の主力ツールがどの Tier にあるかが、導入価値を左右する判断材料になります。

メモリ連携・非エンジニア向けレビュー面

このほか、運用の幅を広げる仕掛けとして次のようなものが用意されています。

• harness-mem 連携（任意）: セッションをまたいだメモリを保持する仕組みで、設定すると過去の文脈を再利用しやすくなります。
• 非エンジニア向けレビュー用 HTML サーフェス: Plan Brief（計画の要約）・Progress Tracker（進捗）・Acceptance Demo（受け入れデモ）といった、エンジニアでなくても内容を確認できる画面が用意されています。

後者は、チームに非エンジニアのレビュアー（プロダクトオーナーなど）がいる場合に効いてくる要素です。計画や進捗・成果を「コードを読まなくても確認できる形」で提示できる点は、レビューを早い段階で巻き込みたいチームにとって魅力になり得ます。

類似OSSとの比較 — 能力を増やすか、軽く補助するか、プロセスを律するか

Claude Code を補助・拡張する OSS は他にも存在します。代表的な類似プロジェクトと比較することで、claude-code-harness の立ち位置がより鮮明になります。なお、各リポジトリの数値は本記事調査時点（2026年5月）の値であり、更新により変動します。

oh-my-claudecode との違い

Yeachan-Heo/oh-my-claudecode は「Teams-first なマルチエージェント・オーケストレーション」を掲げる OSS です。19の専門エージェントや複数の実行モードを備え、簡単なタスクと複雑な推論でモデルを使い分けるといった「能力拡張」型のアプローチを取ります。Stars は約35,000 と規模が大きく、claude-code-harness とは桁が異なります。

両者の違いは、主眼の置き方にあります。oh-my-claudecode は「エージェントに何ができるか・どこまで自律実行できるか」を増やすことが中心です。段階的なパイプラインを使うこともできますが、ゲートの強制が主眼ではありません。対して claude-code-harness は「どう進めるか（Plan→Work→Review→Release という配信プロセス）」を律することと、ステージごとの検証ゲートが主眼です。前者は能力・自律実行の拡張、後者はプロセス規律、と整理できます。

Claude Code 周辺ツールの「能力拡張」型のアプローチを詳しく知りたい場合は、別記事のoh-my-claudecode の解説もあわせて参照すると、どのレイヤーの課題を解決したいのかを切り分けやすくなります。

ccharness との違い

elct9620/ccharness は「Claude Code 体験を改善する軽量ツール群」を掲げる OSS です。Claude Code のフックライフサイクル（Stop / PostToolUse / PreToolUse 等）に統合し、Guard Commit フックやレビューリマインダ、ファイルアクセスの監査といった「限定的なタッチポイント」を補助します。Stars は 7 で、規模としては小さなユーティリティです。

ccharness は、Claude Code のワークフロー構造を置き換えるのではなく、要所にフックを差し込んで補助する立場です。導入も npx でグローバルインストールせずに実行できるほど軽量です。これに対し claude-code-harness は、5動詞のフルプロセスと Go ネイティブのガードレール、マルチツール対応、evidence パッケージングといった広い面を持ちます。「導入が軽い補助」か「規律・網羅性を重視したフルプロセス」か、という対比です。

比較表

3つのツールを軸ごとに整理すると、次のようになります。

出典: Chachamaru127/claude-code-harness / Yeachan-Heo/oh-my-claudecode / elct9620/ccharness

この比較からわかるのは、claude-code-harness の差別化点が「作業の型（ワークフロー）そのものを規定する」ことにある、という点です。能力を増やすタイプ、軽く補助するタイプとは解決しようとしているレイヤーが異なります。「どれを選べばいいか」の答えは、自分の課題が「能力の不足」なのか「軽い補助の欲しさ」なのか「進め方のブレ」なのか、によって変わります。

採用・見送りの判断基準（初見エンジニア向け）

ここまでの内容を踏まえ、claude-code-harness を採用すべきか見送るべきかの判断軸を整理します。なお本記事は動作検証を行わず、公式ドキュメントに基づく記述です。実際の導入可否は、公式の Quickstart セクションで前提条件と手順を確認したうえで判断してください。

向いているケース

次のような状況のチーム・個人は、claude-code-harness の「型で律する」発想が課題に直接刺さります。

• Claude Code を既に使っており、エージェントの逸脱やレビュー漏れ、計画の消失に困っている
• 成果物の予測可能性・レビューのしやすさを、実装スピードよりも重視している
• 計画と実装を明示的に分け、変更のスコープを限定したい
• リリース時に「何を根拠に出したか」を evidence として残したい
• Claude Code を軸に、Codex や OpenCode、Cursor なども横断して使っている

これらに複数当てはまるなら、まず Quickstart に沿って小さな範囲で確認する価値があります。

過剰になりうるケース

一方で、次のような場合は導入の効果が薄かったり、運用が窮屈に感じられたりする可能性があります。

• 使い捨てのスクリプトや、ごく小さな単発作業が中心で、計画・レビューの分離が割に合わない
• プロセスの規律よりも、探索的に素早く試行錯誤する速度を最優先したい段階にある
• 主力ツールがマトリクス上で candidate 扱いで、サポートの厚みが不足している

この場合は、型を強制しないタイプの周辺ツール（軽量なフック補助や能力拡張型）から検討するか、自分の課題が本当に「逸脱の抑制」なのかを先に見極めるのが現実的です。

導入の前提要件と最初の一歩

採用に進む場合、README に記載された前提要件は次のとおりです。

• Claude Code v2.1 以降（supported な Claude 経路の場合）
• 書き込み権限のあるプロジェクトリポジトリ
• Node.js は不要（Go ネイティブコア）
• 任意で harness-mem（設定時）

最終的な判断の前には、少なくとも次の3点を公式情報で確認しておくと精度が上がります。

1. 対応環境と前提条件（Quickstart セクション）
2. 各動詞とステージ・ゲートの具体的な挙動（How it works セクション）
3. ライセンスとメンテナンス状況（リポジトリ本体。本記事時点で MIT ライセンス、最終更新は 2026年5月30日）

まとめ

claude-code-harness は、Claude Code のエージェント作業を Plan→Work→Review→Release の型に沿わせ、spec.md と Plans.md を source-of-truth としてステージ間を橋渡しすることで、逸脱しがちなエージェントを律する OSS です。中心にあるのは「賢さに任せる」のではなく「進め方を構造で縛る」という思想であり、plan / work / review / sync / release という5つの動詞、ステージごとの検証ゲート、Go ネイティブのガードレールがそれを支えています。

類似 OSS が「能力を増やす（oh-my-claudecode）」「軽く補助する（ccharness）」方向に寄っているのに対し、claude-code-harness は「進め方そのものを規定する」方向に踏み込んでいる点が差別化要素です。そのため、レビューを挟んだ再現性のある運用やリリース根拠の保全を重視するチームには有力な選択肢になり、逆に探索的に素早く動かしたいチームには窮屈に映る可能性があります。

初見でこのリポジトリを評価するなら、まず自分の課題が「エージェントの逸脱抑制」にあるかを見極め、当てはまるなら公式の How it works と Quickstart を確認する、という順序が現実的です。本記事はあくまで公式ドキュメントに基づく整理であり、最終的な判断は一次情報で確認することをおすすめします。