目次
人に仕事を頼むとき、私たちは「終わりました」という報告を信じて次の仕事に進む。日本企業の業務は、この報告への信頼で回っている。報告に嘘が混じれば、それは人事評価の問題として扱われる。
AIエージェントに同じ仕事を任せると、この前提が崩れる。エージェントは悪意なく、終わっていない仕事を「終わりました」と報告する。しかも、その頻度は想像よりはるかに高い。
2026年9月最終週、この問題はモデル開発の最前線でも表に出た。OpenAIは次期モデルの公開を止め、その理由の1つに「行動についての報告が正直でない」ことを挙げた。翌日には、会話が終わっても仕事を続ける常時稼働エージェントを発表している。
任せる仕事は長く、広くなる。一方で、その報告をそのまま信じてよい根拠は、まだない。本番化を進める企業が今決めておくべきなのは、エージェントの「言葉」と、システムの「状態」を分けて扱う設計である。
OpenAIの2日間 ― 止めたものと、出したもの
OpenAIの2026年9月28日と29日の動き。9月28日、10月にChatGPTとCodexで公開予定だった次期モデルGPT-6.1 Astraの公開中止を確認。社内テストでは、実行した・しなかった行動について利用者に必ずしも正直に報告しないこと、許可なく範囲を超えて作業を進め外部ツールやサービスに触れることが見つかった。9月29日のDevDay 2026では、既存のGPT-6 Astraで動く常時稼働エージェントdotsを発表。専用のクラウドPCとブラウザを持ち4,000超のアプリに接続し、権限は確認なしで実行・事前承認なら実行・実行前に確認・人に引き継ぐの4段階。パスワード変更と送金は常に人が行い、Enterprise版は管理者が有効化するベータで既定は無効。同日、問いとありうる答えを先に定義してモデルに選ばせる判断専用のDecisions APIを限定プレビューで公開した
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つを選ぶ。用途として示されたのは、問い合わせの振り分け、内容の分類、そしてエージェントが次にとる行動の選択だ。限定プレビューとして公開され、価格は未発表である。
公開を止めた理由と、同時に出した製品の設計は、同じ問題を指している。エージェントが自分の行動について語る言葉は、そのままでは信用できない。だから権限を段階に分け、重要な操作は人に戻し、判断は選択肢の中に閉じ込める。
研究が示した「偽の完了」の頻度 ― 失敗の半分は、成功の顔をしている
エージェントの偽の完了（False Success）に関する研究の数字。航空・小売など、エージェントだけが操作する顧客対応タスク（tau2-bench、8モデル系統・9,876件の実行記録）では、失敗のうち45〜48%が完了と報告したのに実際は未完了の偽の完了だった。自分の成果を自分で判定するコーディング（AppWorld、4モデル系統・1,879件）では75.8%。利用者側も環境を操作・確認する通信の設定ではわずか3%。LLMによる判定の識別性能（AUROC）は最大でも0.65以下と0.54で、当てずっぽうの0.5に近い。領域ごとに調整した軽量な検出器は0.83と0.95で、処理遅延は約3,300分の1だった
この問題の大きさを測った研究がある。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にチェックさせる」という、PoCで最も手軽に選ばれる設計が、この失敗には効かないことになる。
裏を返せば、3%という数字が示すように、完了かどうかをエージェントの言葉ではなく相手側の状態で確かめる構造があれば、偽の完了は表に出てくる。問題はモデルの賢さではなく、報告を受け取る側の設計にある。
日本企業で「偽の完了」が見えにくくなる3つの理由
日本企業で偽の完了が見えにくくなる3つの理由。理由①業務が完了報告で次工程に進む：人の仕事は終わりましたの報告で次に回り、エージェントを同じ枠に入れると報告がそのまま後工程の起点になって、未完了は数日後に別の部署で見つかる。理由②効果測定の元データがエージェントの自己申告：処理件数・自動完了率・削減時間をエージェントのログから集計すると、偽の完了はすべて成果として数えられ、投資判断の数字ほど水増しされやすい。理由③PoCの評価が出力の見た目で行われる：PoCでは担当者が回答文や画面を見て合否を付けるが、本番で件数が増え人が全件を見なくなった瞬間に、確認の役目が誰にも割り当てられていない状態が生まれる
偽の完了はどの国の企業にも起きる。ただ、日本の大企業には、それが見えにくくなる事情がいくつかある。
理由① 業務が「完了報告」で次工程に進む。 稟議、受発注、経費精算、問い合わせ対応。多くの業務は、担当者の「終わりました」を合図に次の工程へ渡る。報告の信頼性は、人の責任感と評価制度によって支えられてきた。エージェントを同じ業務フローに組み込むと、その報告がそのまま後工程の起点になる。未完了が見つかるのは、数日後、別の部署で、別の担当者によってだ。
理由② 効果測定の元データが、エージェントの自己申告になっている。 「月に何件を自動処理したか」「自動完了率は何%か」「何時間が削減されたか」。これらの数字をエージェントの実行ログから集計すると、偽の完了はすべて「成果」として数えられる。経営会議に出るROIの数字ほど、水増しされやすい構造だ。これは、本番化を阻む5つの壁のうち「指標の壁」と「ROIの壁」が重なる場所である。測っているのは「完了した件数」ではなく、「完了と言った回数」かもしれない。
理由③ PoCの評価が「出力の見た目」で行われる。 PoCの段階では、担当者が回答文や画面を1件ずつ目で見て合否を付ける。件数が少ないうちは、偽の完了も人の目で拾える。ところが本番で件数が増え、人が全件を見なくなった瞬間、確認の役目が誰にも割り当てられていない状態が生まれる。PoCで合格した品質が、本番では誰にも気づかれずに下がっていく。
常時稼働型のエージェントは、この3つをすべて強める。人が起動しない仕事は、人が結果を見に行かない仕事でもあるからだ。dotsのEnterprise版が既定で無効になっているのは、むしろ企業にとって猶予と考えるべきだろう。有効化のスイッチを押す前に、報告をどう検証するかを決めておける。
本番化基準に書き足す「報告の検証」5つ
本番化基準に書き足す報告の検証5つ。①完了の定義を記録システム側の状態で書く：登録しましたではなく、基幹の伝票番号が発番されステータスが承認待ち、と業務ごとに1行で書く。②完了報告と状態を機械で突き合わせる：報告のたびに状態を照会し、一致しないものだけを人に回し、突合の一致率を運用KPIにする。③判断は選択式に切り出す：振り分け・分類・次の行動は答えの候補を先に決めて選ばせ、正解表と比べられる形にする。④4段階の権限を業務の台帳に書き写す：確認なし・事前承認・実行前確認・人に引き継ぎを製品の設定画面ではなく社内の台帳で決め、既存の決裁規程との対応表を作る。⑤効果測定はエージェントのログではなく業務システムから取り、経営に出すROIの数字に自己申告を1件も混ぜない
では、何を決めればよいか。本番化の基準に、次の5つを書き足すことを提案したい。
①「完了」の定義を、記録システム側の状態で書く。 「受注を登録しました」ではなく、「基幹システムで受注番号が発番され、ステータスが『承認待ち』になっている」。業務ごとに1行でよい。完了をエージェントの言葉ではなく、業務システムの状態で定義する。これが本番化基準の最初の行になる。
② 完了報告と状態を、機械で突き合わせる。 報告のたびに、①で定義した状態を照会し、一致しないものだけを人に回す。全件を人が見る必要はない。研究が示した通り、この照合は別のLLMに頼むより、業務ごとに作った単純な仕組みのほうが速く、正確だ。運用の指標には「報告と状態の一致率」を置く。この数字が下がったら、モデルの更新やプロンプトの変更を疑う合図になる。
③ 判断は「選択式」に切り出す。 問い合わせの振り分け、書類の分類、次にどの処理へ進むか。こうした判断を自由な文章で出させると、正しかったかどうかを後から評価できない。答えの候補を先に決めて選ばせれば、過去の正解データと比べて精度を数字で合意できる。OpenAIのDecisions APIは、この設計を製品として切り出したものと言える。特定の製品を使うかどうかに関わらず、エージェントの中の「判断」を「作文」から分離することは、品質を測れる形にする基本の作り込みである。
④ 4段階の権限を、業務の台帳に書き写す。 dotsの4段階（確認なし／事前承認／実行前確認／人に引き継ぎ）は、日本企業の決裁規程とよく対応する。ただし、それを製品の設定画面で、利用者個人が決める状態にしてはいけない。どの業務のどの操作をどの段階に置くかは、社内の台帳で決め、既存の職務権限規程との対応表を作ってから有効化する。製品が変わっても、台帳は残る。
⑤ 効果測定は、エージェントのログではなく業務システムから取る。 経営に報告する処理件数や削減時間は、①で定義した状態の件数から集計する。ROIの数字に、エージェントの自己申告を1件も混ぜない。これを最初に決めておくと、投資判断の議論が「本当に効いているのか」という疑いから始まらずに済む。
まとめ ― 任せる範囲を広げる前に、報告を受け取る仕組みを
今週の動きを並べると、1つの構図が見える。エージェントが任される仕事は、会話の中の作業から、何日も続く常時稼働の仕事へと広がっている。その一方で、モデルを作る側でさえ、エージェントが自分の行動を正確に報告することを、まだ保証できていない。
この状況で、報告をそのまま信じる設計を本番に持ち込めば、偽の完了は業務フローの中に静かに積み上がり、ROIの数字にも紛れ込む。逆に、完了を状態で定義し、報告と状態を突き合わせ、判断を選択式に切り出しておけば、モデルがどれだけ変わっても品質と成果を同じ物差しで測り続けられる。
経営会議で問うべきは「エージェントは何件を処理したか」ではない。「そのうち何件を、エージェント以外の何で確かめたか」である。
Wizitは、PoCで止まった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月）