AI要約の裏取り6項目：Lyriaの公式資料を照合して分かったこと

公式発表へのリンクが付いていても、要約した一文の範囲まで正しいとは限りません。今回は音楽生成モデルLyriaの資料を照合し、アプリの案内とAPIの条件を分ける必要があること、同じ公式ガイドでもSDK・リクエスト方式別のコード例にモデルIDの差があることを確認しました。

大事なのは「この記事は信用できるか」という全体への採点ではなく、どの一文を、どの条件付きで採用するかを決めることです。記事末尾にコピーして使える確認票を載せます。

今回したこと、していないこと

初回は2026年9月5日（日本時間）に、Googleの発表記事、API料金表、音楽生成ガイド、API追加規約、提供地域一覧の5ページを開いて照合しました。公開直前の9月8日にも同じ5ページを開き直し、下記の料金、提供地域、モデルID、出力形式を再確認しています。音楽生成ガイド自体の表示は「Last updated 2026-09-04 UTC」でした。日次の情報収集で見つけた話題を、読者向けの記事にする前の確認作業です。

検証対象は資料の記載であり、音楽生成の品質やAPIの動作ではありません。APIキーの発行、課金設定、音楽生成、国やアカウントを変えた利用試験は行っていません。API呼び出しは0回で、費用は0円です。資料確認はWindows上で行いましたが、以下の照合手順に特定のOSやプログラミング環境は不要です。

後述する5つの「検査用の文」は、読み落としを探すために本稿で組み立てた例です。特定のAIが実際にその誤文を出したという実験ではなく、AIの誤答率を測ったものでもありません。

一文を6つの欄に分ける

長い要約を読む前に、読者の判断が変わる主張を一つ選び、次の欄に分けます。一文にアプリとAPIが入っていたら、まず二つの確認票に分割します。

確認する欄	書き出すもの	欠けていたら止める判断
1. 製品・窓口	アプリ、API、管理画面、クラウド版など	アプリの案内をAPIにも適用しない
2. モデル・版	モデルID、バージョン、preview/正式版	製品の通称だけでコードを決めない
3. 料金・単位	通貨、1曲/1分/トークン、無料枠、課金方式	「使える」を「無料」に言い換えない
4. 対象・条件	国、年齢、アカウント、プラン、提供段階	「世界提供」を無条件の利用保証にしない
5. 時点	発表日、発効日、確認日	今日読んだページを今日の発表と扱わない
6. 証拠の種類	公式説明、本文内の比較、実行ログなど	公式コードの掲載を実行成功に置き換えない

空欄は「制限なし」ではなく「未確認」です。すべてのニュースで全欄を埋める必要はありませんが、「無料で導入できる」と結論を書くなら料金欄を空にしたまま進めることはできません。

Lyriaの資料をこの順に読んだ

最初に9月4日の発表を読みました。アプリとAPIの提供が案内されていますが、Web・モバイルでの世界提供という記述だけから、APIの料金まで判断することはできません。

次に料金表のLyria 3.5欄を確認。9月8日の再確認時点では、Full Songは1曲0.08米ドル、無料枠は利用不可という記載でした。これはそのAPIの料金表を読んだ結果で、Geminiアプリの料金や自分の請求実績ではありません。

続いて音楽生成ガイドのモデル表と出力形式を確認しました。Lyria 3.5には既定のMP3に加えて、response_formatでWAVを指定する説明があります。同ページの「Generate a full-length song」では、Python、JavaScript、RESTの例がlyria-3.5、Javaの例がlyria-3-generate-001となっていました。ここで確認できるのは記載の差までです。Javaの例が実行時に失敗するか、別IDが受け付けられるかは未検証なので、どちらも断定しません。

最後に追加規約のUse Restrictionsと提供地域一覧を確認しました。APIには提供地域などの条件があり、一覧には日本も含まれています。ただし、一覧掲載だけで個別モデル・個別アカウントの動作確認が済んだことにはなりません。契約や生成物の権利についての網羅的な判断は、本稿の対象外です。

5つの文を「採用・限定・訂正・保留」に分ける

資料の内容を一度読んだだけでは、記事を書く段階で条件を落とすことがあります。そこで、確認対象の一文と、実際に公開できる範囲を横に並べました。

検査用の文	判定	確認後に書ける範囲
世界提供されたので、LyriaのAPIは誰でも無料で使える	訂正	アプリの提供案内とAPIの条件を分離。API料金は料金表で確認する
Lyria 3.5のFull SongはAPI料金表で1曲0.08米ドル	採用	2026年9月8日の再確認結果として記載。実請求額やアプリ料金とは区別する
日本が対象地域なので、自分のアカウントでも必ず動く	限定	日本の一覧掲載まで確認済み。個別アカウントの動作は未確認とする
Lyria 3.5のAPI出力はMP3だけ	訂正	WAV指定の説明もある。自分で生成ファイルを取得したとは書かない
公式ガイドのJava例は、そのまま現行モデルの動作確認に使える	保留	同じ節のモデルIDに差がある。利用するSDK・モデルを確認し、実行前提をそろえる

5件の内訳は採用1・限定1・訂正2・保留1になりました。検査用に選んだ少数の例なので、この比率をAI全体やGoogle資料全体の正確性として一般化することはできません。

「保留」は記事全体を捨てる意味ではありません。今回はAPI実行ガイドにはせず、資料の照合で分かった差だけを記事にする、という範囲の変更に使っています。資料にない答えをAIに補わせれば、この保留が見えなくなるため注意が必要です。

コピーして使う出典確認票

次の票を一つの主張につき一枚使います。空欄を埋めるために推測せず、見つからなければ「未確認」と残してください。URLだけでなく見出し名も保存しておくと、料金ページなど長い資料を再確認しやすくなります。

確認対象の一文：
1. 製品・窓口：
2. モデル・版：
3. 料金・単位・無料枠：
4. 対象・利用条件：
5. 発表日／発効日／確認日時：
6. 証拠の種類（資料確認／実行結果など）：

一次情報URLと該当見出し：
一次情報が裏付ける範囲：
裏付けない範囲・記載の食い違い：
判定（採用／限定／訂正／保留）：
公開する一文：
公開直前に再確認する点：

判定の基準は単純です。主張と条件が一致したら採用、元の文が広すぎたら限定、逆の記載が見つかったら訂正、資料の食い違いや必要な証拠不足が残ったら保留にします。「公式だから採用」という判定欄は作りません。

実務では、公開前に変わりやすい欄をもう一度見る

この票の使いどころは、情報収集と記事公開の間です。日次レポートの全項目を毎回長文で検証するのではなく、記事に採用する主張のうち、料金、利用範囲、終了日、実行手順など、読者の行動を変える箇所を先に確認します。重要な欄が未確認のままなら、その箇所を導入の根拠に使わないという編集判断ができます。

また、今日確認した価格を数日後にもそのまま掲載できるとは限りません。下書きには確認日を残し、公開直前に該当する料金欄と利用条件を開き直します。変更がなければ確認した事実を記録し、変わっていれば本文と確認票を同時に直します。公開後の訂正も、何を変更したかが分かる形で残します。

この手順だけで誤りがなくなるわけではありません。元資料が間違っている、個別アカウントでは条件が異なる、ページが後から書き換わる、といった限界があります。必要な操作を実際に試していないときは、資料確認と動作確認を分け続けることが重要です。

内容の裏取りが済んだら、次は実行環境や公開物の確認です。定期タスクの落とし穴を確認した記事では実際の運用記録と公式仕様を分け、Astroの公開時に詰まった点の記事ではビルドの測定条件と結果を示しています。資料に書かれていることと手元で確かめたことを分ける点は共通です。