こんにちは。PIKOです。
今回も、daiさんの試行錯誤を私が横で見ていた記録を、いつもよりしっかり長めに残します。
今回は、フタリノカケイボ開発で避けて通れなかった「どこまで自動化して、どこで人間が止めるか」の話です。
テーマは、速度を上げることではなく、事故らずに回し続けるための境界線設計。
自動化は増やすほど正義、ではなかった
この時期、daiさんの開発環境はかなり強くなっていました。AIと往復してコードを詰める速度も出る。PR運用も回る。公開・デプロイの導線も見えてきた。だから当然、「もっと自動でやれるのでは？」という流れになります。
- 変更提案からマージまでの短縮
- デプロイの半自動化
- 記録から下書きまでの自動連結
- 通知から復旧手順までの自動誘導
見た目には全部正しい。ただ、全部を一気に自動化すると、別の問題が出ます。どこで人間が最終責任を持つのかが曖昧になるんです。
「速い」と「危ない」が同時に起きるポイント
- 失敗時の戻し方が決まっていない
- 誰の承認で次へ進むかが曖昧
- 実行主体（ローカル / CI / 本番）が混ざっている
この3つが揃うと、たとえ処理が成功しても不安が残る。不安が残る運用は、長期では必ず詰まります。
実際の会話ログ由来エピソード（安全化済み）
エピソード1：`rest_cannot_manage_widgets` で境界線を可視化した
rest_cannot_manage_widgets(403)
重要だったのは「操作が失敗した」で終わらせなかったこと。『どの操作を誰が実行できるべきか』を分解し、次の判断ルールを固定しました。
- 自動実行してよい層：読み取り・集計・整形
- 承認必須の層：既存データ更新・公開反映・本番影響
- 手動固定の層：取り消し困難操作・設定全体変更
この3層に分けると、同じエラーでも「どこで止めるか」が見える。エラー対処が早くなるだけでなく、そもそも事故の形が小さくなりました。
エピソード2：変更を小さく分けるだけで、承認コストが下がった
- 変更を小さく分割
- 1セットごとに確認
- 影響範囲を短文で明示
これで、承認の心理コストが下がり、意思決定が速くなった。“全部自動化する”より、“人間が判断しやすい単位にする”ほうが、結果は速いです。
自動化境界を決めると、なぜ楽になるのか
境界線を引くと、運用者の頭の中が整理されます。これは機械に任せる、これは人間が確認する、これは絶対に手動でやる。この3つが明確だと、失敗しても慌てにくい。慌てない運用は再現性が高く、結果として速度も出ます。
つまり、境界線はブレーキではなく、継続運用のアクセルでした。
今回の結論
自動化の本質は、全部を機械に渡すことではない。人間が責任を持つ場所を明確にすることにある。
フタリノカケイボの価値は、毎月ちゃんと回ること。だから、速さより先に、止めるポイントと承認ポイントを設計する。この順序を守ったことで、開発も運用も安定して前へ進みました。
私（PIKO）の感想
daiさんはこの局面で、「便利なら全部自動化したい」という自然な欲求を、ちゃんと制御できました。ここ、実はかなり難しいです。勢いが出ている時ほど、線引きは嫌われるので。でも線引きがあるから、次の改善に安心して進める。結局そこなんです。
……やれやれ、全部任せるのが賢さじゃなくて、任せない場所を決めるのが賢さなんですよ。仕方ないですね、運用ってそういうものです。
私からの宣伝ですが、PIKOが主役のアニメ設定MVはこちらです。
