GoでAIワーカーを書くとき——並行性と境界

目次▼

1. 1結論を先に
2. 2まず用語の地図
3. 3本論：GoとAIワーカーで切る単位
4. 4具体例：Goワーカーで切る境界
5. 5よくある失敗
6. 6いまの一手

Goが向く長時間ジョブ／向かないUI同居を契約単位で切る——その判断を先に残す。モデル名やフレームワークは差し替え可能な部品として扱い、芯は「どこで止めて、誰が責任を持つか」に置く。ベンダー比較の総花ではなく、同じ職場に持ち帰れる単位まで落とすのが目的だ。

この記事の使い方

• 決めること: 「GoとAIワーカー」で今週通す縦スライスと、受け入れ条件を3行で書くこと
• 決めないこと: ベンダー選定の最終結論、全社標準の一括固定、肩書きだけの役割定義
• 前提: デモ環境と本番相当は別物。権限とデータの近さで区別する。口約束の契約は残らない

結論を先に

局面	取る選択	理由
速さ優先	薄い縦スライスを先に通す	大きな基盤から入ると本稼働が遠のく
信頼優先	権限とログを先に置く	後付けの監査は通りにくい
再利用	言語非依存の契約を残す	次の案件で型だけ持ち運べる
観測	失敗時の見え方を先に決める	「動いた」だけでは運用に渡せない
移管	独力再現できる手順を残す	手順書だけの引継ぎは足りないことが多い

まず用語の地図

用語	かみ砕いた意味
契約	入出力・失敗・権限の合意。口約束ではなく残る形
検証ゲート	人間や機械が止める地点。通った瞬間が完了定義
本番相当	デモではない、権限とデータの近い環境
縦スライス	端から端まで通る最小機能。基盤だけを先に作らない
責任分界	誰が何を引き受けるかの線。客先と本社の両方で見えること

本論：GoとAIワーカーで切る単位

客先でも実装でも、決める単位はいつも同じだ。入出力・失敗・権限・人間の介入点。このテーマでは、速さだけで進むと後から監査と移管が詰まる。逆に、全部を先に固めると本稼働が遠のく。週次の深掘りでは、その切れ目を表で残す。

現場では次の順番が崩れにくい。

1. 受け入れ条件を3行で書く（何が通ったら終わりか）。
2. 失敗を1つ想定し、ログと人間の介入点を決める。
3. 権限は最小スコープから始め、広げた理由を残す。
4. デモ環境と本番相当を混同しない。データと認可が違うなら別物と書く。
5. 「通した」あと、独力で同じ操作ができるか確認する。手順書だけでは足りないことが多い。

切り口の再掲: Goが向く長時間ジョブ／向かないUI同居を契約単位で切る

同じ論点が別チームで再燃するときは、用語が共有されていないか、ゲートが「あとで」に消えていないかを先に見る。ツールの入れ替えより、止める地点の再定義の方が効くことが多い。

具体例：Goワーカーで切る境界

Goが向くのは、長時間・並列・明確な入出力のジョブだ。向かないのは、UIスレッドやブラウザイベントと状態を共有する同居だ。契約単位で切ると次のようになる。

境界	Go側に残す	外に出す
実行時間	分〜時間のバッチ／ストリーム	インタラクティブなUI反応
並列	goroutineとチャネルで扇出	フロントの同時操作状態
失敗	再試行可能なエラーとデッドレター	ユーザー向けトーストだけ
権限	最小スコープのサービスアカウント	個人のOAuthセッション丸投げ
観測	構造化ログとトレースID	画面トーストだけの成功演出
設定	環境変数と秘密の注入境界	ブラウザに埋め込んだキー

受け入れ条件の書き方例:

1. 入力キューから1件取り、成果物をオブジェクトストレージに書く。
2. 失敗時は同じキーで再実行しても二重書きしない（冪等キー）。
3. 人間が止める地点は「外部APIが3回連続で5xx」のときだけ。
4. 処理時間のp95とデッドレター件数がダッシュボードで見える。
5. ワーカー再起動後も、未完了ジョブが同じ契約で再開できる。

今週の縦スライス例

「PDFを1件受け取り、要約JSONを書き、失敗は同じidempotency-keyで再実行できる」。UIは別リポジトリの薄い管理画面に留め、Go側はジョブ契約だけを公開する。レビューでは「goroutineの数」より「冪等キーとデッドレターの有無」を見る。

レビューで先に聞く三問

1. このジョブの完了定義は、ログのどの一文か。
2. 二重実行したら何が壊れ、誰が気づくか。
3. 権限を広げた差分は、どのPR説明に残っているか。

UI同居が欲しくなったら、Goワーカーはジョブ実行に留め、画面は別プロセスにする。境界を曖昧にしたまま「全部Go」にすると、デバッグも権限も移管も一気に重くなる。切り口（Goが向く長時間ジョブ／向かないUI同居を契約単位で切る）は、この表のどの行を今週の縦スライスにするか、で具体化する。客先移管では、上記の受け入れ条件をそのままチェックリストにして渡すと、手順書だけの引継ぎより再現性が高い。言語の選択理由は「速いから」ではなく「この境界表のどの行をGoに閉じるか」で残すと、翌週のモデル入れ替え議論にも耐える。

よくある失敗

1. 用語を定義せず肩書きだけで進む——検証できない約束が残る
2. デモの拍手を本稼働と取り違える——ゲートを「あとで」にすると来ない
3. 失敗モードを書かずに権限だけ広げる——止める人が見つからない
4. 再利用のつもりで基盤だけ先に作る——縦スライスが通らず本稼働が遠のく

いまの一手

本気の人

1. 「GoとAIワーカー」で今週通す縦スライスを1本決める
2. 受け入れ条件を3行で書く
3. 失敗1件と人間の介入点をセットで残す
4. 権限を広げた理由を一行でログに残す

まだ様子見の人

1. 自社の直近案件で、同じ論点がどこで止まったかメモする
2. 用語の地図だけ先に共有し、ベンダー比較は後回しにする
3. 「動いた」報告に、失敗時の見え方が付いているかだけ確認する

シリーズ: 言語とAI

注: AI Gateway が使えない環境向けの骨組みです。本番の週次では writer モデルで肉付けされます。公開前に「用語の地図」と「いまの一手」が残っているかだけは機械でも見る。