2026年6月29日、LINEヤフーグループ最大の技術カンファレンス「Tech-Verse 2026」が開催されました。ここではKeynoteをアーカイブ動画と書き起こしテキストでご紹介します。
アーカイブ動画
3つのテーマ「Agent i」「AI Platform」「AX」
Keynoteのテーマは、「Agent i」「AI Platform」「AX」の3つ。まず、CTOの朴 イビンが「Agent i」の構想について、続いて、AI CBUリードの並木 良太が「Agent i」を支える「AI Platform」について、最後に、再び朴 イビンが、社内で進めている「AX」の取り組みや今後の展望について語りました。
Agent i
AIはものすごいスピードで進化していますが、実際に日常生活に根付いている利用率は、まだ約16%にとどまっています。LINEヤフーは、このギャップを埋めようとしています。
LINEヤフーでは、すでに1億人を超えるユーザーを持つメッセンジャーサービスであるLINE、そしてYahoo!検索、コマース、コンテンツサービス、決済に至るまで、日常生活に必要なほぼすべての機能がサービス化されています。
私たちは、この資産をエージェント化します。一般ユーザー向けの「Agent i」、そして100万以上のビジネスアカウントを対象とした「Agent i for Business」。この2つのサービスを通じて、ユーザーの日常におけるAI体験を、次のステージへと進化させようとしています。
「Agent i」が目指しているのは、単に機能をエージェント化することではありません。複数のエージェントを連携させて、キーワードではなく意図を読んで探す前に必要なことを差し出す。そうしながらみなさんのあらゆる瞬間に最適な便利さを届ける。それが「Agent i」が目指していることです。
企業向けには、LINEヤフーならではの強みであるミニアプリとLINE公式アカウントを活用します。ビジネスアカウントを持っている企業であれば、AI機能を自社サービスに提供できる、公式アカウントAIモード。そして運営・分析機能を高度化してくれる「Agent i Biz」。この2つのサービスを提供していく予定です。LINEヤフーとつながるすべての企業がDXを加速できる環境を作っていきます。
既存サービスがどうつながって、もっ と便利になるか。例えばLINEのグループトークで、「来月野球の試合を一緒に見に行こう」と声を掛けると、「Agent i」がウェブで検索して、試合の候補日を探して提案。グループの友だちから希望日をもらって、それをマッチングしますが、なかなか返事をしてくれない友だちには「Agent i」が繰り返しリマインドしながら個別調整を代行してくれます。日程が決定できたらトークに共有して、そのまま共有カレンダーへの登録まで連携してくれます。
ビジネスアカウントでも、飲食店の予約など、日常がよりラクになります。続いては、このようなサービスを支えるLINEヤフーのAIプラットフォームについて、並木から紹介してもらいます。
AI Platform
LINEヤフーの新たなサービス「Agent i」。ユーザーの意図を汲み取り便利を提供してくれる。本当にワクワクしますよね。本日は、そんな「Agent i」を動かすための技術的な「裏側の仕組み」についてお話しします。
世の中には便利なAIフレームワークやオープンソースがあふれています。ですが、それらを単にラップしてポンと置くだけでは、私たちが目指すエンタープライズレベルの基盤は成り立ちません。それに対して私たちがどのように立ち向かっているのかを話していこうと思います。
これが私たちの「AI Agent Platform」の全体観です。まずは「Build ＆ Manage」。エージェントを作り管理するレイヤーです。AI専門のエンジニアがいなくても簡単にエージェントを立ち上げられる「Agent Builder」や、どんなエージェントがあるのかを管理する「Agent Catalog」が、ここにはあります。
次に「Run ＆ Orchestrate」。実行の心臓部です。たくさんのエージェントを安全に、迅速に動かす。また、たくさんのエージェントの中から最適なエージェントを見つけ出す。そしてそのエージェントにユーザーの過去の経験を渡す。そうして選ばれたエージェントが、あなたの代わりにタスクを実行するのです。
そして、エージェントをさまざまなツールと接続する。いわゆる生成AIのモデルや各サービスが持っているデータにつなげることで賢く動くのです。
最後に「Governance ＆ Observability」。品質、安全性の統制を担う基盤がそれらを支えることで全体が成り立っています。
今日はこの中から特に重要なコンポーネントを3つの軸に沿ってお話ししたいと思います。
3つの軸。それは、「エージェント開発の民主化」「高精度なパーソナライズ」、そして「ガバナンス」。この順に、私たちのプラットフォームの設計思想と技術的挑戦をお伝えしていきます。
まずは1つ目、「エージェント開発の民主化」です。
たくさんのエージェントを迅速に生み出すためには、開発の民主化が不可欠です。私たちが提供するのはUIベースの「Agent Builder」、そして実行基盤の「Agent Runtime」。プロンプト設計、接続するAPI、社内ツールの選択をUI上で定義するだけで、自律エージェントをデプロイできます。AI専門のエンジニアでなくても、サービス運営に近い人が、1日でエージェントを立ち上げることが可能です。
ここでいう民主化は、単に誰でも触れるUIを作ることではありません。本当に重要なのは、仮説をすぐ形にし、実際のユーザー反応から素早く学べるようにすること、つまり試行錯誤の速度を上げることです。
ただし、ここで難しいのは、自由度を上げるほどリスクも増えるという点です。誰でも作れる、誰でもつなげる、誰でも公開できる、という状態をそのまま許すと、品質もセキュリティも維持できません。だからこそ、「Agent Builder」と「Runtime」には、ガバナンスとスケーラビリティを組み込む必要があります。
速く作れることと、安全に運用できること。この両立が、「AI Agent Platform」として最初に解くべき課題でした。実際に、リリースから2カ月で、すでに100を超えるワークフローが作られています。
先ほどのAgent Builderから社内データにアクセスさせる重要な役割を持つのがMCP Hubです。エージェントが既存の社内データやAPIにアクセスする際、接続経路の管理は容易にカオス になります。
そこで私たちは、最新のオープンスタンダードであるModel Context Protocol、MCPを全面採用したMCP Hubを構築しました。MCP Hubに集約することで、Agent Builderからの利用も容易になるし、ガバナンスもしやすくなるのです。
MCP Hubには大きく3つの機能があります。MCPサーバーそのものをスケーラブルに実行するRuntime、別環境で構築済みのMCPサーバーへ接続するGateway、そしてどんなMCPサーバーが登録されているのかを可視化するCatalog。
MCPサーバー提供者は簡単な手続きでMCP Hub上で公開することができますし、利用者は複雑な認証コードを一切書く必要もなく、Agent BuilderのUI上で、必要なMCPサーバーへの接続をクリックして認可するだけで使えるようになります。
現在150を超えるMCPサーバーが接続されており、このすべてをHubが一元的に監視・統制しています。
MCPを使うと、エージェントとツールの接続インターフェースを標準化できます。ただ、私たちがMCP Hubでやりたいことは、単にMCPサーバーを並べることではありません。ここで重要なのは、エージェントが外部能力を呼び出す瞬間を、プラットフォーム側で制御可能にすることです。MCPサーバーがどのツールを提供しているのか、そのツールは読み取り専用なのか、更新操作を 含むのか。どのエージェントが、どのユーザー文脈で、どのスコープまで呼び出してよいのか。また、エージェントから見ると「ツールを呼ぶ」だけでも、裏側では認可、スキーマ検証、レート制御、ログ、リトライ、フォールバックが必要になります。
つまりMCP Hubは、MCPサーバーのカタログであると同時に、Tool CallingのControl Planeなのです。エージェント開発者は細かい認証実装や接続管理を意識しなくてよい。一方でプラットフォーム側は、「誰が、どのエージェント経由で、どのツールを、どの権限で使ったか」を追跡できる。
この抽象化があるからこそ、Agent Builderからノーコードでツールを接続しながら、エンタープライズレベルの統制も両立できます。
接続できるエージェントが増えてくると、次に問題になるのは、どのエージェントに任せるかです。ユーザーの一言から、最も得意なエージェントを瞬時に見つけ出す。この中央ルーティングを担うのがAgent Routerです。
ここでユーザーの意図から外れたエージェントを選ぶわけにはいきません。一方で、精度を追いすぎて遅くなれば、ユーザーが離脱してしまう可能性があります。精度と速度の両立が求められる、とても重要な機能です。
Routerは、自然言語の裏にあるコンテキストを解読し、最適なエージェントへ動的にディスパッチします。
小規模なエージェント群であれば、ユーザー入力とエージェント一覧をLLMに渡して、「どれが適切ですか」と聞くだけでも動きます。しかし、エージェント数が増えていくと、この方式はすぐに破綻します。理由はシンプルで、レイテンシ、コスト、コンテキスト長、そして評価の難しさが一気に大きくなるからです。
そのためRouterは、単一のLLM呼び出しではなく、多段の検索・判定パイプラインとして設計する必要があります。まず、Agent Catalogに登録されたProfile、Capability、Policyなどのメタデータを使って、候補エージェントを高速に絞り込みます。ここでは、キーワード検索だけではなく、埋め込みベースのセマンティック検索も使えます。
次に、上位候補に対して、ユーザーの発話、現在の文脈、利用可能なツール、ポリシー制約を見ながら、LLMで再ランキングする。つまり候補生成は軽量・高速に、最終判断は文脈理解に強いモデルで行う分担が必要です。
さらに本番運用では、「正しいエージェントを選べたか」を継続的に評価する必要があります。Routerは単なる振り分けロジックではありません。AIエージェントの体験品質を左右する、検索、ランキング、LLM推論、オンライン評価が合わさった中核コンポーネントになります。
ここまでが、エージェントを作り、つなぎ、選ぶための仕組みでした。次は、選ばれたエージェントがユーザーをどう理解するかです。
2つ目の 軸、「高精度なパーソナライズ」です。「もう1人の私」を実現するには、エージェントがユーザーを覚えていることが不可欠です。それを支えるのが Long-Term Memoryです。
ユーザーとエージェントの対話履歴を、Memory Summarizerで要約・圧縮し、Memory Bankに構造化して蓄積します。単なるログ保存ではなく、あとから検索し、応答に活用できる形で保持する仕組みです。現在、ユーザーあたり平均7エントリのメモリが蓄積されており、エージェントはこれを使って、よりパーソナライズされた応答を返しています。
ただし、本当に難しいのは、記憶を保存したあとです。次に、その記憶をどう扱うかを見ていきます。
Long-Term Memoryを単に「過去の会話を保存する仕組み」と捉えると、本質を見誤ります。人間の記憶もそうですが、すべてをそのまま覚えていることが、必ずしも良い体験につながるわけではありません。一時的な予定、昔の好み、今も変わらない生活習慣、センシティブな情報。これらはすべて扱い方が違います。
「Agent i」が本当に「もう1人の私」に近づくためには、何を覚え、何を更新し、何を忘れ、何を守るべきかを判断する必要があります。
さらに、覚えた情報をすべてプロンプトに入れるわけにもいきません。必要なタイミングで、必要な粒度の記憶だけを取り出す必要があります。ここには、要約、検索、ランキング、アクセス制御、データ保護といった技術要素が関わります。
Long-Term Memoryで重要 なのは、記憶の量ではなく、意味のある記憶を安全に使えることです。ユーザーにとって意味のある記憶だけを、安全に、適切なタイミングで使えるようにすること。これが、高精度なパーソナライズを支える重要な技術課題です。
このMemory Lifecycleの先にある次のチャレンジが、Memory Aggregatorです。
LINEヤフーには多くのサービスがあり、居住地域、最寄り駅、購買履歴など、価値の高いデータ資産をたくさんお預かりしています。Memory Aggregatorは、これらのプロフィールデータと、エージェントごとに蓄積されたLong-Term Memoryを、ユーザーが発話した瞬間にリアルタイムで集約する構想です。
私たちはこれをContext Engineeringの問題として捉えています。LLMにとって、良い答えを返せるかどうかは、モデルそのものの性能だけでは決まりません。その瞬間に、どの文脈を、どの粒度で、どの順番で渡すかが非常に重要です。
たとえば、ユーザーの発話に対して、Long-Term Memory、プロフィール情報、サービス利用履歴、エージェント固有の状態をすべてそのまま渡すことはできません。コンテキストウィンドウには上限がありますし、不要な情報を入れると、むしろモデルの判断を邪魔します。さらに、機微性の高い情報は、そもそも渡してよいかを判定しなければなりません。
そこで、複数のデータソースから候補となる記憶や属性を取り出し、関連度、鮮度、信頼度、機微度、ユーザー同意、エージェントの目的を見ながら、最終的にプロンプトへ注入するContextを決める。ここで重要なのは、記憶を増やすことではなく、使うべき記憶を選ぶことです。必要なときに必要なことだけを思い出せるAIにすることで、LINEヤフーでしかできない高精度なパーソナライズを実現していきます。
ここまでが、ユーザーを深く理解するための仕組みです。最後は、それを安全かつ持続的に運用するための「ガバナンス」です。
ガバナンスの1つ目の要素、コストコントロール。
現在は、多くのタスクを汎用大型モデルに任せています。しかし、数万規模のエージェントが大型モデルだけを使い続けると、コストもレイテンシも持続しません。そこで必要になるのがModel Routingです。
適切なモデルを選択していくのがコストコントロールをするうえで重要になりますが、単に「安いモデルと高いモデルを使い分ける」話ではありません。実際にはタスク難易度、必要な推論能力、データの機微度、レイテンシ要求、コスト上限を見ながら、実行時にモデルを選ぶ問題です。
たとえば、分類や定型変換のような処理は、小さなローカルモデルでも十分な場合があります。一方で、複雑な計画立案や曖昧なユーザー意図の解釈では、大型モデルのほうが適しています。さらに、プライバシーに敏感な情報を扱う場合は、そもそも外部モデルに出さず、オンデバイスやローカル環境で処理する選択肢が重要になります。
ローカルモデルについては、現在はOpen-Weightモ デルをそのまま採用していますが、今後は「Agent i」に領域エージェントが増えるにつれ、エージェントに特化したファインチューニングされたモデルを簡単に作り・評価できるプラットフォームも必要になると思っています。
Agent Runtimeから見ると、これは推論リクエストのルーティングですが、プラットフォーム全体から見ると、コスト、品質、プライバシーを同時に最適化するための制御レイヤーです。
ガバナンスの2つ目の要素、品質とポリシーのコントロールです。数万のエージェントが乱立する世界で、プラットフォームの秩序と品質を守るハブとして「Agent Catalog」があります。
これは単なるエージェントの一覧ではありません。「Agent i」につなげてよいのはどれか、長期メモリはどのエージェントと共有するかをポリシーで厳密に制御し、さらにはサービスダウンの死活監視までを一元的にガバナンスする、プラットフォームの心臓部でありエージェントのライフサイクル全体を、ここで統制します。
ガバナンスの3つ目は、実行時の安全性を担うGuardrailsです。AIエージェントは、従来のチャットボットとは違い、ユーザーの代わりに判断し、ツールを呼び出し、外部システムにアクションすることがあります。サービスが便利になればなるほど、プラットフォーム側の責任も大きくなります。悪意ある入力による指示の書き換え、個人情報の混入、目的から外れた応答や操作。こうしたリスクは、個々のエージェント開発者だけでは防ぎきれません。
また、さきほどのパーソナライズを実現するために、私たちは重要なデータをたくさん蓄積・活用しています。AIは便利な一方で、ブラックボックスが増えたと思いませんか。ブラックボックスなシステムだけで安心できるでしょうか。
そこで私たちは、5つのGuardrailsを内製しました。Prompt Injection、個人情報マスキング、有害コンテンツ検知、Off-Topic検知、情報分類という機能を提供しています。
重要なのは、これらを最後に呼ぶだけでは不十分であるという点です。AIエージェントでは、ユーザー入力、Plannerの中間出力、Tool Callingの引数、外部ツールの戻り値、最終応答という複数のポイントでリスクが発生します。
そのため、ガードレールは1カ所のフィルターではなく、Agent Runtimeの各ステップに差し込む必要があります。入力時にはPrompt Injectionや有害入力を検知する。Tool Calling前には、実行してよい操作か、個人情報や機微情報を含まないかを確認する。Toolの戻り値に対しては、プロンプト汚染や不要な個人情報を除去する。そして最終応答では、ポリシー違反やOff-Topicを検知する。
つまりGuardrailsは、モデルの外側にある安全装置であると同時に、Agent Runtimeそのものに組み込まれる実行制御でもあります。ここを内製しているのは、AIエージェントの品質と安全性を、プラットフォームとして継続的に改善できるようにするためです。
ここまでお話ししてきたように、「Agent i」を真に動かすのは、見た目のAI体験だけではありません。その裏側には、エージェントを素早く作るための開発基盤、ユーザーを深く理解するためのメモリ基盤、そして安心して任せられるためのガバナンス基盤があります。これらを1つのプラットフォームとして提供することで、AI体験に今までにない便利と「WOW」を届けていきます。
AX
続いて、LINEヤフーで進めているAX化について紹介します。
新規サービスや小さな組織であれば、AIへの転換は比較的速く進めることができます。しかし、30年以上のレガシー、100個以上のサービス、複雑なグローバル規制を持つ大きな企業でのAXはまったく別の話です。構造的な複雑さ、それがまず課題です。この課題にLINEヤフーがどう向き合っているか、その戦略と現場について共有します。
この難しさを乗り越えるために、LINEヤフーは明確な目標のもとで、戦略的、段階的な実行を進めてきました。この5段階のAXの実行計画の中で、いよいよ今年からExecutionフェーズへと全社のAXを、より加速させようとしています。
まず今まで進んでいたBuild・Enableについてです。こちらのフェーズを進むため、私たちは社内で約37個の大きな横断プロジェクトを3つのグループに分けて進めてきました。その1つ目が、AIプラットフォームや社内向けプラットフォームを整備するグループ。2つ目がAI Readyな環境をつくるプロジェクトグループ。そして最後に、この環境の上でさまざまなAIソリューションを開発するプロジェクトグループ。ここでは、この中でAI Readyな環境づくりについて、もう少し紹介します。
私たちはシステムとデータ、そしてそれを使う人、この2つのAI Readyな状況をつくってきています。まずシステムとデータのAI Readyとして、既存のシステムをAPI化して、社内のMCP Hubの上でMCP化したりエージェント化することを推進してきました。
それはLINEヤフーのすべてのシステムとデータが、AIとつながる環境、すなわちAIが組織の神経網になる環境を作っていくためです。そのうえで、教育などを通じて全社員のAIネイティブ化を進め、誰でもAIをフルに活用できるような環境を整えていきます。
そして今年、このフェーズを次のExecutionフェーズへと加速させます。今までもAIを活用して、個人の生産性が何倍も上がっているケースも多くあります。また、素早く適用できるCSのような領域では、80％以上の生産性向上の結果も出ています。
ここで言うExecutionレベルとは、個人の生産性向上レベルから、組織・サービスの生産性向上レベルへと広げていくこと。個別プロセスへの部分適用から、全体プロセスへの適用へと進めていくことを意味しています。部分から全体へ。個人から組織へ。今、その挑戦を進めています。
いくつかの挑戦の現場と戦略を紹介します。まずはサービスプロダクション領域です。
サービスプロダクションのAX化、その核心はAI駆動開発です。AI駆動開発は新規、軽量サービスでは今でも速いペースで適用して進んでいますが、本当の問題はそこではありません。数千万ユーザーを持っている既存レガシーサービス群。ここにAI駆動開発を安定的に適用すること。私たちは、この部分にフォーカスしてます。
このレガシーのAI駆動開発で一番大事な部分はコーディング部分ではなく、企画・設計部分です。そのため、私たちは各サービスドメイン別に、既存仕様ドキュメントを、AIが理解できる形に構造化したり、大規模サービスを分割して、その依存関係を可視化することで、企画段階のAI Readyを本格的に進 めています。
このレガシーのAI Ready化の結果も少しずつ出ています。この1年で、AI向けに構造化した設計書は約46倍になり、AI向けに準備が整ったリポジトリのカバレッジは約15％まで達しました。
生産性の結果も着実に上がってきています。この1年で、既存レガシーサービスにおいて、AIが生成するコード量が全体の約20％に達しました。今年、本格的に推進することで、この数値を一気に引き上げます。
コード生産量で話をしましたが、AXの本当の成果を測るには、より正確で多角的な指標が必要です。そこでLINEヤフーは、今年からプロダクションのリードタイムを主要指標とし、AI活用率、そして、品質指数、そのうえでまたDORA Metricsまで加えた、多角的な指標体系で測定しようとしています。
レガシーは、プロダクションレイヤーだけでなく、セキュリティ、プライバシー、リーガルなどのセカンドラインのプロセスにも存在します。この領域のリードタイムも、プロダクション全体のリードタイムの相当な割合を占めています。そこで、この領域のAX化も、AI Ready化から着実に進めています。まず、セカンドラインの全体のプロセスを可視化・統合するプロジェクトが進んでおり、7月に一次オープンを予定しています。
一次オープンの対象として、全プロセスの約30％をAX化する予定ですが、現時点での初期的な成果として全体の約13％のリードタイムが短縮できることを確認しました。残りのシステムのAX化も、段階的に進めていく予定です。
続いてインフラ領域です。
昨年のKeynoteで既存のLINEとヤフーのクラウドを統合して進化させたLINEヤフーの新しいプライベートクラウド、Flavaについて紹介しました。Flavaは、現在社内オープンが完了し、FY30に向けて段階的な移行が進んでいます。この土台の上で今年は、AIエージェントがFlavaを安全に使えるようにするクラウドインターフェースへとさらに歩みを進めています。
AIエージェントによるインフラ操作は、単に命令を下すことで はありません。「人だけが直接操作する」という前提から、「人とエージェント、両方が利用者になる」という前提で、前提そのものが本質的に変わることを意味しています。
この転換で一番注意すべきことは、エージェント側にクラウド操作ができるかどうかではなく、どこまで安全に任せられるかにあります。LINEヤフーは、エージェントの権限を段階別に徹底的に検証する環境を作りながら、次の目標であるAI-native Cloudへと進んでいきます。
最後にセキュリティについて紹介します。AIの進化とともに、セキュリティリスクも極めて高まっています。そこでLINEヤフーも、この3つの軸でセキュリティを全方位的に強化しています。
まずAIを安全に使うために、GuardrailsとAgent permissionを含めた信頼設計を基盤として、環境を整えています。また安全に実装するため、開発の初期段階からセキュリティ担当者が入って一緒に設計していますし、脆弱性検出もAIを活用しながら事前の段階から行っています。
最後に、安全に運用するため、グローバルレベルのモニタリングも強化していますし、Zero trust Infrastructureとして再設計まで、先手を打って強化しています。そのうえで、クロスガバナンス体制を高度化しながら、より安全な環境を作ろうとしています。
従業員のみなさん、新たな挑戦でワクワクしながらも、厳しさを感じる場面も多くあると思います。私たちも同じです。その環境の中でもLINEヤフーならではの視座や強みをもとにして、AIを最大限生かしながら最高のサービスを届けていきます。お互いの経験を持ち寄りながら一緒に新たな未来を切り開いていきましょう。
「Tech-Verse 2026」公式SNS・関連情報
- 公式サイト https://tech-verse.lycorp.co.jp/2026/ja/
- 公式Ｘアカウント https://x.com/lycorptech_jp
- LINEヤフー テクノロジー&デザイン https://www.lycorp.co.jp/ja/technology-design/
- LINEヤフー Tech Blog https://techblog.lycorp.co.jp/ja
- LINEヤフー採用note https://note.com/lycorp_recruit
- LINEヤフーDESIGN 公式note https://lydesign.jp/
