ODC向けAI Mentor System あつまれOutSystems Developer!開発者超会議 Autumn 2024 OutSystems MVP 渡部 潤司 : https://qiita.com/jyunji_watanabe : https://twitter.com/JyunjiW : https://www.linkedin.com/in/watanabejyunji/ Qiita X LinkedIn 

本日の内容 1. AI Mentor Systemsとは 2. 使い方 3. 開発プロセスへの適用（案） 

1. AI Mentor Systemとは 

OutSystems版の静的 解析ツール 

静的解析ツールとは ● 動作させずに、プログラム自体を解析して、あらかじめ定めたルールに従って性質をチェックする ツールが静的解析ツール ● AIMSはOutSystemsが事前に定めたルールに従い、Publish済みのプログラムを定期的に チェックし、問題点をODC Portalに列挙してくれる 

AIでソフトウェア開発を支 援するMentorの一部で もある 

Mentor内での位置付け ● 今年（2024年）のONEで、Mentorが発表された [1] ● AIを使ってソフトウェア開発プロセスを支援するもの ● 以下の機能をまとめて表すブランド名になっている ○ 生成AIを使って自然言語のプロンプトや要求文書から完全なAppを生成する ○ IDE中でロジックを作成する際に、コンテキストにあった実装オプションの提案をする （OutSystems11ではCode Mentorと呼ばれていたもの） ○ AI Mentor Systemによる静的解析 ○ AI Agent Builderで外部のAIをOutSystems Appに組み込む 

補足:OutSystemsの生成AI機能 ● 2024/10/19 時点でEAP（Early Access Program）中（興味あるユーザー企業 等が申請して機能の確認等を行うフェーズ） ● ここまで発表されてきた内容からすると、自然言語のプロンプトや仕様記述から完全な App（Screen・Action・Entity・Roleまで備えた）を作成する機能 ● 特定のScreenだけ、Actionだけ、等を作成する機能は無さそう 

2. 使い方 

静的解析の頻度と対象 ● 12時間ごとに自動で評価が行われる ● 今の所、評価タイミングを変更するオプションはない ● 対象は、Developmentステージにある各アプリの最新バージョンで、前回のチェック時から変 更があったもの 

利用手順 1.事前準備（管理者の作業） ● ODC Portal > ANALYZE（カテゴリ） > Code Quality（メニュー）上で、AIMSを有 効にしておく [2] ● 割り当てられたOrganization RoleにAI Mentor Systems用の権限を持たせておく 

利用手順 2.指摘事項を確認（開発者・アーキテクトの作業） ● ODC Portal > ANALYZE > Code Qualityページを開く ● 担当するAppや担当者等で対象を絞り込んで、自分が対応すべき指摘事項を確認 1) フィルタ 2) 指摘されたパターンのリスト 3) 選択されたパターン別の指摘箇所リスト ● 指摘事項の種類をパターンと呼ぶ 

利用手順 2.指摘事項を確認（開発者・アーキテクトの作業） ● 前スライドの③の部分を拡大すると以下のイメージ ● どのAppのどの要素でその指摘が挙がっているかを確認できる（以下の①） 

利用手順 2.指摘事項を確認（開発者・アーキテクトの作業） ● 前スライドの①の部分をクリックすると、指摘の詳細ページ ● Activity: 発見からの履歴（Statu変更やコメント）どのAppのどの要 素に対する指摘か 指摘されたパターンを解消す る方法を説明するポップアッ プを表示する 

利用手順 3.指摘事項に対応（開発者・アーキテクトの作業） ● 指摘詳細画面の「How to resolve」ボタン、またはパターン名で検索して公式ドキュメントを 見て、指摘内容と推奨される対策を確認する [3] ● 右は「How to resolve」ボタンで表示される説明例 ○ Expose REST APIに認証を付けないと危険、というパターン ○ 推奨される対策は当然、認証を設定すること ● 推奨対応をしたら、12時間程度待って解決を確認する ● それ以外にも、Statusを変更する対応もできる ○ Dismissed:指摘を無視する ○ Snoozed:しばらく指摘を表示しない 

3. 開発プロセスへの適用（案） 

開発中は、毎朝、最初の 作業として指摘事項全て に対処するフローとしたい 

対処必須でないものも→事 前に、開発者が任意に Dismissedにできるものと確 認必要なものに分類して一 覧表等に、日本語の解説も つける 

理由 ● 日常的に対応:いざ対応しようとしたら指摘が多すぎるかもしれない ○ 例えば、バッチが多いシステムでAvoid long-running Timersの指摘が大量に溜まっていたら? この指摘に対応 するためには、Timerを再実行可能かつ一定時間毎にコミットして再実行するように再設計することになる。大量の Timerでこの指摘が出ていたら、設計・実装・テストに相当の時間がかかってしまう ● 毎朝対応:12時間に1回しか分析が行われないため ● そもそも、AIMSの指摘は基本的に対応していくのは、プログラムの品質を高めることに加えて、 自動で指摘されるようなポイントをレビューでチェックしなくて済むというメリットもある ● パターンについて、Organization毎に重み付けしたり、指摘しないことにしたり、といった機能 は少なくとも現段階ではない 

その他のコメント ● 現時点では、指摘のリストをファイルとしてエクスポートする機能や、API等は無さそう ● Architectureというカテゴリがあるが、今のところそのカテゴリのパターンは無さそう ● 一般の開発言語にある静的解析は、保存した瞬間やコミットの瞬間に実行できるが、 OutSystemsではそれができない 

以上 

参考資料 

1. ハウスソフトブログ. 「2024年のONEで発表されたMentorについて現時点 （2024/10/17）の情報をメモ」. https://blog.house-soft.info/archives/2247 2. OutSystems Document. 「How ODC Code quality works > Activating AIMS on your Organization」. https://success.outsystems.com/documentation/outsystems_developer_cl oud/monitoring_and_troubleshooting_apps/manage_technical_debt_in_o dc/how_odc_code_quality_works/#activating-aims-on-your-organization, （参照2024-10-19） 3. パターンについて、2024/10時点のドキュメントを追って簡単なコメントをつけたものをQiitaに 書いたので参考までに o https://qiita.com/jyunji_watanabe/items/340913e160e7e1f933c1 o https://qiita.com/jyunji_watanabe/items/2a3c5991d277887d9fa3