Y Combinator 日本語図鑑（19/77ページ）｜No.183-193の企業10社

日本市場の見立て

ブルーオーシャン競合あり／空白ありレッドオーシャン国内王者が市場を掌握

767社

Y Combinator採択企業のうち、ソロ開始・存続・買収条件で絞った767社。日本市場の見立ては公開情報からの推定。1ページ10社で全文を掲載。

815原本

48除外

123図鑑公開

77ページ

183

Sitefire

AIエージェント経由のブランド集客基盤

Sitefireは、AIエージェントに自社商品を発見・利用してもらいたいブランド向けに、コンテンツとツールを提供する事業だ。どのコンテンツがAI上での露出につながるかを分析し、露出を高めるコンテンツを自動作成するほか、利用企業はサイト内外の施策を実行して売上成長を目指す。収益モデル、料金、顧客獲得経路、運営体制や原価については掲載情報に記載がない。チームは2人で、2026年2月創業、ステータスは活動中とされているが、売上や利益などの財務数値は示されていない。AIエージェント上の露出分析からコンテンツ作成、施策実行までを結び付ける点が強みとなる。AIエージェントの普及や露出施策の効果に左右されるほか、料金や収益性、実績が不明な点は主なリスクである。

図鑑を準備中

184

Robby

住宅設備事業者向けの売上機会発掘・成約支援

Robbyは、住宅設備や修理などの訪問サービス事業者に、追加の売上機会を見つけて成約を後押しするAIエージェントを提供する。顧客情報と第三者データを組み合わせて毎日数十件の新規見込み客を抽出し、現場技術者に提案時の要点を示すほか、事業責任者向けに売上管理の司令塔を提供する。収益モデル、料金、顧客獲得チャネル、運営体制や原価は開示されていない。複数の有料顧客がおり、各社で毎週6桁規模の追加売上機会を発掘しているほか、公開初日には1時間以内に4万ドルの新規受注を支援した。技術者への同行や事務所内の各職種の観察を通じて現場業務を理解している点が強みである。一方、顧客数や継続率、実際に実現した追加売上、データの正確性は不明であり、提案の現場定着や顧客情報の適切な利用が課題となる。

図鑑を準備中

185

Emdash

複数の開発エージェントを並行稼働する開発環境

Emdashは、エンジニアリングチーム向けに、複数のコーディングエージェントを並行稼働させてソフトウェア開発を速めるデスクトップアプリを提供する。オープンソースで、特定の提供元に依存しない設計だが、収益モデルや課金、価格は公開情報に記載がない。獲得チャネルや運営体制、原価についても詳細は示されていない。2026年2月創業で、チーム規模は2人であり、売上や利益などの財務数値は開示されていない。複数の開発エージェントを同時に活用できることと、提供元を限定しないことが特徴だ。小規模なチームでの運営に加え、各エージェントの品質や対応範囲、開発コードの取り扱いが導入上のリスクとなる。

図鑑を準備中

186

Reframe

ハードウェア部品の調達を自動化する市場

Reframeは、ハードウェア開発チーム向けに既製部品と特注製造部品の調達を仲介する事業だ。信頼できる供給業者への接続とAIエージェントによる調達工程の一貫した自動化を提供し、少人数での事業拡大を支援する。収益モデル、価格、顧客獲得経路、供給業者との契約条件や運営原価は公開されていない。2026年2月創業で、拠点は米国サンフランシスコ、チーム規模は1人だ。売上高や利益などの財務数値も示されていない。信頼性の高い製品向け部品を製造した供給業者とのつながりと、調達業務の自動化が強みとなる一方、事業実績や供給網の規模、少人数運営の継続性は確認できない。

図鑑を準備中

187

Approxima

ソフトウェア保守を自動化する開発エージェント

Approximaは、企業の開発チーム向けに、保守作業や不具合修正、段階的な機能更新を進める開発エージェントを提供する。エージェントが作業範囲を定め、コードを書き、隔離された環境で修正を一貫して検証したうえで、本番環境への反映まで行う仕組みだ。顧客獲得はデモの予約を案内しているが、価格、課金方式、売上、原価や運営体制の詳細は開示されていない。2026年1月創業で、カナダのトロントを拠点とし、チームは2人である。日常的な保守を自動化し、人間の開発者が新しい企画に注力できる点が強みとなる。自動生成したコードの品質や本番環境への反映に伴う安全性、企業システムへの導入実績や事業規模が不明な点は主なリスクだ。

図鑑を準備中

188

Chamber

機械学習基盤の監視・障害対応自動化

Chamberは、機械学習チーム向けに、クラウド上のAI基盤の監視や障害対応を自動化するエージェントを提供する。エージェントが継続的に異常を監視し、原因を分析して問題を解決するほか、複数のクラウドにまたがる処理の性能と規模を最適化する。料金体系、販売経路、運営体制や原価の詳細は開示されていない。2026年1月創業で、チームは4人だが、売上や利益などの財務数値は示されていない。研究者や機械学習エンジニアの手作業を減らし、計算資源の無駄やGPUのボトルネックを抑える点が強みとなる。実績や効果を裏付ける数値がなく、複数クラウド環境への対応範囲や自動修復の信頼性も主な確認事項である。

図鑑を準備中

189

Patientdesk.ai

歯科医院の予約と決済と保険を自動処理するAI

公式サイト

競合あり／空白あり歯科向け予約支援の国内サービスは複数あるが、予約と決済と保険を一体で扱う同型は確認できない。

事業概要

プロダクト: 患者の電話やネット予約を受け取り、空き枠と処置内容を照合して候補日時を返す。
予約時に患者情報と保険資格を突き合わせ、自己負担額を計算して提示する。
カード決済の可否を判定し、決済結果を予約記録に紐づけて保存する。
キャンセルと無断欠席の履歴から枠の埋まりやすさを採点し、医院に示す。
医院の予約台帳を監視し、単価の高い処置の予約を優先して割り当てる。
技術アーキテクチャ（推定）: 医院の予約台帳、電子カルテ、電話音声、ネット予約フォームからデータを取得するとみられる。
電話は音声認識で文字起こしし、発信の意図と希望日時を抽出する方式と推定される。
患者名と生年月日、保険資格を名寄せし、重複予約や資格切れを照合する。
保険診療の点数と自己負担は規則ベースで計算し、外部の決済網に接続する。
予約と決済の結果を医院側の台帳へ書き戻し、監査用の履歴を残す。
枠ごとの成約確率を過去実績から scoring し、割当順の判断に使うと推定される。
収益モデル: 歯科医院が予約処理の利用料を月額または契約単位で支払う形態とみられる。価格は非公開。
決済の処理件数や取扱高に応じた従量課金を併用する可能性がある。価格は非公開。
保険照合や受付代行を加えた上位契約を設ける余地がある。価格は非公開。
差別化: 予約と決済と保険を同じ記録で扱い、医院の日次業務に入り込む。
院ごとの予約傾向と失客の型が蓄積し、枠割当の精度が上がる。
保険資格の照合履歴が残り、他社への移行コストが高くなる。
日本展開時のリスク: 保険資格の確認と点数計算は制度改正への追随が欠かせない。
患者の診療情報は要配慮個人情報に当たり、保管場所の説明を求められる。
電話応対の自動化は高齢の患者と医院スタッフの運用負荷を招きうる。
レセプト電算や既存の予約台帳との連携仕様が医院ごとに異なる。
決済代行と保険請求の間で責任分界が曖昧になりやすい。

日本での競合

歯科向けの予約と受付支援は国内ベンダーが先行し、導入実績を積んでいる。
予約管理は既存ベンダーの台帳が中心で、置き換えの障壁が高い。
窓口での現金精算が多く、予約と決済を一括で扱う例は限られる。
保険資格のオンライン確認は公的基盤の整備状況に左右される。
予約と決済と保険を一体で扱う直接の同型は、公開情報では確認できない。

出典：Y Combinator / Patientdesk.ai。技術アーキテクチャは公開情報からの推定。

191

Synthetic Sciences

自律型科学を支える研究基盤

Synthetic Sciencesは、自律的な科学研究を可能にする基盤を開発する研究所で、研究者や科学技術分野の組織を対象とする。科学研究の検証に時間と費用がかかり、結果も不完全になりやすいという課題に対し、ツール、評価手法、学習環境、アルゴリズム、モデルを開発する。収益モデル、課金方法、価格、顧客獲得チャネル、運営体制、原価は公開情報に記載がない。2026年2月創業で、チーム規模は2人である。売上や利益などの財務数値は示されていない。検証工程の効率化を複数の技術要素から目指す点が強みだが、商用化の状況や実績は不明であり、少人数体制や開発・検証の難しさが主なリスクとなる。

図鑑を準備中

192

Parameter

アプリと基盤の継続的な脆弱性検証

Parameterは、アプリケーションやインフラを運用する企業向けに、AIエージェントによる継続的な侵入テストを提供する事業だ。エージェントが24時間365日テストを実施し、重大な脆弱性を発見して検証することで、攻撃者に悪用される前の対処を支援する。年1回程度の侵入テストを継続的な検査に置き換える仕組みだが、料金体系や販売チャネル、運営体制の詳細は公開されていない。2026年1月創業で、チームは11人であり、売上や利益などの財務数値は示されていない。継続的な検査と脆弱性の検証を自動化する点が強みである一方、検査の精度や誤検知、顧客環境へのアクセス管理が導入上のリスクとなる。

図鑑を準備中

193

Laurence

Amazon広告の入札を確率モデルで自動調整

公式サイト

競合あり／空白あり国内にもAmazon広告の運用代行や分析ツールはあるが、利益を目的関数にした自動入札は確認できない。

事業概要

プロダクト: 広告アカウントの入札額とキーワードを連携機能で受け取る。
売上・広告費・在庫の実績を日次で取り込み、利益を計算する。
価格帯や曜日ごとの需要の確率分布を推定し、期待利益を試算する。
入札額とキーワード構成の変更案を生成し、配信側へ反映する。
改善額と純利益の推移を日次で返し、撤退の条件も示す。
技術アーキテクチャ（推定）: 顧客の広告アカウントと販売実績を連携機能で取得するとみられる。
在庫・原価・返品の数値を会計や販売管理の仕組みから取り込むと推定。
商品名と広告グループを名寄せし、日次の時系列に正規化する。
需要と入札の変動を確率モデルで推定し、期待利益を算出する。
変更案を段階的に配信し、結果を学習して再調整する仕組みとみられる。
判断履歴と成果は管理画面と日次レポートで提供すると推定。
収益モデル: Amazonブランドが広告運用の委託料を月額で支払う形態とみられる。
広告費に対する一定率、または改善額に連動する課金の可能性がある。
価格は非公開。
差別化: 入札判断と実売結果の対応履歴が顧客ごとに蓄積される。
広告枠の消化ではなく利益を目的関数に置く点が運用代行と異なる。
確率モデルの再学習に運用期間のデータが要り、乗り換え費用が生じる。
日本展開時のリスク: 景品表示法や薬機法など、商材ごとの広告表現の確認が要る。
Amazonの広告配信の仕様変更で機能が制約される恐れがある。
原価や在庫のデータを外部に預けることへの抵抗が導入の壁になる。
運用代行会社との既存契約があり、切り替え交渉が長引く可能性がある。
効果が短期で出ない商材では、月額費用の妥当性が問われる。

日本での競合

Amazon広告の運用は代理店とツールが担い、裾野が広い。
国内に利益を目的関数にした自動入札の専業は確認できない。
広告費の最適化ツールはあるが、原価まで含める例は少ない。
大手の物販事業者は内製の分析チームを持つ場合がある。
参入には広告基盤の仕様追随と、効果指標の合意が要る。

主要プレイヤー

Amazon.co.jp — 国内最大級のECモール。
ブレインパッド — データ分析の支援。

比較軸	Laurence	Amazon.co.jp	ブレインパッド
主な用途	Amazon広告の入札自動調整	ECモール	データ分析
提供範囲	入札から効果測定まで	物販	企業
課金	非公開	手数料	案件単位
強み	利益を目的関数にした確率モデル	物流網	分析人材

出典：Y Combinator / Laurence / Amazon.co.jp / ブレインパッド。技術アーキテクチャは公開情報からの推定。