はじめに
これまでの連載（第１回、第２回）では、AIと協働して開発を進める意義や、伝わるプロンプトのコツを紹介してきました。
第3回となる今回は、「実際にAIにコードを書かせる・修正させる」際に押さえておきたい現場のテクニックや工夫について、実体験とともにまとめます。
※本文中のスクリプトやGitHub Copilotの回答は実際の開発時のものを抜粋して記載していますが、このまま書いても同じ回答が得られるとは限りません。ご了承ください。
※[開発者]はWebアプリの開発経験は豊富ですが、Flutterによるモバイルアプリ開発は初めての開発者です。
※本連載はAI利用の実体験にフォーカスしているため、Flutterなど技術的な詳細説明は省略しています。
1ファイルの分量は短く、小さく
（このファイルのここだけ修正したいけど、300行超えていてAIの提案が途中で途切れる…）
- AIにコード生成や修正を依頼するときは、1ファイルの分量をなるべく短く・小さく保つようにしています。
- コードを分割（画面系のファイルは難しいかもしれませんが、なるべく300行くらいまでを目標に）することで可読性や再利用性も高まるため、適宜AIと一緒にリファクタリングを実施しました。
- ファイルが長すぎる場合、AIが全体を正しく認識できなかったり、回答が途中で途切れてしまうことがあります。
100〜200行程度の粒度で依頼内容を絞ることで、AIの精度が上がると感じました。
- 関数やクラス単位で分割するリファクタリングについても、AIに相談しながら進めるとスムーズです。
新規機能追加はAI生成コード→人間が必ずレビュー
（次は、、アカウント画面だな。データモデルは作成済みだから、データ操作用のサービスをお願いするか。）
アカウントデータのデータ操作用のサービスを作成してください。
コーディングガイドラインに則り、ファイル名の命名もお願いします。
また、先ほど作成したデータモデルを参考にしてください。
1. ファイル名
--- ファイルパスを含めたファイル名の提示 ---
2. コード案（例）
--- コード案の提供 ---
3. ポイント
--- コード案の説明 ---
4. まとめ
--- 回答に対するまとめ ---
（基本的なつくりはOK。データモデルもきちんと考慮されている。でも、エラー処理がガイドラインに沿ってない。エラー処理だけ修正してもらって、とりあえず適用させちゃおう。）
以下のエラー処理ガイドラインに則って、ファイルの見直しをお願いします。
--- エラー処理ガイドラインのコピペ ---
1. 修正案の例
--- 修正したコード案の提供 ---
2. 主な変更点
--- コード案の説明 ---
3. まとめ
--- 回答に対するまとめ ---
（大丈夫そうだ。とりあえずファイルに適用して次の工程に行こう。）
- 新しい機能を追加するときは、AIが生成したコードをそのまま使うのではなく、必ず開発者がレビューしてから採用するようにしています。
- AIが生成したコードは、あくまで“精度の高いたたき台”です。ロジックの誤りや既存仕様との食い違い、冗長な実装が混じることもあるため、必ず人間の目で確認し、UI仕様、クラス設計などもレビューするようにしています。
- また、「なぜこの処理なのか？」をAIに再度質問することで、理解が深まる場面も多いです。
既存機能修正はAI提案→人間が手直し→AI再レビュー
Firebaseの初期化コードの追加
修正案の例（main.dart):
Future<void> main() async {
widgetsFlutterBinding.emsureInitialized();
// Firebaseを初期化
try {
await Firebase.initializeApp {
options: ......
（ふむふむ、、Firebaseを使うには、まずは初期化ね。。提案内容のソースコード、あ、きちんとtry-catchが入っているな。とりあえず、「エディターで適用します」をクリックして、差分を確認して、念のために。）
提案してくれたソースコードを元に修正したので、コードレビューをお願いします。
1. 確認観点
--- 修正したソースコードのコードレビュー観点の提示 ---
2. 確認結果
--- 各観点、コードの詳細をピックアップしつつレビュー結果の提示 ---
3. まとめ
--- 結果、問題ないまたは、修正点を提示 ---
既存の機能修正では、AIの提案をそのまま適用せず、一度開発者が手を入れてから再度AIにレビューを依頼するようにしています。
AI→人間→AIのサイクルで修正を進めることで、品質を担保しやすくなります。修正の意図や背景をAIに説明することで、より的確なフィードバックが得られると感じます。副作用や仕様漏れにも気付きやすくなります。
複数AIエンジンでのクロスレビューも有効
（Copilotの提案どおり修正したけど、実装内容が複雑なので、念のためGeminiにAIエンジンを変更して同じ内容をレビュー依頼。っと。）
この修正で見落としや問題点はありませんか？
GPT系からGemini系へ変更
--- 異なる観点での指摘・追加改善案の提示 ---
Copilotだけでなく、GeminiやClaudeなど他のAIエンジンにも同じ修正案を見せてレビューを依頼することもあります。
AIエンジンによって回答の言い回しにも変化があり、性格が隠れ見えてきて興味深いです。
複数のAIエンジンでレビューすることで、ヒューマンレビューでは見落としがちな観点も補えると感じています。AIごとに違う視点で指摘されることもあり、なぜ回答が違うのかを検証することで、よりよい方針を採用できます。
AIの提案は“すべて正しいわけではない”が、まず信じて進めることで爆速化
（ちょっと怪しいけど、とりあえずAIの提案を適用してみよう。動かしてみて問題があれば、その都度直せばいいや。）
AIの提案は必ずしも正しいとは限りませんが、まずは「信じてそのまま動かしてみる」ことで開発スピードが大きく向上しました。
迷ったらまずAIの提案を仮実装して動作を確認し、問題があれば人間や再度AIで修正するようにしています。完璧を目指して長く吟味するよりも、まず手を動かしてみることで効率的に開発が進みます。テストや動作確認もAIと協力して進めると、さらに効果が上がります。
サンプルコードや公式文書のコピペ活用で精度UP
（なかなか、動くソースコードの提案が出てこないなぁ。Flutter公式ドキュメントを見てみるか……う、長い。とりあえず公式のサンプルをコピペして、AIに丸投げしてみよう。）
--- Flutter公式ドキュメントサンプルのコピペ ---
Flutter公式ドキュメントにサンプルがありました。上記を参考にして、ソースコードを見直してください。
重要な情報ありがとうございます。Flutter公式ドキュメントの記載内容を参考にファイルを修正しました。
--- 動作可能なソースコード ---
- AIに指示を出す際、公式ドキュメントの記述やサンプルコードをそのままチャットにコピペして説明材料とすることで、AIの提案の精度が大きく向上しました。
- 公式ドキュメントやサンプルのコードを直接AIに渡すことで、誤解なく正しいパターンを適用できるようになります。具体的な例を示して「このコードをベースに改修したい」と伝えることで、AIの提案も的確でスピーディになります。
おわりに
今回は、AIにコードを書かせる・直すときの現場テクニックや工夫について紹介しました。
モバイルアプリ開発のように、ライブラリが次々と進化する分野では、AIが提供する情報が古くなっていることも少なくありません。
AIを一緒に開発を進めるチームメンバーの一員と考えることで、お互いの強みを活かし合えるのではないでしょうか。
最後までお読みいただきありがとうございました。
次回は、AIを活用した障害対応・品質改善の工夫や、「人間が最後の砦」となるポイントについて掘り下げていきます。
※本記事は当社による2025年のモバイルアプリ開発実体験を元に記載しています。日々、GitHub CopilotおよびAIエンジンは進化しているため、最新の状況とは異なる場合もあります。もっと良い活用方法があるかもしれませんが、あくまで一つの事例としてお読みいただけますと幸いです。
TravelPassportアプリは以下からダウンロードできます。
