エージェント型要求工学

• Break Down Complex Requirements – 選択した要件を分析し、元の意図を保持したまま、より小さく独立してテスト可能な要件に分割します。

  プロンプト例:

  Break down these requirements.

• Apply Requirement Writing Standards – 要件をレビューし、組織の要件記述ガイドラインに従って書き換えます。一般的なチェック項目には、曖昧さ、検証不能な表現、欠落しているアクター、不明確な受け入れ基準などがあります。

  プロンプト例:

  Rewrite these requirements according to our requirement quality standard.

• Translate Requirements – 技術的意味、用語、ID、トレーサビリティ参照を保持したまま、要件をある言語から別の言語へ翻訳します。

  プロンプト例:

  Translate these requirements to German.

• Classify Requirements – Electronics、Mechanical、Software、Safety、Security、またはその他の企業固有の分類法など、組織の分類スキームを要件に適用します。

  プロンプト例:

  Classify these requirements according to our applicability model.

• Generate Verification Criteria – 要件を分析し、常に同じ方法で適合性を実証するために使用できる検証方法、受け入れ基準、または試験条件を提案します。

  プロンプト例:

  Generate verification criteria for these requirements.

• Summarize a Specification/Section/Group of Requirements – 仕様、要件セクション、または要件セットの簡潔で構造化された要約を生成します。

  プロンプト例:

  Summarize the selected requirements.

優れたスキルは、AI が次の 2 点を理解するのに役立ちます。

• そのスキルをいつ使うべきか

• スキル実行時に AI が何をすべきか

スキルを定義する際、 

これは 3 つのフィールドで表現され、それぞれのフィールドには異なる目的があります。

• Name – ユーザーがスキルを識別しやすくします。

• Short Description – AI がそのスキルが関連するかどうかを判断するのに役立ちます。

• Instructions – スキルが選択された後に AI が従うべき動作を定義します。

各フィールドの詳細については、以下のセクションを参照してください。

名前

Name は短く、明確で、動作指向であるべきです。ユーザーがそのスキルの目的をすばやく理解できるようにする必要があります。良い名前は通常、そのスキルが実行するアクションと、対象とするエンジニアリング データの種類を表します。

優れたスキル名は、次の条件を満たす必要があります。

• 他のスキルと区別できる程度に具体的であること

• スキル一覧で簡単に見渡せる程度に短いこと

• そのスキルが実行する主なタスクに焦点が当たっていること

• ユーザーが自然に理解できる言葉で書かれていること

広すぎたり一般的すぎたりする名前は避けてください。その名前が多くの異なるタスクに当てはまりそうなら、おそらく十分に具体的ではありません。

短い説明

Short Description は、AI がそのスキルの内容と、いつトリガーすべきかを理解するのに役立ちます。このフィールドは重要です。というのも、スキルを手動で選択する必要がないからです。アシスタントはユーザーのプロンプトを分析し、利用可能なスキルと比較して、スキルが関連するかどうかを判断します。

良い短い説明では、次の内容を説明する必要があります。

• そのスキルが実行するタスク

• 適用対象となるエンジニアリング データの種類

• そのスキルを使用すべきタイミング

• そのスキルによって期待される結果

短い説明は簡潔であるべきですが、曖昧であってはなりません。AI が類似するスキルと区別できるよう、十分なコンテキストを含める必要があります。

不十分な短い説明は、そのスキルが属する分野しか示しません。優れた短い説明は、具体的なタスク、想定されるコンテキスト、トリガーとなる状況を説明します。たとえば、「要件を支援する」スキルだと説明するのではなく、要件品質をレビューするのか、複雑な要件を分解するのか、要件文を翻訳するのか、競合を検出するのか、検証基準を生成するのか、あるいは別の特定のアクションを実行するのかを説明すべきです。

短い説明がスキルの目的と使用コンテキストを適切に説明するほど、アシスタントはそれをいつ適用すべきかをより確実に判断できます。

命令

Instructions は、スキルが選択された後に AI が何をすべきかを定義します。これはスキルの動作を制御するうえで最も重要なフィールドです。短い説明は AI がそのスキルをいつ使うかの判断に役立ちますが、命令はそのスキルをどのように実行するかを定義します。

良い命令は、明確なステップごとのガイダンスとして記述されるべきです。最終出力だけでなく、その出力を生成する際に AI が従うべき推論や制約についても記述する必要があります。

命令では、次の内容を説明する必要があります。

• What the AI should analyze first – アシスタントは通常、何かを変更または生成する前に、エンジニアリング上の意図、コンテキスト、構造、または関係性を理解する必要があります。

• What steps the AI should perform – 出力が繰り返し可能で予測可能になるよう、動作は明示的なステップに分ける必要があります。

• What the AI should preserve – これには、元の意図、要件 ID、技術用語、単位、値、制約、参照、適用範囲、階層、またはトレーサビリティ コンテキストが含まれる場合があります。

• What the AI must not do – 優れたスキルは、不足しているエンジニアリング詳細を AI が作り出したり、意図を変更したり、新しい仮定を導入したり、ユーザーのレビューなしで変更を適用したりしないよう、明示的に防止します。

• How the AI should handle uncertainty – 情報が不足している、曖昧である、または不十分である場合、推測するのではなく、その問題を明確に示すようスキルで指示すべきです。

• What output format is expected – 結果を表、箇条書き、書き換え済みテキスト、要約、チェックリスト、または構造化レポートのどの形式で返すべきかをスキルで定義する必要があります。

優れた命令は、エンジニアリング作業において特に重要です。これは、アシスタントが仕様、検証、設計判断、または後続の実装に影響を与えるデータを扱う可能性があるためです。そのためスキルは、AI が過度に自信を持つことなく有用でいられるよう導く必要があります。

その他の注意事項

• 目的は長いプロンプトを書くことではありません。目的は、AI のための明確な運用手順を定義することです。

• Keep Skills Focused

  スキルは、1 つの繰り返し可能なタスクを適切に実行するようにすべきです。

  1 つのスキルであまりに多くのことを行おうとすると、アシスタントにとって使用タイミングの判断が難しくなり、ユーザーにとっても出力を信頼しにくくなります。たとえば、要件の分解、翻訳、品質レビュー、トレーサビリティ分析、検証生成を、これらのアクションが意図的に 1 つの厳密に定義されたワークフローの一部になっているのでない限り、1 つのスキルにまとめるべきではありません。

  スキルの目的に複数の無関係なアクションが必要な場合は、別々のスキルに分割してください。

• Define Boundaries Clearly

  優れたスキルは境界を明確にします。

  これは、要件、仕様、エンジニアリング データを扱う場合に特に重要です。アシスタントは、何を変更してよいのか、何を提案のみにとどめるべきか、何を決して仮定してはならないのかを理解している必要があります。

  有用な境界の例:

  • 元のエンジニアリング上の意図を変更しない

  • 値、制約、または設計判断を作り出さない

  • ID や参照を削除しない

  • 不足している検証方法を仮定しない

  • ユーザーのレビューなしに変更を自動適用しない

  • 不明確な情報を事実として扱わない

  境界を明確にすることで、もっともらしいが誤ったエンジニアリング出力のリスクを低減できます。

• Define the Output Format

  スキルは、結果をどのように返すかを AI に指示する必要があります。

  一貫した出力形式により、スキルのレビュー、比較、再利用がしやすくなります。

  スキルに応じて、出力は次のような形式になります。

  • 表

  • 箇条書きリスト

  • 書き換えた要件

  • 構造化レポート

  • チェックリスト

  • 要約

  • 提案された変更の一覧

  • 質問または未解決事項の一覧

  出力形式はスキルの目的に合っている必要があります。たとえば、レビュー指向のスキルは、問題、説明、推奨事項の列を持つ表形式が適していることがよくあります。書き換え指向のスキルは、元のテキスト、提案出力、根拠を示す形式が適していることがよくあります。