こんにちは。ACS事業部の越川です。
先日、社内で開催された「ゆるっと GitHub Copilot 活用トーク」というイベントにスピーカーとして参加してきました。金曜の夕方、ゆるい雰囲気の中でGitHub Copilotの活用法を語り合うという会です。トークの中心はリリースされたばかりのGitHub Copilot CLIで、今回はその様子と気づきを共有します。
- GitHub Copilot CLIとは
- イベントの概要
- GitHub Copilot CLIとの出会い
- 活用スタイルの違いが面白い
- AIとの付き合い方で共通していたこと
- LLMが苦手な領域とその対策
- おわりに
- ACS 事業部のご紹介
GitHub Copilot CLIとは
GitHub Copilot CLIは、2026年2月にGA（一般提供）されたターミナルベースのAIコーディングエージェントです。VS Codeなどのエディタを開かずに、ターミナルから直接コードの変更、デバッグ、Git操作などを自律的に行えます。詳しくは弊社ブログのGitHub Copilot CLI 入門記事もあわせてご覧ください。
イベントの概要
「ゆるっと GitHub Copilot 活用トーク」は、GitHub Copilot CLIを積極的に活用しているメンバーの活用法を聞こう、という趣旨で突発的に企画されたイベントです。
- 形式: ファシリテーター1名 + スピーカー2名のQ&A対談
- ギャラリー: 10数名の社員が参加
- 雰囲気: タイトル通り「ゆるっと」。金曜夕方の気軽な場
ファシリテーターが質問を投げかけ、私ともう一人のスピーカーがそれぞれの活用法を答えていく形式で進みました。
GitHub Copilot CLIとの出会い
最初の質問は「GitHub Copilot CLIを使い始めたきっかけ」でした。
私の場合、GitHub Copilot CLIがリリースされた日に触って「これは仕事で使える」と確信したのがきっかけです。プライベートでは以前からCLIベースのAIコーディングツールを使っていたので、同等の体験が業務でもできるようになったことに興奮しました。
もう一人のスピーカーは、元上司からAIエージェントの話を聞いたことがきっかけだったそうです。
導入の経緯は違いましたが、二人とも共通していたのは「使い始めてから、自分でコードを書くことがほとんどなくなった」ということ。コードを書く作業はAIに任せ、自分の役割は確認・レビューに変わったという実感を共有しました。
活用スタイルの違いが面白い
トークが盛り上がったのは「お気に入りの使い方・カスタマイズ」の話題でした。ここで二人のアプローチの違いがはっきり出ました。
私のスタイル：全部インストラクションに書く派
私はプロジェクトごとに物理フォルダを分け、最初にインストラクションファイルを作成するところから始めます。AIとの対話（壁打ち）で方針を固めることに重点を置いています。
特徴的なのは、意図的にスキル機能を使わず、すべてをインストラクションに記述している点です。理由はシンプルで、コンテキストの切り替えコストを最小限にしたいから。インフラ、コーディング、ドキュメント作成のすべてでAIファーストのアプローチを取っています。
また、モデルの賢さを最も重視していて、常に最新のモデルを使うことが一番大事だと考えています。カスタマイズは最低限に抑え、モデルの能力に頼るスタイルです。
もう一人のスタイル：安全重視のカスタマイズ派
もう一人のスピーカーは、GitHub Copilot CLIのdenyオプションを活用して、リポジトリへのプッシュなど安全上の懸念があるコマンドをあらかじめ制限するという工夫をしていました。
カスタムインストラクションには、案件の担当者や権限情報を組織単位で設定し、エージェントが適切な提案をするようにしているとのこと。定型的な作業（Azureカスタムロール作成など）はスキル化して、組織単位でリポジトリを管理する仕組みを構築していました。
私がスキルを使わない派なのに対し、もう一人は積極的にスキル化する派。真逆のアプローチですが、どちらも「自分の業務に最適化する」という目的は同じです。この対比はギャラリーの皆さんにも面白く感じてもらえたようでした。
AIとの付き合い方で共通していたこと
スタイルは違っても、根底にある考え方には共通点がありました。
AIファーストで始める
二人とも、まずAIに計画を立てさせるところから業務を始めます。「自分で考えてからAIに手伝わせる」ではなく、「AIに最初のたたき台を出させて、そこからレビューする」というアプローチです。
「刻む」ことの大事さ
ファシリテーターが言った「刻む」という表現が印象的でした。もう一人のスピーカーは、ドキュメントを書かせる前に、まず制約事項を細かく設定してアジェンダ案を先に確定させるという手法を共有してくれました。いきなり完成形を求めるのではなく、段階を踏むことでAIの出力品質が大きく上がるという実感は私も同じです。
「自分で説明できるもの」という線引き
もう一人のスピーカーが語った、お客様への納品物に対する考え方も印象に残りました。「自分で説明できるものしか納品しない」という原則です。AIが生成したコードやドキュメントであっても、自分が理解し説明できなければ使わない。AIを使いこなしているからこそ、この線引きが明確でした。
LLMが苦手な領域とその対策
トークの中では、GitHub Copilot CLIに限らずLLM全般に共通する苦手分野についても話題になりました。
- 画像の判別系: 色やフォントの細かい指定は精度が落ちる
- 時間の概念: 日付や曜日を間違えることがある
これらはGitHub Copilot CLI固有の問題ではなく、現在のLLMが構造的に抱える弱点です。私は時間の間違いを防ぐため、インストラクションに「日付を扱うときはdateコマンドで現在日時を確認する」というルールを書いています。LLMの特性を理解した上で、こうした小さな工夫を積み重ねることが、AIとの協業を安定させるコツだと感じています。
おわりに
1時間弱のトークでしたが、同じツールでもここまで使い方が分かれるのかという発見がありました。「スキルを使い込む派 vs インストラクションに全部書く派」の対比は、どちらが正解というわけではなく、自分の業務スタイルに合わせて最適化していくもの。それだけGitHub Copilot CLIの懐が深いということでもあります。
こうしたツールの活用法を気軽に共有し合える場が社内にあるのは、エンジニアとしてとてもありがたい環境だと感じています。この記事が、皆さんのGitHub Copilot CLI活用のヒントになれば幸いです。
ACS 事業部のご紹介
私の所属する ACS 事業部では、開発者ポータル Backstage、Azure AI Service などを活用し、Platform Engineering ＋ AI の推進・内製化を支援しています。
www.ap-com.co.jp www.ap-com.co.jp www.ap-com.co.jp
また、GitHub パートナーとしてお客様に GitHub ソリューションの導入支援を行っています。 GitHub Copilot などのトレーニングなども行っておりますので、ご興味を持っていただけましたらぜひお声がけいただけますと幸いです。
一緒に働いていただける仲間も募集中です！ ご興味持っていただけましたらぜひお声がけください。
