OpenAI 導入マニュアル
ChatGPT・Codex・APIを業務に導入し、安全に運用するための
準備・設定・実装手順をまとめたマニュアル。
ChatGPT・Codex・APIを業務に導入し、安全に運用するための
準備・設定・実装手順をまとめたマニュアル。
OpenAI製品群の全体像を5層で整理し、画面で完結できる業務をChatGPTで押さえる。
「ChatGPTで使う話」「APIで実装する話」「Codexで開発を支援する話」を混ぜずに、5層で整理する。
| 層 | 代表機能 | 主な利用者 | 実装者が考えること |
|---|---|---|---|
| 利用者体験 | ChatGPT・Search・Deep research・Data Analysis・Canvas・Voice・Projects・Memory | 業務ユーザー・企画担当 | どの業務を画面利用で完結させるか |
| 開発支援 | Codex App・CLI・IDE Extension・Cloud tasks・コードレビュー | エンジニア・QA | 作業単位・AGENTS.md・権限・レビュー基準 |
| API実装 | Responses API・Structured Outputs・Function calling・File/Web Search・Code Interpreter | アプリ開発者 | 状態管理・出力形式・RAG・コスト |
| エージェント | Agents SDK・handoffs・guardrails・sessions・tracing | AIアプリ開発者 | 複数ステップ実行・承認・監査・失敗時の戻し方 |
| 組み込み・拡張 | Custom GPTs・GPT Actions・ChatKit・Apps SDK・MCP/Connectors | 社内IT・SaaS開発者 | 認証・権限・UI・社内データ連携・公開範囲 |
完全網羅とは機能名の列挙ではない。要件から機能を選び、権限とデータを設計し、出力品質を検証して運用に落とす。
画面で完結できる業務は画面で行い、再現性・監査・大量処理が必要になった時点でAPI化を検討する。
| 機能 | 使いどころ | 注意点 |
|---|---|---|
| Search | 最新情報・比較・規約確認など変化しやすい情報の確認 | 「出典付き・一次情報を優先」と明示する |
| Deep research | 複数ソースを調査し体系的なレポートにまとめる | 調査範囲・前提・評価軸を先に指定する |
| ファイル・Data Analysis | 契約書・議事録・CSVの要点抽出、表計算・グラフ化 | 単位・期間・欠損値を確認。根拠箇所を出させる |
| 画像(入力・生成・編集) | 図表・設計書の解釈、プレゼン素材・概念図の生成 | 見えている事実と推測を分けて依頼する |
| Voice / Canvas | 移動中の壁打ち/文章・コードの共同編集 | 正確な記録が必要なら録音・保存先を別途設計 |
| Custom GPTs | 指示・知識・ツールを束ねた専用アシスタント | 機能は必要最小限だけ有効化する |
| Agent | Web操作・フォーム入力など複数ステップの作業 | 許可・禁止・確認のルールを必ず先に与える |
既定はAuto(自動選択)。難しい推論はThinking系、APIの中心はGPT-5.5。
| モデル | 位置づけ | 向く用途 | API価格(入力/出力) |
|---|---|---|---|
| GPT-5.5 | 最上位。1Mトークン入力対応 | 複雑な推論・コーディング・長文脈の分析 | $5 / $30 |
| GPT-5.4 Thinking | 高度な推論のバランス型 | 設計判断・難しい分析・調査 | GPT-5.5より低価格 |
| GPT-5.3 Instant | 高速・日常用途 | 文書作成・要約・翻訳・日常の質問 | 低コスト |
| GPT-5.3-Codex | コーディング特化 | Codexでの実装・レビュー・テスト追加 | Codex経由で利用 |
※ 100万トークンあたりの価格。価格・提供状況は頻繁に変わるため、確定値は公式のPricing/Modelsページで確認する。GPT-4.5は2026年6月27日、o3は8月26日にAPI提供終了が告知済み。旧モデル依存の実装は移行計画を立てる。
「続けて使う」ための3機能。便利さと引き換えに、記憶・共有・自動実行の管理ルールを決める。
| 機能 | 使いどころ | 運用上の注意 |
|---|---|---|
| Memory | 利用者の好み・名前・継続的な目標を反映させたい | 不要な記憶は編集・削除。個人情報や機密を不用意に記憶させない |
| Projects | 複数チャット・ファイル・目的をひとまとまりにしたい | プロジェクト単位で共有範囲とファイル更新日を管理する |
| Scheduled Tasks | 定期的な確認・リマインド・繰り返し分析 | タスクの責任者・失敗時通知・不要タスクの停止を決める |
※ 組織導入では、Memoryに業務情報を記憶させてよい範囲を社内規程で明文化してから展開する。
どちらも「観点を先に渡す」ことで再現性が上がる。
①一次情報を優先 ②発表日・更新日を明記 ③手順・注意点・確認方法に分ける ④不確かな点は不確かと書く——の4点を依頼文に含める。社内秘密情報は投入しない。
①目的と見るべき観点を先に伝える ②要約でなく「根拠箇所・未確認事項・リスク」を出させる ③数値は列定義・単位・欠損値を確認 ④重要判断は人間が該当箇所を再確認する。
チャット以外の入出力を使い分けると、画面利用の範囲が大きく広がる。
コーディングエージェントCodexを「差分をレビューし、テストで確認するチームメイト」として使う。
コードを書く・理解する・直す・レビューする・テストを足すためのコーディングエージェント。作業単位を明確に与えて使う。
同じCodexでも入口が5つある。作業の性質と統制要件で選ぶ。
| 利用面 | 向いている作業 | 注意点 |
|---|---|---|
| Codex App | コード理解・軽微な修正・試作・デバッグ | Gitチェックポイントと権限設定を確認する |
| IDE Extension | 開いているコードと連動した修正・レビュー・テスト追加 | IDE上の差分確認を習慣化する |
| Codex CLI | ローカル実行・スクリプト化・CI補助・レビュー | 実行権限・ネットワーク・承認モードを最小化 |
| Cloud / Web tasks | 長めのタスク・非同期の開発作業・GitHub連携 | 環境変数・秘密情報・ブランチ運用を統制 |
| Integrations | GitHub・Slack・Linear等。PRレビューやチケット起点の実装 | 権限範囲と監査ログを確認する |
※ インストールは curl -fsSL https://chatgpt.com/codex/install.sh | sh または npm install -g @openai/codex。依存関係追加・マイグレーション・外部送信は原則「承認必須」にする。
Responses APIを中心に、プロンプト仕様化・構造化出力・ツール連携・RAG・エージェントまでを実装する。
テキスト生成・会話状態・ツール呼び出し・構造化出力・Web検索・File Searchを、同じ考え方で扱える。
前のターンの保持方法は品質とコストに直結する。要件で選ぶ。
| 方式 | 向いているケース | 注意点 |
|---|---|---|
| アプリ側で履歴を保持 | 独自DB・監査・検索・履歴編集が必要 | トークン増加。要約・圧縮とPII管理が必要 |
| previous_response_id | シンプルな会話継続 | サーバー側状態に依存。保存・削除方針を確認 |
| Conversations API / Sessions | 複数ターンの本格的な会話・Agent運用 | セッション単位の権限・保持期間・監査ログを設計 |
※ まずはアプリ側履歴かprevious_response_idで小さく始め、エージェント化のタイミングでSessionsに移行するのが定石。
業務や実装では再現性・評価可能性・失敗時の扱いが必要。7要素で構造化する。
| 要素 | 書くこと | 例 |
|---|---|---|
| Role | モデルの役割 | あなたはSaaSのセキュリティレビュー担当です |
| Goal | 達成したい結果 | この設計案のリスクを重大度順に整理する |
| Context | 背景情報・制約・前提 | 対象は日本国内のB2B SaaS。個人情報を扱う |
| Input | 対象データ | 設計案・ログ・コード・CSV・問い合わせ文 |
| Process | 進め方 | まず前提不足を列挙し、次にリスク表を作る |
| Output | 形式 | Markdown表。列は重大度・リスク・根拠・対策 |
| Criteria | 合格条件 | 対策が実装可能で、過度に一般論でない |
読み手・範囲・完了条件を埋めるだけで、出力の再現性が大きく変わる。
| 悪い指示 | 問題 | 改善例 |
|---|---|---|
| いい感じに要約して | 読み手・長さ・観点が不明 | 役員向けに、意思決定に必要な論点だけを300字で要約し、未確認リスクを3つ挙げて |
| コードを直して | 再現条件・完了条件がない | 以下のエラーを再現し、最小差分で修正。既存APIは変更せず、回帰テストを追加して |
| FAQを作って | 対象ユーザーと範囲が不明 | 初心者向けに、料金・解約・領収書・ログインの4カテゴリで各3問作る |
| 分析して | 指標と粒度が不明 | 2025年Q4の月次売上を、カテゴリ別に前年比と前月比で分析し、異常値を指摘して |
出力を主観で眺めるだけでは品質は安定しない。テスト観点と「アプリとの分担」を決める。
①正常系 ②情報不足(推測せず質問するか)③形式違反(JSONに余計な文が混ざらないか)④悪意ある入力(上位指示を守るか)⑤長文・ノイズ ⑥機密を含む入力——を依頼前に用意する。
意味理解・要約・分類・候補生成はモデルに任せる。認証・課金・保存・送信・削除・承認・最終判定はアプリで行う。金額・在庫・権限などの事実はDB/APIから取得し、モデルの記憶に頼らない。
出力をJSON Schemaに従わせる機能。後段のプログラムが処理する出力は、自由文でなくschemaで受ける。
| 用途 | 例 | なぜ必要か |
|---|---|---|
| 分類 | 問い合わせカテゴリ・優先度・担当部署 | 後段のルーティングで値の揺れを防ぐ |
| 抽出 | 請求書番号・日付・金額・会社名 | DB保存や照合で型が必要 |
| UI生成 | フォーム項目・カード表示・手順リスト | フロントエンドが安全に描画するため |
| 評価 | 合格/不合格・理由・改善案 | 自動判定と人間レビューを分離するため |
| ツール引数 | function callingのarguments | 外部APIに渡すパラメータを検証するため |
※ 使い分け:最終回答を構造化したい→Structured Outputs/外部システムを呼びたい→Function calling(7章)/複数ステップのワークフロー→Agents SDK(9章)。
モデルが直接DBを更新するわけではない。検証・権限確認・実行・結果返却はアプリ側の責務として設計する。
モデル単体にない能力を、ツールで足す。どれも「権限とログ」の設計がセットになる。
| ツール | 目的 | 実装時の注意 |
|---|---|---|
| Web Search | 最新Web情報を応答に組み込む | 検索が必要な質問に限定。一次情報・日付・出典を扱う |
| File Search | Vector Store化した自社文書から検索 | アクセス制御・文書鮮度・チャンク・引用・評価が重要 |
| Code Interpreter | Python実行・表計算・グラフ・ファイル処理 | 入力ファイル・生成物・タイムアウトを管理 |
| Computer Use | GUIやWeb画面の操作 | 高リスク操作には承認。画面状態の誤認識に注意 |
| Function calling | 自社API・DB・業務処理を呼ぶ | 権限・schema・冪等性・監査(7章) |
| Remote MCP | 外部ツール・社内コンテキストへの標準接続 | 読み取り専用・対象限定・監査ログ必須から始める |
根拠がなければ答えない。それを指示と評価の両方で担保する。
①回答は検索された社内文書の内容に基づく ②根拠が見つからなければ「文書内では確認できません」と答える ③推測や一般論で補わない ④根拠文書名・章節・日付を含める ⑤規程が矛盾したら矛盾点を示し担当部署への確認を促す。
□根拠のない質問で推測せず「確認できない」と答えるか □新旧の文書があるとき新しい版を優先するか □権限のない文書を検索対象にしていないか □回答に根拠文書が付くか □言い回しが違う同じ意図の質問に答えられるか。
複数ステップ・複数担当・承認・観測性が必要になったらAgents SDK。少なければResponses APIだけで始める。
| 要素 | 意味 | 実装時の設計 |
|---|---|---|
| instructions | 役割と行動方針 | 目的・禁止事項・出力形式・確認条件を入れる |
| tools | 使える機能 | 最小権限・schema・タイムアウト・エラー処理 |
| handoffs | 他Agentへの引き継ぎ | 専門領域や責任境界ごとに分ける |
| guardrails | 入力・出力・ツールの検査 | 安全・費用・品質・形式の逸脱を止める |
| session / context | 状態と共有情報 | ユーザー・テナント・権限・会話履歴を管理 |
| tracing | 実行の可視化 | 障害調査・評価・改善のために保存する |
※ 粒度の定石:FAQや単純分類は単一Agent。専門分岐があればHandoff型。調査・要約・評価を部品化するならAgents-as-tools。
Custom GPTからアプリ組み込みまでの選択肢と、画像・音声・帳票を扱うマルチモーダル実装。
「ChatGPT上で使う」のか「自社アプリに組み込む」のか「ChatGPT内で自社サービスを使わせる」のかで選択肢が変わる。
| 要件 | 推奨 | 注意点 |
|---|---|---|
| 非エンジニアが専用アシスタントを作りたい | Custom GPTs | 配布範囲とKnowledge更新を管理 |
| Custom GPTから自社APIを呼びたい | GPT Actions | OpenAPI schemaで定義。認証と権限を厳密に |
| 自社WebアプリにAIチャットを入れたい | ChatKit/独自UI + Responses API | セッション・認証・ツール実行をサーバー側で管理 |
| ChatGPT内で自社SaaSを操作させたい | Apps SDK / MCP App | アプリ公開・認証・UI・セキュリティを設計 |
| 複雑な業務ワークフローを実行したい | Agents SDK + Tools + Guardrails | 9章の設計指針に従う |
プログラムなしで作れる。ただし「何を入れないか」の設計が品質を決める。
| 設定項目 | 設計ポイント |
|---|---|
| Instructions | 役割・対象外・確認条件・出力形式・禁止事項を明確化する |
| Knowledge | 版管理された資料だけを入れる。古い資料・競合する資料を混在させない |
| Capabilities | SearchやData Analysisなど、必要な機能だけ有効化する |
| Actions | 外部API連携。認証・権限・監査ログ・エラー時動作を設計する |
| Testing | 代表質問・対象外質問・悪意ある質問の3種で試す |
| Sharing / Version | 公開範囲を決め、変更理由とリリース日を残してロールバック可能にする |
※ 社内展開前チェック:利用対象者と公開範囲/資料の所有者と更新頻度/高影響操作の承認/ログのマスク対象/問い合わせ先とメンテナンス担当。
資料の図表・スクリーンショット・帳票・音声会話が対象。それぞれ設計ポイントが違う。
| 種類 | 使いどころ | 設計ポイント |
|---|---|---|
| 画像入力(Vision) | UIレビュー・グラフ読み取り・設計図・エラー画面調査 | 見えている事実と推測を分けて依頼する |
| 画像生成・編集 | プレゼン概念図・UIモック・広告ラフ・教育イラスト | 用途・構図・禁止要素・文字の扱いを明記。権利とブランドを確認 |
| 音声・Realtime | 会話型UI・コールセンター補助・現場作業支援 | 遅延・割り込み・文字起こし・参加者同意・切断復帰 |
| 帳票・OCR的利用 | 請求書・領収書・申込書・検査票の抽出 | 抽出schema・信頼度・二重チェック・保存期間 |
重要な金額や契約情報は、必ず人間確認を残す前提で設計する。
データ統制・評価・本番運用・実装レシピ。安全に実務投入するための最終工程。
事故はモデルの回答ミスより、データ投入・権限・ログ・承認不足から起きる。
| データ区分 | 例 | 扱い |
|---|---|---|
| 公開情報 | Web公開資料・公開FAQ | SearchやAPIで扱いやすい。出典確認は必要 |
| 社内一般 | 社内マニュアル・一般手順書 | アクセス制御付きRAG/Projects/Custom GPTで扱う |
| 機密 | 契約・財務・人事・設計・顧客情報 | 投入可否・保存・ログ・権限・マスキングを事前承認 |
| 高度機密 | 秘密鍵・認証情報・未公開M&A・医療/金融の機微情報 | 原則投入しない。必要なら専用環境・契約・DLP・監査を設計 |
※ 導入時の確認事項:OpenAIに送信してよいか/ログに保存してよいか/保存期間と削除方法/学習利用の設定・契約/管理者が確認できるログの範囲/ユーザーへの同意・通知。公式のData Controlsと社内規程・契約条件を突き合わせる。
「入れない」と「即時実行させない」の2つを運用ルールにする。
APIキー・OAuthトークン・Cookie・パスワード・秘密鍵をプロンプトに入れない。エラーログに認証ヘッダーを出さない。ツール引数ログはマスク/ハッシュで最小限に。開発環境に実顧客情報を使わない。Codexの作業リポジトリから.envや秘密ファイルを除外する。
メール送信=下書き生成→宛先・本文確認→人間が送信。返金・契約変更=申請作成→承認者確認→業務システム実行。データ削除=対象確認→バックアップ確認→承認→実行。権限変更=変更前後の表示→管理者承認→監査ログ。
外部コンテンツに埋め込まれた悪意ある指示にモデルが従うリスク。RAG・Web Search・Agent・MCP・ファイル解析では常に想定する。
RAG・ツール呼び出し・エージェントは、最終回答だけでなく途中の検索・ツール選択・失敗時動作も評価する。
| 評価軸 | 見るもの | 測り方 |
|---|---|---|
| 正確性 | 回答が事実・根拠に合うか | ゴールデン質問・専門家レビュー・引用確認 |
| 完全性 | 必要な論点が抜けないか | チェックリスト採点・rubric評価 |
| 形式 | JSON・schema・表・文体が合うか | 自動バリデーション |
| 安全性 | 禁止内容・秘密情報・権限違反がないか | 悪意ある入力・DLP・guardrail |
| ツール適切性 | 必要なtoolを選び、不要なtoolを呼ばないか | tool_callログ・成功率・手戻り率 |
| RAG品質 | 正しい文書を検索し引用できるか | 検索hit率・根拠一致率・未確認回答率 |
| UX | ユーザーが理解し操作できるか | ユーザーテスト・解決率・再質問率 |
代表入力と期待条件のセットを20〜50件から始め、失敗ログをもとに増やす。
input(質問・ファイル)/expected_behavior(完全一致でなく満たすべき条件)/must_include・must_not_include/expected_tool(呼ぶべきtool、または呼ばないこと)/severity(失敗時の重大度)/owner。採点はrubricをモデルに渡して自動化し、結果をリリース判定に使う。
初期導入では人間レビューを組み込み、失敗ケースを「プロンプト/schema/RAG/tool/UIのどこを直すか」で分類する。RAGは検索結果と最終回答を別々に評価し、悪意ある入力・対象外質問・情報不足のケースを必ず含める。
モデルを呼べば終わりではない。7つの層で責務を分けて運用する。
| 層 | 役割 |
|---|---|
| Client / UI | 入力・ストリーミング表示・キャンセル・確認ダイアログ |
| API Gateway | 認証・テナント・レート制限・リクエストID |
| AI Orchestrator | モデル選択・プロンプト・tools・RAG・guardrails・リトライ |
| Data / RAG | Vector Store・文書更新・権限・引用 |
| Tools | DB・API・外部サービス。schema・権限・冪等性 |
| Observability | ログ・メトリクス・トレース・評価・アラート |
| Admin | 設定・モデル切替・プロンプト版管理・ロールバック・監査 |
※ リリース前チェック:モデル名・プロンプト・schema・tool定義のバージョン管理/悪意あるケースの評価/タイムアウト・リトライ・キャンセル/フォールバック文言と運用通知先/コスト上限とダッシュボード。
どちらも「ルーティング」と「送りすぎない」が基本方針になる。
短い回答や分類は高速・低コストモデルに、難しい判断だけ高性能モデルへルーティングする。RAG検索・権限チェック・軽量guardrailは並列化。ユーザー体験はストリーミングで体感を改善。不要な会話履歴や巨大文書を毎回送らず、要約・状態ID・File Searchを使う。
モデルルーティング(分類・抽出・通常回答・難問で分ける)/プロンプト圧縮(不要な履歴・重複資料を削る)/RAGの検索件数調整/同じ質問・文書のキャッシュ/リアルタイム不要な大量処理のバッチ化。評価セットで品質に影響しない箇所から低コスト化する。
推奨構成・実装手順・テスト・運用注意のセットで進める。詳細は出典リファレンス15章。
| ユースケース | 推奨構成 | 外せない要件 |
|---|---|---|
| 社内FAQボット | Responses API + File Search + 権限フィルタ | 根拠外回答の禁止・出典表示 |
| サポート一次対応 | Structured Outputs + Function calling + CRM | 返金は申請のみ。人間引き継ぎ条件 |
| CodexによるPRレビュー | Codex CLI/IDE + AGENTS.md + CI結果 | 自動マージ条件にしない |
| 請求書・領収書抽出 | Vision + Structured Outputs + 人間確認 | 推測禁止・二重登録防止キー |
| KPIデータ分析 | Code Interpreter + ファイルアップロード | 列定義・単位・欠損値の確認 |
| Web調査レポート | Web Search + Structured Outputs | 一次情報優先・公開日の記録 |
| 承認付き購買Agent | Agents SDK + RAG + 承認フロー | 承認なしに発注しない |
| レガシーコード移行 | Codex + 移行計画 + 小分けPR | テストを先に増やす・ロールバック可能 |
どのレシピでも繰り返し現れる4つの型を、最初から組み込む。
リリース前に10項目。「AIに任せるもの」と「アプリで管理するもの」の境界を守ることが、安全な実務投入の最短距離。
本マニュアルで使う主要な用語。
| 用語 | 説明 |
|---|---|
| Responses API | モデル応答・ツール・構造化出力などを扱う中心的なAPI |
| Structured Outputs | JSON Schemaに従った出力を生成する機能 |
| Function calling | モデルが外部関数・APIのtool呼び出しを要求する仕組み |
| RAG / Vector Store | 検索した外部文書を根拠に回答を生成する設計/その文書を検索しやすく保存する仕組み |
| MCP | モデルやエージェントが外部ツール・データソースに接続するためのプロトコル |
| Agent / Handoff / Guardrail | 自律的にタスクを進める構成要素/Agent間の引き継ぎ/入出力・tool実行の検査機構 |
| Codex / AGENTS.md | OpenAIのコーディングエージェント/その作業ルールを伝える指示ファイル |
| ChatKit / Custom GPT | 自社アプリにチャット体験を組み込むツール群/ChatGPT上で作る専用アシスタント |
本マニュアルの内容を、弊所のハンズオン研修で貴社の業務に合わせて実装します。環境構築・プロンプト仕様化・API実装・安全ルールまで伴走します。
公開版では5ページ目まで閲覧できます。全ページ版では、ChatGPT、OpenAI API、 Codex、法人利用時の権限管理と安全運用をまとめて確認できます。
同業者・競合調査目的での無断取得、転載、二次配布はご遠慮ください。