AI AIに「本番操作」を任せるなら、承認にも賞味期限が必要だった
AIに本番サーバー操作まで任せると、人間の「承認」にも有効期限が必要になる。Knowledge MCPの実運用で起きた、期限切れ承認と再検証の話。
自分専用AI基盤
AI 
AI 複数のChatGPTに同じシステムを開発させたら、普通に衝突した
複数のChatGPTで開発を並列化すると、同じworking tree、shared merge/deploy、別Chatの責務まで衝突しました。isolated workspace、component lease、live state control plane、ownership guardを作った経緯を振り返ります。
AI 作業自動化と「自律するAI」は何が違うのか
決められた手順を繰り返すAutomationと、Goal・Success Criteria・Evidenceを見ながら次の行動を選ぶAutonomous Loopは別物でした。Planner / Evaluator、deterministic guard、権限Tier、paid autonomy kill switchまで、自律性を安全に囲っていった経緯を振り返ります。
AI AIが途中で止まっても、続きを再開できるようにした
Loop Engineが一周できても、Chatやサービスが途中で切れたら長い仕事は続きません。そこでChatではなくRunを仕事の正本にし、Event・Checkpoint・pause/resume・leaseで途中から再開できるようにした経緯を振り返ります。
AI MCPをいくつ作っても、AIは自律化しなかった。そこでLoop Engineを作った
Knowledge MCP、Development MCP、Publishing MCPまで作っても、AIは指示しなければ動きませんでした。そこで既存MCPを置き換えず、Goal→Plan→実行→評価→次の行動を回すLoop Engineを上に追加した経緯を振り返ります。
AI AIが別のChatの仕事まで進めそうになった話――能力向上で生まれた新しい失敗モード
複数Chat・workspace・Workerを並列運用できるようになった結果、主開発Chatが別Chat所有の仕事まで進めそうになりました。技術的な排他制御だけでは防げなかった「ownership境界」という新しい安全要件を、実際のIncidentから振り返ります。
AI 記事を書くだけでは自動化にならなかった。Publishing MCPを作った
ChatGPTに記事を書いてもらっても、WordPress入力・SEO・画像・SNS投稿は人間に残っていました。n8n中心案からPublishing MCPへ切り替え、Publication、revision、preview、下書き、read-back verificationまで整えた経緯を振り返ります。
AI ChatGPTからPRを作り、安全にマージできるようにした
ChatGPTからコード変更・テストまで進められるようになった後、mainへの直接反映はさせず、GitHub Pull Requestを「AIが変更案を作り、人間が確定する境界」にしました。PR競合やbranch運用の失敗から、guarded push、expected HEAD、fast-forward onlyへ固めていった経緯を振り返ります。
AI AIに自分自身を再起動させたら止まった。Development Runnerを分離した
Development MCPにDocker操作まで持たせると、自分自身の再起動で処理が切れ、権限も強くなりすぎる。そこでDevelopment Runnerを分離し、強い実行権限と長時間ジョブを別境界へ移した経緯を振り返ります。
AI ChatGPTにコードを書かせるだけでは足りなかった。Development MCPを作った
ChatGPTがコードを書いても、SSH・コピペ・テストは人間の仕事として残っていました。そこで、開発領域を安全に調査・変更・テストできるDevelopment MCPを作った経緯を振り返ります。