Canary 継続配信になった Android 17 で、エージェントには「報告しない条件」から先に渡しました

交差した行だけを残し、終了コードで沈黙を表す

次に、変更点の一覧とこのインベントリを突き合わせます。要点は、出力よりも終了コードで結論を返すことです。エージェントは文章を読んで判断するのではなく、コードを見て次の行動を決められます。

#!/usr/bin/env python3
"""変更点の一覧から、自分の実装に触れる行だけを残す。
 
    python3 relevance_filter.py inventory.tsv changes.txt
 
終了コード（エージェント側の分岐に使う）:
    0  … 自分に関係する変化はなかった（報告しない）
    10 … 関係する変化があった（報告する）
    2  … 入力が読めなかった（設定の間違い。黙って 0 を返さない）
"""
import re
import sys
from pathlib import Path
 
# 一般語と衝突する断片は単独キーにしない。誤検出の主因はここでした。
GENERIC = {
    "internet", "wake_lock", "vibrate", "camera", "storage",
    "notification", "notifications", "service", "activity", "manager",
}
 
 
def keys_for(symbol: str) -> set:
    """android.app.WallpaperManager -> 全体 / app.wallpapermanager / wallpapermanager"""
    parts = [p for p in re.split(r"[.\s]", symbol) if p]
    out = {symbol.lower()}
    if parts:
        last = parts[-1].lower()
        if last not in GENERIC and len(last) > 3:
            out.add(last)
    if len(parts) >= 2:
        out.add(f"{parts[-2]}.{parts[-1]}".lower())
    return out
 
 
def load_inventory(path: Path) -> dict:
    table = {}
    for line in path.read_text(encoding="utf-8").splitlines():
        if not line.strip():
            continue
        kind, _, symbol = line.partition("\t")
        if not symbol:
            continue
        for key in keys_for(symbol):
            if len(key) > 3:
                table.setdefault(key, f"{kind}:{symbol}")
    return table
 
 
def main() -> int:
    if len(sys.argv) != 3:
        print(__doc__, file=sys.stderr)
        return 2
    inv_path, changes_path = Path(sys.argv[1]), Path(sys.argv[2])
    if not inv_path.is_file() or not changes_path.is_file():
        print(f"入力が読めません: {inv_path} / {changes_path}", file=sys.stderr)
        return 2
 
    table = load_inventory(inv_path)
    if not table:
        print("インベントリが空です。抽出側が壊れている可能性があります。", file=sys.stderr)
        return 2
 
    hits = []
    for lineno, raw in enumerate(changes_path.read_text(encoding="utf-8").splitlines(), 1):
        low = raw.lower()
        why = sorted({w for key, w in table.items() if key in low})
        if why:
            hits.append((lineno, raw.strip(), why))
 
    if not hits:
        print("関係する変化はありません。")
        return 0
 
    for lineno, text, why in hits:
        print(f"L{lineno}: {text}")
        for w in why:
            print(f"    ← {w}")
    print(f"\n該当 {len(hits)} 件 / 監視対象 {len(table)} キー")
    return 10
 
 
if __name__ == "__main__":
    sys.exit(main())

五行の変更点リストを通すと、残るのは二行だけでした。

L1: Behavior change: WallpaperManager.setBitmap now throws when the caller is in the background.
    ← import:android.app.WallpaperManager
L4: Foreground services with type dataSync are limited to 6 hours per day.
    ← service-type:dataSync

該当 2 件 / 監視対象 18 キー

残り三行は、Credential Manager や Camera2 や Compose の話でした。どれも重要な変更ですが、いま私の手元のコードには触れていません。読まないという判断が、これで機械的に下せるようになりました。

一般語が沈黙を壊しました

最初に書いた版では、GENERIC の集合がありませんでした。末尾の識別子をそのままキーにしていたのです。

その版で試したとき、こういう行が該当として返ってきました。

L1: Chrome now blocks mixed content over the internet.
    ← permission:android.permission.INTERNET
L2: Android 17 tightens INTERNET-less loopback access.
    ← permission:android.permission.INTERNET

android.permission.INTERNET から internet という単語をキーにしていたため、英文に自然に出てくる「インターネット」がすべて一致していました。ほとんどのアプリが宣言している権限が、ほとんどの文章に一致するキーを持っている。この組み合わせは、フィルタとしては最悪の性質です。関連性フィルタを書くときの典型的な落とし穴で、回避の仕方そのものは単純でした。一般語と衝突する断片を集合として先に列挙し、単独のキーには使わないと決めるだけです。

キーの総数で言えば 19 から 18 に減っただけの修正でした。ですが、この 1 個が沈黙を壊していました。誤検出は「余分な通知が来る」という害に見えて、実際には「通知そのものが信用されなくなる」という害を出します。一度そうなると、正しい通知も読まれません。

私自身、この修正を入れるまでは検出漏れのほうばかり心配していました。関係する変更を見落としたら困る、と。実際に危なかったのは反対側だったわけです。

最後の行が、あとから足したものです。何も報告が来ない状態は、平穏なのか壊れているのか、外からは同じに見えます。インベントリが空になったら終了コード 2 で騒ぐ、と決めておくことで、静けさを信用できるようになりました。

エージェントに渡した指示は三行で足りました

Antigravity 側に渡している内容は、意外なほど短いものです。判断の重心をスクリプトに寄せたぶん、指示文が痩せました。

1. `./inventory.sh .` を実行し、出力を inventory.tsv に保存する
2. 監視元の変更点テキストを changes.txt として取得する
3. `python3 relevance_filter.py inventory.tsv changes.txt` を実行する
   - 終了コード 0 … 何もしない。報告も残さない
   - 終了コード 10 … 出力をそのまま添えて報告する。要約や言い換えはしない
   - 終了コード 2 … 「監視が壊れています」として報告する

三番目の「要約や言い換えはしない」が、運用してみて効きました。エージェントに要約させると、読みやすい代わりに、原文にあった条件（どの API レベルから、どの種別に限って）が落ちることがあります。該当が二行しかないのなら、そのまま二行渡してもらうほうが速いですし、判断を誤りません。

要約が価値を生むのは対象が多いときです。フィルタが効いていれば対象は少なく、少ないなら要約は不要になります。フィルタと要約は、どちらかが効いていればもう一方は要らない関係にありました。

四半期のチェックポイントで人間が見る三点

週次の判定を機械に任せた代わりに、自分で見る場所を決めました。区切りを外から与えられなくなったのだから、自分で置くしかありません。

1. インベントリの差分 — 前回からどの API・権限・種別が増えたか。新しく触れ始めた面は、新しい監視対象です
2. 保留にした非推奨化の期限 — 週次では黙らせている項目を、ここでまとめて棚卸しします
3. 実機での起動確認 — Canary を入れた端末で、壁紙の適用と通知だけ通す最小の確認をします

三点に絞ったのは、多くすると実行されないからです。個人開発の運用ルールは、守れる分量で書かなければ、書いていないのと同じになります。

見落としたときの受け皿を先に用意しておく

このフィルタは、必ずいつか漏らします。リリースノートに書かれていない挙動変更は原理的に拾えませんし、書かれていても言い回しが違えば一致しません。

ですから、検知の精度を上げる努力と同じくらい、漏れた前提の受け皿に手をかけています。私の場合は Google Play の段階公開がその役割です。小さな割合から配信を始め、クラッシュ率と ANR の推移を見てから広げる。本番環境で異常が出たときに配信を止められる状態を保っておけば、検知の取りこぼしは事故ではなく手戻りで済みます。この手順は Android 17 に限らず使っている運用ですが、外部から与えられる検証の区切りが消えたぶん、比重が上がりました。

停止基準そのものの設計はエージェントに段階公開の停止基準を判定させる設計で、実際に踏んだ Android 17 の個別対応はローカルネットワーク権限の呼び出し箇所を機械で洗い出した記録と大画面での向き・リサイズ制限の棚卸しにまとめています。

次に手を付けるなら

もし同じ構成を組むなら、フィルタを書く前に、まず紙でもエディタでも構いませんので「これは報告されなくてよい」と言い切れる変化を五つ書き出してみてください。五つ書けるなら、その基準はコードにできます。書けないうちにフィルタを書くと、条件が「関係ありそうなもの」という曖昧な形になり、一般語の一致で沈黙が壊れます。私が遠回りしたのがまさにその順番でした。

最後までお読みいただき、ありがとうございました。継続配信という配信形態は、まだ私も付き合い方を探っている最中です。よい落としどころが見つかったら、また記録として残そうと思います。