2 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • SimpleEnglish は、LLMが1983年から航空宇宙分野で使われてきた統制言語 ASD-STE100 に合わせて、曖昧でなく短い技術文書を書くようにする Agent Skill です
  • 文長制限、能動態、単純時制、条件の先置き、1文1指示など 53のルール を適用し、文書・エラーメッセージ・ランブック・インシデント報告書・リリースノート・プロンプト・翻訳準備を支援します
  • Claude の6モデルと8つの作業を2条件で比較した96回の評価では、100語あたりの STE違反が平均72.9%減少 し、すべてのモデルで出力トークンも減少しました
  • Agent Skills 標準をサポートする Claude Code、Cursor、VS Code Copilot、OpenAI Codex、Gemini CLI などで依存関係なしに導入でき、未対応環境ではシステムプロンプトやユーザー指示として適用できます
  • 結果は ASD の公式認証ではなく、マーケティング・ブログ・ブランド文体には適用しません。標準モードは構造ルールとドメイン語彙を組み合わせ、厳格モードの単語判定には公式標準が必要です

プロジェクトが解決する問題

  • SimpleEnglish は、LLMの大げさで曖昧な文を ASD-STE100 Simplified Technical English に近い技術文へ変える Agent Skill です
  • ASD-STE100 は、疲れた整備士が指示を誤解しないようにするため、航空宇宙分野で1983年から使われてきた統制言語です
  • Claude が生成した原文と Skill 適用後の違いは、具体性と実行可能性にあります
    • 「堅牢なアーキテクチャを活用してシームレスに同期する」という文を、Postgres テーブルを S3 にコピーし、設定ファイルが1つ必要だという内容に変えます
    • 包括的な接続失敗メッセージを、ユーザー app のパスワード誤りと DB_PASSWORD 修正という対応内容に変えます
    • 不特定のユーザーに影響があった可能性があるというインシデント文言を、失敗時刻、12%のリクエスト失敗、デプロイ原因、ロールバック時刻に変えます
  • README、エラーメッセージ、インシデント報告書、リリースノートの追加比較は examples/before-after.md にあります

インストールと対応環境

  • Agent Skills 標準 をサポートする Claude Code、Cursor、VS Code Copilot、OpenAI Codex、Gemini CLI、Goose、OpenCode など約25のハーネスで動作します
  • プロジェクトは 1つのフォルダで構成 され、外部依存はなく、MIT ライセンスを使用します
  • インストールコマンドは次のとおりです
npx skills add AminBlg/SimpleEnglish
  • skills CLI がインストール済みエージェントを検出し、ユーザーが選んだ対象に Skill を導入します
  • インストール前には次のコマンドで試せます
npx skills use AminBlg/SimpleEnglish@simple-english
  • SKILL.md をサポートしない環境では、prompts/system-prompt.md をシステムプロンプト、AGENTS.md.cursorrules に入れられます
    • トークン予算が小さい環境向けに約 60トークン版 も提供します
    • 技術文書作成を依頼するか、「rewrite this with simple-english」と指示して使えます

ターミナルのない環境で使う

  • Claude.ai 有料プラン は Skill を標準でサポートします
    • SKILL.md を保存します
    • Settings → Capabilities でコード実行を有効化します
    • Settings → Customize → Skills → Upload でファイルをアップロードします
    • Skill を有効にすると、技術文書作成の依頼に適用されます
  • ChatGPT は Skill をサポートしないため、プロンプト版を使います
    • prompts/system-prompt.md のブロックを Settings → Personalization → Custom Instructions、Project、または Custom GPT の指示に入れます
  • Gemini では Gem を作成し、同じプロンプトを指示に貼り付けます
  • 他のチャットボットでは、プロンプトファイルを添付するか内容を貼り付け、すべての出力に適用するよう指示します

ASD-STE100 から取り入れた作成ルール

  • Skill は、1983年に作られた 9セクション53ルール を技術文書に適用します
  • 主なルールは次のとおりです
    • 指示文は最大20語、説明文は最大25語に制限します
    • 文書全体で1つの単語に1つの意味だけを使い、checkverifyconfirmvalidate のような表現の混用を防ぎます
    • 単純時制だけを使い、「has been updated」の代わりに、誰が何を更新したかを直接書きます
    • -ing 動詞形と、それにつながる付加節を使いません
    • 能動態 を使い、「it should be noted that」のような間接表現を削除します
    • shouldwouldmaymight は禁止ですが、canwillmust は許可されます
    • 条件を命令より前に置き、ユーザーが条件を遅れて読むことを防ぎます
    • 1文に1つの指示だけを入れます
    • 冠詞と that は残し、短くても電報文にはしません
  • ソフトウェア例を含む完全な書き換えルールは SKILL.md にあります
  • マーケティングは STE の適用範囲外なので、README のマーケティング文言にはルールを適用せず、Skill も文書作成にだけ適用されます

技術文書以外への適用範囲

  • use-cases.md は、複数の形式向けのルールを提供します
    • エラーメッセージ は、起きたこと、原因、ユーザーがすべきことの順で書きます
    • ランブックは整備マニュアルに近いため、STE を直接適用します
    • インシデント報告書では単純過去を使い、不確実で婉曲な表現を削除します
    • リリースノートの互換性破壊変更は、命令を先に、リスクを後に書く警告として構成します
    • AGENTS.md とシステムプロンプトは、質問できない読者向けの手順として扱い、モデルが任意と解釈できる should を禁止します
    • 翻訳前の文書を、非ネイティブ話者が読みやすく、ローカライズ費用が低い形に整えます
  • マーケティング文言、ブログ文体、ブランドライティング には適用せず、文体が平板なのは意図された特性です

ベンチマーク結果

  • 評価では Claude の6モデルに8つの作成タスクを Skill 適用前後で実行し、合計 96件の生成結果 を測定しました
  • 100語あたりの STE 違反は全体平均で72.9%減少しました
    • claude-opus-4-8: 1.05 から 0.62 に減少し、41%改善
    • claude-opus-4-7: 2.28 から 0.42 に減少し、82%改善
    • claude-opus-4-6: 2.24 から 0.40 に減少し、82%改善
    • claude-opus-4-5: 2.55 から 0.57 に減少し、78%改善
    • claude-sonnet-5: 2.67 から 0.53 に減少し、80%改善
    • claude-sonnet-4-6: 2.06 から 0.52 に減少し、75%改善
  • すべてのモデルで 出力トークン数が減少 し、平均文長は11.2語から9.7語に短縮されました
  • 2条件に同じルールを適用する決定論的な正規表現リンターを使っており、全体の方法と限界は evals/results/RESULTS.md にあります
  • ログイン済みの Claude Code CLI さえあれば、次のコマンドで再現できます
python3 evals/run_bench.py

ルール検証方式

  • Skill はブログ要約ではなく、2025年 Issue 9 の原文 を基準にテスト駆動方式で作られました
  • Skill のない基準エージェントは40語の文を書き、存在しないルール番号を作ることもありました
    • ある結果では短文ルールを「Rule 3.1」と引用しましたが、実際の Rule 3.1 は動詞形に関するルールです
  • 一部の二次資料とは異なり、公式 PDF では canwill を許可しています
  • 記録した基準失敗を1つずつ防ぐように Skill を書き、その後エージェントが通過するまで再テストしました。シナリオと結果は evals/pressure-tests.md にあります

適用上の限界と標準としての位置づけ

  • 成果物は STE認証文書ではありません
    • ASD はどのツールも認証しません
    • 標準モードは構造ルールとユーザーのドメイン語彙を組み合わせます
    • 厳格モードは標準により近づきますが、単語ごとの判定には 公式標準 が必要です
  • 結果は Airbus のマニュアルのように平板で誤解しにくく書かれ、個性的な文体はブログなど別用途に残すよう設計されています
  • 「明確に書け」という主観的な指示と違い、「文を20語以下で書け」は 検証可能な仕様 なので、エージェントが従えます
  • ASD-STE100 は40年以上前の標準ですが、2025年1月の Issue 9 まで維持・更新されており、番号があり、テスト可能です

ライセンスと非公式な位置づけ

  • リポジトリ全体は MIT ライセンス で提供されます
  • 教育のためにルールを言い換えており、公式仕様の文言や辞書内容は複製しません
  • ASD または STEMG と提携または承認を受けたプロジェクトではなく、ASD-STE100 は ASD の登録商標です

1件のコメント

 
GN⁺ 3 시간 전
Hacker Newsのコメント
  • 例を1つ示して、その前に「ASD-STE100簡易技術英語で書き直せ」という一文を付けるだけでも、十分にまともな結果が出る。指示は1〜2文で足りるはずで、ASD-STE100はすでに学習データに含まれている可能性が高いのに、なぜ巨大なスキルが必要なのか疑問

    • モデルが事前学習の知識を自力で活用してくれるはずだという期待は理解できるが、後段の学習フェーズで事前学習データがかなり混ざってしまうようだ
  • LLMの生成文にThe Economistスタイルガイドを適用するスキルを作った: https://github.com/TAJD/economist-style-guide-plugin
    比較的構成がよく、編集しやすい文章を作ってくれる

  • STEの誤用と限定的な導入について: https://en.wikipedia.org/wiki/Simplified_Technical_English#M...

    • 批判資料の「STEで正しく書くには、優れた英語力とその主題に関する十分な知識が必要だ」という一文が印象的だった。これはSTEの有無に関係なく、あらゆる分野で良い英語ライティングに必要な条件にすぎない
    • LLMは翻訳が得意なので、この種の文章作成は特に得意であるはず。実際、ここ1週間すべてのプロンプトに適用してみたが、文体の無駄を削るのに効果的で、過剰な重複修飾表現もまったく見なかった
  • アイデアは気に入っているが、スキル自体には確信が持てない。代わりに https://vale.sh といくつかのリンターを見つけたので試してみるつもり

    • STEはすでに学習データに含まれているので、スキルは重複であり、コンテキストウィンドウを汚すだけ
    • LLMのドキュメント作業でValeをどう活用できるのか気になる
  • やり過ぎに見え、システムプロンプト1行で十分うまく動く: 「出力トークンは貴重なので簡潔に答え、ASD-STE100簡易技術英語を使え」

    • 実際に継続してうまく動くのか気になる。ユーザープロファイルと CLAUDE.md にルールを追加しても、結局モデルは脱線して docstring や説明に技術専門用語を大量に吐き出した
      コード説明をもっとやさしく単純にする方法なら何でも試したいので、これにも期待している
  • READMEからして「曖昧な文1つのせいで読者が死ぬかもしれない人たちが1983年に書いた9章53規則」みたいなLLM特有の文体がそのまま出ていて皮肉。ライティングスキルとしてはあまり有望な兆候ではない

    • その点は認めるが、READMEの文体が本当に気に入らない。「このREADMEは規則の半分を破っているが、マーケティングは明示的にSTEの範囲外であり、スキルはそれを理解して文書内にとどまる」「マーケティング文句、ブログ文体、ブランドライティングは拒否し、意図的に平板に書く」といった具合
      各文にはHNで削除された絵文字まで付いていた
    • しばらく普通の ASD-STE100 プロンプトを使ってみたところ、エージェントの簡易英語は少し好みに近づいたが、文章の全体構成までは変えられない
      文は短くなり、大げさな導入やプレゼン資料のように空疎な節見出しは減って、品質はかなり良くなるが、画期的ではないし問題を完全に解決するわけでもない
    • READMEは簡潔で正確に見え、実際に試してみてもよく動く。周囲で見た多くの人が書いたREADMEよりは良い
  • 標準の Issue 9 の最初の例からして自己矛盾している。Test は承認された名詞だが動詞としては承認されていないのに、STEの例文は「Test B is an alternative to test A」だ
    STE専用ルールを知らなければ明らかに曖昧な文で、明確さとは程遠い。公式サイトがGoogle Formの奥にダウンロードを隠していたので、直接取得できるリンクも置いておく: https://www.asd-ste100.org/assets/files/ASD-STE100_ISSUE9.pd...

    • 何が曖昧なのか分からない。前の Test を動詞として読むには、「BがAの代替かどうかを試験せよ」で that が省略されていると見なさなければならないが、前では動詞で後では名詞なので並列性が崩れている
      しかも、誰かにそうした行動を指示する解釈自体がかなり考えにくい
  • ASD-STE100 が急に注目されているのはバズったツイートのせいなのか気になる。友人に聞いて、数日前に仕様書を上げておいた: https://asd-web-be-prod.azurewebsites.net/media/wunhmi5y/asd...
    PDFのコピーが禁止されているが、簡単に回避できるのに、なぜそうしたのか不思議。許可されていない単語を防ぐには、英語向けの ruff のようなリンターが必要で、そうでなければエージェントは1行の指示などほぼ確実に忘れる

  • こうした指示がモデルの知能や思考能力にどんな影響を与えるのか気になる。出力や思考過程を変えるなら、モデルの能力も変わり得るし、特に学習中にこうした言語を使うよう訓練されていなければなおさらそうかもしれない

    • 指示として与えるより、後処理レイヤーとして実装すべきだと思う
  • https://youtu.be/uJblcC4lKYw では、STEスキルなど複数のスキル・プロンプトとGeorge Orwellの文章作法6原則を比較評価しており、総合的にはOrwellが最も良い結果を出していた
    入力コンテキストに追加されるトークンも多くなく、この規則を適用した散文プロンプトと適用しないものを比べてみると、結果が気に入った。使い古された比喩を避け、短い語で足りるなら長い語を使わず、削れる語は削り、受動態より能動態を使い、日常語があるなら外国語や科学用語・専門用語を避け、野蛮な文を書くくらいならこれらの規則を破れ、という内容だ

    • AIの文章を読み過ぎたせいかもしれないが、動画のナレーション原稿も、この規則を1つも適用していないClaudeが書いたように聞こえる
      「正直に言うと翻訳の改善は本物だったが小さかった」「ここからが正直な部分だ」「同じ病気だが症状が違う」「あの残酷な3%という数字は自然法則ではなくClaudeの特性だった」といった、決まり文句やAI特有の表現が多すぎる