「ハーネスエンジニアリングは分かった。でも結局、どのツールを使えばいいんだ」——概念解説を読み終えた多くのエンジニアが、ここで止まる。
その「次の一歩」を埋めるのが、本記事で扱う ai-boost/awesome-harness-engineering というキュレーションリストだ。harness設計に必要なOSS・論文・テンプレートを、カテゴリ別に束ねた「地図」である。
ハーネスエンジニアリングの概念そのものや流派の整理は ハーネスエンジニアリングとは何か——5つの流派と設計思想を整理する で詳しく扱っている。harnessを実際に動かす土台となるClaude Code側の設定・運用については Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引き が詳しい。本記事はその先、「実装手段をどう探すか」に絞って、このリストの歩き方を解説する。
30秒で理解する awesome-harness-engineering
・何のリスト？ AIエージェントの「ハーネス（足回り）」を作るためのOSS・論文・記事・テンプレ集
・作者／ライセンス GitHubの ai-boost／CC0（パブリックドメイン、自由に使える）
・規模 ★3,614・フォーク437、GitHubリポジトリ220本を含む473リンク（2026-08-19時点の実測）
・構成 12の大分類＋16の小分類。README単体で234KB
・焦点 「モデルそのもの」ではなく「モデルを取り囲む足回り」だけを集約
・注意 同名の別リストがもう1つ存在する（後述）。読む前に作者名の確認が要る
・使いどころ 概念を理解した後、メモリ・MCP・権限・評価などの具体ツールを選定するとき
awesome-harness-engineeringは2つある——まず作者名を確認する
このリストを紹介する前に、先に片づけておくべき落とし穴がある。「awesome-harness-engineering」という名前のリポジトリは、GitHub上に2つ存在する。検索すると両方がヒットするため、どちらを見ているのか分からないまま読み進めてしまいやすい。
2026年8月19日時点でGitHub APIから両方を実測した結果が次の通りだ。
| 項目 | ai-boost/awesome-harness-engineering | walkinglabs/awesome-harness-engineering |
|---|---|---|
| スター | 3,614 | 3,858 |
| フォーク | 437 | 326 |
| 作成日時（UTC） | 2026-03-29 15:39 | 2026-03-29 11:29 |
| 最終更新 | 2026-08-18 | 2026-05-22 |
| README サイズ | 約234KB | 約28KB |
| 収録URL（重複除く） | 674本 | 107本 |
| GitHubのfork関係 | なし（parentなし） | なし（parentなし） |
押さえておきたい事実は3つある。
・どちらもGitHubのフォークではない。 API上、両者とも fork: false で親リポジトリを持たない。片方がもう片方を複製したものだ、という関係はGitHubのメタデータからは確認できない
・作成日は同じ2026年3月29日で、差は約4時間。 どちらが先かはタイムスタンプ上walkinglabs版だが、内容の由来を示す証拠ではないため、本記事では経緯の推測は行わない
・中身はほとんど重なっていない。 両READMEからURLを全件抽出して突き合わせると、共通するURLは22本のみだった。ai-boost版674本・walkinglabs版107本という規模差を踏まえても、実質的には独立した2つのキュレーションと見てよい
どちらを読むべきか
規模と更新の継続性を重視するなら ai-boost版（本記事が扱う方）だ。収録数が6倍以上あり、2026-08-18まで更新が続いている。一方 walkinglabs版はスター数では上回るものの、最終更新が2026-05-22で約3か月止まっている。当サイトの既存記事 ハーネスエンジニアリング入門｜AIエージェントを確実に動かす設計技法 が参照しているのは walkinglabs版のため、あわせて読む際は対象リポジトリが異なる点に注意してほしい。
awesome-harness-engineeringとは何か
awesome-harness-engineeringは、AIエージェントのharness（ハーネス）を設計するためのリソースを一箇所に集めたGitHubのawesomeリストだ。GitHubの ai-boost が管理し、ライセンスはCC0（パブリックドメイン）。2026年3月末に公開され、8月時点で★3,614・フォーク437まで伸びている。6月中旬時点では★約1,800だったので、2か月で概ね倍増した計算だ。
リストの定義文は明快だ。
「Harness engineering is the discipline of designing the scaffolding — context delivery, tool interfaces, planning artifacts, verification loops, memory systems, and sandboxes — that surrounds an AI agent and determines whether it succeeds or fails on real tasks.（ハーネスエンジニアリングとは、コンテキスト供給・ツールインターフェース・計画アーティファクト・検証ループ・メモリシステム・サンドボックスといった足場を設計する規律であり、それがエージェントが実タスクで成功するか失敗するかを決める）」
注目すべきは、リストが掲げるもう一つの前提だ。「This list focuses on the harness, not the model（このリストはモデルではなくharnessに焦点を当てる）」。さらに「最良のharnessは、それらの部品がモデルの進化とともに不要になることを知ったうえで設計されている」とまで言い切る。つまり収録物は「いまモデルができないことを補う部品」として整理されており、何が今のボトルネックなのかを逆算できる構成になっている。
この「モデルではなくharness」という割り切りは、一見すると当たり前に思える。だが実際の開発現場では、うまく動かないとき真っ先に「もっと賢いモデルを待とう」「プロンプトを練り直そう」と考えがちだ。awesome-harness-engineeringは、その手前にある膨大な設計余地——どんなツールを与えるか、どこまで権限を許すか、どうコンテキストを供給するか——にこそレバレッジがあると主張する。
READMEは冒頭に Deutsch / English / Español / Français / 日本語 / 한국어 / Português / Русский / 中文 の言語切り替えを備える。日本語READMEが用意されているため、英語が苦手でもカテゴリ構成と各項目の趣旨は追える。ただし、リンク先の論文・記事・OSSドキュメント自体は英語が大半だ。
リストの構成——「モデル以外のすべて」を28分類に割る
リストを使いこなすには、harness engineeringの基本語彙が必要だ。ここは最小限に絞る。
ハーネスとは馬具が語源で、AIというパワーを制御・誘導する「周囲の仕組み」全体を指す。プロンプトはモデルへの入力を最適化する技法だが、ハーネスはもっと広い。ルール定義（CLAUDE.md / AGENTS.md）、ツールの設計、メモリ、権限管理、検証ループ、サンドボックス——「モデル本体以外のすべて」がハーネスに含まれる。
この記事の立ち位置
概念そのものを基礎から学びたい場合は ハーネスエンジニアリング入門｜AIエージェントを確実に動かす設計技法、Claude Codeのソースから5層モデルを読み解く深掘りは ハーネスエンジニアリング完全解説 を参照してほしい。本記事は概念を理解した人が「実装手段（OSS）を探す」ための地図に徹する。
リストの構成も、この「モデル以外のすべて」を分解した形になっている。大きくは Foundations（基礎文献）／Design Primitives（設計部品）／Reference Implementations（参照実装）／Security・Evals・Templates・Related Lists という骨格で、H2レベルの大分類が12、その下の小分類が16——合わせて28の見出しに整理されている。とりわけDesign Primitivesは12のサブカテゴリに分かれ、harnessを構成する関心事がそのまま見出しになっている。
基礎文献・論文] A --> C[Design Primitives
設計部品 12分類] A --> D[Reference Implementations
参照実装 4分類] A --> E[Security / Evals
Templates / Related] C --> C1[Agent Loop] C --> C2[Planning &
Task Decomposition] C --> C3[Context Delivery &
Compaction] C --> C4[Tool Design] C --> C5[Skills & MCP] C --> C6[Permissions &
Authorization] C --> C7[Memory & State] C --> C8[Task Runners &
Orchestration] C --> C9[Verification &
CI Integration] C --> C10[Observability &
Tracing]
カテゴリごとの代表格を抜き出すと、次のようになる。いずれもREADMEに実際に収録されている項目だ。
| カテゴリ | 解決する課題 | 代表的な収録物 |
|---|---|---|
| Agent Loop | 思考と行動のループ構造 | ReAct（論文）、LangGraph、statewright、deepclaude |
| Planning & Task Decomposition | 長期タスクの分解と計画 | microsoft/TaskWeaver、LATS、Plan-and-Act |
| Context Delivery & Compaction | コンテキストの圧縮・供給 | LLMLingua、Context7、Token Savior、headroom |
| Tool Design | ツール定義の設計 | outlines、instructor、CLI-Anything |
| Skills & MCP | 外部接続とスキル配布 | MCP公式servers、playwright-mcp、Composio |
| Permissions & Authorization | 権限と安全な実行 | Beyond Permission Prompts、OWASP LLM06、Nango |
| Memory & State | セッションを跨ぐ記憶 | Letta(MemGPT)、mem0、Zep、cognee |
| Task Runners & Orchestration | 並列・多エージェント制御 | LangGraph、CrewAI、AutoGen、LiteLLM、Mastra |
| Verification & CI | 評価とCI統合 | promptfoo、AgentBench |
| Observability & Tracing | トレースと可観測性 | Langfuse、Arize Phoenix、OpenLLMetry |
この表を眺めるだけで、harnessが「ひとつの巨大な仕組み」ではなく、交換可能な部品の集合であることが分かる。コンテキストが溢れるならCompaction層、記憶が飛ぶならMemory層、というように、自分の症状に対応する部品だけを差し替えていける。
Foundations — まず読むべき原典
harness engineeringの「教科書」にあたる文献群だ。OpenAIの「Harness Engineering」「Unrolling the Codex Agent Loop」、Anthropicの「Building Effective Agents」「Harness Design for Long-Running Application Development」、Martin Fowlerの「Harness Engineering」、LangChainの「The Anatomy of an Agent Harness」が並ぶ。Microsoftの「Azure SRE Agent」事例（35,000件超の本番インシデントを自律対応し、平均対応時間を40.5時間から3分に短縮）のような実運用の数字も含まれ、概念が机上論でないことを裏づける。
Agent Loop — すべての土台になるループ
エージェントの「思考→行動→観察」ループを扱うカテゴリ。出発点は2022年の ReAct（Thought/Action/Observationの構造を定義した論文）で、いまもほぼすべてのharnessの基礎になっている。実装系では有向グラフとして状態を持つ LangGraph、ワークフローの局面ごとにツール呼び出しを制約する statewright、Claude Codeのエージェントループを別バックエンドへ移植した deepclaude などが収録される。deepclaudeの存在は「エージェントの挙動を決めるのはモデルの正体ではなくループ構造だ」という、harness engineeringの核心を実証する例として面白い。
Context Delivery & Compaction — トークンとの戦い
最も項目数が多いカテゴリのひとつ。コンテキストウィンドウは有限資源だ、という前提で圧縮・供給技術が集まる。MicrosoftのLLMLingua（プロンプトを最大20倍圧縮）、Upstashの Context7（バージョン指定のライブラリドキュメントを注入）、Token Savior（シンボル索引でアクティブトークンを削減）、headroom（ツール出力を圧縮）など、実測値つきのOSSが揃う。Anthropicの「Compaction」公式ドキュメントも収録されている。
Skills & MCP — 接続の標準を押さえる
エージェントを外界につなぐプロトコルとツールのカテゴリ。中心はAnthropicの Model Context Protocol（MCP） と公式の modelcontextprotocol/servers。microsoft/playwright-mcp（アクセシビリティツリー経由のブラウザ操作）、Googleの A2A Protocol（エージェント間通信）、多数のSaaS APIをOAuth込みでラップする Composio などが並ぶ。
Memory & State / Permissions — 覚える層と、止める層
長時間・複数セッションのタスクで効く記憶層には、三層メモリの参照実装 Letta（MemGPT）、ドロップイン型の mem0、会話要約と意味検索の Zep、グラフ＋ベクトル＋リレーショナルのポリストア cognee などが収録される。一方Permissions & Authorizationには、Anthropicの「Beyond Permission Prompts」、OWASP LLM06:2025（Excessive Agency）、API認証を肩代わりする Nango、ツール呼び出しを実行前に遮断する Open Agent Passport（OAP） が並ぶ。「覚えさせる」と「止める」は、自律実行を本番に出すなら必ず両方通るカテゴリだ。
Reference Implementations・Templates — 動く見本と雛形
論文や個別OSSだけでなく、まるごと動く参照実装と雛形も収録されている点がこのリストの実用性を高めている。Reference Implementationsはチュートリアル・教材、harnessを生成するメタツール、デモ用harness、隣接コレクションの4系統に分かれる。Templatesカテゴリには AGENTS.md や HARNESS.md といった、そのまま自分のリポジトリにコピーして使える雛形が並ぶ。「ゼロから設計する」のではなく「実績のある雛形を写経して削る」アプローチが取れるため、最初のharnessを立ち上げる速度が大きく変わる。
6月から8月で何が増えたか——安全性と「動く見本」への傾斜
awesomeリストは生き物だ。このリストが今どちらへ伸びているかは、収録物の差分を取ると分かる。2026年6月15日時点のREADMEと最新版から、それぞれGitHub URLを抽出して突き合わせた。
結果、収録リポジトリは 159本から220本へ、61本増えていた（重複除く）。箇条書きリンクの総数は384本から473本、READMEサイズは187KBから234KBへ膨らんでいる。一方でカテゴリ構成は12大分類＋16小分類のまま、まったく変わっていない。つまりこの2か月は、新しい概念区分が生まれたのではなく、既存の枠に中身が積み増された期間だった。分類の枠組みとしては、すでに落ち着きはじめていると読める。
内訳を見ると、傾向がはっきり出ている。
・安全性まわりが最多。 Security, Sandbox & Permissions が8本、Permissions & Authorization が2本。合わせて10本で、テーマ別では最大の増分になる。エージェントに実行権限を渡す段階に進んだ現場が増え、隔離とサンドボックスの需要が顕在化したことの反映だろう
・「動く見本」が9本。 Demo Harnesses が単一カテゴリでは最多。概念の解説より、まるごと動く参照実装が求められている
・接続規格が7本。 Skills & MCP の増加は、MCPがharness設計の標準部品として定着したことを示す
・生成側が5本。 Generators & Meta-Harnesses、つまり「harnessを作るharness」のカテゴリが伸びているのは、設計そのものの自動化が始まっている兆候だ
この増分には、当サイトが個別に検証記事を書いたOSSも12本含まれている。DietrichGebert/ponytail（スキルの常駐コスト）、kvcache-ai/AgentENV（Firecracker microVMでの環境量産）、cobusgreyling/loop-engineering（ループ設計の体系化）などが、6月以降にこのリストへ加わった。
収録物のうち50本は当サイトで個別に検証済み
このリストの実用性を測る別の角度として、収録220リポジトリのうち、当サイトが単独記事で扱ったものが何本あるかを数えた。結果は50本だった。リストに載っている顔ぶれが、実際に日本語で深掘りする価値のあるOSS群と重なっていることの傍証になる。
リスト側が持つのは1行の紹介文だけだ。実際に動かすと紹介文とズレることは珍しくない。代表例を、当サイトで実測して分かったことと並べて挙げる。
| 収録リポジトリ | リスト上の分類 | 実際に動かして分かったこと |
|---|---|---|
| ChromeDevTools/chrome-devtools-mcp | Skills & MCP | 公称52ツールに対し、既定で有効なのは29本だった（実測記事） |
| DietrichGebert/ponytail | Skills & MCP | スキルを常駐させる際のトークン負担を配布物から実測できる |
| kvcache-ai/AgentENV | Security, Sandbox | Firecracker microVMで使い捨て環境を量産する設計 |
| cloudflare/computer | Demo Harnesses | 「結果をシミュレート」の実体は読み取り時オーバーレイだった |
| cobusgreyling/loop-engineering | Agent Loop | Evaluator-Optimizer型のループ設計を体系化した教材 |
| kerlenton/mcpsnoop | Debugging & DX | MCPのやり取りをWiresharkのように覗くデバッグ用途 |
| omnigent-ai/omnigent | Generators | harness自体を生成するメタharness |
| stablyai/orca | Task Runners | 並列エージェントと既存フレームワークの住み分けが論点 |
| xai-org/grok-build | Demo Harnesses | 公開のされ方そのものが特徴的なターミナルエージェント |
| TencentCloud/CubeSandbox | Security, Sandbox | microVM型のエージェント用サンドボックス |
リストを起点に気になる項目を見つけたら、そのリポジトリ名で当サイト内を検索すると実測ベースの詳細が見つかることが多い——という使い方ができる。リストは「候補を知る」ために使い、採否は自分の環境で確かめるのが基本線だ。
自分のプロジェクトでの活用パターン
リストは眺めるためでなく、自分のharnessに部品を移植するためにある。実践的な使い方を3ステップで示す。
活用の3ステップ
・①症状を言語化する — 「長期タスクで前半の指示を忘れる」「トークン代が高い」「権限が怖くて自動化できない」など、いま困っていることを1文にする
・②対応カテゴリへ直行する — 忘れる→Memory & State、トークン→Context Delivery & Compaction、権限→Permissions & Authorization、という対応で該当カテゴリを開く
・③一次情報→OSSの順で読む — まずFoundationsや各カテゴリ冒頭の論文・公式記事で「なぜそうするか」を掴み、次に実OSSを1つ試す
例: 長期タスクで指示を忘れる] --> C{対応カテゴリを選ぶ} C -->|記憶が飛ぶ| M[Memory & State] C -->|トークン超過| X[Context Delivery] C -->|権限が怖い| P[Permissions] M --> R[原典で理由を理解] X --> R P --> R R --> O[OSSを1つ試す
mem0 / Context7 / Nango など] O --> V[評価ツールで効果測定
promptfoo] V --> S
このループの肝は、最後に Verification（評価）へ戻ることだ。部品を入れて満足するのではなく、promptfooのような評価ツールで「本当に改善したか」を測ってから次へ進む。harness engineeringが「足回りの工学」である以上、計測なしの改善は成り立たない。
具体例で考えてみよう。「Claude Codeで数百ファイルのリファクタを任せると、後半で最初の指示を忘れて方針がブレる」という症状があったとする。これは典型的なコンテキスト劣化（Context Rot）だ。①症状は「長期タスクで前半の指示を忘れる」。②対応カテゴリはMemory & StateとContext Delivery & Compaction。③まずAnthropicの「Effective Context Engineering」で原則を掴み、外部メモリとして AGENTS.md に方針を固定したうえで、mem0 や Token Savior のようなOSSを1つ試す。④最後にpromptfooで「指示を保持できているか」を評価セットで測る——この一周で、感覚ではなく数字で改善を確認できる。
リストを「読み物」ではなく「症状別の処方箋」として引けるようになると、harness改善のサイクルが一気に回り始める。重要なのは一度に全部入れないことだ。部品を1つ入れては計測し、効いた部品だけ残す。harnessはこうして少しずつ育てていくものである。
既存の概念整理記事との関係を整理すると、次の表のように使い分けられる。
| 記事 | 役割 | こんなときに |
|---|---|---|
| ハーネスエンジニアリング入門 | 概念を初歩から | そもそもharnessとは何かを知りたい |
| 5つの流派と設計思想 | 定義と流派の整理 | 人によって定義が違う理由を知りたい |
| 完全解説（5層モデル） | Claude Code内部の深掘り | 実装の内側を読みたい |
| 本記事（awesomeリスト） | OSS・実装手段の地図 | 結局どのツールを使うか決めたい |
リストの品質を実測する——220本中2本がリンク切れ
キュレーションリストの弱点はリンク腐敗（link rot）だ。数百項目を人力で維持する以上、消えたリポジトリが残り続けるのは避けにくい。このリポジトリは verify_urls.py という検証スクリプトを同梱しており、作者側もこの問題を意識していることが分かる。
実際にどの程度健全なのかを確かめるため、READMEに含まれるGitHubリポジトリ220本（重複除く）を全件、GitHub APIで照会した。
・218本は実在を確認できた（約99%）
・2本がAPI・ブラウザともに404を返した — SmileLikeYe/agent-chief と anthropics/ai-harness-scorecard の2件
数百項目規模のリストで生存率99%は高い水準だ。ただし後者は anthropics/ 組織下の名前で「AI Harness Scorecard」として掲載されているにもかかわらず、2026年8月19日時点でリポジトリが存在しない。非公開化・削除・改名のいずれかが起きた可能性があるが、外部からは判別できないため断定はしない。組織名が有名だからといってリンク先の実在が保証されるわけではない、という一般的な注意点として押さえておきたい。
awesomeリストを使うときの前提
キュレーションリストは「誰かが一度は目を通した」ことの保証であって、「いま動く」ことの保証ではない。収録されているOSSを採用候補にする際は、最終コミット日・Issue の活性・ライセンスを自分で確認する手順を必ず挟む。本記事の数値も2026-08-19時点の実測であり、リストは日々更新される。
コントリビュートとライセンス
awesome-harness-engineeringはCC0のコミュニティリストで、貢献の敷居は低い。新しいOSSや見落とされた論文を見つけたら、誰でも追加提案できる。
プルリクエストを出す流れ
・①フォークする — リポジトリを自分のアカウントにフォーク
・②該当カテゴリに1行追記 — [ツール名](URL) — 一言説明 の形式で、既存項目の書式に合わせる
・③CONTRIBUTING.mdを確認 — 収録基準やフォーマット規約に目を通す
・④プルリクエストを送る — リンク切れ修正や分類改善といった小さな貢献も歓迎される
日本語READMEが用意されている分、日本語話者にとっては貢献のハードルも低い。日本発のharness系OSSや、日本語で書かれた良質な解説記事を見つけたら、それを適切なカテゴリへ追加するだけで、リストの多様性に貢献できる。英語一辺倒になりがちなこの分野で、日本語リソースを可視化する意義は小さくない。上で挙げた404の2件のように、リンク切れを見つけて報告するのも立派な貢献だ。
ライセンスがCC0（パブリックドメイン）である点も実務上は効く。リストの内容を自分の社内ドキュメントへ転載・改変しても、原則として制約がない。「社内のAIエージェント設計ガイドライン」の骨子として、カテゴリ構成ごと持ち込むといった使い方ができる。
まとめ：概念から実装への橋渡し
awesome-harness-engineeringは、ハーネスエンジニアリングという抽象概念と、現場で動くOSSの間に架かる橋だ。要点を振り返る。
この記事のまとめ
・同名リストが2つ存在する。本記事が扱うのは ai-boost版（★3,614・収録URL 674本・更新継続中）で、walkinglabs版とはURL重複22本しかない別物
・ai-boost版はCC0で公開され、GitHubリポジトリ220本を含む473リンクを12大分類＋16小分類に整理している
・「モデルではなくharness」に焦点を絞り、症状起点でカテゴリを引ける構成になっている
・6月→8月の2か月で収録リポジトリは159→220本へ増加。安全性・サンドボックス系が最多の伸びで、カテゴリ構成自体は不変
・収録220本のうち50本は当サイトが個別に検証済み。リストで見つけて、実測記事で裏を取るという併用ができる
・リンク生存率は約99%（218/220）。ただし anthropics/ 名義の1件を含む2本が404で、リンク先の実在は自分で確認する必要がある
