「アップロード中… 61%」——そこで、また止まった。
3.27GBの動画を YouTube に上げようとして、3回連続で同じ場所で落ちました。エラーは見たこともない OSError: [Errno 34] Result too large。回線のせいだと思って何度もやり直し、そのたびに”空っぽの動画”が公開予約に残り、しまいには元の動画ファイルまで消えるという二次被害まで起きました。
この記事は、非エンジニアの私（建設業・40代）が、相棒のAI（Claude Code）と一緒にこの「2GBの壁」の正体を突き止めて、最終的に3.27GBの動画をそのまま上げ切るまでの失敗と原因究明の実録です。同じ「大きいファイルがアップロードできない」で詰まっている人の役に立てば。
社長 正直、最初は「うちのWi-Fiが弱いのかな」くらいにしか思ってなかったんだよね。
策 多くの人がそこで止まります。でも今回は、回線じゃなかったんです。
📌 目次（クリックでジャンプ）
なぜか大きい動画だけ、いつも同じ所で落ちる
その日アップしようとしていたのは、約44分のBGM動画。ファイルサイズは3.27GB。アップロードを始めると数分は進むのですが、毎回1%あたりで Errno 34 を吐いて止まりました。
最初は「接続が不安定なんだろう」と何度か再実行。けれど、おかしなことに気づきます。同じ仕組みで上げている”短い動画”（30MBくらい）は、毎回ちゃんと成功するのです。
凛 大きいファイルだけ失敗するなら、回線が”弱い”わけじゃなさそうですよね？
策 そこが分岐点でした。ランダムに切れるなら回線。でも「大きい方だけ・毎回ほぼ同じ所で」失敗するなら、それは”系統的な”原因。偶然じゃない。
ここで大事なのは、「失敗の仕方」をよく観察することでした。たまたま落ちるのか、必ず同じ条件で落ちるのか。これだけで疑うべき場所がガラッと変わります。
※補足：ここで言う「アップロード」は、パソコンの中の動画ファイルを YouTube のサーバーに送る作業のこと。送っている途中で通信が途切れると、当然そこで止まります。
「回線のせい」を疑ったけれど、犯人は別にいた
そこで、AIに切り分けを手伝ってもらいました。やったことはシンプルで、「どこまで進んで落ちるか」を毎回メモしただけです。
- 1回目：1%で停止
- （対策を1つ入れて）2回目：61%まで進んで停止
この「61%」が決定的なヒントでした。3.27GBの61%は、ちょうど約2GB。つまり「送ったデータの合計が2GBに達した瞬間に、毎回死ぬ」。
策 これ、実は古いMac＋特定の送信方法の組み合わせで知られた現象で、ひとつの通信路（コネクション）で累計2GBを超えて送ると、送信処理がエラーを返すんです。短い動画が成功してたのは、合計が2GBに届かなかったから。
社長 なるほど…「回線が遅い」じゃなくて「1本の通信で送れる量に上限があった」ってことか。
凛 観察してなかったら、永遠に”Wi-Fiが悪い”で再起動し続けてましたね…。
念のため補足すると、これは特定環境での話で、すべての人に起きるわけではありません（同じ症状が「必ず2GB前後で出る」なら、この線を疑う価値がある、という業界的にも知られた一般論です）。
解決：ファイルはそのまま、「送り方」だけ変えた
原因が「1本の通信路で2GB超を送れない」ことなら、対策は2つです。
- 動画を2GB未満に圧縮し直す（確実だが画質を触る）
- 送る途中でこまめに通信路を張り替える（ファイルはそのまま）
今回は画質を落としたくなかったので、2番を選びました。技術的には「チャンク（小さなかたまり）ごとに接続を開き直す」設定にしただけ。これで1本の通信路が2GBに到達する前に切り替わるので、上限に当たりません。あわせて、通信経路を新しい規格（IPv6）ではなく従来の規格（IPv4）に固定しました。長い大容量送信ではこちらの方が安定したからです。
結果、3.27GBを圧縮なしでそのまま、最後（100%）まで上げ切ることができました。
凛 ファイルは1ミリも変えてないのに、”送り方”を変えただけで通ったんですね。
策 はい。原因が分かれば、対策は驚くほど小さい。逆に、原因を間違えると一生直りません。
[CTA_CLAUDE_CODE]
油断した隙の二次被害——”空っぽの動画”と、消えたファイル
実はこの戦いの最中、もっと痛い事故が起きていました。
アップロードが途中で失敗したのに、YouTube側には再生時間ゼロの”空っぽの動画”が公開予約付きで残っていたのです。気づかず放置すれば、予約日に中身ゼロの動画が公開されるところでした（毎回これを見つけて削除する羽目に）。
さらに最悪だったのが、自動化スクリプトの作りの問題。「動画IDが返ってきた＝成功」と誤判定して、元の動画ファイルを自動削除してしまい、苦労して書き出した動画を1本失いました（バックアップも取っていなかった）。
社長 これは本当に肝が冷えた…。「成功したフリ」をして元データを消すって、いちばんやっちゃいけないやつ。
策 教訓は2つ。①アップロード前に必ず元ファイルをバックアップする。②”成功”は動画IDの有無ではなく、再生時間がちゃんと付いているかで判定する。この2つを仕組みに入れ直しました。
地味ですが、自動化を任せるほど「失敗したときに何が壊れるか」を先に潰しておくことが効いてきます。
非エンジニアでも、”原因究明”はAIと組めばできる
今回いちばん伝えたいのは、技術の細かい話ではありません。
私はコードが書けません。それでも、「どこで・どう失敗したか」を観察してAIに渡すだけで、原因の特定から対策の実装まで一緒にたどり着けた、という事実です。やったのは「61%で落ちる」と気づいてメモしたこと。あとは相棒（AI）が「それ2GBですね」と繋いでくれました。
凛 専門知識そのものより、「ちゃんと観察して、正確に伝える」ことが武器になるんですね。
策 そうです。AI時代の個人の強みは、コードを書ける事より「現場で起きたことを正確に言語化できる事」かもしれません。
もし今あなたが「大きいファイルだけアップロードできない」で止まっているなら、まず“毎回どこで落ちるか”をメモしてみてください。そのひと手間が、犯人(2GBの壁)を浮かび上がらせます。
そして、こういう”原因究明の相棒”が一台あると、非エンジニアの作業はまるで変わります。私が日々使っているAIツールについては、下記でも紹介しています。
PR / アフィリエイトリンク
この記事は、実際に起きた出来事をもとに、運営者の相棒であるAI（Claude）が構成・執筆しています。登場する会話は、要点を分かりやすく伝えるための再構成です。具体的なチャンネル名や個人が特定される情報は伏せています。
