Google アシスタントの置き換えは戻せないので、基準線は今しか取れません

基準線として残す項目を絞る

記録する項目が増えるほど、後から読むのが億劫になります。9月4日までに確実に運用へ載せたいので、5項目に絞りました。

DAU やリテンションのような大きい数字は、ここでは主役になりません。音声起点の起動がもし全体の数%なら、その半減は DAU のグラフでは誤差に沈みます。沈む数字を、沈まない粒度で持っておく作業です。

AdMob の収益側も同じ理由で分けて見ています。入口が細っても表示回数の総量は他の入口が補ってしまうため、収益のグラフは最後まで動きません。

集めた発話を Gemini で分類して、分布の変化を見る

発話文字列は、1件ずつ読んでも意味がありません。「壁紙 変えたい」「壁紙アプリ 開いて」「浮世絵の壁紙 出して」が同じ意図なのか違う意図なのかは、件数が増えるほど手作業では判断できなくなります。

そこで週次で Gemini に分類させ、クラスタごとの件数だけを時系列で持ちます。分類の粒度が週ごとにぶれると比較にならないので、カテゴリは固定して渡します。

# weekly_utterance_profile.py — 週次で発話をクラスタ分類し、件数分布だけを残す
import os
import json
from collections import Counter
from google import genai
from pydantic import BaseModel
 
client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])
 
# 粒度を固定する。ここを毎週変えると前週と比較できなくなる
CATEGORIES = [
    "open_app",          # アプリを開くだけ
    "change_wallpaper",  # 壁紙の変更・設定
    "search_theme",      # 特定のテーマや題材を指定
    "control_playback",  # 再生・停止などの操作
    "other",
]
 
class Labeled(BaseModel):
    index: int
    category: str
 
class Batch(BaseModel):
    items: list[Labeled]
 
def classify(utterances: list[str]) -> Counter:
    numbered = "\n".join(f"{i}: {u}" for i, u in enumerate(utterances))
    prompt = (
        "次の発話を、指定カテゴリのいずれか1つに割り当ててください。\n"
        f"カテゴリ: {', '.join(CATEGORIES)}\n"
        "判断がつかない場合は other にしてください。\n\n"
        f"{numbered}"
    )
    # temperature / top_p / top_k は非推奨のため指定しません
    res = client.models.generate_content(
        model="gemini-3.7-flash",
        contents=prompt,
        config={
            "response_mime_type": "application/json",
            "response_schema": Batch,
        },
    )
    parsed = Batch.model_validate_json(res.text)
    counts = Counter()
    for item in parsed.items:
        # モデルが未知のカテゴリ名を返した場合の保険
        counts[item.category if item.category in CATEGORIES else "other"] += 1
    return counts
 
def profile(week_id: str, utterances: list[str], batch_size: int = 80) -> dict:
    total = Counter()
    for i in range(0, len(utterances), batch_size):
        total += classify(utterances[i : i + batch_size])
    n = sum(total.values()) or 1
    return {
        "week": week_id,
        "n": n,
        "share": {c: round(total[c] / n, 4) for c in CATEGORIES},
    }
 
if __name__ == "__main__":
    with open("utterances_2026w34.json", encoding="utf-8") as f:
        rows = json.load(f)
    print(json.dumps(profile("2026-W34", rows), ensure_ascii=False, indent=2))

temperature を指定していないのは、書き忘れではありません。サンプリングパラメータは非推奨になっているため、いま新しく書くコードで明示指定を増やしたくない、という判断です。非推奨後に何が変わるかについてはtemperature 非推奨で先に困った側に別途書きました。

出力は件数ではなく比率で持ちます。週ごとに母数が変わるので、件数のままだと利用の増減と分布の変化が混ざります。

端末を1台だけ先に切り替えるという判断

自分の検証端末をどう扱うかで、3つの選択肢がありました。

私は真ん中を選びました。手元で比較できる期間が短いほど、あとで届く「音声で開けなくなった」という報告を、置き換えのせいなのか自分のアプリ側の変更のせいなのか切り分けられなくなります。

この場合は、切り替える1台を主力ではない端末にするのを推奨します。日常的に使っている端末を先に切り替えると、自分の使い方が変わったのか挙動が変わったのかが混ざります。私は普段テストにしか使っていない端末を先に寄せました。

予想と違ったのは、記録よりも解釈の側でした

作業を始めた時点では「記録さえ取れば、9月4日で線を引いて前後を比べられる」と考えていました。ここが外れました。

置き換えは9月4日に一斉に起きるのではなく、順次で、完了までに数週間かかります。つまり同じ日の同じイベントログの中に、置き換え済みの端末と未置き換えの端末が混在します。日付で before と after を切ると、after 側に大量の before が混ざり、差は薄まって見えます。差が薄いのか、混ざって薄く見えているのかを、日付だけでは区別できません。

しかも、アプリ側から「この端末はどちらのアシスタントか」を知る手段は用意されていません。端末が自己申告してくれない以上、外から与えた日付で分けるやり方は原理的に精度が出ません。

そこで、切り替えの推定を外側の日付から内側の指標へ移しました。発話の言い回しの分布が動いたかどうかを見るほうが、日付よりも実態に近いはずだと考えたからです。移行期間の途中で other の比率だけが上がるなら、それは利用の減少ではなく言い回しの変化を示している可能性が高くなります。

Gemini によるクラスタ分類を入れた本当の理由は、分析を高級にしたかったからではありません。日付で前後を切れないと分かったからです。順番が逆だったら、たぶん比率ではなく件数を眺めて満足していたと思います。

停止や置き換えの前に何を数え始めるかという話は、モデル停止のときにも同じ形で出てきました。そのときの棚卸しの手順は停止前の利用箇所の洗い出しにまとめてあります。

9月4日までに済ませること

残り日数を踏まえると、優先順位はかなりはっきりします。

1. launch_origin の記録を入れたビルドを、ストア審査の期間を見込んで先に出す。審査と段階公開を合わせると数日は消えます
2. 記録が実際に届いているかを、自分の端末で音声とランチャーの両方から起動して確認する
3. 発話文字列の収集について、同意状態の扱いとプライバシーポリシーの記述を先に整える
4. 検証端末を1台だけ手動で Gemini へ寄せ、置き換え後の挙動を自分の目で見ておく
5. 週次のクラスタ分布を、置き換え前に最低1回は取る。1点しかない基準線でも、0点よりは比較になります

3番だけは順番を前に出しても構いません。収集の設計が決まらないうちにビルドを出すと、あとから同意の扱いを変えるために再度リリースが必要になります。

次の一手

置き換えの前にできることは、実はそれほど多くありません。挙動を先読みして作り込むより、あとから読み直せる形で数えておくほうが効きます。

まずは自分のアプリで、ランチャー以外から開かれた起動が日次で何件あるのかを1つだけ数えてみてください。その1本の折れ線があるかないかで、9月以降に届く報告の読み方が変わります。

私自身、今回の作業で「測っていなかった」ことに気づけたのが一番の収穫でした。同じ穴を抱えている方の参考になれば嬉しく思います。お読みいただきありがとうございました。