mcpField
P
Python Backend Architecture Review

Python Backend Architecture Review

github.com/rknallテスト・品質86505 回インストール53 週間前に更新
リポジトリ

Python Backend Architecture Review について

Python バックエンドの設計を、システム設計、セキュリティ、データベース、API、性能、デプロイなどの観点から評価するスキルです。設計文書やシステムの説明を確認し、重要度別の指摘と具体的な提案をまとめます。

主な機能

  1. 01システム設計とコード構成の評価
  2. 02データベースと API 設計の確認
  3. 03セキュリティ、性能、可観測性の点検
  4. 04デプロイ、耐障害性、データフローの検討
  5. 05重要度別の指摘整理

活用シーン

  1. 01Python バックエンド設計文書のレビュー
  2. 02マイクロサービスやデータベース設計の評価
  3. 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.md
architecture-checklist.md
README.md
common-patterns.md

詳細

Python バックエンドアーキテクチャのレビュー

このスキルでは、インフラストラクチャからコードの構成まで、システム設計のあらゆる側面を網羅した、Python バックエンドアプリケーションの包括的なアーキテクチャレビュー機能を提供します。

このスキルを使用するタイミング

ユーザーが次の内容を依頼した場合に、このスキルを有効にします。

  • バックエンドアーキテクチャ設計ドキュメントのレビュー
  • Python アプリケーションのシステム設計に関するフィードバック
  • スケーラビリティのパターンとアプローチの分析
  • バックエンドアーキテクチャのセキュリティレビュー
  • データベース設計の評価
  • API 設計の評価
  • マイクロサービスアーキテクチャのレビュー
  • パフォーマンス最適化の提案
  • クラウドインフラストラクチャアーキテクチャのレビュー
  • コード構成とプロジェクト構造の分析

レビューフレームワーク

1. 初期分析

ユーザーからアーキテクチャドキュメントが提供された場合、またはシステムの説明を受けた場合は、次の手順で開始します。

  1. コンテキストの把握

    • 次の点について、明確にするための質問をします。
      • 想定される規模(ユーザー数、毎秒のリクエスト数、データ量)
      • パフォーマンス要件(レイテンシ、スループット)
      • セキュリティおよびコンプライアンス要件
      • チームの規模と専門知識
      • 予算の制約
      • 想定されるスケジュール
  2. ドキュメントの分析

    • アーキテクチャ図やドキュメントが提供された場合は、次の点を分析します。
      • コンポーネント間の関係と境界
      • データフローのパターン
      • 外部依存関係
      • 技術スタックの選択
      • デプロイメントトポロジー
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 のセキュリティに関するベストプラクティス
次のステップと優先順位

推奨事項を次のように優先順位付けしてください。

  1. 必ず修正すべき項目(ブロッキングとなる問題)
  2. 修正すべき項目(本番環境に重要なもの)
  3. あると望ましい項目(改善点)

推定工数と依存関係も含めてください。

4. 対話形式のレビュー手順

レビューを実施する際は、次の手順に従ってください。

  1. アーキテクチャの説明が不完全な場合は、まず確認の質問をします
  2. 制約について確認します(予算、スケジュール、チームの規模)
  3. 分野と具体的なビジネス要件を把握します
  4. 提示されていない場合は、図やドキュメントを依頼します
  5. 大規模なアーキテクチャの場合は、段階的にフィードバックを提供します
  6. 懸念事項の特定領域をさらに詳しく確認することを提案します
  7. 実装例やリファレンスアーキテクチャを提案します
  8. 推奨パターンのコード例を提示します
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 を参照します

質問例

レビューを始める前に、次の質問を検討してください。

  1. このシステムで想定される規模(ユーザー数、リクエスト数、データ量)はどの程度ですか?
  2. 重要なパフォーマンス要件はありますか?
  3. 特定のコンプライアンス要件やセキュリティ要件はありますか?
  4. Python バックエンド開発に関するチームの経験レベルはどの程度ですか?
  5. 現在の開発段階はどの段階ですか(設計、プロトタイプ、本番環境)?
  6. 連携が必要な既存システムはありますか?
  7. インフラストラクチャの予算はいくらですか?
  8. デプロイまでのスケジュールはどのくらいですか?
  9. 技術面での希望や制約はありますか?
  10. 初回リリースで最も重要な機能は何ですか?

成果物

レビューの最後に、次の内容を提示してください。

  1. 総合評価を含むエグゼクティブサマリー
  2. すべてのレビュー領域にわたる詳細な指摘事項
  3. 優先順位付けされた推奨事項の一覧
  4. セキュリティチェックリスト
  5. スケーラビリティのロードマップ(該当する場合)
  6. 技術スタックの評価
  7. 推定工数を含む次のステップ
  8. 任意:コード例やアーキテクチャ図
  9. 任意:参考リンクと資料

継続的な改善

最初のレビューの後は、次の対応を行ってください。

  • 特定の領域をさらに詳しくレビューすることを提案します
  • 推奨事項の実装に関するガイダンスを提供します
  • 具体的な技術課題への対応を支援します
  • 更新された設計をレビューします
  • フォローアップの質問に回答します

目標は、ユーザー固有のニーズと制約を満たす、堅牢で拡張性とセキュリティに優れ、保守しやすい Python バックエンドシステムの構築を支援することです。

コメント