*この記事は下記のドキュメントの内容に沿ったものです (間違いがあれば教えてね☆)。
https://developer.twitter.com/en/docs/publisher-tools/amp/overview

AMPページの自動認識 (canonical URL in a Tweet)

Twitter は非 AMP (canonical) な URLがツイートされた際、そのページの metadata に <link rel="amphtml"> element が含まれているかどうかを Crawl 時に自動的に認識します。コンテンツ提供者はこの element を使うことで、同じページコンテンツに対して AMP / 非 AMP ページの両方が存在することを示すことができます。詳細は下記の AMP ドキュメントより。

Make your pages discoverable

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Fast Bird Sighted — example.com</title>
  <!-- AMP に対応したページ URL -->
  <link rel="amphtml" href="https://amp.example.com/amp/news/fast-bird-sighted">
  <!-- … -->
</html>

URL の Crawl 時、Twitter は Twitterbot/1.0 という User-Agent を利用してアクセスを行います。
また、<link rel="amphtml"> で指定される AMP URL ページは valid であることが前提です。

AMP URL はキャッシュされる

上記で触れた Twitter からの Crawl が終わり、そのページに valid な AMP ページが存在することが分かると、Twitterはその AMP URL をツイートされた canonical URL とは別に更に保管します。

モバイルユーザーだけが自動的に AMP URL へ誘導される

ひとたび Twitter が AMP URL をキャッシュすると、モバイルユーザー (iOS/Android) が当該ツイートの URL リンクをクリックした際に、ツイートされた元の canonical URL ではなく自動的にキャッシュされた AMP URL へとアクセスを振り分けるようになります。User-Agent によって判断しており、Twitter Web からリンクをクリックしても AMP URL には誘導されません。

注意点

Promoted Tweet (広告) には対応していません。Organic Tweet に含まれる URL のみが対象です。
モバイルユーザーは Google が持つ AMP の page cache ではなく、<link rel="amphtml"> で指定されている URL に直接アクセスします。

AMP URL が正しくキャッシュされた事を確認するには

通常、URL をツイートするとそのリンクには t.co の短縮リンクが割り当てられます。

$ twurl '/1.1/statuses/lookup.json?id=${tweet_id}' | jq '.[].entities.urls'
[
  {
    "url": "https://t.co/TjNZ7rvLdf",
    "expanded_url": "https://prtimes.jp/main/html/rd/p/000001364.000005179.html",
    "display_url": "prtimes.jp/main/html/rd/p…",
    "indices": [
      10,
      33
    ]
  }
]

上記の例だと、"url": "https://t.co/TjNZ7rvLdf" がそれにあたります。この URL に対して、"?amp=1" という query parameter を付与してアクセスすることで確認が可能です。

$ curl -svo /dev/null -A "iPhone" https://t.co/TjNZ7rvLdf?amp=1 2>&1 | grep 'location:'
< location: https://prtimes.jp/main/html/rd/amp/p/000001364.000005179.html#click=https://t.co/TjNZ7rvLdf

このように、先のstatuses/lookup.json API で確認できる expanded_url とは違う AMP URL がリダイレクトで返ってくることが分かります。これによって AMP URL が Twitter によって正しく Crawl されたことを確認できました。

Analytics

Twitter のこの機能によってモバイルユーザーが AMP URL へ誘導された場合、ユーザーのクライアントは自動的に元の canonical URL に対しても Ping を行います。この時 Twitter からの Ping アクセスであることを示すため、canonical URL へのPing アクセスには __twitter_impression=true という query parameter が自動的に付与されます。

e.g., https://www.example.com/articles/peregrine-falcon-facts?__twitter_impression=true

Ping アクセスへの応答

__twitter_impression=true が query parameter に含まれる Ping アクセスへの応答は、通常 204 - No Content で返されることが推奨されます。200 を返しても問題ありませんが、どちらにせよレスポンスボディなどは無視されるため、パフォーマンス、及びユーザーの bandwidth 節約の観点からも 204 が好ましいとされています。

Social referral parameter の挙動

多くの場合、URL に Analytics 系の追跡パラメーターが付与されていることがあります。例えば、あるユーザーが下記の URL をツイートしたとします。

e.g., https://example.com/news/tracking-swift-migrations?utm_source=twitter&utm_medium=social

この時、URL の中に utm_source=twitter, utm_medium=social といったパラメーターが見て取れます。
モバイルユーザーが AMP URL へ誘導される場合、Twitter は自動的にこれらの canonical URL に付与されていたパラメーターを AMP URL に対しても引き継ぎます。
これにより、AMP ページ側でも amp-analytics コンポーネントなどを使ってパラメーターを取得することが可能です。

Note: Only parameters from the first-hop are included in this way. Parameters appended by subsequent redirects will not be accessible through AMP.

注意点としては、上記で言及されているように first-hop でのパラメーターだけが引き継がれます。canonical URL にアクセスした際に更にリダイレクトを介して最終的なページにたどり着くような構造の場合、その途中のリダイレクトで付与されるパラメーターなどは、AMP URL へのアクセス時には一切引き継がれません。

その他

もしキャッシュ済みの AMP URL が変更しちゃった場合は？

利用している CMS の設定の問題や任意の事情で、公開済みの AMP ページの URL が変更してしまった場合、明示的に Twitter が保持する AMP URL のキャッシュを更新しないとモバイルユーザーは変更前の URL へ誘導されてしまいます。

AMP URL を強制的に更新する場合、Card Validator tool を使って再 Crawl をリクエストします。URL 欄に canonical URL を入力し、Preview Card をクリックします。入力するのは AMP URL ではないことに注意してください。おおよそ5分以内には反映が完了するはずです。

モバイルの Twitter アプリでリンクを開く -> URL をコピー -> AMP URL じゃないじゃん！！

ちょっと分かりにくい説明なのですが、現状の仕様では、仮にモバイルユーザーが公式クライアントからリンクをクリックし、この機能によって自動的に AMP URL へ正しく誘導されたとしても、ユーザーがそのウィンドウで URL をコピーする操作を行った場合クリップボードには canonical URL が返されるようになっています。
ユーザーが URL をシェアしようとした時には元の canonical URL が優先される、という仕組みのようです。