AI に API を使わせたのは godoc だけだった
tanukirpc の RouteWithTransformer は、パス階層ごとに DI する Registry の型を
Reg1 → Reg2 に差し替えるための API だが、AI に機能追加を実装させると
この API は使われず、各ハンドラに存在チェックが個別にコピペされる傾向があった
(tanukirpc の RouteWithTransformer)。Go 1.27 のジェネリクスメソッドを使えば
これを *Router[Reg1] のメソッドにできる。メソッドになれば AI は使うようになるのかを
実験で確かめた。
実験の設計
因子は3つ。API 形状 (関数 / メソッド)・ネーミング (現行名 / 改名)・godoc の充実度で、 5条件のラダーを組んだ。
| 条件 | API 形状 | 名前 | godoc |
|---|---|---|---|
| C1 | 関数 RouteWithTransformer(r, tr, ...) | 現行 | 無 (現行の tanukirpc そのまま) |
| C2 | メソッド r.RouteWithTransformer(tr, ...) | 現行 | 無 |
| C3 | メソッド r.RouteWithRegistry(tr, ...) | 改名 | 無 |
| C4 | メソッド r.RouteWithRegistry(tr, ...) | 改名 | 充実 |
| C5 | 関数 RouteWithTransformer(r, tr, ...) | 現行 | 充実 |
C1→C2 で API 形状の効果、C2→C3 でネーミングの効果、C1→C5 でドキュメント単独の効果が
それぞれ分離できる。各試行は独立したサブエージェント1体で、渡すのは条件別の API
リファレンスとお題のみ。tanukirpc の実装ソース・README・examples の参照とウェブ検索は
禁止し、リファレンスの記述だけを根拠に判断させた。各条件5試行、お題は2種類
(resource: REST エンドポイント4本の追加、auth: 401/403 を返す認証・認可)。
判定は NewTransformer と RouteWithTransformer/RouteWithRegistry の共起を見る
文字列マッチ。
なお最初に流した実験は、お題に「この存在チェックを重複して書きたくない。1箇所に まとめてください」と書いてしまい 35/35 全条件到達で天井に張り付いた。 これは答えを教えてしまっているのが原因で、詳しくは お題に答えを書くと測定にならない。
結果
到達した試行数 / 5。
Sonnet 5
| 条件 | resource | auth |
|---|---|---|
| C1 関数 + 現行名 + godoc無 | 0 | 0 |
| C2 メソッド + 現行名 + godoc無 | 0 | 0 |
| C3 メソッド + 改名 + godoc無 | 0 | 0 |
| C4 メソッド + 改名 + godoc充実 | 0 | 5 |
| C5 関数 + 現行名 + godoc充実 | 1 | 5 |
gpt-5.6-terra (xhigh)
| 条件 | resource | auth |
|---|---|---|
| C1 関数 + 現行名 + godoc無 | 0 | 5 |
| C2 メソッド + 現行名 + godoc無 | 0 | 4 |
| C3 メソッド + 改名 + godoc無 | 0 | 4 |
| C4 メソッド + 改名 + godoc充実 | 4 | 5 |
| C5 関数 + 現行名 + godoc充実 | 5 | 5 |
読み取れること
- API 形状 (関数→メソッド) の効果は、どちらのモデルでも観測できなかった。 C1→C2 は両モデル・両お題で横ばい (terra の auth は C1 の時点で天井なので判定不能)。
- ネーミングの効果も観測できなかった。C2→C3 は両モデル・両お題で横ばい。
- 効いたのは godoc だけ。それも両モデルで、それぞれ別のお題で 0/5 → 5/5 になった (Sonnet は auth、terra は resource)。C5 はAPI 形状も名前も現行のまま、godoc を 足しただけの条件であることが重要で、これが 0/5 から跳ねている。
- モデル差は「godoc が無いときにどこまで踏み込むか」に出る。terra は auth なら godoc ゼロでも 5/5 で到達するが、Sonnet は 0/5 のまま。
つまり「関数だから router. の補完に出てこないのが原因」という仮説は外れで、
単に何をする API なのか書いていなかったことが原因だった。これは
tanukirpc の RouteWithTransformer で述べている「Transformer 周りだけ godoc が
ゼロ」という現状と噛み合う結果になっている。
限界
各条件5試行なので、0/5 と 1/5、4/5 と 5/5 のような小さな差は読まない。
0/5 と 5/5 のような大きな差だけを読んでいる。Sonnet 側は reasoning effort を
固定できていない — Agent ツールに effort の指定口がなくセッション設定を
継承するため。terra 側は xhigh を明示しているので、2モデルの比較は「モデル差」と
「effort 差」を分離できていない。また API リファレンスだけを渡す設定であり、
実リポジトリ (README・examples) を読ませた場合は結果が変わりうる。判定は文字列
マッチであり、コンパイル可能性や意味的な正しさまでは見ていない。
この実験は発表スライドには入れていない。ジェネリクスメソッドの解説の直後に 「ただしそれは AI の挙動を何も変えません」を置くと結論が噛み合わず、15分の 持ち時間では消化しきれないため、独立した資料として切り離した (ジェネリクスメソッド (Go 1.27))。
出典
Go Release Party 1.27 の発表資料リポジトリ experiment/README.md 全体、
memo.md §6・§7。