Pycon mini Shizuoka2026に参加しました
PyCon mini Shizuokaに今年もスタッフとして参加しました。去年は当日スタッフのみでしたが、今年は準備期間から参加しました。
PyCon mini Shizuoka 2026 - connpass
聞いたトーク
生成AI時代に、画像処理やオーディオ処理のノードエディターを作る理由
生成AIで画像処理・オーディオ処理の試行錯誤をできる時代にノードエディターを自作してそれを使って処理をするお話でした。 トークの前はイメージできていなかったのですが、実際に動いているものを見ると、ノードエディターだと処理の結果を目視で比較しやすくて感動しました。
たしかにノードエディターは
— みずき@PjM, PdM学び中 (@mizzsugar0425) 2026年2月21日
目視で比較しやすい！#pyconshizu pic.twitter.com/MOryf4GLGJ
NodeのUIに使っているReact Flowは知らなかったので勉強になりました。
AI主導でFastAPIのWebサービスを作るときに 人間が構造化すべき境界線
ちゃんと設計しないでAIに任せるとちぐはぐな実装をするから大事なところは取り決めておこうという話でした。データの意味・認証認可・画面ごとの整合性は人間が決めて、正しいかどうかを判断しようとのことでした。
Specは仕様書ではなく、AIと人間の間の約束事という考え方はこれからSpec駆動で開発する時に意識しようと思いました。
画面ごとの整合性がズレにきづく力は今の時代にどうつけていくのか考えて行きたいと思いました。*1
Pydanticで複雑なJSONを一発でValidation
複雑で様々なバリエーションのあるJsonデータを安全に保存するためのバリデーションにJsonSchemaからPydanticに変えた話でした。 かなり整理されていたけれどもそれでも複雑でこれはきつい…というデータ構造だったので、機能が豊富で継承関係を整理しやすいPydanticにしたのは英断だと思いました。 JsonSchemaからPydanticのコードを生成するdatamodel-code-generatorは知らなかったので勉強になりました。*2
DSPy入門 Pythonで実現する自動プロンプト最適化 〜人手によるプロンプト調整からの卒業
LLMのモデルの更新頻度高いしその都度プロンプトを書き換えないといけない作業は不毛だな…と思うので、それを自動化する話は興味深かったです。 機械学習よりも集めないといけないデータの件数が少ないとはいえ100件データを集めるのが難しいサービスもありそうと思う反面、データが集まっていて「こういうふうに回答すべき」というノウハウやドキュメントが存在するであろう問い合わせ系のサービスでは導入しやすそうと雑に考えました。
キーノートとLTはスタッフ業しててちゃんと聴けずでした。X実況やスライドで追います。
懇親会
今年の懇親会は静岡市の醸造所 West Coast BrewingのStarwatcherの樽が用意されました。 スポンサーの皆様のお力と、会場から醸造所まで車で30分もかからない立地の良さと、車を運転してくれるスタッフのおかげで実現できたんだなあと感動しました。
今年の🍺すごい！#pyconshizu pic.twitter.com/JKZFGXpicG
— みずき@PjM, PdM学び中 (@mizzsugar0425) 2026年2月21日
スタッフ業
準備期間の大きな仕事としては2つありました。それと、当日スタッフをしました。
グルメマップ
去年と同じくランチは会場を閉めて食べに行ってもらうスタイルなのですが、去年は「どこに行けば良いか分からない」という声がありました。去年の反省から作りたいと思っていたので、グルメマップの企画・制作をしました。 Pythonで地図表示をするアプリを作る選択肢を考えつつも、費用・納期・要件の簡潔さからGoogle Mapで制作しました。
Xでオススメしたお店・メニューをランチで食べた報告を見て嬉しかったです！
ノベルティのステッカー
デザイン・サイズの決定、発注先選定、発注作業をしました。
デザインはロゴがすでにあったのでそちらを使用させていただきました。ノベルティの話がある前からロゴは存在していたのですが、ロゴの利用規約的にこういったグッズ制作に利用できることが分かっていたのはスムーズに進める上でありがたかったです。
ただ、見積もってみると発注してから出荷する期間が思ったより長く、「ノベルティ作ろう！」と決まったのが遅かったのもあり、試作することも考えると期間がギリギリなのは焦りました。バッファ込みでスケジュールを組みましたが、余裕でバッファ使いきりました。配布する分が届いたので安心しました。バッファはとても大切。
当日スタッフ
受付・懇親会の用意をしました。タイムキーパーなどは他の方が担当してくれたので、トークをじっくり聞くことができました。 Connpassのサブイベント機能について、メインイベントを登録するとサブイベントの出席も確認できたのは便利で感動しました。 スタッフ業とは直接関係ないですが、Connpassを改善されたLTもあり、日々の進化・運用に感謝の気持ちが募りました。
まとめ
今回始めてお会いした方、12月のPyladiesから知り合った方、数年ぶりにお会いした方、いろんなご縁がありました。 仕事でPythonを使わなくなりましたが、Pythonコミュニティは良いなと改めて実感しました。
「「分かった！」と思わせる説明の技術」を読んで
わわわIT辞典の方が書いた説明の技術の本だと聞いて読み始めました。わわわIT辞典は大変わかりやすい説明で、プログラミング初学者の頃によくお世話になっていました。数年が経ち今、仕事上説明をする機会が増え、分かりやすい説明ができる「わわわ」の方の考えを学ぼうと思いました。
説明はおもてなし
「分かった！」と思わせるためには、おもてなしとして説明をするとのことです。相手に「分かった」と思ってスッキリしてもらうこと。そのためにはまず相手のレベルを知って、相手のレベルに合わせた説明をします。
相手のレベルを知るために、「何%理解した？」と聞き、本人の自認よりも10-20%下げて理解度を見積もるのは良い考えだなと思いました。ダニングクルーガー効果で高く自認するケースもありますし、「こんなん分かる舐めるな」と言われた方が理解されないよりマシという吹っ切れた考え方も説明する時に活かそうと思いました。
思い切って削る
難しいことは思い切って削るのが「分かった」と思わせるコツだそうです。削ると専門家からみたら「正しくない」状態になるときがありますが、相手のレベルやコミュニーケーションの目的に沿って削るのは悪いことではないというスタンスです。難しいことは100%正確な状態だと難しいままで理解されないので、確かにと思いました。
いわるく「厳密には正しくない」ことを伝えるのは良くないとエンジニアだけの世界にいると思いがちになるので、コミュニーケーションの目的達成のためには悪いことではないというスタンスには救われました。
クライアントだけでなく、初学者に教える時もどこまで端折るかよく迷います。初学者のようにいずれは100%知らないといけない人については、レベルが足りなかろうが伝わらないと話が進まないところは説明を頑張りつつ、それ以外のところについてはその時のレベルに合わせ分解して説明して、そのうち100%を目指すと割り切るのも1つの戦略かもしれないと思いました。
「ITエンジニアの転職学」を読んで
直近で転職する予定はありませんが、現職に残るにしてもキャリア形成に有益だと評判が良いので読んでみました。
データや経験に基づいたアドバイスや理論に納得したのはもちろんのこと、筆者の方の温かい目線と書き味に、自然と前向きな気持ちになれました。
「XXしないとヤバい」「XXするのが一流」みたいな構文がなく、最後まで安心して読めました。キャリアは気になるけど過剰な煽りが苦手な人にもおすすめです。
また、「人生の一部としての仕事」というスタンスを感じました。例えば、「40代は人生の中でこういう時期だと心理学上言われているので、キャリアと向き合うときにこう感じる人もいるでしょう」と言った感じです。より良い人生にするためにこう向き合うと良いという、温かいメッセージを受け取りました。
6つの評価軸×5つのレベル
実装力、組織貢献力、事業貢献力などの6つの軸と
主力メンバーレベル、リーダーレベルなどの5つのレベル
を定義したマトリックス表が大変参考になりました。
いろんな会社の評価指標を参考にされており、具体的な内容に差はあれど方向性は大体他の会社もそんな感じなんだろうな、と私も数社経験したなりに思いました。
各軸での自分のレベルを振り返り、どんな経験を積めば次のレベルに到達できそうか考えるきっかけになりました。
評価制度を考えている人や、マネジメント業務をしている人にも役に立ちそうです。
20,30,40,50代以降の過ごし方
どの年代がどんなことを期待されているのか、どんな風にキャリアを考えるのかが述べられていました。
こちらも、自分の立ち位置の振り返りとマネジメント業務両方に役立ちそうです。
30代の仕事の向き合い方として「組織の目標を達成することにフォーカスしつつ、その過程に自分独自の工夫を加えて、会社と自分のこだわりのバランスを取る」というところが印象的でした。(これはチームリードしているなら、20代でも当てはまること)
自分の工夫を加えて目標達成した結果が、「〇〇さんがいないとできなかったこと」になるのかもしれないと思いました。いきないそこを目指すのは難しいけど、自分の工夫を加えるのはそれよりはハードルが低いので、そのスタンスで頑張ろうと思いました。
django-anymailとResendでメール送信する 〜Railway無料プランSMTP通信できない問題の解決〜
RailwayというPaaSのFreeプランで開発をすすめていたところ、メール送信でつまづいたのでその原因と解決策の共有です。
使用技術
原因
RailwayはProプラン以上でないとSMTP通信できないそうです。 Outbound Networking | Railway Docs
何回メールを送ってもSTG環境では500エラーになり、ローカル環境では正常送れるのはこの仕様のためでした。
HTTP APIを使ってメールを送信しないといけません。
解決策
今回は運良くDjangoを使っていたので助かりました。
結論から書くと、django-anymailというDjangoでメール送信を簡単に実現するパッケージを使い、ResendのHTTP API通信のメール送信機能を使ってメール送信します。
settings.pyにこれを追加するだけ！
EMAIL_BACKEND = "anymail.backends.resend.EmailBackend" # デフォルト値から書き換え
ANYMAIL = {
"RESEND_API_KEY": os.environ.get('RESEND_API_KEY'),
} # 追加
まず、以下の条件でメールサービスを探しました。
3条件すべて揃っているのがResend でした。 なお、SendGridも候補にあがっていましたが、2025年5月にdjango-anymailのサポート切れとなっていました。
SendGridのパッケージを使えばSendGridを使えますが、django-anymailはsettings.pyに設定値をいれるだけでメールサービスと通信する箇所を実装しなくてもメール送信できる手軽さがあります。 手軽さが勝利して、django-anymailを使えるResendを選びました。
まとめ
SupabaseとMetabase のローカル環境セットアップ
DBにSupabase使うアプリのデータ分析をMetabaseでする構成を作るにあたり、ローカル環境の構築に苦戦したでその備忘録です。 ローカル環境なので、Supabase環境はSupabase CLIで、MetabaseはMetabaseのDockerコンテナで作ります。 アプリ部分はNext.jsにしていますが、今回は関係しないので説明は割愛します。ローカルでNext.jsをインストールして立ち上げるよくある方法です。
使用技術
| 種類 | 使用技術名 |
|---|---|
| OS | Ubuntu 24.04 |
| コンテナ管理 | Docker 17 |
| フロントエンド | Next.js |
| バックエンド・DB | Supabase (PostgreSQL, Auth, Storage) |
| データ分析 | Metabase |
| データ可視化 | Metabase UI |
構成図
本番環境
ローカル環境
ローカル環境構築方法
① Supabase CLI のインストール
curl -fsSL https://cli.supabase.com/install.sh | sh
② Supabase プロジェクトを作成
supabase init
ローカル環境起動：
supabase start
完了すると、コンソールに次のような情報が表示されます。
Started supabase/local-dev Database URL: postgresql://postgres:postgres@127.0.0.1:54322/postgres
このDBをMetabaseから参照します。
③ Metabase を Docker Compose で起動
プロジェクトルートに docker-compose.metabase.yml を作成：
version: '3.8' services: metabase: image: metabase/metabase:latest container_name: tea-metabase ports: - "3002:3000" volumes: - metabase_data:/metabase-data networks: - supabase_network_tea-subscription # Supabaseのネットワークに接続 restart: unless-stopped volumes: metabase_data: networks: supabase_network_tea-subscription: external: true
⚠️ supabase_network_tea-subscription は、supabase start 実行時に自動作成されるネットワーク名です。 環境によって異なる場合があるため、次のコマンドで確認してください：
docker network ls
supabase_network_XXのようなネットワーク名を探し、その名前をComposeファイルに記載します。
起動：
docker compose -f docker-compose.metabase.yml up
④ Metabase にアクセス
ブラウザで http://localhost:3002 にアクセスします。
初回セットアップ画面で次のように設定します：
| 項目 | 値 |
|---|---|
| データベースの種類 | PostgreSQL |
| ホスト | SupabaseのDBコンテナ名（例：supabase-db） |
| ポート | 5432 |
| データベース名 | postgres |
| ユーザー名 | postgres |
| パスワード | postgres |
⚠️Supabase CLI はDBを 127.0.0.1:54322 でホストマシンに公開しますが、 MetabaseはDockerコンテナ内で動作しているため、127.0.0.1 では接続できません。 代わりに SupabaseのDBコンテナ名 を指定する必要があります。
Dockerコンテナ一覧で supabase_db_XXX のような名前のものです。
docker ps
下記のNAME列の値です。
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAME 5b7e5eede59f public.ecr.aws/supabase/postgres:17.X.X.XXX "sh -c '\ncat <<'EOF'…" 23 hours ago Up 23 hours (healthy) 0.0.0.0:54322->5432/tcp, [::]:54322->5432/tcp supabase_db_XXXX
⑤ 動作確認
Metabaseの「データベース一覧」に Supabase の postgres が表示されていれば成功です。 これで Supabase → Metabase のローカル開発環境が完成しました。
最終的なディレクトリ構成
├── metabase
├── nextjs-app
├── docker-compose.yaml
├── .env
└── supabase
└── config.toml
まとめ
Supabase CLI は裏側で Docker Compose を使ってローカル開発環境を構築している。
Metabase は Supabase のDBコンテナと同じDockerネットワークに参加させる必要がある。
Metabaseの接続設定では、ホストにコンテナ名を指定するのがポイント。
「#100日チャレンジ」を読んで
ルーズな生活を送る大学生がChatGPTでソフトフェアエンジニアになったシンデレラストーリーという先入観を持っていてごめんなさい。AIという学習アシスタントがいる時代でのプログラミング学習の過程を綴った本でした。 未知の領域にチャレンジしようとしている人にとって。やってみようと思わせる1冊だと思います。軽妙な語り口でさくっと読めます。*1
ChatGPTの使い方の変化
100日間の中で、プログラミングへの理解度が高まるにつれてChatGPTの使い方が変わっていく様子が書かれていたのが興味深かったです。「プログラミング全くわからないけどChatGPT使ってサクッと実績残そう」と1日目に訳もわからずChatGPTがコピペするところから始まります。意図しないコードを出力するChatGPTとの苦戦を通して、プログラムを理解していないと理想のものを作れないと気づき、100日目には内部構造を主体的に設計してChatGPTをあくまでアシスタント的に使うまでになっていました。
楽しい習慣にすることで続けられる、せっかくだから1%だけでも成長しようという気になる
ずっと意味も分からずコピペだけでも100日達成できるのに、成長できたのも素晴らしかったです。
100日続けられてその間成長できたのは、苦行ではなく楽しさを感じることだから、と言った旨が書かれています。著者にとって100日チャレンジは努力や苦行ではなく、習慣として楽しむものだそうです。「せっかく自分で始めたことだから1%でも成長しないともったいないから少し頑張ってみる」と奮い立たせて「今日はChatGPTが言ってたクラスというものを使ってみる」など1日で出来そうな範囲で進めていました。
しかも、ChatGPTに聞けるので未知の領域を少し頑張るハードルが低いのも、続けられる材料になったと思います。
1日ずつなど目標をすぐ見える範囲にするなど達成しやすくすることで挫折せず楽しく習慣にすることができたのかもしれません。
記録することで成長を感じられたのも良かったと思います。
まとめ
- ChatGPTによって未知の領域への挑戦のハードルが下がった
- わからなくても動くものを作れるので確実に最初の成功体験を得られる
- 進むにつれてわからないことができてもすぐ聞ける
- 楽しく習慣化できるように工夫する
- 「今の実力で少し背伸びできる範囲で頑張る」を繰り返すと気づけば大きな成長になっている
*1:PyConJP 2025で著者の基調講演があるそうです。さくっと読めるので気になる方は読んでから参加するのもアリだと思います（今回私はお留守番しますが…🥲）
具体と抽象きっかけで数学学び直し
「具体と抽象 ―世界が変わって見える知性のしくみ」「13歳から鍛える具体と抽象」の2冊に「数は高度に抽象的な概念である」といった旨の内容が書かれていて数への見方が変わりました。数はとても便利な概念であり発明だと気づき、もしかし数学もそうなのではと思いました。
具体と抽象 ―世界が変わって見える知性のしくみ
13歳から鍛える具体と抽象
数学の学び直しに、「ふたたびの高校数学」を読みました。Kindle Unlimitedで無料で読めます。
この本を読むまでは数学の面白さは数字のパズルゲームのようなものだとしか思っていなかったのですが、新しい概念を理解する面白さに気づきました。
この本の面白いポイントを紹介します。
命題と証明から始める
学校の数学は数Ⅰ、Ⅱ、Ⅲと数A、B、Cに分かれていて、各単元も繋がっている印象が薄かったです。公式の暗記という印象が強かったです。
この本は命題と証明から始まっています。まず物事が正しいことをどう論理的に示すのかを学びます。待遇や背理法などの手段や論理の流れです。その後に方程式や関数を学びます。式や関数がなぜそのようになっているのか証明も解説されており、単なる暗記から意味をもった内容に印象が変わりました。
例えば、ゼロで割ってはいけないと決まり事のように学校で学びましたが、証明が掲載されていたのを読んで納得しました。
さまざまな具体を抽象化したのが方程式や関数、方程式や関数を1段階具体化したのがグラフ
方程式は文字を使って抽象度を上げています。
りんごが1個だと100円、2個だと200円、... x個だと100x円
といったように。
関数は関係性を数式という「箱」にして抽象度を上げています。
上記のりんごの例だと、りんごの合計金額をyとすると
y = 100x
といったようにりんごの合計金額を計算する「箱」になります。
ただ、方程式や関数だけでは変数がかわるごとにどのような変化が生まれるのか想像しづらいです。そのためにグラフという視覚情報に落とし込むことでイメージしやすくするんだろうなと気づきました。
公理や定理の美しさにふれる
数式や証明が美しいと聞くことがありますが、その感覚を味わえた気がします。複雑に絡まった糸を引っ張ると絡まらずまっすぐだったような感動がありました。シンプルな美しさですね。
面白かったのが、微分と積分はそれぞれ別の関係ない分野として発展してたのが、相互関係にあると発見されたことです。世の中よくできてるなと思いました。
数学や天文学など昔の科学者は神を信じていた人が多いそうです。こんなに美しい世界なら神がいるに違いない、神の考えを知るために研究するという考え方だったとのこと。
まとめ
- 数学は論理を鍛える学問
- 数学は具体と抽象を鍛える学問
- 数学の美しさはシンプルな美しさ
