はじめに
GitHubが 8月 6, 2026 、公式ブログでGitHub Copilot appのスラッシュコマンド活用ガイドを公開しました。6月に登場したデスクトップアプリで使える「/」始まりのコマンドについて、本稿では公式ドキュメントの一覧とあわせて、用途別に整理します。
参考記事
メイン記事:
- タイトル: A guide to slash commands in the GitHub Copilot app
- 著者: Jacklyn Carroll
- 発行元: The GitHub Blog
- 発行日: 2026年8月6日
- URL: https://github.blog/ai-and-ml/github-copilot/a-guide-to-slash-commands-in-the-github-copilot-app/
関連情報:
- タイトル: Slash commands for the GitHub Copilot app
- 発行元: GitHub Docs
- URL: https://docs.github.com/en/copilot/reference/github-copilot-app-reference/slash-commands
関連記事
要点
- スラッシュコマンドは、GitHub Copilot appのチャット入力欄に「/」を入力すると候補が表示される、テキスト形式のショートカットである
- Copilot CLIのコマンドがターミナル前提の設計であるのに対し、appのコマンドはセッション移動やプロジェクト管理といったワークフロー寄りに設計されている
- 公式ブログでは /plan、/spar、/autopilot、/rubber-duck、/create-canvas、/orchestrate の6つがプロンプト例つきで紹介されている
- /plan と /autopilot はセッションのモードそのものを切り替えるコマンドであり、チャット入力欄のモード選択メニューからも同じ切り替えが可能である
- 公式ドキュメントのリファレンスには40種類以上のコマンドが掲載されており、セッション操作やプルリクエスト操作の専用コマンドも含まれる
詳細解説
スラッシュコマンドとは何か
スラッシュコマンドは、GitHub Copilot appのチャット入力欄（コンポーザー）に直接入力するテキストショートカットです。GitHubの説明によれば、/ を打ち込むと補完メニューが開き、そのときの状況で使えるコマンドが一覧表示されます。GitHub Docsのリファレンスでも、/ でコマンドピッカーを開いて選択するか、続けて文字を入力して絞り込む操作方法が案内されています。
補完メニューが出るという性質上、コマンド名を暗記する必要はありません。表示される候補は状況によって変わり、セッションを開始しているかどうかでも変化します。まずは / を打って何が使えるかを眺めるところから始められる設計だと言えます。
CLIのスラッシュコマンドとの違い
すでにCopilot CLIでスラッシュコマンドを使っている方であれば、/clear や /model のように両方で共通するコマンドがあることに気づくと思います。一方でGitHubは、CLIのコマンドがターミナル起点のワークフローを前提に設計されている点を差として挙げています。ディレクトリの追加や作業ディレクトリの設定、ターミナルアクセスの管理などは、視覚的なインターフェースを持たないCLIだからこそコマンドとして必要になる機能です。
これに対してappは、プロジェクトのコンテキストを自動的に管理する視覚的なインターフェースを備えているため、/add-dir や /cwd のようなファイルアクセス系コマンドは不要になっています。代わりに、セッション間の移動やプロジェクト管理、エージェントの動作制御といったワークフロー寄りのコマンドが中心です。CLIのインタラクティブモードと非インタラクティブモードの違いを把握している方は、その延長として捉えると理解しやすいかもしれません。
書き始める前に使う /plan と /spar
/plan は、コードを書き始める前にタスクを分解し、アプローチを検討して、次に何をすべきかを整理するためのコマンドです。実行するとセッションが Plan モードに切り替わります。同じ切り替えはコンポーザーの Mode ドロップダウンからも行えます。
GitHubは、新機能の設計、大規模リファクタリングの準備、バグのトリアージという3つの用途を挙げています。たとえばリファクタリング前の調査であれば、次のように書きます。
/plan We want to refactor our notification system code to make it easier to support new channels like push notifications. Help me understand the changes needed and create an incremental migration plan.一方 /spar は、立てた方針をあえて疑わせるためのコマンドです。GitHubはこれを、「これがうまくいかなかったときのことは考えたか」と手を挙げるチームメイトのような存在だと説明しています。前提や見落としているリスク、トレードオフを指摘させることで、方針を固める前に検証できます。
/spar I'm planning to use Redis as a caching layer for our product API. Challenge my approach and point out any scalability or consistency concerns I may have missed.RESTとGraphQLの比較、データベース移行計画のレビュー、パフォーマンス最適化の妥当性検証なども例として挙げられています。設計判断は一度決めると後戻りのコストが大きくなりやすいため、レビュー相手が確保しにくい少人数チームほど有用性が高いかもしれません。
実装を任せる /autopilot と、別モデルに見せる /rubber-duck
/plan で方針が固まった後の実装段階を担うのが /autopilot です。個々の手順を指示する代わりにゴールを渡し、完了までの過程をCopilotに任せる使い方になります。こちらもセッションが Autopilot モードに切り替わります。
/autopilot Update this project to the latest version of React. Identify breaking changes, update the code where needed, and make sure the test suite passes./rubber-duck は名前のとおり、いわゆるラバーダック・デバッグをAIで行うコマンドです。特徴的なのは、GitHubの説明によれば セッションで使っているモデルとは別のモデル が独立してレビューを行う点にあります。同じモデルに確認させると同じ前提を共有したままになりやすいため、盲点や見落としを洗い出す用途では有効な設計だと考えられます。複雑なリファクタリングやアーキテクチャの判断、移行計画のレビューなど、プルリクエストを開く前のセカンドオピニオンとして位置づけられています。
/rubber-duck Review the refactoring we've completed for the notification system. Look for architectural concerns, unnecessary complexity, or areas that could be improved before I open a pull request.対話を成果物に変える /create-canvas、複数タスクをさばく /orchestrate
/create-canvas は、Copilotとの会話からインタラクティブなインターフェースを直接生成するコマンドです。長いチャットの中で情報を追うのではなく、可視化やダッシュボード、独自のワークフローとして扱えるようにする使い方が想定されています。
/create-canvas Create an interactive diagram showing how services in this application connect./orchestrate は、複数のリポジトリにまたがる変更や、関連する複数タスクを並行して進めたい場合に使います。大きな作業を小さなタスクに分解し、セッションやリポジトリをまたいで調整する役割です。GitHub Docsによれば、/orchestrate と /create-canvas はいずれも組み込みスキルとして実装されているコマンドにあたります。
/orchestrate I need to add support for a new authentication flow across our frontend, backend, and shared repositories. Help me break down the work and coordinate the changes needed in each codebase.ブログ未掲載のコマンドも含めた全体像
公式ブログで取り上げられているのは代表的な6つですが、GitHub Docsのリファレンスには40種類以上が掲載されています。用途ごとに整理すると、全体像がつかみやすいと思います。
- セッション管理: /clear（/reset）で履歴を消して新しいセッションを開始、/compact で会話の前半を要約してトークン消費を抑制、/fork で現在のセッションを分岐、/merge-to-parent で分岐した作業を元のセッションへ統合
- プルリクエスト操作: /pr-open でセッションの変更からプルリクエストを作成、/pr-fix-checks で失敗したチェックへの対応、/pr-resolve-comments でレビューコメントへの対応、/pr-merge でマージ
- レビュー・検証: /review でセッションの変更をレビュー、/security-review で差分に対するセキュリティ観点のレビュー
- 履歴の活用: /chronicle 系コマンドでセッション履歴の検索や、/chronicle standup による前日作業の要約、/chronicle cost-tips によるトークン削減の提案
- 環境・設定: /model でモデル選択、/agent でカスタムエージェントの指定、/init でリポジトリ用の指示ファイル生成、/usage で利用状況とレート制限の確認
なお、コマンドによっては動作条件があります。たとえば /pr-merge はマージ可能なプルリクエストが存在すること、/pr-open は変更を含むアクティブなセッションがあることが前提です。GitHub Docsでも、利用できるコマンドの一覧は変わり得るため、現在の状況で使えるものを確認するには実際に / を入力するのが確実だと案内されています。
まとめ
スラッシュコマンドは、モード切り替えや定型ワークフローの起動を短い入力で済ませる仕組みです。全部を覚える必要はなく、自分の作業に合うものから試していくのが現実的だと思います。PlanモードとAutopilotの実際の使い分けは、過去記事でも具体例を整理していますので、あわせてご覧いただければと思います。
