OCI Database ServicesのマネージドMCPサーバーをCodexから使ってみた

はじめに

2026年10月にOCI Database Servicesで機能拡張があり、マネージドMCPサーバーが利用できるようになりました。

この機能により、ユーザーはMCP対応のAIクライアントから自然言語で依頼し、OCI上のデータベース環境の構成や状態を確認できるようになっています。

今回は、大阪リージョンでMCPサーバーを作成し、Codexから次の2パターンを試しました。

• DB一覧を取得し、サービス別・状態別に集計する
• FAILED状態のDBを抽出し、詳細情報を確認する

本記事ではOCI側の設定、Codexへの接続、実行結果まで紹介します。

1. どのような機能か

マネージドMCPサーバーは、MCPクライアントとOCI Databaseのコントロール・プレーンAPIをつなぎます。
利用者が自然言語で依頼すると、AIクライアントが必要なMCPツールを選択し、取得結果を整理することができるという機能です。

今回の機能が使える対象サービスは次の4つです。

• Base Database Service(BaseDB)
• Oracle Exadata Database Service on Cloud@Customer(ExaDB-C@C)
• Oracle Exadata Database Service on Dedicated Infrastructure(ExaDB-D)
• Oracle Exadata Database Service on Exascale Infrastructure(ExaDB-XS)

認証にはOCI Identityを通じたOAuthを使用し、リソースへのアクセスには既存のIAMポリシーが適用されます。MCPに接続しても、認証したユーザーの権限が拡張されるわけではありません。

また、本検証時点で、このマネージドMCPサーバーが提供する操作は読み取り専用で、MCPサーバー経由では、OCI Databaseリソースの作成・更新・削除はできませんでした。

今回は、OCIが管理するリソース情報を取得する動作を確認しており、DBに接続してSQLを実行する検証は行っていません。

2. 検証環境と事前準備

検証環境

事前に用意するもの

• OCIコンソールにログインできるユーザー
• MCPサーバーを作成するための権限
• 使用するアイデンティティ・ドメインを参照する権限
• 対象DBリソースを参照する権限
• 対象コンパートメントのOCID
• 利用可能なCodex環境

権限は、次の3つを分けて確認すると整理しやすくなります。

以降の手順は、これらの権限がある環境を前提にしています。

3. セットアップの流れ

セットアップの大まかな流れは以下です。詳しくは公式ドキュメントをご確認ください。

4. OCI側でMCPサーバーを作成する

4-1. AI機能画面を開く

OCIコンソールの Oracle AI Database から対象サービスを開きます。今回は、Oracle Exadata Database Service on Exascale Infrastructure の画面から操作しました。

左側の AI機能 を選択し、MCPサーバーの表示 をクリックします。

4-2. MCPサーバーを作成する

MCPサーバー一覧で、MCPサーバーの作成 をクリックします。

作成画面で、次の項目を指定します。

例えば、次のように設定します。

名前：mcp-test
コンパートメント：MCPサーバーの作成先
コンパートメント内のドメイン：既存ドメインの所属先
ドメイン：利用する既存ドメイン
サービス：検証対象のDatabaseサービス

MCPサーバーの作成先と、ドメインの所属コンパートメントは別の項目です。

4-3. ドメインが表示されない場合

今回つまずいたのが、ドメイン選択欄に候補が表示されない点でした。

次の順番で確認します。

1. ドメインが所属するコンパートメントを選択しているか確認する
2. 同じユーザーで アイデンティティとセキュリティ → ドメイン を開く
3. 対象ドメインの一覧表示・詳細表示ができるか確認する
4. 表示できなければ、ドメイン参照権限の適用範囲を確認する
5. IAM画面では表示できる場合、MCP作成画面の選択条件や取得エラーを確認する

権限については、read domains の適用範囲を確認します。公式IAM仕様では、inspect domains に一覧取得、read domains に詳細取得などが含まれます。

IAM権限リファレンス

4-4. 作成後にエンドポイントを取得する

設定を確認して作成すると、詳細画面からMCPエンドポイントを取得できます。以降で使うため、Copy endpoint でコピーします。

5. Codex側をセットアップする

5-1. Codex CLIが使えるか確認する

ターミナルで次を実行します。

codex --version

今回の環境では、次のバージョンでした。

codex-cli 0.166.0-alpha.5.1

codex が見つからない場合は、公式のCodex CLIセットアップ手順でインストールします。公式ページにはmacOS/Linux向けのインストーラーが案内されています。

curl -fsSL https://chatgpt.com/codex/install.sh | sh

インストール後に codex --version を再実行します。Codex自体を初めて利用する場合は、codex を起動してサインインします。

Codex自体へのサインインと、次のOCI MCPのOAuth認証は別の認証です。

5-2. MCPサーバーを登録する

OCIで取得したエンドポイントを指定します。

codex mcp add oci-database \
  --url 'https://<生成されたホスト名>/mcp'

• oci-database：Codex側の登録名
• --url：OCIで生成されたMCPエンドポイント

今回の実行では、登録に続いてOAuth認証が開始されました。

Added global MCP server 'oci-database'.
Detected OAuth support. Starting OAuth flow…

認証用URLが表示されたら、ブラウザで案内に従ってOCIの認証を進めます。今回の環境では、最終的に次のメッセージを確認できました。

Successfully logged in.

OAuth認証を別途開始する場合は、次を実行します。

codex mcp login oci-database

認証から情報取得までの流れを簡略化すると、次のようになります。

5-3. 登録内容を確認する

次のコマンドで確認できます。

codex mcp list

今回登録したサーバーの詳細を確認します。

codex mcp get oci-database

今回の環境では、次の設定を確認できました。

enabled: true
transport: streamable_http

CodexのMCP設定・OAuth認証については、公式MCPドキュメントを参照してください。

5-4. チャットからツールを確認する

今回のチャットでは登録直後にツールが反映されていなかったため、Codexアプリを再起動してから確認しました。

チャットに次のように入力します。

OCI MCPのツール一覧を確認して

今回の接続では、116個のツールを認識できました。

ツール数は今回の設定・検証時点の値です。すべての接続で同じ数になるという意味ではありません。

ここから、新規チャットで情報取得を試します。

6. 検証①：DB環境の棚卸し

入力したプロンプト

コンパートメントOCIDを指定し、終了済みのDBを除いた一覧と集計を依頼しました。以下のプレースホルダーを、自分の環境の値に置き換えます。

OCI Database MCPを使って、以下のコンパートメントの
TERMINATEDを除くDB一覧を取得してください。

コンパートメント：
<対象コンパートメントのOCID>

DB名、DB一意名、サービス種別、所属DB Home、
DB Homeのバージョン、ライフサイクル状態を表にし、
サービス別・状態別の件数も集計してください。

使用したMCPツール名と取得条件を最後に記載してください。
ページが分かれる場合は続きを取得してください。
接続文字列、IPアドレス、ユーザー情報は回答に含めないでください。

結果

30件のDB Homeから計28件のDB情報を取得し、TERMINATEDの3件を除いた25件が一覧化されました。

CodexがOCI Database MCPで取得したDB一覧の一部。DB Homeのバージョンやライフサイクル状態を整理できました。

使用されたツールと取得条件

取得後に、DBの lifecycleState = TERMINATED を除外しています。

サービス種別は、返却されたリソース階層タグの service_name から分類していました。バージョンはDB Homeの取得値です。

今回の応答には次ページトークンは返されず、各応答の件数は指定上限未満でした。

DB Homeをたどって取得していた

事前の検証では、ListDatabases にコンパートメントだけを指定すると、次のエラーが返りました。

MissingParameter
This request is missing a required value for at least one of
the following arguments: dbHomeId,systemId

今回のAPI呼び出しでは、DB Homeまたはシステムの指定が必要でした。Codexは、DB Home一覧を先に取得する方法で処理を進めました。

利用者が各DB HomeのOCIDを調べて依頼し直すことなく、Codexが複数のツールを使って一覧に整理できました。

7. 検証②：FAILED状態のDBの初期確認

棚卸しでFAILEDのDBが4件あったため、続いて詳細を確認しました。

入力したプロンプト

OCI Database MCPを使って、以下のコンパートメントの
ライフサイクル状態がFAILEDのDBを確認してください。

コンパートメント：
<対象コンパートメントのOCID>

DB名、DB一意名、所属DB Home、状態、lifecycleDetailsを
表にしてください。必要に応じてDB詳細も取得してください。

取得した事実と、追加確認が必要な点を分けて説明し、
原因を推測だけで断定しないでください。

使用したMCPツール名と取得条件を最後に記載してください。
ページが分かれる場合は続きを取得してください。
接続文字列、IPアドレス、ユーザー情報は回答に含めないでください。

結果

FAILEDのDBは4件でした。Codexは一覧取得に加えて、GetDatabase で各DBの詳細も取得していました。

4件は同じDB Home・Exadata Exascale VMクラスタに所属し、lifecycleDetails には、いずれも「ホスト上のクラウド管理ツールがリソースを検出できない」という内容が返されました。

返されたメッセージには手動削除した場合の案内も含まれていましたが、手動削除が実施されたことを示す証拠ではありません。

回答では、事実と追加確認事項が次のように分けられていました。

使用されたツールと取得条件

今回確認できたのは、調査対象の抽出とOCIが保持する状態説明までです。

根本原因の特定や、リソースの削除・修復は行っていません。障害時の初期確認として、次に調べる対象を整理できました。

8. 試してみた感想

今回の検証では、自然言語の依頼から複数サービスにまたがるDB情報の収集・抽出・集計まで実行できました。

特に便利だったのは、複数のDB Homeをたどって情報を集め、まとめて表にできた点です。環境の棚卸しや、状態別の確認に活用できそうだと思いました。

一方、取得結果の意味を区別することも大切です。

• DB Homeのバージョンは、DB内部で実測したバージョンとは区別する
• OCIのライフサイクル状態がAVAILABLEでも、DB内部を含む健全性の確認とは区別する
• FAILEDの状態説明を取得できても、それだけで根本原因を断定しない

マネージドMCPサーバーを使うことで、情報収集や整理の手間を減らしながら、必要な追加調査につなげられると感じました。

参考リンク

• Managed MCP Servers for OCI Database Services
• Details for IAM with Identity Domains
• Codex CLI
• Codex：Model Context Protocol