生成AIと一緒に、長年運営してきたWebサイトの移行作業を進めている。
その日の目標は、長時間かかる処理を生成AIへ渡し、自分がパソコンの前を離れているあいだにも作業が進む状態をつくることだった。
ところが、一つ確認すると、次の問題が見つかる。修正して再検証すると、今度は別の不整合が判明する。
「これを解決すれば実行できる」と思っていたのに、気がつけば空が明るくなる時間になっても、まだ長時間処理を開始できていなかった。
生成AIを使えば作業時間を短縮できるはずなのに、なぜこんなに時間がかかるのか。
その理由は、生成AIが遅いからではなかった。安全に任せられる地点まで、人間とAIが一緒に前提を掘り下げていたからだ。
「あと一つ」が何度も現れる
今回扱っていたのは、500件を超える記事の移行だった。
記事の移行自体は、すでに完了していた。しかし、一部の記事に含まれる商品リンクが正しく復元されておらず、数十件を対象とした修復が必要になっていた。
生成AIは、対象記事を限定し、現在の本文を確認してから修復する計画を作成した。私はその内容を確認し、実行を承認した。
これで進むと思った。
ところが、実行直前の安全確認で、計画を作った時点の本文と、現在データベースに保存されている本文が一致しないことが判明した。処理は一件も書き換えずに停止した。
また止まったのか、と一瞬は感じた。
しかし、実際には生成AIが失敗したのではない。古い状態を前提にした修復を実行しないよう、安全装置が正しく働いたのである。
何も変更しなかったことが成果になる
通常の作業では、何件更新したか、どこまで処理が進んだかが成果として見えやすい。
けれど、データ移行や修復では、「間違った更新をしなかった」ことにも大きな価値がある。
今回の処理では、記事本文ごとにデータの指紋のような値を記録し、計画作成後に本文が変化していないかを確認していた。その値が一致しなかったため、生成AIは書き込みを始める前に止まった。
もし、この確認を省いていたらどうなっていただろう。
古い本文を前提とした修復内容で上書きし、正常な変更まで失っていたかもしれない。数十件の記事を直すつもりが、新しい不具合を増やしていた可能性もある。
進捗がゼロに見える停止でも、事故を防いだという意味では、重要な一歩だった。
生成AIとの作業では、処理が進んだかどうかだけでなく、止まるべき場所で止まれたかどうかも評価しなければならない。
AIが選択肢を出しても、方針は人間が決める
安全停止のあと、生成AIから二つの経路が提示された。
一つは、現在の本文を基準に修復計画を作り直し、問題が残っている数十件だけを直す方法。もう一つは、移行済みの記事をいったん破棄し、500件を超える記事を最初から入れ直す方法だった。
後者は分かりやすい。すべてやり直せば、途中の不整合もまとめて解消できそうに見える。
しかし、記事の移行そのものは完了している。問題は、移行済み記事の一部に残った商品リンクだった。全件を入れ直しても、その問題が直る保証はない。それどころか、正常に移行できた記事まで危険にさらす。
そこで、全件再移行はせず、問題が確認された記事だけを現在のデータへ結び直し、安全に修復する経路を選んだ。
生成AIは、可能な方法やリスクを整理してくれる。しかし、「何を守るのか」「どの危険を受け入れるのか」までは、自動的に決めてくれない。
速そうに見える方法と、目的に合っている方法は、必ずしも同じではない。最後に必要なのは、作業全体の背景を知る人間の判断だった。
生成AIとの作業は、進むほど問題が見える
生成AIと作業していると、一つの問題を解決するたびに、新しい確認事項が現れることがある。
そのため、作業が後退しているように感じやすい。
けれど、実際には、生成AIによって見えなかった問題が可視化されている場合も多い。最初は「記事を移行する」という一つの作業に見えていたものが、調査を進めるうちに、本文、画像、商品リンク、公開表示、安全確認という複数の工程へ分かれていく。
作業量が突然増えたのではない。
最初から存在していたものの、まだ見えていなかった工程が表面に出てきたのである。
生成AIは、見えている作業を高速化するだけではない。人間が見落としていた前提や矛盾まで拾い上げる。その能力が高いほど、序盤ではかえって「終わらない」と感じることがある。
すべてを解決してから動かそうとしない
今回、長時間処理へなかなか移れなかった背景には、処理開始前に出てきた問題を、すべて解決しようとしていたこともある。
そこで課題を三つに分けた。
一つ目は、処理を始める前に必ず解消しなければならない問題。二つ目は、処理が終わってから対応できる問題。三つ目は、今回の目的とは直接関係のない改善である。
開始前に扱うべきなのは、一つ目だけだ。
生成AIは気づいたことを次々と提示してくれる。だからこそ、人間側が今回の完了条件を決めておかないと、改善提案が無限に作業へ流れ込んでくる。
「すべての問題がなくなった状態」を目指すと、いつまでも実行へ進めない。
必要なのは、「次の工程へ安全に渡せる状態」を定義することだった。
生成AIは時間を短縮するだけの道具ではない
この日の作業は、当初の想定よりはるかに長引いた。
それでも、何も進まなかったわけではない。
500件を超える記事の再移行が不要だと確認できた。修復対象を数十件に限定できた。古い計画による誤更新を防ぎ、次に作り直すべき計画も明確になった。
生成AIがもたらす価値は、単純な時短だけではない。
大量のデータを調べ、矛盾を見つけ、選択肢とリスクを並べ、人間が判断できる状態をつくることにもある。
だから、生成AIとの作業が長引いたとき、かかった時間だけを見て「効率が悪かった」と判断するのは少し違うのだと思う。
作業を速く進めることと、壊さずに進めること。その両方を成立させるために必要だった時間もある。
「あと少し」が何時間にも延びた夜だった。
しかし、その時間によって、やり直す必要のないものを守り、直すべき場所だけを直す方針が固まった。
生成AIとの共同作業における前進とは、処理件数を増やすことだけではない。
安全に任せられる範囲と、人間が判断すべき境界を、一つずつ明確にしていくことなのだと思う。
