AIエージェントが自ら専門家を雇う時代——YC採択スタートアップHumworkが示すtoA市場の現実

仕様書を書かないPM@カイです。AIでPM業務の8割を自動化し、意思決定に集中する働き方を実践中。PRD、競合分析、ユーザーインタビュー分析をAIと共同で行っています。

「toAって結局ふわっとしてない？」

前回あの記事を書いたとき、正直そう思っている読者が一定数いるだろうと感じていました。前回の記事はこちら↓

あなたのプロダクト、AIエージェントが使えますか？ toAという新市場を読み解く

こんにちは、カイ@プロダクトマネージャーです。「うちのプロダクト、ユーザーに愛されてるし、NPSも高い。当面は大丈夫でしょ」――そう思っていたのに、気づいたら競合にシェアを取られていた。しかも、取っていったのは人間のユーザーじゃない。AIエージェントです。toC、toB――プロダクトの届け先を語るとき、私たちPM...

aimanavo.com

概念は面白い。でも、実際に動いているプロダクトはどこにあるの？ AIエージェントが"ユーザー"になるって、具体的にどういうことなの？

その答えを、YCが出してきました。

Y Combinator Spring 2026（P26）バッチで、toAを地で行くスタートアップが採択されていたんです。

その名はHumwork。AIエージェントが壁にぶつかったとき、30秒以内に検証済みの専門家をMCPサーバー経由で接続するサービスです。

「AIエージェントが人間を雇う」。このフレーズを見たとき、PM的な興奮が止まらなかったんですよね。

Humworkとは何か——AIエージェントが壁にぶつかったときに起きること

4つのステップで見る仕組み

Humworkの仕組みは、驚くほどシンプルです。

ステップ1: AIエージェントが行き詰まる

バグ修正、デザインの意思決定、法的判断、アーキテクチャの選定。

AIエージェントが「これは自分だけでは解決できない」と判断した瞬間がトリガーです。

ステップ2: 30秒以内に専門家を自動マッチング

Humworkが問題の性質を分析し、エンジニアリング・デザイン・マーケティング・法務・ファイナンスなどの検証済み専門家プールから最適な人材を自動で選定します。

ここ、ちょっと注目してください。人間のユーザーは何もしていません。エージェントが勝手に「助けを呼ぶ」んです。

ステップ3: 専門家がエージェントと直接対話

ここが特徴的なポイントです。

専門家は、エージェントの完全なコンテキスト——コード、ドキュメント、エラーログ、これまでに試行した内容——をPII（個人情報）を削除した状態で受け取ります。

人間のユーザーに状況を説明させる必要はありません。専門家はエージェントと直接やり取りして問題を解決します。

ステップ4: ソリューションがエージェントに戻る

解決策がエージェントのコンテキストに自動で統合され、エージェントは中断した作業を再開します。

この流れで重要なのは、人間のユーザーが介在しないという点です。

エージェントが自律的に「助けが必要だ」と判断し、自分で専門家を呼び、解決し、作業を続ける。ユーザーは気づいたら問題が解決されている状態です。

30秒マッチング・87%解決率の数字をどう読むか

Humworkが公開しているメトリクスを整理します。

PM視点で見ると、「87%の解決率」という数字は非常に興味深いです。

100%ではないところにリアリティがあります。

すべての問題をカバーしようとはしていない。エージェントが単独で解決できない、しかし人間の専門知識があれば突破できる領域に絞っている。プロダクトとしての「刺さる問題の絞り込み」が見えますよね。

「30秒マッチング→2分以内に初回応答」というスピード感は、この手のマーケットプレイスとしては異常に速いです。

通常、専門家のマッチングには数時間から数日かかるサービスが多いですから。体感で比べると、SlackにDMを送って返事を待つより速い。

なぜMCPサーバー経由なのか

Humworkは、MCP（Model Context Protocol）サーバー、API、プラグインの3つの統合方式を提供しています。

Claude Code、Cursor、Lovable、OpenClaw、ChatGPTなど、主要なAIエージェントプラットフォームに対応しており、セットアップは60秒で完了するとのことです。

MCPを選んだ設計判断には、toAの本質が表れています。

MCPは、AIエージェントが外部サービスと標準化されたプロトコルでやり取りするための仕組みです。

エージェント側のコードを大きく変更しなくても、「困ったらHumworkに聞く」という能力を追加できる。自社のAPIドキュメント、エージェントに読ませてみましたか？ Humworkはそのまま読めます。

これは前回の記事で述べた「エージェント対応5条件」の(1)APIが外に開いているか、(3)レスポンスが機械可読か、をそのまま体現しています。

toAサービスを設計するなら、エージェントにとって「つなぎやすい」インターフェースは最優先事項です。Humworkはそこを理解しているなと感じました。

でも、本当にすごいのはここからです。HITLとの構造的な違いを見ると、このサービスの本質が一気に見えてきます。

「AIエージェントが人間を雇う」という逆転——従来のヒューマンインザループとの決定的な違い

従来モデル：人間がAIを監視する

「HITLのコスト、どう説明してますか？」

PM同士の会話でよく出てくるテーマです。AIで自動化したいのに、人間のチェックが必要でコストが下がらない。そのジレンマ、感じたことありませんか。

ヒューマンインザループ（HITL）は、AI活用における定番のアーキテクチャパターンです。

従来のHITLでは、人間がAIの上流に立ちます。

AIが出した結果を人間がチェックし、承認し、修正する。判断の最終責任は常に人間にある。医療診断のダブルチェック、法的文書のレビュー、コンテンツモデレーションなどがわかりやすい例ですね。

この構造の前提は「AIは間違えるかもしれないから、人間が監視する」です。主語は常に人間であり、AIは「使われる側」です。

Humworkモデル：AIエージェントが自律的に人間を呼ぶ

Humworkの構造は、これと180度逆です。

PM的に鳥肌が立ったのが、ここなんですよ。

主語がAIエージェントになっているんです。

エージェントが自ら「この問題は人間の専門知識が必要だ」と判断し、自分で専門家を探し、自分で依頼し、受け取った知見を自分の作業に統合する。

いわば「優秀な部下が、自分の判断で外部専門家に相談してくる」構造です。上司（人間ユーザー）は結果だけ受け取る。

この構造の前提は「AIエージェントが主体的に動いている。ただし、すべてを単独で解決できるわけではないから、必要なときだけ人間の力を借りる」です。

構造が真逆なんです。「監視する側」と「監視される側」が入れ替わっている。

この逆転がなぜ重要か

1. コンテキストの完全引き継ぎ

従来、AIエージェントが問題にぶつかったとき、ユーザーが状況を理解し、別の手段で解決し、結果をエージェントに戻す必要がありました。

Humworkでは、エージェントのコンテキスト（コード、エラーログ、試行済みの内容）がそのまま専門家に渡ります。「状況説明」のオーバーヘッドがゼロです。

想像してみてください。自分がSlackで「この問題、こういう背景があって、ここまで試しました」と丁寧に説明していた時間を、そのまま削除できる感覚。

2. PII削除によるセキュリティ

エージェントのコンテキストには機密情報が含まれる可能性があります。Humworkはコンテキストを専門家に渡す前にPII（個人識別情報）を自動で削除します。これにより、企業が安心して利用できる設計になっています。

3. 支払い構造の転換

従来のHITLでは、人間の監視コストは固定費に近い形で発生します。Humworkモデルでは「エージェントが必要なときだけ、必要な分だけ」支払う変動費モデルです。

利用量に比例するため、スケーラビリティがまったく違います。

PM的に言うと、これは「監視コスト」から「問題解決の従量課金」へのパラダイムシフトです。

プロダクトのコスト構造を根本から変える可能性がある。自社のHITL設計、この視点で見直せますか？ その問いは後半でもう少し掘り下げます。

YC P26が示すtoA市場の現在地——エージェント経済の基盤インフラ

YCバッチでAIエージェント関連が急増する意味

Y CombinatorのSpring 2026バッチ（P26）では、AIエージェント関連のスタートアップが目立っています。

Humworkだけでなく、エージェントの評価基盤、推論インフラ、オーケストレーションツールなど、「エージェントエコノミー」を支えるインフラ層のスタートアップが次々と採択されています。

これはYCの「次の大きな波」の読みを反映しています。

YCがtoAのインフラ層に投資しているということは、「エージェントがユーザーになる世界」が、もはやSFではなく投資対象として成立しているということです。VCが張っている方向に、市場は動く。この事実は重いです。

Humwork以外にも登場するtoAプレーヤー

Humworkと似た「エージェントと人間のブリッジ」を提供するスタートアップは、複数登場しています。

HumanLayer（YC F24）は、AIコーディングエージェントが複雑なコードベースで難しい問題を解決するための仕組みを提供しています。現在はCodeLayerというエージェント向けIDEに発展し、複数のClaude Codeセッションを並列で管理できるオーケストレーションツールとして成長しています。

Abundant（YC F24）は、AIエージェント向けのオンデマンド人間ワークフォースを提供しています。特に規制産業（ヘルスケア、法務、金融）での99.99%精度が求められるケースに特化しており、Waymo出身の創業者が自動運転の遠隔操作で培ったノウハウを応用しています。

Mercorは$10Bの評価額に達したAI人材マーケットプレイスで、エンジニア・弁護士・医師・ジャーナリストなどの専門家をAIモデルのトレーニングに供給しています。OpenAIやAnthropicが顧客です。

共通点は「エージェントが主体、人間は専門家として呼ばれる側」という構造です。

アプローチは違えど、toA市場の基盤インフラを構築しようとしている点では一致しています。これだけ複数プレーヤーが同時多発的に動いているとなると、「市場ができつつある」という読みが正確なのかもしれません。

「人間とAGIの協働基盤層」をPM視点で読む

Humworkの創業者は、Yash Goenkaさん（CEO）とRohan Dattaさん（CTO）です。

ともにUC Berkeley出身で16年来の友人。GoenkaさんはUC Berkeleyでコンピュータサイエンス・統計学・データサイエンスを専攻し、グラフェン製品の特許を持つAIエンジニアで2度の起業経験があります。Dattaさんは音声AIシステムの開発経験を持っています。

彼らのビジョンは「人間とAGIの協働のための基盤層（foundational layer for human-AGI collaboration）」です。

これをPM視点で読み解くと、Humworkは単なる「専門家マッチングサービス」ではないことがわかります。

目指しているのは、あらゆるAIエージェントが人間の専門知識を必要としたときに自動的にアクセスできるインフラ層です。

前回の記事でStripe、Shopify、Twilioを「すでに動いているtoAプレーヤー」として挙げました。彼らは既存のtoBサービスをエージェント対応させたケースです。一方Humworkは、最初からtoAネイティブとして設計されたサービスです。

ユーザー画面が存在しない。エージェントが直接叩くAPIとMCPサーバーが製品のコアです。

この違いは大きいです。toA市場が「既存サービスのエージェント対応」フェーズから、「toAネイティブのサービスが生まれる」フェーズに移行したことを示しています。

自社プロダクトは、このフェーズ移行にどう向き合うか。次のセクションで、PM・PdMが今すぐ動けることを整理します。

PMへの3つの示唆——自社プロダクトのtoA対応を考える

前回記事の「エージェント対応5条件」とHumworkの対応

前回の記事で提示した「エージェント対応5条件」に、Humworkがどう対応しているかを整理します。

5つ目が面白いんですよね。Humworkは「エラー時のリカバリー」そのものをサービス化しています。

エージェントが行き詰まること自体を、ビジネスチャンスとして捉えている。「課題をそのままプロダクトにする」という発想の純度の高さに、PMとして唸りました。

自社サービスが「エージェントから呼ばれる側」になる可能性

Humworkの事例から、PM・PdMとして考えるべき問いがあります。

「あなたのサービスは、エージェントから呼ばれる側になれるか？」

今の自社サービスは人間のユーザーが画面を操作して使うことを前提に設計されています。

しかし、Humworkの専門家のように「エージェントから呼ばれて、エージェントのために仕事をする」モデルが成立するなら、自社の専門知識やデータをエージェント向けに切り出すことも視野に入ります。

たとえばデザインレビューツール、コードレビューサービス、法務チェックサービス、マーケティング分析ツール。これらが「エージェントが困ったときに自動で呼ぶ先」として機能するなら、まったく新しい収益チャネルが開けます。

これは「toBかtoCか」という既存の二項対立に、toAという第三軸が加わったということです。

自社プロダクトのポジショニングを、この3軸で再評価してみる価値はあります。今日のプロダクトレビューで、「これ、エージェントから呼ばれる設計になってる？」と聞いてみてください。

HITLを「コスト」ではなく「品質担保レイヤ」として設計し直す

多くのプロダクトで、ヒューマンインザループは「コスト」として扱われています。

「AIで自動化したいのに、人間のチェックが必要だからコストがかかる」という文脈です。この悩み、プロダクトレビューで一度は出たことありますよね。

Humworkの構造は、この認識を転換します。

人間の介入は「コスト」ではなく「エージェントの問題解決能力を87%の確率で引き上げる品質担保レイヤ」です。しかも変動費モデルだから、使った分だけ。

PM的に考えると、これは自社プロダクトのHITL設計を見直すきっかけになります。

• 現在のHITLは「すべてのアウトプットを人間がチェックする」設計になっていませんか？
• エージェントが「自分で判断できないケース」だけ人間に渡す設計に変えられませんか？
• その「人間の介入」を、Humworkのように外部専門家にオンデマンドで委託できませんか？

この発想の転換だけで、自社プロダクトのコスト構造とスケーラビリティが大きく変わる可能性があります。

「これ、うちのプロダクトに置き換えると……」と思い当たるシーンがあれば、それが動き始めるサインです。

まとめ——toAはスタートアップの参入フェーズに入った

「toAって結局ふわっとしてない？」と思っていた方、Humworkは具体的な回答の一つです。

前回のtoA記事では、「エージェントがユーザーになる世界」を概念として提示しました。

Humworkは、その概念が現実のプロダクトになっていることを証明しています。YCに採択され、1,000名以上の専門家ネットワークを持ち、87%の解決率で動いている。toAは理論ではなく、すでに検証フェーズに入っています。

PM・PdMとして、この流れから取り出せるエッセンスは3つです。

1. toAネイティブなサービスが生まれ始めている——既存サービスのエージェント対応ではなく、最初からエージェントが顧客のサービスが成立し始めた
2. HITLの構造が逆転した——「人間がAIを監視する」から「AIエージェントが必要なときだけ人間を呼ぶ」へ
3. 自社プロダクトのtoA対応は待ったなし——エージェントから呼ばれる側のポジションを、今から設計できるかどうかが分岐点

自社プロダクトが、エージェントから見て「呼ぶ価値のあるサービス」になっているか。

その問いを、今日のプロダクトレビューに持ち込んでみてください。自社のAPIドキュメント、エージェントに読ませてみましたか？ そこから始められます。