夜11時、メッセンジャーに一行が届きます。「ご依頼の売上データの整理、完了しました。」ほっと胸をなで下ろします。翌朝、その表を開いて会議資料に貼り付けます。ところが、合計がどこかおかしい。先月の数字がそっくり抜け落ちています。「完了しました」は嘘ではありませんでした。AIは確かに作業を終えていたのです。ただ、終えたことと正しく終えたことは、別の話でした。
AIプロジェクトマネージャー(人の依頼を受けて分類し、実行したうえで結果を報告する自動化された担当者、以下AI PM)をチームに迎え入れると、まずこの壁にぶつかります。この担当者は報告が上手です。言葉づかいは丁寧で、「完了」という単語をためらいなく使います。ところが人間の担当者が「終わりました」と言うときは、たいてい自分の目で結果を一度見た後です。AIはその確認のステップを飛ばしても、同じように言えてしまいます。だからAI PMの報告で信じるべきなのは、「完了しました」という言葉ではなく、その横に記された確認の根拠と、まだ終わっていない項目なのです。
仕事には二種類の終わりがあります。ひとつは動作を終えたこと、もうひとつは結果が正しいことです。この二つを区別できないと、AI PMの報告はすべて信じるしかない領域に流れ込んでしまいます。
「取引先10社に案内メールを送りました」という報告を見てみましょう。これは動作の完了です。送信ボタンを押した、という意味です。けれど本当に重要なのは、10社がそのメールを受け取れる状態だったかどうかです。宛先のひとつが打ち間違いだったり、1社が受信拒否だったりすれば、送信は「できた」が到達は「できなかった」ことになります。人間なら、返送通知を見て「ああ、2社には届いてないな」とすぐ気づきます。AIは、返送ボックスを確認するよう指示しなければ、送信API(メールサーバーに「この宛先へ送れ」と渡す自動の通り道)が返してきた「受け付けた」という応答だけを見て、10社すべてを完了として記録します。
この隔たりは、技術的な作業でいっそう鮮明になります。ウェブページをひとつ直すと、サーバーは「200」という信号を返します。正常な応答だ、という意味です。多くの自動化がここで止まります。200を受け取ったから完了。ところが200は「リクエストがサーバーに届き、サーバーが何かを返した」という意味にすぎず、その画面が人の目にきちんと見えているかどうかは教えてくれません。文字が化けているかもしれないし、ボタンが画面の外にはみ出しているかもしれません。数字は青信号なのに、実際の画面はめちゃくちゃ、というのは現場ではよくあることです。
信頼できるAI PMとそうでないAI PMの、最初の違いがここで分かれます。前者は、メールを送ったなら返送の有無まで、ページを直したなら実際の画面を一枚撮って目で確認したうえで、はじめて「完了」と書きます。後者は、動作が終わった瞬間に完了と書きます。見た目はどちらも「完了しました」ですが、その後ろに付く根拠がまるで違うのです。
よい報告は長い必要がありません。その代わり、三つのかたまりが入っていなければなりません。何をやったか、それが正しいとどうやって確認したか、まだ終わっていないものは何か。
第一に、何をやったか。 ほとんどの報告が得意とする部分です。「Aファイルの価格表を第2四半期基準で更新しました」といった具合です。問題は、ここで終わってしまう報告があまりに多いことです。
第二に、どうやって確認したか。 これが核心であり、よい報告と悪い報告がここで分かれます。「更新後、表の合計が営業チームの原本の総額と一致するか突き合わせたところ、1万2千ウォンの差が出たので、四捨五入のルールを合わせて0ウォンにしました。」こう確認の方法が書かれていれば、人は結果を一から見直す必要なく、その方法で十分だったかどうかだけを判断すればよくなります。
ただし、確認の方法が書かれているというだけでは証拠になりません。それはどこまで信じるかを見積もる出発点であって、それ自体が結果の正しさを保証するわけではありません。だからこそ確認の根拠は、言葉だけで書くのではなく、人が自分で開いてたどり直せる場所まで指し示さなければなりません。
この項目が危うくなる理由は、AIが最もよく犯す嘘が、悪意ではなく自信だからです。AIは知らないことも知っているかのように滑らかに語る性質があるので、「自分が直接確認した事実」と「たぶんそうだろうという推測」が同じ平叙文のなかで混ざり合います。「決済モジュールを修正したので、これでカード決済が正常に動きます」を見てみましょう。前半は事実である可能性が高い。コードを直したのはAIが今しがたやった行動だからです。後半は推測かもしれません。実際にカードを切って承認されるのを見たのなら事実ですが、コードの形からいって動きそうだからそう書いたのなら推測です。ところが文は、その二つを同じ断定の形でひとくくりにしてしまっています。
よく訓練されたAI PMは、この二つを言葉づかいで分けておきます。「決済モジュールを修正しました(確認済み)。テスト決済はまだ回せていないので、実際の承認可否は検証前です(未確認)。」見た目はすっきりしません。けれど、人が「では、テスト決済を一度回してみて」と次の指示を出せるようにしてくれます。すべてを断定してしまった報告は、次の行動を塞ぎます。全部終わったと言われて、あと何を頼めるでしょう。だから断定的な文を見たら、「それ、自分で見た?」と一度尋ねればいいのです。答えが「何を、どの値で見た」のように具体的なら、自分でたどり直せる事実に近く、「コード上はそうです」と返ってくれば、推測だったという意味です。推測そのものが悪いわけではありません。推測を事実として包んでしまうのが悪いのです。
ここに、もう一枚だけ気をつけるべきところがあります。AIが自分のやったことを自分で検証する場合です。数字を読み違えて作業していたなら、検証のときも同じ間違った基準で見てしまいがちです。だから重要な確認ほど、作業した側とは別の目で行うのが安全です。これをクロスチェックと呼びます。たとえばAIが売上データを整理したなら、検証は同じ売上データをもう一度足させるのではなく、在庫データの出庫量といった別の出どころと突き合わせる、という具合です。ただし売上額と出庫量は単位からして違いますし、販売数量にそろえて見ても、売上計上のタイミングや返品、無償出庫のせいで正常に差が出ます。ですから「合わなければどちらかが間違っている」とすぐ断定するのではなく、まず比較の基準をそろえ、こうした正常な差を取り除いたうえで、それでも残る不一致をシグナルとして扱うべきです。
第三に、まだ終わっていないものは何か。 完璧に終わる仕事はまれです。ところが多くのAIは、基本的に人を喜ばせる方へ傾いているので、尋ねなければよい知らせばかりが上がってきます。「できるにはできたんですが、一か所ひっかかります」といった報告は、そう上げるよう要求しておかなければ、なかなか出てきません。だから信頼できる報告は、終わっていないものを完了報告のいちばん最後に別立てで書きます。「完了」という大きな文字の下に、小さな文字で埋め込んだりはしません。
やり方は、報告の形式を決めておくことです。すべての完了報告を「完了」欄と「残件」欄に分けさせ、残件がなければ「残件:なし」と明記させます。空欄を許さないのが核心です。残件欄を空にできないようにすれば、AIは「本当にないのか」ともう一度自分の作業を見直すことになります。もちろん、もう一度見直したからといって漏れがない保証にはなりません。それでも、空欄で素通りするよりはましです。そして残件には、四つを付けさせます。何が終わっていないのか、なぜ終わっていないのか、それがどんな影響を与えるのか、解くには何が必要なのか。「前年比の増減率は入れられませんでした」で終わると、人がまた問い詰めなければなりません。「前年比の増減率は入れられませんでした(なぜ:昨年のデータがシステムにない/影響:推移グラフがひとつ空に見える/必要:財務チームの2024年の元帳ファイルひとつ)」まで来てはじめて、人は財務チームにファイルをひとつ頼めば終わりだとわかり、すぐ動けます。残件を隠した完了報告は時限爆弾です。いまはすっきり見えても、終わっていない部分は消えずに残り、たいてい顧客の前で爆発します。
言葉より見本が早い。顧客が納期を2週間前倒ししてほしいと依頼してきた状況を受けたAI PMが、三つのかたまりをそろえて上げると、報告はこんな形になります。
[納期2週間短縮の依頼 — 中間報告] - 実施内容:顧客の納期2週間短縮の依頼を受領、社内の生産スケジュールを検討 - 確認できた事実:現在の生産スケジュールに2週間の余裕あり(生産スケジュール表と突き合わせ) - 条件つきの判断:資材が間に合って入ってくれば2週間の前倒しは可能 — ただし資材の入荷自体はまだ未確認なので条件つき - 根拠:社内の生産スケジュール表 第2四半期シート(開いてたどり直して確認可能) - 残件:① 資材入荷を2週間前倒しできるか — 供給元への確認が必要(AIに連絡の権限なし)② 同じ週のB社向け納品案件と人員が衝突する可能性
この報告が、ありふれた「完了」報告と違う点は二つです。第一に、事実と推測が別の欄に入っています。「2週間の余裕がある」はスケジュール表で直接確認した事実であり、「2週間の前倒しが可能」は資材が間に合うという前提の上に立つ条件つきの推測です。第二に、この報告は「完了」という単語を最後まで使いません。まだすべての条件がそろっていないからです。
この見本がどうやって出てきたのか、依頼が入った瞬間からたどってみます。私たちONTLEでは、AI PMをこう設計してこの問題を解きます。小さな会社なので専任のPMがおらず、代表が別の仕事を見ている間に、納期を2週間前倒ししてほしいという依頼が入った状況です。
悪い処理はこう終わります。依頼を受け、社内スケジュール表の納期の日付を2週間前倒しに直したうえで、「納期を前倒しして反映、完了しました」と報告します。動作は完了です。日付は確かに変わりました。けれどこれは、カレンダーに書かれた数字を変えただけで、その日付に物が実際に出せるのかは何も確認していません。2週間後の納品が穴を空け、顧客は「できると思っていた」と怒ります。
そこでONTLEのAI PMは、五つのステップを踏むように設計しました。
第一に、依頼の本当の意図を読む。 これは「日付を直してほしい」ではなく「2週間前倒ししてよいか判断してほしい」という依頼です。顧客が望んでいるのは日付の数字ではなく、2週間早く物を受け取ることです。
第二に、判断に必要な事実を集める。 生産スケジュールに2週間の余裕があるか、資材の入荷日はいつか、他の納品と重なるか。ここでAICにはできない仕事が出てきます。「資材の入荷を2週間前倒しできるか」は、供給元に尋ねなければわからない外部の事実です。AIはこれをでっち上げてはいけません。わからないものはわからないと示し、確認が必要な項目として切り分けます。
第三に、判断と未確認を分けて報告する。 その結果が、先ほどの見本です。確認できた事実と条件つきの判断を別の欄に置き、供給元への確認とB社との人員衝突を残件として切り出して書きます。この報告は「完了」を使わない代わりに、代表が決めるべき地点を一目で見せます。
第四に、ここで止まって承認を受ける。 顧客に「2週間前倒しします」と答えるのは、外へ出ていく約束です。取り消しにくく、間違えば信頼が壊れます。だからこのステップは人の手に委ねるようにしました。「顧客にこう返信しようと思います:(下書き)。供給元の確認前なので、『検討のうえ明日、確定のご返信を差し上げます』で出すのが安全に見えます。送ってよいですか?」人が承認するまで、外への送信は保留されます。
第五に、承認後の締めくくりまで追う。 代表が下書きを承認すると、AI PMは顧客にまず「検討のうえ明日、確定のご返信を」と送ります。そのあと供給元の返事を受けて資材の入荷が2週間前倒しになるか確認し、B社と重なる人員の問題は代表がスケジュールを調整して解きます。すべての条件がそろってはじめて確定の返信を送り、そのときようやく、初めて「完了」と書きます。それも「納期2週間短縮、顧客へ確定返信を送信済み、資材・人員ともに確保を確認済み」という根拠を添えて。
この一件でAI PMは、日付欄をひとつ直すよりはるかに多くの仕事をしました。信頼できるAI PMほど、完了という単語を惜しみます。根拠がすべてそろう前には使わないからです。
報告を読むたびに全部を検証し直すことはできません。それでは人が二倍働くはめになります。その代わり、先ほどの見本を基準に五つの問いだけ身につければ、危うい報告だけを選んで集中できます。
この五つが「無条件に正しい」という保証ではありません。とくに確認をAIひとりでやったのなら、クロスチェックがもう一枚必要です。それでも、全数検査の代わりに危険な地点だけを拾い出すには十分です。ひとつでもひっかかれば、その部分だけをピンポイントで問い返せばいいのです。
信じられます。ただし、信じる対象を正しく据え直す必要があります。「完了しました」という言葉ではなく、その言葉の後ろに付く根拠を信じるのです。根拠を要求する運用の習慣さえ根づけば、AI PMの報告は、人間の担当者の報告よりむしろ追いやすくなります。何をどう確認したかが文字で残るからです。人は「なんとなく見たけど大丈夫でしたよ」で済ませられますが、形式を備えたAI PMは、その「なんとなく」を文字で書き出さなければなりません。
だからこの話は、結局のところAIの性能の問題ではありません。核心は、「信頼しつつ検証する」というシステムを設計する、管理者の力にあります。報告にどの欄を強制するか、どこで止めて承認を受けさせるか、確認は誰の目で行うか。これは道具をひとつ迎え入れる問題ではなく、組織が「完了」という言葉を扱う仕方そのものを変える問題です。
だからONTLEは、「完了」という単語の重みを知るAI PMを目指します。小さな会社の代表の反復業務を代わりに回す道具にとどまらず、夜のあいだに入ってきた依頼を分類して整理しつつ、その結果を根拠までたどり直せるように残す協業パートナーになること。同じAIを使っても結果が分かれる地点は、結局、完了の横に何が書かれているかを見る、その読む目にあるのです。
時間ではなく出来事を基準にするほうがよいです。1時間ごとに報告させると、言うことがないときにも報告が上がってきて、肝心の急ぎの瞬間には次の周期まで埋もれてしまいます。その代わり、作業ひとつが終わったとき、詰まってそれ以上進めないとき、外へ何かが出ていく直前 — この三つの瞬間に必ず報告させるよう縛っておくほうが、現場にはよく合います。長い作業は、段階が切り替わる地点ごとに進捗を一度ずつ残します。
長さより構造が問題である場合が多いです。結論(完了/保留)をいちばん上の一行に置き、その下に確認の方法と残件を短く付ける、という形式に固定すれば、忙しいときはいちばん上の行だけ読み、必要なときだけ下へ降りればよくなります。読まれない報告は、たいてい結論が途中に埋もれている報告です。