一つのリポジトリを越え、グループが自分のプロジェクトを持つまで

この記事は、2026年7月29–31日のGit記録、設計文書、運用上の問題記録をもとに書き直したHaru Spaceの開発回顧だ。公開に不要なグループ識別子、ローカルパス、内部アドレス、認証情報、個人の会話は含めていない。

初期のHaru Spaceは、一つのプロダクトと一つのリポジトリをうまく運用する問題に近かった。しかし、グループが自分のプロジェクトを始め、自分の公開サイトを作り、自分のAIペットへ作業を任せるようになると、問いは変わった。

一つのアプリにメニューを追加すれば十分なのか。それとも、グループごとにコードと反映先、公開範囲と承認責任まで実際に分ける必要があるのか。

私たちは後者を選んだ。ただし、リポジトリを増やすだけでは独立したプロジェクトにはならなかった。

グループのプロジェクトが独立しているとは、コードが別の場所にあることではない。誰が読み、変え、公開できるのかが、最後まで混ざらないということだった。

まず公開サイトを非公開アプリから切り離した

最初の実験はHaru Journalだった。グループの記事を公開するサイトをHaru Space内部のページにせず、別のリポジトリと別のデプロイプロジェクトとして作った。

この選択は、画面デザインより先にデータ境界を変えた。

• 公開サイトは、ログインせずに読める静的な画面にした。
• 記事と画像は、公開用リポジトリ内で確認済みのファイルだけを使用した。
• 非公開チャット、メンバー、アカウント、グループ内部文書を公開ビルドが直接読まないようにした。
• 下書きは作業ブランチで作り、三言語、スキーマ、権利、公開範囲を確認したうえで、人がPRをマージしたときだけ公開されるようにした。
• 公開サイトには、リポジトリ書き込み資格情報や管理者セッションを置かなかった。

コメントやリアルタイムAI機能を最初から付けなかったのも、同じ理由だった。入力を受け付けた瞬間に、スパム、通報、個人情報、モデル費用、保存方針も一緒に生まれる。まずは読み取り専用の公開面を安定して開き、責任を持って運用できる準備が整った後に対話機能を加えることにした。

静的サイトはコスト面でも合っていた。閲覧のたびにサーバー関数やデータベースを起こさず、CDNから配信できる。画像も保存する原本と、実際に届けるサイズを分けた。グループの独立性のために別プロジェクトを作っても、待機コストまでグループ数に比例させる必要はなかった。

リポジトリ接続は、作業可能になるための一部分にすぎなかった

次の問題はAI作業だった。GitHubやGitLabの接続画面に「確認済み」と表示されても、ペットがそのコードを読み、変更し、結果をリポジトリへ反映できるとは限らなかった。

実際の流れには、異なる四つの接続があった。

1. Haru Spaceが現在のグループ、リポジトリ、基準ブランチの関係を確認する。
2. ゲートウェイが、そのグループの会話用・作業用プロジェクトポリシーを把握する。
3. インストール型の実行環境が、承認済みリポジトリを決められた隔離境界の中に準備する。
4. 別の反映用実行環境が、人の承認を受けた変更だけを作業ブランチへ書き込む。

一段階でも欠ければ、接続画面は緑色なのに実作業は失敗し得た。一方で、新しいグループの設定が一つ間違っただけで、既存グループ全体が止まってもいけなかった。

そこで、誤りや衝突のある接続は、そのグループだけを閉じるようにした。曖昧な接続を別のプロジェクトへ自動的に置き換えず、会話プロジェクトは読み取りだけ、作業プロジェクトは承認された編集だけを許可した。リポジトリ書き込み資格情報はAI実行プロセスへ渡さず、反映段階でのみ短時間使用した。

設定項目が増えたようには見えた。しかしグループのプロジェクトが増えるほど、「似ているリポジトリを自動で選ぶ」という便利さが最も危険な動作になる。接続失敗は直せる。別グループのコードを読み書きして成功してしまった場合は、はるかに復旧が難しい。

手動登録は長く続かなかった

初期には、新しいプロジェクトが増えるたびに、運用者が実行環境とゲートウェイの許可一覧を合わせた。数件までは対応できた。しかし実際には、プロジェクト名、作業用と会話用の区別、リポジトリの位置、基準ブランチ、各実行主体の権限を複数の場所へ繰り返し登録する必要があった。

一か所でも値が違えば、モデルを呼ぶ前に作業が失敗した。リポジトリの内容とは関係のない実行環境の前提が準備を止めることもあった。実行環境を更新した後に古いインスタンスが残れば、画面上の再起動と、実際に一つだけ動いている状態も異なった。

私たちは手順書をさらに長くする代わりに、承認型の自動準備へ方向を変えた。

グループ管理者が確認済みのリポジトリについて接続を依頼すると、権限を持つ管理者がグループとリポジトリの境界を確かめる。その承認後にだけ、実行環境がリポジトリを準備し、ポリシーを同期する。リポジトリや基準ブランチが変われば、過去の承認をそのまま再利用しない。準備に失敗しても、既存のグループやスペースのデータを巻き戻さず、再試行できる状態として残す。

自動化は増えたが、自動承認の範囲は増やさなかった。接続を自動で準備することと、その接続で作られた変更を自動でマージ・公開することは、別の判断だった。

複数リポジトリの成功は、一回のデモでは確認できなかった

複数リポジトリの接続を確認するとき、代表プロジェクト一つの成功だけで終わらせなかった。異なるリポジトリで、読み取り、隔離された編集、コミットとプッシュ、PR、公開反映の接続が同じ境界で動くかを順に確認した。

重要だったのは、変更内容よりも失敗の隔離だった。

• 一つのグループの接続エラーが、ほかのグループの作業を妨げないか。
• 会話が、承認なしに書き込み可能な作業へ昇格しないか。
• 作業用実行環境とリポジトリ反映用実行環境が、資格情報を共有していないか。
• 基準ブランチへの直接プッシュと強制プッシュが遮断されるか。
• PRのマージと公開反映の前に、人が最終範囲を確認するか。

運用確認の記録にも、トークン、内部アドレス、ローカルパスを残さなかった。どのプロジェクトで、どの段階が成功または失敗したか、どのポリシー版と変更フィンガープリントを確認したかだけで復旧できる状態を目指した。

予約作業もグループごとのプロセスにはしなかった

グループプロジェクトが増えると、「毎週この記事を準備して」「決まった時刻に点検して」といった反復作業が自然に必要になった。最も単純な実装は、グループごとに別のCronとAIプロセスを置くことだった。

その方法は、小さなPoCの資源構造には合わなかった。グループ数に合わせて常駐プロセス、設定、ログ、障害点まで増える。代わりに、一つの共有スケジューラが期限を迎えた少数の作業だけを確保し、順に処理するようにした。

予約も二種類に分けた。

• 単純な通知、予定、天気はAIを呼ばない。
• 実際のコードやコンテンツ作業だけが、構造化された作業依頼を作る。

予約作業の自動承認は、作業依頼の受け入れと最初の編集開始までに限った。コミットとプッシュ、PR、マージ、本番反映、データベース変更、権限変更は、既存の人による承認の扉をそのまま通過した。反復作業であることを、結果まで自動公開する理由にはしなかった。

再試行で同じメッセージと作業が重複しないよう、実行ごとに固有の履歴を持たせた。長時間停止した後に、過去の予約をまとめて一斉実行することも避けた。失敗記録は残し、次の反復は次の時刻へ進めた。

一つの長い作業が、予約の限界を示した

実際の運用では、調査、画像、三言語の記事、検証、公開準備を一つの依頼にまとめた予約作業が実行時間の上限を超えた。スケジューラと自動承認は正常で、その後のAI作業だけが失敗していた。

初めは、制限時間を延ばせば解決するように見えた。一部では制限付きの延長が必要だった。しかし実行時間を延ばし続けることは、一つの作業枠が後続の待ち時間を増やし続ける選択でもあった。

より重要な解決は、作業を成果物単位に分けることだった。調査、執筆、言語別レビュー、画像、ビルド検証を一回ですべて任せるより、中間結果をリポジトリへ残し、次の作業が確認済みの成果物から続けるほうが安定した。

時間切れになった部分成果物を、「ほぼ完成している」という理由で反映しなかった。韓国語原稿と画像が残っていても、三言語レビューと最終検証が完了していなければ、公開可能な結果ではなかった。

グループ主権は、プロジェクト数が増えたときに見えた

この三日間に作ったのは、複数リポジトリ機能一つではなかった。グループ、リポジトリ、AIプロジェクト、作業スペース、反映、公開サイトが、どのような関係を持つべきかという基準だった。

もう一度始めるなら、次の順序を守る。

1. 公開面と非公開の原本を先に分ける

公開サイトは、承認済みの公開ファイルまたは公開用の投影だけを読む。編集権限と訪問者の閲覧権限を同じ実行環境へ置かない。

2. 接続完了を段階別の状態で示す

SCM接続、実行環境の準備、リポジトリ反映、公開反映の接続を、一つの緑色表示にまとめない。失敗した層と次の復旧操作を分けて見せる。

3. 自動準備と自動判断を混同しない

反復する設定は自動化しても、コード変更、リポジトリ反映、マージ、公開には既存の人による承認を残す。

4. グループ数に合わせて常駐資源を増やさない

共有スケジューラ、条件付き同期、検証キャッシュを使う。新しいグループ一つの待機コストを、新しいサーバー一台分にしない。

5. 失敗履歴を成功で上書きしない

部分成果物、失敗した予約、拒否された判断を復旧の根拠として残す。次の作業は新しい履歴として続ける。

一つのプラットフォームに複数の基準線を置く

7月31日が終わったとき、Haru Spaceはもはや自分のリポジトリだけを管理するアプリではなかった。グループが別のプロジェクトと公開サイトを持ち、自分のペットへ制限された作業を任せ、その結果を自分の承認フローで反映できる小さなプラットフォームになり始めていた。

しかし、プラットフォームになることは、すべてを中央で支配することではなかった。

中央は接続契約、最小権限、監査、コスト境界を提供する。各グループは自分のリポジトリ、公開範囲、最終判断を持つ。失敗した接続はそのグループ内で閉じ、成功した自動化も人の代わりに最後の扉を開かない。

一つのリポジトリを越えた日に得たものは、単にプロジェクトが増えたことではない。異なるプロジェクトが互いの境界を侵さずに動く方法だった。