3行まとめ
agent run、tools、handoffs、guardrails、sessions、tracingをアプリ側で管理します。
agentが読める情報、呼べるtool、止める条件、人間承認を先に決めます。
MCP、tool approval、tracing、data controls、pricingは公開前に分けて確認します。
モデル選定より前に、権限、停止条件、ログ、データ保持を設計します。
OpenAI Agents SDKは、LLMに会話させるためだけのライブラリではなく、アプリ側がagent run、tools、handoffs、guardrails、sessions、tracingを管理するための実装層です。
業務アプリに入れるなら、最初に決めるべきものはモデル名ではなく、agentが触ってよい業務権限、止める条件、人間承認、保存するログです。
2026-06-12時点のOpenAI公式ドキュメントでは、MCP接続、tool approval、tracing、data controls、pricingの確認点が分かれています。PoCの前に、read-onlyから始める範囲を決めてください。
この記事でわかること
単発のLLM API呼び出し、一般的なworkflow、agent loopを分けて考えます。
toolsを関数一覧ではなく、入力、出力、副作用、承認を含む権限台帳として扱います。
handoffs、agents as tools、human-in-the-loopを混同せず、誰が最終責任を持つかを決めます。
guardrails、sessions、run state、tracingをデータ保持と監査の観点で確認します。
MCP、pricing、data controls、ZDR、契約条件を本番化前に再確認します。
SDKの機能一覧ではなく、業務アプリとして安全に運用するための判断軸です。
- OpenAI Agents SDKを単発のLLM API呼び出しや一般的なworkflowと分けて見る判断軸
- toolsを関数一覧ではなく、業務権限台帳として設計する方法
- handoffs、agents as tools、human-in-the-loopを混同しないための責任分界
- guardrailsを入力、tool実行、出力のどこに置くべきか
- sessions、run state、tracingに残る情報をデータ保持と監査の観点で見る方法
- MCP serverを足す前に決めるscope、承認、tool outputの扱い
- コスト、データ利用、ZDR、公開前に再確認すべき一次情報
本記事ではOpenAI Agents guide、OpenAI Agents SDK Python docs、OpenAI API pricing、data controls、Enterprise privacyを2026-06-12に確認しました。企画時に追ったXアカウントは需要シグナルとして見ましたが、ページ本文を安定して取得できず、記事内の事実根拠には使っていません。スポンサー、アフィリエイト、無償提供、検証環境提供はありません。
前提知識
最初の導入はread-onlyに絞り、traceで原因を追える範囲から始めます。
Agents SDKはagent loopをアプリ側へ置くための層
OpenAIのAgents guideでは、SDKを使う場面として、サーバー側がorchestration、tool execution、state、approvalsを持つケースが示されています。つまり、Agents SDKは「LLMに返答させる薄いラッパー」ではありません。
業務アプリでは、ユーザーが依頼を送る入口、agentが何を読めるか、どのtoolを呼べるか、途中停止した時にどう再開するか、実行後に何を監査するかまでアプリ側で設計します。
逆に、単純な分類、短い要約、1回だけのstructured outputで足りる処理に、最初からagent loopを入れる必要はありません。複数step、tool呼び出し、状態、承認、観測が必要になった時にSDKの価値が出ます。
CodexやClaude Codeとは使う場所が違う
CodexやClaude Codeは、開発者の作業を支援するAIコーディングエージェントとして使う場面が中心です。OpenAI Agents SDKは、読者自身の業務アプリの中にagent実行を組み込むための開発部品として見た方が誤解が少なくなります。
たとえば、社内チケットの調査、返信案の作成、更新前の承認、実行ログの保存をSaaS管理画面に組み込むなら、SDK側でagent、tools、sessions、human approval、tracingをどう設計するかが問題になります。
AIエージェントアプリの基本パターンは、先に<a href="https://ai-dev.blog.mo-gmo.com/ai-agent-app-workflow-tool-calling-guardrails-structured-output/">Workflow・tool calling・guardrails・structured outputの整理</a>を読むとつながりやすいです。
初回導入はread-onlyから始める
最初のPoCで、検索、DB更新、メール送信、外部API実行、MCP接続、長期sessionをまとめて入れると、失敗した時に原因を切り分けにくくなります。
初回はread-only agentが向いています。社内ドキュメントを探す、チケットを要約する、更新案を出す、レビュー観点を列挙する。この程度なら、失敗しても業務データを壊さずに、trace、guardrail、承認UIの設計を試せます。
結果：導入前に決める順番
- 1. 対象業務
agent化すべき処理か、通常のAPI呼び出しで足りるかを分けます。
- 2. tools
agentが触る業務権限と副作用を定義します。
- 3. guardrails
入力、tool、出力のどこで止めるかを決めます。
- 4. human-in-the-loop
自動実行と人間承認の境界を決めます。
- 5. handoffs
複数agent化する前に責任の移動を決めます。
- 6. sessions/state
再開に必要な情報と保存期間を決めます。
- 7. tracing
デバッグ、監査、コスト確認の観測単位を決めます。
- 8. MCP
共通tool基盤が必要な時だけ、scopeと承認を分けて足します。
- 9. コストとデータ保持
pricing、data controls、契約条件を公開前に再確認します。
toolsとguardrailsを先に置くと、handoffsやMCPを広げる時の責任範囲が見えやすくなります。
OpenAI Agents SDKを業務アプリに入れるなら、次の順番で設計すると事故を減らせます。
| 順番 | 決めるもの | 先に決める理由 |
|---|---|---|
| 1 | 対象業務 | agent化すべき処理か、通常のAPI呼び出しで足りるかを分ける |
| 2 | tools | agentが触る業務権限と副作用がここで決まる |
| 3 | guardrails | 入力、tool、出力のどこで止めるかを定義する |
| 4 | human-in-the-loop | 自動実行と人間承認の境界を決める |
| 5 | handoffs | 複数agent化する前に責任の移動を決める |
| 6 | sessions/state | 再開に必要な情報と保存期間を決める |
| 7 | tracing | デバッグ、監査、コスト確認の観測単位を決める |
| 8 | MCP | 共通tool基盤が必要な時だけ、scopeと承認を分けて足す |
| 9 | コストとデータ保持 | pricing、data controls、契約条件を公開前に再確認する |
この順番にする理由は単純です。agentの賢さより先に、agentが触る権限と止め方を決めておかないと、後からguardrailや監査ログを足しても穴が残りやすいからです。
toolsは関数一覧ではなく業務権限台帳にする
write系toolは、承認UIと巻き戻し手順ができてから解禁します。
function toolsは入力スキーマと失敗条件から決める
Agents SDKのtools docsでは、OpenAI-managed hosted tools、local/runtime execution tools、function calling、agents as toolsなどのカテゴリが示されています。業務アプリで最初に扱いやすいのは、自社アプリ側の関数をtoolとして公開する形です。
確認項目
ただし、実装時に「どのPython関数を呼べるか」から始めると、権限設計が抜けます。toolは、agentが業務システムに対して実行できる操作です。入力、出力、副作用、例外、リトライ、承認、監査ログを1つの台帳として扱う方が安全です。
| tool | 分類 | 入力 | 出力 | 副作用 | 初期承認 |
|---|---|---|---|---|---|
search_ticket | read-only | ticket ID、検索語 | 候補一覧 | なし | 自動可 |
draft_reply | draft | ticket本文、制約 | 返信案 | なし | 自動可 |
update_ticket_status | write | ticket ID、status | 更新結果 | 状態変更 | 人間承認 |
send_customer_email | external write | 宛先、本文 | 送信結果 | 外部送信 | 初期禁止 |
この表に、認証主体、rate limit、timeout、再実行可否、監査ログの保存先を足します。小さな表ですが、導入レビューではこの台帳がよく効きます。
read-only、draft、writeを分ける
agentが呼べるtoolは、最低でもread-only、draft、writeに分けてください。
read-onlyは、検索、取得、要約、分類のように業務状態を変えない操作です。draftは、返信案、PR説明、更新案のように、人間が採用する前の候補を作る操作です。writeは、DB更新、チケット状態変更、メール送信、請求操作など、外部状態を変える操作です。
初期PoCではread-onlyとdraftに寄せます。write系は、差分表示、承認、実行後確認、巻き戻し手順が揃ってから足します。
toolごとに認証主体を決める
同じtoolでも、ユーザー本人の権限で実行するのか、サービスアカウントで実行するのかでリスクが変わります。
認証条件
ユーザー本人の権限で実行する場合、既存のRBACを反映しやすい一方で、agentがユーザーの広い権限を借りてしまう可能性があります。サービスアカウントで実行する場合、権限は絞りやすい一方で、誰の依頼で実行したのかを別途ログに残す必要があります。
toolログには、少なくとも依頼ユーザー、承認者、実行主体、tool名、入力の要約、出力の要約、失敗理由、trace IDを残します。秘密情報や顧客本文をそのまま残すかどうかは、後述のdata分類で決めます。
handoffsは専門agentの増殖ではなく責任分界で決める
- 1元agent
依頼内容、既に呼んだtool、確定済みの事実、未確認事項を整理します。
- 2handoff artifact
会話ログ全文ではなく、制約、禁止事項、次に取るべき行動を小さく渡します。
- 3専門agent
請求、契約、レビューなどの担当範囲で作業を引き継ぎます。
- 4戻し先
handoff先が失敗した時に、誰へ戻すか、誰が最終回答するかを決めます。
- 5trace
どのagentからどのagentへ責任が移ったかを後から追えるようにします。
専門agentをtoolのように呼ぶだけなら、元agentが最終責任を持ち続ける設計も選べます。
agents as toolsとhandoffsを分ける
複数agentを使う時、すべてをhandoffにする必要はありません。専門agentをtoolのように呼び、元のagentが最終責任を持ち続ける形もあります。
判断基準
判断基準は、作業の主導権が移るかどうかです。たとえば「契約条項を要約して返す専門agent」はagents as toolsで十分かもしれません。一方で「請求問い合わせを請求専門agentに引き継ぎ、そのagentが最終回答を持つ」ならhandoffに近くなります。
handoffは便利ですが、責任の移動を伴います。どのagentがユーザーへ最終回答するのか、handoff先が失敗した時に誰へ戻すのか、trace上でどう追うのかを先に決めます。
引き継ぐ情報を小さなartifactにする
会話ログを丸ごとhandoff先に渡すと、不要な情報や過去の曖昧な指示まで引き継がれます。handoffでは、必要な情報をartifactとして小さくまとめる設計が向いています。
handoff artifactには、依頼内容、制約、既に呼んだtool、確定済みの事実、未確認事項、禁止事項、次に取るべき行動を入れます。これにより、handoff先のagentが不要な文脈に引きずられにくくなります。
fallbackと再実行を先に決める
handoff先が失敗した場合の戻し先を決めずに複数agent化すると、失敗時のユーザー体験が崩れます。
戻し方は3つあります。元agentに戻す、人間に確認する、作業を中断する。どれにするかは、業務リスクと再実行可否で決めます。外部送信やDB更新が絡む場合、単純なリトライは避け、同じ操作が二重実行されないようにrun stateと監査ログを見ます。
guardrailsは入力、tool実行、出力の3箇所に置く
- 1入力
対象外依頼、秘密情報、許可されない顧客データ、曖昧な実行指示を止めます。
- 2tool実行前
write系toolでは、差分、対象ID、承認状態、実行主体を確認します。
- 3tool実行後
期待した状態になったか、二重実行や部分失敗がないかを確認します。
- 4出力
形式、断定しすぎ、未確認情報、顧客への不適切表現を確認します。
function tools、hosted tools、handoffs、MCP、built-in execution toolsでは確認点が変わります。
input guardrailで対象外依頼を切る
guardrailsは、出力形式を整えるためだけのものではありません。業務アプリでは、入力段階で対象外の依頼、秘密情報、許可されない顧客データ、曖昧な実行指示を止める必要があります。
たとえば社内チケット支援agentなら、請求、法務、医療、個人情報、契約変更など、担当外または承認必須のカテゴリをinput guardrailで検出します。止めた時には、単に拒否するだけでなく、人間へ回す、追加確認を求める、read-onlyに落とすといった分岐を用意します。
tool前後のチェックで副作用を抑える
Agents SDK docsでは、tool guardrailsがfunction toolsの前後で使える一方、handoffsやhosted tools、built-in execution toolsなどには同じguardrail pipelineがそのまま適用されないことが説明されています。
根拠
ここは導入前に必ず確認してください。「guardrailsを設定したから全toolが同じように守られる」と考えると危険です。write系toolは、tool呼び出しの前に差分、対象ID、実行主体、承認者、想定される副作用を表示し、実行後に期待した状態になったかを検証します。
function toolにguardrailを置ける場合でも、業務側の権限チェックはtool内部でも行います。LLM側の判断だけに依存せず、APIやDBの境界でも同じ制約を検証してください。
output guardrailは形式と業務リスクを見る
structured outputを使う場合、JSON schemaや型の検証は有効です。ただし、形式が正しくても業務的に危険な出力はあります。
たとえば、未確認の事実を断定している、顧客へ送るには強すぎる表現がある、社内メモを外部向け文面に混ぜている、承認前なのに実行済みのように書いている。こうしたリスクはoutput guardrailやレビューUIで拾います。
human-in-the-loopは承認ボタンの位置で設計する
- 実行前
顧客データ取得、外部送信、DB更新、請求操作、契約変更、権限変更を開始前に止めます。
- 実行中
想定外のtool、guardrail検知、コスト上限接近、handoff連鎖、tool失敗の反復で一時停止します。
- 承認画面
対象、入力要約、想定される変更、実行主体、戻し方を表示します。
- 実行後
trace、toolログ、最終出力、差分、承認履歴をまとめてレビューします。
承認者が何を見て許可したかを残せる状態が、実務上の承認フローです。
実行前に承認するもの
人間承認は、最後に人間が読めばよいという話ではありません。実行前に止めるべき操作があります。
承認画面の条件
顧客データの取得、外部送信、DB更新、請求操作、契約変更、非公開リポジトリへの書き込み、権限変更は、開始前に承認を置く候補です。承認画面には、tool名だけでなく、対象、入力要約、想定される変更、実行主体、戻し方を表示します。
実行中に止めるもの
agent実行中にも停止ポイントが必要です。想定外のtoolを呼ぼうとした、guardrailに触れた、コスト上限に近づいた、handoffが連鎖している、同じtoolを何度も失敗している。こうした状態は、実行中の一時停止に向きます。
OpenAI Agents SDKのresults docsでは、approvalが必要な場合にinterruptionsやrun stateを使って停止、承認、再開する流れが説明されています。業務アプリ側では、この停止をどのUIで扱うか、承認待ちが期限切れになった時にどうするかを決めます。
実行後にレビューするもの
実行後レビューでは、trace、toolログ、最終出力、差分、承認履歴をまとめて見られる必要があります。
承認者が見たいのは、モデルの長い思考過程ではありません。何が依頼され、何を読み、どのtoolを呼び、どこで止まり、誰が承認し、どの状態が変わったかです。trace設計は、このレビュー画面から逆算した方が実用的です。
sessionsとstateは便利な記憶ではなくデータ保持として扱う
OpenAI側のdata controlsを確認しても、自社アプリ側のDB、ログ、通知に残るデータは別管理です。
sessionに残す情報を最小化する
sessionは、途中までの会話や実行状態を扱いやすくします。一方で、顧客情報、社内情報、tool input、tool output、承認コメントなどが保存対象になる可能性があります。
保存前の確認項目
保存する情報は、再開に必要な最小限へ絞ります。たとえば、全文ではなく要約、実データではなく参照ID、secretではなくマスク済みの識別子にする選択があります。
OpenAI側の扱いと自社側の保存を分ける
OpenAI data controlsでは、API Platformの入力と出力がモデル改善に使われないこと、endpointごとのabuse monitoring retentionやapplication state retention、Zero Data Retentionの対象可否が示されています。Enterprise privacyでは、API inputs and outputsが一定期間保持され得ること、ZDRを申請できる場合があることも説明されています。
ただし、OpenAI側の扱いを確認しても、自社アプリ側のDB、ログ、trace export、監査基盤、エラー通知に残るデータは別問題です。業務アプリに入れるなら、保存先ごとに保持期間、閲覧権限、削除方法、マスク方針を決めます。
| データ | 保存先 | PIIの可能性 | 初期方針 |
|---|---|---|---|
| user input | 自社DB、OpenAI API | 高い | 必要最小限にする |
| tool input/output | 自社ログ、trace | 中から高 | 要約とID中心にする |
| approval log | 自社DB | 中 | 承認者、理由、対象を残す |
| final output | 自社DB、ユーザー画面 | 中 | 業務記録として保持期間を決める |
| trace | OpenAI traces、外部observability | 中から高 | secretと本文をマスクする |
削除、保持期間、監査要求に備える
業務アプリでは、ユーザーが会話を削除した時、関連するtool resultやtraceも消すのかが問題になります。監査のために残す必要がある場合もあります。
削除要求、監査要求、インシデント調査、契約上の保存期間が衝突することがあります。PoC段階でも、session ID、trace ID、user ID、tool execution IDをひも付け、どこまで削除できるかを把握しておくと、本番移行時に困りにくくなります。
tracingはデバッグ、監査、コスト管理を同時に満たす形にする
- 1依頼
run ID、ユーザーまたはrole、対象業務、入力要約を残します。
- 2agent
どのagentが動き、どの判断で次のstepへ進んだかを追います。
- 3toolとguardrail
tool名、呼び出し結果、guardrail検知、停止理由を確認できるようにします。
- 4handoffと承認
責任の移動、承認ID、承認者、却下時の戻し方を残します。
- 5コストと異常
token、再試行、長いsession、権限逸脱、想定外tool呼び出しを検知します。
traceには本文やsecretを残しすぎず、原因調査に必要な要約とIDを中心にします。
traceで見たい単位を先に決める
Agents SDKのtracing docsでは、run、agent、LLM generation、function tool call、guardrail、handoffなどがtrace対象として説明されています。tracingは既定で有効で、無効化の方法も示されています。
評価基準
導入時に見るべき単位は、業務側のレビューに合わせます。1回の依頼で、どのagentが動き、どのtoolを呼び、どのguardrailに触れ、どこで承認され、どのくらいのコストになったか。これを追える粒度が必要です。
traceに載せる情報と伏せる情報を分ける
traceは便利ですが、入力、出力、tool result、顧客情報、社内ID、secretが混ざると、監査ログ自体が機密情報の集積になります。
traceに載せるのは、原因調査に必要な要約とIDを中心にします。本文、ファイル内容、顧客メール、access token、API key、個人情報は、マスクまたは参照ID化します。
また、tracing docsではZDRの組織ではtracingが利用できない旨が示されています。ZDRが必要な業務では、OpenAI側のtraceに頼らず、自社側の観測ログをどう作るかを先に検討します。
異常検知はコストだけでなく権限逸脱にも置く
agentの運用監視は、費用だけを見ると足りません。tool呼び出し回数、失敗率、handoff回数、承認却下率、想定外toolの試行、同じrunの長時間化、外部送信前の停止回数を見ます。
特にMCPや外部APIをつなぐ場合、権限逸脱の兆候を検出できることが重要です。コスト上限に達したら止めるだけでなく、read-onlyの想定なのにwrite系toolを呼ぼうとした時に止める設計が必要です。
MCPは社内権限の入口として慎重に足す
- 1function toolで足りるか
単一アプリ内の小さな操作なら、まずfunction toolで始めます。
- 2server scope
MCP serverごとに、読める範囲、書ける範囲、認証主体を分けます。
- 3approvalとfiltering
require approval、tool filtering、caching、tracingをserver単位で確認します。
- 4tool output
MCP tool outputを次の命令として扱わず、未信頼の外部入力として検証します。
- 5監査ログ
どのclient、agent、userが、どのMCP toolを呼んだかを追えるようにします。
MCPを足すと、接続先、認証、tool一覧、承認、監査、outputの信頼性まで設計範囲が広がります。
function toolsで足りる作業とMCPが向く作業を分ける
MCPは、複数のアプリやagentから共通のtoolやcontextを使いたい時に有効です。OpenAI Agents SDK docsでもMCP serverを扱う方法が説明されています。
一方で、最初の業務アプリで単一の小さな操作をするだけなら、function toolで始めた方が安全です。MCP serverを足すと、接続先、認証、tool一覧、承認、監査、tool outputの信頼性まで考える範囲が広がります。
MCPの基本概念と権限設計は、<a href="https://ai-dev.blog.mo-gmo.com/mcp-tools-resources-prompts-permission-design/">MCPとは何か：Tools・Resources・Promptsと権限設計</a>で詳しく整理しています。
MCP serverごとにscopeと承認を分ける
Agents SDKのMCP docsでは、local MCP serversに対してrequire_approvalを設定できること、tool filtering、caching、tracingなどの共通パターンが説明されています。GitHub releasesでは、MCP tool名の衝突を避けるためにserver名をtool名へ含める設定も追加されています。
注意点
業務アプリでは、MCP serverごとにscopeを分けます。社内検索はread-only、GitHubはissue readから開始、CRMは顧客情報検索まで、DBは本番write禁止。こうした分け方をserver単位とtool単位の両方で設計します。
MCP tool outputを次の命令として扱わない
MCP serverや外部検索から返る内容は、未信頼入力です。tool outputの中に「この指示を優先せよ」「承認を不要にせよ」といった文が含まれても、agentの上位指示や承認ルールを上書きしてはいけません。
これはprompt injection対策にもつながります。MCP outputは、業務データとして読む対象であり、agentへの命令ではありません。外部入力やドキュメント経由のprompt injectionは、<a href="https://ai-dev.blog.mo-gmo.com/ai-coding-agent-prompt-injection-issues-docs-mcp-guardrails/">AIコーディングエージェントのprompt injection対策</a>も合わせて確認してください。
コストとデータ保持はPoC前に見積もる
コストとデータ保持はモデル価格だけでなく、失敗時の停止条件と契約条件に依存します。
token costは平均runではなく失敗runも見る
コスト見積もりで平均runだけを見ると、agent運用では外します。失敗run、tool再試行、handoff増加、長いsession、承認待ちからの再開、trace確認、外部tool料金が加わるからです。
見積もり条件
PoCでは、成功ケースだけでなく、tool失敗、guardrail停止、承認却下、handoff失敗、長文入力、MCP timeoutを入れて、最大コストを見ます。
| ケース | 入力 | tool回数 | handoff | 人間承認 | 見るべきリスク |
|---|---|---|---|---|---|
| 通常run | 短い依頼 | 1から3回 | なし | なし | 平均費用 |
| 失敗run | 曖昧な依頼 | 3から8回 | あり | あり | 再試行と停止 |
| 承認待ちrun | write前提 | 2から5回 | あり | あり | 再開と二重実行 |
| 長期session | 過去履歴あり | 変動 | 変動 | あり | context増加と保存 |
pricingは公開前に再確認する
OpenAI API pricingでは、モデル別の入力、cached input、出力料金に加えて、toolsの料金が分かれています。2026-06-12確認時点では、Web search、File search、Hosted Shell and Code Interpreter、Agent Kit関連の項目が掲載されています。
価格は変わりやすいため、この記事では具体価格の暗記を目的にしません。導入時には、モデル、入力token、cached input、出力token、tool call、storage、container/session、traceやobservabilityの保存先を見積もり列に入れてください。
AIコーディングツール全体の料金・上限制約を見るなら、<a href="https://ai-dev.blog.mo-gmo.com/ai-coding-tool-pricing-plan-limits-team-enterprise-decision/">AIコーディングツール料金改定の見方</a>も参考になります。
data controlsとEnterprise privacyは契約条件に依存する
OpenAIのdata controlsとEnterprise privacyは、API Platform、ChatGPT Business、ChatGPT Enterpriseなどの対象が分かれます。読者の契約、endpoint、ZDR対象可否、保存設定によって判断が変わります。
社内導入では、OpenAIの扱い、自社アプリの保存、外部observabilityへの送信、MCP server側のログ、接続先SaaSの監査ログを分けて確認します。1つのページだけ見て「安全」と結論づけない方がよいです。
失敗点：導入時に起きやすい事故
検索、DB更新、メール送信、MCP、shell、file searchを同時に入れると原因追跡が難しくなります。
安全性はguardrail、tool内部の権限チェック、API側の認可、人間承認、監査ログを組み合わせます。
顧客メール、社内ドキュメント、非公開コード、API keyはマスクまたは参照ID化します。
最終回答者、失敗時の戻し先、trace上の責任移動を先に決めます。
server scope、承認、tool filtering、監査ログなしに共通toolを増やさないようにします。
初期PoCはread-only toolを2つか3つに絞り、traceで説明できる範囲から始めます。
便利なtoolを一度に増やす
最も多い失敗は、PoCの段階でtoolを増やしすぎることです。検索、DB更新、メール送信、MCP、shell、file searchを一度に入れると、agentがどこで間違えたのか分かりません。
初期PoCの制限
最初はread-onlyのtoolを2つか3つに絞り、traceで原因を追える状態を作ります。write系は承認UIと巻き戻し手順ができてからです。
guardrailsを万能扱いする
guardrailsは重要ですが、すべてのtool種別に同じ形で効くわけではありません。function tools、hosted tools、handoffs、MCP、built-in execution toolsで確認点が変わります。
安全性は、guardrail、tool内部の権限チェック、API側の認可、human approval、audit logを組み合わせて作ります。1つの仕組みに寄せるほど、抜けた時の影響が大きくなります。
traceに機密情報を残しすぎる
debugのためにtraceへ全文を残すと、本番ではtraceが機密情報の倉庫になります。顧客メール、社内ドキュメント、非公開コード、API key、個人情報が混ざると、閲覧権限と削除が難しくなります。
traceは原因調査に必要な粒度へ絞り、本文やsecretは載せない方針を先に作ります。
handoffsで責任が曖昧になる
専門agentを増やすと、誰が最終判断をしたのかが曖昧になりやすいです。handoff先が出した結論を元agentが確認するのか、そのままユーザーへ返すのか。ここを決めておかないと、レビューと改善ができません。
MCPを社内便利ツール置き場にする
MCP serverは便利ですが、権限境界が曖昧なまま社内toolを集めると危険です。どのagentが、どのserverの、どのtoolを、どのscopeで使うのかを分けてください。
実務で使うなら：3段階で広げる
- Phase 1: read-only
社内ドキュメント検索、チケット要約、問い合わせ分類、レビュー観点の提示から始めます。
- 評価
成功率、修正率、承認却下率、平均コスト、最大コスト、原因追跡率を見ます。
- Phase 2: draftと承認つきwrite
返信案、更新案、issueコメント案、PR説明案に広げ、人間承認UIを入れます。
- 承認画面
差分、対象、実行主体、戻し方、保存されるログを表示します。
- Phase 3: 複数agentとMCP
traceを見て、本当に専門agentやMCP serverが必要な作業だけを広げます。
Phase 1と2のtraceを見てから、handoffs、MCP、長期session、本番writeへ進みます。
Phase 1はread-only agentで始める
最初の2週間から4週間は、read-only agentに限定します。社内ドキュメント検索、チケット要約、顧客問い合わせの分類、レビュー観点の提示などが向いています。
採用判断の指標
評価指標は、成功率、修正率、承認却下率、平均コスト、最大コスト、traceから原因を追える割合です。ユーザー満足だけでなく、失敗した時に説明できたかを見ます。
Phase 2でdraftと承認つきwriteへ進む
次に、返信案、更新案、issueコメント案、PR説明案のようなdraft系へ広げます。ここで人間承認UIを入れ、write toolは承認後だけ呼べるようにします。
承認画面には、差分、対象、実行主体、戻し方、保存されるログを出します。承認者が判断できない画面なら、承認フローとしては未完成です。
Phase 3で複数agentとMCPを広げる
複数agent、handoffs、MCP server、長期session、本番writeは最後に広げます。Phase 1と2のtraceを見て、どの作業が本当に専門agentを必要としているかを判断します。
法人導入の権限設計は、<a href="https://ai-dev.blog.mo-gmo.com/enterprise-ai-coding-permission-design-api-keys-private-repos-human-approval/">APIキー、非公開リポジトリ、人間承認フローの整理</a>とも重なります。OpenAI Agents SDKだけで閉じず、社内の権限管理と接続してください。
セキュリティ・コスト注意
API key、access token、社内コード、顧客情報、個人情報をpromptやtraceにそのまま載せません。
DB更新、メール送信、請求操作、権限変更、ファイル削除、本番環境操作は初期状態で禁止します。
ZDRが必要な業務では、OpenAI側のtracingを前提にせず、自社側の監査ログを検討します。
失敗run、tool再試行、handoff連鎖、承認待ち再開で停止する条件まで決めます。
セキュリティとコストは単純な勝敗ではなく、対象業務、契約条件、保存先、承認範囲で変わります。
APIキーと秘密情報はtool境界で止める
API key、access token、社内コード、顧客情報、個人情報、非公開リポジトリ情報は、promptやtraceにそのまま載せない設計にします。
初期設定
tool内部でsecretを扱う場合も、agentへsecret値を返さない、traceに書かない、エラー文に出さない、ログ保存先を分けるという基本を守ります。
write系toolは初期禁止にする
DB更新、メール送信、請求操作、権限変更、ファイル削除、本番環境操作は、初期状態では禁止します。必要になったら、対象、承認者、実行条件、戻し方、監査ログを決めてから解禁します。
ZDRとtracingは両立しない場合がある
Agents SDK tracing docsでは、Zero Data Retention policyの組織ではtracingが利用できないと説明されています。ZDRが必要な業務でOpenAI側のtraceを前提にすると、運用設計が崩れます。
その場合は、自社側でtrace相当の監査ログを作る、あるいは対象業務をread-onlyに限定するなど、契約条件と観測要件を合わせて決めます。
コスト上限は失敗時の停止条件まで決める
agentは、失敗すると同じtoolを繰り返したり、handoffを増やしたり、長い履歴を引き回したりします。月額予算だけでなく、1 runあたりの上限、tool回数、handoff回数、承認待ちの期限を置きます。
上限に近づいたら、作業を中断し、人間へ「ここまでの実行内容」と「残りの選択肢」を出す設計が実務的です。
導入前チェックリスト
必須項目を満たしてからPoCへ進み、本番前と拡張時の項目は段階ごとに再確認します。
| 項目 | 必須度 | 確認内容 |
|---|---|---|
| 対象業務 | 必須 | agent化する理由、成功判定、失敗時の影響 |
| tool台帳 | 必須 | 入力、出力、副作用、認証主体、承認要否 |
| read/write分離 | 必須 | 初期PoCでwriteを禁止できているか |
| guardrails | 必須 | 入力、tool前後、出力の停止条件 |
| human approval | 必須 | 承認者、表示情報、却下時の戻し方 |
| sessions/state | 本番前 | 保存内容、保持期間、削除方法、再開方法 |
| tracing | 本番前 | trace粒度、マスク、閲覧権限、ZDRとの整合 |
| MCP | 拡張時 | server scope、tool filtering、approval、監査ログ |
| pricing | 必須 | モデル、tool、storage、失敗runの最大費用 |
| data controls | 必須 | endpoint、契約条件、ZDR、社内保存先 |
| インシデント対応 | 本番前 | 停止条件、通知先、ログ保全、再発防止 |
この表を埋められない状態で本番writeを解禁しない方がよいです。逆に、read-onlyであっても、この表の半分以上はPoC時点で確認できます。
次に読むなら
OpenAI Agents SDKやMCPの仕様は動きが速いので、更新差分を追いたい場合は<a href="https://ai-dev.blog.mo-gmo.com/newsletter/">ニュースレター</a>で新しい検証記事を受け取れます。チーム導入、権限設計、PoCレビューを社内で進める場合は、公開済みの比較表やカテゴリHubから近い記事を探すのも有効です。
FAQ
不要になるとは限りません。既存のジョブ管理、キュー、承認ワークフロー、監査基盤と組み合わせます。
最初から入れる必要はありません。小さな操作はfunction toolで始め、共通基盤が必要になった時に検討します。
運用できますが、run ID、tool call、approval、error、cost estimateを追える代替ログが必要です。
対象業務、tool回数、停止条件、データ保持、最大コストを見て、公開前に最新情報で選びます。
SDKだけで既存の運用基盤が消えるわけではなく、承認、監査、SLA管理との接続が残ります。
OpenAI Agents SDKを使えば、既存のworkflow engineは不要になりますか
不要になるとは限りません。Agents SDKはLLM agentの実行、tool、handoff、guardrail、session、tracingを扱う層です。既存のジョブ管理、キュー、承認ワークフロー、監査基盤、SLA管理があるなら、それらと組み合わせて使う方が自然です。
MCPは最初から入れるべきですか
最初から入れる必要はありません。単一アプリ内の小さな操作はfunction toolで始め、共通tool基盤や複数クライアント連携が必要になった時にMCPを検討します。MCPを入れるなら、serverごとのscope、approval、tool filtering、監査ログを先に決めます。
tracingを無効化しても運用できますか
できますが、代わりの観測ログが必要です。ZDR要件などでOpenAI側のtracingが使えない場合は、自社側でrun ID、tool call、approval、error、cost estimateを追える仕組みを作ります。
どのモデルを選べばよいですか
本記事では特定モデルの推奨はしません。モデル選定は、対象業務、入力量、必要なreasoning、latency、価格、data controls、tool利用の組み合わせで決めます。導入前にOpenAI API pricingとモデルdocsを再確認してください。
参照した主な情報源
- OpenAI Agents guide: https://developers.openai.com/api/docs/guides/agents
- OpenAI Agents SDK Python docs: https://openai.github.io/openai-agents-python/
- OpenAI Agents SDK tools docs: https://openai.github.io/openai-agents-python/tools/
- OpenAI Agents SDK guardrails docs: https://openai.github.io/openai-agents-python/guardrails/
- OpenAI Agents SDK tracing docs: https://openai.github.io/openai-agents-python/tracing/
- OpenAI Agents SDK MCP docs: https://openai.github.io/openai-agents-python/mcp/
- OpenAI Agents SDK results docs: https://openai.github.io/openai-agents-python/results/
- openai/openai-agents-python releases: https://github.com/openai/openai-agents-python/releases
- OpenAI API pricing: https://developers.openai.com/api/docs/pricing
- OpenAI data controls: https://developers.openai.com/api/docs/guides/your-data
- OpenAI Enterprise privacy: https://openai.com/enterprise-privacy/
更新履歴
- 2026-06-12
OpenAI Agents guide、Agents SDK Python docs、GitHub releases、OpenAI API pricing、data controls、Enterprise privacyを確認しました。
- 導入前
Agents SDKのlatest release、pricing、data controlsは変わりやすいため、公式情報を再確認します。
実装前と公開前に、SDK release、価格、データ利用、ZDR、tracing条件を同じ一次情報で見直します。
- 2026-06-12: OpenAI Agents guide、Agents SDK Python docs、GitHub releases、OpenAI API pricing、data controls、Enterprise privacyを確認して初版を作成しました。OpenAI Agents SDKのlatest release、pricing、data controlsは変わりやすいため、導入前に公式情報を再確認してください。