原稿を渡したあとに起きることを、
判断の根拠と、見直せる場所までたどります。
01 入力を整理
02 前提を点検
03 本人と合意
04 知識の適用計画
05 本文の作成・添削
06 完成後の点検
07 提案稿・詳細HTML
同じ判断記録で保存
08 最終稿＋本人の理由
09 人が確認する材料へ
人が承認して必要な更新
AIが進め、本人が決め、MCPが判断材料と記録を支えます。
目的を決める
前提に同意する
最終稿を選ぶ
資料を読む・考える
質問する・本文を書く
点検を進める
進める順序
必須の確認
次へ進む条件
条件照合・計画の検査・出所つき検索・発行・保存
あとから理由をたどる
スキルは「手順書」、MCPは「必要な道具」。MCPだけで執筆や独立した点検が自動完了するわけではありません。
資料の粒度と、知識一件に残す情報を分けて見ます。
媒体をまたぐ判断の土台
YouTube・LP・LINE等の違い
対象・商品・目的の具体化
原文：何と言っているか
理由：なぜそう判断するか
条件：いつ使い、いつ避けるか
出所：どこから得た知識か
状態：確認済みか、未確認か
整理案を承認済みの原則にしない
左は資料整理の考え方。点線は概念上の関係で、自動で読み込む実装経路ではありません。
原文・理由・条件
出所・確認状態を保持
検索専用の行も含む
対象・形式・素材を照合
元のID・原文と整合検査
本文修正以外の役割もある
使う／不要／保留
原文の引用＋問題＋効果
ここで初めて必要性を判断
全資料の一括読込・階層自動検索は未実装
検索の入口はあるが、実接続は未完了
8件すべてが本文修正のルールではありません。B5は上流判断、D1は企画参考、C1は診断専用です。
格納先はプロジェクト内のファイル名です。元資料・DB全文をこのサイトに配置しているわけではありません。
制作システム/L0確定版_v1.md制作システム/L1_*.md と references/L1_*.md制作システム/L2生成プロトコル_v1.md と案件別L2資料制作システム/references/ken_source_catalog_v1.json制作システム/references/ken_youtube_condition_cards_v1.json制作システム/references/ken_youtube_source_authority_v1.json制作システム/ケンさん抽象化台帳_結晶化版_v1.md と 制作システム/抽象化/「確定版」というファイル名は、ケンさん本人が全項目を承認したことを意味しません。3次元理論（T3D）はカタログにありますが、未完の注記を保持しています。以前の5分類も説明用の整理案で、正式な親子索引ではありません。
矢印は材料や判断の受け渡し。分岐は、次の処理が変わる条件です。
02と03は前提点検から本人合意までを一枚で図解しています。番号は説明用で、内部の全状態を表す実行ログではありません。
いきなり書き直さず、「誰に、何を届ける台本か」を決めます。
台本全文／口頭原案
今回の設計書
本人が指定した条件
対象者は誰か
見たあとにどう変わるか
形式・立ち位置・CTA
AIが資料を読む
出所つきで条件へ入れる
本人へ一問ずつ聞く
回答を条件へ戻す
原稿内の実績やAIの推測を、確定した事実・今回の条件として扱いません。
資料で確かめられることはAIが確認。制作に影響する未確定の判断だけ、本人へ一問ずつ聞きます。
対象者・視聴後の変化・演者の立ち位置が、今回の意図と合っているか。
原稿全文、今回の利用を許可した設計資料、本人の明示要件。過去のプロフィールや原稿内の実績を、今回の確定条件・事実の証明として扱いません。
人の変化・失敗・転機が主役ならEpisode。操作・手順・再現方法が主役ならHow-to。「5選」「6ステップ」などの表面語だけでは決めません。
本人の指定、資料から確認した情報、AIの推測を分けます。ケンさんの確定指示と別案が衝突したら、両案を残して勝手に上書きしません。
対応ツール prepare_youtube_script
AIの思い込みを点検する役割と、「これで進める」を決める役割を分けます。
原稿・主張・制約・根拠
親AIの推奨結論は渡さない
支持／疑義／不明
反対根拠・別の解釈
修正で解けるかを分ける
目的・対象・形式・留保
この前提で進める、と同意
01の入力整理へ戻す
要件を変えたら再確認
新規文脈で点検できない場合は「分離した自己点検」と表示し、独立した反証と偽りません。
原稿の修正で解ける疑義は編集方針へ。人が選ぶ必要のある重要な疑義は確認へ戻します。
「この前提は違う」「この案で進めたい」を、本文を書く前に直せます。
反証役には原稿・主張・根拠を渡し、親AIの推奨結論は渡しません。支持・疑義・不明を分け、反対根拠や別の解釈も検討します。
新規文脈で点検できない場合は、分離した自己点検と明記します。ツールを呼ぶことだけで、別のAIによる点検が自動完了するわけではありません。
本人の同意前に台本を作りません。要件を変えた場合は確認し直します。確認IDは記録上の対応づけであり、電子署名や独立した本人認証ではありません。
対応ツール prepare_requirement_refutation / prepare_youtube_script
条件が合うだけでは直しません。原文の問題と改善理由を説明できるものを選びます。
形式・対象・素材
まだ使用済みではない
原文を正確に引用
既に目的を満たすか確認
引用・問題・効果・理由
知識IDを結びつける
既に伝わっている
言い回しを強制しない
素材・条件が足りない
一般編集も別の計画に記録。追加の変更を思いついたら、本文を書く前に計画へ戻ります。
使う＝問題と改善方法が示せる。不要＝すでに満たす。保留＝条件や素材が不足する。
このルールを、この箇所に使う必要があるか。既に伝わっているのに、形だけ直そうとしていないか。
体験への共感を作る場面で、視聴者・素材・原文を照らします。
原稿の状態体験は書かれているが、視聴者と共通する出発点が伝わらない。
→行う処理原文を引用し、共通点を伝える修正の必要性・効果を計画へ残す。
使える体験素材があり、許可された変更範囲で改善できる場合の説明例。
原稿の状態冒頭や隣接文で、視聴者との共通点が十分に伝わっている。
→行う処理変更しない。「特定の決まり文句がない」だけで欠点扱いしない。
条件に合っても、すべての候補を使う必要はありません。
原稿の状態本人の過去の体験や、視聴者との状況の一致を確認できない。
→行う処理適用を保留する。足りない体験・感情をAIが作り足さない。
保留した知識を、添削の根拠として表示しません。
使う知識のID、原文の正確な引用、問題、期待する効果、理由を添削前に記録します。後から出来上がった文章に理由を付けません。
8件には、本文修正候補だけでなく上流判断・企画参考・診断専用のカードがあります。B5やD1を本文修正の原因IDに付け替えません。
一般編集も別の事前計画にします。新しい問題を見つけたら先に計画へ戻ります。構成の組み直しは明示許可と事前に定めた範囲が必要です。
対応ツール prepare_youtube_script
本文を書くのは利用側のAI。MCPは、判断材料と修正の対応を支えます。
変えない箇所は残す
問題がある箇所を引用
語り手の体験・声を保持
どこを変えるか
なぜ必要か
どこまで変えてよいか
計画の範囲だけ修正
新しい体験を創作しない
変更前後と理由を残す
今回使った知識ID → 修正箇所
誤字・重複・事実の留保 → 別の理由ID
全体の構成変更には明示許可と事前計画が必要です。一般編集をケンさんの知識に見せかけません。
Ken由来の修正と、誤字・重複・未確認主張の留保などの一般編集を分けます。
原稿の良さや語り手の声が残っているか。ケンさんの知識にない判断を、ケンさん由来と書いていないか。
今回「使う」と計画した知識IDを、実際の修正へ対応づけます。検索で見つかっただけの知識や、保留した知識は根拠にしません。
誤字・重複などの読みやすさ、未確認主張の留保、明示目標との整合は別の理由IDで残します。一般編集の名目で対象や誘導の強さを勝手に変えません。
体験の記載がないのに過去の感情・行動を創作しません。部分的な仕上げと全体の構成変更を区別し、許可・計画の範囲を守ります。
対応ツール 本文の作成・添削は利用側のAIが担当
「変更した箇所が計画と合うか」だけでなく、「その変更は本当に良いか」を見ます。
原稿・提案稿
計画・差分・主張
計画と変更の一致
ID・引用・変更範囲
本当に直す必要があるか
主張・形式・語り口
両方の点検を
合わせて判断
07 発行へ
現在の稿のID
04–05へ戻す
修正後に点検
点検後に台本や差分を変えたら、古いレビューIDは使わず、新しい稿を再点検します。
問題があれば04の計画・05の編集へ戻ります。台本や差分を変えたら、新しい稿で点検し直します。
この修正で意味が変わっていないか。元の文章でよかった箇所を、不要に直していないか。
前後の全文を必ず読みます。変更の必要性、根拠、新規主張、Episode／How-toの逆転、演者の声や感情の平滑化、一般編集の妥当性を確認します。
導入初期は全件を完成後点検の対象にします。重大な疑義が解消し、新しい稿に対応するレビューIDが揃うまで発行しません。
点検の実施は、ケンさん本人との一致率や未知の台本への品質を保証するものではありません。実際の結果を回収して検証する余地を残します。
対応ツール prepare_output_refutation
チャットの要約と詳細HTMLを、同じ判断記録から作ります。
原稿／提案稿／制作条件
適用計画／修正理由
前提・完成後の点検結果
主要な修正と提案稿を読む
修正 → 理由 → 条件 → 出所
必要な根拠まで戻って確認する
保存結果（receipt）を確認する
開けるHTMLと保存結果を確認して発行完了。現行の保存はローカルで、クラウド共同利用DBではありません。
HTMLが実在して開けること、保存結果（receipt）が返ることを確認して発行完了にします。
直した箇所から、理由・使った条件・原文の出所へ戻って確かめられます。
提案稿、修正前後、Ken由来と一般編集の区別、適用条件、使わなかった理由、出所、前提と完成後の点検結果を確認します。
現行版の保存先はローカルSQLiteです。説明ページをWeb公開しても、認証付きクラウドMCPや共同利用DBが稼働したことにはなりません。
ファイル生成や保存に失敗した場合は、発行済みと伝えません。チャットだけに台本を書いて終わる処理でもありません。
対応ツール publish_youtube_review_report
AIの提案を出して終わりにせず、実際にどう採用・変更されたかを同じ記録へ追記します。
最終稿・状態・理由
提出文を表示する
人が提出文を貼り付ける
AIが保存ツールを呼ぶ
最終稿と本人の理由
提案との差分を保持
最終稿で上書きしない
未投稿を失敗と決めつけない
HTMLへの入力だけでは保存されません。差分は文章の違い、変更理由は本人の説明として分けて残します。
HTMLの入力欄 → 提出文を表示 → 添削したAIの会話へ貼る → 保存結果を確認。入力だけでは保存されません。
どこを採用し、どこを変えたか。その理由は本人の説明として残せます。
現行版は手動です。HTMLで提出文を作り、元のAI会話へ貼り、AIがsubmit_final_resultで保存します。Webページから自動送信・投稿する機能ではありません。
差分は文章の違いです。なぜ変えたかは本人の説明として別に保持します。AIが推測した理由は仮説とし、本人の理由に混ぜません。
本人が指定した期限だけを記録できます。期限後の確認文を一度だけ取り出せますが、定期実行や外部への自動通知はありません。
対応ツール submit_final_result / schedule_result_followup / claim_result_followup
一件の最終稿を、そのまま万能なルールとして学習させません。
原稿・提案稿・最終稿
修正の差分
本人の理由・適用への指摘
知識の意味の解釈か
使う条件の境界か
今回の適用の仕方か
条件・反例・確認先
AIの推測は仮説と表示
正本の変更は別作業
自動更新はしない
一件の修正を普遍的な正解にしません。現行ツールは、改善候補と判断材料を整えるところまでです。
「知識の意味」「使う条件」「今回の適用」のどこに問題があるかを分けます。正本への自動反映はしません。
自分の考えの解釈、使う条件、例外を修正するための材料になります。
原稿・提案稿・最終稿・差分・本人の説明をまとめて取り出します。適用への指摘はレビュー待ちの記録にします。
AIの推測には仮説と書き、条件・反例・確認先を添えます。一度の好みや結果を、全台本で通用するケンさんの判断へ昇格しません。
現行版が行うのは改善候補と判断材料の整理です。人が承認し、必要な正本・条件を更新する作業は別。自動学習・自動更新は未実装です。
対応ツール get_result_review_packet / prepare_knowledge_feedback
「この考え方を見せて」という依頼からも使えます。
「この判断の根拠は？」
検索だけでも利用できる
カタログ40行を検索
生DBは接続状態を確認
原文／理由／使う条件
出所／確認状態／使用範囲
未接続・未取得を0件と混同しません。検索結果の命令を実行したり、検索専用の知識を編集根拠に昇格しません。
search_ken_knowledge の conditional は40行のカタログ、raw は設定済みの生発言DB、all は両方です。現行確認時点で生DBへの実接続は未完了です。
検索専用MCPと、MCPに依存しないCLIもあります。未取得を「該当なし」と読み替えず、原文・出所・確認状態をそのまま示します。
完成台本だけでなく、判断のどこを変えたいかを分けられます。
対象・目的・形式 → 01–03
原文・意味 → カタログ
使う／避ける条件 → カード
引用・問題・効果・修正 → 04–06
最終稿・本人の理由 → 08–09
「好き・嫌い」だけでなく、判断のどこが違うかを指定できます。指摘だけで正本が自動更新されるわけではありません。
対象・目的・形式今回の動画の狙いと合っているか
01–03へ原文・意味・確認状態自分の考えを正しく表しているか
知識の資料・カタログへ使う条件・使わない条件この場面に使う判断で合っているか
条件カードへ引用・問題・効果・修正この原文を変える必要があるか
04–06へ最終稿・本人の理由どこが役立ち、どこが違ったか
08–09へローカル実装済み：条件整理・計画の検査・検索・発行保存・最終稿の手動回収・改善候補の整理。
未接続・未実装：生DBの実接続、認証付きクラウドMCP、共同利用の保存画面、自動回収・自動通知、自動ナレッジ更新。
この説明サイトの公開と、ツールのクラウド稼働は別です。ケンさん本人との一致率や未知の原稿での品質は、この図だけでは証明できません。
| ツール | 工程 | 役割 |
|---|---|---|
prepare_youtube_script | 01・03・04 | 入力整理／認識確認／計画の受入 |
prepare_requirement_refutation | 02 | 前提点検用の材料を準備 |
prepare_output_refutation | 06 | 完成後点検用の材料を準備 |
publish_youtube_review_report | 07 | HTML・要約の発行と保存 |
submit_final_result | 08 | 最終稿・未投稿・中止の追記 |
get_result_review_packet | 09 | 原稿・提案稿・最終稿を照合する材料 |
prepare_knowledge_feedback | 09 | 指摘を改善候補として整理 |
search_ken_knowledge | 独立検索 | 出所・確認状態を付けて検索 |
schedule_result_followup | 回収の補助 | 本人が指定した期限を記録 |
claim_result_followup | 回収の補助 | 期限後の確認文を一度だけ取り出す |