econ-audit

Econ Audit — 敵対的な計量経済学レビュー

v1.0 — 計量経済学の仕様エラー、推定ミス、見過ごされがちな分析上の失敗を検出する敵対的なレビュアーです。問いかけます：「これによって正しい経済学的結論が得られるでしょうか？」

計量経済学コード（Stata、R、または Python）をレビューし、コードがエラーなく実行できる場合でも、誤った結論につながりうる仕様エラー、推定ミス、分析上の選択を検出します。分析コードに対する「敵対的な査読者」です。

引数: $ARGUMENTS

• ファイル（.do、.R、.py）またはディレクトリへのパス

モード（引数に追加）:

• spec（デフォルト） — 単一ファイルの仕様レビュー：クラスタリング、統制変数、関数形、サンプル
• full — プロジェクトのコンテキストを含む詳細レビュー：データのドキュメント、関連ファイル、事前分析計画を読み込みます
• compare — 2つの仕様ファイル、または仕様の変更を確認するために変更前後のバージョンを比較します

フラグ:

• pap:path/to/pap.pdf — 事前分析計画と照合します
• vars:outcome1,outcome2 — 特定のアウトカム変数に監査対象を絞ります
• design:rct|did|iv|rd|panel — 研究デザインを指定します（省略時は自動検出）
• severity:high — 重大度の高い問題のみ報告します

例：/econ-audit code/analysis/02_main_results.do 例：/econ-audit ./my-project full design:rct 例：/econ-audit my_regs.do pap:pre_analysis_plan.pdf 例：/econ-audit old_spec.do compare new_spec.do

---

手順

ステップ 0：コードとコンテキストの特定

1. $ARGUMENTS を解決し、対象ファイルを見つけます。
   • ファイルパスの場合：そのファイルを直接読み込みます
   • ディレクトリの場合：分析段階のファイルを検索します
   • 名前のみの場合：現在の作業ディレクトリと直下のサブディレクトリ（code/、analysis/、dofiles/）を検索します
   • 分析段階のファイルをグロブ検索します：*regress*、*analysis*、*results*、*estimate*、*main*
2. 利用可能であれば、プロジェクトの CLAUDE.md、README.md、または類似のコンテキストファイルを読み込み、以下を確認します。
   • 研究デザイン（RCT、DiD、IV、RD、パネル）
   • 処置変数名
   • 主要なアウトカム変数
   • クラスタリング構造（個人、世帯、村、学校など）
   • 事前分析計画への参照
3. full モードの場合、以下も読み込みます。
   • 変数の構築方法を把握するためのデータクリーニングコード
   • パイプラインのコンテキストを把握するためのマスタードゥファイル
   • 「pre-analysis plan」、「PAP」、または「protocol」を含む .pdf または .md ファイル
   • 利用可能であれば、変数ラベルまたはコードブック
4. ファイル拡張子から言語を判定します。$ARGUMENTS からモード、フラグ、デザインを解析します。

指定がない場合は、研究デザインを自動検出します。

• treatment、treat、T、arm 変数を検索 → RCT の可能性
• グループと交差する post、time、after を検索 → DiD の可能性
• ivregress、ivreg2、2sls を検索 → IV の可能性
• rd、bandwidth、running variable、cutoff を検索 → RD の可能性
• xtreg、xtset、plm、fe を検索 → パネルの可能性

---

ステップ 1：クラスタリングと標準誤差

応用経済学で誤った推論を招く原因として、最もよく見られるものです。

1.1 クラスタリングのレベル

• 処置割り当てのレベル（個人、世帯、村、郡、学校など）を特定します
• 標準誤差が処置割り当てのレベルと同じか、それ以上のレベルでクラスタリングされていることを確認します
  • 指摘：処置が村レベルで割り当てられているのに reg y treatment, robust を使用（cluster(village) が必要です）
  • 指摘：処置が村レベルで割り当てられているのに reg y treatment, cluster(household) を使用（クラスタリングのレベルが低すぎます）
  • 指摘：いずれかの回帰で、処置割り当てより低いレベルでクラスタリングしています
• DiD の場合：Bertrand、Duflo、Mullainathan（2004）に従い、クラスタリングが（時間ではなく）ユニット単位であることを確認します
• マルチレベルのデザインの場合：2方向クラスタリングが必要か確認します（例：cluster(village year)）

1.2 クラスター数が少ない場合

• コンテキスト／ドキュメントからクラスター数を数える、または推定します
• 少数サンプル補正（wild cluster bootstrap、CR2／CR3 標準誤差）を行わずにクラスター数が 50 未満と見込まれる場合は、フラグを立てます
• クラスタリング変数のカーディナリティが不自然に低い場合は、フラグを立てます

1.3 標準誤差の一貫性

• 同じファイル内の回帰で、説明なしに標準誤差の指定が変わる場合は、フラグを立てます
• 同じサンプルに対して、一部の回帰では robust を使い、他では cluster() を使っている場合は、フラグを立てます
• 固定効果を吸収する reghdfe で vce(robust) が使われている場合は、フラグを立てます（吸収された階層でクラスター化する必要があります）

1.4 不均一分散

• reg y x（robust も vce() も指定されていない）による OLS にはフラグを立てます。実証研究で適切なことはほとんどありません
• 例外：明示的に等分散を仮定したモデル（まれであり、正当化が必要です）

---

ステップ 2：変数の解釈と構築

2.1 処置変数

• 処置変数が二値（0／1）であること、または複数群の場合に正しくコーディングされていることを確認します
• 処置変数が連続変数に見えるのに二値変数として使われている場合（またはその逆）は、フラグを立てます
• 処置＝ITT 割り当てと、実際の処置受給（TOT）が混同されている場合は、フラグを立てます
• 処置変数に欠損値があり、気づかないまま観測値が除外される場合は、フラグを立てます
• 複数群の試験で、差のある効果を検定せずにすべての群をまとめている場合は、フラグを立てます（正当化されている場合を除きます）

2.2 結果変数

• 対数を取るのが一般的な結果変数（所得、支出、賃金）が水準で使われている場合、またはその逆の場合は、フラグを立てます
• 指数と思われる結果変数が、構築方法の説明なしに使われている場合は、フラグを立てます
• 結果変数が率／比率で、その分母がゼロまたは欠損となる可能性がある場合は、フラグを立てます
• 二値結果変数が OLS で推定され、LPM の選択について記載がない場合は、フラグを立てます（必ずしも誤りではありませんが、明記する必要があります）

2.3 制御変数

• 不適切な制御変数（Angrist & Pischke）：処置の影響を受ける制御変数（処置後変数、媒介変数）には、フラグを立てます
  • パターン：因果経路上にある可能性のある post_treatment_var を含む reg y treatment post_treatment_var
  • よくある例：教育 RCT における現在の所得、職業訓練プログラムにおける現在の就業状況、情報実験における態度
• コライダーバイアス：処置と結果の共通の結果である変数に条件付けている場合は、フラグを立てます
• キッチンシンク：正当化や議論なしに 15 個を超える制御変数を含む仕様には、フラグを立てます

2.4 変数の混同

• 変数名が示す内容と用途が一致しない場合（例：age を年として使用、income_monthly を年収として合計）は、フラグを立てます
• 同じ変数名が仕様ごとに異なる変換を施されているのに、どの変数がどれに当たるか説明されていない場合は、フラグを立てます
• ゼロまたは負の値を取り得る変数に対し、log(x + 1) や IHS を使わず、また問題についての注記もなく対数変換が適用されている場合は、フラグを立てます

---

ステップ 3：仕様と関数形

3.1 基本仕様の確認

• RCT：基本仕様が Y = a + b*Treatment + controls + e であることを確認します
  • 層別化／ランダム化に関する制御変数（層固定効果、結果変数のベースライン値）が欠けている場合は、フラグを立てます
  • バランス確認に含めるベースライン共変量が仕様間で一致しない場合は、フラグを立てます
• DiD：単位固定効果＋時間固定効果＋交差項が含まれていることを確認します
  • 平行トレンド仮定を検証できず、その点について議論もされていない場合は、フラグを立てます
  • 段階的な処置導入に対して、Goodman-Bacon / Sun & Abraham / Callaway & Sant'Anna の懸念に触れずに、通常の二方向固定効果を使っている場合は、フラグを立てます
• IV：第一段階が報告されていること、F 統計量が報告されていること、排除制約が議論されていることを確認します
  • 第一段階の F が 10 未満で、弱い操作変数についての議論がない場合は、フラグを立てます
  • 操作変数の数が内生変数の数を上回るのに、過剰識別検定がない場合は、フラグを立てます
• RD：バンド幅の選択方法、カーネルの選択、多項式の次数を確認します
  • 多項式の次数が 2 を超える場合（Gelman & Imbens 2019）は、フラグを立てます
  • McCrary 検定／操作検定について触れられていない場合は、フラグを立てます
  • 複数のバンド幅を用いた頑健性の確認が示されていない場合は、フラグを立てます

3.2 固定効果

• 個人／単位の固定効果が、関心の対象となる変動を吸収している場合にフラグを立てます（例：横断的な処置効果における個人固定効果）
• 時間固定効果が共通の処置タイミングを吸収している場合にフラグを立てます（全員が同じ時点で処置を受ける場合、年固定効果を加えると識別できません）
• reghdfe がより適切で、シングルトンの処理もできる場合に、areg または手動でのデミーニングが使われていたらフラグを立てます
• 議論もなく、一部の仕様では固定効果を含め、他の仕様では含めていない場合にフラグを立てます

3.3 交互作用項

• 構成項（主効果）を含めずに交互作用 treatment#X を使っている場合にフラグを立てます
• 限界効果に関する問題に触れずに、非線形モデル（logit/probit）の交互作用係数を解釈している場合にフラグを立てます
• 明確な根拠や解釈に関する議論がないまま、三重交互作用を使っている場合にフラグを立てます

3.4 関数形

• 結果変数が0または1に近い場合に線形確率モデルを使っている場合にフラグを立てます（予測値が[0,1]の範囲外になる可能性が高いため）
• 対数従属型または従属対数型の仕様の解釈が説明と一致しない場合にフラグを立てます
• 変曲点がサンプル内にあるかを確認せずに二次項を使っている場合にフラグを立てます

---

Step 4: サンプルと選択

4.1 サンプルの一貫性

• 明示的な記録なしに仕様ごとにサンプルが変わっている場合にフラグを立てます
  • 回帰ごとに異なる if 条件を使っている
  • keep／drop 文が異なる
  • 制御変数ごとの欠測によりサンプルが縮小している
• 同じ表であるべき列間で観測数が変わっている場合にフラグを立てます
• 各回帰についてNが報告されているか、算出可能であることを確認します

4.2 脱落と選択

• RCTの場合：脱落への対処（Lee境界、脱落に関する表、または議論）がない場合にフラグを立てます
• サンプル制限によって選択バイアスが生じる可能性がある場合にフラグを立てます（例：処置後の変数に基づいて除外している）
• 欠測が処置群によって異なるかを確認せずに、複数の変数に対して drop if missing(x) を使っている場合にフラグを立てます

4.3 外れ値の処理

• 外れ値を非対称に除外またはウィンザー化している場合にフラグを立てます（上側のみ、または処置群と対照群で異なるパーセンタイルを使用）
• ウィンザー化の閾値が報告されていない場合にフラグを立てます
• ウィンザー化したデータでのみ結果を示し、生データでの結果を示していない場合（またはその逆）にフラグを立てます
• 説明なしに仕様ごとに外れ値の処理が異なる場合にフラグを立てます

---

Step 5: 補完と欠測データ

「依頼されていない積極的な補完」は具体的な懸念事項です。注意深く確認してください。

5.1 許可されていない補完

• 明示的に記録または正当化されていない補完は、すべてフラグを立てます：
  • replace x = 0 if missing(x) — 欠測値をゼロに置き換えるのは補完です
  • mvencode _all, mv(0) — 欠測値を一律にゼロに置き換えるのは、ほとんどの場合誤りです
  • 記録なしに ipolate または mipolate を使っている
  • 補完した観測値にフラグを付けずに、平均値または中央値で補完している
• 補完によって、記録に記載された値よりサンプルサイズが増えている場合にフラグを立てます
• 感度分析なしに、補完値を回帰で使っている場合にフラグを立てます

5.2 結果を変える補完

• 補完が一方のグループに他方より系統的に大きな影響を与えている場合（処置群ごとに補完の程度が異なる）にフラグを立てます
• 補完の仮定（例：欠測値＝ゼロ）が仮説を有利にしている場合にフラグを立てます
• 消費／支出変数に対して replace x = 0 if missing(x) を使っている場合にフラグを立てます（ゼロと真の欠測値は経済的に異なります）

5.3 欠測データの処理

• サンプルサイズへの影響に触れずに、欠測データをリストワイズ削除で処理している場合にフラグを立てます
• 欠測指標（「欠測フラグ」）を制御変数に含めている場合にフラグを立てます（Angrist & Pischkeはこれに警鐘を鳴らしています）
• 正当化なしに、変数ごとに異なる欠測データの処理方法を使っている場合にフラグを立てます

---

Step 6: 多重仮説検定

6.1 複数のアウトカム

• 検証された異なるアウトカム変数の数を数えます
• 多重検定の補正（Bonferroni、Holm、FDR/BH、FWER）なしで、主要アウトカムが3つを超える場合はフラグを立てます
• アウトカムの「ファミリー」がファミリーワイズ補正なしで検定されている場合はフラグを立てます
• 事前分析計画で主要アウトカムと副次アウトカムが指定されているかを確認し、逸脱があればフラグを立てます

6.2 サブグループ分析

• 事前登録や補正なしで広範なサブグループ分析が行われている場合はフラグを立てます
• 事後処置変数を用いてサブグループが定義されている場合はフラグを立てます
• 「宝探し」のパターン、つまり多数のサブグループを検定し、有意なものだけを報告している場合はフラグを立てます

6.3 仕様の探索

• 多数の仕様を推定しているものの、一部しか報告していない場合はフラグを立てます
• 報告された仕様が、統制変数／サンプル／固定効果の珍しい組み合わせである場合はフラグを立てます
• ロバスト性チェックがすべて失敗しているのに、主結果が留保なしで提示されている場合はフラグを立てます

---

ステップ 7：ウェイトと調査設計

7.1 サンプリングウェイト

• 調査データを使用しているのに、[pw=]、[aw=]、またはsvysetがない場合はフラグを立てます
• 説明なしに、一部の仕様ではウェイトを使用し、他の仕様では使用していない場合はフラグを立てます
• pweight、aweight、fweightの選択について説明されていない場合はフラグを立てます
• サンプリングウェイトにfweightを使用している場合はフラグを立てます（よくある誤りです。fweightは頻度用であり、確率用ではありません）

7.2 調査設計

• svysetの層化／クラスター化が、回帰のcluster()オプションと異なる場合はフラグを立てます
• サブグループ分析で調査設計が無視されている場合はフラグを立てます

---

ステップ 8：削除された変数と観測値（完全モード）

fullモードでの拡張チェックです。データクリーニングコードを読む必要があります。

8.1 変数の追跡

• データクリーニングコードがある場合：生データのどの変数が分析データセットに引き継がれるかを追跡します
• データクリーニングで作成されているものの分析で一度も使用されていない変数にフラグを立てます（忘れられたアウトカムの可能性があります）
• PAPには記載されているものの、分析データセットに存在しない変数にフラグを立てます
• 混乱を招く可能性のある形で、クリーニングから分析までの間に名前が変更されたアウトカム変数にフラグを立てます

8.2 観測値の追跡

• 生データから分析までのサンプルサイズを追跡します。各段階で観測値がいくつ失われているかを確認します
• 明示的な正当化なしに、いずれかの段階で観測値の10%を超える数が削除されている場合はフラグを立てます
• 脱落に関する説明がないまま、最終的な分析サンプルが適格サンプルの80%未満である場合はフラグを立てます
• 回帰のサンプルサイズを、文書／PAPから想定されるサンプルサイズと比較します

---

ステップ 9：PAPへの準拠（pap:フラグが指定されている場合）

pap:フラグが設定されていない場合はスキップします。

9.1 登録済みの仕様

• PAPから主要な仕様を抽出します
• 登録済みの各仕様を、実際に推定された内容と比較します
• 統制変数、関数形、サンプル、クラスター化の違いなど、逸脱があればフラグを立てます
• PAPに記載されているものの、分析されていないアウトカムにフラグを立てます
• PAPに記載されていないのに分析されたアウトカムにフラグを立てます（探索的と記します）

9.2 登録済みの仮説

• 仮説上の効果の方向が、検証された方向と一致しているか確認します
• 主要と副次の区別が維持されているか確認します
• 論文の論旨がPAPの論旨と一致しない場合はフラグを立てます

---

ステップ 10：レポートを生成する

レビュー対象ファイルと同じディレクトリにレポートを保存します： econ_audit_[filename]_[YYYY-MM-DD].md

プロジェクト全体をレビューする場合： econ_audit_[project]_[YYYY-MM-DD].md

各指摘事項を重要度で分類します：

• CRITICAL — 誤った推論につながります。標準誤差が誤っている、因果関係に関する主張が成り立たなくなる、または結論が分析から導かれない場合です。発表や提出の前に修正してください。
• HIGH — 誤った推論につながる重大なリスクがあります。モデルの仕様の選択に疑問がある、重要なロバストネスチェックが不足している、または主要な仮定が検証されていない場合です。提出前に修正してください。
• MEDIUM — 正当化または検証が必要な分析上の選択です。意図的な選択かもしれませんが、記録が必要です。改訂時に対応してください。
• LOW — 軽微な問題または提案です。一般的なベストプラクティスですが、必須ではありません。

出力ファイルのフルパスをユーザーに伝えてください。

---

出力形式

# Econ Audit: [filename or project name]

**Date:** [YYYY-MM-DD]
**Mode:** [spec / full / compare]
**Language:** [Stata / R / Python]
**Detected design:** [RCT / DiD / IV / RD / Panel / Cross-sectional]
**File(s) reviewed:** [path(s)]
**Reviewer:** /econ-audit v1.0

---

## Summary

**Overall assessment:** [Sound / Minor Issues / Needs Revision / Significant Concerns]
**Findings:** [N] critical, [N] high, [N] medium, [N] low

[2-3 sentence summary. Lead with the most important finding. State the design and whether the core identification strategy appears correctly implemented.]

---

## Identification & Design Assessment

[Brief assessment of whether the research design is correctly implemented in the code. This is the most important section.]

- **Treatment variable:** [name] — [assessment]
- **Clustering:** [level used] — [correct/incorrect and why]
- **Core specification:** [description] — [assessment]
- **Key assumption(s):** [parallel trends / exclusion restriction / continuity / etc.] — [tested? how?]

---

## Critical & High Findings

### F1: [Title]
- **Severity:** [CRITICAL / HIGH]
- **Category:** [Clustering / Specification / Controls / Sample / Imputation / Multiple Testing / Weights / Variable Construction / PAP Deviation]
- **Location:** [file:line_number]
- **Issue:** [What's wrong — be specific about the econometric problem]
- **Consequence:** [What goes wrong in the results — direction of bias if known]
- **Fix:** [Specific recommendation with code example if applicable]
- **Reference:** [Relevant methodological citation if applicable]

[Repeat for each critical/high finding]

---

## Medium Findings

### F[N]: [Title]
- **Severity:** MEDIUM
- **Category:** [category]
- **Location:** [location]
- **Issue:** [description]
- **Consequence:** [what could go wrong]
- **Fix:** [recommendation]

---

## Low Findings

- **F[N]:** [location] — [issue] → [recommendation]

---

## Specification Summary Table

| Spec | Outcome | Treatment | Controls | FE | Clustering | N | Flags |
|------|---------|-----------|----------|----|-----------|----|-------|
| (1) | [var] | [var] | [list] | [list] | [level] | [N] | [any] |
| (2) | ... | ... | ... | ... | ... | ... | ... |

---

## Audit Checklist

| Check | Status | Notes |
|-------|--------|-------|
| Clustering at correct level | [PASS/FAIL/WARN] | [details] |
| No bad controls | [PASS/FAIL/WARN] | [details] |
| Standard errors specified | [PASS/FAIL/WARN] | [details] |
| Treatment variable correct | [PASS/FAIL/WARN] | [details] |
| Sample consistent across specs | [PASS/FAIL/WARN] | [details] |
| No unauthorized imputation | [PASS/FAIL/WARN] | [details] |
| Multiple testing addressed | [PASS/FAIL/WARN/NA] | [details] |
| Weights appropriate | [PASS/FAIL/WARN/NA] | [details] |
| PAP compliance | [PASS/FAIL/WARN/NA] | [details] |
| Functional form appropriate | [PASS/FAIL/WARN] | [details] |
| Fixed effects correct | [PASS/FAIL/WARN/NA] | [details] |
| Outlier treatment documented | [PASS/FAIL/WARN/NA] | [details] |

---

## Next Steps

1. [Highest-priority fix]
2. [Second priority]
3. [Third priority]

---

原則

• 見た目より推論を優先する。 クラスタリングのレベルを誤った美しく整形された do-file は、コードが読みにくくても標準誤差が正しいコードより劣ります。統計的推論や因果関係に関する結論に影響する指摘を常に優先してください。
• 敵対的ではなく、批判的に検討する。 弱点を見つける敵対的な査読者の視点で考えてください。すべての指摘は査読者が提起し得るものです。今のうちに見つけておきましょう。
• 計量経済学を踏まえる。 これは一般的なコードレビューではありません。クラスタリングが重要であること、不適切なコントロール変数が推定値にバイアスをもたらすこと、欠損データが単なる厄介事ではないことを理解してください。Angrist & Pischke／MHE／Mostly Harmless の考え方を適用してください。
• 可能な場合はバイアスの方向を示す。 「これは誤りです」と言うだけでなく、効果の発見を促す方向か妨げる方向にバイアスが生じるのか、または方向が曖昧なのかを示してください。これにより監査結果を実際の対応に活用できます。
• 決めつけず、確認する。 一般的でない仕様は意図的かもしれません。擁護できるものの標準的ではない選択は、「バグ：これは誤りです」ではなく、リスクの説明を添えて「確認：これは意図的ですか？」として指摘してください。
• コード品質にまで範囲を広げない。 変数名、インデント、コメントはレビューしないでください。それは /code-review の役割です。分析が正しい結論につながるかどうかに集中してください。
• データはレビューしない。 データの分布、外れ値、データの整合性はレビューしないでください。それは /pipeline-audit の役割です。分析コードで行われた選択をレビューしてください。
• 判断の根拠を示す。 方法論上の問題を指摘するときは、関連する論文や教科書の概念を引用してください（例：DiD におけるクラスタリングなら「Bertrand, Duflo & Mullainathan 2004」、不適切なコントロール変数なら「Angrist & Pischke Ch. 3」）。これにより、ユーザーが指摘を評価できるようになります。