asd-ste100-skillとは？使い方・できることを実際に使って調べてみた動いた

配布元: https://github.com/danyuchn/asd-ste100-skill 　／　2026-10-22 時点で確認

この日に実際に動かした結果です。内容の誤りに気づかれた場合はお問い合わせください。確認のうえ訂正します。

使う前に分かること

MCPのツールや、エージェント同士でやり取りするAPIを作っていると、説明文や返すメッセージを英語で書く場面があります。読むのは人間ではなく別のAIエージェントで、書いた側に「これはどういう意味ですか」と聞き返す相手もいません。一文が長くなったり、受け身の形で誰がやるのか書かなかったりすると、そこがそのまま誤読の種になります。

今回試したASD-STE100 Skillは、もともと航空機の整備手順書のために作られた統制言語のルールを、AIエージェント向けの英文に応用したものです。整備士は英語が母語でないことも多く、書いた人に確認する術もないので、1つの単語には1つの意味しか持たせない、受け身を避ける、1文に1つの指示だけを書く、といった規則で誤読の余地を削っています。この規則をそのままAIエージェント同士のやり取りに当てはめる、という発想です。

今回はエージェントに自然な日本語で依頼して、あいまいな英文を書き換えてもらうところと、その書き換えの根拠を対応表で見せてもらうところまで試しました。同梱の機械的なチェックで、書き換え前後の違反件数も数えています。npxを使わないClone方式でのインストールや、プロジェクトの説明文や変更履歴のような、やわらかい文章向けのモード（STE-flavored）は試していません。

Skillとして入れる

配布元が最初に案内している入れ方は、npx skills add を使ったクイックインストールです。プロジェクトのフォルダで1回打つだけで済みます。

npx skills add danyuchn/asd-ste100-skill

o  Repository cloned
o  Found 1 skill
o  Installation Summary --------------------------------------------------+
|  ./.agents/skills/asd-ste100                                            |
|    universal: Amp, Antigravity, Antigravity CLI, Cline, Codex +16 more  |
|    symlink → Claude Code                                                |
—  Done!  Review skills before use; they run with full agent permissions.

実体は .agents/skills/asd-ste100 に入り、.claude/skills/asd-ste100 からはシンボリックリンクで見える形になります。これでClaude Code側からSkillとして使えるようになります。配布元には、git cloneで手動コピーする方法も案内として載っていますが、そちらは「早道ではない方」の案内です。

曖昧な英文をエージェントに書き換えてもらう

社内で使うAPIのエラーメッセージという設定で、あいまいな英文をエージェントに渡しました。頼んだ文はこれだけです。

次の英文は、社内で使っているAPIのエラーメッセージなのですが、長くて複数のことを言っているので、何が起きた時にどうなるのか読み取りにくいです。これを読むのは別のAIエージェントなので、人間なら文脈で補える曖昧さも誤解のもとになります。

"The request could not be completed because the upstream service that handles billing returned a response that has been flagged as invalid, and depending on the retry policy that has been configured for this client, the SDK will either throw immediately or queue the request for a retry after a delay that increases each time, unless the maximum number of retries has already been reached, in which case the error is surfaced to the caller along with whatever partial result was obtained before the failure."

このSkillを使って、別のエージェントが読み間違えないように書き換えてください。書き換えた文だけを返してください。

すると、こう返ってきました。

The upstream billing service returned an invalid response. The SDK could not complete the request.

The SDK then checks the client's retry policy.

- If the retry policy does not allow retries, the SDK throws the error immediately.
- If the retry policy allows retries:
  - If the retry count is below the maximum, the SDK queues the request for a retry. Each retry waits longer than the previous retry.
  - If the retry count already equals the maximum, the SDK returns the error to the caller. The SDK also returns any partial result obtained before the failure.

元は1文85語に「失敗した理由」「リトライするかどうかの分岐」「上限に達した場合」の3つを詰め込んだ文でしたが、先に結果（請求サービスが無効な応答を返した）を言い切ってから、リトライ方針の分岐をリスト（さらにその中の入れ子のリスト）に展開する形になりました。元の文では「unless the maximum number of retries has already been reached」が「即座にthrowする方」と「キューに入れてretryする方」のどちらにかかるのか読み取りにくかったのが、書き換え後は上限のチェックが「リトライ方針がretryを許す」場合の中だけに置かれていて、即座にthrowする方にはかからないと一目で分かるようになっています。

書き換えの根拠を対応表で見る

どのルールに違反していたのかを知りたかったので、続けて表にしてもらうよう頼みました。

ありがとうございます。書き換えの根拠が知りたいので、どのルールに違反していたかがわかるように、元の文と書き換え後の文を対応させたdiffの形で教えてください。

返ってきたのは、10件の違反をルールごとに並べた表でした。一部を抜き出すとこうです。

表の末尾には、「厳しく読む方のモードを当て、同梱のlintに通すと元の文は8件（1件は『文が長すぎる』という重い指摘、残り7件は軽めの助言）、書き換え後は0件」という検証結果と、「already（上限判定の時点を示す語）とwhatever/any（部分的な結果が無くても構わないという無条件さ）はどちらも削らずに残した」という注記が付いていました。「may」のような確信度を示す言葉を壊さずに残す、という方針は今回の文には出てきませんでしたが、配布元の説明にはそう明記されています。

lintの誤検出が直った点を確かめる

同梱のPythonスクリプト（scripts/ste-lint.py）は、ASDの辞書を使わずに機械的にチェックできる規則だけを見るlintです。前回の検証時から、「may have runのような助動詞付きの完了形を、受け身や現在完了の違反として誤検出しない」という修正が入っていたので、自分の手で確かめました。

echo -n 'The task may have run.' > /tmp/hedge.txt
echo -n 'The task has run. The flag is set. The task is gone.' > /tmp/plain.txt
python3 scripts/ste-lint.py /tmp/hedge.txt
python3 scripts/ste-lint.py /tmp/plain.txt

0 violations (0 hard, baseline 0), 5 words, 0.0 per 100 words
Hedges/modality (may, might, could) are never flagged: confidence is content.

/tmp/plain.txt:1:10 present-perfect: Compound tense. Use simple past/present unless current relevance is the point (then keep and flag). [has run]
/tmp/plain.txt:1:28 passive-voice: Possible passive voice. Name the actor and use an active verb, unless the actor is unknown or irrelevant. [is set]

2 violations (0 hard, baseline 0), 12 words, 16.7 per 100 words

「may have run」は0件のまま変わりませんが、助動詞のない「has run」はそのまま現在完了の違反として検出され、「is gone」は（受け身ではない自動詞の過去分詞なので）違反として数えられませんでした。「is set」は変わらず受け身として検出されています。確信度を示す言葉を壊さずに、本当に直すべき箇所だけを見る、という狙い通りに動いていました。

配布元の説明にも、Skill自身の説明文（SKILL.md）をこのlintに通すと違反が出ると書かれています。長い文や受け身をわざと例として引用しているためです。これが「増えていないか」を見張るためのコマンドも配布元が案内しているので、打ち直しました。--baseline の数字は「これだけは元から織り込み済みの違反件数」という目印で、実際の件数がこれを超えなければ「新しく壊れていない」とみなせます。

python3 scripts/ste-lint.py --baseline 36 SKILL.md

今回は44件中36件がhardな違反でした。目印の36件と同じなので、新たに増えた違反はありません。前回確認した時点ではこの目印は41件でしたが、その後に入った「インラインコードの ` やリストの印、箇条書きの記号、GitHubの注意書きの記号を単語として数えない」という数え方の修正で、文の長さの違反の判定が正確になり、目印の数自体が36件まで減っていました。

まとめ

社内APIのエラーメッセージを1つ渡しただけですが、85語の1文が「結果→分岐の入れ子リスト」に組み直され、「unless」がどちらの分岐にかかるのかという、機械が読み違えそうな箇所が具体的に直りました。根拠を表で見せてくれる点と、口だけでなくlintの件数でも裏を取れる点はそのまま信頼できます。インストールも npx skills add 1回で済むようになっていて、前回Clone手順で試した時より手数が少なくなっていました。MCPツールの説明文やエラーメッセージを英語で書くときは、このSkillに一度通すと読みやすい文章にしてくれるので、有用です。日本語の文章はそのまま対象外なので、使うのは英語で公開するAPIやツールを持っている場合に限られます。