この記事は、2026-03-24(火) に開催された、OutSystems Developer Day Nagoya 2026 のセッションで話した内容を、あらためて解説するものです。
セッションで使用したスライドは、Speaker Deck で公開しています。
はじめに
前回の記事で、ODC における Action calling 機能が、MCP と同様の仕組みで AI モデルを機能拡張するものだという解説をしました。
今回のイベントセッションでは、その Action calling を含めた、OutSystems と MCP に関わるいくつかの話題についてお話ししました。その中から、今回の記事では、前回記事と重複する内容は極力省いた形で、OutSystems と MCP について、以下の３つの内容についての解説を試みます。
- MCP 概要と ODC の Action calling — MCP の基本と、ODC で AI にツールを使わせる仕組み
- ODC での MCP 利用 — ODC から公開 MCP サーバーを使う方法
- O11 で MCP Server を直接実装 — O11 の Expose REST API を使って MCP Server を作る方法
MCP 概要と ODC の Action calling
MCP（Model Context Protocol）は、2024 年に Anthropic が公開した、AI アプリに外部ツールを使わせるための標準プロトコルです。MCP に対応した AI ツールを介することで、さまざまな外部サービスを AI モデルに使わせることができます。
ODC の Action calling は、MCP に限らず、OutSystems の任意のサーバーアクションを AI に使わせる ことを可能にする仕組みです。ODC で MCP ツールを使う場合も、まず、ODC Portal で MCP ツールをインポートしてサーバーアクション化し、それを Action calling を介して利用します。
MCP や Action calling における、ODC と AI モデルの間の通信内容やそのシーケンスについては、前回記事で詳しく解説しています。
ODC での MCP 利用
ODC は PaaS なので、現時点ではネットワーク経由でアクセスできる「リモート MCP サーバー」のみを利用できます。設定の流れは「ODC Portal で接続設定 → ODC Studio で組み込む」です。
(1) ODC Portal で MCP サーバーを設定する
ODC Portal の Integrate > Connections から MCP サーバーを選択し、接続情報を設定します。設定後の画面で、その MCP サーバーで公開されているツールのうち、ODC アプリで使いたいものを選択して、 Import ボタンを押下します。
(2) ODC Studio で組み込む
ODC Portal で Import したツールは、サーバーアクションとして、ODC Studio の Add public elements でアプリに追加できるようになります。通常の参照追加と同じ操作です。完了すると、Logic タブの Server Actions に追加した MCP アクションが並ぶので、これを、Agentic app の AI モデル呼び出しアクションの Action calling で、「Add action」ボタンから指定します。
MCP を使う場合のシステムプロンプト
エージェントの動作時に、AI モデルがどの MCP ツールアクションを利用するかは、ツールアクションの Description を参照して、AI モデル側で適宜判断してくれますが、エージェントのシステムプロンプトに、適切な誘導を記載しておくと良いでしょう。
たとえば、AWS が公開している Knowledge MCP Server（AWS の公式情報を参照する MCP ツール）を使うことで、AWS 公式情報のみを参照して回答するチャットボットを作成することができます。このとき、システムプロンプトに次のような指示を書きます。
- 公式ドキュメント検索コマンドを使って情報を収集すること
- 必要に応じてドキュメントの内容を確認するコマンドを使うこと
- 収集した情報のみを使ってユーザーへの回答を構築すること
このように設定しておけば、例えば「新規の社内向け業務 API を AWS で作る場合に、Lambda 中心か、コンテナベースか、判断材料を整理して」という質問に対して、世間一般の情報ではなく、AWS 公式ドキュメントのみを参照して詳細に回答してくれるようになります。
現状では ODC からすぐに業務利用できそうなリモート MCP サーバーはまだ多くはありませんが、アプリを使って構築している業務フローによっては、GitHub や Jira の MCP サーバーを活用できる場面もあるでしょう。
O11 で MCP Server を直接実装
最後に、O11 で直接 MCP Server を実装する方法をご紹介します。
「ODC の話は良いんだけど、うちは O11 を使っているんだよね」という方は少なくないと思います。そういった O11 ユーザーの方々も、AI 活用はさまざまに検討されているはずです。
本項は、O11 と AI の連携に「そういう方法もあり得るのか」という視点を紹介するものです。
概要と動機
下のスクリーンショットは、これから紹介する「O11 で作った MCP Server」を、Claude Desktop（Anthropic 公式アプリ）で利用している様子です。O11 で実装している機能を、Claude 内で直接利用することができています。
O11 の実装を AI ツールで利用する場合の、標準的なアプローチは次のようなものです。
- AI ツールで使いたい O11 アプリの機能を、通常の REST API として O11 に実装する。
- ローカル or リモートの環境に、別途 MCP サーバーを用意し、この MCP サーバーで、1 で用意した REST API を参照するツールアクションを構成する。
- AI ツールから、2 で構成した MCP ツールアクションを利用する。
しかし、この方法は「MCP サーバーを自分で立てられる IT スキルのある人」限定の使い方になってしまい、社内などへの横展開がしにくいという難点があります。
リモート MCP サーバーを、「JSON-RPC という規格に沿った内容をやりとりする HTTP エンドポイント」と捉えると、このエンドポイントを O11 の Expose REST API で直接実装 することができそうです。これができれば、エンドポイントの情報を展開するだけで、社内などで容易に使ってもらえるようになります。
なお、本稿執筆時点（2026年4月）では、O11 の Expose REST API 単体での OAuth 認証への対応には制限があります。以下で紹介する実装では、リクエストパラメーターに埋め込んだ Key 文字列を照合する簡易認証を採用しています。
こういった簡易認証は、社内閉域や開発・検証環境での利用であれば十分というケースもあるかと思います。ただ、インターネット公開環境での利用は、リスクを考えて慎重に行なう必要があります。
この観点からは、この記事で紹介している方法が適用できる範囲は限定的かもしれません。「こういう方法もある」という引き出しのひとつだとお考え下さい。
実装詳解
実装すべき JSON-RPC メソッド
AI ツールから O11 アプリで用意した REST エンドポイントに飛んでくるリクエストの共通構造は次の通りです。
{
"jsonrpc": "2.0",
"id": 12,
"method": "<メソッド>",
"params": {
"name": "<アクション名>",
"arguments": {
"<入力パラメーター名>": "<入力パラメーター値>"
}
}
}
リクエストの id は、レスポンスにそのまま返す必要があります。
method にはさまざまな値が送られてきますが、アクションを実行して返すという動作を実現するだけであれば、筆者が検証した範囲では、 initialize、tools/list、tools/call の３つ への対応だけで十分でした。
| メソッド | 用途 |
|---|---|
initialize |
初期化 |
tools/list |
利用可能なツール（アクション）の一覧を返す |
tools/call |
指定されたアクションを実行する |
tools/call の場合のみ、params.name（アクション名）と params.arguments（入力パラメーター）を確認する必要があります。
以下では、この３つのリクエストに対して、それぞれどのようなレスポンスを実装することになるのかを解説します。
initialize へのレスポンス例
初期化リクエストへのレスポンスです。
{
"jsonrpc": "2.0",
"id": 0,
"result": {
"protocolVersion": "2024-11-05",
"capabilities": {
"tools": {}
},
"serverInfo": {
"name": "OutSystems-ContactList-Tool",
"version": "0.0.1"
}
}
}
id 以外は、基本的に固定値で返せば OK です。
protocolVersion は、この MCP エンドポイントが採用するプロトコルのバージョンを示す文字列で、上の例では初期のステーブルバージョン 2024-11-05 を返しています。例えば、ツールアクションのレスポンスとして構造体を返したい、という場合は、2025-06-18 以降のバージョンを指定する必要があります。
serverInfo にはツールの名前とバージョン情報を固定値で設定します。
tools/list へのレスポンス例
「どんなツール（アクション）があるの？」というリクエストへの応答です。
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"tools": [
{
"name": "SearchContacts",
"description": "提供された文字列を使って、担当者リストを検索し...",
"inputSchema": {
"type": "object",
"properties": {
"NameContains": {
"type": "string",
"description": "担当者リストの名前に含まれる文字列..."
}
},
"required": ["NameContains"]
}
}, // 以下、実装するツール（アクション）の数だけ繰り返し
]
}
}
実装しているアクション（AI に使わせたいアクション）の数だけ、tools 配列の要素を繰り返します。各要素には、アクション名・description・入力パラメーターの名前/型/description・必須パラメーターのリストを含めます。
tools/call のリクエスト例
最後は「このツール（アクション）実行して」の tools/call リクエストです。
上の２つと違って、tools/call の場合、リクエストにも可変部があるので、リクエスト例から見ていきます。
{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": {
"name": "SearchContacts",
"arguments": {
"NameContains": "米田"
}
}
}
ツール（アクション名）と、その入力パラメーターが渡されるので、これを抽出して対応するアクションを実行する、という実装をすることになります。
「キー名が可変な JSON」の取り扱い
tools/call リクエストで、アクションの入力パラメーターが格納された params.arguments では、入力パラメーターの名前がオブジェクトのキー名の形で渡されています。このような「キー名が可変」な JSON は、OutSystems のストラクチャーとの変換が少し困難です。
が、実装するツールアクションの総数が膨大でないなら、全アクションの入力パラメーターを１つにまとめたストラクチャーを用意することで対応できます。
この記事で紹介している例では、SearchContacts と GetContactDetail の２つのアクションを実装しているので、SearchContacts の入力パラメーター NameContains と、GetContactDetail の入力パラメーター Id の両方をまとめた RequestParamsArguments というストラクチャーを用意しておいて、これを使ってデシリアライズする、という方法を使っています。
tools/list レスポンスのシリアライズにも同様の手法が使えます。
ただ、こういう「OutSystems のシリアライズ/デシリアライズの制限」ゆえの実装工夫をするには、かなり込み入ったストラクチャーを手動でチマチマ用意する必要があります。その煩雑さを嫌う場合は、このあたりの処理を、文字列操作の形で実装することも可能ではあります（ローコードらしさから離れてしまうことの割り切り）。
tools/call のレスポンス例
アクションの実行結果を返すレスポンスです。
先に少し書いたように、initialize で適切なプロトコルバージョンを返して構造体で返す、ということも可能ではありますが、どのみち LLM に渡す情報なので、O11 アクション内で JSON シリアライズした上で、LLM 向けのテキストに埋め込んで返す形が、汎用的で実装も簡単です。
{
"jsonrpc": "2.0",
"id": 2,
"result": {
"content": [
{
"type": "text",
"text": "検索結果: 1件の担当者が見つかりました。\r\n詳細データ(JSON): [{\"Id\":495,\"Name\":\"米田 謙信\"}]"
}
]
}
}
エラーレスポンス例
最後はエラー応答です。
未実装のメソッドには -32601（Method not found）、存在しないアクション名には -32602 を返すようにしておけば、世間一般の AI ツールからの利用であれば、基本的に問題なく動作するはずです。
{
"jsonrpc": "2.0",
"id": 4,
"error": {
"code": -32601,
"message": "Method not found",
"data": {
"details": "そのメソッドは実装されていません。"
}
}
}
O11 Expose REST API での実装例
ここまでで解説した内容で、単一の Expose REST API アクションを実装します。実際に使うツールアクションが複数あっても、MCP 応答用のアクションは１つだけで、その中でリクエストを見て振り分ける形になります。
この例では：
- URL パラメーターで渡された Key 文字列をサイトプロパティと照合し、失敗したら 401 を返す（簡易認証）。
- リクエストの
methodを見て、initialize/tools/list/tools/callのそれぞれで処理を分岐。 -
tools/callの場合はさらにparams.name（アクション名）を見て、実際の処理を振り分ける。
実装しているアクションが増えた場合は 3 の分岐先を追加するだけです。
こうやって見ると、意外なほどシンプルな実装で実現できることが分かると思います。
AI ツールからの利用
上で示したフロースクショの内容で実装した MCP エンドポイントを AI ツールから使うには、次の設定を行ないます。
-
作成した Expose REST API アクションの HTTP Method プロパティを
POSTに設定 します。 -
AI ツール（Claude Desktop など）の MCP 設定に、以下の形式でエンドポイントを登録します。
https://<プラットホームサーバーホスト名>/<モジュール名>/rest/Mcp/Tool?Key=<サイトプロパティに設定した Key 値>
このセクションの冒頭でお見せしたスクリーンショットは、この手順で Claude Desktop に登録して使った様子です。
まとめ
本記事の要点
- MCP: AI に外部ツールを使わせる標準プロトコル（2024 年 Anthropic 公開）
- ODC × MCP: ODC Portal でインポート → Studio から Action calling で利用
- O11 × MCP: Expose REST API で JSON-RPC を直接実装すれば O11 単独で MCP Server になる
-
O11 MCP 実装のコア:
initialize/tools/list/tools/callの 3 メソッドだけで動作する
OutSystems と MCP に関して、ODC での Action calling による MCP の利用と、O11 で直接 MCP Server を実装する話について解説してきました。
後半で解説した、O11 で MCP Server を直接実装する方法 は、OutSystems 公式コンテンツではあまり触れられることのない話題だと思うのですが、社内の閉じた環境で O11 を使っている方には、刺さることもある内容なんじゃないでしょうか。
この記事で解説したような、公式ドキュメントに掲載されていないような使い方の工夫がいろいろ考えられるのも、OutSystems を使う楽しみの１つです。
これらの情報が、OutSystems の AI 活用の話、そして何より「楽しい開発」に、すこしでもお役に立てていたら幸いです。