IRQ（割り込み要求）の仕組みを徹底解説：PIC/APIC/MSIとチップセット、優先度・トラブル原因まで

IRQ（割り込み要求）は、ネットワークやストレージなどのデバイスがCPUに「今、処理して」と知らせる仕組みです。ただ「デバイスはCPUと直結？」「ハード/ソフト割り込みの優先度は？」「ICH/MCHは何役？」といった疑問も出がち。本記事では割り込みの流れとトラブルの捉え方を、実務目線で整理します。

IRQとは何か：割り込み要求とポーリングの違い

IRQ（Interrupt Request：割り込み要求）は、デバイスや周辺回路がCPUに対して「今すぐ相手をしてほしい出来事が起きた」と通知するための仕組みです。質問で挙げられている「デバイスがCPUの処理を中断させて注意を向けさせる」という理解は、実務上のイメージとしては概ね合っています。

ただし、CPUは“何でもかんでも即中断”するわけではありません。割り込みには種類や優先度があり、OSや割り込みコントローラが「どの割り込みを、どのCPUコアに、どの順序で届けるか」を制御します。まずは、割り込みが存在する理由をポーリング（定期的な見回り）と比較すると整理しやすくなります。

方式	仕組み	メリット	デメリット	向いている場面
ポーリング	CPUが定期的にデバイスの状態を確認する	実装が単純、タイミングが読みやすい	無駄なCPU時間が増えやすい、遅延が発生しやすい	超単純なマイコン制御、頻繁に状態を見る必要がある処理
割り込み（IRQ）	イベント発生時にデバイス側がCPUへ通知する	待ち時間のCPU消費が少ない、応答が速い	同時実行・競合の設計が難しい、ドライバの品質に依存	ネットワーク、ストレージ、USB、タイマーなどイベント駆動の入出力

割り込み処理の全体像：発生から復帰まで

IRQが発生してから実際に処理が行われるまでには、いくつかの役者が登場します。ポイントは「デバイスがCPUに直接“命令”する」のではなく、割り込みコントローラやOSの仕組みを通じて、CPUが安全な形で制御を切り替えることです。

段階	何が起きるか	主な担当	よくある落とし穴
イベント発生	デバイスが完了・受信・エラーなどを検知	デバイス（NIC/SSD/USB等）	ステータスビットのクリア忘れで割り込み連発
割り込み要求の提示	割り込み線をアサート、またはMSI/MSI-Xを送信	デバイス／PCIe	共有IRQやレベルトリガの理解不足
割り込みの集約・配信	どのIRQをどのCPUへ届けるか決め、割り込みベクタへ変換	PIC/APIC/IOAPIC/Local APIC	アフィニティ偏り、割り込み嵐
CPUが割り込みを受理	実行中の命令区切りで制御を切替、状態を退避	CPU	「割り込み＝どんな場所でも即停止」と誤解しがち
割り込みハンドラ実行	原因確認、必要最低限の処理、後続処理の予約	OSカーネル／デバイスドライバ	長時間処理・メモリ確保・スリープで不安定化
復帰	割り込み終了後に元の処理へ戻る	CPU／割り込みコントローラ	終了通知漏れやマスク解除漏れで処理が滞る

図にすると、概念としては次のような流れです（実際の配線や経路は機種や世代で差があります）。

デバイス（イベント発生）
   ↓  割り込み線 or MSI/MSI-X（メッセージ）
割り込みコントローラ（集約・優先度・配送先決定）
   ↓  割り込みベクタとしてCPUへ
CPU（状態退避 → ハンドラへジャンプ）
   ↓
ハンドラ（最小処理）＋後続処理（必要なら別枠で実行）
   ↓
元の処理へ復帰

デバイスがCPUを中断させるという理解の落とし穴

イメージとしての「中断」は役に立ちますが、実装の現実は少しだけ丁寧です。

• CPUは命令の途中で物理的に引き裂かれるわけではなく、基本的に「命令の区切り」で割り込みを受理します（アーキテクチャや状況によって例外はあります）。
• 割り込みを受理すると、CPUはレジスタやフラグなどを退避し、OSが用意した割り込みベクタ（入口）にジャンプします。
• OS側では「割り込みを受け付けない状態（マスク）」にすることもでき、緊急度の低い割り込みは後回しにできます。

つまり、割り込みは“CPUが勝手に暴走して止まる”仕組みではなく、CPUとOSが事前に決めたルールに従って、制御を切り替える仕組みです。ここを押さえると「割り込みがあるから不安定」ではなく「割り込みを扱うコードが難しいから不具合が出やすい」と腹落ちしやすくなります。

デバイスはCPUに直結しているのか：割り込み線と集約

結論から言うと、現代のPCでは「各デバイスがCPUへ1本ずつ直結」という理解はほとんど当てはまりません。理由は単純で、CPUのピン数や割り込み入力には現実的な上限があるからです。

伝統的なPC（ISAの時代）では、確かに「IRQ0〜IRQ15」のような割り込み線があり、デバイスはその線を使って割り込みを主張しました。しかし台数が増えると線が足りませんし、配線も複雑になります。そこで登場するのが割り込みコントローラです。

共有IRQという現実

「割り込み線が足りない」問題への現実的な解として、複数デバイスが同じIRQを共有することがあります。共有IRQでは、割り込みが入ったらOSは候補となるドライバに「あなたが原因ですか？」を順に問い合わせ、原因デバイスを特定します。これは便利な反面、次のような弱点もあります。

• どれか1つのデバイスが割り込みを解除し損ねると、同じIRQ上の他デバイスも巻き込んで性能低下を招く
• 原因特定のための照会が増え、割り込み処理のオーバーヘッドが上がる

PIC/APIC/MSI/MSI-X：割り込みの中継が進化してきた理由

「デバイス → CPU」の間には、世代ごとに異なる割り込み配信の仕組みがあります。用語が増えて混乱しやすいので、まずは役割で捉えるのがおすすめです。

方式	主な世代・用途	割り込みの届け方	特徴	実務で意識する点
PIC	レガシーPC	限られた割り込み線をCPUへ	線が少なく拡張性が低い	古い環境や互換モードで登場
APIC	マルチコア/マルチCPU	割り込みをベクタ化してCPUコアへ配送	多くの割り込みを扱える、配送先制御が可能	アフィニティ、優先度、分散が重要
MSI	PCI/PCIeデバイス	メモリ書き込みの形で割り込みを通知	物理線に頼らない、共有IRQ問題を減らせる	割り込み嵐の原因切り分けがしやすい
MSI-X	高速NIC/ストレージ等	MSIを拡張し複数ベクタを持てる	キュー単位で割り込みを分離できる	受信キューとCPUコアの紐付け最適化が効く

特にPCIeのMSI/MSI-Xは、感覚的には「割り込み線を引く」のではなく「割り込み用の通知メッセージを送る」仕組みです。これにより、線の共有や電気的な制約が減り、マルチコア環境でのスケーリングが改善されます。

ICH/MCHとチップセットはCPUへの伝令役なのか

質問にあるICH/MCHは、いわゆる「北橋（MCH）・南橋（ICH）」構成が主流だった頃の用語です。大づかみに言えば、MCHはメモリや高速バス、ICHはI/Oを担当していました。割り込みの観点では、ICH側にI/Oデバイスが集まるので、割り込みの発生源もICH周辺に集まりやすく、「CPUへ届ける経路の一部」になっていました。

ただし、現代のPCでは構成が変わっています。メモリコントローラがCPU内蔵になり、従来の北橋の役割がCPUへ統合され、南橋に相当する機能がPCHとして残るイメージです。

昔の呼び方	ざっくりした役割	今の構成で近いもの	割り込みとの関係
MCH	メモリ、高速バス、GPU接続など	CPU内蔵のメモリ関連機能＋CPU直結の高速I/O	CPU側に統合され、Local APICなどがより中心に
ICH	USB/SATA/オーディオ等のI/O	PCH	I/O発の割り込みの多くがここを経由して配信される

この意味で「チップセットはCPUへの伝令役か？」という問いには、「伝令役というより、割り込みの交通整理を含む経路の一部」と答えるのが正確です。割り込みコントローラがPCH側に存在したり、PCIeのルート側でMSIメッセージを受け取ってLocal APICへ届けたりと、世代ごとに実装は変わりますが、共通するのは「デバイス→集約と変換→CPU」という構造です。

ハード割り込みとソフト割り込み：言葉の混同ポイント

「ハード割り込み／ソフト割り込み」という言い方は文脈で意味がブレるため、混乱の元になりやすい部分です。多くの場面では、次のように整理すると安全です。

用語	一般的な意味	例	補足
ハードウェア割り込み	外部デバイスが起点の割り込み	NIC受信、SSD完了、タイマ割り込み	APICやMSI経由で届くことが多い
ソフトウェア割り込み	ソフトが意図的に発生させる割り込みやトラップ	x86のINT命令、システムコール	外部デバイス起点ではない
例外	CPUが検出する異常や条件で発生	ページフォルト、ゼロ除算	原因はプログラムやメモリ状態にある
ソフトIRQや下位処理	割り込み処理を分割して後段で実行する仕組み	Linuxのsoftirq/tasklet、WindowsのDPC	上のINT命令とは別物として考える

質問でいう「ハード割り込み／ソフト割り込みの優先度」を知りたい場合、まずはどの“ソフト割り込み”を指しているかを揃える必要があります。OSの用語としてのソフトIRQやDPCは、たいてい「ハード割り込みハンドラよりは後段で実行される」設計です。一方、CPU命令としてのINTや例外は、外部デバイスとは別の優先関係で処理されます。

割り込みの優先度はどう決まるか

優先度は「CPUが持つ優先度のルール」と「割り込みコントローラが持つ配送ルール」と「OSが決める実行ルール」が重なって決まります。細部はOSやCPU世代で変わりますが、実務で押さえたいのは次の観点です。

• マスクできない割り込み：代表例がNMIで、致命的なハード障害の通知などに使われます。通常の割り込みより強い扱いです。
• 通常のマスク可能なハード割り込み：多くのデバイスIRQはここに入り、OSが必要に応じて一時的に受理を止められます。
• 例外：ページフォルトなどは「今の命令の続行に必要な条件が揃っていない」ために発生します。外部デバイスIRQとは別系統ですが、体感としては割り込みのように割り込むため混同されがちです。
• ソフトIRQやDPCなどの後段処理：ハンドラで最低限のことをした後、より重い処理を後で実行する枠です。通常、ハード割り込みハンドラより低い優先度で、スケジューリングの影響も受けます。

優先度を語るときは「誰にとっての優先度か」を明確にすると破綻しません。

• 配信の優先度：どの割り込みを先にCPUへ届けるか。割り込みコントローラやベクタ設定の影響が大きい
• 実行の優先度：受け取った後に、どの程度プリエンプトできるか。OSの割り込みレベルやIRQLなどの概念が関わる

割り込み処理を軽くする仕組み：上半分と下半分

割り込みハンドラはできるだけ短くが鉄則です。割り込み中は他の割り込みやスケジューリングが制約され、遅延や取りこぼしの原因になります。そこで多くのOSは、割り込み処理を次の2段に分けます。

段	役割	代表例	やってはいけないこと
上半分	割り込み要因の特定、最小限の受領、後続処理の予約	LinuxのIRQハンドラ、WindowsのISR	重い計算、ブロッキングI/O、長時間ロック保持
下半分	時間のかかる処理を安全な文脈で実行	Linuxのsoftirq/NAPI/workqueue、WindowsのDPCやワーカ	リアルタイム性が必要な処理を全部後回しにする

たとえばネットワークでは、受信割り込みで「受信した」ことだけ確定させ、実際のパケット処理はNAPIなどの仕組みでまとめて行います。これにより、パケットが多いときに割り込みが嵐になってCPUが割り込み処理だけで埋まる事態を避けます。

割り込みが原因でエラーが起きるのか：ポインタ破損の考え方

「割り込みがエラーを生む」という表現は、現象としてはそれっぽく見えることがありますが、原因としては少しズレやすいです。多くの場合、問題の本体は次のどれかです。

• 割り込みハンドラのバグ：不正なポインタ参照、境界チェック漏れ、ロック不備など。
• 競合：割り込みはタイミングを揺らすため、普段は表に出ない競合を露呈させます。
• メモリ破損：バッファオーバーフロー等でメモリが壊れ、たまたま割り込み文脈でクラッシュする。
• DMAやデバイス設定の不整合：デバイスが不正なメモリ領域に書いてしまい、結果としてカーネル構造体やポインタが壊れる。

つまり、割り込みはトリガーになりやすい一方で、根本原因はドライバ品質やメモリ整合性、並行実行の設計にあることが多い、という捉え方が実用的です。

症状	よくある原因	切り分けの観点
特定デバイス利用時だけフリーズや再起動	割り込み解除漏れ、割り込み嵐、ドライバの競合	そのデバイスの割り込み回数が異常に増えていないか
ポインタ破損やランダムクラッシュ	Use-after-free、バッファオーバーフロー、DMA誤設定	クラッシュ地点より前にメモリ破壊が起きていないか
高負荷時だけネットが遅い、音が途切れる	割り込み分散不足、DPCやsoftirq過多、CPU飽和	コア0だけ割り込みが偏っていないか、MSI-X有効か
ログにspurious interruptのような警告	共有IRQで原因が特定できていない、設定不整合	共有IRQのデバイス一覧、UEFI設定、ドライバ更新

よくある割り込みトラブルの具体例

割り込み嵐とinterrupt storm

現象：CPU使用率が高いのにアプリが進まない、応答が遅い、ログが大量に出る。

典型原因：デバイス側のステータスクリア漏れ、ドライバが割り込み要因を正しく解消できていない、リンク不良やノイズでエラー割り込みが連発。

対処の方向性：対象IRQのカウント増加を確認し、ドライバ更新・設定変更（MSI有効化等）・ケーブルやデバイスの交換を検討します。

割り込みの偏り

現象：マルチコアなのに一部コアだけ常時高負荷、レイテンシが悪化。

典型原因：アフィニティ設定、IRQバランサの未調整、MSI-Xのキュー配置が不適切。

対処の方向性：IRQの分散（アフィニティ調整、irqbalance、RSS/RPS、キュー数見直し）で改善することがあります。

共有IRQでの相互干渉

現象：関係なさそうなデバイスを使うと別デバイスも不安定、割り込み遅延が増える。

典型原因：共有IRQ上のどれかが割り込み解除が下手、またはハンドラが必要以上に重い。

対処の方向性：MSI/MSI-Xが使えるなら移行、UEFI設定で割り込みルーティング改善、問題デバイスのドライバ更新。

LinuxでIRQの状態を確認する手順

LinuxはIRQの可視化がしやすく、原因切り分けに向いています。まずは「どのIRQが増えているか」「どのCPUで処理しているか」を見ます。

cat /proc/interrupts

この出力では、左端がIRQ番号（またはベクタ）、中央がCPUごとのカウント、右端がデバイス名です。特定行だけ異常に増えていれば、そのデバイスが焦点です。

# IRQ番号が分かったら
cat /proc/irq/<IRQ番号>/smp_affinity_list
cat /proc/irq/<IRQ番号>/actions

• smp_affinity_list：そのIRQがどのCPUで処理される設定か
• actions：どのハンドラ（ドライバ）が紐づいているか

PCIeデバイスなら、MSI/MSI-Xの利用状況を含めて確認すると原因に近づきます。

lspci -vv

Windowsで割り込み由来の不調を疑うときの見方

Windowsは内部情報が見えにくい一方、ドライバの不具合はイベントログやダンプ解析に現れます。体感の不調が「ISRやDPCの過多」由来であることも多いので、次の観点で見ます。

• 音切れ・入力遅延：ISR/DPCレイテンシが増えていないか。レイテンシ計測ツールやWPR/WPAで確認する
• ブルースクリーン：原因ドライバ名が出る場合は最優先で更新・切り分け
• デバイスマネージャ：対象デバイスのリソース競合やドライバ状態を確認
• 最小構成で再現性を見る：割り込みトラブルは周辺機器の切り離しで再現性が変わることが多い

「割り込みが原因」というより割り込み文脈で実行されるドライバコードが原因になりやすい点を意識すると、対処がブレません。

理解を固めるための実務チェックリスト

• IRQはデバイスがCPUに通知する仕組みだが、実際は割り込みコントローラとOSが配信と実行を制御する
• デバイスがCPUに直結という発想はレガシー寄りで、現代はAPICやMSI/MSI-Xで集約・メッセージ化される
• ICH/MCHはI/Oが集まる場所として割り込み経路に関与していた。今はPCH＋CPU統合が主流
• ハード割り込みとソフト割り込みは文脈で意味が変わるため、INT命令・例外・softirq/DPCを区別する
• ポインタ破損やクラッシュは割り込みそのものより、ドライバの競合・メモリ破損・DMA設定不整合を疑う

まとめ：IRQを配信の仕組みとして捉えると迷子にならない

IRQは、デバイスがCPUに注意を向けさせるための通知手段です。ただし、現代PCでは割り込みコントローラとOSの設計が前提になっており、「線が来たからCPUが止まる」という単純図式では説明しきれません。デバイス→集約と変換→CPU→ハンドラ→後段処理という流れを押さえると、優先度やチップセットの役割、そして割り込み起点で見える不具合の正体（ドライバ、メモリ、競合）まで、一貫した理解で追えるようになります。