OTR_CodingAgentAssetsPoints

エージェント用アセットの訴求点

• TOP > プロモーション > エージェント用アセットの訴求点
  • 訴求メッセージ
  • 提案のポイント
  • 評価

概要

OpenTouryoCodingAgentAssets（以下、アセット）を、 OpenTouryo を使うアプリ開発に持ち込むときの訴求点を、リポジトリの事実で裏の取れる形 に纏める。

• アセットは、OpenTouryo でのアプリ開発をコーディング・エージェント（Claude Code・GitHub Copilot・Codex など）に行わせるための、 インストラクション・スキル・役の定義・品質の仕組みの集まりである。
• 一言で言えば、汎用のエージェントが書く「一般的な .NET のコード」と、OpenTouryo の層と規約の間の溝を埋め、 さらに、出来たものが仕様どおりであることを保証する仕組みまでを配る。
• 前半（観点 1〜5）は「書かせ方」、後半（観点 6）は「守らせ方」である。 マーケティング の「価値の所在」で言う サプライ・サイドの付加価値（品質保証能力） を具体にしたものが、観点 6 になる。

基準：アセットの main（815e3d7、2026-11-10）の README と DevelopmentHistory.md。

詳細

訴求点

#	観点	言えること（事実）	利用者にとっての意味
1	オープン標準	スキルは Agent Skills のオープン標準（SKILL.md）に準拠する。プロダクトの差はインストラクションの側だけにあり、インストーラが吸収する	1 回書けば、Claude Code・GitHub Copilot・Cursor・Codex CLI・Gemini CLI など、標準に対応したツールで同じスキルを使える
2	常時の文脈と、必要なときのスキルを分ける	AGENTS.md・TESTING.md（概要・規約・進め方）は常に文脈に載る。スキル（46 本）は、エージェントが description を見て必要なときだけ読む	文脈を圧迫せず、層・機能ごとの詳しい書き方を必要なときに引ける
3	層と規約に合わせた書き方	P・B・D 層、Dao の 3 系統（個別・共通・自動生成）、P 層から B 層の呼び方、例外、トランザクション、一括更新などを、スキルに分けて持つ。対象は Web Forms・ASP.NET MVC・ASP.NET Core MVC・Windows Forms・リッチクライアントの非同期・Web API	エージェントが基盤のベースクラスや処理方式を無視した「一般的な .NET のコード」を書かず、決められた枠（スロット）を埋める作業に近づく
4	立ち上げから運用まで	立ち上げ（起点サンプルの選択・基盤 DLL のビルド・取り出し・構成・Docker の DB・変形）→ 各層の実装 → CRUD 画面 → ログの分析によるレビュー、の各工程にスキルがある	新規のプロジェクトを、エージェントと一緒に最初から立ち上げられる
5	導入の配慮	install.ps1 で対象（claude・copilot・agents）ごとの場所へ配る。-WhatIf で事前に確かめられ、生成マーカーの無い既存のファイルは -Force が無い限り上書きしない。Windows PowerShell 5.1・PowerShell 7 の両方で動く。品質の仕組み・見本は opt-in	既存のリポジトリに、壊さず段階的に入れられる
6	テスト先行と、期待値の保護	下の「観点 6 の中身」と「実測」	AI が作ったものが仕様どおりであることを、仕組みで保証する

観点 6 の中身

• 進め方：規模のある変更は、spec → テスト → plan → 実装 で進める（TESTING.md）。
  仕様（画面定義書・イベント仕様書など）から、先に「B 層のルート メソッドの単体テスト」と「画面の E2E テスト」を起こし、 各ケースに根拠の ID を付け、失敗すること（Red）を確かめてから実装（Green）する。
• 承認の 2 段：テストの質は、実装役と別の レビュー役 が確かめる（編集できず、テストを自分で実行する）。
  人は 仕様の決定だけ を GO / NOGO で判断する。実装役・レビュー役はサブ エージェントの定義として配る（Claude Code 向けのみ）。
• テストのスキル：opentouryo-test-layer-b（NUnit）、opentouryo-test-e2e-web（NUnit・Playwright）。
• 期待値の保護（-IncludeQualityGuard）：承認したテストを後から弱める変更（テストの削除・Skip / Ignore の追加・根拠の削除・検証の削除など）を、 エージェントの編集時（確認付き）・コミット時（拒否）・PR（ベース側の版の検出器で検査）の 3 段で検出し、 トレーラー Expectation-Change: <理由> を求める。
  • あわせて、バグをどこで見つけたか（Found-By:）を記録し、互換のための判断（[Obsolete] の追加など）を「要確認」として一覧に出す。
  • この仕組みは、OpenTouryo 本体と汎用認証サイト（MultiPurposeAuthSite）も同じ原本の写しで使っている（品質の羅針盤）。

実測（検証用リポジトリでの結果）

日付	何をしたか	結果
2026-11-06	ASP.NET Core MVC（net10.0）の受注一覧の検索で、テスト仕様 → Red → 計画 → Green を通した（スキルの作者と別のセッションが実施）	B 層のテスト 30 件。Green で全件合格し、テストは Red から変わらなかった。仕様の漏れを、テストを起こす段で見つけた
2026-11-08	ページ切替（B 層 ＋ 画面の E2E）と、仕様の更新への追随	仕様の更新を、テストの変更（トレーラー付き）→ 実装の順で取り込めた。E2E と B 層のテストのデータの干渉を見つけた
2026-11-09	司令役が実装役・レビュー役を回す形の初回	B 層 51 件・E2E 32 件が合格。人の介入は、GO / NOGO の記入 2 回と決定記録のコミットだけ。トレーラーは、期待を変えた 2 コミットにだけ付いた

• 見本の仕様（NorthwindDbSampleSpec）の本文は 意図的に不完全 にしてあり、 テストを起こすエージェントが仕様の漏れを見つけられるかを試す教材にもなっている。
• 検証は、テンプレート VerifyCodingAgentSkillsForOtTemplate から作ったリポジトリで、利用者も再現できる。

言わないこと（言い過ぎの言い換え）

避ける表現	理由	代わりに言うこと
「規約に完全に適合する」	測っていない	「層と規約ごとの書き方を、スキルとして持つ」
「ハルシネーションを起こしにくい」	測っていない	「開発基盤が解空間を狭める」（マーケティング の主張の核）。数字は上の実測から言う
「レガシー・大規模エンタープライズ向け」	古い枠組みに見える。.NET 10 や SoE・SoI への広がりと合わない	「独自の層構造と規約を持つ開発基盤」
「極めて秀逸」「非常に洗練」	自分で言うと宣伝臭が強い	使わない。事実と実測を並べる
「どのエージェントでも同じに動く」	役の定義（サブ エージェント）と段 1 のフックは Claude Code 向けのみ	「スキルは標準に対応したツールで共通。役の定義は Claude Code 向け」
「テストが通れば品質は保証される」	期待値の保護は、アサーションの緩和を機械的には見ない。トレーラーは記録であって証明ではない	「テストを後から黙って弱めさせない」。緩和はレビュー役・人のレビューの観点で拾う

補足

• 観点 1〜5 の出発点は、README を汎用の AI に評価させた結果である（2026-11-10）。
  観点の立て方は利用者に伝わりやすいので採り、表現は事実に直し、README の新しい版にある観点 6 を足した。
• 実測は検証用のリポジトリでの結果で、実案件での効果はまだ測っていない（Open 棟梁の課題と対応）。

参考

• OpenTouryoProject/OpenTouryoCodingAgentAssets - GitHub
• コーディング・エージェント時代の開発基盤
• GitHub上の成果物

---

Tags: 再構築