Teamsから修正を頼める時代、影響する場所はどう見つける？─GitHub Copilotから考えたこと

こんにちは、GDX株式会社でAIリサーチを担当しているMia Sato（佐藤ミア）です。

最近、GitHub CopilotとMicrosoft Teamsの連携についてのニュースを読みました。Teamsに届いた不具合の通知から、AIに原因の調査や修正を依頼できるというものです。

最初は「Teamsからそのまま修正をお願いできるなら便利そう」と思いました。私も開発中の画面についてTeamsで意見をもらい、話し合いの結論を整理して、別のツールで指示し直すことがあります。

でも、少し考えてみると、気になることがもう一つありました。変更内容がうまく伝わっても、その修正がほかの画面や機能にどう影響するのか、依頼する側はどこまで分かっているのでしょうか。

この連携はECサイト専用の機能ではなく、GitHubでコードを管理しているWebサイトやアプリなど、幅広い開発で活用できるものです。

そこで今回は、私たちに身近なECサイトの運用を例に、「直しやすくすること」と「安心して直すこと」の違いを考えてみたいと思います。

Teamsの会話から、修正案を作るところまで

GitHubは2026年10月23日、Microsoft Teams向けアプリの更新を発表しました。GitHubは、プログラムや変更履歴をチームで管理するためのサービスです。今回の更新では、GitHubからの通知と、Copilotへの作業依頼をTeams上でつなげやすくしています。

たとえば、不具合の報告がGitHubに登録され、Teamsに通知が届いたとします。その会話で@GitHubに原因の調査や修正を頼むと、Copilotが報告や関連するやり取りを手がかりに作業を進めます。

修正した内容は、チームが確認するための「Pull Request（プルリクエスト）」として提出されます。「このように直したので確認してください」という提案のようなものです。AIが作業を進めても、そのまま公開中のサイトが書き換わるわけではありません。

 

図：GitHubの公式発表をもとに作成した、Teamsの通知から修正案の確認までの流れ

GitHubの説明では、Teamsでの会話を参考に調査や変更を進め、テストを実行することも想定されています。作業の計画や変更したファイルを確認できる仕組みもあります。

私が面白いと感じたのは、Teamsで問題の通知を確認した人が、その後の調査や修正の進み具合にも関われることです。単に作業を依頼するだけでなく、修正案ができるまでの流れを同じチームで共有しやすくなる点にも、便利さを感じました。

「伝え直す仕事」は、単なるコピーではない

普段のTeamsのやり取りは、最初から完成した修正指示になっているわけではありません。

「このボタンが分かりにくい」という相談から始まり、色を変える案が出たあと、配置を変える方がよいと決まることがあります。修正を頼むときには、途中で出た案ではなく、最終的に決まった内容と条件を伝えなければなりません。

私も会話を読み返し、「どこを変更するか」「何はそのままにするか」をまとめています。考えてみると、これはただ文章を短くするのではなく、複数の意見から結論を選ぶ作業でもありました。

Copilotが会話全体を参考にできるとしても、途中の提案を最後の決定と取り違えないとは限りません。だから、会話の最後に「今回はこれで決定」と残しておくことは、これからも大切だと思います。

ただ、AIが修正内容を正しく理解できたとしても、その変更がほかの機能に影響しないとは限りません。

一か所を直すと、どこまで変わるのだろう

ECサイトでは、画面に見える小さな変更が、別の機能につながっていることがあります。

たとえば、キャンペーンの割引表示を変更したいとします。商品ページの見せ方だけを直せば終わりに見えても、カートでの金額計算やクーポンの条件、注文確認画面の表示にも関係するかもしれません。

実際の買い物は一続きなのに、システムの中ではいくつもの処理が関わっています。修正した画面だけを見て「直った」と判断するのは、少し怖い気がします。

しかも、そのつながりを今の担当者がすべて把握しているとは限りません。長く使っているサイトほど、何度も機能が追加され、担当者が変わっていることもあります。「なぜこの条件になっているんだろう」と思っても、当時の判断を知る人がもういない、という状況も考えられます。

私は普段、目の前の画面で何を変えたいかを考えがちです。でも、見えていない部分にどんな影響があるかは、画面を使っているだけでは分かりません。開発に詳しい人なら分かる、とも簡単には言えないと思います。以前の設計意図が記録されていなければ、誰にとっても確認が難しいからです。

だから、修正を自然な言葉で頼めるようになるほど、実際に変更する前に「ほかに何を確認する必要があるか」を知ることが重要になりそうです。

AIに「直し方」だけでなく「調べる場所」も聞けたら

こうした問題を考えると、私がAIに期待したいのは、修正案を作る前に、関連するプログラムや過去の変更履歴を調べてくれることです。

たとえば、変更する部分がほかの機能からも使われていないか、同じ情報を参照している処理がないか。そうした関係をAIが調べ、影響する可能性のある箇所を整理してくれたら、担当者が気づいていなかった部分も確認しやすくなりそうです。

さらに、なぜその箇所に影響があると考えたのか、根拠となるプログラムや過去の変更内容まで示してくれたらどうでしょうか。単に「ここも確認してください」と言われるより、理由が分かれば、私自身も内容を理解しながら判断できそうです。

もう一つ助かりそうなのは、変更後のテストについての提案です。たとえば、通常の購入では問題がなくても、複数の割引条件が組み合わさった場合はどうなるのか。普段の操作だけでは気づきにくいケースまで確認できれば、修正案をより慎重に評価できると思います。

もちろん、今回のGitHubの発表は、AIがすべての影響を自動で把握できると保証しているわけではありません。社内の運用ルールなど、プログラムだけでは分からないこともあります。

だからこそ、AIが調査した結果だけでなく、まだ確認できていない部分も分かるとよさそうです。開発担当者は技術的な影響を、EC運営担当者は実際の業務への影響を確認するなど、それぞれの視点を持ち寄って判断できます。

これまで修正を依頼するときは、「どう直してほしいか」を伝えることに意識が向いていました。でも、AIが調査の段階から手伝ってくれるなら、「なぜそこを確認する必要があるのか」まで理解しながら進められるかもしれません。私はそこに、単に作業を速くすることとは違う価値を感じました。

「早く直せる」ことが、安心につながるために

修正を頼みやすくなれば、これまで後回しにしていた小さな改善にも取り組みやすくなりそうです。ただ、変更が増えるほど、どこまで確認し、その結果をどう残すかも大切になると思います。

たとえば、修正した内容だけでなく、どの機能に影響する可能性があり、何をテストしてどんな結果だったのか。そうした記録が残っていれば、次に担当する人も過去の判断をたどりやすくなります。

もしAIが、こうした確認結果を整理して残すところまで手伝ってくれるなら、次の修正にも役立ちそうです。担当者が変わっても、過去の経緯を一から調べ直さずに済むことには、長く運用するECサイトならではの価値があると思います。

今回のニュースを見たときは、「Teamsから簡単に修正を頼める」ところに目が向きました。でも今は、変更前に影響範囲を確認し、変更後に判断の根拠を残せることにも、大きな価値があると感じています。

AIが修正を速くするだけでなく、安心して改善を続けるための情報も整理してくれたら。長く使うECサイトにとって、そんな使い方も大切になっていくのかもしれません。

参考・引用

• GitHub Changelog「Turn notifications into code with GitHub Copilot in Teams」（2026年10月23日）
  https://github.blog/changelog/2026-10-23-turn-notifications-into-code-with-github-copilot-in-teams/
• GitHub Changelog「Shared agentic work with GitHub Copilot in Microsoft Teams」（2026年8月21日）
  https://github.blog/changelog/2026-08-21-shared-agentic-work-with-github-copilot-in-microsoft-teams/
• GitHub Docs「Integrating Copilot cloud agent with Teams」
  https://docs.github.com/en/copilot/how-tos/copilot-integrations/integrate-cloud-agent-with-teams