GitHub CopilotをJetBrains Airで使う方法｜契約と注意点

【PR】この記事には、アフィリエイトを含む案内があります。

こんにちは。AIあれこれ散歩道、運営者のもっちゃんです。

GitHub Copilotは、JetBrains Airのエージェント選択画面から使えるようになりました。ただし「AirへCopilotをつなげば、手元のIDEでもブラウザでも同じ条件で動く」という理解は正確ではありません。ローカル作業とクラウド作業では、導入手順、実行場所、必要な契約、管理者設定が違います。特に会社の組織アカウントを使う場合は、個人のCopilot契約だけでクラウド作業を始められるとは限りません。

GitHubは2026年11月3日、AirでCopilotを選べる統合を発表しました。ローカルではJetBrains IDEへAirプラグインを入れ、Copilotアカウントを接続します。クラウドではAir Teamsが有効なBusiness組織、Copilotの利用条件、Air管理者による有効化が必要です。この記事では、公式発表で確認できた範囲をもとに、画面の見分け方から契約の確認、クラウド環境の注意点まで順番に解説します。

JetBrains AirでCopilotを使う仕組み

JetBrains Airは、複数のコーディングエージェントへ作業を任せ、進行状況や変更内容を一つの画面で確認するための環境です。今回の統合では、Airのエージェント選択肢としてGitHub Copilotを指定できます。裏側ではAgent Client Protocol、略してACPが使われます。ACPはエージェントと開発環境をつなぐための仕組みであり、読者が手作業で通信仕様を設定するものではありません。

AirとCopilotの役割

Airは、エージェントを選び、複数の作業セッションを追い、変更をコードの文脈で確認する側です。Copilotは、選択されたエージェントとして指示を受け、コードの調査、編集、テストなどを進めます。似た画面に見えても、AirそのものがCopilotへ置き換わるわけではありません。既存のGitHub CopilotプラグインとAirの統合は併用できるため、普段の補完やチャットと、まとまった作業の委任を用途で分けられます。

たとえば、短い関数の説明や補完はIDE内のCopilotプラグインで済ませ、複数ファイルにまたがる調査や修正はAirからエージェントへ渡す使い方が考えられます。Airでは並行するセッションを追跡し、プロジェクトの文脈やIDEの機能を使いながら変更を確認できます。いきなり大きな改修を任せるより、最初はテスト追加や文書更新など結果を確認しやすい作業から試すと、役割の違いを理解しやすいでしょう。

ローカル作業の始め方

ローカル作業では、対応するJetBrains IDEへAirプラグインを入れます。Airの画面でGitHub Copilotを選び、自分のCopilotアカウントを接続するのが公式案内の流れです。作業対象は手元のプロジェクトで、実行や確認もローカル環境を使います。社内リポジトリを開く場合は、IDEでそのリポジトリへアクセスできる権限、依存関係、実行環境がそろっているかを先に確認してください。

「接続できた」と「目的の作業を実行できる」は別です。アカウント認証に成功しても、対象ファイルの書き込み権限、ターミナル実行の許可、パッケージ取得のネットワーク制限、秘密情報の参照範囲によって、途中で止まる場合があります。最初の確認では、読み取りだけの質問、変更案の提示、テストの実行、ファイル保存の順に段階を分けましょう。どこで許可が必要になるかを把握してから本番の変更へ進む方が安全です。

クラウド作業の条件

クラウド作業は条件が増えます。公式発表では、JetBrainsアカウントがAir Teams対応のBusiness組織に所属していること、GitHub Copilotの利用条件を満たすこと、Air管理者がCopilotを有効にしていることが必要です。ブラウザから使う場合はAirを開き、設定のVCS ProvidersでGitHubを接続し、リポジトリとリモートブランチを選びます。IDEから使う場合は、環境選択でCloudを選びます。

クラウド作業は新しい仮想マシン上のDockerコンテナで実行され、通信はプロキシを通ります。タスク間で状態は引き継がれません。手元のPCへ直接変更を加えずに、ビルド、テスト、パッケージ導入を進められる点は便利です。一方、前のタスクで入れた依存関係や一時ファイルが次のタスクにも残ると期待すると、再現できない原因になります。リポジトリ内の設定や再現可能な手順へ必要事項を残しておくことが大切です。

秘密情報の扱いもローカルと同じ感覚にしないでください。クラウド環境で必要な認証情報は、組織が認めた方法で渡し、指示文やリポジトリへ直接書きません。タスクが終わると状態が持ち越されないため、ローカルの設定ファイルを無理にコピーするのではなく、Airと組織の正式な設定を使います。ネットワークやパッケージ取得の制限がある場合は、制限を解除するのではなく、許可されたミラーや事前準備を検討します。

契約と利用量の注意

GitHubの説明では、AirのクラウドタスクはJetBrains AIクレジットではなくGitHub Copilotのプランを使います。ただし、個々のタスクで個人プランと組織プランのどちらを使うかを利用者が選ぶことはできません。個人のCopilotを契約しているから会社のAir組織でも必ずその契約が使われる、という前提は避けてください。組織の管理者がCopilotを無効にしている場合や、開始時に契約・クレジットが利用できない場合はタスクが失敗します。

Airのガバナンスや分析画面にはCopilotの利用量が含まれず、Air管理者はAir内でCopilotの支出上限を設定できないと案内されています。予算や利用量を管理したい組織は、GitHub側の契約、ポリシー、利用量確認方法を別に見る必要があります。Airの画面に数字が出ないことを「使っていない」「無料で使えている」と読み替えないでください。費用管理は、請求元と表示場所を結び付けて確認します。

JetBrains AirでCopilotを安全に試す手順

導入時は、画面にCopilotが表示されたかだけで終わらせず、どの環境で、どの契約を使い、どこへ変更が保存されるかを確認します。ローカルとクラウドを混ぜると、手元にあるはずのファイルが見つからない、組織の利用量へ反映されない、管理者に許可された範囲を越えてしまう、といった問題が起きやすくなります。以下の順番で小さく試すと切り分けが楽です。

画面と環境を見分ける

最初に、Airのエージェント選択欄でGitHub Copilotが選ばれていることを確認します。次に、実行環境がLocalかCloudかを見ます。ローカルなら開いているIDEとプロジェクト、クラウドならリポジトリとリモートブランチを確認してください。同じプロジェクト名でも、手元の未コミット変更とクラウドのリモートブランチは内容が違う場合があります。作業を依頼する前に、基準となるコミットと変更対象を明示します。

複数のセッションを並行させる場合は、同じファイルを同時に変更しないよう担当範囲を分けます。Airは並行作業を追いやすくしますが、競合を自動で消してくれるわけではありません。片方にテスト、もう片方に文書など、境界をはっきりさせると安全です。セッション名、対象ブランチ、目的、完了条件を最初に書いておけば、レビュー時にどの変更を採用するか判断しやすくなります。

小さな課題で権限を確認

初回は、依存関係を大きく変えない課題を選びます。たとえば既存テストの説明、壊れているリンクの確認、変更案だけの提示が向いています。読み取り、コマンド実行、ファイル更新、コミットやプッシュはそれぞれ別の行為です。エージェントがどこまで自動で進める設定なのか、確認を求める場面はどこかを見ます。予想外の操作が提案されたら、目的へ必要かを確認してから進めてください。

クラウドでは、ネットワーク経由で外部パッケージを取得できるか、テストに必要なサービスへ到達できるかも確認します。制限がある場合は、エラー内容を保存し、管理者へ必要な宛先と用途を伝えます。「動かないから制限を全部外す」という対応は避けましょう。ローカルなら、手元の秘密ファイルや開発用データをエージェントが読む必要が本当にあるかを見直します。最小限の権限で完了できる形が理想です。

変更をレビューして戻せる形に

エージェントの作業後は、差分、テスト結果、未解決事項を確認します。成功という返答だけで採用せず、実際のファイルとコマンド結果を見てください。大きな差分は機能ごとに分け、意図しない整形や依存関係の更新が混ざっていないかを確認します。クラウドタスクでは状態が次へ残らないため、再実行に必要な手順がリポジトリ側へ記録されているかも大切です。

元へ戻せるよう、作業前のブランチとコミットを記録します。未コミット変更があるローカル環境では、別ブランチや作業ツリーを使い、利用者の変更を上書きしません。クラウドではタスクごとに新しい環境が作られますが、リモートへ反映した変更は残ります。プッシュやマージの前に、担当者がレビューする入口を設けましょう。自動化の便利さと、変更の責任は別です。

チーム導入の確認表

チームで導入する場合は、利用者ごとの試行ではなく共通の確認表を作ります。Air Teamsが有効な組織か、Copilotの利用対象者か、管理者が統合を有効にしたか、どのリポジトリを許可するか、利用量をどこで確認するかを一行ずつ記録してください。Airの分析にCopilot利用が含まれない点も、管理担当と開発担当の双方へ共有します。

作業ルールには、秘密情報を指示文へ貼らない、同じブランチを複数セッションで無計画に変更しない、テスト結果を実ファイルで確認する、エラー時に権限制限を迂回しない、という基本を入れます。クラウド作業は手元を汚しにくい反面、実行環境が毎回新しくなるため、暗黙のローカル設定に頼った手順は失敗しやすくなります。再現可能な構成へ整えることが、エージェント活用の土台になります。

よくある質問

導入記録には、使えた機能だけでなく未確認の条件も残してください。実際に試していない契約、OS、組織設定まで利用可能と書かず、確認できた環境と公式資料の一般条件を分けます。別の利用者が同じ結果になるとは限らないためです。

レビュー担当者は、エージェントが提示した説明だけでなく、Git差分と実際のテスト結果を確認します。変更が目的の範囲を越えていないか、依存関係や設定ファイルが意図せず変わっていないか、既存の利用者向け動作を壊していないかを見る流れです。テストが実行できなかった場合は、その理由と残るリスクを明記します。「完了」と表示されたことを品質合格の代わりにせず、人が採用判断できる証拠をそろえます。

AirとCopilotの統合を社内へ案内するときは、便利な機能だけでなく利用できない範囲も書きます。個人と組織のプランをタスクごとに選べないこと、Airの分析へCopilot利用量が含まれないこと、クラウドの状態がタスク間で残らないことは、導入前に知っておきたい条件です。画面や契約が変わる可能性があるため、案内文には確認日と公式発表へのリンクを添え、古い手順を固定化しないようにします。

導入後の運用では、利用者がどの経路でタスクを始めたかを記録します。IDEのLocal、IDEのCloud、ブラウザのAirでは、見えているファイルと認証の境界が異なります。問題が起きたときに「Airから使った」だけでは切り分けられません。開始画面、環境選択、リポジトリ、ブランチ、Copilotの選択状態、表示されたエラーを一組で残すと、管理者へ相談するときも状況を再現しやすくなります。

クラウドタスクでパッケージ導入やテストが失敗した場合は、ローカルで成功したからクラウド側の不具合だと決めつけないでください。OS、コンテナ、ネットワーク、環境変数、秘密情報、利用できるコマンドが違う可能性があります。エージェントへ環境情報の確認と失敗したコマンドの提示を求め、再現条件を保存します。安全な範囲で依存関係を固定し、同じコミットからもう一度実行できる状態へ整えます。

セッションを複数動かすときは、完了報告の形式もそろえましょう。変更したファイル、実行したテスト、未実施の確認、既知の制限、次に人が見る場所を短くまとめます。Airの画面で結果を見られても、重要な判断が会話の中だけに残ると、後で別の担当者が追えません。採用した決定はリポジトリの文書や課題管理へ移し、不要な長い会話や秘密情報をコピーしない運用が扱いやすいです。

トラブル時の切り分け

Copilotが一覧に出ない場合は、Air自体の更新状態、対応するプラグイン、GitHubアカウント接続、組織のポリシーを順に確認します。ローカルだけ出ないのか、クラウドだけ出ないのかで調べる場所が変わります。会社の組織では、利用者が契約対象でもAir管理者が統合を無効にしている場合があります。個人の判断で別アカウントへ切り替えず、組織の管理手順へ沿って確認してください。

クラウドタスク開始時に契約やクレジットのエラーが出た場合は、Airの支出設定を探し続けるのではなく、GitHub側のプランと組織割り当てを確認します。Airの分析にはCopilot利用が含まれず、Air管理者もCopilotの支出上限を設定できないためです。請求元、利用者の席、組織ポリシー、契約の有効期間を分けて確認します。表示された文言と確認日時を残すと、後の仕様変更とも比較できます。

タスクは始まるがコードへ到達できない場合は、VCS ProvidersのGitHub接続、対象組織へのアクセス、リポジトリ、リモートブランチを確認します。ブラウザで見えるリポジトリと、Airが選択できるリポジトリが一致するとは限りません。権限を広げる前に、読み取りだけで足りるのか、書き込みが必要なのかを明確にします。作業の目的に不要な組織全体の権限を求めないことが大切です。

運用後に見直す項目

導入から一週間ほどは、タスクの成功率、レビューで戻した回数、平均の待ち時間、失敗理由を記録します。コード行数だけで効果を測ると、不要な変更が増えた場合を見落とします。人が修正した時間、テスト不足、競合、権限待ちも含め、チームが安全に完了できたかを見てください。数件の成功だけで全リポジトリへ広げず、作業種類ごとに適性を判断します。

クラウド環境が毎回新しい点は、再現性を見直すきっかけになります。ローカルにしかない設定がなければ動かないプロジェクトは、開発者が変わったときにも詰まりやすいものです。セットアップ手順、依存バージョン、テストコマンド、必要なサービスを文書化し、秘密は正式な保管先から渡します。エージェントのためだけでなく、新しく参加した人にも役立つ改善です。

公式の統合は今後も更新される可能性があります。Airの画面、対応IDE、組織条件、利用量の表示場所が変わったら、古い手順をそのまま残さないでください。確認日と参照した公式発表を運用メモへ残し、四半期ごとや大きな更新時に見直します。実際に利用できた条件と、公式に書かれている一般条件を区別しておくと、別の組織へ同じ結果を約束する誤りを防げます。

JetBrains AirでCopilotは無料で使えますか？

AirのクラウドタスクはJetBrains AIクレジットではなくGitHub Copilotのプランを使うと案内されています。利用できる契約や組織条件をGitHub側とAir側で確認してください。

個人のCopilot契約を会社のAirで選べますか？

個々のタスクで個人プランと組織プランのどちらを使うかを選ぶことはできないと説明されています。組織の設定と利用対象を管理者へ確認します。

ローカルとクラウドで同じファイルが見えますか？

必ずしも同じではありません。ローカルは手元の作業状態、クラウドは指定したリポジトリとリモートブランチを基準にします。未コミット変更は自動で共有されません。

クラウドタスクの環境は次回も残りますか？

公式発表では、タスクは新しい仮想マシン上のDockerコンテナで動き、状態はタスク間で持ち越されません。再現に必要な設定はリポジトリや正式な構成へ残します。

Air管理者はCopilotの支出上限を設定できますか？

Air内ではCopilotの支出上限を設定できず、利用量もAirのガバナンス分析に含まれないと案内されています。GitHub側の管理方法を別に確認してください。

JetBrains AirでCopilotを使うまとめ

GitHub CopilotをJetBrains Airから使うと、ローカルのIDE作業と、隔離されたクラウド作業を目的に応じて選べます。大切なのは、AirにCopilotが表示されたことを導入完了と考えず、実行場所、契約、組織、管理者設定を分けて確認することです。クラウドは新しい環境で動き、状態を引き継がないため、再現可能な設定とレビュー手順が欠かせません。

まずは読み取り中心の小さな課題で試し、差分とテスト結果を人が確認できる流れを作ってください。便利な統合だからこそ、どこで何が動いたかを説明できる状態が安心につながります。

参照した一次情報