はじめに
「AIペアプログラミング」に本格的に取り組んでから半年ほどが経ちました。人間だけで開発していた頃と比べ、その進め方は大きく変わっています。さまざまな意見がある中、私は体感で工数を1/3まで削減できたと感じています。
今回は、どのように開発手法が変わったのか、具体的な作業フローを交えながらご紹介します。
開発の主戦場と利用ツール
現在、主に担当しているのは仕様書作成とAPI開発ですが、フロントエンドの修正も行っています。モバイルアプリ開発（iOS/Android）は対象外です。
AIツールは、当初Clineを利用していましたが、タスクによっては参照ファイルが多すぎたり、タスク自体が長くなりすぎたりしたため異常停止することが多発していました。
そこで現在は、GithubCopilotのAgentモードをClaude Sonnet 4と組み合わせて利用しており、現時点では最適な選択肢だと感じています。些細な点に思えるかもしれませんが、アクティブなファイルを自動で優先参照してくれるため、タスクごとにファイルパスを指定する手間が省け、長期的な目で見ると大きな効率化につながっています。
作業フロー
ここでは、Copilotにスムーズに作業してもらうために、私が実践している5つのステップをご紹介します。大切なのは、「AIに全部任せる」のではなく、「AIが最高のパフォーマンスを発揮するためのレールを人間が敷く」という意識です。
1. 実装内容の簡易仕様書を作成する 2. copilotに作業計画を練ってもらう 3. 作業計画をレビューする 4. copilotに実装作業開始してもらう 5. 実装結果をレビューし、動作検証する 6. 作業ガイドラインを更新する
簡易仕様書作成：AIへの的確な指示を出す
AIとの開発を始めたばかりの頃は、「〇〇してもらえる？」といった一行テキストで依頼していました。簡単な作業であればそれでも問題ありませんが、少しでも複雑になると、指示が曖昧な分、作業結果が意図とずれてしまうことが多々ありました。その結果、追加のやり取りが増えたり、「もう自分で直した方が早い」と手動修正が入り、かえって工数が膨らんでしまうことも。
これを防ぐため、必ず作業用フォルダやリポジトリ上のdocumentフォルダなど、Copilotが参照しやすい位置に、md形式で簡易仕様書を作成するようにしました。これまでプロジェクトごとに異なっていた仕様書のフォーマットを統一することで、AIへの指示出しが格段にスムーズになりました。
作業計画のレビュー：まずは全体像を確認する
いきなり実装を始めるのではなく、まずは簡易仕様書をCopilotに確認してもらい、実装計画を提案してもらいます。そして、人間側で以下の点をレビューします。
-
今回の実装で最も重要なポイントを正しく理解しているか
-
不要なタスクが含まれていないか
-
タスクの粒度は適切か（細かすぎないか、大きすぎないか）
問題がなければ、確定した実装計画書をワークスペース上に作成してもらいます。これにより、実装が進むにつれてチャットが膨らんでも、計画書を見返しながらAIの作業を観察でき、計画から外れていないかをチェックしやすくなります。
実装開始：AIの作業を観察する
計画の確認が完了したら、いよいよ実装開始です。Copilotに実装計画書のフェーズ1から順番に作業してもらいます。
このとき、Copilotに任せきりにするのではなく、私は作業内容をリアルタイムで観察するようにしています。なぜなら、特定の作業で無限ループに陥ってしまったり、関係ない部分を修正してしまったりすることがあるからです。予定外の作業に着手している場合は、不要なコードが追加される前にすぐにストップさせ、軌道修正を行います。
実装結果のレビュー：ハルシネーションを見抜く
各ファイルの修正差分を、1行1行丁寧に確認します。ファイル数や行数が多いとついチェックをスキップしたくなりますが、ハルシネーション（AIが事実ではない情報を生成すること）は思わぬ箇所で発生することがあるため、この細かなチェックは必須です。
ガイドライン更新：AIを“育てる”プロセス
実装が完了したところで、このフローは終わりません。最後に、これまでのレビューで発生した指摘事項を、Copilotが参照するinstructions.mdに追記するよう依頼します。
これは、AIをプロジェクトのルールに最適化させるための重要なステップです。たとえば、最近発生した指摘には以下のようなものがありました。
- 「API実装時に利用できる共通関数は〇〇のフォルダにあるため、実装時は該当フォルダ配下の関数を利用できないか確認してください。」
- 「テーブル定義書は〇〇フォルダ配下にあるため、SQL操作を実装する際は実在するカラムを利用してください。利用想定のカラムがない場合は相談してください。」
実在しないカラムを参照しようとしたことが複数回発生したため、このようなガイドラインを追加しました。よくある指摘事項をルールとして明文化し、AIに学習させることで、次回以降の依頼時に同様のミスを減らすことが狙いです。
余談ですが、息抜きに関西弁で回答するようにルールを追加すると、フランクな雰囲気でコミュニケーションが取れるのでおすすめです。（たまにいらっとすることもありますが！）
最後に
今回の一連のフローを通して重要だと感じたのは、実装の前後の「準備と振り返り」です。
2025年現在、AIのコーディングスキルは、まだビジネスロジックまで最適解を提示できるシニアエンジニアのレベルには達していません。そのため、AIに任せっぱなしにするのではなく、依頼者である人間が責任を持ってレビューする姿勢が不可欠です。
しかし、過度なマイクロマネジメントは「それなら自分で書いた方が早い」という本末転倒な状況を招きかねません。AIが想像した期待値に沿うように、依頼者側が仕様書やガイドラインといった「レール」を敷いて、AIとの認識のずれを最小限に抑えることこそが、AI活用を成功させる鍵だと感じています。
このフローは常にベストであるとは限りません。AIモデルのアップデートに伴い、私たち自身の開発フローも見直していくことが重要です。
最後に、スパイダープラスでは仲間を募集中です。スパイダープラスにちょっと興味が出てきたなという方がいらっしゃったらお気軽にご連絡ください。最後までご覧いただき、ありがとうございます。
