連載「Tines 3B を読み解く」の第7回です。
はじめに
AI に自動化を作らせると、直す回数も増えます。直すたびに動いている本番を壊さないか。壊れたとき、誰が気づいて誰が直すのか。
この記事では、2026年7月に一般提供が始まった AI ネイティブのワークフロー基盤「Tines 3B」が、作業中の版と本番の版をどう分け、壊れたときにどう直すのかを公式ドキュメントに沿って整理します。
こんな方に向けて書いています。
- AI が作った自動化を、本番で動かし続けることを検討している
- 「試したら本番のデータが変わった」を避けたい
- 「AI が自動で直す」がどこまで本当なのか知りたい
先に結論です。3B は作業中の「ドラフト」と本番の「ライブ（main）」を分け、直す作業は別のブランチ（枝）でします。自己修復（Autofix）も修正案をブランチに作るところまでで、本番に反映するかは人が決めます。
こんな場面、ありませんか
- 試しに動かしたら、本番の宛先にメールが飛んでしまった。
- 夜中に自動化が失敗していて、朝に気づいた。原因は小さな書き間違いだった。
- 直す前の版に戻したい。けれど、どの版が「正しかった」のか分からない。
共通するのは、「試す場所」と「本番」が同じ場所にあることです。
結論：3つの設計
| 設計 | 何をするか | 防ぐもの |
|---|---|---|
| 作業中と本番を分ける | ドラフトとライブ（main）。自動のトリガーはライブだけで動く | 試行が本番に影響すること |
| データも分ける | ドラフトは独自の保存領域を持つ。ライブでは実行をまたいでデータを残せる | 試行で本番のデータが変わること |
| 直す案は別の枝に作る | Autofix と Autotune がブランチに案を作る。反映は人が決める | 自動の変更が本番を直接変えること |
設計1：作業中と本番を分ける
ドラフトとライブ
ワークフローの版は、ブランチ（枝）で分かれます。
| ブランチ | 役割 |
|---|---|
| ライブ（main） | 本番の版。cron、Webhook、公開ルートなど有効なトリガーを処理する。「Live」の緑の表示で見分ける |
| ドラフト | 試す、改善する、直すための場所。ブランチごとにチャット履歴と変更を持つ |
| Autofix（オレンジ） | ライブのエラーに対して、3B が修正案を作る（有効にしている場合） |
| Autotune（紫） | 3B が改善案を作る |
チャットで作ったものは、まずドラフトに入ります。ライブに出すには「push live」を押します。
push live の前に、3B は事前チェックを走らせます。ステップテストがあれば実行して失敗を示し、直すか、そのまま push するかを選ばせます。push にはスペースの権限が要り、権限がないとボタンは無効です。
ここでの承認は構築時のものです。ライブの実行中に人の承認を挟む公式の仕組みは、確認できていません。
トリガーはライブだけ
いちばん大事な違いはトリガーです。cron（定期実行）、受信 Web リクエスト、メールはライブの版だけで動き、ドラフトは自分では動きません。試すときは手動で実行するか、ブランチを指定した URL でルートを確認します。
「ドラフトで cron が動かない」のは不具合ではなく仕様です。試行が本番の定期実行に紛れ込まないための設計です。
設計2：データも分ける
3B で実行をまたいでデータを残したいときは、保存領域の /storage に置きます。ステップの Dockerfile に VOLUME の行を書きます。
# 実行をまたいで残る保存領域（既定）
VOLUME ["state"]
# 1回の実行だけで消える作業用の領域
VOLUME ["work:scope=run"]
名前をつけた領域（ボリューム）は /storage/<名前> にマウントされます。押さえておきたい点は3つです。
- 書き込みは成功したときだけ確定する。ステップが失敗すると何も公開されず、途中のファイルが他のステップに見えることもありません。
- ブランチごとに独自のコピーを持ちます。ドラフトの試行はライブのデータに触れません。ドラフトのデータはブランチの削除か push live のときに破棄され、ライブへは移りません。
- 同じスペースで同じ名前を宣言すると共有になります。機密度の違うワークフローが同じ名前を使わないよう、注意が要ります。
そのため、「ライブに必要な最初のデータ」はドラフトで作っても引き継がれません。別に用意する手順が要ります。
設計3：直す案は別の枝に作る
Autofix（失敗したとき）
Autofix は、ライブのワークフローが失敗したときに修正案を作る機能です。ワークフローエディタの（⋮）メニューでオンにします。流れは次の5段階です。
- 失敗したステップの実行を見つける。
- エラーログ、設定、コードを分析する。
- 新しいブランチを作り、そこに修正を入れる。ライブは直接変更しない。
- そのブランチでステップを自動で再実行し、直ったことを確かめる。
- 新しいブランチをメールで知らせる。
人はブランチを見て、Accept（ライブへ push）、Iterate（チャットで質問するか、手で直してから push）、Reject（ブランチを削除）のどれかを選びます。
得意なのは、構文や型の誤り、依存の書き忘れ、設定の不一致のような明確なエラーです。直せないものもあります。ネットワーク障害や外部サービスの停止、手作業が要る権限や認証の問題（トークンの更新など）です。公式では、人の監督の代わりではないと明記されています。
Autotune（正常なとき）
Autotune は、問題が出る前に改善案を作ります。観点は信頼性、機能、明快さ、性能の4つです。定期的にワークフローを調べ、直近の実行データ（実行の履歴、エラー率、ステップの時間）から、焦点を絞った改善を1回に1つブランチに作ります。テスト実行で確かめ、メールでレビューのリンクを送ります。
公式では、無批判に受け入れず、改善と複雑さの兼ね合いを見ることが勧められています。受け入れるか却下しないと、次の改善サイクルは進みません。ブランチを開いたままにしないことも勧められています。
守ってくれないこと
- インフラ障害と認証の期限切れ。Autofix の対象外なので、通常の運用で対応します。
- 受け入れの判断。Autofix と Autotune のブランチを誰がいつまでに見るかは、組織が決めます。
- ライブに必要な初期データ。ドラフトからは移りません。
- 前の版に戻す専用の操作。公式に「ロールバック」という操作の記載は確認できていません。履歴の版からブランチを作る方法（Fork as branch）は説明されています。
おわりに
- ドラフトとライブを分け、自動のトリガーはライブだけで動く。
- データもブランチごとに分かれる。実行をまたいで残すのは
/storage。 - Autofix と Autotune は別の枝に案を作り、反映は人が決める。
連載の他の回
連載「Tines 3B を読み解く」（全11回）:
- 第1回 AIが作るコードの乱立に、どう備えるか。Tines 3B の全体像と5つの強みを読み解く
- 第2回 AIが書いたコードを、動かして大丈夫か。Tines 3B の実行とネットワークの分離を読み解く
- 第3回 AIエージェントに、APIキーを渡さない。Tines 3B の認証情報の設計を読み解く
- 第4回 AIに、誰の権限で何をさせるか。Tines 3B の権限とガードレールを読み解く
- 第5回 「誰が何をしたか」と「いくらかかったか」を、どう見るか。Tines 3B の監視・監査・費用を読み解く
- 第6回 AI にチャットで作らせても、実体はコード。Tines 3B の「コードファースト」を読み解く
- 第7回 本番を壊さずに直す。Tines 3B のドラフトと本番、自己修復（Autofix、Autotune）を読み解く（この記事）
- 第8回 「ベンダーに縛られない」は、どこまで本当か。Tines 3B の接続口と、持ち出せる範囲を読み解く
- 第9回 自社環境で動かすなら、何を引き受けるか。Tines 3B のセルフホストを読み解く
- 第10回 契約の前に、何を書面で確かめるか。Tines 3B の導入・契約・費用を読み解く
- 第11回 Tines 3B か、他の製品か。8つの軸で見分ける
参考
公式ドキュメント（docs.3b.tines.com）: