Storia's Blog

PySparkとは？ PythonやSQLと何が違うのか実際に比較してみた

Sat, 29 Aug 2026 00:00:00 GMT

PySparkという名前は前から耳にしていたが、ぶっちゃけ最初は何者なのかよく分かっていなかった。

「PySpark」っていうくらいだし、Pythonを使って何かやるライブラリなのだろうとは思っていたが、

普通のPythonと何が違うんだろう？

という部分がイマイチピンときていなかった。

さらに調べていると、Spark SQLなんて言葉も登場。

SQLで集計できるなら、わざわざPySpark使わなくてもよくね？

という新たな疑問も浮上。

もう一つ気になったのが「大量データ処理」の文脈。なぜデカいデータを扱うときにPySparkがもてはやされるのか。

「Pythonより単に速いからなのかな？」とも思ったが、考えててもラチがあかないので、今回はWindowsのローカル環境でPySparkを動かしてPythonやSQLite + SQLと比較してみることにした。

PySparkの基本的な仕組みを調べつつ、同じデータをPython・SQL・PySparkで回してみて、実行計画や処理時間も確認してみる。

この記事の対象読者

PySparkという言葉を初めて聞いた人
PySparkと普通のPythonの違いがピンときていない人
SQLとPySparkの違いや使い分けが分からない人
Sparkが裏側で何をやっているのか知りたい人
ローカル環境でPySparkをちょっと試してみたい人

まず結論

今回調べて、実際に動かしてみて分かったことを先にまとめておく。

結論1：PySparkは「Pythonを高速化したやつ」ではない

PySparkは、Apache SparkのPython API。

つまり、Pythonそのものを爆速にするライブラリというより、PythonからSparkのデータ処理エンジンを操作するための入口と考えた方がしっくりくる。PySparkは公式でも「Python API for Apache Spark」と説明されていて、PyPIからサクッとインストールしてローカルで試すこともできる。

結論2：Spark SQLとPySparkは単純な別物ではない

PySparkからSpark SQLを普通に実行できる。

しかもSpark内部では、SQLで書こうがDataFrame APIで書こうが、最終的な計算にはまったく同じ実行エンジンが使われる仕組みになっている。

なので、

「SQLかPySparkか、どちらか一方を選ぶ」

みたいな単純な二者択一の関係ではないっぽい。

結論3：PySparkだからといって必ずPythonより速いわけではない

今回1,000万行のデータで検証してみたところ、読み込み後の集計処理だけを見れば local[5] のPySparkが一番速かった。

ただ、Sparkの起動時間やCSV読み込みまで含めたトータル実行時間だと、今回のローカル環境ではまさかのPython単体の方が速いという結果に。

つまり、

「PySparkを使えばPythonより絶対に速くなる」

とは一概には言えない。

「PySparkってPythonと何が違うの？」という素朴な疑問に対しては、速度というより処理を実行する仕組みそのものが根本的に違うと捉えるのが一番しっくりきた。

そもそもPySparkとは何者？

基本的な定義

PySparkは、Apache SparkをPythonから操作するためのAPI。

Apache Spark自体は、大規模なデータを扱うための分散処理基盤。PySparkを使うことで、PythonからSparkのDataFrameやSQL機能を扱えるようになる。

イメージ的にはこんな感じ。

Python
   ↓
PySpark
   ↓
Apache Spark
   ↓
データ処理

ここが最初に少し混乱したポイントだった。

「PySpark」という名前から、最初は「Python製の高速データ処理ライブラリ」みたいなイメージを持っていたが、実際はPythonからSparkという別物を動かすための窓口と考える方がしっくりくる。

Sparkの内部はどうなってるの？

ここで「じゃあそもそもSparkって中で何やってるの？」という話。

Sparkアプリケーションは、主に Driver と Executor というプロセス群で動いている。

公式ドキュメントによると、Driverが SparkContext を保持して全体を指揮し、Executorが実際にタスクを実行してデータをメモリ上に保持する構成になっている。Driverから各ExecutorへTaskが配られるイメージ。

構成を図にするとこんな感じ。

flowchart TB
    App["Sparkアプリケーション"]
    Driver["Driver (SparkContext)"]

    Executor1["Executor 1"]
    Executor2["Executor 2"]

    Task1["Task 1"]
    Task2["Task 2"]

    Data1["Data 1"]
    Data2["Data 2"]

    App --> Driver

    Driver --> Executor1
    Driver --> Executor2

    Executor1 --> Task1
    Executor2 --> Task2

    Task1 --> Data1
    Task2 --> Data2

今回の検証は1台のWindows PC上でSparkを動かしている。なので本格的な複数台マシンによる分散処理ではない。とはいえ、Sparkの分散処理モデルの雰囲気をローカルで体感することは十分可能。

`local[1]` と `local[5]` って何？

Sparkをローカル環境で動かすとき、以下のような指定ができる。

local[1]
local[5]
local[*]

Spark公式での意味は以下の通り。

local[1] → 1つのワーカースレッドで動かす
local[K] → K個のワーカースレッドで動かす
local[*] → マシンの論理コア数いっぱいで動かす

今回の検証PCは20論理プロセッサ搭載だが、CPU負荷を考慮して local[1] と local[5] の2パターンで試してみた（local[*] は今回は見送り）。

なぜにSparkの概念が必要になるのか？

ここが一番気になった部分。

単にデータを集計するだけなら、

CSV
 ↓
Python
 ↓
集計

で済むし、SQLを使うにしても、

CSV
 ↓
SQLite
 ↓
SQL
 ↓
集計

で十分なはず。

じゃあ、なんでわざわざSparkなんて大掛かりなものが必要になるのか？

Spark公式のクラスタ概要を見ると、DriverがTaskを分散し、複数のExecutorで並列処理する前提で作られている。つまり最初から「1つのPythonプロセスで全データを順番に処理する」という世界観ではない。

なのでSparkの本当の価値は、

Pythonコードを単に高速化すること

というより、

超巨大なデータを複数のブロックに分解して並列実行できる仕組み

にあると考える方が自然っぽい。

ただし、このあたりの恩恵は1台のPCのローカル検証だけだと全貌は見えにくいかもしれない。

PySparkのDataFrameって普通のリストやPandasと違うの？

PySparkでは、データをDataFrameという単位で扱う。

コードの書き方自体はこんな感じ。

result = (
    df.withColumn(
        "total_sales",
        col("price") * col("quantity")
    )
    .groupBy("category")
    .agg(
        spark_sum("total_sales").alias("total_sales")
    )
    .orderBy("category")
)

一見すると、普通のPythonオブジェクトをメソッドチェーンで操作しているように見える。

が、PySparkのDataFrameはPythonの普通のリストやDictとは別物。

Spark公式によると、DataFrameは構造化されたデータの「分散コレクション」として定義されている。さらにSpark SQLの最適化エンジン（Catalyst Optimizerなど）が働くことで、計算手順が最適化されてから実行される。

Pythonの for row in rows: みたいに1行ずつ真面目に処理していくのとは、根本的に仕組みが違う。

実際にPython・SQL・PySparkを比較してみた

というわけで、ここから実際に動かして比較してみる。

検証環境

項目	内容
OS	Windows 11
CPU	Intel Core Ultra 7 265K
論理プロセッサ	20
メモリ	約63.35GB
Python	3.13.15
Java	Temurin 21.0.12.1
PySpark	4.2.0
Spark	4.2.0
Spark実行方式	`local[1]` / `local[5]`
SQL	SQLite

※PySpark 4.2.0公式では Python 3.10+、Java 17+ が要件。今回は Python 3.13.15 と Java 21 を使用。

今回使用したデータ

検証用に、以下のようなシンプルな売上データ（CSV）を用意した。

id,product,category,price,quantity
1,Apple,A,100,3
2,Banana,B,200,2
3,Orange,A,150,4
4,Grape,C,300,1
5,Melon,B,500,2
...

ここから、

売上金額 = price × quantity

を計算し、category ごとに合計売上金額を集計する。

たとえば10行のダミーデータなら、期待する結果は以下。

category	total_sales
A	1700
B	2600
C	1770

検証1：Python単体で集計する

まずは一番素直なPython標準ライブラリでの処理。

with CSV_FILE.open(newline="", encoding="utf-8") as f:
    reader = csv.DictReader(f)

    for row in reader:
        category = row["category"]
        price = int(row["price"])
        quantity = int(row["quantity"])

        totals[category] += price * quantity

PythonがCSVを開き、1行ずつDictにしてループで集計していくスタイル。

CSV
 ↓
Python
 ↓
1行ずつル〜プ処理
 ↓
集計

出力結果は当然こうなる。

A 1700
B 2600
C 1770

検証2：SQLite + SQLで集計する

次はSQL。

Python組み込みの sqlite3 を使ってメモリ上（":memory:"）にテーブルを作って集計してみた。

SQL文は標準的なやつ。

SELECT
    category,
    SUM(price * quantity) AS total_sales
FROM sales
GROUP BY category
ORDER BY category

結果は当然同じ。

A 1700
B 2600
C 1770

Pythonのループ処理と比べると、コードの書き味はかなり変わる。

Pythonでの書き方

for row in reader:
    totals[category] += price * quantity

SQLでの書き方

SELECT
    category,
    SUM(price * quantity)
FROM sales
GROUP BY category

最初は「SQLとPySparkってライバル関係なのかな？」と思ってたが、ここで少し視点が変わってきた。

検証3：PySpark（DataFrame API）で集計する

PySparkでの書き方はこんな感じ。

result = (
    df.withColumn(
        "total_sales",
        col("price") * col("quantity")
    )
    .groupBy("category")
    .agg(
        spark_sum("total_sales").alias("total_sales")
    )
    .orderBy("category")
)

実行結果は勿論これ。

A 1700
B 2600
C 1770

結果自体は一緒だが、大事なのは「裏で何が起きているか」。

PythonはPythonのインタプリタが1行ずつ律儀に回しているが、PySparkの方は「こういう処理をしてね」というプランをSparkエンジン側に組み立ててから実行させている。

検証4：PySparkの中でSQLを使う

ここで「SQLじゃだめなの？」という疑問を深掘りしてみる。

実はPySparkでは、DataFrameを一時ビュー（TempView）として登録できる。

df.createOrReplaceTempView("sales")

登録しちゃえば、普通にSQLが書ける。

result = spark.sql("""
    SELECT
        category,
        SUM(price * quantity) AS total_sales
    FROM sales
    GROUP BY category
    ORDER BY category
""")

つまり構造としてはこう。

PySpark
 ├─ DataFrame API (メソッドチェーンで書く)
 │
 └─ Spark SQL (クエリ文字列で書く)

両方使える。

Spark公式ドキュメントでも「SQLとDataFrame APIは表現が違うだけで、裏側の計算エンジンは同一」と明言されている。

なので、

「SQLかPySparkか」

という比較ではなく、

「Sparkの上で、SQLとDataFrame APIのどっちの書き方で指示を出すか」

という話だったことが分かった。

検証5：実行計画を見てみる

せっかくなので、Sparkの裏側（実行計画）を覗いてみる。

PySparkには explain() メソッドがある。

result.explain(mode="formatted")

Spark SQLで書いた場合の実行計画を出してみると、こんな感じのフローになっていた。

Scan csv
 ↓
HashAggregate
 ↓
Exchange
 ↓
HashAggregate
 ↓
Exchange
 ↓
Sort
 ↓
AdaptiveSparkPlan

DataFrame APIで書いた場合もほぼ同じ。

Scan csv
 ↓
Project
 ↓
HashAggregate
 ↓
Exchange
 ↓
HashAggregate
 ↓
Exchange
 ↓
Sort
 ↓
AdaptiveSparkPlan

`Scan csv` って何？

CSVファイルを読み取っているステップ。category price quantity といった必要な列をスキャンしている。

`Project` って何？

DataFrame APIで指定した .withColumn("total_sales", col("price") * col("quantity")) の部分。 price * quantity の計算を行って total_sales という列を作るステップが Project として現れている。

SQL版だと SUM(price * quantity) の中に直接書いたため独立した Project ノードとしては見えなかったっぽい。

`Exchange` って何？（ちょっと気になったポイント）

一番目についたのが Exchange。

詳細を見ると hashpartitioning(category, 200) みたいな記述がある。 GROUP BY category を処理するために、データをカテゴリごとにパーティション再配置（シャッフル）しているということ。

元のデータ
   ↓
categoryを基準にデータを再配置（Exchange）
   ↓
集計（HashAggregate）

単にファイルを上から読んで加算しているわけではなく、分散処理に適した形でデータを並び替えてから集計しているのが見て取れる。

性能も比較してみた

ここまでの仕組みを踏まえて、「で、実際に処理速度はどれくらい違うの？」を測ってみた。

※測定条件：

Windows 11 / 同一PC / 同一CSV / 同一集計処理
PySparkは local[1] と local[5]

注意点として、PythonとPySparkではメモリ構造も動作原理も違うため、あくまで「今回の条件での測定値メモ」として見てほしい。

1,000万行のデカいCSVで勝負

1,000万行のテスト用CSVを作成。 Python側はCSV読み込み完了後の「純粋な集計処理（5回測定）」のタイムを計測。

Python単体

測定値（秒）：

0.392956
0.389598
0.380789
0.408727
0.390020

平均：0.392418秒 / 中央値：0.390020秒

PySpark `local[1]` (スレッド数: 1)

ウォームアップ実行後、5回測定。

測定値（秒）：

0.602338
0.589854
0.591355
0.588073
0.573362

平均：0.588996秒 / 中央値：0.589854秒

PySpark `local[5]` (スレッド数: 5)

測定値（秒）：

0.294400
0.247066
0.238032
0.230247
0.231689

平均：0.248287秒 / 中央値：0.238032秒

性能結果を並べてみる

方法	平均	中央値
Python	0.392418秒	0.390020秒
PySpark `local[1]`	0.588996秒	0.589854秒
PySpark `local[5]`	0.248287秒	0.238032秒

中央値で比較すると、

PySpark local[5]  → 0.238秒 (最速)
Python            → 0.390秒
PySpark local[1]  → 0.590秒

マルチスレッドな local[5] にすると、Python単体より約1.64倍速くなった。一方でシングルスレッドの local[1] だと、オーバーヘッドのせいかPython単体より遅いという結果に。

ここからも、

「PySparkにすれば無条件でPythonより速くなる」

わけではなく、並列度を効かせることで初めて集計処理が速くなるということが良くわかる。

実行時間全体（トータルタイム）でも比較してみた

今度は「CSVの読み込み」や「Spark/JVMの起動コスト」も含めた全体の時間を測定してみた。

1,000万行データでの結果：

方法	実行時間
Python	7.065秒
PySpark `local[1]`	12.823秒
PySpark `local[5]`	8.443秒

まさかのPython単体が一番早いという結果に！

【集計処理だけ】
PySpark local[5] ＞ Python

【起動や読み込みも含めた全体】
Python ＞ PySpark local[5]

見事な逆転劇。

なぜこうなるかというと、PySparkは背景でJVM（Java仮想マシン）やSparkセッションを立ち上げる初期化コストがかかるため。

ローカルPCで中規模程度の処理を1回だけサクッと動かすようなケースだと、PySparkの初期化オーバーヘッドが響いてトータルではPython単体の方が早くなる、というオチ。

「PySpark＝単なるPythonの高速化ツール」という認識がいかにズレているかが実感できる面白い結果となった。

`local[1]` と `local[5]` の並列度の差

データ量によって並列度の差がどう出るかも実験してみた。

10万行

local[1]：約0.336秒
local[5]：約0.337秒 → データが小さいと差はほぼゼロ。

100万行

local[1]：約0.378秒
local[5]：約0.374秒 → まだ明確な差は出ない。

1,000万行

local[1]：0.590秒
local[5]：0.238秒 → ここで一気に差が開く、、、！

データ量が小さいうちはオーバーヘッドの方が大きく、1,000万行クラスになって初めてマルチスレッド（local[5]）の効果がはっきり現れるっぽい。

調べる前と後で考え方が変わった

調べる前

「PySparkってPythonで大量データを爆速処理するライブラリでしょ？」
「SQLで集計できるならPySparkなんて要らなくね？」

調べた後

PySparkはPythonを直接速くする魔法ではなく、Sparkエンジンを動かすためのAPI。
裏ではDriver / Executor / Task という分散実行モデルが動いている。
SQLかPySparkかの二者択一ではなく、Sparkの上で「SQL表記で書くかDataFrame表記で書くか」の違い。

イメージがガラッと変わった。

「Pythonじゃだめなの？」への回答

ローカルPCで小〜中規模のデータをサクッと集計するだけなら、普通にPython単体で十分なケースが多い。

実際、今回の1,000万行の全体処理時間はPython単体の方が速かった。

ただ、データ量が単一マシンのメモリを超えたり、分散クラスタ環境で処理したい場合には、Python単体だと限界が来る。その時にSparkの分散実行モデルをPythonから使えるのがPySparkの強み。

「Pythonより必ず速いから使う」というより、「Sparkの分散実行モデルを使いたいから、書きやすいPythonからPySpark経由で触る」 というのが正しい捉え方っぽい。

「SQLじゃだめなの？」への回答

SQLでも全然OK。今回SQLiteでも同じ集計ができた。

しかもSpark内部にもSpark SQLがある。

なので「SQLだと対応できないからPySparkを使う」というわけではない。

Spark
 ├─ Spark SQL（SQLで記述）
 └─ DataFrame API（Python等のコードで記述）

どっちで書いても裏の計算エンジンは同じなので、チームの好みや処理の複雑さ（前処理のループや条件分岐が多いならDataFrame API、単純集計ならSQLなど）で選べばOK。

注意点・今回分からなかったこと

1台のローカルPCでの検証に過ぎない Spark本来の強みである複数台ノードでの分散環境では試していない。
動作環境依存 Windows 11, Core Ultra 7 265K, メモリ64GBでの検証結果なので、環境が変われば数値も変わる。
Windows環境での警告 winutils.exe や native-hadoop が無いという警告が出たが、今回のCSV処理自体は正常終了した。実運用環境では要確認。

まとめ

PySparkはPythonを高速化するライブラリではなく、Apache SparkをPythonから操作するAPI。
裏では実行計画が組み立てられ、データが再配置（Exchange）されたりTaskに分割されて動く。
SQLとPySpark（DataFrame API）は競合ではなく、同じSparkエンジン上の表現違い。
ローカル環境＆1,000万行程度だとトータル処理時間はPython単体の方が速いこともある。
大量データや分散処理の仕組みが必要になって初めてPySpark（Spark）の真価が発揮される。

「PySpark＝Pythonの高速版」と思って触ると「あれ、意外と遅くね？」と困惑するが、実行モデルや裏側の仕組みを理解すると使いどころが見えてくる、という話だった。

今後調べたいこと

今回の検証で、逆に新しい疑問も出てきた。

特に気になったのが、

Partition
Task
Stage
Exchange
Shuffle
Driver
Executor

の関係。

今回 explain() を見ることで、Sparkが単純なPythonのループ処理ではないことは分かった。

ただ、

「実際にデータがどのように分割され、Taskとして処理されているのか？」

までは、まだ十分に理解できていない。

また、今回はローカルPCの local[1] / local[5] までしか試していないため、

複数ノードのSparkクラスタになると何が変わるのか？

も気になっている。

このあたりは、今回の記事とは分けて書かないとごちゃごちゃになっちゃいそうなので、別記事で。。。

参考資料

今回使用したGithubコード群 ::github{repo="ryo50/pyspark-blog-test"}

Apache Spark 4.2.0 PySpark Installation PySparkのPython対応バージョン、PyPIからのインストール、Java要件など。
Apache Spark 4.2.0 Spark SQL, DataFrames and Datasets Guide Spark SQL、DataFrame API、同一実行エンジンについて。
Apache Spark 4.2.0 Cluster Mode Overview Driver、Executor、Task、Stageなどの構成について。
Apache Spark 4.2.0 Submitting Applications local[K]、local[*]、spark-submitなどについて。
PySpark 4.2.0 DataFrame.explain() 実行計画の確認方法について。
Python 3.13 sqlite3 documentation SQLiteとPython標準のsqlite3について。

※今回の記事の検証結果は、2026年8月29日時点の環境で実施したもの。 PySparkやJava、Pythonのバージョン、Sparkの仕様は今後変更される可能性があるため、記事公開時には公式ドキュメントも再確認してね。

スイムレーン図とは？フローチャートやシーケンス図との違いを調べてみた

Wed, 26 Aug 2026 00:00:00 GMT

はじめに

ユーザーの操作からWeb画面、バックエンドの認証APIまでが絡むログイン機能の設計書を作っているときに、処理の流れを図にする必要があった。

そのとき、自分はシーケンス図を書こうとしていたのだが、チームの先輩から、

「この内容なら、スイムレーン図の方が合っているかもしれない」

と指摘を受けた。

スイムレーン図という名前自体は聞いたことがあったが、改めて考えてみると、正直よく分かっていなかった。

特に気になったのが、

普通のフローチャートと何が違うのか
シーケンス図とは何が違うのか
UMLの図なのか
どんな場面で使うのか
人とシステムを同じ図に書いてよいのか
APIやDBをレーンにしてもよいのか

という点。

そこで今回は、スイムレーン図について調べつつ、同じ「ログイン処理」を題材にして、

フローチャート
スイムレーン図
シーケンス図

の3種類をMermaidで実際に作って比較してみる。

単に「スイムレーン図とは何か」を調べるだけではなく、

結局、どんなときにどの図を使えばいいのか？

まで整理することを今回のゴールにする。

この記事の対象読者

この記事は、以下のような人を対象にしている。

スイムレーン図という言葉を初めて知った人
フローチャートとの違いが分からない人
シーケンス図との違いが分からない人
UMLとスイムレーン図の関係を知りたい人
要件定義や設計で、どの図を使えばよいか迷っている人
Mermaidで設計図を作ってみたい人

まず結論

今回調べてみた結果、自分としては次のように整理した。

図	主に表現したいもの
フローチャート	処理や判断がどのように進むか
スイムレーン図	処理の流れと、その処理を誰・何が担当するか
シーケンス図	要素同士がどの順番でやり取りするか

つまり、

どの図が優れているかではなく、「何を伝えたいか」で使い分けが大事

というのが今回の結論。

例えばログイン処理なら、

「ログイン処理にどんな分岐があるのか」を確認したいならフローチャート。

「ユーザー、Web、認証APIなどが、それぞれ何を担当するのか」を確認したいならスイムレーン図。

「Webから認証API、認証APIからDBというように、誰が誰にどの順番で処理を要求するのか」を確認したいならシーケンス図。

という感じで使い分けられる。

スイムレーン図とは？

基本的な定義

スイムレーン図は、処理の流れを表現すると同時に、その処理を誰・何が担当するのかを区切って表現する図のこと。

「スイムレーン」という名前の通り、図を複数のレーンに分け、それぞれのレーンに担当する処理を配置する。

例えば、

┌──────────┬──────────┬──────────┐
│ ユーザー │ Web画面  │ 認証API   │
├──────────┼──────────┼──────────┤
│          │          │          │
│ 入力     │          │          │
│          │ 認証要求 │          │
│          │          │ 認証     │
│          │ 結果表示 │          │
└──────────┴──────────┴──────────┘

のような形。

通常のフローチャートに「誰が担当するのか」という情報を追加したもの、と考えると最初は理解しやすいと思う。

「スイムレーン」という名前の意味

スイムレーンを英語にすると「泳ぐレーン」の意味になる。

プールのコースを複数のレーンに分けるように、処理を担当者やシステムなどの単位で区切る。

例えば、

ユーザー
────────────
Web
────────────
認証API
────────────
DB

という形で区切り、それぞれの場所に処理を配置していく。

見た目がそのまますぎるが、この形状から「Swimlane」という名前が使われている。

UMLとの関係

ここは少し注意が必要だった。

最初は、

「スイムレーン図というUMLの独立した図がある」

くらいに考えていた。

しかし、UMLではActivity Partitionという要素が定義されている。

Activity Partitionを利用すると、アクティビティ図の中で処理を担当する要素などを区切って表現できる仕組みになっている。

そのため、

「スイムレーン図＝UMLの独立した図」

と単純に考えるより、

UMLのアクティビティ図では、Activity Partitionを利用してスイムレーン形式で表現できる

と理解した方が正確っぽい。

UMLの仕様については、OMGがUML 2.5.1を公開している。

OMG — UML Specification

フローチャートじゃだめなの？

フローチャートは、基本的に処理や判断の流れを表現するための図。

例えばログイン処理なら、

flowchart TD
    Start([開始]) --> Input[ID・パスワードを入力]
    Input --> Auth[認証]
    Auth --> Check{認証成功？}
    Check -->|Yes| Success[ログイン成功]
    Check -->|No| Error[エラー表示]

この図からは、

「ログイン処理がどのように進み、どこで分岐するのか」

がはっきり分かる。

一方で、

「この処理は誰が担当しているのか」

までは、この図だけだと見えてこない。

そこで「誰がやるか」を可視化するためにスイムレーン図を使う形になる。

実際にスイムレーン図を作ってみる

検証目的

今回の検証では、同じログイン処理をスイムレーン図にして、

フローチャートと比べて何が分かりやすくなるのか？

を確認してみる。

検証環境

項目	内容
作図ツール	Mermaid
題材	ログイン処理
比較対象	フローチャート、スイムレーン図、シーケンス図
実行環境	Mermaid対応環境

Mermaidのバージョンについては、スイムレーン構文の対応状況が変わる可能性があるため、実際に記事へ掲載する際には使用したバージョンを記録しておく。

スイムレーン図

Mermaidでは、スイムレーンを使って担当単位を分けることができる。

swimlane-beta LR
 subgraph User["ユーザー"]
        Input["ログイン情報を入力"]
        Complete["ログイン結果を確認"]
    end

    subgraph Web["Web画面"]
        Request["認証要求"]
        Result["認証結果を表示"]
    end

    subgraph Auth["認証API"]
        Authenticate["ユーザー認証"]
    end

    Input --> Request
    Request --> Authenticate
    Authenticate --> Result
    Result --> Complete

この図では、

ユーザー
Web画面
認証API

というレーンを用意している。

同じログイン処理でも、フローチャートとは違って、

「どの処理を誰・何が担当しているのか」

が一目で分かりやすくなる。

スイムレーン図で分かったこと

実際に同じログイン処理をスイムレーンにしてみると、

処理の流れそのものが大きく変わったわけではない

ということが分かった。

変わったのは、処理に「担当」という視点が加わったこと。

例えば、

ユーザー → ログイン情報入力
Web      → 認証要求
認証API  → 認証処理
Web      → 結果表示

という関係が見えるようになる。

そのため、

「普通のフローチャートだとダメ」

ということではない。

確認したい情報が違うだけということが分かった。

レーンにAPIやDBを置くのはだめなの？

ここも気になったので確認してみた。

結論としては、

人間（ユーザー）とシステム（Web画面・API・DB）を1つのスイムレーン図に混在させて書いても全く問題ない

し、レーンを人間で分けるかシステムで分けるのも自由だと分かった。

例えば、ユーザーとWeb画面、認証APIを並べれば、「人間の操作からシステムのどのコンポーネントへ処理が引き継がれるか」という境目が非常にクリアに見えるようになる。

また、システムの処理だけを細かく説明したいなら、

ユーザー
Web
認証API
DB

という区切り方が考えられるし、

一方、業務フローを説明するのであれば、

顧客
営業
経理

のような人間の組織単位での区切り方が考えられる。

つまり、

「レーンには必ず人間だけ（あるいはシステムだけ）を書かないとダメ」

というルールはない。

重要なのは、

この図では、何を単位として処理を分けると理解しやすいのか？

という点。

シーケンス図じゃだめなの？

次に、最初に作ろうとしていたシーケンス図と比較してみる。

シーケンス図では、登場する要素と、それらの間で発生するメッセージの順序を表現できる。

同じログイン処理をMermaidで表現すると、

sequenceDiagram
    actor User as ユーザー
    participant Web as Web画面
    participant Auth as 認証API
    participant DB as DB

    User->>Web: ログイン情報を入力
    Web->>Auth: 認証要求
    Auth->>DB: ユーザー情報を検索
    DB-->>Auth: ユーザー情報
    Auth-->>Web: 認証結果
    Web-->>User: ログイン結果

となる。

こちらでは、

ユーザー → Web → 認証API → DB

というやり取りの順番やリクエスト・レスポンスの往復が分かりやすくなっている。

同じログイン処理を3種類で比較してみる

ここまでの結果を整理してみる。

観点	フローチャート	スイムレーン図	シーケンス図
処理の流れ	◎	◎	○
分岐	◎	◎	○
担当者・担当システム	△	◎	○
時系列	○	○	◎
システム間のやり取り	△	○	◎
業務の全体像	◎	◎	△
APIなどの詳細な連携	△	○	◎

この表からも分かるように、単純に「スイムレーン図がフローチャートより優れている」という話ではない。

それぞれ得意・不得意がある。

どの図を使えばいいのか問題

今回の記事で一番整理したかった部分。

自分は次のように考えると選びやすいと思った。

「処理がどう進むのか」を知りたい

まずフローチャートを検討する。

処理A
 ↓
処理B
 ↓
判断
 ├→ 処理C
 └→ 処理D

処理の流れや分岐を確認することが目的なら、シンプルなフローチャートで十分な場合が多い。

「誰・何が担当するのか」も知りたい

スイムレーン図を候補にする。

ユーザー
Web
API
DB

のように分け、

「この処理は誰が担当しているのか？」

を確認する。

「誰が誰に、どの順番で処理を要求するのか」を知りたい

シーケンス図を候補にする。

A → B
B → C
C → B
B → A

のようなメッセージの流れを確認できる。

特に、

API呼び出し
システム間連携
リクエスト
レスポンス
呼び出し順序

などを詳しく確認したい場合に向いている。

誰が読む資料なのかも考える

今回調べていて、もう一つ重要だと思ったことがある。

それは、

「誰が読む資料なのか？」

という点。

同じログイン処理でも、読む人によって必要な情報は変わる。

例えば業務担当者に対して、

「認証APIがDBへSQLを発行して……」

と説明しても、必要以上に細かいかもしれない。

逆に開発者に対して、

「ユーザーがログインすると認証されます」

だけでは情報不足になる。

そのため、

何を伝えたいのか

だけではなく、

誰に伝えるのか

も図を選ぶときの重要なポイントだと感じた。

要件定義では、どこまで細かく書くのか？

今回、自分がシーケンス図を書こうとしたとき、

「まだ要件定義の段階なので、細かいものはいらない」

と言われた。

最初は、

「シーケンス図ではなくスイムレーン図の方が正しいのかな？」

と考えていた。

しかし今回調べてみると、必ずしもそういう意味ではなさそう。

重要なのは、

その段階で何を共有・確認する必要があるのか

という点。

例えば要件定義の初期段階なら、

ユーザー
 ↓
ログイン
 ↓
認証
 ↓
ログイン完了

程度の全体像で十分かもしれない。

一方、詳細設計では、

Web
 ↓
認証API
 ↓
DB
 ↓
認証API
 ↓
Web

という具体的な処理順序を確認する必要が出てくる場合がある。

この場合は、シーケンス図の方が適している。

つまり、

図の種類だけではなく、設計の段階に応じて必要な情報量も変わる

と考えた方が良さそう。

スイムレーン図のメリット・デメリット

メリット

最大のメリットは、

処理の流れと担当範囲を一緒に確認できること

これに尽きる。

特に、

人からシステムへ処理が移る
部署間で処理を引き継ぐ
複数システムが関係する
担当範囲を明確にしたい

といった場合に、処理の流れだけでは見えにくい責任範囲を整理できる。

デメリット

一方で、レーンを増やしすぎると図が複雑になる問題がある。

例えば、

ユーザー
Web
SPA
API Gateway
認証API
認証サービス
DB
Cache
外部認証サービス

まで細かく分けてしまうと、何を伝えるための図なのか分からなくなる。

そのため、

必要な情報を表現するために必要なレーンだけ用意する

のが大事。

調べる前と調べた後

調べる前

自分は、

「スイムレーン図って、フローチャートに担当者を書いただけなのでは？」

くらいに考えていた。

また、

「シーケンス図とは何が違うんだろう？」

という疑問もあった。

調べた後

調べてみると、重要なのは図の名前よりも、

「何を伝えたいのか？」

ということだと分かった。

フローチャートなら処理の流れ。

スイムレーン図なら処理の流れと担当。

シーケンス図なら要素間のやり取りと順序。

というように、同じログイン処理でも、見るポイントを変えられる。

また、スイムレーン図についても、

「UMLのスイムレーン図という独立した図がある」

と考えていたが、UMLではActivity Partitionを利用してスイムレーン形式の表現ができる、という関係を知ることができた。

注意点・今回分からなかったこと

今回の比較では、同じログイン処理を3種類の図で表現した。

ただし、実際のプロジェクトでは、

「要件定義では必ずこの図」
「詳細設計では必ずこの図」

という共通ルールがあるとは限らない。

また、「スイムレーン図」という言葉も、UMLだけでなく業務プロセスやBPMNなど、複数の文脈で使用される。

そのため、

「スイムレーン図は必ずこの書き方」

と決めつけるのは避けた方が良さそう。

今回の検証も、あくまで同じログイン処理を異なる表現で描くことで、それぞれ何が見えやすくなるのかを比較したもの。

実際の設計では、プロジェクトで採用している記法やルール、資料の読者などを考えて判断する必要がある。

まとめ

今回は、設計書を作っているときに、

「シーケンス図よりスイムレーン図の方が合っているかもしれない」

と言われたことをきっかけに、スイムレーン図について調べてみた。

最初は、

「フローチャートと何が違うの？」

という程度の理解だった。

そこで、同じログイン処理を、

フローチャート
スイムレーン図
シーケンス図

の3種類で実際に作って比較してみた。

その結果、

フローチャート → 処理や判断の流れを見る
スイムレーン図 → 処理の流れと担当を見る
シーケンス図 → 要素間のやり取りと順序を見る

という違いが見えてきた。

今回の最初の疑問だった、

「スイムレーン図とシーケンス図って、何が違うの？」

については、

スイムレーン図は「処理と担当の関係」を把握しやすくする表現で、シーケンス図は「要素間のやり取りと順序」を詳しく把握するための表現

と整理した。

また、どの図を使うか迷ったときは、

何を伝えたいのか
誰に伝えるのか
どの程度の詳細さが必要なのか

を考えると判断しやすそう。

今回調べたことで、次は「要件定義・基本設計・詳細設計で、図の粒度をどのように変えると分かりやすいのか」もスキルとして持っておいた方がよさそうだけど、どうも苦手なんだよなぁ。。。どこかで、勉強してまとめます。。。

参考資料

Databricks Unity CatalogからAWS Glueのテーブルを参照できるか調べてみた

Sun, 23 Aug 2026 00:00:00 GMT

はじめに

DatabricksのUnity Catalogを使っているときに、AWS Glueに登録されているテーブルを直接参照できる「カタログフェデレーション」という機能があることを知った。

最初は、

「GlueのConnectionを作れば、そのままDatabricksから参照できる」

くらいの認識だった。

ところが、実際に調べてみると、いくつか気になることが出てきた。

単にGlueへの接続を作るだけで参照できるのか
IAM Roleの設定はどうすればよいのか
Service Credential と Storage Credential は何が違うのか
エラーが発生したときにどう切り分ければよいのか

そこで今回は、実際に検証用のAWS Glue CatalogとS3を用意し、DatabricksからAWS Glueのメタデータを参照して、最終的にS3上のテーブルデータをSQLで取得できるところまで試してみた。

この記事の対象読者

この記事は、以下のような人を対象にしている。

Databricks Unity Catalog を使っている人
AWS Glue にある既存テーブルを Databricks から参照したい人
Service Credential と Storage Credential の違いを知りたい人
カタログフェデレーション設定時に発生するエラーと対処法を知りたい人

まず結論

今回調べてみて、最初に考えていた、

「GlueのConnectionを作れば簡単に参照できる」

という理解は、少し違っていた。

実際には、単にConnectionを作るだけではなく、

AWS IAM Role
Service Credential
Storage Credential
External Location
Foreign Catalog

といった複数のオブジェクトが関係しており、それぞれに適切な権限やパラメータを設定する必要があった。

特に重要だった役割の違いをまとめると、次のようになる。

オブジェクト	主な役割
Service Credential	AWS Glueなどの外部クラウドサービスへのアクセスに使用
Storage Credential	S3などのクラウドストレージへのアクセスに使用
External Location	Storage CredentialとS3パスを組み合わせたストレージ領域
Foreign Catalog	Glueなどの外部MetastoreをUnity Catalog上に公開するカタログ

また、設定時のハマりどころとして、以下のエラーが発生した。

AccessDeniedException: not authorized to perform: glue:GetDatabase on resource: .../database/default

Databricksは対象のデータベースだけでなく、default データベースの存在確認も行うため、IAM Policyで database/* を許可する必要があった。

そもそも何を検証したかったのか？

今回確認したかったのは、

AWS Glueに登録されているテーブルを、Databricks Unity Catalogから参照できるのか？

という点。

AWS Glue側には、次のようなデータを用意した。

AWS Glue Data Catalog
└─ catalog_federation_test
    └─ sample_table

そして、テーブルの実データはS3に配置した。

s3://catalog-federation-test-20260822-123456789012-us-east-2-an/iceberg/sample_table

最終的には、このGlueのテーブルをDatabricksから参照する。

今回構築した全体の検証構成は以下の通り。

Databricks
   │
   │ Unity Catalog
   │
   ├─ Service Credential
   │       │
   │       ▼
   │   AWS IAM Role
   │       │
   │       ├─ AWS Glue
   │       │     └─ catalog_federation_test
   │       │           └─ sample_table
   │       │
   │       └─ Amazon S3
   │             └─ iceberg/sample_table
   │
   ├─ Connection
   │
   ├─ External Location
   │
   └─ Foreign Catalog
          │
          ▼
       sample_table

最終的にはDatabricks SQLから以下のデータを取得できた。

id    name
1     Alice
2     Bob
3     Carol

前提となるAWSリソースの確認と準備

まずはAWS側で、今回使用するリソースが存在しているか確認する。

1. AWSアカウントを確認する

最初にAWS CloudShellから現在使用しているAWSアカウントを確認した。

aws sts get-caller-identity

結果は以下。

{
    "UserId": "123456789012",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:root"
}

ここで、今回使用するAWSアカウントIDが 123456789012 であることを確認した。

2. AWS GlueにDatabaseとTableが存在することを確認する

AWS CloudShellからGlueのDatabaseを確認した。

aws glue get-databases \
  --region us-east-2 \
  --query 'DatabaseList[].Name' \
  --output table

結果：

-----------------------------
|       GetDatabases        |
+---------------------------+
|  catalog_federation_test  |
+---------------------------+

続いてTableを確認する。

aws glue get-tables \
  --region us-east-2 \
  --database-name catalog_federation_test \
  --query 'TableList[].Name' \
  --output table

結果：

------------------
|    GetTables   |
+----------------+
|  sample_table  |
+----------------+

さらにCatalog IDも確認した。

aws glue get-databases \
  --region us-east-2 \
  --query 'DatabaseList[].CatalogId' \
  --output table

結果：

------------------
|  GetDatabases  |
+----------------+
|  123456789012  |
+----------------+

Tableについても確認。

aws glue get-tables \
  --region us-east-2 \
  --database-name catalog_federation_test \
  --query 'TableList[].{Name:Name,CatalogId:CatalogId}' \
  --output table

結果：

----------------------------------
|            GetTables           |
+---------------+----------------+
|   CatalogId   |     Name       |
+---------------+----------------+
|  123456789012 |  sample_table  |
+---------------+----------------+

これにより、今回参照するGlue Catalogは、

Account / Catalog ID
123456789012

Database
catalog_federation_test

Table
sample_table

であることを確認した。

3. S3に検証用領域を作る

今回は本番データと混ざらないように、検証用S3バケットを用意した。

バケット：

catalog-federation-test-20260822-123456789012-us-east-2-an

バケット内には、主に以下の領域を用意した。

athena-results/
catalog-metadata/
iceberg/

テーブルデータは、

iceberg/sample_table/

に配置している。

最終的に使用するS3パスは、

s3://catalog-federation-test-20260822-123456789012-us-east-2-an/iceberg/sample_table

また、Foreign Catalogのメタデータ保存用として、

s3://catalog-federation-test-20260822-123456789012-us-east-2-an/catalog-metadata/

を用意した。

DatabricksのForeign Catalogでは、Icebergテーブルを読む場合、Storage locationとしてメタデータ保存先を指定する必要がある。

AWS IAM RoleとPolicyの設定

DatabricksからAWS GlueおよびS3へアクセスするためのIAM Roleを作成する。

1. AWS IAM Roleを作成する

Role名：

catalog-federation-test-role

ARN：

arn:aws:iam::123456789012:role/catalog-federation-test-role

DatabricksのAWS Glue Federationでは、DatabricksからAWS GlueへアクセスできるIAM Roleを作成し、そのRoleをUnity CatalogのService Credentialから利用する。

2. IAM RoleのTrust Policyを設定する

DatabricksからRoleをAssumeできるようにTrust Policyを設定した。

検証時には、Databricksから提示されたTrust Policyを使用。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::414351767826:role/unity-catalog-prod-UCMasterRole-14S5ZJVKOTYTL",
          "arn:aws:iam::123456789012:role/catalog-federation-test-role"
        ]
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "your-external-id-uuid"
        }
      }
    }
  ]
}

ここで注意したのは、AWSアカウントIDが2種類登場すること。

123456789012

は今回利用したAWSアカウント。

一方、

414351767826

はTrust Policyで指定されたDatabricks側のPrincipal。

そのため、GlueのResource ARNには今回のAWSアカウントである

123456789012

を使用する。

3. IAM Policyを設定する

最初はGlueの対象Databaseだけを許可していた。

しかし、DatabricksからForeign Catalogを利用すると、default Databaseの存在確認も行われた。

そのため、glue:GetDatabase が arn:aws:glue:us-east-2:123456789012:database/default に対して拒否された。

実際のエラーは、

not authorized to perform: glue:GetDatabase
on resource:
arn:aws:glue:us-east-2:123456789012:database/default

だった。

AWS GlueのData Catalogは、

Catalog
 └─ Database
      └─ Table

という階層になっており、AWS公式ドキュメントでもこれらのリソースに対応したARNをIAM Policyで指定できる。

そこで、今回の検証ではGlueメタデータについてはCatalog全体を読み取り対象とし、S3については検証用バケットだけに限定した。

最終的に使用したIAM Policyは以下。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GlueReadOnly",
      "Effect": "Allow",
      "Action": [
        "glue:GetDatabase",
        "glue:GetDatabases",
        "glue:GetPartition",
        "glue:GetPartitions",
        "glue:GetTable",
        "glue:GetTables",
        "glue:GetUserDefinedFunction",
        "glue:GetUserDefinedFunctions",
        "glue:BatchGetPartition"
      ],
      "Resource": [
        "arn:aws:glue:us-east-2:123456789012:catalog",
        "arn:aws:glue:us-east-2:123456789012:database/*",
        "arn:aws:glue:us-east-2:123456789012:table/*/*"
      ]
    },
    {
      "Sid": "S3ListBucket",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketLocation"
      ],
      "Resource": "arn:aws:s3:::catalog-federation-test-20260822-123456789012-us-east-2-an"
    },
    {
      "Sid": "S3ReadObjects",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject"
      ],
      "Resource": "arn:aws:s3:::catalog-federation-test-20260822-123456789012-us-east-2-an/*"
    },
    {
      "Sid": "S3MetadataWrite",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::catalog-federation-test-20260822-123456789012-us-east-2-an/catalog-metadata/*"
    },
    {
      "Sid": "S3MetadataMultipart",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucketMultipartUploads",
        "s3:ListMultipartUploadParts",
        "s3:AbortMultipartUpload"
      ],
      "Resource": "arn:aws:s3:::catalog-federation-test-20260822-123456789012-us-east-2-an"
    }
  ]
}

Glueについては database/* および table/*/* としているため、今回の検証では default Databaseを含むGlue Catalogのメタデータを読み取れる。

一方、S3については検証用バケットだけに限定している。

なお、このIAM Policyをそのまま本番環境へ適用することを推奨しているわけではない。本番では、必要なGlue DatabaseやTableに対象を絞るなど、最小権限を検討する必要がある。

Databricks Unity Catalog側の構築

次に、Databricks側で設定を行っていく。

1. Service Credentialを作成する

まず、Databricks側でService Credentialを作成した。

Service Credentialには、先ほど作成したAWS IAM Roleを関連付ける。

名前：

catalog-federation-test-service-credential

Databricks公式では、Service Credentialは外部クラウドサービスへのアクセスに使用するUnity Catalogのオブジェクトで、AWSサービスへアクセスする場合はIAM Roleを登録する。

ここで重要なのは、

AWS S3のデータアクセス用のStorage Credentialと、AWS Glueのような外部サービスへのアクセスに使うService Credentialは別物

ということ。

2. Storage Credentialを作成する

S3のアクセスにはService CredentialではなくStorage Credentialを使用する。

今回作成したStorage Credential：

catalog-federation-test-credential

用途を整理すると、次のようになる。

Credential	用途
Service Credential	AWS Glueへのアクセス
Storage Credential	S3へのアクセス

Databricksでは、Storage Credentialがクラウドストレージへの認証情報を表し、External LocationがそのStorage CredentialとS3パスを組み合わせたオブジェクトになる。

今回の検証では、Storage Credentialの設定が読み取り専用になっていたため、Foreign CatalogのStorage locationとして使用するS3領域について、後から書き込み権限も必要になった。

3. External Locationを作成する

次にS3のパスをUnity Catalogで管理するため、External Locationを作成した。

External Locationは、

S3パス
+
Storage Credential

を組み合わせたUnity Catalogオブジェクト。

今回の検証では、以下の領域を対象にした。

s3://catalog-federation-test-20260822-123456789012-us-east-2-an/iceberg/

また、Foreign Catalogのメタデータ保存用として、

s3://catalog-federation-test-20260822-123456789012-us-east-2-an/catalog-metadata/

もExternal Locationとして用意した。

4. File Eventsでエラーが発生した

External Locationの作成時、File Eventsのチェックでエラーが発生した。

表示された内容は、

File Events Permissions Not Verified

で、s3:GetBucketNotification の権限が不足しているという内容だった。

今回の検証ではFile Events自体が必須ではなかったため、まずExternal Locationの作成を優先した。

Databricksの画面でも、

File events are optional but recommended

という説明が表示された。

File Eventsを利用すると、ファイル変更の検知によってストレージの一覧取得を減らせるため、取り込み性能やS3のListコストに影響する可能性がある。ただし、今回の目的はGlue Federationの基本動作確認だったため、File Eventsは検証対象から外した。

▲ External Location作成時に表示される File Events の検証警告画面

5. AWS Glue Connectionを作成する

次にDatabricksでConnectionを作成した。

Connection Type：AWS Glue
AWS Region：us-east-2
AWS Account ID：123456789012
Credential：catalog-federation-test-service-credential

Databricks公式のGlue Federation手順でも、Connection作成時にAWS Region、AWS Account ID、Service Credentialを指定する流れになっている。

6. Connectionのテスト

Connection作成前後で接続テストを実施した。

最終的には、

Success - Assume Role
Success - Self Assume Role
Success - External ID Condition
All Permissions Confirmed

となった。

これは、

DatabricksからIAM RoleをAssumeできる
IAM RoleのSelf Assumeができる
External ID条件を満たしている
必要な権限を確認できている

ことを確認する材料になる。

▲ Databricks Connectionのテスト結果画面

7. Foreign Catalogを作成する

Connectionが作成できたので、Foreign Catalogを作成する。

Catalog name：catalog-federation-test-connection_catalog
Connection：catalog-federation-test-connection

Authorized pathsには、External Locationで許可したS3パスを指定する。

ここで少し分かりづらかったのが、Authorized paths と Storage location の違い。

Authorized paths

実際のテーブルデータが存在するS3領域。

s3://catalog-federation-test-20260822-123456789012-us-east-2-an/iceberg/

Authorized pathsは、Foreign Catalogからアクセスできるクラウドストレージパスを制限するためのもの。

▲ Foreign Catalog作成時の Authorized paths の指定画面

Storage location

Foreign Catalogで使用するメタデータ保存先。

s3://catalog-federation-test-20260822-123456789012-us-east-2-an/catalog-metadata/

Icebergテーブルを読む場合、Storage locationの指定が必要になる。

▲ Foreign Catalog作成時の Storage location の指定画面

8. Foreign Catalogが作成された

作成後、catalog-federation-test-connection_catalog というCatalogが作成された。

最初はCatalog自体は作成できたものの、配下には No Data と表示された。

この時点では、

Catalogが作成できた = テーブルを正常に参照できる

とは限らない。Foreign Catalogでは、ユーザーやワークフローがアクセスすると外部Metastoreからメタデータが同期される。

実際に動かして遭遇したエラーと切り分け

Catalogを作成した後、SQLでテーブルを参照しようとした。

1. AWS Glueの権限不足でエラーになった

SQLでテーブルを参照しようとすると、以下のエラーが発生した。

EXTERNAL_METASTORE_CLIENT_ERROR.OPERATION_FAILED

Unable to verify existence of default database

AccessDeniedException:
not authorized to perform:
glue:GetDatabase

on resource:
arn:aws:glue:us-east-2:123456789012:database/default

最初に作成したIAM Policyでは、database/catalog_federation_test だけを許可していた。

しかしDatabricks側では、database/default の存在確認も行われていた。

そのため、catalog_federation_test に対する権限があっても、default に対する glue:GetDatabase が拒否されていた。

エラーログの確認
        ↓
arn:aws:glue:us-east-2:123456789012:database/default が AccessDenied
        ↓
IAM Policyに default データベースの許可がない
        ↓
database/* を許可するように修正

このエラーから、

IAM RoleのAssume自体は成功しているが、Glueメタデータ取得時のリソース権限が不足している

と切り分けた。

2. IAM Policyを修正する

そこでGlueのメタデータ読み取り範囲を、database/* および table/*/* まで広げた。

この結果、DatabricksからGlueのメタデータを取得できるようになり、No Data だった表示が解消された。

今回の修正は単に権限を全開放したわけではなく、エラーメッセージに表示された具体的なResource（database/default）をもとに原因を特定して修正した。

3. SQLでテーブルを参照する

最後にDatabricks SQLからテーブルを参照した。

Catalog名には - が含まれているため、バッククォートで囲む。

SELECT *
FROM `catalog-federation-test-connection_catalog`.catalog_federation_test.sample_table;

実行結果：

id    name
1     Alice
2     Bob
3     Carol

これで、

Databricks
    ↓
Unity Catalog
    ↓
Foreign Catalog
    ↓
AWS Glue
    ↓
catalog_federation_test
    ↓
sample_table
    ↓
S3

という経路でデータを取得できることを確認できた。

▲ Databricks SQLからAWS Glue経由でS3上のテーブルデータを正常に取得できた最終結果画面

カタログUI上からも存在することを確認できた。

▲ DatabricksカタログUIでの最終結果画面

今回発生したエラーと原因・対処まとめ

今回の検証で発生したエラーと対処をまとめる。

エラー	原因	対応
Credentialが選択できない	Service Credentialへの権限不足	Credentialの権限を確認
File Events Permissions Not Verified	`s3:GetBucketNotification`等が不足	今回はFile Eventsを検証対象外として作成
Foreign CatalogがNo Data	Glueメタデータ取得が正常に完了していない	IAM権限を確認
`glue:GetDatabase` AccessDenied	`default` Databaseへのアクセス権不足	Glue Databaseの許可範囲を見直し（`database/*`）
INVALID_IDENTIFIER	Catalog名に`-`が含まれていた	Catalog名をバッククォートで囲む

特に注意したいのは、

Connectionのテストが成功しても、最終的なSQL実行まで成功するとは限らない

という点。ConnectionのテストではAssume RoleやExternal IDなどを確認できるが、実際のForeign Catalog利用時にはGlueのメタデータ取得やS3アクセスなど、さらに別の権限が必要になる。

実際に調べて分かったこと

調べる前

最初は、

Databricks → AWS Glue と接続設定（Connection）を作るだけで簡単に参照できる

くらいの認識だった。

調べた後

実際に試してみると、単に接続を作るだけではなく、

AWS IAM Role
Service Credential
Storage Credential
Connection
External Location
Foreign Catalog

といった複数のオブジェクトが密接に関係していると分かった。

特に重要だったのが、Service CredentialとStorage Credentialを分けて考えること。

AWS Glue
    ↑
Service Credential

S3
    ↑
Storage Credential
    ↑
External Location

という関係で考えると理解しやすい。

Databricks公式でも、Service CredentialはAWS Glueなどの外部クラウドサービス向け、Storage Credentialはクラウドストレージ向けとして説明されている。

注意点

今回の検証は、以下の環境で実施している。

Databricks Unity Catalog
AWS Glue / Amazon S3
AWS Region: us-east-2

また、検証のためにIAM Policyで database/* を許可しているが、そのまま本番環境へ適用することを推奨するものではない。

本番環境では、利用するDatabaseやTableに権限を限定できないかを確認し、最小権限を検討する必要がある。

今回調べて分からなかったこと

今回の記事では基本機能の疎通確認に絞って検証している。

そのため、次のような内容は今回の調査範囲外。

File Events を有効にした場合の自動同期・パフォーマンスへの影響
大規模テーブルでのフェデレーションクエリのレイテンシ
複数AWSアカウントにまたがるアクセス権限構成
他のデータフォーマット（Delta Lake, Parquet等）での挙動の違い

AWSの知識が圧倒的に不足しているので、権限回りは機会があれば勉強し直したいなぁ先に資格を取るのが先かな

パフォーマンスとかは気になるけどたぶんフリートライアルだと限界ありそうなので誰かがまとめてくれることを願う。。。

他のデータフォーマット（Delta Lake, Parquet等）での挙動の違いは、、、正直Glueだけでもすっっっごい時間かかったので、気力あればまとめますん、、、

まとめ

今回は、Databricks Unity CatalogからAWS Glueのテーブルを参照できるカタログフェデレーションについて調べた。

最終的な全体構成は以下のようになった。

┌──────────────────────────────┐
│         Databricks           │
│                              │
│  Unity Catalog               │
│       │                      │
│       ├─ Service Credential  │
│       │                      │
│       ├─ Storage Credential  │
│       │                      │
│       ├─ Connection          │
│       │                      │
│       ├─ External Location   │
│       │                      │
│       └─ Foreign Catalog     │
│              │               │
└──────────────┼───────────────┘
               │
               │ IAM Role / AssumeRole
               ▼
┌──────────────────────────────┐
│            AWS               │
│                              │
│  IAM Role                    │
│  catalog-federation-test-role│
│       │                      │
│       ├──────────────┐       │
│       ▼              ▼       │
│   AWS Glue          S3       │
│       │              │       │
│       ▼              ▼       │
│ catalog_federation_test      │
│       │                      │
│       └─ sample_table ──────┘
└──────────────────────────────┘

最初は「GlueのConnectionを作れば参照できるのでは？」と思っていたが、実際にはS3のExternal LocationやIAM権限、Foreign Catalogの設定など、複数の設定が必要だった。

また、途中で発生した glue:GetDatabase のAccessDeniedから、Databricksが対象の catalog_federation_test だけではなく default Databaseの存在確認も行っていることが分かった。

最終的には、

SELECT *
FROM `catalog-federation-test-connection_catalog`.catalog_federation_test.sample_table;

で、期待通りのデータを取得できた。

実際の手順を踏んで構築してみることで、IAM、Credential、Connection、External Location、Foreign Catalogというそれぞれの役割と裏側の挙動を確認できた。

参考資料

Databricks: AWS Glue Hive Metastore Federation
Databricks: Service Credentials
Databricks: Unity Catalogによるクラウドストレージへの接続
AWS: AWS Glue Resource ARN
AWS: AWS Glue GetDatabase API

Content-Dispositionとは？ファイルダウンロードとファイル名について調べてみた

Fri, 21 Aug 2026 00:00:00 GMT

はじめに

ファイルダウンロードの仕組みを自作しているときに、Content-Disposition というHTTPヘッダーが出てきた。

最初は、

「ファイルをダウンロードさせるために必要なもの」

くらいの認識だった。

ところが、実際に調べてみると、いくつか気になることが出てきた。

Content-Type もファイルの種類を表しているのに、なぜ Content-Disposition も必要なのか？

また、

Content-Disposition がなくてもファイルを取得できるのか
inline と attachment は何が違うのか
filename を指定するとChromeではどう動くのか
日本語のファイル名はどう指定するのか
filename と filename* は何が違うのか
両方指定した場合はどちらが使われるのか

といった疑問も出てきた。

そこで今回は、Node.jsで簡単なHTTPサーバーを作り、Chromeで実際の挙動を確認しながら調べてみた。

この記事の対象読者

この記事は、以下のような人を対象にしている。

Content-Disposition という言葉を初めて知った人
HTTPでファイルダウンロードを実装している人
Content-Type と Content-Disposition の違いが分からない人
filename と filename* の違いを知りたい人
ブラウザがダウンロードファイルの名前をどう決めるのか知りたい人

まず結論

今回調べてみて、最初に考えていた、

「ファイルをダウンロードさせるには Content-Disposition が必要」

という理解は、少し違っていた。

Content-Disposition は、単純に「ファイルをダウンロードさせるためだけ」のヘッダーではない。

HTTPレスポンスでは、たとえば次のような指定ができる。

Content-Disposition: inline

Content-Disposition: attachment

inline はコンテンツを通常の表示方法で扱うことを示し、attachment はダウンロードする添付ファイルとして扱うことを示す。さらに、filename や filename* を指定することで、保存時などに使うファイル名についても情報を伝えられる。RFC 6266では、これらの用途が定義されている。

一方、Content-Type は、そのデータがどのようなメディアタイプなのかを示すヘッダー。

そのため、ざっくり整理すると次のようになる。

ヘッダー	主な役割
`Content-Type`	データの種類を示す
`Content-Disposition`	レスポンスをどう扱うかを示す
`filename`	保存時などに利用するファイル名を示す
`filename*`	文字コードを指定した形式でファイル名を示す

filename* は拡張パラメータ形式を使って値の文字コードを指定でき、RFC 8187ではUTF-8をサポートすることが定義されている。

ただし、仕様としての定義と、実際のブラウザの挙動が常に同じとは限らない。

そのため、今回はChromeで実際に確認してみる。

Content-Dispositionとは？

基本的な定義

HTTPのレスポンスにおける Content-Disposition は、レスポンスのコンテンツをブラウザ内で通常どおり扱うのか、それとも添付ファイルとしてダウンロードするのかといった、コンテンツの扱い方に関する情報を伝えるヘッダー。

代表的な指定は次の2つ。

Content-Disposition: inline

Content-Disposition: attachment

inline はブラウザ内で表示可能なコンテンツを通常どおり扱う方向の指定。

attachment はダウンロードする添付ファイルとして扱う指定。ブラウザによっては、filename が指定されていれば、その名前を保存候補として利用する。

Content-Typeとの違い

今回、最初に気になったのがここ。

たとえばJPEG画像を返す場合、

Content-Type: image/jpeg

とする。

これは、

「このデータはJPEG画像です」

という情報。

一方、

Content-Disposition: attachment

は、

「このレスポンスは添付ファイルとして扱います」

という情報。

つまり、

Content-Type
    ↓
「これは何のデータ？」

Content-Disposition
    ↓
「そのデータをどう扱う？」

という違いとして考えると分かりやすい。

Content-Type はメディアタイプを示し、Content-Disposition はコンテンツの扱い方を示す。

なぜContent-Dispositionが必要になったのか？

Content-Typeだけでは「どう扱うか」までは決まらない（Content-Typeだけではダメなの？）

たとえば、

Content-Type: image/jpeg

と返せば、JPEGであることは伝えられる。

ただし、

「そのJPEGをブラウザに表示するのか、保存させるのか」

という情報は別。

そこで、

Content-Disposition: attachment

のような指定が使われる。

今回の検証では、この違いを実際に確認してみる。

Content-Dispositionにはどのような指定がある？

今回の記事では、主に次の4パターンを確認する。

指定	今回確認する内容
なし	ヘッダーを指定しないとどうなるか
`inline`	通常の表示として扱われるか
`attachment`	ダウンロードとして扱われるか
`attachment; filename=...`	保存時のファイル名が変わるか

さらに、ファイル名について、

filename="sample.txt"

と、

filename*=UTF-8''...

の違いも確認する。

実際にContent-Dispositionを試してみる

検証環境

項目	内容
OS	Windows 11
言語	JavaScript
ランタイム	Node.js v24.14.1
HTTPサーバー	Node.js標準 `http`
ブラウザ	Google Chrome
検証ファイル	TXT / JPEG

Node.jsの response.setHeader() を使うことで、HTTPレスポンスのヘッダーを設定できる。Node.jsでは、ヘッダー値に不正な文字が含まれている場合、TypeError が発生する。また、UTF-8文字をヘッダー値として扱う場合にはRFC 8187形式を使用する例がNode.jsのドキュメントにも掲載されている。

今回確認したこと

今回の検証では、以下を確認する。

Content-Disposition がない場合、Chromeはどう扱うのか
inline と attachment では何が変わるのか
filename を指定すると保存ファイル名が変わるのか
スペースを含むファイル名はどう扱われるのか
日本語を filename に直接指定するとどうなるのか
filename* を使うとどうなるのか
filename と filename* を両方指定するとどちらが使われるのか
JPEGでも同じような挙動になるのか

検証方法

今回の検証では、ChromeのDevToolsを利用する。

基本的に確認するのは次の3つ。

1. Network

HTTPレスポンスに実際にどのヘッダーが返ってきたか確認する。

特に、

Response Headers

を確認する。

2. Chromeの画面

レスポンスをChromeが実際にどう処理したのかを確認する。

たとえば、

ブラウザ内に表示された
ダウンロードが開始された

など。

3. 保存されたファイル

ダウンロードが発生した場合は、実際に保存されたファイル名も確認する。

検証1：Content-Dispositionを指定しない

まずは Content-Disposition をいっさい指定しないケース。

今回使用するTXTでは、

Content-Type: text/plain

だけを返す。

検証コード

case '/case01-no-disposition-txt':
  sendText(res);
  break;

sendText() の中では Content-Type だけを設定している。

function sendText(res, contentDisposition) {
  res.setHeader('Content-Type', 'text/plain');

  if (contentDisposition !== undefined) {
    res.setHeader('Content-Disposition', contentDisposition);
  }

  res.end(txtData);
}

検証結果

Response HeadersにContent-Dispositionがないことも確認。 ↓ Chromeの画面にテキストが表示された。

検証結果から分かったこと

Chromeでは単なるテキストとしてブラウザ表示されたっぽい。

検証2：inline

次に、

Content-Disposition: inline

を指定してみる。

検証コード

case '/case02-inline-txt':
  sendText(res, 'inline');
  break;

どうなる？

仕様上、inline はコンテンツを通常の表示方法で扱う指定。

ただし、今回は「仕様上そうなっている」だけで終わらせず、Chromeで実際に確認してみる。

検証結果

Response Headersで以下になっていることを確認。 ↓

Content-Disposition: inline

が付与されているが、Chromeの画面にテキストが表示された。

検証結果から分かったこと

inline を指定してもブラウザ内に表示されるっぽい。

検証3：attachment

次に、

Content-Disposition: attachment

を指定してみる。

検証コード

case '/case03-attachment-txt':
  sendText(res, 'attachment');
  break;

attachment はコンテンツをダウンロードする添付ファイルとして扱うための指定。

検証結果

Response Headersで以下になっていることを確認。

Content-Disposition: attachment

↓ ダウンロードダイアログが表示されることを確認。 ↓ 保存されたファイル名：case03-attachment-txt.txt

検証4：filenameを指定する

ここからファイル名指定を確認してみる。

Content-Disposition: attachment; filename="sample.txt"

検証コード

case '/case04-filename-txt':
  sendText(
    res,
    'attachment; filename="sample.txt"'
  );
  break;

filename は、保存時などに利用するファイル名を示すためのパラメータ。

検証結果

Response Headersで以下になっていることを確認。

Content-Disposition: attachment; filename="sample.txt"

↓ ダウンロードダイアログが表示されることを確認。 ↓ 保存されたファイル名：sample.txt

検証結果から分かったこと

filename に指定した名前で、Chromeでも保存された。

検証5：スペースを含むfilename

次に、

Content-Disposition: attachment; filename="sample file.txt"

を試してみる。

ファイル名にスペースなどを含める場合、filename の値を引用符で囲む形式が利用できる。

検証コード

case '/case05-filename-space-txt':
  sendText(
    res,
    'attachment; filename="sample file.txt"'
  );
  break;

検証結果

Response Headersで以下になっていることを確認。

Content-Disposition: attachment; filename="sample file.txt"

↓ ダウンロードダイアログが表示されることを確認。 ↓ 保存されたファイル名：sample file.txt

検証結果から分かったこと

filename にスペースを含む場合は、引用符で囲むことでChromeでも正しくファイル名が保存されるっぽい。

検証6：filenameに日本語を直接指定する

ここで、次のような日本語ファイル名を指定してみる。

Content-Disposition: attachment; filename="日本語.txt"

検証コード

case '/case06-filename-japanese-txt':
  sendText(
    res,
    'attachment; filename="日本語.txt"'
  );
  break;

この検証は、ChromeだけでなくNode.js側も重要。

Node.jsのHTTP APIでは、ヘッダー値に不正な文字が含まれている場合 TypeError になる。Node.jsのドキュメントでは、UTF-8文字を含む値を扱う場合にRFC 8187形式を使用する例も示されている。

Node.js側のターミナルでエラーが発生した。

TypeError
ERR_INVALID_CHAR

Chrome側はエラーレスポンスが返ってきている。

検証結果

Node.js側でエラーが発生したため、Chrome側でレスポンスを受け取れず500エラーになった。エラーとしては TypeError の ERR_INVALID_CHAR が発生している。

検証7：filename*を使う

ここで filename* を試してみる。

たとえば、

Content-Disposition: attachment; filename*=UTF-8''%E6%97%A5%E6%9C%AC%E8%AA%9E.txt

とする。

filename* は拡張パラメータ形式を使用し、文字コードを指定した値を表現できる。RFC 8187では、UTF-8''... のような形式で文字コードと値を指定する。

検証コード

case '/case07-filename-star-txt':
  sendText(
    res,
    "attachment; filename*=UTF-8''%E6%97%A5%E6%9C%AC%E8%AA%9E.txt"
  );
  break;

検証結果

Response Headersで以下になっていることを確認。

Content-Disposition: attachment; filename*=UTF-8''%E6%97%A5%E6%9C%AC%E8%AA%9E.txt

↓ ダウンロードダイアログが表示されることを確認。 ↓ 保存されたファイル名：日本語.txt

検証結果から分かったこと

filename* を使うことで、Chromeでも日本語ファイル名が正しく保存されるようになった。

検証8：filenameとfilename*を両方指定する

次に、2つを同時に指定してみる。

Content-Disposition: attachment;
 filename="fallback.txt";
 filename*=UTF-8''%E6%97%A5%E6%9C%AC%E8%AA%9E.txt

RFC 6266では、両方が存在する場合、filename* を理解するユーザーエージェントは filename* を選択することが推奨されている。古いユーザーエージェントへのフォールバックとして filename と filename* の両方を指定する形も示されている。

検証コード

case '/case08-filename-both-txt':
  sendText(
    res,
    "attachment; filename=\"fallback.txt\"; filename*=UTF-8''%E6%97%A5%E6%9C%AC%E8%AA%9E.txt"
  );
  break;

検証結果

Response Headersで以下になっていることを確認。

Content-Disposition: attachment; filename="fallback.txt"; filename*=UTF-8''%E6%97%A5%E6%9C%AC%E8%AA%9E.txt

↓ ダウンロードダイアログが表示されることを確認。 ↓ 保存されたファイル名：日本語.txt

仕様との比較

仕様上の説明
        ↓
filename* が優先される

実際のChrome
        ↓
filename* の指定 (日本語.txt) で保存された

比較
        ↓
一致した

filename としては "fallback.txt" にしていたが、filename* に日本語を指定したため、日本語.txt の名前で保存された。

検証9：inline + filenameをJPEGで確認する

ここからJPEGを使ってみる。

レスポンスを次のように設定。

Content-Type: image/jpeg
Content-Disposition: inline; filename="sample.jpg"

検証コード

case '/case09-inline-filename-jpg':
  sendJpeg(
    res,
    'inline; filename="sample.jpg"'
  );
  break;

ここでは、

filename を指定していても、inline の場合はどうなるのか？

を確認する。

検証結果

Response Headersで以下になっていることを確認。

Content-Type: image/jpeg
Content-Disposition: inline; filename="sample.jpg"

↓ 保存されたファイル：なし（ダウンロードされず、ブラウザ上で表示された）

検証結果から分かったこと

inline はダウンロードダイアログが表示されず、ブラウザ画面で表示されるっぽい。

検証10：JPEG + attachment

最後に、同じJPEGを attachment にしてみる。

Content-Type: image/jpeg
Content-Disposition: attachment; filename="sample.jpg"

検証コード

case '/case10-attachment-jpg':
  sendJpeg(
    res,
    'attachment; filename="sample.jpg"'
  );
  break;

検証結果

Response Headersで以下になっていることを確認。

Content-Type: image/jpeg
Content-Disposition: attachment; filename="sample.jpg"

↓ ダウンロードダイアログが表示されることを確認。 ↓ 保存されたファイル名：sample.jpg

検証結果をまとめる

10個の検証を実施したら、最後に表で比較する。

No.	ファイル	Content-Disposition	Chromeの結果	保存ファイル名
1	TXT	なし	画面表示	-
2	TXT	`inline`	画面表示	-
3	TXT	`attachment`	ダウンロード	`case03-attachment-txt.txt`
4	TXT	`attachment; filename="sample.txt"`	ダウンロード	`sample.txt`
5	TXT	`attachment; filename="sample file.txt"`	ダウンロード	`sample file.txt`
6	TXT	`attachment; filename="日本語.txt"`	エラー (500)	-
7	TXT	`attachment; filename*`	ダウンロード	`日本語.txt`
8	TXT	`attachment; filename + filename*`	ダウンロード	`日本語.txt`
9	JPEG	`inline; filename="sample.jpg"`	画面表示	-
10	JPEG	`attachment; filename="sample.jpg"`	ダウンロード	`sample.jpg`

実際に調べて分かったこと

調べる前

最初は、

Content-Disposition は、ファイルをダウンロードさせるために必要なHTTPヘッダー

くらいの認識だった。

調べた後

調べてみると、Content-Disposition は「ファイルをダウンロードするためだけ」のものではなく、レスポンスを通常どおり扱うのか、添付ファイルとして扱うのかを示すための仕組みだと分かった。

また、filename や filename* を利用することで、保存時などに利用するファイル名についても伝えられる。

一方、Content-Type はデータのメディアタイプを示すためのもの。

そのため、

「Content-Type があるのに、なぜ Content-Disposition も必要なのか？」

という最初の疑問については、

そもそも役割が違うから

という理解になった。

注意点

今回の検証は、以下の環境で実施している。

Windows 11
Node.js v24.14.1
Google Chrome
Node.js標準のHTTPサーバー

そのため、今回のChromeで確認した結果を、そのまま「すべてのブラウザで同じ」と考えることはできない。

特にファイル名については、ブラウザや保存先のファイルシステムによって調整される場合がある。MDNでも、ブラウザがファイルシステム上の制約に合わせてファイル名を変換する場合があると説明されている。

また、Content-Disposition がなくてもブラウザがリソースを取得したり保存したりする場合がある。

今回調べて分からなかったこと

今回の記事ではChromeに絞って検証している。

そのため、次のような内容は今回の調査範囲外。

FirefoxやSafariでの挙動
<a download> を利用したダウンロードとの関係
複数ブラウザ間での filename / filename* の比較
Windows以外のファイルシステムでのファイル名処理
長すぎるファイル名の詳細な挙動

また時間あるときにでも、調査してみようかな、、、

まとめ

今回は、ファイルダウンロードを自作しているときに気になった Content-Disposition について調べた。

最初は、

「ファイルをダウンロードさせるために必要なヘッダー」

という認識だった。

しかし、調査と検証を通して、より正確には、

Content-Type はデータの種類を示す
Content-Disposition はコンテンツの扱い方を示す
inline は通常の表示として扱う指定
attachment は添付ファイルとして扱う指定
filename で保存時などに利用するファイル名を示せる
filename* で文字コードを指定できる形式でファイル名を示せる
filename と filename* を両方指定する方法もある

ということが分かった。

最初に疑問だった、

「Content-Type があるのに、なぜ Content-Disposition も必要なの？」

については、

Content-Type と Content-Disposition は、そもそも伝えている情報が違うから

という結論になった。

また、

「Content-Disposition がないとファイルをダウンロードできないの？」

については、単純に「必須」と考えるのではなく、実際のブラウザがレスポンスをどのように扱うかを確認する必要があるということも分かった。

参考資料

今回使用したGithubコード群 ::github{repo="ryo50/content-disposition-test"}

RFC 6266 - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)
RFC 8187 - Indicating Character Encoding and Language for HTTP Header Field Parameters
MDN - Content-Disposition header
Node.js v24 HTTP API Documentation

プロセス間通信（IPC）とは？「REST APIでよくない？」と思ったので調べてみた

Tue, 11 Aug 2026 00:00:00 GMT

プロセス間通信（IPC）とは？「REST APIでよくない？」と思ったので調べてみた

はじめに

Dockerについて調べている中で、マイクロサービスに関する話題を見ていたところ、「プロセス間通信（IPC）」という言葉が出てきた。
また、以前システム開発をしていたときにも、

プロセス間通信の方がセキュリティ面や速度面で有効

という話を聞いたことがある。
ただ、当時は「プロセス間通信」という言葉自体を深く理解していなかった。
特に気になったのが、

HTTP通信と何が違うの？

という部分だった。
REST APIならHTTPを使ってデータをやり取りできる。
実装方法も分かりやすく、利用しているシステムも多い。
それなら、

分かりづらいプロセス間通信をわざわざ使うメリットがそこまで多くないなら、REST APIでよくない？

と思った。
さらに調べていくと、

そもそもプロセスとは何なのか
プログラムとプロセスは何が違うのか
プロセス間通信では何を使っているのか
HTTP通信もプロセス間通信と言えるのではないか
ソケットとプロセス間通信は何が違うのか
パイプとは何なのか
共有メモリとは何なのか
なぜIPCは速度面やセキュリティ面で有効と言われるのか

など、いろいろな疑問が出てきた。

そこで今回はDockerの検証はいったん切り離し、まずはプロセス間通信（IPC）そのものについて調べてみる。

実際の検証では、Windows環境にNode.jsをインストールし、HTTP通信とWindowsのNamed Pipeを使った通信を比較する。

まず結論

今回の調査では、プロセス間通信（IPC）について、次のように整理できました。

HTTPは、127.0.0.1:3000のようなIPアドレスとTCPポートを使用し、HTTPプロトコルによって別プロセス間で通信する。
WindowsのNamed Pipeは、\\.\pipe\ipc-test のようなPipe名を使用し、TCP/IPやTCPポートを介さずに別プロセス間で通信できる。
今回の環境で10,000回の通信を実測したところ、Named PipeはHTTPより大幅に短い時間で処理できた。
HTTPは合計189,208.053ms（平均18.921ms）、Named Pipeは合計4,964.665ms（平均0.496ms）だった。
環境はWindows11 + CPU Intel(R) Core(TM) Ultra 7 265K + Node.js v24.14.1。

今回の測定では、Named Pipeの合計処理時間はHTTPの約2.63%、つまりHTTPより約97.4%短い時間で処理された。

ただし、これはあくまでWindows + Node.js v24.14.1 + 今回作成した実装・実行環境における測定結果。
通信方式の違いによる傾向を確認するための検証であり、すべての環境で同じ速度差になることを示すものではない。
そのため、この結果だけから「Named Pipeは常にHTTPより約38倍速い」と一般化することはできない。

また、最初に疑問に思っていた、

「REST APIでよくない？」

については、「同じPC上のプロセス間で高速な通信を行うこと」が目的なら、必ずしもREST APIを選ぶ必要はないという結論になった。 HTTP/REST APIは、ネットワーク越しの通信や、異なるシステム・言語・サービス間で通信する場合には扱いやすく、汎用性が高いというメリットがある。

一方、通信相手が同じWindowsマシン上のプロセスに限定されているのであれば、Named PipeのようなOSが提供するIPCを利用することで、HTTP/TCPを使わずにプロセス間通信を行える。今回の実測でも、HTTPより短い時間で通信を処理できた。

また、セキュリティ面では、Named Pipeへの接続にWindowsのユーザー権限が影響することも確認できた。
今回の検証では、Serverと同じ mainaccount からは接続できた一方、別ユーザーの ipc-test-user からは EPERM となり接続できなかった。
Node.js側で独自の認証処理を実装していなくても、Windows側のアクセス制御によって接続可否が判断されることを確認できた。

そのため、Named Pipeは単に「ローカル通信だから安全」と考えるのではなく、Windowsのユーザー権限やNamed Pipeのアクセス制御を考慮して利用する必要がある。

つまり、「REST APIでよいか」は通信相手と目的次第であり、同一マシン内のプロセス間通信だけが目的なら、Named PipeなどのIPCも有力な選択肢になる。
というのが、今回の検証から得られた結論。

プロセスとは？

プロセス間通信について調べる前に、そもそも「プロセス」とは何なのかを整理する。
自分の場合、調べる前は、

exeファイルなどのプログラムを実行したものがプロセス？

くらいの理解だった。
大きく間違ってはいないものの、「プログラム」と「プロセス」を同じものとして考えていた部分がある。

プログラムとプロセスの違い

プログラムは、コンピューター上で実行される命令やコードそのものを指す。
一方、プロセスは、プログラムが実行されている状態をOSが管理しているもの。

イメージとしては、

プログラム
   │
   │ 実行
   ▼
プロセス

となる。
同じプログラムであっても、複数回起動すれば複数のプロセスとして動作する場合がある。

例えば、

example.exe
    │
    ├─ 実行 → プロセスA
    │
    └─ 実行 → プロセスB

のような状態になる。
つまり、「プログラム」と「プロセス」は同じものではない。

プロセスとスレッドの違い

スレッドについては、

スレッドはプロセスの中で動くもの

という程度の理解だった。
基本的にはこの理解でよく、1つのプロセスの中で複数のスレッドが動作することがある。

プロセス
├─ スレッドA
├─ スレッドB
└─ スレッドC

プロセスとスレッドの大きな違いとして、プロセスは独立した実行単位として扱われ、プロセスごとに独立した仮想アドレス空間を持つ。
一方、同じプロセス内のスレッドは、プロセスが持つメモリ空間などを共有する。
この違いが、後述するプロセス間通信を理解するうえで重要になる。

なぜプロセス間通信が必要なのか？

プロセスごとにメモリ空間が分かれているのであれば、別のプロセスが持っているデータをどうやって利用するのだろうか。
例えば、

プロセスA                 プロセスB

┌──────────────┐        ┌──────────────┐
│ メモリ空間A   │        │ メモリ空間B   │
│              │        │              │
│ "Hello"      │        │              │
└──────────────┘        └──────────────┘

プロセスAが持っている "Hello" というデータを、プロセスBに渡したいとする。
プロセスAのメモリを、プロセスBが通常の変数のように直接読み取れるわけではない。
そこで、プロセス同士がデータをやり取りするための仕組みが必要になる。

それがプロセス間通信（IPC）。

プロセス間通信（IPC）とは？

IPCは「Inter-Process Communication」の略で、日本語では「プロセス間通信」と呼ばれる。
ここで最初に誤解していたのが、

IPCという名前の通信プロトコルが存在する

というイメージだった。
実際には、IPCは特定の1つのプロトコルを指す言葉ではない。

複数のプロセスがデータをやり取りするための仕組みを総称してIPCと呼ぶ。

Windowsの公式ドキュメントでも、IPCの方式としてパイプ、共有メモリ、RPCなど複数の方式が紹介されている。
代表的なものには、次のような方式がある。

方式	概要
パイプ	プロセス間でデータをストリームとして受け渡す
Named Pipe	名前を付けたパイプを使ってプロセス間で通信する
Unix Domain Socket	Unix系OSで同一マシン上のプロセス間通信などに利用される
共有メモリ	複数プロセスからアクセス可能なメモリ領域を利用する
メッセージキュー	メッセージをキューに入れてプロセス間で受け渡す
RPC	別プロセスの処理を呼び出すような形で通信する

つまり、

IPC
├─ パイプ
├─ Named Pipe
├─ Unix Domain Socket
├─ 共有メモリ
├─ メッセージキュー
└─ RPC

という関係になる。

パイプとは？

パイプは、プロセス間でデータを受け渡すための仕組み。
基本的には、一方のプロセスがデータを書き込み、もう一方のプロセスがデータを読み取る。

プロセスA
   │
   │ 書き込み
   ▼
┌──────────┐
│  パイプ   │
└──────────┘
   │
   │ 読み取り
   ▼
プロセスB

Windowsでは、匿名パイプとNamed Pipeが用意されている。
匿名パイプは、主に親プロセスと子プロセスなど、関連するプロセス間のデータ受け渡しに利用される。

一方、Named Pipeは名前を持つため、関連のないプロセス同士でも通信できる。Windowsでは同一コンピューター上だけでなく、ネットワーク越しの通信にも利用できる。
今回はWindows環境でのIPCを実際に試すため、Named Pipeを使用する。

ソケットとは？

ソケットは、プロセス同士がデータを送受信するための通信エンドポイントとして利用される。
ここで、

ソケット通信とプロセス間通信は何が違うの？

という疑問が出てきた。
調べてみると、ソケット自体はIPCだけに使われるものではない。

例えばTCPソケットでは、

Client
   │
   │ TCP/IP
   ▼
Server

のようにネットワークを介した通信ができる。

一方、Unix Domain Socketのように、同一OS上のプロセス間通信に利用されるソケットもある。
Node.jsの node:net でも、TCP用のソケットとIPC用のエンドポイントを扱うことができ、WindowsではIPCエンドポイントとしてNamed Pipeが使用される。そのため、

ソケット＝ IPC

ではない。
また、

IPC ＝特定の通信方式

でもない。
このあたりは、今回調べていて特に混乱しやすかった部分だった。

共有メモリとは？

共有メモリは、複数のプロセスからアクセスできるメモリ領域を利用するIPCの方式。
通常、プロセスごとに独立した仮想アドレス空間を持つ。

プロセスA                 プロセスB

┌──────────────┐        ┌──────────────┐
│ メモリ空間A   │        │ メモリ空間B   │
└──────────────┘        └──────────────┘

共有メモリでは、OSなどの仕組みによって複数のプロセスからアクセスできる共有領域を用意する。

プロセスA                 プロセスB
    │                         │
    │                         │
    └─────────┐   ┌───────────┘
              ▼   ▼
        ┌──────────────┐
        │   共有メモリ   │
        └──────────────┘

そのため、プロセス間で大量のデータをやり取りする場合などに利用される。
Windowsの現行ドキュメントでも、IPC方式の選択肢として共有メモリが挙げられており、大量データや高性能が必要なケースに適した方式として整理されている。

ただし、複数プロセスが同じ領域へアクセスするため、データの整合性を保つための同期処理なども考える必要がある。
今回はNode.jsでの共有メモリの詳細な検証は行わず、まずIPCの代表的な方式として理解するところまでにする。

REST APIでよくない？

ここが今回、一番気になったところだった。
自分は、

HTTPを使ったREST APIの方が分かりやすいし、わざわざIPCを使わなくてもいいのでは？

と思っていた。
例えばREST APIなら、

Node.js Client
      │
      │ HTTP Request
      ▼
Node.js Server
      │
      │ HTTP Response
      ▼
Node.js Client

という構成を簡単にイメージできる。
一方、IPCにはパイプや共有メモリなど複数の方式があり、それぞれ仕組みが異なる。
そこで、実際にHTTPとWindows Named PipeをNode.jsで作って比較してみることにした。

実際にHTTP通信を試してみる

検証環境

今回の検証では、以下の環境を使用します。

項目	環境
OS	Windows 11
実行環境	Node.js
Client	Node.js
Server	Node.js
通信方式	HTTP
プロセス	Client / Serverで別プロセス

今回はWSLやDockerは使用しない。(準備がちょっと大変なので、、、)

検証内容

Node.jsでHTTP Serverを作成し、別プロセスからClientを起動してリクエストを送信する。

Node.js Client
      │
      │ HTTP
      │ TCP/IP
      ▼
Node.js Server

Clientから、

GET /ping

を送信し、Serverからレスポンスを返す。

実装

onst server = http.createServer((req, res) => {
  console.log(`[HTTP Server] PID=${process.pid}`);
  console.log(`[HTTP Server] ${req.method} ${req.url}`);

  if (req.method === 'GET' && req.url === '/ping') {
    res.writeHead(200, {
      'Content-Type': 'application/json',
    });

    res.end(JSON.stringify({
      message: 'pong',
    }));

    return;
  }

  res.writeHead(404);
  res.end();
});

http/server.js (GitHub)

確認すること

ClientとServerが別プロセスであること

ServerのPID
ClientのPID
PIDが異なること

$ node client.js
=== HTTP Client ===
PID: 23304

$ node server.js
=== HTTP Server ===
PID: 28700

HTTP通信の接続先

IPアドレス
ポート番号
HTTPメソッド
URL

$ node client.js
=== HTTP Client ===
Target: http://127.0.0.1:3000/ping
Status: 200
Response: {"message":"pong"}

$ node server.js
=== HTTP Server ===
Address: http://127.0.0.1:3000
[HTTP Server] PID=28700
[HTTP Server] GET /ping

TCPを使用していること

ServerがTCPポートで待ち受けていること
Clientがそのポートへ接続していること

PS C:\Users\XXXXX> Get-NetTCPConnection -LocalPort 3000

LocalAddress                        LocalPort RemoteAddress                       RemotePort State       AppliedSetting
------------                        --------- -------------                       ---------- -----       --------------
127.0.0.1                           3000      0.0.0.0                             0          Listen

検証結果

【Server PID】: OK
【Client PID】: OK
【接続先】: OK
【HTTPレスポンス】:OK
【TCPポートの確認結果】:OK

Windows Named Pipeを試してみる

今回はUnix Domain Socketではなく、WindowsのNamed Pipeを使用する。
Node.jsの node:net は、WindowsではIPCエンドポイントとしてNamed Pipeを使用できる。Node.jsでは server.listen() や net.createConnection() にIPCのパスを指定できる。

検証内容

HTTPの検証とできるだけ同じ処理を、Named Pipeで実装する。

Node.js Client
      │
      │ Windows Named Pipe
      │ \\.\pipe\example
      ▼
Node.js Server

Clientからメッセージを送信し、Serverがレスポンスを返す。

実装

Server

const server = net.createServer((socket) => {
  console.log(`[Named Pipe Server] PID=${process.pid}`);
  console.log('[Named Pipe Server] Client connected');

  socket.on('data', (data) => {
    const message = data.toString();

    console.log(`[Named Pipe Server] Received: ${message}`);

    socket.write('OK');
  });

  socket.on('end', () => {
    console.log('[Named Pipe Server] Client disconnected');
  });

  socket.on('error', (error) => {
    console.error(
      '[Named Pipe Server] Socket error:',
      error.message
    );
  });
});

named-pipe/server.js (GitHub)

Client

const client = net.createConnection({
  path: PIPE_NAME,
});

client.on('connect', () => {
  console.log('[Named Pipe Client] Connected');

  client.write('Hello IPC');
});

client.on('data', (data) => {
  console.log(
    `[Named Pipe Client] Response: ${data.toString()}`
  );

  client.end();
});

client.on('end', () => {
  console.log('[Named Pipe Client] Disconnected');
});

named-pipe/server.js (GitHub)

確認すること

ClientとServerが別プロセスであること

Server PID
Client PID

$ node server.js
=== Windows Named Pipe Server ===
PID: 5264


$ node client.js
=== Windows Named Pipe Client ===
PID: 5612

通信先

HTTPでは、

127.0.0.1:3000

のようにIPアドレスとポート番号を指定した。
Named Pipeでは、

\\.\pipe\example

のようなPipe名を指定する。

$ node server.js
=== Windows Named Pipe Server ===
PID: 5264
Pipe: \\.\pipe\ipc-test
[Named Pipe Server] PID=5264
[Named Pipe Server] Client connected
[Named Pipe Server] Received: Hello IPC
[Named Pipe Server] Client disconnected


$ node client.js
=== Windows Named Pipe Client ===
PID: 5612
Pipe: \\.\pipe\ipc-test
[Named Pipe Client] Connected
[Named Pipe Client] Response: OK
[Named Pipe Client] Disconnected

TCPポートを使用していないこと

HTTPと比較して、

TCPポートを使用するか
IPアドレスを使用するか
Named Pipeをどのように指定するか

PS C:\Users\mainaccount> Get-NetTCPConnection -LocalPort 3000
Get-NetTCPConnection : プロパティ 'LocalPort' が '3000' の MSFT_NetTCPConnection オブジェクトが見つかりません。プロパテ
ィの値を確認してから再試行してください。
発生場所 行:1 文字:1
+ Get-NetTCPConnection -LocalPort 3000
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (3000:UInt16) [Get-NetTCPConnection], CimJobException
    + FullyQualifiedErrorId : CmdletizationQuery_NotFound_LocalPort,Get-NetTCPConnection


PS C:\Users\mainaccount> Get-ChildItem \\.\pipe\ | Where-Object {
>>     $_.Name -like "*ipc-test*"
>> }
    ディレクトリ: \\.\pipe
Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
------        1601/01/01      9:00              4 ipc-test

検証結果

【Server PID】:OK
【Client PID】:OK
【Named Pipeの名前】:OK
【通信結果】:OK
【TCPポート使用有無】:OK

HTTPとNamed Pipeを比較してみる

ここまでの検証結果を整理する。

観点	HTTP	Windows Named Pipe
プロセス	別プロセス	別プロセス
通信方式	HTTP	Named Pipe
IPアドレス	`127.0.0.1` を使用	使用しない
TCPポート	`3000` を使用	使用しない
TCP/IP	TCP/IPを使用	TCP/IPを使用しない
接続先	`http://127.0.0.1:3000/ping`	`\\.\pipe\ipc-test`
Node.jsでの実装	`node:http`	`node:net`
通信結果	HTTP GETを送信し、`{"message":"pong"}` を正常に受信	`Hello IPC` を送信し、`OK` を正常に受信

ここで、

HTTPとNamed Pipeは、どちらも別プロセス間でデータをやり取りしている

ことを確認する。
つまり、HTTPとIPCは必ずしも対立する概念ではない。
HTTPを使って別プロセスと通信すること自体も、広い意味ではプロセス間の通信に該当する。
今回比較しているのは、

HTTPというアプリケーション層の通信方式を利用する場合と、OSが提供するIPC機構であるNamed Pipeを利用する場合の違い

と考えた方が分かりやすそう。

セキュリティ面では何が違う？

最初に聞いた、

「プロセス間通信の方がセキュリティ面で有効」

という話についても確認する。
ここは単純に、

IPCだから安全

とは言えない。
Named PipeではWindowsのセキュリティ機構によってアクセスを制御できる。
Named Pipeにはセキュリティ記述子やACLを設定でき、Clientが接続する際にもアクセスチェックが行われる。
そのため、今回は以下を確認する。

確認すること

Named Pipeにアクセス制御を設定できるか
Windowsのユーザー権限と関係するか
権限によって接続できるかどうかが変わるか
認証なしでも接続できる状態があるか
ローカル専用として扱う場合に注意点があるか

検証結果

確認すること

Named Pipeにアクセス制御が設定されているか
Windowsのユーザー権限がNamed Pipeへの接続に影響するか
同じユーザーと別ユーザーで接続結果が変わるか
Node.js側で認証処理を実装していなくても接続できるか
Named Pipeをローカルプロセス間通信に利用する場合、どのようなセキュリティ上の注意が必要か

検証結果

① 同じユーザーからの接続

Named Pipe Serverを mainaccount で起動し、同じ mainaccount からClientを実行した。

Server User : mainaccount
Client User : mainaccount

Connection : SUCCESS
Response   : OK

Server側でもClientからの接続とデータ受信を確認できた。

=== Client Connected ===
Server PID : 20392
Received   : Hello Security Test
Client disconnected

この結果から、同一Windowsユーザーで起動したClientからNamed Pipeへ正常に接続できることを確認した。

② 別ユーザーからの接続

検証用にWindowsローカルユーザー ipc-test-user を作成し、runas を使用して別ユーザーのPowerShellを起動した。

whoami
→ owner\ipc-test-user

その状態で同じNamed PipeへClientから接続した。
結果は以下のとおりだった。

Connection : FAILED
Error      : EPERM
Message    : connect EPERM \\.\pipe\ipc-security-test

Server側では、別ユーザーからの接続時にClientの接続・データ受信は確認できなかった。
この結果から、今回の環境ではNamed Pipeへの接続時にWindowsユーザーの権限が影響し、mainaccount では接続できた一方、ipc-test-user では接続が拒否されたことを確認できた。

③ Windowsユーザー権限との関係

mainaccount と ipc-test-user のグループ情報を確認した。
mainaccount には、

BUILTIN\Administrators
BUILTIN\Users

などのグループが含まれていた。
一方、ipc-test-user は、

BUILTIN\Users

に所属しており、Administratorsグループには所属していなかった。
今回の検証では、

mainaccount
    ↓
Named Pipeへ接続
    ↓
成功

ipc-test-user
    ↓
Named Pipeへ接続
    ↓
EPERM
    ↓
失敗

という結果になった。

したがって、Named Pipeは単純に「Pipe名を知っていれば誰でも接続できる」という仕組みではなく、Windowsのアクセス制御の影響を受けることを確認できた。

ただし、今回の検証だけでは「Administratorsだから接続できた」とまでは断定できない。Named Pipe作成時にWindowsが設定する既定のセキュリティ記述子や、各ユーザー・グループに設定されたアクセス権など、複数の要因が関係しそう。

④ Node.js側の認証処理

今回のClientでは、

const client = net.createConnection({
  path: '\\\\.\\pipe\\ipc-security-test',
});

としており、ユーザー名やパスワードをNode.js側で送信する処理は実装していない。
それでも同一ユーザーでは接続でき、別ユーザーでは接続が拒否された。

このことから、今回の通信ではアプリケーション側で独自のユーザー認証を実装しなくても、Windows側のアクセス制御によってNamed Pipeへの接続可否が判断されていることを確認できた。

ただし、

「認証処理がない = セキュリティがない」

という意味ではない。

今回確認できたのは、アプリケーション独自の認証処理を実装していなくても、Windowsのユーザー・アクセス権を利用したアクセス制御が働いているということである。

⑤ セキュリティ上の注意点

今回の検証では、同一ユーザーからは接続でき、別ユーザーからは接続できなかった。

そのため、Windows上でNamed PipeをローカルIPCとして利用する場合でも、

Pipe名を知っているだけで接続できるとは限らない
Windowsユーザーやグループの権限が接続可否に影響する
アプリケーション側の認証処理とWindows側のアクセス制御は別の仕組み
「ローカル通信だから安全」と決めつけず、Named Pipeのアクセス権を確認する必要がある

という点に注意する必要がある。

特に、機密情報を扱うNamed Pipeや、特定のユーザー・サービスからだけ接続させたいNamed Pipeでは、Windowsのセキュリティ記述子やDACLを適切に設定する必要がある。

今回の検証結果まとめ

確認項目	結果
Named Pipeへの接続	成功
同一ユーザーからの接続	成功
別ユーザーからの接続	失敗（EPERM）
Windowsユーザー権限との関係	あり
Node.js側のユーザー認証	実装していない
Windows側のアクセス制御	接続結果に影響したことを確認
TCP/IP	使用していない
セキュリティ上の注意	Named Pipeのアクセス権を確認・適切に設定する必要がある

なお、Named Pipeはネットワーク越しにも利用できるため、「Named Pipeだから必ずローカル通信」というわけではない。

速度面では本当に速いのか？

もう一つ気になっていたのが、

「プロセス間通信の方が速度面で速い」

という話だった。
これについても、実際にHTTPとNamed Pipeで簡単な性能比較を行う。

検証条件

できるだけ条件を揃えて、

Client
  │
  │ "Hello IPC"
  ▼
Server
  │
  │ "OK"
  ▼
Client

という処理を繰り返す。

10,000回

の回数で測定する。

記録する値

項目	HTTP	Named Pipe
リクエスト数	10,000	10,000
送信データ	`GET /ping`	`Hello IPC`
合計時間	189,208.053 ms	4,964.665 ms
平均時間	18.921 ms	0.496 ms
成功件数	10,000	10,000
失敗件数	0	0

測定結果

今回の測定では、HTTPの合計時間が 189,208.053 ms、Named Pipeが 4,964.665 ms となった。

平均時間では、

HTTP：18.921 ms
Named Pipe：0.496 ms

となり、今回の測定条件ではNamed Pipeの方が短い時間で処理された。

合計時間を比較すると、Named PipeはHTTPの約 2.63% の時間で処理されており、HTTPと比較して約 97.4%短い時間 だった。

また、両方とも10,000件すべての通信に成功しており、失敗件数は0件だった。

注意点

今回の結果は、

Windows11 + CPU Intel(R) Core(TM) Ultra 7 265K + Node.js v24.14.1 + 今回の実装条件

で測定した結果。
この結果だけをもって、

「Named PipeはHTTPより必ず○倍速い」

と一般化することはしない。 OS、Node.jsのバージョン、送受信するデータサイズ、接続方法、同時実行数などによって結果が変わる可能性があるため。

また、今回のベンチマークでは、1回の通信ごとに接続して通信した後、切断する方式を採用している。そのため、通信そのものだけではなく、接続・切断にかかる処理時間も測定結果に含まれている。

したがって、今回の結果は、

「今回のWindows + Node.js v24.14.1環境で、同じマシン上のプロセス間通信を1回ごとの接続・切断方式で10,000回実行した場合、Named Pipeの方がHTTPより短時間で処理された」

という結果とする。

結局、REST APIでよくない？

今回の記事を書くきっかけになった疑問に戻る。
最初は、

「分かりづらいIPCを使うくらいならREST APIでよくない？」

と思っていた。しかし、調べていくと、そもそもIPCとREST APIを単純に二択で比較すること自体が適切ではないことが分かってきた。

IPCは、

プロセス同士が通信するための仕組み

を表す広い概念。

一方、REST APIは、

HTTPなどを利用してリソースを操作するためのAPI設計の考え方

そのため、

IPC
│
├─ Named Pipe
├─ Shared Memory
├─ Unix Domain Socket
└─ その他

と、

HTTP
│
└─ REST API

は、そもそも同じ分類ではない。

今回の検証から分かったこと

【IPCについて分かったこと】
【HTTPとNamed Pipeの違い】
【速度について分かったこと】
【セキュリティについて分かったこと】

REST APIを使えばよいケース

HTTP/REST APIは、通信相手や利用環境を限定せず、ネットワーク越しにサービスを利用させたい場合に向いている。

例えば、

ネットワーク越しに通信したい
他のシステムやサービスから利用したい
HTTPを利用できるクライアントからアクセスしたい
APIとして外部に公開したい
言語や実行環境が異なるシステムと連携したい

といったケースでは、HTTP/REST APIが扱いやすい選択肢になる。
特にHTTPは、多くのクライアントや開発ツールから利用でき、APIとして設計・公開しやすいことがメリット。

IPCを検討するケース

IPCは、同じコンピューター上で動作するプロセス同士を通信させたい場合に検討できる。
例えば、

同じPC上のアプリケーション間で通信したい
外部ネットワークからアクセスさせる必要がない
HTTP/TCPを使う必要がない
OSが提供するIPC機構を利用したい
プロセス間で高速なデータ交換を行いたい
Windows環境であればNamed Pipeを利用したい

といったケース。今回の検証では、Windows Named Pipeを使用することでTCP/IPを介さずにプロセス間通信ができ、今回の測定条件ではHTTPより短い時間で処理できることを確認した。
Windowsの公式ドキュメントでも、Named Pipeはストリーム型の双方向通信、共有メモリは大量データ・高性能用途など、IPC方式ごとに適した用途が整理されている。

今回はDockerの検証をしない理由

今回、IPCについて調べるきっかけになったのはDockerやマイクロサービスだった。

ただし、Dockerまで含めると、

コンテナ
IPC namespace
ネットワーク
コンテナ間通信
Unix Domain Socket
DockerのIPC設定

など、別の話題が増えるのでまた後日。

とりあえず

IPCとは何なのか？

を理解することを目的とする。
今回の記事で新たに出てきた、

Dockerコンテナ同士ではIPCをどうやって行うのか？

という疑問は、次の記事のテーマにでもする。

次に調べたいこと

今回の調査から、さらに次の疑問が出てきた。

Dockerコンテナ間でもIPCは利用できるのか？
コンテナごとにIPCは分離されるのか？
DockerでNamed PipeやUnix Domain Socketは利用できるのか？
IPC namespaceとは何を分離しているのか？
コンテナ間で共有メモリを利用できるのか？

このあたりは、実際にDockerコンテナを作って検証してみたいと思う。

まとめ

今回は、Dockerやマイクロサービスを調べている中で気になった「プロセス間通信（IPC）」について調べた。

最初は、

「REST APIでよくない？」

と思っていた。

しかし、調べてみるとIPCは特定の通信プロトコルを指す言葉ではなく、プロセス同士がデータをやり取りするための仕組みをまとめた言葉だと分かった。

また、WindowsではNamed Pipeを利用したIPCをNode.jsから実装できる。

今回の検証では、HTTPとNamed Pipeを実際に動かして、通信方法や接続先、TCP/IPの利用などの違いを確認した。

今回分かったこと

【IPCとは何か】
【プロセスとプログラムの違い】
【HTTPとIPCの関係】
【Named Pipeの仕組み】
【セキュリティ面の違い】
【速度面の検証結果】

最初の疑問だった「REST APIでよくない？」についても、必ずしもREST APIでなくても良いと勉強になった。次回は今回の調査で残った疑問をもとに、DockerコンテナにおけるIPCについて実際に検証してみる。

参考資料

今回使用したGithubコード群 ::github{repo="ryo50/ipc-test"}

Web3とは何なのか？Web2との違いから開発現場での活用方法まで整理する

Sat, 01 Aug 2026 00:00:00 GMT

Web3とは何なのか？Web2との違いから開発現場での活用方法まで整理する

Web3という言葉を聞く機会がかなり増えてきました。

以前は「暗号資産やNFTの話」というイメージが強かったですが、最近ではゲーム、金融、デジタルコンテンツなど、さまざまな分野でWeb3というキーワードが出てくるようになっています。

ただ、エンジニア目線で見ると少し悩む部分があります。

「結局、Web3を使うと何が嬉しいのか」「既存システムをブロックチェーンに置き換える意味はあるのか」

このあたりは、技術記事を読んでも少し分かりづらいところがあります。

技術としては面白い一方で、実際のシステム開発では「どこに使うべきか」を判断することの方が重要になりそうです。

今回はWeb3について、単なる用語整理ではなく、仕組みや技術要素を整理しながら、実際の開発で考えるポイントもまとめてみます。

Web3はブロックチェーンを使えば成立するのか問題

Web3と聞くと、まずブロックチェーンを思い浮かべる人が多いと思います。

実際、ブロックチェーンはWeb3を支える重要な技術です。

ただし、「ブロックチェーンを使ったサービス = Web3」というわけではありません。

ここは少し混同されやすいポイントです。

Web3で重要になる考え方は、サービス内のデータや価値を「特定企業だけが管理する状態」から変えていくことです。

少し簡単に言うと、

「サービスを提供している会社だけがデータを持つ」

という形から、

「ユーザー自身もデータや価値を管理できる」

という方向を目指す考え方です。

Web2とWeb3の違い

まずは全体像を整理します。

Web2の一般的な構成

現在多く利用されているWebサービスは、Web2型の構成が中心です。

例えばSNSの場合、以下のような構成になります。

ユーザー
   |
   v
Webサービス
   |
   v
企業が管理するデータベース

ユーザーはサービスを利用しますが、以下のような情報はサービス提供企業が管理しています。

アカウント情報
投稿データ
利用履歴
サービスルール

この形は現在のWebサービスでは一般的です。

メリットとしては、運営側がサービス改善しやすく、ユーザーも簡単に利用できます。

一方で、サービス終了や仕様変更が発生した場合、ユーザー側ではコントロールできません。

Web3の考え方

Web3では、ユーザー自身がウォレットを持ち、デジタル資産や所有情報を管理します。

イメージとしては以下のような構成です。

ユーザー
   |
   v
ウォレット
   |
   v
ブロックチェーン
   |
   v
スマートコントラクト

例えばゲームアイテムの場合、従来はゲーム会社のデータベース上に存在していました。

Web3では、アイテムの所有情報をブロックチェーン上で管理し、ユーザー自身が所有できる仕組みを作れます。

ただし、ここで注意したいのは「所有できる = 必ず価値がある」というわけではない点です。

ユーザーにとって本当に必要な仕組みなのかを考える必要があります。

Web3を構成する主な技術要素

Web3は1つの技術ではありません。

複数の技術を組み合わせた考え方です。

代表的なものは以下です。

ブロックチェーン
ウォレット
スマートコントラクト
NFT
DAO

それぞれ役割が異なります。

ブロックチェーンとは何か

ブロックチェーンは、複数の参加者で同じデータを管理する仕組みです。

通常のWebサービスでは、企業が管理するデータベースに情報を保存します。

例えば、

アプリ
 |
 v
データベース

というシンプルな構成です。

一方、ブロックチェーンでは複数のコンピューター（ノード）が同じ取引履歴を保持します。

そのため、特定の管理者だけが自由にデータを書き換えることが難しくなります。

メリット

データ改ざんへの耐性がある
取引履歴を確認できる
複数組織間で同じ情報を共有しやすい

デメリット

大量データ処理には向かない場合がある
通常のDBより処理速度が遅いケースがある
データ削除が難しい

利用するケース

暗号資産
デジタル資産管理
取引履歴管理
複数企業間の情報共有

個人的なデータ管理や社内システムでは、無理にブロックチェーンを利用する必要がないケースも多いです。

スマートコントラクトとは何か

スマートコントラクトは、ブロックチェーン上で動作するプログラムです。

簡単に言うと、「条件を満たしたら自動的に処理する仕組み」です。

例えば、

支払いが完了したら権利を移転する
条件を満たしたらNFTを発行する
投票結果に応じて処理する

といったことができます。

EthereumではSolidityという言語を使って開発するケースが多いようです。

例：

contract Payment {
    function transfer(address receiver) public payable {
        payable(receiver).transfer(msg.value);
    }
}

上記は簡略化した送金処理の例です。

実際の開発では、資産管理や権利管理など、より複雑な処理を実装します。

スマートコントラクトのメリット・デメリット

スマートコントラクトは、従来は人や企業が仲介していた処理をプログラムで自動化できる点が特徴です。

ただし、便利な反面、通常のWebアプリケーションとは違う難しさがあります。

メリット

仲介処理を減らせる
ルールをコードとして公開できる
条件に応じた自動処理ができる
実行履歴を確認できる

例えば、ゲーム内アイテムの所有権移転や、デジタルコンテンツの販売処理などで活用できます。

デメリット

バグ修正が難しい
セキュリティ問題の影響が大きい
開発難易度が高い
処理内容によっては手数料が発生する

通常のWebアプリケーションの場合、問題が発生したら修正版をリリースできます。

しかし、スマートコントラクトでは公開後の変更が難しいケースがあります。

そのため、設計段階でのレビューやテストがかなり重要になります。

「とりあえず作って後から直す」という開発スタイルとは相性が悪い技術です。

NFTは画像販売の技術なのか問題

NFTという言葉を聞くと、デジタルアート販売をイメージする人が多いと思います。

実際、一時期はNFTアートが大きな話題になりました。

ただ、NFTの本質は「画像を売る技術」ではありません。

NFTは、デジタルデータに対して「これは誰が所有しているものなのか」を管理する仕組みです。

例えば、以下のような利用方法があります。

ゲームアイテム
デジタル会員証
イベントチケット
修了証や証明書
コレクションアイテム

メリット

所有履歴を管理できる
二次流通の仕組みを作れる
デジタル資産として扱える

例えばゲームの場合、ユーザーが入手したアイテムを別のユーザーへ譲渡するような仕組みを作れます。

従来のゲームでは、アイテムは基本的にゲーム運営会社のデータベース上の情報でした。

NFTを利用すると、ユーザー自身が所有するデジタル資産として扱う設計も可能になります。

デメリット

NFT自体が価値を保証するわけではない
法律上の所有権とは別に考える必要がある
ユーザー体験が複雑になりやすい

ここはゲーム開発などでは特に注意したいポイントです。

「アイテムをNFT化すればユーザーが喜ぶ」という単純な話ではありません。

ユーザーにとって、

本当に売買したいのか
所有するメリットがあるのか
ウォレット管理を許容できるのか

を考える必要があります。

DAOとは何か

DAO（Decentralized Autonomous Organization）は、中央管理者を置かずに運営する組織形態です。

日本語では「分散型自律組織」と呼ばれます。

従来の組織では、管理者が意思決定する形が一般的です。

管理者
 |
 v
メンバー
 |
 v
意思決定

一方、DAOでは参加者による投票やルールによって運営する仕組みを目指します。

参加者
 |
 v
投票・ルール
 |
 v
スマートコントラクト

メリット

意思決定プロセスを透明化できる
世界中から参加できる
参加者主体のサービス運営ができる

デメリット

意思決定に時間がかかる場合がある
法的な整理が難しいケースがある
参加者間の合意形成が必要

DAOは面白い考え方ですが、すべてのサービスに向いているわけではありません。

例えば企業サービスの場合、迅速な意思決定が必要な場面では従来型の組織運営の方が適しているケースがあります。

Web3を採用する前に考えるポイント

Web3関連の技術を見ると、「新しい技術だから使ってみたい」と感じることがあります。

ただ、システム開発では技術を採用する理由が重要です。

個人的には、以下のような順番で考えるのが良いと思っています。

解決したい課題
        |
        v
Web3で解決できるか
        |
        v
ブロックチェーンが必要か
        |
        v
具体的な技術選択

いきなり「NFTを使う」「ブロックチェーンを導入する」から考えると、目的と手段が逆になりやすいです。

実務ではWeb3をどう使うのか

実際の開発現場では、サービス全体をWeb3化するケースはそこまで多くありません。

多くの場合、一部の機能で活用できるかを検討します。

例えば以下のようなケースです。

デジタル資産を扱うサービス

ゲームアイテムやデジタルコンテンツなど、ユーザーが所有すること自体に価値がある場合です。

この場合、NFTやウォレットの仕組みが候補になります。

ただし、ゲームの場合は注意が必要です。

すべてのデータをオンチェーン化すると、

処理速度
コスト
運用負荷

が問題になる可能性があります。

そのため、

所有権だけブロックチェーン管理
ゲーム内ステータスは通常DB管理

のような構成も考えられます。

複数企業でデータ共有するサービス

複数企業が関わる場合、1社だけがデータを管理すると信頼性の問題が発生することがあります。

例えば、

取引履歴
証明情報
所有履歴

などです。

このような「誰か1社を完全には信用できない」という状況では、ブロックチェーンのメリットが出やすくなります。

ユーザー参加型サービス

ユーザーがサービス運営や意思決定に関わるサービスでは、DAO的な考え方が活用される場合があります。

例えば、

コミュニティ運営
ファン参加型サービス
共同プロジェクト

などです。

ただし、投票システムを作ればDAOになるわけではありません。

参加者が継続的に関わる仕組みや、価値提供の設計が重要になります。

Web3が向いていないケース

Web3は新しい技術ですが、すべてのシステムに適しているわけではありません。

むしろ、従来型のWebシステムの方が良いケースも多くあります。

社内業務システム

社内だけで利用するシステムでは、基本的に管理者が明確です。

例えば、

社員情報管理
売上管理
業務ワークフロー

などです。

このようなシステムでは、通常のデータベースやクラウドサービスを利用した方が、開発や運用はシンプルになります。

「分散管理する必要があるのか」を考えることが重要です。

高速な大量データ処理

ブロックチェーンは、データの信頼性や透明性を重視する仕組みです。

そのため、

大量ログ解析
リアルタイム集計
大規模検索

のような処理は、一般的なデータ基盤の方が向いています。

例えば、アクセスログを毎秒大量に保存するようなシステムを、すべてブロックチェーンで管理するメリットはあまりありません。

頻繁なデータ変更が必要なサービス

ブロックチェーンは「履歴を残す」ことが得意です。

逆に、

データ更新が多い
削除が必要
管理者が頻繁に修正する

ようなシステムでは扱いづらい場合があります。

Web3開発で注意するポイント

Web3関連の開発では、通常のWebアプリケーションとは違った注意点があります。

特に設計段階で考えておきたいポイントを整理します。

秘密鍵管理

Web3サービスでは、秘密鍵の管理が非常に重要です。

一般的なWebサービスでは、パスワードを忘れた場合に再設定できます。

しかし、ウォレットの秘密鍵を失った場合、資産やデータへアクセスできなくなる可能性があります。

これはWeb2サービスとの大きな違いです。

そのため、ユーザー向けサービスでは以下のような設計が必要になります。

ウォレット作成フロー
秘密鍵バックアップ方法
復旧方法
ユーザーへの説明

技術的には安全でも、ユーザーが利用できないサービスになってしまう可能性があります。

ガス代によるユーザー体験への影響

ブロックチェーンでは、処理ごとに手数料が発生する場合があります。

Ethereumなどでは、この手数料をGas代と呼びます。

例えばゲームで、

「アイテムを取得するたびにユーザーが手数料を払う」

という設計にすると、ユーザー体験が悪くなる可能性があります。

そのため、以下のような工夫を行うケースがあります。

企業側が手数料を負担する
Layer2を利用する
重要な処理だけオンチェーン化する
一部データをオフチェーン管理する

すべての処理をブロックチェーン上で実行する必要はありません。

どこまでブロックチェーンで管理するかが設計ポイントになります。

セキュリティ

スマートコントラクトの脆弱性は、大きな問題につながる可能性があります。

通常のWebアプリケーションでは、サーバー側で問題を修正できます。

しかし、スマートコントラクトでは公開後の変更が難しい場合があります。

確認ポイントとしては以下があります。

権限管理
入力値チェック
外部コントラクト呼び出し
署名処理
監査体制

特に資産を扱う場合は、通常のアプリケーション以上に慎重なレビューが必要になります。

個人的には

個人的には、Web3は「既存のWebサービスを全部置き換える技術」というより、「今まで扱いづらかった所有権や信頼性をサービスに組み込むための選択肢」という位置付けが近いと思っています。

例えば、一般的な会員管理システムをブロックチェーン化しても、メリットは分かりづらいです。

むしろ、

開発コストが増える
運用が複雑になる
担当者の学習コストが増える

といった問題が出る可能性があります。

一方で、

このアイテムは誰のものなのか
この証明情報は正しいのか
複数企業で同じ情報を信用できる形で共有したい

という課題では、Web3の考え方が活きる場面があると思います。

個人的には、Web3を採用するかどうかは「新しい技術だから使う」ではなく、「分散管理する価値が本当にあるか」で判断するのが良さそうです。

まとめ

今回はWeb3について整理しました。

ポイントをまとめると以下です。

Web3はブロックチェーンを中心とした分散型サービスの考え方
ブロックチェーン、スマートコントラクト、NFT、DAOなど複数技術で構成される
重要なのはWeb3化することではなく、分散管理するメリットがあるか判断すること
NFTやDAOは用途によって有効なケースと向いていないケースがある
実際の開発では、UXやセキュリティを含めた設計が重要になる

Web3はまだ発展途中の技術領域です。

すべてのシステムに必要なものではありませんが、所有権や信頼性が重要になるサービスでは、今後も選択肢の1つになっていくと思います。

WCAG（Web Content Accessibility Guidelines）とは？

Thu, 23 Jul 2026 00:00:00 GMT

Webサイト開発をしていると、アクセシビリティについて気にしないといけないことが増えてくる。その中で観点として意識できていなかった**WCAG（Web Content Accessibility Guidelines）**について今回はまとめる。

WCAGとは？

WCAG（Web Content Accessibility Guidelines）は、Webコンテンツを誰でも利用しやすくするためのガイドラインである。

高齢者や障害のある方だけではなく、一時的にマウスが使えない人や、スマートフォンで閲覧している人など、さまざまな利用者が快適にWebサイトを利用できることを目的としている。

WCAGは以下の4つの原則（POUR）で構成されている。

知覚可能（Perceivable） 利用者が情報を認識できる状態にすること。

例

画像には代替テキスト（alt）を設定する
文字と背景のコントラストを十分に確保する

操作可能（Operable） 利用者がWebサイトを操作できる状態にすること。

例

キーボードのみで操作できる
制限時間がある場合は延長できる

理解可能（Understandable） 利用者が内容や操作方法を理解できること。

例

わかりやすい文章で記載する
入力エラーの内容や解決方法を表示する

堅牢（Robust） さまざまなブラウザや支援技術でも利用できること。

例

HTMLを正しく記述する
スクリーンリーダーで読み取れるマークアップを行う

適合レベルって？

WCAGには達成レベルが3段階存在する。

レベル	内容
A	最低限満たすべき要件
AA	一般的に目標となるレベル
AAA	非常に高いアクセシビリティを実現するレベル

実際のWebサイトではAAレベルを目標とするケースが多いみたい。

WCAGの利点は何なのか？

より多くの人が利用できるサイトになる

障害の有無に関係なく、多くの利用者が快適にWebサイトを利用できるようになる。

ユーザー体験（UX）が向上する

アクセシビリティ向上のための改善は、結果としてすべての利用者にとって使いやすいサイトにつながる。

例えば、

ボタンが押しやすい
見出し構造が分かりやすい
エラー内容が理解しやすい

といった改善は、アクセシビリティだけではなくUX向上にもつながる。

SEOにも良い影響がある

適切なHTML構造や画像の代替テキストは、検索エンジンがページ内容を理解しやすくなるため、SEOにも良い影響を与えることがある。(明示はされていなさそうだった)

WCAGは対応しないとダメ？

すべてのWebサイトでWCAGへの対応が義務付けられているわけではない。ただし、官公庁や自治体、多くの大企業では、WCAGを基準としたアクセシビリティ対応が行われているのが現状。

WCAGは、W3C（World Wide Web Consortium）が策定しているWebアクセシビリティの国際的なガイドラインであり、日本でもJIS X 8341-3の基となっている。そのため、特に企業サイトや公共機関のWebサイトでは、WCAG AAを目標として設計・実装されることが多い。

また、海外ではアクセシビリティに関する法整備が進んでおり、グローバルにサービスを展開する企業ではWCAGへの対応が求められるケースが多い。個人開発や小規模なWebサイトでは必須となることは少ないが、アクセシビリティを考慮したサイトは利用者にとって使いやすく、結果としてユーザー体験（UX）の向上にもつながる。そのため、必須ではなくても、Web開発を行うのであれば認識しておかないといけない。

ちなみに、もしグローバルなサービスの場合はアメリカ：ADA EU：European Accessibility Act 等があるので把握しておく必要あり。

WCAGの注意点

WCAGは、チェック項目を満たせば終わりというものではない。

例えば色のコントラストを満たしていても、実際には読みにくかったり、操作しづらかったりする場合がある(実体験)。そのため、ガイドラインを満たすことだけではなく、実際の利用者が使いやすいかどうかを意識して設計・実装することが重要。

また、WCAGは定期的に改訂されており、2026年7月現在はWCAG 2.2が公開されている。案件によって対象バージョンや適合レベルが異なるため、WCAG順守の様な依頼があるなら事前に確認しておいた方がよさげ

当ブログ（Storia's Blog）で意識したアクセシビリティ実践例

そもそも、Astroテンプレートを使っているので意識している箇所はないのだが、lighthouseでチェックしたところいくつか指摘されたので、その辺りを対応した。

ダークモード時のコントラスト比 ダークモード適用時、テキストカラーと背景色のコントラスト比が足りず可読性が落ちる箇所があったため、CSS変数（HSL指定）を微調整しました。
キーボードによる回遊（Focus Ring） Tabキーでヘッダーナビゲーションや記事カードを移動した際、現在どこにフォーカスがあるかが一目で分かるよう focus-visible スタイルを明示的に付与しています。
ライトハウス（Lighthouse）でのチェック 定期的にChrome DevToolsのLighthouseを実行し、Accessibilityスコアが90点以上をキープできるようマークアップ（aria-labelの付与など）を意識しています。

また、ノンデザイナーズ・デザインブックは個人的に、色に関しての意識が変わったのでお勧め。
ノンデザイナーズ・デザインブック

まとめ

WCAGは、誰もが利用しやすいWebサイトを作るためのガイドライン。基本となる考え方は以下の4つ。

知覚可能（Perceivable）
操作可能（Operable）
理解可能（Understandable）
堅牢（Robust）

アクセシビリティというと障害者向けの対応というイメージを持ちやすいが、実際にはすべての利用者にとって使いやすいWebサイトを作るための考え方でもある。個人的にはAAレベルを目標としておけば、最低限イケてるサイトが作れそう。

メダリオンアーキテクチャについて

Wed, 22 Jul 2026 00:00:00 GMT

Databricksやデータ分析基盤でよく耳にする「メダリオンアーキテクチャ」。なぜ分けるのかが曖昧だったので勉強も兼ねて整理してみる。

メダリオンアーキテクチャとは？

メダリオンアーキテクチャ（Medallion Architecture）は、データの品質を段階的に向上させながら管理するための設計パターン。生データをいきなり分析に利用するのではなく、

Raw Data → 整形済みデータ → 業務利用データ

という流れでデータを加工していく。一般的には以下の3層で構成される。

1. Bronze（ブロンズ）

データをそのまま保存する層。 CSVやAPI、ログなど取得したデータを可能な限り加工せず保存する。目的は「元データを残すこと」。万が一加工処理に問題があっても、このデータから再作成できる。

例

API取得データ
CSVファイル
ログデータ
CDCデータ

2. Silver（シルバー）

分析で利用できる品質までデータを整える層。ここではデータクレンジングや形式統一などを行う。

例

NULL値の補正
重複データの削除
データ型の統一
テーブル同士の結合

多くの分析や機械学習では、このSilver層を利用することが多い。「クレンジング」と一言で言っているが、マハラノビス距離/Zスコア/IQR法/LOF/k-NNなどなど方法が様々なようなので、別記事でまとめる。

3. Gold（ゴールド）

業務で直接利用するデータを作る層。 BIツールやダッシュボード、レポートで参照されるデータを配置する。

例

月別売上
KPI
顧客別売上
商品ランキング

利用者がSQLを書くことなく利用できる状態まで加工されていることが多い。

なぜ3層に分けるの？

一番の目的はデータ品質を段階的に向上させること。

例えばSilverで誤った変換をしてしまった場合でも、Bronzeには元データが残っているため再作成できる。また、Silverを共通データとして利用することで、複数の分析やAIモデルで同じデータを再利用できる。結果として

データ品質の向上
保守性の向上
デバッグのしやすさ
データの再利用

といったメリットがある。

注意点

メダリオンアーキテクチャは設計パターンであり、物理構成を決めるものではない。ただし、メダリオンを意識せずに漠然とデータを分けてしまうと

どれが正式データかわからない
不要データが残る
ガバナンスが低下する

といった問題も発生する。そのため、各レイヤーや用途ごとの責務を明確にすることが重要になる。

まとめ

メダリオンアーキテクチャは、データ品質を段階的に向上させるための設計パターン。

Bronze：生データを保持する
Silver：分析しやすい形へ整形する
Gold：業務利用向けに加工する

という役割を持つ。「3層構成」そのものではなく、「データ品質を段階的に高める考え方」として理解するとイメージしやすいかも。ただ、どうしてもSilverとGoldの境界があいまいな気がしてならない。。。 (GoldからGold作ったりとかはないのかなぁとか思ったり)

実データを見てみないとイメージが沸かない部分もあるので、いつか公開されてる大量データからDatabricksの試用期間枠で実際に分けてみようと思う。

AIML案件では実際に何をやっているのか？

Sun, 12 Jul 2026 00:00:00 GMT

最近案件を探していると、「AIML案件」という単語が目に付くようになってきた。「AIML案件」と聞いても、具体的な作業内容が全然思いつかなかったので実際のAIML案件でどのような業務を行っているのかを調べて自分なりにまとめてみた。

AIML案件とは？

AIML案件とは、AI（Artificial Intelligence）や機械学習（Machine Learning）を活用したシステムやデータ基盤を構築・運用するプロジェクトのこと。

AIで使用するデータを収集したり加工したりする。ただし、AIモデルを開発するメンバーだけで案件が成り立つわけではなさげ

実際には、

学習データの生成・活用
データ基盤
データ連携
権限管理
モデル実行環境
AIアプリケーション

など、多くのシステムが組み合わさって構成されている。そのため、一般的なシステム開発と同じように、設計・実装・テスト・運用のような業務が存在する。

自分なりの理解だが、主に以下に分けられる気がする。

1. データ基盤の構築

AIが利用するデータを管理するための基盤を構築する。

例えば、

データの保存先を作成する
データを登録する仕組みを作る
データを安全に利用できるようにする

といった作業がある。 AIの精度以前に、データを正しく管理できることが重要になる。

2. 権限管理

AIML案件では、多くの部署が同じデータ基盤を利用する。

そのため、

誰が閲覧できるか
誰が更新できるか
AIモデルだけが利用できるデータは何か

などを管理する仕組みが必要になる。権限設計はセキュリティにも直結するため、重要な業務の一つ。

3. 学習データの生成・活用

AIモデルは、学習に使用するデータの品質によって性能が大きく左右される。そのため、AIML案件では学習データを準備する作業も重要な業務の一つとなる。

具体的には、

必要なデータの収集
不要なデータや重複データの除去
データ形式の統一
ラベル付け（アノテーション）
学習用・検証用・評価用データへの分割

などを行う。

また、生成AIを活用する案件では、社内文書やマニュアル、FAQなどを整理し、AIが活用しやすい形へ加工する作業を行うこともあるそう。 AIモデルはアルゴリズムだけで性能が決まるわけではなく、学習データの品質が結果に大きく影響するようなので、学習データの作成・整備はAIMLの根幹になっている。

4. データ連携

AIMLは一つのシステムだけで完結することは少ない。

そのため、

S3
データベース
他システム

などと連携しながらデータを受け渡す仕組みを作成する。データの流れを設計することも重要そう。

5. 運用設計

AIが関わるとはいえ、システムは作って終わりではない。

ログ取得
エラー監視
障害対応
権限変更
データ削除

など、運用を考慮した設計も必要になる。

AIML案件でよく使われる技術

比較的よく利用されてそうなものは、

Python
SQL
Apache Spark
Databricks
AWS
Azure

などがある。 AIよりもクラウドやデータ基盤の知識やデータの収集を求められる場面も多い。

AIモデルを作る仕事ばかりではない

AIML案件というと、データサイエンティストがAIモデルを開発しているイメージが強い。しかし実際には、そのモデルを動かすための環境やデータ基盤を開発するエンジニアを求められている場合もある。

データが正しく管理され、必要な人だけがアクセスでき、安定してAIモデルを実行できる環境があって初めて、AIは業務で活用できる。そのため、バックエンド開発やインフラ構築の経験もAIML案件では十分に活かすことができそう。

実務視点での所感：モデル構築よりも「データ基盤と権限設計」の難易度が高い

AIML案件を調べる中で特に感じたのは、AIモデルのアルゴリズム選定以上に「マルチテナント/部署間でのデータ権限管理」や「DWH（Databricks/Snowflakeなど）の構築・CI/CD」がプロジェクトの成否を分けるという点。

従来のシステム開発では「特定DBテーブルのCRUD権限」で済んでいたものが、AIMLでは「特徴量データ」「学習済みモデルのバージョン」「検証用データセット」それぞれにきめ細やかなアクセス制御が求められる。バックエンドエンジニアやインフラエンジニアとしての経験（AWS IAMやOpenShift等のアクセス制御、TerraformによるIaC）は、AIML領域でも極めて強い武器になると実感したし、プラスでAIMLの知識も合わせていないと要件を理解することができないと感じた。

まとめ

AIML案件では、AIモデルを開発するだけではなく、

データ基盤の構築
データ連携
権限管理
API開発
運用設計

といった業務も多く存在する。 AIそのもの以外にも「AIを安全かつ継続的に利用できる環境を作る」という点が必要なことを考えてなかった。

もちろん、LLMについての知識や、DWH、特徴量の出し方などなどデータサイエンティストの知識があると案件上強いのは言わずもがなだが、上記以外にもインフラレイヤーや権限回りの経験などは役立ちそうだった。

デシリアライズ時にはstaticが無視される話

Fri, 15 May 2026 00:00:00 GMT

Javaでシリアライズ/デシリアライズを扱っている時に
「staticな値が復元されていない？」となったのでまとめ。

シリアライズとデシリアライズとは？

まず前提として、シリアライズとデシリアライズは以下。

シリアライズ
オブジェクトを保存や通信できる形式に変換すること。
デシリアライズ
保存されたデータからオブジェクトを復元すること。

JavaではSerializableを実装することでシリアライズ可能になる。

import java.io.Serializable;

public class User implements Serializable {
    private String name;

    public User(String name) {
        this.name = name;
    }
}

staticはシリアライズ対象外

本記事のメイン。
staticはクラスに属する値であり、
インスタンスに属する値ではない。

そのため、シリアライズ時に保存されない。

import java.io.*;

class User implements Serializable {
    static String company = "OpenAI";

    String name;

    User(String name) {
        this.name = name;
    }
}

public class Main {
    public static void main(String[] args) throws Exception {

        User user = new User("Taro");

        // シリアライズ
        ObjectOutputStream out =
            new ObjectOutputStream(new FileOutputStream("user.dat"));
        out.writeObject(user);
        out.close();

        // staticの値を変更
        User.company = "Google";

        // デシリアライズ
        ObjectInputStream in =
            new ObjectInputStream(new FileInputStream("user.dat"));

        User loadedUser = (User) in.readObject();
        in.close();

        System.out.println(loadedUser.name);
        System.out.println(User.company);
    }
}

実行結果

Taro
Google

シリアライズ時にはcompany = "OpenAI"だったが
デシリアライズ後はGoogleになっている。

これはstaticが保存されていないため。

なぜstaticは保存されない？

staticはインスタンスごとの値ではなく、
クラス全体で共有される値。

つまり、シリアライズ対象の「オブジェクトの状態」には含まれない。

イメージとしては以下。

インスタンス変数  -> オブジェクトごとのデータ
static変数       -> クラス共通のデータ

Javaのシリアライズは
「インスタンスの状態」を保存する仕組みのため
staticは対象外になる。

transientとの違い

staticのシリアライズと似た話としてtransientがある。

transientはインスタンス変数だが
「シリアライズ対象から除外する」ためのもの。

class User implements Serializable {

    String name;

    transient String password;
}

違いとしては以下。

種類	シリアライズ対象
static	対象外
transient	明示的に対象外
通常フィールド	対象

注意点

staticに設定値などを保持している場合、
デシリアライズ時に想定外の値になっている可能性がある。

特に以下は注意。

キャッシュ
設定情報
シングルトン管理
staticカウンタ

「保存されて復元される」と思っているとハマりやすい。

まとめ

Javaのシリアライズでは
staticはインスタンスに属する値ではないため保存されない。

そのため、デシリアライズ時には
現在のクラス側のstatic値がそのまま使用される。

シリアライズ対象にしたい値は
staticではなく通常フィールドとして保持する必要がある。

シリアライズ（直列化）とは？

Fri, 15 May 2026 00:00:00 GMT

「Serializableを実装してね。」
「シリアライズすると保存できます。」

Javaを書いているとよく見るが
そもそもシリアライズとは何なのかを整理してみる。

シリアライズとは？

シリアライズ（Serialize）は、
オブジェクトの状態を保存・送信できる形に変換すること。

逆に、保存されたデータから
オブジェクトを復元することをデシリアライズという。

Javaでは以下のようにSerializableを実装すると
シリアライズ可能になる。

import java.io.Serializable;

public class User implements Serializable {

    private String name;

    public User(String name) {
        this.name = name;
    }
}

なぜシリアライズが必要？

シリアライズとは？みたいな形で調べると、よく上記のような説明を受けるが
保存するとき・送信するときもバイナリになるんじゃないの？
と疑問だったので深掘ってみた。

Javaのオブジェクトは
基本的にメモリ上にしか存在しない。

User user = new User("Taro");

このuserはプログラム終了時に消える。

また、そのままでは別PCに送信もできない。

なぜなら、オブジェクトは単なる「メモリ上の構造」(アドレス、ポインタ等)であり
そのままでは保存や通信に適した形ではないため。

そのため、

ファイルに保存できる形
通信できる形

に変換する必要がある。
それがシリアライズ。

オブジェクトってバイナリじゃないの？

ここが混乱しやすいポイントだった。

確かにオブジェクトはメモリ上ではバイナリとして存在している。

ただし、そのまま 保存・送信 はできない。

理由としては以下。

メモリ上のデータはそのまま使えない

例えば以下のオブジェクト。

User user = new User("Taro");

メモリ上では、

クラス情報
メモリアドレス
JVM内部情報
参照情報

なども含めた形で保持されている。

つまり、

このメモリの0x123456にnameがある

のような状態。

しかし、

別PC
次回起動時
別JVM

ではメモリアドレスが変わる。

つまり、メモリ上の状態をそのままコピーしても
復元できない。

そのため、

User
 └ name = "Taro"

のように
「オブジェクトの状態だけ」を取り出して
保存可能な形式へ変換する必要がある。

これがシリアライズ。

シリアライズの用途

よくある用途は以下。

1. ファイル保存

オブジェクトの状態をファイルへ保存できる。

個人的にイメージしやすかったのはゲームのセーブデータ。

Player
 ├ HP = 100
 ├ Level = 10
 └ Items = [...]

を保存しておけば、
次回起動時に復元できる。

2. 通信

オブジェクトを別コンピュータへ送信できる。

例えばAPI通信やSocket通信。

Client → Userオブジェクト送信 → Server

のようなことを行う際、
通信可能なデータ形式へ変換する必要がある。

3. キャッシュ

ここは私的にはイメージがなかった。
Redisなどへオブジェクトを保存する際にも使われる模様。

メモリ上のJavaオブジェクトは
そのままRedisへ置けないためシリアライズ化して保存するようになっている。

Javaではどう保存される？

Java標準のシリアライズでは
バイナリ形式で保存される。

ObjectOutputStream out =
    new ObjectOutputStream(
        new FileOutputStream("sample.dat"));

out.writeObject(user);

保存された.datファイルを開くと
読めないバイナリデータになっている。

JSONとの違い

ファイルで保存と言えば、JSONに変換もするような… と思ったので調べてみた。

最近はJava標準シリアライズより
JSON変換のほうがよく使われる模様。

例えば以下。

{
  "name": "Taro"
}

JSONも広い意味では
「オブジェクトを保存・通信可能な形へ変換している」ため
シリアライズの一種とのこと。

ただし、

Java標準シリアライズ
→ Java専用のバイナリ形式
JSON
→ 人間が読めるテキスト形式

という違いがある。

注意点

Java標準シリアライズは便利だが
以下の問題もある。

クラス変更に弱い
Java依存
セキュリティ事故の原因になりやすい

そのため、最近は

JSON
Protocol Buffers
MessagePack

などを使うことも多い模様。

まとめ

シリアライズとは
オブジェクトを保存・通信可能な形式へ変換すること。

オブジェクトはメモリ上ではバイナリだが、
そのままでは

メモリアドレス
JVM依存情報

などを含むため
保存や通信には使えない。

そのため、
「オブジェクトの状態のみ」を取り出して
保存できる形式へ変換する必要がある。

ゲームのセーブデータや
ネットワーク通信などで利用される重要な仕組み。

HTMLのChunkについて

Wed, 18 Jun 2025 00:00:00 GMT

前提

HTTP/1.1では使用されるが HTTP/2以降のプロトコルでは廃止されているので注意

そもそもChunk転送(チャンク転送)とは何者?

Chunk転送は、HTTP/1.1で導入されたデータ転送方式のひとつ。サーバーがレスポンスのコンテンツ長を事前に決定できない場合や、ストリーミングデータのように順次データを送りたい場合に使われるもの。

ChatGPTの返答がリアルタイムに返ってくる動作だったり動画ストリーミングに利用されている。

なぜにChunk転送の概念がでてきたのか

通常、HTTPレスポンスのヘッダにはContent-Lengthが含まれる。
これにより、ブラウザやクライアントはレスポンスボディの終了位置を知ることができる。

しかし、以下のような場合にContent-Lengthを指定するのが難しい。

動的に生成されるコンテンツ(ChatGPTとか)
ストリーミング形式でのレスポンス(動画系)

このようなケースで使用されるのがチャンク転送エンコーディング。

`Content-Length`でも実装できないか

疑問に感じた、そもそもChunkedが出てくる前はContent-Lengthで何とかなってたはずでポーリング等で再現できそうだが、何が駄目なのかを調べてみた

Chunk転送が来る前のストリーミング

ストリーミングではなくプログレッシブダウンロードを行っていた Content-Length は付与するけど、実際の再生は受信しながら再生になるキャッシュとして端末に動画をダウンロードしながらダウンロードが終わった個所から再生していく形

プログレッシブではだめなの？

プログレッシブダウンロードはストリーミングと違い、一時ファイルが保存される形になるので著作権面で注意する必要があるまた、動画として事前にファイルが用意できないライブ配信には不向きな点があった

そのため、ストリーミング配信が最近は主流になっている

Chunk転送が来る前の動的に生成されるコンテンツ(チャットなど)

ポーリング
ロングポーリング
定期的リロード

を活用して処理をトリガーすることで生成されるコンテンツを読み込んでいた

それぞれ簡単にまとめるとポーリング：クライアント側で定期的に処理を実行し(10秒ごと等)新着があるかサーバーに問い合わせる

ロングポーリング：リクエストされた後に処理が更新されるまでレスポンスを返さない、クライアントはレスポンスされたらすぐにリクエストをして待機

定期的リロード：ページをリロードしてコンテンツを再取得する
といった形で処理をトリガーしていた

ポーリング等ではだめなの？

いつ新着のコンテンツが発生するか分からないため定期的 or 待機をする必要があり、無駄な処理が嵩む事になるまた、ロングポーリングに至っては接続が発生しっぱなしになるため、コネクションとしても効率が悪い

そのため、プロトコル的にも「イベント単位のプッシュ」に最適化されているチャンク転送の方が使い勝手がよい

Chunkedが出る前(HTTP/1.0とか)のKeep-Aliveは何だったのか？

HTTP/1.0や初期のHTTP/1.1では、一応「コネクションを閉じない」設定（Keep-Alive）だけはあったただし、レスポンス自体は最初にContent-Lengthが必要で、ストリーミング的な更新は無理だった

チャンク転送の仕組み

チャンク転送では、以下のようにデータを**チャンク（塊）**に分けて送信しているサーバーがレスポンスを小分けにして送るようなイメージ

HTTP/1.1 200 OK  
Transfer-Encoding: chunked  
...
各チャンクの先頭にチャンクサイズ（16進数）を記載
チャンクサイズの後に改行（CRLF）
チャンクのデータ本体
チャンクの末尾にも改行（CRLF）
...

チャンク転送の終わりは、サイズ0のチャンクを送信することで終わりを示す

SSE

チャンク転送を使用した技術にSSEという通信方法があるサーバー → クライアント（ブラウザ）にイベント形式のデータをストリーミングできる仕組み text/event-stream というMIMEタイプのレスポンスで実現する JavaScriptのEventSourceで簡単に受信できるようになっている

例えば

const source = new EventSource('/sample');
source.onmessage = (event) => console.log(event.data);

上記のコードを書くことで、/sampleから送られてくるレスポンスをイベントとして発火できるようになる

WebSocket

似たような仕組みに、WebSocketがあるただ、似たような事を行っているように見えるが結構別物なので注意こちらはWebSocketプロトコルで動作するのでHTTPではない HTTPの仕組みと違い、双方向で通信ができることが特徴チャット・ゲーム・株価などの双方向、対話的な通信に特化している

HTTPリクエストスマグリング

Chunkedを知るうえで有名な攻撃手法として HTTPリクエストスマグリングと呼ばれる攻撃手法ががあったので調べてみた

そもそもHTTPリクエストスマグリングとは何か？

サーバーやプロキシ（リバースプロキシ、ロードバランサー）間で、 HTTPリクエストの解釈に差があることを突く攻撃のこと

たとえば、同じリクエストをサーバーは「チャンク転送」と解釈するが、プロキシはContent-Length優先で解釈するなどの違いを利用する攻撃

POST / HTTP/1.1
Host: sample.com
Content-Length: 10
Transfer-Encoding: chunked

0

GET /sample HTTP/1.1
Host: sample.com

上記の場合プロキシはContent-Length: 10を信じてリクエストを終了するしかしバックエンドサーバーはチャンク転送として扱いその後のGET /adminを別のリクエストとして解釈してしまう

違いを利用することで

バックエンドに不正リクエストを送り込める
セッション乗っ取り・キャッシュポイズニングなどを誘発するを狙う攻撃手法の一つ

どうすればよいのか、、、？

対策として

リクエストの曖昧なヘッダ（Content-LengthとTransfer-Encodingの併用など）を許可しない
Webサーバーやリバースプロキシの設定を最新化し、既知の脆弱性に対応する
脆弱性スキャナ（Burp Suite など）でHTTPリクエストスマグリングを検査する等がある

まとめ

Chunk転送(チャンク転送)はHTTP/1.1から使用できる Transfer-Encoding: chunkedのヘッダーを付ける事で使用できる動的コンテンツやストリーミングレスポンスに使うもの HTTP/2ではチャンク転送は廃止されている(ストリームとフレームという概念が存在)

オートボクシングについて

Tue, 29 Oct 2024 00:00:00 GMT

オートボクシングとは

プリミティブ型（int、double、booleanなど）を対応するラッパークラス（Integer、Double、Booleanなど）に自動的に変換する機能のこと。逆に、ラッパークラスをプリミティブ型に自動変換することをアンボクシング（unboxing）と呼ぶ。オートボクシングはコードの可読性を向上させるために使ったりするが、パフォーマンス面で注意が必要。

パフォーマンスへの影響

色々調べた感じだと以下の点でパフォーマンスへの影響がありそう。

追加のオブジェクト生成

オートボクシングではプリミティブ型をラッパークラスに変換する際、追加のオブジェクトが生成される模様。

例えば、intがIntegerに変換されると、新しいIntegerオブジェクトが作られる場合がある。^1 もちろんオブジェクト生成にはメモリと処理時間がかかる。頻繁にボクシングが発生する（特に大量のデータを処理する）場合、 GC（ガーベッジコレクション）の負荷が増え、パフォーマンスに影響しそう。

アンボクシングのパフォーマンスコスト

オートボクシングが絡むと、アンボクシングも発生することになる。例えば、Integerをintに変換する際には、ラッパークラスからプリミティブ型に値を取り出す処理が必要になる。上記処理も追加のコストを生むため、パフォーマンスに影響を与えることになる。

特にループ内でボクシングしている場合やコレクション(List<Integer>やMap<Integer, Integer>)のようにラッパークラスで定義を使用している場合、頻繁にボクシングとアンボクシングが発生する可能性が高くなるのでパフォーマンスコストがかかる。

この範囲内の数値であれば、新しいオブジェクトを生成せずに既存のオブジェクトを再利用される模様。しかし、それ以外の値では新たなIntegerオブジェクトが生成される。

実際に確認してみた

どのくらい違うのか気になったので確認してみた。 openjdk version "18.0.2.1" 2022-08-18

public static void main(String[] args) {
    final int EXECUTE_COUNT = 10;
    for (int i = 0; i < EXECUTE_COUNT; i++) {
        System.out.println("Execute count: " + i);
        execute();
    }
}

private static void execute(){
    final int LOOP_COUNT = 100_000_000;

    // オートボクシングを使わないケース
    long startTime = System.nanoTime();
    long sumPrimitive = 0;
    for (int i = 0; i < LOOP_COUNT; i++) {
        sumPrimitive += i;  // プリミティブ型のみ
    }
    long endTime = System.nanoTime();
    System.out.println("Without Autoboxing: " + (endTime - startTime) / 1_000_000 + " ms");

    // オートボクシングを使ったケース
    startTime = System.nanoTime();
    Long sumBoxed = 0L;  // ラッパークラス(Long)
    for (int i = 0; i < LOOP_COUNT; i++) {
        sumBoxed += i;  // オートボクシング
    }
    endTime = System.nanoTime();
    System.out.println("With Autoboxing: " + (endTime - startTime) / 1_000_000 + " ms");
}

Execute count: 0
Without Autoboxing: 41 ms
With Autoboxing: 355 ms
Execute count: 1
Without Autoboxing: 42 ms
With Autoboxing: 347 ms
Execute count: 2
Without Autoboxing: 41 ms
With Autoboxing: 350 ms
Execute count: 3
Without Autoboxing: 40 ms
With Autoboxing: 351 ms
Execute count: 4
Without Autoboxing: 40 ms
With Autoboxing: 352 ms
Execute count: 5
Without Autoboxing: 42 ms
With Autoboxing: 346 ms
Execute count: 6
Without Autoboxing: 42 ms
With Autoboxing: 348 ms
Execute count: 7
Without Autoboxing: 41 ms
With Autoboxing: 355 ms
Execute count: 8
Without Autoboxing: 40 ms
With Autoboxing: 350 ms
Execute count: 9
Without Autoboxing: 40 ms
With Autoboxing: 356 ms

差はかなりありそうだが、そもそも気にするほどパフォーマンスに問題でるような時間はかからなさそう。ただし、ちりつもで遅くなることはありそうな気配。

パフォーマンスを良くするためには

プリミティブ型の使用

そもそも可能であれば、不必要なラッパークラスを使わないことでオートボクシングを発生させない。例えば、Integerを使わずにintを使うことで、不要なオブジェクト生成を防ぐ。

キャッシュの活用

^1に記載したが、扱う数値が-128から127の範囲内であればオートボクシングによるパフォーマンス低下はあまり発生しない。もし、キャッシュ範囲外で値の範囲が定まっているオートボクシングが発生するのであれば以下のJVMオプションをつける事でもパフォーマンス向上が期待できる。 -XX:AutoBoxCacheMax ただし、上記値を大きくすればするほど常時メモリを喰う量が大きくなるので注意が必要。

なんでラッパークラスがあるのか

そもそもプリミティブ型のみであれば、オートボクシングが発生する余地がないのでは？となったのでどうしてラッパークラスがあるのか調べてみた。

コレクションに格納するため

Javaのコレクション（List、Set、Mapなど）やジェネリクスは、オブジェクトを要素として格納することが前提となっているのでプリミティブ型を直接格納することはできない。そのため、例えばList<int>のようにプリミティブ型を直接使えない代わりに、 List<Integer>とすることでプリミティブ型の値もコレクションに格納できるようになる。プリミティブ型のままで集合を扱う場合は、配列のみになる。

プリミティブ型にはないメソッドが利用できる

ラッパークラスには、プリミティブ型の値を操作するための便利なメソッドが提供されている。例えば、IntegerクラスにはparseIntメソッドがあり、文字列を整数に変換することができたりする。

nullの利用

プリミティブ型はnullを許容しないが、ラッパークラスはオブジェクトであるためnullを保持できる。これにより、「値が設定されていない」や「未初期化」という状態を表現することができる。データベースやJSONなどの外部からデータを受け取る場面で、「値が存在しない」場合をnullで表現することがたまにあったりする。ただし、一長一短でプリミティブで扱っていれば気にしなくて済むnullが入ってくるので booleanなどは選択肢がtrue、falseだけでなくnullも考慮に入れる必要が出てくる。

まとめ

パフォーマンスが劇的に悪くなることはないが、 nullの選択肢が入ってくるラッパークラスが良い場面と悪い場面がある。

意識して使い分けることは必須ではないが、出来れば意識して使い分けていきたいところ。

参考

ボクシングのキャッシュについて凄い詳しく書かれているサイト https://medium.com/programmingmitra-com/java-integer-cache-why-integer-valueof-127-integer-valueof-127-is-true-e5076824a3d5

Javaのprotectedについて

Tue, 06 Aug 2024 00:00:00 GMT

継承を説明する時に大体出てくるprotectedについて人に説明をしようとした時に、実はあまり理解できてなかったのでまとめ。

protectedとは？

Javaのprotectedは、クラスのメンバー（フィールドやメソッド）のアクセス制御を行うために使用するもの。 protectedが付けられたメンバーは、次の場合にアクセスできる。

同じパッケージ内のクラス： 同じパッケージに属するクラスからアクセスできる。
サブクラス（継承関係）： 継承しているクラスからアクセスできる。サブクラスが異なるパッケージに存在していても、継承しているクラスであればアクセスできる。

package com.example;

public class Parent {
    protected void display() {
        System.out.println("protectedのメソッド");
    }
}

/* -------------------- */
package com.example;

public class Child extends Parent {
    public void show() {
        display();  // protectedの対象と同じパッケージ内なのでアクセス可能
    }
}

/* -------------------- */
package com.another;
import com.example.Parent;

public class AnotherChild extends Parent {
    public void show() {
        display();  // 異なるパッケージでも継承関係があるのでアクセス可能
    }
}

/* -------------------- */
package com.another;
import com.example.Parent;

public class AnotherClass {
    public void show() {
        Parent parent = new Parent();
        parent.display();  // 異なるパッケージかつ、継承関係でもないのでアクセス不可
    }
}

protectedの利点は何？

親クラスのデータやメソッドをprotectedにすることで、サブクラスに対して適切な範囲でのみアクセスを許可し、外部から意図しない変更がされなくなる。
継承関係にあるクラスで、親クラスのprotectedメンバーを再利用することで、コードの重複を避けて保守しやすいコードがかける。サブクラスは親クラスのprotectedメンバーにアクセスできるので親クラスの機能を拡張しやすい。

protectedの注意点

protectedは別パッケージに対してはprivateだが同一パッケージに関してはpublicのためクラスの内部実装が広範囲に公開される可能性がある。継承しかさせないつもりでクラスを作ったとしても同一パッケージのクラスからはすべて読み込めてしまうのでパッケージの作り方を気にしつつ、必要最小限の範囲で使用することがよい。

まとめ

protectedは同じパッケージに属するクラスか継承しているクラスからアクセスできる。使用箇所としては継承関係が多めな認識。継承で再利用でき別パッケージであれば意図しないアクセスが拒否できる点がメリットそう。

Javaのequalsと==について

Wed, 03 Jul 2024 00:00:00 GMT

今更ながら、きちんと説明できるだけ深堀したことなかったのでまとめ。

そもそも`==`演算子とは？

基本データ型（プリミティブ型）に対して使う場合、その値を比較する。参照型（オブジェクト型）に対して使う場合、そのオブジェクトの参照:メモリアドレスを比較します。

//プリミティブ型の比較
int a = 5;
int b = 5;
System.out.println(a == b); // true（プリミティブかつ値が同じだから）

//オブジェクト型の比較
String str1 = new String("Hello");
String str2 = new String("Hello");
System.out.println(str1 == str2); // false（異なるオブジェクトだから）

`equals`メソッドとは？

オブジェクトの内容を比較するために使われる。 Objectクラスのデフォルトでは、以下のコードになっている。

//Java:21
public boolean equals(Object obj) {
    return (this == obj);
}

特にStringクラスでは、equalsメソッドがオーバーライドされていて文字列が同じかどうかを比較するように実装されている。

//Java:21
public boolean equals(Object anObject) {
    if (this == anObject) {
        return true;
    }
    return (anObject instanceof String aString)
            && (!COMPACT_STRINGS || this.coder == aString.coder)
            && StringLatin1.equals(value, aString.value);
}

自分でクラスを作成する場合、 equalsをオーバーライドして比較する内容を決めてあげる必要がある。

なぜStringに対して`==`を使ってはいけないのか？

よく入門書とかに書かれているString型の時にJavaでは==を使ってはいけないお話。 Stringクラスに対して==を使うと、オブジェクトの参照を比較することになる。つまり、文字列の内容が同じであっても異なるオブジェクトとして作成された場合、 ==はfalseを返してしまう。

String str1 = new String("Hello");
String str2 = new String("Hello");
//中身が同じなのに、、、
System.out.println(str1 == str2); // false

特にStringに関して、書き方によっては文字列リテラルがプールされるため^1 プールされている参照が割当たった時は比較結果が上記と逆になる。

//文字列リテラルをプールして参照した場合
String str1 = "Hello";
String str2 = "Hello";
System.out.println(str1 == str2); // true（同じリテラルを参照しているため）

//オブジェクトとしてそれぞれ定義した場合
String str3 = new String("Hello");
String str4 = new String("Hello");
System.out.println(str3 == str4); // false（異なるオブジェクトだから）

この挙動の違いが期待した結果と異なることが多いためバグの原因となる。

正しい文字列比較の方法

文字列の内容を比較する場合は、必ずequalsメソッドを使用すること。正しく把握して使う分にはよいかと思うが、==にするメリットが思いつかないので Stringはequalsを使うこととして覚えてしまった方がよさげ。 (もちろん、理由はキチンと把握しておいた方がよいが、、、)

文字列はメモリ効率化のため特定の方法で作成するとメモリの特殊な場所に文字列を保存する。その後、同じ文字列を作成する場合、別の場所にメモリを確保するのではなく既にある文字列の場所を参照するようにメモリを持つイメージ

JavaのfindFirstとfindAnyの違い

Fri, 07 Jun 2024 00:00:00 GMT

あまり使うことのなかったfindFirstとfindAnyを調べたのでメモ

findFirstとは

findFirstメソッドは、Streamから最初の要素を返すために使用される。 順序付けされている状態であれば、findFirstは常に最初の要素を返す。

List<String> names = Arrays.asList("Test1", "Test2", "Test3", "Test4");
Optional<String> firstName = names.stream().findFirst();
firstName.ifPresent(System.out::println); //→Test1

findAnyとは

findAnyメソッドは、ストリームから任意の要素を返す。特に並列でストリームを回しているときに性能が良くなるらしい。。。

List<String> names = Arrays.asList("Alice", "Bob", "Charlie", "David");
Optional<String> anyName = names.parallelStream().findAny();
anyName.ifPresent(System.out::println);

findAnyいつ使うの？

性能的に考えてもfindFirstで最初が返されるのであれば感覚的にfindFirstの方が速そう、、、

なので試してみた。

前提

parallelStream自体がマルチコアプロセッサを活かして動く形なので以降の処理結果は CPUに依存する。 XeonなどのマルチコアゴリゴリのCPU等であれば処理結果変わらない可能性がある。

parallelStreamでのfindFirstとfindAnyの比較

import java.util.*;
import java.util.stream.*;

public class Main {
    public static void main(String[] args) {
        for(int i = 1; i < 11; i++){
            execute(i);
        }
    }
    
    
    private static void execute(int index){
        System.out.println(index + "回目");

        List<Integer> largeList = IntStream.range(0, 1000000).boxed().collect(Collectors.toList());

        // findFirstの計測
        long startTime1 = System.nanoTime();
        Optional<Integer> first = largeList.parallelStream().findFirst();
        long endTime1 = System.nanoTime();
        System.out.println("findFirst took :" + (endTime1 - startTime1) + " ns");

        // findAnyの計測
        long startTime2 = System.nanoTime();
        Optional<Integer> any = largeList.parallelStream().findAny();
        long endTime2 = System.nanoTime();
        System.out.println("findAny took   :" + (endTime2 - startTime2) + " ns");
    }
}

1回目
findFirst took :533346 ns
findAny took   :76237 ns
2回目
findFirst took :349193 ns
findAny took   :70898 ns
3回目
findFirst took :163967 ns
findAny took   :100547 ns
4回目
findFirst took :140695 ns
findAny took   :106406 ns
5回目
findFirst took :146328 ns
findAny took   :74622 ns
6回目
findFirst took :293930 ns
findAny took   :95320 ns
7回目
findFirst took :141319 ns
findAny took   :51707 ns
8回目
findFirst took :147466 ns
findAny took   :63520 ns
9回目
findFirst took :138300 ns
findAny took   :283056 ns
10回目
findFirst took :163080 ns
findAny took   :91353 ns

同じように要素を少なく(10個)にしてみた結果

1回目
findFirst took :132483 ns
findAny took   :58254 ns
2回目
findFirst took :112732 ns
findAny took   :53424 ns
3回目
findFirst took :108216 ns
findAny took   :73001 ns
4回目
findFirst took :118181 ns
findAny took   :52879 ns
5回目
findFirst took :117647 ns
findAny took   :51617 ns
6回目
findFirst took :124880 ns
findAny took   :63088 ns
7回目
findFirst took :126601 ns
findAny took   :60481 ns
8回目
findFirst took :124372 ns
findAny took   :59836 ns
9回目
findFirst took :120962 ns
findAny took   :50714 ns
10回目
findFirst took :107710 ns
findAny took   :51197 ns

parallelStreamでのfindFirstとfindAnyの結果

結果的にはparallelStream同士ではfindFirstの方がかなり速かった。

parallelStreamとstreamの場合で比べてみたらどうなるのか気になったので試してみた。

parallelStreamとStreamでのfindFirstとfindAnyの比較

import java.util.*;
import java.util.stream.*;

public class Main {
    public static void main(String[] args) {
        for(int i = 1; i < 11; i++){
            execute(i);
        }
    }
    
    
    private static void execute(int index){
        System.out.println(index + "回目");

        List<Integer> largeList = IntStream.range(0, 100000).boxed().collect(Collectors.toList());

        // findFirstの計測
        long startTime1 = System.nanoTime();
        Optional<Integer> first = largeList.stream().findFirst();
        long endTime1 = System.nanoTime();
        System.out.println("findFirst took :" + (endTime1 - startTime1) + " ns");

        // findAnyの計測
        long startTime2 = System.nanoTime();
        Optional<Integer> any = largeList.parallelStream().findAny();
        long endTime2 = System.nanoTime();
        System.out.println("findAny took   :" + (endTime2 - startTime2) + " ns");
    }
}

1回目
findFirst took :16188 ns
findAny took   :85091 ns
2回目
findFirst took :15263 ns
findAny took   :77307 ns
3回目
findFirst took :15275 ns
findAny took   :108210 ns
4回目
findFirst took :11231 ns
findAny took   :62859 ns
5回目
findFirst took :11406 ns
findAny took   :60593 ns
6回目
findFirst took :11201 ns
findAny took   :60128 ns
7回目
findFirst took :11290 ns
findAny took   :59533 ns
8回目
findFirst took :17196 ns
findAny took   :1116963 ns
9回目
findFirst took :15139 ns
findAny took   :77320 ns
10回目
findFirst took :16299 ns
findAny took   :80137 ns

こちらも同じように要素を少なく(10個)してみた結果

1回目
findFirst took :11960 ns
findAny took   :65212 ns
2回目
findFirst took :10200 ns
findAny took   :61745 ns
3回目
findFirst took :8921 ns
findAny took   :55540 ns
4回目
findFirst took :8800 ns
findAny took   :53469 ns
5回目
findFirst took :8788 ns
findAny took   :54545 ns
6回目
findFirst took :10299 ns
findAny took   :54831 ns
7回目
findFirst took :9144 ns
findAny took   :57409 ns
8回目
findFirst took :8523 ns
findAny took   :52583 ns
9回目
findFirst took :8659 ns
findAny took   :53152 ns
10回目
findFirst took :9056 ns
findAny took   :58739 ns

parallelStreamとstreamでのfindFirstとfindAnyの結果

結果的には、Streamにした状態のfindFirstが速かった。

まとめ

parallelStreamを使用する場合はfindAny streamで良い場合は、findFirstの方がよさげ。

ただ、parallelStreamが必要なレベルの重たい処理を行ったことがないため、 parallelStreamでfindFirstの方がよい場合もあるのかも

HTMLのscriptタグを書く位置について

Thu, 06 Jun 2024 00:00:00 GMT

普段HTMLを書かないと忘れていくので備忘録もかねて

scriptタグどこに記載すればよいか問題

HTMLでscriptを記載できる位置がいくつかあり、どこに書けばよいか分からなくなるのでそれぞれ書く位置と問題点を記載していく

scriptタグを記載できる位置

HTMLドキュメントでは、<script>タグを以下の場所に記載することができる。

<head>タグ内：

<head>
    <script src="./index.js"></script>
</head>

ここに記載すると、HTMLの解析前にスクリプトが読み込まれて実行される。 bodyでのDOM解析より前に走るため、ページのレンダリングがブロックされることがある。特に外部リソースが多い場合やスクリプトが重い場合、ページの表示が遅れる原因となる。

<body>タグ内の適切な場所：

<body>の最初：

<body>
    <script src="./index.js"></script>
    <!-- ページのコンテンツ -->
</body>

<body>の最初にスクリプトを配置すると <head>内に配置した場合と同様に、レンダリングがブロックされる可能性がある。 <head>の時と同じく、スクリプトが重い場合はページの表示が遅れる原因となる。

<body>の終わり：

<body>
    <!-- ページのコンテンツ -->
    <script src="./index.js"></script>
</body>

bodyでのDOM解析より前に走るため、HTMLの解析とページのレンダリングが完了してからスクリプトが実行されることになる。ページを開いたときに描画が先にされるため、ユーザーから見たときにページ表示速度が早い。

`<body>`タグの最後尾に書くのが最適なのか？

描画を第一に考えるのであれば、<body>タグの終わりに書くことが推奨されてる。

ただしDOMが描画される前に行いたい処理などがある場合 <head>タグ内で初期化処理を記載した方が、読み込み順序等を気にする必要がなくなるためあえて<head>に記載する方法も良さそう。

例えば

ページ初期化系：ページロード前に特定の初期化を行う必要がある場合。
重要な設定系：ユーザー認証やアクセス制御、グローバル設定の適用など、ページ全体に影響を与えたい処理。
スタイルやレイアウトの調整系：ページロード後にレイアウトが崩れるのを防ぐために、事前にスタイルを適用する場合。上記のような処理は、<head>タグ内に配置するのが良さそう。

個人的に以前行ってたのは以下みたいな処理 (他にもいろいろやり方はあるはずだが一例として、、、)

<head>
    <script>
        // 認証状態
        let authenticated = false;
        // 認証関連の初期化処理....
    </script>
    <script src="./script.js"></script>
</head>

気を付けないといけない点として、DOMが解析される前に処理を行っているため DOM関連の操作はここでは行えない。

`<head>`タグにスクリプトを記載しつつ描画を先に行いたい

<body>の最後に記載する方法が良いとはいえ、外部のスクリプトなどは<head>にあった方が何を使用しているか分かりやすかったりする。

HTML5以上であればそんなときに使えるdefer属性がある。 defer属性を使用すると、スクリプトはHTMLの解析が完了する(正確にはDOMContentLoadedイベント直前)まで実行を遅延する。また、外部スクリプト等の場合ダウンロードが発生するがダウンロードもDOMの解析と非同期で処理が行われるため、描画に対するブロッキングが発生しない。

遅延読み込み（defer属性）：

<head>
    <script src="./index.js" defer></script>
</head>

async属性でも同じようなことができるが、 async属性の場合、ダウンロードが非同期になるまでは同じでスクリプトの実行がダウンロード完了次第になるためHTMLの解析と並行する。そのため特定の順序でスクリプトを実行する必要がある場合には注意が必要。

async属性とdefer属性の詳しい違いは以下のサイトがかなり詳しく分かりやすく紹介してくれているのでそちら参考。

scriptタグに async / defer を付けた場合のタイミング

JavaのByteの計算で詰まった話

Tue, 04 Jun 2024 00:00:00 GMT

入力されたbyteが0x00 ~ 0xFDの間にあるか確認したい

指定されたbyteが0x00 ~ 0xFDにいる事を確認したく以下コードを書いたとき

byte arg = (byte) 0x01;

if((byte) 0x00 >= arg && arg =< (byte) 0xFD){
  System.out.println("問題なし");
}

何故か条件に入らない、、、

Javaのbyteは符号付き

Javaのbyteは符号付きのためbyteを数値として表すと -128 ~ 127 になる。つまり、2進数の1000 0000で符号付きとして判断されるため 0x80 ~ 0xFFまではマイナスの値になる。

なので

(byte) 0x00 > (byte) 0xFF

はtrueになる。

どうしたか

intとして扱ってあげれば符号付きで変換されないので

byte arg = (byte) 0x01;

if(0x00 >= arg && arg =< 0xFD){
  System.out.println("問題なし");
}

としてあげれば、やりたいことができる。

byte触る機会少なかったら気づかなかった...(言い訳)

補足：ビットマスク演算 (`arg & 0xFF`) を使った無符号化処理

また、別の解決策として & 0xFF によるビット演算を行い、int 型にプロモーションする方法も一般的です。

byte arg = (byte) 0xFD; // 数値としては -3
int unsignedArg = arg & 0xFF; // 0x000000FD (数値としては 253)

if (unsignedArg >= 0x00 && unsignedArg <= 0xFD) {
    System.out.println("0x00〜0xFDの範囲内です");
}

arg & 0xFF を行うことで、符号拡張によって1で埋まった上位24ビットがゼロクリアされ、0〜255の無符号整数（unsigned byteと同等）として安全に比較・計算が行えるようになります。パケット解析やバイナリプロトコルを扱う処理では定番の書き方なので、あわせて押さえておくと安心です。

GASでHTMLを公開するときに詰まった個所まとめ

Mon, 03 Jun 2024 00:00:00 GMT

GASでHTMLを静的に公開したい時に詰まった個所まとめ GASを使用してWebサイトの公開を行う方法とかは色々な箇所で既に説明されているので飛ばします。

iframe

ページ内に埋め込み系のコンテンツがある場合 GAS側ではX-Frame-OptionsにSAMEORIGINが指定されるためSameOriginPolicyで埋め込みがブロックされる。そのため、setXFrameOptionsModeを使ってポリシーの設定をする必要がある。 setXFrameOptionsModeにHtmlService.XFrameOptionsMode.ALLOWALLを渡す事ですべて許可扱いになり埋め込みがブロックされなくなる。

function doGet() {
  return HtmlService.createHtmlOutputFromFile('index').setXFrameOptionsMode(HtmlService.XFrameOptionsMode.ALLOWALL);
}

:::warning{name=""} HtmlService.XFrameOptionsMode.ALLOWALL を使用するとすべて許可になるため、iframeを自由に埋め込み表示することができるがクリックジャッキングも行えることになるため、自身でセキュリティー対策を行う必要あり。詳しくは公式を参照。 Enum XFrameOptionsMode :::

ページ同士のリンク

ページ同士のリンクは静的サイトと違いGASとして完結させる必要があるため GAS側にスクリプトを書いて対応する必要がある。

function doGet(e) {
  let page = e.parameter.page;
  if (!page) {
    page = 'index';
  }
  return HtmlService.createTemplateFromFile(page).evaluate().setXFrameOptionsMode(HtmlService.XFrameOptionsMode.ALLOWALL);
}

function getAppUrl() {
  return ScriptApp.getService().getUrl();
}

変更前

<a href="/index.html">ホーム</a>

変更後

<a href="<?= getAppUrl() ?>?page=index">ホーム</a>

HTMLファイルにはgetAppUrl関数として、GASのURLを返す関数を作成しておき GAS側でHTMLを返す際にURLを埋め込んで返す。また、doGet関数でリクエストパラメータを受け取れるようにし指定されたファイルをHTMLとして返却する。

ページの埋め込み

ページが複数あって、HTML同士を共通化してある時 GAS側でスクリプトを書いてあげる必要がある。例えば、

project-root/
└── public/
    ├── pages/
    │   └── navbar.html
    └── index.html

:
<body>
  <nav id="navbar"></nav>
</body>
:

の時静的サイトの時は、jQueryなり、javascriptでDOMのコピーをすれば対応できるが GASの場合だと取得する対象のHTMLが静的ファイルとして配置されないためファイルの中身が取得できない。

そのため、ファイルの共通化をしたい場合は以下のGASを書いて対応させる必要あり。

function doGet(e) {
  let page = e.parameter.page;
  if (!page) {
    page = 'index';
  }
  return HtmlService.createTemplateFromFile(page).evaluate().setXFrameOptionsMode(HtmlService.XFrameOptionsMode.ALLOWALL);
}

function include(filename) {
  return HtmlService.createTemplateFromFile(filename).evaluate().getContent();
}

HTML側には共通化HTMLを挿入したい箇所に以下の文を追加する。

<body>
  <nav id="navbar">
    <?!= include('navbar') ?> <!-- ←この行を追加 -->
  </nav>
</body>

ポイント

GASでHTMLの内容を返す時にevaluateを行ってからHTMLを返却しないとGASの埋め込みコード(*1)が評価されなくなる

*1 例えば<?= getAppUrl() ?>などの埋め込み部分のテンプレートに埋め込んでいるタグのこと

画像の埋め込み

画像ファイルを表示したい時、GASに画像ファイルをアップロードしても参照ができない。そのため、Base64に変換して埋め込む必要がある。 Base64にするにはNodeで関数を記載するなり、gulpで埋め込むなりする方法がある。

GASの25MB制限

GASはすべてのファイル合わせて25MBの制限がある。公式

もし、画像などを25MB以上ページに使用したい場合は Base64での埋め込みではなくGoogleDriveに画像を保存し HTML側から取得する必要あり。

function getImageAsBase64(fileName) {
  const fileId = getFileIdByName(fileName);
  var file = DriveApp.getFileById(fileId);
  var blob = file.getBlob();
  var contentType = blob.getContentType();
  var base64Data = Utilities.base64Encode(blob.getBytes());
  return 'data:' + contentType + ';base64,' + base64Data;
}

function getFileIdByName(fileName) {
  const folder = DriveApp.getFolderById("ここに画像フォルダのID");
  const files = folder.getFiles();
  let fileId = null;
  while (files.hasNext()) {
    const file = files.next();
    
    if (file.getName() === fileName) {
      fileId = file.getId();
      Logger.log("Found file: " + fileName + " with ID: " + fileId);
      break;
    }
  }
  
  if (fileId === null) {
    Logger.log("File not found: " + fileName);
  }
  return fileId;
}

画像を取得するスクリプトを追加

<script>
function fetchImages() {
    const images = document.querySelectorAll('img[data-file-id]');
    images.forEach(function(img) {
      const fileId = img.getAttribute('data-file-id');
      google.script.run.withSuccessHandler(function(base64Image) {
        img.src = base64Image;
      }).getImageAsBase64(fileId);
    });
}
      
document.addEventListener('DOMContentLoaded', fetchImages);
</script>

画像ファイルを表示したい箇所に以下のように指定

<img src data-file-id="画像ファイル名" />

上記でBase64として表示することができる。もし、画像を誰でも共有にする場合は画像のURLを取得してimageタグのsrcに指定する方法もある。

Storia's Blog

PySparkとは？ PythonやSQLと何が違うのか実際に比較してみた

この記事の対象読者

まず結論

結論1：PySparkは「Pythonを高速化したやつ」ではない

結論2：Spark SQLとPySparkは単純な別物ではない

結論3：PySparkだからといって必ずPythonより速いわけではない

そもそもPySparkとは何者？

基本的な定義

Sparkの内部はどうなってるの？

local[1] と local[5] って何？

なぜにSparkの概念が必要になるのか？

PySparkのDataFrameって普通のリストやPandasと違うの？

実際にPython・SQL・PySparkを比較してみた

検証環境

今回使用したデータ

検証1：Python単体で集計する

検証2：SQLite + SQLで集計する

Pythonでの書き方

SQLでの書き方

検証3：PySpark（DataFrame API）で集計する

検証4：PySparkの中でSQLを使う

検証5：実行計画を見てみる

Scan csv って何？

Project って何？

Exchange って何？（ちょっと気になったポイント）

性能も比較してみた

1,000万行のデカいCSVで勝負

Python単体

PySpark local[1] (スレッド数: 1)

PySpark local[5] (スレッド数: 5)

性能結果を並べてみる

実行時間全体（トータルタイム）でも比較してみた

local[1] と local[5] の並列度の差

10万行

100万行

1,000万行

調べる前と後で考え方が変わった

調べる前

調べた後

「Pythonじゃだめなの？」への回答

「SQLじゃだめなの？」への回答

注意点・今回分からなかったこと

まとめ

今後調べたいこと

参考資料

スイムレーン図とは？フローチャートやシーケンス図との違いを調べてみた

はじめに

この記事の対象読者

まず結論

スイムレーン図とは？

基本的な定義

「スイムレーン」という名前の意味

UMLとの関係

フローチャートじゃだめなの？

実際にスイムレーン図を作ってみる

検証目的

検証環境

スイムレーン図

スイムレーン図で分かったこと

レーンにAPIやDBを置くのはだめなの？

シーケンス図じゃだめなの？

同じログイン処理を3種類で比較してみる

どの図を使えばいいのか問題

「処理がどう進むのか」を知りたい

「誰・何が担当するのか」も知りたい

「誰が誰に、どの順番で処理を要求するのか」を知りたい

誰が読む資料なのかも考える

要件定義では、どこまで細かく書くのか？

スイムレーン図のメリット・デメリット

メリット

デメリット

調べる前と調べた後

調べる前

調べた後

注意点・今回分からなかったこと

まとめ

参考資料

Databricks Unity CatalogからAWS Glueのテーブルを参照できるか調べてみた

はじめに

`local[1]` と `local[5]` って何？

`Scan csv` って何？

`Project` って何？

`Exchange` って何？（ちょっと気になったポイント）

PySpark `local[1]` (スレッド数: 1)

PySpark `local[5]` (スレッド数: 5)

`local[1]` と `local[5]` の並列度の差