MRが楽しい

MRやVRについて学習したことを書き残す

AWESOME-COPILOTのドキュメントを読む その115(Rust Coding Conventions and Best Practices)

本日はAWESOME-COPILOTの技術調査枠です。
AWESOME-COPILOTのドキュメントを読みながら実際に操作を試して記事に残します。
今回はカスタムインストラクションの一つRust Coding Conventions and Best Practicesについてです。

Rust Coding Conventions and Best Practices

Rust Coding Conventions and Best PracticesはRustらしい(idiomatic)・安全・保守性重視の production-grade Rust を書くルールです。
Rustは「安全性・速度・並列処理を重視したシステムプログラミング言語」です。もともとはMozillaが開発し、現在はRust Foundationが中心になって発展しています。

以下のページからGenaiscriptのインストールボタンをクリックして取得します。
github.com

インストールボタンを押してRust Coding Conventions and Best Practicesをダウンロードします。
すると.github/instructions配下にインストラクションがインストールされます。

インストールしたインストラクションはCopilotの動作に自動的に適用されます。
このインストラクションを読み込むと、CopilotはRustの所有権・型安全・API設計まで考えるRustエンジニアとして振る舞います。

以下のRustファイル全般を対象に動作します。

  • **/*.rs

具体的にはCopilotは以下のような行動をとります。

Rustらしい書き方(Idiomatic Rust)を強制する

「Rustっぽくないコード」を避けるようになります。
Copilotはborrow checkerを前提に設計し始めます。

例えば以下のようにborrow を優先し、不要な allocation を避ける設計になります。

fn process(data: &str) {
    println!("{}", data);
}

以下はownershipを無駄に消費し、clone()を多用する悪い例です。

fn process(data: String) {
    println!("{}", data.clone());
}

panicではなくResultベースになる

Copilot は 「落とすコード」ではなく「回復できるコード」 を生成します。
以下のようなパターンを推奨します。

let file = File::open(path)?;
match File::open(path) {
    Ok(file) => file,
    Err(e) => return Err(e.into()),
}

更に以下も積極的に使うようになります。

  • thiserror
  • anyhow
  • meaningful error types

API設計がかなり厳格になる

CopilotはRust API Guidelinesに強く寄ります。
そのためCopilotは型安全を重視します。

例えば以下のように、bool地獄を避ける設計を好みます。

enum UpdateMode {
    Enabled,
    Disabled,
}

非同期・並列処理がRust標準寄りになる

非同期コードを書くと、Copilotはasync/awaitを基本にします。
さらに以下を前提にしやすくなります。

  • tokio
  • async-std

またCPU並列処理ならrayonを提案します。
例えば以下のようなRustらしい並列化に寄ります。

items
    .par_iter()
    .map(process)
    .collect()

テストファースト寄りになる

Copilotがテストを書こうとする率がかなり上がります。
例えば関数を書くと以下のテストを自然に生成しやすくなります。

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_parse_valid_input() {
        ...
    }
}

また以下もテスト対象にしようとします。

  • edge case
  • invalid input
  • error handling

ドキュメントを書くAIになる

Rustはdocumentation cultureが強いので、
Copilotが以下のようなrustdoc (///)を付け始めます。

/// Parses configuration file.
///
/// # Errors
/// Returns an error if the file is invalid.

特にpublic APIでは以下の要素まで説明しようとします。

  • エラー条件
  • panic 条件
  • 使用例
  • safety

プロジェクト構造まで改善する

Copilot が以下のようなmodule分割を提案するようになります。

src/
├── main.rs
├── lib.rs
├── service.rs
├── model.rs
└── error.rs

AWESOME-COPILOTのドキュメントを読む その114(Ruby on Rails)

本日はAWESOME-COPILOTの技術調査枠です。
AWESOME-COPILOTのドキュメントを読みながら実際に操作を試して記事に残します。
今回はカスタムインストラクションの一つRuby on Railsについてです。

Ruby on Rails

Ruby on RailsはRuby on Rails開発時のコーディング規約・設計方針・テスト・API・フロントエンド開発のベストプラクティス集です。
Ruby on Rails(通称 Rails)はRuby言語でWebアプリケーションを高速開発するためのフレームワークです。
Webサービス、管理画面、APIサーバー、ECサイトなどを少ないコード量で素早く作れるのが特徴です。

以下のページからGenaiscriptのインストールボタンをクリックして取得します。
github.com

インストールボタンを押してRuby on Railsをダウンロードします。
すると.github/instructions配下にインストラクションがインストールされます。

インストールしたインストラクションはCopilotの動作に自動的に適用されます。
このインストラクションを読み込むと、CopilotはRailsベストプラクティスに沿ったコード生成するようになります。

以下の関連ファイルを対象に動作します。

  • '**/*.rb'

具体的にはCopilotは以下のような行動をとります。

Rails Way を最優先する

Copilot Convention over Configurationを重視し、Rails標準を優先します。
例えばルーティングには以下を使います。

resources :users

RuboCopスタイルになる

CopilotはRuboCop準拠コードを書きます。
例えばclass/moduleはPascalCaseで命名します。

メソッドを短くする

Copilotはsmall methodを好みます。
深いifを嫌います。

Controllerを小さくする

CopilotはFat Model, Skinny Controller思想でコード作成を行います。

良い例
def create
  OrderService.new(params).call
end
悪い例
class OrdersController
  def create
    # business logic 50 lines
  end
end

Service Objectを積極生成する

Copilotは複雑なロジックをapp/servicesへ切り出します。
例えば以下のようなファイルを生成します。

app/services/payment_service.rb

App Directoryを整理する

Copilot は以下のディレクトリを構成します。

Services

app/services

Forms

app/forms

Serializers

app/serializers

Policies

app/policies

Queries

app/queries

GraphQL

app/graphql

AWESOME-COPILOTのドキュメントを読む その113(React Controls & Platform Libraries)

本日はAWESOME-COPILOTの技術調査枠です。
AWESOME-COPILOTのドキュメントを読みながら実際に操作を試して記事に残します。
今回はカスタムインストラクションの一つReact Controls & Platform Librariesについてです。

React Controls & Platform Libraries

React Controls & Platform LibrariesはGitHub Copilot を「Reactベース PCF(Power Apps Component Framework)専門エンジニア」にするルールです。

以下のページからGenaiscriptのインストールボタンをクリックして取得します。
github.com

インストールボタンを押してReact Controls & Platform Librariesをダウンロードします。
すると.github/instructions配下にインストラクションがインストールされます。

インストールしたインストラクションはCopilotの動作に自動的に適用されます。
このインストラクションを読み込むと、Copilotは以下のプロジェクトに対してPower Apps PCF + React platform libraries前提でコード生成するようになります。

  • TypeScript
  • React (TSX)
  • JavaScript
  • manifest XML
  • pcfproj
  • csproj

以下の関連ファイルを対象に動作します。

  • **/*.{ts,tsx,js,json,xml,pcfproj,csproj}

具体的にはCopilotは以下のような行動をとります。

Reactコンポーネント作成方法

通常のPCF作成時に、--framework reactを指定します。

pac pcf init -n ReactSample -ns SampleNamespace -t field -fw react -npm
パラメータ 意味
-n コンポーネント名
-ns namespace
-t field フィールド型PCF
-fw react React Control化
-npm npm install自動実行

起動方法は通常PCFと同じです。

npm start

作成後は以下で利用可能です。

  • Model-driven app
  • Custom pages
  • Canvas app

通常PCFとの違い

Manifestのcontrol-type

control-type="virtual"になります。

platform-libraryが追加される

Manifest内に以下が入ります。

<resources>
  <code path="index.ts" order="1" />
  <platform-library name="React" version="16.14.0" />
  <platform-library name="Fluent" version="9.46.2" />
</resources>

Power Apps提供React、Power Apps提供Fluent UIを使うことになります。

index.tsの実装が変わる

updateView()でReactElementを返す方式になります。
「Reactコンポーネントを返す」という設計変更です。

bundle.jsが小さい

React/Fluentが同梱されないため、bundle.jsが軽量化されます。

サンプル

以下のReact化サンプルを提供します。

サンプル 内容
ChoicesPickerReact ChoicesPickerControlのReact版
FacepileReact ReactStandardControlのReact版

Virtual Controlなので高性能です。

対応ライブラリバージョン

現在Power Appsが提供する上限バージョンは以下の通りです。

ライブラリ Runtime
React Model: 17.0.2 / Canvas: 16.14
Fluent 8 8.121.1
Fluent 9 9.68.0

注意点

Fluent 8とFluent 9は同時利用不可なのでManifestでどちらか一方のみを指定します。

AWESOME-COPILOTのドキュメントを読む その112(Ruby MCP Server Development Guidelines)

本日はAWESOME-COPILOTの技術調査枠です。
AWESOME-COPILOTのドキュメントを読みながら実際に操作を試して記事に残します。
今回はカスタムインストラクションの一つRuby MCP Server Development Guidelinesについてです。

Ruby MCP Server Development Guidelines

Ruby MCP Server Development GuidelinesはGitHub Copilot を「Ruby製 MCP Server 専門エンジニア」にするルールです。

以下のページからGenaiscriptのインストールボタンをクリックして取得します。
github.com

インストールボタンを押してRuby MCP Server Development Guidelinesをダウンロードします。
すると.github/instructions配下にインストラクションがインストールされます。

インストールしたインストラクションはCopilotの動作に自動的に適用されます。
このインストラクションを読み込むと、Copilotは以下のプロジェクトに対して公式 Ruby MCP SDK (mcp gem) 前提でコード生成をするようになります。

  • Rubyコード
  • Gemfile
  • gemspec
  • rake task

以下の関連ファイルを対象に動作します。

  • **/*.rb
  • **/Gemfile
  • **/*.gemspec
  • **/Rakefile

具体的にはCopilotは以下のような行動をとります。

mcp gem 前提になる

Copilotは最初に gem 'mcp' をインストールします。
つまり公式 Ruby MCP SDK を使う前提で動作します。

MCP::Serverが中心になる

Copilotは独自 server class を作らず、必ず以下の構成を中心に設計します。

server = MCP::Server.new(
  name: 'my_server',
  version: '1.0.0'
)

構成は以下の通りになります。

MCP::Server
 ├─ Tool
 ├─ Resource
 ├─ Prompt
 └─ Transport

ToolをMCP::Toolで作る

Copilotは以下を推奨パターンとします。

class GreetTool < MCP::Tool

定義内容に以下を持ちます。

  • tool_name
  • description
  • input_schema
  • output_schema
  • annotations

例えば以下のようにコードを実装します。

def self.call(name:, server_context:)
  MCP::Tool::Response.new(
    [{ type: 'text', text: "Hello #{name}" }]
  )
end

これによりClass-based Toolを優先します。

Input Schema を必須化する

Copilotは型定義を必ず付けます。
例えば以下のように実装を行います。

input_schema(
  properties: {
    name: {
      type: 'string'
    }
  },
  required: ['name']
)

Output Schemaも定義する

Copilotは出力もschema化します。
例えば以下のような定義を行います。

output_schema(
  properties: {
    message: { type: 'string' }
  }
)

structured_content を返す

ただtextを返すだけではなく以下の形式で返り値を作成します。

MCP::Tool::Response.new(
  [{ type: 'text', text: json }],
  structured_content: data
)

人間向けにはcontentを、LLM向けにはstructured_contentを返す二層構造になります。

Tool Annotationを重視する

Copilotはmetadataを付けます。
例えば以下のような構造です。

annotations(
  read_only_hint: true,
  idempotent_hint: true
)

主なAnnotationは以下の通りです。

Annotation 意味
read_only_hint 読み取り専用
destructive_hint 破壊的変更
idempotent_hint 同入力=同結果
open_world_hint 外部依存あり

minitest前提でテストを書く

CopilotはMinitestを使います。
テスト対象はsuccess、validation、division by zero、error stateなどです。

AWESOME-COPILOTのドキュメントを読む その111(Quarkus)

本日はAWESOME-COPILOTの技術調査枠です。
AWESOME-COPILOTのドキュメントを読みながら実際に操作を試して記事に残します。
今回はカスタムインストラクションの一つQuarkusについてです。

Quarkus

QuarkusはGitHub Copilotを「Quarkus専門のJavaバックエンドエンジニア」にするルールです。
QuarkusはJava向けの高速・軽量なクラウドネイティブフレームワークです。

以下のページからGenaiscriptのインストールボタンをクリックして取得します。
github.com

インストールボタンを押してQuarkusをダウンロードします。
すると.github/instructions配下にインストラクションがインストールされます。

インストールしたインストラクションはCopilotの動作に自動的に適用されます。
このインストラクションを読み込むと、Copilotは「Quarkus backend developer」としてコードを生成するようになります。

具体的にはCopilotは以下のような行動をとります。

Java 17+前提になる

CopilotはJava 17以上のモダン機能を積極利用します。
またQuarkus 3系の標準設計を使います。

開発標準を守る

各クラス、メソッド、複雑なロジックには、明確かつ簡潔なコメントを記述します。
また最適なパフォーマンスと保守性を実現するために、Quarkusのコーディング標準とベストプラクティスを遵守します。
レコードやsealedクラスなど、Java 17以降の機能を適切に使用するようになります。

命名規則を厳格化する

クラス名にはパスカルケースを使用し、メソッド名と変数名にはキャメルケースを使用します。
定数にはすべて大文字を使用します。

Quarkusを活用する

Copilotは以下のQuarkusの機能を活用して開発を行うようになります。

  • Quarkus開発モードを活用して開発サイクルを短縮します。
  • Quarkus拡張機能とベストプラクティスを使用して、ビルド時の最適化を実装するようになります。
  • 最適なパフォーマンスを実現するために、GraalVMを使用したネイティブビルドを設定します。
  • 一貫性のあるログ記録のために、Quarkusのログ機能(JBoss、SL4J、またはJUL)を使用します。

Quarkus固有のルールを守る

Copilotは以下のQuarkus固有のルールを守ります。

  • シングルトンBeanには`@Singleton`ではなく`@ApplicationScoped`を使用します。
  • 依存性注入には`@Inject`を使用します。
  • 従来のJPAリポジトリよりもPanacheリポジトリを優先します。
  • データを変更するサービスメソッドには`@Transactional`を使用します。
  • 分かりやすいRESTエンドポイントパスには`@Path`を適用します。
  • RESTリソースには`@Consumes(MediaType.APPLICATION_JSON)`と`@Produces(MediaType.APPLICATION_JSON)`を使用します。

新機能開発時に開発ワークフローに従う

新機能を作成する場合、Copilotは以下の開発ワークフローに従うようになります。

  1. 適切なバリデーションを持つエンティティを作成します。
  2. カスタムクエリを持つリポジトリを作成します。
  3. ビジネスロジックを持つサービスを作成します。
  4. 適切なエンドポイントを持つRESTリソースを作成します。
  5. 包括的なテストを作成します。
  6. 適切なエラー処理を追加します。
  7. ドキュメントを更新します。

AWESOME-COPILOTのドキュメントを読む その110(Python MCP Server Development)

本日はAWESOME-COPILOTの技術調査枠です。
AWESOME-COPILOTのドキュメントを読みながら実際に操作を試して記事に残します。
今回はカスタムインストラクションの一つPython MCP Server Developmentについてです。

Python MCP Server Development

Python MCP Server DevelopmentはGitHub Copilotを「Python製 MCP Server 専門エンジニア」にするルールです。
特に以下に最適化されます。

  • Python MCP SDK
  • FastMCP
  • uv
  • stdio / HTTP transport
  • Tool / Resource / Prompt registration

以下のページからGenaiscriptのインストールボタンをクリックして取得します。
github.com

インストールボタンを押してPython MCP Server Developmentをダウンロードします。
すると.github/instructions配下にインストラクションがインストールされます。

インストールしたインストラクションはCopilotの動作に自動的に適用されます。
このインストラクションを読み込むと、CopilotはPython/pyproject.toml/requirements.txtに対してModel Context Protocol(MCP)Server開発前提でコード生成するようになります。

以下の関連ファイルを対象に動作します。

  • **/*.py
  • **/pyproject.toml
  • **/requirements.txt

具体的にはCopilotは以下のような行動をとります。

パッケージ管理はuvが前提となる

Copilotはpip/poetryではなくuvを使います。

初期化
uv init mcp-server-demo
MCP SDK追加
uv add "mcp[cli]"

FastMCPを標準採用する

普通の低レベルServer APIではなくFastMCPがデフォルトになります。

Import
from mcp.server.fastmcp import FastMCP
Server生成
mcp = FastMCP("My Server")

Decoratorベース登録を使う

MCP要素登録がdecorator方式になります。
関数 = MCP capabilityとして生成されます。

Tool
@mcp.tool()
def calculate(a: int, b: int) -> int:
    return a + b
Resource
@mcp.resource("users://{id}")
def get_user(id: str):
    return "..."
Prompt
@mcp.prompt()
def review():
    ...

Structured Outputを優先する

Copilotはdict返却より型モデルを優先します。
以下を使用推奨します。

  • Pydantic
  • TypedDict
  • dataclass

Context利用を前提にする

Copilotはctx: Contextを使います。

Import
from mcp.server.fastmcp import Context
Tool例
@mcp.tool()
async def process(
    text: str,
    ctx: Context
):

これにより以下が使えます。

  • logging
  • progress
  • user interaction
  • LLM sampling

ログ出力は ctx.info() を使う

CopilotはMCP loggingを使います。

await ctx.debug()
await ctx.info()
await ctx.warning()
await ctx.error()

MCP内からLLM Sampling可能とする

Copilotは:ctx.session.create_message()を使います。
例えば以下のコードです。

result = await ctx.session.create_message(
    messages=[...],
    max_tokens=100
)

つまりMCP Tool内部でAI推論が可能になります。

MCP Inspector前提でテストする

Copilotはテスト方法も誘導します。

Inspector
uv run mcp dev server.py
Claude Desktop install
uv run mcp install server.py

AWESOME-COPILOTのドキュメントを読む その109(Project Context)

本日はAWESOME-COPILOTの技術調査枠です。
AWESOME-COPILOTのドキュメントを読みながら実際に操作を試して記事に残します。
今回はカスタムインストラクションの一つProject Contextについてです。

Project Context

Project ContextはGitHub Copilot を「Moodle専用PHP/Plugin開発アシスタント」にするルールです。
Moodle は、学校・企業向けの「学習管理システム(LMS: Learning Management System)」です。

以下のページからGenaiscriptのインストールボタンをクリックして取得します。
github.com

インストールボタンを押してProject Contextをダウンロードします。
すると.github/instructions配下にインストラクションがインストールされます。

インストールしたインストラクションはCopilotの動作に自動的に適用されます。
このインストラクションを読み込むと、CopilotはPHP、JavaScript、Mustache、XML、CSS/SCSSをMoodle開発前提で生成するようになります。

以下の関連ファイルを対象に動作します。

  • **/*.php
  • **/*.js
  • **/*.mustache
  • **/*.xml
  • **/*.css
  • **/*.scss

具体的にはCopilotは以下のような行動をとります。

Moodleプロジェクト前提になる

Copilotはコード生成時に Moodle repository と判断して振る舞います。
前提として以下を理解します。

  • Plugin development
  • Theme customization
  • CLI scripts
  • Moodle API integration

Moodle Plugin構造を強制する

Copilotは標準ディレクトリ構造を守ります。
例えば plugin を作ると以下の構成を遵守します。

local/myplugin/
├── classes/
├── db/
├── lang/
├── templates/
├── version.php
├── settings.php
└── lib.php

Moodle namespace(Frankenstyle)を使う

普通のnamespaceではなく、Moodle固有のFrankenstyle namingを使います。

Moodle標準実装を選ぶ

方法が複数ある場合、CopilotはMoodle recommended approachを選択します。
例えばフォームならmoodleformを優先します。
DB変更ならinstall.xml、upgrade.phpの正式手順を優先します。

生成できる機能

Copilotは特に以下の生成が得意になります。

ローカルプラグイン生成

local/myplugin/の雛形一式。

install.xml

DBテーブル定義。

upgrade.php

マイグレーション。

moodleform

フォーム生成。

Renderer + Mustache

UI表示。

Moodleに存在しない関数を作らない

Copilotは架空のMoodle APIを生成しないよう制約されます。
つまりmoodle_get_user()みたいな架空関数を避けます。