マガジン

「アップロードの上限に達しました」:回数と容量の数え方

遊びを見つける

執筆にClaudeを使用しています。

同じ絵の厚いカード束と薄い束を比べ、画像容量の最適化を表した写真風イメージ。
記事のテーマをもとに制作したAI生成イラスト。

「アップロードの上限に達しました」と表示されたとき、原因は三つの数字のどれかです。1日あたりの回数、アカウント全体の累計件数、アカウント全体の累計容量で、数える単位も戻るタイミングも別々です。結論から言うと、1日10回の上限だけが日付の切り替わりで戻る性質のもので、その切り替わりはUTC(協定世界時)基準です。日本時間では午前9時にあたります。 直し直しで何度もアップロードする作り手は、1日の回数に当たりやすくなります。画像や音声を多く含む作品は、容量に先に近づきます。小さな作品をたくさん出す人は、累計の件数が先に迫ります。どの上限に当たったかで、取るべき行動は変わります。 この記事では、確認済みの数字だけを使って「数え方」を整理し、上限に近づいたときの判断手順を示します。案内に書かれていない細部(失敗した試行や更新を1回に数えるか、削除で枠が戻るかなど)は、推測せず「現在の案内で確認する」項目として分けます。

この記事の目次
  1. Q1 アップロードの上限は、全部でいくつありますか?
  2. Q2 「1日10回」は、いつ戻りますか?
  3. Q3 「100アップロード」と「1GiB」は、どう効いてきますか?
  4. Q4 上限に達したとき、どの順番で対処すればよいですか?
  5. Q5 自分で「数え直す」には、どうすればよいですか?
  6. Q6 案内で確認しておきたいことは何ですか?
  7. 次の行動

Q1 アップロードの上限は、全部でいくつありますか?

回数・件数・容量に関するものと、1回のアップロードの大きさに関するものがあります。混ざりやすいので、表にします。

  • 1日の回数、数字:1人あたりUTC1日10回、何に対する上限か:日付が変わると数え直される
  • 累計の件数、数字:アカウントごとに100アップロード、何に対する上限か:アカウント全体
  • 累計の容量、数字:アカウントごとに1GiB、何に対する上限か:アカウント全体
  • 1回の大きさ、数字:20MiB以内、何に対する上限か:1回のアップロード
  • ZIP展開後の合計、数字:100MiB以内、何に対する上限か:展開した中身の合計
  • ファイル数、数字:1,000ファイル以内、何に対する上限か:ZIP展開後
  • 1ファイルの大きさ、数字:30MiB以内、何に対する上限か:展開後の各ファイル

上の三つ(1日の回数、累計の件数、累計の容量)は、アカウントという「箱」に対する上限です。下の四つは、1回ごとの「入口の検査」です。入口の検査に引っかかった場合は、作品そのものを軽くしたり整理したりして解決します。

箱の上限に当たった場合は、作品の中身を直しても解決しません。数が戻る条件を待つか、箱の中身を整理する必要があります。

Q2 「1日10回」は、いつ戻りますか?

「1日」はUTCで数えられます。UTCの0時は日本時間の午前9時です。日本時間の午前9時を過ぎると、新しい1日として数え直されます。

次の場面を仮定して考えてみます。日本時間の22日の夜に、直しながら10回アップロードしたとします。この場合、23日の午前0時になっても枠は戻りません。UTCではまだ同じ日だからです。戻るのは、日本時間23日の午前9時以降です。

反対に、日本時間22日の午前8時台に10回使い切ったとします。この場合は、1時間ほど待てば新しい日の枠が使えます。日本時間の午前8時30分は、UTCでは前日の23時30分にあたるので、午前9時で日が替わります。

回数の上限に当たったと思ったら、まず次の点を確認します。

  1. いまの日本時間から9時間引いて、UTCの日付と時刻を出します。
  2. その日に何回アップロードしたかを、手元の記録で数えます。
  3. 次のUTC0時(日本時間の午前9時)まで、あと何時間かを出します。

回数が戻るのを待つ間にできることもあります。作品をローカルで動かして確認する、ZIPを軽くする、紹介文を整えるといった作業です。これらはアップロードの枠を使いません。

Q3 「100アップロード」と「1GiB」は、どう効いてきますか?

この二つは累計の上限です。日付が変わっても自動では戻りません。

まず、1日10回のペースで毎日使い切る場合を計算します。100アップロードに届くのは、最短で10日目です。1日10回の枠が毎日あっても、累計の100が先に壁になります。「毎日10回までなら自由に使える」と考えるのは危険です。

容量は1GiBです。1GiBは1,024MiBです。仮に「アップロードしたものの大きさをそのまま足していく数え方」だと考えると、次の計算ができます。

  • 20MiBいっぱいのアップロードだけを続けると、51個で1,020MiBに達し、52個目で1GiBを超えます。
  • 100アップロードを使い切る場合、1GiBを100で割ると、1回あたりの平均は約10.24MiBまでです。

つまり、100件使い切りたいなら平均約10MiB以下に収まる必要があります。20MiB近い作品を何度も出し直すと、件数より先に容量が尽きる可能性があります。

ここで注意が必要です。容量の数え方が「ZIPの大きさ」なのか「展開後の合計」なのか、あるいは別の基準なのかは、確認済みの情報にありません。上の計算は「そのまま足す」と仮定した目安です。実際の数え方は、現在の案内で確認してください。

どの上限が先に来るかは、作り方で変わります。

  • 小さな作品を何本も出す人: 100アップロードの件数が先に迫ります。
  • 画像や音声を多く含む作品を出す人: 1GiBの容量が先に迫ります。
  • 一つの作品を何度も作り直して出す人: 1日10回の枠が先に尽きやすくなります。

Q4 上限に達したとき、どの順番で対処すればよいですか?

次の順番で確認します。

1. どの上限かを切り分ける

表示された文言と、自分の記録を照らし合わせます。「今日はまだ数回しか出していない」のに止まったなら、日次ではなく累計の上限を疑います。逆に、今日たくさん出したなら日次の上限が濃厚です。

2. 入口の検査を事前に確認する

アップロード前に、ZIPが20MiB以内か、展開後の合計が100MiB以内か、ファイル数が1,000以内か、1ファイルが30MiB以内かを手元で確認します。直下にindex.htmlがあることと、素材が相対パスで指定されていることも確認します。サーバー用コード、サービスワーカー、SharedArrayBufferを使うマルチスレッドは対象外です。

ZIPが20MiBに収まっていても、展開後に100MiBを超えたり、1ファイルが30MiBを超えたりすれば対象外になります。圧縮前後の大きさは別々に確認します。

3. 試し打ちを減らす

確認に使う回数を減らすのが、いちばん効きます。次の工夫が考えられます。

  • アップロード前に、手元のブラウザでindex.htmlを開いて動作確認を済ませる。
  • 変更を1回ずつ出さず、いくつかの修正をまとめてから出す。
  • 画像や音声は、公開前に不要なものを外し、大きさを抑える。

投稿は「入力→表示の確認→公開」の3段階で進み、途中で下書きを保存することもできます。画面上の「表示の確認」を、手元で済ませられる確認の代わりに使うのは避けるのが無難です。この段階が回数や容量にどう数えられるかは、確認済みの情報にないためです。

4. 不要な作品を整理する

公開済みの作品には、公開内容の更新、非公開化、削除ができます。ただし、削除や非公開化によって累計の件数や容量が減るのか、減るとしたらいつ反映されるのかは、確認済みの情報にありません。整理を考える前に、現在の案内で確認します。作品を削除すると元に戻せない場合があるため、手元にソースを残してから行います。

5. 公開済みURLという選択肢を検討する

作品の投稿には、HTML・ZIPの直接アップロードのほかに、公開済みURLを使う方法もあります。URL投稿の場合、アップロードの容量や回数にどう影響するかは、確認済みの情報にありません。この方法を選ぶ前に、現在の案内で確認してください。

Q5 自分で「数え直す」には、どうすればよいですか?

画面上の残り枠をいつでも見られるとは限りません。確認済みの情報にそのような表示は書かれていないため、手元の記録を持っておくと安心です。

表計算ソフトやメモに、次の列を作ります。

  1. アップロードした日時(日本時間)
  2. その日時をUTCに直した日付(日本時間から9時間引く)
  3. 作品名と、新規か更新かの別
  4. ZIPまたはHTMLの大きさ(MiB)
  5. 結果(成功、入口の検査で失敗、上限で停止)

この記録で、三つの数字を自分で確かめられます。

  • 日次の数え方: 2列目のUTC日付ごとに行数を数えます。10に近いなら、その日は控えます。
  • 累計の件数: 全体の行数を数えます。100に近づいたら整理を考えます。
  • 累計の容量: 4列目を合計します。1,024MiBに近づいたら、大きい作品から見直します。

記録を取ると、失敗した試行や更新が実際の上限表示とどう対応するかも、あとから照らし合わせられます。たとえば、自分の記録では9回なのに「上限」と出た場合は、失敗した試行や更新が1回に数えられている可能性が見えてきます。ただし、記録と表示がずれる理由の断定はできません。ずれが出たら、日時と状況をそろえて、現在の案内や問い合わせ先で確認します。

Q6 案内で確認しておきたいことは何ですか?

確認済みの情報から言えるのは、ここまでです。次の点は、現在の案内で確認する項目として手元に控えておくとよいでしょう。

  • 入口の検査で失敗した試行が、1日の回数や累計の件数に数えられるか。
  • 公開内容の更新が、1回のアップロードとして数えられるか。
  • 作品を削除または非公開にしたとき、累計の件数や容量が戻るか。
  • 1GiBの容量が、ZIPの大きさで数えられるのか、展開後の大きさなのか。
  • 下書き保存が、回数や容量に含まれるか。
  • URL投稿が、回数や容量に含まれるか。

どれも、推測で動くと作品を失ったり、枠を無駄にしたりする恐れがあります。判断に迷う操作は、案内で確かめてから行います。

次の行動

まず、手元に「アップロード記録」の表を作り、日本時間とUTC日付の両方を書き込む習慣をつけてみてください。次に、いま持っている作品のZIPの大きさと展開後の合計を確認し、20MiB・100MiB・30MiBに対する余裕を見ておきます。上限に当たってしまったときは、どの上限かを切り分けてから、日次なら日本時間の午前9時以降に再開します。