Y Combinator 観測：公開シグナルを制約付きの実験へ変える

この日付付き観測の目的

このノートは 2026-10-04 に読んだ YC の公開資料を記録する。特定の会社、製品、RFS 見出しがチームに適するという推薦や根拠ではない。 YC Requests for Startups は、応募者が必ず作るべきものではなく、YC が見たい例を挙げる資料だと説明する。公開シグナルを、解く摩擦、未確認の前提、最小で安全な実験を書くきっかけとして扱う。

1. 1YC の公開資料
2. 2利用者の摩擦と未検証の前提を書く

1. 1制約付きの試作
2. 2権限・データ・失敗の境界を測る

1. 1証拠
2. 2続行・修正・停止

RFS は市場予言でなく問題設定として読む

ここで扱うのは、その日に観測した 2026 Fall RFS ページである。三つの見出しを実作業へ翻訳できる。

A Cloud for Small Software

A Cloud for Small Software は、少人数向けの目的特化ソフトウェアを共有・配備しにくい問題を扱う。auth、permissions、任意コードを安全に共有することが難所である。二人用の CRUD ツールを作り、招待、権限取り消し、secrets の非露出、監査ログ、削除を試す。配備速度だけを測ると、中心にある共有境界を見落とす。

Multiplayer AI

Multiplayer AI は、長時間動く agent を複数人が観察、redirect、handoff できる形を問う。一つの read-only 調査タスクだけに実験を絞り、共同閲覧、誰が指示を変えられるか、変更履歴、競合の優先順位、停止を決める。回答品質と、チームが決定する権限を別に評価する。制御境界のない共同アクセスは協働でなく曖昧さを生む。

Self-Maintaining APIs

Self-Maintaining APIs は、API 提供者が破壊的変更で影響を受けるクライアントコードを検出し、修正 pull request まで作る構想である。公開サンプル repository と一つの合成した breaking change を使う。検出 recall、意図しない編集率、PR diff の可読性、test 通過、承認なしには merge しないことを測る。外部 agent に渡す権限と secrets の境界は、変換ロジックと同じく重要である。

企業は組み合わせる時の摩擦で読む

YC Startup Directory は企業を発見する入口に使い、製品の主張はその企業の documentation、security 資料、pricing、利用規約、公開 source へ戻って確認する。以下は観測日に読んだ公開説明である。batch と active status は YC 企業ページに属し、機能は各製品の documentation に属する。いずれもベンチマークや調達の推薦ではない。

Airbyte の YC ページ は active W20 と記し、公式 documentation はデータ複製と、MCP、Python SDK、HTTP API を使う AI agent の context layer を説明する。摩擦は、分散した業務データの接続、同期、検索である。小さな実験ではダミーの SaaS source 二つだけを接続し、同期遅延、schema 変更、credential rotation、アクセス制御、削除伝播を記録する。多数の connector は source の品質や data governance を保証しない。

PostHog の YC ページ は analytics、session replay、feature flags、experimentation、LLM observability などを一つの製品面として説明し、公式 documentation がある。摩擦は、出した機能が使われ、変更が結果を生んだかを問うために複数の観測ツールを運用することだ。匿名化した staging event、flag の二群、事前登録した主要指標、exposure event、kill switch を用いる。bot traffic、サンプル不足、同時リリースが残る限り、SDK だけでは因果を示せない。

Supabase の YC ページ は active S20 とし、Postgres、Auth、Row Level Security、Realtime、API を挙げる。公式 documentation は database、auth、storage、realtime、edge functions、framework guides を扱う。摩擦はバックエンド基盤を最初に組み立てることだ。架空の二組織・二権限のデータで、RLS が API、直接 SQL、Realtime、Storage の経路ごとに越権を拒否するかを自動 test する。速い初期設定は RLS policy、migration、backup、region、運用の責任を消さない。

4時間更新で守る境界

今後の 4 時間ごとの更新では、RFS の batch 名と見出しを日付付きのページ観測として残す。YC 企業の batch/status は documentation の機能主張と分け、version や release の情報も別に記録する。候補は一つずつ隔離環境で試し、成功・失敗条件、secrets を渡さない境界、削除手順を残す。この観測の価値は流行をひとまとめにすることではなく、検証できる仮説を小さくすることにある。

追補: 描画されたDirectoryは発見面であり静的データセットではない

2026-10-04 JSTに、公式Startup Directoryはブラウザでtitle、batch／industry／region filter、loading中のcompany listを伴って描画されました。可視ページはYCが5,000社超に投資してきたと述べます。これはYCの表示であり、独立監査済みの市場統計ではありません。動的描画のため、この観測は完全なDirectory export、現在の企業数、確認済みの更新日を主張しません。

2024〜2026年のパターンは、会社の発見と製品検証を分離することです。DirectoryまたはRFSで候補を得た後、可視のcompany URLとbatch/statusを日付付きYC観測として記録し、会社のdocumentation、security、pricing、terms、release notesを独立に調べます。dummy dataと削除手順で一つの統合を設計します。company pageやRFS topicは仮説を正当化できますが、需要、信頼性、資金健全性、顧客採用、適合性を証明しません。

RFSを読むための、日付付きの2024年の基準

YCの2024年2月16日のearly interview告知は、その週の前半に新しいRFS一覧を公開したと述べ、応募対象がそのテーマに限定されないことも説明している。これは当時促したいテーマの歴史上のsignalであり、企業の創業数や現在の応募期限ではない。「週の前半」からRFSの正確な公開日を推論しない。

時系列演習では、一つのrequestの本文と日付、後日の企業自身の説明、実際に扱う顧客課題を記録する。「テーマを募集した」「企業が一覧に載った」「動く製品を独立確認した」は別々の観測だ。2024年の資料と2026年10月4日に見たDirectoryを比較しても、可変profileだけではfeatureの公開日を確定できない。後に多くの企業が並んでも、最初の利用者の課題が解決したとは限らない。顧客workflowと採用の証拠を読んでから、その分野が成熟したかを考える。