Python Backend Architecture Review について
Python バックエンドの設計を、システム設計、セキュリティ、データベース、API、性能、デプロイなどの観点から評価するスキルです。設計文書やシステムの説明を確認し、重要度別の指摘と具体的な提案をまとめます。
主な機能
- 01システム設計とコード構成の評価
- 02データベースと API 設計の確認
- 03セキュリティ、性能、可観測性の点検
- 04デプロイ、耐障害性、データフローの検討
- 05重要度別の指摘整理
活用シーン
- 01Python バックエンド設計文書のレビュー
- 02マイクロサービスやデータベース設計の評価
- 03セキュリティと拡張性の確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ rknall/ claude-skills --skill python-backend-architecture-reviewインストール後、Claude Code で/python-backend-architecture-reviewを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
technology-recommendations.mdarchitecture-checklist.mdREADME.mdcommon-patterns.md詳細
Python バックエンドアーキテクチャのレビュー
このスキルでは、インフラストラクチャからコードの構成まで、システム設計のあらゆる側面を網羅した、Python バックエンドアプリケーションの包括的なアーキテクチャレビュー機能を提供します。
このスキルを使用するタイミング
ユーザーが次の内容を依頼した場合に、このスキルを有効にします。
- バックエンドアーキテクチャ設計ドキュメントのレビュー
- Python アプリケーションのシステム設計に関するフィードバック
- スケーラビリティのパターンとアプローチの分析
- バックエンドアーキテクチャのセキュリティレビュー
- データベース設計の評価
- API 設計の評価
- マイクロサービスアーキテクチャのレビュー
- パフォーマンス最適化の提案
- クラウドインフラストラクチャアーキテクチャのレビュー
- コード構成とプロジェクト構造の分析
レビューフレームワーク
1. 初期分析
ユーザーからアーキテクチャドキュメントが提供された場合、またはシステムの説明を受けた場合は、次の手順で開始します。
-
コンテキストの把握
- 次の点について、明確にするための質問をします。
- 想定される規模(ユーザー数、毎秒のリクエスト数、データ量)
- パフォーマンス要件(レイテンシ、スループット)
- セキュリティおよびコンプライアンス要件
- チームの規模と専門知識
- 予算の制約
- 想定されるスケジュール
- 次の点について、明確にするための質問をします。
-
ドキュメントの分析
- アーキテクチャ図やドキュメントが提供された場合は、次の点を分析します。
- コンポーネント間の関係と境界
- データフローのパターン
- 外部依存関係
- 技術スタックの選択
- デプロイメントトポロジー
- アーキテクチャ図やドキュメントが提供された場合は、次の点を分析します。
2. 包括的なレビュー領域
次の側面からアーキテクチャを評価します。
A. システムアーキテクチャと設計パターン
評価項目:
- 全体的なアーキテクチャスタイル(モノリス、マイクロサービス、サーバーレス、ハイブリッド)
- サービスの境界と責務
- 通信パターン(同期/非同期、REST/GraphQL/gRPC)
- イベント駆動型アーキテクチャのコンポーネント
- 該当する場合は、CQRS とイベントソーシングのパターン
- ドメイン駆動設計の原則
- 関心の分離
- 依存関係の管理
フィードバックする項目:
- 選択したアーキテクチャが規模と複雑さに合っているか
- 過剰設計または設計不足の懸念
- 不足しているコンポーネントやサービス
- 密結合の問題
- 単一障害点
- スケーラビリティのボトルネック
Python 固有の考慮事項:
- フレームワークの選択(FastAPI、Django、Flask など)
- ASGI と WSGI の考慮事項
- Async/await パターンとその使用方法
- アーキテクチャ上の判断に対する Python の GIL の影響
- マルチプロセスとマルチスレッドの戦略
B. データベースアーキテクチャ
評価項目:
- データベースの種類の選択(PostgreSQL、MySQL、MongoDB、Redis など)
- データモデリングのアプローチ
- 正規化と非正規化の戦略
- シャーディングとパーティショニングの計画
- リードレプリカとレプリケーションの戦略
- キャッシュ層(Redis、Memcached)
- データベース接続プーリング
- トランザクション管理
- データ整合性モデル(強整合性、結果整合性)
フィードバックする項目:
- スキーマ設計の品質
- インデックス戦略
- クエリ最適化のパターン
- N+1 クエリの防止
- データベースのマイグレーション戦略
- バックアップと災害復旧
- 該当する場合は、マルチテナントのアプローチ
- データの保持およびアーカイブ戦略
Python 固有の考慮事項:
- ORM の選択(SQLAlchemy、Django ORM、Tortoise ORM など)
- 生の SQL と ORM のトレードオフ
- 非同期データベースドライバー(asyncpg、motor など)
- マイグレーションツール(Alembic、Django migrations)
C. API 設計と通信
評価項目:
- API 設計パターン(RESTful、GraphQL、gRPC)
- エンドポイントの構成と命名
- リクエスト/レスポンス形式
- バージョン管理戦略
- 認証と認可
- レート制限とスロットリング
- API ドキュメントの方針
- コントラクトファーストとコードファーストの設計
- リアルタイム機能での WebSocket の使用
- メッセージキューとの統合(RabbitMQ、Kafka、SQS)
フィードバック項目:
- API の一貫性と規約
- エラー処理とステータスコード
- ページネーション戦略
- フィルタリングと検索機能
- 冪等性の保証
- 後方互換性への対応
- 該当する場合は GraphQL スキーマの設計
- 該当する場合は gRPC サービス定義
Python 固有の考慮事項:
- FastAPI による OpenAPI の自動生成
- Pydantic のバリデーションモデル
- Django REST Framework のシリアライザー
- GraphQL ライブラリ(Strawberry、Graphene、Ariadne)
- gRPC-python のコード生成
D. セキュリティアーキテクチャ
評価項目:
- 認証メカニズム(JWT、OAuth2、セッションベース)
- 認可モデル(RBAC、ABAC、ポリシーベース)
- API セキュリティ(レート制限、CORS、CSRF 対策)
- データ暗号化(保存時および転送時)
- シークレット管理の方針
- ネットワークセキュリティ(VPC、セキュリティグループ、ファイアウォールルール)
- 入力のバリデーションとサニタイズ
- SQL インジェクションの防止
- XSS および CSRF の保護
- 依存関係の脆弱性スキャン
- セキュリティヘッダーの実装
フィードバック項目:
- 認証/認可の不備
- 機密データが漏えいするリスク
- 不足しているセキュリティ制御
- 過度に許可されたアクセス
- 安全でないデフォルト設定
- 監査ログの不足
- セキュリティ監視の不足
Python 固有の考慮事項:
- トークン処理における python-jose、PyJWT の使用
- bcrypt、argon2 によるパスワードハッシュ化
- 環境変数の管理(python-dotenv)
- フレームワークのセキュリティミドルウェア
- SQLAlchemy のパラメーター化クエリ
E. スケーラビリティとパフォーマンス
評価項目:
- 水平スケーリングと垂直スケーリングの戦略
- 負荷分散の方針
- オートスケーリングの設定
- キャッシュ戦略(アプリケーション、データベース、CDN)
- 長時間実行タスクの非同期処理
- バックグラウンドジョブ処理(Celery、RQ、Dramatiq)
- キューベースのアーキテクチャ
- データベースの読み取りレプリカ
- コネクションプーリング
- リソースの最適化
フィードバック項目:
- スケーラビリティのボトルネック
- 不足しているキャッシュ層
- 非効率なデータアクセスパターン
- 非同期化すべき同期処理
- キューインフラストラクチャの不足
- リソース利用率の低さ
- パフォーマンス監視の不足
Python 固有の考慮事項:
- ASGI サーバーの選定(Uvicorn、Hypercorn)
- Gunicorn ワーカーの設定
- Celery ワーカーの設定
- 非同期フレームワークの使用(asyncio のベストプラクティス)
- パフォーマンスプロファイリングツール(cProfile、py-spy)
- CPU バウンドなタスクにおける GIL の回避策
F. 可観測性とモニタリング
評価項目:
- ロギング戦略と一元管理
- メトリクスの収集と集約
- 分散トレーシングの実装
- エラー追跡とアラート
- ヘルスチェックエンドポイント
- パフォーマンス監視
- ビジネスメトリクスの追跡
- ログ集約ツール(ELK、Loki、CloudWatch)
- APM ツール(DataDog、New Relic、Prometheus)
フィードバック項目:
- 不足している可観測性コンポーネント
- ログの詳細さが不十分
- 構造化ロギングの不足
- 分散トレーシングの未導入
- 重要なアラートの不足
- パフォーマンスのベースラインがない
- エラー追跡が不十分
Python 固有の考慮事項:
- 構造化ロギングライブラリ(structlog、python-json-logger)
- OpenTelemetry Python SDK
- Sentry との統合
- StatsD/Prometheus クライアントライブラリ
- 非同期コードにおけるコンテキストの伝播
G. デプロイとインフラストラクチャ
評価項目:
- コンテナ化戦略(Docker)
- オーケストレーションのアプローチ(Kubernetes、ECS など)
- CI/CD パイプラインの設計
- 環境管理(開発、ステージング、本番)
- Infrastructure as Code(Terraform、CloudFormation)
- ブルーグリーンデプロイまたはカナリアデプロイ戦略
- ロールバック手順
- 構成管理
- デプロイ時のシークレット管理
フィードバックする項目:
- デプロイの複雑さ
- 自動化の不足
- 環境間の同等性の欠如
- ロールバック戦略がない
- パイプラインでのテスト不足
- 手動のデプロイ手順
- インフラストラクチャのバージョン管理がない
Python 固有の考慮事項:
- Docker イメージの最適化(マルチステージビルド)
- 依存関係の管理(pip、Poetry、PDM)
- コンテナ内での仮想環境の扱い
- Python バージョンの管理
- コンパイル済みの依存関係(wheel ファイル)
H. コード編成とプロジェクト構造
評価項目:
- プロジェクトのディレクトリ構造
- モジュールとパッケージの編成
- 依存性注入のパターン
- 構成管理
- 環境変数の使用
- テスト戦略と編成
- コード再利用のパターン
- パッケージ/モジュールの境界
フィードバックする項目:
- モジュールの責務が不明確
- 循環依存
- コード構造の編成が不適切
- レイヤー間の分離が不十分
- 構成の抽象化がない
- ハードコードされた値
- テストカバレッジの不足
Python 固有の考慮事項:
- パッケージ構造(src レイアウトとフラットレイアウト)
- init.py の編成
- インポートパターンと循環インポートの防止
- 型ヒントと mypy の構成
- Pydantic による設定管理
- pytest の編成とフィクスチャ
I. データフローと状態管理
評価項目:
- リクエストのライフサイクルとデータフロー
- 状態管理のアプローチ
- セッション管理
- キャッシュの無効化戦略
- イベント駆動システムにおけるイベントフロー
- データ変換レイヤー
- データ検証ポイント
フィードバックする項目:
- データフローが不明確
- 状態の同期に関する問題
- 検証レイヤーがない
- データ変換に一貫性がない
- キャッシュの整合性に関する問題
- セッション管理に関する問題
J. レジリエンスとエラー処理
評価項目:
- 再試行メカニズムとバックオフ戦略
- サーキットブレーカーパターン
- タイムアウトの構成
- グレースフルデグラデーションのアプローチ
- エラー処理の一貫性
- デッドレターキューの処理
- バルクヘッドパターン
- レート制限とスロットリング
フィードバックする項目:
- フォールトトレランスパターンがない
- 障害が連鎖するリスク
- タイムアウトがない
- 外部サービス向けのサーキットブレーカーがない
- エラー処理に一貫性がない
- 再試行ロジックがない
- グレースフルデグラデーションがない
Python 固有の考慮事項:
- 再試行に使用する tenacity ライブラリ
- asyncio のタイムアウト処理
- 例外階層の設計
- リソースのクリーンアップに使用するコンテキストマネージャー
3. レビュー出力形式
レビューは次のように構成してください。
エグゼクティブサマリー
- アーキテクチャの総合評価(1〜3 段落)
- 特定された主な強み
- 早急な対応が必要な重大な懸念事項
- 全体的な成熟度と準備状況の評価
詳細な所見
レビュー項目ごとに、次の内容を記載してください。
[項目名]
強み:
- 適切に実施されている点を箇条書きで記載
懸念事項:
- HIGH:対応必須の重大な問題
- MEDIUM:対応すべき重要な問題
- LOW:あると望ましい改善点
推奨事項:
- 具体的で実行可能な推奨事項
- 検討すべき代替アプローチ
- 従うべきベストプラクティス
- Python 固有のライブラリまたはツールの提案
アーキテクチャパターンとベストプラクティス
ユースケースに関連する、実績のあるパターンを提案してください。
- 具体的な設計パターン(Repository、Factory、Strategy など)
- 統合パターン
- Python 固有のイディオム
- フレームワーク固有のベストプラクティス
技術スタックの評価
選択したテクノロジーをレビューしてください。
- ユースケースへの適合性
- チームの専門知識に関する考慮事項
- コミュニティのサポートと成熟度
- 検討すべき代替オプション
- Python パッケージエコシステムに関する推奨事項
スケーラビリティのロードマップ
アーキテクチャの拡張が必要な場合は、以下を示してください。
- 現在の制限事項
- 拡張の段階とトリガー
- 移行戦略
- 規模ごとのコスト予測
セキュリティチェックリスト
具体的なセキュリティチェックリストを提示してください。
- 認証/認可に関する項目
- データ保護に関する項目
- ネットワークセキュリティに関する項目
- コンプライアンスに関する考慮事項(GDPR、HIPAA など)
- Python のセキュリティに関するベストプラクティス
次のステップと優先順位
推奨事項を次のように優先順位付けしてください。
- 必ず修正すべき項目(ブロッキングとなる問題)
- 修正すべき項目(本番環境に重要なもの)
- あると望ましい項目(改善点)
推定工数と依存関係も含めてください。
4. 対話形式のレビュー手順
レビューを実施する際は、次の手順に従ってください。
- アーキテクチャの説明が不完全な場合は、まず確認の質問をします
- 制約について確認します(予算、スケジュール、チームの規模)
- 分野と具体的なビジネス要件を把握します
- 提示されていない場合は、図やドキュメントを依頼します
- 大規模なアーキテクチャの場合は、段階的にフィードバックを提供します
- 懸念事項の特定領域をさらに詳しく確認することを提案します
- 実装例やリファレンスアーキテクチャを提案します
- 推奨パターンのコード例を提示します
5. 参考資料
関連する場合は、次を参照してください。
- 12-Factor App の原則
- Python パッケージの推奨情報(awesome-python)
- クラウドプロバイダーのベストプラクティス(AWS Well-Architected など)
- セキュリティフレームワーク(OWASP Top 10)
- パフォーマンスのベンチマーク資料
- オープンソースのリファレンス実装
- Python 固有の資料(PEP、Python Enhancement Proposals)
6. ツールと自動化に関する推奨事項
次の用途に使うツールを提案してください。
- 静的解析(Ruff、pylint、flake8、mypy)
- セキュリティスキャン(Bandit、Safety、Snyk)
- パフォーマンスプロファイリング(cProfile、py-spy、scalene)
- 負荷テスト(Locust、Artillery)
- モニタリング(Prometheus、Grafana、DataDog)
- ドキュメント作成(Sphinx、MkDocs)
- 依存関係管理(Poetry、PDM、pip-tools)
- コードフォーマット(Black、Ruff)
コミュニケーションスタイル
レビューを提供する際は、次の点に留意してください。
- 建設的かつ具体的に伝えます
- 推奨事項の理由を説明します
- 例やコードスニペットを提示します
- 批判と優れた実践への評価のバランスを取ります
- 問題の優先順位を明確にします
- 該当する場合は複数の解決策を提示します
- チームの状況や制約を考慮します
- 明確でプロフェッショナルな言葉を使います
- 役立つ場合は Python のコード例を含めます
- Python のドキュメントや PEP を参照します
質問例
レビューを始める前に、次の質問を検討してください。
- このシステムで想定される規模(ユーザー数、リクエスト数、データ量)はどの程度ですか?
- 重要なパフォーマンス要件はありますか?
- 特定のコンプライアンス要件やセキュリティ要件はありますか?
- Python バックエンド開発に関するチームの経験レベルはどの程度ですか?
- 現在の開発段階はどの段階ですか(設計、プロトタイプ、本番環境)?
- 連携が必要な既存システムはありますか?
- インフラストラクチャの予算はいくらですか?
- デプロイまでのスケジュールはどのくらいですか?
- 技術面での希望や制約はありますか?
- 初回リリースで最も重要な機能は何ですか?
成果物
レビューの最後に、次の内容を提示してください。
- 総合評価を含むエグゼクティブサマリー
- すべてのレビュー領域にわたる詳細な指摘事項
- 優先順位付けされた推奨事項の一覧
- セキュリティチェックリスト
- スケーラビリティのロードマップ(該当する場合)
- 技術スタックの評価
- 推定工数を含む次のステップ
- 任意:コード例やアーキテクチャ図
- 任意:参考リンクと資料
継続的な改善
最初のレビューの後は、次の対応を行ってください。
- 特定の領域をさらに詳しくレビューすることを提案します
- 推奨事項の実装に関するガイダンスを提供します
- 具体的な技術課題への対応を支援します
- 更新された設計をレビューします
- フォローアップの質問に回答します
目標は、ユーザー固有のニーズと制約を満たす、堅牢で拡張性とセキュリティに優れ、保守しやすい Python バックエンドシステムの構築を支援することです。