AI開発2026-03-23

AIエージェント開発の現場から見えた「動くもの」の条件

株式会社Atsumell|10分で読めます

「AIエージェント、やりたいんですけど」

最近、この相談が急に増えた。

DX推進の担当者、情シスのマネージャー、時にはCTOから直接。「AIエージェントで業務を自動化したい」「チャットボットの次のステップとして検討している」——言葉は様々だが、共通しているのは「何かすごいことができそうだけど、何から始めればいいかわからない」という戸惑いだ。

無理もない。2026年に入ってから、AIエージェントを取り巻く状況は一変した。Gartnerは「企業アプリの40%にタスク特化型AIエージェントが組み込まれる」と予測し、NVIDIAはオープンソースのAgent Toolkitを公開した。NISTはAIエージェントの標準化イニシアチブを立ち上げた。毎週のように「エージェントAI元年」という見出しが踊る。

だが、同じGartnerがこうも言っている。「2027年までに、AIエージェントプロジェクトの40%以上が頓挫する」と。

技術が足りないからではない。本番環境で運用するための設計が足りないからだ。

では、「動くAIエージェント」と「動かないAIエージェント」の差はどこにあるのか。受託開発の現場で実際にエージェントを構築してきた経験から、見えてきたことを書く。

失敗パターン：「何でもできるエージェント」を目指す

最もよくある失敗パターンがこれだ。

「せっかくAIを入れるなら、いろんなことをやらせたい」。その気持ちはわかる。だが、スコープを広げれば広げるほど、エージェントの信頼性は下がる。

トヨタ自動車の事例が示唆的だ。同社は過去30年分の技術文書を学習させ、約800人のエンジニアをサポートするAIシステムを構築した。ただし、1つの万能エージェントではない。9つの専門エージェントに分割し、それぞれが特定領域を担当する設計にしている。結果、技術検討にかかる時間が平均40%短縮された。

ポイントは「分割」だ。1つのエージェントに全部やらせようとすると、プロンプトは肥大化し、コンテキストは汚染され、エッジケースが爆発する。各エージェントの責務を明確にし、得意なことだけをやらせる。これはソフトウェアの「単一責任原則」そのものだ。

実際、ForresterもGartnerも2026年をマルチエージェントシステムのブレークスルー年と位置づけている。単体エージェントの性能向上ではなく、専門エージェントの協調こそが本番環境のカギだという認識が広がっている。

本番で動くエージェントの3つの設計原則

原則1: 人間の判断ポイントを設計に組み込む

「全自動」は魅力的に聞こえるが、本番で求められるのは「適切なタイミングで人間が介入できる設計」だ。

サイバーエージェントグループのAI Shiftが開発した「AI Worker」は、カスタマーサポートの一次対応を自律的に処理する。だが、すべてを自動化しているわけではない。問い合わせの種類や顧客の感情スコアに応じて、人間のオペレーターにエスカレーションする仕組みが組み込まれている。

この「ヒューマン・イン・ザ・ループ」は妥協ではない。むしろ、本番運用に耐えるための設計上の意思決定だ。

私たちの経験でも、承認フローを組み込んだエージェントは導入がスムーズだった。例えば、営業支援エージェントで「メール下書きの自動作成→人間が確認→送信」というフローにするだけで、現場の抵抗感が大幅に減る。「AIが勝手にメールを送った」という事故を防げるし、営業担当者は「自分がコントロールしている」と感じられる。

原則2: 失敗を前提に設計する

AIエージェントは間違える。これは前提だ。

問題は「間違えること」ではなく、「間違えた時に何が起きるか」を設計していないことだ。Kore.aiの調査によれば、エージェントプロジェクトが頓挫する主因は小さなエラーが複数ステップで累積することにある。1ステップの精度が95%でも、5ステップ連続すると信頼度は77%まで落ちる。10ステップなら60%だ。

対策はシンプルだが地味だ。

各ステップの出力を検証するチェックポイントを入れる
失敗時のリトライとグレースフルデグラデーションを実装する
監査ログをすべてのアクションに残す

野村総合研究所はAI活用で開発生産性を大幅に向上させ、直近四半期の営業利益率が約20%に急上昇した。だが、この成果の裏にはAIの出力を人間がレビューする厳格なプロセスがある。AIが生成したコードを盲目的に本番に入れているわけではない。

原則3: 「何を自動化するか」の選定が9割

ヘッドウォータースはGitHub Copilot Coding Agentなどを活用した「AI駆動開発サービス」で、開発効率30%以上の改善を報告している。だが、この数字が出たのは適切な業務を選んでいるからだ。

AIで自動化すべき業務、すべきでない業務でも書いたが、AIエージェントに向いているのは以下の条件を満たす業務だ。

手順が明確で、判断基準を言語化できる
繰り返し頻度が高い（週に何十回も発生する）
失敗した時のリカバリーコストが低い
入出力のフォーマットが安定している

逆に「毎回状況が違う」「正解が曖昧」「間違えたら取り返しがつかない」業務にAIエージェントを入れると、運用コストが開発コストを上回る。

PwCの調査では、AI導入で「期待を上回る効果を得た」企業はまだ少数派だ。だが、成功している企業には共通点がある。2〜3の高価値ユースケースに絞って、明確なKPIで効果を測定している。十数個のPoCを並行して走らせるより、1つの業務を確実に自動化するほうが成果は出る。

日本企業がAIエージェントで勝てる領域

「AIエージェント＝アメリカのビッグテックの領域」と思われがちだが、実はそうでもない。

日経新聞のレポートでは「特定領域向けのAIエージェントであれば、日本の商習慣を知る日本企業が国内市場では優位」と指摘されている。確かに、汎用的なLLMの開発ではGoogleやOpenAIにかなわない。だが、日本の商習慣に特化した業務エージェントであれば、ドメイン知識が最大の参入障壁になる。

製造業の品質管理、金融の規制対応、SIerの要件定義プロセス——これらは日本独自の商慣習やルールが深く絡んでいる。海外のSaaSでは対応しきれない。

富士通はある電材メーカーと組んで、国内外18工場・49システムの情報を統合するAIエージェントを構築した。こういう「複雑な既存システムの間をつなぐ」仕事は、日本のSIerが長年やってきたことだ。AIエージェントの時代になっても、システムの間を理解し、業務フローを設計できる力は変わらず求められる。

受託開発でAIエージェントを作る時のリアル

正直なところ、AIエージェント開発の受託は従来のシステム開発とは勝手が違う。

見積もりが難しい。LLMの出力は非決定的だから、「この機能を作るのにX人月」と言い切れない。精度チューニングにどれだけ時間がかかるか、やってみないとわからない部分がある。

テストの考え方が変わる。従来の「入力Aに対して出力Bが返ること」というテストでは不十分だ。LLMの出力は毎回微妙に異なるから、「許容範囲内の出力であること」を検証する設計が必要になる。仕様駆動開発（SDD）の考え方が活きるのはこういう場面で、仕様で「振る舞いの境界」を定義しておけば、非決定的な出力でも品質を担保できる。

コスト設計が重要。LLMのAPI呼び出しは従量課金だ。エージェントの設計によっては、1回のタスク完了に数十回のAPI呼び出しが発生する。本番トラフィックを想定したコストシミュレーションなしに開発を始めると、「動くけど採算が合わない」システムができあがる。Databricksのレポートでも、2026年のトレンドとしてエージェントのコスト最適化がアーキテクチャ設計の一級市民になったと指摘されている。