GitHub Copilot Coding Agent を使って「AIに委託」してみた

本記事は【Advent Calendar 2025】 13日目の記事です。
🌟🎄 12日目 ▶▶ 本記事 ▶▶ 14日目 🎅🎁

はじめに
全体構成
委託フローの構築
- 1. 初版サイトの実装
- 2. 諸々の連携設定
委託してみる
- 結論
まとめ

はじめに

こんにちは、GitHub Copilot の課金歴がもうすぐ1年になる古田です。

先日、 Agile Japan 2025のキーノート「AI時代のソフトウェア開発を考える（2025/11版）」をメンバーから教えてもらったのですが、「AIと伴走」と「AIに委託」という二つのアプローチが示されているのが特に印象的でした。私自身、バイブコーディングの実践などから「AIと伴走」する流れは体感していましたが、「AIに委託」という発想はこれまであまり持っていませんでした。

今回は、自分が委託者になりきって、GitHub Copilot Coding Agent を利用した「AIに委託」するフローを試してみます。

全体構成

AIに完全委託する前提で進めるため、PR の確認・コードレビューは委託者側では行いません。品質レビューは実際に動作するプレビュー環境上でのみ行います。プレビュー環境には Netlify を利用します。

また、GitHub Copilot Coding Agent は GitHub Issues を起点に動くのですが、おそらく IT エンジニアではない委託者が必ずしも GitHub を触るとは限らないため、一般的な課題管理ツール経由で要求仕様を伝える構成にします。今回は Jira を使って要求を投げます。

利用サービス・プラン
- GitHub Copilot Pro
- Jira Cloud Free
- Netlify Free

委託フローの構築

1. 初版サイトの実装

アドベントカレンダーの静的サイトを作ることにします。まだフローがないので、初版の実装は AI に委託せず、Copilot 使ったバイブコーディングでサクッと作りました。GitHub へプッシュして Netlify で公開します。

2. 諸々の連携設定

ワークフローは以下のように実現します。Jira に拘ったら思ったより大変でした。

Jiraで課題作成
Jira Automationが発火
GitHub repository dispatch APIを呼び出し
GitHub Actions ワークフローを起動
GitHub Issue 自動作成、@copilot を自動アサイン
Copilot が実装開始、PR作成
トピックブランチからNetlifyのプレビュー環境が作成・デプロイされる
プレビュー環境のURLを Jira の課題へコメントし、Jira ステータス更新
Jiraでステータス更新（動作確認完了）
再び Jira Automation が発火し、GitHub repository dispatch APIを呼び出し
GitHub Actions でPR承認＆マージ
mainブランチからNetlifyの本番環境へ自動デプロイ

Jira 側の設定

JiraアプリGitHub for Atlassian をインストール
課題起票で GitHub Actions を起動する Jira Automation を作成
ステータス更新で GitHub Actions を起動する Jira Automation を作成

GitHub Actions

以下のような Issues を作成して Copilot をアサインするワークフローを用意します。

name: Create GitHub Issue from Jira

on:
  repository_dispatch:
    types: [jira-issue-created]

permissions:
  issues: write

jobs:
  create-github-issue:
    runs-on: ubuntu-latest
    timeout-minutes: 2
    
    steps:
      - name: Create GitHub Issue from Jira
        uses: actions/github-script@v7
        with:
          script: |
            const payload = context.payload.client_payload;
            const jiraKey = payload.issue_key;
            const jiraTitle = payload.issue_title;
            const jiraDescription = payload.issue_description || '';
            const jiraUrl = payload.issue_url;
            const jiraType = payload.issue_type || 'Task';
            
            // GitHub Issueを作成
            const issue = await github.rest.issues.create({
              owner: context.repo.owner,
              repo: context.repo.repo,
              title: `[${jiraKey}] ${jiraTitle}`,
              body: `**Jira:** [${jiraKey}](${jiraUrl})
            ${jiraDescription}
              labels: ['auto-implement', 'from-jira']
            });
            
            // @copilot を自動アサイン
            await github.rest.issues.addAssignees({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: issue.data.number,
              assignees: ['copilot']
            });
            
            console.log(`Assigned @copilot to Issue #${issue.data.number}`);
            
            // Jira課題にコメントを投稿
            if (process.env.JIRA_API_TOKEN && process.env.JIRA_BASE_URL && process.env.JIRA_USER_EMAIL) {
              const jiraComment = {
                body: `GitHub Issue が自動作成されました: ${issue.data.html_url}\n\n@copilot による自動実装が開始されます。`
              };
            }
        env:
          JIRA_API_TOKEN: ${{ secrets.JIRA_API_TOKEN }}
          JIRA_BASE_URL: ${{ secrets.JIRA_BASE_URL }}
          JIRA_USER_EMAIL: ${{ secrets.JIRA_USER_EMAIL }}

他にも、Netlify のプレビュー環境 URL を Jira にコメントするワークフロー、PR を自動承認＆マージするワークフローが必要です。

Netlify

PRごとのプレビュー環境ができるよう設定を追加します。

# Deploy Previewsの設定（）
[context.deploy-preview]
  command = "npm run build"

委託してみる

実際に 12/8 の記事を追加するよう、Jira で雑に投げてみました。

GitHub Issues が無事作成されましたね。

しかし、自動でアサインされるはずの Copilot がアサインされず、色々と調べましたがワークフロー上からの Copilot のアサインがうまく動作しなかったため、今回は諦めて手動でアサインしました。

しばらく待つと Copilot により自動で PR が作成され、Netlify のプレビュー環境にも反映されます。

Jira にコメントされたプレビュー環境にアクセスして確認すると、12/8 記事が追加されリンクも機能しています。指示どおりに修正されていますね。

最終的に Jira のステータスを進めて本番デプロイまで完了しました。

結論

残念ながらワークフロー上での Copilot のアサインがうまくできなかったため、Jira バックログの操作だけで完結させることはできませんでしたが、委託者の立場でレビューしながら要件を形にする「AIに委託」スタイルは十分に機能しました。

レビューNGの場合に追加で修正指示を出せるようにしたり、Copilot のカスタムエージェントや他のコード特化 AI も試してみたり（Claude Code なら GitHub Actions 上で自由に呼び出せそう？また課金…💸）、ワークフローの改善はまだまだ必要ですが、最終的にはニュースやブログ記事のようなWebサイトのコンテンツ更新業務など、実際の業務にも十分適用できそうです。

まとめ

今回の試行で分かったのは、「AIに委託」を実現する鍵が環境と評価のワークフロー設計にあるという点です。冒頭で触れた t_wada さんの講演でも指摘されているように、要件を宣言的に記述し、評価関数で期待値を定義する、今回のようにプレビュー環境を用意するなど正しくテスト戦略を実践すれば、AIを適切に動かしつつも必要な品質は担保することができます。書いていて気づいたのですが、こうした要素は「AIに委託」特有のものというより、通常の開発委託にも共通して求められるものだと思います。

この1年 GitHub Copilot を使ってきて、AIモデルの進化の速さを実感しています。最初は確か GPT-4 で、4.1 、5 、最近のメインは専ら Claude Sonnet 4.5 になっており、利用するモデルの変遷とともに任せられる範囲は格段に広がっています。今回は簡単な内容のバックログ対応でしたが、いずれはもっと高難度の要求も委託できるレベルに達するだろうと感じます。一方で、どれだけ自動化が進んでも、そのためのワークフローを考え・試行錯誤し・編み出していくのは結局は人の仕事です。今後も「AIへの委託」の進化を追い続け、実業務に耐える仕組み作りを続けていきたいと思います。