Linq の iMessage アプリが支払いやチケット購入をメッセージ内で可能に
本文の状態
日本語全文を表示中
詳細モードで約10分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
MarkTechPost
Linq が提供する新機能「imessage_app」により、開発者は iMessage 内で動作するインタラクティブなミニアプリを作成できるようになった。これによりユーザーはブラウザを離れることなく、決済やゲーム、飛行機予約などを直接メッセージ画面で完結できる。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
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 developers can now build iMessage Apps. These are interactive mini-apps that run inside a iMessages conversation.
A user can shop, play a game, book a flight, or pay. None of it requires leaving the iMessage thread. There is no deep link to an external browser. There is no ‘tap here to finish in the app.’
Previously, an agent’s main API option was to send a link. The user then had to follow it somewhere else. iMessage Apps remove that handoff.
TL;DR
Linq’s new imessage_app part renders tappable, interactive cards directly inside an iMessage thread.
One card handles full workflows: games, payments, tickets, flights, music, and dating.
Cards update in place via /messages/{id}/update, so state changes redraw the same bubble.
An interactive flag toggles the live experience versus a static caption-only layout card.
It’s iMessage-only with no SMS/RCS fallback, and rich rendering needs your app installed.
iMessage Apps
An iMessage App is a tappable card that opens an interactive experience in place. The card becomes your app inside the bubble.
Technically, it is a new message part with type: "imessage_app". This replaces the text, media, and link parts you already use. An installed Messages extension draws the rich content from a url you provide.
Linq is the messaging-infrastructure startup behind the API. Its platform lets AI agents message users over iMessage, RCS, and SMS.
How It Works
A few details decide whether your first card renders correctly.
The app identity is the rendering key: The app object carries team_id and bundle_id. Those fields tell Messages which extension renders the card. team_id is the app’s 10-character uppercase identifier. You usually pass your own app’s identity.
There is one common failure mode here. An unrecognized identity silently renders as plain text. If team_id and bundle_id do not match an installed extension, the card falls back to your caption. No error is thrown.
You control captions; the app controls the image: The layout object holds the text drawn on the card. There is no image field. The photo, icon, and interactive UI come from your extension.
layout fieldPosition
captiontop-left, bold primary label
subcaptionleft, below caption
trailing_captiontop-right
trailing_subcaptionright, below trailing_caption
At least one field must be set. Otherwise the card renders as an empty bubble. Messages treats the url as opaque, so changing the url changes what the card shows.
An interactive flag controls live versus static. It defaults to true. With true, recipients who have your app see the live card. Set it to false to always show the static layout card instead.
Install state and the flag together decide the result. Three outcomes are possible:
Has your app, interactive: true → the extension renders the rich card from your url.
Has your app, interactive: false → the recipient sees the static layout card.
No app → the recipient sees your layout captions. Set app_store_id to add a Get the app affordance.
Implementation: Sending and Updating a Card
Send a card with Create Chat, or post it into an existing chat with Send Message.
Copy CodeCopiedUse a different Browser
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"
}
}
]
}
}'
Updates are the interesting primitive. A delivered card can be replaced in place by referencing the original message. This is how a game move redraws a board.
Copy CodeCopiedUse a different Browser
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" }
}'
A few rules govern updates. Only url, fallback_text, interactive, and layout can change. The app identity stays fixed for the card’s life. The card must already be delivered.
You can update only an imessage_app card you sent. Inbound cards cannot be updated, and the call returns 400. A 409 means the card is not delivered yet. Retry after the message.delivered webhook.
Each update is delivered as a new message with its own ID. The interactive flag is not inherited, so resend it each time. To update again, reference the new message ID.
You can also receive cards. Inbound messages include an imessage_app part in the message.received webhook.
What You Can Build
Linq frames these as examples, not a fixed menu. Try each one yourself in the interactive demo below (created by Marktechpost).
Games: Send a move and redraw the board. A live match becomes a sequence of updates to one bubble.
Payments: Send a checkout or request-to-pay as a card. The recipient completes it without a redirect.
Tickets: A card can move from “Going / Not going” to a confirmed ticket in place.
Flight booking: Surface a fare, let the user pick a seat, then update the card to a boarding pass.
Music. Drop a track and let people play it inline. The card is a player, not a link.
Dating: Let users swipe profiles and explore matches where they already talk.
iMessage Apps vs Other Message Parts
The imessage_app part trades reach for interactivity. This table shows the tradeoff:
Capabilityimessage_apptextmedialink (rich link)
Interactive in the bubbleYesNoNoNo
Updates in placeYes, via /updateNoNoNo
Drawn byYour Messages extensionMessagesMessagesMessages
Visible without your appCaptions onlyAlwaysAlwaysAlways
Falls back to SMS or RCSNoYesYesYes
Combine with other partsNo, must be the only partYesYesYes
If you need an image everyone can see, use media or a rich link. That is a different tool for a different job.
Strengths and Weaknesses
Strengths
In-place updates turn one card into a stateful, multi-step workflow.
The interactive workflow runs in the thread, with no browser redirect.
The API surface is small: send, update, receive, plus webhooks.
Captions give a graceful, predictable fallback for recipients without the app.
Weaknesses
iMessage only, with no SMS or RCS fallback, limits global reach.
Rich rendering depends on the recipient installing your Messages extension.
The team_id and bundle_id failure mode is silent, not loud.
It builds on Apple’s platform, which carries the usual platform risk.
Check out the Technical details. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well.
Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us
The post Linq’s iMessage Apps Bring Payments, Tickets, Flights, and Games Into the iMessage Bubble Through the imessage_app Part appeared first on MarkTechPost.
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み