結論から言うと、今回のずれの原因は、AIの賢さではなく、報告の読み元になっている記録が更新されていなかったことでした。起きたのは、6月上旬に完了して正式な保管場所への統合まで済んでいた仕事を、7月末のセッション立ち上げ時の自動要約が「未完了」と報告していた、という出来事です。ずれは51日、7週間あまり。なぜそんなことが起きたのか、どこを疑えばいいのかを、この記事でお伝えします。

なお、これは社内の作業管理で起きた出来事で、お客様への報告や納品物が間違っていた話ではありません。ただ、同じ形の見落としは、AIに報告を任せている仕組みなら起こりえます。

何が起きたか。「未完了」と報告された仕事は、7週間前に終わっていた

HaruIroAIには、AIとの作業セッションを立ち上げると、最初に「いまどのタスクの途中で、何が残っているか」をAIが自動で要約して見せる仕組みがあります。毎回同じ形式で現在地を教えてくれる、便利な仕組みです。

7月末のある日、この要約が、ある作業を「未完了」と報告しました。公開作業の安全装置に関する社内標準づくりで、やることが5項目残っている、という表示です。ところが実物を確かめると、この作業は6月上旬に検証まで終わり、成果物は会社の正式な保管場所に統合済みでした。そこで作られた標準文書は、プロジェクトの必読ドキュメント一覧にも載っています。つまり要約が見せていたのは、51日前——7週間あまり前の「現在地」だったのです。

原因はAIの賢さではなく、1枚のファイルだった

調べてみると、仕組み自体は何も壊れていませんでした。この自動要約は、作業計画ファイルの置き場——「作業中」の棚にあたるフォルダ——を読んで、報告を作ります。仕事が終わったら、計画ファイルに完了の印を付けて棚から下ろす。それが前提の設計です。

今回抜けていたのは、その最後のひと手間でした。仕事そのものは終わったのに、計画ファイルが「作業中」の棚に残ったままになっていたのです。

もう1つ、細かいけれど大事な発見がありました。その計画ファイルの中には、文章としては「検証まで完了した」という記録がきちんと書いてあったのです。ところが、進捗を示すチェック欄は、すべて未チェックのままでした。人間がファイルを開いて文章を読めば「終わっている」と分かります。しかし自動要約は、機械的に読み取れるチェック欄だけを見ます。同じ1枚のファイルの中に、「完了」と読める場所と「未完了」と読まれる場所が同居していて、機械は後者だけを読んでいました。

なぜ7週間も気づかなかったのか

理由は3つありそうです。まず、報告が毎回同じ形式で、自信ありげに出てくること。体裁が整っているものは、正しく見えます。次に、「自動で出てくるものは最新だ」という思い込みです。自動化されているのは「表示」であって、「記録の更新」までは自動ではなかったのに、そこを区別せずに受け取っていました。

そして一番大きいのは、実害がすぐには出ないことです。報告が古くても、その日の作業は別の指示で進むので、目の前の仕事は回ってしまいます。誰も困らないから、誰も疑わない。ずれが見つかったのは、立ち上げ時の報告と、保管場所にある実物とを突き合わせたときでした。この仕組みは同じファイルを読んで表示を作るので、ファイルが直らない限り、いつ立ち上げても同じ古い現在地が出続けることになります。

直し方。「完了」に、記録を閉じるまでを含める

この出来事を受けて、HaruIroAIで整理した対策は3つです。

1つ目は、仕事の「完了」の定義に、管理記録を更新して棚から下ろすまでを含めることです。成果物ができて、確認が終わった時点では、まだ完了ではありません。計画ファイルに完了の印を付け、「作業中」の棚から片づけて、そこで完了です。料理にたとえるなら、皿を洗って棚に戻すまでが料理です。

2つ目は、自動報告が「どの記録を読んで作られているか」を一度確認しておくことです。読み元さえ分かっていれば、報告がおかしいと感じたとき、どこを見ればいいかがすぐ分かります。逆に読み元が古ければ、報告はどれだけ体裁が整っていても古いままです。

3つ目は、月に一度でもいいので、報告と実物を突き合わせることです。報告の上で「未完了」となっているものは、実物ではどうなっているか。「完了」とされているものの成果物は、本当にあるか。今回のずれは7週間続きましたが、月に一度の突き合わせがあれば、遅くとも1か月ほどで見つかっていたはずです。

記録は、読ませるだけでなく、閉じるまで

同じ質問を何度もしてくるAIには、答えずに「どこを見て」と返すという記事では、AIが手元の記録を読まずに人に聞いた話を書きました。今回はその逆で、AIは記録をきちんと読んでいたのに、記録の側が更新されていなかった話です。並べてみると、教訓は1つにつながります。記録は、AIに読ませる手順と、更新し続ける手順の両方がそろって、初めて役に立ちます。

正しそうな表示と実態がずれるという出来事そのものは、サーバーは直ってるのに、まだ古いまま見える――AIが「確認しました」と言った後に起きたことでも書きました。あのときの原因は通信の仕組み(キャッシュ)、今回は運用の抜けと、中身は違いますが、「表示の読み元を疑う」という確かめ方は共通です。

これはHaruIroAIで起きた1件の実例で、AIの自動報告全般が信用できないという話ではありません。ただ、AIからの報告を毎日受け取っているなら、「この報告は、どの記録を読んで作られているのか」を一度だけ確かめておく価値はあるはずです。

この記事を書いた人

相葉 葵 / HaruIroAI 広報

HaruIroAIの広報担当。専門用語をできるだけ使わず、WebやAI活用の実践で分かったことを、小規模事業者向けに整理します。記事はHaruIroAIの検証記録と一次情報をもとに作成し、公開前に人が確認しています。

この記事の作り方

この記事は、構成・一次記録の照合・文章化にAIを使用し、HaruIroAIの編集ルールと社内の一次記録に基づいて作成しています。社内の管理ツールの名称や作業の詳細は、本題と無関係なため省略しています。内容は公開前に人が最終確認しています。