【2026年最新】Responses API実践ガイド｜社内AIエージェント開発

「OpenAI APIで社内AIを作るなら、今はChat Completionsでいいんですか？それともResponses APIですか？」

企業向けAI研修や導入相談で、最近かなり増えている質問です。以前は「まずChat Completionsで試しましょう」で十分でした。でも、2026年時点では状況が変わっています。OpenAI公式ドキュメントでは、Responses APIを新しいAPIプリミティブと位置づけ、Chat Completionsは継続サポートしつつも、新規プロジェクトにはResponses APIを推奨しています。

正直に言うと、Responses APIは「チャットAPIの名前が変わっただけ」ではありません。Web検索、ファイル検索、コード実行、Computer Use、リモートMCP、自前の関数呼び出しなどを、1つのエージェント的なループの中で扱うための土台です。

一方で、便利になったぶん、企業導入では事故ポイントも増えます。社内ファイルを読ませる、外部サービスに接続する、CRMやGoogle Workspaceを操作する。ここまでできるようになると、プロンプトの上手さだけではなく、権限設計・監査ログ・承認フローがかなり重要になります。

この記事では、OpenAI公式のResponses API移行ガイド、Using tools、MCP and Connectors、OpenAI Agents SDK公式ドキュメントを確認したうえで、中小企業が実務で使える設計手順に落とし込みます。

Responses APIとは？Chat Completionsとの違い

Responses APIは、OpenAIが提供する新しい統合インターフェースです。公式ドキュメントでは、Responses APIについて「Chat Completionsの進化版であり、よりシンプルで強力なエージェント的プリミティブを統合に持ち込むもの」と説明されています。

ざっくり言うと、違いはこの3つです。

OpenAI公式ドキュメントでは、Responses APIの特徴として、組み込みツール、複数ターンのやり取り、テキスト・画像のマルチモーダル対応が挙げられています。また、内部評価として、同じプロンプトと設定でSWE-benchが3%改善、キャッシュ利用が40〜80%改善したという説明もあります。ここは公式ソースで確認できる数字なので、導入検討時の参考にしてよいポイントです。

ただし、数字だけを見て「すぐ全部移行しよう」と判断するのは危険です。既存システムが安定稼働しているなら、まず新規機能や小さな社内ツールからResponses APIで作るのが安全です。

社内AIエージェントでResponses APIが向いている5つの業務

Responses APIは「何でもできるAPI」ではなく、ツール呼び出しや状態管理が必要な業務で特に力を発揮します。研修で説明するときは、次の5パターンに分けると理解されやすいです。

1. 社内ナレッジ検索AI

就業規則、営業資料、製品マニュアル、FAQ、議事録などを検索して回答するAIです。Responses APIではファイル検索や自前の検索関数と組み合わせやすいため、単なるチャットより実務向きです。

2. 営業支援AI

顧客情報、過去商談、提案書テンプレートを参照し、商談前メモや提案骨子を作るAIです。CRMに接続する場合は、必ず読み取り専用から始めるのがコツです。いきなり顧客情報を書き換えるAIにすると、現場が怖くて使えません。

3. 問い合わせ一次対応AI

社内ヘルプデスクや顧客サポートの一次回答を作るAIです。返信を自動送信する前に、人間の承認を挟む設計にすると、品質と安心感のバランスが取りやすくなります。

4. レポート作成AI

スプレッドシートやDBからデータを取り、週次レポートや経営会議用の要点を作るAIです。コード実行や自前関数を組み合わせると、集計・グラフ化・文章化まで一気通貫で設計できます。

5. 業務アシスタントAI

Google Workspace、Dropbox、社内SaaSなどと接続し、予定確認、資料探索、下書き作成を支援するAIです。OpenAIのMCP and Connectorsドキュメントでは、ConnectorsはOpenAIが管理するMCPラッパー、remote MCP serversはインターネット上のMCPサーバーとして説明されています。

社内AIエージェントの全体像を知りたい方は、先にAIエージェント完全ガイドも読んでおくとつながりやすいです。

まず作るべき最小構成：1業務・1データソース・1承認

導入相談でよくある失敗が、「全社の情報を全部つないで、何でも答えるAIを作りたいです」というパターンです。気持ちはめちゃくちゃ分かります。でも、それは最初の一手としては大きすぎます。

おすすめは、次の最小構成です。

• 1業務：例）営業の商談前メモ作成
• 1データソース：例）過去提案書フォルダ、FAQ、Notionの1データベース
• 1承認：例）AIが作った文章は必ず担当者が確認してから送る

これだけで十分です。むしろ最初は小さいほど、現場の反応を見て改善できます。AI導入全体の進め方は、AI導入戦略ガイドでも整理しています。

要件定義に使えるプロンプト

あなたは社内AIエージェント導入の要件定義担当です。
以下の業務について、Responses APIで実装する前提で、最小構成を整理してください。

対象業務: [例: 営業の商談前メモ作成]
利用者: [例: 営業担当者]
参照したいデータ: [例: 過去提案書、商談メモ、FAQ]
AIに許可する操作: [例: 検索のみ / 下書き作成まで / 外部送信は不可]
人間の承認が必要な箇所: [例: 顧客へ送る前]

出力形式:
1. 解決したい課題
2. 最小構成
3. APIで必要な機能
4. 権限設計
5. ログとして残すべき項目
6. 最初の2週間で検証するKPI

不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず"仮定"と明記してください。

このプロンプトは、非エンジニアのDX担当者にもかなり使いやすいです。いきなり実装に入らず、「AIに何を許可するか」を先に言語化できるからです。

Responses APIで使う主要機能：ツール・状態管理・MCP

Responses APIで社内AIを作るとき、最初に押さえるべき機能は3つです。

1. Tools：AIにできることを増やす

OpenAI公式のUsing toolsでは、組み込みツール、function calling、tool search、remote MCP serversを使ってモデルの能力を拡張できると説明されています。たとえば、Web検索、ファイル検索、社内DB検索、自社API呼び出しなどです。

ただし、ツールは「多いほど良い」わけではありません。最初から10個もツールを渡すと、モデルがどれを使うべきか迷いやすくなります。最初は3つ以内がおすすめです。

2. Conversation state：会話の文脈を扱う

社内AIでは、1問1答ではなく「前回の回答を踏まえて修正」「この条件も追加」「別部署向けに言い換え」のような流れがよくあります。Responses APIでは、会話状態を扱う設計がしやすくなっています。

一方で、状態を保存するということは、社内情報がどこまで保持されるかを決める必要があるということです。機密情報を扱う場合は、保存範囲、保存期間、ログ閲覧権限を事前に決めてください。

3. Remote MCP / Connectors：外部サービスとつなぐ

OpenAI公式のMCP and Connectorsでは、remote MCP serverやconnectorを通じて外部サービスに接続できると説明されています。これは便利ですが、同じページで「悪意あるMCPサーバーは、モデルのコンテキストに入った機密データを外部流出させる可能性がある」と注意喚起されています。

ここ、かなり重要です。MCPは社内AIの可能性を広げますが、同時にリスクも広げます。MCPの基本を先に押さえるなら、MCP完全実装ガイドも参考にしてください。

コピペで使える設計プロンプト5選

ここからは、Responses APIで社内AIを作る前に使えるプロンプトをまとめます。実装前の整理に使うものなので、エンジニアだけでなく、事業責任者やDX担当者にもおすすめです。

プロンプト1：ツール権限の棚卸し

あなたはAIガバナンス担当です。
以下の社内AIエージェントに接続予定のツールについて、権限リスクを棚卸ししてください。

AIエージェントの目的: [目的]
接続予定ツール: [例: Google Drive, Slack, CRM, 社内DB]
AIに許可したい操作: [読み取り / 下書き作成 / 更新 / 送信]
利用者: [部署・役職]
扱う情報: [個人情報、顧客情報、財務情報など]

出力形式:
- ツール名
- 必要な最小権限
- 禁止すべき操作
- 人間承認が必要な操作
- ログに残すべき項目
- 導入前に確認すべき社内規程

不足している情報があれば、最初に質問してから作業を開始してください。
数字と固有名詞は、根拠（出典/計算式）を添えてください。

プロンプト2：最初のPoC範囲を決める

あなたはAI導入プロジェクトのPMです。
以下の候補業務から、Responses APIで最初にPoCすべき業務を1つ選んでください。

候補業務:
1. [業務A]
2. [業務B]
3. [業務C]

評価軸:
- 現場の困り度
- データの整備状況
- セキュリティリスク
- 効果測定のしやすさ
- 2週間で検証できるか

出力形式:
1. 最初に選ぶべき業務
2. 選定理由
3. 今回やらないこと
4. 2週間の検証計画
5. 成功/失敗の判定基準

不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず"仮定"と明記してください。

プロンプト3：システムプロンプトの初稿

あなたは社内AIエージェントのシステムプロンプト設計者です。
以下の要件をもとに、システムプロンプトの初稿を作成してください。

目的: [例: 営業担当者向けに商談前メモを作る]
利用者: [例: 営業部]
参照できる情報: [例: FAQ、過去提案書]
禁止事項: [例: 顧客への自動送信、価格の断定、未確認情報の提示]
回答トーン: [例: 簡潔、根拠付き、箇条書き中心]
人間に確認すべき条件: [例: 金額、契約条件、個人情報]

必ず含める要素:
- 役割
- 目的
- 参照情報の扱い
- 禁止事項
- 不明点がある場合の動作
- 出典・根拠の出し方
- 人間承認が必要な条件

不足している情報があれば、最初に質問してから作業を開始してください。
数字と固有名詞は、根拠（出典/計算式）を添えてください。

プロンプト4：ログ設計

あなたは社内AIシステムの監査ログ設計者です。
以下のAIエージェントについて、監査ログとして保存すべき項目を設計してください。

AIエージェントの用途: [用途]
利用部署: [部署]
接続ツール: [ツール]
扱う情報の機密度: [低/中/高]
自動実行する操作: [操作]

出力形式:
- 保存すべきログ項目
- 保存しない方がよい情報
- 保存期間の考え方
- 管理者が確認すべきアラート条件
- インシデント発生時の確認手順

不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず"仮定"と明記してください。

プロンプト5：運用ルールの社内文書化

あなたは社内AI利用ルールの作成担当です。
以下のAIエージェントを社内公開する前に、利用者向けの運用ルールを作成してください。

AIエージェント名: [名称]
できること: [機能]
できないこと: [制限]
入力してよい情報: [情報]
入力してはいけない情報: [情報]
回答を使う前に確認すべきこと: [条件]
問い合わせ先: [部署]

出力形式:
1. 利用目的
2. 利用できる人
3. 入力してよい情報
4. 入力禁止情報
5. AI回答の確認ルール
6. トラブル時の連絡先
7. よくある質問

不足している情報があれば、最初に質問してから作業を開始してください。
数字と固有名詞は、根拠（出典/計算式）を添えてください。

プロンプト6：リリース前チェック

あなたはAIシステムのリリース判定者です。
以下の社内AIエージェントについて、公開前チェックリストを作成してください。

用途: [用途]
対象ユーザー: [ユーザー]
接続データ: [データ]
接続ツール: [ツール]
自動実行する操作: [操作]
公開範囲: [部署/全社]

観点:
- セキュリティ
- 個人情報
- 権限
- ログ
- 誤回答時の対応
- 人間承認
- 効果測定

出力形式:
- 必須チェック項目
- 未完了ならリリース不可の項目
- リリース後1週間で見る指標
- 改善サイクル

不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず"仮定"と明記してください。

Agents SDKとResponses APIはどう使い分ける？

OpenAI Agents SDKの公式ドキュメントでは、Agents SDKはコードでエージェントを構築し、実行ループ、状態、Guardrails、人間レビュー、ツール連携など、より高度なランタイムパターンへ広げるためのものとして整理されています。つまり、Responses APIとAgents SDKは競合というより、使う抽象度が違います。

最初のPoCはResponses APIを直接使い、業務が複雑になったらAgents SDKを検討する。この順番が一番スムーズです。すでにエージェント開発の全体像を見たい方は、OpenAI Agents SDK完全ガイドも合わせて読んでください。

【要注意】Responses API導入でよくある失敗パターン

失敗1：最初から全部の社内データにつなぐ

❌ よくある間違い：Google Drive、Slack、CRM、会計システム、社内DBを一気につなぐ。

⭕ 正しいアプローチ：最初は1つのデータソースに絞る。たとえば「営業FAQだけ」「提案書フォルダだけ」から始める。

なぜ重要か：接続先が増えるほど、権限・ログ・誤参照・情報漏洩のリスクが増えます。便利さより先に、管理できる範囲を決めるのが大事です。

失敗2：ツール実行を全部自動承認にする

❌ よくある間違い：AIが必要だと判断したら、外部サービス操作も自動で実行させる。

⭕ 正しいアプローチ：読み取りは自動、書き込み・送信・削除は人間承認を必須にする。

なぜ重要か：OpenAI公式のMCP and Connectorsでも、remote MCP serverには機密データ流出リスクがあると説明されています。特に社外送信・データ更新・削除は、必ず承認を挟んでください。

失敗3：プロンプトだけで安全性を担保しようとする

❌ よくある間違い：「機密情報を漏らさないで」とシステムプロンプトに書いて終わり。

⭕ 正しいアプローチ：プロンプト、権限、ネットワーク、ログ、レビューを組み合わせる。

なぜ重要か：AIの安全性は、文章だけでは守れません。そもそもアクセスできない設計、実行前に止める設計、後から追える設計が必要です。

失敗4：効果測定を後回しにする

❌ よくある間違い：「便利そうだから導入」で始める。

⭕ 正しいアプローチ：問い合わせ対応時間、検索時間、下書き作成時間、差し戻し回数など、最初に見る指標を決める。

なぜ重要か：AI導入は、現場が「なんとなく便利」と感じるだけでは継続しません。定量・定性の両方で効果を見える化しましょう。

導入7ステップ：中小企業が安全に始める手順

1. 業務を1つ選ぶ：現場の困り度が高く、2週間で検証できる業務を選ぶ。
2. データを1つに絞る：FAQ、マニュアル、提案書など、最初の参照元を限定する。
3. Responses APIで最小プロトタイプを作る：まずは読み取りと下書き生成だけで十分です。
4. 権限を最小化する：読み取り専用から始め、書き込み権限は後から検討する。
5. ログを残す：誰が、いつ、何を入力し、どのツールが呼ばれたかを追えるようにする。
6. 人間承認を入れる：社外送信、顧客情報更新、金額提示などは必ず承認対象にする。
7. 改善サイクルを回す：週1回、誤回答、使われない理由、現場の要望を確認する。

ChatGPT活用そのものから整理したい場合は、ChatGPTビジネス活用ガイドも入口としておすすめです。

セキュリティとガバナンス：最低限ここだけは外さない

Responses APIは、社内AIの実装をかなり楽にしてくれます。でも、企業導入では「作れる」より「安全に運用できる」が重要です。

最低限、次のチェックは入れてください。

• 入力制限：個人情報、契約情報、財務情報など、入力禁止情報を明文化する。
• 権限分離：利用者の部署・役職によって参照できるデータを分ける。
• 承認フロー：外部送信、データ更新、削除は人間承認を必須にする。
• 監査ログ：入力、出力、ツール呼び出し、承認者を記録する。
• プロンプト管理：本番プロンプトを誰でも変更できる状態にしない。
• 外部MCPの審査：接続前に提供元、権限、通信内容、ログ保存方針を確認する。

AIガバナンスの全体設計は、AIガバナンス・セキュリティカテゴリの記事も参考になります。

まとめ：今日から始める3つのアクション

Responses APIは、社内AIエージェント開発の中心になりやすいAPIです。特に、ツール連携、状態管理、MCP接続を見据えるなら、これからの新規開発では優先的に検討してよいと思います。

ただし、最初から大きく作る必要はありません。むしろ、小さく始めるほど成功率は上がります。

1. 今日：社内で一番困っている「検索・下書き・要約」業務を1つ選ぶ。
2. 今週：参照データ、禁止操作、承認フローを1枚にまとめる。
3. 今月：Responses APIで最小プロトタイプを作り、限定メンバーで検証する。

参考出典

• OpenAI API Docs: Migrate to the Responses API
• OpenAI API Docs: Using tools
• OpenAI API Docs: Conversation state
• OpenAI API Docs: MCP and Connectors
• OpenAI API Docs: Agents SDK

著者プロフィール

次回予告：次回は、Responses APIとMCPを使った「社内ナレッジ検索AI」の最小実装パターンを、要件定義から権限設計まで具体的に解説します。