AIエージェント構築事例11選｜国内外10社から学ぶ本番運用の設計原則

結論：本番運用の差は、LLMより周辺システムで生まれる

LINEヤフー、DeNA、LinkedIn、Spotify、Salesforceなどの事例は、より大きく自律的なエージェントへ一方向に進んでいるわけではありません。LLMに任せる判断を限定し、通常のプログラムで処理する部分、狭い責務を持つエージェント、必要最小限のツール、承認フロー、再実行できる評価基盤を組み合わせる方向へ収束しています。

優れたAIエージェントは、何でも自動で実行するシステムではありません。モデルが間違えることを前提に、行動を観測でき、危険な操作を止められ、問題を再現して修正できるシステムです。モデル名だけを比較するより、データ、権限、実行、評価、運用までを一つの設計として考える必要があります。

10社・11事例の比較から得られた5つの示唆

• マルチエージェントは目的ではなく、独立した責務へ分けられる業務で効果を発揮する
• 公開事例ではFine-tuningやLoRAを主役にせず、プロンプト、ツール、検索、実行制約、モデル切り替えを重視する例が多い
• 複数の事例で、モデルを呼ぶ前の絞り込みと不要なコンテキストの削減が品質とコストの両方に効いている
• 実行を伴う事例では、回答文だけでなく、選んだツール、引数、処理順序、最終状態の評価が重要になる
• 一部の成熟企業では、認証、ツール接続、メモリ、監視、評価を共通基盤化している

国内外10社・11件のAIエージェント構築事例を比較

調査対象は、目的に応じて推論や計画を行い、外部データやツールを参照・実行し、複数ステップの業務を進める仕組みです。単純なチャットボットではなく、これらの条件を複数備え、公式の技術ブログ、製品資料、開発者の発表などで構成や運用を確認できる事例を中心に比較しました。

公開されている情報の深さは企業ごとに異なります。モデル名やフレームワークが非公開の事例について、利用技術を推測で補ってはいません。また、成果の数値は各社が示した条件に限られるため、すべての業務へそのまま当てはまるものではありません。

国内事例：ワークフロー化、最小権限、既存業務への埋め込み

LINEヤフーのAgent iは、単体のエージェントよりも、企業全体で安全にエージェントを作り、接続し、運用する仕組みに重点を置いています。Agent Builder、Runtime、Catalog、MCP Hubをそろえ、認証、スキーマ検証、流量制御、ログ、再試行などを共通化しています。複雑な計画には大型モデル、単純な分類や変換には小型モデルというように、タスクに応じたモデルの切り替えも前提です。

DeNAのkintone承認事例は、予算、ツール名、法務確認という独立した判定を、Routerと3つの専門エージェントへ分けています。各エージェントには必要なツールだけを渡し、LLMを呼ぶ前に不要なWebhookを除外し、入力項目を減らしてYAMLへ変換しました。27件の評価では、正しくコメントを投稿していた7件が、最終回答の文面が異なるという理由だけで不合格判定となる問題が見つかり、評価の中心をツールの選択・順序・引数へ移しています。

同社のAI社員は、Slack上でDrive、Confluence、Jiraなどへ接続し、定期レポートや監視、チケット作成を行います。最初から書き込み権限を広く与えず、読み取り専用から始め、先行エージェントで観測してから全体へ展開する段階的な運用が特徴です。先行するBerryでは、2026年7月1日から10日までの8営業日で約52.6時間、1営業日当たり平均約6.6時間相当の作業削減が推計されています。

メルカリのIBISは、過去の障害情報を検索し、Slackで類似事例や対応案を示します。利用者が自分から呼び出すだけの仕組みでは使われにくかったため、障害発生時にエージェント側から提案する形へ発展しました。モデルの精度だけでなく、普段の業務フローへ自然に組み込むことが、現場で利用されるかどうかを左右する例です。

SORACOM AgentのTechnology Preview版では、SORACOMに接続されたリファレンスデバイスや蓄積データの分析・回答・制御を支援しています。遠隔制御など一部の機能は、対象機器やサービスの対応が前提です。この機能から導ける設計上の論点として、文章を生成するエージェント以上に権限境界と監査が重要です。NTT DATAは、複数案件で実行環境や監視を作り直さないよう、Bedrock AgentCoreとDatadogを用いたAgentOps構成の検証・標準化を進めています。どちらも、エージェントの価値がモデルだけでは決まらないことを示しています。

海外事例：既存の統制へ接続し、実行と評価を共通化

GitHub Copilot coding agentは、独立したGitHub Actions環境でリポジトリを調べ、コード変更、テスト、コミットを行い、成果をDraft Pull Requestへ着地させます。AI専用の承認制度を新設するのではなく、Pull Request、レビュー、CI、ブランチ保護という既存の統制を、変更・承認の境界として使う設計です。

Salesforceは、音声やチャットなどに分かれていた実行基盤をUnified Plannerへ統合し、自由なLLM推論と明示的な状態遷移を併用しています。検査、検索、コンテキスト収集など、依存関係のない処理を並列化することで、一部ケースでは約20秒から約2.3秒へ短縮したと公表しています。

LinkedIn Hiring Assistantは、長く複雑な採用業務を、計画を作る部分とツールを実行する部分に分けています。採用担当者ごとに独立したIDとメールボックスを持ち、会話、出来事、知識、手順を分けたメモリを利用します。vLLM上の推論最適化により、同一QPS・SLA上限の条件でスループットを約4倍に向上させ、P90のエンドツーエンド遅延を平均66％削減し、社内評価では品質低下がなかったと報告しています。

Spotify Ads AIは、広告目的、予算、対象者、日程などを専門エージェントへ分け、並列に解決します。Datadog Bits Investigationは、本番障害を再現できる評価環境を作り、毎週数万件のシナリオで変更の影響を確認します。前者は責務分解による速度と保守性、後者は本番データを使った継続評価の重要性を示す事例です。

マルチエージェントは、責務を明確に分けられるときだけ使う

エージェントの数を増やすこと自体が高度化ではありません。DeNAは予算、ツール名、法務へ、Spotifyは広告プランの構成要素へ責務を分けました。一方でLINEヤフーは、人が処理ノードを組み合わせ、順序と再現性を管理しやすいワークフロー型の仕組みを強化しています。

独立して並列処理できる仕事にはマルチエージェントが向きます。処理の順序、承認、再現性が重要な仕事には、明示的なワークフローと必要な箇所だけのLLM判断が向きます。分割の理由が曖昧なままエージェントを増やすと、トークン消費、状態同期、引き継ぎ失敗、調査すべきログが増え、品質の原因を切り分けにくくなります。

マルチエージェント化を検討できる条件

• 担当ごとに独立した責務とツールの範囲を定義できる
• 複数の処理を並列化することで待ち時間を減らせる
• 専門エージェントごとにテストデータと合格条件を用意できる
• 引き継ぎ時の情報欠落や失敗より、分割による効果が大きい

RAGより先に、その処理に必要なコンテキストを設計する

AIエージェントに必要な情報は、ベクトル検索だけではありません。メルカリはBigQueryのベクトル検索、GitHubはCode Search、SpotifyはPostgreSQLの構造化データ、LinkedInは採用データと複数種類のメモリを使っています。DeNAはkintoneの不要項目を削り、簡潔な形式に変えてからモデルへ渡しました。

重要なのは、各ステップで必要な情報だけを、信頼できる情報源から、少ない量で渡すことです。文書があるからすべて埋め込み検索へ入れる、コンテキスト上限が大きいから全部渡す、という方法では、不要な情報が推論を悪化させることがあります。Datadogも、ある機能向けに情報を増やした結果、別種類の障害調査が悪化した経験を公表しています。

コスト対策も、安いモデルへ交換することから始めるとは限りません。まず不要なモデル呼び出しをなくし、入力を減らし、ツール結果をキャッシュし、独立処理を並列化します。そのうえでタスク別のモデル切り替えや推論基盤の最適化を検討すると、品質を保ちながら成功1タスク当たりの費用を下げやすくなります。

セキュリティは、プロンプトよりツール権限で守る

システムプロンプトに「危険な操作をしない」と書くだけでは、誤判断やプロンプトインジェクションを防ぎ切れません。重要なのは、エージェントが実行できる行為を狭く定義し、認証、対象データ、操作範囲、引数、回数を実行層で検証することです。汎用的なデータベース操作を渡すより、「申請を検索する」「下書きコメントを作る」のように業務能力を限定したツールにします。

読み取り、提案、下書き、承認、実行を段階に分け、操作の影響に応じて人間を介在させます。すべてを承認制にすると自動化の価値が下がり、すべてを自動にすると事故時の影響が大きくなるため、一律ではなくリスクで決めます。

評価は「正しい文章」ではなく「正しい行動」を測る

外部ツールを使うエージェントでは、最後の回答文が本当の成果物とは限りません。DeNAの事例では、kintoneへのコメント投稿は成功しているのに、最終文面の揺れだけで不合格になるケースがありました。回答の一致率だけでなく、適切なツールを正しい順番・引数で呼び、望む状態に到達したかを評価する必要があります。

さらに、本番で起きた失敗を匿名化・分類し、同じ条件を再現できる評価データへ戻します。モデル、プロンプト、検索、ツール、ワークフローを変更するたびに同じシナリオを実行し、平均点だけでなく、業務、部署、言語、ツール、リスク別に悪化がないかを確認します。

最初のAIエージェントは、1業務・少数ツールから始める

最初に「AIエージェントを作る」と決めるのではなく、対象業務を、開始条件、情報収集、判断、実行、確認へ分解します。条件を通常のプログラムで書ける処理はそのまま残し、曖昧な分類、探索、計画、自然言語の理解など、LLMが必要な部分だけをエージェントにします。

初期構成の一つの目安は、入力の決定論的な検証、1つのエージェント、3〜5個の限定ツール、リスクに応じた人間承認です。最初から多数のエージェント、長期メモリ、大規模な検索基盤、Fine-tuningを同時に入れると、問題がモデル、データ、プロンプト、ツール、引き継ぎのどこにあるかを判別しにくくなります。

候補業務には、件数が多く、入力と成果物を観測でき、失敗時に元へ戻せ、人間による過去の判断データがある仕事が向きます。2〜3件の本番ユースケースを一つの目安として、共通の課題が見えた段階で、モデル接続、ツール認証、メモリ、監視、評価、エージェント台帳を共通サービスへ切り出します。

企画・設計時に確認したい10項目

AIエージェントの企画書やPoC要件では、モデル名だけでなく、対象業務、許可する行動、評価、運用責任までを同じ文書で決めます。次の項目が曖昧なまま開発へ進むと、動くデモはできても、本番導入の判断ができません。

本番を見据えた設計チェックリスト

• 対象業務を開始条件、情報収集、判断、実行、確認へ分解したか
• 通常のプログラムで処理する部分と、LLMに判断させる部分を分けたか
• 各ステップの情報源、更新頻度、最大コンテキスト量を決めたか
• ツールを最小権限にし、読み取りと書き込みを分離したか
• 高リスク操作の承認者、停止条件、元に戻す方法を決めたか
• タスク完了、ツール選択、引数、安全性、費用の評価データを用意したか
• モデル、プロンプト、検索結果、ツール実行、最終状態を追跡できるか
• 本番で発生した失敗を再現テストへ戻す運用を決めたか
• モデルを交換しても業務ロジック全体を作り直さない構成か
• 成功1タスク当たり費用と、人の作業削減や売上への効果を測れるか

まとめ：最も自律的ではなく、最も安全に改善できる仕組みを選ぶ

国内外10社・11事例から見えるのは、AIエージェントの競争力がモデルの賢さだけでは決まらないということです。必要な情報を適切な量で渡し、狭い権限のツールを使わせ、重要な操作は人が承認し、行動の結果を継続評価できることが本番運用の土台になります。

まずは1業務、1エージェント、少数ツールで価値とリスクを確認します。責務が明確になれば専門エージェントへ分け、複数の本番事例で重複する課題が見えればAgentOps基盤へ共通化します。この順序なら、将来モデルが変わっても、業務知識、ツール、権限、評価データを自社の資産として残せます。

調査方法と数値の見方

本記事は、2026年9月2日時点で公開されていた企業の公式Engineering Blog、公式技術・製品資料、開発者の発表などの一次情報を中心に、LINEヤフー、DeNA、メルカリ、ソラコム、NTT DATA、GitHub、Salesforce、LinkedIn、Spotify、Datadogの10社・11事例を比較した調査資料を再構成したものです。

公開情報には偏りがあり、モデルやフレームワークは公開されやすい一方、GPU、推論単価、SLA、トークン数、データ容量、秘密情報管理、プロンプト全文、Fine-tuningデータなどは多くが非公開です。非公開の項目を推定で補わず、各社の数値には「一部ケース」「最大」「推計」「同一QPS・SLA条件」など、公表時の前提を付けています。導入計画では、自社の業務データと条件で改めて評価してください。

構成や数値を確認した主な公式情報・開発者資料は以下の通りです。

• LINEヤフー「Tech-Verse 2026」Keynote
• LINEヤフー「Agent iを支えるAIエージェント基盤」
• DeNA「ADKマルチエージェントでkintone承認を自動化した設計と自動評価」
• DeNA「果物の名を持つAI社員たちと、その実装の裏側」
• メルカリIBIS開発者「これからのSREとメルカリIBISの挑戦」
• ソラコム「SORACOM Agentを提供開始」
• Datadog「Lessons from NTT DATA」
• GitHub「Meet the new coding agent」
• Salesforce Engineering「Inside Unified Planner」
• LinkedIn Engineering「How we engineered Hiring Assistant」
• LinkedIn Engineering「Accelerating LLM inference with speculative decoding」
• Spotify Engineering「Our Multi-Agent Architecture for Smarter Advertising」
• Datadog「Evaluation platform for autonomous SRE agents」
• Datadog「How we built an AI SRE agent」