モデルは全体のごく一部です。データは使えるか、インターフェースは明確か、業務フローはつながるか、AI が間違えたら誰が対応するか。これらの問題は一度に現れます。
gptpmt のチュートリアルを書き終えてから、さまざまなことに追われ、腰を据えて一本の記事を書く時間を長らく取れずにいました。
2022年に ChatGPT に触れ、2023年に gptpmt を書き始め、その後は企業での AI 導入にも関わってきました。三年以上の間に多くの試みを重ね、企業が AI を実務に入れるときに直面する問題を見てきました。
最近、周囲からよく聞かれるのが、「すでに多くの業務システムを持つ企業は、どう AI と接続すればよいのか」という質問です。
一見すると、これは技術の問題です。どのモデルを選ぶか、どのフレームワークを使うか、API をどう呼ぶか。
しかし実際に始めると、モデルは小さな一部にすぎないと分かります。社内データを使えるのか、既存のインターフェースは理解できるのか、複数の業務フローをどう接続するのか、AI の誤りを誰が処理するのか。すべてが同時に問われます。
典型的なカスタマーサポートから考えましょう。ユーザーがチャットを開いて尋ねます。
「注文した商品がまだ発送されないのはなぜですか？」
AI は物流が遅れる一般的な理由を長々と説明し、最後に注文番号を求めます。番号を受け取っても照会できず、結局は人の担当者へ転送します。
企業は AI サポートの構築に時間をかけたのに、担当者の仕事は減りません。それどころか、AI の説明を補う仕事が増えました。
なぜでしょうか。
問題は必ずしもモデルではありません。質問に答えるだけのシステムを、照会、判断、実行、リスク負担が必要なタスクへ直接投入したことにあります。
基礎を作らないまま最上階の内装を話し合う建築に似ています。工事が遅いだけでなく、途中で下の構造が支えられないと判明します。
レガシーシステムへの AI 導入も、能力を一層ずつ整える必要があります。大きく四段階に分けられます。Chatbot（対話で質問に答える仕組み）、AI + Tools（AI が明確な業務機能を呼び出せる構成）、Copilot（目標に向けて複数の手順をつなぎ、不確実な場面では人に戻す支援システム）、Agent（合意した範囲で自律的に実行するシステム）です。
これは業界標準ではなく、能力を点検するための枠組みです。すべての中間版を正式公開する必要はありませんが、データ、ツール、タスク、ガバナンスという土台は飛ばせません。
四つの段階、四つの能力層。
第1段階：Chatbot——まず正しく答える
質問を簡単にします。
個別注文ではなく、「支払い後、通常は何日で発送されますか」と聞かれた場合です。
このとき AI は業務システムへ入る必要がありません。発送ルール、返金ポリシー、商品情報、よくある質問が整理されていれば答えられます。
この段階の Chatbot は、企業の知識に基づいて一般的な質問へ回答します。
営業時間、製品説明、経費精算制度、アフターサービスの規則などは、通常すでに社内文書にあります。以前は従業員が自分で探していましたが、自然言語で質問し、AI に関連箇所を見つけて回答を組み立てさせられます。
文書を入れるだけでよいように見えます。
しかし個別の注文になると、Chatbot は何も知りません。ユーザーが誰か、どの注文を持つか、注文が今どの状態かが分からないまま答え続ければ、一般規則から推測するだけです。
したがって第1段階の境界は明確です。企業の知識にある質問には答えられますが、進行中の業務事実を知っているふりはできません。
段階0から第1段階へ：鍵はモデルではなくデータガバナンス
多くの企業は、何百万字もの Lark 文書、製品マニュアル、サポート記録を一度に AI へ渡し、文書が多いほど回答もよくなると考えます。
しかし、文書の量と知識の利用可能性は別です。
ラベルも定位置もない同じ形の調味料入れが、台所に何十個も並んでいると想像してください。塩、砂糖、酢、胡椒があると分かっていても、使うときには一つずつ開けて確かめるしかありません。
企業文書もよく似ています。
同じ返金ポリシーが三つの版で残り、販売終了製品の古い応対文も残る。ある語が部門によって別の意味を持ち、同じ業務名が数年の間に何度も変わることもあります。
人が迷うなら、AI も誤った文書を探します。
さらに AI の回答は流暢です。古い規則と新しい規則を混ぜても、一般のユーザーは気づけないかもしれません。誤答が正答らしく見えるほど、リスクは高まります。
最初に必要なのはデータガバナンスです。少なくとも次を明確にします。
- どの内容が正しく、どれが失効しているか。
- 文書をどう分類し、各質問をどこから検索するか。
- 同じ概念がシステムごとに何と呼ばれ、共通用語集が必要か。
- 各利用者が何を閲覧でき、機密情報をどう分離するか。
- 誰が更新し、古い版をいつ廃止するか。
- 何を正答とし、誤りを継続的にどう発見するか。
AI は分類、重複除去、整理を支援できますが、分類体系、保守責任、合格基準を定めるのは企業です。
データガバナンスは一度きりの大掃除ではありません。業務規則、製品、組織は変わり、今日正しい内容も半年後には古くなります。知識ベースには継続的な更新経路が必要です。
ここまで来れば、サポートは単に「大規模モデルを接続した」のではなく、有効な企業知識に基づいて答えられます。根拠がなければ、もっともらしい内容を作らず「分からない」と言うべきです。
第1段階の完了は、準備済みの質問に答えるデモでは判断できません。実ユーザーが言い換え、連続して質問し、権限境界に触れても正しい根拠を探せるかを確認します。そこが安定して初めて、業務システムの奥へ進む意味があります。
第2段階：AI + Tools——この注文を照会できるようにする
第2段階では、質問が個別注文に関わります。
冒頭の質問に答えるには、AI が注文照会ツールを呼び、ユーザーの注文と配送状況を取得しなければなりません。倉庫に残っていると確認して初めて、本当の理由を伝えられます。
ユーザーが返金を求めれば、返金ツールも呼びます。
AI は企業知識を読むだけでなく、業務システムを使って具体的な操作を行います。これが AI + Tools です。
Tools は企業が AI に提供する能力の入口です。注文照会、配送情報取得、返金額計算、実際の返金申請は、それぞれ別のツールです。
AI はユーザーの言葉を理解し、適切なツールを選び、返されたデータを分かりやすい結果にまとめます。
簡単に聞こえますが、問題はここからです。
レガシーシステムには、返金 API が十数個並存することがあります。旧版、クーポンだけを返すもの、内部フィールドが必要なもの、失敗理由を明確に返さないものなどです。
全部を AI に渡して選ばせても、システムは賢くなりません。隠れていた複雑さが表に出るだけです。
以前はシステムに詳しい開発者が呼び出していました。どれが使え、どれが過去の遺物で、「任意」と書かれたどの引数が実際には必須かを知っていました。AI にはその暗黙知がなく、与えられた説明だけで判断します。
ツール名が曖昧で、引数定義が不完全、返り値も不統一なら、高性能なモデルでも選択を誤ります。
第1段階から第2段階へ：鍵はツールガバナンス
ツールガバナンスは、古い API を包むだけではありません。基本事項を改めて答えることです。
- 何を解決するツールで、いつ使ってはいけないか。
- 必須引数は何で、どこから取得するか。
- 成功、失敗、部分成功をどの構造で返すか。
- どの役割が呼べ、どのデータを読み書きできるか。
- 照会回数に上限はあるか、変更操作には確認が必要か。
- 同じ要求が重複したとき、二重返金や二重注文をどう防ぐか。
- 呼び出した人、入力、結果を完全に追跡できるか。
見落とされやすいのが冪等性です。
返金ツールがタイムアウトすると、AI は成功したか分からず再度呼ぶかもしれません。重複防止がなければ、同じ注文を二度返金する可能性があります。
これはモデルの賢さではなく、ツールが自動化に備えているかという問題です。
まず保守担当者が使い方を明確に説明できる状態にし、その後 AI へ渡します。ツールが少なく責務が明確なほど、AI は正しく使いやすくなります。十数個の歴史的 API は、少数の安定した業務能力へ集約するのが理想です。
ここで、「指示を実行する」ことと「タスクを完了する」ことを分けます。
注文照会、配送状況取得、返金開始は、それぞれ明確な指示です。人が一手を指示し、AI が一つのツールを呼んで止まるなら AI + Tools です。
最終目標だけを伝え、何を先に行い、途中の問題をどう扱うかまでシステムが判断するなら、次の段階に入ります。
第3段階：Copilot——タスクを先へ進める
条件を一つ加えます。「この注文を確認し、まだ発送されていなければ返金してください」。
一回のツール呼び出しでは終わりません。ユーザーと注文を確認し、配送状況を調べ、返金条件を判定し、金額を計算し、返金を申請して結果を伝えます。
AI + Tools は、人が一手を指示して AI が一手を進める形です。Copilot では人が目標を渡し、AI が複数の手順をつなぎます。不確実性や高いリスクに出会ったら止まり、人へ戻します。
AI は「現在の目標を理解する → 次の手を決める → ツールを呼ぶ → 結果を読む → 新しい結果から次を判断する」というループを繰り返します。
発送済みなら未発送返金へ進まず、返金額が異常なら停止し、本人確認前なら注文を変更しません。各ステップの結果が次の行動を変えます。
これがタスクの閉ループです。
第2段階と第3段階の違いは、複数ツールを一度に呼べるかでも、読み取りから書き込みへ変わることでもありません。目標に向けて、完了、失敗、または人への引き継ぎまで継続できるかどうかです。
ツールを連結すると、新たな問題が現れます。
問題1：意図のガバナンス
難しいのは個々のツールより、最初に誤ったフローへ入ることです。
配送情報が三日更新されず、ユーザーが苦情と返金を同時に求めたとします。
要求には配送異常、苦情、返金が含まれます。苦情だけと認識すれば、なだめ続けて返金を扱わない。即時返金すれば、注文状態や返金条件を見落とします。
まず業務領域を判断し、曖昧な表現を実行可能な意図に分解して、順番を決める必要があります。
なぜ数百の選択肢を持つ巨大な意図分類器を一つ作らないのでしょうか。
実際の業務はデモより複雑です。「変更して」が、注文では住所変更、出張では予約変更、人事では従業員情報の変更を意味することがあります。業務が増えるほど、全意図を一階層に置く分類は混乱します。
適しているのは階層型ルーティングです。
最初に注文、配送、アフターサービス、アカウントを分け、注文内で照会、変更、取消、返金を分けます。複数の意図があれば分解し、依存関係に沿って並べます。
配車ならさらに明確です。「明朝、空港へ送って」には出発地、便の時刻、到着余裕が必要です。「同行者にも一台呼んで」が加わると、二人目、別の乗車地、異なる車種が生じます。すべてを単純な「配車」意図へ押し込めば、後続フローが混ざります。
意図のガバナンスは一文にラベルを付けることではありません。ユーザーが本当に達成したいことを、システムが実行できるタスクへ段階的に絞ることです。
一つの発話から、実行可能なタスクへ。
問題2：状態管理
さらに変化を加えます。
注文照会が終わり、返金直前にユーザーが「返金はやめて、配送先を変えたい」と言いました。
返金を強行するのも、それまでの結果を捨てるのも不適切です。現在のフローを中断し、取得済みの注文・配送情報を保持して、住所変更が可能かを判断します。
これには状態管理が必要です。会話の内容だけでなく、タスクの現在地、実行済みツール、取り消せる操作を把握します。すでに返金を申請したなら、何もなかったふりをせず、取消または補償フローへ入ります。
少なくとも二種類のコンテキストがあります。会話コンテキストは「この注文」がどれか、何を確認済みかを示します。タスクコンテキストは返金処理の現在地、成功したツール、確認待ちの操作を示します。
チャット履歴だけでは足りません。「返金準備中」と書かれていても、実際に申請したかは別の状態です。ツール状態だけでも足りません。ユーザーの「やっぱりやめる」が目標を変えるからです。
Copilot は次の変化を扱う必要があります。
- 中断後も完了済みの結果を再利用できる。
- 追加情報を受けて正しい地点から再開できる。
- 依存する複数の意図を順番に実行できる。
- 副作用のある操作が失敗したら、ロールバックまたは補償へ進める。
- 能力超過、情報不足、高リスク時に、完全なコンテキストとともに人へ渡せる。
意図のガバナンスは正しい道を選んだかを決め、状態管理は変化後に迷わないかを決めます。
ここまでできて初めて、AI は数個のツールを囲うチャット画面ではなく、業務フローへ参加し始めます。
第4段階：Agent——境界内の結果を誰が引き受けるか
Copilot は目標を理解し、手順を組み、ツールを継続して呼べます。Agent との差は何でしょうか。
責任です。
AI サポートが返金できるとして、本来50元までの注文で、ユーザーに誘導され5,000元を返したら、誰が結果を負うのでしょう。
担当者が全件確認し、問題時に「確認者が見落とした」とするなら、まだ Copilot です。AI が実行し、人が横でブレーキを踏んでいます。
Agent は別の約束を意味します。合意した運用境界内では担当者が全件確認せず、システムの自律判断が誤った場合、Agent を提供するチームが合意範囲の結果に責任を持ちます。
Agent が無制限に保証するという意味ではありません。
運転自動化の L2 と L3 は変化を理解する助けになります。L2 では運転者の継続監視が必要です。L3 は限定条件でシステムがより多くの運転タスクを担い、引き継ぎ要件も残します。この比喩はタスクと監視責任の変化を示すだけで、個別事故の法的責任を導くものではありません。
実際の責任は、地域の法律、製品上の約束、運用条件、事実関係で決まります。Agent も同じで、境界を先に明記し、外れた場合は拒否、安全に機能を縮退、または人へ引き継ぎます。
例えば返金 Agent は、金額200元以下、注文状態が明確、本人確認済みの通常対応だけを扱う。上限超過、異常アカウント、規則の衝突があれば直ちに人へ回します。
範囲内は自力で完了できても、範囲外で完了率のために推測を続けてはいけません。
Copilot から Agent へ：鍵は体系的な監督
人が全件確認しなくても、監督は消えません。「人が各手順を見る」から「システムがリスクを自動で抑える」へ変わります。
無人運用は、無監督という意味ではありません。
少なくとも次を管理します。
- 権限： アクセス可能なシステム、読めるデータ、変更できる内容。
- 予算： 一タスクのツール回数、資源消費、扱える金額。
- 監視： 現在の動作、目標からの逸脱、異常の早期検知。
- リスク管理： 絶対に迂回できない規則、再本人確認が必要な条件。
- サーキットブレーカー： 連続失敗、異常コスト、制御不能時に即停止できるか。
- ロールバックと補償： 途中まで実行した操作を安全な状態へ戻す方法。
- 監査と評価： 判断を追跡でき、極端なケースを繰り返し試験しているか。
- 責任体制： 問題時に誰が対応・修復し、合意範囲の結果を誰が負うか。
難しいのは、従業員の経験にあった判断を、システムが実行できる規則に変えることです。
担当者は異常な返金を見て「何かおかしい」と感じます。Agent にその曖昧な共通理解はありません。金額、回数、アカウント、注文状態と理由の不一致のどれが異常なのか。直接拒否、再確認、人への転送を分ける条件は何か。企業が具体化する必要があります。
経験を言語化して初めて、体系的な監督が存在します。
評価も平均精度だけでは不十分です。通常注文をうまく処理しても、極端な入力で権限を迂回できたり、連続失敗後もツールを呼び続けたりするなら、無人環境には置けません。
信頼できる Agent には、高性能なモデルだけでなく、明確な運用範囲、継続監視、人への引き継ぎ、インシデント対応、復旧能力が必要です。
この枠組みでの Agent は、Copilot の流行名ではありません。境界内の自律的な結果に責任を持つという約束です。
企業はどの層から始めるべきか
「Agent をどう作るか」と尋ねる前に、現在のシステムに何が欠けているかを見ます。
最も弱い層を見つけ、そこから始める。
企業知識が不正確なら、まずデータを整理し、AI に何でも答えさせようとしない。
Chatbot が正しく答えられるなら、混乱した古い API を明確で安全、追跡可能なツールへ整える。
ツールが使えるなら、意図のガバナンスと状態管理を加え、正しいワークフローを継続させる。
Copilot が多段階タスクを安定して完了できるなら、人の監督にある有効な規則を、実行可能な権限、リスク管理、サーキットブレーカー、監査、責任体制へ落とし込みます。
四層の行動を具体化します。
第1層：まず知識を整理する
境界が明確で質問が集中する一つの業務を選び、最初から全社文書を投入しません。信頼できる情報源、分類、権限、保守担当を決め、実際の質問で反復試験します。
第2層：次にツールを整理する
照会ツールから始め、入口と返り値を安定させます。データ変更ツールでは、事故前に権限、確認、冪等性、監査を整えます。
第3層：タスクの閉ループを作る
手順が多すぎず結果を検証しやすいフローを選び、意図分解、タスク状態、中断・再開、人への引き継ぎを試します。十個の未完成品より、一つの安定した完結フローに価値があります。
第4層：自律境界を少しずつ広げる
無人実行を許すタスクを明記し、その範囲に予算、監視、リスク管理、サーキットブレーカー、補償、責任者を設定します。安定を確認してから少しずつ広げ、最初から何でも自動化しません。
中間版を正式公開しない選択はできますが、背後の能力構築と検証は飛ばせません。
すべての企業が最終段階へ進む必要もありません。Chatbot で十分な業務も、高リスクのため長期的に人の確認を残すほうがよい操作もあります。
おわりに
Chatbot、AI + Tools、Copilot、Agent は、全企業が従う業界標準でも、第4段階まで行けば成功という基準でもありません。
この区分が答えたいのは、もっと実際的な問いです。AI プロジェクトが止まったとき、何が本当に足りないかを見分けられるか。
回答が不正確なら知識とデータを見る。ツールの選択を誤るなら API と権限を見る。フローが完了しないなら意図と状態を見る。自律運用が不安なら監督と責任を見る。
一段進むごとに、人が隠していた次層の問題が現れます。従業員の経験で覚えていた規則はデータ問題に、開発者の暗黙知で使っていた API はツール問題に、担当者が見張っていた例外はガバナンス問題になります。
より強いモデルを接続しても、これらは自動で消えません。
誰もが探索の途中で、概念の境界も変わり続けます。Agent を作ったと急いで証明するより、実際の一場面を選び、一つの質問に正しく答え、一つのツールを正しく使い、一つのフローを安定して完了させるほうが先です。
実践が、次に足りないものを教えます。
今どの層にいるかを判断し、その層を本当に整える。そうして初めて、レガシーシステムへの AI 導入は、賢そうなチャット画面を増やすだけではなくなります。
参考資料
- NHTSA, Automated Vehicle Safety; SAE, J3016 Levels of Driving Automation.
- NIST, AI Risk Management Framework Core.
- Anthropic, Building Effective AI Agents.
WeChat 公式アカウント
企業 AI、Agent、実業務への導入に関心があれば、WeChat 公式アカウント「刘路飞」をフォローしてください。今後もこれらの問題を書いていきます。
Luffy Liu · 刘路飞 は独立系プロダクトビルダーとして、企業 AI、Agent、実際のワークフローを記録しています。
続けて読む
Independent product builder · AI, agents and real workflows.