AIのGo変更を守るAST検査とコンパイル時計装
POINT
- AIエージェントが変更したGoコードは、ASTベースの構造検索で禁止パターンを機械的に止められる。
- OpenTelemetry Go Compile-Time Instrumentation v1は、ソース変更なしでビルド時に計装を注入し、実行後の影響を追える。
- 静的な差分検査と実行時テレメトリーを組み合わせると、小規模チームでもレビュー対象を絞りやすい。
AIのGo変更を、テストだけで判断しない
CodexやClaude Codeは、複数ファイルにまたがる修正を短時間で作成する。一方で、テストが通っても、既存の設計ルールを崩す変更や、依存先への呼び出しが増える変更は残りうる。
確認は二層に分ける。 マージ前は構造検索で「書いてはいけない形」を検査し、実行後は計装によってHTTP、DB、RPCの振る舞いを観測する。人は全行を追う代わりに、検査で止まった差分と観測値の変化に集中できる。
構造検索で、コードの形を検査する
文字列検索では、改行や変数名が異なるだけで同じ実装を見逃す。ASTベースの構造検索は構文木を対象にするため、関数呼び出しやエラー処理など、コードの形としてルールを記述できる。
AIの変更を対象に、禁止APIの追加、エラーを握りつぶす分岐、境界層をまたぐ直接参照といったチーム固有のルールをCIで検査する。検出結果のファイルと該当箇所をエージェントへ返せば、レビュー担当者は実装の意図や例外の判断に時間を使える。
ast-grepはTree-sitterのRust実装への移行で、outline処理のユーザーCPU時間を1.233秒から0.960秒へ22.2%削減したと報告している。AIエージェントが扱う完全なファイルスナップショットの解析に範囲を絞った設計でもある。
ビルド時の計装で、実行後を追う
OpenTelemetryコミュニティは2026年、Go向けコンパイル時自動計装の初の安定版を発表した。AlibabaとDatadogが2025年初めから共同開発してきた、ベンダーに依存しない仕組みである。
コマンドラインツールのotelcは標準Goツールチェーンをラップし、go buildをotelc go buildに置き換える。ソースコードや実行時エージェントを追加せず、-toolexec経由でアプリケーション、依存ライブラリ、標準ライブラリへ計装を注入する。
v1はnet/http、database/sql、gRPC、Redis、Goランタイムメトリクスに対応する。AI変更の前後でHTTP処理時間、DB呼び出し、RPCの失敗を同じテレメトリー（実行時の観測データ）で比較できる。
導入の分岐点は、変更の影響範囲
最初に、事故時の影響が大きいルールを少数選ぶ。認証、外部通信、データ更新の境界に絞り、構造検索をAIエージェントの完了条件とCIの両方に置く。ルールを増やしすぎると、例外処理そのものが新たなボトルネックになる。
次に、ステージング環境でotelcビルドを使い、代表リクエストのトレースを取得する。構造検索を通過しても、DB呼び出し回数やgRPCエラーが増えた変更は、人が差し戻す判断をする。性能や障害影響を持たない小さな修正まで、この運用を強制する必要はない。
まとめ
AI駆動開発では、構造検索で設計上の逸脱を止め、コンパイル時計装で実行後の振る舞いを確かめる。まずは自チームで許容しないGoの変更パターンと、変更後に必ず確認するテレメトリーを一つずつ決めたい。次のAI変更で、人が判断すべき例外はどこに残すべきかを明確にすることが、レビューを速くしながら品質を守る起点になる。