有料購読ニュースアプリAxionの今後の製品開発について

0. イントロダクション

このブログは、有料購読メディア「Axion」の長期的な製品開発の要点とロードマップを書いたものだ。ウェブサイト自体は必要最低限の状態ですでに存在している（このサイトで有料購読を開始することも可能だ）。Axionは現在「プロダクトユーザーフィット」（Product User Fit）の状態に到達し（詳しくはこちら）た。さらなる開発が必要になるのは確実だ。

構成は[1]ビジネスの目的、[2]デザイン、[3]開発、[4]付記の流れである。[1]から読むと理解が進むように書いたつもりだが、もちろん自分の好きなところだけを読んでもらってかまわない。

• 本ブログの目的。このタイミングで、1) 開発面の行程を整理しておく、2) 将来的にチーム形成を進める際の手がかりにする 3) 外部の人にどのような製品を作ろうとしているか開示することである。
• 想定読者：開発者、プロダクトマネージャー、デザイナー。ビジネスサイドの人も[1]と[2]は読めるようにできている。

1. ビジネスの目的

1.1 ビジネスのキーポイント

サブスクリプションモデルの採用により、広告モデルの弊害を回避。推薦システムの目的を「インプレッション」（デジタル広告の表示回数）にまつわるものから「ユーザーの長期的幸福」に転換する。

1.2 概要

Axionは有料購読ニュースアグリゲータ。推薦アルゴリズムがユーザーの長期的なWell-being（幸福）の最適化を目的に、コンテンツを推薦する（詳しくは弊社のビジョンとミッションを参照）。

従来型のニュースアグリゲータの課題は、広告による収益化によって、低品質なコンテンツをプッシュする傾向が強いことだ。従来型の推薦システムは「フィルターバブル」を生じさせており、特に政治社会における極性化の要因の1つと考えられている。広告モデルを採用している限り、人間による編集部が記事を推薦している場合でも、同様の傾向が見られる。

このような低品質なコンテンツがあふれるニュースアグリゲータのコメント欄や、それを引用するソーシャルメディアでは、恒常的にトロール（扇動）が行われている。

1.3 ビジネスモデル

サブスクリプション（有料購読）。有料購読者は月額2000円を支払う。非購読者はサインインの後、月に数本の記事を無料で読むことができる。

収益分配。サブスクリプション収益の多くの割合をコンテンツ提供者に分配する。分配のロジックは記事の「質」を評価し、クリックベイトを抑制するものにする。

1.4 推薦システム

推薦システムはコンテンツとユーザーを適切にマッチングさせる上で、必要不可欠なものだ。Axionの両面市場（Two-sided Market）においても、両者のエンゲージメントを保つための重要な装置だと私は考えている。

Contextual Banditやコンテンツベース、協調フィルタリング等を用いた推薦アルゴリズムはしばしば、「フィルターバブル」と表現される思想の自己強化のメカニズムを引き起こす可能性がある。それは近年の深層学習を活用したより複雑なモデルを採用したときでも顕著である。機械学習の門外漢の私が考える解決策は、ビジネスモデルの転換により、アルゴリズム設計の前提を変更することだ。

1.41 ビジネスモデルと推薦システム

課題：ステークホルダー間の目的の不一致。広告モデルを採用したニュースアグリゲータは、コンテンツ提供者、プラットフォーム、ユーザー、広告主の四者の目的が噛み合わず、解決不能な問題に直面する。ステークホルダーの中に敗者を生み出す傾向がある。多くの場合、コンテンツ提供者が「敗者」になる（図2左）。敗者とされたコンテンツ提供者には、低品質記事を製作するインセンティブが生じたり、高品質記事の供給を停止したりする傾向がある。その結果、ニュースプラットフォームを流通するコンテンツの質が悪化する。これが社会に対し愚民化政策のような形で働いている可能性も否定できない。

解決策：直接的な関係。他方、サブスクリプションを採用したニュースアグリゲータでは、需要側（購読者）と供給側（コンテンツ提供者）の関係が明確であり、プラットフォームが両者の便益を向上することにより、両面市場が上手く機能する（図2右）。

1.5 ビジネスの展望

このビジネスの鍵は、ネットワーク効果（ネットワーク外部性）が生じるかである。需要側と供給側の双方で「same-side network effect」が生じ、同時に双方の垣根をまたいで「cross-side network effects」が生じれば、大きな成長を享受できるだろう。

「流動性ネットワーク効果」（liquidity network effect）はコンテンツ提供者（パブリッシャー）とユーザーの間の正のフィードバックに関するものだ。これは、①コンテンツ提供者が供給を増やす②それによってユーザーの選択肢が増える③ユーザー数が増える④コンテンツ提供者への報酬が増える⑤コンテンツ提供者が増える――が循環する可能性を示している。

有料購読は、価格を一定に据え置くが、価格が効用で定められると仮定した時、購読者が購読を継続する鍵は、サービスの価格に相当する効用以上の効用を得られていることとなる。したがって質の高いコンテンツを大量に用意し、その流通を推薦システム通じて最適化することで、購読者の効用を引き上げる必要性がある。

日本ではスモールサイズのIPOが可能なため、一部のプレイヤーにはビジネスの実質的な基礎を作らずに上場を目指す傾向がある。これは我々の好むところではない。世界にとって意義のあるビジネスを生み出すため、株式会社アクシオンテクノロジーズは、会社のタクトを自らコントロールすることを優先事項の一つとする。Axionは長期主義的で、確かな成長を楽しむことを志向し、人類を前にすすめることを目的としている会社だ。

2. デザイン

2.1 デザインコンセプト

高品質、高い信頼性、権威。上述したように広告モデルのニュースアグリゲータでは、脊髄反射を誘う低品質なコンテンツが溢れている。情報の洪水の中で、Axionを選択しておけば、フェイクニュースやトロール（扇動、ネット工作）に騙されることなく、幸福に暮らすための知識が得られる、とユーザーに納得してもらう。Axionはそういう製品だ。

2.2 対象ユーザーのペルソナ

「50歳以下の急速なデジタル化へのキャッチアップが必要なビジネスパーソン」。ユーザーインタビューの結果、これらの層には、現状のスキルセットが役に立たなくなることへの不安と、実質賃金が低下する中、転職や昇進などで給与を上げないといけない危機感の双方を私はユーザーインタビューを通じて観測した。

このような傾向は特にデジタル化の切っ先にさらされている金融、メディア、コンサルティング、会計事務所、士業、商社、通信、消費財メーカー、小売、自動車、電機などで見て取れた。これらの業種のビジネスパーソンはすでにAxionの読者である。

2.3 Webとアプリの違い

Webは非購読者が多数、モバイルはほぼ購読者限定。全利用者96％がWebを通じてAxionのサービスに触れ、残りの4％がWebとモバイルアプリを併用する。ユーザー数の大半は、デスクトップWebとモバイルWebのみを利用する。しかし、モバイルアプリは購読者という最も重要なユーザーが利用する。つまり、Webはオーディエンス向け、アプリはロイヤルカスタマー向けのデザインが求められる。

大半の訪問はウェブでもたらされるが、購読者の訪問の半分はアプリでもたらされる。職場のデスクトップとスキマ時間のモバイルアプリにまたがる体験を形成できるかが解約率低下の鍵になる。

Webサイトのデザイン

あなたが見ているこのサイトです。

Appのデザイン

https://sketch.cloud/s/YMwLe/eP09Om/play

3. 開発

3.1 Overview

• Axionは、JavaScriptライブラリ / NodeJS で作られたシングルページアプリケーション（SPA）であり、iOS / Androidのモバイルアプリである。
• コンテンツ提供者から取得した記事を、推薦システムで個々のユーザーに対しパーソナライズされた形で提示する。
• この製品を他と差別化するのは、ダイナミックペイウォールと推薦システムであり、どちらもデータ分析と機械学習を活用したものである。
• ここに示したロードマップは、将来を見通すために設定された仮の計画であり、それぞれの開発者の判断によってベストプラクティスを実行する。
• ビジネスの進展が伴わないと必要性が生まれない開発プロセスが多々あり、状況を勘案しながら時期や計画を逐次変更する。

3.2 ロードマップ

以下の順序で開発を進める。

ウェブアプリケーションの開発を優先し、「ニュースのNetflix」のためのバックエンドのServicesを構築したのち、モバイルアプリケーションを開発する。

1. ウェブアプリケーション (3.3)
2. クローラー (3.4)
3. データ基盤 (3.5)
4. ペイウォール (3.6)
5. レコメンド (3.7)
6. モバイルアプリケーション (今回は触れない)

3.3 ウェブアプリケーション

3.31 構成

• シングルページアプリケーション（SPA）。React等のJS LibraryによるクライアントとBFFの構成。バックエンドではサーバーの管理をせずにAWS Lambdaかそれに類するサービスでコードを実行する。フロントエンドとバックエンドが非同期的なことが特徴。
• マイクロサービス。アプリケーションをコア機能ごとに細分化する疎結合的なアーキテクチャ。個々のサービスが正常に機能してもしなくても、他のサービスに悪影響を及ぼさない。開発を少数のチームに細分化できるため、大規模サービスの運用にも適している。
• BFF（Backend For Frontends）という「フロントエンドのためのバックエンド」という概念。一般的なAPIオーケストレーションと異なるのは明確にフロントエンドを意識していることで、APIのトランザクション集約やCORS（Cross-Origin Resource Sharing）対応、フロントエンドには扱いづらいプロトコルの仲介を行うなどして、フロントエンドが扱いやすいJSONを提供する。SEO対策のためのSSR（Server Side Rendering）を担う。

3.32 購読料支払い

Axionでは購読料の支払いに関してStripe Billingを利用する。Stripe Billing API は、既存のウェブサイト、モバイルアプリに定期支払いを組み込める。段階制料金体系を構築する Tiered Pricing や毎月の利用料に応じて請求できる Metered Billing といった仕組みを適用できる。

Stripe Billingでは以下のような様々な種類の請求モデルを適用できる。Axionは、初期のうちは、非常にシンプルな請求モデル（定額見放題）を採用。コンテンツが多様化されたら、複雑化を検討する。

• 段階制の請求モデル - Tiered Pricing。2種類ある。利用量に応じ単価が異なる段階制モデル（最終的に使われる単価は一つ）と利用量に応じ単価が累進的に利用される段階制モデル（最終的に使われる単価は複数又は一つ）。
• 利用量に応じ単価が累進的に利用される段階制モデル。利用料を階層にわけ、階層ごとに単価を適用する。ドキュメント。
• 従量制の定期支払いモデル - Metered Billing。該当期間の利用量をもとに、請求金額を決め後から請求する手法で、従量課金制などともよく呼ばれるモデル。metered billing では、subscription を開始した時点では請求は発生しません。利用量 (quantity) を更新する必要があるため、Usage を API 経由で更新していく必要がある。ドキュメント。

3.33 許可と認証

Axionは許可と認証に関してAuth0を採用する。Auth0を採用する利点は、非常に複雑なアイデンティ関連の開発を外部化できるだけでなく、様々な用途に対応している所もある。

• Auth0は、Mobile Native AppやWeb API、Single Page Applicationに対応
• OAuth 1.0/2.0やOpenID Connectと言ったオープンな認証・認可方式に対応
• 多要素認証にも対応しており、Auth0が提供しているAuth0 Guardian MFAだけでなく、Google AuthenticatorやDUO Securityなどの多要素認証(MFA)も利用でき、EmailやSMSを介してOTPを送信する、Passwordless認証にも対応している
• ユーザーストア(Connection) にはAuth0標準 (ビルトイン) であるMongoDBはもちろんのこと、企業がすでに使用している各種DBやActive Direcotry,LDAPなど複数のユーザーストアを利用することができる
• 様々なソーシャルネットワークのアカウントを利用したユーザ認証・認可を簡単に利用することが可能
• Native, SPA, Web/App Server, CLIなど約80種類のフレームワークに対するサンプルプロジェクトをgithubに公開しており、これを利用することで簡単に既存アプリケーションをAuth0と連携することができる

3.34 サイト内検索

Axionは当面、検索とそのためのデータベースとして Elasticsearchを採用する。ElasticsearchはApache Lucene を基盤として構築されたオープンソースのRESTful分散検索/分析エンジン。LogstashとBeatsは、データの収集、集約、抽出を容易にし、Elasticsearchにデータを保存する。Kibanaを使用すると、インタラクティブにデータのインサイトを探索、可視化、共有し、スタックを管理、監視することができる。

マスタデータは、マスタDBに格納。マスタデータをElasticsearchにインポートするコマンドを作成。データ書き込みは、マスタDBとElasticsearch 両方に書き込まれるようにする。

• Elastic App Searchは、オープンソースの分散型 RESTful 検索エンジン Elasticsearch の上に構築されている。Elastic App Searchを使用すると、開発者はアプリケーション検索のユースケースを処理するために最適化されたAPIエンドポイントの堅牢なセットへのアクセスを得ることができる。
• フルマネージドのElasticsearch Service。Elastic社のクラウド製品のほか、AWSのAmazon Elasticsearch Service、GCP、Azureにも同様のサービスがある。Amazon Elasticsearch Serviceは、Elasticsearchクラスターを数分でデプロイできる。

3.36 CMS

基本的には車輪の再発明はしない。「ありもの」のCMSを採用する。

3.361 Headless CMS

ヘッドレスCMSは、RESTful APIを介してコンテンツにアクセスし、あらゆるデバイスで表示できるようにするバックエンド専用のコンテンツ管理システムのことを指す。以下の2つが有望な候補。

• Contentful
• Ghost CMS

あるいは、WordPress（それか他のCMS）をEC2で構築し、WordPressサイトを静的ページに変換するプラグインを導入し、サイトをhtmlファイルとして出力、その後、Amazon S3へ転送し、CDNと連携して、フロントエンドに記事をプッシュする形を採用する可能性がある。

3.37 CDN

Fastlyを使用する。Fastlyの利点はVCLを使って設定変更し、柔軟にキャッシュを制御できること。キャッシュの削除が150msで終わる。日本経済新聞社、Financial Times等での実績があり、柔軟なキャッシュ制御性能は、ニュースメディアコンテンツの配信に最適。

3.371 基本方針

• CDNで実行できることは基本的にはCDNに任せる
• 動的なコンテンツもCDNで配信する
• VCLで柔軟にキャッシュを制御する

3.372 動的コンテンツの配信とキャッシュについて

トップページは更新頻度が欲しいから30秒ごとにキャッシュし、個別の記事ページはさほど更新されることがないので5分ごとにキャッシュする。そういうかたちで個々にキャッシュコントロールを柔軟に制御。

3.4 クローラー

Axionは契約を交わしたプレミアムコンテンツ提供者のコンテンツをアグリゲイトする。Axionは、高品質コンテンツに集中するため、収集するコンテンツ量は、先行例のJinri Toutiao、SmartNewsなどと比較すると、少なくなると想定される。

クローリングはウェブサイトからHTMLや任意の情報を取得する技術で、 スクレイピングは取得したHTMLから任意の情報を抽出する。クローリングにはMechanize、Nokogiriなどの方法がある。スクレイピングにはBeautiful Soup、XPathなどの方法がある。

3.41 クロール、スクレイピングから推薦までのフロー

1. クロール
2. スクレイピング
3. インデックス
4. 推薦基盤がインデックスから「候補」を抽出する

クローラーがコンテンツ提供者のウェブアプリケーションを定期的に訪れ、情報を取得。スクレイピングしたデータをAmazon S3に格納する。集めた記事をインデックスし、推薦アルゴリズムの実行を容易にする。推薦基盤は、インデックスされたデータから各読者にふさわしい記事の「候補」を選定し、最終的に読者のコンテクストなどにふさわしい記事群をクライアントに送信する（図8）。

3.5 データ基盤

データ基盤は、データ分析だけでなく、集計・レポーティングや機械学習にも使う。この製品の要所であるダイナミックペイウォールや機械学習、それから本ブログでは触れないが、マーケティングにおいても重要な役割を果たす。基盤はアドテクノロジーのDMPを含むことになる。

AxionはMLOps、を中核的な提供価値の根源と捉えているため、目的に沿ったデータ基盤を構築したい。

3.51 基本的な構成

• データレイク。元のデータを加工せずそのまま1つのシステムに集約したもの。データソース（水源）から流れてきたデータをそのまま蓄える場所なのでレイク（湖）。S3やGCSなどのストレージサービスを使うことが多い。
• データウェアハウス。複数のデータを統合・蓄積して、意思決定に活用できるように整理したものです。 大量のデータを意味のある形で管理することからウェアハウス（倉庫）
• データマート。特定の利用者・用途向けにデータを加工・整理したもの。 すぐに使える完成品を取り揃えていることからマート（市場）と呼ぶ。

3.52 ワークフロー

実際に毎日の運用の中で定期的にデータを更新して、可視化するためには、一連の処理を自動化する必要となる。データパイプライン （⁠以下，パイプライン）は、データ処理を行なう小さなタスク（1回のファイルコピーや，SQLの実行など）を順次実行することにより，最終的に求める結果を得るための一連のプロセス。ワークフロー管理は、指定した時間に複数のジョブを実行し、各ジョブの進行を管理するためのシステムを指す。たとえば、ジョブのスケジュール実行、ジョブの依存関係の解決、エラー時の通知や自動リトライ、指定したジョブの再実行、過去の実行履歴の管理などといった機能がある。

3.6 ペイウォール

ペイウォールの構築にはデータ基盤（3.5）の設計が必要である。また、別個ではサイトを訪問者やログインユーザーの行動をトラックする技術の実装も必要である。

3.61 Access Control Management

アクセス制御管理（ACM）モジュールの主な機能は、ウェブサイト上の個々のユーザーを識別し（認証）、要求されたコンテンツへのアクセスを許可するかどうかを決定することだ。最初に、ユーザは、ウェブサイト上の特定のコンテンツ単位へのアクセスを要求する。

ACMモジュールは、CookieまたはJavaScriptのような技術を使用して、利用可能な多数の識別パラメータを収集することにより、個々のユーザを追跡し、識別する。ユーザーがコンテンツにアクセスする資格がある場合、サーバーがコンテンツページを配信し、アクセスが許可される。そうでなければ、ACMモジュールは、ユーザの資格情報を検証するために、ユーザをログインページに誘導する。

検証が成功した場合、許可されたユーザーは要求されたコンテンツにアクセスすることができる。しかし、検証が成功しなかった場合、ACMモジュールは、ユーザーが認証されるまで、要求されたコンテンツへのアクセスをブロックする。

3.62 ペイウォール開発の手順

1. メーター制ペイウォールを構築
2. 得られたデータを基にダイナミックペイウォールを構築

3.63 メーター制ペイウォール

ログインユーザーのページ閲覧回数をCookie等で追跡することでメーターを設定できる。

• 月に事前に規定された回数の無料記事の閲覧を許可
• それ以上に達するとペイウォール画面を表示。翌月まで続く。
• 欧米のベストプラクティスは、閲覧許容回数を月5回以下に抑えること。
• ブラウザのincognitoモードでメーターを回避できる「抜け穴」があったようだが、他のユーザーをトラックする手段があるようだ。

3.64 ダイナミックペイウォール

ダイナミックペイウォールのほかに、適合的ペイウォール（Adaptive Paywall）、フレキシブルペイウォール（Flexible Paywall）等の呼称が存在する。

カナダ全国紙の実データを利用した唯一の論文では、ペイウォールを提示するべきかいなかの問題を、逐次決定過程と捉え、近似動的計画法によって定式化。カナダ全国紙の実データを利用し、ハードペイウォールや標準的なモデルと比較すると、著者のDavoudiらの提案したモデルは、大幅に好ましい購読パフォーマンスを得た。

問題の定式化手法は、強化学習の枠組みと似ているため、強化学習の適応を検討したい。ある環境において長期的な収益の期待値を最大化するような行動系列を学習するため、強化学習モデルを採用したペイウォールは、得られるフィードバックを活かしながら、長期的な報酬を最適化していくと想定される。

3.7  推薦システム

推薦システムの構築にはデータ基盤（3.5）の設計が必要である。また、ユーザー行動を追跡をする技術の実装が必要でもある。最初の着地点として、簡易なデータ基盤だけでも実現できるオープンソースの推薦システムは存在するが、それが、有料購読型ニュースメディアにそのまま応用可能かどうかは検証が必要だ。

3.71 留意点

• 弊社の推薦システムでは、強化学習を採用した場合、目的関数を「ユーザーの長期的な幸福（Well-Being）」に類するものに設定する（弊社のビジョンを読んでほしい）。Axionはサブスクリプション型で直接課金をしているため、広告型が採用するような、広告収益を最大化する（ときにはユーザーをハックする）目的関数を設計する必要がない。ユーザーのための推薦に集中できる。ここが大きな競争優位性になる、と考えられる。
• 近年、推薦システムのフィードバックループ（いわゆるフィルターバブル）により人の思想が変化したり、自己強化サイクルに入ったりする可能性が指摘されている。弊社はそれを防ぐため、探索的なアルゴリズムの採用やユーザーが推薦システムのチューニングを実行できるような仕組みを採用する。
• 両面市場（Two-sided Market）のネットワーク効果を高めるためにも、ユーザーが無数のコンテンツの中から、自身にあったものとマッチングできるようにする推薦システムの重要性は高い。

3.72 推薦システムのフロー

このようなフローになるはずだが、段階ごとにどのような処理を行うかは、機械学習の門外漢の僕にはわからない。適切な画を書くためにも優秀な人材の獲得が求められる。

3.73 ニュースの価値は時間減衰する

ニュースの価値は時間とともに減衰する。ログがたまったときにはニュースの価値は低下する（Tekeshi Yoneda et al. 2019）。これらの解決策のひとつとして、弊社はコンテンツを、新聞社が扱うような短期的な消費のためのものではなく、雑誌や書籍のような長期的な知識のためのものを扱うようにする。これで一定程度、価値時間減衰の問題と戦うことができる。音楽推薦や映画推薦と同じ問題に落とし込めると好ましいが…こればかりはやってみないとわからない。

4. 付記

• 開発のタイミングごとにクリアするべき条件が存在する。それは技術的なものもあれば、ビジネス的なものもある。それを留意しながら、製品開発を進めていくべきだ。
• Axionの鍵は、データ基盤とその応用である。具体的な応用先は、推薦システム、ダイナミックペイウォール、マーケティング、開発、ビジネスインテリジェンスなどだ。
• これらを開発し、私の想像力の外まで拡張するための開発者の獲得は、長期的な課題になる。

参考文献

1. AWS. Amazon CloudFront とは.
2. @horike37 "Auth0+DynamoDBでユーザ認証基盤を作る" 2018年10月18日に更新. Qiita.
3. Auth0 Doc. "Amazon API Gateway Tutorial - Adding Security and Deploying".
4. @TakahikoKawasaki. OAuth 2.0 全フローの図解と動画. 2020年03月20日に更新.
5. @y_toku. Stripe Billing 101. 2018年10月09日に更新
6. Gojko Adzic. S3 or DynamoDB?
7. Elasticsearch. "Elasticsearch Reference".
8. Kaoru Nasuno. "クローリングとスクレイピング".
9. "クローリング・スクレイピングの技術を知る". 技術評論社.  2019年8月30日.
10. ビッグデータ分析のシステムと開発がこれ1冊でしっかりわかる教科書 渡部 徹太郎
11. 高橋達. "第9回［最終回］データパイプラインのためのワークフロー管理". 2015年12月7日.
12. Takeshi Yoneda et al (2019). "Algorithms and System Architecture for Immediate Personalized News Recommendations". WI '19: IEEE/WIC/ACM International Conference on Web Intelligence, Thessaloniki, Greece, October 2019.
13. "Customize your feedly with the look and feel that best suits you". Feedly blog. September 14, 2015.
14. Sam Newman. Pattern: Backends For Frontends. Nov 18 2015.

Photo by 🇨🇭 Claudio Schwarz | @purzlbaum on Unsplash