画面をそのまま渡せるようになった
GitHub Copilot の 2026 年 7 月リリースで、Copilot Vision が正式提供 になりました。チャットに画像と PDF を添付できます。
公式の案内はこの一行です。
Add images and PDFs to chat: Copilot vision is now generally available.
使う人からすると、変わるのは「説明し直す手間」です。エラーの画面を見ながら、その内容を文字に起こして貼り直す。図で示された設計を、言葉で説明し直す。この作業が要らなくなります。
小さく見えますが、説明できないから相談しない、という状態がなくなる のは大きい変化です。うまく言葉にできない場面ほど、助けが要る場面でもあります。
実際に効く場面
使う人の側から見て、効きそうなのは次のような場面です。
エラー画面をそのまま渡す。 ログをコピーできない画面や、複数の情報が同時に出ている画面では、文字に起こす作業が重くなります。撮って渡すほうが速く、抜け漏れもありません。
設計の図を渡す。 画面の構成を言葉で説明するのは、思っている以上に難しい作業です。「左に一覧、右に詳細、上に検索」と書いても、余白や比率までは伝わりません。図があれば一度で済みます。
資料の PDF を読ませる。 仕様書や要件の資料を渡して、内容についてやり取りできます。該当箇所を探して貼り直す手間が減ります。
表やグラフを読ませる。 数字が並んだ画像は、文字に起こすのがいちばん面倒な種類の情報です。そのまま渡せると、転記の手間と写し間違いの両方がなくなります。
コツ
効果が分かりやすいのは、説明に時間がかかっていた場面 です。逆に、もともと文字で足りていた作業では変化を感じにくいはずです。
渡す前に見てほしいこと
便利な反面、気をつけていただきたい点があります。画面のスクリーンショットには、思っていないものが写ります。
よく写り込むのは、次のようなものです。
- 他のタブやウィンドウのタイトル
- 通知に出ている相手の名前や本文の冒頭
- 開いているファイルのパスや、プロジェクト名
- 顧客名や案件名が入った画面の一部
本人は問題の箇所だけを見ているので、周りが目に入りません。 これは注意力の問題ではなく、見たいものに集中しているときに自然に起きることです。
対処は簡単で、全画面ではなく必要な範囲だけを切り取る 習慣にしておくことです。範囲を選ぶ操作を挟むだけで、写り込みはほとんど防げます。
業務で使う場合は、この一言をチームで共有しておくと安心です。禁止のルールにする必要はなく、「範囲を切って渡す」と伝わっていれば足ります。
もう 1 つ、渡した画像がどこまで残るか は、契約しているプランによって扱いが変わります。個人で使うぶんには気にならなくても、業務のデータを写した画像となると話が別です。社内で使うことになったら、そこは一度確認しておいてください。この観点は 生成 AI 情報漏洩対策と社内利用チェックリスト にも整理しています。
PDF を渡すときの向き不向き
PDF も渡せるようになりましたが、こちらは向き不向きがはっきりしています。
向いているのは、図や表が中心の資料 です。文字だけの資料なら、本文をコピーして貼るほうが確実で速い場面もあります。わざわざ PDF にする必要はありません。
向いていないのは、非常に長い資料 です。全体を渡して「まとめて」と頼むより、該当する章だけを切り出して渡すほうが、返ってくる内容が具体的になります。範囲を絞る手間はかかりますが、やり取りの回数が減るぶん早く終わります。
もう 1 点、渡した資料の中身がそのまま扱われる ことは意識しておいてください。社外秘の資料をまるごと渡す前に、社内の利用ルールを確認します。この判断は画像と同じです。
会話を分岐できる peer chat
もう 1 つ、進め方に効く機能が入っています。peer chat です。
公式にはこう書かれています。
Fork into a peer chat: Explore a different approach from any point in your conversation.
会話の任意の地点から分岐して、別の進め方を試せます。使う人からすると、「戻れる」という安心感 が大きい機能です。
これまでは、方針を変えたいときに 2 つの選択肢しかありませんでした。今の会話の続きで方針転換を伝えるか、新しく始め直すか。前者は経緯が混ざって伝わりにくくなり、後者はそれまでの前提を渡し直す手間がかかります。
分岐できると、この間が取れます。元の流れを残したまま、別案だけを試せます。 気に入らなければ元に戻ればよいので、試すこと自体の心理的な負担が下がります。
FIXIT
Hinata途中で「やっぱり別の方法かも」と思う場面、けっこうありますよ。
FIXITHinataその面倒がなくなる機能です。戻れると思うと、試しやすくなります。
Agents ウィンドウの刷新
エディタ部分の設計も変わりました。会話の隣にファイルや差分を開けるようになっています。
Review code alongside chat: The editor panel has a new design. Open files and diffs next to your conversation.
加えて、関連するセッションをグループ化して並べ替えられるようになりました。BYOK のモデルも Agents ウィンドウで使えます。
いずれも、行き来の回数を減らす方向 の変更です。会話を読んで、成果物を見に行って、また会話に戻る。この往復が減ると、確認する回数が自然に増えます。
使う人の側から見ると、ここが実は効きます。確認しやすくなると、確認するようになります。 見に行くのが面倒な状態では、結果だけ受け取って先へ進んでしまいがちです。
セッションのグループ化も、同じ方向の変更です。作業ごとに会話が散らばると、前に何を話したかを探すところから始まります。まとめて並べ替えられると、続きから再開しやすくなります。
小さな改善に見えますが、道具が使われるかどうかは、こういう部分で決まることが多くあります。機能が足りないから使われないのではなく、面倒が積み重なって離れていく ほうがずっと多いです。
デザインと実装のあいだで使う
わたしの立場から見て、いちばん効きそうなのはここです。デザインと実装のあいだのやり取り に画像が使えるようになります。
これまでは、画面の意図を言葉にして渡していました。「ここの余白をもう少し」「この文字はもう少し落ち着いた色で」。伝わることもありますが、認識がずれたまま進むこともよくあります。
画像を渡せると、基準そのものを共有できます。 完成イメージを見せて「これに寄せてください」と言えるほうが、言葉を重ねるより早いです。
逆方向も同じです。実装された画面を撮って「ここが想定と違う」と渡せば、どこを直すかがすぐ決まります。文字で場所を説明する作業が消えます。
コツ
比べたい 2 枚を並べた 1 枚の画像にして渡すと、差が伝わりやすくなります。左が想定、右が現状、のような形です。
ただし、渡し方には少し気をつけてください。画像だけを渡して察してもらおうとすると、意図が伝わりません。 見てほしい箇所と、どうしたいのかを一言添える。この一手間で、返ってくる内容が変わります。
使い始める順番
新しい機能が 3 つ同時に来ると、どれから触ればよいか迷います。画像から始めるのがいちばん分かりやすいです。
理由は、効果がその場で分かるからです。エラー画面を撮って渡す。それだけで、今まで文字に起こしていた作業が消えます。1 回で違いが体感できます。
| 機能 | 試す順番 | 分かりやすさ |
|---|---|---|
| 画像・PDF の添付 | 1 番目 | その場で違いが分かる |
| Agents ウィンドウ | 2 番目 | 使っているうちに慣れる |
| peer chat | 3 番目 | 迷う場面が来たときに効く |
peer chat を最後にしているのは、必要になる場面が来ないと価値が分からない ためです。知識として知っておいて、迷ったときに思い出せれば十分です。
なお、3 つ全部を使いこなす必要はありません。画像だけ使っている状態でも、十分に元は取れます。 機能が増えたときに全部覚えようとすると、かえって手が止まります。
期待しすぎないほうがよい部分
前向きな話が続いたので、見込みすぎないほうがよい点も書いておきます。
画像を渡せば意図まで汲んでくれる、わけではありません。 画面に何が写っているかは読み取れますが、それが「良いか悪いか」の判断は、こちらが基準を伝えないと出てきません。デザインの相談で使うなら、何を良しとするかは自分の側にあります。
手書きのメモや、写真で撮った紙の資料は、読み取りの精度が落ちます。 きれいに撮れていないものを渡して要領を得ない答えが返ってきたら、まず画像の質を疑ってください。
画像が増えるほど、やり取りは重くなります。 何枚も貼れば伝わるというものでもありません。1 枚に絞って、見てほしい箇所を添えるほうが結果は良くなります。
いずれも、渡し方の工夫で埋まる範囲 です。機能の限界というより、使い方の慣れの問題だと考えてください。
チームへ伝えるとき
新機能の共有は、機能名だけを並べても伝わりません。使う場面と一緒に伝えてください。
たとえば、次のような書き方です。
- 「エラー画面をそのまま貼れるようになりました。文字に起こさなくて大丈夫です」
- 「途中で別の方法を試したくなったら、その場から分岐できます」
- 「会話の隣にコードを出せるので、見に行かなくて済みます」
機能名ではなく、いつもやっている面倒がどう減るかを書く。 これだけで読まれ方が変わります。
伝える相手も選んでください。全員に一斉に流すより、その面倒に実際にぶつかっている人へ個別に伝えるほうが、使われ始めます。 エラーの説明に困っていた人、画面の相談に時間をかけていた人。心当たりのある顔が浮かぶなら、そこから始めるのが早道です。
導入したてのチームでは、こういう小さな案内の積み重ねが定着を左右します。Copilot を使い込む側の話は GitHub Copilot を実プロジェクトで使い倒す 6 つのポイント にまとめています。
導入したてのチームで、ここから始めると入りやすい
新しい道具を配ったのに使われない、という相談をよく聞きます。その原因の 1 つが、最初のハードルの高さ です。
書き方を学んで、指示の作法を覚えて、それから使う。この順番だと、覚えるところで止まる人が出ます。
その点、画像を渡す使い方は入口として優秀です。特別な書き方を覚えなくても、撮って貼るだけで結果が返ってきます。 「うまく指示できないから使えない」という段差がありません。
導入の最初の一歩としては、次のような案内が入りやすいはずです。
- エラーが出たら、その画面を撮って貼ってみる
- 返ってきた内容を読んで、そのとおりにやってみる
- 違ったら、もう一度画面を撮って「こうなりました」と貼る
この 3 手だけで、やり取りが成立します。 ここで一度成功体験があると、そのあとの説明が入りやすくなります。
定着の進め方そのものは Claude Code を現場に定着させる進め方 にまとめていますが、考え方はツールを問いません。最初の 1 回をどれだけ簡単にするかが、その後を決めます。
画像を渡せることの、もう一歩先
少し先の話をすると、画像を渡せることの意味は「手間が減る」だけではありません。説明の負担が下がると、相談する人が増えます。
うまく説明できないから聞かない、という状態は、実は多くあります。デザインの意図をコードの人に伝えるとき、逆に実装の状況をデザインの人に伝えるとき。言葉にする段階で止まってしまう場面です。
画面を見せるだけで話が始められると、その手前の心理的な段差がなくなります。 これは職種をまたぐやり取りで、とくに効きます。
もっとも、渡せば伝わるわけでもありません。何を見てほしいのかは、一言添えたほうが確実です。 画面全体を渡して「どう思いますか」と聞くより、「この赤い枠の中だけ見てください」と添えるほうが、返ってくる内容が具体的になります。
まとめ
- チャットに画像と PDF を添付できる Copilot Vision が正式提供になった
- 効くのは「文字で説明し直す手間」が消えること。説明しにくい場面ほど差が出る
- スクリーンショットには意図しないものが写る。範囲を切って渡す習慣にする
- peer chat で会話を分岐でき、元へ戻れる状態のまま別案を試せる
- Agents ウィンドウの刷新で、会話と成果物の行き来が減った
- チームへ伝えるときは、機能名ではなく「どの面倒が減るか」を書く
- 導入したてのチームでは、画像を貼るところから始めると入りやすい