ArmとGitHub、ネイティブArmでの代理開発を説明、ローカル試験とPR審査とArm64 CIを接続

Armは10月29日、GitHubとの協力によるArmネイティブの開発手順を説明した。11月1日は本サイトの技術号の日付で、元の記事の発表日ではない。組織が管理するArm計算環境でCopilot CLIが編集、ビルド、テストと障害調査を行い、その後GitHubのプルリクエストとArm64のCIで審査と再検証を行う。記事は期待できる作業上の利点を述べるが、あらゆる開発に共通する速度向上率を測定していない。

重要なのは命令を実行する場所だ。x86上で書いてビルドし、最後になってArmで試すと、依存パッケージの非対応、コンパイラ設定の違い、特定の命令セットを前提にしたコード、実行時の差を遅く発見する場合がある。開発中から対象のArm環境で命令を走らせれば、そのような失敗を変更の途中で見つけられる。エミュレーションに由来する追加の変数も減る。ただし「早く分かる」という工程上の利点が、すべての案件で一定時間の節約になると証明されたわけではない。

三つの役割は分かれている。Armはネイティブに実行し計測する基盤を提供し、Copilot CLIはコード編集やプロジェクトの命令実行を支援する。GitHubはソース管理、プルリクエスト、レビューとArm64 runnerによる自動検証を担う。Remote Controlを使うと別の端末からセッションを操作できるが、命令は引き続き組織管理のArm機で実行される。操作端末と実行端末を混同すると、テスト証拠の意味やアクセス制御の境界を誤る。

Armの例では、メディアアプリの依存関係をCopilot CLIに更新させ、その場でテストする。Arm上で動かすため、アーキテクチャに固有の失敗が早く表に出る。その後、開発者がプルリクエストを提出し、GitHub ActionsのArm64 runnerでビルドとテストを繰り返す。CIはエージェントの報告を信じるだけでなく、別環境で結果を確認する段階だ。Armは生成された変更のレビューと正しさの確認を人間の責任として残している。

最適化には対象機械の測定が必要である。ArmはCPU使用率、実行時間、遅延、メモリの挙動、スループットを例に挙げる。テストが通ることは互換性の一部を示すが、十分に高速であることは示さない。また代理の提案が速いかは、同じハードウェアと入力で変更前後を測って判断すべきだ。この記事に、全アプリへ適用できる性能改善率は掲載されていない。

組織管理の計算機を使うなら、代理が実行できる命令、アクセスできるリポジトリや資格情報も組織の規則で定める必要がある。遠隔操作が可能だからといって新しい権限を自動的に与えるわけではない。ローカルとCIでは権限や依存関係が違い得るため、両方の記録を読み、生成差分を人が審査することが重要だ。

実施するなら、Arm用ツールチェーンを準備し、管理されたArm機に対応版のCopilot CLIを配置し、代表的な変更とテストを実行する。次にPRで審査し、Arm64 CIで再実行し、正しさを確認した後で実機の性能を測る。この順序は原文の作業例から導く判断であり、本サイトが速度を実測した結果ではない。発表の要点はAI支援の編集を対象アーキテクチャの実行とレビューにつなぐことにある。