PMがAI x ローコードツール（Retool）で業務システムを作ってみた

published

author

authorDisplayName

Riho Konishi

⚡️ AI全盛期、PMでも本当に ”開発” できるのか?

プロダクト開発に携わる方であれば「バイブコーディング（Vibe Coding）」というワードを1度は耳にした1年だったのではないでしょうか。

コーディングまではしないにしても、ノーコード・ローコードツールも増えてきており、さらに生成AIが搭載されるなどの進化も遂げている昨今、”誰でも開発できる環境” が整ってきていると感じます。

一方で、日々エンジニアと一緒に仕事する私の目線からみると「本当に誰でも開発できるのか‥？」と疑問に感じることも正直あります。

そんな中、ちょうどエンジニア不在、PMだけで業務システムを作る機会ができた為、論より証拠ということでAI搭載のローコードツール「Retool」を使って開発にトライしてみました。

Retool | Build internal software better, with AI.

Build, deploy, and manage internal tools with Retool’s unified engine. Connect to any database, API, or LLM. Leverage AI throughout your business.

https://retool.com/

Retool | Build internal software better, with AI.

しかしながら、途中まで読んでがっかりする方が出ないよう先に結論から述べると、

エンジニアリング知識がないに等しいPMが、中長期的に運用される業務システムを2ヶ月強で作りあげるのは難しい側面も多く、結果的に今はPM 1名 + エンジニア 1名（+ レビュワー1名）という体制で開発を進めています。

とはいえ学びや気づきも多くあった為、この記事では、AI時代にPMが開発することの意義について、実体験をもとにリアルをまとめてみました📝

🍵 今回のトライの背景

前提：解決したい課題・目的

令和トラベルには、ハワイにALOHA7, Inc.という子会社があり、ホテルの在庫仕入や令和トラベル含めいくつかの代理店からのホテル・送迎予約手配といったランドオペレーター業務を行っています。

そこで、大きく以下2つの課題がありました。

令和トラベルとしてハワイ方面の予約創出をしていく為にも、現地メンバーはセールスやリレーション構築に時間を割きたいが、手配業務に忙殺されている

上場に向けガバナンス強化を行っていきたいが、紙などアナログな方法での情報管理もあり日本から統制しづらい状況にある

令和トラベル社内においては、業務システム（以下、トラベルマネジメントシステム）を1から内製し、創業当初から「旅行代理店の業務の完全自動化・ソフトウェア化」に注力してきました。

💡 くわしくは以下の記事をご覧ください

AIトランスフォーメーションで描く、旅行事業の未来 | 令和トラベル Engineering Blog

https://engineering.reiwatravel.co.jp/blog/Advent-Calendar-20250407

AIトランスフォーメーションで描く、旅行事業の未来 | 令和トラベル Engineering Blog

一方、ALOHA7社に関しては、外部のシステムベンダーが開発したオンプレミスの業務システムを長年利用しており、

各代理店からの手配依頼を元に手動で予約を登録

手動メールでホテルへ手配依頼

手配内容をPDFでエクスポート

PDFを印刷し、1予約ずつ紙でカスタマー管理

という、とてもアナログな方法で手配業務が行われていました。

そこで、業務システムを1からクラウド上に作り直すと同時に、業務の自動化も見据えた機能・オペレーション設計をすることになりました。

なぜPMが開発をすることになったのか

率直かつ端的にいうと、このプロジェクトが走り出した当初は、エンジニアでアサインできるメンバーがいなかったからです😇笑（スキルセットという意味ではなく、リソースが限定されていたという意味で。）

とはいえ、一般的に「エンジニアがいないなら、PMで作ろう！」となるかというと、多くのプロダクト開発の現場では「先に要件定義を進めて、とりあえず開発Readyの状態を作っておこう」となることがほとんどかと思います。

しかし、今回は「PMで作れる方法はないか？」という前提でツールの選定も行いました。

なぜPMで作るという方針に至ったのか。今回のゴールは「業務システムをリプレイスし、業務効率化を図る」という、一見すると大規模な開発になりそうなものでしたが、

行っている業務としては比較的シンプルかつ、トラベルマネジメントシステムとも通ずるところがある

そのトラベルマネジメントシステムのプロダクトマネジメントも担当してきた（ちょうど2年前に似たようなことを社内でやっていました、懐かしい）

現行システムにはない自動化の拡張はPhase2以降とし、まずは現行踏襲で基盤をクラウド上につくることをスコープにおく

という前提がありました。（厳密にいうと、スコープは後から決めた部分もありますが、システム開発の定石である ”MVPで作る” という大方針はあったので、業務オペレーション体制等も鑑み、Phase1は上記スコープとすることにしました。）

また、ハワイの現地メンバーに業務ヒアリングを行うことで、業務自体や作りたいもののイメージも私の脳内では固まってきており、PRDなどドキュメント作成に時間を割くより、手段さえ整えば作ってしまったほうが速そうという状況でした。

もちろんこの時も「開発のすべてをPMだけでやりきる」までは考えていませんでしたが、「複雑なシステムロジックなどを除き、原則はエンジニアなしに作れるとベター」と目論んでいました。

選ばれたのはRetoolでした

Retoolは、社内ツールや業務システムを素早く作るためのローコード開発プラットフォームです。最大の特徴は環境構築が不要で、GUIで直感的に開発を行えることです。

通常の開発では、自分のPCに開発環境を構築し、コードを書いて、サーバーにアップロードするなどのステップを踏む必要があります。

しかし、Retoolはブラウザでログインすれば即開発ができ、保存すればそのままリリースできます。

ボタン、テーブル、フォームなど、100種類以上のあらかじめ用意されたコンポーネントをドラッグ＆ドロップするだけでUI構築を進められ、CSSを書く必要もほぼありません。

「ローコード」なのでコードを全く書かないわけではなく、ロジックやデータソースとの接続部分について一部TypeScriptなどのコーディングが必要になりますが、AI機能も搭載されているため、こういった部分だけバイブコーディング的に開発することも可能です。

また、中長期的に運用していくシステムになるため、アクセス権限管理や監査ログ、バージョン管理なども整っている必要がありましたが、その点についても基準を満たす機能が揃っていたため、Retoolを採用しました。

🗺️ 検討〜開発をどう進めたか？

実際のプロセス

「PMで開発する」と決めたものの、Retoolはあくまで手段でしかありません。したがって「何を作るのか」の定義はいつも通り必要になるため、以下のステップで進めていきました。

☝

誤解のないよう補足をすると、PM自身で作るとはいえ、オペレーションや現行仕様の可視化は、「使われないもの」を作らず、最小単位を見定めるためにも一定の整理は必要不可欠と考えています。

現行業務フローの把握と今後の業務フローの見通しを立てる

誰が、何を、どの順番で行っているか

どこに課題があるか（工数、オペミス率など）

今後の業務フローの大まかなイメージと、自動化できそうなポイントを見据える

現行業務フロー（Cursorを使ってdraw.ioで書くことで効率化しています）

現行システム仕様の把握

今使っているシステムの構造、画面、機能

ユーザーの実際の使い方（意外と使われていない機能もあるため、重要なポイント）

現行の画面：オンプレのため現地でしか画面が見れず、写真をとって画面遷移図になるようにmiroにぺたぺたしたもの

画面の洗い出しと機能定義

新システムで必要な画面

各画面で必要な項目・機能

現行システムのどの機能を残すか、削るか、変更するか

各画面の構築・テーブル定義

具体的な項目や機能を詰めつつ、テーブル定義をブラッシュアップ

今後の業務フローとの整合性確認

画面を作りながら、より良い業務フローがあれば見直す

本当にこの機能で十分か考えながら作る

普段の開発プロセスと異なる点

Step1〜3は、通常のプロダクト開発と大きな違いはありません。異なるのはStep4以降です。

普段は、PMが業務フローを元に要件定義を行い、画面のワイヤーフレーム程度まで作成した後に、エンジニアはデータ構造の設計・テーブル定義から入り、その後に画面設計・実装と進んでいくことが多いと思います。

一方、私はワイヤーフレームの作成まではできたとしても、テーブル設計に関するスキルセットを十分に持ち合わせていなかったため、

まずは必要な画面と項目、機能を洗い出し

その時点でわかっている項目でテーブルを作成し、データベースとつなぎ込みを行う

作ったり検討していく中で、必要に応じてテーブル定義をブラッシュアップしていく

という方法で進めました。

ただ、これでは全体を俯瞰したときに、この構造でよいのか??を確認するタイミングが遅れますし、何より普段やらないフローのため、検討と構築に時間がかかりました。

結果、ちょうどこのあたりを進めている間にバックエンドエンジニア1名にjoinしてもらえることが決まり、私は引き続きStep1〜3、Step5を各画面ごとに進めつつ、並行してエンジニアにはデータモデルの設計やStep4である画面構築を進めてもらうことにしました。

👀「PMでも開発できる」は嘘ではない

「動くもの」は一瞬でできる

Retoolを触り始めた当初は「AIでどこまでできるかを知る」という観点で、まず以下のあまりにも雑なプロンプトをRetoolに搭載されたAIチャットに投げてみました。すると、

わずか数分でそれらしいものができあがりました。

実際に動いている様子がこちら ↓

ステータス列のデザインなどは気になりますが笑、あの雑なプロンプトでここまで動くものを一瞬で作れるのは、平凡な表現ではありますが、驚きました。

UIだけじゃなくて裏側もいけるの‥？ということで、次はこんなプロンプトを送ってみたのですが、

データベースの構築もそれなりにできていそうでした。

ただし、最大の問題点は‥

この進め方の最大の問題点は、私自身がAIが書いたコードの正しさを判断できないことです。当たり前ですが、エラーが出なくても、正しく動いているとは限りません。

かといって、ここまで作り込まれたものを1からエンジニアにレビューしてもらうのも、かえって工数がかかるように思います。

また、コンテキストを適切に与えるのが難しいと感じました。

Retool AIはRetoolの仕様にはくわしいですが、旅行ドメインのエキスパートでもなければ、今回、構造を参考にしたい既存のトラベルマネジメントシステムのソースコードを参照できるわけでもありません。

PMとエンジニア間では「トラベルマネジメントシステムでいうあの構造と同じ」という会話が成立しますが、Retool AIとそのような対話を行うことは、初期構築の段階では難しいと感じました。

AIに全部やらせない

これはRetoolに限ったことでも、さらには開発でのAI活用に限ったことでもありませんが、AIには「やってほしいことを丸投げして1から全部やってもらう」よりも、自分の不明点を部分的に助けてくれるサポート役として使う方がコントロールしやすいと感じます。

そこで、先程のようにRetool AIに丸投げして作るのではなく、ある程度自分で作りつつ、わからないところは尋ねる形式で進めていくことにしました。

冒頭にも特徴として書いた通り、Retoolには豊富なコンポーネントが用意されているため、UIに関してはワイヤーフレームを作るよりも簡単に組み立てていくことができました。

一方、

テーブルデータの追加や更新

APIで受け取ったレスポンスのハンドリング

など、一定のコーディングが必要なものの、単一テーブルの更新など、シンプルな処理であれば以下のようにGUIベースで設定可能で、「こういうことがしたいのだけど、どのように設定したらよいか？」とRetool AIに尋ねて進めていきました。

なお、これもまたAIエージェントあるあるですが、「xxxしたい」だけ伝えるとそのまま実行し始めてしまい、やっていることがブラックボックスになったり、余計なことまで操作してしまうことがあります。

例えば、以下のようなプロンプトにしたところ、応答だけみると一見正しい実装をしてくれそうに見えますが、実際のアウトプットを見ると全然バリデーションメッセージではない、普通のコメントまで英語に書き換えていました😇

そのため、「xxxしたいので、やり方を提示して」と伝え、最初はある程度、やっていることの中身を自分でも理解しながら進め、同じことの繰り返しが発生したら、そこはAIに一括で作ってもらうという進め方が良さそうです。

また、RetoolのAIチャットだとスクリーンショットを貼って「ここ」を伝えることができないため、その場合はChatGPTやGeminiを使って操作方法を確認していました。

「正しく動く」を作るのはムズカシイ

少し話がそれてしまいましたが、結論、AIの力を借りれば、UIをそれらしく作ったり、モノが動くようにコードを書いてもらうことはできます。そういった意味ではPMが1人で開発することは可能になりました。

しかし、テーブル設計や中長期的なアーキテクチャは別です。

最初の設計が後々の保守性を決めるといっても過言ではなく、正規化すべきか、どこまで分けるべきか、パフォーマンスをどう考慮するか等、これらの判断は一朝一夕でできるものでは決してなく、エンジニアの知見が不可欠です。

「作れる・動く」と「設計できる・正しく動く」は全くの別物だと改めて実感しました。

🥋 PMだけで完結はできなかったけれども

技術的な限界を感じた一方で、新たな学びや、ローコードツールならではのコミュニケーションもありました。

開発サイクル & 修正スピードの高速化

「実際のプロセス」セクションで記載した検討ステップは踏んでいたものの、実態としては、PMが項目定義を詳細に行っていない段階でも、エンジニアには現行システムをもとにRetoolで構築を始めてもらうケースもありました。

そういった際、Retoolであれば開発しているものがブラウザ上で簡単かつリアルタイムに確認できる為、PMはその場で動くUIを触りながら詳細検討を進め、すぐにエンジニアへフィードバックを行うことができたり、

テキストレベルの修正など、内容によってはPM自身で直してしまったりと、かなりスピーディーにサイクルを回すことができました 🤝

（もちろん、開発体制が普段よりミニマムで機動力があることも高速化の要因の1つではあります。）

「見えなかった考慮ポイント」の多さを体感

PMが仕様書を書くとき、多くは「入力 / 更新 / 削除」といったアクションベースで、「こういう操作をしたら、こうなってこのように表示する」という機能を定義することが多いのではないかと思います。

しかし、いざ実装するときには、

変数名を決める

データベースのどのカラムに保存するか

空白だったら？既に登録済みだったら？

データベース接続エラーが起きたら？

更新に失敗したら何を表示する？

ログは残す？

など、考えることがたくさんあります。エンジニアはこうした点を考えながら作っているのだと、ごく一部ではありますが体験できました。

🤔 AI時代、PMが開発する意義とは？

「PMでも開発できる時代」は間違いなく来ていると感じます ⏳️

しかし、エンジニアリング知識のないPMが1人で業務システムを作り切るには、まだまだスキルセットが足りませんでした。中長期的に堅牢なシステムを作るのは、やはりプロフェッショナルの領域です。

ただ、PMが「AIやローコードを使ってまず自分で手を動かしてみる」ことの価値は、“1つの処理の中にこれだけの考慮事項がある”と身を以て知り、エンジニアが見ている景色の解像度が上がることにあると考えます。

そうすることで、Why（なぜそれをやるのか、どんな目的か）をエンジニアへ伝える重要性を改めて体感するとともに、Howの解像度があがり意思決定の質も高められるのではないでしょうか。

Retoolは現時点、本記事で紹介したような機能は無料版でも一定利用できるため、「社内システムを作りたいのだけど、リソースがなかなかなくて…」という場合には、ぜひ一度触ってみてください💡

また、この記事を読んでRetool触ってみたよ!! という方がいらっしゃいましたら、とっても喜ぶのでXでご一報ください🥺（Xはこちら）

📣 1月のイベント開催のお知らせ

令和トラベルでは、毎月技術的な知識や知見・成果を共有するLT会を毎月実施しています。発表テーマや令和トラベルに興味をお持ちいただいた方は、誰でも気軽に参加いただけます。

【1/28 開催！3社共催】モバイルアプリ開発 ✕ AI ー組織・技術課題と向き合い、AIと走る

2026年のスタートを切る1月の「NEWT Tech Talk」は、”モバイルアプリ開発 ✕ AI ー組織・技術課題と向き合い、AIと走る” というテーマで開催。

クラシル株式会社なぐもさん、株式会社ヤプリにゃふんたさんをゲストに、令和トラベルやぎにいの3名が登壇します。モバイルアプリ開発の現場で、AI活用に取り組む3社のエンジニアが、個人・チーム・技術課題それぞれの視点から、AIとどのように向き合い、どのように開発を前に進めてきたのか、具体の取り組みをシェアしながら語ります！

【3社共催】モバイルアプリ開発 ✕ AI ー組織・技術課題と向き合い、AIと走る (2026/01/28 19:30〜)

# 📍 イベント概要今回のNEWT Tech Talkは、"モバイルアプリ開発 x AI - 組織・技術課題と向き合い、AIとの走る"をテーマに開催します！ AIの進化が進む中で、モバイルアプリ開発の現場でも、AIとの付き合い方について話題にのぼることが増えてきています。本イベントでは、モバイルアプリ開発の現場でAI活用に取り組む3社のエンジニアが、個人・チーム・技術課題それぞれの視点から、AIとどのように向き合い、どのように開発を前に進めてきたのかを率直に共有します。抽象論だけでなく、実際の現場での工夫や失敗、学びを通して、モバイルアプリ開発におけるAIとの「現実的な走り方...