はじめに
こんにちは。
株式会社アイスタイルで @cosme モバイルアプリ（Android / iOS）のエンジニアをしている鈴木と申します。
今回は、GitHub Copilot cloud agentをプロダクト開発で約3か月運用してみて、実際に何が変わったのか、どこに課題があるのかを振り返っていきます。
なお、この記事の内容は2026/06時点の情報です。
@cosmeアプリの構成について
本題に入る前に、当時の@cosmeアプリの構成について説明します。
@cosmeアプリは、Android、iOS、Shared（共通モジュール）の3つに分かれていました。Android側とiOS側は、それぞれSharedをsubmoduleとして取り込み、リポジトリも別々に管理していました。
Sharedモジュールに至る経緯については、過去の記事でも紹介しています。
Compose Multiplatform(KMP)で未来を切り拓く: @cosmeアプリの取り組み事例紹介
Compose Multiplatform(KMP)をプロジェクトで運用してみて2年が経過しました
この構成は、OSごとに独立して開発を進めやすい一方で、Sharedの変更を両OS側から追いかける必要がありました。
Copilot導入直後に見えた課題
Copilot導入直後は、Android側とiOS側からそれぞれGitHub Copilotに指示を出していました。
しかし、Sharedモジュールの文脈をAndroid側・iOS側のどちらからも十分に参照しづらく、共通部分を前提にした修正や提案が活きない場面がありました。
AIを使って開発効率を上げたい意図はあったものの、分かれたリポジトリ構成のままだとAIが全体像を把握しづらい、という課題が明確になりました。
モノレポ化を決断して変化したこと
そこで、3つのリポジトリを1つに統合する、いわゆるモノレポ化を決断しました。
モノレポ化では、既存履歴を失わないことと、現在の開発フローを大きく壊さずに移行することを重視しました。
そのため統合にはgit filter-repoを利用し、親リポジトリ配下にAndroid、iOS、Sharedの各ディレクトリを置く形へ整理しています。
リポジトリ統合後は、AIがShared側の修正も含めて参照できるようになりました。
その結果、Android / iOSのどちらの観点でも共通コードを前提にしたやり取りがしやすくなりました。
モノレポ化で苦労したこと
モノレポ化により、パス構成が全体的に変わったことが大きな影響になりました。
特に、既存で自動化していた仕組みのパス指定を見直す必要がありました。
例えば、@cosmeアプリではGitHub ActionsでCI/CD環境を構築しています。GitHub Actionsでは、pathsを指定して特定パスでのみworkflowを動かす設定を行っています。
移行前はAndroid、iOS、Sharedがルートに存在していたため単純でしたが、移行後はworkflowごとに対象ディレクトリの指定を再調整する必要があり、関連する設定を一通り修正しました。
このほかにも、パス変更に伴ってshellスクリプトの修正や動作確認が必要になりました。
GitHub Copilot cloud agentを導入してみて
弊社ではGeminiとGitHub Copilotの両方が利用可能で、@cosmeモバイルアプリチームはCopilotを中心に活用していました。
一方で、cloud agent導入前は、Geminiでのチャット相談や実装の参考利用が中心で、AI活用がチーム全体に広がりきっている状態ではありませんでした。
そこでcloud agentをより使いやすくするために、社内で利用しているSlackとGitHubアプリを連携し、SlackからAIを利用できる運用を整えました。
Slack連携方法
連携にはGitHubのSlackアプリを利用します。
未導入の場合は、まずワークスペースへインストールしてください。
指示の出し方は次の通りです。
@GitHub
指示したい内容
in repo=OWNER_NAME/REPO_NAME branch=BRANCH_NAME
基本的には@GitHubメンションを付け、最後にrepoとbranchを指定すると、タスク実行からプルリクエスト作成まで自動で進めてもらえます。
指示を送るとSlackスレッドで返信が返り、View SessionをクリックするとAIが今どの作業をしているか確認できます。
Slackから指示を投げるようになって変わったこと
Slackから日常的に指示を投げる運用に変えてからは、モノレポ化の効果もあり、複数作業を並行しやすくなり、AI活用の量が明確に増えました。
また、Slack上にプロンプトが残ることで、メンバー同士で「どう指示すると期待した結果が出るか」をオープンに共有しやすくなりました。
3か月経過時点でチーム全体にアンケートを取ってみましたので、その結果を元に変化を見ていきます。
利用頻度については、「ほぼ毎日」利用するヘビーユーザー層と、「週に1〜2回程度」のライトな利用にとどまる層に大きく分かれて、利用期間が長ければ毎日使うようになるというわけではなく、個人の業務内容（開発・実装の割合や、調査・レビュー業務の多さなど）や、個人のスタイルによって利用頻度が定着していると考えられます。
回答者全員が6以上の評価をつけており、業務効率に対して全く貢献していない（低い評価）と感じているユーザーはいません。
大半のユーザーがSlack版 Copilot Agentの導入によって業務が効率化されたと感じています。また、特定のユーザーにとっては劇的な業務改善をもたらしていることがわかります。
また、色々とヒアリングしたところ、次のような声がありました。
- Slackに依頼している間に別作業を進められる
- AIが独立して動くため、調査タスクを並行で回せる
- お問い合わせ調査、仕様調査、不具合調査、ドキュメント化の用途で活用し、時間のかかる作業を委任できる
モノレポ化後は、以前のようにAndroid/iOSそれぞれで個別に調査を分担しなくても、Slackで指示を出して調査ドキュメントの完成を待ち、通知後に各担当者がレビューする進め方が取りやすくなっています。
AIによる開発をさらに進めるためのSKILL検討
Copilot活用が進むにつれて、SKILL.mdの整備も検討するようになりました。
SKILLとは？
エージェントスキルとは、Copilotが特定タスクでより高いパフォーマンスを出すために、必要に応じて読み込む指示・スクリプト・リソースをまとめたフォルダーです。
Adding agent skills for GitHub Copilot - GitHub Docs
特定ケース向けの詳細な指示を事前に定義しておくことで、Copilotが必要時に読み込んで利用できます。
配置は次の通りです。
.github/skills/{機能名}/SKILL.md
記載例は次の通りです。
---
name: {スキル名称}
description: {スキルで実現すること、発火条件について記載する}
---
{具体的な指示を書く}
スキル名称は任意で問題ありません。
descriptionには「何をするスキルか」と「どんな時に読み込んでほしいか」を書くのが重要です。
SKILLを作りたいが、作り方が分からない場合
公式公開のSKILLがあるため、まずは自チームの技術スタックに近いものを探すのがおすすめです。
Android向けであれば次が参考になります。
また、第三者公開のSKILLもGitHub上にあるため、良さそうなものを調査したうえで、既存コードベースに合わせてAIに作成してもらい、成果物を修正していくアプローチも有効でした（権利周りの確認は必要です）。
まず既存資産を探し、叩き台を作ってから自チーム向けに磨き込む流れが実践しやすいと感じています。
レビューについて
実装だけでなく、レビューにもAIを活用しています。
レビュー用のカスタム指示を作成し、GitHub側で設定を行うことで、CopilotによるCode Reviewを有効化できます。
アプリ開発部では、既存のレビュー観点ドキュメントをベースにinstructionsを整備しました。
現在はAIレビューの指摘を先に反映してから、他メンバーへレビュー依頼を出すフローで運用しています。
3か月ほどAIを用いた開発を行う中で出てきた課題
chatやCLIの機能を十分に使い切れない
3か月ほどGitHub Copilot cloud agentを運用して、課題として見えてきたのは、chatやCLIの機能を十分に活用しきれていない点でした。
特に要望が多いのは、planモードの活用と自動レビュー修正です。
VSCodeなどのチャット機能で一度planモードを使って壁打ちしてから進めること、そして次に述べる形でレビュー修正を補完することを検討しています。
Slack×GitHubアプリでは柔軟性が不足する
GitHub上で使う場合は、cloud agentをAgentsタブから利用し、カスタムエージェントやモデルを柔軟に選択できます。
しかしSlackのGitHubアプリ経由では、現時点で同等の柔軟な指定が難しい状況です。
対応策として、Slack Bot × GitHub Copilot CLIの活用を検討しています。
CLIで必要機能を補完しつつ、現在の開発体験を損なわない運用方針を模索中です。
おわりに
日々進化するAIのスピードは非常に速く、すでにAIは開発における重要な相棒だと感じています。
これからもAIの進化に合わせて、開発スタイルそのものを更新し続けていきたいと思います。