Go 1.26（2026年3月）の新機能「//go:fix inline」：ソースレベルインライナーによるAPI移行の自動化と仕組みの解説

2026年5月1日

アップデート情報

2026年3月にリリースされたGo 1.26では、開発者のコードを最新の状態に保つための強力なアップデートが導入されました。

その中心となるのが、全面的に刷新されたgo fixサブコマンドです。

特に、新たに実装されたソースレベルインライナーと、それを制御する//go:fix inlineディレクティブは、ライブラリの作者がAPIの移行やアップデートを安全かつ自動的にユーザーへ提供することを可能にします。

本記事では、この新しいインライナーの仕組みと、なぜこれがGoのエコシステムにとって重要なのかを詳しく解説します。

目次 [ close ]

Go 1.26におけるソースレベルインライニングの導入

Go 1.26のgo fixは、特定の言語機能やライブラリの変更に対応するための個別のモダナイザー（近代化ツール）を備えていますが、その中でも「セルフサービス」型のモダナイズを実現する最初の成果が、このソースレベルインライナーです。

ソースレベルインライニングとは何か

一般的なコンパイラにおける「インライニング」は、実行効率を高めるためにコンパイラ内部の中間表現 (IR) レベルで行われる最適化です。

これに対し、今回のアップデートで導入されたソースレベルインライニングは、実際のソースコードを直接書き換えて永続的な変更を加える手法を指します。

この機能は、関数呼び出しをその関数の本体で置き換え、引数をパラメータに代入するリファクタリングを自動化します。

すでにgopls (Goの言語サーバー) を利用している環境では、エディタ上の「Inline call」機能として先行して体験できましたが、Go 1.26からはgo fixコマンドを通じてプロジェクト全体に一括適用できるようになりました。

//go:fix inline ディレクティブの役割

ライブラリの作者が特定の関数を非推奨にし、新しいAPIへの移行を促したい場合、これまではドキュメントに記載するしかありませんでした。

しかし、Go 1.26からは関数に //go:fix inline というコメントを追加するだけで、その関数を呼び出しているユーザーのコードを自動的に置換対象としてマークできます。

実践例：APIの移行と設計ミスの修正

具体的なシナリオを通じて、インライナーがどのようにコードを変換するのかを見ていきましょう。

ioutil.ReadFile から os.ReadFile への移行

Go 1.16でioutil.ReadFileが非推奨になり、os.ReadFileに移行した際、多くの開発者が手動で置換作業を行いました。

これをインライナーで行う場合、標準ライブラリ側で次のように記述されます。

package ioutil

import "os"

// ReadFile はファイルの名称を受け取り、その内容を読み取ります。
// Deprecated: Go 1.16以降、この関数は単に [os.ReadFile] を呼び出します。
//go:fix inline
func ReadFile(filename string) ([]byte, error) {
    return os.ReadFile(filename)
}

この状態で、ユーザーが自分のプロジェクトで go fix を実行すると、次のような差分が自動生成されます。

$ go fix -diff ./...
-import "io/ioutil"
+import "os"

-   data, err := ioutil.ReadFile("hello.txt")
+   data, err := os.ReadFile("hello.txt")

単なる関数のインライン化によって、「ある関数を別の関数へ置き換える」という移行作業が安全に完了します。

APIの設計上の欠陥を修正する

より複雑な例として、パラメータの順序を間違えて設計してしまった古いパッケージ (oldmath) を、正しい設計の新しいパッケージ (newmath) へ移行させるケースを考えます。

// Package oldmath は設計に問題のある古い数学パッケージです。
package oldmath

import "newmath"

// Sub は x - y を返すべきですが、パラメータの順序が y, x になっています。
// Deprecated: パラメータの順序が混乱を招くため、newmath.Sub を使用してください。
//go:fix inline
func Sub(y, x int) int {
    return newmath.Sub(x, y)
}

ユーザーのコード内で oldmath.Sub(1, 10) (10 – 1 を期待して記述) という呼び出しがある場合、go fix を実行すると次のように変換されます。

// 変換前
var nine = oldmath.Sub(1, 10)

// 変換後 (go fix 実行後)
var nine = newmath.Sub(10, 1)

単なる名前の置換ではなく、引数の順序まで正しく入れ替えられている点に注目してください。

これにより、動作を変えずにAPIの品質を向上させることができます。

また、この機能は関数だけでなく、型エイリアスや定数にも適用可能です。

//go:fix inline
type Rational = newmath.Rational

//go:fix inline
const Pi = newmath.Pi

インライナーの背後にある高度な技術

ソースコードの置換は一見簡単そうに見えますが、Goのような厳密な型システムと意味論を持つ言語では、多くの落とし穴が存在します。

Go 1.26のインライナーは約7,000行に及ぶ複雑なロジックで構成されており、以下の6つの重要な課題に対処しています。

1. パラメータの削除とバインディング

インライナーは、関数のパラメータを呼び出し側の引数で直接置き換えようと試みます。

引数が 0 や "" のような単純なリテラルの場合は容易ですが、複雑な式が複数回登場する場合、そのまま展開するとコードの可読性が低下したり、冗長な計算が発生したりします。

このような場合、インライナーは「パラメータバインディング」と呼ばれる宣言を挿入し、安全なコードを生成します。

ケース	置換方法	理由
単純なリテラル	直接置換	コードが簡潔になり副作用もないため
パラメータが複数回使われる式	`var` 宣言を挿入	値の関係性を維持し、コードの重複を防ぐため
副作用のある引数	`var` 宣言を挿入	評価順序や回数を変えないため

2. 副作用と評価順序の制御

命令型言語であるGoでは、関数の評価順序が重要です。

例えば、add(f(), g()) という呼び出しにおいて、f() の後に g() が実行されることが保証される必要があります。

インライナーは「ハザード分析」を行い、インライン化によって副作用の順序が変わるリスクがあるかどうかを判断します。

もし安全性が証明できない場合は、破壊的な変更を避けるための保守的な判断として、明示的な変数宣言を残すように設計されています。

3. コンパイル時エラーを引き起こす定数式

実行時にはエラーにならなくても、インライン化によって定数が展開されることで、コンパイルエラーが発生するケースがあります。

//go:fix inline
func index(s string, i int) byte {
    return s[i]
}

// 呼び出し側
index("", 0)

これを単純に展開すると ""[0] となり、Goのコンパイラは「定数文字列の範囲外アクセス」としてコンパイルエラーを出します。

インライナーは制約システムを用いてこのような問題を事前に検知し、安全に展開できない場合はバインディングを維持します。

4. シャドウイング (名前の衝突)

呼び出し側と関数側で同じ変数名が使われている場合、単純な置換は変数の「シャドウイング」を引き起こし、意図しない変数を参照してしまう可能性があります。

インライナーはレキシカルスコープを正確に解析し、必要に応じてインポートの追加やブロックスコープの構築を行うことで、名前の衝突を回避します。

5. 未使用変数の発生

引数として渡されていた変数が、インライン化の結果としてどこからも参照されなくなることがあります。

Goでは「未使用のローカル変数」はコンパイルエラーになるため、インライナーは変数の参照カウントを追跡し、最後の参照を削除してしまわないよう配慮します。

6. defer ステートメントの制約

defer を含む関数をインライン化すると、その実行タイミングが「呼び出し元の関数が終了したとき」まで遅延してしまい、プログラムの挙動が変わってしまいます。

func callee() {
    defer cleanup()
    // 処理
}

func caller() {
    callee() // ここで完了してほしい
    // 別の処理
}

このため、Go 1.26の go fix では、defer を含む関数のインライン化は原則として拒否されるか、匿名関数の即時実行 (func() { ... }()) に包む形でのみ提供されます。

まとめ

Go 1.26で導入されたソースレベルインライナーは、単なるテキスト置換ツールではなく、Goのセマンティクスを深く理解した「コードの美しさを最適化するコンパイラ」のような存在です。

ライブラリ作者は //go:fix inline を活用することで、ユーザーに負担を強いることなくAPIを洗練させることができ、ユーザーは go fix を実行するだけで、常に最新のベストプラクティスに沿ったコードを維持できます。

もちろん、インライナーも万能ではありません。

複雑な副作用や評価順序の制約により、生成されたコードに手動のクリーンアップが必要になる場合もあります。

しかし、このツールによって数千、数万もの非推奨な関数呼び出しが自動的に解消される未来は、Goプロジェクトの長期的なメンテナンス性を大きく向上させるでしょう。

ぜひ、自身のプロジェクトでも新しい go fix を試し、API移行の自動化を体験してみてください。