専門特化AI Agent の設計に必要なもの
— ハーネスはドメイン知識の翻訳作業から生まれる

ハーネスを設計するとは「判断ポイントを言語化する」こと

前章で引いた Anthropic の Rajasekaran 氏の一文を、もう一度読み直します。

この一文を、設計者の視点で言い直すと、こうです。ハーネスを書くには、まず「どこで・何を・なぜ判断しなければならないか」が言語化されている必要がある。判断ポイントが特定されていない領域で、モデルに何かを丸投げしても、出てくるのは雰囲気だけ整った文章です。意思決定には使えません。

したがって、専門特化 AI Agent を作るために本当に必要なのは、3つの言語化です。

この3つが揃って初めて、LLM はその領域で「使える知能」になります。逆に言えば、この3つを書ける人がいない領域では、どんなにモデルが賢くなっても、専門特化 AI Agent は組み上がりません。

具体例：A4 で扱った「マージンが個人成績に反映されるか」という事実

抽象論を続けても説得力は出ません。1つだけ、具体例を深く掘らせてください。A4「重点パートナーの絞り込み」で扱った、必須条件のひとつです。

パートナー企業がいくら自社プロダクトに前向きでも、目の前の営業担当の 個人評価 にマージンが反映されない限り、その担当者は動きません。理由は単純で、営業は誰しも自分の予算を背負っているからです。説得や勉強会では覆りません。

この事実は、樫山氏が公開セミナーで語ったので、いまこうして文字としても残っています。けれど、ここから先がポイントです。この発言を「Tier階層・重要度ランク 判定の必須条件」として位置づけられるかどうかは、別の作業 です。

Aは消費、Bは内省、Cは設計です。汎用 LLM に「樫山氏のこの発言をどう読むか」と聞けば、AかB相当の答えは返ってきます。けれど、Cの読み方 ── これを必須条件として、足切りロジックの一段目に置く ── という発想は、現場で同じ失敗を何度も見てきた人間にしか書けません。

実際に A4 では、必須条件はこの「マージンが個人成績に反映されるか」を含む4つで構成されています。1つでも欠けたら重点支援から外す、という運用です。なぜそこまで強い扱いにできるか ── マージンが個人成績に反映されないパートナーに、いくら共同マーケや勉強会のリソースを投下しても 構造的に動かない という観察が、複数の事業会社に共通して存在しているからです。

SmartHR の清水氏も、同じ判定の入口で「予算（本気度）」を必ず聞くと述べています。

マージン×個人成績反映、予算×本気度。異なる事業会社の登壇者が、独立に、同じ性質のチェック項目を語っている。これが「観察可能な必須条件として一段目に置く」という設計判断の根拠になります。一発言だけなら個人の流儀ですが、複数の事業会社に共通して観察される現象は、ハーネスに組み込んでよい構造です。

同じ性質の事実が、A1〜A6 に大量に詰まっている

いま掘り下げた「マージン×個人成績反映」は、たった1つの判定軸です。同じ性質の事実 ── 現場で繰り返し観察され、複数の登壇者が独立に語り、観測可能シグナルとして翻訳できるもの ── が、Section A の各章に積み上がっています。

例として、A5「キーマンの探し方」で示された5階層のキーマン語彙を見てください。決裁者・メインカウンターパート・トップセールス・チャンピオン・案件創出者。これは「キーマン」という単数語を、機能の違いで5つに分解したものです。

三宅氏のこの発言は、「キーマンを 人 として探すと失敗する。機能 として配置を読まないと当たらない」という現場感を、別の言葉で言い直したものです。企画が効く会社、現場が効く会社、それぞれで 機能の重力 が違う ── ここを5階層で記述できるからこそ、SoR事実の唯一の記録元 のコンタクトレコードに「役割バッジ」というスキーマが置けます。1人が複数階層を兼ねるケースも、別人が同じ階層に2人いるケースも、構造的に表現できます。

さらに A6「営業人材の発掘」では、同じ「観察 → 言語化 → 仕組み化」の作業が、もっと細かい粒度で行われています。

佐々木氏のこの発言には、3つの観測軸が同居しています ── 席の位置、メモの取り方、周囲の人脈。「拡販人材を発掘するときに、勉強会の現場で何を見ればいいか」という問いに、ここまで具体的な観察対象を挙げられる発話は稀です。これを「観測可能シグナル」として SoA次の一手を提案する層 の入力に登録できれば、勘ではなく仕組みで拡販人材を浮かび上がらせられます。

Section A 全体を、判断ポイント・判断軸・シグナルというフレームで一覧にすると、こうなります。

A1〜A6 は、表面的には「パートナーセールスの解説記事」に見えます。けれど中身は、判断ポイント・判断軸・観測可能シグナルが3層で揃った仕様書 です。これがハーネス設計の前提物なのです。

このフォーマット化は、現場に浸かっていないと発想できない

ここまで読まれた方には、もう自然に見えていると思います。「マージンが個人成績に反映されるか YES/NO」を Tier 判定の一段目に置く という設計判断は、樫山氏のセミナーを聞いただけでは出てきません。出てくるのは「面白い話だった」「次の打ち合わせで共有しよう」というレベルです。

判定軸として置けるようになるには、最低でも次の経験が要ります。

この4つを満たさないと、ある発言を「判定軸」に翻訳する作業は、構造的にできません。汎用 LLM エンジニアにも、外部の AI コンサルにも、業界経験のないコンサルにも、難しい作業です。理由は能力ではなく、観察対象に触れている時間 の問題です。

ここで先ほど引用した佐々木氏の発言に戻ります。「席の場所」「真剣さ」「周囲の人脈」── このレベルの細かさで観測対象を切り出せるのは、佐々木氏自身が現場で何百回と勉強会に同席して、拡販に繋がった営業と繋がらなかった営業を分ける何かを観察し続けてきたからです。LLM の学習データの中に、この粒度の観察ノートはほぼ存在しません。

では「集める場」と「翻訳する設計」は、同じ場所に必要

ここまでの議論を整理すると、専門特化 AI Agent を作るには、ふたつのものが 同じ場所に 必要だということが見えてきます。

どちらか一方だけでは足りません。事実を集めても翻訳できなければ、ナレッジベースが膨らむだけで現場の判断は変わらない。設計眼があっても流れ込む事実がなければ、ハーネスは想像で書かれるしかなく、現場で試した瞬間に裏切られます。

この2つの条件は、組織として揃えるのに 時間 がかかります。事実が集まる場は、コミュニティであれメディアであれ、関係構築に数年単位を要します。翻訳する設計眼は、その場に浸かりながら、判定軸を実際に試して擦ってきた人間の中にしか育ちません。「やろう」と決めた当日に揃えられる条件ではないのです。

synergeee は、Japan Partner Sales というコミュニティと partnersales.biz というメディアを3年以上運営してきました。本記事内で引いた樫山氏・清水氏・三宅氏・佐々木氏・荒井氏・冨樫嘉一氏・高田氏らの発言は、いずれもそこで生まれた一次情報です。そして、その一次情報を A1〜A6 という形に 判断ポイント・判断軸・シグナル として翻訳し、SoR のスキーマと SoA のロジックに転写してきました。これは自慢ではなく、上の2条件をどう満たしているかの構造的な説明です。

翻訳された構造が、ハーネスの実体になる

ここまでの議論を、ハーネス設計の実装図に落とすと、こうなります。

これらは「やったことアピール」ではなく、「ハーネスを書こうとしたら、必然的にこの形にしかならない」という設計の説明です。判断ポイントが言語化されていなければエージェントは沈黙する。判断軸が曖昧なら、的外れな提案が量産される。シグナルが定義されていなければ、観測対象は混沌としたまま動かない。だから、A1〜A6 で言語化された3層の構造が、そのままハーネスの骨格として現れます。

言い換えると、ハーネスは ドメイン知識の影絵 です。影絵だけを綺麗に作ろうとしても、本体がなければ何も動きません。本体（A1〜A6 として翻訳された構造）があるから、影絵（SoR / SoA というハーネス）に意味が宿ります。