LINEヤフーでは、ユーザーの目的に応じてさまざまなサービスや機能をつなぐAIエージェントサービス「Agent i」の開発を進めています。
Agent iで多様なニーズに応えるには、現場のアイデアを素早くAIエージェントとして形にできることに加え、作られたエージェントを安全かつ安定的に本番環境で動かせることが必要です。
そこで私たちは、エンジニアでなくてもノーコードでワークフローを構築できる「Agent Builder」と、公開されたワークフローをサービスの負荷に応じて実行する「Agent Runtime」を内製化しました。
本記事では、当初目指していたマルチエージェント構想から、なぜ「まずエージェントを作れる基盤が必要だ」という結論に至ったのか、そして作りやすさと本番運用の要件をどのような設計で両立したのかを紹介します。
AIエージェント領域への方針転換
私たちのチームはもともと別のAI領域で開発に取り組んでいました。そうした中、LLM (Large Language Model)の急速な進歩によって、AIエージェントを活用したサービス開発の可能性が大きく広がりました。より大きな事業成長を見込み、AIエージェント領域への新たなチャレンジをすることになりました。
方針を転換した時点では、具体的に何を作り、どのように進めるかまでは決まっていませんでした。最初に取り組んだのはAIエージェントの普及によって生じる課題の整理です。
当初はAIエージェントが今後急速に増え、エージェント同士の連携が課題になると考えていました。その見立てから「マルチエージェント」を軸に据え、エージェント間連携を最初に解くべきテーマとして検討を進めました。
エージェントを増やせない理由
検討を進めるとマルチエージェントの前に解くべき課題が見えてきました。エージェント同士を連携させる以前に、一つひとつのエージェントを作ること自体が、まだ難しかったのです。
一つのエージェントを作るにはコードを書く必要があり、担い手がエンジニアに限られていました。加えて、処理の分岐や実行経路も把握しにくいため、設計の見通しが立ちにくくなります。作った後も、デプロイして動かすまでには手間がかかります。
エージェントを量産し、試行錯誤を高速に繰り返せる状態には至っていません。連携させるエージェントそのものを増やせなければ、マルチエージェントの活用も広がりません。
こうした状況を踏まえ、エージェント同士の連携はその先に取り組むものだと判断しました。先に作るべきだったのは、エージェントそのものを手軽に作ってすぐに試せる環境だったのです。
アイデアをエージェントとして形にするツール
私たちが目指したのは、AIエージェント開発に関われる人の幅を広げることです。現場で生まれたアイデアを自分たちですぐ試せれば、エンドユーザーに近い場所で検証と改善を重ねられます。この考えから、エンジニアだけでなく、ユーザーや事業に近い企画職や営業職も自らアイデアを形にできる環境を作ることにしました。
アイデアを試すたびにコードによる実装が必要になると、試行錯誤の速度を上げにくくなります。そのため、利用者自身がエージェントを構築できるノーコードのツールを目指しました。
そのうえで、使いやすさを優先するため、ツールが扱うユースケースを絞りました。複雑な制御や高度なカスタマイズは、引き続きエンジニアが担う設計としています。アイデアをまずは小さく動かせる形にし、汎用的な処理はほかのケースにも再利用しやすい設計を目指しました。
利用者の範囲とあわせて、このツールでどのようなエージェントを構築できるようにするかも検討しました。単一のエージェントにすべてを任せるのではなく、人が複数の処理を組み合わせて設計するワークフロー方式を採用しました。
利用者自身が処理の実行順序や条件を確認し、動作を制御しながら改善を重ねられることも大きな利点です。
この方式を実現するにあたり、類似サービスを参考に開発基盤に必要な要件を整理しました。その中で重視したのが、社内データへ安全に接続できることと、自社サービスの要件に合わせて継続的に拡張できることです。既存ツールをそのまま利用するだけでは両立が難しいと判断し、設計から実行までを自社で制御できるノーコードの開発基盤を内製化する方針としました。
エージェント開発基盤の仕組み
開発基盤は、エージェント開発ツールのAgent Builderと、エージェント実行基盤のAgent Runtimeで構成されています。
Agent Builderでは、社内の利用 者がワークフローを定義します。Agent Runtimeでは、定義されたワークフローを読み込み、処理量に応じてスケールしながら実行します。
Agent Builderの仕組み
Agent Builderでは、ノードとエッジを配置・接続し、ワークフローをノーコードで組み立てられるグラフ形式の編集画面を提供しています。LLMの処理や分岐、繰り返しを画面上で組み合わせ、テストから公開・デプロイまでを一貫して進められます。
編集画面にはReact Flowを採用し、ノードの配置や接続に加えて処理ごとの表示・設定画面も柔軟に組み込んでいます。
作成したワークフローから、後述する独自の中間表現（IR: Intermediate Representation）を生成し、構造や設定を検証したうえで保存します。検証では、到達可能性や接続関係をグラフ理論に基づいて確認します。問題があれば公開前に利用者へフィードバックし、構造上の不整合による実行時エラーを未然に防ぎます。さらに、Agent Builderでは、高度なLLM機能を画面上の操作に落とし込み、専門的な仕様を意識せず使えるようにしています。
リリース後は利用者からさまざまな改善要望が寄せられましたが、そのまますべてを機能に加えるわけではありません。幅広い利用者にとって意味がわかりやすく、誤った設定が起きにくいかを見極め、専門知識が必要な機能はユーザーインターフェースだけで設定できる形に落とし込んでいます。例えば、VerbosityやReasoning EffortといったLLMのAPIパラメータのうち、効果を理解しやすい項目は見つけやすい場所に配置し、モデル選択とあわせて処理ごとに調整できます。一方、Structured Outputsでは、画面上で設定した出力項目からJSON Schemaを自動生成し、専門的な記述なしで利用できるよう工夫しました。
Agent Runtimeの仕組み
Agent Runtimeには、公開されたワークフローをサービスの負荷に応じて安定して実行できるようにする役割があります。そのため、Kubernetes上でスケールし、高負荷時の安定性とリソース効率の両立を目指した構成です。
設計を実行へつなぐIR
ワークフローの設計時と実行時のデータ表現の違いは、共通モデルとなるIRで吸収します。Agent Runtimeは実行リクエストを受けると、Agent Builderで生成・検証されたIRを読み込み、LangGraphの実行グラフへ変換・コンパイルして実行します。LangGraphは条件分岐や繰り返し、ノード間の状態管理に対応しており、IRを実行グラフへ落とし込みやすいことから採用しました。
実行環境を分離するサンドボックス設計
また、Agent Runtimeの特徴の一つはKubernetes Namespaceを実行環境ごとに分離し、論理的なサンドボックスとして扱う構成です。
各環境では、ネットワークACL (Access Control List)で通信先を絞り、MCP (Model Context Protocol) Serverやドキュメント、内部APIなどへのアクセス可否も実行時に検証します。また、認証情報やAPIキーはワークフロー定義に含めず、必要なタイミングで取得し、社内データや外部サービスへ接続します。
さらに、Namespaceの分離によって、負荷も実行環境ごとに局所化できます。特定のワークフロー群にアクセスが集中しても影響をほかの環境へ広げにくくし、必要な範囲だけレプリカ数やリソース量を調整できます。これにより、負荷への耐性と平常時のコスト効率の両立を図っています。
負荷試験で見えた実行基盤のボトルネック
こうした構成を整える過程では、ファーストリリースに向けたQA (Quality Assurance)で安定性に関する課題が次々と見つかり、想定する最大負荷に耐えられるよう負荷試験を繰り返しました。検証を進める中で、CPUとメモリを見直した後、同時実行数に対応するためレプリカ数を増やすと、今度はネットワーク帯域がボトルネックになりました。この経験から、実行基盤全体を継続的に監視し、ボトルネックに応じてリソースをすぐに調整できる仕組みが必要だとわかりました。
問題の原因を特定するため、メトリクスの確認と仮説検証を短いサイクルで繰り返し、再現条件を絞り込みました。また、短期間で検証サイクルを回すため、検証用スタブの作成からログやコードの調査、原因分析、修正案とテスト観点の洗い出しまでをコ ーディングエージェントに任せました。設計・検証の方針と最終確認は人が担い、コーディングエージェントとの分担で原因特定から修正・再検証までを一気に進められたのは良い経験でした。
接続方式の違いを吸収するGateway
Agent Runtimeを異なる複数のサービスで共通利用できるよう、Gatewayが接続方式をAgent Runtimeの共通インターフェースへ変換して、仕様差分の吸収と認証を担います。一方、LLMの実行はAgent Runtimeが担い、サービス固有の出力結果の扱いは利用側に任せています。
Agent iを例にすると、Agent Builderでは出力を制御するためにStructured Outputsの共通テンプレートを用意しています。この出力のうち、Agent Runtimeが処理に使う共通部分だけをGatewayが変換し、カードやフォーム、表といった画面表示用のUI定義はそのままAgent i側へ渡します。これにより、Agent i側でUIパーツを追加しても、Gatewayの変換処理を変更する必要はありません。
将来的には、A2A (Agent2Agent)によるエージェント間の接続やMCPによるLLMクライアントからの接続もサポートし、利用範囲を広げていく方針です。これらのプロトコルは開発当初から候補にありましたが、当時はA2Aが発表されたばかりで仕様が安定していなかったため、現在は独自プロトコルを採用しています。Gatewayへプロトコルを柔軟に追加できるため、今後新たな接続方式や利用パターンが必要になっても対応しやす くなります。このようにGatewayを前段に用意したことで、Agent Runtimeを大きく変えずに将来の変化を受け入れられる点に大きなメリットを感じています。
エージェント開発に生まれた変化
わかりやすい成果は、エージェント開発のサイクルを速く回せるようになったことです。例えば、最終的な実装にエンジニアの力が必要でも、企画職や営業職がプロトタイプを作ってアイデアを具体化できます。また、画面上で処理を追加したり順序を変えたりできるため、試した結果をすぐ次の改善へ反映できます。
実際にこの基盤で作成したワークフローは、Agent iで利用できるエージェントとして提供されています。ツール上で検証したワークフローをそのままサービスへつなげられるため、アイデアを形にしてエンドユーザーに届けるまでの時間も短縮できます。
開発サイクルの短縮に加え、企画職や営業職が自分たちの業務知識をプロンプトや処理の流れとして表現できるようになったことで、これまで要件として伝えきれなかった知見も実際の動作に反映できるようになりました。また、既存のプロンプトやワークフローを再利用できるため、新しい利用者もエージェント開発を始めやすくなりました。
さらに、社内データとの連携を進めたことで、エージェントがMCPやRAG (Retrieval-Augmented Generation)などで必要なデータへ自律的にアクセスできるようになりました。これにより、エンドユーザーの多様なニーズに応えるエージェントを量産する土台も整ってきました。
エージェント開発のサイクルが速くなり、より多くの人が業務知識や社内データを生かして開発に参加できるようになりました。
おわりに
エンジニア以外もエージェントを作って試せる環境の実現は、目指す姿に向けた最初の一歩に過ぎません。今後は増えていくエージェントを個別に完結させず、エンドユーザーの目的に合わせて連携させる仕組みへ発展させていきたいです。
具体的には必要なエージェントを自律的に選び、組み合わせて実行できる仕組みを目指します。一つひとつのエージェントを生み出す基盤が整い、ようやくプロジェクト発足当初に構想したマルチエージェントへ進める段階まで来ました。
AIエージェントを誰もが作れるようになっても、それだけでエンドユーザーへ価値を届けられるわけではありません。作る人の知識を取り込み、試行錯誤を重ねながら、必要なエージェントを適切につなぐ基盤を育て続けることが欠かせません。
今後も、より多くのアイデアを形にし、AIエージェントを通じてユーザーに「WOW」を届けられる基盤へ成長させていきます。
