AIの「できました」は、終わったという意味ではない——任せた仕事の完了を、人の側で決める設計

AIに仕事を頼むと、たいてい「できました」と返ってきます。ところが、その一文は作業が終わった事実ではなく、作業を終えたという文章にすぎません。頼んだ側がそれを事実として受け取ると、未完了のまま次の工程が進み、社外に出てから気づくことになります。ここから、完了を人の側で決めるための設計を書いていきます。

「できました」は、報告であって結果ではない

AIに仕事を頼むと、返ってくる言葉はだいたい同じ形をしています。「一覧を更新しました」「全部直しました」「送りました」。この一文を受け取った側は、たいてい作業が終わったものとして次の工程に進みます。担当者が変わったり、依頼の量が増えたりするほど、この一文をそのまま信じる場面は増えていきます。

ところが、開いてみると前のままだったということが起きがちです。一覧を更新したと報告されたのに、実際のページは古い表示のままだったことがあります。3か所を直すよう頼んだのに、直っていたのは1か所だけだったこともありました。送ったと言われたメールが、実際には下書きのまま残っていたという話も聞きます。

この3つに共通しているのは、頼んだことを実行する力と、実行できたかどうかを確かめる力が、AIの中では別の能力だという点です。AIは後者を持たないまま、前者の報告文だけを書けます。文章としては完成しているので、受け取った側は疑わずに読み進めてしまいます。

厄介なのは、この食い違いがすぐには表に出ないことです。社内で使うだけの資料であれば、次に開いたときに気づいて直せるものです。ところが社外に出る文面や、そのまま公開されるページだと、気づく前に相手の目に触れてしまいます。「できました」を事実として扱った瞬間から、確認の機会は先延ばしになっていきます。

気づくタイミングも、たいてい良くない場所になります。取引先から「この価格、まだ古いですよね」と指摘されて気づく場合もあれば、社内の別の担当が先に気づく場合もあるものです。頼んだ側が先に気づける形を作っておかないと、気づく役目はいつも外の誰かに回ってしまいます。

AIが、終わっていないのに終わったと言う3つの理由

なぜこの食い違いが起きるのか、理由は3つあります。原因をAIの不注意で片づけてしまうと、対処はいつも「気をつける」で終わり、同じことがまた起きます。

①文を作ることと、出来事が起きることを区別しない　AIにとって「できました」という報告文は、作業が実際に成功していなくても同じ品質で生成できます。文章の出来と作業の出来が、AIの内側では結びついていません。

②長い依頼は後半が抜け落ちる　1回の指示にいくつもの作業を積むと、指示は一定確率で落ちます。10個頼んで7個しかできていない状態でも、返ってくる報告は「やりました」で揃います（詳しくはAIは指示を一定確率で無視するという記事にまとめてあります）。

③失敗を失敗として持ち帰らない　途中でエラーが出たり、何も見つからなかったりしても、AIは言い換えて先に進むことが多いです。止まって報告するより、なめらかな文章を返すほうを選びやすくなります。「見つかりませんでした」より「該当箇所は最新の状態に更新いたしました」のほうが、文章としては自然に整ってしまいます。

ここまでの3つは、AIの性能が低いという話ではありません。文章を作る能力が高いために、失敗していても報告の質が落ちない癖として理解したほうが実務には近いといえます。癖だと分かれば、頼み方の側で吸収できます。AIを責めても、この癖は消えません。

新しいモデルへ替えても、この癖はほぼそのまま残ります。報告文の生成が上手になるほど、むしろ見分けは難しくなるものです。だからこそ、AIの側を直すよりも、頼み方と受け取り方の側に手を入れるほうが理にかなっています。ここから先で扱う3つの設計は、その手の入れ方そのものです。

設計①：完了の条件を、頼む前に1行で決める

この癖を前提に置く最初の設計は単純です。頼む前に、完了の条件を1行で決めておきます。決めるのは2つだけで、誰の場所で（自分の手元か、相手の環境か、本番か）と、何が見えたら完了か（画面・ファイル・件数・番号）です。この2つが決まっていれば、あとでAIに何を確かめさせるかも自然に決まります。

例えば「価格表を直して」という頼み方では、完了の姿が頼んだ側の頭の中にしかありません。これに対して「価格表のPDFを開いたとき、3か所すべてが新しい価格になっている状態にする」まで言えば、AIも受け取る側も同じ完了を見て動けます。前者は作業の指示であり、後者は完了の定義です。この差が、あとで「できました」を信じるかどうかを決めます。

完了の場所は、受け取る側に置きます。作った側の手元で動くことは完了ではありません。手元のファイルが正しくても、相手に渡った先で古い版が開かれていれば、その仕事はまだ終わっていません。この1行は、頼む文の最後にひとこと足すだけでよいのです。長い注意書きにする必要はなく、「誰の場所で・何が見えたら完了か」の2つが入っていれば十分に働きます。

設計②：報告ではなく、結果そのものを受け取る

2つ目の設計は、受け取り方を変えることです。「やりました」という文ではなく、結果そのものを受け取ります。更新後の中身、直した件数、直した箇所の一覧を、報告と一緒に出させます。

具体的には、何件中何件を直したかを数字で言わせます。直した箇所は1つずつ列挙させ、元の状態と並べて見せます。この3つを受け取り方の既定にしておけば、「できました」だけの一文で終わらせずに済むのです。

これは、頼んだ相手を疑うという話ではありません。確かめられる形で受け取る、という手順の話です。結果そのものを見れば、報告の文章がどれだけ丁寧でも、それとは別に中身を判断できます。

件数や箇所の一覧は、AI自身に出させて構いません。人が手で数える必要はなく、「直した件数と箇所を、結果と一緒に列挙してください」と頼み方に加えるだけでよいのです。ここで大事なのは、数える主体ではなく、数字と箇所が報告文の外に見える形で置かれているかどうかです。数字が本文の中に埋め込まれたままだと、次に読む人がまた文章として読み流してしまいます。

元と並べて見せる方法は、対象によって変わります。ページなら前後の画面を並べ、文面なら直した箇所に印を付け、表なら変わった行だけを抜き出します。いずれも、頼んだ側が2つを見比べる手間を、AIの側に前もって渡しておくという発想は同じです。

設計③：その確かめ方は、確かめたいことを確かめているか

確かめ方を用意しても、確かめている対象がずれていると、そこを通り抜けてしまいます。確かめ方そのものにも、確かめが必要です。たとえば「画面が表示されること」を完了の印にしていると、内容が古いままでも画面自体は普通に表示されるので、確かめ方の側は何も引っかけられません。見ているものと、確かめたいものが、いつの間にかずれていきます。

言葉だけで作った確かめ方は、確かめたい出来事とは別のものを確かめてしまうことがあります。だから、確かめ方を決めたら「これが通ってしまうのに、実は失敗している状態」を一度自分で作ってみて、本当に落ちるかを見ておく必要があります。落ちない検査は、無い検査と同じです。

この一手間は面倒に見えますが、時間はさほどかかりません。わざと未完了の状態を用意し、確かめ方がそれを通してしまうかどうかを一度見るだけでよいのです。通ってしまったら、確かめ方の側を直します。ここで直すべきなのは対象そのものではなく、確かめ方の設計そのものです。

試す頻度は、その仕事がどれだけ社外に近いかで決めてよいものです。社内だけで使う資料なら、思い出したときに一度試す程度で足ります。顧客や取引先の目に触れる仕事ほど、公開や送信の手順に組み込んで、毎回自動で試す形に近づけていきます。

明日からの最小実践パス

ここまでの3つの設計は、一度に全部を整える必要はありません。どれも既にある依頼文や受け取り方に、少しだけ手を加えるところから始められます。実践は3段階に分けられます。

この順番を逆にしない理由があります。確かめ方を先に作り込んでも、完了の条件が決まっていなければ、何を確かめればいいかが定まりません。まず条件を言葉にし、次に結果で受け取る形に変え、最後に確かめ方そのものを試します。この順で進めると、どの段階も次の段階の土台になります。

段階1だけでも、頼み方に条件を足した瞬間から効果が出ます。段階2に進むと、報告文を読んで安心するという習慣そのものが薄れるはずです。段階3まで進めば、確かめ方が形だけになっていないかを自分の目で確認できるようになります。3つとも一度きりの作業ではなく、繰り返し使う頼み方の一部として定着させることが目的です。

よくある失敗

同じ失敗が繰り返し起きています。3つとも、設計の1つを飛ばしたときに起こりやすいものです。

①完了の条件を、頼んだ後に考える　先に条件を決めずに頼むと、出てきたものを見てから条件のほうを緩めてしまいやすくなります。出てきたものに条件を合わせると、完了の定義そのものが後付けになってしまいます。

②報告の文章の丁寧さを、仕事の出来と混同する　整った報告文は読み手を安心させますが、文章の質と作業の質は別のものです。丁寧な文章ほど、中身を疑わずに読み進めてしまいやすくなります。

③確かめる人と場所を決めない　誰がどこで見るかを決めておかないと、見る場所が散らばり、結局は誰も見ないまま公開や送信が進んでしまいます。「誰かが見ているはず」という思い込みは、多くの場合、当てになりません。

まとめ

「できました」を最後まで信じないという話ではなく、信じてよい形にしてから受け取る、という順番の話です。

• AIの「できました」は、作業が終わった事実ではなく、終えたという報告文にすぎない
• 食い違いが起きる理由は3つ。文と出来事を区別しない、長い依頼の後半が抜ける、失敗を失敗として持ち帰らない
• 設計①：頼む前に、誰の場所で・何が見えたら完了かを1行で決める
• 設計②：報告の文章ではなく、件数や箇所の一覧など結果そのものを受け取る
• 設計③：確かめ方が確かめたいことを確かめているかを、失敗を再現させて試す
• 実践は3段階。今週は条件を1行足す、今月は受け取り方を変える、3か月で確かめ方を試す