GitHub Copilotを半年間実務で使ってわかったこと

Last updated at 2026-03-16Posted at 2026-03-06

はじめに

半年間、GitHub Copilotを業務で使う案件に携わりました。

「AI補助ツールって結局どうなの？」という疑問を持つエンジニア、あるいはこれからAIを活用したい方に向けて、現場で感じたことをまとめます。

結論としては開発工程はますます短縮されていくと思います。重要なのはAIに的確な指示を出せる「インプット力」だと感じました。

GitHub Copilot とは

ざっくり説明すると、GitHub・Microsoft・OpenAIが共同開発したAIコーディング補助ツールです。エンジニアがコードを書いている最中に「次に書くべきコード」をリアルタイムで提案してくれます。

提案の精度が高い理由は、仕様書・コメント・既存コードから文脈を読み取る能力があるからです。単なるオートコンプリートではなく、文脈を理解した上で提案してきます。

2025年7月時点で累計ユーザーは2,000万人超、Fortune 100企業の90%が導入済みという状況です。

主な用途としては：

コード補完・生成
テストコードの自動生成
インフラ構成のコード化（Terraformなど）
エラー解析・コードレビュー支援
Agent Mode（Issueを渡すだけで自律的にPRを作成）

2025年の大進化

2025年はCopilotが大きく変わった年でした。

Agent Mode

2025年にAgent Modeが主要IDEで正式GAになりました。「このファイルのバグを直して」と言ったら、関連する複数ファイルを同時に編集して、ターミナルでテストを実行して、エラーが出たら自分で修正する——という一連の流れを自律的にやってくれるモードです。

VS Codeが最も早く4月GA、私が使っていたIntelliJ IDEA・Eclipse・XcodeはGA 2025年7月です。

Coding Agent & Agent HQ

2025年9月にはCoding AgentがGAになりました。GitHubのIssueを作って「Copilotに割り当てる」だけで、自律的にコードを書いてドラフトPRを作ってくれます。

さらに2025年10月にはAgent HQが登場。Copilot自身だけでなく、Claude CodeやOpenAI Codexなどのサードパーティエージェントも一元管理してオーケストレーションできる仕組みです。

マルチモデル対応とモデル選定の実体験

Claude Sonnet / GPT-4.1 / Gemini 2.5など複数モデルを切り替えて使えるようになっています。

私が実際に使っていた経験として、GPT系は早期にClaudeへ切り替えました。理由は以下の通りです：

日本語指示で全く関係ない箇所に修正が入る
複数箇所の修正が部分的にしか反映されない
修正内容が意図と大きく異なる

以降はClaude一択で使っていました。主に使っていたのはClaude Sonnet 4と4.5です。

実際に使ってみた：3つの活用場面

活用①：コード・テストコードの自動生成

仕様書を渡すと機能の実装、UTでは正常系・異常系のテストケースを網羅的に提案してくれます。JUnit 5 + Mockitoで手動で書けば数時間かかる作業が大幅に短縮されました。

効果的なプロンプト例：

テスト対象: UserService#createUser
仕様: メールが重複する場合は例外を投げる
JUnit5 + Mockito で正常系・異常系を網羅してください

注意点：1ファイルが肥大化すると精度が低下する

テストファイルの行数が3,000行を超えてくると、AIがファイル内容を正確に把握しきれず精度が落ちてきます。ファイル・機能単位でセッションを切り替えることで精度を高く維持できました。

また、「完璧です」「エラーを修正しました」という返答が出たときは要注意です。 実際には問題が残っていることがあります。このような返答が来たらセッションをリセットし、新規セッションに同一プロンプトで再投入するのが効果的でした。

活用②：インフラ構成のコード化

テスト工程に入ると、AWS上での環境準備が必要になる場面がありました。

VPC・Subnetなどの構成情報と、作成したいリソース（ECS Fargate、ALB、RDSなど）の概要を渡すと、Terraformスクリプトのたたき台を自動生成してくれます。

インフラのコード化（IaC）は、経験が浅いと取り掛かりのハードルが高い作業ですが、必要な情報さえ整理できれば、AIがベースを作ってくれます。あとはそれを人間が確認・修正するだけです。

「情報を整理して渡す」という工程が重要で、これがうまくできると、専門領域以外のコード生成も現実的になります。

活用③：エラー解決・コードレビュー支援

エラーが出たら、まずAIに投げる。

これが習慣になりました。以下のようなテンプレートでエラーメッセージと関連するコードを貼り付けるだけで、原因と修正案が即座に返ってきます。

エラー: [エラーメッセージをここに]
期待動作: [何をしたかったか]
実際の動作: [何が起きたか]
関連コード: [該当コード]
原因と修正方法を教えてください

コードレビューの場面でも活用しました。

Typo（変数名・コメントのスペルミス）の検出
ビジネスロジックの考慮漏れの指摘
コーディング規約・命名規則からの逸脱を指摘

人間のレビュアーへ依頼する前のセルフチェックとして使うと、レビューの質を上げながらレビュアーの負担も減らせます。

実体験：AIが教えてくれること・くれないこと

ZIPファイルアップロード機能を実装した際、ZIP爆弾・パストラバーサルの考慮をインプットに入れ忘れていた経験があります。AIが見落としたのではなく、人間のインプット設計の漏れでした。AIは渡された仕様の範囲でしか考えません。設計書にないセキュリティ要件は人間が追加する必要があります。

また他者コードのレビューでは、スレッドセーフでないAPIが「現行踏襲」として通っていたケースもAIが発見してくれました。

知識の深さがAI活用の質を決める

半年間の現場で実感したことがあります。AIを使いこなせるかどうかは、結局**「問いを立てる力」**に帰着します。

「知らない」には層がある

層	状態	問題
①	存在を知らない	そもそも使わない
②	触ったことはある	補完を受け入れるだけで「活用できている」と思っている
③	使えるが判断できない	どこに・何を渡すべきか分からない
④	使えるが検証できない	出力を鵜呑みにし、品質を担保できない

厄介なのは②③の人が「できている」と思っていることが多い点です。指摘されるまで気づきません。

経験8〜9年・資格保有者であっても、AIへの問いを設計する力が伴っていなければアウトプットは低品質のままです。AIは地力の差を消すのではなく増幅します。

知識の深さ × AIへの活かし方

レベル	状態	AIへの活かし方
Lv.1	存在を知っている	「Terraformで書いて」と頼める
Lv.2	概念を理解している	「ECS+ALBをモジュール分割で」と具体的に渡せる
Lv.3	設計を理解している	セキュリティグループ要件を判断・AIの出力不足を指摘できる
Lv.4	深く理解している	出力の正誤を自分で判断できる

Lv.1でも「入口」に立てます。ただし、Lv.3〜4がなければ「検証」ができません。浅い知識は使い始める理由、深い知識が品質を担保する力です。

ZIP爆弾の例で言えば、「ZIP爆弾という概念を知らなければ」AIへのインプットに含めることができません。知識がなければ「渡すべきことに気づけない」のです。

まず計画を立てさせる：仕様書→TODO化フロー

個人的に最も効果があったワークフローを紹介します。

いきなり実装させるのではなく、まずAIに計画を作らせることで、出力の方向性を人間がコントロールしやすくなりました。実装フェーズの手戻りが激減しました。

Step 1: 仕様書・設計書をAIに渡す
  ↓
Step 2: AIにTODOリスト・実装計画を生成させる
  ↓
Step 3: 経験・PJ方針・既存コードと照らして人間が修正
  ↓
Step 4: 修正済み計画を元に実装・テスト生成を依頼

実際のプロンプト例：

以下の設計書をもとに、実装手順を
TODOリスト形式で出力してください。
実装に必要な順序と依存関係も
明記してください。

[設計書・仕様をここに貼る]

このアプローチで得られたメリット：

AIの出力方向性を人間がコントロールできる
計画を見るだけで「インプットが不十分」と気づける
実装フェーズの手戻りが減る

使って気づいた注意点

⚠️ 仕様書の丸投げは期待外れになりやすい

最初は仕様書をそのまま貼り付けて「実装してください」とやってみましたが、反応がいまいちでした。

AIに限らずですが、インプットの質がアウトプットの質を左右します。最初に試してみて、反応が悪ければ伝え方を変える。この反復が大事です。

⚠️ セッションが長くなると精度が落ちる

同じセッションを長く続けていると、AIが文脈を抱えすぎて回答がぼやけてきます。

「あれ、さっきより精度落ちた？」と感じたら、それはセッションのリセットサインです。機能単位・ファイル単位でセッションを区切るのが効果的でした。

⚠️ AIに意思決定を丸投げしない

「この方法で進めていい？」

このような意思決定を任せること自体ナンセンスだと思います。AIは可能性を広げる道具であって、意思決定するのは人間です。

有効なプロンプトの工夫：「AとBの設計、それぞれのメリット・デメリット・想定される反論を教えて」という形で複数の選択肢を比較させると、人間側の意思決定が格段に楽になります。「どっちがいい？」と聞くのではなく、判断に必要な情報を引き出す問い方が良かったです。

⚠️ AIの「完璧です」を鵜呑みにしない

「エラーは取れました」「問題ありません」と自信満々に返してくるのに、実際にはエラーが残っていることがあります。特にエラー修正を繰り返した長いセッションで起きやすい印象です。

AIはユーザーが喜ぶ回答を優先する傾向があるため、出力は必ず自分で動作確認して検証することが大前提です。AIの言葉より、実行結果を信じましょう。

AIを道具として使いこなす鉄則

3S原則でインプットを磨く

Specific（具体的に）

曖昧な依頼を避け、具体的に指示する。

❌ RESTコントローラー作って
✅ Spring Boot 3.x, @Valid入力検証、
  DTO分離、@ControllerAdvice
  エラーハンドリング込みでCRUD

Small（小さく分割）

複雑な機能を小さなタスクに分割して依頼する。

❌ ユーザー管理機能を全部作って
✅ ①Entity → ②Repository
   → ③Service → ④Controller
   → ⑤テスト の順に分割

Show examples（例を示す）

入出力の具体例を示してAIを誘導する。

入力例: {"userId": 1}
期待出力例: {"id":1, "name":"Alice", "email":"..."}
このフォーマットで実装してください

copilot-instructions.md でチームの底上げ

リポジトリに.github/copilot-instructions.mdを置くと、Java/Spring Bootの規約をCopilotに覚えさせられます。

Java 21 + Spring Boot 3.xならコンストラクタインジェクション・DTO分離・JUnit 5 + Mockito・SLF4Jログ記法などのチーム規約を記載しておくだけで、全チームメンバーの出力品質が底上げされます。個人の努力ではなくチームの仕組みとして使えるのが強みです。

その他のコツ

余分な前置きを省く。 「あなたは優秀なJavaエンジニアです」のような役割設定、「よろしくお願いします」のような締め言葉——これらはコンテキストを消費するだけです。指示に直接必要な情報だけを入力する癖をつけましょう。

英語でのやり取りも有効。 日本語の方が文章量を少なくできるメリットはあります。ただしAIの学習データ量・トークン効率は英語が有利です。余裕があれば英語で試してみてください。

PDCAでAIを育てる

Plan → Do → Check → Act
（準備） （投げる） （精査） （改善）

Plan：copilot-instructions.mdで規約を定義し、3S原則でインプットを作り込む
Do：AIに投げる
Check：出力を人間がしっかり精査・検証する（セキュリティ・品質・仕様適合性）
Act：指示を改善して再投入。うまくいったプロンプトはチームで共有する

最初から完璧な出力を求めない。出力を見て指示を磨いていく。この反復を続けることで、AIから引き出せる品質が上がっていきます。

事例：Amazonで起きたバイブコーディング障害

「AIに書かせたコードはそのまま使っても問題ない」——この認識が現実に牙を剥いた事例があります。

2025年12月、AmazonのAIエージェント「Kiro」がバグ修正中に本番環境を自律削除・再構築し、中国リージョンで13時間の障害が発生しました。2026年3月にも大規模停止が起き、約630万件の注文喪失と推定される被害が出ました。

背景には複数の問題がありました：

AIエージェントにオペレーターレベルの権限を付与しながら本番変更のピアレビューが不在
1,500人以上の解雇後、残存エンジニアが人手不足をAIで補おうとする組織的圧力

これを受けてAmazonが導入した対策：ジュニア・中堅エンジニアがAI支援コードを本番デプロイする際にシニアエンジニアの承認を義務化。

さらにVeracode（2025年）の調査では、100以上のLLMをテストした結果、AI生成コードの45%にOWASP Top 10の脆弱性が含まれており、人間が書いたコードより2.74倍多いという結果が出ています。モデルを大きくしてもセキュリティは有意に改善しなかった（スケーリング問題ではなく構造的問題）とされています。

「AIが書いた＝正しい」ではなく、承認・検証のプロセスを設計することが不可欠です。

「AIに仕事が奪われる」は本当？

「AIが進化したらエンジニアは不要になる」という話をよく聞きます。

現場での実感は少し違います。

「AIに仕事が奪われる」のではなく、「AIを使いこなせるエンジニアが、そうでないエンジニアの作業を代替していく」。

価値のシフトも起きています。「コードをどれだけ書けるか」から、「仕様・設計を整理してAIに渡せるか」へ。SIer/SES業界では人月ビジネスモデルの変容が中長期的に不可避です。「AIに正しく指示できる人材」の希少性が高まっており、今行動する人が先行者優位を持てる時代です。

まとめ：これからAIを触るエンジニアへ

まずFree版で試してみる

クレカ不要・補完2,000回/月。個人のアウトプット量を増やせる環境はすでに整っています。使ってみないことには何も始まりません。

システム全体を広く理解する

フロント・バックエンド・DB・インフラを俯瞰して理解していると、AIへの指示の精度が大幅に上がります。知識の深さがそのまま活用の質を決めます。

インプット力を磨く（3S原則）

コードをどれだけ知っているかより、仕様や設計を整理してAIに渡せる状態を作れるかが全てです。

PDCAでAIを育てる

丸投げではなく、反復しながら指示を最適化していく。AIとの付き合い方は人間に物を作ってもらうのと同じ感覚です。

SES現場では書面承認を必ず取る

顧客コードをAIに入力する行為はNDA上の「第三者への開示」に該当する可能性があります。Business版（IDEゼロデータ保持）を使い、かつ顧客からの書面での承認を得ることが前提です。

AIを活用できるエンジニアとそうでないエンジニアの差は、これからの時代に確実に広がっていきます。

AIを活用しようとしているエンジニアの参考に少しでもなれば幸いです。

参考情報

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up