Goにおける明示的な純粋性制約の静的検査: mikotoの設計と検証

Wed, 30 Sep 2026 22:38:00 +0900

概要

Goの関数の長さと、明示的に指定した関数の純粋性に関する制約を検査するmikotoを作った。関数宣言へ//mikoto:pureを付けると、値型だけを用いた入出力、パッケージ変数へのアクセス、参照先の変更、ポインタの間接参照、呼び出し先などを検査する。実装にはGoのASTと型情報を使い、検査対象を同一パッケージ内の関数宣言に限定している。

背景にあるのは、コードの量が増えたとき、設計上の意図を毎回人間が読み直して確認することの難しさだ。「この関数は入力から結果を計算するだけ」という意図があっても、後から時刻の参照や共有状態の更新が加われば、その前提は変わる。そこで、守りたい制約をソースへ明示し、実装がその制約から外れたときに診断する形にした。

初期実装を検証すると、型パラメータを介したmapの走査や、配列ポインタの暗黙の間接参照を見逃す一方、正当なジェネリック呼び出しや括弧付き操作を拒否する問題が見つかった。PR #6ではこれらと行数計算の問題を修正した。この記事では、検査モデル、実装、修正例、検証結果を順に示し、診断がないことから何を言えて、何を言えないかを考える。

以下は学術論文のように問題設定と評価を分けた開発記録であり、一般的なGoプログラムの参照透過性を証明した報告ではない。対象は2026年9月30日のmain、commit 2235f226aaである。提案する使い方と、実装で確認できる動作も区別して書く。

1. 背景と問題設定

1.1 実装量と確認量は同じ速度で増えない

AI Codingとコードレビューについての記事では、人間がすべてのコードを同じ密度で読み続けることに依存せず、仕様、テスト、静的解析、観測性を強くするという考え方を書いた。mikotoは、そのうち機械的に確認できる設計上の制約を、小さい範囲から検査する試みになる。

コードレビューでは、個々の式の正しさだけでなく、関数の役割が変わっていないかも確認する。料金を計算する関数がデータベースを更新していないか。入力を分類する関数が現在時刻を直接読んでいないか。小さな計算のための関数に、通知、ログ出力、共有キャッシュの更新が追加されていないか。どれもコンパイラの型検査だけでは、設計上の問題としては扱われない。

こうした変更は必ずしもバグではない。時刻を読むことも、状態を更新することも、システム全体では必要だ。ただ、入力から結果を計算する部分と、外界を読み書きする部分を分けていたなら、その境界を変える判断が必要になる。コードが動くことと、意図していた責務に収まることは、別々に確かめたい。

そこで「副作用がありそうか」を都度LLMへ尋ねる前に、明確に禁止したい構文や依存先を解析ツールで調べることを考えた。診断の根拠がソース上の操作に対応していれば、変更した人は、その操作を計算部分から外すのか、関数の責務を変えるのかを判断できる。問題を見つける仕組みと、その問題をどう扱うか決める仕事を分けられる。

1.2 二つの制約を一つのツールで扱う

mikotoには、関数の長さの検査と、指定した関数の純粋性制約の検査がある。前者はすべての対象関数に適用し、後者はマーカーを付けた関数だけに適用する。長さの上限は既定で80行、-max-lines=0を指定すると行数検査を無効にできる。

両者は関連するが、同じ性質ではない。短い関数でも外部状態を複雑に変更できるし、長い関数でも値の変換だけを行える。関数を短く分割しただけで、依存先が明確になるとも限らない。行数は読む範囲を見直すための指標、純粋性制約は外部状態との関係を制限するルールとして、独立に扱っている。

一つの関数を何行までにするかは、プロジェクトの方針で変わる。80行という既定値に品質の普遍的な境界があるわけではない。同様に、すべての関数を純粋にすることも目的ではない。ファイルを開く関数、HTTP要求を送る関数、トランザクションを開始する関数には、外界とのやり取りが本来の責務としてある。

この記事で扱う問いは、「Goの任意の関数が純粋かを完全に判定できるか」より狭い。入力に対する計算へ役割を限定したい関数を明示したとき、その境界を破る操作を、どの程度小さく、説明可能なルールで検査できるか。そして、そのルールをGoの構文と型の仕組みに合わせて実装すると、どこで単純な判定が破綻するか、という問いである。

2. 純粋性をどのような性質として扱うか

2.1 外部への変更と外部への依存

純粋関数を説明するとき、「副作用がない」という言葉だけでは範囲が曖昧になる。外部状態を書き換えなくても、それを読み取って結果を変える関数は、入力だけから結果が定まらない。現在時刻を返す関数は、自分で時計を変更していなくても、同じ引数で別の値を返せる。

例えば次の二つには、異なる問題がある。

var rate = 2

func Multiply(n int) int {
 return n * rate
}

func Count(n int) int {
 rate++
 return n * 2
}

Multiplyはパッケージ変数の現在値に依存する。Countは戻り値だけ見れば同じ入力で同じ結果になるが、呼び出すことで外部状態を変更する。戻り値の決定性と、外部状態を変えないことは、分けて考える必要がある。mikotoは、指定した関数からパッケージ変数へアクセスすることを、読み書きの両方で診断する。

概念的には、引数をx、呼び出し前の外部状態をs、戻り値をy、呼び出し後の外部状態をs'として、関数の実行を次のように書ける。

execute(f, x, s) = (y, s')

外部状態を変えない: s' = s
結果が外部状態に依存しない: y = g(x)

これは説明のためのモデルで、mikotoが実際に状態空間を列挙して確認しているわけではない。また、何を外部状態と観測に含めるかで性質の意味が変わる。メモリ割り当てやGCまで含め、機械の状態が一切変わらないことを要求したら、普通の計算もほとんど成立しない。ここで関心があるのは、計算の結果と、呼び出し元や外界から観測する依存・変更の関係だ。

2.2 参照透過性との距離

参照透過性は、式をその値で置き換えても観測される振る舞いが変わらない、という考え方で説明できる。ある計算を一度行って結果を再利用することと、必要な場所で毎回実行することが同じなら、計算の置き場所や回数を考えやすくなる。

ただし、プログラムでは戻り値だけが観測対象ではない。panic、無限ループ、資源消費、浮動小数点の扱い、実行環境の違いも関わる。さらに、戻り値をGoの==で比較すればよいとも限らない。NaNのように、自分自身との比較が真にならない値もある。意味上の同じ結果と、特定の比較演算の結果を混同したくない。

mikotoのREADMEでも、検査を参照透過性の数学的な証明とはしていない。診断がなかったという結果は、現在のルールに抵触する操作を検出しなかったという結果だ。メモ化や実行順の変更を正当化する証明書が生成されるわけではない。

それでも、外部状態を読む経路と変更する経路を減らすことには意味がある。原因が入力へ寄れば、テストの条件を作りやすくなり、失敗したときに再現すべき情報も整理しやすい。普遍的な保証を得る前に、調べる範囲を小さくする効果がある。

2.3 ローカル変数の変更は許可する

外部状態を変更しないことと、関数の内部で一切代入しないことは違う。例えば整数の和を計算するとき、ローカル変数を更新して結果を蓄積しても、その変数が外へ共有されていなければ、呼び出し元の状態を変更したことにはならない。

//mikoto:pure
func Sum(n int) int {
 total := 0
 for i := range n {
 total += i
 }
 return total
}

現在のmikotoはこの関数を受理する。totalとiへの代入があるから拒否する、というルールではない。通常の代入では左辺の括弧を外し、識別子なら許可する。もしその識別子がパッケージ変数なら、別の名前参照の検査で診断する。