GoogleエンジニアがLinuxカーネル向けAIコードレビューシステム「Sashiko」を公開
Linuxカーネルのコード品質を自動で審査するAIシステムが登場した。Sashiko(刺し子)はGoogleのLinuxカーネルチームのエンジニアRoman Gushchinが開発し、2026年3月17日にLKML(Linux Kernel Mailing List)で正式にアナウンスされた。Rustで実装されており、Gemini CLIを使って構築されたという。GitHubリポジトリ(sashiko-dev/sashiko)はApache 2.0で公開されている。
名前の「刺し子」は日本の刺繍技法に由来する。布を補強する刺し子のように、自動レビューでカーネルの品質を強化するという意味を込めた命名だ。
Linuxカーネル開発とメーリングリスト
Linuxカーネルの開発は、GitHubのPull Requestのような仕組みではなくメーリングリストベースで行われている。開発者がパッチ(コードの変更差分)をメールで投稿し、他の開発者がメールで返信してレビューする。このやりとりのアーカイブがlore.kernel.orgで公開されている。
Sashikoはこのlore.kernel.orgからパッチを自動取得する。取得にはNNTPプロトコルを使う。NNTPはもともとUsenet(1980年代から続く電子掲示板ネットワーク)のために設計されたプロトコルで、大量の投稿を効率的に配信・購読する仕組みだ。lore.kernel.orgがNNTPでのアクセスに対応しているため、Sashikoはこれを利用して新しいパッチの投稿をリアルタイムに検知している。
パッチ取得からレビューまでの流れ
graph TD
A[開発者がパッチをメールで投稿] --> B[lore.kernel.orgに<br/>アーカイブされる]
B -->|NNTP経由で<br/>新着パッチを検知| C[Sashiko]
C --> D[カーネルリポジトリから<br/>関連コードを取得]
D --> E[パッチ + 周辺コードを<br/>LLMに送信]
E --> F[4段階のレビュー実行]
F --> G[結果をSQLiteに保存]
G --> H[sashiko.devとCLIで<br/>結果を閲覧]
監視対象のサブシステム(メモリ管理、ネットワーク等)を設定しておくと、該当するメーリングリストに投稿されたパッチを自動でキューに追加する。ローカルのgitリポジトリから手動でパッチを取り込むこともできる。
パッチを取得したあと、Sashikoはカーネルリポジトリから周辺のコンテキスト(関連する関数・型定義・コミット履歴)を取得してプロンプトに組み込む。パッチのdiffだけだとAIが文脈を把握しづらいため、周辺コードを含めることでレビューの精度を上げる設計になっている。
4段階のレビュー
レビューは人間のレビュアーが見るのと同じような複数の観点で構成されている。
| レビュー段階 | 主な検出対象 |
|---|---|
| アーキテクチャ検証 | パッチの設計意図が適切か、既存の設計方針と矛盾しないか |
| セキュリティ監査 | メモリ安全性・権限昇格・バッファオーバーフロー |
| リソース管理分析 | メモリリーク・ファイルディスクリプタリーク・ロックの取得と解放 |
| 並行性分析 | レースコンディション・デッドロック・メモリ順序の問題 |
サブシステムごとに重視する観点が異なるため、専用のプロンプトを使い分ける。これらはChris Masonが別リポジトリ(masoncl/review-prompts)で管理している。
出力はJSON構造で、severity(critical / high / medium / low)が付いた指摘事項のリストとして保存される。
バグ検出率53.6%の前提
発表で引用されたバグ検出率53.6%には重要な前提がある。
テスト対象は「Fixes:」タグを持つLinuxカーネルコミット1,000件(フィルタなしの無作為抽出)。「Fixes:」タグは「このコミットは過去のバグを修正している」というマーカーで、つまりバグを含んでいたコミットが特定されている。Sashikoをバグが混入した時点のパッチに対して実行し、何件を検出できたかを測定した。
ポイントは、これらのバグが全件、人間のコードレビューを通過してマージされていたという点だ。つまりSashikoは「人間のレビュアーが見逃した問題」を対象にして53.6%を検出したことになる。
READMEでは45.2%(偽陽性率20%未満)という別の数値も記載されている。測定条件によって結果が変動することはGushchinも認めており、ビルドエラーやパフォーマンス問題など静的コードレビューでは本質的に検出しにくいバグ種別があることも補足している。
Gemini・Claude両対応
プロダクション環境ではGoogleが費用を負担してGeminiが使われているが、Anthropic Claudeにも対応している。
| 設定 | Gemini | Claude |
|---|---|---|
| プロバイダー環境変数 | SASHIKO_AI__PROVIDER=gemini | SASHIKO_AI__PROVIDER=anthropic |
| APIキー | GOOGLE_API_KEY または LLM_API_KEY | ANTHROPIC_API_KEY |
| モデル例 | gemini-3.1-pro-preview、Gemini Flash | claude-sonnet-4-5 |
| コンテキストウィンドウ | — | 200Kトークン(180K安全マージン設定) |
Claude側にはプロンプトキャッシング(TTL 5分)とレート制限時の自動リトライが実装されている。
Rust実装とビルド
Rust 1.86以上が必要。
git clone --recursive https://github.com/sashiko-dev/sashiko.git
cargo build --release
ストレージはSQLiteで、パッチのメタデータとレビュー結果を管理する。レビュー結果はsashiko.devのWebインターフェースとCLIの両方から参照できる。
プロジェクトには687件以上のコミットがあり、Linuxカーネルメンテナーやネットワーキングの専門家を含む13名以上がコントリビューターとして参加している(プロンプトリポジトリの貢献者含む)。
LKMLでの反応とLinux Foundation移管
LKMLアナウンス(Message-ID: 7ia4o6kmpj5s.fsf@castle.c.googlers.com)は即座に反響を呼び、Lorenzo Stoakes・SeongJae Park・Chris Masonら著名なカーネル開発者が議論に参加した。
プロジェクトはLinux Foundationへの移管が予定されている。所有権が個人や特定企業から独立する形になる。
ロードマップにはb4(メーリングリストからのパッチ適用ツール)やhkml(カーネルメーリングリストクライアント)との統合が挙げられている。さらに、レビュー結果をパッチ投稿へのリプライとして直接メールで送信する機能も計画されている。
これが実現すれば、パッチ作者がレビュー結果をほぼリアルタイムで受け取れるようになる。なお、Sashikoは「出力は確率的」と明示しており、人間のレビュアーの補完ツールという位置付けだ。