STE80 Humanizer: AI テキストを自然な人間風と構造化された技術英語へ変換するツール

STE80 Humanizer は、AI が生成した文章の内容を変更せずに、読み手が「慎重な人間が書いたもの」と感じるようにするための処理ツールです。本ツールは以下の 2 つの手法を組み合わせて動作します。

• Humanizer 手法: Wikipedia の「AI 書式の兆候（Signs of AI writing）」で挙げられている 26 の特徴をすべて排除します。
  • 実装参照：

    blader/humanizer

    カタログ（Siqi Chen）。
• Karpathy の STE80 手法: 航空機整備マニュアルで使用される制御言語 ASD-STE100 に至る道のりの「80% まで」、文書構造を再構築します。

目標： 人々が容易に読みやすい文章を作ることです。AI 検出器を回避することが目標ではありません。

---

なぜ 2 つの処理（Passes）が必要なのか

多くの Humanizer ツールは単に単語やフレーズを削除するだけの「文字面での修正」で留まります。これでは構造的な問題（長い文、主語の不明瞭さなど）が残ったまま AI 由来の文章のままになってしまいます。

ステップ	残された要素・状態
Before（処理前）	チャットボットのオープニング、ダッシュ記号、「〜ではないが〜である」という構成、不確実性を示す修飾語の羅列など。
1 度目の処理後（兆候除去）	「言葉自体は清潔」ですが、文章構成が重くなります。（例：「不良なプローブ設定は連鎖的な再起動を引き起こす可能性がありますので、パラメータを慎重に調整する必要があります。」）
2 度目の処理後（STE80 化）	短い文調、一文で一つの意味、能動態、記述と指示を分けた構造などに整います。

---

手法の背景：Andrej Karpathy の提言

2026 年 10 月 2 日、Andrej Karpathy は「LLM が生成する内容を理解する時間を確保する方法」として以下の提言を行いました。

「LLM に ASD-STE100 で何かを説明させるように依頼してください。」

• ASD-STE100 は当初、航空宇宙分野の保守ドキュメント用に開発された制御言語です。
• 厳格なスタイル制約があるため、多くの場合「より読みやすい」出力になります。
• 仕様自体が厳しいため、「ASD-STE100 に至る道のりの 80%」を求めて少し和らげるアプローチも検討しました。

スキル実装における注意点（辞書の誤り）

Karpathy の引用された STE 概要図には事実確認のミスを発見しています。ASD-STE100 第 9 版 では以下のルールが適用されます。

• approximately

  は承認されています。

• TEST

  は名詞としては承認されますが、動詞としては承認されません。

• in order to

  のエントリはありません。

※本スキルでは第 9 版に従います。

なぜ「80%」なのか？

100% のモード（厳格モード）では、

check

や

test

は名詞のみに制限され、

may

/

should

が禁止されるため、「通常の散文（プロース）」のように読めず硬く聞こえてしまいます。 一方、80% のモード（デフォルト） では、完全な文構造を維持しつつ、依然として自然に聞こえる程度の語彙を使用します。

STE ルール	100%（厳格モード）	80%（デフォルト・本スキル）
文の長さ (20/25 語)	絶対上限	数語程度オーバーしても可
一文に一つの意味	常時遵守	常時遵守
能動態・単数形	常時遵守	常時遵守
承認済み辞書のみ使用	はい	いいえ、一般的な単語を使用可
「check」「test」を動詞として	いいえ	はい
「may」「should」の用法	いいえ	はい、真の不確実性を示す場合
縮約形（例：don't）	いいえ	はい、カジュアルな文章の場合

---

スキルの読み方と構成要素

SKILL.md

には番号付きリストが 2 つ定義されています。

1. §1 から §26: AI の兆候を排除するルール（Pass 1）。
2. S1 から S15: STE80 の構造化ルール（Pass 2）。

各項目は「Watch for（注意）、Problem（問題点）、Before（処理前）、After（処理後）」という共通フィールドを持っています。Pass 2 の項目では、80% モードと Strict モードの違いも明記されています。「Weak（弱い）」という言葉単独で指定されている場合、他の兆候が近い場合にのみ対応します。 スキルは編集内容を番号で報告するため（例：

§1, §8, S2

）、各項目を個別に確認できます。

---

インストール方法

インストール済みの場合は

/ste80-humanizer

コマンドで利用可能です。また、以下のキーワードが含まれると自動起動します。

• 「テキストの人間化」「単純化」「AI 除去」
• STE のリクエスト

すべてのエージェント向け（skills.sh）

npx skills add Dodaios/ste80-humanizer

特定の 1 つのエージェント全体、またはすべてのエージェントへグローバルにインストール:

npx skills add Dodaios/ste80-humanizer --global --agent claude-code
npx skills add Dodaios/ste80-humanizer --global --agent codex
npx skills add Dodaios/ste80-humanizer --global --agent cursor
npx skills add Dodaios/ste80-humanizer --global --agent '*'

• --global

  オプションなしの場合、スキルは現在の実行プロジェクトのみにインストールされます。
• Vercel の CLI は、Claude Code、Codex、Cursor、OpenCode および多くの他のエージェントと動作します。

Claude Code プラグイン

/plugin marketplace add Dodaios/ste80-humanizer
/plugin install ste80-humanizer@ste80-humanizer

Claude.ai と Claude Desktop

1. このリポジトリを ZIP ファイルとしてダウンロード（Code → Download ZIP）。
2. Settings → Capabilities → Skills でアップロードします。

---

使用方法

基本コマンド：

/ste80-humanizer <テキストを貼り付け>

または、直接問い合わせても構いません（例）：

• 「これは ChatGPT が書いたように聞こえます。人のようにはっきりさせください。」
• 「この README を ASD-STE100 への 80% の位置まで書き直してください。」
• 「TLS ハンドシェイクがどう機能するかを STE で説明してください。」
• 「軽度：docs/intro.md から AI の要素だけを取り除いてください（ライトタッチ）。」
• 「docs/runbook.md を厳格な STE に変換してください。」
• 「このメールは AI っぽいですか？ただ答えて、書き直さなくて大丈夫です。」

モード選択

モード	対象となるケース	動作内容
Humanize（デフォルト）	通常のリクエスト	Pass 1 を完全に行う、Pass 2 は 80% モード。あなたの文体を保ちます。
Light	「軽度」「AI の要素だけを取り除く」など	Pass 1 を実行し、Pass 2 では最も問題の多い文のみを処理します。
Strict STE	「厳格」「完全な STE」「手順書」「安全注意」など	Pass 1 と Pass 2 の両方を 100% モードで実行します。

文体調整機能: あなたの執筆サンプルを追加すると、スキルはその文長、単語選択、句読点をあなたに合わせて修正します。

真実性の優先。 このスキルは事実をすべて保持し、「may」や「40+」もそのまま維持します。追加の情報を入れないだけでなく、元の情報源の矛盾も指摘します。これは単純なプロンプトとの最も明確な差です（Tests 参照）。

---

Pass 1: AI の兆候 26 選と具体例

以下の表は、AI が生成する典型的な特徴を排除するルールとその前後例を示しています。

#	カテゴリ・兆候 (Tell)	Before（例）	After（例）
A. Stating instead of staging (結論先行ではなく事実提示)	1. Not X but Y 2. One-line closers 3. Sayings that sound deep 4. Staged run-up 5. Arguing with no one	It's not just a faster build tool, it's a new way to think. ...No cold starts. No excuses. At its core, observability is the language of trust. Let's dive in. To be clear, I'm not saying microservices are bad...	The build tool caches each step. Latency dropped to 40 ms. Shared dashboards show both teams the same data. The API allows 100 requests per minute. We split the billing service out first.
B. Rhythm by rule (リズムの規則化)	6. Forced triads 7. Repeated openings 8. Dashes everywhere 9. Stacked qualifiers 10. Hyphenated pairs 11. Passive, missing subjects	fast, intuitive, and powerful It reads... It checks... The migration — which took six weeks — is done. could potentially possibly cause The API is well-documented. No account needed.	loads in under a second It reads the config and checks the schema. The migration took six weeks and is done. can break The API is well documented. You do not need an account.
C. Inflation and borrowed authority (誇張と権威の借用)	12. Overused AI words 13. Inflated significance 14. Vague association 15. Shallow -ing riders 16. Sales language 17. Borrowed authority 18. Avoiding is / has	leverages a robust caching layer, showcasing... marks a pivotal moment in the project's journey The outage was linked to the DNS change. ..., highlighting its commitment to accessibility our groundbreaking, world-class editor Experts agree... featured in TechCrunch, Wired... serves as the central hub and boasts 40 options	caches API responses on the device adds a CLI and drops Node 16 The DNS change caused the outage. (削除) The editor runs inside VS Code. It was on the front page of Hacker News in May. holds the settings. It has 40 options.
D. Formatting by rule (書式の規則化)	19. Bold as decoration 20. Decorative headings 21. Curly quotes	Performance: Performance has been improved. ## 🚀 Getting Started With The CLI → "true"	The release makes pages load faster. ## Install the CLI "true"
E. Leftovers from chat (チャット・下書きからの残り)	22. Chatbot residue 23. Knowledge-limit hedges 24. Heading repeated 25. Writing about the document	Great question! ... I hope this helps! While details are limited, it was likely created around 2015. ## Security / Security is important. This function was added to replace the old approach...	(Wrapper を削除) The sources do not say. (行を削除) This function looks up users in a hash map.
F. Writing for wrong reader (対象読者不適切)	26. Re-explaining what the reader knows	A reply that walks through the whole diagnosis first	Agreed. I'll switch the job to UTC.

---

Pass 2: STE80 のルール 15 選とモードの違い

#	ルール (Rule)	80% モード vs Strict モード
S1	一文に一つの意味	80%：「and」や「because」で接続された 2 つの事実を許容
S2	短い文（指示文 20 語、記述文 25 語）	80%：数語程度オーバーしても可
S3	条件節を最初（「もし X なら、Y をする」）	両モードで同じ
S4	単語の省略禁止（the, a, that など）	80%：表や見出しでは断片化も可
S5	リストによる手順・複雑な内容の提示	両モードで同じ
S6	能動態	両モードで同じ
S7	単数形（現在時制・過去時制）のみ	両モードで同じ
S8	動詞の多用、名詞化禁止、「-ing」連続	Strict：「check」と「test」は名詞のみ
S9	正直な修飾語（can, must, will）	80%：真の不確実性には「may」「should」も使用可
S10	簡単な単語、一意の意味、複合動詞禁止	80%：自然な単語を使用可
S11	事物に一つの用語のみ	両モードで同じ
S12	3 語以上の名詞の羅列禁止	両モードで同じ
S13	パラグラフに一つのトピック、最大 6 文まで	両モードで同じ
S14	手順と記述は別扱い、警告を最初に出す	両モードで同じ
S15	シンプルな句読点、分点禁止	Strict：縮約形も禁止

• 詳細な例については

  references/ste80-rules.md

  を参照。
• 完全な Strict モードのルールとチェックリストは

  references/strict-mode.md

  にあります。
• 単語置換例は

  references/word-swaps.md

  にあります。

---

チェッカー（Checker）

scripts/ste_check.py

は依存関係のない小さな Python ラインタです。多くの Pass 1 の兆候と計測可能な Pass 2 のルール（文・段落の長さ、分点、ダッシュなど）を指摘します。 ※これはヒューリスティックなツールであり、AI 検出器でもコンプライアンスチェッカーではありません。

python scripts/ste_check.py README.md
python scripts/ste_check.py --strict docs/runbook.md
cat draft.txt | python scripts/ste_check.py -

---

テストと限界（Limits）

测试结果

evals/

フォルダには、Claude プラグインの評価フォーマットに従うケースがあります。

• README の書き直し
• ゼロから説明する文章作成
• Strict モードの手順書
• STE を言及しないカジュアルな LinkedIn ポスト

主な発見: プロンプトに ASD-STE100 と記述すると、ベースモデルはすでにスタイルの大部分を正しく捉えます。しかし、このスキルが真実性の面で差を生みました。

• スキルを使用しない場合：引用を作ったり、「40+ customers」を「40-odd」と変更したりする傾向があります。
• スキルを使用した場合：すべての事実を保持。

限界

1. 対象テキスト: STE は明確な説明テキストのために設計されています。小説、スピーチ、ブランディングコピーについては、Pass 1 のみを実行します。
2. 言語対応: STE は英語の基準です。他の言語についても兆候と構造化ルールは適用されますが、英語の単語リストは適用されません。
3. 準拠の定義: 「STE スタイル」とは「STE に準拠（compliant）している」という意味ではありません。準拠には公式な辞書、訓練を受けたライター、およびレビューが必要です。

---

ソースとクレジット

• Andrej Karpathy on X, 2026 年 10 月 2 日: https://x.com/karpathy/status/2105819303471976479
• ASD-STE100 Issue 9 (2025): https://www.asd-ste100.org
• Wikipedia, Signs of AI writing (WikiProject AI Cleanup)

• blader/humanizer

  by Siqi Chen (MIT). Pass 1 はその 26 パターンカタログと順序に従い、新しい例を加えています。ライセンス表記は LICENSE ファイルにあります。
• Hacker News の STE スキルに関する議論（2026 年 7 月）: https://news.ycombinator.com/item?id=49114639

免責事項

このスキルには ASD-STE100 仕様書やその辞書が含まれていません。STE ルールは要約・簡略化されています。ASD-STE100 および Simplified Technical English は、欧州航空宇宙・セキュリティ・防衛産業協会（AeroSpace, Security and Defence Industries Association of Europe）の登録商標です。本プロジェクトは ASD との関連性はありませんし、ASD による推薦でもありません。

ライセンス

MIT