今月（2026/04）はじめに発表されていた、ODC Studio内でMentorを利用する機能（チャットI/Fによるローカルコーディングエージェント機能）がリリースされていたので軽く試しておく。
関連資料
すでに動画コースがリリースされているので、まずここから始めるのが良い。
Agentic development
機能名である「Mentor Studio」を含むものを見る。
この中に、「Modify an app with Mentor Studio」というハンズオンのページがあるが、そのTipsがMentor Studioを使う時のガイドラインを提供している。
Reference elements by name. Mentor doesn't detect the current screen or your selection. Always include entity, action, or screen names in the prompt.
一般のコーディングエージェントと違い、「今開いているファイル（OutSystemsでいうならScreenやActionなどの要素が該当するか）」を認識しないため、対象とする要素は名前で明確に指定する。
One task per prompt. Break complex requests into individual steps for more predictable results.
複雑な依頼はそのままプロンプト入力せず、細かいステップに分割した上で、１ステップずつプロンプト入力する。
前提条件
Mentor StudioのリリースがODC Studio V1.7.1なので、それ以上のバージョンを使っていることを確認する。
また、接続先のOrganizationについて、PEにはまだきていないようだ（2026/4/14時点）。いくつかの有償Organizationについては全てきているようだった。現時点で動作確認したい場合は、PE以外に接続する必要が恐らくある。
使い方
ODC Studio右上、検索アイコンの右隣に「Mentor]ボタンが追加されているのでクリック。
依頼したい作業を入力し、Enter（改行はShift + Enterでできた）。
指示に対し、既存の実装を確認し、計画を立て、実行する。その過程が以下のように表示される（動画のコースでは作業の承認を求めるという話だったと思うのだが、今回はWelcome画面実装まで進んでしまった）。以下のスクリーンショットでは後続作業の提案まで表示されている。
また、最後に修正が入った要素のリストが表示される。「View changes」ボタンをクリックするとマージダイアログが表示され、Mentor Studioによる修正前後の比較を確認できる。勝手にPublishまではされない。
Entityに対する操作を試す
プロンプト
ECサイトの「注文管理」に必要なEntityを作ってください。
1つの注文に複数の商品が含まれるケースを考慮し、ユーザー、商品、注文、注文明細の4つのテーブルで構成してください。
各テーブルに適切なデータ型と、Unique・外部キー制約を含めてください。
また作成したEntityは区別しやすいように1つのフォルダにまとめてください。
レスポンス
プロンプトの内容は基本的に踏まえた結果が返ってきた。ただ、フォルダに作って、というプロンプトに対し、フォルダを作りはしたものの、Entityはフォルダ内ではなくルートに置かれていた。型や参照は良さそう。
1. 追加したフォルダ
OrderManagement
4つのEntityをこのフォルダにまとめました
2. 追加したEntity
ECUser
Id : Long Integer / AutoNumber / 主キー
Email : Email / 必須
FullName : Text(100) / 必須
PhoneNumber : Phone Number
CreatedAt : Date Time / 必須
Product
Id : Long Integer / AutoNumber / 主キー
SKU : Text(50) / 必須
Name : Text(100) / 必須
Description : Text(500)
UnitPrice : Currency / 必須
IsActive : Boolean / 必須
CreatedAt : Date Time / 必須
Order
Id : Long Integer / AutoNumber / 主キー
OrderNumber : Text(30) / 必須
UserId : ECUser Identifier / 必須 / 外部キー
OrderDate : Date Time / 必須
Status : Text(30) / 必須
TotalAmount : Currency / 必須
ShippingAddress : Text(500)
OrderItem
Id : Long Integer / AutoNumber / 主キー
OrderId : Order Identifier / 必須 / 外部キー
ProductId : Product Identifier / 必須 / 外部キー
Quantity : Integer / 必須
UnitPrice : Currency / 必須
LineAmount : Currency / 必須
3. 制約
Unique
ECUser.Email
Product.SKU
Order.OrderNumber
OrderItem(OrderId, ProductId)
同一注文内で同一商品が重複しないように設定
外部キー
Order.UserId → ECUser
OrderItem.OrderId → Order
OrderItem.ProductId → Product
削除ルール
Order.UserId は Protect
OrderItem.ProductId は Protect
OrderItem.OrderId は Delete
注文削除時に注文明細も削除
必要なら次に、
注文ステータスを Static Entity に分ける
この4テーブル向けの 一覧画面 / 登録画面
注文合計を自動計算するロジック
まで続けて追加できます。
Action作成
プロンプト
種別：Client Action
Input Parameter： 処理対象Textと区切り文字（Text型）
Output Parameter：区切り文字で処理対象Textを分割し、結果をTextのList
制約：Server Actionを使わない
結果
今回は、計画を立てた後、その計画で進めて良いか確認をとってくれた。
ただ、当初はちょっと手抜きをしてServer Actionを呼び出す構成にされていた。Server側処理呼び出しにはオーバーヘッドがあるので、共通部品的利用が想定される場合は、可能な限り避けたい。
そこでプロンプトに「制約：Server Actionを使わない」を追加した。
出来上がったActionは以下の通り、再帰を使っている。先頭の区切り文字の左側をOutput ParameterのListに追加し、右側を同じActionの再帰呼び出しのパラメータに渡す構造。ざっとみた感じは良さそう（動作確認はしていない）。
IfのLabelには問題がありそう（区切り文字が見つからない、という条件のIfのLabelに「Delimiter found?」と設定されている）だが、このくらいなら小規模な修正。
Action Flow 1/2
Action Flow 2/2
既存Screenの修正
「Welcome Screen上の「ようこそ」を緑色に変更して」というプロンプトで動作確認してみた。想定通り該当の文字色は変更された。
ちゃんとStyle Classesプロパティを使ってくれている。
感想
- ちょっとプロンプトに対する処理時間が長い
- 思ったよりずっとコーディングエージェントとして動いている
- プロンプトによる依頼で自律的に要素を修正し、勝手にPublishせずにマージウィンドウで結果を確認させてくれる。概ね思い描いていた通りの作業フロー
- エージェントの作業依頼している間は他の要素を見ながら別の実装を検討したいので、ダイアログでなく別ウィンドウにしてほしいが……
まだ出たばかりで、これから発展していくと考えれば、期待以上と言ってよさそう。この調子で是非頑張ってほしい。