「あなたのエージェントはひどいコードを書いている、このツールがそれを捕まえる」
React DoctorのREADMEにはとても傲岸な一文があります：「Your agent writes bad React. This catches it.」
耳障りのいい言葉ではありませんが、2026年のほぼすべてのフロントエンド開発者が抱える痛みに突き刺さっています。
Cursor、Copilot、CodexといったAIプログラミングツールが普及して以来、フロントエンドコードの生産速度は数倍になりました。しかし速度が上がったとして、品質はどうでしょうか？
実戦から生まれたツール
React Doctorの作者はAiden Bai——Million.jsの創設者です。この人は普通のプロジェクトメンテナーではなく、Reactパフォーマンス最適化にほとんど執念とも言える追求を持つエンジニアです。
Million.js自体が「Reactより70%速い」を売りにした仮想DOMの代替方案です。だからこそ、彼が「AIが書いたReactコードに問題がある」と言うときは、真剣に耳を傾けるべきです。
さらに注目すべきは、このプロジェクトの最近更新頻度です——2時間前までPRをマージしており、誤検知の修正、スコアリングアルゴリズムの改善を行っています。これはコンセプト実証を作っているのではなく、真剣に使えるツールを作っていることを示しています。
実際には何をチェックするのか？
React Doctorは汎用的なリンターではありません。焦点を当てているのは、AI生成コードによくある「動いているように見えるが実際には罠」なパターンです：
- 不必要な再レンダリング：AIは
memoやuseMemoが欠けたコンポーネントを生成することが多く、機能的には問題ないがパフォーマンスは灾难 - 誤ったデータフェッチパターン：renderの中で直接APIを呼ぶ、エラーハンドリングの欠如、ローディング状態なし
- 過度に複雑なコンポーネント構造：AIはロジックを1つのコンポーネントに詰め込む傾向がある
- Reactベストプラクティスに違反する書き方：setStateを使わずにstateを直接変更するなど
チェックロジックは単純なASTマッチングではなく、セマンティック分析を組み合わせています——「このコードは文法的には正しいが、実行すると問題が起きる」ことを理解できます。
GitHub Action統合がキラー機能
React Doctorの最も賢いデザインは、それをGitHub Actionにしたことです。
手動で実行する必要はありません——PRが提出されるたびに自動的に走り、コード品質にスコアを付け、具体的な問題をリストアップします。つまり：
- AI生成コードが自動的にレビューされ、人手で1行ずつチェックする必要がない
- チームが品質閾値を設定でき、閾値を下回るPRは自動的にリジェクトされる
- 問題がPRに直接表示され、開発者がコードレビューインターフェースで直接確認できる
このワークフローのデザインは、実際のチーム開発シーンに非常にフィットしています。
リーダーボードが生む競争
React Doctorは最近Leaderboard機能を追加しました——異なるAIプログラミングツールのコード品質をランキングします。
一見小さな機能に見えますが、その意義はツール自体よりも大きいかもしれません。なぜなら、それは公開された比較次元を作り出したからです：誰の機能が多いか、谁的响应が速いかではなく、「谁的代码质量更好」という比較です。
この競争次元が成立すれば、AIプログラミングツールベンダーはコード品質に力を入れるようになり、機能の数だけを増やすことをしなくなるでしょう。
私の懸念
React Doctorの思路は素晴らしいですが、根本的な問題があります：「良いコード」を誰が定義するのか？
Aiden BaiのReactパフォーマンスに対する理解は間違いなくトップクラスですが、彼の基準がすべてのチーム、すべてのプロジェクトに適するわけではありません。一部のシナリオでは可読性がパフォーマンスより重要であり、一部のシナリオでは開発速度がコード品質より重要です。
React Doctorは「正しい書き方は一つしかない」というツールになることを避ける必要があります。幸い、最近の更新から、チームは誤検知率の低減とユーザーフィードバックの受け入れに積極的です——これは良いシグナルです。
AIツールでReactコードを書いているなら、React DoctorをCIプロセスに追加する価値があります。人手のコードレビューに取って代わるものではありませんが、「AIは問題ないと思ったが実際には問題がある」コードをブロックしてくれます。