【AI導入日記#12】動いているのに直せない──内製AIツールが止まった日にやること

止まる日は、いちばん忙しい日に来る

昨日まで動いていたものが、今日は動かない

AIで内製した業務ツールを持つ会社が、必ず一度は通る日があります。昨日まで当たり前に動いていた処理が、今日は途中で止まる。画面には見慣れない文字列が出ている。作った本人も、その文字列を初めて見る。そういう日です。

そしてこの日は、たいてい忙しい日に来ます。月末の締め、繁忙期の受注ピーク、担当者が出張に出ている午後。仕組みが最もよく使われる時期は、扱う量が最も増える時期でもあるからです。量が増えたときに表に出る設計上の無理は、暇な日には顔を出しません。

止まったこと自体は事故ではありません。事故になるのは、止まったあとの動き方が決まっていないときです。この記事では、当社が自社サイトの運用で決めた手順を、そのままお渡しします。

「再実行したら直った」で終わらせない

止まったツールは、もう一度動かすと動くことがよくあります。業務が回り始めるので、その日はそれで終わります。翌朝には、止まったこと自体を誰も覚えていません。

ここで終わらせると、同じことがもう一度起きます。しかも二度目は、一度目より悪い条件で来ます。再実行で直ったときこそ、記録を残すタイミングです。原因が分からなくて構いません。日時、どの操作の途中だったか、画面に何が出ていたか。この3つを書くだけで、二度目の切り分けにかかる時間がまるで変わります。

「再実行したら直った」は、直っていません。原因が残ったまま、症状だけが消えた状態です。消えた症状は、必ず戻ってきます。

怖いのは性能の限界ではなく、復旧できなさ

内製AIツールでいちばん怖いのは、AIの性能が足りないことではありません。止まったときに、原因を追える記録も、追える人もいないことです。動いているうちは最高の道具ですが、止まった瞬間に業務ごと止まります。そして、なぜ止まったのかを知る手段がありません。

この「復旧できなさ」は、画面には映りません。権限の穴やデータ量の限界と同じで、動いている限り誰も気づけません。気づくのは、止まった日の午後です。内製AIツール診断で最初に確認するのも、動作の速さではなく、この復旧の可否です。

止まった日に、最初にやること

原因より先に、被害を数える

止まったと分かると、原因を探しに行きたくなります。手を動かせる人ほどそうなります。しかし業務が乗っている仕組みでは、先にやることがあります。何件が処理済みで、何件が未処理で、二重に処理されたものがいくつあるか。この3つの数を確定させることです。

順番を間違えると、原因を追っている間に、取引先や顧客への影響が静かに広がります。請求が二重に飛ぶ、発送が漏れる、在庫の数が合わなくなる。あとから範囲を特定する作業は、その場で数えるより何倍も重くなります。関係先への説明も、範囲が確定していなければ始まりません。

被害の範囲さえ押さえていれば、原因究明は落ち着いて進められます。まず数える。これが当社の第一手です。

止める判断を、誰がするか

次に難しいのが、止めるかどうかの判断です。動かし続けたほうが被害の小さい障害と、動かし続けるほど被害が広がる障害があります。二重処理や誤送信が起きているなら、迷わず止めます。表示が崩れているだけなら、止めずに直します。

この判断は技術の問題ではなく、業務の問題です。決めるのは、作った本人ではなく業務の責任を持つ人です。そして平時のうちに「誰が止める判断をするか」を決めておかなければ、止まった当日は誰も判断しません。判断されないまま動き続けるのが、いちばん被害の大きくなる形です。

止める権限を現場に渡すことを恐れる会社がありますが、逆です。止めてよいと言われていない現場は、おかしいと気づいても動かし続けます。

応急処置と恒久対応を、はじめから分ける

業務を戻す作業と、原因に手を入れる作業は別物です。混ぜると、応急処置で業務が回った時点で気持ちが済んでしまい、根本の原因が残ります。残った原因は、次の忙しい日に同じ症状で戻ってきます。

当社は、応急処置をした時点で「恒久対応が未完了である」と記録に残す運用にしています。書かれていない対応は、終わったことにされるからです。応急のまま半年動いている処理は、どの会社にもあります。

止まったときの型を、5つに固定する

障害のたびに手順を考えていると、判断が遅れます。順番を先に決めておけば、慌てずに動けます。当社が使っている型は、次の5つです。

この表を印刷して、ツールを使う場所に貼っておいてください。作った本人が不在でも、最初の1時間の動き方が変わります。

いまお使いの仕組みで、この5つのうちどこが埋まっていないか。内製AIツール診断では、動いている実物を拝見して、止まった原因を追える記録があるか、復旧の手順が言語化されているかを点検します。初回のヒアリングは無料・オンライン・所要60分です。

止まったとき誰が何をするかを、60分で整理する（無料）→

直せない会社に共通する、3つの欠落

何が起きたかの記録がない

1つ目は、障害そのものの記録がないことです。どこで止まったのか、どんな入力だったのか、何が返ってきたのか。これが残っていないと、対応はすべて推測になります。推測で直すと、直ったかどうかも推測になります。

記録は、凝った仕組みでなくて構いません。日時と症状を書いたメモが1か所に集まっているだけで、3回目には傾向が見えます。「月初に多い」「件数が多い日に出る」といった傾向は、記録がなければ絶対に見えません。傾向が見えれば、原因の候補は一気に絞れます。

何を変えたかの履歴がない

2つ目は、変更の履歴がないことです。AIに何度も修正を頼むうちに、いつ何を変えたのかが分からなくなります。すると「昨日から動かない」という最も有力な手がかりが、役に立たなくなります。昨日との差分が分からないからです。

内製AIツールでこの欠落が起きやすいのは、修正が速いからです。思いついた瞬間に指示を出せば、数分で直ります。速いぶん、記録を残す間もなく次の修正に移ります。手で書いていた時代より、履歴は残りにくくなっています。

「正常な状態」が定義されていない

3つ目が、いちばん見落とされます。そもそも「正しく動いている状態」を言葉にしていないことです。定義がなければ、直ったかどうかを判定できません。画面にエラーが出なくなっただけで、直ったことにしてしまいます。

判定は数で書きます。入力した件数と出力の件数が一致する。合計金額が元の資料と合う。同じ番号が二度出てこない。見れば白黒がつく形にしてください。エラーが出ないことと、結果が正しいことは別物です。この2つを分けられるかどうかが、運用の質を決めます。

実際、最も見つけにくい障害は、止まる障害ではありません。止まらずに、間違った結果を出し続ける障害です。エラーは出ないので、誰も気づきません。気づくのは、取引先から連絡が来たときです。

「AIに直して」と頼むときに、渡すもの・渡さないもの

感想ではなく、事実を渡す

AIに修正を頼むとき、進む人と進まない人の差は、渡す情報の質にあります。「動かないので直してください」だけでは、AIは推測で答えるしかありません。推測に推測を重ねた結果が、「直したら別の場所が壊れた」です。

渡すのは事実です。いつから、どの操作で、何件目で、どんな表示が出て止まったのか。エラーの文言はそのまま貼ります。要約したり、自分の解釈を足したりしないでください。解釈は、事実を渡したあとで一緒に考えれば済みます。

この6項目を埋めてから相談すると、やり取りの往復が減ります。埋められない項目があるなら、そこが記録の欠けている場所です。

一度に1か所しか変えない

気になる箇所をまとめて頼みたくなりますが、これが「直したら別の場所が壊れる」の主な原因です。一度に複数を変えると、効いた修正と壊した修正の区別がつきません。切り分けに戻る時間のほうが、まとめて頼んで浮いた時間より長くなります。

当社は、1回の指示で変える範囲を1か所に限る運用にしています。面倒に見えて、結果的にはこのほうが速く終わります。そして、変更のたびに「正常な状態」の定義で確認します。1か所ずつ変えて、そのつど確認する。この2つが揃って初めて、修正は前に進みます。

貼る前に、エラー文へ目を通す

エラーの文言には、顧客の氏名やメールアドレス、接続情報、認証キーが混じります。そのまま貼れば、そのまま外へ出ます。貼る前に一度読み、該当箇所は伏せてください。

そのつど迷わないよう、入力してよい情報といけない情報を先に決めておきます。当社は、認証情報と顧客の個人情報は伏せる、公開済みの内容と自社で作った下書きはそのまま渡す、という線引きで運用しています。この線引きの作り方は、Claude 法人導入支援でも最初に手をつける項目です。

当社がサイト運用で決めた、2つの約束

変える前に、戻せる状態を作る

当社はこのコーポレートサイトを、Claude Code で運用しています。日本語の指示だけで記事を書き、ページを更新し、サイトそのものを改修しています。その運用で最初に決めたのは、速く直す方法ではなく、変更の前に戻せる状態を作るという約束でした。

手順は単純です。作業に入る前に、いまの状態を保存する。作業後に問題が出たら、迷わず戻す。戻してから、あらためて原因を考える。壊れた状態のまま原因を追うのは、業務を止めながらの捜査です。失うもののほうが大きくなります。

戻せる状態がない仕組みは、修正するたびに賭けになります。賭けを避けようとすると、誰も何も直さなくなります。放置された仕組みは、放置されている間も古くなり続けます。

なぜ変えたかを、日本語で残す

もうひとつの約束が、変更の理由を日本語で残すことです。何を変えたかは後から追えますが、なぜ変えたかは記録しなければ消えます。そして障害対応でいちばん役に立つのが、この「なぜ」です。

難しく書く必要はありません。「表示が崩れていたので余白の指定を変えた」で十分です。数か月後の自分は他人だと思って書く。これが記録の要点です。当社は用語の定義をそろえる目的でIT業界用語辞典も自社運用していますが、社内の記録も同じで、言葉が揃っていない記録は読み返せません。

安全のための仕組みが、攻めやすさになる

戻せる状態を作る、理由を残す。どちらも地味な決めごとです。しかしこの2つがあると、変更のハードルが下がります。戻せると分かっていれば、思い切って試せるからです。

安全側の仕組みは、守りの投資に見えて、実際には速度を上げます。当社が自社サイトで日本語の指示だけで改修を回せているのは、指示の書き方が特別だからではありません。失敗しても戻せる形にしてあるからです。

止まる前に用意する、1枚の復旧手順書

書くのは5項目だけ

復旧手順書と聞くと身構えますが、紙1枚で足ります。書くのは次の5項目です。

この5項目が埋まっていれば、作った本人が不在でも初動が取れます。初動が取れるかどうかで、復旧までの時間は桁で変わります。

埋まらない項目が、いまの弱点

書いてみると、埋まらない項目が出ます。それが現在の弱点です。「正常な状態」が書けないなら、判定基準がありません。「戻す手順」が書けないなら、変更が一方通行になっています。

弱点が言葉になった時点で、次の一手は決まります。全部を一度に直す必要はありません。埋まらなかった項目のうち、業務が止まったときに最も困るものから順に手を入れます。

属人化は、事故のリスクであり、経営上の制約

作った本人しか直せない仕組みは、その人が休めない仕組みです。旅行に行けない、体調を崩せない、他の仕事に移れない。これは事故のリスクであると同時に、経営上の制約です。人を採用しても任せられず、担当を替えられず、その人の時間が上限になります。

記録を残す作業は、会社を守る作業であると同時に、その人が休むための作業です。引き継げる形にして初めて、内製AIツールは個人の便利道具から会社の資産に変わります。

当社の内製AIツール診断では、止まった原因を追える記録があるか、復旧の手順が言語化されているか、作った本人以外が運用できるかを、動いている実物で点検します。ご用意いただくのは画面ひとつだけです。資料も事前整理も要りません。差し支えのある情報は伏せていただいて構いません。

動いている実物を見せて、危ないところを洗い出す（無料・60分）→