Valiassistantを使用したカスタムアクションの例

Created: 1月 23, 2025 | Updated: 11月 17, 2025

以下は、カスタムアクションと一緒に実装できるスクリプトの例です。スクリプトは、AI が指示されるたびに、要件、ブロック、または Valis からの情報とともに送信されるカスタムプロンプトを使用して AI に送信します。これらのスクリプト例は、お客様のニーズやユースケースに合わせて自由に変更してください。

これらのスクリプトを要件 & システムポータルで動作させるには、スクリプトの最初の設定部分で API URL を指定する必要があります。このAPI URLの取得方法はこちらを参照してください。

AIタイトル提案

このスクリプトは、AI を使用して、個々の要件に対応する短くて正確なタイトルを作成します。

AI_Title_Suggestion.txt

使用されるカスタムプロンプトは

custom_prompt = "テキストに基づいて、システムエンジニアリングのコンテキストでこの要件の短いタイトルを入力してください。タイトルに数字や単位を含めないでください。タイトルだけを返し、他のテキストは返さないでください。

これは、AIに要件テキストと一緒に送信されます。

AIによる要件タイプの提案

このスクリプトは、AI を使用して、要件テキストに基づいて、要件を「機能」、「パフォーマンス」、「システム」などの特定のタイプに分類します。要件とシステムポータルの設定で定義されているすべてのタイプが考慮されます。

AI_Type_Suggestion.txt

使用されるカスタムプロンプトは次のとおりです：

custom_prompt = "タイプのみで応答してください。以下のタイプを考慮してください：{types_string}。要件テキストに基づいて、提供された要件を提供されたタイプ ({types_string}) のいずれかに分類します。type'の形式でタイプのみを返します。"

AI 要件の品質チェック

このスクリプトは、INCOSE 規格に照らして要件テキストの品質をチェックし、品質タグおよび改善案という形で、定量的および質的応答を返します。

AI_Quality_Check.txt

使用されるカスタムプロンプトには、最も関連性の高い INCOSE ルールが含まれています：

custom_prompt = """
        要件（Requirements）を記述するためのINCOSE標準を以下に示します：
        R1 - 構造化された完全な文章（主語、動詞、目的語）を使用する。 
        R2 - 必要性または要件文の主文構造では能動態を使用し、責任主体を文の主語として明確に特定する。 
        R3 - ニーズまたは要求事項の文の主語と動詞が、そのニーズまたは要求事項が参照するエンティティに適切であることを確認する。 
        R5-不定冠詞 "a "ではなく定冠詞 "the "を使用する。
        R6 - 数量を記載する際には、適切な単位を使用する。すべての数値には単位を明示する。
        R7 - 「いくつか」、「どれでも」、「許容範囲」、「いくつか」、「たくさん」、「いくつか」、「ほとんどいつも」、「ほとんど」、「ほぼ」、「ほぼ」、「ほぼ」、「ほぼ」、「ほぼ近い」、「ほぼ」、「おおよそ」などの曖昧な用語の使用は避ける。 
        R8-「可能な限り」、「可能な限り少なく」、「可能な限り」、「可能な限り」、「可能な限り」、「必要と証明されれば」、「必要であれば」、「必要な程度に」、「適切であれば」、「必要であれば」、「実用的な程度に」、「実用可能であれば」などの逃げ口上は避ける。 
        R9- "including but not limited to"、"etc."、"and so on "のようなオープンエンドの句は避ける。 
        R10- "be designed to"、"be able to"、"be capable of "のような余計な不定詞は避ける。  
        R12, 13, 14 - 正しい文法、スペル、句読点を使う。
        R15 - 「[X AND Y]」、「[X OR Y]」、「[X XOR Y]」、「NOT[X OR Y]」のような論理表現は、決められた規則で表現する。
        R16 - "not" の使用を避ける。 
        R17 - km/hrのような単位以外では、斜め記号（"/"）の使用を避ける。
        R18 - 関連する小節によって条件づけられ、修飾された一つの考えを含む一つの文を書く。
        R19 - "and"、"or"、"then"、"unless"、"but"、"as well as"、"but also"、"however"、"whether"、"meanwhile"、"whereas"、"on the other hand"、"otherwise "などの、節をつなぐ組み合わせ記号は避ける。 
        R20 - 必要性や要求の目的を示す表現は避ける。 
        R21 - 従属テキストを含む括弧や括弧は避ける。
        R22 - セットの名前にグループ名詞を使う代わりに、明示的にセットを列挙する。 
        R24 - 代名詞や不定代名詞の使用は避ける。
        R26 - 100'%の信頼性、100'%の可用性、all、every、always、never などの、達成不可能な絶対値の使用は避ける。
        R28 - 特定の条件に対する行動を列挙するのではなく、一つの行動に対して条件の命題性を明示する。
        R29 - 対応する問題やシステムの側面に従って、ニーズと要求を分類する。 
        R31 - 設計入力を定義するときは、設計を制約する根拠がない限り、解決策を述べることは避ける。どのように "という解決策よりも、"何を "という問題に焦点を当てなさい。 
        R32 - 普遍的な定量化を意図する場合は、「すべて」、「いずれか」、「両方」ではなく、「それぞれ」を使用する。 
        R33 - 数量は、それが適用され、エンティティが検証または妥当性確認されるエンティティに適した値の範囲で定義する。
        R34 - 必要性または要求事項が記載され、エンティティが満たすことが検証されるエンティティに適切な、具体的で測定可能なパフォーマンス目標を提供する。
        R35 - "最終的に"、"まで"、"前に"、"後に"、"として"、"一度"、"最も早く"、"最も遅く"、"瞬時に"、"同時に"、"最後に "などの不定な時間的キーワードを使用する代わりに、時間的依存関係を明示的に定義する。
        R38 「略語の使用は避ける。
        これらのINCOSEの要件基準に基づいて、0から100までのquality_score_of_the_requirement_textと、それに対応するcomment_for_improvementの形式の辞書を返してください：
        こ の辞書には、 0 ～ 100 ま での品質スコ ア と 、 それに対応す る 改善の コ メ ン ト が次の形式で格納 さ れてい ます ： {'Score': quality_score_of_the_requirement_text, 'Comment': comment_for_improvement}.
        """