Karpathy：AIに複雑な問題を明快に解説させる4つの手法

AIの仕事が増える中、私たちはその出力をどう理解すべきか？

AIが出力するコンテンツがますます長くなり、含まれるコードや技術的な論述が複雑になるにつれて、読者は文脈の整理、代名詞の指示対象の特定、論理の検証に膨大な時間を費やす必要があります。

この課題に対し、Andrej Karpathyは元ポストにおいて先見的な見解を示しました。AIが基本的な実行作業を自律的に担うようになるにつれ、人間の仕事の重心は監督と理解へと移行し、私たちはAIの出力を理解するためにこれまでよりもはるかに多くの時間を費やすことになる、というものです。本記事で引用している6つの英語原文は、いずれもこの元ポストからの重要な抜粋です。

Karpathy による元ポストの要点訳（抜粋）

1. 文章作成：私が試して効果的だった方法：AIにASD-STE100規格に沿って物事を説明させること。
2. 図解／画像：文章を書かせる代わりに、AIに図を描かせること。図解のほうが処理、分析、理解が容易になる場合がある。
3. Webページ：「HTML形式で」出力を要求し、見栄えの良いインタラクティブなWebページを得ること。
4. 解説動画：私が最も期待している出力形式は、任意のトピックについて完全にカスタマイズされた解説動画を生成することだ。

彼は元ポストの最後で次のように締めくくっています：

• AIが強力になるにつれて、基本的な実行作業はますます自律的にこなすようになり、私たちの仕事の多くはより高い抽象化レベル、すなわち監督と理解へと移行していきます。
• 幸いなことに、AIはこの点でも力を発揮します。知能とコードがますます豊かになるにつれ、Webアプリケーションや解説動画のように、オンデマンドでカスタマイズされ、使い終わったらそのまま破棄できる相当な規模のソフトウェア成果物の生成を要求できます。これらはかつて、わざわざ専用に制作する価値すらなかったかもしれないものです。既存の使い方の枠組みを超えてみてください。きっと驚くはずです。

以下では、最も手軽に直接活用できるテキストの手法から始め、これら6つの理念の背景にあるメカニズム、使い方、具体的事例を順に展開していきます。

---

1. 明快な言葉を使い、読者の推測を減らす

原文抜粋：Ask your LLM to explain something in ASD-STE100
訳文：AIにASD-STE100規格に沿って説明するよう指示する。

1. 詳細な解説：なぜ「もっとシンプルに」と言うだけでは不十分なのか？

AIの出力が難解だと感じたとき、私たちは習慣的に「もっと分かりやすく簡単に説明してください」と聞き返しがちです。しかし、この指示では自分がどこでつまずいているのかが伝わらず、具体的な書き換えのルールも示されていません。その理由は、「分かりやすい」や「シンプル」という言葉が極めて主観的であり、実行可能な境界を欠いた抽象的な要求だからです。AIは「シンプル」を詳細の削除と解釈することもあれば、比喩への置き換えと捉えることもあります。文章が短くなり、親しみやすい響きになったとしても、条件や因果関係が明確に説明されたとは限りません。

対照的に、AIに具体的な文章作成ルールを与えることで、どのように改稿すべきかを明確に指示できます。Karpathyが推奨するASD-STE100は、もともと航空業界が整備文書のために策定した制御自然言語（Controlled Natural Language）の国際規格です。Karpathyは、AIはこの規格に精通しており、自身もこれを用いることでより読みやすい解説を得られたと述べています。単に「分かりやすく」と求めるのに比べ、規格を指定することで語彙や文構造に明確な制約が課されます。ただし出力後も、事実関係や手順に誤りがないか確認する必要があります。

ASD-STE100 第9版規格のダウンロード（公式PDF）

背景の補足：ASD-STE100の中核メカニズム
ASD-STE100（Simplified Technical English、簡略技術英語）は、制御語彙辞書と執筆規則の2つの部分から構成されています：

1. 同一語の同一意味と品詞の固定：一般語彙辞書で承認された単語は、原則として単一の意味と承認された品詞のみが保持されます（例：close は動詞の「閉じる」としてのみ使用でき、形容詞の「近い」としては使用不可）。これにより、多義語による推測を減らします。
2. 文長の制限と単一指示：手順の指示文は原則として20語以内、解説文は原則として25語以内とします。1つの文で表現する指示は原則1つとし、同時に発生する動作は1つの文にまとめて記述できます。
3. 能動態：手順を説明するテキストでは動作を直接書き、読者が何をすべきかを明確にします。中国語の操作説明では、条件を動作の前に配置することも可能で、例えば「ネットワーク回復後、もう一度試行する」のように、まず条件を判断しやすくします。
4. 技術的ファクトの維持：制御された規範は技術的事実を削除するものでは決してなく、一般的な語彙の制約とは別に、規則に従って専門技術名詞や技術動詞の使用を認めています。

短い文にする核心的な目的は、長い文において読者が主語・述語・目的語の入れ子構造や関係節の修飾を推測する負担を軽減することにあり、単に文字数を削るために、動作の前提条件や必要な技術的ファクトを削ぎ落としてはなりません。

2. 重要な検討事項：理解と適用の境界

• 「80%」は口語的な調整であり、規格の公式バージョンではない：Karpathyは、STE規格が厳格すぎて不自然だと感じる場合、その8割程度の水準を満たすよう求めることができると述べています。これは制約を緩和し、表現の流暢さを両立させるために彼が試みたプロンプトの工夫であり、規格自体に「80%準拠」という公式基準が存在するわけではありません。
• 中国語への応用は組織原則の参考であり、英語の辞書をそのまま当てはめることではない：ASD-STE100はアメリカ英語を対象に構築された語彙・文法体系であり、中国語の文法メカニズムは全く異なります。中国語の実践においては、その「短文、能動態、一文一事、条件前置」という考え方を取り入れるべきであり、中国語がこの国際規格に準拠していると機械的に主張すべきではありません。

3. 具体的な実例：操作マニュアルの書き換え比較

以下は本記事で作成した想定事例です。

• プロンプトの参考例：
  STEの原則を参考に、中国語環境ではAIに次のように指示できます：

  「以下の操作手順を簡潔な技術文書スタイルで書き直してください。要件：1. 1文につき1つの事実または動作のみを表現すること；2. 能動態の命令文を使用すること；3. 手順の前提条件は必ず動作の前に置くこと；4. 因果関係と事実の完全性を保ち、余分な挨拶や修飾は削除すること。」

シナリオ：Webページでのファイルアップロード失敗時の処理手順の書き換え

• 【書き換え前：冗長なバージョン】

  “ユーザーがフロントエンドのインターフェースでファイルアップロード操作を実行したものの、アップロード失敗を示すシステムエラーメッセージに遭遇した場合、第一歩としてまずローカルデバイスのネットワーク接続がスムーズに通じているかどうかを調査・確認する必要があります。バックエンドサーバーへの余計なリクエスト送信を回避し、システムの混雑負荷を悪化させないようにするため、ユーザーは短時間の間に送信ボタンを何度も連続して繰り返しクリックしないように十分注意しなければなりません。ローカルネットワークが完全に正常復帰したことを確認できた段階で、送信ボタンを改めて1回クリックして再試行を試みることができます。その後も依然としてファイルのアップロードが正常に完了しない場合は、画面にポップアップ表示された具体的なエラーコードの完全なスクリーンショットを撮るかコピーして保存した上で、さらなる支援を得るために技術サポートチームへ必ず連絡してください。”

• 【書き換え後：明快なバージョン】

  1. アップロードに失敗した場合は、まずローカルのネットワーク接続を確認してください。
  2. 送信ボタンを繰り返しクリックしないでください。
  3. ネットワークが復旧したら、送信を1回再試行してください。
  4. それでもアップロードに失敗する場合は、エラーコードを保存して技術サポートにお問い合わせください。

比較分析：
書き換え後のテキストは操作の前提条件を一切削ることなく、「まず条件を判断してから行動する」という原則を厳格に適用しています。例えばステップ3の「ネットワーク回復後、もう一度送信を試行する」において、もし前半の条件が抜け落ちて単に「再送信を試行する」とだけ書かれていれば、読者はネットワークが回復していないにもかかわらず送信を繰り返してしまう可能性があります。文は短くなっても、操作の論理が失われてしまうのです。「条件前置」は、読者が動作を実行するたびに環境がそれを許容しているかをまず確認できるようにし、読者が行うべき動作を見つけやすくすると同時に、本来の処理順序を確実に保持します。

---

2. 関係を図式化し、頭の中でプロセスを組み立てる負担を減らす

原文抜粋：Instead of writing, ask your LLM to create a diagram.
訳文：AIにテキストを書かせる代わりに、図を描くよう指示する。

1. 詳細な解説：なぜ図表は理解に役立つのか？

技術的な内容が複数モジュールの連携、データの流れ、または前後関係に及ぶ場合、読者は読み進めながら各モジュールを記憶にとどめ、それらを頭の中で結びつける必要があります。後の方を読む段階になると、前のどのノードと関連していたかを振り返って確認しなければなりません。Karpathyは、AIに長文を出力させるよりも図表を生成させたほうが、視覚的なグラフィック構造によってモジュール間の関連性を直接提示でき、解析や理解がはるかに容易になると指摘しています。

解説用図表の価値は、重要な処理の分岐、合流ノード、データの流転方向を保持できる点にあります。実践においては、AIにMermaidフローチャートやSVGアーキテクチャ図を直接出力させることが可能です。

2. 具体的な実例：AI検索拡張生成（RAG）のフロー

以下は本記事で作成した想定事例です。

• 指示の考え方：
  元ポストの考え方を参考に、中国語環境ではAIに次のように指示できます：

  「AI検索拡張生成（RAG）の実行フローをMermaidフローチャートで示してください。ユーザーの質問、検索、リランキング、コンテキスト統合、AIの回答などの各工程を明記し、データの流れを示してください。」

RAGの実行メカニズムと図表の分析

図表を見る前に、まず簡潔なロジックでRAGの中核リンクを整理しておきましょう：

1. 検索：ユーザーが質問を提示した後、システムはナレッジベース内から関連する可能性のある参考資料の断片を検索します。
2. リランキング：初期スクリーニングされた断片の関連度にはばらつきがあるため、リランキングモジュールが各断片の関連度を再スコアリングし、質問に最も即した高品質な断片を選出します。
3. 質問と断片の統合：元の質問と絞り込まれた背景情報の断片を組み合わせ、外部の参考資料を含む1つのプロンプトを組み立てます。
4. 回答生成：AIがコンテキストを含む完全なプロンプトを読み込み、それに基づいて回答を生成します。

フローチャートに示されている「20件のリコール断片からリランキングして3件の断片を絞り込む」という数値は、教育的なデモを意図した想定設定であり、固定されたエンジニアリング標準ではありません。

質問と参考資料がここで合流する

ユーザーの質問

↓

埋め込みモデル：質問を検索可能な数値表現に変換

↓

ナレッジベース：20件の候補資料を抽出（デモ用の設定）

↓

リランキング：関連性を比較し、3件を保持（デモ用の設定）

↓

プロンプト組み立て：元の質問 ＋ 抽出された参考資料の断片

↓

AI：資料を組み合わせて回答を生成

元の質問は組み立て段階まで保持され、検索用の数値だけになるわけではありません。矢印はデータの流れを示します。資料が利用可能であっても、回答が正しいかどうかの検証は依然として必要です。

読者はこの図から何を発見できるか？
図に沿って追っていくと、特に2つの事柄を区別して理解できます。元の質問はそのまま保持される必要があり、検索によって得られた資料も最終的なプロンプトに送られる必要があります。これらは用途が異なります：

• 元の質問は、ユーザーが実際に何を尋ねているかをAIに伝えるものであり、プロンプト組み立て時にも保持されます。
• 検索ステップでは、質問の表現を利用して資料を探し、リランキングによって断片を厳選した上で、それらを元の質問と統合します。デモの設定では20件から3件を保持しています。

各段階を並べて俯瞰することで、読者はプロセスに沿って次の検証を行えます。もし最終的な回答に誤りがあった場合、それは初期検索で見つけられなかったのか（リコール段階の欠落）、リランキングが適切な断片を取りこぼしたのか（順位付けの歪み）、あるいは資料は届いていたのにAIが正しく利用できなかったのか？ 図表はどの段階を検査すべきかの手掛かりを与えてくれますが、原因を特定するには実際の入力と出力を確認する必要があります。

---

3. 読者が条件を変更できるようにし、結果がどう変化するかを視覚化する

原文抜粋：Ask for output "in HTML"
訳文：AIに「HTML形式」で出力するよう指示する。

1. 詳細な解説：理解を助けるインタラクティブツールとしてのソフトウェア

Karpathyが示した3つ目のテクニックは、AIに対してHTML、すなわちWebページのコードを直接出力するよう要求することです。彼は、AIがフロントエンド開発に長けてきており、UIコントロール、アニメーション、インタラクションを含むページを作成できると考えています。HTMLがコンテンツ構造を決定し、CSSが見た目を担い、JavaScriptが読者の操作と計算結果を連動させます。

静的なテキストでは「Aが変化すればBも変化する」という一方向の説明しかできませんが、スライダーや入力欄を備えたインタラクティブなWebページであれば、読者自らがパラメータを調整し、入力に応じて出力が連続的に変化する因果関係のプロセスをリアルタイムで確認できます。境界を能動的に探索することで、読者は同一のアルゴリズムが異なる条件下でどのように振る舞うかを比較できます。

2. 具体的な実例：インタラクティブWebページの設計とロジック

以下のデモでは想定スコアを使用し、明確な数式に基づいて計算を行っています。

• プロンプトの参考例：
  元ポストの考え方を参考に、中国語環境ではAIに次のように指示できます：

  「HTML（CSSおよびJSを含む）を出力し、温度パラメータ（Temperature）がAIの単語選択確率に与える影響を分かりやすく解説するインタラクティブなページを作成してください。要件：1. 上部にTemperatureスライダー（範囲0.1〜2.0）を設けること；2. 想定logitスコア[3, 2, 1, 0]における候補単語『公園、散歩、図書館、火星』の確率棒グラフを表示すること；3. スライダーをドラッグした際、計算式に基づいて各単語の確率と説明をリアルタイムに更新すること。」

インタラクティブコンポーネントの形態と動作プロセスの実演

1. 数学的公式と計算の基準：
   現在の文脈において、AIが4つの候補単語に対して生成した元のスコア（logitスコア）が、公園 z₁ = 3、散歩 z₂ = 2、図書館 z₃ = 1、火星 z₄ = 0 であると仮定します。システムは温度パラメータを組み込んだSoftmaxの公式を通じて、各単語の選択確率を計算します：
   pᵢ = exp(zᵢ / T) ÷ Σ exp(zⱼ / T)。ここでexpは指数関数であり、分母は4つの候補の数値を合算して確率の総和が1になるようにします。
   注意：ここでの元スコアは教育用の想定値であり、実演の主眼はアルゴリズムの変換メカニズムにあります。実際のAIの予測確率を示すものではありません。

2. 固定入力における計算差異の追跡：
   このインタラクティブ設計では、4つの単語の元スコアは厳密に固定されており、唯一変動する変数は温度スライダー T です。読者はスライダーを動かすことで、「入力パラメータ → 数式による計算 → 確率分布」という一連の差異を明確に追跡できます：

   • スライダーを T = 0.1 に動かしたとき：温度が低いため、元のスコア差をTで除算した値が非常に大きくなり、さらに指数計算を経ることで確率の差が大幅に増幅されます。各単語の確率はそれぞれおよそ、公園 99.995%、散歩 0.00454%、図書館 0.000000206%、火星 0.00000000000936% となります。下部の説明には、確率分布が極端に急峻になり、ほぼ常に最高スコアの候補単語が選択されると表示されます。
   • スライダーを T = 1.0 に動かしたとき：T=1における基準となる確率分布が得られ、それぞれおよそ、公園 64.39%、散歩 23.69%、図書館 8.71%、火星 3.21% となります。
   • スライダーを T = 2.0 に動かしたとき：温度が高くなることで指数の差が平滑化され、各単語の確率はそれぞれおよそ、公園 45.51%、散歩 27.60%、図書館 16.74%、火星 10.15% となります。低スコアの単語が選ばれる確率が明らかに上昇します。

3. 読者は比較からどのように理解を構築するか：
   数式を見るだけでは、読者は「Tで割る必要がある」ことは理解できても、この項が結果をどのように変化させるかを直感的に把握できないことがあります。しかしインタラクティブなデモにおいて、基準スコアを固定したままスライダーを連続的に動かすことで、棒グラフが「極端な格差」から次第に「平坦」になっていく様を目の当たりにできます。これにより読者は、温度パラメータ自体がAIに新たな知識を注入したりスコアの順位を入れ替えたりするのではなく、各候補が選択される確率（チャンス）を変化させているのだと実感できます。温度が高くなるほど、スコアの低い候補にも選ばれる機会が生じます。なお、T=0 の場合は数式を直接計算できませんが、T が正の値から 0 に近づくにつれて最高スコアの候補の確率は 1 に収束します（エンジニアリング上は通常、最高スコアの単語を貪欲に選択する処理に縮退します）。高温だからといって完全な出鱈目を捏造するわけではなく、低温だからといって答えの正しさが保証されるわけでもありません。

温度を変更し、同一の候補単語群を観察する

例示スコア：公園 3、散歩 2、図書館 1、火星 0。4つの候補のみを示すデモであり、実際のモデル出力ではありません。

温度 T：

1.0

確率 = exp(スコア ÷ T) ÷ 全候補の exp(スコア ÷ T) の総和。

公園

64.39%

散歩

23.69%

図書館

8.71%

火星

3.21%

候補はスコアに応じて確率が配分されます。最高スコアの候補が依然として優位です。

温度を高くすると確率分布がより平坦になります。知識を補完するものではなく、回答の正確性を保証するものでもありません。スクリプト無効時は T=1 の数値を保持します。

---

4. オーダーメイド動画を活用し、変化のプロセスを展開して見せる

原文抜粋：fully custom / bespoke explainer videos generated on any arbitrary topic
訳文：任意のトピックについて完全にカスタマイズされた解説動画を生成する。

1. 詳細な解説：静的な読書から動的な進化へ

あらゆる出力形式の中で、Karpathyが最も有望視していると述べたのが、任意のトピックに対して完全にカスタマイズされた解説動画を生成することです。彼は元ポストにおいて具体的な実装の考え方を紹介しています。AIに3Blue1Brownスタイルのトピック解説動画を作成させ、ElevenLabsのAPIキーを使ってナレーション音声を付けるか、あるいはローカルの計算リソースを活用する無料の代替ツールをAIに探させるという手法です。Karpathyは、このアプローチがすでに機能し始めており、大いに探索する価値があると述べています。

3Blue1Brown（3b1bと略されることが多い）は、アニメーションを用いて数学を解説する人気の教育チャンネルです。ここで参考にされているのは、映像を使って数学的な関係性を視覚的に示す解説スタイルです。

この構想を実際に再生可能な映像に落とし込むには、自動動画生成における複数の連動プロセスが必要となります。説明すべき関係性の決定、絵コンテの作成、幾何学アニメーションのコード生成、映像のレンダリング、音声ナレーションの合成、そして字幕のアライメントです。動画の持つ決定的な価値は、抽象的な数学の導出を、観察可能な連続的変化として表現できる点にあります。

2. 具体的事例：内積はなぜ負の値になるのか？

本記事ではClaude CodeのOpus 5.5を用いて約63秒の数学解説動画を制作し、Doubao（豆包）の「劉飛」音声による中国語ナレーションを付けました。この動画は、連続的な回転、射影、数値を同一画面内に収め、内積がどのようにして負の値になるのかを示しています。ベクトル A=(2,0) を固定し、ベクトル B の長さを 1 とします。B の水平方向における符号付き射影は cosθ となり、これに A の長さ 2 を掛けることで、内積 2cosθ が得られます。

• 元ポストの手法の要約：
  3Blue1Brownスタイルのトピック解説動画を制作し、ElevenLabsのAPIキーでナレーションを付けるか、ローカルの無料代替策を探す。
• 中国語プロンプトの参考例（日本語訳）：

  「【テーマ：2次元ベクトルの内積の幾何学的意味】を分かりやすく解説する、1分程度の3Blue1Brown風の数学アニメーション短編スクリプトを設計してください。要件：固定ベクトルA=(2,0)と長さ1の回転ベクトルBを例とし、BのA方向への符号付き射影にAの長さを掛けた値（2cosθ）を示すこと；タイムラインに沿って画面の幾何学的変化とそれに対応する口頭の解説ナレーションを分解して記述すること。」

動画の中で何が起きているのか？

連続的な変化と同期した解説はどのように理解を助けるのか？
静止画では通常、孤立したある角度における断面的な射影しか表現できず、読者が公式 A·B = |A||B|cosθ を暗記していたとしても、負の符号がどこから生じるのかを感覚的に理解しているとは限りません。しかし連続した動画の中では：

• 負の符号の由来を1フレームずつ可視化：ベクトルBが90度を超えて回転するとき、水平軸上の射影は原点を通過し、負の半軸へと移ります。「射影が左側にある」ことと「数値がゼロ未満である」ことが同一のプロセス内で現れるため、読者は向きと負の符号を結びつけて捉えることができます。
• ナレーション、字幕、画面の対応：120度の場面では、画面に射影 -0.5 が表示され、内積が 2 × (-0.5) = -1 と示されます。ナレーションがなぜ負になるのかを解説し、字幕が重要な数値を保持し、グラフィックが位置の変化を提示します。読者は長文を読み終えてから図中の該当箇所を探し直す必要がありません。なお、内積の具体的な意味は、ベクトルが何を表現しているかに依存します。

---

どう選ぶか：自分がどの段階でつまずいているかによる

1. メディアの選択は具体的な認知的タスクに依存する

Karpathyは元ポストにおいて段階的な修辞を用い、テキストから動画に至る表現の可能性を示しました。しかし実際の応用においては、メディアごとに得意分野が異なり、あらゆる場面に通用する万能の解決策は存在しません：

• 制御されたテキスト（STE規格）：閲覧が素早く、検索が容易。エラーのトラブルシューティング、インターフェース定義、安全操作規定に適しており、読者は再生を待つ必要がありません。
• 構造図・フローチャート：モジュール間の関係性、時系列、分岐のトポロジーを直感的に提示し、読者が頭の中に全体構造を構築するのに適しています。
• インタラクティブなWebページ：多変数の探索やパラメータの動的応答に適しており、読者が自ら入力を調整して出力の変化を観察することで、因果関係の直感を養うことができます。
• 動的動画：連続的な動きや幾何学的な進化のプロセスを提示するのに適していますが、線形なタイムラインを持つため、情報の逆引きや特定位置へのアクセスのコストは比較的高くなります。

5. 人間の重心は監督へと移る：理解の深さが何を検証できるかを決める

原文抜粋：oversight and understanding
訳文：監督と理解。

1. 詳細な解説：なぜ「動く」ことは「ビジネス的に正しい」ことを意味しないのか？

Karpathyが指摘した本質的なトレンドは、AIの能力が向上し続けるにつれて、基本的なコード作成や実行作業はAIが自律的に完了するようになり、人間の仕事の重心は監督と理解へとシフトしていくという点です。

返金ボタンが正常にクリックでき、リクエストが問題なく送信できたとしても、二重返金が発生したり、金額が上限を超えたり、未確定の状態を失敗と誤認したりする問題が依然として潜んでいる可能性があります。インターフェースが正常に動作していることは、振る舞いの一部を証明したにすぎません。AIには明確なビジネス要件が必要であり、人間側もどの条件が満たされていなければならないかを理解していなければ、AIの実装が要件を満たしているかを検証できません。ビジネスルールに対する理解の深さが、AIの成果物を検証するためにどのようなテストケースを設計できるかを直接決定します。例えば「タイムアウト後は結果が未確定である」という本質を理解していなければ、成功と失敗のケースしかテストせず、最も処理すべき中間状態を見落としてしまうことになります。

2. 具体的事例：ECサイトの返金機能の実装と監査

以下は教育用の想定事例であり、実際の決済には接続されておらず、元ポストに記載されていた事例でもありません。

AIに返金画面のフロントエンドおよびバックエンドの処理ロジックを一式生成させる際、AIにフォーム、バリデーション、リクエスト処理のコードを作成させた上で、具体的なビジネスルールに基づいて次の3つのシナリオを検査できます：

1. 同一注文に対する重複返金の防止：
   • テスト入力：すでに全額返金が完了した注文に対して、再度返金処理を実行する。
   • ビジネス要件：サーバー側は確定済みの返金記録に基づいて重複申請を遮断し、「注文は返金済みのため、再送信できません」と返すべきです。フロントエンドのボタンを非活性化するだけでは、重複リクエストへの対処として不十分です。また、サーバー側は同時に到達したリクエストの二重実行も防ぐ必要があります。
2. 返金金額の上限と一部返金のバリデーション：
   • テスト入力：ある注文の実際の支払金額が 100 元であるのに対し、返金金額として 120 元を入力する。または、すでに 60 元を返金した後に、再度 50 元の返金を申請する。
   • ビジネス要件：システムは累計返金総額が実際の支払総額を超えないよう検証し、超過した返金を遮断してエラーを表示しなければなりません。
3. ネットワークタイムアウト時における状態の一貫性とリクエスト識別子：
   • テスト入力：決済ゲートウェイに返金リクエストを送信する際、ネットワークタイムアウト（明確な応答が受信できない状態）をシミュレートする。
   • ビジネス要件：ネットワークタイムアウトは「結果が不明」であることを意味します。相手側では返金処理がすでに完了しており、単に応答が届いていないだけかもしれません。システムはこの返金の一意なビジネス識別子を保持し、ステータスを「処理中／照合待ち」に設定した上で、決済サービスのインターフェース仕様に従って結果を問い合わせる必要があります。再試行が必要な場合も、仕様に従って同一のリクエスト識別子を再利用し、再試行が新規の返金として扱われないようにしなければなりません。これにはサーバー側と決済インターフェースの双方が協調して対応している必要があります。

このプロセスにおいて、AIはコードを書くという実行作業を担い、人間はルールを明確にし、境界となる入力を設計し、実際の結果を照合することで監督を遂行します。理解が具体的であればあるほど、テストは「どこが誤っており、どのように修正すべきか」を的確に指摘できるようになります。

6. 一度の理解のためにソフトウェアを作り、使い終わったら破棄する

原文抜粋：large, custom, discardable software artifacts
訳文：相当な規模を持ち、オンデマンドでカスタマイズされ、使い捨て可能なソフトウェア成果物。

1. 詳細な解説：なぜ使い捨てソフトウェアは過去には非現実的で、今や試す価値があるのか？

かつては、一度きりの意思決定のために専用のソフトウェアを制作する際、投入に見合う価値があるかを検討する必要がありました。要件を詰め、UIを組み、計算を実装し、デバッグを行って納品するまでには、いずれも多大な時間を要しました。タスクを一度しか行わないのであれば、手計算や表計算ソフトを使用したほうが合理的だったのです。

Karpathyが重視している変化は、コード生成が容易になったことで、かつてはわざわざ開発する価値のなかったツールが、今や試す価値のあるものになったという点です。目の前の課題に合わせて要件を提示し、その場限りのタスクに合致したWebページや解説動画をAIに作らせることができます。ソフトウェアの価値は、必ずしも長期的な利用にあるのではなく、ある問題を理解する手助けをしてくれることそのものから見出せます。ここでの「相当な規模」は、一時的なツールであっても十分な情報量やインタラクションを盛り込めることを意味し、「使い捨て可能」とはその寿命の短さを指すものであって、開発や検証の手間が全く不要になるわけではありません。

2. 具体的事例：イベント会場候補A/B案のコスト比較選定

以下は教育用の想定事例です。

あるチームがイベントのために2つの候補会場の間で意思決定を行う必要がありますが、最終的な参加人数がまだ確定していません：

• 会場A：固定レンタル料 1000 元、1人あたりの追加費用 80 元。総コストの計算式は 1000 + 80x。
• 会場B：固定レンタル料 4000 元、1人あたりの追加費用 50 元。総コストの計算式は 4000 + 50x。

意思決定を支援するために、AIに2つのプランのコストを比較する一時的なWebページを生成させることができます：

• 人数が 50人 の場合：会場Aは 1000 + 80 × 50 = 5000 元、会場Bは 4000 + 50 × 50 = 6500 元となり、会場Aのほうが 1500 元安くなります。
• 人数が 100人 の場合：会場Aは 1000 + 80 × 100 = 9000 元、会場Bは 4000 + 50 × 100 = 9000 元となり、両者の費用は完全に一致します。
• 人数が 150人 の場合：会場Aは 1000 + 80 × 150 = 13000 元、会場Bは 4000 + 50 × 150 = 11500 元となり、会場Bのほうが 1500 元安くなります。

今回のイベントの会場費用を計算する

前提となる見積もり：会場Aは固定費 1000 元、1人あたり 80 元。会場Bは固定費 4000 元、1人あたり 50 元。これらの費用のみを比較します。

参加人数：

100

人

A：

9000

元
1000 + 80 × 人数

B：

9000

元
4000 + 50 × 人数

100 人の時、両者の費用は同額です。

50人：A 5000 元、B 6500 元。150人：A 13000 元、B 11500 元。収容人数、アクセス、キャンセル規定は別途確認が必要です。

結果から意思決定の境界をどう理解するか？
この一時的なミニツールは、両者の費用の損益分岐点（100人）を視覚的に明示しています。人数が100人未満であれば会場Aのほうが安く、100人を超えると会場Bのほうが安くなります。この計算結果は費用の疑問に答えてくれますが、実際に会場を選択するには、さらに他の条件も加味する必要があります：

• チームが予想する参加人数が 90人から110人 という変動範囲にある場合、人数がわずかにブレるだけで優劣が逆転してしまいます。
• 実際の人数が100人のラインをまたぐ可能性がある場合、どちらが安価かも入れ替わります。さらに収容人数、交通の便、キャンセル規定なども確認しなければなりません。会場が手狭であったり、イベントの要件を満たしていなかったりすれば、費用がいくら安くても不適切です。

この会場評価を終えた後は、このWebページをそのまま閉じて破棄することができ、保守し続ける必要はありません。「使い捨て」とはソフトウェアの利用寿命が単一のタスクに限定されていることを指すのであって、内部のロジックをいい加減に作ってよいという意味ではありません。背後にある数学的境界や入力の前提条件は、依然として人間が厳密に検証する必要があります。

---

そのまま再利用できるプロンプト