AIでReact開発を進める方法｜設計から修正まで

AIでReact開発を進めるときは、画面全体を一度に作らせず、要件、componentの責務、状態の流れ、受け入れ条件を先に決めて、小さな差分で依頼します。生成コードが型checkを通っても、既存projectの設計に合うとは限りません。変更範囲を限定し、既存のpattern、tests、表示状態を確認しながら統合してください。

依頼の前にprojectの事実を集める

まず、現在のReact version、framework、routing、TypeScriptの有無、CSS方式、test runner、既存のcomponent構成を確認します。AIへは必要な設定や該当ファイルだけを渡し、project全体のruleを推測させません。既存のAGENTS.md、README、lint設定、関連componentがあれば、そちらを優先します。依存追加や大規模なfolder移動を先に決めさせないでください。

依頼には、ユーザーが行う操作、表示する内容、loading・empty・error時の状態、変更可能な範囲を含めます。「検索フォームを作る」だけでは、入力、submit、URL更新、結果0件、失敗時の動きが不明です。要件に答えられない点は、AIへ不足項目として出させ、曖昧なまま仮の仕様を実装しないようにします。

Componentの役割を画面要件から切り分ける

ReactのcomponentはUIを組み立てる単位です。画面の見た目だけで分割せず、再利用する責務、データを持つ場所、親子で共有する操作を見ます。ボタン、入力欄、結果一覧などを分けても、あらゆる要素をcomponentにする必要はありません。propsが大量に通過する、親がデータ整形とAPI通信と表示を全部持つなど、変更理由が混ざっていないか確認します。

最初の実装依頼では、ファイル変更より先にcomponent案とdata flowを提示させます。既存構成を読んだ結果、推奨案が既存patternと異なるなら、差と理由を説明させます。名前だけを変えた新しい抽象化や、似たcomponentの重複を増やさないよう、既存の一覧と検索してから作ります。

Stateは必要な場所にだけ持たせる

画面で変化する値を整理し、どのcomponentが所有するか決めます。入力欄の値、開閉状態、取得済みデータ、URL検索条件などは別の種類の状態です。複数componentが同じ値を使うなら共通の親へ移し、画面から計算できる値は重複してstateに保存しない方が保守しやすくなります。React公式Docsも、stateを構造化し、重複・冗長な状態を避けることを説明しています。

表は横にスクロールできます

情報	確認すること	よくある問題
入力値	誰が更新・検証するか	親子で別々に保持
取得データ	loading / error / stale	成功だけ実装
派生値	元stateから計算可能か	二重stateで不整合
URL条件	reload後に保つ必要があるか	UIだけ変わりURL不一致
一時表示	他componentと共有するか	不要にglobal化

サーバー由来のデータをどこへ置くか、キャッシュや再取得をどうするかはframeworkや既存libraryに依存します。AIに独自state管理を追加させる前に、projectに既存のquery clientやserver actionなどがないか確認します。

小さく動く完成条件を決める

変更を一つの完了条件へ分けます。例えば「検索条件が入力できる」「submitでURLが更新される」「結果0件を説明する」「再読み込み後も条件を復元する」のように、操作と期待結果を明記します。componentが増えるときも、最初に最小の表示を作り、data接続やエラー状態を後の差分として追加できます。

依頼例：

「既存のReactとTypeScript構成を維持。検索フォームにquery入力、submit、loading、0件、error表示を追加してください。既存routeとAPIを使い、新規依存・既存ファイルの一括置換・global state追加はしないでください。実装前に変更予定ファイルと各componentの責務を提示し、その後必要最小限の差分を作成。URL queryはreload後に復元できること。既存のlint、typecheck、該当testを実行し、変更した挙動と未確認事項を報告してください。」

この例もprojectの契約やデータ構造を規定するものではありません。AIが実際に読んだファイルと、変更するファイルを照らし、未読のAPI仕様を推測していないか確認します。

HooksとEffectを意図から選ぶ

Hooksはcomponentや他のHookのトップレベルで呼び出し、条件分岐やloop内で呼び出さないというルールがあります。useStateで状態を持つ、useContextでcontextを読む、useEffectで外部システムと同期するなど、用途に合わせます。値を計算するだけならeffectやstateを増やさずrender中に導出できる場合があります。

effectを追加する場合は、何と同期するのか、cleanupが必要か、依存値の変更時に何が再実行されるかを説明させます。データ取得をeffectで実装するのが既存構成に合うかは、frameworkやquery libraryの規則を優先します。React DocsのAPIは更新されるため、AIが古いpatternを提案したら現行の公式Referenceとproject依存versionを確認してください。

実装は差分ごとにレビューする

一度に複数画面、API、state管理、スタイルを変更すると、問題の原因を切り分けにくくなります。まずUI骨格、次に状態、次にデータ接続というように、各段階で差分を確認します。既存の命名、error処理、loading component、class名を再利用できるかを見て、AIが新しい共通layerを追加した理由を確認します。

diffを読む際は、不要な依存、未使用state、重複処理、危険なHTML挿入、console出力、テストデータの混入を確認します。フォームやURL入力からSQLやHTMLなどへ渡る値は適切に扱われているか、secretやtokenをclient codeに含めていないかも見ます。変更範囲が要求を超えていたら、コードを受け入れる前に不要差分を戻すよう頼みます。

UIの状態を動作ごとにテストする

componentの初期表示だけでなく、利用者の操作に対する結果を検証します。主要なケースは正常入力、空、無効な値、取得失敗、連続submit、遅延応答、キーボード操作です。テストは内部stateの実装に過度に依存せず、利用者から見えるrole、label、結果、messageを確認します。非同期更新があるときは、Reactのテスト方法と既存runnerに従い、更新完了後にassertします。

表は横にスクロールできます

状態	操作	期待する確認
初期	ページを開く	説明と操作が見える
loading	送信して待つ	多重操作を防ぎ状態を伝える
success	正常応答	結果が条件に一致
empty	0件応答	次に何を変えるか分かる
error	API失敗	再試行・問い合わせ先が分かる
keyboard	Tab / Enter	focusと操作が成立

testがpassしても、実ブラウザのresponsive、navigation、画像、consoleを確認します。テストが意図した失敗を検出できるか、assertionを一つ外したときに失敗するかも小さな例で確かめます。

AIの提案を採用する前に仕様へ戻る

コードが動くこと、見た目が一致すること、要件を満たすことは別々に評価します。PRやIssueの受け入れ条件、デザイン、データsourceをもう一度確認し、追加された要素に説明できない機能がないか見ます。AIに生成させたtestも、期待値が仕様に結びつくか確認します。正確な動作を示せない場合は「未確認」とし、経験談や動作済みのように報告しません。

AIものさしの判断

React開発でAIを使うなら、AIにcomponentや修正候補を作らせ、人間が責務、data flow、project rule、完成条件を管理します。小さなdiffをtypecheckやtestで確かめられる変更なら、工程を分けて任せられます。要件や既存APIが曖昧、stateの所有者が不明、影響範囲を説明できない場合は、実装を増やさず、その前提をprojectの担当者へ確認してください。

Typecheck・lint・browser確認を差分に結び付ける

差分ごとに、変更した責務に対応するtypecheck、lint、testを実行します。広いtest suiteを回す前に該当componentのケースを確認し、最後にproject全体の正式validationを行います。warningを黙って無効化したり、testをskipして通すのではなく、原因と未解決事項を報告します。画面を直接操作し、狭い画面、長い入力、空の一覧、遅い応答でlayoutと操作が崩れないことを見ます。必要なQAが実行できない場合は、その範囲を明確に残し、全件確認済みとは表現しません。