システムプログラミング教科書OSS「coursebook」の仕組みと特徴

システムプログラミングを体系的に学び直したいと考えたとき、最初に突き当たるのは「どの教材から始めるか」という問題です。商業書籍は網羅性が高い一方で、章ごとの難易度や前提知識が購入前には見えにくく、社内勉強会で配布するには部数の問題もついてきます。

無料の OSS 教材に目を向けても、今度は別の不安が出てきます。更新が数年前に止まっていないか、断片的なメモの集まりではなく一周できるカリキュラムになっているか、そして社内資料に図や本文を引用してよいライセンスなのか。この 3 点が確認できないまま読み始めると、途中で「これは自分が求めていた教材ではなかった」と気づくことになります。

こうした判断材料を比較的そろえやすい OSS 教材のひとつが、イリノイ大学アーバナ・シャンペーン校（UIUC）の授業で使われている cs341-illinois/coursebook です。大学の 1 学期分のシラバスに対応する 18 章の本文が LaTeX ソースとして公開され、PDF・EPUB・Wiki・HTML の 4 形態が自動ビルドで配信され、さらにアクセシビリティ検査が CI で強制されています。

本記事では、このリポジトリを「自分の学習や自社の教育に採用してよいか」という観点から、章構成と前提知識、ビルド・配信パイプラインの設計、CI の品質ゲート、そして 3 分割されたライセンスの扱いという順に整理します。あわせて、同じ領域の OSS 教科書 4 件との違いも比較します。

なお本記事の記述は、公開されている README・ドキュメント・ワークフロー定義ファイル・GitHub API の返却値を読み解いた結果に基づくものです。ビルドの実行やインストールは行っていないため、所要時間や生成物のページ数といった実測値は扱いません。

coursebook とは｜イリノイ大学 CS 341 の公式教科書OSS

coursebook は、UIUC の CS 341: System Programming で使われるシステムプログラミング入門教科書のソースと、そのビルド・配信の仕組みをまとめたリポジトリです。README は本リポジトリを「高品質でオープンソースのシステムプログラミング入門教科書を収めたもの」と位置づけており、読み物としての技術ブログ集ではなく、授業で使われる教科書そのものが公開されている形になります。

リポジトリの基本データ

教材選定で最初に気になるメンテナンス状況について、数値は比較的はっきりしています。最終 push は本記事の執筆日（2026 年 10 月 7 日）の前日である 2026 年 10 月 6 日で、archived=false かつ fork=false、すなわちアーカイブもフォークもされていない現役のリポジトリです。直近のコミット履歴を見ると、2026 年 10 月初旬だけでも Unix タイムスタンプのオーバーフローに関する事実誤りの修正 PR（外部コントリビューターによる #254）、解決済み項目の一覧削除（#253）、タグ付き PDF 対応（#251）がマージされています。外部からの事実修正が取り込まれているという事実は、後述する README の目標「引用や脚注を加えて事実性を高める」が運用として機能していることの裏付けになります。

Angrave の wikibook から「教科書」へ：標準化という狙い

coursebook は、ゼロから書き起こされた教材ではありません。README には、Lawrence Angrave によるオリジナルの wikibook 実験を標準化し、その上に積み上げることを目的とする旨が明記されています。

README が掲げる目標は 4 つで、要約すると次の内容です。

1. オリジナル wikibook の品質と厳密さを、オープンさを保ったまま改善する
2. 引用・脚注・参考文献・用語集を加えて事実性を高める
3. PDF・Markdown・HTML の形式でエクスポートする
4. 自動ビルドにより、書き手が執筆に集中できるようにする

「厳密さの改善」「引用による事実性」「複数形式のエクスポート」「自動ビルド」という 4 点は、そのまま本記事の後半で扱うビルド設計と CI 品質ゲートに対応しています。つまり coursebook の特徴は、本文の内容そのものだけでなく、教科書としての品質を仕組みで担保しようとしている点にあります。

なお、このリポジトリの組織名は旧名 illinois-cs241 から cs341-illinois に変更されています（コース名が CS 241 から CS 341 に改称されたことに対応するもので、旧 URL へのアクセスは GitHub 側でリダイレクトされます）。日本語圏の古い記事やブックマークは旧 URL を指している場合があります。

18章で学べるシステムプログラミングの範囲と前提知識

教材を選ぶうえで最も知りたいのは、どこからどこまでを扱うのかという範囲です。coursebook の章順は order.yaml という 1 ファイルで管理されており、ここに並ぶディレクトリがそのまま本の章になります。

章構成（order.yaml と公式目次の対応）

- introduction/introduction
- background/background
- introc/introc
- processes/processes
- malloc/malloc
- threads/threads
- synchronization/synchronization
- deadlock/deadlock
- ipc/ipc
- scheduling/scheduling
- networking/networking
- filesystems/filesystems
- signals/signals
- security/security
- review/review
- honors/honors
- appendix/appendix
- post_mortems/post_mortems

出典: https://github.com/cs341-illinois/coursebook/blob/master/or…

この 18 ディレクトリは、公式 HTML 版に掲載された章タイトルと順序どおりに対応します。

扱う領域は、C 言語の基礎から始まり、プロセス、メモリアロケータ、スレッドと同期、デッドロック、仮想メモリと IPC、スケジューリング、ネットワーキング、ファイルシステム、シグナル、セキュリティへと進みます。ユーザー空間から見た POSIX API の世界をひととおり縦断する構成で、カーネル内部の実装読解には踏み込みません。この線引きは、後述する類似リポジトリとの比較で重要になります。

想定読者レベル：何を知っていれば読み始められるか

README は前提知識を明示しています。すなわち「プログラミング言語の授業を履修済みで、アセンブリ命令に馴染みがあること」を想定し、コードと解説はすべて C で書かれています（README は C を "the de-facto language of the Linux Kernel" と位置づけています）。

ここは「入門（introductory）」という語の解釈に注意が必要な箇所です。プログラミング自体の入門ではなく、プログラミングを一度学んだ人がシステムプログラミングに入門するための教材という意味になります。C の文法を知らない状態から読み始めると、3 章（The C Programming Language）で急に負荷が上がる構成になっています。また本文は英語で書かれており、日本語訳の存在を示す資料は確認できていません。

学習計画を立てるうえでは、公式サイトが章ごとの個別 PDF ダウンロードに加えて "One Big PDF" と "One Big EPUB" も提供している点が使いやすい部分です。1 章ずつ切り出して読む運用と、通読する運用の両方が最初から想定されています。

大学授業由来の章（Review / Honors topics / Post Mortems）の読み方

後半 4 章は、一般的な技術書にはあまり見られない構成です。review は復習、honors は学生の必読コアには含まれない発展トピック、appendix は付録、post_mortems は事後分析にあたります。大学の 1 学期分の授業運営に紐づいた章立てであるため、独学で読む場合は 1〜14 章を本体、15〜18 章を補助として扱うのが素直な読み方になります。

どのトピックが扱われるかの輪郭は、CS 341 のコース内容からも読み取れます。C プログラミング、非同期プログラミング（プロセス・スレッド・シグナル・セマフォ・ミューテックス・条件変数・競合状態・デッドロック）、メモリと仮想メモリ（ページテーブル・パイプ・アロケータ・mmap）、スケジューリング、ファイルとファイルシステム（ブロック・inode・パーミッション・ext・BtrFS・ZFS）、ネットワーキング（TCP/UDP・epoll・RPC）が並びます（出典: ACM@UIUC wiki の CS 341 ページ、担当教員は Lawrence Angrave、3 単位）。

単一のLaTeXソースからPDF・EPUB・Wiki・HTMLを生成する仕組み

ここから先は、教材としての評価とは別の軸の話になります。coursebook は 1 セットの LaTeX ソースから 4 つの配布形態を生成しており、docs-as-code のパイプラインの参考実装として読む価値があります。以下の記述は、公開されているワークフロー定義・スクリプト一覧・貢献ガイドの読解に基づくもので、ビルドの実行は行っていません。

README 冒頭のバッジが示す配布形態は 4 つです。

BUILD_FOCUS による3系統のビルド

ビルドは環境変数 BUILD_FOCUS の値（WIKI / EPUB / PDF）で分岐します。Wiki と EPUB の系統は Python 3.11 と pandoc を使い、_scripts/gen_wiki.py が order.yaml を読んで Markdown を生成します。PDF の系統は texlive/texlive コンテナ（TeX Live 2026、ダイジェスト固定）の中で LaTeX をビルドします。

ローカルでの Wiki 版ビルド手順は CONTRIBUTING.md に記載されています。

$ virtualenv -p python3 env
$ source env/bin/activate
(env) $

(env) $ python -m pip install -r requirements.txt

(env) $ mkdir out
(env) $ python _scripts/gen_wiki.py order.yaml out

出典: https://github.com/cs341-illinois/coursebook/blob/master/CO…

PDF 版は texlive-full 相当をインストールした環境で make を叩く形です。本全体と章単位の 2 通りが用意されています。

$ make main.pdf

$ make introc/introc.pdf

出典: https://github.com/cs341-illinois/coursebook/blob/master/CO…

章単位でビルドできる設計は、章別 PDF が公式サイトで配布されている事実と対応しています。勉強会で特定の章だけを扱いたい場合に、この粒度が効いてきます。なお変更を監視して自動再ビルドする ./rebuilder.sh も用意されており、こちらは inotify-tools を必要とします。

デプロイ先が4つある構成と、それを壊さないためのCI設定

配信の制御は .github/workflows/deploy.yaml にあります。master への push で起動し、Wiki への push、epub_deploy と pdf_deploy への force-push、サイト側リポジトリの起動という 4 系統のデプロイを担います。

この構成に対して、2 つの CI 設定に理由つきのコメントが添えられている点が参考になります。

ひとつは同時実行制御です。concurrency の cancel-in-progress は false に固定されています。コメントの趣旨は、デプロイが Wiki・EPUB・PDF・サイトという複数の宛先に書き込むため、途中でキャンセルすると宛先ごとに別のコミットの内容が残ってしまう、というものです。新しい push が来たら走行中のジョブを打ち切る一般的な設定を、あえて採らない判断が記録されています。

もうひとつはマトリクスの fail-fast: false です。コメントの趣旨は、WIKI と EPUB は独立したデプロイ先であり、既定の fail-fast では WIKI の失敗が EPUB のジョブをキャンセルしてしまう、そうすると EPUB 自体は健全なのに epub_deploy が黙って古いまま取り残される、というものです。

認証まわりの経緯もコメントに残されています。かつて使われていた暗号化デプロイキー（site-deploy.enc / wiki-deploy.enc）はもはや認証できず、リポジトリにデプロイキーが登録されていないため push が権限エラーで失敗していた、原因は組織名のリネームで失われた可能性が高い、という記述です。現在は組み込みの GITHUB_TOKEN で push する方式に変更され、ローテーション対象のシークレットを持たずリネームにも耐える形になっています。サイト側リポジトリの再ビルド起動のみは別途デプロイキー（SITE_DEPLOY_KEY）を使い、シークレットが未設定の環境（フォークなど）ではサイトデプロイを失敗させずスキップします。

こうした「なぜこの設定なのか」がワークフロー定義の中にコメントとして残されている点は、自社でドキュメント基盤の CI を設計する際に真似しやすい部分です。

ツールチェーンを厳密にピン留めする理由

依存関係のバージョン指定も細かく、_scripts/install.sh には各ピンの理由がコメントで書かれています。

Python 側の依存は requirements.txt に 5 行で収まっています。

panflute==2.3.1
PyYAML>=4.2b1
Jinja2>=2.10.1
requests==2.33.0
python-dateutil==2.7.5

出典: https://github.com/cs341-illinois/coursebook/blob/master/re…

ピンの理由が「このバージョン以降でないとアクセシビリティ機能が働かない」という形で言語化されているため、将来バージョンを上げる判断をするときに何を確認すればよいかが追えるようになっています。

アクセシビリティをCIで担保する品質ゲート

coursebook のビルドで最も目を引くのは、アクセシビリティに関する検査が CI で強制されている点です。_scripts/Readme.md には、issue #238 に紐づくゲート記号つきでスクリプトの役割が列挙されています。

alt テキストを必須にするゲート

alt テキストの決定ロジックは alt_text.py に集約されており、alt= キーがあればそれを使い、なければ figure のキャプションを使い、どちらもなければビルドを失敗させます。つまり「図には説明を付ける」という方針が、レビュー時の指摘ではなくビルドの成否として強制されています。

貢献ガイドはさらに一歩踏み込んでいて、lint は alt テキストが存在することしか証明できず、書かれた文章が正しいか有用かは判定できないため、alt= 値や figure を追加・変更する PR には変更した alt テキストと該当図の対応リストを添えることを求めています。自動検査と人間のレビューの役割分担が明文化されている例です。

タグ付き PDF と PDF/UA-2 検証

PDF 側のゲートはタグ構造に踏み込みます。

タグ付き PDF ビルドの設計メモは docs/pdf-tagging-spike.md にまとめられています。docs/ 配下はこの 1 ファイルのみで、設計判断の記録場所として使われています。

フォーマット間の整合性と、デプロイ後の再検査

B4a は「タグを付けた PDF と付けない PDF で、ページ数と語が変わっていないこと」を確認します。アクセシビリティ対応のためにタグを入れた結果、本文の見え方が変わってしまうことを防ぐ検査です。A4 の pandoc AST 比較も同じ発想で、変換の前後で要素数がどれだけ変わったかを報告し、引用が消えていないかを確認します。

さらに deploy.yaml には、デプロイ後に走るスモークチェックが定義されています。EPUB については epub_deploy ブランチから公開中の main.epub を取り出して epub_check.py にかけ、続けて EPUBCheck を --failonwarnings 付きで実行します。wiki については公開中の wiki を clone して wiki_check.py にかけます。コメントには、ローカルビルドに対しては既に同じ検査を走らせているが、ここで見つけたいのは「別のものが公開されてしまったデプロイ」であり、失敗した場合は master が壊れた EPUB か wiki を公開している状態なので当該コミットを revert すること、という運用まで書かれています。

読者が受け取る成果物そのものを検査対象にする、という考え方は、教材に限らず公開ドキュメントの品質管理に転用できる設計です。

ライセンスが3分割されている理由と二次利用の注意点

社内勉強会で使う、あるいは自社ドキュメントに図を引用する、といった用途を考える場合、ライセンスの確認が避けられません。ここで coursebook には注意点があります。

なぜ GitHub 上で「ライセンスなし」と表示されるのか

GitHub API でこのリポジトリのメタデータを取得すると、license フィールドは null を返します。SPDX ID が特定されていない、つまり GitHub のライセンス検出が効いていない状態です。

ただしこれは「ライセンスが未設定」という意味ではありません。理由は、リポジトリ直下の LICENSE がファイルではなくディレクトリであり、その中に複数のライセンスファイルが置かれているためです。GitHub のライセンス検出は単一の LICENSE ファイルを前提とするため、この構成では SPDX ID を一意に決められず null になります。

採用判断の場面では、この null 表示を「ライセンス未設定なので使えない」と読み違えて検討を打ち切ってしまうのが最もありがちな誤りです。実態は逆で、資産の種別ごとにライセンスが書き分けられています。

3つのライセンスがカバーする範囲

LICENSE/README.md に方針が記載されており、内訳は次のとおりです。

LICENSE/README.md の記述の要旨は、本プロジェクトは原典 wikibook を LICENSE.original のライセンス下でリミックスしたものであり、ソフトウェア貢献分は NCSA ライセンス、自動ビルドが生成する PDF は CC BY 4.0 であって、PDF や Markdown をコピーして何らかの著作物に使う場合は著者表示が必要、というものです。原典 wikibook 由来部分の著者表示については、リポジトリ直下の AUTHORS を参照する形になっています。

社内利用・二次利用で確認すべき点

典型的な利用シナリオごとに、どのファイルを読むべきかを整理すると次のようになります。

• 公開 PDF を社内勉強会の資料としてそのまま配る → 配布対象はビルド成果物なので LICENSE.output（CC BY 4.0）が起点になります。著者表示の要否と方法を確認してください
• 章の図や本文の一部を自社ドキュメントに引用する → 同じく成果物の利用にあたるため LICENSE.output を確認し、該当箇所が原典 wikibook 由来かどうかで LICENSE.original（CC BY 3.0）と AUTHORS の確認が追加で必要になる可能性があります
• ビルドスクリプトや LaTeX マクロを自社のドキュメント基盤に流用する → ソフトウェア貢献分なので LICENSE.code（NCSA）を確認してください

本記事はどのシナリオについても可否を断定しません。ライセンス文の解釈と、自社での利用形態がそれに収まるかの判断は法務確認の領域です。ここで押さえておきたいのは、GitHub 上の null 表示を理由に判断を止める必要はなく、読むべきファイルは LICENSE/ ディレクトリ配下に 3 つある、という点に尽きます。

類似のOSS教科書との違い

システムプログラミング周辺には、同じく無料で読める OSS 教材が複数あります。選択肢を並べたうえで、coursebook がどの位置にあるかを確認します。以下はいずれも 2026 年 10 月 7 日時点の GitHub API 取得値です。

選定の判断軸は、対象レイヤ・体系性・更新状況・ライセンス明示度の 4 つに整理できます。

angrave/SystemProgramming は coursebook の母体にあたる原典です。GitHub Wiki 上にクラウドソースで書かれた「実験」であり、リポジトリ本体に本文ソースを持たないため言語検出も効いていません。最終 push は 2020 年 1 月で実質的に止まっています。coursebook は同じ内容を LaTeX ソースにリミックスし、引用・脚注・用語集・自動ビルド・CI 検査を加えた標準化版に相当します。学習目的で原典を選ぶ理由は薄く、coursebook 側を見るのが素直です。

sysprog21/lkmpg は同じ LaTeX ベースの OSS 教科書ですが、対象がカーネルモジュール開発です。ユーザー空間から POSIX API を使う側を扱う coursebook とはスコープが重なりません。ライセンスは OSL-3.0 の単一指定で、coursebook の 3 分割構成とは対照的に明示度が高くなっています。両者は競合ではなく、coursebook を一周したあとに読む教材という関係に近いものです。

0xAX/linux-insides は Linux カーネル内部実装の読み解きで、5 件のなかで最も読まれています（スター 33,625）。ただし説明は "A book-in-progress"、つまり書きかけの本であり、1 学期分のカリキュラムとして完結しているわけではありません。coursebook は 18 章で授業 1 期分に対応する章立てを持つ点が異なります。抽象レイヤも 1 段下なので、順序としては coursebook のあとに読む位置づけです。

remzi-arpacidusseau/ostep-code は、OS の定番教科書 OSTEP（Operating Systems: Three Easy Pieces）の章別サンプルコードを収めたリポジトリです。本文は ostep.org 側の PDF で提供され、このリポジトリ自体は教材本体ではありません。最終 push は 2023 年 11 月です。coursebook は本文ソース・ビルド・配信・品質検査までを 1 リポジトリに収めており、この一体性が構成上の違いになります。

まとめると、ユーザー空間の POSIX API を体系的に一周したいなら coursebook、カーネルモジュールを書きたいなら lkmpg、カーネル内部を読みたいなら linux-insides、OS 理論を教科書で学びたいなら OSTEP 本体という住み分けになります。

どんなエンジニア・チームに向くか

ここまでの事実から、公開情報の範囲で読み取れる適合条件を整理します。

向くケース

• C とアセンブリの素養があり、OS 寄りの層を体系的に一周したい個人。プロセス・メモリ・スレッド・同期・ネットワークが 18 章の一本道に並んでおり、どこから手を付けるかを自分で設計する必要がありません
• 社内勉強会を章単位で分割して進めたいチーム。公式サイトが章別 PDF を配布しており、ビルド側も make introc/introc.pdf のように章単位のターゲットを持つため、1 回 1 章の運用と構造が合っています
• docs-as-code のパイプラインを設計しようとしているチーム。単一ソースから 4 形態を生成する構成、理由つきのバージョンピン、alt テキストを必須にする lint、デプロイ後の再検査といった要素が、参考実装として読み取れる形で公開されています
• 教材の品質保証の根拠を確認したいチーム。図の説明や引用の整合性が人手のレビューだけでなく自動検査で担保されているため、「この教材を信じてよいか」の判断材料が仕組みとして確認できます

向かないケース・代替候補

• C 言語をこれから学ぶ読者。README が前提知識を明示しているとおり、プログラミング言語の授業を履修済みであることが想定されています。C そのものの入門書を先に挟む必要があります
• カーネル内部の実装を読みたい読者。coursebook はユーザー空間側が対象です。lkmpg（カーネルモジュール）や linux-insides（カーネル内部）が該当します
• 日本語の教材が必要な読者。本文は英語で書かれており、日本語訳の存在を示す資料は確認できていません。チーム内に英語ドキュメントを読む習慣がない場合、勉強会の運用コストとして見積もる必要があります
• OS の理論体系から入りたい読者。coursebook は API と実装寄りの構成です。理論からの導入を求める場合は OSTEP 本体が候補になります

判断がつきにくい場合は、まず公式 HTML 版の目次を開いて 3 章（The C Programming Language）と 5 章（Memory Allocators）を数ページ読むのが手早い確認方法です。この 2 章の記述密度が、通読したときの負荷の目安になります。

まとめ

coursebook は、大学の授業で現に使われているシステムプログラミングの教科書が、本文ソース・章立て・ビルド・配信・品質検査まで含めてまるごと公開されている OSS です。

採用判断の要点を一文ずつで振り返ると、カバー範囲はユーザー空間の POSIX API を 18 章で縦断するもので、前提知識は C とアセンブリの素養、メンテナンス状況は 2026 年 10 月 6 日が最終 push でアーカイブもフォークもされていない現役、ライセンスは GitHub 上では null と表示されるものの実態としては LICENSE/ 配下で 3 分割されており成果物の二次利用は CC BY 4.0 が起点、類似リポジトリとの違いは対象レイヤと体系性にある、という整理になります。

読み方は 2 通りあります。ひとつは学習教材として、公式サイトの章別 PDF を 1 章ずつ消化していく読み方です。もうひとつは docs-as-code の参考実装として、単一ソースからの多形態生成と CI による文書品質検査の設計を読む読み方です。前者が目的なら公式 HTML 版から、後者が目的ならリポジトリ本体の _scripts/ と .github/workflows/ から入るのが近道です。

関連情報

社内の技術教育の仕組みづくりや、ドキュメント基盤・CI パイプラインの設計をご検討中の方は、お問い合わせフォームからご相談ください。要件が固まっていない構想段階からでもご相談いただけます。