「ハーネスエンジニアリングは分かった。でも結局、どのツールを使えばいいんだ」——概念解説を読み終えた多くのエンジニアが、ここで止まる。
その「次の一歩」を埋めるのが、本記事で扱う ai-boost/awesome-harness-engineering というキュレーションリストだ。harness設計に必要なOSS・論文・テンプレートを、カテゴリ別に束ねた「地図」である。
ハーネスエンジニアリングの概念そのものや流派の整理は ハーネスエンジニアリングとは何か——5つの流派と設計思想を整理する で詳しく扱っている。本記事はその先、「実装手段をどう探すか」に絞って、このリストの歩き方を解説する。
30秒で理解する awesome-harness-engineering
・何のリスト？ AIエージェントの「ハーネス（足回り）」を作るためのOSS・論文・記事・テンプレ集
・作者／ライセンス GitHubの ai-boost／CC0（パブリックドメイン、自由に使える）
・規模 ★約1,800・フォーク185（2026年6月時点）、20以上のカテゴリに数百項目
・焦点 「モデルそのもの」ではなく「モデルを取り囲む足回り」だけを集約
・多言語対応 日本語を含む9言語のREADME
・使いどころ 概念を理解した後、メモリ・MCP・権限・評価などの具体ツールを選定するとき
awesome-harness-engineeringとは何か
awesome-harness-engineeringは、AIエージェントのharness（ハーネス）を設計するためのリソースを一箇所に集めたGitHubのawesomeリストだ。GitHubの ai-boost が管理し、ライセンスはCC0（パブリックドメイン）。2026年3月末に公開され、6月時点で★約1,800・フォーク185と、harness系のリストとしては急速に伸びている。
リストの定義文は明快だ。
「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は、その手前にある膨大な設計余地——どんなツールを与えるか、どこまで権限を許すか、どうコンテキストを供給するか——にこそレバレッジがあると主張する。Anthropicの「2026 Agentic Coding Trends Report」が「harnessの設定だけでベンチマークが5ポイント以上動く」と報告しているのは、その裏づけだ。
awesomeリストとは、特定テーマの優良リソースを有志がキュレーションするGitHubの文化だ。一次情報（論文・公式ドキュメント）と実際に動くOSSが同じ粒度で並ぶため、「概念→実装」をひとつのページで往復できる。harness engineeringのように動きの速い分野では、個別に検索するより信頼できるリストを起点にした方が圧倒的に速い。
ハーネスエンジニアリングの基本をおさらいする
リストを使いこなすには、harness engineeringの基本語彙が必要だ。ここは最小限に絞る。
ハーネスとは馬具が語源で、AIというパワーを制御・誘導する「周囲の仕組み」全体を指す。プロンプトはモデルへの入力を最適化する技法だが、ハーネスはもっと広い。ルール定義（CLAUDE.md / AGENTS.md）、ツールの設計、メモリ、権限管理、検証ループ、サンドボックス——「モデル本体以外のすべて」がハーネスに含まれる。
この記事の立ち位置
概念そのものを基礎から学びたい場合は ハーネスエンジニアリング入門｜AIエージェントを確実に動かす設計技法、Claude Codeのソースから5層モデルを読み解く深掘りは ハーネスエンジニアリング完全解説 を参照してほしい。本記事は概念を理解した人が「実装手段（OSS）を探す」ための地図に徹する。
リストの構成も、この「モデル以外のすべて」を分解した形になっている。大きくは Foundations（基礎文献）／Design Primitives（設計部品）／Reference Implementations（参照実装）／Security・Evals・Templates・Related Lists という骨格だ。とりわけDesign Primitivesは12のサブカテゴリに分かれ、harnessを構成する関心事がそのまま見出しになっている。次の図がリスト全体の俯瞰だ。
基礎文献・論文] A --> C[Design Primitives
設計部品 12分類] A --> D[Reference Implementations
参照実装] 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]
ギャラリー：リストの第一印象
awesome-harness-engineeringは、装飾過多なリポジトリではない。冒頭に1枚のバナーがあり、その下にバッジ群とテーマの定義が続く、典型的なawesomeリストの構成だ。デモGIFや動画は持たないが、その分「リンクの密度」で勝負している。
冒頭のバッジ群は、リストの素性を一目で伝える。
READMEは冒頭に Deutsch / English / Español / Français / 日本語 / 한국어 / Português / Русский / 中文 の言語切り替えを備える。日本語READMEが用意されているため、英語が苦手でもカテゴリ構成と各項目の趣旨は追える。ただし、リンク先の論文・記事・OSSドキュメント自体は英語が大半だ。
画像の扱いについて
本記事のバナー画像は、リンク切れ（GitHubの一時画像URLは期限切れになることがある）を避けるため、公式READMEのバナーをローカルに保存して掲載している。最新の状態は必ず公式リポジトリで確認してほしい。
収録されている主要OSS／ツール（カテゴリ別ダイジェスト）
ここがリストの本体だ。数百項目すべては追えないので、カテゴリごとに「代表格」を抜き出す。いずれも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層、というように、自分の症状に対応する部品だけを差し替えていける。
なぜ「awesomeリスト」という形が必要なのか
harness engineeringの情報は、いま爆発的に増えている。AnthropicやOpenAIの公式記事、Microsoft・Googleのエンジニアリングブログ、arXivの新着論文、個人OSS——これらが毎週のように積み上がる。個別検索では、古い記事や重複コンテンツに埋もれて一次情報にたどり着きにくい。
awesomeリストは、この洪水に対する人力のフィルタとして機能する。とくにawesome-harness-engineeringは、収録物に一貫した「読み筋」を与えている点が優れている。
このリストが優れている3つの理由
・一次情報の密度が高い — OpenAIの「Harness Engineering」、Anthropicの「Building Effective Agents」「Effective Context Engineering」、Microsoftの「Azure SRE Agent」事例など、公式の原典に直接リンクしている
・論文とOSSが同居 — ReActやLATSのような基礎論文と、すぐ使えるmem0やpromptfooのようなOSSが同じカテゴリに並び、理論と実装を往復できる
・症状起点で引ける — 「長時間タスクが壊れる」「コンテキストが溢れる」「権限が怖い」といった現場の悩みが、そのままカテゴリ名になっている
ハーネスエンジニアリングという言葉の定義は人によって揺れる。その整理は 5つの流派と設計思想 に譲るが、定義が揺れる分野だからこそ、信頼できるリストが羅針盤になる。
各カテゴリの読みどころ
ここからは主要カテゴリを掘り下げる。すべてREADMEに実在する収録物だけを取り上げる。
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（SWE-benchのサブセットでローカルモデルの通過率を2/10から10/10へ改善）、Claude Codeのエージェントループを別バックエンドへ移植した deepclaude などが収録される。deepclaudeの存在は「エージェントの挙動を決めるのはモデルの正体ではなくループ構造だ」という、harness engineeringの核心を実証する例として面白い。
Planning & Task Decomposition — 長期タスクを分解する
長期・複雑タスクを計画に落とすカテゴリ。Microsoftの TaskWeaver（プランナーとエグゼキューターを分離したコードファーストの分解フレームワーク）、Monte Carlo木探索で推論・行動・計画を統合する LATS、計画と実行を分離する Plan-and-Act（WebVoyagerで81.36%の成功率）などが並ぶ。AnthropicやOpenAIの公式記事も「計画アーティファクト（Plan.md / Implement.md）をharnessの状態として持つ」という具体的な作法を示しており、論文と実務がきれいに対応している。
Tool Design — ツールはエージェントのUX
「ツール設計はエージェントのUXである」という思想のカテゴリ。Anthropicの「Writing Effective Tools for Agents」を筆頭に、デコード段階で出力をJSON Schemaに制約する outlines、PydanticモデルをそのままLLM抽出に対応づける instructor、任意ソフトをエージェント向けCLIに変換する CLI-Anything などが収録される。ツールの命名・スキーマ・エラー表現が、そのままエージェントの成否を左右する——という観点が一貫している。
Context Delivery & Compaction — トークンとの戦い
最も項目数が多いカテゴリのひとつ。コンテキストウィンドウは有限資源だ、という前提で圧縮・供給技術が集まる。MicrosoftのLLMLingua（プロンプトを最大20倍圧縮）、Upstashの Context7（バージョン指定のライブラリドキュメントを注入）、Token Savior（シンボル索引でアクティブトークンを77%削減）、headroom（ツール出力を60〜95%圧縮）など、実測値つきのOSSが揃う。Anthropicの「Compaction」公式ドキュメント（100ターンの検索評価でトークン消費を84%削減）も収録されている。
Skills & MCP — 接続の標準を押さえる
エージェントを外界につなぐプロトコルとツールのカテゴリ。中心はAnthropicの Model Context Protocol（MCP） と公式の modelcontextprotocol/servers。microsoft/playwright-mcp（アクセシビリティツリー経由のブラウザ操作）、Googleの A2A Protocol（エージェント間通信）、250以上のSaaS APIをOAuth込みでラップする Composio などが並ぶ。MCPやSkillの全体像は Claude Code完全ガイド2026 でも触れている。
Memory & State — セッションを越えて覚える
長時間・複数セッションのタスクで効く記憶層。三層メモリの参照実装 Letta（MemGPT）、ドロップイン型の mem0（AWS Agent SDKの標準メモリプロバイダ）、会話要約と意味検索の Zep、グラフ＋ベクトル＋リレーショナルのポリストア cognee などが収録される。「記憶をどう設計するか」はharnessの中核論点であり、論文（MAGMA、GAAMAなど）も併載されている。
Task Runners & Orchestration — 並列と多エージェント
複数のエージェントやモデルを束ねるフレームワーク群。100以上のプロバイダにルーティングする LiteLLM、グラフ状態機械の LangGraph、Microsoftの AutoGen、二層構造の CrewAI、型安全な PydanticAI、22K★超の Mastra などが揃う。Anthropicの「16体のClaudeで並列にCコンパイラを作る」事例も含まれ、オーケストレーションが実用段階にあることを示す。
Permissions & Authorization — 安全に実行する
エージェントに権限を与える際の設計と原典。Anthropicの「Beyond Permission Prompts」、OWASP LLM06:2025（Excessive Agency）、700以上のAPI認証を肩代わりする Nango、ツール呼び出しを実行前に遮断する Open Agent Passport（OAP）（攻撃成功率を74.6%から0%へ）などが並ぶ。自律実行を本番に出すなら、必ず通るべきカテゴリだ。
Verification・Observability — 壊れたら気づく仕組み
評価と可観測性。YAML駆動のLLMテスト promptfoo、多環境ベンチ AgentBench、トレースUIの Langfuse・Arize Phoenix、OpenTelemetryベースの OpenLLMetry など。harnessは「作って終わり」ではなく、評価ループと監視がセットで初めて回る。
Reference Implementations・Templates — 動く見本と雛形
論文や個別OSSだけでなく、まるごと動く参照実装と雛形も収録されている点がこのリストの実用性を高めている。Reference Implementationsはチュートリアル・教材、harnessを生成するメタツール、デモ用harness、隣接コレクションの4系統に分かれる。Templatesカテゴリには AGENTS.md や HARNESS.md、FEATURE_INTAKE.md といった、そのまま自分のリポジトリにコピーして使える雛形が並ぶ。「ゼロから設計する」のではなく「実績のある雛形を写経して削る」アプローチが取れるため、最初のharnessを立ち上げる速度が大きく変わる。
末尾のRelated Awesome Listsからは、MCP・エージェント・プロンプトなど隣接テーマの優良リストへ辿れる。harness engineeringは単独で完結せず、MCPやエージェントフレームワークの知識と地続きだ。リスト同士をハブとして横断できる構造になっているのは、awesome文化ならではの強みである。
自分のプロジェクトでの活用パターン
リストは眺めるためでなく、自分の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・実装手段の地図 | 結局どのツールを使うか決めたい |
コントリビュート方法
awesome-harness-engineeringはCC0のコミュニティリストで、貢献の敷居は低い。新しいOSSや見落とされた論文を見つけたら、誰でも追加提案できる。
プルリクエストを出す流れ
・①フォークする — リポジトリを自分のアカウントにフォーク
・②該当カテゴリに1行追記 — [ツール名](URL) — 一言説明 の形式で、既存項目の書式に合わせる
・③CONTRIBUTING.mdを確認 — 収録基準やフォーマット規約に目を通す
・④プルリクエストを送る — リンク切れ修正や分類改善といった小さな貢献も歓迎される
日本語READMEが用意されている分、日本語話者にとっては貢献のハードルも低い。日本発のharness系OSSや、日本語で書かれた良質な解説記事を見つけたら、それを適切なカテゴリへ追加するだけで、リストの多様性に貢献できる。英語一辺倒になりがちなこの分野で、日本語リソースを可視化する意義は小さくない。
awesomeリストへの貢献は、OSS活動の入り口として最適だ。コードを書かなくても、良質なリソースを1つ見つけて適切なカテゴリに置くだけで、世界中の同じ悩みを持つエンジニアの役に立つ。CC0なので、リストの内容を自分の社内ドキュメントへ転載・改変するのも自由だ。
まとめ：概念から実装への橋渡し
awesome-harness-engineeringは、ハーネスエンジニアリングという抽象概念と、現場で動くOSSの間に架かる橋だ。要点を振り返る。
この記事のまとめ
・awesome-harness-engineeringは ai-boost がCC0で公開する、harness設計のOSS・論文・テンプレ集（★約1,800）
・「モデルではなくharness」に焦点を絞り、20以上のカテゴリで部品を整理している
・Foundationsで原典を押さえ、症状に対応するDesign Primitivesのサブカテゴリへ進むのが効率的
・活用の鍵は「症状の言語化→カテゴリ直行→一次情報→OSS→評価で計測」のループ
・概念の理解は入門・流派整理・完全解説の各記事に譲り、本リストは実装手段の地図として使う
ハーネスエンジニアリングは「モデルが賢いか」より「足回りが信頼できるか」の工学だ。その足回りの部品カタログとして、このリストをブックマークしておく価値は十分にある。まずは自分のいちばん困っている症状を1つ選び、対応するカテゴリを開くところから始めてほしい。モデルは日々賢くなるが、いま手元のエージェントを確実に動かすのは、結局のところ自分で設計したharnessだ。リストはその設計を独力でやらずに済ませるための、先人の知恵の集積である。
関連記事として、概念を基礎から学ぶ ハーネスエンジニアリング入門、定義の違いを整理する 5つの流派と設計思想、内部実装を読み解く ハーネスエンジニアリング完全解説 も合わせて参照してほしい。
参照ソース
・ai-boost/awesome-harness-engineering（GitHub公式リポジトリ） — 本記事の一次情報。README・カテゴリ構成・収録物・ライセンス（CC0）
・GitHub API: ai-boost/awesome-harness-engineering — ★数・フォーク数・更新日時の実測値
</content>
</invoke>
