はじめに

Linux カーネル 7.2 が、2026年8月中旬（開発陣は8月16日を狙い、修正が必要な不具合が残ればもう少しずれる可能性）に安定版のリリースを控えています。ソースツリーは4,300万行を超える巨大なもので、今回も多くの変更が入りました。

ところが、7.2 の話題には、見出しだけを読むと取り違えやすい2点があります。「Linux が RISC-V を既定アーキテクチャにした」「7.2 で AI 支援コミットが解禁された」——どちらも、そう受け取ると不正確です。この記事のいちばんの価値は、その2点を一次情報で正しく解きほぐすことにあります。取り違えやすいポイントなので、ここを正確に押さえるだけで見通しがよくなります。

  • 誤解1：RISC-V「既定化」ではない。正しくは既定のコア上限を64→256へ引き上げ＋一部 SoC の有効化
  • 誤解2：AI 支援コミットは 7.2 の新ルールではない。7.0 で既に入った公式ドキュメントが、7.2 の開発で実運用に入っている

そのうえで、7.2 に実際に入った目玉も整理します。なお「RISC-V」「アーキテクチャ」といった言葉に馴染みがなければ、次の「用語の地図」から読んでください。ここで言葉の土台をそろえてから本題に入ります。

🗓️ この記事の時点（2026年8月2日）と姿勢

本記事は 2026年8月2日時点の kernel.org 系の一次情報（公式ドキュメント docs.kernel.org）と、複数の技術媒体の報道にもとづく「stable 直前のプレビュー」です。事実と、筆者の受け止め（所感）は分けて記します。バージョンやリリース時期・一部の性能数値は報道ベースのものがあり、その旨を帰属します。数値・日付は執筆時点のものです。

🗺️ 1. 前提の整理——用語の地図（知っている人は読み飛ばしてOK）

本題に入る前に、この記事に出てくる言葉を短く地図にします。「Linux 7.2 って何？」「Ubuntu とは違うの？」「RISC-V って？」——ここが曖昧なままだと、以降の話がぼやけます。ご存じの方は次の見出しへ進んでください。

そもそも Linux 7.2 とは何か——以前は？

Linux 7.2 は、Linux カーネル（後述）のバージョン番号です。7.0 が2026年4月12日にリリースされ、その前は 6.19（6 世代は 6.19 で終わり）でした。そこから 7.0 → 7.1 → 7.2 と順に来ています。

ここで多くの人が引っかかるのが「6 から 7 に上がった＝何かすごい変化があったの？」という点ですが、答えはノーです。メジャー番号のジャンプは、大きな機能変更が理由ではありません。開発者の Linus Torvalds が「バージョンが x.19 まで来たら、次は繰り上げて x.0 にする」という慣習で運用しているためです。Linus 本人が、数字が大きくなって混乱してきたので次は 7.0 と呼ぶ、という趣旨を述べたと報じられています（報道による）。つまり 7.2 は「7 世代の3つ目」であって、特別な節目ではありません。

リリースの周期も知っておくと、記事に出てくる rc2 rc3 rc5 が読めるようになります。カーネルはおおむね9〜10週ごとにリリースされ、1サイクルは次の形です。

flowchart LR A["マージウィンドウ（約2週間）：新機能を取り込む"] --> B["安定化期間（約7週間）：rc1・rc2・…（毎週）バグを潰す"] B --> C["stable リリース"]
💡 ワード解説：rc（リリース候補）

rc は release candidate（リリース候補）の略。stable（安定版）を出す前のテスト版です。マージウィンドウで新機能を取り込んだあと、rc1, rc2, … と毎週出しながら、通常は rc7 あたりまでバグを潰していきます。本記事で「rc2 で256コア対応」「rc3 で SoC 有効化」と出てくるのは、8月中旬の stable に向けた途中経過という意味です。だからこの記事は「stable 直前のプレビュー」なのです。

Ubuntu とは違うの？——カーネルとディストリビューション

いちばん躓きやすいのがここです。「Linux カーネル」と「Ubuntu」は、別のレイヤーの話です。

💡 ワード解説：カーネルとディストリビューション

カーネルは OS の中核。ハードウェアとソフトウェアの間に立ち、CPU・メモリ・デバイスを取り仕切る「土台」の部分です。Linus Torvalds たちが開発しているのは、このカーネルだけです。 ディストリビューション（ディストリ）は、そのカーネルに、デスクトップ環境・アプリ・パッケージ管理などをまとめて、すぐ使える製品として配ったもの。Ubuntu / Debian / Fedora / Arch などがこれにあたります。一般の人が「Linux を使う」と言うとき、実際に触れているのはディストリのほうです。

関係を図にすると、こうなります。

flowchart TD K["Linux カーネル（7.0 / 7.1 / 7.2 …）＝OSの中核"] K --> U["Ubuntu"] K --> D["Debian"] K --> F["Fedora / Arch など"] K --> AND["Android（スマホ）"] K --> EMB["ルータ・家電・サーバ など組み込み機器"] U --> ME["デスクトップ環境＋アプリ＋パッケージ管理を同梱して配布"]

つまり、カーネルの新バージョンは、少し後になってディストリ経由で自分の手元に降りてくるのが普通です。実際、Linux 7.0 は Ubuntu 26.04 LTS（2026年4月23日）の既定カーネルとして載り、Ubuntu 26.10 が 7.2 を既定カーネルに採用する予定と報じられています。さらに、スマホの Android も Linux カーネルの上で動いており、ルータや家電、サーバの多くにも Linux は入っています。「自分は Linux なんて使っていない」という人も、知らないうちに恩恵を受けているわけです。

RISC-V とは何？ ほかにはあるの？

この記事のタイトルにも入っている RISC-V。これは ISA（命令セットアーキテクチャ）の一つです。

💡 ワード解説：ISA（命令セットアーキテクチャ）

ISA は、CPU が理解できる命令の決まりごと——いわば CPU の「共通語」です。同じプログラムでも、ISA が違う CPU ではそのままでは動きません（対応した形に作り直す・コンパイルし直す必要があります）。パソコンやスマホ、マイコンの中身は、どれかの ISA に沿った CPU で動いています。

主な ISA を並べると、性格の違いがはっきりします。

ISA 主な使われ方 ライセンス的な性格
x86 / x86-64 PC・サーバの主流（Intel・AMD） 各社の独自・限られたベンダーが提供
Arm スマホ・組み込み・Apple Silicon ライセンスを買って使う
RISC-V 組み込みから新興のサーバまで拡大中 オープン標準・ロイヤリティフリー（誰でも自由に実装可）

RISC-V の最大の特徴は、オープンな標準で、ライセンス料なしに誰でも実装できることです（RISC-V International は「open, royalty-free ISA」と説明）。だからこそ新興ベンダーや各国のメーカーが続々と参入していて、後半に出てくる「サーバ級の RISC-V チップが登場してきた」という話にもつながります。

✅ 実は、あなたも RISC-V を使っているかもしれない

「RISC-V なんて縁がない」と思うかもしれません。でも、Espressif の ESP32-C3 / C6 / H2 / P4 は、いずれも RISC-V コアです（一方、無印 ESP32・ESP32-S2・S3 は Xtensa という別の ISA）。つまり ESP32-C3 のボードを触っているなら、あなたはもう RISC-V を使っています。どのチップがどの ISA かは、ESP32 シリーズの選び方｜S3・C3・C6・H2・P4 の違いと使い分けで詳しく整理しています。RISC-V の ESP32-P4 を実機で動かした記録はESP32-P4 実機実録｜公式サンプルを動かすまでの壁と実測にあります。

ここまでを地図として、本題に入ります。

🧩 2. 誤解1：「RISC-V 既定化」ではなく、256コアへの地ならし

まず、いちばん誤解されやすい点から。「Linux が RISC-V を既定アーキテクチャにした」わけではありません。 そんな変更は起きていません。実際に入ったのは、RISC-V の既定設定（defconfig）の拡張です。

  • 既定のコア上限を 64 → 256 に引き上げ（Linux 7.2-rc2）。RISC-V 64bit の既定 NR_CPUS がこれまで64だったところを256へ。背景には、80コアや128コア級のサーバ向け RISC-V チップが実際に登場してきたことがある、と報じられています
  • UltraRISC SoC のサポートを RISC-V の既定 config で有効化（rc3 で反映）。具体的には UR-DP1000 など
💡 ワード解説：defconfig と NR_CPUS

defconfig は、カーネルをビルドするときの「既定の設定ファイル」。どの機能・どのハードを標準で有効にするかをまとめたものです。 NR_CPUS は、カーネルが扱える CPU コア数の上限を決める設定。ここを64から256へ上げるということは、64コアを超えるような多コアの RISC-V マシンを、追加設定なしの標準ビルドで扱えるようにする、という意味です。「RISC-V が特別扱いになった」のではなく、「サーバ級の多コア RISC-V に、標準構成で備える」地ならしだと捉えるのが正確です。

つまり、何が変わり／何は変わらないかは次のとおりです。

内容
変わったこと RISC-V 64bit の既定コア上限が 64 → 256／UltraRISC SoC が既定 config で有効に
変わっていないこと RISC-V が「カーネルの既定アーキテクチャ」になったわけではない（x86/Arm と並ぶ対応アーキの一つのまま）

組み込みや個人でいじる RISC-V ボードにとって、この変更が明日すぐ効くわけではありません。ただ、RISC-V がサーバ領域まで視野に入る段階に来たという象徴として読むと意味があります。

🤖 3. 誤解2：「AI 支援コミット」は 7.2 の新ルールではない

もう一つの誤解。「Linux 7.2 で、AI が書いたコードのコミットが解禁された」——これも不正確です。AI 支援に関する公式ドキュメントは、7.2 の新機能ではありません。

正確には、Documentation/process/coding-assistants.rst という文書が 2025年12月23日にコミットされ、Linux 7.0 で既に出荷済みです（作者は NVIDIA の Sasha Levin、承認はドキュメントメンテナの Jonathan Corbet と報じられています。この経緯・時期は報道ベースのため帰属します）。7.2 は、その既に入った既定路線が実運用の段階に入っているサイクル、という位置づけです。

では、その公式ドキュメントには何が書いてあるのか。一次（docs.kernel.org）で確認した要点は、「AI に丸投げして良い」という話とは正反対です。

⚠️ 公式ドキュメントの要点（原文にもとづく）
  • AI エージェントは Signed-off-by タグを付けてはならない（MUST NOT）。 DCO（Developer Certificate of Origin）を法的に証明できるのは人間だけ、と明記されています
  • 人間の提出者は、次のすべてに責任を負います：AI 生成コードをすべてレビューする／ライセンス要件への適合を確保する／自分の Signed-off-by を付けて DCO を証明する／その貢献に全責任を負う
  • AI の関与を示す Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] という帰属タグは、推奨（should）であって強制ではありません
💡 ワード解説：DCO（Developer Certificate of Origin）と Signed-off-by

DCO は、「このコードを貢献する権利が自分にある」ことを証明する取り決め。カーネルへのパッチには、それを示す Signed-off-by（署名）の行を付けます。今回のポイントは、この署名は人間しか付けられない＝法的な責任は人間が負う、という原則を、AI 時代に改めて明文化したところにあります。

まとめると、公式の立場は「AI にコードを書かせてもよいが、レビューも署名も責任も人間が持つ」というものです。なお、原文にはハルシネーションや機密性への直接の言及はなく、導入バージョンの記載もありません（バージョン情報は報道による）。強制のトーンではなく、Levin 自身が「強制は意図的に避けた（enforcement is deliberately avoided）」と述べた、とも報じられています。

⚙️ 4. では 7.2 の「実際の目玉」は何か

誤解を解いたところで、7.2 に本当に入った主な変更を見ます（性能値には報道ベースのものがあり、その旨を帰属します）。まず「どれが誰に効くか」で分けておくと、次の説明が読みやすくなります。

flowchart TD L["Linux 7.2 の主な変更"] L --> SV["主にサーバ・デスクトップ向け"] L --> BASE["品質・基盤の底上げ（組み込み・Cを書く人にも）"] SV --> S1["Cache-Aware Scheduling（多コアCPUを速く）"] SV --> S2["Btrfs の large folios（ファイルシステム効率化）"] SV --> S3["AMDGPU の HDMI 2.1 FRL（AMD GPUの映像出力）"] BASE --> E1["strncpy 撤廃（危ういC文字列関数の追放）"] BASE --> E2["ネットワークドライバが変更の35%超"]
  • Cache-Aware Scheduling：CPU には、よく使うデータを手元に置いておく高速で小さなメモリ（キャッシュ）があります。近年の CPU はコアが多く、しかもキャッシュが複数に分かれているため、どのコアにタスクを置くかで速度が変わります。それを賢くする仕組みで、コアの多いサーバやデスクトップで効きます。AMD Zen 5 などで効果があるとされ、あるワークロード（MongoDB）でスループット最大2倍という数値も報じられていますが、これは報道ベースで、条件依存です（断定しません）
  • Btrfs の large folios を既定で有効化：Btrfs は Linux のファイルシステム（データをディスクに記録する方式）の一つで、ext4 と並ぶ選択肢です。large folios は、メモリのページをまとめて大きな単位で扱い、その入出力を効率化する変更で、主にサーバ・デスクトップのストレージ性能に効きます
  • AMDGPU に HDMI 2.1 FRL の初期サポート：AMD の GPU ドライバに、HDMI 2.1 の高速伝送方式 FRL（Fixed Rate Link）の初期対応が入りました。高解像度・高リフレッシュレートの映像を送るための仕組みです。AMD GPU を積んだ PC 向けの話で、組み込みの読者には縁が薄い項目です
  • strncpy API の完全撤廃：strncpy は C 言語の文字列コピー関数です。コピー先のサイズ指定を誤ると、隣のメモリを壊す（バッファオーバーフロー）などの事故につながりやすく、長年「使い方を誤りやすい関数」とされてきました。より安全な代替へ6年がかりで置き換え、ついにカーネルから完全に姿を消しました。組み込みで C を書く読者には、いちばん自分事の項目です——手元のコードでも同じ関数の扱いを見直すきっかけになります
  • ネットワークドライバが変更の35%超：相変わらずネットワーク周りが開発の主戦場です
  • 配布面では、Ubuntu 26.10 が 7.2 を既定カーネルに採用予定と報じられています

🧑‍💻 5. 個人開発者・組み込み層に効くのはどれか

ここまでの前提（カーネルとディストリ、RISC-V、そして今回の中身）を踏まえて、「カーネルの話」で終わらせず読者の手元に引き寄せます。今回の 7.2 で、電子工作・組み込み・個人開発の視点から見ておくと良いのは次の点です。

  • RISC-V の256コア対応：手元の安価な RISC-V ボードに直接効く話ではありません。ただ、RISC-V が「マイコンの選択肢」から「サーバまで届く選択肢」へ広がりつつある——という流れの確認として。組み込みでの RISC-V 採用の裾野を占う材料になります
  • AI 支援コミットの原則：これは最も自分事です。個人開発でも「AI にコードを書かせて、自分が責任を持つ」場面は日常になりました。カーネルの原則（レビュー・署名・責任は人間が持つ／AIは署名できない）は、そのまま個人の開発姿勢の指針として読めます
  • 安定性・保守性の地道な改善：strncpy 撤廃のような「危ういAPIを長い時間かけて畳む」動きは、地味ですが、長く動かすコードを書く人にとって学びの多い姿勢です

RISC-V の裾野という点ではZephyr RTOS はなぜ標準になりつつあるか｜組み込み最短入門、AI にコードを書かせるツールの現在地はSpaceXAI「Grok Build」OSS公開｜Claude Codeの対抗馬かも参考になります。

🧑‍💻 6. 筆者の見方

📌 筆者の見方（カーネル開発は専門外ですが）

筆者はカーネル開発が本業ではなく、ふだんは ESP32 などの組み込み・個人開発が中心です。そのうえで、今回いちばん刺さったのは AI 支援コミットのポリシーでした。

「AI が書いてもいい。ただしレビューも署名も責任も人間が持つ」——これは、筆者の日常そのものです。手元でも Claude Code のような道具に ESP-IDF のコードを書かせることは増えましたが、最後にビルドを通し、実機で確かめ、責任を持つのは自分だという感覚は変わりません。カーネルという最も硬い現場が、それを「AIは Signed-off-by を付けられない＝法的責任を負えない」という一線で明文化したのは、個人開発者にとっても腹落ちする整理だと感じています。強制ではなく原則として置いた点も含めて、健全だと受け止めています。

RISC-V の256コア対応については、正直、筆者の手元の作業に明日効くものではありません。ただ、マイコンで馴染みのある RISC-V が、標準構成でサーバ級の多コアまで見据える段階に来た、という事実には静かに驚きます。「誤解された見出し」の裏に、こういう地に足のついた前進があること自体が、カーネル開発の面白さだと思います。政治的な評価をするつもりはなく、あくまで作る側の実感としての受け止めです。

✅ まとめ

📌 この記事のポイント
  • Linux 7.2 は8月中旬に stable 予定。ソースは4,300万行超。よく見かける2つの言い方は、いずれも不正確
  • 誤解1：RISC-V「既定化」ではない。実際は既定コア上限を64→256へ引き上げ＋UltraRISC SoC を既定 config で有効化。RISC-V が既定アーキになったわけではない
  • 誤解2：AI支援コミットは7.2の新ルールではない。7.0 でシップ済みの公式ドキュメント。原文は「AIは Signed-off-by を付けられない（MUST NOT）／DCO を証明できるのは人間だけ／Assisted-by タグは推奨で強制ではない／人間が全責任」
  • 7.2 の実際の目玉：Cache-Aware Scheduling（MongoDB最大2倍は報道帰属・条件依存）、Btrfs large folios 既定化、strncpy 完全撤廃、ネットワークが変更の35%超
  • 個人開発者に最も効くのはAIコミットの原則——「AIに書かせて、責任は人間」は日常の指針そのもの

よくある質問（FAQ）

Q. Linux 7.2 と Ubuntu は何が違うのですか？

A. レイヤーが違います。Linux 7.2 は OS の中核である「カーネル」のバージョンで、Linus Torvalds たちが開発しているのはこの部分だけです。Ubuntu は、そのカーネルにデスクトップ環境やアプリ、パッケージ管理をまとめて配る「ディストリビューション」という製品です。カーネルの新版は少し後にディストリ経由で手元に届き、実際 Linux 7.0 は Ubuntu 26.04 LTS の既定カーネル、Ubuntu 26.10 は 7.2 を採用予定と報じられています。

Q. RISC-V とは何ですか？

A. CPU が理解できる命令の決まりごと（ISA＝命令セットアーキテクチャ）の一つです。x86（PC・サーバ）や Arm（スマホ・組み込み）と並ぶ選択肢で、RISC-V の特徴はオープン標準・ロイヤリティフリーで誰でも自由に実装できる点にあります。身近なところでは、Espressif の ESP32-C3／C6／H2／P4 が RISC-V コアです（無印 ESP32・S2・S3 は Xtensa）。

Q. Linux は「6」から「7」に上がって何がすごくなったのですか？

A. メジャー番号のジャンプ自体は、大きな機能変更を意味しません。Linus Torvalds が「バージョンが x.19 まで来たら次は x.0 に繰り上げる」という慣習で運用しているためで、7.0 も節目というより通常の進捗リリースと位置づけられています（6 世代は 6.19 で終了、7.0 は2026年4月12日）。

Q. Linux 7.2 で RISC-V が既定のアーキテクチャになったのですか？

A. いいえ。RISC-V が「カーネルの既定アーキテクチャ」になった事実はありません。実際に入ったのは、RISC-V 64bit の既定コア上限を64→256に引き上げたことと、UltraRISC SoC を RISC-V の既定 config で有効化したことです。サーバ級の多コア RISC-V に標準構成で備えるための変更です。

Q. Linux 7.2 で「AIが書いたコード」が解禁されたのですか？

A. いいえ。AI 支援に関する公式ドキュメント（coding-assistants）は、報道によれば2025年12月23日にコミットされ、Linux 7.0 で既に出荷されています。7.2 の新ルールではありません。7.2 は、その既定路線が実運用に入っているサイクル、という位置づけです。

Q. カーネルは AI にコードを書かせて良いと言っているのですか？

A. 「書かせても良いが、責任は人間が持つ」という立場です。公式ドキュメントは、AI エージェントが Signed-off-by を付けることを禁じ（MUST NOT）、DCO を証明できるのは人間だけとしています。人間の提出者は、AI 生成コードのレビュー・ライセンス適合・自分の署名・全責任を負います。

Q. Assisted-by タグは必ず付けないといけないのですか？

A. いいえ。AI の関与を示す Assisted-by: タグは推奨（should）であって、強制ではありません。報道によれば、作者自身も強制は意図的に避けたと述べています。

Q. Cache-Aware Scheduling で本当に性能が2倍になりますか？

A. 「MongoDB で最大2倍」という数値は報道で伝えられたもので、CPU やワークロードに強く依存します。すべての環境で2倍になるわけではありません。本記事はこの数値を断定していません。

参考

本記事は kernel.org 系の一次情報と複数媒体の報道にもとづいて、事実関係と取り違えやすい点を整理したものです。リリース時期や一部の性能数値は執筆時点のものであり、変わり得ます。