2．ハーネスエンジニアリングとは何か

ハーネスエンジニアリングは、AIエージェントが安定して成果を出せるように、モデルの外側にある環境を設計する取り組みを指します。ここでいうハーネスとは、AIエージェントを制御し、導き、検証し、必要に応じて修正を促すための環境全体を意味します。

従来の開発では、こうした判断の多くを人間の開発者が暗黙知として担っていました。どのコマンドを実行すべきか、どの設計方針を守るべきか、どの例外処理は見落としてはいけないのかといった判断は、必ずしも明文化されているわけではありません。チーム内の経験や会話、レビューの積み重ねの中で共有されてきました。

しかし、AIエージェントがその暗黙知を最初から理解しているわけではありません。Slackで合意した設計方針や、口頭で共有した注意点も、AIエージェントが参照できなければ、実質的には存在しないのと同じです。

そのため、企業がAIエージェントを本格的に活用するには、人間の暗黙知をAIエージェントが参照し、検証し、実行に移せる形へ変えていく必要があります。この変換の流れをつくることが、ハーネスエンジニアリングの中核です。

3．なぜAGENTS.mdだけでは不十分なのか

AIエージェント向けの指示書として、AGENTS.mdのようなファイルを整備する取り組みは、有効な第一歩です。ビルド手順、テスト方法、コーディング規約、Pull Request作成ルールなどを明示することで、AIエージェントの作業精度は高まります。

ただし、AGENTS.mdに何でも書き込めばよいわけではありません。指示が膨らみすぎると、かえってAIエージェントは重要な情報を見落としやすくなります。また、ドキュメントは放っておくとすぐに古くなります。古い指示が残り続ければ、AIエージェントは誤った前提で作業を続けることになります。

そのため、AGENTS.mdは「すべてを説明するマニュアル」ではなく、「正しい情報にたどり着くための目次」として扱うのが現実的です。詳細なアーキテクチャ、品質基準、設計判断、実行計画、既知の技術的負債は、構造化されたドキュメントとしてリポジトリ内に配置します。さらに、それらのリンク切れや情報の古さ、内容の不整合を、CI（※4）やAIエージェント自身で継続的に確認します。

図1：AGENTS.mdの構成例

これにより、単にドキュメントを置くだけではなく、ドキュメントを参照した結果として、AIエージェントの行動が継続的に変わる状態をつくります。

4．企業システムに求められるハーネスの観点

ここでは、企業がハーネスエンジニアリングを導入する際の観点を、知識、実行、制約、検証、運用の5つに分けて整理します。もちろん、これが唯一の分類というわけではなく、企業システム開発で使いやすい形に整理することもできます。

図2：ハーネスエンジニアリングの全体像

4-1．知識ハーネス

知識ハーネスは、AIエージェントが業務やシステム、設計方針を理解するための情報基盤です。AGENTS.md、ARCHITECTURE.md、設計ドキュメント、API仕様、データモデル、過去の意思決定ログなどが含まれます。

企業システムでは、仕様書や設計情報が複数の場所に散らばっていることも珍しくありません。ファイルサーバー、チケット管理ツール、チャット、個人の記憶に情報が分断されている状態では、AIエージェントは正しく作業できません。AI活用を進める前に、知識ハーネスでまず知識がどこにあるのかを整理し、AIエージェントが参照できる形に整えます。

4-2．実行ハーネス

実行ハーネスは、AIエージェントにどのツールを使わせるのか、どの権限を与えるのか、どの環境で実行させるのかを設計するものです。シェル、ブラウザ、API、MCP（※5）サーバー、ファイルシステム、データベース、クラウド環境、サンドボックスなどが含まれます。

AIエージェントは、ファイルを読み書きし、コマンドを実行し、外部サービスと連携します。そのために、利用可能なツール、実行権限、ネットワーク接続、ファイルシステムの読み書き範囲、認証情報の渡し方を実行ハーネスで明確にします。

特に企業システムでは、開発者端末に存在するSSH鍵、クラウド認証情報、.envファイル、個人情報などへ無制限にアクセスできる構成は避けるべきです。実行ハーネスは、AIエージェントにできることを広げながら、危険な操作や不要なアクセスを防ぐ役割も担います。

4-3．制約ハーネス

制約ハーネスは、AIエージェントに守ってほしい構造やルールを、仕組みとして強制するものです。

たとえば、ドメイン層からUI層への依存方向、特定モジュール間の参照禁止、認証・認可処理の共通化、ログ出力形式、例外処理、個人情報の取り扱いなどが該当します。これらは、文章で伝えるだけではなかなか守られません。リンター、静的解析、構造テスト、CIゲートによって、違反した変更を検知できる状態にします。

AIエージェントは高速にコードを生成できます。その分、誤った構造も一気に広がってしまいます。制約ハーネスがあれば、開発スピードを落としすぎずに品質を守りやすくなります。

4-4．検証ハーネス

検証ハーネスは、AIエージェントが自分の作業結果を確認し、失敗に気づいて修正するためのフィードバックループです。

単体テストや結合テストだけでなく、ブラウザを用いたUI検証、ログ・メトリクス・トレースの確認、セキュリティスキャン、性能評価、アクセシビリティ検査なども含まれます。ここで大切なのは、検証結果を人間だけでなく、AIエージェントにも解釈できる形で返すことです。

検証ハーネスにより、たとえば「テスト失敗」とだけ表示するのではなく、どの仕様に反し、どの修正が必要かを示す。カスタムリンターのエラーメッセージに、修正方針を含める。そうすることで、検証結果は単なる失敗通知ではなく、AIエージェントが自分で修正するための手がかりになります。

4-5．運用ハーネス

運用ハーネスは、AIエージェントによる変更を、本番運用やガバナンスの観点から管理する考え方です。

AIが作成したコードであっても、企業側の説明責任がなくなるわけではありません。どの要件に基づき、どの設計判断を行い、どの検証を通過し、誰が承認したのかを追跡できる状態にします。具体的には、機密情報や個人情報の流出を防ぐ仕組み、利用ルールと承認範囲の明確化、依存関係に起因するリスクの確認、監査や変更管理との接続などが含まれます。また、セキュリティ、監査、変更管理、リリース判定といった既存の運用プロセスとも、無理なく接続できる形にします。

AIエージェントの活用により、開発サイクルが短くなる場面があります。一方で、説明責任と統制が追いつかなければ、システム全体のリスクは増大します。運用ハーネスは、AI-Nativeな開発を企業で安心して使うために欠かせない仕組みです。

5．ハーネスエンジニアリング導入に向けた設計ポイント

ハーネスエンジニアリングは、いきなり全社展開を目指すより、小さく始める方が現実的です。

最初に取り組みやすいのは、繰り返し発生する修正、テスト追加、ドキュメント更新、軽微なリファクタリング、既存パターンに沿った機能追加などです。これらの作業は、成功条件を決めやすく、検証ハーネスもつくりやすい領域です。

次に、AIエージェントがどこで失敗したのかを記録します。間違ったコマンドを実行したのか。仕様の所在を見つけられなかったのか。テストを実行しなかったのか。アーキテクチャ境界を破ったのか。こうした失敗は、単なるプロンプトの問題ではなく、環境設計に足りないものがあったサインとして扱います。

そして、その失敗を1つずつ、再発を防ぐ方法に変えていきます。AGENTS.mdを更新する。テストを追加する。リンターをつくる。ログを読みやすくする。ドキュメントの置き場所を変える。実行計画テンプレートを整える。こうした小さな改善を積み重ねることで、AIエージェントはチームの開発文化を参照し、判断材料として使いやすくなります。

ここで誤解してはいけないのは、人間の役割がなくなるわけではないという点です。むしろ、人間はより重要な判断に集中する必要があります。何をつくるべきか。どのリスクを許容するか。どの品質基準だけは譲れないのか。どの業務知識をAIエージェントに渡すべきか。これらは依然として人間の責務です。

6．まとめ：AI-Native開発に必要なのは、AIを管理する仕組みである

AIエージェントの進化により、システム開発は「人間がコードを書く」ことを中心にした形から、「人間が環境を設計し、AIが実行する」形へと変わり始めています。

この変化は、単なる開発効率化の話にとどまりません。設計情報の管理、アーキテクチャ統制、テスト戦略、セキュリティ、監査、運用、組織知の継承まで含めて、開発プロセス全体を見直すことにつながります。

ハーネスエンジニアリングは、AIエージェントを単なる「便利な補助ツール」ではなく、「企業システム開発を支える実行主体の一部」として位置づけ直すための考え方です。AIの能力を引き出す鍵は、プロンプトをただ長くすることではありません。AIが迷いにくく、危険な動きをせず、失敗から修正でき、説明可能な形で成果を出せる環境をつくることにあります。

自組織でハーネスエンジニアリングを検討するなら、まず次の観点から確認するとよいでしょう。知識がどこにあるかを整理できているか。守るべき制約を仕組みとして強制できているか。検証結果をAIエージェントにも解釈できる形で返せているか。承認や監査の記録を追跡できるか。そして、AIエージェントに入力してよい情報の範囲、つまり機密情報や個人情報の扱いをどう定めるか。これらはモデルの性能とは別に、企業自身が設計しなければならない領域です。

AI-Native開発の成否を分けるのは、モデルの性能だけではありません。自社の知識、制約、検証、運用を、どこまでハーネスとして設計できるかが問われます。