🐥

Anthropicで利用されているモダンなPython開発のベストプラクティス

に公開1

はじめに

Anthropic といえば、最近はコード生成ツールが大きな話題になっていますよね。

AI企業アンスロピック、今年の売上高30億ドルに急増へ

売上高を牽引しているのはコード生成機能です。グーグルの親会社であるアルファベット([GOOGL.O](https://jp.reuters.com/markets/companies/GOOGL.O))や、アマゾン・ドット・コム([AMZN.O](https://jp.reuters.com/markets/companies/AMZN.O))が支援しているアンスロピックは、コンピュータープログラミングに特化した AI として知られています。

このコード生成機能を活用する際に使用するのが、CLI コマンドの claude です。このツールの完成度は非常に高く、最近ではコード生成時に積極的に利用するエンジニアも増えてきています。

この claude を効果的に使うために参照されているのが、CLAUDE.md というドキュメントです。

CLAUDE.md とは何かというと、claude を使ってコードを生成する際の「Development Guidelines (開発ガイドライン)」のようなものです。
簡単に言えば、コード生成時に守るべきルールやガイドラインを定めたドキュメントで、これを明確に定義することで、希望に沿ったコードをより高い精度で生成できるようになります。

とはいえ、CLAUDE.md が重要だとドキュメントに書かれていても、リアルワールドのプロジェクトでどのように活用すればよいのか、具体的なプラクティスまでは見えてこないこともあります。

そんな中、Model Context Protocol(MCP)の開発にあたって、たまたま python-sdk のソースコードを読んでいたのですが、そこに含まれている CLAUDE.md が非常に参考になる内容でした。

どの程度参考になるかというと、近年の Python 開発における Development Guidelines(開発ガイドライン)のロールモデルとして十分通用するレベルの完成度で、とても実践的な内容です。今回はその内容を紹介したいと思います。

Anthorpicで利用されているモダンなPython開発時のDevelopment Guidelines(開発ガイドライン)

CLAUDE.md には、Git や PR の運用ルールなども含まれています。
今回はその中から、特に Python 開発において実用的と思われる部分を抜粋して紹介します。

なお、今回紹介する部分以外にも、claude の利用時や開発フローの整備に役立つ内容が多く含まれているため、可能であれば全文に目を通すことをおすすめします


Core Development Rules(基本開発ルール)

このセクションでは、プロジェクトにおけるパッケージ管理、コード品質、テスト要件についてのルールが体系的にまとめられています。
特に pip の使用を禁止し uv を標準にする方針や、関数の粒度、型ヒントの徹底、非同期テストにおける anyio の使用など、再現性と堅牢性を重視した構成が印象的です。

1. パッケージ管理
   - `uv` のみを使用し、`pip` は絶対に使わない
   - インストール方法:`uv add package`
   - ツールの実行:`uv run tool`
   - アップグレード:`uv add --dev package --upgrade-package package`
   - 禁止事項:`uv pip install``@latest` 構文の使用

2. コード品質
   - すべてのコードに型ヒントを必須とする
   - パブリックAPIには必ずドキュメンテーション文字列(docstring)を付ける
   - 関数は集中して小さく保つこと
   - 既存のパターンを正確に踏襲すること
   - 行の最大長は88文字まで

3. テスト要件
   - テストフレームワーク:`uv run --frozen pytest`
   - 非同期テストは `asyncio` ではなく `anyio` を使用
   - カバレッジはエッジケースやエラーも含めてテストすること
   - 新機能には必ずテストを追加すること
   - バグ修正にはユニットテストを追加すること

Python Tools(Python 開発ツール)

このセクションでは、開発環境で使用されるツール群とその具体的な使い方が整理されています。
ruffpyrightpre-commit などのツールに対し、コマンドの実行例とともに整形・静的解析・コミット前フックの適用手順が丁寧に記載されています。

1. Ruff
   - フォーマット実行:`uv run --frozen ruff format .`
   - チェック実行:`uv run --frozen ruff check .`
   - 修正実行:`uv run --frozen ruff check . --fix`
   - 重要な指摘内容:
     - 行の長さ(88文字)
     - インポートのソート(I001)
     - 未使用のインポート
   - 行の折り返し:
     - 文字列は括弧を使う
     - 関数呼び出しは複数行にして適切にインデント
     - インポート文は複数行に分ける

2. 型チェック
   - ツール:`uv run --frozen pyright`
   - 要件:
     - Optional型には明示的なNoneチェックを入れる
     - 文字列の型は狭めて扱う
     - バージョン警告はチェックが通れば無視してよい

3. Pre-commit
   - 設定ファイル:`.pre-commit-config.yaml`
   - 実行タイミング:gitコミット時
   - 使用ツール:Prettier(YAML/JSON用)、Ruff(Python用)
   - Ruffの更新方法:
     - PyPIのバージョンを確認する
     - 設定ファイルのリビジョンを更新する
     - まず設定ファイルをコミットする

Development Guidelines(開発ガイドライン)まとめ

上記の内容を箇条書きでまとめると以下のようになります。

パッケージ管理

  • uvツールのみを使用(pipは禁止)
  • インストール、実行、アップグレードの具体的なコマンド指定
  • 特定の構文(@latestなど)の使用禁止

コード品質基準

  • 型ヒントの必須化
  • 公開APIへのdocstring要求
  • 88文字の行長制限
  • 関数の簡潔性と既存パターンへの準拠

テスト要件

  • pytestフレームワークの使用
  • 非同期テストではanyioを使用
  • エッジケースとエラーのテストカバレッジ
  • 新機能とバグ修正に対するテスト必須

開発ツール

  • Ruff: コードフォーマッターとリンター
  • Pyright: 型チェック
  • Pre-commit: Git コミット時の自動チェック

まとめ

今回は、CLAUDE.md にまとめられたPython開発に関するルールとツールについて紹介しました。

特に基本開発ルールでは、uv のみを使用し、pip は一切禁止する方針が明確に示されています。これにより、依存関係の管理が一元化され、環境の再現性が大幅に向上します。また、@latest のような曖昧なバージョン指定の廃止も徹底されており、常に安定した依存関係を保つことが重視されています。

コード品質やテストに関する厳格なガイドラインも設けられており、型ヒントの徹底、関数の粒度管理、非同期テストにおける anyio の使用など、堅牢でメンテナブルなコード作成が推奨されています。

さらに、ruffpyrightpre-commit といったツールの活用方法も具体的に示されており、コード整形や静的解析、コミット前チェックを効率的に実行できます。

CLAUDE.md には今回紹介した部分以外にも、claude の利用や開発フローの整備に役立つ有益な情報が多数含まれています。全文に目を通し、日々の開発にぜひ活かしてください。

今回取り上げたAnthropicのプロジェクトで採用されているDevelopment Guidelines(開発ガイドライン)の内容は、モダンなPython開発をする上で必須となる実践的な手法やベストプラクティスを網羅的に含んでおり、新規プロジェクト今からPython開発をする際にはかなり役に立つ内容なので、これらを参考にすることでモダンで快適で効率的なPython環境の構築を行うことができるようになるでしょう。

余談: https://claude.md とブラウザで入力すると https://docs.anthropic.com/en/docs/claude-code/overview にリダイレクトされるとは芸が細かい😲

Discussion

guvnrtheguvnrthe

@latestを使わないとすぐ依存関係が古くなって、いちいち手動でアップデートしないといけなくなる。それに、直接使うパッケージのバージョンは確定出来ても、そのパッケージが@latest使ってたらバージョンは確定しない。モダンなプラクティスはむしろ@latestを積極的に使うことで、何らかの仕組みでflattenされた依存関係の変更管理をすることかな。もちろん、@latestで問題が発生したらパッケージのバージョンを固定するのは構わない。