asd-ste100

ASD-STE100 簡易技術英語（STE）

ASD-STE100 Issue 9（2025年1月）に準拠して技術文書の作成、書き換え、検証を行います。STE は ASD（欧州航空宇宙・安全保障・防衛産業協会）が所有する制御された自然言語です。これにより、技術文書は曖昧さがなく、理解しやすく、翻訳しやすくなります。この標準は2つの部分で構成されています。9つのセクションに分かれた53の執筆ルール（Part 1）と、約900の承認語を収録した制御辞書（Part 2）です。

STE は学習者向けの簡易英語ではありません。適用するには高い英語力が必要となる厳密な標準です。これはスタイルガイドを補足するものであり、置き換えるものではありません。

このスキルを適用する場面

• 既存の技術文書（マニュアル、手順、警告）を STE に書き換える
• STE に準拠した新しい手順や説明を作成する
• テキストの STE 準拠状況をレビューし、違反を報告する
• STE のルール、辞書、標準について説明する

ルール0：意味は語彙よりも優先される

他のどのステップよりも先に：辞書を満たすために、技術的事実を変更したり、限定詞を削除したり、目的語を削除したり、行為者をでっち上げたりしてはなりません。 STE は曖昧さを取り除くものであり、内容を取り除くものではありません。承認語だけで構成されていても、虚偽または空虚なことを述べている文は、フラグが付いた語を1つ残した文よりも悪い失敗です。

これは、STE の書き換えが準拠しているように見え、もっともらしく読めながら、実際には誤っているという失敗のパターンです。自分の出力で注意すべき3つの兆候：

• 最も近い語への置き換え。「失われる可能性があるデータ」→「減少する可能性があるデータ」。decrease は承認語だったため採用されましたが、定義は今や虚偽です。代わりに文を再構成します：「システムが失う可能性があるデータの量」。
• 目的語の切断。「プラットフォームの拡張を助ける」→「プラットフォームの増加を助ける」。何が増加するのか？ 他動詞は目的語を保持しなければ、その文は何も述べていません。
• ヘッジの削除。「より重要になる可能性がある」→「より重要である」。法助動詞を削除すると、限定された主張が絶対的な主張に変わります。（そして can は承認語です — 以下の動詞ルールを参照してください。）

承認語が意味を担えない場合は、次の手順を順番に取ります：文を再構成する、承認された動詞句（get access to、make sure that、find the cause of）を使う、プロジェクトの用語集から技術名詞または技術動詞を宣言する、または正確な語を保持してフラグを立て、その理由を成果物に記載します。置き換えを正当化するために辞書の裁定をでっち上げてはなりません。

完全な手順、トラップ表、および5つの忠実性パス：references/meaning-fidelity.md。すべての書き換えでこれを読み込んでください。

ステップ1：テキストの種類を特定する

各ルールは、テキストが手順的か記述的かによって異なります。書く前に分類してください。

	手順（指示）	記述（説明）
目的	ユーザーに何をすべきかを伝える	物事がどのように機能するか、または何が起きたかを説明する
態	能動態のみ、命令形（「ポンプを設置する」）	できるだけ能動態。行為者が不明または重要でない場合は受動態も許容される
文の長さ制限	最大20語	最大25語
構造	1文につき1つの指示	1段落につき1つのトピック

同じ箇所で手順的な文章と記述的な文章を混在させないでください。

受動態を避けるために行為者をでっち上げてはなりません。 ルール3.5は、記述的な文章においてできるだけ能動態を求めており、どんな犠牲を払っても求めてはいません。元の文が「バックアップは頻繁に取得すべきである」と述べている場合、「チームは頻繁にバックアップを取得しなければならない」と書いてはなりません — 元の文はチームを名指ししておらず、その義務を割り当てもしていません。記述的な受動態（行為者不明）を保持するか、より多くの場合、その箇所が実質的には手順的であると認識して命令形を使います：「頻繁にバックアップを取得してください。」再分類することで、受動態とでっち上げられた行為者の両方を一度に取り除けます。

ステップ 2: 中核ルールを適用する

1 語、1 意味、1 品詞。 承認済みの各語には、承認済みの意味が 1 つと承認済みの品詞が 1 つあります。語は特定の品詞に対して承認されます。ある語が辞書に載っていても、あなたの文では違反になることがあります。例:

• start (v) は承認されています。begin、commence、initiate は承認されていません
• fall (v) は「重力によって下へ移動する」だけを意味し、「減少する」を意味することはありません
• check は名詞としてのみ承認されています -- 「do a check of the valve」と書き、「check the valve」とは書きません
• about は「〜に関係する」だけを意味し、「およそ」を意味することはありません

承認済みの動詞形のみ: 不定詞、命令形、単純現在、単純過去、単純未来、および形容詞としてのみの過去分詞(「the installed component」)。

過去分詞はその基本動詞の判定に従います。 形容詞として使われる分詞は、その基本動詞が承認されているか、宣言された技術動詞である場合にのみ有効です。install (v) は承認されているので、「the installed component」は正しいです。require は承認されていないので、「the required parts」は正しくありません -- たとえ普通の形容詞に見えてもです。分詞をまず不定詞に還元し、それについて判定してください。同じルールが名詞化にも当てはまります。install (v) が承認されているからといって、installation (n) が承認されていることにはなりません。

法助動詞と助動詞 -- can と must は承認されています。それ以外は承認されていません。

許可	用途	不許可	置き換え
can (v)	能力または可能性: 「you can get access to the jacks」	may、might、could	can、または条件を述べる: 「If X, then Y」
must (v)	義務: 「you must have the necessary parts」	should、shall、ought to	must、または命令形
will	単純未来	would	単純現在または can で書き直す

原文の文から can や must を削除すると、その文が主張する内容が変わります。より「簡素化」して見せるためにこれらを落とさないでください -- それは簡素化ではなく、ルール 0 の違反です。

使用しないもの:

• 非承認の法助動詞: may、might、could、should、would、shall
• 進行形または複雑な動詞構文(「must be installing」は「install」になる)
• 動詞としての -ing 形 -- 技術名詞(「the opening」)として、または技術名詞内の修飾語としてのみ使用してください
• 手順における受動態
• 文の要素の省略 -- 主語、動詞、冠詞を保持してください

構造ルール:

• 1 文につき 1 つの指示、1 段落につき 1 つのトピック、1 段落につき最大 6 文
• 複数語名詞: 最大 3 語。これは上限であり、目標ではありません -- 適法な 2 語および 3 語のクラスタ(「database query times」、「application errors」)は保持し、前置詞句は 4 語以上のクラスタ、または曖昧なクラスタにのみ使用してください。すべての短いクラスタを of の連鎖に変換すると、原文より重い文章になります
• 条件は命令の前に置いてください: 「Do Y if X」ではなく「If X, do Y」と書きます
• 複雑な手順には縦のリストを使用してください
• 記述的な文章では文の長さと構文を変化させてください(ルール 6.5)。同じ枠組みの文が 3 つ連続する(「The teams must...」)のは違反であり、中立的な文体ではありません
• 冠詞は存在させるだけでなく正しく保ってください: 不可算名詞は a/an を取りません(「a high CPU use」ではなく「high CPU use」)。また、総称的な種類は the を取りません
• 安全指示(WARNING、CAUTION、NOTE)は明確な命令または条件で始めなければなりません

綴り: アメリカ英語(Merriam-Webster)を使用してください。イギリス綴りを変換してください(colour は color になる)。

技術名詞と動詞: 会社またはドメイン固有の用語(たとえば「hydraulic pump assembly」、「to ream」)は、公式ドキュメントや用語集に由来する場合、辞書になくても許可されます。それらの中の非承認語は最小限に抑えてください。

ステップ 3: 辞書に対して語を検証する -- その品詞とともに

語彙管理は、STE レビューが最も頻繁に失敗する領域です。短く能動的な文だけでは十分ではありません。すべての内容語は、承認された語（1 つの承認された意味と品詞を持つ）または宣言された技術名詞もしくは技術動詞でなければなりません。語の判定を記憶だけに頼らないでください。

語は、テキスト文字列としてではなく、実際に使われている形で判定します。 語が合格するのは、その形が辞書に記載されており、使われている品詞が辞書の見出し語と一致し、意味が単一の承認された意味と一致する場合だけです。品詞をタグ付けせずに語をリストと照合することは、非準拠のテキストがレビューを通過してしまう最も一般的な原因です。たとえば、「Check all required dependencies」は短く、能動的で、命令形ですが、それでも 2 つの辞書の判定に違反します。タグ付けの手順、派生形の規則、およびこの文を完全に処理した例については、references/pos-analysis.md を参照してください。実際の辞書に対して、利用可能な最初の情報源から次の順序で検証してください。

1. ユーザーの公式 PDF（最良の情報源）。 ユーザーに ASD-STE100 の自分のコピーを依頼してください。これは asd-ste100.org から、Downloads、Issue 9 の順に進み、短いリクエストフォームの後に無料で入手できます。ユーザーが自分のコピーへのファイルパスまたは URL を提供した場合は、PDF ツールで Part 2（辞書）を直接読んでください。疑わしい各語を検索し、その後、形式の慣例を適用します -- 大文字は承認済み、小文字は非承認を意味し、第 2 列には承認された意味または大文字の代替語が示されます。完全な検索手順については、references/dictionary-access.md を参照してください。
2. Web 取得（限定的）。 asd-ste100.org へのアクセスは、現在の Issue を確認し、ユーザーに正確なリクエストページを伝えるためだけに使用してください。辞書はリクエストフォームの背後にあり、スクレイピングすることはできません。Web 上で見つかる非公式のミラーコピーは使用しないでください（著作権および正確性のリスク）。
3. 組み込みのフォールバック。 公式コピーが利用できない場合は、references/dictionary.md（既知の判定と高リスク語の表）に基づいて作業し、成果物に次のように明確に記載してください：「語彙は、既知の判定と高リスクパターンのみに対してチェックされ、公式の ASD-STE100 Part 2 辞書に対してはチェックされていません。完全な準拠には、公式標準に対する検証が必要です。」

書き換えまたはレビューの検証手順：

1. 最初に用語表を作成します。原文で各対象物に使用されているすべての名称（たとえば、platform、application、system、software package）を列挙します。対象物ごとに 1 つの名称 -- 承認された語または宣言された技術名詞 -- を選び、記録し、どこでもそれを使用します。
2. 下書きからすべての内容語（名詞、動詞、形容詞、副詞）を、一意の文字列としてではなく出現として抽出します。2 つの文にある同じ語が 2 つの品詞を持つことがあり、2 つの判定が必要です。宣言された技術名詞および技術動詞と、承認された機能語は除外します。
3. 各出現を、文脈における品詞でタグ付けします。 単純な単語リストでは見落とされる形に注意してください。文頭の命令形（「Check the valve」 -- 名詞ではなく動詞）、動詞として使われる名詞（「torque the bolt」）、形容詞として使われる過去分詞（「the required parts」）、-ing 修飾語、および名詞化です。
4. 派生形をその基本形に還元し、まず基本形について判定します。 分詞は不定詞に、名詞化は動詞に、-ing 修飾語はそれを含む技術名詞になります。派生形は、その基本動詞が不合格になると不合格になります。
5. 各出現を、上記の辞書情報源に対してその品詞マーカー（check (n)、install (v)）とともに調べます。記載されていますか？ 品詞は一致しますか？ 単一の意味は一致しますか？ 判定は語 + 品詞として記録します -- 「check：承認済み」と書くことは有効な判定結果ではありません。
6. references/dictionary.md にある高リスクパターンをスキャンします -- 曖昧な数量詞、主観的な形容詞、抽象的な名詞化、判断に基づく指示。これらは、文が短く能動的であってもレビューに失敗します。
7. 不合格になったすべての出現を置き換えるか、正当化します。レビューレポートでは、各不合格について、その品詞、判定、および判定の情報源（公式辞書またはフォールバック表）を記載します。

ステップ 4: 変換と検証

テキストを STE に変換するワークフロー:

1. 原文のパッセージに含まれる命題を洗い出す: 各事実、関係、限定表現を列挙します。これがステップ 12 (references/meaning-fidelity.md、パス 1) で出力と照合するリストになります
2. 各パッセージを手順的または記述的に分類する
3. 20/25 語の制限を超える文を分割する。削除は決してせず、必ず分割します -- どの語を削るかではなく、どの命題を独立した文にする必要があるかを問いかけます
4. 実際の行為者が存在する場合は受動態を能動態に変換し、承認されていない法助動詞と進行形を承認済みの動詞形に変換します。can と must はそのまま保持します
5. 文脈内のすべての内容語に POS タグを付与し、各出現箇所をその POS とともに辞書と照合して検証し、用語テーブル (ステップ 3) を適用します
6. すべての置換に対して置換の安全性を実行する: 文脈における元の語の意味と候補の承認済みの意味を明示し、両者が異なる場合は置換を却下します (パス 2)。反意語の罠に注意してください -- decrease は "lose" ではなく、stop は "fail" ではなく、find は "monitor" ではありません
7. 曖昧な数量詞と主観的な表現を削除し、判断を要する箇所を「If X, do Y」の判断ルールに置き換えます (references/dictionary.md の高リスクテーブル)。設計上カウントが変動する場合は、別の未検証の類義語に手を伸ばすのではなく、「more than one」を使用します
8. 抽象的な名詞化を、原文が提供する行為者を伴う動詞句に変換するか、技術名詞として宣言します。行為者を捏造してはいけません
9. 結合された指示を 1 文につき 1 つの指示に分割する
10. 条件を文の先頭に移動する
11. 省略された主語、動詞、冠詞を補い、追加した冠詞を確認します: 不可算名詞に a/an を付けず、総称的なクラスに the を付けません
12. 忠実性チェック。 ステップ 1 の命題リストを出力と照合して確認します: すべてが存在し、何も改変されておらず、何も捏造されておらず、すべてのヘッジ表現と他動詞のすべての目的語が無傷であること
13. 散文チェック。 出力を文の集まりとしてではなく、1 つの文書として読みます。繰り返される文の枠組み、正当な 2 語および 3 語の名詞クラスタから再構築された of の連鎖、均一な長さの段落がないか探します (パス 4)
14. references/checklist.md の完全なチェックリストを実行し、残っている違反と未解決としてフラグを立てたすべての語を報告します

変換例:

非 STE	STE
"Before acceptance of unit..."	"Before you accept the unit, do the specified test procedure."
"Rotate the cover until the jacks are accessible."	"Turn the cover until you can get access to the jacks."
"The unit must be installed carefully."	"Install the unit carefully."
"Check all required dependencies before you start the installation."	"Before you install the software, make sure that you have all the necessary dependencies."

最後の行は POS の問題を示しています: その草案は短く、能動態で、命令形ですが、それでも 2 回失敗します -- check は名詞としてのみ承認されており、required は require の分詞ですが、これは承認されていません。どちらの誤りも POS タグ付けなしでは見えません。

語のチェックを通過してもなお失敗する書き換え:

準拠しているように見える草案	なぜ失敗しているか	修正版
「障害後に減少する可能性があるデータの最大量」	「失われる」の代わりに decrease が使われています。障害でデータが減少することはありません -- この定義は今や誤りです（ルール0）	「障害後にシステムが失う可能性があるデータの最大量」
「このアーキテクチャはプラットフォームの増加を助けます。」	他動詞の目的語が、承認されていない語とともに削除されています。何を増加させるのですか？	「このアーキテクチャを使用すると、負荷が増加したときにより多くのアプリケーションインスタンスを追加できます。」
「応答レイテンシの速い増加は、高い CPU 使用よりも重要です。」	can be が削除されています（ヘッジであり、can は承認されています）。また、不可算名詞の「CPU 使用」に a が付いています	「応答レイテンシの急激な増加は、高い CPU 使用よりも重要である場合があります。」
「チームはリカバリ手順のテストを実施しなければなりません。」	受動態を避けるためにエージェントが考案されました。この箇所は手順を述べたものです	「リカバリ手順をテストします。」
「データベースクエリの時間」	合法な3語のクラスタが of 連鎖に分解されています	「データベースクエリ時間」

テキストをチェックする（書き換えるのではなく）ときは、各違反について、破られたルール、違反しているテキスト、違反の原因となった品詞、および準拠した書き換えを報告してください。

著作権と正確性に関する制約

• このスキルは非公式の補助ツールです。ASD または STEMG と提携しておらず、承認も受けていません。ASD-STE100 は ASD の登録商標です。
• 完全な辞書（約900の承認語と約1200の非承認語）は ASD が著作権を保有しています（EU 商標 017966390）。成果物に複製しないでください。ユーザー自身が正当に入手したコピーを読んで語を検証することは、その文書の通常の使用です。個々の判定を引用してください。パート2を一括抽出しないでください。権威あるアクセスについては、asd-ste100.org にある無料の公式標準へユーザーを案内してください。
• どのツールも（このスキルを含めて）STE 準拠を保証することはできません。最終的な承認は常に人間の執筆者に委ねられます。チェックしたテキストを納品するときは、このことを伝えてください。
• ASD/STEMG は、いかなるチェックツールや非認定トレーニングも推奨していません。

その他のリソース

参照ファイル

必要に応じてこれらを読み込んでください。デフォルトですべてを読み込まないでください：

• references/meaning-fidelity.md -- ルール 0 の全文：5 つの忠実性パス（命題インベントリ、置換の安全性、創作されたエージェント、文章品質、情報の欠落）、反意語と紛らわしい語のトラップ表、冠詞と可算性のルール、名詞クラスターの過剰修正、および実例。すべてのリライトで読み込んでください。
• references/writing-rules.md -- 9 つのルールセクションの詳細：動詞の形、文構造、複数語名詞、安全指示、-ing 形のルール、手順と説明の違い
• references/pos-analysis.md -- 品詞タグ付けの手順、派生形のルール（過去分詞、-ing 形、名詞化、名詞から動詞への変換）、確定した品詞の裁定、品詞トラップ表、実例
• references/dictionary.md -- 4 列の辞書形式、検索テクニック、既知の承認済みおよび未承認の裁定、高リスク語のパターン表、技術名詞と動詞
• references/dictionary-access.md -- 公式 Part 2 辞書に対して単語を検証する方法：無料の公式 PDF の入手、段階的なアクセス（ローカル PDF、Web フェッチ、フォールバック）、単語ごとおよび一括検索の手順
• references/checklist.md -- 完全なコンプライアンスチェックリスト（忠実性パスが最初）、文章品質の項目、最も一般的なライティングエラー、およびライターと組織のベストプラクティスリスト
• references/background.md -- 歴史、ガバナンス（STEMG）、Issue 9 の変更、業界での採用、トレーニングと認定、ツールの状況、誤解、他の制御言語との比較

リライトタスクでは、meaning-fidelity.md、writing-rules.md、dictionary.md、pos-analysis.md、dictionary-access.md を読み込んでください。コンプライアンスレビューでは checklist.md を読み込んでください。標準自体に関する質問にのみ background.md を読み込んでください。単語レベルの裁定については、リライトでもレビューでも pos-analysis.md を読み込んでください。dictionary.md と pos-analysis.md だけでリライトを実行しないでください -- これらの 2 つのファイルは置換を促しますが、meaning-fidelity.md が置換によってコンテンツが損なわれるのを防ぐものです。