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

ハーネスは、AIを支え、制御する装置である

ハーネス（harness）は、もともと装備や馬具を指す言葉であり、現在では、人や動物を支え、動きを制御する装具などを意味する。共通するのは、対象を外部から支え、目的に沿って働けるようにする点である。AIの文脈ではThoughtworksのDistinguished EngineerであるBirgitta Boeckeler氏が、2026年4月2日にMartinFowler.comで公表した記事において、業界で広がりつつある用法を「AIエージェントのうち、モデル以外のすべて」と整理している。

エージェント ＝ モデル ＋ ハーネス

モデルが頭脳なら、ハーネスは、その頭脳に情報を渡し、道具を使わせ、行動範囲を定め、結果を点検する周囲の装置一式である。指示、参照データ、ツール、接続先、権限、処理の流れ、検証、ログ、停止や復旧の仕組みなどが含まれる。Boeckeler氏の記事は主としてコーディングエージェントを対象としており、ハーネスの要素を二つに整理している。

• ガイド：行動前に、必要な情報や規則を与えて方向づける。
• センサー：行動後の結果を点検し、自己修正、停止または人への引継ぎを促す。

これらには、テストやリンターのように機械的に判定するものと、AIレビューのように推論を伴うものがある。重要なのは、AIへの指示だけでなく、AIが動く環境全体を設計対象とすることである。

外部事業者のクローズドモデルでは、内部構造や学習データを利用企業が全面的に確認することは難しい。一方、使用するモデル、接続するデータ、付与する権限、検証、監視、停止条件など、利用システム側には自社がより直接的に統制できる余地がある。ハーネスエンジニアリングとは、この領域を意図的に設計し、維持することである。

AIを囲む4本の柵

逸脱の類似事例検索を例にすると、ハーネスによる統制は、例えば次の4群に整理できる。

1. データと接続先
   参照できる情報を、逸脱データベースの所定期間と承認済みSOPに限定する。外部サイト、未承認文書、権限外のデータベースには接続させず、入力データが外部事業者のモデル学習に使われないことも確認する。
2. 権限と禁止動作
   AIには検索と候補提示に必要な最小限の権限だけを与える。原記録の削除・更新、逸脱分類や原因の最終決定、承認、電子署名などは実行できないようにする。
   重要な禁止事項は、「しないでください」というプロンプト上のお願いだけに依存させない。技術的に強制できるものは、可能な限りシステム側で制限する。
3. 受入基準と停止条件
   必須項目の欠落、無効な記録番号、参照先との不整合などを機械的に点検し、不合格なら次の処理へ進めない。原記録への参照不能、未許可データへのアクセス、検証機能やログの停止などが生じた場合は、自動処理を止めて人へ引き継ぐ。
   「8項目のチェック」「参照不能が20％を超えたら停止」といった数値を用いる場合、それらは規制上の標準値ではなく、意図した用途とリスクに基づいて設定する設計値である。分母、集計単位、評価期間、閾値の根拠も定めなければならない。
4. 記録と通知
   誰が、いつ、どのモデル、設定、指示、参照データを使い、何を実行し、どの結果を得たかを再構成できる記録を残す。停止または重大な異常が発生した場合は、適格かつ権限を有する担当者へ通知する。
   ただし、一般的なシステムログが、そのままGxPの監査証跡になるわけではない。目的とリスクに応じて、帰属性、時刻同期、完全性、改変防止、保存期間、アクセス制限およびレビュー方法を確認する必要がある。

既存の品質システムで理解できる

ハーネスエンジニアリングの構成要素の多くは、既存の品質システムと比較して理解できる。

• AGENTS.mdやCLAUDE.mdなどの指示ファイルは、作業指示やチェックリストに似ている。
• 自動テストや評価は、検証試験や受入試験の証拠になり得る。
• リンターは、書式や規約の自動点検に相当する。
• 権限と接続先の制限は、アクセス管理や職務分掌に対応する。
• エスカレーションは、例外処理や逸脱報告に近い。
• ハーネスの変更は、変更管理と影響評価の対象になる。

ただし、これらは機能上の類似であって、同一概念ではない。指示ファイルは、承認、版管理、発効日などを管理しなければSOPと同等にはならない。自動テストも、それだけでOQやPQになるのではなく、要求、リスク、期待結果、逸脱処理、レビューなどを含む検証活動の一部である。

また、実行ログは監査証跡を構成し得るが、必要な要件を満たしているかを別途評価しなければならない。ロールバックは技術的な復旧手段であり、原因分析、影響評価、承認、有効性確認を含む変更管理やCAPAそのものではない。要点は、AIのために品質管理をゼロから発明することではない。既存の品質システムを土台にしながら、モデルの非決定性、プロンプトや参照情報による挙動変化、モデル更新、外部サービスへの依存といったAI固有の論点を追加することである。

ハーネス自体も検証する

「AIの出力が正しいか」と「ハーネスが意図どおりに働くか」は別の問題である。AIが提示した類似逸脱を人が妥当と判断しても、それだけでは、権限制御、停止条件、通知、ログ、接続制限が正しく作動していることの証明にはならない。反対に、技術的統制が正常でも、AIの判断内容が業務上妥当とは限らない。稼働前、重要な変更後および定期的な評価では、少なくとも次を確かめる。

• 不合格データを受入基準が検出できるか。
• 禁止動作を実際に実行できないか。
• 停止条件が想定どおり発火するか。
• 通知が所定の担当者へ届くか。
• ログから処理を再構成できるか。
• バックアップから復旧できるか。
• 再開権限が指定担当者に限定されているか。

停止条件をSOPに書いただけでは、実際に停止できる保証にはならない。火災報知器を設置しても、鳴るか、通知が届くか、その後に対応できるかを点検しなければならないのと同じである。検証の深さは用途とリスクで決める。AIが候補を示し、人が原記録を確認して判断する用途と、AIの結果が正式記録、製品品質判断、出荷判定または患者安全へ直接影響する用途を、同じ管理水準で扱ってはならない。

供給者とモデルの変更も管理する

モデルやクラウドサービスは、利用企業の都合とは無関係に更新または停止する可能性がある。そのため、供給者評価、責任分担、モデルとAPIの版、変更通知、データ利用条件、障害時の代替手順、契約終了時のデータ処理などを管理対象に含める。「一度検証したモデルは、その後も同じ」とは考えない。使用しているモデルとサービスを識別し、変更を検知し、意図した用途への影響を評価し、必要に応じて再試験または再検証できる仕組みが必要である。

おわりに

ハーネスエンジニアリングとは、AIへ上手な指示を書くことだけではない。モデルの周囲にあるデータ、ツール、権限、検証、記録、停止、人への引継ぎ、復旧および供給者管理を、一つの利用システムとして設計することである。GxPの観点から見れば、意図した用途を定め、リスクを評価し、権限を制限し、試験し、記録し、変更を管理し、例外時に人が責任を持って判断するという基本は変わらない。

信頼できるAI利用は、モデルの性能だけで決まるものではない。AIがどの情報を使い、何を許され、どのように点検され、いつ停止し、誰へ引き継がれるのか。その周囲に構築したハーネスの品質が、実用上の信頼性を左右する。

参考資料

• Birgitta Boeckeler, “Harness engineering for coding agent users,” MartinFowler.com, 2 April 2026: https://martinfowler.com/articles/harness-engineering.html
• Thoughtworks, “What is harness engineering?”, 14 May 2026: https://www.thoughtworks.com/en-us/insights/podcasts/technology-podcasts/what-harness-engineering
• European Commission, EudraLex Volume 4, Annex 11, “Computerised Systems”: https://health.ec.europa.eu/system/files/2016-11/annex11_01-2011_en_0.pdf
• U.S. FDA, “Computer Software Assurance for Production and Quality Management System Software”: https://www.fda.gov/media/188844/download
• NIST, “Artificial Intelligence Risk Management Framework (AI RMF 1.0)”: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf

この分野の解説動画