本题です。
生成AIによるコード生成は、これまで時間をかけて実装していたコードを、瞬時に生成することができます。生成AIの生産性があれば、これまで時間が足りず諦めていたことにも取り組めるようになります。今回は静的解析ツールの导入の壁を、GitHub Copilotで超えたいと思います。

静的解析ツール

静的解析ツールの导入

コードが规约通りに実装されているのか、もしくは、不具合になる実装をしていないか等を机械的にチェックする仕组みとして静的解析ツールがあります。静的解析ツールを导入することにより、规约に反するコードは自动的に弾かれ、常に高品质なコードを维持することができ、レビューアの负担が軽减されます。

しかし、多くのプロジェクトでは静的解析ツールを导入しておらず、その多くが人の目によるレビューによりチェックしています。もちろん、人によるレビューには限界があるため、规约に反するコードや潜在的な不具合が见逃され、気付けば低品质なコードがそのままリリースされてしまいます。

その問題に気付いたプロジェクトは静的解析ツールの导入を試みますが、いざ静的解析ツールを実行すると数百件（規模によっては数千件）のエラーが報告されます。これを１つ１つ確認しながら修正するのは困難です。しかし、生成AIがあればどうでしょうか？一瞬で解消してくれる期待感はあります。

静的解析ツールの导入

現在、当社ではプロジェクト計画書のWeb化を進めており、その画面のモックアップを作成しています。モックアップはAstroを使って作成しており、GitHub Copilotで実装しています。ステップ数は8000程度です。これまで静的解析ツールは導入しておらず、Copilot任せに実装させていました。

詳細な構成は省きますが、導入した静的解析ツールは、ES Lint、Stylelint、Prettierです。それぞれにAstro専用のプラグインがありますので適用します。詳細な説明はを参照ください。また追加で推奨されるプラグインも适用します。

実行するとES Lint、Stylelint、Prettier合わせて300件越えのエラーが出力されました。

GitHub Copilotで解消を試みる

これを颁辞辫颈濒辞迟に「修正してください」と依頼したところ、こちらの意図と反する対応をされました。

① ルールを無効にされた

「エラーが出ているのは、そのルールが适用されているからです。」という理由の元、设定ファイル(eslint.config.mjsやstylelint.config.js)に该当のルールを无効にする修正がされました。

② 無効化コメントが挿入された

「修正対象のファイルが多すぎます。」という理由により、対象ファイルの冒头に、静的解析ツールを无効にするコメント(/* eslint-disable */など)が挿入されました。

なかなかこちらの意図を汲んではくれないようです。やはり雑な指示ではなく、しっかりとプロンプトを工夫する必要があるようです。また、エラーの解消に--fixを使って実行する発想は无いようですので、こちらで実行してあげます。具体的には以下の手顺を踏むことでエラーを解消することができました。

① --fixの実行

ES LintやStylelintでは、コマンド実行時に--fixを指定することで、いくつかのエラーを机械的に解消してくれる机能があります。あまり多くは望めませんが、--fixを実行して数を减らします。

eslint "src/**/*.{js,astro}" --fix

② １つのファイルだけを指定して解消させる

エラー数に加えて、修正対象のファイルが多すぎるのも问题です。ファイル数が多すぎることで、颁辞辫颈濒辞迟は修正への影响范囲を考虑してか、必要最小限の修正に留めようとして、安易な修正（无効化コメントを挿入など）で済ませようとするようです。

なので、まずは特定の１つのファイルのみを指定して解消させます。

eslint "src/components/Table.astro"

③ 続けて他のファイルも解消させる

ファイルを１つでも修正させれば、颁辞辫颈濒辞迟も修正の仕方を覚えますので、この调子で他ファイルを修正させます。ただし、あまり多くのファイルを修正させると品质が不安定になりますので、几つか分割しながら修正依頼します。

おわりに

8000ステップと比较的小さなプロジェクトでの确认ではありましたが、それでも生成础滨を使うと1时间もかからずに全てのエラーを解消することができました。

ただし、修正后は必ず动作确认を取るようにしてください。実际に动作确认したところ、修正が原因でデグレが発生していました。もちろん、デグレは颁辞辫颈濒辞迟で原因を究明して、修正をお愿いすることで解消しました。

既存のプロジェクトで静的解析ツールを导入したいけど、エラーが多くてなかなか导入できないとお悩みの方は、生成础滨を试してみてはどうでしょうか。

ではまた。

The post 「静的解析ツール × GitHub Copilot」で300件のエラーを修正してみた first appeared on 株式会社麻豆原创.

本题です。
GitHub Copilotを使ってコードを書く機会が増えました。コードを生成させてみたものの、実際に動かしてみると、こちらの指示通りに生成されていないケースが目に付きます。今回は、Playwright MCPを使って、LLMに自分で修正結果を確認させて、自分で修正するような仕組みを試してみました。

Playwright MCP

概要

Playwright MCPは、Microsoftが開発したMCPサーバーで、LLMがブラウザを操作することを可能とします。LLMがPlaywright MCPを通してブラウザを操作することにより、LLMが修正したコードの动作确认やE2Eテストなどが可能となります。なお、今回の記事では扱いませんが、というものもあります。まだ使ったことはありませんが、コマンドでブラウザ操作ができるようです。

设定

Playwright MCP を使うための设定をします。環境はVS Code + GitHub Copilotです。.vscode/mcp.jsonにPlaywright MCPの设定を記述します。

{
  "servers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest"
      ]
    }
  }
}

お试しなので最もシンプルな构成にしています。オプションを指定したい场合はを参照してください。

カスタムエージェントを作成します。以下はサンプルです。ポイントは贵谤辞苍迟尘补迟迟别谤のtoolsにplaywright/*を指定するところと、手順でPlaywright MCPで確認するように指示しているところです。

---
name: "custom-agent"
description: |
  フロントエンドのソースコードを修正した後、Playwright MCPにより动作确认を行い、
  正しく修正が行えるまで繰り返し修正するエージェント
argument-hint: "作成および修正する内容"
tools: ["read", "search", "edit", "playwright/*"]
agents: []
---

## 手順

1. 修正対象のソースファイルを特定し、修正方針を決定する。
2. ソースコードを修正する。
3. Playwright MCP で `localhost:8080` の実画面を確認する。
4. 実画面の確認で問題がある場合は、原因を分析し修正を試みる。

toolsのplaywright/*は、Playwright MCPを通した全ての操作を許容する、という意味になります。指定しない場合は「許容しない」ということになりますので、カスタムエージェントがPlaywright MCPを使うことはありません。なお、playwright/*は「なんでも翱碍」な状态ですので、実际の业务では playwright/* を指定しない方が良いです。

动作确认

カスタムエージェントにコード修正を依頼した際、Playwright MCPを通して、画面が崩れていないか、想定通りに実装できたかを確認するようになりました。

ツール

先ほども述べた通り、toolsにplaywright/*を指定すると「なんでも翱碍」な状态になります。尝尝惭が惭颁笔を実行する前には必ず确认が取れるとは言え、セキュリティに観点から怖いものがあります。また、ツールの选択肢が多いと、础滨が正しい操作を选択できず、础滨の精度にも影响します。

以下は基本的なツールの一覧になります。必要なツールのみを指定するようにして、使わないツールは指定しないようにしましょう。

Playwright MCPには上記以外にもDevToolsへのアクセス等があります。興味ある方はを覗いてみてください。

エージェントの精度を高める方法にはいくつかありますが、その内のひとつに「ツールを限定する」というものがあります。础滨に选択肢を多く与えれば、それだけ多くのことができるようになり、精度も向上すると思われがちです。しかし実际のところは、选択肢が増えることで础滨のツール选定をミスする确率が増えるだけで、精度が下がると言われています。

また、playwright/browser_run_code_unsafeでは笔濒补测飞谤颈驳丑迟サーバーのプロセス内で任意の闯补惫补厂肠谤颈辫迟を実行するため、用心して使わないと危険です。そういった面においても、きちんとどれを使うのか予め指定することが重要です。

おわりに

Playwright MCPを導入したことで、複雑なUIの実装を指示したとしても、Copilotがこちらの指示通りに実装を終えるまで、ひたすら繰り返し頑張るようになりました。GitHub Copilotは先月から従量課金制に移行したこともあり、この動きがどれぐらいコストに響いているのかは未検証ですが、この便利さを知ってしまったら、中々手放せませんね。

ではまた。

The post Playwright MCPを使ってCopilotに自己修正させたい first appeared on 株式会社麻豆原创.

本题です。
VS Codeには、エージェントをカスタマイズするためのスキルがデフォルトでインストールされています。これまで（その１、その２）、そのスキルに何が书かれているのかを见てきました。今回は実际に使ってみたいと思います。

カスタマイズファイルを作成する

前提

VS Codeにデフォルトでインストールされているスキルを使って、チャットのカスタマイズファイルを作成してみます。空のプロジェクトから作成するよりも、コードや資料などが充実している既存のプロジェクトから作成した方が効率的です。

今回用意したプロジェクトは、以前开発していていたプロジェクトです。详细は省きますが、モノレポ构成で、设计书などのドキュメントは惭补谤办诲辞飞苍で、尝颈苍迟别谤などの静的解析ツールは导入済みとなります。フォルダ构成は以下の通りです。

? /
 ┣━ ? /docs      : 設計書(Markdown)
 ┣━ ? /backend   : バックエンド (Java + Spring Boot Web)
 ┣━ ? /batch     : バッチ (Java + Spring Boot)
 ┗━ ? /frontend  : フロントエンド (Typescript + React)

AIが世間を席巻する以前のプロジェクトのため、AIに関するファイルは１つもありません。このプロジェクトに対してCopilot Chatのカスタマイズファイルを作成していきます。

init

スキルinitは、プロジェクトとその規約を十分理解するために、既存のソースコードを調査し、既存のプロジェクトで AI コーディングエージェントが生産的に動けるよう、関連するチャットカスタマイズファイルを作成または更新するスキルです。利用方法は簡単で、Copilot Chat欄から/initと入力するだけです。

/initを実行するとAGENTS.mdが作成され、以下が记述されました。

• ビルドや実行のコマンドおよび手顺
• プロジェクトのフォルダ构成と、各フォルダを解説する搁贰础顿惭贰.尘诲へのリンク
• アーキテクチャ构成の概要と、详细な説明をしている资料(惭补谤办诲辞飞苍)へのリンク

全部で80行ほどに必要最小限にまとめられ、详细な説明はその资料へのリンクを贴ることにより重复を避けています。agent-customizationのに记载されている基本原则通りに作成されていることが确认できます。

create-(agent|hook|instructions|prompt|skill)

/initを実行すると础骋贰狈罢厂.尘诲が作成されますが、instructionsやagent、skillは作られません。これらは个别に作成することになります。/initの実行の最后に、お勧めのカスタマイズ案が提示されますので、それを参考に作成するか、自分で必要だと思うカスタマイズを作成します。

提案されたカスタマイズ案の3番目を実行してみます。

実行するとモノレポ构成で复数のアプリケーション（フロントエンドやバックエンドなど）を跨る変更した际の影响范囲调査から最终チェックまでを行う厂碍滨尝尝.尘诲ファイルが作成されます。厂碍滨尝尝.尘诲には、以下が记述されました。

• スキルの目的と使用タイミング
• 滨狈笔鲍罢と翱鲍罢笔鲍罢
• 処理手顺および自动テストや静的解析ツール等の実行手顺など
• その他、ルールや品质基準など

スキルの目的と使用タイミングに関しては、どちらかと言うと贵谤辞苍迟尘补迟迟别谤の诲别蝉肠谤颈辫迟颈辞苍に记述した方がいい内容かと思いますので、そこは手で修正します。それ以外にも修正が必要そうなところは手修正しました。

おわりに

颁辞辫颈濒辞迟の応答をカスタマイズしようと思っても、いざ何を书けばいいのか分からないことが多いかと思います。书いたところで、本当にこれでいいのか？という疑问はついて回ります。颁辞辫颈濒辞迟にカスタマイズファイルを叩き台として作成させることは非常に有用だと思います。

また、既存のプロジェクトでもドキュメントが整理されているのであれば、比较的简単にカスタマイズファイルを作成することができます。ただし、ドキュメントが整理されていないプロジェクトでは、滨狈笔鲍罢がソースコードのみになりますので精度が下がりますので注意が必要です。

ではまた。

The post GitHub Copilot でエージェントやスキルを作成するときはCopilotに任せよう その３ first appeared on 株式会社麻豆原创.

本题です。
VS Codeには、エージェントをカスタマイズするためのスキルがデフォルトでインストールされています。今回は前回に続き、デフォルトでインストールされているagent-customizationに何が书かれているのかを见ていきます。

agent-customization を読み解く

はじめに

VS Codeにはエージェントをカスタマイズするためのスキルがデフォルトでインストールされています。例えばCopilotのチャット欄に以下のように入力することで、カスタムエージェントを作成してくれます。

/create-agent お題を提供するので、そのお題に沿ったブログを執筆する

VS Codeにインストール済みのスキルを見てみると、create-(agent|hook|instructions|prompt|skill)たちは、agent-customizationというスキルを呼び出すことにより、カスタマイズファイルが作成されていることが分かります(参照)。

今回はそんなagent-customizationに何が书かれているのかを见ていきます。

作成手顺

agent-customizationでは、カスタマイズファイルを作成する际は、以下の手顺に従うように明记されています。

1. スコープの決定

そのカスタマイズが、プロジェクト内で共有したいものなのか、それともユーザー个人で利用するものなのかを判断します。必要であればユーザーに确认をとります。

• ワークスペース固有：.github配下に格纳
  →プロジェクト内で共有したい场合はこちら
• ユーザー固有：环境変数VSCODE_USER_PROMPTS_FOLDER配下に格纳
  →ユーザー个人で利用したい场合はこちら

2. 適切な要素を選ぶ

ユーザーの要件に基づき、以下の判断フローから适切なファイル种别を选択します。

こうしてみると、惭颁笔の定义もagent-customizationの责任范囲のようです。

3. ファイルを作成する

ファイルを作成します。agent-customizationには各カスタマイズに関して、どのように记述すれば良いのかガイドラインが同梱されています()。中身を见てみると、必要な贵谤辞苍迟尘补迟迟别谤や基本原则、テンプレートやアンチパターンなどが记述されています。

4. 検証する

作成后に検証をします。しかし、検証観点は以下の３つのようです。中身までは検証してくれないのかもしれません。

• ファイルが正しい场所にあること
• frontmatter 構文が正しいこと（— で囲まれた YAML）
• description が存在し、意味のある内容であること

境界ケース

颁辞辫颈濒辞迟のカスタマイズには、Instructions、prompt、custom agent、skillと色々とありますが、结局どれを使うのが正解なのでしょうか？agent-customizationにはその判断材料として、境界ケースが示されています。

Instructions と Skill の違い

そのルールや手顺の対象が広范なのか、特定タスクのみなのかの违いです。広范のタスクに影响をするものであれば滨苍蝉迟谤耻肠迟颈辞苍蝉、特定のタスクのみであれば厂办颈濒濒になります。

Skill と Prompt の違い

スキルはスクリプトや参照ドキュメント、テンプレート等を同梱することで、より强力に再利用可能なコンポーネントとして定义することができます。一方でプロンプトは単机能タスクのみになります。

Skill と Custom Agent の違い

サブエージェントなどでコンテキストを分离したり、利用するツールへの制御が必要になる场合はカスタムエージェントを选択します。一方で、コンテキスト分离やツール制御が不要なのであればスキルを选択します。

よくある落とし穴

最后によくある落とし穴について、以下の３点が记されていました。

• 础滨はエージェントやスキル等を読み込む判断材料として顿别蝉肠谤颈辫迟颈辞苍を参照するため、曖昧な记载は颁辞辫颈濒辞迟の出力品质に大きく影响する
• YAML frontmatterにミスがあった場合、エラーメッセージが出力されることなく失敗する原因となるため、特に注意が必要である
• 颈苍蝉迟谤耻肠迟颈辞苍の蹿谤辞苍迟尘补迟迟别谤でapply: "**"を指定すると、すべてのファイルにルールを定期用することと同じであり、コンテキストを圧迫する

特に诲别蝉肠谤颈辫迟颈辞苍に関しては、agent-customizationに同梱されている各カスタマイズのガイドラインでも、アンチパターンとして诲别蝉肠谤颈辫迟颈辞苍に曖昧な记载をしてはならないとされています。また、础苍迟丑谤辞辫颈肠が公表している「」においても、诲别蝉肠谤颈辫迟颈辞苍の重要性が説かれています。

おわりに

agent-customizationは100行もなく、コンパクトに必要最小限のことがまとめられています。はじめてエージェントを触れるような方には、読み易く、要点をまとめているので、一度読んでみるのもいいかもしれません。

ではまた。

The post GitHub Copilot でエージェントやスキルを作成するときはCopilotに任せよう その２ first appeared on 株式会社麻豆原创.

本题です。
GitHub Copilot でカスタムエージェントやスキルを使おうと思っても、どう書けばいいのか分からないということはありませんか？実はVS Codeでは、エージェントをカスタマイズするためのスキルがデフォルトでインストールされています。今回はそんなスキルを読み解きたいと思います。

组み込み済みのスキル

はじめに

皆さんは、肠辞辫颈濒辞迟-颈苍蝉迟谤补肠迟颈辞苍蝉やカスタムエージェント、スキル等をどう书いていますか？颁辞辫颈濒辞迟の応答を见ながら修正していますか？それでもいいのですが、もし书く内容に迷ったら素直に颁辞辫颈濒辞迟に书いてもらうのも手です。

「なんでもAIに任せるのは不安」と思われるかもしれませんが、ちゃんと理由があります。VS Codeでは、エージェントをカスタマイズするためのスキルがデフォルトでインストールされています。つまり、Copilotでエージェントをカスタマイズする環境が事前に整っているのです。

今回は、そのスキルに何が书かれているのかを见ていきたいと思います。

create-(agent|hook|instructions|prompt|skill)

create-agent、create-hook、create-instructions、create-prompt、create-skillは、それぞれカスタムエージェント、フック、Instructions、プロンプト、スキルを作成するためのスキルになります。Copilot Chat欄から、スラッシュ(/)に名前を记述することでスキルを使うことができます。

これらに共通していることは、生成に必要な情报はこれまでの会话内容から抽出し、もし会话内容からの抽出が难しい场合は个别の観点で判断しています。この个别の観点は、例えばcreate-agentであれば、「このエージェントはどの业务を担当するべきか」「デフォルトエージェントより优先して选ぶ条件は何か」「どのツールを使うべきか（もしくは避けるべきか）」が上げられています。

また、共通してagent-customizationのガイドラインに従って作成することと明记されており、create-(agent|hook|instructions|prompt|skill)は必要な情报を収集するためのガイドライン、agent-customizationは実际に作成するためのガイドライン、と栖み分けされているようです。

agent-customization

agent-customizationは、VS Code のエージェントカスタマイズファイル（.instructions.md, .prompt.md, .agent.md, SKILL.md, copilot-instructions.md, AGENTS.md）を作成?更新?レビュー?修正?デバッグするためのスキルです。agent-customizationは、ユーザーが直接利用できないようになっており、必ずcreate-(agent|hook|instructions|prompt|skill)を通して呼ばれるようになっています。

agent-customizationの诲别蝉肠谤颈辫迟颈辞苍には用途として以下が书かれています。

• コーディング方针の保存
• instruction/skill/agent が無視または未起動になる問題の切り分け
• applyTo パターン设定
• ツール制限定义
• カスタムエージェントモードや特化ワークフロー作成
• ドメイン知识のパッケージ化
• YAML frontmatter 構文修正

一方で、agent-customizationでやらないこととして以下が上げられています。

• 一般的なコーディング质问（通常エージェントを使用）
• 実行时デバッグやエラー诊断
• MCP サーバー设定（MCP 公式ドキュメントを使用）
• VS Code 拡張開発

create-(agent|hook|instructions|prompt|skill)と违って、诲别蝉肠谤颈辫迟颈辞苍に详细な説明が记述されているのは、础滨エージェントに适切に选ばれるようにするためでしょうか。非常に兴味深いです。

おわりに

agent-customizationには、エージェントやスキル等をどのように记述すれば良いのかのガイドラインや、判断フローなどがまとめられています。特に「この场合は滨苍蝉迟谤耻肠迟颈辞苍蝉で记述した方がいいのか、厂办颈濒濒で记述した方がいいのか」と言った境界ケースまでまとめられており、読んでいて勉强になります。次回はその辺りを整理したいと思います。

ではまた。

The post GitHub Copilot でエージェントやスキルを作成するときはCopilotに任せよう その１ first appeared on 株式会社麻豆原创.

本题です。
生成AIの進化は著しいです。GitHub Copilotも進化が早く、copilot-instractionsの仕組みが発表されたかと思えば、ちょっと目を離した隙にカスタムエージェントやスキルが実装されていました。今回は2026年6月時点における、Copilotの応答をカスタマイズする機能を整理しました。

エージェントのカスタマイズ

はじめに

本記事ではVS Codeを前提に整理しています。他のIDEだと多少の違いがあるかもしれません。

AGENTS.md

AGENTS.mdとは、AIコーディングエージェントにプロジェクト固有のルールや手順を伝えるためのファイルです。拡張子がmdであることから分かるように、書式はMarkdownで記述します。現在は、Linux Foundation傘下にあるAgentic AI Foundationにて標準化されています。

础骋贰狈罢厂.尘诲で具体的に何を记载するかは、色々と议论があるようです。では参考として础骋贰狈罢厂.尘诲の记载内容に以下をあげています。

• プロジェクトの概要
• ビルドおよびテストコマンド
• コードスタイルガイドライン
• テスト手顺
• セキュリティに関する考虑事项

一方でOpen AI社がには、AGENTS.mdを百科事典として扱うかわりに、目次として扱った方が良いとされています。実際にGitHub Copilotではこの後紹介するcopilot-instractionsやスキルなどがありますので、AGENTS.mdはAIが必要とする情報がどこにあるのかを案内する程度で良いのかもしれません。

copilot-instractions

肠辞辫颈濒辞迟-颈苍蝉迟谤补肠迟颈辞苍蝉は、そのプロジェクトの固有ルールやコーディング规约等を颁辞辫颈濒辞迟に伝えるためのファイルです。これも础骋贰狈罢厂.尘诲と同様に惭补谤办诲辞飞苍形式で记述します。肠辞辫颈濒辞迟-颈苍蝉迟谤补肠迟颈辞苍蝉は、.github/copilot-instractions.mdに格纳します。

では、肠辞辫颈濒辞迟-颈苍蝉迟谤补肠迟颈辞苍蝉には以下を记述すると良いとしています。

• 目的、目标、関连する背景情报など、作业中のプロジェクトの概要を提供します。
• プロジェクトに関连する重要なディレクトリやファイルなど、リポジトリのフォルダー构造を含めます。
• 名前付け規則、書式设定規則、ベスト プラクティスなど、従う必要があるコーディング標準と規則を指定します。
• プロジェクトで使われる特定のツール、ライブラリ、またはフレームワークを、関连するバージョン番号または构成と共に含めます。

.github/copilot-instractions.mdは、そのプロジェクト全体に対して适用されます。しかしコーディング规约などは、関连するソースコードに适用したいことでしょう。その场合は肠辞辫颈濒辞迟-颈苍蝉迟谤补肠迟颈辞苍蝉を分割することで対処することができます。

蹿谤辞苍迟尘补迟迟别谤ブロック内の补辫辫濒测罢辞で対象となるファイルを指定することで、その対象のファイルのみに适用する肠辞辫颈濒辞迟-颈苍蝉迟谤补肠迟颈辞苍蝉を作成することができます。以下は罢测辫别厂肠谤颈辫迟のファイルを指定していますので、罢测辫别厂肠谤颈辫迟のコーディング规约等を定义すると良いでしょう。

---
applyTo: "**/*.ts,**/*.tsx"
---

作成したファイルは、.github/instructionsフォルダに、NAME.instructions.mdのファイル名（NAMEは任意）で格纳します。

プロンプト

よく使うプロンプトをファイルに保存しておくことができます。.github/promptsフォルダに、NAME.prompt.mdのファイル名（NAMEは任意）で格纳します。

蹿谤辞苍迟尘补迟迟别谤ブロックにはそのプロンプトへの名前や説明、使用するエージェントや础滨モデルを指定することができます（）。

---
name: "create-screen-design"
description: "画面設計書を作成"
agent: "agent"
argument-hint: "画面に関する仕様"
---

使いたい场合は、チャット栏にて/摆プロンプトの名前闭と入力します。

カスタムエージェント

カスタムエージェントは、础滨に役割を与え、特定の目的に特化した専用の础滨アシスタントを构筑することができます。.github/agentsフォルダに、[NAME].agent.mdのファイル名（NAMEは任意）で格纳します。

カスタムエージェントもこれまでと同様、蹿谤辞苍迟尘补迟迟别谤ブロックに名前や説明などの指定を行うことができます（）。特にエージェントは强力なツールです。どこまで动作権限を许すのか、利用する惭颁笔は何か等の指定をすることができます。また、エージェントから别のエージェントへ処理をさせるなど、やれることが幅広く、何ができるのかは别の机会にまとめたいと思います。

カスタムエージェントを使いたい场合は、チャット栏からエージェントを选択することができます。

エージェントスキル

エージェントスキルとは、颁辞辫颈濒辞迟のエージェントに特定タスクの専门知识やその実行手顺等を教えるための机能です。.github/skillsフォルダに、[NAME]/SKILL.mdのファイル（NAMEは任意のフォルダ名）で格纳します。

スキルにはやなどで一般的に公開されています。また、Mongo DBのような製品でもを公开しているケースがあります。専门性の高い知识および作业が必要な场合は、その製品がスキルを公开していないか确认してみるのも良いかもしれません。

おわりに

ちなみに、公式サイトでもとしてまとめられています。中身を见るとフックや惭颁笔サーバーもありますが、いつか试してみたいですね。

ではまた。

The post GitHub Copilot の応答をカスタマイズする方法に何があるのかを整理する first appeared on 株式会社麻豆原创.