賢いAIほど、それぞれの正解を作ってしまう ― AIエージェントを成果に変えるAgent Harness Architecture

AIの導入は済んだのに、成果が個人の手元にしか残らない。組織を分けているのはモデルの性能ではなく、AIに目的と制約と参照先と検査を与える器、つまりHarnessを持っているかどうかです。

ただし、器を一つ作るだけでは足りません。上流の体験戦略と接点設計にも、下流のコンテンツ・デザイン・実装にも、それぞれの器が要ります。その縦と横をどうつなぐかを決めるのが、Agent Harness Architectureです。

この記事では、当社が実際に使っている定義から、上流と下流をつなぐ構造正本、人と機械の関門の置き分けまでを通して書きます。専門的な用語が続きますが、初出には日本語の意味を添えました。

目次

• AIを入れたのに、成果が組織に積み上がらない
• Harness（器）とAgent Harness Architecture（器をつなぐ設計）
• Harnessが最低限持つべき8つの要素
• Design Agent Harnessだけでは、Touchpoint（顧客との接点）は作れない
• 各Harnessが参照する正本、Standards / Knowledge Layer
• 上流と下流をつなぐのは、文章ではなく構造正本です
• Standards、Findings、Gapsを分ける
• Human Gate（人が決める関門）とQuality Gate（機械が通す検査）を、あらかじめ置く
• 定義を書くことと、動くものを残すことは別です
• Moat（模倣されにくい堀）は、Experience Intelligenceに宿る

AIを入れたのに、成果が組織に積み上がらない

生成AIの導入そのものは、もう済んでいる会社が多いのではないでしょうか。全社にアカウントを配り、プロンプト集を共有し、社内勉強会も開いた。個人の作業は確かに速くなった。それなのに、組織としての成果になっているかと問われると言葉に詰まる。DXやAI推進を担当されている方から、こういう話をよく伺います。

なぜ、こうなるのでしょう。AIをうまく使える人が「うまく使えている」だけで、その使い方が仕事の仕組みとして定着していないからです。腕のいい担当者が、頭の中にある目的と制約をその都度プロンプトに流し込み、出てきたものが良いかどうかもその人の目で判断している。属人的な職人仕事が、速い道具を得て、より速い職人仕事になっただけの状態です。

ここで効いてくるのは、モデルの性能ではありません。同じモデルを使っても、成果が積み上がる組織と積み上がらない組織に分かれます。分けているのは、AIに「何を目的に、どんな制約の中で、何を参照して、どこまで自分で判断してよいか」を与える器と、その器をどう組み合わせて仕事を回すかの設計です。前者はHarness（ハーネス）と呼ばれ、AIエージェントの分野ではすでに一般的な言葉です。当社が言いたいのはその先で、Harnessを縦にも横にも置き、つなぎ方まで含めて設計したものをAgent Harness Architecture（エージェント実行基盤の設計思想）と呼んでいます。

Harness（器）とAgent Harness Architecture（器をつなぐ設計）

Harnessは、もともと馬具のことです。馬そのものを強くする道具ではありません。馬の力を、行きたい方向に、壊さずに伝えるための装置です。ソフトウェアの世界にはコードを走らせて期待値と突き合わせるtest harnessという言い方が先にあり、AIの分野で使われるHarnessもその延長にあります。どちらの由来も、力を足すのではなく、力を方向づけて確かめる装置だという点では同じです。

用語を整理しておきます。Agent（エージェント）は、限定された役割を持ち、入力を受けて判断または生成を行う実行主体です。ここで言うAgentは、自分で判断して動き続ける自律型のものに限りません。決められた順序の中で一区切りの仕事をするものも含みます。Skill（スキル）は、そのAgentが呼び出す再利用可能な作業単位、たとえば競合分析や表記チェックのような一つひとつの仕事です。なお、いまSkillという語はAgent Skillsという具体的なフォーマットの名前としても使われていますが、ここで言うSkillはその形式ではなく、作業単位という意味です。

Harnessは、Agentに目的、文脈、制約、参照知識、Tool、検証、Human Gate（人が決める関門）、フィードバック経路を与え、案件の目的に沿って働かせる仕組みを指します。一般には Agent = Model + Harness という形で、モデルの推論以外、つまりTool実行、メモリ、状態保持、実行環境、安全制御を担う層として説明されます。当社の定義は、そこに案件設計の要素を足したものです。そして複数のHarnessを起動し、依存関係、順序、分岐、統合、差し戻しを管理する層をOrchestration（統制層）と呼びます。

ここからが本題です。Harnessを一つ作ることと、Agent Harness Architectureを持つことは、まったく別のものです。

Harnessは器です。一つの領域についてAIが自社らしい出力を安定して出せるようにする。有用ですが、単体では点にとどまります。Agent Harness Architectureは、案件の条件から必要なHarnessを選び、依存関係と順序を決め、共通に参照するStandardsを置き、Quality Gateで検査し、落ちたらどの層へ差し戻すかを決め、終わったあとに学びを次の案件へ返す。その全体の設計思想です。

比喩を続けるなら、Harnessは馬具で、Architectureは馬車と御者と道の設計です。良い馬具をいくつ揃えても、それだけでは荷物は目的地に着きません。ツールを増やしても成果が積み上がらないのは、たいてい器が足りないのではなく、器をつなぐ設計が無いからではないでしょうか。

Harnessが最低限持つべき8つの要素

Harnessはプロンプト集ではありません。プロンプトは指示ですが、Harnessは、入力が足りているかを問い返す仕組み、出力を機械的に検査する仕組み、落ちたときに誰へ戻すかの経路までを含みます。当社では、Harnessが最低限持つべきものを8つに定めています。Input（入力）、Output（出力）、Questions（不足を検出する確認質問）、Process（進め方）、Standards（参照する正本）、Quality Gate（機械で通す品質検査）、Risk / Guardrail（やらないことの線引き）、Learning（学びの戻し先）です。

このうち現場で一番抜けやすいのが、QuestionsとLearningです。前者が無いとInputが足りないまま生成が走り、後者が無いと成功も失敗も次の案件に届きません。そして学びを戻す先があるということ自体が、Architectureを前提にしています。

Design Agent Harnessだけでは、Touchpoint（顧客との接点）は作れない

いま話題になりやすいのは、デザイン領域のHarnessです。自社のデザインルールや判断基準をAIが参照できる状態に整えて、自社らしい表現を安定して出せるようにする。有用な取り組みだと思います。

ただ、それだけで顧客のTouchpoint（顧客との接点）が作れるわけではありません。Design Agent Harnessが担保するのは、出てきたものの一貫性です。そもそも「誰の、どの状態を、どの方向へ変えるのか」「その変化をどの接点が担うのか」が決まっていなければ、一貫してはいるけれど狙いから外れたものが、速く大量に出てくることになります。

しかも、上流が曖昧なまま下流を走らせると、その曖昧さは消えずに、揺れ幅として増幅されて出てきます。Experience Strategyの解釈が二通りありうるなら、Touchpointの設計は四通りに割れ、制作物は八通りになる。人がやっていた頃は、その揺れを経験のある担当者が途中で吸収していました。AIは吸収しません。指示された範囲で、それぞれもっともらしいものを作ります。

ですから縦方向に、上流にもHarnessが要ります。市場・競争・顧客・事業目標から「誰の、どの状態を、どの方向へ変えるべきか」を決めるExperience Strategy Harness（体験戦略の器）。その結論を、ジャーニー、タッチポイントの役割、情報構造、機能、コンテンツ要件、評価指標へ変換するTouchpoint / UX Planning Harness（接点とUX設計の器）。上流のHarnessが出すのは制作物ではなく、下流の判断基準です。

足りないのは、縦だけではありません。横方向、つまり同じProduction Harnesses（制作の層）の中でも、Design Agent Harnessの隣にContent Agent Harness（言葉の器）とCoding Agent Harness（実装の器）が要ります。Content Agent HarnessはBrand Voice（ブランドとしての語り口）、根拠、権利、チャネル制約、SEO / GEO要件（検索エンジンと生成AI経由の流入への対応）を参照して一貫性と事実性を検証し、Coding Agent HarnessはEngineering Standards、Architecture、Security、Performance、Accessibility、Testing、Deployment条件を参照して生成・レビュー・テスト・修正を反復します。参照するStandardsも検査の仕方も違うので、それぞれに器が要ります。

しかもこの3つは、直列の受け渡しではありません。ContentがLayout制約を受け、Designが実装可能性を受け、Codingの結果がDesignとUXへ戻る双方向の関係です。双方向に動くからこそ、3つが共通に読む一つの参照物が要ります。

つまりHarnessは、縦にも横にも要るということです。そして、この縦と横をどうつなぐかを決めるのがAgent Harness Architectureです。

各Harnessが参照する正本、Standards / Knowledge Layer

上流のHarnessや抽出の工程が出すものには、名前が付いています。Design System（意匠の型）、Content System（言葉の型）、Engineering Standards（実装の型）です。Design Systemはトークン、コンポーネント目録、レイアウト規則、ブレークポイント。Content Systemは用語集、表記の正、禁止語、ボイス、スロット字数レンジ、メタ・URL規約。Engineering Standardsはスタック、ディレクトリ、命名、実装規約、性能・アクセシビリティ基準です。

この3つが、当社がStandards / Knowledge Layer（各Harnessが参照する正本の層）と呼ぶものを構成します。ここはHarnessそのものではなく、各Harnessが参照する正本です。下流のAgentは、その場の思いつきではなく、この層を見て判断します。

Standards / Knowledge Layerは、中身を2つに分けて持ちます。クライアント・案件固有のもの（Business / Brand / User Context、UX Strategy、Journey、契約・権利・セキュリティ・AI利用条件、案件内のDecision Log）と、ニューロマジック共通のもの（Module / Skill / Harnessの型、評価基準、レビュー手順、禁止パターンの書式、再利用可能なTemplateとGuardrail、案件分類と見積・体制・リスク判断のパターン）です。この2つを混ぜずに持ち、その分離を宣言ではなく仕組みとして担保しておくことが、後で効いてきます。

上流と下流をつなぐのは、文章ではなく構造正本です

Webサイトを作る場面で考えてみます。Content、Design、Codingの3つのHarnessに渡されるのが「こういうページを作ってください」というBriefだけだと、何が起きるか。文章はスロットの数も順序も字数も縛れませんから、3つがそれぞれ別の構造を想像します。出てきたものを人が突き合わせて、ずれを直す。速く作れたぶんだけ、速くずれます。

ですから当社は、3つが共通に読む構造正本（Structure Source of Truth）をTouchpoint / UX Planning Harnessの層に置くことにしました。形式は、スタイルを一切当てないHTMLです。要素と階層と順序だけを持ち、色もフォントも余白も持ちません。文言も決めません。決めるのは、この見出しの下にこの要素が何個、それぞれ何字から何字の幅で入る、というところまでです。

なぜ文言を決めないのか。決めた瞬間に、上流が下流の決定を先取りして、責任分界が消えるからです。逆に、なぜ字数の幅は上流で決めるのか。幅はレイアウトを規定するのでDesignとCodingの両方に効く、つまり構造の一部だからです。細かい話に見えますが、「どこまでが構造で、どこからがビジュアルか」を毎回もめずに済ませるための、かなり効く一本の線になります。

この考え方はWebに限りません。業務プロセスでも、AIに渡す前に共通の型を決めておかないと、賢いモデルほど、それぞれの解釈で立派なものを作ってしまいます。

Standards、Findings、Gapsを分ける

既存資産の扱いにも触れておきます。新規に立ち上げる仕事より、リニューアルや運用改善のほうが実際には多く、そこでは現行のサイトやアプリ、ブランドガイドが出発点になります。ここを担うのがStandards Extraction Harnessで、既存のTouchpointからDesign System、Content System、Engineering Standardsを起こします。

このHarnessが守る一線は、現行資産を「正本」と「現状」に分けることです。動いているものが、すべて正しいわけではありません。表記のゆれ、アクセシビリティ違反、未トークン化。分けずに取り込むと、既存の欠陥をそのまま次の成果物へ再生産します。ですから出力を、Standards（守るべき正本）、Findings（現行資産の欠陥）、Gaps（観測範囲に存在しなかった領域）に分けます。3つ目が特に重要で、観測できなかった領域を推測で埋めず、新規設計が必要だと明示します。

加えて、値ごとにProvenance Ledger（出どころの台帳）を残します。その値のorigin（確からしさの由来。declared＝宣言、measured＝実測、inferred＝推定）とscope（帰属。project＝案件固有、shared＝当社共通）、出典URL、観測日、観測条件です。値そのものより、その値がクライアントの宣言なのか、当社が実測から丸めたものか、推定なのかが、後工程の判断を分けます。scopeを持たせておかないと、案件が終わったあとに「この値は次の案件へ持っていけるか」が判断できなくなります。

Human Gate（人が決める関門）とQuality Gate（機械が通す検査）を、あらかじめ置く

「どこまでAIに任せるか」は必ず出る問いです。当社の答えは、任せる割合ではなく、人が決める場所をあらかじめ設計しておく、というものです。

置き分けの基準ははっきりしています。事業文脈がないと決まらないことは、機械に渡さない。現行資産の欠陥を「直すべき欠陥」と見るか「クライアントの意図的な選択」と見るかは、事業の優先順位を知らないと決まりません。ここはHuman Gateです。一方、必須項目が埋まっているか、禁止パターンが混ざっていないかといった検査はQuality Gateとして機械で通します。落ちているものを人に見せて時間を使わせないためです。

Human Gateで記録するものは3つあります。承認そのもの、承認時に保留した項目、そして意図的に決めなかった項目です。3つ目が抜けやすく、書き残さないと、後になって「決まっていたはず」が起きます。

そして、Gateを通ったあとに次工程の議論が出ることを、差し戻しと呼ばないことです。構造に合意したあとでスタイルの議論が出るのは当然で、それは差し戻しではなくProduction Harnessesの範囲です。何が本当の手戻りで、何が次工程なのか。この切り分けを持てるかどうかも、Architectureの有無で決まります。

定義を書くことと、動くものを残すことは別です

Architectureの話をすると、多くの場合、定義の議論から始まります。どんな役割を置くか、どの順で回すか、誰が承認するか。ここは楽しい議論ですし、文書としてきれいにまとまります。

ただ、AI活用が組織に定着するかどうかを分けるのは、その先です。考え方は文書になって共有されるのに、実際に動く検査やスクリプトは作った人の手元の環境に留まっている。この状態だと、担当者が異動した時点で仕組みは途切れます。文書は残るのに再現できない、という形の目減りは、想像よりも起きやすいのではないでしょうか。

ですから当社は、定義と実装を分けたうえで、実装のほうをバージョン管理の下に置いています。生成物と根拠はコミットし、Human Gateの判定は日付と判断者つきで書き、確定時にタグを打つ。Standards / Knowledge Layerのクライアント固有と当社共通は、宣言ではなくフォルダとして分け、混ざったら成り立たない形にしておく。分離を文書の主張ではなく動く仕組みにしておくと、あとから見ても境目がわかります。

Moat（模倣されにくい堀）は、Experience Intelligenceに宿る

AIによって同じ範囲の仕事を安く速く提供できることは、もはや市場の標準です。競争力ではありません。旧来の工程と価格をそのまま維持することはできませんし、それに気づかないままだと、じわじわとコンペで選ばれなくなります。

では、何が差別化になるのでしょう。案件ごとに、ふさわしいスコープ、プロセス、品質、納期、予算配分をどう設計できるか。そしてその設計判断が、案件を回すたびに組織へ戻ってくるかどうかです。どの案件条件でどのHarnessが有効だったか、どこにHuman Gateを置くと成果が安定したか、Quality / Time / Cost / Riskの実測はどうだったか、どんな失敗パターンが出たか。これを蓄積し、次の案件の構成へ返す回路を当社ではExperience Intelligence（案件から回収した判断知）と呼んでいて、ここがAgent Harness Architectureの本体であり、模倣されにくいMoatになると考えています。

まとめると、こうなります。AI Agentを成果につなげる鍵は、モデルの性能でも、プロンプトの巧拙でも、Harnessを一つ作ることでもありません。縦にも横にもHarnessを置き、Standards / Knowledge Layerと構造正本でつなぎ、Quality Gateで検査し、Human Gateを残し、学びをExperience Intelligenceへ戻す。この設計思想を持てるかどうかです。そして設計は、一度に完成させる必要はありません。一つのModuleまたは一つの案件で、Input、Output、Questions、Human Gateを決めて回してみる。それが最小実装単位であり、最初の一歩になります。

みなさんの組織では、AIの成果はどこに溜まっているでしょうか。個人の手元にしか残っていないと感じるなら、Harnessを増やす前に、つなぐ設計を持つタイミングが来ているのかもしれません。当社は、このAgent Harness Architectureの設計と、実際の案件での運用の両方に取り組んでいます。自社のAI活用をどこから仕組みに変えていくか、一緒に考えたい方はお気軽にお声がけください。