AIのPDF添付が壊れる原因｜base64転記で1バイト欠けた実測

AIに「この見積書をメールの下書きに添付しておいて」と頼む。下書きはちゃんと出来上がり、添付のアイコンも付いている。ところが、そのPDFを開こうとすると開けない。

私（UMEO CREATE・伊藤）は、これを自分の環境で実際に踏みました。原因を追うと、PDFの中身が1バイトだけ欠けていました。ファイル名も、作成日時も、サイズもほぼ同じ。違うのは1バイトだけです。それでもPDFは開けなくなります。

先に結論を書きます。壊したのはGmailでも、base64という仕組みでもありません。AIが、base64に変換した長い文字列を「自分で書き写す」経路を通したことが原因でした。この記事では、2026年7月から9月に私の環境で起きたことを日付と数字つきで整理し、いま使っている「壊れない添付の手順」と「壊れていないことの確かめ方」をまとめます。AIエージェント（指示を受けてファイル操作やメール作成まで代行するAI）に事務を任せ始めた方、これから任せたい方に向けた記事です。

この記事の目次（7項目）

何が起きたか：同じ名前のPDFが、片方だけ開けなかった

時系列で書きます。

2026年7月17日：最初の兆候（3バイト欠け）
AIからGoogleドライブへファイルを置く方法を試していたときのことです。AIとドライブをつなぐ接続部品（コネクタ）には、ファイルの中身をbase64の文字列で渡してアップロードする機能があります。これで小さなファイルを1つ上げ、念のためサイズを比べたところ、手元は7,975バイト、ドライブ側は7,972バイトでした。3バイト足りません。8KBに届かない小さなファイルです。

同じ日、Gmailの下書きにPDFを添付する機能も試しました。こちらは13KBと16KBのPDFで下書きが作成でき、添付も付いていました。私はこの時点で「請求書や納品書は、AIがPDF添付済みの下書きまで作り、私は宛先を確かめて送信ボタンを押すだけ」という手順を、自分の標準として記録しています。ドライブ側の3バイト欠けは「アップロードのときは気をつけよう」で済ませてしまいました。

2026年8月24日：開けない見積書が見つかる
約1か月後、書類フォルダを整理していて、取引先向けの見積書PDFが2か所にあることに気づきました。案件のフォルダにある原本と、添付用に作られたコピーです。ファイル名は同じ、PDFの中に記録されている作成日時も一致。ところがコピーのほうだけ開けません。

中身を調べると、ページ本文が入っている部分の、先頭の1バイトが欠けていました。PDFは本文を圧縮や符号化をかけた状態で持っているので、先頭が1文字ずれると、そこから先がすべて復元できなくなります。

幸い、このPDFはまだ送信されていませんでした。送信履歴を確認したところ、その取引先へ送ったメールは6月のものが最後でした。もし気づかずに送っていたら、「見積書が開けません」という連絡を先方からもらうことになっていたはずです。見積書や請求書は、届いて読めることが前提の書類です。ここで信用を落とすのは、もったいないどころの話ではありません。

原因はbase64ではなく、AIが「書き写す」ことだった

ここは誤解されやすいので、丁寧に書きます。

base64は、PDFや画像のような「文字ではないデータ」を、英数字と記号だけの文字列に置き換える方式です。メールの添付ファイルは昔からこの方式で送られています。base64そのものは何も壊しません。 Gmailも壊しません。プログラムが機械的に変換して渡す限り、1バイトも変わらずに届きます。

問題は、AIエージェントがコネクタを使うときの渡し方にありました。私が使っていたコネクタは、添付ファイルを「base64の文字列」として受け取る作りです。するとAIは、次の手順を踏むことになります。

1. 手元のPDFをbase64の文字列に変換する
2. その文字列を読む
3. コネクタを呼び出す命令の中に、その文字列を一字一句、自分で書き出す

この3番目が危ない箇所です。AIは文章を1語ずつ生成する仕組みで動いています。コピー機のように丸ごと複写しているわけではありません。意味のある文章なら多少の言い換えがあっても通じますが、base64は意味を持たない文字の並びです。数千文字、数万文字の無意味な並びを、1文字も落とさず書き写すことを求められているわけです。

たとえるなら、床まで届く長いレシートに印字された英数字を、人が目で読んで別の紙に手で写すようなものです。ほとんど合っていても、どこかで1か所飛ばせば、そこから先の意味が変わります。

正直に書いておくと、どの段階で何文字落ちたのかまでは特定できていません。分かっているのは、入口と出口でバイト数が合わなかったこと（7,975→7,972）、そして壊れたPDFは本文部分の先頭1バイトが無かったこと、この2つの事実だけです。「何回に1回壊れるのか」という率も測っていないので、ここには書きません。ただ、8KB未満の小さなファイルで実際に欠けた以上、「小さいファイルなら大丈夫」とは言えない、というのが私の結論です。

大きいPDFでは、そもそも現実的ではない

壊れるかどうか以前に、サイズの問題もあります。

base64にすると、データは元の約1.33倍の文字数になります。私の環境で、約250KBの発注書PDFを変換したところ、文字列は331KB、AIが扱う単位（トークン）に直すとおよそ8万になりました。これをAIが読み、さらに同じ長さを書き出すことになります。

時間も費用もかかるうえ、書き写す文字数が増えるほど、どこかで落とす可能性も上がります。13KBや16KBで下書きが作れたからといって、250KBでも同じようにいくとは考えないほうが安全です。社印の画像が入った請求書、写真つきの報告書、数ページの提案書は、すぐ数百KBになります。

壊れない手順：AIに「中身」を通さず、「場所」だけ渡す

対策の考え方は1つです。ファイルの中身をAIに読ませない・書かせない。AIには「どのファイルか（場所）」だけを扱わせる。

人に頼むときと同じです。書類の内容を電話で読み上げてもらって書き取るのではなく、封をした封筒のまま手渡してもらう。中身に触れなければ、写し間違いは起こりようがありません。

私がいま使っている経路は、次の3つです。

① メールの添付：ブラウザの「ファイルを選択」に、ファイルの場所を渡す
本文だけの下書きを先にAIに作らせます。そのあとAIにブラウザを操作させ、下書きを開いて、添付欄（ファイル選択の入力欄）に手元のファイルの場所（パス）を指定させます。ファイルを読み込んでGmailへ送るのはブラウザの仕事で、AIは中身に一切触れません。

2026年8月22日に、この方法で312KBの発注書PDFを添付し、自分宛に送って確かめました。9月13日には、取引先への返信の下書きに請求書PDFを添付する作業で使い、AIの操作は4回の呼び出しで済みました。

② ドライブへの配置：同期フォルダにコピーする
パソコンにGoogleドライブの同期アプリを入れていると、ドライブが1つのフォルダとして見えます。AIには、そのフォルダへファイルをコピーする命令だけを出させます。アップロードは同期アプリが行うので、ここでもAIは中身を通りません。

③ ドライブの中での移動：ドライブ側でコピーさせる
すでにドライブ上にあるファイルを別のフォルダへ置くときは、コネクタの「コピー」機能を使います。ファイル番号と行き先を指定するだけで、複製はGoogleのサーバーの中で行われます。

3つに共通するのは、AIが扱うのが「パス」や「ファイル番号」という短い文字列だけだという点です。短ければ、書き間違える余地はほとんどありません。

壊れていないことを、どう確かめるか

手順を変えても、確認を省いてよいことにはなりません。私が決めている確認は3段です。

1段目：サイズとハッシュ値を比べる

いちばん確実なのは、手元の原本と、送る側に入ったファイルが完全に同じかを比べることです。サイズ（バイト数）が同じか。さらにハッシュ値（ファイルの中身から計算する指紋のような値。1バイトでも違えば別の値になる）が同じか。

9月13日の請求書では、下書きに付いた添付を取り出して原本と比べ、24,876バイトでサイズが一致、ハッシュ値も一致していることを確かめてから、送信を待つ状態にしました。

比べるだけなら、数行で済みます。

import hashlib, pathlib

def fingerprint(path):
    data = pathlib.Path(path).read_bytes()
    return len(data), hashlib.sha256(data).hexdigest()

print(fingerprint("原本.pdf"))
print(fingerprint("下書きから取り出したもの.pdf"))

2行の出力がまったく同じなら、同じファイルです。7月17日の3バイト欠けは、この「サイズを比べる」だけで見つかりました。

2段目：実際に開く

原本と比べられないとき（受け取ったファイルなど）は、開けるかどうかを確かめます。目で開くのが基本ですが、枚数が多いならプログラムで全ページを読み込ませ、エラーが出ないかを見る方法もあります。ファイル名やサイズを眺めるだけでは、今回の1バイト欠けは見抜けませんでした。

3段目：「下書きに付いている添付」を見る

最後の確認は、手元のPDFではなく、下書きに実際に付いているほうを開いて行います。送られるのはそちらだからです。

ここには落とし穴が2つありました。

1つ目。ブラウザ経由で付けた添付は、AIがコネクタで下書きを読み返しても「添付なし」と表示されました。付いていないのではなく、その読み方では見えないだけです。メールを丸ごとの形式で取り出してから中の添付を取り出し、比べる必要がありました。AIの「添付はありません」「添付しました」という報告を、そのまま信じないほうがよい、という教訓です。

2つ目。Gmailの下書きは、作った時点の添付を抱えたままです。あとから手元のPDFを作り直しても、下書きの添付は古いまま残ります。2026年8月24日、ある請求書で、下書きを作ったあとに社印の表示の不具合に気づいてPDFを作り直しました。下書き作成が10時01分、作り直しが10時18分、送信が10時20分。このときは私が送信の前に手で添付を差し替えたので事なきを得ましたが、そのまま押していれば古い版が飛んでいました。PDFを直したら、下書きの添付も必ず差し替える。 これも手順に入れています。

AIに書類の送付を任せるときのチェックリスト

最後に、私がAIに書類の送付準備をさせるときに見ている項目をまとめます。

• 添付やアップロードで、AIがファイルの中身（base64の文字列）を書き出す経路を使っていないか
• AIに渡しているのは、ファイルの場所や番号だけになっているか
• 送る前に、原本と送る側のファイルのサイズ・ハッシュ値を比べたか
• 下書きに付いているほうの添付を、実際に開いたか
• 下書きを作ったあとにPDFを作り直していないか。作り直したなら、添付を差し替えたか
• 同じ名前のファイルが複数の場所にあるとき、どれが原本かを言えるか
• 送信ボタンは人が押す流れになっているか

最後の1つは、技術ではなく運用の話です。私は、AIには下書きまでしか作らせず、送信は必ず自分で押しています。今回の開けない見積書が先方に届かなかったのは、この一線があったからでもあります。

なお、PDFをAIに「読ませる」側にも、似た種類の落とし穴があります。スキャンしたPDFをそのまま渡すと数字を読み違える条件については、スキャンPDFをAIに読ませると、数字が化ける条件に実測を書きました。

まとめ：AIは「考える」のは得意でも、「写す」のは道具に任せる

AIエージェントは、文章を考える、段取りを組む、表を整えるといった仕事はとてもよくこなします。一方で、意味のない文字の並びを一字一句そのまま運ぶという仕事は、仕組みの上で向いていません。そこは、ブラウザや同期アプリ、サーバー側のコピーといった、写すことが本業の道具に任せるのが正解でした。

そして、うまくいったように見えるときほど確かめる。下書きが出来ていて、添付のアイコンも付いていた。それでも中身は1バイト欠けていた。「出来ました」という報告と、「正しく出来ている」は別のことです。これはAIに限らず、人に仕事を頼むときも同じだと思います。

UMEO CREATEでは、御社に伺い、御社のパソコンにAIが働く環境を半日でつくる「AIエージェント導入支援」を行っています。お渡しするのは、今回の添付の手順も含め、私が自社で毎日使っている仕組みが元になったものです。

▼ AIエージェント導入支援について
https://www.umeocreate.com/agent.html

---

【群馬・北関東の中小企業・ひとり社長のAI導入をサポート】

UMEO CREATE（ウメオクリエイト）では、群馬県（高崎・前橋・太田・伊勢崎・吉岡町など）を中心に、中小企業や個人事業主・ひとり社長様向けの「AI導入・業務自動化・DX伴走コンサルティング」を行っています。

「自社の業務でもAIを使える？」「何から手をつければいいかわからない」「面倒な事務作業を自動化したい」といったご相談は、お気軽に公式LINEまたはWebサイトのお問い合わせフォームよりご連絡ください。