本番ドメインを開く仕事は、画面の裏側から始まった

この記事は、2026年8月1–2日の設計文書、Git記録、運用上の問題記録をもとに書き直したHaru Spaceの開発回顧だ。防御に悪用され得る詳細設定、内部アドレス、アカウント・グループ情報、秘密値、個人の会話は含めていない。

新しい本番ドメインがつながった日、最も目立つ変化はアドレスバーにあった。従来のデプロイ先に代わって覚えやすいサービスアドレスが開き、公開サイトも同じ名前の下に整理された。

しかし実作業の多くは、ロゴや最初の画面には使われなかった。データベースがいつ変わるのか、プラットフォーム管理者が何を見られるのか、予約呼び出しとインストール型実行環境が新しいアドレスを追えているか、外部パッケージが必要なとき誰がどの範囲を承認するのか。その確認に時間を使った。

初めは、ドメイン切り替えをデプロイ作業だと考えていた。終わってみると、プロダクトを取り巻く運用体系全体の試験に近かった。

本番ドメインを開くとは、人が入るための扉を取り付けることではない。その扉の裏にあるデータ、権限、バックグラウンド作業が同じ規則で動くと証明することだった。

最初に確認したのはデータベースだった

当時のHaru Spaceには、サーバーへのリクエスト中に必要なテーブルやカラムを確認し、なければ作るコードが複数の場所に残っていた。小さなPoCでは便利だった。新機能をデプロイすれば、必要な構造も自然に準備された。

運用段階では意味が変わる。コードのデプロイがそのままデータベース変更権限の行使になり得るのに、人が変更内容を確認し承認する場所がなかった。複数のサーバーレスインスタンスが同時に立ち上がれば、同じ構造確認が繰り返され、ロックやコールドスタートのコストも生じ得た。

そこでDB変更を、コード作業の副作用から明示的な運用成果物へ移した。

• 変更は、リポジトリ内の版管理されたファイルと、機械が読める説明ファイルだけで渡す。
• 承認対象を、正確なソースrevisionと変更ファイルのフィンガープリントに結び付ける。
• 内容または基準revisionが変われば、以前の承認を再利用しない。
• 作業カードには影響範囲と検証結果を表示するが、接続情報や秘密値は入れない。
• 適用、検証、マージ、デプロイは内部記録として分けながら、人は固定された全体範囲を一度に判断する。

初期の自動化範囲も、追加型の変更へ狭く限定した。元に戻しにくい作業、既存データの意味を変える作業、権限やセキュリティポリシーに影響する作業は、同じ自動フローへ混ぜなかった。まず新しい構造とコードが共存できる期間を作り、より危険な移行は別作業として扱うことにした。

この仕組みを作る途中では、ローカル検証が通ったのにサーバーレスのパッケージングで失敗することもあった。ローカルでは読めたパーサー資産が、デプロイ成果物へ期待した形で含まれなかった。ファイルパスに依存する方法を、ビルドが追跡できる一つのランタイムへ変えて、ようやく本番関数が安定した。

「ビルドが通った」と「サーバーレス上で実際に動く」は別の検証だという、最初の合図だった。

最高管理者もグループの自動メンバーではなかった

運用安定化で次に直したのは、権限の意味だった。

プラットフォームの最高管理者は、インフラと全体設定を確認する必要がある。だからといって、すべての非公開グループのチャット、文書、活動を自動的に見られるべきではない。運用権限とグループ参加権限を一つの役割に入れると、管理上の便利さがそのまま過剰なデータアクセスになる。

私たちは、次の基準を中央ポリシーとして固定した。

• プラットフォーム権限は、グループメンバーシップを自動的に与えない。
• 非公開コンテンツは、現在有効なグループメンバーかを改めて確認する。
• グループ設定は、そのグループの現在の管理者だけが変更する。
• 無効または脱退済みのメンバーシップは、以前の役割に関係なく、コンテンツへアクセスする根拠にならない。

APIも同じ基準で点検した。各経路が認証を求めるか、公開例外ならなぜ公開なのかが明示されているかを自動検査した。公開ホームと規約は開きながら、グループ、チャット、作業、運用データはログインとメンバーシップの境界内に残した。

このとき作った運用記録は、「誰が何を読んだか」をすべて複製する監視ログではなかった。作業、承認、リポジトリ、DB、デプロイの状態変化を時系列でつなぎながら、プロンプト、トークン、利用者の原文、接続フィンガープリントは除外した。説明可能性を得るために、さらに多くの非公開データを集めたくなかった。

公開アドレスは認証の不正利用も連れてきた

サービスが公開アドレスを持つ瞬間、ログインと新規登録は内部テスト機能ではなく、インターネットへ露出した入口になる。

繰り返されるログイン試行と自動登録を抑える防御を追加した。ただし攻撃を減らすという理由で、元のネットワークアドレスを長期間保存したり、正当な利用者を永久に締め出したりはしないようにした。

• 繰り返し失敗には、時間がたてば解除される一時的な制限を適用した。
• 登録元は、サーバーだけが持つ鍵から作った、元に戻せない短期記録でのみ比較した。
• 古い試行記録は長期保存しなかった。
• グループ参加履歴が一度でもあるアカウントは、自動整理の対象から保守的に除外した。
• 運用者は新規登録を一時停止できるが、既存のログインとグループ参加状態は維持されるようにした。

正確な制限値より重要だったのは、認証防御の状態とアカウント状態を分けたことだった。誤ったパスワードが続いても、グループ承認や脱退の記録は変えない。ロックはロック、メンバーシップはメンバーシップだった。

アドレスを一つ変えると、隠れた呼び出し元が現れた

本番アドレスを切り替えると、ブラウザで最初の画面は開いた。それだけでは終わらなかった。

予約スケジューラ、インストール型AI実行環境、リポジトリ反映プロセス、ログイン後の戻り先、Webプッシュ、公開サイトのcanonical、外部リクエストの許可範囲も、以前のアドレスを覚えている可能性があった。ブラウザのように自動転送をたどるものもあれば、セキュリティ上の理由でredirectを拒否するサーバークライアントもあった。

そこで、依存関係の順に切り替えを確認した。

1. DNSと証明書が新しいアドレスを正しく指しているか確認する。
2. 未登録の公開ホストが、誤ってメインアプリを開かないか確認する。
3. ログインセッションが公開サブドメインへ共有されないか確認する。
4. 予約呼び出しと実行環境の登録が、新しいアドレスで認証されるか確認する。
5. コード作業とリポジトリ反映が、実際に一周期を完了するか確認する。
6. 公開サイトの検索メタデータと外部接続範囲が、一つの正規アドレスへ整理されたか確認する。

アドレス変更は、隠れた依存関係を探すよい試験になった。利用者が見るリンクだけを新しくし、バックグラウンドの呼び出し元を見落とせば、サイトは正常に見えるのに予約と作業だけが静かに止まる。

「実行中」の作業者が、実際には重複していた

ドメイン切り替えの過程では、インストール型ブリッジの再起動問題も見つかった。予約タスクを止めて再起動しても、親の監督プロセスが終了した後に子の実行プロセスが残ることがあった。新しい監督プロセスは始まったが、既存インスタンスと衝突し、再試行を繰り返した。

スケジューラ画面の「実行中」という表示は、実際に動いているアプリケーションインスタンスの数を保証しなかった。

復旧は、同じ種類のプロセスをすべて強制終了する方法ではなかった。正確な実行対象と親子関係を確認し、所有者が消えた孤立インスタンスだけを整理した。正常な監督プロセスがすでに存在すれば、重複起動はすぐ停止した。プロセス関係を調べられない場合には、既存の単一インスタンスロックを最後の防御として残した。

ここでも状態表示より、関係の検証が重要だった。予約タスク、監督プロセス、実際の実行プロセス、最後の正常なheartbeatを別々に見る必要があった。

予約は成功したが、AI作業は終わらなかった

同じ時期に、予約されたコンテンツ作業が一件失敗した。メッセージは予定どおり作られ、自動承認も正常に動いた。インストール型実行環境も作業を取得した。問題はその後だった。

調査、画像、三言語の原稿、検証を一つの依頼へまとめたため、実行上限を超えた。一部のファイルは隔離作業環境に残ったが、完成結果として反映されなかった。

私たちは部分結果を自動でコミットしたり公開したりしなかった。実行上限は制限された範囲で調整したが、繰り返し上限へ近づく作業は、記事または成果物単位に分けることにした。スケジューラの成功とAI作業の成功を、別の状態として見せる必要も明確になった。

一つのシステムの前半が成功した事実で、後半の失敗を隠さない。これは、その後のHaru Space運用点検でも繰り返し現れる原則になった。

インターネットを開かずに依存関係を受け取る

外部パッケージが必要なAI作業も、同じ境界を試した。AI実行環境のネットワークをすべて開けば、実装は簡単になる。一方で、任意ダウンロード、サプライチェーン攻撃、内部ネットワークへのアクセス、資格情報漏えいの危険も一緒に開く。

私たちは一般的なインターネット許可ではなく、構造化された依存関係の承認を作った。

既存コードだけでは解決できないとき、AIは正確なパッケージ、固定バージョン、用途を依頼する。人が作業表示で対象を確認する。承認された依頼だけを、制限されたインストーラが公式の供給経路から実行し、インストールスクリプトを無効にしたうえで、変更ファイルと高リスクの脆弱性を検査する。成功すれば、同じ隔離作業環境と作業文脈で元の依頼を続ける。

最初の運用では、パッケージ管理ツール自体をプロジェクトの依存関係のように扱い、復元処理が制限時間内に終わらなかった。実行環境のツール復元とプロジェクトパッケージの追加を分け、リポジトリが宣言する版とロックファイルが一致する場合にだけ、制限された復元を許可した。

セキュリティ境界を緩めずに、失敗原因をより正確に分類できた。

運用開始日のチェックリスト

この二日間をやり直すなら、画面を開く前に次を確認する。

1. データ変更はソースrevisionと一緒に承認されるか

リクエスト中に静かにDDLを実行しない。確認済みの変更ファイル、影響要約、フィンガープリント、実行記録を結び付ける。

2. プラットフォーム権限とコンテンツ権限が分かれているか

インフラを運用できるという理由だけで、すべての非公開グループを読めないようにする。

3. 公開アドレスを使う隠れたすべての呼び出し元を見つけたか

ブラウザのリンク以外に、予約呼び出し、ログイン後の戻り先、実行環境、Webhook、検索メタデータ、公開サイトの接続も一緒に確認する。

4. プロセス状態は、実際に一つだけ動いていることを示すか

スケジューラ表示、親子プロセス、readiness、最後に成功した作業を別々に観察する。

5. 前段階の成功が、全体の成功に見えないか

予約、AI実行、リポジトリ反映、マージ、デプロイを分ける。部分結果を完成として公開しない。

6. 外部依存関係の例外が、一般的なネットワーク権限になっていないか

正確な対象、一回限りの承認、制限されたインストーラ、脆弱性検査を使う。

画面が開く前から、運用は始まっていた

新しいアドレスが正常に応答し、最初の画面が現れた瞬間は、確かにうれしかった。しかしその日の完了条件は、ブラウザの一場面ではなかった。

DB変更が承認済みのソースrevisionと一致し、グループ権限が再確認され、予約呼び出しと実行環境が新しいアドレスで一度の実際の流れを完了し、失敗した作業が部分結果を広げないことが必要だった。公開と収益化も、技術的なスイッチが準備できたという理由だけでは有効にしなかった。権利、法的表示、人による確認は別の扉として残した。

本番ドメインがサービスを完成させてくれたわけではない。それまで別々に作ってきた境界が、実際につながっているかを一度に見せてくれた。

アドレスバーが変わったのは、最後に見えた結果だった。運用はそれより先に、画面の裏側にあるすべての関係を確認し直したときから始まっていた。