Azure IaaS サポートエンジニアから Azure 製品営業にロールチェンジしたTomoyaです。
（IaaS には、Azure VM（OS含む）、Azure Storage 管理、Azure ハードウェア基盤などが含まれます）
私個人が思っていることを綴った記事です。
はじめに（結論）
まず、結論から申し上げると、私は世の中のコードから生まれる全ての製品のサポート、職種名でいうとテクニカルサポートエンジニアといわれるような人には GitHub Copilot を全員に使ってほしいと思っています。（暴論）
理由はシンプルで、Github Copilot は「開発者のための道具」であることはもちろんですが、むしろ、サポートという “見えないゴールを探索する仕事” を加速する道具として素晴らしい相方になると考えています。
サポートエンジニアの仕事の実態
「サポートエンジニアは社内情報見て、ソースコード読んで、そこからすぐにトラブルシューティングできるデショ」とお客様や非技術職の人などから思われていることが多いですが、実態はかなり泥臭い お仕事です。
- 状況整理（何が起きてる？いつから？何が変わった？）
- 切り分け（原因候補を並べて、潰していく）
- 検証（コマンド実行、ログ確認、再現）
- 連絡（顧客への依頼、進捗、結論）
- エスカレーション（上位部隊に投げるためのサマリ作り）
- ナレッジ化（同じ問題、事故を減らす）
そして、サポートエンジニアの時間・精神を消耗するのは「難しい判断」よりも、「反復作業」と「文章作成」です。
回答文を作成するのはもちろんのこと、回答前のレビュー、エスカレーションするときは詳細な調査内容を順を追って作成し、上位部隊に伝えるための文章作成なども行います。
これらが１つのケースで何度も繰り返されます。
同じような問い合わせでも、毎回状況が "微妙" に違うため、完全にテンプレ化できない上、テンプレ化できないので、毎回 “書き直し” が発生します。
このようなことから、地味にHP（体力）が削られていきます。
「その気持ちわかるぅ」と思っていただける方に GitHub Copilot を使ってほしいです。
サポートエンジニアの価値
持論ですが、市場価値の高いサポートエンジニアは「正解を知ってる」より「最短で正解にたどり着ける」スキルを持ち合わせる人だと思っています。
サポートの価値（勝ち筋）は、博識さ（知識量）だけじゃないということかなと。
当然、知識は武器ではありますが、現場で必要とされるサポートエンジニアは、知識量と正解にたどり着くまでの思考に長けていると思います。
１文でまとめるとこんな感じ。
「不確実性の霧の中で、最短距離で原因に寄っていける力」
現実の問い合わせはだいたいこういう性質を持っています。
- 情報が足りない（再現手順が曖昧、ログがない、環境情報が不明瞭）
- 事象が複雑（複数コンポーネント、複数変更点）
- 解決までの時間的制約に縛られる（影響範囲、優先度、顧客の温度感）
- “確率”で動く必要がある（100%の確信を持ってから行動すると遅い）
つまり、サポートの仕事は「答え合わせ」ではなく、 探索のお仕事 かと思います。
探索を速く回せる人が強く、探索のループ回数を稼ぎつつ、無駄打ちを減らせる人が強いというのが価値あるサポートエンジニアです。
ここで重要なのは、「知ってること」だけで勝負しないこと。
現場では、知識があっても情報が足りなければ答えまでたどり着けないし、逆に知識が薄くても探索の回し方が上手ければ、答えに早く寄って行けるかなとおもいます。
私はどちらかというと回し方（ハンドリング力）でどうにか仕事をしていました…。
GitHub Copilot は何を速くするのか？
GitHub Copilot を コードを書くためのAI としてだけ見ると、サポート業務では過小評価しがちです。
（当たり前である）
しかし、実際は、サポートが苦しみがちな作業をかなり得意としています。
- ログ調査の補助（大量なログバンドルからサマリ分析、ログ解析結果の壁打ち）
- 叩き台を作る（文章、手順、コマンド、チェックリスト）
- 観点を増やす（原因候補、確認ポイントの洗い出し）
- 形式を整える（エスカレーションサマリ、ナレッジ構成、説明文）
要するに、サポートエンジニアの業務の中で行う、探索ループ処理 で発生する 「ログの分析」「手を動かすだけの工程」 の時間・思考を圧縮できます。
探索ループの中身を理解すると分かりやすい
サポートの探索ループをざっくり書いてみます。
- 仮説を立てる
- 確認手段を決める（何を見る？何を聞く？何を実行する？）
- 実行して証拠を集める
- 仮説を更新する
- 顧客に共有する（依頼・進捗・結論）
GitHub Copilot は１〜５どのフェーズでも効果を発揮できます。
仮説を立てるときに、いくつかの案の中から確率が高そうなものを壁打ちして選択し、
仮説のもと、対象となるログバンドル（ログファイルの集合体）を一括で Agent mode で調査する。仮説に誤りがあれば、再度仮説を壁打ちし直し、顧客向けの文章をGithub Copilot に考えてもらう。こういった使い方をすると、探索ループ全体の効率化が見込めます。
壁打ちの際には、「どんな観点があるか」を先に視野を広げてくれるので、ジュニアなサポートエンジニアの人でも、視野が広がることにより、確認漏れの確率も下がります。
（もちろんゼロにはならない。そこは現実）
人間は判断と責任、AIは壁打ちと反復：分業が一番強い
GitHub Copilot は優秀ですが、サポートエンジニアの現場でやらかしやすい罠があります。
- それっぽい嘘（存在しないコマンド、微妙に違う設定名）
- 断定口調の文章（顧客向けに送ると事故る）
- 前提の取り違え（OSや権限、構成を勝手に補完する）
そのため、役割分担を決めるのが安全です。
人間がやること
事実確認、優先度判断、仮説の採択、リスク判断、顧客への最終表現、責任を持つ決定
AIにやらせること
叩き台作り、観点列挙、テンプレ生成、文章整形、反復作業の短縮
- GitHub Copilot を「正解製造機」にすると事故ります。
- GitHub Copilot を「下書き製造機」にすると猛者になれます。
この違いは言われたらそりゃそうだよね、と思うかもしれませんが、結果に直結します。
X とかでもよく、「ChatGPTはこう言ってますよ？」という投稿見かけますよね。
愚かな発言だな、と日々思います…
探索ループ効率化で 「次の一手」 の高速化
私は、GitHub Copilot の活用で本当に変わるのは、
作業時間が数分減ることだけではなく、以下の点があると考えています。
- 初動の返信が速くなる（必要情報の依頼文を早く出せる）
- 仮説の壁打ち回数が増加するため
- 切り分けが整理される（観点の棚卸しが早い）
- 異なる視野からの助言をもらえるため
- 上位エスカレーション時のスムーズさ（必要情報が早く揃う）
- 多くの視野からの見解を得ることができるため、必要情報が早めに揃った状態になる
- ナレッジ化が進む（解決を資産にしやすい）
- どういうプロセスで思考したのかが GitHub Copilot とのやり取りに残る
つまり、「次に何をすべきか」を決めるまでの時間が短くなります。
サポートは“次の一手”が遅いほど苦しくなる仕事なので、ここが縮む恩恵は大きいです。
極端に言うなら、サポートの仕事は「入力（情報）」と「出力（判断と次の一手）」の往復ですので、
GitHub Copilot はこの往復を補助してくれるため、回転数が上がるイメージかと思っています。
使う前に決めておく安全ルール（最低限）
ここまで読んで「じゃあ何でも投げればいいじゃん」と思った人に、釘を刺しておきますが、サポートは信頼業なので、安全運転が大前提です。
- 機密情報は入れない（顧客情報、契約、トークン、内部情報）
- 出力は検証する（公式ドキュメント、実行結果、実ログで裏取り）
- 断定口調は自分で直す（顧客向け文面は特に）
- 前提を明確にして依頼する（OS・環境・制約・目的）
これを守ると、GitHub Copilot は “危ない近道” ではなく、安全なショートカットになります。
まとめ：Copilot を使うべき理由（サポート視点で）
最後に、言いたいことをまとめますが、世の中にはソフトウェア製品が溢れる昨今、それに付随してサポートエンジニアと呼ばれる製品を守る人たちがたくさんいます。
どのような会社であっても、「AIを使ってサポートを効率化できないのか」というお達しが上から降ってくることは必然ですので、私の思っていることを綴りました。
- サポートの価値は「正解を知ってる」より「最短で正解にたどり着くこと」
- GitHub Copilot は 正解にたどり着く速度を上げる
- 人間は判断と責任、AIは下書きと反復 で分業すると強い
AI は魔法ではありませんが、サポートの “地味にHPが削られる重い仕事” を粉砕するハンマーではあると思います。
みんな Github Copilot 早く使おうぜ！！
** 第2部につづく：じゃあ具体的に何ができるの？
次の第2部では、実際に「サポートのどの場面で、どう使うと効果的か」をユースケースでご紹介したいとおもっています。初動ヒアリング、切り分け、ログ観点、など。
（いつになるか、、、）
Tomoya
Discussion