ウェブページをリニューアルしました＋近況

かなり久しぶりのブログ更新です。

タイトルの通りですが、約6年ぶりにウェブページを刷新しました。

ウェブページを更新しました

前回は2018年頃に、Zend Frameworkをベースに作っていたのをLaravelベースのサーバーに置き換え、AppEngineで動かす形にしていました。

紆余曲折あり、趣味の個人サイトにVPSで動かすやら、クラウドサービス移行でも無駄にDB使っている部分が切り離せないなどの問題がありました。が、PHPでのSSRを止め、モダンなTypeScriptベースのSPAとして置き換えるに至りました。

それまでも移行しつつ、無駄に細々した機能があり、重い腰が上がらなかったのですが、特にここ1〜2年ほどでAIコーディング、AIエージェントの登場もあり、そのサポートを受けながらどうにか移行できました。

といっても、サイトデザインなどは既存を踏襲したため目新しい感じはほぼなく、逆に古くささも残ります。

これで誰も来ないのに 約1800円/月 もかかっていた運用コストも劇的に抑えることができました。最近のホスティングサービスやクラウドの無料枠、ありがたいです。

近況について

変わらずすごしています。こっちで何も更新がない間も、Zennに記事を書いてみたり、AT ProtocolベースのWhiteWindに記事を書いてみたり、色々分散していますが、何かしら時々アウトプットしてます。あとSNS投稿の場をTwitterから Blueskyに移動したりしてました。

これまでは外部サービスを利用すると、ある日そのサービスが消えたときにすべてが消えてしまう恐れがあり、なるべく自前でホストしたい欲があったため、自分でホストするブログに記事を残す、自前でホストしたWikiに書く。などをしていたのですが、テック記事については今後Zennや外部記事でホストしてもらった方が、運用コストやコミュニティ間での広がり（露出）を兼ねると、トータルで良いかもしれないと思ってきて、このようにしています。

またBlueskyを主に使うようになって、BlueskyやAT Protocolの仕組みを活用してみるサービス開発もするようになりました。

それらの話題は基本的にAT Protocolで作られたサービス（WhiteWindやLeaflet、Mochottなど）で書いたりしています。このブログに関しても、そちらに移行してもいいかなと思ってきています。

ちなみにBluesky関連で作ったアプリは以下です。

Bluesky関連アプリ

• SkyTools Blueskyに未ログイン状態でも各アカウントの投稿などが閲覧できるビューワ、アカウント変更履歴の表示などのツール
• Chronosky Blueskyへ日時指定で投稿する予約投稿サービス
• Chavatar Blueskyのプロフィールアイコンを時間ごとに自動変更するアプリ
• 簡易アプリ
• Save Your Follows 公開されているモデレーションリスト内にフォロワーやフォロー中の人が含まれていないか確認するアプリ。そのリストを購読することで、誤って既存のフォロー中の人をブロックしてしまわないか確認できます。
• Campaign Tool for Bluesky BlueskyでRPフォローキャンペーンをするときに、対象ポストのRPとフォロワーを集計して抽選するアプリ。企業や企画のプロモーションに活用してください。
• Bluesky モデレーションリスト複製ツール その名の通り。公開されているモデレーションリストを自分のアカウントに複製します。複製時にリスト内のアカウントを自分で選択できるため、自分で無関係だと思われる人を既存のリストから外すことができます。ただし残ったアカウントは引き続きモデレーション対象として、自身のアカウント内で扱われることになるので、ご注意ください。
• その他
• Bluesky Handle Checker (一般利用向けはこちら)
  Blueskyに登録されるアカウントで、特定のハンドルが存在するかを定期監視し、見つかったらDiscordに通知するbotとサービス。企業やブランドのドメインがカスタムハンドルとして登録されると通知され、公式アカウントが作られたことを確認できます（但し公式アカウントがカスタムハンドルとしてドメインを使用するか否かは各公式アカウントの運用方針によります）

バイブコーディングに合致するか分からないですが、コーディングエージェントにはだいぶ助けてもらいつつ、やりたかったことを実現できました。これまでの経験では知見が足りなかったりして時間のかかっていたフロントエンドを作り込んでいき、モダンな環境で実行できるアプリケーションを複数出してみることはできたかなと思います。

というわけで、ATProtocol関連で日々続々と出てくるプロダクトなどにワクワクしつつ、そちらの方に興味をそそられている毎日です。

AT Protocolにホストしても良いかなと言っても、結局のところ、ホストされるPDS（アカウントに紐付くデータが保管される場所）に依存するためそこが急に閉じてしまえばそれでデータは消失してしまうことにはなりますが、移行期間と移行先（受け入れ先）が設けられれば、どこにおいても同じように継続できるのはいい仕組みだなと思っています。

最近作ったアプリの話

先日、コナミ社の提供しているコナステのダウンロードコンテンツゲームを1クリックで起動できるアプリを作り、公開した。

Ks Game Launcher (Github)

作った理由として、インストール時に作成されたショートカットをクリックするとブラウザが起動し、ログインしていたらそこから起動ボタンを押して初めてクライアントのランチャーが立ち上がる……という起動方法がイマイチに感じたため。

また、過去に似たような理由（とサブ垢切り替えが面倒だったため）で作ったことがある拙生作 TSLoginManager と同等の仕組みで実装できると考えたため。また、久しぶりにクライアントアプリの開発言語を触りたかったから、というのもある。

今回は作ったときのメモとして、どんなことをやったか、どんな経緯だったかをこの記事に残してみる。メモなのでまとまっていない書き方になっている点はご容赦を。

1Passwordでヴォールトをアーカイブ（非表示）する

昔から1Passwordを使っていて、これまではスタンドアロンタイプの買い切りで利用してきました。

1Password 8からは完全にサブスクリプション型に移行してしまったのでサブスクリプションで利用しています。

サブスクリプション型ではこれまでと同じように管理できますが、基本的にクラウドベースの同期型で管理されます。

私は用途ごとにいくつかのヴォールトに分けて中身を管理しています。例えば、少しお手伝いしたプロジェクトなど。そういった中にはお手伝いが終了したプロジェクトもあるため、本来であればその時点で削除するのが好ましいのですが、状況により引き継ぎが完了していなかった情報があった場合、あとから確認されるケースもあります。

あるいは、個人的に過去に使っていたけど、現在は不要になった情報などもあると思います。

そういった削除したくないけど、普段は使わないため非表示にしておきたいヴォールトについて、ヴォールト単位でアーカイブする機能はないかなと思っていたのですが、そういったものはなさそうで、諦めていました。

が、改めて1Passwordをウェブから確認したところ、これを実現できそうなものがあり、実際できたのでメモしておきます。

👋Clubhouseについてまとめ（更新）

最近流行している新しいSNS、Clubhouse 。これまでのSNSと異なり、文字によるコミュニケーションではなく、音声でのコミュニケーションがメインのSNS。

テキスト主体のSNSがTwitter、画像主体のSNSがInstagram、あるいはPinterestだとして、Clubhouseは音声、会話でのSNSとなっている。SNSなので、その時に話したい人同士で好きに聞いて、話してとすることができる。

ありがたいことに、国内ではやり始め直後に招待してもらうことができ、それを試すことができたので、この新興SNSについて、（既に書かれていること、分かっていることも多いが）分かったこと仕様などをメモとしてここに書く。

日本では2021年1月25日頃から流行りだした。このタイミングで、このアプリの登録時に必要な電話番号で国番号+81（日本の国番号）が追加されたとのこと。

実はサービス自体は既に昨年の夏（2020年7月）頃から、そしてベータ版は２０２０年月頃から北米西海岸を中心に始まっていた模様。このタイミングは、各アカウントにある招待してくれた人（Nominated by）を辿っていき、開発者（@rohan、またはアプリアイコンにもなっている@iambomanix）に辿り着くことで分かる。

日本でも既に多くの人が招待を受けているようで、マスメディア、芸能関係、政治関係者、その他インフルエンサーなどでも早い段階から入ってきている人も多い。このあたりはそれぞれの業界関係者のTwitterへの参入時のときから比較すると、かなりリーチが早く、正直驚いている（これまでのSNSの傾向的に、この手のアーリーアダプターはテック系メディア関係者やITエンジニアなんか界隈で賑わうことが多い印象が個人的にあった）

AppEngineでcomposerが更新されないとき

Google AppEngine

 最近になってようやくGoogle AppEngine (以下GAE)を使いだし、自サイトをその上で動かせるよう試行錯誤しています。

前置き

私の主サイトは古くからPHPで動かしていて（初期の頃はLegacy ASPで動かしていたこともありました）、GAEでPHPがサポートされてからいつか移植して動かしてみたい。と思っていたのですが、ベースとしていたフレームワークが古く、composerも使用していない状態のものだったため、最近になり、重い腰を上げてLaravelに置き換えるまでなかなか移植できずにいました。

GAEで開発していると、自分で好き勝手にモジュールをインストールして動かしていた環境と異なり、ある程度の制約を受けつつその中で作るようになります。幸いにも既存機能については代替の外部APIなどに置き換える事でほとんど移植可能になりそうとなりました。

minikubeでGoogle Container Registry (gcr)からイメージを取得する

最近は今ごろになってKubernetesの勉強をしています。
概念は大まかに理解した。つもり。けど全然分からん。

Zennで書いた記事のミラー。なので、以下同じ内容。

前置き

現在Google Cloudの無料期間を利用しつつ色々試しているのですが、Google Container Registry(gcr.io)にホストしたコンテナイメージをminikubeで構築しているローカルの環境から取得する際に、プライベートリポジトリだと認証処理が必要になります。

Kubernetesでもこのあたりはもちろん考慮されていて、Dockerレジストリで使用されるログイン認証に準拠した仕組みが準備されています。

が、如何せんうまく認証されない。普通にリポジトリパスを指定しても、PullImageErrorとなってしまう。

エラーログを見ると、認証方法を確認しろ（意訳）というメッセージとともに GCRでの認証方法を案内するページ へのリンクが出ているので確認し、手順に則って見るも、うまくできない🤔

フリーWi-Fiに接続したらサイトに接続できない場合の話

 スマートフォンが普及してからだいぶ経ち、国外からの旅行者向け、観光誘致も込めてまちなかで使用できるフリーWi-Fiもだいぶ普及が進んできました。

おかげで飲食店などに入り、その店内でWi-Fi経由で調べ物をしたりするのにはとても便利だったりします。

しかし、フリーWi-Fiに接続した途端にサイトに接続できなくなることありますよね。あれ鬱陶しいですね。

これは少し仕方がない部分があって、これもまた最近広まっている、常時HTTPS通信によるものが影響してます。

何故繋がらなくなるのか

HTTPSの通信によって通信の内容は暗号化されています。その内容は利用者以外からは読み取れません。また、その通信内容を改ざんすることもできません。

フリーWi-Fiで繋がらなくなるのはこの通信に介入（実質的には一部改竄）し、Wi-Fiの事前認証情報にログインしていない場合はログイン画面に移動させようとします。
また認証されていない場合、ログイン画面と、一部の許可されたサイト（例えば店舗のウェブサイトなど）以外は通信を制限するようにしています。

この機能はフリーWi-Fiのルーターの機能によるもので、これをキャプティブポータル（Captive Portal）といいます。

そのためログイン画面に遷移させることもできず、外部のサイトへの接続も制限された結果、フリーWi-Fiにつないだ途端にウェブサイトにつながらない。という状態が発生します。

データ通信用eSIMの契約と設定 (Pixel 4編)

eSIMの契約と設定 (Pixel 4編)

先日Googleのイベントで発表、その後発売されたPixel 4を購入しました。

PixelシリーズでもPixel3からeSIMに対応しましたが、国内版ではFeliCaが使用可能な代わりにそれが有効化されず、eSIMが使えるのは北米版でした。Pixel 4では国内版でもeSIMが使えるようになり、FeliCaも引き続き利用できるようになりました。

日本ではしばらくeSIMを提供するキャリアは存在しませんでしたが、2019年7月18日から、IIJ mioでeSIM契約の提供が開始されました。
現在はデータ通信専用、かつベータ版ということで、eSIM側で音声通話はできないですが、主回線とデータ通信線用回線でプランを使い分けすることが可能になります。

IIJ mioでは、10月31日までのキャンペーンで、初期費用3000円が0円、月額1,520円(税抜)/6GBが3ヶ月間1,000円引きの520円となるキャンペーンが開催されているため契約してみました。（10月28日までに繰り上げ、10月29日現在終了済み）

iPhone版はこちら

データ通信用eSIMの契約と設定 (iPhone XS編)

eSIMの契約と設定 (iPhone XS編)

iPhoneはXSからデュアルSIMに対応し、中国、香港を除く地域で販売されるiPhone XS以降ではeSIMが使えるようになりました。

日本ではしばらくeSIMを提供するキャリアは存在しませんでしたが、2019年7月18日から、IIJ mioでeSIM契約の提供が開始されました。
現在はデータ通信専用、かつベータ版ということで、eSIM側で音声通話はできないですが、主回線とデータ通信線用回線でプランを使い分けすることが可能になります。

IIJ mioでは、10月31日までのキャンペーンで、初期費用3000円が0円、月額1,520円(税抜)/6GBが3ヶ月間1,000円引きの520円となるキャンペーンが開催されているため契約してみました。（10月28日までに繰り上げ、10月29日現在終了済み）

Android版はこちら

他人が自分のメールアドレスでサービスを利用した場合（AmazonとNetflixの場合）

サービス登録とメールアドレス

本来あまりあってはならないが、サービスによってはユーザー登録時の利便性を考慮し、利用者が入力したメールアドレスの所有確認をその場ではしないものもある。
そうした場合でも、サービス利用開始後にマイページなどで受信確認を行わせるものはある。
しかし、その確認はあくまでもユーザー任意となっており、実質的に自分の所有していないメールアドレスで登録、利用できてしまうケースもある。

自分のメールアドレスを利用しないことによるデメリット

この場合で困るのは、アカウントを利用しようとしたユーザーがパスワードを紛失した際に、自力で復旧することが困難になる。
また、登録時に利用した他人のメールアドレスが実在した場合、場合によってはその所有者に登録者の個人情報が漏れる事である。

後者の場合、悪意あるメールアドレス保有者だった場合に、そのサービスにアクセスし、パスワードをリセットさせることで、そのアカウントを乗っ取ることができる。サービスの作りによっては、乗っ取ったアカウント内に保存されている住所などの連絡先情報やメールの内容、登録されたクレジットカード情報などが確認できてしまう可能性すらある。

サービス登録時は自分のメールアドレスをよく確認して登録しよう。


今回は自分のメールアドレスが他人に勝手に登録され、利用された場合の各サービスへの問い合わせと、その対応結果についてここに書く。

中古ドメインを購入しG Suiteでキャッチオールで受信してみた

G Suiteとキャッチオール機能

G Suiteは独自ドメインでGoogleサービスを利用できるもの。
代表的な機能としてはGmailで、G Suite管理画面から払い出したアカウント毎に独自ドメインで利用可能なGoogleアカウントが作成される。

そのため通常には通常のメールアドレスと同じく一つの受信先のメールのみ利用できる（別途受信用にエイリアスを指定することは可能）が、自分のドメイン宛の他のメールアドレス（存在しないアカウント）宛に送られたメールについても受信設定をすることが可能である。これをキャッチオール機能という。これはメールシステムによってサポートされていなかったりもするが、G Suiteでもこれを設定し、受信することができる。

G Suiteでは、存在しているメールアドレス以外の、存在しないメールアドレス宛のメールを設定できることはもちろん、存在しているメールアドレス宛のものも設定できる。
後者は組織で監査目的などで設定し、別途監視する、ということも可能ではある。

使用するドメインについて

さて、今回試用する中古ドメインは、中古といっても期限が切れたものをすぐに新規で取得したもので、ドメインオークションサイトなどで出品されていたものを入手したとか、前の所有者から直接譲渡された、というわけではない。

ファーストオーナーではないことが分かりきった上でこれを設定するのもなかなかイヤラシいが、はたしてどんなメールが来るのか少々興味があった。

サーバーに仮想通貨採掘マルウェアを仕込まれた話

PexelsのSaksham Choudharyによる写真

Qiitaに投稿していた記事と同じものになります。

先日、個人で利用しているサーバー（VPS）に侵入され、マルウェアを仕込まれました。
エンジニアとして大変恥ずかしい話ではありますが、皆さんしっかり対策されていると思われるので、検索しても日本語では同様の事例が見つからなかったのでここに残します。

Google DriveをEvilに（ずる賢く）使う方法について検証してみる

Google Driveはクラウドドライブサービスとして、自分のファイルのクラウド上での保存はもちろん、オンライン上の複数人への共有にも役立つサービス。
しかしGoogleサービスを使いこなしているとアカウントに割り当てられた初期容量 15GB（無償版の場合）もあっという間に消化してしまうかもしれない……。

ところで話は変わり、Googleドライブを利用していると関連製品としてオフィススイートのGoogleドキュメント、Googleスプレッドシート、Googleスライドを目にすると思う。
これらによって作られたファイルもGoogleドライブ内にファイルとして保存されるが、これらのファイルの保存容量は0バイトとなる。

ドライブ内にこのように配置してみた。画像ファイルなどはそれぞれファイルサイズが表示され、容量が消費されている。スライドファイルはファイルサイズが表示されない

これはGoogleのヘルプにも記載されているが、オフィススイート製品で作成されたファイルは容量を消費しない。そう、Googleサイトで作成したページすらもアカウントの容量制限を受けずに利用できるのである。

さて、ここで気付くことがある。もしかして、Googleオフィススイートのファイル（仮にここではドキュメント）のファイルをコンテナとすれば、ドライブの容量を消費せず、実質容量無制限でファイルを保存できるのではないか……。
悪魔（Evil）な考えですが、思いつくものは仕方が無い。試してみましょう。

東京メトロと富士ゼロックスのサテライトオフィスサービスを利用してきた

富士ゼロックスと東京メトロが実証実験を行っている、サテライトオフィスサービスを利用してみました。

サテライトオフィスサービスとは何か。

街中の一角に壁に囲まれたスペース内に電源とディスプレイとWi-Fiが提供された個室サービス。

こちらのサービスでは現在は東京メトロの地下鉄、一部駅の設置されたスペース（新宿だけ新宿野村ビル内に設置）となっていて、それぞれ時間貸しで利用できます。最低単位は15分/枠で、2018年11月現在は1枠200円（税別）です。

現在スペースが設置されている場所（主に駅構内）

今回は縁あってサービスの利用権をいただけたので利用してみました。

スマートフォンゲームで利用されているフォント

数多くのスマートフォンゲームが日々リリースされていますが、ゲームも基本システムが似ているものから独特のものまで様々。もちろんUIもそれぞれのゲーム毎に特徴が異なるわけですが、最近はゲーム内の世界に合わせてやや特徴的なゲーム内フォントを用いることも増えてきてます。

そんなわけで、いくつかの代表的なゲーム（筆者の観測内）で利用されているフォントをいくつかピックアップしてまとめてみます。

パズドラ

くろかねEB （フォントワークス）

モンスターストライク

コミックレゲエB （フォントワークス）

グランブルーファンタジー

ニューシネマB D （フォントワークス）

Fate/Grand Order

スキップB （フォントワークス）

シノアリス

パールL （フォントワークス）

白猫プロジェクト 

スキップD （フォントワークス）

プリンセスコネクト！Re-dive

ハミングD （フォントワークス）

マギアレコード 魔法少女まどか☆マギカ外伝

NUDモトヤF4アポロ5 （モトヤフォント）

NGINXのSecureLinkモジュールを使ってみる

突然ですがSecureLinkモジュールとはなんぞや、というところですが、簡単に言うと、サービス登録時のメールアドレス確認で、下記の様なメールで見たことがあるような、一定時間のみ有効な時限式URLの認証機能を提供するモジュールです。

通常このような機能を作成する場合、URLの発行、利用期限の管理含め、基本的にはいわゆるPHP、Ruby、Python、Javaなどのサーバサイドアプリケーションで実装して利用しますが、このSecureLinkモジュールはこのうちの利用期限管理（URLの正当性検証）をnginx側で処理してくれるものになります。
そのため、時限式URLに絡めて、事前に入力されたユーザー情報を参照して〜といった、上記のメール画像のような機能には適さないですが、例えば、特定の静的ファイルを時限式URLで不特定多数に配布したい、といった場合であれば有効であると言えます。


長い前置きはさておき、以下からは実際に設定していきます。



まず、このモジュールはnginxの標準モジュールとしては提供されていないため、nginxのconfigure時に--with-http_secure_link_moduleオプションを付けてビルドし、有効化します。

一番簡単な設定方法としては、モジュールの公式ドキュメントやこちらのページ(by レンタルサーバー・自宅サーバー設定・構築のヒント)で紹介されているとおり設定すると基本的に動きます。

で、同じ内容で紹介してもあまり芸がないので、今回はほんの少しだけトリッキーな設定（ただの応用）での構築をここで記載してみます。

まず、構成を下記の様に設定するものとします。

パス設定
/var/www/example.com/public
└ドキュメントルート
/var/www/example.com/secure
└セキュアファイル設置場所

URL
https://example.com
└通常URL
https://example.com/secure
└セキュアリンクURL

通常の設定

ここまでの設定で、通常設定すると下記の様な設定になります。

server {
    root    /var/www/example.com/public;
    index   index.html;
    # SecureLinkアクセス用URI
    location /secure/ {
        alias /var/www/example.com/secure;
        # 公開鍵のパラメータ k=公開鍵&t=タイムスタンプ のパラメータを与える設定
        secure_link $arg_k,$arg_t;
        # 公開鍵レシピ
        secure_link_md5 YOUR_SECRET_KEY_WITH$uri?$arg_t;
        if ($secure_link = "") {
           # 認証NGの場合404を返却
           return 404;
        }
        if ($secure_link = "0") {
            # 有効期限切れの場合は403を返却
            return 403;
        }

        try_files /$request_uri =404;
    }
}

上記設定では、例えば https://example.com/secure/secret.html?k=OqjJ-smKxgnNTCGYz78TOg&t=1531815176 というURLにアクセスすると、パラメータkの公開鍵とtのタイムスタンプがそれぞれ正しければsecret.htmlのファイルを閲覧することができます。
/secure/パス以下は、ドキュメントルート外の/var/www/example.com/secureを参照したいので、alias で別途パスを指定してます。（ここでrootディレクティブで指定すると、/secureの参照先が/var/www/example.com/secure/secure 以下を参照する事となり、恐らく想定した通りのパスを見てくれません）

セキュアリンクモジュールを使用した場合、パラメータまで一致していて初めてアクセスできるので、これらのURLパラメータを削除して、直接 https://example.com/secure/secret.html にアクセスしても、secret.htmlは閲覧できません。
が、今回はもうちょっとURLをそれっぽくしたい。

セキュアリンクのURLをカスタムしたい

https://example.com/secure/OqjJ-smKxgnNTCGYz78TOg/secret.html?t=1531815176

というURLのフォーマットにしたいと思ったので、下記の様にアレンジしてみました。

    # SecureLinkアクセス用URI
    location ~ ^/secure/(?<pubkey>[0-9a-zA-Z_\-]+)/(?<filepath>.+) {
        alias /var/www/example.com/secure;
        # Public key (URI)
        secure_link $pubkey,$arg_t;
        # Secret key
        secure_link_md5 "YOUR_SECRET_KEY_WITH$filepath?$secure_link_expires";
        # Invalid key
        if ($secure_link = "") {
           return 404;
        }
        # timeout
        if ($secure_link = "0") {
            return 403;
        }
        try_files /$filepath =404;
    }

今回のポイント

ポイントはlocationディレクティブを名前付き正規表現でパラメータを判定できるようにして、その名前（ここでは変数$pubkey）とURLパラメータ(t)をsecure_linkに引数として渡しているところです。
また、対象のファイルは同じく名前付き正規表現で変数$filepathに格納しています。

すべての認証が成功した際に、try_files で$filepathを確認し、なければ404を返す様にしています。

Apple Musicのプレビュープレイヤーが公開されたので実際に使ってみる

Apple Musicのウェブプレイヤーが公開され、誰でもiTunesストアおよびApple Musicで配信されている楽曲の埋め込みができるようになったので使ってみました。

Apple Music マーケティングツール こちらのページからアーティスト名や楽曲名で検索し、Apple Musicで配信されている楽曲に関してはページ内埋め込みができます。

このように、埋め込み時のサイズを指定すると、その下に埋め込み時のプレビューが表示されます。

もしプレビューが表示されない場合は、配信が停止された場合か、下記ドメインのクッキーに対して許可が必要になります。

embed.music.apple.com

プレビューのしたに、埋め込み用のコードが表示されています。
現在は「プレビュープレイヤー」用のコードが表示されていますが、他に「バッジ」「Text Lookup」「App Icon」などの方法によるリンクも設置できるようになっています。

下記は私が個人的に好きなアーティストさんのアルバムを表示したものです。


アルバムに入っている特定の楽曲を指定した場合は下記の様になります。（トラック9のInternet Cityを指定）


一部、プレビュープレイヤー（埋め込み型プレイヤー）では配信できない楽曲もあるらしく、その場合はプレイヤーを埋め込んだ場所に下記の様に表示されます。

この場合は仕方がないので、リンクで対応する必要があります。（リンク先では表示、プレビュー可能でした）


埋め込み型ウェブプレイヤーは基本的にはiTunesのプレビュー試聴が出来る状態です。
実際にApple Musicで試聴するにはiTunesが必要です。