mcpField
A
asd-ste100

asd-ste100

github.com/danyuchnエージェントワークフロー5.8k7.8k 回インストール3 日前に更新
リポジトリ

asd-ste100 について

ASD-STE100の考え方を取り入れ、エージェントや後続システム向けに曖昧な英語を書き換えるスキルです。厳格モードとSTE風モードがあり、公式の承認語辞書は含みません。

主な機能

  1. 01厳格モードとSTE風モード
  2. 02構造ルールに基づく文の簡素化
  3. 03よくある6種類の問題を確認
  4. 04書き換え前後の比較
  5. 05事実と条件の保持

活用シーン

  1. 01エージェントのエラー文やツール説明の明確化
  2. 02プロンプトやシステムメッセージの作成
  3. 03他のエージェントや翻訳工程向けの文章整理
  4. 04安全条件や精度が失われていないかの確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/danyuchn/asd-ste100-skill --skill asd-ste100

インストール後、Claude Code で/asd-ste100を入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

README.md
LICENSE
.claude-plugin/
marketplace.json
plugin.json
examples/
linter-edge-cases.md
before-after.md
references/
writing-rules.md
scripts/
ste-lint.py

詳細

簡易テクニカル英語(ASD-STE100)

ASD-STE100は、航空宇宙・防衛産業(ASD、欧州航空宇宙・防衛産業協会)が、整備技術者が英語の指示を誤読しないように策定した、統制言語の規格です。この規格は、誤読の主な原因を二つ取り除きます。一つの単語に複数の意味があることと、一つの文に複数の解釈可能な構造があることです。

このスキルは、同じ規律を別の読み手、つまり、エラー メッセージ、ツールの説明、エージェント間の指示、状況報告などの英語の文字列を、人間の介在なしに解析する必要があるAI エージェントまたは下流システムに適用します。整備技術者が「close the valve」を形容詞(「近くにあるバルブ」)ではなく命令として読み違える可能性があるなら、言語モデルにも同じことが起こり得ます。

このスキルを使うとき

  • エージェントの出力(説明、指示、ログメッセージ、ツールの説明)が、難解で専門用語が多く、または曖昧に読める場合。
  • テキストが別のエージェント、翻訳パイプライン、または英語を母語としない読み手に渡され、誤解析によって実害が生じる可能性がある場合。
  • プロンプト、システムメッセージ、またはツールの説明を書くときに、モデルが目にする前に曖昧さを取り除きたい場合。
  • どのルールに違反していたのか、書き換えでどのように修正したのかを正確に示す変更前/変更後の比較が必要な場合。依頼してください。既定の出力は書き換えたテキストのみです(「出力形式」を参照)。

このスキルは、創作やマーケティングの文章には適していません。STEは意図的に平板で字義どおりの表現を使います。語り口、ニュアンス、説得力が重要な文章には適用しないでください。

2つのモード

書き換える前にモードを選びます。ユーザーが指定しない場合は、テキストの種類から判断します。ユーザーがルール表を求めない限り、選択は内部にとどめます(「出力形式」を参照)。

厳密モード — 手順、エラーメッセージ、ツールと関数の説明、エージェント間の指示、安全に関するテキストに使います。誤読により損害が生じる可能性がある、あらゆる場面が対象です。厳しい長さ制限や「1つの単語に1つの意味」の原則を含め、以下のすべてのルールを適用します。

STE風モード — README、PRの説明、変更履歴、解説文に使います。構造に関するルールはすべて適用し、語彙に関するルールは参考として扱います(この区分については「書き換えの基本ルール」を参照)。実際には、文の長さの制限、能動態、単純な時制、句動詞なし、セミコロンなし、名詞化なし、マーケティング用の形容詞なしを維持しつつ、「1つの単語に1つの意味」という厳格な制限は解除します。文章にはある程度の幅が必要です。厳密に書き換えると、明確化というより個性をすっかり変えてしまったように読めます。

この2つのモードと、構造/語彙の区分は、同じ違いを異なる方向から見たものです。区分では、ASDの辞書を使わずにこのスキルが検証できるルールを示します。モードでは、文章の種類に応じて、どのルールを適用するかを示します。

出典と対象範囲

このスキルは、ASD-STE100 第9版(2025年1月)の規則カテゴリーをまとめたものです。9つのセクションにわたる53の執筆規則が含まれ、語句の選択、文法、文の構成、スタイルを扱います。また、約900語の使用が承認された語(各語に意味と品詞が1つずつ)と、置き換え候補を示した約1,200語の使用を避けるべき語からなる辞書に基づいています。規則の概要と出典の詳細については、references/writing-rules.mdを参照してください。

ASDの使用承認語約900語の辞書をそのまま転載するものではありません。ASD-STE100は無料で入手できますが、再配布は無料ではありません。第9版の2ページには、「ASDの役員から書面による許可を得ずに、全文または一部を複製または公開してはならない」と記載されており、複製権が無償で認められるのは、記載されている8つのカテゴリー(ASD/AIA/AIACの加盟団体およびその加盟企業と顧客、加盟国の国防省、A4A、耐空性当局、教育目的で利用する大学および研究機関)のみに限られています。このプロジェクトはそのいずれにも該当しないため、このリポジトリには辞書を含めません。

その代わりに、このスキルでは固定された単語リストとの照合ではなく、根底にある原則(入手できる中で最も平易で一般的な語を選び、毎回同じ意味で使うこと)を適用します。ASDで承認された正確な表現が重要な場合(実際の航空機整備文書など)は、規格を入手し、実際の辞書と一語ずつ照合してください。公式ダウンロードページから請求してください。これはリンクがメールで届く請求フォームであり、直接ダウンロードするページではないことに注意してください。

主な書き換え規則

STEの規則は2種類に分かれており、このスキルが完全に適用できるのはそのうち1種類だけです。構造規則はそれ自体で完結しており、文の形を説明しているため、説明だけで適用できます。語彙規則は公式の約900語の辞書のみに基づいて定義されています。このスキルでは、その辞書を意図的に転載していません(「出典と対象範囲」を参照)。辞書がなければ、語彙規則は照合可能な基準ではなく、平易な語を好む方針にとどまります。

構造規則は確実に適用してください。語彙規則は目指す方向性として適用し、辞書への準拠を確認できないのに確認済みであるかのように示すのではなく、その旨を出力に記載してください。

構造規則 — 適用するもの
規則することしないこと
能動態"エージェントがファイルを削除します。""ファイルが削除されます(エージェントによって)。" — 行為者が本当に不明、または重要でない場合を除く
句動詞を使わない(規則9.3)"パネルを取り外します。" / "ジョブを開始します。""パネルを外します。" / "ジョブを立ち上げます。" — 2語からなる動詞の意味は、各語から予測できないため
1文につき指示は1つ"ファイルを開きます。3行目を読みます。""ファイルを開いて3行目を読み、次に一致するかどうかを確認します。"
文の長さ指示や手順は20語以下、説明は25語以下複数の節を含む長い文
セミコロンを使わない(規則8.1)文を分けるセミコロンを一切使わないこと。STEは節の接続に限らず、記号そのものを禁止しています。(規則8.1は、その他の標準的な句読点をすべて認めています。ダッシュはSTEで禁止されていませんが、文を分けるべき箇所に使われていることがよくあります。)
名詞の連結名詞句として連結する語は3語以下(「燃料ポンプ弁」)名詞を4語以上連結すること(「高圧燃料ポンプ入口弁アセンブリー」)
省略記号を使わない長くなっても、主語、動詞、冠詞を明示する簡潔にするために語を省くこと(「バックアップされていないファイルは失われます」→どのファイルか曖昧)
法を維持する"リクエストは失敗した可能性があります。"は「可能性があります」のままにする推量を事実として断定する(「リクエストは失敗しました。」)、または原文にない確実性を加える
段落の制限1段落につき1つの話題、6文以下複数の話題を含む段落
手順にはリストを使う手順または条件が3つ以上ある場合は、番号付きリストまたは箇条書きを使う複数の手順を1つの文章に詰め込む
語彙のルール — 方向性のみ
ルールすることしないことここでは弱い理由
1つの単語に1つの意味1つの動作には1つの動詞を選び、毎回同じものを使います(例:常に「確認する」を使い、同じ動作に「確認する」「検証する」「確かめる」を混在させない)同じ考えを表す類義語を文書内で使い分ける文書内の一貫性は確認できます。どの単語が 承認済み なのかは、辞書がなければ確認できません。
1つの単語につき1つの品詞「バルブにオイルを塗布する」(オイル=名詞)「バルブにオイルを差す」(oil=動詞)「oil」が名詞としてのみ承認されているかどうかは、辞書に記載された事実です。どちらも同じように自然なら、名詞形を優先してください。準拠していると断言しないでください。
名詞ではなく動詞(ルール3.7)「ログを分析する。」「ログの分析を実行する。」— 動作を名詞形にすると文が長くなり、誰が行うのかが見えにくくなりますルール3.7では、「動作を表すには承認済みの動詞を使う」とされています。動詞形を優先することは、どこでも安全に適用できます。どの動詞が承認済みかを知るには、辞書が必要です。
専門用語必要な技術的な名詞・動詞は使い、一般的な英語ではないものは一度定義します(STEでは、基本辞書に加えてプロジェクト固有の用語集を使用できます)定義しないまま専門用語を使う用語集の使用が認められているのは確かにSTEの規定ですが、それが補う基本辞書はありません。
単純時制 — 1つの例外を除いて適用

STEで認められているのは、不定詞、命令形、単純現在形、単純過去形、単純未来形、および形容詞としての過去分詞です。現在完了形やその他の複合形は除外されます。「レポートを受け取りました」とし、「レポートを受け取っています」とはしません。

航空機のマニュアルで現在完了形が必要になることはないため、この除外によって規格の有用性が損なわれることはありません。一方、ほかの文書ではそうとは限りません。「ジョブが完了した」(その出力は現在利用可能)と「ジョブが完了した」(過去のある時点でのこと)は異なる内容を述べており、ステータス文では前者が必要になることがよくあります。複合形が、単純形では表せない情報(現在との関連性や、「失敗した可能性がある」のような控えめな表現)を含む場合は、その形を維持し、規則からの逸脱として注記してください。 それ以外の場合は、規則に従ってください。

スキャン用チェックリスト

この6つの習慣で、機械生成された英語の読み取りを難しくする要因の大半をカバーできます。どれも機械的に確認できます。判断に頼らず、ルールに反する単語や句読点を正確に指摘できます。書き直しを始める前に、6項目すべてを確認してください。

  1. 類義語の使い分け — 同じものに文書内で複数の名前が付けられています(「ユーザー」「顧客」「クライアント」など)。読者には、それらが同じものなのか、別々のものなのか判断できません。対処法:名前を1つ選び、常にそれを使います。
  2. 曖昧表現の重ねがけ — 補助動詞や限定表現が重なり、文が何も主張しなくなっています(「これは改善に役立つ可能性があるかもしれない点に注意することが重要です」など)。対処法:主張を明確に述べるか、削除します。
  3. 名詞化 — 動作が名詞に変えられています(「分析を実行する」「支援を提供する」など)。対処法:動詞を使います(「分析する」「支援する」など)。
  4. マーケティング形容詞 — 実績を示す代わりに品質を主張する言葉です。シームレス、堅牢、強力、最先端、手間いらず、驚異的に高速などが該当します。対処法:削除するか、その主張を裏付ける測定値に置き換えます。
  5. 長すぎる文 — 複数の考えをセミコロンやダッシュでつないでいます。対処法:1文につき1つの考えにします。
  6. 曖昧な句動詞 — 「立ち上げる」「連絡する」「掘り下げる」「開始する」などです。対処法:単純で明確な動詞(「始める」「連絡する」「読む」「開始する」など)を使います。

手順

  1. モード(Strict または STE 風)を選びます。ユーザーがルール表を求めた場合に限り、選んだモードを伝えます。「出力形式」を参照してください。
  2. 意味を把握するため、入力テキストを一度読みます。書き換えた後も何を伝える必要があるかを理解する前に、書き換えを始めないでください。
  3. 文ごとに確認します。「コア書き換えルール」の表にあるルール違反と、「確認チェックリスト」にある習慣をすべて指摘します。STE 風モードでは、語彙ルールを指摘しますが、適用はしません。構造ルールの機械的な一次チェックには、scripts/ste-lint.py を実行します(標準入力またはファイル引数を使用し、構造化出力には --json を指定します)。このツールは、セミコロン、文の長さ、句動詞、名詞化、宣伝的な形容詞、類義語の使い分け、対応するリスト項目における接続詞のぶら下がり、受動態、複合時制をチェックします。また、設計上、ヘッジ表現やモダリティは決して指摘しません。--baseline N は、既存の文書に導入する際に、N 個の重大な違反を許容します。--disable rule1,rule2 は、指定したルールを無効にします。
  4. 指摘した各文を書き換えて、元の意味を正確に保ちながら違反を修正します。書き換えによって必要な精度(安全条件、適用範囲を限定する表現、数値など)が失われる場合は、暗黙に簡略化するのではなく、長い表現を維持してその旨を指摘します。
    • 書き換えを確定する前に、モダリティを確認してください。 ヘッジ表現(「may」「could」「sometimes」「is likely to」など)は、著者の確信度を示すものであり、確信度は内容の一部です。ヘッジ表現を事実の断定に変えて文を短くするのは、単純化ではなく、別の主張です。ヘッジ表現こそ文字数制限によって削られやすいため、善意の STE 書き換えで最もよく起こる誤りです。
    • 原文にない事実を加えてはいけません。原因、頻度、仕組みを補うことで読みやすくなる書き換えは、もはや書き換えではありません。
  5. 書き換えたテキストを出力します(「出力形式」を参照してください)。ユーザーが求めない限り、モードの選択とルールの分析は内部に留めます。
  6. 入力がすでにルールに準拠している場合は、その旨を伝えます。準拠しているテキストを無理に変更してはいけません。

出力形式

既定:書き換えたテキストのみ。 多くの依頼者は、ツールの説明、エラーメッセージ、プロンプトにそのまま貼り付けられる結果を求めています。簡略化したテキストだけを出力します。このスキルに関する前置き、モードの告知、違反数、変更内容の要約、ルール表、説明の申し出を最後に加えてはいけません。

追加が許されるのは、手順 4 で意図的に長い表現を維持した場合のみです。その場合はテキストの後に、Kept as-is: を先頭に付けた一行を追加し、維持した表現と、失われるはずだった精度を示します。報告する内容がない場合は、この行を省略します。

要望がある場合:ルール表。 ユーザーが理由の提示を求めた場合(「差分を見せて」「どのルールに違反していましたか」「変更内容を説明して」「変更前/変更後」など)は、代わりに次の表を出力します。

| Rule violated | Original | Simplified |
|---|---|---|
| Present perfect tense | "We have received your request." | "We received your request." |
| Noun cluster (4+ words) | "the agent task queue priority handler" | "the handler that sets task-queue priority" |

Mode: Strict. 7 violations found.

表の後に、意図的に簡略化しなかった内容とその理由を一行で記します(通常は、簡略化すると必要な精度が失われるためです)。

境界

行うこと:

  • 曖昧または難解な英語を、短く、意味が一つに定まる能動態の文に書き換えます。
  • デフォルトでは書き換えたテキストのみを返し、ユーザーから求められた場合は適用したルールを示します。
  • 原文に含まれるすべての事実、条件、適用範囲の限定を保持します。
  • すべてのヘッジの強さを保ち、原文にない主張を加えません。
  • そのまま残す必要がある専門用語について、1行の用語集エントリーを提案します。

行わないこと:

  • ASDの公式約900語の辞書を、丸暗記したかのように再現しません。承認済みの正確な表現については、必ず公式ダウンロード版を正とします。
  • 表現やニュアンスが重要な創作、マーケティング、説得を目的とする文章を簡略化しません。
  • 文を短くするために、安全上の条件、例外、適用範囲の限定を黙って削除しません。そのようなトレードオフが生じる場合は、代わりに指摘します。
  • 「失敗した可能性がある」を「失敗した」に、「Xが原因かもしれない」を「Xが原因だ」に変えません。ヘッジを失うと主張の内容が変わります。
  • 航空宇宙・防衛分野の要件を満たすSTE準拠文書を保証しません。これはSTEに着想を得た汎用の明確化ツールであり、認定済みのSTE文書作成ツールではありません。
  • 内容の乏しい文章を、真実にしたり有用にしたりすることはできません。STEが改善するのはテキストの形式であり、内容ではありません。内容のない段落をこのルールで書き換えると、整った、短く、句読点も適切な内容のない段落になります。文章に言うべきことが何もなければ、どんな書き換えでも解決できないため、磨き上げるのではなく、その旨を伝えます。
  • 明確さが損なわれるほど短くしません。目的は単語を削ることではなく、曖昧さをなくすことです。ある程度を超えて圧縮すると、読者の時間を節約するどころか余計にかかるようになります。そのため、最短ではなく、曖昧さがなくなった時点で止めます。

追加リソース

  • references/writing-rules.md — 9つのルール項目と辞書の構成を、公式規格および二次資料の引用とともに詳しくまとめています。
  • examples/before-after.md — 公式STEの例や、このスキル向けに作成したエージェント出力の例を含む、書き換え例です。
  • scripts/ste-lint.py — 対応するリスト項目の接続詞のぶら下がりや、ファイルごとに判定する類義語の使い分けチェック(1つの単語に1つの意味)など、構造ルールを検査する決定論的な標準ライブラリのみのリンターです。ハード違反が--baseline(デフォルトは0)を超えると終了コード1を返します。助言的な検出結果(受動態、複合時制)によって実行が失敗することはありません。--disableを使うと、指定したルールを無効にできます。ヘッジや法性は内容であり文体ではないため、検出対象にしません。また、--selftestでは「may have failed」が問題なく通過することを検証します。

コメント