Copilot CLI新ターミナルUI入門——Issue/PRタブでNext.js開発を回す

はじめに

ターミナルでAIエージェントを使っていて、こんな状態になっていませんか？

2026年6月23日、GitHubは「Copilot CLI: New terminal interface is generally available」を公開しました。新しいターミナルUIでは、インタラクティブセッション上部にタブが表示され、GitHubリポジトリ内で起動するとIssuesとPull requestsのタブも使えます。IssueやPRを選んで c を押すとプロンプトへ参照を挿入でき、o でブラウザを開き、/ で検索できます。

本記事では、架空の在庫管理SaaS「StockLane」を題材に、Copilot CLIの新UIをNext.js App Router + Firestore + GitHub Actionsの開発フローへ組み込む方法を解説します。この記事を読み終わると、Issueから実装、作業ログ、CI検証までをターミナル中心で回す設計ができます。

参考にした一次情報は次の通りです。

• Copilot CLI: New terminal interface is generally available
• About GitHub Copilot CLI
• Installing GitHub Copilot CLI
• Use GitHub Copilot CLI
• GitHub Copilot CLI command reference

何が変わったのか

今回の更新で重要なのは、Copilot CLIが「質問を投げる場所」から「GitHub上の作業対象を選び、実装へつなげる場所」に近づいたことです。

インストール方法は公式ドキュメントで、npm、Homebrew、WinGet、インストールスクリプトが案内されています。npmの場合はNode.js 22以降が前提で、コマンドは次の通りです。

npm install -g @github/copilot

このプロジェクト自体の依存管理は yarn のままで構いません。上のコマンドは、Copilot CLI本体をグローバルに導入するための公式手順です。

全体像

StockLaneでは、SL-001 から SL-028 までの在庫アラート改善タスクをGitHub Issuesで管理します。1回のセッションですべてを任せるのではなく、3〜4件ずつ依存関係の近いIssueをまとめ、実装後に必ずCIと作業ログを残します。

ここで大事なのは、AIエージェントの自由度を「チケット」「指示ファイル」「CI」の3点で囲うことです。Copilot CLIはターミナルからコード変更やGitHub操作を助けてくれますが、どのファイルをどう検証するかはリポジトリ側に明文化しておく必要があります。

ハンズオン1: リポジトリ指示を固定する

まず、Copilot CLIに毎回伝えたい前提を .github/copilot-instructions.md に置きます。公式リファレンスでは、copilot init またはインタラクティブセッション内の /init により、このファイルを作成または更新できると説明されています。ここではStockLane向けに、手動で書く例を示します。

# StockLane development instructions

- Use Next.js App Router and TypeScript.
- Use Server Components by default.
- Use Server Actions for mutations from authenticated admin screens.
- Store operational records in Cloud Firestore with firebase-admin.
- Do not add Express, Prisma, or SQL examples.
- Before finishing, run `yarn build`.
- When changing inventory alert behavior, update or create GitHub Issues notes.

プロンプトでは、Issue参照と受け入れ基準を分けて渡します。Issuesタブで SL-014 を選び、c で参照を挿入したあと、次のように依頼します。

このIssueを実装してください。

対象:
- StockLaneの在庫アラート一覧
- Next.js App Router
- Firestoreの inventoryAlerts コレクション

受け入れ基準:
- 閾値未満のSKUだけを表示する
- Server Componentで初期表示する
- 管理者操作はServer Actionに閉じる
- 最後に yarn build を実行する

「よしなに直して」ではなく、対象コレクション、画面、検証コマンドを明示します。Copilot CLIの新UIでIssue参照を入れやすくなっても、判断基準までIssue本文に書かれていなければ、実装の揺れは残ります。

ハンズオン2: Firestoreに作業ログを残す

AIに任せた実装は、PRだけでは作業意図を追いきれないことがあります。StockLaneでは、管理画面からIssue単位の作業ログをFirestoreへ残します。

"use server";

import { FieldValue, getFirestore } from "firebase-admin/firestore";

type CopilotWorkLogInput = {
  issueNumber: number;
  title: string;
  summary: string;
  checks: string[];
  actorId: string;
};

export async function createCopilotWorkLog(input: CopilotWorkLogInput) {
  if (!Number.isInteger(input.issueNumber) || input.issueNumber <= 0) {
    throw new Error("issueNumber must be a positive integer");
  }

  if (input.checks.length === 0) {
    throw new Error("checks must include at least one verification item");
  }

  const db = getFirestore();
  const ref = db
    .collection("copilotWorkLogs")
    .doc(`SL-${String(input.issueNumber).padStart(3, "0")}`);

  await ref.set(
    {
      title: input.title,
      summary: input.summary,
      checks: input.checks,
      actorId: input.actorId,
      updatedAt: FieldValue.serverTimestamp(),
    },
    { merge: true },
  );
}

ログに入れるのは、顧客名や実在の在庫数ではなく、検証した観点です。たとえば「閾値判定の境界値を確認」「Firestoreの複合インデックスが不要なクエリにした」「yarn build 成功」のように、あとからレビューできる情報だけを残します。

ハンズオン3: 3〜4件ずつ並列化する

28件のIssueを1本の巨大プロンプトにまとめると、コンテキストが膨らみ、レビューも難しくなります。StockLaneでは、依存関係で小さなバッチに分けます。

Copilot CLIのIssuesタブで同じバッチのIssueを確認し、依存関係が近いものだけを1セッションに入れます。複数のPRを扱う場合は、公式Docsにある /pr コマンドでPRの表示、作成、修正をターミナルから扱えます。大規模な作業を速めたい場合は /fleet もDocsに掲載されていますが、まずは小さなバッチでレビュー可能な単位を保つほうが実務では安定します。

GitHub Actionsで最後に止める

AIエージェントの実装を受け入れる前に、CIで最低限の品質ゲートを通します。StockLaneでは、Next.jsのビルドと、Firestoreルールの静的チェックをPRごとに実行します。

name: pull-request-check

on:
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "22"
          cache: "yarn"
      - run: yarn install --frozen-lockfile
      - run: yarn build

Copilot CLIの公式リファレンスには、ツール許可の考え方も整理されています。たとえば --allow-tool や --deny-tool は、読み取り、書き込み、シェル実行、URLアクセスなどを制御するためのパターンを受け取ります。ローカルで強い権限を与えるほど作業は速くなりますが、まずは「ファイル変更は確認する」「CIで必ず再検証する」という運用を崩さないことが重要です。

実務での注意点

Copilot CLIの新UIは、IssueやPRへのアクセスを近くしてくれます。ただし、Issueを見つけやすいことと、実装が安全であることは別です。

• Issue本文に受け入れ基準、対象外、検証コマンドを書く
• .github/copilot-instructions.md に技術スタックを固定する
• Firestoreには作業証跡だけを残し、顧客データを入れない
• 3〜4Issue単位でバッチ化し、依存関係の遠い作業を混ぜない
• PRではCopilotの説明ではなく、差分とCI結果を根拠にレビューする

まとめ

Copilot CLIの新ターミナルUIは、GitHub Issues、PR、Gistsをターミナル内のタブとして扱えるようになり、Issue駆動の開発にかなり寄せやすくなりました。Next.js + Firestoreのような業務アプリでは、Issue参照を正確に渡し、リポジトリ指示で技術スタックを固定し、Firestoreに作業ログを残し、GitHub Actionsで最後に止める構成が現実的です。

まずは1つの小さな改善Issueで、Issuesタブから参照を挿入し、yarn build まで通す流れを試すのがよいです。そこから3〜4件のバッチへ広げると、AIエージェントの速度を使いつつ、レビュー可能な粒度を保てます。