こんにちは、技術広報の yayawowo です。 私たち株式会社ラクス開発本部では、Missionである 「顧客の成長を支援する、圧倒的に使いやすいクラウドサービスを創り提供する」 を念頭に、日々プロダクト開発に励んでいます。 現在、ラクスでは歴史あるロングセラーのプロダクトから、近年立ち上がった新規プロダクトまで、多くの開発プロジェクトが並行して動いています。このように古いものから新しいものまで多くのプロダクト開発に深く携われるからこそ、エンジニアやデザイナーが触れられる技術の機会が非常に多い点が、私たちの組織の大きな特徴であり魅力です。 本記事では、各プロダクトの「技術スタック」を改めて整理し、皆様に最新情報をお届けしたいと思います！自社開発に携わるエンジニア、デザイナーだけでなく、これから携わりたい！という方にも必見の内容です。 現場のリアルな最新データから見えてきたのは、単なるツールの変更履歴ではありません。 ラクスが開発組織として一貫して掲げている「技術選定の思想」そのものでした。 各組織の最新スタックを公開する前に、まずは私たちが大切にしている「2つのコア思想」を技術広報の視点からご紹介します！ 1. ラクスが技術選定で掲げる「2つのコア思想」 ① お客様の日常を守り、進化させるための「顧客志向」 ② 技術を「価値創造」に集中させるための「AIネイティブ＆自動化」 2. 各プロダクトの紹介 ＆ 最新技術スタック 楽楽精算 楽楽明細 楽楽電子保存 楽楽債権管理 楽楽勤怠（給与計算） 楽楽販売 楽楽請求 楽楽自動応対開発 楽楽メールマーケティング blastmail / blastengine 3. それを支える連携部署の技術スタック フロントエンド推進課 SRE AI開発課 ＆ AIエージェント開発課 QA課 インフラ開発部 プロダクトデザイナー 4. 終わりに 1. ラクスが技術選定で掲げる「2つのコア思想」 今回、全社規模で集まった最新のデータを見て、技術広報である私が一番強く感じたのは、ラクスが大切にしている「技術選定のブレない軸」でした。私たちは、単に流行りのツールを追いかけるのではなく、以下の2つの思想をベースに日々の開発環境をアップデートしています。 ① お客様の日常を守り、進化させるための「顧客志向」 ラクスにとって、技術は「自分たちが使いたいから」選ぶものではありません。すべては「お客様の業務をいかに楽にできるか」という目の前の課題を解決するための最高の手段です。 私たちのクラウドサービスは、ありがたいことに数万社を超えるお客様の日常のビジネスを支える社会インフラになっています。だからこそ、長年培った圧倒的な安定基盤を深くリスペクトし、1分1秒のダウンも許されない堅牢性を守り抜く責任があります。しかし、私たちは「守り」だけでは終わりません。お客様へより速く、より安全に新しい価値を届けるために、歴史のあるプロダクトほど「お客様の未来のために、今最適な武器は何か」を貪欲に追求し、裏側では大胆なモダナイズを仕掛けています。 ② 技術を「価値創造」に集中させるための「AIネイティブ＆自動化」 お客様の課題解決に1分1秒でも多くの時間を割くため、ラクスはエンジニアの創造性を奪う泥臭い手作業や無駄な作業を徹底的に排除する環境作りに本気で取り組んでいます。 今回、一際目を引いたのが、各現場の「AIと自動化へのリアルな使い分け」です。単に世間の流行りに乗って同じツールを一律で入れるのではなく、プロダクトの特性に合わせて最適な技術スタックを現場主導で選定しています。そして何より特徴的なのが、ほぼすべての組織が、実装前の「壁打ち相手」としてAIをフル活用している点です。単にツールを入れて楽をするためではなく、エンジニアが本来向き合うべき「顧客のための価値ある設計や、より良いユーザー体験の創造（本質）」に100%集中できる環境を、ラクスは本気で作り上げています。 具体的にどんなツールを、どんな考え方で使い分けているのか？ それは、この後各プロダクトの技術スタックにてご紹介します。 2. 各プロダクトの紹介 ＆ 最新技術スタック ここからは、ラクスが展開する各クラウドサービスと、現場のエンジニアが2026年度現在、実際に選定して使っている技術スタックをご紹介します。 楽楽精算 会社の「経費精算」にかかる時間と労力を劇的に減らすシステムです。利用者はスマホで領収書を撮影するだけで金額や日付が自動入力され、面倒な紙の提出や手入力をすることなく精算を完了できます。経理担当者にとっても、確認や承認の負担を大幅に削減する「日本のバックオフィスを楽にする」代名詞的な存在です。 ✅バックエンド カテゴリ 技術スタック 使用言語 Java、Swift、Kotlin MW PostgreSQL、Postfix、Apache、Room、Realm FW・ライブラリ Spring Boot、jQuery、Retrofit2 開発ツール IntelliJ IDEA、Xcode、Android Studio、Flyway、Redmine、GitHub、VSCode CI・テスト Selenide、Gradle、JUnit、JMeter、Jenkins、GitHub Actions AI Claude Code、Codex、GitHub Copilot、Gemini、ChatGPT、Notebook LM、Cursor ※2026年7月時点での情報です。 ✅フロントエンド カテゴリ 技術スタック 使用言語 HTML、CSS、JavaScript、TypeScript FW・ライブラリ React、jQuery、MUI、Jotai、zod、TanStack Form、Tanstack Query、Sass、Vite、ESLint、Prettier、Biome、Storybook、msw 開発ツール GitHub、GitHub Projects、VSCode、OpenAPI、Figma CI・テスト GitHub Actions、Jenkins、Playwright、Vitest AI Claude Code、Codex、GitHub Copilot、Gemini、ChatGPT、Notebook LM ※2026年7月時点での情報です。 楽楽明細 企業が取引先に発行する「請求書」や「納品書」を、すべてWeb上で一括配信するシステムです。これまでは担当者が印刷し、封筒に詰め、切手を貼って郵送していた手作業をゼロにします。受け取る側の取引先もマイページからいつでも即座に確認・ダウンロードできるため、双方のペーパーレス化と業務スピードアップを同時に実現しています。 カテゴリ 技術スタック 使用言語 Java、TypeScript、JavaScript MW PostgreSQL、Tomcat、Postfix、Docker、Redis、AWS Lambda / EventBridge / Step Functions / S3 / SQS FW・ライブラリ SpringBoot、React、Redux、JasperReports、Lombok、Jooq、jQuery、GraphQL 開発ツール IntelliJ IDEA、VSCode、Redmine、GitHub、gulp.js、webpack、Storybook CI・テスト Gradle、jUnit、Playwright、GitHub Actions AI Claude、Claude Code、GitHub Copilot、ChatGPT、Codex、Notebook LM、Gemini ※2026年7月時点での情報です。 楽楽電子保存 国税関係の書類（領収書や請求書など）を、国が定める「電子帳簿保存法」の厳しい要件に100%準拠して、安全にクラウド保存・一元管理できるシステムです。ユーザーは「法律が変わってどう対応すればいいかわからない…」という不安から解放され、検索機能を使っていつでも過去の書類を1秒で見つけ出せるようになります。 カテゴリ 技術スタック 使用言語 Java、TypeScript、JavaScript MW PostgreSQL、Nginx、Tomcat、Postfix、Docker、Kubernetes、Node.js、AWS Lambda / S3 / DynamoDB / API Gateway / SQS FW・ライブラリ React、MUI、MSW、Spring Boot、Jooq 開発ツール IntelliJ IDEA、GitHub、Vite、VSCode、Open API、Figma、ESLint、Prettier、Yarn CI・テスト Gradle、JUnit、GitHub Runner、Vitest、Cypress、argoCD、Playwright、GitHub Actions AI Claude、Claude Code、GitHub Copilot、ChatGPT、Codex、Notebook LM、Gemini ※2026年7月時点での情報です。 楽楽債権管理 「取引先からちゃんとお金が振り込まれているか」を確認する、企業の経理で最も神経を使う入金消込・債権管理業務をスムーズにするシステムです。銀行の入金データと自社の請求データを自動で照合し、ミスマッチがあればすぐに通知。人の目によるダブルチェックや残高管理のプレッシャーから担当者を解放し、確実な資金管理を支えます。 カテゴリ 技術スタック 使用言語 Java、TypeScript、JavaScript MW PostgreSQL、Tomcat、Postfix、Docker、Redis、AWS S3 FW・ライブラリ React、MUI、Spring Boot、Jooq、DuckDB 開発ツール IntelliJ IDEA、VSCode、Redmine、GitHub、Storybook、Open API、Figma CI・テスト Gradle、jUnit、Playwright、GitHub Actions AI Claude、Claude Code、GitHub Copilot、ChatGPT、Codex、Notebook LM、Gemini ※2026年7月時点での情報です。 楽楽勤怠（給与計算） 従業員の日々の「出退勤」を正しく記録し、労働時間や時間外労働時間を自動で集計、そのまま給与計算システムへとデータをスムーズに連携させるシステムです。シフト管理や有給休暇の消化状況もひと目でわかるため、中小企業から大企業まで、複雑な労務管理をミスなくシンプルに行える環境を作ります。 カテゴリ 技術スタック 使用言語 PHP、Python、JavaScript、TypeScript MW MySQL、Nginx、Docker、Node.js、Gunicorn FW・ライブラリ Flow、Vue.js、Fast API、Pinia / Pinia Colada, Vue Router, Vue I18n, Vite, Tailwind CSS, ESLint, Prettier, Storybook, msw 開発ツール GitHub、GitHub Projects、PhpStorm、IntelliJ IDEA、VSCode、Cursor、OpenAPI、Figma、renovate CI・テスト GitHub Actions、PHPUnit、PHPStan、Selenium、Ansible AI Claude、Claude Code、GitHub Copilot、ChatGPT、Codex、Notebook LM、Gemini、VertexAI ※2026年7月時点での情報です。 楽楽販売 販売管理、顧客管理、案件管理など、自社のやりたい業務に合わせて画面や項目をノーコードで自由自在に構築できるWebデータベースシステムです。Excelで属人化してしまっていた複雑なデータをチーム全員で見える化し、ボタン一つでの帳票発行や、ルーチンワークの自動化によって、会社全体のコア業務を劇的にスピードアップさせます。 カテゴリ 技術スタック 使用言語 PHP、Java MW PostgreSQL、Postfix、Apache、Redis FW・ライブラリ Zend Framework、jQuery 開発ツール VS Code、Cursor、GitHub CI・テスト Selenium/Selenide、PHPUnit、JMeter、Jenkins、PHPStan、Playwright AI Claude Code、Codex、ChatGPT、Devin、Notebook LM ※2026年7月時点での情報です。 楽楽請求 取引先から紙、PDF、メールなど様々な形でバラバラに届く「受領請求書」を、一つの画面でスマートに一元管理するシステムです。高性能なAI-OCRが中身を自動で読み取ってくれるため、手入力の手間が激減。仕訳データや支払処理、データの保存までをワンストップで効率化し、毎月発生する「請求書処理の山」を瞬時に片付けます。 カテゴリ 技術スタック 使用言語 Java, Kotlin、TypeScript MW PostgreSQL、Pure Storage、Redis、nginx、Tomcat、Kubernetes、AWS[SQS、SES、S3] FW・ライブラリ Spring Boot、jOOQ、React、MUI、Storybook 開発ツール IntelliJ IDEA、Flyway、Gradle、detekt、GitHub、OpenAPI、Figma CI・テスト Playwright、Kotest、Vitest、ArgoCD、Grafana AI GitHub Copilot、ChatGPT、Devin、Notebook LM、Claude ※2026年7月時点での情報です。 楽楽自動応対開発 お客様から届く膨大な問い合わせメールやチャットを、チーム全員で一元管理・共有するシステムです。「誰がどのメールに対応しているか」「返信待ちか、対応済か」がリアルタイムに全員に共有されるため、ネットショップやサポート窓口での対応漏れや、二重返信によるクレームを完全に防ぎ、顧客対応の品質を最大化します。 カテゴリ 技術スタック 使用言語 PHP、Node.js、TypeScript MW PostgreSQL、Apache、Postfix、AWS Lambda / S3 / DynamoDB / SQS、Qdrant FW・ライブラリ Laravel、jQuery、CKEditor、Socket.IO、Vue.js、NestJS 開発ツール PhpStorm、Github、VS Code CI・テスト Selenium/Selenide、PHPUnit、Vitest、Biome、Jenkins、GitHub Actions、Ansible AI Claude Code、Codex、GitHub Copilot、 ChatGPT、 Devin、 Notebook LM ※2026年7月時点での情報です。 楽楽メールマーケティング 企業のマーケティングや営業担当者が、顧客へ一斉にメルマガや案内メールを配信し、そこからの成果を最大化するためのシステムです。ただ送るだけでなく、「誰がメールを開いたか」「どのURLをクリックしたか」を直感的に分析可能。見込み客の興味関心を可視化することで、次の商談獲得へのアプローチをシンプルかつ効果的に支えます。 カテゴリ 技術スタック 使用言語 PHP、TypeScript MW PostgreSQL、Postfix、Nginx、Apache、Redis FW・ライブラリ Slim、jQuery、Vue.js 開発ツール PhpStorm、GitHub、Docker、Podman CI・テスト Playwright、Puppeteer、Jenkins、JMeter、PHPUnit、PHPStan、PHP_CodeSniffer、PHPDoc、Ansible、vegeta AI Claude Code、Codex、GitHub Copilot、ChatGPT、Devin、Notebook LM ※2026年7月時点での情報です。 blastmail / blastengine 「blastmail」は数百万通ものメールを顧客へ一瞬で確実に届ける独自の配信システム、「blastengine」はエンジニアが自社のシステムやアプリに組み込んで、通知メールなどを超高速で自動配信させるためのAPI・リレーサービスです。どちらも「遅延なく、迷惑メールに振り分けられることなく、確実に届ける」という配信技術の極限を支えています。 カテゴリ 技術スタック 使用言語 Java、TypeScript、Go、Python MW Docker、PostgreSQL、MongoDB、Postfix、RabbitMQ、AWS[EC2、ECS、RDS、S3、Lambda、SQS] FW・ライブラリ SpringBoot、React、Quarkus 開発ツール VSCode、GitLab、Redmine、Gradle、OpenAPI、Figma、StoryBook CI・テスト GitLab CI/CD、JUnit、Vitest、Biome、Playwright AI Claude Code、Codex、GitHub Copilot、Gemini、ChatGPT、Notebook LM ※2026年7月時点での情報です。 3. それを支える連携部署の技術スタック ラクスには、各プロダクトの提供価値を最大化し、開発組織全体のエンジニアリング水準を横断的に引き上げる連携・専門組織が存在します。実務で選定している先進的な「武器」をご紹介します。 フロントエンド推進課 フロントエンド推進課は、ラクスの各サービス開発チームと協力し、フロントエンド領域からプロダクトの成長と品質向上を支える専門組織です。 新機能開発や既存機能のUI/UX改善に加え、技術的負債の解消、リアーキテクト、パフォーマンス改善、デザインシステム構築、共通UIコンポーネント開発など、サービス単体では対応しきれない横断的なテーマにも取り組んでいます。 各プロダクトの事業フェーズや技術課題を踏まえ、開発現場に入り込みながら、ユーザーにとって使いやすく、開発者にとって継続的に改善しやすいフロントエンドを実現していくことが役割です。 技術を目的化するのではなく、ユーザー価値、開発生産性、品質、保守性を高めるためにどう活用するかを重視し、プロダクトとチームの両面からラクスのサービス成長に貢献しています。 カテゴリ 技術スタック 使用言語 HTML、CSS、JavaScript、TypeScript FW・ライブラリ React, TypeScript, MUI, RHF, zod, Tanstack Router, Tanstack Query, zustand, emotion, Vue.js, Pinia / Pinia Colada, Vue Router, Vue I18n, Vite, Tailwind CSS, ESLint, Prettier, Storybook, msw 開発ツール GitHub, Github Projects, VSCode, OpenAPI, Figma, renovate CI・テスト GitHub Actions, Playwright, Vitest, happy-dom AI Claude Code, Codex, Copilot, ChatGPT, Gemini, Notebook LM ※2026年7月時点での情報です。 SRE ラクスにおけるSREでは、開発とインフラの知見を活かして顧客への価値提供スピード向上に寄与する自動化・標準化（生産性向上のための取り組み）を推進する役割を担います。 開発とインフラを繋ぐHubというビジョンを持ちながら、システムのモダナイズ化や基盤の構築を行う役割です。 開発言語は主にGoを利用し、横断的なトイル削減や運用の自動化を推進しています。 新しい技術スタック調査などを進めながらノウハウを各サービスへ広めることで、開発部門全体のアーキテクチャ刷新へ寄与していきます。 カテゴリ 技術スタック 使用言語 Go 仮想基盤 Kubernetes MW PostgreSQL, Amazon Aurora, Redis, Kafka FW・ライブラリ gRPC CI/CD・IaC GitHub Actions, ArgoCD, Argo Workflows, Argo Event, Hashicorp Vault, Terraform, Helm 運用・監視 Grafana Stack AI Claude Code, Codex, GitHub Copilot, ChatGPT, Devin, Notebook LM ※2026年7月時点での情報です。 AI開発課 ＆ AIエージェント開発課 ラクスが提供する各プロダクトへ実用的なAI機能を組み込むための研究開発や、社内の複数プロジェクトを横断して業務を自動化する「AIエージェント」の実装・導入を牽引する最先端チームです。 ✅AI開発課 カテゴリ 技術スタック 使用言語 Python MW PostgreSQL、Redis、DynamoDB、Docker、Kubernetes FW・ライブラリ PyTorch、Keras、TensorFlow、FastAPI、OpenAI API、AWS Bedrock、Vertex AI 開発ツール GitHub CI・テスト GitHub Actions、pytest、Terraform AI（開発支援） Claude Code、GitHub Copilot、ChatGPT、Notebook LM、Cursor (OpenSpec) ※2026年7月時点での情報です。 ✅AIエージェント開発課 カテゴリ 技術スタック 使用言語 Java, TypeScript, Python MW amazon corretto, tomcat, postgres, Kubernetes, AWS[Lambda, SQS, SNS, Bedrock, EKS, CloudWatch, DynamoDB, S3, KMS], ArgoCD, Grafana, Litellm, flipt, Otel-collector FW・ライブラリ Spring Boot, Mastra, Hono 開発ツール Gradle, Github, Zed, Visual Studio Code, pnpm, mise CI・テスト junit, vitest, testcontainer, Github Actions AI（開発支援） Claude Code, Codex, Github Copilot Agent, Devin ※2026年7月時点での情報です。 QA課 各プロダクトに準ずる開発環境や仕様を深く理解し、お客様に届くクラウドサービスの品質を「テスト・保証」の側面からハックする品質専門組織です。 カテゴリ 技術スタック 使用言語・MW 各プロダクトに準ずる 開発ツール・FW 各プロダクトに準ずる CI・テスト Playwright、Jenkins 他、各プロダクトに準ずる AI Claude Code、ChatGPT、Gemini、Notebook LM ※2026年7月時点での情報です。 インフラ開発部 8割のサービスリソースをオンプレミスで構築しております。 オンプレミス環境でも自動化などなるべくソフトウェア視点のアプローチが出来るようにHCIで基盤構築し運用効率化をしています。 今後のアップデートとしては、クラウドで先行構築したクラウドネイティブなコンテナ環境やCI/CD環境などをオンプレミス環境にフィードバックし、自動化、自立化を推進しつつもコスト優位性を出せるシステムを構築していきます。 カテゴリ 技術スタック 使用言語 Python、Bash プラットフォーム On-Premise、AWS「EC2、ECS、EKS、RDS、S3、Lambda・・・etc」、GCP ネットワーク Cisco、Dell、Paloalto、F5 OS・仮想化 LinuxOS、VMware、Nutanix、Docker、K8S MW PostgreSQL、Apache、Tomcat、Nginx、PaceMaker、etc... IaC Ansible、Terraform その他ツール Git、Rundeck 運用・監視 Zabbix、Grafana、Prometheus、ArgoCD AI GitHub Copilot、ChatGPT、Devin、Claude、Gemini ※2026年7月時点での情報です。 プロダクトデザイナー フロントオフィス・バックオフィスの業務システムにおける管理画面のUI/UX設計を担当しています。 業務ドメインの理解を深め、ユーザーの声を直接収集しながら課題を把握し、複雑な業務をUI/UXの力でシンプルに解決することを目指している組織です。 また、AI活用による設計業務の効率化、サービス横断での一貫した体験を実現するデザインガイドラインの策定、さらにデザイン組織としての勉強会やナレッジ共有にも取り組んでいます。 カテゴリ 技術スタック デザインツール Figma コミュニケーションツール Slack、Zoom、Google Meet、FigJam AI（業務支援） GitHub Copilot、Claude Code、Cursor、ChatGPT、Notebook LM、Gemini ※2026年7月時点での情報です。 4. 終わりに 最新の技術スタック、あなたの得意な技術や、挑戦してみたい武器はどこかに見つかりましたでしょうか？ ラクスがこれほどまでに技術スタックをオープンにし、長年愛されている歴史あるプロダクトであっても現状に甘んじず変化を続けさせているのには、明確な理由があります。それは、私たちのミッションが「ITサービスで企業の成長を継続的に支援」することだからです。 技術はあくまで、誰かの課題を解決するための素晴らしい手段です。しかし、最高の手段をエンジニアが持たなければ、お客様に最高の価値を届けることはできません。 だからこそ私たちは、これまで培ってきた圧倒的な安定基盤を深くリスペクトしつつも、時代に合わせたインフラの進化や、AIを活用した開発体制へのアップデート、品質を支える仕組みづくりに注力しています。 「自分が今まで培ってきたスキルを、このクラウドサービスで活かしてみたい」 日々進化する技術を積極的に取り入れ、自社プロダクトの未来を共に創り上げていきたい。 そう少しでも感じていただけたなら、その力をぜひラクスで発揮してみませんか。 最後までお読みいただき、ありがとうございました。

こんにちは、ミイダス Tech Officeです。 ミイダス株式会社のテックチームが直近で開発した機能を現場のエンジニアから共有する「MIIDAS Tech LIVE」。 第13回目の開催となる今回は3つのリリース情報をお届けしました。 採用マッチングサービス「ミイダス」は、独自の診断ツールで採用のミスマッチを減らす中途採用サービスです。メインの採用関連の機能に加え、診断や研修、組織サーベイの支援金の検索機能など、幅広い機能開発が行われています。 MIIDAS Tech LIVE #13 (2026/03/25 12:00〜) ## 📢 概要 MIIDAS Tech LIVEでは、ミイダス株式会社のテックチームが直近で開発した機能を現場のエンジニ miidas-tech.connpass.com

はじめに ども！GitHub Copilot の設定に対して徐々に理解が進んでいる龍ちゃんです。 これまでの記事で、 AGENTS.md と Custom Agents の違い と、 copilot-instructions.md の分割設計 について解説してきました。 で、ここまで読んでくれた方は気づいたかもしれません。 AGENTS.md と copilot-instructions.md、書く内容かぶってない？ と。 機能的には両者が近い機能を持っているように感じています。発火条件も近いですしね。 んでよ！どっちのファイルも同じタイミングで読み込まれるなって話になってしまいまして迷子になりました。そりゃ、「AGENTS.md」は参照されるだけで、GitHub Copilot がメインでメンテナンスしているものではないですからね。 というわけで、今回はそれぞれの設定ファイルの公開されている「設定すべき情報」から共生させる方法について考えた内容に関して触れていこうと思います。それぞれのファイルの設定すべき内容にも触れるので、AGENTS・instructions どちらかしか使ってねえ！って方でもそれぞれのファイルで設定すべき内容について触れるから安心してね。 ぶっちゃけ前提 プロジェクト上、とんでもなく特殊な事情がない限り どっちかに寄せたい ！だってメンテナンスとか、どっちのファイルに何書くとか考えるのめんどくさいもん！ なんでこれはチーム向けの記事だと思って読み物で。特殊な状況になった皆さんにお疲れさまと、もしもっといい方法があるってわかったら連絡くださいってお気持ちを置いときます。 検証環境 検証日: 2026年1月30日 環境: VS Code + Dev Container GitHub Copilot: 2026年1月時点の機能 複数ファイルの読み込み動作 まず、Copilot Coding Agent がどのファイルを読み込むのかを整理します。 ポイント : 競合ではなくマージ される 矛盾する指示があった場合の優先順位は 公式未定義 → 矛盾を避ける設計が必要 全部読み込んでマージされるってことは、同じことを両方に書いたら重複するし、矛盾したら何が優先されるかわからないってことです。 公式が推奨する記載内容 両ファイルにどのような内容を書くべきか、公式が推奨している内容を整理します。 copilot-instructions.md の公式推奨（5セクション） 出典: 5 tips for writing better custom instructions for Copilot – GitHub Blog セクション 英語名 書くべき内容 プロジェクト概要 Project Overview アプリの目的、対象ユーザー、主要機能 テックスタック Tech Stack Backend/Frontend/Testing のフレームワーク、API コーディングガイドライン Coding Guidelines 言語ルール（セミコロン、型ヒント等）、セキュリティ慣行 プロジェクト構造 Project Structure フォルダ構成と各ディレクトリの用途 リソース Resources 開発スクリプト、MCPサーバー、自動化ツール 制約 : 2ページ以内 AGENTS.md の公式推奨（6セクション） 出典: How to write a great agents.md – GitHub Blog セクション 英語名 書くべき内容 コマンド Commands ビルド、テスト、リントの実行コマンド（フラグ含む） テスト Testing テストフレームワーク、実行方法 プロジェクト構造 Project Structure ディレクトリ構成の説明 コードスタイル Code Style Good/Bad のコード例、命名規則 Gitワークフロー Git Workflow コミット慣行、ブランチ戦略 境界線 Boundaries Always / Ask First / Never ベストプラクティス : コマンドを先頭に配置、説明より具体例を重視 公式推奨の重複に注目 両方の公式推奨を見比べると、 重複する項目 があることがわかります。 項目 copilot-instructions.md AGENTS.md プロジェクト構造 ○ ○ テスト ○（Tech Stack内） ○ コードスタイル ○（Coding Guidelines） ○ 公式は「What vs How」の分離を明示的に推奨していません。 これはおそらく以下の理由によるものです： 単独利用を想定 : どちらか一方だけ使う場合でも完結するように クロスツール互換 : AGENTS.md は他のAIツールでも使うため、Copilot固有の情報に依存しない 次のセクションで紹介する「What vs How 分離」は、 両方を併用する場合に重複・矛盾を避けるための筆者独自の設計指針 として提案するものです。 役割分担の原則: What vs How【筆者独自の提案】 注意 : 以下は公式推奨ではなく、両ファイル併用時の重複・矛盾を避けるための筆者独自の設計指針です。 両方使うなら、役割分担が必要です。僕が考えた分離の基準は「 What vs How 」です。 観点 copilot-instructions.md AGENTS.md 責務 What （何をするか） How （どうやるか） 内容 方針・規約・制約 手順・コマンド・境界線 更新頻度 低（安定したルール） 中〜高（手順は変わりやすい） 適用範囲 Copilot 全機能 Coding Agent 中心 なぜこの分離が有効か copilot-instructions.md は .github/ ディレクトリにあって、機能変更とは別にコミットされることが多いです。レビュー時も「設定変更」として独立して見られます。 一方、AGENTS.md は各ディレクトリに配置できるので、そのディレクトリのファイル変更と一緒にレビューされやすい。つまり「手順」の変更は実装と一緒に更新されるイメージです。 What（方針） は変わりにくい → copilot-instructions.md How（手順） は変わりやすい → AGENTS.md 変更頻度でファイルを分けると管理しやすい 何をどこに書くか【具体例】 copilot-instructions.md に書く内容（What） ## コードスタイル - TypeScript strict mode を使用 - 関数は camelCase、コンポーネントは PascalCase - any 型の使用禁止 ## アーキテクチャ - Clean Architecture に従う - ビジネスロジックは domain/ に配置 - 外部依存は infrastructure/ に隔離 ## 使用ライブラリ - 状態管理: Zustand（Redux は使わない） - フォーム: React Hook Form + Zod - テスト: Vitest + Testing Library 特徴 : 「どうあるべきか」を記述 AGENTS.md に書く内容（How） ## コマンド npm ci # 依存インストール npm run dev # 開発サーバー起動 npm test # テスト実行 npm run lint:fix # リント自動修正 ## 境界線 ### Always Do - テストを書いてから実装（TDD） - 変更したファイルに対応するテストを更新 ### Ask First - 新しいnpmパッケージの追加 - 既存のAPI契約（型定義）の変更 ### Never Do - .env ファイルをコミットしない - console.log を本番コードに残さない 特徴 : 「どうやるか」を記述 同じことを両方に書かない 悪い例（重複） # copilot-instructions.md TypeScriptのstrictモードを使用してください。 テストはVitestで書いてください。 `npm test` でテストを実行します。 ← 手順がここにある # AGENTS.md TypeScriptのstrictモードを使用してください。 ← 重複 テストはVitestで書いてください。 ← 重複 npm test # テスト実行 問題点 : 同じ内容が2箇所に。片方だけ更新すると矛盾が発生。 良い例（分担） # copilot-instructions.md TypeScriptのstrictモードを使用してください。 テストはVitestで書いてください。 ← コマンドは書かない # AGENTS.md ## コマンド npm test # テスト実行 npm run test:watch # ウォッチモード ← 方針は書かない メリット : 責務が明確、更新箇所が1箇所、矛盾が発生しない どっちに書くか迷ったら 新しい指示を追加するとき、どっちに書くか迷ったら 2つの質問 で判断してください。 Q1. Chat や Code Review でも使いたい？ No → AGENTS.md に書く（Coding Agent 専用でOK） Yes → Q2 へ Q2. 「方針」か「手順」か？ 方針 （〜すべき、〜を使う、〜は禁止） → copilot-instructions.md 手順 （コマンド、境界線、具体的な操作） → AGENTS.md シンプルに言うと： こんな内容なら 配置先 「TypeScript strict mode を使う」 copilot-instructions.md npm test で実行 AGENTS.md 「Redux は使わない」 copilot-instructions.md 「.env をコミットしない」（Never Do） AGENTS.md *.instructions.md との組み合わせ 前回記事で紹介した *.instructions.md も含めると、3層構造になります。 copilot-instructions.md # 全体の方針（What） ├── *.instructions.md # ファイル別の詳細ルール（What の詳細） └── AGENTS.md # 手順・コマンド・境界線（How） 内容 配置先 「TypeScript strict mode を使用」 copilot-instructions.md 「React コンポーネントは forwardRef 必須」 frontend-ui.instructions.md 「 npm run lint:fix でリント修正」 AGENTS.md まとめ ファイル 役割 キーワード copilot-instructions.md What（何をするか） 方針・規約・制約 AGENTS.md How（どうやるか） 手順・コマンド・境界線 *.instructions.md What の詳細 ファイル別ルール 複数ファイルは マージ されて読み込まれる 公式推奨には重複があるが、両方使うなら 役割分担 が必要 What と How で分離するのが筆者のおすすめ ただし、特殊な事情がなければ どっちかに寄せる のが一番楽 参考リンク 公式ドキュメント Adding custom instructions for GitHub Copilot – GitHub Docs 5 tips for writing better custom instructions for Copilot – GitHub Blog How to write a great agents.md – GitHub Blog 関連記事 AGENTS.md vs Custom Agents【5つの比較表で混乱解消】 copilot-instructions.md を分割したい？applyTo パターンで解決 ここまで読んでいただき、ありがとうございました！ 正直、両方メンテするのはしんどいので、可能なら片方に寄せてください。でも「Claude Code も使ってるから AGENTS.md は残したい」みたいな状況になったら、この記事を思い出してもらえると嬉しいです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post copilot-instructions.md と AGENTS.md、どっちに何を書く？【公式推奨と使い分け】 first appeared on SIOS Tech Lab .