🐍
DjangoCongress JP 2025 レポート（Room2編）
公開
2025-03-02
文章量
約9086字
Yard 編集部
Yardの編集部が、テック業界の最新トレンドや知見について発信します。
目次
はじめに
生成AIでDjangoアプリが作れるのかどうか(FastAPIでもやってみよう)
セッションの狙い
生成AIによるコード自動生成の取り組み
成果と課題
DXにおけるDjangoの部分的利用
事例の背景
どこにDjangoを使っているのか
メリット・デメリット
できる！Djangoテスト(2025)
テスト文化の現状
pytestの導入
モジュール構成とフィクスチャ
モックとパラメトリックテスト
コードカバレッジとテスト対象範囲
CI/CDでのテスト実行
全体を踏まえた感想──「テストを書く敷居を下げる」ことの大切さ
Djangoにおける複数ユーザー種別認証の設計アプローチ
複数認証要件が生じる理由
設計手法のバリエーション
コミュニティへの期待
全体を踏まえた感想──複数ユーザー種別は“Webサービス”の本質
Getting Knowledge from Django Hits: Using Grafana and Prometheus
監視・可視化ツールの導入背景
Prometheus & Grafana連携の方法
トラブルシューティング事例
全体を踏まえた感想──観測が生む“次の改善”への一歩
Culture Eats Strategy for Breakfast: Why Psychological Safety Matters in Open Source
オープンソースにおける心理的安全性
Djangoコミュニティ事例
課題と展望
全体を踏まえた感想──「人」が育むDjangoの未来
µDjango. The next step in the evolution of asynchronous microservices technology
µDjangoのコンセプト
非同期マイクロサービスへの進化
将来の可能性
全体を踏まえた感想──小さく軽やかな一歩が未来を拓く
クロージングと今後の展望
イベント終了時のあたたかな空気
さらなる広がりへの期待
総括──Djangoの新たな一面
総括の狙い
Djangoの柔軟性と奥深さ
コミュニティを通じた未来
結びの言葉
はじめに
2025年2月22日、Pythonの代表的なWebフレームワークであるDjangoに特化したカンファレンス「DjangoCongress JP 2025」が開催されました。
公式サイトにはイベント全体の情報やプログラムが掲載されており、今回のオンライン開催に向けた企画背景なども詳しく紹介されています。
本年度はオンライン中心で開催され、アーカイブ映像も公開されています。
アーカイブ視聴はこちらからご覧いただけますので、当日リアルタイムで参加できなかった方でもあとから学ぶことが可能です。
Djangoを活用するエンジニア、学習中の学生、コミュニティのベテランなどが一堂に会し、最新技術や知見、経験談を共有する貴重な機会となりました。
今回は世界各地からの登壇者や視聴者も参加し、まさにグローバル規模でDjangoの魅力を再確認する場になったのが特徴です。
本記事では、Room2の内容を紹介します。
Room1の記事は、こちらをご覧ください。
生成AIでDjangoアプリが作れるのかどうか(FastAPIでもやってみよう)
セッションの狙い
Room2の幕開けを飾ったのは、Ryosuke Ikuru氏とKazuki Matsuno氏による「生成AI」を使ったWebアプリコードの自動生成に関する発表です。
お二人は「生成AI初心者」であることを公言しつつ、DjangoとFastAPIの両方でコードを書かせてみたらどうなるのか、という大胆な実験を試みました。
Djangoをしっかり学んできた人や、最近注目度の高いFastAPIを実験的に触りたい人にとって、朝イチにもかかわらず“ドキドキ”するセッションだったのが印象に残ります。
生成AIによるコード自動生成の取り組み
まずはDjango版のサンプルから着手。教科書的な投票アプリをお題に設定し、モデル、ビュー、テンプレート、さらにはDB初期化コマンドに至るまでAIがどこまで自動生成できるかを試しました。
すると、CRUDのひな型やテストコードはサッと生成されるものの、細かなコンフィグレーションやファイル構成についてはやはり微調整が必要。「AIに全面依存はできないが、スターティングポイントを爆速で用意してくれるのは大きい」というコメントが好評を博します。
次にFastAPI版に挑戦すると、非同期処理やディレクトリ構成でやや混乱が起きがちな様子。
それでもPydanticモデルの生成や基本的なテストコードの記述などは比較的スムーズ。
「ちょっとしたサンプルを作り始めるハードルを思い切り下げられる」点は非常に有用で、学習段階でAIを“メンターがわり”に活用するというアイデアも飛び出しました。
成果と課題
セッションを通じて、「AIが書いたコードを試すという体験自体が学びになる」 という結論が得られたようです。
とはいえ、セキュリティや最適化された構成をAIに期待するのは難しく、最終的には人の目でレビュー・修正が不可欠。
また、Dockerや仮想環境などインフラまわりを自動化させるには、プロンプトを巧みに作る必要があるなど、実務投入にはまだ越えるべきハードルがあります。
それでも、チュートリアルレベルの雛形構築や機械的なテストコードの下書きといった、エンジニアがしばしば億劫に感じる作業をAIが肩代わりしてくれるのは大きな魅力。「これからは生成AIが“相棒”として、Django・FastAPIの入り口を支えてくれるかも」と予感させるセッションでした。
DXにおけるDjangoの部分的利用
事例の背景
続いて登壇したnaohide氏（東京ガス）は、老舗企業のDX推進において「Djangoをどう部分導入するか」をテーマに語りました。
140年以上の歴史ある東京ガスでは、膨大な既存システムの全部取り替えが不可能なため、新技術への移行を段階的に進めるしかありません。そのなかでDjangoに期待するポイントは、強力なORMやアドミン画面など。
フルスタックではなく、あえて“おいしい部分だけ”を取り出すことによって、DXのスピードを落とさずに効果を得られるそうです。
どこにDjangoを使っているのか
ORMによるDB操作をメインに、ミドルウェアを活用した外部サービス連携チェック、さらにアドミン機能による非エンジニア向け管理UIが大きく活躍しているとのこと。
「Djangoの依存を最小限にするため、クリーンアーキテクチャをベースにレイヤー分割を実施している」という点が特筆されました。
たとえば将来、新しいフレームワークが企業要件に合致したら、すぐ切り替えられる余地を残しつつ、現時点ではDjangoの成熟したパッケージ群を活かす――この割り切りこそが、大企業DXの現場で“リアルに使える”設計アプローチだといいます。
メリット・デメリット
レガシーシステムと同居しながらDXを加速するには、Djangoの豊富なライブラリとアドミンが極めて有効。
一方で、Djangoが引きずる“フルスタック感”を抑えるための設計コストはそれなりに高く、小規模チームには負荷が大きい可能性があること、また大量データとの連携では運用計画が要ることがデメリットとして挙げられました。
それでも「Djangoをフルセットで導入しなくても、DXを支える十分な要素がある」という言葉が印象深く、企業の段階的DXにおける“柔軟な救世主”となるシナリオを実感させる事例でした。
できる！Djangoテスト(2025)
テスト文化の現状
ここからはBプラウドのtell-k氏が「Djangoテストの実践」をテーマに登壇。
7年前にも同テーマで話しており、今回は最新のpytestや関連ライブラリを踏まえたアップデート版という位置づけでした。
冒頭では「テストを書きたいが、どこから手を付ければいいか分からない」「既存コードに後付けするのが大変」という初心者ならではの悩みを確認。
Djangoコミュニティでのテスト文化は根付いてきているものの、“最初の一歩”が難しく感じられるケースがいまだ多いそうです。
pytestの導入
tell-k氏がまず推奨したのは、pytestの採用。
公式unittestでももちろんテストは書けるが、pytestはフィクスチャやアサーションの使いやすさが飛び抜けており、初心者にもおすすめ。
Djangoとの相性も良く、pytest-djangoなどを組み合わせることで、マイグレーションを考慮したDBテストも容易に行えるといいます。
モジュール構成とフィクスチャ
テストコードの配置はアプリごとにtests/ディレクトリを切るのが定番スタイル。ファイル名にtest_を付けるだけでpytestが自動収集してくれる利点もあり、初心者がスムーズに参入しやすい。
フィクスチャはdjango_dbやファクトリーボーイを使うとモデルテストが捗り、「DBに書き込みたいがテストが衝突しそう」といった問題も解決できるとのこと。
モックとパラメトリックテスト
外部APIや時刻取得などはpytest-mockで置き換えられ、シンプルなテストを書く鍵になる。さらに、パラメトリックテスト（pytest.mark.parametrize）を使えば、複数の入力パターンを1つのテスト関数に集約可能。
似通ったアサートを大量に書く手間を省き、可読性も高められるのが魅力です。
コードカバレッジとテスト対象範囲
カバレッジを100%にすれば品質が上がるわけではないが、未テストコードを見つけ出すうえで重要な指標となるため、有効に活用すべきだと話されました。
pytest-covなどで手軽に数値化し、リファクタリングの検討材料にする流れが主流ということです。
CI/CDでのテスト実行
近年はCI/CD環境でpytestを自動実行し、テスト結果が緑にならないとマージできない仕組みを整えるのが当たり前になっているそうです。
大量のDBアクセスや外部サービス連携テストなど、負荷の大きいケースにどう対処するかが大規模プロジェクトの悩みで、pytestのマーク機能で柔軟に制御するノウハウが紹介されました。
全体を踏まえた感想──「テストを書く敷居を下げる」ことの大切さ
単に「テストを書こう」ではなく、「書きやすい仕組みを整える」ことがいかに大事かを再認識できるセッションでした。
pytestやフィクスチャ、モック、カバレッジなどの技術スタックを整えることで、初心者でも“ちょっとやってみよう”と感じられるのが大切ということです。
また、Djangoには巨大なテストコミュニティがあり、様々なプラグインが充実しているのも心強いポイント。
テストこそがリファクタリングや品質向上の鍵になる今、こうした知見を積極的に取り入れて“書き始めのハードル”をとことん下げることが、プロジェクト全体にとって良い影響をもたらすでしょう。
Djangoにおける複数ユーザー種別認証の設計アプローチ
複数認証要件が生じる理由
Room2のさらなる深掘りとして、Bプラウドの奥寺さんが「ユーザー種別が2つ以上あるWebサービスの認証設計」を披露。
ECサイトでの出品者と購入者、あるいは管理者と一般ユーザーなど、実際のサービスではユーザーの役割が大きく分かれ、同じUserモデルだけではカバーしづらいケースが多々あります。
Djangoの組み込みUserをどう拡張・切り分けるかが、焦点となるわけです。
設計手法のバリエーション
まずはタイプフィールドパターン。1つのテーブルに種別フィールドを持ち、出品者か購入者かを判別する手法ですが、固有フィールドまで1カ所に混在するのが難点。次に認証モデル共有パターン。
Djangoが想定するUserモデルを「認証情報」と割り切り、ビジネスロジックや固有フィールドはCustomerやMerchantモデルに任せるやり方。フレームワークの恩恵を得やすく、大多数のケースで問題なく回るようです。
さらに認証モデル切り替えパターンでは、環境単位でAUTH_USER_MODELを変えるという試みもあり得るが、テストやマイグレーションが複雑になりやすいとの警告が。
最後の自前実装はセキュリティリスクや保守コストが高く、よほど尖った要件がない限りはオススメできないという結論でした。
コミュニティへの期待
複数ユーザー種別をDjangoで扱うベストプラクティスはまだ発展途上。
複数の手法に挑戦した知見を持ち寄ることで、さらに洗練された設計論が生まれることを期待し、奥寺さんは「ぜひブログや実装例を共有してほしい」と呼びかけました。
複数ユーザーの認証設計は多くのWebサービスの要点でもあり、今後のコミュニティ議論が益々活発化しそうな予感です。
全体を踏まえた感想──複数ユーザー種別は“Webサービス”の本質
出品者と購入者のように異なるロールをどう扱うかは、ビジネス要件やデータ構造、フレームワーク活用度合いを一気に浮き彫りにするテーマです。
Djangoの認証機能をフレームワークのレールに沿ったまま使うか、少し外れてリスクをとってでも独立性を高めるか――このバランスをどう取るかは、運用者の好みや組織文化にも左右されるでしょう。
それでも事例が少しずつ蓄積され、コミュニティで議論が進んでいるのは心強い限り。複数種別認証は多くのサービスが直面する現実問題だけに、Djangoコミュニティ全体で更なるノウハウを醸成していく意義は大きいと感じました。
Getting Knowledge from Django Hits: Using Grafana and Prometheus
監視・可視化ツールの導入背景
Apoorv Garg氏の発表は、Djangoが動く現場でよく起きがちな「障害発生時や性能劣化をどう検知するか」問題にフォーカスしていました。
従来のログ解析だけでは抽象度が高く、リアルタイムに把握しづらい。そこで近年注目されるのが、PrometheusとGrafanaの組み合わせによる監視と可視化です。
サーバーの稼働状況やリクエスト数、レスポンスタイム、DBクエリ数といったメトリクスを取得・蓄積し、“いつどのような負荷がかかっているか”をグラフィカルに見られるメリットを強調していました。
Prometheus & Grafana連携の方法
Prometheusはプル型のアーキテクチャを採用しているため、Djangoアプリ（またはPush Gateway）から一定間隔でメトリクスをスクレイプします。
Docker ComposeでPrometheusとGrafanaを気軽に立ち上げ、YAMLで設定するだけでデータを収集可能とのこと。
あとはGrafanaをデータソースとして登録すれば、時系列チャートやヒストグラムをリアルタイム表示できるそうです。
エラースパイクやゼロリクエストの瞬間を可視化し、原因究明を素早く行える――これが監視・可視化ツール導入の真髄だとApoorv氏は熱弁しました。
トラブルシューティング事例
氏はトラブル事例として「ある日突然リクエストが倍増したり、DB負荷が激増したり」というシナリオを紹介。
昔は原因不明のまま時間を浪費していたが、Prometheus/Grafanaを導入した後はリクエストカウントやCPU使用率が“一瞬で”数値化され、外部からの大量アクセスがすぐに判明し、障害対応を最小限で済ませられたそうです。
一方、メトリクスを増やしすぎると運用自体が複雑化するリスクもあるため、まずは主要指標から始め、必要に応じて拡張していくのが良いとのアドバイスで締めくくられました。
全体を踏まえた感想──観測が生む“次の改善”への一歩
「見える化はゴールではなく、改善のスタートライン」。Djangoと相性の良いPrometheus＆Grafanaを活用することで、開発チームはシステムの現状をリアルタイムに把握し、問題点を明確に洗い出せる。
マイクロサービスや大規模展開を視野に入れる前に、まずは監視基盤をシンプルに導入するだけでも得られる価値は大きい――そんな力強いメッセージを実証的に示してくれたセッションでした。
Culture Eats Strategy for Breakfast: Why Psychological Safety Matters in Open Source
オープンソースにおける心理的安全性
Priya Pahwa氏が取り上げたのは、技術的優位性だけではなく「心理的安全性」こそがオープンソースを成功に導く最重要ファクターだという視点です。
エンジニアリングの現場でいくら頭脳集団が集まっても、お互いに意見を遠慮し合い、質問しづらい空気が漂っていたら、抜本的なイノベーションは難しい。
逆に「失敗しても怒られない」「初歩的な質問でも歓迎される」環境があれば、初心者から熟練者まで、多様なアイデアが次々と出やすくなります。
Djangoコミュニティ事例
Djangoコミュニティは、Code of Conductの策定をはじめ「誰でも気軽にコントリビュートできる」文化づくりを早期から進めてきました。
新規コントリビューターにはメンターが付き、疑問や提案をフォーラムやIssueで受けとめる仕組みが整備されているそうです。
こうした心理的安全性が、Djangoエコシステムの拡張と品質向上を支える大きな柱となっている、とPahwa氏は力説します。
課題と展望
とはいえ、ボランティアベースで動くコミュニティゆえに、メンタリングやモデレーションには相応のリソースが必要。
メンターが疲弊しない体制づくりや、新規参加者と古参コントリビューターとの“温度差”をどう埋めるかは、今後も課題として残るとの指摘です。
それでも心理的安全性を土台に多彩な人材を巻き込み続けることが、Djangoの繁栄を維持するための要だといえます。
全体を踏まえた感想──「人」が育むDjangoの未来
Priya Pahwa氏の講演は、「コミュニティ文化がテクノロジーを凌駕する」というオープンソースの本質を改めて感じさせました。
Djangoに限らず、OSSが進化するスピードを決めるのは結局「人と人のやりとり」です。
心理的安全性が担保されたコミュニティは、遠慮なく質問でき、初心者が入りやすく、結果として先端技術へのアップデートも速まる――まさにDjangoが“古くならない”理由を文化面で示したセッションでした。
µDjango. The next step in the evolution of asynchronous microservices technology
µDjangoのコンセプト
Room2のラストを飾ったMaxim Danilov氏の「µDjango」は、一言で言えば「単一ファイルで運用可能な軽量Django」という大胆なアイデアです。
通常、Djangoは複数ファイル・複数アプリに分割して管理するのが定番。
しかし、あえて1ファイルに集約すればマイクロサービスを単独運用する際に効率的で、PoCやプロトタイプを素早く作りたい状況に活用できると氏は語ります。
非同期マイクロサービスへの進化
Django 3.x以降、ASGIを通じて部分的に非同期化が可能となったとはいえ、まだフルに非同期を扱うのは実装面で課題が多い。
µDjangoのように単一ファイル構成だと「必要なエンドポイントだけ非同期化する」「モノリシックなプロジェクトの一部を切り出す」といった柔軟なマイクロサービス化がやりやすい、というメリットが紹介されました。
将来の可能性
小規模サービスやPoCでの採用が特に有望で、モノリスから段階的にマイクロサービスへ移行する際にもヒントがありそう。
ただしあくまでDjango本体の非同期対応が道半ばであることもあり、大規模運用で全面的にµDjangoへ切り替えるには慎重な検討が必要とのこと。
とはいえ、「Djangoを単一ファイルでサクッと動かす」という発想自体がエンジニアに新鮮なインスピレーションを与えるのは確かで、今後のコミュニティ発展を暗示する新潮流だと感じさせる内容でした。
全体を踏まえた感想──小さく軽やかな一歩が未来を拓く
シンプルゆえのインパクト――µDjangoは、「モノリス＝大規模構成が当たり前」とされがちなDjangoの常識を覆す、新たな発想を投じました。
単一ファイルでも動作し、非同期にも対応できるという柔軟性は、PoCや部分的マイクロサービス化など、多様なニーズに応えそうです。
Djangoが進化していく過程で、こうした小さくて革新的な試みが次々と生まれるのは、コミュニティの活力を象徴するようにも思えます。
クロージングと今後の展望
イベント終了時のあたたかな空気
DjangoCongress JP 2025のRoom2セッションがすべて終わると、パブリックビューイング会場やオンラインチャットには「お疲れさま！」の声が相次ぎ、スタッフへの労いの言葉も絶えませんでした。
オンラインながら同時翻訳やDiscord連携が充実しており、国内外の参加者が“ワイワイ”と盛り上がるさまは、あたかもリアル会場のよう。
新しいスタイルのカンファレンスに手応えを感じる瞬間でした。
運営チームもカメラの向こうで「無事走りきった」という安堵感をにじませつつ、画面越しに笑顔と感謝を伝えていたのが印象的です。
さらなる広がりへの期待
今回のRoom2では、生成AIやDX事例、監視ツールにおけるDjangoの部分活用、心理的安全性の重要性など、本当に多岐にわたるテーマが共有されました。
Djangoの底力を再認識しつつ、「こんな応用方法もあるのか」「これなら自分たちの現場でも試せそう」といった声が続出。
カンファレンス終了後には、主催者からのアンケート依頼もあり、次回に向けた改良と企画案が早くも動き始めているようです。
公式アーカイブの公開も予定されているので、聞き逃したトークや見返したい部分はぜひチェックしてみましょう。
総括──Djangoの新たな一面
総括の狙い
これまで見てきたように、Room2のセッションはDjangoの“新しい扉”を開くテーマが多く取り上げられました。生成AIや部分的導入、認証の多様化、監視・可視化の実践、そしてコミュニティ文化の深まりなど――どれもDjangoというフレームワークの奥深さと拡張性を、あらためて実感させる内容でした。
Djangoの柔軟性と奥深さ
バッテリー同梱型のDjangoが、ここまで多様な応用に対応できるのは、長年培われてきたコアの堅牢性と、コミュニティの力が大きいと言えます。
単純に「Djangoをそのまま使う」だけでなく、必要なところだけ取り入れたり、生成AIや監視ツールと組み合わせたり、さらにはマイクロサービス化の足がかりにもなる。
Room2のセッションは、Djangoが“古いフレームワーク”ではなく、“攻めのフレームワーク”として活き続ける姿を描き出してくれました。
コミュニティを通じた未来
心理的安全性やオープンな質問文化を重視するコミュニティがあるからこそ、Djangoは最新の課題に遅れずアップデートされ、実務上の知見も共有され続けるのだと感じます。
開発者が新しいアイデアを提案しやすい風土こそが、Djangoの“止まらない成長”を支えている。
Room2の登壇者たちが共有してくれたノウハウやエピソードは、そのことを強く裏付けていました。
結びの言葉
Room2のセッションは、Djangoを一歩進んだ形で使いこなすための示唆に富んだ内容ばかりでした。
単にコードを書く技術だけではなく、組織や文化、そしてコミュニティとの関わり方まで含めて、Djangoの活用範囲は広がり続けています。
もうすでにRoom1の記事も公開されており、そちらとあわせて読むことでカンファレンス全体像がよりクリアになるはずです。
Djangoが示す未来への可能性は、こうしたコミュニティの結束と技術の融合から生まれる――今回のRoom2は、まさにそのエネルギーを如実に体感できる場だったのではないでしょうか。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
