AIの動きを記録から追う方法|止まった理由を特定する

AIの動きを記録から追う方法|止まった理由を特定する

「うまくいかないのは、指示の書き方が悪いからだ」「出てきたものを見て、おかしければ直せばいい」——AIに一続きの作業を任せ始めた職場で、決まって交わされるやり取りです。どちらも間違ってはいませんが、任せる範囲が数手を超えたところで通用しなくなります。3つの資料を読み、2つの道具を使い、途中で条件を判断して分かれ道に進む。この長さになると、出てきた結果だけを見てもどこで道を外れたのかが分かりません。これは指示の巧拙の問題ではありません。本当は、途中の記録が残っていないために、原因のある場所を指し示せないという問題です。この記事では、途中の記録であるトレースに何を残し、どう読み、止まった理由をどう特定するかを整理します。


カメ先生カメ先生

AIの仕事は出てきた答えを見れば評価できると思われがちだが、本当は途中の記録を見ないと良し悪しが判断できないんだ。


カメ子カメ子

答えが合っていれば、それでよいのではないでしょうか。


カメ先生カメ先生

合っているように見えて、根拠にした資料が3年前のものだった、ということが起きる。逆に外れていても、原因が材料なのか道具なのか指示なのかは、答えだけからは切り分けられない。


カメ子カメ子

途中で何を読み、何を使ったかが残っていれば、そこが見えるということですね。


この記事のポイント
  • 答えの正誤だけでは原因の場所は分からない。読んだ材料・使った道具・判断の分かれ目を時間順に残す
  • 止まる理由は4つに絞れる。材料が足りない、道具が失敗した、指示が曖昧、途中で条件が消えた
  • いちばん危ないのは止まらずに間違える場合。形の整った結果ほど、記録を見ないと見抜けない

AI活用を戦略に落とす前に、まずは導入・定着から始めませんか?

デボノはアカウント開設・初期設定など「そもそものAI導入」から社内定着まで伴走支援。マーケティング活用など一歩進んだご相談にも対応します。

目次

月曜の朝、300件のうち80件しか出来ていなかった

具体的な場面から始めます。展示会で集めた名刺の情報が300件。これを業種と役職で読み分けて、それぞれに合わせた案内メールの下書きを作り、担当の営業ごとに振り分ける。この一続きの作業をAIに任せ、金曜の夜に走らせました。月曜の朝に確認すると、出来ていたのは80件です。残りの220件は、途中で止まっているか、宛名だけの空の下書きになっていました

この時点で担当者がまずやることは、たいてい指示文を読み直すことです。ところが指示は1つしかなく、300件すべてに同じものを使っています。同じ指示で80件は成功しているのですから、成否を分けた原因は指示の外にあります。指示文をいくら読み返しても、そこには書かれていません。

手元にあるのは「220件が失敗した」という事実だけです。どの工程で失敗したのかが分からないまま作り直せば、同じ割合でまた失敗します。しかも次に走らせるまで結果は分かりません。1回の試行に週末をまるごと使う作業では、当てずっぽうの修正が最も高くつきます

答えだけを見ても、原因の場所は分からない

社内では、AIの扱いをめぐる整備がすでにいくつか進んでいるはずです。どこまで任せるかを工程に割って決める話、利用のルールを規程として文書にする話、商談の記録をAIに作らせる話。本記事が扱うのはそのどれでもなく、動かした後に残った記録を読んで、原因の場所を特定する実務です。権限の設計が「これから何を任せるか」を決める作業だとすれば、こちらは「任せた結果、何が起きたか」を読む作業にあたります。決めるのが先で、読むのが後です。

なぜ結果だけでは足りないのか。理由は単純で、出力は結果であって経過ではないからです。同じ結果が、まったく違う原因から生まれます。先ほどの空の下書きを例にとると、原因として少なくとも3つが考えられます。名刺データの業種欄が空だった。参照するはずの製品資料の置き場に届かなかった。文章の分量が上限に当たって途中で切れた。

この3つに対する打ち手は、それぞれまったく違います。1つ目はデータの整備、2つ目は接続と権限、3つ目は工程の分割です。原因を1つに絞れないまま打ち手を選ぶと、3分の2の確率で外します。記録を読むというのは、この確率を下げるための作業です。

トレースとは、何を残したものか

トレースは、一続きの処理を時間の区間の集まりとして残したものです。いちばん外側の区間が作業全体を表し、その内側に、モデルへの1回の問い合わせ、道具の1回の実行、資料の検索といった小さな区間がぶら下がります。区間には親子の関係が付いているので、どの処理がどの処理の中で起きたかが分かります。

もともとは、複数の仕組みにまたがる処理を追いかけるために、監視の分野で長く使われてきた記録の形です。それをAIの処理に当てはめる共通の書き方が、2025年から2026年にかけて整えられました。使ったモデルの名前、入力と出力の分量、終了した理由、呼び出した道具の名前と識別子といった項目が定められ、主要な監視の仕組みや開発の枠組みが対応しています。

ただし、言葉の定義を覚えても実務は動きません。意味があるのは形式ではなく、何を読み、何を使い、どこで判断が変わったかが、時間順に並んでいることです。専用の仕組みが無くても、各工程の入口と出口を表計算に1行ずつ書き出すだけで、当面の役目は果たせます。まず何を残すかを決めるほうが先で、道具を選ぶのはその後です。

記録に残す7つの項目

残す項目を欲張ると、書き込む工数が増えて続きません。逆に少なすぎると、後から読んでも何も分かりません。実務で最低限そろえたいのは次の7つです。右端の列が、その項目が無かったときに分からなくなることです。

残す項目具体的に書く中身無いと分からないこと
作業の識別子いつ、どの依頼で走ったのかを一意に示す番号同じ失敗が繰り返しているのか、別件なのか
読んだ材料参照した資料の名前と、いつ時点のものか古い情報を根拠にしていないか
使った道具道具の名前、渡した値、返ってきた結果失敗が道具の側か、判断の側か
判断の分かれ目どの条件で、どちらに進んだか途中で方針が変わった箇所
終了した理由完了か、上限に当たったか、例外が出たか止まり方の種類
時間と分量工程ごとの所要時間、入力と出力の分量詰まっている箇所と、かかった費用
人が入った箇所誰がいつ承認したか、どこを直したか責任の所在と、確認が形だけになっていないか

7つのうち、切り分けに最も効くのは2番目と3番目です。読んだ材料と使った道具さえ残っていれば、失敗の大半は場所が特定できます。逆に、この2つを残していない記録は、量があっても読む価値が薄いです。導入の初期は、まずこの2つだけを確実に残すところから始めても構いません。

  • 材料は名前だけでなく、いつ時点のものかを一緒に残す
  • 道具に渡した値は、そのまま残す。要約すると再現できなくなる
  • 終了した理由は、成功と失敗の2値ではなく種類で残す
  • 工程の名前は、社内で通じる業務の言い方に揃える
  • 1件ごとの記録と、日次の集計は分けて置く。読む人が違う

どこまで残すか、機密と保存期間を先に決める

全部残しておけば安心、とはなりません。入力した文と出力された文には、顧客の名前や取引の条件がそのまま入ります。記録の置き場は業務の仕組みとは別の場所になることが多いので、そこに機密が複製されることになります。読むために残した記録が、新しい漏えいの経路になっては本末転倒です。

実務の作法としては、入力文と出力文の中身は既定では記録しない設定にしておき、調べる必要があるときだけ有効にします。記録する場合も、常に検索対象になる欄ではなく出来事として残し、長さを500文字から1000文字程度で打ち切る。収集の途中で特定の項目を伏せ字にする、条件に当てはまる記録は丸ごと除外する、といった手当ても組み合わせます。

量の決め方にも定石があります。試している間は全件、本番で成功したものは1割前後を抜き取り、失敗したものと、分量が極端に大きかったものは全件残す。この分け方なら、費用を抑えながら読みたい記録は手元に残ります。保存期間は二段に分けると扱いやすく、中身を含む記録は数週間、件数や時間だけの集計は年単位で持つ。期間を決めずに始めると、消す判断ができないまま増え続けます

誰の許可が要るかも、着手の前に確かめておきます。顧客の氏名や連絡先が記録に含まれるなら、その置き場と保存の期間は、個人情報の扱いに関する社内の取り決めの範囲に入ります。マーケの側だけで決めて走らせ、後から差し戻されると、記録そのものが止まって元の状態に戻ります。置き場所と、残す項目と、保存する期間。この3点だけを情報システムの担当に共有し、合意した内容を1枚の覚書として残しておけば、後の議論はほとんど起きません。逆にここを飛ばすと、いちばん記録が必要な時期に運用を止めることになります。

読み方の手順:時間の並びで原因を絞る

記録がそろったら読み方です。1件あたり数万字になることも珍しくないので、最初から通して読むと必ず埋もれます。読む順番を決めておくと、開く区間は数個で済みます。

STEP1
成功した回と失敗した回を1件ずつ並べる

同じ指示で成否が割れているなら、差は必ず経過にあります。両方の記録を横に置き、どこまで同じで、どこから違うかを見ます。分かれ目より前は原因ではないので、読む必要がありません。

STEP2
差が出た最初の区間を開く

食い違いが生まれた最初の区間だけを開き、そこで何を読み、何を渡し、何が返ってきたかを確認します。原因はここにある確率が最も高く、たいてい1画面で判断が付きます。

STEP3
終了した理由を確認する

完了したのか、上限に当たったのか、例外が出て止まったのか。止まり方の種類によって、次に見る場所が変わります。例外なら道具の側、上限なら工程の分け方の側です。

STEP4
同じ止まり方が何件あるかを数える

1件だけなら個別の事情、まとまった数なら仕組みの側の問題です。件数を数えるまでは打ち手を決めません。1件の事故に合わせて全体を作り替えるのが、最も損の大きい対応です。

この順で読むと、冒頭の300件の例では220件のうち大半が同じ止まり方をしていることが分かります。件数の内訳が出た時点で、原因は2つか3つに絞れています。ここまで来てから、次の4つの型のどれに当たるかを見ていきます。

切り分け1:材料が足りなかった

記録での見え方は特徴的です。道具は正常に動き、モデルも答えを返している。それでも読んだ材料の欄が空になっているか、想定していたものと違う資料が並んでいます。出力そのものは形が整っているため、結果だけを見ていると気づけません。

冒頭の例に当てはめると、名刺データの業種欄が空のまま取り込まれていた、という状況がこれにあたります。業種が分からなければ文面を分けられないので、AIは当たり障りのない文章を作るか、判断できずに止まります。展示会で集めた名刺は手書きや撮影から起こすことが多く、特定の欄だけが大量に欠けるのはよくある事故です。

打ち手は材料の側にあります。足りない項目は先に人が埋めるか、埋まらない場合の既定の動きを決めておく。足りないときに止まるのか、既定値で進むのかを先に決めていないと、記録を見ても仕様なのか事故なのか判断できません。この一文を工程の説明に書き足すだけで、次からの切り分けが速くなります。

切り分け2:道具が失敗した

道具の区間に例外がそのまま残るので、記録の上ではいちばん見つけやすい型です。接続できなかった、権限が足りなかった、呼び出しの上限に当たった、返ってきた値が空だった。失敗の内容が文字で残るため、原因の特定に迷いはほとんど生じません

実務で多いのは権限と上限の2つです。特に見落とされやすいのが、まとめて処理したときにだけ現れる制限です。1件ずつ手で試したときには出なかったのに、300件を続けて流すと途中から弾かれる。週末にまとめて走らせる運用は、この型の失敗を最も引き当てやすい形です。時間帯や件数で制限が変わる仕組みを使っている場合はなおさらです。

打ち手は3つです。失敗したときに何回、どの間隔でやり直すかを決める。やり直しても駄目だった件は別の一覧に落として、全体は止めずに先へ進める。そして翌営業日に、その一覧だけを人が見る。1件の失敗で全体が止まる作りにしないことが、無人で走らせる処理の前提になります。

切り分け3:指示が曖昧だった

材料も道具も正常で、それでも出力が毎回ばらつく。この場合は指示が複数の読み方を許しています。記録を横に並べると、同じような条件なのに違う分かれ道に進んでいる箇所が見つかります。そこが曖昧さの居場所です。

よくあるのは分類の定義が無い指示です。役職に応じて文面を変える、という指示は一見明確ですが、部長と本部長を同じ扱いにするのか、担当者と主任を分けるのかが書かれていません。丁寧に、簡潔に、といった形容も同じで、判断の基準がないので回ごとに揺れます。

打ち手は、指示文を丁寧に書き直すことではありません。曖昧さは言い回しではなく、分類の定義が無いところに宿ります。先に分類の表を作り、どれにも当てはまらないものは「その他」に落として人が見る、と決める。分けられないものを分けさせないのが要点で、この一手で出力の揺れは目に見えて減ります。

切り分け4:途中で条件が消えた

前半では守られていた条件が、後半で守られなくなる型です。300件を続けて処理する場合なら、最初の数十件は指定した書式どおりなのに、途中から書式が崩れる。記録を順に見ていくと、崩れ始めた地点がはっきり分かります。

原因は2つあります。1つは、やり取りが長くなるにつれて古い部分から扱いが軽くなり、あるいは切り落とされること。最初に伝えた守るべき条件ほど先に消えます。もう1つは、工程を分けて別々に処理させたときに、後の工程へ条件が引き継がれていないことです。渡した本人は伝えたつもりでも、次の工程はそれを受け取っていません

打ち手は、条件を工程の境目ごとに渡し直すことです。最初に1回だけ伝える形をやめ、工程が変わるところで守るべき条件を短くまとめて再度渡す。長い処理を1本で流さず、区切りを入れて条件を入れ直すほうが、結果として速く終わります。

止まらずに間違える場合が、いちばん危ない

ここまでは止まった場合の話でした。実務でより危ないのは、止まらずに最後まで進み、形の整った結果が出てくる場合です。AIに任せた処理の失敗は成功のように見える形で現れると指摘されています。形は正しいが中身が違う出力、必要のない道具の呼び出し、手順としては妥当だが意味の通らない操作。どれも件数の集計には表れません。

冒頭の例に戻すと、出来ていた80件のほうにも問題が潜んでいることがあります。宛名の会社名が別の会社のものになっている、実績として挙げた事例が業種の違う顧客のものになっている。完了した件数だけを見ていると、この種の誤りは一度も表に出ません。むしろ文章として整っているぶん、確認する人の目を素通りします。

対策は、完了した件も抜き取りで記録を読むことです。読むのは出力の文章ではなく、根拠にした材料の欄です。出力を読むと文章の巧拙に目が行き、中身の誤りを見落とします。どの資料のどの箇所を根拠にしたかを見れば、業種の取り違えはその場で分かります。抜き取りは全体の1割でも、傾向はつかめます。

あわせて、人が確認する範囲も先に決めておきます。全件を確認すると決めるのは、決めていないのとほとんど同じです。作る手間より確認の手間が上回った時点で、その仕組みは使われなくなります。確認する対象は、社名や人名といった固有名詞、金額と数量、日付の3種類に絞る。この3つ以外は元の資料と照らさない、と先に決めてしまえば、作業した本人でなくても確認できます。確認を属人化させないことが、無人で走らせる処理を続けるための条件です。抜き取りの割合と、確認する3種類。この2つを紙に書いておくだけで、運用は驚くほど安定します。

失敗の多くは、モデルではなく仕組みの決め方に由来する

経験則ではなく、まとまった検証もあります。2025年3月に公開され、同年10月に改訂された研究では、7つの主要な枠組みで動く構成の実行記録1,600件以上に人手で注釈を付け、14の失敗の型を整理しています。型は3つに大別され、仕組みの決め方に関するもの、担当どうしのすれ違いに関するもの、検証と終了に関するものです。

挙げられている型を日本語にすると、指示が不完全、指示が曖昧、目的がずれている、履歴が失われる、止め時が分からない、役割の決め方が甘い、決めた役割から外れる、伝達が不十分、連携が取れていない、早すぎる打ち切り、同じ処理の繰り返し、完了したかどうかを検証しない、といった具合です。並べてみると、モデルの賢さが足りないという型は1つも入っていません

この結果には実務上の意味があります。うまくいかないからといってモデルを新しいものに替えても、多くは直りません。直るのは、工程の区切り方、担当の決め方、終了条件の書き方のほうです。そしてそのどれもが、記録を読まなければ、どこが悪いのか判断できない箇所です。

3つの大別は、手を付ける順番としても読めます。最初に直すのは仕組みの決め方、つまり工程の切り方と指示の粒度です。次が、役割を分けている場合の受け渡しの作り。最後に、終わったかどうかを誰がどう確かめるかを決めます。順番を逆にして終了の確認だけを厳しくすると、確認で弾かれる件数が増えるだけで、原因は手前に残ったままになります。現場では、弾かれた件を人が手直しする作業が積み上がり、自動化した意味が消えます。工程の切り方から直すほうが、遠回りに見えて早く終わります。

症状別に、記録のどこを見るか

ここまでの内容を、現場で使える形にまとめます。出ている症状から、記録のどこを開けばよいかを引く表です。この順で見れば、たいていは3手以内で場所が決まります。

出ている症状記録のどこを見るか多い原因
途中で止まって進まない終了した理由と、直前の道具の区間権限不足、呼び出しの上限
中身が空、または当たり障りのない文章読んだ材料の欄材料の欠損、参照先に届いていない
同じ入力で結果がばらつく判断の分かれ目の記録分類の定義が無い
後半だけ書式や条件が崩れる崩れ始めた地点の前後の区間条件が引き継がれていない
同じ処理を延々と繰り返す区間の繰り返し回数と終了条件止め時が決まっていない
形は整っているが事実が違う根拠にした材料の名前と時点古い資料、対象の取り違え
費用が想定より大きい工程ごとの入力と出力の分量材料の渡しすぎ、工程の切り方

表を引く前に確かめておきたい項目もまとめておきます。ここが埋まっていないと、記録があっても読めません。運用を始める前に一度、そして三か月ごとに一度、この一覧で点検してください。

  • 1件ごとに一意の識別子が付いていて、後から特定の1件を呼び出せるか
  • 読んだ材料の名前と、その時点が残っているか
  • 道具に渡した値と、返ってきた結果が、要約されずに残っているか
  • 終了した理由が、成功か失敗かではなく種類で残っているか
  • 失敗した記録は全件残る設定になっているか
  • 入力文と出力文の中身を残すかどうかを、意図して決めたか
  • 記録の保存期間と、消す担当が決まっているか
  • 人が承認した箇所と、その人の名前が残っているか

用語を、実務の言い方に置き換えておく

この分野の言葉は英語由来のものが多く、社内で共有するときに詰まります。会議で使う言い方に置き換えておくと、情報システムの担当と話すときも、決裁者に説明するときも通ります。

記録まわりの言葉を、社内で使う言い方に直す
  • トレース:1回の作業について、途中の出来事を時間順に並べた記録のひとまとまり
  • 区間:作業の中の1工程ぶんの記録。開始と終了の時刻、入力、出力、結果が入る
  • 親子の関係:どの工程がどの工程の内側で起きたかを示す入れ子。原因の場所を絞るのに使う
  • 終了した理由:その工程がどう終わったか。完了、上限に到達、例外の発生などの種類
  • 抜き取りの割合:全部ではなく何割を残すかの設定。失敗した分は割合に関わらず全件残す
  • 伏せ字化:記録に残す前に、顧客名や連絡先などを別の文字に置き換える処理

言葉をそろえると、依頼の仕方も変わります。「ログを見せてください」では、何が返ってくるか分かりません。「この1件について、読んだ材料と終了した理由を出してください」と言えば、必要な情報だけが返ってきます。依頼の精度は、そのまま復旧までの時間に効きます。

社内の誰が、どの頻度で見るか

記録は、作れば読まれるものではありません。読む人と頻度を決めないと、置き場だけができて誰も開かない状態になります。実務では3つの役割に分けると回ります。粒度が違うので、同じ画面を全員で見る形にはしないほうがよいです。

日々見るのは業務の担当で、対象は失敗した件の一覧だけです。週に一度見るのはマーケの責任者で、止まり方の種類と件数の推移を見ます。月に一度見るのは情報システムの担当と決裁者で、傾向と、権限や上限の設定を見直すかどうかを判断します。日次の担当に傾向の分析まで求めると、どちらも中途半端になります

うまくいかない運用には共通した形があります。実際によく見かけるものを並べます。

  • 記録は取っているが、誰も開いていない:置き場を作った時点で終わり、失敗が起きてから初めて開く
  • 成功も失敗も同じ量だけ残す:費用が膨らみ、削減の対象になって最初に切られる
  • 失敗の件数だけを見る:止まり方の種類を見ないので、打ち手が毎回同じになる
  • 1件の事故に合わせて全体を作り替える:件数を数える前に動くと、効かない対策が積み上がる
  • 入力文と出力文を無条件に全部残す:顧客情報が別の場所に複製され、管理の対象が増える
  • 見る人を決めずに全員に共有する:全員が見ていると思い、結果として誰も見ない

最後の項目は特に多く見かけます。共有の範囲を広げることと、読む責任を持たせることは別です。見る人を1人決め、その人が読めなかった週は誰かに引き継ぐところまで決めておくと、運用が空洞化しません。

外部に委託しているとき、何を出してもらうか

自社で組んでいない場合、記録は委託先の中にあります。契約の時点で何を出してもらうかを決めておかないと、事故が起きてから交渉することになります。動いていない最中に条件を詰めるのは、時間の使い方として最悪です。

出してもらう対象は5つに絞れます。失敗した件の一覧と止まり方の種類、根拠にした材料の名前と時点、道具の実行結果、人が介在した箇所、そして保存期間と削除の方針です。入力文と出力文そのものは、必ずしも受け取る必要がありません。むしろ受け取ると自社側の管理対象が増えます。必要なのは中身ではなく、どこで何が起きたかの経過です。

確かめ方にもこつがあります。記録を取っているかと尋ねると、取っているという答えで終わってしまいます。

  1. 特定の1件を指定して依頼する:この案件のこの1件について、止まった理由を記録から示してくださいと頼む
  2. 返ってくるまでの時間を測る:即日で出るのか、1週間かかるのか。復旧までの時間はここで決まる
  3. 体制が変わったときの引き継ぎを確認する:担当が交代しても同じ記録が同じ形で出るかを聞いておく

この3つを発注前に一度試しておくと、運用が始まってからの見通しが立ちます。記録を出せない委託先は、原因を特定できない委託先でもあります。品質の話をする前に、ここを確かめておく価値があります。

まとめ

AIに一続きの作業を任せると、出てきた答えだけでは良し悪しも原因も判断できません。必要なのは、何を読み、どの道具を使い、どこで判断が変わったかが時間順に並んだ記録です。残す項目は7つで、なかでも読んだ材料と使った道具の2つが切り分けに効きます。読み方には順番があり、成功した回と失敗した回を並べ、差が出た最初の区間を開き、終了した理由を確かめ、同じ止まり方の件数を数える。ここまで来れば、原因は材料の不足、道具の失敗、指示の曖昧さ、条件の消失のどれかに絞れます。より危ないのは止まらずに間違える場合で、完了した件も抜き取りで根拠の欄を読む必要があります。まとまった検証でも、失敗の型はモデルの賢さではなく仕組みの決め方に集まっていました。記録には機密が入るので、中身を残すかどうかと保存期間は先に決め、失敗した分だけは全件残す。読む人は日次と週次と月次で分け、外部に委託している場合は特定の1件を指定して記録を出してもらえるかを発注前に試す。まずは直近で止まった処理を1件選び、その1件について何が記録に残っているかを確かめるところから始めてください。残っていない項目が、そのまま最初に足すべき項目です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。

AI活用を戦略に落とす前に、まずは導入・定着から始めませんか?

デボノはアカウント開設・初期設定など「そもそものAI導入」から社内定着まで伴走支援。マーケティング活用など一歩進んだご相談にも対応します。

運営会社:株式会社デボノ

目次