AIエージェントは自動化率で選ばない——本番運用を決める「完了一件」の設計

AIエージェントの導入報告では、「業務の何％を任せたか」「何体のエージェントを動かしたか」「人の作業時間を何時間減らしたか」が目立ちます。いずれも変化を伝えやすい数字ですが、本番運用の成否を単独では説明できません。自動化された処理が増えても、完了前に人がやり直し、障害時に止められず、従量課金だけが積み上がれば、業務は軽くならないからです。

2026年9月に公開された複数の事例は、その境界を具体的に示しています。NTTドコモソリューションズは、ネットワーク運用で万能型エージェントを試して品質の低い結果に直面し、役割を分けた構成と手順書参照へ作り直しました。日立製作所は、製造部門ごとのAI、調整役のAI、計画最適化エンジン、人の最終判断をつなぐ構想を示しています。GitHubは、単発の指示ではなく、取得、実行、検査、例外処理を反復可能にする「ループ」や、モデルの周囲に道具、権限、記憶、評価を置く「ハーネス」を整理しました。

同時に、生成AIは従来の人数課金型ソフトウェアと違い、トークンやクレジットの消費が実行回数と再試行に連動します。賢いモデルを選ぶ議論だけでは、業務が終わるまでの再作業、待ち時間、承認、復旧、監視費を捉えられません。

日本企業がAIエージェントを試行から本番へ移すとき、中心に置くべき単位は「自動化率」ではなく「正しく完了した一件」です。本記事では、完了、例外、費用、復旧を一つの仕事番号で追い、本番移行と撤退を同じ表で決める方法を整理します。

結論——本番移行は「完了一件の収支」と「戻れる時間」で決めます

AIエージェントの本番移行を決める最小の判定表には、少なくとも次の六項目が必要です。

判定項目	測る内容	危険な見方
完了率	人の再作成なしで業務の完了条件へ到達した割合	AIが何か出力した件数を完了と数えます
完了時間	受付から承認、実行、記録までの所要時間	モデルの応答時間だけを見ます
例外負債	保留、差戻し、手作業への移管、未解決の件数と古さ	人が処理した例外を成功件数から隠します
完了一件費	モデル、道具、検索、監視、人の確認、再作業を含む費用	トークン単価だけを比べます
影響範囲	読取、変更、送信、設備操作ごとの最大被害	便利さのため一体へ権限を集めます
復旧時間	停止から手作業、旧手順、旧版へ戻るまでの時間	停止ボタンがあるだけで安心します

この六項目を満たすとは、AIが人より何でも上手になることではありません。どの仕事なら安定して終えられ、どの例外は人へ戻り、いくらかかり、失敗時に何分で縮退できるかを説明できることです。

自動化率が20％でも、対象が明確で、復旧が速く、完了一件費が下がるなら本番価値があります。反対に自動化率が80％でも、残り20％が長く滞留し、取消不能な操作を含み、熟練者の確認時間が増えるなら拡大を止めるべきです。AIの活動量ではなく、業務全体の出口から評価します。

万能型エージェントの失敗は、能力不足より仕事の境界不足を示しました

ITmedia エンタープライズが紹介したNTTドコモソリューションズの事例では、同社のプラットフォームサービス部が、業務の約30％をAIエージェントへ任せる運用を進めています。故障解析では、復旧時間を30％短縮する目標に対し、34％短縮したと同社は説明しています。

重要なのは、最初から順調だったわけではない点です。当初は複数業務を一体で担う万能型をネットワーク障害対応へ投入しましたが、原因と関係のない箇所を調べるなど、品質の低い出力が返ったとされています。そこで、情報を集める役、ネットワーク機器を調べる役、それらへ指示して結果をまとめる役へ分割しました。

役割分割だけでも終わりませんでした。現場で使うと人の確認作業が残り、効果が限定的だったため、既存の解析手順や担当者の知識をAIが参照できる手順書として整えました。さらに、コマンド実行前の承認を残し、拒否された場合は理由を受けて代替案を提示する流れにしています。

この経緯から、三つの教訓が得られます。

第一に、モデルへ多くの能力を持たせることと、業務を完了できることは別です。問い合わせ、情報収集、原因分析、操作、報告は、必要な資料、権限、失敗時の扱いが違います。一つの長い指示へ詰め込むほど、どこで誤ったかを切り分けにくくなります。

第二に、精度が上がることと、人の負担が減ることも別です。AIが毎回長い報告を作り、人が最初から読み直すなら、処理は自動でも確認工程は軽くなりません。人には、変更点、根拠、実行予定の操作、取り消せない影響、代替案を短く渡す必要があります。

第三に、成功指標は利用時間ではありません。同社は、長時間AIを使うことが経営への貢献と同じではないとして、時間短縮だけでなく業務の高度化や新しい価値を評価する考えを示しています。これは本番運用の測定単位を、会話回数から完了一件へ変える理由になります。

複数AIをタスク・相互作用・権限・成果の四台帳で管理する記事では、役職名より関係を記録する必要性を整理しました。今回さらに必要なのは、その関係が実際の復旧や納品へ到達し、費用と例外を含めても続けられるかを測る出口です。

日立の製造AIが示すのは、最終判断の前に「実行可能性」を作る構造です

MONOistが報じた日立製作所のAIオーケストレーション技術は、製造業の部門間調整を扱います。特急注文や部材の納期変更が起きると、営業、調達、生産、検査、出荷へ変更が波及します。従来は各担当者が別々のシステムを確認し、連絡しながら条件をすり合わせる場面が多かったと説明されています。

日立の構想では、部品調達、製造、検査、出荷などに特化したAIが各部門の条件と選択肢を整理します。コーディネーターAIが部門間の情報を集め、計画最適化エンジンが設備や稼働状況を踏まえて実行可能な候補を算出し、最終判断は人が担います。HMAX Industryの一部として、2027年中の提供開始が予定されています。

ここで「最後は人が決める」という一文だけを安全策にしてはいけません。人へ届く候補が、各部門の制約を本当に満たすか、在庫や設備情報がいつの時点か、候補間で誰の負担が増えるかを確認できなければ、承認者はAIが整えた見栄えを追認するだけになります。

製造の完了一件は「計画案を生成した」ではありません。例えば特急注文なら、受注条件を確認し、部材と設備を確保し、既存注文への影響を承認し、製造・検査・出荷の予定を各システムへ反映し、顧客へ約束を通知して初めて閉じます。途中の候補生成を自動化率へ数えても、反映漏れや再調整が残れば完了時間は短くなりません。

したがって、仕事番号には次の時刻と状態を残します。

1. 変更要求を受けた時刻と、元の約束を固定します。
2. 各部門AIが参照した在庫、設備、要員、契約条件の版を残します。
3. 最適化エンジンが棄却した案と理由も残します。
4. 人が選んだ案、変更した案、保留した案を区別します。
5. 業務システムへ反映された時刻と、顧客通知の完了を確認します。
6. 後から再調整が起きた場合、同じ仕事番号へ費用と遅延を戻します。

この記録があれば、「AIが候補を十秒で作った」という速度と、「注文変更を二時間で安全に閉じた」という業務成果を分けられます。また、一部の部門AIを止めたとき、どの担当者がどの表を使って調整を続けるかも設計できます。

ループとハーネスは、繰り返す仕組みではなく終わらせる仕組みです

GitHubのAI用語ガイドは、ループエンジニアリングを、エージェントへ単発の指示を毎回出すのではなく、取得、処理、確認、滞留時の引き上げを反復可能にする設計として説明しています。例えば課題を自動取得し、AIへ渡し、結果を検査し、行き詰まった案件だけを人へ上げる流れです。

同ガイドは、エージェントへ仕事を繰り返させる方式が、反復のたびにトークン、文脈、計算資源を使い、高価で非効率になり得るとも述べています。そこで、スキル、可観測性、検証、振り分け、チェックポイントを周囲へ加えます。道具、権限、記憶、文脈、調整機能を含むモデル周辺の仕組みを「ハーネス」と呼びます。

実務で大切なのは、ループを「粘り強く何度でも試す機能」と誤解しないことです。終了条件がないループは、未完了を費用へ変換し続けます。正常終了、例外終了、予算終了、時間終了、安全停止の五つを先に定義します。

終了の種類	条件の例	次に渡すもの
正常終了	完了条件と独立した検査を通過しました	完成物、根拠、変更記録
例外終了	必須情報がない、規程が衝突しています	不足項目、試した経路、担当部署
予算終了	一件の上限トークンまたは上限費用へ達しました	現在案、残作業、消費内訳
時間終了	業務の期限から逆算した引継時刻へ達しました	手作業で再開できる状態
安全停止	権限外操作、外部送信、取消不能な変更を検知しました	操作前の状態、証跡、復旧手順

停止時に「失敗しました」だけを返すのでは不十分です。人が同じ資料を探し直さずに続けられるよう、入力、参照済み資料、確定した事実、未確定の点、実行していない操作を分けて渡します。エージェントが止まった後の人の探索時間も、完了一件費へ含めます。

GitHubが説明する「ヒルクライミング」も、ただ評価点を上げ続けることではありません。実質的な不具合を見つけたか、提案が利用者に役立ったかを測り、モデル周辺の構成を調整する考え方です。本番では、成功率だけを上げると、難しい案件を早く人へ押し付けたり、警告を減らして見かけの完了を増やしたりする可能性があります。完了率、誤完了、例外滞留、費用、復旧を同時に見ます。

トークン単価より、再試行と人の手直しを含む「完了一件費」を見ます

＠ITの生成AIコスト解説は、Gartnerの調査として、経営層の85％がAIによるコスト削減を期待する一方、ROI測定に成功していると答えた企業は14％にとどまると紹介しています。また、従量課金では、操作ごとの消費条件、用途別倍率、超過料金、未使用分、全社共有の可否など、契約の構造を理解する必要があると整理しています。

これらは調査対象と質問条件に基づく数値であり、日本企業すべての結果を表すものではありません。ただし、期待を先に置き、測定方法を後回しにしやすい構造は、自社の予算表でも点検できます。

モデルAがモデルBより入力単価を半分にしても、Aが三回やり直し、長い文書を毎回読み込み、最後に熟練者が全面修正すれば安くなりません。反対に高価なモデルでも、一回で必要な根拠を集め、狭い確認で完了し、例外を早く人へ返せるなら、一件全体では安くなる場合があります。

完了一件費には、次の七つの箱を置きます。

• モデル費は、入力、出力、推論、キャッシュ、再試行を含めます。
• 道具費は、検索、データベース、外部API、実行環境を含めます。
• データ費は、文書整備、索引更新、権限付与、保持を含めます。
• 人の費用は、依頼準備、承認、修正、例外対応を含めます。
• 品質費は、誤りの発見、差戻し、顧客対応、再実行を含めます。
• 運用費は、監視、評価、ログ、当番、モデル更新を含めます。
• 復旧費は、停止、旧手順への切替、データ修復、再開を含めます。

HBMやHBFを「記憶の配置」として整理した記事でも、API呼び出し一回ではなく仕事の完了一件を測定単位にしました。エージェント運用では、そこへ人の承認と例外負債を加えます。速いモデルを選ぶだけでなく、同じ資料を何度読ませ、どこで人が待ち、何件が翌日へ残ったかを結びます。

費用上限も月額だけでは足りません。月末まで予算が残っていても、一件が暴走して数時間ループすれば、他の案件を遅らせます。一件上限、部署の日次上限、全社月次上限を分け、上限へ近づいたときは、小さいモデル、短い文脈、提案のみ、手作業へ段階的に縮退します。

人の確認回数ではなく、例外が読める状態を測ります

AIエージェントの試行では、人が全件を丁寧に確認できます。本番で件数が十倍になれば、同じ確認方法は続きません。画面へ承認ボタンを置くだけでは、長い出力を流し読みして押す「反射承認」が増えます。

危険操作と承認疲れからレビュー工程を整理した記事で述べたように、狭い自動停止、通常確認、専門家による例外審査、承認後の追跡を分ける必要があります。今回の本番移行判定では、次の指標へ落とします。

• 通常案件で、人が根拠へ到達するまでの中央値を測ります。
• 例外案件が担当者へ届くまでの時間と、未処理の古さを測ります。
• AIの提案を人が変更した割合だけでなく、変更理由を分類します。
• 承認後に判明した誤りと、顧客や設備へ届く前に止めた誤りを分けます。
• エージェント停止後、人が業務を完了できた割合と時間を測ります。

例外率が下がることだけを目標にすると、AIが警告を出さずに完了扱いする誘因が生まれます。望ましいのは、重要な例外を早く分離し、十分な材料とともに適切な人へ渡すことです。例外が増えても、見落としが減り、解決時間が短くなるなら、導入初期には健全な改善かもしれません。

30日で「本番へ進める仕事」と「戻す仕事」を一つずつ決めます

全社共通の巨大なAI基盤を先に完成させる必要はありません。完了条件が明確で、件数があり、失敗しても局所化できる一業務を選びます。問い合わせの下書き、リリースノートの影響判定、定型的な社内申請などが候補です。契約締結、支払い、設備の不可逆操作は、最初の自律実行から外します。

最初の10日——人の現行工程を一件ずつ閉じます

受付から完了までを観察し、誰が何を見て、何を変更し、どの条件で終わりとするかを書きます。平均時間だけでなく、最も遅い一割と、翌日へ残る理由を集めます。AIを入れる前の完了率、完了時間、例外、費用、復旧経路が基準線です。

この段階で、完了条件を「回答を作る」から「根拠を付け、承認を受け、記録し、相手へ届く」へ具体化します。現行業務に終わりが定義されていなければ、AIも終われません。

次の10日——影の運用で出口だけを比べます

AIは提案を作りますが、実際の業務は従来手順で進めます。同じ案件について、AI案がどこまで正しく、どこで人が直し、何トークンと何分を使ったかを測ります。モデルの点数ではなく、人の実績と同じ完了条件で比較します。

一日ごとに、成功例だけでなく、長い再試行、誤った早期終了、不要な資料参照、権限要求、例外の渡し方を見直します。ハーネスを変更したら版を付け、前後の案件を混ぜません。

最後の10日——限定本番と縮退訓練を行います

低リスクの一部案件だけで実行を許可し、一件上限と時間上限を設定します。正常時の成功率を測るだけでなく、モデル停止、検索停止、古い手順書、権限拒否、予算上限を意図的に起こします。人が旧手順へ戻り、案件を失わずに閉じられるかを測ります。

30日後は「導入するか、やめるか」の二択にしません。安定した狭い仕事は本番へ進めます。例外負債が大きい仕事は提案のみに戻します。完了条件が曖昧な仕事は業務整理へ戻します。費用が合わない仕事は小さいモデルや定型処理へ替えます。取消不能な影響を局所化できない仕事は自律実行を見送ります。

参考にした主な情報

• 2026年9月14日、MONOist「日立HMAX新技術『AIオーケストレーション』、特急注文など部門間調整を自動化」
• 2026年9月14日配信、ITmedia エンタープライズ「“最強エージェント”は、まさかのポンコツだった」
• 2026年9月13日、＠IT「生成AIの予算超過を防ぐトークン浪費対策の全て」
• 2026年9月2日、GitHub Blog「Decoding the new AI lingo」

結論——増やす前に、終わらせ方と戻し方を決めます

AIエージェントの本番価値は、動いた回数や自動化率ではなく、正しく閉じた仕事の数で決まります。その一件には、モデルの出力だけでなく、根拠、承認、実行、記録、例外、費用、復旧まで含まれます。

NTTドコモソリューションズの事例は、万能型から役割分割と手順参照へ進み、復旧という出口を測る重要性を示しました。日立の構想は、部門ごとの条件を集め、実行可能な候補を作って人へ渡す構造を示します。GitHubの整理は、その工程を繰り返し、検査し、途中で止める周辺設計がモデルと同じくらい重要だと教えます。

次の会議で「何％をAI化できますか」と聞く前に、「一件が終わったと誰が判定し、失敗したら何分で人へ戻せますか」と尋ねてみてはどうでしょうか。その答えを実測できる仕事から始めれば、AIエージェントは派手な試行ではなく、止めても続けられる日常の仕組みになります。