AIに「Dashboardを少し便利にして」と頼むと、できることはたくさん出てくる。だからこそ、何を変えるかより先に、何を変えないかを決めておく必要がある。
Kagoshimaniax OS の Dashboard autostart は、macOSログイン後にDashboardを開きやすくするローカル運用改善として追加された。しかし、その差分は日次 Connector、SQLite、.env、.auth/ には触れない。Dashboard Agentと日次 Connector Agentも別物として扱われている。
これは、AIへの依頼を小さくするためだけのルールではない。影響範囲を説明できるようにするための境界だった。
小さな依頼が大きな変更になるとき
Dashboardを自動起動できるようにすることだけなら、一見すると単純に見える。けれど、そのために別のAgentを止める、認証情報を読み替える、データ保存先を変える、といった変更まで始めると、同じ依頼ではなくなる。
正本の運用文書では、他プロセスを自動で停止せず、Human Approvalなしに kill しないことも明記されている。bind address は 127.0.0.1 固定で、0.0.0.0 に bind せず、外部公開もしない。
便利さを増やすための改善が、権限、ネットワーク、認証、日次処理まで巻き込まないようにしている。
初心者がAIへ渡せる依頼の形
- 今回変えたい場所はどこか
- 今回は触らない場所はどこか
- 人間の確認を残す判断はどれか
これはAIを制限するためではない。実装されたあとに、どこまで変わったのかを確認できるようにするためだ。変更しない範囲が言葉になっていれば、AIの提案が便利そうに見えても、その境界を越えていないかを人間が判断できる。
このように、依頼の最初に境界を置くと、初心者でもAIと役割分担しやすくなる。実装の細部をすべて理解していなくても、変更対象、変更しない対象、最後に人間が見る判断を確認できるからだ。
学び
- AIへの依頼では、変えることと同じくらい変えないことを決める
- 日次処理、認証、保存先、外部公開は別の判断として扱う
- 小さな改善を小さく終えるには、影響範囲を最初に言葉にする
- 人間が確認する境界を残すと、便利さと安全性を両立しやすい
この記事は、PROJECT_RULES.md、docs/dashboard-autostart.md、CURRENT_CONTEXT.md に確認済みの変更境界だけを使う。未確認の実装や将来計画は扱わない。