はじめに
その1ではデイリーノートを中心にした全体像を、その2ではYouTube 2チャンネルの制作管理を書きました。最終回のその3は、制作で失敗したことを次の制作に活かすための「修正・改善ログ」です。
私の音楽・動画制作では、似た失敗が何度も起きていました。琴が単音しか鳴らない、動画の画面が揺れる、ループのつなぎ目がずれる。前にも直したはずなのに、次の回でまた同じことで悩む。これを減らすために作ったのが、症状別の修正・改善ログです。
このガイドでわかること
- 失敗と修正を、どこにどう記録しているか
- 日付順ではなく「症状別」にまとめている理由
- 次の制作の前にログを読む流れ
- まだ効果が分からない改善案の扱い方
- 運用してみて分かった限界
ステップ1：その回の失敗は、デイリーノートの表に書く
YouTubeの制作ガイドがあるデイリーノートには、「修正・改善メモ」という表を置いています。音楽と動画で分けて、次の5列で記録します。
|
列 |
書くこと |
|
曲・ツール |
どの曲か、どの動画生成AIか |
|
問題 |
何が起きたか |
|
直した箇所 |
プロンプトのどこを、どう変えたか |
|
結果 |
○・△・× |
|
次回も使う？ |
✅・要検証・使わない |
たとえばYS-075の制作記録では、動画生成AIの結果をこう記録しました。
- Kling：霧だけを動かす指示では、動きが見られなかった（×）
- DomoAI：揺れを抑える一文を入れても、画面が揺れた（×）
- Flow：採用。10秒で作って5秒に短くし、つなぎ目を1.5秒のトランジションで処理した（○）
失敗した結果も、採用しなかったツールも省かずに書くのがポイントです。「何がダメだったか」は、次の回で一番役に立つ情報だからです。
ステップ2：投稿が終わったら、「症状別」のログに移す
動画を投稿し終えたら、表の中で「次回も使う？」が✅の行を、チャンネル専用の修正・改善ログにも追記します。元のデイリーノートは残し、その回の経緯をたどれるようにします。YAMATO SOULSは「制作の修正ログ（音楽・動画）」、もふもふ睡眠BGMは「音楽の修正ログ」です。
このログは、日付順ではなく症状別に見出しを立てています。
- 楽器が電子音になる・はっきりしない
- 主役の楽器が埋もれる／背景の楽器が出しゃばる
- ループのつなぎ目・展開の問題
- 動きが不自然・動きすぎる
- ツールごとの得意・苦手
日付順にすると、「琴が単音になったとき、前はどう直したっけ？」を探すのに、過去のノートを1日ずつさかのぼることになります。症状の見出しから引ければ、同じ悩みの記録がまとまって見つかります。
見出しの下には、「どの回で・何をしたら・どうなったか」と、出典のデイリーノートへのリンクを書いています。詳しい経緯が知りたければ、リンクから元のノートに戻れます。
「避ける語」も残す
採用した修正だけでなく、「改善しなかった語句・悪化を疑った語句」も残しています。YS-074ではgroove（リズムの乗り）を使った版で打楽器のようなノイズが出て、duet（二重奏）などを加えた版でも音の混濁は改善しませんでした。YS-075では周波数の語句を含む初版で、音程の不安定さが記録されています。
ただし、これらは私の制作中の観察とGemsの分析による仮説です。複数の箇所を同時に変えたため、その語句だけが原因だったとは言い切れません。どんな曲にも使えない言葉の一覧ではなく、次に比較するときの手がかりとして扱っています。
ステップ3：次の制作の前に、必ずログを読む
ログは書くだけでは意味がありません。次の制作でプロンプトを作る前に読むことを、Claude Code用の指示書（CLAUDE.md）に書いています。
- 音楽のプロンプトを作る前 → 音楽の修正ログを読む
- 動画のプロンプトを作る前 → 動画の修正ログを読む
作業を依頼するとき、このルールをもとに過去の記録を参照してもらいます。ログを置くだけで自動的に学習・反映されるわけではないので、作成されたプロンプトも確認します。たとえば動画なら、「Klingは霧だけだと動かない」「DomoAIは揺れやすい」「Flowの採用例ではつなぎ目を編集した」といった過去の結果を、プロンプトを書く前に確認できます。
同じ失敗が何度も出たときは、ログからさらに一段上げて、プロンプトの「型（テンプレート）」そのものを直します。YS-075では10回以上作り直した結果をもとに、YAMATO SOULSの4シリーズ分の音楽プロンプトの型を作り直しました。
まだ効くか分からない案は「未検証」として分けておく
週次レポートの記事を書くとき、うまくいかなかった点については、Claude Codeに公式ドキュメントや実例を調べてもらい、改善案を出してもらっています。
ただし、調べて出てきた案は、まだ試していません。そこでログの冒頭に「未検証の改善案」という表を別に作り、効果を確かめた記録とは分けて置いています。
|
列 |
内容 |
|
症状 |
どの回の、どの問題か |
|
改善案 |
次にそのまま試せる形で書く |
|
根拠 |
参考にしたURLなど |
|
確度 |
公式の記載／複数の実例／推測 |
|
試した結果 |
次の制作で試したら記入 |
試して効いたものだけを、症状別の見出しに移します。効かなかった場合も「試した結果」に書き残します。
実際、DomoAIの揺れを抑える一文は、公式ブログを根拠にした試行案として表に入れていました。ただし、その記事が対象とするモデルと、私が使用したモデルが同じかは未確認です。YS-074では被写体が動いてしまい揺れの効果は判断できず、YS-075では揺れを防げませんでした。この結果も、未検証の表に残しています。
運用してみて分かったこと
良かった点
- 同じ症状が出たとき、過去の直し方をすぐに探せる
- 前に試して改善しなかった言葉を、次の制作前に確認できる
- 失敗が続いたときに、ログを見て「型ごと直す」判断ができた
限界
- 1回で複数の箇所を直すと、どれが効いたか分からない：YS-074では5回、YS-075では10回以上作り直しましたが、毎回いくつかの言葉を同時に変えていました。そのため、どの一言が効いたのかは切り分けられていません。ログにも「単独の効果は不明」と書いています
- 1本で効いただけのものが多い：Shrine & Koto Healingのシリーズで効いた型が、ほかのシリーズでも効くとは限りません。「何本で確認したか」をログに書くようにしています
- ログ自体も長くなる：症状の見出しが増え、古い案と新しい案が混ざりやすくなっています。その1・その2で書いたノートの長さの問題は、ここでも同じです
まとめ
- その回の失敗と修正は、デイリーノートの表に○△×で記録する
- 投稿後、次回も使えるものを「症状別」の修正ログにも追記する
- 次のプロンプトを作る前に、AIにもログを参照するよう指示する
- 調べただけの改善案は「未検証」として分け、試した結果で振り分ける
- 限界は、同時に複数を直すと効果を切り分けられないこと。今後は1回に1か所ずつ変えることを徹底したい
3回にわたって、2026年9月時点のObsidianの使い方をまとめました。デイリーノートを司令塔にして、台帳で全体を見て、修正ログで失敗を次に活かす。まだ課題は多いですが、今の私の制作は、この3つで回っています。
参考リンク
- Obsidianの今の使い方①｜デイリーノートが制作の「司令塔」になるまで
- Obsidianの今の使い方②｜YouTube制作を「番号・フォルダ・台帳」で管理する
- Stable Audioで和楽器BGMになるまで｜YS-074で5回修正して見えたこと
