処理方式と処理の流れ（DVI/PDF）

LaTeX は、原稿を書いている最中に結果を見せてはくれません。テキストの .tex ファイルを書き、それを コンパイル して PDF を得る——この「書いてから一括処理する」流れが TeX 流です。途中に DVI という中間ファイルを挟む経路と、いきなり PDF を出す経路の 2 通りがあります。

なぜ WYSIWYG ではないのか

TeX の行分割は 段落全体を見渡して 最適化されます。だから段落の末尾に 1 文字足しただけで、その段落の 最初の行の折り返し位置まで変わる ことがあります。これをキー入力のたびにやり直すのは計算量が大きすぎます。

そこで TeX は、画面を逐次更新する WYSIWYG（ワープロ型）ではなく、原稿を一括で処理する バッチ方式 を採ります。引き換えに「打ちながら結果を見る」ことはできませんが、全体最適な組版・文書全体での体裁の一貫性・プレーンテキストゆえの自動化という利点が得られます。

ソースから出力まで — 2 つの経路

あなたが書いた .tex をエンジンが処理します。出力のされ方には 2 系統あります。モダンな経路 では、pdfTeX・XeTeX・LuaTeX が いきなり PDF を出力 します。とくに XeTeX・LuaTeX は入力が Unicode で、OS にインストールされた OpenType フォントをそのまま使えます。

レガシーな経路 では、エンジンはまず DVI ファイルを出力します。DVI は *device independent*（装置非依存）の略で、「どの出力機にも縛られない、純粋なページの記述」です。これを dvi ドライバ が目的の形式へ変換します——dvipdfmx なら PDF、dvips なら PostScript、dvisvgm なら SVG。画面表示用のドライバは dvi ビューア と呼ばれます。日本語の pLaTeX／upLaTeX はこの DVI 経路を使います。

# Direct PDF (modern engines)
lualatex document.tex        # → document.pdf

# Via DVI (legacy route, e.g. Japanese upLaTeX)
uplatex  document.tex        # → document.dvi
dvipdfmx document.dvi        # → document.pdf

例外として pdfLaTeX は、入力こそ昔ながら（非 Unicode 寄り）ですが、DVI を介さず PDF を直接出力します。要するに「DVI を経由するか／直接 PDF か」と「Unicode・OS フォントが使えるか」は別の軸だと捉えると整理しやすいです。

補助ファイルと「2 回コンパイル」

コンパイルすると、PDF のほかに .aux（ラベルや参照の情報）、.toc（目次）、.log（記録）などの補助ファイルができます。相互参照や目次は 2 回処理が必要 です——1 回目で「第 3 章は何ページか」といった番号と位置を .aux に書き出し、2 回目でそれを読み込んで \ref や目次に正しい値を埋めます。

だから「?? と表示される」「*Rerun to get cross-references right* と警告が出る」ときは、もう一度コンパイルすれば直ります。参考文献（BibTeX/biber）や索引（makeindex）を使うと、さらに処理回数が増えます。

回数を気にしない — latexmk とエディタ

毎回手で回数を数えるのは面倒です。**latexmk** は、.aux などの変化を見て 必要な回数だけ自動で再実行 し、必要なら BibTeX/biber や makeindex も走らせ、安定したら止まります。

latexmk -lualatex document.tex   # LuaLaTeX, as many passes as needed
latexmk -pdf     document.tex     # pdfLaTeX
latexmk -c                        # clean .aux/.log and friends

VS Code（LaTeX Workshop）や TeXShop、Overleaf などの環境は、裏で latexmk を呼んでいることが多く、あなたは「コンパイル」を押すだけで済みます。さらに SyncTeX が有効なら、ソースの該当行と PDF の該当箇所をクリックで行き来できます。