ローカルDashboardを127.0.0.1に固定した理由

1. リード

Dashboard をログイン後に自動起動できるようにすると、次に気になるのは「どこから開けるようにするか」だった。

確認済みの Dashboard autostart 運用文書では、bind address を 127.0.0.1 に固定し、0.0.0.0 には bind しないこと、インターネット公開をしないことが明記されている。これは実装上の細部ではなく、ローカル運用改善の範囲を決める条件だった。

今回は、ローカルで開きやすくする改善が、なぜ外へ開く改善にならなかったのかを、確認済みの運用条件だけで整理したい。

2. 便利にする場所を決める

Dashboard autostart の目的は、macOS にログインしたあとに Dashboard を起動しておき、ブックマークから http://localhost:8501 を開けるようにすることだ。毎回コマンドを入力しなくてよい状態を作る。ただし、外部から見られる画面を作ることでも、共有用のサービスを追加することでもない。

この目的が先に固定されているから、bind address も 127.0.0.1 になっている。自分のMacの中で使いやすくするための仕組みを、ネットワークの外側へ広げる必要はない。0.0.0.0 に bind しないという一行は、利便性のための改善を、公開範囲の変更に変えないための線だった。

3. Dashboardだけを変える

Dashboard autostart の文書では、Dashboard Agent と日次 Connector Agent も別物として扱われている。日次 Connector、SQLite、.env、.auth/ には触れない。他プロセスを自動で停止せず、Human Approval なしに kill もしない。

ここで大切なのは、同じMacで動くものを一つの自動化にまとめなかったことだと思う。日次 Connector には、DarkWake を避けること、通常 Wake 後に実行すること、通信障害を有限回だけ再試行すること、OAuth refresh を扱うことなど、別の運用条件がある。Dashboardを開きやすくする差分が、それらの条件まで動かし始めると、便利にするための変更が日次データ取得の信頼性を巻き込んでしまう。

だから、Dashboardの起動を楽にしても、Connectorの実行条件や保存先、認証情報まで変えない。改善の対象を狭く保つことが、既存の運用を壊さないための条件になっている。

4. ローカルという判断

非エンジニアの自分にとって、自動起動と外部公開は一見すると近い話に見える。どちらも「開きやすくする」からだ。

しかし正本を読むと、二つはまったく別の判断だった。自動起動は、ログイン後に自分が見るDashboardを準備しておく話である。外部公開は、誰がどこからアクセスできるかを変える話になる。後者には、公開範囲、認証、ネットワーク、運用責任の判断が加わる。

127.0.0.1 固定は、その二つを混ぜないための選択だと感じた。便利さを足すときに、どこまでを便利にするかを決める。そこから先は、別の判断として残す。Kagoshimaniax OS の release後のローカル運用改善は、この順番を守っていた。

5. 学び

• ローカルで開きやすくすることと、外部公開できるようにすることは別の改善である
• 127.0.0.1 固定は、Dashboardを自分のMacの中で使う範囲に保つ判断になる
• Dashboard Agentと日次 Connector Agentを分けると、便利さの変更が日次運用を巻き込みにくい
• 自動化であっても、他プロセスの停止や認証情報への変更はHuman Approvalの外へ出さない
• 改善の対象を狭く決めることが、既存の運用を守る

この記事は、docs/dashboard-autostart.md と CURRENT_CONTEXT.md に確認済みのローカル運用改善の事実だけを使う。外部公開、次Version、新しい認証方式は扱わない。