GitHub CopilotでDNS設定ゼロ、Pagesカスタムドメインを14分で公開
GitHub Copilot CLIでDNS設定ゼロ。GitHub Pagesカスタムドメインを14分で公開
カスタムドメインの取得とDNS設定は、多くの開発者にとって「最後の関門」だ。Aレコード、CNAMEエントリ、TTL（Time To Live / DNSキャッシュの有効期間）、そして「設定が反映されたのかどうかもわからない」という長い待ち時間。これらの煩わしさが、せっかくのプロジェクト公開を先延ばしにする原因になっている。
GitHub Blogで2026年7月8日に公開された記事によれば、GitHub Copilot CLIとコミュニティ製のNamecheapスキルを組み合わせることで、DNSレコードを手動で1行も編集せずに、約14分でカスタムドメインの設定からHTTPS化されたサイト公開までを完了できることが実証された。空のリポジトリから公開まで、わずか14分だ。
本記事では、このワークフローをステップごとに分解し、技術的な仕組みと実務への応用方法を解説する。DNSの知識がなくても理解できるよう、専門用語には都度説明を加えながら進める。
Copilot CLIがDNSの常識を変える、手動設定から自動化への転換
従来のDNS設定が抱える3つの課題
カスタムドメインをGitHub Pagesに紐付けるには、従来以下の作業が必要だった。ドメインを購入し、レジストラ（ドメイン管理会社）の管理画面でAレコードとCNAMEレコードを手動で追加し、GitHubリポジトリ側にもCNAMEファイルをコミットする。さらにDNSの伝播（設定がインターネット全体に行き渡るプロセス）を待ち、最大で48時間かかることもある。
この一連の作業には大きく3つの課題がある。第一に手順の複雑さだ。AレコードやCNAMEといったDNSレコードの種類を理解し、正しい値を入力する必要がある。第二にフィードバックの遅さ。設定が正しいかどうかの確認に長時間を要する。第三にミスのリスク。1文字でも間違えるとサイトが表示されず、原因特定にも手間取る。
Copilot CLIが解決するDNS設定の自動化
GitHub Copilot CLIは、自然言語での指示をシェルコマンドやAPI操作に変換するAIアシスタントだ。これにレジストラのAPIと連携するスキルを組み合わせることで、DNSレコードの読み取り・設定・検証までを自動化できる。
今回のワークフローでは、Namecheap（ドメインレジストラ）のAPIを操作するコミュニティ製スキル「namecheap-skill」を使用する。Copilot CLIに対して「このドメインをGitHub Pagesに向けて」と指示するだけで、スキルが必要なAレコードとCNAMEレコードを自動生成し、レジストラのAPI経由で設定する。さらにGitHubリポジトリ側のCNAMEファイルも自動でコミットする。
手動で6ステップかかっていたDNS設定が、自然言語の指示1行で完結する。ミスのリスクが排除され、待ち時間も大幅に短縮される点が最大の利点だ。
準備編、GitHub Pagesへの公開と格安ドメインの取得
ステップ1、GitHub Pagesでランディングページを公開する
まずは公開用のリポジトリを作成する。空のパブリックリポジトリを用意したら、index.htmlを手書きする必要はない。Copilot CLIに「このリポジトリでGitHub Pagesを有効にして、カスタムドメインに関するランディングページを作成して」と指示するだけで、HTMLの生成からPagesの有効化までを自動実行してくれる。
この時点でサイトは ユーザー名.github.io というURLで公開される。まずはデフォルトドメインでサイトが表示されることを確認し、次に独自ドメインの設定に進む。
ステップ2、低コストでドメインを取得する
サイドプロジェクトにプレミアムな .com ドメインは必須ではない。今回の検証では、最も安価なTLD（トップレベルドメイン / .comや.orgなどのドメイン末尾部分）のひとつである .click が選択された。購入費用はわずか2米ドル（約300円）だ。サイドプロジェクトでカスタムドメインを試すにはリスクの低い金額といえる。
Namecheapでドメインを検索し、利用可能な名前を選んで購入する。決済が完了すれば、次のステップでAPI経由のDNS設定に進む準備が整う。
Namecheap APIとCopilot CLIの連携でDNSレコードを自動設定
Namecheap APIアクセスを有効化する
Copilot CLIがDNSを操作するには、事前にNamecheapのAPIを有効化する必要がある。Namecheapの管理画面で「Profile → Tools → Business & Dev Tools」と進み、Namecheap API Accessの管理画面を開く。ここで3つの設定を行う。
- APIをONに切り替える
- APIを呼び出すマシンのパブリックIPを許可リスト（ホワイトリスト）に追加する
- APIキーをコピーして安全な場所に保管する
APIキーは後続のステップでCopilot CLIに入力するため、手元に控えておく必要がある。NamecheapのAPIを使うと、ドメイン一覧の取得やDNSレコードの読み書きをプログラムから実行できるようになる。
Namecheapスキルをインストールする
続いて、Copilot CLIにNamecheapと通信する能力を与えるスキルをインストールする。以下の1コマンドで完了する。
gh skill install github/awesome-copilot namecheap --scope userスキルのインストール後、Copilot CLIに対して「自分のNamecheapドメインを一覧表示して」と指示すると、初回実行時にAPIキーの入力を求められる。先ほど控えたキーを入力すれば、アカウント内のドメイン一覧が表示され、連携が正常に機能していることを確認できる。
この4ステップで、Copilot CLIがドメインレジストラのAPIを直接操作できる状態になる。従来のように管理画面を手動で操作する必要はない。
ドメインの紐付けと自動検証、すべてが14分で完了
Copilot CLIにドメイン接続を指示する
準備が整ったら、Copilot CLIに対して「このGitHub Pagesサイトでカスタムドメインを有効にして」と指示する。スキルは現在のDNSレコードを確認し、変更を適用する前に確認を求めてくる。これは重要な安全設計だ。誤ったDNS変更がサイトの表示停止につながるリスクを、人間の承認によって防いでいる。
承認後、スキルは以下の作業を自動実行する。
- Namecheapのパーキングレコード（未使用ドメインの仮レコード）を削除
- GitHub PagesのAレコード（IPアドレス指定）を登録
- WWWサブドメイン用のCNAMEレコードを追加
- リポジトリにCNAMEファイルを自動コミット
これらの手順はGitHubが公式に定めるカスタムドメイン設定手順に完全に準拠している。手動で行う場合とまったく同じ結果が、人的ミスのリスクなく得られる。
自動検証でDNS設定の完了を確認する
設定が完了したら、Copilot CLIは自らの作業を検証する。まずドメインが正しく解決されるか（DNSルックアップ）を確認し、次にサイトがHTTP 200（正常応答）を返すかをチェックする。手動での動作確認すら自動化されているのだ。
実際のタイムラインを見てみよう。ドメイン購入は東部時間の午前11時21分27秒に行われた。約14分後の午前11時35分には、カスタムドメインでHTTPS化されたサイトが公開されていた。この14分にはAPIセットアップ、スキルインストール、DNS設定、伝播、検証のすべてが含まれている。
Copilot CLIがDNSルックアップとHTTPステータス確認を自動実行し、人間が待機する必要はない。設定ミスがあればすぐに検出され、修正も対話的に行える。
DNS自動化が変える開発体験、Namecheap以外でも使える汎用ワークフロー
このワークフローの本質は、Namecheapに限ったものではない。APIを提供しているレジストラであれば、同じアプローチが適用できる。専用のスキルがなくても、Copilot CLIにレジストラのAPIドキュメントを読み込ませ、「このAPIを使ってGitHub PagesのDNSレコードを設定して」と指示すればよい。レジストラが変わってもワークフローは変わらない。
DNS設定は「難しくはないが、面倒で失敗しやすく、フィードバックが遅い」という特性を持つ作業だった。Copilot CLIはこの3つの課題を同時に解決する。面倒な手順は自動化され、失敗のリスクは承認プロセスで抑制され、フィードバックは自動検証で即時に得られる。
カスタムドメインの設定を「面倒だから」と後回しにしてきた開発者にとって、このワークフローは心理的な障壁を取り除く。14分という時間は、コーヒーを淹れるのと変わらない。DNS設定がコマンド1行で済む時代が、すでに来ている。
この記事のポイント
- GitHub Copilot CLIとNamecheapスキルでDNSレコードの手動編集が不要になる
- 空のリポジトリからHTTPS化されたカスタムドメインサイトまで約14分で完了
- API経由の自動設定によりAレコードやCNAMEの入力ミスがゼロになる
- 設定後はCopilot CLIがDNS解決とHTTPステータスを自動検証する
- Namecheap以外のレジストラでも、APIがあれば同じワークフローが適用可能
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GitHub Copilotデスクトップアプリ登場、エージェント駆動開発の拠点に
GitHubが2026年6月2日、新たなGitHub Copilotアプリをテクニカルプレビューとして公開した。このアプリは、複数のAIエージェントを並行して管理・指示するための「エージェントネイティブ」なデスクトップ体験を提供する。
Copilot Pro、Pro+、Business、Enterpriseの既存ユーザーはすぐに利用を開始できる。My Workビュー、ワークツリーによるセッション分離、Agent Merge、Canvas、サンドボックス、高度なコードレビュー、SDK、刷新されたCLIなど、エージェント主導開発の基盤として設計された機能群を詳しく見ていく。
GitHub Copilotアプリ：エージェントネイティブ開発のコントロールセンター
多くの開発者が日常的に複数エージェントを動かすようになるにつれ、ウィンドウを切り替えながらセッションを追跡する従来のやり方では限界が出てきた。Copilotアプリはその断絶を解消する。
「My Work」ビューは、接続されたリポジトリ全体にわたって稼働中のセッション、Issue、プルリクエスト、バックグラウンド自動化を一覧表示する。各セッションは固有のgit worktree（ブランチの独立した作業コピー）で実行されるため、エージェントどうしが互いの作業を壊すことはない。worktreeの作成や後片付けはアプリが自動的に処理する。
さらにAgent Merge機能は、プルリクエストをレビューからチェック、マージまで運ぶ。CIの監視、必須レビュアーの確認、失敗したチェックの修正をCopilotが代行し、開発者は「CIをグリーンに戻す」「フィードバックに対応する」「条件を満たしたらマージする」といった自動化の範囲を選べる。
GitHub Blogに掲載されたAvanade Inc.のDavid Jobling氏（Master Technology Architect）のコメントによれば、「Forward Deployedのエンジニアは多数のエージェントを一元的に扱い、複数のイニシアチブを管理できる。プランやオートパイロットへのアクセスが容易になり、必要に応じてインタラクティブなセッションを実行したりコードに介入したりできる」と評価している。
この統合感をビフォーアフターで示すと、次のような差になる。
このデモのように、Copilotアプリはエージェントが「ただコードを提案する」存在から「プロジェクト全体を駆動する」存在へ変わるための統制盤になる。
Canvas：意図を見える化する双方向作業面
チャットは指示や曖昧さの解消に強い。しかしエージェントが本格的な作業を始めると、チャットスレッドは判断やログ、修正指示の長いスクロールになり、作業そのものの全体像を見失いがちだ。
そこで導入されたCanvasは、人間とエージェントが同じ面で作業する双方向の作業サーフェスだ。プラン、プルリクエスト、ブラウザセッション、ターミナル、デプロイ状況、ワークフローの状態など、エージェントが作業を進めるにつれてCanvasが更新され、開発者はその場で編集、順序変更、承認、方向転換ができる。
チャットが「思考の場」だとすれば、Canvasは「作業の場」だ。これが、GitHubが提唱するエージェント体験（AX）の出発点になる。
サンドボックス：本番に触れずにエージェントを動かす隔離環境
コードを提案するだけでなく、実際にコードを実行し、テストし、結果を調べて反復できることがエージェントの実用性を高める。そのために用意されたのが、ローカルとクラウドの2種類のサンドボックスだ。
・ポリシーを一元的に設定・適用
・オフライン作業に最適
・組織のポリシーを自由に定義
・任意のデバイスからリモート操作
ローカルではマシンのリソースを直接使いつつもポリシーで範囲を絞り、クラウドでは完全に独立したエフェメラル環境が手に入る。いずれも本番環境に手を触れることなく、エージェントがコードの実行と検証を繰り返せる。
コードレビュー機能：エージェント出力にスケールする審査
エージェントが生成するプルリクエストが増えるほど、コードレビューの負荷は増す。Copilotコードレビューは、適応的なエージェントシステムでノイズをふるい分け、開発者は本当に重要な判断に集中できる。
新たに追加された「中程度」レビューティアでは、より高精度な推論モデルを利用してレビューの適合率と再現率を向上させる。管理者はリポジトリごとに「低」か「中」を割り当てられ、リスクの低いコードには軽量なモデルを、影響度の高いリポジトリには強力なモデルを振り分けられる。
また、/security-reviewスキルはセキュリティに特化した評価経路を用意し、一般提供された/rubberduckスキルは複数のモデルファミリーを利用して実装を批判的に検証し、新たな問題点を見つける。
さらに、Azure DevOpsユーザーはCopilotコードレビューをネイティブに利用できるようになった。ワンクリックレビュー、インラインコメント、コミット可能な修正提案といった機能がそのまま使える。
・時間が足りない
・/security-reviewでセキュリティ専用評価
・/rubberduckで実装の批判的検討
・自社ポリシーに合わせてカスタマイズ
このように、レビューの質とスループットを両立させる仕組みがCopilotアプリの中核に組み込まれている。
Copilot SDKとCLI：開発者自身のツールを構築する土台
エージェント機能はアプリの中だけにとどまらない。Copilot SDKが一般提供され、Node.js/TypeScript、Python、Go、.NET、Rust、Javaといった主要言語から同じエージェントランタイムを利用できる。自社のコード分析ツール、カスタムリリースノート生成、サポートワークフローに組み込むエージェントなどを、共通の土台の上に構築できる。
CLIも大きく刷新された。再設計されたTUIではタブでプルリクエスト、Issue、Gistにアクセスでき、音声入力にも対応する（音声データは端末外に出ない）。/everyを使えば定期的なプロンプト実行やバックグラウンドタスクのスケジュールが組める。クラウド自動化では、エージェントがGitHubイベントに反応してIssueを開いたりコメントを残したりできる。初期設定では書き込みアクションの前に都度許可を求めるが、信頼を確立した後はオートパイロットに切り替え可能だ。
さらにMemory++と/chronicleによって、アプリ、CLI、VS Code、github.comをまたいだセッションの文脈が連続する。パートナー企業（LaunchDarkly、Sonar、Amplitude、PagerDutyなど）が構築したエージェントアプリも統合され、開発者はGitHubを離れることなく、馴染みのツールをエージェント主導のワークフローに組み込める。
エージェント主導開発の未来を見据えて
プロフェッショナルなソフトウェア開発には、判断、検証、説明責任が不可欠だ。GitHub Copilotアプリ、サンドボックス、コードレビュー、自動化、文脈連続性、パートナーエコシステムは、エージェントがより多くの作業を担いながらも、開発者が品質、ポリシー、デリバリーの統制を保つための一つのシステムとして結実している。
GitHub Blogの記事では、エージェント主導の開発がプラットフォーム全体で拡大する中、可用性を第一に据え、これらのシステムを堅牢化し、チームが日々の開発で依存できる速さと信頼性を確保していく姿勢が示されている。
この記事のポイント
- GitHub Copilotアプリは複数エージェントを並行管理し、worktreeとAgent Mergeで混乱を防ぐコントロールセンターとして機能する
- Canvasにより、チャットの指示を視覚的な作業面に展開し、人間とエージェントが同じキャンバス上で協調できる
- ローカルとクラウドのサンドボックスで、本番環境に触れずにエージェントがコードを実行・検証できる
- コードレビュー機能は中程度推論モデルやセキュリティ専用スキルで品質を保ち、Azure DevOpsでもネイティブ利用可能
- SDKと刷新されたCLIにより、開発者自身のツールや自動化を同じエージェントランタイム上に構築できる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GitHub Shop新作「ESC」コレクション、開発者のまま外へ出かけよう
GitHubは2026年5月28日、公式ショップの新作コレクション「ESC」を発表した。Tシャツやキャップ、スライドサンダル、さらにはタコキャット型のドリンクホルダーまで、デスクを離れて過ごす夏のためのグッズが揃っている。単なるノベルティではなく、開発者コミュニティの遊び心を形にしたラインアップだ。
このコレクション最大の特徴は、HTMLタグをあしらったアパレルと、CopilotやOctocatのトロピカルデザインだ。「デスクの外にも良いアイデアは転がっている」という考え方が企画の起点になっている。プールサイドやビーチでリラックスしながら、ふとバグの解決策を思いつく瞬間を後押しする仕掛けだ。
HTMLタグが服に 開発者ジョークを身にまとう
「ESC」コレクションの中心は、普段着として着られるアパレル製品だ。特に話題を呼んでいるのが、Tシャツ、キャップ、スライドサンダルにそれぞれHTMLタグの<body>、<header>、<footer>をあしらったデザインである。
これまでのGitHub Shopではキャップや靴下が定番だった。一方で「Tシャツはないのか」という声がコミュニティから多く寄せられていた。今回の<body>Tシャツは、まさにその要望に応えたかたちだ。
<header>ハットは新しいカラーバリエーションが追加されている。頭部を飾るという意味で、HTMLのセマンティクスと物理的な位置が見事に一致している点が面白い。スライドサンダルに<footer>と書かれているのも、同じ発想だ。
このネーミングは単なるジョークに留まらず、開発者文化のアイデンティティを日常生活に溶け込ませる工夫と言える。GitHub Shopの担当者は、デスクの外でこそ優れた問題解決が生まれるというメッセージを、商品名そのものに込めたのだろう。
ビーチでもCopilot トロピカルデザインのCabanaセット
より大胆なデザインを求める開発者には、トロピカル柄のCabanaセットが用意された。上下が揃いになったシャツとショーツには、OctocatことMona、GitHub Copilot、そしてラバーダックのキャラクターがヤシの木や花とともに描かれている。
ラバーダックは「ラバーダックデバッグ」と呼ばれるプログラミング技法に由来する。コードの問題を誰かに説明する過程で自己解決する手法で、開発者にはおなじみの存在だ。GitHub Copilotと並べて配置することで、AI時代の新しいペアプログラミングを連想させるデザインになっている。
派手なCabanaセットの対極として、より控えめなリネンシャツも用意されている。Hibiscus Tocatリネンシャツは、ハイビスカス柄の中に小さくOctocatを忍ばせたデザインで、開発者と気づかれずに開発者アピールできる逸品だ。
さらに、クーラートートバッグも注目に値する。Invertocatデザインの保冷バッグは、ビーチやプールサイドに飲み物を持ち運ぶのに最適なサイズ感だ。開発者がコードから離れて過ごす時間を、きちんとサポートする機能性を持っている。
ドリンクを冷やす小さなパーカー 人気商品をミニチュア化
ESCコレクションのユニークなアイテムとして、ブラックInvertocatパーカーのデザインをそのまま缶クーラー（クージー）に落とし込んだ製品がある。フード付きパーカーを模した小さなドリンクホルダーで、人気アパレル商品のミニチュア版という発想が秀逸だ。
本家のInvertocatパーカーはGitHub Shopのベストセラーである。今回それを「缶用」として展開したことは、スケーリングとユーモアの両面で開発者マインドをくすぐる。実用品でありながら、コードレビューで突っ込みたくなる会話のきっかけにもなるだろう。
さらに、プール用のドリンクフロートとしてMonaフロートも登場した。Octocatの形状をした浮き輪型ドリンクホルダーで、プールに浮かべながら飲み物を楽しめる。開発者のデスク周りにOctocatグッズが並ぶように、水辺にもOctocatを持ち込む発想である。
これらの商品からは、「開発者であることをオフの時間にも楽しもう」というブランドの一貫した姿勢が感じられる。コードを書くことだけが開発者ではない。問題解決の思考は日常のあらゆる場面で活きるという考え方だ。
ショッピング体験にも技術を パーソナライズ機能と今後の展開
GitHub Shopのサイト自体にも技術的な工夫が施されている。商品画像の背景にはLiDARスキャナーが使われており、ユーザーは色味やズームを自由に変更して、自分好みのビジュアルで商品を確認できる。ECサイトの枠を超え、開発者に「どんな技術で実装しているのか」を想像させる仕掛けだ。
これは単なるファッション販売ではなく、GitHubブランドの世界観をデジタル上で体験させる戦略と言える。商品を選ぶ行為そのものをインタラクティブな開発者体験に昇華している点がユニークだ。
ESCコレクションの発表と併せて、GitHubは近くワールドカップ関連の特別企画も準備していると予告している。開発者文化と世界的なスポーツイベントをどう結びつけるのか、続報が待たれるところだ。
この記事のポイント
- GitHub Shopの新作「ESC」コレクションは、デスクを離れた場所でのリラックスをテーマにしている
- HTMLタグにちなんだアパレルや、Copilot・Octocatをあしらったトロピカルデザインが特徴
- ベストセラーパーカーを模した缶クーラーなど、実用品に開発者向けの遊び心を落とし込んでいる
- 商品画像にLiDARスキャナーを使うなど、ショッピング体験そのものにも技術的工夫がある
- コードから離れる時間が、むしろ良いアイデアを生むというブランド思想が商品全体を貫いている
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
VS Code 1.123リリース、エージェント画面刷新とチャット機能の進化
Visual Studio Codeのバージョン1.123が2026年5月末にリリースされた。このアップデートの中核は、AIエージェントとの対話体験を根本から再設計したことにある。エージェント画面のグリッド表示、スタンドアローン環境とのセッション受け渡し、そしてチャット機能の柔軟性向上が主な柱だ。
基盤となるElectronは42へとメジャーバージョンアップし、内部ブラウザのChromiumが148、ランタイムのNode.jsが22.xへと刷新された。これにより、VS Code全体の安定性とパフォーマンスが底上げされている。開発者はこの新バージョンにより、AIとの共同作業をより自然に、より強力に進められるようになる。
本記事では、今回のアップデートで開発現場に最もインパクトを与える4つの変更点を掘り下げ、その実務的な意味を解き明かす。
Electron 42基盤刷新がもたらす安定性とパフォーマンス
VS Code 1.123の最大の土台変更は、フレームワークの中枢であるElectronをバージョン42に引き上げたことだ。この一言で片付けるにはあまりに影響範囲が広い。Electronとは、ウェブ技術（HTML、CSS、JavaScript）でデスクトップアプリケーションを構築するためのプラットフォームである。VS CodeもこのElectronの上に成り立っている。
この変更は、VS Codeの内部ブラウザ機能や拡張機能の動作環境に直接影響する。
Chromium 148への移行で変わる統合ブラウザの実用性
VS Codeには簡易ウェブブラウザ機能が統合されており、フロントエンド開発者は別途ブラウザを立ち上げずにプレビューを確認できる。Chromium 148とは、Google Chromeの基盤部分のことだ。今回のアップデートでこの基盤がバージョン148へと刷新されたことで、最新のウェブ標準に準拠した表示が可能になった。
具体的には、新しいCSSプロパティやWeb APIが利用できるようになり、プレビュー表示の信頼性が向上する。また、ブラウザ関連の設定が設定エディタ内で独立したセクションにまとめられ、管理しやすくなった点も見逃せない。設定画面の見通しが良くなったことで、開発者は必要な項目に素早くアクセスできる。
Node.js 22.xによる拡張機能の実行速度向上
Node.jsとは、サーバーサイドでJavaScriptを動かす実行環境である。VS Codeの拡張機能やターミナル機能はこの上で動作している。ランタイムが20.xから22.xへと一段階飛び級でアップグレードされたことで、JavaScriptエンジン「V8」の最適化が進み、拡張機能の起動時間やターミナルでのコマンド実行が高速化される見込みだ。
さらに、BYOK（Bring Your Own Key）環境でOpenRouterやDeepSeekといった外部推論モデルを利用している場合、ツール呼び出し後にHTTP 400エラーが発生する不具合も今回のNode.js更新に伴い修正された。これにより、外部AIプロバイダーとの連携がより安定する。
エージェント画面の進化、グリッド表示とスレッド返信で管理性が向上
VS CodeのAIエージェント機能は、コード編集やタスク実行を自律的に支援する存在だ。このエージェントとの対話履歴を確認する「エージェント画面」が、バージョン1.123で大幅に再設計された。最も目を引くのは、セッション一覧が従来のリスト形式からグリッド形式に変わった点である。
多数のエージェントセッションを並行して扱う開発者にとって、この変更は作業効率の大幅な改善につながる。
スレッド返信機能でフィードバックが対話的に
エージェント画面に追加されたもうひとつの重要な機能が、スレッド形式の返信だ。これまではエージェントの出力に対するフィードバックを一方向的に追加することしかできなかった。しかし今回のアップデートにより、特定のコメントに対して個別に返信できるようになった。
これは、チームでのコードレビューに近い体験をエージェントとの対話にもたらす。エージェントが生成したコードの特定の部分に対し「このロジックを修正してほしい」と指摘したり、複数の修正案を比較検討したりするコミュニケーションが、より構造化された形で可能になる。
チャットセッションを受け渡すハンドオフ機能
VS Codeの編集画面で進行中のチャットを、スタンドアローンのエージェント画面にそのまま移行できるハンドオフ機能も追加された。編集画面ではコードに集中したいが、エージェントとの対話は続けたい、という状況で役立つ。
また、エージェントホストセッション中に送信されたステアリングメッセージが、従来は実行中のターンに埋め込まれていたが、今回から独立したユーザーターンとしてチャット上に表示されるようになった。これにより、どの指示がどのタイミングで送られたのかが明確になり、対話の透明性が高まっている。
チャット機能が柔軟に、添付ファイルのみの送信やエリアスクリーンショットに対応
日々のコーディングで最も頻繁に使われるチャット機能にも、実用的な改善が施された。中でも画期的なのは、テキストメッセージなしで添付ファイルだけを送信できるようになった点である。
この一見小さな変更が意味するところは大きい。エラー画面のスクリーンショットを撮ってそのまま投げ込むといったフローが、ワンアクションで完結するのだ。
統合ブラウザのエリアスクリーンショット機能
統合ブラウザ上で、ページ全体ではなく特定の領域だけを選択し、そのスクリーンショットをチャットのコンテキストとして追加できる機能も実装された。デザインの微調整をAIに依頼する場合や、特定のUI要素について質問する場合に、余計な情報を省いた的確なコミュニケーションが可能になる。
並列ターミナルコマンドの完了通知がバッチ化
エージェントモードが複数のターミナルコマンドを並列実行する際、これまではコマンドごとに個別のエージェントターンが作成され、チャット画面が完了通知で埋め尽くされる問題があった。今回のアップデートでは、これらの通知が1つのメッセージにまとめてバッチ化される。チャット画面がすっきりと整理され、本質的な対話に集中しやすくなった。
プロンプトファイルと外部環境連携の改善
開発者がAIに与える指示をファイル化する「プロンプトファイル」の仕組みにも、いくつかの使い勝手の向上が図られた。
サブコマンド呼び出しの直感的な書式
プロンプトファイル内でサブコマンドを呼び出す際、従来はコロン区切りの形式（例、/chronicle:tips）が必須だった。この構文がスペース区切り（例、/chronicle tips）でも動作するようになった。この変更は表記法の微細な違いに過ぎないように見えるが、シェルコマンドや自然言語の記法に慣れ親しんだ開発者にとって、認知負荷を下げる効果がある。
外部AI推論モデルとの互換性修正
BYOK（Bring Your Own Key）モデルで、OpenRouterやDeepSeekといった推論特化型プロバイダーを利用する場合、ツール呼び出し後にHTTP 400エラーが発生する不具合があった。これはVS Codeが送信するリクエスト形式と、一部のプロバイダー側のパース処理の間に生じていた非互換が原因だ。今回の修正により、これらの外部モデルが安定して動作するようになった。
Cloudタスクの出力がローカルと同等の表現力に
GitHub CopilotのCloudタスク機能では、これまで実行結果の表示がテキスト主体で、ターミナル出力の表現力に限界があった。今回のアップデートで、CloudタスクもローカルのCopilot CLIセッションと同様に、ツールカードや編集差分、ターミナル出力をリッチにレンダリングできるようになった。リモート実行とローカル実行の間で、視覚的な体験が統一される。
細部に及ぶ品質改善と不具合修正
メジャーな機能追加の裏で、開発者の日常業務にじわじわと効いてくる細かな修正も数多く含まれている。
/docコマンドのPython docstring配置修正
/doc コマンドを使ってPythonコードにドキュメント文字列を生成する際、docstringがデコレータの前に挿入されるという不具合があった。本来は関数本体の内部に配置されるべきものであり、修正により正しい位置に生成されるようになった。Python開発者にとっては、コードの可読性を保つ上で見過ごせない変更だ。
Zenモード時のインジケーター非表示
Zenモードは、余計なUI要素を排除してコードに没頭するための表示モードだ。しかしエージェントモードのインジケーターがタイトルバーに表示され続けることで、没入感が損なわれていた。今回の修正で、Zenモード時にはこれらのインジケーターが自動的に非表示になる。
Windows環境でのCLIフラグ問題を解消
Windows環境限定の問題として、--folder-uri や --file-uri といったCLIフラグが特定の条件下で無視される不具合が解消された。引数の順序が最後でない場合や --wait フラグと併用した場合に発生していたこの問題は、VS Codeをスクリプトや外部ツールから起動するワークフローで特に支障をきたしていた。修正により、コマンドラインからの起動オプションが全プラットフォームで一貫して動作する。
この記事のポイント
- VS Code 1.123の中核はエージェント画面のグリッド表示とスレッド返信だ、多数のAIセッションを並行管理する開発者の負荷が下がる
- Electron 42への基盤刷新によりChromium 148とNode.js 22.xが導入され、統合ブラウザの互換性と拡張機能の実行速度が向上する
- チャットに添付ファイルのみを送信できる新機能で、エラー共有や画像解析の依頼が1アクションで完結する
- 外部AI推論モデルとの非互換やPython docstring生成位置の不具合など、現場の開発者が直面していた細かな問題が着実に修正されている
- プロンプトファイルのサブコマンド記法が簡略化され、AIへの指示をより直感的に記述できるようになった
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GitHub Copilotに新プランMax登場、Pro/Pro+にFlex割り当てで利用可能額が大幅増
2026年6月1日から、GitHub Copilotの個人向けプランが大きく変わる。利用量に応じた課金への移行に伴い、ProとPro+プランに「Flexアロットメント」と呼ばれる変動型の追加利用枠が導入され、月額100ドルの新プラン「Max」も登場する。
GitHubの公式ブログで発表された今回の変更は、長時間のエージェント駆動作業や複数ステップの複雑なタスクに対応するためのものだ。価格は据え置きで利用可能な総額が大幅に増える仕組みであり、とくにPro+ユーザーには大きな恩恵となる。
この記事では、Flexアロットメントの仕組み、各プランの具体的な料金とクレジット、移行時に注意すべき点を詳しく解説する。
GitHub Copilotの個人向けプラン刷新概要
なぜ今、プランが変わるのか
GitHubは2026年1月に、Copilotの課金方式を「月額固定の定額制」から「利用量ベースの課金（Usage-based billing）」へ切り替える方針を発表した。この移行に伴い、多くのユーザーから「含まれる利用量が十分か」という懸念が寄せられていた。とくに、マルチステップのエージェント作業や、より高性能なモデルの利用が増えるにつれて、当初発表された利用枠では不足するケースが想定されたのである。
公式ブログの記事によれば、GitHubはこのフィードバックを受け、Pro/Pro+プランの利用総量を増やすとともに、新しいMaxプランを追加した。これにより、個人開発者から高負荷のAI活用まで幅広いニーズをカバーする形となる。
新ラインナップの全体像
2026年6月1日以降、個人向けCopilotは「Free」「Pro」「Pro+」「Max」の4プラン体制に再編される。Freeプランは引き続き月に限定的なコード補完とチャット、エージェント機能を提供する。Pro、Pro+、Maxは有料となり、利用量ベースの課金が適用されるが、月額料金に応じた「基本クレジット」と、変動する「Flexアロットメント」の合計が利用可能な総クレジットとなる。
Flexアロットメントの仕組み
基本クレジットとFlex割り当ての関係
有料プランでは、毎月の利用可能額は2つの部分で構成される。一つは「基本クレジット（Base credits）」で、これは月額料金と1対1で対応し、常に固定だ。たとえばProプラン（月額10ドル）なら基本クレジットは10ドル分になる。もう一つが「Flexアロットメント（Flex allotment）」で、これは基本クレジットの上乗せ分として付与される可変の追加枠である。
実際の利用時には、まず基本クレジットが消費される。基本クレジットを使い切ると、自動的にFlexアロットメントが適用される。ユーザーは特別な設定やバケット管理をする必要はなく、ダッシュボードで残りの利用可能額を確認するだけで済む。IDE、github.com、CLIのすべてで共通のレートで消費される仕組みだ。
Flexが無制限ではない理由
FlexアロットメントはAIの経済性の変化に応じて変動するよう設計されている。具体的には、モデルの価格変動や新モデルの登場、推論効率の向上といった要因によって、GitHub側が柔軟に割り当て量を調整する。つまり、利用可能な追加枠は時期によって変わりうる。しかし基本クレジットは常に月額料金と等価のため、最低限保証されるラインはブレない。
このように、Proプランは従来の固定クレジットに上乗せがあるため、実質的なお得感が増す。とりわけPro+プランでは基本の39ドルに加えて31ドル分のFlexが付与され、合計70ドル分の利用が可能になる。頻繁に長大なエージェントタスクを回すパワーユーザー向けにはMaxが用意された形だ。
各プランの料金と利用可能クレジット
Proプラン：月額10ドルで15ドル分
Proプランは月額10ドル。基本クレジットは10ドル分、Flexアロットメントが5ドル分付与され、合計15ドル分の利用枠となる。小規模な個人開発や、日々のコード補完を主に使う層には十分な容量と言える。
Pro+プラン：月額39ドルで70ドル分
Pro+プランは月額39ドル。基本39ドルに加え、Flexで31ドルが追加され、総額70ドル分を利用できる。マルチステップのリファクタリングやドキュメント生成、中規模のエージェントタスクを日常的にこなす開発者にとって、コストパフォーマンスが非常に高い設計だ。
Maxプラン：月額100ドルで200ドル分
新設のMaxプランは月額100ドル。基本クレジット100ドル分に、同じく100ドル分のFlexが加わり、総利用可能額は200ドルになる。大量のコード生成や継続的なエージェント実行を必要とするフルタイムのAI活用シナリオを想定したプランだ。大規模オープンソースプロジェクトのメンテナや、AIを骨太に組み込んだ開発フローを回すチームリーダーに適している。
クレジットの消費ルールと実際の使い方
コード補完と次編集候補は引き続き無制限
有料プランでは、コード補完（Code completions）と次編集候補（Next edit suggestions）は無制限で、クレジットを消費しない。つまり、エディタ上でリアルタイムに表示される補完候補はこれまでどおり使い放題である。クレジットが消費されるのは、チャット形式の問い合わせやエージェントによる複数ステップの実行、より高度なモデルを利用した処理だ。
超過時の追加購入とダッシュボード
もし基本クレジットとFlexアロットメントの両方を使い切ってしまった場合でも、追加のクレジットを購入して作業を続けられる。ダッシュボードには、現在の残りクレジットと消費状況が表示されるため、いつでも確認できる。これにより、月末に突然利用できなくなる心配はなく、プロジェクトの進捗に合わせて柔軟にリソースを追加できる。
Flexアロットメントが変動する背景
AIの経済性の進化に合わせた設計
Flexアロットメントが月によって変わるかもしれない最大の理由は、AIモデルの推論コストが急速に変化しているためだ。新モデルの登場やハードウェア効率の改善、サードパーティのAPI価格改定などが起きれば、GitHubは利用者に提供できる付加価値の量を動的に調整する。固定の枠では、こうした外的要因に対応しきれないリスクがある。
GitHubの発表では、基本クレジットだけは常に月額料金と等価であることを約束している。Flex部分が変動しても、最低限のコストパフォーマンスは損なわれない仕組みだ。このハイブリッドな設計は、ユーザーに安定した基盤を提供しつつ、AI技術の進歩をプランに取り込むGitHub側の狙いが感じられる。
ユーザーが今すぐすべきこと
月額契約者は自動移行、追加操作不要
現在ProまたはPro+の月額プランを利用しているユーザーは、2026年6月1日になると自動的に新しい利用量ベース課金のプランへ移行し、Flexアロットメントが適用される。手動でプランを変更する必要はない。もし年間契約を結んでいる場合は、更新タイミングなどの詳細を公式ドキュメントで確認するとよい。
移行後すぐにダッシュボードでクレジットの残高をチェックし、自分の普段の開発スタイルでどれだけ消費するかを把握しておくことを推奨する。特にエージェント機能を積極的に使っているユーザーは、Pro+やMaxへのアップグレードを検討するタイミングかもしれない。
この記事のポイント
- 2026年6月1日より、GitHub Copilot個人向けプランにFlexアロットメントと新Maxプランが導入される
- Pro（10ドル）とPro+（39ドル）の月額料金は据え置きのまま、利用可能クレジットが増加（Proは15ドル分、Pro+は70ドル分）
- Maxプランは月額100ドルで200ドル分のクレジットを提供し、高負荷なAI活用を想定
- コード補完と次編集候補は有料プランでも無制限で、クレジット消費はチャットやエージェント利用時のみ
- FlexアロットメントはAIの経済性変化に応じて変動するが、基本クレジットは常に固定
- 既存の月額契約者は自動移行のため、追加の操作は不要
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
エージェントPRが急増中。レビューで見るべき5つの視点
テストが通り、コードもクリーンに見える。多くの開発者がそのプルリクエストを深く疑わずにマージしている。しかし、そのPRを書いたのは人間ではない。エージェントが生成したコードだ。そして、簡単に承認してしまうことこそが最大の問題である。
2026年1月に発表された研究「More Code, Less Reuse」によれば、エージェントが生成したコードは人間が書いたコードよりも変更あたりの冗長性と技術的負債が大きい。表面上はクリーンだが、負債は静かに蓄積される。さらに、同じ研究はレビュアーがエージェントのコードに対してむしろ積極的に承認したくなる傾向があることも指摘している。
これは開発速度を落とせという主張ではない。意図的かつ戦略的にレビューに臨むべきだという提言だ。エージェントのPRをどうレビューすれば、隠れた問題を見落とさずに済むのか。本稿では、GitHubのシニアデベロッパーアドボケイトであるAndrea氏が公開した実践ガイドをもとに、具体的なチェックポイントと効率的なワークフローを解説する。
エージェントPRの急増とレビュー負荷のギャップ
すでにプルリクエストの量は膨大だ。GitHub Copilotのコードレビュー機能はこれまでに6,000万回以上のレビューを処理し、1年足らずで10倍の規模に成長した。GitHub上のコードレビューの5件に1件以上がエージェントと関わっている。これは自動レビューの通過数に過ぎない。肝心のプルリクエストそのものは、レビュアーが処理できる速度をはるかに超えて増殖している。
従来の「レビュー依頼→コードオーナーが確認→マージ」というループは、1人の開発者が午前中に十数回のエージェントセッションを起動できる今、崩壊しつつある。スループットは指数関数的に伸びたが、人間のレビュー能力は変わっていない。そのギャップは広がる一方だ。
レビュアーが持つべき「コードを書いたのは誰か」の認識
diffの1行を見る前に、レビュアーは自分が何を確認しているのかをモデル化しておく必要がある。コーディングエージェントとは、生産的で字義通りに動き、既存のコードパターンを忠実に模倣する貢献者のような存在だ。しかし、そのエージェントには、自社のインシデント履歴も、チームが蓄積してきたエッジケースの知見も、リポジトリの外にある運用上の制約も一切ない。
エージェントは一見完成されたコードを生成する。だが、この「完成しているように見える」という状態が危険なのだ。コードが動き、テストも通る。それにもかかわらず、運用環境では破綻する。レビュアーこそが、そうした抜け落ちた文脈を埋める存在である。それは負担ではなく、レビューの本質的な仕事であり、自動化できない判断の部分だ。
エージェントPRで見るべき5つのレッドフラッグ
このデモは、エージェントのプルリクエストをレビューする際にまず確認すべき5つのポイントをまとめたものだ。各項目の詳細は以下で解説する。
1. CIの改ざん
エージェントはCIに失敗すると、テストを通すための明白な抜け道を選ぶことがある。テストの削除、リントステップのスキップ、テストコマンドに || true を追加するなどの行為だ。CIを弱体化させる変更は即座にブロックすべきである。
具体的には、カバレッジ閾値の変更、テストの削除やリネーム、スキップの追加、ワークフローがフォークやPRで実行されなくなっていないか、CIステップが新たな条件でゲートされていないか、を必ずチェックする。
2. 既存コードの再発明
これはレビュアーにとって最も費用対効果の高いチェックだ。エージェントはリポジトリ内のパターンを探し、それを複製する。同名の機能を持つ既存ユーティリティを確認せず、よく似た名前の新規関数を追加する。バリデーションロジックを複数箇所に再実装し、共有モジュールに既にあるミドルウェアをゼロから書き直す。こうした「ほとんど同じだが名前が違う」ヘルパーが生まれやすい。
エージェントのローカルコンテキストにはリポジトリ全体の見取り図が欠けている。レビュアーは新しく追加されたユーティリティやヘルパーをすべて検索し、重複があれば統合をマージ前に要求する。重複ロジックを放置すると、それが今後のエージェントにとっての「先行事例」になり、さらに複製が加速する。
3. うわべだけの正しさ
存在しないAPIを呼び出すような明らかな誤りはCIで検出される。深刻なのは、コンパイルが通り、すべてのテストを通過し、それでも間違っているコードだ。ページネーションのオフバイワンエラー、テストで決して通らないブランチでの権限チェック漏れ、エージェントが考慮しなかったエッジケースで短絡するバリデーション、大規模環境でのみ顕在化する競合状態などが該当する。
diffの中で最も重要なパスを選び、入力を出力まで追跡する。境界条件（ゼロ、最大値、空）や外部値のバリデーション漏れ、全ブランチの権限チェック、予期しない条件分岐を確認する。加えて、変更前の動作で失敗する新たなテストを要求すれば、理解不足や修正の不完全さを炙り出せる。
4. エージェントの沈黙と見せかけの反応
詳細なレビューを残しても、PRが沈黙してしまうケースがある。あるいはエージェントが要点を外した返信を繰り返し、堂々巡りになる。特に大きく構造化されていないPRでは、エージェントの放棄やミスアライメントが目立つ。レビュー時間を無駄にしないためにも、大規模なエージェントPRに深く入る前に、PRの履歴を確認する。
それまでのラウンドで応答性があったか、明確な実装計画があるか、エージェントがいきなりコードを書き始めただけではないかを見極める。計画がない場合は、以下のような定型文で分割や概要の提示を求める。これは個人攻撃ではなく、時間を節約するための率直な要求だ。
このPRは大きすぎて、明確な実装計画なしにレビューできません。
小さな単位に分割するか、各パートの目的と構造の意図をまとめてもらえますか。
その後、改めてレビューします。5. ワークフローへの信頼できない入力
CIエージェントへのプロンプトインジェクションは過小評価されている脅威だ。典型的なパターンとして、PR本文やIssue、コミットメッセージから内容を読み取り、それをプロンプトに展開し、モデル出力をシェルコマンドに流し込み、GITHUB_TOKEN権限で実行する流れがある。
LLMを呼び出すワークフローをレビューする際は、以下をブロッカーとみなす。信頼できないユーザー入力（PR本文、Issue本文、コミットメッセージ）が無害化されずにプロンプトに挿入されていないか。GITHUB_TOKENが書き込みスコープを持っているのに読み取りしか必要としていないか。モデル出力がバリデーションなしでシェルコマンドとして実行されていないか。シークレットがエージェントステップに渡されたりログに出力されたりしていないか。
マージ前に求めるべき対策は、ワークフローYAMLでの最小権限の原則（permissions: read-all をデフォルトに）、プロンプトに触れる前に信頼できないコンテンツのサニタイズとクォート、本番環境に触れる部分での「分析」と「実行」の分離と人間の承認ゲート、モデル出力の直接実行の禁止だ。
10分で完了する効率的なレビューワークフロー
上のフローは、GitHubのAndrea氏が提唱する時間枠付きのレビュー手順を図示したものだ。ポイントは、CIチェックを最優先し、重複検索を別工程で行い、最後に「証拠」としてのテストを要求することにある。
diffが5つ以上の無関係なファイルにまたがる、PRの目的を一文で説明できない、実装計画がない、CIが落ちていて変更点がテストファイルだけ、といった場合には、PRの縮小や計画の明確化を依頼する判断も必要になる。
Copilotに先にレビューさせるメリット
自動レビューは、機械的なチェックを人間に代わって処理するという、その得意分野で使うのが賢明だ。Copilotコードレビューは、スタイルの不一致、明らかなロジックエラー、エラーハンドリング不足、型の不一致などを自動検出する。これにより、低レベルの走査から解放され、レビュアーは判断を要する作業に集中できる。
自動レビューはあくまで前提条件であり、代替ではない。Copilotを最初に走らせ、明らかな問題があれば著者に修正させてから、人間のレビューに進む。チーム固有のカスタム指示を与えれば、CI閾値の変更をフラグ付けしたり、重複レビュー用に新しいユーティリティを表面化させたり、外部入力のバリデーションを確認したりといった調整も可能だ。
実際、Andrea氏はCopilot SDKを使って自分のレビューチェックリストをコード化し、管理エンドポイントの認証、テストの実効性、安全な環境変数処理といった観点を自動チェックするワークフローを構築したという。重大な問題が見つかればマージをブロックする仕組みだ。こうした自動化によって、レビュアーは真に価値のある判断業務に時間を振り向けられる。
この記事のポイント
- エージェント生成PRは表面上クリーンだが、冗長性と技術的負債を内包しやすい
- CIを弱める変更は即座にブロックし、テスト削除やカバレッジ操作を厳重に確認する
- 新規ユーティリティの重複検索を習慣化し、既存コードの再発明を防ぐ
- 最重要パスをトレースし、境界条件と権限チェックを目視で検証する
- CIエージェントへのプロンプトインジェクション対策として、ワークフローの最小権限化と入力サニタイズを徹底する
- Copilotコードレビューを先に実行し、機械的チェックを済ませたうえで人間の判断に集中する
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験