もざぶれなるままに

Pythonで自作した将棋AIと対局してみた｜学習前でも探索回数がかなり重要だった実装ログ

Fri, 20 Mar 2026 12:00:00 +0900

今回は「学習前のAI」と対局してみた

この記事は、「自前で将棋AIを作ろうプロジェクト」の第二弾です。

第一弾はこちらです。

Pythonで将棋AIを作るならまずGUI｜実装した理由と設計

前回は、将棋AI開発の土台としてGUIを先に作った、という話を書きました。

今回はその続きで、まだ強化学習を本格的に回す前の将棋AIと実際に対局してみたログです。

この段階のAIは、ニューラルネットワークで強くなったAIではありません。
中身はあくまで、手作り評価関数 + MCTS（モンテカルロ木探索） をベースにした「学習前の将棋AI」です。 MCTS は、候補手を試しながら有望そうな手を重点的に読む探索手法です。

やってみて一番はっきり分かったのは、同じ評価関数でも探索回数で強さがかなり変わる ということでした。

※ ここでいう探索回数は、探索AIが次の一手を決める前にどれだけ候補手を試しながら読むかの回数です。実装上の引数名では simulations に当たるものです。

この時点の将棋AIの中身

現時点の ML-shogi は、純粋な学習済みモデルではなく、まずは評価関数ベースで最低限戦えることを優先して作っています。

評価関数は、駒の損得が大きくズレないことを軸に、将棋らしい補正を少しずつ足した形です。基準値は次の通りです。

駒	評価値	駒	評価値
歩	`100`	と	`600`
香	`300`	成香	`450`
桂	`350`	成桂	`500`
銀	`550`	成銀	`550`
金	`600`
角	`800`	馬	`1200`
飛	`1000`	龍	`1300`

玉は通常の駒価値には入れず、詰みや終局判定で別に扱っています。

補正は次の通りです。

駒価値ベースの静的評価を軸にする
持ち駒は盤上より少し高く見る
王手した側には +200、王手されている側には -200 を入れる
銀、桂馬、香車は自玉の近くにいないと少し下げる
角と飛車は利きマス数と対玉プレッシャーで加点する
馬は自玉近くの守備駒としても加点する

持ち駒ボーナスは固定加点で、飛車 +100、角 +80、金と銀 +50、桂 +40、香 +30 です。

銀・桂馬・香車には守備補正も入れています。
銀は自玉の近くにいないと -40、桂は -30、香は -25 です。
考え方は単純で、玉そばの銀・桂馬・香車の価値は高い というものです。

金はもともと守備駒として使う前提が強いので、位置補正は入れていません。

大駒は働きも見ています。
角は利き1マスごとに +8、相手玉と角のラインが通っていれば追加で +80、飛車は利き1マスごとに +7、相手玉への縦横の圧力が通っていれば +100 です。
馬は自玉の周囲2マス以内なら +100、3マス以内なら +40 を足して、攻守両用の駒として少し評価しています。

要するに、最初から複雑にしすぎず、探索を回した時に将棋として破綻しにくい評価 を優先しています。

実際に対局してみた印象

今回は、探索回数 32 / 500 / 1024 の3局を見ています。

いきなりパックマンを誘ってきたと思った。パックマンに乗ったらパックマンせえへんのかーい！

うっかり龍をただで取られているのは秘密です。
65手目からAIあるあるの終盤での謎王手が来ました。AIやってるって感じがして嬉しくなった。これの要因は、王手に評価ボーナスを入れていることです。

学習前でも、合法手が壊れている感じはなく、飛車角交換や持ち駒の打ちもそれなりに将棋っぽく進みます。

一方で、読みが浅い設定では不自然な手もまだ残っていて、評価関数を使ってどれだけ先まで読むか の影響がかなり大きいと感じました。

学習前のAIでは探索回数がかなり重要

特に探索回数 32 あたりの低め設定では、

交換の損得はそれっぽくても、その後が続かない
受けない

という感じで、話にならないです。

逆に探索回数 1024 まで上げると、

明らかな取り逃しが減る
飛車や角の圧力を活かす手が増える

という変化が出ました。
評価関数そのものを変えていないのに対局感がかなり変わるので、少なくとも学習前のAIでは探索回数がかなり重要 だと分かりました。

開発ログとしての収穫

学習前でも人間相手に触れる段階まで持っていく価値は大きい です。
自己対局ログや損失だけでは見えにくい「変な指し回し」が、実際に対局するとすぐ分かります。

次に、自己対局の探索回数を 8 から 128 に上げたことで学習が進み始めたのも、かなり納得感がありました。
実際に人間が相手をすると、探索回数が少ないAIは教師データ生成にも不利そう だと体感できます。

評価関数ベースでも一応対局は成立する
探索回数で強さが大きく変わる
学習前のボトルネックが、評価関数そのものだけでなく探索品質にもあると分かった

特に今回は、「強化学習を始める前に、まず評価関数 + 探索だけでどこまで戦えるかを見る」 という意味でかなり良い確認になりました。
学習に入る前の土台として、どこが弱くて、どこは意外と戦えているのかが少しずつ見えてきました。

次にやりたいこと

次は学習です。
少なくとも学習前のAIでは探索回数がかなり重要だと分かったので、この土台の上で自己対局と学習を回して、どこまで指し回しが変わるかを見ていきます。

まとめ

学習前の将棋AIでも、手作り評価関数 + MCTS だけである程度は対局になります。
ただし強さは「評価関数の出来」だけでは決まらず、探索回数でかなり別物になる というのが今回の一番大きな発見でした。

同じ評価関数でも、読む回数が少ないとかなり軽い手を指し、増やすと急にしぶとくなります。

次は、この土台の上で実際に学習を回していきます。

Ansysのバージョン選択ツールを作った理由｜古い解析ファイルを別バージョンで開くリスクを減らす

Wed, 18 Mar 2026 11:00:00 +0900

GitHub: mitz17/ANSYS_Version_Selector

このツールは GitHub で公開しています。興味があればコードや README もそのまま確認できます。この記事で紹介するツールは個人が作成した非公式ツールであり、Ansys の公式製品・公式サポートとは関係ありません。

作った理由

自分の環境では、Ansys® Fluent、Ansys SpaceClaim、Ansys Workbench を複数バージョン入れていると、「どのバージョンで開くか」を毎回きちんと制御しづらいことがありました。

手元では、バージョン選択が素直に動かず、2025 R2 を押したのに 2025 R1 が開いてしまうことがありました。
しかも、既定のアプリを新しいバージョンに設定していると、古い解析ファイルをうっかり新しいバージョンで開いてしまうことがあります。

この状態で何も考えず保存すると、今度は古いバージョンで開けなくなることがあります。
実際の運用ではこれがかなり厄介で、「どのバージョンで開くか」を毎回明示的に選べる仕組みが欲しくなりました。

もちろん、Ansys 製品そのものは解析機能として非常に強力で、実務でも頼る場面が多いです。
今回作ったのはその代替ではなく、複数バージョン運用時の起動まわりを少し安全にするための補助ツールです。

そこで作ったのが、Fluent、SpaceClaim、Workbench 向けのバージョン選択ツールです。

何をするツールか

このツールは、Windows 上で Ansys 製品の起動前にバージョンを選ぶための小さな GUI ランチャーです。

対象は次の 3 つです。

Fluent
SpaceClaim
Workbench

やっていること自体はシンプルで、インストール済みの実行ファイルをバージョンごとに登録しておき、開きたいファイルに対して「どの版で起動するか」を選べるようにしています。

これにより、次のようなリスクを減らしやすくなります。

古い解析ファイルを新しい版で開いてしまう
複数バージョン環境で意図しない版が起動する
実行ファイルの場所を毎回手で探す

対応しているもの

Fluent

対応拡張子は以下です。

.msh
.msh.h5
.cas
.cas.h5
.dat
.dat.h5

Fluent については、単に EXE を起動するだけではなく、読ませるファイルに応じて一時 .jou ファイルを生成して自動読込するようにしています。
これは、.msh、.cas、.dat で読み込み手順が異なるためで、起動後に毎回手作業で読み込みコマンドを入れなくて済むようにするためです。

さらに、次のような指定にも対応しています。

ソルバ / メッシング切り替え
2D / 3D
Double Precision
並列数指定

Fluent 向けの画面では、バージョン選択に加えて、製品モード、次元、精度、並列数までまとめて指定できます。
単に「どの版を開くか」だけでなく、起動条件までワンステップで決められるようにしました。

SpaceClaim

対応拡張子は以下です。

.scdoc
.step
.stp
.iges
.igs

こちらは比較的単純で、選択したバージョンの SpaceClaim.exe に対象ファイルをそのまま渡して起動します。

SpaceClaim は起動引数が比較的単純なので、画面もかなりミニマルです。
対応ファイルを選んで、どのバージョンで開くかを決めることに役割を絞っています。

Workbench

対応拡張子は以下です。

.wbpj

Workbench は、選択した実行ファイルに対して -F <filepath> を付けて起動します。

Workbench も基本はシンプルで、.wbpj を選び、開く版を選んで起動する構成です。
古い案件をどの版で開くかを明示できるだけでも、うっかり事故はかなり減らせます。

共通インターフェース

各ランチャーは個別スクリプトですが、設定保存やバージョン管理 UI は共通化しています。
その共通処理をまとめているのが launcher_common.py です。

共通化している処理の中でも特に大きいのが、設定ファイルの保存と、バージョン一覧を編集するためのダイアログです。
その設定情報は JSON で保存します。
保存されるのは「バージョン名」と「そのバージョンで使う実行ファイルの絶対パス」の対応です。

たとえば Fluent なら、こんなイメージです。

{
 "versions": {
 "v252": "C:\\Program Files\\ANSYS Inc\\v252\\fluent\\ntbin\\win64\\fluent.exe"
 }
}

この形式にしておくと、人間が見ても分かりやすく、あとから手修正もしやすいです。

設定画面では、検出したバージョンを一覧で管理できます。
追加・更新・削除だけでなく、上へ / 下へ ボタンで並び順も変更できるようにしてあり、よく使う版を上に寄せておけます。
自動検出した結果をそのまま使うだけでなく、現場の運用に合わせて順番を整えられるようにしました。

実装方針

GUI は tkinter で作っています。
理由は単純で、Windows 上で配ることを考えたときに依存を増やしたくなかったからです。

このツール全体の設計では、次の方針を優先しました。

Windows 専用前提で割り切る
依存を増やしすぎず、配布しやすくする
製品ごとの違いは吸収しつつ、責務は分ける
自動化しすぎるより、現場で直しやすい形を優先する

たとえば GUI を tkinter にしたのは、見た目の派手さよりも「Python 標準に近い構成でそのまま動く」ことを優先したからです。
複数人に配る可能性や、あとから EXE 化することも考えると、追加依存が少ない方が扱いやすいと判断しました。

また、Fluent / SpaceClaim / Workbench を全部ひとつの巨大なランチャーにまとめるのではなく、製品ごとにスクリプトを分けています。
これは、Fluent だけ起動オプションや読み込みロジックが明らかに重く、SpaceClaim や Workbench とは責務が違うからです。

そのうえで、

設定保存
バージョン管理 UI
旧設定の移行

のような共通部分だけを launcher_common.py に寄せています。
つまり、全部を抽象化するのではなく、「同じ処理だけ共通化し、違う処理は分ける」という方針です。

バージョン検出も同じ考え方で、何でも自動判定するより、典型的なインストール先をまず確実に拾い、ダメなら手で修正できる構成にしています。
実際の現場では、検出ロジックが賢すぎることより、意図が読めて自分で直せることの方が重要だと感じたためです。

コード上ではどう動いているか

ランチャー本体は 3 ファイルに分かれています。

Fluent_Launcher_from_md.py
SpaceClaim_Launcher.py
Workbench_Launcher.py

共通部分は launcher_common.py に寄せています。

共通処理: 設定保存と設定ダイアログ

設定ファイルの保存場所は launcher_common.py の config_base_dir() で決めています。

def config_base_dir() -> Path:
 base = app_base_dir()
 if not getattr(sys, "frozen", False):
 return base

 appdata = os.environ.get("APPDATA")
 if appdata:
 candidate = Path(appdata) / "AnsysLaunchers"

.py として実行する場合はスクリプト配置フォルダを使い、EXE 化後は %APPDATA%\AnsysLaunchers を優先します。
この分岐を入れておくことで、開発中の扱いやすさと、配布後の設定保存先の安定性を両立しています。

設定画面そのものは BaseSettingsDialog として共通化してあり、各ランチャーは「何をスキャンするか」だけを差し替える形です。

ttk.Button(btn_frm, text="追加/更新", command=self.add_update).pack(side="left")
ttk.Button(btn_frm, text="削除", command=self.delete_item).pack(side="left", padx=(5, 0))
ttk.Button(btn_frm, text="上へ", command=lambda: self.move_item(-1)).pack(side="left", padx=(5, 0))
ttk.Button(btn_frm, text="下へ", command=lambda: self.move_item(1)).pack(side="left", padx=(5, 0))
ttk.Button(btn_frm, text="スキャン", command=self.scan_versions).pack(side="left", padx=(20, 0))

move_item() で辞書順ではなく表示順を入れ替えて保存しているので、一覧の先頭に「よく使う版」を持ってきやすくしています。

Fluent: ファイル種別ごとにジャーナルを作る

Fluent では、どの拡張子を開くかによって起動時の処理を変えています。
その中核が build_journal_for_file() です。

if base_ext in [".msh", ".msh.h5"]:
 cmds.append(f"/file/read-mesh \"{p}\"")
elif base_ext in [".cas", ".cas.h5"]:
 cmds.append(f"/file/read-case \"{p}\"")
elif base_ext in [".dat", ".dat.h5"]:
 cas_candidates = [
 filepath.with_name(f"{base_root}.cas"),
 filepath.with_name(f"{base_root}.cas.h5"),
 ]

ここで、

.msh なら read-mesh
.cas なら read-case
.dat なら対応する .cas を探してから read-data

という流れを組み立てています。

その後 launch_fluent() で一時 .jou を作って -i 付きで Fluent に渡します。

with tempfile.NamedTemporaryFile(
 "w",
 delete=False,
 prefix="ansys_launcher_",
 suffix=".jou",
 encoding="utf-8",
 newline="\n",
) as tf:
 tf.write(journal_text)
 journal_path = tf.name

cmd.extend(["-i", journal_path])

これで、GUI からバージョンを選ぶだけで、対象ファイルに応じた読込処理まで自動で流せるようにしています。

Fluent: 2D/3D、DP、並列数も起動引数に反映

Fluent は版選択だけではなく、起動条件も GUI から変えられるようにしています。

def resolve_mode(self) -> str:
 if self.product_var.get() == "meshing":
 return "3d"
 dim = self.dim_var.get()
 dp = self.dp_var.get()
 mode = dim
 if dp:
 mode += "dp"
 return mode

この返り値をそのまま起動引数に使い、さらに並列数も -t で付けています。

if n_procs > 1:
 cmd.append("-t" + str(n_procs))

SpaceClaim / Workbench: できるだけ単純に起動

SpaceClaim と Workbench は、Fluent のような追加ロジックを極力持たせていません。
必要な引数だけ渡して、あとは選んだ版で開くことに責務を絞っています。

SpaceClaim はこうです。

cmd = [exe]
if filepath:
 cmd.append(filepath)

Workbench は .wbpj を -F 付きで渡します。

cmd = [exe]
if filepath:
 cmd.extend(["-F", filepath])

どちらも「起動する版を間違えない」ことが主目的なので、実装もその目的に対して必要最小限にしています。

バージョン検出の考え方

完全自動で何でも見つけるより、まずは「よくあるインストール先を確実に拾う」方針にしています。

たとえば Fluent なら、次のような典型パスを見に行きます。

C:\Program Files\ANSYS Inc\v252\fluent\ntbin\win64\fluent.exe

SpaceClaim や Workbench も同様に、典型的なインストール先を優先してスキャンします。
見つからない場合は、設定ダイアログから手で実行ファイルを登録できるようにしています。

このあたりは「賢すぎる自動検出」より、「現場で確実に直せること」を優先しました。

実際の検出も、かなり素直です。
たとえば Fluent は v***\fluent\ntbin\win64\fluent.exe を見ています。

exe = vdir / "fluent" / "ntbin" / "win64" / "fluent.exe"
if exe.exists():
 found[vdir.name] = str(exe)

Workbench では RunWB2.exe や ansyswb.exe を探し、SpaceClaim では SpaceClaim.exe や SCDM.exe を見ています。
見つからないときは設定画面から手で登録できるので、多少環境差があっても逃げ道を残しています。

Fluent だけ少しロジックが重い

3 つの中でいちばん実装が厚いのは Fluent です。

理由は、単に EXE を開くだけでは済まず、読み込むファイルの種類によって処理を変える必要があるからです。

たとえば、

.msh なら read-mesh
.cas なら read-case
.dat なら必要に応じて対応する .cas を先に探してから read-data

というように、起動時に流すジャーナルを変えています。

親プロセス側でジャーナルをすぐ消してしまうと、Fluent 側の読み込みタイミング次第で失敗する可能性があるため、一時 .jou は即削除しない設計にしました。
代わりに、48 時間以上古いランチャー由来のジャーナルを次回起動時に掃除するようにしています。

このあたりは地味ですが、実際に安定して使うには必要な処理でした。

ジャーナルを即削除しない理由もコード側で明示してあります。
親プロセスが先に消すと Fluent 側の読込タイミングと競合する可能性があるため、cleanup_old_journals() で次回起動時に古いものだけ掃除する方式にしました。

使い方

Python スクリプトとして使う

各スクリプトは単体で起動できます。

py -3 .\Fluent_Launcher_from_md.py
py -3 .\SpaceClaim_Launcher.py
py -3 .\Workbench_Launcher.py

ファイルを引数で渡して起動することもできます。

py -3 .\Fluent_Launcher_from_md.py D:\work\sample.cas.h5
py -3 .\SpaceClaim_Launcher.py D:\cad\part.scdoc
py -3 .\Workbench_Launcher.py D:\project\model.wbpj

普段はこれを既定アプリや右クリックメニューと組み合わせて使う想定です。
ダブルクリック直後に版を選べるようにしておけば、「そのまま新しい版で開いてしまった」をかなり防げます。

初回起動時の流れ

初回起動時に設定ファイルがなければ、典型的なインストール先をスキャンします。
検出に成功すれば、その結果を JSON として保存します。

以後は、

登録済みバージョンを選ぶ
必要なら設定画面で追加・修正する
ファイルを選んで起動する

という流れです。

EXE 化の方法

このツールは PyInstaller による単一 EXE 化を前提にしています。

通常ビルド:

.\build_all_exe.ps1

クリーンビルド:

.\build_all_exe.ps1 -Clean

README にあるとおり、ビルドすると次の EXE を作る構成です。

FluentVersionSelector.exe
SpaceClaimVersionSelector.exe
WorkbenchVersionSelector.exe

PyInstaller が見つからない場合だけ python -m pip install pyinstaller を実行する想定なので、毎回余計なことをしない構成になっています。

EXE 化した場合は設定保存先が %APPDATA%\AnsysLaunchers に切り替わるので、スクリプト直実行時と設定の置き場が混ざりにくいのも利点です。

ちなみに、各ランチャーに使っているアイコン画像は生成AIで作成したものです。
ツールの機能自体は地味ですが、配布物として見たときに判別しやすいよう、Fluent / SpaceClaim / Workbench でそれぞれ見分けがつくようにしています。

設定保存まわり

スクリプトを .py のまま使う場合は、設定 JSON をスクリプトと同じフォルダに保存します。
一方、PyInstaller で EXE 化した場合は %APPDATA%\AnsysLaunchers を優先して保存します。

これにより、

手元で Python スクリプトとして使う
EXE にして配布する

の両方に対応しやすくしています。

また、旧配置に JSON がある場合は新しい保存先へ移行する処理も入れています。
こういう移行処理は地味ですが、後から置き場を変えるときに効いてきます。

EXE 化も前提にした

このツールは自分用に始めましたが、最初から「Windows 上でそのまま置いて使える」ことも意識していました。

そのため、PyInstaller で単一 EXE にできる構成にしてあります。

ビルドすると、次のような実行ファイルを作れます。

FluentVersionSelector.exe
SpaceClaimVersionSelector.exe
WorkbenchVersionSelector.exe

Python が入っていない環境でも扱いやすくしたかったので、ここは早めに整えました。

使ってみて良かった点

この手のツールは派手ではありませんが、複数バージョンを触る現場だと地味に効きます。

特に良かったのは次の点です。

「どのバージョンで開くか」を毎回明示できる
古い案件を新しい版で誤って開くリスクを下げられる
実行ファイルの場所を覚えなくてよい
Fluent だけ起動オプションが複雑、という差も吸収できる

Ansys 本体の大きな機能追加ではなく、運用上の誤操作や取り違えを減らすための小さな補助ツール、という立ち位置です。

まとめ

このツールを作ったきっかけは、自分の環境で Ansys 製品のバージョン選択が期待通りに動かず、意図しないバージョンが開くことがあったからです。
さらに、既定アプリを新しい版にしていると、古い解析ファイルをうっかり新しい版で開いて保存してしまい、後戻りしにくくなる問題もありました。

そこで、「起動前に必ず版を選ぶ」ための小さなランチャーを自作しました。

やっていることは地味ですが、複数バージョン運用ではかなり実用的です。
同じように、Fluent や Workbench の版違いでヒヤッとしたことがあるなら、こういうワンクッションを入れるだけでもだいぶ楽になります。

※ Ansys、Ansys Fluent、Ansys SpaceClaim、Ansys Workbench は Ansys, Inc. またはその関連会社の商標または登録商標です。本記事は第三者による非公式な紹介です。

Pythonで将棋AIを作るならまずGUI｜実装した理由と設計

Wed, 18 Mar 2026 00:00:00 +0900

開発のきっかけ

この記事は、「自前で将棋AIを作ろうプロジェクト」の第一弾です。

続き（第二弾）はこちらです。

Pythonで自作した将棋AIと対局してみた｜学習前でも探索回数がかなり重要だった実装ログ

将棋AIを作ろうとすると、「まず何から作るべきか？」で悩むと思います。

強化学習、探索、評価関数あたりから入りたくなりますが、実際にはその前に、「盤面が正しく動いているかを確認できる環境」を作るのがかなり重要です。

この記事では、Pythonで将棋AIを作る第一歩として、強化学習に入る前にGUIを先に実装した理由と設計について解説します。

将来的には、強化学習で将棋AIを作ってみたいと思っています。

ただ、いきなり学習だけを回し始めても、

盤面が正しく更新されているのか
合法手生成が壊れていないか
成りや持ち駒の扱いが想定通りか
探索結果がそれっぽく動いているか

を確認しづらいです。

ログだけ見て追うやり方もありますが、将棋みたいにルールが多いゲームではやはり盤面を直接見られる方が早い。ということで、この「自前で将棋AIを作ろうプロジェクト」の第一歩として、まずは将棋GUIを作りました。

このあと実際に、学習前の評価関数ベースAIと対局してみた記録 は次の記事にまとめています。

将棋AIを強化学習前に対局テスト｜MCTSのsimulation数で強さが激変した開発ログ

最終目標は「自前の強化学習将棋AIを育てること」

今作っている ML-shogi では、単に「将棋が動くプログラム」を作りたいわけではなく、

将棋ルールをコードで扱えるようにする
盤面を特徴量に変換する
自己対局で (state, policy, value) を集める
それをもとに方策・価値ネットワークを育てる
最終的に探索と組み合わせて対局できるAIにする

という流れを目標にしています。

その意味でGUIは完成品ではなく、学習基盤を人間が検証するための観測装置に近い立ち位置です。

将棋AI開発でGUIを先に作った理由

強化学習のコードを書いていると、ボトルネックは「学習アルゴリズムそのもの」だけではありません。

合法手生成のバグ
打ち歩詰めや成り判定の抜け
千日手や入玉まわりの終局処理
評価値や探索結果の向きが逆になる問題
人間が見ると明らかにおかしい手をAIが選んでいるのに、ログだけだと気づきにくい問題

このあたりは、学習が弱いのか、ルール実装が壊れているのか、探索が悪いのかを切り分けるのが面倒です。

そこで、盤面・持ち駒・最終手・評価推移・対局状態を一画面で見られるGUIを先に作っておけば、将来の自己対局や学習結果の確認がかなり楽になるはずだと考えました。

Python製の将棋GUIでできること

9x9 の盤面表示
先手/後手の持ち駒表示
人間 vs AI の対局
AI 同士の自動対局観戦
最終手の強調表示
王手・詰み・投了など終局状態の表示
評価値の簡易グラフ表示
negamax と MCTS の切り替え
棋譜の .kif 保存

見た目はこんな感じです。

盤面だけでなく、右側に状態表示、評価値、持ち駒、操作ボタン、評価推移グラフをまとめています。
「いま何が起きているか」をなるべくログを読まなくても分かるようにしたかったので、観戦ツール寄りの構成にしました。

盤面上の駒画像には koma.png を使っています。

これは生成AIで作った画像です。もうちょっと本物の将棋駒っぽい質感にしたかったのですが、今回はひとまず使える見た目になったところで妥協しました。
とはいえ、GUIの操作感を確認する用途としては十分だったので、まずはこの画像で進めています。

将棋GUIで特に欲しかった確認ポイント

1. 合法手が直感どおりに選べること

人間側で駒をクリックしたとき、移動可能なマスだけが候補として出るようにしています。
これで「その局面で本当にその手が合法なのか」を視覚的に確認できます。

持ち駒を打つ処理も含めて見られるので、将棋ルールの土台チェックとしてかなり便利です。

コードは例えばこんな感じで、GUI側では合法手生成の結果をそのまま使って移動候補を出しています。

def _targets_from_square(position: Position, square: tuple[int, int]) -> set[tuple[int, int]]:
 return {
 move.to_square
 for move in generate_legal_moves(position)
 if move.from_square == square
 }

やっていること自体は単純で、あるマスを始点に持つ合法手だけを抜き出して、移動先の集合を作っているだけです。
ただ、この「エンジン側の合法手生成をそのままGUIに流す」形にしておくと、表示と内部ロジックのズレが起きにくいので、将棋AI開発の初期段階ではかなり扱いやすいです。

2. 成りの扱いをその場で確認できること

成り・不成の両方がありえる局面では、ポップアップで選べるようにしました。

これを入れておくと、成り判定の境界がおかしくなっていないかを実際の操作で確認できます。
学習前の段階では、こういう地味な確認が意外と大事です。

3. 終局状態を見逃さないこと

詰みや投了時は、終局が分かるように強めに表示しています。

終局判定そのものは内部ロジック側で持っていますが、GUI上でも見えていないと「本当に正しく終わったのか」が分かりにくい。
詰み、千日手、入玉宣言勝ちは内部ロジックとしてすでに実装してあるので、GUI側ではそれらの終局状態を人間が確認しやすい形で見えるようにしています。

終局判定のコードも雰囲気としてはかなり素直で、合法手が残っているか、千日手か、入玉条件を満たしているかを順番に見ています。

def terminal_result(position: Position) -> TerminalResult:
 entering_king = entering_king_declaration_result(position, position.side_to_move)
 if entering_king is not None:
 return entering_king

 if is_repetition(position):
 return TerminalResult(status=TerminalStatus.REPETITION, winner=None)

 legal_moves = generate_legal_moves(position)
 if legal_moves:
 return TerminalResult(status=TerminalStatus.ONGOING, winner=None)

 if is_in_check(position, position.side_to_move):
 return TerminalResult(
 status=TerminalStatus.CHECKMATE,
 winner=position.side_to_move.opponent.value,
 )
 return TerminalResult(status=TerminalStatus.STALEMATE, winner=None)

このあたりを GUI 上で即確認できるようにしておくと、「終局判定の実装が正しいか」と「その結果の見せ方が分かりやすいか」を同時に潰せます。

中身は「見た目」より「将棋AIの検証しやすさ」重視

今回のGUIは Tkinter ベースで、見た目の豪華さよりもまずは開発速度と検証効率を優先しています。

内部では、

将棋の盤面状態
合法手生成
局面評価
negamax 探索
MCTS による探索
自己対局用の状態遷移

といったAI側の処理を同じコードベースで使い回しています。

つまりこのGUIは、単なる「盤面を表示するアプリ」ではなく、今後の強化学習や自己対局の挙動確認にもそのまま使う前提のフロントエンドです。

将棋AI開発の初期段階でよかった点

ルール実装の違和感に早く気づける
AIの手が弱いのか、そもそも探索や終局判定が怪しいのかを切り分けやすい
自己対局や学習結果をあとで可視化する土台になる
棋譜保存があるので、気になった局面を後から追いやすい

特に「強化学習に入る前の将棋エンジン確認ツール」としてはかなり有効でした。
見えているだけで、デバッグの心理的ハードルがかなり下がります。

今後やりたいこと

学習済みチェックポイントをGUIから切り替えて対局できるようにする
自己対局の進行状況や勝率をもっと見やすくする
評価推移だけでなく、候補手や探索回数も表示する
棋譜の読み込み対応
強化学習で育ったモデルと人間が対局しやすい形に整える

最終的には、「将棋GUIを作った」で終わりではなく、ここから自己対局と学習を回して、少しずつ自前の将棋AIとして形にしていきたいと思っています。

まとめ

自前で将棋AIを作るつもりなら、いきなり学習コードだけを書くより、先に盤面をちゃんと見られる環境を作っておく方がたぶん楽です。

今回作った将棋GUIは、そのための土台であり、「自前で将棋AIを作ろうプロジェクト」の第一弾でもあります。
将棋AI本体より一見地味ですが、合法手、成り、持ち駒、終局、探索結果を人間が直接確認できる環境があるだけで、後の開発がかなり進めやすくなります。

次はこの土台の上で、評価関数を自作して、強化学習なしの状態でどこまで戦えるかを試す予定です。

要するに第二弾は、「評価関数を自作して強化学習0で対戦してみる」 になります。

続き（第二弾）はこちらです。

Pythonで自作した将棋AIと対局してみた｜学習前でも探索回数がかなり重要だった実装ログ

その先では、どれだけ学習させたら自分（将棋ウォーズ初段）が敵わなくなるのか、そしてそこまで本当に自力で学習させられるのかを試してみたいと思っています。
今回は外部の棋譜や定石は学習させない前提なので、かなり遠回りになるはずですが、そのぶんどこまで伸びるのかは普通に楽しみです。

ffmpeg loudnorm の使い方｜LUFS正規化と2pass設定をコマンド例で解説

Sun, 08 Mar 2026 00:00:00 +0900

この記事でやること

ffmpeg の loudnorm フィルタを使って、音声ファイルの音量を LUFS ベースで揃える方法をまとめます。

「コマンドを貼って終わり」ではなく、次の点まで押さえます。

LUFS とは何か
loudnorm の主要パラメータの意味
1pass と 2pass の使い分け
正規化後に必要な再エンコードの考え方
MP3 のタグやアートワークを落とさない方法

Python から ffmpeg を呼び出してまとめて処理する実装については、音楽の音量を自動調整するツールをPythonで作る LUFS正規化開発ログを参照してください。

前提
LUFS とは
まず試す：基本コマンド（1pass）
loudnorm の主要パラメータ
1pass と 2pass の使い分け
loudnorm でイントロが大きくなる理由
正規化後は再エンコードが必要
タグとアートワークを保持しやすくする基本設定
フィルタチェーンの考え方
実用テンプレート
まとめ

前提

ffmpeg 6.x 系が利用できること（導入はこの Qiita 記事を参考）
主な対象は MP3 だが、考え方は AAC / WAV / FLAC でもほぼ同じ
コマンド例は PowerShell・bash どちらでも読み替えやすい形で記載

LUFS とは

LUFS（Loudness Units relative to Full Scale） は、ITU-R BS.1770 をベースにした、人が感じる音の大きさ（ラウドネス）を表す単位です。値は通常負の数で表され、0 に近いほど音が大きいことを意味します。

なお、デジタル音声の最大振幅の基準は 0 dBFS であり、LUFS はそれとは別の「知覚的なラウドネス」の指標です。TP（True Peak）の上限として 0 dBFS を参照するのはそのためです。

プラットフォーム別の配信実務における目安は次のとおりです。厳密な規格値ではなく、実運用上よく使われる参考値です。

プラットフォーム	目安 LUFS
YouTube / Spotify	-14 LUFS 前後
Podcast	-16 LUFS 前後
TV 放送（EBU R 128）	-23 LUFS

注記： Spotify は再生時にラウドネス正規化を行いますが、設定によって基準値が異なる場合があります（Loud / Normal / Quiet モード）。YouTube も「-14 LUFS を目標に書き出すべき」と公式仕様として明示しているわけではありません。配信先の最新仕様は各プラットフォームの公式ドキュメントで確認してください。

まず試す：基本コマンド（1pass）

細かい説明の前に、すぐ使える形を示します。

ffmpeg -i input.mp3 \
 -map 0 -map_metadata 0 -c:v copy \
 -af "loudnorm=I=-14:TP=-1.5:LRA=11" \
 -c:a libmp3lame -q:a 2 \
 output.mp3

各オプションの意味は以下のとおりです。

オプション	意味
`-i input.mp3`	入力ファイル
`-map 0`	全ストリーム（音声・アートワークなど）を出力に引き継ぐ
`-map_metadata 0`	ID3 タグなどのメタデータをコピーする
`-c:v copy`	アルバムアートを再エンコードせずそのままコピーする
`-af "loudnorm=..."`	ラウドネス正規化フィルタを適用する
`-c:a libmp3lame`	MP3 として再エンコードする
`-q:a 2`	VBR 高品質（平均約 190 kbps）

より正確に目標値へ合わせたいときは 2pass を使います。次のセクションから順に見ていきます。

loudnorm の主要パラメータ

loudnorm で押さえるべきパラメータは 5 系統です。

パラメータ	意味
`I`	目標 LUFS（Integrated Loudness）
`TP`	True Peak の上限
`LRA`	Loudness Range の目標値
`linear`	線形補正を使うかどうか
`measured_*`	2pass 用の測定結果を渡すパラメータ群

I（目標 LUFS）

「最終的にどの LUFS へ寄せたいか」を決める中心パラメータです。用途に合わせて次の値を基準にしてください。

I=-14：YouTube、Spotify
I=-16：Podcast
I=-23：TV など

TP（True Peak の上限）

サンプル間ピークまで含めた実効ピーク値の上限を設定します。波形上ではクリップしていなくても、再生・変換の過程でピークが 0 dBFS を超えてノイズが発生することがあります。これを防ぐため、少し余裕を持たせるのが一般的です。

迷ったら -1.5 dBTP 前後から始めるのが安全です。

LRA（Loudness Range）

曲の中の音量変動の広さを示します。値が大きいほど静かな部分と大きい部分の差が大きく、クラシックや映画音声では高くなりやすい傾向があります。

ジャンル / 用途	LRA の目安
ポップス / ロック	6〜10
EDM / ダンス	4〜8
一般的な音楽	6〜12
クラシック / 映画音声	12〜20

まずは I と TP を固めることを優先し、LRA は素材のジャンルや用途が明確なときだけ調整するのが実務上の流れです。迷ったら LRA=11 のままにしておいて問題ありません。

linear

linear=true を指定すると、音声全体を同じ倍率で上げ下げする線形補正になります。曲の抑揚はそのままに、全体を一様にシフトするイメージです。

2pass で測定結果を渡すときによく使われます。1pass では線形補正が完全には効かない場合があります。

measured_*

1 回目の測定で得た値を 2 回目に引き渡すためのパラメータ群です。対応関係は次のとおりです。

measured_*	1回目の出力値
`measured_I`	`input_i`
`measured_TP`	`input_tp`
`measured_LRA`	`input_lra`
`measured_thresh`	`input_thresh`
`offset`	`target_offset`

1pass と 2pass の使い分け

1pass

1 回の実行で解析と補正を同時に行います。シンプルで速いため、バッチ処理や手早い試行に向いています。

ffmpeg -i input.mp3 \
 -af "loudnorm=I=-14:TP=-1.5:LRA=11" \
 -c:a libmp3lame -q:a 2 \
 output.mp3

ただし、厳密に目標値へ合わせたい場面では 2pass よりブレが出やすくなります。

2pass

1 回目で測定し、その結果を 2 回目に渡して本番変換する方法です。目標ラウドネスへより安定して寄せられます。

1 回目：測定のみ（ファイルを書き出さない）

ffmpeg -i input.mp3 \
 -af "loudnorm=I=-14:TP=-1.5:LRA=11:print_format=json" \
 -f null -

-f null - により出力ファイルを作らず、JSON だけを取得できます。出力から次の値を拾います。

input_i
input_tp
input_lra
input_thresh
target_offset

2 回目：測定値を渡して本番変換

ffmpeg -i input.mp3 \
 -map 0 -map_metadata 0 -c:v copy \
 -af "loudnorm=I=-14:TP=-1.5:LRA=11:linear=true:measured_I=-18.3:measured_TP=-0.7:measured_LRA=9.5:measured_thresh=-29.2:offset=-0.1" \
 -c:a libmp3lame -q:a 2 \
 output.mp3

ツールとして実装する場合は、測定フェーズと本番フェーズを分けて設計しておくと扱いやすくなります。

loudnorm でイントロが大きくなる理由

loudnorm は曲全体の Integrated Loudness を見て補正量を決めます。静かなイントロだけを個別に判定しているわけではないため、次のような曲ではイントロが想定以上に持ち上がって聞こえることがあります。

イントロだけ極端に静かで、途中から急に音圧が上がる曲
もともとダイナミクスが広い音源

特に linear=true では全体を一様に上げ下げするため、サビに合わせて補正すると静かなイントロもまとめて大きくなります。TP はピークの上限を抑えるもので、体感音量が上がること自体は防げません。

対策として有効なのは次のとおりです。

1pass より 2pass でより安定した補正をかける
目標 LUFS を少し下げる
素材によっては前段の編集や別のダイナミクス処理を組み合わせる

正規化後は再エンコードが必要

loudnorm のような音声フィルタを使う場合、音声はデコード → 処理 → エンコードの流れが必要になります。ストリームコピー（-c:a copy）では済まないため、必ずコーデックを指定します。

-c:a libmp3lame -q:a 2

よく使う指定の考え方は次のとおりです。

オプション	説明
`-c:a libmp3lame`	MP3 として再エンコードする
`-q:a 2`	VBR 品質指定。数値が低いほど高音質（0〜9）
`-b:a 192k`	CBR や ABR でビットレートを明示したいときに使う

音質とサイズのバランスを取りたいなら、まずは -q:a 2 か -q:a 3 から始めるのが実用的です。

タグとアートワークを保持しやすくする基本設定

MP3 には音声以外にも、メタデータ（ID3 タグ）とアルバムアート（画像ストリーム）が含まれています。オプションを省略すると「音は出るがジャケットが消えた」「タグが落ちた」という事故が起きやすくなります。

-map 0 -map_metadata 0 -c:v copy

オプション	意味
`-map 0`	入力の全ストリームを対象にする
`-map_metadata 0`	メタデータを入力からコピーする
`-c:v copy`	画像ストリームを再エンコードせずコピーする

MP3 の埋め込みジャケットは内部的に画像ストリームとして扱われます。音声だけを明示して出力すると、画像ストリームがマッピング対象から外れて消えます。アートワークを保持したいなら、この 3 つをセットで指定するのが基本です。

ただし、独自の ID3 フレームや埋め込み歌詞など、入力ファイルの構造によってはこの設定だけでは完全に保持されないケースもあります。変換後にタグの欠損が気になる場合は id3v2 や eyeD3 などの専用ツールで確認・修正するのが安全です。

フィルタチェーンの考え方

-af を使うと、複数のフィルタをカンマでつないで順番に適用できます。

ffmpeg -i input.mp3 \
 -af "afftdn,agate,loudnorm=I=-14:TP=-1.5:LRA=11" \
 -c:a libmp3lame -q:a 2 \
 output.mp3

よく使われるフィルタの役割は次のとおりです。

フィルタ	用途
`loudnorm`	ラウドネス正規化
`afftdn`	ノイズ除去
`agate`	ノイズゲート

ただし、ノイズ除去やゲートは素材によって効きすぎることがあります。まずは loudnorm 単独で正規化を安定させてから、必要であれば前処理を足すほうが安全です。

実用テンプレート

まず試す：1pass

ffmpeg -i input.mp3 \
 -map 0 -map_metadata 0 -c:v copy \
 -af "loudnorm=I=-14:TP=-1.5:LRA=11" \
 -c:a libmp3lame -q:a 2 \
 output.mp3

精度を上げる：2pass

1 回目（測定）

ffmpeg -hide_banner -i input.mp3 \
 -af "loudnorm=I=-14:TP=-1.5:LRA=11:print_format=json" \
 -f null -

2 回目（本番変換）

ffmpeg -i input.mp3 \
 -map 0 -map_metadata 0 -c:v copy \
 -af "loudnorm=I=-14:TP=-1.5:LRA=11:linear=true:measured_I=...:measured_TP=...:measured_LRA=...:measured_thresh=...:offset=..." \
 -c:a libmp3lame -q:a 2 \
 output.mp3

... の部分に 1 回目の JSON から拾った値を入れます。

まとめ

ポイント	内容
目標値の決め方	まず `I` を決め、`TP=-1.5`、`LRA=11` を基準に調整
1pass vs 2pass	手軽さなら 1pass、精度重視なら 2pass
再エンコード	フィルタ使用時は `-c:a libmp3lame -q:a 2` が必須
タグ・アートワーク保持	`-map 0 -map_metadata 0 -c:v copy` をセットで指定
ツール化するなら	測定フェーズ（`-f null -`）と本番フェーズを分けて設計

Python からまとめて処理したい場合や、CLI で自動化したい場合は音楽の音量を自動調整するツールをPythonで作る LUFS正規化開発ログを参照してください。

Ryzen 5 7600＋RTX 4070 Superの自作PC構成例｜16.3万円の開発・AI実験向け実例

Thu, 05 Mar 2026 00:00:00 +0900

2024年11月のブラックフライデーセールで購入した構成です。
最新ではないものの、開発・ローカルAI実験の両立という観点ではいまも満足度が高いので、実例として紹介します。

主な用途

日常的な開発作業（エディタ・ビルド・Docker・DB）
ローカルLLM・AI実験
重すぎないゲーム

買い替えた理由

前のGPUは GTX 760（Kepler世代、CUDA Compute Capability 3.0）だった。
PyTorchやTensorFlowの近年のバージョンはCUDA 3.5以上、あるいは5.0以上を要件とするものが多く、ライブラリの要件を満たせずローカルでのAI実験が実質困難な状況だった。

ローカルで推論・ファインチューニングを試せる環境を整えるために、今回の構成へ移行した。

構成と購入価格

パーツ	型番・仕様	価格	購入店
CPU＋MB＋RAM セット	Ryzen 5 7600 / B650M Pro RS / DDR5 32GB	¥49,800	ソフマップ
GPU	RTX 4070 Super（VRAM 12GB）	¥93,500	ドスパラ
SSD	M.2 NVMe 500GB	¥5,590	ツクモ
ケース	Antec CX200 RGB Elite	¥6,380	PC工房
電源	650W 80PLUS Bronze	¥7,645	Joshin

合計: ¥162,915（税込）

※ すべてネット通販で購入。OS（Ubuntu）はライセンス費用なし。
※ HDD・サブSSDは既存資産を流用のため上記に含まず。

各パーツの選定理由

Ryzen 5 7600

AM5プラットフォームのエントリークラスに位置するが、シングルスレッド性能は高く、開発中の体感（エディタ操作・ビルド・日常操作）には十分と判断した。
マルチスレッドが主役になる用途（動画エンコード・大規模コンパイル等）ではより上位のCPUが有利になる場面もあるが、本構成の主目的には過剰投資と判断してコスト圧縮に充てた。

RTX 4070 Super（VRAM 12GB）

ローカルAI実験では、VRAMがロードできるモデルサイズの上限を直接規定する。
7B〜13Bパラメータクラスのモデルをfloat16で動かす場合、目安として14〜26GB前後のVRAMが理想だが、量子化（GGUF / AWQ等）を活用すれば12GBでも7B〜13Bクラスは実用的に扱える。
予算内でVRAMを最大化する選択として採用した。

メモリ 32GB（DDR5）

Docker・IDE・ブラウザ・DBを同時に起動する開発環境では、16GBでは用途によって不足が生じやすい。
32GBを選択したのは「余裕を持った実用容量の確保」が主な理由で、当時の価格が安かったことも追い風になった。
なお、必要な容量は用途やDockerイメージの構成次第で変わるため、あくまで本構成の判断基準として参考にしてほしい。

Ubuntu運用

OS費用をゼロにすることで、削減分をGPU・メモリに充当した。
AI・開発ツールのエコシステムとの親和性も高く、本用途では合理的な選択と判断している。

省スペース化：microATXを選んだ経緯

前のPCはATXフルタワーで、設置スペースを取りすぎていた。
今回はmicroATX構成に切り替えて省スペース化を図った。

ケース（Antec CX200 RGB Elite）はレビューでも指摘されているとおり組み立てに難があり、内部スペースが限られるため配線はやや窮屈になる。
ただし完成後の外観は満足度が高く、トータルでは及第点以上の選択だった。

構成の割り切りポイント

電源：非モジュラーを選択
650W・80PLUS BronzeはRTX 4070 Super（TDP220W）＋Ryzen 5 7600（65W）の構成に対して容量的に問題ない。
フルモジュラー電源は余剰ケーブルの取り回しが楽になるメリットがあるが、価格差を他パーツに回す判断でノンモジュラーを選んだ。

見た目より性能単価を優先
ケースが白のため、GPUも白で揃えたかったが、外装カラーだけで数万円高くなる選択肢は費用対効果が見合わないと判断して断念した。

ストレージは既存資産を流用
HDDとサブSSDは旧構成から持ち越し。新規購入はOS用のM.2 NVMe（500GB）のみとし、総額を抑えた。

組み立て時の注意点

M.2 Wi-Fiカードを後付けする場合

このケースでM.2 Wi-Fiアダプタを後付けする場合、マザーボードから背面スロットに引くアンテナ線の経路が長くなり、取り回しがかなりタイトになる。
後から追加する予定がある場合は、組み立て前にアンテナ線のルートを確認しておくことを勧める。

まとめ

「使うところにだけ予算をかける」方針で組んだ構成。

GPU：VRAMを重視し、予算の過半を投入
CPU：開発用途の体感を確保しつつコスト圧縮
メモリ：Docker・IDE同時利用を想定して32GBを確保
OS・ストレージ：無料OS＋既存資産流用で節約

合計16.3万円で、開発とローカルAI実験を現実的に回せる環境を構築できた。
購入当時の価格のため現在の市場価格とは異なるが、構成の参考になれば幸い。

SeleniumでChromeDriverを自動取得するPythonツールを作った

Wed, 04 Mar 2026 00:00:00 +0900

GitHub: mitz17/get-chrome-driver

作った理由

Selenium でスクレイピングやブラウザ自動操作をしていると、Chrome の自動更新が原因で ChromeDriver とのバージョン不一致が突然起きることがあります。実際に次のようなエラーでテストが止まる場面が何度かありました。

SessionNotCreatedException
This version of ChromeDriver only supports Chrome version XX
Current browser version is YY

Selenium で Chrome を操作するには、インストール済みの Chrome と互換性のある ChromeDriver が必要です。ただし Chrome は自動更新されるため、毎回対応する ZIP を探して展開し、実行環境へ配る運用はすぐに面倒になります。

さらに 2023 年以降は、ChromeDriver の配布が Chrome for Testing (CfT) API に集約され、過去の固定 URL を前提にした方法では最新の互換ドライバを安定して取れなくなりました。そこで、次の処理を自動化する get-chrome-driver を作りました。

Selenium 実行前に ChromeDriver のバージョン不一致を自動解消する

実行環境に入っている Chrome のバージョンを調べる
CfT API から一致する ChromeDriver を取得して保存する
必要なら Selenium で実行確認まで行う

この記事では、その処理の流れと使い方をまとめます。

処理の流れ

1. インストール済み Chrome のバージョンを取得する

# get_chrome_driver/utils.py
def get_chrome_version():
 system = platform.system()
 if system == "Windows":
 import locale
 encoding = locale.getpreferredencoding()
 paths = [
 r'reg query "HKEY_CURRENT_USER\Software\Google\Chrome\BLBeacon" /v version',
 r'reg query "HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Google Chrome" /v version'
 ]
 for cmd in paths:
 try:
 raw_output = subprocess.check_output(cmd, shell=True, stderr=subprocess.DEVNULL)
 try:
 output = raw_output.decode(encoding)
 except UnicodeDecodeError:
 output = raw_output.decode('cp932', errors='replace')
 match = re.search(r'version\s+REG_SZ\s+([\d\.]+)', output)
 if match:
 version = match.group(1)
 break
 except subprocess.CalledProcessError:
 continue
 elif system == "Linux":
 commands = ["google-chrome", "google-chrome-stable", "chromium", "chromium-browser"]
 for cmd in commands:
 try:
 output = subprocess.check_output([cmd, "--version"]).decode().strip()
 match = re.search(r'[\d\.]+', output)
 if match:
 version = match.group(0)
 break
 except (subprocess.CalledProcessError, FileNotFoundError):
 continue

Windows ではまずレジストリを確認し、見つからなければ後続処理で chrome.exe の ProductVersion も参照します。Linux では google-chrome や chromium-browser など複数の候補コマンドを順番に試し、macOS では --version の出力を解析します。

2. CfT API 用のプラットフォーム名を決める

# get_chrome_driver/api.py
def get_platform_string():
 os_name = platform.system()
 arch = platform.machine()
 if os_name == "Linux":
 return "linux64"
 elif os_name == "Darwin":
 if arch == "arm64":
 return "mac-arm64"
 return "mac-x64"
 elif os_name == "Windows":
 if sys.maxsize > 2**32:
 return "win64"
 return "win32"
 return None

CfT API の JSON に合わせて、実行環境を linux64 mac-arm64 mac-x64 win64 win32 のような識別子に変換します。Windows では Python が 64bit かどうかを基準に判定しています。

3. CfT API から対応するダウンロード URL を探す

# get_chrome_driver/api.py
def get_driver_download_url(chrome_version, platform_name):
 major_version = chrome_version.split('.')[0]
 try:
 response = requests.get(KNOWN_GOOD_URL, timeout=30)
 response.raise_for_status()
 version, url = _extract_from_versions(response.json().get('versions', []), major_version, platform_name)
 if url:
 return url
 except Exception as e:
 print(f"CfT known-good lookup failed: {e}")

 try:
 response = requests.get(LAST_KNOWN_GOOD_URL, timeout=30)
 response.raise_for_status()
 payload = response.json()
 version, url = _extract_from_versions(payload.get('versions', []), major_version, platform_name)
 if url:
 return url
 version, url = _extract_from_channels(payload.get('channels', {}), major_version, platform_name)
 if url:
 return url
 except Exception as e:
 print(f"CfT last-known-good lookup failed: {e}")

 return None

まず known-good-versions-with-downloads.json を参照し、見つからなければ last-known-good-versions-with-downloads.json の versions と channels を順に確認します。完全一致ではなくメジャーバージョン一致で探すため、細かいビルド番号の差があっても実用上の互換ドライバを見つけやすくしています。

4. 既存のドライバが使えるかを先に判定する

# get_chrome_driver/core.py
existing_version = self._get_installed_driver_version()
target_major = version.split('.')[0]
if existing_version:
 existing_major = existing_version.split('.')[0]
 if existing_major == target_major and self.driver_path.exists():
 print(f"Existing ChromeDriver version {existing_version} is compatible.")
 return str(self.driver_path)
 else:
 print(f"Updating ChromeDriver: {existing_version} -> major {target_major}")

すでに保存済みの ChromeDriver があり、メジャーバージョンが一致していれば再ダウンロードはしません。互換性が崩れたときだけ更新します。

5. ZIP を安全に展開して保存する

# get_chrome_driver/core.py
response = requests.get(url, timeout=30)
with zipfile.ZipFile(io.BytesIO(response.content)) as z:
 driver_member = None
 for member in z.infolist():
 member_path = os.path.normpath(member.filename)
 if os.path.isabs(member_path) or member_path.startswith(".."):
 continue
 if os.path.basename(member_path) == self.driver_name:
 driver_member = member
 break
 with z.open(driver_member) as source, open(self.driver_path, "wb") as target:
 shutil.copyfileobj(source, target)
if os.name != "nt":
 self.driver_path.chmod(0o755)

ZIP 内に .. や絶対パスを含むエントリがあっても無視し、chromedriver または chromedriver.exe 本体だけを取り出します。macOS と Linux では展開後に実行権限も付けます。

6. Selenium で起動確認する

# get_chrome_driver/core.py
options = Options()
options.add_argument("--headless")
options.add_argument("--no-sandbox")
options.add_argument("--disable-dev-shm-usage")
service = Service(executable_path=driver_path)
driver = webdriver.Chrome(service=service, options=options)
driver.get("https://google.com")
title = driver.title
driver.quit()

GetChromeDriver.validate() はこの確認を実行し、Chrome が起動して Google に到達できれば成功とみなします。CI や閉域環境のように検証を省きたい場合は、main.py --no-validate でスキップできます。

使い方

前提

Python 3.8 以上
Chrome がインストールされていること
ネットワークに接続できること

セットアップ

# リポジトリを取得して仮想環境を作成
cd C:\workspace\projects
python -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install -r get-chrome-driver\requirements.txt

基本コマンド

# ChromeDriver を取得し、ヘッドレス Selenium で動作確認する
python main.py

# 現在の Chrome バージョンだけ確認する
python main.py --check

# ドライバ取得だけ行い、Selenium 検証は省略する
python main.py --no-validate

取得した ChromeDriver は ~/.get-chrome-driver/ に保存されます。Windows では通常 C:\Users\<username>\.get-chrome-driver\ です。PATH に追加しなくても、Selenium 側で driver_path を明示すれば使えます。

Selenium スクリプトから直接使う

CLI を単発で使うだけでなく、テストコードの中で GetChromeDriver を呼ぶと、実行前に毎回ドライバをそろえられます。

from get_chrome_driver.core import GetChromeDriver
from selenium import webdriver
from selenium.webdriver.chrome.service import Service

installer = GetChromeDriver()
driver_path = installer.install()
service = Service(executable_path=driver_path)
driver = webdriver.Chrome(service=service)
# ここから Selenium の処理を書く

Chrome が自動更新された直後でも、先にこの処理を通しておけば対応する ChromeDriver を取得できます。ダウンロード結果は ~/.get-chrome-driver/ にキャッシュされるので、毎回取り直す必要もありません。

まとめ

get-chrome-driver を使うと、ChromeDriver のバージョン不一致を実行前に自動で解消できます。CfT API の仕様変更があっても、基本的には api.py の取得ロジックを追従すれば対応しやすい構成にしてあります。Selenium の準備作業を減らしたいときに便利な小さなツールです。

Power Automateで前月分データをSharePointからExcelへ出力する方法｜落とし穴も解説

Tue, 03 Mar 2026 18:05:00 +0900

Power Automateで前月分データをSharePointからExcelへ出力する方法｜落とし穴も解説

この記事では、Power Automate を使って次の処理を自動化する際に詰まりやすかったポイントをまとめます。

毎月1日に自動実行する
SharePoint Online リストから前月分のデータを取得する
Excel テンプレートをコピーして新しいファイルを作る
取得したデータを1件ずつ Excel テーブルに追加する
必要に応じて PDF 化する

先に結論

Power Automate で前月分データを SharePoint から Excel に出力する場合、特に詰まりやすいのは次の4点です。

SharePoint の列は表示名ではなく内部名で扱う必要がある
前月フィルターは日付条件を明示しないと取りこぼしや余計な取得が起きやすい
Excel 側はテーブル化が必須で、表に行を追加 には 1 行オブジェクトが必要
実行成功直後でも、Excel への保存反映に少し時間差がある

この4点を先に理解しておくと、かなり詰まりにくくなります。

前提条件

今回の前提は次のとおりです。

Power Automate のクラウドフローを使う
データ元は SharePoint Online リスト
出力先は Excel Online のテーブル
毎月1日に前月分だけを抽出して出力する

フロー全体

今回やりたかったフロー全体はこうです。

スケジュールで毎月1日に実行
SharePoint Online リストから前月分データを取得
Excel テンプレートをコピーして当月用ファイルを作成
Apply to each で 1 件ずつテーブルへ追加
保存反映を待ってから後続処理を実行
必要に応じて PDF 化

個々のアクション自体は珍しくありませんが、つなぎ込みでハマるポイントが多い構成でした。

用語を最小限だけ整理

Power Automate

Microsoft の自動化ツールです。
トリガーとアクションをつないで、クラウド上で処理を流せます。

SharePoint Online リスト

表形式でデータを持てるリストです。
今回の用途では、利用日や所属、氏名などを持つ一覧データとして使っています。

フィルタークエリ

SharePoint Online から取得するデータを条件付きで絞り込むための式です。
前月分だけ取得したいときはここが重要になります。

Excel テーブル

Power Automate の 表に行を追加 は、ただのセル範囲ではなく Excel のテーブルを対象にします。
テーブル化されていないシートに対しては基本的にうまく動きません。

内部名

SharePoint Online の列には、画面上の表示名とは別に内部名があります。
日本語列では特に、内部名がエンコードされたような形になりやすいです。

1. SharePoint の列名が表示名のままでは使えない

起きたこと

利用日、所属、氏名 のような列をそのまま参照しても、式の中で正しく読めませんでした。

保存時には、Apply_to_each や 表に行を追加 まわりでテンプレートエラーが出ることもありました。

原因

SharePoint の取得結果では、表示名と内部名が一致しないことがあります。
たとえば 利用日 は、実際には次のようなキー名になっていました。

表示名: 利用日
内部名: OData__x5229__x7528__x65e5_

このため、式で ['利用日'] を指定しても存在しない扱いになります。

対処

フローをテスト実行して、複数の項目の取得 の出力を確認します。
生データを見ると、実際に使うべきキー名が分かります。

Power Automate で SharePoint を扱うときは、「表示名ではなく内部名を使う」が基本だと考えた方が安全です。

2. 前月フィルターは日付条件を具体化した方がよい

タイトルどおり「前月分データを出力する」フローにしたいなら、フィルター条件を曖昧にしない方がよいです。

考え方としては、

前月の開始日以上
今月の開始日未満

の 2 条件で範囲指定するのが分かりやすいです。

たとえば利用日列の内部名が OData__x5229__x7528__x65e5_ なら、概念的には次のような条件になります。

OData__x5229__x7528__x65e5_ ge 前月初日
and
OData__x5229__x7528__x65e5_ lt 今月初日

実際の式は環境や列型に合わせて調整が必要ですが、
「前月っぽい文字列でなんとなく絞る」のではなく、日付の開始・終了で範囲を切る方が安定します。

3. Excel の `表に行を追加` はテーブル前提

起きたエラー

最初の方で出たのがこれです。

A value must be provided for item

原因

表に行を追加 の item は、単一セルの値ではなく「1 行分のオブジェクト」を要求します。
さらに、追加先の Excel 側はテーブル化されている必要があります。

つまり必要なのは、

Excel シートをテーブル化しておく
1 行分のデータをオブジェクトとして渡す

の 2 点です。

実際のイメージ

{
 "利用日": "2026/02/17",
 "所属": "鰻屋",
 "氏名": "藤井"
}

この形で 1 件ずつ Apply to each から渡していくと、意図した動きに近づきます。

4. 成功しているのに Excel が空に見えることがある

起きたこと

Power Automate 上では成功になっているのに、Excel を見ると何も入っていないように見えました。

実際はどうだったか

実行履歴を見ると、

statusCode: 200
追加した行データ

は返ってきていました。
つまり処理そのものは成功していました。

原因

問題は、処理成功から実際の保存・反映まで少し時間差があることでした。
体感では 30 秒程度のラグがあるケースがありました。

対処

後続処理に進む前に 遅延 を入れて、保存反映の待ち時間を確保しました。
クラウドフローの成功表示だけを見てすぐ次へ進むと、見た目上「空に見える」ことがあります。

5. 本番移行時に接続破損が起きることがある

発生したエラー

'表に行を追加' の接続が破損しています。
接続を修正してください。

原因

Power Automate の接続は、次の情報に紐づきます。

ユーザーアカウント
環境（開発 / 本番）
認証トークン

そのため、開発環境で作った接続が本番環境ではそのまま使えないことがあります。

確認方法

方法1: アクション単位で確認

フローを編集モードで開く
問題のアクションをクリック
右側パネル上部の接続欄を確認する

方法2: 接続一覧から確認

左メニューから データ
接続
エラー状態の接続を探す

対処

接続を修正 を押す
新しい接続を作成する
必要なら問題のアクションを作り直す

私の環境では、再認証だけで直らず、失敗していたブロックを削除して作り直した方が早いケースもありました。

まとめ

Power Automate で SharePoint Online の前月分データを Excel に出力する処理自体は実現できますが、次の点でつまずきやすいです。

SharePoint は内部名で扱う
前月フィルターは日付範囲で考える
Excel 側はテーブル化が必須
保存反映の遅延を考慮する
本番環境では接続破損も疑う

個々のアクションだけを見ると簡単そうでも、実際には「つなぎ込み」でハマりやすいので、
最初にこの5点を意識しておくとかなり進めやすくなるはずです。

【初心者向け】Cloudflare Email Routingの設定方法｜独自ドメインのメールをGmailで受信する手順

Mon, 02 Mar 2026 12:00:00 +0900

この記事でやること

独自ドメイン mitz17.com でメールアドレスを作り、Cloudflare Email Routing を使って Gmail へ無料で転送。サーバー構築なし、ほぼノーコードで完結した。

参考にした資料

CloudflareのEmail Routingでカスタムドメイン宛メールを受信する手順

操作1: Cloudflare でドメインの管理画面を表示

手順

Cloudflare にログイン。
対象ドメイン（今回は mitz17.com）を選択。

操作2: 開始ボタンを押す

手順

左メニューの「メールアドレス」→「Email Routing」を開く。
「開始」をクリック。

操作3: アドレスの設定

手順

「カスタムアドレス」に好きなメールアドレスを入力
（例: mitz17@mitz17.com）
「宛先」に転送したい Gmail アドレスを入力
「作成して続行」をクリック

すると Gmail に確認メールが届く。

メール内の “Verify email address” をクリックすれば認証完了。

だいたい数分待てば設定が反映される。

操作4: 受信テスト

手順

外部アドレスからテストメールを送る。

Gmailに届けば成功。

届かない場合は：

MXレコードが間違っている
まだDNSが反映されていない
認証が終わっていない

このあたりをチェック。

まとめ

Cloudflare Email Routing と Gmail で自分のドメインのメールを受け取れるようになりました。

受信は簡単。

問題は「送信側」。(らしい)

SendGrid の無料プランがサ終したそうなので、
Mailgun か AWS SES あたりを検討中。

次は送信環境を作る。

MP3の音量がバラバラな問題、ffmpegで一発解決｜Python製ツールの使い方と仕組み

Mon, 02 Mar 2026 00:00:00 +0900

GitHub: mitz17/mp3-normalizer

MP3の音量がバラバラで困っていませんか？

昔作った MP3 を久しぶりに再生したら「あれ、音ちいさくない？」と感じたことはありませんか。ファイル自体は壊れていないのに、曲ごとに音量がまちまちで、再生のたびにボリュームを手動調整している──そんな悩みを ffmpeg の loudnorm フィルタ と Python 製ツール「mp3-normalizer」 で丸ごと解決します。

このツールでできることを先にまとめます。

フォルダ内の MP3 を まとめて -14 LUFS に正規化（業界標準値）
GUI でも CLI でも 同じエンジンで処理できる
ID3 タグ・歌詞・アートワークを保ったまま再エンコード
処理済み履歴を JSON で管理し、二重処理・上書きを自動防止

ffmpeg の `loudnorm` とは？

loudnorm は ffmpeg に組み込まれた音量正規化フィルタです。波形のピーク値ではなく LUFS（Loudness Units Full Scale） という人間の聴感に近い指標を基準にするため、曲ごとの「うるさい・静かすぎる」問題を自然に解消できます。

パラメータや 1pass / 2pass の仕組みを先に把握したい場合は、ffmpeg loudnorm 完全解説：LUFS正規化と2passノーマライズの仕組みにまとめています。

対象読者・前提環境

古い MP3 アーカイブを大切にしていて、音量だけさっと手直ししたい人
ffmpeg のコマンドを覚えていないけど、まとめて処理したい人
Python が書ける人で、実装の中身まで確認したい人

動作には Python 3.11 以上 と ffmpeg 6.x が必要です。ffmpeg の導入はこの Qiita 記事を OS ごとに手順をたどれば OK です。正規化したい .mp3 はフォルダにまとめておいてください（WAV など他形式は事前に変換するか、後述の拡張子設定で対応できます）。

セットアップ

# 1. リポジトリを取得
git clone https://github.com/mitz17/mp3-normalizer

# 2. 仮想環境を作成・有効化
python -m venv .venv
source .venv/bin/activate # Windows: .venv\Scripts\Activate.ps1

# 3. 依存パッケージをインストール
pip install -r requirements.txt

# 4. 起動
python main.py # GUI モード
python main.py --cli ... # CLI バッチ処理

使い方：GUI 編

入力・出力ディレクトリを指定すると、対象 MP3 がリストに表示されます。
LUFS と True Peak を入力。迷ったらデフォルト（-14 LUFS / -1 dBFS）のままで OK。
再帰チェック（サブフォルダを含むか）や強制再エンコードのトグルで挙動を調整。
「実行」を押すと進捗ログがリアルタイムで流れ、完了後に結果を確認できます。

入力/出力パス・ターゲット LUFS・対象ファイル一覧・ログを 1 画面で確認できます。

使い方：CLI 編

GUI なしでバッチ処理したいときはこちら。スクリプトやタスクスケジューラと組み合わせやすいです。

# 基本（入力・出力ディレクトリを指定）
python main.py --cli --input ./music_in --output ./music_out

# LUFS と True Peak を変更する場合
python main.py --cli --input ./music_in --output ./music_out --lufs -16 --tp -1.5

# 並列数を指定（デフォルトは CPU コア数）
python main.py --cli --input ./music_in --output ./music_out --workers 4

# 対象拡張子と出力形式を変更
python main.py --cli --input ./music_in --output ./music_out --ext flac --format aac

処理結果は mp3_normalizer.log に記録され、実行した ffmpeg コマンドごとの LUFS 値も残ります。

実装のポイント

アーキテクチャ概要

main.py
├── gui.py ─ Tkinter + ttk。別スレッドで ffmpeg を呼び出し UI フリーズを回避
├── processor.py ─ GUI / CLI 共通エンジン。ファイル走査・重複回避・正規化を担当
└── utils.py ─ パス生成・ログ整形などの汎用ユーティリティ

処理済みファイルは processed_history.json にサイズ・更新日時で記録され、再実行時に自動スキップされます。デフォルト（force=False）では既存ファイルへの上書きも行いません。

ファイル走査と重複回避

processor.py の AudioProcessor.process_directory では、入力ディレクトリを走査して処理計画を立て、衝突しそうなファイル名に _1, _2 のサフィックスを付加します（GitHub の該当コード）。

for index, entry in enumerate(plan.entries, start=1):
 destination = output_dir / entry.relative
 ensure_directory(destination.parent)
 destination = destination.with_suffix(".mp3")
 destination = generate_unique_output_path(destination)
 ...
 result = self.executor.normalize(
 input_file=entry.source,
 destination=destination,
 target_lufs=target_lufs,
 true_peak=true_peak,
 )
 results.append(result)
 if result.success:
 self.history_service.mark_processed(entry.relative, entry.size, entry.mtime)

self.history_service.save()

ffmpeg コマンドの組み立て

実際に ffmpeg を叩くのは FfmpegExecutor.normalize（コードはこちら）。コマンド全体をログに残すため、GUI からでも「裏で何をしているか」が一目でわかります。

command = [
 self.ffmpeg_cmd, "-hide_banner", "-y",
 "-i", str(input_file),
 "-af", f"loudnorm=I={target_lufs}:TP={true_peak}:LRA=11",
 "-c:a", "libmp3lame", "-q:a", "2",
 "-map_metadata", "0",
 str(destination),
]
command_str = format_command(command)
self.logger.info("ffmpeg コマンド: %s", command_str)
completed = subprocess.run(command, check=False, capture_output=True, text=True)

-map_metadata 0 で ID3 タグをそのまま引き継ぎ、mutagen ライブラリで歌詞タグを後から上書きコピーすることで、ffmpeg だけでは落ちてしまうタグも保持します。

アップデート履歴

日付	内容
2026-03-04	直列処理 → 並列処理対応。145 件の処理が 670 秒 → 207 秒（約 3.2 倍高速化）。Windows での文字コード処理を堅牢化
2026-03-05	mutagen を用いた歌詞タグのコピー処理を追加。正規化後も歌詞を保持可能に
2026-03-08	静かなイントロでの音量増大を抑制。入力ビットレートを検出して同等ビットレートで出力。入力拡張子・出力形式（mp3 / aac / flac / wav / ogg）を選択可能に。アートワーク保持を二段構えで強化
2026-03-18	既知の不具合：100 曲に 1 曲程度の割合でアーティストタグが消えるケースを確認。同一アルバム内でも再現条件が定まらず調査中。Issue を立てる予定。修正に協力いただける方はこちら

まとめ

Tkinter × ffmpeg という素朴な構成でも、MP3 音量の正規化はかなり快適にできる
GUI で直感操作・CLI でバッチ自動化、どちらでも同じ品質に揃えられる
古い MP3 をまだまだ活用したい人は、ぜひ mp3-normalizer をクローンしてみてください

【初投稿】技術ブログを始めました｜このブログで発信する内容

Sun, 01 Mar 2026 11:17:14 +0900

意気込み

はじめまして、mitz17です。ブログ、ハジメマシタ。

日々をちょっとだけ豊かにするためのプログラム開発とか、思いついたライフハックとか、作ってみたものの記録とか。

そんな感じのことを、備忘録がてらゆるっと書いていきます。

始めようと思ったきっかけ

「自分のドメインを持つ」って、なんかちょっとカッコよくないですか？

そんなノリで勢いよく取得しました。で、取ったはいいものの、特に壮大なビジョンがあったわけでもなく。

でも、ドメインって維持費(約￥1,500-)かかるんですよね。

私は毎月・毎年じわじわ削られていくいわゆる固定費が死ぬほど苦手です。

だったら――
ブログの広告で維持費くらい回収できればよくない？

途中で飽きる可能性はあります。でも、それも含めてログとして残っていたら面白いかなと思っています。

目標

このブログの広告収益で、ドメインの維持費をまかなうこと。

これが最初の10歩。

もざぶれなるままに

Pythonで自作した将棋AIと対局してみた｜学習前でも探索回数がかなり重要だった実装ログ

今回は「学習前のAI」と対局してみた

この時点の将棋AIの中身

実際に対局してみた印象

学習前のAIでは探索回数がかなり重要

開発ログとしての収穫

次にやりたいこと

まとめ

関連記事

Ansysのバージョン選択ツールを作った理由｜古い解析ファイルを別バージョンで開くリスクを減らす

作った理由

何をするツールか

対応しているもの

Fluent

SpaceClaim

Workbench

共通インターフェース

実装方針

コード上ではどう動いているか

共通処理: 設定保存と設定ダイアログ

Fluent: ファイル種別ごとにジャーナルを作る

Fluent: 2D/3D、DP、並列数も起動引数に反映

SpaceClaim / Workbench: できるだけ単純に起動

バージョン検出の考え方

Fluent だけ少しロジックが重い

使い方

Python スクリプトとして使う

初回起動時の流れ

EXE 化の方法

設定保存まわり

EXE 化も前提にした

使ってみて良かった点

まとめ

関連記事

Pythonで将棋AIを作るならまずGUI｜実装した理由と設計

開発のきっかけ

最終目標は「自前の強化学習将棋AIを育てること」

将棋AI開発でGUIを先に作った理由

Python製の将棋GUIでできること

将棋GUIで特に欲しかった確認ポイント

1. 合法手が直感どおりに選べること

2. 成りの扱いをその場で確認できること

3. 終局状態を見逃さないこと

中身は「見た目」より「将棋AIの検証しやすさ」重視

将棋AI開発の初期段階でよかった点

今後やりたいこと

まとめ

関連記事

ffmpeg loudnorm の使い方｜LUFS正規化と2pass設定をコマンド例で解説

この記事でやること

目次

前提

LUFS とは

まず試す：基本コマンド（1pass）

loudnorm の主要パラメータ

I（目標 LUFS）

TP（True Peak の上限）

LRA（Loudness Range）

linear

measured_*

1pass と 2pass の使い分け

1pass

2pass

loudnorm でイントロが大きくなる理由

正規化後は再エンコードが必要

タグとアートワークを保持しやすくする基本設定

フィルタチェーンの考え方

実用テンプレート

まず試す：1pass

精度を上げる：2pass

まとめ

関連記事

Ryzen 5 7600＋RTX 4070 Superの自作PC構成例｜16.3万円の開発・AI実験向け実例

目次

主な用途

買い替えた理由

構成と購入価格

各パーツの選定理由

Ryzen 5 7600

3. Excel の `表に行を追加` はテーブル前提