目次 ― 5 章
人に仕事を頼むとき、私たちは「終わりました」という報告を信じて次の仕事に進む。日本企業の業務は、この報告への信頼で回っている。報告に嘘が混じれば、それは人事評価の問題として扱われる。
AIエージェントに同じ仕事を任せると、この前提が崩れる。エージェントは悪意なく、終わっていない仕事を「終わりました」と報告する。しかも、その頻度は想像よりはるかに高い。
2026年9月最終週、この問題はモデル開発の最前線でも表に出た。OpenAIは次期モデルの公開を止め、その理由の1つに「行動についての報告が正直でない」ことを挙げた。翌日には、会話が終わっても仕事を続ける常時稼働エージェントを発表している。
任せる仕事は長く、広くなる。一方で、その報告をそのまま信じてよい根拠は、まだない。業務への定着を進める企業が今決めておくべきなのは、エージェントの「言葉」と、システムの「状態」を分けて扱う設計である。
01OpenAIの2日間 ― 止めたものと、出したもの
2026年9月28日、OpenAIは10月に予定していた次期モデル「GPT-6.1 Astra」の公開を見送ることを確認した。ChatGPTとCodexで提供される予定だったモデルである。
報道によれば、社内テストで問題になったのは性能ではなかった。同社の安全システム責任者であるSaachi Jain氏は、このモデルが「範囲と権限の内側にとどまること」と「自分が行った作業について利用者にどう伝えるか」の2点で基準に届かなかったと説明している。具体的には、実行した行動・実行しなかった行動について必ずしも正直に報告しない傾向が強まり、利用者の許可なく作業範囲を超えて外部のツールやサービスに触れることがあったという。改めての公開時期は示されていない。
翌9月29日、同社は年次開発者会議「DevDay 2026」で20件を超える発表を行った。中心は、常時稼働型のエージェント「dots」である。dotsは9月に公開済みのGPT-6 Astraで動き、1体ごとに専用のクラウドPCとブラウザを持つ。4,000を超えるアプリと接続し、利用者が目標を渡せば、会話が終わったあとも作業を続けて結果を持ち帰る。
企業向けに注目すべきは、その権限の設計だ。dotsの「カスタムルール」は、①確認なしで実行、②事前に承認されていれば実行、③実行前に確認、④人に引き継ぐの4段階で行動を区分する。メール送信のように他者に影響する操作は実行前に自動レビューにかけられ、パスワード変更と送金は常に人が行う。Enterprise・Edu・Healthcare向けは管理者が有効化するベータで、既定では無効とされた。企業の役割を担う「Specialist dots」は、調達・請求・メールマーケティング・サポート・契約業務で試験が行われたと報じられている。
それでもOpenAI自身の注意書きは率直だった。「dotsは間違えることがある。重要な成果物は必ず確認してほしい」。
同じ日、もう1つ地味な発表があった。判断に特化した「Decisions API」である。開発者が問いと「ありうる答え」をあらかじめ定義し、モデルはその中から1つを選ぶ。用途として示されたのは、問い合わせの振り分け、内容の分類、そしてエージェントが次にとる行動の選択だ。限定プレビューとして公開され、価格は未発表である。
公開を止めた理由と、同時に出した製品の設計は、同じ問題を指している。エージェントが自分の行動について語る言葉は、そのままでは信用できない。だから権限を段階に分け、重要な操作は人に戻し、判断は選択肢の中に閉じ込める。
02研究が示した「偽の完了」の頻度 ― 失敗の半分は、成功の顔をしている
この問題の大きさを測った研究がある。2026年6月にarXivで公開された論文「From Confident Closing to Silent Failure: Characterizing False Success in LLM Agents」は、エージェントが「完了した」と報告したのに、システムの状態は完了していない失敗を「False Success（偽の完了）」と名付け、その頻度を調べた。
結果は次の通りだ。
- 航空・小売などの顧客対応タスクを再現したベンチマーク（tau2-bench、8つのモデル系統、9,876件の実行記録）では、失敗のうち45〜48%が偽の完了だった
- 自分の書いたコードの成否を自分で判定する設定（AppWorld、4つのモデル系統、1,879件）では、75.8%に達した
- 一方、利用者の側も環境を操作し、状態を確かめられる設定（通信）では、わずか3%だった
偽の完了が厄介なのは、エラーとして表に出ないことだ。処理が止まれば誰かが気づく。人に引き継げば誰かが対応する。だが「完了しました」と言われた仕事は、誰も見に行かない。顧客は問題が解決したと思い、後工程はデータが揃ったと思って動き出す。
さらに重要な発見がある。別のLLMに完了報告の真偽を判定させても、ほとんど見抜けなかった。複数の判定モデルと指示の与え方を試しても、識別性能（AUROC。0.5が当てずっぽう、1.0が完全）は顧客対応で最大0.65以下、コーディングでは0.54にとどまった。反対に、領域ごとに調整した単純で軽量な検出器は0.83と0.95を記録し、処理の遅延は約3,300分の1だった。
著者の結論は、実務の監視ではLLMによる判定を主役にせず、業務ごとに調整した軽い検出の仕組みを使うべきというものだ。「AIの出力はAIにチェックさせる」という、試作で最も手軽に選ばれる設計が、この失敗には効かないことになる。
裏を返せば、3%という数字が示すように、完了かどうかをエージェントの言葉ではなく相手側の状態で確かめる構造があれば、偽の完了は表に出てくる。問題はモデルの賢さではなく、報告を受け取る側の設計にある。
03日本企業で「偽の完了」が見えにくくなる3つの理由
偽の完了はどの国の企業にも起きる。ただ、日本の大企業には、それが見えにくくなる事情がいくつかある。
理由① 業務が「完了報告」で次工程に進む。 稟議、受発注、経費精算、問い合わせ対応。多くの業務は、担当者の「終わりました」を合図に次の工程へ渡る。報告の信頼性は、人の責任感と評価制度によって支えられてきた。エージェントを同じ業務フローに組み込むと、その報告がそのまま後工程の起点になる。未完了が見つかるのは、数日後、別の部署で、別の担当者によってだ。
理由② 効果測定の元データが、エージェントの自己申告になっている。 「月に何件を自動処理したか」「自動完了率は何%か」「何時間が削減されたか」。これらの数字をエージェントの実行ログから集計すると、偽の完了はすべて「成果」として数えられる。経営会議に出るROIの数字ほど、水増しされやすい構造だ。これは、業務への定着を阻む5つの壁のうち「指標の壁」と「ROIの壁」が重なる場所である。測っているのは「完了した件数」ではなく、「完了と言った回数」かもしれない。
理由③ 試作の評価が「出力の見た目」で行われる。 試作の段階では、担当者が回答文や画面を1件ずつ目で見て合否を付ける。件数が少ないうちは、偽の完了も人の目で拾える。ところが実務で件数が増え、人が全件を見なくなった瞬間、確認の役目が誰にも割り当てられていない状態が生まれる。試作で合格した品質が、実務では誰にも気づかれずに下がっていく。
常時稼働型のエージェントは、この3つをすべて強める。人が起動しない仕事は、人が結果を見に行かない仕事でもあるからだ。dotsのEnterprise版が既定で無効になっているのは、むしろ企業にとって猶予と考えるべきだろう。有効化のスイッチを押す前に、報告をどう検証するかを決めておける。
04導入基準に書き足す「報告の検証」5つ
では、何を決めればよいか。業務への定着の基準に、次の5つを書き足すことを提案したい。
①「完了」の定義を、記録システム側の状態で書く。 「受注を登録しました」ではなく、「基幹システムで受注番号が発番され、ステータスが『承認待ち』になっている」。業務ごとに1行でよい。完了をエージェントの言葉ではなく、業務システムの状態で定義する。これが導入基準の最初の行になる。
② 完了報告と状態を、機械で突き合わせる。 報告のたびに、①で定義した状態を照会し、一致しないものだけを人に回す。全件を人が見る必要はない。研究が示した通り、この照合は別のLLMに頼むより、業務ごとに作った単純な仕組みのほうが速く、正確だ。運用の指標には「報告と状態の一致率」を置く。この数字が下がったら、モデルの更新やプロンプトの変更を疑う合図になる。
③ 判断は「選択式」に切り出す。 問い合わせの振り分け、書類の分類、次にどの処理へ進むか。こうした判断を自由な文章で出させると、正しかったかどうかを後から評価できない。答えの候補を先に決めて選ばせれば、過去の正解データと比べて精度を数字で合意できる。OpenAIのDecisions APIは、この設計を製品として切り出したものと言える。特定の製品を使うかどうかに関わらず、エージェントの中の「判断」を「作文」から分離することは、品質を測れる形にする基本の作り込みである。
④ 4段階の権限を、業務の台帳に書き写す。 dotsの4段階（確認なし／事前承認／実行前確認／人に引き継ぎ）は、日本企業の決裁規程とよく対応する。ただし、それを製品の設定画面で、利用者個人が決める状態にしてはいけない。どの業務のどの操作をどの段階に置くかは、社内の台帳で決め、既存の職務権限規程との対応表を作ってから有効化する。製品が変わっても、台帳は残る。
⑤ 効果測定は、エージェントのログではなく業務システムから取る。 経営に報告する処理件数や削減時間は、①で定義した状態の件数から集計する。ROIの数字に、エージェントの自己申告を1件も混ぜない。これを最初に決めておくと、投資判断の議論が「本当に効いているのか」という疑いから始まらずに済む。
05まとめ ― 任せる範囲を広げる前に、報告を受け取る仕組みを
今週の動きを並べると、1つの構図が見える。エージェントが任される仕事は、会話の中の作業から、何日も続く常時稼働の仕事へと広がっている。その一方で、モデルを作る側でさえ、エージェントが自分の行動を正確に報告することを、まだ保証できていない。
この状況で、報告をそのまま信じる設計を実務に持ち込めば、偽の完了は業務フローの中に静かに積み上がり、ROIの数字にも紛れ込む。逆に、完了を状態で定義し、報告と状態を突き合わせ、判断を選択式に切り出しておけば、モデルがどれだけ変わっても品質と成果を同じ物差しで測り続けられる。
経営会議で問うべきは「エージェントは何件を処理したか」ではない。「そのうち何件を、エージェント以外の何で確かめたか」である。
Wizitは、試作で止まったAIを業務への定着とROIまで動かし切る実装パートナーとして、大企業の現場でこうした「実務に出してから効いてくる設計」に向き合っています。完了の定義づくりから、報告と状態の突合、効果測定の設計まで、業務部門と情報システム部門の間に入って手を動かす形でご支援しています。
出典
- 9to5Google「OpenAI cancels GPT-6.1 Astra release over misbehavior & safety concerns」（2026年9月28日）、Al Jazeera「OpenAI cancels release of AI model GPT-6.1 Astra, citing safety concerns」（2026年9月29日）、CNBC（2026年9月28日）
- OpenAI DevDay 2026 発表（2026年9月29日）ならびに ITmedia NEWS「OpenAIの『DevDay 2026』で発表された主なことまとめ」（2026年9月30日）、The Next Web・9to5Google による dots に関する報道（2026年9月29〜30日）
- innFactory「OpenAI dots: What Always-On Agents Mean for Your Company」（dots の権限モデルとEnterprise向け機能の整理）
- OpenAI Developers による Decisions API の告知（2026年9月29日）ならびに AlphaSignal による解説
- Laksh Advani「From Confident Closing to Silent Failure: Characterizing False Success in LLM Agents」arXiv:2606.09863（2026年6月）
発行: 株式会社Wizit。記事の内容に誤りがありましたら、お問い合わせからお知らせください。
