Markdown 数式レンダリングルールとトラブルシューティング
トリガーパス：3つの安全策でスキル実行を確実に
このスキルは、数式記述時に確実に実行されるよう、以下の3つのパスで動作します：
- 前提トリガー: この説明文で「数式を書く前に」というトリガーを宣言し、レンダリング失敗後の修正に依存しません。
- ワークフロー統合: リポジトリのメインスキル
math-question-skill（D:\math_question\SKILL.md）の強制ルールからこのスキルを参照します——問題解決、解説、日替わり問題のすべてでこのパスを経由します。 - 公開前自己チェック: 数式を含む出力の最終確定前に
scripts/check_inline_math.pyを実行してスキャンします。行内$...$が見つかった場合は、行間数式またはプレーンテキストに変更してから送信/書き込みを行います。
コアルール（Codexアプリ内で強制）
Codexデスクトップアプリは、独立した行の行間数式 $$...$$ のみをレンダリングし、行内数式 $...$ はレンダリングしません（公式 issue #14985 で確認済み）。数式自体は正しくても、区切り文字の使い方が間違っています：
❌ $f(x)=\sqrt[3]{x}$ ← 行内 $...$、アプリでレンダリングされない
❌ $\dfrac{f(x_0+h)-f(x_0)}{h}$ ← 行内 $...$、アプリでレンダリングされない
修正方法——数式を独立した行にし、$$...$$ を使用：
✅ よって
$$
f'(x_0)=\lim_{h\to0}\dfrac{f(x_0+h)-f(x_0)}{h}
$$
微分可能 ⟺ その極限が存在し有限である
短い行内式にはUnicode数学記号を使用し、レンダリング結果に近い見た目を実現します：
- 上付き文字/下付き文字：
xˣ（U+02E3）、10⁶、2ⁿ、x₀、x₁ - 平方根：
√x（U+221A）、∛x（U+221B 立方根） - 分数の上付き表記：
x¹⁄³（¹ U+00B9 + ⁄ U+2044 + ³ U+00B3） - 微分のプライム記号：
f′(x)（U+2032、ストレートプライム'は使用しない） - 演算子/関係記号：
·、−、±、∞、≠、≤、≥、∈
⚠️ ^(...) のようなプログラミング風の書き方は使用しない：x^(1/3) はソースコードのように見えます。∛x または x¹⁄³ に変更してください。
複雑な行内式（分数、平方根、極限）はブロックレベルの $$...$$ に分割し、無理にプレーンテキストにしないでください。
ユーザーから「行内数式を保持」と要求された場合の対応（ハードルールは変更なし）
会話中、ユーザーが「行内数式 $...$ を保持し、スペースのくっつきだけを修正してほしい」と言うかもしれません——これはアプリのレンダリング動作を変更しません。行内数式 $...$ はCodexアプリでは一切レンダリングされず、スペースを追加しても「ソースコード + スペース」になるだけで、見た目はさらに悪くなり、依然として失敗とみなされます（過去の教訓：くっつきを修正しても、ユーザーから「まだ問題がある」とフィードバックがあり、根本原因は行内 $...$ がUnicode化されていないことでした）。そのため：
- 最終確定前でもハードルールに従う：短い行内式はUnicodeに、複雑な式は独立した行の
$$...$$に変更する； - ユーザーが明示的に行内
$...$の保持を主張する場合、まず結果（アプリにソースコードが表示されること）を説明し、出力の末尾に「レンダリングに関する注意」を添付する； - ユーザーの要求で
check_inline_math.pyの自己チェックをスキップしない；[FAIL]がゼロになるまで完了とみなさない。
行内数式 → Unicode 早見表
| シナリオ | 行内LaTeX（禁止） | Unicode修正方法 |
|---|---|---|
| 単一文字変数 | $f$、$g$、$A$ | f、g、A（プレーンテキスト） |
| 上付き/下付き文字 | $x^n$、$x_0$、$a_n$ | xⁿ、x₀、aₙ |
| 根式 | $\sqrt{x}$、$\sqrt[3]{x}$ | √x、∛x |
| 分数 | $\frac1n$、$\frac{x^n}{1+x}$ | 短い式は 1/n；複雑な式は $$...$$ ブロックに分割 |
| 極限 | $\lim_{n\to\infty}a_n$ | lim(n→∞) aₙ（Unicodeに下付き矢印はないため、収束条件は括弧でlimに含める；複雑な式はブロックに分割） |
| 積分 | $\int_0^1 f(x)\,dx$ | 複雑な式は $$...$$ ブロックに分割、無理に行内に詰め込まない |
| 絶対値 | $\lvert x\rvert$ | ` |
| 集合/関係 | $x\in[0,1]$、$f\le g$ | x∈[0,1]、f ≤ g |
| 矢印 | $x\to0$、$n\to\infty$ | x→0、n→∞ |
| 省略記号 | $a_1+\cdots+a_k$ | a₁+…+aₖ |
表の中の数式（Codexアプリで2番目に多い問題）
表のセル内で $...$ はレンダリングされません。また、$$...$$ を独立した行にすると表の行が崩れます。表のセル内では数式区切り文字を一切使用しないでください：
| 方法 | 説明 |
|---|---|
❌ セルに $x^{1/3}$ と記述 | 行内はレンダリングされず、ソースコードが表示される |
❌ セルに $$x^{1/3}$$ と記述 | 複数行の区切り文字が表を崩す |
| ✅ セルにはプレーンテキスト/Unicodeのみ | ∛x、` |
| ✅ 数式は表の下に配置 | 各数式を独立した行 $$...$$ で表の後に記述 |
| ✅ 内容が主に数式の場合 | 構造化リスト（小見出し + $$...$$）を使用し、表は使用しない |
例——微分不可能な3つの例：
| 関数 | x = 0 での失敗パターン |
|---|---|
| ∛x | 垂直接線、差分商 → +∞ |
| x·sin(1/x) | 激しい振動、極限が存在しない |
表の下に数式を配置：
$$ \lim_{h\to0}\frac{h^{1/3}}{h}=+\infty $$
公開前自己チェック（30秒、最終確定時に必須）
⚠️ 先にコンソールのエンコーディングをUTF-8に設定：WindowsのデフォルトコンソールはGBKのため、スクリプト出力に日本語や絵文字（✅など）が含まれると UnicodeEncodeError または文字化けが発生します。チェックを実行する前に以下を実行：
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
$OutputEncoding = [System.Text.Encoding]::UTF8
$env:PYTHONIOENCODING = 'utf-8'
チャット返信の草稿をチェック：
python "D:\math_question\.agents\skills\markdown-math-render\scripts\check_inline_math.py" - < 草稿.txt
すでに書き込まれたファイルをチェック：
python "D:\math_question\.agents\skills\markdown-math-render\scripts\check_inline_math.py" "D:\math_question\目標ファイル.md"
- 終了コード0（出力
[OK]）→ 問題なし、送信/書き込み可能 - 終了コード0 +
[STYLE]ヒント →^(...)形式のソースコード風上付き文字（例：x^(1/3)）がある、見た目がコードのようで、∛x/x¹⁄³またはブロックレベル数式への変更を推奨（スタイル提案、ブロックはしない） - 終了コード1（出力
[FAIL]と行番号）→ 2種類の問題：行内$...$（独立した行の$$...$$またはUnicodeプレーンテキストに変更）；$$...$$が独立した行でない（$$のある行の先頭/末尾のテキストを移動）。行番号に従って修正し、[FAIL]がなくなるまで再実行
数式自体が壊れていないことの確認（30秒）
リポジトリに同梱のKaTeX CLIでTeX構文を検証：
@'
\dfrac{f(x_0+h)-f(x_0)}{h}
'@ | node scripts/node_modules/katex/cli.js
- 出力に
<annotation ...>が含まれ、終了コード0 → 数式に問題なし、区切り文字/レンダラーの問題 - ParseErrorが発生 → TeX構文エラー、先に数式を修正
一言で言えば
Codexアプリでは、数式はすべて独立した行に
$$...$$で記述；短い行内式はUnicodeの上付き/下付き文字（xˣ、f′(x)）で修飾；表のセル内には数式を入れず、数式は表の下に配置；最終確定前にcheck_inline_math.pyを実行して問題をチェックし、行内$...$は禁止。