ハーネスエンジニアリング

概要 Claude Code の拡張機構（hooks / permissions / plugin system / skills / MCP）を AI エンジニアが自作で組むと数日かかる設定を、インストール 1 回で手元に落とせる外装プラグイン。GitHub リポジトリ: Chachamaru127/claude-code-harness Claude Code には強力な拡張機構があるが、plugin.json / hooks.json / settings.json / .mcp.json / .claude-plugin/hooks.json の 5〜6 本の JSON を整合させながら自律運用のワークフローを組むのは現実的でない。Harness はこれを 1 パッケージで提供する。 v4.0.0 “Hokage” の主な変更点（2026-04-14） 改善点 Before After フック実行速度 ~300ms（bash → Node.js → TypeScript 3段ロケット） ~10ms（Go バイナリ 1 本、30 倍速） 設定ファイル数 5〜6 本を手動整合 harness.toml 1 本（SSOT） ガードレール R12 warn deny + Bash bypass 二重防御 Node.js 必要 不要（ネイティブバイナリ 3 本で配布） Go ネイティブ化の詳細 pure-Go SQLite（modernc.org/sqlite）採用で Node.js ランタイム要件を完全排除 bin/harness が hooks.json から直接呼ばれ、フック 1 回 ~10ms bin/harness sync で plugin.json / hooks.json / settings.json が全整合 harness.toml による SSOT 1 2 3 # harness.toml を書いて $ bin/harness sync # plugin.json / hooks.json / settings.json が全て整合 ガードレール強化 R12（保護ブランチへの直接 push）を deny に格上げ Claude Code 2.1.98 で発見された Bash permission bypass 2 種をハーネス側で二層目として塞ぐ defense in depth: CC 本体が塞いだ穴を Harness が再度塞ぐ構造 インストール Claude Code v2.1.92 以上が必要。 ...

概要 Graphite は GitHub 上の PR ワークフローを拡張する開発者プラットフォーム。2025年3月に Anthropic から $52M の Series B を調達。元 Airbnb・Meta エンジニア出身チームが、Meta 内部ツール（Phabricator/Sapling）のスタック開発体験を GitHub に持ち込んだ。AI が大量に PR を量産する「AI ファースト開発」環境での詰まりを解消する。 3本柱 1. スタックドPR 大きな変更を依存関係のある小さな PR の連鎖に分割する。DB スキーマ→API→認証ミドルウェアのような依存チェーンを独立した PR として管理し、レビュアーの認知負荷を下げる。 1 2 3 gt stack # 現在のスタック状態を確認 gt submit # スタック全体を一括 PR 作成 gt sync # main の変更を全 PR にリベース 2. マージキュー（スタック対応） スタックの依存関係を理解した上で main へのマージを直列化。CI が通ったものから順番にマージされるため、コンフリクトなしに高頻度デプロイが可能になる。 3. Graphite Agent（旧 Diamond） AI によるコードレビューと対話的修正。差分を理解した上でコメントし、Chat で修正まで完結できる。 ...

r.kagaya 氏（@ry0_kaga、AstarMinds CTO）が Zenn に公開した記事がある。「ハーネスエンジニアリングとは何で、何ではないのか 〜作る側のハーネス、使う側のハーネス〜」という記事だ。ハーネスエンジニアリングをめぐる言葉の混乱を整理し、エージェントハーネスとユーザーハーネスという2層の区分を提示している。 CLAUDE.md や Skills を書けば「ハーネスエンジニアリングをやっている」と言える。でも、それはハーネスエンジニアリングの全体ではない。この記事ではその全体像を整理する。 そもそも「ハーネス」の定義が割れている 前提として、ハーネスエンジニアリングという言葉には統一された定義がない。同じ言葉を使いながら、各社・各人が指しているものが違う。 用語の来歴 「ハーネス」の原義は馬具だ。馬を馬車に繋ぎ、方向を制御し、力を伝達する装備。ソフトウェア文脈では 2020 年の lm-eval-harness（言語モデル評価ハーネス）が初出とされる（r.kagaya 氏による整理）。2024 年に All Hands AI / OpenHands が「エージェントハーネス」に拡張。2026 年に Mitchell Hashimoto（Terraform 創業者）が「Engineer the Harness」と命名し、OpenAI の記事で広まった。 各社の定義 誰が 何と言っているか LangChain (Vivek Trivedy) 「Agent = Model + Harness。モデルでなければハーネス」 Anthropic 「LLM を呼び出し、ツールコールをルーティングする制御ループ」 OpenAI 宣言的制約 + サンドボックス + スケーリング Böckeler / Martin Fowler サイバネティクス的制御。フィードフォワード × フィードバック Phil Schmid (Hugging Face) Model = CPU, Harness = OS Bedi (Composio CEO) 「システムエンジニアリングのサブセットに新しい名前をつけているだけ」 LangChain の「モデルでなければハーネス」は極めて広い。Anthropic の「制御ループ」はエージェント実装寄り。「そもそも新しい概念ですらない」と言う人もいる。さらにベンダー（作り手）と利用者（使い手）で意味が違うという構造的な問題もある。 ...

CreaoAI が25名で6週間のリリースサイクルを1日に短縮した事例では、PR 管理ツールとして Graphite が採用されていた。1日8回デプロイ・AI が大量に PR を量産する運用で、素の GitHub PR フローは何が詰まり、Graphite は何を解決するのか。本記事では Graphite の3本柱（スタックドPR・マージキュー・AIレビュー）を、CLI コマンドと具体的な運用シナリオで解説する。 Graphite とは Graphite は GitHub 上の PR ワークフローを拡張する開発者プラットフォーム。2025年3月に Anthropic から $52M の Series B を調達し、同時に AI コードレビュー「Diamond」をローンチした（現在は Graphite Agent に名称統合）。元 Airbnb・Meta のエンジニア出身チームが、Meta 内部で使われていた Phabricator / Sapling 的なスタック開発体験を GitHub に持ち込んだのが出発点だ。 主要機能は3つに整理できる。 スタックドPR — 大きな変更を依存関係のある小さな PR の連鎖に分割する マージキュー — スタックを理解した状態で main にマージを直列化する（stack-aware） Graphite Agent（旧 Diamond）+ Chat — AI によるコードレビューと対話的修正 スタックドPR：大きな差分を「小さなレビュー単位の連鎖」に分解する 何が問題だったのか AI エージェントや生産性の高い開発者は、1つのフィーチャーを実装する過程でしばしば以下のような複数階層の変更を生む。 DBスキーマの追加 それを使う API エンドポイント 認証ミドルウェアの更新 フロントエンドの呼び出し 従来の GitHub PR モデルだと選択肢は2つしかない。 ...

MetaのGenAIチーム（LLaMA）出身のCo-FounderであるPeter Pang（@intuitiveml）が率いるエージェントプラットフォーム企業CreaoAI（25名）が、「AIファースト」を本気で実践した結果、コードの99%をAIが書き、かつてのリリースサイクル6週間を1日に短縮した方法を解説している。 元記事タイトルは “Why Your ‘AI-First’ Strategy Is Probably Wrong”。@SuguruKun_ai がX（旧Twitter）のスレッドで日本語解説している。 AIを「導入した」会社と「前提に組み直した」会社の違い 多くの企業は既存のプロセスにAIを乗せています。エンジニアがCursorを開き、PMがChatGPTで仕様書を書く――ワークフローは変わらず、効率が10〜20%上がるだけです。 AIファーストとはまったく別物です。AIファーストとは、「AIがメインのビルダーである」という前提でプロセス・アーキテクチャ・組織を再設計することです。「どうすればAIがエンジニアの役に立てるか？」ではなく、「どう再構築すればAIがビルドし、エンジニアが方向と判断を提供できるか？」という問いです。 ハーネスエンジニアリングとは何か OpenAIが2026年2月に発表した概念で、CreaoAIが実践の中で独自に到達していたアプローチと一致しました。 エンジニアリングチームの主な仕事はもはやコードを書くことではなく、エージェントが有用な作業を行える「環境（ハーネス）」を整えることである。 失敗が起きたとき、解決策は「もっと頑張れ」ではなく「どのケイパビリティが欠けているか、エージェントにとって読み解けるようにするにはどうすればよいか」を問うことです。 3つのボトルネックを解消した CreaoAIはAI移行前に3つの深刻な問題を抱えていました。 ① プロダクトマネジメントのボトルネック エージェントは2時間でフィーチャーを実装できます。数週間の計画サイクルがボトルネックになります。仕様書レビューではなく、プロトタイプ→リリース→テスト→反復のループで動く必要があります。 ② QAのボトルネック ビルド時間2時間・テスト時間3日では話になりません。AIが書いたコードをAIが構築したテストプラットフォームで検証し、バリデーションを実装と同速度で動かします。 ③ ヘッドカウントのボトルネック 競合は100倍の人員。CreaoAIは25名。採用では追いつけないため、設計で追いつく必要がありました。 アーキテクチャ統合：モノレポへ移行した理由 複数リポジトリにまたがる変更はAIエージェントにとって「不透明」でした。AIは全体像を把握できず、クロスサービスの影響を推論できません。 モノレポへ統合した一番の理由：AIがすべてを見られるようにするため。 ハーネスエンジニアリングの原則では「エージェントが検査・検証・変更できる形にコードを引き込むほどレバレッジが増す」とされる。1週間かけて新設計を策定し、さらに1週間でエージェントを使ってコードベース全体をリアーキテクチャした。 技術スタック詳細 インフラ：AWS 自動スケーリングのコンテナサービスとサーキットブレーカーロールバックで運用。デプロイ後にメトリクスが劣化すると自動でリバートします。CloudWatchを中枢神経系として使い、25以上のアラームとカスタムメトリクスで全サービスから構造化ログを収集します。 CI/CD：GitHub Actions（6フェーズ） 1 Verify CI → Build/Deploy Dev → Test Dev → Deploy Prod → Test Prod → Release CIゲートは型チェック・リント・ユニットテスト・統合テスト・Dockerビルド・Playwright E2Eテスト・環境パリティチェックをすべて必須で実施。手動オーバーライドは存在しない。パイプラインが決定論的であるため、エージェントが結果を予測して障害を推論できる。 AIコードレビュー：Claude Opus 4.6 PRのたびに3つのClaudeレビューパスを並列実行します。 コード品質 — ロジックエラー、パフォーマンス問題、保守性 セキュリティ — 脆弱性スキャン、認証境界チェック、インジェクションリスク 依存関係スキャン — サプライチェーンリスク、バージョン競合、ライセンス問題 1日8回デプロイする状況で人間レビュアーがすべてのPRに集中し続けることは不可能だ。これはサジェスチョンではなくレビューゲートである。 ...