GitHub Copilot CLI、Markdownでcustom agentを標準化
Original: GitHub Copilot CLI turns Markdown files into custom workflow agents View original →
何が変わったか
GitHub Copilot CLIは、端末でコマンドを相談する道具から、チーム固有の作業手順を実行するエージェント基盤へ近づいている。GitHubはソース投稿で「Custom agents in GitHub Copilot CLI」とし、「Define roles, tools, and guardrails in Markdown」と書いた。短い投稿だが、焦点は明確だ。毎回プロンプトで説明するのではなく、リポジトリ内のMarkdownがエージェントの役割、使える道具、守るべき制約を決める。
リンク先のGitHub Blogによると、custom agentはagent profileというMarkdownファイルで定義される。置き場所は.github/agentsで、ファイル名は.agent.mdで終わり、YAML frontmatterに役割、範囲、能力、guardrailsを書く。このファイルがリポジトリに入るため、チームは通常のコードと同じようにレビューし、履歴を残し、必要に応じて改善できる。
開発組織への意味
GitHubが挙げた用途は、security audit、infrastructure as codeの準拠確認、release documentation、incident responseだ。いずれも端末で始まりやすいが、最後にはpull request用のチェックリスト、CHANGELOG、承認用サマリー、初動レポートといった共有可能な成果物が必要になる。custom agentは、その一連の手順と出力形式をMarkdownで固定し、Copilot CLIから繰り返し呼び出せるようにする。
GitHub BlogはJFrog、Dynatrace、Octopus Deploy、Armなどのpartner agentにも触れている。これは、custom agentsが個人の補助機能にとどまらず、observability、security、infrastructure operationsのような既存ツールの使い方まで含む可能性を示す。次に注目すべき点は2つある。1つはagent profileの変更がCI設定やdeploy scriptと同じ重みでレビューされるか。もう1つは、CLIで始まった作業がIDEやGitHub pull requestまで文脈を保って届くかだ。
Related Articles
GitHubはCopilot agentic harnessを5種類のtask suiteでmodel標準harnessと比較した。同じmodelとtask条件で、解決率は同等水準、token使用量は多くの構成で少ないという結果だ。
GitHubがJira issueをCopilot coding agentに直接割り当て、GitHubでdraft pull requestを生成できるintegrationをpublic previewで公開した。JiraとGitHub間のcontext switchingを減らしつつ、既存のreview・approvalルールを維持する点が中心だ。
GitHub は 2026年4月1日、Copilot cloud agent が pull request 中心の workflow に限定されなくなったと発表した。branch-first の実行、コード生成前の implementation plan、repository deep research が今回の中心機能だ。