Stan on suzuna's memo

ConoHaオブジェクトストレージをboto3で使ってみる

Thu, 11 Dec 2025 00:00:00 +0900

この記事はConoHa Advent Calendar 2025の11日目の記事です。このはのアドカレは3年ぶりの参加です。

今年はあんずちゃんがいっぱいツイートしてくれて嬉しいです。

さて、2025/8/28に、ConoHaのオブジェクトストレージはS3互換APIを提供開始しました。

S3互換APIがあるということは、オブジェクトストレージの代表格であるAmazon S3を操作するAWS CLIや、AWSのPython SDKであるboto3が使えてうれしいところです。

この記事では、AWSリソースを操作するPythonライブラリのboto3を使ってConoHaのオブジェクトストレージを操作してみます。S3の経験はあるけどConoHaオブジェクトストレージは使ったことがない人の参考になれば幸いです。

ConoHaオブジェクトストレージとは

名前のとおり、ConoHaが提供するオブジェクトストレージです。

実際に使用した容量にかかわらず、確保した容量に対して100GBあたり545円/月の料金がかかります。その一方、1時間単位で使った時間分だけ課金されるので、試しやすくていいですね。また、S3やGoogle Cloud Storageなどと異なり、アウトバウンドの通信に転送料金がかかりません。

ConoHaオブジェクトストレージはオープンソースのオブジェクトストレージであるOpenStack Swiftで構築されています。そのため、従来はOpenStack SwiftのAPIを叩くか、OpenStack SwiftからS3に「翻訳」してくれるS3Proxyをローカルなどに立てたうえでS3相当の操作をする必要があり、S3と同様に扱うには若干の壁があるのが正直なところでした。

S3互換APIがあれば、S3との差異をあまり意識することなく操作できて扱いやすいですね。

事前準備

まずはオブジェクトストレージを使う前に準備をしておきましょう。手順は以下の通りです。

オブジェクトストレージの契約
APIユーザーの作成
EC2 Credentialの発行

オブジェクトストレージの契約

事前にConoHaのコントロールパネルにログインし、左のパネルから「オブジェクトストレージ」を選び、適当に容量を選択します。お試しならまず100GBでいいでしょう。公式マニュアルに画像付きで分かりやすくまとまっているのでこれを参考にしてください。

mendoitarou_さんの昨年のアドカレの記事も分かりやすいです！（ConoHaのオブジェクトストレージを使ってみる #Conoha - Qiita）

APIユーザーの作成

次に、APIユーザーを作成したことがない場合は、公式マニュアルに従って、コントロールパネルの左のパネルの「API」からAPIユーザーを作成しておいてください。

EC2 Credentialの発行

こちらも既にやったことがあれば飛ばしてOKです。

EC2 Credentialは、ConoHaのオブジェクトストレージをS3互換APIから操作するのに必要なクレデンシャルです¹。AWSのaws_access_key_idとaws_secret_access_keyに相当します。

まず、コントロールパネルの「API」を開きます。

ちょうど端っこからこのはちゃんが見えてかわいいですね。

以下をそれぞれメモしておきます。

APIユーザーの「ユーザーID」
APIユーザーの「パスワード」
テナント情報の「テナントID」

EC2 Credentialを発行するためにはトークンが必要なので、先にトークンを発行します（公式マニュアル）。

次に、EC2 Credentialを発行します（公式マニュアル）。

合わせて、こんなコードで発行できます。このコードを含め、本記事の全てのコードはPython=3.13.7, boto3=1.42.5, botocore=1.42.5で実行しました。

クリックで折り畳みが開きます

import os
import requests
# os.environの各Keyの環境変数に設定していることを前提とします
# コード中べた書きでもいいですが、セキュリティ上推奨しません
# それぞれ順に
# - APIユーザーの「ユーザーID」
# - APIユーザーの「パスワード」
# - テナント情報の「テナントID」
api_user_id = os.environ["CONOHA_API_USER_ID"]
api_user_password = os.environ["CONOHA_API_USER_PASSWORD"]
tenant_id = os.environ["CONOHA_TENANT_ID"]
# トークンの発行
auth_url = "https://identity.c3j1.conoha.io/v3/auth/tokens"
auth_data = {
"auth": {
"identity": {
"methods": ["password"],
"password": {
"user": {
"id": api_user_id,
"password": api_user_password
}
}
},
"scope": {
"project": {
"id": tenant_id
}
}
}
}
resp = requests.post(auth_url, json=auth_data)
token = resp.headers["x-subject-token"]
# EC2 Credentialの作成
credential_url = f"https://identity.c3j1.conoha.io/v3/users/{api_user_id}/credentials/OS-EC2"
credential_data = {"tenant_id": tenant_id}
resp = requests.post(
credential_url,
json=credential_data,
headers={"X-Auth-Token": token}
)
credential = resp.json()["credential"]
access_key = credential["access"]
secret_key = credential["secret"]

api_user_id, api_user_password, tenant_id, access_key, secret_keyは他人に知られないよう管理に注意してください（tokenは有効期限が24時間ではありますが、これも漏らさない方がもちろんよいですね）。

access_keyとsecret_keyの中身をそれぞれメモしておいてください。EC2 Credentialは1ユーザーにつき3つしか作成できません。もし忘れた場合は、同様にAPIで既存のEC2 Credentialを削除してから再度作成してください。

boto3を使ってConoHaオブジェクトストレージで遊んでみる

参考: Object Storage API｜ConoHaドキュメントサイト

clientインスタンスの作成

まずはboto3.clientを作ります。

import boto3
from botocore.config import Config
cli = boto3.client(
"s3",
endpoint_url=endpoint_url,
aws_access_key_id=access_key,
aws_secret_access_key=secret_key,
config=Config(
signature_version="s3v4",
request_checksum_calculation="when_required",
response_checksum_validation="when_required",
),
)

endpoint_urlは、先ほどのコントロールパネルの画像の「エンドポイント」の「S3 Service」のURLです。

ポイントは、request_checksum_calculation="when_required"と、 response_checksum_validation="when_required"を指定することです。"when_required"にしておかないと、オブジェクトをアップロードするときにXAmzContentSHA256Mismatchなどというエラーが出ます。

S3が提供する新しいチェックサム機能に合わせて、boto3>=1.36.0では、これらの引数はデフォルトで"when_supported"になりました。boto3のissueでは、S3互換ストレージでは対応していないものもあるため、エラーが出たら"when_required"にするようにとありますので、そのとおりやってあげれば回避できます。

これは地味にはまりポイントでした。

コンテナの作成

S3をboto3で操作したことがあれば、ここからは全く同じ操作で扱うことができます。

コンテナとはS3でいうバケットに相当するものです。conohaという名前のコンテナを作ってみます。

cli.create_bucket(Bucket="conoha")

コンテナのリストアップ

作ったコンテナをリストアップします。AWS CLIでいう、aws s3 ls相当の操作です。

response = cli.list_buckets()
for bucket in response.get("Buckets", []):
print(bucket["Name"])

conoha

今作ったconohaがありますね！

オブジェクトのアップロード

2025年12月に公開されたばかりの、このはちゃんの清楚かわいい冬壁紙をアップロードしてみます。

壁紙は公式サイトからダウンロードできます。眺めていると幸せな気持ちになれますね。皆さんもダウンロードして自分のデバイスの壁紙に設定しましょう。昨今の公式素材といえばSNSアイコンが多い印象ですが、壁紙を配布してくれていて大変ありがたい…

わたしが好きなのはこのおまつりこのはちゃんですね。これはきっと夏の終わりに見た幻…

さて、さっきの冬壁紙（conoha-wallpaper-2025winter-1280x800.jpg）を、コンテナconohaに、mikumo/conoha.jpgというkeyでアップロードしてみます。S3でいうところのs3://conoha/mikumo/conoha.jpgにアップロードするということです。

cli.upload_file("conoha-wallpaper-2025winter-1280x800.jpg", "conoha", "mikumo/conoha.jpg")

オブジェクトストレージなのでディレクトリという概念はありませんが、keyをスラッシュで区切ることで仮想的にディレクトリのような階層構造で扱うことができます。

オブジェクトのリストアップ

conohaというコンテナにある全てのオブジェクトをリストアップします。aws s3 ls s3://conoha相当の操作ですね。

# 以下はオブジェクトが1000件を超える場合ページネーションが必要
# resp = cli.list_objects_v2(Bucket="conoha")
# for obj in resp.get("Contents", []):
# print(obj["Key"])
# こちらはページネーションに対応
paginator = cli.get_paginator("list_objects_v2")
for page in paginator.paginate(Bucket="conoha"):
for obj in page.get("Contents", []):
print(obj["Key"])

mikumo/conoha.jpg

今アップロードしたmikumo/conoha.jpgがありますね！

オブジェクトのダウンロード

ローカルにダウンロードもできます。

cli.download_file("conoha", "mikumo/conoha.jpg", "mikumo-conoha.jpg")

Presigned URLの発行

非公開のオブジェクトでも、S3のPresigned URLという、有効期限付きのダウンロードリンクを発行することができます。

以下の例では、mikumo/conoha.jpgに対して、1時間だけ有効なURLを発行します。

url = cli.generate_presigned_url(
"get_object",
Params={"Bucket": "conoha", "Key": "mikumo/conoha.jpg"},
ExpiresIn=3600 # 3600 secs = 1 hour
)
print(url)

例えばブラウザからこのURLにアクセスすると、画像を開くことができます。

ConoHaオブジェクトストレージは一時的Web公開で同様の操作ができます。これは、OpenStack Swiftが提供するSwift TempURLというOpenStack独自の一時的なアクセスURLを発行する仕組みによります。

一方でS3互換APIがありますので、ConoHa公式には記載がありませんがS3相当のPresigned URLも発行できます（上のコードです）。以下の記事にあるようにS3互換のCloudflare R2でもできるそうなので、ConoHaでもできるかな？と思ったらできました。

S3互換のCloudflare R2で署名付きURLを発行する（AWS CLI, Python + Boto3） | DevelopersIO

オブジェクトの削除

オブジェクトストレージは現在使っている容量以下に契約容量を下げることはできませんし、オブジェクトとコンテナを全て削除しないと解約できません（公式マニュアル）。そのため、オブジェクトとコンテナの削除の方法もみておきましょう。

cli.delete_object(Bucket="conoha", Key="mikumo/conoha.jpg")

ばいばいこのはちゃん…

コンテナの削除

最後にコンテナを削除します。なお、コンテナの中身が全て空でなければ削除できません（エラーが返ります）。

cli.delete_bucket(Bucket="conoha")

これで全て削除されたのでオブジェクトストレージを解約しても構いませんが、契約し続けたほうがこのはちゃんが喜びます。

おわりに

S3の経験があれば簡単に触れますし、boto3のドキュメントはいっぱいあるのでS3の経験がなくても触れそうです。

活用例を調べてみると、2015年のアドカレ記事でConoHaのインスタンスのリバースプロキシと合わせた画像アップローダーサイトが面白いなと思いました。

【月額1350円でできる！！】ConoHaのオブジェクトストレージを使ってWEB画像アップローダーサイトを作ってみよう #Ruby - Qiita

転送料金フリーなメリットを活かしてなんか作れたらいいな！

個人的な話ですが、3年前のこのはのアドカレはわたしがはじめて書いたアドカレなので、このはのアドカレには少し思い入れがあります（そのときの記事: GPT-2で作ったConoHa上のこのはちゃんbotとSlackで会話する）。久々に参加できて楽しかったので、来年も何か記事を出せるようにConoHaを触りながら考えてみます！

（本文中で引用した壁紙は©GMO Internet, Inc., 再使用禁止です）

正確には、OpenStackをS3互換APIで使うのに必要なクレデンシャルです。 ↩︎

多変量確率的ボラティリティモデルで相関係数の時変性をとらえる

Tue, 09 Dec 2025 00:00:00 +0900

はじめに

この記事はマケデコ Advent Calendar 2025の9日目の記事です。

資産間のリターンの相関係数を求める方法としては、過去一定期間のリターンからローリング相関を計算するものが広く用いられています。しかし、この方法には、ローリングのウィンドウの期間の長さによって値が変わったり、市場の急変に追随するのが遅かったりするという課題が存在します。

これを解決する方法として、ボラティリティと相関を同時にモデリングする、多変量の確率的ボラティリティモデル（Multivariate Stochastic Volatility (MSV) モデル）を紹介します。

MSVモデルをPythonとStanで実装し、2008年～2025年のTOPIXと東証REIT指数の相関係数を推定してみました。相関係数はおおむね0.4程度ですが、2016年～2020年や2025年は0.2程度まで低下していました。

金融工学の論文実装でアドカレを書いている人があんまりいないのでこういうのもありでしょう。マケデコのアドカレは気付けば3年連続で書いています。よかったら過去記事も読んでみてください。

毎年ボラティリティネタで書いてますね。これはわたしの趣味です。

ちなみにこの記事は、2023年の記事のStochastic Volatilityモデルを単一資産から複数資産に拡張したものですので、この過去の記事も参考になると思います。

相関係数のモデリングの重要性

リターンの相関係数はアセットアロケーションなどに使われるため、個々の資産のボラティリティとならんで重要なのはいうまでもありません。ではどうやって相関係数を求めればよいのでしょうか？

よく知られているのは、各資産の過去n日のリターンどうしの相関係数を求め、1日ずつスライドさせていく、いわゆるローリング相関係数です。

2008/5〜2025/12のTOPIXと東証REIT指数（両方配当なし）のデータを用いて、それぞれの対数リターンの過去n営業日ローリング相関係数をn=250でプロットしてみると以下のようになります。これは過去1年のローリングに相当します。なお、TOPIXと東証REIT指数のデータはJ-Quantsから取りました。

これは広く用いられている方法ですが、問題点があります。

nの値によって相関係数の値が大きく変わる
ウィンドウ期間中は相関係数が一定という前提のもとに成り立つ
極端なリターンがあると相関係数が過度に変化する

特に2点目と3点目ですが、ローリング相関は、ウィンドウ期間中の相関係数が一定であることを暗黙の前提とします。その場合、ウィンドウ期間中の標本相関係数は真の相関の推定値として解釈できます。

しかし、市場は急に変動することがあるためその仮定は現実的ではありません。極端なリターンがあると相関係数が急変動する一方、相関係数の構造変化には追随が遅れてしまいます。極端なリターンの例としては、2011年3月の東日本大震災のときの市場の急変動により、プロットのとおり相関係数が急に上がっていることが挙げられます。日次リターンではなく月次リターンなどより長い期間のリターンから求めることで極端なリターンへの対応ができますが、構造変化への追随はより遅れます。

これらの問題に対する一つの解決策は、それぞれの資産の日次のリターンから、各資産のボラティリティとその相関係数をモデリングすることです。

様々な方法が提案されていますが¹、その一つがMSVモデルです。これは、観測されるリターンから、潜在変数である各資産のボラティリティと資産間の相関係数を同時にモデリングするものです。

複雑な状態空間モデルですが、Stanなどで実装すればボラティリティや相関係数の推定値を得ることができます。またモデルの拡張も容易です。

MSVモデルをアセットアロケーションに適用した研究としては、Aguilar and West (2000) や、それを発展させてスパース性を持たせたZhou, et al. (2014) が有名です。特に前者では、MSVモデルを用いたアセットアロケーションは、1992年のイギリスのERM脱退時のポンド相場のような構造変化時によいパフォーマンスを示すことが報告されています。

モデル

いま、資産1と資産2の$t$日における日次終値をそれぞれ$S_{t,1}, S_{t,2}$とします。

このとき、$t$日におけるリターンを、対数リターンの100倍として、それぞれ$r_{t,1} = 100 (\log(S_{t,1}) - \log(S_{t-1,1})), r_{t,2} = 100 (\log(S_{t,2}) - \log(S_{t-1,2}))$とします。100倍するのは、パーセント表記にするということです。

以下のように定式化したMSVモデルを考えます。

$$ \begin{aligned} y_{t,i} &= \exp(h_{t,i}/2) \epsilon_{t,i}, \quad i = 1, 2 \\ (\epsilon_{t,1}, \epsilon_{t,2})’ &\sim N\left(\begin{pmatrix} 0 \\ 0 \end{pmatrix}, \begin{pmatrix} 1 & \rho_t \\ \rho_t & 1 \end{pmatrix}\right) \\ h_{t+1,i} &= \mu_i + \phi_i (h_{t,i} - \mu_i) + \eta_{t,i}, \quad \eta_{t,i} \sim N(0, \sigma_{\eta,i}^2) \\ g_{t+1} &= g_t + \zeta_t, \quad \zeta_t \sim N(0, \sigma_\zeta^2) \\ \rho_t &= \tanh(g_t) \end{aligned} $$

ただし、$y_{t,i} = r_{t, i}$とします。これは日次リターンが有意に正でも負でもないということです。多くの実証研究ではそれが示されていますが、仮にそうではない場合は、第1式に定数項か、その定数を時変にしてその状態方程式を加えます。

このとき、資産$i (i = 1, 2)$の$t$日におけるボラティリティは$\sigma_{t,i} = \exp(h_{t,i}/2)$、相関係数は$\rho_t$となります。

分散の対数がAR(1)過程に従い、相関係数はランダムウォークする$g_t$を$\tanh({g_{t}})$で相関係数が取るべき-1から1までの間に押し込めたものとして同時にモデリングしています。

なお、MSVモデルにはさまざまなバリエーションが存在します²。多変量の観測系列があり、各系列のボラティリティが確率的で時変する潜在変数であればMSVモデルといえます。例えば相関係数をつくる$g$は上の式ではなく平均回帰性を持つようにAR(1)過程にするなど、細かい差異がいろいろ存在します。大森 (2019) に詳しく書かれています。

実装

上述のモデルをStanで書いて、Pythonからキックすることでパラメータを推定します。この実装のセクションはStanの知識が必要ですので、Stanに慣れていない方はこの章は読み飛ばしても大丈夫ですが、自分でやってみたい場合は参考にしてください。最近はStan以外にもベイズ推定のフレームワークがいろいろあるので好きなものを使ってください。

いま、以下のようにTOPIXと東証REIT指数の終値と対前日対数リターン（100倍したもの）をpolars.DataFrameで持っているとします。

shape: (4_303, 5)
┌────────────┬────────────┬───────────┬───────────┬───────────┐
│ Date ┆ CloseTopix ┆ RetTopix ┆ CloseReit ┆ RetReit │
│ --- ┆ --- ┆ --- ┆ --- ┆ --- │
│ date ┆ f64 ┆ f64 ┆ f64 ┆ f64 │
╞════════════╪════════════╪═══════════╪═══════════╪═══════════╡
│ 2008-05-08 ┆ 1372.95 ┆ -1.469897 ┆ 1585.12 ┆ 0.608743 │
│ 2008-05-09 ┆ 1341.76 ┆ -2.297952 ┆ 1550.03 ┆ -2.238583 │
│ 2008-05-12 ┆ 1342.79 ┆ 0.076735 ┆ 1535.05 ┆ -0.971133 │
│ 2008-05-13 ┆ 1360.05 ┆ 1.277192 ┆ 1547.59 ┆ 0.813593 │
│ 2008-05-14 ┆ 1373.04 ┆ 0.95058 ┆ 1556.18 ┆ 0.553522 │
│ … ┆ … ┆ … ┆ … ┆ … │
│ 2025-12-01 ┆ 3338.33 ┆ -1.194338 ┆ 1995.68 ┆ -1.399209 │
│ 2025-12-02 ┆ 3341.06 ┆ 0.081744 ┆ 1998.79 ┆ 0.155715 │
│ 2025-12-03 ┆ 3334.32 ┆ -0.201936 ┆ 1986.95 ┆ -0.59412 │
│ 2025-12-04 ┆ 3398.21 ┆ 1.898006 ┆ 1973.22 ┆ -0.693407 │
│ 2025-12-05 ┆ 3362.56 ┆ -1.054623 ┆ 1962.18 ┆ -0.561063 │
└────────────┴────────────┴───────────┴───────────┴───────────┘

上のMSVモデルを以下の通り書き下します³。事前分布はKim, Shephard and Chib (1998), 大森 (2019) にならっています。

Stanコード（クリックすると折りたたみが開きます）

// Stanの収束をよくするためのテクニックを以下の通り入れている
// 1. phiのlower, upperを-0.999から0.999に縛っている
// -1 - 1だと両端でサンプリングが不安定になって収束が悪いため
//（sigma系のパラメータのacfやESSが微妙になる）
// 2. h_raw, g_rawの非中心パラメータ化（「再パラメータ化」の一種）
// sigma_etaが小さいとき、hとsigma_etaの事後分布が強く相関するので、h_rawとsigma_etaを分離する
data {
int<lower=0> n; // 時点数
int<lower=1> p; // 次元（p=2 であることを前提としている）
matrix[p, n] y; // リターン（2×n）
}
parameters {
matrix[p, n] h_raw;
vector[n] g_raw;
vector[p] mu;
vector<lower=0.0005, upper=0.9995>[p] phi_raw;
vector<lower=0>[p] sigma_eta_sq;
real<lower=0> sigma_zeta;
}
transformed parameters {
vector<lower=-1, upper=1>[p] phi = 2 * phi_raw - 1;
vector<lower=0>[p] sigma_eta = sqrt(sigma_eta_sq);
matrix[p, n] h;
vector[n] g;
vector<lower=-1, upper=1>[n] rho;
// 非中心パラメータ化
for (i in 1:p) {
h[i, 1] = mu[i] + (sigma_eta[i] / sqrt(1 - phi[i]^2)) * h_raw[i, 1];
}
g[1] = 10 * g_raw[1];
for (t in 2:n) {
for (i in 1:p) {
h[i, t] = mu[i] + phi[i] * (h[i, t-1] - mu[i]) + sigma_eta[i] * h_raw[i, t];
}
g[t] = g[t-1] + sigma_zeta * g_raw[t];
}
for (t in 1:n) {
rho[t] = tanh(g[t]);
}
}
model {
// 論文のとおり事前分布を設定する
// sigma_zetaは論文とはモデルが違うのでflat priorにしている
mu ~ normal(0, 1);
phi_raw ~ beta(20, 1.5);
sigma_eta_sq ~ inv_gamma(2.5, 0.025);
to_vector(h_raw) ~ std_normal();
g_raw ~ std_normal();
// 観測方程式
for (t in 1:n) {
real sigma1 = exp(h[1, t] / 2.0);
real sigma2 = exp(h[2, t] / 2.0);
matrix[p, p] Sigma;
Sigma[1, 1] = sigma1^2;
Sigma[2, 2] = sigma2^2;
Sigma[1, 2] = rho[t] * sigma1 * sigma2;
Sigma[2, 1] = Sigma[1, 2];
y[, t] ~ multi_normal(rep_vector(0.0, p), Sigma);
}
}
generated quantities {
matrix[p, n] volatility;
vector[n] log_lik;
for (t in 1:n) {
real sigma1 = exp(h[1, t] / 2.0);
real sigma2 = exp(h[2, t] / 2.0);
volatility[1, t] = sigma1;
volatility[2, t] = sigma2;
matrix[p, p] Sigma;
Sigma[1, 1] = sigma1^2;
Sigma[2, 2] = sigma2^2;
Sigma[1, 2] = rho[t] * sigma1 * sigma2;
Sigma[2, 1] = Sigma[1, 2];
log_lik[t] = multi_normal_lpdf(y[, t] | rep_vector(0.0, p), Sigma);
}
}

MSVモデルは素朴に実装するとMCMCの収束が悪くなりがちなので、非中心パラメータ化のようなテクニックを使っています（Stanコードのコメントを参照）。

cmdstanpyのCmdStanModelのsampleを用いて、iter_warmup=1000, iter_sampling=1000, thin=1, chain=4で、私の環境では4chain並列して15分くらいで推定できました。なお、使用した環境はPython=3.13.7, CmdStan=2.36, cmdstanpy=1.3.0です。

MCMCサンプリングが収束したこと（パラメータ推定に問題がないこと）を確認しましたが、割愛します⁴。

結果

結果の相関係数です。線の上下の帯は95%ベイズ信用区間です。

おおむね0.4程度を取っていますが、2016-2020年や2025年は0.2程度まで低下していますね。

2023年時点での過去10年の月次相関係数を計算すると、国内株と国内REITは0.4程度とのことです。（参考: 資産配分を再考、最適な投信の組み合わせは？ | 東証マネ部！）

これと整合的な結果が得られましたが、時期によってはそれより小さいことも大きいこともあることが分かり、市場の変化に追随できることを示せました。また、各時点での相関係数の信用区間を示すこともでき、不確実性の程度が分かるのもよい点です。

基本的に国内株も国内REITも金利と逆相関の動きをしますが、株は景気や業績の影響も強く受けるため、2025年のように金利上昇局面でも買われることがありますね。このような場合に相関関係が崩れるのだと思われます。

補足

このプロットは、冒頭のローリング相関のプロットと異なり、滑らかな曲線を描いています。

これは、一つはMSVモデルによる相関係数のモデリングの効果によります。もう一つは、MSVモデルでは$t$の相関係数を全期間のリターンデータを用いて推定していますが、ローリング相関では$t$までのデータ（さらに直近n期間のみ）から求めていることの違いによるものです。

状態空間モデルの文脈で言うと、前者は「平滑化」と呼ばれる推定量に近いものであり、後者は「フィルタ化」と呼ばれる推定量に近いです（ただし、ローリング相関は状態空間モデルではないので、あくまで$t$の相関係数を$t$までのデータから求めているという意味でフィルタ化に近いということです）。

MCMCで求めたパラメータの推定値は平滑化推定量に近いものです。将来の時点のデータを使って過去の時点のパラメータを求めているためバックテストには使えませんが、後から振り返ってデータを解釈する目的では適していますね。

バックテストに使うためには、MCMCで毎日回すか、あるいは粒子フィルタのようなフィルタ系の手法で推定してフィルタ化推定量を求めるという解決策があります。後者ですが、推定にかかる時間もフィルタ系の方が早いので、毎日や毎週のオンライン予測には適しています。

なお、資産価格の系列数が多くなると共分散行列の要素数が多くなるためパラメータの推定が困難になります。その場合は少ない因子に分解して推定するなどの方法を取ります。これも大森 (2019) を参照してください。

おわりに

金融工学の論文は実装すればすぐ収益に結びつくようなものではありませんが、論文の読解と実装を地道に積み重ねていくことで知見が得られると思っています。やはり、巨人の肩の上に立つことには意味があるんだと思います。

参考文献

大森裕浩 (2019). 多変量ボラティリティモデルのベイズ推定. 日本統計学会誌, 48(2), 177-198.
Aguilar, O., & West, M. (2000). Bayesian dynamic factor models and portfolio allocation. Journal of Business and Economic Statistics, 18(3), 338-357.
Kim, S., Shephard, N., & Chib, S. (1998). Stochastic volatility: Likelihood inference and comparison with ARCH models. Review of Economic Studies, 65(3), 361-393.
Zhou, X., Nakajima, J., & West, M. (2014). Bayesian forecasting and portfolio decisions using dynamic dependent sparse factor models. International Journal of Forecasting, 30(4), 963-980.

他に、分足データを用いて相関係数の推定値を求めるRealized Correlationという手法もあります。2024年のアドカレで書いたRealized Volatilityの記事の多変量版の拡張になります。 ↩︎
ここで書いたモデルは、大森 (2019) の「動学的均一相関MSVモデル」を2変量に限定して、$g$をAR(1)ではなくランダムウォークとし、かつ相関係数が正だけではなく負の値も取れるように拡張したものにおおむね相当します。 ↩︎
なお、TOPIXのリターンは平均0.020, 標準偏差1.345, 東証REIT指数のリターンは平均0.005, 標準偏差1.336であり、有意に正でも負でもないため、前掲のモデルの第1式に定数項を入れないことは妥当な定式化と言えます。 ↩︎
内容はこちらを参考にしてください: [R] [stan] bayesplot を使ったモンテカルロ法の実践ガイド - ill-identified diary, [R][Stan]マルコフ連鎖モンテカルロ法の実践ガイド2: ランクプロット他 - ill-identified diary ↩︎

plotnineで非営業日を軸から除いたプロットを描く

Sun, 21 Sep 2025 00:00:00 +0900

Pythonのプロット描画ライブラリであるplotnineにおいて、土日祝日などの任意の非営業日を除外して営業日ベースでプロットを描く方法です。

結論からいうと、日付からint型の連番列を作ってこの連番列をx軸に取り、plotnine.scale_x_continuousのlabels引数に軸ラベルにするstr型の日付の文字列を渡せばよいです¹。

株価のようにデータによっては非営業日を除外して軸を描くケースが頻出なんですよね。よく使うのでメモしておきます。

環境は以下のとおりです。

Python=3.13.7
polars=1.33.1
plotnine=0.15.0
mizani=0.14.2

こういうサンプルデータを考えます。

import polars as pl
import plotnine as p9
from mizani.breaks import breaks_width, breaks_date_width
df = (
# 2025/1/11-12は土日、1/13は祝日、1/18-19は土日
pl.DataFrame({
"date": [
"2025-01-06", "2025-01-07", "2025-01-08", "2025-01-09", "2025-01-10",
"2025-01-14", "2025-01-15", "2025-01-16", "2025-01-17",
"2025-01-20", "2025-01-21", "2025-01-22", "2025-01-23", "2025-01-24"
],
"a": [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14],
"b": [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15],
})
.with_columns(
date=pl.col("date").str.strptime(pl.Date, "%Y-%m-%d"),
)
)
df = (
df
.unpivot(
on=["a", "b"],
index="date",
variable_name="stock_name",
value_name="price"
)
.sort("date", "stock_name")
)
print(df)

shape: (28, 3)
┌────────────┬────────────┬───────┐
│ date ┆ stock_name ┆ price │
│ --- ┆ --- ┆ --- │
│ date ┆ str ┆ i64 │
╞════════════╪════════════╪═══════╡
│ 2025-01-06 ┆ a ┆ 1 │
│ 2025-01-06 ┆ b ┆ 2 │
│ 2025-01-07 ┆ a ┆ 2 │
│ 2025-01-07 ┆ b ┆ 3 │
│ 2025-01-08 ┆ a ┆ 3 │
│ … ┆ … ┆ … │
│ 2025-01-22 ┆ b ┆ 13 │
│ 2025-01-23 ┆ a ┆ 13 │
│ 2025-01-23 ┆ b ┆ 14 │
│ 2025-01-24 ┆ a ┆ 14 │
│ 2025-01-24 ┆ b ┆ 15 │
└────────────┴────────────┴───────┘

aとbという株の株価が記録されたpolars.DataFrameだとイメージしてください。

aesのxにdateを指定してふつうに折れ線グラフを描くと、レコードがない日、すなわち株式市場が空いていない日が直線で繋がってしまいます²。そうではなく、例えば2025/1/10の一つ隣は2025/1/14が来るようにプロットしたいです。

(
p9.ggplot(
df,
p9.aes(x="date", y="price", color="stock_name")
) +
p9.geom_line() +
p9.geom_point() +
p9.scale_x_date(breaks=breaks_date_width("1 day"), minor_breaks=None) +
p9.scale_y_continuous(breaks=breaks_width(1), minor_breaks=None) +
p9.theme(axis_text_x=p9.element_text(rotation=90))
)

これを解決するには、まずx軸に取りたい日付のdateをintの連番にしたindex列を用意します。

df = (
df
# 縦持ちのデータでは同一日が複数行あるので、rankのmethodはdenseを使う
.with_columns(
date_idx=pl.col("date").rank("dense") - 1
)
)

date_idxで1を引いているのは、date_idxを0始まりにするためです。あとで5日おきに軸ラベルを振るコードを示しますが、そのとき5で割り切れるdate_idxに軸ラベルを振るというコードで最初の日付にもラベルを振ることができ、コードが分かりやすくなります³。

そしてindex列をx軸に取り、scale_x_continuousのbreaksとminor_breaks引数にそれぞれ軸ラベルと目盛りを振りたい連番を指定してあげます。

また、軸ラベルにする日付の文字列として、breaksの引数と同じ長さのlist[str]をlabelsに与えます。

date_labels = sorted(df["date"].unique().dt.strftime("%Y-%m-%d").to_list())
date_idx = sorted(df["date_idx"].unique().to_list())
# 軸ラベルは全部の日付に振り、軸ラベルの間のminor_breaksは振らないとする
major_breaks_idx = date_idx
minor_breaks_idx = None
major_labels = [date_labels[i] for i in major_breaks_idx]
(
p9.ggplot(
df,
p9.aes(x="date_idx", y="price", color="stock_name")
) +
p9.geom_line() +
p9.geom_point() +
p9.scale_x_continuous(breaks=major_breaks_idx, minor_breaks=minor_breaks_idx, labels=major_labels) +
p9.scale_y_continuous(breaks=breaks_width(1), minor_breaks=None) +
p9.theme(axis_text_x=p9.element_text(rotation=90)) +
p9.labs(x="date")
)

うまく描けていますね。

実際は軸ラベルを整えたいことも多いですが、5日おきに軸ラベルを振るということもできます。

major_breaks_idx = [i for i in date_idx if i % 5 == 0]
minor_breaks_idx = date_idx
major_labels = [date_labels[i] for i in major_breaks_idx]
(
p9.ggplot(
df,
p9.aes(x="date_idx", y="price", color="stock_name")
) +
p9.geom_line() +
p9.geom_point() +
p9.scale_x_continuous(breaks=major_breaks_idx, minor_breaks=minor_breaks_idx, labels=major_labels) +
p9.scale_y_continuous(breaks=breaks_width(1), minor_breaks=None) +
p9.theme(axis_text_x=p9.element_text(rotation=90)) +
p9.labs(x="date")
)

例えば月曜日を週始まりとして、週の最初の日付だけに軸ラベルを振りたいというケースもよくあります。

この場合も、scale_x_continuousのbreaks引数に、軸ラベルを振りたいdateの連番を渡せばよいです。polarsで各週の最初の曜日の日付のindexを集計して、それをscale_x_continuousのbreaks引数に渡せばよいですね。

idx_first_business_day_of_week = (
df
.with_columns(
year=pl.col("date").dt.year(),
week=pl.col("date").dt.week()
)
.group_by("year", "week")
.agg(
first_business_day_of_week_idx=pl.col("date_idx").min()
)
.sort("year", "week")
.get_column("first_business_day_of_week_idx")
.to_list()
)
major_breaks_idx = idx_first_business_day_of_week
minor_breaks_idx = date_idx
major_labels = [date_labels[i] for i in major_breaks_idx]
(
p9.ggplot(
df,
p9.aes(x="date_idx", y="price", color="stock_name")
) +
p9.geom_line() +
p9.geom_point() +
p9.scale_x_continuous(breaks=major_breaks_idx, minor_breaks=minor_breaks_idx, labels=major_labels) +
p9.scale_y_continuous(breaks=breaks_width(1), minor_breaks=None) +
p9.theme(axis_text_x=p9.element_text(rotation=90)) +
p9.labs(x="date")
)

注意点として、年をまたぐ同一の週番号を正しく別に扱えるようにyearでもgroup_byして集計しています。

ISO weekの週は月曜日始まりなので、weekでgroup_byしてdate_idxのminを取ると、月曜日始まりの週の最初の日付を取得できます。月曜日以外の日を週始まりとしたい場合は別の書き方が必要ですが、そうしたいケースに出会ったことはないのでたいていこれで十分だと思います。

同様に月の最初の日だけ軸ラベルを振るようなこともできます。上のコードとほとんど同じコードなので省略しますが、この場合はweekをmonthに読み替えればOKです。

ちなみにRのggplot2を使う場合は、bdscaleという便利なパッケージがあり、bdscale::scale_x_bdで一発で描けます。 ↩︎
dfは株式市場が空いていない日はレコードがありませんが、例えば空いていない日をdate列に入れてa列とb列をNoneとしたとしても、直線が途中で切れるだけで所望のプロットは描けません。 ↩︎
1始まりでも「5で割って1余るdate_idxに軸ラベルを振る」とできますが、ちょっと分かりにくい気がします。 ↩︎

機械学習によるレコメンドエンジンで自分に小説をおすすめした

Tue, 15 Jul 2025 00:00:00 +0900

はじめに

この一年ほど、小説をよく読んでいます。それまでは一年に一冊も小説を読まなかったのですが、一度読んでみるとだんだん自分の好みが分かってきて楽しくなりました。

すると、自分の好みに合う小説や、以前読んで気に入った小説に似た小説が読みたくなります。Amazonの「この商品をチェックした人はこんな商品もチェックしています」のレコメンドを参考に新しい本を知ることが多いです。

しかし、Amazonが作ったブラックボックスのアルゴリズムに自分の興味を操作されるのはなんか嫌ですね。そこで機械学習によるレコメンドエンジンを作って自分に本をおすすめすることにしました。

スクレイピング

レコメンドエンジンを作るためのレビューデータとして、読書メーターをスクレイピングしました。

読書メーターではユーザが読んだ本を登録することができます。この、それぞれのユーザがどの本を何回「読んだ本」リストに登録したかというデータを用います。「AさんはX, Y, Zの3冊を読んだ」というようなデータです。本の作家の名前やあらすじなど、それ以外の情報は用いていません。

ユーザIDがuser_idのユーザの読んだ本は、https://bookmeter.com/users/{user_id}/books/readで見ることができます。user_idは1から始まる自然数であり、約150万まで存在しました。この中から20%分のIDをサンプリングして、十分に間隔を空けながらforループで上のページをスクレイピングしました。

その結果、IDが存在しないユーザ（おそらく退会したユーザ）や、1冊も読んでいないユーザを除外して、168,262人のユーザによる1,679,143冊の本に対する22,188,378件のレビューを得ることができました。

さて、今回取得した168,262人のユーザに最も読まれた本は何でしょうか？

title	author	count	user_count
“阪急電車 (幻冬舎文庫)”	“有川浩”	12368	11712
“夜は短し歩けよ乙女 (角川文庫も 19-2)”	“森見登美彦”	10862	10318
“西の魔女が死んだ (新潮文庫)”	“梨木香歩”	10587	10090

「阪急電車」でした。11,712人のユーザに合計12,368回読まれた本でした。ユーザ数より読まれた回数が多いのは、読書メーターでは同一の本を複数回読んだと登録できるためです。

Implicit Matrix Factorizationのアルゴリズム

今回のレコメンドエンジンで使うImplicit Matrix Factorizationについて説明します。この分野は全くの素人なので誤りがあるかもしれません。

この節の説明は推薦システム実践入門を参考にしました。体系的にレコメンドエンジンを学ぶことができ、理論と実装の説明のバランスが取れているかなりの良書でした。

明示的評価値と暗黙的評価値

いま、ユーザ$u (1, \dots, n)$のアイテム$i (1, \dots, m)$に対する評価値を$r_{u,i}$とします。$r_{u,i}$を行方向にユーザ、列方向にアイテムを取って並べた$n \times m$の行列を評価値行列と呼びます。以下、$R$と表記します。

この評価値には、明示的評価値と暗黙的評価値の二種類があります。

明示的評価値とは、ユーザが直接アイテムに得点を付けたような評価値を指します。Amazonのレビューの点数のようなものですね。一方、暗黙的評価値とは、ユーザがアイテムに対して起こした行動に関するデータです。例えばECサイトでのアイテムの閲覧回数です。今回用いる読書メーターの評価値は、ユーザがそれぞれの本を読んだと登録した回数であり、暗黙的評価値にあたります。

明示的評価値はユーザの好みを正確に示したデータですが、暗黙的評価値はユーザの好みをそのまま反映しているとは限りません。そのため、各種のレコメンド手法は、明示的評価値に適用できるものと暗黙的評価値に適用できるものに分かれます。

行列分解によるレコメンドエンジン

評価値行列$R$を、ユーザの特徴を表すユーザ行列とアイテムの特徴を表すアイテム行列という二つの行列に分解することを考えます。具体的には、$R$を$R = PQ^{T}$で表される行列$P (n \times k)$, $Q (m \times k)$に分解します。

$P$をユーザ行列、$Q$をアイテム行列と呼びます。$k$は潜在因子数というハイパーパラメータです。この操作は、ユーザ$u$とアイテム$i$をそれぞれ$k$次元のベクトルで表現するということです。$k$は大きい値にするほど表現力が高くなりますが、過学習しやすくなります。

以上より、ユーザ$u$のアイテム$i$に対する評価値$r_{u,i}$の予測値はベクトルの内積$P_{u} Q_{i}^{T}$で求められます。評価値の予測値が高いものをユーザにレコメンドします。

Implicit Matrix Factorization

Implicit Matrix Factorizationは、暗黙的評価値に対して適用できる、行列分解による協調フィルタリングベースのレコメンド手法の一つです。

概要を簡単に説明します。以下、$r_{u,i}$を暗黙的評価値とします。

$\bar{r}_{u,i}$を$\bar{r}_{u,i} = 1 (r_{u,i} > 0), 0 (r_{u,i} = 0)$で定義します。$r_{u,i}$が0より大きい正の値であれば、ユーザ$u$はアイテム$i$に対して好意を持っていることを示します。$\bar{r}_{u,i}$は、好意を持っているかどうかを示す0/1の変数です。

$c_{u,i} = 1 + \alpha r_{u,i}$で定義される$c_{u,i}$を信頼度と呼びます。

$r_{u,i} = 0$の場合、ユーザ$u$はアイテム$i$に対して好意を持っていないとは限りません。そのアイテムを知らなかっただけの可能性もあるからです。そのため、$r_{u,i} = 0$の場合でも$c_{u,i} = 1$を割り当てます。

$r_{u,i}$が大きければ大きいほどユーザ$u$はアイテム$i$に対して大きな好意を持っていると考えられますが、暗黙的評価値である$r_{u,i}$をそのまま好意の度合いとして使用することは適切ではありません。$r_{u,i}$がどの程度好意を表すかというパラメータ$\alpha$を導入して、好意の信頼度$c_{u,i}$を定義します。

Implicit Matrix Factorizationで求められるユーザ行列$P$とアイテム行列$Q$は、以下を満たす行列です。

$$ min_{p,q} \sum_{u} \sum_{i} c_{u,i} (\bar{r}_{u,i} - p_{u}^{T} q_{i})^{2} + \lambda (\sum_{u} ||p_{u}||^{2} + \sum_{i} ||q_{i}||^{2}) $$

右辺第2項は過学習防止のためのL2正則化であり、$||p_{u}||^{2} = p_{u,1}^{2} + p_{u,2}^{2} + \dots$（L2ノルム）です。

この関数を普通に最小化しようとするとユーザ数 x アイテム数を計算することになり計算コストが大きいですが、implicit alternating least squares（iALS）というアルゴリズムを用いるとこの目的関数を効率的に最小化することができます。2008年の論文のモデルですが、Revisiting the Performance of iALS on Item Recommendation Benchmarksによると、ハイパーパラメータを調整することで2022年時点では深層学習系のモデルと引けを取らない精度が出るそうです。

アルゴリズムについては参考文献に載せたとおり素晴らしく分かりやすく解説されたサイトがありますので、詳細はそちらをご覧ください。

実装

評価値行列の作成

環境はPython 3.12.0, polars 1.31.0, implicit 0.7.2です。

import implicit
import numpy as np
import polars as pl
from scipy import sparse
from threadpoolctl import threadpool_limits
from tqdm import tqdm

次のデータを持っています。ユーザuser_idが本book_idをcount回読んだというデータであり、user_idとbook_idの組み合わせ数だけレコードがあります。ただし表示しているuser_idは匿名化したものであり、読書メーターの実際のuser_idからは変更しています。なお、読まれた人数が少ない本や、読んだ本の数が少ないユーザによるレビューを除外しています。

shape: (14_841_848, 3)
┌─────────┬──────────┬───────┐
│ user_id ┆ book_id ┆ count │
╞═════════╪══════════╪═══════╡
│ 1 ┆ 2845 ┆ 1 │
│ 1 ┆ 104674 ┆ 1 │
│ 1 ┆ 105027 ┆ 1 │
│ 1 ┆ 105086 ┆ 1 │
│ 1 ┆ 105096 ┆ 1 │
│ … ┆ … ┆ … │
│ 134877 ┆ 20586079 ┆ 1 │
│ 134877 ┆ 20716260 ┆ 1 │
│ 134877 ┆ 21248535 ┆ 1 │
│ 134877 ┆ 21658085 ┆ 1 │
│ 134877 ┆ 21700595 ┆ 1 │
└─────────┴──────────┴───────┘

このDataFrameから評価値行列を作成します。

user_ids = np.array(sorted(set(df.get_column("user_id"))))
book_ids = np.array(sorted(set(df.get_column("book_id"))))
user_id2index = dict(zip(user_ids, range(len(user_ids))))
book_id2index = dict(zip(book_ids, range(len(book_ids))))
index2user_id = dict(zip(range(len(user_ids)), user_ids))
index2book_id = dict(zip(range(len(book_ids)), book_ids))
# implicit.als.AlternatingLeastSquares.fitに通せるのはcsr_matrixだが、
# 行方向の代入はlil_matrixのほうが早いので、lil_matrixで代入してからcsr_matrixに変換する
feature_matrix = sparse.lil_matrix(
np.zeros((len(user_ids), len(book_ids)), dtype=np.int8)
)
# Implicit Matrix Factorizationのalpha
alpha = 1.0
for u, b, c in tqdm(zip(
df.get_column("user_id").to_numpy(),
df.get_column("book_id").to_numpy(),
df.get_column("count").to_numpy()
)):
feature_matrix[
user_id2index[u], book_id2index[b]
] = 1.0 * alpha
feature_matrix = feature_matrix.tocsr()

同一のユーザが同一の本を2回以上読んでいることがありますが、評価値行列では1回しか読んでいないという扱いにしました。$r_{u,i} \geq 2$の場合は$r_{u,i} = 1$として扱ったということです。読書メーターの「読んだ本」の登録は何回でもできるのですが、たいていのユーザは1回だけ登録している一方、一部のユーザは何回も登録しているようなことがあるため、2回以上読んだ場合でも1回とみなす方が適当に思われたためです。

134,877人のユーザ x 119,737冊の本の合計14,841,848件のレビューを評価値行列とします。

feature_matrix

<Compressed Sparse Row sparse matrix of dtype 'int8'
with 14841848 stored elements and shape (134877, 119737)>

モデルの学習

Pythonではimplicit.als.AlternatingLeastSquaresで実装されているのでこれを使います。

なお、潜在因子数$k$は$k = 512$としました。いろいろ試してみて、なんとなく妥当な結果だと思えたのが512だからです。評価指標を用いてちゃんと決めたほうがいいです。

また、その他のハイパーパラメータはデフォルト値のままですが、先の論文によるとハイパーパラメータチューニングによって大きく性能が変わるようなのでこれもちゃんとチューニングしたほうがいいです。論文によれば、iALSはまずは$k$をできるだけ大きく取り、次に正則化パラメータ$\lambda$を調整することでよい精度が出るそうです。（ハイパーパラメータのチューニングは別の記事にするかもしれません）。

i9-9900K（16スレッド）でスレッド並列で実行すると2分くらいで計算が終わります。データセットの規模の割に高速ですね。

# これを実行するとマルチスレッド環境でimplicit.als.AlternatingLeastSquaresの計算速度が落ちない
threadpool_limits(1, "blas")
model = implicit.als.AlternatingLeastSquares(
factors=512,
regularization=0.01, # デフォルト値
iterations=10,
calculate_training_loss=True,
random_state=1,
)
# 元のfeature_matrixでモデルを再学習（新しいユーザ推薦用）
model.fit(feature_matrix)

レコメンド

実際にレコメンドを出してみます。

インプットにしたい本を評価値行列にして、partial_fit_usersというメソッドで学習済みモデルから埋め込みベクトルを作り、recommendでレコメンドを出せます。このときすべてのデータセットで再学習する必要はなく、1秒もしないうちに結果が出るので一度学習済みモデルを作ってしまえばとても使い勝手が良いです。

わたしは綿矢りささんが好きです。女性の割り切れない感情を繊細で美しい文章で表現するところが好きです。というわけでまずは綿矢さんの「かわいそうだね？」に対するレコメンドを出してみます。

# 新しいユーザの評価値行列を付ける（今レコメンドを出したいユーザ）
new_book_ids = [4255880]
new_feature_matrix = sparse.lil_matrix(
np.zeros((1, len(book_ids)), dtype=np.int8)
)
for nbi in new_book_ids:
new_feature_matrix[0, book_id2index[nbi]] = 1.0 * alpha
new_feature_matrix = new_feature_matrix.tocsr()
# 新しいユーザのインデックス
new_user_index = feature_matrix.shape[0]
# 新しいユーザをモデルに追加学習させる
model.partial_fit_users([new_user_index], new_feature_matrix)
# 新しいユーザに対するレコメンド
ids, scores = model.recommend(
userid=new_user_index,
user_items=new_feature_matrix,
N=100,
filter_already_liked_items=True
)
res = (
pl.DataFrame({"book_id": [index2book_id[i] for i in ids], "score": scores})
.with_columns(book_id=pl.col("book_id").cast(pl.Int32))
)
# 別に持っていたbook_idと著者名のマスタテーブルから著者名を付ける
res = (
res
.join(books, on="book_id", how="left")
.with_columns(score=pl.col("score").round(4))
.select("title", "author", "score")
)
res.head(10)

title	author	score
“何者”	“朝井リョウ”	0.0207
“勝手にふるえてろ”	“綿矢りさ”	0.0167
“蹴りたい背中 (河出文庫わ 1-2)”	“綿矢りさ”	0.0161
“推し、燃ゆ”	“宇佐見りん”	0.0139
“ひらいて”	“綿矢りさ”	0.0137
“勝手にふるえてろ (文春文庫わ 17-1)”	“綿矢りさ”	0.0132
“蹴りたい背中”	“綿矢りさ”	0.0125
“ふがいない僕は空を見た”	“窪美澄”	0.0118
“しょうがの味は熱い”	“綿矢りさ”	0.0109
“すべて真夜中の恋人たち”	“川上未映子”	0.0109

似ている度合いのスコアが高い順に並べました。特徴量に作家名は使っていないにもかかわらず、インプットと同じ綿矢りさ作品が多く並んでいるのが驚きです。本を読む人は、読んだ本の別の作家の本を読んだり作家を追っていたりすることが多いので、協調フィルタリングがこのような結果を返すのは納得です。

なお、同一タイトルの本が複数回登場していますが、単行本と文庫本の違いです。読書メーターでは単行本と文庫本はそれぞれ別の本として存在するためです。レコメンド上はどちらか一つに揃えてもよいのですが、元のデータが分かれているので仕方ないものとしてそのままにしています。

一方で、別の本として扱うことにメリットもあります。ふつう、最初に単行本で発売され、ある程度売れると文庫本が出ます。そのため、単行本で読んだ人はその作者を追っている熱心なファンである可能性が高く、単行本で読んだか文庫本で読んだかは異なる情報を持っています。特徴量設計の難しいポイントですね。

複数冊をインプットにしてレコメンドすることもできます。大人のやさしい恋愛小説やささやかな日常をテーマにした短編が好きなので、以下の2冊でレコメンドしてみます。

畑野智美「大人になったら、」
加藤千恵「消えていく日に」

title	author	score
“マカン・マラン - 二十三時の夜食カフェ”	“古内一絵”	0.0053
“わたしたちは銀のフォークと薬を手にして”	“島本理生”	0.0051
“女王さまの夜食カフェ - マカン・マランふたたび”	“古内一絵”	0.0049
“神さまを待っている”	“畑野智美”	0.0048
“大人は泣かないと思っていた”	“寺地はるな”	0.0046
“あなたの愛人の名前は”	“島本理生”	0.0045
“婚活中毒”	“秋吉理香子”	0.0044
“きまぐれな夜食カフェ - マカン・マランみたび (単行本)”	“古内一絵”	0.0043
“BUTTER”	“柚木麻子”	0.0043
“デートクレンジング”	“柚木麻子”	0.0043

この辺りの本をよく読む方なら納得ではないでしょうか。

「わたしたちは銀のフォークと薬を手にして」と「大人は泣かないと思っていた」はわたしのAmazonのほしいものリストに入っていました。自分で作ったレコメンドエンジンに好みを当てられていますね。

「デートクレンジング」が気になったので実際に買って読んでみました。文庫本では「踊る彼女のシルエット」に改題されています。女性はある程度の年齢になると結婚や出産の有無で規定されがちという息苦しさをテーマにした小説です。ストーリーの展開は好みが分かれそうですが、柚木さんらしい視線のするどさもあってお気に入りの一冊になりました。これは「大人になったら、」と近いテーマでして、レコメンドエンジンの真骨頂を感じました。

レコメンドエンジンのすごさを感じたのはこちらの二冊です。

青山美智子「木曜日にはココアを」
長月天音「キッチン常夜灯」

後述のとおり課題点なのですが、実行するとこの二人の本ばかり上位に出てしまうので、結果のうち二人の本以外のものに絞って載せます。

title	author	score
“三千円の使いかた (中公文庫は 74-1)”	“原田ひ香”	0.0355
“傲慢と善良 (朝日文庫)”	“辻村深月”	0.0344
“満月珈琲店の星詠み (文春文庫も 29-21)”	“望月麻衣”	0.0338
“和菓子のアン (光文社文庫さ 24-3)”	“坂木司”	0.0296
“マカン・マラン - 二十三時の夜食カフェ”	“古内一絵”	0.0295
“52ヘルツのクジラたち (単行本)”	“町田そのこ”	0.0274
“タルト・タタンの夢 (創元推理文庫)”	“近藤史恵”	0.0268
“コンビニ人間 (文春文庫む 16-1)”	“村田沙耶香”	0.0255
“夜空に泳ぐチョコレートグラミー (新潮文庫)”	“町田そのこ”	0.0253
“そして、バトンは渡された (文春文庫せ 8-3)”	“瀬尾まいこ”	0.0246

「木曜日にはココアを」はカフェ、「キッチン常夜灯」はビストロを舞台に、そこに集う人たちの悩みを癒やしていく物語です。

「満月珈琲店の星詠み」、「和菓子のアン」、「マカン・マラン - 二十三時の夜食カフェ」、「タルト・タタンの夢」と、飲食店が舞台で似たテーマの小説が出てくるのは素晴らしいですね。特徴量は各ユーザがそれぞれの本を読んだか読んでいないかというデータであり、あらすじの情報は用いていないにもかかわらず、好みに合いそうな小説を上手に選ぶことができています。

おわりに

想像していたよりもいい感じにレコメンドできたので、StreamlitでWebアプリにして早速使いつつ（このアプリは個人利用目的であり非公開です）、レコメンドされた作品をいくつか買って読んでいます。

今のモデルでは、インプットに入れた本の作家の別の本ばかりがレコメンドされたりする課題があり、改善したいところです。同じ作家の本を読む人が多いから協調フィルタリングがそのような結果を返すのは当然なのですが、「推薦システム実践入門」にも書いてあるように、レコメンド結果の面白さは「意外性」が大切です。

iALSは学習が高速ながら精度が出る優れたモデルなので、先に挙げた論文を読んで勉強してハイパーパラメータチューニングにも取り組みたいです。

参考文献

t分布を用いたロバストな家賃相場の階層ベイズモデリング

Sun, 16 Mar 2025 00:00:00 +0900

はじめに

賃貸マンションの家賃相場は、おおむね、最寄り駅、面積、築年数、階数と、駅からの徒歩分数で決まります。これらの要因から家賃相場を推定する階層ベイズモデルを構築しました。なぜこんなことをしているのかというと、部屋探しの過程で家賃が決まるメカニズムに興味を持ったことがきっかけです。

家賃データには誤入力や並外れた高額物件などによる外れ値が含まれます。誤差項に正規分布を仮定した通常のモデルでは、これらの外れ値に推定結果が引きずられてしまいます。そのためこの記事では、誤差項にt分布を用いることで、この問題に対処したロバストなモデルを作りました。

2024年12月にSUUMOに掲載されていた東京23区の賃貸マンションの家賃データ（62万件）を用いて家賃相場を推定したところ、次の内容が分かりました。

t分布の自由度は7.5程度
- 正規分布ではなく裾の重さを考慮することが妥当
家賃に与える影響
- 築年数1年あたり1.2%下がる
- 徒歩1分あたり0.8%下がる
- 階数が1階上がると0.9%上がる
- 1階と地下1階は2階からみてそれぞれ4.6%、6.4%下がる
- 最上階でも家賃相場は変わらない
t分布モデルでは、急行停車駅が各駅停車駅よりも家賃が高い現象や、都心に近い駅ほど家賃が高い現象をとらえることができた
t分布モデルは正規分布モデルよりもWAICでの汎化性能が高かった

データ

SUUMOから2024年12月にPythonでスクレイピングした、東京23区の賃貸マンションの家賃相場データ（約62万件）を用います。

ただし、対象はマンションのみ、間取りは1K, 1DK, 1LDK, 2K, 2DK, 2LDK, 家賃+管理費が100万円以下、面積は20m2～100m2、築40年以内、最寄り駅徒歩20分以内、地上15階以下です¹。

このようなデータフレームです。

外れ値の存在

x軸に面積の対数、y軸に家賃+管理費（以下家賃と呼びます）の対数をとり、築年数で色分けしてプロットしてみました。

面積の対数と家賃の対数はほぼ線形に並んでいるため、面積の対数と家賃の対数を線形回帰することは妥当だと思われますが、一部外れ値のような点があります。例えばexp(3.25)=25m2, exp(4.5)=90万円は明らかな誤入力ですね（家賃を1桁多く入力しているようでした）。

線形のライン状に密集しているエリアの少しだけ上と下にも点があります。これらは他の物件とは並外れた特徴がある物件かもしれません。このような物件が一定数あるということは、裾が正規分布より厚い分布に従っているということです。

線形回帰の誤差項を正規分布より裾が厚いt分布やコーシー分布とすることで、どちらのケースにも対応して外れ値に引っ張られないロバストな回帰を行うことができます。こちらの記事が分かりやすいです。

尤度関数におけるガウス分布とスチューデントのt分布の比較 - suzuzusu日記

散布図を見る限りはそこまで裾が重そうな分布ではないのでコーシー分布とするとやりすぎかと思ったのと、自由度が1のt分布はコーシー分布でありt分布はコーシー分布を包含するため、この記事ではt分布を適用してみます。

モデル

家賃相場は最寄り駅、面積、築年数、最寄り駅からの徒歩分数、階数で決まるとします。これはEDAから妥当な仮定であることが分かっているのと、部屋の方角などの他の特徴量を取得することはスクレイピングの時間的制約から難しいため、これらの特徴量だけを用います。ちなみに、このように家賃などの不動産価格を面積などの属性の関数として表すアプローチをヘドニック法といいます（ヘドニック法については清水・唐渡 (2007) が分かりやすかったです）。

最寄り駅によって家賃の水準と面積に対する家賃の弾力性が異なることを階層ベイズで表現します。これにより、物件数が少ない駅でも、東京23区の全体の平均の傾向を借用できる（「縮約」という）ことからパラメータの推定が安定します。

築年数と徒歩分数、階数の影響は共通とします。駅近の方が築古でも家賃が下がりにくいと一般に言われますが、最も効くのは最寄り駅別の家賃水準の違いなので、こちらの影響は共通とします。もちろん高度化の余地はあります。

散布図で見たとおり、家賃と面積は両対数線形の関係とします。また、築年数、徒歩分数、階数の効果は家賃に対して乗算で効くというドメイン的に自然な仮定を置きます（例えば、築1年増えるごとに1%下がるようなイメージです）。これによって、対数を取ると線形モデルとなり、扱いやすくなります。線形モデルの誤差項はt分布とすることで裾の厚さを表現します。

これらをモデルにすると、以下のとおりとなります。

物件$i(1, \dots, N)$の最寄り駅を$sta[i] (1, \dots, S)$とします。

$$ \begin{align*} \log{y_{i}} & \sim student\_t(\nu, \mu_{i}, \sigma) \\\ \mu_{i} &= a_{sta[i]} + b_{sta[i]} \log{\mathrm{area}_{i}} \\\ &+ \beta_{\mathrm{age}} \mathrm{age}_{i} \\\ &+ \beta_{\mathrm{walk}}(\mathrm{walk}_{i} - 1) \\\ &+ \beta_{\mathrm{floor}} \max {(\mathrm{floor}_{i} - 2, 0)} \\\ &+ \beta_{\mathrm{isTop}} \mathrm{isTop}_{i} \\\ &+ \beta_{\mathrm{isGround}} \mathrm{isGround}_{i} \\\ &+ \beta_{\mathrm{isUnderground}} \mathrm{isUnderground}_{i} \\\ a_{sta[i]} & \sim N(a_{all}, \sigma_{a_{all}}) \\\ b_{sta[i]} & \sim N(b_{all}, \sigma_{b_{all}}) \\\ \end{align*} $$

このとき、物件の対数家賃の相場は$\mu_{i}$万円であると考えます。ただし、式中の変数は以下のとおりです。

$y_{i}$: 家賃+管理費（万円）
$\mathrm{area}_{i} (20 \leq \mathrm{area}_{i} \leq 100)$: 面積（m2）
$\mathrm{age}_{i} (= 0, 1, \dots, 40)$: 築年数（新築は0年とする）
$\mathrm{walk}_{i} (= 1, 2, \dots, 20)$: 最寄り駅からの徒歩分数
$\mathrm{floor}_{i} (= -1, 1, 2, \dots, 15)$: 物件の階数
$\mathrm{isTop}_{i} (= 0, 1)$: 最上階なら1, そうではないなら0
$\mathrm{isGround}_{i} (= 0, 1)$: 1階なら1, そうではないなら0
$\mathrm{isUnderground}_{i} (= 0, 1)$: 地下1階なら1, そうではないなら0

式中の$\nu$はt分布の自由度です。StanとRでベイズ統計モデリングによれば、そこまで裾が重くない分布の場合は自由度6～8を設定するとよいそうです。なので自由度を6～8くらいの定数と決め打ちしてもいいと思いますが、自由度もパラメータとして推定することにします。

なお、モデル比較用に別途、t分布のところを正規分布としたモデルも推定しました。

実装

先のモデルを以下のStanコードで実装しました。

data {
int N; // 物件の数
vector[N] Y; // 家賃+管理費
vector[N] AREA; // 面積
int S; // 最寄り駅の数
array[N] int<lower=1, upper=S> STATION; // 最寄り駅index
vector[N] AGE; // 築年数（0 - 40）
vector[N] WALK; // 徒歩分数（1 - 20）
vector[N] FLOOR; // 階数（-1, 1 - 15）
vector[N] IS_TOP; // 最上階かどうか（0/1）
vector[N] IS_GROUND; // 1階かどうか（0/1）
vector[N] IS_UNDERGROUND; // 地下1階かどうか（0/1）
}
transformed data {
vector[N] FLOOR2;
for (i in 1:N) {
if (FLOOR[i] <= 1) {
FLOOR2[i] = 2;
} else {
FLOOR2[i] = FLOOR[i];
}
}
}
parameters {
real a_all;
real b_all;
vector[S] a;
vector[S] b;
real<upper=0> age;
real<upper=0> walk;
real<lower=0> floor_num;
real<lower=0> is_top;
real<upper=0> is_ground;
real<upper=0> is_underground;
real<lower=0> sigma_a;
real<lower=0> sigma_b;
real<lower=0> sigma;
real<lower=1> nu;
}
model {
a ~ normal(a_all, sigma_a);
b ~ normal(b_all, sigma_b);
log(Y) ~ student_t(
nu,
a[STATION] + b[STATION] .* log(AREA) +
age*AGE +
walk*(WALK - 1)+
floor_num*(FLOOR2 - 2) +
is_top*IS_TOP +
is_ground*IS_GROUND +
is_underground*IS_UNDERGROUND,
sigma
);
}

cmdstanrのcmdstan_modelのsampleを用いて、chains=4, iter_warmup=1000, iter_sampling=1000, thin=1でサンプリングしました。4chain並列で4日かかりました。環境はR=4.4.2, CmdStan=2.35.0, cmdstanr=0.8.1です。

結果

パラメータ

fit$print(
c("age", "walk", "floor_num", "is_top", "is_ground", "is_underground", "sigma", "nu"),
max_rows=12, digits=3
)
#> variable mean median sd mad q5 q95 rhat ess_bulk ess_tail
#> age -0.012 -0.012 0.000 0.000 -0.012 -0.012 1.001 3951 2624
#> walk -0.008 -0.008 0.000 0.000 -0.008 -0.008 1.001 7615 3078
#> floor_num 0.009 0.009 0.000 0.000 0.009 0.009 1.000 6234 2861
#> is_top 0.000 0.000 0.000 0.000 0.000 0.000 1.001 3665 2064
#> is_ground -0.049 -0.049 0.000 0.000 -0.049 -0.048 1.000 7561 2916
#> is_underground -0.066 -0.066 0.002 0.002 -0.070 -0.062 1.002 7136 2928
#> sigma 0.093 0.093 0.000 0.000 0.093 0.094 1.000 6458 3222
#> nu 7.562 7.561 0.076 0.074 7.440 7.689 1.000 7036 3119

自由度$\nu$の推定値は7.56でした。正規分布とはいえないくらいには裾が重い分布ということを示します。

築年数効果（age）、徒歩分数効果（walk）、階数効果（floor_num）、最上階効果（is_top）、1階効果（is_ground）、地下1階効果（is_underground）の各パラメータより、以下のことが分かりました²。

築年数が1年増えるごとに家賃相場は1.2%下がる
徒歩1分増えるごとに0.8%下がる
2階から上に1階高くなるごとに0.9%上がる
1階と地下1階は2階から見てそれぞれ4.6%、6.4%下がる
最上階でも家賃相場は変わらない

これらは比較用の正規分布モデルと大きく変わりませんでした。

階数のところですが、例えば4階建てのマンションで2階が家賃10万円なら、3階は10.09万円、4階は10.18万円、1階は9.54万円であり、直感的な結果なのではないでしょうか。

最寄り駅ごとの家賃相場

正規分布ではなくt分布を設定したことで、最寄り駅ごとの家賃相場をドメイン知識に合った形でうまく推定することができました。その一例を挙げます。

25m2、新築、駅から徒歩5分、3階の物件を仮定して、小田急線の最寄り駅別の家賃相場を求めてみます³。

左のプロットが今回推定したt分布のモデル、右のプロットは比較用に別途推定した正規分布のモデルです。横軸の単位は万円で、黒い点は事後分布の中央値、横の棒は95%信用区間です。

今回のt分布のモデルの方がうまく推定できたと思われるところは二つあります。

成城学園前と祖師ヶ谷大蔵
- 成城学園前は急行が止まり、祖師ヶ谷大蔵は各駅のみの停車駅
- 正規分布のモデルではほぼ差がないが、t分布モデルでは成城学園前＞祖師ヶ谷大蔵
- 祖師ヶ谷大蔵は成城学園前より一駅分都心に近いが、成城学園前は急行停車駅であることに加えて高級住宅街であるため、t分布の方の結果が納得できる
梅ヶ丘と豪徳寺、千歳船橋と祖師ヶ谷大蔵
- 4駅とも各駅停車駅
- 正規分布モデルでは梅ヶ丘＜豪徳寺、千歳船橋＜祖師ヶ谷大蔵。t分布モデルでは、95%有意ではないものの、梅ヶ丘＞豪徳寺、千歳船橋＞祖師ヶ谷大蔵
- 都心に近い方が家賃が高くなるt分布モデルの方がドメイン知識に整合的

WAICによる汎化誤差の比較

このようなきれいなストーリーが偶然ではないことを知りたいですね。汎化誤差が小さいモデルを選ぶために、WAICを計算してみます。

WAICを算出するには、まずStanのコードのmodelブロックの下に以下のgenerated quantitiesブロックを追加して対数尤度を計算しておきます。

generated quantities {
vector[N] log_lik; // 対数尤度
for (i in 1:N) {
log_lik[i] = student_t_lpdf(
log(Y[i]) |
nu,
a[STATION[i]] + b[STATION[i]] .* log(AREA[i]) +
age*AGE[i] +
walk*(WALK[i] - 1)+
floor_num*(FLOOR2[i] - 2) +
is_top*IS_TOP[i] +
is_ground*IS_GROUND[i] +
is_underground*IS_UNDERGROUND[i],
sigma
);
}
}

これによりlog_likで対数尤度を持っているCmdStanFitモデルを作っておけば、loo::waic()でWAICが計算できます。

今回使ったデータのうち、渋谷区の物件のデータ（約41000件）を用いてパラメータを推定してWAICを求めたところ、以下のとおりでした。

t分布（自由度もパラメータとして推定）: -74652.41
正規分布: -73071.94

このことからも正規分布よりはt分布の方が汎化性能がよいことが分かります。

おわりに

t分布の導入により、外れ値にロバストなモデルを作ることができました。現実のデータは裾が厚い分布に従うことがあるのでt分布は役立ちますね。

参考文献

清水千弘・唐渡広志 (2007).『不動産市場の計量経済分析』朝倉書店.

面積、築年数、最寄り駅、階数の条件は、物件数が一定程度存在する領域に絞ったという理由です。特に階数ですが、地上15階を超える物件は少ないです。建築基準法・消防法上、15階建て程度までであれば非常用エレベータやスプリンクラーの設置が免除されることから、コスト的に15階建てを超えるマンションは立てにくいものだと思われます。間取りですが、ワンルームは部屋の設備が簡略化されていることから、3LDK以上は物件数が少ないうえに近年の分譲マンション価格の高騰でファミリー層が賃貸に流れていることから、その他の間取りとは相場特性が異なると考え、これらも除外しました。 ↩︎
各パラメータのmedianの$\exp$を取ったものです。 ↩︎
他に最上階ではないという条件も設定していますが、is_topが0であることから最上階かどうかは家賃に影響を与えないので、最上階だとしてもプロットは変わりません。 ↩︎

東京23区の賃貸マンションの家賃相場を階層ベイズで推定する（2024年12月版）

Sat, 04 Jan 2025 00:00:00 +0900

はじめに

階層ベイズモデルで東京23区の賃貸マンションの家賃相場を推定しました。

2024年12月にSUUMOをスクレイピングして約60万件の東京23区の賃貸マンションの家賃データを取得しました。家賃相場の階層ベイズモデルをStanとR（cmdstanr）で実装してモデルのパラメータを推定することで、東京23区の最寄り駅別の家賃相場や、築年数、駅徒歩分数、階数による家賃の押し上げ・押し下げ効果を推定しました。

最寄り駅ごとの家賃相場はSUUMOやHOME’Sなどの賃貸物件サイトで見ることができます。ただ、これらのサイトが公表している家賃相場は、何駅の1Kはいくら？くらいの粗い粒度です。面積が1m2違うだけでも数千円変わってきますから、例えば40m2で築5年で駅徒歩5分の物件はいくら？というような細かい家賃相場が知りたいですね。また、築10年の差はどの程度家賃相場が変わってくるのかも知りたいです。知りたいのですが、ここまで細かい家賃相場は知る限りネットに見つかりません。なければ自分で作る、というわけで実装しました。

ちなみにこのブログでは以前にも家賃相場のベイズモデリングに関する記事を書いています。

これらの記事でモデルは作れていたのですが、より安定した推定精度を得るためにデータ数を増やすなどいくつかのアップデートを行いました。

データ

データ取得と前処理

SUUMOの東京23区の賃貸マンションの物件一覧ページを2024年12月に1日1回ずつ、計2週間ほどスクレイピングしました。Python（requests + BeautifulSoup4）で実装しました。

ある一時点のデータでは、スクレイピングしたときにたまたま高級物件の募集が多かった駅の家賃相場が高く推定されてしまいます。複数日のデータを用意することで、単純にデータ数を増やせるだけでなく、このような影響を軽減できます。

複数日にわたって掲載されている物件は当然重複しますので、重複を除外します。それに加えてSUUMOでは同一の物件でも異なる物件として登録されていることがあるため、この重複も除外しました¹。

そのうえで、分析やモデリングに使えるように前処理するとともに、データの誤入力や未入力と思われる物件を除外しました²。

ここまでで分析に使えるテーブルデータを作ることができました。以下のように、各行が個々の物件、列が特徴量のデータフレームです。87万件の物件データです。

同じマンションに複数の物件の募集が出ている場合は物件数だけレコードがあります。

1行目の物件は、「千代田区麹町6丁目で家賃76万円、管理費5万円（家賃+管理費81万円）、敷金76万円、礼金0万円、3LDK、90m2、中央線四ツ谷駅から徒歩3分、築4年、12階（地上14階地下0階建て）」ということを意味します。81万円の賃貸ってすごいですね…。

なお、最寄り駅はSUUMOには最大3駅まで書いてありますが、簡単のため最初の1駅の情報のみを利用します。また、物件の構造（鉄筋か鉄骨かなど）、部屋の方角、物件の設備（バストイレ別かや食洗器が付いているかなど）のようなより詳細なデータはありません³。

使用するデータ

取得できたデータのうち、以下を満たす物件のみを家賃相場の推定に使います。

マンションのみ
- 理由: アパートや一戸建ては家賃相場の推定上同一に扱えないため（築古による家賃押し下げ効果なども異なる）
間取りは1K, 1DK, 1LDK, 2K, 2DK, 2LDK
- 理由: 1Rはバストイレ一緒の物件が多いなど1K以上と同一に扱えないため除外、3K以上も物件数が少ないので除外⁴
家賃+管理費100万円以下
- 理由: 外れ値を除くため
面積は20m2～100m2
- 理由: 間取りと同様
築40年まで
- 理由: 築40年を超える物件は少ないため除外
駅から徒歩20分以内
- 理由: 23区内では徒歩20分を超える物件は少ないため除外
マンションの階数（各物件の階数ではなく、建物自体の階数）は地上15階まで、かつ地下階はないか地下1階まで
- 理由: 16階建て以上の物件は少なく、タワーマンションのような高級物件となるので除外

ある程度均質なデータに絞るということです。外れ値の除外方法は工夫の余地があると思います。約62万件の物件データを用意できました。

モデル

家賃相場は、物件の最寄り駅、面積、築年数、駅からの徒歩分数、部屋の階数で決まると考えます。実際の家賃は部屋の設備のようなその他の特徴量にも左右されますが、おおむねこれらで決まると考えても大きくは外さないでしょう。以下、家賃とは家賃+管理費を指します。

物件$i(1, \dots, N)$の最寄り駅を$sta[i] (1, \dots, S)$とします。

$$ \begin{align*} \log{y_{i}} & \sim N(\mu_{i}, \sigma) \\\ \mu_{i} &= a_{sta[i]} + b_{sta[i]} \log{\mathrm{area}_{i}} \\\ &+ \beta_{\mathrm{age}} \mathrm{age}_{i} \\\ &+ \beta_{\mathrm{walk}}(\mathrm{walk}_{i} - 1) \\\ &+ \beta_{\mathrm{floor}} \max {(\mathrm{floor}_{i} - 2, 0)} \\\ &+ \beta_{\mathrm{isTop}} \mathrm{isTop}_{i} \\\ &+ \beta_{\mathrm{isGround}} \mathrm{isGround}_{i} \\\ &+ \beta_{\mathrm{isUnderground}} \mathrm{isUnderground}_{i} \\\ a_{sta[i]} & \sim N(a_{all}, \sigma_{a_{all}}) \\\ b_{sta[i]} & \sim N(b_{all}, \sigma_{b_{all}}) \\\ \end{align*} $$

このとき、物件の対数家賃の相場は$\mu_{i}$万円であると考えます。ただし、式中の変数は以下のとおりです。

$y_{i}$: 家賃+管理費（万円）
$\mathrm{area}_{i} (20 \leq \mathrm{area}_{i} \leq 100)$: 面積（m2）
$\mathrm{age}_{i} (= 0, 1, \dots, 40)$: 築年数（新築は0年とする）
$\mathrm{walk}_{i} (= 1, 2, \dots, 20)$: 最寄り駅からの徒歩分数
$\mathrm{floor}_{i} (= -1, 1, 2, \dots, 15)$: 物件の階数
$\mathrm{isTop}_{i} (= 0, 1)$: 最上階なら1, そうではないなら0
$\mathrm{isGround}_{i} (= 0, 1)$: 1階なら1, そうではないなら0
$\mathrm{isUnderground}_{i} (= 0, 1)$: 地下1階なら1, そうではないなら0

間取りの情報は入れていません。間取りと面積はかなり相関が強い変数であり多重共線性があるので面積のみをモデルに入れました。

最寄り駅によって同じ面積でも家賃相場が違うことを考慮しています。築浅や駅近、高層階ほど家賃が高いことや、最上階は家賃が高いこと、1階や地下階は家賃が安いこともモデルに織り込んでいます。あまり物件が存在しない最寄り駅でも、全体の傾向を踏まえてパラメータを安定して推定できるのが階層ベイズのメリットです。

ただし、このモデルでは以下のように単純化した定式化となっています。

築年数は1年増えるごとに、駅徒歩1分増えるごとに家賃相場が一定割合減る
1階高くなるごとに家賃相場が一定割合上がる
築年数、駅徒歩、階数や、1階や地下1階であることがそれぞれ家賃相場を押し上げる・押し下げる効果は、全ての最寄り駅で一定であり、その他の変数とは独立

これらは一定程度強い仮定であることに注意が必要です。

実際には、築浅物件と築古物件では、築1年経過することによる家賃の押し下げ効果は築浅物件の方が大きいと思われます。物件を検索するときは徒歩10分までのようなきりのよい値を指定することが多いため、徒歩10分と11分だと家賃相場が大きく変わるかもしれません。駅近ほどよいかというと、駅に近すぎると線路や駅周辺の騒音で家賃相場が安い可能性もあります。また、築古でも駅近や人気の駅、マンションの新規建設があまり行われていない地域では家賃が下がりにくいのも想像がつきます。

モデルのブラッシュアップの余地はありますが、大まかな傾向をつかめればよいということでこのモデルを採用します。

実装

環境はR=4.4.2, cmdstan=2.35.0, cmdstanr=0.8.1, bayesplot=1.11.1, tidybayes=3.0.7です。

上のモデルをStanで書きます。このコードを”model.stan”というファイル名で保存します。

data {
int N;
vector[N] Y;
vector[N] AREA;
int S;
array[N] int<lower=1, upper=S> STATION; // 最寄り駅index
vector[N] AGE; // 築年数（0 - 40）
vector[N] WALK; // 徒歩分数（1 - 20）
vector[N] FLOOR; // 階数（2 - 15; -1と1は2とする）
vector[N] IS_TOP; // 最上階かどうか（0/1）
vector[N] IS_GROUND; // 1階かどうか（0/1）
vector[N] IS_UNDERGROUND; // 地下1階かどうか（0/1）
}
parameters {
real a_all;
real b_all;
vector[S] a;
vector[S] b;
real<upper=0> age;
real<upper=0> walk;
real<lower=0> floor_num;
real<lower=0> is_top;
real<upper=0> is_ground;
real<upper=0> is_underground;
real<lower=0> sigma_a;
real<lower=0> sigma_b;
real<lower=0> sigma;
}
model {
a ~ normal(a_all, sigma_a);
b ~ normal(b_all, sigma_b);
log(Y) ~ normal(
a[STATION] + b[STATION].*log(AREA) +
age*AGE +
walk*(WALK - 1)+
floor_num*(FLOOR - 2) +
is_top*IS_TOP +
is_ground*IS_GROUND +
is_underground*IS_UNDERGROUND,
sigma
);
}

次に以下のRコードでstanコードをキックします。さきほど画像を載せたdata.frameをdf_uniqueという変数名で持っている前提です。

library(tidyverse)
library(cmdstanr)
library(bayesplot)
library(tidybayes)
df <- df_unique |>
filter(rent_admin <= 100) |>
filter(area <= 100 & area >= 20) |>
filter(age <= 40) |>
filter(walk <= 20) |>
filter(story_under <= 1L & story_above <= 15L) |>
filter(floor >= -1L & floor <= 15L) |>
filter(layout %in% c("1K", "1DK", "1LDK", "2K", "2DK", "2LDK")) |>
# Stanに入れるために、駅名をintegerに変換する
mutate(station_index=as.integer(as.factor(station))) |>
mutate(
# 平屋や2階建ての2階の場合は「最上階」とはみなさないことにする（その方が直感的に自然なので）
is_top=as.integer(floor == story_above & story_above >= 3),
is_ground=as.integer(floor == 1L),
is_underground=as.integer(floor <= -1L)
)
mod <- cmdstanr::cmdstan_model("model.stan")
fit <- mod$sample(
data=list(
N=nrow(df),
Y=df$rent_admin,
AREA=df$area,
S=length(unique(df$station_index)),
STATION=df$station_index,
AGE=df$age,
WALK=df$walk,
# 地下1階, 1階は"2"に変換して入れる
FLOOR=df |>
mutate(floor2=if_else(floor <= 1L, 2L, floor)) |>
pull(floor2),
IS_TOP=df$is_top,
IS_GROUND=df$is_ground,
IS_UNDERGROUND=df$is_underground
),
chains=4, parallel_chains=4, iter_warmup=1000, iter_sampling=1000, thin=1,
seed=1234, refresh=10
)

StanコードをRからキックするパッケージは、前の記事まではrstanを用いていましたが、cmdstanrに乗り換えました。コンパイルが早い、動作が安定していてクラッシュしにくい、開発が盛ん、OpenCLでGPUも使えるなどいいことづくめです。

warmupを入れて合計2000回のiterationで約2日かかりました。

結果

パラメータ

Rhat < 1.1であること以外にもStanによるMCMCの収束チェックは行いましたが、記事上は省略します⁵。

fit$print(
c("a_all", "b_all", "age", "walk", "floor_num", "is_top", "is_ground", "is_underground",
"sigma_a", "sigma_b", "sigma"),
max_rows=11, digits=3
)
#> variable mean median sd mad q5 q95 rhat ess_bulk ess_tail
#> a_all -0.146 -0.146 0.016 0.016 -0.172 -0.120 1.001 7784 2950
#> b_all 0.839 0.839 0.006 0.006 0.829 0.848 1.001 7788 2648
#> age -0.012 -0.012 0.000 0.000 -0.012 -0.012 1.000 4176 2826
#> walk -0.008 -0.008 0.000 0.000 -0.008 -0.008 0.999 10482 2819
#> floor_num 0.009 0.009 0.000 0.000 0.009 0.009 1.002 9145 3069
#> is_top 0.000 0.000 0.000 0.000 0.000 0.000 1.001 5474 2358
#> is_ground -0.047 -0.047 0.000 0.000 -0.048 -0.046 1.000 8558 3008
#> is_underground -0.069 -0.069 0.002 0.002 -0.073 -0.065 1.004 10218 2805
#> sigma_a 0.333 0.333 0.012 0.012 0.315 0.353 1.000 5732 2706
#> sigma_b 0.119 0.119 0.004 0.004 0.113 0.126 1.000 7172 3115
#> sigma 0.109 0.109 0.000 0.000 0.109 0.109 1.000 3873 2026

築年数効果、駅徒歩分数効果、階数効果、最上階・1階・地下1階効果

パラメータageは事後分布の中央値が-0.0119でした。築年数が1年増えるごとに家賃相場の対数$\mu_{i}$が-0.0119小さくなることを意味します。つまり、築年数が1年増えるごとに家賃相場$\exp(\mu_{i})$は$\exp(-0.0119) = 0.988$倍になる、すなわち築年数が1年増えるごとに家賃相場は1.2%下がるということです。新築と比べると築5年は約6%、築10年は約11%家賃が下がることになります。

築1年経過するごとに家賃が1%下がるという経験則があるそうです。結果はこの経験則と整合的ですね。ただし今引用したレポートでは、築10年までの築浅物件とそれ以降の物件では前者の方が経年による家賃の下落率が高いと指摘されています。この点の考慮は今後の課題です。

同様に駅徒歩1分増えるごとに家賃相場は0.8%下がることが分かりました。

また、2階から見て1階上がるごとに家賃相場は0.9%上がります。また、1階と地下1階は2階から見てそれぞれ4.6%、6.7%家賃相場が下がります。is_undergroundのパラメータの95%信用区間の下限が0を上回らないことから、最上階であっても家賃は変わらないと言えることも分かりました。最上階はお得ですね！

例えば地上4階地下1階建てのマンションで2階が家賃10万円なら、3階は10.09万円、4階は10.18万円、1階は9.54万円、地下1階は9.33万円程度になる計算になります。だいぶ妥当な感じがします。1階は避けたがる人も多いですが、5%安いメリットを天秤にかけてどう判断するかですね。

最寄り駅ごとの家賃相場

25m2、新築、駅から徒歩5分、3階の物件を仮定して、この物件の最寄り駅別の家賃相場を求めてみましょう⁶。25m2というのは1Kや1DKでよくある面積です。特に1Kでは25m2～26m2というサイズの物件が非常に多いです。MCMCで得られた各パラメータのサンプリングされた値を用いて$\exp(\mu_{i})$の分布を求めることで計算できます。

JR中央線の新宿より西側を見てみます。

Code

draws <- tidybayes::spread_draws(
fit, a[station_index], b[station_index], age, walk, floor_num, is_top, is_ground, is_underground
)
station_index_table <- df |>
select(station, station_index) |>
distinct(station, .keep_all=TRUE)
# 駅名があればそのindex, なければNA_integer_を返す
station_to_idx <- function(station_name) {
chr <- station_index_table$station
idx <- station_index_table$station_index
if (length(idx[which(chr==station_name)]) == 0) {
return(NA_integer_)
} else {
return(idx[which(chr==station_name)])
}
}

Code

stations <- c(
"新宿駅", "大久保駅", "東中野駅", "中野駅", "高円寺駅", "阿佐ケ谷駅", "荻窪駅", "西荻窪駅"
)
idxs <- map_int(stations, station_to_idx)
AREA <- 25
AGE <- 0
WALK <- 5
FLOOR <- 3
IS_TOP <- 0
draws |>
filter(station_index %in% idxs) |>
# 駅名をプロットに表示するため
left_join(station_index_table, by="station_index") |>
mutate(station=factor(station, levels=rev(stations))) |>
mutate(
mu_exp=exp(
a + b*log(AREA) +
age*AGE +
walk*(WALK - 1) +
floor_num*max(FLOOR - 2, 0) +
is_top*IS_TOP +
is_ground*as.integer(FLOOR == 1L) +
is_underground*as.integer(FLOOR == -1L)
)
) |>
ggplot(aes(mu_exp, station))+
theme_minimal()+
tidybayes::stat_pointinterval(point_interval=tidybayes::median_qi, .width=0.95)+
theme(axis.title.y=element_blank(), axis.text=element_text(color="black"))

黒い点は事後分布の中央値、点の左右にある棒は95%ベイズ信用区間です。25m2の新築、徒歩5分、3階の物件は最寄り駅が荻窪駅だと黒い点より13.1万円くらい、棒より95%の確率で13.0万円 - 13.2万円くらいだということを示します。

なお、例えば築年数以外は同じ条件のまま築10年の家賃相場を考えてみると、築10年は新築と比べて約11%安くなることが分かっていますから、13.1万円 x 89% = 11万円後半になります。

12万円台後半～13万円の高円寺から西荻窪は駅によって街の特徴が分かれるところですが、個人的には西荻窪は商店街が個性的なお店やおいしいお店が多く魅力的です。新宿まで15分ですし、10分で中野に出て東京メトロの東西線にも乗り換えられて交通の便もいいですね。隣が吉祥寺なので買い物に困ることもないですね。

家賃相場の数値自体がどのくらい合っているかは評価が難しいところですが、最寄り駅ごとの相対的な違いとしては割と妥当に思われました。

さて、いま示した「家賃相場」とは何でしょうか？今回設定したモデルの下では、「荻窪駅から徒歩5分、新築、25m2、3階の物件の家賃の平均的な値」という確率変数$\exp(\mu_{i})$があり、これを「家賃相場」と呼ぶと、家賃相場の中央値は13.1万円であり、家賃相場の確率分布の95%は13.0万円 - 13.2万円の間に入るということを示します。

実際の物件の家賃は、この家賃相場にさらに$\sigma$というノイズが乗ったものとして観測される⁷ので、実際には13万円より安い物件も13.2万円より高い物件もありえます。ノイズには、バストイレ別かどうか、分譲賃貸かのようなモデルに入れていない特徴量や、その他説明が付かなかった物件固有のいろいろなものが含まれます。

おわりに

このモデルを参考にしながら物件を探してみたのですが、「掘り出し物の物件」というものはほとんどないんだなと思いました。グレードの高い物件はたいてい家賃相場から少し高めに設定されていましたし、家賃相場と比べて安い物件はエレベーターが付いていないなど、理由が何かしらありました。

東京23区だけでも1ヶ月で100万件近いデータが得られたように賃貸マンション市場は非常に大きい市場であるため、競争が働いていて効率的な市場になっているということなんですね。

なので掘り出し物の物件を見つけようというよりは、最寄り駅を変えるとどのくらい相場が変わるのかとか、築年数を10年下げる代わりに同じ家賃でどのくらい広い物件に住めるのかとか、物件探しのときの検討材料にするのがよさそうです。

このような目的としては統計モデリングが非常に効果的ですね。予測精度としてはLightGBMのような機械学習の決定木の特徴を持つ手法が優れていますし、LightGBMでもPartial Dependenceで似たような解釈ができます。

しかし、統計モデルには、最寄り駅ごとに家賃相場が異なるというようなデータ生成のメカニズムを明示的にモデルに織り込むことでドメイン知識を活用できるメリットがあります。また、ベイズモデリングによって、複雑な統計モデルであってもある程度パラメータを推定しやすいことや、パラメータの信用区間という形で何パーセントの確率でパラメータはこの範囲内であるというパラメータの確信度合いを示せることが、解釈性の高さにつながっています。

今後は築年数や駅徒歩分数の効果を非線形にするとか、家賃の外れ値のデータにロバストにするように正規分布ではなくt分布を導入するとか、モデルの高度化を進めてみたいです。

例えば、全く同じ物件でも、マンション名が「○○マンション」のように明記されているページと、「○○駅徒歩x分築y年」のように明記されていないページで複数回登場することがあります。住所、最寄り駅と最寄駅からの分数、築年数、物件の階数、家賃が全く同じでマンション名だけ異なる物件が複数回ある場合は重複を除外するようにしました。 ↩︎
詳細は階層ベイズで東京23区のお部屋の家賃相場を推定する#前処理をご参照ください。 ↩︎
これらのデータは各物件の詳細ページに載っています。物件一覧ページは1ページに数十件の物件が載っているため高速にスクレイピングできますが、詳細ページは1ページ1件のため時間の制約上現実的にスクレイピングできないので断念しました。 ↩︎
1SLDKのように納戸のある物件もありますが、これも除外しています。納戸は居室には使えない部屋なので、納戸の面積は家賃に与える影響がその他の部屋と異なる可能性があるため、モデルからは除外しました。 ↩︎
一般的に、[R] [stan] bayesplot を使ったモンテカルロ法の実践ガイド - ill-identified diaryのような内容をチェックします。詳細は階層ベイズで東京23区のお部屋の家賃相場を推定する#推定結果のチェックをご参照ください。 ↩︎
他に最上階ではないという条件も設定していますが、これまでみたように最上階かどうかは家賃に影響を与えないので、最上階だとしてもプロットは変わりません。 ↩︎
正確には、$\log y_{i} \sim N(\mu_{i}, \sigma)$で生成される$y_{i}$のexpを取ったものです。$\exp(\mu_{i})$は信用区間、$y_{i}$は予測区間を求めているという違いです。 ↩︎

Rで画像をドット絵化する

Thu, 19 Dec 2024 00:00:00 +0900

はじめに

この記事はR言語 Advent Calendar 2024の19日目の記事です。

Rのパッケージimagerを用いて、アニメ絵をドット絵に変換してみました。ドット絵作りたいな～と思い立ちまして、せっかくなので好きなRで実装してみました。

ロジック

ドット絵化のロジックはこちらです。

画像を適当な幅でグリッドに切り、それぞれのグリッドについて、全ての画素のRGB値をグリッド内の画素のRGB値の平均値とする（平均プーリング）
k-means法により、各グリッドのRGB値を、指定した色数でクラスタリングされた値に置き換える

1で色と色の境目をギザギザにして2で色数を減らすことでドット絵っぽさを出します。k-meansはこちらの記事（k-means法を用いて画像をドット絵風に変換する）にアイデアをもらいました。なお、2の前に1でも色数が減るため、2のk-meansの実行時間を抑えることができます。

グリッドの縦と横のピクセル数とk-meansの色数はハイパーパラメータとして与えます。これらの値次第でドット絵の味わいが変わってきます。

実装で使うimagerはC++のCImgをラップしたパッケージです。画像処理分野では他にもImageMagickのラッパーのmagickやOpenCVのラッパーのRvisionなどいくつかパッケージがあるようです。今回の内容は配列操作で完結するので何を使ってもいいと思います。

実装

アニメ「スローループ」の海凪小春ちゃんです¹。この画像をドット絵にします。（©うちのまいこ・芳文社／スローループ製作委員会）

画像の読み込み

環境はR4.4.2, imager1.0.2です。

# install.packages(c("tidyverse", "imager"))
library(tidyverse)
library(imager)

まず、imager::load.image()で画像を読み込みます。

img <- imager::load.image("slowloop.jpg")
plot(img)

imager::load.image()で読み込まれた画像はcimgというS3クラスであり、その実体はwidth x height x depth（静止画なら1、動画ならフレーム数） x color channel（透過度（アルファチャンネル）がないカラー画像なら3）の4次元arrayです。

img
#> Image. Width: 1920 pix Height: 1080 pix Depth: 1 Colour channels: 3
str(img)
#> 'cimg' num [1:1920, 1:1080, 1, 1:3] 0.863 0.863 0.863 0.863 0.863 ...

1920px x 1080pxの画像であることが分かります。

実体はarrayなのでdimのような配列操作の関数が使えますし、as.array()するとarrayを得ることができます。

試しに左上の座標が(101, 101)、右下の座標が(105, 105)の長方形の領域を取り出してみます。R, G, Bの値が4次元で入っていることが分かります。（255で割って0-1にスケーリングされた値が入っています）

as.array(img)[101:105, 101:105, 1, , drop=FALSE]
#> , , 1, 1
#>
#> [,1] [,2] [,3] [,4] [,5]
#> [1,] 0.7333333 0.7215686 0.7137255 0.7058824 0.6980392
#> [2,] 0.7333333 0.7176471 0.7098039 0.7019608 0.6980392
#> [3,] 0.7333333 0.7176471 0.7098039 0.7019608 0.6941176
#> [4,] 0.7294118 0.7137255 0.7098039 0.7019608 0.6941176
#> [5,] 0.7254902 0.7137255 0.7098039 0.7058824 0.6941176
#>
#> , , 1, 2
#>
#> [,1] [,2] [,3] [,4] [,5]
#> [1,] 0.8352941 0.8313725 0.8235294 0.8196078 0.8117647
#> [2,] 0.8352941 0.8274510 0.8196078 0.8156863 0.8117647
#> [3,] 0.8352941 0.8274510 0.8196078 0.8156863 0.8078431
#> [4,] 0.8313725 0.8235294 0.8196078 0.8156863 0.8078431
#> [5,] 0.8235294 0.8235294 0.8196078 0.8196078 0.8078431
#>
#> , , 1, 3
#>
#> [,1] [,2] [,3] [,4] [,5]
#> [1,] 0.9803922 0.9843137 0.9764706 0.9764706 0.9764706
#> [2,] 0.9803922 0.9803922 0.9764706 0.9725490 0.9764706
#> [3,] 0.9803922 0.9803922 0.9764706 0.9803922 0.9725490
#> [4,] 0.9764706 0.9764706 0.9764706 0.9803922 0.9803922
#> [5,] 0.9803922 0.9764706 0.9764706 0.9843137 0.9803922

平均プーリングによる減色

1920px x 1080pxの元の画像を、縦横15pxずつのグリッドに切って、各グリッドのRGB値を平均値に置き換えます。

# グリッドの縦と横の幅
row_px <- 15
col_px <- 15
width <- dim(img)[1]
height <- dim(img)[2]
# 空のarrayを用意しておく
# 1は静止画なので、3はカラー画像なので
img_average <- array(NA_real_, dim=c(width, height, 1, 3))
for (x0 in seq(1, width, by=col_px)) {
for (y0 in seq(1, height, by=row_px)) {
# x1 <- x0-1+col_pxだと元の画像がグリッドで割り切れないときにエラーになる
x1 <- min(x0-1+col_px, width)
y1 <- min(y0-1+row_px, height)
img_block <- img[x0:x1, y0:y1, 1, 1:3, drop=FALSE]
img_average[x0:x1, y0:y1, 1, 1] <- mean(img_block[, , 1, 1])
img_average[x0:x1, y0:y1, 1, 2] <- mean(img_block[, , 1, 2])
img_average[x0:x1, y0:y1, 1, 3] <- mean(img_block[, , 1, 3])
}
}
img_average <- imager::as.cimg(img_average)

img_average <- as.cimg(img_average)の部分ですが、width x height x depth x color channelの4次元arrayをimager::as.cimg()するとcimgオブジェクトに変換できます。

k-means

cimgオブジェクトをas.data.frame()すると、x, yにおけるカラーチャンネルの画素値がdata.frameで得られます。

as.data.frame(img_average) |>
head(5)
#> x y cc value
#> 1 1 1 1 0.8627451
#> 2 2 1 1 0.8627451
#> 3 3 1 1 0.8627451
#> 4 4 1 1 0.8627451
#> 5 5 1 1 0.8627451

このdata.frameの状態でstats::kmeansを実行します。ただしさきほど平均プーリングをかけたので、高速化のために画素値が異なっている行のみを残してからk-meansを実行します。

使える色は16色にしてみます。

# k-meansのパラメータ
k <- 16
nstart <- 1234
# 扱いやすくするためにdata.frameに変換する
img_average_df <- as.data.frame(img_average) |>
# pivot_widerで横持ちにすると`1`, `2`, `3`という列ができるので
# 先頭にccを付けておくことでselectなどするときにバッククオートで囲わなくてすむ
mutate(cc=str_c("cc", cc)) |>
pivot_wider(names_from=cc, values_from=value)
# ユニークなピクセルだけでk-meansを実行することで高速化する
# ユニークなピクセルを識別するidを付けておく
img_unique_df <- img_average_df |>
distinct(cc1, cc2, cc3, .keep_all=TRUE) |>
select(cc1, cc2, cc3) |>
mutate(id=row_number())
img_average_df <- img_average_df |>
left_join(img_unique_df, by=c("cc1", "cc2", "cc3"))
# k-meansを実行する
res_kmeans <- kmeans(
img_unique_df |>
select("cc1", "cc2", "cc3"),
centers=k, nstart=nstart, iter.max=1000, algorithm="MacQueen"
)
img_kmeans_df <- data.frame(
res_kmeans$centers[res_kmeans$cluster, ]
) |>
as_tibble() |>
set_names(c("cc1_k", "cc2_k", "cc3_k")) |>
mutate(id=row_number())
# 元の平均プーリングした画像のそれぞれのピクセルのRGB値にk-meansしたあとのRGB値をつける
res <- left_join(img_average_df, img_kmeans_df, by="id") |>
select(x, y, cc1_k, cc2_k, cc3_k) |>
pivot_longer(c(cc1_k, cc2_k, cc3_k), names_to="cc") |>
mutate(cc=case_when(
cc == "cc1_k" ~ 1L,
cc == "cc2_k" ~ 2L,
cc == "cc3_k" ~ 3L
))
# x, y, cc, valueを列に持つdata.frameを`imager::as.cimg()`すると`cimg`オブジェクトに変換できる
res <- imager::as.cimg(res, dim=c(width, height, 1, 3))
imager::save.image(res, "output.jpg")

結果

結果です。だいたい20秒くらいで作れました。

ドット絵感が出てますね！

今の画像は16色ですが、8色に絞ってみます。

ドット絵感はより強くなりましたが、使える色数が減ったのでほっぺたや手の指の境目など一部色が消えていますね。

もっとグリッドを小さくしたり色数を増やしたりすると絵はきれいになりますがドット絵感が薄れます。グリッドの幅と高さや色数の最適な値は元の画像によって異なります。書き込みが細かい画像であればグリッドを小さくしたり色数を増やしたりする方が上手に作れます。

おわりに

シンプルなアルゴリズムですが、いい感じのドット絵を作ることができました。Rで画像処理も楽しいですね。

Realized Volatilityの理論と実装

Tue, 10 Dec 2024 00:00:00 +0900

はじめに

この記事はマケデコ Advent Calendar 2024の10日目の記事です。

Realized Volatility (RV) という、金融商品の価格のボラティリティの推定量があります。

RVはティックレベル～分足レベルの高頻度の価格データから計算できます。モデルフリーで精度のよい日次ボラティリティの推定量であることが知られているとともに、連続な価格変動によるボラティリティとジャンプによるボラティリティを分離するように拡張できるのがメリットです。

この記事ではまずRVの理論をざっくり解説したあと、GMOコインのAPIからドル円の分足データを取得してドル円のRVの計算を実装します。

為替介入があった日にジャンプによるボラティリティが大きかったことが確認できました。これは、RVによるボラティリティの推定と、ジャンプ拡散過程を考慮することによるボラティリティの連続成分とジャンプ成分の分離が有用なことを示唆します。

理論

ボラティリティはリスク管理上などで重要な変数ですが真の値は直接観測できない潜在変数であるため、その推定方法は数理ファイナンスの主要な分野となっています。

一定期間の日次収益率のローリング標準偏差とする方法はシンプルながらよく用いられる方法ですが、ローリングウィンドウの間はボラティリティが一定であることを仮定するため、ボラティリティの日々のシャープな変動をとらえることができません。

日々変動するボラティリティを推定するため、日次のボラティリティを数理モデルで表し、日次の収益率からボラティリティを推定する方法があります。有名なGARCHモデルや、状態空間モデルの一種であるStochastic Volatility (SV) モデルはこれに該当します。なお、昨年のアドベントカレンダーの記事ではSVモデルをStanで実装してみました。興味があれば読んでみてください。

一方、高頻度の価格データを用いることでボラティリティの推定量を直接求めるアプローチがあります。特に2000年代～2010年代に注目された分野です。最も代表的な推定量であるAndersen and Bolleslev (1998) が示したRVについて、簡単に解説します。

連続過程

ある時点$s$における資産の対数価格を$p(s)$とします。

いま、$t$日に等間隔に$n$回価格が観測されるとして¹、$t$日の観測時点$i$における日中収益率を

$$ r_{t, i} = p(t-1 + i/n) - p(t-1 + (i-1)/n), \quad i=1, 2, \dots, n $$

と定義します。要するに1時点前との対数収益率です。

このとき、$t$日のRVは以下で求められます。

$$ RV_{t} = \sum_{i=1}^n r_{t, i}^2 $$

日中収益率をそれぞれ2乗して足し合わせただけですね。

RVは真のボラティリティの一致推定量であることが知られています²。簡単な計算方法に見えますが、対数価格がセミマルチンゲールな確率過程に従うとき、RVは真のボラティリティの一致推定量であるという理論的な裏付けがあります。

いま具体的に、$p(s)$が以下の確率過程に従うとします³。$W(s)$は標準ブラウン運動です。

$$ dp(s) = \mu(s) ds + \sigma(s) dW(s) $$

$t$日における真のボラティリティ$IV_{t}$ (Integrated Volatility; IV) は、瞬間的なボラティリティ$\sigma(s)$を一日分積分したものです。

$$ IV_{t} = \int_{t-1}^{t} \sigma(s)^2 ds $$

ただし、積分範囲の$t-1, t$は、それぞれ$t-1$日, $t$日の最後の観測時点であることを示します。

ここで問題になるのは、$\sigma(s)$は直接観測できないパラメータなので$IV_{t}$も直接観測できないということです。そのため、何かしらの方法で推定値を求めることになります。

$n \rightarrow \infty$のとき$RV_{t} \rightarrow IV_{t}$となるため⁴、$n$を大きく取るとき、RVはIVの精度のよい一致推定量となります。

なお、$t$日における対前日の対数収益率を$r_{t}$とすると、以下の$\sigma_{t}$が$t$日における真のボラティリティです。

$$ \begin{aligned} r_{t} &= E_{t-1} [r_{t}] + \epsilon_{t} \\ \epsilon_{t} &= \sigma_{t} z_{t}, \quad \sigma_{t} > 0, \quad z_{t} \sim i.i.d., \quad E[z_{t}] = 0, \quad Var[z_{t}] = 1 \end{aligned} $$

$E_{t-1} [r_{t}]= 0, z_{t} \sim N(0, 1)$とすれば$r_{t} \sim N(0, \sigma_{t}^2)$です。$RV_{t}$は$\sigma_{t}^2$であるというとRVとは何かイメージしやすいのではないでしょうか。

ジャンプ過程

実際の対数価格は連続な確率過程ではなく、しばしば不連続なジャンプを含みます。以上の議論をジャンプ過程に拡張してみましょう。

$p(s)$は以下のジャンプ拡散過程に従うとします。

$$ dp(s) = \mu(s) ds + \sigma(s) dW(s) + \kappa(s) dN(s) $$

$N(s)$は時点$s$でジャンプがある場合$dN(s) = 1$、ない場合$dN(s) = 0$となるポアソン過程です。$\kappa(s)$は時点$s$におけるジャンプの大きさを表します。

連続の場合と同様に、$RV_{t} = \sum_{i=1}^n r_{t, i}^2$とすると、$n \rightarrow \infty$のとき、

$$ RV_{t} \rightarrow \int_{t - 1}^{t} \sigma(s)^2 ds + \sum_{t-1 < s \leq t} \kappa(s)^2 $$

となります。

右辺第1項と右辺第2項はそれぞれ連続 (Continuous) な価格変動によるボラティリティとジャンプ (Jump) の価格変動によるボラティリティです。それぞれの推定量を$C_{t}, J_{t}$と表します。

ジャンプ過程: ジャンプ部分に由来するボラティリティの分離

$C_{t}, J_{t}$は異なる性質を持つリスクなので、$RV_{t}$を$C_{t}, J_{t}$に分解できると嬉しいことがありそうです。分解の方法については提案されている手法がいくつかありますが、Barndorff-Nielsen and Shephard (2004, 2006) の方法を説明します。

次の式の$BV_{t}$ (Bipower Variation; BV) は$n \rightarrow \infty$で連続部分のボラティリティに確率収束します。

$$ BV_{t} = \mu_{1}^{-2} \sum_{i=2}^{n} |r_{t, i}| |r_{t, i-1}| $$

ただし、$\mu_{1} = 2^{1/2} \Gamma(1) \Gamma(1/2)^{-1}$です。

以上より、$n \rightarrow \infty$のとき、$C_{t} = BV_{t}, J_{t} = \max(RV_{t} - BV_{t}, 0)$となります。

ただし、ジャンプの存在が有意かどうかを検定することが実証上は多いです。ジャンプが存在しないという帰無仮説のもとでは、以下の統計量$Z_{t}$は漸近的に標準正規分布に従います。

$$ Z_{t} = \frac{\log RV_{t} - \log BV_{t}}{((\mu_{1}^{-4} + 2\mu_{1}^{-2} - 5) TQ_{t} BV_{t}^{-2} / n)^{1/2}} $$

ただし、$TQ_{t}$ (Tri-power Quarticity; TQ) は

$$ TQ_{t} = n \mu_{4/3}^{-3} \sum_{i=3}^{n} |r_{t, i}|^{4/3} |r_{t, i-1}|^{4/3} |r_{t, i-2}|^{4/3} $$

であり、$\mu_{4/3} = 2^{2/3} \Gamma(7/6) \Gamma(1/2)^{-1}$です。

有意水準を5%のように設定して⁵、帰無仮説が棄却されれば$J_{t} = RV_{t} - BV_{t}$、棄却されなければ$J_{t} = 0$とします。

nの設定

以上の議論は$n \rightarrow \infty$で行ってきたので、実装する際にはティックデータを用いるのが一見最もよさそうに思われます。

しかし、実際のマーケットでは、価格には様々なノイズ（マイクロマーケットストラクチャーノイズといいます）が含まれています。一例を挙げると、価格には呼値が設定されていますが、最も高い買値で約定するか最も安い売値で約定するかによって、真の価格は変わらなくても実際の価格はBidとAskを行ったり来たりします。なのでnを細かくするほどRVにはノイズが多く含まれ、IVの一致推定量としての精度が落ちます。

ではノイズを考慮してnをどの程度に取るのが望ましいかですが、アセットクラスや流動性によって多少異なるものの、RVでは5分間隔の価格データを用いるのがおおむねよいとされます (Liu, Patton and Sheppard (2015))。以前より実証では5分がよく用いられていたのですが、5分のRVは他の時間間隔や他のボラティリティの推定量と比べてだいぶいい推定精度のパフォーマンスを示すことがこの論文で示されました⁶。

実装

RVを実装してみましょう。上の結果の導出は難しいですが、結果の実装は難しくありません。

データの取得

GMOコインが為替の分足データをAPI経由で無料で提供しています。ここからドル円の5分足をJSTの2023/10/30から2024/12/6まで取得します。分足が簡単に手に入りレスポンスも速い、いいAPIです。

環境はpython=3.11.5, polars=1.16.0, plotnine=0.14.3です。

import datetime
import json
import math
import time
import plotnine as pn
import polars as pl
import requests
import scipy as sp

endpoint = "https://forex-api.coin.z.com/public/v1/klines"
dates = [i.strftime("%Y%m%d") for i in pl.date_range(
start=datetime.date(2023, 10, 28),
end=datetime.date(2024, 12, 6),
interval="1d",
eager=True
)]
res = []
for date in dates:
params = {
"symbol": "USD_JPY",
"priceType": "ASK",
"interval": "5min",
"date": date,
}
resp = requests.get(endpoint, params=params)
# データが存在しない日（市場が開いていない日）は空のリスト("[]")が返る
res.append(pl.DataFrame(json.loads(resp.text)["data"]))
time.sleep(1)
df = pl.concat([i for i in res if not i.is_empty()])
df = (
df
.with_columns(
open=pl.col("open").cast(float),
high=pl.col("high").cast(float),
low=pl.col("low").cast(float),
close=pl.col("close").cast(float),
)
)

取得したデータをpolars.DataFrameで持ちます。

shape: (82_248, 5)
┌───────────────┬─────────┬─────────┬─────────┬─────────┐
│ openTime ┆ open ┆ high ┆ low ┆ close │
│ --- ┆ --- ┆ --- ┆ --- ┆ --- │
│ str ┆ f64 ┆ f64 ┆ f64 ┆ f64 │
╞═══════════════╪═════════╪═════════╪═════════╪═════════╡
│ 1698616800000 ┆ 149.641 ┆ 149.685 ┆ 149.641 ┆ 149.669 │
│ 1698617100000 ┆ 149.669 ┆ 149.669 ┆ 149.636 ┆ 149.644 │
│ 1698617400000 ┆ 149.644 ┆ 149.677 ┆ 149.638 ┆ 149.67 │
│ … ┆ … ┆ … ┆ … ┆ … │
│ 1733517900000 ┆ 150.103 ┆ 150.123 ┆ 150.096 ┆ 150.105 │
│ 1733518200000 ┆ 150.105 ┆ 150.109 ┆ 150.075 ┆ 150.105 │
│ 1733518500000 ┆ 150.106 ┆ 150.111 ┆ 150.091 ┆ 150.096 │
└───────────────┴─────────┴─────────┴─────────┴─────────┘

openTime列はUTCのエポックミリ秒なので、JSTに直します。

次に、RVなどの計算において何時から何時までを1日として扱うかですが、APIのパスパラメータでdate=yyyymmddを指定すると、JSTのyyyymmddの6:00-翌日5:59（月曜日はJST7:00-5:59）のデータが得られるので、JSTの6:00-5:59を1日とすることにします。

df = (
df
.rename({"openTime": "openTimeUtc"})
.with_columns(
timestamp_utc=pl.from_epoch(pl.col("openTimeUtc").cast(int), time_unit="ms")
)
.with_columns(
timestamp_jst=pl.col("timestamp_utc")+datetime.timedelta(hours=9),
timestamp=pl.col("timestamp_utc")+datetime.timedelta(hours=9)-datetime.timedelta(hours=6)
)
.with_columns(date=pl.col("timestamp").dt.date())
)

こんなデータができました。表示上の都合で一部の列に絞っています。

JSTの2023/10/30の7:00-7:05は始値が149.641, 終値が149.669ということを示します。

shape: (82_248, 6)
┌─────────┬─────────┬─────────┬─────────┬─────────────────────┬────────────┐
│ open ┆ high ┆ low ┆ close ┆ timestamp_jst ┆ date │
│ --- ┆ --- ┆ --- ┆ --- ┆ --- ┆ --- │
│ f64 ┆ f64 ┆ f64 ┆ f64 ┆ datetime[ms] ┆ date │
╞═════════╪═════════╪═════════╪═════════╪═════════════════════╪════════════╡
│ 149.641 ┆ 149.685 ┆ 149.641 ┆ 149.669 ┆ 2023-10-30 07:00:00 ┆ 2023-10-30 │
│ 149.669 ┆ 149.669 ┆ 149.636 ┆ 149.644 ┆ 2023-10-30 07:05:00 ┆ 2023-10-30 │
│ 149.644 ┆ 149.677 ┆ 149.638 ┆ 149.67 ┆ 2023-10-30 07:10:00 ┆ 2023-10-30 │
│ … ┆ … ┆ … ┆ … ┆ … ┆ … │
│ 150.103 ┆ 150.123 ┆ 150.096 ┆ 150.105 ┆ 2024-12-07 05:45:00 ┆ 2024-12-06 │
│ 150.105 ┆ 150.109 ┆ 150.075 ┆ 150.105 ┆ 2024-12-07 05:50:00 ┆ 2024-12-06 │
│ 150.106 ┆ 150.111 ┆ 150.091 ┆ 150.096 ┆ 2024-12-07 05:55:00 ┆ 2024-12-06 │
└─────────┴─────────┴─────────┴─────────┴─────────────────────┴────────────┘

RVの実装

前のセクションで述べた結果を実装します。ジャンプの検定に使う有意水準は5%としています。

mu_1 = 2**(1/2) * math.gamma(1) * math.gamma(1/2)**(-1)
mu_4over3 = 2**(2/3) * math.gamma(7/6) * math.gamma(1/2)**(-1)
alpha = 0.95
df_volatility = (
df
# 収益率は100倍して%表記にする
.with_columns(ret=(pl.col("close").log() - pl.col("close").shift(1).log()) * 100)
.group_by("date")
.agg(
n=pl.len(),
rv=(pl.col("ret")**2).sum(),
bv=mu_1**(-2) * (pl.col("ret").abs() * pl.col("ret").shift(1).abs()).sum(),
tq=pl.len() * mu_4over3**(-3) * (pl.col("ret").abs()**(4/3) * pl.col("ret").shift(1).abs()**(4/3) * pl.col("ret").shift(2).abs()**(4/3)).sum(),
)
.sort("date")
.with_columns(
z=(pl.col("rv").log() - pl.col("bv").log()) / ((mu_1**(-4) + 2 * mu_1**(-2) - 5) * pl.col("tq") * pl.col("bv")**(-2) / pl.col("n"))**(1/2)
)
.with_columns(
j=pl.when(pl.col("z") > sp.stats.norm.ppf(alpha)).then(pl.col("rv") - pl.col("bv")).otherwise(pl.lit(0))
)
.with_columns(
c=pl.col("rv") - pl.col("j")
)
)

以下のとおり求められました。

shape: (288, 8)
┌────────────┬─────┬──────────┬──────────┬──────────┬───────────┬──────────┬──────────┐
│ date ┆ n ┆ rv ┆ bv ┆ tq ┆ z ┆ j ┆ c │
│ --- ┆ --- ┆ --- ┆ --- ┆ --- ┆ --- ┆ --- ┆ --- │
│ date ┆ u32 ┆ f64 ┆ f64 ┆ f64 ┆ f64 ┆ f64 ┆ f64 │
╞════════════╪═════╪══════════╪══════════╪══════════╪═══════════╪══════════╪══════════╡
│ 2023-10-30 ┆ 276 ┆ 0.199465 ┆ 0.094773 ┆ 0.012525 ┆ 13.415503 ┆ 0.104692 ┆ 0.094773 │
│ 2023-10-31 ┆ 288 ┆ 0.374825 ┆ 0.30842 ┆ 0.333002 ┆ 2.266396 ┆ 0.066405 ┆ 0.30842 │
│ 2023-11-01 ┆ 288 ┆ 0.194893 ┆ 0.19418 ┆ 0.086115 ┆ 0.052693 ┆ 0.0 ┆ 0.194893 │
│ … ┆ … ┆ … ┆ … ┆ … ┆ … ┆ … ┆ … │
│ 2024-12-04 ┆ 288 ┆ 0.487489 ┆ 0.446522 ┆ 0.22751 ┆ 1.786992 ┆ 0.040967 ┆ 0.446522 │
│ 2024-12-05 ┆ 288 ┆ 0.471903 ┆ 0.458031 ┆ 0.306132 ┆ 0.537139 ┆ 0.0 ┆ 0.471903 │
│ 2024-12-06 ┆ 288 ┆ 0.486899 ┆ 0.455146 ┆ 0.425198 ┆ 1.023669 ┆ 0.0 ┆ 0.486899 │
└────────────┴─────┴──────────┴──────────┴──────────┴───────────┴──────────┴──────────┘

polarsはめちゃくちゃ読みやすいですね。polarsは大きなDataFrameを高速に処理できることがメリットとしてよく言われますが、認知負荷にやさしい構文なのが一番好きなポイントです。Rのtidyverseに近い書き方なのでtidyverseで育ったわたしにとっても使いやすいです。

プロット

RVは%表記です。積み上げ面グラフで連続部分$C_{t}$とジャンプ部分$J_{t}$に分けています。

Code

p1 = (
pn.ggplot(
df_volatility
.select("date", "j", "c")
.unpivot(index="date", variable_name="variable", value_name="value"),
)
+pn.geom_area(pn.aes("date", "value", fill="variable"), color="gray", size=0.2, alpha=0.8)
+pn.scale_fill_brewer(type="qual", palette="Set2")
+pn.scale_x_date(date_labels="%Y/%m")
+pn.scale_y_continuous(breaks=range(0, 100, 1))
+pn.theme_minimal()
+pn.labs(x="date", y="volatility", title="realized volatility", subtitle="decomposed into continuous component (c) and jump component (j)")
+pn.theme(figure_size=(8, 3), dpi=200, legend_position="right")
)

cとjは必ずしも同じような動きをしていないのが面白いです。

さて、ジャンプ部分jの値が一番大きい日は2024/7/11、次に大きい日は2024/4/29でした。

shape: (288, 8)
┌────────────┬─────┬──────────┬──────────┬───────────┬──────────┬──────────┬──────────┐
│ date ┆ n ┆ rv ┆ bv ┆ tq ┆ z ┆ j ┆ c │
│ --- ┆ --- ┆ --- ┆ --- ┆ --- ┆ --- ┆ --- ┆ --- │
│ date ┆ u32 ┆ f64 ┆ f64 ┆ f64 ┆ f64 ┆ f64 ┆ f64 │
╞════════════╪═════╪══════════╪══════════╪═══════════╪══════════╪══════════╪══════════╡
│ 2024-07-11 ┆ 288 ┆ 2.826537 ┆ 1.161507 ┆ 26.76854 ┆ 4.341744 ┆ 1.66503 ┆ 1.161507 │
│ 2024-04-29 ┆ 276 ┆ 5.346737 ┆ 3.789614 ┆ 85.518574 ┆ 3.002976 ┆ 1.557123 ┆ 3.789614 │
│ 2024-09-27 ┆ 288 ┆ 2.879915 ┆ 1.608273 ┆ 19.819779 ┆ 4.57689 ┆ 1.271642 ┆ 1.608273 │
│ … ┆ … ┆ … ┆ … ┆ … ┆ … ┆ … ┆ … │
│ 2024-12-03 ┆ 288 ┆ 0.588244 ┆ 0.561047 ┆ 0.635917 ┆ 0.724247 ┆ 0.0 ┆ 0.588244 │
│ 2024-12-05 ┆ 288 ┆ 0.471903 ┆ 0.458031 ┆ 0.306132 ┆ 0.537139 ┆ 0.0 ┆ 0.471903 │
│ 2024-12-06 ┆ 288 ┆ 0.486899 ┆ 0.455146 ┆ 0.425198 ┆ 1.023669 ┆ 0.0 ┆ 0.486899 │
└────────────┴─────┴──────────┴──────────┴───────────┴──────────┴──────────┴──────────┘

この2日は何があったのでしょうか？

2024/7/11のドル円チャートはこちらです。

2024/4/29はこちらです。

気付きましたか？この2日は為替介入が行われた日なんですね。為替介入であれば当然、ジャンプのような非連続な価格変動が起こります。

連続な過程ではなくジャンプ拡散過程でモデリングするのがより適切であること、そして一般にイレギュラーな要因で生まれるジャンプ部分のボラティリティを分離して把握することが大切なことが分かるよい例でした。

おわりに

RVの理論と実装を簡単に解説してみました。

金融市場の解析でも機械学習や深層学習の話題が多いですが、数理ファイナンスのトピックや論文も知っておくといろいろ使えることが多いと思います。

参考文献

Andersen, T. and Bollerslev, T. (1998). Answering the Skeptics: Yes, Standard Volatility Models do Provide Accurate Forecasts. International Economic Review, 39(4), 885-905.
Barndorff-Nielsen, O. E., and Shephard, N. (2004). Power and Bipower Variation with Stochastic Volatility and Jumps, Journal of Financial Econometrics, 2, 1-48.
Barndorff-Nielsen, O. E., and Shephard, N. (2006). Econometrics of Testing for Jumps in Financial Economics Using Bipower Variation, Journal of Financial Econometrics, 4, 1-30.
Hansen, P. R., and Lunde, A. (2005). Realized Variance and Market Microstructure Noise. Journal of Business & Economic Statistics, 24, 127-161.
Liu, L. Y., Patton, A. J., and Sheppard K. (2015). Does anything beat 5-minute RV? A comparison of realized measures across multiple asset classes. Journal of Econometrics, 187(1), 293-311.

価格が観測される時点が等間隔でなくても同じ議論が適用できます。 ↩︎
なお、株のように昼休みや夜間に休場する商品では、昼休みや夜間を挟む収益率も含んで普通にRVを計算すると、RVの精度が低くなり真のボラティリティに対する一致性を持たなくなります。このような市場でもRVが真のボラティリティの一致推定量になるように修正した計算方法があります (Hansen and Lunde (2005))。 ↩︎
ドリフトと拡散係数が時変の確率過程となっています。つまり、ドリフトと拡散係数が定数である幾何ブラウン運動よりも広い条件で成り立ちます。 ↩︎
確率微分方程式の計算ルールである「伊藤ルール」より計算できます。 ↩︎
5%や1%、0.1%などがよく用いられます。小さくするほどジャンプを厳しく判定することになります。 ↩︎
論文のタイトルからして（他の時間間隔やRV以外の他のボラティリティの推定量と比較して）“Does anything beat 5-minute RV?”という名前です。 ↩︎

ラグナロクオンラインの露店取引ログを返すAPIを作った

Fri, 02 Aug 2024 00:00:00 +0900

概要

ラグナロクオンライン（RO）という、2002年リリース（！）の老舗のMMORPGがあります。ドット絵のかわいさが特徴的なMMOです。

ROには露店システムというものがあります。プレイヤーはゲーム内でお店を開くことができ、自分が所有しているアイテムに自分で値段を設定して他のプレイヤーに売ることができます。

同じアイテムにはだいたいどのプレイヤーも似たような値段を付けるようになり、これが相場として形成されるわけですが、相場は時期によって大きく変動します。露店が並んでいる街を歩き回って掘り出し物を探すのも楽しいですし¹、今後もっと高くなると考え、アイテムを安い時期に買って高い時期に売ることで差益を狙うというのもROの一つの醍醐味です。

何のアイテムがいついくらで売れたという露店の取引履歴は公式のツールで提供されています。このツールは各アイテムについて最新1000件の取引履歴を表示します。露店に出すときは、だいたいこのツールの履歴と他の露店が付けている値段を見ながら適当な値段を設定します。

このデータ、データ分析屋としては貯めておいて長い時期で価格変動を見てみたくなります。というわけで、取引履歴を定期的にクローリングして貯めておき、GETすると過去の履歴を返すようなAPIを作りました。（自分用なので公開はしていません）

技術構成

構成図はこちらです。

VPS
- Pythonで定期的に公式ツールをクローリングし、JSONで保存してデータをCloud Storageにアップロード
  - 負荷をかけないようにするため、クローリングには十分なスリープを入れている
Google Cloud + Terraform
- Cloud StorageにアップロードされたらCloud Functionsを起動してBigQueryテーブルに書き込む
  - BigQueryに直接書き込まずにCloud Storageを前段に置いているのは、クローリングしたデータの形式が変わっていてBigQueryへの書き込みでエラーになる場合にデータが消失しないようにするため
- Cloud Functions（認証付きHTTPエンドポイント） + FastAPI（Python）でAPIエンドポイントを用意
  - GETでリクエストしたらBigQueryをクエリする

クローリングはVPS (cron), データ基盤はBigQuery + Terraformというオレオレ定番パターンです。以前に作ったニコニコ動画の再生数推移のデータ基盤と同じパターンです。

なお、公式ツールは常に最新の1000件のログを表示するため、前回のクローリングの取引ログと重複します²。こういう場合、重複を許して全件放り込むBigQueryテーブルに加え、重複を除いたユニークな取引ログを入れるBigQueryテーブルを用意して、前者にappendされるたびにスキャンして後者を全件洗い替えるのが定番です³。ですが、自分一人しか使わないアプリケーションのためにスキャンする方がかえってコストがかかるので、重複したままのBigQueryテーブルだけ作り、クエリするときにSQLで重複を取り除くようにしています。

使ってみる

月夜花カードというアイテムのレコードをAPIから取得してみます。

最初のレコードは、2024/7/18 18:16に1.3G Zeny（Zenyは通貨の名前。1G Zeny = 1000 M Zeny = 1000^2 K Zeny = 1000^3 Zeny）で1個取引が成立したというレコードです。

# 最新の3件の一部のkeyのみ抜粋
[
{
"datetime": "2024-07-18T18:16:00+09:00",
"world": "Noatun",
"item_id": "4131",
"item_name": "月夜花カード",
"price": 1300000000,
"count": 1
},
{
"datetime": "2024-07-10T19:38:00+09:00",
"world": "Noatun",
"item_id": "4131",
"item_name": "月夜花カード",
"price": 1000000000,
"count": 1
},
{
"datetime": "2024-06-29T15:43:00+09:00",
"world": "Noatun",
"item_id": "4131",
"item_name": "月夜花カード",
"price": 1000000000,
"count": 1
}
]

全部プロットしてみるとこんな感じです。価格変動が激しいですね。

APIで整形済みのデータが得られるのも分析的に楽ですね。作ったはいいものの、何に使えるかは分かりませんが…。

© Gravity Co., Ltd. & Lee MyoungJin(studio DTDS). All rights reserved.
© GungHo Online Entertainment, Inc. All Rights Reserved.
当コンテンツの再利用（再転載・配布など）は、禁止しています。

プロンテラの露店街はROの華ですね。 ↩︎
例えば前のクローリングから新たに100件のログが増えていた場合、900件分のレコードが二重にカウントされることになります。 ↩︎
例えば: BigQuery にデータを差分ロード（UPSERT）する方法まとめ ↩︎

読んだ: 「はじめての統計的因果推論」

Tue, 30 Jul 2024 00:00:00 +0900

「はじめての統計的因果推論」（著: 林岳彦）を読みました。

最近出版された統計的因果推論の本で評価が高かったので読んでみました。統計的因果推論に興味のある非データ分析者や初めて学ぶデータ分析者はもちろん、統計的因果推論を多少知っていて理解を整理したいデータ分析者にも非常によい本だと思いました。ほとんど数式を用いずに本質を説明していたのが印象的でした。なお、具体的な実装方法を説明している本ではありません。

いいなと思ったのは三点あります。

まず、因果効果を推定するとはどういうことなのか、じっくりと丁寧に論理を積み重ねて、これでもかというくらいかみ砕いて説明している点です。ここは書籍の第1部に該当します。

本で取り上げられている例を挙げます。いま、肥料を使用するとりんごの糖度が高くなるのかどうかを調べたいとします。肥料を使用したりんご（介入群）が数十個、使用していないりんご（対照群）が数十個あるとして、肥料を使用すると何度糖度が上がるか、このりんごからどうやって推定しましょうか？

介入群のりんごと対照群のりんごについて、それぞれ糖度を平均して引き算すればよいと思いつくかもしれません。ですがこの数値は因果効果とは限りません。というのは、例えば介入群にはもともと糖度が高い品種のりんごが、対照群のりんごにはもともと糖度が低い品種のりんごが多く含まれる場合、単なる平均の差では、このもともとの品種による糖度の違いを因果効果に加えてしまっているため、本来の因果効果よりも過大に効果を推定するからです（セレクションバイアス）。

品種に加え、天候などその他あらゆる要因の分布が介入群と対照群で等しいときに、肥料という処置による糖度への因果効果の推定値は、実際に観測された群間の糖度の平均の差となります。統計的因果推論の本質は、統計モデリングによって群間での要因の分布を揃える、あるいは揃えた状況を作り出すことです。実際にはすべての要因の分布を群間で揃える必要はなく、特定の要因（共変量）が揃っていれば因果効果を推定できます。何の要因を揃える必要があるのかを解き明かすために、因果ダイアグラムやバックドア基準を書籍中で説明しています。

RCTは、あらゆる要因の分布を群間で揃えられるので最も強力な手法です。因果ダイアグラムの観点から見ると、共変量を無作為割付（コイントス）という単一の変数に絞ることでバックドア基準を達成する方法であり、潜在結果モデルの観点から見ると、本来観測できない反事実下での期待値を無作為割付によって観測値で代替できるようにする方法です。

RCTが使えない場合に2群間で要因の分布を揃える方法として、層別化や重回帰分析、傾向スコアなどの各種手法を使用します。この書籍のおすすめポイントの二つ目は、第2部でこれらの各種手法の計算ロジックを暗算で計算できる簡単な例で説明していることです。各手法にはメリットとデメリットがありますし、適用するためにデータが満たす必要がある特徴もありますが（例えば、傾向スコア法では傾向スコアの分布が介入群と対照群で似ている必要があります（コモンサポート））、手計算レベルの例をなぞることで自然に理解できます。

最後に第3部で、統計的因果推論で推定される因果効果とは何か、科学哲学的な観点からしっかり説明している点もよかったです。

実験をよく設計しなければ、本来の処置の効果とは違う効果が因果効果の中に含まれてしまうことがあります（だから二重盲検法を使用するのですね）。また、特定の集団から取り出したサンプルで推定した因果効果を、その特定の集団を包含するより大きい集団の因果効果として扱っていいのかという問題もあります（外的妥当性）。

これらは統計的因果推論の本では、特に実装系の本では触れられないこともありますが、統計的因果推論を実社会に適用する上でデータ分析者が考慮しなければならない非常に重要なポイントです。章を複数割いて説明しているところに著者の心意気を感じました。

具体的な実装方法や理論を学びたい場合は例えば次の書籍に進むとよいのではないでしょうか。最初の二つの書籍は特に定番ですね。

読んだ: 「やりたいことが今すぐわかる逆引きGit入門」

Mon, 01 Jul 2024 00:00:00 +0900

「やりたいことが今すぐわかる逆引きGit入門」（著: 高見龍、訳: 鶴本彰子）を読みました。

数年前に一度読み、先日再び一部読み直しました。特に有名な本ではない気がしますが、Gitの入門書として良書だと思ったので感想を書きます。ちなみにわたしがGitを困らずに使えるようになったのはこの本のおかげです。

Gitの操作を一つずつ仕組みを踏まえて解説していく本
コマンドラインに加え、GUIとしてSourcetreeの二つ扱っている
著者は台湾の人っぽい
- https://github.com/kaochenlong
語りかけているような講義調の文体。著者の文章と訳者の訳が上手なのか頭にすっと入ってきた
逆引きGit入門というタイトルだが、辞書感はあまりない（タイトルでちょっと損している気が…）
- こういうときどうするかという事例集でありつつも、ハンズオン形式でGitの概念とコマンドを順を追って説明しているからかな？
Gitのガベージコレクションや.gitディレクトリの中身などのちょっと進んだ解説が面白かった
- ある程度Gitを使えるようになってからもう一度読むとさらに勉強になる！
こういう人に合っていると思う（かつての自分）
- Gitは何となく使えるけどググってばかり
- Gitってなんか怖い
- Gitの概念や仕組みからしっかり理解したい
- コマンドを使えるようになりたい

印象に残っている部分

二つ紹介します。

git addでステージングエリアに載せてからgit commitでコミットと、なぜ2回操作が必要なのか？という質問で、以下のように例えていたのが面白かったです。（4.3章）（以下の文章は本の抜粋ではなく、該当の文章をわたしが意訳したものです）

倉庫を一つ所有していて、倉庫の前にはちょっとした荷物置き場のスペースがあるとする。トラックで届く荷物を待っているとする。届いた荷物は一旦倉庫の前の空きスペース（ステージングエリア）に置いておく（git add）。ある程度届いたら倉庫（リポジトリ）に移す（git commit）。荷物が届くたびに毎回倉庫に移してもいいけど、そうすると倉庫に移した記録（コミットログ）が細々して後で見返すと分からなくなりがち。きりのいい単位で荷物をまとめて倉庫に移して記録を付けると分かりやすいよね。

もう一つ、ブランチを切り替え忘れてコミットしてしまったときの対処法です。（11.1章）

こういうコミットログを考えます。

コミットIDがc004とc005のコミットはdevelopブランチに積むつもりがmainブランチにすでに積んでしまった！今のmainとdevelopを入れ替えたいというケースです。時々やるやつですね。

git log --oneline
c005 (HEAD, main) foo
c004 piyo
c003 (develop) fuga
c002 hoge
c001 first commit

どうやって入れ替えましょうか？この本では以下の二つの方法が紹介されています。

まずはdevelopを元々置きたかったc005（今のHEAD）に持ってきてから、mainブランチをc003まで持ってくる方法です。

# git branch <branch-name> <commit-ID>でbranch-nameをcommit-IDに作る
# branch-nameが既に存在するときは-fオプションを使う
git branch -f develop c005
# この段階ではmainブランチをcheckoutしている
# 以下の2行の代わりにgit reset --hard c003でもいい
git switch develop
git branch -f main c003

もう一つ、mainとdevelopの名前を入れ替える方法もあります。

# ブランチの名前を変える時に、そのブランチがHEADにいると名前を変えられないので
# c005にHEADを置く（detached HEAD）
# git checkout c005でもよい
git switch c005 --detach
git branch -m develop tmp
git branch -m main develop
git branch -m tmp main
# detached HEADを解消する
git switch main

変数xとyを入れ替えるときに、yをtmpに、xをyにして最後にtmpをxに変える方法がありますが、これと同じことですね。鮮やかな解法ですね。

本の中で繰り返し述べられていますが、ブランチというのはコミットログのツリーの枝（例えばVSCodeの拡張機能であるGit Graphの線）全体を指すものではなく¹、特定のコミットに貼り付けた付箋のようなものです。

最初の解法ではgit branch <branch-name> <commit-ID>によって、付箋を剥がしては別のコミットに貼るイメージ、次の解法ではgit branch -mによって付箋を貼り変えるイメージです。

ブランチはツリーではなくコミットを指す付箋だという教えを実感できる解法が本の最後に出てきて、読んでいて感動しました。

なお、本では触れられていませんが、developブランチにcherry-pickする方法もあります。

git switch develop
git cherry-pick c004 c005
git switch main
git reset --hard c003

じゃあよく見るコミットログのツリーの枝は何なのかですが、各コミットにはその親のコミット（≒一個前のコミット）のコミットIDが記録されています。それをつなげたのがよく見るツリーの枝です。 ↩︎

部屋の階数は家賃にどれだけ影響を与えるのか？

Fri, 24 May 2024 00:00:00 +0900

はじめに

昨年の確率的プログラミング言語アドベントカレンダーに出した記事（階層ベイズで東京23区のお部屋の家賃相場を推定する - suzuna’s memo）の続きです。（本記事を読む上では、この記事は読まなくて大丈夫です）

前の記事では、まず賃貸物件の情報サイトであるSUUMOをスクレイピングすることで、約20万件の東京23区の賃貸物件の家賃データを収集しました。そのデータを用いて、東京23区の家賃相場を推定する階層ベイズモデルをR + RStanで実装しました。なお、ここでいう家賃とは、毎月発生する家賃と管理費の合計を指します（以下、単に家賃と記載します）。

このモデルの説明変数には最寄り駅、部屋の面積、築年数、駅からの徒歩分数を使用しました。そのため、部屋がある階数の情報を考慮できていませんでした。同じマンションでも部屋の階数が高いほど家賃は高くなります。1階や地下1階の部屋の家賃は安く設定されていることが多いですし、2階と10階では家賃にそれなりの開きがあります。また、最寄り駅によって、高層マンションの物件が多い駅と低層マンションの物件が多い駅があるため、階を考慮しなければ、前者の駅ほど割高に推定することになります。

そこでこの記事では、先の東京23区の家賃相場のモデルの説明変数に部屋の階数を追加しました。これにより、階数が1階上がるごとに家賃がどの程度高くなるのかや、1階や地下階だとどの程度安くなるのかを解き明かしてみようと思います。また、築年数1年や、駅からの徒歩分数1分ごとに家賃がどの程度変化するかも合わせて示します。

さらに、最寄り駅以外の全ての条件（説明変数）を揃えたとき、最寄り駅によってどの程度家賃相場が変わるかを見てみようと思います。

結論

築年数が1年増えるごとに家賃は1%下がる
駅から徒歩1分増えるごとに家賃は0.7%下がる
物件の階数が2階から1階上がるごとに家賃は1.2%上がる
最上階かどうかは家賃に影響がない
1階は2階と比べて家賃は3.6%、地下1階は2階と比べて家賃は6.6%下がる
任意の最寄り駅、面積、築年数、駅からの徒歩分数、階数における物件の家賃相場を示すことができた
- 例: 最寄り駅が表参道の25m2、築5年、駅から徒歩5分、3階のマンションの家賃相場は15.9万円

環境

R 4.3.1
rstan 2.32.3
bayesplot 1.10.0
tidybayes 3.0.6

使うデータ

2023年11月にSUUMOからスクレイピングした東京23区の賃貸マンションの賃貸データを用います。

用いたのは、東京23区の賃貸物件のうち、以下に該当する物件です。124354件の物件です。

SUUMOのカテゴリが「賃貸マンション」の物件（アパートや一戸建てを除く）¹
面積が15m2～100m2の物件²
マンションの高さが、地下階はないか地下1階まで、かつ地上階は15階以下の物件³
築年数が40年以下の物件
駅から徒歩（＝車やバスではない）かつ駅からの徒歩分数が20分以内の物件
家賃+管理費が100万円以下の物件
階数の情報がページに存在し、かつ建物の地下階の階数<=物件の階数<=地上階の階数である物件
- SUUMOの誤記入なのか、3階建てのマンションなのに部屋が4階と書かれているようなことがまれにあるが、そういうものを除くということ

25m2の物件と150m2の物件だったり、駅から徒歩10分の物件と駅からバスで20分、バス停から徒歩5分の物件を同じ線形モデルで説明することは無理があります。150m2の物件やバスで20分に徒歩5分の物件は、数としては多くないので、使用しないことにしたということです。

前処理の内容や可視化については前の記事で詳細に触れていますので興味があれば見てみてください。

モデル

家賃相場は、物件の最寄り駅、面積、築年数、駅からの徒歩分数、部屋の階数で決まると考えます。ここでいう家賃相場とは、これらの条件（＝説明変数）なら平均的にはこのくらいの家賃になるという水準です（そのため、実際に観測される家賃は、この家賃相場の上下に分布します）。

具体的には、以下のモデルで定式化します。

物件$i(1, \dots, N)$の最寄り駅（SUUMOの物件ページで一番上に書いてある1番目の最寄り駅）を$sta[i] (1, \dots, S)$とします。このとき、物件の対数家賃の相場は$\mu_{i}$万円であると考えます。

$$ \begin{align*} \log{y_{i}} & \sim N(\mu_{i}, \sigma) \\\ \mu_{i} &= a_{sta[i]} + b_{sta[i]} \log{\mathrm{area}_{i}} \\\ &+ \beta_{\mathrm{age}} \mathrm{age}_{i} + \beta_{\mathrm{walk}}(\mathrm{walk}_{i} - 1) \\\ &+ \beta_{\mathrm{floor}} \max {(\mathrm{floor}_{i} - 2, 0)} \\\ &+ \beta_{\mathrm{isTop}} \mathrm{isTop}_{i} \\\ &+ \beta_{\mathrm{isGround}} \mathrm{isGround}_{i} \\\ &+ \beta_{\mathrm{isUnderground}} \mathrm{isUnderground}_{i} \\\ a_{sta[i]} & \sim N(a_{all}, \sigma_{a_{all}}) \\\ b_{sta[i]} & \sim N(b_{all}, \sigma_{b_{all}}) \\\ \end{align*} $$

ただし、物件$i$について、それぞれ以下の通りとします。

$y_{i}$: 家賃+管理費（万円）
$\mathrm{area}_{i} (15 \leq \mathrm{area}_{i} \leq 100)$: 面積（m2）
$\mathrm{age}_{i} (= 0, 1, \dots, 40)$: 築年数。新築は0年とする
$\mathrm{walk}_{i} (= 1, 2, \dots, 20)$: 最寄り駅からの徒歩分数
$\mathrm{floor}_{i} (= -1, 1, 2, \dots, 15)$: 物件の階数
$\mathrm{isTop}_{i} (= 0, 1)$: その部屋が最上階なら1, そうではないなら0
$\mathrm{isGround}_{i} (= 0, 1)$: その部屋が1階なら1, そうではないなら0
$\mathrm{isUnderground}_{i} (= 0, 1)$: その部屋が地下1階なら1, そうではないなら0

面積の対数と家賃の対数は線形の関係で、その切片と傾きは最寄り駅によって違うというモデルです。要するに最寄り駅によって家賃水準が変わってくるということです。同じ面積の部屋でも家賃の高い駅と安い駅がありますし、面積を大きくしたときに家賃の上がり幅が大きい駅と小さい駅があります。これを階層ベイズで表現します⁴。

築年数が1年増えたり、最寄り駅から徒歩1分増えたり、部屋の階数が1階上がったりするごとに家賃が一定割合増減するという仮定を置きます。部屋が最上階なら追加で一定割合家賃が上がり、反対に1階や地下1階なら2階と比べて一定割合家賃が下がるとします（家探しをしたことがあれば何となく分かると思いますが、2階以上では階が上がるごとに一定割合家賃が上がっていく一方で、1階と地下1階はそれより大きい割合で家賃が安くなると思われるため、1階と地下1階は別のパラメータに分けました。ドメイン知識ですね）。これらの割合は、最寄り駅によらず一定とします。

なお、SUUMOでは物件ごとに最寄り駅が最大3つ書かれていますが、このモデルでは最初に書かれている1番目の最寄り駅のみを使用しています。他の最寄り駅も考慮するとより精緻になりそうですが、これでも駅ごとの家賃の大まかな傾向はとらえられると思われます。

Stanの実装

このモデルをStanのコードで書きます。事前分布は無情報事前分布です。

data {
int N; // 物件の数
vector[N] Y; // 家賃+管理費
vector[N] AREA; // 面積
int S; // 最寄り駅の数
int<lower=1, upper=S> STATION[N]; // 物件nの最寄り駅index
vector[N] AGE; // 物件nの築年数
vector[N] WALK; // 物件nの徒歩分数
vector[N] FLOOR; // 物件nの階数（ただし、1階や地下1階の場合は0）
vector[N] IS_TOP;
vector[N] IS_GROUND;
vector[N] IS_UNDERGROUND;
}
parameters {
real a0; // 面積の切片の全体平均
real b0; // 面積の傾きの全体平均
vector[S] a;
vector[S] b;
real<upper=0> age_b;
real<upper=0> walk_b;
real<lower=0> floor_b;
real<lower=0> floor_b_is_top;
real<upper=0> floor_b_is_ground;
real<upper=0> floor_b_is_underground;
real<lower=0> sigma_a;
real<lower=0> sigma_b;
real<lower=0> sigma;
}
model {
a ~ normal(a0, sigma_a);
b ~ normal(b0, sigma_b);
log(Y) ~ normal(
a[STATION] + b[STATION] .* log(AREA) +
age_b * AGE +
walk_b * (WALK - 1)+
floor_b * (FLOOR - 2)+
floor_b_is_top * IS_TOP +
floor_b_is_ground * IS_GROUND +
floor_b_is_underground * IS_UNDERGROUND,
sigma
);
}

このStanコードをmodel.stanというファイル名で保存し、以下のコードでRStanでキックします。chains=4, iter=5000, warmup=1000で約20時間かかりました。

library(tidyverse)
library(rstan)
library(bayesplot)
library(tidybayes)
library(patchwork)

# 上はMCMCの並列化、下はstanコードが変わらない限り再コンパイルしない
options(mc.cores=parallel::detectCores())
rstan::rstan_options(auto_write=TRUE)
# Stanコードのコンパイル
mod <- rstan::stan_model("model.stan")
# MCMCの実行
# dataはstanコードのdataブロックのN, Y, ...をlist(N=hoge, Y=fuga, ...)のように持つ
fit <- rstan::sampling(
mod,
data=data,
chains=4, iter=5000, warmup=1000, thin=1, refresh=10, seed=1234
)

MCMCが収束していることをトレースプロットやRhatなどでチェックしましたが、結果は割愛します。（具体的な実装は前回の記事をご参照ください）

結果

Stanのパラメータ推定結果です。（一部のパラメータのみ抜粋）

Code

print(
fit,
pars=c(
"a0", "b0", "age_b", "walk_b",
"floor_b", "floor_b_is_top", "floor_b_is_ground", "floor_b_is_underground",
"sigma_a", "sigma_b", "sigma"
),
digits_summary=3
)

#> Inference for Stan model: anon_model.
#> 4 chains, each with iter=5000; warmup=1000; thin=1;
#> post-warmup draws per chain=4000, total post-warmup draws=16000.
#>
#> mean se_mean sd 2.5% 25% 50% 75% 97.5%
#> a0 -0.116 0 0.011 -0.139 -0.124 -0.116 -0.108 -0.094
#> b0 0.803 0 0.005 0.793 0.799 0.803 0.806 0.812
#> age_b -0.011 0 0.000 -0.011 -0.011 -0.011 -0.011 -0.010
#> walk_b -0.007 0 0.000 -0.007 -0.007 -0.007 -0.007 -0.007
#> floor_b 0.012 0 0.000 0.012 0.012 0.012 0.012 0.012
#> floor_b_is_top 0.000 0 0.000 0.000 0.000 0.000 0.000 0.000
#> floor_b_is_ground -0.036 0 0.001 -0.038 -0.037 -0.036 -0.036 -0.034
#> floor_b_is_underground -0.068 0 0.006 -0.080 -0.072 -0.068 -0.064 -0.056
#> sigma_a 0.219 0 0.009 0.203 0.213 0.219 0.225 0.237
#> sigma_b 0.099 0 0.004 0.092 0.097 0.099 0.101 0.106
#> sigma 0.110 0 0.000 0.110 0.110 0.110 0.111 0.111
#> n_eff Rhat
#> a0 23848 1
#> b0 24227 1
#> age_b 16923 1
#> walk_b 33368 1
#> floor_b 33061 1
#> floor_b_is_top 23531 1
#> floor_b_is_ground 35017 1
#> floor_b_is_underground 34735 1
#> sigma_a 16979 1
#> sigma_b 25626 1
#> sigma 16128 1
#>
#> Samples were drawn using NUTS(diag_e) at Thu Apr 4 16:17:37 2024.
#> For each parameter, n_eff is a crude measure of effective sample size,
#> and Rhat is the potential scale reduction factor on split chains (at
#> convergence, Rhat=1).

築年数効果

以下、点推定値としてmedianを採用します。$\beta_{\mathrm{age}}$ = -0.011でした。これは、築年数が1年増えるごとに、家賃の対数が0.011小さくなることを意味します。

築年数1年につき家賃の対数が0.011小さくなると言われてもよく分からないので、家賃が何%小さくなるのかが知りたいですね。これは、$\mathrm{age}_{i} = 0, \dots, 40$としたときの$\exp (\beta_{\mathrm{age}} \mathrm{age}_{i})$の事後中央値と95%ベイズ信用区間を求めればよいです。

medianは事後分布の中央値、upperとlowerは95%ベイズ信用区間の上限と下限です。

Code

age_b <- tidy_draws |>
pull(age_b)
res_age <- 0:40 |>
map_dfr(\(age) {
samples <- exp(age_b * age)
tibble::tibble(
age=age,
median=quantile(samples, 0.5),
lower=quantile(samples, 0.025),
upper=quantile(samples, 0.975)
)
})
# きりのいいageだけ表示する
res_age |>
filter(age %in% c(0:5, seq(5, 40, 5))) |>
print(n=15)

#> # A tibble: 13 × 4
#> age median lower upper
#> <int> <dbl> <dbl> <dbl>
#> 1 0 1 1 1
#> 2 1 0.990 0.989 0.990
#> 3 2 0.979 0.979 0.979
#> 4 3 0.969 0.969 0.969
#> 5 4 0.959 0.959 0.959
#> 6 5 0.949 0.948 0.949
#> 7 10 0.900 0.900 0.901
#> 8 15 0.854 0.853 0.855
#> 9 20 0.810 0.809 0.811
#> 10 25 0.769 0.768 0.770
#> 11 30 0.729 0.728 0.730
#> 12 35 0.692 0.691 0.693
#> 13 40 0.656 0.655 0.658

medianの列のとおり、築年数が1年増えるごとに家賃は1%下がります。覚えやすいですね。

例えば築20年の物件は、新築の物件と比較して19%（≒1-0.99^20）下がります。

徒歩分数効果

Code

walk_b <- fit |>
tidybayes::spread_draws(walk_b) |>
pull(walk_b)
res_walk <- 1:20 |>
map_dfr(\(walk) {
samples <- exp(walk_b * (walk - 1))
tibble::tibble(
walk=walk,
median=quantile(samples, 0.5),
lower=quantile(samples, 0.025),
upper=quantile(samples, 0.975)
)
})
res_walk |>
filter(walk %in% c(1, 2, 3, 5, 10, 15, 20)) |>
print()

#> # A tibble: 7 × 4
#> walk median lower upper
#> <int> <dbl> <dbl> <dbl>
#> 1 1 1 1 1
#> 2 2 0.993 0.993 0.993
#> 3 3 0.986 0.986 0.986
#> 4 5 0.972 0.972 0.973
#> 5 10 0.939 0.937 0.941
#> 6 15 0.907 0.904 0.909
#> 7 20 0.876 0.872 0.879

同様に、駅から徒歩1分増えるごとに家賃は0.7%下がります。例えば駅から徒歩10分の物件は徒歩1分の物件と比べて6.1%（≒1-0.993^9）下がります。駅から遠くても家賃はあまり下がりませんね。

徒歩分数1分あたりの家賃の変化量は全ての駅で一定としていますが、地上駅やターミナル駅では駅に近すぎると電車や駅周辺の騒音の影響で家賃が下がりそうな気もします。

階数効果

Code

options(pillar.sigfig=4)
floor_b <- fit |>
tidybayes::spread_draws(floor_b) |>
pull(floor_b)
res_floor <- 2:15 |>
map_dfr(\(floors) {
samples <- exp(floor_b * max(floors - 2, 0))
tibble::tibble(
floor=floors,
median=quantile(samples, 0.5),
lower=quantile(samples, 0.025),
upper=quantile(samples, 0.975)
)
})
res_floor |>
print(digits=5)

#> # A tibble: 14 × 4
#> floor median lower upper
#> <int> <dbl> <dbl> <dbl>
#> 1 2 1 1 1
#> 2 3 1.012 1.012 1.012
#> 3 4 1.024 1.023 1.024
#> 4 5 1.036 1.035 1.037
#> 5 6 1.048 1.047 1.049
#> 6 7 1.061 1.059 1.062
#> 7 8 1.073 1.072 1.075
#> 8 9 1.086 1.084 1.088
#> 9 10 1.099 1.097 1.101
#> 10 11 1.112 1.109 1.115
#> 11 12 1.125 1.122 1.128
#> 12 13 1.139 1.135 1.142
#> 13 14 1.152 1.148 1.156
#> 14 15 1.166 1.162 1.170

物件の階数が2階から上に1階上がるごとに家賃が1.2%上がることが分かりました。

最上階効果、1階効果、地下1階効果

Code

fit |>
tidybayes::spread_draws(
floor_b_is_top, floor_b_is_ground, floor_b_is_underground
) |>
mutate(
exp_is_top=exp(floor_b_is_top),
exp_is_ground=exp(floor_b_is_ground),
exp_is_underground=exp(floor_b_is_underground)
) |>
tidybayes::median_qi(
exp_is_top, exp_is_ground, exp_is_underground, .width=0.95
)

#> exp_is_top exp_is_top.lower exp_is_top.upper exp_is_ground
#> 1 1.000026 1.000001 1.000139 0.9644208
#> exp_is_ground.lower exp_is_ground.upper exp_is_underground
#> 1 0.9625942 0.9662279 0.9338659
#> exp_is_underground.lower exp_is_underground.upper .width .point .interval
#> 1 0.9228108 0.945169 0.95 median qi

以下のことが分かります。

最上階であることは、家賃を全く押し上げない。（exp_is_top）
1階の物件は、2階の物件と比べて家賃が3.6%下がる。（exp_is_ground）
地下1階の物件は、2階の物件と比べて家賃が6.6%下がる⁵。（exp_is_underground）

階数効果と合わせて考えると、例えば地上4階地下1階建てのマンションで2階が家賃10万円なら、3階は10.12万円、4階は10.24万円、1階は9.64万円、地下1階は9.34万円くらいになるということです。だいぶ妥当な感じの結果ですね。

2階から3階は1.2%上がる一方、2階から1階は3.6%、2階から地下1階は6.6%下がることから、やはり1階や地下1階の物件の家賃はディスカウントされているということが分かりました。

最上階だからといって、階数効果（1階につき1.2%）以上に追加で家賃を押し上げることはないというのがちょっと意外でした。ですが、新築のマンションの各部屋の家賃（新築は完成時に全階の物件が一斉に募集がかかる）を見たことがあるのですが、確かに最上階だからといって家賃が高くなることはないような気もしました。

最寄り駅効果

最寄り駅以外の条件を固定して、最寄り駅ごとに家賃相場がどの程度異なるかを見ることができます。25m2、築5年、駅から徒歩5分、3階の賃貸マンションという条件で、最寄り駅だけ変えてみましょう⁶。ちなみに25m2というのは一人暮らし用の物件でよくみられる面積です。

まずは京王線沿いの各駅です。

Code

# 駅名とモデルに投入したindexのマッピング
sta_chr_idx_table <- df_mod |>
select(moyorieki_1_station, moyorieki_1_station_index) |>
distinct(moyorieki_1_station, .keep_all=TRUE)
# 駅名があればそのindex, なければNA_integer_を返す
station_to_idx <- function(station_name) {
chr <- sta_chr_idx_table$moyorieki_1_station
idx <- sta_chr_idx_table$moyorieki_1_station_index
if (length(idx[which(chr==station_name)]) == 0) {
return(NA_integer_)
} else {
return(idx[which(chr==station_name)])
}
}
tidy_draws_by_idx <- tidybayes::spread_draws(fit, a[idx], b[idx], age_b, walk_b, floor_b, floor_b_is_top, floor_b_is_ground, floor_b_is_underground, sigma_a, sigma_b)
stations <- c(
"新宿駅", "初台駅", "幡ヶ谷駅", "笹塚駅", "代田橋駅", "明大前駅", "下高井戸駅", "桜上水駅", "上北沢駅", "八幡山駅", "芦花公園駅", "千歳烏山駅"
)
# factor型で駅の路線順に並べる
stations_fct <- forcats::fct_relevel(as.factor(stations), stations)
# 見る駅名のindex（stanのa[s]やb[s]のs）
idxs <- map_int(stations, station_to_idx)
area <- 25
age <- 5
walk <- 5
floor <- 3
is_top <- 0
p1 <- tidy_draws_by_idx |>
filter(idx %in% idxs) |>
# 駅のindexではなく駅名をプロットに付けるためにindexと駅名のテーブルをjoinする
left_join(
df_mod |>
filter(moyorieki_1_station %in% stations) |>
distinct(moyorieki_1_station, .keep_all=TRUE) |>
select(moyorieki_1_station, moyorieki_1_station_index) |>
rename(station=moyorieki_1_station, idx=moyorieki_1_station_index) |>
mutate(station=forcats::fct_relevel(station, stations)),
by="idx"
) |>
mutate(
mu_exp=exp(
a+b*log(area)+age_b*age+walk_b*(walk-1)+
floor_b*max(floor-2, 0)+
floor_b_is_top*is_top+
floor_b_is_ground*as.integer(floor == 1L)+
floor_b_is_underground*as.integer(floor == -1L)
)
) |>
ggplot(aes(mu_exp, station))+
theme_light()+
tidybayes::stat_pointinterval(point_interval=tidybayes::median_qi, .width=0.95)+
scale_x_continuous(breaks=0:20)+
theme(axis.title.y=element_blank())+
labs(
title="exp(mu_i) (25m2, 築5年, 徒歩5分, 3階)",
subtitle="point: estimated (median), bar: 95% bayesian CI",
x="exp(mu_i) (万円)",
y="station"
)
p2 <- df_mod |>
filter(moyorieki_1_station %in% stations) |>
count(moyorieki_1_station, moyorieki_1_station_index, name="n") |>
rename(station=moyorieki_1_station, idx=moyorieki_1_station_index) |>
mutate(station=forcats::fct_relevel(station, stations)) |>
arrange(station) |>
ggplot(aes(station, n))+
theme_light()+
geom_bar(stat="identity", color="black", fill="gray", alpha=0.6)+
scale_y_continuous(breaks=seq(0, 2000, 500), minor_breaks=seq(0, 2000, 100))+
geom_text(aes(label=n, y=100))+
theme(axis.title.y=element_blank())+
coord_flip()+
labs(
title="（参考）物件数"
)
patchwork::wrap_plots(p1, p2, ncol=2, widths=c(3, 2))

左のプロットは最寄り駅と上の条件での家賃相場（万円）です。真ん中の点が推定値、左右の棒は95%ベイズ信用区間です。右のプロットはSUUMOにその最寄り駅の物件が何件あったかを示します。例えば、25m2、築5年、駅から徒歩5分、3階のマンションの家賃相場は、最寄り駅が新宿だと14.3万円、初台だと12.1万円ということを示します。ちなみに、例えば築10年だとこの結果に0.95（≒1-0.99^(10-5)）をかけたものになります。

明大前が下高井戸と代田橋より少し高く、また千歳烏山が芦花公園より少し高いことが面白いですね。明大前と千歳烏山は特急～各駅の全ての列車が止まること、明大前は京王井の頭線（渋谷～吉祥寺）も通ることが理由でしょうか。桜上水は新宿まで10分と近く、特急以外が止まります。閑静で住みやすい街ですが比較的お手頃な家賃で、住むにはよさそうですね。

次に同じ条件で小田急線沿いを見てみます。京王線と同じく新宿が始発で、京王線の南側を走る路線です。

Code

stations <- c(
"新宿駅", "南新宿駅", "参宮橋駅", "代々木八幡駅", "代々木上原駅", "東北沢駅", "下北沢駅", "世田谷代田駅", "梅ヶ丘駅", "豪徳寺駅", "経堂駅", "千歳船橋駅", "祖師ヶ谷大蔵駅", "成城学園前駅"
)
# factor型で駅の路線順に並べる
stations_fct <- forcats::fct_relevel(as.factor(stations), stations)
# 見る駅名のindex（stanのa[s]やb[s]のs）
idxs <- map_int(stations, station_to_idx)
area <- 25
age <- 5
walk <- 5
floor <- 3
is_top <- 0
p1 <- tidy_draws_by_idx |>
filter(idx %in% idxs) |>
# 駅のindexではなく駅名をプロットに付けるためにindexと駅名のテーブルをjoinする
left_join(
df_mod |>
filter(moyorieki_1_station %in% stations) |>
distinct(moyorieki_1_station, .keep_all=TRUE) |>
select(moyorieki_1_station, moyorieki_1_station_index) |>
rename(station=moyorieki_1_station, idx=moyorieki_1_station_index) |>
mutate(station=forcats::fct_relevel(station, stations)),
by="idx"
) |>
mutate(
mu_exp=exp(
a+b*log(area)+age_b*age+walk_b*(walk-1)+
floor_b*max(floor-2, 0)+
floor_b_is_top*is_top+
floor_b_is_ground*as.integer(floor == 1L)+
floor_b_is_underground*as.integer(floor == -1L)
)
) |>
ggplot(aes(mu_exp, station))+
theme_light()+
tidybayes::stat_pointinterval(point_interval=tidybayes::median_qi, .width=0.95)+
scale_x_continuous(breaks=0:20)+
theme(axis.title.y=element_blank())+
labs(
title="exp(mu_i) (25m2, 築5年, 徒歩5分, 3階)",
subtitle="point: estimated (median), bar: 95% bayesian CI",
x="exp(mu_i) (万円)",
y="station"
)
p2 <- df_mod |>
filter(moyorieki_1_station %in% stations) |>
count(moyorieki_1_station, moyorieki_1_station_index, name="n") |>
rename(station=moyorieki_1_station, idx=moyorieki_1_station_index) |>
mutate(station=forcats::fct_relevel(station, stations)) |>
arrange(station) |>
ggplot(aes(station, n))+
theme_light()+
geom_bar(stat="identity", color="black", fill="gray", alpha=0.6)+
scale_y_continuous(breaks=seq(0, 2000, 500), minor_breaks=seq(0, 2000, 100))+
geom_text(aes(label=n, y=100))+
theme(axis.title.y=element_blank())+
coord_flip()+
labs(
title="（参考）物件数"
)
patchwork::wrap_plots(p1, p2, ncol=2, widths=c(3, 2))

代々木上原まで、下北沢まで、成城学園前までで分かれていますね。経堂～梅ヶ丘も桜上水と同じく新宿から10分強ですし、静かな住みやすい街でよいのではないでしょうか。経堂は快速急行以外が止まるので便利ですね。

最後に東京メトロの千代田線沿い（代々木上原～赤坂）を見てみます。国会議事堂前～大手町は物件がほとんどないので省略します。

Code

stations <- c(
"代々木上原駅", "代々木公園駅", "明治神宮前駅", "表参道駅", "乃木坂駅", "赤坂駅"
)
# factor型で駅の路線順に並べる
stations_fct <- forcats::fct_relevel(as.factor(stations), stations)
# 見る駅名のindex（stanのa[s]やb[s]のs）
idxs <- map_int(stations, station_to_idx)
area <- 25
age <- 5
walk <- 5
floor <- 3
is_top <- 0
p1 <- tidy_draws_by_idx |>
filter(idx %in% idxs) |>
# 駅のindexではなく駅名をプロットに付けるためにindexと駅名のテーブルをjoinする
left_join(
df_mod |>
filter(moyorieki_1_station %in% stations) |>
distinct(moyorieki_1_station, .keep_all=TRUE) |>
select(moyorieki_1_station, moyorieki_1_station_index) |>
rename(station=moyorieki_1_station, idx=moyorieki_1_station_index) |>
mutate(station=forcats::fct_relevel(station, stations)),
by="idx"
) |>
mutate(
mu_exp=exp(
a+b*log(area)+age_b*age+walk_b*(walk-1)+
floor_b*max(floor-2, 0)+
floor_b_is_top*is_top+
floor_b_is_ground*as.integer(floor == 1L)+
floor_b_is_underground*as.integer(floor == -1L)
)
) |>
ggplot(aes(mu_exp, station))+
theme_light()+
tidybayes::stat_pointinterval(point_interval=tidybayes::median_qi, .width=0.95)+
scale_x_continuous(breaks=0:20)+
theme(axis.title.y=element_blank())+
labs(
title="exp(mu_i) (25m2, 築5年, 徒歩5分, 3階)",
subtitle="point: estimated (median), bar: 95% bayesian CI",
x="exp(mu_i) (万円)",
y="station"
)
p2 <- df_mod |>
filter(moyorieki_1_station %in% stations) |>
count(moyorieki_1_station, moyorieki_1_station_index, name="n") |>
rename(station=moyorieki_1_station, idx=moyorieki_1_station_index) |>
mutate(station=forcats::fct_relevel(station, stations)) |>
arrange(station) |>
ggplot(aes(station, n))+
theme_light()+
geom_bar(stat="identity", color="black", fill="gray", alpha=0.6)+
scale_y_continuous(breaks=seq(0, 2000, 500), minor_breaks=seq(0, 2000, 100))+
geom_text(aes(label=n, y=100))+
theme(axis.title.y=element_blank())+
coord_flip()+
labs(
title="（参考）物件数"
)
patchwork::wrap_plots(p1, p2, ncol=2, widths=c(3, 2))

赤坂は15.1万円、表参道は15.9万円、明治神宮前は16.8万円！高いですね…。他の駅なら同じ金額で二人暮らし用の物件が借りられますね。この辺りはどこも高く、例えば東京メトロ銀座線の外苑前は15.9万円、東急東横線の代官山は15.2万円です。

おわりに

部屋の階数や最寄り駅などによってどの程度家賃相場が変わるのかを定量的に示すことができ、役に立ちそうな結果が得られました。

ツリー系の機械学習モデルの方が家賃の予測精度は高そうですが、1階は2階と比べて3.6%安いとか、初台～笹塚はほとんど家賃が変わらないといった解釈に使える知見を得るという点では統計モデリングが強いですね。ベイズモデリングなので、築年数効果のような各パラメータや家賃相場の幅をベイズ信用区間という形で知ることができるのもいい点です。

家賃はまさに階層ベイズ向きのテーマで面白いですね。今後もモデルをブラッシュアップしていきたいです。

アパートは木造が多くマンションは鉄筋コンクリートが多いですが、木造と鉄筋コンクリートでは耐用年数が異なるため築年数が経過することによる家賃の押し下げ効果が異なると思われます。またアパートは高くても3階程度までですがマンションはより高く建てられることから、部屋の階数による家賃への影響もアパートとマンションで異なりそうです。そのため、この記事では賃貸マンションのみに絞りました。 ↩︎
前の記事では10m2～100m2としていましたが、10m2近辺の物件でモデルの当てはまりが悪いことが分かっています。つまり10m2近辺では面積と家賃の間の関係性が崩れていると思われます。本記事では15m2以上に引き上げました。 ↩︎
地上階の高さが高すぎるマンションや地下階が深すぎるマンションは東京23区の賃貸物件ではわずかなため、階数が家賃に与える効果をロバストに推定する観点からこの条件を加えました。なお、15階以下としているのは、16階以上のマンションはごくわずかであるためです（前回の記事をご参照）。 ↩︎
この階層ベイズモデルでは、各最寄り駅における切片と傾きは東京23区全体のそれら（＝23区の平均値）から一定程度ばらついたものであると定式化しています。これは、地価を考慮するとデータ生成のメカニズムに沿っていて理にかなったものです。また、最寄り駅ごとに別々に線形回帰するのではなく東京23区全体の傾向を借用することで、データ数が少ない最寄り駅の物件でもパラメータの推定が行えるのも階層ベイズのメリットです（縮約といいます）。 ↩︎
地下1階効果の95%ベイズ信用区間は5.5%-7.7%と若干広いです。これはパラメータ推定に使った物件データの中に地下1階の物件の数があまり多くなかったからです。 ↩︎
他に最上階ではないという条件も与えていますが、これまで見たように最上階かどうかは家賃に影響を与えないので、最上階だとしてもプロットは変わりません。 ↩︎

カルマンフィルタで株式のベータ値を推定する

Tue, 16 Jan 2024 00:00:00 +0900

概要

個別株式のリスクが市場全体のリスクと比べてどの程度大きいかを示す「ベータ値」という数値があります。
精緻化された「時変ベータ」を求めるため、ベータ値の変動を状態空間モデルで定式化し、カルマンフィルタを用いて東京電力のベータ値を推定してみました。
- カルマンフィルタはPythonでフルスクラッチで書きました。なお、参考までにRのKFASを使ったバージョンも付けています。
経済・ファイナンスのためのカルマンフィルター入門（森平, 2019）でも述べられているように、東京電力株は株価の値動きが景気変動に影響を受けづらいディフェンシブ銘柄の代表格とされてきましたが、ベータ値は2011年の東日本大震災や原発事故の時期を境に急上昇したことが分かりました。
- この書籍で用いている状態空間モデルと本記事で用いた状態空間モデルは若干違います（後述）。
Pythonでのカルマンフィルタの実装は「カルマンフィルタの実装」の章をご覧ください。結果を見たい方は「ベータ値（カルマンフィルタ版）」の章をご覧ください。

ベータ値とは

TOPIXなどの市場全体の株価と比べて、個別株式などの株価がどの程度大きく動く傾向かというリスクの指標です。個別株式のリスクの大きさを示す指標としてよく使用されます。なお、金融リスクの分野でいうリスクとは、一般的に値動きの激しさを示します。リターンの分布の分散のイメージです。

例えば、対日経平均株価のベータ値が1.5の銘柄は、日経平均が1%動くと平均的に1.5%動くことを示します。1より大きい銘柄は、値上がるときは市場平均よりも大きく上がるものの、値下がるときは市場平均よりも大きく下がる傾向にあります。一方、1より小さい銘柄は、値上がるときは市場平均よりも上がらないものの、値下がるときは市場平均よりも小幅な下げにとどまりやすいです。

ベータ値は一般的には0～2程度を取ることが多いです。負の値を取ることもあり得ます。景気に敏感なセクターである電気機器セクターや機械セクターの銘柄は1より大きく、景気に左右されにくい電気・ガスセクターや食品セクターといった内需型のセクターは1より小さい傾向にあります。各銘柄のベータ値は例えば日経電子版のベータ値高位ランキングなどで見ることができます。

ベータ値は、個別株式のポジションのヘッジポジションを組むためにも使われます。個別株式のリスクは、市場全体に由来するリスクと個別株式に由来するリスクに分解されます。個別株式の買いポジションを持っているとき、その買いポジションの金額にベータ値を掛けた金額だけ株価指数の売りポジションを持つと、市場全体から来る変動を打ち消すことができます¹。

ベータ値の定式化

$S_{t}, S_{t}^{M}$をそれぞれ、$t (1, \dots, T)$日における個別株式とマーケット指数の終値とします。「マーケット指数」は、日経平均株価やTOPIXなどです。

$t$日における個別株式とマーケット指数の対前日リターンをそれぞれ$r_{t}, r_{t}^{M}$とすると、対数リターンは以下で計算できます²。

$$ \begin{align*} r_{t} &= \log S_{t} - \log S_{t-1} \\\ r_{t}^{M} &= \log S_{t}^{M} - \log S_{t-1}^{M} \end{align*} $$

このとき、$t$日におけるベータ値は、以下の$\beta_{t}$です。

$$ r_{t} = \alpha_{t} + \beta_{t} r_{t}^{M} + \epsilon_t, \quad \epsilon_{t} \sim N(0, \sigma^2) $$

$\beta_{t}$は、過去一定期間の$r_{t}, r_{t}^{M}$を用いて回帰で求められます。過去1年～3年＝250営業日～750営業日とすることが多いように思います。この期間を1日ずつずらしてローリング回帰することで各$t$における$\beta_{t}$を得るというのが簡単な推定方法です。

しかしこの方法は簡略化しているため、いくつか問題点があります。ローリング回帰に用いた標本期間$t-i+1, \dots, t$日の間はベータ値は一定と仮定していますが、実際にはそうではありません。ある日にベータ値が急に動いたとしても、この方法では変動は遅れてマイルドにしか現れません。また$i$をいくつに設定するかによってベータ値が変わります。

状態空間モデルを用いてベータ値を動的に定式化することで、これらの問題を解消することができます。この記事では、最もオーソドックスだと思われる以下の状態空間モデルを推定します³。

$$ \begin{align*} r_{t} &= \alpha_{t} + \beta_{t} r_{t}^{M} + e_{t}, &e_t \sim N(0, \sigma_{e}^2) \\\ \alpha_{t} &= \alpha_{t-1} + \epsilon_{t}, &\eta_t \sim N(0, \sigma_{\epsilon}^2) \\\ \beta_{t} &= \beta_{t-1} + \eta_{t}, &\eta_t \sim N(0, \sigma_{\eta}^2) \end{align*} $$

$\beta_{t}$がベータ値です。これは時変ベータと呼ばれます。1本目の式が観測方程式、2本目と3本目の式が状態方程式の状態空間モデルで、ベータ値が日々確率的に変動することを示しています。

最初のベーシックな方法でのベータ値は、このモデルの2本目と3本目の式をなくしたものですね。時系列回帰が静的から動的になったと考えてもいいです（動的な時系列回帰をするために回帰タイプの状態空間モデルを組むというのはよくあるパターンです）。

このような、線形で誤差項が正規分布の状態空間モデルでは、状態空間モデルの状態（上のモデルでは$\alpha_{t}, \beta_{t}$）の平均と分散・共分散は、カルマンフィルタというアルゴリズムによって解析的に行列計算で高速に求められます。

この記事では、まずベータ値とは何かをイメージするために最初の方法でのベータ値を示します。次に後者の時変ベータをカルマンフィルタで実装することで時変ベータをみてみます。

環境

株価の取得はpandas-datareader, DataFrameのハンドリングはpolars, プロットはplotnineを使います。

カルマンフィルタはnumpyとscipyで自分で一から実装しました。最初はpykalmanといういい感じのライブラリを見つけたのですが、メンテが止まっており、GitHubのissueに立っているエラーと同じエラーが出て動きませんでした。

Windows 10
Python 3.11.5
numpy 1.26.0
pandas-datareader 0.10.0
polars 0.19.6
plotnine 0.12.3
patchworklib 0.6.2
scipy 1.11.3

import numpy as np
import scipy as sp
import pandas_datareader.data as pdr
import polars as pl
import patchworklib as pw
from plotnine import *

株価データの取得

2001/1/5～2023/12/29の東京電力と日経平均株価を取得しました。

株価はpandas_datareader.data.DataReaderを用いてStooqから取得します。一定期間の個別株式と日経平均の終値が取得できればデータソースは何でも構いません。

東京電力と日経平均の終値からそれぞれ対前日の対数リターンを計算しておきます。対数リターンは%表記できるように100倍します。また、最初の日のリターンは計算できないので最初の日のレコードを除きます。

STOCK_CODE = "9501.JP"
MARKET_CODE = "^NKX"
START_DATE = "2001-01-01"
END_DATE = "2023-12-29"
stock = pdr.DataReader(STOCK_CODE, data_source="stooq", start=START_DATE, end=END_DATE)
# pd.reset_index()でindexにあるdateをカラムとして持つ
df_stock = pl.from_pandas(stock.reset_index())
df_stock = (
df_stock
.sort("Date")
# 数レコードだけ株価がnullの日付があるが、nullの場合は削除する
.filter(pl.col("Close").is_not_null())
.with_columns(
Date=pl.col("Date").dt.date(),
ret=(pl.col("Close").log() - pl.col("Close").shift(1).log())*100
)
.slice(1)
)
market = pdr.DataReader(MARKET_CODE, data_source="stooq", start=START_DATE, end=END_DATE)
df_market = pl.from_pandas(market.reset_index())
df_market = (
df_market
.sort("Date")
.filter(pl.col("Close").is_not_null())
.with_columns(
Date=pl.col("Date").dt.date(),
ret=(pl.col("Close").log() - pl.col("Close").shift(1).log())*100
)
.slice(1)
)
df = (
df_stock
.rename({"Date": "date", "Close": "close_stock", "ret": "ret_stock"})
.select("date", "close_stock", "ret_stock")
.join(
df_market
.rename({"Date": "date", "Close": "close_market", "ret": "ret_market"})
.select("date", "close_market", "ret_market"),
how="inner",
on="date"
)
)

こんな感じのDataFrameです。closeは終値、retはリターン（%）、_stockは東京電力、_marketは日経平均を指します。

polarsはDataFrameをprintしたときに各カラムのデータ型を書いてくれるのも素敵ですね。

print(df)

shape: (5_632, 5)
┌────────────┬─────────────┬───────────┬──────────────┬────────────┐
│ date ┆ close_stock ┆ ret_stock ┆ close_market ┆ ret_market │
│ --- ┆ --- ┆ --- ┆ --- ┆ --- │
│ date ┆ f64 ┆ f64 ┆ f64 ┆ f64 │
╞════════════╪═════════════╪═══════════╪══════════════╪════════════╡
│ 2001-01-05 ┆ 2800.0 ┆ -2.469261 ┆ 13867.61 ┆ 1.278143 │
│ 2001-01-09 ┆ 2805.0 ┆ 0.178412 ┆ 13610.51 ┆ -1.871362 │
│ 2001-01-10 ┆ 2840.0 ┆ 1.240051 ┆ 13432.65 ┆ -1.315398 │
│ 2001-01-11 ┆ 2850.0 ┆ 0.351494 ┆ 13201.07 ┆ -1.739042 │
│ … ┆ … ┆ … ┆ … ┆ … │
│ 2023-12-26 ┆ 733.1 ┆ 0.684372 ┆ 33305.85 ┆ 0.155709 │
│ 2023-12-27 ┆ 735.0 ┆ 0.258838 ┆ 33681.24 ┆ 1.120795 │
│ 2023-12-28 ┆ 736.7 ┆ 0.231025 ┆ 33539.62 ┆ -0.421358 │
│ 2023-12-29 ┆ 738.5 ┆ 0.244035 ┆ 33464.17 ┆ -0.225211 │
└────────────┴─────────────┴───────────┴──────────────┴────────────┘

ベータ値（ベーシック版）

ベーシックな方法でのベータ値は、一定期間の市場全体のリターンを横軸に、個別株式のリターンを縦軸に取って散布図を描き、そこに回帰直線を引いたときの回帰直線の傾きになります。

以下のプロットは、2023/12/29から直近250営業日のリターンの散布図です。赤い線は回帰直線です。赤い線の傾きが、直近250日のデータから計算する2023/12/29のベータ値になります。1を少し下回るくらいです。

Code

(
ggplot(
df.tail(250),
aes("ret_market", "ret_stock")
)
+geom_point()
+theme_light()
+stat_smooth(method="lm", formula="y ~ x + 1", se=False, color="firebrick")
+labs()
+theme(figure_size=(10, 4), dpi=100)
).draw()

以上の方法で各日ごとにローリング回帰すればベータ値を得ることができます。

カルマンフィルタのアルゴリズム

線形・ガウスの状態空間モデルでは、観測誤差（今回のモデルでは$\sigma_{e}$）と状態誤差（$\sigma_{\epsilon}, \sigma_{\eta}$）をパラメータとして与えると、各$t (1, \dots, T)$における状態（今回のモデルでは$\alpha_{t}, \beta_{t}$）の平均と共分散行列は行列計算で解析的に得られます。このアルゴリズムをカルマンフィルタといいます。

ここで得られる状態は以下の2通りです。

フィルタ化推定量: 各$t$における状態を、$1, \dots, t$の観測値から推定する
平滑化推定量: 各$t$における状態を、$1, \dots, T$の観測値から推定する

後者は全時点のデータから状態をbackwardに推定するため、状態の変化は滑らかに、状態の分散は小さく（信頼区間の幅がフィルタ化推定量より狭く）なります。

以下にカルマンフィルタのアルゴリズムを示します。

いま、観測値を$y_{t}$, 状態を$\boldsymbol{x_{t}}$とします。以下、太字の変数は行列、そうではない変数はスカラーを示します。

行列表現で表すと以下の1本目の式が状態方程式、2本目の式が観測方程式です。

$$ \begin{align*} \boldsymbol{x_{t}} &= \boldsymbol{G_{t}} \boldsymbol{x_{t-1}} + \boldsymbol{w_{t}}, &\boldsymbol{w_{t}} \sim N(\boldsymbol{0}, \boldsymbol{W_{t}}) \\\ y_{t} &= \boldsymbol{F_{t}} \boldsymbol{x_{t}} + v_{t}, &v_{t} \sim N(0, V_{t}) \end{align*} $$

ただし、$\boldsymbol{G_{t}}$は状態遷移行列（p x p）、$\boldsymbol{F_{t}}$は観測行列（1 x p）、$\boldsymbol{W_{t}}$は状態誤差の共分散行列（p x p）、$V_{t}$は観測誤差の分散です。

また、状態の事前分布$\boldsymbol{x_{0}}$は$\boldsymbol{x_{0}}\sim N(\boldsymbol{m_{0}}, \boldsymbol{C_{0}})$であり、$\boldsymbol{m_{0}}$はp次元のベクトル、$\boldsymbol{C_{0}}$はp x pの行列です。

フィルタリング

$t-1$での状態のフィルタリング分布の平均と共分散行列$\boldsymbol{m_{t-1}}, \boldsymbol{C_{t-1}}$（それぞれp次元ベクトル、p x pの行列）が与えられると、

フィルタリング分布: $N(\boldsymbol{m_{t}}, \boldsymbol{C_{t}})$
- $\boldsymbol{m_{t}}, \boldsymbol{C_{t}}$はそれぞれp次元ベクトル、p x pの行列
一期先予測分布: $N(\boldsymbol{a_{t-1}}, \boldsymbol{R_{t-1}})$
- $\boldsymbol{a_{t}}, \boldsymbol{R_{t}}$はそれぞれp次元ベクトル、p x pの行列
一期先予測尤度: $N(f_{t}, Q_{t})$
- $f_{t}, Q_{t}$はスカラー

は以下で計算できます。

$$ \begin{align*} \boldsymbol{a_{t}} &= \boldsymbol{G_{t}} \boldsymbol{m_{t-1}} \\\ \boldsymbol{R_{t}} &= \boldsymbol{G_{t}} \boldsymbol{C_{t-1}} \boldsymbol{G_{t}}^{\mathrm{T}} + \boldsymbol{W_{t}} \\\ f_{t} &= \boldsymbol{F_{t}} \boldsymbol{a_{t}} \\\ Q_{t} &= \boldsymbol{F_{t}} \boldsymbol{R_{t}} \boldsymbol{F_{t}}^{\mathrm{T}} + V_{t} \\\ \boldsymbol{K_{t}} &= \boldsymbol{R_{t}} \boldsymbol{F_{t}}^{\mathrm{T}} Q_{t}^{-1} \\\ \boldsymbol{m_{t}} &= \boldsymbol{a_{t}} + \boldsymbol{K_{t}} (y_{t} - f_{t}) \\\ \boldsymbol{C_{t}} &= (\boldsymbol{I} - \boldsymbol{K_{t}} \boldsymbol{F_{t}}) \boldsymbol{R_{t}} \end{align*} $$

$\boldsymbol{K_{t}}$はカルマンゲインと呼ばれるものです。$\boldsymbol{I}$は単位行列です。

平滑化

$t+1$での状態の平滑化分布の平均と共分散行列$\boldsymbol{s_{t+1}}, \boldsymbol{S_{t+1}}$（それぞれp次元ベクトル、p x pの行列）が与えられると、平滑化分布 $N(\boldsymbol{s_{t}}, \boldsymbol{S_{t}})$は以下で計算できます。

$$ \begin{align*} \boldsymbol{A_{t}} &= \boldsymbol{C_{t}} \boldsymbol{G_{t+1}}^{\boldsymbol{T}} \boldsymbol{R_{t+1}}^{-1} \\\ \boldsymbol{s_{t}} &= \boldsymbol{m_{t}} + \boldsymbol{A_{t}} (\boldsymbol{s_{t+1}} - \boldsymbol{a_{t+1}}) \\\ \boldsymbol{S_{t}} &= \boldsymbol{C_{t}} + \boldsymbol{A_{t}} (\boldsymbol{S_{t+1}} - \boldsymbol{R_{t+1}}) \boldsymbol{A_{t}}^{\boldsymbol{T}} \end{align*} $$

$\boldsymbol{A_{t}}$は平滑化利得と呼ばれるものです。

対数尤度

観測誤差と状態誤差をパラメータとして与えると、一期先予測尤度から尤度を解析的に計算できます。対数尤度は以下で求められます。

$$ \begin{align*} loglik(\boldsymbol{G_{t}}, \boldsymbol{F_{t}}, \boldsymbol{W_{t}}, V_{t}, \boldsymbol{m_{0}}, \boldsymbol{C_{0}}) &= \sum_{t=1}^{T} \log p(y_{t} | y_{1:t-1}; \boldsymbol{G_{t}}, \boldsymbol{F_{t}}, \boldsymbol{W_{t}}, V_{t}, \boldsymbol{m_{0}}, \boldsymbol{C_{0}}) \\\ &= -\frac{1}{2} T \log 2 \pi - \frac{1}{2} \sum_{t=1}^{T} log |Q_{t}| - \frac{1}{2} \sum_{t=1}^{T} (y_{t} - f_{t})^2 / Q_{t} \end{align*} $$

対数尤度を最大化するような観測誤差と状態誤差の値を数理最適化で求めるプロセスを最初に行い、この観測誤差と状態誤差をパラメータとして用いてフィルタリングと平滑化を行います。

以上のアルゴリズムの導出はこちらの書籍をご参照ください。

基礎からわかる時系列分析 ―Rで実践するカルマンフィルタ・MCMC・粒子フィルター
- 日本語で読める状態空間モデルの本では最高レベルに充実していると思います。
- Rのコードでの実装例もあるので大変参考になります。

カルマンフィルタの実装

いま推定したいベータ値のモデルは、上の行列形式の状態空間モデルでそれぞれ以下としたものです。

$y_{t}$: $r_{t}$
$\boldsymbol{F_{t}}$: $(1, r_{t}^{M})$
$\boldsymbol{x_{t}}$: $(\alpha_{t}, {\beta_{t}})^{\mathrm{T}}$
$\boldsymbol{G_{t}}$: 2 x 2の単位行列
$\boldsymbol{w_{t}}$: 左上が$W_{\alpha}$, 右下が$W_{\beta}$の2 x 2の対角行列

以下のコードがカルマンフィルタの実装です。上で示したアルゴリズムをそのまま実装します。

def filtering(y, m, C, G, F, W, V):
"""
(t-1)期において、1期先（t期）のフィルタリングを行う関数
such as:
x_t = G_t * x_(t-1) + w_t, w_t ~ N(0, W_t) : 状態方程式
y_t = F_t * x_t + v_t, v_t ~ N(0, V_t) : 観測方程式
x, G, w, W, Fは行列, y, v, Vはスカラー
Params:
y: 観測値 [時点t]
m, C: 状態の平均, 共分散行列 [t-1]
G, F, W, V: 状態遷移行列, 観測行列, 状態誤差の共分散行列, 観測誤差の共分散行列 [t]
Returns:
tuple
フィルタリング分布の平均と共分散行列 m, C [t]
一期先予測分布の平均と共分散行列 a, R [t]
一期先予測尤度の平均と共分散行列 f, Q [t]
"""
# 一期先予測分布
a = G @ m
R = G @ C @ G.T + W
# 一期先予測尤度
f = F @ a
Q = F @ R @ F.T + V
# カルマンゲイン
K = R @ F.T @ np.linalg.inv(Q)
# 状態の更新
m = a + K @ (y - f)
C = R - K @ F @ R
f_scalar, Q_scalar = f.item(), Q.item()
return m, C, a, R, f_scalar, Q_scalar
def smoothing(s, S, m, C, a, R, G):
"""
(t+1)期のsとSからt期のsとSを求める（状態の平滑化分布の平均と共分散行列）
Params:
s, S: 平滑化分布の平均, 共分散行列 [t+1]
m, C: 状態の平均, 共分散行列 [t]
a, R: 一期先予測分布の平均と共分散行列 [t+1]
G: 状態遷移行列 [t+1]
Returns:
tuple
平滑化分布の平均, 共分散行列 s, S [t]
"""
# 平滑化利得
A = C @ G.T @ np.linalg.inv(R)
# 平滑化された状態
s = m + A @ (s - a)
S = C + A @ (S - R) @ A.T
return s, S
def reverse_loglik(w_v, dims, y, G, F, m0, C0):
"""
状態誤差と観測誤差を与えると対数尤度の-1倍を返す関数
Params:
w_v: 長さ2のtuple　状態誤差と観測誤差の値
dims: 状態の数
y, G, F, m0, C0: 状態空間モデルの係数
Returns:
float: 対数尤度の-1倍
"""
# 分散は負にならないのでexpをかける
W = np.eye(dims) * np.exp(w_v[0])
V = np.array([1]).reshape((1, 1)) * np.exp(w_v[1])
T = len(y)
m, C = np.zeros((T, dims)), np.zeros((T, dims, dims))
a, R = np.zeros((T, dims)), np.zeros((T, dims, dims))
f, Q = np.zeros((T)), np.zeros((T))
# 全期間フィルタリングする
for t in range(0, T):
_F = F[t].reshape((1, dims))
if t == 0:
m[t], C[t], a[t], R[t], f[t], Q[t] = filtering(y[t], m0, C0, G, _F, W, V)
else:
m[t], C[t], a[t], R[t], f[t], Q[t] = filtering(y[t], m[t-1], C[t-1], G, _F, W, V)
loglik = (-1) * np.sum(np.log(Q)) / 2 - (np.sum((y - f)**2 / Q)) / 2
return (-1)*loglik
# 対数尤度を最大化する観測誤差と状態誤差を求める
ret_market = df.get_column("ret_market").to_numpy()
ret_stock = df.get_column("ret_stock").to_numpy()
y = ret_stock
x = ret_market
T = len(y)
dims = 2
G = np.eye(dims)
F = np.eye(T, dims)
F[:, 0] = 1
F[:, 1] = x
# 状態の平均と共分散行列の初期値
m0 = np.zeros(dims)
C0 = np.eye(dims)*10000000
best_par=sp.optimize.minimize(
reverse_loglik,
[0.0, 0.0],
args=(dims, y, G, F, m0, C0),
method="BFGS"
)
W = np.eye(dims) * np.exp(best_par.x[0])
V = np.array([1]).reshape((1, 1)) * np.exp(best_par.x[1])
# 上で求めた観測誤差と状態誤差をもとにフィルタリングと平滑化を行う
# 結果を入れる変数
m, C = np.zeros((T, dims)), np.zeros((T, dims, dims))
a, R = np.zeros((T, dims)), np.zeros((T, dims, dims))
f, Q = np.zeros((T)), np.zeros((T))
s, S = np.zeros((T, dims)), np.zeros((T, dims, dims))
# フィルタリング
for t in range(0, T):
_F = F[t].reshape((1, dims))
if t == 0:
m[t], C[t], a[t], R[t], f[t], Q[t] = filtering(y[t], m0, C0, G, _F, W, V)
else:
m[t], C[t], a[t], R[t], f[t], Q[t] = filtering(y[t], m[t-1], C[t-1], G, _F, W, V)
# 平滑化
for t in range(T - 1, 0, -1):
if t == T - 1:
s[t], S[t] = m[t], C[t]
else:
s[t], S[t] = smoothing(s[t+1], S[t+1], m[t], C[t], a[t+1], R[t+1], G)

20秒くらいで推定できます。

scipyのscipy.optimize.minimizeは最小化なので、対数尤度の-1倍を最小化の目的関数とします。scipy.optimize.minimizeに渡す初期値ですが、与える初期値によっては局所解に落ちるので、初期値を複数与えて目的関数が最小となる初期値をグリッドサーチで求めるのが望ましいです。

RやPythonなどのよくできたライブラリだとよくあるタイプのモデルは行列形式で書かなくても記述できますが、少しカスタマイズしようとすると、ライブラリを使っても行列表現して自分で係数行列を与えてあげることが必要になります。

スクラッチで実装するにしてもライブラリを使うにしても、カルマンフィルタの実装のポイントは、推定したいモデルを行列形式で書くこと、各パラメータの行列の次元（m x n）と何が行列で何がスカラーなのかを意識することだと思います。意識しないと混乱するんですよね。

ベータ値（カルマンフィルタ版）

フィルタ化と平滑化の状態の平均と共分散行列を取り出して95%信頼区間を計算します。扱いやすいようにnumpy.ndarrayからpolars.DataFrameに変換して持っておきます。

Code

# フィルタ化と平滑化の平均と共分散行列を取り出し、そこから95%信頼区間を計算する
beta_est = (
pl.DataFrame({
"date": df.get_column("date"),
"estimated": m[:, 1],
"std_error": np.sqrt(C[:, 1, 1])
})
.with_columns(
lower=pl.col("estimated")+sp.stats.norm.ppf(0.025)*pl.col("std_error"),
upper=pl.col("estimated")+sp.stats.norm.ppf(0.975)*pl.col("std_error"),
)
)
alpha_est = (
pl.DataFrame({
"date": df.get_column("date"),
"estimated": m[:, 0],
"std_error": np.sqrt(C[:, 0, 0])
})
.with_columns(
lower=pl.col("estimated")+sp.stats.norm.ppf(0.025)*pl.col("std_error"),
upper=pl.col("estimated")+sp.stats.norm.ppf(0.975)*pl.col("std_error"),
)
)
beta_smooth = (
pl.DataFrame({
"date": df.get_column("date"),
"estimated": s[:, 1],
"std_error": np.sqrt(S[:, 1, 1])
})
.with_columns(
lower=pl.col("estimated")+sp.stats.norm.ppf(0.025)*pl.col("std_error"),
upper=pl.col("estimated")+sp.stats.norm.ppf(0.975)*pl.col("std_error"),
)
)
alpha_smooth = (
pl.DataFrame({
"date": df.get_column("date"),
"estimated": s[:, 0],
"std_error": np.sqrt(S[:, 0, 0])
})
.with_columns(
lower=pl.col("estimated")+sp.stats.norm.ppf(0.025)*pl.col("std_error"),
upper=pl.col("estimated")+sp.stats.norm.ppf(0.975)*pl.col("std_error"),
)
)

次のプロットの1枚目はベータ値（$\beta_{t}$）のフィルタ化推定量、2枚目は平滑化推定量、3枚目は東京電力の終値です。赤い線は平均値、上下の青いリボンは95%信頼区間です。ただし最初の50営業日は推定が安定していないので51営業日以降をプロットしています。

Code

# 結果のプロット
# 最初の50期は使わない
p1 = (
ggplot(beta_est.slice(50), aes("date"))+
theme_light()+
geom_ribbon(aes(ymin="lower", ymax="upper"), fill="lightsteelblue", alpha=0.5)+
geom_line(aes(y="lower"), color="lightsteelblue")+
geom_line(aes(y="upper"), color="lightsteelblue")+
geom_line(aes(y="estimated"), color="firebrick")+
scale_x_date(breaks="1 year", date_labels="%y")+
scale_y_continuous(breaks=range(-1, 3, 1))+
labs(
title="[9501: Tepco HD] time-varing beta (filtered); red: estimated (mean), light blue: 95%CI",
x="date (year)",
y="beta"
)
)
p2 = (
ggplot(beta_smooth.slice(50), aes("date"))+
theme_light()+
geom_ribbon(aes(ymin="lower", ymax="upper"), fill="lightsteelblue", alpha=0.5)+
geom_line(aes(y="lower"), color="lightsteelblue")+
geom_line(aes(y="upper"), color="lightsteelblue")+
geom_line(aes(y="estimated"), color="firebrick")+
scale_x_date(breaks="1 year", date_labels="%y")+
scale_y_continuous(breaks=range(-1, 3, 1))+
labs(
title="[9501: Tepco HD] time-varing beta (smoothed); red: estimated (mean), light blue: 95%CI",
x="date (year)",
y="beta"
)
)
p3 = (
ggplot(df.slice(50), aes("date", "close_stock"))+
theme_light()+
geom_line()+
scale_x_date(breaks="1 year", date_labels="%y")+
labs(
title="[9501: Tepco HD] stock price (close)",
x="date (year)",
y="close"
)
)
pw.load_ggplot(p1, figsize=(10, 2)) / pw.load_ggplot(p2, figsize=(10, 2)) / pw.load_ggplot(p3, figsize=(10, 2))

状態空間モデルを用いたことで、ベータ値の推定値だけでなく、ベータ値の95%信頼区間を求めることができます。ベータ値は95%の確率でこの範囲内という幅を得られるのもうれしいですね。

一番上のプロットを見ると分かりますが、2011年3月の東日本大震災までは、ベータ値の平均は1を下回っています。東京電力株は景気変動の影響を受けにくいディフェンシブ銘柄の代表ともいえる銘柄でしたが、東日本大震災のころにベータ値が急変動し、一時は2程度まで上がっていることが分かります。

2枚目のプロットは平滑化推定量なので、1枚目のプロットを滑らかにしたような感じになっていて大まかなトレンドが分かりやすいですね。ただし、全期間の観測値から状態を推定するという平滑化のアルゴリズム上、ベータ値は東日本大震災の前から大きく上昇しています。

東日本大震災のころにベータ値が急変動している背景は、原発事故やそれによる経営環境の変化だと想像はできますが、状態空間モデルではそうであるという因果関係は何も示していないことに注意が必要です。しかし、冒頭で触れた「経済・ファイナンスのためのカルマンフィルター入門」では、原発を持たない沖縄電力以外の電力会社は東京電力と同様に震災を境にベータの振る舞いが変わっていて、沖縄電力だけは特に変化がなかったと述べられています。

おわりに

状態空間モデルとカルマンフィルタによってベータ値の変動をとらえることができました。

状態誤差と観測誤差は正規分布としましたが、ベータ値の状態空間モデルでは特に状態誤差は正規分布ではないという先行研究⁴もあるので、状態誤差をt分布などにしたモデルを組んでみても面白そうです。

[Appendix. 1] R + KFASでのカルマンフィルタの実装

Rで実装する場合の例です。Rでカルマンフィルタをやるなら、KFASという、dlmに並んでデファクトスタンダードのライブラリがあります。

Pythonの場合と同じように、dfというdata.frameに、ret_stockとret_marketというカラムを持っている前提です。

library(KFAS)
# 状態空間モデルの定義
mod <- KFAS::SSModel(
# 観測誤差の分散
H=NA,
# SSMregression内の-1は状態方程式に切片がないことを示す
# Qは状態誤差の分散
ret_stock ~ KFAS::SSMregression(~ret_market-1, Q=NA),
data=df
)
# 対数尤度を最大化する観測誤差と状態誤差を数理最適化で求める
fit <- KFAS::fitSSM(mod, inits=c(0,0), method="BFGS")
# フィルタリングと平滑化をする
kfs <- KFAS::KFS(fit$model, filtering=c("state", "mean"), smoothing=c("state", "mean"))

これだけです。楽ですね。今回の回帰タイプの線形・ガウスの状態空間モデルはKFAS::SSMregression()という関数でサポートされていますのでこれを呼ぶだけです。

フィルタ化推定量の平均と共分散行列、平滑化推定量の平均と共分散行列をそれぞれkfs$att, kfs$Ptt, kfs$alphahat, kfs$Vで取り出して、Python版と同じようなベータ値の時系列プロットを描くことができます。

[Appendix. 2] ベータ値の定式化（リスクフリーレートバージョン）

ベータ値の推定モデルは、リスクフリーレート⁵を取り入れたバージョンもあります。

いま、$t$日におけるリスクフリーレートを$r_{t}^{f}$としたとき、最初の簡略化したモデルは以下になります。

$$ r_{t} - r_{t}^{f} = \beta_{t} (r_{t}^{M} - r_{t}^{f}) + \epsilon_t, \quad \epsilon_{t} \sim N(0, \sigma^2) $$

また、状態空間モデルバージョンはこちらになります。

$$ \begin{aligned} r_{t} - r_{t}^{f} &= \beta_{t} (r_{t}^{M} - r_{t}^{f}) + e_{t}, \quad e_t \sim N(0, \sigma_{e}^2) \\\ \beta_{t} &= \beta_{t-1} + \eta_{t}, \quad \eta_t \sim N(0, \sigma_{\eta}^2) \end{aligned} $$

どちらも、$\alpha_{t}$の項がなくなっています。

$r_{t} - r_{t}^{f}$と$r_{t}^{M} - r_{t}^{f}$はそれぞれ、リスクを負って得られる個別株式とマーケット指数の超過リターンです。そのため、$\alpha_{t}$が正であれば、リスクを全く負わずに、リターンがリスクフリーレート+$\alpha_{t}$だけ得られることを示します。そのような裁定取引の機会は効率的な市場では得られないというファイナンスの無裁定理論より、$\alpha_{t}$は0となります⁶。なお、これは理論だけの話ではなく、$\alpha_{t}$をモデルに入れて推定すると、多くの場合で$\alpha_{t}$は有意に正でも負でもないことが実証的にも示されます。

ただし、日本のリスクフリーレートはほぼ0のため、リスクフリーレートを考慮してもしなくても大きくは変わりません。

TOPIXのボラティリティをStochastic Volatilityモデル + R + Stanで推定する - suzuna's memo

このヘッジによって市場平均のリターンとの差分だけを得ることができます。例えば市場平均が-5%、個別株式のポジションが-3%となった場合、-3%-(-5%)=2%のリターンを得られます。個別株式のポジションが値下がった場合でも市場平均とのリターンの差分だけを得られるというのがメリットです。詳しく知りたい方はこちらの本の第3章をご参照ください: ジョン・ハル (2016), 「ファイナンシャルエンジニアリング（第9版）」。ただし実際には、個別株式や株価指数（先物）の最低投資単位の都合上ベータ値を厳密に0にするポジションは組みづらいこと、ヘッジ比率を調整することの手数料の考慮、連続的な値動きに対してヘッジ比率の調整は日次や週次、月次など離散的なタイミングでしか行えず厳密にヘッジができないことなどの難しさがあります。 ↩︎
リターンと聞いてふつうイメージするのは、$r_{t} = (S_{t} / S_{t-1}) - 1$だと思います。金融工学では当日の株価の自然対数と前日の株価の自然対数の差である対数リターンを用います。株価がたいてい取りうる数%くらいのリターンの範囲では、テイラー展開より対数リターンは割り算でのリターンとほぼ一致します。 ↩︎
なお、「経済・ファイナンスのためのカルマンフィルター入門」（森平, 2019）では、$\alpha$は時変ではないモデルを推定しています。 ↩︎
矢野浩一 (2004), 「カルマンフィルタによるベータ推定」2004年度FSAリサーチレビュー, 104-125. ↩︎
ここでいうリスクフリーレートには、現在では無担保コール翌日物金利やOISレートが用いられます。リスクフリーレートとみなされることの多い国債の利回りは、日本国の信用リスクが含まれるため厳密にはリスクフリーなレートではありません。無担保コール翌日物金利やOISは信用リスクをほとんど含まない金利のため、リスクフリーレートとして望ましいです。リスクフリーレートにどの金利を使うかというのはリーマンショック以降特に意識されるようになったと聞きます。リスクフリーレートについて知りたい方はこの辺が参考になるかと思います。リスク・フリー・レート（RFR）入門－TONA，TORF，OISを中心に－/金利スワップ入門 -基礎編- ↩︎
逆に言うと、競争が働いている効率的な市場ではない市場では、そうではない可能性はあります。 ↩︎

tcardgenとGitHub ActionsでHugoのブログのOGPを動的に作る

Wed, 27 Dec 2023 00:00:00 +0900

概要

markdownファイルからOGP画像を生成するLadicle/tcardgenを使い、Hugoで作っているブログで記事のmarkdownファイルをGitHubにpushすると、記事のOGP画像を動的に作るGitHub Actionsを作りました。動的というのは、markdownファイルのFront Matterからtitleなどを取り出してOGP画像を作るということです。

こんな感じです。

OGP画像にはうずらフォントを使いました。わたしの好きなかわいいフォントを選べてうれしいです。こういうのがモチベーションを上げるのです。

GitHub Actionsではなくローカルでtcardgenを実行してもいいですが、HugoのビルドもGitHub Actionsで行っている場合、markdownファイルを書いてpushするだけでビルドもOGP画像生成も自動でできちゃうのでとっても快適です。

このブログはHugo（テーマはanubis）のページバンドルとして、Leaf Bundleを採用しています。tcardgenをLeaf Bundleで動かすところとHugoのテーマにOGPを入れるのにちょっと苦戦したので、HugoのLeaf Bundleを採用しているサイトでtcardgenによってOGP画像をGitHub Actionsで作る方法をご紹介します。

大手ブログや技術ブログサイトなら何もしなくてもOGPを作ってくれるのでこういう手間はありませんが、自分だけのお城をHugoで好きなように建てていくのも悪くないです。使い慣れたエディタ（VSCode）とGitとGitHubで全てが完結できるのもいいですね。

技術構成

技術構成はこのようになっています。

もともと、Hugoのソースのリポジトリ（suzuna/blog-source）にpushすると、GitHub ActionsによってHugoのビルドを行い、生成物をHugoの公開用のリポジトリ（suzuna/blog）にpushするようにしていたのですが、このGitHub ActionsにtcardgenでのOGP画像生成を加えました。

Hugoのディレクトリ構成

content/以下はこのような構成になっています。content/posts以下に、記事を書いた日付をyyyymmddで先頭に付与したフォルダを作り、その中に記事をindex.mdで作成します。

content
├── about.md
└── posts
├── yyyymmdd-hoge-fuga-piyo
│   └── index.md
└── yyyymmdd-foo-bar-baz
├── images
│   └── image01.jpg
└── index.md

やったこと

tcardgenの出力OGP画像のファイル名の調整

tcardgenで、特定のディレクトリ以下にある全てのmarkdownファイルについてそれぞれOGP画像を作るなら、まずこちらを行います。

Goをインストールする
path/to/fontDir以下に、<font-name>-Bold.ttf, <font-name>-Medium.ttf, <font-name>-Regular.ttfのファイル名で3個のフォントを置く¹
path/to/templateFileというファイル名でOGP画像のテンプレートファイルを置く

そして、tcardgenのREADMEのとおり以下を実行すれば、path/to/static/ogp直下に、path/to/content/posts/*.mdに該当する個々のmarkdownファイルから作成したOGP画像が出力されます。

go install github.com/Ladicle/tcardgen@latest
# 出力先の画像のディレクトリは事前に作る必要がある
mkdir -p path/to/static/ogp
tcardgen \
--fontDir path/to/fontDir \
--output path/to/static/ogp \
--template path/to/templateFile \
path/to/content/posts/*.md

ここで、出力される画像のファイル名は、Markdownファイルのファイル名と同じものになります。index.mdならindex.pngです。Leaf Bundleでは、記事のmarkdownファイルのファイル名は全てindex.mdのため、全ての記事のOGP画像はindex.pngとなり、ファイルが上書きされて1個しか生成されません。当たり前と言えば当たり前なのですが、ここでハマりました。

これを解消するために、content/posts/yyyymmdd-hoge-fuga-piyo/index.mdのOGP画像はhoge-fuga-piyo.pngとするように、1ファイルずつtcardgenを走らせます。

go install github.com/Ladicle/tcardgen@latest
mkdir -p static/ogp
files=`find ./content/posts/*/index.md -type f`
for f in $files; do
slugname=`dirname ${f} | xargs -I@ basename @ | cut -c 10-`
tcardgen --fontDir ogp/font --output "static/ogp/${slugname}.png" \
--template ogp/tcard/template.png ${f}
done

このシェルスクリプトでcontent/posts/yyyymmdd-<適当な名前>/index.mdに合致する全てのmarkdownファイルのOGP画像がstatic/ogp/<適当な名前>.pngに出力されます。

ローカルで実行すればローカルで画像が生成されますが、今回はGitHub Actions上で行います。あとで説明します。

HugoのテンプレートにOGPを入れる

Step1でOGP画像は出力されますが、Hugoのテーマで対応していなければURLが貼られたときにOGP画像が表示されません。

OGP画像とOGPのdescriptionが表示されるよう、HugoのAnubisというThemeのfooter.htmlに以下を追加しました²。テーマ側でOGPに対応していなければどのテーマでも自分で書くことになります。

<meta property="og:url" content="{{ .Permalink }}" />
<meta property="og:type" content="{{ if .IsHome }}website{{ else }}article{{ end }}" />
<meta property="og:site_name" content="{{ .Site.Title }}" />
<meta property="og:title" content="{{ .Title }}" />
<meta property="og:description" content="{{ with .Description -}}{{ . }}{{ else -}}{{ if .IsPage }}{{ substr .Summary 0 300 }}{{ else }}{{ with .Site.Params.description }}{{ . }}{{ end }}{{ end }}{{ end }}" />
<meta property="og:image" content="{{ if .Params.thumbnail -}}{{ .Params.thumbnail|absURL }}{{ else if and .IsPage (eq .Section "posts")}}{{ path.Join "ogp" (print .Slug ".png") | absURL }}{{ else -}}{{ "img/default.png" | absURL }}{{ end -}}" />

posts/yyyymmdd-hoge-fuga-piyo/index.mdのOGP画像として、ogp/{slug}.pngが読み込まれます。

このため、各記事のindex.mdのslugをhoge-fuga-piyoにする必要があります。ディレクトリ名のyyyymmdd-hoge-fuga-piyoのhoge-fuga-piyoとslugを一致させる必要があるということです。実装的に微妙な気はしますがこれで困らないのでいいかなと…。

なお、OGP画像の下に展開されるdescriptionは、各index.mdのFront Matterにdescriptionを書いていればそれが、書いていなければFront Matterの直下から最初の300文字になります。

GitHub Actionsのyamlファイルの作成

以上をGitHub Actionsにするとこうなります。.github/workflows直下に拡張子.ymlで任意のファイル名で保存します。

OGP生成に必要なのはSetup GoとInstall tcardgenとGenerate ogp imagesです。他は通常のHugoのビルド部分とGitHub Pagesへのpush部分なので必要に応じて変更してください。

name: github-pages
on:
push:
branches:
- master
jobs:
deploy:
runs-on: ubuntu-latest
timeout-minutes: 10
steps:
- uses: actions/checkout@v2
with:
submodules: true # Fetch Hugo themes (true OR recursive)
fetch-depth: 0 # Fetch all history for .GitInfo and .Lastmod
- name: Setup Go
uses: actions/setup-go@v4
with:
go-version: '1.21.1'
- name: Install tcardgen
run: go install github.com/Ladicle/tcardgen
- name: Generate ogp images
run: |
mkdir -p static/ogp
files=`find ./content/posts/*/index.md -type f`
for f in $files; do
slugname=`dirname ${f} | xargs -I@ basename @ | cut -c 10-`
tcardgen --fontDir ogp/font --output "static/ogp/${slugname}.png" \
--template ogp/tcard/template.png ${f}
done
- name: Setup Hugo
uses: peaceiris/actions-hugo@v2
with:
hugo-version: 'latest'
# extended: true
- name: Build
run: hugo
- name: Deploy
uses: peaceiris/actions-gh-pages@v3
with:
deploy_key: ${{ secrets.ACTIONS_DEPLOY_KEY }}
external_repository: suzuna/blog
publish_dir: ./docs
publish_branch: main

tcardgenを改造する版

わたしはtcardgenを改造しましたので、上と少し違ったGitHub Actionsを動かしています。

tcardgenは、HugoのyamlのFront MatterのTitleだけでなく、CategoryとTag, Author, DateをOGP画像に含めます。

しかし個人的にCategory, Tag, Author, DateはOGP画像に含めなくていいと思ったのと、Authorの代わりにブログのタイトルを表示したかったので、tcardgenをforkしてソースをいじって実現しました。Goは全く分からないのでソースは汚いです。

本家のインストールのこちらの代わりに、

go install github.com/Ladicle/tcardgen@latest

自作のfork版をインストールします。

go install github.com/suzuna/tcardgen@latest

forkしてGoを書いていじれる人はこんな記事を見なくてもできると思いますが…

自作のfork版を使っているため、GitHub ActionsのInstall tcardgenとGenerate ogp imagesはさきほど紹介したものの代わりにこちらを使っています。Generate ogp imagesのtcardgenの実行部分に--topTitleや--bottomAuthorというオプションが付いているのは独自仕様です。

- name: Setup Go
uses: actions/setup-go@v4
with:
go-version: '1.21.1'
- name: Install tcardgen
run: go install github.com/suzuna/tcardgen
- name: Generate ogp images
run: |
mkdir -p static/ogp
files=`find ./content/posts/*/index.md -type f`
for f in $files; do
slugname=`dirname ${f} | xargs -I@ basename @ | cut -c 10-`
tcardgen --fontDir ogp/font --output "static/ogp/${slugname}.png" \
--template ogp/tcard/template.png --topTitle "" --bottomAuthor "suzuna's memo" ${f}
done

参考

うずらフォントもですが、BoldやMediumがないフォントの場合は、-Bold, -Mediumをファイル名につけた全く同じフォントを置く必要があります。tcardgenの内部でファイル名をパースしているからです。もちろん、そのようにしてBoldやMediumがないフォントを使うと、OGP画像のフォントの太さは当然すべて同じになります。 ↩︎
footer.htmlはthemes/hugo-theme-anubis/layouts/partials/footer.htmlにあるので、実際には、これをプロジェクトルートディレクトリ直下のlayouts/partials/footer.htmlにコピーし、そのコピーしたファイルに追加しました。theme/<テーマ名>/layouts/以下のファイルをlayouts以下のファイルで上書きできるので、テーマを編集する場合は後者を変更します。そうしないとテーマ本体のアップデートによって編集内容が上書きされてしまいます。 ↩︎

階層ベイズで東京23区のお部屋の家賃相場を推定する

Mon, 25 Dec 2023 00:00:00 +0900

はじめに

この記事は確率的プログラミング言語 Advent Calendar 2023の19日目の記事です。松浦先生、主催いただきありがとうございます。今回は参加できてうれしく思います。6日遅れての投稿で恐縮ですがどうぞよろしくお願いいたします。

SUUMOからスクレイピングした東京23区の20万件程度の賃貸物件のデータを用いて、最寄り駅で階層化した家賃の階層モデルをStanで実装して家賃相場を推定してみました。

スクレイピングはPython + requests + BeautifulSoup4、それ以降の分析パートはR + Stan (rstan) で実装しました。Stanの可視化にはbayesplotやtidybayesを使っています。

データ取得や前処理、可視化の部分がだいぶ長くなってしまいましたので、モデルの推定や結果については「モデリング」の章からご覧ください。

追記: 続きの記事を書きました。部屋の階数は家賃にどれだけ影響を与えるのか？ - suzuna's memo

モデリングの動機

部屋を探すとき、都心に住みたいけど高いなあ、じゃあこの路線沿いで都心から離れるほどどのくらい家賃相場が変わるの？とか、新築は高いなあ、築年数を広げるとどのくらい家賃が下がるの？とか、一度は考えたことはないでしょうか？

何々駅の家賃相場は1LDKでいくらという情報はググれば見つけられます。大まかな家賃相場を理解するために有用な情報なのですが、築年数や駅からの距離によって当然相場は変わってきます。築浅がいい、逆に古くてもいいから安くしたいとか、絶対駅近がいい、駅から離れていてもいいとか、人によって好みがあります。

また、築浅物件が多い街、そうではない街という違いもあります。単純に平均すると、築年数の影響で後者の街の家賃相場が下がってしまうので、築年数の影響を除いた相場も知りたいですね¹。

それに、例えば1LDKと言っても面積は物件によって様々です。40m2の1LDKと50m2の1LDKでは、他の条件が同じなら当然後者の方が高いです。なので、例えば最寄り駅がここで面積はいくつで築年数が何年で徒歩何分の物件はいくらかという情報が知りたくなるところです。

直感的には、同じ最寄り駅の物件に限定すると、家賃は面積の単調増加、築年数と最寄り駅からの徒歩分数の単調減少な関数であり、地価の違いからこの回帰直線は物件の最寄り駅によって上下動するように思われます。階層ベイズにぴったりのテーマのように思われます。

わたしが知りたいのは以下の内容です。

築年数が1年増えると家賃がどの程度下がるのか
駅からの徒歩分数が1分増えると家賃がどの程度下がるのか
築年数、徒歩分数、面積を固定したとき、最寄り駅によってどの程度家賃相場が変わるのか
面積を変えるとどの程度家賃相場が変わるのか

これが分かれば、任意の築年数、徒歩分数、面積、最寄り駅での家賃相場を推定することができます。

というわけで、自分が知りたくなったのでStanで実装してみました。

環境

R 4.3.1
rstan 2.32.3
bayesplot 1.10.0
tidybayes 3.0.6
furrr 0.3.1
MLmetrics 1.1.1

問題設定

目的変数と説明変数

対象は東京23区の賃貸物件です。

目的変数を家賃+管理費とするモデルを組むことにします。要するに毎月発生する費用です。敷金や礼金は考慮しないこととします²。以下断りがない限り「家賃」は「家賃+管理費」を指します。

使える説明変数は、SUUMOでスクレイピングした物件リストのページに存在する以下の項目です。今回のモデリングではこの中でも使っていない変数もあります。

住所（「東京都千代田区千代田1」の粒度まで）
専有面積
築年数
最寄り駅の路線、駅名、駅からの徒歩の分数
- 最大3つの最寄り駅が記載されている
間取り（1LDKとか）
建物の高さ（地上x階地下y階建てのxとy）
部屋の階数

敷金や礼金も取得できますが、説明変数には使用しません。敷金や礼金はたいてい家賃の0～2ヶ月分なので、これを説明変数に入れると家賃+管理費はある程度予測できてしまうからです。ある意味Leakageですね。

SUUMOの物件ごとのページには以下の項目も記載されていますが、このページもスクレイピングしようとするとスクレイピングにかかる時間が膨れ上がるため、今回はスクレイピングせず使用しませんでした。

部屋の特徴・設備
- バストイレ別や浴室乾燥機があるかどうか、角部屋かどうかなど
部屋の方角
建物の構造（鉄筋や鉄骨など）
近所のコンビニやスーパーマーケットなどの店名と物件からそこまでの距離
部屋の画像
敷金・礼金以外のその他の初期費用

分析の流れ

以下の流れで進めていきます。

データの取得（SUUMOのスクレイピング）
前処理
可視化（探索的データ分析）
可視化の結果をもとにモデルを定式化
MCMCでのモデルのパラメータ推定
パラメータが正しく推定できているかチェック
推定結果の解釈

データ取得

物件ごとの家賃と面積などのデータをSUUMOから2023年11月にスクレイピングしました³。

例えば、東京都千代田区の全ての物件は、こちらのページで見ることができます。このページを23区分、PythonのrequestsとBeautifulSoup4を用いてスクレイピングしました。一つの区について、ページネーションを1ページずつめくっていきます。1ページに50件物件が載っているので意外とサクサク取得できます。

数時間かけて129978件の建物における243544件の物件情報を収集しました。ただし、同じ物件が異なる建物名の部屋として重複して登録されていることがあり、その重複を除くと実際には211074件の物件となりました。

Rでスクレイピングしてもよかったですが、Pythonを使ったのは今回はPythonでのクラスや例外処理の勉強を兼ねたためでもあります。rvestも超優秀なパッケージです。

なお、上の一覧ページから各物件の詳細ページに飛ぶと、部屋の設備の有無などの詳細な情報を取得することができます。しかし、このページは物件の数だけページが存在するためにスクレイピングにかかる時間が長くなってしまうのでスクレイピングしていません。前のページが1ページに50件載っているのに対してこちらは1ページに1件なので、こちらも取得しようとするとさらに50倍の時間がかかります。

出力した結果のjsonファイルはこんな感じです。長いので折り畳んでいます。内容はダミーです。建物の数だけ”name”があり、“room”は同一の物件内の部屋の数だけあります。

jsonの中身

[
{
"type": "賃貸マンション",
"name": "hogehogeマンション",
"address": "東京都千代田区千代田１",
"moyorieki": [
"東京メトロ千代田線/大手町駅 歩5分",
"東京メトロ日比谷線/日比谷駅 歩6分",
"ＪＲ中央線/東京駅 歩10分"
],
"age": "築1年",
"story": "10階建",
"room": [
{
"floor": "3階",
"rent": "10万円",
"admin": "5000円",
"shikikin": "10万円",
"reikin": "-",
"layout": "ワンルーム",
"area": "25.05m2",
"link": "<物件ページへのリンク>"
},
{
"floor": "5階",
"rent": "12.5万円",
"admin": "10000円",
"shikikin": "12.5万円",
"reikin": "12.5",
"layout": "1LDK",
"area": "50.50m2",
"link": "<物件ページへのリンク>"
}
]
},
{
"type": "賃貸マンション",
（以下同様）
}
]

前処理

ここからはRで行います。

library(tidyverse)
library(rstan)
library(bayesplot)
library(tidybayes)
library(patchwork)
library(furrr)
library(MLmetrics)

上の章で出力したjsonファイルをdata.frameで読み込んでdfという変数に入れておきます。

まず建物名以外が全く同じで建物名のみ異なる物件が結構あります。これは重複とみなしてdplyr::distinct()でレコードを削除しています（32000件程度）。そのうえでいくつかの条件で物件を除外しています。

1.1個目の最寄り駅から徒歩ではない物件（バスや車） [1025件]
- 徒歩以外を考慮しようとすると手間がかかるから
- この除外により、最寄駅からバスや車という物件が多い駅の家賃を過大に評価しそうだが今回は単純に除外した
2.賃貸マンション、賃貸アパート以外の物件（一戸建てなど）[5392件]
- マンションやアパートとは同列に扱えないから
3.物件の階数の情報がない物件 [11件]
- “-”のようなパターン
4.物件の階数が建物の地上階の階数より高い物件、または地下階の高さより低い物件 [189件]
- 誤入力？

次に以下のロジックで前処理しました。正規表現とstringrで何とかしました。前処理あるあるなんですが、このコードのロジックで漏れなく前処理できているか？というのを逐一確かめながらコードを書いていくのが大変なんですよね。それでもSUUMOのデータはかなりきれいでした。

ward（区）: address（住所）から正規表現で区を抽出
area_str（面積）: “m2”を削除
age_str（築年数）: 「築x年」のxを抽出。「新築」なら0、「築99年以上」なら99とする
moyorieki_1（1個目の最寄り駅）から路線部分と駅名部分と徒歩x分のxをそれぞれ別のカラムに入れる
rent（家賃）, admin（管理費）, shikikin（敷金）, reikin（礼金）を万円単位で統一する。“-”は0とする
目的変数である家賃+管理費をrent_admin（万円）として列を足す
story（建物の階数）から地上階数と地下階数をそれぞれstory_aboveとstory_underとして取り出す。平屋は地上1階地下0階建てとする
floor（部屋の階数）から階数を取り出す
- 地下階はマイナスを付ける（例: “B2階”は-2とする）
- “1-2階”のような複数階にまたがるものは左側を採用（この例では1階とする）
- “3-1階”のようなパターンもあったが機械的に3階とした
適宜double型やinteger型に変換

前処理のコード

df2 <- df |>
# バスや車を除外
filter(str_detect(moyorieki_1, "駅 歩")) |>
filter(!str_detect(moyorieki_1, "駅 バス")) |>
# 「賃貸その他」、「賃貸テラス・タウンハウス」、「賃貸一戸建て」を除外
filter(type %in% c("賃貸マンション", "賃貸アパート")) |>
# 階が入っていないものを除外
filter(floor_str != "-")
df3 <- df2 |>
mutate(
ward=str_extract(address, "(?<=東京都).*?区")
) |>
mutate(
area=as.numeric(str_remove(area, "m2$"))
) |>
mutate(
age=case_when(
age_str == "新築" ~ 0L,
age_str == "築99年以上" ~ 99L,
str_detect(age_str, "^築[0-9]{1,2}年$") ~ as.integer(str_extract(age_str, "(?<=築)[0-9]{1,2}(?=年)"))
)
) |>
mutate(
moyorieki_1_railroad=str_extract(moyorieki_1, "^.*(?=/)"),
moyorieki_1_station=str_extract(moyorieki_1, "(?<=/).*駅"),
moyorieki_1_walk=as.integer(str_extract(moyorieki_1, "(?<=駅 歩).*(?=分)"))
) |>
mutate(
across(
c(rent, admin, shikikin, reikin),
~{
case_when(
.x == "-" ~ 0L,
str_detect(.x, "万円$") ~ as.numeric(str_extract(.x, "[0-9\\.]+(?=万円$)")),
str_detect(.x, "(?!=万)円$") ~ as.numeric(str_extract(.x, "[0-9\\.]+(?=円$)"))/10000
)
}
),
rent_admin=rent + admin
) |>
mutate(
story_above=case_when(
str_detect(story_str, "(?<=地上)[0-9]+(?=階建$)") ~ as.integer(str_extract(story_str, "(?<=地上)[0-9]+(?=階建$)")),
str_detect(story_str, "[0-9]+階建$") ~ as.integer(str_extract(story_str, "[0-9]+(?=階建$)")),
story_str == "平屋" ~ 1L
),
story_under=case_when(
str_detect(story_str, "(?<=^地下)[0-9]+") ~ as.integer(str_extract(story_str, "(?<=^地下)[0-9]+")),
story_str == "平屋" ~ 0L,
TRUE ~ 0L
)
) |>
mutate(
floor=case_when(
str_detect(floor_str, "^B[0-9]+階$") ~ as.integer(str_extract(floor_str, "[0-9]+")) * -1L,
floor_str == "B階" ~ -1L,
str_detect(floor_str, "B\\-.*階") ~ -1L,
str_detect(floor_str, "^[0-9]+階$") ~ as.integer(str_extract(floor_str, "[0-9]+")),
str_detect(floor_str, "^B[0-9]+\\-[BM]?[0-9]+階$") ~ as.integer(str_extract(floor_str, "(?<=B)[0-9]+")) * -1L,
str_detect(floor_str, "^[0-9]+\\-[BM]?[0-9]+階$") ~ as.integer(str_extract(floor_str, "^[0-9]+"))
)
)
df4 <- df3 |>
filter(floor >= story_under * -1, floor <= story_above) |>
select(
-moyorieki_1, -moyorieki_2, -moyorieki_3,
-age_str, -story_str, -floor_str,
-shikikin, -reikin
)

これをdf4として格納します。次の画像のようなdata.frameです。結果として204457件の物件が残りました。

可視化

ようやくきれいなテーブルデータができたので、ggplot2で色々プロットしてみます。

探索的データ分析の過程ではデュアルディスプレイの片面にRStudioとかVSCodeとかのIDE、もう片面にプロットを表示すると快適です。

間取り・面積の分布

1つの建物に3つの部屋の募集が掲載されていたら、物件数は3とカウントします。また、面積は150m2以上は150m2として扱います。

Code

p1 <- df4 |>
count(layout, name="count") |>
arrange(desc(count)) |>
ggplot(aes(forcats::fct_reorder(layout, count), count))+
theme_light()+
geom_bar(stat="identity", alpha=0.6, color="black")+
labs(x="layout（間取り）", y="物件数（部屋）")+
coord_flip()
p2 <- df4 |>
mutate(area=if_else(area >= 150, 150, area)) |>
ggplot(aes(area))+
theme_light()+
geom_histogram()+
scale_x_continuous(breaks=seq(0, 150, 50), minor_breaks=seq(0, 150, 10))+
labs(x="area（面積）", y="物件数（部屋）")
patchwork::wrap_plots(p1, p2, ncol=2)

11Kや14Kは1Kの誤入力でした。20m2～50m2あたりのゾーンがボリュームゾーンなんですね。

家賃・築年数の分布

左の家賃のグラフですが、外れ値でプロットが見づらくなるので家賃100万円以下の物件のみに絞ります。

Code

p1 <- df4 |>
ggplot(aes(rent_admin))+
theme_light()+
geom_histogram(binwidth=2)+
coord_cartesian(xlim=c(0, 100))+
scale_x_continuous(breaks=seq(0, 100, 10), minor_breaks=NULL)+
labs(x="rent_admin（家賃+管理費）", y="物件数（部屋）")
p2 <- df4 |>
ggplot(aes(age))+
theme_light()+
geom_histogram()+
scale_x_continuous(breaks=seq(0, 100, 10), minor_breaks=NULL)+
labs(x="age（築年数）", y="物件数（部屋）")
patchwork::wrap_plots(p1, p2, ncol=2)

家賃の分布は右に裾を引いた対数正規分布のような形をしています。

右の築年数の分布は20年と40年手前に崖があります。建物が満たすべき耐震基準は建築基準法で定められており、1981年以前に建築確認申請が行われた建物は「旧耐震基準」、それ以降の建物は「新耐震基準」、2000年以降の建物は「2000年基準」が適用されるそうです。後ろほど耐震基準が高まります。新耐震基準適用開始から40年、2000年基準適用開始から20年くらいになるので、20年や40年を目途に建て替えられているのかもしれません（建築は特に詳しくないので違うかもしれません。単なる推測です）。

面積と家賃の散布図（間取りで色分け）

点の色分けが分かりづらくなるので、1R, 1K, 1DK, 1LDK, 2K, 2DK, 2LDK以外の間取りをothersにまとめています。また、面積100m2以下、家賃50万円以下の物件のみをプロットします。

Code

df4 |>
mutate(
layout=if_else(layout %in% c("1K", "1R", "1LDK", "1DK", "2LDK", "2DK", "2K"), layout, "others")
) |>
ggplot(aes(area, rent_admin, color=layout))+
theme_light()+
geom_point(size=0.1)+
coord_cartesian(xlim=c(0, 100), ylim=c(0, 50))+
guides(colour=guide_legend(override.aes=list(size=6)))+
labs(x="area（面積）", y="rent_admin（家賃+管理費）")

面積が小さい方から1R（緑色）、1K（黄土色）、1DK（オレンジ色）、1LDK（黄緑色）、2LDK（紫色）は同じ直線に乗っているように見えます。つまり、これらの5個の間取りに関しては、面積と間取りは相関が非常に高く多重共線性を起こしそうなことを示します。

一方でちょっと見づらいですが、2K（青色）は1K～1DKと同じ面積なのに下の方に位置するように見えます。同じく2DK（水色）も1LDKと同じ面積なのに下の方にあります。

この理由は次のプロットで推測できます。

築年数の分布（間取り別）

上の散布図と同じデータを、築年数のヒストグラムで描きます。

Code

df4 |>
mutate(
layout=if_else(layout %in% c("1K", "1R", "1LDK", "1DK", "2LDK", "2DK", "2K"), layout, "others")
) |>
ggplot(aes(age))+
theme_light()+
geom_histogram()+
labs(x="age（築年数）", y="物件数（部屋）")+
theme(
strip.background=element_rect(color="black", fill="white"),
strip.text=element_text(color="black")
)+
facet_wrap(~layout, ncol=4)

すると、2Kと2DKは他の間取りと違い、築年数が25年～50年の間にピークがあることが分かります。

つまり、一つ前の面積と家賃の散布図における、「2Kは1Kや1DKと同じ面積なのに下の方に位置し、同様に2DKは1LDKと同じ面積なのに下の方に位置する」現象は、2Kと2DKは築年数が経過した物件が多いため、2Kは1Kや1DK、2DKは1LDKと同じ面積でも家賃が安いということだと推測できます。そうなら、間取りは説明変数から削除してもよさそうです。

以下のページにもあるのですが、間取りにも流行りがあるそうです。

面積と家賃の散布図（築年数別・徒歩分数別）

上で見た面積と家賃のプロットを150m2以下、200万円以下に広げて築年数で色分けしてみます。グラデーションを見やすくするため、築年数が40年以上は40年としています。右のプロットは面積と家賃を両方対数を取ったものです。

Code

p1 <- df3 |>
filter(area <= 150 & rent_admin <= 200) |>
mutate(age=if_else(age >= 40L, 40L, age)) |>
ggplot(aes(area, rent_admin, color=age))+
theme_light()+
geom_point(size=0.1)+
theme(legend.position="bottom")+
labs(x="area（面積）", y="rent_admin（家賃+管理費）")+
geom_vline(xintercept=10, color="purple")+
geom_vline(xintercept=100, color="black")+
geom_hline(yintercept=100, color="firebrick")
p2 <- df3 |>
filter(area <= 150 & rent_admin <= 200) |>
mutate(age=if_else(age >= 40L, 40L, age)) |>
ggplot(aes(log(area), log(rent_admin), color=age))+
theme_light()+
geom_point(size=0.1)+
theme(legend.position="bottom")+
labs(x="log(area)（面積の対数）", y="log(rent_admin)（家賃+管理費の対数）")+
geom_vline(xintercept=log(10), color="purple")+
geom_vline(xintercept=log(100), color="black")+
geom_hline(yintercept=log(100), color="firebrick")
patchwork::wrap_plots(p1, p2, ncol=2)

x=10, x=100, y=100にそれぞれ紫色、黒色、赤色の線を引いています。

右側の両対数プロットだと、築年数が増えるほど点が下方にシフトしているように見えますね。

左のプロットを見ると、面積が100m2（黒色の線）を超えるあたりからばらつきが大きくなっています。100m2を超える広い物件は家賃のメカニズムも変わってきそうです。23区で100m2のマンションはかなり広いです。面積がかなり大きいゾーンにも当てはめようとすると、ボリュームゾーンの25m2～50m2の物件の当てはまりが悪くなりそうなので、100m2を超える物件はモデルから除外することにします。また、100m2超はデータの誤入力っぽい物件もちらほらあるので、それを弾く意味もあります。

100m2以下の物件はほとんど100万円（赤色の線）以下に収まっていますね。いま、モデルには100m2以下の物件データのみを使うことにしたので、誤入力をはじく意味で家賃が100万円の物件も除外することにします。

また、右の対数のプロットを見ると、10m2（紫色の線）より左側は線形の関係が成り立っていなさそうです。このような狭い物件にも対数線形のモデルをフィットさせようとするのはやはり難しそうなので、10m2以下の物件も除外します。

次のプロットは、先ほどのプロットの色分けを最寄り駅からの徒歩分数にしたものです。ただし20分以上は20分にまとめています。

Code

p1 <- df3 |>
filter(area <= 150 & rent_admin <= 200) |>
mutate(moyorieki_1_walk=if_else(moyorieki_1_walk >= 20L, 20L, moyorieki_1_walk)) |>
ggplot(aes(area, rent_admin, color=moyorieki_1_walk))+
theme_light()+
geom_point(size=0.1)+
theme(legend.position="bottom")+
labs(x="area（面積）", y="rent_admin（家賃+管理費）")+
geom_vline(xintercept=10, color="purple")+
geom_vline(xintercept=100, color="black")+
geom_hline(yintercept=100, color="firebrick")
p2 <- df3 |>
filter(area <= 150 & rent_admin <= 200) |>
mutate(moyorieki_1_walk=if_else(moyorieki_1_walk >= 20L, 20L, moyorieki_1_walk)) |>
ggplot(aes(log(area), log(rent_admin), color=moyorieki_1_walk))+
theme_light()+
geom_point(size=0.1)+
theme(legend.position="bottom")+
labs(x="log(area)（面積の対数）", y="log(rent_admin)（家賃+管理費の対数）")+
geom_vline(xintercept=log(10), color="purple")+
geom_vline(xintercept=log(100), color="black")+
geom_hline(yintercept=log(100), color="firebrick")
patchwork::wrap_plots(p1, p2, ncol=2)

築年数と同様、徒歩分数が増えると点が下方にシフトしているように見えます。これは、対数家賃を対数面積で回帰するモデルを組むと、築年数と徒歩分数はこの回帰式の項に加えられることを示唆します。

面積と家賃の散布図（最寄り駅別・築年数で色分け）

23区の各区ごとに最も物件数が多い最寄り駅の物件について、築年数で色分けして面積と家賃の散布図を描いてみます。グラデーションを見やすくするため、築年数が40年以上は40年としています。面積は100m2以下、家賃は50万円以下に絞っています。

Code

top_stations_in_each_ward <- df4 |>
count(ward, moyorieki_1_station, name="n") |>
group_by(ward) |>
mutate(rank=dense_rank(desc(n))) |>
filter(rank == 1) |>
pull(moyorieki_1_station)
df4 |>
filter(moyorieki_1_station %in% top_stations_in_each_ward) |>
mutate(age=if_else(age >= 40L, 40L, age)) |>
ggplot(aes(area, rent_admin, color=age))+
theme_light()+
geom_point(size=1)+
coord_cartesian(xlim=c(0, 100), ylim=c(0, 50))+
labs(x="area（面積）", y="rent_admin（家賃+管理費）")+
theme(
strip.background=element_rect(color="black", fill="white"),
strip.text=element_text(color="black")
)+
facet_wrap(~moyorieki_1_station, ncol=4)

恵比寿と麻布十番は高いですね。神田や勝どきも高いし、濃い色の点が多いので築浅物件が多そうです（実際、駅別に築年数のヒストグラムを描くとその通りです）。

次のプロットで面積と家賃をそれぞれ自然対数を取って描き直してみると、駅によって面積と家賃の傾きが違う直線に乗り、また対数を取る前より面積が大きいゾーン（x軸の右の方）のばらつきが抑えられたことが分かります。

Code

df4 |>
filter(moyorieki_1_station %in% top_stations_in_each_ward) |>
mutate(age=if_else(age >= 40L, 40L, age)) |>
ggplot(aes(log(area), log(rent_admin), color=age))+
theme_light()+
geom_point(size=1)+
labs(x="log(area)（面積の対数）", y="log(rent_admin)（家賃+管理費の対数）")+
theme(
strip.background=element_rect(color="black", fill="white"),
strip.text=element_text(color="black")
)+
facet_wrap(~moyorieki_1_station, ncol=4)

徒歩分数の分布

1個目の最寄り駅（物件ページの一番上に書いてある最寄り駅）からの徒歩分数の1分刻みのヒストグラムです。ただし30分以上の場合は30分としています。

5分と10分が多く見えます。物件サイトで検索するときは駅から5分以内や10分以内でフィルターをかけて検索することが多いので、駅から10分以上かかるような最寄り駅と駅からギリギリ10分という最寄り駅があったら、後者を最寄り駅として書くのかもしれません。

Code

df4 |>
mutate(moyorieki_1_walk=if_else(moyorieki_1_walk >= 30L, 30L, moyorieki_1_walk)) |>
ggplot(aes(moyorieki_1_walk))+
theme_light()+
geom_histogram(binwidth=1)+
labs(x="moyorieki_1_walk（1個目の最寄り駅からの徒歩分数）", y="物件数（部屋）")+
theme(
strip.background=element_rect(color="black", fill="white"),
strip.text=element_text(color="black")
)+
facet_wrap(~ward, ncol=4, scales="free_y")

モデリング

モデルの設計

長かったですが、可視化の結果とドメイン知識を踏まるとこんな感じです。改めてですが、断りがない限り「家賃」は「家賃+管理費」を指します。

横軸を面積、縦軸を家賃に取ると、最寄り駅によって切片と傾きが違う
面積と間取りは家賃に与える情報が被りそう
築年数や徒歩分数が増えるほど家賃は下がる

2つ目はちょっとだけ意外かもしれませんが、そりゃそうだよねという感じです。可視化の結果誰も知らないことが分かることはあまりなく、えてして皆が知っていることをデータから再確認するものなのです。

同じ面積でも最寄り駅によって家賃は違いそうです。また、面積が2倍になればある最寄り駅の物件では家賃が1.5倍になるかもしれないし、ある最寄り駅では3倍になるかもしれないですね。

築年数は1年増えるごとに、徒歩分数は1分増えるごとに定数が乗算されて家賃が下がるモデルにしてみます。つまり新築で10万円の物件なら築5年で9万円、築10年で8万円として、新築で20万円の物件なら築5年で18万円、築10年なら16万円というイメージでしょう。家賃の絶対水準が違うからですね。

これは築年数や徒歩分数は家賃の対数に対して負の線形の関係があるということです。特に築年数に関して言うと、建物は一年あたりの減価率の年数乗で減価するというのは直感（ドメイン知識）と合っています。減価償却の定率法的な感じです。

ここまで書いたことを以下のようにモデルで表現してみました。

物件$i(1, \dots, N)$の最寄り駅（SUUMOの物件ページで一番上に書いてある1番目の最寄り駅）を$sta[i] (1, \dots, S)$とします。

$$ \begin{align*} \log{y_{i}} & \sim N(\mu_{i}, \sigma) \\\ \mu_{i} &= a_{sta[i]} + b_{sta[i]} \log{\mathrm{area}_{i}} \\\ &+ \beta_{\mathrm{age}} \mathrm{age}_{i} + \beta_{\mathrm{walk}}(\mathrm{walk}_{i} - 1) \\\ a_{sta[i]} & \sim N(a_{all}, \sigma_{a_{all}}) \\\ b_{sta[i]} & \sim N(b_{all}, \sigma_{b_{all}}) \\\ \end{align*} $$

ただし、物件$i$について、それぞれ以下の通りとします。

$y_{i}$: 家賃+管理費（万円）
$\mathrm{area}_{i}$: 面積（m2）
$\mathrm{age}_{i} (0 \leq \mathrm{age}_{i} \leq 40)$: 築年数（年、整数）。新築は0年とする
$\mathrm{walk}_{i} (1 \leq \mathrm{walk}_{i} \leq 20)$: 最寄り駅からの徒歩分数（分、整数）。徒歩0分という物件はない

最寄り駅が$sta[i]$, 面積が$\mathrm{area}_{i}$（m2）, 築年数が$\mathrm{age}_{i}$（年）, 最寄り駅から徒歩$\mathrm{walk}_{i}$（分）の物件$i$について、その家賃（管理費込み）の対数$\log{y_{i}}$（万円）は、平均$\mu_{i}$, 標準偏差$\sigma$の正規分布に従うと仮定したモデルです。ただし、最寄り駅が複数あっても1個しか考慮しません。要するに物件の最寄り駅で階層化した面積のランダム切片＋ランダム係数モデルに、築年数と最寄り駅からの徒歩分数による減価要素を入れたものです。

このとき、この最寄り駅、面積、築年数、徒歩分数での条件における物件の対数家賃の相場は$\mu_{i}$万円であると考えます。

最寄り駅ごとに回帰直線を別々に推定するのではなく階層モデルにすると何がうれしいのかというと、サンプル数の少ない駅でも全体の傾向を借用してパラメータを推定することができます。これを縮約といいます。また、各最寄り駅のパラメータ$a_{sta[i]}, b_{sta[i]}$は、$a_{all}, b_{all}$という全ての最寄り駅の「平均的な」パラメータから$\sigma_{a_{all}}, \sigma_{b_{all}}$だけばらつくという、ドメイン知識に合ったメカニズムを組み込むことができるのもメリットです。

なお、$y_{i}$と$area_{i}$は対数変換しない選択肢もありますが、いま定式化したように、家賃 + 管理費 = (a + b * 面積) * 築年数効果 * 徒歩分数効果という右辺が乗算のモデルを考えるなら、左辺を対数変換すると右辺を加算の関係に変換することができるので、StanでのMCMCが収束しやすいというメリットもあります。a*築年数効果のようなパラメータ同士の積があると収束しにくいです。

モデルに投入するデータ

投入するデータは、SUUMOに掲載されている東京23区のデータのうち、以下を除外した178113件のデータです。

1.1個目の最寄り駅から徒歩ではない物件（バスや車） [1025件]
2.賃貸マンション、賃貸アパート以外の物件（一戸建てなど）[5392件]
3.物件の階数の情報がない物件 [11件]
4.物件の階数が建物の地上階の階数より高い物件、または地下階の高さより低い物件 [189件]
5.家賃+管理費が100万円を超える物件 [1286件]
6.面積が100m2を超える物件 [436件]
7.面積が10m2未満の物件 [1033件]
8.築年数が40年を超える物件 [22565件]
- 40年超の物件は数が減るため
9.1個目の最寄り駅からの徒歩分数が20分を超える物件 [1852件]
- 8と同様

1～4は可視化の時点で既に除外していました。5～9は可視化の結果を踏まえてモデルの推定では追加で除外することにしました。

徒歩分数の方はともかく築年数の方は全体の1割なので少なくはないですが、今回は築年数が40年まで見られれば自分の関心を満たせるということでいったん40年で切りました。可視化の章で述べた通り40年を目安に適用される建築基準法が異なる問題もあるので、家賃相場の傾向も変わってくる可能性があります。40年で分けて考えるのは悪くなさそうです。

Stanの実装

以下のコードです。

data {
int N; // 物件の数
vector[N] Y; // 物件nの家賃+管理費
vector[N] AREA; // 物件nの面積
int S; // 最寄り駅の数
int<lower=1, upper=S> STATION[N]; // 物件nの最寄り駅index
vector[N] AGE; // 物件nの築年数（lower=0, upper=40の整数）
vector[N] WALK; // 物件nの徒歩分数（lower=1, upper=20の整数）
}
parameters {
real a0; // 面積の切片の全体平均
real b0; // 面積の傾きの全体平均
vector[S] a;
vector[S] b;
real<upper=0> age_b;
real<upper=0> walk_b;
real<lower=0> sigma_a;
real<lower=0> sigma_b;
real<lower=0> sigma; // 物件ごとのばらつき
}
model {
// 最寄り駅による面積の階層効果
a ~ normal(a0, sigma_a);
b ~ normal(b0, sigma_b);
log(Y) ~ normal(a[STATION] + b[STATION] .* log(AREA) + age_b*AGE + walk_b*(WALK - 1), sigma);
}

事前分布は無情報事前分布です。

全体平均のa0とb0を正規分布の平均として織り込むというのは階層モデルのMCMC推定の高速化と収束しやすくするテクニックです。アヒル本（StanとRでベイズ統計モデリング）の8.1.6章を参考にしました。

高速化のためにベクトル化しているので少し分かりづらいですが、ベクトル化しないと以下のコードです。

model {
for (s in 1:S) {
a[s] ~ normal(a0, sigma_a);
b[s] ~ normal(b0, sigma_b);
}
for (n in 1:N) {
log(Y[n]) ~ normal(a[STATION[n]] + b[STATION[n]]*log(AREA[n]) + age_b*AGE[n] + walk_b*(WALK[n] - 1), sigma);
}
}

このコードを”model.stan”で保存して以下のRコードでキックします。chains=4, iter=5000, warmup=1000で約12時間かかりました。

Code

# 特徴量生成
df_mod <- df4 |>
filter(rent_admin <= 50 & area <= 100) |>
filter(moyorieki_1_walk <= 20 & age <= 40) |>
# Stanに渡すために最寄り駅 (character) をfactorを経由してintegerにする
mutate(moyorieki_1_station_index=as.integer(as.factor(moyorieki_1_station)))

# 上はMCMCの並列化、下はstanコードが変わらない限り再コンパイルしない
options(mc.cores=parallel::detectCores())
rstan::rstan_options(auto_write=TRUE)
# Stanコードのコンパイル
mod <- rstan::stan_model("model.stan")
# MCMCの実行
fit <- rstan::sampling(
mod,
data=list(
N=nrow(df_mod),
Y=df_mod$rent_admin,
AREA=df_mod$area,
S=length(unique(df_mod$moyorieki_1_station_index)),
STATION=df_mod$moyorieki_1_station_index,
AGE=df_mod$age,
WALK=df_mod$moyorieki_1_walk
),
chains=4, iter=5000, warmup=1000, thin=1, refresh=10, seed=1234
)

デフォルトではiter/10ごとにprogressが出力されますが、MCMCの推定に時間がかかるようなモデルの場合は中々出力されず不安になるのでrefreshに小さい値を指定しておくことで細かくprogressを表示しておくといいです。

推定結果のチェック

MCMCのチェック

StanのMCMCが終わったら、パラメータが正しく推定されていることを確かめるために、以下をチェックします。bayesplotを使うと簡単にプロットできます。

トレースプロットが混ざり合っていること
- MCMCで生成されたパラメータのサンプルが初期値によらず同じ値に収束しているか（＝局所解に落ちていないか）の確認
Rhat < 1.1であること
- 上の収束の度合いを数値で表したもの
有効サンプルサイズn_effが大きいこと
- サンプルが互いに独立であることを示す（＝定常な分布に収束している）
- 目安はサンプル数で割った値が0.1以上
パラメータのサンプルに自己相関がないこと
- 上を自己相関係数のプロットで示したもの

事後診断の詳細はこちらの素晴らしい記事も参考にさせていただきました。

[R] [stan] bayesplot を使ったモンテカルロ法の実践ガイド - ill-identified diary

以下にプロットを載せます。きれいなプロットで全てよさそうです。

スペース的に全部のパラメータを載せることは難しいのでトレースプロット（1枚目）と自己相関（4枚目）で描くパラメータは一部のパラメータに絞っていますが、他のパラメータも問題ありませんでした。

# トレースプロット
bayesplot::mcmc_trace(fit, pars=c("a0", "b0", "age_b", "walk_b"))

# Rhatのヒストグラム
bayesplot::mcmc_rhat_hist(bayesplot::rhat(fit))

# n_eff/Nのヒストグラム
bayesplot::mcmc_neff_hist(bayesplot::neff_ratio(fit))

# 自己相関係数のプロット
bayesplot::mcmc_acf_bar(fit, pars=c("a0", "b0", "age_b", "walk_b"))

モデルの当てはまりのチェック

MCMCのサンプリングがうまく収束したことは分かりましたが、そもそも今回設定したモデルは現実の家賃データに当てはまっているのか？ということを確かめます。

これは、Stanのgenerated quantitilesブロックに以下のように書いてStan上で予測値を生成すればいいです。

generated quantities {
vector[N] y_pred;
for (n in 1:N) {
y_pred[n] ~ exp(normal_rng(a[STATION[n]] + b[STATION[n]] * log(AREA[n]) + age_b*AGE[n] + walk_b*(WALK[n] - 1), sigma));
}
}

しかし、N=18万弱のy_predそれぞれについて、(5000 (iter) - 1000 (warmup)) / 1 (thin) * 4 (chain) = 16000個（draw）の予測値をStanで生成するため、rstan::extract(fit)$y_predは16000 x 18万弱のmatrixとなります。これではrstan::sampling()の返り値はとんでもなく大きいサイズのオブジェクトになってしまいます。

大まかな事後予測チェックには予測値はそんなにたくさんなくてもいいと思い、Stanで上のコードを書くのではなく、Rでパラメータの事後分布からサンプリングして予測値を100個生成することにしました。要するに100 x 18万弱のmatrixを作る（このサイズのmatrixでも150MBあります）ということです。（Stanコードでgenerated quantitiesの予測値をdraw個ではなく100個など任意の個数に絞る方法はあるのでしょうか…）

furrrで並列化して10秒くらいで生成できました。

Code

# MCMCのサンプルを取り出す
# matrix (draws x stations)
sample_a <- rstan::extract(fit, "a")$a
sample_b <- rstan::extract(fit, "b")$b
# vector (length = draws)
sample_age_b <- rstan::extract(fit, "age_b")$age_b
sample_walk_b <- rstan::extract(fit, "walk_b")$walk_b
sample_sigma_a <- rstan::extract(fit, "sigma_a")$sigma_a
sample_sigma_b <- rstan::extract(fit, "sigma_b")$sigma_b
sample_sigma <- rstan::extract(fit, "sigma")$sigma
# 予測値の中央値を求める関数（n_pred個の予測値を作る）
calc_pred <- function(station_idx, area, age, walk, n_pred, seed) {
mu <- sample_a[,station_idx] + sample_b[,station_idx]*log(area) + sample_age_b*age + sample_walk_b*(walk - 1)
mu2 <- withr::with_seed(seed, sample(mu, size=n_pred))
sigma2 <- withr::with_seed(seed, sample(sample_sigma, size=n_pred))
map2_dbl(mu2, sigma2, function(x, y) {
withr::with_seed(seed, rnorm(1, mean=x, sd=y))
})
}
station_idxs <- df_mod$moyorieki_1_station_index
areas <- df_mod$area
ages <- df_mod$age
walks <- df_mod$moyorieki_1_walk
rent_admins <- df_mod$rent_admin
variables <- list(
station_idx=station_idxs,
area=areas,
age=ages,
walk=walks
)
# 予測値を求める
future::plan(future::multisession)
y_preds <- furrr::future_pmap(
variables,
function(station_idx, area, age, walk) {
calc_pred(station_idx, area, age, walk, n_pred=100, seed=1234)
},
.progress=TRUE,
.options=furrr::furrr_options(seed=1234)
)
# bayesplotに渡すためにsample (n_pred) x data length (180000)のmatrixに変換する
y_pred <- simplify2array(y_preds)

以下は調整済みではない決定係数です。1個目の結果は家賃の対数との比較、2個目は対数ではない家賃との比較です。trainとtestのsplitはしていないので、学習データ内での決定係数です。予測値を100個しか作っていないので参考程度ですが、0.91程度なので悪くないでしょう。

MLmetrics::R2_Score(apply(y_pred, 2, median), log(rent_admins))

#> [1] 0.9294308

MLmetrics::R2_Score(apply(exp(y_pred), 2, median), rent_admins)

#> [1] 0.9082848

次は予測値（横軸）と実際の値（縦軸）のプロットです。左のプロットは対数家賃、右は対数を外した家賃です。

Code

patchwork::wrap_plots(
bayesplot::ppc_scatter_avg(log(rent_admins), y_pred, size=0.1)+
geom_abline(slope=1, intercept=0)+
labs(title="対数家賃"),
bayesplot::ppc_scatter_avg(rent_admins, exp(y_pred), size=0.1)+
geom_abline(slope=1, intercept=0)+
labs(title="家賃"),
ncol=2
)

左の対数家賃が45度線上に載っています。

次は残差のプロットです。横軸は面積、縦軸は残差（予測値-実際の値）です。

Code

patchwork::wrap_plots(
bayesplot::ppc_error_scatter_avg_vs_x(log(rent_admins), y_pred, df_mod$area, size=0.1)+
labs(title="対数家賃")+
geom_vline(xintercept=0)+
scale_y_continuous(breaks=seq(0, 100, 20)),
bayesplot::ppc_error_scatter_avg_vs_x(rent_admins, exp(y_pred), df_mod$area, size=0.1)+
labs(title="家賃")+
geom_vline(xintercept=0)+
scale_y_continuous(breaks=seq(0, 100, 20)),
ncol=2
)

左の図を見ると、y=0の直線の上下にだいたい均等に分布しているので、回帰モデルの前提である残差の等分散性と正規性がだいたい満たされていそうです。おおむね悪くなさそうです。

ただ、x <= 15m2くらいの面積が小さいゾーンで縦軸が正の点が多いことが分かります。つまり15m2を切るような物件では過少に予測しがちということですね。10m2未満の物件を除外しましたが、除外する閾値を15m2に上げてもよかったかもしれません。

また、70m2～以上の物件も同様に過少に予測しがちでした。この面積帯はファミリー向けなので、一人暮らし～二人暮らしゾーンの20～60m2程度の物件とはちょっとメカニズムが違うのかもしれません。

結果

ようやく結果を見るところまでたどり着きました。こちらが推定されたパラメータの結果です。ただしprintが長くなるのでa[s], b[s]は省略します。

print(fit, pars=c("a0", "b0", "age_b", "walk_b", "sigma_a", "sigma_b", "sigma"), digits_summary=3)

#> Inference for Stan model: anon_model.
#> 4 chains, each with iter=5000; warmup=1000; thin=1;
#> post-warmup draws per chain=4000, total post-warmup draws=16000.
#>
#> mean se_mean sd 2.5% 25% 50% 75% 97.5% n_eff Rhat
#> a0 -0.101 0 0.015 -0.131 -0.111 -0.101 -0.091 -0.071 25141 1
#> b0 0.804 0 0.006 0.792 0.800 0.804 0.808 0.817 22027 1
#> age_b -0.011 0 0.000 -0.011 -0.011 -0.011 -0.010 -0.010 17203 1
#> walk_b -0.009 0 0.000 -0.009 -0.009 -0.009 -0.009 -0.009 28102 1
#> sigma_a 0.313 0 0.011 0.292 0.306 0.313 0.321 0.337 20686 1
#> sigma_b 0.137 0 0.005 0.128 0.133 0.136 0.140 0.146 26200 1
#> sigma 0.125 0 0.000 0.125 0.125 0.125 0.125 0.126 15352 1
#>
#> Samples were drawn using NUTS(diag_e) at Sun Dec 24 15:16:08 2023.
#> For each parameter, n_eff is a crude measure of effective sample size,
#> and Rhat is the potential scale reduction factor on split chains (at
#> convergence, Rhat=1).

築年数効果

以下、点推定値としてmedianを採用します⁴。$\beta_{\mathrm{age}}$ = -0.011でした。これは、築年数が1年増えるごとに、家賃+管理費の対数が0.011小さくなることを意味します。

と言われてもよく分からないですね。また、築年数が$m$年の物件は新築と比べてどの程度家賃が下がるのかも知りたいです。

この疑問に答えるには、$\mathrm{age}_{i} = 1, \dots, 40$としたときの$\exp (\beta_{\mathrm{age}} \mathrm{age}_{i})$の事後中央値と95%ベイズ信用区間を求めればよいです。tidybayes::spread_draws()を使うとrstan::sampling()の返り値からサンプルをtidyな形で取り出すことができて計算が楽です。

Code

tidy_draws <- tidybayes::spread_draws(fit, age_b, walk_b, sigma_a, sigma_b, sigma)
age_b <- tidy_draws |>
pull(age_b)
# 1年 - 40年
res_age <- 1:40 |>
map_dfr(\(age) {
samples <- exp(age_b * age)
tibble::tibble(
age=age,
median=quantile(samples, 0.5),
lower=quantile(samples, 0.975),
upper=quantile(samples, 0.025)
)
})
# きりのいいageだけ表示する
res_age |>
filter(age %in% c(0:5, seq(5, 40, 5))) |>
print(n=15)

#> # A tibble: 12 × 4
#> age median lower upper
#> <int> <dbl> <dbl> <dbl>
#> 1 1 0.990 0.990 0.990
#> 2 2 0.979 0.979 0.979
#> 3 3 0.969 0.969 0.969
#> 4 4 0.959 0.959 0.959
#> 5 5 0.949 0.949 0.949
#> 6 10 0.900 0.901 0.900
#> 7 15 0.854 0.855 0.854
#> 8 20 0.810 0.811 0.810
#> 9 25 0.769 0.770 0.768
#> 10 30 0.730 0.731 0.729
#> 11 35 0.692 0.693 0.691
#> 12 40 0.657 0.658 0.656

medianは事後分布の中央値、upperとlowerは95%CIの上限と下限です。

medianの列の通り、築年数が1年増えるごとに家賃は0.99倍になります。新築の物件と比較すると、築5年の物件で5%、10年で10%、15年で15%、20年で19%家賃が下がります。築25年くらいまではほぼ1年で1%減ると近似できて覚えやすいです⁵。これは参考にできそうな知見ですね。個人的に参考にしようと思いました。

物件数が18万件と多いおかげでサンプルの標準誤差が小さいためにmedianもupperもlowerもほぼ一致しています。データ数は正義。

次の徒歩分数や最寄り駅別の家賃相場の結果も同様ですが、「築年数が1年増えるごとに家賃は0.99倍」というのは今回設定したモデルでの数値であって、モデルの設定が変われば数値も変わることに注意してください。

最寄り駅からの徒歩分数効果

最寄り駅からの徒歩分数が伸びるとどの程度家賃が下がるのでしょうか？築年数効果と同じように、$\mathrm{walk}_{i} = 2, \dots, 20$としたときの$\exp (\beta_{\mathrm{walk}} (\mathrm{walk}_{i} - 1))$の事後中央値と95%ベイズ信用区間を求めれば分かります。

Code

walk_b <- fit |>
tidybayes::spread_draws(walk_b) |>
pull(walk_b)
# 2分 - 20分
res_walk <- 2:20 |>
map_dfr(\(walk) {
samples <- exp(walk_b * (walk - 1))
tibble::tibble(
walk=walk,
median=quantile(samples, 0.5),
lower=quantile(samples, 0.975),
upper=quantile(samples, 0.025)
)
})
# きりのいいwalkだけ表示する
res_walk |>
filter(walk %in% c(2, 3, 5, 10, 15, 20)) |>
print()

#> # A tibble: 6 × 4
#> walk median lower upper
#> <int> <dbl> <dbl> <dbl>
#> 1 2 0.991 0.991 0.991
#> 2 3 0.982 0.982 0.982
#> 3 5 0.964 0.965 0.964
#> 4 10 0.921 0.923 0.920
#> 5 15 0.880 0.882 0.878
#> 6 20 0.841 0.844 0.838

駅からの徒歩分数が1分増えるごとに家賃は0.991倍になります。駅から徒歩1分の物件と比較すると、家賃は徒歩5分の物件で4%、10分で8%、15分で12%、20分で16%下がるようです。

ただし、新築と築数年や、徒歩1分と徒歩5分などはもう少しだけ離れていても不思議ではないかなという気もします。

最寄り駅別の家賃相場（面積固定）

最寄り駅によってどの程度家賃が変わるか見てみましょう。同一の路線内で見るとイメージが付いて面白いです。

実際のところ、新築で徒歩1分の物件はあまりないので相場感をイメージしづらいですね。現実的なところで築5年、徒歩5分で30m2の物件の相場を見てみましょう。これは$\mathrm{area}_{i} = 30, \mathrm{age}_{i} = 5, \mathrm{walk}_{i} = 5$としたときの$\exp(\mu_{i})$の事後中央値と95%ベイズ信用区間を計算します。

京王線・京王新線です。新宿から西の方に伸びる路線ですね。北の方にJR中央線、南の方に小田急線が並行して走っています。

Code

# 駅名とモデルに投入したindexのマッピング
sta_chr_idx_table <- df_mod |>
select(moyorieki_1_station, moyorieki_1_station_index) |>
distinct(moyorieki_1_station, .keep_all=TRUE)
# 駅名があればそのindex, なければNA_integer_を返す
station_to_idx <- function(station_name) {
chr <- sta_chr_idx_table$moyorieki_1_station
idx <- sta_chr_idx_table$moyorieki_1_station_index
if (length(idx[which(chr==station_name)]) == 0) {
return(NA_integer_)
} else {
return(idx[which(chr==station_name)])
}
}
tidy_draws_by_idx <- tidybayes::spread_draws(fit, a[idx], b[idx], age_b, walk_b, sigma_a, sigma_b)
stations <- c(
"新宿駅", "初台駅", "幡ヶ谷駅", "笹塚駅", "代田橋駅", "明大前駅", "下高井戸駅", "桜上水駅", "上北沢駅", "八幡山駅", "芦花公園駅", "千歳烏山駅"
)
# factor型で駅の路線順に並べる
stations_fct <- forcats::fct_relevel(as.factor(stations), stations)
# 見る駅名のindex（stanのa[s]やb[s]のs）
idxs <- map_int(stations, station_to_idx)
area <- 30
age <- 5
walk <- 5
p1 <- tidy_draws_by_idx |>
filter(idx %in% idxs) |>
# 駅のindexではなく駅名をプロットに付けるためにindexと駅名のテーブルをjoinする
left_join(
df_mod |>
filter(moyorieki_1_station %in% stations) |>
distinct(moyorieki_1_station, .keep_all=TRUE) |>
select(moyorieki_1_station, moyorieki_1_station_index) |>
rename(station=moyorieki_1_station, idx=moyorieki_1_station_index) |>
mutate(station=forcats::fct_relevel(station, stations)),
by="idx"
) |>
mutate(mu_exp=exp(a+b*log(area)+age_b*age+walk_b*(walk-1))) |>
ggplot(aes(mu_exp, station))+
theme_light()+
tidybayes::stat_pointinterval(point_interval=tidybayes::median_qi, .width=0.95)+
scale_x_continuous(breaks=0:20)+
theme(axis.title.y=element_blank())+
labs(
title="exp(mu_i) (age_i=5, walk_i=5, area_i=30)",
subtitle="point: estimated (median), bar: 95% bayesian CI",
x="exp(mu_i)",
y="station"
)
p2 <- df_mod |>
filter(moyorieki_1_station %in% stations) |>
count(moyorieki_1_station, moyorieki_1_station_index, name="n") |>
rename(station=moyorieki_1_station, idx=moyorieki_1_station_index) |>
mutate(station=forcats::fct_relevel(station, stations)) |>
arrange(station) |>
ggplot(aes(station, n))+
theme_light()+
geom_bar(stat="identity", color="black", fill="gray", alpha=0.6)+
scale_y_continuous(breaks=seq(0, 2000, 500), minor_breaks=seq(0, 2000, 100))+
geom_text(aes(label=n, y=100))+
theme(axis.title.y=element_blank())+
coord_flip()+
labs(
title="（参考）物件数",
subtitle="築40年以下, 徒歩20分以下, 10m2-100m2の物件のみ"
)
patchwork::wrap_plots(p1, p2, ncol=2, widths=c(3, 2))

y軸は路線図の順番通りに駅を並べています。物件数も合わせて示しているのは、そもそもそのエリアに物件がどのくらいあるのかという参考です。なお、家賃相場のモデルには路線名を入れていないので、左のプロットの推定家賃相場は京王線の新宿もJRなどの他の路線の新宿も同じになります。また、最寄り駅が新宿駅という物件数には、京王線以外の新宿駅が最寄り駅の物件も含まれています。

左の図の点は事後中央値、点の左右の棒は95%ベイズ信用区間です。今回設定したモデルの下では、新宿から徒歩5分、築5年の30m2の物件の相場は17.4万円（95%CI: 17.1万円-17.8万円）ということです。

今回設定したモデルの下では「新宿から徒歩5分の築5年の30m2の物件の家賃の平均的な姿」というパラメータがあり、これに「新宿から徒歩5分の築5年の30m2の物件の家賃相場」と名付けるなら、「家賃相場」の確率分布の95%は17.1万円-17.8万円の間に入るということを意味します。繰り返しですがモデル式が変われば図で示した家賃相場の数値は当然変わります。新宿から徒歩5分、築5年、30m2の実際の物件を集めて中央値を取ったら17.4万円でしたということでもありません。

また、実際に観測される物件の家賃は、家賃相場にさらに$\sigma$というノイズが乗ります⁶。モデルに入れていない特徴量による物件の特徴での加算・減算分や、その他の説明のつかなかった色々なものを示します。なので、新宿から徒歩5分の築5年の30m2の物件の実際の家賃は、その95%が17.1万円-17.8万円の間に入るということではなく、17.1万円より小さいものから17.8万円より大きいものまでもっとあります。信用区間と予測区間の違いですね。

この図に限らず知っている駅や路線をいくつか見てみると、だいたいの金額や駅間の相対的な水準はそんなに外してはいないかなと思いました。

図に戻りますが、直感通り、新宿から遠ざかるほど相場が下がっていきます。明大前と代田橋は明大前の方が新宿から遠いですが、明大前の方が少し高いのは特急～各駅の全ての列車が止まること、井の頭線も通っているので渋谷や吉祥寺に出やすいからでしょうか。同様に千歳烏山は芦花公園より高いですが、千歳烏山も全ての列車が止まることが理由でしょうか。ただし95%ベイズ信用区間が広くて被っているので明確に差があるとは言いづらいです。

千歳烏山の次の駅は仙川です。千歳烏山と仙川の間の東側が世田谷区、西側が調布市です。23区の物件をスクレイピングした都合上、最寄り駅が仙川という物件のうち、世田谷区にある物件しかデータに存在しません。これが仙川の推定値にどの程度影響を与えるか分からないので、仙川の相場は表には載せませんでした。

わたし的には幡ヶ谷～桜上水がよさそうで気になりました。13.5万円前後の幡ヶ谷と笹塚は新宿まで5分、12.5万円の明大前は新宿と渋谷に10分で出られます。12万円弱の桜上水は駅の数としては新宿から離れますが急行が止まるので新宿まで15分です。閑静な住宅街という街ですね。安いかと言われるとどこも安くはないですが、新宿へのアクセスの良さを考えるとなかなかいいような気がします。

ちなみに上の図はpatchworkというggplot2オブジェクトを上下左右に並べられるパッケージを使っています。このように左のプロットと右のプロットを3:2の幅で並べるという並べ方も簡単にできます。重宝するパッケージです。

京王線・京王新線は新宿から遠ざかるほど家賃が安くなり、速達列車が止まる駅はすこしお高くなりました。都心と郊外を結ぶ路線はおおむねこのパターンです。一方で、都内の2駅を結ぶ路線はちょっと変わります。

次の図は東急池上線（五反田～蒲田）です。池上線は各駅停車のみの路線です。

Code

stations <- c(
"五反田駅", "大崎広小路駅", "戸越銀座駅", "荏原中延駅", "旗の台駅", "長原駅", "洗足池駅", "石川台駅", "雪が谷大塚駅", "御嶽山駅", "久が原駅", "千鳥町駅", "池上駅", "蓮沼駅", "蒲田駅"
)
stations_fct <- forcats::fct_relevel(as.factor(stations), stations)
idxs <- map_int(stations, station_to_idx)
area <- 30
age <- 5
walk <- 5
p1 <- tidy_draws_by_idx |>
filter(idx %in% idxs) |>
left_join(
df_mod |>
filter(moyorieki_1_station %in% stations) |>
distinct(moyorieki_1_station, .keep_all=TRUE) |>
select(moyorieki_1_station, moyorieki_1_station_index) |>
rename(station=moyorieki_1_station, idx=moyorieki_1_station_index) |>
mutate(station=forcats::fct_relevel(station, stations)),
by="idx"
) |>
mutate(mu_exp=exp(a+b*log(area)+age_b*age+walk_b*(walk-1))) |>
ggplot(aes(mu_exp, station))+
theme_light()+
tidybayes::stat_pointinterval(point_interval=tidybayes::median_qi, .width=c(0.95))+
scale_x_continuous(breaks=0:20)+
theme(axis.title.y=element_blank())+
labs(
title="exp(mu_i) (age_i=5, walk_i=5, area_i=30)",
subtitle="point: estimated (median), bar: 95% bayesian CI",
x="exp(mu_i)",
y="station"
)
p2 <- df_mod |>
filter(moyorieki_1_station %in% stations) |>
count(moyorieki_1_station, moyorieki_1_station_index, name="n") |>
rename(station=moyorieki_1_station, idx=moyorieki_1_station_index) |>
mutate(station=forcats::fct_relevel(station, stations)) |>
arrange(station) |>
ggplot(aes(station, n))+
theme_light()+
geom_bar(stat="identity", color="black", fill="gray", alpha=0.6)+
scale_y_continuous(breaks=seq(0, 2000, 500), minor_breaks=seq(0, 2000, 100))+
geom_text(aes(label=n, y=100))+
theme(axis.title.y=element_blank())+
coord_flip()+
labs(
title="（参考）物件数",
subtitle="築40年以下, 徒歩20分以下, 10m2-100m2の物件のみ"
)
patchwork::wrap_plots(p1, p2, ncol=2, widths=c(3, 2))

五反田と蒲田が高く、その間が比較的安くなります。アルファベットの大文字のJの文字を時計回りに90度回転させたような図になります。京王井の頭線（渋谷～吉祥寺）もこのパターンです。

大崎広小路は物件数が66件しかないですが、階層モデルのおかげでパラメータが推定できています（当然、95%ベイズ信用区間は広くなります）。

東京メトロや都営地下鉄のように都心を横切るような路線だと真ん中あたりが高くなることもあります。

階層モデルによって面積や築年数や徒歩分数要素を分離して同じ条件で比較できるようになったことで、条件を固定したときの最寄り駅による家賃の違いを知ることができました。Stan（MCMC）のおかげでパラメータの確率分布が得られるので、だいたい17.1万円-17.8万円の間という幅も分かっていいですね。家賃相場は17.4万円ですと言われても、だいたい17.1万円-17.8万円なのかだいたい15万円-20万円なのかでは話が変わってきますからね。

最寄り駅別の家賃相場（面積可変）

築5年、徒歩5分は固定のまま、面積を20m2から60m2まで変えたときに最寄り駅によってどの程度家賃相場が変わるのか見てみましょう。$\mathrm{age}_{i} = 5, \mathrm{walk}_{i} = 5$としたときの、$\mathrm{area}_{i}$を20から60まで変えたときの$\exp(\mu_{i})$の事後中央値と95%ベイズ信用区間を計算します。

Code

stations <- c("初台駅", "幡ヶ谷駅", "笹塚駅")
stations_fct <- forcats::fct_relevel(as.factor(stations), stations)
idxs <- map_int(stations, station_to_idx)
# MCMCの取り出したサンプルが必要（上で一度実行しているのでコメントアウトで再掲）
# sample_a <- rstan::extract(fit, "a")$a
# sample_b <- rstan::extract(fit, "b")$b
# sample_age_b <- rstan::extract(fit, "age_b")$age_b
# sample_walk_b <- rstan::extract(fit, "walk_b")$walk_b
# sample_sigma_a <- rstan::extract(fit, "sigma_a")$sigma_a
# sample_sigma_b <- rstan::extract(fit, "sigma_b")$sigma_b
# sample_sigma <- rstan::extract(fit, "sigma")$sigma
area_rent_table <- tidyr::expand_grid(
idx=idxs,
area=20:60,
age=5,
walk=5
) |>
left_join(
df_mod |>
filter(moyorieki_1_station %in% stations) |>
distinct(moyorieki_1_station, .keep_all=TRUE) |>
select(moyorieki_1_station, moyorieki_1_station_index) |>
rename(station=moyorieki_1_station, idx=moyorieki_1_station_index) |>
mutate(station=forcats::fct_relevel(station, stations)),
by="idx"
) |>
mutate(
mu=pmap(list(idx=idx, area=area, age=age, walk=walk), \(idx, area, age, walk) {
sample_a[,idx] + sample_b[,idx]*log(area) + sample_age_b*age + sample_walk_b*(walk - 1)
})
) |>
mutate(
mu_exp_median=exp(map_dbl(mu, \(x) quantile(x, 0.5))),
mu_exp_lower=exp(map_dbl(mu, \(x) quantile(x, 0.025))),
mu_exp_upper=exp(map_dbl(mu, \(x) quantile(x, 0.975)))
)
area_rent_table |>
ggplot(aes(area, color=station, fill=station))+
theme_light()+
geom_ribbon(aes(ymin=mu_exp_lower, ymax=mu_exp_upper), alpha=0.2)+
geom_line(aes(y=mu_exp_median))+
scale_y_continuous(breaks=seq(5, 30, 5), minor_breaks=5:30)+
ggsci::scale_color_aaas()+
ggsci::scale_fill_aaas()+
theme(legend.title=element_blank())+
labs(
title="exp(mu_i) (age_i=5, walk_i=5, area_i=20 - 60)",
subtitle="center line: estimated (median), ribbon: 95% bayesian CI",
x="area（面積）",
y="exp(mu_i)",
)

三色のバンドの中にある線は事後中央値、その上下の線は95%ベイズ信用区間です。

初台、幡ヶ谷、笹塚の3駅を見ると、20m2～30m2のゾーンでは家賃はあまり変わりませんが、面積が大きくなると初台＞幡ヶ谷＞笹塚の順に家賃が変わってきます。

これは結局、面積の増加に対する対数家賃の増え方のパラメータであるbが、初台＞幡ヶ谷＞笹塚の順に大きいからですね。以下の表は、$b_{sta[i]}$の事後中央値（表のb）、95%ベイズ信用区間（.lower, .upper）です。

Code

# print(fit, pars=c("b[89]", "b[173]", "b[353]"))
tidy_draws_by_idx |>
filter(idx %in% idxs) |>
left_join(
df_mod |>
filter(moyorieki_1_station %in% stations) |>
distinct(moyorieki_1_station, .keep_all=TRUE) |>
select(moyorieki_1_station, moyorieki_1_station_index) |>
rename(station=moyorieki_1_station, idx=moyorieki_1_station_index) |>
mutate(station=forcats::fct_relevel(station, stations)),
by="idx"
) |>
ungroup() |>
group_by(station) |>
tidybayes::median_qi(b, .width=0.95) |>
select(station, b, .lower, .upper)

#> # A tibble: 3 × 4
#> station b .lower .upper
#> <fct> <dbl> <dbl> <dbl>
#> 1 初台駅 0.883 0.858 0.907
#> 2 幡ヶ谷駅 0.836 0.814 0.859
#> 3 笹塚駅 0.791 0.770 0.812

なので、面積が大きくなるほど家賃相場が開いていきます。

R｜階層線形モデルで渋谷区の賃貸価格を予想する｜hanaoriの記事にインスピレーションをいただいた内容です。

おわりに

任意の築年数、徒歩分数、面積、最寄り駅のもとでの家賃相場を推定できました。Stanではドメイン知識を活かして考えたモデルをそのままコードに落として推定や解釈ができるので楽しいですね。住みたい駅を見つけるのに使えそうです。

わたし自身が知りたかった内容を知ることができたのでよかったです。個人開発は自分が使いたいものを作ろうという話がありますが、まさにその通りでした。

今回のモデルでは、築年数と徒歩分数が対数家賃を押し下げる効果は線形でかつ一律としました。しかし、新築や徒歩1～2分のような物件は、築数年や徒歩5分程度の物件と比べてさらに高い可能性もあります。新築のプレミアムのようなイメージですね。

また、減価効果は駅によっても違うかもしれません。特に都心の真ん中の新築物件や駅近物件は、他の駅の新築物件や駅近物件よりもプレミアムが乗る可能性があります。一方で、同じ駅近でも地下鉄ではなく地上を走る路線沿いや大きな駅の近くの場合は、騒音などの影響でプレミアムが乗らない可能性もあります。

築年数による減価効果は建物の材質や駅からの徒歩距離によっても変わりそうです。木造より鉄筋の方が、また駅から遠い物件より駅近物件の方が、築年数が経過しても価値が下がりにくいかもしれません。

しかし、全体の傾向をつかむという目的のモデルでは、一律でもそこまで悪くないだろうということで定式化しました（今回は建物の材質のデータは取れていないこともあります）。

他にも特徴量を追加することでさらに説明力のあるモデルが作れそうです。Future Work、今後の課題ということで以下に示します。

最寄り駅を複数考慮
- 今回は最大で3つある最寄り駅のうち1番上に書いてあるものしか使っていない
- 同じ幡ヶ谷が最寄り駅でも、初台寄りの幡ヶ谷と笹塚寄りの幡ヶ谷だと平均的には前者の方がすこし高そう。最寄り駅の情報を複数使うと、最寄り駅効果をよりよく推定できそう
  - 地図は二次元平面なので二次元の位置関係を考慮するということ
物件の階数や建物の高さ
- 1階は安く最上階は高い
- 物件の階数が上がるほど高い
- 階数が高い建物はその分設備が豪華になる傾向にありそうなので家賃も上がりそう
物件の構造や設備の有無
- 鉄筋なら高そうだし、バストイレ別とか角部屋だとやはり高そう
- 鉄筋か木造かのような物件の構造は築年数による減価効果に影響がありそう
近所の店舗情報と駅の位置関係
- スーパーマーケットが近所100mか500mかで違いそうだし、同じ100mでも、駅 - スーパー - 物件という位置関係の方が、駅 - 物件 - スーパーという位置関係よりも家賃が高そう（駅からの帰りに寄れる）

参考にした記事など

先行研究

bayesplotのプロット

書籍

StanとRでベイズ統計モデリング (Wonderful R)

単純に平均するのは、「その街の家賃相場」は実際にある物件の築年数を含めたものとして算出するという考えによるので、どちらが正しいということではありません。 ↩︎
家賃10万円で敷金1ヶ月礼金1ヶ月（＝2年で260万円）の物件と、家賃10.5万円で敷金礼金なし（＝2年で252万円）の物件なら、他の全ての条件が同じなら後者を選びそうですが、分かりやすくするため ↩︎
SUUMOの利用規約を読んだところ、スクレイピングを特に禁じてはいないと理解しています。 ↩︎
この後expをかけて対数を外したパラメータを示しますが、medianは変数変換に依存しないからです。 ↩︎
テイラー展開より、$x=0$のまわりなら$(1-x)^n \approx -nx$なので$-nx$で近似できるということです。 ↩︎
正確には、$N(\mu_{i}, \sigma)$から生成される$\log{y_{i}}$のexpを取ったもの ↩︎

TOPIXのボラティリティをStochastic Volatilityモデル + R + Stanで推定する

Tue, 19 Dec 2023 00:00:00 +0900

はじめに

この記事はマケデコ Advent Calendar 2023の18日目の記事です。1日遅れですが、枠が空いていたので飛び入り参加してみました。

状態空間モデルによるボラティリティモデルのStochastic Volatilityの論文をR + Stanで実装してみました。Stanの推定結果のプロットにはbayesplotとggplot2を用いています。

非線形な状態空間モデルによるボラティリティモデルであるStochastic Volatility (SV) モデルをStanで実装することで、TOPIXのボラティリティを推定しました。
推定されたボラティリティは、2008年のリーマンショックと、2011年の東日本大震災、2020年の新型コロナウイルスによる市場の急落局面で非常に高まっていることを確認できました。
ボラティリティが一度高まるとしばらくボラティリティが高い日が続く現象であるボラティリティ・クラスタリングも確認できました。

ボラティリティの定式化

ボラティリティとは、金融商品の値動きの変動の大きさを指すパラメータです。どのくらいの損失がどのくらいの確率で発生するかを示すVaR（Value at Risk）に使われるなど、金融工学の根幹をなす値です。

以下は株式に限らず、例えば為替など、金融商品であれば何でもよいですが、株式とします。

$S_t$を$t (1, \dots,\ T)$日における株式の価格とするとき、$t$日における対前日の収益率$r_t$は$r_t=\log S_t - \log S_{t-1}$となります。これを対数収益率といいます。

このとき、ボラティリティとは以下の$\sigma_t$、あるいは$\sigma_t^2$を指します¹。

$$ \begin{aligned} r_t &= E_{t-1}[r_t] + \epsilon_t \\\ \epsilon_t &= \sigma_t z_t, \quad \sigma_t > 0, \quad z_t \sim i.i.d., \quad E[z_t] = 0, \quad Var[z_t] = 1 \end{aligned} $$

$\sigma_t$と$\sigma_t^2$のどちらをボラティリティと呼ぶかは文献によりますが、以降$\sigma_t$をボラティリティと呼びます。

この$\sigma_t$を推定する方法は大きく分けて三通りあります。

一つ目の方法は、$\sigma_t$を過去一定期間の$r_t$の標準偏差とする方法です。過去1年～3年＝250～750営業日ということで$j=250$や$j=750$などとして、$\{r_{t-j+1},r_{t-j+2},\dots r_{t}\}$の標準偏差とします。もちろん直近のボラティリティを重視したいなら$j$をより小さい値に設定します。この$t$を1日ずつずらしてローリング計算することでボラティリティの時系列を得ることができます。

この方法はシンプルですが、標準偏差を計算している$t-j+1,\dots,t$の間は$\sigma_t$が一定であることを暗に仮定しています。実際はそうではありませんので、精緻に求めるなら残りの二つの方法のどちらかを用いることになります。

二つ目の方法は、$\sigma_t$を統計的なモデルで定式化するものです。

このタイプのモデルは有名なGARCHモデルをはじめ色々ありますが、本記事ではStochastic Volatility (SV) モデルと呼ばれるモデルのうち、シンプルな以下のモデルを推定することにします。

$$ \begin{aligned} y_t &= \exp(x_t/2) \epsilon_t, \quad \epsilon_t \sim N(0,1) \\\ x_{t+1} &= \mu + \phi(x_t - \mu) + \eta_t, \quad \eta_t \sim N(0,\sigma_{\eta}^2) \\\ x_1 & \sim N(0,\sigma_{\eta}^2/(1-\phi^2)) \end{aligned} $$

ここで$y_t$は対数収益率$r_t$であり、$\exp(x_t/2)$がボラティリティ$\sigma_t$です。$x_t$は定常な過程と仮定し、$|\phi|<1$です。

このSVモデルは、最初の式で$E_{t-1}[r_t]=0$とした上で、$x_t = \log \sigma_t^2$がAR(1)モデルに従うことを意味します。

このモデルは1本目の式が観測方程式、2本目の式が状態方程式の非線形な状態空間モデルですので、パーティクルフィルタのような非線形な状態空間モデルでも推定できるタイプのフィルタ系の手法か、Stanなどを用いてMCMCで推定することになります。

最後に三つ目の方法としては、以上二つのように収益率$r_t$の時系列から$\sigma_t$を推定するのではなく、分単位のような細かい収益率データを用いて直接$\sigma_t$を求めるアプローチがあります。本記事からは外れるので詳細は触れませんが、$t$日における1分間隔や5分間隔程度の細かい間隔の収益率の2乗を1日分足し合わせたものが$\sigma_t$の精度のよい推定量（Realized Volatility²と呼びます）になることが知られています。

環境

R + RStanです。Stanコードを書いてrstanというRのパッケージから呼び出します。

Rを用いているのはベイズモデリングは文献もパッケージもRが豊富なためです。あとこの記事のコードは自分で昔書いたコードを流用しているのですが、それがRだったからというのもあります。

Windows 10
R 4.3.1
httr 1.4.7
rstan 2.32.3
bayesplot 1.10.0
patchwork 1.1.3

library(tidyverse)
library(httr)
library(rstan)
library(bayesplot)
library(patchwork)

データの取得

今回は上で挙げたSVモデルをRとStan (RStan)で実装し、MCMCによってパラメータを推定してみます。

TOPIXの日次の終値が必要なので用意します。2008/5/7～2023/12/18（3824営業日）のTOPIXの終値をJ-Quantsから取得しました。J-QuantsはJPXが個人向けにリリースしている株価などの金融データのAPIです。

この記事のモデリングをするにはTOPIXの終値だけあればいいので、J-Quantsではなくとも構いません。証券会社に口座を開いていれば、証券会社が提供しているトレーディングツールからCSVでエクスポートできたりもします。

データの取得コード

J-Quantsは、認証エンドポイントを2回POSTしてトークンを取得したら、そのトークンをBearer認証のヘッダに入れてTOPIXのエンドポイントをGETするだけのシンプルな作りです。

# J-Quantsに登録したメールアドレスとパスワード
mail_address <- "MAIL_ADDRESS"
password <- "PASSWORD"

resp <- httr::POST(
"https://api.jquants.com/v1/token/auth_user",
body=jsonlite::toJSON(
list(mailaddress=mail_address, password=password),
auto_unbox=TRUE
)
)
refresh_token <- httr::content(resp)$refreshToken
resp <- httr::POST(
"https://api.jquants.com/v1/token/auth_refresh",
query=list(refreshtoken=refresh_token)
)
id_token <- httr::content(resp)$idToken
resp <- httr::GET(
"https://api.jquants.com/v1/indices/topix",
query=list(from="2008-05-07", to="2023-12-18"),
httr::add_headers(Authorization=glue::glue("Bearer {id_token}"))
)
topix <- httr::content(resp)$topix |>
dplyr::bind_rows() |>
tibble::as_tibble()

最初のPOSTでは{"mailaddress": "mail@example.com", "password": "hoge"}のようなJSONをbodyに入れます。RでこのJSONを作るには、jsonlite::toJSON(list(mailaddress=mail_address, password=password), auto_unbox=TRUE)とします。

jsonlite::toJSON()の引数auto_unboxはデフォルトではFALSEなのですが、jsonlite::toJSON(list(mailaddress=mail_address, password=password), auto_unbox=FALSE)は{"mailaddress": ["mail@example.com"], "password": ["hoge"]}となってしまいます。Rではmail@example.comのような文字列は長さ1のcharacter型のベクトルであるため、そのまま長さ1のリストができてしまうからです。これを防ぐためにauto_unbox=TRUEを指定します。

TOPIXの終値から対前日の対数収益率を計算します。100倍して%表記にします。また、最初の1日の収益率はNAになるので最初の1日を除いておきます。

df <- topix |>
mutate(Date=as.Date(Date, "%Y-%m-%d")) |>
mutate(ret=(log(Close) - log(lag(Close, 1)))*100) |>
slice(-1)

こんな感じのデータです。

df

#> # A tibble: 3,823 × 6
#> Date Open High Low Close ret
#> <date> <dbl> <dbl> <dbl> <dbl> <dbl>
#> 1 2008-05-08 1384. 1386. 1373. 1373. -1.47
#> 2 2008-05-09 1372. 1374. 1341. 1342. -2.30
#> 3 2008-05-12 1331. 1345. 1327. 1343. 0.0767
#> 4 2008-05-13 1351. 1364. 1344. 1360. 1.28
#> 5 2008-05-14 1360. 1376. 1351. 1373. 0.951
#> 6 2008-05-15 1382. 1404. 1382. 1393. 1.43
#> 7 2008-05-16 1405. 1412. 1391. 1396. 0.215
#> 8 2008-05-19 1400. 1410. 1397. 1404. 0.599
#> 9 2008-05-20 1402. 1410. 1394. 1400. -0.315
#> 10 2008-05-21 1385. 1386. 1361. 1370. -2.15
#> # ℹ 3,813 more rows

Stanで実装

上に挙げたSVモデルをStanコードで書きます。

data {
int N;
vector[N] y;
}
parameters {
vector[N] x;
real mu;
real<lower=-1,upper=1> phi;
real<lower=0> sigma_eta;
}
transformed parameters {
real phi_beta;
phi_beta = (phi + 1)/2;
real sigma_eta_square;
sigma_eta_square = sigma_eta^2;
}
model {
mu ~ normal(0, 1);
phi_beta ~ beta(20, 1.5);
sigma_eta_square ~ inv_gamma(5.0/2, 0.05/2);
x[1] ~ normal(0, sigma_eta/sqrt(1 - phi^2));
x[2:N] ~ normal(mu + phi * (x[1:(N-1)] - mu), sigma_eta);
y ~ normal(0, exp(x/2));
}
generated quantities {
vector[N] vol;
vol = exp(x/2);
vector[N] y_pred;
for (i in 1:N) {
y_pred[i] = normal_rng(0, exp(x[i]/2));
}
}

以下、実装のポイントです。

$\mu, \phi, \sigma_{\eta}$の事前分布は、SVモデルの元の論文であるKim, Shephard and Chib (1998) ³や、それを日本株に適用した大森, 渡部 (2007)⁴ にある以下の分布を用いました。IGは逆ガンマ分布です。無情報事前分布ではなく、事前分布を書いてあげると収束しやすくなります。

$$ \begin{aligned} \mu & \sim N(0,1) \\\ \frac{\phi+1}{2} & \sim Beta(20,1.5) \\\ \sigma_{\eta}^2 & \sim IG(5/2, 0.05/2) \end{aligned} $$

generated quantitiesのvolが今回求めたいボラティリティ$\sigma_t$です。MCMCの結果から$x$の事後分布を取り出してR上で$\exp(x/2)$を計算することで求めることもできますが、Stanで求めておきます。

generated quantitiesのy_predは、各パラメータの事後分布から乱数で生成した$y_t$の値です。これはパラメータの推定自体には不要ですが、あとでモデルの事後診断に使用するために求めています。

あとは高速化のためにできるだけベクトル化をします。

このStanコードを”svmodel.stan”で保存して以下のRコードでキックすることでMCMCの推定を行います。

i9-9900Kで実行しました。chains=4, iter=110000, warmup=10000, thin=50で8時間程度かかりました。iterをかなり大きくしてthinで間引かないと$\phi$などのパラメータに自己相関が残っていました。

# Stanのおまじない（上は並列化、下はstanコードが変わらない限り再コンパイルしない）
options(mc.cores=parallel::detectCores())
rstan_options(auto_write=TRUE)
# C++コードへのコンパイル
mod <- rstan::stan_model("svmodel.stan")
# MCMCサンプリング
fit <- rstan::sampling(
mod,
data=list(N=nrow(df), y=df$ret),
chains=4, iter=110000, warmup=10000, thin=50, seed=1234
)

MCMCのチェック

MCMCがうまくいっているかチェックします。

MCMCが終わったら早速パラメータの値を見たいところですが、収束していないということがよくあるのでチェックしましょう⁵。収束していなければパラメータが正しく推定されていないということです。

詳細に知りたい方は、例えばこちらの分かりやすい記事をご覧ください。

[R] [stan] bayesplot を使ったモンテカルロ法の実践ガイド - ill-identified diary

このあたりの事後診断の可視化はbayesplotが超便利です。ggplot2ベースなので出力のグラフにggplot2の関数で軸などのレイアウトを微調整できるのもナイスです。

まずはRhatです。MCMCが収束しているかの目安であり、全てのパラメータで1.1を下回ることが必要とされます。パラメータが多くて個別にプロットするのは難しいので、ヒストグラムで描きます。いい感じです。

bayesplot::mcmc_rhat_hist(bayesplot::rhat(fit))

次に有効サンプルサイズ（n_eff）です。Nで割ったものが0.1以上であることが望ましいとされます。0.1を下回るような小さい値のパラメータは、MCMCのサンプリングで自己相関が残っていることを示唆します。自己相関が大きいとパラメータの事後分布の分散を正しく推定できません。

こちらもよさそうですね。

bayesplot::mcmc_neff_hist(bayesplot::neff_ratio(fit))

次は自己相関です。サンプルに自己相関が残っている場合、サンプルに定常性がないということになります。

全部描けないので以下の3つのパラメータに絞ります。phiとsigma_etaにちょっと自己相関が残っていそうですが、おおむねいい感じです。もう少しiterとthinを増やせばphiとsigma_etaの自己相関も消える気がします。

bayesplot::mcmc_acf_bar(fit, pars=c("mu", "phi", "sigma_eta"))

ちなみにbayesplot::mcmc_acf_bar()をはじめ、bayesplotの描画関数はparsでパラメータを指定し忘れると全パラメータ描画します。巨大なモデルだとこれでRStudioがクラッシュすることがありますので気を付けましょう。特に時系列の状態空間モデルはパラメータの数が多いのでクラッシュしがちです（今回はxがx[1]からx[3823]まである）。モデルをRDSファイルに保存し忘れた状態だと推定結果が消えて悲しいことになります。

そしてトレースプロットを見ます。こちらもパラメータを絞っています。

これはchainごとのサンプルの推移で、線が混ざり合っていると初期値によらず同じ値に収束している＝局所解に落ちていないことを示します。Rhatが大きいときはトレースプロットが混ざり合っていないので、Rhatと合わせてチェックします。いい感じですね！

bayesplot::mcmc_trace(fit, pars=c("mu", "phi", "sigma_eta"))

最後に、モデルが現実のデータをよく説明するように定式化されているなら、パラメータの事後分布から乱数を振って得られる目的変数（ここでは$y_t$）は、実際の$y_t$と同じような分布で得られるはずです。これを図示してみます。

濃い線は実際のy_t（対数収益率）の分布、薄い線はモデルから生成した8000系列の対数収益率y_predのうち最初の10系列の分布です。薄い線はそれぞれの系列で10本あります。8000系列は描けないので10本に絞っています。

濃い線と薄い線が大体重なっているので悪くなさそうです。

bayesplot::ppc_dens_overlay(df$ret, rstan::extract(fit)$y_pred[1:10,])

自分でモデルを一から組む場合は、モデルのパラメータはMCMCで正しく推定されていても、そもそもモデル自体が元のデータを全然説明できていない誤ったモデルであることがあります（SVモデルは幅広く用いられているモデルなので、今回ちゃんと当てはまるのはある意味当然なわけですが）。モデルが元のデータに当てはまっているかどうかを示してくれるのが上のプロットです。

bayesplot::ppc_*系の関数はこのような事後予測の確認に役立つものが色々あって便利です。

以上がMCMCの結果の基本的なチェック方法です。

パラメータの推定結果

以下がパラメータの推定結果です。ただしprintが長くなるので一部のパラメータに絞っています。

print(fit, pars=c("mu", "phi", "sigma_eta"), digits_summary=3)

#> Inference for Stan model: anon_model.
#> 4 chains, each with iter=110000; warmup=10000; thin=50;
#> post-warmup draws per chain=2000, total post-warmup draws=8000.
#>
#> mean se_mean sd 2.5% 25% 50% 75% 97.5% n_eff Rhat
#> mu 0.127 0.001 0.106 -0.079 0.058 0.127 0.197 0.336 7883 1
#> phi 0.966 0.000 0.007 0.951 0.961 0.966 0.971 0.978 4028 1
#> sigma_eta 0.213 0.000 0.020 0.176 0.198 0.212 0.226 0.255 3167 1
#>
#> Samples were drawn using NUTS(diag_e) at Wed Dec 20 00:41:18 2023.
#> For each parameter, n_eff is a crude measure of effective sample size,
#> and Rhat is the potential scale reduction factor on split chains (at
#> convergence, Rhat=1).

推定したボラティリティを見てみましょう。rstan::extract()を用いてパラメータの事後分布のサンプルからvolの時系列を作ります。

点推定値として事後中央値を用います。あわせて95%ベイズ信用区間も示したいので、中央値と2.5%タイル点と97.5%タイル点を取り出します。volの事後分布の(110000 (iter) - 10000 (warmup))/50 (thin) * 4 (chain) = 8000個のサンプルを小さい順に並び変えて50%と2.5%と97.5%のタイル点を取り出すことで得られます。

# 8000 (サンプル) x 3823 (vol[1] - vol[3823])のmatrix
mat <- rstan::extract(fit, "vol")$vol
vol_stat <- tibble::tibble(
vol_median=apply(mat, 2, \(x) quantile(x, 0.5)),
vol_lower=apply(mat, 2, \(x) quantile(x, 0.025)),
vol_upper=apply(mat, 2, \(x) quantile(x, 0.975))
) |>
mutate(Date=df$Date) |>
relocate(Date)
res <- left_join(df, vol_stat, by="Date")
res

#> # A tibble: 3,823 × 9
#> Date Open High Low Close ret vol_median vol_lower vol_upper
#> <date> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl>
#> 1 2008-05-08 1384. 1386. 1373. 1373. -1.47 1.36 0.892 2.20
#> 2 2008-05-09 1372. 1374. 1341. 1342. -2.30 1.37 0.908 2.15
#> 3 2008-05-12 1331. 1345. 1327. 1343. 0.0767 1.34 0.894 2.10
#> 4 2008-05-13 1351. 1364. 1344. 1360. 1.28 1.33 0.896 2.10
#> 5 2008-05-14 1360. 1376. 1351. 1373. 0.951 1.33 0.894 2.06
#> 6 2008-05-15 1382. 1404. 1382. 1393. 1.43 1.33 0.892 2.05
#> 7 2008-05-16 1405. 1412. 1391. 1396. 0.215 1.32 0.887 2.07
#> 8 2008-05-19 1400. 1410. 1397. 1404. 0.599 1.33 0.903 2.05
#> 9 2008-05-20 1402. 1410. 1394. 1400. -0.315 1.36 0.918 2.06
#> 10 2008-05-21 1385. 1386. 1361. 1370. -2.15 1.39 0.963 2.09
#> # ℹ 3,813 more rows

以下のグラフの上はボラティリティ$\sigma_t$（赤線は$\sigma_{t}$の事後分布の中央値、青いバンドは95%ベイズ信用区間）、下はTOPIXの終値です。$\sigma_t = a$であれば、TOPIXの収益率の標準偏差がa[%]であることを意味します。

code

p_vol <- res |>
ggplot(aes(Date))+
theme_light()+
geom_ribbon(aes(ymin=vol_lower, ymax=vol_upper), fill="lightsteelblue1", alpha=0.5)+
geom_line(aes(y=vol_upper), color="lightsteelblue1")+
geom_line(aes(y=vol_lower), color="lightsteelblue1")+
geom_line(aes(y=vol_median), color="firebrick")+
scale_x_date(breaks=scales::date_breaks("1 year"), date_labels="%y")+
labs(
x="date (year)",
y="volatility (sigma_t)",
subtitle="red: estimated (median), light blue: 95% CI"
)
p_topix <- res |>
ggplot(aes(x=Date, y=Close))+
theme_light()+
geom_line()+
scale_x_date(breaks=scales::date_breaks("1 year"), date_labels="%y")+
labs(x="date (year)", y="TOPIX close")
patchwork::wrap_plots(p_vol, p_topix, ncol=1)

2008年のリーマンショック、2011年の東日本大震災、2020年の新型コロナウイルスの市場急落局面でボラティリティが高まっていることが分かります。

なお、グラフはpatchworkで並べました。複数のggplotオブジェクトを綺麗に並べられて重宝するパッケージです。

最後に$\phi$のパラメータの事後分布を見てみます。先程示した通り、$\phi$ = 0.966 (95%CI: 0.951-0.978)でした。

bayesplot::mcmc_hist(fit, pars="phi")

このパラメータは過去のボラティリティがどの程度後を引くかを示すパラメータであり、1に近いということは持続性がかなりあるということを示します。ボラティリティが一度上昇するとしばらくボラティリティが高い日が続くということであり、この現象をボラティリティ・クラスタリングといいます。

SVモデルを推定した論文をサーベイすると$\phi$の推定値は0.8から0.995までの値となっているという論文がありますが⁶、この先行研究と整合的です。

おわりに

Stanを使うと柔軟にモデルを組んで解釈ができて楽しいですね。

SVモデルの一番シンプルなものを推定してみましたが、SVモデルには収益率の裾の厚さを表現するために誤差項をt分布としたり、収益率がマイナスの日の方がボラティリティが高まる（ボラティリティの非対称性といいます）ことを表現したりするモデルなど、色々な発展形があります。これらをStanで組んでみてもよいでしょう。

最後に株価データで時系列モデリングをやってみたいという方におすすめの書籍をご紹介します。

ボラティリティ変動モデル (シリーズ現代金融工学)
- 統計モデル的アプローチによるボラティリティモデルです。ボラティリティモデルをしっかり学ぶならこれです。MCMCによる推定も少し触れられています。コード例はなく数式展開の理論の本です。
経済・ファイナンスのためのカルマンフィルター入門 (統計ライブラリー)
- 前半はカルマンフィルタの解説、後半は経済・金融データへのカルマンフィルタの適用事例の紹介です。前半はカルマンフィルタの導出を丁寧に書いていて理解しやすかったです。後半はカルマンフィルタでベータ値を推定したりペアトレーディングの銘柄を発掘したりと面白い事例が豊富です。コードはないですが読みやすいです。

カルマンフィルタで株式のベータ値を推定する - suzuna's memo

式の通り、$z_t$は正規分布とは指定していないので、$r_t$も正規分布以外の分布を仮定することができます。実証的には$r_t$は裾が厚く正規分布ではないとされます。 ↩︎
例えばこの辺りの論文をご覧ください。渡部敏明, 佐々木浩二 (2006), 「ARCH型モデルと”Realized Volatility”によるボラティリティ予測とバリュー・アット・リスク」, 金融研究, 25 別冊(2), 39-74. ↩︎
Kim, S., N. Shephard, and S. Chib (1998), “Stochastic Volatility: Likelihood Inference and Comparison with ARCH Models”, Review of Economic Studies, 65, 361-393. ↩︎
大森裕浩, 渡部敏明 (2007), 「MCMC法とその確率的ボラティリティモデルへの応用」CIRJEディスカッションペーパー, J-173, 1-39. ↩︎
何日もかけて回したMCMCの結果をチェックしたら全然収束していない悲しみもあるある ↩︎
Jacquier, E., N. Polson, and P. Rossi (2004), “Bayesian Analysis of Stochastic Volatility Models (with Discussion)”, Journal of Business & Economic Statistics, 12, 371-417. ↩︎

GitHub ActionsでHugoのビルドを自動化する

Tue, 17 Oct 2023 00:00:00 +0900

概要

Hugoで作ったブログをGitHub Pagesで公開するときに、HugoのビルドをGitHub Actionsで行うことでビルドを自動化します。

GitHubのリポジトリはHugoのソース用のリポジトリと、Hugoのビルドの生成物のリポジトリの二つ作っている場合を考えます。前者は下の構成図でsuzuna/blog-source、後者はsuzuna/blogにあたります。

このとき、前者にgit pushすると、Hugoでビルドし、生成物を後者にpushするようなGitHub Actionsを前者のリポジトリで動かすということです。

Hugoのビルド自動化×リポジトリ分割のメリット

HugoのビルドをGitHub Actionsで自動化するメリットは、主に二つあると思います。

記事を書き上げてGitHub Pagesで公開する前に、ローカルPCでHugoのビルドのコマンドを実行する必要がないのが一つです。hugoでビルドするのを忘れてpushすることがよくあるんですよね。

また、Hugoのビルド環境が統一されるのがもう一つのメリットです。複数のPCで記事を書くような場合でも環境の差異に悩むことがなくなりますし、Markdownが書ければよいのでHugoを入れていない端末でも記事を書けます。

次にHugoのソースと生成物を別々のリポジトリに分割することで、ソースと生成物が同じリポジトリに混ざらないためGit上で差分が見やすくなります。記事やHugoのThemeのテンプレートを編集するときなどに、ソースとビルドの生成物の差分が混ざらないメリットをよく実感できます。このリポジトリ分割は一般的な方法なのか分かりませんが（ググるとちらほら出てきます）、Git管理上快適だと感じています。

GitHub Actionsのトークンの作成

ここから実際の方法を説明します。

GitHub Actionsを実行するリポジトリから別のリポジトリにpushし、pushしたリポジトリでGitHub Pagesとして公開するGitHub Actionとして、peaceiris/actions-gh-pagesを用います。

このGitHub Actionsは、同一のリポジトリにpushしてGitHub Pagesとして公開することもできます。GitHubのReadmeにある通り、この場合は特段GitHubのトークンは必要ではないのですが、今回のように別のリポジトリにpushする際はGitHubのトークンを渡す必要があります。

そのため、最初にssh鍵であるdeploy_keyか、Personal Access Tokenであるpersonal_tokenのどちらかを用意する必要があります。以下のどちらかを行ってください。

トークンの作成（deploy_key）

ssh鍵を作ります。GitHubにssh接続する際にも作るやつですね。GitHubの公式ドキュメントの通りなのですが、簡単に説明します。

まずGit Bashで以下を実行します。

ssh-keygen -t ed25519 -C "<GitHubに登録したメールアドレス>"

これを実行すると、以下の3項目を入力するようメッセージが出ますので、順に入力します。

“Enter file in which to save the key”: ssh鍵に付けるファイル名を入力します。
“Enter passphrase (empty for no passphrase)” 鍵のパスフレーズです。emptyでいいので何も入力せずEnterを押します。
“Enter same passphrase again”: 上と同じ値を入力します。こちらも同じく何も入力せずEnterを入力します。

1個目で何も入力しなければ、id_ed25519（秘密鍵）とid_ed25519.pub（公開鍵）の2つの鍵が生成されています。

そうしたら、ソース管理用のGitHubリポジトリ（構成図のsuzuna/blog-source）をブラウザで開き、Settings > Secrets > Actions > New repository secretを開きます。NameとValueを入力する欄があります。NameはGitHub Actions上で参照するSecretの名前です。任意の文字列でよいですが、ここではACTIONS_DEPLOY_KEYとします。Valueは秘密鍵の中身を貼り付けます。後者はid_ed25519をテキストエディタで開いて中身を全部コピーして貼り付ければOKです。

次に、Hugoの生成物のリポジトリ（構成図のsuzuna/blog）をブラウザで開き、Settings > Deploy keys > Add deploy keyを開きます。Titleは任意の名前を設定します。Keyは公開鍵の中身を貼り付けます。最後にAllow write accessにチェックを入れます。

トークンの作成（personal_token）

GitHubをブラウザで開き、Account SettingsのSettings > Developer settings > Personal access tokens > Generate new tokenを開きます。Personal Access TokenのScopeとしてrepoとworkflowにチェックを入れます。Tokenが表示されるので控えておきます。

そうしたら、deploy_keyの場合と同様に、ソース管理用のGitHubリポジトリのrepository secretを開き、Nameには任意の名前（ここではPERSONAL_TOKENとします）、Valueには先程のTokenを入力します。

GitHub Actionsの作成

次に、GitHub Actionsのymlファイルを作成します。

deploy_keyを用いる場合は、下記をソース管理用のリポジトリに".github/workflows/<任意のファイル名>.yml"で保存してcommitします。onに記載の通り、masterにpushするとGitHub Actionsが実行されます。

name: github-pages
on:
push:
branches:
- master
jobs:
deploy:
runs-on: ubuntu-latest
timeout-minutes: 10
steps:
- uses: actions/checkout@v4
with:
submodules: true # Fetch Hugo themes (true OR recursive)
fetch-depth: 0 # Fetch all history for .GitInfo and .Lastmod
- name: Setup Hugo
uses: peaceiris/actions-hugo@v2
with:
hugo-version: 'latest'
# extended: true # if use extended version
- name: Build
run: hugo
- name: Deploy
uses: peaceiris/actions-gh-pages@v3
with:
deploy_key: ${{ secrets.ACTIONS_DEPLOY_KEY }}
external_repository: <name>/<repository>
publish_dir: ./docs
publish_branch: master

timeout-minutesを設定しておくと、何らかの理由でビルドに失敗した場合でもGitHub Actionsのquotaを大量に消費せずに済みます。
peaceiris/actions-gh-pagesのパラメータは以下の通り指定します。
- external_repository: Hugoのビルドの生成物をpushするリポジトリ（最初の構成図ではsuzuna/blog）
- publish_dir: external_repositoryにpushするディレクトリ
  - HugoのThemeのconfig.ymlのpublishDirにします
- publish_branch: external_repositoryのpushするブランチ

なお、personal_tokenを用いる場合は、こちらを

deploy_key: ${{ secrets.ACTIONS_DEPLOY_KEY }}

以下に変更します。

personal_token: ${{ secrets.PERSONAL_TOKEN }}

以上、GitHub Actionsとリポジトリ分割で快適なHugo環境を作れました！

独自ドメイン対応

GitHub Pagesに独自ドメインを使っている場合は、以下のどちらかを行います。

ソース管理用のリポジトリにおいて、staticフォルダ内にCNAMEファイルを置く
以下のように、ソース管理用のリポジトリの".github/workflows/main.yml"において、peaceiris/actions-gh-pages@v3のwith内にcnameを指定する
- peaceiris/actions-gh-pagesのREADME.mdの"Add CNAME file cname"を参照

- name: Deploy
uses: peaceiris/actions-gh-pages@v3
with:
deploy_key: ${{ secrets.ACTIONS_DEPLOY_KEY }}
external_repository: <name>/<repository>
publish_dir: ./docs
publish_branch: master
cname: <customdomain>

参考

公式ドキュメント
参考にさせていただいた記事
- Hugo + GitHub Pages / Actionsでブログを公開する
- Hugo + GitHub Pages + GitHub Actions で独自ドメインのウェブサイトを構築する

Rの便利なlogging package: logger

Tue, 03 Oct 2023 00:00:00 +0900

Rでログを取る場合どうしていますか？インタラクティブなデータ分析ならprintやcatでもよいのですが、バッチ処理を行うような場合は、print文に現在時刻を含んだり、コンソールだけではなくファイルにも出力したりしたいところです。

Pythonなら標準ライブラリのloggingやサードバーティーのloguruなどがありますが、同じようにRでもloggerを使いたいですね。

便利なロガーパッケージのloggerを紹介します。Pythonのloggingに近いインタフェースをしているので¹、loggingを使ったことがあればすんなり使えるのではないかと思います。

環境

R 4.3.1
logger 0.2.2

インストール

インストールはこちらです。

# CRANからインストールする場合
install.packages("logger")
# GitHubからインストールする場合
remotes::install_github("daroczig/logger")

library(logger)

基本的な使い方

コンソールに表示するだけであれば、以下で使うことができます。最初にlogger::log_thresholdでログを出力する閾値を定めます。

logのlevelは高い順にfatal > error > warn > success > info > debug > traceです。（参考）

log_threshold(INFO)
log_info("info")
#> INFO [2023-10-04 02:38:37] info
log_warn("warn")
#> WARN [2023-10-04 02:38:37] warn
# DEBUGはINFOより下のlevelなので表示されない
log_debug("debug")

デフォルトではlogger::log_formatter(logger::formatter_glue)が設定されているため、glue::glueを使わなくてもglueの記法で変数を展開したり関数を評価したりできます。

x <- 1
log_info("x is {x}")
#> INFO [2023-10-04 02:38:37] x is 1
log_info("x + 1 is {x + 1}")
#> INFO [2023-10-04 02:38:37] x + 1 is 2

ログの出力先は、logger::log_appenderの引数appenderで設定することができます。デフォルトではlogger::log_appender(appender=logger::appender_console)が設定されていますので、デフォルト設定のままコンソールに出力するだけであればlogger::log_appenderは不要です。

logger::log_appenderの引数appenderにappender_で始まる関数を渡すことで、出力先を変えることができます。

以下のようにすれば、コンソールとファイルに同時に出力することもできます²。

file_path <- tempfile()
log_appender(appender_console)
log_appender(appender_file(file=file_path))
log_threshold(INFO)
log_info("info")

appender_で始まる出力先を設定する関数は他にも色々ありますが、logger::appender_slackで出力先をSlackにすることができるのが嬉しいポイントですね。内部ではslackr::slackr_msgを呼んでいるようです。バッチ処理が正常に終了したとき、あるいはエラーが出たときだけSlackに通知したいということがよくあります。

出力先ごとに出し分ける

loggerパッケージにはnamespaceとindexという概念があります。前者はloggerの名前空間（logger::log_appenderのデフォルト値は"global"）、後者は同一のnamespaceの中でのloggerのindexです（デフォルト値は1）。

namespaceは関数内でのログをメイン処理から分けるような場合などに使います。indexを活用すると、以下のようにコンソールとファイルで別々のlog levelの閾値を設定するようなこともできます。

file_path <- tempfile()
log_appender(appender_console, namespace="global", index=1)
log_appender(appender_file(file=file_path), namespace="global", index=2)
# コンソールにはINFO以上、ファイルにはDEBUG以上でログを出力する
log_threshold(INFO, namespace="global", index=1)
log_threshold(DEBUG, namespace="global", index=2)
log_info("info")
log_debug("debug")
log_trace("trace")
readLines(file_path)
#> [1] "INFO [2023-10-04 02:38:37] info" "DEBUG [2023-10-04 02:38:37] debug"

なお、同一のnamespaceとindexにlogger::appender_consoleのコンソール出力とlogger::appender_fileのファイル出力を行う場合は、logger::appender_teeというエイリアスが使えます。

log_appender(appender_tee(file=file_path), namespace="global", index=1)

ログフォーマットをカスタマイズする

logのlayoutをlogger::log_layoutの引数layoutに指定すればOKです。

例えば、logger::layout_jsonでjsonの形式にできます。

file_path <- tempfile()
log_appender(appender_console)
log_threshold(INFO)
log_layout(layout_json())
log_info("info")

フォーマットをカスタマイズすることもできます。logger::layout_glue_generatorでは、glueの記法でカスタマイズすることができます。ログレベル（level）や時刻（time）、メッセージ（msg）などいくつかの変数が組み込まれています。変数の一覧はこちらにあります。

file_path <- tempfile()
log_appender(appender_file(file=file_path))
log_threshold(INFO)
my_layout <- layout_glue_generator(
format="{level} | {format(time, '%Y-%m-%dT%H:%M:%S+09:00')} | {msg}"
)
log_layout(my_layout)
log_info("info")
readLines(file_path)
#> [1] "INFO | 2023-10-04T02:38:37+09:00 | info"

おわりに

これくらいを抑えておけばひとまず使えるかと思います。vignetteが充実しているので詳細はvignetteをご覧ください。

Reference

パッケージの作者もそのように書いています。（参考）“A lightweight, modern and flexibly logging utility for R – heavily inspired by the futile.logger R package and logging Python module.” ↩︎
なお、RMarkdownやQuartoのコードブロックにログを出力する場合、logger::appender_consoleやlogger::appender_stderrでは出力が表示されないようです。logger::appender_stdoutでは出力できます。環境はrmarkdown: 2.25, knitr: 1.44, Quarto (CLI): 1.3.450 (Windows 10, 64bit)です。 ↩︎

Typora + Googleドライブで快適なMarkdown環境を作った

Wed, 27 Sep 2023 00:00:00 +0900

要約

Markdownでメモを作成して複数のPCで同期したい場合、MarkdownエディタとしてTyporaを使い、PC版Googleドライブをインストールしてメモの保存先をGoogleドライブにしてオフラインで使用可能にするのをおすすめの方法の一つとして推します。

他の人のMarkdownエディタ事情を読むのが好きなので自分も書いてみました。

どういうこと？

この記事の対象

PCでMarkdownのメモを作成する人
複数のPCでメモを同期させたい人
- 特に、PCがインターネットに繋がっていない環境でもファイルを開いたり編集したりしたい人（ノートPCを持ち運ぶなど）

やり方

以下を満たせればよいわけです。

何らかのMarkdownエディタを用いて
Markdownの保存先として何らかのオンラインストレージに保存する
- 可能であれば、オフラインにもデータを持っておき、オンライン時に同期できるようにする

1個目の要件については好きなMarkdownエディタを使えばよいのですが、個人的にはTyporaがよかったです。（2023/9/26時点では有料、3つのデバイスまで使えて買い切り14.99ドル）

個人的にメモ用のMarkdownエディタに求めることとしてはこの辺です。

Markdownのソースコードのエディタも、リアルタイムプレビュー（Markdownのソースコードを入力すると、画面上ではリアルタイムでレンダリングされた状態が表示されている）も使えること
左ペインにフォルダ内のMarkdownファイルを一覧表示するエクスプローラが付いていること
エディタ起動時にそのエクスプローラで指定したフォルダが開かれていること
指定したフォルダ内のMarkdownファイルを対象にしたgrepができること
指定した行数・列数のTableをGUIで挿入できること

ブログや技術記事はがっつり書きたいので、VSCodeでエディタペインとプレビューペインの2ペインを並べて書いていますが¹、メモは気軽に取りたいのでリアルタイムプレビューでWYSIWIGでも書きたいものです。また、メモをメモフォルダ内に雑多に突っ込んでいまして、エディタ起動時にエクスプローラ上でフォルダが開かれていてgrepが使いたいです。Tableを手で組むのは辛いのでこれもサポートしていてほしいです。

Typoraはこれらを満たしています。有料化前から使っていて気に入っていたので有料化した際にライセンス代を支払いましたが、最近だと無料でも似たような機能を持つエディタがあるので好きなのを使えばいいと思います。無料でオープンソースのMarkTextなんかもよさそうですね。（前はGitHubでしか配布していなかった気がしますが今見たらインストーラーがあった）

保存先としてはオンラインストレージですと複数のPCで同期されてよいですね。PCが壊れても安心です。移動中などインターネットが繋がらない場所でも開いたり編集したりしたい場合は、ファイルをローカルのストレージにも持っておき、インターネットに繋がっていたらリアルタイムで同期するというオフラインモードでも開けるサービスがよいです。

PC版Googleドライブはこの辺の要件を満たします。インストールするとローカルファイルと同じようにファイルパスを持つようになります。WindowsではGoogleドライブにドライブレターが一つ割り当てられてD:\マイドライブのように、Macでは/Users/<ユーザネーム>/<Googleアカウント名>/のように扱えます。これが中々便利でして、Typoraの保存先としてD:\マイドライブ\メモフォルダを指定しておき、このフォルダをオフラインでも使用できるモードにしておけば²全ての要件を満たしてくれます。MicrosoftのOneDriveとかでもいいですが。

余談ですが、VSCodeではMarkdown All in One （色々）+ markdownlint （文法チェック）+ Markdown PDF（PDF出力） + Table Formatter（Tableの入力支援）の4つの拡張機能がお気に入りです。 ↩︎
Windowsならエクスプローラ、MacならFinderで指定のフォルダを右クリックして出てくるメニューで設定できます。 ↩︎

ニコニコ動画の再生数の推移を見られるWebアプリを作った

Thu, 21 Sep 2023 00:00:00 +0900

概要

ニコニコ動画の動画について、再生数、マイリスト数、コメント数、いいね数の日次の推移を表示するWebアプリを作りました。

こんな感じで、動画のIDを入力すると過去の値を表示します。対象は再生数が3000以上の動画（2023/9/19時点で410万件程度）です。

技術構成

当日の断面における個々の動画の再生数などのメタデータを返すスナップショット検索API v2というAPIをニコニコ動画が公開しています。このAPIは当日分のデータしか返さないため、毎日リクエストしてデータを蓄積しています。

面白そうなデータなので毎日貯めているのですが、このような過去の再生数を表示するWebサイトはほとんどない¹こともあり、勉強も兼ねてデータ基盤とWebアプリを作りました。

構成図はこちらです。

バックエンド
- クローリング部分 (VPS, Debian)
  - cronで1日1回スナップショットAPIをリクエストして結果のCSVを保存する (R)
    - ここだけRなのは、過去にRで書いたコードを流用したから
  - CSVファイルをCloud Storageにアップロードする (Python)
- データ基盤部分 (Google Cloud)
  - CSVファイルがCloud StorageにアップロードされたらBigQueryに書き込むCloud Functions (Python)
  - 過去の再生数などを保持するBigQuery
  - 動画IDをクエリストリングに与えるとBigQueryをクエリして過去の再生数などを返すCloud Functions (Python)
    - SQLインジェクション対策のため、フロントエンドだけでなくバックエンドでも入力値をバリデーション
フロントエンド (Google Cloud)
- Cloud Run (Streamlit)
  - Artifact RegistryにpushしたDocker imageでdeploy
  - 以前はHerokuにdeployしていたが、Heroku代が高いのでCloud Runに引っ越した
    - バックエンドとフロントエンドをGoogle Cloudに揃えたことにより、バックエンドのCloud Functionsをリクエストする認証周りがすっきりするメリットもあった

VPS部分のコードは、GitHub Actionsを使って、mainブランチにpushするとVPSにデプロイ（git pull）しています。Google Cloud部分のコードはTerraformで定義しています。

クローリング・スクレイピングはVPS (cron)、データ基盤はBigQuery + Terraformというのは気に入っている構成でよく採用しています。

前者にVPSを利用するのは、長時間のクローリングでも気にせずコードを動かせることと、アウトバウンドの通信量に課金がされないことからです。Cloud FunctionsやCloud Runは実行時間に上限があるので、引っかかる場合は処理をうまく分割してあげる必要がありますが、VPSならcronで雑にスクリプトを動かせます。

なお、VPSのディスク容量などの監視ツールとして、はてな製のサービスであるMackerelを使っています。無料プランでは過去のメトリクスが1日分しか見られませんが、トリガーに引っかかったときはメールやSlackで通知でき、個人開発の心強い味方です。

技術的なTips

BigQueryのテーブル設計: パーティショニング

BigQueryのテーブルを一部抜粋します。カラムは順に日時、動画ID、再生数を表します。

lastModified	contentId	viewCounter
2023-09-15T08:59:37+09:00	sm1097445	16575782
2023-09-16T08:53:20+09:00	sm1097445	16576909
2023-09-17T08:52:41+09:00	sm1097445	16578086

フロント側でデータを取得する際、例えば取得したい動画IDをsm1097445とすると、以下のクエリを書くことになります。

SELECT lastModified, contentId, viewCounter
FROM TABLE_NAME
WHERE contentId = "sm1097445"
ORDER BY lastModified;

クエリ量を削減するためにこのテーブルにパーティショニングを設定します。where句で絞るcontentIdでパーティショニングしたいところですが、パーティショニング可能なのは整数範囲、時間単位、取り込み時間のいずれかです。

contentIdはアルファベットの小文字2文字+数字1文字以上で表されることを利用し、contentIdの数字部分を4000で割った余りであるidModという列をテーブルにwrite_appendする際に付け加え、この列でパーティショニングすることにしました。4000というのは、当時BigQueryの整数範囲パーティショニングの上限は4000個までだったからです。

lastModified	contentId	viewCounter	idMod
2023-09-15T08:59:37+09:00	sm1097445	16575782	1445
2023-09-16T08:53:20+09:00	sm1097445	16576909	1445
2023-09-17T08:52:41+09:00	sm1097445	16578086	1445

SQLでパーティショニングのidMod列をwhere句に含めることで、理想的にはクエリサイズが1/4000に抑えられます。

SELECT lastModified, contentId, viewCounter
FROM TABLE_NAME
WHERE contentId = "sm1097445" and idMod = 1445
ORDER BY lastModified;

今回はcontentIdでフィルタするクエリを書くためにこのようなパーティショニングを設定しましたが、例えば同一のlastModifiedにおけるレコードを全件取得するような使い方をするならlastModified列で時間単位パーティショニングすることになります。

Terraformの環境分け（本番環境と開発環境）

Google Cloud部分は、本番環境（prod）と開発環境（dev）を分けられるように定義しています。

Terraformで異なる環境を作成する方法としては以下の三つがメジャーなところかと思いますが、三番目の方法を取っています。

Terraform Workspacesを使う
moduleを使う
.tfbackendファイルと.tfvarsファイルを用いて変数で環境を分ける

具体的にはこちらです。

リソース名の先頭に環境名を付ける（例: prod-hoge-bucket）
環境名をprod.tfvars, dev.tfvarsに記載する
Terraformのstatusを管理するCloud Storageの情報をprod.tfbackend, dev.tfbackendに記載する

小規模のバックエンド基盤では楽な方法ですね。

詳細には、こちらの記事（Terraformでmoduleを使わずに複数環境を構築する）が丁寧に解説されています。

もう少し説明

ディレクトリ構成はこのような感じです。

.
└── terraform
├── envs
│ ├── dev
│ │ ├── dev.tfbackend
│ │ └── dev.tfvars
│ └── prod
│ ├── prod.tfbackend
│ └── prod.tfvars
├── main.tf
└── variables.tf

main.tfは以下の通り

provider "google" {
project = var.project_id
region = var.project_region
}
terraform {
# バージョンは任意
required_version = "~> 1.5.5"
required_providers {
google = {
source = "hashicorp/google"
version = "~> 4.80.0"
}
archive = {
source = "hashicorp/archive"
version = "~> 2.4.0"
}
}
backend "gcs" {
# envs/(env_name)/(env_name).tfbackendに定義
}
}
# 例えばCloud Storageのバケットを作成してみる
resource "google_storage_bucket" "tmp_bucket" {
name = "${var.env}-tmp-bucket"
location = var.project_region
force_destroy = var.env == "prod" ? true : false
}

envs/dev/dev.tfvarsは以下の通り

env = "dev"
project_region = "<PROJECT_REGION>"
project_id = "<PROJECT_ID>"

envs/dev/dev.tfbackend（stateを置くバックエンドのCloud Storageの情報）は以下の通り

bucket = "<BUCKET_NAME>"
prefix = "<PREFIX>"

variables.tfは以下の通り

variable "env" {
type = string
description = "environment name"
}
variable "project_region" {
type = string
description = "Google Cloud Region"
}
variable "project_id" {
type = string
description = "Project ID"
}

以上のように用意して、terraform initするときにtfbackendファイルを、terraform planとterraform applyするときにtfvarsファイルをオプションで渡すことで、環境ごとに異なるバックエンドを参照して異なるリソースを作成することができます。

# dev環境にdeployする
$ cd terraform
$ terraform init -backend-config=envs/dev/dev.tfbackend
$ terraform plan -var-file=envs/dev/dev.tfvars
$ terraform apply -var-file=envs/dev/dev.tfvars

調べた範囲だとニコログがあります。こちらはランキングに載った動画や新着動画は収集されており、該当の動画だと1時間単位でデータがありますが、該当しないと収集されていないようです。 ↩︎

radikoでラジオ番組をタイムフリー録音してGoogleドライブにアップロードする

Sun, 14 May 2023 00:00:00 +0900

概要

radikoの指定した番組の放送終了後にVPS上でタイムフリー録音をダウンロードし、Google Driveにアップロードするようにしました。（自分のみの私的利用を目的としています）

わたしはラジオが好きでいつも作業したりコードを書いたりしながら聞いています。radikoのタイムフリー録音を使うと、1週間以内であれば放送終了後の番組を聞くことができるのですが、1週間以上経っても後から聞き返したくなることがあります。

番組をダウンロードするフリーソフトとしては、らじれこという優れたものがあります。これを活用して、1週間に1回、その週の番組をまとめてダウンロードしていました。しかし、聞く番組が増えてくると手でダウンロードボタンを押すのが面倒になってきますし、ダウンロードをし忘れることもあります。

技術屋としては技術で解決したいところです。色々調べてみると、タイムフリー録音するスクリプトを先人が作ってくれていましたので、それを活用して自動で録音する仕組みを作りました。

仕組みとしては以下のようになっています。

タイムフリー録音をダウンロードするスクリプトをVPSにおいてcronで実行
- uru2/rec_radiko_ts: Radiko timefree program recorderをベースに、引数の与え方を少し変えたかったのでラッパーのPythonスクリプトを作成
- 放送終了の5分後に、その番組を保存するようなcronを番組の数だけ書く
録音したファイルをGoogleドライブにアップロードし、アップロード完了後にVPS上からファイルを削除するPythonスクリプトをVPS上でcronで実行
- Pythonで自作
- 参考
  - PyDriveによるGoogleドライブへのファイルアップロード - Fun Scripting 2.0
  - Python, PyDriveでGoogle Driveのダウンロード、アップロード、削除など | note.nkmk.me
GoogleドライブにネットワークドライブのようにエクスプローラからアクセスできるGoogle公式のツールをWindows PCにインストール
- ローカルに保存しているのと同じような感覚で快適にアクセスできる
- 参考
  - GoogleドライブをG:などに割り当ててWindows 10でシームレスに使う：Tech TIPS - ＠IT

1個目と2個目については、エラーが発生した場合はtry～exceptでつかまえてSlackにwebhookで通知しています。

技術選定の理由はこんな感じです。

VPS
- radikoへアクセスするアウトバウンドの通信がそれなりにあるので、通信量に課金がされるGCPなどのクラウドではなく、元々借りていた通信量に課金がされないVPSを利用。
  - とりあえずcronで実行できるので楽ですね。cronが取っ散らかっていく問題はありますが…
  - VPSへのコードデプロイはGitHubのmainブランチにpushしたらVPS上でコードをpullするGitHub Actionsで行っています。
  - ちなみにConoHa（東京リージョン）ではradikoのフリープランでも東京の番組が聞けます。XServer VPSではプレミアムプランでなければ聞くことができませんでした。（サーバがあるリージョンの問題っぽい）
Googleドライブ
- Googleドライブからローカルへのダウンロードに通信量がかからず、選択した容量で月額決まった料金となる上に、先述の通り、GoogleドライブはWindowsからネットワークドライブのように扱えて便利なため。スマートフォンからもアプリでアクセス可能。
  - 最初は何も考えずGCPのCloud Storageを使おうとしたのですが、このメリットを思い出して変更しました。技術選定大事。
  - 保存容量が15GBまでなら無料、200GBでも月380円で済みます。ちなみに1時間番組1本で20MB程度です。

Tips

以下、実装の過程で出会った技術的なTipsを書き留めます。

Pythonでの`subprocess.run()`のエラーハンドリング

Pythonからコマンドを実行するときに使うsubprocess.run()ですが、正常に実行されたときとエラーが起きた時で処理を分けて、エラーの場合はエラーメッセージを取得したいというケースがあります。

解決策としては、引数にcapture_output=Trueとtext=Trueを指定します。前者により出力を受け取り、後者により出力をbyte型ではなく文字列で受け取ります。リターンコード、標準出力、標準エラー出力はreturncode, stdout, stderrで受け取ることができます。

# 任意のコマンド
cmd = "bash hoge.sh"
res = subprocess.run(cmd, shell=True, text=True, capture_output=True)
if res.returncode == 0:
logger.info(f"success | {res.stdout}")
else:
logger.error(f"error | {res.stderr}")

引数にcheck=Trueを指定すると、returncodeが0ではないときにsubprocess.CalledProcessErrorの例外を起こすことができます。

# 上の例と同じことができる
cmd = "bash hoge.sh"
try:
res = subprocess.run(cmd, shell=True, text=True, capture_output=True, check=True)
logger.info(res.stdout)
except subprocess.CalledProcessError as e:
logger.error(e)
logger.error(res.stderr)

Pythonスクリプト中での相対パスを固定する

このようなディレクトリ構造において、以下のスクリプトをmain.pyで保存します。

hoge
|-- fuga
|-- main.py

import os
print(os.getcwd())

このスクリプトは、カレントディレクトリがhogeかfugaかで返ってくる値が異なります。

hoge $ python ./fuga/main.py
hoge
hoge/fuga $ python main.py
hoge/fuga

これでは、コード中で相対パスでファイルを読み込んでいるとき（プロジェクトディレクトリであるfugaを起点にするようなパターン）、cronなどでシェルから実行する場合、カレントディレクトリによって挙動が変わり不便です。

Python>=3.9では、以下のようにos.chdir(os.path.dirname(__file__))を足してあげることで、コードが存在するディレクトリを起点にそれより下のコードが実行されて便利です。

import os
os.chdir(os.path.dirname(__file__))
print(os.getcwd())

参考：Pythonで実行中のファイルの場所（パス）を取得する__file__ | note.nkmk.me

アニメのキャプチャ画像から線画を作る

Sat, 14 Jan 2023 00:00:00 +0900

はじめに

OpenCVを用いてアニメのキャプチャ画像から線画を生成してみました。鉛筆で書いたような味のある線画が作れました。

線画生成は最近では深層学習の手法を使うものもありますが、この記事では古典的な画像処理の方法で作ってみました。アニメに限らずいわゆるアニメ風のイラストであれば記事の方法で同様に適用できると思います。

線画抽出のロジック

イラストの線画抽出については、グレースケールで読み込み -> 1回収縮 -> 収縮前との差を取る -> 白黒反転という方法でそれなりに綺麗なものが作れることが知られています（例えば：そこそこな線画を目指す OpenCV - Qiita）。収縮の際のカーネルは4近傍（2x2の行列）か8近傍（3x3の行列）を用います。シンプルですが結構きれいに線画が抽出できる優れた方法です。

この方法を出発点に、より綺麗に線画が抽出できる方法を探ってみました。

結論としては、グレースケールで読み込み -> 適応的ヒストグラム平坦化 -> 1回収縮 -> 収縮前との差を取る -> 白黒反転 -> Non-local Means Denoising -> ガンマ変換で綺麗な線画が作れました。パラメータなどは決め打ちしたのでもっといい方法はあると思います。

環境

Windows 10
python 3.10.0
opencv-python 4.5.5.64

実装

きんいろモザイクの第1期12話のこちらの画像から線画を作ってみます。

import cv2
import numpy as np

画像を読み込みます。

image_original = cv2.imread("image_original/kinmosa.jpg")

こちらがベースラインとなる「グレースケールで読み込み -> 1回収縮 -> 収縮前との差を取る -> 白黒反転」のロジックです。

image = cv2.cvtColor(image_original, cv2.COLOR_BGR2GRAY)
image_dilate = cv2.dilate(image, np.ones((3, 3), np.uint8), iterations=1)
image = cv2.absdiff(image, image_dilate)
image = cv2.bitwise_not(image)

この段階で十分きれいで驚きました。ただ、2つ改善したい点があります。

一番右の小路綾さんの左手と胴の間の線や、セーターとスカートの間の線、セーターのしわがうまく抽出できていません。
- 元の画像と見比べると分かりますが、これらはセーターの濃紺の中にある黒い線ですから、単純な収縮では線を取り出しづらいのかと思います。
全体的に線が薄いため、線にメリハリを付けたいです。

1点目はコントラストを平坦化するのがよさそうです。特に、画像の小さな領域ごとにヒストグラムを平坦化する適応的ヒストグラム平坦化（cv2.createCLAHE）が効きそうな感じがします。というわけで、グレースケール化した後に適応的ヒストグラム平坦化をかけてみます。

また、2点目については、ガンマ変換をかけることにします。

ガンマ変換前の画像のnp.ndarrayをxとするとき、単にx/255**gamma*255でガンマ変換できますが、xの全ての画素についてこの計算をするのは計算負荷が大きいです。0から255までの整数値をaとしたときに、ガンマ変換後の値yはa/255**gamma*255で与えられますから、ガンマ変換を実装する上では、aとyのマッピングテーブルを用意しておき、このテーブルのaをxで読み替えるのが賢い方法です。

なお、ガンマ変換をかけると線の周辺や真っ白の領域に黒いモスキートノイズが浮かび上がってしまうため、ガンマ変換の前に何らかのフィルターをかけてノイズを軽減する必要があります。このタイプのノイズを取るには、Bilateral Filter（cv2.bilateralFilter）、Adaptive Bilateral Filter（cv2>=3.0.0で削除された）、Non-local Means Denoising（cv2.fastNlMeansDenoising）などがあると思います。ここではNon-local Means Denoisingを試してみました。

以上を実装してみます。なお、画像処理の各種パラメータは私が色々試してみて良さそうだと感じたものを適当に採用しています。

def contrast_equalization(img: np.ndarray, clip_limit: float, tile_grid_size: int) -> np.ndarray:
clahe = cv2.createCLAHE(clipLimit=clip_limit, tileGridSize=(tile_grid_size, tile_grid_size))
res = clahe.apply(img)
return res
def gamma_transformation(img: np.ndarray, gamma: float) -> np.ndarray:
x = np.arange(0, 256)
look_up_table = (x / 255) ** gamma * 255
look_up_table = look_up_table.astype(np.uint8)
return cv2.LUT(img, look_up_table)
image = cv2.cvtColor(image_original, cv2.COLOR_BGR2GRAY)
# 追加
image = contrast_equalization(image, 2.0, 8)
image_dilate = cv2.dilate(image, np.ones((3, 3), np.uint8), iterations=1)
image = cv2.absdiff(image, image_dilate)
image = cv2.bitwise_not(image)
# 追加
image = cv2.fastNlMeansDenoising(image, h=3, templateWindowSize=7, searchWindowSize=21)
# 追加
image = gamma_transformation(image, 1.5)

以上に挙げた点がそれなりに解消していますね。ノイズは若干残ってしまっています。モスキートノイズに効果があるらしいAdaptive Bilateral Filterを使ってみたいので元の論文（Zhang and Allebach, 2008）を読んで実装したい…。

ガンマ変換はパラメータによってはノイズが出過ぎるので、やらなくてもいいかもしれません。

他のキャプチャ画像でも色々線画を作ってみましたが、少なくとも私が試してみた範囲では、コード中のパラメータはそのままで問題なさそうです。

スローループの海凪小春ちゃん

kawaii!コントラストがはっきりしている画像だと線画が綺麗に取り出せますね。

線画から動画を作る

このロジックとffmpegを用いて、アニメの動画を線画化することができます。

流れは以下の通りです。1〜5をシェルスクリプトで書いて3のpythonコードをシェルスクリプト内で読み込むようにしました。

（ffmpeg）元の動画から静止画を取り出す
（ffmpeg）元の動画から音声を取り出す
（上のpythonコード）1で取り出した静止画を線画に変換する
（ffmpeg）3で作った線画を動画にする
（ffmpeg）4で作った動画に2の音声を合わせて音声ありの動画にする

きんいろモザイク1期のOPの冒頭です。ただし5の音声は付けていません。

おわりに

いい感じに線画が作れました。

画像処理は素人なので多少勉強をしたのですが、こちらの本が参考になりました。画像処理のアルゴリズムを一通り解説しているものです。何も分からずにOpenCVの関数を使うのではなく、その背後にあるアルゴリズムを多少なりとも把握できるとより面白く感じられました。

ディジタル画像処理改訂第二版

参考

そこそこな線画を目指す OpenCV - Qiita
膨張差分法とキャニー法による線画の比較 - test.py
B. Zhang and J. P. Allebach, “Adaptive Bilateral Filter for Sharpness Enhancement and Noise Removal”, IEEE Transactions on Image Processing, vol. 17, no. 5, pp. 664-678, 2008.

FastAPIアプリをGunicorn + Nginxで公開する

Sun, 25 Dec 2022 00:00:00 +0900

はじめに

概要

PythonのAPIフレームワークであるFastAPIを用い、Ubuntu環境 (VPS) にFastAPI + Gunicorn + Nginxの構成でREST APIを作る際の設定方法です。特にNginxの設定がいつも分からなくてググっているのでメモしておきます。

この記事の対象はNginxを全く触ったことないような方です。私のようなNginxが全く分からないPython使いがとりあえずFastAPIをNginxで公開できる所まで持っていこうという趣旨です。

環境

Ubuntu 22.04.1 LTS（ConoHa VPS）
nginx 1.18.0
certbot 1.21.0
Python: Miniconda環境
- Miniconda 4.12.0
- Python 3.10.4
- FastAPI 0.79.0
- uvicorn 0.18.2
- gunicorn 20.1.0

FastAPIアプリを公開する（Uvicorn/Gunicorn）

FastAPIでAPIエンドポイントの作成

それでは今回デプロイするFastAPIアプリを作成します。

$ pip install fastapi pydantic uvicorn[standard] gunicorn

以下のコードをVPS上の適当なディレクトリにmain.pyというファイル名で保存します。

from fastapi import FastAPI
app = FastAPI(root_path="/")
@app.get("/")
def say_hello():
return {"message": "Hello!"}

ルートにGETすると{"message": "Hello!"}というJSONを返すAPIです。

FastAPIアプリの公開（ローカル）

まずはアプリケーションサーバにUvicornを用いて127.0.0.1:8000にこのAPIを立てます。ポート番号は好きな番号で構いませんが、とりあえず8000番ポートに立ててみます。

$ cd [main.pyを保存したディレクトリのパス]
$ python -m uvicorn main:app --host 127.0.0.1 --port 8000

AnacondaやMiniconda環境の場合は、conda activate [仮想環境名]してから上を実行するか、上のpythonを、Anaconda/Miniconda環境で使用しているPythonのパスに置き換えます。このパスは、conda activate [仮想環境名]; which pythonで知ることができます。

別のターミナルを開き、VPS上で127.0.0.1:8000にcurlでGETして{"message": "Hello!"}というJSONが返ってくればAPIが立てられています。

$ curl 127.0.0.1:8000
{"message":"Hello!"}

今はアプリケーションサーバにUvicornを用いましたが、Gunicornを用いてGunicornからUvicornを触ることができます。本番環境ではGunicornを用いる方がいいようなので、以下Gunicornを用いて説明します。

Uvicornを直接用いる前述の場合は単一プロセスですが、Gunicornを用いるとUvicornを複数プロセス立ち上げることができ、またそのUvicornプロセスが落ちたとしても再度プロセスを自動で立ち上げてくれます。（詳細は公式ドキュメントを参照: Server Workers - Gunicorn with Uvicorn - FastAPI）

以下のようにすることで、-wの引数で指定したプロセス数だけワーカーを持つようにGunicornが起動します。ワーカー数は適当に2にします。127.0.0.1:8000にcurlでGETすると同様に{"message": "Hello!"}が返ってきます。

python -m gunicorn main:app --bind 127.0.0.1:8000 -w 2 -k uvicorn.workers.UvicornWorker

FastAPIアプリの公開（グローバル）

これまでは127.0.0.1にAPIを立てていました。以下のように0.0.0.0を指定することで、外部からアクセスできるようになります。

# Uvicornの場合
$ python -m uvicorn main:app --host 0.0.0.0 --port 8000
# Gunicornの場合
$ python -m gunicorn main:app --bind 0.0.0.0:8000 -w 2 -k uvicorn.workers.UvicornWorker

指定したポート番号のポート（ここでは8000番）をファイアウォールで開けておいてください。
特権ポートと呼ばれる1023番までのポート番号を指定する場合、sudo権限が必要です。先頭にsudoを付けてください。

VPSではなく自分のローカルPCからcurl [VPSのIPアドレス]:8000を叩いてみて、同様に{"message":"Hello!"}が返ってくれば成功です。Webブラウザのアドレスバーに[VPSのIPアドレス]:8000を入力して開いてみても構いません。

Nginxの概略

以上の内容でとりあえずFastAPIアプリを公開することができますが、以下ではAPIにアクセスしてくるユーザとUvicorn/Gunicornの間にWebサーバのNginxを入れようと思います。

Nginxを入れない場合、複数のFastAPIアプリなどを公開しようとすると、アプリごとにポート番号を変える必要があります。

http://x.x.x.x:8000でアプリ1にアクセスできる
http://x.x.x.x:8001でアプリ2にアクセスできる

一方、Nginxを入れてリバースプロキシすると、このようにサブディレクトリへのアクセスを振り分けることができます。

http://127.0.0.1:8000でアプリ1を立ち上げる
- http://hoge.example.com/app1/を127.0.0.1:8000にリバースプロキシしてアプリ1にアクセスできる
http://127.0.0.1:8001でアプリ2を立ち上げる
- http://hoge.example.com/app2/を127.0.0.1:8001にリバースプロキシしてアプリ2にアクセスできる

この次の章では、先程作成したFastAPIアプリを127.0.0.1:8000で立ち上げておき、http://（VPSのIPアドレス）/appにGETするとNginxのリバースプロキシで127.0.0.1:8000に転送され、先程のアプリがレスポンスを返すようにします。この章では、その前にNginxの設定ファイルについて簡単に説明します。

Nginxのインストール

まずNginxをインストールします。

$ sudo apt install nginx

1行目でNginxを起動し、2行目でUbuntuの起動時にNginxが自動で起動するようにします。

$ sudo systemctl start nginx
$ sudo systemctl enable nginx

起動できているか、また自動起動が有効になっているかを確認します。

$ sudo systemctl status nginx
nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2022-12-25 20:43:29 JST; 25s ago
（以下略）

Active: active (running)とあるのが今起動できていること、/lib/systemd/system/nginx.service; enabledとあるのが自動起動されていることを示します。

なお、起動しているNginxを停止したい場合はsudo systemctl stop nginx、自動起動を無効にしたい場合はsudo systemctl disable nginxです。

Nginxの設定ファイル

バーチャルホストを作るときに使うNginxの設定ファイルの構成は以下のようになっています。

/etc/nginx/nginx.conf
/etc/nginx/conf.d/*.conf
/etc/nginx/sites-enabled/*

バーチャルホストを追加する際は、/etc/nginx/nginx.confは編集せず、/etc/nginx/conf.d/*.confか/etc/nginx/sites-enabled/*に追加します。

/etc/nginx/nginx.confには以下のように記載されていることから、/etc/nginx/nginx.confがロードされるときに、その中で/etc/nginx/conf.d/直下にある拡張子confのファイルと/etc/nginx/sites-enabled/直下にあるファイルが読み込まれることが分かります。

http {
（略）
##
# Virtual Host Configs
##
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}

/etc/nginx/sites-enabled/*に追加する際は、実際には/etc/nginx/sites-available/直下に設定を作成し、それを/etc/nginx/sites-enabled/にシンボリックリンクを張るようにするのが一般的です。シンボリックリンクを外せばNginxの設定から除外されるのがメリットです。

それでは/etc/nginx/conf.d/*.confとetc/nginx/sites-available/*のどちらに設定を記載すればよいかですが、多くのバーチャルホストを使う場合、あるいはバーチャルホストをデプロイしたりしなかったりと切り替えたい場合は後者、そうではない場合は前者、のような考え方が一つの決め方になります。本記事では、/etc/nginx/sites-available/以下に設定を作ることにします。

FastAPIアプリを公開する（Gunicorn + Nginx）

Nginxを用いたリバースプロキシでのAPIの公開について説明します。

まず、/etc/nginx/sites-available/直下に設定ファイルを作成します。この記事では/etc/nginx/sites-available/fastapiというファイルを作ることにします。デフォルトのファイルとして/etc/nginx/sites-available/defaultが用意されていますので、これをひな形としてコピーしてから編集することにします。

$ sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/fastapi
$ sudo ln -s /etc/nginx/sites-available/fastapi /etc/nginx/sites-enabled/

2行目のシンボリックリンクを貼る作業は、シンボリックリンクを外さない限りは/etc/nginx/sites-available/に新しいファイルを作成したら最初の1回だけ行っておけば大丈夫です。

sudo nano /etc/nginx/sites-available/fastapiでこのファイルを編集します。以下を貼り付けて上書き保存します。

server {
listen 80;
location /app/ {
proxy_pass http://127.0.0.1:8000/;
}
}

VPSのIPアドレスをx.x.x.xとします。80番ポートをlistenするよ、http://x.x.x.x:80/app/に来たアクセスは127.0.0.1:8000に転送するよということですね。

なお、proxy_passのtrailing slash（末尾のスラッシュ）は付けるようにしましょう。付けないと正しくアクセスできません。地味にハマりポイントです。

保存したら、sudo nginx -tを実行してNginxの設定ファイルに構文エラーがないかどうかを確かめておきます。

エラーが表示されなければ構文に誤りはありませんので、Nginxを再起動することで今作成した設定ファイルを反映させます。設定ファイルを更新したら必ずNginxを再起動してください。再起動するまでは反映されません。

$ sudo systemctl stop nginx
$ sudo systemctl start nginx

次に、先程作成したFastAPIアプリのroot_pathを/app/に変更します。

from fastapi import FastAPI
app = FastAPI(root_path="/app/")
@app.get("/")
def say_hello():
return {"message": "Hello!"}

このFastAPIのエンドポイントをGunicornで公開します。

$ python -m gunicorn main:app --bind 127.0.0.1:8000 -w 2 -k uvicorn.workers.UvicornWorker

ローカルのPCからhttp://x.x.x.x/app/をブラウザで開くかcurlを叩いて{"message":"Hello!"}が返ってくれば成功です。

http://x.x.x.x/で公開したい場合は、FastAPIアプリのroot_pathを/app/ではなく/にし、/etc/nginx/sites-available/fastapiのlocationも/app/ではなく/にします。

Nginxのより進んだ設定

ここまででFastAPIアプリをGunicorn + Nginxで公開することができました。

FastAPIアプリを本番公開する際には、Nginxの設定において追加でいくつか行った方がいいことがあります。以下順に説明していきます。

SSL化
1. Let’s Encript + certbotでSSL証明書の導入と自動更新
2. SSL対応 + HTTPに来たアクセスのリダイレクト
IPアドレス直打ちでのアクセスを拒否
Nginxのバージョンを非表示
IPv6対応
アクセスログにリバースプロキシを考慮したIPアドレスを残す
アクセスログにPOSTボディを出す
アクセスログを別ファイル化

1. SSL化

SSL証明書の導入・自動更新の設定

この節は独自ドメインのSSL証明書を取る時の最初の1回だけ行います。

独自ドメインを取得していることを前提にします。以下、hoge.example.comという独自ドメインを使いたいとします。まず、独自ドメインを取得したドメイン会社のDNSレコード設定ページから、独自ドメインとVPSサーバのIPアドレスを紐づけてください。

sshの証明書はLet’s Encriptで取ることにします。証明書は90日おきに更新する必要がありますが、certbotを入れておくと自動で更新してくれます。

$ sudo apt install -y certbot python3-certbot-nginx

certbotの設定をします。以下を実行すると、恐らくメールアドレスを入力するようにメッセージが出ると思いますので、その通り入力してください。

$ sudo certbot --nginx -d hoge.example.com

次に、証明書の90日おきの自動更新が機能しているかどうか確かめます。以下を実行してエラーが出なければOKです。

$ sudo certbot renew --dry-run

Nginxの設定ファイルの対応

ここまでで独自ドメインのSSL化ができました。次にNginxの設定を行います。

独自ドメインを使いたいアプリの設定が記述されているファイル（/etc/nginx/sites-available/fastapiなど）に以下を貼り付けて上書き保存します。

server {
server_name hoge.example.com;
listen 443 ssl default_server;
ssl_certificate /etc/letsencrypt/live/hoge.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/hoge.example.com/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
（略）
}
server {
if ($host = hoge.example.com) {
return 301 https://$host$request_uri;
}
listen 80;
server_name hoge.example.com;
return 404;
}

1個目のserverディレクティブでは、80番ポートだけでなく443番ポートもlistenするように設定します。また、SSLの証明書のパスなどを設定しています。
2個目のserverディレクティブでは、80番ポートへのアクセスを443番ポートにリダイレクトしています。

なお、default_serverの挙動ですが、デフォルトでは複数の設定ファイルを読み込んでいるときはファイル名の順番に読み込み、一番最初に読み込まれた設定ファイルに記載されているserver_nameをdefault_serverとします。

上で記載したように同一のserverディレクティブ内にserver_nameを指定してlisten [port] default_serverと記載すると、このserverディレクティブ内のserver_nameをdefault_serverとします。

2. IP直打ち拒否

x.x.x.x宛のアクセスを拒否します。ユーザがWebサーバにIPアドレス直打ちでアクセスしてくることは普通考えにくいためです。

設定を反映させたい設定ファイルに以下を記述します。性質上、全てのバーチャルホストで同じ設定をしたいケースが多いと思いますので、個別の設定ファイルである/etc/nginx/sites-available/fastapiではなく、/etc/nginx/nginx.confか/etc/nginx/conf.d/default.confに以下の通り記述するのでも構いません。

server {
server_name _;
listen 80 default_server;
listen 443 ssl default_server;
return 444;
}

Nginxは、Hostヘッダがどのサーバ名ともマッチしないとき、あるいはリクエストにHostヘッダが含まれていないときはデフォルトサーバに振り分けます。これによって、他の設定ファイルのserverディレクティブ内に記載されているドメイン以外のアクセスは444エラーを返します。

server_nameのアンダーバーは「全てのサーバ」を示します。他の設定ファイルで定義されているhoge.example.comなどのドメインに該当しなかった全てのアクセスをこのserverディレクティブでキャッチするということですね。

3. Nginxのバージョンを非表示

Nginxはデフォルトでは使っているバージョンを表示します。特定のバージョンに脆弱性があり、自分が使っているバージョンが脆弱性のあるバージョンの場合、侵入者に脆弱性を知らせてしまっていますから、バージョンを非表示にするのが望ましいです。

/etc/nginx/nginx.conf内に以下の1行を記載すればOKです。

http {
（略）
server_tokens off;
}

あるいは、/etc/nginx/sites-available/fastapiなどの個別の設定ファイル内に以下のように記載しても構いません。

server {
（略）
server_tokens off;
}

4. IPv6対応

/etc/nginx/sites-available/fastapiに以下を記載します。

server {
（略）
# ここから下2行はIPv4対応
listen 80 default_server;
listen 443 ssl default_server;
# ここから下2行はIPv6対応
listen [::]:80 default_server;
listen [::]:443 ssl default_server;
}

5. ログにリバースプロキシを考慮した接続元のIPアドレスを残す

リバースプロキシしているので、何も設定しないとログファイルに残るIPアドレスなどは自分のIPアドレスになってしまいます。外部からアクセスしてきたIPアドレスなどをそのまま残すには、/etc/nginx/sites-available/fastapiのlocationディレクティブの中に、proxy_set_headerで始まる5行を書きます。

server {
（略）
location /app/ {
proxy_pass http://127.0.0.1:8000/;
# ここから
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Real-IP $remote_addr;
# ここまで
}
}

6. ログにPOSTボディを出す

Nginxのデフォルトの設定では、ログにPOSTボディの中身は表示されません。以下のようにすると表示できます。

ただし、POSTボディが長い文字列になる場合、ログファイルが圧迫されてしまうことに注意してください。

まず、/etc/nginx/nginx.confにコメントを付した3行を記載します。

http {
##
# Logging Settings
##
log_format '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
# 以下の3行を記載する
log_format format1 '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" "$request_body"';
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;

次に、/etc/nginx/sites-available/fastapi内に次の1行を追加します。これにより、/etc/nginx/nginx.confで定義したformat1の形式でログが記載されます。

server {
location /app/ {
（略）
# 追加する
access_log /var/log/nginx/access.log format1;
}
}

7. ログを別ファイル化

デフォルトでは/etc/nginx/nginx.confのaccess_logに記載の/var/log/nginx/access.logにログが作られますが、変更することもできます。

/etc/nginx/sites-available/fastapiに以下を追記します。

server {
location /app/ {
（略）
# 追加する
access_log /var/log/nginx/access_fastapi.log;
}
}

もちろん、上で説明したようにログのフォーマットを変えることもできます。

server {
location /app/ {
（略）
# 追加する
access_log /var/log/nginx/access_fastapi.log format1;
}
}

参考

公式ドキュメント
- FastAPI + Uvicorn / Gunicorn
  - Server Workers - Gunicorn with Uvicorn - FastAPI
- Nginx
  - Getting Started | NGINX
その他参考にさせていただいた記事（Nginx）

GPT-2で作ったConoHa上のこのはちゃんbotとSlackで会話する

Sun, 11 Dec 2022 00:00:00 +0900

はじめに

この記事はConoHa Advent Calendar 2022の11日目の記事です。

ConoHa Advent Calendarは初めての投稿です。どうぞよろしくお願いいたします。

ConoHa、いいですよね。課金が時間単位、転送量課金がない、スケールアップ・スケールダウンが可能、と使い勝手がいいですが、何より美雲このはちゃんが清楚かわいいのでモチベーションが上がります。

Advent Calendarの記事のテーマを考えながらConoHa上で作業をしていたときにふと思いました。ConoHaでの作業の合間にこのはちゃんとおしゃべりできたら楽しそうだなと。個人的にちょうどGPT-2にも興味を持っていたのです。技術の力で何とかなるかもしれませんね？

というわけで、自然言語処理における深層学習モデルの一種であるGPT-2を利用して、文章を入力すると「このはちゃんっぽい」返事を出力するモデル（このはちゃんモデル）を作成しました。このモデルを組み込んだSlackのチャットボットのAPIをConoHa VPS上に立て、Slackでこのはちゃんbotとおしゃべりしてみました。なお、このはちゃんモデルを作成する際には、Twitterのこのはちゃん（@MikumoConoHa）へのメンションのツイートとそれに対するこのはちゃんのリプライのテキストデータを用いています。

技術的には、GPT-2の推論モデルを組み込んだSlack botのAPIをConoHa上にFastAPI + Boltで立てました。FastAPIはPythonのAPIフレームワーク、BoltはSlack botを作れるSlack公式のライブラリです。モデルはrinna社の日本語の事前学習済みGPT-2モデルであるjapanese-gpt2-smallをツイートデータでファインチューニングすることで作成しています。

記事の流れは以下の通りです。

学習データの入手（ローカルPC）
1. ツイートを収集する
2. 1のテキストを前処理する
このはちゃんモデルの作成（ローカルPC）
1. ローカルPCに環境を構築する
2. ファインチューニングする
このはちゃんモデルを組み込んだSlack botのAPIをデプロイ（ConoHa VPS）
1. Slack APIのWebサイトよりEvent Subscription型のSlackアプリを作成する
2. 2-2で作成したこのはちゃんモデルを組み込んだSlack botのAPIをVPSにデプロイする

環境

ローカルPC

OS、ハード
- Windows 10
- NVIDIA GeForce RTX 2060 Super
- CUDA 11.6
- CuDNN 8.5.0
Python
- python 3.10.4 (miniconda 4.10.3)
- torch 1.12.1+cu116
- transformers 4.22.0.dev0
- sentencepiece 0.1.97
R
- R 4.2.1 (RStudio 2022.07.1+554 Spotted Wakerobin (desktop))
- rtweet 1.0.2
- rvest 1.0.3

ConoHa VPS（メモリ2GB）

OS
- Ubuntu 22.04.1 LTS
Python
- python 3.10.4 (miniconda 4.12.0)
- fastapi 0.79.0
- slack-bolt 1.14.3
- gunicorn 20.1.0
- torch, transformers, sentencepieceはローカルPCと同じ

学習データの入手

（この章はConoHa VPSを使っていないので読み飛ばしていただいても構いません）

ツイートの収集

まずは後のファインチューニングの学習データとして使用するツイートを集めます。

いま作りたいチャットボットは、何かしらの問いかけをするとそれに対してこのはちゃんbotが返事をしてくれるというものです。ですから、学習データとして、@MikumoConoHaに対するリプライツイートと、それに対する@MikumoConoHaによるリプライのペアを集めればよいことになります。このようなツイートのペアを取得するには、まず@MikumoConoHaのツイートを取得し、次にツイートごとにツイートがリプライの場合はリプライ元のツイートを取得することになります。

ロジックは以下の通りです。

@MikumoConoHaのツイートの取得
- 過去のツイートを保存しているtwilogというWebサイトの@MikumoConoHaのページより@MikumoConoHaのツイートをスクレイピングします。
  - Twitter APIを用いれば指定したユーザのツイートを取得することができます。
    - rtweet（RのTwitter APIクライアント）ではrtweet::get_timeline、tweepy（PythonのTwitter APIクライアント）ではtweepy.API.user_timeline
  - しかし、無料版では最新3200件しか取得できません。
  - twilogには3200件の制約なく過去のツイートが掲載されているため、この方法をとりました。
@MikumoConoHaのツイートが他のツイートへのリプライである場合、そのリプライ元のツイートのIDの取得
- 上のスクレイピングで取得した@MikumoConoHaの各ツイートのID（https://twitter.com/<user_name>/status/[0-9]+の[0-9]+）を用いてTwitter APIを叩くことで、各ツイートのテキストやメタ情報を取得します。メタ情報の中にはリプライ元のツイートのIDがin_reply_to_status_idとして含まれていますので、これを取り出します（ツイートが他のツイートに対するリプライでない場合はNULL）。
  - rtweetではrtweet::lookup_tweet、tweepyではtweepy.API.get_status
  - 細かい話ですが、非公式RTなどではin_reply_to_status_idがNULLになることがあるようです。
リプライ元のツイートのテキストの取得
- 上で入手したリプライ元のツイートのIDを用いて同じAPIをもう一度叩くことでリプライ元のツイートのテキストを得ます。
  - なお、非公開アカウントからのツイートである場合は得られません。

ローカルPC上で、R（rtweet + rvest）で取得しました。記事の他の部分はPythonを用いているのでこの節もPython（tweepy + requests + beautifulsoup）で書いて言語を統一してもいいのですが、以前Rで似たようなコードを書いていたのでそれを流用しています。スクレイピングやクローリングの定期実行はVPSの得意とする所ですが、今回は数時間、1回のクローリングでデータが得られるためローカルPC上で実行しています。

テキストの前処理

ここまでで入手したツイートのペアのテキストを前処理します。前処理あるあるだと思いますが、今回の記事で一番大変な工程でした。

まずはツイートからメンション記号（@）やリツイート記号（RT）などを取り除き、純粋なテキスト部分を取り出します。リツイートは複数連鎖していたり、メンション記号が複数付いていたりするので、正規表現で頑張って取り除きます。

そのうえで、通常のテキストの前処理を行います。全角チルダを波ダッシュに置換（いわゆる全角チルダ・波ダッシュ問題）、絵文字や顔文字、ハッシュタグの削除、NFKC正規化、記号の表記ゆれの統一（「、、」を「…」に置換するなど）を行っています。

ここまでできたら、後述のモデルに投入するために、リプライ元とリプライのツイートの各ペアを

<s>（リプライ元のツイートのテキスト）[SEP]（それに対する@MikumoConoHaのリプライのテキスト）</s>

という形式で1行ずつ書き出したUTF-8のテキストファイルで出力します。ちなみに、リプライが複数往復している場合は複数行に切り分けられます。

例えば、こちらのこのはちゃんとあんずちゃんの微笑ましい（？）やりとりから、

やだねっ！
— 美雲このは☁️💙 (@MikumoConoHa) May 27, 2021

以下の学習データが作成されます。

<s>疲れちゃったこのはちゃんも手伝って〜![SEP]やだねっ!</s>

（絵文字を単純に削除したせいで「疲れちゃった」と「このはちゃん」がくっついてしまい、「このはちゃんが疲れた」ようにも読めますね。前処理の難しい所です。）

このテキストがペアの数だけ行として存在します。以上により、リプライ元のツイートと@MikumoConoHaのリプライのペアを約23000件（約2.5MB）集めることができました。

このはちゃんモデルの作成

（この章もConoHa VPSを使っていないので読み飛ばしていただいても構いません）

今回用いた手法であるGPT-2では、巨大な言語コーパスを学習データとした汎用的なモデル（事前学習モデル）をそのまま解きたいタスクに適用することもできますし、解きたいタスクのドメインに関する比較的少量のテキストを用いて事前学習モデルをファインチューニングすることでタスクに特化したモデルを作成することもできます。

一般に、「汎用的なモデル」を一から作るには膨大な計算資源が必要ですので、既に公開されているモデルを利用するのが定番です。事前学習モデルはりんなちゃんのrinna社が公開している日本語のGPT-2モデルであるrinnakk/japanese-pretrained-modelsのjapanese-gpt2-smallというモデルを用いました。よりサイズが大きいモデルも公開されていますが、私のローカルPCのGPUではメモリに載らなかったため、japanese-gpt2-smallを用いました。

このjapanese-gpt2-smallを先程作成したツイートデータでファインチューニングすることで、文章を入力するとそれに対するこのはちゃんっぽい文章を出力する（これが入力した文章に対する返信ということです）という今回解きたいタスクに特化したモデルを作るという流れです。

ConoHa VPSにはGPUインスタンスがないため、ファインチューニングはローカルPCで行い、できたモデルをConoHaに持っていくことにします。深層学習は素人なため、誤りがあったらすみません。

環境構築

まずローカルPCにPyTorchとCUDA, CuDNNの環境を作ります。CUDAとCuDNNはtorchでGPUを使うのに必要なものです。

環境構築はこちらの記事を参考にさせていただきました（ただし、この参考記事と違いPyTorch1.12 + CUDA 11.6 + CuDNN 8.5を入れました）。

Windows10にPyTorch1.10とCUDA11.3の環境を作る

CUDAとCuDNNを入れたら、以下を実行します。私はMinicondaの仮想環境の中でpipを用いています。

$ conda create -n conoha-chatbot python=3.10
$ conda activate conoha-chatbot
$ conda install pip
# 参照: [Start Locally | PyTorch](https://pytorch.org/get-started/locally/)
$ pip install torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/cu116
# protobufのバージョンを3.20以下にするようにエラーが出るのでprotobufは3.20のバージョンを指定
$ pip install pip install sentencepiece datasets evaluate protobuf==3.20
$ pip install git+https://github.com/huggingface/transformers
$ cd <適当な作業ディレクトリ>
# あとでファインチューニングでスクリプトを使うため
$ git clone https://github.com/huggingface/transformers

ファインチューニング

こちらの記事を参考にさせていただきました。

GPT-2をファインチューニングしてニュース記事のタイトルを条件付きで生成してみた。 - Qiita

ファインチューニング用のファイルであるtransformersのrun_clm.pyの引数に先程作成した学習データとパラメータを渡せばOKです。

$ cd <作業ディレクトリ>
$ python ./transformers/examples/pytorch/language-modeling/run_clm.py \
--model_name_or_path=rinna/japanese-gpt2-small \
# 先程出力したデータのテキストファイルのファイル名
--train_file=conoha_training_data.txt \
--validation_file=conoha_training_data.txt \
--do_train \
--do_eval \
--num_train_epochs=100 \
--save_steps=10000 \
--save_total_limit=3 \
--per_device_train_batch_size=1 \
--per_device_eval_batch_size=1 \
--output_dir=model_output \
--use_fast_tokenizer=False

以上を実行して学習が終わるまで待つと、作業ディレクトリ内のmodel_outputというディレクトリにモデルが出力されます。学習データは約23000件（約2.5MB）、エポック数100、バッチサイズ1で学習に約4時間かかりました。

Slack botのデプロイ

ここからいよいよConoHa VPSを使います。

Slackアプリの作成

https://api.slack.com/ よりSlackアプリを作成します。

今回作りたいSlack botはEvent Subscriptionのbotです。これは、Slack上でメッセージを投稿するなど何かしらの動作をすると、指定したエンドポイントにSlackがリクエストを投げ、そのリクエストに対して何かしらのレスポンスを返すとSlackに反映されるというものです。

まずはSlack Appを作り、アプリにSlack上の権限を付与します。作り方はこちらの記事を参考にさせていただきました。

できたら、適当にSlackのチャンネルを作り、そのチャンネルにAppをインストールします。

また、このはちゃんとチャットしている雰囲気を出すために、Slack APIのWebサイト上からアイコンを設定しました。アイコンは美雲このはオフィシャルサイトの二次創作用イラストよりいただきました。

このはちゃんモデルを組み込んだSlack botのAPIのデプロイ

ようやくこのはちゃんbotのデプロイまでたどり着きました。FastAPI (Bolt) + Gunicornを用いて、Slack botのAPIを<VPSのIPアドレス>:8000に立てることにします。

実際は、独自ドメインを取ってSSL化した上でSlack APIのURLをhttps://mydomain.example.com/slack/eventsに設定し、NginxでそのURL宛のリクエストを127.0.0.1:8000にリバースプロキシし、APIを127.0.0.1:8000に立てました。ここでは簡単のため独自ドメイン、SSL化、Nginxによるリバースプロキシを使わない前提で説明します。

まずはConoHa VPS上に使用するcondaの仮想環境を作り、次にFastAPI関連のライブラリと、SlackのEvent Subscription型のアプリを作れるSlack公式のSDKであるBoltというライブラリを入れます。

$ conda create -n conoha-chatbot python=3.10
$ conda activate conoha-chatbot
$ conda install pip
$ pip install fastapi pydantic uvicorn[standard] gunicorn
$ pip install slack_bolt

次にPyTorchの環境設定を行います。推論はCPUで行うので、CUDAやCuDNNのインストールは不要です。

$ conda activate conoha-chatbot
# 前処理で絵文字を削除するのに使う
$ pip install demoji
$ pip install torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/cu116
$ pip install pip install sentencepiece datasets evaluate protobuf==3.20
$ pip install git+https://github.com/huggingface/transformers

次に、先程訓練したモデルが入ったローカルPCの"model_output"ディレクトリ以下を、VPSの作業ディレクトリ直下に移します。

そして、以下のmain.pyとgenerate.pyをそれぞれ作業ディレクトリ直下に作成します。

ディレクトリ構成はこのようになっています。

$ tree -L 1 <作業ディレクトリ>
<作業ディレクトリ>
├── generate.py
├── main.py
└── model_output

main.py

コード内の二つのcredentialはSlack APIのポータルサイトより得られる値を記入します。

SLACK_BOT_TOKEN
- 左サイドバーの「OAuth & Permissions」ページ内の「Bot User OAuth Token」（xoxb-で始まる文字列）
SLACK_SIGNING_SECRET
- 左サイドバーの「Basic Information」ページ内の「Signing Secret」

from slack_bolt import App
from slack_bolt.adapter.fastapi import SlackRequestHandler
from fastapi import FastAPI, Request
from generate import preprocess, generate
# 自分のcredentialを入れる（コード内に書かず、環境変数として切り出す方が望ましい）
SLACK_BOT_TOKEN = "xoxb-xxxxxx"
SLACK_SIGNING_SECRET = "xxxxxx"
app = App(token=SLACK_BOT_TOKEN, signing_secret=SLACK_SIGNING_SECRET)
app_handler = SlackRequestHandler(app)
# 引数のroot_pathはNginxなどでリバースプロキシするときに変える（今回はルートのまま）
api = FastAPI(root_path="/")
@api.post("/")
async def endpoint(req: Request):
return await app_handler.handle(req)
# 「Slackにメッセージが投稿されたらこの関数を実行する」という意味のデコレータ
@app.event("message")
def handle_app_mentions(body, say, logger):
text = body["event"]["text"]
res: list[str] = generate(preprocess(text), 1)
res: str = res[0]
print(f"input: {text} - output: {res}")
say(res)

generate.py

import re
import unicodedata
import demoji
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer
device = torch.device("cpu")
tokenizer = AutoTokenizer.from_pretrained("rinna/japanese-gpt2-small")
tokenizer.do_lower_case = True
model = AutoModelForCausalLM.from_pretrained("<作業ディレクトリ>/model_output/")
model.to(device)
def preprocess(text: str) -> str:
"""
テキストを前処理する
"""
# windowsの全角チルダを波ダッシュに変換する（いわゆる全角チルダ・波ダッシュ問題）
text = re.sub("\uff5e", "\u301c", text)
# 絵文字を削除
text = demoji.replace(text, "")
text = unicodedata.normalize("NFKC", text)
# 顔文字を雑に削除
text = re.sub(r"[\(（].*[\)）]", "", text)
# URLを削除
text = re.sub(r"https?://[\w/:%#\$&\?\(\)~\.=\+\-]+", "", text)
# ハッシュタグを削除
text = re.sub(r"#.+ ?", "", text)
# 表記ゆれ系を統一
text = re.sub(r"[・、。]{2,3}", "…", text)
text = re.sub(r"\.\.\.", "…", text)
text = re.sub("ー{2,}", "ー", text)
text = re.sub(r"!{2,}", "!", text)
text = re.sub(r"\?{2,}", "?", text)
text = re.sub(r"…{2,}", "…", text)
text = text.strip()
return text
def generate(input: str, num: int = 1) -> list[str]:
"""
推論する
引数inputのテキストからnum個のテキストを作る
"""
input_text = "<s>" + input + "[SEP]"
input_ids = tokenizer.encode(input_text, return_tensors="pt").to(device)
# ここのパラメータを変えると出力される文章が変わる
out = model.generate(
input_ids, do_sample=True, top_p=0.95, top_k=500, repetition_penalty=1.2,
num_return_sequences=num, max_length=30, bad_words_ids=[[1], [5]]
)
res = []
for output_text in tokenizer.batch_decode(out):
output_text = output_text.split("[SEP]</s>")[1]
output_text = output_text.replace("</s>", "")
res.append(output_text)
return res

技術的な説明

APIの起動時にこのはちゃんモデルがロードされます。
Slack Appをインストールしたチャンネルで何らかのメッセージを入力すると、そのメッセージを含むJSONがこのAPIにPOSTされます。
API側では以下の処理が行われます。
- 実際にSlackに入力されたテキストをJSONから取り出します。
- それをテキストの前処理関数であるpreprocessで前処理します。
  - ローカルPCでの前処理の際に使用した関数と同じものです。
- モデルに通すために、前処理した入力するテキストを<s>（入力するテキスト）[SEP]の形の文字列にします。
- これをこのはちゃんモデルに通し、出力の文字列を得ます。
- Slack側にレスポンスを返します。

Slackにメッセージが投稿されたらそれを受け取って何かしらのレスポンスを返すという処理は、Boltを使わずrequestsなどを使って自分で一から作ることもできますが、結構骨が折れます。Boltはデコレータによってこの処理を簡単に記述できるライブラリです。BoltにはHTTPServerアダプタが組み込まれているためBolt単体でもAPIを立ち上げられますが、FastAPIやFlaskのようなAPIのライブラリにBoltを組み込むことができます（公式のドキュメントでは、本番環境ではそうすることが推奨されています）。BoltのFastAPIへの組み込み方については、BoltのGitHubライブラリ内のサンプルコードを参考にしました。

テキストを与えると返事を出力するGPT-2の推論部分を別のAPIとして作成し、Slack botのAPIではそのAPIを叩きに行くのがよくある構成だと思いますが、簡単のためbotのAPI内で直接モデルをロードすることにしました。

APIのデプロイ

アプリケーションサーバにGunicornを用いて、このAPIを8000番ポートで公開します。事前にファイアウォールで8000番ポートを開けておきます。

$ cd <作業ディレクトリ>
$ python -m gunicorn main:app --bind 0:0:0:0:8000 -w 1 -k uvicorn.workers.UvicornWorker

Gunicornのワーカー数（-w 1の部分）は1にしています。各ワーカーでこのはちゃんモデルがロードされるため、メモリ2GBのプランではメモリ使用量的にワーカー数は1がギリギリでした。なお、VPS（CPU3コア、メモリ2GB）にssh接続した状態でメモリ使用量（sar -rコマンドの%memused）を確認してみると、APIの起動前は10%、起動直後（モデルをロードしているとき）は50%、メッセージ待機時と推論時は40%程度を推移していました。

APIエンドポイントをSlackに登録する

先程Slack Appを作成したSlack APIのWebサイトより、左サイドバーの"Event Subscriptions"を開きます。画像の"Enable Events"の横のトグルをOnにした後、今立ち上げたAPIエンドポイントのURLをRequest URLの欄に入力します。

画像内の"Request URL"にhttp://<VPSのIPアドレス>:8000を入力します。

入力するとSlack側から立ち上げたAPIにドメインの所有権を確かめるためのPOSTが行われます。上手くAPIが立ち上げられていれば、bolt側でこれを打ち返してくれるので、“Verified"と表示されるはずです。

最後にSlack Appをインストールしたチャンネルに適当にメッセージを入力してみて、数秒経ってからこのはちゃんbotから返事が来れば成功です。

APIのURLの初回登録時は、ドメインの所有権を確認するために、SlackからPOSTされるjsonの"challenge"というキーの値を送り返す必要があります（画像の"We’ll send HTTP POST requests to this URL when events occur.（以下省略）“に書いてある通り）。上記で利用したBoltでAPIを立てるとこの対応を内部で行ってくれますので、この処理に関するコードを書く必要はありません。 Boltを用いない場合はFastAPIなどのAPIフレームワークを使って自分でAPIを立てて対応する必要があります。詳細はSlackの公式ドキュメントをご参照ください。

会話してみた

会話してみます。

おはようと挨拶するとちゃんとおはようと返してくれます。ちなみに、このはちゃんモデルは文脈は考慮しません。（前のやり取りを踏まえて次の出力の文章が変わるということはありません）

こんばんはと挨拶してもおはようとしか返してくれません。謎の冬季限定チョコレート推し…。

清楚かわいいとほめると喜んでくれます。

あんずちゃんにはたまに厳しくなるみたいです。

おわりに

雰囲気は何となくこのはちゃんっぽい感じがしますね。個人的には満足しましたが、意味が通っていない返事をすることも結構ありました。前処理の改善やよりパラメータ数の大きい事前学習モデルの使用、パラメータチューニングなどが今後の課題でしょうか。

以上、ConoHa VPSでAPIを立てて深層学習チャットボットを作ることができました。今後もConoHaで物を作っていきたいです。

参考

公式ドキュメントなど
- Twitter: @MikumoConoHa
- 美雲このはオフィシャルサイト
  - 本記事の中で使用したこのはちゃんのイラストはこちらからいただきました。
  - ©GMO Internet Group, Inc., 再利用禁止です。
- りんなオフィシャルサイト
- rinnakk/japanese-pretrained-models
  - rinna社による日本語GPT-2の事前学習モデル
- Slack | Bolt for Python
- BoltのGitHubライブラリ内のサンプルコード
- Using the Slack Events API | Slack
参考にさせていただいたサイト
- WindowsにおけるPyTorchのGPU環境の作り方
  - Windows10にPyTorch1.10とCUDA11.3の環境を作る
- rinnakk/japanese-pretrained-modelsの使い方
  - GPT-2をファインチューニングしてニュース記事のタイトルを条件付きで生成してみた。 - Qiita
- Slack Appの作り方
  - Slack Appの作り方を丁寧に残す【BotとEvent APIの設定編】
  - 【30分で完成】オウム返しBotから始めるSlackアプリの作り方 | PCIソリューションズ - プロダクト・サービスサイト

代替文字を含むShift-JISのテキストファイルをRで読み込む（おまけにPythonも）

Mon, 21 Nov 2022 00:00:00 +0900

概要

Question

以下のdata.txtというファイル名のShift-JISのテキストファイルを考えます。ただし、代替文字（Replacement Character, UnicodeでU+FFFD）が含まれる行が存在する可能性があります。

りんご
みかん
バナナ
（以下略）

いま、このテキストファイルを、代替文字は削除したうえで1行が1要素の文字列ベクトル（c("りんご", "みかん", "バナナ"...)）として読み込みたいです。ただし、環境はWindows, RはR>=4.2.0のバージョンとします。

Answer

回答は一例です。

readr::read_lines_raw("data.txt") %>%
stringi::stri_encode(from="Shift-JIS") %>%
stringr::str_remove_all("\ufffd")

環境

version R version 4.2.1 (2022-06-23 ucrt)
os Windows 10 x64 (build 19045)
system x86_64, mingw32
ui RStudio
language (EN)
collate Japanese_Japan.utf8
ctype Japanese_Japan.utf8
tz Asia/Tokyo
date 2022-11-21
rstudio 2022.07.1+554 Spotted Wakerobin (desktop)
（一部割愛）
readr: 2.1.3
stringi: 1.7.8
stringr: 1.4.1

説明

data.txtに代替文字が含まれていなければ、以下で問題ありません。代替文字を含む場合でも、ファイルがUTF-8やEUC-JPの場合はencodingをそれに変えれば上記の環境で同様に問題なく読み込めました。

readr::read_lines("data.txt", locale=readr::locale(encoding="Shift-JIS"))

しかし、代替文字を含むShift-JISのファイルの場合、Error: Invalid Multibyte Sequenceというエラーが出てRStudioがクラッシュします。そのため、一旦raw形式で読み込んでから文字列に直します。raw形式で読み込む関数は、例えばreadr::read_lines_rawがあります。

次に、raw形式から文字列に変換する必要がありますが、rawToCharを用いると文字化けしてしまいます。理由は私にはよく分かっていないのですが、こちらのStack Overflowのアンサーによると（Encoding and raw in R - Stack Overflow）、charToRawの関数ヘルプにはエンコーディングを考慮しないと記載があるので、rawToCharも同様にエンコーディングが考慮されないのではないか、とのことです。R>=4.2.0の環境では日本語環境のWindowsでも文字のロケールがUTF-8ですので、辻褄が合います。

したがって、エンコーディングを考慮してrawから文字列に変換するstringi::stri_encodeを用います。

最後にstringr::str_remove_allで代替文字である\ufffdを削除すれば完成です。

Python版

おまけにPythonで同じことをするコードを載せておきます。バイナリモードで1行ずつ読み込んでShift-JISに変換すればOKです。line_binary.decodeでignoreとすればReplacement Characterを読み込んだ上で削除されますが、ここをreplaceとしてからre.subで削除したり他の文字に置き換えることも可能です。

res = []
with open("data.txt", "rb") as f:
while True:
line_binary = f.readline()
line = line_binary.decode("Shift-JIS", "ignore")
if line == "":
break
res.append(line)

参考にさせていただいたサイト

スマホゲーム「CUE!」のストーリーをOpenCVとOCR（Vision API）で書き起こす

Wed, 05 Oct 2022 00:00:00 +0900

概要

はじめに

次世代声優育成スマホゲームCUE!のゲームシナリオをOpenCVとOCR（Google CloudのVision API）を使って自動で書き起こしてみました。

プレイヤーが声優事務所のマネージャーとなり、事務所に所属する16人の新人声優を育てていくというゲームです。

美晴さんはほんわかおっとりしていながらも、周りの子たちをよく見ていて支えになるお姉さんです。

CUE!にはシナリオパートがあり、キャラクター同士やキャラクターとプレイヤーの掛け合いを見ることができます。CUE!ではシナリオは上に挙げたような画像で、画像下部の台詞がテロップのように流れながらキャラクターがしゃべります。

サービス開始日から遊んでいたアプリだったので、セリフを使って何か分析したりモデルを組んだりしたいと思ったのですが、そもそもセリフのテキストデータがないため自分でセリフを書き起こしてデータセットを作る必要がありました。

セリフのスクリーンショットを用意しなくとも、スマートフォンやタブレットでストーリーを流しっぱなしにしたまま画面を録画した動画をインプットにできると楽です。そのためセリフ画像を切り出す所もコードで対応することにしました。

CUE!はもうサービスが終了してしまったゲームであり、手元にはサービス提供中にストーリーを撮った動画が残っているという事情もあります。

やったこと

CUE!のストーリーを録画した動画のmp4ファイルをインプットとし、各セリフの発話キャラクターとセリフ内容を列に、セリフの数だけ行を持つようなcsvファイルを出力しました。

インプットに使用する動画はストーリーごとに1本ずつ分かれた動画であり、スマートフォンかタブレットの画面録画か、あるいはキャプチャボードを用いてスマートフォンやタブレットを接続したPCから録画するかのどちらかを想定しています。

技術構成

Step1: 動画から静止画を切り出す
- FFmpeg
Step2: 切り出した画像から、セリフが載っている画像だけを漏れなくダブりなく取り出す
- セリフはテロップのように流れるので、Step1で切り出した画像には、キャラクターが話し終わる途中でセリフが切れてしまっている画像が含まれていたり、セリフが全て写っている画像がダブっていたりします。また、セリフが含まれていない画像もあります。これらを取り除きます。
- Python + OpenCV
Step3: 残った画像について、超解像で画像を拡大する
- waifu2x-caffe
Step4: 前処理する
- OpenCVの画像処理ではバイラテラルフィルタと収縮を使用
- Python + OpenCV
Step5: OCRでテキストを取り出す
- Python + Google Cloud Vision API

CUE!以外のスマホゲームでも同様のロジックで文字起こしができると思います。（ただし画像処理部分のコードはゲームに応じて描き直す必要があります）

環境

ハード
- Core i9-9900K
- NVIDIA GeForce RTX 2060 Super
ソフト
- Windows10
- Python 3.10.0
- opencv-python 4.5.5.64
- waifu2x-caffe 1.2.0.4

Step1 動画から静止画を切り出す

FFmpegをコマンドラインから使えるようにダウンロードして設定した後、以下をコマンドプロンプトかbashで実行すると動画1秒につき15枚のjpg画像が切り出されます。

1時間の動画であれば15×60×60=54000枚の画像が出力されます。動画の解像度や画質にもよりますが、画像1枚で数百KB程度になりますので、ローカルのストレージに十分な容量を確保する必要があります。

# 切り出した静止画を保存するフォルダは、事前に作成しておくこと
cd 切り出した静止画を保存するフォルダパス
# `-q:v 1`は最高画質で保存する
# image_{7桁の連番}.jpgで保存される
ffmpeg -i "動画のファイルパス" -r 15 -q:v 1 image_%07d.jpg -vcodec jpg

Step2 画像を漏れなくダブりなく取り出す

課題

Step1で静止画を切り出すことができましたが、得られたキャプチャ画像には問題が3つあります。

セリフが表示されていない幕間の場面をキャプチャしている
セリフが全て表示し終わる前にキャプチャしているため、セリフが途中で切れている
セリフが全て表示し終わってからキャプチャしているが、同じセリフが写っているキャプチャが何枚もある

1と2の画像は全て削除して、3のキャプチャはセリフごとに1枚だけ残したいです。

参考: 2の例

解決策

まず問題1についてですが、画像を見て分かるように、セリフが映っている画像では、セリフの長方形の領域の背景はほぼ白です。一方で、セリフが表示されていない画像はそうではありません。

このことを活かし、まずセリフの領域を切り出し、とりあえず雑にセリフの領域の左上の隅からx軸方向に2px、y軸方向に2pxの1ピクセルと、右下の隅からx軸方向に-2px、y軸方向に-2pxの1ピクセルの2点を取り出し、この2点がいずれも白色でなければその画像にはセリフのボックスが含まれていないとみなしてその画像を削除することにしました。

セリフのボックスの位置は全ての画像で固定です。よって、GIMPなどのマウスカーソルを載せた場所の座標を取得できる画像ビューアを用いて事前にボックスの四隅の座標を調べておき、その座標を指定することで元の画像からセリフのボックスを切り出すことができます。

白色かどうかの判定ですが、真っ白を表す(R, G, B) = (255, 255, 255)と比較してCIEDE2000の色差が5以上であれば白色ではないとみなすことにしました。CIEDE2000での色差は、skimage.color.deltaE_ciede2000で求めることができます。

次に問題2と3の解決方法についてです。

今、セリフの領域を切り出して二値化した画像を用意し、この画像内で「最も右側の黒色の画素（＝行列値が0）のx座標」を考えてみます。ただしセリフは最大で2行あるため、セリフのボックスを上下2分割し、下段のセリフを上段のセリフの右端にくっつけた画像で考えます。

元々のセリフのボックスの領域はこれですが、

大津の二値化を行ってから上下を横にくっつけたこちらの画像を用いて考えます。

以下、画像iの「最も右側の黒色のピクセルのx座標」を$x_{i}$と表します。ただし、iは動画の初めから終わりまで順番に並んでいるものとします。

$x_{i}$を求める関数は下のような感じで書けます。

def calc_max_serifu_px(img: np.ndarray):
# x = x' (0 <= x' <= img.shape[1]) の直線上に0である画素が2点以上あれば、
# x = x'には黒色の画素があるとみなす
# （1点だけだとノイズの可能性があるため2点とした）
idx_text_pixel = (np.sum(img == 0, axis=0) >= 2).astype(np.int16)
idx = 0 if np.all(idx_text_pixel == 0) else np.where(idx_text_pixel == 1)[0][-1]
return idx

calc_max_serifu_px(new_img_text)

一つ前の画像を見ると、確かにx座標が1570px程度の所までセリフがあります。

先程の2の状態では、セリフはテロップのように流れるため、$x_{i}$は広義の単調増加（単調非減少）です。3の状態に移ると、セリフは全て流れ切っているので$x_{i}$は横ばいです。次のセリフの2の状態に移ると、$x_{i}$はその前の$x_{i-1}$と比べ、大きく変動します。そこから再び$x_{i}$は広義の単調増加となります。これが繰り返されます。

いま取り出したい「ユニークなセリフの画像」は、次の台詞の2の状態に移る直前の3の状態の画像ですから、すなわち以下の2つの条件を満たすiを見つければよいということになります。

$|x_{i-j}-x_{i-(j-1)}|, |x_{i-(j-1)}-x_{i-(j-2)}|, \dots, |x_{i-1}-x_{i}|$の平均が$a$以下（$a$は$a \geq 0$の定数）
- すなわち、$x_{i-j}, x_{i-(j-1)}, \dots, x_{i}$は横ばいということ
$|x_{i}-x_{i+1}| \geq b$（$b$は$b \geq 0$の定数）

j, a, bは事前に決める必要がありますが、色々試した結果$j = 4, a = 2, b = 5$としました。この数値はStep1で動画から静止画を取り出す際の、1秒あたり何枚の画像を取り出すかに影響を受けます。

以上2つのロジックによって、セリフが映っていない画像は削除した上で、ユニークなセリフの画像のみを取り出すことができます。ストーリーを収録したインプットの動画を1時間とすると、Step1で得られた54000枚の画像から、Step2で500枚程度まで減らすことができました。

Step3 画像を超解像で拡大する

Step2で残った画像全てについて、以降のステップでOCRで画像を読み取りますが、その前に超解像でノイズ除去・拡大し、OpenCVでさらにノイズ除去などの前処理を行う必要があります。Step3は前者、Step4は後者です。

超解像というとOpenCVのcv2.dnn_superresを使う手もありますが、waifu2xのcaffe実装であるlltcggie / waifu2x-caffeを用いました。

上のリンクからダウンロード後GUI版を起動し、Step2までで取り出された画像を超解像にかけます。設定値は下記の通りです。

出力拡張子: jpg
出力画質: 95
変換モード: ノイズ除去（自動判別）と拡大
ノイズ除去レベル: レベル3
拡大サイズ: 拡大率で指定（2.0）
モデル: 2次元イラスト（UpRGBモデル）（TTAモードを使わない）
分割サイズ: 128, バッチサイズ: 8

ノイズを除去したうえで縦横2倍に拡大しました。GPUを使って5万枚の画像を4時間程度で処理できました。

Step4 前処理する

import cv2
import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
from google.cloud import vision
from google.oauth2 import service_account
# 表示用の関数
def view(img: np.ndarray) -> None:
plt.imshow(cv2.cvtColor(img,cv2.COLOR_BGR2RGB))
img = cv2.imread("image_waifu2x.jpg")
view(img)

この画像から名前の部分とセリフ部分を切り出します。

# 画像上にマウスポインタを載せるとその場所の座標を
# 取得できる画像ビューア（GIMPなど）を使用し、適当な座標を調べます
name_topleft = [155*2, 550*2]
name_bottomright = [340*2, 580*2]
text_topleft = [155*2, 595*2]
text_bottomright = [1085*2, 670*2]
name_x1, name_y1 = name_topleft[0], name_topleft[1]
name_x2, name_y2 = name_bottomright[0], name_bottomright[1]
text_x1, text_y1 = text_topleft[0], text_topleft[1]
text_x2, text_y2 = text_bottomright[0], text_bottomright[1]
img_name = img[name_y1:name_y2, name_x1:name_x2]
img_text = img[text_y1:text_y2, text_x1:text_x2]

view(img_name)

view(img_text)

名前部分とセリフ部分にバイラテラルフィルタ -> 二値化 -> 収縮をかけます。

文字の縁のノイズを除去するためにバイラテラルフィルタをかけるとともに、文字が比較的太く、線と線がつながりやすく見えるため、収縮をかけて線同士を離します。

def preprocess_img_name(img: np.ndarray) -> np.ndarray:
# パラメータは適当（目視でよさそうなパラメータを適当に採用した）
img = cv2.bilateralFilter(img, d=10, sigmaColor=20, sigmaSpace=20)
img = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY)
_, img = cv2.threshold(img, 0, 255, cv2.THRESH_OTSU)
# パラメータは適当
img = cv2.erode(img, kernel=np.ones((2, 2), np.uint8),iterations=1)
img = cv2.bitwise_not(img)
return img
def preprocess_img_text(img: np.ndarray) -> np.ndarray:
img = cv2.bilateralFilter(img, d=10, sigmaColor=20, sigmaSpace=20)
img = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY)
img = cv2.bitwise_not(img)
_, img = cv2.threshold(img, 0, 255, cv2.THRESH_OTSU)
img = cv2.erode(img, kernel=np.ones((2, 2), np.uint8), iterations=1)
img = cv2.bitwise_not(img)
return img
img_name_preprocessed = preprocess_img_name(img_name)
img_text_preprocessed = preprocess_img_text(img_text)

名前部分とセリフ部分の横幅を揃えて、一枚の画像に結合します。

img_name_preprocessed = cv2.copyMakeBorder(img_name_preprocessed, 10, 10, name_x1 - text_x1, text_x2-name_x2, cv2.BORDER_CONSTANT, value=(255, 255, 255))
img_text_preprocessed = cv2.copyMakeBorder(img_text_preprocessed, 10, 10, 0, 0, cv2.BORDER_CONSTANT, value=(255, 255, 255))
img_preprocessed = cv2.vconcat([img_name_preprocessed, img_text_preprocessed])
view(img_preprocessed)

Step5 OCRにかける

ここまで前処理した画像を、Vision APIを用いてOCRにかけます。月間1000コールまで無料、それ以上は500万コールまでは1000コールごとに1.5ドルとリーズナブルです。

class VisionApi:
def __init__(self, credential_path: str) -> None:
self.credentials = service_account.Credentials.from_service_account_file(credential_path)
self.client = vision.ImageAnnotatorClient(credentials=self.credentials)
def ocr(self, img: np.ndarray) -> str:
content = cv2.imencode(".png", img)[1].tobytes()
vision_img = vision.Image(content=content)
response = self.client.document_text_detection(image=vision_img)
text = response.full_text_annotation.text
return text
# このcredentialのjsonファイルはGCPに登録するとダウンロードできます
va = VisionApi("../python-ocr.json")
texts = va.ocr(img_preprocessed)
texts

'夜峰美晴\nわたし達の声を通して、素敵な風を吹かせられたらいいなって･･･\nそれが、わたし達の進む道･･・・･･、 なんじゃないかな?'

“名前（改行記号）セリフ1行目（改行記号）セリフ2行目”の文字列で返ってきていることを利用し、名前とセリフに分けてpandas.DataFrameにします。

def parse_to_df(texts: list[str]) -> pd.DataFrame:
texts = [i for i in texts.splitlines()]
if len(texts) == 0:
name = ""
line = ""
elif len(texts) == 1:
name = texts[0]
line = ""
else:
name, line = texts[0], texts[1:]
df = pd.DataFrame([{"name": name, "line": line}])
return df
df = parse_to_df(texts)
res = (
df
# たまにセリフがない画像があるので、セリフがない場合は除外する
.loc[lambda d: ~pd.isna(d.line)]
# line列はlist（行が1行だけなら要素数は1、2行なら2）なので、改行を[br]で繋ぐ
.assign(line_joined = lambda d: d.line.map(lambda x: "[br]".join(x)))
)

print(res.name.to_list())

['夜峰美晴']

print(res.line_joined.to_list())

['わたし達の声を通して、素敵な風を吹かせられたらいいなって･･･[br]それが、わたし達の進む道･･・・･･、 なんじゃないかな?']

割といい感じに取れていますね！

実際はこの後、セリフ部分のテキストの正規化が必要になります。というのも、以下のような誤認識が頻発するためです。

句読点の後にスペースが入る
句読点がカンマやピリオドとして認識される
…（三点リーダ）が誤認識される
- ・（中黒）として認識される
- その他、中黒に似た記号として認識される
  - 三点リーダ1個が中黒か中黒に似た記号3個として認識されたりします。
  - 2個や4個として認識されたりもします。
単語の一部文字だけ全く違う文字として認識される

特に記号は難易度が高いですね…。上の画像においても、読点の後に半角スペースが入っていたり、1個の三点リーダが中黒や半角中黒（UnicodeでU+FF65）3個として認識されていたり、また三点リーダが1個減っていたりします。NFKC正規化などで一旦普通の中黒に置き換えてから三点リーダに置換する必要があります。

おわりに

OCR自体はAPIに投げるだけなので楽ですね。時間がかかったのはStep2の漏れなくダブりなく画像を取り出すロジックの考案とStep4の前処理のロジック、Step5のOCRの後のテキストの正規化でした。

VPS（Ubuntu/Debian）でRとPythonとJuliaの開発環境を作る: part3

Mon, 26 Sep 2022 00:00:00 +0900

はじめに

概要

VPS (Ubuntu/Debian) を借りて環境設定する際の、part1より進んだ設定の内容です。この記事の内容は必須ではありませんが、設定しておくとよりセキュリティレベルが上がったり、便利に使ったりすることができます。

取り上げる内容はこちらです。

fail2banの導入
- 繰り返しssh接続を試してくるIPアドレスをBAN
ssmtpの導入
- 監視用の簡易なメール送信クライアント
logwatchの導入
落穂拾い
- 時刻のタイムゾーンをAsia/Tokyoにする
- デフォルトのシェルを変更する
- sysstatの導入
- ベンチマークを取る（Unixbench、speedtest）

環境

VPS
- ConoHa VPS（メモリ1GB）
- Linux
  - Ubuntu: Ubuntu 22.04.1 LTS / Debian: Debian 11
ローカル環境
- Windows 10 Home

fail2ban

VPSを起動してしばらく放っておくと、ssh接続を試みてくるIPアドレスが出現します。

fail2banを導入すると、一定時間以内に一定回数以上ssh接続に失敗したIPアドレスを、一定時間ssh接続できないように弾くことができます。part1の設定の通り、パスワードログインを廃止し、ssh鍵でしかログインできないようにしておけばあまり気にしなくてもいいのですが、fail2banで簡単にBANできるので設定します。

ちなみにssh接続のログは/var/log/auth.logですので、ssh接続を試みてくるIPアドレスは、sudo cat /var/log/auth.logで見ることができます。

まず、fail2banをインストールします。

sudo apt install fail2ban

fail2banは、sshdなどの各種サービスのログファイルを監視するものです。filter, action, jailから構成されます。

filter
- 各種サービスのログファイルにどのような文字列が表れたら攻撃と判定するか
  - /etc/fail2ban/filter.d/*.conf
action
- 攻撃があった場合にどう動作するか
  - /etc/fail2ban/action.d/*.conf
jail
- filterとactionの組み合わせや、actionが発動する閾値（攻撃回数・時間数）などを定める
  - /etc/fail2ban/jail.conf

sshdを含むメジャーなサービスのfilterやactionはデフォルトで用意されているので、ここではjailのルールを編集するだけで導入ができます。

/etc/fail2ban/jail.confはアップデートで書き換えられる恐れがあるそうなので、/etc/fail2ban/jail.localを編集します。

# /etc/fail2ban/jail.localが存在しない場合だけ、最初に作っておく
sudo touch /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

jail.localがnanoで開いたら、以下の4行を記載して保存します。

[sshd]
enabled = true
bantime = 86400
findtime = 3600
maxretry = 10

findtime秒以内にmaxretry回sshの接続に失敗したIPアドレスは、bantime（秒）の間sshの接続をブロックするという意味です。bantime, findtime, maxretryは好みに応じて値を書き換えてください。

保存したらfail2banを起動し、Ubuntu起動時に自動で起動するようにします。今記載したjail.localを反映させるため、既に起動されている場合はsudo systemctl stop fai2banを実行してから以下のコマンドを入力してください。

sudo systemctl start fail2ban
sudo systemctl enable fail2ban

うまく起動できていて、かつ自動起動も有効になっていることを確認します。

sudo systemctl status fail2ban
# 以下の通り表示されればOK
# /lib/systemd/system/fail2ban.service; enabled: Ubuntu起動時に起動する設定になっている
# Active: active: 現在起動している
Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled)
Active: active (running)

なお、この後再度jail.localを書き換えた場合はsudo systemctl restart fail2banでfail2banを再起動してください。

今現在ブロックされているIPアドレスは、こちらで確認できます。

sudo fail2ban-client status sshd

また、fail2banのログである/var/log/fail2ban.logを見ると、filterやaction、banのログが確認できます。

fail2banの基準は当然自分にも当てはまりますので、自分も接続に失敗するとssh接続ができなくなります。自分が引っかかった場合は、ConoHaのWebのコンソールからログインし、以下で解除することができます。（jail.localに自分のIPアドレスをignoreipとして設定すれば自分を除外できますが、固定IPでないとあまり意味がないと思います）

sudo fail2ban-client set sshd unbanip [解除したい自分のIPアドレス]
# 設定を反映する
sudo fail2ban-client restart

sSMTP

sSMTPとはメール送信専用（受信はできない）クライアントです。自前でSMTPサーバを用意せずに外部のSMTPサーバを使ってメールを送信する仕組みであり、Postfixなどより導入が簡単です。

Gmailなどの既に持っているメールアドレスを使ってVPSからメールの送信をしたいという場合に役に立ちます。特に後述のlogwatchでメールを送信する際に使えます。

sudo apt install ssmtp

設定ファイルの/etc/ssmtp/ssmtp.confを編集します。

sudo nano /etc/ssmtp/ssmtp.conf

以下はGmailを使って送信したい場合の例です。イコールの右辺は自分のメール環境に合わせてください。

root=postmaster
mailhub=smtp.gmail.com:587
rewriteDomain=gmail.com
hostname=gmail.com
FromLineOverride=YES
UseSTARTTLS=YES
AuthUser=[YOUR_GMAIL_ACCOUNT_NAME]@gmail.com
AuthPass=[YOUR_GMAIL_LOGIN_PASSWORD]
AuthMethod=LOGIN
TLS_CA_File=/etc/pki/tls/certs/ca-bundle.crt

cronのエラー出力などのroot宛に送られるメールは、1行目のrootの行に書いた宛先に送られます。デフォルトはpostmasterです。

保存したら送信テストをしてみます。以下の通り、インタラクティブにメールを書くことができます。Toで書いたアドレス宛にメールが届けば成功です。

sendmail -t #ここでEnter
From: [受信時に見せたいメールアドレス] #ここでEnter
To: [宛先のメールアドレス] #ここでEnter
Subject: [題名] #ここでEnter
[以下本文] #ここでEnter。書き終わったらCtrl+Dで送信

logwatch

ログを取って1日に1回メールで送ってくれます。

先にsudo apt install ssmtpでsSMTPをインストールしておいてください。

sudo apt install logwatch

デフォルトの設定は/usr/share/logwatch/default.conf/logwatch.confです。これを/etc/logwatch/conf/logwatch.confにコピーし、/etc/logwatch/conf/logwatch.confを編集することにします。

sudo cp /usr/share/logwatch/default.conf/logwatch.conf /etc/logwatch/conf/logwatch.conf
sudo nano /etc/logwatch/conf/logwatch.conf

MailTo: rootと書かれた行があるので、rootを受信したいメールアドレスにします。なお、rootのままにしている場合、sSMTPを導入済で、かつ/etc/ssmtp/ssmtp.confのrootに何らかのメールアドレスを書いていると、そのメールアドレス宛にメールが送られます（logwatchがrootにメールを送り、sSMTPがroot宛のメールを転送するから）。

保存したら、logwatchのテストを行います。以下の2行を順番に実行します。1行目ではコンソールにログが表示され、2行目ではメールが届けば成功です。

logwatch --output stdout
logwatch --output mail

私はこんなエラーが出たのですが、ググったところ/var/cache/logwatchが存在しないことが原因のようで、sudo mkdir /var/cache/logwatchすると正しく動作しました。（参考: Logwatch設定 - keimlab’s diary）

/var/cache/logwatch No such file or directory at /usr/sbin/logwatch line 651.

なお、毎日1回logwatchからメールが届くようになります。というのも、/etc/cron.daily/00logwatchに以下の通り記述されているからです。

#!/bin/bash
#Check if removed-but-not-purged
test -x /usr/share/logwatch/scripts/logwatch.pl || exit 0
#execute
/usr/sbin/logwatch --output mail #これ
#Note: It's possible to force the recipient in above command
#Just pass --mailto address@a.com instead of --output mail

logwatchのメールを受け取りたくない場合は、上の/usr/sbin/logwatch --output mailをコメントアウトするとメールが送られなくなります。

落穂拾い

タイムゾーンをJSTに変更

タイムゾーンはデフォルトではUTCになっていることがあります。以下の通りJSTに変更することができます。

dateコマンドかtimedatectlコマンドで今の時刻を確認します。

JST、あるいはAsia/Tokyoと書いてあればタイムゾーンはJSTになっています。UTCなどと、JST以外の設定になっていたら下記でJSTに変更します。

sudo timedatectl set-timezone Asia/Tokyo

再度dateコマンドかtimedatectlコマンドを実行し、JSTかAsia/Tokyoとあれば成功です。

デフォルトのシェルを変更

デフォルトではshが使われていますが、bashに変えたいという場合は以下の通りコマンドを打ちます。

まずbashのパスを調べます。

which bash

例えば/usr/bin/bashと表示されたら、chshで以下の通り変更します。

chsh -s /usr/bin/bash

再ログインするとbashに変わっているはずです。

sysstat

CPU使用率やメモリ使用量などの情報をリアルタイムで表示したり、過去の値を後から確認するのに使えます。

sudo apt install sysstat

インストールできたら、リアルタイムの情報を確認してみます。

# CPU使用率を1秒間隔で表示する
sar 1
# メモリ使用率を3秒間隔で表示する
sar -r 3

インストール後はCPU使用率などのログが自動的に/var/log/sysstat/[sa + 日付]に保存されています。インストールしてしばらく経ってからsarやsar -rとコマンドを打ってみると、過去のシステム使用状況の情報が見られます。

ベンチマークを取る

Unixbench

システムのパフォーマンスを測定するベンチマークです。ソースはkdlucas/byte-unixbenchにありますので、ここからgit cloneしてビルドします。

cd [byte-unixbenchを展開したい適当なディレクトリ]
git clone https://github.com/kdlucas/byte-unixbench
# ビルドに使う
sudo apt install build-essential
cd byte-unixbench/UnixBench
./Run

数十分ほど待つとベンチマークの結果が表示されます。

Speedtest

回線速度を測定するものです。Speedtest by Ooklaが提供しているCLIツールを使います。

こちらのインストール方法の通りインストールして実行します。

sudo apt install curl
curl -s https://packagecloud.io/install/repositories/ookla/speedtest-cli/script.deb.sh | sudo bash
sudo apt install speedtest
speedtest

参考にしたサイト

VPS（Ubuntu/Debian）でRとPythonとJuliaの開発環境を作る: part2

Thu, 22 Sep 2022 00:00:00 +0900

はじめに

概要

VPS (Ubuntu/Debian) でのRとPythonとJuliaの開発環境の作り方です。このpart2では、R, Python (Miniconda), Julia, Gitの設定方法を書きます。

環境

VPS
- ConoHa VPS（メモリ1GB）
- Linux
  - Ubuntu: Ubuntu 22.04.1 LTS / Debian: Debian 11
- R 4.2.1
- Miniconda 4.12.0 + Python 3.10.4
- Julia 1.7.3
- Git 2.34.1
ローカル環境
- Windows 10 Home

Rのインストール

この章は、UbuntuとDebianで入力するコマンドが異なります。

CRANのトップページに記載の"Download R for Linux"のリンクの通り、以下を実行してインストールします。UbuntuとDebianでリンクが異なりますので、使っているLinuxのディストリビューションに合わせてリンクを参照します。

Ubuntu

sudo apt update -qq
sudo apt install --no-install-recommends software-properties-common dirmngr
wget -qO- https://cloud.r-project.org/bin/linux/ubuntu/marutter_pubkey.asc | sudo tee -a /etc/apt/trusted.gpg.d/cran_ubuntu_key.asc
sudo add-apt-repository "deb https://cloud.r-project.org/bin/linux/ubuntu $(lsb_release -cs)-cran40/"
sudo apt install --no-install-recommends r-base

Debian

sudo apt install software-properties-common
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-key "95C0FAF38DB3CCAD0C080A7BDC78B2DDEABC47B7"
sudo add-apt-repository "deb http://cloud.r-project.org/bin/linux/debian bullseye-cran40/"
sudo apt update
sudo apt install r-base r-base-dev
# どちらか片方（線形代数の計算を高速にするライブラリ）
sudo apt install libatlas3-base
sudo apt install libopenblas-base

UbuntuとDebianのどちらでも、終わったら、Rと入力してRの対話環境が出てくればインストールできています。

install.packages()でライブラリをインストールする際、パッケージがないためにインストールに失敗することがあります。私の環境では少なくともinstall.packages("tidyverse")でこのエラーを確認しました。同じエラーはRでパッケージがインストールできない時の対処法メモでも確認しました。

install.packages()する前に、以下のコマンドでパッケージを入れておくといいと思います。以下のaptのパッケージは、tidyverseのインストールで必要なもの以外に、他のパッケージのインストールで必要なものも含みます（何のパッケージで必要だったか忘れました…）。

sudo apt install build-essential libcurl4-openssl-dev xorg-dev libssl-dev libxml2-dev

Python (Miniconda) のインストール

Miniconda公式のダウンロードページより、インストールしたいバージョンのMinicondaを選び、ダウンロードリンクのURLをローカルにコピーしておきます。ここでは最新版の"https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh"をインストールすることにします。

なお、Linuxのインストーラーはx86やARMなどプラットフォームごとに分かれています。使っているVPSのプラットフォームはuname -mで調べられます。以下、x86の前提で進めていきます。

適当なディレクトリにインストーラーのシェルファイルをwgetでダウンロードして、bashでインストーラーを実行します。ここではユーザーディレクトリ直下にdownloadsディレクトリを作り、そこにダウンロードすることにします。

cd ~
mkdir downloads
cd downloads
wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh
# "Miniconda3-latest-Linux-x86_64.sh"は上のwgetのファイル名と合わせる
bash Miniconda3-latest-Linux-x86_64.sh

次に~/.bashrcをnanoなどの適当なエディタで開き、最終行以降に以下の2行を書いて上書き保存します。私の環境では1行目は既に~/.bashrc内に書いてあったので、2行目だけを記載しました。~/.bashrcがなければtouch ~/.bashrcで作成してください。

export PATH=~/miniconda3/bin:$PATH
source ~/miniconda3/etc/profile.d/conda.sh

1行目はminicondaのパスを通しています。2行目はconda activateのエラー対策です。例えばこの辺をご覧ください。（conda activate の CommandNotFoundError への対処方法 - Qiita）

上書き保存したら以下を実行して、~/.bashrcの内容を読み込みます。これを実行しないと設定内容が反映されません。

source ~/.bashrc

ターミナルからpythonと打ってPythonの対話環境が出れば成功です。

Juliaのインストール

Download Juliaより、インストールしたいバージョンのインストーラーのURLをローカルにコピーしておきます。

適当なフォルダにインストーラーをダウンロードしてから解凍します。ここではユーザーディレクトリ直下にjulia173というディレクトリを作ってそこに解凍しています。

cd ~/downloads
wget https://julialang-s3.julialang.org/bin/linux/x64/1.7/julia-1.7.3-linux-x86_64.tar.gz
mkdir ~/julia173
tar zxvf ~/downloads/julia-1.7.3-linux-x86_64.tar.gz -C ~/julia173

終わったら、Juliaにパスを通すため、最後に~/.bashrcの最終行に次の1行を追記して上書き保存します。julia173/julia-1.7.3の部分は自分の環境のJuliaのディレクトリに変えてください。

export PATH="$PATH:~/julia173/julia-1.7.3/bin"

上書き保存したらMinicondaの場合と同じくsource ~/.bashrcを実行してください。その後juliaと入力してJuliaの対話環境が出れば成功です。

Gitのインストール＋GitHubをsshで使えるようにする

まずaptでGitをインストールします。

sudo apt install git

次に秘密鍵・公開鍵を作り、GitHubに登録します。

まず鍵の作成です。VPSから以下を実行します。

cd ~/.ssh
# 700のパーミッションを設定していない場合は以下で設定する
# chmod 700 ~/.ssh
# -f以降は好きなファイル名にする。これを入力した後、いくつか質問されるが全部Enterを押して大丈夫
ssh-keygen -t ed25519 -f github_conoha

~/.sshに、github_conoha（秘密鍵）、github_conoha.pub（公開鍵）の2つのファイルができています。このうち公開鍵のgithub_conoha.pubをnanoか何か適当なエディタで開き、中身を全選択してクリップボードにコピーします。

そうしたら次に公開鍵をGitHubに登録します。ローカルPCからGitHubを開き、settings > sshから先程の公開鍵を貼り付けます。

再度VPSに戻り、~/.ssh/configに以下を記載して保存すればOKです。（~/.ssh/configが存在しない場合は、touch ~/.ssh/configで作ってください）3行目は先程作った秘密鍵のパスを指定します。

Host github.com
HostName github.com
IdentityFile ~/.ssh/github_conoha
User git

保存したら、以下を実行します。

ssh -T git@github.com

Hi [Your Username]! You've successfully authenticated, but GitHub does not provide shell access.と表示されればGitHubとssh接続ができています。

ここまで終われば、R, Python, Julia, Gitを使える開発環境が整いました。お疲れ様でした。

参考

公式ドキュメント
- R
  - Ubuntu
  - Debian
- Miniconda
  - Installing on Linux
- Julia
  - Platform Specific Instructions for Official Binaries
- GitHub
  - SSH を使用した GitHub への接続 - GitHub Docs

VPS（Ubuntu/Debian）でRとPythonとJuliaの開発環境を作る: part1

Mon, 05 Sep 2022 00:00:00 +0900

はじめに

概要

VPS (Ubuntu/Debian) を借りてRとPythonとJuliaの開発環境を作るところまでの基本的な設定の仕方です。UbuntuでもDebianでもどちらでも同じように設定できます。ConoHa VPSを利用していますが、Ubuntu/DebianであればConoHaではない他のVPSでも同じように進められると思います。

part1ではssh接続の設定について書きます。これらの設定を入れることにします。

rootユーザでのsshログインを許可しない
秘密鍵でのsshログインのみ許可し、パスワードログインを禁止
ポート番号を22番から変更
許可したポート番号以外のポート番号を閉じる

環境

VPS
- ConoHa VPS（メモリ1GB）
- Linux
  - Ubuntu: Ubuntu 22.04.1 LTS / Debian: Debian 11
ローカル環境
- Windows 10 Home

VPS契約

ブラウザからConoHaにログインして新しくVPSを立てます。詳しくは公式のガイドを参照ください。

「接続許可ポート」のオプションは、ポート開放はあとでVPS上からufwで行うので、「全て許可」にチェックを入れます。また、「SSH Key」は、後でローカルで作成するので、「使用しない」にチェックを入れます。

なおConoHaではスペックのグレードを選ぶことができますが、メモリ1GB以上のプランを選んでおくといいです。VPSを立てた後からプランをアップグレード・ダウングレードできますが、512MBプランはその対象外であるためです。

パッケージのアップデート

ローカルのWindowsのコマンドプロンプトを立ち上げ、rootユーザでsshログインします。パスワードを聞かれるので、VPSを立てる時にConoHaの設定画面で入力したrootパスワードを入力してください。

なお、以下、かっこ（[]）で囲った部分は、何らかの値を入れることを示します。実際にコマンドを打つ際はかっこは不要です。

# sshはデフォルトでは22番ポートでログインするので、"-p 22"は付けなくていい
ssh root@[VPSのIPアドレス]

ログイン後、まずはパッケージをアップデートします。

apt update -y
apt upgrade -y
apt dist-upgrade -y
apt --purge autoremove

再起動するようメッセージで求められた場合はrebootで再起動してください。再起動されるまで数十秒程度かかりますので、そのくらいの時間待ってから再度rootユーザでsshログインします。

一般ユーザの作成＋sudoユーザー化

セキュリティの観点からrootユーザではssh接続できないようにします。そのため、sudo権限を持つ一般ユーザーを作成し、このユーザーにsshでログインすることにします。

ここから先、userというユーザー名のユーザーを作成することにします。

# "-m"を付けることで、/home/直下にユーザーフォルダを作成する
useradd -m user

次にsshのログインパスワードを設定します。パスワードを聞かれるので、設定したいパスワードを入力してください。

passwd user

ここまで終わったら、以下id userと入力すると、(sudo)の文字列は出てこないはずです。これは、userがsudo権限を持っていないユーザーであることを示します。

id user
# (sudo)の文字列が出てこない = sudoerではない
# uid=xxxx(user) gid=xxxx(user) groups=xxxx(user)

userをsudoerにします。

gpasswd -a user sudo

ここまで終わったら、id userと入力すると、(sudo)の文字列が表示されるはずです。

id user
# (sudo)の文字列が表示される = sudoer
# uid=xxxx(user) gid=xxxx(user) groups=xxxx(user) xxxx(sudo)

rootでのsshログイン禁止

exitと打ってログインを切ってから、以下をローカルのコマンドプロンプトで打ってuserでログインします（ログインを切らずにsu userでもいいです）。パスワードを入力する必要があるので、passwd userで設定したパスワードを入力してください。

ssh user@[VPSのIPアドレス]

ssh接続の設定ファイルである/etc/ssh/sshd_configを編集します。sudo権限でないと編集できないので、sudoをコマンドの先頭に付けます。

sudo nano /etc/ssh/sshd_config

/etc/ssh/sshd_configがnanoで開きます。PermitRootLogin yesと書いてある行があるので、このyesをnoに書き換え、保存してsshd_configを閉じます。

なお、nanoではCtrl + Oを押してからEnterを押して上書き保存し、次にCtrl + Xで閉じることができます。

上書き保存してnanoを終了できたら、以下のコマンドでsshd_configの変更内容を反映させます。

sudo systemctl restart sshd

rootではsshログインできず、userではログインできることを確認しておく必要があります。

ローカルでコマンドプロンプトを別窓で立ち上げ、ssh root@[VPSのIPアドレス]ではログインできなくなったことを確認しておきます。次にssh user@[VPSのIPアドレス]ではログインできることも確認しておきます。

このとき、今設定のために接続しているコマンドプロンプトは閉じず、別窓でコマンドプロンプトを開くことに注意してください。sshの設定に失敗して接続できなくなった場合、接続できていたコマンドプロンプトを閉じてしまうとsshでログインできなくなってしまいます。（仮にそうなったとしても、ConoHaではブラウザの設定画面からコンソールログインができるはずですが…。）以降もssh接続の設定を変える度に都度接続できることを確認していきますが、必ず今繋いでいるコマンドプロンプトを閉じないで別窓で確認するようにします。

ssh鍵の作成と登録

ローカルに、VPSと接続するための秘密鍵と公開鍵を作ります。

rootユーザでログインしているコマンドプロンプトを閉じてssh接続を切ってから、以下を入力します。ユーザーフォルダ直下に.sshフォルダが存在しなければ先に.sshフォルダを作成してください。-fの後には鍵のファイルに付けたいファイル名を入れます。ここでは仮でhogeとしておきます。

cd [ユーザーフォルダ直下の.sshフォルダのパス]
ssh-keygen -t ed25519 -f hoge

passphraseを入力してくださいなどと3回ほど入力を求められるはずですが、全て何も入力せずにEnterキーを押してください。

そうすると、ユーザーフォルダの直下の.sshフォルダにhogeとhoge.pubという二つのファイルが作られていると思います。前者は秘密鍵、後者は公開鍵です。

次に、今作成した鍵のうち、公開鍵（hoge.pub）をVPSの~/.ssh/authorized_keysに保存します。ssh user@[VPSのIPアドレス]でVPSのuserにsshログインしてから、ターミナルで以下を入力します。

cd ~
mkdir .ssh
chmod 700 .ssh
touch .ssh/authorized_keys
nano .ssh/authorized_keys

nanoで~/.ssh/authorized_keysが開きます。ここでローカルでhoge.pubを開き、中身を全選択 -> クリップボードにコピーし、sshで接続しているコマンドプロンプトのnanoの画面に貼り付けて上書き保存してください。

念のためcat .ssh/authorized_keysを実行し、ローカルのhoge.pubと同じものが貼り付けられていることを確認します。

最後に.ssh/authorized_keysに600のパーミッションを設定します。

chmod 600 .ssh/authorized_keys

ここで、正常に秘密鍵でssh接続できることを確認します。今VPSにssh接続しているコマンドプロンプトとは別窓でコマンドプロンプトを立ち上げ、以下を入力してssh接続できることを確かめてください。

ssh user@[VPSのIPアドレス] -i [ローカルの秘密鍵hogeのフルパス]

パスワードログインの禁止

次に、全てのユーザでパスワードログインできないようにします。

sudo nano /etc/ssh/sshd_config

PasswordAuthentication yesと書いてある行があるので、そのyesをnoに変えて上書き保存します。私の場合、PasswordAuthenticationは2箇所あったので、2箇所ともnoに変えました。

以下で設定を反映させます。

sudo systemctl restart sshd

今ssh接続しているコマンドプロンプトとは別窓でコマンドプロンプトを立ち上げ、パスワード認証ではログインできず、かつ鍵ではログインできることを確認します。

# パスワードログインしてみる
# これはエラーでログインできないことを確認する
ssh user@[VPSのIPアドレス] -o PreferredAuthentications=password
# 次に、鍵でログインしてみる
# これはログインできることを確認する
ssh user@[VPSのIPアドレス] -i [ローカルの秘密鍵hogeのフルパス]

ポート開放＋sshのポート番号の変更

sshのポート番号はデフォルトでは22番ですが、これを他の適当な番号に変えます。

ポート番号は0番～65535番まであり、うち0番～1023番のWell-known Portは他のサービスで使われることもあるので、1024番以上のポートにしましょう。1024番～49151番のRegistered Portも使われていることがあるので、好みが特になければユーザーが自由に使えることになっている49152番以降のポート番号にするといいと思います。ここでは仮に50022番に変更することにします。

まず、念のため50022番がポート番号として使われていないことを確認します。

sudo lsof -i:50022

何もコンソールに表示されなければ使われていないので問題ありません。

ポート開放

ポート開放の設定に使うufwをインストールし、OSが起動した際に自動起動するようにします。

sudo apt install ufw
sudo systemctl enable ufw

それでは次に、ufwを使ってファイアウォールの設定を変更し、50022番を通すようにします。その前に、50022番が開放されていないことを念のため確認します。

sudo ufw status

50022番がallowされていなければ、開放する必要があります。allowされていれば以下の開放の必要はありません。（私が試した所、初期状態では22番のOpenSSHしか開放されていませんでした）

sudo ufw allow 50022

再度sudo ufw statusと打って、50022番がallowとなっていればOKです。

ssh接続のポート番号の変更

そしたら、sshd_configを編集してssh接続に使用するポート番号を変更します。

sudo nano /etc/ssh/sshd_config

Port 22と書いてある行があると思います。この22を50022に変更して上書き保存します。

以下で設定を反映させます。

sudo systemctl restart sshd

最後に、今ssh接続しているコマンドプロンプトとは別窓でコマンドプロンプトを立ち上げ、22番ではログインできず、50022番ではログインできることを確認します。

# これはエラーでログインできないことを確認する
ssh user@[VPSのIPアドレス] -i [ローカルの秘密鍵hogeのフルパス] -p 22
# 次に、これはログインできることを確認する
ssh user@[VPSのIPアドレス] -i [ローカルの秘密鍵hogeのフルパス] -p 50022

これでひとまず最低限のssh接続のセキュリティ確保の設定が終わりました。お疲れ様でした。

ConoHaではVPSのディスクイメージを保存しておくことができます。VPSを削除しても、新しくVPSを作る際に、保存したディスクイメージから復元することができ便利です。この段階で一旦VPSのディスクイメージを作っておくと役立つかもしれません。

ローカルのconfigにsshログインの設定を記載

さて、これからはssh user@[VPSのIPアドレス] -i [ローカルの秘密鍵hogeのフルパス] -p 50022でログインするわけですが、毎回これを入力するのは面倒です。それを簡略化できるように、ローカルの~/.ssh/configにssh接続の設定を記載します。

ローカルのユーザーフォルダ直下の.ssh/configを適当なエディタで開き、以下を追記して上書き保存します。

Host conoha
HostName [VPSのIPアドレス]
User user # VPSで接続したいユーザー名。ここでは先程作ったuser
Port 50022
IdentityFile [上で作成した秘密鍵 (hoge) のフルパス]

Host conohaのconohaは好きな名前にしてください。ただし、.ssh/configの中では一意な名前にする必要があります。

Identity Fileは、Windowsではファイルパスの区切り文字はバックスラッシュですが、バックスラッシュでもUnix風のスラッシュ（~/.ssh/hoge）でもどちらでも構いません。

これにより、今後はssh user@[VPSのIPアドレス] -i [ローカルの秘密鍵hogeのフルパス] -p 50022の代わりにssh conohaでログインできるようになります。

ローカルのVSCodeに拡張機能Remote Developmentをインストール

VSCodeの拡張機能Remote Developmentを入れると、VSCode上でssh接続し、あたかもローカルのファイルを操作しているかのように作業ができます。入れ方は良記事がたくさんあるのでググってみてください。

この拡張機能は色々便利なのですが、VSCodeからssh接続してターミナルでcode [開きたいファイルのパス]と打つと、VSCode上でそのファイルが開かれて編集できることが中々快適です。nano [開きたいファイルのパス]の代わりになります。

ニコニコ動画の検索WebアプリをShinyで作った

Fri, 29 Apr 2022 00:00:00 +0900

概要

ニコニコ動画の検索アプリを作りました。→ニコニコ検索（仮）

公式のニコニコ動画では行えない、以下の検索が可能なのが特徴です。

投稿日時、再生数、コメント数、マイリスト数、いいね数、再生時間をフィルタ条件に指定した検索
検索結果を、コメント率、マイリスト率、いいね率、マイリスト数/コメント数の大小順で表示

使い方

こういう検索ができます。（マイリスト数/コメント数が大きい順に並べたいが、再生数やマイリスト数、コメント数が小さすぎるとマイリス数/コメ数が大きくなりすぎるので、下限を設定している）

作った動機

公式では不可能な、概要に記載した検索方法やソート方法をやってみたかったからです。

ジャンルによっては、良作の動画はマイリスト率が高かったり、マイリスト数＞コメント数となっていたりすることが特徴であることが知られています。そのような動画を見つけるためにこのWebアプリを作ってみました。

ロジック

ニコニコ動画公式のスナップショット検索API v2を叩き、マイリス率などを計算して指定したソート順で並べています。1回のリクエストで最大100件まで取得できるため、検索結果が100件を超える場合は100件ずつ分けてスリープを挟んで全て取得してから指定したソート順で並べます。

このように全て取得することでコメント率やマイリス率、コメ数/マイリス数のソートが可能になりますが、その代わり検索結果数が多くなると結果が返るまでに数十秒要します。

Shinyで実装しており、shinyapps.ioでデプロイしています。

今後やりたいこと

独自ドメイン化
- 折角ドメインを取ったので
- shinyapps.ioで独自ドメインを使うには299ドル/月のProfessionalコースに入らないといけないようなのでHerokuへの移植を検討中

RMarkdownにhighlight.jsのcssテーマを適用する

Thu, 18 Feb 2021 00:00:00 +0900

RMarkdownにhighlight.jsのcssテーマを適用する

highlight.jsのcssテーマを用いてRMarkdownのコードハイライトを変更する方法を示します。

以下の記事にあるように、RMarkdownはYAML部分のオプションを用いてコード部分のハイライトを変更することができます。設定できるコードハイライトのテーマはdefault,tango,pygments,kate,monochrome,espresso,zenburn,haddock,textmateの9個です。

R Markdownでコードハイライトのテーマ設定

もっと多くのハイライトテーマを使うには、例えばhighlight.jsを用いる方法があります。2021年2月のバージョン10.5.0時点で97パターンあります。

そこで、highlightjs と highlightjs-line-numbers プラグインで Rmarkdown のコードブロックに行番号をつけるを参考にしながら、highlight.jsのcssテーマをRMarkdownのコードハイライトに当てる方法を考えました。

結論としては、以下のコードをRMarkdownのYAML部分の直下（＝本文部分の先頭）に記載します。

<style type="text/css">
@import "https://cdnjs.cloudflare.com/ajax/libs/highlight.js/10.5.0/styles/rainbow.min.css";
</style>
```{css, echo=FALSE}
pre{
border: transparent;
background: transparent;
padding: 0px;
}
/* preのpadding 9.5px + border 1px */
code.hljs{
padding: 10.5px;
}
```

@importで読み込むhighlight.jsのCDNのアドレスの最後の"rainbow.min.css"の"rainbow"は、highlight.jsのGitHubのリポジトリにある"テーマ名.css"の"テーマ名"です。highlight.jsのdemoで使いたいテーマを見つけたら、このリポジトリからテーマ名を探します。CDNで読み込むときはテーマ名に.minを付けます。

RMarkdownのコードブロックでは、border: 1px, padding: 9.5pxのpreという要素の中に、code.hljsという要素のコード部分が存在します。上のコードの最初の3行（style～/style部分）だけをRMarkdownに書いてcssを変更しないと、code.hljsはテーマの背景に変わっているのに、borderとpaddingはデフォルトのグレーのまま残ってしまいます。highlight.jsのcssはcode.hljsにかかるので、上のようにpreのborderとbackgroundをcode.hljsの透過としてpaddingをいじることで、見た目をうまく調節しています。

なお、上記ではborderをtransparentにしているので、背景が白系のテーマだと、コードとそれ以外のブロックの区別が付きません。その場合はborder: transparent;を削除すると、枠線だけ残ります。

おまけ（フォント変更）

以下を追加することで、RMarkdownのコード部分のフォントをコード用のフォントに変えられます。インラインのコードのフォントも変わります。

```{css, echo=FALSE}
code{
font-family: SFMono-Regular, Consolas, Liberation Mono, Menlo, monospace;
}
```

RStudioのデフォルトのフォントにする場合は以下です。

```{css, echo=FALSE}
code{
font-family: Lucida Console, monospace;
}
```

環境

Rは4.0.2、RMarkdownは2.7、highlight.jsは10.5.0のバージョンを使用しています。

RMeCabで形態素解析した結果をtidy textなdata.frameで取得する

Mon, 08 Feb 2021 00:00:00 +0900

RMeCabを使っていると、品詞や品詞細分類、読みなどの結果をdata.frameの形で取得したいと思うことがあります。ここでは、品詞についての全ての結果と、品詞情報のみをdata.frameで取得する方法を示します。

例として、以下のtextを形態素解析します。

library(tidyverse)
library(magrittr)
library(RMeCab)
text <- c("吾輩は猫である。","名前はまだない。")

全結果を取得する場合

以下のように、RMeCabText関数は、一つ一つの形態素ごとに「表層形」、「品詞」、「品詞細分類1」、「品詞細分類2」、「品詞細分類3」、「活用形1」、「活用形2」、「原形」、「読み」、「発音」の長さ10のベクトルを要素に持つリストを作ります。

tmp <- tempfile()
write(text[1],tmp)
rmecab_text <- RMeCabText(tmp)

rmecab_text %>%
head(3)

## [[1]]
## [1] "吾輩" "名詞" "代名詞" "一般" "*" "*"
## [7] "*" "吾輩" "ワガハイ" "ワガハイ"
##
## [[2]]
## [1] "は" "助詞" "係助詞" "*" "*" "*" "*" "は"
## [9] "ハ" "ワ"
##
## [[3]]
## [1] "猫" "名詞" "一般" "*" "*" "*" "*" "猫" "ネコ" "ネコ"

なお、RMeCabTextはファイルから読み込むため、R上のオブジェクトをRMeCabTextに掛ける場合はtempfileで一時ファイルを作ってそれを読み込む形をとります。

ということは、textの各要素についてRMeCabTextを行い、各結果のリストをflatten_chrして全部繋げてから10列のdata.frameにすれば欲しい結果が得られます。

res1 <- text %>%
map(function(x){
tmp <- tempfile()
write(x,tmp)
func <- quietly(RMeCabText)
res <- func(tmp)$result
res_df <- res %>%
flatten_chr() %>%
matrix(ncol=10,byrow=TRUE) %>%
as.data.frame() %>%
set_colnames(c("surface","pos","pos1","pos2","pos3","form1","form2","base","yomi","hatsuon"))
file.remove(tmp)
return(res_df)
}) %>%
# textの何番目の要素を形態素解析したかというidを付けておく
enframe(name="id",value="value") %>%
unnest(value) %>%
# tibbleをdata.frameに直す（直さなくてもいい）
as.data.frame()
res1

## id surface pos pos1 pos2 pos3 form1 form2 base yomi
## 1 1 吾輩 名詞 代名詞 一般 * * * 吾輩 ワガハイ
## 2 1 は 助詞 係助詞 * * * * は ハ
## 3 1 猫 名詞 一般 * * * * 猫 ネコ
## 4 1 で 助動詞 * * * 特殊・ダ 連用形 だ デ
## 5 1 ある 助動詞 * * * 五段・ラ行アル 基本形 ある アル
## 6 1 。 記号 句点 * * * * 。 。
## 7 2 名前 名詞 一般 * * * * 名前 ナマエ
## 8 2 は 助詞 係助詞 * * * * は ハ
## 9 2 まだ 副詞 助詞類接続 * * * * まだ マダ
## 10 2 ない 形容詞 自立 * * 形容詞・アウオ段 基本形 ない ナイ
## 11 2 。 記号 句点 * * * * 。 。
## hatsuon
## 1 ワガハイ
## 2 ワ
## 3 ネコ
## 4 デ
## 5 アル
## 6 。
## 7 ナマエ
## 8 ワ
## 9 マダ
## 10 ナイ
## 11 。

RMeCabTextは読み込んだファイルパスをコンソールに出力します。これはありがたいのですが、今回読み込んでいるのは一時ファイルであり、しかもtextの1要素ずつ一時ファイルを作っているためにコンソールの出力がすごい量になるので、purrr::quietlyを用いて出力しないようにしています。

今形態素解析にかけたtextはベクトルでしたが、実際の分析では以下のようなdata.frameの場合もよくあります。

df <- data.frame(sentence_id=1:2,text=text)
df

## sentence_id text
## 1 1 吾輩は猫である。
## 2 2 名前はまだない。

その場合でも、一発でtext列と紐付いた結果が得られますね。

left_join(df,res1,by=c("sentence_id"="id")) %>%
head(3)

## sentence_id text surface pos pos1 pos2 pos3 form1 form2 base
## 1 1 吾輩は猫である。 吾輩 名詞 代名詞 一般 * * * 吾輩
## 2 1 吾輩は猫である。 は 助詞 係助詞 * * * * は
## 3 1 吾輩は猫である。 猫 名詞 一般 * * * * 猫
## yomi hatsuon
## 1 ワガハイ ワガハイ
## 2 ハ ワ
## 3 ネコ ネコ

このような綺麗な形式のdata.frameが得られると、その後の分析が楽になりますね。

語と品詞だけあればよい場合

品詞細分類などの列は不要であり、形態素解析された語と品詞の列だけあれば十分という場合も多いです。

この場合、上記のコードを実行後にselectで必要な列のみ選択してもいいのですが、以下のRMeCabCを用いる方法もあります。

RMeCabCはベクトルを引数に取り、以下のような返り値を返します。

RMeCabC(text[1]) %>%
head(3)

## [[1]]
## 名詞
## "吾輩"
##
## [[2]]
## 助詞
## "は"
##
## [[3]]
## 名詞
## "猫"

ということは、flatten_chrすれば、分かち書きされた結果のベクトルに、品詞情報が名前として付いた名前付きベクトルが得られるので、以下のようにすれば欲しい結果が得られます。

res2 <- text %>%
map(function(x){
mecab_raw <- RMeCabC(x)
mecab_vec <- flatten_chr(mecab_raw)
mecab_df <- data.frame(surface=mecab_vec,pos=names(mecab_vec))
return(mecab_df)
}) %>%
enframe(name="id",value="value") %>%
unnest(value) %>%
as.data.frame()
res2 %>%
head

## id surface pos
## 1 1 吾輩 名詞
## 2 1 は 助詞
## 3 1 猫 名詞
## 4 1 で 助動詞
## 5 1 ある 助動詞
## 6 1 。 記号

形態素解析にかけたいtextがdata.frameの形式の場合でも、先の例と同様にすれば結果が得られます。

purrr様々ですね。

tidy text

tidy textという概念があります。tidy textについては以下の書籍が詳しいです。

Rによるテキストマイニング ―tidytextを活用したデータ分析と可視化の基礎

これは、以下の英語の原文を和訳したものです。

Text Mining with R

原文の第1章冒頭で、tidy textは以下のように定義されています。

“We thus define the tidy text format as being a table with one-token-per-row. A token is a meaningful unit of text, such as a word, that we are interested in using for analysis, and tokenization is the process of splitting text into tokens.”

1行につき1トークン（単語や形態素など）のdata.frameの形でトークンが記載されているデータのことです。この記事で紹介した方法では、形態素解析の結果がtidy textな形式で得られるので、その後のデータの加工が容易になるというメリットがあります。

Stan on suzuna's memo

ConoHaオブジェクトストレージをboto3で使ってみる

ConoHaオブジェクトストレージとは

事前準備

オブジェクトストレージの契約

APIユーザーの作成

EC2 Credentialの発行

boto3を使ってConoHaオブジェクトストレージで遊んでみる

clientインスタンスの作成

コンテナの作成

コンテナのリストアップ

オブジェクトのアップロード

オブジェクトのリストアップ

オブジェクトのダウンロード

Presigned URLの発行

オブジェクトの削除

コンテナの削除

おわりに

多変量確率的ボラティリティモデルで相関係数の時変性をとらえる

はじめに

相関係数のモデリングの重要性

モデル

実装

結果

補足

おわりに

参考文献

plotnineで非営業日を軸から除いたプロットを描く

機械学習によるレコメンドエンジンで自分に小説をおすすめした

はじめに

スクレイピング

Implicit Matrix Factorizationのアルゴリズム

明示的評価値と暗黙的評価値

行列分解によるレコメンドエンジン

Implicit Matrix Factorization

実装

評価値行列の作成

モデルの学習

レコメンド

おわりに

参考文献

t分布を用いたロバストな家賃相場の階層ベイズモデリング

はじめに

データ

外れ値の存在

モデル

実装

結果

パラメータ

最寄り駅ごとの家賃相場

WAICによる汎化誤差の比較

おわりに

参考文献

東京23区の賃貸マンションの家賃相場を階層ベイズで推定する（2024年12月版）

はじめに

データ

データ取得と前処理

使用するデータ

モデル

実装

結果

パラメータ

築年数効果、駅徒歩分数効果、階数効果、最上階・1階・地下1階効果

最寄り駅ごとの家賃相場

おわりに

Rで画像をドット絵化する

はじめに

ロジック

実装

画像の読み込み

平均プーリングによる減色

k-means

結果

おわりに

関連リンク

Realized Volatilityの理論と実装

はじめに

理論

連続過程

ジャンプ過程

読んだ: 「やりたいことが今すぐわかる逆引きGit入門」