コンピュータプログラミングの用語で制御の反転（Inversion of Control、IoC）とは、なんらかの種類のプログラムにおいて、プロシージャを「呼び出す側」と「呼び出される側」が、従来のプログラムとは逆になるようにする、ということである。たとえば従来の、シェルのコマンドで実行される古典的なアプリケーションではメインループが最上位で動いており、そこからライブラリなどのAPIを呼ぶのに対し、ウェブブラウザ中で実行されるJavaScriptアプリケーションでは、各種のハンドラがブラウザから呼ばれてアプリケーションが動く、というのも大きく見ればそのような「反転」の一種と言える。これが使われる一例としては、プログラムのモジュール化を促進して、その拡張性を高めるために用いられている[1]。用語として Inversion of Control を略した IoC を広めたのはロバート・マーティンとマーティン・ファウラーらである。IoC は彼らの「依存性反転原則」とは関係しているが異なるものである。依存性反転原則は、共有された抽象化を通じて、高次と低次の抽象化レイヤー間の結合度を下げることを示している。従来からのプログラミングでは、フローはコードの中核部分で制御されている。IoCを使うと、これが全く変わってくる。呼び出し側は応答を得るが、いつどのようにして応答を得るかは呼び出し側が制御できない。逆に呼び出された側がいつどのようにして応えるかを決定する。
概要

従来式のプログラミングでは、例えば、あるアプリケーションのmain関数が、メニューライブラリ内の関数を呼び出して、利用可能なコマンドの一覧を表示し、その中のどれか一つの機能をユーザーに選ばせる[2]。するとそのライブラリはユーザが選んだ項目を、関数呼び出しに対する戻り値として返し、するとmain関数がその戻り値を使って、関係する命令を実行する。このスタイルはテキストユーザインタフェースでは一般的である。たとえば、電子メールクライアントであれば、スクリーン上に「新着メールを読み込む」、「このメールに返信する」、「新規メール作成」などのコマンドが表示されており、ユーザがいずれかのコマンドを選択するまで、プログラムの実行はブロックされた状態になる。

一方、制御の反転を使うと、このプログラムは、汎用的な振舞いやグラフィック要素を持っているソフトウェアフレームワークを使って書かれることになるだろう。そうしたフレームワークには、たとえばウィンドウシステムや、メニュー、マウス制御などが既に組み込まれている。個別に開発するコードは、フレームワークの「空白部分を埋める」ものになる。たとえば、メニュー項目の一覧を与えるとか、それぞれのメニュー項目に対応するサブルーチンを登録するといったものだ。一方、ユーザの操作を監視していて、ユーザがメニュー項目を選択したときに、それに対応するサブルーチンを呼び出すのはフレームワークの側だ。メールクライアントの例で言えば、フレームワークはキーボードとマウスの両方の入力を追う事が出来ていて、いずれかの方法によりユーザがコマンドを実行した場合に、その命令を呼び出す。それと同時に、新着メッセージがないかどうかを見るためにネットワーク・インターフェイスも監視しており、何らかのネットワーク活動を検知した場合には画面を更新する。それと同じフレームワークが、表計算プログラムやテキストエディターの骨組にも利用できる。逆に、フレームワークは電子メールクライアントや、表計算や、テキストエディターについては何も知らない。それらの機能の実現には個別に実装されたコードを使っているからである。

制御の反転ということは、再利用可能なコードと、個別目的のためのコードは、たとえそれらが一つのアプリケーションの中で一緒に動くものであるとしても、それぞれ独立したものとして開発されるということを暗黙的に言っている。ソフトウェアフレームワーク、コールバック、スケジューラ、イベントループ、依存性の注入は、制御の反転の原則に従ったデザインパターンの例である。しかし、制御の反転という用語は、オブジェクト指向プログラミングの文脈の中で最もよく使われる。

制御の反転は以下のような設計目的のために使われる：

あるタスクの実行を実装から分離するため

あるモジュールを、目的とするタスクだけに集中させるため

モジュールを作る際に、他のシステムが何をどのようにするかについて仮定しながらコーディングすることから解放し、そのかわり契約に依拠してコーディングするため（契約プログラミング）

モジュールを置き換える際の副作用を予防するため

ハリウッドの原則

制御の反転は冗談として時々「ハリウッドの原則」と呼ばれることもある[3]。つまり「君の方から電話してこないで。君が必要な時はこっちから電話するから」ということである（つまりここでの「ハリウッド」は、いわゆる「買い手市場」の代名詞ということである）。冗談ではあるが、「電話する」という英語の動詞 call と、サブルーチン呼出（subroutine call）の call を掛けたダジャレになっている（英語では）。
背景

そもそも、コンピュータ科学ないしはソフトウェア工学などの観点から、これは何か斬新なアイディアというわけではない。IoC という言葉を広めたマーティン・ファウラー自身も[4]起源は1988年に遡るとしている。この考え方は、階層による抽象化とよく似ている。それが21世紀になって IoC という略称とともに広がったのは、Java など新しい環境が広く使われるようになり、そのプログラマも増えたといったような背景がある。これは、そのような設計原則に開発者の目を惹きつけ、その重要性を再認識させた。Javaの世界ではこの用語が一定の認知を得た。また、特定のプログラミング言語に依存しないアーキテクチャを述べる際にも好んで使われる。

制御の反転がデザインパターンなのか、それともアーキテクチャの原則なのかは議論が分かれている。Shivprasad Koirala の記事では[5]、「制御の反転」はデザインパターンとしての「依存性の注入」と組み合わせて語られており、そこでは依存性の注入がデザインパターンで、制御の反転は依存性の注入を使って実装されるとしている。一方 Mani Malarvannan の記事では[6]、「制御の反転」は文脈化された参照 (contextualized lookup) を使ったデザインパターンとして紹介されている。サービスロケータを使ったものも同じデザインパターンだとされている。

ロバート C. マーチン（英語版） の記事 The Dependency Inversion Principle では[7]、階層による抽象化と共に論じている。