Django

計画編で方針を、自動化基盤編でフレームワークを紹介しました。最終回では、実際に 15 Issue を自律実行した結果と、得られた教訓を共有します。 実行結果サマリー タイムライン 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 12:06 ── Phase 0: 初期セットアップ ────── 12分 (リトライ1回) 12:18 ── Phase 1-1: マスタモデル ──────── 14分 (リトライ1回) 12:33 ── Phase 1-2: 契約モデル ──────── 12分 12:45 ── Phase 1-3: 入金・会計モデル ──── 9分 12:57 ── Phase 2: 認証 & API ────────── 12分 (リトライ1回) 13:09 ── Phase 3-1: テンプレート ──────── 16分 (リトライ2回) 13:25 ── Phase 3-2: マスタ CRUD ────── 21分 13:46 ── Phase 4-1: 契約検索 ──────── 12分 13:58 ── Phase 4-2: 契約 CRUD ──────── 16分 14:14 ── Phase 4-3: 支払・入金 ──────── 21分 (リトライ1回) 14:35 ── Phase 5-1: CSV インポート ──── 24分 (リトライ1回) 14:59 ── Phase 5-2: Excel エクスポート ── 24分 (リトライ1回) 15:00 ── Phase 6: 月次締処理 ──────── 10分 15:34 ── Phase 7: テスト ──────────── 20分 (リトライ2回) 15:54 ── Phase 8: デプロイ準備 ──────── 8分 合計: 約 5.5 時間 数値で見る結果 項目 数値 完了 Issue 15 / 15 総コミット 84 うち修正コミット (fix:) 16 (19%) リトライ発生 Issue 8 / 15 (53%) 最大リトライ回数 2 回 Python コード行数 約 15,000 行 テンプレート 50+ ファイル テスト数 199 テスト通過率 100% 1 Issue あたり平均時間 15〜25 分 うまくいったこと 1. inspectdb による正確なモデル定義 既存 DB ダンプから inspectdb でモデル雛形を生成し、それを整理する方式は非常に効果的でした。カラム名・型・制約が実 DB と完全一致するため、「モデル定義を書いたが DB と合わない」問題が発生しませんでした。 ...

redis-py の Lock クラスは UUID ベースのトークンでロックの所有権を管理するが、フェンシングトークン（単調増加する数値）は提供しない。しかし、Lock クラスは do_acquire や Lua スクリプトをオーバーライドできる設計になっており、サブクラス化でフェンシングトークンを追加できる。 本記事では、redis-py の Lock を拡張してフェンシングトークンを発行する FencedLock クラスの実装例を紹介する。 前提知識：Redis の Lua スクリプティング Redis はバージョン 2.6 から Lua スクリプトの実行機能を内蔵している。EVAL コマンドで Lua スクリプトを Redis サーバー上で直接実行でき、複数の Redis コマンドをアトミック（不可分）に実行できる。 なぜ Lua スクリプトが必要か 通常、Redis コマンドは1つずつ実行される。例えば「キーが存在しなければセットし、同時にカウンターをインクリメントする」という処理を2つのコマンドで行うと、その間に他のクライアントが割り込む可能性がある： クライアント A: SET mykey value NX → 成功 ← クライアント B が割り込む余地 クライアント A: INCR counter → インクリメント Lua スクリプトを使えば、この2つの操作を1回のアトミックな呼び出しにまとめられる： 1 2 3 4 5 6 -- Redis サーバー上で実行される（他のコマンドは割り込めない） local ok = redis.call('SET', KEYS[1], ARGV[1], 'NX') if ok then return redis.call('INCR', KEYS[2]) end return nil Redis CLI での実行例 1 2 # EVAL "スクリプト" キーの数 キー1 キー2 ... 引数1 引数2 ... redis-cli EVAL "return redis.call('SET', KEYS[1], ARGV[1])" 1 mykey myvalue redis-py での実行例 1 2 3 4 5 6 7 8 9 10 import redis r = redis.Redis() # 方法1: eval で直接実行 r.eval("return redis.call('SET', KEYS[1], ARGV[1])", 1, "mykey", "myvalue") # 方法2: register_script で事前登録（推奨） # サーバー側に SHA1 でキャッシュされ、2回目以降はスクリプト本文の転送が不要 script = r.register_script("return redis.call('GET', KEYS[1])") result = script(keys=["mykey"]) セキュリティ上の注意 Lua スクリプトのパラメータは KEYS[] と ARGV[] で渡される。SQL のプリペアドステートメントと同様に、パラメータが文字列としてスクリプトに展開されることはないため、パラメータ経由でのインジェクションはできない。ただし、ユーザー入力でスクリプト文字列自体を動的に組み立てると危険なので、スクリプトは固定文字列として定義すること。 ...

Sentry × Claude Code で実現する AI デバッグワークフロー — エラー監視から自動修正まで Sentry × Claude Code で実現する AI デバッグワークフロー — エラー監視から自動修正まで 「バグが起きたら Sentry が検知し、AI が分析して修正案を出す」— そんなワークフローが現実になっています。 @riku720720（Rikuo）さんのポストは、この流れを端的にまとめています。 「アプリ開発する上でsentryは必須。sentry APIをskillsにすればユーザーのバグとか不具合とか全部分析できる。claudecodeの新機能/batchで一気に改善してもらう」 この記事では、Sentry の全体像から Claude Code との連携、そして実践的なワークフローまでを解説します。 Sentry とは Sentry は、開発者ファーストのエラートラッキング＆パフォーマンス監視プラットフォームです。100以上のプラットフォーム・フレームワーク、30以上のプログラミング言語に対応しています。 単なるエラーログではない Sentry が他のログ監視ツールと異なるのは、エラーの文脈（コンテキスト）を自動収集する点です。スタックトレースだけでなく、ユーザーのセッション情報、パフォーマンスデータ、リリースバージョンなど、デバッグに必要な情報を一元化します。 Sentry の主要機能 1. Error Monitoring（エラー監視） Sentry の中核機能です。 リアルタイム検知：エラー発生を即座にキャッチ インテリジェントグルーピング：同じ原因のエラーを自動的に1つの Issue にまとめる アラート通知：Slack、メール、PagerDuty 等と連携 1 2 3 4 5 6 7 8 # Django での導入例 import sentry_sdk sentry_sdk.init( dsn="https://xxx@xxx.ingest.sentry.io/xxx", traces_sample_rate=1.0, profiles_sample_rate=1.0, ) 2. Performance Monitoring（パフォーマンス監視） 分散トレーシング：リクエストの流れをフロントエンドからバックエンドまで追跡 トランザクション分析：遅いエンドポイントやクエリを特定 Web Vitals：LCP、FID、CLS などフロントエンドのパフォーマンス指標 3. Session Replay（セッションリプレイ） ユーザーのセッションをビデオのように再生できる機能です。 ...

CloudFront → ALB → Django 構成で API レスポンスの URL スキームが http:// になる問題と解決策 はじめに AWS の CloudFront + ALB + ECS Fargate で Django REST Framework (DRF) の API サーバーを運用していたところ、API レスポンスに含まれる URL が http:// で返されるという問題に遭遇しました。本記事では原因の調査過程と、最終的な解決策を紹介します。 構成 Client (HTTPS) ↓ CloudFront (SSL終端, us-east-1) ↓ HTTP ALB (HTTP:80のみ受付, ap-northeast-1) ↓ HTTP ECS Fargate (Gunicorn + Uvicorn, port 9000) ↓ Django REST Framework CloudFront がSSLを終端し、ALB へは HTTP で転送する構成です。 問題 DRF の API ルート (/api/rest/) にアクセスすると、レスポンスに含まれる URL がすべて http:// になっていました。 ...

CloudWatch Logs のエラーを自動で GitHub Issues に課題化する ECS で稼働するWebアプリケーションのエラーログを自動的に GitHub Issues に報告する仕組みを構築しました。手動でログを監視する必要がなくなり、エラー発生時に即座にチームが認識・対応できるようになります。 背景 マルチテナントの業務システムを ECS Fargate 上で運用しています。アプリケーションは2つあり、それぞれ異なるフレームワークで構築されています。 アプリ フレームワーク 用途 web Laravel (PHP) 業務管理システム api Django (Python) API サーバー これまで CloudWatch Logs にログは収集していたものの、エラーの検知は手動確認に頼っていました。500エラーや例外発生を見逃すリスクがあり、自動検知の仕組みが必要でした。 アーキテクチャ Subscription Filter + Lambda + GitHub Issues API の構成を採用しました。 CloudWatch Logs (/ecs/{prefix}-ecs-{app}) └── Subscription Filter (エラーパターンマッチ) └── Lambda Function (Docker/arm64, Python 3.12) ├── エラー解析 (HTTP 5xx, 例外, スタックトレース) ├── ±5秒のログコンテキスト取得 ├── 既存 Open Issue 検索 └── 新規 Issue 作成 or 既存 Issue にコメント追加 この構成を選んだ理由 方式 リアルタイム性 柔軟性 コスト Subscription Filter + Lambda (採用) 高 高 中 Metric Filter + Alarm + SNS 中 (1分以上遅延) 低 低 CloudWatch Logs Insights (定期実行) 低 高 低 Subscription Filter はログ出力時にほぼリアルタイムで Lambda を起動するため、エラー発生から数秒で Issue が作成されます。 ...

django-oauth-toolkit 2.0 の client_secret ハッシュ化で外部連携が壊れた話 TL;DR django-oauth-toolkit を 1.x から 2.0 にアップグレードすると、Application.client_secret が 平文からハッシュ値に自動変換 される。この変更に気づかず、DB 上のハッシュ値を「シークレット」として外部サービスにコピーすると、二重ハッシュ で認証が通らなくなる。さらに、Application を動的に生成するコードがある場合、バージョンアップ後に平文を返すべき箇所でハッシュ値を返してしまう問題も起きる。 背景 2つの Django サービス間で OAuth2 Client Credentials Grant による認証を行っていた。 サービス 役割 django-oauth-toolkit Service A (リソースサーバー) ファイル配信 API を提供 2.4.0 Service B (クライアント) API からファイルを取得 1.7.1 Service B は Service A の OAuth2 トークンエンドポイントに HTTP Basic Auth で client_id:client_secret を送信し、アクセストークンを取得してからファイルをダウンロードする。 Service B Service A | | |-- POST /o/token/ --------------->| | Authorization: Basic base64( | | client_id:client_secret) | | |-- client_secret をハッシュ化 | |-- DB のハッシュ値と比較 |<-- access_token -----------------| | | |-- GET /api/files/ -------------->| | Authorization: Bearer token | |<-- file data --------------------| このフローは数年間安定稼働していた。 ...

メール送信 Djangoでメールを送信する際に、都度サーバーを切り替える方法はいくつかあります。以下の手順で実装できます。 メールサーバーの設定を動的に変更する: DjangoのEmailMessageクラスを使用して、メール送信時にサーバー設定を動的に変更できます。例えば、以下のようにconnectionパラメータを使用して異なるサーバーを指定します。 1 2 3 4 5 6 7 8 9 10 11 12 13 from django.core.mail import EmailMessage, get_connection def send_email(subject, message, from_email, recipient_list, server_settings): connection = get_connection( host=server_settings['EMAIL_HOST'], port=server_settings['EMAIL_PORT'], username=server_settings['EMAIL_HOST_USER'], password=server_settings['EMAIL_HOST_PASSWORD'], use_tls=server_settings['EMAIL_USE_TLS'], use_ssl=server_settings['EMAIL_USE_SSL'], ) email = EmailMessage(subject, message, from_email, recipient_list, connection=connection) email.send() サーバー設定のリストを用意する: 複数のサーバー設定をリストで管理し、メール送信時にランダムまたは順番に選択する方法です。 ...

Strawberry https://strawberry.rocks/ Djanog Integration https://strawberry.rocks/docs/integrations/django Getting started with Strawberry 1 2 3 uv add strawberry-graphql[debug-server] uv add strawberry-graphql-django uv add django-choices-field\n strawberry-sqlalchemy https://github.com/strawberry-graphql/strawberry-sqlalchemy 記事 FastAPI と Strawberry(GraphQL) が動作する諸々整ったデモアプリを作ってみた https://github.com/0machi/FastAPI_Strawberry_strawberry-sqlalchemy_DemoApp Graphene vs Strawberry: Which is better for providing a GraphQL API? Django Developing GraphQL APIs in Django with Strawberry

FastAPI FastAPI入門 FastAPI を用いた API 開発テンプレート 【FastAPI】Uvicorn と Gunicorn、WSGI と ASGI、ワーカープロセスについて実施コマンドと共に解説 Hypercorn+FastAPI のコンテナイメージを作成してみる Hypercorn Django を Hypercorn とともに使う How to deploy any Python Web Application? FastAPI を始める時のメモ（ボツ） How to serve HTTP 1, 2, and 3 in Python 1 poetry add fastapi hypercorn quart filters fastapi-filters: https://pypi.org/project/fastapi-filters/ https://fastapi-filter.netlify.app/ https://github.com/arthurio/fastapi-filter/tree/main その他: https://pypi.org/project/fastapi-query-tools/ モデルマッパー SQLModel(https://sqlmodel.tiangolo.com/) Database Migrations with sqlmodel and alembic FastAPI + SQLModel を使った簡単API開発をやってみた Pythonライブラリ(SQL)：SQLModel（応用編-FastAPI) Pythonライブラリ(SQL)：SQLModel Alembicでマイグレーション（FastAPI+SQLModel） FastAPI SQLModel 入門 https://github.com/Joichiro433/Blog-fastapi-todo/tree/main

OAuth PKCE Authorization Code with PKCE on Django using django-oauth-toolkit PKCE_REQUIRED RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients 日本語訳