🧠 はじめに

PythonでExcelを操作する大規模な処理フローを作っていたとき、
「もっと効率よく動かすにはスレッドやプロセスを使えないか？」と考えました。

そこでふと、

「PythonのスレッドとCPUのスレッドって、どう違うんだっけ？」

という疑問が浮かび、調べていくうちに話がどんどん深くなり……
最終的には OSアーキテクチャの設計思想 にまでたどり着きました。

せっかくなので、単なるPythonのスレッド解説ではなく、
WindowsとUNIXのOSアーキテクチャの違い をベースに整理してみました。

🧩 1. Windowsにおけるプロセスとスレッド

Windowsでは、プロセスは実行中のプログラムをまとめる論理的な単位で、
スレッドは実際に処理を行う最小単位です。

1つのPythonプログラム（＝1プロセス）の中に複数のスレッドを作ると、
それらは同じメモリ空間を共有しながら動作します。

しかし、CPU上ではそれぞれのスレッドが別のコアやハードウェアスレッドに割り当てられ、
物理的には同時並行で動いているのがポイントです。

💡 同じプロセスのスレッドでも、実際にはCPUの別のハードウェアスレッドで同時に動く。

UNIX系（Linux, macOSなど）では、プロセスとスレッドの構造がよりシンプル。
違いはメモリ空間を共有するかどうかだけです。

この設計により、UNIXでは自由度の高い並列設計がしやすくなっています。
一方でWindowsは、COMやUIスレッドのように「通信ルール」をOSレベルで定義しています。

Windowsでは、COM（Component Object Model） という仕組みが多くのシステムを支えています。
このCOMは「スレッドモデル（Apartment Model）」というルールを持ち、それが STA と MTA です。

モデル	意味	特徴
STA（Single Threaded Apartment）	1スレッド専用でCOMオブジェクトを扱う	主にUI用（スレッドセーフではない）
MTA（Multi Threaded Apartment）	複数スレッドで同時に扱える	スレッドセーフなコンポーネント向け

STAは主にExcelやWord、UIアプリなどで採用されます。
COMオブジェクトが「特定スレッドに属する」という前提で動作しているため、
別スレッドからUIを直接いじると破壊されるのです。

UIスレッドが壊れる原因は単なる「データ競合」ではありません。
メッセージの順序と文脈（コンテキスト）の破壊が起きるからです。

UIは常に「イベントループ（メッセージキュー）」上で動いています。
たとえば次のような流れです：
ボタンが押される → 再描画 → 次のイベント待ち

別スレッドからUIを直接操作すると、
この順序を無視して描画命令が混入し、
イベントの整合性が崩れ、UIがフリーズ・消失・クラッシュします。

🔸 排他制御は「同時アクセス」は防げても、
「処理順序の破壊」は防げない。

STAが1スレッド専用なのはこのため。
UI操作は必ずそのスレッドのメッセージループを通して行う必要があります。
だからWindowsでは「UIはメインスレッドで」というルールが存在します。
このイベントループの仕組みはPythonのTkinterと同じです。

Windowsでは「スレッド」1つにも明確なルールがあり、
UNIXでは「設計者の自由」がそのまま反映されます。

どちらが良い・悪いという話ではなく、
Windowsは安全性重視、UNIXは自由度重視 という思想の違いです。