モバイルアプリチームのAI Agent活用戦略 ― GitHub Copilotで開発プロセスを自律化する

はじめに

こんにちは！モバイルアプリチームの二宮です。

AIエージェントは、ソフトウェア開発の現場でも活用が広がりつつあると感じています。コード補完にとどまらず、タスクの自律的な実行やマルチエージェント連携など、活用できる領域も広がっています。

一方で、まだ発展途上の領域でもあり、新しい機能やコンセプトも継続的に登場している印象です。そのため、キャッチアップするだけでも大変だと感じる場面があるのではないでしょうか。

モバイルアプリチームでは、プロダクト思考を大切にし、ユーザーにとって価値のある機能や体験に向き合う時間を増やすために、GitHub Copilotを利用したAIエージェントによる開発プロセスの自律化に取り組んでいます。GitHub Copilotには Instructions、SKILL、サブエージェントといった機能がありますが、私たちも「結局どれをいつ使えばいいの？」という疑問を持つ場面がありました。

私たちはこの使い分けを「必要な時に必要な情報をコンテキストウィンドウに載せる」という考え方で設計しています。本記事ではその考え方の詳細と、各機能の活用事例を紹介します。

なぜ「必要な時に必要な情報を載せる」必要があるのか

AIに載せられる情報量には上限がある

AIエージェントが1回の推論で参照できるトークン数には上限があり、これをコンテキストウィンドウと呼びます。GitHub Copilotの場合、利用モデルによってサイズは異なりますが、以下のように確認できます。

コンテキストが肥大化すると、必要な情報を参照しづらくなる

GitHub Copilot では、コンテキストウィンドウが埋まると会話履歴が自動的に compact され、過去の文脈が要約される仕組みがあります。

一方で、要約・圧縮によってタスク遂行に必要な情報が十分に残らない場合、出力品質に影響する可能性があります。Anthropic は、長いコンテキストを扱うエージェントでは context pollution や information relevance の問題が起きうると説明しています。

さらに、long-running application development に関する記事では、長時間タスクにおいてコンテキストウィンドウが埋まるにつれてモデルが一貫性を失いやすくなることや、コンテキスト上限が近いと作業を早めに畳みにいく "context anxiety" が起きうることも紹介されています。同記事では、ビルドを扱いやすい単位に分解し、セッション間では構造化された成果物で文脈を引き継ぐこと、必要に応じて新しいエージェントにコンテキストをリセットすることが有効だったと述べられています。

つまり、情報を詰め込めば詰め込むほど良い結果になるとは限りません。むしろ、タスクに必要な情報を選び、適切なタイミングでコンテキストに載せる設計が重要になります。これが「はじめに」で述べた「必要な時に必要な情報をコンテキストウィンドウに載せる」という思想の背景です。

参考文献:
- Effective context engineering for AI agents - Anthropic
- Harness design for long-running application development - Anthropic

私たちのアプローチ：情報の性質で置き場所を分ける

では、「必要な情報だけを載せる」を実践するにはどうすればいいのでしょうか？　すべての情報を一律に扱うと、必要な情報の取捨選択が難しくなりやすいと考えています。そこで私たちが着目したのが、情報の性質によって置き場所を分けるというアプローチです。

GitHub Copilotでは、私たちの活用上、Instructions・SKILL・サブエージェントという3つを情報の置き場所／実行単位として使い分けています。それぞれコンテキストへの載せ方や扱い方が異なるため、情報の性質に応じて3つを使い分けることにしました。

	Instructions	SKILL	サブエージェント
情報の性質	全タスク共通で参照したい知識	特定タスクで参照したい専門知識	子エージェントに委譲したい専門知識
コンテキストの振る舞い	原則として常に参照される前提で扱う	必要なときに参照させる前提で扱う	親とは別のコンテキストで処理させやすい
粒度	リポジトリ全体	タスク単位	役割単位（親エージェントから委譲）
活用例	コーディング規約、アーキテクチャ方針	脆弱性調査の自動化、SKILL作成支援	テスト・実装・リファクタリングを別々のサブエージェントに委譲
参考文献	Adding repository custom instructions for GitHub Copilot	About agent skills	About custom agents

考え方はシンプルです。

どのタスクでも必要な情報 → Instructions に置く
- 常に参照される前提で扱いたいから。例：コーディング規約、アーキテクチャ方針
- ただし常にコンテキストを消費する可能性があるため、本当に全タスク共通で必要な情報に絞るのが望ましいと考えています。「あると便利」程度の情報はSKILLへ寄せる方針です
特定タスクでだけ必要な情報 → SKILL に置く
- 必要なときだけ参照できればよいから。例：脆弱性調査手順、マイグレーション手順
- 使われないSKILLは通常の会話コンテキストを圧迫しにくいため、専門知識を比較的増やしやすいと考えています。ベテランのノウハウをSKILL化することで、チームの知識共有にも活用できると考えています
役割ごとに分離したい大きな仕事 → サブエージェントに委譲する
- 親とは別のコンテキストで処理させられるため、親側のコンテキスト消費を抑えやすいと考えています。例：TDDのテスト・実装・リファクタリングを別々のサブエージェントに分離
- 親のコンテキスト消費を抑えつつ、専門性の高い出力を得やすくなると考えています。InstructionsやSKILLが「親のコンテキスト内で情報を管理する仕組み」だとすると、サブエージェントは「処理するコンテキストを分けるための仕組み」と捉えています
- 特に、実装する役割とレビューする役割のように、判断基準が異なる作業はロールを分けることで、自己評価に寄りすぎないフィードバックループを作りやすくなります

応用編：TDDオーケストレーターエージェント ― 自律的にTDDを回す

ここまでは、Instructions・SKILL・サブエージェントの使い分けという情報設計の話をしてきました。ここからは、それらを組み合わせて実際にモバイルアプリチームで構築したTDDオーケストレーターエージェントの取り組みを紹介します。

このエージェントは、規約を参照し、テスト結果を見ながら修正し、不明点はユーザーへの質問で解決しながら、TDDを自律的に進めることを目指したエージェントです。

全体作業フロー

このフロー全体を統括するのがTDDオーケストレーターエージェント（親エージェント）です。オーケストレーターはtodosツールで全体のタスクリストを管理しながら、各ステップを専門のサブエージェントに委譲して進行します。

ここで重視しているのは、単に作業を細かく分けることではなく、ロールごとにコンテキストと判断基準を分けることです。

Anthropicの記事では、計画を立てる Planner、実装する Generator、動作確認して評価する Evaluator という3エージェント構成が紹介されています。特に「作業するエージェント」と「判断・評価するエージェント」を分けることは、生成物に対する甘い自己評価を避け、具体的なフィードバックをもとに改善しやすくするための有効なレバーだと説明されています。

私たちのプロダクト開発でも同じ考え方を取り入れ、1つのエージェントに調査・設計・テスト・実装・レビューをすべて担わせるのではなく、ロールごとにサブエージェントを分けています。これにより、各サブエージェントは自分の責務に集中し、親エージェントは全体の流れと意思決定をオーケストレーションしやすくなります。言い換えると、サブエージェントは「作業を並列化するための仕組み」だけではなく、コンテキストを分離し、評価観点を外部化するための設計でもあります。

フローのポイントは次の通りです。

調査 → 設計 → テストコード実装 → 機能実装 → テスト実施 → コードレビュー → 完了 という一連のTDDサイクルを、オーケストレーターが各サブエージェントにタスクを委譲しながら進行できるようにしています
テスト失敗時はオーケストレーターが結果を確認し、必要に応じて機能実装サブエージェントに修正を再委譲します
コードレビューで指摘がある場合はコード修正に戻り、レビューがクリアになるまでループさせる設計にしています
各ステップでサブエージェントが発見した不明点や追加タスクはオーケストレーターに返され、オーケストレーターがaskQuestionsでユーザーに質問したり、todosでタスクリストを更新したりして、全体の進行をコントロールします

なぜ自律的に回せるのか：`todos` と `askQuestions` の活用

このエージェントが自律的にTDDを進められる鍵は、GitHub Copilotが提供する2つのツールにあります。

	役割	TDDオーケストレーターでの活用
`todos`	タスクの動的な管理・追跡	サブエージェントからの追加タスクや未解決事項をTodoリストとして管理し、オーケストレーターがタスクを修正・追加しながら進行できるようにする
`askQuestions`	エージェントからユーザーへの質問	仕様の不明点やビジネスロジックの判断が必要な箇所で、エージェントがユーザーに確認してから実装に進めるようにする

この2つのツールにより、エージェントは「何をすべきかを自分で管理する」、「わからないことは人に聞く」という、人間の開発者に近い振る舞いに近づけられると考えています。

実際の出力例を紹介します。

todosツールでは、エージェントがタスクの進捗状況をリアルタイムに把握し、完了・進行中・未着手を管理しています。人間がTodoリストを更新するように、サブエージェントから返ってきた結果に応じてタスクを動的に追加・修正していく様子がわかります。

todos ツールの出力例

askQuestionsツールでは、エージェントが実装を進める中で「ここは自分だけでは判断できない」と認識した箇所をユーザーに質問しています。推測で実装を進めるのではなく、確認してから進むというアプローチにより、手戻りを減らすことにつながると考えています。

askQuestions ツールの出力例

まとめ

本記事で紹介した使い分けの考え方を改めて整理します。

	判断基準	コンテキストの扱い方
Instructions	どのタスクでも常に守りたいルール	原則として常に参照される前提で扱う
SKILL	特定のタスクでのみ必要な知識・フロー	必要なときだけ参照させる前提で扱う
サブエージェント	別のコンテキストで専門的に処理させたい仕事	親とは別のコンテキストで処理させやすい