Linq の iMessage アプリが支払いやチケット購入をメッセージ内で可能に
Linq が提供する新機能により、AI エージェントが iMessage 内で決済やゲームなどの複雑なワークフローを完結するインタラクティブカードとして展開できるようになり、従来の外部リンク経由の手順が不要となる。
キーポイント
iMessage 内での完全完結型体験の実現
ユーザーが iMessage スレッドから離れることなく、決済、チケット購入、フライト予約、ゲームプレイなどのアクションを完結できるインタラクティブミニアプリ（imessage_app）が利用可能になった。
技術的実装とレンダリングメカニズム
新しいメッセージパートタイプ「imessage_app」を採用し、team_id と bundle_id によってインストールされた拡張機能がカードをレンダリングする仕組みで、URL を変更することで動的にコンテンツを更新できる。
フォールバックと静的表示の制御
アプリが未インストールの場合やフラグ設定により、リッチなインタラクティブ体験ではなく、キャプション付きの静的カードとして表示される柔軟性を持ち、エラーを吐かずにテキストにフォールバックする。
AI エージェントへのインテグレーション
Linq のプラットフォームを通じて AI エージェントが iMessage 経由でユーザーと対話し、複雑なタスクを実行するための基盤としてこの機能が位置づけられている。
カードのリアルタイム更新機能
配信済みのimessage_appカードは、元のメッセージを参照してその場で内容（URL、レイアウトなど）を更新でき、ゲームや決済などのライブ体験を実現します。
更新制限と送信権限
更新可能なフィールドはURL、fallback_text、interactive、layoutに限定され、アプリIDは固定であり、自身が送信したカードのみが更新対象となります。
多様なユースケースの実現
ゲームの盤面更新、決済完了、チケット発行、フライト搭乗券表示など、リダイレクトなしで完結する多彩なアプリ体験を構築できます。
影響分析・編集コメントを表示
影響分析
この技術的進展は、AI エージェントと人間の対話体験を根本から変革するものであり、従来の「リンクを送ってブラウザで開く」という非効率なフローを排除し、チャット内での完結型取引やエンターテインメントを可能にします。特に決済や予約などの信頼性が求められるタスクにおいて、ユーザーの離脱率を下げ、コンバージョン率を劇的に向上させる可能性を秘めています。
編集コメント
AI エージェントの実用化において、ユーザー体験（UX）の断絶を解消するこの機能は、チャットベースのインターフェースが単なる情報提供から「実行プラットフォーム」へと進化するための重要なマイルストーンです。
Linq の開発者は now、iMessage アプリを構築できるようになりました。これらは iMessage の会話内内で動作するインタラクティブなミニアプリです。
ユーザーはショッピングをしたり、ゲームを楽しんだり、フライトを予約したり、支払いを行ったりできます。すべて iMessage スレッドから離れる必要はありません。外部ブラウザへのディープリンクもありません。「アプリで完了するにはここをタップ」という指示も不要です。
以前は、エージェントの主要な API オプションはリンクを送信することでした。ユーザーはそのリンクに従って別の場所へ移動する必要がありました。iMessage アプリはこのハンドオフ（引き継ぎ）を排除します。
TL;DR
Linq の新しい imessage_app パートは、タップ可能なインタラクティブなカードを iMessage スレッド内に直接レンダリングします。
1 つのカードでゲーム、支払い、チケット、フライト、音楽、デートといったフルワークフローを処理できます。
カードは /messages/{id}/update を介してその場で更新されるため、状態の変化が同じバブル（吹き出し）を再描画します。
インタラクティブなフラグにより、ライブ体験とキャプションのみの静的レイアウトを持つカードの切り替えが可能です。
これは iMessage のみで動作し、SMS/RCS へのフォールバックはなく、リッチレンダリングにはアプリのインストールが必要です。
iMessage アプリ
iMessage アプリは、その場でインタラクティブな体験を開くタップ可能なカードです。このカードがバブル内でのあなたのアプリとなります。
技術的には、これは「imessage_app」という型の新しいメッセージパートです。これにより、すでに使用しているテキスト、メディア、リンクのパートが置き換えられます。インストールされた Messages 拡張機能（Messages Extension）が、あなたが提供する URL からリッチコンテンツを描画します。
Linq は API の背後にあるメッセージングインフラストラクチャスタートアップです。そのプラットフォームは、AI エージェントが iMessage、RCS、SMS を通じてユーザーにメッセージを送信することを可能にします。
仕組み
最初のカードが正しくレンダリングされるかどうかを決定するいくつかの詳細があります。
アプリのアイデンティティはレンダリングの鍵となります：アプリオブジェクトには team_id と bundle_id が含まれています。これらのフィールドは、どの拡張機能がカードをレンダリングするかを Messages に伝えます。team_id は、アプリの 10 文字大文字の識別子です。通常は、ご自身のアプリのアイデンティティを渡します。
ここでよくある失敗モードがあります。認識されないアイデンティティは、静かにプレーンテキストとしてレンダリングされます。team_id と bundle_id がインストールされた拡張機能と一致しない場合、カードはキャプションにフォールバックします。エラーは発生しません。
キャプションの制御はあなたが行い、画像の制御はアプリが行います：レイアウトオブジェクトには、カード上に描画されるテキストが保持されます。画像フィールドはありません。写真、アイコン、インタラクティブな UI はすべて拡張機能から提供されます。
layout fieldPosition
caption: 左上、太字の主要ラベル
subcaption: キャプションの下、左側
trailing_caption: 右上
trailing_subcaption: trailing_caption の下、右側
少なくとも 1 つのフィールドを設定する必要があります。そうでないと、カードは空のバブルとしてレンダリングされます。Messages は URL を不透明な値として扱うため、URL を変更するとカードに表示される内容が変化します。
インタラクティブフラグは、ライブ表示と静的表示を制御します。デフォルトは true です。true に設定すると、アプリをお持ちの受信者はライブカードを見ることができます。常に静的レイアウトカードを表示させるには、これを false に設定してください。
インストール状態とこのフラグが組み合わさって結果が決まります。3 つの結果が可能です：
ご自身のアプリを持っており、インタラクティブ：true → 拡張機能が URL からリッチカードをレンダリングします。
ご自身のアプリを持っており、インタラクティブ：false → 受信者は静的レイアウトカードを見ます。
アプリがない場合、受信者はレイアウトのキャプションのみ表示されます。アプリの入手を促す表示を追加するには、app_store_id を設定してください。
実装：カードの送信と更新
Create Chat でカードを送信するか、既存のチャットに Send Message で投稿します。
コードをコピーしました別のブラウザを使用
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" }
}'
必ず JSON 形式で返してください。translation フィールドのみ。他のフィールド (technical_terms 等) は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:
{"translation": "アプリがない場合、受信者はレイアウトのキャプションのみ表示されます。アプリの入手を促す表示を追加するには、app_store_id を設定してください。
実装：カードの送信と更新
Create Chat でカードを送信するか、既存のチャットに Send Message で投稿します。
コードをコピーしました別のブラウザを使用
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 作成）でそれぞれ実際に試してみてください。
ゲーム：手番を送信して盤面を再描画します。ライブマッチは、1 つのバブルに対する一連の更新シーケンスになります。
決済：チェックアウトまたは支払いリクエストをカードとして送信します。受信者はリダイレクトなしで完了できます。
チケット：カードは「参加する/しない」からその場で確認済みチケットへと移行できます。
フライト予約：運賃を表示し、ユーザーに座席を選ばせた後、カードを搭乗券に更新します。
音楽：トラックを配置して、ユーザーがインラインで再生できるようにします。カードはリンクではなくプレイヤーです。
デート：ユーザーがプロフィールをスワイプして、すでに会話している相手とのマッチングを検索できます。
(function(){
function h(e){
if(!e.data||e.data.type!=='mtp-imsg-resize')return;
var f=document.getElementById('mtp-imessage-apps-demo');
if(f&&e.data.height)f.style.height=e.data.height+'px';
}
window.addEventListener('message',h);
})();
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.
技術的な詳細についてはこちらをご覧ください。また、Twitter でフォローしていただくこともお気軽にどうぞ。忘れずに 150k+ML の SubReddit に参加し、ニュースレターも購読してください。待ってください！Telegram をご利用ですか？今なら Telegram でも私たちに参加いただけます。
GitHub リポジトリや Hugging Face ページ、製品リリース、ウェビナーなどのプロモーションを当社と提携して行いたい場合は、こちらからご連絡ください。
本記事「Linq の iMessage アプリが imessage_app を通じて支払い、チケット、フライト、ゲームを iMessage バブル内に取り込む」は、MarkTechPost で最初に公開されました。
原文を表示
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.
(function(){
function h(e){
if(!e.data||e.data.type!=='mtp-imsg-resize')return;
var f=document.getElementById('mtp-imessage-apps-demo');
if(f&&e.data.height)f.style.height=e.data.height+'px';
}
window.addEventListener('message',h);
})();
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日報で今日の重要ニュースをまとめ読み