AI時代の迅速なフロントエンド開発

ウェブサイトの構成は整い、メニューにも必要な項目がそろっていますが、お問い合わせフォームの送信先はまだ決まっていません。6ページにわたる共通ヘッダーの更新が必要で、クライアントによる確認用のバージョンも誰かが用意しなければなりません。

こうした作業が、ウェブサイトをどれだけ早く公開できるかを左右します。魅力的なレイアウトを生成するツールは、初稿の作成に役立ちます。一方、優れた開発ワークフローがあれば、その後の変更を管理し、テストしやすくなります。

迅速なフロントエンド開発では、再利用可能なコンポーネントとインターフェースを活用し、 ビジュアル編集 を可能にするとともに、素早いフィードバックサイクルを実現して、開発時間を大幅に短縮します。ローコードツールを使えば、すべての要素を手作業で作成しなくても、ページを組み立てて動作を設定できるため、このアプローチが可能になります。

このガイドでは、さまざまなプロジェクトに適した8つのプラットフォームを比較したうえで、TeleportHQを使った実践的なワークフローを解説します。例として、サービス紹介サイトとデータに接続されたディレクトリを取り上げます。また、アプリケーション機能が必要になる場面や、機能を追加したときに何が変わるのか、公開前の無駄な作業を避ける方法も紹介します。

迅速なフロントエンド開発とは#

フロントエンドとは、ウェブサイトやアプリのうち、ユーザーが目にして操作する部分を指します。ページのレイアウト、メニュー、ボタンなど、あらゆる視覚的な要素が含まれます。ディレクトリを絞り込んだり、フォームに入力したり、アプリやウェブサイト内を移動したりするとき、ユーザーが操作しているのがフロントエンドです。

要件に合意したら、迅速な開発に取りかかり、インターフェースをテストして必要に応じて修正を重ねます。この段階では、たとえば簡単な余白の調整などを行う際に、ビジュアルエディターが大きな効果を発揮します。また、再利用可能なカードやコンポーネントを使えば、個別に管理していた多数のレイアウトを置き換えられ、作業をさらに効率化できます。

速度は、作業全体を通して評価する必要があります。ページの作成、動作の設定、レビューで見つかった問題の修正にかかる時間を記録しましょう。初稿が5分でできても、コンテンツの構成やモバイル表示が適切でなければ、その後に多くの作業が必要になる場合があります。

30のコースを提供する研修会社を考えてみましょう。最初に必要なのは、検索機能と問い合わせフォームを備えたコース一覧です。コースカードを1つずつ個別に作成すると、デザインを変更するたびに同じ作業が繰り返し発生します。コース情報と連携した共通カードを使えば、デザインは一度変更するだけで済み、コース情報はデータとして管理できます。

この例からは、迅速なウェブサイト開発と、より広範なアプリケーション開発の違いもわかります。公開ディレクトリは情報を提示します。一方、学習の進捗を保存する学習者ポータルには、アカウントとアクセスルールが必要です。どちらにもフロントエンドがありますが、後者のプロジェクトでは、動作やデータの所有権についてさらに検討する必要があります。

作りたいものに合わせてツールを選ぶ#

適切な開発ツールは、何を作るのか、どのようなリソースがあるのか、どの種類のインフラを運用しているのかによって異なります。ローコードプラットフォームは、さまざまな種類の作業に対応できるよう設計されています。デザイナー向けのウェブサイト構築ツールもあれば、開発者が既存のアプリにビジュアル編集機能を追加できるツールもあります。社内ツール向けのプラットフォームは、データ管理や日常業務の自動化といったタスクに重点を置いています。

この記事では、ほぼ同じ機能を提供しながら、ウェブ開発へのアプローチが異なるツールを比較します。いずれも迅速なウェブ開発を支援するツールですが、その方法はそれぞれ異なります。ここで紹介するおすすめは、測定された速度の順位ではなく、公開されている機能とプロジェクトとの適合性に基づいています。

1. ウェブサイトやウェブアプリにはTeleportHQ#

TeleportHQは、AIによる生成とビジュアルエディターを組み合わせ、ホスティングや公開のオプションも提供しているため、外部のホスティングプロバイダーに依存する必要がありません。AIアシスタントを使えば、簡単なプロンプトから始めて段階的に作り込んだり、テンプレートから始めたり、Figmaのデザインをインポートしたりできます。より複雑なプロジェクトでは、複雑なワークフローや、認証が必要なウェブサイトやアプリなど、幅広いものを作成できます。

サービス業のビジネスなら、まずサービス内容を説明し、問い合わせを受け付けるページから作成しましょう。生成されたコンテンツを実際のビジネスに合わせて調整し、フォームをテストします。ディレクトリを作成する場合は、まず掲載データを定義し、それを繰り返し使えるレイアウトに紐づけます。見た目が似ているプロジェクトでも、必要な準備は異なります。

早い段階で決めておくべき重要な点は、プロジェクトの種類です。対象となるウェブサイトは有料プランでコードをダウンロードできますが、ウェブアプリはTeleportHQのホスティング上で動作し、アプリケーション全体のコードとしてエクスポートすることはできません。 現在の製品概要 には利用できるプロジェクトの種類が記載されており、エクスポートの条件については、このガイドの後半で説明します。

ひとつのビジュアルワークフロー内でサイトを作成・保守したい場合は、TeleportHQを選びましょう。既存のソフトウェア製品を特定のリポジトリに維持する必要がある場合は、ビルダーを選ぶ前に、連携方法と所有権に関する要件を確認してください。

2. カスタムアプリケーションのインターフェースにはWeWeb#

WeWeb は、ビジュアルなインターフェース開発とワークフローに対応し、組み込みのデータ・API機能に加えて、外部バックエンドとの接続も可能です。現在のドキュメントではフルスタックビルダーとして説明されているため、フロントエンド専用ツールとする古い比較は不完全です。

評価に適したプロジェクトの例は、ユーザーがデータを閲覧して更新を送信できる顧客ポータルです。まずはひとつのデータ種別と、ひとつのユーザー操作の流れから始めましょう。インターフェースがどのようにデータを受け取り、ユーザーがアクセスできるデータをシステムがどのように判断するかを確認します。サンプルのグラフだけを使ったデモより、こうした詳細のほうが参考になります。

アプリケーションの動作がプロジェクトの中心となる場合は、WeWebを検討する価値があります。WeWebの よくある質問 では、エクスポートしたソースコードの変更と、ビジュアルプラットフォーム上での編集が別々に扱われることも説明されています。手作業でのコード変更とビジュアル編集を交互に行う予定がある場合は、導入を決める前に、そのワークフローを明確にしておきましょう。

3. 既存のReactプロジェクト向けPlasmic#

Plasmic を使うと、チームは既存のReactコンポーネントやデータソースを活用して、ビジュアルに構築できます。開発者がすでにアプリケーションを保守しており、他のメンバーにも同じ環境でインターフェースを組み立ててもらいたい場合に適しています。

価格カードやアカウント管理画面の使用が承認されているソフトウェア企業を想像してみてください。開発者がそれらのコンポーネントをビジュアル編集向けに準備すれば、デザイナーは確立された要素を使ってページを組み立てられます。得られる効果は、コンポーネントライブラリの品質と、そこで利用できる選択肢に左右されます。

既存のコードベースを維持することが必須要件であれば、Plasmicを試す価値があります。初期統合とコンポーネントの設定には時間を確保してください。コンポーネントの依存関係が不明瞭だったり、特定のページレイアウトを前提としていたりする場合、ビジュアルキャンバスではその問題を補えません。 開発者向けクイックスタート は、フレームワークへの統合を始める際に役立ちます。

4. ビジュアルコンテンツ制作フロー向けBuilder.io#

Builder.ioのビジュアルエディター を使うと、再利用可能なコンテンツやカスタムコンポーネントを組み合わせて、ページやセクションを作成できます。ドキュメントでは、レスポンシブプレビュー、共同作業、コンテンツテストについて解説されています。開発者が保守するサイトでマーケティングチームが頻繁に変更を加える必要がある場合に、こうした機能が役立ちます。

たとえば、開発者が承認済みのお客様の声セクションと料金ブロックを用意できます。キャンペーン担当者はそれらを配置し、変更を加えるたびに新しいページの実装を依頼することなく、許可されたコンテンツを編集できます。コンポーネントを公開する前に、編集者が操作できるプロパティを決めておきましょう。

Builder.ioにはコードを扱う機能もあるため、評価対象となる製品のワークフローを明確にしましょう。ビジュアルCMSの統合とコードの生成・変更では、レビューやデプロイに必要な手順が異なります。コンテンツ中心のプロジェクトでは、初期設定の完了後、編集者が日常的な更新をどれだけ速く行えるかを確認してください。

5. マーケティングサイトやCMSサイト向けWebflow#

WebflowのビジュアルCMS は、コンテンツ管理とビジュアルなページデザインを組み合わせています。記事の公開や、構造化された導入事例の管理を、ページレイアウトを一から作り直さずに行いたい編集者がいる企業サイトに適した選択肢です。

実際のコンテンツを使って試験プロジェクトを始めましょう。長いタイトルと複数のセクションを含む事例紹介を作成し、更新を担当する人に編集してもらいます。これにより、コンテンツモデルと編集体験がチームに適しているかどうかが分かります。洗練されたホームページだけでは、継続的な保守のしやすさはほとんど判断できません。

Webflowでは HTML、CSS、JavaScriptの埋め込みに対応していますが、サーバーサイド言語は実行できません。アプリケーションに必要な機能については、Webflowの機能や外部サービスを個別に確認してください。顧客向けダッシュボードは、ウェブサイトと同じデザインにする場合でも、別個の技術要件として扱いましょう。

6. Retool：社内業務アプリケーション#

Retool は、社内向け業務ツールの開発を目的としています。データベースやAPIに接続してクエリを実行し、アプリと連携するワークフローも利用できます。現在、アプリの作成方法は2種類あります。 新しいアプリビルダー はAIを中心とした方式です。チャットタブでアプリの内容を説明すると、コードタブで確認・編集できるReactのソースコードが生成されます。 従来型アプリ はドラッグ＆ドロップエディターで作成し、キャンバス上に組み込み済みのコンポーネントを配置します。Retoolのドキュメントでは、新しいビルダーのものを「アプリ」、旧方式のものを「従来型アプリ」と呼ぶようになっているため、チュートリアルがどちらを説明しているか確認してください。一部の機能は、どちらか一方でしか使えません。たとえばRetoolのMCP連携は新しいビルダーには対応していますが、従来型アプリには対応していません。Retool Mobileアプリは、引き続き従来型のドラッグ＆ドロップエディターで作成します。従来型アプリ向けのAIアシスタント「Assist」は、2026年9月30日に 従来型ビルダーでの提供を終了しました。既存の従来型アプリは引き続き完全に編集でき、Team、Business、Enterpriseプランでは新しいビルダーへの変換が無料だとRetoolは説明しています。

サポートチームが顧客情報を検索し、アカウントのステータスを修正する必要があるとします。その場合、洗練されたビジュアルよりも、分かりやすい操作方法と信頼できるデータ処理のほうが重要です。実際にその業務を担当する人にインターフェースを試してもらい、リクエストに失敗したときの挙動も確認しましょう。

Retoolは、主な利用者が社内システムへのアクセスを必要とする従業員である場合に最適です。書き込み操作を接続する前に、アクセス権限を設定してください。レコードを更新するボタンは、目的が明確で、結果も予測できるものでなければなりません。特に、そのレコードがほかのシステムにも反映される場合は重要です。

7. FlutterFlow Studio：モバイルアプリケーション#

FlutterFlow Studio は、Flutterアプリケーションをビジュアルに開発できるツールです。有料プランではカスタムコードを利用でき、Flutterプロジェクトをダウンロードできます。iOSとAndroidに加え、ウェブへのデプロイにも対応しています。

モバイルアプリケーションが主要な成果物である場合に検討しましょう。ユーザーがスマートフォンで日常的に使う顧客向けアプリは、一般公開するサービスサイトとは操作性や配布方法の要件が異なる場合があります。ユーザーが繰り返し行う必要のある操作を含め、実際のモバイル利用の流れを早い段階で評価してください。

技術選定は重要です。Flutterは、一般的なHTMLやReactのウェブサイトとは異なる実装方法を採用しています。カスタムコードを誰が保守するのか、ウェブ版をどのように動作させるのかを確認しましょう。主な成果物が検索流入を重視したマーケティングサイトである場合は、モバイルファーストの開発手法を選ぶ前に、ウェブサイト向けのビルダーと比較してください。

8. オープンソースの社内ツール向けAppsmith#

Appsmith を使うと、あらかじめ用意されたウィジェットでインターフェースを構築し、データベースやAPIに接続して、JavaScriptで独自のロジックを追加できます。コアプラットフォームは Apache 2.0ライセンスのもとでオープンソースとして公開されています。ユーザー数の上限がない無料のCommunityエディションを自社インフラで運用することも、 無料プランのユーザー数が5人に制限されているAppsmithのマネージドクラウドを利用することもできます。Git連携を使えばリポジトリでアプリをバージョン管理できますが、リポジトリの上限はプランによって異なります。

実用的な評価方法として、レコードを読み込み、限られた項目を更新する小規模な管理画面を作成してみましょう。実際の利用に近いデータを使い、管理者以外のアカウントで権限を確認します。画面のレイアウトにかかる時間だけでなく、クエリの保守にかかる労力も記録してください。

オープンソースやセルフホスティングを重視するなら、Appsmithは検討する価値があります。セルフホスティングにはライセンス料がかかりませんが、アップグレード、バックアップ、セキュリティパッチの適用はチームの責任になります。

ライセンス、Communityエディションのユーザー数無制限、クラウド無料プランのユーザー数上限（5人）、Gitリポジトリの制限に関する情報は、2026年6月から9月に公開された第三者のレビューや料金プランの比較記事に基づいています。Appsmithの公式料金ページでは確認できなかったため、プランの制限は頻繁に変わることを踏まえ、公開前に同ページを確認してください。この確認作業も選定時の考慮事項に含めましょう。Appsmithは、主に一般公開向けのマーケティングページを作るツールよりも、Retoolのような社内ツール構築プラットフォームに近い比較対象です。

訪問者の一連の行動を定義する#

サイトを生成する前に、訪問者に完了してほしいタスクを定義しましょう。研修会社の場合、最初の一連の行動は「適切な講座を見つけ、詳細を確認し、問い合わせを送る」といったものが考えられます。受講者用アカウントや決済機能をすぐに構築しなくても、この行動を軸に評価できます。

各項目について、簡潔な受け入れ基準を作成しましょう。講座一覧には最新の講座が表示されていること。各カードから正しい詳細ページに移動できること。チームが返信するのに十分な情報が問い合わせに含まれていること。こうすれば、サイトが完成したように感じるかではなく、具体的な動作を確認できます。

公開時に必要な要件と、将来的な要望を分けましょう。受講者用ポータルの構想はプロジェクト概要に含めても、一般公開用の講座一覧の公開を遅らせる必要はありません。一方、有料アクセスが公開時に必要なら、初期のアーキテクチャで対応できるようにする必要があります。必要なアカウントシステムを先送りすると、避けられるはずの再設計が発生します。

各ページについて、主な対象読者と次に取ってほしい行動を記録しましょう。一般的なサービスページなら、問い合わせへ誘導します。講座の詳細ページなら、その講座が自分に適しているか訪問者が判断できるようにします。こうした準備をしておけば、「モダンなウェブサイトを作って」という大まかな依頼よりも、AIとチームに的確な指示を与えられます。

ウェブサイトとウェブアプリのどちらを選ぶか#

TeleportHQでは、ウェブサイトプロジェクトとウェブアプリを明確に区別しています。通常のフォームや連携データを含むウェブサイトでも、ウェブアプリになるわけではありません。認証やワークフローなど、プラットフォーム上で動作するアプリケーション機能を追加すると、プロジェクトの種類が変わります。

この違いは、デプロイと今後のメンテナンスの両方に影響します。 コードのエクスポートに関するドキュメントによると、ウェブサイトをエクスポートするには、有料のProまたはPremiumワークスペースと適切な共同編集者の役割が必要です。ウェブアプリは、有料プランにかかわらずコードとしてダウンロードできません。

データベースへの接続を、完成したアプリケーションと同一視しないでください。ディレクトリサイトは、ユーザーアカウント機能がなくても、公開されている講座情報を読み込める場合があります。学習者向けポータルには、誰がどの情報にアクセスできるかを定めるルールが必要です。 データソースのガイド では、データソースを接続するだけではプロジェクトの性質は変わらないことが明確に説明されています。

ページ配信について詳しくは、 静的ウェブサイトと動的ウェブサイトをご覧ください。このアーキテクチャに関する説明と、プラットフォームの料金体系やプロジェクトの分類は分けて考えましょう。実際に重要なのは、個々のプロジェクトでどの機能を使うのか、またその機能に何が必要なのかという点です。

役立つ最初のバージョンを作成する#

具体的な brief に基づいてページを生成する#

TeleportHQ では、まず「+ New Project」を選び、「Presentation Website」を選択してから「Generate with AI」をクリックします。ビジネスの内容を説明し、必要なページを指定してください。設定ではデザインの好みも選べます。最新の手順は、 AIによるウェブサイト生成ガイド をご確認ください。

参考になる依頼文の例：

中小企業向けに専門的な研修を提供する会社のウェブサイトを作成してください。ホーム、コース、会社概要、お問い合わせのページを含めてください。主な目的は、コースについて問い合わせてもらうことです。コースの説明は分かりやすくし、デザインは控えめにしてください。ナビゲーションの構成は全ページで統一してください。事業の詳細が提供されていない箇所には、内容が分かるラベル付きのプレースホルダーを使用してください。

デザインを整える前に、内容が事実に即しているか確認してください。架空のコース説明は差し替え、根拠のない主張は削除します。提案されたナビゲーションが、実際に生成されたページと一致しているかも確認してください。キャンペーン資料へのリンクを設定し始める前に、ページの不足を修正しておくと簡単です。

ウェブアプリやストアの機能が合意した範囲に含まれる場合は、それに対応する開始方法を選んでください。 ウェブアプリの生成ガイド では、その方法を説明しています。初期バージョンに訪問者が必要とする機能を反映できるよう、必要な動作を具体的に記述してください。

既存のデザインをインポートする#

レイアウトがFigmaですでに承認されている場合は、そのデザインを出発点にしましょう。該当するフレームを選択し、TeleportHQプラグインを実行して、「新しいプロジェクトとしてエクスポート」を選びます。 Figmaインポートガイド では、オブジェクトを既存のプロジェクトにコピーする方法も説明しています。

インポートするデザインを事前に整えておきましょう。TeleportHQは、よりよいインポート結果を得るためにFigmaのオートレイアウトを推奨しています。インポート後は要素の構成を確認し、狭い画面幅でもテストしてください。デザインファイルは見た目の意図を伝えますが、実際に動作するサイトには、ナビゲーションの動作や各フォームの送信先も必要です。

デザイン全体を移す前に、代表的なセクションを一つインポートしましょう。長い見出しや繰り返し使うカードなどを含めておくと、難しい部分を早い段階で評価できます。 AIによるデザインからコードへの変換ガイド では、ビジュアルの参考資料を編集可能なウェブサイトのレイアウトに変換する方法をさらに詳しく解説しています。

連動して変更するパーツを再利用する#

繰り返し使う要素や、一貫性を保つ必要がある要素には、共通コンポーネントを作成しましょう。ナビゲーションやフッターがその代表例です。構成を保ちながら内容を変えるコースカードも、再利用に適しています。一度しか使わない編集記事のセクションは、通常の要素として管理したほうが簡単な場合があります。

TeleportHQでは、メインコンポーネントと、ページ上に配置するその複製であるインスタンスを区別します。メインコンポーネントを変更すると、そのインスタンスにも変更が反映されます。プロパティ（props）と呼ばれる編集可能な項目を使えば、各インスタンスに異なるコンテンツを設定できます。 コンポーネントガイド では、これらの関係と、インスタンスを切り離した場合の影響について説明しています。

コースカードをデザインするときは、レイアウトをいじり始める前に、まずコンテンツを整理しましょう。タイトルと概要の配置を決め、ボタンの文言とリンク先を確定します。また、実際の例を使ってカードを試してみましょう。2語のタイトルだけでは、8語に及ぶコース名にレイアウトが対応できるかどうかは分かりません。

ちょっとした見た目の調整のたびに、新しいコンポーネントを作るのは避けましょう。その違いは編集可能なプロパティで表現できるのか、それとも本当に別の構造が必要なのかを考えてみてください。ひと目で理解できる少数のコンポーネントを用意するほうが、よく似たコンポーネントを何十個も並べるより、次の編集者にとって扱いやすくなります。

再利用可能なテンプレートがUI制作を効率化するのも、すでに決めたデザイン上の判断を次のページに引き継げるからです。テンプレートの価値を決めるのは、選べる種類の多さではなく、適切な構造と期待どおりに動作する編集機能です。プロジェクト全体で使うと決める前に、自分のコンテンツで試してみましょう。

レイアウトを複製する前にデータを接続する#

レコードに明確な構造を持たせる#

コンテンツをレコードとして管理すると、ディレクトリの保守が容易になります。コースの例では、インターフェースにデータを紐づける前に、フィールド名を決めておきましょう。以下の表は、提案するコンテンツモデルであり、TeleportHQで必須のスキーマではありません。

デザインを完成させる前に、実際のデータを想定したレコードを用意してください。少なくとも、長い概要を含むレコードと、任意項目が欠けているレコードを用意します。それぞれをどのように表示するか決めておきましょう。すべてのサンプルに理想的な内容ばかりを使うと、通常の運用で生じる問題をレイアウトの確認時に見落としてしまいます。

TeleportHQは 独自のデータベース や、SQLデータベース、スプレッドシートなどの外部ソースに対応しています。チームが安定して管理できるソースを選びましょう。既存の講座データベースがすでに情報を管理しているなら、それを利用するのが適切かもしれません。一方、小規模な公開ディレクトリなら、よりシンプルなコンテンツ管理手順で十分な場合もあります。

スタイルを設定する前にAPIの応答を確認する#

APIとは、ソフトウェアがデータを要求したり、操作を実行したりするためのインターフェースです。REST APIでは一般にウェブリクエストを使用し、JSONなどの構造化データを返します。TeleportHQで「Data Sources」→「Add Data Source」→「REST API」を開き、アドレスを入力して必要なリクエスト設定を行います。

「Fetch data from API」を使って、保存する前に応答を確認してください。 REST API接続ガイド では、メソッドや認証、キャッシュについて説明しています。例に記載されたアドレスは仮のものとして扱ってください。プロジェクトには、必要なレコードを実際に提供するエンドポイントが必要です。

この段階で、応答の構造を確認してください。講座の一覧はそのまま返されますか、それとも別のオブジェクトの中に格納されていますか。画像は完全なURLですか。講座には安定した識別子がありますか。こうした点をスタイル設定の前に確認すれば、実際のサービスが提供していないフィールドに依存したレイアウトを作ることを防げます。

データの鮮度に関する要件も確認しましょう。講座の説明文ならキャッシュされた内容でも問題ないかもしれませんが、時間によって変わる空き状況の数値には別の扱いが必要な場合があります。動作を意図的に選び、実際のデータソースで更新をテストしてください。一度正しいデータが表示されたからといって、今後の変更がどのように反映されるかまで確認できたことにはなりません。

各レコードに1枚のカードを紐づける#

TeleportHQのArray Mapperを使うと、レコードのリストに同じレイアウトを繰り返し表示できます。「Elements → List → Array Mapper」から追加し、データソースを接続して、その中に繰り返し表示するコンテンツをデザインします。 リスト要素のガイド で設定方法を説明しています。

タイトルと画像を現在のリスト項目に紐づけます。よくある間違いは、すべてのカードをデータソースの最初の行に紐づけてしまうことです。その場合、レイアウトは正しく繰り返されても、すべてのカードに同じ情報が表示されます。 データバインディングのドキュメント では、固定レコードと現在の項目の違いについて説明しています。

意図的に内容を変えた複数のレコードで、紐づけを確認します。表示されるタイトルと画像、リンク先を照らし合わせてください。2つ目のコースを選んだのに1つ目のコースのページが開く場合、見た目は完成していても機能に問題があります。レコードを追加したり見た目の効果を加えたりする前に、マッピングを修正しましょう。

基本的なリストが機能したら、訪問者に必要なコントロールだけを追加します。幅広いカタログにはカテゴリーフィルターが役立つ場合があります。リストが長く、移動しにくい場合はページネーションを検討しましょう。コントロールを増やすとテストすべき状態も増えるため、それぞれが明確なユーザーニーズに応えていることを確認してください。

タスクに合ったフォームとワークフローを選ぶ#

簡単な問い合わせには通常のフォームを使う#

サービスに関する問い合わせには、標準的なフォームを使えます。返信に必要な情報を尋ね、送信後の流れを説明しましょう。営業チームが必要としているのがメールアドレスとメッセージだけなら、さらに複数の項目を必須にすると、訪問者に不要な手間をかける可能性があります。

TeleportHQでForm要素または既製のフォームセクションを追加し、項目を設定します。TeleportHQのホスティングを利用している場合、送信内容はGrowth → Formsで確認できます。 フォーム作成ガイド では設定方法を説明し、通常のフォームを設置しただけでウェブサイトがウェブアプリに変わるわけではないことを確認しています。

送信が成功するケースと、入力内容が無効なケースをテストします。保存された値と、訪問者に表示されるメッセージの両方を確認してください。問い合わせにコース名を含める必要がある場合は、チームに正しいコース情報が届くことを確かめましょう。見た目に説得力のある確認メッセージが表示されても、必要な情報が届いた証明にはなりません。

ホスティング環境は、この選択に影響します。TeleportHQの組み込みフォーム処理は、プロジェクトでサポートされているホストアドレスと、接続済みのカスタムドメインに対応しています。ウェブサイトをエクスポートして別の場所でホスティングする場合は、別のフォーム処理サービスを用意してください。サイトを移行してから慌てて対応することのないよう、その代替サービスも引き継ぎ範囲に含めておきましょう。

アプリの動作にワークフローを追加する#

要件に明確な一連の操作が含まれる場合は、ワークフローを使います。たとえば、問い合わせを受けた際に、データベースへのレコード作成と通知の送信が必要になることがあります。ワークフローを設定する前に、トリガーと期待する結果を明確にしてください。動作を確認しやすくなります。

TeleportHQでWorkflowsパネルを開き、ワークフローを追加してから、トリガーとステップを選択します。 ワークフロー作成ガイド によると、ワークフローを追加するとウェブサイトはウェブアプリに変換されます。この変換は元に戻せず、単純なインターフェース操作だけのワークフローであっても、コードのダウンロードができなくなります。

シンプルなタブや開閉式のセクションには、ページまたはコンポーネントの状態を使う方法も検討してください。状態は、セクションが開いているかどうかなどの値を保持します。こうしたローカル状態は、ワークフローを追加せずにウェブサイトプロジェクトで利用できます。プロジェクトの種類を変更する前に、操作に合った機能を選びましょう。

データベース操作については、プラットフォームのドキュメントで「Create Item」や「Update Item」などのステップが紹介されています。 データベースワークフローガイド に沿って、データソースを選択し、値を対応付けてください。更新する場合は、重要なデータでテストする前に、フィルターでどのレコードが選択されるかを確認しましょう。

コースに関する問い合わせでは、次のような設定が考えられます。

1. フォームの送信をトリガーにします。
2. 「Data → Create Item」を追加し、問い合わせテーブルを選択します。
3. 送信されたメールアドレスとコース識別子を、それぞれ保存先の列に対応付けます。
4. 新しいレコードが必要な手順を実行する前に、データベースの処理結果を待ちます。

ワークフローで送信を処理すると、フォームは通常のFormsプロセスを通じて送信内容を保存しなくなります。問い合わせを保存する必要がある場合は、明示的な保存ステップを追加してください。ラベル付きのテストレコードを使ってワークフローをテストし、保存された内容を確認するために保存先のテーブルを調べます。

成功時だけでなく、失敗時のケースも併せて計画します。レコードは保存されたものの通知に失敗した場合、訪問者には何を表示しますか。チームは問い合わせをどのように見つけますか。こうした点もワークフローの仕様に含める必要があります。そうすることで、一部だけ完了した処理を、完全な失敗や成功と誤認するのを防げます。

実際のコンテンツでレスポンシブ動作をテストする#

レスポンシブデザインは、画面幅に応じてインターフェースを調整します。TeleportHQでは、有効になっているブレークポイントのうち最も大きいものから小さい画面へとスタイルが引き継がれます。そのうえで、画面幅の狭いデバイス向けに調整できます。 レスポンシブデザインガイド では、この継承の仕組みと利用可能なブレークポイントの設定について説明しています。

関連する各画面サイズで、主要な操作の流れを確認します。コース名が読みやすく表示されているか、問い合わせボタンを見つけやすいかを確認してください。モバイルナビゲーションを開き、フォームを送信します。こうした操作を試すことで、ページ上部の静止画を見るだけよりも多くの問題を発見できます。

あらかじめ設定された表示サイズだけでなく、中間の画面幅でもテストします。幅の広いモニターと狭いスマートフォンでは正しく表示されても、その中間の幅では崩れることがあります。テキストの見切れや横スクロールが発生していないか確認してください。繰り返し使われるコンポーネントは、1つのレイアウトの問題が多数のページに影響することがあるため、念入りに確認します。

テストでは、さまざまな条件のコンテンツも確認します。翻訳後にラベルが長くなると、より広いスペースが必要になる場合があります。画像のないコースでも、使いやすいカードとして表示される必要があります。画像がない場合にプレースホルダーを表示するのか、レイアウトから画像を省くのかを決め、その方針を一覧全体で統一してください。

レビューの範囲を明確にし、無理のない量にする#

共有エディターが役立つのは、各自の責任が明確な場合に限られます。チーム内に適切な役割がある場合は、コンテンツの承認担当者と、訪問者の操作の流れを確認する担当者を割り当てます。公開できる人も決めておきましょう。そうしないと、ページが正しく編集されても、動作確認が終わる前に公開されてしまうおそれがあります。

TeleportHQでは、権限の異なる共同作業者の役割を設定できます。編集者はコンテンツやページを編集できますが、デザイン設定や公開には別の権限が必要です。クライアントやチームメイトを招待する前に、 役割と権限のリファレンス を確認し、プロジェクトへのアクセス権とワークスペースへのアクセス権を区別しましょう。

フィードバックは、具体的に確認できる問題として伝えましょう。「画面幅が狭いとコース名が所要時間に重なる」なら、編集者は同じ状況を再現して対応できます。「カードをもっとよくして」では、期待する結果が曖昧です。該当するページと画面サイズを示し、修正後にどうなればよいかを伝えましょう。

各レビューを特定の目的に絞りましょう。複数人が同じセクションを書き換える前に、レイアウトのレビューを済ませます。コンテンツの承認後は、ユーザーの一連の操作を改めて確認してください。ラベルが長くなったり、リンクが変わったりすると、インターフェースに影響することがあります。判断の順序を明確にすれば、共同作業による遅延を減らせます。

テスト済みのバージョンを公開する#

編集画面以外で変更を確認するには、ステージングサイトを使いましょう。TeleportHQのホスティングでは、ステージング用の専用アドレスが提供されます。「公開」を開いて「ステージング」を選び、候補のバージョンを公開します。テスト済みのビルドを「公開する」で本番環境に反映する方法は、 ステージングガイド で説明しています。

レビュー担当者には、簡潔な受け入れチェックリストを渡しましょう。主要な問い合わせの流れを実際に試してもらい、具体的な問題を報告するよう依頼します。内部リンクを確認し、フォームの送信結果も調べます。ディレクトリが外部データを読み込む場合は、この環境で想定どおりのレコードが表示されるか確認してください。

ステージング環境を利用できても、すべての外部連携でテスト用データが使われるとは限りません。レビュー前に、送信内容やワークフローの処理先を確認してください。レビュー中の操作と実際の問い合わせを区別できるよう、識別可能なテスト用レコードを使いましょう。テストが終わったら、それらのレコードを削除してください。

ここで説明しているステージングの手順は、TeleportHQのホスティングを利用する場合に適用されます。個人のVercelアカウントから公開するプロジェクトでは、設定が異なります。コードを書き出して利用する場合は、ビルダーのステージング手順が書き出したファイルにも適用されると思い込まず、そのホスティング環境に合わせてプレビューとリリース時の確認手順を整えてください。

機能を短いサイクルで改善し、テストする#

素早く改善するには、変更ごとに目的を明確にすることが大切です。たとえば、訪問者がコースページを開くものの、問い合わせをほとんど送信しないとします。まずフォームが正常に動作するか、次に何をすればよいかが明確かを確認しましょう。基本的な操作の流れを調べる前にサイト全体を変更すると、結果の解釈が難しくなります。

繰り返し実行できるプロセスを使いましょう。

1. 確認した問題と、影響を受けるページを記録します。
2. 変更後に期待する動作を明確にします。
3. 関連するコンポーネントまたはセクションのうち、必要最小限のものを更新します。
4. 代表的なコンテンツと画面サイズで変更をテストします。
5. 公開前にステージング版を確認します。
6. 関連する利用が十分にあった後で、結果を確認します。

こうした後のサイクルでは、再利用が特に効果を発揮します。共有カードを修正すれば、すべてのコース一覧を改善できます。フィールドに分かりやすい名前を付ければ、コンテンツ更新時の混乱を防げます。最初の構築時に行う小さな構造上の決定が、その後のすべての修正にかかる時間を左右します。

AIは範囲を絞った編集を支援できますが、依頼内容には明確な条件が必要です。たとえば、「このコースの概要を約40語に短縮してください。受講要件と記載されている期間は残してください」のような指示が有効です。公開前に、出力を元の資料と照合してください。文章が流暢だからといって、事実が正確だとは限りません。

変更内容を記録しておきましょう。変更理由と公開日を記し、十分なデータが得られた時点で関連する成果を比較します。アクセス数の少ないウェブサイトでは、短期的なコンバージョン率の変化よりも、利用者から直接寄せられる使いやすさに関するフィードバックのほうが、問題を早く明らかにすることがあります。実際の利用量に見合った根拠を選びましょう。