新登場の OCI Enterprise AI Agents で MCPを使ったエージェントを作ろう！

はじめに

OCI Enterprise AI は、Oracle Cloud Infrastructure（OCI）上で LLMや埋め込みモデルへのAPIアクセス、AI エージェントの構築、デプロイ、ガバナンスをワンストップで提供するマネージドサービスです。Cohere、Google、Meta、OpenAI、xAI といった主要プロバイダのモデルにを利用することができます。

OCI Enterprise AI の大きな特徴のひとつが、OpenAI の Responses API との互換性です。OpenAI の Python SDK をそのまま使い、base_url を OCI のエンドポイントに差し替えるだけで利用できるため、OpenAI SDK の経験をお持ちの方はすぐに OCI で AIエージェントの開発をはじめることができます。また、既存の OpenAI 向けコードを最小限の変更で OCI に移行することができます。さらに、Conversations API によるマルチターンの会話状態管理、MCP（Model Context Protocol）サーバーへの接続、Function Calling、File Search、Code Interpreter といったエージェント向けのツール群もサポートされています。

この記事では、OCI Enterprise AI Agents の環境セットアップから、MCP サーバーを活用した対話型 AI エージェント「GitHub DeepInsight」の実装までを一通り紹介してみようと思います。DeepWiki MCP サーバーを使って GitHub リポジトリの内容を深掘りできるCLIアプリケーションを、Python で実際に動かしてみます。

OCI Enterprise AI Agents での AI エージェント開発の流れ

この記事で行う作業の全体像を先にご紹介しておきます。OCI Enterprise AI Agents で AI エージェントを開発して動かすまでの流れは、大きく6つのステップに分かれます。

上にMermaid形式フローチャートが表示されない場合はこちら

AI エージェント開発の流れフローチャート画像

まず 「①権限設定」 で、API Key の作成とポリシーの設定を行います。OCI Enterprise AI のエンドポイントを呼び出すための認証情報を準備するステップです。

次に 「②Project の作成」 です。OCI Enterprise AI では、エージェントやリソースを Project 単位で管理します。コンソールから Project を作成し、その OCID を控えておきます。

「③Agent の設計」 では、エージェントの振る舞いを決めます。どのモデルを使うか、instructions にどんな役割と制約を与えるか、どのツール（MCP サーバー、Function Calling、File Search、Code Interpreter など）を持たせるかを検討します。

「④コードの実装」 では、OpenAI SDK を使ってクライアントを作成し、Responses API や Conversations API で対話ロジックを組みます。OCI Enterprise AI は OpenAI Responses API 互換なので、既存の OpenAI 向けコードの資産をそのまま活かせます。

「⑤テスト・実行」 で、ローカル環境でエージェントを動かして動作を確認します。

最後に 「⑥デプロイ」 です。デプロイ方式を選択します。オンプレミスや閉域環境にセルフホスティングすることもできますし、OCI Enterprise AI Agents のマネージドサービスを使ってクラウド上にデプロイすることもできます。

この記事では、①から⑤までをサンプルアプリケーション「GitHub DeepInsight」の実装を通じて順番にご紹介していきます。

OCI Enterprise AI Agents における AI エージェントのデプロイメント

OCI Enterprise AI Agents では、セルフホスティングの形態を Managed API only モデル、マネージドサービスを Hosted Applications モデルと呼んでいます。

Managed API only モデル

AIエージェントをデプロイするインフラは自前で用意して、OCI Enterprise AI Agents の各種マネージドAPIだけを利用する形態です。OCI Enterprise AI Agents が提供する Managed API には以下のカテゴリがあります。

Agentic API

モデルやエージェント機能をプロバイダー間で利用するための、OpenAI Responses API 互換かつ Open Responses API 準拠のAPI

Agent Tool

ファイル検索、コードインタープリタ、関数呼び出し（ローカル定義関数）、MCP呼び出し（リモートMCPサーバー）などのツール機能

Agent Memory

Conversations APIのためのメモリ機能、長期記憶、およびメモリコンテキスト最適化
Lower-Level Agent Building Blocks – OpenAI互換のベクターストアAPI、ファイルAPI、およびコンテナAPI

Hosted Applications モデル

AIエージェントを OCI Enterprise AI のインフラにデプロイする形態です。開発した AIエージェントをコンテナ化してデプロイすることで、サービス側でエンドポイントとオートスケーリング機能をマネージドで提供します。

Hosted Applications では、 OpenAI Agents SDK, LangChain, LangGraph, AutoGen などで開発した AIエージェントのホスティング（ Agentic Application Hosting ）と MCP サーバーのホスティング（ MCP Server Hosting ）が可能です。

Tips
開発したAIエージェントを OCI Enterprise AI Agents のマネージド環境でホスティングする場合（ Hosted Applications モデルのデプロイメント）は、おおまかに以下のような流れになります。詳しい手順は公式ドキュメントのHosted Applications and Deploymentsに記載があります。

まず、エージェントアプリケーションに FastAPI 等の Web フレームワークで HTTP リクエストを受け付けるサーバー機能を実装します。デプロイサービスがコンテナの状態を監視するためのヘルスチェックエンドポイント（/health など）も必要です。次に、アプリケーションをコンテナイメージとしてパッケージし、OCI Container Registry（OCIR）にプッシュします。OCI コンソール上で Application（ランタイム構成の定義）と Deployment（コンテナイメージの選択とプロビジョニング）を作成すると、エンドポイントが公開されてクライアントからエージェントを呼び出せるようになります。詳細は、公式ドキュメント Permissions for Deploying Applicationsに記載があります。

Hosted Applications モデルでデプロイされるエージェント・アプリケーションは、リソースプリンシパル認証で Managed API その他のOCIリソースへのアクセスを認証します。そのため、適切な動的グループとポリシーの設定が必要です。

OCI Enterprise AI サービス利用の権限を設定する

API Key を作る

ここでは、検証環境を想定して簡便な API Key で認証する方法をとることにします。

Tips
本番環境などでは、長期間有効な API Key の利用は必ずしも適切ではありません。
そのような環境の場合には、OCI IAM 認証を使いましょう。

• 公式ドキュメント：OCI IAM Authentication
• OCI GenAI Auth Python library：oci-genai-auth
• 参考記事：OCI Enterprise AIをとりあえず触ってみる

生成したAPIキーは、どこか安全なところにメモしておきましょう。このダイアログを閉じると同じAPIキーを再び参照することはできません。忘れてしまった場合は再生成となります。APIキーは、プログラムから OCI Enterprise AI のエンドポイントを呼び出す際に必要となります。
メモしたらダイアログを閉じます。

APIキーの OCID をメモしておきます。これは、後から再確認することができます。次のポリシー設定で必要となります。

ポリシーの設定

API Key で OCI Enterprise AI サービスを利用できるようにポリシーを設定します。

レスポンスAIの使用権限を付与するポリシーの例

allow any-user to manage generative-ai-family in compartment <コンパートメント名>
allow any-user to use generative-ai-response in compartment <コンパートメント名> where ALL { request.principal.type = 'generativeaiapikey', request.principal.id='<APIキーの OCID>'}

Tips
request.principal.id に記述する ID は、API Key そのものではなく、API Key の OCID です。
OCI Enterprise AI Agents に必要な権限は、公式ドキュメントPrerequisite: Set Up IAM Permissions に記載があります。

Projects の作成

OCI Enterprise AI では、Project がエージェント開発の基本単位となるリソースです。会話、ファイル、コンテナ、メモリといったリソースは Project 単位で分離・管理され、データ保持期間やメモリの設定も Project ごとに構成できます。Responses API を呼び出す際には Project の OCID を指定する必要があるため、まずここで Project を作成しておきます。

Project の作成画面では、基本情報（名前・説明・コンパートメント）に加えて、データ保存とメモリに関する設定項目があります。今回はデフォルトのまま作成しますが、それぞれの役割を簡単に紹介しておきます。

「データ保存」 では、レスポンスおよび会話を保持できる期間を構成します。レスポンスの保持期間は、生成後に自動的に削除されるまでのレスポンスの保持期間を制御し、会話の保持期間は、最新の更新後に会話が維持される期間を制御します。

「短期メモリー圧縮構成」 は、最近の会話コンテキストを継続的に要約して圧縮し、コンパクトで構造化された表現で重要な情報を保持しながらトークンの使用とレイテンシを低減する機能です。エージェントとの対話が長くなると、過去のやり取りがすべてコンテキストウィンドウを消費してしまいます。短期メモリー圧縮を有効にすると、これまでのチャット履歴を要約し、コンテキストを軽量化できます。コンテキストエンジニアリングの観点では、限られたコンテキストウィンドウの中でいかに「今の判断に必要な情報」を効率的に保持するかが重要になりますが、この機能はまさにその課題をプラットフォームレベルで解決してくれるものです。

「長期メモリー構成」 は、会話から重要な情報を抽出して格納し、後から取得することができる機能です。格納された情報は検索可能なベクトルとして埋め込まれます。たとえば、ユーザーの好みや過去の意思決定といった情報をセッションをまたいで記憶しておくことができます。コンテキストエンジニアリングの文脈では、「今のコンテキストウィンドウには載っていないが、エージェントが知っておくべき情報」を必要なタイミングで取り出せる仕組みといえます。

Tips
短期メモリー圧縮と長期メモリーは、いずれも Project 作成時にのみ設定可能で、後から変更することはできません。有効化したい場合は作成時に忘れずに設定しましょう。今回はどちらもデフォルト（無効）のまま進めます。

作成した Projects の OCID をメモしておきます。プログラムから OCI Enterprise AI の Responses API を呼び出す際に必要です。

サンプルコード"GitHub DeepInsight"

DeepWiki MCP サーバーを使って、GItHub のレポジトリを調査する対話型のCLIアプリケーション（Python）を作ってみます。

OCI Responses API に必要なパラメータ

.env ファイル

# OCI Enterprise AI の OpenAI 互換 Responses API 用
# 使い方: このファイルをコピーして .env にリネームし、実際の値を入れてください。
#   Windows: copy .env_example .env
#   macOS/Linux: cp .env_example .env

# OpenAI 互換エンドポイントのベース URL
# （ 'https://inference.generativeai.<region-id>.oci.oraclecloud.com/openai/v1'）
ENTERPRISE_AI_BASE_URL=

# API キー（OCI Enterprise AI の API キー）
ENTERPRISE_AI_API_KEY=

# プロジェクト ID（OCI Enterprise AI のプロジェクト ID）
GENAI_PROJECT_ID=

ENTERPRISE_AI_BASE_URL は、https://inference.generativeai.<region-id>.oci.oraclecloud.com/openai/v1 です。<region-id> は、us-chicago-1 や ap-osaka-1 のような形式の OCI リージョンです。リージョン毎に提供されているLLMが異なりますので使いたいモデルを提供しているリージョンを記載します。

ENTERPRISE_AI_API_KEY は、先程生成した API キーです。リージョン毎に異なりますので、上の ENTERPRISE_AI_BASE_URL のリージョンで作成された API キーである必要があります。これは、OCIDではなく、APIキーそのものを指定します。

GENAI_PROJECT_ID も、先程作成した Projects の OCID です。

"GitHub DeepInsight" のコード

200_demo_mcp_deepwiki.py

import os
import pyfiglet
from dotenv import load_dotenv
from rich.console import Console
from rich.markdown import Markdown
from rich.panel import Panel
from openai import OpenAI

"""
このPython スクリプトは、OpenAI SDKを使用してインタラクティブなチャットを実行するデモです。
 - Conversations APIによるマルチターンの対話
 - ターミナルでのインタラクティブなチャット体験
 - MarkdownとPanelによるリッチフォーマットの応答表示
"""

load_dotenv()
console = Console()

# OpenAIクライアントオブジェクトを作成
client = OpenAI(
    base_url=os.environ["ENTERPRISE_AI_BASE_URL"],
    api_key=os.environ["ENTERPRISE_AI_API_KEY"],
    project=os.environ["ENTERPRISE_AI_PROJECT_ID"],
)

# Agent を定義
agent = {
    "model": "xai.grok-4-1-fast-reasoning",
    "instructions": (
        "あなたはDeepWiki MCPを使用して GitHub のリポジトリを分析するエージェントです。"
        "DeepWiki MCPを使用してリポジトリを理解してユーザーのリクエストに応えます。"
        "DeepWiki から得られた情報だけに基づいて回答します。"
        "DeepWiki で情報が見つからない場合は、その旨を報告します。"
    ),
    "tools": [
        {
            "type": "mcp",
            "server_label": "DeepWiki",
            "server_url": "https://mcp.deepwiki.com/mcp",
            "require_approval": "never"
        }
    ],
}

# ユーザーのメッセージに対してエージェントを実行
def run_agent(user_input: str, conversation_id: str) -> None:
    # Responses API でエージェントループを実行
    with console.status("[bold blue]お調べしています..."):
        response = client.responses.create(
            **agent,
            conversation=conversation_id,
            input=user_input,
        )

    # レスポンスをMarkdown形式でパネル表示する
    console.print(Panel(Markdown(response.output_text)))

# メインエントリーポイント
if __name__ == "__main__":
    # 新しい会話を作成して、複数のターンをサポート
    conv = client.conversations.create()

    # ウェルカムメッセージを表示
    console.print(pyfiglet.figlet_format("GitHub DeepInsight"))
    console.print(
        "GitHub DeepInsightは、GitHubのリポジトリを分析し、"
        "その内容を深掘りすることができます。"
        "調査対象リポジトリは、オーナー名/リポジトリ名形式で指定してください。"
        "最大10個まで指定できます。"
    )
    console.print("'quit' や 'bye' で終了します")

    # インタラクティブなチャットループ
    while True:
        # ユーザーの入力を取得
        user_input = console.input("\n[bold green]メッセージ:[/] ").strip()

        # 終了コマンドを処理
        if user_input.lower() in (
            "quit", "exit", "q", "Q",
            "bye", "Bye", "byebye", "Byebye",
            "goodbye", "Goodbye", "goodbyebye", "Goodbyebye",
            "goodbyebye", "Goodbyebye", "goodbyebyebye", "Goodbyebyebye",
            "goodbyebyebyebye", "Goodbyebyebyebye",
            "さようなら", "さよなら", "バイバイ",
            "終わります", "終了", "終了します",
            "終わりだよ", "終わりだよ～"
        ):
            break

        # 空の入力を処理
        if not user_input:
            continue

        # エージェントを実行してレスポンスを表示
        run_agent(user_input, conv.id)

コードの要点の説明

OpenAIクライアントオブジェクトを作成コード

OpenAIクライアントオブジェクト作成

client = OpenAI(
    base_url=os.environ["ENTERPRISE_AI_BASE_URL"],
    api_key=os.environ["ENTERPRISE_AI_API_KEY"],
    project=os.environ["ENTERPRISE_AI_PROJECT_ID"],
)

OCI Enterprise AI は OpenAI の Responses API と互換性があるため、OpenAI の公式 Python SDK（openai パッケージ）をそのまま利用できます。ポイントは3つのパラメータです。

base_url には OCI Enterprise AI の OpenAI 互換エンドポイントを指定します。通常の OpenAI であれば https://api.openai.com/v1 となるところを、OCI のリージョン別エンドポイント https://inference.generativeai.<region-id>.oci.oraclecloud.com/openai/v1 に差し替えています。これにより、SDK 内部の HTTP リクエスト先が OCI に向きます。

api_key には先ほど OCI コンソールで生成した API キーを指定します。OpenAI の API キーと同じ役割を果たし、リクエストの認証に使われます。

project には OCI Enterprise AI の Projects の OCID を指定します。OpenAI SDK の project パラメータを流用する形で、OCI 側でどのプロジェクトに対してリクエストを実行するかを識別しています。

このように、接続先とクレデンシャルを変えるだけで、OpenAI 向けに書いたコードがほぼそのまま OCI Enterprise AI 上で動作します。

Agent の定義コード

Agent 定義

agent = {
    "model": "xai.grok-4-1-fast-reasoning",
    "instructions": (
        "あなたはDeepWiki MCPを使用して GitHub のリポジトリを分析するエージェントです。"
        "DeepWiki MCPを使用してリポジトリを理解してユーザーのリクエストに応えます。"
        "DeepWiki から得られた情報だけに基づいて回答します。"
        "DeepWiki で情報が見つからない場合は、その旨を報告します。"
    ),
    "tools": [
        {
            "type": "mcp",
            "server_label": "DeepWiki",
            "server_url": "https://mcp.deepwiki.com/mcp",
            "require_approval": "never"
        }
    ],
}

Agent は JSON 形式で定義します。

• model: 使用する LLM（OCI Enterprise AI Models の OCI Resposes API をサポートしたモデルである必要があります）。今回は、xAI の grok-4-1-fast-reasoning を使っています
• instructions: Agent 全体の役割や口調、制約などをまとめて与える「システムメッセージ」に相当するテキストです
• tools: Agent が利用できるツールを指定します。今回は、DeepWiki が提供している MCP サーバーを使います

Agent の実行コード

Agent の実行

def run_agent(user_input: str, conversation_id: str) -> None:
    # Responses API でエージェントループを実行
    with console.status("[bold blue]お調べしています..."):
        response = client.responses.create(
            **agent,
            conversation=conversation_id,
            input=user_input,
        )

    # レスポンスをMarkdown形式でパネル表示する
    console.print(Panel(Markdown(response.output_text)))

client.responses.create() が、OCI Enterprise AI の Responses API を呼び出している箇所です。**agent で先ほど定義した Agent の設定（model、instructions、tools）を展開して渡しています。

conversation パラメータには、事前に client.conversations.create() で生成した会話IDを渡します。OCI Enterprise AI の Conversations API はサーバーサイドで会話の状態を管理しており、同じ conversation ID を使い続けることで、過去のやり取りの文脈を保持したマルチターン対話が実現します。クライアント側で会話履歴を配列に蓄積して毎回送り直す必要がなく、コードがシンプルになるのが利点です。

input にはユーザーの入力テキストをそのまま渡します。Responses API はこの入力を受け取ると、Agent の instructions に従い、必要に応じて tools で定義された MCP サーバーを呼び出しながら、最終的な回答を生成します。MCP サーバーの呼び出しや結果の統合といったエージェントループはサーバーサイドで自動的に処理されるため、クライアント側で明示的にループを実装する必要はありません。

レスポンスの output_text に最終的な回答テキストが格納されるので、それを Rich ライブラリで Markdown レンダリングして表示しています。

依存パッケージ

requirements.txt

python-dotenv>=1.0.0,<2
openai>=1.60.0,<2
rich>=13.0.0,<15
pyfiglet

実行例

ここで、「oracle/mcp と krisrice/oracle-db-skills について説明して」と指示してみます。

調査が開始されて、「お調べしています...」と表示されました。

そして、最終的な出力は下記となりました。

さらに、「krisrice/oracle-db-skills について詳しく説明してください」と聞いてみます。

調子に乗って詳しくと聞いたので、かなり長い出力となりました。

まとめ

今回は、OCI Enterprise AI の環境セットアップから、MCP サーバーを活用した対話型 AI エージェントの実装までを試しました。

実際に手を動かしてみて感じたのは、OpenAI SDK との互換性のおかげで、既存の知識やコードをそのまま活かせるという点です。base_url と api_key を差し替えるだけで OCI 上のモデルを呼び出せるため、新しい SDK やフレームワークを学ぶコストがほとんどかかりません。

Conversations API によるサーバーサイドの会話状態管理も便利でした。クライアント側で会話履歴を蓄積・送信するコードを書く必要がなく、conversation ID を渡すだけでマルチターン対話が成立するため、実装がかなりシンプルになりますね。

MCP サーバーとの連携も、tools の定義に URL を記述するだけで済みます。エージェントがツールを呼び出して結果を統合するループはサーバーサイドで自動処理されるので、クライアント側のコードは「リクエストを投げて結果を表示する」という単純な構造だけで済みます。

OCI Enterprise AI では xAI Grok、Meta Llama、Google Gemini、Cohere Command、OpenAI GPT など複数プロバイダのモデルを統一的な API で利用でき、用途やコストに応じたモデルの使い分けも容易です。エンタープライズ向けの IAM 統合やガバナンス機能も備えているため、検証から本番まで一貫したプラットフォームで運用できる点も魅力だと思います。

今回は、シンプルなエージェントでしたので、OpenAI SDK のみで構成していますが、OpenAI Response API と互換性のある様々な OSS エージェントフレームワークでエージェント開発を行うことができます。また、この記事の製作例では、コードをローカルで動かしていますが、OCI Enterprise AI Agents には、作ったエージェントアプロケーションをホスティングしてくれる機能もあります。

OCI Enterprise AI は、エージェント開発の敷居を大きく下げてくれるサービスだと思います。この記事が MCP を活用して外部のデータソースやツールと連携するエージェントを作ってみたいと思っている方々のお役に立てましたら。