ハーネス・イズ・カンパニー

なぜ SaaS ビジネスは今や harness ビジネスなのか

Shrivu Shankar

2026年8月24日

あらゆる SaaS ビジネスは、本人たちが気づいているかどうかにかかわらず、モデルの外側を包む harness になっていく。

harness とは何か

狭い意味では、harness は LangGraph のようなフレームワークや、Codex、Claude Code、OpenCode のようなコーディング agent と結びつけて語られる。ステートレスなモデル API にツールと状態を十分に被せ、実際に仕事が回るようにするものだ。ここで使う harness はもっと広い意味で、ステートレスな LLM を取り巻くインフラ、インターフェース、コンテキスト、状態のすべてを指す。1 つの harness は、タスクごとに調整された複数のサブ harness から構成されてもよい（それらを束ねる役が meta-harness だ）。「ソフトウェア工場」も harness の一種で、その部品のそれぞれがより小さな harness になっている。仕様を書くもの、コードを書くもの、レビューするもの、そして何をいつ動かすかを決める層だ。この広い定義を受け入れるなら（あるいは harness という語を好みの言い方に置き換えるなら）、多くのソフトウェアサービス企業はこういう軌跡をたどると私は見ている。

1. 従来の SaaS のやり方で作ったソフトウェアサービスを売っている。harness はない。

ソフトウェアサービスを売ってはいるが、エンジニアは agent とペアを組んで仕事をする。プロダクト、セールスなど、ますます多くの職能が agent とペアを組んで効率を上げている。

1. 個人が harness を操作する。

ソフトウェアサービスを売ってはいるが、中核的なタスクの多くがクラウド上で動くバックグラウンド agent に移る（ノート PC では 20 個も動かせない）。エンジニア、プロダクト、セールスがこれらの agent を起動し（つまり prompt を書き）、出力をレビューする。

1. 個人が harness を編成する。

ソフトウェアサービスを売ってはいるが、中核的なタスクの多くが自律的に動くバックグラウンド agent に移り、エンジニア、プロダクト、セールスは agent の出力のレビューに軸足を移す。全件レビューはサンプリングレビューになる。何をすべきかを人があらかじめ設計するのではなく、ますます多くの agent が自分で決めるようになる。

1. harness が個人を編成する。

反転。SaaS の形では人がソフトウェアを支える。harness の形ではモデルが働き、人の注意力は本当に重要な場所へと導かれる。

この軌跡をたどり切ると、会社は実質的に harness になっている。ソフトウェアサービスを作る仕事は、人から harness へと移っている。

• 中核的なタスクは agent がこなし、「プロダクト」は完全にモデルの出力になる。会社が提供するのはコンテキスト、統合、そして人向けのレビューインターフェースだ。
• ソフトウェアと組織構造の関係が反転する。組織図は、harness が人から最大限の品味と判断力を引き出すには人をどこに置くか、という問いに変わる。人 itself が harness の一部になる。
• 会社のドメイン知識、ツールチェーン、権限、レビューループ、コンテキストなど、そのすべてがビジネスの harness になる。

AI のゴミ工場にしか聞こえない。

主に AI が作り、AI がレビューするプロダクトは必ず品質が低く、人ではなく harness で作ればゴミが大規模に量産されるだけだ、と考えるのはたやすい。だがその見方は、そう動く会社が無人工場だと前提しているように思う。

本当の解は、人の入力がどこで最も効くかを harness 自身に見つけさせることにある。たとえば：

• あるプロダクト判断について、agent が顧客会議でセールス担当者に個別に問いを立て、その結果を 1 つのプロダクト demo に統合して、プロダクト責任者のレビューに回す。
• 顧客会議で出た 1 つの機能提案を、agent が重大なアーキテクチャ判断に変換し、エンジニア側の品味の番人に提出する。
• UI の刷新がフィードバックの集約を経て始まり、いくつかのバージョンを試したうえで、最良の案をデザイン側の品味の番人に提出する。

優れた harness は、顧客に最大の価値を生みながら、人の注意力——従業員のものも、顧客のものも——を必要な場所にだけ使う。

注意力はルーティングされる。harness が人の入力をどこへ向けるかを決める。顧客の分も含めて。

まだ疑わしいなら、それはもっともだ。今日のフロンティアモデルと作り込んだ harness があっても、agent にこうやって外側のループを任せるのはかなり難しい（私たちはそれを試すことにかなりの時間を費やした）。それでも、モデルが最終的にこれをできない方に賭ける価値はないと思う。まして、こうした計画やレビューの仕事の多くが検証可能な報酬を持ち、ラボが訓練に使えるタスクへと分解されつつあるのだから。

「テイスト・ホルダー」型の組織とはどんなものか知りたい場合は、The Transposed Organization を参照してほしい。本稿はかなりの部分で、あの記事で提示した考えの上に成り立っている。

harness が製品の生産と販売を担うなら、それは中核能力だ。

どんな差異化が効くかはサービスの種類によって変わる。信頼、ディストリビューション、効率、ドメイン文脈——企業の強みはたいていこのあたりから生まれる。自律的に動くバックグラウンド agent の世界では、harness をどう作るか——何を学ばせ、何を監視し、人間のテイスト・ホルダーとどう接続し、どのシステムを統合するか——が、その差異化を維持する手段になっていく。

いまや harness は、仕事を納品するために何を満たす必要があるか（≒信頼）、製品がどれだけ速く、どんな形で世に出るか（≒ディストリビューション）、フィードバックループの速さと文脈（≒効率）、そして組織知がどう吸収され維持されるか（≒ドメイン文脈）を決めている。

harness は、金を払ってでも使いたい社内ツールから、絶対に外注しないものへと変わっていく。製品エンジニアリングチームや GTM チームを外注しないのと同じだ。AI 以前とはまるで違う。当時は、ソフトウェアを使って物事を成し遂げる人の数が、アウトプットの上限をどれだけ左右するかが問題だった。

すでに起きている。

自社製の AI 開発者ツール——Ramp、Stripe、DoorDash などで見られるようなもの——が、この動きの始まりだと考えている。

この判断ははっきり言っておく。

AI をワークフローに取り込んだ企業にとって、SDLC ツールベンダーが連携を追加し、あるインターフェースに対応し、コストを許容できる水準まで下げるのを待つことは、製品を開発・保守する能力をますます強く縛っている。短期的には特にそうだ。企業のソフトウェア工場全体を代わりに回せないサードパーティツールとなればなおさらで、理由はたいてい技術スタックが特殊すぎる、ガバナンス制約が厳しすぎる、重要機能のサポートが遅すぎる、コストモデルが気に入らない、といったところにある。

すべてを内製して保守しろと言っているわけではない。企業は最上位の harness——何を作るかを決め、返ってきた結果を審査する層——を握り、具体的なワークフローにはベンダー製品を接続すればいい。いずれ「仕様からテスト済み pull request まで」をエンタープライズ品質でやるサードパーティが現れ、その時点でソフトウェアサイクルのその区間はその製品に差し替えつつ、入力となる仕様を書き、pull request の出力の後工程を扱う agent は自社に残せる。

外側のループ全体がどうにかサードパーティの harness で完結するなら（つまり業務そのものをサービスとして、自律バックグラウンド agent で回すなら）、その会社はもうコモディティ化していると思う。

で、どうなる？

このメンタルモデルが正しければ、こういうことが見えるはずだ：

• 内製 harness の数が異常に多い。構築側も販売側も
• 組織図と個人の役割が、業務 harness の中での位置を軸に組み替えられる
• 「堀」が harness 化しやすい領域で、AI ネイティブのスタートアップが incumbent を打ち負かす
• ソフトウェア企業が使うあらゆるソフトウェア（中核の構築・販売経路の上、あるいはそれに結びつくもの）に headless が求められる。外側の harness がそれらを駆動できるようにするためだ