読者です 読者をやめる 読者になる 読者になる

Voicy Tech Blog

Voicy公式Techブログ

Twitterがしゃべる!?Playerカードの作成方法

こんにちは!Voicy CTOの窪田です。

先日Voicyのサイトにチャンネル紹介のページが追加されました! 公式チャンネルや人気のパーソナリティをピックアップして掲載しているのですが、それぞれのページをTwitterでシェアすると、なんとタイムライン上で音声を聴くことができます!

例えばこちらのVoicy公式チャンネルのURLをTwitterでつぶやくと
https://voicy.jp/channel/voicy.html

このように表示されます。

f:id:voice-tech:20170504190928p:plain

そしてツイートをクリックすると再生画面が展開されて、Twitterのタイムライン上で音声を聴くことができます!

f:id:voice-tech:20170504190933p:plain

そこで、今回はこの再生機能の作成方法ついてお話しさせていただきます。

Playerカードについて

タイムライン上での再生機能は、Twitterが提供しているPlayerカードというものを使用しています。正確にはTwitterカードで選べるカードタイプのうちの1つがPlayerカードです。表示される再生画面はHTMLで自作するので、デザインはかなり自由に作ることができ、もちろん音声に限らず動画も再生可能です。

Twitterカード自体は誰でもすぐに使用できるのですが、Playerカードだけはドメインの利用申請が必要になります。また、HTTPSでアクセスできるWebサーバーも必要です。

Playerカードは以下の手順で作成していきます。公式マニュアルも合わせてお読みください。

  1. 再生画面をHTMLで作成
  2. 再生画面をHTTPSでアクセスできるように配置
  3. シェアされるページに専用のMETAタグを設定
  4. シェアされるページのドメインTwitterに申請
  5. Card Validatorで動作確認

Playerカード作成手順

1. 再生画面をHTMLで作成

再生画面を作成する際の注意点が公式マニュアルの"申請時のポイント"に載っているので、それさえ守れば自由にデザインや機能を実装できます。

後から変更することもできるので、Voicyではまず最小限の機能だけを半日くらいで開発して申請を行い、その後正式版として作り直しました。申請時には特に以下の内容を意識して開発しました。

  • iPhoneAndroidTwitterアプリ、twitter.com、mobile.twitter.comなどのすべてのTwitterクライアントでエクスペリエンスをテストしてください。これらすべてのTwitterクライアントで動作しないカードは承認されません。
  • すべてのクライアントで動画コンテンツが表示エリアの横幅いっぱいに表示されるようにしてください。
  • 動画コンテンツとオーディオコンテンツに関する注意
    1. コンテンツが自動的に再生される動画では、初期設定を “消音” にする
    2. 長さが10秒を超えるコンテンツは自動的再生されないようにする
    3. 停止、一時停止、再生ボタンを設置する

2. 再生画面をHTTPSでアクセスできるように配置

再生画面はHTTPSでアクセスできる必要があります。実はVoicyのサイトはこれまでHTTPSに対応していなかったのですが、これを機にサイト全体をHTTPS化しました。

3. シェアされるページに専用のMETAタグを設定

Playerカードを使用するために、シェアされるページのMETAタグで再生画面に関する情報を指定します。この設定が必要なのはシェアされるページであって、再生画面のHTMLではないのでご注意ください。

さきほどのVoicy公式チャンネルページでは以下のように指定しています。

<meta name="twitter:card" content="player" />
<meta name="twitter:title" content="Voicy - Voicy公式チャンネル" />
<meta name="twitter:description" content="毎朝月曜から土曜まで、新鮮なニュースをお伝えするVoicy公式チャンネル。 これさえ聞けば日々の主要ニュースは網羅できるはず。通勤・通学のお供におすすめです。" />
<meta name="twitter:image" content="https://voicy.jp/tw/img/thumb/voicy.png" />
<meta name="twitter:site" content="@voicy_jp" />
<meta name="twitter:player" content="https://voicy.jp/tw/#voicy" />
<meta name="twitter:player:width" content="320" />
<meta name="twitter:player:height" content="450" />
プロパティ 必須 説明
twitter:card 必須 Playerカードを使用する場合は"player"固定です。
twitter:title 必須 タイムラインに表示されるサイトのタイトルです。
twitter:description 必須 タイムラインに表示されるサイトのタイトルです。
twitter:image 必須 タイムラインに表示されるサムネイル画像です。iframe未対応のブラウだでは再生画面の代わりに表示されます。
twitter:site 任意 TwitterのIDです。"twitter:site"もしくは"twitter:site:id"のどちらかが必須です。
twitter:player 必須 再生画面のURLです。HTTPSで指定する必要があります。
twitter:player:width 必須 再生画面の横幅です。
twitter:player:height 必須 再生画面の縦幅です。

プロパティに指定できる値はこの他にもあります。詳細は公式マニュアルをご覧いただきたいのですが、日本語ページと英語ページで説明が異なる部分もあるので、実際に作って動作確認することをオススメします。

4. シェアされるページのドメインTwitterに申請

公式マニュアルでは、「Playerカードを申請する」とあるので、新しいPlayerカードを作成したらその度に申請が必要なのかと思いましたが、実際はドメイン毎の承認になるので、一度承認されれば以降の申請は必要なさそうです。

マニュアルではCard Validatorで動作確認をしてから申請するように書いてあるのですが、Playerカードの場合はドメインの承認前はエラーとなってしまい動作確認ができません。

申請前の画面

f:id:voice-tech:20170504190942p:plain

そのため、多分大丈夫だろうという見込みで申請を行いました(笑) エラー画面に表示されているRequestApprovalのボタンを押して必要事項を入力します。

申請画面

f:id:voice-tech:20170504190938p:plain

Descriptionには簡単なサイトの説明を英語で入力します。"Mark my cards ~“のチェックボックスは基本的にチェック不要です。もしsensitive contentを扱うのであればチェックしてください。その他はデフォルトで入力されていました。

申請が完了するとエラーメッセージが変わります。

f:id:voice-tech:20170504190946p:plain

申請した翌日には承認され、以下のメールが送られてきました。

f:id:voice-tech:20170504191226p:plain

5. Card validatorで動作確認

無事承認されるとCard Validatorで確認することができます。

f:id:voice-tech:20170504190950p:plain

Audioカードについて

今回紹介したPlayerカードの他にも、TwitterにはAudioカードという似たような名前のものがあります。

Audioカードの方がPlayerカードよりもリッチな表現ができるようなのですが、残念ながらこれを使用するにはTwitterと企業提携を行う必要があるそうです。もしTwitterの方がいらしたらぜひ連絡ください(笑)

現在は@SoundCloudのアカウントがよくAudioカードを使用しています。スマホのアプリで見るとわかるのですが、PlayerカードだとWebViewが立ち上がって再生画面が表示されるのに対し、Audioカードではポップアップで表示されるので、ユーザー体験を考えるとAudioカードの方が良いと思います。

終わりに

現在は動画全盛期なので、動画のシェア方法は充実しているのですが、音声や音楽といった音だけのコンテンツに関しては十分とは言えません。Facebookでもタイムライン上で動画を流すことはできますが、音声だけとなると簡単にはできないのが現状です。(Music Storiesというサービスがあるのですが、新規の募集は受け付けていないそうです。。。)

それはさておき、今回のサイトリニューアルで、これまでアプリでしか聴けなかった音声を(一部ですが)ブラウザや、Twitter上でも聴けるようになりました!Voicyでは今後もあらゆる手段で声をお届けできるよう、新しいことへ積極的にチャレンジしていきます!

Voicyのメンバーがどういった思いでサービスを作っているのか、ぜひともこちらのインタビューも合わせてお読みください!

VoicyがGoLangとEchoを採択した理由。

Voicy社 ITO 伊東です。

現在iPhoneアプリを提供しているVoicyですが、WEB版を鋭意製作中であります。
これまではネイティブアプリ開発用の環境を構築しておりましたが、Webに最適化または双方で使うために環境を構築し直す必要が出てきました。

そこで、今回は環境を構築し直すにあたっての言語とフレームワークの選定についてお話します。

結構いろんな言語と比較したんですが、結果的には GoLang × Echoを採択しました。

言語選定の前提となるミッション

今回はAPIを作るのに適した環境を作るという事が一番重要なミッション。
いわゆるマイクロサービスというやつですね。小さい単位でサービスを作ってAPIを通して各機能を呼び出すということ。そうすることで

  • 開発チームがサービスごとに分かれて、得意な言語を利用して各サービスの開発を進めることができる
  • 変更をかけたいときは、システム全体ではなく、その小さなサービスごとに変更をかけられる
  • 小さなサービスで開発単位を進めるため、ビルドやテストの期間が短くなり開発効率が上がる
  • モノリシックなシステムだと何か障害が起きたときに、どこがおかしいのかルート構造をたどるのに時間がかかるが、原因の突き止めが比較的容易

つまり、用途・目的ごとに小さな(マイクロな)サービスを作っておくことで、「変化に強くて柔軟性の高い、アプリケーション開発を行おう」というのがマイクロサービスなのです。

引用元 https://www.salesforce.com/jp/blog/2016/03/microservices.html

はい、僕の言いたいことを全ていい切ってくれてますね(しろめ
コレガヤリタイカラゲンゴカエルンダ、コジンテキナスキルアップデハナインダ・・・

最適な言語はなんなのか?比べてみた

APIを作るのに適した環境を作るというのを念頭に比較してますが、個人の主観も大きく入っておりますのでその点ご了承くださいませ(しろめ

・Java8 & Lagom

Ruby & Rails

PHP & Lumen

・Python3 & Nameko

GoLang & Echo

を検討致しました。
個人的にはRoRが好きです。
今回はORマッパーを使わない想定です(ふるえ
※別に嫌いではないですがAPIという事で1ミリ秒でも早くレスポンスを返したいという事を優先しております。

Java8 & Lagom

速度    ◎
開発効率  △
API化 ◯
採用    ☓

Java8で以前マイクロサービスを開発をしたことがありまして、結構簡単に出来ましたね。(もともとJava使いだからですが)個人的な主観でいってしまいますが 、
選択したくない(キリ
なぜなら別の言語にチャレンジしたいから(しろめ

RubyOnRails

速度    △
開発効率  ◎
API化  △
採用    ◯

Railsはとても好きなフレームワークで ルーティングも簡単に制御できますし、開発効率も高いです。 Viewを使わずActiveRecordのORマッパーも使わないという事ですと、Railsを採用する意味が大きく損なわれてしまいましたね・・

PHP & Lumen

速度    △
開発効率  ◎
API化    ◯
採用    △

LumenはLaravelのマイクロフレームワーク版で同じIlluminateコンポーネントを使用しております。 ルーティング処理もとても評判が良く、とても悩みました。 PHP自体は使えるエンジニアもとても多く、CakeやLaravel等も開発効率が高くサービスリリースを行う上でとても強い武器になると思います。
が、実行速度が遅い(スクリプト言語に求めるなという話ですけどね)事から却下。

Python3 & Nameko

速度    △
開発効率  ◯
API化 ◯
採用    ◯

Python結構いい感じですね、APIを構築するのにとてもあっている気がしますし、永続処理や非同期処理も様々なツールを合わせることで上手く対応できますね。音声ビッグデータ解析等いろいろ行う予定であるVoicyにとってパイソンは通らなくてはならない道ではあります。適材適所の言語を使用すれば良いと私自身は考えますので、その時にパイソンを選択すれば良いかと思います。

GoLang & Echo

速度    ◯
開発効率  ◯
API化  ◯
採用    ◯

GoLang使いました。 APIを作るために存在しているようなくらい簡単に出来てしまいますね。 継承が出来ないので(無理無理できないことはないけど・・・) コーディングするときに少し戸惑いはありますが ルーティング簡単、APIつくるの簡単(というか、それ以外無理ですねこれ)という形でしょうか。

優勝 GoLang

個人的な権限を行使して、面白そうなGoLangに決めました。

GoLang用のフレームワークの選定(すでにEchoとか書いてしまっておりますが・・)

  • Gin
  • Iris
  • Echo の3つを検討致しました。

結論からいうと、Echoを採用致しました。

フレームワークの実行速度で比較

Gin  734
Echo 879
Kami 1237
Goji   1299
Bone 1463
http   1854
Gocraft 1915
Gorilla 3944
Martini 5823
ns/op

参考記事
http://qiita.com/najeira/items/bdc988c4e93b3b5ccf2f

個人的にはGinかEchoの2択に絞られました。

書きやすさで比較

今回はAPIを作るのに適した環境を作るという事を一番の念頭に入れてはおりましたので、その点でどのフレームワークが書きやすそうかという事を考えました。

参考記事
http://blog.iktakahiro.sh/entry/2016/12/10/090000

http://qiita.com/keika299/items/62e806ae42828bb3567a

実際に書いて動作させてみましたがルーティングがとても簡単。

    // ルーティング
    e.Get("/hello", handle.MainPage())
    e.Post("/hello", handle.MainPage())

これで事が足りてしまいます。

まとめ:GoLangAPI作るならEchoが良さそう!

Go自体並列処理が行うのが得意なので、色々とめんどうな処理もは早く処理できそうですし。

Pythonも最後まで捨てがたかったのですが

  1. 学習コスト
  2. 採用
  3. 実行速度(コンパイルする分早いのは当たり前ですけどね)
    (4.個人の趣味)

でしょうか。
RoRからGolangに移行するひとが結構知り合いにも居ましたが気落ちが大分わかりました。

クラウド放送局アプリVoicyの音声収録から配信までのシステム構成

はじめまして。VoicyでCTOをしている窪田です。

さて、今回は最初の技術記事ということで簡単なアプリの紹介を踏まえながらと全体のシステム構成についてお話ししたいと思います。

Voicyというアプリについて

Voicyとは人の声で聞くニュースメディアです。 最近はITで声と言えばAmazonのAlexaや初音ミクに代表される音声認識音声合成を思い浮かべる方も多いと思いますが、Voicyでは機械ではなく人の声でニュースを届けています。

ユーザーは自分の声でコンテンツを読み上げて配信する「パーソナリティ」と「リスナー」に分けられます。 そのためVoicyのアプリも「パーソナリティが使用する録音用」と「一般リスナーが使用する再生用」の二つがあり、並行して開発を進めています。(現在はiPhoneのみ)

f:id:voice-tech:20170401155929p:plain

Voicy [ボイシー] - ニュースは声で聴く時代へを App Store で

Voicy Recorderを App Store で

使い方としては、オーディションに合格したパーソナリティが録音用アプリでニュース記事を読んだり、好きなことについて語ったりしたものを収録し、一般のリスナーが再生用アプリで聞くという流れになります。

システム構成

Voicyのシステム構成を簡単な図にまとめたものがこちらになります。

f:id:voice-tech:20170401155943p:plain

1. 録音アプリ

録音用アプリは誰でもダウンロードして収録することができますが、再生用アプリへ配信して他の人に聞いてもらうためには、定期的に行っているパーソナリティオーディションに応募して合格する必要があります。そのため、アプリ内では配信権限の有無により項目の表示/非表示制御や、権限チェックが必要になります。もちろん不正アクセスを考慮して、サーバーサイドでも同様に権限チェックを行っています。

アプリで収録した音声ファイルはサーバーへ送られ、その後圧縮、フォーマット変換されます。音声ファイルは動画ほどではないとはいえ、通常のWebサービスに比べると大きなサイズのデータを扱うことになるため、サーバーのメモリ使用量は注意しておく必要があります。現在は十分なスペックを確保できていますが、ユーザー数の増加に合わせて当然見直しが必要になってくるため、モニタリングは欠かせません。

2. 再生アプリ

耳から便利にニュースが聞けるといった機能性だけであれば音声合成で十分です。Voicyでは、それに加えてパーソナリティの個性や人間味といった"その人らしさ"を伝えてたいと考えています。そのため、UIではパーソナリティの写真をメインにデザインし、初めてアプリを開いたリスナーが自分好みのチャンネルに出会えるような情報をトップ画面に載せています。

また、アプリを楽しく操作できるための工夫として、フリックや画面遷移したりするタイミングで効果音を鳴らしています。始めにアプリを開発する時は、音声、BGM、効果音といった音のデータをどう扱うかで苦労しました。例えば、マナーモード中にアプリを触ってる時は効果音鳴って欲しくないけど、再生ボタンを押したら音声は流れるようにしたい。そして音声が流れてる時であれば、音が出ている状態なのでマナーモード中であっても効果音鳴らしてもいいんじゃないか、といった具合です。

3. 記事クローラー

パーソナリティが読む記事を収集するためのクローラで、収集された記事はリアルタイムに録音用アプリに表示されます。クローラー毎日新聞スポニチといった提携メディアから記事を取得していますが、取得方法がメディアによって異なるため、提携先が増えるたびにクローラーを開発する必要があります。

とはいえ毎回ゼロから作るわけにもいかないので、クローラーのための共通フレームワークを自作し、面倒な処理のほとんどはフレームワークで行えるようになっています。フレームワークも一度作って終わりではなく、常に改善しているため、当初新しいクローラーを追加するのに丸一日かかっていた作業が、現在は早ければ1時間かからず、長くても3,4時間あれば作れるまでに効率化されました。

4. バッチ処理

上記以外にも、日次レポートの作成やキャッシュデータの更新といったバッチ処理が定期的に実行されています。こちらもクローラー同様に共通フレームワークを自作しているので、新しいバッチを追加する際でも、エンジニアは面倒なことは気にせずにビジネスロジックだけに集中して開発できるようになっています。

最後に

いかがでしたでしょうか。とても簡単ではありましたがVoicyが声を届けるための仕組みを紹介させていただきました。今後はそれぞれのシステムで使用されている技術ついて、もっと詳しく紹介していければと思います。

Voicyのサービスはまだ始まったばかりで、これからどんどん進化していきます!また、まだお話できないような新しいサービスもいろいろと考えております。その実現のためにもVoicyでは現在エンジニアを絶賛募集中です!ちょっと話を聞いてみたい、ベンチャーの雰囲気を感じてみたいといった理由でも構いませんので、ぜひ一度オフィスに遊びに来てください。

www.wantedly.com

パーソナリティをやっている声優やアナウンサーの方々もふらっと遊びに来てくれる、とてもフレンドリーでアットホームなオフィスです! こんなメンバーが働いている現場です。 よろしければインタビューもぜひご覧ください!

Voicy、テックブログはじめます。

ついにVoicyでもテックブログを開設いたしました!

以前からやろうやろうという話はしていたのですが、なんやかんやでサービスリリースから半年も経ってしまいました。これからは社内で使用している技術や開発手法はもちろん、声のベンチャーであるVoicyらしく 声 × IT の Voice Techというトピックをみなさんにお届けしていきますのでお楽しみに!

さて、今回は初回エントリーということで、Voicyという会社はどんな会社なのか、そして、Voicyでエンジニアとして働くことの面白さについて書いてみたいと思います。

Voicyってどんな会社?

株式会社Voicyは2016年に設立されたスタートアップです。
声で新しい文化を作るをビジョンに

  • 世の中に新しい価値を生む
  • 誰もやらないことをやる
  • 自分たちが最高に楽しむ

をミッションに掲げています。
2016年9月に声のメディアアプリVoicyをリリース、2017年3月にエンジェルラウンドでの資金調達に成功しました。

どんな人が働いているのか

メンバーの半数以上が熟練度の高いエンジニアとデザイナーで、残りのメンバーもビジネスマンとしての経験値の高い人が集まっています。人数規模はまだ小さいですが、全員が個性豊かなプロフェッショナル集団です。

開発の中心メンバーはエンジニアとして15年以上のキャリアを持つCTOの窪田、数々の企業やスタートアップで事業を作ってきたCIOの伊東の2名です。
代表の緒方がこれではCTOが二人になってしまう、伊東の役職はITOにするしかない…と悩むくらいに技術力の高いメンバーです。以下のインタビューでこれまでのキャリアや初期の開発裏話が語られています。

サービスではなく「業界」を作りたい。まだスタンダードがない分野へ挑戦し続けるCTOのVoicyアプリ開発秘話 | Voicyのメンバー紹介ブログ
自分たちの想像すら超える新しい文化を作りたい。超大規模インフラ開発から超ドベンチャーへ転職したCIOのVoicyジョインストーリー | Voicyのメンバー紹介ブログ

Voicyでエンジニアとして働く面白みとは

サービスにダイレクトに関わりながら進めるアジャイル開発

現在のVoicyは社員番号一桁台、アプリも正式ローンチしてまだ半年のフェーズ。そのため仕様書が降りてきてそれを淡々とこなしていくような開発ではなく、サービスにダイレクトに関わりながらアジャイル的な開発に携われます。たとえばアプリをこういう使い方をしている人は離脱率がこれくらいだね、どうしたら改善できるだろう?というような会話にエンジニアも参加していたりします。

エンドユーザーの声を直接聞ける

また、エンドユーザーと接する機会が多いのも特徴です。通常、自分が開発をしているプロダクトを実際に使ってくれているユーザーと会う機会はそこまで多くはないと思います。Voicyではアプリを使ってくれているユーザーがオフィスにフラっと遊びにきてくれたり、ユーザー感謝祭を開催したりと、エンジニアも直接ユーザーの声を聞く機会があります。 直接話してわかる気づきもありますし、純粋に、自分が作ったものを目の前で「これすごくいいですね!」と言ってもらえるのはやっぱり素直に嬉しいですよね。

音声という新たなインターフェース

Voicyは音声という新たなインターフェースの可能性を信じています。
現在運営しているアプリは、「声」でニュースを聴くアプリ。活字コンテンツに声の魅力を加えることにより、「体温のある情報を届けるプラットフォーム」を実現しました。

まだ公にできないこともありますが、今後も音声という未来のインターフェースを使ってまだ誰もやっていないサービスを開発していくつもりです。そこにエンジニアとして関われるというのは技術的にも、また文化を作っていくという意味でも非常にやりがいがあるといえます。

おわりに

ずっと開発の中心メンバーは窪田と伊東の2名です。とお伝えしてきましたが、中心というか実はフルコミットの開発メンバーが窪田と伊東しかいないんですよね。 というわけで一緒にサービス開発をしたいエンジニアも絶賛募集中です。

www.wantedly.com

アットホームなオフィスなのでちょっと話を聞いてみたいという方も気軽にコンタクトをくださればと思います。

今回は初回のエントリということで、技術的なことにはあまり触れませんでしたが、今後は窪田と伊東が社内で使用している技術や開発手法などを発信していく予定です。 ぜひチェックしてみてくださいね!