Photo by Ferdy Jovanno on Pexels
こんにちは。ワタシです。
今回は AI エージェント界隈で急に流行り始めた「ハーネス」というヤツについて考えてみたいと思います。ハーネスですよ、ハーネス。犬の首輪のことじゃないですよ。エージェントを取り巻く環境設計の話です。ハーネス。 真面目な話です。なんかかっこいい響きですね。ワタシも今後積極的に使っていきたいです。
で、このハーネスという概念が 2026 年の春頃からわりと本格的に出回り始めまして、気がつくと界隈の人たちの住み分けが発生しているわけです。バイクに乗っている人たちがアメリカン派とレーサーレプリカ派とオフロード派に自然に棲み分けされているのとまったく同じ原理です。流儀があり、宗派があり、「俺のほうが正しい」という静かな睨み合いがある。
というわけで、ハーネスをめぐる人種の考察をやっていきたいと思います。ついでに、それぞれの派閥が 経営や開発の現場ではどう効いてくるのか も、一言ずつ添えていきます。技術顧問として相談を受ける立場としても、この棲み分けは結構意味があります。「どの派閥に近いチームと組むか」で、半年後のスピードがけっこう変わるからです。
図1. 7派閥のマッピング
図1：「ハーネスの所有スタイル（自前 ⇄ マネージド）」と「議論への距離感（推進 ⇄ 観察）」の2軸で7派閥を配置。どこに自分・自チームが立っているかを把握する補助線として。
素人派（Vibe のみ）
まず最初に申し上げますと、この人たちは悪気がないです。本当に。
「いい感じに作って」の一言でプロンプトを終わらせる層です。CLAUDE.md？ 何それおいしいの。Hooks？ MCP？ skills？ 全部呪文に聞こえます。出力が一発で出ないとキレる。それは分かります、ワタシだってキレます、ていうか毎日キレています。
ただこの人たちにハーネス設計の話をしても 空を見上げるだけ なのでやめたほうがいいです。かわいいもんです。悪気はない。本当に無垢なんです。
判断ポイント：非エンジニア経営者がここに留まること自体は悪くない。むしろ Vibe Coding で社内ツールを自分で作れる強さは本物です。問題は、本番運用に乗せた瞬間に「進化が止まる」フェーズが来ること。そのタイミングで誰かにハーネスごと巻き取ってもらえる体制があるかどうかが分かれ目になります。
公式マネージド派（Anthropic 教）
これは分かりやすいです。公式が出したものは正義。 以上。
Managed Agents、Remote Control、公式が提供するやつ全部乗っかる。自前でインフラ組むなんて時間の無駄だと言う。正論です。確かに正論なんです。自分でゼロからガレージ建てるより、完成したハコを借りた方が早い。
しかしですね。
この人たちはハーネス自体がマネージドサービスになったことを「メタハーネス」という造語で表現し始めまして、それを聞いたワタシは「ああそういうことか」と思うと同時に、「なんか・・・・・・」という絶望感に包まれました。土日で自前ハーネスをマネージドに移行してやってよかったと書ける人間のことを、ワタシは尊敬と軽い嫉妬を混ぜた目で見ています。畜生。
判断ポイント：スタートアップや事業ローンチ前のフェーズなら、まず公式マネージドに寄せるのが速い。自前ハーネスを組むのは「自社固有の業務知識やセキュリティ要件が、公式のデフォルトでは表現しきれなくなったとき」に始めればいい。順番を間違えると、コア事業より先にハーネスの面倒を見る羽目になります。
DIY ハーネス派（手作りガチ勢）
これがいちばんやばい。
settings.json を書き、CLAUDE.md を練り上げ、Hooks を仕込み、Skill ファイルを整然と並べる。70,000 字の実装記録を聖典として読み込む人種です。70,000 字ですよ。70,000 字。ワタシが今まで生きてきた中で書いたラブレターの総文字数より多い可能性があります。書いたことないですが。関係ないですね。
「プロンプトエンジニアリング → コンテキストエンジニアリング → ハーネスエンジニアリング」という進化の図式を整理して言語化できる人たちです。モデルは CPU、ハーネスは OS。OS がクソなら CPU がいくら速くても意味がない。正しい。完璧に正しい。
LangChain でハーネスを改善しただけで Terminal Bench のスコアが Top30 から Top5 になったという話も出ていまして、これを聞いたとき ワタシは思わず「うそだろ」と言いました。 本当に言いました。独り言で。部屋で一人で。
判断ポイント：自社の競争優位が「他社にできない作業フローを LLM に任せきれること」にあるなら、DIY 派の知見は本気で取りに行く価値があります。一方で、ハーネスを磨き続けること自体が目的化していないかは、月1 回ぐらいは正気に戻って点検したほうがいい。
Knowledge Base 原理主義派（循環の信者）
raw/ フォルダに資料をぶち込んで、LLM で wiki 化して、Q&A して、成果物を作って、また wiki に反映させる、という 壮大な知識の循環 を回す人たちです。
この派閥のすごいところは信者の反応速度です。提唱者が投稿して 48 時間後には GitHub にツールが生えている。1 コマンドで任意フォルダを知識グラフ化するやつが。ワタシが「へえ面白いな」と思って記事を読み終わる頃には、世界のどこかの誰かがもうそれを動かしています。
「30 分で組める」とか言う人も出てきます。30 分。ワタシは 30 分でカップ麺を作ることすら失敗することがあります。お湯を沸かすのを忘れます。
そして「画期的なのは各機能じゃなくて、ナレッジベース自体が継続編集される循環が回っていることだ」という指摘が飛んでくるわけで、これを読んだワタシはようやくこの派閥の本質が分かった気がしました。静的な知識の置き場を作るんじゃなくて、知識が自分で育つ仕組み を作る。
判断ポイント：業務ナレッジが属人化している組織ほど、この派閥の発想は効きます。ただ「循環を回す担当」が誰なのかを決めずに導入すると、結局 raw/ に資料を投げて終わるパターンになる。仕組みより先に、誰がオーナーかを決める話だと思っています。
冷めた観察派（棲み分けの番人）
この人たちがいちばん怖い。
全員がハーネス設計に盛り上がっているところに「でもみんな結局 Claude Code 使っているよね」とぽつりと言う。そうなんです。良い性能のハーネスを作る市場、本当に存在するのか？ 完成した頃に本家が全部持っていく、という冷静な観測です。「勝負する市場を間違えたらダメだぞ」。
これを読んだときワタシは「うっ」と思いました。完全に正しいんだけど、言われたくなかったタイプの正しさです。
RAG と agentic search の棲み分けも整理して、「.doc や .pdf を .md にして、LLM で古い部分や重複を削ぎ落とし、agent の視界に収まるサイズに圧縮する壮大なる大掃除が 2026 年の Agentic DX」という言語化まで出てくる始末です。壮大なる大掃除。すごいネーミングです。
判断ポイント：自社プロダクトとしてハーネスを売るなら、この派閥の冷たい問いに先に答えておく必要があります。「半年後に本家が同じものを出したら、自分たちのプロダクトは何で残るのか」。逆に、社内向けハーネスならこの問いは無視してよくて、本家が同じ機能を出したら乗り換えればいいだけです。社内 vs プロダクトで判断軸が変わる。
Memory 独立主義派（ロックイン警戒組）
ハーネスを特定のサービスに委ねることは、記憶の管理権を第三者に渡すことだ。という話です。
メモリはあなたのエージェント体験の質を決める。だから memory も harness もオープンであるべきだ。あなたは自分のメモリを所有するべきだ。
・・・・・・なんかこれすごく真剣な話なのに、ワタシは「メモリ所有」という言葉を聞いて一瞬だけ「ワタシのメモリ、なんもないじゃん」と思ってしまいました。知識グラフどころか、昨日の夕飯が思い出せないレベルです。
判断ポイント：エンタープライズの相談だと、ここはほぼ必ず議題になります。「うちの業務知識を Anthropic（あるいは OpenAI）の中に置いていいのか」問題です。技術選定そのものより、メモリを自社側に保持できる構成になっているか を契約・アーキテクチャ両面で確認するのが、結局いちばん効くチェックポイントだと思っています。
進化論派（三段階史観）
weights → context → harness。
2022 年はモデル自体を賢くする時代。2024 年は文脈を賢くする時代。2026 年はモデルを取り巻く環境を賢くする時代。という進化の図解です。これ自体はシンプルで美しいんですが、美しすぎて逆に怪しいとも言える。 世の中そんなにきれいに三段階に分かれるものか？
ただ「プロンプトを磨いても限界があって、次のレイヤーはハーネスだ」という流れは体感として分かるんです。なんか上手くいかないなと思ったとき、実はプロンプトの問題じゃなくて設計の問題だった、という経験、ワタシにも何度かあります。
判断ポイント：チーム内で「LLM がうまく動かない」議論になったとき、最初に「これはプロンプトの問題か、コンテキストの問題か、ハーネスの問題か」を分けるだけで議論の質が変わります。三段階史観は半分宗教だとしても、問題の切り分けフレームワーク としては実用的です。
さて、結局どうすればいいのか
Anthropic はマネージドを出した。ある人はそれをロックインと呼んだ。別の人はハーネス市場ごと本家に持っていかれると言った。知識の循環を育てろという人もいる。全員違うことを言っていて、全員どこか正しい。
そしてワタシはといえば、全部の話が面白くてとりあえず記事を読み続けていたら夜中の 3 時になっていました。ハーネスより睡眠管理のほうが先だったかもしれない。
ただ、技術顧問として実際に相談を受ける立場で言うと、この観察記から取り出せる実用的な判断軸は、案外シンプルだと思っています。
- フェーズで選ぶ：立ち上げ期は公式マネージドに寄せる。差別化フェーズに入ってから DIY を検討する。
- 目的で選ぶ：社内向けか、外販プロダクトか。冷めた観察派の問いに答える必要があるのは後者だけ。
- オーナーで選ぶ：ナレッジ循環を回すなら、オーナーを先に決める。仕組みより人。
- 可搬性で選ぶ：メモリを自社側に保持できるか。これは長期で効く。
ハーネスを語る人たちは、それぞれのレイヤーから世界を見ています。だからこそ、自分のチームが今どのレイヤーで悩んでいるのかを見極めるほうが、流派選びより先にやるべきことかもしれません。
ここまで読んでいただき、ありがとうございます。
mak246.com では、こうした AI エージェント設計と経営判断の交差点にある実践知 を、現場目線で整理しています。前回の LLMにおけるハーネス理論とは？Minecraftでわかるエージェント設計の本質 と合わせて読んでいただくと、「理論」と「現場の派閥」の両側から、ハーネスの全体像が見えやすくなると思います。