お知らせ:当社は、お客様により充実したサポート情報を迅速に提供するため、本ページのコンテンツは機械翻訳を用いて日本語に翻訳しています。正確かつ最新のサポート情報をご覧いただくには、本内容の
英語版を参照してください。
1. Zoho Zia App Builder で作成されるもの
Zoho Zia App Builderは、GenAI を使用して、自然言語で記述された意図、プロセスフロー、期待される結果を解釈し、プロンプトを機能する Zoho Creator アプリケーションに変換します。データベーススキーマや自動化ロジックなどの技術的な要素を事前に定義する必要はありません。これらは、要件の記述内容から自動的に導き出されます。
プロンプトが送信されると、Zoho Zia は、どのような情報を取得する必要があるか、レコード同士をどのように関連付けるか、プロセスにどのようなアクションや遷移が含まれるかを分析します。この理解に基づいて、記述された業務フローを反映した初期のデータモデルと、それに連動するフォームや関連するユースケースを生成します。
この段階で、生成されたデータモデルを確認し、ユースケースを追加・削除・調整して、先に進む前に意図したプロセスを正確に表現できているかを確認できます。データモデルが確定すると、Zoho Zia がアプリケーションの構築を開始します。承認されたデータモデルに基づき、Zoho Creator 内に関連するフォーム、レポート、ワークフロー、ブループリント、ユーザー権限、ダッシュボード、およびユーザー操作画面の補助要素を作成します。
その結果、すぐに確認して、必要に応じて機能を拡張できる実行可能なアプリケーションが作成されます。リファレンス用のスキーマドキュメントや抽象的なモデルを生成するのではなく、Zoho Zia は実際の業務運用をすぐに支援できるアプリ構造を生成します。
次のセクションでは、Zoho Zia がプロンプトの各要素をどのように解釈し、それをアプリケーション構造の設計にどのように活用するかを説明します。
2. Zoho Zia がプロンプトを理解する方法
Zoho Zia は、プロンプトを意図を推測し、記述された要件や業務プロセスに最適なアプリケーションのデータモデルを設計するための指針として解釈します。指示どおりに逐語的に従うわけではないため、生成されるアプリケーションの品質には、目的、フロー、期待される結果を明確にすることが重要です。
プロンプトは、次のような要素に基づいて評価されます。
- 意図:達成したいゴールや成果を明確に定義します。
- コンテキスト:アプリケーションが運用されるビジネスシナリオを説明し、Zoho Zia が実際の利用状況に沿った構造を設計できるようにします。
- 制約:データモデルの作成時に必ず守るべきルール、バリデーション、構造上の要件を指定します。
これらの入力を基に、Zoho Zia は自然言語での要件と、Zoho Creator におけるアプリケーション構造とのギャップを埋めます。
情報:Zoho Zia はプロンプトのローカライズにも対応しており、多言語アプリケーションを構築できます。これにより、手動で翻訳作業を行わなくても、コンテンツをグローバルなユーザー向けに最適化できます。
次のセクションでは、Zoho Zia が正しく解釈し、信頼性の高いアプリケーションを生成できるように、プロンプトをどのように構成すべきかを説明します。
3. プロンプトに含めるべき内容
- 解決したい課題 - アプリやコンポーネントが対処する課題やニーズを明確に記述します。
- サポートすべきプロセス - Zoho Zia に実装してほしいワークフローを説明します。複雑なプロセスは、明確で論理的なステップに分解します。
- 期待する成果 - 出力がどのようなものか、アプリが何を生成・自動化・改善すべきかを説明します。
- 目的と背景 - アプリや機能の存在理由を簡潔に説明します。これにより、Zoho Zia はより正確なロジックやフローを設計できます。
- 含めるタブ - Zoho Zia が基にすべき、固有のタブとそのデータ入力要件を指定します。Zoho Zia はそれらを分析し、適切な項目タイプを作成・割り当てます。
- 関連する情報のみ - 挙動に影響する制約、入力、出力、ルールを追加します。
- 明確で、直接的な言葉 - まず Zoho Zia に作成してほしい内容を平易な言葉で説明し、その後に詳細を重ねていきます。
4. 指定する必要がない内容
- 項目タイプの定義 - 「価格の項目を通貨型にしてほしい」「日付の項目をカレンダー入力にしてほしい」などと Zoho Zia に指示する必要はありません。
Zoho Zia のロジック:プロンプトに「Cost(コスト)」「Deadline(期限)」「Customer メール」などと記載すると、Zoho Zia は自動的に通貨、日時、メールといった項目タイプを割り当てます。また、メールアドレスに @ 記号が含まれているかなどのデータバリデーションも、自動的に処理します。
- データの正規化 - データの重複や、アプリを整理するために情報を複数のフォームに分割する方法について心配する必要はありません。
Zoho Zia のロジック:プロンプトが「顧客、その注文、および注文内の商品を管理したい」のように複雑な場合、Zoho Zia は 1 つのフォームに詰め込むのではなく、これらを 3 つの別々のフォームに分割することを賢く提案します。
- UI/UX レイアウトルール - 「送信ボタンは下部に配置してほしい」「項目は 2 列に整列してほしい」などと指定する必要はありません。
Zoho Zia のロジック:Zoho Zia は Zoho Creator の標準デザインテーマに従います。項目を論理的なセクションに整理し、自動的にモバイル対応のグリッドに配置します。
- コンポーネント名と構造 - 「フォーム」「レポート」「ワークフロー」や特定の項目名など、Creator のコンポーネント名を正確に指定する必要はありません。
Zoho Zia のロジック:取得・閲覧・自動化したい内容を説明すると、Zoho Zia が必要な Creator コンポーネントを判断し、アプリケーション構造内で適切に整理します。
5. テキストとファイル入力によるプロンプト
Zoho Zia への要件の伝達は、テキストプロンプト、ファイルのアップロード、またはその両方の組み合わせで行えます。以下はいくつかの開始方法です。
大まかなアイデアしかない場合や、簡単な PoC(概念実証)やデモを作成したい場合は、アプリケーションが何を行うべきかを平易な言葉で説明するシンプルなテキストプロンプトから始められます。Zoho Zia はこの入力を解釈して、初期のユースケースと基礎となるデータモデルを生成し、その後アイデアの進展に合わせて調整・拡張できます。
- シンプルなアイデアから始める - 大まかなアイデアしかない場合や、簡単な PoC やデモを作成したい場合は、アプリが達成すべき内容を平易な言葉で説明するシンプルなテキストプロンプトから始められます。Zoho Zia はこの入力を解釈し、初期のユースケースと基本的なデータモデルを作成します。その後、アイデアの成長に合わせて調整できます。
- 精度向上のために詳細を追加する - 要件がより明確な場合は、次のような形で構築できます。
- 会話形式のプロンプト:アプリがどのように動作すべきか、どのような課題を解決する必要があるかを、具体的な詳細を含めて説明します。これにより、Zoho Zia は意図したプロセスに合致した、より正確で最適化されたフォームやその他のコンポーネントを生成できます。
- タブ駆動型プロンプト:データモデルの構成が明確な場合は、詳細なデータ入力要件を含めて、個別のタブを分類・定義します。これにより、Zoho Zia は各タブに基づいて、関連するフォーム項目やダッシュボードなどを含むフォームを生成できます。
- 複雑な要件にはドキュメントをアップロードする - すでに BRD(ビジネス要件定義書)、PRD(プロダクト要件定義書)、RFP(提案依頼書)、詳細なタブ別情報を含むプロセスフローダイアグラムなどの正式なドキュメントがある場合は、それらをプロンプトとしてアップロードできます。この場合、Zoho Zia は定義された要件を抽出し、ドキュメントの内容に沿った構造化データモデルに変換します。
メモ:
- テキストプロンプトは最大 5000 文字まで入力できます。より詳細な要件が必要な場合は、ドキュメントとしてアップロードすることを検討してください。
- 参照ファイルとしてアップロードできる形式は、PNG、JPG、JPEG、WEBP、PDF、TXT です。
- 1 つのプロンプトにつき、画像は最大 3 枚、またはドキュメント 1 件のいずれかをアップロードできます。
ファイルをアップロードする際の推奨ベストプラクティスは次のとおりです。
- 構造化 - セクション構成が明確なファイルの方が、Zoho Zia はより高い精度で処理できます。
- 関連する参照のみをまとめる:同じユースケースに属するファイルのみをアップロードしてください。関連性のない複数のドキュメントをまとめると、意図が不明確になる可能性があります。
- 高品質なファイル - 画像やスキャンした図をアップロードする場合は、文字が判読可能であることを確認し、手書きや不鮮明なテキストは避けてください。
- テキストベースのコンテンツを優先する - 最適な結果を得るには、埋め込み画像ではなく、テキスト情報を含むドキュメントを使用してください。
- ファイルの概要をテキスト入力で補足する - ファイル内の特に重要なセクションを簡潔に説明し、正確な解釈を促すための概要をテキストで入力してください。
サンプルプロンプトファイル:この
フォルダーには、マルチモーダルシステムへのアップロードやテスト、検証に使用できるサンプル PRD やプロセス図が含まれています。これらのサンプルファイルは、独自の要件ドキュメントを作成する際の参考フレームワークとしても利用できます。
6. 要件レベルに応じたプロンプト作成
プロンプトのアプローチは、要件の詳細度によって異なります。シンプルな PoC から、中程度の詳細を含むプロンプト、PRD・BRD・プロセスフローに基づくエンタープライズレベルの入力まで、さまざまです。
6.1. シンプルな PoC
後からカスタマイズや拡張を行うことを前提とした、基本的なアプリケーションを作成するためのプロンプトです。
サンプルプロンプト:
顧客を登録し、購入履歴を追跡し、支出額に応じて自動的にポイントを付与し、特典交換を管理し、顧客のアクティビティとロイヤルティのパフォーマンスに関するインサイトを提供する、顧客ロイヤルティプログラムアプリケーションを作成してください。
6.2. 詳細なプロンプト
特定のユースケースに合わせて、実運用に近いアプリケーションを生成するための、詳細とコンテキストを含んだプロンプトです。
例 1:会話形式のプロンプト
実店舗とオンラインストアの両方を運営する中規模のファッション小売業向けに、顧客ロイヤルティ管理アプリケーションを作成してください。このアプリの目的は、顧客登録の管理、チャネルをまたいだ購入履歴の追跡、ロイヤルティポイントの正確な計算、定義済みの承認・実行ワークフローに基づく特典交換の処理です。
アプリは、レジでの店頭登録、オンラインでのセルフ登録、来店客に対するスタッフによる登録など、複数の顧客登録方法をサポートする必要があります。各顧客データには、個人情報、連絡先情報、よく利用する店舗、登録経路、会員ランクを含める必要があります。
購入情報は、スタッフによる手動入力または売上データとの連携により記録され、請求書番号、購入チャネル(店舗またはオンライン)、商品カテゴリ、取引金額、日付などの詳細を含めます。ロイヤルティポイントは、利用金額に応じたポイント付与、特定カテゴリ商品のボーナスポイント、シーズンプロモーション、会員ランクに応じた倍率など、事前に定義されたルールに基づいて計算される必要があります。顧客とのやり取りには、購入履歴、特典交換、カスタマーサポートへの問い合わせ、キャンペーン参加などのアクティビティを含めます。各アクティビティはログとして記録し、顧客プロファイルに紐付けて、完全なインサイトを得られるようにします。
アプリには、購入の検証後に自動でポイントを付与するワークフロー、ポイントが加算された際に顧客へ通知するワークフロー、顧客が特典利用条件を満たしたときにアラートをトリガーするワークフローを含める必要があります。特典交換リクエストは、スタッフが利用条件を確認し、リクエストを承認または却下し、特典の提供完了を記録できる承認プロセスに従う必要があります。
システムは、顧客のポイント残高、ランクの進捗、失効予定ポイント、交換履歴に関するリアルタイムのインサイトを維持する必要があります。また、リピート購入傾向、最も利用されている特典、休眠顧客、優良ロイヤルティ会員などのパフォーマンス指標も生成する必要があります。
全体として、このアプリケーションはロイヤルティ運用を一元管理し、ポイント管理を自動化し、一貫したワークフローを適用し、小売ビジネスが顧客維持と長期的なエンゲージメントを向上できるような実用的なインサイトを提供する必要があります。
例 2:タブ駆動型プロンプト
実店舗とオンラインチャネルの両方を運営するファッション小売ビジネス向けに、ロイヤルティ管理アプリケーションを作成します。アプリでは、顧客登録、購入履歴の管理、ロイヤルティポイントの計算、特典交換、パフォーマンス分析、主要なロイヤルティ指標を一元的に監視するダッシュボードを、統合されたシステムとして管理できるようにします。以下のコアタブを使用してアプリケーションを設計し、それぞれで指定されたデータを確実に取得してください。
1. 顧客・会員管理
氏名、連絡先情報、住所、よく利用する店舗、登録経路(店舗、オンライン、スタッフ対応)などの顧客の個人情報を取得します。会員ランク、登録日、ランク開始日と有効期限、配信設定、顧客ステータスを記録します。すべてのチャネルで一元化された顧客プロファイルを維持します。
2. 取引および顧客アクティビティ
請求書番号、購入日、購入チャネル、商品カテゴリ、取引金額、紐づく顧客などの情報とともに、購入取引を記録します。問い合わせ、サポート依頼、プロモーション参加、来店など、非購入のやり取りも記録します。各顧客プロファイルに紐づくアクティビティ履歴を完全な形で保持します。
3. ロイヤルティポイント管理
獲得ポイント、利用ポイント、ポイント付与理由、関連する購入参照、日付などを含むポイント取引を保存します。現在のポイント残高、使用済みポイント、失効ポイント、有効期限を管理します。ポイント計算を会員ランク、プロモーション、購入カテゴリと関連付けます。
4. 特典およびポイント交換管理
特典名、説明、必要ポイント数、有効期間、適用条件などの特典情報を取得します。顧客参照、申請日、使用ポイント数、承認ステータス、履行ステータス、履行方法、完了日を含むポイント交換申請を記録します。
5. インサイトとモニタリング
発行ポイント総数、利用ポイント総数、最終購入日、リピート購入頻度、休眠顧客、優良顧客、最も交換された特典などの指標を追跡します。ロイヤルティ施策へのエンゲージメント傾向を分析するために必要なデータを提供します。
プロセス、ワークフロー、スケジュール、通知
- 購入内容を検証したうえで、自動的にポイントを付与します。
- ポイント付与時、顧客が特典の利用条件を満たした時、ポイントの有効期限が近づいた時に通知をトリガーします。
- ポイント交換申請は、履行前に承認プロセスに回します。
- ランクアップ、ランク有効期限、ポイント有効期限を定期的にチェックするスケジュールを設定します。
6.3. 複雑な要件ファイル向けプロンプト
PRD、BRD、プロセスフローなどの包括的な資産をすでに保有している企業向けに設計されたプロンプトです。
ガイド用テキストプロンプト:
このドキュメントは、Zoho Creator で構築し、Zoho CRM と連携するカスタマーロイヤルティ管理アプリケーションの範囲と機能要件を定義したものです。フォーム、ワークフロー、レポート、連携機能を設計する際は、このスコープを主な参照情報として使用してください。アプリケーションは、顧客登録、ロイヤルティポイントの蓄積、ランク管理、特典交換、通知、レポートをサポートし、Zoho CRM の連絡先および商談と正確にデータ同期される必要があります。ドキュメントに記載されたワークフロー、データモデル、受け入れ基準に従うことで、スケーラブルで監査可能、かつ実際のビジネスにおけるロイヤルティ活用事例に即したアプリケーションを実現してください。
7. 会話型プロンプトによるアプリケーション作成
8. まとめ
一般的な目安として、プロンプトが具体的であるほど、得られる結果は良くなります。目的、背景、期待する成果を明確に伝えることで、Zoho Zia は意図を正確に理解できます。よく練られたプロンプトを使用すると、フォーム、ワークフロー、ダッシュボードなど、ビジネスニーズに合致し、効果的なアプリケーションを GenAI で包括的に構築できます。
- Creator における Zoho Zia 機能の概要
- Zoho Zia App Builder(Zoho GenAI 対応)でアプリケーションを作成する
- Zoho Zia App Builder(OpenAI、Google、Anthropic 対応)でアプリケーションを作成する