YouTube チャンネルデータのウェブ情報収集とトレンド分析

VS Code が開かれています。左側のファイルエクスプローラーには「YouTube Analysis」というプロジェクトフォルダが空の状態で待機しており、右側には Claude Code の対話ウィンドウが点滅しています。この空のフォルダを出発点として、YouTube チャンネルデータの収集、トレンド分析、そして専門的なレポート作成を自動で実行し、メールで送信する自動化システムを構築してまいります。

本章では、これまで取り上げてきた MCP、スキル、GWS コマンドライン方式、WAT フレームワークを一つのワークフロー内で統合する事例をご紹介いたします。

プロジェクトの初期化

まず初めに、claude.md ファイルをプロジェクトに配置する必要があります。このファイルはエージェントのシステムプロンプト（System Prompt）として機能し、WAT フレームワークの構造、すなわちワークフロー、エージェント、ツールの 3 層構造をエージェントに伝達します。

ファイルを配置した後、Claude Code に「この claude.md ファイルを基にプロジェクトを初期化してください」と依頼します。エージェントは temp、tools、workflows フォルダを作成し、.env ファイルと .gitignore を設定します。これでプロジェクトの骨格が整いました。

計画モードでの要件伝達

計画モードに切り替えます。この段階の重要性は前章で十分に強調しましたので、早速実習に入りましょう。

この依頼は意図的に「ブレインダンプ」の形式です。完璧に洗練された要件ではありません。計画モードの真価はまさにこの点にあります。

エージェントによる調査と質問

エージェントは単に考えるだけではありません。ウェブ検索を実行し、YouTube データをウェブ情報として収集する方法や、MCP 接続サーバーの活用方法を調査します。そして、質問が投げかけられます。

各質問に答えます。チャンネルは自動発見、頻度は週次、シート記録は含み、メールは自身の Gmail 宛て。これらの回答が、要件定義書の空欄を埋めていきます。

[図 20-1] 計画モードでエージェントが質問を投げかけ、回答を収集する画面

実行計画の策定

エージェントが提示した計画の規模は相当なものです。7 つの Python ツールを作成するというものです。

1. fetch_youtube_data.py — YouTube データ収集 2. analyze_youtube_data.py — 収集データの分析 3. generate_charts.py — チャート画像の生成 4. generate_slides.py — スライドデッキの構成 5. send_email_report.py — メールレポートの送信 6.

export_sheets.py — Google スプレッドシートへのエクスポート 7. discover_channels.py — AI によるチャンネルの自動発見

ワークフローは「youtube_weekly_report」という名前で生成されます。このワークフローは、7 つのツールを順次呼び出す指揮者の役割を果たします。

計画が承認されると、エージェントはタスクリストを作成し、一つずつ実行していきます。その間、他のモニターで別の作業をしながら、時々進行状況を確認すれば十分です。

依存関係のインストールと API キーの設定

ツール作成が完了すると、エージェントが次の手順を案内します。

API キーは.env ファイルに保存します。エージェントに「依存関係をインストールしてください。YouTube API キーは私が取得します」と伝えれば大丈夫です。API キーをClaude Codeに渡す際は、.env ファイルにのみ記録されるよう確認してください。

OAuth認証には、Google CloudプロジェクトでYouTube Data API、Gmail API、Google Sheets APIを有効化する必要があります。この手順は第19章のGWSコマンドライン方式インストールで説明したものと同一です。

最初の検証実行

すべての設定が完了すると、エージェントが自動的にパイプラインを検証します。その結果は以下の通りです。

[図 20-2] 最初の検証実行結果の要約 — 収集されたデータの規模

スライドデッキの自動生成

メールで届いた報告書を開きます。「AI Automation YouTube Analytics」というタイトルの週次報告書です。

メール本文

30 件のチャンネル追跡、187 件の動画分析という主要な数値が上部に配置されています。今週の上位動画リストとコンテンツ制作の推奨事項が本文に含まれています。

パワーポイントデックの構成

添付されたパワーポイントファイルを開くと、以下のスライドが表示されます。

[図 20-3] 自動生成されたパワーポイントスライドデックの画面キャプチャ

Google スプレッドシートのデータ構造

レポートとともにGoogleスプレッドシートにもデータが記録されます。シートには3つのタブがあります。

チャンネル統計（Channel Stats）: チャンネル ID、チャンネル名、購読者数、総再生回数、動画数が日付別に記録されます。毎週実行するたびに新しい行が追加されるため、時間の経過に伴うチャンネルの成長を追跡できます。

上位動画（Top Videos）: 動画 ID、タイトル、チャンネル名、再生回数、いいね数、コメント数、エンゲージメント率、投稿後の経過日数が含まれます。エンゲージメント率と経過日数を併せて確認することで、「現在注目を集めている」動画を正確に把握できます。

週次サマリー（Weekly Summary）: 実行日、追跡対象チャンネル数、分析対象動画数、中央値再生回数、中央値エンゲージメントスコア、上位キーワードが1行に要約されます。週次データが蓄積されることで、業界トレンドの変化を一目で把握できます。

PDFレポートへの変換

パワーポイントではなく、ブランディングが施された PDFレポートをご希望の場合は、キャンバスデザイン（Canvas Design）スキルを活用できます。Claude Code テンプレートウェブサイトからこのスキルを検索してインストールします。インストールコマンドを Claude Code に貼り付けることで、.claude/skills フォルダにスキルファイルとフォントが生成されます。

エージェントは既存の generate_slides.py ツールを新しい PDF 生成ツールに置き換え、ワークフローファイルを更新します。メール送信ツールも、添付ファイルの形式をパワーポイントから PDF に変更します。

最初の PDF 生成結果に問題が発生する可能性があります。表紙と最終ページのみが含まれ、本文のグラフが抜けてしまう場合です。その際は自然言語で修正意見を提示します。

エージェントは原因を特定し、ツールを修正してワークフローを更新した後、9 ページ分の完成した PDF を新たに生成します。ロゴが上部に配置され、日付が表示され、すべてのグラフと推奨事項が含まれています。

[図 20-4] ブランディングが適用された PDF レポートの完成画面

Gmail 連携：レポートの自動送信

ワークフローの最終段階は、完成したレポートを Gmail に送信することです。

メール送信ツールの構成

send_email_report.py ツールは、以下の要素を処理します。

GWS コマンドライン方式により Gmail API を呼び出すため、SMTP 設定やアプリパスワードは不要です。OAuth 認証が完了していれば、gws コマンドを 1 行実行するだけでメールが送信されます。

Google スプレッドシートの同時更新

メール送信と同時に、データはGoogleスシートにも記録されます。シートを直接作成する必要はありません。エージェントが新しいシートを作成するか、既存のシートにタブを追加し、スキーマ（列構成）を設定してデータを入力します。毎週実行するたびに新しい行が追加されるため、時系列データが自然に蓄積されていきます。

検証と最適化

ワークフローが完成したからといって、すぐにデプロイすることはできません。検証と最適化の段階が残されています。

反復改善の実際

初回実行ですべてが完璧に機能することは稀です。YouTube分析ワークフローでも、何度かの修正が必要でした。

各問題を発見するたびにエージェントに自然言語で伝えると、エージェントが原因を調査して修正します。修正内容はツールファイルとワークフローファイルに反映されるため、次の実行では同じ問題が再発しません。

セキュリティレビュー

デプロイ前には必ずセキュリティレビューを実施する必要があります。

エージェントはコード全体をレビューし、以下の項目を確認します。

セキュリティレビューで注意が必要な項目が見つかったとしても、実際に脆弱な状態ではない場合があります。エージェントが「3 つの注意項目がありますが、すべてのシークレットは安全に管理されています」と報告すれば、デプロイを進めても問題ありません。

[図 20-5] セキュリティレビュー結果のサマリー画面

デプロイ：Modalを活用したスケジュール実行

ワークフローを週次スケジュールで運用するには、クラウド上にデプロイする必要があります。AIインフラプラットフォームであるModalを活用します。Modalは自動化が実行された時のみ課金されるため、コスト効率に優れています。無料クレジットも提供されています。

デプロイの手順は以下の通りです。

エージェントは、次の作業を順次実行します。

1. スクリプトの環境変数パスの更新 2. Modal 配布ファイルの作成 3. クロン（Cron）スケジューリングの設定 4. API キーと認証モデルが参照するテキスト断片を Modal シークレットに登録 5. 配布の実行と検証

配布が完了したら、Modal ダッシュボードでアプリを確認できます。手動実行（マニュアルトリガー）で再度検証し、正常に動作することが確認できたら、スケジュールトリガーを有効にします。

配布後のメンテナンス

前章で言及した重要な区別をもう一度確認しましょう。配布されるのはワークフローとツールです。エージェントは配布されません。したがって、配布されたワークフローが実行中に新たなエラーに遭遇しても、自己修復は行われません。

メンテナンスの流れは以下の通りです。

ワークフローが安定化すれば、この周期は徐々に短縮されます。初期には週に1〜2回の確認が必要ですが、エッジケースが解消されるにつれ、自動実行のみで十分となります。

全体アーキテクチャの整理

YouTube分析ワークフローの全体構造を一目で整理します。

[図20-6] YouTube分析ワークフローの全体アーキテクチャダイアグラム

MCP（Firecrawl）、API（YouTube Data）、コマンドライン方式（GWS）、スキル（Canvas Design）、そしてWATフレームワークが、一つのワークフロー内で有機的に結合されています。これらすべてを調律しているのは、自然言語による対話だけです。

空のフォルダから始め、週次のYouTubeトレンドレポートが自動的にメールボックスに届くまで、その全過程を歩んできました。1つのプロンプトから出発し、エージェントとの対話を通じて7つのツールと1つのワークフローを構築し、検証し、修正し、デプロイしました。

ここで得た感覚、つまり目標を自然言語で説明し、エージェントの質問に答え、結果を確認して修正意見を伝えるというリズムは、今後どのような自動化を構築する場合にも同じように適用されます。