AIで開発を効率化する方法｜作業の切り分け・依頼・修正・引き継ぎの実践手順
AIにコードを書いてもらったものの、修正を繰り返すうちに時間がかかってしまう。機能は増えたけれど、何が変わったのか分からなくなる。AIを開発に取り入れると、こうした悩みに直面することがあります。
開発の効率化では、コードが出てくる速さだけでなく、依頼・確認・修正まで含めた作業全体を見ます。この記事では、AIに任せる作業の切り分け方から、情報の渡し方、うまく進まないときの立て直し方までを具体的に紹介します。
目次
１．AI開発の効率は「完成までの手間」で考える
AIが短時間でコードを生成しても、その内容を理解するために長時間かかったり、不要な変更を戻したりしていれば、作業全体が短くなったとは限りません。生成時間と、使える状態にするまでの時間を分けて考えましょう。
特に既存のアプリでは、追加した機能だけでなく、元からある機能との関係を確認する必要があります。効率を見直すときは、次のように工程を分けると、時間がかかっている場所を捉えやすくなります。
| 工程 | 含まれる作業 | 見直すポイント |
|---|---|---|
| 依頼準備 | 仕様や関連コードを整理する | 毎回同じ説明を作り直していないか |
| 生成・実装 | AIの提案を受け取り、変更する | 一度に扱う範囲が広すぎないか |
| 確認 | 差分を読み、動作やテスト結果を確かめる | 何を確認すればよいか明確か |
| 修正 | 誤りや仕様との違いを直す | 原因を調べず修正を繰り返していないか |
| 引き継ぎ | 決定事項や未完了の作業を残す | 次回も同じ調査から始めていないか |
目指すのは、生成するコード量を増やすことではありません。必要な機能を、理解・確認・保守できる形で完成させることです。
２．AIに任せる作業は、確認できる大きさに分ける
最初から「予約アプリを全部作って」と依頼すると、画面、データ保存、認証、通知などの変更が一度に発生します。問題が起きたときに原因を絞りにくく、提案が目的に合っているかの確認も難しくなります。
そこで、一つの依頼で何を変え、何を確認するかが分かる単位に切り分けます。単にファイルや行数で分けるのではなく、一つの動作として確かめられるまとまりを意識しましょう。
例：予約フォームを段階的に作る
次の表は、学習用の予約フォームを作る場合の進め方の例です。実際に予約を受け付ける前には、重複予約、権限、個人情報の扱いなど、用途に応じた確認も必要になります。
| 段階 | 今回作るもの | 確認すること |
|---|---|---|
| １．入力画面 | 日付・時間帯を選ぶ画面 | 必要な項目があり、操作できるか |
| ２．入力確認 | 必須項目や入力条件の確認 | 未入力・不正な値を適切に扱うか |
| ３．仮の受付処理 | テストデータで結果を返す処理 | 成功・失敗の表示を確認できるか |
| ４．保存処理 | 検証環境でのデータ保存 | 保存内容と失敗時の動作が正しいか |
| ５．公開に向けた確認 | 実際の運用条件への対応 | 権限、同時操作、復旧方法などを確認できるか |
小さく分けることは、未完成の状態で公開することではありません。開発中の確認単位を小さくし、必要な条件が揃ってから公開するための進め方です。
３．依頼前に、共通情報と今回の変更を分ける
AIに渡す情報には、毎回変わらないものと、今回だけ必要なものがあります。これらを分けておくと、依頼のたびに説明を書き直す手間を減らせます。
共通情報には、使用する言語・バージョン、フォルダ構成、実行方法、既存の設計方針などをまとめます。一方、今回の依頼には、変更したい動作、関連ファイル、完了条件を記載します。
| 情報の種類 | 記載する内容 |
|---|---|
| プロジェクトの共通情報 | 目的、技術構成、起動方法、確認コマンド |
| 既存のルール | 命名、配置場所、再利用する関数や部品 |
| 今回の目的 | 誰の、どの困りごとを解決するか |
| 変更範囲 | 関係する画面・処理・ファイル |
| 完了条件 | どの操作で、どの結果になればよいか |
GitHub Copilotなどには、プロジェクト共通の指示をファイルで渡す仕組みがあります。ただし、対応する機能や読み込み方はツールによって異なります。用意した文書が実際に参照される設定になっているかも確認してください。
また、コードやログを渡す際は、利用してよいサービスと入力できる情報の範囲を確認します。APIキーや実際の顧客情報を含めず、調査に必要な構造を残したテストデータへ置き換えましょう。
最初の依頼に使えるテンプレート
テンプレートの項目を埋めること自体が目的ではありません。小さな修正なら短くまとめ、大きな変更なら具体例を追加するなど、必要な情報量に調整してください。
AIへの指示をもう少し具体的に整えたい方へ。目的・条件・出力形式を整理し、修正とテストにつなげるプロンプト設計を紹介しています。
AI開発のプロンプト設計｜指示の作り方・修正手順・テストの進め方 記事を読む →４．修正が続くときは、コードを増やす前に状況を整理する
期待どおりに動かないとき、「まだ直りません」とだけ伝えると、AIは不足している情報を推測して別の修正を提案することがあります。変更を重ねるほど、元の問題と新しく発生した問題を区別しにくくなります。
まずは、期待する動作・実際の動作・再現手順を揃えてください。エラーが出ている場合は、秘密情報を除いたメッセージと、どの操作で発生したかを添えます。
原因の候補と、確かめる方法を先に整理する
例えば「次へボタンを押しても画面が変わらない」場合、クリック処理が動いていないのか、状態は更新されているが表示に反映されていないのかで、修正箇所が変わります。
この段階では、複数の場所を一度に書き換えるより、イベントが呼ばれるか、値が変わるか、エラーが出ているかを順に調べます。AIには、原因の断定だけでなく、候補を確認する方法も求めましょう。
一度動いていた状態があるなら、その版との差分も確認します。変更を戻す場合は、必要な作業まで失わないよう、対象の差分を把握してから行ってください。
５．会話を続けるだけでなく、決定事項を残す
長い会話には、採用しなかった案や、すでに変更した仕様も残ります。そのまま依頼を続けると、現在の前提と過去の案が混ざることがあります。
区切りのよいところで、採用した仕様、現在の状態、未解決の問題を短くまとめましょう。新しい会話へ移る場合も、最新のコードとこの記録を使うと、引き継ぐ情報を整理できます。
| 残す情報 | 記載例 |
|---|---|
| 採用した仕様 | 未回答の状態では次の問題へ進めない |
| 実装済みの範囲 | 表示・回答判定・解説の表示まで実装済み |
| 確認したこと | テストした条件と、その結果 |
| 未確認事項 | スマートフォンでの表示は未確認 |
| 次の作業 | 問題切り替え時の状態初期化を確認する |
記録は、AIの説明だけで確定せず、コードや実行結果と照合します。「実装済み」と「動作確認済み」を分けることも、引き継ぎの誤解を減らすために大切です。
６．チームでは、担当と変更する場所を揃える
複数人がAIを使って開発すると、同じファイルへの変更や、別々の前提で作られた機能が衝突する場合があります。AIの導入に合わせて、担当範囲と機能同士の受け渡しも確認しましょう。
例えば、画面担当とAPI担当が別なら、項目名、入力形式、成功時と失敗時の応答を先に揃えます。双方のAIに異なる仕様を渡してしまうと、それぞれ単体では動いても、連携できないことがあります。
- 仕様：共通して参照する最新版を決める。
- 担当：誰がどの機能やファイルを変更するかを共有する。
- 受け渡し：データ形式やエラーの扱いを合わせる。
- 変更共有：仕様を変えたら、関係する担当者へ伝える。
- 統合確認：各部分の確認に加えて、組み合わせた動作も確かめる。
共通の指示文を作っても、それだけで全員の作業が一致するわけではありません。実際の変更と、共有している仕様がずれていないかを確認する工程が必要です。
７．効率化の効果は、品質と一緒に記録する
AIを使った効果を確かめるなら、「速く感じた」という感想に加えて、作業時間と手戻りを記録します。最初から細かい測定を行わなくても、依頼準備・確認・修正のどこに時間がかかったかが分かれば、改善の材料になります。
| 記録する項目 | 見るポイント |
|---|---|
| 完了までの作業時間 | 生成だけでなく、準備・確認・修正を含める |
| 修正の往復 | 仕様不足、実装ミス、環境の違いなど、理由を分ける |
| 変更範囲 | 依頼に関係しない変更が増えていないか |
| 確認結果 | 必要な動作と既存機能を確認できたか |
| 後日の修正 | 公開後や引き継ぎ後に、追加の問題が生じていないか |
異なる難しさの作業を比べて、「AIで何倍速くなった」と結論づけるのは適切ではありません。同じ種類・近い規模の作業を複数記録し、担当者の経験や既存コードへの慣れなどの違いも考慮します。
生成時間が短くなっても、確認や手戻りが増えているなら、依頼範囲や渡す情報を見直す余地があります。逆に、共通情報を整えることで準備時間が減った場合は、その仕組みを次の作業にも活用できます。
作業を速く進めることに加えて、どの確認を行ってから採用・公開するかも整理しましょう。変更の影響に合わせたチェック体制を解説しています。
AI開発の役割分担とチェック体制｜人の確認・自動テスト・公開判断の進め方 記事を読む →８．AIとの共同開発でよくある質問
最初に何をAIへ任せればよいですか？
入出力と確認方法が分かる、小さな作業から始めてください。例えば、既存関数の説明、再現手順の整理、条件が決まった表示処理の変更などです。作業の小ささだけでなく、結果を自分で確認できることが重要です。
AIの提案が毎回違う場合は、どうすればよいですか？
同じ目的でも複数の実装方法があるため、提案が異なること自体は不具合ではありません。既存の設計、変更範囲、保守のしやすさなど、採用基準を決めて比較しましょう。新しい案が出るたびに全面的に置き換える必要はありません。
古いシステムの調査にも使えますか？
処理の説明や依存関係の候補整理に利用できます。ただし、実際に使っている言語・ライブラリのバージョンを伝え、現在の動作と照合してください。新しい書き方へ置き換える前に、維持すべき仕様や互換性を確認する必要があります。
AIを使うと、プログラミングを学ぶ必要はなくなりますか？
AIがコードを作成しても、入力・処理・出力や、エラーの意味を理解することは、確認と修正に役立ちます。提案を読んで動作を予想し、実行結果と比較するなど、開発と学習を組み合わせてください。
９．次の１件で、依頼と確認の流れを整える
AIとの開発を効率化するには、目的を明確にし、確認できる大きさで依頼し、結果と未完了の作業を残すことが大切です。コードを速く生成するだけでなく、迷いや手戻りを減らす進め方を整えましょう。
まずは次の修正で、「今回変えること」「完了条件」「実際に確認したこと」を短く記録してみてください。その記録を見直すことで、自分やチームにとって、どの作業にAIを使うと進めやすいかを判断できます。
参考資料
- Google Engineering Practices：Small CLs — 変更を小さく、まとまりのある単位にする考え方。
- GitHub：Best practices for using GitHub Copilot — 作業の分割、具体的な指示、提案の確認。
- GitHub：Adding repository custom instructions — プロジェクトの情報や共通指示を渡す方法。
Learning Tools
記事を検索したい方はここから！
記事を検索
関連記事や、今の内容に近いテーマをすぐに検索できます。
例: AI / 情報Ⅰ / Python / 統計 / 資格 / 学習法