2026/09時点のMentor StudioがOutSystemsに限定しないWeb Appの仕様を受け取った時にどう実現するかを確認したい。
後で、同じ仕様をGitHub CopilotかClaude Codeでも試してみてどこが違うのかも検証してみるつもり。
環境情報
ODC Personal Edition
ODC Studio (Version 1.7.25)
仕様案をGeminiに作ってもらう
以下のプロンプトで依頼したらGeminiがいい感じに作ってくれたのでこれでいいことにする。
以下の条件を満たす仕様(プロンプト)案を作って
目的:色々なハーネスやモデルの性能を比較するため、最小限の機能を備えた企業の内部業務アプリケーション作成用プロンプトを用意する
要求事項:承認フロー、権限管理、マスタ管理、帳票、バッチ、監査ログなど、業務アプリらしい要素をひと通り含める
仕様案
GitHubに配置してある。リンクしたらQiitaが表示してくれたのでこれで。
Appを用意
いつも通り、ODC StudioからCreate -> Web Appで空のAppを用意した。
Mentor Webでも作れるが、できることが限られているのと、Mentor Studioでやったことと混ざって評価しにくくなるのを避けるためこの形式。
ODC StudioでAppを開くと、最近は画面の左側にMentorのペインがある。
とりあえず仕様を貼り付けて依頼 → 意図を明確にするための質問が返ってきた
仕様テキストを貼り付けて、「以下の仕様を満たす機能を作成して」と依頼。
ODCで実現するにあたり仕様を明確にするための質問を返してきた。
この仕様は非常に詳細で、OutSystems Webアプリとして実装可能な部分と、プラットフォームの特性上アプローチが異なる部分があります。実装計画を提示する前に、いくつか確認させてください。
**OutSystems (ODC) での実装における前提確認:**
1. **テストコード**: ODCはビジュアル言語のため、従来のUnit/Integrationテストコード(JUnit等)は生成できません。ステータス遷移の検証はサーバーアクション内のロジックで担保する形になります。この点はご了承いただけますか?
2. **Docker / README.md**: ODCはクラウドPaaSのため、`docker compose`での起動やREADME.mdファイルの生成はプラットフォームの範囲外です。代わりに、ODC Portal上での動作確認手順をコメントとして残す形でよいでしょうか?
3. **IPアドレス取得**: 監査ログのIPアドレス記録はODCの標準機能では取得が困難です。クライアント情報の記録は「ユーザーID・タイムスタンプ・操作種別」に絞る形でよいでしょうか?
4. **PDF出力**: ODCには標準のPDF生成機能がありません。印刷用HTMLレイアウト(ブラウザの印刷機能でPDF化)として実装する形でよいでしょうか?
5. **初期シードデータ**: ODCにはマイグレーションスクリプトの概念がありません。管理画面から手動投入するか、アプリ起動時に自動投入するサーバーアクションとして実装する形でよいでしょうか?
上記の前提が合意できれば、全体の実装計画を提示します。
1. テストコード
この通りでOutSystemsは製品と組み合わせて使う自動テストの機能がない。
一応ForgeにBDDFrameworkなどがあるが、一般的なユニットテストツールに比べると作成にも実行にも時間がかかる。
というわけでこれは仕方ない。
2. Docker / README.md
ODCにはOutSystemsが管理するクラウド環境しかなく、バージョン管理も製品組み込みのものを強制的に利用することになる。
よってここも仕方ない。
それよりも、MentorがちゃんとDockerなどのことも認知して回答を返してきている。
恐らく内部で新し目のAIモデルを使っているんだろうから、普通の言語でAIDD使っている時と同じような返答が期待できそう。
3. IPアドレス取得
クライアントのIPアドレスがとれないとのことだが、リクエストヘッダのX-Forwarded-Forからとれた気がするので、その旨聞いてみる。
4. PDF出力
標準機能には確かにPDF出力機能がない。
UltimatePDFなどForgeコンポーネントを使えばできるのだが、そこは調べてくれないようだ。この点は一般言語でのAIDDと比べるとマイナスか。
UltimatePDF利用を後付けすればいいので、提案された「印刷用HTMLレイアウト(ブラウザの印刷機能でPDF化)として実装する形」でよしとする。
5. 初期シードデータ
「ODCにはマイグレーションスクリプトの概念がありません。」これはその通り。
そこで、昔からトレーニングなどで使われていた、When PublishedのTimerで、データが空の時だけ初期データを投入する、という方法にしてもらう。
返答
1-2 問題なし
3 HTTPリクエストヘッダーのX-Forwarded-ForにIPアドレスがなかっただろうか?
4 問題なし
5 代替策として、Schedule=When PublishedのTimerで、中身が空の時だけ初期データを投入する方法にしよう
「3について確認しました。ODCではHTTPリクエストヘッダーへのアクセスに外部ライブラリが必要なため、標準機能の範囲では取得が難しい状況です。」
みたいなことを言ってきたので、HTTP/Request_GetHeaderで取得できるはずと書いたら「ご指摘の通りです。HTTP_GetRequestHeader を使えば X-Forwarded-For ヘッダーからIPアドレスを取得できます。監査ログにIPアドレス/クライアント情報も含める形で進めます。」
ということなので、あとは提示された計画を承認して進める。
変更結果を確認
全体をもれなく書くと大変なので、ざっくりみていって気になったポイントを列挙する。
権限管理
仕様に書かれていたRoleの説明文はDescriptionに入っている。

Entity
マスタ管理で指定されていた
勘定科目マスタ(Account)・部門マスタ (Department) ・ユーザーマスタ (UserProfile2、仕様とは名前が違うが、これは(System)に元からあるUser Entityとの名前衝突のため)
トランザクション機能の経費申請 & 承認フローで指定されていた
申請データのヘッダ(ExpenseReport)・明細 (ExposeReportItem) ・ステータスを管理するStatic Entity(ExpenseStatus)
監査ログを格納する
AuditLog
が作成されている。
マスタ管理にはCRUDという指定があるが、ちゃんと実装しきれていない
AccountMasterという画面がAccount Entityを一覧表示している。
しかしこの画面は単純にTableに一覧表示しているだけで詳細画面へのリンクがない。
このEntityについて、CRUDラッパーとなるActionはあるのに、呼ぶ画面がない。
というよりも、マスタEntityのラッパーはあるのにCUDの更新計処理が軒並み呼ばれていない。
これだと、作成は完全とは言えないな。
と思ってMentorの回答をみていたら、最後の注意事項に以下のようにあった。なぜこれで完了と判断してしまうのか……。
マスタ管理画面のインライン編集(保存・削除ボタン)は画面上に配置されていますが、CRUDアクションとの接続はODC Studio上で完成させてください。
経費申請 & 承認フロー ちゃんと実装されていない
すると、申請日だけ入力するフォームが出てくるので(申請項目はヘッダと明細合わせて結構あるのでこの時点で仕様を満たしていない)、申請日を選択して「提出」ボタンをクリック。

すると、エラーになる(There was a problem. Please contact the administratorという一般的すぎるメッセージ。実用を考えると望ましくない)。
申請日しか入力していないのでそれはそうだろう、という感じだが、実装をみると、「新規申請」で遷移してきた(画面パラメーターのEntity Identifier項目にはNullIdentifier()が指定されている)にも関わらず、そのIdでEntityを検索し結果がヒットすることを前提としたロジックになっている。
ここまでみてくると枠を不完全に作り、背景ロジックも意味をなしているとは言い難い。
恐らく最近の賢いモデルを使っているはずなのにこれで完了と判断するというのは、不思議ではある。
監査ログ
監査ログ格納用Entity・出力Action・一覧画面はある。
ただ、ここでも詳細画面がない。
それから、これはある更新処理時の出力Action呼び出し時のパラメータ。BeforeData・AfterDataには、仕様によると「操作前データ(JSON), 操作後データ(JSON)」を渡す。ので仕様を満たしていない。
初期データ投入Timer
Timerそのものはあったが、DepartmentとAccountをそれぞれ2件だけ登録している。
いかにも少ないが、これは初期データでやりたいことを明示していなかったせいもあるかもしれない。といいつつも、投入するように仕様に書いてあったのに投入されていないEntityがあるのでやはり駄目かな。
Menu
追加された画面はMenuに追加されていなかった。
サンプル画面
Key takeaways
- 概ね実装でき、ODCで対応できること、できないことを判断してユーザーに確認することはできる
- 可能な部分については結構早く実装できた
- 自分(ODC)の機能についても知らないことがある(例えば上でIP取得について出てきたHTTP/Request_GetHeaderを使うことを思いつかなかったり)
- 恐らくForgeコンポーネントの知識はなさそう(BDDFrameworkやUltimatePDFが、テストや帳票出力の話題の中で出てこなかったので)
- 機能には実装不十分な部分が結構ある
まあ、大枠はできているので、ここに自分で肉付けしていくつもりであればつかうことはできそう。





