data-analysis-patterns

データ分析パターン

データ分析ワークフローにおける重要な判断、特に集計、再計算、分析の整合性の維持に関する専門的なガイダンスです。

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

• 生データから再計算するか、集計済みデータを再利用するかを判断するとき
• 既存の分析でカテゴリ定義を変更するとき
• 公開品質の分析の正確性を確保するとき
• 分離が必要な、複数の特徴が混在したデータを扱うとき
• 正確性を損なわずに分析パイプラインを最適化するとき
• 複合キーを使って複数ソースのデータセットを結合するとき
• エンリッチメント中に発生するDataFrameの型変換の問題に対処するとき

基本パターン

1. 集計済みデータの再計算と再利用

集計済みデータがあるものの、異なるカテゴリやグループ分けが必要な場合：

• カテゴリ定義が根本的に変わる場合、以前は混在していた特徴を分離する必要がある場合、集計基準が変わる場合、または公開時の正確性が重要な場合は、生データから再計算します
• 探索的分析の場合、カテゴリがほぼ一致する場合、または生データが利用できない場合は、近似でも許容できることがあります
• ルール：情報を失わずに古い分類から新しい分類へ確実に対応づけられない場合は、再計算します

詳細なパターンとコード例については、data-manipulation-recipes.mdを参照してください

2. 複数ソースのデータ結合に使う複合キー

複数のソースからデータセットを結合する場合、単一の識別子では一意にならないことがよくあります：

• 複数のフィールドを区切り文字（|または::）で連結して複合キーを作成します
• 複合キーを作成した後は、必ず一意性を確認します
• 結合前に重複を明示的に処理します（最新の日付を優先し、次に最も完全なレコードを優先します）
• 最終保存の前に複合キーを削除します（一時的な作業用列です）

実装の詳細については、data-manipulation-recipes.mdを参照してください

3. 混在した特徴の分離

1つの指標に複数の独立した特徴が含まれている場合は、それぞれを独立した分析に分けます：

• 各カテゴリにどの特徴が混在しているかを特定します
• 独立した特徴ごとにカテゴリ体系を作成します
• これにより、明確な解釈と将来的な独立分析が可能になります

例については、data-manipulation-recipes.mdを参照してください

4. エンリッチメント中のDataFrameの型変換

外部ソースのデータでDataFrameをエンリッチメントする際には、型の不一致がよく発生します：

• 代入前に対象列のdtypeを確認します
• 値を対象のdtypeに合わせて変換します（列全体を変換するより簡単です）
• 型チェックのロジックをカプセル化するヘルパー関数を使用します
• pd.notna()によるチェックを使ってNaNを明示的に処理します

型安全な代入パターンと例については、data-manipulation-recipes.mdを参照してください

5. AWSデータエンリッチメントのパターン

AWS S3または外部リポジトリの表形式データをエンリッチメントする場合：

• 複数ソースのパス解決を使用します（直接検索とパス推定）
• 冪等な再実行のため、最も完全な入力ファイルを自動検出します
• 列は冪等に追加します（追加前に確認します）
• エンリッチメント全体を実行する前に、初期検証にTEST_MODEを使用します

実装パターンについては、enrichment-patterns.mdを参照してください

6. 重要なデータ検証

列名が必ずしも内容と一致するとは限りません。カテゴリ列を使う前に、必ずソースコードと照合してください：

• ソーススクリプトを特定し、値の割り当てロジックを確認します
• 生物学的妥当性を検証するアサーションを追加します
• 既知のコントロールサンプルでテストします
• 見つかった不一致を文書化して修正します

検証ワークフロー全体と予防チェックリストについては、validation-patterns.mdを参照してください

7. データの出所の検証

派生列で質の低いデータソースを使うと、気づかないうちにデータが失われることがあります。

• 派生列のカバレッジを、データソースとなる可能性が高い列と比較します
• クロス集計して、対応関係の一貫性を検証します
• 疎な外部ファイルをマージするより、情報量の多いソース列から再分類することを優先します

診断パターンについては、validation-patterns.mdを参照してください。

8. トークン効率を高める分析テキストの整理

計算（ノートブック）と解釈（Markdown ファイル）を分離します。

• 図ごとの Markdown ファイルを格納するanalysis_files/ディレクトリを作成します
• ノートブックにはコードを、分析ファイルには解釈を記述します
• トークン削減率：98%（ノートブックは1.1Mトークン、分析ファイルは22Kトークン）

ディレクトリ構成と執筆ガイドラインについては、analysis-organization.mdを参照してください。

9. 多因子実験計画の分析

実験計画に複数の因子がある場合：

• 3カテゴリーの設計を使って、各因子の個別の影響を切り分けます
• 1つの因子を一度に1つずつ統制しながら、ペアを比較します
• 相乗的、支配的、または拮抗的な相互作用を特定します

解釈のフレームワークと例については、analysis-interpretation.mdを参照してください。

10. 逆説的な結果の解釈

あるカテゴリーが指標Xでは優れた結果を示す一方、関連する指標YとZでは劣る場合：

• トレードオフ仮説のフレームワークを適用します
• 直感に反する結果を透明性をもって記録します
• 結果を退けるのではなく、メカニズムに基づく説明を探ります

記録パターンについては、analysis-interpretation.mdを参照してください。

11. 種名の照合

外部サービスで、メタデータとは異なる種名が使われている場合：

• 不一致を、体系的な置換と名称の異形に分類します
• 異形の検出にはファジーマッチングを使います
• 関連するすべてのファイルに修正を反映します
• 修正段階を追跡できるよう、ファイルにバージョンを付けます

照合のワークフローとコードについては、species-reconciliation.mdを参照してください。

12. 系統樹のカバレッジ分析

系統樹のうち、データを利用できる割合を追跡します。

• カバレッジ指標を計算し、欠損している種を特定します
• 欠損を、復元可能、系統学的コンテキスト、または不明に分類します
• 非推奨データセットからTime Treeの代替データを復元します
• 想定内・想定外のデータ欠損を記録します

カバレッジ分析のワークフローについては、species-reconciliation.mdを参照してください。

13. 真の変動と検出力の限界の区別

複数のグループを分析する際は、効果が見られない原因が実際に効果がないためなのか、検出力が不十分なためなのかを判断します。

• 検出力の限界を示す指標：サンプル数が少ない、予想される方向への傾向がある、カテゴリー間に不均衡がある、信頼区間が広い
• 真の帰無を示す指標：サンプル数が多く信頼区間が狭い、他のグループとは反対方向の結果が出ている、一部の指標では有意だが他の指標では有意でない
• 適切に報告します：「検出力が不十分」か「十分な検出力があるにもかかわらず効果がない」

報告に関する推奨事項と例については、analysis-interpretation.mdを参照してください。

14. 技術的交絡の分析

時間的な傾向は、手法の改善ではなく技術の導入を反映している可能性があります。

• 3段階のアプローチを使います：複数の技術が混在するベースライン、技術を統制したサブセット、比較
• 直交性、持続性、時間的なパターンを検証します
• 技術をまたいでデータを統合するかどうかを判断するための決定マトリクスを使います

体系的な検証アプローチについては、analysis-interpretation.mdを参照してください。

15. データ統合とエンリッチメントのワークフロー

複数の中間データセットバージョンを扱う場合：

• 統合 -> エンリッチメント -> 検証のパターンに従います
• フィルタリングしたサブセットは、必ずエンリッチメント済みのマスターから再構築します（手動で結合しないでください）
• リリース日が信頼できない場合は、リポジトリのファイル名から正確な日付を抽出します

ワークフローの詳細については、enrichment-patterns.md を参照してください。

16. データファイルの圧縮戦略

大きなデータファイルは削除せずに圧縮します：

• 判断基準：アクティブ（保持）／再生成可能（削除）／アーカイブ（圧縮）
• BED／VCF／FASTA は gzip で 70～90％圧縮できます
• 圧縮ファイルを直接読み込むよう、スクリプトを更新します
• README に圧縮について記載します

圧縮のベンチマークとワークフローについては、compression-strategies.md を参照してください。

主要な原則

1. カテゴリの定義が変更された場合、特徴が混同されていた場合、または公開用の正確性が必要な場合は、再計算を優先します
2. 近似値を使用する場合はその旨を記録し、再計算したデータのサブセットと照合して検証します
3. 明確にするため、混同されている特徴を個別の分析に分離します
4. 分析の前に、必ずソースコードと照らし合わせて列名を確認します
5. DataFrame をエンリッチする際は、代入の前にdtype を確認します
6. 新しい列を手動で結合するのではなく、マスターからフィルタリング済みのサブセットを再構築します
7. 技術世代をまたいでプールする前に、技術による交絡がないか確認します
8. 後で必要になる可能性のあるデータファイルは、削除せず圧縮します

ベストプラクティス

情報の損失を評価する

集約データを再利用するか判断する前に、次の点を確認します：集約データから生データを完全に再構築できますか？できない場合は、再計算します。

判断を記録する

"""
Data source: scaffold_telomere_data.csv (n=6,356 scaffolds)
Recalculated: 2026-01-29
Reason: Previous aggregation conflated terminal and interstitial presence
Method: [describe categorization logic]
"""

可能であれば元データと照合して検証する

original_total = df['cat1'] + df['cat2'] + df['cat3'] + df['cat4']
new_total = df['new_cat1'] + df['new_cat2'] + df['new_cat3']
assert (original_total == new_total).all(), "Category totals don't match!"

時間と正確性のトレードオフ

• 探索段階：近似値を使用してもかまいませんが、その旨を明確に記録します
• 公開段階：正確性を確保するため、必ず再計算します
• 中間段階：一度再計算して結果を保存し、その結果を再利用します

パフォーマンスに関する考慮事項

再計算は、思っているより速く完了することがよくあります：

# Modern pandas on 10,000+ rows
df['new_cat'] = df.apply(categorize_func, axis=1)
result = df.groupby('species').agg({'new_cat': 'value_counts'})
# Often < 1 second

最適化：ベクトル化演算を使用し、関連する列に絞り込み、中間結果をキャッシュします。

関連ファイル

ファイル	内容
data-manipulation-recipes.md	再計算のパターン、複合キー、混同された特徴、型変換
enrichment-patterns.md	AWS のエンリッチメント、データ統合、日付抽出、フィルタリング済みデータセットの再構築
validation-patterns.md	列名の確認、データ品質チェック、データの来歴
analysis-interpretation.md	多要因デザイン、逆説的な結果、検出力の限界、技術による交絡
species-reconciliation.md	種名の照合、系統樹のカバー範囲
analysis-organization.md	トークン効率に優れた分析テキストの整理、統計結果の入力
compression-strategies.md	ファイル圧縮の判断基準、ベンチマーク、スクリプトの更新