仕事の流れが一箇所で止まり、原因を特定する様子を表した生成ビジュアル

AI社員が動かないときの復旧方法|7つの停止症状から原因を特定

AI社員やAIカンパニーが止まったら、七つの項目を一度に直さないでください。最後に止まった一業務を開始からたどり、最初の停止点を一箇所だけ直して、同じ案件を再実行します。

新しいAIへ替えるのは、停止点がモデルの能力にあると切り分けた後です。役割が曖昧、正式情報が決まっていない、入力不足、完了を判定できないという状態では、モデルを替えても同じ場所で止まります。

まず、最近止まった一業務を一本だけ選ぶ

「AI社員が使われない」という全体症状では、原因を特定できません。最後に期待どおり終わらなかった案件を一つ選び、依頼を受けた時点から結果を渡す時点まで、実際に残っている入力、出力、検証、承認記録をたどります。

記憶で説明を補わないことが重要です。記録がない地点は、それ自体が停止点の候補です。

5分診断:Yesの数ではなく、最初の停止点を探す

選んだ案件を、次の順で止めながら確認します。後ろの項目まで採点する必要はありません。最初に実物で説明できなくなった行が、最初に直す候補です。

幅が狭い場合は表を横にスクロールできます

実物で確かめること 説明できないときの停止点 次に開く記録
誰が、何を受け取り、何を作る仕事だったか 役割 依頼内容と役割定義
どの情報を正式なものとして使ったか 会社情報 参照元と更新時点
開始時に必要な入力がそろっていたか 入力・停止条件 受領した項目と不足確認
誰へ何を渡せば完了だったか 完了条件 成果物と受け取り手の要件
正しさを何で確かめたか 検証 検証結果と失敗内容
外部送信や重要な変更を誰が決めたか 承認 承認対象、判断者、対象版
修正理由と次の担当が残ったか 記録・引き継ぎ 実行結果、判断理由、未完了

たとえば検証結果がない場合でも、その前に完了条件を説明できなければ、最初に直すのは検証ではなく完了条件です。何を正解とするか決まっていないまま、検査だけを増やしても復旧しません。

AIカンパニーが止まったときに、役割、情報、入力、完了条件、検証、承認、改善記録を順に確かめる図
最後に止まった一業務をたどり、最初に説明できなくなった地点だけを直す。

停止点1:毎回、仕事の説明からやり直している

症状: 同じAI社員へ頼んでいるのに、担当者が依頼のたびに目的、範囲、成果物を説明している。

見分け方: 役割名を隠し、実際の入力、作る成果物、渡す相手、担当外を一文で説明できるか確かめます。「営業AI」「経理AI」のような肩書しか残らないなら、停止点は役割です。

最初の修正: 役割を一つの受け渡しへ狭めます。「何を受け取り、何を作り、誰へ渡すか」を決め、担当外と人へ戻す条件を添えます。人格や名称の作り直しは後回しにします。AI社員の役割カードで、入力と出力を一つに絞れます。

停止点2:同じ依頼なのに、答えの前提が変わる

症状: 古い価格や廃止した表現が混じる。担当者によってAIへ渡す資料が変わり、出力も揺れる。

見分け方: 問題の出力に使われた根拠をたどり、「その時点で会社が使う正式情報だった」と説明できるか確認します。似た資料が複数あることだけでなく、どれを更新する責任者か決まっていない状態も該当します。

最初の修正: 問題になった項目だけ、正式な参照元と更新責任者を一つ決めます。全社資料の整理から始めず、同じ案件の再実行に必要な情報へ範囲を限定します。AIに渡す会社情報の整理方法では、原文、過去の判断、現在使う情報を分ける方法を扱います。

停止点3:情報が足りないのに、処理が進む

症状: 対象期間、顧客名、契約版などが欠けているのに、もっともらしい成果物が作られる。

見分け方: 開始時に受け取った実物と、仕事に必要だった項目を並べます。不足があったのに質問、保留、差し戻しの記録がなければ、入力と停止条件が原因です。

最初の修正: 必須入力を追加し、一つでも欠けたら成果物を作らず、不足項目を示して人へ戻します。推測で補ってよい項目を増やす前に、推測してはいけない項目を固定します。

停止点4:出力はあるが、次の担当が使えない

症状: 長い文章や資料は作られているが、受け取った人が作り直す。作業がAIの出力で終わり、次へ渡らない。

見分け方: 出力の品質を抽象的に評価せず、次の担当が仕事を始めるために必要だった項目と照合します。受け取り手と必要項目が決まっていなければ、停止点は完了条件です。

最初の修正: 次の担当者が受け取る成果物の必須項目、形式、未確認事項を定めます。「分かりやすい」「高品質」のように合否を確かめられない言葉は、完了条件にしません。

停止点5:公開や送信の後に欠落へ気づく

症状: リンク切れ、数値の不一致、必須項目の欠落、動作不良が、成果物を渡した後に見つかる。

見分け方: 実行前の検証結果を探します。結果がない、実際には検査していない、失敗した項目を消して合格にした場合は、検証が停止点です。

最初の修正: 発生した欠落を一つ、再実行できる検証項目へ変えます。失敗したら基準を弱めず、入力、処理、期待結果のどこが違ったかを記録します。すべての品質問題を一度に検査しようとせず、今回の失敗を再び見逃さない検査から追加します。

停止点6:勝手に進む、または承認待ちで動かない

ここには反対の症状があります。

  • 外部送信、公開、契約、金額変更などが、人の判断なしに実行される
  • 戻せる内部処理まで同じ承認者へ集まり、待ち行列になる

見分け方: 業務名ではなく、問題の操作について、失敗時の影響、戻しやすさ、外部への作用を確認します。AIができるかどうかだけで実行区分を決めていたら、承認設計が停止点です。

最初の修正: 今回止まった操作を「自動」「確認付き」「人が判断・実行」のどこへ置くか一つだけ決め直します。承認依頼には変更、根拠、検証、未確認事項、影響、戻し方を添えます。AIを安全に使うための承認と管理のルールで操作ごとの委任表を作れます。

停止点7:直したはずの問題が繰り返される

症状: 同じ説明、差し戻し、判断を繰り返す。担当者が変わると、前回の修正がなかったことになる。

見分け方: 最後の成果物だけでなく、参照情報、検証結果、人が直した理由、未完了、次の担当をたどれるか確認します。説明できるのが当時の担当者だけなら、記録と引き継ぎが停止点です。

最初の修正: 今回の修正理由を、次回の仕事で参照する情報または手順へ一箇所だけ戻します。出力を保存するだけではなく、「なぜ直したか」と「次に誰が何を確かめるか」を残します。

直す順序は、最初の停止点から後ろへ進める

七つを成功要素のチェックリストとして全部整える必要はありません。実際の案件で最初に止まった地点を修正し、同じ入力を使って、そこから先へ進めるか再実行します。

  1. 停止点を一箇所に絞る
  2. その地点で必要な定義、情報、条件、記録のいずれかを直す
  3. 同じ案件を最初から再実行する
  4. 修正した地点を通過できた証拠を残す
  5. 次に止まった場合だけ、次の一箇所へ進む

役割と正式情報が説明できるのに承認だけで止まっているなら、役割設計からやり直す必要はありません。反対に、役割が曖昧なら、後工程の検証や承認を先に増やさないでください。

AIネイティブ企業の作り方では、復旧した一業務を30日間の成果物と完了条件へ戻して育てる順序を確認できます。

3日で最初の形を作り、帰社後に育てる

初期設定や対象業務の絞り込みで止まる場合、合宿で作るもの、作らないものを読むと、一業務の設計、動く試作、検証、帰社後の計画までの範囲を確認できます。

3日間で失敗がなくなるわけではありません。止まった理由を見つけ、帰社後に直せる状態を作ります。

AI社員が使われなくなったとき、七つ全部を整えてから再開する必要はありません。実際の一業務で最初に止まった一箇所を直し、同じ案件で通過できるか確かめることが復旧の単位です。

直した仕事を次の段階へ進める目安は、AIネイティブ経営の4段階で確認できます。