Clipchampで「保存して編集」を押したのにプロジェクトに残らない、WEBMを手動インポートしてもエラーになる――そんな症状は、録画ファイルのメタデータ未書き込みや保存先の同期・権限・一時ファイル衝突が重なって発生します。本記事では原因の見極め方から恒久対策、緊急の取り回し、ARM版WindowsやOneDrive環境の落とし穴まで、現場ですぐ役立つ実践手順をまとめました。
事象の概要とポイント
対象は Clipchamp のデスクトップ版。録画完了後に表示される「保存して編集」を押してもプロジェクト側に録画クリップが現れず、エクスプローラーに残る .webm を手動インポートしても「読み込みに失敗」「サポートされていないファイル」等のエラーが出る。新しい WEBM だけが「created by / modified by などのメタデータが空」なのが特徴。カメラ権限やサインインは正常で再現する――というケースです。
このパターンは、録画終了時に WEBM コンテナへ書き込まれるべきタグ・索引が欠落し、Clipchamp のインジェスト（プロジェクト取り込み）で形式判定に失敗することが主因と考えられます。同期ドライブやキャッシュ破損、WebView2 依存関係、ARM 環境のコーデック周りが誘因になることもあります。
まずはこの対処一覧から
| 項目 | 手順・ポイント | 効果 / 備考 |
|---|---|---|
| ① アプリの更新 | Microsoft Store →「ライブラリ」→「更新」で Clipchamp を最新ビルドへ | 過去のアップデートで本不具合が修正された例あり |
| ② 保存先をローカルに固定 | Clipchamp 設定 → ストレージ で保存先を OneDrive/ネットワークではなく C:\Users\<ユーザー>\Videos 等のローカルに変更してから録画 | 録画完了時のメタデータ欠落を回避 |
| ③ WEBM→MP4 へ変換（応急処置） | HandBrake／VLC 等で問題の WEBM を MP4 に変換してからインポート | コンテナ破損だけをバイパス可能 |
| ④ キャッシュ削除 → 再ログイン | 1) Clipchamp からサインアウト 2) %LocalAppData%\Packages\Clipchamp.Clipchamp_*\ 内 Cache と Temp を削除3) 再ログインして録画 | 古い一時ファイルの干渉を排除 |
| ⑤ 「エクスポート」経由で取り込み | 録画直後に 「保存して編集」ではなく「録画をエクスポート（MP4）」 を選択し、生成された MP4 を新規プロジェクトへ追加 | 内部処理ルートを変えることで失敗回避 |
| ⑥ 別アカウントを利用する回避策 | Microsoft 365 組織アカウントで録画 → 出来たファイルを個人アカウントの Clipchamp で編集 | 一部ユーザーが成功を報告 |
| ⑦ ARM デバイス固有の疑い | Surface Laptop（Snapdragon）など ARM 版 Windows で発生報告が多い。Intel 機では再現しにくいとの声 | ハードウェア依存の可能性あり |
原因の深掘り：なぜ WEBM が読み込めなくなるのか
- 録画の終端処理が最後まで完了していない：WebM（Matroska 派生）は終了時に索引（Cues）やタグが書き込まれます。終了直後にストレージが一時的にロックされたり、同期ドライブがプレースホルダー化すると、タグが空のまま保存され、再読込で「未知の形式」扱いになります。
- WebView2/コーデック連携の不整合：Clipchamp は WebView2 ランタイムに依存します。破損や旧版が残ると、録画終了イベントやファイルクローズが不安定になることがあります。
- OneDrive のファイル オンデマンド：録画直後に「オンラインのみ」へ切り替わると、メタデータ追記や検証が途中で中断されることがあります。Known Folder Move（デスクトップ/ドキュメントのリダイレクト）も影響します。
- ARM 環境のコーデック・ドライバ：VP9/Opus のハードウェアアクセラレーションやカメラドライバで境界ケースが出ることがあり、Intel 機では出ない揺らぎが生じます。
- キャッシュ・一時領域の破損：「保存して編集」時にプロジェクト側へアセット登録（JSON/DB 更新）しますが、キャッシュ衝突で参照が切れると“録画済みだがプロジェクトに現れない”症状になります。
各対処の具体手順（恒久対策優先）
アプリと依存関係の健全化
- Clipchamp を最新に：Microsoft Store →「ライブラリ」→「更新」→ Clipchamp を更新。更新後はいったん Windows を再起動。
- WebView2 ランタイムの修復：Windows 設定 →「アプリ」→「インストールされたアプリ」→「Microsoft Edge WebView2 Runtime」→「修復」。修復後に再起動。
- Clipchamp の修復/リセット：設定 →「アプリ」→ Clipchamp →「詳細オプション」→「修復」。改善しない場合は「リセット」（プロジェクトの未保存データが消える可能性に注意）。
- Windows Update 適用：設定 →「Windows Update」→「更新プログラムのチェック」→再起動。
保存先をローカル固定（OneDrive/ネットワークを避ける）
- Clipchamp を開き、左下の「設定」→「ストレージ」。
- 保存先を
C:\Users\<ユーザー>\Videos\Clipchampなどのローカルフォルダーへ。 - OneDrive を併用する場合は、保存先フォルダーをエクスプローラーで右クリック→「このデバイス上で常に保持する」を有効化（プレースホルダー化防止）。
- Known Folder Move を使っている場合（ドキュメント等が OneDrive へリダイレクト）：録画保存先だけは OneDrive 配下から外す。
ポイント：録画直後のファイルは書き込み頻度が高く、同期ドライブは最も相性が悪いタイミング。まずはローカル固定で安定化させ、必要に応じて後段でバックアップ同期するのが安全です。
キャッシュ削除 → 再ログイン
- Clipchamp をサインアウトし、アプリを終了。
- エクスプローラーで
%LocalAppData%\Packages\Clipchamp.Clipchamp_*を開く。 - 配下の Cache と Temp フォルダーを削除（フォルダーごとで可）。
- Windows を再起動 → Clipchamp に再サインイン → 録画テスト。
同階層に EBWebView や LocalCache がある場合、それらのサイズが極端に大きい/壊れている場合は一旦退避して再生成を促すのも有効です。
「録画をエクスポート（MP4）」経由で取り込む
- 録画が完了した直後のダイアログで、「保存して編集」ではなく「録画をエクスポート」を選択。
- エクスポート形式を MP4 にして保存。
- 新規プロジェクトを作り、先ほどの MP4 をドラッグ＆ドロップで追加。
この方法は、録画→プロジェクト登録という一連の内部フローを迂回できるため、取り込み失敗を回避できます。恒久対策を実施するまでの暫定運用に向きます。
WEBM→MP4 変換の実施（応急処置）
WEBM 側のコンテナ破損が原因なら、動画そのものは生きている可能性が高いです。GUI 派は HandBrake、内蔵プレーヤー派は VLC、CLI 派は ffmpeg を使いましょう。
HandBrake（GUI）
- HandBrake を起動し、問題の
.webmを読み込む。 - 「Preset」から「Fast 1080p30」などを選択。
- 「Video」→「Video Encoder」を H.264 (x264) に、Framerate を「Same as source」固定。
- 「Audio」→ Codec を AAC に設定。
- 「Save As」を確認して「Start Encode」。出力された
.mp4を Clipchamp にインポート。
VLC（GUI）
- VLC →「メディア」→「変換/保存」。
- ファイルを追加→「変換/保存」。
- プロファイルで「Video – H.264 + MP3 (MP4)」等を選択（AAC があれば AAC 推奨）。
- 保存先を指定し「開始」。
ffmpeg（CLI）
高品質重視の例（再エンコード）：
ffmpeg -y -i "input.webm" -vf "setpts=PTS/1" -c:v libx264 -pix_fmt yuv420p -preset veryfast -crf 20 -c:a aac -b:a 160k -movflags +faststart "output.mp4"時短重視でまず救出だけを狙う場合（可否はソース次第）：
ffmpeg -y -i "input.webm" -c copy "output.mkv"※ VP9/Opus を MP4 に -c copy で無変換格納できない環境があるため、確実性を優先するなら H.264/AAC へ再エンコードしてください。
PowerShell で一括変換
cd "C:\Videos\ProblemWebM"
Get-ChildItem -Filter *.webm | ForEach-Object {
$out = "$($_.BaseName).mp4"
ffmpeg -y -i $_.FullName -c:v libx264 -pix_fmt yuv420p -preset veryfast -crf 20 -c:a aac -b:a 160k -movflags +faststart $out
}ARM/ドライバ観点の検証
- 別 PC（Intel/AMD）で再現するか確認：同じファイルと手順で再現度が変わる場合、ARM 固有の問題が濃厚です。
- グラフィックスドライバ・カメラドライバ更新：PC メーカーのユーティリティまたは Windows Update から最新を適用。
- ハードウェアアクセラレーション切替：「設定 → システム → ディスプレイ → グラフィック」から Clipchamp の優先 GPU/省電力を切替 → 再検証。
セキュリティ・権限周りの見直し
- カメラとマイク：「設定 → プライバシーとセキュリティ → カメラ/マイク」→「デスクトップアプリのアクセスを許可」をオン。Clipchamp のアクセスが拒否されていないか確認。
- ランサムウェア防止（アクセス制御されたフォルダー）：Windows セキュリティ →「ウイルスと脅威の防止」→「ランサムウェア防止」→「許可されたアプリ」へ Clipchamp を追加。
- 保存先フォルダーのアクセス権：プロパティ →「セキュリティ」でユーザーに「変更/書き込み」があるかを確認。
切り分けのためのチェックリスト
| 観点 | 確認方法 | 結果の解釈 |
|---|---|---|
| WEBM のメタ情報 | ファイルを右クリック→「プロパティ」→「詳細」。または ffprobe -show_format | 作成者/タグが空、Duration が 0 に見える場合はコンテナ/索引不整合の疑い |
| 保存先の種類 | パスが OneDrive（%UserProfile%\OneDrive）や UNC（\\server\share）かどうか | 同期/遅延/ロックで終端書き込みに失敗しやすい |
| 再現条件 | 短時間録画では成功、長時間で失敗などの傾向を記録 | 大容量時に索引書き込みでタイムアウトしている可能性 |
| 別ユーザー/別 PC | ローカルアカウントや別テナント、Intel 機で試す | 環境依存（ARM/ポリシー/WebView2）の切り分けに有効 |
プロジェクト側の見直し（「保存して編集」が消えるとき）
- 自動保存の状態：Clipchamp 右上の自動保存がオンか確認。オフのまま閉じると、録画ファイルは残るがプロジェクトへの紐付けが欠落することがあります。
- プロジェクト格納場所：プロジェクト自体が OneDrive 配下だと、アセット登録時に競合しやすい。まずはローカルで完結させる。
- プロジェクトの復旧：編集画面左のメディアパネルで「メディアを再リンク」を実行し、録画ファイルの実体を手動で紐付け直す。
再発防止の運用設計
- 録画ワークフローの標準化：「録画→ローカル保存→編集→完成ファイルのみクラウド同期」をチーム標準とする。
- 命名規則と保存場所：
YYYYMMDD_案件_テイク番号のようなルールを決め、Videos\Clipchamp\YYYYMM単位で整理。 - バックアップ：ローカル保存直後に Robocopy/バックアップツールで別ドライブへ複製（録画元と別ボリューム推奨）。
- OneDrive の対象外設定：録画フォルダーのみ同期除外 or 常に保持。ファイル オンデマンドの対象外に。
- 長時間録画の分割：1 セッション 15～30 分単位で区切ると終端書き込みの失敗確率を下げられます。
トラブルが続く場合に試す追加策
- 完全再インストール：Clipchamp をアンインストール → 再起動 → Microsoft Store から再インストール。必要なら
%LocalAppData%\Packages\Clipchamp.Clipchamp_*を退避削除。 - OS 側メディアスタック更新：Windows 機能のオプション機能でビデオ拡張を最新に、HEVC などのコーデックも更新。
- イベントログでヒント収集：イベント ビューア →「Windows ログ」→「アプリケーション」→ Clipchamp/WebView2/MediaFoundation のエラーを確認。
- 代替録画の併用：一時的に Windows カメラアプリや Xbox Game Bar で収録し、MP4（H.264/AAC）で受け渡す。
- フィードバック送信：Clipchamp 右上の「ヘルプとサポート」→不具合報告。再現条件・PC 構成・保存先・ファイルサイズ・発生時刻を添えると調査が進みます。
よくある質問（FAQ）
WEBM の「created by」「modified by」が空なのは問題？
必ずしも必須ではありませんが、録画完了時にタグや索引が書かれていない兆候になりえます。ファイル自体が完全でも Clipchamp の形式判定に落ちることがあり、MP4 へ変換するか、録画保存先をローカル固定して再収録するのが確実です。
なぜ OneDrive だと失敗しやすい？
録画直後は断続的に追記・検証が走ります。同期クライアントが同時にファイルを開く、プレースホルダー化する、帯域が詰まる等で終端書き込みが中断され、壊れた WEBM が残るためです。録画はローカル、完成品のみ同期が原則です。
MP4 への再エンコードで画質を落としたくない
H.264 の -crf を 18～20 に設定、ビットレート固定ではなく品質ベースにするのがコツです。音声は AAC 160kbps 程度で十分。納品条件が厳しい場合は ProRes/MXF 等の中間コーデックも検討してください（容量は増えます）。
ARM PC でだけ起きるときの最短回避は？
録画は「録画をエクスポート（MP4）」ルートで出力→編集、または別の Intel/AMD 機で収録だけ行い、編集は ARM 機で行う形が安定しやすいです。ドライバ更新と OS/Clipchamp/WebView2 の全更新もセットで。
企業環境でだけ再現する
MDM/グループポリシーで OneDrive の強制 KFM、Controlled Folder Access、ストレージ仮想化が有効化されていないか確認。録画フォルダーのみ例外（同期除外/許可アプリ追加）を設定すると改善します。
最終チェック：恒久対策のテンプレ手順
- Clipchamp・WebView2・Windows をすべて最新化。
- 保存先を ローカル固定、録画フォルダーは「このデバイス上で常に保持」。
- キャッシュと一時フォルダーをクリア → 再ログイン。
- 録画直後はファイル操作・移動・同期を行わない（数十秒待機）。
- 長尺は分割収録。万一壊れた場合は HandBrake/VLC/ffmpeg で MP4 化して救出。
まとめ
「保存して編集」で消える／手動インポートでエラーになる問題は、WEBM の終端書き込みと保存先の相性が大半です。更新・ローカル固定・キャッシュ整理の三本柱に、暫定運用として「録画をエクスポート（MP4）」と変換ワークフローを組み合わせれば、たいていの現場で再現と再発を止められます。ARM やクラウド同期の特殊条件が絡む場合は、別機材・別アカウントでの切り分けと運用標準化で安定化させましょう。
手早く使える実務レシピ集
| 目的 | やること | 期待結果 |
|---|---|---|
| 今日の収録を確実に通したい | 保存先を一時的に C:\Users\<ユーザー>\Videos\Clipchamp へ、完了後に手動で OneDrive へコピー | 終端書き込みの失敗を最小化 |
| 壊れた WEBM を救出 | HandBrake で H.264/AAC の MP4 へ | Clipchamp で編集可能に |
| 組織内で横展開 | 録画運用ガイド（保存先・同期・分割・バックアップ）をドキュメント化 | 再発率と問い合わせを削減 |
安全上の注意
- キャッシュ・リセット・再インストール前は、必ずプロジェクトと素材のバックアップを取得してください。
- レジストリやセキュリティ設定の変更は企業ポリシーに従い、必要最小限にとどめましょう。
この手順で改善しない場合
- Windows Update を適用し OS 側のメディアライブラリを更新。
- Clipchamp をアンインストール → 再インストール。
- アプリ内「ヘルプとサポート」または Feedback Hub で、不具合報告（再現手順・環境情報・ログの時刻）を提出。
以上の手順で、Clipchamp 録画の読み込み不能問題はほぼ解消または回避できます。恒久対策（保存先のローカル固定・更新・キャッシュ整備）を土台に、暫定回避（エクスポート／変換）と運用ルールを組み合わせて、安定した制作フローを実現してください。
コメント