一言で言うと
大規模言語モデル（LLM: Large Language Model）の性能向上ではなく、LLMに渡す情報を業務ロジックで絞り込む設計が、コスト・精度の両方を改善する近道です。IBM Researchはこれを「エージェントロジック」と名付け、社内5業務の計測結果を根拠として示しています。
先に理解しておくこと
多くの企業向けAIは、社内マニュアル・コード・ログをまとめてAIに渡し、「この中から答えて」と頼む形に近いです。資料が増えるほど、AIの利用料（トークン）も上がり、関係のない情報に引っ張られて答えがぶれやすくなります。
IBMが「エージェントロジック」と呼んでいるのは、その逆の設計です。AIそのものを賢くするのではなく、AIに渡す前に、見るべき情報だけを選び抜く層を別途用意する、という考え方です。
たとえば新入社員に初日、全社の資料庫を丸ごと渡すのではなく、先輩が「この案件では、このチェックリストと、この3フォルダだけ見て」と渡す——その「先輩の仕事」をソフトウェアが担うイメージに近いです。記事で挙がる3つの手段は、業務ごとに組み合わせが変わります。
- 知識グラフ — 部品・システム・規則のつながりを地図のように整理したもの。記事での例：サーバー障害がどのアプリに波及するか、を先にたどる。
- プログラム分析 — 古いプログラムの構造を機械が読み取り、関連部分だけを抜き出す仕組み。記事での例：何百万行もあるCOBOLから、質問に関係する箇所だけを渡す。
- アルゴリズム（ここでの意味） — 「次に何を調べるか」を決める手順・ルール。記事での例：コンプライアンスで「規制A→対策Bの順で確認」と順番を固定する。
大規模言語モデル（LLM: Large Language Model）は、この絞り込まれた材料をもとに文章化・判断する役割に徹します。だから「モデルを入れ替えなくても、渡す情報の設計を変えるだけで精度が上がり、コストが下がった」という結果が、5つの異なる業務で再現された、とIBMは説明しています。
何が起きているのか
IBM ResearchはHugging Face Blogで、エンタープライズ（大企業・組織向け）AI導入の壁を、LLM単体では超えられない理由と、その解決策として論じる記事を公開しました。記事の骨子は、上記「先に理解しておくこと」で述べたエージェントロジック——IBMの用語では、知識グラフ・プログラム分析・アルゴリズムなどのプリミティブ（基本的な構成部品）をエージェント層に載せ、LLMに渡す文脈を絞って業務目標へ誘導する設計——を、社内の6事例で数値化したものです。
以下、業務ごとに「何に困っていたか」「何をしたか」「どう変わったか」の順で整理します。いずれもベースライン（比較の基準）として「エージェントロジックなしでLLMや汎用エージェントだけ使った場合」との対比が記載されています。
ユースケース1: レガシーコード理解（IBM watsonx Code Assistant for Z）
- 課題: 金融機関などが抱えるレガシーコード（何十年も前から動いている古いプログラム）。COBOL・PL/1といった言語で書かれた資産は、全体が100万行を超え、プログラム数も1,000を超える規模があり、AIに丸ごと読ませるとコストも精度も破綻しやすい。
- やったこと: プログラム分析で「この質問に関係する箇所だけ」を機械的に抜き出し、あわせてDBスキーマ（データベースの設計図）を事前にインデックス化（検索しやすい形に整理）してエージェントロジックに載せた。LLMにはその抜粋だけを渡す。
- 使ったモデル: Mistral Medium 250B。
- 結果: トークン消費が約30分の1。同じ規模のコードでも、「全部渡す」のではなく「関係部分だけ渡す」設計の効果が最も分かりやすい例。
ユースケース2: テスト自動生成（Asterライブラリ）
- 課題: Javaアプリに対するテスト（動作確認用のプログラム）の自動作成。コード量が多いほど、AIが無関係な部分まで読み込み、品質の低いテストや高コストになりがち。
- やったこと: IBM社内のAsterライブラリでプログラム分析と前後処理（AIの前後でデータを整形する処理）を組み、テスト対象の「行・分岐・メソッド」（プログラムの通り道と関数単位）に絞ってからLLMに渡した。
- 使ったモデル: Devstral 24B。75件以上のアプリ（最大560クラス・67,000行超）で検証。
- 結果: カバレッジ（テストがコードのどれだけを踏んでいるか）が20〜45%向上。最先端のコーディングエージェント（コードを書くAIエージェント）と比べても、トークンは最大15分の1。
ユースケース3: インシデント対応（IBM Concertプラットフォーム）
- 課題: システム障害（インシデント）が起きたとき、原因のサーバー・アプリ・ログをたどる作業。情報が散らばっており、AIに全部渡すと調査が遅く、コストも膨らむ。
- やったこと: 知識グラフで障害の波及関係を地図化し、プログラム分析で関連コードを絞り、観測データ（監視ツールのログなど）に基づくオーケストレーション（複数の調査ステップを順番に回す制御）を組み合わせた。
- 比較: 業界ベンチマークITBench上で、GPT-5.1を使ったReAct（「考える→ツールを使う」を繰り返す汎用エージェントの定番手法）より4.0倍改善。Gemini 3 Flashよりスコアは17%低いが、トークンは1.6分の1。
- 内訳: マイクロサービス（小さなサービスを組み合わせた構成）の原因特定は精度3.0倍・トークン3.7分の1。バグ修正は1.6倍・5.9分の1。
ユースケース4: ITコンプライアンス近代化（IBM Sovereign Core）
- 課題: 社内のコンプライアンス（法令・社内規程の遵守）管理。規制と対策の対応が16,000件以上あり、AIに「全部説明して」と頼むと成功率が一桁台にとどまった、と記事は述べています。
- やったこと: アルゴリズムで確認順序を固定し、適応型プランニング（状況に応じて次の調査を選ぶ仕組み）とワークフローオーケストレーション（承認や確認の流れを自動で回す）で、デジタル化されたコントロール対応表（どの規制にどの対策が紐づくかの一覧）を段階的にたどる設計にした。
- 使ったモデル: Claude 4 Sonnet。
- 結果: 複雑なシナリオの成功率が一桁台→80%超。従来型エージェント比で1.3〜2.0倍。「手順を先に決める」エージェントロジックが、法令系の業務で効いた例。
ケーススタディ1: 設定可能な汎用エージェント（CUGA）— 医療向け
- 課題: 医療分野では、AIの回答が社内規程や患者安全のルールから外れないことが必須。プロンプト（AIへの指示文）だけではルール違反を防ぎきれない場面がある。
- やったこと: ポリシー・アズ・コード（規則をプログラムとして書き、違反した回答を機械的に弾く手法）をエージェントロジックとして強制適用。LLMは「ルールを通過した範囲」だけで回答する。
- 使ったモデル: Claude Opus、GPT OSS 120B、GPT-4.1の3系統すべてで検証。
- 結果: 精度が15〜26%向上。ファインチューニング（モデル自体の再学習）もプロンプトの書き換えも不要——「渡す前のルール層」だけで改善した、とIBMは報告しています。
ケーススタディ2: 設備保全（IBM Maximo Condition Insights）
- 課題: 工場など120拠点・6,000件の物理設備の状態レビュー。従来は1件あたり15〜20分かかり、全体のカバレッジ（点検できた割合）は約1%にとどまっていた、と記事は述べています。
- やったこと: DAG（有向非巡回グラフ：処理の順序と依存関係を矢印で表した図）で「どのセンサー・どの部品を先に見るか」を固定し、構造化された証拠検証（回答ごとに根拠データを照合する仕組み）で、根拠のない推測を減らした。
- 使ったモデル: GPT OSS 120B。
- 結果: 分析時間が15〜20分→15〜30秒（約97%短縮）。カバレッジ約1%→約30%。根拠のない主張が57%減、トークンは平均77%削減。
AI業界の文脈では
LLMのコンテキストウィンドウ（一度に処理できる情報量）の拡大競争は続いています。しかしコンテキストウィンドウが広がるほどトークン消費が増え、コストと推論ループが肥大化する問題が実務で表面化しつつあります。IBMの言う「エージェントロジック」は、その問題への一つの答えです。
5月28日の朝版でOpenAIの税務AIを取り上げた際、「フィードバックループの構造化が先で、モデルの精度向上は後から来る」という視点を示しました。今回のIBMの論考は同じ方向の議論を、「モデルに渡す情報を事前に絞り込む設計層が先にある」という形で示したものと読めます。どちらも、LLMを賢くすることより「LLMに何をどう渡すか」の設計が企業AI導入の本質だという立場です。
IBMが強調するのは特定の手法ではなく、業務領域ごとに異なるプリミティブ（コード分析・知識グラフ・アルゴリズム）を使い分けることです。COBOL解析には静的プログラム分析、設備保全にはDAG、医療コンプライアンスにはポリシー・アズ・コードというように、業務の構造に合わせてエージェントロジックを設計することが重要とされています。
私の見立て
注目すべきは数字の大きさよりも、異なる5業務で同じアプローチが機能したという点だと考えます。COBOLのレガシーコード、Javaのテスト生成、ITインフラのインシデント対応、コンプライアンス管理、製造業の設備保全——これだけ異なる業務で一貫して「エージェントロジックで文脈を絞ると精度が上がりトークンが減る」という結果が出ていることは、特定技術の宣伝を超えた設計原則として受け取れます。
ただし留保も必要です。これらはIBM社内の評価であり、独立した第三者による再現検証は記事には示されていません。使用されているモデルもMistral・Devstral・GPT-5.1・Gemini 3 Flash・Claude 4 Sonnet・GPT OSS 120Bと複数あり、モデルとエージェントロジックのどちらが結果に寄与したかの切り分けは明示されていません。
それでも、エンタープライズAIを設計する立場から見ると、「まず業務の構造をプログラム分析や知識グラフで整理し、その出力をLLMに渡す」という設計順序は、汎用モデルに業務説明を全部プロンプトで詰め込む現在の主流アプローチとは異なる方向性です。
→ 何が変わるか: LLMの性能スコアよりも、「業務ロジックをどれだけ正確にエージェント層に実装できるか」がエンタープライズAI導入の成否を分ける評価軸として浮上してきます。コンテキストウィンドウの拡大はコスト増の問題を持ち込むことがあり、情報を絞り込む設計の価値が相対的に上がります。
→ 何をすべきか: 社内業務にAIを導入する際、汎用LLMにプロンプトで業務説明を詰め込む前に、業務の構造（判断ルール・依存関係・制約条件）をコードやグラフとして整理できる部分がないか確認することを勧めます。そのコストは初期に集中しますが、精度の安定とトークンコストの削減という形で後から回収できます。IBMの5事例はその判断材料になります。