Linq の iMessage アプリが支払いやチケット購入をメッセージ内で可能に

Linq 開発者向けに、iMessage アプリの構築が可能になりました。これは iMessage の会話内だけで動作するインタラクティブなミニアプリです。 ユーザーは、このアプリ内でショッピングやゲーム、フライト予約、決済を行うことができます。外部ブラウザへ遷移する必要もなければ、「アプリで完了するにはこちらをタップ」といった手動操作も不要です。 従来、エージェントが利用できた主な API の選択肢はリンクを送信することでした。ユーザーはそのリンクをクリックして別の場所へ移動しなければなりませんでした。iMessage アプリはこの「手渡し」のステップをなくします。 要約すると、Linq の新しい `imessage_app` パーツにより、iMessage スレッド内でタップ可能なインタラクティブなカードが直接レンダリングされます。1 つのカードでゲーム、決済、チケット、フライト、音楽、デートといったフルワークフローを処理可能です。また、`/messages/{id}/update` を介してカードはインプレースで更新され、状態変化に応じて同じバブル内で再描画が行われます。 インタラクティブな機能の有無はフラグで切り替えられ、ライブ体験とキャプションのみの静的レイアウトを区別します。なお、これは iMessage に限定された機能であり、SMS や RCS へのフォールバックはありません。また、リッチな表示にはユーザー側でのアプリインストールが必要です。 iMessage アプリとは、タップするとその場でインタラクティブな体験が開かれるカードのことです。このカードが、バブル内におけるあなたのアプリの姿となります。 技術的には、これは `type: "imessage_app"` という新しいメッセージパーツです。既存のテキスト、メディア、リンクのパーツに代わるものです。インストール済みの Messages 拡張機能が、指定した URL からリッチコンテンツを描画します。 Linq はこの API を提供するメッセージインフラスタートアップです。同社のプラットフォームでは、AI エージェントが iMessage、RCS、SMS を通じてユーザーとメッセージを送受信できます。 仕組みの詳細については、最初のカードが正しくレンダリングされるかどうかを決定するいくつかの要素があります。 カードの表示を決定する鍵となるのは、アプリの識別子です。アプリオブジェクトには team_id と bundle_id が含まれており、これらのフィールドが Messages にどの拡張機能でカードを描画するかを伝えます。team_id は、10 文字の大文字からなるアプリ固有の識別子です。通常は、自社のアプリのこの情報を指定します。 ここで注意すべき失敗パターンがあります。認識されない識別子は、エラーを吐くことなく静かにプレーンテキストとして表示されてしまいます。もし team_id と bundle_id がインストール済みの拡張機能と一致しない場合、カードはキャプションにフォールバックします。エラーは発生しません。 キャプションの制御権はあなたにあり、画像の描画はアプリ側で行われます。レイアウトオブジェクトには、カード上に描画されるテキストが格納されます。画像フィールドは存在せず、写真やアイコン、インタラクティブな UI はすべて拡張機能から提供されます。 レイアウトフィールドの詳細: - caption: 左上に配置され、太字のプライマリラベルとして表示されます。 - subcaption: キャプションの下、左側に配置されます。 - trailing_caption: 右上に配置されます。 - trailing_subcaption: trailing_caption の下、右側に配置されます。 少なくとも一つのフィールドは設定する必要があります。そうでないとカードは空のバブルとして描画されてしまいます。Messages は URL を非構造的な文字列として扱うため、URL を変更するとカードに表示される内容も変わります。 インタラクティブフラグが、ライブ表示と静止画表示を切り替えます。デフォルト値は true です。true に設定すると、アプリをインストールしている受信者はライブカードを表示します。false に設定すれば、常に静的なレイアウトカードを表示させることができます。 インストール状態とこのフラグの組み合わせによって結果が決まります。考えられるケースは以下の 3 つです: - アプリをインストールしており、インタラクティブが true の場合 → 拡張機能が URL からリッチカードを描画します。 - アプリをインストールしており、インタラクティブが false の場合 → 受信者は静的なレイアウトカードを見ます。 アプリが未インストールの場合、受信者はレイアウトのキャプションが表示されます。"app_store_id" を設定すると、アプリの入手ボタンが表示されるようになります。 実装：カードの送信と更新 「チャットを作成」でカードを送信するか、既存のチャットに「メッセージを送信」して投稿します。 コピー コピー済み 別のブラウザを使用 curl -X POST https://api.linqapp.com/api/partner/v3/chats \ -H "Authorization: Bearer $LINQ_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "from": "+12052535597", "to": ["+12052532136"], "message": { "parts": [ { "type": "imessage_app", "app": { "name": "Example App", "team_id": "A1B2C3D4E5", "bundle_id": "com.example.app.MessageExtension" }, "url": "https://app.example.com/card?id=abc123", "fallback_text": "Open in Example App", "layout": { "caption": "Example App", "subcaption": "You said: hello" } } ] } }' 更新処理が最も重要なプリミティブです。配信されたカードは、元のメッセージを参照することでその場で置き換えることができます。これにより、ゲームの動きで盤面を再描画するといったことが可能になります。 コピー コピー済み 別のブラウザを使用 curl -X POST https://api.linqapp.com/api/partner/v3/messages/{messageId}/update \ -H "Authorization: Bearer $LINQ_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "url": "https://app.example.com/card?game=7f3a&move=2", "fallback_text": "Score update", "layout": { "caption": "Score: 2 - 1" } }' 更新にはいくつかのルールが適用されます。変更できるのは url、fallback_text、interactive、layout のみです。アプリのアイデンティティはカードの有効期間中は固定されます。また、カードはすでに配信済みである必要があります。 送信した imessage_app カードのみを更新できます。受信したカードの更新はできず、その場合は 400 エラーが返されます。409 エラーはカードがまだ配信されていないことを意味します。message.delivered ウェブフックを受信してから再試行してください。 各更新は、独自の ID を持つ新しいメッセージとして配信されます。interactive フラグは継承されないため、毎回明示的に指定する必要があります。再度更新する際は、新しく生成されたメッセージ ID を参照してください。 また、カードの受信も可能です。受信したメッセージには message.received ウェブフックを通じて imessage_app パートが含まれます。 ## 何ができるか Linq はこれらを固定されたメニューではなく、例として提示しています。以下のインタラクティブデモ（Marktechpost 作成）で実際に試してみてください。 - **ゲーム**: 手番を送信して盤面を再描画します。ライブマッチは、一つのバブルに対する一連の更新シーケンスとして実現されます。 - **決済**: チェックアウトや支払いリクエストをカードとして送信します。受信側はリダイレクトなしで完了できます。 - **チケット**: カードの状態を「参加する／しない」から、その場で確認済みチケットへと変更できます。 - **飛行機予約**: 運賃を表示し、ユーザーに座席を選んでもらった後、カードを搭乗券として更新します。 - **音楽**: 曲を配置して、ユーザーがその場で再生できるようにします。カードはリンクではなくプレイヤーそのものです。 - **デート**: ユーザーがプロフィールをスワイプしてマッチングを確認できる機能を、すでに会話をしている相手との間で提供できます。 （以下はデモ表示用のスクリプトです） iMessage アプリとその他のメッセージパーツの比較 imessage_app パーツは、到達範囲を犠牲にしてインタラクション性を獲得します。このトレードオフを表にまとめました。 | 機能 | imessage_app | テキスト | メディア | リッチリンク | | :--- | :---: | :---: | :---: | :---: | | バブル内でのインタラクティブ性 | ○ | × | × | × | | その場での更新 | ○（/update 経由） | × | × | × | | 描画元 | Your Messages エクステンション | メッセージ | メッセージ | メッセージ | | アプリ未インストール時に表示 | キャプションのみ | 常に表示 | 常に表示 | 常に表示 | | SMS または RCS へのフォールバック | × | ○ | ○ | ○ | | 他のパーツとの併用 | ×（唯一のパーツである必要がある） | ○ | ○ | ○ | 誰にでも画像を見せたい場合は、メディアまたはリッチリンクを使用してください。それらはそれぞれ異なる目的のための別々のツールです。 強みと弱み 強み その場での更新機能により、単なるカードから状態を保持する多段階のワークフローへと進化します。 インタラクティブなワークフローはスレッド内で完結し、ブラウザへのリダイレクトが発生しません。 API の表面積が小さく、送受信や更新、ウェブフックのみで構成されます。 キャプション機能により、アプリをインストールしていない相手にも、予測可能で滑らかなフォールバックを提供します。 弱み iMessage に限定され、SMS や RCS へのフォールバックがないため、グローバルな到達範囲が制限されます。 リッチレンダリングは、相手がメッセージエクステンションをインストールしているかどうかに依存します。 team_id と bundle_id のエラー発生時は、警告音や目立つ表示ではなく、静かな失敗モードとなります。 Apple のプラットフォーム上に構築されているため、一般的なプラットフォームリスクを伴います。 技術的な詳細については、こちらをご覧ください。また、Twitter でフォローしていただくと幸いです。15 万人以上のメンバーが参加する ML サブレディットにもぜひご参加ください。さらに、ニュースレターへの登録も忘れずに。 Telegram をご利用中ですか？今なら Telegram でもコミュニティに参加できます。

Linq の iMessage アプリが支払いやチケット購入をメッセージ内で可能に

背景や根拠まで確認しますか？

調べる

選ぶ

サイト