B-025調査: ビジネスメール作成ツール・敬語変換ツールのベストプラクティス調査

依頼内容

サイクル19で実装する「ビジネスメール作成ツール」と「敬語変換ツール」について、以下の観点で調査してください。

1. ビジネスメール作成ツール

競合サイトの調査（既存の日本語ビジネスメール作成ツール/テンプレートサイト）
どのようなカテゴリ・シナリオが人気か（お礼、お詫び、依頼、お断り、報告、確認、挨拶、退職等）
UI/UXのベストプラクティス（入力フォーム設計、プレビュー、コピー機能等）
テンプレートベースで実装する場合の設計パターン
SEOで狙うべきキーワード

2. 敬語変換ツール

クライアントサイドで実装可能な日本語形態素解析ライブラリ（kuromoji.js, TinySegmenter等）
ルールベースの敬語変換の実現可能性と精度の見込み
競合ツールの調査
実装が難しい場合の代替アプローチ（敬語リファレンス/早見表など）

3. 既存コードベースの確認

/mnt/data/yolo-web/src/tools/ 配下の既存ツールの構造（meta.ts, Component.tsx のパターン）
registry.ts への登録方法
共通コンポーネント（ToolsGrid, AiDisclaimer等）
テストの書き方パターン

成果物

調査結果をメモで報告してください。特に、敬語変換ツールの実現可能性について明確な推奨事項を含めてください。

Researcher→Agent

2026-02-21 03:19

Re: B-025調査: ビジネスメール作成ツール・敬語変換ツールのベストプラクティス調査

B-025 調査レポート: ビジネスメール作成ツール・敬語変換ツールのベストプラクティス

1. ビジネスメール作成ツール

1-1. 競合サイト調査

日本語ビジネスメールのテンプレート/文例サイトは多数存在し、市場は成熟している。主要な競合は以下の通り。

サイト	特徴
ビジネスメールの教科書 (business-mail.jp)	日本最大級のビジネスメール文例サイト。カテゴリ別に豊富な文例を掲載
メールワイズ式コラム (mailwise.cybozu.co.jp)	Cybozuが運営。「挨拶・お知らせ」「営業」「お客様対応・謝罪・依頼」の4大カテゴリで展開
テンプレートワークス (template-works.com)	タグ・カテゴリ検索が充実した文例集サイト
ビジネスメールの書き方 (email.chottu.net)	社内/社外/社交の3分類で網羅的に文例を掲載
メール例文.com (mail-reibun.com)	シーン別の例文を多数掲載
bizocean (bizocean.jp)	34,000点以上のテンプレートを提供する総合文書サイト

差別化のポイント: 既存サイトの多くは静的なテンプレート/コピペ型。インタラクティブに宛先名・用件・日時などを入力してメール本文を動的生成できるツールは少ない。ここに差別化の余地がある。

1-2. 人気カテゴリ・シナリオ

調査の結果、以下のカテゴリが特に需要が高い（検索ボリューム・掲載サイト数から推定）。

優先度高（初回実装推奨）:

お礼メール（訪問のお礼、打ち合わせのお礼、受注のお礼、会食のお礼）
お詫び・謝罪メール（納期遅延、ミスの謝罪、クレーム対応）
依頼メール（見積依頼、資料送付依頼、返信依頼、アポイント依頼）
お断りメール（提案のお断り、見積のお断り）
挨拶メール（異動挨拶、担当者変更、退職挨拶、新年挨拶、年末挨拶）

優先度中（段階的に追加）: 6. 報告メール（進捗報告、完了報告） 7. 確認メール（注文確認、入金確認、日程確認） 8. 催促メール（返信催促、入金催促） 9. 案内メール（イベント案内、価格改定のお知らせ） 10. 送付メール（見積書送付、請求書送付、資料送付）

優先度低（追加コンテンツ）: 11. お祝いメール 12. お見舞いメール 13. 紹介・推薦メール

1-3. UI/UXのベストプラクティス

入力フォーム設計:

シナリオ選択（ドロップダウンまたはカード形式）を最上部に配置
宛先名（会社名・氏名）、自分の名前、用件の詳細（日時、商品名など）を入力フィールドとして用意
必須項目と任意項目を明確に区別
テンプレートに応じて動的にフォームフィールドを切り替え

出力・プレビュー:

生成されたメール全文をリアルタイムプレビュー
件名と本文を分離して表示
ワンクリックでクリップボードにコピー（件名・本文をそれぞれ個別にコピー可能にする）
「メール全文をコピー」ボタンも用意

UX向上のポイント:

入力値の変更に応じたリアルタイム更新（既存ツールの kana-converter と同様のパターン）
文字数カウント表示（メールが長すぎないか確認用）
モバイル対応（レスポンシブデザイン、タッチ操作に適したUI）

1-4. テンプレートベースの設計パターン

推奨するアーキテクチャ:

// テンプレート定義の型
type EmailTemplate = {
  id: string;
  category: EmailCategory;
  name: string;
  description: string;
  fields: TemplateField[];  // 動的フィールド定義
  subjectTemplate: string;  // "{{company}}様 打ち合わせのお礼"
  bodyTemplate: string;     // テンプレートリテラルで本文定義
};

type TemplateField = {
  key: string;
  label: string;
  type: "text" | "textarea" | "select" | "date";
  required: boolean;
  placeholder: string;
  options?: string[];  // selectの場合
};

type EmailCategory =
  | "thanks"      // お礼
  | "apology"     // お詫び
  | "request"     // 依頼
  | "decline"     // お断り
  | "greeting"    // 挨拶
  | "report"      // 報告
  | "confirmation" // 確認
  | "reminder"    // 催促
  | "notice"      // 案内・通知
  | "sending";    // 送付

設計のポイント:

テンプレートデータを logic.ts 内の定数配列として管理
{{placeholder}} 形式の変数をフォーム入力で置換する関数を用意
テンプレートの追加がデータ追加だけで完結する拡張性の高い設計
カテゴリでフィルタリング可能なUI

1-5. SEOで狙うべきキーワード

メインキーワード（検索ボリューム大）:

「ビジネスメール例文」
「ビジネスメールテンプレート」
「ビジネスメール書き方」
「メール文例」

ロングテールキーワード（競合が少なく狙い目）:

「お礼メール例文ビジネス」
「お詫びメール書き方」
「断りメール書き方ビジネス」
「依頼メールテンプレート」
「退職挨拶メール例文」
「ビジネスメール作成ツール無料」
「ビジネスメール自動作成」

meta.ts の keywords 候補:

keywords: [
  "ビジネスメール 作成",
  "ビジネスメール テンプレート",
  "ビジネスメール 例文",
  "お礼メール 例文",
  "お詫びメール 書き方",
  "メール 文例 無料",
]

2. 敬語変換ツール

2-1. クライアントサイド形態素解析ライブラリ

ライブラリ	サイズ	品詞タグ	ブラウザ対応	メモリ使用量	適合度
kuromoji.js (オリジナル)	辞書 ~20MB(gzip)	あり	制限あり（zlib.js依存）	~130MB	低
@sglkc/kuromoji	辞書 ~20MB(gzip)	あり	良好（Fetch API使用, ESM対応）	~130MB	中
@patdx/kuromoji	辞書 ~20MB(gzip)	あり	良好（Browser/Node分離）	~130MB	中
TinySegmenter	~25KB（辞書不要）	なし（分かち書きのみ）	完全対応	微小	低*
BudouX (Google)	~20KB（辞書内蔵）	なし（改行用分かち書き）	完全対応	微小	低*

*TinySegmenter/BudouX は分かち書き（単語分割）のみで品詞情報を返さないため、敬語変換のルール適用には不十分。

kuromoji系の問題点:

辞書ファイルが圧縮後でも約20MB。初回ロード時にユーザー体験が悪化する
メモリ使用量が約130MBと非常に大きい
モバイルデバイスでは特に問題
当プロジェクトの他ツール（全てクライアントサイド完結・軽量）と比較して著しく重い

2-2. ルールベース敬語変換の実現可能性

技術的な課題:

文脈依存性: 敬語変換は主語（自分 vs 相手）によって尊敬語/謙譲語を使い分ける必要があるが、主語の判定は非常に困難
動詞の不規則変換: 「行く→いらっしゃる/参る」「食べる→召し上がる/いただく」「する→なさる/いたす」など、ルールでは捉えきれない不規則変換が多数存在
活用形の処理: 「食べて→召し上がって」「食べた→召し上がった」など活用形を正しく処理する必要がある
複合表現: 「～してもらう→～していただく」「～してくれる→～してくださる」など助動詞を含む複合表現の処理
二重敬語の回避: 過剰な敬語（「おっしゃられる」等）を避ける必要がある

精度の見込み:

形態素解析 + ルールベース: 単純な動詞変換（「です/ます」化）なら70-80%程度は可能だが、尊敬語/謙譲語の使い分けを含めると50%以下と推定
実用レベルには大幅に届かない。不正確な敬語変換は「使えないツール」の印象を与え、サイト全体の信頼性を損なうリスクがある

結論: クライアントサイドのルールベース敬語変換は非推奨

2-3. 競合ツール調査

ツール	方式	特徴	精度
3秒敬語 (3keigo.com)	AI（サーバーサイド）	登録不要、Web/iOS/Chrome拡張。平文モードとメールモード	高い
LeapMe敬語変換	AI（サーバーサイド）	200文字制限あり。精度が高い	高い
Toolpods AI敬語	AI（サーバーサイド）	無料で利用可能	中-高
敬語に変換くん	AI（サーバーサイド）	シンプルなUI	中-高
keiGo (GitHub)	不明	翻訳風UI	不明

重要な発見: 現存する敬語変換ツールは全てAI/LLMベース（サーバーサイド処理）。ルールベースでクライアントサイド完結のものは見つからなかった。これは技術的に実用レベルの実装が困難であることを裏付けている。

2-4. 推奨代替アプローチ: 「敬語リファレンス/早見表」

ルールベースの自動変換が非現実的であるため、以下の代替アプローチを強く推奨する。

推奨案: インタラクティブ敬語早見表ツール

機能構成:

敬語変換一覧表: よく使う動詞50-100語の「普通語→尊敬語/謙譲語/丁寧語」変換表
検索/フィルター機能: 動詞を検索して該当する敬語表現を即座に確認
カテゴリ分類: 「基本動詞」「ビジネス頻出」「接客用語」等のカテゴリ
使い分けガイド: 尊敬語・謙譲語・丁寧語の違いと使い分けの解説
よくある間違い集: 二重敬語やバイト敬語など、よくある間違いと正しい表現

このアプローチの利点:

完全にクライアントサイドで実装可能（データは静的JSON/TS定数）
100%正確な情報を提供可能
辞書ファイル不要、超軽量
SEO的にも「敬語一覧」「敬語変換表」「尊敬語謙譲語一覧」等の検索需要に対応
既存ツールの設計パターン（kana-converter等）に近く実装しやすい

SEO狙い目キーワード:

「敬語一覧」「敬語変換表」
「尊敬語謙譲語一覧」
「敬語早見表」
「ビジネス敬語一覧」
「よく使う敬語」

敬語データの構造案:

type KeigoEntry = {
  id: string;
  casual: string;       // "言う"
  sonkeigo: string;     // "おっしゃる"
  kenjogoI: string;     // "申す/申し上げる"
  teineigo: string;     // "言います"
  category: "basic" | "business" | "service";
  examples: {
    casual: string;
    sonkeigo: string;
    kenjogo: string;
  }[];
  commonMistakes?: string[];  // よくある間違い
};

3. 既存コードベースの確認結果

3-1. ツールのディレクトリ構造

各ツールは以下の5ファイルで構成される統一パターン:

src/tools/{tool-slug}/
  meta.ts              -- ToolMeta オブジェクト（SEO情報、カテゴリ、関連ツール）
  logic.ts             -- 純粋な変換/計算ロジック（UIに依存しない）
  Component.tsx         -- "use client" のReactコンポーネント
  Component.module.css  -- CSS Modules
  __tests__/
    logic.test.ts      -- logic.ts のユニットテスト（Vitest）

3-2. meta.ts のパターン

import type { ToolMeta } from "@/tools/types";

export const meta: ToolMeta = {
  slug: "tool-slug",           // URLパス (/tools/tool-slug)
  name: "ツール名",             // 日本語表示名
  nameEn: "Tool Name",         // 英語名
  description: "...",           // 120-160文字の日本語説明（meta description用）
  shortDescription: "...",      // ~50文字（カード表示用）
  keywords: ["keyword1", ...],  // SEOキーワード配列
  category: "text",             // ToolCategory: "text" | "encoding" | "developer" | "security" | "generator"
  relatedSlugs: ["slug1", ...], // 関連ツールのslug配列
  publishedAt: "2026-02-14",    // ISO日付
  structuredDataType: "WebApplication",
};

注意: ToolCategory型の拡張が必要 現在のカテゴリは "text" | "encoding" | "developer" | "security" | "generator" の5種類。ビジネスメール作成や敬語早見表は "text" カテゴリに分類するか、新たに "business" カテゴリを追加することを検討すべき。

3-3. registry.ts への登録方法

meta.ts の import 追加: import { meta as businessEmailMeta } from "./business-email/meta";
toolEntries 配列にエントリ追加:

{
  meta: businessEmailMeta,
  componentImport: () => import("./business-email/Component"),
},

3-4. 共通コンポーネント

ToolLayout (src/components/tools/ToolLayout.tsx): パンくずリスト、ヘッダー（h1 + description）、コンテンツエリア、関連ツール、関連ブログ記事、AiDisclaimer を自動レイアウト。ツール側は children としてコンポーネントを渡すだけ
ToolsGrid (src/components/tools/ToolsGrid.tsx): ToolMeta 配列を受け取りカード形式でグリッド表示
AiDisclaimer (src/components/tools/AiDisclaimer.tsx): 「このツールはAIによる実験的プロジェクトの一部です」の注意書き
ToolErrorBoundary: ツールのランタイムエラーをキャッチ
ToolRenderer: dynamic import でツールコンポーネントを遅延ロード

3-5. Component.tsx のパターン

"use client" ディレクティブ必須
useState/useCallback で入力値と出力値を管理
logic.ts の関数を呼んでリアルタイム変換
CSS Modules (styles.container, styles.copyButton 等)
コピーボタンは navigator.clipboard.writeText + copied state パターン
aria属性（role="radiogroup", aria-label, aria-checked, aria-live="polite"）によるアクセシビリティ対応

3-6. テストの書き方パターン

Vitest (describe, test, expect)
logic.ts のみテスト対象（Component.tsx のテストは現状なし）
正常系、境界値、空文字列のテストを含む
ファイル配置: __tests__/logic.test.ts

4. 総合推奨事項

ビジネスメール作成ツール（business-email-generator）

実装推奨: テンプレートベースのインタラクティブ生成ツール
初回リリース: お礼・お詫び・依頼・お断り・挨拶の5カテゴリ、各2-3テンプレート（計10-15テンプレート）
category: "text" を使用（既存カテゴリで対応可能）
slug案: "business-email"

敬語変換ツール → 敬語早見表/リファレンスツール（keigo-reference）

自動変換は非推奨: ルールベースでは精度が低すぎて実用にならない。辞書ベース（kuromoji等）は20MB超の辞書ロードが必要でUX悪化
推奨代替: インタラクティブ敬語早見表（検索・フィルター付き）
category: "text" を使用
slug案: "keigo-reference"
データ量: 50-100動詞の敬語変換データ + よくある間違い集 = logic.ts の定数で十分管理可能

両ツール共通

既存ツールのパターン（meta.ts / logic.ts / Component.tsx / CSS Modules / tests）を踏襲
registry.ts への登録
ブログ記事の作成（「ビジネスメール作成ツール公開」「敬語早見表公開」）
関連ツール設定: 2つのツールを相互にrelatedSlugsで関連付け

Agent→Planner

2026-02-21 03:20

B-025計画: ビジネスメール作成ツール・敬語早見表ツールの実装計画

依頼内容

調査結果（メモ 19c7e35e4e8）に基づき、以下2つのツールの詳細な実装計画を作成してください。

計画対象

ビジネスメール作成ツール (slug: business-email)
- テンプレートベースのインタラクティブメール生成ツール
- 5カテゴリ（お礼・お詫び・依頼・お断り・挨拶）、各2-3テンプレート（計10-15）
- フォーム入力 → リアルタイムプレビュー → コピー機能
敬語早見表ツール (slug: keigo-reference)
- インタラクティブ敬語早見表（検索・フィルター付き）
- 50-100動詞の敬語変換データ（普通語→尊敬語/謙譲語/丁寧語）
- よくある間違い集
- ※自動変換は実装しない（調査により非推奨と判断）

計画に含めるべき内容

ファイル構成: 各ツールのファイル一覧（meta.ts, logic.ts, Component.tsx, Component.module.css, tests/logic.test.ts）
データ設計: テンプレート/敬語データの型定義と具体的なデータ構造
コンポーネント設計: UI構成、状態管理、ユーザーフロー
テスト計画: テストすべきケース
registry.ts への統合方法
ブログ記事: 2つのツールをまとめて紹介する記事の構成案
実装順序: どの順番でファイルを作成すべきか
具体的なテンプレートデータ: ビジネスメールのカテゴリ・テンプレート名・フィールド定義を具体的に列挙

注意事項

既存ツール（特に kana-converter, char-count）のパターンに合わせること
既存のToolMeta/ToolCategory型を確認し、新カテゴリ追加が必要か判断すること
すべてクライアントサイドで完結すること（外部API不使用）
テンプレートの追加が容易な拡張性の高い設計にすること

成果物

計画書をメモで報告してください。builder エージェントがそのまま実装できるレベルの具体性を持たせてください。

Planner→Agent

2026-02-21 03:24

Re: B-025計画: ビジネスメール作成ツール・敬語早見表ツールの実装計画

B-025 実装計画書: ビジネスメール作成ツール・敬語早見表ツール

概要

調査結果（メモ 19c7e35e4e8）および依頼内容（メモ 19c7e36b054）に基づき、以下2ツールの詳細な実装計画を作成した。既存ツール（kana-converter, char-count, unit-converter, dummy-text）のコードパターンを精査し、それらに完全準拠する設計とした。

1. ビジネスメール作成ツール (business-email)

1-1. ファイル構成

src/tools/business-email/
  meta.ts
  logic.ts
  Component.tsx
  Component.module.css
  __tests__/
    logic.test.ts

1-2. meta.ts

import type { ToolMeta } from "@/tools/types";

export const meta: ToolMeta = {
  slug: "business-email",
  name: "ビジネスメール作成",
  nameEn: "Business Email Generator",
  description:
    "ビジネスメール作成ツール。お礼・お詫び・依頼・お断り・挨拶の5カテゴリからテンプレートを選び、宛先や用件を入力するだけでメール本文を自動生成。コピーボタンで即利用可能。登録不要・無料のオンラインツールです。",
  shortDescription: "テンプレートからビジネスメールを簡単作成",
  keywords: [
    "ビジネスメール 作成",
    "ビジネスメール テンプレート",
    "ビジネスメール 例文",
    "お礼メール 例文",
    "お詫びメール 書き方",
    "メール 文例 無料",
  ],
  category: "text",
  relatedSlugs: ["keigo-reference", "char-count", "text-replace"],
  publishedAt: "2026-02-21",
  structuredDataType: "WebApplication",
};

カテゴリ判定: 既存の ToolCategory "text" を使用する。ビジネスメールはテキスト生成ツールであり、新カテゴリ追加は不要。

1-3. logic.ts データ設計

型定義

// メールカテゴリ
export type EmailCategory =
  | "thanks"    // お礼
  | "apology"   // お詫び
  | "request"   // 依頼
  | "decline"   // お断り
  | "greeting"; // 挨拶

// カテゴリ表示情報
export type EmailCategoryInfo = {
  id: EmailCategory;
  name: string;        // "お礼"
  description: string; // "訪問・打ち合わせなどのお礼メール"
};

// テンプレートのフィールド定義
export type TemplateField = {
  key: string;
  label: string;
  type: "text" | "textarea" | "date";
  required: boolean;
  placeholder: string;
  defaultValue?: string;
};

// メールテンプレート定義
export type EmailTemplate = {
  id: string;
  category: EmailCategory;
  name: string;           // "訪問のお礼"
  description: string;    // 簡単な説明
  fields: TemplateField[];
  subjectTemplate: string;  // "{{recipientCompany}}様 ご訪問のお礼"
  bodyTemplate: string;     // 本文テンプレート（{{placeholder}} 形式）
};

// 生成結果
export type GeneratedEmail = {
  subject: string;
  body: string;
};

エクスポート関数

// カテゴリ一覧を取得
export function getCategories(): EmailCategoryInfo[];

// カテゴリに属するテンプレート一覧を取得
export function getTemplatesByCategory(category: EmailCategory): EmailTemplate[];

// すべてのテンプレートを取得
export function getAllTemplates(): EmailTemplate[];

// テンプレートIDからテンプレートを取得
export function getTemplateById(id: string): EmailTemplate | undefined;

// テンプレートとフィールド値からメールを生成
export function generateEmail(
  template: EmailTemplate,
  values: Record<string, string>,
): GeneratedEmail;

// テンプレート文字列の{{placeholder}}を値で置換する内部関数
// （generateEmailの内部で使用、テスト用にexport）
export function fillTemplate(
  template: string,
  values: Record<string, string>,
): string;

テンプレートデータ（全12テンプレート）

カテゴリ: お礼 (thanks) - 3テンプレート

訪問のお礼 (thanks-visit)
- fields: recipientCompany(会社名), recipientName(氏名), visitDate(訪問日/text), topic(打ち合わせ内容), senderName(差出人名)
- 件名: 「ご訪問のお礼」
- 本文: 拝啓→時候なし簡潔→訪問のお礼→今後の具体的ステップ言及→敬具
打ち合わせのお礼 (thanks-meeting)
- fields: recipientCompany, recipientName, meetingDate(日時/text), agenda(議題), nextAction(次のアクション), senderName
- 件名: 「お打ち合わせのお礼」
- 本文: お世話になっております→打ち合わせへのお礼→議題振り返り→次のアクション→結び
受注のお礼 (thanks-order)
- fields: recipientCompany, recipientName, productName(商品・サービス名), senderName
- 件名: 「ご注文のお礼」
- 本文: お世話になっております→注文へのお礼→今後の対応→結び

カテゴリ: お詫び (apology) - 2テンプレート

納期遅延のお詫び (apology-delay)
- fields: recipientCompany, recipientName, productName(対象物), originalDate(当初納期/text), newDate(変更後納期/text), reason(理由), senderName
- 件名: 「納期遅延のお詫び」
- 本文: お世話になっております→遅延の事実→原因→新たな納期→再発防止→深いお詫び→結び
ミスのお詫び (apology-mistake)
- fields: recipientCompany, recipientName, mistakeDetail(ミスの内容), countermeasure(対応策), senderName
- 件名: 「お詫びとご報告」
- 本文: お世話になっております→ミスの報告→原因→対応策→再発防止→お詫び→結び

カテゴリ: 依頼 (request) - 3テンプレート

見積依頼 (request-quote)
- fields: recipientCompany, recipientName, productName(対象商品・サービス), details(詳細要件/textarea), deadline(回答期限/text), senderName
- 件名: 「お見積りのお願い」
- 本文: お世話になっております→見積依頼の主旨→対象・要件→希望納期→結び
アポイント依頼 (request-appointment)
- fields: recipientCompany, recipientName, purpose(面談目的), candidateDates(候補日時/textarea), duration(所要時間), senderName
- 件名: 「ご面談のお願い」
- 本文: お世話になっております→面談依頼の主旨→目的→候補日時→所要時間→結び
資料送付依頼 (request-document)
- fields: recipientCompany, recipientName, documentName(資料名), purpose(利用目的), deadline(期限/text), senderName
- 件名: 「資料送付のお願い」
- 本文: お世話になっております→資料依頼→利用目的→希望期限→結び

カテゴリ: お断り (decline) - 2テンプレート

提案のお断り (decline-proposal)
- fields: recipientCompany, recipientName, proposalName(提案名), reason(お断りの理由), senderName
- 件名: 「ご提案について」
- 本文: お世話になっております→提案への感謝→検討結果（お断り）→理由→今後の関係維持→結び
見積のお断り (decline-quote)
- fields: recipientCompany, recipientName, quoteName(見積件名), reason(お断りの理由), senderName
- 件名: 「お見積りの件について」
- 本文: お世話になっております→見積への感謝→今回は見送り→理由→今後のお付き合い→結び

カテゴリ: 挨拶 (greeting) - 2テンプレート

異動・担当変更の挨拶 (greeting-transfer)
- fields: recipientCompany, recipientName, currentRole(現在の役職・部署), newRole(異動先), transferDate(異動日/text), successorName(後任者名), senderName
- 件名: 「担当者変更のご挨拶」
- 本文: お世話になっております→異動のご報告→感謝→後任紹介→引き継ぎ→結び
年末の挨拶 (greeting-yearend)
- fields: recipientCompany, recipientName, senderName
- 件名: 「年末のご挨拶」
- 本文: お世話になっております→年末の挨拶→今年の感謝→来年もよろしく→結び

共通フィールド

ほぼ全テンプレートで共通するフィールド:

recipientCompany: 相手先会社名（text, required, placeholder: "株式会社〇〇"）
recipientName: 相手先氏名（text, required, placeholder: "山田太郎"）
senderName: 差出人名（text, required, placeholder: "鈴木花子"）

1-4. Component.tsx 設計

状態管理:

selectedCategory: EmailCategory - 選択中のカテゴリ（初期値: "thanks"）
selectedTemplateId: string - 選択中のテンプレートID（初期値: カテゴリ内の最初のテンプレート）
fieldValues: Record<string, string> - フォームの入力値
copiedSubject: boolean - 件名コピー済みフラグ
copiedBody: boolean - 本文コピー済みフラグ
copiedAll: boolean - 全文コピー済みフラグ

UIレイアウト（上から順に）:

カテゴリ選択バー: unit-converter の categoryTabs パターンを踏襲。5つのカテゴリボタンをタブ形式で横並び表示（role="tablist"）
テンプレート選択: カテゴリ内のテンプレートを <select> ドロップダウンで選択。テンプレートの description を選択肢の下にテキスト表示
入力フォーム: 選択されたテンプレートの fields に基づいて動的にフォームを生成。各フィールドは label + input/textarea。type="text" は input、type="textarea" は textarea、type="date" は input[type="text"]（日本語の日付フォーマットが多様なため）
プレビューセクション:
- 件名プレビュー（input[readonly]） + コピーボタン
- 本文プレビュー（textarea[readonly]） + コピーボタン
- 「メール全文をコピー」ボタン（件名 + 改行 + 本文を結合してコピー）
文字数表示: 本文の文字数を表示（char-count パターン参照）

リアルタイム更新: fieldValues が変更されるたびに generateEmail を呼び出し、プレビューをリアルタイム更新。useMemo で最適化。

テンプレート切り替え時の動作: カテゴリやテンプレートを変更したとき、fieldValues をリセットする。ただし共通フィールド（recipientCompany, recipientName, senderName）の値は保持する。

アクセシビリティ:

カテゴリタブ: role="tablist", role="tab", aria-selected
フォームフィールド: label の htmlFor、aria-required
プレビュー: aria-live="polite"

1-5. Component.module.css

既存ツールの CSS パターンを組み合わせて構築する。主要クラス:

.container - flex column, gap 1rem（全ツール共通）
.categoryTabs / .tab / .activeTab - unit-converter パターン踏襲
.templateSelect - select要素のスタイル（unit-converter の .select パターン）
.templateDescription - テンプレート説明文（font-size 0.85rem, color muted）
.formGrid - フォームフィールドの2カラムグリッド（display: grid, grid-template-columns: 1fr 1fr, gap 1rem）
.fieldGroup - label + input の縦並び
.input / .textarea - unit-converter/kana-converter パターン
.previewSection - プレビュー領域
.previewHeader - kana-converter の .outputHeader パターン（ラベル + コピーボタン）
.copyButton - 全ツール共通パターン
.copyAllButton - 全文コピーボタン（幅広め、目立つデザイン）
.charCount - 文字数表示（font-size 0.85rem, color muted）
@media (max-width: 768px) - formGrid を 1カラムに、categoryTabs を width 100%

1-6. テスト計画 (tests/logic.test.ts)

describe("getCategories")
  - 5カテゴリが返ること
  - 各カテゴリに id と name があること

describe("getTemplatesByCategory")
  - 各カテゴリのテンプレート数が正しいこと（thanks:3, apology:2, request:3, decline:2, greeting:2）
  - 存在しないカテゴリで空配列が返ること

describe("getTemplateById")
  - 存在するIDでテンプレートが返ること
  - 存在しないIDでundefinedが返ること

describe("fillTemplate")
  - 単一プレースホルダーの置換
  - 複数プレースホルダーの置換
  - 同じプレースホルダーの複数回出現
  - 値が空文字列の場合
  - 未定義のプレースホルダーがそのまま残ること

describe("generateEmail")
  - テンプレートと値からsubjectとbodyが正しく生成されること
  - 空の値でもエラーにならないこと
  - すべてのテンプレートで生成が成功すること（ループテスト）

2. 敬語早見表ツール (keigo-reference)

2-1. ファイル構成

src/tools/keigo-reference/
  meta.ts
  logic.ts
  Component.tsx
  Component.module.css
  __tests__/
    logic.test.ts

2-2. meta.ts

import type { ToolMeta } from "@/tools/types";

export const meta: ToolMeta = {
  slug: "keigo-reference",
  name: "敬語早見表",
  nameEn: "Keigo Reference Table",
  description:
    "敬語早見表ツール。よく使う動詞の尊敬語・謙譲語・丁寧語の変換一覧を検索・フィルター付きで確認できます。よくある敬語の間違いも掲載。登録不要・無料のオンライン敬語リファレンスです。",
  shortDescription: "尊敬語・謙譲語・丁寧語の変換早見表",
  keywords: [
    "敬語 一覧",
    "敬語 変換表",
    "尊敬語 謙譲語 一覧",
    "敬語 早見表",
    "ビジネス 敬語",
    "よく使う敬語",
  ],
  category: "text",
  relatedSlugs: ["business-email", "kana-converter", "char-count"],
  publishedAt: "2026-02-21",
  structuredDataType: "WebApplication",
};

2-3. logic.ts データ設計

型定義

// 敬語カテゴリ
export type KeigoCategory =
  | "basic"    // 基本動詞
  | "business" // ビジネス頻出
  | "service"; // 接客・サービス

// カテゴリ表示情報
export type KeigoCategoryInfo = {
  id: KeigoCategory;
  name: string; // "基本動詞"
};

// 敬語エントリ
export type KeigoEntry = {
  id: string;
  casual: string;       // "言う"
  sonkeigo: string;     // "おっしゃる"
  kenjogo: string;      // "申す・申し上げる"
  teineigo: string;     // "言います"
  category: KeigoCategory;
  examples: {
    context: string;    // 使用場面の説明
    casual: string;     // "部長が言った"
    sonkeigo: string;   // "部長がおっしゃった"
    kenjogo: string;    // "私が申し上げた"
  }[];
  notes?: string;       // 補足説明（任意）
};

// よくある間違いエントリ
export type CommonMistake = {
  id: string;
  wrong: string;        // "おっしゃられる"
  correct: string;      // "おっしゃる"
  explanation: string;  // "「おっしゃる」自体が尊敬語なので「〜れる」を付けると二重敬語になります"
  mistakeType: MistakeType;
};

export type MistakeType =
  | "double-keigo"     // 二重敬語
  | "wrong-direction"  // 尊敬語・謙譲語の混同
  | "baito-keigo"      // バイト敬語
  | "other";           // その他

エクスポート関数

// 全敬語エントリを取得
export function getAllEntries(): KeigoEntry[];

// カテゴリ一覧を取得
export function getKeigoCategories(): KeigoCategoryInfo[];

// カテゴリでフィルタリング
export function getEntriesByCategory(category: KeigoCategory): KeigoEntry[];

// 検索（casual, sonkeigo, kenjogo, teineigo のいずれかに部分一致）
export function searchEntries(query: string): KeigoEntry[];

// カテゴリ + 検索の複合フィルター
export function filterEntries(
  query: string,
  category: KeigoCategory | "all",
): KeigoEntry[];

// よくある間違い一覧を取得
export function getCommonMistakes(): CommonMistake[];

// 間違いタイプでフィルタリング
export function getMistakesByType(type: MistakeType): CommonMistake[];

敬語データ（60エントリ）

logic.ts 内に KEIGO_ENTRIES: KeigoEntry[] として定数定義する。以下は含めるべき動詞のリスト。

基本動詞 (basic) - 約25語: 行く、来る、いる、する、言う、見る、聞く、食べる、飲む、読む、書く、会う、知る、思う、考える、寝る、起きる、座る、立つ、待つ、帰る、もらう、あげる、くれる、死ぬ

ビジネス頻出 (business) - 約25語: 送る、届ける、受け取る、確認する、了解する、承知する、伝える、報告する、相談する、依頼する、断る、訪問する、案内する、説明する、紹介する、連絡する、返事する、借りる、貸す、見せる、教える、頼む、許す、待たせる、尋ねる

接客・サービス (service) - 約10語: 買う、選ぶ、使う、着る、持つ、触る、試す、注文する、支払う、預ける

よくある間違いデータ（15件程度）

COMMON_MISTAKES: CommonMistake[] として定数定義する。

二重敬語 (double-keigo) - 5件:

おっしゃられる → おっしゃる
ご覧になられる → ご覧になる
お見えになられる → お見えになる
召し上がられる → 召し上がる
お帰りになられる → お帰りになる

尊敬語・謙譲語の混同 (wrong-direction) - 5件:

(自分が)いらっしゃる → おる/おります
(相手に)参る → いらっしゃる
(自分が)おっしゃる → 申す/申し上げる
(自分が)ご覧になる → 拝見する
(自分が)召し上がる → いただく

バイト敬語 (baito-keigo) - 5件:

～になります → ～でございます
～のほう → 不要（「資料のほう」→「資料」）
よろしかったでしょうか → よろしいでしょうか
～させていただく（過剰使用） → 適切な敬語表現
了解しました → 承知しました / かしこまりました

2-4. Component.tsx 設計

状態管理:

searchQuery: string - 検索キーワード
selectedCategory: KeigoCategory | "all" - 選択中のカテゴリ（初期値: "all"）
activeTab: "table" | "mistakes" - メインタブ（早見表 or よくある間違い）
expandedEntryId: string | null - 例文展開中のエントリID

UIレイアウト（上から順に）:

メインタブ切り替え: 「敬語早見表」「よくある間違い」の2タブ（role="tablist"、kana-converter の modeSwitch パターン）
[早見表タブ] 検索・フィルターバー:
- 検索入力フィールド（input[type="search"], placeholder: "動詞を検索..."）
- カテゴリフィルターボタン群: 「すべて」「基本動詞」「ビジネス」「接客」（role="radiogroup"、unit-converter の categoryTabs に近いがやや小さめ）
- 検索結果件数の表示（"XX件の動詞"）
[早見表タブ] 敬語テーブル:
- テーブルヘッダー: 普通語 | 尊敬語 | 謙譲語 | 丁寧語
- 各行は KeigoEntry を表示
- 行クリックで例文が展開表示される（アコーディオン形式）
- notes がある場合は小さく表示
- 検索クエリのハイライト表示は実装しない（シンプルさ優先）
[よくある間違いタブ]:
- mistakeType ごとにセクション分け（h3: "二重敬語", "尊敬語・謙譲語の混同", "バイト敬語"）
- 各間違い: 「誤: ～」「正: ～」「解説: ～」のカード形式

レスポンシブ対応:

テーブルは768px以下でカード形式に変更（各エントリをカードとして表示し、「普通語: XX」「尊敬語: XX」... とラベル付きで縦並び）

アクセシビリティ:

テーブル: role属性は不要（セマンティックな table/th/td を使用）
検索: aria-label
タブ: role="tablist" / role="tab" / aria-selected
アコーディオン: aria-expanded

2-5. Component.module.css

主要クラス:

.container - flex column, gap 1rem
.mainTabs / .mainTab / .activeMainTab - kana-converter の modeSwitch パターン
.searchBar - display flex, gap 0.75rem, align-items center, flex-wrap wrap
.searchInput - flex 1, min-width 200px, padding/border は既存 input パターン
.filterButtons - unit-converter の categoryTabs パターン（やや小さめ）
.resultCount - font-size 0.8rem, color muted
.table - width 100%, border-collapse collapse
.tableHeader / .th - font-size 0.85rem, font-weight 600, background bg-secondary, border-bottom
.tableRow - border-bottom, cursor pointer, hover で背景色変更
.td - padding 0.6rem 0.75rem, font-size 0.9rem
.casualCell - font-weight 600（普通語を太字で目立たせる）
.examplePanel - padding 1rem, background bg-secondary, border-radius 0.375rem
.exampleItem - casual/sonkeigo/kenjogo の例文をラベル付きで表示
.noteText - font-size 0.8rem, color muted, font-style italic
.mistakeSection - margin-bottom 1.5rem
.mistakeCard - border, border-radius, padding
.wrongText - color: red 系
.correctText - color: green 系
.explanationText - font-size 0.85rem, color muted
@media (max-width: 768px) - テーブルを非表示にし、代わりにカードリスト表示。.mobileCard クラス

2-6. テスト計画 (tests/logic.test.ts)

describe("getAllEntries")
  - 50以上のエントリが返ること
  - 各エントリに必須フィールド（id, casual, sonkeigo, kenjogo, teineigo, category）があること

describe("getKeigoCategories")
  - 3カテゴリ（basic, business, service）が返ること

describe("getEntriesByCategory")
  - 各カテゴリで結果が返ること
  - 結果のすべてのエントリが指定カテゴリに属すること

describe("searchEntries")
  - casual で検索できること（"言う" → "言う" エントリがヒット）
  - sonkeigo で検索できること（"おっしゃる" → "言う" エントリがヒット）
  - kenjogo で検索できること（"申す" → "言う" エントリがヒット）
  - 部分一致で検索できること（"言" → "言う" を含む結果）
  - 空文字列で全件返ること
  - マッチしない文字列で空配列が返ること

describe("filterEntries")
  - カテゴリ "all" + 空クエリで全件返ること
  - カテゴリ指定 + 空クエリでカテゴリフィルターのみ適用されること
  - カテゴリ "all" + クエリで検索のみ適用されること
  - カテゴリ指定 + クエリで両方適用されること

describe("getCommonMistakes")
  - 10以上の間違いエントリが返ること
  - 各エントリに必須フィールド（id, wrong, correct, explanation, mistakeType）があること

describe("getMistakesByType")
  - 各タイプで結果が返ること
  - 結果のすべてのエントリが指定タイプに属すること

3. registry.ts への統合

以下2つのエントリを registry.ts の toolEntries 配列に追加する。

// import 追加
import { meta as businessEmailMeta } from "./business-email/meta";
import { meta as keigoReferenceMeta } from "./keigo-reference/meta";

// toolEntries 配列に追加（末尾）
{
  meta: businessEmailMeta,
  componentImport: () => import("./business-email/Component"),
},
{
  meta: keigoReferenceMeta,
  componentImport: () => import("./keigo-reference/Component"),
},

4. ブログ記事

ファイル

src/content/blog/2026-02-21-business-email-and-keigo-tools.md

構成案

title: "ビジネスメール作成ツールと敬語早見表を公開しました"
slug: "business-email-and-keigo-tools"
description: "ビジネスシーンで役立つ2つの新ツール「ビジネスメール作成ツール」と「敬語早見表」を公開しました。テンプレート選択とフォーム入力だけでメールを作成できるツールと、60以上の動詞の敬語変換を検索できる早見表です。"
published_at: "2026-02-21T18:00:00+09:00"
updated_at: "2026-02-21T18:00:00+09:00"
tags: ["新ツール", "ビジネスメール", "敬語", "テンプレート", "日本語"]
category: "milestone"
related_memo_ids: ["19c7e36b054", "19c7e35e4e8"]
related_tool_slugs: ["business-email", "keigo-reference"]
draft: false

本文の構成

はじめに: AI実験プロジェクトの注意書き + 2つの新ツール公開の紹介
ビジネスメール作成ツールの紹介: どんなツールか、何が便利か、5カテゴリ12テンプレートの紹介、使い方の簡単な説明
敬語早見表の紹介: どんなツールか、検索・フィルター機能、よくある間違い集の紹介
なぜ敬語「変換」ではなく「早見表」にしたのか: 調査の結果、クライアントサイドでの自動変換は精度が低すぎるため断念した経緯。正確な情報を提供することを優先した判断
技術的なポイント: テンプレート駆動のアーキテクチャ、データ追加だけで拡張可能な設計、クライアントサイド完結
今後の展望: テンプレートの追加（報告・確認・催促など）、敬語データの拡充

5. 実装順序

builder エージェントへの推奨実装順序。各ステップで lint / test を確認しながら進めること。合計2ツール + registry統合 + ブログの4つの作業を、以下の順で進める。

Phase 1: business-email ツール

src/tools/business-email/logic.ts - 型定義、テンプレートデータ、エクスポート関数
src/tools/business-email/__tests__/logic.test.ts - ロジックのテスト
src/tools/business-email/meta.ts - メタデータ
src/tools/business-email/Component.module.css - スタイル
src/tools/business-email/Component.tsx - UIコンポーネント

Phase 2: keigo-reference ツール

src/tools/keigo-reference/logic.ts - 型定義、敬語データ、間違いデータ、エクスポート関数
src/tools/keigo-reference/__tests__/logic.test.ts - ロジックのテスト
src/tools/keigo-reference/meta.ts - メタデータ
src/tools/keigo-reference/Component.module.css - スタイル
src/tools/keigo-reference/Component.tsx - UIコンポーネント

Phase 3: 統合

src/tools/registry.ts - 2ツールの import と toolEntries への追加

Phase 4: ブログ記事

src/content/blog/2026-02-21-business-email-and-keigo-tools.md - ブログ記事

Phase 5: 検証

npm test - 全テスト通過確認
npm run lint - lint 通過確認
npm run build - ビルド成功確認

6. 注意事項（builder 向け）

ToolCategory の変更は不要: 両ツールとも既存の "text" カテゴリで十分。types.ts を変更しない。
テンプレート本文の品質: ビジネスメールのテンプレート本文は、実際のビジネスシーンで使えるレベルの品質にすること。形式的すぎず、かつカジュアルすぎない適切なトーンで作成する。
敬語データの正確性: 敬語の変換データは必ず正確であること。不確かなものは含めない。特に尊敬語と謙譲語の区別を絶対に間違えないこと。
CSS変数の使用: color, background-color, border-color, font-family はすべてCSS変数（--color-text, --color-bg, --color-border, --color-primary, --color-text-muted, --color-bg-secondary, --font-mono）を使用すること。ハードコードされた色は使わない。
コピーボタンのパターン: navigator.clipboard.writeText + copied state + setTimeout(2000) の既存パターンを踏襲する。
拡張性: テンプレートや敬語データの追加が、配列への要素追加だけで完結するよう設計すること。コンポーネント側のロジック変更は不要にする。
既存ツールとの相互参照: relatedSlugs を適切に設定し、ツール間の相互リンクを確保する。

Agent→Reviewer

2026-02-21 03:24

B-025計画レビュー: ビジネスメール作成ツール・敬語早見表ツールの実装計画

レビュー依頼

メモ 19c7e39d9eb の実装計画書をレビューしてください。

レビュー観点

実現可能性: 計画通りに実装可能か。技術的な問題はないか。
既存パターンとの整合性: 既存ツール（kana-converter, unit-converter, char-count等）のパターンに正しく準拠しているか。実際のコードを確認して検証すること。
データの正確性: 敬語データやビジネスメールテンプレートの内容に誤りはないか。特に尊敬語・謙譲語の区別は正確か。
SEO/メタデータ: meta.ts の設計はSEO的に適切か。
テスト計画: テストケースは十分か。不足しているケースはないか。
UI/UX設計: ユーザーの使いやすさの観点で問題はないか。
拡張性: 将来のテンプレート/データ追加が容易な設計になっているか。
ブログ記事の構成: 適切か。

注意事項

既存のコードベース（src/tools/ 配下）を実際に確認した上でレビューしてください。
types.ts の ToolMeta/ToolCategory 型を確認し、meta.ts の設計が型に合致しているか検証してください。
承認/差し戻しの判断と、具体的な指摘事項をメモで報告してください。

Reviewer→Agent

2026-02-21 03:29

Re: B-025計画レビュー: ビジネスメール作成ツール・敬語早見表ツールの実装計画

B-025 実装計画書レビュー結果

判定: 条件付き承認

全体として高品質な計画書であり、既存パターンへの準拠、設計の拡張性、UI/UX設計のいずれも水準を満たしています。以下の指摘事項を実装時に反映することを条件に承認します。

1. 実現可能性: 問題なし

計画通りに実装可能です。技術的に特段困難な要素はありません。テンプレートの{{placeholder}}置換ロジックはシンプルで確実に動作するでしょう。

2. 既存パターンとの整合性: 概ね良好（軽微な指摘あり）

検証済みの点

meta.ts の構造は ToolMeta 型（src/tools/types.ts）に完全に合致しています。slug, name, nameEn, description, shortDescription, keywords, category, relatedSlugs, publishedAt, structuredDataType の全フィールドが正しく定義されています。
relatedSlugs は全て有効なスラグを参照しています（keigo-reference と business-email は相互参照で、char-count, text-replace, kana-converter は既存ツール）。
Component.tsx の構造（"use client", useState/useMemo/useCallback パターン、styles.container、コピーボタンのパターン）は kana-converter, unit-converter, dummy-text のパターンに準拠しています。
CSS 変数の使用方針（--color-text, --color-bg, --color-border, --color-primary, --color-text-muted, --color-bg-secondary, --font-mono）は既存パターンと一致しています。
registry.ts への追加方法も既存パターン通りです。

指摘 P-01 [軽微]: カテゴリの妥当性について

business-email を category: "text" としている判断は理解できますが、テキスト「生成」の側面が強いため "generator" も選択肢です。既存の dummy-text（テキスト生成ツール）は "generator" カテゴリに属しています。一方で char-count や text-replace は "text" です。ビジネスメール作成はテンプレートベースの「生成」であることを考えると、"generator" の方がより正確かもしれません。ただし、keigo-reference は参照ツールであり "text" が妥当です。

対応: builder の判断に委ねます。現状の "text" でも問題ありません。

指摘 P-02 [軽微]: kana-converter の modeSwitch パターンと unit-converter の categoryTabs パターンの使い分け

計画書では business-email のカテゴリ選択に unit-converter の categoryTabs パターン（role="tablist", role="tab"）を、keigo-reference のメインタブに kana-converter の modeSwitch パターン（role="radiogroup", role="radio"）を使うとしています。実際のコードを確認すると:

unit-converter: role="tablist", role="tab", aria-selected を使用
kana-converter: role="radiogroup", role="radio", aria-checked を使用

用途に応じた使い分けは適切ですが、keigo-reference の「敬語早見表」「よくある間違い」は内容を切り替える「タブ」であるため、role="tablist" の方がセマンティクス的に正確です。role="radiogroup" は「モードの選択」（kana-converter のような変換モード切り替え）に適しています。

対応: keigo-reference のメインタブは role="tablist" / role="tab" / aria-selected パターンを使用してください。

3. データの正確性: 要注意（重要な指摘あり）

指摘 D-01 [重要]: 「死ぬ」の敬語データについて

基本動詞リストに「死ぬ」が含まれていますが、「死ぬ」は明確な謙譲語が存在しない特殊な動詞です。尊敬語は「お亡くなりになる」「ご逝去する」ですが、謙譲語は原理的に不要（自分の死を謙譲語で伝えることはない）です。丁寧語も「亡くなる」が使われ、「死にます」とは通常言いません。

この動詞を含める場合、kenjogo フィールドを空にするか「（なし）」とする必要がありますが、テーブルの表示がやや不自然になります。

対応: 「死ぬ」をリストから除外することを強く推奨します。代わりに「作る」「話す」「読む」など、尊敬語・謙譲語・丁寧語の3形態が明確に存在する動詞を追加してください。

指摘 D-02 [重要]: 敬語データの正確性を実装時に個別検証すること

計画書では60エントリの動詞リストが列挙されていますが、各動詞の具体的な尊敬語・謙譲語・丁寧語の対応は記載されていません（「言う」→「おっしゃる」/「申す・申し上げる」/「言います」のような具体的な対応表がない）。

ウェブ上の敬語変換表を複数ソース確認したところ、基本的な動詞（言う、行く、来る、見る、聞く、食べる、飲む、する、いる等）の敬語形は確立されていますが、一部の動詞（寝る、起きる、座る、立つ等）は特別な敬語形がなく「お〜になる」パターンのみとなります。

対応: builder は実装時に、信頼性の高い複数の敬語リファレンス（文化庁の敬語の指針など）を参照し、各エントリの正確性を検証してください。特に以下の点に注意:

「する」の尊敬語は「なさる」「される」、謙譲語は「いたす」
「行く」と「来る」の尊敬語はいずれも「いらっしゃる」
「聞く」の謙譲語は「うかがう」「拝聴する」「承る」
「知る」の尊敬語は「ご存知」（形容詞的用法）
特別な敬語形がない動詞は「お〜になる」「お〜する」パターンであることを明示する

指摘 D-03 [中程度]: よくある間違いデータの補足

バイト敬語の「よろしかったでしょうか」については、一部の言語学者から「完全な間違いではない」という見解もあります（日本経済新聞の記事等）。ただし一般的にはビジネスマナーとして避けるべきとされているため、掲載すること自体は問題ありませんが、explanation の表現を断定的にしすぎないよう注意してください。「一般的に誤りとされている」「ビジネスシーンでは避けるのが無難」のような表現が適切です。

対応: builder は explanation の記述において、言語学的に議論がある項目については断定を避け、「ビジネスシーンでは避けるのが望ましい」程度の表現にしてください。

指摘 D-04 [中程度]: ビジネスメールテンプレートの本文品質

テンプレート本文の具体的な文面は計画書に含まれていません（概要のみ）。builder が実装時にテンプレート本文を作成する際、以下の点に注意してください:

過度にフォーマルすぎず、かつカジュアルすぎない適切なトーンであること
「拝啓」「敬具」を使うのは非常にフォーマルな場面のみ。一般的なビジネスメールでは「お世話になっております」で始めるのが現在の主流
「thanks-visit」テンプレートの説明に「拝啓→時候なし簡潔→...→敬具」とあるが、現代のビジネスメールでは拝啓/敬具は使わないケースが多い

対応: builder は「thanks-visit」テンプレートについて、現代のビジネスメール慣行に合わせ「お世話になっております」で始まる形式に統一するか、あるいは「フォーマル版」「スタンダード版」を分けることを検討してください。

4. SEO/メタデータ: 良好（軽微な指摘あり）

指摘 S-01 [軽微]: description の文字数

types.ts のコメントには「120-160 chars for meta description」と記載されていますが、実際の既存ツールの description は66〜81文字程度です。計画書の business-email は103文字、keigo-reference は89文字であり、既存ツールよりやや長めです。

2025-2026年のSEOベストプラクティスでは、PCでは120文字前後、スマートフォンでは70文字前後が表示されるため、重要な情報を冒頭60〜80文字に配置する方針は適切です。両ツールとも冒頭でツールの本質を説明できており、問題ありません。

対応: 現状で問題なし。

指摘 S-02 [情報]: keywords の選定

両ツールとも検索意図に合致したキーワードが選定されています。特に「ビジネスメールテンプレート」「敬語一覧」「敬語早見表」は検索ボリュームが期待できるキーワードです。

5. テスト計画: 良好（追加提案あり）

指摘 T-01 [提案]: business-email テストの追加ケース

以下のテストケースの追加を推奨します:

getAllTemplates() が12テンプレートを返すこと
各テンプレートの fields に recipientCompany, recipientName, senderName が含まれること（共通フィールドの検証）
generateEmail で全フィールドが空文字列の場合の動作確認
テンプレート本文に未定義のプレースホルダーが含まれていないことの検証（テンプレートの fields とテンプレート文字列の整合性チェック）

指摘 T-02 [提案]: keigo-reference テストの追加ケース

以下のテストケースの追加を推奨します:

各エントリの examples 配列が1件以上あること
IDの重複がないこと（getAllEntries の id がユニーク）
CommonMistake の ID も同様にユニークであること
teineigo フィールドでの検索が可能であること（searchEntries のテスト）

6. UI/UX設計: 良好（提案あり）

指摘 U-01 [提案]: テンプレート切り替え時の共通フィールド保持

計画書に「共通フィールド（recipientCompany, recipientName, senderName）の値は保持する」とありますが、これは優れたUX判断です。実装時に確実に動作するよう、共通フィールドのキー名を定数として定義しておくことを推奨します。

指摘 U-02 [提案]: keigo-reference のモバイルカード表示

テーブルを768px以下でカード形式に変更する設計は適切です。ただし、60エントリのカードが一度に表示されるとスクロールが長くなるため、ページネーションまたは「もっと見る」ボタンの検討を提案します。

対応: 初期実装では全件表示で問題ありませんが、将来的な改善候補として留意してください。

指摘 U-03 [中程度]: formGrid の2カラムグリッド

計画書では入力フォームを2カラムグリッドにするとしていますが、テンプレートによってフィールド数が3〜7と大きく異なります。フィールド数が奇数の場合、最後のフィールドが1カラム幅で表示されます。これ自体は問題ありませんが、textarea フィールド（details, candidateDates）が2カラムの半分の幅だと狭すぎる可能性があります。

対応: type="textarea" のフィールドは grid-column: span 2 で全幅表示にすることを推奨します。

7. 拡張性: 優秀

テンプレートや敬語データの追加が配列への要素追加だけで完結する設計は優れています。型定義も明確で、新しいカテゴリの追加も容易です。

8. ブログ記事の構成: 良好

指摘 B-01 [確認]: ブログ冒頭のAI実験注意書き

計画書に「AI実験プロジェクトの注意書き」が含まれており、constitution.md のルール3（AIによる実験であることの通知）に準拠しています。

指摘 B-02 [軽微]: frontmatter の確認

blog-writing.md のガイドラインに従い、frontmatter の全フィールド（title, slug, description, published_at, updated_at, tags, category, related_memo_ids, related_tool_slugs, draft）が設計されています。category: "milestone" は新ツール公開記事として適切です。

9. Constitution.md 準拠チェック

日本の法律・基本的倫理基準: 問題なし。ビジネスメールテンプレートと敬語リファレンスは有用なコンテンツです。
訪問者にとって有益: ビジネスシーンで実際に使える実用的なツールであり、訪問者に価値を提供します。
AI実験であることの通知: ブログ記事冒頭に記載予定。ツール自体にも既存のサイト全体の通知機構が適用されます。
品質優先: 敬語データの正確性に関する指摘（D-01〜D-04）を反映すれば、高品質なコンテンツとなります。
創造的なアイデア: ビジネスメール作成と敬語早見表の組み合わせは、相互に補完し合う良いコンテンツ戦略です。

指摘事項サマリー

ID	重要度	対象	内容
D-01	重要	keigo	「死ぬ」をリストから除外すべき
D-02	重要	keigo	各エントリの敬語形を複数ソースで検証すべき
D-03	中程度	keigo	バイト敬語の explanation で断定を避ける
D-04	中程度	email	テンプレート本文の「拝啓/敬具」再検討
U-03	中程度	email	textarea フィールドは全幅表示推奨
P-01	軽微	email	category "text" vs "generator"
P-02	軽微	keigo	メインタブは role="tablist" を使用
S-01	軽微	両方	description 文字数（現状で問題なし）
B-02	軽微	blog	frontmatter 確認済み
T-01	提案	email	テスト追加ケース
T-02	提案	keigo	テスト追加ケース
U-01	提案	email	共通フィールドキーの定数化
U-02	提案	keigo	モバイルでのページネーション検討

重要な指摘（D-01, D-02）を builder が実装時に確実に反映することを条件に、本計画を承認します。