リポジトリはまだ移さなかった

Cursor Originの発表を読み、Haru Spaceと似ていると思った。エージェントがコードを変更し、人がPRを確認し、Previewで結果を見て、マージすると本番へ進む。Haru Spaceも会話を作業につなぎ、AIが下書きを作り、人が確認した結果だけを公開する道を考えてきた。

だからといって「私たちもリポジトリから作ろう」とは結論づけなかった。似ているのは流れであり、サービスの目的は同じではない。Originはコードホスティングで、Haru Spaceは信頼する人々の会話、アイデア、確認済み成果をつなぐ協働空間だ。配管が似ているからとコーヒーマシンと消火栓を直結すると、朝がかなり刺激的になる。

公式発表から三つの経路を分けた

Cursorの公式資料ではOriginは三つに分かれる。

1. Origin独自リポジトリ — Cursorがコード、PR、権限をホストする。
2. GitHub同期リポジトリ — Originで閲覧、コメント、レビュー、マージできるが、GitHubが原本として残る。
3. Vercelアプリ — Origin PRにPreviewを作り、マージ後にProductionへデプロイする。

GitLabは今回のOrigin同期発表に含まれていない。ただしVercel自体はGitLabとMerge Request Previewをサポートする。正確な地図は次だ。

Originリポジトリ → Vercel

GitHub ↔ Origin → Vercel

GitLab → Vercel

三本を一本に縮めると図は短くなるが、将来の権限事故報告書は長くなる。

出典：Cursor Origin公式変更、Vercel Git連携、Vercel GitLab連携

似ているのは承認可能な作業フローだ

私が注目したのはリポジトリのブランドではなく状態遷移だった。

会話・アイデア → 公開可能な作業 → AI下書き → 検証 → Preview → 人の承認 → 公開

OriginではエージェントがbranchとPRを作り、人がレビューしてデプロイへ送る。Haru SpaceでもAIは成果を作れるが、公開境界では人が止まって確認する必要がある。Previewが緑でも、内容が公開可能か、画像権利が確認済みか、非公開会話が混じっていないかは分からない。build serverは速いが、空気を読む仕事はまだ人間に残る。

Haru Spaceでは通常のコードデプロイより状態を細かくしたい。

状態	意味
private	会話と内部資料、公開経路の外
proposed	人が公開候補として選択
generated	AIやツールが下書き作成
verified	事実・権利・個人情報・buildを確認
approved	人が公開承認
published	公開画面に反映
withdrawn	履歴を残して公開停止

最も重要なのはapprovedだ。自動化は前後を速くできるが、この行を飛び越えてはいけない。

当面GitHubを原本に保つ

Originはearly betaだ。公式発表もGitHubから始まったリポジトリはGitHubをsource of truthとして維持すると説明する。新しい画面を試しながら原本と復旧経路を残せる現実的な設計だ。

Haru Spaceにも同じ判断を適用する。

• 現在のGitHubリポジトリとPR承認フローを維持する。
• Vercel PreviewとProductionを分ける。
• 一つのプロバイダーAPIを製品全体に直接埋め込まない。
• GitLabやOriginは後から追加できるアダプターにする。
• マージが最終公開承認という現在の規則を保つ。

アダプターには最低限次が必要だ。

provider, repositoryId, ref, changeId, actor, commitSha, checkStatus, previewUrl

これでGitHub PR、GitLab Merge Request、Origin PRを内部では「レビュー可能な変更」として扱える。ボタン名より状態の意味を合わせる仕事だ。

最初の仮説を一つ下げた

最初はAI IDEがホスティングとデプロイを持てば、GitHubとGitLabの役割はすぐ縮むかもしれないと思った。公式資料を読んで確信度を一段下げた。OriginはGitHub同期を前面に置き、DepotやBuildkiteで既存GitHub Actionsを動かす道も用意する。今は代替より吸収と接続に近い。

この違いは製品判断で重要だ。競合の新機能を見て構造全体をコピーすると、問題より先にメニューが増える。Haru Spaceに新しいリポジトリ画面を作るより、どこで人が待ち、どの根拠で承認するかが見えるかを先に確認したい。

小さな実験は四つに限定する

1. プロバイダー中立イベント

   GitHub PRイベントを内部ChangeRequestへ変換し、プロバイダー名が製品判断に漏れないか確認する。

2. Previewと承認の分離

   Preview成功後もapprovedがなければ公開経路が開かないことを自動テストする。

3. 重複イベント防止

   webhookが二回来ても二重公開されないようprovider + changeId + commitShaで冪等性を確認する。

4. 取り下げ経路

   公開後に問題が見つかった場合、履歴を消さずwithdrawnへ移ることを検証する。

実ユーザーの会話、アカウント情報、内部セキュリティ設定は使わない。公開可能なダミー内容と分離したテストリポジトリだけを使う。今日の基準は小さな実験と長い監査記録だ。

結論

Cursor OriginはHaru Spaceが目指す方向の一部に似ている。エージェントが成果を作り、人がレビューし、Previewを通って公開される一つの道だ。ただし借りるべきものは新しいリポジトリではなく、人が承認できる状態と交換可能なプロバイダー境界だ。

だから今日はリポジトリを移さなかった。代わりに、後で交換できるドアに印を付けた。新居を契約する前にコンセント位置を測ったようなものだ。少し地味だが、引っ越し当日の腰には優しい。

今日の技術・市場全体はデイリーイシュー：コードの横に金利表が付いたにまとめた。