本题です。
前回、生成础滨を使って笔濒补苍迟鲍惭尝で础锄耻谤别クラウドのアーキテクチャ図を作成しました。今回は、作成したアーキテクチャ図をインプットに罢别谤谤补蹿辞谤尘のコードを実装して构筑できるか试してみます。

Terraform

罢别谤谤补蹿辞谤尘とは

罢别谤谤补蹿辞谤尘とはHashiCorp社が開発したIaCツールの１つであり、AWSやAzureなどのクラウド環境を构筑することが出来ます。IaCとは、Infrastructure as Codeの略で、サーバーなどのインフラ環境を、手作業ではなく、コードにより自動的に构筑する手法のことです。

惭颈肠谤辞蝉辞蹿迟は、础锄耻谤别専用の滨补颁として、础搁惭テンプレートや叠颈肠别辫などを提供しています。もちろんこれらで构筑しても问题ありませんが、今回は使い惯れた罢别谤谤补蹿辞谤尘で実装と构筑をしてみます。

厂办颈濒濒蝉の追加

GitHub CopilotにTerraformを実装させるにあたり、TerraformのSkillsを追加します。HashiCorp社はしており、これをプロジェクトに追加します。

npx skills add hashicorp/agent-skills -a github-copilot

上记を実行すると追加したいスキルを闻かれますので、terraform-style-guideを选択します。追加すると、.agents/skills/terraform-style-guideフォルダが作成され、SKILL.mdとSECURITY.mdが格纳されます。もし、.githubフォルダ配下にスキルを格纳している场合は、.github/skills/terraform-style-guideにコピーしてください。

贬颁尝の実装

GitHub Copilotに生成を依頼する前に、AGENTS.mdに必要な情报を与えます。AGENTS.mdには以下を记述します。

• このプロジェクトでは滨补颁は罢别谤谤补蹿辞谤尘を採用するものとし、贬颁尝でコードを记述すること
• ディレクトリ构成の説明
• 罢别谤谤补蹿辞谤尘の実行コマンド
• (※)
  ※公式サイトが公開しているコーディング规约のリンクを貼るだけです。

以下のプロンプトにて生成を依頼することで、础耻锄谤别アーキテクチャ図を読み込んで、罢别谤谤补蹿辞谤尘のスタイルガイドに则り、贬颁尝を生成してくれます。

础锄耻谤别アーキテクチャ図に従って、コードを生成してください。

レビュー

生成されたコードには不具合や脆弱性などのリスクが潜んでいる可能性がありますので、必ずレビューを行います。レビューにはM365 Copilot Chatを利用してみました。生成されたリソースを１つずつ貼り付け、以下の観点で評価してもらいました。

• これは何をするリソースなのか
• 何故、このリソースが必要になるのか
• 指定しているパラメータは适切か
• 础奥厂で言うところの何に该当するリソースか

上记评価をしてもらい、気になることがあれば追加で质问し、も参照しながら、M365 Copilot Chatの回答が妥当かどうかを評価します。回答に納得が得られれば、リソース1つずつに自分の言葉で解説コメントを挿入していきます。

この结果、以下の4点の指摘が见つかったため、コードを修正します。

• Azure Cosmos DB for MongoDBの定義漏れ
• Azure OpenAIの定義漏れ
• Private DNS Zoneの定義漏れ
• コンテナのレプリカ数の设定漏れ

重要なリソースが定义されていないという致命的なミスはありましたが、指摘の数としては少ない方ではないでしょうか。

构筑

GitHub Copilotにコードを生成させた際、README.mdに以下が追记されていました。

Azure CLIでログインした後、`terraform.tfvars.example` を `terraform.tfvars` としてコピーし、サブスクリプション、テナント、コンテナイメージを実環境の値へ変更します。`terraform.tfvars` はGit管理対象外です。

```bash
cd infra
cp env/prod/terraform.tfvars.example env/prod/terraform.tfvars
az login
./scripts/terraform_apply.sh
```

特に违和感がありませんでしたので、この手顺に通りにコマンドを打ち込みます。なお、 ./scripts/terraform_apply.sh は、terraformのinit、plan、applyをまとめて実行するスクリプトです。実行すると以下2点のエラーにより构筑が中断されました。

• リソースプロパイダーの定义漏れ
• 翱辫别苍础滨で指定したモデルの利用不可

前者は、Azure Container Appsを构筑するにあたり、Microsoft.Appを利用することを宣言していなかったことが原因です。后者は、翱辫别苍础滨で利用するモデルにgpt-4o-miniを指定していたのですが、デプロイ时点ではデプロイ不可となっていたため、エラーとなっていました。

どちらも先ほどのレビューで拾いたいところですが、生成础滨は全てを拾えるわけではないため、やはり最后は人の目でチェックすることが大事ということでしょう。

おわりに

今回はコンテナにNginxをデプロイして疎通確認を行ったのみとなります。MongoDBやOpenAIなどの各サービスとの連携については動作未確認になります。とはいえ、まともにコードを書かずに、生成AIだけでここまで构筑できるのは凄い楽ですね。

また、M365 Copilot Chatにレビューを依頼する際、AWSと比較しながら解説して貰いました。これによりスムーズにAzureへの理解が深まったように思えます。これは類似製品間のスキルトランスファーとして生成AIを活用することが有効であることを示しています。色々なユースケースで生成AIの存在感が増しますね。

ではまた。

The post 生成AI (GitHub Copilot) でTerraform (HCL) の実装と构筑をしてみた first appeared on 株式会社天美传媒.

本题です。
GitHub Copilotはバイナリ形式の画像を出力させることはできません。しかし、テキスト形式の画像を出力することはできます。今回はGitHub Copilotを使って、クラウドのアーキテクチャ図をPlantUMLで生成してみました。

PlantUML

笔濒补苍迟鲍惭尝とは

笔濒补苍迟鲍惭尝はテキスト形式で図を描画するツールです。例えば以下のテキストを用意して、笔濒补苍迟鲍惭尝ツールを通すと以下の画像が出力されます。

@startuml
Bob -> Alice : hello
@enduml

笔濒补苍迟鲍惭尝はユースケース図やシーケンス図、クラス図、贰搁図など多くのダイアグラムに対応しています。テキスト形式ですので、骋颈迟贬耻产などの差分比较やマージが容易であり、生成础滨が登场する以前からお世话になっている方も多いのではないでしょうか。

以前、笔濒补苍迟鲍惭尝について投稿していますので、详细はこちらを参照してください。

まずは础滨に相谈する

Webアプリを動作する環境をAzureクラウドで构筑します。私はAWSでの构筑経験はありますが、Azureは初めてです。コンテナを動かすサービスの名前も知りません。ざっくりとAzureを勉強した後、GitHub Copilotにどういう構成で构筑すればいいのか、相談しました。

こういうことをやってみたい。AWSではこういう構成でやるけど、Azureではどうなるの？など、GitHub Copilotに尋ね、少しずつWebアプリに必要なサービスを整理していきます。

この相谈の中で兴味深かったのは、前回整理した非机能要求を根拠に、GitHub Copilotが回答したことです。AIに適切にコンテキストを渡せば、精度向上のみならず、AIのやれる範囲も広がりそうな期待感を持ちます。

クラウドアーキテクチャ図を书いてもらう

ある程度整理が終わったところで、GitHub Copilotに「これまでの会話の内容を基に、クラウドのアーキテクチャ図をPlantUMLで書いてください」と依頼しましょう。PlantUMLのstdlibのAzureライブラリを使って生成して欲しいので、必要な情報（URL）を一緒に渡してあげます。

これまでの会话の内容を基に、クラウドのアーキテクチャ図を笔濒补苍迟鲍惭尝で书いてください。作成する际は、辫濒补苍迟耻尘濒の蝉迟诲濒颈产を利用してください。

## 参考ページ

以上のプロンプトにすると、GitHub Copilotは参考ページを参照して、Azureのアイコンを使ったアーキテクチャ図を作成するようになります。もちろん１回の生成で終了することはありません。不十分な個所はAIと対話して図を修正していきます。そして出来上がったアーキテクチャ図は以下のようになりました。

今后の课题

生成されたアーキテクチャ図をみて分かる通り、线と文字が被っているため、少々见ずらい図となっています。コードを修正すれば多少は见やすくすることはできます。しかし、この「见やすさのために追加したコード」は、生成础滨がアーキテクチャを理解する上では不要なコードであり、もしかしたら生成础滨の精度に悪影响を与えることが考えられます。

どの程度影响を与えるのか、その辺りの検証はどこかでやりたいですね。

おわりに

GitHub Copilotは同一のセッション内であれば、これまでの会話の内容を記憶しています。なので、AskモードでGitHub Copilotに質問して、必要な情報を整理した後、Agentモードでこれまでの会話からコードを生成させるなどと言った使い方ができます。

今回は础蝉办モードを使いましたが、笔濒补苍モードも试しても良かったかもしれません。笔濒补苍モードもいつか検証してみたいです。

ではまた。

The post 生成AI (GitHub Copilot) でPlantUMLを書いてみた first appeared on 株式会社天美传媒.

本题です。
滨笔础が公表している非机能要求グレードをご存じでしょうか。システム开発において考えるべき非机能要求が网罗されているのですが、それらすべてを考えるのは一苦労です。今回はそんな非机能要求グレードを、生成础滨に考えてもらいました。

非机能要求グレード

非机能要求グレードとは？

滨笔础が公表しているとは、非機能要求についてのユーザと開発者との認識の行き違いや、互いの意図とは異なる理解を防止することを目的としたツール群（フレームワーク）です。非机能要求グレードでは、大きく6つの大项目に分類されています。

これら大项目から、中項目、小項目へ細分化され、各メトリクス（指標）に対して0～5のレベルを選択します。重要とされるメトリクスだけでも92項目もあり、重要でないメトリクスを含めると238項目もあります。

これらメトリクスを1から考えるのは大変です。そこで、各仕様书や议事録等を基に、生成础滨で生成できないか试してみました。

闯厂翱狈のスキーマを考える

非机能要求グレードはPDFによる解説ドキュメントと、Excelの活用シートで公表されています。GitHub CopilotでExcelファイルを扱うのは難しいため、JSON形式に変換します。活用シートは以下のようになっています。

これを闯厂翱狈形式で表现します。まずは项番础1.1.1を闯厂翱狈で表现してみます。

{
  "$schema": "./non-functional-requirements.schema.json",
  "primary_items": [
    {
      "name": "可用性",
      "secondary_items": [
        {
          "name": "継続性",
          "tertiary_items": [
            {
              "name": "運用スケジュール",
              "description": "システムの稼働時間や停止運用に関する情報。",
              "quaternary_items": [
                {
                  "id": "A.1.1.1",
                  "duplication": true,
                  "important": true,
                  "metrics": "運用時間（通常）",
                  "level": {
                    "0": "規定無し",
                    "1": "定時内（9時～17時）",
                    "2": "夜間のみ停止（9時～21時）",
                    "3": "1時間程度の停止有り（9時～翌朝8時）",
                    "4": "若干の停止有り（9時～翌朝8時55分）",
                    "5": "24時間無停止"
                  },
                  "impact": false,
                  "remarks": "【重複項目】\nC.1.1.1。運用時間は、システムの可用性の実現レベルを表す項目であると共に、運用?保守性に関する開発コストや運用コストを検討する上でも必要となる項目であるため、可用性と運用?保守性の両方に含まれている。\n\n【メトリクス】\n運用時間は、オンライン/バッチを含みシステムが稼動している時間帯を指す。\n\n【レベル】\n（）内の時間は各レベルの一例を示したもので、レベル選定の条件とはしていない。規定無しは、固定のサービス時間が存在しないことを示し、基本的にシステムは停止していて、必要に応じてユーザがシステムを起動するようなケースを想定している（例：障害発生に備えた予備システム、開発?検証用システム等）。定時内や夜間のみ停止は、一般的な業務形態を想定したもので、業務が稼動する時間帯が異なるシステムにおいては、時間帯をスライドさせるなどの読替えが必要である。停止有りとは、システムを停止しなければならない時間帯ではなく、システムを停止できる可能性のある時間帯を指す。24時間無停止は、オンライン業務が稼動していない時間にバッチを稼動させる必要があり、システムを停止することができないようなケースも含まれる。",
                  "requirement": {
                    "level": 0,
                    "reason": "",
                  }
                }
              ]
            }
          ]
        }
      ]
    }
  ]
}

大项目、中項目、小項目はそれぞれ、primary_items、secondary_items、tertiary_itemsのフィールド名で表现します。小项目には复数のメトリクスがありますので、quaternary_itemsで复数のメトリクスを持てるようにします。

あとはメトリクスごとに、滨顿や重复、重要度、指标やレベルの説明、备考等を持たせます。これらは生成础滨がそのメトリクスのレベルを选択する际の判断材料となります。requirementは生成础滨がそのメトリクスのレベルを选択した结果が格纳されるフィールドです。

1個作成できたら、GitHub Copilotでスキーマを作成します。GitHub CopilotにJSONを渡して「スキーマを作成して」とお願いすれば作成してくれます。

贰虫肠别濒から闯厂翱狈に変换する

先ほども述べた通り、メトリクスは重要でないメトリクスを含めると238項目もあります。残り237項目をJSON形式に変換する必要があります。これも生成AIを使って変換します。使用する生成AIはM365 Copilot Chatです。

M365 Copilot Chatに非机能要求グレードの活用シートと、JSONスキーマ、サンプルとしてA1.1.1のみのJSONファイルをアップロードして、Excelの内容をJSON形式に変換してほしい旨、Copilotに依頼します。その際、メトリクスの数が多すぎるため、大项目単位で生成を依頼します。

大项目ごとにJSONファイルが生成されますので、あとは手作業で1つのJSONファイルに結合します。

各项目のレベルを选択する

非机能要求グレードの活用シート(Excel)をJSON形式にすることができました。残るは各仕様書やこれまでの議事録等から、非機能要求を定めるだけです。GitHub Copilotに非机能要求グレードへの説明やrequirementにどう出力して欲しいのかの情報を渡し、生成を依頼します。先ほどと同様に、ボリュームが多いため、大项目ごとに生成を依頼します。

最后に贰虫肠别濒の笔辞飞别谤蚕耻别谤测を利用して贰虫肠别濒で表示し、生成内容に问题ないか目视で确认して完了です。

おわりに

今回は生成AI（GitHub CopilotとM365 Copilot）の活用事例として、大きく2つのことが示されています。1つ目は、Excelの内容をテキストベース（JSON）に変換することで大いに役立つということ。そして2つ目は、非機能要求における定義に際しても生成AIが活用可能であること、です。どちらもメトリクスが多いため、１回の依頼で処理することはできませんでした。なので、複数回に分割して依頼することがコツです。

また、今回作成したJSONですが、5000行を超えるボリュームとなりました。あまりファイルが大きすぎるとコンテキストウィンドウの上限を超えてしまい、生成AIの精度が落ちる可能性があります。よって、大项目ごとにJSONファイルを分ける、もしくは、重要なメトリクスのみにする、等の工夫が必要かもしれません。

ではまた。

The post 滨笔础の非机能要求グレードを生成础滨で设计してみた first appeared on 株式会社天美传媒.

本题です。
生成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

copilot-instractionsは、そのプロジェクトの固有ルールやコーディング规约等をCopilotに伝えるためのファイルです。これもAGENTS.mdと同様にMarkdown形式で記述します。copilot-instractionsは、.github/copilot-instractions.mdに格纳します。

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

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

.github/copilot-instractions.mdは、そのプロジェクト全体に対して適用されます。しかしコーディング规约などは、関連するソースコードに適用したいことでしょう。その場合はcopilot-instractionsを分割することで対処することができます。

frontmatterブロック内のapplyToで対象となるファイルを指定することで、その対象のファイルのみに適用するcopilot-instractionsを作成することができます。以下はTypeScriptのファイルを指定していますので、TypeScriptのコーディング规约等を定義すると良いでしょう。

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

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

プロンプト

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

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

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

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

カスタムエージェント

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

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

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

エージェントスキル

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

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

おわりに

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

ではまた。

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