はじめに
こんにちは、安直思考な２年目エンジニアです。
今回は、Google Apps Script (GAS) を使って、Googleドライブに保存された画像や音声ファイルをウェブアプリケーションで扱おうとしていた時の失敗談を共有します。
最初は「IDでデータが特定できるんだから、そのIDをフロントエンドに渡して、ブラウザ側で直接ドライブから読み込めばいいじゃん！」と安直に考えていたのですが、現実は甘くなかったんです。
結論から言うと、「Base64」が全てを解決してくれました。
本記事では、実体験を交えながら、データの根源である 「バイナリコード」 の基本から、それをテキスト形式に変換する通訳者 「Base64」 の仕組み、そして「なぜBase64にしないとデータがうまく渡らないことがあるのか」ということについて、その解決策について、私なりの理解で解説していきます。
0と1の謎の羅列「バイナリコード」とは？
私たちが日々触れているデジタルデータ（画像、動画、音声、テキストなど）は、コンピュータの中では最終的に 「0」と「1」の羅列 で表現されています。これが、まさにコンピュータが話す唯一の言葉、 「バイナリコード」 です。
「なぜ動かない！？」直面したデータの壁とBase64との出会い
私はあるウェブアプリケーションで、Googleドライブに保存された画像や音声ファイルをフロントエンドに表示・再生する機能を作っていました。最初はこんな風に考えていました。
「GASのバックエンドでGoogleドライブから画像や音声のデータ本体を取得したんだから、そのデータをそのままの形式でフロントエンドに送れば、ブラウザで表示・再生できるでしょ！」
しかしそう現実は甘くありませんでした。
・画像も音声も表示、再生されない！
・フロントエンド側でデータ形式の認識エラーが発生！
そう、私が直面していたのは、 「テキストしか読めないHTTP通信やJSONというプロトコルに、バイナリデータをそのまま突っ込んでいた」 という、根本的な「言葉の壁」だったんです。
バイナリデータを救う通訳者「Base64」
HTTP通信やJSONなどは、基本的にテキストデータの送受信を前提に設計されています。画像や音声などのバイナリデータをそのまま送ると、プロトコルの制約や文字コードの問題で、データが破損したり、意図しない文字に変換されたりする悲劇が起こります。
ここで登場するのが 「Base64」 です。
Base64は、バイナリデータをテキストデータ（文字列）に変換するためのエンコーディング方式です。
Base64の変換の仕組み (超ざっくり)
元のバイナリデータを3バイトずつ区切り、それを6ビットずつの4つのグループに分割。各6ビットを、Base64の定義された64種類の文字（A-Z, a-z, 0-9, +, /）に変換します。
これにより、データは安全に伝送されますが、Base64に変換されたデータは元の 約1.33倍 のサイズに膨らむという特徴があります。
実践！ GASでGoogleドライブのファイルをBase64に変換する
私のトラブル解決に役立った、GASの具体的なコードを見てみましょう。
// Google Driveに保存されている画像をBase64形式のData URIに変換する処理
const fileId = 〇〇; // Google Drive上のファイルのID
const file = DriveApp.getFileById(fileId); // ファイルIDからファイルオブジェクトを取得
const blob = file.getBlob(); // ファイルの中身をバイナリデータ（Blob）として取得
const base64Data = Utilities.base64Encode(blob.getBytes()); // Blobのバイト列をBase64エンコード
imageDataUrls.push(`data:${blob.getContentType()};base64,${base64Data}`); // Data URI形式で配列に追加
このコードは、GASというバックエンドでGoogleドライブ上のバイナリデータ（画像や音声）を取得し、それをフロントエンドで利用できる テキスト形式（Base64のData URI) に変換する例です。
まとめ
「画像も音声も消えた！」という実体験から、Base64の重要性を学ぶことができました。
・ バイナリコード : コンピュータが扱う0と1のデータ形式。
・ Base64 : バイナリデータをテキスト形式に変換し、テキストベースの環境で安全にやり取りするための通訳者。データサイズは約1.33倍に。
・ なぜBase64が必要か : HTTP/JSONなどテキストベースの通信プロトコルでバイナリデータをそのまま送ろうとすると、破損や文字化けが起こるため。私の場合は、GASで取得したバイナリデータをそのままフロントエンドに渡そうとして失敗しました。
皆さんも、もし同じような壁にぶつかったら、Base64を思い出してみてください。
この記事が、これからChrome拡張機能開発に挑戦する方や、普段の業務でちょっと息抜きしたいエンジニアの皆さんの参考になれば幸いです。