ハーネスエンジニアリングの本質ー従来の開発規律を、エージェントが回せるように再設計する / 開発者向けブログ・イベント

はじめに

こんにちは。GMOインターネットの平野です。

以前、ハーネスエンジニアリングの紹介記事では、ConoHa VPS MCPサーバー開発で実践したハーネスエンジニアリングの具体的な仕組みを紹介しました。「何をやったか」の話です。今回は一段メタな視点で、「なぜそうなるのか」を掘り下げます。ハーネスエンジニアリングとは、結局のところ何をしているのか。その本質と思想を整理します。

本質: 従来の開発規律の再設計

ハーネスエンジニアリングの本質は、新しい規律の発明ではありません。

テスト、CI、リンター、コードレビュー、ADR （Architecture Decision Records）──これらは従来からやるべきだった開発規律です。ハーネスエンジニアリングの新しさは、これらをエージェントが end-to-end で回せるように再設計している点にあります。

4 つの再設計軸

従来の開発とハーネスエンジニアリングの違いを、4 つの軸で整理します。

再設計軸	従来	ハーネスエンジニアリング
実行環境	人間がローカルで実行	エージェントが Hooks・CI で自律的に駆動
知識配置	Wiki等に記述的に蓄積	メタデータ付きのMarkdownファイル
検証ループ	CI → 人間レビュー → 修正	PostToolUse（ms）→ プリコミット（s）→ CI（min）で自己修正
運用経済	人間の時間が律速、慎重にマージ	エージェントの実行時間が律速、「修正は安価、待機は高コスト」

この 4 軸は、ハーネスエンジニアリングを考えるときの基本的なフレームワークになります。

制御なき AI コーディングの課題

ハーネスなしで AI に自由にコーディングさせると、以下の問題が構造的に発生します。

一貫性の欠如: ファイルごとに実装パターンがずれる、命名規約に揺れが出る
アーキテクチャの崩壊: 境界を越えた import が紛れ込む、レイヤー設計が壊れる
技術的負債のサイロ化: エントロピーが増大し、各セッションが独立した負債を生産する

これらは AI の能力不足ではなく、制約の不在が引き起こす構造的問題です。人間の開発者でも、レビューやルールがなければ同様のことが起きます。AI の場合、速度が速いぶん、問題の蓄積も速くなるだけです。

プロンプトの限界とハーネスの複利効果

「AI に良いコードを書かせたいなら、良いプロンプトを書けばいい」──これは直感的には正しく聞こえます。しかし、この方法には構造的な限界があります。

プロンプト依存の限界:

AI に高品質を求めるほど、指示が肥大化する
指示が肥大化するほど、品質担保が「人間がプロンプトを正しく書けたか」に依存する
プロンプトは毎回書き直す消耗品であり、セッションをまたいで蓄積しない

一方、ハーネスは一度作れば繰り返し品質を安定供給できます。たとえば、リンタールールを 1 つ追加すれば、以降すべてのセッションでそのミスが防がれます。

プロンプトは単利、ハーネスは複利です。

もちろん、プロンプトが不要になるわけではありません。プロンプトは「何をつくるか」の方向づけに不可欠です。ただし、「どう品質を守るか」をプロンプトに頼り続けるのは、スケールしない方法だということです。

6 つの核心原則

ハーネスエンジニアリングの設計を支える原則を 6 つに整理します。

品質の源泉は「仕組み」: プロンプトではなく、ハーネスで品質の不確実性を除去する
速度こそが品質: フィードバックループの速さが品質を規定する。ms 単位でエラーを発見できれば、修正コストは限りなく小さくなる
制約がエージェントを導く: 自由度ではなく「制約」で一貫性と予測可能性を両立させる
ルールは陳腐化が前提: ルールの鮮度の自動検証、AI レビューを実施する
機械的に検証しづらい品質も測る: 機械的に検証しづらい品質基準も言語化し、AI に提供することで、機械的検証の死角をカバーする
自律に耐えうる設計: ルール自体の運用（追加・変更・廃止）を、エージェントが実行できるように明示する

原則 6 は特に重要です。ルールを作るだけでなく、ルールのメタ運用自体もエージェントが参加できるよう設計する。これによって、ルール体系そのものが自律的に進化し続けるための土台ができます。

広義と狭義のハーネスエンジニアリング

広義: 3 つの柱の統合

ハーネスエンジニアリングを広義に捉えると、3 つの柱で構成されます。

コンテキストエンジニアリング ──エージェントに「何を守るべきか」を正しく伝える

CLAUDE.md の設計（50行以下、詳細はオンデマンドロード）
計画と実行の分離（エージェントに計画を立てさせ、人間がレビューしてから実行）
Skillsやコーディングパターンのドキュメントのメタデータ設計

ハーネス（制約） ──不変条件を機械的に検証し、違反をブロックする

リンター、テスト etc…
Hooks による開発時ガード
構造テストによるアーキテクチャ不変条件の固定

ガベージコレクション ──ルール体系そのものの劣化を検知し、鮮度を保つ

ルールの鮮度チェック
ADR によるルール変更経緯の記録

この 3 つの柱は独立しているのではなく、互いに依存しています。コンテキストエンジニアリングがなければ制約は伝わらず、制約がなければ品質は守れず、ガベージコレクションがなければ制約は陳腐化します。

狭義: 制約で狭める

狭義のハーネスエンジニアリングは、2 番目の柱──制約による品質担保──に焦点を当てます。

エージェントの解決空間を広げるのではなく、狭めることで一貫性と予測可能性を高める
「自由にやらせて後でレビュー」ではなく、「最初から選択肢を絞り、逸脱を即座に検知」
制約がエージェントを弱くするのではなく、制約がエージェントを強くする

ここでのポイントは、今すぐ機械で判定できないルールであっても、言語化しておく価値があるということです。定義さえあれば、将来のツール改善によって自動化が可能になります。定義がなければ、永遠に暗黙知のまま残ります。

運用思想: 人間とエージェントの役割分担

人間の役割──方向づけと判断

優先順位付け: 何を先にやるか、何を後回しにするか
受け入れ基準の定義: 完了条件を曖昧にせず言語化する
成果検証: エージェントの出力が意図と合致しているか確認
例外判断: ルールから外れるべきケースの判断（ADR として記録）

人間は主にプロンプトで方向づけし、エージェントが実装・レビュー対応・修正まで進めます。

エージェントの役割──実行と自己修正

エージェントは、人間が設計した制約の中で、end-to-end の実行ループを自律的に回します。

実装
レビュー指摘への対応
テスト修正

重要なのは、エージェントに「何でもできる自由」を与えることではなく、「制約の中で確実に動ける仕組み」を提供することです。

暗黙知の排除原則

すべてのルールはまず知識として全情報をAIに渡します。人間だけが感覚で知っている状態を排除する──これが運用思想の根幹です。

人間が暗黙的に持っている品質基準を、明示的に言語化してAIに渡す
「わかっているはず」「常識だろう」という前提を排除し、すべてを機械可読な形で記述する

暗黙知の排除は、AI のためだけの施策ではありません。新しいチームメンバーのオンボーディングにも、同じ形で効きます。

運用経済: 「修正は安価、待機は高コスト」

従来の開発では、人間の時間が最も高コストでした。だからこそ「慎重にレビューし、確実にマージする」ことが合理的でした。

エージェント駆動開発では、この経済構造が反転します。

観点	従来の開発	エージェント駆動開発
最も高コストなもの	人間の時間	エージェントの待機時間
マージ戦略	慎重にレビューを行う	お客様影響がないと言い切れるものはレビューを最小限にし、スループットを上げる

この経済観から導かれる設計判断

人間の承認待ちがボトルネックにならないよう、自動マージ可能な範囲を広げる
フィードバックループの高速化を行うために、PostToolUse（ms）で直せるものを CI（min）まで待たせない

フィードバック速度のパラダイムシフト

従来は人間によるレビュー（数時間）が品質の最終防衛線でした。ハーネスエンジニアリングでは、この防衛線をツール実行（数ミリ秒）へシフトさせます。

レイヤー	速度	性質
PostToolUse	ms	機械的・即時
Pre-commit	s	ローカル環境
CI	min	リモート環境
Human Review	h	人間的・遅延

CI で落ちてから気づくのではなく、開発ループの中で「その場で正される」即効性が品質を生みます。できるだけ多くのチェックを、最も速いレイヤー（ms）に移動させることがハーネス設計の基本原則です。

まとめ

ハーネスエンジニアリングの本質は、「新しい規律の発明」ではなく「既存の開発規律を、エージェントが回せるように再設計すること」です。この記事の要点を 2 つに整理します。

1. 制約がエージェントを強くする

エージェントの能力を引き出すのは自由度ではなく制約です。制約を強め、逸脱を即座に検知する仕組みが、一貫性と予測可能性を生みます。プロンプトによる毎回の指示（単利）ではなく、ハーネスという仕組みへの投資（複利）が、長期的に品質を安定させます。

2. 暗黙知を排除し、すべてを機械可読にする

人間だけが感覚で知っている状態を排除し、ルールを明示的に言語化する。今すぐ自動化できなくても、デジタルで定義しておくことで、将来の自動化への道が開けます。ルールの追加・変更・廃止というメタ運用も含めて、機械可読に設計することが、自律的に進化するルール体系の土台になります。

以前紹介した記事の実践は、この思想の具体的な表現です。個々のテクニックとして消費するのではなく、「従来の開発規律の再設計」というフレームで捉えることで、自分たちのプロジェクトに合った仕組みを設計するヒントになれば幸いです。

また、ハーネスエンジニアリングについての弊社の取り組みについて、インタビュー記事も公開されました。よかったら合わせてご覧いただけますと幸いです。

ブログの著者欄

平野空暉

システム本部

入社以来、ConoHa・お名前.comにおけるAI関連の企画・開発に従事。生成AI関連のサービスを複数手がけるほか、社内開発におけるAIネイティブな開発スタイルを提案・実践中。プロトタイプ開発やフロントエンドの UX 改善、パフォーマンスチューニングに特に関心を持つ。

ブログ記事一覧へ

採用情報

KEYWORD

CATEGORY

KEYWORD

YEAR/MONTH

AUTHOR

SNS FOLLOW

OLD REPORT

TAG

ハーネスエンジニアリングの本質ー従来の開発規律を、エージェントが回せるように再設計する

はじめに