RetoolがReactベースになった意味とは。AI時代の業務アプリ内製化を「作る」から「育てる」へ

生成AIを使えば、業務アプリの画面を短時間で作れるようになりました。自然言語で要件を伝えるだけで、検索画面や管理画面、申請フォームのたたき台が生成されます。

一方、企業における業務アプリ開発では、画面が動くだけでは十分ではありません。実際のデータに接続し、利用者を制限し、変更履歴を管理しながら、継続的に改善していく必要があります。

Retoolの新しいApp Builderでは、アプリのフロントエンドがReact、バックエンドがTypeScriptをベースとする構成に変わりました。AIへの指示を中心に開発できる点が注目されがちですが、内製化の観点では、一般的な開発技術を基盤に採用したことも重要な変化です。

これは単なる内部実装の変更ではありません。

AIが生成したアプリを、担当者だけが理解できる試作品で終わらせず、IT部門や開発者が確認、修正、運用できる業務システムへつなげやすくなるからです。Retoolでは、生成されたReactコードを確認し、必要に応じて直接編集できるようになっています。

Reactベースになると、何が変わるのか

Reactは、Webアプリケーションのユーザーインターフェースを構築する際に広く使われている技術です。

ただし、「Reactになったから高機能になった」という理解だけでは、この変更の意味を十分に捉えられません。企業の内製化にとって大きいのは、アプリの中身を、特定製品だけに閉じた表現ではなく、開発者やAIが扱いやすい一般的なコードとして確認できるようになったことです。

従来のローコード開発では、画面を素早く作れる一方、製品独自の設定やコンポーネント構造を理解する必要がありました。専門の開発者であっても、まずその製品固有の作法を学ばなければ、細かな調整やレビューができないことがあります。

Reactベースのアプリであれば、社内外のWebエンジニアが、すでに持っている知識を活用しやすくなります。AIもReactやTypeScriptのコードを大量に学習しているため、一般的なパターンに沿ったコードの生成や修正を行いやすくなります。

その結果、次のような流れを作りやすくなります。

• 現場担当者がAIとの対話でアプリの原型を作る

• IT部門や開発者がコードとデータ処理を確認する

• 必要な部分だけを直接修正する

• 権限やデータアクセスを設定して本番公開する

• 運用後も、業務の変化に合わせて改善する

つまり、ノーコードかスクラッチ開発かを選ぶのではなく、AIによる生成、視覚的な編集、コードによる調整を、同じ開発プロセスの中で使い分けられるようになります。

AIが生成したコードを「読める」ことの意味

AI開発では、短時間でコードを生成できること以上に、そのコードを後から理解できるかが重要です。

試作品の段階では、画面が期待どおりに動けば問題にならないこともあります。しかし、顧客情報や売上情報、在庫、契約、社内申請などを扱うようになると、どの操作によって、どのデータが読み書きされるのかを確認しなければなりません。

Retoolの新App Builderには、生成されたReactコードを確認、編集するためのCodeタブが用意されています。画面上の要素を選択すると、対応するコードの場所へ移動できるため、大量の生成コードから対象箇所を探す負担も抑えられます。

これは、AIへの指示だけで最後まで開発するための機能というより、AIと人間の間を行き来するための仕組みと考えられます。

例えば、一覧画面の構成や入力フォームの追加はAIに依頼し、複雑な表示条件や社内独自の操作性については開発者がコードを調整する、といった分担が可能です。

現場担当者がすべてのReactコードを理解する必要はありません。一方で、開発者が必要になった段階でコードを確認できることは、試作品を本番環境へ移行するうえで大きな違いになります。

業務アプリでは、画面よりもデータ処理が重要になる

業務アプリの品質を左右するのは、画面の見た目だけではありません。

「検索ボタンを押したときに、どのデータベースへ問い合わせるのか」「承認したときに、どのシステムを更新するのか」「利用者の所属によって、表示するデータをどう切り替えるのか」といった処理が重要です。

Retoolでは、データソースとやり取りする処理を関数として確認できるDataタブも用意されています。複雑な処理については、入力、条件分岐、データソースとの関係を視覚的なグラフで確認できます。

生成AIを使った開発では、画面は確認しやすい一方、その裏側で何が行われているかが見えにくくなりがちです。データ処理を画面とは別に整理して確認できれば、IT部門は次のような観点でレビューしやすくなります。

• 不要なデータまで取得していないか

• 更新処理の対象は正しいか

• エラーが発生した場合の動作は定義されているか

• 本番環境と検証環境が適切に分かれているか

• 利用者の権限に応じてデータを制御できているか

Reactベースになったことに加え、データ処理を確認できる構造があることで、AIが作ったアプリをブラックボックスのまま公開するリスクを下げられます。

Reactコードの確認やDataタブ、AIによる画面生成が実際にどのようにつながるのかは、画面を見ながら確認すると理解しやすくなります。

Retoolのデモをご希望の方は、GxPまでご相談ください。

デモ予約

IT部門と現場の役割分担はどう変わるか

日本企業の内製化では、「現場に自由に作ってもらうか」「IT部門が統制するか」という二者択一になりやすい傾向があります。

現場だけで進めれば、業務に合ったアプリを素早く作れます。しかし、同じようなアプリが複数作られたり、担当者の異動後に保守できなくなったりする可能性があります。

一方、すべてをIT部門が引き受けると、要望が集中し、小規模な改善まで対応できなくなります。

ReactベースのApp Builderは、この役割分担を少し変える可能性があります。

現場部門は、業務要件や画面イメージをAIに伝え、動く形で要望を具体化します。IT部門は、すべてをゼロから開発するのではなく、データ接続、権限、セキュリティ、コード品質、本番公開を確認します。

現場部門が担当しやすい領域

• 必要な画面や入力項目の整理

• 業務フローの説明

• 試作品の作成

• 実際の利用者による動作確認

• 改善要望の反映

IT部門が担当すべき領域

• 接続を許可するデータソースの管理

• 認証とアクセス権限の設計

• 本番環境への公開判断

• コードやデータ処理のレビュー

• 監査、変更管理、廃止ルールの整備

この分担であれば、現場のスピードを維持しながら、IT部門が企業全体の安全性を管理できます。

IT部門の役割は、すべてのアプリを自ら作ることから、各部門が安全に開発できる共通基盤を整えることへと移っていきます。

想定される5つの活用パターン

1．AIで作った試作品を、そのまま業務アプリへ近づける

営業部門が顧客管理画面の試作品を作ったものの、認証やデータベース接続を追加できず、検証で止まってしまうケースがあります。

新しいRetoolでは、Retool上で作ったアプリだけでなく、ReplitやLovable、ローカル環境などで作成したReactアプリを取り込み、Retoolで管理されているデータ接続や権限へ結び付ける構成が示されています。

これにより、試作品を見ながら同じものを作り直すのではなく、すでに作った成果を生かして本番運用へ近づける選択肢が生まれます。

2．Excelや業務資料から、アプリのたたき台を作る

業務改善の初期段階では、詳細な要件定義書が用意されているとは限りません。

実際には、Excelの管理表、既存システムのスクリーンショット、PDFの申請書、担当者が作った画面イメージなどが出発点になることが多いでしょう。

新しいApp Builderでは、スクリーンショット、PDF、デザインファイル、スプレッドシートなどを入力情報として利用できます。

例えば、Excelで管理している案件一覧を渡し、「営業担当者別に絞り込み、対応状況を更新できる画面を作る」と指示することで、要件を議論するための具体的なたたき台を作れます。

AIが完成品を自動的に作るというより、抽象的な会話を、操作できる画面へ早く変換する使い方です。

3．部門ごとに異なる業務画面を、共通基盤上で展開する

同じ顧客データを使っていても、営業部門、カスタマーサポート部門、管理部門では必要な画面が異なります。

すべての部門に同じ大規模システムを使わせると、画面が複雑になり、入力負担も増えます。一方、部門ごとに個別開発すると、権限やデータ接続の管理が分散します。

Retoolでは、認証、ロールベースのアクセス制御、データアクセスの方針を、個々のアプリコードとは分けて管理する考え方が採用されています。

共通の顧客データや認証基盤を使いながら、各部門の業務に合わせたReact画面を作ることで、個別最適と全体統制を両立しやすくなります。

4．既存のReact資産を社内業務へ活用する

すでに社内や開発会社でReactアプリを作っている企業では、そのコードをRetool上へ持ち込む使い方も考えられます。

例えば、検証用に作った管理画面や、特定部門向けの小規模なWebアプリがあるものの、認証やホスティング、権限管理の整備に時間がかかっているケースです。

既存コードを生かしながら、Retoolのデータ接続や運用管理へ寄せることができれば、アプリ本体を作り直さずに、企業利用に必要な要素を追加できる可能性があります。

5．長期間使う業務アプリを継続的に改善する

業務アプリは、公開した時点で完成するものではありません。

組織変更によって閲覧権限が変わり、業務ルールの改定によって入力項目が増え、接続先システムの変更によって処理を修正する必要が生じます。

ReactやTypeScriptを基盤としてコードを確認できれば、初期構築者とは別の開発者が保守へ参加しやすくなります。また、Retoolではバージョン管理、リリース管理、環境間の反映、アクセス変更、監視など、公開後の運用も一つの基盤で管理する方針が示されています。

AIによって初期開発が速くなるほど、企業では公開後のアプリが増えていきます。そのため、開発スピードと同じくらい、誰が管理し、どう変更し、いつ廃止するかが重要になります。

Reactになれば、すべてが自動的に解決するわけではない

Reactベースであることは、アプリの品質を自動的に保証するものではありません。

AIが生成したコードには、重複した処理や分かりにくい構造が含まれる可能性があります。業務要件が曖昧であれば、技術的に正しく動いても、実際の業務に合わないアプリが作られます。

本番運用では、少なくとも次の点を整理する必要があります。

• アプリの責任者は誰か

• 本番公開を誰が承認するか

• 接続してよいデータソースは何か

• 権限をどこで管理するか

• 変更時にどのようなテストを行うか

• 利用されなくなったアプリをどう廃止するか

重要なのは、AIで自由に作ることと、何の制約も設けないことを混同しないことです。

現場が自由に試せる領域と、本番データへ接続するための審査を分けることで、開発スピードと統制を両立しやすくなります。

内製化の対象が「開発」から「運用」へ広がる

これまでの内製化では、自社の担当者がアプリを作れるかどうかが中心的な論点でした。

AIによって開発の入り口が広がると、今後は別の能力が求められます。

作られたアプリを評価し、業務に合わせて改善し、権限やデータ接続を管理しながら、安全に使い続ける能力です。

Reactベースの新しいApp Builderは、非エンジニアだけでアプリを完成させるためのものではありません。現場担当者、IT部門、開発者、AIが、同じアプリを引き継ぎながら改善していくための基盤として捉える方が実態に近いでしょう。

AIで画面を作り、必要に応じてコードを確認し、共通のガバナンス基盤を通じて公開する。

この流れが定着すれば、内製化は「誰が開発するか」という議論から、「組織としてどのように業務アプリを育てるか」という段階へ進んでいきます。

ReactベースのApp Builderによって、AIでの生成、コード編集、データ接続、本番運用がどのようにつながるのかを、デモでご紹介しています。

自社の業務や開発体制に適用できるか確認したい方は、GxPへお問い合わせください。

お問い合わせ