ニュース

ASD-STE100とは？AIの文章癖を航空規格で直すAgent Skill解説

2026.07.31 公開 16分で読める

この記事の結論

HN発のAgent Skill「SimpleEnglish」を解説。ASD-STE100 Simplified Technical Englishで文書を矯正する仕組み、実測値、日本企業での検証手順まで。

この記事でわかること：Hacker Newsで話題になった「Agent Skill to Force Docs in ASD-STE100 Simplified Technical English」は、AIエージェントが書くドキュメントを航空宇宙業界の管制言語規格「ASD-STE100」に強制的に従わせるオープンソースのAgent Skill（AminBlg/SimpleEnglish）です。「seamlessly」「robust」のようなAI特有の水増し表現を構造的に排除し、リポジトリの実測では6つのClaudeモデル平均でSTE違反が72.9%減少したと報告されています。この記事では、公開されたスキルの中身、ASD-STE100という規格の背景、日本企業のエージェント運用への示唆、そして5分で始められる検証手順までを一次情報ベースで解説します。

「AIに書かせたREADMEやランブックが、どうにも中身の薄いマーケティング文書みたいになる…」

Claude CodeやCursorでドキュメント生成を運用していると、必ずぶつかる悩みです。実際に検証環境でエージェントにREADMEを書かせてみると、「robust」「seamlessly」「leverage」といった形容詞まみれの文章が量産され、レビューで全部書き直しになったことが何度もあります。

2026年7月21日に公開されたAgent Skill「SimpleEnglish」は、この問題に対して意外な角度から答えを出しました。40年前から航空機の整備マニュアルで使われてきた管制言語規格を、そのままAIの文体矯正に転用したのです。Hacker Newsでは公開から数日で166ポイントを超えて注目を集め、賛否含めて活発な議論になっています。順に見ていきましょう。

何が公開されたのか：SimpleEnglishスキルの概要

リポジトリの基本情報

まずファクトを整理します。以下はGitHubリポジトリとGitHub APIで確認した情報です（参照日: 2026-07-31）。

項目	内容
リポジトリ	AminBlg/SimpleEnglish
公開日	2026年7月21日
ライセンス	MIT
形式	Agent Skills標準（SKILL.md）準拠のスキルフォルダ
対応環境	Claude Code、Cursor、VS Code Copilot、OpenAI Codex、Gemini CLI、Goose、OpenCodeなどAgent Skills標準対応ハーネス
依存関係	なし（1フォルダのみ）
スター数	約330（2026年7月31日時点）

スキルの中身は、ASD-STE100の執筆ルールをソフトウェアドキュメント向けに言い換えた指示書です。重要な点として、リポジトリは規格本文や公式辞書の内容を一切転載しておらず、ルールを教育目的でパラフレーズした非公式プロジェクトであると明記されています。ASDやSTEMG（規格の管理団体）の公認・提携プロジェクトではありません。

Before/Afterで見る効果

リポジトリに掲載されている実例が、このスキルの狙いを最もよく表しています。左が素のClaude出力、右がスキル適用後です。

スキルなし	スキルあり
「sqlpipeの堅牢なアーキテクチャを活用することで、ユーザーは最小限の設定オーバーヘッドでPostgresテーブルをS3にシームレスに同期できます…」	「sqlpipeはPostgresのテーブルをS3にコピーします。設定ファイルは1つ必要です。開始前にAWS認証情報が正しいことを確認してください。正しくない場合、S3は権限エラーでアップロードを拒否します。」
「おっと！接続の確立中に問題が発生しました。認証情報が正しく設定されていることを確認して再試行するか、問題が続く場合は管理者にお問い合わせください。」	「データベースへの接続が失敗しました：ユーザー`app`のパスワードが正しくありません。`DB_PASSWORD`を正しい値に設定してから、再度接続してください。」
「一部のユーザーのサービスアクセスに影響を与えた可能性のある問題を確認いたしました。ご不便をおかけしたことを深くお詫び申し上げます。」	「14:02から14:31 UTCの間、リクエストの12%が失敗しました。14:00のデプロイがキャッシュウォームアップ手順を削除していました。14:27にリバートしました。」

ポイントは、単に「短くなった」のではなく、謝罪や装飾が消えて、実行可能な情報だけが残っていることです。エラーメッセージは「何が起きた→なぜ→どうする」の順になり、インシデント報告は曖昧な「影響を与えた可能性」が具体的な数字と時刻に置き換わっています。これは後述するSTEのルールが機械的に強制した結果です。

ASD-STE100とは何か：1986年から続く管制言語

航空機整備の現場が生んだ規格

ASD-STE100 Simplified Technical English（STE）は、技術文書を書くための制限言語（controlled natural language）の国際規格です。管理団体STEMGの公式サイトによると、その歴史は次のとおりです（参照日: 2026-07-31）。

1970年代後半、欧州航空機産業協会（AECMA、現ASD）が欧州の航空会社の要請を受けて開発を開始
1986年に「AECMA Simplified English Guide」として最初のガイドを公開
2005年に国際仕様（international specification）となる
2025年に国際規格（international standard）「ASD-STE100」となり、最新版のIssue 9が2025年1月15日に発行

もともとの目的は、英語が母語でない整備士でも航空機の整備マニュアルを誤読しないようにすることでした。整備マニュアルの誤読は文字どおり人命に関わるため、「曖昧に読める文を書けない」ように言語仕様そのものを制限したわけです。規格の正式コピーは公式サイトから無償でリクエストできます。なお「ASD-STE100」はASD（欧州航空宇宙・安全保障・防衛産業協会）の登録商標です。

代表的なルール：AIの悪癖と1対1で対応する

STEの執筆ルールのうち、SimpleEnglishスキルが特に効かせているものをリポジトリの整理に沿って挙げます。右列を見ると、AIが生成する文章の「あるある」とほぼ1対1で対応していることがわかります。

STEのルール（スキルでの言い換え）	排除されるAIの悪癖
指示文は最大20語、説明文は最大25語	読点でつなぎ続ける長文
1つの単語には文書全体で1つの意味だけを与える	check / verify / confirm / validate の無自覚な混用
単純時制のみ使用	「has been updated」のような回りくどい完了形
能動態で書く	「it should be noted that」型の責任者不在文
should / would / may / might を禁止（can / will / must は許可）	ヘッジ（逃げ）表現
条件は命令の前に置く	「…if the flag is set」と末尾に条件が来て読者が実行後に気づく文
1文につき指示は1つ	深夜2時のオンコール担当者が追えない複合手順

面白いのは、この規格が2026年のAIブームとは無関係に、40年前から「疲れた読み手でも誤読できない文」を目指して磨かれてきたことです。結果として、AIの生成文が持つ冗長さ・曖昧さ・ヘッジ癖の、ほぼ完全なネガ（裏返し）になっていました。スキル作者はこれを「AI slop dies as a side effect（AIスロップは副作用として死ぬ）」と表現しています。

「write clearly」ではダメなのか：スキル設計の考え方

「明確に」は意見、「20語以内」は仕様

「プロンプトに『簡潔に書いて』と足せば済むのでは？」という疑問は当然出てきます。リポジトリのFAQは、これに対して明快な整理をしています。

「clearly（明確に）」は意見であり、モデルの解釈次第でブレる
「1文20語以内」「should禁止」「条件は命令の前」は仕様であり、機械的に検証できる
エージェントは意見よりも仕様に従う

これはドキュメント生成に限らず、エージェント設計全般に効く視点です。実際、リポジトリは「AGENTS.mdやシステムプロンプト自体をSTEで書く」という応用も提示しています。システムプロンプトは「質問できない読み手のための手順書」であり、モデルは「should」を任意事項として読む傾向があるため、STEが「should」を禁止していることには実務上の意味がある、という理屈です。長文ポリシーがエージェントを縛れない問題はHANDBOOK.md解説｜長文ポリシーはエージェントを縛れないでも扱いましたが、「形容詞を仕様に置き換える」というアプローチは同じ問題への別解といえます。

リポジトリ公表のベンチマーク

リポジトリには効果測定の結果が公開されています。これはスキル作者による自己報告値であり、第三者検証ではない点に注意した上で、方法論ごと見ておきましょう。

測定対象：Claudeの6モデル × 8種類の執筆タスク × スキルあり/なしの2条件 = 96回の生成
測定方法：決定的な正規表現ベースのリンターで100語あたりのSTE違反数をカウント（両条件で同一ルール）
結果：スキルありでSTE違反が平均72.9%減少。6モデルすべてで出力トークン数も減少。平均文長は11.2語から9.7語に短縮

モデル	ベースライン違反/100語	スキルあり違反/100語	削減率
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%

評価スクリプト（evals/run_bench.py）はリポジトリに同梱されており、ログイン済みのClaude Code CLIがあれば自分の環境で再実行できます。ベンチマークを鵜呑みにせず再現手段が用意されている点は、検証する側としてはありがたい設計です。エージェント出力の品質を機械的に測る考え方自体は、AIエージェント品質評価ガイド｜5ステップで始めるテスト自動化で解説した評価パイプラインの構図とそのまま重なります。

もう1つ、リポジトリの開発過程の記録に重要な示唆があります。スキルなしのエージェントにSTEで書かせようとしたところ、40語の文を書いた上に存在しないルール番号を捏造した（「Rule 3.1: 短文化」と自信満々に引用したが、実際のRule 3.1は動詞の形に関する規則だった）と報告されています。「モデルは規格名を知っているが、規格の中身は正確に運用できない」という、エージェント実務者にはおなじみの現象です。

コミュニティの反応：Hacker Newsでの論点

公開後のHacker Newsのスレッドでは、スキルそのものの評価が割れました。主な論点を整理します（以下はコミュニティの意見であり、検証済みの事実ではありません）。

懐疑派：「これを使いこなせる人には不要。プロンプトに1行『ASD-STE100で書け』と足せば十分」という指摘が複数。実際に例文の前に1行付けるだけで「十分良い結果」が得られたという報告もありました。
擁護派：「CLAUDE.mdやユーザープロファイルに指示を書いても、モデルは結局ドリフトして専門用語まみれに戻る」という実運用の悩みからスキルに期待する声。また「スキルの価値は、指示・詳細ポリシー・トラブルシューティング・ヘルパースクリプトを1パッケージに束ねられること」という構造面の評価。
運用ノウハウ：「スキルを作る→エージェントに使わせる→ミスを観察する→そのミスへの警告をスキルに追記させる」という反復改善プロセスで、素のプロンプトより良い結果になるという実践者のコメント。ただし「LLMにスキルを書かせると冗長で説教くさくなりがちで、人間が書いた短いものの方が効くことが多い」という注意も添えられていました。
ドリフト問題：「モデルはすぐに逸脱する。Gitのコミットフックでドキュメントにリンターをかける方が確実」という、強制手段をプロンプト層ではなくCI層に置くべきだという意見。

正直に言うと、この議論はSimpleEnglish固有というよりAgent Skillという仕組み全体への評価軸です。「1行プロンプトで足りるか、構造化されたスキルが必要か」は、タスクの複雑さと運用期間で答えが変わります。単発のリライトなら1行で足り、チーム全員のエージェントに数カ月間同じ文体を守らせたいならスキル+リンターの組み合わせに分があります。

日本企業のエージェント運用にどう関係するか

直接効く場面：英語ドキュメントを書くエージェント

日本企業でも、次のような場面ではこのスキルがそのまま使えます。

OSS・海外向けプロダクトのREADME/APIドキュメント：非ネイティブが書く英語ドキュメントこそSTEの本来の得意領域です。STEはもともと翻訳・ローカライズのコスト削減も目的に含んでいます。
ランブック・障害対応手順書：リポジトリが指摘するとおり、ランブックは構造的に整備マニュアルそのものです。深夜のオンコールで誤読されない手順書、という要件はSTEの設計思想と完全に一致します。
エラーメッセージ・インシデント報告の英文テンプレート：「何が起きた→なぜ→どうする」の順序強制は、グローバル展開しているSaaSのステータスページ運用にそのまま応用できます。

注意点：日本語ドキュメントには「そのまま」は使えない

一方で、過度な期待は禁物です。ASD-STE100はあくまで英語の規格であり、語彙制限や文法規則は日本語に直接適用できません。「1文の長さ制限」「1文1指示」「条件を先に書く」「用語の1対1対応」といった構造ルールの思想は日本語の技術文書にも輸入できますが、それはこのスキルをインストールすれば済む話ではなく、自社の日本語スタイルガイドをスキル化する作業になります。

むしろ日本のエージェント実務者にとっての本質的な学びは、次の3点だと考えています。

文体は「お願い」ではなく「検証可能な仕様」で縛る。「わかりやすく」ではなく「1文40字以内」「二重否定禁止」のように書く。
既存の成熟した規格を探してから自作する。40年分の改訂を経た規格は、ゼロから書くスタイルガイドより網羅的です。日本語ならJIS Z 8301（規格票の様式）やテクニカルコミュニケーター協会のガイドラインなど、参照できる資産があります。
スキル+リンターの二段構えにする。生成時にスキルで誘導し、CIで機械検証する。SimpleEnglishが正規表現リンターを同梱しているのは、この二段構えの実装例です。

導入・検証の始め方

インストール（5分で完了）

Agent Skills標準対応の環境なら、skills CLIで1コマンドです。

# インストール（対応エージェントを自動検出して選択インストール）
npx skills add AminBlg/SimpleEnglish

# インストールせずに試す場合
npx skills use AminBlg/SimpleEnglish@simple-english

動作環境: Node.js（npx実行可能な環境）+ Claude Code / Cursor / Codex / Gemini CLI等のAgent Skills対応エージェント。SKILL.md非対応の環境では、リポジトリ同梱のprompts/system-prompt.mdをシステムプロンプトやAGENTS.md、.cursorrulesに貼り付ける方式が用意されています（約60トークンの短縮版もあり）。

注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

CLIを使わない場合（claude.ai / ChatGPT / Gemini）

ブラウザ版でも使えます。リポジトリの案内によると次のとおりです。

claude.ai（有料プラン）：SKILL.mdファイルを保存し、Settings → Capabilitiesでコード実行を有効化 → Settings → Customize → Skills → Uploadからアップロードしてトグルをオンにする
ChatGPT：スキル機能がないため、prompts/system-prompt.mdの内容をCustom InstructionsまたはProject / Custom GPTのinstructionsに貼る
Gemini：Gemを作成して同じプロンプトブロックをinstructionsに貼る

自社での検証手順（3ステップ）

導入判断の前に、次の手順で自社のユースケースに効くかを確かめることをおすすめします。

自社の実ドキュメントでBefore/Afterを取る：直近のREADME・障害報告・リリースノートから3本選び、スキルあり/なしでリライトさせて並べる。リポジトリのサンプルではなく自社文書で見るのが重要です。
同梱ベンチマークを回す：python3 evals/run_bench.pyで、自分が使うモデルでの違反削減率を測る。公表値の72.9%が自分の環境でも出るかは、実測しないとわかりません。
禁止語がドメイン用語と衝突しないか確認する：STEの語彙制限は汎用の技術文書を想定しています。デフォルトはドメイン語彙を許容するプラグマティックモードですが、厳格モードでは自社の必須用語が弾かれる可能性があるため、用語集と突き合わせてください。

【要注意】よくある失敗パターンと回避策

失敗1：「STE認証されたドキュメント」と誤解する

❌ スキルを通した文書を「ASD-STE100認証済み」として顧客に提示する
⭕ 「STEの構造ルールを参考にした社内スタイル」として扱う

なぜ重要か：リポジトリのFAQが明言するとおり、ASDはいかなるツールも認証しておらず、このスキルの出力は認証品ではありません。厳密な語彙レベルの判定は公式規格（無償リクエスト可）を参照する必要があります。契約文書や規制対応でSTE準拠を謳う場合は、公式規格と有資格のSTEトレーナーによるレビューが別途必要です。

失敗2：マーケティング文書やブログにまで適用する

❌ 全社の文章生成にスキルを常時適用する
⭕ ドキュメント・ランブック・エラーメッセージに限定して適用する

なぜ重要か：STEは意図的に「フラットで誤読不可能な文」を作る規格です。リポジトリ自身が「マーケティングコピー、ブログの文体、ブランドライティングには適用を拒否する」設計だと明記しています。LP文言や採用広報に適用すると、単に魅力のない文章ができあがります。

失敗3：スキルだけ入れてドリフトを放置する

❌ スキルをインストールして満足し、その後の出力をチェックしない
⭕ 同梱リンター（またはtextlint等の自前ルール）をCIに組み込み、継続的に違反数を監視する

なぜ重要か：HNのコメントでも指摘されていたとおり、モデルは長いセッションで指示から逸脱（ドリフト）します。プロンプト層の誘導とCI層の強制は役割が別物です。エージェントの挙動を仕組みで縛る設計はClaude Agent SDK サブエージェント実装ガイドで扱ったフック・権限設計と同じ発想で、「守らせたいルールは検証可能な形でシステム側に置く」が原則です。

まとめ：今日から始める3つのアクション

今日やること：npx skills use AminBlg/SimpleEnglish@simple-englishで、自社の英語README1本をリライトさせてBefore/Afterを比較する
今週中：ランブックかエラーメッセージのテンプレートに適用範囲を広げ、同梱のevals/run_bench.pyで自環境の違反削減率を実測する
今月中：効果があれば、STEの構造ルール（文長制限・1文1指示・用語の1対1対応）を参考に日本語ドキュメント用の自社スキル+リンターを設計する

「AIの文章癖」という2026年の問題に、1986年生まれの航空規格が最も鋭い解答を持っていた、というのがこのニュースの面白さです。形容詞で文体を注文するのをやめて、検証可能な仕様で縛る。ドキュメント生成に限らず、エージェント設計全体に持ち帰れる教訓だと感じています。

参考・出典

AminBlg/SimpleEnglish – GitHub — スキル本体・ベンチマーク・FAQ（参照日: 2026-07-31）
ASD-STE100 公式サイト（STEMG） — 規格の歴史・Issue 9（2025年1月15日発行）の情報（参照日: 2026-07-31）
ASD-STE100 公式コピーの無償リクエストページ — 規格本文の入手方法（参照日: 2026-07-31）
Agent Skill to Force Docs in ASD-STE100 Simplified Technical English – Hacker News — コミュニティの反応（参照日: 2026-07-31）
vercel-labs/skills – GitHub — インストールに使うskills CLI（参照日: 2026-07-31）

この記事を読んで導入イメージが固まってきた方へ

UravationではAIエージェント導入の研修・コンサルを行っています。

Need help moving from reading to rollout?

この記事を読んで導入イメージが固まってきた方へ

Uravationでは、AIエージェントの要件整理、PoC設計、社内導入、研修まで一気通貫で支援しています。

30分無料相談を予約支援実績を見る

※ 本記事の情報は2026年7月時点のものです。サービスの料金・仕様は変更される可能性があります。最新情報は各サービスの公式サイトをご確認ください。

ASD-STE100とは？AIの文章癖を航空規格で直すAgent Skill解説