アプリビルダーの使い方

Suite、すべてのバージョン

Professional、EnterpriseまたはEnterprise Plus

Support

ProfessionalまたはEnterprise

アプリビルダーでZendeskアプリを作成してZendeskの機能を拡張し、顧客サービスや従業員サービスの個々のワークフローに適合させることができます。開発者から費用の高いサポートを受けたり、新機能のリリースを長く待ったりせずに、必要な専門的なプロセスをサポートするソリューションを、必要な時にすばやく構築できます。

アプリビルダーによるアプリの作成では、自然言語処理（NLP）と生成AIを活用できます。NLPを使うと、同僚や友人にアイデアを説明するように、平易な言葉で指示を入力できます。生成AIはそれらの指示を解釈し、必要なコード、UI、機能を生成します。生成AIを使えば、アプリを説明するのと同じくらい簡単にアプリの構築ができ、従来のコーディングに伴う学習のハードルを解消できます。

アプリビルダーを使用することで、主に次のようなメリットがあります。

短期間でのプロトタイプ作成：平易な言葉のプロンプトから機能するコードを生成できるため、コンセプトから動作させるプロトタイプまで迅速に移行できます。
リアルタイムのビジュアルプレビュー：開発中にアプリの外観や動作を即座に確認できるため、デザインと機能性の検証が容易です。
ビルトインのバージョン管理機能：変更が発生するたびに自動的にバージョン管理が行われます。変更イベントの追跡、以前のバージョンの復元、変更点の差異の比較が簡単に行えます。
エンドツーエンドのテスト環境：デプロイ前に、Zendeskの実データとAPIレスポンスを使ってアプリをテストできます。ただし、テスト中に加えた変更は実際のアカウントに反映されます。
Zendeskに特化したAIの知見：Zendeskのフレームワーク、API、設計のベストプラクティスを活用してアプリを生成し、Zendesk特有の一般的な問題も自動的に解決します。
データ統合：Zendesk、社内システム、GoogleやJiraなどの主要サードパーティプラットフォームのデータを連携させて活用するアプリを構築できます。
作業内容の保存と同期：作業内容はセッション、ブラウザ、デバイスを問わず安全に保存され、常に最新の状態が維持されます。
ダークモード対応：アプリビルダーはダークモードとライトモードの両方をサポートします。好みのテーマでアプリを構築およびテストでき、アプリは、エージェントごとのインターフェイス設定に合わせて自動的に表示が調整されます。追加のコーディングは不要です。2025年12月以前に構築されたアプリをダークモードで正しく表示させるには、アプリを再度公開するか、またはプロンプトの更新が必要になる場合があります。
多言語対応のローカライズ可能なインターフェイス：アプリビルダーとそのすべてのメニュー、プロンプト、ガイダンスはすべて翻訳可能です。翻訳が提供されている場合、インターフェイスは選択した言語で表示され、右から左（RTL）のレイアウトや地域固有の書式が自動的にサポートされます。

アプリビルダーで作成したアプリは、Zendesk Gardenのコンポーネント、ZAF API、およびREST APIを使用して設計されています。

メモ：旧バージョンのSupportインターフェイスを使用しているアカウントでは、アプリビルダーは利用できません。

この記事では、以下のトピックについて説明します。

アプリビルダーの概要（ビデオ）
初めての使い方
例：担当者変更の追跡アプリを作成する
コードタブとアプリの設定を詳しく見る
アプリをインストールして管理する
プライベートシステムおよびサードパーティプラットフォームと統合する
トラブルシューティング
免責事項とメンテナンス
制限事項

アプリビルダーの概要（ビデオ）

この記事の説明に加えて、次のビデオはアプリビルダーの使用を開始するための概要を視覚的にまとめています。

初めての使い方

会話は、会話ペインで行われるガイド付きの継続的なやり取りです。このペインで、要件の概要説明、提案された解決策の確認、アプリの改良、必要に応じたエラーのトラブルシューティングを行います。会話はアプリビルダーとの対話型ワークスペースとして機能し、アプリの構想を練る過程で交わされるすべてのプロンプト、応答、反復を記録します。

複数の会話を同時に進め、異なるアイデアやプロトタイプを探求することができます。すべての会話がアプリとして公開されるわけではありません。時には、実験や学習、機能テストのためだけに利用されることがあります。

プロンプトとは、会話を進めるために会話の中で送信する個々の指示や質問のことです。たとえば、「このビューにステータスフィルターを追加する」や「優先度の高いチケットを最初に表示するようにアプリに変更を加える」といったプロンプトを入力できます。一連のプロンプトと応答を通じて、アプリビルダーとやりとりしながらアプリを構築し、改良していきます。

アプリとは、成功した会話から作成してインストールされる具体的な成果物です。アプリは、Zendesk内で構築、テスト、公開、管理する実務ソリューションです。公開したアプリを、エージェントと管理者はワークフロー内で利用できます。アプリは、1つの会話または複数のやりとりから生成される場合もあれば、複数回の調整を経て生成される場合もあります。

アプリビルダーでは、会話とアプリは別々に追跡されます。会話は、作成中または改良中の未完成状態のアプリか、またはZendeskで既に運用されている公開済みアプリのいずれかにリンクできます。このリンク付けにより、いつでも任意の会話に戻ってアプリの構築を再開したり、公開済みアプリに変更を加えて再公開したりできます。

アプリビルダーはNLPと生成AIを活用し、ユーザーのプロンプトを理解して機能するアプリを生成します。アプリビルダーの結果を最適なものにするには、特定のガイドラインに従ってプロンプトを作成することが重要です。ベストプラクティスについては「アプリビルダーのプロンプト作成ガイドライン」を参照してください。

本番運用可能なアプリを一度で作成できることは滅多にありません。通常、アプリの最終形に達するまで作業を何度も繰り返すことになります。以下にベストプラクティスのガイドラインを示します。

まずはシンプルな機能を構築し、さらにプロンプトを追加してコンテキストや詳細な要件を補足しながら継続的にアプリを改良します。開発プロセスを複数の段階に分割することで、複雑化しないうちに、アプリの特定の部分に生じる問題のトラブルシューティングや解決の取り組みが容易になります。
構築したアプリが動作しない場合は、AIにロギングを依頼してください。
AIの応答を読み、構築の依頼内容をAIが正しく理解しているか確認します。
アプリを公開する前にテストを徹底的に行います。
テスト中にエラーが発生したら、そのエラーメッセージをコピーしてプロンプトにペーストしてください。これにより、アプリビルダーが問題を分析し、デバッグを支援します。
期待通りに動作しないものがある場合は、期待する動作、正常に機能している部分、機能していない部分などを詳細に説明してください。単に「動作しない」と述べるのは避けてください。
忍耐強くプロセスに取り組み、AIの動作のしくみや、期待した結果にならない場合の対処法を深く理解するようにしてください。

アプリをはじめて作成する

アプリを作成するには

管理センターで、サイドバーの「 アプリおよびインテグレーション」をクリックし、「アプリ」>「アプリビルダー」を選択します。アプリビルダーを使用するには、Zendeskの管理者であることが必要です。

はじめてアプリを作成する場合、アプリビルダーを開くとウェルカムページが表示されます。「会話を開始」をクリックしてアプリの作成プロセスを開始します。

2回目以降からは、アプリビルダーを開くと会話リストページが開き、既存の会話に素早くアクセスすることができます。会話は最終更新日時の新しい順に並んでいます。

会話を開始すると、まずアプリの表示場所を選択するよう求められます。各アプリで選択できる表示場所は一度に1か所のみです。以下のいずれかの表示場所を選択します。

チケットサイドバー：Zendesk Supportの各チケットの詳細画面に表示されます（デフォルト）。この場所は、チケット固有の情報、アクション、インテグレーションを表示するのに適しています。既存チケットおよび新規チケット（オプション）に適用されます。
新規チケットサイドバー：エージェントが新規チケットを作成する際に表示されます。チケット作成の支援、テンプレート、データの拡充、検証に最適です。
トップナビゲーション：Zendeskインターフェイスの最上部のバーは、チケットや画面に関係なく常に表示されているため、アクセスが容易です。通知ハブやクイックアクションなど、全体で利用するツールに適しています。
サイドナビゲーション：Zendesk Supportの左側ナビゲーションパネルの下部に表示されます。ダッシュボードやレポートなどの追加スペースを必要とする複雑なアプリやスタンドアロンアプリに最適です。

アプリの表示場所を選択すると、会話ペインが表示されます。提供されたプロンプト例のいずれかを使用するか、独自のアプリ要件を入力して「送信」をクリックしてください。

AIが提案したプランを承認する

最初のプロンプトを入力すると、アプリビルダーのAIがアプリに適した推奨プランを生成して提示します。そのプランを確認して、そのまま承認するか、不要な要素を削除するか、または追加で推奨された機能を組み込むことができます。この方法により、ニーズに合わせてアプリを迅速かつ柔軟にカスタマイズできます。

「プランを承認する」画面に、提案されたアプリの機能と、コアおよびオプションの機能の概要が表示されます。希望に応じて、各機能の横にあるチェックボックスをクリックして機能をオン/オフにします。後から変更を続けることも可能なので、現時点で迷っても問題ありません。以下に例を示します。

プランニング画面の下部には、2つの選択肢があります。

プランニングを続行：新たな要件を追加したり、調整を加えるなどして、提案されたプランをさらに練り上げます。
プランを承認して構築：選択した機能を確認し、承認したプランに基づいてアプリを生成します。

アプリを改良してテストする

承認したプランをAIが生成した後、アプリビルダーを使用して、Zendeskアカウント内で直接アプリの調整、プレビュー、テスト、公開を行うことができます。

プレビュー：「プレビュー」をクリックすると、新しく生成されたアプリを「プレビュー」タブで確認できます。ここではダミーデータを使用して、レイアウト、データフロー、インタラクティブな要素を、安全にプレビューできます。ただし、これは公開後にアプリが期待通りに動作することを保証するものではありません。公開する前に、実際のアカウントデータを使用してアプリをテストします（以下を参照）。
「コード」タブを使用してアプリのファイル、フォルダ、コンポーネントを確認し、「設定」タブを使用してアプリの名前やロゴを確認し、更新します。
調整と反復：会話ペインに新しいプロンプトを入力することで、いつでもアプリを調整および更新できます。すべての変更は保存されるため、自由に試行錯誤ができ、必要に応じていつでも前のバージョンに戻すことができます。すべての変更には自動的にバージョンが付けられます。
復元：変更内容はすべて新しいバージョンとして自動的に保存されるため、実験している間も、エラーの修正中も、あるいはアプローチの見直し中でも、いつでも以前のバージョンに戻すことができます。
テスト：「テスト」をクリックして、実際のアカウントデータを使用してZendesk Supportでアプリを実行します。この操作では、アプリが意図したとおりにデータを表示、読み取り、書き込みを行い、実際のシナリオで正常に動作するかを確認できます。
メモ：アプリのテスト中に実施された更新や変更は、実際のアカウントデータに反映されます。
問題への対処：正常に動作しない場合は、アプリに表示されたエラーメッセージやログを参照して問題を特定してください。プロンプトにエラーの詳細を貼り付けて具体的な解決策を得るか、アプリビルダーにデバッグ出力を追加するよう指示してください。
アプリの設定：「設定」タブで、カスタム名を入力し、Gardenのアイコンライブラリからアイコンと背景色を選択して、アプリの表示をカスタマイズします。
アプリの公開と管理：アプリの改良が完了したら、「公開」をクリックして、Zendeskの管理者やエージェントがアプリを利用できるようにします。

例：担当者の変更を追跡するアプリの作成

ここでは、チケットの担当者変更を追跡するアプリの例を示します。

管理センターで、サイドバーの「 アプリおよびインテグレーション」をクリックし、「アプリ」>「アプリビルダー」を選択します。
「会話を開始」をクリックします。
「チケットのサイドバー」を選択し、「位置を選択」をクリックします。
プロンプトが表示されたら、以下の内容を入力します。
目的：このアプリは、チケットのイベント履歴をくまなく調べ、すべての担当者変更イベントを検索して追跡する手間を省き、担当者の変更状況を即座に把握できるようにします。また、「これらのチケットの引き継ぎはどこで行われたのか」というよくある疑問にも答えられます。アクション：特定のチケットにおける担当者の変更履歴を追跡する「Assignee Change Tracker」というアプリを作成します。構成要素：テーブルには、チケットの担当者の各変更について、最新のものから順に表示します。各行には、担当者の名前、割り当てられた日付、およびそのチケットに割り当てられていた期間などが含まれます。テーブルの上部には、そのチケットの担当者変更の回数が表示されます。表示データを更新するボタンを追加して、最新の変更を表示に反映できるようにします。データをExcelスプレッドシートにエクスポートするボタンも追加します。ボタンのサイズはどちらも小さくし、隣り合わせに配置してください。スコープ：このアプリは現在のチケットのみを対象とします。
デフォルトのプラン選択を使用し、「プランを承認して構築」をクリックしてください。
「送信」をクリックします。
アプリビルダーからは、次のような画面が返されます。
プレビューを確認して、アプリの見た目や動作を確認し、AIの応答内容を確認して、どのような内容に基づいてアプリが構築されているかを把握してください。
「コード」タブをクリックすると、生成されたコードや、プレビューの表示に使用されたモックデータを含むファイルを確認できます。
プロンプトが表示されたら、以下の内容を入力します。
テーブルの一番左側に「前の担当者」の列を追加し、前任のチケット担当者のフルネームが表示されるようにします。また、両方のボタンにツールチップを追加し、カーソルを合わせると各ボタンの機能に関する簡単な説明が表示されるようにします。
「送信」をクリックします。
アプリビルダーからは、次のような画面が返されます。
「テスト」をクリックして、実際のZendeskデータを使用してアプリをテストします。
テスト中は、行った変更が実際のアカウントに反映されるため、操作の影響を慎重に確認してください。また、「設定」タブでアプリの外観をカスタマイズすることもできます。たとえば、デフォルトのアイコンをそのまま使用するのではなく、運用するアプリのテーマに合った色やアイコンに変更します。これにより、アプリをすばやく識別できるようになります。

これでアプリが完成し、公開できる状態になりました。

コードタブとアプリの設定を詳しく見る

アプリビルダーでのアプリの構築と調整が終わると、「コード」タブを開いて、アプリの構築で生成されたすべてのコードファイルとフォルダを確認できます。

ファイルまたはフォルダ	説明
blueprint.md	アプリの目的、アーキテクチャ、機能、アプリ統合の詳細、および使用されている主要な技術（React、Zendesk Gardenのコンポーネントなど）に関する概要。
changelog.md	アプリの開発中に実施されたすべての変更および更新の履歴（時系列順）。これを使用して進捗状況を追跡し、変更をロールバックする必要があれば「生成されたアプリ」プルダウンメニューまたは会話履歴の「バージョン」から行えます。
index.jsx	アプリのメインソースファイル。アプリの読み込み、エラー処理、テーマの適用を管理し、アプリの機能のエントリポイントの役割を果たします。
mock.js	アプリビルダーの環境内でアプリの表示をプレビューしたり、UIフローをテストしたりするために使用するモックデータが含まれているファイル。
components	アプリのインタラクティブなユーザーインターフェイスと構造を定義するReactコンポーネントが含まれているフォルダ。
styles	一貫した外観と操作感を確保するためのスタイルシートが含まれているフォルダ。
utils	アプリ全体で使用されるヘルパー関数やユーティリティコードが含まれているフォルダ。これらの関数によって、日付のフォーマットやデータのフィルタリングなどのタスクが実行されます。

アプリのコード構造を熟知していれば、問題をより効率的に特定し、修正することができます。具体的には以下のことができます。

blueprintとchangelogファイルを使用して、時系列で変更を追跡できます。
何かがうまく機能しない場合でも、どこを確認すべきかがわかるため、問題を簡単に見つけて修正できます。
スタイル、モックデータ、新機能を安全に試せます。

毎日コードを書かない場合でも、構造を理解しておけば、アプリの構築、改良、保守を確実に行うことができます。

コードの詳細については、Zendesk開発者ドキュメントの「Apps」セクションをご覧ください。

上部には以下の項目があります。

オプションメニュー：縦並び3点ドットのアイコンをクリックして、フィードバックを送信したり、会話をJSONファイルとしてダウンロードしたりできます。ダウンロードした会話は、トラブルシューティングの際に特に役立ちます。ユーザーが解決できないエラーに遭遇した場合、チームの誰もが会話の詳しい内容をすべて確認できるためです。また、ヘルプセンターの「プロンプト作成ガイドライン」の記事にアクセスして、要件をアプリビルダーに明確に伝えるための戦略や作成例を確認することもできます。
生成されたアプリ：メニューでさまざまなバージョンのアプリを選択してプレビューができます。これにより、特定のバージョンを確認したり、変更点を比較したり、必要に応じて以前の機能に戻したりすることができます。
テスト：クリックしてZendesk Support内でアプリを表示し、操作することができます。このアプリのテストでは、Zendeskアカウントの実際のデータを使用して、その機能を試したり評価したりできます。アプリのテスト中に行った更新や加えた変更は、実際のアカウントデータに反映されます。チーム全体にデプロイする前に、アプリが意図したとおりに動作することを必ず確認してください。テスト中にエラーが発生した場合、公開しても自動的に解決されるわけではありません。アプリの公開は、Zendeskアカウントでアプリを利用可能にするだけであり、エラーを修正するものではありません。公開後にアプリが期待通りに動作するように、テスト中にすべての問題を解決してください。
公開：アプリの公開準備が整ったら、「公開」をクリックします。これによりアプリがインストールされ、エージェントが利用できるようになります。

アプリのカスタムアイコンの選択

アプリのアイコンをカスタムアイコンにすると、アプリを識別しやすくなります。ブランドやワークフローに合わせてアイコンの表示をカスタマイズできます。ZendeskのGardenアイコンライブラリからアイコンを選択して、アプリのアイコンをカスタマイズできます。アプリが置かれたそれぞれの場所で、アプリビルダーは、必要に応じてSVGアイコンのPNGバージョンを生成することで、アイコンが正しく表示されるようにします。

アプリのカスタムアイコンを選択するには

「設定」タブをクリックします。
アプリの名前を入力します。
名前を入力しない場合、アプリビルダーは会話の内容やプロンプトの入力に基づいて自動的に名前を生成します。
厳選されたGardenのアイコンと背景色のコレクションを閲覧します。アイコンまたは色の組み合わせをクリックして、アプリでの表示をプレビューで確認できます。
カスタマイズが完了したら、「保存」をクリックします。

公開すると、選択したアプリ名、アイコン、背景色がZendesk Supportに表示されます。カスタムアイコンを選択しない場合は、デフォルトのプレースホルダアイコンが使用されます。

設定の変更はアプリビルダーに保存されるため、次回同じアプリを開いた際には、変更を加えたバージョン以降の最新の名前とアイコンが表示されます。

バージョン管理

アプリビルダーは、アプリの構築や改良の過程で自動的にバージョンを管理するため、さまざまな試行や変更の確認、元の状態への復元が簡単に行えます。

更新を行ったり、以前のバージョンに戻したりするたびに、アプリビルダーは新しいバージョンを作成し、そのタイムスタンプを記録します。

新しいバージョンが作成されると、会話履歴にバージョンの詳細情報が表示されます。「復元」をクリックすることで、プレビューのアプリとコードを以前のいずれかの状態に戻すことができます。復元では常に新しいバージョンが生成されるため、データが失われることはありません。

また、「プレビュー」または「コード」タブの「生成されたアプリ」プルダウンメニューから、以前のバージョンを選択することもできます。

アプリをインストールして管理する

アプリをインストールして管理するには

カスタマイズしたアプリに問題がなければ、画面右上の「公開」をクリックします。
Zendeskの特定のロール（管理者、エージェントなど）やユーザーのグループを選択して、このアプリへのアクセス権を付与するユーザーを設定するよう求められます。この設定で、ロールやグループに基づいてアプリへのアクセスを制限することができます。たとえば、アプリの使用を管理者のみに制限したり、特定のユーザーグループに限定したりできます。
アプリビルダーで作成されたアプリの使用に関するサービス免責事項に同意します。
「同意して公開」をクリックするとインストールプロセスが開始されます。アプリのインストールが完了するとアプリビルダーから通知が送られてきます。
権限の変更やアプリの詳細な管理を行うには、「アプリを管理」をクリックするか、アプリ >「Zendesk Supportアプリ」を選択します。
詳細については、「インストール済みアプリの管理」を参照してください。

メモ：アプリをアカウント内の異なるZendeskインスタンス間で自動的に移動させることはできません。アプリを別のインスタンスで使用したい場合は、アプリコードを手動でダウンロードし、新しいインスタンスにアップロードする必要があります。

プライベートシステムおよびサードパーティプラットフォームと統合する

アプリビルダーでは、接続の設定と認証方法の手順をステップ・バイ・ステップで案内することで、アプリを社内のデータソースや外部のサードパーティ製プラットフォームに簡単に接続できます。

社内サービスや外部サービスと連携させるには、通常、APIエンドポイントと認証情報が必要です。アプリビルダーは、主に2種類の認証方式をサポートしています。

APIキー認証：認証情報としてAPIキーを直接指定することで、外部APIにアクセスする権限がアプリに許可されます。このキーは、APIの使用が許可されていることを証明するものです。APIキーはすばやく簡単に使用できるため、社内システムや、APIを管理している場合に最適です。
OAuth 2.0認証：APIキーを入力する代わりに、OAuth 2.0がアプリと外部サービス間の安全な接続を確立します。この方法は、APIキーを直接扱う必要がなく、きめ細かな権限設定も可能なため、より安全です。この方法は、ユーザーがアプリに対して自身のデータへのアクセスを明示的に許可する必要があるサードパーティ製サービスには最適です。

アプリビルダーは、通常、AIを活用したWeb検索を通じてサードパーティ製システムの要件を調査した後などに認証設定が必要になった場合、適切な認証設定パネルを自動的に表示します。認証設定パネルは、「テスト」または「公開」をクリックしたときにのみ表示されます。

詳細については、「アプリビルダーでのAPI接続のセキュリティ確保」を参照してください。

APIキーの使用

APIキーによる接続を作成する際には、HTTPヘッダー名を指定する必要があります。この接続を使用してAPIコールを実行すると、Zendeskはこのヘッダーの値としてAPIキーを渡します。

APIキー認証の設定手順は、作成するインテグレーションによって異なります。以下に、一般的な例と手順の説明を示します。

「ドメイン」に、アカウントのベースURL（例：testdomain）を入力します
プロジェクトキーを入力します。これは、このアプリが接続するプロジェクトを識別するための一意のキーです（例：HR）。
「続行」をクリックします。
「テスト」をクリックします。
「次へ」をクリックします。
「許可されたドメイン」には、この接続を許可する完全なドメインを入力します（例：testdomain.atlassian.net）。
APIトークンを入力します。これは、サービスへの接続を認証するために使用される安全な認証情報です。
「インテグレーションの作成&アプリのテスト」をクリックします。

OAuth 2.0の使用

アプリビルダーは、サードパーティ製および社内APIに安全に接続できるよう、業界標準のOAuth 2.0プロトコルをサポートしています。これにより、静的な認証情報を共有する代わりに、トークンを用いた認証フローを使用して、外部システムや自社のAPIデータにアクセスするアプリを安全に構築することができます。

OAuth 2.0認証タイプのコネクションを作成する前に、OAuthクライアントを設定する必要があります。OAuthクライアントを設定する際には、外部システムのOAuth設定インターフェイスまたは管理ポータルで提供されるクライアントID、クライアントシークレット、認証URL、トークンURL、およびスコープが必要です。これらの認証情報は、クライアントアプリケーション（Zendeskなど）を外部システムに登録する際に生成されます。正確な手順は外部サービスによって異なります。アプリビルダーは、外部システムにOAuthクライアントを作成する設定手順を提供しようとします。ただし、アプリビルダーに必要な詳細情報が不足している場合、手順が提供されないことがあります。

OAuthを必要とするインテグレーションを作成するには、2つの方法があります。

OAuthを明示的に要求する：インテグレーションがOAuthを必要とすることが分かっている場合は、アプリビルダーへのプロンプトでこれを直接指定できます。たとえば、「GoogleスプレッドシートからZendeskチケットにリンクを追加できるアプリを作成し、利用可能なGoogleスプレッドシートのリストが表示されるようにしてください。Googleへの接続にはOAuthを使用してください」というように指示します。「OAuthを使用する」といった要件を含めることで、アプリビルダーに、正しいOAuthフローを使用してアプリを外部プラットフォームに接続する手順をステップ・バイ・ステップでガイドさせることができます。
OAuth要件の自動検出：認証を開始するために、認証方式の専門家である必要はありません。「Googleに接続する」など、希望する機能を記述すれば、プロンプトに明示的に指示しなくても、アプリビルダーはOAuthが必要なことを認識します。システムが、必要な認証手順を順を追って案内します。

OAuthを使用する生成済みアプリの「テスト」をクリックする場合

OAuthクライアントのコールバックURLをコピーし、安全な場所に保存します。サードパーティ製のOAuthプロバイダーシステムでOAuthクライアントを作成する際には、このURLをリダイレクトURIとして使用する必要があります。
認証タイプとしてOAuthが自動的に選択されます。このオプションは無効にされており、変更することはできません。
接続に許可するドメインを入力します。作成した接続の許可されたドメインは、あとから変更することはできません。
クライアントIDを入力します。これは、クライアントのユーザー名のように、OAuthクライアントに割り当てられる一意の識別子です。
クライアントシークレットを入力します。これは、OAuthクライアントの登録の際に発行される秘密鍵です。
アクセストークンURLを入力します。このURLは、アクセストークンを受け取るために使用するURLです。
認証URLを入力します。これは、アプリケーションにアカウントへのアクセスを許可するためのURLです。
上記のフィールドのほとんどについて、アプリビルダーが提案する値が事前入力されます。ただし、必ず内容を確認し、入力されている情報が正しいことを確認してください。
デフォルトのスコープをスペース区切りで入力します。スコープとは、ユーザーに代わってクライアントアプリケーションがアクセスできる対象を表す権限です。
「次へ」をクリックします。
「グラントタイプ」フィールドに、認証コードを入力します。OAuthのグラントタイプによって、アプリによる認証の方法が決まります。
（オプション）「オフラインアクセスを許可」を選択すると、リフレッシュトークンをリクエストしたり、ユーザーがオフラインの間のアクセスを維持したりできます。
（オプション）OAuth URLのサブドメインを入力します。必要に応じて、OAuthプロバイダーのカスタムサブドメインを入力します。該当するものがない場合は空欄のままにしておきます。
「接続」をクリックし、アカウントを選択します。
アプリビルダーは、アカウントの選択とアクセス許可を行えるよう、サードパーティのOAuthプロバイダーのページへリダイレクトします。
接続IDをコピーします。アプリの設定や認証済みリクエストを行う際に、このOAuth接続を参照するために必要になります。
「続行」をクリックします。

次のビデオでは、アプリのテストを含むOAuthフローの例を紹介しています。

次のビデオでは、アプリの公開を含むOAuthフローの例を紹介しています。

ガイドに従ったインテグレーション

APIキーやOAuthなどの認証を必要とするプライベートサービスやサードパーティのサービスに接続する場合、アプリビルダーのAIが会話内のプロンプトを分析し、必要な接続情報を特定します。

アプリビルダーは関連する認証設定を表示し、指示に含まれる必要な情報を自動的に取得します。

さらに詳細な情報が必要な場合、アプリビルダーは必要な認証情報や設定をプロンプトで質問し、接続設定をステップ・バイ・ステップでガイドします。

社内システムとのインテグレーション

プライベートシステムまたは社内システムに接続するには

社内ドキュメントまたは開発チームから、APIエンドポイントと認証方法（APIキーやOAuth認証情報の必要性など）に関する情報を入手します。
複雑なインテグレーションを行う場合は、必要なすべての認証情報（APIキー、OAuthトークン）を収集し、アプリで使用する入力および出力データの形式を定義します。
接続の設定準備が整ったら、収集した情報をアプリビルダーに入力します。残りのステップが案内されます。アプリビルダーはユーザーの社内システムについて詳しくないため、これらのシステムに関する関連ドキュメントや詳細情報を提供することで初めてユーザーへの支援が可能となります。

インテグレーションの設定が完了したら、アプリビルダーの「テスト」をクリックし、本番のZendesk環境にデプロイする前にインテグレーションの機能が正常に動作するか確認してください。

アプリとサードパーティ製プラットフォームとのインテグレーション

アプリビルダーを使用すると、Jira、Slack、Google、Calendly、Workdayなど、公開APIを備えているあらゆるサードパーティ製アプリケーションとの間で、データの表示や操作を行うアプリケーションを作成できます。たとえば、Googleスプレッドシートとのインテグレーションを構築すれば、エージェントはZendesk内で、顧客レコード、チケットログ、在庫リスト、ワークフローの進捗状況をすばやく確認または更新できるようになります。このアプリは、特定のスプレッドシートやデータ範囲のリアルタイムデータを表示できるほか、エージェントがZendeskのインターフェイスから直接、新しいエントリの追加、セルの値の更新、古いレコードのアーカイブを行うことも可能です。アクションが実行されるたびに、アプリはアクションが成功したかどうか、またインテグレーションに問題があったかどうかをエージェントに報告します。

トラブルシューティング

アプリビルダーでは、発生したエラーによっては、解決するために追加のコンテキストや詳細情報が必要になる場合があります。そのようなエラーの例としては、以下のようなものがあります。

プレビューを読み込めません。
アプリの生成またはインストールができません。
社内のシステムやサードパーティのプラットフォームとのインテグレーションに失敗しました。

アプリビルダーで問題が発生した場合、自動的に解決を試みます。解決できない場合は、エラーメッセージが表示されます。「エラーの詳細」をクリックすると、問題に関する詳しい情報を確認できます。

アプリビルダーが問題を診断および修正できるよう、会話の中で明確かつ具体的な詳細情報を提供してください。これには、説明、認証情報、またはエラーに関連する不足しているコンテキストなどが含まれます。これらの情報から問題を深く理解して、AIは問題の解決を試みるか、追加の詳細情報を求めます。

たとえば、期待される出力が特定のデータ形式やアプリからの特定の応答であったにもかかわらず、実際の出力が期待したものでなかった場合、こうした相違点を詳しくAIに説明することで、アプリビルダーは効果的にトラブルシューティングを行い、適切な解決策を提案できるようになります。フィードバックが正確で詳細であればあるほど、AIはそのやりとりから多くのことを学習し、将来のシナリオにおける回答を改善することができます。

Zendeskインスタンスで実際のデータを使用してアプリをテストする場合（レコードの取得や更新、サードパーティ製アプリとのインテグレーションなど）、プレビューモードでダミーデータを使用している場合には表示されないエラーが発生することがあります。コードのコンパイルに問題がありプレビューが読み込まれない場合を除き、ほとんどのアプリは「プレビュー」タブでは正常に機能しているように見えます。Guardrail通知による警告は、実際のデータを使用したテスト中にそのようなエラーが発生した場合に行われます。エラーが発生した場合は、詳細をコピーして会話に貼り付けてください。これにより、アプリビルダーが問題を分析し、解決を支援できるようになります。

発生する可能性のある一般的なエラーコードを以下に示します。

401：認証エラー。要求されたリソースにアクセスするために必要な権限をユーザーが持っていないことを示します。
403：アクセス拒否エラー。アプリビルダーがブラウザで開いたままの状態である間に、ユーザーのセッションが期限切れとなり、管理センターからログアウトされた場合に発生します。また、インテグレーションの失敗によっても発生することがあります。
404：ページが見つかりませんエラー。URLが破損しているか間違っていることを示しています。また、リクエストされたAPIパスが間違っているか、利用できないことを示す場合もあります。
431：リクエストヘッダーフィールドが大きすぎます。通常、一連のプロンプトが長く続いた後に発生します。解決するには、ブラウザでZendeskアプリのキャッシュとクッキーを削除してみてください。
503：サービス利用不可エラー。サーバーが受信したリクエストが多すぎて、リソース制限を超過した場合に発生します。また、サーバーがメンテナンスや更新のために停止している場合にも発生することがあります。

免責事項とメンテナンス

アプリビルダーで作成したアプリは、Zendeskのサービスとはみなされません。アプリが意図したとおりに機能することの確認および継続的なメンテナンスは、お客様の責任となります。Zendeskは、アプリビルダーで構築されたアプリの機能、サポート、または継続的なメンテナンスを保証するものではありません。

制限事項

アプリビルダーには現在、以下の制限があります。

プランによるアカウントあたりの会話数の上限：
- Suite ProfessionalおよびSupport Professional：最大5件のアプリ会話
- Suite EnterpriseおよびSupport Enterprise：最大10件のアプリ会話
- Suite Enterprise Plus：最大20件のアプリ会話
メモ：会話とは、AIと協力しながらアプリのアイデアを計画、改良、解決するためのチャットまたは一連のプロンプトのことです。作成する新しいアプリごとに、新しい会話を開始してください。すべての会話がアプリの公開につながるわけではありません。
アプリとは、会話から公開する完成品のことです。公開したアプリはZendeskアカウントにインストールされ、エージェントや管理者が使用できるようになります。

会話数の制限は、同時進行できるビルドの数にのみ適用されます。公開およびデプロイできるアプリの数は無制限です。公開するアプリの数に上限はなく、同時進行できるアプリ会話の数にのみ制限があります。
アプリ会話の削除は、公開済みのアプリ自体を削除するものではありません。アプリはZendesk内で引き続き利用可能であり、エージェントや管理者が使用できます。ただし、会話が削除されると、そのアプリを編集または更新することはできなくなります。さらに変更を加えるには、新しい会話を作成し、新しいバージョンのアプリを作成する必要があります。
アプリビルダーへのアクセス権を持つ対象となるすべてのお客様には、約3,600回のプロンプトが無料で提供されます。この制限の数値は概算です。詳細については、次の項目をご覧ください。この制限に達した場合、アプリビルダーにはバナー通知が表示され、資格に応じて最大約7,200回まで一時的に増量するリクエストを行うためのリンクが表示されます。リクエストが承認されなかった場合、または上限に達した場合は、アプリビルダーでのアプリ構築を再開するには、2月1日に年間プロンプト数の制限がリセットされるまで待つ必要があります。
許可されるプロンプトの最大数は、各プロンプトの予想される長さと複雑さに基づきます。長いプロンプトを送信すると、それに応じて、送信できるプロンプトの総数が減少します。
アプリビルダーは、プロンプトの使用状況をユーザーインターフェイス上で追跡または表示しません。
アプリビルダーでは現在、入力プロンプトの文字数を50,000文字に制限しており、1つの会話につき最大200メッセージまで許可されます。また、アクションのリクエスト数も、ユーザー一人あたり1分間に6～12件に制限されています。これらの制限は会話単位で適用されます。
OAuthプロバイダーは、アプリごとに1つだけです。同じアプリ内で複数のOAuthサービス（Googleなど）に接続することはできません。
アプリは単一の環境内でのみ構築および使用できます。アプリをサンドボックスから本番環境へ、または環境間で移動することはできないため、別の場所でアプリを使用したい場合は、手動でアプリを再作成する必要があります。
既存のアプリをアプリビルダーにインポートして編集や機能拡張を行うことはできません。新しいアプリの作成、またはアプリビルダーで最初に開始されたアプリでの作業の継続のみが可能です。
新しいアプリを開始する際は、その場所を指定する必要があります。また、会話が開始された後は、この場所を変更することはできません。
各アプリには、1つの場所に関するコードのみを含めることができます。複数の場所で同じ機能を利用したい場合は、場所ごとに別々のバージョンのアプリを構築して管理する必要があります。
アプリビルダー内のアプリは、すべて自然言語のプロンプトを通じて作成および更新されます。現在、画像、デザイン、ドキュメントを入力としてアップロードする機能はサポートされていません。
テスト中にアプリでエラーが発生した場合、アプリビルダーは自動的には解決しません。代わりに、エラーの詳細をコピーし、AIに修正の支援を依頼する必要があります。
完全なページネーションがまだサポートされていないため、会話が長くなるにつれてパフォーマンスの低下を感じる場合があります。
変更履歴ログには、直近10バージョンの情報のみが記録されます。ファイルがあまりに長くなると、完全に追跡されない可能性があるため、アプリのすべての変更履歴が常に表示されるとは限りません。
アプリをダウンロードすると、個別のソースファイルや完全な設定情報ではなく、コンパイル済みのコードが提供されます。そのため、現時点ではアプリビルダーの外部で編集することはできません。
アプリビルダーは、セキュア設定パラメータの入力フィールドのみを生成できます。アプリに追加の（非セキュアな）ユーザー設定可能なパラメータが必要な場合は、アプリのソースコード内でそれらの設定を手動で追加して管理する必要があります。セキュア設定とは、暗号化されエンドユーザーには表示されない値のことです（例：APIキーやシークレット）。非セキュア設定とは、通常の、表示される設定値のことです（例：機能フラグ、ラベル、URL）。
現在、サードパーティ製の pdfjs-dist、tesseract.js、およびチャート作成ライブラリがサポートされています。