最近、GitHub Copilotの従量制導入の話題が賑やかですね。私も正直「また課金の話か…」と思いながら情報を追っていたのですが、そんな中で出会った「Copilot CLI」の破壊力に、完全にやられてしまいました。今回はその体験と、私が実践している軽量ワークフローをたっぷり語ります。
Copilot CLIとは何か、そしてなぜ感動したのか
Copilot CLIとは、ターミナル(コマンドライン)上でGitHub Copilotを直接呼び出せるツールです。IDE上のコード補完とは全く別物で、「シェルコマンドを自然言語で生成する」「コマンドの意味を説明させる」「コマンドのデバッグをさせる」といったことが、ターミナルを離れることなくできるようになります。インストールは `npm install -g @githubnext/github-copilot-cli` でできます(※現在はGitHub CLIの拡張機能として `gh extension install github/gh-copilot` という形に統合されている場合もあります)。認証も `gh auth login` 経由でサクッと通ります。
使い方はシンプルで、主に3つのコマンドが中心です。
・`gh copilot suggest` : 「やりたいこと」を日本語で入力すると、それに対応するシェルコマンドを提案してくれます。
・`gh copilot explain` : 見慣れないコマンドや複雑なパイプラインを貼り付けると、何をしているのか自然言語で説明してくれます。
・`??` / `git?` / `gh?` : インタラクティブなエイリアス経由で、さらに手軽に呼び出せます。
私が最初に感動したのは、PowerShellで「ある拡張子のファイルを再帰的に探してCSVに出力したい」という作業をやっていたときです。今まではStackOverflowをさまよいながらオプションを調べていたのが、`??` で一言打ち込むだけで即答が返ってきた。「あ、これは時代が変わったな」と思った瞬間でした。
AI開発の2つの役割分担
AIを活用した開発を続ける中で、私はだんだんと「役割を分けること」の重要性を感じるようになりました。ざっくり言うと、こんな分担です。**① AI-IDE(WindsurfやCursorなど):設計・複雑な実装担当**
プロジェクト全体のコンテキストを理解した上で、「こういう設計にしたい」「この機能を実装して」という創造的・設計的な指示を与えるのに向いています。複数ファイルをまたいだリファクタリングや、仕様をMarkdownで渡してのスキャフォールディングなども得意です。
**② Copilot CLI:環境調査・ファイル整備・コマンド操作担当**
「この環境でnode.exeがどこにあるか調べたい」「不要ファイルを条件を絞って一括削除したい」「gitの特定コミットのログを整形して出力したい」といった、定型的・反復的なコマンド操作はCLIに任せます。IDE上でウィンドウを切り替えることなく、ターミナル内で完結するのが快感です。
この2つを使い分けることで、「IDEが重くて思考が途切れる」「コマンドを調べるためにブラウザに飛ぶ」といったコンテキストスイッチのコストが激減しました。特に私のように「荒野の無料者」スタイルで複数ツールのクォータをやりくりしている場合、この分担は無駄なAPI消費を減らす上でも有効です。
私のCOPILOT_CLIの最小構造
「ただCLIを使う」だけでは、作業が属人的になってセッションをまたいだ再現性が失われます。私はCopilot CLIを呼び出すときの「入力の構造」を少しだけ整備することで、再現性と継続性を確保しています。以下がその最小構成です。1. `COPILOT_CLI`という親フォルダを用意する。このフォルダがCopilot CLIとのやりとりの「作業場」になります。Windowsのユーザーフォルダ直下など、パスが短くなる場所に置くと便利です。
2. `.instruction`フォルダに最低限守って欲しいルールを`instruction.md`として置く。内容は「ログは`.log`フォルダに日付付きで出力すること」「スクリプトを生成した場合は`.script`フォルダに保存すること」「コマンドを実行する前にその意図を一行で説明すること」といった、作業の一貫性を保つための方針です。
3. `.request`フォルダに今回の依頼を`request.md`として保存する。同じ作業を翌日また頼みたいとき、ターミナルで長い自然言語プロンプトを打ち直す必要がなくなります。`request.md`を更新するだけで済む、というのが地味に大きいです。
4. `.script`フォルダにAIが生成したスクリプト・ツールを保存する。「あのとき使ったPowerShellスクリプト、どこいったっけ」という事態を防げます。後述しますが、このフォルダが「手製のスクリプトライブラリ」に育っていくのが面白いです。
5. `entryPoint.md`に上記の参照順や実行指示をまとめ、CLIにはこのファイルを渡すだけにする。「まずinstructionを読め、次にrequestを読め、必要ならscriptフォルダを参照せよ」という順序を明記しておくと、AIが毎回同じコンテキストで動いてくれます。
この構造、AI-IDEのプロジェクトと同じ発想です。私はAI-IDEでも`entryPoint.md`(または`index.md`)を使って跨セッション継続性を確保していますが、その考え方をCLIにも輸入した形です。一度作ってしまえば、「CLIを呼ぶときはこのフォルダを開く」という習慣に乗るだけなので、認知負荷がとても低いです。
実際の使用例:こんな場面で助かった
抽象論だけでは伝わらないので、私が実際に感動した具体的な場面をいくつか挙げます。**【例1】Node.jsのバージョン管理の混乱を解消**
nvmとnodistが混在した環境で「いまどのnodeが動いているのか、PATH上にどれが先にある?」という状況に陥ったことがあります。`?? 現在のPATH上のnodeのパスを全部一覧したい` と打ち込むと、`where node`+`$env:PATH`の解析コマンドを組み合わせた回答が即座に返ってきて、混乱が3分で解消しました。
**【例2】ログファイルの集計作業**
`.log`ファイルが複数フォルダに散らばっていて「ERROR行だけ抜き出して日付ごとに集計したい」という作業。`?? logsフォルダ以下の.logファイルからERRORを含む行を日付ごとに集計してCSV出力` と頼んだら、PowerShellの`Get-ChildItem`と`Select-String`とグループ化を組み合わせたスクリプトを出力してくれました。これを`.script`フォルダに保存しておいたので、翌週また使えました。
**【例3】Gitの複雑なログ整形**
「特定のファイルだけ変更したコミットを、著者・日付・メッセージ付きでCSVに出したい」という依頼。gitのログオプションをすべて覚えている人はほとんどいないと思いますが、自然言語で頼むと `git log --follow --pretty=format:...` のコマンドをサッと組み立ててくれます。`git explain` で意味を確認しながら使えるのも、学習として有益です。
実践で気づいたことと注意点
ここまで良いことばかり書きましたが、使ってみてわかった注意点もあります。正直に書いておきます。・**CLIは「何をするか」が明確なときに輝く。** 曖昧な目的で使うと、提案が的外れになることがあります。「なんかいい感じにして」ではなく「このフォルダの.tmpファイルを30日以上古いものだけ削除したい」のように、具体的な条件を日本語で与えることが大切です。
・**生成されたコマンドは必ず一度目で確認する。** Copilot CLIはデフォルトで「実行前に確認を求める」フローになっていますが、それでも自分の目で何をするコマンドか読む習慣は絶対に持ってください。特に`rm -rf`系や`DROP`が混じるコマンドは要注意です(私はSQL Serverを扱う仕事もあるので、これは切実です)。
・**`entryPoint.md`の「参照順」は明確に書く。** 「どの順序で、どのファイルを参照するか」を明示しておくと、同じ作業を別のタイミングで行うときにミスが減ります。私は`# 実行順序`というセクションを設けて、番号付きで書くようにしています。
・**instructionにはログ出力ルールを必ず入れる。** 「何をやったか」のログが残っていると、「あのとき何のコマンドを生成したっけ」という再確認が格段に楽になります。特に環境調査系の作業は、後から見直したくなることが多いです。
・**重要なスクリプトはプロジェクト内に保管する。** Copilot CLIのクォータや仕様が変わっても、`.script`フォルダに育てたスクリプト資産は手元に残ります。「ツールが使えなくなったら終わり」という依存を避けるためにも、生成物はローカルに保管するのが鉄則です。
・**AI-IDEと組み合わせることで本領を発揮する。** Copilot CLIは「単体で全部やる」ツールではありません。AI-IDEで設計した仕様を`.request`に書き起こし、CLIで環境整備・ファイル操作を進め、IDEに戻って実装するというサイクルを回すことで、両者の長所を最大化できます。
まとめ:力を入れる場所と抜く場所
Copilot CLIを使い始めてから、開発作業の「力の入れどころ」が変わってきました。力を入れる場所は、**設計とレビュー**です。どんな構造にするか、どんな仕様書をAIに渡すか、生成されたコードや構成が本当に意図通りかを確認する、人間の思考と判断が必要な部分です。
力を抜く場所は、**繰り返し作業と環境の細々した調査**です。ここはCLIに任せる。コマンドを覚えることに認知資源を使わず、設計・レビューに集中できるようになると、長い目で見たときの生産性が大きく変わります。
「AIに全部やらせる」でもなく「自分で全部やる」でもない、この使い分けのバランスが、気持ちよく長続きするコツだと感じています。30年近くこの業界にいると、「魔法のツールがすべてを解決する」という波は何度も来ては引いていくのを見てきました。でも今回のCopilot CLIは、小さいけれど確実に「地に足のついた生産性向上」を感じさせてくれるツールです。
ぜひ一度試してみてください。それではまた次の記事でお会いしましょう!!


































