LASSIC Media らしくメディア

シリアライズとは何か

プログラムが動作している間、扱っているデータはメモリ上でオブジェクトや構造体、配列といった形を取っています。このメモリ上の表現はプログラムの実行環境に強く依存しており、そのままの形でファイルに書き出したり、ネットワーク越しに別のシステムへ送ったりすることはできません。メモリ上のデータ構造を、保存や送信が可能な連続したバイト列やテキスト形式へ変換する処理がシリアライズ（直列化）です。反対に、受け取ったバイト列やテキストを解析して元のデータ構造に復元する処理がデシリアライズ（非直列化）にあたります。

API設計を担当する開発者、システム連携を検討するPM、外部委託を発注する立場の方にとって、シリアライズとデシリアライズはデータをやり取りするあらゆる場面の土台になる仕組みです。なお、文字を伝送用の符号へ変換するURLエンコードや、数値のバイト並び順を扱うエンディアンとは異なるテーマである点に触れておきます。本記事の主眼は、オブジェクトや構造体といったデータ構造そのものを、保存・転送できる形式へ変換する処理を整理することにあります。

荷物を旅行かばんに詰めて運び、目的地で荷ほどきする動きに近い例え方もできます。かばんに詰める作業がシリアライズ、届いた先で中身を取り出して元通りに配置する作業がデシリアライズにあたるイメージです。プログラムの世界でも、メモリ上に散らばった値や参照関係を持つデータを、一列に並んだバイト列やテキストへいったんまとめてから運び、届いた先で元の構造に組み立て直すという流れは共通しています。

なぜシリアライズが必要なのか

メモリ上のデータをそのまま扱えないという制約は、次のような場面で顕在化します。

• データの永続化：プログラムを終了してもデータを残すには、ファイルやデータベースへ書き込む必要があります。メモリ上のオブジェクトはそのままでは保存できないため、シリアライズしてディスクへ書き出すことになります。
• プロセス間・システム間のデータ受け渡し：API通信やメッセージキューを介して別のプロセス、別のサーバーへデータを渡す際は、送信側でシリアライズし、受信側でデシリアライズして元の構造に戻す流れが一般的です。
• キャッシュ：計算結果やセッション情報をRedisなどのキャッシュストアに置く場合も、シリアライズされた形式で格納されるケースがほとんどです。

共通しているのは、メモリ上の形式のままでは「他所へ運べない」という制約です。運べる形へ変換し、届いた先で元の構造に戻す。この往復がシステム連携の基本動作といえるでしょう。

具体的な場面を挙げると、Webアプリケーションでログイン中のユーザー情報をセッションストアに置く、バッチ処理の途中結果を一時ファイルに書き出して次の工程に引き継ぐ、マイクロサービス間で注文データをやり取りする、といったケースが該当します。いずれもデータの受け渡し先がプログラムの外側にあるため、メモリ上の形式のままでは完結しないものです。設計段階でどの形式に変換して受け渡すかを決めておくことが、後工程での手戻りを避けることにつながります。

代表的なシリアライズ形式

シリアライズ形式は大きくテキスト系とバイナリ系に分かれます。

テキスト系の代表はJSON・XML・YAMLです。文字として人が読める形式であり、異なる言語やプラットフォーム間での相互運用性が高いことから、Web APIのレスポンス形式として広く使われています。設定ファイルやログにも向いています。

バイナリ系の代表はProtocol Buffers・MessagePack・Apache Avroなどです。データをコンパクトなバイト列に詰め込むため、テキスト系と比べてサイズが小さく、パースの処理も高速になりやすいのが特徴になります。一方で人が中身をそのまま読むことは難しく、スキーマ定義ファイルなど専用の仕組みを併用するのが一般的です。

例えば「氏名が佐藤、年齢が32の人物」というデータをテキスト系形式で表すと、JSONでは次のようになります。

{"name": "佐藤", "age": 32}

XMLで表すと次のようになります。

<person><name>佐藤</name><age>32</age></person>

同じデータでも形式によって見た目は大きく異なりますが、いずれも目視で内容を確認できる点は共通しています。これに対してProtocol Buffersのようなバイナリ系形式では、事前に用意したスキーマ定義（.protoファイルなど）に沿ってフィールドを番号で管理し、値を詰め込んだバイト列として表現するものです。人が読める形ではありませんが、同じデータでもファイルサイズは小さくなる傾向があり、フィールド名の文字列を毎回含めないぶん通信量を抑えやすくなります。

両者の違いを整理すると次のとおりです。

注意点

シリアライズ・デシリアライズを実装や設計に取り入れる際は、次の点に注意が必要です。

• 言語独自のバイナリシリアライズのリスク：Javaの標準シリアライズやPythonのpickleのように、プログラミング言語自体が提供するオブジェクト直列化の仕組みは手軽である一方、信頼できない送信元のデータをそのままデシリアライズすると、想定していないコードの実行など深刻なリスクにつながり得ます。外部から受け取るデータについては、入力元の検証や許可リストの利用など、慎重な取り扱いが求められます。
• スキーマ変更時の互換性：運用中にデータ構造へ項目を追加・削除すると、古いバージョンでシリアライズされたデータを新しいバージョンでデシリアライズできなくなる、あるいはその逆が起こることがあります。フィールドの追加は後方互換を保ちやすい一方、削除や型変更は影響範囲を事前に洗い出しておく必要があるでしょう。
• 文字コード・数値精度・日時の扱い：テキスト系形式では文字コードの不一致が文字化けの原因になりますし、JSONの数値は言語によって精度の扱いが異なるため大きな整数が丸められることもあります。日時についてもタイムゾーンや書式の違いを送受信側で揃えておくことが望ましいところです。

これらはいずれも、実装が完了してから気づくと修正コストが大きくなりやすい部分です。設計段階でシリアライズ対象のデータ範囲や、想定する送信元・送信先を洗い出しておくと、後になって想定外の入力に対応する手戻りを減らしやすくなります。特にスキーマのバージョン管理は、複数のサービスが同じデータ形式を参照する構成では影響範囲が広がりやすいため、変更履歴を残しながら段階的に移行する進め方が現実的でしょう。

実務での関わり

実際のシステム開発では、シリアライズ形式の選定が設計の初期段階で意思決定事項になります。

• 社外・社内を問わずAPI設計を行う場合、JSONを採用するケースが標準的です。人が読めるためデバッグやドキュメント化がしやすく、フロントエンドやモバイルアプリなど幅広いクライアントとの相性も良好です。
• 大量データのバッチ処理や、低遅延が求められるマイクロサービス間通信では、Protocol Buffersなどのバイナリ形式が選ばれることがあります。通信量やCPU負荷を抑えたい場面で検討に値する選択肢です。
• 設計レビューの観点としては、形式選定がシステムの要件（可読性・性能・相互運用性）に見合っているか、信頼できない入力のデシリアライズを避ける実装になっているか、将来のスキーマ変更を見据えた互換性の設計になっているか、といった点を確認しておくと手戻りを減らしやすくなります。

発注者の立場であっても、こうした観点をあらかじめ押さえておくと、開発ベンダーとの仕様調整がスムーズに進みやすくなるでしょう。

実際のプロジェクトでは、外部向けの公開APIはJSON、社内のマイクロサービス間通信はgRPC（Protocol Buffersを利用する通信方式）といったように、公開範囲や利用者の技術水準に応じて形式を使い分ける構成もよく見られます。要件定義の段階で「誰が」「どのような頻度で」「どの程度のデータ量を」やり取りするのかを整理しておくと、形式選定の判断材料が明確になります。また、既存システムを改修する場合は、現行のシリアライズ形式を変更すると連携先すべてに影響が及ぶため、移行時には新旧両方の形式を一定期間並行運用するなど、段階的な切り替え計画を立てておくと現場の混乱を抑えやすくなるでしょう。

まとめ

シリアライズは、メモリ上のオブジェクトや構造体を保存・送信できる形式へ変換する処理であり、デシリアライズはその逆で元の構造に復元する処理です。データの永続化やシステム間連携、キャッシュといった場面で欠かせない仕組みといえます。形式にはJSON・XML・YAMLなどのテキスト系と、Protocol Buffers・MessagePackなどのバイナリ系があり、可読性・性能・相互運用性のバランスを見て選定します。信頼できない入力のデシリアライズやスキーマ変更時の互換性には注意を払う必要があるでしょう。API設計や大量データ処理を伴うプロジェクトでは、こうした基礎を踏まえた形式選定がシステムの安定運用につながっていきます。

新規開発の場面ではJSONなどのテキスト系形式から検討を始め、性能要件やデータ量が明確になった段階でバイナリ系への切り替えを検討する、という進め方も選択肢の一つです。形式そのものは技術的な話題に見えますが、実際にはAPIの公開範囲、連携先の技術水準、将来のデータ量の見通しといった事業側の要件と密接に結びついています。開発を依頼する立場であっても、この基礎を把握しておくことで、仕様検討の場での意思疎通がしやすくなるでしょう。

相談するメリット

API設計やシステム間のデータ連携では、シリアライズ形式の選定に加えて、スキーマ変更時の互換性やセキュリティを踏まえた実装が求められます。どの形式が要件に合うか判断がつきにくい、既存システムとの連携部分を見直したいといったご相談は決して珍しくないものです。LASSICではニアショア開発体制を活かし、API・データ連携基盤の設計から実装までを受託でご支援しています。形式選定の妥当性確認や、信頼できない入力を扱う際の実装レビューなど、部分的なご相談にも対応可能です。

すでに稼働しているシステムの連携部分を見直す場合、現行のデータ形式を維持したまま段階的に手を加えるのか、新しい形式へ移行するのかによって作業範囲が変わります。既存の仕様書やコードが整っていない状態からのご相談でも、現状のヒアリングを起点に、優先度の高い箇所から一緒に整理していくことが可能です。設計フェーズだけの部分的な依頼から、実装・テストまでを含めた一括の受託まで、プロジェクトの状況に合わせてご相談いただけます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

データ連携の設計・実装はLASSICにご相談ください

API設計やシステム間のデータ連携基盤の構築でお悩みの際は、要件整理から実装、レビューまでLASSICにご相談ください。ニアショア体制による柔軟な開発体制で、貴社のシステム連携をご支援いたします。

出典

• シリアライズ – Wikipedia
• Serialization（シリアライズ）- MDN Web Docs 用語集
• JSON – JavaScript | MDN

Tweet