こんにちは。LINEヤフーの永吉です。5月8日（金）、「LINEヤフー Development with Agents Meetup #3」を開催しました。
今回のMeetupでは、Orchestration Development Workshop（以下、ODW）で得られた知見が、開発現場でどのように活用され、定着しつつあるのかを共有しました。
本記事では、各発表の内容と、イベントで共有された生成AI活用の具体的な取り組みを紹介します。
イベント概要
- 日時：2026年5月8日（金）19:00〜22:00
- 場所：LINEヤフー株式会社
- イベントページ（connpass）：「LINEヤフー Development with Agents Meetup #3」イベントページ
発表紹介
イベントで行われた各発表を紹介します。
発表1：「Orchestration Development Workshopを半期実施して」
本セッションのオープニングでは、LINEヤフーにおける生成AI活用の取り組み「ODW」について、山手政実さんから半期の実施結果が共有されました。
山手さんの発表で一貫して強調されていたのは、「AI活用を個人のスキルに閉じず、組織能力としてスケールさせる」という設計思想です。ODWは、AIとの協働を実務で再現できるようにするための取り組みです。単なる知識共有にとどまらず、参加者が自分の業務で試せる構成になっています。
具体的には、ハンズオンを中心にした双方向型の構成で、参加者が自分の業務に引き寄せて活用方法を検討できるようになっています。「見るだけで終わらせない」ことを重視し、個人が得た体験を組織内で再現・共有しやすくすることを狙っています。
また、扱うテーマも開発ワークフロー全体や障害対応といった日常業務に直結する内容が中心です。Jiraを起点とした要件整理からコード生成、テスト、レビューまでの流れや、Slack上での不具合報告から原因推定・修正提案までのプロセスを例に、AIを組み込んだ形で再構成することで、「自分の現場でも使える」という具体的なイメージを持たせる設計になっていました。
このような設計の背景には、AI活用が個人任せになることで、知見が組織に蓄積されないという課題があります。ODWでは、ワークショップで得た知見を各組織に持ち帰り、さらに展開していくことを前提にしています。個人の試行錯誤を組織全体で共有し、再利用できるようにする仕組みです。
実際の取り組み規模としても、社内エンジニア約7,000人を対象に展開され、累計4,700人以上が参加し、開発組織の約85％にリーチしていると紹介されていました。この規模で継続的に実施されている点からも、単発の施策ではなく、組織的な変革を見据えた取り組みであることがうかがえます。
成果面では、生成AIの利用促進につながっていることが示されていました。社内ツールの利用率向上に加え、ワークショップ参加者は非参加者と比べてAI未利用率が34％低く、さらに約75％が業務の生産性向上を実感しているという結果が共有されています。これらの数値からも、「体験を通じて実務に接続する」という設計が有効に機能していることが読み取れます。
一方で、課題として挙げられていたのが「継続的な活用」です。ワークショップを通じてAIを使うきっかけは作れているものの、それが日々の業務フローに組み込ま れ、継続的に使われているかについてはまだ十分ではないと整理されていました。
この点を踏まえ、今後は「AIを身近にするフェーズ」から「AIで開発を変えるフェーズ」へと進んでいく方針が示されました。単なるツール活用の普及にとどまらず、開発プロセスそのものを再設計する段階へ移行していくことが、ODWの次のテーマです。
発表資料：Orchestration Development Workshopを半期実施して（Speaker Deck）
発表2：「Agent Development Kit（ADK）で学ぶ実践Context Engineeringと社内での応用例」
井上秀一さんからは、「コンテキストエンジニアリング」をテーマに、AIエージェントのコストと精度を同時に改善する設計手法が紹介されました。
本発表では、AIエージェント活用が広がる中で課題になりやすい、コストと精度の両立が取り上げられました。Claude CodeやCodex、MCP、マルチエージェントの利用が進む一方で、Token消費によるコスト増加や、コンテキストが膨らむことによる出力品質の劣化が起きやすくなっています。井上さんは、これらを別々の問題ではなく、「AIに渡す情報の設計」の問題として整理していました。
そこで重要になるのが、コンテキストエンジニアリングです。コンテキストエンジニアリングは、推論時にモデルへ渡されるプロンプト、会話履歴、ツール定義、外部データなどを選別・管理する考え方です。単にプロンプトを工夫するだけではなく、AIが扱う情報全体を設計対象にする点が、従来のプロンプトエンジニアリングとの違いとして説明されていました。
発表では、コンテキストエンジニアリングの原則として「最小限の高品質なTokenセットを見つける」ことが強調されていました。不要な情報を減らすことでコストを抑えられるだけでなく、ノイズが減ることで精度向上にもつながるという考え方です。
具体的な実装例として紹介されたのが、Googleが公開しているAgent Development Kit（ADK）を使ったマルチエージェント構成です。ADKでは、エージェント同士の連携、Web UI、APIサーバー、MCP連携などを扱えるため、個人のローカル環境に閉じない形で、組織単位のエージェント活用を設計しやすい点がメリットとして挙げられていました。
その中でも、コンテキスト量を抑えるための実装パターンとして、Agent Tool、Tool Filter、Structured Outputの3つが紹介されました。Agent Toolは子エージェントの内部処理を呼び出し元に漏らさず、最終結果だけを返す仕組みです。Tool Filterは不要なMCPツールを渡さないための仕組みで、Structured Outputは出力スキーマを固定し、余計な情報や揺れを抑えるために使われます。
社内での検証例としては、Jiraのチケット情報から週次レポートを生成するエージェントが紹介されました。単一エージェントで処理する構成と、コンテキストエンジニアリングを適用した構成を比較したところ、コンテキストウィンドウ使用率を77.7％削減し、システム全体のToken使用量も40％以上削減できたとのことです。
さらに、Kubernetes as a Service基盤における問い合わせ対応業務では、サーバー側で独立して動作するマルチエージェント構成を活用し、一次調査の自動化にも取り組んでいることが紹介されました。過去の問い合わせJiraチケット、PF Docs、チーム内ドキュメント、クラスタ情報など、問い合わせ対応に必要な複数のデータソースを対象に、情報収集・分析・トラブルシュートをマルチエージェントで自動化しています。その結果、チーム全体の作業時間を57％削減できたとのことでした。
本発表では、AIエージェントを個人利用にとどめず、組織で継続的に運用するための設計の考え方が示されました。特に、コスト削減と精度向上を同時に実現するには、モデルやプロンプトだけでなく、渡す情報そのものを設計する必要があるという点が重要なポイントでした。
なお、本ワークショップの詳細な内容や実装方法は、以下のLINEヤフー Tech Blogで公開されています。ADKやMCPを使ったエージェント設計、コンテキストエンジニアリングの具体的な適用方法を試したい方は、あわせて参照してください。
LINEヤフー Tech Blog / 3つの手法でToken消費量40％削減 — ADKで実践するContext Engineering
発表資料：Agent Development Kit（ADK）で学ぶ実践Context Engineeringと社内での応用例（Speaker Deck）
発表3：「Slack MCPでインシデント対応とFAQ生成を加速する：社内ワークショップの実践」
迫川凌さんからは、Slack MCPを活用したワークショップの実践が紹介されました。
本発表では、Slack MCPの機能紹介にとどまらず、「効率化できるツールをどのように現場に広げるか」という観点で、ワークショップ設計と具体的なユースケースが紹介されました。特に、AI活用を「知っている」だけでなく、実務で「使える」ようにするためのアプローチが中心でした。
Slack MCPの前提として整理されていたのが、「Slackは一次情報の宝庫である」という考え方です。日々の問い合わせ対応やインシデント対応など、重要な情報が蓄積されている一方で、それらは分散しており、人手での整理に依存しているという課題があります。
ワークショップでは、この課題に対して「問い合わせ対応のナレッジ化」と「インシデント対応支援」の2つのユースケースが扱われました。Slack上のスレッドをもとに、FAQやインシデントレポートを構造化して生成することで、対応コストの削減と品質の平準化を図るアプローチです。
これらの取り組みでは、単なる自動化にとどまらず、「スキル」として再利用できる形にしている点がポイントです。プロンプトを定型化し、誰でも同じように実行できる形にすることで、個人の工夫をチームや組織に展開できる設計になっています。
また、ワークショップ設計では、「スピード感」と「体験を通じた理解」が重視されていました。ツールの登場直後という関心が高いタイミングで実施し、Hello投稿のような簡単な操作から始めて段階的に実務ユースケースへつなげることで、参加者が自然に“自分ごと化”できる構成になっていました。
なお、本ワークショップの詳細については以下のLINEヤフー Tech Blogで公開されています。実際に試してみたい方は、あわせて参照してください。
LINEヤフー Tech Blog / Slack MCPでインシデント対応とFAQ生成を加速する：社内ワークショップの実践
発表資料：Slack MCPでインシデント対応とFAQ生成を加速する：社内ワークショップの実践（Speaker Deck）
発表4：「SDDで見える、AIコーディングの『内訳』」
曾⽥知也さんからは、SDD（Spec Driven Development）を用いたAIコーディングの可視化について紹介されました。
本発表は 、「AIコーディングは本当に速くなっているのか」という問題提起から始まります。Claude CodeやCodexの活用によって開発の体感速度は向上している一方で、実装前の検討や手戻りにかかる時間など、表面に現れにくいコストも増えており、実際の効率がどこまで改善されているのかは見えづらいという指摘です。
この課題に対して提示されたのが、SDDによる開発プロセスの構造化です。SDDでは、要件定義・設計・タスク分解・実装といったフェーズを明示的に分けて進めます。各工程で使うスキルを固定し、生成物をドキュメントとして残すことで、Claude Codeなどのセッションログを解析すれば、どの工程にどれだけ時間がかかっているかを可視化できるようになります。
発表では、このプロセスをゴルフに例えて説明していました。要件や仕様を固める工程を「風を読む」、AIに実装を任せる工程を「ショット」、マージを「カップイン」と捉え、AIコーディングにおける手戻りの構造を直感的に説明していました。
この例えが示しているのは、最終的な成果を左右するのは「ショット（実装）」ではなく、「風を読む（要件・設計）」の精度であるという点です。仕様が曖昧なままだと、AIの出力も曖昧になり、何度も打ち直しが発生します。一方で、必ずしも完璧に要件を固めることが最適とは限らず、場合によっては実装しながら調整する方が効率的なケースもあるというバランスも示されていました。
曾⽥さんは実際に2カ月間SDDを導入し、チーム全体のセッションログを解析することで開発プロセスを可視化しています。スプリントごとに「風を読んだ時間」「打ち直しにかかった時間」「打ち直し回数」といった指標を集計し、プルリクエスト単位でどの工程に時間がかかっているかを分析できるようにしていました。
その結果、打ち直しの回数が少ないほど必ずしも開発時間が短くなるわけではない、という傾向が示されました。ドキュメントを詰めるよりも、コードを書きながら理解を深めた方が早いケースもあり、「手戻りをなくすこと」自体が目的ではないと分かります。
本発表では、AIコーディングの速度を評価するには、単にマージまでの時間を見るのではなく、その内訳を把握することが重要だと説明されました。SDDは本来、開発品質を高めるための手法ですが、プロセスを揃えることで「計測できる状態」を作り出せる点にも価値があります。
また、曾⽥さんはODW回において、Codex CLIを活用したSlack問い合わせ対応の自動化についても紹介しています。Slack上のやり取りやコードベースを横断的に参照し、根拠付きの回答を生成する仕組みについては、以下のLINEヤフー Tech Blogで詳しく解説されています。今回の内容とあわせて読むと、AI活用を開発プロセスだけでなく、日常業務全体へ広げる流れを具体的に把握できます。
LINEヤフー Tech Blog / Codex CLIで作るSlack 1次回答AI
発表資料：SDDで見える、AIコーディングの『内訳』（Speaker Deck）
発表5：「コーディングAIが導くリスクベースド探索的テストの実践」
福山怜史さんからは、「コーディングAIが導くリスクベースド探索的テストの実践」について紹介されました。
本発表の出発点は、テストにおける判断が暗黙知になりやすいという課題です。前回バグが出た箇所を重点的に見る、リリース前にどこまで確認するかを判断する、どの領域にリスクがありそうかを見極める。こうした判断は、ベテランの経験に依存しがちです。福山さんは、この暗黙知をAIエージェントによって形式知化し、誰でも再現できる仕組みに変えられないか、という問いを提示していました。
今回紹介されたアプローチは、「どこにリスクがあるか」「何を確認すべきか」「どう試すべきか」をAIで一連の流れとして扱うものです。具体的には、過去のバグチケットからリスク分析表を生成し、そのリスクとプルリクエストの変更内容を掛け合わせてテストケースを作り、最後にPlaywright MCPなどのテスト自動化ツールを使ってAIがブラウザを操作しながらテストを実行する、という3ステップで構成されていました。
最初のステップでは、GitHub IssueやJiraなどに蓄積されたバグ情報を入力として、発生しやすさと影響度を軸にしたリスク分析表を生成します。ここでは、AIにすべてを任せるのではなく、自然言語の解釈や正規化はAIに任せ、集計処理はスクリプトで行う設計が紹介されました。これにより、AI の出力揺れを抑えながら、再現性のあるリスクマトリクスを作れるようにしていました。
次のステップでは、生成したリスク分析表とプルリクエストの差分をもとに、テストケースを生成します。単に変更差分から一律にテスト項目を出すのではなく、過去に問題が起きやすかった領域ほど多めにテストケースを生成する点がポイントです。また、既存のテスト観点や機能ごとの標準的な確認手順をリファレンスとして用意しておくことで、チームの前提知識をAIが活用できるようにしていました。
最後のステップでは、生成されたテストケースをもとにAIが自動で動作確認を行います。フロントエンド領域では、Playwright MCPなどのテスト自動化ツールを使うことで、AIがブラウザを操作し、指定された手順に沿ってテストを進められるようになります。さらに、失敗がなかった場合にも追加検証へ進む分岐を設けることで、単なる自動実行ではなく、探索的テストに近い動きができるよう工夫されていました。
実際の検証では、あるパフォーマンス改善のプルリクエストに対して、自動生成されたテストケース41件のうち14件がリスクを考慮した内容となり、手動テスト以外の確認を約30分で完了できたとのことでした。N=1の検証ではあるものの、重大なバグの再発確認や異常系テストの網羅に効果が見られた点から、実務でも活用できる可能性が示されました。
一方で、自動テスト可能と判定されたケースでも、モックやテストデータの都合で実行できない場面があったことも課題として挙げられていました。AIがテストを実行できるようになるほど、人間側には「AIが検証しやすいテスト環境」を整えることが求められます。
本発表は、テストを単に自動化する話ではなく、ベテランの判断をリスク分析・テストケース生成・実行の流れに落とし込む試みとして紹介されました。AIエージェントを活用することで、これまで暗黙知に頼っていたテスト判断を、チームで再利用できる仕組みに変えていくアプローチです。
なお、本ワークショップの詳細な内容や実装方法については、以下のLINEヤフー Tech Blogで詳しく解説されています。リスクベースドテストとAIエージェントの組み合わせを実際に試したい方は、記事もあわせて参照してください。
LINEヤフー Tech Blog / リスクベースド × AIエージェントで実現する探索的テスト 〜「暗黙知」を「形式知」に変えるテストの考え方〜
発表資料：コーディングAIが導くリスクベースド探索的テストの実践（Speaker Deck）
発表6：「Personal knowledge bases using LLM」
LINE Plus CorporationのAI Labでリードを務めるkilro.hanさんから、LLMを活用したパーソナルナレッジベース「LLM Wiki」について紹介されました。
本発表の出発点は、日々の業務で蓄積さ れる情報を「あとから活用しづらい」という課題です。Slackでのやり取り、Jiraのチケット、Confluenceのドキュメント、個人のメモやWebページなど、情報はさまざまな場所に分散しています。これらをあとから振り返ろうとすると、「どこに何があったか」を探すだけでも時間がかかるという問題があります。
LLM Wikiは、散らばった情報をLLMによって再構造化し、自分専用の知識ベースとして扱えるようにする考え方です。特定のフレームワークや厳密な実装方法が決まっているわけではなく、Andrej Karpathy氏が提唱したアイデアをベースに、それぞれの用途やプロジェクトに合わせて構築していく概念です。
発表では、LINE Payのインシデント対応を例に、LLM Wikiの活用イメージが示されました。決済承認失敗率の急増という事象に対して、Slackでの議論、Jiraのチケット、Confluenceでの振り返り、Pull Requestなど、複数の成果物が生成されます。これらをJSON形式などでまとめてLLMに取り込ませることで、一連の出来事を横断的に理解できる知識ベースを構築できます。
LLM Wikiの基本的なライフサイクルは、Build、Ingest、Query、Lintの4段階で説明されていました。Buildでは最初にWikiの構造を定義し、IngestではSlackやJiraなどのrawデータをその構造に沿って取り込みます。その後Queryによって自然言語で質問できるようになり、最後にLintによって知識ベースの整合性や品質を維持していきます。
構造としては、raw、source、entity、concept、synthesisといった層に分けて情報が整理されます。rawは元データ、sourceは参照元の要約、entityは人物やシステムなどの対象、conceptはテーマや主題、synthesisはそれらを統合した知識と いった役割を持ちます。LLM Wikiは、単なるログやドキュメントの蓄積ではなく、「意味のある単位」に分解して再構築する点が特徴です。
Queryによる活用と、その結果の再取り込みも重要です。ユーザーが質問し、その回答が有用であれば、それ自体を新たな知識として再度Wikiに取り込むことができます。そのため、単なる検索システムではなく、利用するほど情報が蓄積・更新される知識ベースとして機能します。
一方で、こうした知識ベースは放置すると劣化していきます。発表では「腐敗」という言葉で表現されており、矛盾、古い情報、孤立したページ、未定義の概念、リンク切れ、データ不足、スキーマのずれといった問題が発生します。これらを防ぐためにLintを定期的に実行し、構造を保ちながら更新していく必要があると説明されていました。
また、LLM Wikiは単なる知識管理ツールではなく、「自分専用のキュレーター」を持つという考え方としても紹介されました。日々の活動や思考を継続的に取り込み、それをもとに意思決定を支援する存在として説明されていました。生成AIによってアウトプットの量が増えるほど、人間側の意思決定がボトルネックになりやすくなります。その点で、LLM Wikiのような仕組みは、情報を整理し意思決定を支える基盤として参考になります。
イベントで使用したSkillは、公開GitHubリポジトリ wasplinguist/my-llm-wikiでも提供されています。LLM Wikiのライフサイクルを実際に試したい方は、こちらのリポジトリでBuild、Ingest、Query、Lintの流れを確認できます。
なお、本ワークショップの詳細な内容や実装 方法については、LINEヤフー Tech Blogで詳しく公開されています。LLMを活用した知識管理や、個人・チームの知識基盤を構築したい方は、あわせて参照してください。
LINEヤフー Tech Blog / Git自動化で見るMCPとAgent Skillの長所・短所
発表資料：Personal knowledge bases using LLM（Speaker Deck）
おわりに
今回のイベントで多くの発表に共通していたのは、AIを単に「使う」のではなく、業務や開発プロセスに「組み込む」という発想です。プロンプトやツールを工夫するだけでなく、プロセス、データ、知識の管理まで含めて設計することで、継続して使える仕組みに近づくことが示されていました。
生成AIの進化によって、開発速度やアウトプット量は今後もさらに増えていきます。その中で重要になるのは、「何を作るか」「どこに時間を使うか」「どう意思決定するか」といった人間側の設計です。今回のイベントでは、各チームの具体的な取り組みを通じて、AI活用を自分たちの現場に取り入れるための視点が共有されました。
AI活用を進めている方にとっても、本イベントの取り組みは、自身の現場で試す際の参考になるのではないでしょうか。
Development with Agents Meetupは、こうした実践知を社内外に共有する場として、今後も継続的に開催します。ぜひ今後の取り組みにもご期待ください。
