SAP Screen PersonasでIW29をモバイル化｜AI活用事例

公開日: 2026.10.16 あく抜き太郎

既存SAP WEB GUIを生かしてFiori UIへ

SAPの業務画面をモバイルに対応させる際、すべてを新しいFioriアプリとして作り直す必要はありません。既存のトランザクションと業務ロジックを残したまま、利用者が操作する画面だけをSAP Screen PersonasとSAPUI5で組み直すこともできます。

本記事で取り上げるのは、設備保全通知の一覧を表示するトランザクション「IW29」です。既存SAP WEB GUIの資産を生かし、検索・並べ替え・絞り込みに対応したモバイル向け画面へ組み直す過程を紹介します。あわせて、開発者を支援するAIエージェントと人との役割分担にも、公開できる範囲で触れます。

ポイントは、バックエンドの業務機能まで作り直すのではなく、「残す機能」と「変えるユーザー体験」を分けることです。

この記事で分かること

SAP Screen Personas、Flavor、Slipstream Engine、SAPUI5 Appletの関係
既存SAP WEB GUIのIW29をモバイル向けに再構成する全体像
GuiGridViewからJSONModel、sap.m.Tableまでのデータの流れ
レスポンシブ表示、検索、行選択を実装するコードの要点
AIエージェントに任せる範囲と、人が確認すべき技術的な観点
Applet開発工数の実績と、AI支援による短縮効果

既存SAP WEB GUIを生かすという考え方

IW29は、SAPの設備保全領域で通知を一覧表示するトランザクションです。PCの広い画面では多くの列を同時に確認できますが、スマートフォンやタブレットにそのまま同じ情報量とレイアウトを持ち込むと、横スクロールや細かなタップ操作が増えてしまいます。

既存SAP WEB GUIを生かすという考え方

そこで今回は、標準トランザクションを全面的に置き換えず、SAP Screen Personasで不要な要素を整理し、一覧部分をSAPUI5 Appletへ置き換えます。

通知データや既存の権限、IW29・IW53の業務処理はそのまま生かし、利用者が触れる一覧だけをモバイル向けに作り直す構成です。

対象	残すもの	変えるもの
SAPバックエンド	通知データ、標準トランザクション、業務ロジック	原則として変更しない
画面構成	業務に必要な項目と操作	不要項目の非表示、配置、情報の優先順位
通知一覧	通知番号、設備番号、日付、優先度など	レスポンシブ表示、検索、並べ替え、絞り込み
画面遷移	IW29からIW53へ進む業務の流れ	行のタップを起点とした操作へ単純化

モバイル対応で重要なことは、「既存画面を小さく表示する」のではなく「利用場面に必要な情報と操作へ再編集する」ことです。

Personas・Fiori UI・AIエージェントの役割

SAP Screen Personas、Fiori UI、AIエージェントを横並びの製品として比べると、それぞれの役割が見えにくくなります。今回は次のように切り分けます。

要素	主な役割	今回のIW29で担当すること
SAP Screen Personas	既存のクラシックアプリケーションへ変更レイヤーを重ねる	Flavorによる画面整理、Appletの配置、SAP画面との連携
Fiori UI	利用者中心の一貫したUXを設計するための基準	役割に必要な情報へ絞り、端末幅へ適応する一覧を設計
SAPUI5	Fiori UIを実装するJavaScript UIフレームワーク	sap.m.Table、検索、フィルター、状態表示を実装
AIエージェント	開発者の調査・実装・確認作業を支援する	開発を補助するが、要件判断と最終検証は人が担当

Fioriのデザイン原則には、Role-based、Adaptive、Simple、Coherent、Delightfulがあります。今回特に重要なのは、担当者の役割に必要な情報へ絞る「Role-based」、端末へ適応する「Adaptive」、操作を単純にする「Simple」です。

Personasは既存資産との接点、Fiori UIは目指す体験の基準、AIエージェントは作る人を支援する存在です。

最新のデジタルトランスフォーメーション技術とは？技術の一覧と成功事例を紹介

IW29モバイル対応の技術構成

出発点：現場から挙がったモバイル対応の要件

今回の取り組みの出発点は、設備保全の現場から挙がった「通知の一覧を現場で確認したい」という要件です。設備保全の担当者は工場内を移動しながら点検や修理にあたりますが、通知の確認はIW29を表示できる事務所のPCに戻って行う必要がありました。確認のたびに現場と事務所を往復する移動時間が発生し、対応の優先判断も後回しになりがちです。

要件を整理すると、次の3点に集約されました。

現場で持ち歩くタブレット・スマートフォンから、通知の一覧を確認したい
設備番号や優先度で素早く絞り込み、対応すべき通知を見つけたい
通知を選んだら、そのまま詳細（IW53）へ進みたい

一方で、通知データの管理、権限、IW29・IW53の業務処理そのものに不満はなく、変えたいのは「現場の端末で見たときの画面」だけです。ここまで整理できると、新しいFioriアプリをゼロから開発するのではなく、既存のIW29を生かして画面だけをモバイル向けに再構成する方針が現実的な選択肢になります。

採用した構成

技術面の出発点は、ブラウザで利用している既存SAP WEB GUIのIW29です。一方、SAPUI5 Appletを組み込んだモバイル画面は、SAP Screen PersonasのSlipstream Engineで描画します。Slipstream EngineとSAP GUI for HTML（WebGUI）は描画方式こそ異なりますが、どちらも既存のクラシックアプリケーションをブラウザから利用します。

技術上の整理：SAPUI5 AppletをSAP WEB GUIへ直接埋め込む構成ではありません。既存のIW29とバックエンド資産を引き継ぎ、モバイル向けの実行画面をSlipstream EngineとSAPUI5 Appletで構成します。

データ表示までの流れ

1. IW29 通知データを取得し、元のGuiGridViewへ表示

→

2. Personasスクリプトグリッドを読み取り、JavaScriptの配列へ変換

→

3. JSONModel NotificationCollectionへデータを設定

→

4. sap.m.Table バインディングにより一覧を自動描画

IW29の元の一覧はGuiGridViewです。Personasスクリプトがグリッドの行を読み取り、通知番号QMNUM、通知タイプQMART、通知日QMDAT、説明QMTXT、設備番号EQUNR、優先度PRIOKなどをJavaScriptオブジェクトへ変換します。

変換した配列をAppletのJSONModelへ設定すると、XML Viewに記述したデータバインディングが反応し、sap.m.Tableの行が生成されます。画面側で1行ずつDOMを組み立てるのではなく、モデルとViewの対応関係を宣言しておく構成です。

TIPS：データバインディングとは

データと画面部品の対応関係をあらかじめ定義する仕組みです。今回のコードでは、NotificationCollectionという通知データの配列を、テーブルのitemsへ結び付けています。PersonasスクリプトがJSONModelへデータを設定すると、その件数に応じてSAPUI5が表の行を自動的に生成・更新します。

items="{DATA>/NotificationCollection}"：配列の要素ごとに行を作る「集約バインディング」
title="{DATA>QMNUM}"：各行の通知番号を画面部品へ表示する「プロパティバインディング」

通知を選択してIW53へ進む流れ

1. 行をタップ selectionChangeが発火

→

2. Controller 選択行から通知番号を取得

→

3. SelectionService 外部向けに選択イベントを通知

→

4. Personasスクリプト通知番号を引き継ぎIW53へ遷移

Applet内部では、Controllerが選択された通知番号をEventBusへ発行し、SelectionServiceが外部リスナーへ転送します。Personasスクリプトはそのイベントを受け取り、選択された通知番号を保持したうえでIW53へ進みます。AppletとPersonasスクリプトを直接密結合させず、サービスを境界にするのがこの構成の特徴です。

SAPUI5 Appletの実装ポイント

ここからは、SAP公開サンプル「iw29-mobile-table」を基に実装を見ていきます。サンプルはApache License 2.0で公開されていますが、現在はアーカイブされているため、実案件へ適用する際は対象環境のSAPUI5バージョンとAPI仕様を確認してください。なお、本節のコードはAIエージェントの支援で作成したたたき台を、開発者がレビュー・修正したものです（AIとの役割分担は6章で説明します）。

sap.m.Tableへ通知データをバインドする

XML Viewでは、items集約をDATA>/NotificationCollectionへバインドします。配列に通知が100件入れば、行テンプレートから100行が生成されます。

📄 Table.view.xml

<mvc:View
  controllerName="iw29mobiletable.controller.Table"
  xmlns:mvc="sap.ui.core.mvc"
  xmlns="sap.m">

  <!-- DATAモデルの通知一覧をテーブルの行へバインドする -->
  <Table id="idNotificationsTable"
         mode="SingleSelectMaster"
         selectionChange="onSelect"
         items="{DATA>/NotificationCollection}">

    <headerToolbar>
      <Toolbar>
        <SearchField
          placeholder="設備番号で検索"
          search="onSearch" />
      </Toolbar>
    </headerToolbar>

    <columns>
      <Column>
        <Text text="通知" />
      </Column>
      <!-- 画面幅が狭い場合は、独立した列から行内表示へ切り替える -->
      <Column minScreenWidth="Tablet" demandPopin="true">
        <Text text="設備番号" />
      </Column>
      <Column minScreenWidth="Tablet" demandPopin="true">
        <Text text="優先度" />
      </Column>
    </columns>

    <items>
      <ColumnListItem>
        <cells>
          <ObjectIdentifier
            title="{DATA>QMNUM}"
            text="{DATA>QMART}" />
          <Text text="{DATA>EQUNR}" />
          <ObjectStatus
            text="{DATA>PRIOKX}"
            state="{
              path: 'DATA>PRIOK',
              formatter: 'iw29mobiletable.Formatter.priority'
            }" />
        </cells>
      </ColumnListItem>
    </items>
  </Table>
</mvc:View>

minScreenWidth="Tablet"とdemandPopin="true"を指定した列は、画面幅が狭くなると独立した列から行内のポップイン表示へ切り替わります。単に表全体を縮小するのではなく、狭い画面でもラベルと値の関係を保つための設定です。

モバイル対応では、すべての列を残すことより、現場で最初に判断したい項目を先頭へ置くことが重要です。

設備番号で一覧を検索する

検索処理では、テーブルとモデルを結ぶitemsバインディングへフィルターを適用します。次の例は、設備番号EQUNRに検索語を含む行だけを表示します。

📄 Table.controller.js

onSearch: function (oEvent) {
  // SearchFieldへ入力された検索語と、テーブルのバインディングを取得する
  var sQuery = oEvent.getParameter("query");
  var oBinding = this.byId("idNotificationsTable")
    .getBinding("items");

  // 検索語が空の場合は、既存の絞り込みを解除する
  if (!sQuery) {
    oBinding.filter([]);
    return;
  }

  // 設備番号（EQUNR）に検索語を含む通知だけを表示する
  oBinding.filter([
    new Filter(
      "EQUNR",
      FilterOperator.Contains,
      sQuery
    )
  ]);
}

この処理では元データを変更しません。モデル内の通知一覧はそのまま残し、Viewに表示する行だけを絞り込みます。説明文や通知番号も検索対象に含める場合は、複数のFilterをOR条件でまとめます。

選択された通知番号をイベントで渡す

行を選択したら、その行のバインディングコンテキストから通知番号を取得します。表示上のセル位置ではなく、モデル内の項目名で値を参照するのがポイントです。

TIPS：バインディングコンテキストとは

画面部品が、モデル内のどのデータを表示しているかを示す参照情報です。今回のテーブルでは、各行のバインディングコンテキストがNotificationCollection内の1件の通知データを指します。getBindingContext("DATA")で選択行のデータを取得し、getProperty("QMNUM")で通知番号を読み出しています。

この方法なら、表示列の順番を変えても通知番号の取得処理は変わりません。

📄 Table.controller.js

onSelect: function (oEvent) {
  // 選択された行のDATAモデルから通知番号を取得する
  var oItem = oEvent.getParameter("listItem");
  var oContext = oItem.getBindingContext("DATA");
  var sNotificationId = oContext.getProperty("QMNUM");

  // 通知番号をイベントとして発行し、外部のPersonasスクリプトへ渡す
  this._oEventBus.publish(
    "iw29mobiletable",
    "select",
    { id: sNotificationId }
  );
}

Controllerが発行するのは「この通知番号が選ばれた」というイベントだけです。IW53への遷移は外側の処理へ分けているため、Applet単体のテストや別画面での再利用がしやすくなります。

PersonasスクリプトからJSONModelへデータを渡す

Appletが初期化されると、Flavorに設定したonAppletComponentLoadイベントからPersonasスクリプトが実行されます。このスクリプトで元のGuiGridViewを読み取り、AppletのDATAモデルへ通知一覧を設定します。

📄 Personasスクリプト

// Flavorへ配置したSAPUI5 Appletのコンポーネントを取得する
var oApplet = session
  .findById("<AppletコントロールID>")
  .getComponent();

// 元のIW29グリッドを読み取り、通知データの配列へ変換する
var aNotifications = fnReadModelData();

// 変換した通知一覧をAppletのDATAモデルへ設定する
oApplet.getModel("DATA").setData({
  NotificationCollection: aNotifications
});

// Appletで選択された通知番号を、次の画面遷移で利用できるように保持する
oApplet.getService("SelectionService")
  .attachSelect(function (oEvent) {
    session.utils.put(
      "SELECTED_NOTIFICATION",
      oEvent.getParameter("id")
    );
  });

fnReadModelData()では、環境固有のコントロールIDからGuiGridViewを取得します。グリッドが仮想スクロールを使用している場合、画面上に見えている行だけでなく、firstVisibleRowを動かしながら全行を走査する必要があります。そのため、件数が多い場合は読み取り時間とメモリ使用量を測定し、取得件数の上限や検索条件を検討します。

コード掲載上の注意：コントロールID、トランザクション遷移、権限、システム固有の設定値は環境によって異なります。上記は構造を説明するための抜粋であり、そのまま本番へ配置する導入手順ではありません。

導入までの実装ステップ

SAPUI5 AppletのUIコードはPersonasのスクリプトエディタへ直接書かず、独立したSAPUI5コンポーネントとして開発します。実装からテストまでの流れを整理すると、次のようになります。

工程	実施内容	主な確認事項
1. 要件整理	IW29で残す項目、隠す項目、モバイルで必要な操作を決める	利用者、端末、件数、遷移先
2. Flavor設計	元のグリッドや不要なコントロールを整理し、Applet領域を確保する	画面サイズ別の配置
3. Applet開発	Component、Manifest、XML View、Controller、Serviceを実装する	SAPUI5バージョンとAPI互換性
4. デプロイ	SAPUI5 ABAP Repositoryへコンポーネントを配置する	名前空間、キャッシュ、移送
5. Allowlist登録	Personas管理画面で利用を許可するコンポーネントを登録する	信頼できるコードか、権限は適切か
6. Flavorへ配置	Appletを挿入し、コンテナサイズへ追従させる	Stretch設定、端末別レイアウト
7. データ・イベント連携	GuiGridViewからモデルへデータを渡し、選択イベントをIW53へつなぐ	初期化順序、再入場時のイベント重複
8. テスト	検索、ソート、フィルター、行選択、権限、性能を確認する	PC、タブレット、スマートフォン

画面が表示できた時点を完成とせず、初期化順序、イベントの解除、データ件数、権限、端末幅まで確認する必要があります。

開発AIエージェントをどう位置づけるか

sap-web-gui-to-fiori-ui-04

本記事で扱うのは、IW29の利用者が問い合わせに使うAIではありません。開発者の作業を支援するAIエージェントです。技術情報の整理やコードのたたき台、テスト観点の洗い出し、ドキュメントの下書きなど、開発のさまざまな場面で活用できます。

AIに任せる前に整えたこと

今回の開発でAI支援が機能したのは、実装を任せる前の「前段」を人が整えていたからです。AIへ最初に渡したのは、白紙の依頼ではなく、次の3点が決まった状態のタスクでした。

構成は人が決めておく：GuiGridViewからJSONModel、sap.m.Tableへ至るデータフローと、AppletとPersonasスクリプトの責務分割は、AIに任せる前に確定させました。AIが担当するのは「決まった構成の中の実装」です。
参照材料は人が選んでおく：拠り所とする公開サンプル（iw29-mobile-table）と、対象環境のSAPUI5バージョンを人が指定しました。AIに自由に情報源を探させると、環境に合わない実装が混入しやすくなります。
完成条件を先に定義しておく：レスポンシブ表示、設備番号での検索、行選択からのイベント発行という受け入れ観点を先に決め、AIの出力はこの観点で人が判定しました。

AI支援の質は、AIへの依頼の巧拙よりも、依頼の前に何を決めておくかで大きく変わります。

AIが支援する領域と、人が判断する領域

前段を整えたうえでも、SAP Screen PersonasとSAPUI5 Appletの実装には、対象システムのバージョン、コントロールID、権限、Flavorのライフサイクルなど、環境に依存する条件があります。AIが提示したコードが構文上正しくても、その環境で正しく動くとは限りません。

AIが支援できる領域	人が確認・判断する領域
公開情報や既存コードの整理	業務要件と実際の利用手順が一致しているか
実装案や修正候補の提示	対象SAPUI5・Personas環境での互換性
テスト観点や確認項目の列挙	実データを使った結果と回帰影響
説明文や技術資料の下書き	権限、セキュリティ、公開可能な情報の判定

AIが出したコードをそのまま採用せず、開発者が動作と影響範囲を確認してから取り込みます。

実データ、認証情報、接続先、非公開コードは、外部サービスへ入力する前に可否を確認します。必要に応じてデータを匿名化し、入力する情報も必要な範囲に絞ります。

Applet開発の時間とAI支援の効果

今回のIW29モバイル対応のうち、AI支援の効果を実測できたのはSAPUI5 Appletの開発工程です。公開サンプルの調査、API仕様の確認、XML View・Controller・Serviceの実装、レビュー後の修正までを含むこの工程に要した時間は、3時間でした。

同じ作業をAI支援なしで行う場合の想定工数は16時間（SAPUI5経験者による見積値）です。差は13時間、短縮率は約80％になります。

AI支援なしの想定工数（Applet開発） 16時間

AI支援ありの実績工数（Applet開発） 3時間

短縮効果 13時間／約80％

短縮率は、次の式で計算しています。

短縮率（％）＝（想定工数－実績工数）÷想定工数×100

短縮の主な要因は、AIそのものの速さではなく、6章で述べた前段の整理にあります。構成・参照材料・完成条件が決まっていたため、AIへの依頼とその確認を短いサイクルで回すことができ、開発者は判断とレビューに集中できました。

一方、Flavor設計、データ・イベント連携、実機テスト、Allowlist登録といった工程は、実環境での確認作業が中心のため、AI支援の有無で所要時間に大きな差はありませんでした。AI支援が効くのはコーディングが中心の工程であり、開発全体の短縮幅は、その工程が全体に占める割合によって決まります。

なお、この比較は担当者1名・Applet開発工程のみを対象とし、AI支援なし側は実測値ではなく見積値です。そのため「削減実績」ではなく「想定工数との差」として示しています。

実装・運用で注意したい点

SAPUI5とPersonasのバージョンを確認する

公開サンプルのAPIやプロジェクト構成が、現在のSAPUI5でも推奨されているとは限りません。対象環境の公式ドキュメントと照らし、非推奨API、ライブラリの読み込み方、Fragmentの生成方法を確認してから採用します。

GuiGridViewの全件走査を性能面から評価する

画面に表示されていない行まで仮想スクロールで読み取る方式は、件数に応じて処理時間が増えます。実データ量で待ち時間を測り、必要であれば検索条件による事前絞り込みや取得上限を設けます。

イベントの多重登録を防ぐ

同じAppletインスタンスでattachSelect()を繰り返すと、1回の選択でリスナーが複数回実行される可能性があります。画面へ戻ったときのライフサイクルを確認し、必要な箇所ではdetachSelect()でリスナーを解除します。

Allowlistと権限を「動かすための設定」だけにしない

Allowlistは、信頼するSAPUI5コンポーネントだけをFlavorへ挿入できるようにする仕組みです。登録時にはコードの出所、通信先、権限、更新手順を確認します。Personasを導入しても、SAP標準の権限制御は引き続き必要です。

モバイル実機で操作を確認する

ブラウザの幅を狭めただけの確認では、タップ領域、ソフトウェアキーボード、回線速度、縦横回転などを評価できません。PC、タブレット、スマートフォンの実機で、表示だけでなく一連の業務操作を確認します。

技術的に表示できることと、現場で安全かつ短時間に操作できることは別の評価です。

まとめ

既存SAP WEB GUIをモバイル向けに改善する場合、画面全体を作り直さなくても対応できます。SAP Screen Personasでクラシックアプリケーションを生かし、利用者が触れる一覧をSAPUI5 Appletで組み直す方法です。

IW29の例では、元のGuiGridViewから通知データを取り出し、JSONModelを介してsap.m.Tableへ表示します。検索やレスポンシブ表示はSAPUI5側へ、IW53への遷移はイベントとPersonasスクリプトへ分けることで、それぞれの責務を整理できます。

そして今回のプロジェクトで確かめられたのは、AIと人の分担のかたちです。AIはコーディングという開発工程に特化させ、人は要件の整理、構成の設計、参照材料の選定、そして動作・互換性・権限・セキュリティの検証に集中する。Applet開発が3時間で完了したのは、AIの性能だけでなく、この分担が機能した結果です。

AIに任せる工程と人が担う工程をあらかじめ切り分けておけば、AIの進化はそのまま開発スピードの向上につながり、品質と安全性は人の手に残ります。私たちは今後も、この分担を前提にSAP画面改善のプロジェクトを進めていきます。

最初から対象を広げず、利用頻度が高く、操作負担の大きい1画面を選びます。その画面で「残す業務機能」と「変えたいユーザー体験」を切り分けるところから始めてみてください。

よくある質問

Q1. SAP Screen PersonasとSAP Fioriアプリは何が違いますか？

A. SAP Screen Personasは、既存のクラシックアプリケーション（SAP GUIの画面）に変更レイヤーを重ね、項目の非表示や配置の変更、複数トランザクションの連続処理を行う仕組みです。Fioriアプリは、SAPUI5などで新たに開発する、Fioriのデザイン原則に沿ったアプリケーションです。本記事の事例では、Personasで既存のIW29を生かしつつ、一覧部分だけをSAPUI5 Appletで作り、両者を組み合わせています。

Q2. 既存のトランザクションを変更せずにモバイル対応できますか？

A. できます。本記事の構成では、通知データ、権限、IW29・IW53の業務処理はそのまま残し、利用者が操作する画面だけをモバイル向けに再構成しています。新しいFioriアプリをゼロから開発する場合に比べ、バックエンドへの影響を抑えられる点がメリットです。

Q3. SAP開発でAIエージェントに任せられるのはどの作業ですか？

A. 公開情報や既存コードの整理、実装案やコードのたたき台の作成、テスト観点の洗い出し、技術資料の下書きなどです。一方、業務要件との整合性、対象環境での互換性、実データでの動作確認、権限やセキュリティの判断は、人が担う必要があります。

Q4. AI支援でどのくらい開発工数を短縮できますか？

A. 本記事の事例では、SAPUI5 Appletの開発工程を、AI支援なしの想定16時間に対して3時間で完了しました（約80％の短縮）。ただし、Flavor設計や実機テストなど実環境での確認が中心の工程では、大きな差はありませんでした。開発全体の短縮幅は、コーディング中心の工程が全体に占める割合によって変わります。

Q5. AIエージェントに社内のSAP情報を入力しても問題ありませんか？

A. 実データ、認証情報、接続先、非公開コードは、外部サービスへ入力する前に可否を確認する必要があります。必要に応じてデータを匿名化し、入力する情報も必要な範囲に絞ってください。また、AIが出力したコードは構文上正しくても環境に合わない場合があるため、開発者が動作と影響範囲を確認してから取り込みます。

【本記事の執筆・監修体制について】

執筆：あく抜き太郎

リアルテックジャパン株式会社 AI企画開発担当

2000年からインターネット業界に従事。インフラ・ネットワークエンジニア、プロジェクトマネージャー、テクニカルディレクター、社内情報システム責任者などを歴任。現在はAIを活用したシステム開発や、ロボット・IoTのPoC・開発に取り組む。情報システムの構築・改善やセキュリティ強化にも精通している。

専門領域：AI活用システム開発／ロボット・IoT／情報システム・セキュリティ

監修：リアルテックジャパン株式会社 SAPソリューション事業

最終監修責任者：代表取締役社長松浦一哉

リアルテックのブログ一覧会社概要はこちら

SAP Screen PersonasでIW29をモバイル化｜AI活用事例

既存SAP WEB GUIを生かすという考え方

Personas・Fiori UI・AIエージェントの役割

IW29モバイル対応の技術構成

出発点：現場から挙がったモバイル対応の要件

採用した構成

データ表示までの流れ

通知を選択してIW53へ進む流れ

SAPUI5 Appletの実装ポイント

sap.m.Tableへ通知データをバインドする

設備番号で一覧を検索する

選択された通知番号をイベントで渡す

PersonasスクリプトからJSONModelへデータを渡す

導入までの実装ステップ

開発AIエージェントをどう位置づけるか

AIに任せる前に整えたこと

AIが支援する領域と、人が判断する領域

Applet開発の時間とAI支援の効果

実装・運用で注意したい点

SAPUI5とPersonasのバージョンを確認する

GuiGridViewの全件走査を性能面から評価する

イベントの多重登録を防ぐ

Allowlistと権限を「動かすための設定」だけにしない

モバイル実機で操作を確認する

まとめ

よくある質問

Q1. SAP Screen PersonasとSAP Fioriアプリは何が違いますか？

Q2. 既存のトランザクションを変更せずにモバイル対応できますか？

Q3. SAP開発でAIエージェントに任せられるのはどの作業ですか？

Q4. AI支援でどのくらい開発工数を短縮できますか？

Q5. AIエージェントに社内のSAP情報を入力しても問題ありませんか？

RELATED POST関連記事

RANKING人気資料ランキング

RECENT POST 最新記事

RANKING人気記事ランキング

TOPIC トピック一覧

SEARCHブログ内検索