【失敗実録】YouTube動画のアップロードが”2GBの壁”で何度も落ちた話｜原因と、AIと突き止めた突破法

2026-06-222026-10-15

YouTubeの大容量アップロードが2GBの壁で止まる問題とAIで突き止めた突破法のアイキャッチ

「アップロード中… 61%」——そこで、また止まった。

3.27GBの動画を YouTube に上げようとして、3回連続で同じ場所で落ちました。エラーは見たこともない OSError: [Errno 34] Result too large。回線のせいだと思って何度もやり直し、そのたびに”空っぽの動画”が公開予約に残り、しまいには元の動画ファイルまで消えるという二次被害まで起きました。

※ 本記事にはアフィリエイトリンク（広告）が含まれます。広告のすぐ上には「PR」と表示しています。

※ 61%・3.27GB・エラー文などは、2026年6月に筆者の環境で起きたことの記録です。YouTubeのアップロード上限や仕組みの説明は、2026年10月13日に公式ヘルプ・公式ドキュメントで確認して追記しました。

この記事は、非エンジニアの私（会社員・40代）が、相棒のAI（Claude Code）と一緒にこの「2GBの壁」の正体を突き止めて、最終的に3.27GBの動画をそのまま上げ切るまでの失敗と原因究明の実録です。同じ「大きいファイルがアップロードできない」で詰まっている人の役に立てば。

社長正直、最初は「うちのWi-Fiが弱いのかな」くらいにしか思ってなかったんだよね。

策まず回線を疑うのは自然です。でも今回は、回線じゃなかったんです。

※ 本記事は Claude Code（筆者が使用中のAIアシスタント）が筆者の実体験を元に執筆しています。

📌 目次（クリックでジャンプ）

なぜか大きい動画だけ、いつも同じ所で落ちる
「回線のせい」を疑ったけれど、犯人は別にいた
解決：ファイルはそのまま、「送り方」だけ変えた
油断した隙の二次被害——”空っぽの動画”と、消えたファイル
非エンジニアでも、”原因究明”はAIと組めばできる
同じ症状かどうかを見分けるチェックリストと、実際に使った2つの対策

なぜか大きい動画だけ、いつも同じ所で落ちる

社長：大きい動画だけ止まるなら、何を記録すればいい？

策：この記事では、小さい動画との違い、停止した割合、表示されたエラーを手がかりにしています。原因は環境ごとに切り分けが必要です。

凛：再試行する前に、ファイルの大きさと止まった位置をメモしておきましょう。

その日アップしようとしていたのは、約44分のBGM動画。ファイルサイズは3.27GB。アップロードを始めると数分は進むのですが、最初は毎回1%あたりで止まりました（Errno 34 のエラーがはっきり出たのは、下の「61%で止まる」段階です）。

最初は「接続が不安定なんだろう」と何度か再実行。けれど、おかしなことに気づきます。同じ仕組みで上げている”短い動画”（30MBくらい）は、毎回ちゃんと成功するのです。

凛大きいファイルだけ失敗するなら、回線が”弱い”わけじゃなさそうですよね？

策そこが分岐点でした。ランダムに切れるなら回線。でも「大きい方だけ・毎回ほぼ同じ所で」失敗するなら、それは”系統的な”原因。偶然じゃない。

ここで大事なのは、「失敗の仕方」をよく観察することでした。たまたま落ちるのか、必ず同じ条件で落ちるのか。これだけで疑うべき場所がガラッと変わります。

※補足：ここで言う「アップロード」は、パソコンの中の動画ファイルを YouTube のサーバーに送る作業のこと。送っている途中で通信が途切れると、当然そこで止まります。

「回線のせい」を疑ったけれど、犯人は別にいた

そこで、AIに切り分けを手伝ってもらいました。やったことはシンプルで、「どこまで進んで落ちるか」を毎回メモしただけです。

1回目：1%で停止
（対策を1つ入れて）2回目：61%まで進んで停止

この「61%」が決定的なヒントでした。3.27GBの61%は、ちょうど約2GB。つまり「送ったデータの合計が2GBに達した瞬間に、毎回死ぬ」。

策筆者の環境（Mac＋Pythonの送信ライブラリ）では、ひとつの通信路（コネクション）で累計2GBを超えて送ったところで、送信処理がエラーを返していました。短い動画が成功してたのは、合計が2GBに届かなかったからだと考えています。

社長なるほど…「回線が遅い」じゃなくて「1本の通信で送れる量に上限があった」ってことか。

凛観察してなかったら、永遠に”Wi-Fiが悪い”で再起動し続けてましたね…。

念のため補足すると、これは筆者の環境での話で、すべての人に起きるわけではありません。同じ症状が「毎回2GB前後で出る」なら、この線を疑ってみる価値がある、という程度に受け取ってください（この現象の原因を公式に説明した資料は、2026年10月13日時点で見つけられていません）。

2GBは YouTube 側の上限ではありません。YouTube ヘルプでは、アップロードできる動画の上限は「256GB または 12時間のどちらか小さい方」とされています。また、15分を超える動画を上げるには Google アカウントの確認（電話番号での確認）が必要です（2026年10月13日確認／出典：YouTube ヘルプ「15 分を超える動画をアップロードする」）。つまり今回の壁は、YouTube ではなく送る側（自分のパソコンと送信の仕組み）にありました。

解決：ファイルはそのまま、「送り方」だけ変えた

原因が「1本の通信路で2GB超を送れない」ことなら、対策は2つです。

動画を2GB未満に圧縮し直す（確実だが画質を触る）
送る途中でこまめに通信路を張り替える（ファイルはそのまま）

今回は画質を落としたくなかったので、2番を選びました。技術的には「チャンク（小さなかたまり）ごとに接続を開き直す」設定にしただけ。これで1本の通信路が2GBに到達する前に切り替わるので、上限に当たりません。あわせて、通信経路を新しい規格（IPv6）ではなく従来の規格（IPv4）に固定しました。長い大容量送信ではこちらの方が安定したからです。

結果、3.27GBを圧縮なしでそのまま、最後（100%）まで上げ切ることができました。

凛ファイルは1ミリも変えてないのに、”送り方”を変えただけで通ったんですね。

策はい。今回は、原因が分かったら対策は小さく済みました。逆に、原因を取り違えたままだと、何度やり直しても同じ所で止まり続けます。

なお、画質を少し触ってもよいので「動画を2GB未満に圧縮し直す」（上の1番）を選ぶ場合は、動画の形式や容量を変換できるソフトを使う方法もあります。筆者は今回この方法は使っていないので、機能や料金は公式サイトで確認してください。

PR / アフィリエイトリンク

油断した隙の二次被害——”空っぽの動画”と、消えたファイル

社長：動画IDが返ったら、元ファイルを片付けていい？

策：この記事では、その判定で元ファイルを失っています。送信後の動画の長さと処理状態まで確認する運用に変えました。

凛：手元のコピーを残し、管理画面で再生できる状態か確かめてから片付けて。

実はこの戦いの最中、もっと痛い事故が起きていました。

アップロードが途中で失敗したのに、YouTube側には再生時間ゼロの”空っぽの動画”が公開予約付きで残っていたのです。気づかず放置すれば、予約日に中身ゼロの動画が公開されるところでした（毎回これを見つけて削除する羽目に）。

さらに最悪だったのが、自動化スクリプトの作りの問題。「動画IDが返ってきた＝成功」と誤判定して、元の動画ファイルを自動削除してしまい、苦労して書き出した動画を1本失いました（バックアップも取っていなかった）。

社長これは本当に肝が冷えた…。「成功したフリ」をして元データを消すって、いちばんやっちゃいけないやつ。

策教訓は2つ。①アップロード前に必ず元ファイルをバックアップする。②”成功”は動画IDの有無ではなく、再生時間がちゃんと付いているかで判定する。この2つを仕組みに入れ直しました。

地味ですが、自動化を任せるほど「失敗したときに何が壊れるか」を先に潰しておくことが効いてきます。元ファイルの退避を仕組みにする方法は、Google Driveに自動バックアップする方法｜Macの「同期してるから安心」が危ない理由でまとめています。

1接続2GB上限をチャンクごとに接続を張り替えて回避するBefore/After図

同じ症状かどうかを見分けるチェックリストと、実際に使った2つの対策（2026年9月追記）

公開後に「うちも同じ？」という質問をもらったので、筆者の環境で起きたことを、切り分けに使える形でまとめ直します。環境が違えば原因も違うので、まず下の条件に当てはまるかを見てください。

筆者の環境で起きたこと（記録）

発生日：2026年6月20日
環境：Mac、Python（YouTube公式の送信ライブラリ経由）、ファイルは約44分の動画で3.27GB
症状の型：30MB程度の短い動画は毎回成功。3.27GBは1%で停止。通信経路をIPv4に固定すると61%（＝約2GB）まで進んで必ず停止
エラー文：OSError: [Errno 34] Result too large（暗号化通信の送信中に発生）
判定：「大きいファイルだけ・毎回同じ割合で落ちる」は、回線の不安定さだけでは説明しにくい。1本の通信路で累計2GBを超えたところで落ちていると判断した

対策1：通信路を毎回張り替える（ファイルはそのまま）

YouTube の公式の送り方（再開可能アップロード）は、ファイルを小さなかたまりに分けて送り、途中で通信が切れても、届いた所の続きから再開できる仕組みです（2026年10月13日確認／出典：YouTube Data API「再開可能なアップロード」）。ただ筆者の環境では、送信ライブラリが内部で同じ通信路を使い回していたため、累計が2GBに達したところで止まりました。そこで「1かたまり送るごとに通信路を閉じて開き直す」ように、送信部分を差し替えました。AIに「httplib2 の接続を毎リクエスト後に閉じるパッチを書いて」と頼んで出てきたのが、次の数行です。

import httplib2
_req = httplib2.Http.request
def req(self, *a, **k):
    r = _req(self, *a, **k)
    for c in list(self.connections.values()):
        try: c.close()
        except Exception: pass
    self.connections.clear()
    return r
httplib2.Http.request = req

対策2：通信経路をIPv4に固定する

1%で落ちていたのは経路の問題で、これは新しい規格（IPv6）ではなく従来の規格（IPv4）に固定すると61%まで伸びました。対策1と併用して、3.27GBを圧縮せずそのまま完走しています。この2つは「送り方」だけの変更で、動画ファイルには何もしていません。

「送れた」と「YouTube側で処理できた」は別物

もう1つ、上の本文で書いた二次被害の再発防止です。筆者の環境では、アップロード直後に YouTube の管理情報を読むと、動画の長さが「0秒（P0D）」と返ることがありました（YouTube の処理が終わる前の時間帯）。ここを「成功した」と判定して元ファイルを消すと、処理に失敗したときに手元に何も残りません。筆者はこれで元動画を1本失いました。今は次の2点を固定しています。

アップロードを始める前に、動画ファイルを別フォルダへコピーしてから送る
完了判定は「送信が終わった」ではなく、動画の長さが0秒以外で返り、処理中の表示が消えたことを確認してから

※ YouTube Data API の公式ドキュメントでは、動画ごとに「処理の状態」（処理中・成功・失敗など）を確認できる項目が用意されています。自動化するなら、長さに加えてこの状態が「成功（succeeded）」になったかも見ると確実です（2026年10月13日確認／出典：YouTube Data API「Videos」）。