DaVinci Resolve 20で階調を最大限に引き出す実践的なHDR編集手法

はじめに

DJI Osmo Pocket 3 には、HDR収録が可能な「HLGモード」と「D-Log Mモード」が搭載されています。
このうち HLGモードは“True HLG” であり、撮影した映像をそのままHDR対応ディスプレイで再生しても自然な輝度階調を再現できます。

ただし、HLGモードではカメラ内部でトーンマッピング処理が行われるため、
撮影時点で輝度レンジが圧縮され、白飛びしやすく、後処理でのリカバリー余地が小さいという弱点があります。

一方、D-Log Mモードで撮影してポストプロダクションでHLG化 すれば、
センサーが捉えた広いダイナミックレンジをそのまま保持したまま、
自分の意図で階調と色を整えることが可能になります。

つまり――

“撮って出しのHLG”ではなく、“後で仕上げるHLG”こそがOsmo Pocket 3の真価を引き出す方法。

本記事では、そのための実践的なワークフローを、
DaVinci Resolve 20を用いた「D-Log M→HLG変換」を中心に解説します。

前回の記事「GoPro GP-Log→HLGのワークフロー解説」では、
Log素材を中間空間で処理してHLG出力する流れを紹介しました。

今回はその考え方を DJI Osmo Pocket 3 の D-Log M素材 に応用します。

なお、DaVinci Resolveには「D-Log M」ガンマのプリセットは現時点で存在しません。
そのため、Input Gamma には「DJI D-Log」を指定して処理します（トーン特性が近く、実用上問題なし）。
加えてResolve 20では Input Color Space に「DJI D-Gamut」 を選べますので、DJI D-Gamut + DJI D-Log が最適解です。

また今回は、

「10bit素材を10bit素材として活かしたい」
という撮影・編集者の視点から、
メーカー公式LUTを初手で使用した場合に起こる“縮小コピー→拡大コピー”現象についても触れます。

⚠️ 動作環境に関する重要な注意点

本記事で解説するワークフローは、DaVinci Resolveのカラーマネジメント機能と、DJI D-Gamut/D-Logの最新のプリセットを利用します。

特に、D-Log M素材は10-bit H.265 (HEVC)で記録されるため、以下の点に注意が必要です。

1. DaVinci Resolveのバージョン: 記事で示している設定項目（特に「DJI D-Gamut」）は、DaVinci Resolve 18以降（推奨：Resolve 20）のバージョンでの動作を前提としています。古いバージョンでは、一部のプリセットや機能が利用できません。
2. Windows環境の無料版: Windows版のDaVinci Resolve無料版は、原則として10-bit H.265のネイティブサポートがありません。WindowsユーザーでD-Log M (10-bit)をスムーズに編集するには、DaVinci Resolve Studio版（有償）の利用を強く推奨します。MacユーザーはOSの機能により無料版でも編集できるケースが多いですが、動作を保証するものではありません。

プロジェクト設定（カラーマネジメント）

本ワークフローでは、DaVinci YRGB Color Managedモードを使用しつつ、
自動カラーマネジメントをOFFに設定し、プロジェクト全体をHDR処理向けに構成します。

🔹 推奨設定

この設定により、プロジェクト全体がHDR（HLG）出力を前提とした色域・ガンマで動作します。
Resolve内部では常にDWG/Intermediate基準で演算が行われ、
CSTを使ったLog→中間→出力変換がスムーズに行えます。

🔹 なぜこの設定にしているのか

アクションカム（Osmo Pocket 3やGoProなど）は、
メインカメラではなく「サブカメラ」として使われる場面が多い という前提があります。
単独でHLGやD-Log M素材を仕上げることもできますが、
将来的にミラーレス機（例：S-Log3やV-Logなど）で撮影した素材と同一タイムラインで扱うことを考えると、
共通の作業空間（DaVinci Wide Gamut / Intermediate）で運用できる環境を整えておく方が拡張性が高い のです。

この「Color Managed（Auto OFF）」構成を採用すると：
– Resolve内部の演算は常にDWG/Intermediate基準で統一される
– 自動変換は行われず、素材ごとにCSTを明示的に設定できる
– 将来、別カメラ素材を追加してもCSTで正規化するだけで整合が取れる

つまり、「今はOsmo Pocket 3単体で完結していても、将来的に複数カメラを混在させても破綻しない」構成です。

🎯 ポイント
Resolveが内部でDWG基準を維持してくれるため、
S-Log3やV-Log素材を後から追加しても、
同じタイムライン上で自然なトーン一致が得られます。

🔹 DJI素材の自動認識について

Resolveはクリップのメタデータに基づいて自動で色空間を認識しますが、
コンシューマ寄りの機種ではタグが簡略化されていることが多く、誤認識や非認識が起きがちです。
Osmo Pocket 3のD-Log M素材も、自動では Rec.709 や Unknown と見なされることがあります。

• Resolve 20のポイント
  入力側プリセットとして 「DJI D-Gamut（色域）」 と 「DJI D-Log（ガンマ）」 が選択可能。
  D-Log Mプリセットは未搭載のため、DJI D-Logを代用するのが正解です。

💡 確認方法：
メディアプールでクリップを右クリック →「入力カラースペース」を確認。
「DJI D-Gamut / DJI D-Log」になっていなければ、ノードのCSTで 手動指定 します。

なぜ D-Log M→HLG なのか

• カメラ内HLGよりも広いダイナミックレンジを後処理で維持できる
• D-Log M素材は広色域（DJI D-Gamut相当）で、HDR出力と親和性が高い
• 10bit素材を10bitのまま扱えば、Log特有の滑らかな階調を損なわない
• 公式LUTを初手で当てると、一度SDR（Rec.709）に潰してから再拡張する
  → 結果として「縮小コピー→拡大コピー」のような階調破壊が起きる

中間ノードの考え方や、Log→中間→最終出力の三段構成は
前回の記事「GoPro GP-Log→HLG ワークフロー」を参照してください。

全体構成

ノード構成：
1️⃣ 入力正規化（D-Log M→DWG/Intermediate）
2️⃣ グレーディング（中間ノード）
3️⃣ 出力正規化（DWG→Rec.2100 HLG）

🔹 補足：メディアプール設定について

DaVinci Resolve 20では、素材を読み込んだ際に「入力カラースペース」が自動設定されることがありますが、
今回のワークフローは Auto Color Management＝OFF で CST手動制御 が前提です。
メディアプール側では変換を適用しないようにします。

設定手順

1. メディアプールでD-Log M素材を選択
2. 右クリック → 「入力カラースペース」 → 「タイムラインと同じ（Same as Timeline）」 を選択
3. ノード側のCSTで
   Input Color Space = DJI D-Gamut、Input Gamma = DJI D-Log（D-Log Mの代用） を手動指定します。

📌 理由：
Resolve 20では「未指定（Unmanaged）」メニューが廃止。
Same as Timeline を選ぶと実質“変換なし”として扱え、CSTのみが有効になります。

第1ノード：入力正規化（CST）

Resolve 20で選べるプリセットを前提 にした推奨設定：

📌 メモ
D-Log M専用のガンマが無いぶん、露出にごく僅かなズレが出る場合があります。
Exposure ±0.2〜0.3 や Gamma/Pivot で微調整すれば実用上問題ありません。

中間ノード（グレーディング）

DWG/Intermediate空間で露出補正・彩度調整・ノイズリダクションなどを行います。

ただし、D-Log M素材は非常に素直な特性を持つため、
CSTで正しく展開すれば、ほぼその時点で自然なコントラストと色調が得られます。
実際には、第1ノード（CST）と最終ノード（出力）だけで“完成形に近い画”になることも多く、
中間ノードでは軽い微調整――例えば露出の微補正や全体彩度の調整程度――で十分です。

詳しいノード構成や作業手順は、前回記事の
→ GP-Log→HLG ワークフロー解説
を参照してください。

最終ノード：出力正規化（HLG変換）

DWG/Intermediateのまま出力します。
実際のHLG化はプロジェクト設定の 出力カラースペース＝Rec.2100 HLG が担当するため、
ここで改めてCST変換を行う必要はありません（GP-Log記事と同一方針）。

推奨設定（GP-Log版と同様）

📌 補足
HLG化はプロジェクト設定に任せるのがポイント。
詳細な意図と検証は、前回記事
GP-Log→HLG ワークフロー を参照。

🎓 アマチュア動画編集者が混乱しやすい「自動認識」の罠

アクションカム（Osmo Pocket 3やGoProなど）は、手軽にLog撮影ができる反面、
記録ファイル内のメタデータが簡略化されているため、
DaVinci Resolveが素材を正しく認識できない場合があります。

特に今回のように 「D-Log M」ガンマがDaVinci Resolve内にそもそも存在しない ため、
ソフト側としても自動的に正しい入力設定を選択することができません。
つまり編集者自身が、「DJI D-Logで代用する」などの代替案を理解して設定する必要がある のです。

その状態で「自動カラーマネージメント」をONにしたり、
メーカー公式LUTを適用したりすると、
Resolveが内部的にRec.709扱いで変換してしまい、
結果として 彩度・コントラストが二重に適用される（トーン破綻） という現象が起きます。

アマチュア動画編集者の方が「Logで撮ったのに色が濃すぎる」「LUTを当てたら白飛びした」と感じるケースの多くは、
この自動認識の誤動作が原因です。

そして、ただでさえ難易度の高いLog撮影のハードルを、さらに上げてしまっている要因がまさにここにあります。
Log撮影自体は本来、センサーの持つダイナミックレンジを最大限活かす手法ですが、
カメラと編集ソフトの“色空間の食い違い”が起こると、その利点が一気に失われてしまいます。

DaVinci Resolve はプロ向けの素晴らしいツールであり、
無料版でも非常に高い編集・色管理性能を備えています。
しかし皮肉なことに、アマチュア動画編集者が用意するアクションカム素材ほど、Resolveが自動で正しく認識できないことが多く、
場合によっては 誤ってRec.709として扱ってしまう ケースすらあります。

この「最初の入り口」で混乱するユーザーが非常に多く、
実際にはLog撮影やHDR処理よりも、
素材の色空間を正しく扱うことこそが最初のハードル になっているのが現実です。

本記事で紹介したように、自動カラーマネージメントをOFFにしてCSTで明示的に変換する構成にしておけば、
こうした誤認識の影響を受けず、素材本来の画質を引き出すことができます。

まとめ

• Resolve 20では Inputに「DJI D-Gamut」＋「DJI D-Log」 を選ぶのがベスト（D-Log Mは未搭載のため代用）
• カラー処理モードは HDR DaVinci Wide Gamut Intermediate、出力は Rec.2100 HLG
• カメラ内HLGは便利だがトーンマッピングが固定で後処理耐性が低い
• メディアプールは「入力カラースペース：タイムラインと同じ」で自動変換を無効化 → ノードでCST指定
• 将来的なマルチカメラ運用にも対応可能（DWG/Intermediate基準）
• 10bit素材を10bitのまま活かすには、公式LUTではなくCST運用が基本
• D-Log M素材は素直な特性を持つため、CST正規化だけで完成度の高い映像が得られる
• 公式LUTを初手で当てると「縮小コピー→拡大コピー」になり階調が破壊される

※この記事は前回記事「GP-Log→HLG ワークフロー」の応用編です。
中間ノード構成や色調整の考え方、出力ノードの詳細設定はそちらをご参照ください。

AIを業務のどこに組み込めば、現実的な効率化につながるか。私にとってその答えの一つが、WordPressでの執筆と公開でした。アイデア自体は早くからあったのですが、「日々の運用で迷わず使える手触り」を得るまでには試行錯誤が必要でした。

なぜ WordPress なのか

数あるブログサービスの中で WordPress を選んだ最大の理由は、公式の REST API が充実していることです。外部ツールからの連携余地が広く、AI と直接的にやり取りする構成を作りやすい。生成AIが作成したテキストを人間がコピペする形は、ワークフローとして洗練されていないため避けたいと考えました。

最初のアプローチ：GPTs による直接操作

はじめは GPTs にファンクションコールを定義し、チャットボットから WordPress を直接操作する実験をしました。固定料金で使えるのは魅力ですが、長文の保持・推敲が続く執筆フローではコンテキスト容量の制約がボトルネックになり、安定運用の観点では課題が残りました。

方向転換：CLI と組み合わせる

2025 年初頭、CLI 系の生成 AI が普及しはじめ、試してみると「仕様に沿った機械的な反復処理」に非常に強いことがわかりました。CLI に自作ツールを渡せば、README とヘルプを根拠に、一定品質の操作を一貫して行える。そこで本稿の主役となる WpAiCli を作りました。

フェーズ1：REST 直叩きのフル機能 CLI

最初の段階では、投稿・リビジョン・カテゴリ・タグ・メディアの作成／取得／更新／削除を網羅。WordPress運用に必要なコマンドをひと通り備えました。とはいえ、AI が“その場で取得したサーバーデータをどう扱うか”という判断は不得手で、レビューや改稿の流れが途切れやすい問題が残りました。

学び：API を叩く術よりも、編集対象の素材を手元に揃える設計のほうが、AI と人の分担に向いている。

フェーズ2：ローカル主体（キャッシュ & 双方向同期）へ

そこで設計を見直し、WordPress の状態をローカルに可視化。人がテキストファイルを直接編集し、差分だけをプッシュする形にしました。

• 双方向同期：サーバ → ローカルへ取り込み（sync）、ローカルの差分だけをサーバへ反映（push）
• キャッシュ構造（例）
  wp-ai-cache.db # 内部用SQLite（非編集）
posts/ # 1投稿=1 Markdown（YAMLフロントマター＋本文）
categories/*.yaml
tags/*.yaml
media/*.{bin, yaml}
• 競合時は明示解決：resolve local-wins / server-wins で方針を指定

この方針により、AI はローカルのファイル群を入力として整形・校正し、確定した差分を確実に反映できます。人は落ち着いて原稿と構成に集中でき、両者の役割が整理されました。

リビジョンは「一応」：本命はローカルGitの履歴運用

WordPress の REST API はリビジョン（過去版）をサポートしており、本ツールでも取得・復元には対応しています（必要十分の範囲で）。一方で、実務上の強みはキャッシュフォルダを Git で管理することにあります。

• AI が自発的に過去版を参照できる：git log や git diff の文脈から、意図や推敲の流れを把握し、過去の良い表現を現在の構成に自然に接続できます。
• フロントマターごと履歴化：タイトル・ステータス・カテゴリ/タグ・カスタムフィールドを含め、構造的に時系列を追える。
• オフラインでも強い：ネットワークに依存せず、git show で即比較／差し戻し。画像は Git LFS を併用するか、メタだけ Git に入れるなど柔軟に運用可能。

.gitignore の一例

wp-ai-cache.db
media/*              # バイナリは LFS 推奨
!media/*.yaml

まとめると：WPのリビジョン機能は“保険”として確保しつつ、日々の執筆サイクルはローカルGitの履歴が中心。これにより、AI が自律的に過去版を読み込み、意図を踏まえた提案や調整を行えるようになります。

運用上のポイント（README 準拠）

• 接続情報の登録・切替、投稿/分類/メディアの CRUD と同期、--format table|json|raw などの出力形式切替に対応。
• 投稿のローカルキャッシュと双方向同期が基本。リビジョン取得、分類・メディアの同期も備えています。
• Markdown の扱いは client/server モードに対応（サーバ側で Markdown 変換を行う場合は、_md_source メタの取り扱いに注意）。
• 競合検出時は resolve コマンドで明示的に解決。
  （詳しいコマンド一覧やワークフローは README を参照してください。）

よく使う流れ（例）

1. サーバ → ローカルで posts sync。必要に応じて taxonomies sync / media sync。
2. posts/<ID>-<title>.md を編集（フロントマター含む）。
3. ローカルGitにコミット（AI が履歴を参照しやすくなる）。
4. 確定分のみ push <ID>。必要に応じて revisions 機能を利用。

これから

• wpai self-update（自己更新）
• WordPress 側の補助プラグイン（_md_source の扱いを明確化）
• API モックとローカル差分テストを含む自動テスト
• 署名・公証、テンプレート集の整備 など

参考リンク

• NuGet: https://www.nuget.org/packages/WpAiCli/
• GitHub: https://github.com/aroooy/WpAiCli

おわりに
生成AIとWordPressの距離は、「素材をローカルに引き寄せる」だけで大きく縮まります。WpAiCli は、人が原稿を磨くプロセスを中心に据えながら、AI の反復処理と参照能力を引き出すための土台です。WP のリビジョンは保険として確保しつつ、ローカルGit履歴 × AI 参照を主軸に据えることで、安定した執筆サイクルが実現できました。