GitHub Copilot のクロスリポジトリ対応と、APM・Wazaによるスキル配布基盤を構築する

設計ドキュメントと実装コードが別リポジトリに分かれているプロジェクトでは、GitHub Copilot のようなコーディングエージェントも、リポジトリをまたいで情報を参照できる必要があります。本記事では、GitHub Codespaces・APM（Agent Package Manager）・Waza を組み合わせて、クロスリポジトリでの AI 駆動開発と Copilot スキルの一元管理を実現した構成を紹介します。

やりたいこと / 前提

あるプロジェクトでは、設計ドキュメントを置くプロジェクトリポジトリ（P）と、実装コードを置く実装リポジトリ（I）が分かれています。さらに同一プロジェクト内に複数チームが存在し、チームごとに P1/I1、P2/I2……という単位でリポジトリが増えていく体制でした。

人間が開発していた頃から、実装を進める際には対応するプロジェクトリポジトリの設計書を参照する、という作業が発生していました。AI 駆動開発（AIDD）に移行しても、この「リポジトリをまたいだ参照」という本質的な作業は変わりません。むしろ、コーディングエージェントが同じことをできる基盤を用意する必要が出てきます。

もう一つの課題が、GitHub Copilot に読み込ませるスキルの管理でした。スキルは基本的に複数リポジトリで使い回したいものですが、各リポジトリに個別に置いて管理を任せてしまうと、リポジトリごとにスキルの内容やバージョンがバラバラになってしまいます。

構成 / アーキテクチャ

登場するリポジトリは3種類です。

• プロジェクトリポジトリ（P）：設計・ドキュメントを管理
• 実装リポジトリ（I）：実装のソースコードを管理
• スキルマーケットプレスリポジトリ：GitHub Copilot のスキルを集中管理するプライベートリポジトリ

このうち P・I はプロジェクト開始時から存在していたリポジトリで、そこに新たにスキルマーケットプレスリポジトリを追加し、各リポジトリがそこから最新のスキルを取得する形にしています。

手順

1. Codespaces にリポジトリをまたぐ権限を与える

GitHub Codespaces のコンテナ環境に発行されるトークンは、既定では開いたリポジトリだけに権限を持ちます。そのため、プロジェクトリポジトリで Codespaces を起動しても、実装リポジトリを普通には参照できません。

これは devcontainer.json の customizations.codespaces.repositories でリポジトリ単位の権限を明示することで解決します。

{
  "customizations": {
    "codespaces": {
      "repositories": {
        "my-org/implementation-repo": {
          "permissions": {
            "contents": "write"
          }
        }
      }
    }
  }
}

contents: write を指定すると、その Codespaces から対象リポジトリの任意のブランチへ push できるようになります。main ブランチも含めてどのブランチにも書き込める権限のため、実運用では専用の作業ブランチを切ってそこにコミットしていく運用にしています。

2. 作業用ディレクトリでペアリポジトリを手元に持つ

設計と実装は別リポジトリなので、Codespaces 起動時に対応するリポジトリを手元に置いておく必要があります。ここでは git worktree コマンドは使わず、規約として用意した作業用ディレクトリに、通常の git clone でペアとなるリポジトリを配置する形にしました。

具体的には、Codespaces 初回起動時に一度だけ実行されるタスク（postCreateCommand から呼び出す形）でペアリポジトリのクローンを行い、以降の取得・同期は別タスクとして用意して、必要なタイミングで実行する運用にしています。

3. スキルマーケットプレスと APM によるスキル配布

GitHub Copilot のスキルをリポジトリごとにバラバラに SKILL.md として置くのではなく、スキルマーケットプレスリポジトリに集約し、そこから APM（Agent Package Manager） で各リポジトリに配布する構成にしています。

APM は Microsoft が公開している AI エージェント向けのパッケージマネージャーで、npm や pip のようにスキル・プロンプト・指示書・MCP サーバーなどを apm.yml に宣言し、apm install 一発で GitHub Copilot や Claude Code など各エージェント向けのディレクトリに展開できます。

配布の流れは次の通りです。

1. スキルマーケットプレスリポジトリに marketplace.json を置き、配布するスキルの格納場所を定義する
2. 配布先リポジトリで apm marketplace add を実行すると、そのマーケットプレスを参照する apm.yml が生成される
3. apm.yml があるディレクトリで apm install を実行すると、マーケットプレスから最新のスキルがフェッチされ、リポジトリ内に展開される

このコマンドを devcontainer.json の postCreateCommand に仕込んでおくことで、Codespaces を起動するたびに最新スキルが同期された状態でスタートできます。APM のインストール先ディレクトリは .gitignore に登録し、配布先リポジトリ側では中身をコミット管理しないようにしています。

ハマったポイント

権限設定の意図が伝わりにくい contents: write という権限名だけでは、「何が」「どこまで」できるようになるのかが直感的に伝わりません。レビューの場でも「このリポジトリに対して Codespaces からプッシュできる権限を許可している、という認識で合っているか」という確認が入りました。設定を導入するドキュメントには、権限名だけでなく「どのブランチに何ができるようになるか」を具体的に書いておくべきだと感じています。

スキルマーケットプレスへの逆流フローが手動で煩雑 プロジェクト側のリポジトリでスキルを改善した場合、その差分をスキルマーケットプレス側にも反映する必要があります。現状は、開発者自身がスキルマーケットプレスリポジトリを作業用ディレクトリにクローンし、同じ修正を手動でコピーしてコミット・プッシュ（場合によってはプルリクエスト）するフローになっています。

レビューでは「プロジェクト側で既にアップデート済みのスキルを、もう一度手動でマーケットプレス側にコピーするのは手間がかかる」という指摘があり、コマンド一つで差分をプルリクエスト化できるような仕組みが望ましい、という議論になりました。ここは仕組み化できていない部分で、今後の課題です。

スキルの品質担保 各リポジトリから自由にスキルマーケットプレスへ書き込めるようにすると、質の低いスキルが混入するリスクがあります。この対策として、Waza（Microsoft が公開しているスキル評価用 CLI）によるスキル評価を GitHub Actions 上で走らせ、プルリクエスト時などのタイミングで品質ゲートとして機能させる運用を検討しています。具体的にどのタイミングで評価を走らせるかはまだ確定しておらず、引き続き検討中です。

まとめ

今回の構成は次の3点に整理できます。

一方で、スキルマーケットプレスへの改善の取り込みは依然として手動運用が中心で、開発者への負荷が課題として残っています。プルリクエストベースでの取り込みや、Waza による品質評価を組み込んだ品質ゲートの整備など、改善を継続していく予定です。

複数リポジトリにまたがる AI 駆動開発の基盤づくりについて、社内で継続的に改善を進めています。同様の課題をお持ちの方はお気軽に KDDIアイレットへご相談ください。