はじめに
OutSystems 11(O11)の開発ツール Service Studio が、MCP(Model Context Protocol)サーバーを内蔵するようになりました。AIエージェントが、Service Studio で開いているアプリのモデル(画面、ウィジェット、Server Action、エンティティなど)を直接読めるようになったということです。
そこで、O11 の MCP と mabl の MCP を Claude Code から組み合わせて、OutSystems アプリの E2E テストを作る・回す・直すところまでを、AIエージェントにどこまで任せられるかを試してみました。
このシリーズでは、その結果を6回に分けて紹介します。第1回の今回は、手を動かす前に押さえておきたい「考え方」と全体の構成をまとめます。
| 回 | 内容 |
|---|---|
| 1. 概要編(この記事) | なぜ独立した検証が必要か、考え方の核、全体の構成 |
| 2. 環境構築編 | Service Studio の MCP と mabl MCP を Claude Code につなぐ |
| 3. 仕様とモデルの突き合わせ編 | AIに仕様と実装の食い違いを見つけさせる |
| 4. テスト作成・実行編 | 仕様どおりの期待値で mabl のテストを作る |
| 5. 修正ループ編 | AIが直し、人が Compare and Merge で取り込む |
| 6. メンテナンス編 | 同期コマンドとバージョン管理で回し続ける |
なぜ今、独立した検証なのか
変更の量と速さが増えた
ローコードの開発は、もともと変更が速いのが特徴です。そこに AIエージェントが加わり、Service Studio のモデルの変更まで提案できるようになりました。
一方で、テストの作成と保守は、変更が増えるほど追いつかなくなります。開発の速さに検証が追いつかない状態が、今回の出発点です。
実装から作ったテストは、不具合を見逃す
では、テストも AI に作らせればよいかというと、ここに落とし穴があります。
AIに実装(O11のロジック)を読ませて「このロジックが通るテスト」を作らせると、実装に入っている不具合まで「正しい動き」としてテストに固定されてしまいます。
たとえば、業務ルールが「50,000円以上の申請には説明が必要」なのに、実装の条件が Amount > 50000（50,000円ちょうどは対象外）になっていたとします。
実装を答えにしたテストは「50,000円・説明なしでも申請できる」ことを確認して合格し、不具合を見逃します。仕様を答えにしたテストは「50,000円・説明なしはエラー」を確認して失敗し、不具合を検出します。
コードを書いた側が、自分の仕事を公平に確かめることはできません。英語では "the author cannot be the verifier" と言われる原則です。AIエージェントに開発を任せるほど、作った側とは独立した検証が必要になります。
考え方の核
今回の検証で、いちばん大事にした考え方は次の一文です。
操作の手がかりはモデルから、期待値は仕様から
O11 MCP で、エージェントはアプリの構造を理解できる
Service Studio の MCP からは、次のような情報が取れます。人が画面を見て手順を書き起こさなくても、エージェントがアプリの構造を理解できます。
| 取れる情報 | テストでの使い道 |
|---|---|
| 画面と URL | 開く画面と順番 |
| ウィジェットの名前 | 壊れにくい要素の特定 |
| ロール | テストに使うユーザー |
| エンティティ、静的エンティティ | 有効なテストデータ |
| Description | 各要素の意図 |
ウィジェットに Input_Title(タイトル入力) や Button_Approve(承認ボタン) のような意味のある名前を付けておくことが、そのままテストの安定につながります。
ただし、何が正しいかはモデルには書いていない
モデルが教えてくれるのは「どう操作するか」です。「どうなるべきか」は教えてくれません。それを決めるのは、実装とは別に書かれた仕様です。
正本として使える文書には、たとえば次のようなものがあります。
- 業務の文書：要件定義書、業務規程(経費精算規程など)、業務マニュアル、受け入れ基準
- テストの文書：人が期待結果を書いた既存のテスト仕様書、テスト結果報告書に記録された過去の不具合
テスト結果報告書を使う場合は注意が必要です。そこに記録されている「合格したときの動き」は、その時点の実装の動きにすぎません。使うのは期待結果と過去の不具合(回帰テストの観点)だけにしないと、実装を正解にするのと同じ落とし穴にはまります。
ロジックは観点の地図、答えではない
では、モデルのロジックを読むことは無意味かというと、そうではありません。分岐の条件を見れば、「50,000円の境界を確かめる」のような、テストすべき観点が見つかります。
ロジックは「どこを確かめるべきか」を教えてくれる地図として使い、「何が正しいか」の答えには使わない。これが今回の線引きです。
Description は実装のそばにある仕様
O11 の各要素には Description を書けます。エージェントにとっては、画面や処理の意図を知るための大事な手がかりです。
ただし、Description は実装した人が書くので、実装と同じ思い込みが入ることがあります。また、仕様を直しても Description だけが古いまま残ることもあります。実際、今回のデモ検証では(自分で開発、検証していても)「Description には書かれているのに、ロジックにはそのチェックがない」という食い違いがありました(第3回で紹介します)。
Description は参考にしつつ、正本はあくまで実装とは別の文書に置く、という扱いにしています。
全体の構成
今回の構成は、次の4つの部品からなります。
| 部品 | 役割 |
|---|---|
| Service Studio（O11 MCP） | 手元のPCで動き、アプリのモデルをエージェントに公開する |
| mabl（mabl MCP） | クラウドで動き、テストの作成・実行・失敗の分析をエージェントから扱えるようにする |
| Claude Code | 2つの MCP をつなぎ、仕様とモデルを読んで作業を進める（GitHub Copilot や Cursor など、MCP に対応した他のエージェントでも同じ構成を組めます） |
| Git リポジトリ | 仕様（業務ルール）、mabl の ID の対応表、プロンプト、結果の要約を置く。人と AI の共通の土台 |
O11 の書き込み（モデルの変更）は、Service Studio の設定で「Compare and Merge で人が確認してから取り込む」を選びました。AIが変更を提案しても、取り込むかどうかは人が決める形です。なお、書き込みの機能は執筆時点では Beta です。
題材と、4つのステップ
題材には、申請者が経費を申請し、承認者が承認または差し戻す「経費申請アプリ」を O11 で作りました。画面からは見えない業務ルールが15項目あり、そのうち2つに、よくある種類の不具合(境界値の勘違いと、権限の確認漏れ)をわざと入れてあります。
このアプリを使って、次の4つのステップを試しました。
| ステップ | やること | 記事 |
|---|---|---|
| 1. 突き合わせ | O11 のモデルを読み、仕様と実装の食い違いを見つける | 第3回 |
| 2. 作成と実行 | 仕様どおりの期待値で mabl のテストを作り、実行して不具合を検出する | 第4回 |
| 3. 修正ループ | AIが原因を特定して直し、人が Compare and Merge で取り込み、再検証する | 第5回 |
| 4. メンテナンス | リポジトリとモデル、mabl を同期し、回し続ける | 第6回 |
結果を少しだけ先に書くと、仕込んだ2つの不具合はステップ1の突き合わせで両方とも見つかり、ステップ2の mabl のテストでも仕様との食い違いとして検出されました。その後、AIの修正を人が確認して取り込み、テストがすべて合格するところまで、その日のうちに回すことができました。ただし、これは小さなデモアプリでの結果です。
役割分担のまとめ
最後に、今回の構成での役割分担をまとめておきます。
| 担い手 | 役割 |
|---|---|
| 人 | 仕様を決める。AIの変更を取り込むかを判断する |
| AIエージェント | モデルと仕様を読む。ツールをつなぐ。テストと修正を提案する |
| mabl | コードを書いた側とは独立して、仕様どおりに動くかを検証する |
AIに任せられる部分は大きいのですが、「何が正しいか」を決めるのは仕様と人で、最後に確かめるのは作った側とは独立した仕組み、というのが今回のいちばんの学びでした。
次回は、Service Studio の MCP と mabl MCP を Claude Code につなぐ環境構築を紹介します。
この記事は個人の検証結果をまとめたものです。所属する組織の公式な見解ではありません。mabl に関する記述は、公開されている製品情報とドキュメントにもとづいています。