AIにコードを任せる進め方｜設計・実装・レビューの分担を決める

結論から言うと、AIにコードを任せる範囲は「設計は人、実装は任せやすい、レビューは必ず人」という分担が現実的です。設計をAIに丸投げして後から修正に時間がかかった経験が私にもあるので、最初から役割を決めておいたほうがいいと思います。

結論

設計はAIに丸投げしない

設計フェーズでAIを使うなら、「叩き台を出させて人が判断する」用途に限るのが安全です。

AIが提案するアーキテクチャや設計案は、既存コードの文脈を知らない状態で書かれます。プロジェクト固有の規約、選んでいるフレームワークのバージョン、チームの暗黙のルールは、明示的に渡さない限り反映されません。

実際に設計をほぼAIに任せたとき、提案されたディレクトリ構成が既存の規約と合わなくて、実装が進んでからリファクタリングが必要になったことがあります。最初から「この構成を前提にして」と文脈を渡していればよかったです。

設計で人が判断すべき点は次の通りです。

• どのコンポーネントに何の責任を持たせるか
• 既存の命名規則・ディレクトリ構成との整合性
• スケールしたときに問題になりそうな箇所
• セキュリティ要件・データの持ち方

この判断をAIに委ねてしまうと、後で気づいて直す時間のほうが節約した時間より長くなることがあります。

実装に渡すべき文脈4つ

実装フェーズはAIに任せやすい工程ですが、渡す文脈の質で出力の質が変わります。

文脈の種類	渡す内容
コードの規約	コメントの書き方・変数名の規則・関数の粒度
依存関係	使っているライブラリ・フレームワークのバージョン
テストの有無	テストを書く前提か・どのテストフレームワークを使うか
エラー処理の方針	例外をどう扱うか・ログをどこに書くか

これらをコメントや仕様として渡してから実装を頼むと、後から直す箇所が減ります。

私が今使っているパターンは、実装依頼の冒頭に「既存のこのファイルと同じ書き方で実装して」と類似コードを貼ることです。ゼロから説明するより、サンプルを渡すほうが意図が伝わりやすいです。

事故りやすい処理の種類

AIが生成したコードをそのまま使うとリスクが高い処理があります。次のものは必ず重点的に確認してください。

認証・権限まわり
- セッション管理の実装
- トークンの有効期限・検証
- アクセス制御の抜け漏れ

課金・決済まわり
- 金額計算のロジック
- 二重処理・重複チャージの防止
- 外部決済APIのエラーハンドリング

削除処理
- 論理削除・物理削除の区別
- 関連データのカスケード削除
- 削除のロールバック可否

外部API連携
- レート制限の扱い
- タイムアウト・リトライの設計
- APIキーや認証情報の扱い方

これらの処理でバグが出ると、単に機能が壊れるだけでなく、ユーザーデータの損失や金銭的な誤りにつながります。AIが出した実装を読むとき、正常系だけでなくエラーケースを先に見るようにしています。

レビューで人が確認すべきポイント

AIが実装したコードのレビューは、通常のコードレビューより意識すべき点が追加されます。

コードが何をしているかを読む
AIが書いたコードは、変数名が整っていてコメントもあるように見えても、処理の意図が本来の仕様と合っていないことがあります。「きれいに見える」「動いている」で終わらせず、処理の流れを読むことが必要です。

エラー処理が抜けていないか確認する
AIは正常系の実装は得意ですが、エラー処理を省略したり浅くしたりすることがあります。例外はどこで拾っているか、予期しない入力に対してどう動くかを確認してください。

外部依存の扱いを確認する
AIが提案するライブラリが古いバージョンを参照していたり、実際のプロジェクトでは別のものを使っている場合があります。importやrequireの内容も確認してください。

AIコーディングツールの使い分け

現在よく使われているAIコーディングツールには、IDEに統合するタイプと、チャットと合わせて使うタイプがあります。

GitHubCopilotはエディタ内で補完として動くため、既に慣れているエディタを変えずに使えます。Cursorはエディタ自体がAI機能を含んでいて、コードベース全体を参照しながら指示できる場面があります。

どちらが向いているかは使っているエディタや作業スタイルによって変わります。利用できるプランや価格は変動するため、公式のプラン説明で最新情報を確認してください。両方に無料・試用の枠があるなら、まず自分の実際の作業で試してから継続するかを判断するのが確実です。

私はGitHubCopilotを先に使い始めましたが、既存コードを大量に読ませてから実装させたい場面ではCursorのほうが扱いやすいと感じています。一方で、小さな補完や定型コードの自動入力はGitHubCopilotのほうが摩擦が少ないです。どちらが「絶対に優れている」というより、作業の種類で使い分けが出てくるのが実態です。

引き継ぎとドキュメントの扱い

AIを使って実装した箇所は、人が書いたコードと同様にドキュメントを残す必要があります。「AIが書いたから動けばいい」という扱いは後で困ります。

特に意識するのは次の点です。

• なぜそのアーキテクチャを選んだか（AIが提案しても、採用した理由は人が持つ）
• 類似処理を別の場所でも実装するときの参考コードを明記する
• 意図的にエラーを無視している箇所はコメントで理由を書く

AIが書いたコードは可読性が高い場合もありますが、判断の経緯が記録されていないことが多いです。引き継ぎのときに「なぜこう書いてあるのか分からない」が増えないよう、実装の意図はコメントで残す習慣は変わらず必要です。

キャリアとしてAIコーディングをどう活かすか

AIツールが実装の多くをこなすようになっても、設計の判断・レビューの責任・要件の解釈はエンジニアの仕事として残ります。AIを使いこなせるエンジニアの需要は増えていますが、それはAIの出力を無批判に使える人ではなく、出力の品質を判断できる人です。

スキルを積んで副業や転職も視野に入れているエンジニアなら、こうした現場経験は市場価値につながります。

私の使い方

AIコーディングツールを使い始めて変わったのは、実装の速さと、レビューに使う集中力の向け先です。ボイラープレートや定型処理は任せて、設計の判断とレビューに時間を使うようになりました。

事故を減らすための鉄則は2つです。「認証・課金・削除は先に確認する」と「エラーケースを正常系より先に見る」。この2点を守っていれば、AIコーディングは実務で使える武器になります。