荷物の上限を「重さ」だと思って詰めたら、実は「個数」の上限で、断られた。仕事の上限を、単位を取り違えたまま見積もったことはないだろうか。
実はこれは、私たちの会社の社内ツールで起きたことである。
結論を先に言う。上限は、数え方が分からないまま運用すると踏む。通った実績から余裕を取り、手前で機械的に止める。そして、分からないことは分からないと書いておく。
大きいほうが通り、小さいほうが落ちた
社内の業務ツールを、Google Apps Script（Googleのサービス上で動くプログラム実行環境）に載せていた。データを同梱して送ったところ、10分以上待たされた末、原因の書かれていないエラーが1行だけ返ってきた。
2026年8月7日の実測では、約39MB（約15.7M文字）は成功し、約32MB（約21.5M文字）は失敗した。約26MB（約15.5M文字）に縮めたら成功した。容量はバイトで見ると小さいほうが落ちている。文字数で並べると矛盾しない。
日本語は1文字が大きく、英数字は小さいので、中身の比率が変わるとバイトと文字数はずれる。つまり、前回通ったからという判断は、中身が変わった瞬間に外れる。
人の職場なら、こうなる
ポイントは、上限の単位を確かめないまま、前回の実績で判断することである。
たとえばSNSのリール制作で、「前回は30秒で通ったから今回も」と進める。ところが審査の基準が、長さではなく別の何かだったら、通る理由も落ちる理由も分からない。しかも失敗の知らせは、原因を言ってくれないことが多い。今回も、1回の失敗の確認に10〜15分かかった。
手前で止める運用
自社では、予算を14.9M文字と決め、超えそうなら自動で削るようにした。夜間の反映は、2026年8月11日〜9月24日の43回、すべて成功している。
分かっていないこと
- 境界は、15.7M文字と21.5M文字の間のどこか、としか言えない。
- 15.7M文字で通ったという記録は、社内の別の記録と食い違っている。元の実行ログは残っていない。だから予算は、どちらの説でも安全側になる値にした。
- 夜間の文字数は記録しておらず、上限にどこまで近づいた夜があったかは今から分からない。
- Googleが文字数で数えていると確認したわけではない。言えるのは、「バイトでは説明がつかず、文字数なら矛盾しない」ところまでである。
自社で確かめる3つの問い
- 上限のある仕組みについて、上限の単位を確かめてから使っているか
- 上限に近づいたことを、毎回の記録に残しているか
- 失敗の知らせが原因を言わないとき、切り分けの手順があるか
2つ以上「いいえ」なら、見直す余地があるかもしれない。目安であって実証ではないが、AI診断で確かめてみてほしい。
