--- title: "Agent Development Kit（ADK）で Google Cloud リリースノート取得・影響確認を自動化した気づき | grasys blog" url: "https://blog.grasys.io/post/nishino/designphilosophy-adk/" description: "Google Cloud のリリースノートの確認作業は利用サービスが増えるほど確認に時間がかかります。更新履歴を集めるだけでなく内容を読み、利用中のシステムに関係しそうな点を洗い出す作業になるからですね。 今回、 Agent Development Kit（ADK）を使ってリリースノートの取得から日本語レポートの作成…" --- # Agent Development Kit（ADK）で Google Cloud リリースノート取得・影響確認を自動化した気づき - ![](/_astro/noicon.CTHOhNiB_1HMs6A.webp)[nishino](/authors/nishino/) - 公開日：2026年7月15日 - カテゴリー：[Tech](/categories/tech/) - タグ：[#Agent Development Kit](/tags/agent-development-kit/)[#AIエージェント](/tags/aiエージェント/)[#Google Cloud](/tags/google-cloud/) ![Agent Development Kit（ADK）で Google Cloud リリースノート取得・影響確認を自動化した気づき](/_astro/hero.D-jsLC_T_Z1JLVSM.webp) Google Cloud のリリースノートの確認作業は利用サービスが増えるほど確認に時間がかかります。更新履歴を集めるだけでなく内容を読み、利用中のシステムに関係しそうな点を洗い出す作業になるからですね。 今回、 Agent Development Kit（ADK）を使ってリリースノートの取得から日本語レポートの作成までを1つの Workflow にしました。 具体的なコードはコーディング支援 AI Agent を活用して実装できます。そこで本記事では実装手順ではなく、どの工程を ADK の Agent に任せ、どこに人の判断を残すかという考え方など経験を書き残すので運用担当者や ADK の具体的な活用例を探している方の参考になればと思います。 ## リリースノート確認作業の役割を分ける | 作業 | 必要な判断 | この事例の担当 | | --- | --- | --- | | 取得と絞り込み | 対象サービス、対象日、公開日時を抽出して判定する | プログラム | | 翻訳 | タイトルと概要の意味を保って日本語にする | 翻訳 Agent | | 確認観点の作成 | 更新内容を読み、次に調べるリソースや設定を選ぶ | 確認観点生成 Agent | | 実際の影響判断 | 組織の構成や利用状況と照合する | エンジニア | 最初の作業は条件を列挙できるため通常のプログラムで処理できます。 翻訳と確認観点の作成は入力された文面に応じて出力を変える必要があります。 今回最も重要なのは3つ目の確認観点の作成です。 固定したサービス別チェックリストを返すのではなく、サービス名、タイトル、概要を材料に、今回の更新で次に調べる対象を組み立てます。 4つ目の影響判断にはリリースノートに含まれない慣習など組織固有の情報が必要です。 そのため、自動化のゴールを「影響あり、影響なしの判定」ではなく、「エンジニアが確認を始められる状態」に置きます。 ## ADK Workflow で構成した処理 [ADK の graph-based workflow](https://adk.dev/graphs/) は規則に従う処理と生成モデルを使う処理を node と edge で構成できます。 今回はその構造を使って取得からレポート出力までを次のようにつなぎました。 ![ADK Workflow で構成した処理の画面](/_astro/01-graph-agent-2-343x1024-bf519596.DIBTN3JP_4lb8.webp) 処理は七つの段階に分かれます。 | フロー | 処理 | ADK 上の表現 | | --- | --- | --- | | 対象の決定 | 対象期間とレポート種別を決める | Function node | | リリースノートの取得 | 複数サービスの配信フィードを取得する | 複数の Function node | | 取得結果の合流 | すべての取得結果を待ち、一定の順序へ戻す | JoinNode と Function node | | 更新有無の判定 | 更新ありと更新なしの経路を分ける | route | | 確認観点の作成 | 更新内容から次に確認する項目を作る | Agent node | | 翻訳 | タイトルと概要を日本語にする | Agent node | | レポート出力 | 取得した事実と Agent の出力を Markdown にする | Function node | 複数サービスの取得処理は互いに依存しないため、複数の branch へ分けて実行します。 取得後は JoinNode で合流して処理の完了順ではなく定義したサービス順で流します。 合流した結果に更新があれば、確認観点生成 Agent、翻訳 Agent、レポート出力の順に進みます。 更新がなければ確認観点生成 Agent を通らず、翻訳 Agent も生成モデルを呼ばずに通過して「更新なし」のレポートを出力します。 ## Function node と Agent node を使い分けた理由 Function と Agent という言い回しから察しがつくかもしれませんが次のとおりです。 対象日の計算、配信フィードの取得、日付による絞り込み、更新件数の判定、元リンクの保持、Markdown の組み立てでは指定した URL からの取得、日時の比較、項目のコピーといった手順をあらかじめ決めれるので Function node で構成します。 確認観点の作成ではサービス名、タイトル、概要に応じて次に確認する項目を変える必要があります。翻訳も入力されたタイトルと概要に応じて出力が変わるので Agent node で構成します。 結果的に生成モデルを使う範囲は確認観点の作成と翻訳の2つになりました。 ## 確認観点生成 Agent が行う一次解釈について 確認観点生成 Agent は、サービス名、リリースノートのタイトル、概要を受け取ります。 実装では、固定したサービス別チェックリストを使わず、入力された文面から確認項目を作るよう指示しています。人が1件ずつ文面を読み、調査の切り口を考える作業は Agent が目星をつけておきます。 出力は1件のリリースノートにつき3 ~ 5つの確認項目です。 各項目はリソース、設定、IaC、監視、展開方法、担当者について、エンジニアが次に確認する観点を示します。 翻訳 Agent はタイトルと概要だけを日本語にします。 確認観点生成 Agent が追加した項目や取得時に得たリンクと公開日時には触れず誤って要約の要約がされないようにします。 ### 2026年7月6日の BigQuery 更新 実行時に保存されたレポートから一件を抜粋します。 | 取得した項目 | | | --- | --- | | サービス | BigQuery | | 公開日時 | 2026-07-06T16:00:00+09:00 | | 元リンク | 2026年7月6日の BigQuery リリースノート | リリースノートには、変更点が次のように記載されています。 > For data transfers from Facebook Ads, support for the `AdInsightsMMM` report has been temporarily disabled. 既存の転送は動き続けるものの `AdInsightsMMM` のデータは含まれなくなると説明されています。 翻訳 Agent が作った概要は次の内容です。 > Facebook 広告からのデータ転送において、`AdInsightsMMM` レポートのサポートが一時的に無効化されました。 > `AdInsightsMMM` レポートを含む既存の Facebook 広告データ転送は引き続き実行されますが、転送には `AdInsightsMMM` レポートのデータは含まれません。 > この変更は、Facebook 広告 API のスキーマ変更によるものです。 確認観点生成 Agent が返した四点は次のとおりです。 - BigQuery Data Transfer Service で Facebook Ads 転送を利用している設定（特に `AdInsightsMMM` レポートを含むもの）の有無を確認する - `AdInsightsMMM` レポートのデータ欠落に伴い、下流のデータパイプライン、BI ダッシュボード、または分析クエリに影響がないか確認する - Facebook Ads API のスキーマ変更に伴う、データ転送設定の IaC（Terraform 等）の定義変更や更新の必要性を確認する - データ転送の実行ログやモニタリングアラートにおいて、本変更に伴う警告やエラーが発生していないか監視設定を確認する ## 取得した事実と Agent の出力を分けることについて レポートには元のリリースノートから取得した情報と Agent が生成した情報の両方を記載します。 今回の構成ではサービス名、公開日時、元リンクは取得時のまま残し、確認観点を作る工程、タイトルと概要を日本語にする工程だけを Agent に任せました。 元リンクを保持しているため、レポートを読んだエンジニアは必要に応じて元のリリースノートへ戻れます。 ただし、Agent に任せる範囲を絞っただけでは応答の抜けや重複までは防げません。 そこで、レポートへ反映する前にAgent に渡したリリースノートごとに応答が1件ずつそろっていることを確認します。 確認観点が1件につき3 ~ 5つあることも確かめて条件を満たさない応答は Markdown を出力する前にエラーにします。 応答がすべて揃って件数が正しくても確認観点が慣習や組織固有の構成に合っているとは限りません。 そこから先はエンジニアが判断することになります。 ## 慣習や組織固有の影響判断は人が行う 確認観点生成 Agent はリリースノートの内容から確認観点を作りますが、実際の影響有無は判定しません。 リリースノートだけでは組織がどのサービス、リソース、権限、ネットワーク、接続方式を使っているか分からないからです。 エンジニアは Agent が作った確認観点を構成管理情報、IaC、ログ、監視、運用手順、担当者の情報と照合します。 その結果を基に、対応の要否、優先度、検証方法を決めます。 このレポートはエンジニアが影響を調べて次の対応を決めるための手がかりになります。 ## 単純なプログラムやバッチとの違い リリースノートの取得、日付による絞り込み、翻訳、確認観点の作成は通常のプログラムやバッチでも実装できます。 生成モデルの呼び出しもバッチの一工程として実装ができるので必ずしも人の解釈を伴う処理を自動化するには ADK が必須ということではありません。 今回 ADK を選んだ理由は取得や絞り込みを行う Function node、確認観点の作成と翻訳を行う Agent node、人へ渡す出力を別々の責務として1つの Workflow として構成できることです。 構成は次のように整理できます。 | 状況 | 向いている構成 | | --- | --- | | 固定された規則で最終成果物を作れればよい | 通常のバッチ | | 既存バッチを Agent から起動したい | バッチ全体を一つの処理として呼び出す | | 取得や整形を行う Function node と複数の Agent node を分け、条件分岐を含む流れとして管理したい | ADK Graphs | | Agent の出力を人の判断へ渡す境界を明示したい | ADK Graphs | バッチ全体を一つの処理として呼び出すと、ADK から見えるのはバッチへの入力と実行結果です。 この構成でも既存処理を再利用できますが、取得、確認観点の作成、翻訳、人への引き渡しという分担はバッチの内部処理となります。 ADK Graphs ではこれらの責務と処理順序を node と edge で表せます。 ただし、node 間で受け渡す項目と Agent の応答を検証する処理も保守する必要があるため、一時的や使い捨ての用途であればバッチのほうが単純で良いです。 ## 人の解釈を含む作業を Workflow 化していく 文面を読み、確認すべき内容を考える作業を自動化するときは、このような役割分担を適用できます。 次の自動化対象を検討するときも、Agent の導入を出発点にせずにどの解釈を任せてどの判断を人に残すかを基に Workflow を構築します。 ## この記事を書いた人 [![](/_astro/nishino.qi9pzvtD_ZQ8ElO.webp)](/authors/nishino/) ### [nishino](/authors/nishino/) 食材も設計もコードもたくさん調理しますよ。 [プロフィールと記事一覧](/authors/nishino/)