何が起きたか
OpenCode 1.15.12と1.15.13では、AIコーディングツールをチームの作業環境に寄せるための更新が続きました。公式リリースでは、ACP integrationsからprompt、slash command、usage updateを送れる更新、OpenAI responses対応チャネル向けのWebSocket transport、session metadata、設定ファイルの読み込み位置の改善などが説明されています。
派手な「新しいAIが増えた」という話ではありません。どちらかと言えば、AI作業を1回きりのチャットではなく、セッション、設定、外部連携、利用状況の単位で扱いやすくする更新です。
何が変わったか
1.15.12で見たいのはACP連携とWebSocket transportです。ACP integrationsからpromptやslash command、usage updateを扱えるようになると、OpenCodeを単体のCLIではなく、別の開発環境や管理画面とつなぐ余地が出ます。WebSocket transportも、対応チャネルでは応答のやり取りをよりリアルタイム寄りに扱うための土台になります。
1.15.13では、session metadataと設定読み込みの改善が実務寄りです。セッションに任意のmetadataを持たせられると、作業の出どころ、案件、担当、検証状態のような情報を外側のシステムと結びつけやすくなります。設定を開いた場所から上位へ読みに行く挙動も、プロジェクト単位でOpenCodeを使う時に効きます。
小さな会社・開発会社・EC運用ではどこに効くか
少人数の開発会社では、AIコーディングツールを入れても、最初は個人の端末で便利に使うだけになりがちです。そこから会社の仕事に使うには、誰が、どの案件で、どの権限で、どの作業をしたかを残せる形に寄せる必要があります。
session metadataは、その入口になります。たとえば、社内ツールの修正、Shopifyアプリの調査、WordPressまわりの小さな改善、商品データ変換スクリプトの作成。こうした作業をAIに任せる時、作業メモがセッションの外に散ると、後で追えません。metadataを活用できる環境なら、AI作業を案件管理やレビューの流れに接続しやすくなります。
ACP連携は、今すぐ全社で使うというより、AIツールを既存の開発フローにどう差し込むかを考える材料です。EC運用会社なら、商品情報の整形、FAQ下書き、CSVチェック、問い合わせ分類などを、いきなり本番連携せず、まず検証用の作業レーンに置くのが現実的です。
そのまま真似ると危ない点
危ないのは、連携先を増やせば運用が進むと考えることです。promptやslash commandを外部から送れるようになるほど、誰が何を実行できるかを決めないと事故が起きます。特に、ファイル変更、外部API、公開サイト、商品価格、在庫、顧客対応に触る作業は、読み取りと書き込みを分けるべきです。
WebSocketやmetadataも同じです。便利な一方で、ログに残る内容、外部に渡る内容、社内で見える範囲を決めておかないと、後から説明しにくくなります。ツールの設定名だけを見て安全と判断しない方がいいです。
最初にやるなら何か
最初は、OpenCodeを本番案件につなぐのではなく、検証用リポジトリで作業レーンを1つ作ります。おすすめは「読むだけ」「下書きまで」「ファイル変更あり」を分けることです。
- 読むだけ：仕様調査、既存コードの説明、差分の確認
- 下書きまで：修正方針、テスト案、商品説明やFAQの草案
- ファイル変更あり：検証用ブランチでだけ許可し、人が差分を見る
そのうえで、session metadataに案件名や作業種別を付けられるかを確認します。ここまでできると、AI作業を「便利だった」で終わらせず、再現できる運用に近づきます。
monoblo実務メモ
私なら、OpenCode 1.15.12〜1.15.13は「AIの回答性能」より「AI作業を管理対象にするための更新」と見ます。少人数チームでは、AIツールを増やすことより、作業の入口、権限、記録、戻し方を先に決めた方が効果が残ります。
関連して読むなら、AIに作業を任せる前の検証環境と、社内ナレッジをAIに戻す仕組みが近いテーマです。