企画意図
この記事は「AIエージェントとは何か」ではなく、企業導入でAIエージェントがなぜ失敗するのかを、LLM性能ではなくハーネス不足として説明する。狙う読者は、AIエージェントPoCを進めたが本番化できない事業責任者、CTO、情報システム部門、DX推進部門、AI活用を進める経営者である。
結論は明確である。AIエージェントが業務で失敗する主因は、モデルが少し賢くないことではない。目的、権限、記憶、品質、停止条件、復旧経路、監査証跡を囲うハーネスがないことである。MARIA OSがDynamic Harnessを中核に置く理由もここにある。
1. PoCでは動くのに、本番で止まる理由
AIエージェントのデモはよく動く。メールを読み、要約し、タスクを作り、カレンダーを確認し、CRMを更新し、Slackに通知する。短い動画にすると未来が来たように見える。PoCでも、限定されたデータ、限定された権限、担当者の近くで動かすなら成果が出る。
しかし本番に近づくと急に難しくなる。権限が増える。例外が増える。古いデータが混ざる。部署ごとのルールが衝突する。人間が期待していた暗黙知をAIが知らない。間違ったときに誰が直すのか決まっていない。AIがどこまで自律実行してよいのか、現場も管理者も分からない。
ここで多くの組織は「モデルがまだ弱い」と考える。もちろんモデル能力は重要である。しかし、最新モデルに変えても同じ失敗が起きることは多い。なぜなら、問題は推論能力だけではなく、運用構造にあるからである。
AIエージェントは、賢い関数ではない。目的を持ち、記憶を読み、ツールを呼び、他者に影響を与え、時間をまたいで状態を変える実行主体である。これを囲うハーネスがなければ、モデルが賢くなるほど、失敗の到達距離も伸びる。
2. ハーネスとは何か
ハーネスとは、AIエージェントを安全に実行するための運用枠である。単なるテストではない。エージェントが何を目的に動き、どの権限を持ち、どの情報を根拠にし、どこで止まり、失敗時にどう復旧し、誰へ説明責任を残すのかを定義する仕組みである。
ソフトウェア開発でテストハーネスは、対象コードを決められた条件の中で動かし、期待値と比較する。AIエージェントのハーネスはさらに広い。実行前、実行中、実行後を見なければならない。
実行前には、目的、入力、権限、禁止事項、参照してよいデータ、必要な承認を確認する。実行中には、ツール呼び出し、推論の逸脱、コスト、レイテンシ、責任境界、リスク兆候を監視する。実行後には、結果、根拠、影響、修正要否、監査ログ、再発防止を記録する。
つまりハーネスは、AIを縛るものではない。AIに業務を任せるための条件である。ハーネスが弱い組織ほど、自律性を広げられない。ハーネスが強い組織ほど、どこまで任せてよいかを段階的に判断できる。
3. 企業AIエージェントの典型的な失敗
企業導入でよく起きる失敗は、モデルの幻覚だけではない。むしろ、もっと地味な失敗が多い。
第一に、目的のドリフトである。最初は請求書処理の補助だったAgentが、例外処理、催促、会計判断、顧客連絡まで引き受け始める。人間は便利なので止めない。しかし、どこから先が権限外なのか定義されていない。
第二に、記憶のドリフトである。古いルール、過去の暫定対応、特定顧客だけの例外が記憶に残り、新しい判断に混ざる。AIは文脈を持っているように見えるが、その文脈が現在も有効かどうかを知らない。
第三に、責任の空白である。AIが提案し、人間が承認し、別の部署が実行したとき、失敗の責任は誰にあるのか。AIベンダーなのか、承認者なのか、業務オーナーなのか、システム管理者なのか。ここが曖昧なまま本番化すると、事故が起きた時に誰も判断を前に進められない。
第四に、復旧経路の欠如である。AIが失敗した時、再実行すればよいのか、差し戻すのか、手動処理に切り替えるのか、顧客へ連絡するのか、ログを凍結するのかが決まっていない。失敗よりも、失敗後に組織が固まることの方が危険である。
第五に、監査証跡の不足である。AIがなぜその判断をしたのか、どのデータを見たのか、どのルールに従ったのか、誰が承認したのかが残っていない。これでは、成功している間は便利でも、トラブル時に説明できない。
4. LLMを替えても解決しない問題
モデル性能が上がれば、文章は自然になり、推論も改善し、ツール利用も安定する。これは事実である。しかし、次の問いにはモデルだけでは答えられない。
- このAgentは、どの業務目的のために動いているのか
- このツールを呼ぶ権限は誰から委譲されたのか
- この判断は、どの証拠が揃えば自動実行してよいのか
- どのリスク兆候が出たらfail-closedするのか
- 人間へ渡す時、どの文脈を渡すのか
- 失敗後に復旧してよい範囲はどこまでか
- 監査時に、判断の根拠を再現できるのか
これらはモデル選定ではなく、ハーネス設計の問いである。最新モデルを使っても、権限境界がなければ危険である。高精度RAGを使っても、古い情報と新しい情報の優先順位がなければ迷う。ツール呼び出しが正確でも、呼んではいけないタイミングを知らなければ事故になる。
企業AIエージェントの本番化とは、モデルを導入することではない。モデルが行動してよい条件を定義することである。
5. MARIA OSにおけるDynamic Harness
MARIA OSでは、ハーネスを静的なテストではなく、動的な運用レイヤーとして扱う。Dynamic Harnessは、Agent runtimeの状態を観測し、失敗兆候を分類し、必要に応じて自律性を下げ、人間承認へ渡し、復旧候補を生成する。
重要なのは、出力だけを見ないことである。AIの答えが正しく見えても、裏側で再試行が増え、参照データが揺れ、権限外ツールの呼び出しが増え、ユーザー修正が増えているなら、システムは不安定化している。Dynamic Harnessは、この軌道を見る。
MARIA OSのハーネスは、少なくとも6つの層を持つ。
- Goal Harness: Agentの目的が業務目的からズレていないかを見る
- Evidence Harness: 判断に必要な根拠が揃っているかを見る
- Authority Harness: 実行権限と禁止事項を確認する
- Quality Harness: 出力品質と再作業率を観測する
- Recovery Harness: 失敗時の復旧経路を選ぶ
- Responsibility Harness: 誰が判断を所有するかを残す
この構造があるから、自律性を段階的に広げられる。すべてを人間承認にするとAIの意味が薄い。すべてを自動実行にするとリスクが高い。重要なのは、リスクと証拠に応じて自律性を変えることである。
6. ハーネスがあると、AIエージェントの導入順序が変わる
ハーネスのない導入は、まずAgentを作り、その後に問題が起きたらガバナンスを足す。この順序は危ない。最初に便利さを見せてしまうため、現場は境界のない自動化に慣れてしまう。後から制限を入れると、導入が後退したように見える。
ハーネスのある導入は順序が逆である。まず対象業務をepisode化する。次に、目的、入力、出力、権限、停止条件、有人介入条件、監査項目を定義する。その上で、低リスクの範囲からAgentに任せる。実行ログを見て、安定した領域だけ自律性を広げる。
この導入順序では、AIは最初から万能に見えない。しかし本番化には強い。なぜなら、どこまで任せてよいかを組織が説明できるからである。
7. 事業責任者が見るべき指標
AIエージェントの導入効果を測る時、処理件数や削減時間だけを見ると不十分である。事業責任者は、次の指標を見るべきである。
- 自動実行率: どの範囲が人間なしで処理できているか
- HITL発火率: どの条件で人間介入が必要になっているか
- 再作業率: AI出力を人間がどれだけ修正しているか
- 権限逸脱未遂: 実行前に止めた危険なアクションがあるか
- 復旧成功率: 失敗後に正しい経路で戻せたか
- 監査再現率: 後から判断根拠を追えるか
特に重要なのは、HITL発火率の推移である。導入初期に高いのは自然である。問題は、同じ種類の用件でいつまでもHITLが下がらない場合である。それは、AIが学習していないか、業務ルールが曖昧なまま人間へ投げられている可能性がある。
逆に、HITL率が下がり、再作業率も下がり、監査再現率が維持されているなら、AIエージェントは現場知を運用資産に変え始めている。
8. 結論
AIエージェントが業務で失敗する理由は、LLMが少し賢くないからではない。多くの場合、ハーネスがないからである。目的を囲わず、権限を囲わず、記憶を検査せず、停止条件を決めず、復旧経路を設計せず、監査証跡を残さないまま、AIに行動させようとしている。
「AIエージェントとは何か」という記事は、もう多く存在する。ボンギンカンが書くべきなのは、「なぜ企業のAIエージェントはPoCで止まり、本番化できないのか」である。そして答えは、モデルではなく運用構造にある。
MARIA OSの価値は、AIエージェントを作ることだけではない。AIエージェントが失敗し、止まり、復旧し、人間へ渡り、証拠を残しながら、少しずつ自律範囲を広げられるOSを作ることにある。
これからの企業AI導入で差がつくのは、どのモデルを使っているかだけではない。どれだけ強いハーネスで、知能を業務に接続しているかである。