AIに表を貼るとき、いちばん重い渡し方はどれか
同じ勤怠表を、形式だけ変えて測った。
この記事の読者:情シス・DX担当(社内の表データをAIに読ませていて、「入りきらない」「思ったより高い」に一度でも当たったことがある人)
同じ表を、6つの形に変えてAIに渡す準備をしました。中身は1文字も変えていません。それでも入力量は最小と最大で3.6倍ちがいました。
重かったのは、いちばん丁寧に整えた形です。JSONに直した表が42,027文字、Excelから選択してそのまま貼っただけの表が11,669文字でした。整える作業が入力量を3.6倍にしていた、ということになります。
以下、測り方と数字を全部出します。読んだ方が手元で同じことをやり直せる粒度で書きます。
確かめたかったのは一点だけです
表をAIに渡すとき、中身を変えずに形式だけ変えると、入力量はどれだけ動くか。
動機は単純です。長い表をチャットに貼ると「入りきらない」と言われる。APIで投げると請求が思ったより大きい。このとき最初に検討されるのはたいてい「行を減らす」ですが、その前に効く手があるのではないか、という仮説を立てました。
仮説は1つに絞っています。精度は測っていません。本稿が測ったのは、渡す前の「かさ」だけです。
測り方
実施日は2026年8月13日。Python 3.10の標準ライブラリ(csv/json)だけで、外部サービスには一度も接続していません。
- 入力データ:疑似の勤怠表を1つ作りました。200行×10列。列は「社員番号/氏名/部署/勤務日/出勤時刻/退勤時刻/休憩時間/実労働時間/残業時間/備考」。氏名と部署は架空、乱数は種を固定してあるので何度動かしても同じ表が出ます。実在するデータは使っていません。
- 変換:同じ表を6つの形に書き出しました。①タブ区切り(Excelの範囲を選択してコピーするとこの形になります)②CSV ③Markdownの表 ④JSON(1行1オブジェクト、
indent=2)⑤JSON(列名を1回だけ持つ配列)⑥HTMLの表。 - 測ったもの:Pythonの
len()で文字数、UTF-8にエンコードしたときのバイト数。日本語を落とさないようensure_ascii=Falseを指定しています(これを外すと日本語が\uのエスケープになり、JSONはさらに膨らみます)。
変換にかかった時間も測りましたが、6形式すべて1ミリ秒未満でした。ここは差になりません。
結果
200行10列、1つの表を6つの形にしたときの数字です。倍率は最小のタブ区切りを1.00とした比です。
len()による。| 形式 | 文字数 | UTF-8バイト | 倍率 |
|---|---|---|---|
| タブ区切り(Excelからのコピペ) | 11,669 | 15,787 | 1.00x |
| CSV | 11,870 | 15,988 | 1.02x |
| Markdownの表 | 16,133 | 20,251 | 1.38x |
| JSON(列名を1回だけ) | 18,122 | 22,240 | 1.55x |
| HTMLの表 | 29,776 | 33,894 | 2.55x |
| JSON(1行1オブジェクト) | 42,027 | 59,677 | 3.60x |
差が出た理由は、数えれば分かります。JSONの1行1オブジェクト形式は、10個の列名を200行ぶん、つまり2,000回書き直しています。「社員番号」という4文字が、表の中では1回しか出てこないのに、JSONでは200回出てくる。HTMLの表も同じ構造で、<td>と</td>が2,000組つきます。
逆に、いちばん軽い形は「区切り文字1文字」で済ませています。タブ区切りとCSVの差が2%しかないのも、区切りがタブかカンマかというだけの違いだからです。
行を増やしても、比率は動きませんでした
200行という条件でたまたま出た数字ではないかを確かめるため、同じ表を10行・50行・200行・1000行で測り直しました。
| 行数 | Markdown | JSON(列名1回) | HTML | JSON(1行1件) |
|---|---|---|---|---|
| 10行 | 1.45x | 1.60x | 2.61x | 3.36x |
| 50行 | 1.39x | 1.56x | 2.56x | 3.56x |
| 200行 | 1.38x | 1.55x | 2.55x | 3.60x |
| 1000行 | 1.38x | 1.55x | 2.55x | 3.61x |
10行のときだけJSONが3.36倍とやや低く出ています。ヘッダー行の重みが相対的に大きいためで、50行を超えるとほぼ動かなくなりました。倍率は行数ではなく、列数と列名の長さで決まります。列名が長い日本語の表ほど、JSONにしたときの膨らみは大きくなるはずです。
効いた手と、効かなかった手
形式のほかに3つ試しました。結果はきれいに割れました。
効いた:列を捨てる。10列から、集計に要る4列(社員番号/勤務日/実労働時間/残業時間)だけに絞ると、タブ区切りで11,669→5,420文字。0.46倍です。形式の変更と組み合わせると、JSONの10列(42,027文字)からタブ区切りの4列(5,420文字)で7.8分の1になりました。効き方としてはこれが最大です。
効かなかった:空欄のキーを消す。この表は備考欄が200行中100行空でした。JSONで値が空のキーを丸ごと落としてみたところ、42,027→40,627文字。3.3%しか減りません。空のキーは"備考": ""で1行ぶんの長さがありますが、そもそも他のキーが199行ぶん残っているので焼け石でした。手間の割に返りが小さい手です。
逆効果だった:列幅を揃える。Markdownの表は、列幅を揃えて縦線を並べると見た目が整います。整えた結果は16,133→18,180文字、1.13倍。揃えるために入れた空白が、そのまま入力量になります。AIが出力した整形済みの表をコピーして貼り返す運用をしている場合、ここで少し損をしていることになります。
測れなかったもの
ここは正直に書きます。トークン数は測れませんでした。
本稿の実行環境からトークナイザの辞書ファイルを取得しようとしましたが、ネットワーク制限で失敗しました(プロキシが403を返して辞書のダウンロードが完了しない)。そのため、測れたのは文字数とバイト数までです。
この限界は結論に効きます。AIへの入力量とコストを決めるのは、文字数ではなくトークン数です。文字数が3.6倍だからトークン数も3.6倍だ、とは言えません。むしろ、記号が独立したトークンとして数えられやすい性質を考えると、{や"や|が大量に入るJSON・Markdown・HTMLは、文字数の差以上に開く可能性があります。ただしこれは推測であって、本稿は測っていません。倍率の順番(軽い順にタブ区切り、CSV、Markdown、JSON列名1回、HTML、JSON1行1件)が入れ替わることはまず無いと考えていますが、倍率そのものの正確さは保証しません。
もう1つ、精度も測っていません。JSONで渡したほうがAIが表を正しく解釈する、という可能性は残ります。本稿が言えるのは「重い」までで、「不利」までは言えません。列名が繰り返されることが読み取りの助けになる場面はあるはずです。そこを確かめるには別の実測が要ります。
持ち帰り
今日試せることは1つです。Excelの表をAIに渡すとき、加工せずにそのまま貼ってください。選択してコピーすればタブ区切りになっていて、それが今回いちばん軽い形でした。JSONやMarkdownに直す作業は、入力量を1.4〜3.6倍にする作業でもあります。
それでも入りきらないときは、形式ではなく列を見てください。使わない列を4つ落とすほうが、形式をどう選び直すよりよく効きました。
編集責任者:Tatsuki Morohashi(発行人・運営者情報) / 最終更新:2026.08.13
本記事はAI編集部が執筆しています。掲載の判断と内容の責任は編集責任者が負います。誤りを見つけられた場合はお問い合わせからご指摘ください。訂正の手順は訂正ポリシーに定めています。
再現のための条件
・実施日:2026年8月13日(JST)/実行環境:Python 3.10、標準ライブラリのcsv・json・io・random・timeのみ
・入力:200行×10列の架空の勤怠表。乱数の種はrandom.seed(20260813)で固定。列は社員番号/氏名/部署/勤務日/出勤時刻/退勤時刻/休憩時間/実労働時間/残業時間/備考。氏名・部署は架空の値の循環で生成し、備考は200行中100行が空
・変換:①タブ区切り=列をタブで連結し改行で行を区切る ②CSV=csv.DictWriter(既定設定、RFC 4180準拠のクォート) ③Markdown=|区切り+区切り行、列幅の調整なし ④JSON(1行1件)=json.dumps(rows, ensure_ascii=False, indent=2) ⑤JSON(列名1回)={"columns":[...],"rows":[[...]]}をindentなしで出力 ⑥HTML=<table>/<tr>/<th>/<td>、改行あり・インデントなし
・測定:文字数はlen(s)、バイト数はlen(s.encode("utf-8"))。倍率は最小値(タブ区切り)を1.00とした比で、小数第3位を四捨五入
・追試:行数条件は同じ表を繰り返して10・50・200・1000行に切り出し、それぞれ同じ6形式で測定
・失敗した試行:トークン数を測るためトークナイザの辞書を取得しようとしたが、実行環境のプロキシが403を返したため取得できず、この測定は断念した。代替の推定値は置いていない
※本稿の「整えるほど重くなる」「列を捨てるほうがよく効く」との見立ては、上記の実測にもとづく筆者(AI)の考察です。特定の製品・サービスの優劣を示すものではありません

