PyCon mini 東海 2025 に参加しました¶
11月08日（土）に、名古屋で開催された、PyCon mini 東海 2025に参加しました。 昨年 の初開催に続けて、2回目の開催です。
PyCon mini 東海 2025 ！¶
参加人数はconnpass上で50名（スタッフ等入れて60名前後）で当日LTありと、「昨年よりちょっとパワーアップ（by 座長）」でした。
トラック数は1つでキーノートを含むトーク8個、トラック2でワークショップ3個、と昨年と同様の構成でした。 ワークショップを覗きに行くのを忘れてしまいましたが、ある回は10人くらい参加者がいて賑わっていたようです。
そして、ランチも名古屋めし弁当が2種にパワーアップ、無限コーヒーあり（有限）の、相変わらずminiと言うには頑張りすぎている気もする盛りだくさんなイベントだったと思います。
イベント概要¶
- イベント名:
PyCon mini 東海 2025
- 公式ウェブサイト:
- 日付:
2025年11月08日（土）
- 場所:
名古屋市中区栄 中日ホール&カンファレンス
- 参加費:
パトロン10000円、一般3000円、学生1000円
私の参加時のメモ（blog元ネタ）が PyCon mini 東海 2025 - 清水川のScrapbox にあります。
開場～オープニング¶
1年ぶり2回目の名古屋駅 → 栄駅 → 中日ホール&カンファレンス（会場）ルートは迷わず移動できました。一番迷いそうになったのは名古屋で新幹線口をでてから東山線に乗り換えるところだったかもしれない。来年はもうナビなしで移動できそうです。
受付の様子¶
10時からオープニング開始。座長のりょうさんから「昨年よりちょっとパワーアップ」という紹介がありました。
オープニングトーク¶
キーノート¶
10:30 ~ 11:20
村橋 究理基
教育・研究現場で活用されるPython
キーノートの村橋さん¶
村橋 究理基さんのキーノートは、語り口が軽快で面白かった。「タイトルが固い」という自虐から始まり、開始15分でRubyの話を経てやっとPythonの話になるという展開。ご本人も、序盤Rubyの話をずっとしてる的なことを言いながら、Ruby松江シールを配ってました。
Ruby City MATSUE シール¶
島根大学での話が中心で、RaspberryPiでコマ撮りした写真をタイムラプス動画にしてYouTubeに上げているプロジェクトの紹介がありました（ [2025/11/06] タイムラプス 北海道大学から札幌駅方向 - YouTube ）。トーク全体は、主言語にPythonを使っているとか、講義や演習でPythonを教えているとかに関係なく、Pythonが色々な人に色々なところで使われていている言語だという現状でどう付き合っていっているか、ということの紹介だったと思います。
質疑応答では、島根大学でのPython教育について質問が出ました。公式には各学科でPythonを教えていることにはなっていないけれど、解析にはmatplotlibなどが必要で独学で学んでいるし、教員も教えているとのこと。Ruby振興に松江市がお金を出しているという大人の事情もあるそうですが、C/C++はしっかり教えて、それゆえPythonを独学で学べる程度の基礎力を付けているので、あとは独学できるという話でした。
トークセッション（午前）¶
PyScriptとOpenCVを使ってWebで画像処理AI¶
11:35 ~
高橋 かずひと
PyScriptとOpenCVを使ってWebで画像処理AI
高橋 かずひとさんのトークは、PyScriptの実践的な活用例でした。
高橋 かずひとさん¶
PyScriptでは、NumPy、OpenCV、Pillowが使えて、TensorFlowやPyTorchの代わりにOpenCV DNNを使うことでAI画像処理が実現できるとのこと。そして、PyScriptでメディアデバイス（Webカメラ）にアクセスしてオンデマンドで物体検知するデモで会場から良い反応がありました。インストール無しでここまで出来るのはすごい。
デモではYOLOを使った物体検出を見せてくれましたが、推論自体はそんなに遅くないけどCanvas反映が遅いという課題があるそうです。create_proxy を使うと速いけどメモリリークがあったので今回は避けたとのこと。
今回のスライドは全てGitHub Pagesで動作しているというのも面白いポイントでした。 そういえば昨年のPyCon mini 東海2024では、めっちゃ動くPowerPointスライドで会場を沸かせてたなあ。
質疑応答では、「Python処理系のWASM/WASI対応について」 （@aodag）、「PyOdideとPyScriptの違いについて」（@nikkie）、「OpenCV DNN も学習済みモデルを取り込めるのか？」（@terapyon）といった質問がありました。PyScriptの推しポイントは「Pythonそのままのソースコードをアップロードできる」ことと「PyOdideのラッパーとして使いやすくしている」ことだそうです。そして、他のTensorFlow等で作ったモデルをそのままOpenCV DNNで使えるが、これはまだ開発中で最新のモデルが使えないなどの制限がある、ということでした。
個人ではじめるマルチAIエージェント入門¶
12:05 ～ 12:30
Tomoko FURUKI (@komo_fr)
個人ではじめるマルチAIエージェント入門 〜LangChain × LangGraphでアイデアを形にするステップ〜
@komo_fr さんのトークは、 LangChain × LangGraph を使ったマルチAIエージェントの実装でした。インプットに対して複数のAI処理を行って結果を出す、その微調整の試行錯誤をめっちゃ楽にするためのフレームワーク群の紹介です。
児童文学サークル出身で、文学を小学校低学年向けに変換するAIエージェントを作ったときに使ったツールチェインを紹介するというものでした。マルチエージェントのお手本っぽいチャートもあり、分かりやすく、見ていてとても面白かったです。
楽に開発できるようにする工夫として、まずJSONを直に扱うと補完も効かず手間が多かったため、 Pydantic でデータ構造を定義してstructured outputsを利用するようにしたとのこと。さらに LangGraph を導入して、エージェントのワークフローをグラフ構造で定義し、各エージェントが扱うデータをステートとして受け渡せるようにすることで、処理の流れがかなり見通しよくなっていました。 graph.get_graph.draw_mermaid_png() でワークフローグラフを Mermaid 形式で出力できるのも便利そう。
（JSONだと型定義が活用できないので、スループットとのトレードオフはあるらしいですが良い選択だなと思いました。あと余談ですが、MCPサーバーの Structured Content をPydanticで実装したのを思いだしました）
また、 LangChain 開発元が提供する LangSmith を使って、実行ログを Web ダッシュボード上で評価、管理していました。 LangGraph の実行結果を人間が評価してコンソールからスコアを入力し、その評価を LangSmith に送ることでエージェントの振る舞いを改善していける、という話が、「実務で使う」感があって良かったです。
エージェントの質を上げる工夫として、作品でよく言及される名言や印象的なフレーズを TavilySearchAPIRetriever で Web から取得し、それを sentence-transformers によるコサイン類似度検索で原文から正確に拾ってくる、という流れを紹介していました。さらに、同じ作者の別作品の文体を模倣する「文体模倣エージェント」を追加して、子ども向けに書き換えても元の作品の雰囲気を維持できるようにしているのが印象的でした。
質疑応答では、「一番苦労したのは（スライドには書いていない）文体の部分」という話や、LLM のバージョン比較の話（ChatGPT-4.1, 4.5, 5 で比較したところ 4.5 が一番良かった、5 は短文になりがちだった）という裏話が面白かった。このあたりの泥臭い部分は、実際にやってみると難しくて、簡単には乗り越えられないだろうなあ。
ランチタイム¶
12:30 - 13:50
今回はお弁当が2種類！ 尾張御膳（おわりごぜん）と十二単（じゅうにひとえ）でした。
十二単¶
尾張御膳（フードロス対策で2つめを頂きました）¶
スクリーン前にコミュニケーションエリアが用意されていて、初めて会った人同士で話しやすい環境作りがされていました。
ランチの様子¶
トークセッション（午後）¶
Pythonでやってはいけないやってみるべきこと¶
13:50 -14:15
@aodag
Pythonでやってはいけないやってみるべきこと
@aodagさんのトークは、昼ご飯の後のまったりとした時間に技術の話をしますよ、という前置きから始まる、語り口が超おもしろいセッションでした。
@aodagさん¶
前半は、最近の mypy や ruff、pyright など静的解析ツールが充実してきた流れに対して「Pythonってダイナミックな言語なはずなのに静的型チェックとかなんなんだよ！」という、モダンPythonの「安全で窮屈」さの話。たしかに、ちょっとした雑なスクリプトがIDEで警告されるのは私も時々邪魔だなあと思ったりします。そこから「冒険的プログラミング」として、「あえて悪いことをしてみよう」「違う自分になってみよう」として cat.__class__ = Dog で cat.greet() # => わん になるコードを紹介。それでも「いくらやっても（壊そうとしても）、Pythonの手のひらから出られない、Pythonの手のひらってどこだよ」とか、漫談を目指したというトークはしっかり面白かった。さすがだなあ。
まとめとして挙げられていた「やってみるべきこと」は、
ふとした疑問を試してみる
さらに疑問を投げかける
黒魔術との境に気をつける
黒魔術に気付く
質疑応答では、「仕事でやらかしちゃった事ってありますか？」という率直な質問に対して、「存分に……本番のOracleのセッションをロックしたことがあります」とさらっと答えていました。また、__class__ の差し替えは仕様として禁止した方がいいのでは？という質問に「禁止して良いと思う」「Zopeの人たちはなんとかすると思うので良いと思います」という返しもあり、現実世界とのバランス感覚も含めて、とてもaodagさんらしいトークだったなあという印象でした。
APIのテストデータを自動生成できるSchemathesisの紹介¶
14:20 - 14:45
筒井 隆次 (@ryu22e)
APIのテストデータを自動生成できるSchemathesisの紹介
@ryu22e さんのトークは、Schemathesisを使ったAPIテストの自動化でした。
Schemathesis はOpenAPIドキュメントを使ってWebAPIエンドポイントをProperty-Based Testingで検証するテスティングツールです（詳しくはryu22eさんの資料 or https://scrapbox.io/shimizukawa/Schemathesis を参照）。
@ryu22e さん¶
Schemathesis が実装漏れのエッジケースを何度も見つけてくる状況に、「API実装を直したけど、まだコケる.. こんなデータでAPIエッジケースを見つけて来て正直ムカつきます」というぶっちゃけ感想から始まり、 Schemathesis がどうエッジケースを見つけてくるかを紹介してくれました。
Schemathesis は大量のテストケースを作りますが、キャッシュとテスト順序変更によって、次のテストでエラーになりそうなケースを優先的にテストして失敗時のエラーを早く出してくれるそうです。GitHub Actionsでこの動作を活かしたい場合は、 .hypothesis ディレクトリをキャッシュしておくと良いとのこと。
Schemathesis があれば「人間がテストを書かなくて良いのでは？」と考えるかもしれないが「そんなことはなかった」という結論でした。 Schemathesis のテストはどんなテストが行われるのか分からないしコントロールできず、テストコードから仕様を読み取れなくなるという課題があるそうです。使いどころは「エッジケースを見つける」「仕様と実装の乖離を見つける」というところ、ということでした。
稼働中のバッチアプリケーションを依存性逆転の法則でモダナイズ¶
14:55 - 15:20
fujidomoe
稼働中のバッチアプリケーションを依存性逆転の法則でモダナイズ - 型安全と堅牢なテストによるリプレイス戦略
資料（見当たらず）
fujidomoeさんのトークは、エンジニアでない方が書いたPythonコードをモダナイズした事例でした。
fujidomoe さん¶
ビジネスの根幹ではあるけど本番で動かすには安全ではないコードで、テストコードなし、試行錯誤の結果そのまま、Jupyter Notebookから始まったコードがほとんどそのまま本番バッチで動いている、という状態だったそうです。この状況を「dfが登場したら研究職と思え」と表現したのは、めっちゃ分かる。
アンチパターンとして挙げられていたのは、大きく2つ。ひとつは **kwargs で引数を処理していて、どこから何が渡ってくるのか見通しが悪くなっていること。もうひとつは、グローバル関数がたくさん増えてしまって、依存関係が分かりづらくなっていることでした。
対策として、Pydanticの導入による型安全とパラメータの明示化、リポジトリパターンとDIP（依存性逆転の原則）の導入で、 collection.abc を使ってメソッドの実装を強制し、インフラレイヤーがインターフェースだけを把握すればよい設計にしたとのこと。
対策としては、まず Pydantic の導入によって、型安全とパラメータの明示を行ったこと。 dataclass では型チェックが行われないのに対して、Pydantic を使うことで入力値のバリデーションをしっかり掛けられるようにしていました。次にリポジトリパターンとDIP（依存性逆転の原則）を導入し、 collections.abc を使ってメソッドの実装を強制することで、インフラレイヤー側は実装詳細ではなくインターフェースだけを把握すればよい構造にしていったとのこと。（私の活動領域ではこれはやり過ぎな気がするけど、Python標準で必要最小限の制約を加えているやりかたは良さそう）。
また、環境構築手順をREADMEからMakefileへ移行し、make docker/setup で完結、make docker/test でテストも実行できるようにしたそうです。質疑応答で「READMEが秘伝のたれになると言うけどMakefileも秘伝のたれになるのでは」という@aodagさんの質問に対して、「READMEは文章なので劣化に気付きづらいが、Makefileは壊れるとすぐ分かるのでまだマシ」という回答でした。
質疑応答では他に、Q「レイヤー構造化したことで逆に認知負荷が高まることはなかったか？」A「それ以前がノールールだったので、特に混乱はなかったです」。Q「レイヤー構造にみんながちゃんと沿ってくれるのか、どう強制するのか」A「もらうときは構造に沿ってなくても良いけど、そのまま本番に持っていくことは防いでいる。エンジニアが水際で防いでいます」というチームへの導入と運用の参考になりそうな話もありました。
型でつなぐFastAPI x フロントエンド活用術¶
15:35 - 16:00
三浦 耕生（@k_miura_io）
型でつなぐFastAPI × フロントエンド活用術
Miuraさんのトークは、FastAPIとフロントエンドの連携でした。名古屋のPython勉強会 鯱.py の運営もされている方です。
@k_miura_io さん¶
FastAPIの特徴として、軽量、高速、柔軟なファイル構成、型ヒントによる堅牢なAPI設計、OpenAPIドキュメント自動生成を挙げていました。私はあまりOpenAPIネイティブなフレームワークを使えていないので、良いなあ使いたいなあと思いながら聞いてました。
紹介してくれた Hey API は、OpenAPIドキュメントからTypeScript対応のAPIクライアントを生成してくれるツールで、FastAPIの公式で紹介されているそうです。
redoc というツールも紹介されていて、Swagger-UIよりもドキュメントっぽい出力ができるとのこと。たしかにSwagger-UIはツールっぽい感じです。聞きながら、 redoc は connpassのAPI(v2)リファレンス にも採用されていることを思い出しました。
質疑応答では、「Hey API知らなかったので勉強になりました。genというファイルは何者？(@terapyon)」A「genファイルはHey APIのアウトプットで、それを参照してクライアントを生成します」Q「Q. 本番で使っても大丈夫なもの？」A「大丈夫です」というやりとりがありました。
Pythonで構築する人口移動ナレッジグラフ¶
16:05 - 16:30
丹野良介（@negi111111）
Pythonで構築する人口移動ナレッジグラフ: GraphRagを用いた意味的地域検索への応用
丹野さんのトークは、GraphRagを用いた意味的地域検索への応用でした。
@negi111111 さん（人口移動ナレッジグラフは時間の都合で間に合わず、タイトル変更とのこと）¶
題材として使われていたのは SSDSE（Standardized Statistical Data Set for Education）という教育用標準データセットで、欠損値がなくデータ量も多く、解説PDFまで付いているという至れり尽くせりなデータセットとのこと。 SSDSE（教育用標準データセット） | 独立行政法人 統計センター で配布されています。公的機関がこういうちゃんとしたオープンデータを提供してくれてるんですね。
データ分析そのものは、昔ながらの「Pandasでゴリゴリ書く」スタイルからだいぶ変わってきていて、Vive Coding に任せて使われるものになったとのこと。データ把握をしようと思ったら Google Spreadsheet 一択で、Gemini が内蔵されているので自然言語で質問しながら探索している、というのはかなり2025年っぽいワークフローだと感じました。
テーブルデータから知識グラフ構造への変換ではNetworkXで扱えるグラフ構造に変換していきますが、ここもVive Codingに手伝ってもらって一発で作ってもらったそうです。スライドでは「知識グラフとは？」という図から始まり、RAGとは何か、そこからさらにGraphRAGとは何か、という流れで説明されていました（知識グラフって具体的に何？というのは私は掴みきれず）。
知識グラフとは¶
GraphRAG用のデータに変換したあとは、人口移動のデータを使って地域間の関係性をグラフとして表現し、意味的な地域検索に応用していく、というのがこのトークの肝です。ただし、知識グラフを動かすには、そこそこお金がかかるので注意、という現実的な話もありました。
質疑応答では、「GraphRAGデータベースというのはMicrosoftのもの？」という質問に対して、「RAGをGraph構造に拡張したのはMicrosoftだけれど、GraphRAG自体はデータベースというより、ファイル群を作ってそれをクエリできるようにしているようなもの」という説明がありました（私はよく分からず.. Vector Database に入れている訳ではない…？）。また、「市と市のつながりは作った？」という質問には、「名古屋から三重に移動したデータがあるのでそれを使ったが、今回はデータの関係のみ（重みなし）で扱っている」という回答でした。
休憩¶
会場のテラスに出たところ。
会場のテラス、去年作りかけだったビルが完成している！！¶
...と思ったら、まだ完成ではないらしい。
LT¶
当日募集のLTもあり、盛り上がりました。
16:50 - 17:10
Lightning Talks
@attakei さん
@attakei さん¶
「oEmbedPyを使って、ドキュメントに◯◯◯を埋め込もう」
oembed は民主的なフォーマットでメジャーどころは対応しているらしい
oEmbedPy を使えばSphinxドキュメントに簡単にoembedフォーマットの◯◯を埋め込める
埋め込みたくて探したけどPyPIにあった他のPythonクライアントはどれもメンテされてなかったので自分で作った
みその （miso taku）さん
みその （miso taku）さん¶
巡回セールスマン問題を数理最適化で解いてハシゴ酒の最短ルートを見つける（MIP, Google Maps API）
巡回セールスマン問題とは、組み合わせが膨大で簡単には解けない問題
数理最適化を解く MIP を使って最短距離でハシゴ酒するアプリをStreamlitで作成した
行ってきた -> 3軒でおなかいっぱい（会場笑
まとめ: ハシゴ酒に巡回セールスマン問題は必要ない
@takanory さん
@takanory さん¶
🐱絵文字をドキュメントにいれよう
クロージング¶
昨年同様、運営の皆さんの温かい雰囲気で締めくくられました。
司会進行で「座長からのあいさつ」を全部しゃべっちゃったｗ（右端に見切れてる座長）¶
プレゼント企画
おめでとうございます～¶
盛り上げ役のドラがだんだん上手になっていく¶
感想¶
2回目の開催ということで、昨年よりも少しパワーアップした内容で、とても楽しいイベントでした。 イベント運営されたみなさん、スピーカーの皆さん、ありがとうございました！
前回同様の1トラック構成は、聞く話を選べない代わりにどれを聞こうか迷うこともなく、そのおかげで普段聞かない分野のとても面白い話に出会えて良かったです。
懇親会は、昨年と同じ ワイマーケットのクラフト食堂 ナゴロバ¶
二次会も、昨年と同じHUB¶
おまけ¶
東京から名古屋に行く新幹線は本数がかなり多いので、自由席でもホームで少し待てば好きな席が選べます。……というのを何も考えずに出発直前のに飛び乗ったので窓側の電源が確保出来ず。
名古屋に着いてから、駅構内の"住よし"できしめんを頂きました。 去年はきつね。今年は山菜。次回はかき揚げにしよう。
住よし の きしめん（山菜）¶
7:39 東海道新幹線 東京駅発
9:16 名古屋着
9:30 住よしできしめんを頂く
9:40 東山線 名古屋 発
9:50 東山線 栄 着
10:00 会場着（中日ホール）
17:50 買い物（ベーカリーピカソ@三越）
18:20 懇親会（ワイマーケットのクラフト食堂）
21:38 地下鉄
21:43 名古屋駅着
21:50 東海道新幹線、名古屋発
23:39 東京駅着
