Obsidianの今の使い方③｜修正・改善ログで失敗を次の制作に活かす

Contents

はじめに
このガイドでわかること
ステップ1：その回の失敗は、デイリーノートの表に書く
ステップ2：投稿が終わったら、「症状別」のログに移す
- 「避ける語」も残す
ステップ3：次の制作の前に、必ずログを読む
- まだ効くか分からない案は「未検証」として分けておく
運用してみて分かったこと
まとめ
参考リンク

はじめに

その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で書いたノートの長さの問題は、ここでも同じです