LLM の出力を理解するための Karpathy のヒントと、規格を誤って伝える ASD-STE100 チートシート

10 月 2 日、Andrej Karpathy が投稿しました。いまや多くの人が毎日抱えている問題についての短いガイドです。書き出しはこうです。

We'll be spending a lot more time trying to understand the outputs of language models.
A few thoughts, tips & tricks:

10 月 4 日に確認した時点で、表示回数は 640 万回でした。続いて 4 つの出力形式がはしご状に並び、段を上がるたびに「But even better:」と前置きされます。そして画像が 1 枚。航空機の整備マニュアルに使われる制限英語 ASD-STE100 を、技術図面風に 1 ページにまとめたものです。

投稿を読み、次に投稿が勧める規格を読み、それから画像を規格と照らし合わせました。レイアウトのおかげで規則はざっと目を通しやすく、内容の大半は正しいのですが、辞書の 3 行は読者に間違ったことを教えてしまいます。実はこれがスレッド全体でいちばん学びの多い部分でした。投稿そのもののテーマを、投稿自身の添付画像が実演しているからです。

Karpathy は LLM の出力を理解するために何を勧めたのか

手軽なものから野心的なものへ、順に 4 つの形式です。本人の言葉を抜粋します。

Writing. Something I've had success with: Ask your LLM to explain something in ASD-STE100,
it's a controlled language specification originally developed for aerospace maintenance
documentation.

Diagrams / images. Instead of writing, ask your LLM to create a diagram. These can be a lot
easier to process, parse, and understand.

Web pages. Ask for output "in HTML" to get a beautiful, interactive webpage.

Explainer videos. The output format I am most bullish on is fully custom / bespoke explainer
videos generated on any arbitrary topic.

文章の段には、実用的な緩和策を添えています。「the spec is quite stringent」（仕様がかなり厳しい）ので、ときには「80% of the way to ASD-STE100」（ASD-STE100 の 8 割程度）で頼むそうです。動画については「Create a 3b1b style video explainer on X. Use my ElevenLabs API key for audio narration」というプロンプト例を示し、代わりに「decent free alternatives that use your local compute」、つまり手元のマシンで動くまともな無料の代替手段をモデルに探させてもよいと書いています。

本当の主張はまとめの部分にあります。モデルが仕事の多くを担うようになるにつれ、「a lot more of our work will rise up the abstractions into oversight and understanding」、つまり私たちの仕事の多くは抽象度を上げ、監督と理解へと移っていく。知能もコードも安くなっているので、「you can ask for large, custom, discardable software artifacts (e.g. web apps, video explainers) that would have never made sense to create before.」以前なら作る意味がなかった大きく、目的に合わせて作る使い捨てのソフトウェア成果物を頼めるようになった、というわけです。この方向性は以前からのもので、2025 年の振り返りでもすでにコードを「discardable after single use」（一度使えば捨ててよいもの）と呼び、モデルは私たちが好む形式で語りかけるべきだと書いていました。

方向性には賛成です。この記事の残りでは、それぞれの形式で何を確認できるかを見ていきます。

ASD-STE100 とは何か、なぜ LLM にその形式で書かせるのか

ASD-STE100 は Simplified Technical English、つまり簡略技術英語と呼ばれる制限言語です。始まりは 1979 年で、ヨーロッパの航空会社が航空機メーカーに対し、第二言語で読む整備士でも誤読しようのない整備文書を求めたことがきっかけでした。最初のガイドは 1986 年に出ています。管理しているのはヨーロッパの航空宇宙・防衛産業団体 ASD で、現行版の Issue 9（2025 年 1 月 15 日）で仕様から国際規格へと位置づけが変わりました。

構成は 2 部です。1 つは執筆規則で、9 つのセクションに 53 の規則があり、語、複合名詞、動詞、文、手順の記述と説明の記述、安全に関する指示、句読点、執筆の実務を扱います。もう 1 つは約 900 の承認語を収めた辞書で、原則として 1 語に 1 つの意味と 1 つの品詞が割り当てられ、さらに約 1,200 の非承認語とその代わりに使う承認語が載っています。書き手は定められたカテゴリーの技術名詞と技術動詞も使えるので、STE は 900 語だけに閉じた言語ではありません。よく引用される制限は実在します。手順の文は最大 20 語、説明の文は 25 語、1 段落は 6 文まで、複合名詞は 3 語まで、動作が同時に起こる場合を除いて 1 文に指示は 1 つ、能動態を使い、セミコロンは使いません。

これがモデルに合う理由は、LLM の文章を読み疲れるものにしている癖を、規則がまさに取り除くからです。「it is imperative that」も「prior to commencing」も使わず、節を積み重ねず、誰が何をするのかをはっきり言うことを強く好みます。Karpathy が言いたいのは、モデルはこのスタイルをよく知っていて、結果が「a lot more readable」（ずっと読みやすい）になるということです。人間の読み手に効果があることも実際に裏づけられています。1996 年に航空機整備技術者 175 人を対象にした研究では、Simplified English によって理解度が上がり、効果がもっとも大きかったのは最も難しい作業カードと、英語を母語としない読み手でした。

使う前に、何を借りてくるのかを知っておいてください。

• 入手は無料ですが、再配布は制限されています。公式のダウンロードページから写しを申し込む形で、文書の著作権は ASD にあり、複製は著作権表示に記された許可の範囲に限られます。
• 規格自身の FAQ は、STE が「is not intended for general-purpose writing」、つまり一般的な文章向けではないと述べつつ、短い文や能動態といった原則はほかの場面にもよく応用できると認めています。Karpathy の「80% of the way」はまさにその妥協点です。
• 上手に書くのは難しいものです。「STE was created for the maximum benefit of the reader. This does not necessarily mean that it is simple to write.」

これを始めたのは Karpathy ではありません。2026 年 7 月には「モデルに STE で書かせる」スキルが GitHub と Hacker News で次々に登場し、そのうち 2 つはそれぞれ 3,000 を超えるスターを集めました。Karpathy の投稿は、それをはるかに大きな読者層に届けたわけです。

Karpathy の投稿にある ASD-STE100 チートシートは規格を正しく伝えているか

細部の多くは正しく、いくつかの項目は間違った規則を教えてしまいます。投稿に添付された画像はこちらです。

画像は Karpathy の X への投稿（2026 年 10 月 2 日）から、検証のために転載しました。作成者は明記されていません。ASD の刊行物ではありません。

パネルごとに Issue 9 と照らし合わせ、必要に応じて Issue 8 とも比べました。多くは正しい内容です。数値の制限はすべて合っています（20、25、6、3、1 文に指示 1 つ）。承認された 6 つの動詞の形、2 部 9 セクションの構成、承認語を大文字で書く慣例、語数つきの例文も正確です。辞書の 10 行のうち 7 行は、語も承認の可否も正しく書かれています。疲れた読み手ならこれを信頼するでしょうし、たいていはそれで問題ありません。

では、間違っている辞書パネルを見ていきます。

同じ画像の拡大。

• approximately は承認語なのに、シートは非承認としています。この行は「approximately (adv)」を非承認とし、代わりに ABOUT を挙げて、「Wait for ABOUT 10 minutes」を正しい形としています。規格では逆です。APPROXIMATELY は「almost correct or accurate」という意味の承認された副詞です。ABOUT は「concerned with」という意味の前置詞としてのみ承認されていて、規格はまさにこの組み合わせを教材の例に使っています。「Drain about 2 liters of fuel from the tank」は、書いてはいけない例として挙げられているのです。シートは、規格が注意を促している誤りそのものを教えています。
• TEST は承認された動詞ではありません。この行は「TEST (v)」を承認語とし、「To find if it operates correctly」という定義を添えていますが、この定義は規格の中に見つけられませんでした。TEST は名詞としてのみ承認されています。規格自身の例は「DO A FUNCTIONAL TEST OF THE SOFTWARE」で、避けるべき書き方として「Functionally test the software」が挙げられています。7 月には Hacker News で、まさにこの規則を引用した人がいました。
• 「in order to」の行に当たる項目は、規格の辞書には見つかりませんでした。TO に縮めるのは理にかなった助言で、規格の精神にも沿っていますが、Issue 9 と Issue 8 のどちらの辞書にもそういう行はありませんでした。シートは推奨を辞書の項目の形で示しています。

辞書の外にも、内容に関わる問題がさらに 2 つあります。動詞のパネルは、説明の文では「can use the passive only when it is necessary」（必要な場合にのみ受動態を使える）としています。実際の規則はもっと狭く、説明の文では「you can use the passive voice only when the agent is unknown」、つまり動作主がわからない場合にのみ受動態を使えます。「必要な場合」は判断に委ねられますが、「動作主がわからない場合」は確かめられる基準です。また構成のパネルは、技術名と技術動詞を辞書の中身として挙げていますが、FAQ は、それらが辞書には載っていないとはっきり述べています。これらは執筆規則で定義されるカテゴリーです。

シート全体には、もう少し目立たないサインもあります。用語が Issue 9 より前のもので、Issue 8 と一致しているのです。「noun clusters」（現在は「multi-word nouns」）、「technical name」（現在は「technical noun」）、タイトル欄の「Specification」（現在は規格）という表記があり、年表は 2025 年の変更より前で終わっています。セクション見出しの 1 つ「Procedures」は、どちらの版とも一致しません。

投稿は誰がどうやって画像を作ったのかを書いていません。出どころがどうであれ、結果は同じです。役に立つ要約と誤った辞書の助言が並び、レイアウトのせいでどちらも同じくらい権威があるように見えます。そして、すでに情報源として使われています。投稿の当日に作られたあるリポジトリは、制限値を「Karpathy's sheet」から取っています（たまたま制限値は正しい部分でした）。また、投稿より前の 7 月に書かれた別の STE スキルにはオープンな issue があり、承認語を禁止している 12 の行が挙げられていて、その中に approximately も入っています。機械で作られた STE の語彙表は、それぞれ独立に同じ形で失敗しているわけです。読者も一部には気づいていました。投稿から約 20 時間後、ある返信が ChatGPT の回答を貼りつけて approximately の行を指摘し、GitHub のあるリファレンスファイルも同じ誤りと古い用語を記録していました。TEST の行、「in order to」の行、受動態の規則の言い換えを指摘した人は見つかりませんでした。

規格を管理する側は、こうなることを予見していました。2026 年 6 月に STE と AI に関するホワイトペーパーを公開し、ダウンロードページはその内容を 2 つの文でまとめています。あらゆる AI スタイルガイドの冒頭に掲げたい文です。

AI-generated text can appear clear, authoritative, and consistent with STE, even when it
does not correctly apply the rules and vocabulary of the standard. Plausibility must not
be confused with verified compliance.

LLM は頼めば本当に ASD-STE100 に従うのか

ゆるくしか従いません。しかもモデルは、実際以上にうまく従えていると思い込みがちです。

詳しく調べたあるテクニカルライターは、モデルが出すものを「STE-flavored English, not STE」（STE 風の英語であって STE ではない）と呼んでいます。現行の辞書と照合しなければ、モデルはスタイルをまねながら語彙の規則を破ってしまうことがあります。Karpathy の投稿への返信では、現行モデル 3 つがこの依頼を「simply ignore」（あっさり無視する）と報告した人がいて、STE の回答と普通の回答にほとんど差がなかったという人もいました。7 月の Hacker News では、規則への準拠はすぐにずれていき、それを保てるのはリンターかコミットフックだけだ、という意見が繰り返し出ていました。

計測はわずかです。スターがもっとも多い STE スキルは「cuts slop 72.9%」とうたっていましたが、この数字はスキル自身のリンター規則への違反を数えたものでした。作者はその後、バージョン 2.0.0 を 8 つのシナリオで監査し、短いプロンプトのほうが短く、書式の不備も少ない回答を返すことを確認しています。これは理解度の研究ではなく、プロジェクトはその後スキルを作り直しました。Lucian Ghinda はコードの説明を題材に、小規模で、本人も明言しているとおり非公式なテストを行いました。Claude では、ゆるい「simple technical English」プロンプトでは、採点対象の事実への言及がベースラインの回答より 8.5% 少なく、厳密な ASD-STE100 プロンプトでは 46.8% 少なくなりました。Codex ではそれぞれ 43.3% と 40.0% の減少でした。コードサンプル 4 つ、セッション 2 回です。ランキングとしてではなく、簡略化で事実が落ちうるという警告として受け取ってください。制約への従い方を扱った 2026 年のプレプリント 2 本も、予想どおりの結果を示しています。モデルは自分の準拠度を過大評価し、規則を言い直しながらその規則を破ることがあります。

実務上の結論は、プロンプト一般について書いたことと同じです。プロンプトに書いたスタイル規則はお願いであって、保証ではありません。本当に STE が必要なら、モデルの外で確認してください。文章用リンターの Vale なら、守らせたい規則を選んで組み込めるので、「80%」を自分で決めた規則のリストに置き換えることにもなります。リンターが確認するのは設定した規則だけで、STE への完全な準拠も、文章が正しいことも保証しません。

LLM の出力を理解するには、文章より図のほうがよいのか

Larkin と Simon は 1987 年の論文のタイトルに答えを書いています。「Why a Diagram is (Sometimes) Worth Ten Thousand Words.」同じ情報を持つ文章と図でも、図のほうがはるかに楽に使えることがあります。読み手が頭の中でやるはずの索引づけを、位置が代わりに担ってくれるからです。Cromley と Chen による 2025 年のメタ分析は、マルチメディア学習に関する 181 件の研究を対象に、全体の効果量を約 0.37 と見積もりました。ただし設計原則や評価指標によるばらつきは大きく、文章と図の組み合わせの結果は比較的一貫していた一方、アニメーションはずっとばらついていました。

モデルに特有の注意点が 2 つあります。生成された図は、図としてまだ信頼できません。SVG や Mermaid などの形式のベンチマークでは、はっきりした弱点が見えています。そして図には図なりの誇張の仕方があります。ある返信がうまく言い表していました。簡略化するときは「if」「unless」「not yet verified」のような言葉を守ること。それがないと「a clearer sentence can become a stronger claim」、つまりわかりやすくなった文がより強い主張に変わってしまうからです。図も同じで、矢印が 1 本欠けているだけで、依存関係はないと黙って主張することになります。逆の例も出ていました。矢印が 1 本逆を向いていたおかげで、文章では隠れていた本物の誤りに気づいた人がいたのです。どちらも本当です。図は構造を、間違った構造も含めて見えるようにし、抜け落ちたものを見えなくします。

私ならこう使います。読めて diff も取れるテキスト形式（Mermaid、Graphviz、シンプルな SVG）で図を頼み、レンダリング結果を見て、描いた関係をすべて 1 つずつ文にして図の下に並べるようモデルに頼みます。そして、そのリストを読みます。

なぜ LLM に HTML で出力させるのか

Bret Victor は 2011 年に 「Explorable Explanations」で、こうした文書の目標を書いています。「A reactive document allows the reader to play with the author's assumptions and analyses, and see the consequences.」読み手が著者の前提や分析をいじって、その結果を見られる文書です。HTML の回答には、文章にはないものがあります。表やスライダー、折りたためるセクション、小さなシミュレーションです。返信でいちばん好評だったのもこの段で、2024 年には Claude の Artifacts や ChatGPT の Canvas が、生成されたコンテンツを専用の作業スペースに持ち込みました。

スレッドで最良の提案は、何人かが別々に出していた派生案でした。答えを見せるページではなく、前提を 1 つ変えて何が壊れるかを見られるページを頼む、というものです。こうすると説明の前提を点検できるようになります。ただ、それはまだ実物のテストではありません。モデルがキャッシュのバグをインタラクティブなページで説明した場合、ページのトグルが検証するのはページの中のバグのモデルであって、あなたのシステムではありません。診断を確かめるには、実際のコードと入力で再現してください。

コストもあります。HTML の成果物は普通の回答よりトークンも時間もかかり、チートシートと同じように、仕上がりがきれいなまま間違っていることもあります。前提をページ上に見える形で列挙した、単体で完結するファイルを頼んでください。

LLM は 3Blue1Brown 風の解説動画を作れるのか

作れるようになってきています。そしてここが、Karpathy がもっとも期待を寄せ、根拠がもっとも薄いところです。「3b1b style」を実現する方法の 1 つが Manim で、Grant Sanderson が 3Blue1Brown のために書いたアニメーションエンジンです（MIT ライセンス、スター約 94,500）。もう 1 つは、ドキュメントが充実したコミュニティフォークの ManimCE です。両者はセットアップが違うので、どちらを使いたいかを指定してください。モデルが Manim のコードを書き、そのコードがアニメーションをレンダリングし、テキスト読み上げサービスがナレーションをつけます。返信では、実際にそれを 1 日以内にやってみせた人たちがいました。確率解析について、決済の仕組みについて、そして API キーを使わずすべてローカルのツールで作ったものもありました。最後のものは、Karpathy 自身が触れていた代替手段です。

このアイデアの裏には実際の研究もあります。240 の定理からなるベンチマークで評価された TheoremExplainAgent の研究（ACL 2025）は、心強い結果を示しています。動画にすると、文章の説明では隠れていたモデルの推論の欠陥が表に出たのです。アニメーションにすると、次に何が起こるかを確定させざるをえません。それで視聴者の学びが良くなるかどうかは別の問題で、この研究では検証されていません。

実務上の注意が 3 つあります。Karpathy のプロンプト例に出てくる ElevenLabs は、送ったテキストをデフォルトでログに残し、それを無効にするのはエンタープライズ向けの機能です。ですから、非公開の素材はホスト型のナレーションに出さないか、ローカルの方法を使ってください。キーはプロンプトに書かず、ツールの認証情報の設定に入れてください。そして動画は、文字起こしやチャプターがないと拾い読みしにくくなります。edX の動画 862 本、視聴セッション 690 万件を調べた研究では、視聴時間の中央値は約 6 分で頭打ちになっていました。スクリプト、字幕、元のプロジェクトを残しておけば、主張を検索できる状態に保てます。早い時期のある返信が、リスクを一文で言い表していました。「a wrong claim narrated over a 3b1b animation is way harder to catch than a wrong sentence.」3b1b 風のアニメーションに乗せて語られた誤った主張は、誤った一文よりはるかに見抜きにくい、ということです。

読みやすい LLM の出力は、検証しやすい出力なのか

それだけでは、そうとは言えません。わかりやすい形式は、矢印や定理の動画の例のように誤りをあぶり出すこともあれば、裏づけのない主張を受け入れやすくすることもあります。問うべきは、それぞれの形式で何を点検できるかです。

2 つ目の効果についての研究は知っておく価値があります。2024 年の研究（Si et al., NAACL）では、LLM の説明を手がかりに主張のファクトチェックをした約 80 人のクラウドワーカーは、説明が正しいときには 87% 正解しましたが、説明が間違っているときの正解率は 35% でした。これは、同じケースで根拠を何も見なかったときの 49% を下回ります。CHI 2021 の研究では、AI の助言が正しいかどうかにかかわらず、説明があると人は助言を受け入れやすくなることがわかりました。テキスト簡略化の研究（Devaraj et al., ACL 2022）は、簡略化された版には事実の誤りがよくあることを見いだし、読みやすいが不正確な版は、まったく読めない状態よりも悪い場合があると論じています。そして説明深度の錯覚、つまり仕組みをどれだけ理解しているかを過大評価しがちな私たちの癖を思うと、目に見える仕組みを完全な説明と取り違えないよう慎重になります。

これらの研究はどれも Karpathy の 4 つの形式を比べたものではないので、段を上がるほど確認しにくくなるとまでは言いません。言えるのはもっと狭いことです。段ごとに、主張は新しい場所に移ります。文章なら引用も検索もできます。図では矢印と、描かれていないものの中に入ります。ページではコードとレイアウトの中に、動画ではタイミングと声の中に入ります。確認はそこまで追いかけていく必要があり、4 つの形式のどれもそれを代わりにやってはくれません。

Karpathy のまとめは、私たちの仕事が「into oversight and understanding」、つまり監督と理解へと上がっていくと述べています。そのとおりだと思いますが、この 2 つは同じ作業ではない、と付け加えたいところです。翻訳を理解することは、それを検証することと同じではありません。自分では作れなかったはずの出力なら、どんなものでも同じことが言えます。

Karpathy のテクニックにだまされずに使うには

4 つの段はすべて使ってください。どれも良いものです。そして、どの段でも確認できるものを 1 つ手元に残してください。

STE やそれに近い形で書かせる場合：

• 簡略化した版を頼み、元の版を横に置いておきます。簡略化は置き換えではなく、1 つの見せ方であるべきです。
• 識別子、パラメーター名、エラーメッセージの文字列、専門用語は書かれたとおりに残し、「if」「unless」「not verified」はすべて残すようモデルに指示します。簡略化するときに真っ先に落とされるのがこれらの言葉です。
• スタイルが重要なら、モデルの言葉を信じるのではなく、リンターで確認します。

図の場合：テキスト形式で頼み、レンダリング結果を見てから、エッジ 1 本につき 1 文を読みます。

HTML の場合：前提がページ上に列挙され、その前提を変えられるページを頼み、実際のシステムは別にテストします。

動画の場合：スクリプトをテキストで残し、見る前に一度読み、非公開の素材はホスト型のナレーションに出さないようにします。

そして、それをもとに行動するものについては、重要な主張を 1 つ選び、一次情報と照らし合わせてください。チートシートの誤りも、そうやって明らかになります。辞書の項目を 1 つ見るだけで足りました。

Karpathy の投稿は仕事の行方について何を語っているか

希少なスキルが、出力を生み出すことから出力を判断することへ移りつつあるということ。そしてモデルは、手作業ではとても作る価値のなかった成果物を生み出すことで、その判断も手伝えるということです。使い捨ての解説、一度きりのインタラクティブなページ、たった 1 人の視聴者のために作られた動画。これらは現実のもので、新しいものです。

付け加えたいのは、投稿がはっきり言っていない区別です。何かを理解したという感覚は、それが正しいことの証拠ではありません。このはしごは前者にはとても強い。後者は、どの形式を選ぶにせよ、意図して組み込む必要があります。明確で曖昧さのない文章のための規格について、今週もっとも広く共有された要約は、その規格自身の教材の例の 1 つを、これ以上ないほどわかりやすいレイアウトで逆にしていました。私なら、美しいものの横に一次情報を開いておきます。