AIエージェント導入の「期待と現実のギャップ」──ハーネス設計とデータ基盤が本番の壁になる
2025年はAIエージェントへの期待が最高潮に達した年だったが、本番導入フェーズに踏み込んだ企業の多くが深刻なギャップに直面した──そう総括するOracle Developer Day 2026の基調講演レポートは、私が日常業務で感じていることと重なる部分が多い。
出典: 2026年のAI×エンジニアリング──エンジニアはビジネスロジックを設計する役割へ？ AIがもたらすエンジニアの未来 2026
要点 (事実のみ)
- ジェネラティブエージェンツ西見公宏氏は「会社が求める内容と、AIエージェントができること・配備に必要な検討事項の間に非常に大きな開きがある」と指摘
- LLM単体は推論エンジンに過ぎず、外部ツール・メモリ・API連携などを周辺機能として設計する「ハーネスエンジニアリング」が本格活用の鍵とされる
- AI駆動開発では、コーディング・設計書作成が高速化する一方、意思決定・合意形成・仕様すり合わせの時間比率が「圧倒的に増える」（吉田真吾氏）
- MVP段階で問題なく動いたエージェントも全社展開でハルシネーションが頻発した原因は、AIの推論能力ではなくデータリネージ未整備にあったと分析
- AIの自律度は「Human-in-the-loop → Human-on-the-loop → Human-out-the-loop」へ進化するが、吉田氏は「人間の関与がゼロになることはあり得ない」と断言
- 2026年のキーワードとして「パーソナルエージェント」の普及とISO/IEC 42001対応が必須要件化することが挙げられた
徐 聖博の見解
この記事が指摘する「期待と現実のギャップ」は、私が受託開発やAIエージェントのPoC支援で実際に向き合っている問題そのものだ。
特に共感するのが、ハルシネーションの根本原因をAIの推論能力に帰属させるのではなく、データリネージの未整備に求めている点だ。私自身、Indeed JapanやXincereでのML運用経験を通じて、「モデルが悪い」と言われるケースの多くは上流のデータパイプラインに問題があると何度も確認している。エージェントが増えれば増えるほど、コンテキストの品質がシステム全体の信頼性を左右する。データ基盤の整備はAI導入よりも地味で時間がかかるが、これを後回しにするとスケール時に必ず破綻する。
「ハーネスエンジニアリング」という概念についても、実装者として重要だと感じる。Claude CodeやCodexはハーネスが完成品として組み込まれているから使えるのであって、企業固有の業務システムに組み込むには同等の設計思想を自分たちで作り込む必要がある。エージェントの自律性が高まるほど、ハーネスの設計ミスが与えるダメージも大きくなる。これは、PoC段階でそれなりに動いた理由と、本番で壊れた理由が一致する構造だ。
発注側・中小企業の視点で言えば、「AIを入れたい」という要望が「Howから始まっている」ケースは今もよく見かける。何の業務課題をどの指標で改善するか──このWhatが定義されないまま動くと、ベンダーも開発者も悪意がなくても失敗プロジェクトが生まれる。「汝、いかなる手作業をやめよ」という登壇者の言葉は刺激的だが、前提として業務プロセスを理解している人間がゼロベースで設計に関与しないと、AIに置き換えるべき手作業すら正しく特定できない。
エンジニアの役割が「コーディング」から「ビジネスロジックの設計」へシフトするという論点は、実装者として正確だと思う。ただし、これは「コードを書かなくてよくなる」ではなく、「何を書くべきかを判断する能力」がより直接的に問われるようになるという意味だ。設計意図を持てない人間がAIに指示を出しても、出てくるコードは偶然の産物に近い。
(編集レンズ: 実装・運用視点 / 発注側・中小企業への含意)
