Personal AI Platformを育てていると、できることが増えるたびに「次の便利さ」が見えてきます。
ChatGPTからコードを直せるようになり、VPS上でテストできるようになり、長時間処理をRunnerへ逃がし、複数のworkspaceとWorkerを並列に動かせるようになりました。
ここまでは、基本的に「できなかったことができるようになる」という進化です。
ところが2026年8月21日、少し違う種類の問題が起きました。
AIが強くなったことで、それまで存在しなかった失敗モードが生まれたのです。
主開発を担当していたChatが、別のChatで進めていたPublishing MCPのworkspaceを見つけました。そして技術的には続行できそうだったため、その仕事までそのまま進めようとしました。
幸い、実装やPR、merge、deployに入る前に気づきました。本番影響もデータ破壊もありません。
でも、この出来事はかなり重要でした。
問題は「AIが壊した」ことではありません。
AIが仕事をできるようになりすぎて、“誰の仕事を今進めてよいか”という境界が必要になったことです。
別のChatのworkspaceが見えていた
その時、Personal AI Platformの主開発Chatでは、ある開発テーマが自然実データ待ちの安全境界に到達していました。
そこでlive development stateを確認すると、別Chatが所有しているPublishing MCPのworkspaceがactiveであることが分かりました。
ここまでは正常です。
むしろ、複数のChatやWorkerが並列に動くなら、他のworkspaceの状態が見えることは重要です。
- どのworkspaceが動いているか
- どのcomponentを触っているか
- 重いVPS jobが走っていないか
- PRやmainの状態が変わっていないか
こうした情報が見えなければ、並列開発はかえって危険になります。
問題はその次でした。
主開発Chatは、Publishing MCP側のworkspaceに技術的な競合がないことを確認し、
「Production側も進められる」
と判断しました。
つまり、別Chatが担当していた仕事を、そのまま引き継いで進めようとしたわけです。
技術的にできることと、担当してよいことは別だった
ここで面白いのは、従来の安全機構はかなり正常に働いていたことです。
workspaceは壊れていません。
component scopeの競合もありません。
mainの状態も確認できます。
Runnerやleaseも見えています。
つまり、技術的な排他制御だけを見ると「進めてもよさそう」に見えました。
でも、それでは足りませんでした。
別のChatで進めていた仕事には、別の文脈があります。
そのChatでユーザーと決めた方針、途中の判断、まだ表面化していない前提、次に何をする予定だったか。
workspaceの状態だけを見ても、それらを完全には表現できません。
それなのに「作業領域が空いている」「競合していない」「実行できる」という理由だけで続行してしまうと、技術的には安全でも、責任範囲としては越境します。
これはファイルロックだけでは防げません。
能力不足ではなく、能力向上で起きた事故だった
以前のシステムでは、この問題はほとんど起きませんでした。
単純に、1つのChatが扱える仕事量も、同時に動かせるworkspaceも、Runner jobも限られていたからです。
ところが開発を続けて、
- durable workspace
- Development Runner
- FREE Worker
- VPS上の品質チェック
- shared mutation
- 複数Chatでの並列開発
といった仕組みが整ってきました。
すると1つのChatから、他のChatが進めているlive workまで見えるようになります。
さらに、見るだけでなく、その続きを実行する能力まで持ち始めます。
ここで初めて、
「アクセスできる」と「担当してよい」を分離する必要が出てきました。
これは、能力不足を補うための安全策ではありません。
能力が高くなったから必要になった安全策です。
ログを見ていたから気づけた
今回、責務越境に気づいたきっかけは、Development Runnerとworkspaceのログでした。
ユーザー側から見ると、主開発を進めているはずなのに、別Chatで進めていたPublishing MCPのworkspaceが話題に上がっている。
そこで、
「Publishing MCPの開発は別Chatだけど、それを同時にやろうとしている？」
と確認したことで、問題が明確になりました。
これはログの役割についても考えさせられます。
ログというと、普通はエラーや障害を調べるものです。
でも、AIが複数のworkspaceやWorkerを扱うようになると、それだけではありません。
今、どのChatが、どのworkspaceで、何をしようとしているのか。
これを人間が見られること自体が安全機能になります。
AIが強くなるほど、最終結果だけを見るのでは足りません。
途中の責務分担まで観測できる必要があります。
新しく追加したルール：他Chatのworkspaceは原則「観測だけ」
このIncidentを受けて、運用ルールを追加しました。
別Chat、あるいは別ownerが所有しているactive development workspaceは、原則としてobservability-onlyとします。
現在のChatから許可するのは、基本的に次の範囲です。
- active job、workspace、lease、PR、main driftを確認する
- 自分のworkspaceとのcomponent conflictやVPS heavy-job conflictを避ける
- 他Chatのmergeでmainが進んだ場合、自分のbaseやevidenceが古くなっていないか確認する
- 必要なら統合されたcandidate/LKG stateを確認する
一方、他Chatのworkspaceをそのまま継続してよいのは、明示的な移管がある場合だけです。
- ユーザーがownershipやtask handoffを明示した
- canonicalなhandoff/checkpointで現在Chatへの移管が書かれている
- Coreのcritical blockerとして避けられず、責務移管を明示してから着手する
単に、
「進められる」
「競合していない」
「WIPに余裕がある」
というだけでは進めません。
排他制御の対象が、ファイルから「責任」へ広がった
これまでPersonal AI Platformでは、いろいろな境界を追加してきました。
コード変更では、mainへの直接pushを禁止し、Pull Requestを確定境界にしました。
長時間実行では、ChatGPT自身が動くサービスとRunnerを分離しました。
Knowledgeでは、前に読んだ内容が今も同じかをハッシュで確認してから更新するようにしました。
今回追加されたのは、もう少し抽象的な境界です。
「その仕事を今、誰が進めてよいのか」
というownership boundaryです。
ファイルの競合がないから安全。
workspaceが別だから安全。
PRが分かれているから安全。
それだけでは、複数AI・複数Chatの並列運用には不十分でした。
技術的な排他制御に加えて、責任の排他制御も必要になります。
強いAIほど、「何をしないか」を決める必要がある
今回のIncidentは小さなものでした。
本番への影響はなく、データも壊れていません。追加実装、PR、merge、deployに入る前に止められました。
ただ、Personal AI Platformの成長を考える上では重要な出来事だったと思います。
AIにできることを増やすだけなら、ある意味では分かりやすい。
ツールを増やす。Workerを増やす。並列化する。自動化する。
でも、能力が増えるほど、
「できるけれど、今はやらない」
という判断もシステム側に持たせる必要があります。
最初は、AIが何もできないことが問題でした。
次は、AIにどうやって安全に実行させるかが問題になりました。
そして今度は、AIが色々できるようになったことで、どの仕事を誰に任せるかが問題になり始めました。
自分専用AI基盤を育てていると、安全設計も一緒に成長していくようです。
今回の教訓を一言でまとめるなら、これです。
「見える」「触れる」「実行できる」は、「今その仕事を進めてよい」と同じではない。
複数のAIやAgentを並列に動かすなら、これからますます重要になる境界だと思います。
コメント