Author: Kenichi Kurihara

THEOを毎月積立でしばらく放置していたので、過去の運用実績を計算してみました。計算間違っていたらすみません。2019年4月¹から同じ額で積み立てているので2019年4月から2022年11月までの年率リターンと年率リスク(年率標準偏差)を計算してみました²。参考に、同じ時期のｅＭＡＸＩＳ Ｓｌｉｍ 米国株式（Ｓ＆Ｐ５００）と2020年1月までのTHEOが公式に公開している平均リスクとリターンも表にまとめています。

	私のTHEO実績	eMAXISSlim S&P500	THEO 公式公開情報
期間	2019/4 – 2022/11	2019/4 – 2022/11	2016/3 – 2020/1
年率リターン	7.3%	16.7%	7%
年率リスク	13.6%	18.8%	~12%

私のTHEOの実績はeMAXISSlim S&P500と比較すると、ちゃんとリスクは下がってます。THEO公式が公開しているデータの7%リターンあたりのリスクが12%強なので、私の実績とほぼ一致しています。

THEOにしろ似た様な商品にしろ、手数料は取られますが、全て自動で購入とリバランスをしてくれるのは便利かなと思います。専門家でないので、このリスクとリターンのバランスが妥当なのかはっきりとは言えませんが悪くはなさそうに思えます。個人的には私の実績が公開データとほぼ一致していて安心しました。

脚注

1. ちなみに、私の2019/4のTHEOの口座は二桁万円入っていたので、一応それなりにポートフォリオは分散されていました。
2. 残念ながらTHEOは過去の評価額をダウンロードできないみたいです。仕方ないので、手で月末の評価額を拾いました。ちょっと面倒だった。

AiraloというアプリからeSIMを何度かインストールしたことがあり、今回もインストールしようとしたところ、アクティベーションがなかなか終わらない。

しばらくすると、アクティベーションに失敗したと表示された。Airaloのアプリの中にサポートへのチャット機能があるので、アクティベーションに失敗したことを伝えると、30分位の後に返事が来た。

アメリカのeSIMはアメリカにいないとアクティベーションされないとのこと。知らなかった。今までは、日本を含む世界中で使用可能なeSIMを使用してたので、日本でアクティベーションに成功していたのでしょう。

アメリカに到着後、無事に使えるようになりました。若干使えるようになるまで時間がかかったので、到着すぐにeSIMを使いたいなら、ひょっとすると全世界で使えるプランを選んだ方がいいかもしれません。ちなみに、今までの経験では、Airaloはスイス、イスラエル、アメリカで使えました。

突然Bluetoothがつながらなりました。記事のタイトルのように「接続が拒否されました」とエラーがでてました。ちなみに、英語UIだと”Connection Rejected”となるようです。いろいろ調べたところ、Bluetoothをリセットするコマンドを発見して、実際それで接続できるようになりました。

sudo pkill bluetoothd

PRAMリセットやSMCリセットやBluetoothデバイスを登録し直したりいろいろしたんですが、どれもだめでしたが、上記のコマンドはうまくいきました。ひょっとすると、Bluetoothデバイスをたくさん登録しすぎて、設定がおかしくなってたのかもしれません。

MacのterminalのVimでPythonフォーマッターのBlackを使おうとしたら、タイトルのようなエラーが出たのであれこれしましたが、結局

$ brew install vim

で/opt/homebrew/bin/vimを使えば解決しました。/usr/bin/vimだとMacに標準のpython2.7が起動していた模様。そちらをどうやって直すかまでは調べてません。

気がついたらiPhoneのバックアップが止まってました。iCloudの空き容量が足りなくなってバックアップができないようでした。もっと調べると、Nintendo Switchからコピーした動画が結構な容量になっていたことが分かりました。ローカルファイルをバックアップの対象から外せばいいのは分かったのですが、「ファイル」アプリをバックアップから外しても、ローカルファイルのバックアップは行われるようです。

色々試行錯誤して分かったのは、動画ファイルをVLCアプリのフォルダに入れて、VLCをバックアップから外すと、見事に問題の動画ファイルをバックアップから外せました。特定のアプリをiCloudバックアップから外す方法はこちら。

アプリはVLCでなくても他のアプリでも大丈夫だと思います。もしローカルファイルのせいでバックアップの容量不足になったら、こんな方法でも解決できるようです。

上記のような注意が出てました。PHPにセキュリティ問題があるから、PHPのバージョンをアップデートしなさいということです。

私のWordPressの環境はBitnamiのGCP向けのWordPressのパッケージです。残念ながら、Bitnamiはパッケージの中のソフトウェアを個別にアップデートすることは公式にサポートしてません。

仕方ないので、GCPに一からBitnamiのWordPressをインストールしました。時間かかるので、できるだけ避けたい作業ですね。All-in-One WP Migrationとか使えば、コンテンツの移行は楽になるかと思います。私のサイトは個人ページなので、ダウンタイムとか気にしませんでしたが、ダウンタイムを避けたい、または最小限にしたい状況だと丁寧に仕事をしなくてはいけないので、より厄介になります。Bitnamiを利用する際の欠点かと思います。

落ち着いてwordpress.comにログインして、

My Sites → Settings → Security → Prevent brute force login attacks

もしくは

管理 → 設定 → セキュリティ → 総当たりログイン攻撃を防止

から自分のIPを登録したら大丈夫。wordpress.orgのこちらのフォーラムページを参考にしました。

WordPressのHTTPSの設定を終えたつもりでいたらうっかりWP_SITEURLとWP_HOMEのプロトコルをHTTPからHTTPSに書き換え忘れてました。/opt/bitnami/apps/wordpress/htdocs/wp-config.phpのWP_SITEURLとWP_HOMEを以下のように書き換えるべきです。

define('WP_SITEURL', 'https://' . $_SERVER['HTTP_HOST'] . '/');
define('WP_HOME', 'https://' . $_SERVER['HTTP_HOST'] . '/');

この書き換えを忘れている間、ブログポストの編集をしようとすると”you are probably offline”というエラーが出ていました。最初はなんでそんなエラーが起きるのかさっぱり分かりませんでしたが、同じエラーの人を探してるとWP_SITEURLとWP_HOMEのことを書いている人がいたので、参考にさせてもらいました。

All-in-one WP Migrationのimportするためにアップロードサイズの最大サイズがひっかかったので、設定ファイルをいじった。私が使っているのはBitnamiのWordPress NGINXのパッケージなので対応する公式ドキュメントは以下のもの。

https://docs.bitnami.com/bch/apps/wordpress-pro/administration/increase-upload-limit-php/

/opt/bitnami/php/etc/php.ini を以下のように変更

; Maximum size of POST data that PHP will accept.

post_max_size = 16M
; Maximum allowed size for uploaded files.

upload_max_filesize = 16M

/opt/bitnami/nginx/conf/nginx.conf を以下のように変更

http {

...

client_max_body_size 16M;

...

サーバースタックを再起動

sudo /opt/bitnami/ctlscript.sh restart