Y Combinator 日本語図鑑

事業概要

プロダクト

• 作り手が企画と脚本を入力すると、動画エージェントが映像素材を生成する。
• 生成した映像を編集して作品ファイルとして書き出し、公開ページに掲載する。
• 公開した企画にファンが資金を出し、支援額と支援者が一覧で可視化される。
• 観客の視聴や支援の履歴を集計し、作り手の収益として算出して通知する。
• 作品ごとの支援状況と収益を一画面で確認できる管理機能を提供する。

技術アーキテクチャ（推定）

• 入力は作り手が投稿する企画書、脚本、参考画像とみられる。
• 映像生成は自社の動画エージェントがテキスト指示から行う構成と推定される。
• 生成物はクラウドに保存し、配信用に変換して公開ページへ配信するとみられる。
• 支援と視聴の履歴を決済事業者や配信基盤から取得し、収益額を集計する。
• ファン向け公開ページと作り手向け管理画面を同一基盤で提供すると推定される。

収益モデル

• 作り手が制作と公開の機能利用料を支払う構図とみられる。価格は非公開。
• ファンが作品へ支払う支援金から手数料を取る可能性がある。料率は非公開。
• 観客の視聴や購入による収益を作り手と分配する形態と推定される。

差別化

• 制作と資金調達と配信を一つの導線にまとめ、作り手の流出を抑える。
• 作品ごとにファンの支援履歴が蓄積し、後発が同じ関係を再現しにくい。
• 動画エージェントの生成品質と制作実績が評判として積み上がる。

日本展開時のリスク

• 生成映像の著作権と肖像権の処理方法が法令上明確でない部分がある。
• 資金調達の形態によっては資金決済法や寄付募集の規制対象になり得る。
• 国内の決済手段や税務処理への対応が利用者の参加障壁になり得る。
• 支援が集まる作品に偏りやすく、収益が安定しにくい構造がある。
• 制作物の品質に対する責任範囲が不明確で、苦情対応の負担が生じ得る。

日本での競合

• 国内にはAI映像の制作と資金調達を一体で提供する事業者が見当たらない。
• ファン支援ではpixivFANBOX、資金調達ではCAMPFIREが強い。
• 映像制作では生成AI各社のツールが個別機能として普及している。
• 直接の同型がないため、参入時の比較対象が存在しない状態にある。
• 決済と権利処理の整備が参入時の実務的な障壁となる。

事業概要

プロダクト

• 投入前のジョブ定義と過去の実行履歴を入力として受け取る。
• 必要とするGPU数と実行時間を予測し、適正な資源量を返す。
• コードと設定の変更案を生成し、研究者が自分で適用できる形で示す。
• 失敗する可能性の高いジョブを投入前に検出して警告する。
• スケジューラーに渡す前の段階で補正済みの投入案を出力する。

技術アーキテクチャ（推定）

• 顧客の計算基盤からジョブ定義・実行履歴・資源使用ログを取得するとみられる。
• エージェント型の収集かAPI連携で、スケジューラーの手前に入り込む構成と推定される。
• ジョブ種別やコード特徴を正規化し、資源量と成否を予測するモデルに通す。
• マルチモーダルな資源予測器を中核に据え、公表基準を上回ったとされる。
• 予測結果と提案を既存の投入手順に返し、履歴を蓄積して精度を更新する。
• 保存形態や提供方式は非公開で、常時接続型か一時参照型かは未確認。

収益モデル

• 計算基盤を運用する組織が、遊休削減と失敗回避の対価を支払う形と推定される。
• 課金単位は月額か従量か案件単位かを含め、価格は非公開。
• 研究機関と民間の計算基盤運用者が主な支払い主体になるとみられる。

差別化

• 大規模な並列計算基盤の運用経験を設計に直接反映している。
• 投入前の予測という工程に位置取りし、実行後の監視と競合しない。
• 失敗予測と資源予測を同じ履歴基盤で扱う点が再現しにくい。
• 蓄積した実行履歴が増えるほど予測精度が上がる構造と推定される。

日本展開時のリスク

• 大学や研究機関の調達は年度予算と入札手続きに縛られ期間が長い。
• 既存のジョブ管理系や課金系との接続仕様が非公開で検証が要る。
• 研究データを外部に送る前提への学内規程の審査が必要になる。
• 計算基盤の運用内製志向が強く、外部ツール導入の優先度が上がりにくい。
• 為替と価格帯次第で、国内予算枠に対する費用対効果の説明が重くなる。

日本での競合

• 国内のGPU計算需要は研究機関と生成AI開発企業に集中している。
• 計算基盤はクラウド大手と国内事業者の提供が中心で、運用改善は利用者負担になっている。
• 資源予測と失敗予測を専業で提供する国内事業者は確認できない。
• 直接の同型はなく、参入余地は運用改善の工程に残る。
• 計算基盤事業者が同種機能を自社服務に組み込む可能性は否定できない。
• 導入の壁は既存スケジューラーとの接続とデータ持ち出しの規程対応にある。

主要プレイヤー

• さくらインターネット — 国内データセンターのクラウド。
• Amazon Web Services — クラウド基盤。国内リージョンで提供。
• Google Cloud — クラウド基盤とデータ分析。

事業概要

プロダクト

• 顧客は施策の狙いと条件を文章の概要として提出する。
• 概要から対象顧客の絞り込み条件と配信先を決める。
• 過去施策とブランド指針を参照し制作物を生成する。
• 制作物をHubSpot、WordPress、LinkedInへ設定し配信する。
• 配信結果と修正指示を次回の施策条件に反映する。

技術アーキテクチャ（推定）

• 顧客のHubSpotやMarketoから過去施策と顧客データをAPI連携で取得するとみられる。
• 公開されたブランドガイドライン資料を読み込み表現規則を抽出するとみられる。
• 概要文を解釈し対象条件と配信先を決める処理に生成モデルを使うと推定される。
• 生成した制作物を各ツールの画面上の操作で投入する型のエージェントとみられる。
• 施策履歴と修正指示を蓄積しブランド適合の判定に再利用すると推定される。

収益モデル

• 企業のマーケティング部門が施策の制作と配信の実行に対して支払う。
• 従来は代理店へ支払っていた設定作業の費用を置き換える位置づけである。
• 課金単位は施策件数か利用席数と推定されるが、価格は非公開。

差別化

• 顧客ツール内の操作履歴と修正指示が学習材料として蓄積する。
• 配信設定の代行により日々の運用の入口を握る。
• ブランド再現の精度が修正履歴の量に依存し後発が追いにくい。
• 連携先ツールの操作仕様への対応範囲が実務上の障壁になる。

日本展開時のリスク

• 顧客の個人情報を外部エージェントが扱う際の委託先管理が問われる。
• 景品表示法や薬機法など表現規制への適合確認は顧客側に残る。
• 国内企業は代理店経由の稟議と相見積もりが多く直接契約に時間がかかる。
• 国内向け配信ツールは独自仕様が多く操作代行の対象範囲が限られる。
• 施策単位の課金は代理店の月額契約と比較され価格の妥当性を示す必要がある。

日本での競合

• 国内では施策の管理と配信を行う基盤が中心で実行作業の代行は少ない。
• HubSpot JapanやSalesforce Japanが中堅・大企業の配信基盤を握る。
• 制作と設定を代理店に委ねる商習慣が残り内製化の余地は限定的である。
• 施策の制作から配信までを一貫して代行する同型は確認できない。
• 参入には国内ツールの操作対応と個人情報の取り扱いの整備が要る。

主要プレイヤー

• HubSpot Japan — マーケ・営業・サポートの統合CRM。
• Salesforce Japan — 営業支援と顧客管理のクラウド。
• Zoho Japan — 業務アプリ群を低価格で提供。

事業概要

プロダクト

• 利用者は担当させたい業務と使用するエージェントを登録する。
• エージェントの発言と作業結果を一つの画面に集約する。
• エージェント同士の依頼と応答を記録し、作業の受け渡しを追跡する。
• 未処理の作業と重複した作業を一覧で返す。
• 実行の履歴を時系列で残し、後から経緯を確認できる。

技術アーキテクチャ（推定）

• 顧客が接続した業務ツールやエージェントの実行基盤から履歴を取得するとみられる。
• 接続はAPI連携が中心で、外部の実行環境とは別途つなぐと推定される。
• 発言と作業を同一の識別子に名寄せし、時系列の作業記録として正規化する。
• 依頼と応答の対応関係を照合し、未完了の作業を抽出するとみられる。
• 記録はワークスペース単位で保存し、画面とAPIの両方から参照させる。

収益モデル

• 企業がエージェント用のワークスペース利用料を支払う形とみられる。
• 課金単位は利用席数か実行量と推定されるが、価格は非公開。
• 無料の試用枠を設けているかは未確認。

差別化

• エージェント間の依頼と応答の履歴がそのまま資産として蓄積される。
• 人間向けの連絡ツールではなく、実行主体の調整に設計を寄せている。
• 業務の受け渡しを同一画面で完結させ、外部への往復を減らす。
• 創業直後で導入実績は未確認。

日本展開時のリスク

• 既存のグループウエアと用途が重なり、導入理由が立ちにくい。
• エージェントの操作権限と監査記録の扱いが社内規程に触れる可能性がある。
• 国内企業は業務データを外部の実行基盤に置くことを避ける傾向がある。
• 担当者が一人であり、導入支援と保守の体制が未整備とみられる。
• 価格が非公開で、費用対効果の説明ができない。

日本での競合

• 国内にはエージェント同士の連携専用の製品が見当たらない。
• 連絡と協働の領域はChatworkやMicrosoft Teamsが広く使われている。
• 生成AIを試す企業は増えたが、複数エージェントの運用は事例が少ない。
• 直接の同型がないため空白は大きいが、需要の存在は未確認。
• 既存グループウエアの機能追加という形で埋まる可能性がある。
• 導入時は権限設計と監査の整備が壁になる。

主要プレイヤー

• Chatwork — チャットとタスク管理のビジネスツール。
• サイボウズ — グループウェアと業務アプリ。
• Backlog — 課題管理とWikiを備えたプロジェクト管理。

事業概要

プロダクト

• 見積書や注文書を取り込み、品目と数量を抽出する。
• 過去の見積もりと原価データを照合し、参考価格を算出する。
• 受注情報を基幹システムへ登録し、重複や欠損を検出する。
• 請求書を生成し、金額と税区分の整合を確認して出力する。
• 処理結果を一覧で返し、担当者が直した差分を記録する。
• 顧客の業務データで個別モデルを訓練し、判断精度を更新する。

技術アーキテクチャ（推定）

• 顧客の基幹システムやメール、書類から見積・注文・請求のデータを取得するとみられる。
• 取得は業務システムの連携機能やファイル取り込み、画面操作の記録で行うと推定される。
• 品目名や取引先名を名寄せし、表記の揺れを正規化して照合するとみられる。
• 顧客固有のデータで言語モデルを調整し、見積項目や金額の候補を生成すると推定される。
• 生成結果は既存の台帳と突き合わせ、規則違反や欠損を検査してから返すとみられる。
• 学習済みのモデルと処理履歴は顧客単位で分離して保管すると推定される。

収益モデル

• 製造業者から月額または案件単位で利用料を受け取る形態とみられる。
• 導入支援や個別モデルの構築を初期費用として請求する可能性がある。
• 価格は非公開。

差別化

• 顧客の見積・受注履歴を学習に使い、導入先ごとに精度が上がる構造を持つ。
• 事務処理の実行まで担い、基幹システムとの接続点を押さえる。
• 人件費の回避額を導入判断の根拠として示せる点が異なる。

日本展開時のリスク

• 見積もりや請求の誤処理が商取引上の損害に直結しやすい。
• 基幹システムが多様で、接続のための個別開発が導入の障壁になる。
• 顧客の原価や取引条件を扱うため、データ保管の範囲が問われる。
• 製造業の事務は取引先ごとの慣行が強く、標準化が難しい。
• 人件費の回避を前提とした価格が、国内の賃金水準に見合うか不明である。

日本での競合

• 国内の製造業向け業務製品は生産管理や原価計算が中心である。
• 見積もりから請求までの事務処理は依然として人手に依存する。
• アラジンオフィスやTECHS-BKは近接するが、自動化の範囲が異なる。
• 個別モデルで複数工程を処理する同型の製品は確認できない。
• 導入時は基幹システムとの接続と、誤処理時の責任分界が壁になる。

主要プレイヤー

• マネーフォワード — 会計・経費・給与をクラウド化。
• 勘定奉行 — 中堅・大企業向けの会計システム。
• freee — 会計・人事労務・請求書をクラウド化。

事業概要

プロダクト

• 利用者はブラウザーから仮想計算機を起動し、作業を始める。
• アプリごとに独立したGPU・入力・実行環境を割り当てる。
• WindowsとLinuxのアプリを同一セッション内で同時に動かす。
• 人とエージェントが同じ画面群で並行して操作できる。
• 起動は数秒で、端末を問わずブラウザーから接続できる。

技術アーキテクチャ（推定）

• 顧客のブラウザーから接続し、画面と入力操作を送受信するとみられる。
• クラウド基盤上にアプリ単位の仮想計算機を生成し、GPUを割り当てる。
• WindowsとLinuxの実行環境を同一セッションで束ねるとみられる。
• 利用状況や課金対象の計測情報を基盤側で収集すると推定される。
• 公開情報では保存方式や調達先クラウドは未確認である。

収益モデル

• 法人利用者から仮想計算機の利用に対して課金する。
• 課金単位は月額か従量課金とみられるが、価格は非公開。
• 個人開発者向けの従量プランの有無は未確認。

差別化

• アプリごとに計算機を分ける設計で並列数の上限を外している。
• 人間とエージェントを同じ環境で同時に動かせる点が構造的に異なる。
• 独自OSの実装蓄積が差別化の源泉とみられるが、実績は未確認。

日本展開時のリスク

• 企業データを海外クラウドに置く場合の保管要件の確認が必要。
• 既存の仮想デスクトップや社内システムとの接続仕様が不明。
• 国内販売チャネルやサポート体制は未確認である。
• GPUを含む従量課金は国内企業の予算感に合うか未検証。
• 創業直後で導入実績がなく、調達・審査で不利になりうる。

日本での競合

• 国内では仮想デスクトップ型の提供が主流で、設計思想が異なる。
• 大手クラウド各社が企業向け計算基盤を握り、営業網が強い。
• アプリ単位の独立環境を並列提供する同型は見当たらない。
• 空白は大きいが、利用実績と互換性の証明が参入条件になる。
• 国内の再販・SIer経由の商流に入れるかが普及の分岐点となる。

主要プレイヤー

• Amazon Web Services — クラウド基盤。国内リージョンで提供。
• Microsoft Azure — クラウド基盤と業務アプリ。
• Google Cloud — クラウド基盤とデータ分析。
• さくらインターネット — 国内データセンターのクラウド。

事業概要

プロダクト

• クラウドの設定情報とコード、コンテナ情報を取り込む。
• 外部の監視・セキュリティ製品の検知結果も同じ画面に集約する。
• 取り込んだ情報を知識グラフで関連づけ、影響範囲を判定する。
• 検知した問題を自動で選別し、実際に悪用できるかを検証する。
• 修正案を生成し、承認後に環境へ適用する。
• 判断が難しい案件だけ担当者に引き継ぎ、判断理由を残す。

技術アーキテクチャ（推定）

• 顧客のクラウド契約と連携し、設定や資産の一覧をAPI経由で取得するとみられる。
• コード管理と継続的インテグレーションの履歴を連携し、変更差分を取り込むと推定。
• 監視やセキュリティ製品の検知結果を外部連携で受け取り、資産単位で名寄せする。
• 収集した情報を知識グラフとして保持し、依存関係から影響範囲をたどる。
• 修正操作は権限を絞った実行環境から行い、履歴を残す構成とみられる。

収益モデル

• クラウドを運用する企業が年間契約で利用料を支払う形態とみられる。
• 課金単位は保護対象の資産数か利用者数と推定されるが、価格は非公開。
• 導入支援や初期設定を別途有償で提供する可能性がある。価格は非公開。

差別化

• コード・クラウド・監視製品の情報を一つのグラフに蓄積する点が違い。
• 修正の実行まで担うため、顧客の運用フローに入り込む。
• 導入が進むほど資産の依存関係のデータが厚くなる。

日本展開時のリスク

• 本番環境の修正権限を外部サービスに渡すことへの抵抗が大きい。
• 金融や医療では監査対応の証跡要件が厳しく、導入審査が長期化する。
• 既存の開発・監視ツールとの連携設定に相応の作業が要る。
• 国内のクラウド再販・運用代行会社との販売チャネル構築が課題。
• 障害時に自動修正が原因か否かを切り分ける手段の説明が要る。

日本での競合

• 国内のクラウドセキュリティは診断と監視が中心で、自動修正は少ない。
• 開発工程の診断では国内専業の企業が実績を持つ。
• 大手の総合構築事業者やセキュリティ専業は監査・運用支援が中心。
• 直接の同型はなく、空白は残っている。
• 修正権限の委譲と監査証跡の説明が参入の壁になる。
• クラウド事業者自身のセキュリティ機能との重複も争点になる。

主要プレイヤー

• ラック — セキュリティ監視と診断。
• トレンドマイクロ — セキュリティソフト。
• デジタルアーツ — Webフィルタリング。
• FFRI — セキュリティ研究と製品。

事業概要

プロダクト

• 利用者は手元のスキル定義と接続設定をアプリに読み込ませる。
• 50以上のモデル提供元を切り替え、同じ操作画面から呼び出せる。
• 接続済みの道具と手順をひとまとめにし、配布できる形で書き出す。
• 受け取った側は同じ設定を自分の端末に取り込み、作業環境を再現する。
• ソースコードは公開され、利用者が自ら改変して動かせる。

技術アーキテクチャ（推定）

• スキル定義、接続設定、過去の手順は利用者の端末から読み取るとみられる。
• 外部モデルへの呼び出しは各提供元のAPIを経由し、鍵は端末側で保持する推定。
• 接続口の仕様に沿って外部の道具を呼び出し、結果を会話の文脈に戻す。
• 共有用の設定は構造化された形式に正規化し、配布できる単位にまとめる。
• 保存は端末内の領域が中心で、サーバー側の処理は限定的と推定される。
• 更新の配布は公開されたリポジトリ経由で行う形とみられる。

収益モデル

• アプリのダウンロードと利用は無料で、提供元は課金を公表していない。
• 有料プランの有無、課金単位、価格は非公開。
• モデル提供元への利用料は利用者が各社へ直接支払う形とみられる。
• チーム向けの管理機能を課金対象にする可能性は未確認。

差別化

• 実装が公開され、利用者が自ら改変して動かせる。
• 複数のモデル提供元を同じ画面で扱え、特定の提供元に縛られない。
• 設定を配布物として共有でき、チーム内の再現性を保てる。
• 接続口の仕様変更へ追随する速度は、規模の小ささが支えになる。
• 創業から日が浅く、導入実績の蓄積は未確認。

日本展開時のリスク

• 無料配布が前提のため、有料機能への転換経路が未確認である。
• 外部モデルと外部の道具の利用条件は利用者側で順守する必要がある。
• 端末に置く接続鍵と業務データの管理規程を社内で整える必要がある。
• 既存の業務システムへつなぐには個別の接続実装が要る場合がある。
• 国内の販売代理店や導入支援の体制は未確認である。

日本での競合

• 国内にデスクトップ型で複数モデルを束ねる同型製品は見当たらない。
• 生成AIの利用基盤はクラウド各社と国内の再販事業者が占めている。
• 業務システムとの接続は各社の個別開発と構築事業者の領域である。
• 空白は大きいが、無料配布の製品は導入決裁の根拠を作りにくい。
• モデル提供元の規約と社内の情報管理規程が導入時の主な壁になる。

事業概要

プロダクト

• 宣言型の手順書を入力として受け取る。
• 手順を実行基盤が解釈し、各工程の状態を保持する。
• 外部接続や待機を含む長い処理を順に実行する。
• 失敗した工程を検知し、再試行や巻き戻しを適用する。
• 実行履歴と現在の状態を開発者に返す。
• 基盤自体は公開リポジトリで配布する。

技術アーキテクチャ（推定）

• 手順書は独自の宣言型言語で記述され、設定として読み込まれるとみられる。
• 実行基盤は外部のAPIや社内システムへ都度接続し、結果を取得すると推定される。
• 工程ごとの状態を保存し、中断後の再開に備える設計とみられる。
• 失敗や遅延を検知して再試行や分岐を選ぶ仕組みと推定される。
• 提供形態はライブラリと実行環境で、自社側での運用も選べるとみられる。

収益モデル

• 基盤はオープンソースで無償提供とみられる。
• 有償の課金単位や価格は非公開。
• ホスト型の実行環境を将来用意する可能性があるが未確認。

差別化

• 宣言型言語と実行基盤を一体で設計している点。
• 長時間処理の状態管理と再開の実装蓄積。
• オープンソースによる導入のしやすさ。

日本展開時のリスク

• 国内の導入実績がなく、採用判断の材料が乏しい。
• 社内システム接続時の権限設計と監査対応の負担が重い。
• 無償の公開品であり、有償化の道筋が未確認。
• 可用性の保証水準が示されておらず、基幹用途に置きにくい。
• 3人体制で、国内向けの販売支援体制がない。

日本での競合

• 国内に同型の宣言型エージェント基盤を提供する事業者は見当たらない。
• 近接領域は開発者向けのテスト自動化や業務ワークフロー製品。
• 大手クラウド各社の実行環境が代替手段になり得る。
• 基幹系接続や監査対応は国内事業者が担う領域。
• 直接競合が不在な分、導入実績の積み上げが参入の壁になる。

事業概要

プロダクト

• 利用者が調査目的と制約条件を文章で入力する。
• システムは目的を下位の問いへ分解し調査計画を生成する。
• 数千のAIエージェントを並列に走らせ外部情報を収集させる。
• 収集結果を突き合わせ根拠付きの調査報告書を出力する。
• 途中経過と根拠を一覧で返し追加調査の指示を受け付ける。

技術アーキテクチャ（推定）

• 公開ウェブや論文、顧客が渡す資料を入力源とするとみられる。
• 取得は巡回収集とAPI連携を組み合わせると推定される。
• エージェントごとに担当論点を割り当て並列に検索と読解を回す。
• 重複した主張を名寄せし出典との照合で信頼度を付す。
• 生成物は根拠リンク付きで保存し後から追跡できる形で返す。

収益モデル

• 法人顧客が調査テーマ単位または月額で契約する形とみられる。
• 同時実行するエージェント数や案件数に応じた従量課金も想定される。
• 価格は非公開。

差別化

• 並列エージェントの運用ノウハウが蓄積され調査品質が反復で上がる。
• 問いの分解から報告までを一続きで担い作業場所を占有する。
• 出典照合の履歴が残り再現性の高い成果物を出せる。

日本展開時のリスク

• 調査対象データの保管場所と越境移転の扱いが契約上の論点になる。
• 生成物の著作権や二次利用の範囲は法解釈が固まっていない。
• 国内企業は外部委託より社内調査を選ぶ商習慣が残る。
• 成果の妥当性を誰が保証するかで稟議が止まりやすい。
• 費用の妥当性を判断できる導入事例が国内にない。

日本での競合

• 国内に自律型の研究基盤を提供する事業者は確認できない。
• 生成AIを使った情報整理や調査支援は複数社が手掛ける。
• コンサルティング会社の調査部門が実務上の代替になる。
• 直接の同型がないため空白は大きいが需要の裏付けは薄い。
• 機密情報を扱うため調達審査の通過が参入の壁になる。

主要プレイヤー

• ストックマーク — 企業情報の分析。
• ブレインパッド — データ分析の支援。
• エクサウィザーズ — AIの社会実装。