🚀

PyConJP 2025 参加レポート

に公開1件
Python
レポート
キャッチアップ
conference
イベント参加レポート
idea

PyConJP 2025 について

https://2025.pycon.jp/ja/venue

Python についての conference です。
Python といえばやはり機械学習用途が真っ先に思いつくので、AI 絡みばっかりかと思いましたが全然そんなことはなく、いろんな角度から発表がありました。
また、発表の難易度も幅広く、多くのリスナーを集めようといった気合いが感じられました。
登壇者も、ソフトウェア開発企業から研究機関が出身の方まで広かったです。

特に、公式サイト のタイムテーブルが丁寧で、各発表それぞれに「リスナーに求める前提知識」「難易度」「話すこと・話さないこと」が記載されており、1セクションあたり4つのプログラムが並行して行われていましたが、自分が聴きたい、と思えるやつをしっかり選べた感覚です。ぜひ他の conf. でも採用してほしい笑
セッションルームがいくつか離れた場所に配置されているものの、円滑に運営されていました。
1日の締めに忘れ物などを紹介されていたのも、いろいろとイベント参加した中で初めてだと思います👏

この記事に記載するのは私が参加したセッションの概要と主観の感想です。

Pythonで実現する堅牢なシステム設計 - イミュータブルがもたらす恩恵

概要

https://speakerdeck.com/masaya00/pythondeshi-xian-surujian-lao-nasisutemushe-ji-imiyutaburugamotarasuen-hui

  • ミュータブルな設計をして開発をしていた。運用が長くなるにつれ、問題点が浮上してきた
  • イミュータブルモデルを導入して解決した
  • 本筋ではないが、データモデリング手法の1例も紹介された

感想

JS でも mutable, immutable の話は出てくるので、Python でも共通の課題だな、と思い拝聴しました。
mutable, immutable の利点・欠点はよく話題に上がりますが、「監査」の観点で immutable が有利、というのは確かになと思いました。
ここでいう監査とは、主にデバッグのことを指しています。

データ保持専用のクラスのための Python の組み込みライブラリとして dataclass、外部ライブラリとして Pydantic が紹介されました。
Pydantic は dataclass よりもオーバーヘッドが大きい一方で、バリデーションが強力であるということ。
また、config の設定により、インスタンスを immutable にすることが可能になる。
イミュータブルモデルを Python で実現する際には必ず検討する選択肢の１つになるだろうなと思いました。
js では immer などがシェア率高いですかね

また、データモデリング手法の１例も紹介されていました。
最近 TM によるモデリングについて学んでいるので、共通する考え方と差分となる考え方、と切り分けて聞いていました。
リソースエンティティ・イベントエンティティの関係性は TM と同じで、その後の関係性をモデリングするところからは TM がより体系的に定義している、という印象です。

データの整合性やバグの少なさを重視すると immutable の利点が大きくなりますが、どうしてもパフォーマンスの問題がつきものであり、実際業務でこれが無視できないサイズの問題になったのか、伺いたい

フロントエンドエンジニアが Python エンジニアになって見えた世界！

https://speakerdeck.com/anfinii/hurontoentoensiniaka-python-enzinianinatutejian-etashi-jie

概要

  • js/ts と Python の違いについて、下記の観点からスピーカーの見解が説明された

感想

登壇者のスキルセットが私と被るところが多かったので、興味があり拝聴しました。
ts と Python の言語的な仕様の違いの紹介がされていました。
ts と Python 両方のスキルスタックを持っている人前提の発表です。
「フロント」に限った発表はありませんでした。
ts 経験者が Python に着手する際に資料を読むとキャッチアップが早くなると思います。

js/ts の undefined/null がバグを生み出すのはよくありますが、Python は None でシンプル、ということでした。
Python で API 書いたことないんですが、Python 圏内で null を扱うときは None として扱うんですかね？
API の定義では null となっているのに Python の中では None と扱われるのだとしたら違和感あるなと思いました。慣れの問題だと思いますが😅

テンプレートリテラルについて、Python はフォーマットを指定できる点で機能としては充実しているそうです。Python で API 書いてみたことがないので知らなかったですが、これは地味に嬉しいですね😃
ts のテンプレートリテラルの利点としては ts の型定義にテンプレートリテラルを使える(≒文字列に制約を加えたり, 文字列から値を推論できる)ので、その点での ts でのメリットの方が大きいかな、というのが個人意見ではあります。Hono とかはこれをこれを活用しまくっています。

Python の snake_case の文化、API 呼ぶ際にフロントとかと壁があって面倒だろうな、と思っていましたが、案の定面倒なようで、フロントが変換を担当しているそうです。

ts というより js の仕様と Python の比較が多い発表でした。
SaaS が流行って js/ts が流行っていますが、AI が流行った今、Python もまた盛り上がっているように思いますので、ts エンジニアにとってはよい発表になると思いました。

余談ですが、ダックタイピング という言葉を知りました。
そんな名前ついてたんですね🦆🦆🦆🦆🦆
こういうユーモアある命名好きです笑
SQL アンチパターンとか、面白い命名多いですよね

Python では Protocol calss を実装することで実現できるそうです。

AI による解説

ダックタイピングは、オブジェクトの型ではなく、その振る舞い（持っているメソッドや属性）に基づいてオブジェクトを扱うというプログラミングの考え方です。

この名前は、「もしそれがアヒルのように歩き、アヒルのように鳴くなら、それはアヒルである」という、いわゆる「アヒルのテスト」という格言に由来しています。つまり、あるオブジェクトが特定のメソッド（たとえば、walk()やquack()など）を持っているならば、それがどのクラスに属していようと、アヒルとして扱って問題ない、という発想です。

主な特徴と利点

  • 柔軟性と再利用性: 異なるクラスに属するオブジェクトでも、同じメソッドを持っていれば同じように扱うことができます。これにより、コードの柔軟性が高まり、再利用が容易になります。

  • 動的型付け言語との相性が良い: Python、Ruby、JavaScriptなどの動的型付け言語でよく用いられます。これらの言語では、コンパイル時に厳密な型チェックを行わないため、実行時にオブジェクトが特定のメソッドを持っているかどうかを確認すればよいという考え方が自然に適用されます。

留意点
ダックタイピングは便利である一方で、以下のような留意点もあります。

  • 実行時エラーの可能性: 呼び出そうとしたメソッドがオブジェクトに存在しない場合、実行時になって初めてエラーが発生します。静的型付け言語のように、コンパイル時にエラーを検出することはできません。

  • コードの可読性: メソッドがどこで定義されているのか、どのようなオブジェクトが渡されるのかが不明確になり、コードの理解を難しくする場合があります。

Pythonスレッドとは結局何なのか？ ~CPython実装から見るNoGIL時代の変化~

パフォーマンスについては最近の私の関心領域で、ISUCON に出場を予定しているので興味があり拝聴しました。

概要

keywords

  • 🔑 : python-threads, GIL
  • 🔑 : pthreads
  • 🔑 : 参照カウント
  • CPU リソースが限られる場合、並列処理は結局はマルチスレッドになる. CPU 1 つのOSはそれに該当する
  • 「プロセス」と「スレッド」の違いについて説明
  • threads と OS との関係性について説明
  • GIL について説明
  • GIL の背景について説明
    • intel CPU の歴史

感想

Python threads についての話でした
全体通して、Python threads の仕組みの導入から始まる、難易度の高い発表でした

threads の仕組みに関しては理解できずでしたが、キーポイントとして

  • thread の並列化
  • プロセス の並列化
    というのを切り分けて考える必要があるそう。

Python threads は multi threads を実現するための機能ですが、GIL によってそれがブロックされているそう。
その時代的な背景に、Intel Core のマルチコアの実現があったそう(よくわかっていない)
GIL の目的は参照カウントのリソース管理の問題を簡素化するためであったが、Python 3.14 で GIL の無効化, NoGIL が公式にリリースされたらしい。

Ruby も同様の課題を抱えているものの、Ruby は web サーバーとして使われるのがメインであるため、I/O の並列化が大部分であるため真のマルチスレッドへの対応は必要ではない、という姿勢らしい。
Python は機械学習での利用の側面が大きいため、真摯に対応する必要があるそう。

Python のライブラリの筆頭である numpy は CPU ごとのチューニングを行っているのもあり高速。ライブラリの職人には感謝しましょう。

招待講演】医療職が始めるPython：1000人が集うコミュニティの創造

概要

keywords

  • 🔑 DICOM : Digital Imaging and Communications in Medicine
    • 医療画像の国際基準
  • 医学物理士とは何を行う人かについて説明された
  • DICOM について説明された
    • DICOM 医療者には読み取れない. DICOM データ自体は情報が詰まっており、解析などに使いたい
    • しかし、読み解くにはプログラミングスキルが要るし、Matlab はライセンス費用が高く、C lang では大変すぎる
  • スピーカーの pydicom(DICOM を扱うための Python のライブラリ)との出会いについて説明された
  • 医療現場での Python の有効性を確信し、医療界隈の普及を目的にの講習会を開くも、主に受講者の環境構築で多発したトラブルのエピソードについて説明された
  • pycon 2020 でのチュートリアル手法を真似て、Python 講習会の進め方を大改善したエピソードが紹介された

感想

Python の技術的な話ではなく、医療現場での課題を解決するという目的のために Python と出会い、さらに医療界隈に普及に努められたお話です。
技術に振り切った話も面白いですが、課題解決のために採用された背景から普及までの道筋がとても面白かったです。

スピーカーは元々プログラミングの経験はなかったそうですが、医療現場の課題解決のために Python を学ぶところから、1000人に至るコミュニティを作成するまでに至ったエピソードがとても面白かったです。
特に印象的なのが、Python 講習会第一回では大失敗したのを糧に改善を重ね、Python 2020 でのやり方を真似、そのときの講師を講習会にお呼びするなど、スピーカーの熱意がとても感じられました。

この課題をもし知っていれば、Python などで API 作成して医療現場で使いやすく・・・といったことはエンジニアならすぐに思いつきそうで、「もっと早くその課題をしっていれば・・・！」という歯がゆい気持ちも感じ、「課題がある」ことを知ることの重要性を感じさせられました。
ハッカソン・アイデアソンはこういった課題に触れるのに一番身近な機会だと思いました。

Django NinjaによるAPI開発の効率化とリプレースの実践

https://speakerdeck.com/kashewnuts/django-ninja-djangocongress2025

概要

  • Django Ninja の概要について紹介された
    • Fast API に強く影響を受けている
    • django の rest API 作成用フレームワーク
  • Django Ninja の選定理由が説明された
    • 選択肢と学習コスト、開発効率、保守性の観点からの評価
  • Django Ninjaを用いた実践例が紹介された
  • リプレイスの段階戦略について紹介された

感想

FastAPI を使ったことないですが、FastAPI と Django Ninja を比較したら、確かにめちゃ似てます。FastAPI x Django って感じですね
JS では NestJS の書き方や思想にかなり近いなぁと思いました。

Django Ninja はまだ成熟度が若く、若いなりの課題があります。が、Fast API の思想を継承しているため、Fast API のドキュメントを参照してみる、といったアプローチをとっているそうでおもしろいなと思いました。

直接は関係ないですが、swagger の visualize には swagger-UI は知っていましたが、redocてのもメジャーなんですね。初知りです。

基調講演 : Behind the scenes of FastAPI and friends for developers and builders

Fast API の作者からの講演でした

  • PR に対して感謝を一言添えることのモチベーションへの影響
  • 無限の仕事を生まないようにどこかで No という勇気
  • ドキュメント駆動開発ともいえる、ドキュメントを重視した開発

などなど、短期間にここまで広く使われるようになった秘訣が語られました。

作者が 15 歳のときに自宅に web サーバーを立てるも、両親にとっての課題解決にはつながらなかった苦い経験が由来して、本当にいいものを作ろうという精神につながっているのかなと思いました。

ポスターセッション

大学研究室時代に python で研究&ポスター発表したのを思い出してノスタルジックでした笑
ポスター発表って見た目の割に作成にかなり時間かかるんですよね。
印象に残っているものを取り上げて記載します。

そのグラフに「魂」は宿っているか？ ～生成AI全盛期におけるデータ可視化手法とライブラリ比較～

https://speakerdeck.com/negi111111/sonogurahuni-hun-hasu-tuteiruka-sheng-cheng-aiquan-sheng-qi-niokerudetake-shi-hua-shou-fa-toraiburaribi-jiao

概要

  1. LLM で matplotlib を用いてグラフを描かせる
  2. 1度で思い描いていた通りの図が生成されることはなかなかなく、自然言語で FeedBack を与え、 LLM に修正をさせる
  3. LLM によって FB を正確に汲み取り反映できるのかを検証. また、AI model による差分を検証する

感想

自然言語で FB を与える、というのが UX としていいですよね。
「招待講演】医療職が始めるPython：1000人が集うコミュニティの創造」のセクションにもあるように、Python は医療機関や研究機関でよく使われるものの、プログラミング未経験の方からすればハードルはかなり高いです。Python はあくまでツールなので、そこを勉強する時間はなかなか割けないもの。
自然言語によるオペレーションが実現できれば、そのハードルがグッと下がります。

結果としては、まだ課題が残るものの、仕様場所を限定すれば実用性は十分にあるなと思いました。
ぜひ上記の URL からポスターを表示して結果を見てみていただきたいですが、

  • FB を与えることで確かな改善がみられるし、改善後のグラフは視認性高く十分に使えるもの
  • GPT5 モデルであれば再現性が高い
    課題は
  • 複雑なグラフの描写の精度
  • 複雑なグラフの描写の再現性
    • 特に、研究現場では複雑なグラフになりがち
  • コスト

でした。
とはいえ、グラフを 0 からプログラミングするよりは遥かに楽であるし、なにより知識がなくても簡単な図は書ける、というのは嬉しい場面多いと思います。

「まっすぐ行って、右！」って言ってラズパイカーを動かしたい 〜生成AI × Raspberry Pi Pico × Gradioの試作メモ〜

https://speakerdeck.com/komofr/pyconjp2025-poster

概要

  • RasPy を経由して自然言語でロボットを動かしてみる
  • 音声入力 -> G*** で音声ファイル作成 -> *** で文字起こし -> OpenAI API でコマンド生成 -> RasPy でコマンド実行して動かす

感想

Alexa ですね！
音声入力でデバイスが動くんだから Alexa ですね

音声ファイルの作成と API 呼び出しがボトルネックだそうです。
うまいことストリーミング処理ができたら反応速度が上がりそうですね😄

こう組み上げたら実現できるよなぁ、と頭で構想されていたものが実現されていて、コマンド生成の部分を LLM が担うことで個人でも十分実現可能である事実を目の当たりにしました。
家庭用 AI ロボットを自作できる日は近いかも？

その他

  • LT で時間きたらマジでぶっつり切るの初めて見ました笑. でもそれでこそ LT ですよね笑
  • Junie : JetBrains 製の AI アシスタント
  • PyCon Tシャツ配布していました

Discussion

shiracamusshiracamus

js/ts の undefined/null がバグを生み出すのはよくありますが、Python は None でシンプル、ということでした。
Python で API 書いたことないんですが、Python 圏内で null を扱うときは None として扱うんですかね？

Pythonにundefined（オブジェクト内の未定義メンバにアクセスするとundefinedが返るとか）は存在しないです。未定義メンバにアクセスすると例外発生します。
変数やオブジェクト内に値を代入することで変数定義・メンバ定義されます。
変数やメンバを未定義にするにはdel文を使います。
Noneはnullと同じ用途で使いますが、nullはオブジェクトがないのに対してNoneはオブジェクトです。
NoneはNoneType型のシングルトンオブジェクトです。

JavaScript
> x = {}
{}
> x.y = 1
1
> x.y
1
> x.z  // 未定義メンバにアクセス
undefined
Python
>>> class Object:
...     pass
...
>>> x = Object()
>>> x.y = 1
>>> x.y
1
>>> x.z  # 未定義メンバにアクセス
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'Object' object has no attribute 'z'
>>> hasattr(x, 'z')  # メンバが存在するかはhasattr関数で確認
False
>>> None.__class__  # Noneの型（クラス）
<class 'NoneType'>
>>> None.__sizeof__()  # Noneのオブジェクトサイズ（バイト数）
16
2