効果システムとモナド（副作用の型付け）

なぜ副作用を型で追いかけるのか

純粋な関数は、同じ引数なら必ず同じ結果を返し、外界に何の痕跡も残しません（参照透過性）。ところが現実のプログラムは、ファイルを読み、乱数を引き、例外を投げ、グローバル変数を書き換えます。これらが副作用（side effect）です。問題は、ふつうの型シグネチャ Int -> Int を見ても、その関数が裏でログを吐くのか、DBを叩くのかが一切分からないこと。効果システム（effect system）は、この「見えない作用」を型に書き出し、純粋な計算と作用を持つ計算を型レベルで区別します。こうすると、どの関数がIOを行うか、どこで失敗しうるかをコンパイラが追跡でき、テスト容易性や並行化の安全性が型から導けるようになります。

この記事の出発点は、副作用を「型の中に閉じ込めて値として扱う」という発想です。その値の代表例がモナドであり、より新しい解法が代数的効果です。

モナド：効果を持つ計算を値にする

モナドは、ひとことで言えば「効果を伴う計算」を表す型コンストラクタ M と、それを安全に合成する2つの操作の組です。型は次の2つで構成されます。

• return（または pure）: 普通の値 a を、効果のない計算 M a に持ち上げる。型は a -> M a。
• bind（演算子 >>=）: 計算 M a の結果を取り出して次の計算へ渡す。型は M a -> (a -> M b) -> M b。

要は、bind が「前の計算が成功したらその値を使って次へ進む」という逐次合成を一手に引き受けます。重要なのは、bind の中に「効果をどう繰り越すか」のロジックを閉じ込められる点です。利用者は M a と a -> M b をつなぐだけで、状態の引き回しや失敗の早期脱出を意識せずに済みます。

モナドが満たすべきモナド則は3つ。return を左に置いても右に置いても素通りすること（左単位則・右単位則）と、bind のネストの結合順が結果に影響しないこと（結合則）です。これらは「合成しても壊れない」ことの保証で、bind のチェーンを安心して書き換えられる根拠になります。

-- bind の型と、do 記法による糖衣
program :: IO ()
program = getLine >>= (\name -> putStrLn ("Hello " ++ name))

-- 上は do 記法だと「手続き的」に見える
program2 = do
  name <- getLine           -- IO String から String を取り出す
  putStrLn ("Hello " ++ name)

代表的な3つのモナド：IO・State・Either

モナドが強力なのは、M を差し替えるだけで「逐次合成」という同じ骨格にまったく違う効果を載せられるからです。

IOモナドは、ファイル読み書きやコンソール出力といった外界作用を「実行手順を記述した値」として包みます。IO a という値は作用そのものではなく作用のレシピで、ランタイムが評価して初めて実際に走ります。これにより「副作用を起こす関数」も純粋な値として型に表れ、Int -> IO Int を見れば作用ありと一目で分かります。

Stateモナドは、状態 s を明示的に持ち回る計算を表します。本質は State s a = s -> (a, s)、つまり「状態を受け取り、結果と新しい状態を返す関数」です。bind がこの状態の受け渡しを自動化するため、グローバル変数を使わずに状態更新の連鎖を純粋に書けます。

Eitherモナドは失敗を型で表します。Right は成功値、Left はエラーを運び、bind は Left に出会うと残りの計算をスキップします。これは例外処理を型安全に置き換えるもので、「どんなエラーが起こりうるか」が戻り値の型 Either e a に明記される点が、投げて捕まえる例外との決定的な違いです。失敗の有無を呼び出し側が無視できないよう、コンパイラが強制します。

モナドの数理的な背景

モナドは関数型プログラミングの発明品ではなく、圏論から借りてきた概念です。圏論的には、モナドは自己関手 M に2つの自然変換 unit（return に対応）と join :: M (M a) -> M a を添えた構造です。join は「二重に包まれた計算」を一重に潰す操作で、bind は fmap と join の合成（m >>= f = join (fmap f m)）として定義できます。つまり bind の本質は「計算の中で生まれた計算を、外側の計算へ平坦化する」ことにあります。

この発想を計算機科学に持ち込んだのがE. モッジで、副作用・非決定性・例外といった多様な「計算の様態」を M という1つの枠で統一的に扱えることを示しました。P. ウォドラーがこれを純粋関数型言語の実用的な道具へ翻訳し、IOモナドが生まれます。型から作用を追える効果システムの礎は、ここにあります。型と計算の対応という大きな見取り図は型理論の基礎につながっています。

モナド変換子と、その限界

実務では「IOもしたいが失敗も型で扱いたい」のように、複数の効果を同時に使いたくなります。素朴には IO (Either e a) のように入れ子にしますが、こうすると bind が二重になり、内側の Either を毎回開け閉めする定型コードが氾濫します。これを解決するのがモナド変換子（monad transformer）で、ExceptT e IO a のように既存モナドへ別の効果を「重ねて」合成済みの bind を提供します。

ただしモナド変換子には実務上の痛点があります。第一に、効果を重ねる順序が意味を変えます（StateT s (ExceptT e IO) と ExceptT e (StateT s IO) では失敗時に状態を巻き戻すか保持するかが変わる）。第二に、スタックが深くなると lift で各層を貫通する記述が増え、型も読みにくくなります。第三に、変換子は互いに自由に組み合わせられず、合成が線形にしか伸びません。この窮屈さへの不満が、次の代数的効果を生む動機になりました。

代数的効果ハンドラ：発生と解釈を分ける

代数的効果（algebraic effects）は、副作用を「効果操作の呼び出し」と「その操作をどう解釈するか（ハンドラ）」に分離する仕組みです。プログラム側は perform Read のように効果を発生させるだけで、その効果が実際に何をするか（ファイルから読むのか、テスト用の固定値を返すのか）は、外側に置いたハンドラが後から決めます。これは例外の try/catch を一般化したもので、決定的な違いは「ハンドラが処理を継続できる」点にあります。

その核心が継続（continuation）です。効果が発生するとプログラムはハンドラへジャンプしますが、このとき「効果発生地点から先の残りの計算」が継続としてハンドラに渡されます。ハンドラは値を計算して継続を呼び出し、効果発生地点へ戻ることができます。例外がスタックを巻き戻して二度と戻らないのに対し、効果ハンドラは継続を1回呼べば通常の関数のように再開し、複数回呼べば計算を分岐させて非決定性すら表現できます。

// 疑似コード：効果の発生（perform）とハンドラ（handle）の分離
function readConfig() {
  let host = perform Read("host")   // 効果を発生させるだけ
  let port = perform Read("port")
  return host + ":" + port
}

handle readConfig() with {
  Read(key), resume ->              // resume が「残りの計算」＝継続
    resume(lookupEnv(key))          // 値を渡して発生地点へ戻る
}
// 別のハンドラに差し替えれば、同じ readConfig をテスト用の固定値で動かせる

モナド方式と代数的効果方式の比較

両者は排他ではありません。代数的効果はしばしば「自由モナド」（free monad）として型付けでき、効果システムの型がどの効果を許すかを <Read, Write> のような効果行（effect row）として関数の型に並べます。つまり代数的効果も、副作用を型に書き出すという効果システムの目標を、モナドとは別経路で達成しているわけです。

まとめ：副作用を「値」と「型」に落とす

効果システムの本質は、見えない副作用を型に書き出してコンパイラの監視下に置くことです。モナドは効果を持つ計算を値 M a として表し、bind で逐次合成する古典的な解。IO・State・Either は同じ骨格に違う効果を載せた具体例で、とりわけ Either による失敗の型付けは例外処理を型安全にします。代数的効果ハンドラは効果の発生と解釈を継続で分離し、モナド変換子の合成難を回避する新潮流です。

いずれの方式も、参照透過な核を保ったまま外界と関わるという同じ目標を、純粋な関数とイミュータビリティを土台に追っています。Either や IO がそもそも代数的データ型で表されることを思い出せば、効果の型付けが型システム全体と地続きであることが見えてくるはずです。