OutSystems 11のMCPとmablで、AIエージェントにE2Eテストを任せる(5) 修正ループ編

はじめに

第4回(テスト作成・実行編)では、仕様どおりの期待値で mabl のテストを作り、3件中2件(R4 と A5)が不具合を検出して失敗するところまでを紹介しました。

第5回の今回は、その不具合を直します。AIエージェントに原因を特定させて O11 のモデルを修正させ、人が Compare and Merge で確認して取り込み、mabl のテストで再検証する、という修正のループです。

回	内容
1. 概要編	なぜ独立した検証が必要か、考え方の核、全体の構成
2. 環境構築編	Service Studio の MCP と mabl MCP を Claude Code につなぐ
3. 仕様とモデルの突き合わせ編	AIに仕様と実装の食い違いを見つけさせる
4. テスト作成・実行編	仕様どおりの期待値で mabl のテストを作る
5. 修正ループ編(この記事)	AIが直し、人が Compare and Merge で取り込む
6. メンテナンス編	同期コマンドとバージョン管理で回し続ける

O11 の MCP のうち、モデルを変更する書き込みの機能(applyModelApiCode や omlMerge など)は、執筆時点では Beta です。この記事の手順は、検証用の個人環境で試したものです。

修正の前に、戻れる場所を作っておく

AIにモデルを変更させる前に、まず今の状態に戻れるようにしておきます。今回は、Service Center で ExpenseApp の今のバージョンの番号を控え、OML と OAP をダウンロードしてリポジトリで管理しました。

修正がうまくいかなかったときや、デモの後で不具合の入った状態に戻したいときに、このバージョンを公開し直せば元に戻せます。詳しくは第6回で紹介します。

原因の特定と修正を依頼する

Claude Code には、次のように依頼しました。

テスト 003 と 004 が失敗している原因を、servicestudio MCP で O11 モデルを確認して特定し、
business-rules.md の R4 と A5 に合うように修正してください。

- 修正する前に、どの要素をどう変えるかを日本語で説明してください。
- 修正は Compare and Merge で私が確認します。Publish は私が行います。
- Publish の後で、テスト 003 と 004 を実行して、合格するか確認してください。

「修正する前に説明する」は、CLAUDE.md にもルールとして書いてあります。依頼文にも念のため入れています。

AIが原因を特定し、直す前に説明する

エージェントは、servicestudio MCP でモデルを読み、次のように説明してから変更を始めました。

	原因	変更内容
R4	ValidateExpenseRequest の If「説明必須チェック」の条件が Request.Amount > 50000 になっている	条件を Request.Amount >= 50000 に変える。ほかの条件やフローはそのまま
A5	ApproveRequest がロールとステータスしか確認しておらず、申請者本人かどうかを確認していない	ステータスの確認の後に If「本人申請チェック」を追加し、本人の申請なら BusinessRuleException「自分の申請は承認できません」を返す

注目したいのは、冒頭の一文です。エージェントは、承認待ち一覧の画面(承認ボタンの処理)が BusinessRuleException を受け取ってエラーメッセージを表示する作りになっていることをモデルから確かめ、「変更が要るのはサーバーアクションだけ」と判断しています。

画面とサーバーの両方を直す、といった過剰な変更をせず、必要最小限の変更にとどめてくれるのは、モデルを読めるからこそです。また、変更の前に説明があるので、人は次の Compare and Merge で「何を確認すればよいか」が分かった状態で差分を見られます。

取り込むかどうかは、人が Compare and Merge で決める

エージェントがモデルを変更すると、Service Studio の Compare and Merge の画面が開きます。第2回で、Write permissions を「Manual review changes in compare and merge」にしておいたためです。

Compare and Merge の画面は、Claude Code ではなく Service Studio の側に開きます。Claude Code の画面を見ているだけでは気づかず、エージェントは人の確認を待ち続けます。マージの段階に入ったら、Service Studio のウィンドウに切り替えて確認してください。

左の「Your changes」が Service Studio で開いている今のモデル、右の「The other version」がエージェントが変更したモデルです。要素ごとに、どちらの版を残すかを選べます。要素をダブルクリックすると、どこが違うのかを詳しく確かめられます。

必要な変更だけを選んで取り込む

一覧を見ると、変更したはずの Server Action 2つのほかに、エージェントが触っていないはずの画面(Menu、ApprovalQueue、MyRequests)にも差分が出ていました。

ダブルクリックして中身を見ると、違いはウィジェットの Width だけでした。モデルを書き出して読み込み直す過程で出る、動作に影響のない差分です。そこで、次のように選びました。

要素	選んだ側	理由
ApproveRequest、ValidateExpenseRequest	右(AIの変更)	今回の修正そのもの
(System)	右(AIの変更)	参照の更新
Menu、ApprovalQueue、MyRequests	左(今のモデル)	Width だけの差分なので、元のまま残す

AIの変更を丸ごと受け入れるのではなく、中身を見て必要なものだけを取り込む。人が確認する意味は、ここにあります。

次に同じ差分が出たときに迷わないよう、CLAUDE.md に「Width だけの差分が出た画面・ブロックは、元の側(Your changes)を選ぶようユーザーに案内する」と追記し、エージェントのほうから選び方を案内してもらうようにしています。

取り込んだ後は、いつもの Service Studio で確認できる

取り込んだ後の変更は、Service Studio でいつもどおりに確認できます。

修正は2か所だけです。普段の開発と同じ画面で AI の変更を見て判断できるので、ローコードの開発者にとっても違和感がありません。確認できたら、人が Publish します。

再検証する

Publish の後、Regression プランを再実行しました。

テスト	修正前	修正後(1回目)
002 下書き保存から申請	成功	成功
004 自分の申請は承認できない(A5)	失敗	成功(初めて合格)
003 50,000円ちょうどは説明が必須(R4)	失敗(手順8)	失敗(手順9.6)

A5 は修正で初めて合格しました。R4 も、肝心の手順8(50,000円・説明なしでエラーメッセージが出て、画面が移らない)は合格しています。ところが、003 は別の場所(手順9.6)で失敗しました。

アプリを直して初めて、テストの不具合が見つかる

エージェントの報告によると、手順9.6 は「該当する申請の行が1行だけ」であることを確かめるアサーションでした。このアサーションが要素を1つだけ探す設定のまま行数を数えようとしていて、mabl が実行できなかった、というテスト側の不具合です。

修正前の 003 は、手順8で不具合を検出して止まっていました。そのため、手順9以降は一度も実行されていなかったのです。アプリを直したことで、初めてテストの後半が動き、隠れていたテストの不具合が表に出ました。

エージェントは、次のように切り分けていました。

• 手順9.6 の直前の確認(金額「¥49,999」、ステータス「下書き」)は合格しているので、50,000円の申請は保存されていない
• 期待値の「1行」は仕様どおりなので変えず、行数を数えるアサーションとして作り直す

期待値には手を付けず、アサーションの作り方だけを直す。ここでも、CLAUDE.md と Agent instructions に書いた「期待値は仕様から」が守られています。直したテストを単体で合格させてから Regression プランを再実行し、3件すべて合格になりました。

	結果
修正前	成功1、失敗2(R4、A5 を検出)
アプリを修正	成功2、失敗1(003 の後半で、テスト側の不具合が見つかる)
テストを修正	成功3(期待値は変えずに直す)

不具合で途中で止まっていたテストは、後半の手順がまだ検証されていません。アプリを直した後の再実行で、テストの後半の不具合が見つかることがある、というのは、AI に任せるかどうかに関係なく、テストを運用するうえで覚えておきたい点です。

修正ループでつまずいたこと

つまずいたこと	対処
変更していない画面にも、Width だけの差分が出る	中身を確認し、元の側を選ぶ。CLAUDE.md に選び方を書いておく
Compare and Merge の画面が Service Studio の側に開いていることに気づかず、マージのツールが待ち時間切れになった	マージの段階では Service Studio に切り替えて確認する。待ち時間切れになっても再実行せず、Service Studio 側で取り込まれたかを確認する(CLAUDE.md にも書いておく)。第2回の MCP_TOOL_TIMEOUT を長めにしておくと、確認に時間がかかっても切れにくい
修正後の再実行で、テストの後半の不具合が見つかる	期待値は変えずにテストを直し、単体で合格させてからプランを再実行する

まとめ

担い手	この回でしたこと
AIエージェント	モデルを読んで原因を特定し、必要最小限の変更を説明してから適用した。テストの不具合も、期待値を変えずに切り分けた
人	Compare and Merge で差分を確認し、必要な変更だけを選んで取り込み、Publish した
mabl	仕様どおりの期待値で再検証し、修正の効果と、隠れていたテストの不具合を明らかにした

「AIが直し、人が決め、mabl が確かめる」という役割分担が、修正のループの中でもそのまま働きました。

次回は最終回です。リポジトリとモデル、mabl の設定を同期し続けるためのコマンドや、バージョン管理の方法など、この仕組みを回し続けるためのメンテナンスを紹介します。

この記事は個人の検証結果をまとめたものです。所属する組織の公式な見解ではありません。mabl に関する記述は、公開されている製品情報とドキュメントにもとづいています。