1. はじめに
業務部門で使われるツール、いわゆる EUC（End User Computing）ツール の世界では、長らく Excel VBA やAccess VBAが主役でした。フォームを置いてボタンを配置し、担当者が押せば処理が走る。この「誰でも触れる入口」があることが、EUCツールが現場に定着する最大の理由でした。
一方で近年は、VBA だけでは手が届かない領域（大量データの高速処理、Web API 連携、PDF・画像処理、機械学習など）を Python で補完するケースが増えています。しかし Python でツールを書いたときに必ずぶつかるのが、「コマンドラインしか無いツールを、どうやって業務部門に渡すのか」 という問題です。
python main.py と打ってくださいと言って通じる現場は、まずありません。引数の指定ミス、パスの打ち間違い、黒い画面への心理的抵抗。ここを埋めるのが GUI ライブラリの役割です。
本記事では、EUCツール開発という文脈にフォーカスして、Python の GUI ライブラリから次の3つを取り上げ、それぞれの特徴と適用場面を整理します。
- Tkinter（Python 標準ライブラリ）
- FreeSimpleGUI（PySimpleGUI の LGPL3 フォーク）
- TkEasyGUI（国産・MIT ライセンス）
3つとも内部的には Tkinter を基盤としており、追加のランタイムを必要とせず、社内配布のハードルが低いという共通点があります。これは Web フレームワークやネイティブGUIフレームワークにはない、EUC 用途での決定的な強みです。
2. この記事の対象者
以下のような方を想定しています。
- Excel VBA で業務ツールを作ってきたが、Python への移行・併用を検討している方
- Python スクリプトを業務部門に配布したいが、GUI をどう作るか悩んでいる方
- 社内でツールを配布する立場にあり、ライセンスや依存関係の少なさを重視する方
- GUI ライブラリが多すぎて、どれを選べばよいか判断軸が欲しい方
- PySimpleGUI を使っていたが、ライセンス変更を受けて移行先を探している方
逆に、以下のような方には本記事はあまり向いていません。
- モダンで洗練された UI デザインを最優先したい方（→ Flet、CustomTkinter、PySide6 などの検討をおすすめします）
- Web アプリとして社内公開したい方（→ Streamlit、Gradio、Django などが適しています）
- ゲームやリアルタイム描画を伴うアプリを作りたい方（→ DearPyGui、Pygame など）
3. Python の GUI ライブラリとは
3-1. GUI ライブラリの役割
GUI（Graphical User Interface）ライブラリとは、ウィンドウ・ボタン・入力欄・一覧表といった画面部品を生成し、ユーザーの操作をプログラムに伝えるための仕組みを提供するライブラリです。
VBA で言うところの UserForm に相当します。例えば Excel VBA では、Excel 自体が GUI の器を提供してくれるため、フォームデザイナにコントロールをドラッグして配置し、CommandButton1_Click のようなイベントプロシージャを書けば動きました。
Python にはこの「標準の器」がありません。そのため、GUI を作るにはライブラリを選ぶところから始まります。
3-2. GUI ライブラリの内部構造
Python の GUI ライブラリは、多くの場合 既存の GUI ツールキット（C/C++ 製）に対する Python バインディング（ラッパー） として実装されています。
| 層 | 役割 | 例 |
|---|---|---|
| Python ライブラリ層 | Python から扱いやすい API を提供 | Tkinter, PyQt, wxPython |
| ツールキット層 | 画面部品の実体を提供 | Tcl/Tk, Qt, wxWidgets |
| OS のウィンドウシステム | 実際の描画・入力処理 | Win32 API, Cocoa, X11/Wayland |
Tkinter の場合、下層に Tcl/Tk という歴史あるツールキットが存在し、Python はそれを呼び出しているに過ぎません。この構造を理解しておくと、「なぜ Tkinter のエラーメッセージに Tcl の文字列が出てくるのか」といった疑問が解けます。
3-3. イベント駆動というモデル
GUI プログラムは、上から下へ順に実行される手続き型のスクリプトとは根本的に構造が異なります。GUI は イベント駆動（Event-Driven） で動きます。
処理の流れはおおむね次のとおりです。
- ウィンドウと部品を組み立てる
- イベントループに入る（プログラムは「待ち」の状態になる）
- ユーザーがボタンを押す・文字を入力する・ウィンドウを閉じるなどの操作をする
- その操作がイベントとしてプログラムに通知される
- 対応する処理を実行し、再びイベントループに戻る
VBA でボタンの Click イベントに処理を書いていたのと同じ発想ですが、Python の場合は イベントループを自分で回す必要がある点が異なります。
このイベントループの書き方には、大きく2つの流派があります。
コールバック方式（Tkinter が採用）
部品ごとに「押されたら呼ばれる関数」を事前に登録しておく方式です。
button = ttk.Button(root, text="実行", command=run_process) # 関数を登録
root.mainloop() # あとはライブラリに任せる
柔軟性が高い一方、処理が複数の関数に分散するため、規模が大きくなると状態管理が煩雑になりがちです。
メッセージパッシング方式（FreeSimpleGUI / TkEasyGUI が採用）
イベントループを自分で while 文で回し、「どのイベントが発生したか」を戻り値で受け取って分岐する方式です。
while True:
event, values = window.read() # イベントが起きるまで待機
if event == "実行":
run_process(values)
手続き型のコードとして読み下せるため、VBA からの移行組にとっては圧倒的に理解しやすい構造です。本記事で FreeSimpleGUI と TkEasyGUI を推す最大の理由がここにあります。
3-4. EUC ツールにおける GUI ライブラリの選定軸
業務ツールとして配布する前提に立つと、選定軸は一般的な「使いやすさ」だけでは足りません。実務上は次の観点が効いてきます。
| 観点 | 確認すべきこと |
|---|---|
| 配布容易性 | 追加ランタイムが必要か。PyInstaller で EXE 化したときのサイズは |
| ライセンス | 社内利用・再配布が可能か。法務・情シスへの説明コストは |
| 依存関係の少なさ | 外部パッケージの持ち込み審査が必要な環境か |
| 学習コスト | 後任者が引き継げるか。ドキュメントは日本語で読めるか |
| 保守性 | ライブラリ自体が今後も存続するか。突然のライセンス変更リスクは |
| 見た目 | 業務ツールとして許容される程度の体裁が整うか |
特に金融機関をはじめとする管理の厳しい環境では、「Python 標準に含まれるかどうか」 が導入可否を左右することも少なくありません。この点は各ライブラリの説明で改めて触れます。
4. GUI ライブラリ3選
以降、3つのライブラリで 「名前を入力して OK を押すと挨拶を返す」 という同じアプリを実装し、コードの違いを比較します。
4-1. Tkinter
概要
Tkinter は Python の標準ライブラリに含まれる GUI ツールキットです。1990年代から存在し、下層の Tcl/Tk を含めて非常に長い歴史を持ちます。import tkinter と書くだけで使え、追加インストールが一切不要という点が最大の特徴です。
Windows・macOS 向けの公式インストーラには Tcl/Tk が同梱されています（Linux では python3-tk などのパッケージを別途導入するディストリビューションもあります）。
コード例
import tkinter as tk
from tkinter import ttk, messagebox
def on_ok():
name = entry.get()
messagebox.showinfo("確認", f"こんにちは、{name}さん")
root.destroy()
root = tk.Tk()
root.title("テスト")
root.geometry("300x140")
ttk.Label(root, text="名前を入力してください").pack(padx=10, pady=(15, 5))
entry = ttk.Entry(root, width=30)
entry.pack(padx=10, pady=5)
frame = ttk.Frame(root)
frame.pack(pady=10)
ttk.Button(frame, text="OK", command=on_ok).pack(side="left", padx=5)
ttk.Button(frame, text="キャンセル", command=root.destroy).pack(side="left", padx=5)
root.mainloop()
特徴
メリット
- 標準ライブラリであるため、外部パッケージの持ち込み審査が不要
- ライセンスは Python 本体と同じ PSF ライセンスで、実務上ほぼ問題にならない
- 情報量が圧倒的に多く、書籍・Web 記事・Stack Overflow の蓄積が豊富
-
ttk（テーマ付きウィジェット）を使えば、OS ネイティブに近い見た目になる - PyInstaller での EXE 化実績が非常に多く、トラブル事例と対処法が出揃っている
- 細かい制御が効くため、複雑な画面レイアウトにも対応できる
デメリット
- 記述量が多い。上記の単純な例でも 20 行を超える
- 3種類のジオメトリマネージャ（
pack/grid/place）を理解する必要があり、混在させると破綻する - API の設計が古く、直感的とは言い難い（
StringVarなどの Variable クラスの扱いなど） - デフォルトの見た目が素朴で、モダンな UI を求めると苦戦する
- 一覧表（
ttk.Treeview）やファイル選択などを組むと、途端にコード量が膨らむ
EUC ツールとしての評価
「環境制約が厳しい現場での最終防衛ライン」という位置づけです。外部ライブラリを一切追加できない環境でも、Python さえ入っていれば確実に動きます。一方で記述量の多さは、後任への引き継ぎコストにそのまま跳ね返るため、規模が大きくなるほど不利になります。
4-2. FreeSimpleGUI
概要
FreeSimpleGUI は、かつて GUI ライブラリの定番だった PySimpleGUI の、LGPL3 ライセンス時代（バージョン4系）のコードを引き継いだフォークです。
背景を簡単に整理しておきます。PySimpleGUI は 2024 年にバージョン5でオープンソースライセンスを廃止し、ライセンスキーによる利用登録が必要な形態へ移行しました。これを受けて、最後の LGPL3 版をベースにコミュニティが立ち上げたのが FreeSimpleGUI です。
補足（2026年時点の状況）
PySimpleGUI 本体はその後、商用化を終了し、2026年にバージョン6として再び LGPL3 のオープンソースへ回帰しています。ただし数年にわたる混乱の経緯を踏まえ、安定的に LGPL3 が維持されてきた FreeSimpleGUI を選ぶという判断は、業務ツールの前提として引き続き合理的です。導入前には必ず最新のライセンス状況をご確認ください。
import PySimpleGUI as sg を import FreeSimpleGUI as sg に書き換えるだけで、既存コードの多くがそのまま動作します。
インストール
pip install FreeSimpleGUI
コード例
import FreeSimpleGUI as sg
layout = [
[sg.Text("名前を入力してください")],
[sg.Input(key="-NAME-", size=(30, 1))],
[sg.Button("OK"), sg.Button("キャンセル")],
]
window = sg.Window("テスト", layout)
while True:
event, values = window.read()
if event in (sg.WIN_CLOSED, "キャンセル"):
break
if event == "OK":
sg.popup(f"こんにちは、{values['-NAME-']}さん")
break
window.close()
Tkinter 版と比べて記述量が半分以下になっているのが分かります。レイアウトを二次元リストで宣言するという発想が、この系統のライブラリの核心です。VBA の UserForm にコントロールを並べる感覚に近く、コードを見ただけで画面の形が想像できます。
特徴
メリット
- PySimpleGUI 4系の膨大な資産がそのまま使える。書籍、Web 記事、300以上の公式デモが全て有効
- レイアウトが二次元リストで表現でき、直感的
-
sg.popup系のダイアログが充実しており、簡易ツールなら数行で完成する - Tkinter 以外に Qt・wxPython・Web（Remi）版のポートも存在し、同一コードの移植性がある
- 単一の
.pyファイルで構成されているため、pipが使えない環境でもファイルを直接配置して利用できる
デメリット
- LGPL3 ライセンスである点。ライブラリを改変せず利用する分には実務上問題になりにくいものの、社内の法務・情シスへの説明が必要になる場合がある
- ベースが PySimpleGUI 4系のため、コード自体は 2024 年時点の設計を引き継いでいる
- 型ヒントの整備が限定的で、エディタの補完が効きにくい場面がある
- 日本語のドキュメントは公式には用意されていない（PySimpleGUI 時代の日本語記事が事実上の代替）
- 見た目は Tkinter ベースであり、独自テーマを当てても限界がある
EUC ツールとしての評価
「過去資産と情報量を重視する場合の第一候補」です。PySimpleGUI 時代に書かれた日本語の解説記事や書籍がほぼそのまま通用するため、チームで学習を進めやすいのが強みです。ライセンスの説明コストだけ、事前に確認しておくとよいでしょう。
4-3. TkEasyGUI
概要
TkEasyGUI は、日本語プログラミング言語「なでしこ」の作者として知られる クジラ飛行机氏 が開発した国産の GUI ライブラリです。PySimpleGUI のライセンス変更を契機に、ゼロから再実装されました。
2024年11月にバージョン1.0がリリースされ、その後も継続的に更新されています。MIT ライセンスを採用しており、しかも将来にわたってライセンスを変更しないことが明言されている点が、業務利用における大きな安心材料です。
インストール
pip install TkEasyGUI
コード例
import TkEasyGUI as eg
layout = [
[eg.Text("名前を入力してください")],
[eg.Input("", key="-NAME-")],
[eg.Button("OK"), eg.Button("キャンセル")],
]
window = eg.Window("テスト", layout=layout)
for event, values in window.event_iter():
if event == "OK":
eg.popup(f"こんにちは、{values['-NAME-']}さん")
break
if event == "キャンセル":
break
window.close()
注目していただきたいのが window.event_iter() です。for 文でイベントループを回せるという、TkEasyGUI 独自の設計です。while True と break の組み合わせよりも、Python らしく自然に書けます。
もちろん、従来どおり while window.is_alive(): event, values = window.read() という書き方も可能です。
特徴
メリット
- MIT ライセンス。商用利用・再配布が自由で、社内展開の際の説明コストが最も低い
- 将来的にライセンスを変更しないと明言されている。EUC ツールは数年単位で運用されるため、この保証は極めて重要
- 型ヒントに対応しており、VSCode などのエディタで引数やプロパティの補完が効く
- 開発者が日本人であり、公式ドキュメント・解説記事が日本語で読める
-
popup_get_form（複数項目の入力ダイアログ）、popup_color（色選択）など独自の便利ダイアログが豊富 - OS の配色をデフォルトで利用するため、素の見た目が比較的自然
- 画像は PNG だけでなく JPEG も直接読み込める
- イベントフック・一括イベント登録といった、実用寄りの機能が整備されている
デメリット
- 後発であるため、情報の絶対量が Tkinter や PySimpleGUI 系に及ばない。トラブル時に検索で解決しにくい場面がある
- PySimpleGUI との完全な互換性は意図されていない。プロパティ名やウィンドウクローズ時の戻り値の仕様が異なる箇所があり、既存コードの単純な移植は失敗することがある
- 実質的に個人開発プロジェクトであり、バス係数の観点でのリスクはゼロではない（MIT ライセンスなのでフォーク可能ではあります）
- バージョン間で仕様が調整されることがあるため、業務利用時はバージョン固定を推奨
EUC ツールとしての評価
「これから新規に作るなら最有力」です。特に、MIT ライセンスであることと日本語ドキュメントが揃っていることの2点は、社内展開・引き継ぎの局面で効いてきます。要件定義の段階から TkEasyGUI を前提にできるなら、迷う理由は少ないでしょう。
5. 3ライブラリの比較表
| 項目 | Tkinter | FreeSimpleGUI | TkEasyGUI |
|---|---|---|---|
| 位置づけ | Python 標準ライブラリ | PySimpleGUI 4系のフォーク | 国産・ゼロから再実装 |
| インストール | 不要（標準同梱） | pip install FreeSimpleGUI |
pip install TkEasyGUI |
| ライセンス | PSF ライセンス | LGPL3 | MIT |
| ライセンス変更リスク | 極めて低い | 低い | 極めて低い（変更しない旨を明言） |
| 基盤 | Tcl/Tk | Tkinter（他ポートもあり） | Tkinter |
| イベントモデル | コールバック方式 | メッセージパッシング（while） |
メッセージパッシング（for / while） |
| レイアウト記述 |
pack / grid / place
|
二次元リスト | 二次元リスト |
| 記述量（体感） | 多い | 少ない | 少ない |
| 学習コスト | 高い | 低い | 低い |
| 型ヒント対応 | 部分的 | 限定的 | 対応 |
| 日本語ドキュメント | 記事は豊富（非公式） | 非公式記事のみ | 公式が日本語 |
| 情報量（全体） | 非常に多い | 多い（PySimpleGUI 資産を含む） | 中程度 |
| デフォルトの見た目 | 素朴（ttk で改善可） |
素朴（テーマ多数） | 素朴（OS配色に追従） |
| 細かい制御 | 得意 | やや不得手 | やや不得手 |
| EXE 化（PyInstaller） | 実績豊富 | 可能 | 可能 |
| 開発体制 | Python コア | コミュニティ | 個人（活発） |
6. どのユーザー・ケースに最適か
6-1. Tkinter が最適なケース
こんな方に
- 外部ライブラリの持ち込みが制限されている環境で開発している方
- 情シス・セキュリティ部門の審査を通す手間を最小化したい方
- Python の GUI を体系的に学び、他ライブラリの内部挙動まで理解したい方
- 既存の Tkinter 資産を保守する立場にある方
こんなケースで
- 社内標準の Python 環境に、追加パッケージを入れられない
- 数個のボタンと入力欄だけの、ごく小さなランチャーを作る
- 他ライブラリでは実現できない、独特なレイアウトや描画（Canvas を使った図形描画など） が必要
- FreeSimpleGUI / TkEasyGUI を使いつつ、下層の Tkinter オブジェクトを直接触って細かく調整したい
判断のポイント
「制約が厳しいから Tkinter」という消極的な選択が多くなります。逆に言えば、制約がないなら、わざわざ記述量の多い Tkinter を素で書く理由は薄いです。
ただし、FreeSimpleGUI も TkEasyGUI も内部は Tkinter なので、Tkinter の知識は無駄になりません。トラブルシューティングの際、下層を理解しているかどうかで解決速度が変わります。
6-2. FreeSimpleGUI が最適なケース
こんな方に
- PySimpleGUI で書かれた既存ツールを保守・移行する立場にある方
- PySimpleGUI 関連の書籍や記事で学習した経験がある方
- チームメンバーに PySimpleGUI 経験者が複数いる方
- LGPL3 の利用について、社内で既に判断基準が確立している方
こんなケースで
- 過去に PySimpleGUI で作ったツールが社内に複数あり、まとめて移行したい
- 参考にできる日本語の書籍・記事が多いことを、教育コストの観点から重視する
- 将来的に Qt や Web（Remi）版への移行余地を残しておきたい
-
pipが使えないクローズド環境で、単一の.pyファイルを直接配置して使いたい
判断のポイント
移行コストの低さが最大の武器です。import 行を1行書き換えるだけで動くケースが多く、既存資産があるなら第一候補になります。
一方、LGPL3 の解釈について社内で説明を求められる可能性があります。ライブラリを改変せず利用するだけであれば実務上の問題は生じにくいものの、事前に法務・情シスと認識を合わせておくと安全です。この一手間が惜しい場合は、次の TkEasyGUI が有力な選択肢になります。
6-3. TkEasyGUI が最適なケース
こんな方に
- これから新規に Python の GUI ツールを作り始める方
- VBA から Python への移行を進めており、直感的に書けるライブラリを探している方
- ライセンス面での説明コストを最小化したい方
- 日本語のドキュメントを重視する方、あるいは英語が苦手なメンバーがチームにいる方
- エディタの補完を効かせて効率よく開発したい方
こんなケースで
- 既存資産がなく、ゼロベースでライブラリを選定できる
- 作ったツールを 社内の複数部署に配布する（MIT ライセンスなら再配布の説明が最も簡単）
- 後任への引き継ぎを強く意識しており、日本語ドキュメントの存在が価値になる
- 複数項目の入力フォームやファイル選択など、定型的な業務ツールの画面を素早く組みたい
- 数年単位で運用するツールであり、ライセンス変更リスクを避けたい
判断のポイント
新規開発における総合力では、現時点で最もバランスが取れています。特に「MIT ライセンス」「日本語公式ドキュメント」「型ヒント対応」の3点は、日本の業務現場での開発において実利が大きい要素です。
注意点は情報量です。ニッチな要件でつまずいた際、検索で解決できない可能性があります。その場合は下層の Tkinter の知識で対処するか、GitHub の Issue や Discord で問い合わせることになります。Tkinter の基礎知識を保険として持っておくことをおすすめします。
7. 用途別の選択指針まとめ
| シチュエーション | 推奨 | 理由 |
|---|---|---|
| 外部ライブラリを追加できない環境 | Tkinter | 標準同梱で審査不要 |
| 既存の PySimpleGUI 資産を移行したい | FreeSimpleGUI |
import 1行の書き換えで済むことが多い |
| ゼロから新規開発する | TkEasyGUI | ライセンス・日本語ドキュメント・補完の総合力 |
| VBA からの移行組が主な開発者 | TkEasyGUI / FreeSimpleGUI | 手続き型で読み下せるイベントループ |
| 社外を含む再配布の可能性がある | TkEasyGUI | MIT ライセンスで制約が最も緩い |
| 日本語ドキュメントを重視する | TkEasyGUI | 開発者・公式ドキュメントが日本語 |
| 日本語の書籍で学習したい | FreeSimpleGUI | PySimpleGUI 系書籍がほぼそのまま通用 |
| 独自の描画・複雑なレイアウトが必要 | Tkinter | 下層を直接制御できる |
| 数行のダイアログだけ出したい | TkEasyGUI / FreeSimpleGUI |
popup 系が充実 |
| 長期運用でライセンス変更を避けたい | Tkinter / TkEasyGUI | PSF / MIT で変更リスクが極小 |
| 情報量の多さでトラブルを避けたい | Tkinter | 蓄積された事例が圧倒的 |
| 将来的に Qt / Web へ移植する可能性がある | FreeSimpleGUI | 複数ポートが提供されている |
迷ったときの実務的な結論
筆者としては、次の順序で判断することをおすすめします。
- 既存の PySimpleGUI 資産があるか → あれば FreeSimpleGUI
- 外部ライブラリを追加できるか → 追加できないなら Tkinter
- 上記以外 → TkEasyGUI
そのうえで、いずれを選んだ場合でも Tkinter の基礎（ウィジェット、ジオメトリマネージャ、イベントループ）は押さえておくと、詰まったときの引き出しが増えます。3つとも土台は同じだからです。
8. おわりに
Python の GUI ライブラリと聞くと、モダンな見た目や凝ったアニメーションに目が行きがちです。しかし EUC ツールの文脈で本当に重要なのは、「配布できるか」「引き継げるか」「使い続けられるか」 の3点だと考えています。
その観点で見たとき、Tkinter を基盤とする本記事の3ライブラリは、いずれも堅実な選択肢です。追加ランタイムが不要で、PyInstaller での EXE 化実績があり、ライセンスも明快。華やかではないが、業務の現場で確実に動くという性質は、EUC ツールにとって何よりの美点です。
そして忘れてはならないのが、GUI をつけたからといって、それが最適解とは限らないという点です。Excel VBA でフォームを出せば済む要件に、わざわざ Python の GUI を持ち込む必要はありません。GUI ライブラリは、「Python でなければ実現できない処理があり、かつ業務部門が直接操作する必要がある」 という条件が揃ったときに初めて真価を発揮します。
適材適所を意識しながら、手元のツール箱にひとつ選択肢を増やしていただければ幸いです。
最後までお読みいただき、ありがとうございました。
参考リンク
- Tkinter — Python 公式ドキュメント
- FreeSimpleGUI — PyPI
- FreeSimpleGUI — GitHub
- TkEasyGUI — 公式サイト（日本語）
- TkEasyGUI — GitHub
- TkEasyGUI — PyPI
各ライブラリのライセンスやバージョンは変更される可能性があります。業務での採用にあたっては、必ず最新の公式情報をご確認ください。