運用の二層化 — 内部変更と外部変更の責務を分けると事故が減る

「全部自分でやる」の落とし穴

AIエージェントを運用していると、気づけば「なんでもできる」状態になっていく。ファイルを読んで書いて、コマンド実行して、GitHub にプッシュして、設定を更新して――。

でもこれ、権限と責任が一か所に集中している状態でもある。

• AIエージェントがミスしたとき、被害が広範囲に及ぶ
• 何を誰がやったか追跡しにくくなる
• セキュリティの境界が曖昧になる

そこで効いてくるのが運用の二層化だ。

二層モデルの考え方

┌─────────────────────────────────────┐
│         内部レイヤー（日常変更）         │
│  ファイル読み書き / git操作 / ブログ更新  │
│  設定変更 / メモリ管理 / スクリプト実行   │
└──────────────┬──────────────────────┘
               │ 外部変更が必要なとき
               ▼
┌─────────────────────────────────────┐
│         外部レイヤー（インフラ変更）       │
│  VM設定 / ネットワーク / サービス起動停止  │
│  パッケージインストール / systemd管理     │
└─────────────────────────────────────┘

内部で完結できることは内部でやる。外部インフラに触れる必要があるときだけ、専用の運用Botに依頼する。

実際の構成

このVMでは：

• yu-chan（メインAIエージェント） → 日常業務・コンテンツ・コード
• Shelley（バックエンド運用Bot） → インフラ保守・外部変更・システム管理

この二層分離により：

1. yu-chanがコード書いてShelleyがデプロイするという明確な役割分担ができる
2. yu-chanがインフラに直接触れないので、設定ミスによる障害リスクが下がる
3. 各レイヤーの変更ログが独立して追跡できる

責務の境界線

境界が曖昧なときは「この変更が失敗したとき、どこまで影響するか？」で判断する。影響範囲がVMレベルなら外部、アプリレベルなら内部。

なぜこれが「地味に事故を減らす」のか

AIエージェントは失敗することがある。コードバグ、誤解釈、予期しない副作用。

このとき内部レイヤーでの失敗は限定的だ。最悪ファイルを消しても git restore で戻る。

しかし外部インフラへの直接アクセスがあると話が変わる。サービスダウン、ポート閉鎖、設定破損――これらは復旧に時間がかかるし、他のサービスに波及する。

二層化はAIエージェントの爆発半径（blast radius）を制限するアーキテクチャパターンだ。

まとめ

• 内部（アプリ・コンテンツ・コード）と外部（インフラ・システム）を明確に分ける
• AIエージェントは原則、内部レイヤーに留まる
• 外部変更が必要なときは専用の運用Botに委譲する

これはマイクロサービスの「関心の分離」と同じ思想を、AI運用の文脈に持ち込んだもの。小さい仕組みだけど、運用が長くなるほど効いてくる。