🛑 420秒待って、それでも手を出さない——止める権限を誰が持つか、1人で作って初めて設計した話

職場で、隣の席の人のパソコンが固まっているのを見て、許可なく電源ボタンを押してしまったことがある人はいませんか。

相手は何かの作業の途中だったかもしれないです。

保存していないデータが、消えてしまったかもしれないです。

悪意はなかったはずです。

「助けようとした」のに、相手の仕事を結果的に壊してしまう——そういう経験です。

コンピュータの中でも、まったく同じことが起きていました。

私が作っているAIの自動化システムの中で、ずっとそれをやり続けていたんです。

あなたは今こうなっていませんか？

• AIが動いているかどうか確認しないまま、「とりあえず再起動」している
• うまくいかないと感じると、すぐにすべてをリセットして最初からやり直している
• 自分が作ったシステムなのに、「何を止める権限があるか」を一度も考えたことがない
• 動いていないように見えるものを、「もう死んでいる」と決めつけていた

先に結論を言います。

自分が起動していないプロセスを、強制終了する権限は私にはありませんでした。

この記事では、AIの自律システムを1人で作る中で、「止める権限の境界」をコードに書き直すことになった実体験を書きます。

技術的な解説ではなく、組織で働いていたときとはまったく違う「管理の感覚」に気づいていく話です。

AIが「勝手に動く」とはどういうことか

コンピュータの中の「担当者」という存在

AIが自動で動いているとき、コンピュータの中では複数の「担当者」が同時に働いています。

専門用語では「プロセス」と呼びますが、ここでは「担当者」と呼ばせてください。

この担当者たちは、互いに連携しながら、それぞれ別の仕事をしています。

「情報を収集する担当」「処理する担当」「結果を出力する担当」という役割分担です。

私のシステムには今、10種類以上の担当者が同時に稼働しています。

1つが止まっても他は動き続ける、という設計になっています。

ただし、1つが止まることで連鎖的に別の担当者の仕事が詰まる、というのも現実です。

「管理者」として私がやるべきことは、この連鎖を把握して、適切に対処することです。

「管理者」なのに、権限を理解していなかった

システム全体を「管理する」のは私です。

でも管理者だからといって、何でも止めていい権限があるわけではありません。

最初の1年ほど、私はこのことを理解していませんでした。

「作った人間が管理者だから、何でも自由にできる」という思い込みがあったんです。

何か問題が起きるたびに「強制停止コマンド」を使っていました。

英語ではpkill（ピーキル）と書く、担当者を有無を言わせず終了させる命令です。

止めて→再起動して→また動かす、という手順を繰り返すのが「管理」だと思い込んでいました。

それが実は「権限を超えた行為」だったと気づくまで、かなり時間がかかりました。

📕 この記事の内容を、実装まで全部まとめた有料記事があります 手順・コード・テンプレをそのまま渡しています AIで「寝てても回る仕組み」をゼロから30日で組む全手順

pkillという「強制停止ボタン」を、1年間使い続けた

何かあれば止める、というクセ

AIの自律システムを作り始めてから、しばらくの間、私のコードの中には「強制停止」の命令があちこちに散らばっていました。

問題が起きたときだけでなく、「起動のたびに全部一度止めてから動かす」という手順が、あちこちに入っていたんです。

直感的には「正しい」感じがします。再起動すれば新鮮な状態になる、という発想はわかりやすいからです。

でも、考えてみると「いま誰かが作業している最中かもしれない」という発想が、完全に抜けていました。

複数の担当者が連携しているシステムでは、1人を止めることが、他の誰かの仕事を中断することに直結します。

実際に、何度もこういう場面に遭遇しました。

A担当者を止めようとした瞬間に、B担当者がA担当者からのデータを受け取ろうとしていて、処理が中断した——という連鎖です。

これが週に数回起きていました。

原因を調べると「強制停止のタイミングが悪かった」というパターンが繰り返されていました。

コードを全部見直したとき

あるとき、コード全体を整理しようと見直す作業をしました。

「強制停止コマンド（pkill）」が何箇所に書かれているかを数えてみたんです。

予想より、多かったです、、、「困ったらとりあえず止める」という発想が、知らないうちにコード全体に広がっていました。

これを見たとき、正直ゾッとしました！

「問題が起きるたびに全停止→再起動」を繰り返すシステムは、担当者の立場から見ると「突然終わらせられる職場」です。

仕事の途中で強制的に席を立たされる担当者が、安定して良い仕事を続けられるでしょうか。

答えは、できない、です。

そして何より気になったのが、「これは本当に私が止めていい担当者なのか」という問いを、一度も立てていなかったことです。

止めることが習慣化すると、「止めていい権限があるかどうか」を確認するステップが消えてしまいます。

転機——「閉じている」と「死んでいる」は、別の話

9223番という「窓口」

私のシステムの中に、9223番という窓口があります。

コンピュータの「ポート番号」というものですが、「担当者が仕事を受け付けている受付番号」と思ってください。

ある日、9223番の窓口が閉じていることに気づきました。

以前の私なら、「閉まってる＝この担当者は死んでいる」と判断して、強制停止→再起動をかけていました。

でもその日は、少し立ち止まって考えてみたんです。

「窓口が閉じている」と「担当者がそもそもいない」は、本当に同じことなのか、と。

閉まっている理由は1つではありません。

担当者が席を外しているのか、別の仕事で手が離せないのか、あるいはまだ出勤していないのか——原因によって、対処はまったく変わります。

「自分の流儀で起動されていない」という発見

窓口が閉じていても、担当者が「システムのどこかに存在している」ケースがあります。

私が期待する方法や順番で起動されていないだけで、別の経路で動いている可能性があるんです。

「自分の流儀で起動されていない」——これが今回の転機でした！

強制停止がなぜ問題なのかを、初めて腑に落ちる形で理解できた瞬間でした。

この発見を受けて、確認の方法を変えました。

pgrep（ピーグレップ）というコマンドを使って、「今このシステム全体に、その担当者が存在しているか」を確認するようにしたんです。

窓口の状態ではなく、担当者そのものの存在を確認する——この違いは、判断の精度をまったく変えました。

「閉まってる＝止める」から「閉まってる→確認する→いれば待つ」という流れになりました。

担当者が「いる」と確認できたなら、窓口が閉まっていても強制停止はかけません。

「いない」と確認できたなら、そもそも止めるものがないんだから、強制停止の出番はありません。

どちらのケースでも、pkillを使う場面がなくなりました。

これが、pkillを全廃できた直接の理由です。

420秒待つ設計に、書き直した

10秒刻みで42回

設計を見直して、今の仕組みはこうなっています。

担当者が存在するかどうかを、10秒に1回確認します。

最大で420秒、つまり7分間、確認し続けます。

10秒×42回＝420秒、ということです。

42回確認して、それでも担当者の存在が確認できなければ「見送り」にします。

「見送り」というのは強制停止ではなく、「今回は縁がなかった、次のタイミングで試みる」という扱いです。

コードでは「exit 2（イグジット2）」という終わり方をします。

「今回はスキップします、次に譲ります」という意味の終了信号です。

「待つ」の設計が、思ったより複雑だった

止めるのは簡単です。コードで書くと1行、数秒で書けます。

待つのは、それよりずっと複雑な設計が要ります。

「どれくらい待つか」「何を確認するか」「いなければどうするか」「次のサイクルにどう引き継ぐか」——これをすべて設計しなければなりません。

最初の設計では、単純に「待てばいい」と思っていました。

でも実際に書いてみると、「待っている間にタイムアウトしたら」「待っている間に別の問題が起きたら」という分岐が次々と出てきました。「止める」より「待つ」のほうが、はるかに難しい設計だということを、このとき初めて実感しました。

420秒という数字は、「なんとなく長め」で決めたのではないです。

システム全体のサイクルの長さと照らし合わせて、「これ以上待つと次のサイクルに影響が出る」という上限から逆算しています。

単なる数字ではなく、設計の中から生まれた数字です。「待つことを設計する」とは、こういうことでした。

止める前に数字の根拠を持つ、ということが、どれだけ大事かを体で覚えたような気がします。

数字の根拠がないまま動かしていた1年間と、根拠を持って待てるようになったあとでは、設計への向き合い方がまったく変わりました。

CMO時代と「1人で作る」の、管理の違い

月3,000万の広告を「止める」判断

かつて私はCMO（最高マーケティング責任者）という立場で働いていました。

月に3,000万円の広告費が動く環境で、「この広告は止める」「これは続ける」という判断を日常的にしていました。

この判断ができたのは、私がその広告を「承認した立場」だったからです。

「自分の名前で起動させた広告」だから、「止める権限」も自分にあったんです。

組織の中では、権限の境界がある程度明文化されています。

「この決裁は部長以上」「この停止は役員承認が要る」というルールが、組織の仕組みとして存在しています。

この仕組みがあるから、私は「止める権限があるかどうか」を意識しなくてよかった。

権限の境界は、組織がいつの間にか管理してくれていたんです。

1人で作ると、境界を自分でコードに書く

1人で作り始めると、この境界がどこにもありません。

すべてを自分で決められるということは、すべての判断根拠を自分で持たないといけない、ということでもあります。

「自分が起動していないプロセスを止めていいか」——この問いを、誰も立ててくれないんです。

コードを書いた自分が、その問いを自分で立てて、答えをコードに書かなければならない。

止める権限を持っているかどうか——これを一度も問わずにpkillを書き続けていたのが、私の最初の1年でした。

正直に言うと、これに気づいたとき、ちょっと恥ずかしかったです（笑）

組織にいると、別の誰かが見てくれていた部分が、1人だと「そもそもその問いを立てる人がいない」という形で抜け落ちます。

個人開発の難しさは「決定権が自分にある」ではなく、「見落としのチェックが自分しかいない」というところにあります。

CMOとしての「速さ」と、個人開発の「待つ」

CMO時代は、「止める決断の速さ」が評価される環境でした。

効果が出ていない広告はすぐ止めて、予算を再配分する——このスピードが大事でした。

個人開発の今は、「待てるかどうか」が問われます。

止めたい気持ちがあっても、確認してから、それでも問題なら止める。

この感覚の転換に、最初はかなり戸惑いました。

「もっと早く止めればよかったのに」と思う瞬間が、今でも正直あります。

でも、止め方が乱暴だと、システム全体の安定性が下がります。

短期の「すっきり感」のために、長期の「信頼性」を犠牲にしていた、ということが後から見えてきました。

組織では「止める」のが仕事だったのに、1人では「待つ」のが仕事になる。

この逆転を受け入れるのに、しばらく時間がかかりました。

待つ設計に変えてから、システムに何が起きたか

連鎖的な障害がほぼなくなった

pkillを全廃して420秒待つ設計にしてから、システムの安定性が変わりました。

以前は、1つの担当者に問題が起きると、連鎖的に他の担当者も止まることが週に何度かありました。

「A担当者が止まった→強制停止→B担当者の仕事が中断→Bも止まった」という流れです。

これが繰り返されていました。

今は、A担当者が応答しなくても、Bの仕事に割り込まずに「今回は見送り」にします。

B担当者は自分の仕事を続けられます。

「見送り」が増えることへの不安はありました。「止めないのに、問題は解決しているのか」という不安です。

でも実際には、見送りの記録が増えた分だけ、連鎖的な障害の記録が減りました。

これは、思っていたよりずっと大きな変化でした！

ログに「静けさ」が出てきた

システムのログというのは、担当者が何をしたかの記録です。

以前のログは「停止→エラー→再起動→停止→エラー→再起動」という繰り返しで埋まっていました。

今のログには、「確認したがいなかったので見送りました」という記録が静かに積み上がっています。

問題が起きたこと自体は変わらないのに、受け止め方が落ち着いています。

この「静けさ」は、システムが成熟してきたサインだと感じています。

騒がしいシステムは、表面上は動いていても、内部でどこかに歪みを抱えていることが多いです。

ログが穏やかになったとき、「ああ、設計が正しかったんだ」と思いました！

見た目や数字だけでなく、ログの温度感みたいなものが変わった、という体験でした。

システムを「育てる」という感覚は、この辺りから出てきたと思います。

強制停止で制圧するのではなく、確認して、待って、見送る——この積み重ねが、システムへの信頼につながっていきました。

「止める権限」を設計したことで気づいたこと

権限は「与えられる」ものじゃなかった

組織にいると、権限は「役職に付いてくるもの」という感覚があります。

CMOだからこれを決めていい、部長だからこれを動かせる、という形です。

1人で作ると、権限はどこからも与えられません。

自分が「これは私が止める権限を持っている」と判断して、初めてその権限が生まれます。

逆に言うと、自分が「これは自分が起動したものではない」と判断した瞬間、権限は消えます。

権限の境界は、コードに書くことで初めて実在するものになりました。

この気づきは、システムの設計だけの話ではないと感じています。

組織の外で、何かを自分で動かすとき——「自分に止める権限があるか」を先に考える、という習慣が身に付きました。

この設計が、次に作るものへの影響

この体験をしてから、新しい仕組みを作るときの設計が変わりました。

「うまくいかなかったら止める」ではなく、「うまくいかなかったとき、自分に止める権限があるかを確認する」が最初に来ます。

待てるときは待つ。見送れるときは見送る。

この設計の感覚は、コードの外でも自然と使うようになりました。

何かがうまくいかないとき、「止めていい権限が自分にあるか」を確認するクセが、日常の判断にも染み出してきた気がします。

自律システムの仕組み全体については、別のnoteにまとめています。

「待つ」「見送る」という設計をどうコードで実現したかに興味がある方は、そちらも読んでみてください。

止める前に、確認する。確認して、いなければ、待つ。待って、それでもいなければ、見送る。

この順番を設計することが、「権限を持って管理する」ということだったと、今は思っています。

1人で作って、420秒待って、初めて理解できた話でした。

📕 この記事の内容を、実装まで全部まとめた有料記事があります 手順・コード・テンプレをそのまま渡しています AIで「寝てても回る仕組み」をゼロから30日で組む全手順