Android のプラットフォーム変更を Devin + Gemini + GitHub Actions で週次自動監視する仕組み

Posted at 2026-02-24

はじめに

Android の targetSdkVersion 要件変更、ライブラリの breaking change、Security Bulletin など、20箇所以上に分散した情報ソースを Devin + Gemini + GitHub Actions で毎週自動チェックする仕組みを構築しました。約3.5 ACU/週・GHA（GitHub Actions）約10分/週で運用しています。

多数のクライアント向けにモバイルアプリを運用する中で、外部プラットフォームの変更見落としは常にリスクでした。月次のウォッチ体制は属人化しており、ライブラリの仕様変更はクライアントからの指摘で初めて気づくこともありました。前回の記事で紹介した社内コードの変更分析に続き、今回は外部変更の自動監視について、実際のレポート出力や運用で得られた知見を中心に紹介します。

全体の流れ

毎週 GitHub Actions が以下を順番に実行します:

依存インベントリ収集（GHA）: ./gradlew dependencies + Lint を実行し、プロジェクトの依存ライブラリ一覧と警告を JSON に変換
Devin による情報収集・分析（約3.5 ACU）: 20+の監視対象ソースをブラウザで巡回し、インベントリと突合してレポートを生成
Gemini によるファクトチェック（GHA）: Devin が生成した URL・バージョン番号・日付を Google Search で自動検証
配信（GHA）: breaking change の GitHub Issue 自動作成 + Slack 通知 + Docbase 反映

Devin の完了検知は ポーリングではなくイベント駆動 です。Devin が PR を作成 → auto-merge → main への push をトリガーにファクトチェックが起動します。

実際の出力例

レポートの JSON 出力

Devin が生成するレポートには、人間が読む Markdown セクションと、下流スクリプトが処理する 構造化 JSON が埋め込まれています。以下は実際のレポートから抜粋したものです。

検出された変更（changes）

{
  "id": "CHG-001",
  "title": "Android 17 Beta 1: 大画面デバイスでの画面回転・リサイズ制限オプトアウト廃止",
  "severity": "warning",
  "confidence": "high",
  "status": "carried_over",
  "published_date": "2026-02-13",
  "source_url": "https://android-developers.googleblog.com/2026/02/first-beta-android-17.html",
  "verification_status": "verified"
}

各変更に severity（breaking / warning / info）と confidence（high / medium / low）が付与されます。verification_status は Gemini によるファクトチェック結果です。

既知の問題トラッキング（known_issues）

{
  "library": "com.github.bumptech.glide:glide",
  "status": "バージョン不一致（安定版リリース済み）",
  "current_version": "4.16.0",
  "latest_version": "5.0.5",
  "migration_guide_url": "https://bumptech.github.io/glide/doc/download-setup.html"
}

廃止済みライブラリやバージョン不一致など、対応が完了するまで毎週自動でステータスを再確認し、レポートに含め続けます。

ビルド環境ヘルスチェック（build_health）

{
  "lint_summary": { "error": 0, "warning": 364, "information": 0 },
  "gradle_deprecations": { "total_count": 1 }
}

Lint 警告数と Gradle の非推奨警告を毎週記録し、プラットフォーム変更との関連性を分析します。例えば、Android 17 の画面回転制限廃止と LockedOrientationActivity 警告が紐付けられ、将来の targetSdk 引き上げ時に対応が必要であることが自動で報告されます。

Slack 通知

レポート確定後、Breaking/Warning の件数と概要が Slack に自動投稿されます。チェックしたソース数、検出した変更数、対応が必要な変更のタイトル一覧が含まれ、全文はリンク先のレポートで確認できます。

GitHub Issue 自動作成

severity: breaking の変更は GitHub Issue として自動作成されます。変更の概要、影響を受けるライブラリ、推奨アクション、対応期限が Issue に記載されます。source_url ベースで重複チェックを行い、基本的に同じ変更に対して Issue が重複作成されることはありません。

設定のポイント

プロンプト1ファイルで全て管理

project-root/
├── prompts/            # Devin への指示（~840行）+ Gemini のシステムプロンプト
├── .github/workflows/  # GHA ワークフロー（収集・監視・ファクトチェック・配信）
├── scripts/            # Python スクリプト（Slack通知・Issue作成等）
└── configs/            # 監視対象ソース URL・ライブラリ一覧

この仕組みの核は 約840行のプロンプトファイル 1つです。構造は大きく2つに分かれます:

不変の骨格: 出力フォーマット、分析手順、JSON スキーマ定義
可変のパラメータ: 監視対象ソース URL の一覧、既知の問題リスト、ビルド設定値

骨格部分の例として、未解決の変更を自動で引き継ぐルールがあります:

前回レポートの changes 配列から以下の条件に該当する変更を抽出:
- severity が breaking または warning
- confidence が high
- status が resolved でない
→ 今週のレポートに carried_over として引き継ぐ

ソースの追加・削除や分析観点の変更はプロンプトの編集だけで済みます。スクレイピングスクリプトの開発・保守が不要なのが、この構成の最大のメリットです。骨格部分と可変部分がセクションで明確に分離されているため、Git 上での差分レビューも容易です。監視対象の URL が 404 やリダイレクトになった場合も、Devin がレポート内に状況を記載し、プロンプト更新の PR として提出するため、監視網の腐敗もプロンプトの保守で吸収できます。URL 変更時はコメントで履歴を残すルールにしており、Git 上で変更理由を追跡できます:

<!-- removed 2026-02-18: https://example.com/old-page (404返却のため) -->
<!-- was: https://firebase.google.com/support/release-notes (updated 2026-02-20: リダイレクト検出) -->

信頼度スコアの判定基準

変更の信頼度はコードによるアルゴリズムではなく、プロンプト内で Devin に判定基準を指示しています:

■ 依存系の変更（ライブラリ更新・廃止等）:
  - High: inventory の依存一覧にライブラリが存在し、かつ影響バージョンが一致する
  - Medium: inventory の依存一覧にライブラリが存在するが、影響バージョンの一致は未確認
  - Low: 依存一覧との一致が確認できない（間接的な影響の可能性）

■ プラットフォーム系の変更（OS要件・ストア規約）:
  - High: ビルド設定値（targetSdk, minSdk, compileSdk等）が変更の条件に該当
  - Medium: 該当する可能性があるが、設定値との照合が不完全
  - Low: 直接的な関連性は低い

ファクトチェック

Devin が生成したレポートの URL・バージョン番号・日付を、Gemini API の Google Search 統合機能 で自動検証します。結果は ✓（確認済み） / ✗（誤り） / ?（確認不可） の3段階で報告されます。

例えば、Devin が「ライブラリ X が v3.0.0 をリリース」と報告した場合に、Gemini が「実際は v3.0.0-beta02 であり正式リリースは未公開」と検出するケースがあります。こうした beta と正式版の取り違えは、手動チェックでは見落としやすい誤りです。

また、プロンプト側でも source_url の具体性を強制し、ハルシネーションを抑制しています:

source_url は該当する変更が記載されている具体的なページの URL を記載すること。
トップページやインデックスページの URL は不可。

✗ https://firebase.google.com/support/release-notes
○ https://firebase.google.com/support/release-notes#2026-01-28

✗ が検出された場合の内容修正は人間がレビューして判断します。完全自動修正にしない理由は、文脈を踏まえた修正判断（項目の削除か訂正か）はまだ人間が行うべきと考えているためです。

コスト

項目	コスト
Devin	約3.5 ACU/週（月約14 ACU）
Gemini API	数円/回
GitHub Actions	inventory 収集 + ファクトチェック + 配信で計約10分/週（Devin は非同期で別枠）

プロンプト1ファイルで管理しているため、スクレイピングコードの開発・保守が不要 です。障害対応の主戦場がコードではなくプロンプトに寄り、監視対象の追加もソース URL を1行追加するだけで済みます。10分の内訳は、依存/警告収集が約6分、ファクトチェックが約2分、配信が約2分です。

やってみてわかったこと

GitHub Actions への情報収集移行を試みて撤回した話

「URL 巡回は Devin でなくてもできるのでは」と考え、GitHub Releases の API 取得や RSS フィード解析を GHA スクリプトに移行する改修を行いました。技術的には問題なく動作しましたが、結果として ACU 削減効果がほとんどなく、管理の複雑性だけが増えた ため撤回しています。

URL 巡回は Devin の作業全体の 25-30% 程度で、残りの大部分はインベントリとの突合分析やレポート生成です。巡回を GHA に移しても 3.5 ACU が 3.0 ACU になる程度の差にしかならず、代わりにコレクタスクリプト4本 + ワークフロー1本 + 設定ファイル改修という保守コストが発生しました。

教訓: プロンプト1ファイルで完結する手軽さは、それ自体が大きな価値。技術的に正しい最適化でも、運用全体のコストを考慮すると割に合わないことがあります。最適化の評価軸は ACU の削減量ではなく、保守対象の数で考えるべきでした。

Devin の強みは巡回ではなく判断にある

この経験を通じて、Devin の真の強みは URL を巡回できることではなく、収集した情報とプロジェクトの依存関係を突合して影響度を判断できること だと実感しました。RSS/API で機械的に情報を集めることは簡単ですが、それが自分たちのプロジェクトにどう影響するかを分析する部分にこそ AI エージェントの価値があります。

おわりに

この記事では、Devin + Gemini + GitHub Actions によるプラットフォーム変更の自動監視について、実際の出力例と運用知見を中心に紹介しました。

前回記事では社内コードの変更分析、今回は外部プラットフォームの監視と、AI エージェントの活用範囲を段階的に広げてきました。現在は Android で先行導入したこの仕組みを、iOS やサーバサイドなど他プラットフォームにも展開する準備を進めています。さらに、Devin の役割を「情報収集・レポート作成」から 「検出した変更に対する修正 PR 作成」 に進化させることを構想しています。breaking change が検出されたら、Devin にコードベースの影響範囲調査と修正 PR の作成まで依頼し、人間は PR をレビューするだけ — という流れです。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up