AIにファイル容量の一覧を整理させるときは、数値だけでなく単位を残します。「1 GB」と「1 GiB」は同じバイト数ではありません。画面に丸めて表示された「1.0」だけを比べると、上限を超える候補を範囲内と判断することがあります。
この記事では、架空のファイル候補と上限をバイトへそろえ、判定表を作ります。実ファイルを測定した例や、特定サービスのアップロード上限を調べた結果ではありません。AIサービスやアップロードも実行していません。
目次
容量の単位と、比べる対象を決める
MBとGBは十進、MiBとGiBは二進の倍数です。NISTの説明では、それぞれ次のバイト数になります。NIST：二進接頭語とSI接頭語の比較（新しいタブで開く）
表は横にスクロールできます
| 単位 | 今回使うバイトへの換算係数 |
|---|---|
| MB | 1,000,000 |
| GB | 1,000,000,000 |
| MiB | 1,048,576 |
| GiB | 1,073,741,824 |
この表は単位の定義です。実サービスがGBという表示をどの定義で使っているか、制限の対象がファイル本体かリクエスト全体かは、そのサービスの資料へ戻って確認します。表の定義だけで個別サービスの実装を確認したことにはしません。
一ファイルの上限、保存容量の合計、転送量、転送速度も別の量です。保存容量に余裕があっても一ファイルの制限へ入るとは限らず、速度の数値を容量の上限と比べることもできません。
元の値と単位を分けて保存する
今回は「一つのファイル本体が1 GB以下なら容量条件を満たす」という架空の上限を使います。1 GBは1,000,000,000バイトと定義し、ちょうど同じ値も含めます。実サービスの仕様ではありません。
次のF01〜F04は別々のファイル候補です。まとめて送る一回の要求や、合計保存量の例ではありません。U01は単位が不明瞭、R01は速度の資料が混ざった例です。
record_id,value,unit,kind
L01,1,GB,limit
F01,950,MiB,file
F02,960,MiB,file
F03,1,GiB,file
F04,1000,MB,file
U01,1,G,file
R01,100,Mb/s,rate
AIへは原文の値と単位を分けて整理させ、換算後のバイト数を別列へ加えます。元の単位を消すと、計算違いなのか資料の読み違いなのかを追えません。実務では、参照資料と確認日、実ファイルならどの版を測ったかも残します。
U01のGを、見慣れたGBの省略として勝手に確定しません。R01も今回のファイル容量の比較対象へ混ぜず、別の量として外します。単位をすべて大文字へ変える前処理も、元の意味を確認してから行います。
バイトへ換算してから、上限と比べる
換算は「値×対応する係数」です。結果を丸める前に、上限との差を計算します。
表は横にスクロールできます
| ID | 原表記 | 換算したバイト数 | 架空の上限との差 | 容量条件の判定 |
|---|---|---|---|---|
| F01 | 950 MiB | 996,147,200 | 3,852,800バイトの余裕 | 範囲内 |
| F02 | 960 MiB | 1,006,632,960 | 6,632,960バイト超過 | 範囲外 |
| F03 | 1 GiB | 1,073,741,824 | 73,741,824バイト超過 | 範囲外 |
| F04 | 1000 MB | 1,000,000,000 | 差0、今回の上限と同じ | 範囲内 |
| U01 | 1 G | 未換算 | 単位が確定していない | 確認待ち |
| R01 | 100 Mb/s | 比較対象外 | ファイル容量ではない | 別の量 |
950 MiBと960 MiBの差は10 MiBですが、この架空の上限をまたぎます。「だいたい1 GB」とまとめず、実際のバイト数で判定します。
実ファイルでは、作成前の見積もりと、最終的に書き出したファイルのサイズも分けます。圧縮後、結合後、再書き出し後に内容が変わったなら、その版のバイト数を確認します。ここで示す候補サイズは、実ファイルを作って確かめたものではありません。
表示の丸めを、判定へ戻さない
F02は十進GBで表すと1.00663296 GBです。小数第1位だけ表示すると1.0 GBになり、F04の1.0 GBと見分けがつきません。表示を丸めても、元のバイト数と判定は保持します。
F02：1,006,632,960バイト → 表示1.0 GB → 上限超過
F04：1,000,000,000バイト → 表示1.0 GB → 上限と同じ
同じ表示になったからといって、上限との関係まで同じではありません。共有表にはバイト数か超過量を残し、見た目の桁数だけで採用を決めないようにします。
入力が「約1 GB」「1 GB前後」といった概数なら、その概数を正確な1,000,000,000バイトとして扱いません。今回の換算表は、値と単位が明示された架空データに対する計算です。資料が丸め値しか示していない場合は、上限判定に必要な精度があるかを別に確認します。
AIへの依頼は、換算できない行も出力させる
容量資料を、バイト数へ換算して確認表にしてください。
元ID、原文の数値、単位を保持し、換算値は別列へ追加してください。
換算対象はMB、GB、MiB、GiBだけです。
MB=1000000、GB=1000000000、MiB=1048576、GiB=1073741824バイト。
単位不明、概数、資料間の定義不一致は推測せず確認待ちにしてください。
容量以外の量を混ぜないでください。速度は別の量として分けてください。
比較上限は、この架空例では1000000000バイト以下です。
各ファイル候補を個別に比較し、まとめた合計と混同しないでください。
出力：ID｜原表記｜換算バイト数｜換算根拠｜上限との差｜判定｜確認事項。
丸める前の値で判定し、表示用の丸めと分けてください。
この判定だけで、実際のアップロード成功や保存成功を断定しないでください。
入力：［必要な数値と資料］
AIが作った表では、換算係数と掛け算を一行ずつ照合します。ファイル候補の件数、換算できた件数、確認待ち、別の量を数え、入力行がどこかへ消えていないかを確認します。この例では、上限1行、換算できるファイル4行、単位確認待ち1行、速度1行の計7行です。
単位の揺れを許す場合も、採用した対応表を残します。元資料のMBをMiBへ自動で読み替える、大小文字を一律に無視するなど、根拠のない補正を換算と一緒に行わないでください。
容量条件の判定と、送信できるかを分ける
今回の範囲内という結果は、定義した一つの容量条件を満たすという意味です。形式、ファイルの破損、認証、契約、要求全体のサイズ、残っている保存領域などを検証した結果ではありません。実サービスでは対象資料と環境に合わせて、別の条件も確認します。
上限が「未満」なのか「以下」なのかも確認します。今回F04を範囲内にしたのは、架空の条件を「以下」と決めたからです。境界が不明な資料から、同じ値なら必ず受け付けられるとは判断しません。
渡す成果物は、原表記、換算係数、バイト数、比較条件、超過量、確認待ちを持つ表です。容量が大きい候補を自動で優位とせず、何の制限を満たしたいのかへ戻って使います。資料の数値整理と、実ファイルの測定・転送結果を分ければ、次の担当者も判定を追えます。
参考資料
公式の単位定義の確認日：2026年10月20日。上限と候補データは架空例です。換算値と差をローカルで検算しました。実ファイルのサイズ測定、AI出力、製品の容量制限、アップロード・保存、画面表示は検証していません。