ハーネスエンジニアリング on hdknr blog

Claude Harness

Mon, 27 Apr 2026 00:00:00 +0000

Claude Code の拡張機構（hooks / permissions / skills / MCP）をワンパッケージで組み込んだ外装プラグイン。v4.0.0 "Hokage" で Go ネイティブ化・harness.toml 1 本管理を実現

Graphite

Thu, 23 Apr 2026 00:00:00 +0000

スタックドPR・マージキュー・AI コードレビューで AI ファースト開発を加速する GitHub PR ワークフロー拡張プラットフォーム

エージェントハーネスとユーザーハーネス — ハーネスエンジニアリングの全体像を正しく理解する

Thu, 23 Apr 2026 00:00:00 +0000

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 の「制御ループ」はエージェント実装寄り。「そもそも新しい概念ですらない」と言う人もいる。さらにベンダー（作り手）と利用者（使い手）で意味が違うという構造的な問題もある。

Graphite 徹底解説 — スタックドPRとマージキューがAIファースト開発を加速する理由

Sun, 19 Apr 2026 00:00:00 +0000

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つしかない。

「AIファースト」戦略の本当の意味 — ハーネスエンジニアリングで25人チームが6週間を1日に短縮した方法

Fri, 17 Apr 2026 00:00:00 +0000

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に集中し続けることは不可能だ。これはサジェスチョンではなくレビューゲートである。