> For the complete documentation index, see [llms.txt](https://docs-embed.anyflow.jp/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs-embed.anyflow.jp/trial-tour/start-intermediate/step3.md).
# STEP3 | スキーマの共通化
## **概要**
STEP2ではSlackにおけるユーザー一覧取得とメンション付きのメッセージ投稿のソリューションを作成しました。
STEP3では、同じコミュニケーションツールであるTeamsでも同じようにソリューションを作成し、違いを体感してみましょう。
***
## **1. スキーマの共通化について理解する**
STEP3でお伝えしたいことを先にご紹介します。こちらを理解いただければSTEP3を実際に試す必要はありません。
Slackでユーザー一覧を取得しメンション付きのメッセージを送る際にレスポンスで受け取ったデータは、ユーザーIDとメールアドレスでした。
ユーザーIDは同じSlackでもTeamsでも`id` という同じ名称でデータを保持しています。
しかし、メールアドレスはSlackでは`email`、Teamsでは`mail`と異なる名称でデータを保持しています。
また、名前（表示名）に至ってはそれぞれのアプリケーションが、複数のデータを異なる名称で持っています。
このように同じ「ユーザー情報」でもアプリケーションによってフィールド名が異なります。\
アプリごとに異なるデータ構造に対応する開発は、以下の理由で大変です：
* 各アプリのAPI仕様を個別に学習する必要がある
* データ取得ロジックをアプリごとに実装する必要がある
* 新しいアプリを追加するたびに実装コストがかかる
### Request\&Responseトリガーによるデータの正規化
Request\&Responseトリガーのレスポンスペイロード機能を使うと、異なるアプリケーションから取得したデータを統一された形式に変換して返すことができます。
**具体的な実装例**
Slackの場合（入力）
```
{
"id": "U12345",
"email": "user@example.com",
"real_name": "John Doe"
}
```
Teamsの場合（入力）
```
{
"id": "29:12345",
"mail": "user@example.com",
"displayName": "John Doe"
}
```
Response Stepのペイロード設定（統一形式）
```
{ "id": "$=payload.id=$",
"email": "$=payload.email=$", // Slackの場合
"email": "$=payload.mail=$", // Teamsの場合
"name": "$=payload.real_name=$", // Slackの場合
"name": "$=payload.displayName=$" // Teamsの場合
}
```
最終的なレスポンス（どちらのアプリでも同じ形式）
```
{
"id": "...",
"email": "user@example.com",
"name": "John Doe"
}
```
### メリット
* 統一されたインターフェース：呼び出し元はどのアプリからデータが来たかを意識する必要がない
* 開発効率の向上：データを使用する側の実装を1つで済ませられる
* 保守性の向上：新しいアプリを追加する場合、Response Stepのマッピングを追加するだけで済む
* テストの簡素化：統一された形式でテストできるため、テストケースがシンプルになる
Request\&Responseトリガーのレスポンスペイロード機能は、異なるアプリケーションのデータ構造の違いを吸収する「アダプター層」として機能します。これにより、アプリケーションごとの実装の違いを隠蔽し、統一されたインターフェースを提供できるため、開発効率と保守性が向上します。
***
## **2.実際にTeamsでのソリューションを作成する**
Teamsにはチームとチャネルという概念があります。\
チームに所属しているユーザーは複数のチャネルを作成してそれぞれでチャットができます。
このチームとチャネルという概念はSTEP2で使用したSlackにはありません。\
そこで、エンドユーザーを追加して、ウィザードを設定しましょう。
まず、中級STEP2で作成したソリューションを複製したものを開き、ウィザード画面を開いてください。
### **2-1. エンドユーザー変数を設定する**
変数のウィンドウから\[エンドユーザー変数]をクリックします。
追加ボタンを押して、\[チームID]と\[チャネルID]を追加します。※型は`String`です。
すでにあるチャンネルは削除してください。
### **2-2. ウィザードを設定する**
SlackBotの認証は使わないため、ウィザードから解除します。
左下にあるエンドユーザーの設定項目からMicrosoft Teamsをスクリーン1に割り当ててください。
同様にチームIDとチャネルIDもスクリーン1に割り当ててください。
チームIDを選択し、設定を下記に変更してください。
* 入力方法：\[アシスト]
* アシストを選択：\[チーム一覧]
チャネルIDを選択し、設定を下記に変更してください。
* 入力方法：\[アシスト]
* アシストを選択：\[チームのチャネル一覧]
* 参照フィールド：\[チームID]
### 2-3.メンバー一覧を取得する
ソリューション画面に戻ります。
ステップ3に\[+]ボタンから\[アクション]を選択し\[Microsoft Teams]を選択します。
* カスタムアクションを選択します。
{% hint style="info" %}
### カスタムアクションについて
Helpをご確認の上、下記をご覧ください。
{% endhint %}
* カスタムアクション名：任意の名前を付けます。
* HTTPメソッド：`GET`を選択します。
* リクエストパス：`users`と入力します。
* レスポンスタイプ：`json`を選択します。
* レスポンス定義：JSONまたは手動で追加します。下記を参考に追加してください。
{% tabs %}
{% tab title="{}JSONで追加" %}
```
{
"value": [
{
"id": "1",
"mail": "test@anyflow.co.jp"
}
]
}
```
{% endtab %}
{% tab title="手動追加" %}
* 名前「value」、型「Array」で、追加します。
* 名前「element」、型「Object」で、任意項目にするにチェックを入れて追加します。
* 名前「id」、型「String」で、任意項目にするにチェックを入れて追加します。
* 名前「mail」、型「String」で、任意項目にするにチェックを入れて追加します。
* elementをvalueの配下に移動します。同様にidとemailをelement配下に移動させます。
{% endtab %}
{% endtabs %}
ステップ4に\[レスポンス]を追加します。
* 実行ステータス：`成功にする`を選択します。
* レスポンス名：任意の名前を付けます。
* レスポンスペイロードは以下のように設定します。
* リストソース：変数のStep3にある`value` を選択します。
* id：変数のStep3にある`id` を選択します。
* email：変数のStep3にある`mail` を選択します。
### 2-4.Teamsにメッセージを送信する
ステップ2の\[if]から\[else]を設定すると、ステップ5に配置されます。
ステップ6にアクションから\[Teams]を選択し、\[チャネルにメッセージを送信]を選択します。
* チームID：変数からエンドユーザー変数の\[チームID]を選択します。
* チャネルID：変数からエンドユーザー変数の\[チャネルID]を選択します。
* メッセージ本文は下記のように設定します。
* コンテンツタイプ：\[HTML形式]を選択します。
* メッセージ内容：変数からStep1の\[message]を選択します。
* メンションは下記のように設定します。
* ユーザーID：変数からStep1の\[mention\_id]を選択します。
ステップ7に\[レスポンス]を選択します。
* レンポンス名：\[ok]を選択します。
* ペイロード：任意のレスポンスを設定します。今回は\[ok]と入力します。
### **2-5. ソリューションをテストする**
完成したので、テストしましょう。ソリューションの仕組みはSTEP2と同様です。searchでユーザー一覧を取得し、取得したidに対して、メンション付きのメッセージを送信する。という流れです。
テストに成功したら、終了です。
***
## **まとめ**
今回のセクションでは、スキーマの共通化について学ぶことができました。
中級編はこれにて完了です。お疲れ様でした。
次はいよいよ実際に本番に向けてソリューションを構築していきましょう。
### 👉**いよいよ、本番向けソリューションの構築へ**
[トライアルツアーが終わったら](/trial-tour/after-trial-tour.md)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs-embed.anyflow.jp/trial-tour/start-intermediate/step3.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.