AI要約の裏取り6項目：LyriaとGemini Skillsの公式資料を照合

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

2026年10月20日には同じ6欄をGemini Skillsの公式3ページへ適用しました。提供開始日は確認できた一方、年齢条件は公式ページ間で一致せず、「Google AI subscriptionなし」という説明もSkillsをチャットで使う範囲に限られていました。差を埋めずに保留・限定へ戻す例として追記します。

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

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

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

10月20日の追試では、同日の日次レポートHTMLとraw JSONについて、日付、Asia/Tokyo、Top News 3件、3件の代表URLとその順序が一致することをローカルで確認しました。レポートは題材選定にだけ使い、要約や事業案は転載していません。その後、Skills提供状況、作成・管理条件、書き方を説明するGoogle公式3ページを開き直しました。

検証対象は資料の記載と保存済みレポートのメタデータであり、音楽生成の品質やSkillsの動作ではありません。APIキーの発行、課金設定、音楽生成、国やアカウントを変えた利用試験、GeminiへのSkill作成・upload・自動適用は行っていません。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が受け付けられるかは未検証なので、どちらも断定しません。

2026年10月25日に同じガイドを開き直すと、Java例もlyria-3.5へ統一されており、9月8日に記録したモデルIDの差は現行ページでは再現しませんでした。変更日や旧Java例の実行可否は未確認です。現在の実装判断には現行ガイドを使い、上の差は確認日時を伴う履歴として扱います。

最後に追加規約の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に補わせれば、この保留が見えなくなるため注意が必要です。

10月20日追試：Gemini Skillsの3資料を並べる

題材にした10月13日のWorkspace Updatesでは、GeminiアプリのSkillsは10月13日から段階展開し、完了予定は11月中旬と説明されています。一方、Workspace内のSkillsは安全性と信頼性の確認のため延期され、更新時期は確定していません。二つをまとめて「Workspaceでも提供済み」とは書けません。

作成・管理のHelpでは、利用条件としてサインインとKeep Activityの有効化が挙げられています。同ページの「Skills are available without a Google AI subscription and can be used in your chats」という説明から確認できるのは、Skillsをチャットで使う範囲です。TasksやSchedules、Workspace内機能、全アカウントへの即時提供まで無料と広げません。

9月30日のGoogle BlogはSkillsの展開開始を案内し、脚注で公開時点は18歳以上、18歳未満は今後と説明しています。10月13日のWorkspace Updatesにある全年齢説明との時系列差は確認できますが、どのアカウントへいつ適用されたかは資料比較だけでは確定できません。

比較すると、年齢だけは同じGeminiアプリ版を指す公式ページ間でall agesと18 or overに分かれました。どちらかを推測で採用せず、2026年10月20日時点では保留です。Helpページには公開日・更新日の表示も見当たらなかったため、確認日を資料日として言い換えていません。

この追試では保存ファイルの件数・URL比較と公式資料の読み比べだけを行いました。Geminiの実アカウント画面は操作しておらず、段階展開が自分のアカウントへ到達したか、Keep Activityを変更した場合にどうなるか、Skillの作成・upload・自動適用が成功するかは未検証です。図は比較結果を読みやすくしたもので、操作画面や実行ログではありません。

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

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

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

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

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

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

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

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

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

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

収集した候補を裏取り前に整理する段階では、日次ニュースの日時と重複を確認する記事で、公開時刻がない行を推測で期間内にせず、要確認として残す方法を検証しています。本稿の6欄票は主張の中身を確認する工程、リンク先の記事はその前段でメタデータを整理する工程です。

更新履歴：2026年10月20日に、同日入力のHTML/JSON照合とGemini Skills公式3ページの比較を追加しました。2026年10月25日にLyriaガイドを再確認し、Java例もlyria-3.5へ統一されていた現状を追記しました。9月8日に記録した資料差は履歴として維持しています。