autofinetuneとは
autofinetuneが自動化するのは、モデルの回答そのものではなく「次に何を試すか」です。人が用意するのは、実行可能な学習スクリプト、評価指標、変更してよい範囲、触れてはいけない条件です。エージェントは仮説を立て、コードを変更し、学習結果を評価します。改善した変更だけをGitに残し、悪化した変更は戻します。
| 担当 | 主な仕事 |
|---|---|
| 人 | 目的、評価指標、データ、禁止事項を定義 |
| AIエージェント | 仮説作成、設定変更、実験実行、結果比較 |
| Git | 改善した変更の保持、悪化した変更の巻き戻し |
| Tunix | SFTやGRPOなどの追加学習を実行 |
| Cloud TPU | 学習と評価に必要な計算資源を提供 |
Google Developers Blogは2026年9月11日、この方法を「自律的なLLM post-training」として紹介しました。着想元はAndrej Karpathy氏のautoresearchです。autoresearchが小さな事前学習の実験を単一GPUで回すのに対し、autofinetuneはGemmaの教師あり追加学習（SFT）と強化学習（GRPO）へ対象を広げています。
手動作業が変わる
一般的な追加学習では、担当者が結果を見て次の設定を考えます。autofinetuneでは、この外側のループをエージェントが回します。ただし「何を良い結果とするか」は人が先に固定します。ここを曖昧にすると、エージェントは数字だけを上げる近道を選びかねません。
| 工程 | 手動運用 | autofinetune |
|---|---|---|
| 仮説 | 担当者が毎回考える | エージェントが候補を作る |
| 設定変更 | ファイルを手で編集 | 許可範囲内で自動変更 |
| 実行 | ジョブを起動して待つ | 連続して実行 |
| 採否 | グラフや表を見て判断 | 単一の評価指標で比較 |
| 記録 | 表計算や実験管理ツール | results.tsvとGit commit |
公開例のprogram.mdでは、LoRAのrankとalpha、対象レイヤー、学習率、スケジュール、optimizer、batch size、seedなどを変更対象にしています。一方、データセット、epoch数、モデル構造は変更禁止です。つまり自動化の要点は、自由に試させることではなく、探索空間を狭く設計することにあります。
ファインチューニングの用語やLoRA、GRPOの位置づけを先に確認したい場合は、TechCreateのファインチューニング入門が前提整理に使えます。autofinetuneは学習手法を置き換えるものではなく、既存手法を試す順序と評価を自動化する外側の仕組みです。
二つの実験結果
公開された検証は2種類です。ひとつはFunctionGemmaのSFT、もうひとつはGemma 3 1Bの数学推論を対象にしたGRPOです。どちらも「エージェントに任せれば必ず最適解へ到達する」と証明する実験ではありません。固定した条件のなかで、人が張り付かずに複数案を比較できるかを確かめています。
| 項目 | SFT実験 | GRPO実験 |
|---|---|---|
| モデル | FunctionGemma 270M | Gemma 3 1B |
| データ | mobile-actions | GSM8K |
| 計算資源 | Cloud TPU v5e-1 | Cloud TPU v6e-1 |
| 実験回数 | 20回 | 40回 |
| 所要時間 | 数時間 | 2〜3日 |
| 評価 | 関数呼び出し正解率 | 数値正解率と形式正解率の合計 |
| 公開結果 | 改善案を順次保持 | 合成指標が約10%改善 |
SFTでは、エージェントがLoRAの設定やoptimizer、学習率を調整し、関数呼び出しの正解率が上がる変更を残しました。GRPOでは、LoRA構成に加えてrollout temperature、KL penalty、system promptなども探索しています。後者は1回に数時間かかるため、40回の実験を人が順番に監視する負担は小さくありません。
ただし、約10%改善したのはGoogleが実験用に定義した合成指標です。一般的な会話品質や安全性が10%上がったという意味ではありません。自動探索の成果は、評価関数の置き方と切り離して判断できません。
料金と導入条件
autofinetuneのコードはMIT License、学習基盤のTunixはApache License 2.0で公開されています。ライセンス料はかかりません。一方、公開例をそのまま再現するにはCloud TPU、Google Cloudのプロジェクトとクォータ、Python環境、対象モデルとデータセットが必要です。モデル提供者の利用条件も別に確認しなければなりません。
| 項目 | 条件・費用 |
|---|---|
| autofinetune | MIT License、公開コード |
| Tunix | Apache-2.0、JAXベース |
| インストール | pip install google-tunix[prod] |
| TPU利用 | Google Cloudプロジェクトと対象TPUのクォータが必要 |
| TPU v5e | 米国の一部リージョンでオンデマンド1.20ドル／chip-hour |
| TPU v6e | 米国の一部リージョンでオンデマンド2.70ドル／chip-hour |
公式料金表を単純に連続稼働へ当てはめると、v5e-1を2時間使うチップ料金は2.40ドルです。v6e-1を48〜72時間使う場合は129.60〜194.40ドルになります。これは実験ブログの「数時間」「2〜3日」をもとにした概算であり、実際の稼働時間、リージョン、Flex-startやSpot、VM・ストレージなどの料金で変わります。Googleは実験の請求総額を公表していません。
Cloud TPUは作成すれば必ず確保できるとは限りません。Google CloudのTPU計画ガイドでは、オンデマンドにも容量保証がなく、バージョン、サイズ、zoneごとのクォータ確認が必要だと説明しています。中断に耐えられる実験ならSpot、7日以内の検証ならFlex-startも候補です。
試す前の注意点
公開リポジトリは、そのまま業務へ投入できる製品ではありません。READMEには、Antigravity CLIがTPU VMでクラッシュするため回避策が必要だと記載されています。また、権限確認を省く起動オプションも例示されていますが、共有環境や機密データで安易に使うべきではありません。
- 評価指標を1つに絞りすぎると、別の品質や安全性が悪化しても見逃します。
- データセットやモデル構造など、比較条件に関わる項目は変更禁止にします。
- 学習ジョブの上限時間と予算を決め、失敗時に自動停止できるようにします。
- エージェントへ渡す認証情報とファイル権限を最小化します。
- 改善commitだけでなく、全試行の条件と失敗理由を保存します。
- まず小型モデルと小さなデータでループ自体を検証します。
特に注意したいのは、評価指標への過適合です。数学問題の数値正解率と形式正解率を足した指標が上がっても、未知の問題、長い入力、誤答時の振る舞いまで良くなったとは限りません。自動実験は人の評価を消すものではなく、人が深く見る候補を絞る仕組みと考えるのが安全です。
比較の基準となる最初の学習結果も保存しておきます。自動ループ後の最高値だけを見ると、偶然よかったseedや評価データへの適合を成果と取り違えます。複数seedでの再実行、ループが触れていない検証セット、人による失敗例の確認を組み合わせると、改善が再現するかを確かめられます。エージェントが選んだ設定は結論ではなく、追加検証へ進める候補です。
使うべきチーム
autofinetuneが向くのは、すでに追加学習を実行でき、評価の再現性に課題を感じているチームです。はじめてLLMを触る段階では、実験ループより先にデータ品質、baseline、評価セットを固めるほうが効果的です。
| 状況 | 判断 |
|---|---|
| 同じ設定調整を何度も手で回している | 小型モデルで試す価値がある |
| 評価指標とbaselineが固定されている | 自動比較へ進みやすい |
| 正解を人の感覚だけで判断している | 先に評価設計が必要 |
| 個人情報や機密データを扱う | 権限と保存先を設計してから |
| TPUのクォータや予算上限がない | 先にインフラ条件を確認 |
生成AI用語50選でSFT、LoRA、GRPOの違いを説明でき、1回の学習結果を再現できる状態が出発点です。そのうえでprogram.mdに評価指標、変更可能な変数、禁止事項、時間と費用の上限を書く。最初の目標は最高スコアではなく、同じループを安全に止め、再開し、検証できることです。
反対に、学習データを作っている途中、評価担当者の判断が一致しない、1回の学習も安定しない段階では導入を急がないほうがよいでしょう。自動化すると、曖昧な実験が速く大量に増えるだけです。人が1回分の採否を説明できてから、その判断手順をエージェントへ渡す。この順序なら、速度と検証可能性を両立できます。
まとめ
- autofinetuneは追加学習そのものを新しくする製品ではなく、仮説、設定変更、実行、評価、Git記録の反復をAIエージェントへ移す公開実験です。
- SFTの20回とGRPOの40回では改善案を自動で残せましたが、成果は固定した評価指標の範囲に限られます。数字が上がったことと、モデル全体が良くなったことは分けて判断する必要があります。
- 導入判断の中心はエージェントの賢さではありません。評価セット、変更禁止領域、権限、停止条件、TPU予算を人が先に設計できるかどうかです。
