OpenAI自動研究インターンの人手引き継ぎはどうする？2026年導入ガイド

症状：Agentは数時間連続で動けるのに、成功した研究タスクほど人手の介入が残ります。
最速の解法：すべてを監視するのではなく、読み取り、戻せる変更、外部へ影響する操作を分級し、承認点で停止して状態を保存します。

この方法が向くのは、Codexに実験コードの修正や評価処理を任せる研究チーム、Agent基盤とキューを管理するプラットフォームエンジニア、そしてXcodeやデスクトップツールを使うリモートMac環境の責任者です。

OpenAIは2026年9月6日の研究披露で、自動研究インターンに近い内部目標へ到達した一方、複雑な成功タスクでも人による誘導が頻繁に必要だと説明しています。これはOpenAI内部の測定結果であり、一般のチームで同じ成功率や効率が得られる保証ではありません。詳細はOpenAIの研究披露で確認できます。

導入前の操作分級

研究Agentの人手引き継ぎで最初に避けるべきなのは、自然言語の説明だけを読んで承認する運用です。承認者が見るべきなのは隠れた思考過程ではなく、呼び出すツール、引数の要約、対象ワークスペース、書き込み範囲、外部への影響です。

次のように分けると、読み取り操作のたびに人を待たせず、高リスク操作だけを止められます。

この三層はOpenAIが全研究Agent向けに公開した統一アーキテクチャではありません。OpenAI Agents SDKの人工承認機能を土台に、チームの権限モデルへ落とし込むための実装フレームです。SDKの人手承認ドキュメントでは、承認待ちのツール呼び出しを扱う基本設計が説明されています。

研究Agentで人の承認を待たせるべき操作は何ですか。
共有リソースを書き換える操作、取り消しにくい外部送信、認証情報を使う操作、結果を本番データへ反映する操作です。反対に、読み取り専用の検索や隔離ワークスペース内の差分生成まで止めると、承認キューが単なる監視画面になります。

開始直後の状態保存

承認画面を作るだけでは、Agentの停止と再開は成立しません。待機中のツール呼び出し、タスクの版、ワークスペース識別子、完了済み手順、承認結果をアプリケーションのデータベースまたは永続キューへ保存してください。研究者の端末やチャット画面だけに残すと、担当者の離席やプロセス終了で再開条件が失われます。

OpenAI Agents SDKには、割り込みを含む実行状態を扱うRunStateの考え方があります。RunStateの公式リファレンスとコンテキストの説明を確認し、次の情報を分離して保存します。

• Agentが生成した計画と最終出力
• 現在の実行状態と保留中のツール呼び出し
• 承認者、承認時刻、承認対象の引数要約
• リポジトリの版、ワークスペース、実行環境の識別情報
• 成功、拒否、失敗、再計画の結果

APIキー、リポジトリトークン、SSH秘密鍵などはRunStateへそのまま渡してはいけません。状態から参照する場合も、短期の資格情報やサーバー側の安全な参照名に置き換え、再開時に権限を再検証します。

注意：RunStateは外部副作用を自動的に取り消す仕組みではありません。承認済みの書き込みが途中まで完了した場合は、再開処理の前に実行済み記録と冪等性キーを照合してください。

Agentが承認待ちで停止した後、元の作業をどう続けますか。
保留中の呼び出しを新しいキュー項目として復元し、承認時点のツール定義、入力版、ワークスペースが現在も一致するかを検査します。一致しなければ古い決定を使わず、Agentに再計画させてから再申請します。SDKの実行結果に関する説明も、保存する結果と実行状態の境界を確認する材料になります。

初回実行の可逆性

最初の試行では、コードパッチ、一時ファイルの生成、読み取り専用の実験クエリに限定してください。共有ブランチへのマージ、外部サービスへの投稿、課金を伴う実験、デスクトップ上の不可逆操作は後回しにします。

承認キューでは、次の三つの経路を個別に実行します。

• 承認：ツールが一度だけ実行され、引数と実行結果が保存される。
• 拒否：タスクが安全に終了するか、理由を受けて再計画される。
• 無応答：期限を過ぎても暗黙承認にならず、保留または安全終了になる。

拒否を通常のネットワークエラーと同じ扱いにすると、Agentが同じ危険操作を繰り返し申請する可能性があります。承認済みかどうかを呼び出し単位で識別し、再試行してよい操作と、必ず人の判断が必要な操作を分けてください。

初日の環境分離

複数のCodexタスクを扱うときは、承認キューの項目とコードワークスペースを一対一で結び付けます。承認者が別のホスト、別のリポジトリ版、別の環境に対して放行する事故を防ぐため、画面には少なくとも対象環境、リポジトリの版、予想される書き込み範囲、外部副作用を表示します。

クラウドMac上の長時間タスクでは、端末の接続断とAgentの停止を同じ障害として扱わないでください。SSHや画面接続が切れてもプロセスが動いている場合があるため、プロセス状態、承認状態、ワークスペース状態を別々に確認します。Mac上でDockerを使う構成を検討する場合は、MacでDockerを動かす構成の比較も参照できます。

複数のCodexタスクの人手引き継ぎはどう分担しますか。
タスク単位で主担当を一人に固定し、拒否や期限超過だけを副担当へ転送します。チーム全員が全件を監視するのではなく、タスクの危険度、対象ワークスペース、必要な権限をキューに持たせると、担当の重複と見落としを減らせます。

二日以内の引き継ぎ検証

原担当者の離席、Agentプロセスの再起動、別マシンからの状態復元、ツール定義の更新を順に模擬します。復元後に、保留中の呼び出しが正しい担当者へ届き、古い承認が自動的に再利用されないことを確認してください。

承認待ちの間は、プロンプト、モデル、ツールのスキーマ、入力データ、ワークスペース版を凍結します。どれかが変わった場合は、再承認または再計画へ戻します。SDKでAgentを動かす基本的な流れは公式の実行ガイドで確認できますが、権限設計や外部副作用の管理まで自動化されるわけではありません。

リモートMac上の長いタスクが拒否された場合も、状態を残したまま安全に復元できるとは限りません。実行済みのファイル変更、生成物、外部送信の有無を確認し、再実行しても二重登録や二重送信が起きない処理だけを再開対象にします。そうでなければ、ワークスペースを凍結して新しい計画として承認を取り直します。

初週の拡大判定

最初の週は、処理件数よりも接管の証拠を集めます。タスク種別ごとに、介入理由、承認待ち時間、拒否後の結果、重複副作用、独立した再現確認を記録してください。OpenAI内部の研究結果を、そのまま自チームの目標値や成功率として扱ってはいけません。

拡大前には、次のチェックを実行します。

• [ ] 読み取り、可逆変更、外部副作用の権限が分離されている
• [ ] 承認待ちのツール呼び出しが永続化されている
• [ ] 拒否、無応答、プロセス再起動の経路を検証した
• [ ] 承認画面に環境、版、書き込み範囲、外部影響が表示される
• [ ] ワークスペースと承認キューが一対一で対応している
• [ ] ツール定義や入力版が変わったとき、古い承認を破棄できる
• [ ] 独立した担当者が最終成果物を再実行または再確認した
• [ ] 失敗時に安全終了、再計画、環境変更の判断先が決まっている

このチェックを満たせない場合は、長時間タスクの拡大ではなく、低権限の実験へ戻します。合格後も、ルール化した自動承認を追加するのか、人工承認を維持するのか、専用のリモートMac環境を増やすのかを、記録された失敗原因に基づいて決めます。

手元の開発機だけでこの運用を続けると、共有ワークスペースの競合、接続断後の状態確認、XcodeやmacOS作業の環境差分が残りやすくなります。自前のMacを常時専有する方法は長期の安定負荷には向きますが、短期の検証では固定費と環境管理の負担が増えます。

そのため、初回の停止・承認・復元テストを終えたら、タスクごとに隔離環境が必要かを棚卸ししてください。既存の端末で独立した実行環境を維持しにくい場合は、Macを購入するかレンタルするかの比較やMacの料金と利用条件を確認し、必要な期間だけクラウドMacの試験枠を用意する判断が現実的です。