【個人向け】Google（Gemini）

こんにちは。ファインディの開（ @hiracky16 ）と佐藤（ @heizari ）です。 2026年8月20日から22日にかけて広島国際会議場で開催された PyCon JP 2026 に参加しました。PyCon JPは日本最大級のPythonコミュニティの祭典で、Pythonを使う人、これから学びたい人、コミュニティに関わるすべての人が集まるカンファレンスです。 ファインディは今年もスポンサーとしてブースを出展させてもらいました。エンジニアも2名で参加しており、参加者の皆様と一緒にセッションを聞いたり、ブースでコミュニケーションを取ったりしてきましたので、その様子をレポートします。 PyCon JP 2026とは Findy Drinkup at PyCon JP 2026 印象に残ったセッションの内容 開: Pythonチュートリアル、venvを作ってpip installと2026年も教え続けますか？ 佐藤: Retry Is Not a Strategy: Classifying and Recovering from AI Agent Failures in Python カンファレンスの様子 ファインディブース オフィシャルパーティー Open Spaceでのフリートーク お好みトーク まとめ PyCon JP 2026とは 開催日: 2026年8月21日〜22日（前日の8月20日にDay0イベントあり） 会場: 広島国際会議場 公式サイト: https://2026.pycon.jp/ja 今回は広島での開催ということもあり、地元の学生や企業の方々との交流が多いカンファレンスになりました。 Findy Drinkup at PyCon JP 2026 Findy Drinkup at PyCon JP 2026 を開催し、学生から社会人までさまざまな参加者と交流しました。 意外だったのは、社会人だけでなく学生の参加が多かったことです。プログラミングサークルのメンバーが連れ立って参加しており、研究でPythonを使っているという話や、サークル活動の一環で日頃からコードを書いているという話を聞くことができました。学生と社会人が同じ場でPythonについて語り合える空間になっていたのが印象的でした。 会話の中心になったのは、やはりPyCon JPそのものの話題です。次の日にどのセッションを聴きに行くか、気になっているトークは何かといった話で大いに盛り上がりました。カンファレンス参加をきっかけに初対面同士でも共通の話題ができるのは、Drinkupならではの良さだと感じました。 また、PyCon JP運営の方にも足を運んでいただき、直接お話しする機会もいただきました。 Drinkupにご参加いただきありがとうございました！みなさんとゆっくりお話しできて良かったです☺️🌟🌟 明日からPyCon楽しみましょう〜🐍 #pycon2026_findy pic.twitter.com/yAPIuDzoz1 — いわさき@Findy DevRel (@iwasakitchen) 2026年8月20日 印象に残ったセッションの内容 開: Pythonチュートリアル、venvを作ってpip installと2026年も教え続けますか？ 2026.pycon.jp 以前、登壇者のnikkieさんに「最近、なぜみんなuvを使っているんですか？ Pythonパッケージ管理の変遷と現在地」というFindy Mediaの記事へ寄稿いただいたことがあり、実は今回のセッションの中でもその記事を引用してくださっていました。この場を借りてお礼をお伝えします。 findy-code.io Findy Mediaの記事を通じて、Pythonのパッケージ管理がvenv・pip installから、poetryやrye、そしてuvへと移り変わってきた歴史的な背景を知ることができました。普段Pythonを使って開発していても、その裏にある思想の部分まで意識することはあまりなかったので、見方が変わるきっかけになった記事です。そんな背景もあり、nikkieさんの発表を楽しみにしていました。 セッションでは、venvやpoetry、rye、uvといった各ツールがそれぞれどのような課題を解決するために必要になったのか、その背景を丁寧に説明されていました。ツールが進化するにつれてできることが広がっていく様子が伝わってくる内容でした。そのうえで、タイトルの問いに対する答えは明快でした。チュートリアルでvenvを作ってpip installと教えるのはやめ、uvを勧めるという結論です。 中でも印象に残ったのが、 inline script metadata の話です。スクリプトに前提となるパッケージを直接記述して仮想環境を作れる仕組みで、 uv run script.py 一発で実行できる手軽さは、コーディングエージェントとの相性が良く、ちょっとした実験にはぴったりだと感じました。 uvの良さとして、次のような点も紹介されていました。 簡単で、動作もはやい uvを使っているだけで、できることがどんどん広げられる FastAPIをはじめ、有名なパッケージでもuvの採用が進んでいる コーディングエージェントが普及したことで「コーディングエージェントがはやいだけでなく、コーディングエージェントが使うツール自体もはやい必要がある」という指摘も印象的でした。uvが高速な理由の一つはキャッシュを活用している点で、 uv cache dir コマンドで実際のキャッシュディレクトリを確認できます。コーディングエージェントがこのキャッシュディレクトリにアクセスできる環境であることが、開発体験の速度を保つ上で重要になるという話でした。 また、サプライチェーン攻撃を踏まえると便利だと感じたのが、uvにcooldown（最新版を一定期間経ってから取得する仕組み）を設定できる点です。最近では、Flatt Security社が提供するTakumi Guardでも、設定を一つ加えるだけでプロジェクトが参照するレジストリを切り替えられるようになっており、手軽にサプライチェーン対策を導入できます。Takumi Guardの対応パッケージマネージャーとしてuvがしっかり採用されているあたりにも、uvがエコシステムの中で標準的な位置を占めつつあることが表れていると感じました。 shisho.dev uv自体にも、既知の脆弱性やマルウェアを検出するuv audit機能がプレビューとして追加されており、依存関係のセキュリティチェックをuvのワークフローに統合できる点も便利だと感じました。 astral.sh セッションのスライドと詳しい解説は、nikkieさんご本人の ブログ記事 でも公開されています。 佐藤: Retry Is Not a Strategy: Classifying and Recovering from AI Agent Failures in Python 2026.pycon.jp Cambridge University Press & AssessmentのAI Centre of ExcellenceでAIソフトウェア開発をされているCyrus Manteさんの発表です。クライアント向けにエージェントのパイプラインを構築する中で、理由を説明できない壊れ方に何度も遭遇したものの、試したフレームワークはどれも最初からやり直すか諦めるかしか返してくれませんでした。この課題を解消するために作ったのが、今回紹介されたtriage-agentです。 タイトルのとおり、問題提起は明快でした。普通のPythonの例外処理と違い、エージェントの失敗には名前がありません。例外自体は飛んでくるものの、それはSDKやツールの都合でついた名前で、エージェントが何を間違えたのかまでは読み取れません。 triage-agentは、間違ったツールを呼ぶ、スキーマが合わない、外部サービスが落ちる、黙って同じところを回り続けるといった失敗を9種類の型として定義し、エージェントをポリシーでラップして運用するフレームワーク非依存のPythonライブラリです。記録された軌跡から原因を分類し、そのまま再試行する、プランを立て直す、チェックポイントまで巻き戻す、それでも駄目なら人間にエスカレーションする、といった回復手段へ振り分けます。 導入も、既存のエージェントを包むだけで済みます。実装は公開されていて、 pip install triage-agent で試せます。 github.com 特に参考になったのは、失敗に型を与えることで、次の挙動を細かく選べるようになる、という点でした。ひとくちにリトライと言っても、そのままやり直せばいいのか、ツールの見直しを促すべきなのか、チェックポイントまで巻き戻すべきなのかは、失敗の内容によって変わります。名前がないうちは、それが全部「失敗したのでもう一度」に潰れてしまい、何度やり直しても同じところで落ちる失敗が残ります。 その名前のつけ方が、普段書いている例外処理の考え方をそのままエージェントの一段上へ持ち上げたものになっているのが上手いと感じました。新しい作法を覚え直す必要がありません。 面白いのは、その分類自体をどう解くかにも選択肢が用意されていることです。ルールベースの分類器と、LLMを使う分類器、その組み合わせが用意されていて、発表ではLLMに判断させる話が中心でした。分類は単純なタスクに閉じているぶん失敗しにくく、テストケースも自分で用意できます。Q&Aでも、Cyrusさんはこの程度の分類なら軽量なモデルで対応できるだろうと答えていました。 ユーザーの介入を減らして自律的にタスクを進めるエージェントを作ろうとすると、予期せぬ動作や失敗をどう扱うかは避けて通れません。 triage-agentでは、どの失敗にどの回復手段を当てるか、何回で人間に上げるかをポリシーとしてコード上に宣言できます。失敗ごとの対処をプロンプトに書き込んでLLMの判断に委ねるのではなく、判断はPythonの側に置いて、再試行のときに必要なヒントや状態だけを型のついた形で渡す。ここが今後のエージェント開発に活かせそうだと感じています。 カンファレンスの様子 ファインディブース ファインディブースでは、例年通りPythonクイズを実施しました。Day1・Day2それぞれで別の問題セットを用意し、来場者の方に挑戦していただきました。 Day1始まりましたね！今年もクイズを準備してます。ぜひブースにお立ち寄りください🫶 #PyConJP2026 pic.twitter.com/aHg3oZiJ6J — いわさき@Findy DevRel (@iwasakitchen) 2026年8月21日 例えば、次のような出題文を用意しました。 t = ([ 1 , 2 ], [ 3 ]) t[ 0 ] += [ 99 ] print (t) このコードを実行すると何が起きるでしょうか？ A: TypeError が発生し、 t は ([1, 2], [3]) のまま変化しない B: TypeError が発生するが、 t は ([1, 2, 99], [3]) に変化している C: 例外は発生せず、 ([1, 2, 99], [3]) と出力される D: AttributeError が発生する 正解はBです。タプルの要素であるリストに対して複合代入 += を行うとどうなるかを問う問題で、次の2段階の処理に気づけるかがポイントになっています。 t[0] += [99] はまずリストの __iadd__ を呼び出し、リスト自体がその場で [1, 2, 99] に書き換わる 続けてタプルの要素へ代入し直そうとするが、タプルはイミュータブルなので TypeError が発生する つまり、例外が発生する時点ですでにリストの中身は書き換わっているため、 t は ([1, 2, 99], [3]) のまま残ります。 「難しい」という声を多くいただき、ファインディのDevRelメンバーも実際に挑戦した感想をXに投稿してくれました。 去年に引き続きむずい PyCon JP 2026「Pythonの達人を目指そう！」DAY1で 1/3問正解！ 称号は「Python見習い（Python Apprentice）」でした🐍 #PyConJP2026 #PyConQuiz #pycon_findy https://t.co/41AVR7eIAD — 北川雅士@DevRel (@OnigiriMa_shi) 2026年8月21日 ブースに来ていただいた方々ありがとうございました！ オフィシャルパーティー Day1の夜にはオフィシャルパーティーが開催され、PyCon JP運営からビールをプレゼントいただきました。カンファレンス初日で疲れた体に染み渡る美味しさでした！ オフィシャルパーティーでは、PyCon JP 2026オリジナルビールをご用意しています🍺 ソフトドリンクも取り揃えていますよ🥤 #pyconjp2026 pic.twitter.com/w49Lz4W5WS — PyCon JP (@pyconjapan) 2026年8月21日 立食形式だったこともあり、初日にLTをされた方や他の参加者の方々とたくさんお話しすることができました。中には「ファインディのイベント見ています！」と声をかけてくださる方もいて、とてもありがたく感じました。 Open Spaceでのフリートーク Open Spaceは、参加者が自由にテーマを立てて集まり議論できる時間です。Day1に「Pythonを使ったちょっとした改善のアイデアやネタについて話したい」というテーマを投稿し、話す機会をいただきました。 集まったのは少人数でしたが、その分お互いの前提をすり合わせながら深い議論ができました。話題は昨今のAI活用から、日々の働き方の話まで多岐にわたり、Pythonを使った業務改善というテーマを起点に幅広い視点で意見交換ができたのが印象的でした。 ブースやセッション後などはどうしても関連する話題の会話が中心になりますが、こうしたフリーテーマで参加者同士が交流できる場が設計されているのはとても良いと感じました。 お好みトーク お好みトーク は、広島のお好み焼き文化にちなんで名付けられたライトニングトーク企画です。事前審査はなく、現地参加者であれば誰でも当日に発表を応募でき、実際に登壇するかは現地参加者の投票で決まります。各日3〜5本、1本あたり5分間という枠の中で発表します。 今回、このお好みトークの枠で「500名弱規模の組織のPythonプロジェクト(dbt)をどう管理するか？」というテーマで発表する機会をいただきました。 組織や事業が成長する中、各チームが独立してdbtリポジトリを構築した結果、リポジトリごとにPythonのバージョンやルールがバラバラになり、バージョンアップやセキュリティ対応のコストが線形に増えていくという課題を紹介しました。 その解決策として、共通設定リポジトリを設計するパターンを提案しました。 pyproject.toml や uv.lock をサブモジュール化して集約し、SQLのlintルール（ .sqlfluff ）を一元管理した上で、Taskfileで操作インターフェースを抽象化する構成です。 変わらない要素である環境や規約を部品化することで、各チームが変わる要素であるビジネスロジックに集中できる体制を作ることの重要性を伝えました。 まとめ PyCon JP 2026では、セッションを通じてPythonのエコシステムやAIエージェント開発の最新動向を学べただけでなく、Drinkupやオフィシャルパーティー、Open Space、お好みトークといった交流の場を通じて、学生から社会人まで幅広い参加者の方々と直接お話しする機会にも恵まれました。 ブースでのPythonクイズでは「難しい」という声を多くいただきましたが、その分Pythonの仕様を改めて見つめ直すきっかけになったのではないかと思います。広島での開催ということもあり、ファインディの認知度にはまだ伸びしろがあると感じた一方、「イベントいつも見ています」と声をかけてくださる方もいて、これまでの発信活動が着実に届いていることも実感できました。ファインディ主催のDrinkupやブースへ遊びに来ていただいた方々、本当にありがとうございました。 今回紹介した以外のセッションでも、AIといっしょにどう開発するか、AIを機能にどう組み込むかについて、登壇者それぞれの工夫を知ることができました。自分たちの興味の範囲に合致していた面もありますが、LLMを使って何をしたかよりも、それらをプロダクトや組織としてどう評価し、どう制御するかという話が多く印象に残り、学びの多い2日間になりました。パッケージ管理の移行やAIエージェントの失敗への向き合い方は、ファインディが複数のPythonプロジェクトを運用し、AIエージェントを活用したプロダクト開発を進める中でも、そのまま議論の材料にできる内容だと感じています。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

はじめに こんにちは。普段は@niftyトップページの開発運用をしている宮本です。 最近 git worktree で並行して開発していたところ、 .terraform や node_modules フォルダが大量に作成され、気づいたらPCのストレージが限界に近づいていました。便利で多用していたのですが、掃除をしないと思わぬ落とし穴がありますね。 さて、今回の記事では自分が開発運用担当している一部のサイトで利用しているAmplifyについて、1年以上運用してみた感想について紹介させていただきます。 AWS Amplify AWS Amplify （以下Amplify）はフロントからバックエンドまでを一括で管理できるマネージドサービスです。 サイト運用に必要なAWSリソースを裏側で準備してくれるだけでなく、Gitリポジトリと連携することでブランチごとのサイトの状態を確認できたりすることが大きな特徴です。 前提 この記事ではAmplifyを利用してサイトを1年以上運用してきた経験を元に記述していますが、以下のようなサイトを運用しています。 Astro製SSGのWebサイトの運用がメイン Next.jsを用いたSSRは一部サイトのみ利用 CognitoやDynamoDBなどの各種AWSリソースの利用は無し GitHub連携を利用 AWS Amplify CLIは未利用 特にAmplifyを利用する際に大きな利点となりそうな他のAWSリソースとの組み合わせは試したことがないため、これについては触れません。 便利だった点 手軽にサイトを立てることができる PRごとに自動でサイトを作ることができる ブランチごとに環境変数を設定することができる Basic認証が機能として用意されている 手軽にサイトを立てることができる Amplifyを作成してビルド設定のファイルを用意してリポジトリと接続するだけでサイトを作れるため、特にSSRを用いるサイトだとコンテナ周りの煩雑な準備をせずに済むのが楽でした。 一方で、以下のような条件が重なった場合は必ずしも最も手軽とは言い切れないようにも感じました。 単純なs3+CloudFrontのみで事足りるようなSSGサイト AWS CDKなどのIaCツールを利用して運用することを前提にしている 特に単純な静的サイト用のIaCコードは簡単にAI生成できるため、リソースの準備は比較的容易です。リソースに加えてサイトのビルド+アップロードの構築もありますが、これもGitHub Actionsを用いることで比較的簡単に準備できると感じました。 PRごとに自動でサイトを作ることができる Amplifyを使っていて特に便利だった機能です。 コード変更をしてPRを提出した際、PRごとに専用に新しく割り振られたドメインでサイトの確認が可能になります。 マージ前に変更内容を確認するために、ローカルでブランチを切り替えずとも確認できるサイトが自動でデプロイされるのはとてもありがたかったです。 この辺りを自力で作ろうとするのはかなり大変なので、明確にAmplifyの利点だと感じました。 ブランチごとに環境変数を設定することができる 本番・ステージング・開発環境と複数の環境を常に用意していると、環境によってサイト自体の動作を変更したいケースがあります。 担当しているサイトではCMSを用いて運用していたため、一部の環境では本番公開前のデータを取得し、また開発環境では開発環境のCMSからデータを取得したいということがありました。 このときAmplifyアプリそのものを分けずともブランチごとの設定で分けられるのは便利でした。 Basic認証が機能として用意されている 本番環境以外を一般公開しないようにするため、デフォルトでBasic認証を仕掛けることができるのは便利でした。 デフォルトで組み込まれていない場合はWAFを設定したり、前段にCloudFrontを用意した上でCloudFront Functionsで制御する等々が必要になり、またブランチやPRごとに自動で作成されるサイトには追加することができないため一気に扱い辛くなっていたと思います。 詰まった点・もう少し便利だと嬉しい点 リダイレクトでワイルドカードを利用できる箇所が限られる IaC管理しようとするとやや複雑 ビルド通知を使いやすくしようとするとやや手間がかかる ビルド時のログを出力できない Git上のブランチに必ず依存する IaC管理しようとするとやや複雑 基本的にリソースは全てIaCで管理するようにしているのですが、Amplify自体の管理がやや複雑でした。TerraformとAWS CDKどちらも利用して作成したことがありますが、Amplify管理についてはこの二つの差はあまり感じませんでした。 IaCで管理しようとした場合、Amplify本体のリソースとブランチごとの環境を定義する必要があり少々記述量が多くなります。また、GitHubリポジトリとの接続でリソース作成時はPAT認証が必要になるなど、引っかかる点もありました。 この辺り、簡単にリソースを作成して煩わしさを省くためのAmplifyなので、厳格さを求めるIaCとは若干相性が悪いようにも感じました。 ビルド通知を使いやすくしようとすると手間がかかる Amplifyのビルド通知は、デフォルトではemailのみ対応しています。効率を考えるとslack等に流したいですが、機能としては存在しません。 ビルド自体はEventBridgeをトリガーに検知することができるため、そこからLambdaなどを使うことで通知することはできます。興味がある方は 以前書いた記事 をご参照ください。 ただ、そもそも必要なリソースを設定一つで用意できるのがAmplifyの利点にもかかわらず、別途細かい仕様を把握しリソースを作る必要があるという点が少々煩わしく感じました。 ビルド時のログをCloudWatchに出力できない Amplifyは連携されたコードを元に、Amplify上でコードをビルドしたものをサイトとして公開します。ここで厄介なのが、ビルド時のログそのものはAmplifyのコンソール画面でしか確認できない点です。 SSRでアクセス時に出力されるアプリケーションログはCloudWatch Logsに出力することができますが、ビルド時のログはCloudWatch Logsには出力されません。 よってSSGのサイトなどでビルド時にデータ取得に失敗した場合なども、どこで異常が発生したのかコンソールからたどる必要がある点が運用を考えると少々手間です。 もっとも、これについてはGitHub actionsなどでビルドする場合も同じかもしれません。普段AWSを使っているとCloudWatch Logsからアラートを流しているからこそ、少々物足りなく感じた部分もありました。 Git上のブランチに必ず依存する AmplifyのデプロイはGit上のブランチに紐づいていて便利ですが、このブランチがなくなると環境が消えてしまいます。 本番稼働ブランチなど設定することはできますが、特に保護されているわけでもなく依存しているブランチが消えた場合は該当のブランチの環境は容赦無く削除されます。 よって、本番で動作しているブランチについては確実にGitHubのブランチ保護のルールを仕掛けましょう。初歩的すぎてAmplifyを使わずとも注意すべき当たり前のことではありますが、Amplifyの場合はブランチの誤削除がダイレクトにサイトそのものの存在と直結します。そのためリスクは普段以上に大きく注意が必要です。 特に多くのサイトを管理している場合、うっかり一つでも保護漏れがないか注意しましょう。 まとめ 正直なところAmplifyの機能のさわり程度しかまだ利用していませんが、さわり程度でもPRプレビュー機能などかなり便利に感じる箇所は多いです。ECSで動作させているサイトでPRごとに環境を用意しようとした場合、環境の準備はもちろんデプロイトリガーの用意など考えることは多く、これを設定のチェック一つで実現してしまう点は非常に強力に感じました。 一方で物足りなく感じる点もあり、ビルドログやビルド通知などAmplify内で多くのことを自動的に処理してしまっているからこそ、そこをカスタマイズしようとすると思った以上に手間がかかったり、そもそも対応できないケースなどが出てきます。 この辺りは単にサイトをデプロイするだけでなく運用も踏まえて考えないと後から躓くポイントになりかねないので、少々厄介なポイントだと思います。 とはいえAmplify自体の機能アップデートも続いており、例えば以前はAmplifyにWAFを直接紐づけられなかったのですが、これも2025年にはGAされています。今後も不便に感じていたポイントがアップデートで解消される可能性もあるので、機能アップデートには注視していきたいです。 参考 https://aws.amazon.com/jp/amplify/