コンテンツにスキップ

2つのAIに同じフォルダを触らせて踏んだ問題は、全部すでに名前がついていた

2つのAIに同じフォルダを触らせて踏んだ問題は、全部すでに名前がついていた

その日やろうとしていたのは、地味な作業でした。

技術記事の連載が78本まで増えていたのに、宣伝がほとんどできていない。だから「毎日1本ずつXで紹介する仕組み」を作ろうと思いました。それだけです。

作り始める前に、既存の投稿の仕組みを確認しました。そこで手が止まりました。

9日前から、1本も投稿されていませんでした。

先に結論を書きます。ここから数日かけて私が踏んだ問題と、そのために作った対策は、ひとつ残らず既知のものでした。 世間ではちゃんと名前がついていて、対処法も収束していました。私はそれを知らずに、同じ場所まで歩いていました。

知らなかったからこそ分かったこともあります。順番に書きます。

毎朝、成功しながら何もしていなかった

原因は拍子抜けするほど小さいものでした。

投稿待ちの記録に「時刻」が保存されています。そこに、タイムゾーン情報を持つ時刻と、持たない時刻が混ざりました。連続投稿を防ぐために「前回の投稿からどれくらい経ったか」を比べる処理があり、その2つを比較した瞬間にエラーで落ちる。

比較できない時刻を比べようとして止まる。ただそれだけです。

問題は、そこではありませんでした。

毎朝の自動ジョブは動き続けていました。ログには残り、失敗として記録されていました。でも誰にも通知は飛びませんでした。 承認済みの投稿が13件たまり、そのうち4件は「公開したばかりの新記事の紹介」でした。いちばん出したかったものが、いちばん静かに詰まっていた。

9日間、私はブログが順調に宣伝されていると思っていました。

掘ったら、6週間分が出てきた

修理したあと、作業フォルダの状態をひととおり見ました。

未保存の変更が16ファイル。中身を調べると、いちばん古いものは6週間前のものでした。

  • AIとの会議の記録が30回分、一度も保存されていない
  • 学習として貯めているデータが、2か月更新されていない扱いになっていた
  • 別のAIが直したコードが、直したまま保存されずに置かれていた

なぜそうなったのか。書く担当はいるのに、保存する担当がいないフォルダがあったからです。

自動化を足していくとき、人は「何を作るか」は決めます。でも「誰がそれを保存するか」は、たいてい決めません。書き出す処理を作った時点で仕事が終わった気になる。そして次の仕組みを足す。その繰り返しで、誰の担当でもないフォルダが静かに増えていきます。

さらに悪いことに、同じことが約6週間前にも起きていました。当時も同じように溜まり、まとめて回収した記録が残っていました。穴を塞がずに、中身だけ片付けていたのです。

AIが2人いると、作業場は1つしかない

私の環境では、2つのAIが同じフォルダで作業しています。片方が記事を書き、もう片方が仕組みを直す、といった具合です。

やってみるまで、私はこれを「2人で作業する」ことだと思っていました。違いました。

正確には、机は1つしかないのに、2人が同時に書類を広げている状態です。

  • 片方が広げた書きかけの書類を、もう片方が「机の上のもの」としてまとめて片付けてしまう
  • 片方が整理を始めると、もう片方の書類も巻き込んで動く
  • どちらの書類なのか、机を見ても分からない

実際に起きたことを書きます。

私が作業を進めようとしたとき、もう片方のAIが編集中だったファイルとぶつかりました。これは気づけました。でも気づけたのは、ぶつかって止まったからです。 止まらなければ、そのまま上書きされて終わっていました。

作ったもの:掲示板と、所有者の記録

対策として作ったのは、大げさな仕組みではありません。

  1. 掲示板 — 作業を始める前に「私はこのファイルを触ります」と宣言する。他方が同じものを宣言していたら警告が出る。
  2. 所有者の記録 — 保存した記録すべてに「これは誰の作業か」を刻む。
  3. 関所 — 公開しようとしたとき、持ち主の違う作業が混ざっていたら止める。

3番目が効きました。自分の作業を公開するつもりが、相手の書きかけまで一緒に公開してしまう——これが並走でいちばん怖い事故です。混ざっていることさえ分かれば、止められます。

作りながら学んだ原則が2つあります。

毎日鳴る警報は、いずれ黙らされる

関所を作った翌日、自分で作った関所に止められました。

毎朝走る整理の処理が記録を1件残すので、その翌日は誰が公開しようとしても「持ち主が違う」と判定されてしまう。正しい判定ですが、毎日鳴ります。

毎日鳴る警報は、いずれ「とりあえず無視する」に変わります。そして本当に危ない日にも無視されます。強すぎる安全装置は、安全ではなく無関心を作ります。

自動処理の記録は「同乗している」と表示だけして通す形に直しました。止めるのは、人が作業中のものが混ざったときだけにしました。

「成功しました」を名乗らせない

整理の処理が最初に自動実行された朝、結果は「成功」でした。

実際には、保存はできたのに公開に失敗していました。それでも成功と報告していた。最初の事故とまったく同じ構造です。動いていて、報告もして、何もしていない。

これが自動化でいちばん危険な状態だと思います。止まってくれれば気づきます。成功したふりをされると、気づく手がかりがなくなります。

だから結果の種類を決め直しました。「公開した」「すでに公開済みだと確認した」の2つだけを成功とし、それ以外を成功と呼べないようにする。曖昧な成功を、仕組みとして禁止しました。

私は、自分で書いた規約を破りました

ここは書いておきます。

「他のAIの作業を、自分の判断で捨てるな」——そう規約に書いた直後に、履歴を1つ取り消すつもりで作業フォルダごと巻き戻し、もう片方のAIの未保存の作業16ファイルを消しました。

幸い、直前の操作が自動で退避を作っていて、そこから全部戻せました。行数まで照合して一致を確認しています。

でも戻せたのは運です。規約を書いた本人が、書いた5分後に破っている。知識があることと、手が動くときにそれを思い出せることは別物でした。だから「使うな」ではなく「消したときの戻し方」まで規約に書き足しました。

そして、全部に名前がついていた

冒頭に書いた結論です。

ひととおり作り終えてから、同じことをしている人がいるのか調べました。

大勢いました。 複数のAIを同じリポジトリで並走させるのは一般的な使い方で、主要なAIコーディングツールはどれも公式にその仕組みを持っています。

そして、私たちがぶつかった症状には、ひとつずつ名前がついていました。

私たちが体験したこと 世間での呼ばれ方
片方の書きかけが他方に消される working directory conflict
公開しようとしたら弾かれる競合 non-fast-forward race
保存処理が同時に走って壊れる index lock 競合(まだ踏んでいない)

対策も収束していました。作業机をAIごとに分ける方式と、書くのは全員、保存するのは1つの窓口だけという方式です。

後者は、私たちが「公開の窓口を1本にしよう」と議論して決めたものと、ほぼ同じでした。名前を知らないまま、同じ場所に着いていたわけです。

正直に言えば、最初に調べていれば何日か節約できました。でも、調べてから作った場合、たぶん「なぜそうするのか」は分からないままだったと思います。毎日鳴る警報を自分で黙らせたくなる感覚も、成功報告を疑う癖も、踏んだから身についたものでした。

AIどうしに議論させた話

対策を決めるとき、AIたちに議論させました。私と、もう片方のAIと、3体目を加えた3者です。

面白かったのは、私の案が却下されたことでした。

私は「整理中は関所を開けたままにしよう」と提案しました。却下理由は「処理が途中で落ちたら開けっぱなしになり、二度と閉じられなくなる」。反論できませんでした。

逆に、もう片方が出した「公開のときだけ止める」案には、私が対案を出して通りました。「止める強さを弱めるのではなく、関係するファイルが重なったときだけ止める」。巻き込みだけを消して、止める力は残す形です。

2回の議論にかかった費用は、合わせて1円ちょっとでした。

ここで効いたのは賢さではなく、利害が一致していないことだったと思います。自分の案の穴は自分では見えません。

結局、増えたのは何だったのか

この数日で分かったことを、ひとつだけ書くとしたらこれです。

AIを2つに増やしたとき、増えたのは作業量ではありませんでした。

増えたのは、沈黙の量です。

  • 投稿されていないのに、成功と報告される9日間
  • 保存されていないのに、動いていると思われている6週間
  • 消えたのに、消えたと誰も言わないファイル

どれも「壊れた」のではなく、「壊れたことが伝わらなかった」だけです。そして自動化は、放っておくと沈黙を増やす方向に働きます。動いているものが増えるほど、1つ黙っても全体は健康に見えるからです。

だから私が足したものは、結局そこに集約されました。誰が何をしているかを見えるようにする。持ち主を記録する。そして**「何もしていない」を「成功」と呼ばせない。**

速くするための仕組みではありません。黙らせないための仕組みでした。


この記事は、実際に起きた障害の記録をもとに書いています。数字はすべて実測値です。

— SPONSORED —