Agent Development Kit (ADK) で学ぶ実践Context Engineering と社内での応用例 LINE ヤフー Development with Agents Meetup #3 LINE ヤフー株式会社 Shuichi Inoue (Hideichi) 1 

自己紹介 井上 秀一 / Hideichi 社内向け Kubernetes as a Service 基盤 FKE の運用 開発 社内で AI Agent の組織展開 を推進 趣味: ドライブ・映画・美味しいものを食べる 2 

本日のゴール AI Agent のコストと精度を 同時に改善する設計手法を持ち帰る Take Away (15 分後に得られるもの) 1. Context Engineering の概念と、なぜ今必要か 2. ADK での実装パターン（核心3 つ） 3. 社内実業務での応用例（FKE の CS 対応） 4. 明日からチームで始められる 3 ステップ 3 

Agenda 1. AI Agent 活用で起きている課題 2. Context Engineering とは 3. ADK での実装パターン 4. 社内実業務での応用例（FKE CS 対応） 5. まとめと明日のアクション 4 

AI Agent 活用で起きている課題 1 章 AI Agent 活用で起きている課題 5 

AI Agent の活用は急速に広がっている 利用が当たり前になったツール Claude Code 、Cursor 、Cline 、Codex Agent Development Kit (ADK) など Multi-Agent フレームワーク 各種MCP (Jira 、Confluence 、社内API 、...) 一方で… 「使えば使うほど課題が顕在化してきた」 1 章 AI Agent 活用で起きている課題 6 

顕在化している3 つの課題 立場 課題 組織 Token コストが予算を圧迫 エンジニア AI Agent が 期待通りに動かない エンジニア 長い Context で 精度が落ちる（Context Rot ※） 「プロンプトに書いてあるのに無視される」 「会話が長くなると変な回答になる」 ※ Context Rot: 長文脈で AI の出力品質が劣化する現象 1 章 AI Agent 活用で起きている課題 7 

これらの課題は別々の問題ではない すべては… 「AI に渡す情報の設計問題」 に収束する 個別ツールのチューニングでは限界 Claude Code を頑張る、Cursor を頑張る… では追いつかない 共通する設計原則 が必要 1 章 AI Agent 活用で起きている課題 8 

Context Engineering とは 2 章 Context Engineering とは 9 

定義 推論時にモデルに渡される すべての情報を選別・管理する技術 「すべての情報」とは システムプロンプト (Agent の役割・ルール) ツール定義 ( 利用可能な Tool の説明) 会話履歴 ( 過去のターン) 外部データ (RAG 、MCP 経由で取得した情報) 2 章 Context Engineering とは 10 

Token / Context / Context Window の関係 概念 説明 イメージ Token LLM が扱うテキストの最小単位 1 文字・1 単語 Context LLM に渡すすべての情報 会話の「中身」 Context Window 一度に処理できるToken 上限 会話を入れる「器」 2 章 Context Engineering とは 11 

Prompt Engineering との違い 観点 Prompt Engineering Context Engineering 何を設計 AI への指示文 AI が参照する記憶と環境全体 スコープ プロンプトに集中 プロンプト + ツール + データ + 履歴 適用場面 単発タスク マルチターン / Agent 運用 最適化対象 指示の明確さ Token 効率・コスト・スケーラビリティ Agent 時代は Context Engineering が必須 2 章 Context Engineering とは 12 

核心原則: Token は有限なリソース "Find the smallest set of high-signal tokens" 最小限の、高品質なトークンセットを見つける つまり コスト ↓ : 不要な情報を削る → API 費用削減 精度 ↑ : ノイズを排除 → AI が重要な指示に集中 コストと精度はトレードオフではなく 両立可能 2 章 Context Engineering とは Reference: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents 13 

普遍的な原則 ADK / Claude Code / Cursor / Codex どのツールでも共通する設計原則 今日の話の進め方 概念だけで終わらせない ADK での実装パターン に落とす（次章） 実業務に適用した事例 を共有する（5 章） 2 章 Context Engineering とは 14 

ADK での実装パターン 3 章 ADK での実装パターン 15 

Agent Development Kit (ADK) とは Google が公開する Multi-Agent System 構築用の OSS AI Agent の動作を ソフトウェア的に定義・制御 できる Multi-Agent （複数 Agent の連携）を簡単に組める Tool / MCP に標準対応 Tips Google 製だが Google Cloud がなくても動く 3 章 ADK での実装パターン Reference: https://google.github.io/adk-docs/ 16 

なぜ ADK か（1/2 ）: Local vs Remote の構造的な違い 個人ツール（Claude Code / Codex ） Local で動作 → 個人の使い方・スキルに依存 Context Engineering のコツも 個人の中に閉じる 組織単位でのオプトインにならない ADK は Remote にホストできる 業務タスクに最適化した Agent を API Server / Web UI で公開 一人が設計した Agent を全員が使える → Context Engineering の恩恵が 組織全体に行き渡る 3 章 ADK での実装パターン 17 

なぜ ADK か（2/2 ）: 標準で揃っている機能 特徴 機能 Multi-Agent 業務フローに基づき Agent を設計可能 Web UI デバッグ / Agent 動作の追跡 API Server 既存システムとの統合・Remote 公開 Tool / MCP 外部システム連携を標準サポート → 「Remote にホストできる Multi-Agent 」 が標準で揃っている 3 章 ADK での実装パターン 18 

よくある Agent 構成: Sub-agents Parent Agent の下に 子 Agent を配置 して階層構造を作る、Multi-Agent の標準パター ン Minimal Context per Agent Delegate Delegate Delegate Result Result Result User Request Parent Agent (Orchestrator) Sub-agent A (Search) Sub-agent B (Analysis) Sub-agent C (Report) Context A + Tool A only Context B + Tool B only Context C + Tool C only 呼び出し方は2 通り → Agent Transfer か AgentTool （後ほど対比） 3 章 ADK での実装パターン Reference: https://google.github.io/adk-docs/agents/multi-agents/ 19 

よくある実装だと… 親の履歴が膨張する Parent から見た会話履歴は 子の内部処理がすべて積もる Parent Agent の Context （履歴） ───────────────────────────────────── [User Query] [Parent: 子に委譲] [ 子: Tool A 呼び出し → 大量のレスポンス] [ 子: 中間推論…] [ 子: Tool B 呼び出し → 大量のレスポンス] [ 子: 最終回答] [Parent: 整形して返答] ───────────────────────────────────── → Context 膨張 / Token 浪費 / ノイズで判断ブレ 3 章 ADK での実装パターン 20 

Context Engineering に効く3 つのコンポーネント ADK の Key Components の中から、 Context Engineering に 直接効く3 点 に絞って紹介 1. AgentTool: Context 分離 2. tool_filter : 不要 Tool の削減 3. Structured Output: 構造化出力 3 章 ADK での実装パターン 21 

① AgentTool: Context 分離 子 Agent を Tool としてラップ すると、内部の Context が呼び出し元に漏れない AgentTool Internal Delegate task Final output only Input Agent AgentTool (Another Agent) Output Tool A Tool B Own Context 3 章 ADK での実装パターン Reference: https://google.github.io/adk-docs/ 22 

① AgentTool でどう変わるか Parent Agent の Context （履歴） ───────────────────────────────── [User Query] [Parent: AgentTool 呼び出し] [AgentTool: 最終出力のみ] ← 内部処理は隠蔽 [Parent: 整形して返答] ───────────────────────────────── 効果 子の Tool 呼び出し・中間推論は親に漏れない 親には 最終出力のみ が返る → Context 節約 3 章 ADK での実装パターン Reference: https://google.github.io/adk-docs/ 23 

② tool_filter : 不要 Tool の削減 MCPToolset で 必要な Tool だけ をエージェントに提供 mcp_tool = MCPToolset( connection_params=..., tool_filter=["search_pages", "get_page"], ) 効果 Tool 定義自体が Context を食う → Token 節約 LLM が選ぶ候補が絞られる → 判断精度向上 3 章 ADK での実装パターン Reference: https://google.github.io/adk-docs/tools-custom/mcp-tools/ 24 

③ Structured Output: 構造化出力 output_schema で出力を JSON 形式に強制 class TicketSummary(BaseModel): ticket_id: str status: str next_action: str agent = LlmAgent( name="summarizer", output_schema=TicketSummary, # 出力をJSON 強制 ) 効果 不要な自由テキストを排除 → 次 Agent への受け渡しが決定的 3 章 ADK での実装パターン Reference: https://google.github.io/adk-docs/agents/llm-agents/ 25 

実験対象: jira_weekly_report とは 社内ワークショップ用の検証 Agent やること Jira からチームのチケット一覧を取得 各チケットの 内容・コメントを分析・要約 Markdown 表形式の 週次レポート を出力 出力イメージ Key Summary Status Assignee Report XXXX-1234 ... In Progress ... チケットの要約... XXXX-1235 ... To Do ... チケットの要約... 3 章 ADK での実装パターン Reference: https://google.github.io/adk-docs/agents/llm-agents/ 26 

実験対象 (1/2): jira_weekly_report v1 （Before ） 1 つの Agent が全部やる構成 Tool 層 Agent 層 検索 / 取得 ( チケット数だけ ループ) Input Output: Report jira_weekly_report_v1 （Single Agent ） Jira MCP 検索 → 取得をループするうちに、全チケットの詳細・コメント・履歴が Context に累積 3 章 ADK での実装パターン Reference: https://google.github.io/adk-docs/agents/llm-agents/ 27 

実験対象 (2/2): jira_weekly_report v2 （After ） AgentTool / tool_filter / output_schema を適用 → 内部 Context は親に漏れない Tool 層 Agent 層 AgentTool 内部 ∕ Context 分離 AgentTool 呼び出し { issue_key } Structured Report （output_schema で決定的） 検索 取得 Input Output: Report jira_weekly_report_v2 （Root Agent ） tool_filter: 検索のみ single_ticket_analysis_agent tool_filter: 取得のみ output_schema: 構造化Report Jira MCP 3 章 ADK での実装パターン Reference: https://google.github.io/adk-docs/agents/llm-agents/ 28 

実験結果: v1 → v2 で何が変わったか 指標 v1 (Before) v2 (After) 削減 Context Window 使用率（root_agent ） 33.49 % 7.46 % 77.7 % 減（26 pt 減） システム全体の総 Token 174,643 103,583 40.7 % 削減 3 章 ADK での実装パターン Reference: https://google.github.io/adk-docs/agents/llm-agents/ 29 

コスト試算: 組織規模で効いてくる 前提: 月4 回 × 12 ヶ月 = 年48 回/ チーム 利用 Model 規模 v1 v2 年間削減額 gpt-5-mini 1 回あたり ¥14 ¥8 ¥6 100 チーム（年 4,800 回） ¥6.7 万 ¥4.0 万 ¥2.7 万 1,000 チーム（年 48,000 回） ¥67 万 ¥40 万 ¥27 万 gpt-5 1 回あたり ¥69 ¥41 ¥28 100 チーム（年 4,800 回） ¥33 万 ¥20 万 ¥14 万 1,000 チーム（年 48,000 回） ¥333 万 ¥197 万 ¥136 万 ※ 料金: gpt-5-mini Input $0.25 / Output $2.00, gpt-5 Input $1.25 / Output $10.00 per 1M tokens ／ Input:Output = 85:15 ／ $1 = ¥155 換算 3 章 ADK での実装パターン Reference: https://platform.openai.com/docs/pricing 30 

実験結果の前提 ワークロード: Jira 週次レポート生成（単一ワークロード） 試行回数: v1 / v2 をそれぞれ 10 回試行した平均値 モデル: GPT-5 （Context Window 400K Token ） v1 → v2 の差分: AgentTool / tool_filter / output_schema のみ 外挿の注意: 自組織で再現する際は 再計測が前提 3 章 ADK での実装パターン 31 

社内実業務での応用例 FKE の CS 対応に Multi-Agent を導入 4 章 社内実業務での応用例 32 

適用先: FKE の CS 対応 LINE ヤフー社内向け KaaS (Flava Kubernetes Engine) の CS 対応業務 CS 対応で時間がかかる要因 問い合わせごとに Jira （過去事例）/ Confluence （Docs ）/ Cluster （状態） を 横断調査 1 チケットあたり数十分〜数時間の調査時間 全チケット分の対応 → CS メンバーの工数を 大量に消費 AI Agent で一次調査を自動化したい ただし、1 Agent で全部やると Context が膨張・判断もブレる → 設計が肝 4 章 社内実業務での応用例 Reference: https://speakerdeck.com/lycorptech_jp/flava-kubernetes-engine-towards-intuitive-platform 33 

全体構成: 4 段階の Multi-Agent System Multi-Agent System (Sequential) ③ 翻訳 (Parallel) en 翻訳 jp 翻訳 ① 調査 (Sequential) 過去調査 (Parallel) Jira 過去事例 Confluence Docs Cluster 状態 起点解析 CS チケット GitHub Issue へ蓄 積 ② 統合‧要約 ④ Issue 投稿 SequentialAgent の中に ParallelAgent をネスト して責務を分離 4 章 社内実業務での応用例 34 

設計判断 ①: なぜ Agent を細かく分けたか 単一 Agent で全部やろうとすると… 起点解析 / 過去事例 / Docs 検索 / Cluster 調査 / 要約 / 翻訳 / 投稿 プロンプトが肥大、Context が膨張、判断がブレる → 責務ごとに Sub-agent + Sequential / Parallel で連結 各 Agent は 単一責務 に絞る → プロンプトを最小化 ParallelAgent で独立データソース（Jira / Confluence / Cluster ）を並列実行 → 速度も上がる 4 章 社内実業務での応用例 35 

設計判断 ②: Context を切る — include_contents="none" + State 通常は親の会話履歴が子 Agent にも渡る 上流の試行錯誤・取得データが下流の Context を圧迫 （例: 翻訳 Agent が 前段の Agent ログまで翻訳 しようとして崩れる） 解: include_contents="none" + State で受け渡し include_contents="none" : 親の会話履歴を子に渡さない State: ADK の Session 共有 key-value ストア（全 Agent が R/W 可能） 前段が output_key="…" で書く → 後段が {state_key} で参照 → 各 Agent には 「いま見るべき情報だけ」 が渡る 4 章 社内実業務での応用例 36 

設計判断 ③: 各 Agent の Tool を最小化 内部システムには 用途別の専用 Python Tool を用意 Agent 渡す Tool Jira 過去事例検索 JiraTool の検索 / 取得関数のみ Docs 検索 ドキュメント RAG の search のみ Cluster 状態調査 MgmtClusterViewer の状態確認系関数のみ Issue 投稿 GitHubTool のみ 効果と原則 LLM の判断候補が絞られて 判断が安定／Tool 定義 Token も削減 ※ §4 の tool_filter （MCP 用） と 同じ原則 を Python 関数粒度で適用 4 章 社内実業務での応用例 37 

設計の成果（投入後初月） 大幅な時間削減 解決時間: 平均 −55% 作業時間: 平均 −57% 仕組みの効果 CS チケット起票時に 自動で動作 する設計 チーム全員が Report を受け取れる 構造 → 個人ではなく チーム全体 の効率化に成功 4 章 社内実業務での応用例 38 

ADK Context Engineering の全体像 5 章 ADK Context Engineering の全体像とまとめ 39 

今日深掘りした3 つは「氷山の一角」 ADK には 他にも Context Engineering に効くコンポーネントが揃っている レイヤー コンポーネント 主な効果 データ State , output_schema 情報の効率的な保存・構造化 Context 最適 化 include_contents , Context Filter Plugin, Callbacks 不要な情報の排除・圧縮 アーキテクチ ャ AgentTool , MCPToolset ( tool_filter ) , Sub- agents 責務分離による Context 分離 ワークフロー Workflow Agents (Sequential / Parallel / Loop) 決定論的振る舞い による Token 削減 = 今日深掘りした3 点／組み合わせて使える のが ADK の強み 5 章 ADK Context Engineering の全体像とまとめ Reference: https://google.github.io/adk-docs/ 40 

締めメッセージ Context Engineering は単発の最適化ではなく コンポーネントの組み合わせで効いてくる 今日紹介した3 つを入口に、 ADK の他のコンポーネントも触ってみてください 5 章 ADK Context Engineering の全体像とまとめ 41 

Thank You Links ADK Docs: https://google.github.io/adk-docs/ LY Tech Blog: https://techblog.lycorp.co.jp/ja/20251211a FKE 公開資料: https://speakerdeck.com/lycorptech_jp/flava-kubernetes-engine- towards-intuitive-platform 前回登壇 Meetup #1: https://lycorptech-jp.connpass.com/event/379357/ Speaker LINE ヤフー株式会社 Shuichi Inoue (Hideichi) 42