CI（GitHub Actions など）

CI（継続的インテグレーション）とは、push するたびにサーバーが自動で PDF をビルドする 仕組みです。手元で組まなくても常に最新の出力が手に入り、「自分の環境では通る」問題を早く検知できます。LaTeX では GitHub Actions が定番で、リポジトリをチェックアウトし、TeX Live 環境でコンパイルし、できた PDF を成果物として保存する、という流れになります。

なぜ CI でビルドするのか

push のたびに、まっさらで再現性のある TeX Live 環境 で自動ビルドされます。利点は——手元固有の設定に依存した不具合を早期に発見でき、文書が常にコンパイル可能な状態に保たれ、TeX を入れていない共著者や査読者にも 最新 PDF を渡せる、そして必要ならリリースとして公開できること。ビルド内容は .github/workflows/ 内のワークフローファイル（YAML）で定義します。

GitHub Actions の最小ワークフロー

次の YAML を .github/workflows/build.yml として置けば動きます。actions/checkout でソースを取得し、xu-cheng/latex-action でコンパイルし、actions/upload-artifact で PDF を保存します。Actions はメジャーバージョンが進むため、ここでは 2026 年時点の主要版（checkout v6、upload-artifact v7）で書いています。

# .github/workflows/build.yml
name: Build LaTeX
on: [push]
permissions:
  contents: read
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: xu-cheng/latex-action@v4
        with:
          root_file: main.tex
      - uses: actions/upload-artifact@v7
        with:
          name: PDF
          path: main.pdf

xu-cheng/latex-action は root_file が必須で、既定では pdfLaTeX を使います。エンジンを変えたいときは latexmk_use_xelatex: true または latexmk_use_lualatex: true を指定します。upLaTeX＋dvipdfmx のように細かい手順が必要な文書は、.latexmkrc をリポジトリに置いて action から同じ設定を読ませると、ローカルと CI の差を小さくできます。

この YAML は「PDF が作れるか」を見る最小形です。卒論や共同研究の原稿では、push だけでなく pull_request でも実行し、レビュー前に壊れた PDF が混ざらないようにします。アクションのメジャーバージョンは上がるので、テンプレートを長期運用するなら、依存更新の PR を受け取るか、年度ごとに公式 README を見直す日を決めます。

TeX Live 環境 — texlive/texlive イメージ

ビルドには TeX Live が必要で、latex-action は内部にそれを同梱しています。環境を細かく制御したいとき（特定パッケージ、日本語など）は、Island of TeX が提供する texlive/texlive Docker イメージを直接使えます。latest は継続的に更新されるため、再現性を重視する提出物では日付付きタグや TeX Live 年度タグに固定し、普段の検証では latest を使う、と分けると扱いやすいです。ジョブの container: に指定して、latexmk を自分で走らせる形です。

jobs:
  build:
    runs-on: ubuntu-latest
    container: texlive/texlive:latest
    steps:
      - uses: actions/checkout@v6
      - run: latexmk -pdf main.tex
      - uses: actions/upload-artifact@v7
        with:
          name: PDF
          path: main.pdf

CI で落ちたらログを読む

CI の失敗は、まず「LaTeX のエラー」「足りないパッケージ」「成果物のパス違い」に分けます。! LaTeX Error や Undefined control sequence が出ていれば文書側、File ... not found が TeX Live のパッケージ不足ならイメージや tlmgr、upload-artifact が No files were found と言うなら path: と実際の出力名を確認します。手元で通って CI だけ落ちるときは、ローカルにしかないフォント・画像・生成済み .bbl に依存していないかを疑います。

PDF を成果物に・リリースに

• actions/upload-artifact で保存した PDF は、ワークフロー実行ページから ダウンロード できます（実行ごとに保存）。
• 公開版として配りたいなら、PDF を GitHub Release に添付 する手もあります（タグ push を契機にするなど）。
• 日本語文書は texlive/texlive コンテナで latexmk を uplatex＋dvipdfmx 構成にして組むのが確実です。
• ビルド設定（.latexmkrc 等）をリポジトリに同梱しておけば、ローカルと CI で同じ手順になります。
• 提出前のワークフローでは -halt-on-error を有効にし、警告をログとして残して原因を追えるようにします。