LINEヤフーが2026年8月26日、AIエージェント「Agent i」を支える開発基盤の設計を公式の技術ブログで公開しました。
この事例のいちばんの読みどころは、技術そのものより着手の順序を途中で入れ替えたことにあります。当初は「AIエージェントが増えると連携が課題になる」と考えてマルチエージェントから取り組もうとしましたが、検討を進めた結果、その手前で「エージェントを1体作ること自体が難しい」という現実にぶつかり、先に作れる基盤のほうを内製しました。
この記事は2026年9月2日時点で、LINEヤフーの公式技術ブログと公式プレスリリースに書かれている内容だけをまとめています。推測した構成は含めていません。
何が動いているのか
「Agent i」は、それまで別々に提供されていた「Yahoo! JAPAN」の「AIアシスタント」と「LINE」の「LINE AI」を統合したAIエージェントの新ブランドです。2026年4月20日に提供が始まりました。
- ▸2026年4月20日の開始時点で、領域エージェントは7種類（β版を含む）。お買い物、おでかけ、天気などで、自動車・人間関係・仕事相談・レシピはβ版として提供されていました
- ▸2026年6月30日には累計22領域（β版を含む）へ拡大。この日にファイナンスエージェントの提供が始まっています
- ▸「LINE」と「Yahoo! JAPAN」の両方からワンタップでアクセスできるWebサービスとして提供されている
- ▸LINEヤフーの100を超えるサービスから得られる独自データを活用する、と公式に説明されている
2か月あまりで7領域から22領域へ増えていることになります。この増え方を支えているのが、今回公開された開発基盤です。
マルチエージェントから出発して、「作れる基盤」に戻った
技術ブログによれば、チームはもともと別のAI領域を担当していて、LLMの進歩を受けてAIエージェント領域へ方針転換しました。方針転換の時点では何を作るかは決まっておらず、まず課題の整理から始めています。
そこで最初に立てた見立てが「エージェントは今後急速に増える。だからエージェント同士の連携（マルチエージェント）が最初に解くべきテーマだ」というものでした。
ところが検討を進めると、その前提が崩れます。技術ブログはこう書いています。一つのエージェントを作るにはコードを書く必要があり、担い手がエンジニアに限られていた。 処理の分岐や実行経路も把握しにくく設計の見通しが立たない。作った後もデプロイして動かすまでに手間がかかる。
つまり連携させる対象そのものが増やせない状態でした。連携は「その先に取り組むもの」と判断し、先に「エージェントを手軽に作ってすぐ試せる環境」を作る方針に切り替えています。
基盤の構成
開発基盤はAgent Builder（開発ツール）とAgent Runtime（実行基盤）の2つで構成されています。既存ツールをそのまま使う案は、「社内データへ安全に接続できること」と「自社サービスの要件に合わせて継続的に拡張できること」の両立が難しいと判断し、内製に踏み切ったと説明されています。
Agent Builder — ノードとエッジで組み立てる
- ▸ノードとエッジを配置・接続してワークフローを組み立てる、グラフ形式のノーコード編集画面。編集画面には React Flow を採用
- ▸LLMの処理・分岐・繰り返しを画面上で組み合わせ、テストから公開・デプロイまで一貫して行える
- ▸作成したワークフローから独自の中間表現（IR: Intermediate Representation）を生成し、構造や設定を検証したうえで保存する
- ▸検証では到達可能性や接続関係をグラフ理論に基づいて確認し、問題があれば公開前に利用者へフィードバックする。構造上の不整合による実行時エラーを未然に防ぐ狙い
- ▸Structured Outputs は、画面で設定した出力項目から JSON Schema を自動生成する。専門的な記述なしで使える
- ▸Verbosity や Reasoning Effort といったLLMのAPIパラメータのうち、効果を理解しやすいものは見つけやすい場所に配置し、モデル選択とあわせて処理ごとに調整できる
見落としやすい点として、「何でもノーコードにする」設計ではありません。 使いやすさを優先するために扱うユースケースを絞り、複雑な制御や高度なカスタマイズは引き続きエンジニアが担う設計だと明記されています。また、寄せられた改善要望をそのまま機能追加するのではなく、「幅広い利用者にとって意味がわかりやすく、誤った設定が起きにくいか」を見極めてから取り込んでいます。
Agent Runtime — IRを実行グラフに変換して動かす
Agent Runtime は、公開されたワークフローをサービスの負荷に応じて安定して実行する役割を持ち、Kubernetes上でスケールする構成です。設計時と実行時のデータ表現の違いは、共通モデルであるIRが吸収します。データの流れは次のとおりです。
- ▸① 社内の利用者が Agent Builder でワークフローを定義する
- ▸② ワークフローから IR を生成し、構造と設定を検証したうえで保存する
- ▸③ Agent Runtime が実行リクエストを受け取ると、そのIRを読み込む
- ▸④ IRを LangGraph の実行グラフへ変換・コンパイルして実行する（条件分岐・繰り返し・ノード間の状態管理に対応しており、IRを落とし込みやすいことが採用理由）
- ▸⑤ 前段の Gateway が、サービスごとに異なる接続方式をAgent Runtimeの共通インターフェースへ変換し、仕様差分の吸収と認証を担う
Gatewayの分担は具体的に説明されています。Agent i の場合、Agent Builder 側で出力制御用の Structured Outputs 共通テンプレートを用意し、そのうちAgent Runtimeが処理に使う共通部分だけをGatewayが変換します。カードやフォーム、表といった画面表示用のUI定義はそのままAgent i側へ渡すため、Agent i側でUIパーツを追加してもGatewayの変換処理を変えずに済みます。
将来的には A2A（Agent2Agent） によるエージェント間接続や MCP によるLLMクライアントからの接続もサポートする方針ですが、現在は独自プロトコルです。開発当初はA2Aが発表されたばかりで仕様が安定していなかったため、という理由まで書かれています。
「誰でも作れる」を「安全に動かせる」と両立させた部分
作れる人を広げると、そのぶん本番環境で動くものの素性がばらつきます。ここをどう抑えているかが、この事例のもう一つの読みどころです。
- ▸Kubernetes Namespace を実行環境ごとに分離し、論理的なサンドボックスとして扱う
- ▸各環境ではネットワークACLで通信先を絞る。MCP Server・ドキュメント・内部APIなどへのアクセス可否を実行時に検証する
- ▸認証情報やAPIキーをワークフロー定義に含めない。 必要なタイミングで取得して社内データや外部サービスへ接続する
- ▸Namespace分離により負荷も実行環境ごとに局所化される。特定のワークフロー群にアクセスが集中しても影響が広がりにくく、必要な範囲だけレプリカ数やリソース量を調整できる
- ▸公開前のIR検証（到達可能性・接続関係の確認）が、実行時エラーになる構造を事前に止める
負荷試験の記述も具体的です。CPUとメモリを見直したあと、同時実行数に対応するためレプリカ数を増やすと、今度はネットワーク帯域がボトルネックになったと書かれています。ここから得た教訓として、実行基盤全体を継続的に監視し、ボトルネックに応じてリソースをすぐ調整できる仕組みが必要だとまとめられています。
なお原因特定の作業では、検証用スタブの作成、ログとコードの調査、原因分析、修正案とテスト観点の洗い出しをコーディングエージェントに任せ、設計・検証の方針と最終確認は人が担う分担をとったことも記されています。
現場に起きた変化
- ▸最終的な実装にエンジニアが必要な場合でも、企画職や営業職がプロトタイプを作ってアイデアを具体化できるようになった
- ▸画面上で処理を追加したり順序を変えたりできるため、試した結果をすぐ次の改善へ反映できる
- ▸ツール上で検証したワークフローをそのままサービスへつなげられるため、エンドユーザーに届くまでの時間が短縮された
- ▸企画職や営業職が自分の業務知識をプロンプトや処理の流れとして表現できるようになり、要件として伝えきれなかった知見が動作に反映されるようになった
- ▸既存のプロンプトやワークフローを再利用できるため、新しい利用者が始めやすい
- ▸社内データとの連携により、エージェントが MCP や RAG で必要なデータへ自律的にアクセスできるようになった
そして技術ブログは、「ようやくプロジェクト発足当初に構想したマルチエージェントへ進める段階まで来た」と締めくくっています。最初に解こうとしたテーマに、基盤を整えてから戻ってきた形です。
この事例から持ち帰れること
「連携」より先に「1個目を作る手間」を疑う。 AI活用の計画は、複数のAIを組み合わせる将来像から描かれがちです。しかしこの事例では、連携の前に担い手がエンジニアに限られているという制約が効いていました。試したい人が自分で試せない状態では、そもそも数が増えません。自社で同じ検討をするなら、「作ったあと」ではなく「作り始めるまで」に何日かかるかを先に測るほうが実態に近づきます。
作れる人を広げる施策は、実行時の隔離とセットで考える。 誰でも作れる基盤は、裏返せば素性の異なるものが本番で動くということです。この事例が実行環境の分離・通信先の制限・認証情報をワークフロー定義に置かない設計をあわせて用意しているのは、そのためです。「使える人を増やす」と「安全に動かす」は別々の施策ではなく、同時に設計するものとして扱われています。
将来の接続方式が決まらないなら、変換層を前に置いて先へ進む。 A2Aの仕様が固まっていない時点で待たず、Gatewayで吸収して独自プロトコルで進める判断をしています。標準が固まるまで止めるのではなく、あとで差し替えられる場所を用意して進むという選択肢は、多くの現場で応用が利きます。