Codex自動化のバルク操作とスレッドハンドオフ｜実行履歴の一括管理とlocal↔remote引き継ぎ

「自動化を10本も20本も回していると、実行履歴に未読が溜まる一方で、1件ずつ既読にするだけで一仕事になる」——OpenAI Codexで日次チェックや週次レポートを何本も自動化している方ほど、この管理の手間に心当たりがあるはずです。

結論から言うと、Codexは2026年6月の更新で、自動化の実行履歴を一括で既読・アーカイブできる「バルク操作」と、作業中のスレッドをローカルとリモートのホスト間で引き継げる「スレッドハンドオフ」を相次いで追加しました。どちらも新しい機能を覚える負担は小さく、既存の運用にそのまま乗せられる改善です。

株式会社Fyveは中小企業向けにAI業務効率化の受託開発と専属AI活用顧問サービスを提供しています。私たちもCodexの自動化を複数の案件で運用しており、この2つの更新は実務の運用負荷に直結すると感じました。本記事では公式情報をもとに、それぞれの仕組みと使いどころを解説します。

自動化のバルク操作とは｜実行履歴を一括で既読・アーカイブ

まず前提として、Codexの「自動化（Automations）」は、コードチェックや分析、レポート作成といった作業をスケジュールに沿って自動で繰り返し実行する機能です。毎日決まった時刻に走らせる、特定のGitリポジトリに紐づけて回す、あるいは進行中のスレッドに対する定期的なチェックインとして使う、といった形で運用します。

自動化が実行されるたびに「実行（run）」が1件記録され、その結果は「Triage（トリアージ）」と呼ばれる自動化専用の受信箱にまとまります。ここでは全件表示と未読のみ表示を切り替えて確認できる仕組みになっています。

2026年6月11日（Codexアプリ 26.611）の更新で、公式の変更履歴には次のように明記されました。

「Added bulk actions to automation run history so you can mark every run as read or archive eligible runs.」——実行履歴に対してバルク操作が追加され、すべての実行を一括で既読にする、またはアーカイブ対象の実行をまとめてアーカイブする、という2つの操作がまとめて行えるようになりました。

バルク操作の前後比較：Beforeは実行履歴を1件ずつ既読・アーカイブしていたが、Afterは全件一括で既読・アーカイブできる

これまでは、自動化を多く回している人ほど、Triageに溜まった実行履歴を1件ずつ開いて既読にする、または個別にアーカイブするという地道な作業が発生していました。バルク操作の追加によって、この整理作業がまとめて完了するようになった、というのが今回の変更の要点です。

スレッドハンドオフとは｜local↔remoteホスト間の作業引き継ぎ

もう1つの更新が、2026年6月18日（Codexアプリ 26.616）に追加された「スレッドハンドオフ」です。公式の変更履歴には次のように記載されています。

「Added thread handoff between local and remote hosts, so you can move a thread to a matching project on a connected host and continue it there.」——作業中のスレッドを、接続済みの別のホスト上にある同じプロジェクトへ移動し、そのまま続きの作業ができるようになりました。

この機能を理解するには、まずCodexが対応する「接続ホスト」の種類を押さえておくと分かりやすくなります。公式ドキュメントでは、接続先として次の3種類が挙げられています。

普段使いのノートPC・デスクトップ：Codexを日常的に動かしている手元のMacやWindows PC。スリープやネットワーク切断、Codexの終了で接続は切れます
常時稼働の専用マシン：必要なプロジェクト・認証情報・プラグイン・MCPサーバーをあらかじめ設定した上で、電源を落とさず動かし続けるMacやWindows PC
リモート開発環境：プロジェクトが元々置かれているSSHホスト。Codexアプリがこの環境にSSH経由で接続する形になります

ハンドオフの操作自体はシンプルで、公式ドキュメントによると次の手順で行います。

スレッドのフッターで、現在の実行場所を選択する
移動先のホストを選ぶ（ローカルに戻す場合は「This computer」を選択）
移動先のホストとブランチの内容を確認する
「Hand off」を選択して実行する

スレッドハンドオフの流れ：ノートPCで作業中のスレッドを常時稼働マシンやリモート環境に移動し、続きを作業できる

ハンドオフが移すのは、スレッドそのものに加えて、ブランチ情報などのGit状態と、移動先で新規作成または再利用されるworktree（作業ディレクトリ）です。もし移動時にスレッドが実行中だった場合は、進行中の応答が中断されたうえで転送される仕様になっています。

あわせて、公式ドキュメントは次の条件・制約も明記しています。

移動先のホストへの接続がすでに存在していること
移動元と同じGitリポジトリのプロジェクトが、移動先のホストにも保存されていること（サブディレクトリを使っている場合は同じ階層まで一致している必要がある）
Codexのクラウド環境（cloud environment）へのハンドオフには対応していない
ハンドオフをリクエストしているスレッド自身を移動先にすることはできない

読者特典・無料ダウンロードひとりAI経営全体マップ無料でダウンロード →

何が嬉しいか｜多数の自動化運用の整理と、環境をまたぐ作業の継続

この2つの更新は別々の機能ですが、どちらも「Codexを日常的に、かつ複数の場所・複数の本数で使い込むほど恩恵が大きい」という共通点があります。

バルク操作が効くのは、自動化を1本や2本ではなく、複数のプロジェクト・複数のチェック項目にまたがって走らせている運用です。日次のコードチェック、週次のレポート、特定条件での通知など、本数が増えるほどTriageに溜まる実行件数も増えます。ここを一括で既読・アーカイブできることで、「本当に確認が必要な実行だけ」に注意を向けやすくなります。

スレッドハンドオフが効くのは、1つの作業を1台のPCだけで完結させない働き方です。ノートPCで作業を始めたものの外出の時間になった、あるいは処理に時間がかかる作業を常時稼働のマシンに移して続けさせたい、といった場面で、スレッドとGit状態をまとめて移動できるため、「どこまで進んでいたか」を自分で説明し直す手間がなくなります。

実務での使いどころ

具体的には、次のような場面で使いどころがあります。

複数案件の自動化を並行運用している場合：クライアントごとに日次の動作チェックや簡易レポートを自動化していると、Triageの実行件数がすぐに数十件単位になります。朝一番でまとめて既読にし、異常があった実行だけを個別に開いて確認する、という運用がバルク操作で成立します
定期実行の棚卸しをするとき：しばらく様子見していた自動化のうち、もう不要になったものの実行履歴をまとめてアーカイブし、Triageを整理してから新しい自動化を追加する、という定期メンテナンスがしやすくなります
作業場所を切り替えながら開発を進めるとき：日中はノートPCで指示を出し、時間のかかる処理だけ常時稼働の専用マシンに引き継いで動かし続け、翌朝また続きを確認する、という運用がスレッドハンドオフで実現できます
手元の環境とリモート開発環境を使い分けているとき：プロジェクトの実体がSSH接続のリモート環境にある場合でも、作業の起点は手元のノートPCのままにして、必要なタイミングだけリモート側にスレッドを移す、という切り替えが可能です

私たちが受託開発の現場で感じるのは、自動化もリモート作業も「本数・台数が増えてから」初めて管理の手間が表面化するという点です。今回の2つの更新は、いずれもその「増えてから困る」部分をピンポイントで解消する変更だと言えます。

よくある質問

自動化のバルク操作では、具体的に何ができますか？

公式の変更履歴では「すべての実行を既読にする」「アーカイブ対象の実行をまとめてアーカイブする」の2つが明記されています。実行履歴を1件ずつ開かずに、Triage全体をまとめて整理できる操作です。

スレッドハンドオフでは、何が移動先に引き継がれますか？

スレッド本体に加えて、ブランチなどのGit状態、そして移動先ホスト上のworktree（作業ディレクトリ、必要に応じて新規作成または再利用）が引き継がれます。

ハンドオフできない相手はありますか？

あります。公式ドキュメントによると、Codexのクラウド環境へのハンドオフは対応しておらず、また移動先の候補として表示されるのは「同じプロジェクトが保存されているホスト」だけです。加えて、ハンドオフをリクエストしているスレッド自身を移動先にすることもできません。

作業中のスレッドをハンドオフするとどうなりますか？

移動時にスレッドが実行中だった場合は、進行中の応答がいったん中断されたうえで転送されます。処理の途中経過を保ったまま無停止で移動する、という挙動ではない点に注意してください。

ハンドオフに必要な事前準備はありますか？

移動先ホストへの接続がすでに確立されていること、そして移動元と同じGitリポジトリのプロジェクトが移動先にも保存されていることが必要です。サブディレクトリを使っている場合は、その階層まで一致している必要があります。

非エンジニアでも自動化のバルク操作は使えますか？

使えます。自動化そのものを設計するのはエンジニア寄りの作業になりがちですが、日々の実行履歴を確認・整理する操作はTriage画面上のクリック操作だけで完結するため、運用担当者が既読・アーカイブを回すだけの役割であれば十分に扱えます。

2つの機能は同時に使う必要がありますか？

いいえ、それぞれ独立した機能です。自動化を複数本回している方はバルク操作だけを、複数の環境で作業を続ける方はスレッドハンドオフだけを使う、という部分的な導入でも十分に効果があります。

まとめ

バルク操作（2026年6月11日・Codexアプリ26.611）：自動化の実行履歴を一括で既読にする、またはアーカイブ対象をまとめてアーカイブできる
スレッドハンドオフ（2026年6月18日・Codexアプリ26.616）：作業中のスレッドを、接続済みの別ホスト上にある同じプロジェクトへ移動し、そのまま続きの作業ができる
接続ホストは「普段使いのPC」「常時稼働の専用マシン」「SSH接続のリモート開発環境」の3種類
ハンドオフで移動するのはスレッド本体・Git状態・worktreeの3点。実行中の応答は移動前にいったん中断される
クラウド環境へのハンドオフは非対応。移動先には同じプロジェクトが保存されている必要がある
バルク操作は複数の自動化を並行運用している方、ハンドオフは複数の環境・端末をまたいで作業する方に特に効果がある
手元の挙動が本記事と異なる場合は、Codexアプリのバージョンと最新の公式情報をあわせて確認してください

Codexで複数のAIエージェントを並列に動かす運用方法について、あわせてこちらの記事でも解説しています。