GitHub Copilotのエージェント的機能を最大限に活用する方法

How to maximize GitHub Copilot's agentic capabilities - The GitHub Blog Ari LiVigni·@arilivigni February 2, 2026 | 5 minutes Share:

Modern engineering work rarely lives in a single file. Real systems evolve across years of incrementally layered decisions—some good, some accidental. A single feature request (“Add tagging to notes,” “Refactor the validation layer,” “Support a new consumer on our API”) often touches controllers, domain models, repositories, migrations, tests, documentation, and deployment strategy.

Copilot’s agentic capabilities don’t replace your judgment in these situations—they amplify it. When used well, Copilot becomes a partner in system design, refactoring, modernization, and multi-file coordination.

This guide focuses on architecture-aware, multi-step workflows used every day by staff engineers, but written to be accessible for earlier-career engineers who want to understand how senior engineers think—and how Copilot can accelerate their own growth.

It draws on four GitHub Skills exercises (linked below), and builds toward a complete, real-world scenario: extending a small modular Notes Service with a tagging subsystem, refactoring a validation layer, designing a safe migration, and modernizing tests.

You’ll get the most out of this guide if you have:

GitHub Copilot with agent mode enabled

Some familiarity with service-layer architectures (Node, Python, Go—language doesn’t matter

Copy a GitHub Skills exercise template to your handle or organization (use the green “Copy Exercise” button)

A willingness to let Copilot propose solutions—and the judgment to inspect and challenge them

If you’re earlier in your career, don’t worry. Each section explains why these patterns matter and how to practice them safely.

Using Copilot for system design and decomposition (not just scaffolding)

Senior engineers rarely begin by writing code. They begin by identifying boundaries: domain logic, data access, interfaces, and how modules should interact.

Copilot agent mode can help by revealing structural issues and proposing architectures.

Analyze this service and propose a modular decomposition with domain, infrastructure, and interface layers. Identify anti-patterns, coupling issues, and potential failure points. You’ll typically get back:

Duplication or tight weaving of responsibilities

Testability and observability implications

This transforms Copilot from an autocomplete tool into a design reviewer.

You can push further by asking it to compare architectures:

Compare hexagonal architecture vs. layered architecture for this codebase. Recommend one based on the constraints here. Include tradeoffs. Want to try it yourself? Use these proposals as starting points.

Building a modular service using agentic workflows

Once boundaries are defined, Copilot can coordinate changes across modules.

Implement the domain, controller, and repository layers as distinct modules. Use dependency inversion to reduce coupling. Document assumptions and contracts for each module. Copilot will typically generate:

Controller logic calling domain services

A short Markdown summary describing each module

For earlier-career engineers, this provides exposure to real engineering patterns. For senior engineers, it provides leverage and reduces boilerplate overhead.

Feature work with architectural awareness (example: tagging subsystem)

Adding a tagging subsystem is a deceptively simple request with meaningful architectural implications.

Even this single feature forces decisions across the system:

Data modeling: embedded tags vs. normalized tables vs. many-to-many relationships

Search behavior: how tags affect indexing, filtering, and relevance

API contracts: whether tags are first-class resources or an implementation detail

Validation boundaries: where constraints and invariants are enforced

Migration and rollout: additive vs. breaking changes and rollback strategy

Before touching code, ask Copilot to map the impact.

Propose the architectural changes required to add a tagging subsystem. Identify migration needs, cross-cutting concerns, caching or indexing implications, and potential regressions. Copilot may identify:

Tag–note relationships (one-to-many or many-to-many)

Implications on external API consumers

This is the staff-level lens that Copilot can help junior developers adopt.

Implement the tagging domain model, schema changes, repository updates, and controller logic. Update tests and documentation. Show each change as a diff. Example output (simplified)

ALTER TABLE notes ADD COLUMN tags TEXT DEFAULT '[]'; Domain model example:

export interface Tag { id: string; label: string; } export interface Note { id: string; title: string; body: string; tags: Tag[]; } Controller update (partial):

await noteService.addTag(noteId, { label: req.body.label }); This is where agent