プロフェッショナルな AI プロジェクトのディレクトリ構成

final.ipynb、final2.ipynb、really_final.ipynbという名前のノートブックを積み重ねるだけでは、AIプロジェクトはいずれ破綻します。一貫したディレクトリ構成にすると、プロジェクトが読みやすく、再現可能になり、共同作業もしやすくなります。

このレッスンでは、広く使われているCookiecutter Data Scienceの構成を扱います。

入力データが上書きされないように、処理段階ごとにデータを分けます。

• data/raw/ — 元の変更されないソースデータ
• data/processed/ — クリーニング済みでモデルに利用できるデータ
• data/interim/ — 中間的な変換結果

data/rawは読み取り専用として扱います。そこから他のすべてを常に再生成できるようにしてください。

クリーニングのバグによってデータの唯一のコピーが壊れると、プロジェクトは立ち行かなくなります。data/rawを変更せずに保てば、パイプラインを再実行することで、処理済みファイルをすべて再現できます。

処理済みの出力は使い捨てにできますが、rawデータは決して変更してはいけません。

notebooks/には、探索やレポート作成に使うノートブックを格納します。一般的な慣例として、処理段階の番号と作成者のイニシャルを付けます。たとえば 1.0-mk-eda.ipynb のようにします。

ノートブックは探索用です。再利用するロジックは src/ に移してください。

src/には、インポート可能なPythonコードを責務ごとに分けて格納します。

• src/data/ — データの読み込みと処理のスクリプト
• src/features/ — 特徴量エンジニアリング
• src/models/ — 学習と予測のコード
• src/visualization/ — プロットとレポート

特徴量エンジニアリングとモデリングを別のモジュールに分けると、多くのメリットがあります。特徴量のコードを単体テストでき、複数のノートブックで再利用でき、データ準備を書き直さずにモデルを入れ替えられます。

models/には、学習済みのシリアライズ済みアーティファクト（例：model.pkl、model.joblib）を保存します。これらはソースコードではなく、出力です。

通常、大きなモデルファイルはGitに入れるべきではありません。代わりに、DVCやオブジェクトストレージで管理します（次のレッスンで扱います）。

reports/には、人が読むために生成した出力を格納します。reports/figures/にはプロットを置き、プロジェクトのルートにはレポート文書を置きます。これらはコードから生成するため、再生成できます。

プロジェクトレベルのファイルを追加して、構成を整えます。

• requirements.txtまたはenvironment.yml — 依存関係
• config.yaml — ハイパーパラメーターとパス
• README.md — プロジェクトの概要と実行方法
• .gitignore — Gitが無視する対象

これらをまとめると、整理されたAIプロジェクトは次のようになります。

この構成を毎回手作業で作る必要はありません。cookiecutter-data-scienceテンプレートを使えば、1つのコマンドで構成全体をひな形として生成できます。

データ提供元から元のCSVファイルをダウンロードしたとします。

プロフェッショナルなAIプロジェクトの構成を学びました。

• data/raw（変更不可）と、処理段階ごとのdata/processed
• 探索用のnotebooks/と、再利用可能なコード用のsrc/featuresおよびsrc/models
• アーティファクト用のmodels/と、出力用のreports/
• ルートに配置する設定ファイル、requirements、README、.gitignore
• 構成全体をすぐにひな形として生成するcookiecutter-data-science

次は、AIプロジェクトでGitを効果的に使う方法です。