壊れたら、間違えたら、変えるとき、どうするか

仕組みは、必ず壊れ、間違え、変わります。壊れない仕組みを作るのではなく、壊れたとき・間違えたとき・変えるときの備えを、作る前に決めておく。それが、動かし続けるための土台です。そしてもう一つ。AIが「できました」と言った時点は、完成ではありません。何をもって正しいと判断するかは、自社で決めます。

この記事は、実務編の6つ目の問いを扱います。長い問いなので、備え（止まったとき・直す人・戻す・記録）と、変えるとき（試す場・完成の基準・確認する人）に分けて見ます。テストの技法や、監視の仕組みの細部には降りません。

この仕組みが止まったとき、業務をどう続けるか

「そもそも自分たちで作るべきか」では、壊れても業務が止まらないかを、作るかどうかの基準にしました。ここで扱うのは、作ると決めた仕組みが止まったときの備えです。決めておくのは二つ、止まったときの代わりのやり方と、いつまでに直っていなければならないかです。止められる時間は、業務で違います。

業務	止まったときの代わりのやり方	いつまでに直す
会議室の予約	声をかけて調整する	急がない。数日止まっても済む
勤怠管理	その日の打刻は紙に書き、直った後に打ち直す	月末の締めまで。給与計算に間に合わせる

この二つが決まっていれば、止まった朝に慌てません。

壊れたら、誰が直すか

直す作業そのものは、AIに頼めます。基本編の「AIが書いたコードをどう動かすか」で扱ったとおり、エラーをそのまま貼り戻せば、たいていは原因の説明と直したコードが返ってきます。一度で直らなければ、出たエラーをまた貼ります。決めておくのは、この往復を誰がやるか、です。作った本人が休みの日、辞めた後、忙しくて手が回らないときに、代わりに往復できる人がいるか。

直す人を決めるのは、運用の責任者を決めること（「そもそも自分たちで作るべきか」）の一部です。直す人が一人しかいない状態は、止まったときの代わりのやり方がない状態と同じ重さで見ておきます。作った本人以外にも直せる状態の作り方は「特定のAI・サービス・本人がいなくても、直し続けられるか」で扱います。

間違えたら、元に戻せるか

誤った操作で記録が消えた。直したつもりが壊した。そのとき戻せるかどうかは、バックアップがあるかで決まります。バックアップとは、データとコードの控え——別の場所に取っておいたコピー——のことです。

何を	戻せる状態とは
データ	少なくとも前日の状態に戻せる控えがある
コード	リポジトリに履歴があり、前の版に戻せる

控えを取っているだけでは足りません。戻せるかを、一度は試しておく。スプレッドシートには版の履歴があり、クラウドのデータベースやファイルの置き場にも、自動で控えを取る仕組みが用意されていることが多いものです。ただし、最初から効いているとは限らず、有料の上位プランでだけ使えることもあります。どの仕組みで、いつの時点まで戻せるかを、作るときに確かめておきます。戻すと、控えを取った時点より後の記録は消えます。その分を打ち直せるように、止まったときの代わりのやり方がここでも効きます。データベースは、戻す作業そのものに慣れが要るので、控えと復元は専門家寄りの作業です。

何が起きたか、後から分かるか

間違いに気づいたとき、いつ、誰が、何をしたかが分からなければ、直しようがありません。それを残すのがログです。ログとは、仕組みが自分の動きを記録したもののことです。誰がいつログインしたか、どの記録をいつ変えたか、エラーがいつ出たか。

「そのデータは何で、どれを正とするか」の履歴が、直す前の値と誰がいつ直したかをデータの側に残すことなら、ログは、ログインや操作やエラーを仕組みの側に残すことです。勤怠管理なら、打刻の修正は両方に残り、修正の前に誰がログインして何を開いたかは、ログにだけ残ります。AIに頼むときは、「誰がいつ何をしたかの記録を残して」と一言添えます。細かい監視の仕組みは要りません。後から追える記録があれば足ります。

変えるとき、本番を壊さず試せるか

業務に使っている仕組みを、本番と呼びます。本番を直接いじって試すと、試している間は業務が止まり、失敗すれば記録が壊れます。試す場を本番と分ける。コピーを作り、そこで直し、確かめてから本番に反映します。反映する時期も選びます。勤怠管理なら、月末の締めの直前は避けます。

試す場に、本番のデータをそのまま持ち込まないことも大事です。勤怠の記録は社員の個人情報です。試すために社員全員分をコピーして、試す場に置きっぱなしにすると、守るべき場所が二つに増えます。試す場には、架空の社員数人分のデータを置きます。

作ったものが正しいと、何をもって判断するか

AIは、頼まれたものを作り終えると、たいてい「できました」と返してきます。けれど、それは「動くものを書いた」であって、「自社の業務で正しく動く」ではありません。完成の基準は、自社が持ちます。基準は4つです。

確かめること	何で確かめるか
例外でも期待どおり動くか	「業務は整っているか」で書き出した例外の一覧。打刻忘れ、直行直帰、日をまたぐ勤務
想定外の値や操作をされたとき、どうなるか	未来の日付で打刻する、空欄のまま送る、同じ日を二度打つ
権限の違う人で試したか	「誰に何を見せ、何をさせてよいか」の表。表の役割それぞれでログインして、見えてはいけないものが見えないか
修正で、以前動いていた部分を壊していないか	直す前に動いていた操作を、直した後にもう一度通す

この4つを、AIに頼む前に用意しておくと、「できました」の後に確かめることが決まります。テストの技法を学ぶ必要はありません。自社の例外と役割の一覧が、そのまま確認の項目になります。

変えた後、期待どおり動くことを誰が確認するか

最後に、確認する人です。作った本人は、自分の意図どおりに動くかは見られますが、意図そのものの抜けには気づきにくいものです。直した後に、上の4つを通す人を決めておきます。最低限、作った本人と、実際にその業務を回している人の二人です。勤怠管理なら、作った本人と、月末の集計をする担当者になります。それ以上の体制を大きく作る必要はありません。

つまずきやすいところ

• AIの「できました」で終わりにする。 「動いた」は入口です。上の表の4つ（例外・想定外・権限・修正で壊していないか）を通して、初めて業務に乗せられます。
• バックアップを取って安心する。 戻したことのないバックアップは、戻せるかどうか分かりません。一度は戻す練習をします。
• 本番で試す。 急いでいるときほど、本番を直接直したくなります。「コピーで試してから反映する」を崩しません。
• 備えを、作ってから決めようとする。 止まったときの代わりのやり方、戻し方、確かめる項目は、作る前に決めるほうが楽です。作った後は、動いていることに安心して手が回りません。

まとめ

仕組みは壊れ、間違え、変わります。止まったときの代わりのやり方と、直っていなければならない期限を決め、直す往復を誰がやるかを決めます。戻せる控えを取り、一度は戻してみます。誰がいつ何をしたかの記録を残し、試す場を本番と分け、本番のデータを持ち込みません。完成の基準を4つ持ち、AIの「できました」で終わりにせず、直した後に確かめる人を決めます。

備えが決まったら、最後の問いです。作るのに使ったAIやサービスが変わっても、作った本人が抜けても、会社として直し続けられるか。「特定のAI・サービス・本人がいなくても、直し続けられるか」で扱います。