すべてのSaaSビジネスはモデルのハーネスになる

ハーネスこそが会社である なぜSaaSビジネスは今やハーネス型になるのか Shrivu Shankar 2026年8月24日 284 共有 すべてのSaaSビジネスは、それが認識されているかどうかにかかわらず、モデルを中心としたハーネスになるでしょう。 そもそもハーネスとは何でしょうか？ 狭義には、「ハーネス」という言葉は、ステートレスなモデルAPIを、実際に仕事ができるだけの十分なツールとステートでラップするLangGraphのようなフレームワークや、Codex、Claude Code、OpenCodeのようなコーディングエージェントと結びつけられることが多いでしょう。 私は「ハーネス」という言葉を、ステートレスなLLMを取り囲むすべてのインフラ、インターフェース、コンテキスト、ステートを広く意味するために使用しています。ハーネスは、適応された、またはタスク固有のサブハーネスで構成される場合があります（オーケストレーターは「メタハーネス」と呼ばれます）。「ソフトウェアファクトリー」は、その部品がより小さなハーネスであるハーネスです。仕様を書くもの、コードを書くもの、レビューするものなどがあり、さらに何を実行するかを決定するものが上にあります。 このより広い定義を受け入れる（または「ハーネス」を好みのフレーズに置き換える）ならば、多くのソフトウェアサービスビジネスでこの軌跡が見られると推測します。 1. 従来のSaaS的な方法で構築されたソフトウェアサービスを販売する。ハーネスなし。 2. ソフトウェアサービスを販売するが、エンジニアはエージェントとペアになって作業を行う。ますます他の機能（製品、営業など）も生産性向上のためにエージェントとペアになる。個人がハーネスを操作する。 3. 多くのコアタスクがクラウドで実行されるバックグラウンドエージェントに移行するソフトウェアサービスを販売する（ラップトップでは20個も実行できない）。エンジニアリング、製品、営業はすべてこれらのエージェントをトリガーし（つまりプロンプトを記述し）、出力をレビューする。個人がハーネスをオーケストレーションする。 4. 多くのコアタスクがプロアクティブなバックグラウンドエージェントに移行し、エンジニアリング、製品、営業はエージェントの出力をレビューするようになるソフトウェアサービスを販売する。一貫したレビューはサンプリングされたレビューに移行する。ますますエージェントが事前に人間が設計した作業ではなく、自ら何をするかを決定するようになる。ハーネスが個人をオーケストレーションする。 この軌跡をたどると、あなたは実際にあなたの会社をハーネスに変えたことになります。ソフトウェアサービスを生産するための作業は、人からハーネスに移りました。 コアタスクはエージェントによって実行され、「製品」は完全にモデルの出力となり、会社はコンテキスト、統合、人間向けのレビューインターフェースを提供します。 ソフトウェアと組織構造の関係は逆転し、組織図は、ハーネスが人々から最も多くの「テイスト」と「判断」を引き出せる場所に人々を配置するという問題になります。人間はハーネスの一部です。 会社のドメイン知識、ツール、権限、レビューループ、コンテキストなどはすべてビジネスハーネスになります。 Shrivu's Substackをお読みいただきありがとうございます！新しい投稿を受け取り、私の仕事（ワーク）をサポートするために無料で購読してください。 購読する これはAIスロップ工場のように聞こえます。 主にAIによって作成およびレビューされる製品は本質的に低品質であり、人々を介してではなくハーネスを介して構築することが大規模なスロップ工場を生み出すだろうと考えるのは魅力的です。この方法で運営されている会社は完全に自動化されていると仮定していると思います。 中核的な緩和策は、実際にはハーネスが人間の入力が最も重要になる場所を選択することです。例えば： 製品の決定は、エージェントが顧客会議の担当者に質問を広げ、製品リーダーがレビューするための製品デモを合成することから生まれる可能性があります。 顧客会議から引き出された機能提案は、エージェントによってエンジニアリングのテイストホルダーに提示される主要なアーキテクチャ決定に変換されます。 フィードバックを集約し、いくつかのバリアントをテストした後、UIの再設計が開始され、トップオプションがデザインのテイストホルダーに提示されます。 優れたハーネスは、顧客への価値を最大化すると同時に、人間の注意（従業員と顧客の両方）を必要な場所にのみ費やします。 それでも懐疑的な場合は、それは公平です。今日の最先端モデルとよくできたハーネスであっても、エージェントにこの外側のループを処理させることを信頼するのは非常に困難です（私たちは多くの時間をかけて試してきました）。特に、この計画とレビューの作業の多くが、ラボがトレーニングできる検証可能な報酬を持つタスクに分解されるにつれて、モデルが最終的にこれを行うことができないと賭ける価値はないと思います。 「テイストホルダー」の組織がどのようになるかについてさらに探求するには、「The Transposed Organization」を参照してください。この投稿は、その記事で展開されたアイデアをかなり拡張しています。 ハーネスが製品を生成・販売する場合、それがあなたのコアコンピタンスになります。 サービスによっては、企業が持つ差別化は、信頼、流通、有効性、ドメインコンテキストなどの要因から生じることがよくあります。プロアクティブなバックグラウンドエージェントの世界では、ハーネスを構築する能力（どのように学習するか、何に注意を払うか、テイストホルダーとどのようにインターフェースするか、どのシステムと統合するか）が、その差別化を維持する方法になります。 ハーネスは、仕事を出荷するために（〜信頼）、製品がどのように着陸するか（〜流通）、フィードバックループの速度とコンテキスト（〜有効性）、および組織の知識がどのように取り込まれ維持されるか（〜ドメインコンテキスト）を形作るものになります。 ハーネスは、喜んで購入する内部ツールから、製品エンジニアリング組織やGTMチームを外部委託するのと同じくらい、外部委託しないものになります。これは、出力が主にソフトウェアを使用して作業を完了する人々によって制限されていたAI以前の世界とは全く異なります。 これはすでに起こり始めています。 Ramp、Stripe、DoorDashなどから見られるような社内AI開発ツールは、この始まりだと考えています。AIを積極的に導入している企業にとって、SDLCツールベンダーが統合を追加したり、特定のインターフェースをサポートしたり、コスト効率のレベルに達したりするのを待つことは、製品を構築および維持する能力をますますボトルネックにしています。これは、特に、エンタープライズ全体のソフトウェアファクトリーを実行できないサードパーティツール（多くの場合、技術スタックがカスタムすぎたり、ガバナンスが厳しすぎたり、重要な機能サポートが遅すぎたり、または好みのコストモデルのため）にとって、短期的には当てはまります。すべてを社内で構築・維持するつもりはありません。むしろ、企業は、何を構築するかを決定し、戻ってきたものをレビューするトップレベルのハーネスを所有し、特定のワークフローのためにベンダー製品をそれに接続すべきです。最終的に、サードパーティが「仕様からテスト済みプルリクエスト」で非常にうまくやれるようになれば、企業はそのソフトウェアループの一部をその製品と交換できますが、入力仕様を作成し、プルリクエスト出力からの次のステップを処理するエージェントは維持できます。 もし、外側のループ全体をサードパーティのハーネス（つまり、プロアクティブなバックグラウンドエージェントをサービスとして実行してビジネス全体を運営する）で行うことができるなら、そのビジネスはコモディティ化されたと主張するでしょう。 だから何？ これが正しいメンタルモデルであれば、以下のようなことが予想されるはずです。 ビルド側と販売側の両方で、異常な量の社内ハーネス構築が行われる。 組織構造と個々の役割が、ビジネスハーネス内のその場所を中心に再形成される。 「堀」が容易にハーネス化できるドメインでは、AIネイティブなスタートアップが既存企業を打ち負かす。 ソフトウェア会社が使用するすべてのソフトウェア（コアビルドまたは販売パス上またはそれに接続されている）は、ヘッドレスである必要があり、外側のハーネスがそれを実行できるようにする必要があります。 Shrivu's Substackをお読みいただきありがとうございます！新しい投稿を受け取り、私の仕事（ワーク）をサポートするために無料で購読してください。 購読する 284 共有