結論から言うと、並行作業では「一番新しい結果」を「自分の依頼の結果」と思い込む取り違えが起こりえます。HaruIroAIで昨日実際に起きたのは、3体のAIに検品を同時に頼んだところ、1体分の依頼がジョブの記録に残らず、そのAIが「一番最後に始まった仕事」——つまり隣のAIの仕事——を自分のものとして回収しかけた、という出来事でした。
先にお伝えしておくと、この取り違えは結果が使われる前に、番号の照合で止まっています。間違った検品結果で記事を直した事実はなく、お客様への影響もない、社内工程の中の出来事です。だからこそ、どうやって止まったかの手順が、そのまま皆さんに使っていただける防ぎ方になります。
何をしていたか。3本の記事の検品を、3体のAIへ同時に頼んだ
HaruIroAIでは、ブログ記事を公開する前に、書いた側とは別のAIに検品させる工程を挟んでいます（この運用自体は以前の記事で書いたとおり、普段どおりの手順です）。昨日はまとめて3本の記事を仕上げていたため、検品を担当するAIを3体、記事ごとに1体ずつ、ほぼ同時に走らせました。
この3体は、検品の実行に同じ「共有の実行環境」を使います。依頼を受け付けて、順に処理していく窓口のようなものです。3体が同時に窓口へ依頼を出す——ここに今回の落とし穴がありました。
何が起きたか。2件は0.2秒差で受理され、1件は記録に残らなかった
あとから記録を確かめると、3体のうち2体分の依頼は、わずか0.2秒差で受理されていました。ところが3体目の依頼は、受理の記録そのものが残っていませんでした。どの段階で失われたのかは、記録がないため分かりません。分かるのは、窓口の記録のどこにも存在しない、ということだけです。
この時点で、3体目のAIから異常の報告はなく、工程はそのまま進みました。
依頼が残らなかった1体は、「一番新しい仕事」を回収しようとした
しばらくして、3体目のAIが結果を回収しようとしました。使ったのは「一番最後に始まった仕事の結果を取る」という方法です。自分の依頼と回収対象が1対1に対応している状況なら、これで対象は一致します。しかし共有の実行環境では、「一番新しい仕事」が自分の依頼だとは限りません。
ところが実際に「一番新しい仕事」だったのは、隣のAIが進めていた、別の記事の検品でした。自分の依頼は記録に無いのですから、どれだけ待っても自分の仕事は現れません。それでも見た目の上では、「一番新しい仕事」がそこにある。AIがその番号を自分の仕事として報告し、回収を試みた記録が残っています。
幸い、この時点では対象の検品がまだ実行中である旨が返り、結果は回収されませんでした。
番号を突き合わせて、取り違えが発覚した
回収できなかったことをきっかけに、そのAIは依頼の番号——仕事1件ごとに付く整理番号——を突き合わせました。すると2つのことが分かりました。回収しようとしていた番号は、別の記事の検品のものだったこと。そして、自分が出したはずの依頼は、そもそも記録のどこにも存在しないことです。
AIはこれを自分から訂正報告してきました。その番号は自分の仕事ではなく、自分の依頼はそもそもジョブ記録に存在しない、という内容です。その上で、正しい依頼を新しい番号で出し直し、以後の受け取りは番号を指定して行うようにしました。検品はその番号で正常に完走しています。
もしあのとき、実行中ではなく完了した結果が返っていたら——別の記事に向けた検品指摘を、違う記事に適用してしまう混乱が起きえました。指摘はどれも自信のある文章で書かれているので、中身だけを読んで取り違えに気づくのは難しかったはずです。止めたのは、内容の吟味ではなく、番号の照合でした。
直し方。「一番新しい」ではなく「番号の一致」で受け取る
この出来事を受けて、HaruIroAIで整理した手順は3つです。
1つ目は、並行で頼む依頼には、最初から番号や名前を付けることです。「A記事の検品」「B記事の検品」と名前が付いていれば、答えを受け取る側は名前で照合できます。付いていないと、「一番新しいもの」のような、あいまいな手がかりに頼りやすくなります。
2つ目は、答えを受け取るときに、「これはどの依頼への答えか」を答えの側に言わせることです。番号の照合と合わせれば、二重の手がかりになります。人間側の記憶で「たぶんこれはあの依頼の答え」と照合するのは、並行数が増えるほど当てになりません。
3つ目は、照合が合わないときは、答えを使う前に止まることです。今回も、事故にならなかった理由は「賢く取り違えを見抜いた」からではなく、「合わない時点で使うのをやめて、確かめ直した」からでした。当日中に、結果の受け取りをすべて番号指定へ切り替え、同日の後続の検品では取り違えは再発していません。仕組みとして強制する対策はこれからで、今はまだ運用の手順で守っている段階です。
番号札という、昔からの知恵
振り返ってみると、これはAIに特有の新しい問題ではありません。レストランの呼び出し番号、クリーニングの引換札、薬局の受付番号——並行して進む仕事の受け渡しを間違えないために、人間はずっと「番号の照合」を使ってきました。AIとの仕事が並行になった途端、同じ知恵がそのまま必要になった、というだけの話です。
似た形の出来事は以前にもありました。同じお願いをしたはずなのに、前の返事がそのまま返ってきた——承認の仕組みに見つけた盲点では、依頼の「同じ・違う」の判定を仕組みが取り違えました。今回は、答えの「自分の・他人の」の照合が抜けかけました。どちらも、内容の賢さではなく、突き合わせの設計が結果を分けています。
これはHaruIroAIで起きた1件の実例で、AIを並行で使うと必ず取り違えが起きるという話ではありません。ただ、AIへの依頼を並行にし始めたら、「この答えは、どの依頼への答えか」を確かめる一手間を、受け取りの手順に最初から入れておく価値はあるはずです。
この記事を書いた人
この記事の作り方
この記事は、構成・一次記録の照合・文章化にAIを使用し、HaruIroAIの編集ルールと社内の一次記録に基づいて作成しています。実行環境やAI製品の名称、依頼番号の実際の値は、本題と無関係なため記載していません。内容は公開前に人が最終確認しています。