結論から書きます。業務AIが規模化しない原因は、モデルの性能不足ではなく設計の不在です。IBM Researchは、業務手順やルールをAIの外側に置いて誘導する構成に組み直すことで、トークン消費が最大30分の1、成功率が1桁台から80%超に改善したと報告しています。ただしこれは自社製品の提供者による発表です。
何が測られたのか（一次資料の実測）
IBM Researchが Hugging Face ブログ上で公開した寄稿記事「Beyond LLMs: Why Scalable Enterprise AI Adoption Depends on Agent Logic」に、複数業務での比較実測が並んでいます。共通する主張は一つで、LLMに全部を考えさせるのではなく、業務ルール・台帳・既存ツールといった従来型のソフトウェア部品でLLMの手順を固定する、という設計（記事では「エージェントロジック」と呼ばれています）を入れると、コストと精度が同時に改善するというものです。
報告されている数字を、条件つきで並べます。
| 業務領域 | 報告された結果 | 比較条件（記事の記載） |
|---|---|---|
| レガシーコード解析 | トークン消費 約30分の1 | LLM単体（LLM-only）ベースラインとの比較。対象は最大100万行・1,000プログラム規模のシステム |
| テスト自動生成（Aster） | コードカバレッジ +20%〜45% | 75本以上のJavaアプリケーションが対象。1アプリあたり最大560クラス超・6.7万行超 |
| テスト自動生成（Aster） | トークン使用量 最大15分の1 | 同上（75本以上のJavaアプリ、LLM単体比） |
| インシデント対応 | 性能 4.0倍 | ReAct方式のエージェントをベースラインとした比較 |
| インシデント対応（新しいモデルの比較エージェント） | トークン1.6倍消費・性能17%低下 | 同タスクでの比較。詳細なモデル名・試行数は記載なし |
| コンプライアンス自動化 | 性能 1.3〜2.0倍 | 従来型エージェントとの比較。n数・期間は記載なし |
| コンプライアンス自動化 | 成功率 1桁台 → 最大80%超 | 従来手法からの改善幅。タスク件数・期間は記載なし |
| 医療ポリシー適用 | 精度 15%〜26%改善 | 複数のモデルファミリーにまたがって計測。具体的なモデル名・n数は記載なし |
| 設備保全 | 所要時間 97%削減（15〜20分 → 15〜30秒） | 1件あたりの処理時間比較。件数・期間は記載なし |
| 設備保全 | 根拠のない主張（unsupported claims）57%削減 | 同タスクでの比較。ベースラインの詳細は記載なし |
| 設備保全 | トークン使用量 77%削減 | 同上。ベースライン詳細は記載なし |
（出典：IBM Research（Hugging Face ブログ上の寄稿記事、2026年6月1日公開）、2026-06-01、https://huggingface.co/blog/ibm-research/agent-logic-and-scalable-ai-adoption）
読む前に押さえるべき前提があります。この記事は IBM Research 自身による発表であり、同社は本文中で言及される製品（watsonx Code Assistant for Z、IBM Concert、IBM Sovereign Core、IBM Maximo Condition Insights）の提供者です。つまり「エージェントロジックを組み込んだ製品が有効だ」という結論が出ることに利害関係のある発信元が、自ら測って自ら公開した数字です。数字を頭から疑えという意味ではなく、ベースラインの取り方や条件の選び方に都合のよさが入り込んでいないかを、読む側が自分で確かめる必要がある、という意味です。
読者への意味：投資すべきはモデルのグレードではない
中小企業の経営者・情報システム担当にとって、この報告が持つ実務的な意味は明快です。AI導入の予算を「より高性能なモデルの利用料」に投じるのではなく、「自社の業務手順とデータ構造の言語化」に投じたほうが効く可能性が高い、ということです。
理由は数字の構造にあります。ここで報告されている改善は、いずれもモデルを賢くしたことによるものではありません。モデルは同じか、むしろ据え置きのまま、その外側に手順・ルール・既存ツールを配置して「どの順番で、何を見て、何をしてはいけないか」を固定した結果として出ています。
中小企業でよくある失敗は、次の形を取ります。
- 高性能モデルに社内資料をまとめて投げ、「いい感じにやって」と頼む
- 精度が出ないので、さらに情報を追加投入する。プロンプトが肥大化する
- 結果としてトークン代だけが積み上がり、精度は横ばいのまま止まる
この記事の数字は、その逆の順序を示しています。先に手順を固定し、AIに渡す前の段階で情報を絞り、判断の分岐は従来型のプログラムやルールで処理する。AIには「その工程でしかできないこと」だけを任せる。同じ作業でトークンが15分の1から30分の1になるのは、AIに考えさせる範囲をそこまで削れた、ということです。
つまり社内でまずやるべきは、AIの選定ではなく業務の棚卸しです。誰がどの台帳を見て、どういう条件でどう判断しているのか。それを文章と表に落とせているかどうかが、そのままAI化の可否と費用を決めます。最初の一歩の踏み方は 中小企業のAI導入、最初の一歩 に、AIの外側でどう手順を組むかという発想は 業務ワークフローを自動化する に整理しています。
「新しいモデルに替えれば良くなる」は成り立つのか
この記事の中でもっとも実務に効く数字は、実は最大の改善幅ではありません。より新しいモデルを使った比較エージェントが、トークンを1.6倍消費したうえで性能が17%低下したという結果のほうです（インシデント対応タスクでの比較。詳細なモデル名・試行数は記載なし）。
これが示すのは、モデルの更新がそのまま業務性能の改善にはならない、ということです。ベンチマーク上で強いモデルが、自社の業務手順のなかで強いとは限りません。手順やプロンプトが以前のモデルの癖に合わせて調整されていれば、差し替えた瞬間に噛み合わなくなることもあります。
社内での運用ルールとして、次の3点を決めておく価値があります。
- モデルを切り替える前に、実際の業務データで旧構成と新構成を同じ条件で比較する
- 比較の指標は精度だけでなく、1件あたりのトークン消費と所要時間も必ず並べる
- 提供元から「新モデルへの移行推奨」の案内が来ても、比較結果が出るまでは既存構成を維持する
「新しいほうが良いとは限らない」という論点は 新しいモデルが同じ優位を保つとは限らない でも扱っています。自社の業務に合わせた評価軸の作り方は 自社の評価基準を持つ を参照してください。
この数字が当てはまらない範囲
誠実に書いておくべき限界があります。まず、本文中に発信元自身が認める限界や不都合な結果の明示的な記述はありません。成果はいずれも検証済みのものとして提示されています。技術記事としては珍しいことではありませんが、読む側は「限界が書かれていない」こと自体を情報として扱うべきです。
そのうえで、この記事の数字を自社に当てはめる際に注意すべき点を挙げます。
- 数値の多くは、ベースラインの定義、試行回数、評価期間が本文に明記されていません。第三者による再現・検証は困難です。「成功率1桁台から80%超」も、何件のタスクをどの期間測ったのかは書かれていません
- 唯一の不都合な結果である「新しいモデルでトークン1.6倍・性能17%低下」も、自社手法の優位を補強する文脈で提示されており、中立な失敗報告として書かれたものではありません
- 評価対象がレガシーCOBOL資産、最大100万行規模のシステム、6.7万行超のJavaアプリ、企業インフラ運用といった大企業前提のワークロードです。中小企業の業務規模にそのまま当てはまる保証はありません
- 特に「トークン30分の1」は、対象が100万行規模のコード解析だからこそ削減幅が大きく出ている面があります。もともと投入情報量が少ない業務では、同じ比率の削減は期待できません
比率で示された改善は、分母が大きいほど見栄えがします。自社に当てはめるときは、比率ではなく「1件あたり何円が何円になるか」に置き換えて考えるのが安全です。
TOEの読み筋
先に明記します。TOEでは、この記事で紹介されているIBMの製品群（watsonx Code Assistant for Z、IBM Concert、IBM Sovereign Core、IBM Maximo Condition Insights）はいずれも未検証・未実施です。以下は記事の内容と、TOEがこれまで自社およびクライアント業務でAIを組んできた経験からの読み筋であって、検証結果ではありません。
そのうえで、この記事の主張はTOEの実感と一致します。AI導入の成否を分けるのは、ほぼ常にAIの外側です。業務手順が言語化されておらず、台帳がスプレッドシートの中で人によって書式が違い、判断基準が担当者の頭の中にしかない。この状態でどれだけ高性能なモデルを持ってきても、AIは毎回ゼロから状況を推測することになり、トークンを食い、そして外します。
だからTOEがクライアントに最初に提案するのは、モデルの選定ではなく手順の書き出しです。地味で、成果が見えにくく、社内の合意も取りにくい工程ですが、ここを飛ばした案件はほぼ例外なく「使われないAI」になります。
もう一点、この記事から中小企業が持ち帰るべきは、AIに全部やらせない設計が正解になりうるという発想の転換です。条件分岐は if 文で書けばよく、台帳の検索はSQLで足り、フォーマット変換はスクリプトで済みます。AIが必要なのは、自然言語の解釈と、決まった型に落とせない判断の部分だけです。この切り分けができると、コストは桁で下がり、動作は安定し、何が起きたか説明できるようになります。
なお、TOEはこの記事の数字を検証していません。自社で同種の構成を組んだ場合に30分の1や80%超が再現するかは不明です。実務で確かめるなら、1業務・1か月・件数を数えられる範囲から始めて、自社の数字を自分で取ることをおすすめします。
まとめ
- IBM Researchは、業務ルールや既存ツールでLLMを誘導する設計により、トークン消費が最大30分の1（100万行規模のコード解析、LLM単体比）、コンプライアンス自動化の成功率が1桁台から最大80%超に改善したと報告している
- この記事は IBM Research 自身による発表であり、同社は本文中で言及される製品の提供者である。利害関係のある発信元による数字だという前提を持って読む必要がある
- 数値の多くはベースラインの定義・試行回数・評価期間が明記されておらず、第三者による再現・検証は困難。評価対象も大企業前提の大規模ワークロードで、中小企業にそのまま当てはまる保証はない
- 「新しいモデルの比較エージェントがトークン1.6倍・性能17%低下」という結果は、モデル更新が自動的に改善を意味しないことを示す。切り替え前の同条件比較を社内ルールにする根拠になる
- 中小企業が投資すべきはモデルのグレードではなく、業務手順とデータ構造の言語化、およびAIに渡す前の前処理。なおTOEでは本記事の製品群はいずれも未検証・未実施であり、上記は読み筋である