Domain Analyzer

概要

このSkillは、ユーザーが提供する業務領域や目的の情報を基に、プラグイン化に必要な機能を分析・抽出する。ユーザーとの対話を通じて業務の本質を理解し、自動化すべき作業や必要なプラグイン要素を特定する。

責任範囲

このSkillは以下の範囲をカバーする:

• ユーザーの業務領域や目的の理解
• 業務の特徴・制約・前提条件の把握
• 自動化可能な機能の抽出
• 機能のカテゴリ分類と優先順位付け
• 推奨エージェント・スキル・コマンドの提案
• 業務領域分析レポートの作成

ワークフロー

フェーズ1: 情報収集

ユーザーとの対話を通じて、業務領域や目的に関する基本情報を収集する。

実施内容:

1. 業務領域の概要を確認する
2. プラグイン化の目的を明確にする
3. 対象ユーザー（利用者）を特定する
4. 現在の課題や問題点を把握する
5. 期待される効果や成果を確認する

質問例:

【業務領域の確認】
プラグイン化したい業務領域を教えてください。以下のどれに近いですか？

1. 開発プロセス（要件定義、設計、実装、テストなど）
2. ドキュメント作成（技術文書、仕様書、マニュアルなど）
3. データ処理（分析、変換、集計など）
4. その他（具体的に教えてください）

良い例:

業務領域: データベース設計
目的: データベーススキーマ設計を効率化し、設計品質を向上させる
対象ユーザー: バックエンド開発者、データベースエンジニア
課題: 手作業でのER図作成に時間がかかり、正規化の検証が不十分
期待効果: 設計時間を50%削減し、正規化ルール違反をゼロにする

悪い例:

業務領域: いろいろなこと
目的: 便利にしたい
対象ユーザー: みんな
課題: よくわからない
期待効果: 良くなる

フェーズ2: 領域分析

収集した情報を基に、業務領域の特徴や制約を分析する。

実施内容:

1. 業務の特徴を整理する
2. 技術的制約を特定する
3. ビジネス的制約を特定する
4. 前提条件や依存関係を把握する
5. 既存ツールやプロセスとの関係を確認する

分析観点:

• 業務の複雑度（シンプル/標準/複雑）
• 自動化の難易度（容易/中程度/困難）
• 必要な専門知識のレベル（基本/中級/上級）
• 対象範囲の広さ（狭い/中程度/広い）

良い例:

【分析結果】
業務の特徴:
- データベース設計は段階的なプロセス（概念設計 → 論理設計 → 物理設計）
- 正規化ルールや命名規則など、明確な規約が存在する
- ER図やテーブル定義書など、複数の成果物が必要

技術的制約:
- データベース製品（MySQL, PostgreSQL, SQL Serverなど）により構文が異なる
- 既存データベースとの互換性を考慮する必要がある

ビジネス的制約:
- 設計変更のコストが高いため、初期段階での品質確保が重要
- チーム内での設計レビューが必須

悪い例:

【分析結果】
業務の特徴: 複雑
制約: いろいろある

フェーズ3: 機能抽出

業務領域から、プラグインとして実装すべき機能を抽出する。

実施内容:

1. 業務の各ステップを分解する
2. 自動化可能な作業を特定する
3. 手作業が必要な部分を明確にする
4. 各機能の入力と出力を定義する
5. 機能間の依存関係を整理する

抽出基準:

• 繰り返し実施される作業
• 明確なルールやパターンがある作業
• 検証や品質チェックが必要な作業
• ドキュメント生成が必要な作業
• テンプレートファイルを使用する作業（ドキュメント生成、フォーム入力、定型文作成など）

良い例:

【抽出された機能】

1. エンティティ定義の収集
   - 入力: ユーザーからの要求、既存システムの情報
   - 処理: エンティティの特定、属性の定義、関連の整理
   - 出力: エンティティ一覧、属性リスト

2. 正規化の実施
   - 入力: エンティティ定義
   - 処理: 第1正規形〜第3正規形への変換、正規化ルール検証
   - 出力: 正規化されたテーブル定義

3. ER図の生成
   - 入力: 正規化されたテーブル定義
   - 処理: ER図の自動生成、レイアウト最適化
   - 出力: ER図（Mermaid形式）

4. テーブル定義書の作成
   - 入力: テーブル定義、制約情報
   - 処理: 定義書フォーマットへの変換
   - 出力: テーブル定義書（Markdown形式）
   - テンプレート: table-definition-template.md（テーブル名、カラム定義、インデックス、制約の記述フォーマット）

5. DDLスクリプトの生成
   - 入力: テーブル定義、対象データベース製品
   - 処理: データベース製品別のDDL生成
   - 出力: CREATE TABLE文、制約定義

悪い例:

【抽出された機能】

1. データベースを作る
2. 便利にする
3. 良くする

フェーズ4: 要素分類

抽出した機能を、エージェント・スキル・コマンドに分類する。

実施内容:

1. 責任範囲の広い機能をエージェント候補として分類する
2. 具体的な作業手順をスキル候補として分類する
3. エージェントとスキルの組み合わせをコマンド候補として分類する
4. 規約やガイドラインをコンベンションスキル候補として分類する
5. 必要なテンプレートファイルと対応するスキルの関係を特定する
6. 要素間の依存関係を整理する

分類基準:

• エージェント: 特定フェーズや領域全体に対する責任を持つ
• スキル（ワークフロー）: 具体的な作業手順を定義する
• スキル（コンベンション）: 規約やガイドラインを定義する
• コマンド: エージェントとスキルを組み合わせて実行可能にする

良い例:

【分類結果】

エージェント候補:
- database-design-agent: データベース設計全体に対する責任を持つ

ワークフロースキル候補:
- entity-definition-collector: エンティティ定義を収集する
- normalization-processor: 正規化を実施する
- er-diagram-generator: ER図を生成する
- table-definition-writer: テーブル定義書を作成する
- ddl-script-generator: DDLスクリプトを生成する

コンベンションスキル候補:
- database-naming-conventions: データベース命名規則
- normalization-rules: 正規化ルール

コマンド候補:
- design-database: データベース設計全体を実行（全スキルを順次実行）
- generate-schema: スキーマ定義のみを生成（一部スキルを実行）

悪い例:

【分類結果】

エージェント: データベース
スキル: いろいろ
コマンド: 実行

フェーズ5: 推奨提示

分類結果を基に、推奨されるプラグイン構成をユーザーに提示する。

実施内容:

1. 推奨されるエージェント構成を提示する
2. 推奨されるスキル構成を提示する
3. 推奨されるコマンド構成を提示する
4. 実装の優先順位を提案する
5. 次のステップ（各要素の詳細設計）を案内する

提示形式:

【推奨プラグイン構成】

プラグイン名: database-design-plugin

エージェント (1個):
- database-design-agent: データベース設計全体に対する責任を持つ

スキル (7個):
ワークフロースキル:
- entity-definition-collector: エンティティ定義を収集する
- normalization-processor: 正規化を実施する
- er-diagram-generator: ER図を生成する
- table-definition-writer: テーブル定義書を作成する
- ddl-script-generator: DDLスクリプトを生成する

コンベンションスキル:
- database-naming-conventions: データベース命名規則
- normalization-rules: 正規化ルール

コマンド (2個):
- design-database: データベース設計全体を実行
- generate-schema: スキーマ定義のみを生成

【実装優先順位】

優先度1（必須）:
- database-design-agent
- entity-definition-collector
- normalization-processor
- database-naming-conventions
- normalization-rules

優先度2（推奨）:
- er-diagram-generator
- table-definition-writer
- design-database コマンド

優先度3（オプション）:
- ddl-script-generator
- generate-schema コマンド

良い例:

推奨構成が明確で、各要素の役割が説明されており、優先順位が付けられている。

悪い例:

【推奨プラグイン構成】

いろいろ作る

アウトプット

このスキルは以下を生成する:

• 必要な機能リスト: 抽出された機能の一覧（入力・処理・出力を含む）
• 推奨エージェント/スキル/コマンド候補: プラグイン要素の推奨構成
• テンプレートファイルリスト: ドキュメント生成機能で使用するテンプレートファイルの一覧（配置先を含む）
• 業務領域分析レポート: 業務の特徴、制約、前提条件をまとめたドキュメント

想定されるエラーと対処法

エラー1: 業務領域が曖昧

検出例:

業務領域: いろいろなこと

対処法:

• 具体的な業務名や作業内容を確認する
• 既存の業務プロセスやドキュメントを参照する
• ユーザーに具体例を尋ねる

エラー2: 機能の粒度が不適切

検出例:

機能: データベース全体を作成する

対処法:

• 機能を小さなステップに分解する
• 各ステップの入力と出力を明確にする
• 1つの機能は1つの明確な目的を持つようにする

エラー3: 要素分類が不明確

検出例:

エージェントとスキルの区別が曖昧で、どちらに分類すべきか不明確。

対処法:

• エージェントは「責任範囲」、スキルは「具体的な作業手順」と区別する
• 複数のスキルをまとめる役割はエージェントにする
• 1つの明確な作業フローを持つものはスキルにする

ベストプラクティス

• 業務領域の理解には十分な時間をかける（急がず丁寧に）
• ユーザーとの対話を重視し、推測や仮定を避ける
• 機能は小さく分解し、単一責任の原則に従う
• 要素分類は明確な基準に基づいて行う
• 推奨構成は実装の優先順位を明示する
• 業務領域分析レポートは後続フェーズで参照できるようにする

チェックリスト

情報収集完了時

• 業務領域の概要が明確になっている
• プラグイン化の目的が明確になっている
• 対象ユーザーが特定されている
• 現在の課題や問題点が把握されている
• 期待される効果や成果が確認されている

領域分析完了時

• 業務の特徴が整理されている
• 技術的制約が特定されている
• ビジネス的制約が特定されている
• 前提条件や依存関係が把握されている
• 既存ツールやプロセスとの関係が確認されている

機能抽出完了時

• 業務の各ステップが分解されている
• 自動化可能な作業が特定されている
• 手作業が必要な部分が明確になっている
• 各機能の入力と出力が定義されている
• ドキュメント生成機能で使用するテンプレートファイルが特定されている
• 機能間の依存関係が整理されている
• 機能の粒度が適切である（単一責任の原則）

要素分類完了時

• エージェント候補が特定されている
• ワークフロースキル候補が特定されている
• コンベンションスキル候補が特定されている
• コマンド候補が特定されている
• 要素間の依存関係が整理されている
• 分類基準が明確である

推奨提示完了時

• 推奨プラグイン構成が明確に提示されている
• 各要素の役割が説明されている
• 実装の優先順位が付けられている
• 次のステップが案内されている
• ユーザーの承認を得ている

最終確認

• 必要な機能リストが作成されている
• 推奨エージェント/スキル/コマンド候補が提示されている
• 業務領域分析レポートが作成されている
• すべてのアウトプットが明確で理解しやすい
• ユーザーが次のステップに進める状態になっている