GitHub Copilot CLIのinteractive modeとnon-interactive modeの違いは、ひと言で言えば「Copilotと会話しながら進めるか」「1回のコマンドで結果だけ受け取るか」です。2026年4月30日に公開されたGitHub Blogの記事「GitHub Copilot CLI for Beginners: Interactive v. non-interactive mode」は、この2つの使い分けを初心者向けに整理した公式解説です。(The GitHub Blog)
結論として、調査・修正・実行確認のように作業が途中で変わる場合はinteractive mode、リポジトリ要約や短いコード生成、スクリプト連携のように目的が明確な場合はnon-interactive modeが向いています。管理者や開発チームは、単なる便利機能として見るのではなく、「誰が、どのディレクトリで、どのコマンド実行を許可するか」まで含めて運用を考えるべきです。(GitHub Docs)
GitHub Copilot CLI for Beginners: Interactive v. non-interactive modeで何が変わったか
今回の公式記事は、GitHub Copilot CLIに新しい単一機能を追加した発表というより、CLIでCopilotを使うときの基本導線を初心者向けに明確化したアップデートとして読むのが適切です。
GitHub Copilot CLIは、ターミナルからCopilotを直接使うためのCLIです。質問への回答だけでなく、コードの作成・デバッグ、GitHub.comとのやり取り、プロジェクト内の変更作業などに使えると説明されています。GitHub Docsでは、Copilot CLIはすべてのCopilotプランで利用可能ですが、組織経由で利用している場合は組織側のCopilot CLIポリシーが有効である必要があるとされています。(GitHub Docs)
今回の記事の中心は、次の3点です。
| ポイント | 内容 | 読者が押さえるべき意味 |
|---|---|---|
| interactive mode | copilotで開始する会話型の使い方 | 初心者、調査、デバッグ、複数手順の作業に向く |
| non-interactive mode | copilot -pで1回限りのプロンプトを渡す使い方 | 要約、短い質問、定型処理、スクリプト連携に向く |
| session resume | /resumeまたはcopilot --resumeで過去セッションに戻る | 作業の文脈を引き継ぎやすい |
特に重要なのは、Copilot CLIを「コマンドを教えてくれるチャット」とだけ捉えないことです。公式ドキュメントでは、Copilot CLIはユーザーの代わりにファイルの変更やコマンド実行を行う可能性があると説明されています。つまり、便利さと同時に、実行権限・対象ディレクトリ・承認フローの設計が重要になります。(GitHub Docs)
interactive modeとは：Copilotと会話しながら進めるモード
interactive modeは、Copilot CLIを会話型で使うモードです。ターミナルで次のように入力すると開始できます。
copilotGitHub Blogでは、interactive modeはCopilotとやり取りしながら進めるチャットのような体験であり、copilotを起動した時点でデフォルトで入るモードだと説明されています。質問への回答を確認し、追加質問をし、必要に応じて「実行して」「別の方法で進めて」と指示を重ねられる点が特徴です。(The GitHub Blog)
たとえば、初めて触るリポジトリで次のように聞けます。
このプロジェクトをローカルで起動する手順を確認して。
必要なコマンドを実行する前に、何をするか説明して。また、特定のファイルを文脈に入れて質問したい場合は、次のような使い方が実務的です。
@src/app.ts の処理を初心者にも分かるように説明して。
このファイルで例外処理が不足していそうな箇所を指摘して。GitHub Docsでは、interactive sessionではCopilotに1つ以上のタスクを依頼でき、フィードバックを与えて作業の方向を調整できると説明されています。また、interactive interfaceには通常のask/execute modeに加えてplan modeがあり、Shift+Tabで切り替えられるとされています。plan modeでは、コードを書く前に実装計画を作るため、複雑な変更で誤解を早めに見つけやすくなります。(GitHub Docs)
interactive modeが向いている場面
interactive modeは、答えが一発で決まらない作業に向いています。
| 利用シーン | interactive modeを選ぶ理由 |
|---|---|
| 新しいリポジトリの理解 | 追加質問をしながら構成、依存関係、実行方法を確認できる |
| バグ調査 | 仮説を出し、ログや関連ファイルを見ながら進められる |
| 仕様が曖昧な機能追加 | 先に計画を確認し、必要に応じて修正できる |
| テスト修正 | 失敗原因の確認、修正案、再実行の流れを会話で進められる |
| チーム標準に沿った実装 | 「このプロジェクトの規約に合わせて」と指示し直せる |
初心者が最初に試すなら、まずinteractive modeを選ぶのが安全です。理由は、Copilotの回答を見ながら止めたり、指示を変えたり、実行前に確認したりしやすいからです。
non-interactive modeとは：1回のプロンプトで結果を受け取るモード
non-interactive modeは、ターミナル上で1回だけプロンプトを渡し、結果を受け取ったら通常のシェル作業に戻る使い方です。GitHub Blogでは、短い質問やリポジトリ要約、コードスニペット生成、自動化ワークフローへの組み込みに向いていると説明されています。(The GitHub Blog)
基本形は次の通りです。
copilot -p "このリポジトリの目的と主要ディレクトリを要約して"GitHub Docsでは、この使い方はprogrammatic interfaceとして説明されており、-pまたは--promptオプションで単一プロンプトを渡すと、CLIがタスクを完了して終了するとされています。(GitHub Docs)
たとえば、次のような用途に向いています。
copilot -p "このREADMEを初心者向けに要約して"copilot -p "直近1週間のコミットを要約して" --allow-tool='shell(git)'ただし、non-interactive modeでファイル変更やコマンド実行を伴う作業をさせる場合は注意が必要です。GitHub Docsでは、Copilotに手動承認なしでツールを使わせるには承認オプションを指定する必要があると説明されています。便利な一方で、許可範囲を広げすぎると意図しない操作につながる可能性があります。(GitHub Docs)
non-interactive modeが向いている場面
non-interactive modeは、質問内容が明確で、会話の往復が不要な作業に向いています。
| 利用シーン | 例 |
|---|---|
| リポジトリの概要把握 | copilot -p "このリポジトリの構成を要約して" |
| Gitログの要約 | copilot -p "直近10件のコミットを要約して" |
| 短いコード例の生成 | copilot -p "TypeScriptで日付をYYYY-MM-DDに整形する関数を書いて" |
| 定型的な説明文作成 | copilot -p "この変更内容からPR説明文の下書きを作って" |
| 自動化の一部 | CIやローカルスクリプトから決まった質問を投げる |
ポイントは、「次に何を聞くか迷いそうな作業」には使わないことです。最初から欲しい答えがはっきりしている場合に使うと、ターミナルの流れを止めずに作業できます。
interactive modeとnon-interactive modeの違い
2つのモードは、優劣ではなく用途が違います。実務では、同じプロジェクト内でも使い分けるのが自然です。
| 比較項目 | interactive mode | non-interactive mode |
|---|---|---|
| 起動方法 | copilot | copilot -p "..."またはcopilot --prompt "..." |
| 使い方 | 会話しながら進める | 1回のプロンプトで結果を得る |
| 向いている作業 | 調査、設計、デバッグ、複数手順の変更 | 要約、短い質問、定型処理、スクリプト連携 |
| 初心者向け度 | 高い。途中で確認しやすい | 中程度。プロンプトの精度が重要 |
| 作業の柔軟性 | 高い。追加質問や方針変更がしやすい | 低め。目的が明確なときに強い |
| 自動化との相性 | 手作業中心 | 高い |
| 注意点 | 承認を流れ作業にしない | 許可オプションを広げすぎない |
GitHub Blogの整理に沿うと、探索的で深い作業にはinteractive mode、すでに欲しい結果が明確な高速処理にはnon-interactive mode、という判断軸が最も分かりやすいです。(The GitHub Blog)
どちらを使うべきかを判断する基準
迷ったときは、次の基準で選ぶと失敗しにくくなります。
仕様や原因が分からないならinteractive mode
バグの原因調査、既存コードの理解、ライブラリ移行のように「途中で判断が必要な作業」はinteractive modeが向いています。
このAPIで500エラーが出る原因を調べたい。
関連しそうなファイルを確認し、修正する前に仮説を3つ出して。このような依頼では、Copilotの最初の答えがそのまま最終解になるとは限りません。追加でログ、テスト、関連ファイルを見ながら進める必要があるため、会話型の方が安全です。
目的が1文で書けるならnon-interactive mode
一方で、次のように目的が明確ならnon-interactive modeで十分です。
copilot -p "このpackage.jsonのscriptsを初心者向けに説明して"copilot -p "このリポジトリの主要フォルダを表形式で要約して"「この質問にだけ答えてほしい」という場面では、毎回interactive sessionを開くより、-pで済ませた方が効率的です。
ファイル変更を伴うなら、最初はinteractive modeが無難
Copilot CLIは、ローカル環境でファイルの作成・編集・削除やコマンド実行を行う可能性があります。GitHub Docsでは、セッション中にCopilotが現在のフォルダ以下のファイルを読み取り、変更し、実行する可能性があるため、その場所を信頼できる場合のみ進めるべきだと説明されています。(GitHub Docs)
初心者がいきなりnon-interactive modeで変更作業を任せると、何が行われたかを見落としやすくなります。まずはinteractive modeで作業内容を説明させ、変更前に計画を確認し、実行後に差分を見る流れを作るのがおすすめです。
自動化に組み込むなら、許可範囲を最小化する
non-interactive modeは自動化と相性が良い一方で、--allow-all-toolsのような広い許可を安易に使うべきではありません。GitHub Docsでは、--allow-toolで特定ツールを許可し、--deny-toolで特定ツールを拒否できると説明されています。たとえば、git pushのような外部影響の大きい操作を拒否する設計が考えられます。(GitHub Docs)
管理者視点では、「動けばよい」ではなく、「どのツールを、どのディレクトリで、どのユーザーに許可するか」を決めることが重要です。
初心者が最初に試す手順
GitHub Copilot CLIを初めて触る場合は、本番リポジトリではなく、影響の小さいサンプルプロジェクトや検証用ブランチで試すのが安全です。
事前条件を確認する
GitHub Docsでは、Copilot CLIの利用には有効なGitHub Copilotサブスクリプションが必要で、WindowsではPowerShell v6以上が前提とされています。また、インストール方法としてWinGet、Homebrew、npm、macOS/Linux向けのインストールスクリプトが案内されています。(GitHub Docs)
Windows環境なら、まずWinGetで導入するのが分かりやすいでしょう。
winget install GitHub.CopilotNode.jsを使う環境では、npmによるインストールも選択肢になります。
npm install -g @github/copilot組織アカウントで使う場合は、インストールより前に管理者側のCopilot CLIポリシーが有効か確認してください。組織やエンタープライズの設定で無効化されている場合、ユーザー側でインストールしても利用できない可能性があります。(GitHub Docs)
検証用ブランチを作る
ファイル変更を試す前に、検証用ブランチを作ります。
git checkout -b try-copilot-cli次に、対象リポジトリのルートへ移動してinteractive modeを起動します。
copilot初回利用時には、対象フォルダを信頼するか確認されることがあります。GitHub Docsでは、現在のセッションのみ信頼する選択肢と、将来のセッションでも信頼する選択肢が説明されています。恒久的に信頼する設定は、その場所が常に安全だと確信できる場合だけ選ぶべきです。(GitHub Docs)
最初のプロンプトは「説明だけ」にする
最初から「修正して」と依頼するのではなく、まずは説明だけを求めます。
このリポジトリの目的、主要ディレクトリ、ローカル起動手順を説明して。
まだファイルは変更しないで。このプロンプトなら、Copilotがどの程度プロジェクトを理解できるかを確認できます。説明に違和感があれば、追加で質問しましょう。
どのファイルを根拠にそう判断したか教えて。次にnon-interactive modeを試す
interactive modeで感覚をつかんだら、別のターミナルでnon-interactive modeを試します。
copilot -p "このリポジトリの主要フォルダを5行で要約して"このような読み取り中心の質問であれば、non-interactive modeの強みが分かりやすくなります。目的が明確な質問ほど、短時間で結果を得やすくなります。
過去セッションを再開する
GitHub Blogでは、interactive modeでは/resume、通常のコマンドラインからはcopilot --resumeで過去セッションを選べると説明されています。途中で中断した調査や、前日に作った修正計画へ戻りたいときに便利です。(The GitHub Blog)
copilot --resumeただし、再開できるからといって、前回の判断をそのまま信じる必要はありません。作業前に現在のブランチ、差分、依存関係の変更を確認してから再開しましょう。
実務で使えるプロンプト例
Copilot CLIは、プロンプトの具体性で結果が大きく変わります。初心者ほど、「何をしてほしいか」「何をしてほしくないか」「出力形式」を明確にするのがコツです。
| 目的 | 推奨モード | プロンプト例 |
|---|---|---|
| リポジトリ概要を知る | non-interactive | このリポジトリの目的、主要ディレクトリ、起動方法を簡潔に要約して |
| ローカル起動を手伝ってもらう | interactive | このプロジェクトをローカルで起動したい。実行前に各コマンドの意味を説明して |
| バグ調査を始める | interactive | ログイン後に500エラーが出る。関連しそうなファイルを調べ、修正前に原因候補を挙げて |
| PR説明文を作る | non-interactive | 現在のブランチの変更内容からPR説明文の下書きを作って |
| テスト修正を進める | interactive | 失敗しているテストを調べ、修正案を出して。変更前に差分の方針を説明して |
| 管理者が挙動を確認する | interactive | この作業で実行しそうなコマンドと、ファイル変更の範囲を先に列挙して |
避けたいのは、次のような曖昧な依頼です。
いい感じに直してこのプロンプトでは、どの範囲を変更してよいのか、テストを実行してよいのか、既存仕様を守るべきなのかが分かりません。代わりに、次のように書くと実務で使いやすくなります。
ログインフォームのバリデーションを修正して。
対象はsrc/components/LoginForm.tsxに限定して。
変更前に修正方針を説明し、変更後に関連テストの実行コマンドを提案して。管理者・チームが注意すべきポイント
GitHub Copilot CLIは個人の生産性向上だけでなく、組織の開発ワークフローにも影響します。特にMicrosoft ecosystemの読者、つまりGitHub Enterprise、Windows端末、PowerShell、Microsoft 365環境の管理に関わる人は、導入前に運用ルールを決めておくべきです。
ホームディレクトリや機密フォルダで起動しない
GitHub Docsでは、信頼できるディレクトリからのみCopilot CLIを起動すべきであり、通常はホームディレクトリから起動すべきではないと説明されています。ホームディレクトリにはSSHキー、設定ファイル、個人データ、社内資料などが含まれる可能性があるためです。(GitHub Docs)
実務では、次のようなルールを設けると安全です。
- 検証用リポジトリまたは対象プロジェクトのルートでのみ起動する
~/やC:\Users\ユーザー名直下では起動しない- 秘密情報を含むフォルダでは使わない
- 本番設定ファイルや証明書がある場所では、事前に管理者へ確認する
承認プロンプトを読み飛ばさない
Copilot CLIがtouch、chmod、node、sedなど、ファイル変更や実行に関わるツールを使おうとする場合、承認を求めることがあります。GitHub Docsでは、承認には一度だけ許可する選択肢と、現在のセッション中は同じツールを許可する選択肢があると説明されています。(GitHub Docs)
問題は、2つ目の選択肢を雑に選ぶことです。たとえば、rm系の操作をセッション中ずっと許可すると、想定外の削除が起きるリスクがあります。GitHub Docsでも、rmの承認例について注意が示されています。(GitHub Docs)
--allow-all-toolsは検証環境以外では慎重に扱う
--allow-all-toolsは便利ですが、チーム開発や社内端末で安易に使うべきではありません。許可するなら、コンテナ、仮想マシン、検証専用端末など、影響範囲を絞った環境で使うのが現実的です。GitHub Docsでも、自動承認のリスクを軽減する方法として、権限やネットワークアクセスを制御した制限環境の利用が示されています。(GitHub Docs)
安全性を優先するなら、まずは次のように限定的に許可します。
copilot -p "直近のコミットを要約して" --allow-tool='shell(git)'さらに、外部へ影響する操作を拒否する例として、次のような考え方もあります。
copilot --deny-tool='shell(git push)'--allow-toolと--deny-toolを組み合わせることで、「必要な操作だけ許可し、危険な操作は明示的に拒否する」運用に近づけられます。(GitHub Docs)
出力をそのまま信用しない
Copilot CLIの提案は、レビュー対象です。GitHub Docsのベストプラクティスでも、提案された変更を受け入れる前に確認し、シークレットをコミットしないよう検証すべきだとされています。(GitHub Docs)
実務では、Copilot CLIの作業後に最低限次を確認しましょう。
git diffで差分を確認する- テスト、lint、ビルドを実行する
- 認証情報やトークンが含まれていないか確認する
- 破壊的なコマンドが実行されていないか履歴を見る
- PRでは人間のレビューを通す
AIエージェントを使っても、最終責任は開発者とチームにあります。
Microsoft ecosystem読者が見るべき実務上の意味
GitHub Copilot CLIのinteractive/non-interactive mode整理は、開発者だけでなく、管理者やプロダクトウォッチャーにとっても意味があります。
Windows環境では、PowerShellやWSLからCopilot CLIを利用できるとGitHub Docsで説明されています。さらにインストール方法としてWinGetが案内されているため、Windows中心の開発チームでも導入フローを組み立てやすい点は注目できます。(GitHub Docs)
管理者にとって重要なのは、Copilot CLIがIDE内の補完機能とは異なり、ターミナル上でファイル変更やコマンド実行に関与し得ることです。つまり、ライセンス付与だけでなく、次のような運用設計が必要になります。
| 管理項目 | 確認すべきこと |
|---|---|
| 利用ポリシー | 組織でCopilot CLIを有効にするか |
| 端末環境 | PowerShell、WSL、Node.js、WinGetなどの前提を満たすか |
| 対象ディレクトリ | どのリポジトリで利用を許可するか |
| ツール実行 | どのコマンドを許可・拒否するか |
| レビュー | AIによる変更を誰が確認するか |
| 教育 | interactiveとnon-interactiveの使い分けを説明できているか |
プロダクトウォッチャー視点では、Copilot CLIは「エディタ内補完」から「ターミナル内エージェント」への広がりを示す動きです。開発者がIDEを離れずにAIを使うだけでなく、シェル、Git、テスト、ビルド、PR作成といった一連の作業の中にAIエージェントが入り込む流れが強まっています。
失敗しやすい使い方と回避策
初心者がつまずきやすいポイントは、機能不足ではなく、使い方の粒度です。
| 失敗例 | 起きやすい問題 | 回避策 |
|---|---|---|
| いきなり大きな修正を依頼する | 変更範囲が広がり、レビューしづらい | まず調査、次に計画、最後に実装の順に分ける |
| non-interactive modeで曖昧な依頼をする | 期待と違う結果になる | 目的、対象ファイル、出力形式を明記する |
| 承認を流れ作業で許可する | 意図しないコマンド実行につながる | 実行内容を読み、危険な操作は拒否する |
| ホームディレクトリで起動する | 不要なファイルや機密情報に触れるリスクがある | 対象リポジトリのルートで起動する |
| AIの変更をそのままコミットする | バグやシークレット混入を見逃す | diff、テスト、レビューを必ず通す |
特に「調査」と「変更」を同じプロンプトに詰め込むと、結果を追いづらくなります。最初は次のように分けると安全です。
まず原因候補を調べて。まだファイルは変更しないで。原因候補のうち、最も可能性が高いものを修正する計画を出して。その計画で進めて。変更後に差分とテスト方法を説明して。この順序なら、人間が判断する余地を残しながらCopilot CLIを使えます。
チーム導入時のおすすめルール
チームでGitHub Copilot CLIを使うなら、個人任せにせず、最小限のルールを文書化しておくと混乱を防げます。
おすすめは、リポジトリに.github/copilot-instructions.mdのような指示ファイルを用意し、ビルド、テスト、lint、コミットメッセージ、レビュー方針を明記することです。GitHub Docsのベストプラクティスでも、Copilot CLIが複数の場所にあるカスタム指示を読み取れること、リポジトリ単位の指示でチーム規約を反映できることが説明されています。(GitHub Docs)
たとえば、次のような内容をチーム標準として置いておくと実務で役立ちます。
## Build Commands
- npm run build でビルドする
- npm test でテストを実行する
- npm run lint でlintを確認する
## Workflow
- 変更前に実装方針を説明する
- 大きな変更は小さなステップに分ける
- 認証情報やAPIキーを生成・保存しない
- PR作成前に差分とテスト結果を要約するこのような指示を用意しておくと、Copilot CLIに毎回同じ前提を説明する手間を減らせます。ただし、長すぎる指示は効果が薄れる可能性があるため、具体的で短い内容に絞るのが実用的です。(GitHub Docs)
まず何から始めるべきか
GitHub Copilot CLIのinteractive modeとnon-interactive modeは、どちらか一方だけを覚えればよいものではありません。最初はinteractive modeで安全に挙動を確認し、慣れてきたらnon-interactive modeで要約や定型処理を効率化する流れが現実的です。
最初の一歩としては、次の順で試すのがおすすめです。
- 影響の小さいリポジトリで
copilotを起動する - 「説明だけ」「変更しないで」と明示してプロジェクト理解に使う
copilot -pでリポジトリ要約やGitログ要約を試す- ファイル変更を依頼する前に、plan modeや実装方針の確認を使う
- チーム利用では、信頼ディレクトリ、許可ツール、レビュー手順を決める
今回の公式記事から読み取るべき本質は、Copilot CLIを「AIに任せるツール」としてではなく、ターミナル上で人間が主導権を持ちながらAIエージェントを使い分けるツールとして扱うことです。探索的な作業はinteractive mode、明確な一問一答や自動化はnon-interactive mode。この線引きをチームで共有するだけでも、導入時の失敗はかなり減らせます。
コメント