世界を動かす技術を、日本語で。

ASD-STE100 簡易技術英語における文書強制のためのエージェントスキル

2026年7月31日原文(github.com)

概要

  • ASD-STE100 は航空宇宙分野で使われる 制御言語規格
  • AIエージェント にこの規格を適用するスキルの紹介
  • 導入方法効果ルール の要点を解説
  • マーケティング文書 には適用不可、技術文書専用
  • ベンチマーク での効果やFAQも網羅

AIエージェント向け「ASD-STE100 Simplified Technical English」スキル概要

  • ASD-STE100 は1983年から航空宇宙業界で標準採用
  • 曖昧な表現長文 を排除し、誤読を防止
  • AIエージェント が技術文書を 簡潔かつ明確 に作成
  • Claude CodeCursorVS Code CopilotOpenAI CodexGemini CLIGooseOpenCode など25以上のツール対応
  • インストール は1フォルダ、 依存関係なしMITライセンス

インストール手順

  • コマンドラインで npx skills add AminBlg/SimpleEnglish を実行
  • skills CLI が対応エージェントを自動検出
  • 試用npx skills use AminBlg/SimpleEnglish@simple-english で可能
  • SKILL.md を手動でシステムプロンプトやカスタムインストラクションに貼り付けて利用可能
  • claude.ai の場合、 Settings → Capabilities → code execution をONにし、 Skills からスキルファイルをアップロード

適用範囲と制限

  • 技術文書エラーメッセージ運用手順書インシデントレポートリリースノート に適用
  • マーケティング文書ブログブランドライティング には適用不可
  • システムプロンプト翻訳前処理 にも有効

ASD-STE100主なルール(抜粋)

  • 1文20語以内 (説明文は25語まで)
  • 単語ごとの意味 を統一、 全体でチェック
  • 時制は単純形のみ受動態禁止進行形禁止
  • 主語+動詞能動態 で記述
  • 命令文は1文1指示
  • 条件は文頭 に記載
  • 助動詞should/would/may/might禁止 (can, will, mustは可)
  • 曖昧な表現冗長な修飾 を排除

効果・ベンチマーク

  • STE違反率 が平均 72.9%減少 (6モデル×8タスク×2条件で評価)
  • 出力トークン数 も全モデルで減少
  • 平均文長 は11.2語→9.7語に短縮
  • 曖昧な副詞 (例:「seamlessly」)は排除
  • 再現性 のある評価手法と TDD で開発

FAQ(よくある質問)

  • ASD-STE100認証出力か?
    • 公式認証は存在せず、ルール準拠の実装
  • 文章がロボットのようになるか?
    • Airbusマニュアル のように 誤読不能 な明確さ
  • なぜこの規格?
    • 40年以上維持 され、 明確な仕様テスト性 を持つため
  • マーケティングやブログには?
    • 適用不可技術文書専用

ライセンスと注意事項

  • MITライセンス
  • ASD-STE100ASD の登録商標
  • 非公式プロジェクトASDやSTEMG非公認
  • 公式規格や辞書内容は含まず、パラフレーズのみ使用

技術文書出力例(Before / After)

  • Before: 曖昧な表現や冗長な説明
  • After: ASD-STE100準拠 の短く明確な文
  • :
    • Before: "Leveraging sqlpipe's robust architecture, users can seamlessly synchronize their Postgres tables to S3 with minimal configuration overhead."
    • After: "sqlpipeはPostgresテーブルをS3にコピーする。1つの設定ファイルが必要。開始前にAWS認証情報が正しいか確認。"

まとめ

  • ASD-STE100 スキルは 技術文書の誤読防止 に最適
  • AIエージェント の出力品質を 大幅に向上
  • 導入簡単幅広いプラットフォーム対応
  • 技術文書の標準化多言語展開 にも有効

Hackerたちの意見

READMEがLLMによって書かれたっていうのが皮肉だよね。> 53のルール、9つのセクション、1983年に読者が曖昧な文で死ぬ人たちによって書かれた。重労働をしているのは… 書き方のスキルとしてはあまり期待できないと思う。

READMEは簡潔で正確に見えるよ。試してみたけど、ちゃんと動く。周りの人が書いたREADMEよりもずっと良いと思う。

それは認めてるけど、READMEのスタイルが本当に嫌いだな。> はい、このREADMEはその半分を破っています。マーケティングはSTEの範囲外です。スキルはそれを知っていて、ドキュメントに留まっています。> 行かないところ: マーケティングコピー、ブログの声、ブランドライティング。わざとフラットにしてある。(そこにある各文にはHNがカットする絵文字が付いてる)

それに関連して、経済学者のスタイルガイドをLLM生成の文章に適用するスキルを作ったよ。https://github.com/TAJD/economist-style-guide-plugin これを使うと、編集しやすい構造の良い文章ができる傾向がある。

一つの例(「sqlpipeの強力な...」)を取って、これを前に付けただけだよ。> これをASD-STE100の簡略化された技術英語で書き直してみて: そしたら、まあまあの結果が得られるみたい?ガイダンス用にもう一文か二文追加してもいいけど、ASD-STE100がトレーニング資料に入ってたのに、なんでこんな巨大なスキルが必要なんだろう?

モデルが事前学習の知識をうまく活用すべきだって感じるのはわかるけど、事前学習データが後の段階でかなり混乱してるみたいだね。

アイデアは好きだけど、そのスキルにはまだ納得できてない。でも、https://vale.sh とそのいろんなリンターを見つけるきっかけにはなった。試してみるかも。

これは無駄なものだね。[1] これを使える人は誰も必要ないよ—せいぜいプロンプトの一行だね。 [1] https://knowyourmeme.com/memes/thinking-quickly-dave-constru...

https://www.npmjs.com/package/is-odd

この説明に合わない「エージェントスキル」を見たことがないな。

「ASD-STE100 簡略技術英語のみ出力」というプロンプトは、スキルと同じことをするよ。でも、すごく便利だし、スキルはプロンプトを共有するのにいい方法だから、どっちでもいいよ。スキルかプロンプトを試してみて。エージェントとのやり取りがもっと良くなると思う。

私はエージェントの設定に「過度な熱意はなしで、マーケティングも控えてください。それに、ADHDがあるからすぐに気が散るんです」と書いてるんだけど、これで返答がずっとわかりやすく、要点がまとまったものになったよ。

Hacker Newsで議論の続きを見る