X・Bluesky埋め込み修正OSS「FxEmbed」の仕組みと特徴

Discord や Telegram のチャンネルに X（旧 Twitter）や Bluesky の投稿リンクを貼ったとき、動画が再生できない、複数枚の画像のうち 1 枚しか出ない、投票結果や引用元の投稿が消える——こうした状態に遭遇した方は少なくないはずです。情報共有のたびにスクリーンショットを撮り直したり、「リンク先を開いて見てください」と補足したりする運用は、地味に手間が積み重なります。

やりづらいのは、この問題がこちら側のアプリケーションのバグではなく、SNS 側が外部サービスに返すプレビュー用メタデータの仕様に依存している点です。プラットフォーム側の仕様は変わり続けるため、「今は表示されるが、いつまで表示されるか分からない」という不安が残り、恒久的な対処方針を決めづらくなります。

この領域には、SNS のリンクを受け取ってプレビュー用のメタデータを補完し直す「埋め込み修正系」のオープンソースプロジェクトが複数存在します。その中で、X / Twitter と Bluesky の両方を 1 つのコードベースでカバーし、公開 API まで提供しているのが FxEmbed/FxEmbed です。使い始めるときに必要なのは、共有する URL のドメインを数文字書き換えるだけで、アプリのインストールも設定も要りません。

ただし、公開インスタンスに業務のワークフローを乗せるのか、自前でセルフホストするのか、そもそも類似 OSS のどれを選ぶのかは、別途判断が必要になります。本記事では、FxEmbed の仕組み・主要機能・技術構成・公開 API の制約・類似 OSS との違い・セルフホストの要件を、公式ドキュメントと GitHub 上で取得できる情報だけをもとに整理します。動作検証やインストールは行っておらず、記述はすべて公開ドキュメントと GitHub API の取得値に紐づけています。

FxEmbedとは｜X・Blueskyの埋め込みを修正するOSS

FxEmbed は、X / Twitter と Bluesky のリンクを、Discord や Telegram などのプラットフォームでリッチなプレビュー（埋め込み）として表示できるようにするためのオープンソースプロジェクトです。リポジトリの説明文は "Fix X/Twitter and Bluesky embeds! Use multiple images, videos, polls, translations and more on Discord, Telegram and others" とされており、複数画像・動画・投票・翻訳といった、標準の埋め込みでは落ちてしまう要素を補うことが目的に据えられています（FxEmbed/FxEmbed（GitHub））。

プロジェクト全体の解説は FxEmbed 公式ドキュメント（docs.fxembed.com）にまとまっており、Getting Started / API Reference / Self-Hosting の 3 系統で構成されています。

リポジトリの基本情報

GitHub API から取得した 2026 年 10 月時点の値は次のとおりです。スター数・フォーク数は変動するため、最新値は GitHub 上で確認してください。

出典: gh api /repos/FxEmbed/FxEmbed（2026 年 10 月時点の取得値）

ここで確認しておきたいのは最後の行です。FxEmbed は アーカイブされておらず（archived=false）、他リポジトリのフォークでもなく（fork=false）、無効化もされていません（disabled=false）。後述するとおり、この分野には既にアーカイブされた OSS が実在するため、アクティブなメンテナンス下にあることは採用検討を続ける前提条件になります。最終 push が 2026 年 10 月 10 日であることも、更新が止まっていないことの裏付けになります。

FxTwitter / FixupX / FxBluesky の3サービスと1コードベースの関係

FxEmbed を調べ始めると、fxtwitter.com や fixupx.com という名前を先に目にすることが多いはずです。README の見出しが "Home of FxTwitter, FixupX, and FxBluesky" とされているとおり、この 3 つのサービスは FxEmbed という単一のコードベースから提供されています（FxEmbed/FxEmbed（GitHub））。

つまり「FxTwitter は知っていたが FxEmbed は知らなかった」という状態は自然で、ブランド名として露出しているのはサービス側、リポジトリ名として管理されているのが FxEmbed という関係になります。採用検討やセルフホストを考える際は、リポジトリ名の FxEmbed 側を参照先として押さえておくのが確実です。

なお README には、"Twitter, Tweet, and X are trademarks of X Corp. This project is not affiliated in any way with X Corp or Twitter." という免責事項が記載されています。FxEmbed は X Corp とは無関係のサードパーティ実装であり、業務利用時はこの点を前提に自社のポリシーを確認する必要があります。

FxEmbedの使い方｜ドメインのプレフィックスを変える仕組み

FxEmbed の使い方は、共有したい URL のドメインにプレフィックスを足すだけです。ブラウザ拡張のインストールもアカウント登録も不要で、公式ドキュメントの Getting Started にも同じ内容が記載されています（公式ドキュメントの Getting Started）。

twitter.com と bsky.app には fx を、x.com には fixup を付ける、という対応です。パス部分はそのまま流用できるため、既にチャットに貼られたリンクを後から書き換えることもできます。

採用判断の観点として重要なのは、この方式が「試すコストをほぼゼロにしている」ことです。サーバーを立てる必要も、チャットツール側に Bot を導入する必要もなく、1 本のリンクを書き換えれば自分の環境で結果を確認できます。チーム内で合意形成を取る前に挙動を共有できるため、導入検討の初手としてのハードルは低く済みます。

一方で、この手軽さは「公開インスタンス（fxtwitter.com 等）に依存している」ことの裏返しでもあります。業務の定常フローやプロダクトの機能として組み込む場合は、公開インスタンスの可用性と後述するレート制限をどう扱うかを決めておく必要があります。

FxEmbedの主要機能｜動画・複数画像・投票・引用・翻訳

公式ドキュメントが挙げる機能は 4 系統です。それぞれ「標準の埋め込みでは何が足りないのか」と対にして整理します。

実務上の意味合いで言うと、動画・GIF と複数画像は「社内チャットでの情報共有」に直結し、投票結果と引用投稿の表示は「コミュニティ運営で議論の文脈を落とさない」ために効きます。翻訳は多言語のタイムラインを追うチームで価値が出ます。そして公開 API は、Bot や社内ツールに組み込む用途を想定している場合の中心的な機能になります。

機能の裏付けとして、package.json の依存関係には多言語化ライブラリの i18next と i18next-icu が含まれており、翻訳文自体は Crowdin 上のプロジェクトで運用されています。公開ドキュメントと依存構成の両方で翻訳機能が担保されている形です。

複数画像の結合処理については、FxEmbed 本体ではなく別リポジトリの FxEmbed/mosaic が担当していることが README に明記されています。セルフホストする場合、この Mosaic は任意のサービスとして別途立てる構成になるため、「複数画像の結合まで自前環境で再現したいか」は構成を決める際の分岐点になります。

FxEmbedの技術構成｜Cloudflare WorkersとHonoによる実装

自分たちで読めるコードベースか、既存のインフラに乗るのかを判断するために、package.json と README から読み取れる構成を整理します。ここで挙げる内容はいずれもリポジトリ上のファイルで確認できる事実に限定しています。

Cloudflare Worker として動く構成

FxEmbed は Cloudflare Worker として動作することを前提に作られています。デプロイ用の npm スクリプトは wrangler deploy --no-bundle、ローカル実行は wrangler dev --local で、devDependencies には wrangler と @cloudflare/workers-types が含まれています。テストは vitest に加えて @cloudflare/vitest-pool-workers を使い、Workers ランタイム上での実行を前提とした構成になっています。ビルドは esbuild です。

この点は採用判断に大きく影響します。「Node.js のサーバーとして自社の既存環境に相乗りさせる」想定で検討を始めると、前提が合わないまま進んでしまう可能性があります。エッジランタイム前提であることは、セルフホストのインフラ選択を実質的に制約する要素として最初に押さえておきたいところです。

リポジトリ全体は npm workspaces 構成（workspaces: ["packages/*"]）で、@fxembed/atmosphere というサブパッケージを持ちます。言語構成は TypeScript が約 172 万バイトを占め、JavaScript と Dockerfile がわずかに含まれる形です（gh api /repos/FxEmbed/FxEmbed/languages 取得値）。

Hono + zod-openapi による API 定義と OpenAPI 公開

ルーターには hono が採用されています。API のスキーマ定義は @hono/zod-openapi と zod で行われており、これが後述する OpenAPI 仕様の公開（/2/openapi.json）と対応しています。エラートラッキングには @hono/sentry が使われ、HTML のパースには cheerio が入っています。

スキーマ定義から OpenAPI 仕様を生成する構成になっているため、API の形が仕様として機械可読な形で公開されている点は、クライアント側のコード生成を考える際に効いてきます。実際、openapi:atmosphere という npm スクリプトは本番 API の openapi.json から型を生成する処理になっています。

Host ヘッダによるマルチドメイン対応

1 つのコードベースが FxTwitter / FixupX / FxBluesky の 3 ドメインを提供できるのは、リクエストの Host ヘッダでルーティングを切り替える設計になっているためです。README の Docker セクションには、ローカルで特定のドメインの挙動を確認する際の例として次のコマンドが掲載されています。

curl -H "Host: fxtwitter.com" -H "User-Agent: Discordbot/2.0" "http://localhost:8787/user/status/123"

出典: https://github.com/FxEmbed/FxEmbed （README の Docker セクション）

Host に対象ドメインを、User-Agent にクローラー相当の値を指定していることから、「どのドメインとして振る舞うか」と「相手がプレビュー取得のクローラーかブラウザか」の 2 軸で応答を切り替える構造が読み取れます。セルフホストする場合、このドメイン単位のルーティングを自前のドメイン運用にどう対応させるかが設計上の論点になります。

FxEmbedの公開APIとレート制限

Bot や社内ツールに組み込むことを検討している場合、最も実務的な情報はここに集まります。詳細は FxEmbed API Reference に記載されています。

公開 API は 2 系統です。

実装時に押さえておきたい仕様は次の 4 点です。

• 現行エンドポイントはすべて /2/ 配下（API v2）。旧 v1（/:handle/status/:id 形式）は互換性のために動作しますが、新しい機能の一部には対応していません。新規実装では v2 を前提にするのが妥当です
• レスポンスの code フィールドでエラー判定ができる。レスポンスは JSON で返り、HTTP ステータスが 200 の場合でも、全レスポンスに HTTP ステータスと同じ値の code フィールドが含まれます。クライアント側のエラーハンドリングはこのフィールドを見る前提で組めます
• ページングは cursor オブジェクト。一覧系エンドポイントは top / bottom を持つ cursor オブジェクトを返し、次ページの取得には cursor.bottom の値をクエリパラメータ cursor に渡します
• OpenAPI 3.0 仕様が実行時に取得できる。https://api.fxtwitter.com/2/openapi.json と https://api.fxbsky.app/2/openapi.json で公開されており、型生成やクライアント自動生成に使えます

そして採用判断の分岐点になるのがレート制限です。API Reference には 「API v2 のレート制限は IP アドレスあたり 1 分 1,000 リクエスト（約 16.7 リクエスト/秒）」 と明記されており、これを超える用途についてはセルフホストが案内されています。

この数値は、判断の線引きとしてそのまま使えます。チーム内の Discord サーバーでの利用や中規模の Bot であれば公開 API の範囲で収まる可能性が高く、逆に大量のリンクを連続処理するバッチや、多数のユーザーを抱えるサービスの常時機能として組み込む場合は、設計段階からセルフホストを前提にすることになります。

なお、API の認証が必要かどうかについては、この API Reference のページには明記がありません。Deployment 配下の Credentials に関連する記述があるため、認証周りの要件を詰める必要がある場合は公式ドキュメントの該当ページを直接確認してください。

類似OSSとの違い｜vxTwitter・VixBlueskyとの比較軸

「埋め込み修正系」の OSS は FxEmbed だけではありません。GitHub API で属性を確認できた主な類似リポジトリは次の 3 件です。

出典: gh api /repos/{owner}/{name}（2026 年 10 月時点の取得値）

比較の軸は「対象サービス範囲 / 実装と実行環境 / ライセンス / 公開 API の有無 / メンテナンス状況」の 5 つです。読み解くうえで特に効くのは次の 2 点です。

1. ライセンス差が、自社サービスへの組み込み可否に直結する

FxEmbed は MIT、VixBluesky は AGPL-3.0、vxTwitter は WTFPL です。MIT は改変・再配布・商用利用の条件が緩く、自社プロダクトの一部として組み込む際の制約が小さく済みます。対して AGPL-3.0 は、改変したコードをネットワーク経由でサービス提供する場合にソースコードの公開義務が及ぶため、クローズドなサービスへの組み込みを前提とするなら事前に法務面の確認が必要になります。「機能が足りているか」だけでなく、このライセンス条件が選定の実質的な制約になるケースは珍しくありません。

2. この分野の OSS は停止しうる、という前提を持つ

表の 3 件目、Instagram 向けの InstaFix は MIT ライセンスで 1,030 スターを集めていますが、既にアーカイブされています。TikTok 向けの dylanpdx/vxtiktok も同様にアーカイブ済みです。SNS 側の仕様変更に追随し続ける性質上、このカテゴリのプロジェクトはメンテナンスが止まるリスクを構造的に抱えています。

したがって、埋め込み修正系 OSS を選ぶときは、スター数よりも「最終 push の日付」と「archived フラグ」を先に見るべきです。FxEmbed については、先に示したとおり archived=false かつ最終 push が 2026 年 10 月 10 日で、この観点では健全な状態にあります。

対象サービス範囲で見ると、FxEmbed は X / Twitter と Bluesky を 1 つのコードベースで扱い、vxTwitter は X / Twitter 中心、VixBluesky は Bluesky 専用です。両方を使うチームであれば、運用対象を 1 つに集約できる FxEmbed に利点があります。一方、Bluesky だけを対象にしていて Cloudflare Workers を使いたくない、といった条件なら VixBluesky を検討する余地があります。

なお、本記事では各プロジェクトの 性能・速度の優劣は比較していません。計測を行っていないためで、レスポンス速度が選定条件になる場合は自環境での検証が必要です。vxTwitter の内部実装の詳細についても、公式リポジトリの説明文と GitHub API で取得できる言語・ライセンスの範囲に留めています。

セルフホストの要件と判断ポイント

公開 API のレート制限を超える用途、あるいは公開インスタンスへの依存を避けたい場合は、セルフホストが選択肢になります。手順の全文は Self-Hosting Guide にあるため、ここでは採用判断に必要な制約を抽出します。

Cloudflare Workers へのデプロイ手順の骨格

想定実行環境は Cloudflare Workers です。公式ドキュメントは「1 アカウント 1 日 10 万リクエストまで無料」と記載しており、グローバルエッジ上で動くことが前提に置かれています。Hono で構築されているため Web 標準準拠の他ランタイムでも動作する可能性があるとしつつ、導入が容易な Cloudflare Workers が推奨とされています。

前提条件は、Node.js の最新 LTS、Cloudflare アカウント、Cloudflare Account ID の 3 つです。手順の骨格は次の流れになります。

1. リポジトリを clone して npm install
2. wrangler.example.toml を wrangler.toml にコピーし account_id を設定（Cloudflare Analytics Engine を使わない場合は analytics_engine_datasets の記述を削除）
3. .env.example を .env にコピーして編集
4. （任意）branding.example.json を branding.json にコピーし、ゾーンごとの名前・色・アイコン・リダイレクト URL を設定
5. npm run deploy を実行（esbuild でビルドし wrangler deploy --no-bundle でデプロイ）
6. *.workers.dev で動作を確認し、Cloudflare ダッシュボードでカスタムドメインを追加

運用コマンドとしては、Sentry へのアップロードを伴わないビルドのみを行う npm run build-local と、wrangler tail でリアルタイムログを流す npm run log が用意されています。更新時は git pull → npm install → npm run deploy の手順です。

Docker イメージの前提と再ビルドが必要なケース

README には Docker を使う構成も記載されていますが、ここには注意点があります。README は、FxEmbed が Cloudflare Worker であるため、Docker イメージは「素の Node.js サーバーを起動するのではなく、Wrangler 経由でローカルの Workers ランタイムを動かす」ものだと明記しています。ベースイメージが node:24-bookworm-slim である理由も、Wrangler の workerd バイナリが glibc にリンクされており Alpine / musl 環境では安定して動かないためと説明されています。

つまり Docker を使っても「Workers ランタイムから離れられる」わけではありません。この点を誤解したまま進めると、インフラ構成の前提から見直すことになります。

起動前には設定ファイルのコピーが必要で、README には次のコマンドが掲載されています。

cp .env.example .env
cp wrangler.example.toml wrangler.toml
cp branding.example.json branding.json

出典: https://github.com/FxEmbed/FxEmbed （README の Docker セクション）

起動は docker compose up -d --build で、ワーカーは http://localhost:8787 で待ち受けます。運用上もう 1 つ押さえておきたいのが、.env の環境変数はビルド時にバンドルされるという点です。ドメインリストなどを変更した場合はイメージの再ビルドが必要になります。一方、CREDENTIAL_KEY や EXCEPTION_DISCORD_WEBHOOK といったランタイムシークレットは、シェルまたは Compose の .env から渡す形になります。

セルフホストに踏み込むかの判断軸

以上を踏まえると、セルフホストの可否は次の 3 点で判断できます。

• Cloudflare に寄せられるか: 実行環境は Cloudflare Workers 前提で、Docker 構成でもその前提は変わりません。マルチクラウド方針や既存のインフラ標準と整合するかを先に確認する必要があります
• ドメイン運用を維持できるか: カスタムドメインの追加と、Host ヘッダベースのルーティングを前提にした運用が必要になります
• 再ビルド運用を許容できるか: 設定変更がビルド時にバンドルされるため、設定変更ごとに再ビルド・再デプロイが発生します

FxEmbedを採用するか判断するためのチェックポイント

ここまでの事実を、採用判断の軸として組み替えます。

• ライセンス: MIT（GitHub API 取得値）。組み込み・改変・再配布の制約が小さく、自社プロダクトへの組み込みを前提とした検討がしやすい。類似 OSS の AGPL-3.0 と比べると、この差は実務上の判断材料になる
• メンテナンス状況: 2026 年 10 月時点で archived=false / fork=false / disabled=false、最終 push は 2026 年 10 月 10 日、リポジトリ作成は 2022 年 7 月 13 日。GitHub Actions による build / tests のワークフローが稼働し、稼働監視のステータスページも公開されている。一方で GitHub Releases のタグは作成されていないため、バージョンの追跡はコミットと package.json（記事執筆時点で 2.0.0）で行う必要がある。オープン Issue は 76 件
• 依存の集中: Cloudflare Workers への依存度が高い。Workers から離れる前提での採用には追加検証が必要
• 利用規模: 公開 API のレート制限は IP アドレスあたり 1 分 1,000 リクエスト。これを超える規模であればセルフホストが前提になる
• 対象 SNS: X / Twitter と Bluesky のみ。Instagram や TikTok は別の OSS が担当する領域で、そのうちいくつかは既にアーカイブされている
• 機能の分割: 複数画像の結合は別リポジトリの Mosaic が担当する。セルフホスト時に同等の表示を再現したい場合は、追加のサービス構成が必要になる
• 商標・立場: X Corp とは無関係のサードパーティ実装である点を踏まえ、業務用途では自社のポリシー確認が必要

導入検討の順序としては、まず公開インスタンス（fxtwitter.com 等）でリンク変換の挙動を確認し、必要な機能が揃っているかを見極め、そのうえでレート制限と可用性の要件からセルフホストの必要性を判断する流れが現実的です。

なお、本記事は公開ドキュメントと GitHub 上で取得できる情報に基づく整理であり、動作検証に基づくものではありません。実際の挙動や性能、自環境での互換性については、公式ドキュメントを参照のうえ各自の環境で確認してください。

まとめ

FxEmbed は、X / Twitter と Bluesky のリンクを Discord や Telegram などで正しく埋め込み表示するための OSS で、FxTwitter / FixupX / FxBluesky という 3 つのサービスを 1 つのコードベースから提供しています。使い始めるコストは「URL のドメインにプレフィックスを足す」だけで済み、検討の初手としてのハードルは低く抑えられています。

一方で、本格的に組み込む段階では前提が変わります。公開 API のレート制限は IP アドレスあたり 1 分 1,000 リクエストで、これを超える用途ではセルフホストが案内されています。そしてセルフホストは Cloudflare Workers 前提で、Docker 構成を採っても Workers ランタイムから離れられるわけではありません。「軽く試す」から「本番に載せる」の間にインフラ方針の判断が挟まる構造になっています。

類似 OSS との差は、対象サービス範囲とライセンスに最も明確に出ます。X / Twitter と Bluesky の両方を 1 つの運用対象に集約できる点と、MIT ライセンスで組み込み条件が緩い点が FxEmbed の特徴で、Bluesky 専用の VixBluesky（AGPL-3.0）や X / Twitter 中心の vxTwitter（WTFPL）とは選定条件が変わります。

そして、この分野を検討するうえで共通して押さえておきたいのは、Instagram 向けの InstaFix や TikTok 向けの vxtiktok が既にアーカイブされているという事実です。埋め込み修正系の OSS はスター数より先に最終 push と archived フラグを確認するのが、選定時の実用的な作法になります。次の一手としては、FxEmbed 公式ドキュメント の Getting Started と API Reference を読み、自分のユースケースが公開 API の範囲に収まるかを確認するところから始めるのが確実です。

関連情報

SNS 連携 Bot・社内ツールの開発や、OSS を前提としたシステム構成の選定・セルフホスト環境の構築をご検討中の方は、お問い合わせフォーム からご相談ください。要件の整理段階からご相談いただけます。

参考リンク

• FxEmbed/FxEmbed（GitHub）
• FxEmbed 公式ドキュメント
• FxEmbed API Reference
• Self-Hosting Guide
• FxEmbed/mosaic
• FxTwitter ステータスページ
• FxTwitter 翻訳プロジェクト（Crowdin）
• dylanpdx/BetterTwitFix（vxTwitter）
• Lexedia/VixBluesky
• Wikidepia/InstaFix