ツールの呼び出し、状態の保存、承認には別々の役割がある。業務に組み込むなら、中断後の復帰まで設計したい。
OpenAI Agents SDK は、指示、ツール選択、反復実行、委譲、追跡を備えたプログラム可能な実行基盤だ。業務システムに Agent を接続するチームには、フレームワーク選びに加えて、どの操作を自動で続け、どこで止め、誰が再開できるかという設計が必要になる。
公式の入門文書は Agents、ツール、handoffs、guardrails を核に、sessions、tracing、sandbox agents、人の介入を説明している。アプリケーションはそれらを、自分たちの認証、権限、永続化、操作先と接続する。
実行ループを誰が管理するか
Responses API を直接使う方法は、ループ、ツールの振り分け、状態をアプリ側で管理したい場合に合う。Agents SDK は複数ターン、ツール実行、委譲、会話をランタイムに管理させたい場合に向く。同じ製品内で併用でき、全経路を一度に移す必要はない。
短い応答だけなら複雑な編成は不要かもしれない。ファイルを使い、複数段階を進み、成果物を返す仕事では、明示的な状態と復帰手順が役立つ。SDK は重複実装を減らせるが、業務の終了条件はアプリが定める。
ツールが成功を返したことと、目的の業務記録が正しく更新されたことは別の出来事だ。同じ完了フラグにまとめると、再試行や承認の意味が曖昧になる。
ツール・検査・承認を分ける
ツールは実行可能な操作を定義する。guardrails は入力や出力、制約を検査する。承認は特定の重要な操作に許可を与える。それぞれの責任を別々に設定する。
公式の人工介入ガイドでは、承認が必要なツール呼び出しを interruption として返す。アプリは実行を RunState に変え、承認または拒否を受けてから再開する。委譲先のツールや、入れ子の Agent ツール内で発生した承認も同じ仕組みで扱える。
プロンプトの「送信前に聞いて」は、それだけで実行層の障壁にはならない。ツールまたはランタイムの方針に実際の停止条件を設定し、未承認リクエストを処理する。パラメーターの形式検査に通っても、業務責任者の同意を得たことにはならない。
判断を画面に、信頼する状態をサーバーに
レビュアーには操作先、引数、想定される影響、根拠を示す。完全な実行スナップショットには保留中の呼び出しや機密情報が含まれ得るため、アプリが管理するサーバー側に保存する。
公式ガイドは、RunState の復元自体は状態や送信者を認証しないと明記する。形式の正しいデータは権限の証明ではない。レビュアーを認証し、その実行を判断する権限を確認し、サーバーに保存した保留中の呼び出しと決定を照合する。
ブラウザーが送るのは判断と不透明な識別子でよい。ツール引数や実行状態全体を差し替えさせない。名前や引数を画面に出す際はエスケープする。画面は意思を表し、ランタイムは再開し、認証と権限はアプリが管理する。
複数人が同じ依頼を開いている場合も考える。一人が消費して再開した後、古い画面から同じ状態を再開してはいけない。必要なのは、所有者と現在状態を確認する原子的な保存処理だ。ボタンを無効にするだけでは足りない。
一度の承認は一度だけの実行を保証しない
外部操作が完了した直後、新しい実行状態を保存する前にプロセスが落ちる場合がある。古い承認済み状態から再開すると、ツールがもう一度動く可能性がある。
公式文書は承認と exactly-once の効果を区別する。決済、送信、業務更新には、論理的な操作ごとに安定した冪等キーを設け、操作先が重複効果を防ぐ仕組みを使う。再試行では同じキーと引数を維持し、保持期間と契約にも従う。
操作先に信頼できる冪等性がなければ、再試行前に実際の結果を照合する。通常の検索で見つからなくても、反映が遅れていたり古い依頼が処理中だったりする。確定できない場合は不明状態を残し、自動で再実行しない。
レビュー画面にも、承認済み、呼び出し済み、操作先確認済み、未確定を分けて表示する。意思決定と実行結果を分ければ、担当者は次に照合すべきか再試行すべきか分かる。
継続的な許可は権限の範囲に合わせる
SDK は一回の呼び出しへの決定と、後続の一致するツールに継続適用する決定を扱う。後者は中断を減らすが、一致条件の理解が必要だ。
公式ガイドは、ローカル shell とファイル編集の継続決定が、所有 Agent ではなくツールの種類と名前に基づくと警告する。実行器ごとの権限が違う場合は逐次決定を優先し、新しい権限環境では新しい承認コンテキストを使う。同じ名前は同じ操作範囲を意味しない。
長く待つ承認では SDK や Agent 定義の版も保存する。保留した状態を対応するコードで復元できなければ、後日のツール変更で依頼の意味が変わる可能性がある。
チームの成果物まで接続する
Buda を使って、実資料、実行、人のレビューをつなぐフローを構築できる。Agent にファイル、制約、成果物を用意し、実行後に実物を確認して次の操作を許可する。ワークスペースと Drive とメモリは継続する文脈を支える。SDK で自作するかは、必要な実行制御と保守能力から判断したい。
自作の承認サービスでは、保留を保存する、有権者が判断する、元の実行を再開する、操作先の結果を取得する、同じタスクへ書き戻す、まで一経路を通す。その後に、クラッシュ、重複送信、拒否の分岐を確かめる。承認ボタンはその一部分だ。
実装時の疑問
tracing で業務監査も済むか
追跡はデバッグに役立つ。業務監査には本人、承認範囲、引数、操作先結果、最終状態も要る。追跡と業務タスクを関連づけ、それぞれの役割を保つ。
全ツールを人が承認すべきか
影響と既存許可に応じて分ける。許可された低リスクの読み取りは自動で進め、重要な更新や外部操作はツール方針で停止させる。実行層で効くルールと、個々の操作が許された理由が必要だ。