AIコードレビューは、
「なんでも任せる」で失敗する

「presentation層からrepository層を直接importしない」といったアーキテクチャ上の制約は、import文を構文的にチェックするだけで機械的に検出できます。

custom_lint:
  rules:
    - import_rule:
      presentation_layer:
        target: "package:app/feature/*/presentation/*.dart"
        from: "package:app/feature/*/*.dart"
        message: "Presentation層では許可された依存関係のみ使用できます。"

「applicationフォルダには *_service.dart 以外のファイルを置かない」といったチーム独自の配置規約は、ファイルパスとファイル名を正規表現でチェックするだけで判定できます。

class ApplicationLayerLintRule extends DartLintRule {
  @override
  void run(CustomLintResolver resolver, ErrorReporter reporter,
      CustomLintContext context) {
    final path = resolver.source.uri.path.split('/');
    final fileName = path.last.split('.').first;
    final folder = path[path.length - 2];

    if (folder == 'application' &&
        !RegExp(r'^.+_service$').hasMatch(fileName)) {
      reporter.atOffset(offset: 0, length: 1, errorCode: code);
    }
  }
}

build内でref.readを使うこと自体が常に誤りというわけではありません。ただし「画面を再描画したい値をref.readで取得している」場合は、値の変更を購読していないため、変更時に再ビルドされないという具体的な不具合につながります。この「UI更新目的の参照かどうか」を呼び出し位置とメソッド名の組み合わせから機械的に検出できます。

Widget build(BuildContext context, WidgetRef ref) {
  final counter = ref.read(counterProvider);
  // 値の変更を購読していないため、
  // 変更されても再ビルドされない
  return Text('$counter');
}

Widget build(BuildContext context, WidgetRef ref) {
  final counter = ref.watch(counterProvider);
  // 値の変化を購読している
  return Text('$counter');
}

TextEditingControllerなどをdispose()し忘れるとメモリリークにつながります。フィールドで直接生成されているような単純なパターンであれば、生成箇所と解放箇所の対応関係を構文的に追跡し、「disposeされていない可能性」を検出できます。

class _MyWidgetState extends State<MyWidget> {
  final _controller = TextEditingController();
  // disposeされていない

  @override
  Widget build(BuildContext context) =>
      TextField(controller: _controller);
}

class _MyWidgetState extends State<MyWidget> {
  final _controller = TextEditingController();

  @override
  void dispose() {
    _controller.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) =>
      TextField(controller: _controller);
}

※ 別メソッドへの委譲（final controller = createController();のような間接生成）や継承・条件分岐が絡む複雑なケースでは、単純なAST（抽象構文木）パターンだけでは検出しきれない場合があります。「万能に検出できる」わけではなく、あくまで一定パターンに対する検出です。

「Widgetのテキストに文字列リテラルを直接書かない」というi18nルールは、引数が文字列リテラルかどうかを構文的に判定するだけで検出できます。

Text('Hello, world!');

Text(AppLocalizations.of(context).greeting);

「DateTime.now()を直接呼ばず、注入されたClockを経由する」というテスト容易性の規約も、特定メソッドの呼び出しパターンとして機械的に検出できます。「dispose漏れ」と同様、あくまで一定の呼び出しパターンに対する検出です。

class OrderService {
  bool isExpired(Order order) {
    // DateTime.now()を直接呼ぶとテストで
    // 時刻を固定できない
    return DateTime.now().isAfter(order.expiresAt);
  }
}

class OrderService {
  OrderService(this._clock);
  final Clock _clock;

  bool isExpired(Order order) {
    return _clock.now().isAfter(order.expiresAt);
  }
}

include: package:flutter_lints/flutter.yaml

analyzer:
  plugins:
    - custom_lint

custom_lint:
  rules:
    # 1. アーキテクチャ・レイヤー制約 --------------------------------------
    - layer_file_naming:
        directories:
          "data/services": ["_service.dart", "_client.dart"]
          "data/repositories": ["_repository.dart"]
          "data/models": ["_api_model.dart", "_model.dart"]
          "domain/use_cases": ["_use_case.dart"]
          "ui/features/*/view_models": ["_view_model.dart"]
          "ui/features/*/views": ["_view.dart", "_page.dart"]
    - layer_import_boundary:
        layers:
          domain: []
          data: [domain]
          ui: [domain, data]

    # 2. Riverpod の使い方 -----------------------------------------------
    - avoid_ref_read_inside_build
    - prefer_static_provider

    # 3. Widget 実装上の注意点 -----------------------------------------
    - always_dispose_controllers
    - avoid_single_child_flex

    # 4. i18n 強制 ----------------------------------------------------
    - no_literal_string_in_widget:
        allow_empty: true

    # 5. チーム独自規約 ------------------------------------------------
    - avoid_datetime_now

※ ここまでの本文では紹介しきれなかったprefer_static_provider（providerをトップレベルのfinal変数として定義することを強制するもの）やavoid_single_child_flex（単一子要素のColumn/Rowを検出するもの）も含めています。前者はRiverpod公式ドキュメントが推奨する書き方、後者は前回までの記事内でも触れたルールです。

custom_lintのテストでは、// expect_lint: ルール名というコメントを使い、「このルールがここで検出されるはずだ」という期待値をコード上に書く手法がよく使われます。ここでは同じサンプルアプリ（Counterアプリ）を題材に、上のYAMLで定義した各ルールが検出するNGパターンをまとめて示します。

layer_import_boundary：dataレイヤーからuiレイヤーの型に触れている

// expect_lint: layer_import_boundary
import 'package:sample_app/ui/features/counter/views/counter_page.dart';

class BadAnalyticsService {
  void track(Object screen) {
    // data から ui の型に触ってしまっている悪い例
    assert(screen is CounterPage || true);
  }
}

layer_file_naming：配置フォルダに対して許可されていない命名のファイル

// expect_lint: layer_file_naming
import 'package:sample_app/data/models/counter_api_model.dart';

class CounterCache {
  CounterApiModel? last;
}

layer_import_boundary：domainがdataの型（APIモデル）を直接知っている

// expect_lint: layer_import_boundary
import 'package:sample_app/data/models/counter_api_model.dart';

/// domain が data の型（API モデル）を直接知ってしまっている悪い例。
class BadCounterStats {
  const BadCounterStats(this.raw);

  final CounterApiModel raw;
}

avoid_datetime_now：DateTime.now()の直接呼び出し

void increment() {
  // NG: 現在時刻を直接取得している。テストで時刻を固定できない。
  // expect_lint: avoid_datetime_now
  final now = DateTime.now();
  final next = Counter(value: state, updatedAt: now).increment(now);
  state = next.value;
}

1つのWidgetに複数のNGパターンが同時に現れる例

class BadCounterView extends ConsumerWidget {
  const BadCounterView({super.key, required this.provider});

  // NG: providerをフィールドで持ち回している。静的解析できずwatchも追えない。
  // expect_lint: prefer_static_provider
  final NotifierProvider<CounterViewModel, int> provider;

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // NG: build直下のref.read。値が変わっても再描画されない。
    // expect_lint: avoid_ref_read_inside_build
    final count = ref.read(counterViewModelProvider);

    // NG: 子が1つしかないColumn。
    // expect_lint: avoid_single_child_flex
    return Column(
      children: [
        // NG: Textへの文字列直書き（i18nされていない）。
        // expect_lint: no_literal_string_in_widget
        Text('現在の値: $count'),
      ],
    );
  }
}

always_dispose_controllers：Controllerのdispose漏れ

class BadInputField extends StatefulWidget {
  const BadInputField({super.key});

  @override
  State<BadInputField> createState() => _BadInputFieldState();
}

class _BadInputFieldState extends State<BadInputField> {
  // expect_lint: always_dispose_controllers
  final _controller = TextEditingController();

  @override
  Widget build(BuildContext context) {
    return TextField(controller: _controller);
  }
}

※ 実際のテストでは、これらのNG例に対応する形でOK例（ルール違反を修正したコード）も用意し、両方に対してcustom_lintのテストランナーを実行して検証します。

ここまで見てきたcustom_lintは、Flutter/Dartで「実行せずに機械的に判定できる」仕組みの一部です。Dart Analyzer・flutter_test・Golden Testも性質は違いますが、同じ「決定的・低コスト・CIでブロック可能」という条件を満たします。

Dart Analyzer：コードを実行せず、型やnull安全性を検査する

「Stringを渡すべき引数にintを渡している」「nullかもしれない値をnullチェックなしで使っている」といった違反は、custom_lintの土台でもあるDart Analyzerが標準で検出します。custom_lintは、このAnalyzerのプラグイン機構の上で動く拡張です。

flutter_test：実際にWidgetを動かして振る舞いを検証する

testWidgets('ボタンをタップするとカウントが増える', (tester) async {
  await tester.pumpWidget(const CounterApp());

  expect(find.text('0'), findsOneWidget);

  await tester.tap(find.byIcon(Icons.add));
  await tester.pump();

  expect(find.text('1'), findsOneWidget);
});

「このボタンを押したら、この状態になるはずだ」という期待値をコードで書いておき、実行結果と機械的に照合します。lintがコードの構造を検査するのに対し、flutter_testは実際に動かした振る舞いを検査します。

Golden Test：見た目の意図しない変化を検出する

Widgetを実際に描画し、あらかじめ保存しておいた基準画像（golden image）とピクセル単位で比較します。「ロジックは正しいが、意図せずレイアウトが崩れた」という、AIにも人間のレビュアーにも気づきにくい変化を機械的に検出できます。