GitHub Copilot CLI 実践テクニック共有会 でスキル運用についてLTしました
はじめに
5月25日に GitHub Copilot CLI を装備せよ 〜実践テクニック共有会 LT Night〜 というイベントに参加し、LT登壇しました。GitHub Copilot CLI がマッスルに馴染むまで というタイトルで、既存のAIコーディングエージェント運用にどう Copilot CLI を組み込んでいくかという話をしました。
内容
最近の AI コーディングエージェント界隈は、Claude / GitHub Copilot ともに料金体系の見直しによる従量課金への移行が続いています。
結果としてモデルごとの価格と性能のトレードオフを意識して使い分ける場面が増えると考えています。
手元では Claude Code を中心に tmux で複数エージェントを並走させる構成[1]を組んでおり、ここに GitHub Copilot CLI を「もう一本のハーネス」として組み込むのが今回のテーマです。
昨年からありますが、複数ハーネスを並走させ始めるとすぐにぶつかるのが、各ツールごとに設定や運用ルールがバラけてしまう問題です。プロンプト・コマンド・MCP 設定などをハーネスごとに書き直していると、運用負担がリニアに増えていきます。ただスキルに関しては標準化の影響もあり、現状かなり改善しています。スキルエコシステムについて見ていきます。
GitHub Copilot CLI は スキルとメモリ(instruction)の探索パスが広いです。
スキルの管理はスコープを「ユーザー」と「プロジェクト」で分けて考えています。ユーザースコープは自分の作業環境全体で使い回すもの、プロジェクトスコープはリポジトリに紐付くものです。例えば googleworkspace/cli はユーザーに紐づくことが多いと思います。
ユーザースコープ側は Nix と Renovate を組み合わせて、スキルの導入と更新を宣言的かつ自動化しています。手元の dotfiles 同様、入れたいスキルをコードで宣言しておけば、新しいマシンでも同じ環境がそのまま再現できます。~/.agents/skills で Codex, OpenCode, GitHub Copilot CLIが設定されます。標準化ありがとうございます。
プロジェクトスコープでは複数の選択肢が考えられます。今時点では microsoft/apm を使うのが良いと思います[2]。
リポジトリにスキルを取り込みつつバージョンを commit SHA でピン留めし、Renovate で自動追従しています。
スキルのfetchがシーケンシャルなので大量にある場合体験に影響があります。そのためuser scopeで不採用とした経緯があります。
まとめとしては、GitHub Copilot CLI 単体の機能紹介というより、複数ハーネス時代の運用をどう薄く保つかという話に寄せた構成にしました。GitHub Copilot CLI のサポート範囲は思った以上に広く、既存のスキル資産をそのまま乗せやすかったのが今回の良い発見です。
さいごに
他の登壇者の方の発表では、Copilot CLI のコンテキスト管理を継戦能力という観点で整理する話、M365 Work IQ と組み合わせる活用ネタ、CLI であることを活かした使いこなし、SDK と A2A プロトコルで複数 Copilot を協調させる話、Rubber Duck 機能を品質向上に使う話、Copilot app による開発体験の変化、IDE / Web / スマホをまたいだ開発フローの話など、切り口が幅広く非常に学びの多い回でした。詳しくはイベントサイトをご覧ください。
DHH の画面構成を参考にしたペイン分割など、tmux まわりの工夫はこちらにまとめています。 https://dev.classmethod.jp/articles/shuntaka-claude-code-tmux-personal-tips/ ↩︎
apm でのスキル管理と Renovate による自動追従の構成は別記事にまとめています。 https://dev.classmethod.jp/articles/shuntaka-apm-agent-skills-renovate/ ↩︎
