「データ指向」で検索すると、ゲームエンジンのメモリ配置を論じる技術ブログ、開発者向けの翔泳社の書籍、分散システムを扱うオライリーの660ページの本が、同じ検索結果に並びます。言葉は同じでも、解こうとしている問題は別物です。CPUキャッシュの話を読み込んでも、分散データベースのレプリケーション設計の判断材料にはなりません。この記事では、データ指向設計（DOD）・データ指向プログラミング（DOP）・データ指向アプリケーション（data-intensive）の3つを出自から切り分け、オブジェクト指向との関係と、目的別にどれへ進むべきかを整理します。
まとめ：データ指向という語は3つの別々の技術を指す
| 呼び方 | 英語 | 主な現場 | 中心にある問題 | 代表文献 |
|---|---|---|---|---|
| データ指向設計（DOD） | Data-Oriented Design | ゲーム・組込み | CPUキャッシュとメモリ帯域 | Acton, CppCon 2014 |
| データ指向プログラミング（DOP） | Data-Oriented Programming | フロント・バックエンド開発 | コードとデータの分離・不変性 | 翔泳社 2023／Goetz 2022 |
| データ指向アプリケーション | Data-Intensive Applications | Web・データ基盤 | 信頼性・拡張性・保守性 | オライリー 2019 |
迷ったときの判断はこうなります。フレームレートやバッチの処理時間を縮めたいならDOD。Java・C#・Pythonで書かれたロジックが状態管理で壊れているならDOP。ユーザー数やデータ量の増加でデータベースが持たなくなってきたなら、データ指向アプリケーション、つまり分散システム設計の領域。3つは対立する流派ではなく、扱うレイヤーが違うだけです。なおDOPには、後述するようにSharvit本の流儀とJavaの流儀という2つの系統があります。以下、それぞれの出自と、混同したときに何を間違えるのかを見ていきます。
データ指向設計（DOD）：メモリ配置とキャッシュ効率の設計
1万倍と10倍：CPUとメモリの性能差という出発点
DODはゲーム開発の現場から広まった設計手法です。この名前を世に広げたのは、Insomniac GamesのMike Actonが CppCon 2014 の第3キーノートで行った講演「Data-Oriented Design and C++」で、コンソールゲーム開発という性能が要求される領域を題材に、C++でよく使われる書き方がその目的と相反すると論じました。
日本語で読める実測付きの解説としては、Cygames Engineers’ Blogの「データ指向設計」（2016年）があります。同記事は前提をこう説明しています。「この30年でCPUの性能は1万倍以上になりましたが、メモリの転送速度は10倍にもなっていません。そのため、プログラムのボトルネックはメモリ帯域となることが多くなりました」。ゲーム業界でこの考え方が広まった背景としては、PlayStation3がCellプロセッサを搭載していたことを大きな要因の一つに挙げています。
つまりDODが最適化の対象にしているのは、アルゴリズムの計算量ではありません。同記事の定義を借りれば、「データ指向設計では、そのデータをどのようにメモリに配置し、どのように読み込み、どのように書きだすのかに着目して設計を行います」。命令をいくら減らしても、メモリからデータが届かなければCPUは待つだけ。ここが出発点になります。
オブジェクト単位から配列単位へのデータ配置換え
具体的には、1つのオブジェクトに関連データをまとめる配置（AoS：Array of Structures）から、同じ種類のデータを配列としてまとめる配置（SoA：Structure of Arrays）へ組み替えます。次はその違いを示すC言語の宣言です。
typedef struct { float x, y, z; float hp; char name[32]; } EntityAoS;
EntityAoS aos[1024];
typedef struct {
float x[1024], y[1024], z[1024];
float hp[1024];
} EntitySoA;
EntitySoA soa;手元のclang（-O2）でsizeofを取ると、EntityAoSの配列は49,152バイト、1体あたり48バイト。ところが全エンティティの座標を更新するループが実際に触るのは先頭のx・y・zの12バイトだけで、残る36バイトはキャッシュラインを埋めるだけの積荷になります。SoA側なら、x配列を連続して読み込めるわけです。Cygamesの記事は、敵の位置更新処理をデータ指向設計へ組み替えた計測（Intel Core i-7 3820K 3.3GHz／Visual Studio 2015 の /Ox でコンパイル）で、オブジェクト指向設計と比べて3倍程度高速に動作したと報告しています。
この手法が効くのは、同じ処理を大量の要素へ一括で適用する場面に限られます。要素が数十個のUI部品にSoAを持ち込んでも、コードが読みにくくなるだけでしょう。
データ指向プログラミング（DOP）：コードとデータを分離する設計原則
対象読者はJava・C#・Python経験2年以上のフロント／バックエンド開発者
DODと名前は似ていますが、DOPはメモリ配置の話をしません。Yehonathan Sharvit著『データ指向プログラミング ソフトウェアがもつ複雑さの軽減に向けて』（クイープ訳、翔泳社、2023年4月19日発売、480ページ、定価3,960円・本体3,600円＋税10%）が示すのは、ソフトウェアの複雑さを減らすための設計原則です。翔泳社は同書を「Java、C#、C++、Ruby、Pythonなどの高級プログラミング言語で2年以上の経験を持つ、フロントエンド、バックエンド、フルスタック開発者向けの本です」と紹介し、オブジェクト指向の開発者は「慣れ親しんだ環境や世界観をいったん捨て去るように指示されるかもしれません」と断っています。
構成もその順で組まれています。第2章がコードとデータの分離、第4章が状態管理、第7章と第12章がデータ検証、第9章が永続的なデータ構造。巻末の付録Aに「データ指向プログラミングの原則」がまとまっています。データをクラスの内側に隠さず、汎用的なデータ構造として外に出し、書き換えではなく新しい値の生成で状態を進める。これがDOPの骨格です。
Java 21のrecord・sealed型によるDOPとSharvit本の違い
DOPという語は、Javaの世界でも別系統で使われています。Java言語アーキテクトのBrian Goetzが2022年6月20日にInfoQへ寄稿した「Data Oriented Programming in Java」がその起点で、原則を “Model the data, the whole data, and nothing but the data” “Data is immutable” と表現しました。
Sharvit本との違いは、データの表現手段にあります。Sharvit流は汎用の不変データ構造（マップなど）にデータを持たせ、汎用の関数で操作する形。Java流はrecordでデータを、sealed型で選択肢を表し、両者の組み合わせで代数的データ型を作ったうえで、パターンマッチによって振る舞いを足します。この3つの言語機能が正式機能になったのは、OpenJDKのJEPによればrecordがJava 16（JEP 395）、sealed classesがJava 17（JEP 409）、switchのパターンマッチがJava 21（JEP 441）。Java 21で道具が出揃ったことが、この用法の広がりにつながりました。
どちらも「データと振る舞いを分ける」という方向は共通しています。分かれるのは、それを汎用データ構造でやるか静的な型でやるかという点。Javaで「データ指向」を調べているならGoetzの記事、言語を問わず原則から追いたいならSharvit本、という選び方になります。
DODとDOPを取り違えたときの実害
DODとDOPを同じものとして扱う解説は珍しくありませんが、著者のSharvit自身が両者を別のパラダイムとして整理しています。同氏はDODを「CPUキャッシュの効率的な利用に動機づけられたプログラム最適化のアプローチで、主にビデオゲーム開発で使われる」とし、DOPを「システムの複雑さを減らす」ことを目的に汎用の不変データ構造を扱うパラダイムだと説明しました。目的関数が違うわけです。
実務では、この違いが逆方向の指示になって表れます。DODは「データを連続した領域へ詰めて一括で舐めろ」と言い、DOPは「データを不変にして、書き換えるたびに新しい構造を作れ」と言う。永続的データ構造は木構造の共有によって効率を稼ぐ設計で、メモリ上の連続性を保証しません。DODの目的からすれば不利な配置になります。
したがって、保守性を上げたいチームがDODの記事を読んでSoAへの書き換えを始めても、複雑さは減りません。逆に、フレームレートが出ないゲームのループへ不変データ構造を持ち込めば、確保と破棄が増えて悪化します。名前が似ているだけの別の道具として扱ってください。
データ指向アプリケーション：信頼性・拡張性・保守性で測る分散システム
レプリケーションとシャーディングという2つの分散方法
3つ目の用法が、Martin Kleppmann『データ指向アプリケーションデザイン』の言う data-intensive application です。CPU時間ではなくデータの量・複雑さ・変化の速さが制約になるシステムを指し、副題のとおり信頼性・拡張性・保守性という3つの尺度で設計を評価します。
分散の手段は大きく2つ。同じデータの複製を複数ノードへ置くレプリケーションと、データを分割して別々のノードへ配るシャーディング（パーティショニング）です。前者はノード障害時の可用性と読み取り性能を、後者は単一ノードに収まらない容量と書き込み性能を稼ぎます。両者は排他ではありません。データを分割したうえで、各パーティションをさらに複製する組み合わせも取れます。負荷の増加に対してどこまで台数で対応できるかという観点は、スケーラブル（スケーラビリティ）の考え方として別記事にまとめました。
強い一貫性と結果整合性の選び分け
複製を持った瞬間に、どのノードを読んでも同じ値が返るのかという問題が生じます。全ノードの同意を待つ強い一貫性は、書き込みのたびにネットワーク往復とノード間の合意処理を挟むため、レイテンシと可用性が犠牲になる設計。一方の結果整合性は、伝播が終わるまでの間、古い値が読める状態を許容します。
ここは要件で決める場面です。残高や在庫の引き当てのように二重処理が損害へ直結する処理は強い一貫性側へ寄せ、閲覧数の集計やタイムラインの表示は結果整合性で構いません。システム全体を一律にどちらかへ倒す設計は、たいてい過剰か不足のどちらかになります。
CQRSとイベントソーシングによる読み書きの分離
読み取りと書き込みで求められる性質が違うなら、モデルごと分けるという選択肢が出てきます。それがCQRS（コマンドクエリ責務分離）。書き込み側は整合性を守る形に、読み取り側は画面に必要な形に、それぞれ別の構造を持たせる設計です。状態そのものではなく状態を変えた出来事の履歴を保存するイベントソーシングと組み合わせると、過去の任意時点の状態を再構築できます。Javaでこの構成を組む際の実装基盤にはAxon Frameworkがあります。
ただし、CQRSとイベントソーシングは読み取りモデルの遅延と運用コストを持ち込みます。単一のリレーショナルデータベースで足りているうちは採用しないほうが安全です。
オブジェクト指向の対義語として扱われる理由と、その限界
3つのデータ指向に共通する「結合を解く」という軸
「オブジェクト指向 対義語」「オブジェクト指向 反対」といった調べ方でデータ指向にたどり着く人がいます。誤解ではありません。3つの用法には、オブジェクト指向がまとめたものを解くという共通の方向があります。
オブジェクト指向は、データとそれを操作する手続きを1つのクラスへ束ね、外部からの直接アクセスを制限する考え方。これはカプセル化として整理されています。DODはこの束ねられたデータをメモリ上で分解し、DOPはコードとデータを別の場所へ置き、データ指向アプリケーションはドメインモデルとストレージ表現を切り離す。対象のレイヤーは違っても、束ねる方向の逆へ進むという点が共通しています。
データ指向を採用すべきでない場面
とはいえ、対義語という理解を設計判断へそのまま持ち込むのは行き過ぎです。3つとも、オブジェクト指向を置き換える汎用の代替ではありません。
データ指向を採るべきでない典型は、業務ルールが複雑で、そのルール自体が仕様変更の主戦場になっているシステムです。この場合はデータを平坦に開くほど、不変条件をどこで守るのかが曖昧になります。ここはドメイン駆動設計（DDD）のようにモデル側へ責務を集める設計のほうが合うでしょう。データの量も同時実行数も小さく、単一プロセスで完結するアプリケーションも同様で、分散前提の議論を持ち込む理由がありません。判断の順序は、まず制約がどこにあるかを測ってからです。
書籍『データ指向アプリケーションデザイン』の書誌・電子版・原書第2版
日本語版の書誌情報と電子版の形式
日本語版は『データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理』（Martin Kleppmann著、斉藤太郎監訳、玉川竜司訳、オライリー・ジャパン、2019年7月18日発行、660ページ、5,060円・税込、ISBN 978-4-87311-870-3）です。原書は Designing Data-Intensive Applications で、この英語書名から日本語版を探している場合、対応するのはこの1冊になります。
電子版はオライリー・ジャパンの書籍ページでEbookとして販売されており、形式はPDFとEPUB、価格は紙と同じ5,060円（税込）です。無償のPDFが正規に配布されているわけではないため、無料配布をうたうファイルには手を出さないでください。
原書第2版（2026年3月・Riccomini共著）との差
原書は2026年3月に第2版が出ています。著者は Martin Kleppmann と Chris Riccomini の共著となり、初版の構成を土台にしつつ、新しい技術と動向を取り込んだ改訂。日本語版は上記のとおり初版の翻訳なので、初版刊行以降に一般化した技術まで追う必要があるなら、原書第2版を当たることになります。なお本書が「難しい」と言われる理由と読み進め方は、後述のよくある質問で触れます。
よくある質問
データ指向はオブジェクト指向の対義語ですか？
厳密な対義語ではありませんが、方向が逆であるという理解は妥当です。オブジェクト指向がデータと手続きを1つの単位へ束ねるのに対し、データ指向設計はメモリ上で、データ指向プログラミングはコードとの関係で、データ指向アプリケーションはモデルとストレージの関係で、それぞれ束ねられたものを分離します。ただし置き換え関係ではないため、どちらか一方を選ぶ二者択一として設計判断に使うことはおすすめしません。
データ指向設計とデータ指向プログラミングは同じものですか？
別物です。データ指向設計（Data-Oriented Design）はCPUキャッシュとメモリ帯域を対象とし、データを連続領域へ配置して一括処理する手法で、ゲームや組込みが主戦場になります。データ指向プログラミング（Data-Oriented Programming）はSharvit著の同名書が示す設計原則で、コードとデータの分離や永続的なデータ構造によってソフトウェアの複雑さを減らすことを狙います。Sharvit自身が両者を別のパラダイムとして区別しているので、出典がどちらの系統かを確認してください。
Javaのデータ指向プログラミングはSharvitの本と同じものですか？
目的は近いものの、手段が違います。Javaの用法はBrian GoetzがInfoQに寄稿した「Data Oriented Programming in Java」（2022年6月20日）が起点で、recordとsealed型で代数的データ型を組み、パターンマッチで振る舞いを足します。Sharvit本は言語機能ではなく汎用の不変データ構造を使うため、同じDOPという略称でも設計の見た目は別物です。土台となる機能はrecordがJava 16、sealed classesがJava 17、switchのパターンマッチがJava 21で正式機能になりました。
『データ指向アプリケーションデザイン』の日本語版とPDFはありますか？
日本語版はオライリー・ジャパン刊の1冊のみで、ISBNは978-4-87311-870-3です。電子版も同社の書籍ページでEbookとして販売されており、形式はPDFとEPUB。無償配布はされていないため、無料PDFをうたうファイルは避けてください。書誌の詳細は本文の該当章にまとめています。
データ指向アプリケーションデザインが難しいと言われるのはなぜですか？
660ページという分量で、ストレージエンジンの内部構造、レプリケーション、パーティショニング、トランザクション、一貫性と合意、バッチ処理とストリーム処理までを一続きに扱うためです。前提知識が足りない章で止まりやすい構成なので、最初から通読するより、担当システムで現に問題になっている章から読む進め方が現実的でしょう。
データ中心アプローチ（DOA）はこの記事のデータ指向と同じですか？
別系統の用語です。データ中心アプローチ（DOA、data oriented approach）は「日本で生まれたソフトウェア工学上の業務分析･業務設計手法の総称」で、プロセス指向アプローチ（POA）と対比されます。扱うのは業務データの構造と関数従属性であり、プログラムのメモリ配置やコード構造の設計ではありません。業務分析の文脈で出てきたならDOA、実装の文脈ならこの記事の3つ、と切り分けてください。
データ指向型組織（データドリブン）は、この記事のデータ指向と関係ありますか？
直接の関係はありません。データ指向型組織やデータドリブン経営は、意思決定を勘や慣習ではなくデータに基づいて行うという経営・組織運営の話で、システムの内部設計を指す用語ではないためです。同じ「データ指向」という訳語が当てられているだけなので、技術文書を探すときは英語表記（Data-Oriented Design／Data-Oriented Programming／Data-Intensive）を添えて検索すると混ざりません。
