Mentorでできること・できないこと
OutSystemsではMentorによって、自然言語を使ったアプリケーションの生成や既存アプリケーションの調査・改修が可能になってきています。
一方で、昨今のClaude CodeやCodexなどを利用したAI駆動開発では、単に「コードをAIに書かせる」だけではなく、
- 要件や設計資料をAIに読み込ませる
- チケットをもとに改修する
- テストを実行する
- 失敗した場合は修正して再テストする
- 結果をドキュメントへ反映する
といった、開発プロセス全体をAIに支援させる方向へ進んでいます。
そこで今回は、現在のMentorで「できること・難しいこと」を整理し、今後予定されているMCPを含む外部AIエージェントとの連携によって、どこまでその制約が解消されそうかを比較してみます。
※ 外部AIエージェント連携については、執筆時点ではClaude Code、Cursor、OpenAI Codexなどへの対応が一般提供されていないため、公開情報と一般的なAIエージェントの機能をもとにした予想を含みます。
MentorとMCP＋外部AIの比較
| 観点 | Mentor | MCP＋外部AI | 補足 |
|---|---|---|---|
| OutSystemsアプリの新規生成 | ◎ | ◎想定 | 画面・Entity・Logicなど |
| 既存アプリの理解・修正 | ◎ | ◎想定 | Mentorの得意領域 |
| 複数レイヤーをまたぐ変更 | ◎ | ◎想定 | UI・Logic・Dataを横断 |
| OutSystems固有の構造・依存関係の理解 | ◎ | ◎想定 | OutSystems側の大きな強み |
| 外部ファイルを入力として利用 | △ | ◎想定 | Excel、CSV、Markdown、各種設計資料など |
| ファイルを成果物として出力 | △ | ◎想定 | Excel、CSV、JSON、Markdown、設計書など |
| テストデータの生成・投入 | △ | ◎想定 | 外部ツールとの組み合わせが必要 |
| 自動テストの実行 | △ | ◎想定 | PlaywrightやComputer Useなどとの連携 |
| テスト→修正→再テストの自動化 | × | ◎想定 | AI駆動開発で重要なポイント |
| Git・Issue管理との連携 | △ | ◎想定 | GitHub、Jira、Backlogなど |
| チャット・作業セッションの管理 | △ | ◎ | 外部AIではタスク単位の管理がしやすい |
| プロジェクト固有ルールの永続化 | △ | ◎ | Markdownなどで管理可能 |
| 複数ツールを横断した作業 | △ | ◎想定 | OutSystems＋Git＋ファイル＋テストなど |
| 利用するAIモデルの選択 | × | ◎ | 外部AI側でモデルを選択可能 |
| 開発プロセス全体の自動化 | △ | ◎想定 | 要件→実装→テスト→結果記録まで |
表だけを見ると、Mentorで可能なOutSystems上の操作については、外部AIエージェントからも将来的に多くが実行可能になると予想されます。
では、AI駆動開発という観点から見た場合、現在のMentorでは何が不足しているのでしょうか。
特に重要だと考えているポイントをいくつか取り上げます。
チャット履歴のセッション管理
AI駆動開発では、チャットのセッション管理は非常に重要だと考えています。
AIに毎回完璧なインプットを与えることは簡単ではありません。
開発を進める中で、
- なぜこの実装にしたのか
- どの方法を試して失敗したのか
- どこまで調査したのか
- 何が未解決なのか
といった情報が少しずつ蓄積されていきます。
過去のやり取りを引き継げれば、これらを毎回説明し直す必要がなくなり、AIへの指示精度と開発効率を高めることができます。
一方で、あえて過去の会話を引き継がないことが重要な場面もあります。
例えば、実装を行ったAIと同じコンテキストのままレビューを行うと、自分自身の実装を正当化する方向のバイアスがかかる可能性があります。
そのため、
実装セッション
↓
別セッションでレビュー
↓
指摘内容を実装セッションへ戻す
のように、目的ごとにセッションを分離できることには大きな意味があります。
MentorはOutSystemsアプリケーションそのものの現在状態を理解することには優れていますが、AIとの作業履歴そのものを開発資産として管理するという点では、一般的なAIコーディングツールと比較すると制約があります。
ファイルの入出力
AI駆動開発になっても、要件定義書や基本設計書といったドキュメントが不要になるとは限りません。
例えば、
要件定義書
↓
AIが内容を理解
↓
OutSystemsを改修
↓
テスト
↓
設計書も更新
という流れが実現できれば、ドキュメントと実装の乖離を小さくできます。
また、開発現場にはExcel、CSV、PDF、Markdownなど、さまざまな形式の資料が存在します。
こうした外部ファイルを自由にインプットとして利用できない場合、必要な情報を人間がMentorへ転記する作業が残ります。
出力についても同様です。
例えば、
- 調査結果をMarkdownへまとめる
- テスト結果をExcelへ出力する
- 設計書を実装内容に合わせて更新する
- 変更内容をレビュー資料としてまとめる
といった作業までAIに任せられると、人間が担当する作業範囲をさらに減らせます。
アプリケーションの変更だけでなく、その前後に存在するドキュメントまで扱えるかどうかは、AI駆動開発の効率に大きく影響すると考えています。
複数ツールを横断した作業
実際の開発では、OutSystemsだけを見て作業が完結するケースは多くありません。
例えば、
Jiraのチケットを確認
↓
SharePointの要件資料を確認
↓
OutSystemsを調査
↓
実装
↓
テスト
↓
Jiraのチケットを更新
というように、複数のシステムを横断して作業します。
今後AI駆動開発が普及すると、
「人間が各ツールから情報を集めてAIへ渡す」
のではなく、
「AI自身が必要なツールを参照して作業する」
ことが標準的になっていく可能性があります。
MCPをはじめとした外部ツール連携の大きな価値は、単にOutSystemsを外部AIから操作できることではなく、OutSystemsを開発プロセス全体の中の1つのツールとして扱えるようになることにあると考えています。
テスト駆動の自動ループを作りにくい
AI駆動開発で特に大きな効果が期待できるのが、実装とテストのループです。
理想的には、
要件を確認
↓
実装
↓
テストデータ作成
↓
テスト実行
↓
失敗
↓
原因調査
↓
修正
↓
再テスト
というサイクルをAI自身が繰り返せます。
人間が毎回、
「実装してください」
「次にテストしてください」
「エラーになったので直してください」
と指示する必要がなくなります。
現在のMentorはOutSystemsの実装・変更については強力ですが、テストデータの準備やブラウザ操作を含め、テスト結果をフィードバックとして自律的に修正を繰り返す仕組みをMentorだけで構築することは難しいと考えています。
外部AIエージェントからOutSystemsを操作できるようになれば、Playwrightなどのテストツールと組み合わせ、
実装 → テスト → 修正 → 再テスト
というループまで一つのAI駆動開発プロセスとして構築できる可能性があります。
プロジェクト固有ルールの永続化
実際の開発では、プロジェクトごとにさまざまなルールがあります。
例えば、
- Entityの命名規則
- 共通部品を優先して利用する
- 特定の処理をClient Actionへ記述しない
- Aggregateの取得件数に制限を設ける
- コメントの記述方法
- エラー処理の方針
などです。
AIに開発を任せる場合、これらを毎回プロンプトに記載するのは現実的ではありません。
Claude CodeやCodexなどでは、プロジェクト内のMarkdownファイルなどにルールを記載し、それを継続的なコンテキストとして利用できます。
プロジェクトルール
↓
要件
↓
実装
↓
レビュー
↓
ルール違反なら修正
という形を作れるため、AI駆動開発を継続するほど重要になる機能だと考えています。
MentorにもOutSystemsのアーキテクチャや依存関係を理解する仕組みがありますが、開発チーム独自のルールを自由な形で蓄積し、AI開発プロセス全体から継続参照するという点では、外部AIツールの方が柔軟性があります。
最新モデルを自由に選択できない
もう一つ無視できないのが、利用するAIモデルです。
生成AIは現在も非常に速い速度で進化しています。
数か月前まで難しかった作業が、新しいモデルではほぼ一度の指示で実行できるようになることも珍しくありません。
Mentorの場合、利用するモデルやAI基盤はOutSystems側によって提供されるため、開発者が用途に応じて自由に最新モデルを選択することはできません。
一方、外部AIエージェントを利用できれば、
- 実装能力を重視したモデル
- 高度な推論に強いモデル
- 高速・低コストなモデル
など、その時点で適切なモデルを選択できる可能性があります。
AIモデルの性能向上がそのまま開発効率へ影響する現在では、モデルを選択できること自体が開発環境の重要な要素になっていると考えています。
総括
AI駆動開発を単なる「AIによるコード生成」ではなく、開発プロセス全体として洗練していくのであれば、MCPなどによるOutSystemsと外部AIエージェントとの接続は非常に重要になりそうです。
特に、
要件・チケット
↓
AI
↙ ↓ ↘
資料 OutSystems Git
↓
テスト
↓
結果・設計書更新
のように、AIを中心として開発に必要なツールを横断できるようになると、現在人間が担当している「ツール間の橋渡し」を大幅に減らせる可能性があります。
ここまでMentorでは難しいことを多く挙げましたが、Mentorに使い道がないという意味ではありません。
むしろMentorには、OutSystemsと密接に統合されているからこその強みがあります。
現在のMentorでは、実際に改修を開始する前に、
- どのEntityを変更するのか
- どのServer Actionを変更するのか
- どのScreenを変更するのか
といった変更予定を確認し、必要な変更だけを選択して適用できます。
これは、AIにすべてを自由に変更させるのではなく、
「AIが何を変更しようとしているのかを人間が把握したうえで実行する」
というガバナンスの観点で非常に重要な仕組みです。
特に企業システムでは、単純な開発速度だけではなく、変更範囲を把握しながら安全に開発を進めることも求められます。
その意味では、
MentorはOutSystems内部を深く理解し、安全に変更することに強いAI
と見ることができます。
一方で、
MCP＋外部AIは、OutSystemsを含めた開発プロセス全体を扱うことに強い
という違いが出てくるのではないでしょうか。
また、外部のクラウドLLM製品やAIコーディングツールの利用許可が下りにくい現場では、外部AIからOutSystems開発環境へ接続すること自体が難しい可能性があります。
そのような環境でも、
- 細かな機能改修
- 複数機能を横断した調査
- 既存ロジックの理解
- リファクタリング
- 変更影響の確認
といった用途では、OutSystemsに統合されたMentorは引き続き頼もしい存在になるでしょう。
私自身、今後OutSystemsにおけるAI駆動開発がどこまで実現できるのか非常に興味があります。
今後もMentorやMCP、外部AIエージェントを実際に使いながら、OutSystemsにおけるAI駆動開発の現時点での最適解を検証していく予定です。
検証した内容については随時記事にしていきますので、引き続きよろしくお願いします。