AIによるコンテンツ制作
題材を受け取り、工程と役割を分けて生成し、出力の形を契約で決め、出す前に検査してから成果物にする仕組み。公開されている実装3件を同じ観点で比較した構成です。
公開実装 3 件を、各リポジトリの固定コミット（コミット日 2026-03-21〜2026-08-25）で見ています。根拠の一覧へ
- Claude Code指示文あり・実行は未検証
- Codex未対応
完成後にできること
この構成を作ると、実データで確認された範囲で次のことができます。
- 1題材の受け取り
- 2工程の段分け
- 3役割の分割
- 4本文の生成
- 5出力形式の契約
- 6出す前の検査
システム構成
役割による層（入力→処理→出力）。実データで観測された要素のみ。
接続線は構成レイヤー（役割の流れ）を示します。個々のツール間の正確な接続は、Evidence で確認できた場合のみ別途表示します。
使用ツール / 始める前に必要なもの
観測された実装と Blueprint の要件です。
- 題材の受け取り
題材は任意入力（未指定なら企画エージェントが自動選定） / 題材の入力＋リポジトリ内の候補集（選定後に候補集を更新） / 前工程（キーワード調査）の出力を受け取り、執筆前に上位検索結果を調べる
- 工程の段分け
6段の固定パイプライン（strategy → script → thumbnail → seo → production → quality_review） / 6段の Stage（脚本+beats → コンポジション → QA → 音声 → 効果音 → 音楽） / 執筆前 / 執筆後 / 公開前 の3段のゲートで工程を区切る
- 役割の分割
7役割を別モジュールに分離（企画 / 台本 / サムネイル / SEO / 制作 / 公開 / 分析） / 制作トラックごとに別 skill・共通骨格は3トラック共有・破綻規則は別 skill / skill ごとの担当範囲と「使わない場合の行き先」を明示
- 本文の生成
構造化された台本オブジェクト（title / hook / introduction / mainContent / conclusion / CTA） / 脚本と beats の作成（Stage 1） / 調査結果をもとに本文を書く工程
- 出力形式の契約
段ごとの必須要素検査（通らない限り completed にしない） / beats.json（format / vo[] / beats[] / timeline の機械可読契約） / JSON-LD の構造化データ（Article / FAQPage）とメタタグ
- 出す前の検査
公開メタデータの正規化と検証（不合格は例外で停止） / 本レンダリング前のフレーム目視検査（チェックリスト） / 3段のチェックリスト（AI 語彙の除去・全主張に出典）
- 成果物の取り出し
実在を確認した動画ファイル / 1本ごとの出力ディレクトリに置かれる動画ファイル / 記事（Markdown またはCMS の下書き）
- 素材の生成
サムネイル生成（概念 → プロンプト → 画像 → 文字重ね → 最適化） / 行単位の音声合成＋単語単位の実時刻の書き戻し（本文ハッシュでキャッシュ）
- 公開・配信
YouTube への公開（readiness と provenance の2ゲートで停止） / 設定で選ぶCMS 4種・既定は下書きかローカル出力（自動公開は明示指定のみ）
- 状態の保存
1本 = 1ディレクトリの固定配置（脚本 / 契約 / 音声 / 効果音計画 / 出力）
- 公開後の測定
承認済みの推奨だけを次の企画の入力に渡す
必須（最初に用意）
- ・題材の受け取り
- ・工程の段分け
- ・役割の分割
- ・本文の生成
- ・出力形式の契約
- ・出す前の検査
- ・成果物の取り出し
後から追加
- ・素材の生成
- ・公開・配信
必要になったら
- ・状態の保存
- ・公開後の測定
なぜこの構成なのか
なぜ題材の入口を決めるか：3件とも題材を受け取る口が定義されていた（利用者の入力と自動選定 / リポジトリ内の候補集 / 前工程の出力）。
なぜ段に分けるか：3件とも工程が名前のついた段に分かれていた（6段の定数配列 / 6つの Stage 見出し / 執筆前・執筆後・公開前のゲート）。
なぜ役割を分けるか：3件とも1つの指示に集約せず責務を分けていた（7役割の別モジュール / トラック別 skill / 「使わない場合の行き先」の明示）。
なぜ出力を契約で縛るか：3件とも生成の後ろに出力形式の約束が置かれていた（段ごとの必須要素検査 / beats.json / JSON-LD）。
なぜ検査を別に置くか：3件とも生成だけで終わらせず、成果物にする前の検査が独立した工程として存在した（メタデータ検証 / フレーム目視 / 3段のチェックリスト）。
なぜ成果物を明示するか：3件とも「何が出来上がりか」が実体で決まっていた（実在確認つきの動画ファイル / 出力ディレクトリの動画 / 記事）。
NOW — 3件すべてで観測された部分
題材の受け取り → 段分けと役割の分割 → 本文の生成 → 出力形式の契約 → 出す前の検査 → 成果物。この並びは公開実装3件すべてで観測されました。最適だから並べたのではありません。
- 題材の受け取り
題材は任意入力（未指定なら企画エージェントが自動選定） / 題材の入力＋リポジトリ内の候補集（選定後に候補集を更新） / 前工程（キーワード調査）の出力を受け取り、執筆前に上位検索結果を調べる
- 工程の段分け
6段の固定パイプライン（strategy → script → thumbnail → seo → production → quality_review） / 6段の Stage（脚本+beats → コンポジション → QA → 音声 → 効果音 → 音楽） / 執筆前 / 執筆後 / 公開前 の3段のゲートで工程を区切る
- 役割の分割
7役割を別モジュールに分離（企画 / 台本 / サムネイル / SEO / 制作 / 公開 / 分析） / 制作トラックごとに別 skill・共通骨格は3トラック共有・破綻規則は別 skill / skill ごとの担当範囲と「使わない場合の行き先」を明示
- 本文の生成
構造化された台本オブジェクト（title / hook / introduction / mainContent / conclusion / CTA） / 脚本と beats の作成（Stage 1） / 調査結果をもとに本文を書く工程
- 出力形式の契約
段ごとの必須要素検査（通らない限り completed にしない） / beats.json（format / vo[] / beats[] / timeline の機械可読契約） / JSON-LD の構造化データ（Article / FAQPage）とメタタグ
- 出す前の検査
公開メタデータの正規化と検証（不合格は例外で停止） / 本レンダリング前のフレーム目視検査（チェックリスト） / 3段のチェックリスト（AI 語彙の除去・全主張に出典）
- 成果物の取り出し
実在を確認した動画ファイル / 1本ごとの出力ディレクトリに置かれる動画ファイル / 記事（Markdown またはCMS の下書き）
NEXT — 3件中2件で観測された部分
素材の生成と公開・配信。必須ではなく、作る媒体と配信先による選択として観測されました。
- 素材の生成
サムネイル生成（概念 → プロンプト → 画像 → 文字重ね → 最適化） / 行単位の音声合成＋単語単位の実時刻の書き戻し（本文ハッシュでキャッシュ）
- 公開・配信
YouTube への公開（readiness と provenance の2ゲートで停止） / 設定で選ぶCMS 4種・既定は下書きかローカル出力（自動公開は明示指定のみ）
LATER — 3件中1件で観測された部分
状態の保存と公開後の測定。1件でしか観測していないため、共通の構成には含めていません。
- 状態の保存
1本 = 1ディレクトリの固定配置（脚本 / 契約 / 音声 / 効果音計画 / 出力）
- 公開後の測定
承認済みの推奨だけを次の企画の入力に渡す
この Blueprint では規定しない
共通の作り方を観測していない事項です。決めないことを明示します。
- 失敗したときの扱い方
- モデル・プロバイダの選び方
- 作り直しの手順
- 継続的な運用
- 具体的なツールの選定
FAQ
根拠（なぜこの構成か／実例限定の理由）から生成しています。
なぜ「題材の受け取り」がこの構成に必要か？
なぜ題材の入口を決めるか：3件とも題材を受け取る口が定義されていた（利用者の入力と自動選定 / リポジトリ内の候補集 / 前工程の出力）。（3/3 システムで確認・確度: 確認済み）
根拠:darkzOGx ↗（youtube-automation-agent の観測時点のソースを開く（コミット 260d7a9）・新しいタブで開く）hassancs91 ↗（claude-faceless-shorts-creator の観測時点のソースを開く（コミット 773054b）・新しいタブで開く）watchdealer-pavel ↗（seo-content-autopilot の観測時点のソースを開く（コミット 2fd9a3c）・新しいタブで開く）
なぜ「工程の段分け」がこの構成に必要か？
なぜ段に分けるか：3件とも工程が名前のついた段に分かれていた（6段の定数配列 / 6つの Stage 見出し / 執筆前・執筆後・公開前のゲート）。（3/3 システムで確認・確度: 確認済み）
根拠:darkzOGx ↗（youtube-automation-agent の観測時点のソースを開く（コミット 260d7a9）・新しいタブで開く）hassancs91 ↗（claude-faceless-shorts-creator の観測時点のソースを開く（コミット 773054b）・新しいタブで開く）watchdealer-pavel ↗（seo-content-autopilot の観測時点のソースを開く（コミット 2fd9a3c）・新しいタブで開く）
なぜ「役割の分割」がこの構成に必要か？
なぜ役割を分けるか：3件とも1つの指示に集約せず責務を分けていた（7役割の別モジュール / トラック別 skill / 「使わない場合の行き先」の明示）。（3/3 システムで確認・確度: 確認済み）
根拠:darkzOGx ↗（youtube-automation-agent の観測時点のソースを開く（コミット 260d7a9）・新しいタブで開く）hassancs91 ↗（claude-faceless-shorts-creator の観測時点のソースを開く（コミット 773054b）・新しいタブで開く）watchdealer-pavel ↗（seo-content-autopilot の観測時点のソースを開く（コミット 2fd9a3c）・新しいタブで開く）
なぜ「出力形式の契約」がこの構成に必要か？
なぜ出力を契約で縛るか：3件とも生成の後ろに出力形式の約束が置かれていた（段ごとの必須要素検査 / beats.json / JSON-LD）。（3/3 システムで確認・確度: 確認済み）
根拠:darkzOGx ↗（youtube-automation-agent の観測時点のソースを開く（コミット 260d7a9）・新しいタブで開く）hassancs91 ↗（claude-faceless-shorts-creator の観測時点のソースを開く（コミット 773054b）・新しいタブで開く）watchdealer-pavel ↗（seo-content-autopilot の観測時点のソースを開く（コミット 2fd9a3c）・新しいタブで開く）
なぜ「出す前の検査」がこの構成に必要か？
なぜ検査を別に置くか：3件とも生成だけで終わらせず、成果物にする前の検査が独立した工程として存在した（メタデータ検証 / フレーム目視 / 3段のチェックリスト）。（3/3 システムで確認・確度: 確認済み）
根拠:darkzOGx ↗（youtube-automation-agent の観測時点のソースを開く（コミット 260d7a9）・新しいタブで開く）hassancs91 ↗（claude-faceless-shorts-creator の観測時点のソースを開く（コミット 773054b）・新しいタブで開く）watchdealer-pavel ↗（seo-content-autopilot の観測時点のソースを開く（コミット 2fd9a3c）・新しいタブで開く）
なぜ「成果物の取り出し」がこの構成に必要か？
なぜ成果物を明示するか：3件とも「何が出来上がりか」が実体で決まっていた（実在確認つきの動画ファイル / 出力ディレクトリの動画 / 記事）。（3/3 システムで確認・確度: 確認済み）
根拠:darkzOGx ↗（youtube-automation-agent の観測時点のソースを開く（コミット 260d7a9）・新しいタブで開く）hassancs91 ↗（claude-faceless-shorts-creator の観測時点のソースを開く（コミット 773054b）・新しいタブで開く）watchdealer-pavel ↗（seo-content-autopilot の観測時点のソースを開く（コミット 2fd9a3c）・新しいタブで開く）
「状態の保存」はなぜ後回し/限定なのか？
実例が限定的なためです（1/3 システムでのみ確認・推定）。
「公開後の測定」はなぜ後回し/限定なのか？
実例が限定的なためです（1/3 システムでのみ確認・推定）。
この目的に対して証拠が限定的な範囲は？
素材の生成（3件中2件・扱う媒体で分かれる） / 公開・配信（3件中2件・配信先が実装ごとに異なる） / 状態の保存（3件中1件） / 公開後の測定（3件中1件） / モデル・プロバイダの選び方（本版では証拠として採録していない） / 失敗したときの扱い（本版では証拠として採録していない） / 生成物の品質や成果（観測していない） / 運用実績（公開された運用実績は確認していません）（標準構成ではありません。レビューした公開実装3件で共通して観測された部分と、実装ごとに分かれた部分を分けて示しています。）
根拠（一次ソース・証拠レコード）
公開実装 = 3 件。証拠レコード = 27。両者は別物です。
リンク先は Plentro が観測した時点のソース（コミット固定）です。その後の更新は含みません。
- youtube-automation-agent
Builder: darkzOGx · github_repository
観測コミット 260d7a9（2026-08-25）
観測時点のソースを開く ↗（youtube-automation-agent の観測時点のソースを開く（コミット 260d7a9）・新しいタブで開く） - claude-faceless-shorts-creator
Builder: hassancs91 · github_repository
観測コミット 773054b（2026-08-18）
観測時点のソースを開く ↗（claude-faceless-shorts-creator の観測時点のソースを開く（コミット 773054b）・新しいタブで開く） - seo-content-autopilot
Builder: watchdealer-pavel · github_repository
観測コミット 2fd9a3c（2026-03-21）
観測時点のソースを開く ↗（seo-content-autopilot の観測時点のソースを開く（コミット 2fd9a3c）・新しいタブで開く）
この構成を出発点に、自分の条件で選ぶ。
登録すると、条件を入力して構成候補を確認できます。Claude Code を接続すれば、 あなたの構成を検出し、実在 Builder の Claude Code 構成と比べられます。
- あなたが渡すもの
- Claude Code に指示文を貼り、内容を自分で確認して承認すると、構成の一覧（ツール / MCP / スキル / コマンド / フックの種類と数）だけが送られます。
- 送られないもの
- ソースコード本文・APIキー等の秘密情報・.env・秘密鍵・git 認証情報・会話履歴・端末内の絶対パス。 これらは受信側で構造的に拒否・除去されます。
- 返ってくるもの
- あなたの構成の検出結果と、実在 Builder の Claude Code 構成との差分、そこから決まる次にやること 1 つ。