GitHub Copilotの活用事例

副業で受けた開発案件に時間がかかりすぎ、報酬に対して実質の時給が下がっていた。

ツールを1つに絞ると得意でない工程で手が止まる。

1. 案件を4タイプに分けて使うツールを先に決める
2. 既存コードの修正はGitHub Copilotの補完提案をそのまま試す
3. 小規模サイトはCursorで骨組みだけ手書きし残りを生成させる
4. 中規模アプリはClaudeに画面構成とAPI設計とDB設計を出させる
5. 要望があいまいな案件はClaudeで機能候補と優先順位を整理する

ポートフォリオサイト制作は8時間で終わり、所要時間が60%削減された。

中規模アプリ開発は約120時間で、所要時間が40%削減された。

電子請求書発行システム「楽楽明細」の新オプションを、実装に使える期間が1か月弱という条件で12機能ぶん作る必要があった。

要求仕様書は例外系や受け入れ条件が足りず、そのままAIに渡せる粒度ではなかった。

1. 決めた仕様をClaudeでプロトタイプ化し40社に見せて機能を約30%削った
2. 要件をEARS形式で1アクション単位に分け例外パスも書いた
3. kiro（cc-sdd）でspec化しエージェントに読ませた
4. Codexを主軸にgit worktreeで機能ごとに複数セッションを同時に走らせた
5. 一次レビューをGitHub CopilotとClaude Codeで出し人が二次で確認した

4月7日の開発決定から5月末リリースと実質2か月未満で出せた一方、12機能を1本のプルリクにまとめたため変更ファイルは700超、サーバーサイドのレビューは全量確認に5営業日かかった。

実装方針を決めきらなかったため同じ指摘を機能の数だけ受けた。

VS Codeを更新するたびに出るRelease Notesは分量が多く英語のため、読まずに閉じていた。

新機能や変更点を知りたいのに手が出しにくかった。

1. 使用中のVS Codeのバージョンに合う公式Release Notesを取得する
2. 原文をLanguage Model APIに渡し日本語の要約を作らせる
3. 要約をまず知っておきたい変更・便利になったところ・必要な人だけ・3行まとめに分けて表示する
4. バージョン更新時に要約作成を通知しコマンドパレットからも呼び出せるようにする
5. 気になった項目は公式のSourceリンクから原文を読む形にし全文翻訳はやめる

拡張機能Release Digest for Visual Studio Codeを作り、MIT LicenseのOSSとしてGitHubにソースごと公開した。

専用のAPIキーは不要で、拡張機能自体は無料で使える。

長い設計書やソースコードをそのままAIに読ませると読み込む量が増え、場所を探すのにも時間がかかっていた。

人間向けの形式のままではエージェントの動きが遅くなる。

1. 設計知識をobjectiveやconceptなど8種類に分ける
2. 1ファイル2〜3ページの小さなYAML文書として貯める
3. ファイル間の行き来をjsonl形式のインデックスでたどる
4. 会話や要件のmarkdownを先に知識へ分解しコードを書かせる
5. リポジトリ間の変更は提案書を相手側の知識に評価させる

3つのリポジトリでコンセプト665・568・162件、相互リンク6,633・5,471・857件の知識を作り、Codex・Claude Code・GitHub Copilot・Grokのどれでも問題なく動いた。

エージェント同士を同じモデルで対立させたことで設計が洗練される場になった。

転職で150社以上に応募しても通らず、原因の一つに見せられる開発実績が無いことがあった。

自分でコードを書く前提だったが、開発環境づくりの段階からつまずいた。

1. 職務経歴書を作るWebアプリという題材を決めた
2. devcontainerの構築からAIエージェントに任せた
3. 人は指示役に回り設計・実装・テストをAIが進めた
4. 進捗と方針をリポジトリ内にAIが書き残す形にした
5. 別PCではdocs/designを読んで続けろと指示し再開した

2026年8月15日に始めた開発は8月23日に本番へのデプロイまで終わった。

かかった費用はGitHub Copilotのクレジット約40ドルとドメイン11.51ドル、それにVPSの36か月契約22,733円とGemini APIの5000円だった。

パッケージ時代から続く仕様書中心の開発の流れが残り、実装後に仕様書を書き直す手戻りも多かった。

AIを入れただけでは人の進め方が足かせになっていた。

1. 全社で使えるGeminiを土台に置く
2. 用途ごとにCursorやClaude Codeを使い分ける
3. 人が要求と制約を渡し設計から実装までAIに任せる
4. 仕様書をMarkdownに直しGitHubでまとめる
5. AIの実装を人が直しその成果物からAIに文書を作らせる

対象の開発案件で見積工数が約5分の1まで減った。

AIを使った開発手法のワークショップでは3日間でプロトタイプまで仕上がった。

開発者3000人にAIコーディング支援を配ったが使われるのはコード補完だけで高度な機能が眠っていた。

費用の膨張やセキュリティ面の統制も課題になった。

1. 社内専用チャットbotを作り従業員の7割に広げた
2. 開発者にGitHub Copilotを配布した
3. 人事部門と組んで6つの学習コースを用意した
4. 自社製の管理ツールで利用量をダッシュボード化した
5. 消費が急増した用途は安いモデルへ切り替えた

導入から1年でIT子会社Liberty ITのGitHub Copilot利用率は90％に達した。

数時間で2万ドルかかっていた処理はモデルの入れ替えで最終的に4万ドルの費用削減につながった。

古い仕様書は要件の一部が省かれ判断の根拠が口頭のままで残っていた。

主語の省略や古い章立てもあり読み解くのに時間がかかっていた。

1. 古い仕様書をMicrosoft Copilotに渡し今の読み方に合う文章へ書き直す
2. GitHub Copilotで既存コードを読み取り仕様書の抜けを埋める
3. 1ファイルはMicrosoft Copilot、依存追跡はGitHub Copilot
4. 設計書のレジスタ定義や関数宣言を渡し#defineやヘッダ定義を出させる
5. 影響範囲の洗い出しや責任の切り分けは人が引き取る

新人教育にかかっていた工数の負担が下がり、コード読解の速さも上がった。

量は多いが判断の少ない宣言部分で工数を減らせた一方、網羅性と正確性と統合が必要な作業は人の担当として残った。

事業者向け管理画面と一般ユーザー向けシステムを同時に作る大規模開発で、仕様策定やデザインの確認に時間がかかっていた。

実装が終わってから想定と違う挙動に気づき、大きな手戻りが出ることもあった。

1. デザイナーがざっくりした仕様をAIに渡し数分で動くモックを作らせる
2. モックを関係者と見ながら認識を合わせる
3. 方向性が決まったらFigmaのオートレイアウト付きデータへ変換させる
4. PdMが議事録とSlackのスレッドURLを渡しNotionのPRDへ変更点を反映させる
5. SDKチームは仕様書からコード生成までプラグインに任せ人はレビューに回る

仕様を決めてから動くものを見るまでのサイクルが、以前の2週間〜1ヶ月から1日、2日になった。

深刻な手戻りも開発の初期段階で防げるようになった。

開発チームごとに違うツールと手順を使っていて協力しづらかった。

リリースの手順も不安定でミスが起きやすい状態だった。

1. 約3,000人と2万のリポジトリをGitHub Enterpriseへ移した。
2. 移行ではGitHub IssuesとActionsで権限を作り直した。
3. 人への連絡や日程調整は自前で作ったソフトに任せた。
4. 土台が整ったあとGitHub Copilotを試験的に入れた。
5. 検査やテストを使い回せるActionsとしてまとめた。

試験導入の初期の結果では開発の速さが40%上がった。

移行後は開発者とソースコードの99%近くがGitHubにまとまり、自動で走るCI/CDの回数は100%増えた。

開発ツールが古くばらばらで開発者の作業が滞りリリースが遅れていた。

脆弱性の発覚も終盤になりがちで事業のリスクになっていた。

1. 開発の環境をGitHubの基盤へまとめる
2. IDE上でCopilotの補完を受けて作業した
3. 込み入った変更はエージェントモードに任せる
4. 検査を開発の流れに組み込み書きながら直した
5. Autofixの修正案は開発者が確かめて反映する

技術的負債の修正は前年と比べて40%良くなった。

セキュリティ修正のMTTRは63%減り、開発者の満足度とNPSは4.4/5まで上がった。

2023年からGitHub Copilotを全エンジニアに配ってきたが、さらに開発の速さと質を上げるには使う範囲を広げる必要があった。

1. 2025年8月に全エンジニアへ開発AIエージェントを配った。
2. 仕様づくりから設計やコーディングやコードレビューまで任せる。
3. エンジニアの採用管理や仕事の進み具合の把握にも使う。
4. 誰がどれだけ貢献したかを見える形にする。
5. 導入の前に複数のサービスを試し開発量が伸びたものを選んだ。

試した段階で開発量が伸びる手応えを得たため本格導入に踏み切った。

コーディング以外の管理の仕事も含めて開発組織全体の底上げを狙う。

グループ全体で業務の無駄を減らしたいが、社員ごとにAIの使い方がそろっていなかった。

ガイドブックや社内規定は量が多く、必要な情報にたどり着くまで時間がかかっていた。

1. 社内公募で集まった46名でプロジェクトを立ち上げた。
2. 動画で使い方やプロンプトを社員へ配った。
3. 全社員にGeminiの有料版を配って毎日の業務で使うよう呼びかけた。
4. ガイドブックと社内資料をRAGに読み込ませ問い合わせを検索に置き換えた。
5. ベトナムの開発拠点ではGitHub Copilotを開発に使っている。

2025年4月の社内アンケートでは月に数回以上使う社員が95.18％になり、ひと月で6,268時間を生み出した。

年間に直すと75,216時間で、AIロープレの導入により研修運営の管理者負担も約30%減った。

クラウドソーシングのcrowdworksへCSS Modulesを入れた後、CSSクラスの名前の付け方がばらばらで一括の置き換えができなかった。

約500ファイル3200箇所を手で直すと1984時間かかる見込みだった。

1. 直す必要のある箇所と命名のパターンを洗い出した。
2. GitHub Copilot Chatへ相談した。
3. 複数の書き方に対応できる置換プログラムを作らせた。
4. 約500ファイルへまとめてかけ3200箇所を直した。
5. 社内のナレッジ共有コンテストPIPで全社へ共有した。

コーディングの工数が1984時間から20時間になり、99％削減できた。

最新の技術に触れられる環境が社員に無く、競争力とエンジニアのやる気を保ちにくかった。

全社で生成AIを使うにはセキュリティと社内ルールの整備も必要だった。

1. 4月にCTO体制で全社横断のプロジェクトを立ち上げた
2. 希望者にChatGPT Plusを配る
3. エンジニア全員にGitHub Copilotを渡した
4. 5月に利用ガイドラインを決めて全社へ広げる
5. 6月にSlackへChatGPTBotを置き記録と絞り込みを足した

8月の社内アンケートでGPT-4の利用率は76%になり、使っている業務の効率は実感で平均44%改善した。

GitHub Copilotはエンジニアの75%が使い、効率は平均37%改善した。

案件ごとに専用のパソコンを用意して設定する必要があり、その作業が開発者の時間を奪っていた。

1. 案件ごとに端末を組み立てる進め方をやめた
2. クラウドのMicrosoft Dev Boxから専用の作業環境を呼び出す
3. 開発者は立ち上がった環境でそのままコードを書き始める
4. コードを書く場面でGitHub Copilotに補完や下書きをさせる

プロジェクトの立ち上げにかかる時間が1週間減った。

GitHub Copilotで開発者の生産性が20%上がり、2025年には375,000時間の節約を見込む。