はじめに
C-8までで使ってきたRaspberry Pi OSやArmbianは、「誰かがビルドしてくれた」Linuxでした。しかし製品開発では、必要なものだけを入れ、ライセンスと構成を追跡できる自前のLinux一式が欲しくなります。そのために広く使われている仕組みが Yocto Project です。
Yoctoは多機能ゆえに用語が多く、「チュートリアル通り打ったらイメージはできたが、何をしたのか分からない」となりがちです。今回はコマンド集ではなく、登場人物の相関図を作ることに徹します。ここが描ければ、C-11（AMD Zynq）・C-12（Altera Cyclone V SoC）のベンダーフローは「相関図のどこをベンダーが差し替えているか」として読めるようになります。
今回扱わない範囲：実際のビルド手順の詳細、recipeの文法、SDK生成。まず地図です。
この記事の前提
- ブートローダー、Linuxカーネル、Device Tree、rootfsの役割を大まかに把握している
- C-9までを未読でも読めますが、CPU＋FPGA SoCとの関係はC-9を先に読むと追いやすくなります
- Yoctoのコマンドやディレクトリ構成はリリースによって変わります。本記事は概念を主題とし、実際の操作は採用リリースの公式ドキュメントを優先します
Yoctoは「ディストリではなく、ディストリを作る工場」
最初の誤解ポイントはここです。Ubuntuは「できあがったOS」ですが、 Yoctoは「OSを作るためのビルドシステムと部品群」 です。成果物は主に3つ。
- ターゲット向け成果物：rootfsイメージのほか、カーネル、DTB、ブートローダー、書き込み用ファイルなど
- SDK/ツールチェーン：アプリ開発者に配るクロスコンパイル環境
- ライセンス・構成情報：何がどのライセンスで入っているかを追跡するための情報。設定によりSPDX形式の情報も生成できる
登場人物の相関図
図の上段にあるPokyは、BitBake、OpenEmbedded-Core、参照用のdistro/BSPなどを組み合わせたスターターキットです。そこへベンダーや自社のlayerを追加し、MACHINE、DISTRO、IMAGE recipeという観点で作るものを決めます。BitBakeがそれらのメタデータを読み、最終的なイメージやSDKなどを生成します。
各人物を一言ずつ紹介します。
BitBake：ビルドの実行係
makeの親玉のようなタスク実行エンジンです。「curlをビルドせよ」と言われれば、ソース取得→展開→パッチ→configure→コンパイル→パッケージ化までを、依存関係を解決しながら実行します。
recipe（.bbファイル）：部品1個の作り方
「このソースをどこから取り、どうビルドし、何をインストールするか」を書いたファイルです。busyboxのrecipe、カーネルのrecipe、自社アプリのrecipe……世界は全部recipeでできています。既存recipeへの差分は.bbappendで当てられ、他人のlayerを直接書き換えずに済む仕組みになっています。
layer（meta-〇〇）：recipeの部品棚
recipeをテーマ別に束ねたディレクトリです。コアのopenembedded-core（meta）、追加パッケージ集のmeta-openembedded、各社のBSPレイヤー（meta-raspberrypi、AMD／Altera系のFPGA向けレイヤー等）、そして自社製品のmeta-自社。「ベンダーのものは触らず、自分の変更は自分のlayerに置く」 のがYocto流の秩序です。
Poky：スターターキット
BitBake＋コアlayer＋サンプルdistroを組み合わせた参照ディストリビューションです。長く「Yoctoを始める＝Pokyを取得する」という手順が使われてきましたが、Poky＝Yocto本体ではありません。
ここまでは、私が既存製品やベンダーBSPで触れてきたPokyベースの構成を入口にしています。図は構成要素の関係を表したものであり、Pokyリポジトリの取得を必須とするものではありません。
2026年時点の補足：Yocto Project 6.0系のQuick Buildでは、
bitbake-setupを使って必要なリポジトリとビルド環境を準備する流れが標準の入口になっています。保守対象の旧版では従来のPoky取得手順、新規検証では採用版のQuick Buildというように、手順を混ぜずに読み分けます。
machine／distro／image：作るものを決める3つの観点
ここがYocto理解の核心です。「どのボード向けか」「どういう方針のOSか」「何を入れるか」 を分けて考えます。厳密には、machineとdistroは構成、imageはビルド対象となるrecipeですが、最初は次の3つの問いとして捉えると見通しが良くなります。
| 軸 | 決めること | 例 |
|---|---|---|
| machine | ボード・SoC固有：カーネル、DTB、ブートローダー、書込形式 | raspberrypi4-64 |
| distro | OSの方針：initはsystemdか、Cライブラリは何か、機能フラグ | poky |
| image | 搭載パッケージの集合 | core-image-minimal / core-image-base |
この分離のおかげで、「同じimage定義をmachineだけ替えて別ボード向けにビルドする」「同じボードで開発用と量産用のimageを切り替える」といった構成が可能です。入門手順ではbuild/conf/local.confにmachineなどを指定し、bblayers.confに使うlayerを並べます。ただし、この2ファイルだけが製品定義のすべてではありません。恒久的な製品設定は、自社のlayer、distro、machine、image recipeなどへ分けて管理します。
最小の流れ（雰囲気だけ）
地図の確認として、長く使われてきたPokyベースの流れを一度だけ載せます。
$ git clone -b <release-branch> https://git.yoctoproject.org/poky
$ source poky/oe-init-build-env # ビルド環境に入る(build/が生える)
$ vi conf/local.conf # MACHINE ?= "..." を設定
$ bitbake core-image-minimal # imageを指名してビルド
# → tmp/deploy/images/<machine>/ に書き込めるイメージ一式
この形は、私が触れてきたベンダーBSPや保守対象の旧リリースを読むときに今も出会います。現在のリリースでは前述のbitbake-setupが入口です。どちらが正しいかではなく、対象製品が採用したYoctoリリースの手順を一組で使うことが重要です。
初回ビルドは多数のソースを取得してビルドするため、対象やマシン性能によっては数時間かかります。2回目以降はsstate（共有状態キャッシュ）を再利用でき、処理時間を短縮できます。
ハマりどころ
- バージョン（コードネーム）不一致：layer同士は同じリリース系列（ブランチ）で揃えるのが大原則。混ぜるとビルドエラーの嵐になります
- ビルドマシンの要求が高い：必要容量は対象やキャッシュ設定で大きく変わり、数十GBから100GBを超えることもあります。公式のシステム要件を確認し、ビルド中の増加分にも余裕を持たせます
- local.confに書きすぎ問題：local.confは個人の作業用。製品の構成をここに書き込むと再現性が失われます。恒久的な設定は自社layer・自社distro/imageへ
-
エラーログの場所：失敗したら
tmp/work/…/temp/log.do_<タスク名>。BitBakeの画面出力だけ眺めていても原因には辿り着けません - ネット遮断環境でのビルド：ソース取得があるため、プロキシ設定やダウンロードミラー（DL_DIR共有）は企業環境では最初に整備する項目です
現場コラム：Yoctoを覚える価値は「台帳」にある
Yoctoの学習コストは正直高いです。それでも製品開発で選ばれる理由の一つは、ビルド条件を管理し、「何が入っているか」の台帳を作りやすいことだと思っています。
製品を10年保守するとき、「この出荷イメージを数年後にもう一度作れるか」「脆弱性が見つかったパッケージが製品に入っているか」「OSSライセンスの一覧を出せるか」が問われます。手作業で育てたrootfsでは、後から追うのがかなり大変です。
ただし、Yoctoを使えば自動的に製品全体の同一バイナリを再生成できるわけではありません。ソースのrevision、設定、取得物を固定し、追加したlayerやrecipeを含めて再現性をテストして初めて効いてきます。Yoctoは魔法ではなく、管理すべき情報をコードと成果物として残すための土台です。
最初に確認するのはBSPの対応ブランチ
実際の案件でYoctoを触り始めるなら、最初の一手はコマンド入力ではありません。使いたいボードのBSP layerが、どのYoctoリリースに対応しているかをREADMEやリリースノートで確認します。ここが決まれば、揃えるべき他のlayerとドキュメントの版も決まり、入口での混線をかなり減らせます。
まとめと次回
- Yoctoは「ディストリ」ではなく「ディストリを作る工場」。成果物はターゲット向けファイル、SDK、ライセンス・構成情報
- layer（部品棚）とrecipe（部品の作り方）を組み合わせ、machine／distro／imageの観点で作るものを決め、BitBakeがタスクを実行する
- 自分の変更は自社layerへ。local.confは作業用と割り切る
次回C-10.5前編は前後編です。前編では、製品へ載せるユーザーアプリの「正」をどこへ置くかを運用面から整理します。後編はさらに根拠を確認したい読者向けに、PV、PR、SRCREVとマニフェスト生成の流れをBitBakeの中から掘り下げます。その後C-11で、この地図を手に AMD Zynq-7000の開発フロー（Vivado→XSA→PetaLinux/Yocto） を歩きます。