EXP21の付属品について

付属品は写真の通りである。順に挙げていくと、

• バンパーケース
• 65W HyperCharge対応急速充電器及びTypeC to C ケーブル、USB Standard-A to TypeCケーブル
• ワイヤレスイヤフォン”Premium Earbuds” 及び充電ケース
• SIMピン
• 説明書等の書類

の上記5種類である。

ワイヤレスイヤフォンについて

イヤーピースは予め取り付けられているものの他に4セット付属していた。サイズについては確認していない。

中身はMaster & Dynamic社の完全ワイヤレスイヤフォンMW08Sとなる。

型番的にMW08をベースモデルとしているようだが、ベースモデルの方はSnapdragon Sound対応を謳っていないのに対し、こちらはもちろんSnapdragon Soundに対応していることと、アプリ側で「MW08S」と識別されているので、全く同じというわけではないのだろう。イヤフォンのレビューはこちらで行っている。

イヤフォンのケースは、充電用のUSB Type-Cポートを備えている。 ワイヤレス充電には非対応である。 充電は約5V⎓1Aの5Wで行われ、赤いインジケータが表示された状態(29％以下)から充電し100％になるまで1時間程かかった。

EXP21フォトレビュー:存在感を放つSnapdragonロゴ

開封の儀セッションの最後は写真と共にEXP21の外観をチェックしていく。

EXP21の背面について:Snapdragonここに在り

一際目を惹くのはやはり、Snapdragonの代紋だろう。白く光るが、天下のSnapdragonがここにあるということを主張する以上の意味は持たない。Snapdragonであるという価値を示すためのものだ。

今となっては珍しいことに、背面に指紋センサを搭載する。指紋センサに関しては別項でレビューするが、これがまた使いにくい。質感の違いから、自分が指紋センサを触っているのか背面を撫でているのかはわかるものの、見ての通りシームレスに取り付けられているため位置が分かりにくく慣れが必要だ。精度や速度に申し分ないだけに、かなり惜しいと感じる。

カメラ部分は分厚く出っ張っている。厚さはSIMカード3枚分といったところか(図 16 (a))。 参考までにROG Phone5 UltimateはSIMカード1.5枚ほどの厚さだ(図 16 (b))。 両者の厚さの違いは光学式手ぶれ補正(OIS)の違いに起因すると考えられる。

EXP21のスペック

一通りスペックをなぞってみたがスペックシート上は何一つ不満がなく、特に対応bandなど圧巻と言ってもいいだろう。筆者は別にアンテナ設計に詳しいわけではないが、一般的に数多くのband(周波数)に対応させるには技術がいると聞く。

特に周波数帯の高いミリ波などは扱いが難しいとされている中、周波数帯を決め打ちするならまだしもn257, n258, n260, n261に対応(つまり、26GHz、28GHz、跳んで39GHz)とASUSはよくもまあこんなに詰め込んでみせたものだと感心した。

これはASUS信者の目線だが、Qualcommが初めて一般発売するリファレンススマホを手掛ける会社としてASUSを選んだのも、ASUSがマザーボードのトップを走りそして長年スマートフォンを手掛けてきた信頼と実績があるからだろう。

さて、詰め込んだと聞いて、不安になるのが発熱やそれに伴う熱暴走だろう。「処理性能について」ではそんな懸念を検証しているため、気になる方はそちらをご覧いただきたい。

◎綺麗/便利なカメラ

筆者の使う範囲では文句なしに綺麗な写真が撮れるメインカメラを搭載しており、なおかつGoogleレンズにワンタッチで接続出来るUIも良い。

超広角カメラもメインカメラと間違える程綺麗に撮れる。

望遠カメラは、光学式手ブレ補正の存在が地味に助かるシーンが多かった。

◎最新のゲーミングスマホに引けを取らないマシンスペック

AnTuTuベンチマークテストでは最上位のゲーミングスマートフォンであるROG Phone5 Ultimateをも上回るスコアを叩き出した。

連続してベンチマークテストをするとスコアはROG Phone5を下回っていったが、それでもなお1年前のハイエンドゲーミングスマホ(空冷クーラー付き)には勝るスコアであった。※AnTuTuベンチマークテストの結果はこちら

CPUやGPUだけでなく144Hzのリフレッシュレートを備えたディスプレイや高速かつ大容量のストレージを備えるなど、スペックだけみればゲーミングスマホそのものだ。EXP21でゲームをして負けることがあっても、それはスマホのせいではないだろう。

とはいえ、ゲーミングスマホでは必須となったショルダーボタン（L1/R1ボタン）や純正冷却ファンが存在しないといった点や、そもそもゲームをアシストするソフトウェアを備えない点から、いくら性能が高くともEXP21をゲーム用のスマホとして購入することはおすすめ出来ない。EXP21の文句なしのマシンパワーはゲームをするために高められているのではないのだ。

◎512GBと大容量かつ高速な内蔵ストレージ

マシンスペックを語る際にも触れたが、EXP21は読み書き共に高速な512GBストレージを搭載している。 規格はUFS3.1というものが使われており、その速度を測ったところ、Read（Input）が1985MB/s, Write（Output）が785MB/sのため、スマートフォンとして使う上で不満になることがまずない。超高速かつ大容量なストレージを備えるため、これならmicroSDカードスロット非搭載な点も納得は出来る。

◎万が一の時も安心なQualcomm QuickCharge5.0急速充電

独自の急速充電規格では速くても、一般的な急速充電規格に対応していなければ、良さは半減してしまう。

しかし、EXP21は違う。一般的なUSB PD PPSや急速充電規格の最大手であるQualcomm QuickChargeに対応している。そのため、「普通の」モバイルバッテリーやACアダプターでも急速充電が可能だ。

実際、Qualcommの規格ではなくUSBとしての規格であるUSB PD PPSに対応したモバイルバッテリーを使っても約30Wで充電され、20%から100%になるまで、僅か59分しかかからなかった。

※なお、充電速度は満充電（100％）に近づく程遅くなっている。実用に際して「絶対に100％まで充電したい！」ということは少なく、95％程度で良しとするならもっと早く済む。

ちなみに付属品である純正ACアダプターで充電した際にも同様に30W程で充電され52分（20%→100%）だったので、わざわざデカくてプラグの折り畳めない付属のACアダプターを持ち歩く必要はない点が素晴らしい。※急速充電の検証はこちら

◎普段は充電速度や電池持ち残量を制御し「長く使う」選択肢も選べるASUSらしさ

急速充電は確かに便利だ。万が一充電を忘れてもさっと充電出来るし、外出先でも困らない。 とはいえ、例えば寝る時にまで急速充電をする必要はない。いくら対策は練られているとは言え、発熱やバッテリー劣化が気になって寝られないなんて人もいるかもしれない。

ASUSスマートフォンはそういった声にも応え、「スケジュール充電」や「低速充電モード」さらには「80%（90%）充電制限」といったバッテリー劣化を抑える（バッテリーケア）機能も用意している。

数々のASUSらしい嬉しい機能が取り除かれ、ピュアなAndroidに近くなっているEXP21だが、バッテリーケア機能が残されたのは嬉しい。

◎音質良し接続性良しの完全ワイヤレスイヤフォン付属

付属品の完全ワイヤレスイヤフォンの外観はフォトセクションで示した通り(図 12 (d))だが、高音質かつ低遅延を両立していて最高である。雑踏でも音が途切れないのも素晴らしい。 この付属品は非売品であるものの、姉妹モデル(これと違いSnapdragon Soundには非対応)のMW08が3万7千円を下回ることがないので、より上位モデルとなるこの「MW08S」は4万円くらいの代物だろう。そう考えるとEXP21は実質12万円程度とお安くなってしまう。※付属する完全ワイヤレスイヤフォンの詳細はこちら

◎抜群なアンテナ感度と通信速度

詳細はこちらの通りであるが、最強のゲーミングスマホROG Phone5 Ultimateと比較してWi-Fiの受信信号強度が高く、アンテナ性能が良いことが分かった。Wi-Fiの通信速度はなんと2401Mbpsのリンク速度を表示するため、最新のパソコン並のWi-Fi性能(Wi-Fi6 160MHz×2ストリーム)である。※Wi-Fi速度の詳細はこちら

◎綺麗かつヌルヌル動く動くディスプレイ

こちらで検証した通り、綺麗な発色と144Hzの高リフレッシュレートを両立している。カタログスペックによれば111.23% DCI-P3の色域でかつ色精度がDelta-E <1なのだから、鮮やかかつ正確な発色だ。筆者としては今の解像度に全く不満はないが、2448 x 1080ドットなので、4Kディスプレイにはならないところがカタログスペック上唯一の弱点だろうか。実際にはスマホのディスプレイサイズで4Kにしたところで…と言ったところなのでスマホとして使う分には問題ないだろう。

明るさは800nitが保証されており(おそらくこれがディスプレイ全体の最大輝度)、最大1200nitのピーク輝度(画面の一部を点灯させた際の最大輝度)になっている。ピーク輝度の方はHDRコンテンツの視聴等で役立つだろう。なお、筆者が秋空の下で試したところ800nitでも問題なかった。※ディスプレイ性能についてはこちら

○AOSP（ピュアAndroid）っぽいUI

筆者は生粋のASUS信者のため、無個性なAOSPライクなUIよりも使い慣れておりかつ便利なZenUI、つまりASUSのカスタマイズが施されたスマホの方が嬉しい。

とは言え一般的にはAOSP、つまりピュアなAndroidの方がスマホを買い替えたり(あるいは複数台使うときに)戸惑わないし、何より余計なカスタマイズがない分OSアップデートが早い(だろう)から喜ばれるのだろう。

EXP21が特殊なスマートフォンなので、2台目のスマホとして非ASUSユーザーから選ばれることも十分想定される。もともと最近のASUSスマホがAOSPライクになってきた中、さらに純度を高めたEXP21はそういった面では好ましい。

○指紋や顔認証の「速度」や「精度」は良い

少なくとも顔認証は何1つ不満がない。マスクをしたままでも行える点も良いし速度もワンテンポだけ遅く、カメラを見つめる間があるが、ストレスになる程ではない。

指紋認証も、速度は爆速だ。0.1秒、指で指紋センサを弾くように叩くだけで認証される。精度も問題なく、同じ指であれば先端でもサイドでも（しっかり指紋登録をしていれば）問題なく認証されるし、逆に他の指ではもちろん弾かれる。※顔認証や指紋認証の詳細はこちら

速度や精度は問題ないのだ。含みを持たせた言い方だが、くどくなるのでその詳細は指紋センサーについてや、 「×指紋センサーの見つけにくさ」をご覧いただきたい。

○デュアルフロントではないものの本体スピーカーの質も良い

ROG Phoneシリーズとは違い、デュアルフロントスピーカーではないものの、本体の画面上部と、側面(底部)にスピーカーを備えるため、大きな違和感(左右差をおぼえること)なくステレオを楽しむ事ができる。

最大音量がけっこう大きくなおかつ目立った音割れはしなかったため、スマートフォンのスピーカーとしてはかなり上位のものとなるのではないだろうか。

△防水非対応

まあ、ASUSスマートフォンで防水に対応しているのは初代ROG Phone（IPX4のお守り程度の生活防水）とZenfone8(IP68防水防塵)くらいで、ASUS自体あまり防水スマートフォンに力を入れていなかったので、まあ仕方ないと諦めるしかない。 （EXP21も端子やスピーカー周りに浸水防止のキャップを付けるくらいのことはやってそうだが、水没させたら完全にアウトだろう）

△指紋センサーが「指紋認証」にしか使えない

画面が大きいので、通知バーをスワイプさせる時に背面の指紋センサーで代用できれば便利なのだが、ZenFone6で出来たことがEXP21では出来ない。

そのため片手で通知バーを下ろすには、不便になったASUSの改悪版「片手モード」で画面全体を下に下げてスワイプするしかない。片手モードの改悪については、EXP21と直接関係ない(EXP21は改悪版片手モードがデフォルト搭載だった)ため、ここではこれ以上深堀りしないことにする。

とにかく、指紋センサーが指紋センサーとしてしか使えないので、背面に置かれている意味が半減してしまっている。

△有線接続でのファイル転送が遅い

USB 2.0と紛う程遅い。ファイルサイズに関わらず300Mbps程度しか出せずWi-Fiで転送した方が速いというのはいかがなものか。せっかくの高速内蔵ストレージなのだから、USB 3.1 Gen2（10Gbps）の転送速度を出してくれても良さそうなのだが…※USBでの転送速度についてはこちら

△3.5mmオーディオジャック非搭載

これはまあ、付属品の完全ワイヤレスイヤフォンMW08SとSnapdragon Sound technologyが素晴らしいので許せる。許せるが、別に3.5mmオーディオジャックがあって困ることはないので、非搭載なことを△とした。EXP21とMW08Sの組み合わせで使う分にはなくても困らない。

△microSDカードスロット非搭載

まあ、これも内蔵ストレージが512GBもあってなおかつUFS3.1と高速なので許せる範囲だ。

△「片手モード」が使いにくい

EXP21の片手モードは、iOSの「簡易アクセス」やAndroid12標準機能？の片手モードと同じ、画面が下半分にスライドする(筆者にとって)不便な片手モードだ(図 28 (a))。画面を縮小するタイプの片手モード(図 28 (b))の方が使いやすいと考えているため、これは受け入れがたい。

写真は都合上ROG Phone5のものを使用しているが、EXP21でも同様である。

△デカくて重い

仕方のないことだが、デカくて重い。デカいのは、建前としては「5Gで提供されるリッチなコンテンツを大画面で楽しむため」とかそういったところだろう。実際は、内部設計的にコンパクトサイズに収めるのは無理があったからに違いない。その証左に、同じサイズでROG Phone5は6000mAhのバッテリーを搭載しているところ、EXP21は4000mAhだ。内部設計の余裕がないことが容易に想像出来る。

重さは210gだ。まあ、最近のスマートフォンは200gも超えることも珍しくない。ROG Phone5なぞ(6000mAhの大容量バッテリーを搭載していることもあり)239gだ。ちなみに、iPhone 13Pro Maxも同じような画面サイズ(6.7インチ)で238gだ。もう、このサイズのスマートフォンになると重いのは仕方のないことなのだろう。

△ワイヤレス充電非対応

Qualcomはワイヤレス充電にも関わっており、最近ではQuick Charge3を用いた30Wのワイヤレス充電器を(さらっと)発表している。また、ワイヤレス充電の国際標準規格Qiとも相互運用性を確保しているため、てっきりQiに対応させてくるものだと思っていたのだが…

EXP21は非金属ボディのため、材質的にはワイヤレス充電が可能なはずだが、ワイヤレス充電に対応するコイルやチップ、内部ケーブルを置く余裕がなかったのかもしれない。

まあ、ワイヤレス充電は発熱や遅さもあり、かつ位置合わせもけっこう面倒という問題もある。そして当たり前だが、ワイヤレス充電器そのものはワイヤレスではない。結局のところ充電器とスマホの間がワイヤレスかどうかという話なので、筆者としては魅力を感じていないし、搭載されいなくても問題はないと考えている。ただ、Qualcommの描くワイヤレス充電の世界を見たかったという気持ちはあるため△とした。

✕マニュアル撮影出来ないカメラ

「カメラについて1」のマニュアルカメラの項目で触れている通り、これは許しがたい。なまじ性能が良いだけに、自分の思う設定で撮れないのが歯痒く感じる。とても綺麗な絵が撮れるが、これでは筆者がシャッターを切っただけで、Snapdragonの作品となってしまう。もちろん、Snapdragonのサポートがあって始めてEXP21で写真が撮れるのだが、マニュアル撮影が出来ないとなると、筆者が介入する余地がないのだ。これでは写真は楽しめても撮影が楽しめない。

また、EXP21の癖として青白い色味になる点やISO感度を上げて明るく撮りたがる点、彩度やコントラストが強い写真になるという点がある。マニュアル撮影が出来れば、少なくとも色味やISO感度はこちらで抑えられるのだ。筆者の腕前がない分、普段はもちろんSnapdragonのサポートには頼りたいが、たまにはマニュアル撮影がしたい。

ASUSスマートフォンは古くからマニュアル撮影(Proモード)をサポートしてきた。そのため、技術的には今すぐにでも対応出来るはずだ。Qualcommの意向であれば仕方のないことだが、なんとしてもマニュアル撮影に対応して欲しいものだ。

✕指紋センサーの見つけにくさ

「指紋センサーについて」で触れている通り、指紋センサーが見つけにくい。背面にあるため手探りで指紋センサーを見つけることになるのだが、指紋センサーの周りは凹凸がなく、すぐにはそれと分からない。使い勝手に直結する問題なので、この点はなんとかして欲しかった。

まあ、指紋センサーは動いたりしないので、最終的には慣れの問題だとは思うが、指紋認証そのものは速く高精度なため惜しく感じる。

✕ゲームに便利なASUS独自機能「Game Genie」非対応

筆者は生粋のROG Phoneユーザーであり、ゲームをする上で「Game Genie」は必須と感じている。

「Game Genie」はROG Phone・Zenfoneシリーズに搭載されているゲームをサポートする機能(図 42)で、例えばゲーム中の着信・通知の拒否や、スクリーンレコーダー、バックグラウンドアプリ等をKILLする「最適化」、オート周回時に誤作動やスリープモードにならない「ロックタッチ」などが、スワイプ1つで呼び出せる便利さがある。

また、大っぴらには言えないが、マクロ機能(予め指定した通りに画面を自動でポチポチとタップしてくれる機能)もあるのだが(図 30)、EXP21にはそれらの機能を備えたGame Genieがない。

これではいくら性能が高くても…と言ったところだ。まあ、ゲームをしたいならROG Phoneシリーズを買うべきだろう。EXP21のマシンスペックはゲームに特化したものではないのだ。

✕rootを取らなきゃ電測には向かない

一般的なスマートフォンの使い方ではないが、EXP21の使い方としては一般的と言える電測だが、EXP21はrootを取らないとNRバンドやCAの組み合わせが分からない。

※何を言っているか分からないという方には不要の機能なので気にする必要はない。

せっかく対応bandが(ありえない程に)豊富なのに、これはあまりにも痛すぎる。Android12でNRやCAの組み合わせが見れるようになることを切に願う。

✕無意味に光るだけのSnapdragonロゴ

せめて通知があった時だけ光るとか、そういう利便性を付けてほしいものだ。色も白一色と味気ない。ROG Phoneシリーズは通知に合わせて、例えばTwitterからの通知なら水色に、Instagramからの通知なら紫色に、といった感じで通知+カラーで光らせ方を変えることが可能だ(図 31)。

EXP21の場合、白色LEDしか搭載していない(と思われる)ため、カラーの方は諦めるしかないが、せめて光らせ方をもっと増やして欲しいものだ。光らせ方のカスタマイズは、ROGの十八番だ。技術的には問題ないはずなので、これはQualcommの意向なのかもしれない。

「このQualcomm様のSnapdragonロゴを通知に合わせて光らせるなど許せん、Snapdragonはただ輝いていれば良い。そこにそれ以外の意味などない。」なんてことを考えるのは流石にQualcommに対する偏見が過ぎるだろうか。冗談はさておき、今の仕様だと本体にバッテリーの無駄遣いである。それでSnapdragon Insiders達が喜ぶなら、まあ良いが。

なお、ここからは各項目について詳細をチェックしていく。膨大な量となっているので、気になる項目だけを読んでいくことを推奨する。

10連続AnTuTuベンチマーク結果

バッテリー温度≒内部温度について

続いて筆者が着目したのはバッテリーの温度だ。バッテリー(スマートフォンに搭載されているリチウムイオン電池のことを指す)というのは熱に弱く、45℃以上になると劣化が始まると言われている(Anker 2022, FUJITSU 2014)。

両者ともに45℃のラインは下回っている(図 32, 図 35)。これは、放熱性能やサーマルスロットリングなどの結果、スマホ内部の温度を適切に保てていると言えよう。当然とは言え、サーマルスロットリングを行っているEXP21の方が統計学的に有意に温度が低い。

背面及びディスプレイの温度について:放熱システムを探る

高性能なスマートフォンにおいて、SoCの発熱は避けて通れない。そして安全のため、一定の温度を超えたら性能を制限する(サーマルスロットリングを行う)というのは先述の通りである。

もちろん、発熱を抑えるのも大事だが、その熱を冷ましてやるというのも大事なことである。ただ、熱を冷ますと言っても熱が勝手に消えてくれるわけではない。熱というのはどこかに移動させて外部に逃がしてやるものだ。そしてその外部と接触する場所というのが、スマートフォンの表面、つまりディスプレイや背面、フレームにあたる。

放熱をする上で表面が火傷をする程熱くなってしまう、言わば「ホッカイロ」では問題だが、全体がじんわり温かいというのは適切に熱を内部から逃せている証拠であり喜ぶべきことなのだ。(正確には、ディスプレイの場合はディスプレイ自体の発熱もあるため、ディスプレイが温かい=SoCの熱を逃がせているというわけではないが、ディスプレイもまた放熱面であることは事実である)

図 36, 図 37の通り、背面及びディスプレイの温度はEXP21とROG Phone5の間に有意な差があるとはいえない結果になった。

それよりも、注目したいのは熱の分布だ。

サーモグラフィー(図 38)を見ていただければわかるが、ROG Phone5もEXP21も中央部はまんべんなく熱くなっており、高負荷なゲーム等で横持ちした際に手に触れる部分は最大でも35.7℃と人肌以下に抑えられている。これはユーザーに不快感を与えず効率的に熱を逃がしているので100点満点だ。

というわけで前置きが長くなってしまったが、この項では、冷却(放熱)性能・冷却システムに焦点を当ててEXP21をレビューしたい。

とは言っても、貸出機であるしそもそも筆者にそんな技術はないので、分解して内部構造を探ることは出来ない。あくまでサーモグラフィーの結果と、明らかにされているROG Phone5の冷却システムをもとに推測をしていくこととなる。

まず、熱源となるSoCだが、これはROG Phone5もEXP21も同じものになる。注目したいのはその配置だ。ROG Phone5では、スマートフォンの中央にSoCを置くことで、均等に熱を分散すると共に、横持ちした際、手に熱を感じさせないような工夫をしていた図 39。

EXP21のSoCがどこに配置されているか言及された公式資料はなかったが、サーモグラフィーの結果図 38を見るに、ROG Phone5と同じく中央に配置されていると思われる。

EXP21の設計はASUSが行っていためROG Phone5と同じような設計であることになんらおかしさはない。0から新しく設計するよりか、同じ筐体サイズであるROG Phone5の設計を下地にしたと考える方が自然だ。(ちなみに、図 20で示した通り、ディスプレイパネルは完全にROG Phone5のパーツを流用しており、ディスプレイ下部には、EXP21には不要なスピーカーノッチが存在している)

余談となるが、本体中央にSoCを置くということは、マザーボードの配置もROG Phone5と同じような形となるはずだ。そうなると、4000mAhのバッテリーを単体で下部に配置することはスペースの制約上おそらく出来ない。ということは、EXP21はROG Phone5同様に2つのバッテリーの間にマザーボードが挟まている形となるのだろう。

EXP21の内部構造は不明ながら、製品紹介ビデオでは図 40のようななイメージになっている

最近はバッテリーを2つに分割し直列接続する(2Sバッテリーにする)ことで、高電圧での急速充電を行うのが流行りだ。

EXP21はSnapdragon Insidersなスマートフォンであり、Qualcommの技術を体現するスマートフォンだ。そんなQualcommのQuick Charge 5.0ではこの2Sバッテリーへの対応が売りの1つになっていること図 41や、逆にシングルバッテリーのZenfoneシリーズが65Wの急速充電に対応していないことから、この65W急速充電では2Sバッテリーの証左であり、ひいてはROG Phone5と同じように中央にSoCやマザーボードを、そしてその左右にバッテリーを備えるという形であると考えられよう。

話を戻そう。中央に熱源を持ってくることで、熱は均等に伝えられそうだ。

では、どうやって熱を伝えているのか。これもROG Phone5と同じであれば、3Dベイパーチャンバーとグラファイトシートだろう。

（これも余談だが、ROG Phoneシリーズでは従来これに加えてヒートシンクを採用していることを大々的に喧伝していたが、ROG Phone5ではそのような宣伝はなかった。）

おそらくベイパーチャンバーやグラファイトシートで運ばれた熱はディスプレイと背面、そしてサイドのメタルフレームを用いてスマートフォンの表面全体で放熱されるのだろう。内部に余裕がなくヒートシンクを置くスペースがなさそうなEXP21もこれと同様と思われる。

ということで、EXP21の冷却システムはベイパーチャンバーとグラファイトシートによる熱移動と本体表面での放熱(自然冷却)に支えられてそうだ。

スペースの都合上、ROG Phone5とベイパーチャンバーやグラファイトシートが同等のサイズであるとは限らない。むしろ小さくなっている可能性の方が高いだろう。また、放熱箇所の1つであるサイドフレームもROG Phoneと違って金属製ではない。熱伝導率は劣るだろう。まあ、おかげでフレーム部分を持ってもあまり熱くないというメリットもあったのだが。

さて、これで冷却システムの話は一通り出来たと思う。御託はいいから放熱性能はどうなんだよという話だが、実際、ROG Phone5に比べるとEXP21の放熱性能はやや弱いように思える。 実際、サーマルカメラで見た熱の分布(図 38)もROG Phone5に比べ高温（図中白色）の分布が少なく、かつ最高温度も高い。

たとえば、背面のサーモグラフィー(図 38 (a))を見ると、ROG Phone5に比べて高温部(白く塗られた箇所)が集中しており、最大温度はEXP21の方が高いか同等という結果だ。これはつまり、熱を上手く拡散出来ていないということだ。 背面側にあるのはROG Phone5と同じであればグラファイトシートである(図 39)。グラファイトシートの面積が足りてないのか、あるいは単純に背面ガラスパネルの中央にあるSnapdragonのロゴが熱伝導率の差を引き起こし足を引っ張っているのかもしれない。繰り返しになるが、筆者は熱力学や熱設計に詳しくない。この考察が誤りである可能性もある。ただ、まあ熱の分散がROG Phone5に比べて劣っているのと、そもそもサーマルスロットリングを行っているのでSoCの発熱自体は抑えられているはずなのに、ROG Phone5と同じかわずかに高い温度を出しているため放熱能力がやや劣るというのは言えそうだ。

一方のディスプレイサイド(図 38 (b))はROG Phone5の設計で同じであれば主力であるベイパーチャンバーがある方になる(図 39)。サーマルスロットリングを行っている関係上EXP21の方が温度が低いのは当然だ。そのため色の塗り分けで熱分散を見るのが難しいが、どちらもしっかりベイパーチャンバーが仕事をしているように思える。強いて言えば、ROG Phone5のほうが仕事をしてそうだ。

長くなってきたので、話をまとめよう。まあ、素人目線で見る限りはどちらもしっかりSoCの熱を外に逃せているように見える。しかも、手に触れる部分はきっちり避けているのが見事だ。

EXP21がサーマルスロットリングを行った背景、つまり、なぜサーマルスロットリングの閾値が厳しいのかその理由は定かではないが、筆者はこれこそゲーミングスマートフォンと一般的なスマートフォンの違いであると考える。

ASUSのゲーミングブランド、ROGから出ているROG Phone5は、まさしくゲーマーのためのゲーミングスマートフォンであるため、たとえその影響が僅かであってもサーマルスロットリングによる性能の制限はしたくないと考えるのに対し、一般向けの(EXP21が一般的かはさておき)スマートフォンであれば、最高性能に張り付く意味は薄く、むしろ、発熱というエネルギーロス・能率の低下はバッテリーの浪費に繋がるため避けたいと考えるはずだ。また、バッテリー容量もROG Phone5が6000mAhなのに対し、EXP21は4000mAhだ。なおさら、バッテリーの浪費は避けたいところだろう。サーマルカメラを通じた分析でもEXP21の放熱設計は(ROG Phone5に比べて僅かに劣るとはいえ)優秀のため、熱を扱いきれないからサーマルスロットリングをしているのではなく、バッテリーの節約のために行っていると考えるのが自然だ。

サーマルスロットリングを行っていながら、大幅な性能低下は見られず、昨年のフラグシップモデル以上のパフォーマンスは出せているので、結論としては両者とも優れた放熱性能を持っていると言えよう。ROG Phone5以上に色々と詰め込んでいて余裕がないはずなのに、発熱で大きく性能を落とすことがないのは流石だ。

目次に戻る

EXP21メインカメラ

筆者としてはとても綺麗に撮れているという印象だ。筆者のセンスがあればもっと素敵な写真が撮れていたことだろう。オートモードのため何も設定はしていないが、全体的に「バエる」仕上がりになっている点は好みが分かれるかもしれない。

EXP21 超広角カメラ

メインカメラももちろん美しく撮れるが、印象的だったのが超広角カメラの写りだ。具体的な比較は後に行うが、ROG Phoneシリーズでは積極的に使おうと思わなかった超広角カメラの写りが(キャプションではちょっと厳し目に評しているが)劇的に良い。超広角で撮ったと言われなければ気付けない程だ。

EXP21 望遠カメラ

望遠も必要十分といった写りだ。光学式なので電子ズームより画質は良いし、何より嬉しいのが光学式手ブレ補正である。望遠はブレやすいので光学式手ブレ補正はありがたい。

作例としてはまったくバエないが、基地局のシールを撮影するときなどは、光学式ズームと光学式手ブレ補正のWパンチが大いに役立った。

さて、ということで文句なしに綺麗な写真が撮れるメインカメラ、そのメインカメラと遜色ない質でワイドな写真が撮れる超広角カメラ、光学式手ブレ補正もついた便利な光学式3倍望遠カメラと文句なしなカメラ構成なEXP21だが、本当に文句はないのだろうか。実はある。

EXP21のカメラは「マニュアル撮影」が出来ない。

マニュアル撮影ができない、つまり自分でシャッタースピードやISO、フォーカスを調節出来ないというのは、人によっては「はい、解散。」となる致命的な欠点だ。というか筆者がそのたちである。

スマートフォンのカメラは、ソフトウェアの調整が強く、さらにはコンピュテーショナルフォトグラフィー（Computational photography）、つまりAIを用いてボケ感を強めたり画像合成を行うという要素が強い。レンズやセンサーはスマートフォン向けの小型サイズであり、得られる光学情報は限られているので、デジタル補正でバエる写真にしようという訳だ。

その流れはもちろん分かる。手軽にバエる写真が撮れるのは良いことだ。だが、EXP21は光学的にも優れている。だから、だからこそその強さを活かした「こだわった」写真が撮りたい。綺麗な写真が撮れれば撮れる程、筆者の歯がゆさは増していった。

特に流し撮りや光跡といった躍動感のある写真を撮るためには(Pixel6などを除き)マニュアル撮影が必要になる。また、写真好きにとってはスマホで手軽に撮れる良さを享受しつつも自分でも撮ってみたいという気持ちが湧くシーンもあることだろう。やっぱり撮ってて楽しいのはマニュアル撮影なのだ。

ということで、「綺麗な写真」は撮れるが「撮影体験は楽しめない」というのが、EXP21に抱いた感想である。マニュアル撮影など、ZenFoneは古くからサポートしてきたのに、EXP21ではそれが出来ないというのは不思議でならない。Qualcommの意向だとすれば、今後のアップデートで追加される望みも薄いだろう。「綺麗に撮れる」からこそ、筆者にはそれが残念でならない。

上手い作例が用意出来なかったが、これが一応その例だ。オートだとどれも明るい写りとなってしまい、静謐な兼六園の雰囲気とは合わない(図 48)。

しかし、マニュアル撮影であればこのように落ち着いた雰囲気を捉えることが出来る(図 49)。

どちらがよりSNS映えするかは分からないが、筆者が撮りたかったのは後者である。

余談:AIシーン認識による補正差について

2018年以降のASUSスマートフォンのカメラには「AIシーン認識」という機能がある。

これは、認識されたシーンに合わせて自動で写真の写り(おそらく色味など)を調節をしてくれる機能であり、EXP21もその例に漏れずAIシーン認識機能が搭載されている。

EXP21の写真が比較的「バエ」より、つまり彩度やコントラストが高めな仕上がりになるのは、もしかしたらこのAIシーン認識による補正によるものなのではという疑問が生じたため、軽くだが検証してみた。

結論から先に言えば、その差は僅かであり比較してみないと気づかない程自然な仕上がりだった。

「引き」で見たときに若干緑の彩度が高いと感じる程度なので、AIシーン認識による調節は誤差の範囲と言ってよく、「バエ」な写真に仕上げるのはEXP21のチューニングによるものだと言えそうだ。

目次に戻る

「飯テロ」性能

まずは、食事の比較だ。いずれも撮影はオートモードで行った。

海鮮丼で比較をしてみたところ、近距離だったこともありピントの合う範囲がシビアな印象で、iPadを除きどれもエビの頭や足などはボケている。（iPad Proに使われるイメージセンサの詳細は分からないものの、他機種と比べセンサーサイズが小さくボケにくい可能性がある）

EXP21は他の機種と違い、青白い写りとなっている。いわゆる飯テロ画像においては、暖色系が好まれる印象だが、これはこれで悪くない気がする。ホワイトバランス以外で言うと、特に青じその葉脈がはっきり見えるのは、何かシャープに見える補正をかけているからだろうか。

ROG Phone5とは手ブレ補正を除きハードウェアスペックは全く同じだが、ホワイトバランスという点で顕著な差が出た。また、ASUSスマートフォンはEXP21を含めすべて「食事モード」でAI認識されているのにも関わらず、ここまで差が出るとは思ってもいなかった。これがQualcommのチューニングなのだろう。

別日に自宅でも比較をしてみた。

被写体はそれぞれ寿司、野菜、デザートだ。特に設定していないがいずれも「食事モード」となった。

傾向として、EXP21はとにかく明るく撮りたがるようでISO感度が他機種よりも高めになっている。光学式手ブレ補正を搭載しているのだから、筆者ならISOを下げシャッタースピードを遅くするアプローチで明るくするのだが…。

また、寿司においてはEXP21の明るくコントラストの高い写真に仕上げるという癖が裏目に出ており、玉子ずしが完全に白飛びしてしまっている。

風景(メイン、超広角、3倍望遠or電子ズーム)

続いては青空と緑を含む風景画だ。これは橋の上から広角、超広角、3倍望遠でそれぞれ比較した。

薄暗い場所での癖を確認

次に薄暗い(雰囲気のある)喫茶店での比較だ。

筆者としては薄暗くコントラストに乏しい場所が一番スマホにとって難しく、そしてチューニング(戦略)の差が出るところだと思っている。というのも夜景となればコントラストがはっきりしているし、最近は「夜景モード」なんてものもあるくらい各社が力を入れているが、曖昧な薄暗い場所はそうではない。ワキの甘さが出かねず、気を抜くとノイジーな写りになり、ノイズを避けようとするならソフトウェア補正で潰すか、ISO感度を下げる代わりに(手ブレのリスクを負いながら)シャッタースピードを遅くするしかないからだ。

前置きが長くなった割にバエない写真で恐縮だが、これがその比較である。

EXP21は寒色寄りに写す癖があるというのが一番目立つが、面白いのがシャッタースピードだ。EXP21はメインカメラに光学式手ブレ補正を搭載しているので、シャッタースピードを遅くしてもブレには強いはずであり、そのメリットを活かしISOを下げてノイズを潰すものだと思っていたのだが、予想に反しシャッタースピードがROG Phone5と同じだっただけでなく、ISOを上げて、より明るい写りを求めていた。繰り返しになるが、手ブレ補正に強いのだから、シャッタースピードを遅くして明るくするのが筋であるのにも関わらず、だ。

穿った見方かもしれないが、光学的優位よりも、自身のISPとそのチューニングにQualcommは自信を持っているのかもしれない。光学式手ブレ補正を除けばROG Phone5と同じレンズとイメージセンサ、そしてISPを持っていながら、まさかこのような差が生じるとは思わなかった。

食事の写真を比較した際にも感じたことだが、EXP21は明るく撮りたがる傾向がありそうだ。

夜景その1(メイン、超広角)

続いて夜景の比較だ。iPad Proを交えた計5機種での比較はこれが最後となる(iPad ProはGoogleDriveでのみ公開)。

人目もあり、やや画角が異なるが概ね同じ場所から金沢駅を撮った。

流石のQualcommも夜景レベルまで暗くなると光学式手ブレ補正を活かしてくるようで、EXP21のシャッタースピードが1/15秒と一番遅かったが、貪欲なことにISOも最も高く明るさを求めてきた。ISOを高めてもノイズはしっかり処理出来ており、結果として最も綺麗な仕上がりになっている。

超広角も広角と同じ画角で撮ってみた。

不思議なことにEXP21はシャッタースピードを広角から変えることなくISOを下げた。スペック表にある通り、超広角には光学式手ブレ補正ではなく電子式手ブレ補正しかないのにも関わらずシャッタースピードを変えることがないのも、そのくせISOを上げるのではなくむしろ下げてきたことも意外だ。ただ、超広角側でISOを下げるという選択は他の機種でも同様だったため、画素ピッチなどを鑑みて、ノイズを避けるための挙動なのかもしれない。

なお、レンズのF値はEXP21とROG Phone5がF2.2と光学的に明るい作りとなっている。光学的優位と優秀なソフトウェア調整もあって、やはりEXP21が一番綺麗な写りになっている。

夜景その2(メイン、超広角、6倍ズーム)

夜景としては上記の作例はやや光源に欠けていたので、新宿でも夜景の比較を行った。

なお、この場所は筆者がいつも夜景比較を行っている場所であるため日付を跨いでの比較も可能ではあるものの、今回はそれを行わず、出来うる限り同じ条件で比較を行う。要するにiPad Proを使って撮り忘れたので、iPadとの比較は行わないということである。

新宿での夜景撮影は、広角、超広角、望遠6倍で行った。

接写(マクロ)性能比較

最後に接写の比較を行う。

EXP21はマクロレンズを持たないものの、超広角レンズを用いての接写が可能である。ROG Phone5及びROG Phone3は専用のマクロレンズを持っているので、そちらで撮影した。ZenFone6はそもそもマクロ撮影に対応していないため、今回の比較からは外した。

結論から言えば、専用のマクロレンズよりもEXP21の超広角レンズでマクロ撮影を行った方がはるかに綺麗な写真となった。比較にもならない。

「トリプルカメラ搭載」を謳いたいがために数合わせで用意したマクロカメラより、IMX363というちゃんとしたイメージセンサとレンズで撮った方がはるかに綺麗なのだ。ゲーミングスマホにマクロ撮影など求めてない。ROG Phone6(仮)では、いい加減マクロカメラなどやめて少しでも価格を下げて欲しいものだ。

EXP21のカメラ性能比較を総評

EXP21のカメラは全体的に「バエる」写りを意識しており、明るめかつ彩度とコントラストが高い写真に仕上げる。また、寒色寄りの青白い写真になる傾向がある。

メインカメラにおいて、ISOを上げて明るく撮りたがる傾向がある。光学式手ブレ補正を備えているのにも関わらず、シャッタースピードを遅くするよりISOで明るくするきらいがあるのは、とりあえず明るい写真にしノイズはソフトウェア補正で消せるという自信だろうか。

超広角に関しては他機種と比較した際に気になる癖は(ホワイトバランス以外)見られない。写りとしては前述の通りバエを意識した仕上がりになる。

望遠における癖は、そもそも比較に用いた機種に望遠レンズを搭載しているものがなかったため何とも言えない。他機種と違い電子ズームではなく光学3倍という優位と光学式手ブレ補正という強みから、他機種と比較し綺麗に写るがこれはある意味当たり前だろう。

最後になるが、ここで掲載した写真はすべてGoogle Driveにオリジナル(ものによっては位置情報のみ削除している）をアップロードしてある。また、ブログには掲載しきれなかった写真もあるので、興味があればそちらをご覧いただきたい。

目次に戻る

光学式手ブレ補正の実力を確認

とりあえず、EXP21の光学式手ブレ補正が動画撮影時にどう頑張っているのかをROG Phone5と比較してみた。すでに何度も触れている通り、メインカメラのハードウェア的には光学式手ブレ補正を除きEXP21とROG Phone5で共通である。そのため、この動画は純粋に「光学式手ブレ補正＆電子手ブレ補正」vs「電子手ブレ補正のみ」 という比較になるはずだ。

ROG Phone5 UltimateとEXP21の4K60fps動画撮影比較です。
EXP21は光学式手ぶれ補正機構を搭載しています。
トリミングして比較しやすくしたのが後半にあります。 pic.twitter.com/5wSuheQNHu

— ポッタル ((Pottal_MDS?)) November 3, 2021

ROG Phone5 UltimateとEXP21の4K60fps動画撮影比較です。
EXP21は光学式手ぶれ補正機構を搭載しています。
トリミングして比較しやすくしたのが後半にあります。 pic.twitter.com/5wSuheQNHu

— ポッタル ((Pottal_MDS?)) November 3, 2021

Twitterでの動画再生がうまくいかない場合や画質が悪い場合は、例のごとくGoogle Driveにあるデータを参照してもらえれば幸いだ。なお今回は容量の都合上生データではなく「比較動画」のみのアップロードとなる。

動画の通り、確かに光学式手ブレ補正は仕事をしており、電子手ブレ補正のみのROG Phone5よりもブレのない映像がとれている。

8K動画は室温(20℃)で30分以上撮影可能

EXP21は8K@30FPS動画も撮影可能なため、どの程度の時間撮影出来るのか≒どの程度発熱に耐えられるのかを検証してみた。

検証は室温（20℃）環境下にて、スマホホルダーを使って三脚に取り付けた状態で行った。

結論から言うと30分を過ぎたあたりで、発熱警告が出たものの撮影そのものは続行可能で、50分ほどで強制停止された。

8Kチャレンジ、室温20℃で50分間撮影可能だった。本体（バッテリー）温度50℃で制限かけてるのかな。 pic.twitter.com/nU05W7n11c

— ポッタル ((Pottal_MDS?)) December 22, 2021

具体的にどこの温度を参照しカメラを矯正停止したのかは分からないものの、強制停止された時のバッテリー温度は48.1℃と記録されており、これが最大値である。

とりあえず、8K@30FPSで50分間撮影した結果、動画のファイルサイズは49.8GBであった。また、バッテリーは80％から25％まで減った。

また、サーマルカメラで本体の温度を測定したところ、このような結果となった。

熱くて持てないということはなさそうだが、低温火傷の可能性や本体の放熱を考えるとスマホホルダーを使って挟みこみミニ一脚や三脚を使うのが良さそうである。

本体温度は手に触れないであろうディスプレイ部分で42℃、手に触れるであろうフレーム部分で38℃ほどであった。

1時間を超える撮影となると、おそらく熱云々よりバッテリーが尽きるため、充電しながら撮影することになるが、充電の際に発熱するため今度はバッテリーは問題なくとも熱で長時間の撮影が行えないことになる。

ちなみに、発熱対策としてペルチェ素子クーラーで冷却をしながら撮影したところ1時間を超えて撮影出来たが、バッテリーが先に尽きてしまった。

つまり、長時間撮影するためには、ペルチェ素子クーラーの電源とEXP21本体の充電と2つ給電ポートを用意する必要があるが、そもそもペルチェ素子クーラーの音がノイズとなるので実用的ではない…

実用の範囲内で撮影するとなると8K@30FPSの場合は30分程度と考えておくべきだろう。

144Hz表示について

EXP21のディスプレイは144Hz/120Hz/60Hz/そしてコンテンツに応じてリフレッシュレートを選択するAutoモードの計4種類の表示モードがある。

なお、Autoモードでのリフレッシュレートがどのように選択されるのか、正確に言えば「60Hz」「120Hz」「144Hz」という3つの選択肢から選んでいるのか、それとも可変リフレッシュレート(もっと柔軟にリフレッシュレートを選べるもの)なのかは検証はしていない。

筆者は144Hzしか使わないものの、人によっては「90Hzで十分！それよりバッテリー持ちを重視したい」ということもあるので90Hzという選択肢があれば、なお良かったと思う。

また、前述の通り144Hz表示をしてもROG Phone3のように画質が悪くなることもない。

明るさについて

季節がもう秋だったこともあり、少なくとも野外で問題なく使えるディスプレイ輝度であった。

カタログスペック上は800nit、ピーク輝度は1200nitとなっている。ピーク輝度はHDR表示などで使われるものなので、参考にすべきはこの800nitというところだろう。繰り返しになるが、秋空の下で使う分には問題ない明るさであった。

目次に戻る

付属の完全ワイヤレスイヤフォン「MW08S」について

EXP21にはSnapdragon Sound technologyだけでなく、Snapdragon Sound Optimizationと呼ばれるオーディオイコライザーのような機能も備えている。

デフォルト（Snapdragon Sound Optimizationオンかつのオート状態）ではベースがやけにくっきり聴こえる。無理して1音1音をはっきり聴かせようとしてるからか、聴き疲れする。

Snapdragon Sound Optimizationは切った方が良い。

オフにした状態でも、ちゃんと1音1音が聴こえるため基本的にはオフにした方が良い…と言いたいのだが、人間とは本当に勝手なもので、オフにしたらしたで、段々と濃い味付けが恋しくなるものだ。先程は香水を過剰に振りまいた時のように感じたチューニングが、打って変わって、香りが花開いたと感じるのだから、我ながら呆れてしまう。ただ、香りと違って嗅覚疲労（段々と強い匂いに慣れてしまう）ならぬ「聴覚疲労」は起こらず、文字通り聴いていて「疲れて」しまうので、長時間聴く場合はオフにしたい。ノイズキャンセリングと併せて、通勤電車や人混みなどノイジーなところで濃いめに味付けたいときに使うのが良いだろう。

ちなみに、このSnapdragon Sound Optimizationは他のBluetoothオーディオでも使用が可能だ。傾向は概ね同じで、オンにすると音圧強めで聴き疲れする。

音ゲーもできる遅延のなさについて

イヤフォンの評価なのか本体の評価なのか堺が怪しいが、EXP21と付属のイヤフォンの組み合わせで実現されたSnapdragon Sound technologyは、遅延にシビアなリズムゲーム(音ゲー)を難なくこなせる程に低遅延だった。

これは、高音質なモードと低遅延なモードを上手く切り替えられているからである。

具体的には音ゲーをプレイするときはQualcomm aptX Adaptiveのプロファイルが自動的(というか強制的に)Low Latencyモードに切り替わる。

なお、この挙動はMW08SとEXP21の組み合わせでのみ見られ、ROG Phone5やROG Phone3とMW08Sを接続した際は、aptX Adaptiveこそ有効になるものの、aptX Adaptiveの設定画面を呼び出すことは出来なかった。

ちなみに、プロファイルの切替えは手動で行えない。 そのため、aptX Adaptiveの挙動なのかSnapdragon Sound technology対応機であるEXP21だからなせる技なのかは分からなかった。特にROG Phone5では相性が悪く高音質モードのまま切り替わらないような挙動で遅延が酷かった（実際にはプロファイルが見れないため不明)。

今回の遅延評価に用いたのは「アイドルマスター シンデレラガールズ スターライトステージ（デレステ）」である。なお、筆者の腕前のせいで難易度「MASTER」(大きく分けて5段階ある難易度のうち上から2番目)の「お願いシンデレラ」すらフルコンボ(ミスなしでクリア)出来ていないが、これは遅延のせいではなくあくまで筆者の腕前のせいだ。

Qualcomm aptX AdaptiveのLow Latencyは本当に低遅延であり、デレステでのタイミング調整値の差(本体スピーカーの調整値と付属の完全ワイヤレスイヤフォンMW08SをQualcomm aptX Adaptive Low Latencyで接続した際の調整値)は僅か2.6であった。筆者の体感としては「±8」程度の差であれば問題なくプレイ出来るという認識であるから、これは恐るべき数値だ。

なお、結果はGoogle Driveでも公開している。

目次に戻る

EXP21の本体スピーカーについて:音量も音質も十分

EXP21は画面上部と本体側面(底部)にスピーカーを備える。ROG Phoneシリーズとは違い、デュアルフロントスピーカーではないものの、大きな違和感(左右差をおぼえること)なくステレオを楽しむ事ができる。

EXP21 Smartphone vs ROG Phone5 Ultimate
スピーカー比較テスト pic.twitter.com/9XdvIeIJR0

— ポッタル ((Pottal_MDS?)) January 14, 2022

EXP21 Smartphone vs ROG Phone5 Ultimate
スピーカー比較テスト pic.twitter.com/9XdvIeIJR0

— ポッタル ((Pottal_MDS?)) January 14, 2022

（Twitterでの動画再生がうまくいかない場合や画質が悪い場合は、例のごとくGoogle Driveにあるデータを参照してもらえれば幸いだ。）

最大音量がけっこう大きくなおかつ目立った音割れはしなかったため、スマートフォンのスピーカーとしてはかなり上位のものとなるのではないだろうか。

ちなみに、ROG Phone5と比べるとやや見劣りする他、高音域の音質に顕著な差がある。とはいえ、最高峰のROG Phone5と比べてしまうのは酷であろう。

EXP21そのもののBluetooth性能について

繰り返しになるが、EXP21はSnapdragon Sound technology（Qualcomm aptX Adaptive）に対応している他、LDAC、SBC、AACといったBluetoothオーディオコーデックに対応していることを確認した。BluetoothのバージョンはBluetooth5.2とある。

アンテナ感度は(定量的測定ではなく、あくまで主観によるものだが)これまでで抜群に良く、LDACでもほとんど音飛びしなかった。（Snapdragon Sound technologyとは違い全く音飛びしないというわけではない。）

EXP21の5G安定性について:

この記事の冒頭で書いた通り、今回お貸りしたEXP21はVoLTEが有効にならないという挙動を見せたが、これは試供用モデルの日本向けOS書き換え不良によるものとのことで、正常な日本版OSのものをレンタルさせていただくこととなった。

その後の、貸出機では問題なく使用できたが、詳細な検証は時間の都合上行っていない。

EXP21の5G速度について

前述の通り、安定して5Gが受信出来ず、かつNRが見れないためSub6なのかミリ波なのか分からないが、ミリ波が吹いているであろうdocomoの基地局前で測定を行った。

その最高速度がこちらである。

とりあえず、実測で最大1.5Gbpsのダウンロード速度が出ている。アップロード速度は最大30Mbps程である。

docomoだけでなく、KDDI、Rakuten、ローカル5Gを使った5G通信を確認している

目次に戻る

EXP21のWi-Fi性能について

EXP21は6GHz帯を用いたWi-Fi 6Eに対応しているものの、日本ではまだWi-Fi6Eを使うことが出来ない。そのため、日本においてはWi-Fi6 (802.11a/b/g/n/ac/ax)まで利用可能だ。2x2 MIMOにも対応している。

5GHz帯において、80MHzまでのサポートか160MHzの帯域幅をサポートしているのか明らかにされていないが、実測の結果160MHzに対応している可能性が高いと言えた。

EXP21のWi-Fi感度について:ゲーミングスマホより優秀！

EXP21のWi-Fi感度を測定した。

筆者は普段、ASUSルーターを4台使ってメッシュWi-Fiにして家全体を1つのWi-Fi APでカバーしているが、それでは測定にならないため今回は親機である「RT-AX89X」のみを用いて測定を行った。

なお、5GHz帯を用いたWi-Fi6しか取り扱っていない。2.4GHz帯であればもっと感度は良いはずである。

測定エリアはそれぞれ、基準となる

1. リビング(Wi-Fiのすぐ近く)、
2. 階段踊り場
3. 1階「客間」
4. 1階「風呂」（脱衣場）
5. 1階「部屋」

である。

測定はAndroid11の開発者オプションで「Wi-Fi詳細ログの有効化」をし、RSSI、Scoreを取得した。また、Wi-Fiの設定画面から送信リンク速度と受信リンク速度を取得した。

テストの様子は以下のTweetの他、Google Driveでも公開している

EXP21とROG Phone5で同時に測定。

— ポッタル ((Pottal_MDS?)) November 14, 2021

RSSIやリンク速度などの結果(図 85)を総合して見るに、EXP21の方がWi-Fiの感度が良かったと言えそうだ。

今回は都合上ROG Phone5としか比較していないが、ROG Phone5はゲーミングスマホのため、Wi-Fi性能に力を入れている。それに勝るのだから、EXP21のWi-Fi性能(感度)はピカイチと言っていいだろう。

ちなみに(公開はしていないものの)測定地点は写真でも控えている。そのためいつでも同所での測定可能なので、今後はこの地点をWi-Fi測定の基準にするつもりだ。

目次に戻る

充電速度について: 付属品での場合（HyperCharge 65）

まず、付属品である65Wの充電器及び3Aケーブルを使用したところ、EXP21に「Hyper Charge65」という表示と「⚡⚡」という充電アイコンが表示された。（ちなみに後述するが、HyperCharge 65はASUSの独自充電規格でありQualcommのQuick Charge5.0とは異なる）

なお、付属品である65W充電器の詳細は下記の通りである。

• Model:A320Q-200325C-US
• Input:100-240V~50/60Hz,1.5A
• Output:5V⎓3A/9V⎓3A/12V⎓3A/15V⎓3A/20V⎓3.25A
• PPS:3.3-11V⎓5A/3.3-21V⎓3.25A 65W MAX
• その他:ひし形PSEマーク ASUS JAPAN株式会社

余談であるが、付属充電器A320Q-200325C-USの性能はROG Phone5の付属品と全く同じである(図 10)

AVHzY CT-3を用いてPDOをキャプチャしたところ、充電器が通知した7つのPDOのうち、7つ目のPDOである3.3-21V⎓3Aを選択し最大2.35A⎓19.22Vのリクエストが行われた。

実際の電流及び電圧の変動はグラフの通りである。

図 91を見ても、やはり45Wが最大である。なお、上記の結果は20％から100％充電するまでのものであるため、0％→20％の充電速度に関しては分からない。この区間で65Wの充電が行われている可能性は十分にある。とりあえず、20％から100％まで充電するのに50分ほどかかることがわかった。

※なお、充電速度は満充電（100％）に近づく程遅くなっている。実用に際して「絶対に100％まで充電したい！」ということは少なく、95％程度で良しとするならもっと早く済む。

サードパーティ製の充電器・モバイルバッテリーを使った場合（USB PD PPS）

次にPPS対応のモバイルバッテリーを用いた際の結果を示す。

使用したモバイルバッテリーは良くも悪くも話題のCIO製のSMARTCOBY 20000mAh 60Wである。

PDOをキャプチャしたところ、3Aまでのケーブルに対してモバイルバッテリーが3.3-11V⎓5AのPDOを通知し、最大9.08V⎓2.5AをEXP21がリクエストしたのだが、モバイルバッテリー側は8.74V⎓3.8Aで出力した(図 93)。

電流及び電圧変動のグラフ(図 94)を見ると最大35W、電流は最大3.9Aで充電されていることがわかった。また、上記の結果は同様に20％から100％充電するまでのものであるため、0％→20％の充電速度に関しては分からない。純正のACアダプタを使って充電するのに約50分かかったのに対しモバイルバッテリーでも約60分と大差なく、モバイルバッテリーを使っても十分な速度で充電できるのは嬉しい。

※なお、充電速度は満充電（100％）に近づく程遅くなっている。実用に際して「絶対に100％まで充電したい！」ということは少なく、95％程度で良しとするならもっと早く済む。

モバイルバッテリーが3Aのケーブルに対して5Aの出力を通知し実際3.9A流すのは正直いい気持ちがしないが、これはCIOが悪いのでここでは追求しない。

ちなみに、「急速充電」という表示と⚡の充電アイコンが表示された。

HyperCharge65の場合は「HyperCharge65」「⚡⚡」という表示であった(図 88)ため区別されていることがわかる。

サードパーティ製の充電器・モバイルバッテリーを使った場合(Quick Charge5.0)

筆者がずっと気になっていたのが、HyperCharge65という表示だ。これは果たして何なのか。QualcommのQuick Charge5.0とは異なるのか。異なるのであれば、なぜ付属品にはデカデカとQuick Charge5.0とあるのか。

結論から言うと、Quick Change5.0とHyperCharge65は別物であった。

その証左に、Quick Charge5.0対応の充電器を使って充電しても「HyperCharge65」とは表示されず、「急速充電中」「⚡⚡」という表示であった。

ということで、Quick Charge5.0で充電した際の結果を記す。

今回の検証に使用したのは、Baseus 100W PD 充電器 CCGAN100CSだ。

使用したケーブルはEXP21の付属品（3A）のものだ。

3Aまでのケーブルに対してQC5.0の充電器側が3.33-20.00V⎓3AのPDOを通知し、最大9V⎓2.5AをEXP21がリクエストし、充電器側は9V⎓2.7A程で出力した。

電流及び電圧変動のグラフ(図 99)を見ると最大24W、電流は最大2.7Aで充電されていることがわかった。また、上記の結果は同様に20％から100％充電するまでのものであるため、0％→20％の充電速度に関しては分からない。

純正のACアダプタを使って20％から100％まで充電するのに52分かかったのに対しQC5.0でも52分と変わらない結果となった。

純正のACアダプタが実測で最大45Wを出しているのに対し、QC5.0では最大でも25W程であるにも関わらず、同じ時間で20％から100％まで充電が行えているのは驚きだ。充電速度は最大W数ではないということを実感した。

※なお、充電速度は満充電（100％）に近づく程遅くなっている。実用に際して「絶対に100％まで充電したい！」ということは少なく、95％程度で良しとするならもっと早く済む。

サードパーティ製の充電器・モバイルバッテリーを使った場合(普通のUSB PD)

USB PD PPSならともかく普通のUSB PDは最も広く普及している急速充電規格と考えられるため、普通のUSB PDで充電した場合の充電速度も調べてみた。

出先での充電速度を調べるなら、PD対応のモバイルバッテリーを用いて検証を行い検証を行うべきだったのだが、「90WのPD充電ではどうなるのだろう」という好奇心にとらわれてしまい、うっかり(持ち歩きには不向きな)大きいAC充電器でしか測定を行っていなかった。

まあ、測定結果を見るに90WのUSB PDだろうと30WのUSB PDだろうと変わらないことが予想出来るのだが…

ということで、言い訳が長くなったがUSB PD PPSではなく普通のUSB PDで充電した結果を記す。

今回使用したのは、(ステマによってAmazonからBANされたことで有名な)RAVPowerの90W充電器 RP-PC128だ。この製品はTypeCポートが2つあり、片方のみで使用した際は20V⎓4.5Aで充電できるらしい。

使用したケーブルは最大スペックを引き出すために3Aではなく5Aのものを使用している。

5A対応のケーブルに対して充電器側は20.00V⎓4.50AのPDOを通知し、それに対し最大9V⎓2AをEXP21がリクエストした。

電流及び電圧変動のグラフ(図 101)を見ると最大16W、電流は最大1.9Aで充電されていることがわかった。また、上記の結果は同様に20％から100％充電するまでのものであるため、0％→20％の充電速度に関しては分からない。

純正のACアダプタを使って20％から100％まで充電するのに約50分かかったのに対しUSB PDでも約60分と変わらない結果となった。

※なお、充電速度は満充電（100％）に近づく程遅くなっている。実用に際して「絶対に100％まで充電したい！」ということは少なく、95％程度で良しとするならもっと早く済む。

実測の結果、90W対応のUSB PD充電器でもEXP21側が9V⎓2Aで18W程度しかリクエストしていないことから、30WのUSB PDモバイルバッテリーでも充電速度は変わらないと予想できる。(とは言え、モバイルバッテリーは自身のバッテリー残量が低下すると出力も低下するものが多いため、きっちり同じではないかもしれないが…)

サードパーティ製の充電器・モバイルバッテリーを使った場合(Quick Charge3.0)

USB PD以外で最も普及している急速充電規格は、おそらくQualcommのQuick Charge3.0だろう。(と筆者は勝手に考えている)

そのため、Quick Charge3.0を使っての充電速度も調べてみた。

検証に使用したのはSatechi Type-C 75W トラベルチャージャー ST-MCTCAMである。

www.amazon.co.jp

ケーブルはEXP21の付属品(3A)を用いた。

出来るなら、外出先を想定しモバイルバッテリーないしコンパクトなAC充電器を用いたかったのだが、あいにく手元にあるモバイルバッテリーで純粋なQuick Charge3.0対応のものが、これくらいしかなかったのだ。(AnkerのPowerIQやRAVPowerのよく分からない急速充電規格のものはゴロゴロ転がっているが…)

電流及び電圧変動のグラフ(図 102)を見ると最大約17W、電流は最大1.9Aで充電されていることがわかった。また、上記の結果は同様に20％から100％充電するまでのものであるため、0％→20％の充電速度に関しては分からない。

USB PDではないので、PDOのパケット等は取得出来なかった。

純正のACアダプタを使って充電するのに約50分かかったのに対し、Quick Charge3.0でも約55分と大差なく、一般的なモバイルバッテリーを使っても十分な速度で充電できそうなのは嬉しい。

※なお、充電速度は満充電（100％）に近づく程遅くなっている。実用に際して「絶対に100％まで充電したい！」ということは少なく、95％程度で良しとするならもっと早く済む。

充電まとめ: EXP21の充電速度は20％→100％の範囲なら、どの充電規格でも大差ない

ASUS独自のHyperCharge65やQualcomm Quick Charge5.0でも20％から100％まで充電するのに約50分、一般的な急速充電規格USB PD(PPS)やQuick Charge3.0だと約60分かかった。※なお、充電速度は満充電（100％）に近づく程遅くなっている。実用に際して「絶対に100％まで充電したい！」ということは少なく、95％程度で良しとするならもっと早く済む。

最大W数はまちまちだが、充電速度だけを見れば(少なくとも20%から100％まで充電するのには)大差ない。今回は測定・検証していないが、発熱という観点や0％からの充電速度、あるいは90％を超えたあたりの充電速度では、また違った結果になるかもしれない。

余談だが、ASUSの独自充電規格HyperChargeにはHyperCharge65とROG Phone3で用いられているHyperCharge30がある。

HyperCharge30というドマイナーな規格で充電した結果は「蛇足その2:EXP21の充電規格詳細」をご覧いただきたい。結論から言うとやっぱり大差なく最大23Wで20％から100％まで55分程だった。

目次に戻る

指紋認証について

指紋認証の精度自体はすこぶる良い。0.1秒、人差し指で弾くだけで認識されるし、濡れた指でも問題はなかった。

(同じく背面に指紋センサーを搭載しているZenFone6と速度を比較した動画をGoogle Driveにアップロードしているため、気になる方はそちらをご覧いただきたい。)

動画の通り、速度は問題ないのだ。速度は。

しかし、EXP21の指紋認証には致命的な欠点がある。それが、背面指紋センサーなのに、指紋センサーの位置の目印となる凹凸がないことだ。普通いちいち背面を見ながらロックを解除するなんて煩わしいことはしないので、人差し指は当てずっぽうで指紋センサーと思わしき場所をタッチすることとなる。当てずっぽうなので、指がクリーンヒットすることは少なく、結果として指のごく一部のみが指紋センサーに触れ、読み取り不良でロックが解除出来ないという悲劇が起こる。

どうして指紋センサー部を凹凸にしなかったのか。フラットな形状にしたかったのであれば、せめてSnapdragonのロゴと同じ大きさにして指の当たる確率を上げてくれなかったのか。

これは筆者の勝手な推測だが、指紋センサー部を凹ますことは、内部設計上余裕がなく実現が出来ず、指紋センサーの面積を大きくすることはQualcommが許さなかったのだろう。Qualcommはこの指紋センサーに自信をもっておりこの大きさで十分と考えているはずだ。指紋センサーが見えない画面内指紋認証なら兎も角、Snapdragonのロゴが霞むようなデカデカとした指紋センサーなど、付けたくなかったに違いない。まあ、確かに鳴り物入りのQualcomm3DSonicSensor Gen 2で、でっかい指紋センサーなどつけられたら、自信がないように見えてしまう。

これは筆者の勝手な妄想だが、なんとなくそんな理由なのではないかと思えないだろうか。

いや、何故画面内指紋認証センサーにしなかったのか…。 画面内指紋認証センサーにすれば、全てが丸く収まったのではないだろうか。センサーが内部設計上収まらなかったのだろうか…

顔認証について

スマホを持ち上げて、ちらっと見ればOKなので非常に快適だ。比較動画はGoogle Driveにアップロードしているが、なんとROG Phone5よりも認証が速い。

また、マスクを着用していない状態で登録しても、顔認証を行う際にはマスクを着けたままでも認識される。

（マスクを着けた状態だと）じっとカメラを見つめるという間があるが、ワンテンポ遅れるだけなのでストレスにはならない。

目次に戻る

ASUSスマホにはあってEXP21にはない機能

• 純正カメラアプリにおける「Proモード(マニュアル撮影機能)」
• Twinアプリ(同じアプリを複数インストール出来る機能)
• Game Genie(マクロ機能やゲーム中の通知・着信をブロックする機能)

筆者が特に痛いと感じたのはこの3つだ。

特に、マニュアル撮影機能はQualcommの意向、つまりオート撮影で誰でも簡単に綺麗な写真をスマホが撮ってくれるというビジョンに反するだろう。少なくとも製品ページではIntelligent Photographyが謳われている。（また、Snapdragon888の紹介ビデオで真っ先に触れられるのがカメラ(ISP)であり、AIの紹介ビデオでもやはり画像処理を最初にしている。）

Game GenieやTwinアプリもちょっとQualcommの意向には反するかもしれない。マクロ機能(つまり、自動で操作を入力してくれる機能)はゲームによってはチート、つまり規約違反として扱われる。

複数アカウントでの操作を容易にするTwinアプリ機能もゲームによってはよろしくない。例えば、Pokemon Goなどは複数アカウントを禁止していることで有名だ。通常、複数アカウントでプレイするには複数台のスマホが必要なところを、この機能は1台で済ませてしまうのだ。(尤も、Twinとついているように2アカウントまでのサポートとなる)

Androidの画面分割機能を使えば、画面上側でPokemon Goをしながら画面下側でも別のアカウントでPokemon Goなんてことも可能だ。

Game Genieのマクロ機能やツインアプリでの複数アカウント所持は、ユーザーに判断が委ねられるものであるものの、やはりQualcommとしてはよろしくないのだろう。

その他、取り除かれた機能は以下の通りだ。

• 背面指紋センサをスワイプして通知バーを呼び出す機能

もちろん、上記以外にも取り除かれた機能はあるだろうが、筆者が確認出来たのは以上である。

EXP21の独自機能について

EXP21はASUSスマートフォンに搭載された便利機能のいくつかが取り除かれてしまったが、逆にEXP21だけに搭載された特別な機能もある。

「アドバンスドモード」での詳細設定

EXP21は動作モードを選ぶことが出来る。ここまではあまり珍しいない機能だ。動作モードは「高性能」「ダイナミック(バランスをとる推奨設定)」「省電力」「超省電力」「アドバンスド」から選べる。

そのうち動作モードを「アドバンスド」に設定した際には、パフォーマンス調整機能でCPU,GPU,RAMパフォーマンスを「低」「中」「高」の3段階、同じく温度上限(つまりサーマルスロットリングの基準)も「低」「中」「高」の3段階から設定することが可能だ。

なお、動作モードを「高性能」に設定した際は(おそらく全ての設定がハイパフォーマンスになっているため)設定を変えることが出来ない。

動作モード自体はZenfoneシリーズやROG Phoneシリーズでも選択が可能だったが、動作モードでここまで詳細に本体のパフォーマンス設定を変えられるのはEXP21だけだ。なお、ROG PhoneシリーズであればArmoury Crateという専用アプリで、各アプリ(ゲーム)ごとにこのCPUや温度上限のパフォーマンスを変えることが出来る。

ROG PhoneシリーズとEXP21の設定の違いは、アプリごとなのか一括して本体のパフォーマンスをチューニングするか、ということになる。

背面ロゴの「照明エフェクト」

背面のロゴのオン・オフ、そしてオンにしたときの光らせ方を「固定」か、緩やかに点いたり消えたりする「呼吸」から選べる。

通知が来たら光るといった便利な機能はなく、ただただバッテリーを浪費するだけである。ROG Phoneシリーズのようにカラフルに光ってなおかつ通知に合わせて色を変えるなんてことが出来たら良いのだが、色も白一色である。

よほどのSnapdragon信者でなければ無駄に思うだけだろう。まあ、筆者はSnapdragonの「呼吸」を感じたかったのでオンにしたのだが。

 

目次に戻る

▷蛇足を飛ばして結論を読む

EXP21の映像出力について

映像出力の観点からUSB規格を推測した際にはUSB3.1 Gen2であると考えた。 これは外部ディスプレイに出力した際に「リフレッシュレートは120Hzに設定されています」との表示が出たからである。これは、同社のROG Phone5 Ultimateと同じ挙動であり、EXP21が120Hzの映像出力に対応していることを伺わせるものだ。ちなみに、ROG Phoneシリーズを外部ディスプレイに接続した際には出力可能なFPSとスマートフォン側のリフレッシュレートをなるべく一致させようという挙動が見られることから、EXP21でも同様の挙動であると推測した。なお、接続したディスプレイは75Hzまでにしか対応していなかったため実際のところ何Hzで出力可能なのかは分からない。仮に2,448×1,080ドットを(8bitで)120Hzで出力できるとすれば9.6Gbpsの転送速度に対応していることになるため、USB 3.1 Gen2(10Gbps)だと断定できるのだが…

(ちなみに、144Hzで出力するには11Gbpsの転送速度が必要になるため、USB3.1Gen2ではまかない切れない。そのため、144Hzの映像出力が可能なROG Phone3シリーズとTwinView Dock 3の組み合わせでは、USB3.1 Gen1ポートと独自のポートを用いてTwinView Dock 3に映像を出力しているものと見られる。ROG Phone3単体で映像出力する際は90Hzに制限されるのも、ひとえにUSB3.1 Gen1では追いつかないからだろう。なお、ROG Phone3の解像度で90Hzを出力した際には6.82Gbps必要になるのでその差分はどこから来るのだろうかという話になってしまうのだが…)

※映像出力の帯域幅はこちらの計算ツールを用いた。

EXP21のファイル転送速度について

次にファイルの転送速度でUSB規格を考えてみる。前提条件として、EXP21のストレージ速度はRead(Input)が1985MB/s, Write(Output)が785MB/sである。つまり、ストレージ速度的にはUSB 3.1 Gen2(10Gbps)に対応していておかしくないスペックである。

続いて接続したパソコンだが、Read・Write共に3000MB/s超え≒24Gbps、PC側のTypeCポート及び接続したケーブルはUSB 3.2 Gen2（10Gbps）となっているため、10Gbps内であればボトルネックは発生しない。※USB 3.2 Gen2はUSB3.1 Gen2と同じ10Gbpsの転送速度である

それにも関わらず、EXP21のTypeCポートはUSB2.0並の速度であった。

結果はGoogle Driveにもアップロードしている。

EXP21のTypeCポートがUSB3.1 Gen1(5Gbps)なのかUSB3.1 Gen2(10Gbps)なのか検証しようと思ったら、USB2.0並の速度しか出なかったのは驚きだ。

ちなみに、今回比較に挙げたROG Phone5はサイドのUSB 3.1ポート(こちらも詳細不明)と底面のUSB2.0ポートと2つのポートを備えるのだが、まさしくそのUSB2.0側のポートと同じような速度であった。何度試そうと、ファイルサイズを変えようとROG Phone5 Ultimateのサイドポートと比べて明らかに遅いのだ。内蔵ストレージの性能的には大差がないのに、有線接続した際の転送速度に明らかな差があるので、ROG Phone5 Ultimateに比べてUSBの規格が劣ると考えられる。

PC→EXP21 10GB pic.twitter.com/flM1LI3vtw

— ポッタル ((Pottal_MDS?)) December 15, 2021

なおEXP21のストレージはほとんど使っていないため、ストレージ容量の圧迫による速度低下はないと考えられる。

EXP21のUSB規格は分からなかった。

DisplayPort Alt Modeを使ってTypeCケーブル1本で映像出力が可能なディスプレイ(LG 34WP65G-B)に映像出力が可能であったため、EXP21はUSB 3.1に対応していることがわかるが、実際にファイルを転送してみるとUSB3.1どころか、USB2.0並の転送速度であった。USB3.1 Gen1なのかUSB3.1 Gen2なのか確かめようと思っていたのにますます混乱が深まる結果となった。

「DisplayPort Alt ModeはUSB 3.x以上が必須である」という認識は半分正しく、半分誤っています。USBやDisplayPortの仕様では、DP Alt Modeをサポートする場合にUSB 3.x以上もサポートすることは特に要件になっていないため、DP Alt Modeをサポートするデバイスが必ずしもUSB 3.x以上をサポートする必要はありません。一方で、DP Alt Modeの信号はUSB 3.x用の信号線 (SSRX/SSTX) を使ってモニターに伝送されるため、ケーブルについてはUSB 3.x以上をサポートしている必要があります (@Hanpenblog 2024)

目次に戻る

広告位置について

美しくない・ユーザーを混乱させてしまうといった理由から、ファーストビュー(ページの最上部やタイトル前後など最初に表示される一等地)に広告を設置しないように努めておりましたが、Google AdSenseの除外エリア設定では、そもそも除外エリアに指定できない箇所の広告はブロックできないため、ファーストビューに広告が設置されてしまうケースが何件か確認されました。

ここの位置に広告表示したくないのに、GoogleAdSenseの除外エリアに指定できなくて泣いてる pic.twitter.com/NTmyFVl2Ek

— ポッタル (@Pottal_MDS) June 18, 2024

これがきっかけで、Google AdSenseの自動広告を廃止することに決めました。

ゾーニングされていない悪質な広告について

Google AdSenseの設定でブロックしてもブロックしても湧いてくるゾーニングされていない広告と戦うのに疲れました。無理です。

Obsidianとは何か

Obsidianは個人用ナレッジマネジメントシステムとして設計されたノートテイキングアプリケーションです。 その特徴は大きく5つほどあり、①ローカルで動作・管理されること(クラウド同期・マルチデバイスにも対応), ②Markdownを用いることで頑強かつ汎用性があること, ③メモ同士を繋ぐグラフビューによる可視化が可能なこと, ④マウスホバーによるインライン表示が可能なこと, ⑤コミュニティプラグインと呼ばれる有志による拡張機能が豊富なことが挙げられ、特に①~③の特徴から、「第二の脳(Second Brain)」のツールとして着目されています。

例えば、クラウド上のメモサービス(Evernote, Notion, Google Keepなど)は、あくまでオンラインが前提であり、またサービスが終了してしまった場合、自分でデータをエクスポートしないとデータはおそらく消えてしまうことでしょう。また、データ検索もサーバーや回線の具合によってはうまくいかないことがあります。その点、Obsidianはオフライン(ローカル環境)が前提のアプリで、メモは全てデバイス上にMarkdownファイルとして保存されます。 Markdown(.md)はシンプルで読みやすいテキストベースのマークアップ言語であり、広く普及しているため、たとえObsidianがサービス終了したとしても問題なく他のアプリやテキストエディタ上で読むことができます。

同人ゲームへの活用

このツールを作る動機となったのが、ホワイトボード(無限キャンバス)上のアイデアをテキストに変換し、ゲーム作りを楽にしたいというものでした。

このプロットを直接使ってゲームのスクリプトに変換するということはしませんが、全体のプロットや章や節ごとのプロットを脚本に落とし込むのに使えればと思っています。

筆者の作りたいノベルゲームにおいては選択肢などによる分岐がとても重要になるので、スクリプトの改良を進めて本格的な分岐に対応できるようにしたいです。

知的生産の技術 こざね法への活用

『知的生産の技術』(梅棹 1969)というとても古い本があります。筆者は高校3年生の頃にこの本に出会い、以来ずっと読んだ時の感銘が熾火のように胸に残っており、同時にそこから学んだ知的生産の技術を活用・実行できていない悔しさや劣等感といったものが火傷のように心を苛んでいます。 1969年のものなので、とっくに時代遅れになってもおかしくない本なのですが、なんと2023年になっても色褪せておらず「アカデミックスキルズ図書リスト」（東京大学駒場図書館所蔵2023）の、しかもトップにこの本がリストアップされているようです(山本 2023)。ちなみに、それを知ったのはObsidianで知的生産の技術を活用したいと思って文献を読み漁っていたからです。

『知的生産の技術』(梅棹 1969)の何が今も輝いているのでしょうか。筆者は、それを「カード法」と「こざね法」にあると考えています。「カード法」は、同年代にドイツで活躍されていたニクラス・ルーマンのZettelkasten(ツェッテルカステン)メソッドに通じるものがあり、そちらの方が有名だと思います。このカード法(Zettelkasten)は、Obsidianが得意とするところであり、Obsidianを世に広めたい筆者としては声高らかに解説したいところなのですが、話の本筋から外れてしまうため、今回は「こざね法」の紹介だけにとどめておきます。

2-2-1. Google Fit APIについて

各アプリ・デバイスで計測した生データは、(Google Fitと連携させた場合)Google Fit APIを使ってJSON形式でアップロードされます。

データには睡眠ステージ, その睡眠ステージの開始時刻, 終了時刻が含まれています。睡眠ステージの判断は大元である各デバイス・アプリに任せられているようです。

サンプルJSONデータ.json

{
    "Data Source": "raw:com.google.sleep.segment:com.hoge",
    "Data Points": [
        {"fitValue":[{"value":{"intVal":1}}],"originDataSourceId":"","endTimeNanos":1620291780000000000,"dataTypeName":"com.google.sleep.segment","startTimeNanos":1620285780000000000,"modifiedTimeMillis":1624604115227,"rawTimestampNanos":0},
        {"fitValue":[{"value":{"intVal":3}}],"originDataSourceId":"","endTimeNanos":1620338280000000000,"dataTypeName":"com.google.sleep.segment","startTimeNanos":1620313260000000000,"modifiedTimeMillis":1624604115227,"rawTimestampNanos":0},
        {"fitValue":[{"value":{"intVal":5}}],"originDataSourceId":"","endTimeNanos":1620379200000000000,"dataTypeName":"com.google.sleep.segment","startTimeNanos":1620367020000000000,"modifiedTimeMillis":1624604115227,"rawTimestampNanos":0},
        {"fitValue":[{"value":{"intVal":6}}],"originDataSourceId":"","endTimeNanos":1620435480000000000,"dataTypeName":"com.google.sleep.segment","startTimeNanos":1620412740000000000,"modifiedTimeMillis":1624604117511,"rawTimestampNanos":0},
        {"fitValue":[{"value":{"intVal":1}}],"originDataSourceId":"","endTimeNanos":1620450300000000000,"dataTypeName":"com.google.sleep.segment","startTimeNanos":1620443520000000000,"modifiedTimeMillis":1624604117511,"rawTimestampNanos":0},
    ]
}

睡眠ステージの内訳は以下の通りです(Google for Developers 2023)。

懸念事項として、Google Fit APIが終了しHealth Connect API(?)へと移行されること(Google for Developers 2023)が挙げられます。今後、睡眠データはGoogle FitではなくHealth Connectに集約されることとなるでしょう。データのフォーマットが変わってしまうと、このノートブックの前提が崩れてしまうので、詳細が分かり次第対応していきたいと思います。

2-2-2. Python及びJupyter Notebookの採用理由

何を使って睡眠データの可視化・分析ツールを作るかは少し悩みました。R言語は、必要最低限の読み書きができるものの、ChatGPTをはじめとする生成AIの支援を受けにくいこと, 自分以外の人が使う際に配布・再現しにくいことがネックだったため、Pythonを採用しました。

Pythonは print("Hello World!") くらいしか知らないためChatGPTにあれこれ聞き、最終的にPythonというかJupyter Notebookを採用することになりました。

データの読み込み, データ属性の入力, 日付やデータ期間の選択といった作業を、スクリプトを書き換えるのではなくユーザーが直感的に分かりやすくボタン操作などで行える点(図 2)が、筆者の持つPython並びにJupyter Notebookへの苦手意識を上回ったからです。

3-2-1. Google Fit からデータをダウンロードする方法

1. Google データ エクスポートにアクセスします。

2. 追加するデータの選択 にて選択をすべて解除します(余計なデータが多すぎるため)。

   

3. Fit(Google Fit)のみを選択します。

   

4. 一番下までスクロールし、次のステップをクリックします。

5. ファイル形式、エクスポート回数、エクスポート先の選択をします。

   • エクスポート先 は ダウンロードリンクをメールで送信を選択します
   • 頻度は1回エクスポートを選択します
   • ファイル形式は.zipを選択します
   • ファイルサイズは50GBを選択します(念の為)
   • 上記を確認した後、エクスポートを作成をクリックします

   

6. データのエクスポートが処理され、ダウンロードリンクがメールで送られていくるまで数時間から数日かかります。気長に待ちます(ページを閉じても大丈夫です)。

   • 進捗はGoogle データ エクスポートにて確認できます
   • メールはデータのエクスポートをリクエストしたGoogleアカウント宛(gmail)に届きます

7. ダウンロードリンクが書かれたメールを開き、ダウンロードページに跳びます(ファイルをダウンロードをクリックします)。

   • メールの件名はGoogle データをダウンロードできるようになりましたでした

   

8. Googleアカウントのパスワードを入力後、データをダウンロードします。

   • 筆者の場合、エラーが含まれていました(が、どうしようもないので続行します)

   

以上で、Google Fitデータのダウンロードは終了です。

3-2-2. データ分析の流れ

1. モジュールのインポート

2. データの取り込み

3. (手動の睡眠記録がある場合)データセットの選択

4. (必要であれば)データをCSVファイルとしてエクスポート

5. アクトグラムを用いた四半期ごとの睡眠記録の可視化

   

6. 四半期ごとの統計

7. 任意の日付の睡眠記録の可視化

   

import subprocess
import sys

# 必要なライブラリをリストにまとめる
required_libraries = [
    'json',
    'pandas',
    'matplotlib',
    'pytz',
    'ipywidgets',
    'numpy',
    'seaborn',
    'ipyfilechooser',
    'plotly'
]

# ライブラリのインストール関数
def install_and_import(library):
    try:
        __import__(library)
    except ImportError:
        subprocess.check_call([sys.executable, "-m", "pip", "install", library])
        __import__(library)

# 各ライブラリのインストールとインポート
for library in required_libraries:
    install_and_import(library)

# インポート文
import json
import pandas as pd
import os
import matplotlib.pyplot as plt
plt.rcParams['font.family'] = 'Yu Mincho', #'Hiragino Kaku Gothic ProN', #'Meiryo', #'Noto Sans CJK JP'
import matplotlib.dates as mdates
import pytz
import ipywidgets as widgets
import numpy as np
import seaborn as sns
import plotly.graph_objects as go
import plotly.express as px
import plotly.io as pio
from ipywidgets import DatePicker, Button, HBox
from matplotlib.lines import Line2D
from pytz import timezone
from IPython.display import display, clear_output
from ipyfilechooser import FileChooser
from datetime import datetime
from datetime import timedelta

print("All libraries are installed and imported successfully.")

睡眠データの読み込み

# ファイルアップロードウィジェットの作成
uploader = widgets.FileUpload(
    accept='.json',  # JSONファイルのみを許可
    multiple=True,   # 複数のファイルをアップロード可能
    description='Upload JSON files'
)

file_loading_flag = False

# アップロードされたデータを処理する関数
def process_uploaded_files(change):
    global file_loading_flag
    # 処理中メッセージを表示
    with output:
        clear_output()
        print("ファイルの処理中です。次のセルには進まないでください。")
        sys.stdout.flush()  # 出力を即座にフラッシュ

    try:
        for file_info in change['new']:
            print(f"Processing {file_info['name']}")
            sys.stdout.flush()  # 出力を即座にフラッシュ
            content = file_info['content']
            import_data = json.loads(content.tobytes().decode('utf-8'))
            df = load_and_process_sleep_data(import_data, 'Type of Sleep')
        print("ファイルの読み込みが完了しました。次のセルに進んでください")
        file_loading_flag = True

        with output:
            if file_loading_flag is True:
                clear_output()
                print("ファイルの読み込みが完了しました。次のセルに進んでください。")
                sys.stdout.flush()  # 出力を即座にフラッシュ

    except Exception as e:
        with output:
            clear_output()
            print(f"エラーが発生しました: {e}")
            sys.stdout.flush()  # 出力を即座にフラッシュ


# JSONデータをDataFrameに変換するための関数
def load_and_process_sleep_data(import_data, type_value):
    data_source = import_data['Data Source']
    data_points = import_data['Data Points']
    df = pd.DataFrame([{
        'data_source': data_source,
        'start_time_ns': dp['startTimeNanos'],
        'end_time_ns': dp['endTimeNanos'],
        'sleep_state': dp['fitValue'][0]['value']['intVal'],
        'modified_time_ms': dp['modifiedTimeMillis'],
        'Type': type_value
    } for dp in data_points])
    df['start_time'] = pd.to_datetime(df['start_time_ns'], unit='ns')
    df['end_time'] = pd.to_datetime(df['end_time_ns'], unit='ns')
    return df

# 出力ウィジェットの作成
output = widgets.Output()

# 初期メッセージの表示
with output:
    print("ファイルの処理が完了するまで、次のセルには進まないでください")


# アップロードイベントに関数をバインド
uploader.observe(process_uploaded_files, names='value')

# ウィジェットの表示
display(uploader)
display(output)

睡眠データのフォーマット関数など

def parse_datetime_with_format(dt_series):
    dt_series_with_ms = dt_series[dt_series.astype(str).str.contains(r"\.\d+")]
    dt_series_without_ms = dt_series[~dt_series.astype(str).str.contains(r"\.\d+")]
    parsed_with_ms = pd.to_datetime(dt_series_with_ms, format='%Y-%m-%d %H:%M:%S.%f', errors='coerce')
    parsed_without_ms = pd.to_datetime(dt_series_without_ms, format='%Y-%m-%d %H:%M:%S', errors='coerce')
    return pd.concat([parsed_with_ms, parsed_without_ms]).sort_index()

# アップロードされたファイル名とデータの取得
uploaded_files = uploader.value

手動睡眠記録の識別

# 説明文を表示
description_label = widgets.Label('もし手動で睡眠記録を開始/停止したデータセットがあれば該当するものにチェックを入れてください。')
display(description_label)

# 空のデータフレームを初期化
combined_data = pd.DataFrame()

# ファイルと対応するチェックボックスを表示
checkboxes = []
for file_details in uploader.value:
    cb = widgets.Checkbox(
        value=False,
        description='',  
        disabled=False
    )
    label = widgets.Label(file_details['name'])  
    box = widgets.HBox([cb, label])  
    checkboxes.append(cb)
    display(box)

# プロセスボタンを作成
process_button = widgets.Button(description="決定(データを処理)")

# ボタンのイベントハンドラー
def on_button_clicked(b):
    clear_output(wait=True)
    global combined_data
    for cb, file_details in zip(checkboxes, uploader.value):
        filename = file_details['name']
        content = file_details['content']
        sleep_data = json.loads(content.tobytes().decode('utf-8'))

        # チェックボックスの値に応じてデータタイプを設定
        type_column_value = 'Manual' if cb.value else 'Auto'
        data = load_and_process_sleep_data(sleep_data, type_column_value)
        combined_data = pd.concat([combined_data, data], ignore_index=True)

    # データ処理後の状態を表示
    print("Data processing complete. Dataframe contains:", combined_data.shape[0], "rows.")
    
process_button.on_click(on_button_clicked)
display(process_button)

CSVとしてエクスポート

# CSVを保存する関数
# ユーザーのデスクトップパスを取得
desktop_path = os.path.join(os.environ['USERPROFILE'], 'Desktop')

# CSVを保存する関数
def save_csv(sleep_data, path):
    sleep_data.to_csv(path, index=False)
    return f'CSVファイルを {path}に保存しました。'

# 「Save」ボタンの動作を定義
def on_save_button_clicked(b):
    with output:
        clear_output()
        if not fc.selected:
            print("CSVファイルの保存先を選択してください")
        else:
            # ここでDataFrameを保存
            result = save_csv(sleep_data, fc.selected)  # dfは保存したいDataFrameの変数名
            print(result)

# ファイル選択ダイアログを設定
fc = FileChooser(desktop_path)
fc.default_filename = 'sleep_data.csv'
fc.use_dir_icons = True

# 「Save」ボタンの作成
save_button = widgets.Button(
    description='Save',
    button_style='',
    tooltip='Click to save the CSV file',
    icon='check'
)
save_button.on_click(on_save_button_clicked)

# 出力エリアを設定
output = widgets.Output()

# ウィジェットを表示
display(fc, save_button, output)

アクトグラムの表示を準備するセル

#  日またぎを処理する関数
def adjust_end_time(start, end):
    if end < start:
        end += 1440  # 翌日にまたがる場合は24時間分（分）を加算
    return end

def convert_to_jst_if_needed(column):
    # タイムゾーン情報を確認し、必要に応じて変換を行う
    if column.dt.tz is None:
        # タイムゾーン情報がない場合、UTCとして解釈し、JSTに変換
        return pd.to_datetime(column, utc=True).dt.tz_convert('Asia/Tokyo')
    elif str(column.dt.tz) == 'UTC':
        # タイムゾーンがUTCであれば、JSTに変換
        return column.dt.tz_convert('Asia/Tokyo')
    elif str(column.dt.tz) != 'Asia/Tokyo':
        # タイムゾーンがJSTでない他のタイムゾーンであれば、JSTに変換
        return column.dt.tz_convert('Asia/Tokyo')
    else:
        # 既にJSTであればそのまま返す
        return column

def convert_sleep_data_to_jst(sleep_data):
    # sleep_dataをコピーしてタイムゾーンを変換
    jst_sleep_data = sleep_data.copy()
    jst_sleep_data['start_time'] = convert_to_jst_if_needed(jst_sleep_data['start_time'])
    jst_sleep_data['end_time'] = convert_to_jst_if_needed(jst_sleep_data['end_time'])
    
    # 明示的に datetime64[ns, Asia/Tokyo] にキャスト
    jst_sleep_data['start_time'] = jst_sleep_data['start_time'].astype('datetime64[ns, Asia/Tokyo]')
    jst_sleep_data['end_time'] = jst_sleep_data['end_time'].astype('datetime64[ns, Asia/Tokyo]')
    
    return jst_sleep_data

def plot_actogram(sleep_data, start_date, end_date):
    # タイムゾーン変換後のデータを取得
    jst_sleep_data = convert_sleep_data_to_jst(sleep_data)

    # 指定された期間でデータをフィルタリング
    filtered_data = jst_sleep_data[
        (jst_sleep_data['start_time'] >= pd.Timestamp(start_date).tz_localize('Asia/Tokyo')) &
        (jst_sleep_data['end_time'] <= pd.Timestamp(end_date).tz_localize('Asia/Tokyo'))
    ].copy()
    
    if filtered_data.empty:
        print(f"No data available to plot between {start_date} and {end_date}.")
        return

    # 日またぎを考慮した時間の計算
    filtered_data['start_minutes'] = filtered_data['start_time'].apply(lambda dt: dt.hour * 60 + dt.minute)
    filtered_data['end_minutes'] = filtered_data.apply(
        lambda row: adjust_end_time(row['start_minutes'], row['start_minutes'] + (row['end_time'] - row['start_time']).seconds // 60), axis=1)

    color_map = {1: '#e0ffff', 2: '#b3e5fc', 3: '#ff5252', 4: '#03a9f4', 5: '#303f9f', 6: '#ab47bc', 10: 'yellow'}
    filtered_data['color'] = filtered_data['sleep_state'].map(color_map)

    num_days = max(1, (pd.Timestamp(end_date) - pd.Timestamp(start_date)).days + 1)
    fig, ax = plt.subplots(figsize=(20, num_days * 0.4))
    for _, row in filtered_data.iterrows():
        day_of_week = (row['start_time'] - pd.Timestamp(start_date).tz_localize('Asia/Tokyo')).days
        ax.plot([row['start_minutes'], row['end_minutes']], [day_of_week, day_of_week], color=row['color'], alpha=0.7)
        ax.plot([row['start_minutes'] + 1440, row['end_minutes'] + 1440], [day_of_week + 1, day_of_week + 1], color=row['color'], alpha=0.7)

    ax.set_xlim(0, 2880)
    ax.set_ylim(0, num_days)
    ax.set_yticks(range(num_days))
    ax.set_yticklabels([(pd.Timestamp(start_date).tz_localize('Asia/Tokyo') + pd.Timedelta(days=x)).strftime('%Y-%m-%d') for x in range(num_days)])
    ax.set_xlabel('Time')
    ax.set_ylabel('Days from Start Date')
    plt.title(f'Actogram from {start_date} to {end_date}')
    plt.grid(True)
    plt.xticks(ticks=[i * 60 for i in range(49)], labels=[f'{(i % 24):02d}:00' if i % 2 == 0 else '' for i in range(49)], rotation=45)
    plt.show()



# データセットの範囲確認
jst_sleep_data = convert_sleep_data_to_jst(sleep_data)
start_date = jst_sleep_data['start_time'].min().strftime('%Y-%m-%d')
end_date = jst_sleep_data['start_time'].max().strftime('%Y-%m-%d')
print(f"This dataset contains data from {start_date} to {end_date}.")

全ての期間を対象に四半期ごとにアクトグラムをプロット

# 四半期毎にデータをプロット
start_year = jst_sleep_data['start_time'].dt.year.min()
end_year = jst_sleep_data['start_time'].dt.year.max()
last_date = jst_sleep_data['start_time'].max()

for year in range(start_year, end_year + 1):
    for quarter in range(1, 5):
        start_month = 3 * quarter - 2
        end_month = 3 * quarter
        quarter_start_date = pd.Timestamp(year=year, month=start_month, day=1).tz_localize('Asia/Tokyo')
        quarter_end_date = pd.Timestamp(year=year, month=end_month, day=1).tz_localize('Asia/Tokyo') + pd.DateOffset(months=1) - pd.DateOffset(days=1)
        
        if quarter_start_date > last_date:
            break  # この四半期の開始日がデータセットの最後の日を超えている場合はスキップ
        if quarter_end_date > last_date:
            quarter_end_date = last_date  # 四半期の終了日がデータセットの最後の日を超えている場合は調整

        plot_actogram(jst_sleep_data, quarter_start_date.strftime('%Y-%m-%d'), quarter_end_date.strftime('%Y-%m-%d'))

任意の期間に絞ったアクトグラムのプロット

# 任意の期間のアクトグラム

def plot_interactive_actogram(sleep_data, start_date, end_date):
    # タイムゾーン変換後のデータを取得
    jst_sleep_data = convert_sleep_data_to_jst(sleep_data)

    # 指定された期間でデータをフィルタリング
    filtered_data = jst_sleep_data[
        (jst_sleep_data['start_time'] >= pd.Timestamp(start_date).tz_localize('Asia/Tokyo')) &
        (jst_sleep_data['end_time'] <= pd.Timestamp(end_date).tz_localize('Asia/Tokyo'))
    ].copy()

    if filtered_data.empty:
        print(f"No data available to plot between {start_date} and {end_date}.")
        return

    # 日またぎを考慮した時間の計算
    filtered_data['start_minutes'] = filtered_data['start_time'].apply(lambda dt: dt.hour * 60 + dt.minute)
    filtered_data['end_minutes'] = filtered_data.apply(
        lambda row: adjust_end_time(row['start_minutes'], row['start_minutes'] + (row['end_time'] - row['start_time']).seconds // 60), axis=1)

    color_map = {
        1: '#e0ffff',  # 覚醒（睡眠サイクル中）
        2: '#b3e5fc',  # 睡眠
        3: '#ff5252',  # ベッド外
        4: '#03a9f4',  # 浅い睡眠
        5: '#303f9f',  # 深い睡眠
        6: '#ab47bc',   # レム睡眠
        10: 'black'    # ミッドスリープタイム（色を強調）
    }
    sleep_stage_labels = {
        1: '覚醒（睡眠サイクル中）',
        2: '睡眠',
        3: 'ベッド外',
        4: '浅い睡眠',
        5: '深い睡眠',
        6: 'レム睡眠',
        10: 'ミッドスリープタイム'
    }
    filtered_data['color'] = filtered_data['sleep_state'].map(color_map)

    num_days = max(1, (pd.Timestamp(end_date) - pd.Timestamp(start_date)).days + 1)
    fig = go.Figure()

    for sleep_state, color in color_map.items():
        sleep_state_data = filtered_data[filtered_data['sleep_state'] == sleep_state]
        if not sleep_state_data.empty:
            for _, row in sleep_state_data.iterrows():
                day_of_week = (row['start_time'] - pd.Timestamp(start_date).tz_localize('Asia/Tokyo')).days
                line_width = 7.5 if sleep_state == 10 else 5  # ミッドスリープタイムの場合は線の太さを15に設定
                y_offset = 0 if sleep_state == 10 else 0  # ミッドスリープタイムの場合はy座標をさらにオフセット
                opacity = 1 if sleep_state == 10 else 0.5  # ミッドスリープタイム以外は透明度を0.3に設定
                fig.add_trace(go.Scatter(
                    x=[row['start_minutes'], row['end_minutes']],
                    y=[day_of_week + y_offset, day_of_week + y_offset],
                    mode='lines',
                    line=dict(color=row['color'], width=line_width),
                    name=sleep_stage_labels[sleep_state],
                    text=f"{row['start_time'].strftime('%Y-%m-%d %H:%M')} to {row['end_time'].strftime('%Y-%m-%d %H:%M')}",
                    hoverinfo='text',
                    opacity=opacity
                ))
                fig.add_trace(go.Scatter(
                    x=[row['start_minutes'] + 1440, row['end_minutes'] + 1440],
                    y=[day_of_week + 1 + y_offset, day_of_week + 1 + y_offset],
                    mode='lines',
                    line=dict(color=row['color'], width=line_width),
                    name=sleep_stage_labels[sleep_state],
                    text=f"{row['start_time'].strftime('%Y-%m-%d %H:%M')} to {row['end_time'].strftime('%Y-%m-%d %H:%M')}",
                    hoverinfo='text',
                    opacity=opacity
                ))

    # 凡例を統合
    unique_labels = set()
    fig.for_each_trace(lambda trace: trace.update(showlegend=False) if trace.name in unique_labels else unique_labels.add(trace.name))

    fig.update_layout(
        title=f'Interactive Actogram from {start_date} to {end_date}',
        xaxis_title='Time',
        yaxis_title='Days from Start Date',
        xaxis=dict(
            tickmode='array',
            tickvals=[i * 60 for i in range(49)],
            ticktext=[f'{(i % 24):02d}:00' if i % 2 == 0 else '' for i in range(49)],
            range=[0, 2880]
        ),
        yaxis=dict(
            tickvals=list(range(num_days)),
            ticktext=[(pd.Timestamp(start_date).tz_localize('Asia/Tokyo') + pd.Timedelta(days=x)).strftime('%Y-%m-%d') for x in range(num_days)],
            range=[0, num_days],
            tickfont=dict(size=10)  # Y軸ラベルの文字サイズを小さく
        ),
        hovermode='closest',
        legend=dict(
            itemsizing='constant'
        )
    )

    pio.write_html(fig, file='sleep_data_plot.html', auto_open=True)

# ウィジェットの作成
start_date_picker = widgets.DatePicker(
    description='Start Date',
    disabled=False
)
end_date_picker = widgets.DatePicker(
    description='End Date',
    disabled=False
)
interactive_button = widgets.Button(
    description='Plot Interactive Actogram',
    button_style='info',
    tooltip='Click to plot the interactive actogram',
    icon='line-chart'
)
notice_label = widgets.Label(
    value='データ範囲は四半期(3ヶ月)程度にしてください。それ以上の期間を指定すると文字が潰れて読めなくなります。また、グラフの作成には少し時間がかかります。'
)

# ボタンがクリックされたときの動作
def on_button_clicked(b):
    start_date = start_date_picker.value
    end_date = end_date_picker.value
    if start_date is not None and end_date is not None:
        plot_interactive_actogram(sleep_data, start_date, end_date)
    else:
        print("Please select both start and end dates.")

interactive_button.on_click(on_button_clicked)

# ウィジェットの表示
display(notice_label, start_date_picker, end_date_picker, interactive_button)

睡眠の統計

def calculate_sleep_quality(sleep_data):
    # 各セッションの睡眠時間を計算
    session_start_end = sleep_data.groupby('session_id').agg(
        start_time=('start_time', 'min'),
        end_time=('end_time', 'max')
    ).reset_index()
    session_start_end['sleep_duration_total'] = (session_start_end['end_time'] - session_start_end['start_time']).dt.total_seconds() / 3600
    
    # 深い睡眠の割合を計算
    sleep_data['sleep_duration'] = (sleep_data['end_time'] - sleep_data['start_time']).dt.total_seconds() / 3600
    deep_sleep_data = sleep_data[sleep_data['sleep_state'] == 5]  # 深い睡眠
    deep_sleep_duration = deep_sleep_data.groupby('session_id')['sleep_duration'].sum().reset_index()
    
    # 列名を変更
    deep_sleep_duration.rename(columns={'sleep_duration': 'sleep_duration_deep'}, inplace=True)
    
    sleep_quality = pd.merge(session_start_end, deep_sleep_duration, on='session_id', how='left')
    sleep_quality['sleep_quality'] = sleep_quality['sleep_duration_deep'].fillna(0) / sleep_quality['sleep_duration_total']
    
    return sleep_quality[['session_id', 'sleep_duration_total', 'sleep_quality']]

def calculate_quarterly_sleep_stats(sleep_data):
    sleep_quality = calculate_sleep_quality(sleep_data)
    sleep_data = pd.merge(sleep_data, sleep_quality, on='session_id')
    
    sleep_data['quarter'] = sleep_data['start_time'].dt.to_period('Q')
    quarterly_stats = sleep_data.groupby('quarter').agg(
        avg_sleep_time=('sleep_duration_total', 'mean'),
        avg_sleep_quality=('sleep_quality', 'mean')
    ).reset_index()
    
    return quarterly_stats

def plot_quarterly_sleep_stats(quarterly_stats):
    fig, ax1 = plt.subplots(figsize=(18, 6))

    ax1.set_xlabel('Quarter')
    ax1.set_ylabel('Average Sleep Time (hours)', color='tab:blue')
    ax1.plot(quarterly_stats['quarter'].astype(str), quarterly_stats['avg_sleep_time'], color='tab:blue', marker='o', label='Avg Sleep Time')
    ax1.tick_params(axis='y', labelcolor='tab:blue')

    ax2 = ax1.twinx()
    ax2.set_ylabel('Average Sleep Quality', color='tab:orange')
    ax2.plot(quarterly_stats['quarter'].astype(str), quarterly_stats['avg_sleep_quality'], color='tab:orange', marker='o', linestyle='--', label='Avg Sleep Quality')
    ax2.tick_params(axis='y', labelcolor='tab:orange')

    fig.tight_layout()
    fig.legend(loc='upper left', bbox_to_anchor=(0.1, 0.9))
    plt.title('Quarterly Average Sleep Time and Quality')
    plt.show()

def calculate_weekly_sleep_stats(sleep_data):
    sleep_quality = calculate_sleep_quality(sleep_data)
    sleep_data = pd.merge(sleep_data, sleep_quality, on='session_id')
    
    sleep_data['quarter'] = sleep_data['start_time'].dt.to_period('Q')
    sleep_data['weekday'] = sleep_data['start_time'].dt.day_name()
    weekly_stats = sleep_data.groupby(['quarter', 'weekday']).agg(
        avg_sleep_time=('sleep_duration_total', 'mean'),
        avg_sleep_quality=('sleep_quality', 'mean')
    ).reset_index()
    
    return weekly_stats

def plot_weekly_sleep_stats_boxplot(sleep_data_jst):
    sleep_quality = calculate_sleep_quality(sleep_data_jst)
    sleep_data = pd.merge(sleep_data_jst, sleep_quality, on='session_id')
    
    sleep_data['quarter'] = sleep_data['start_time'].dt.to_period('Q')
    sleep_data['weekday'] = sleep_data['start_time'].dt.day_name()
    weekdays = ['Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday', 'Sunday']
    weekday_colors = ['#3498db', '#3498db', '#3498db', '#3498db', '#3498db', '#e74c3c', '#e74c3c']  # 平日は青、土日は赤
    weekday_palette = dict(zip(weekdays, weekday_colors))

    for quarter in sleep_data['quarter'].unique():
        quarter_data = sleep_data[sleep_data['quarter'] == quarter]
        
        fig, (ax1, ax2) = plt.subplots(2, 1, figsize=(12, 12))
        
        # 睡眠時間の箱ひげ図
        sns.boxplot(x='weekday', y='sleep_duration_total', data=quarter_data, order=weekdays, palette=weekday_palette, ax=ax1, hue='weekday', dodge=False)
        ax1.set_title(f'Weekly Sleep Duration for {quarter}')
        ax1.set_xlabel('Weekday')
        ax1.set_ylabel('Sleep Duration (hours)')
        ax1.legend([],[], frameon=False)  # レジェンドを非表示にする

        # 睡眠の質の箱ひげ図
        sns.boxplot(x='weekday', y='sleep_quality', data=quarter_data, order=weekdays, palette=weekday_palette, ax=ax2, hue='weekday', dodge=False)
        ax2.set_title(f'Weekly Sleep Quality for {quarter}')
        ax2.set_xlabel('Weekday')
        ax2.set_ylabel('Sleep Quality')
        ax2.legend([],[], frameon=False)  # レジェンドを非表示にする
        
        plt.tight_layout()
        plt.show()


# データの準備
sleep_data_jst = convert_sleep_data_to_jst(sleep_data)

# 四半期ごとの統計を計算
quarterly_stats = calculate_quarterly_sleep_stats(sleep_data_jst)

# 結果をプロット
plot_quarterly_sleep_stats(quarterly_stats)

# 曜日別の統計を計算
weekly_stats = calculate_weekly_sleep_stats(sleep_data_jst)

# 結果を箱ひげ図でプロット
plot_weekly_sleep_stats_boxplot(sleep_data_jst)

任意の日付の睡眠記録の可視化

def convert_to_jst_if_needed(column):
    # タイムゾーン情報を確認し、必要に応じて変換を行う
    if column.dt.tz is None:
        # タイムゾーン情報がない場合、UTCとして解釈し、JSTに変換
        return pd.to_datetime(column, utc=True).dt.tz_convert('Asia/Tokyo')
    elif str(column.dt.tz) == 'UTC':
        # タイムゾーンがUTCであれば、JSTに変換
        return column.dt.tz_convert('Asia/Tokyo')
    elif str(column.dt.tz) != 'Asia/Tokyo':
        # タイムゾーンがJSTでない他のタイムゾーンであれば、JSTに変換
        return column.dt.tz_convert('Asia/Tokyo')
    else:
        # 既にJSTであればそのまま返す
        return column

def convert_sleep_data_to_jst(sleep_data):
    # sleep_dataをコピーしてタイムゾーンを変換
    sleep_data_jst = sleep_data.copy()
    sleep_data_jst['start_time'] = convert_to_jst_if_needed(sleep_data_jst['start_time'])
    sleep_data_jst['end_time'] = convert_to_jst_if_needed(sleep_data_jst['end_time'])
    if 'in_bed_time' in sleep_data.columns:
        sleep_data_jst['in_bed_time'] = convert_to_jst_if_needed(sleep_data_jst['in_bed_time'])
    else:
        sleep_data_jst['in_bed_time'] = None
        
    # 明示的に datetime64[ns, Asia/Tokyo] にキャスト
    sleep_data_jst['start_time'] = sleep_data_jst['start_time'].astype('datetime64[ns, Asia/Tokyo]')
    sleep_data_jst['end_time'] = sleep_data_jst['end_time'].astype('datetime64[ns, Asia/Tokyo]')
    sleep_data_jst['in_bed_time'] = sleep_data_jst['in_bed_time'].astype('datetime64[ns, Asia/Tokyo]')
    
    return sleep_data_jst

def create_session_data(sleep_data_jst):
    # 各セッションの最終 'end_time' を取得して日付に変換
    session_dates = sleep_data_jst.groupby('session_id')['end_time'].max().dt.date
    session_dates = session_dates.reset_index()
    session_dates.rename(columns={'end_time': 'session_date'}, inplace=True)
    
    # 睡眠時間と睡眠潜時の計算
    sleep_times = sleep_data_jst.groupby('session_id').agg(
        sleep_time=('end_time', lambda x: (x.max() - x.min()).total_seconds() / 3600),
        start_time=('start_time', 'min')
    )
    sleep_times.reset_index(inplace=True)

    # 睡眠潜時の計算
    sleep_latency = sleep_data_jst.groupby('session_id').apply(
        lambda group: calculate_sleep_latency(group[['in_bed_time', 'start_time', 'Type', 'sleep_state']]),
        include_groups=False  # 追加: グループ化列を適用操作から除外
    ).reset_index(name='sleep_latency')

    # 結合して全データを含むデータフレームを作成
    full_session_data = pd.merge(session_dates, sleep_times[['session_id', 'sleep_time']], on='session_id')
    full_session_data = pd.merge(full_session_data, sleep_latency, on='session_id')
    
    return full_session_data

def calculate_sleep_latency(group):
    group = group.sort_values(by='start_time')
    auto_sleep_times = group[(group['Type'] == 'Auto') & (group['sleep_state'] >= 4)]
    if not auto_sleep_times.empty:
        auto_sleep_time = auto_sleep_times['start_time'].iloc[0]
        if pd.notna(group['in_bed_time'].iloc[0]) and group['in_bed_time'].iloc[0] <= group['start_time'].iloc[0]:
            return (auto_sleep_time - group['in_bed_time'].iloc[0]).total_seconds() / 60
    return np.nan

sleep_data_jst = convert_sleep_data_to_jst(sleep_data)
full_session_data = create_session_data(sleep_data_jst)

# 日付選択ウィジェット
date_picker = DatePicker(description='Select Date', disabled=False)

def on_prev_clicked(b):
    date_picker.value = date_picker.value - pd.Timedelta(days=1) if date_picker.value else None

def on_next_clicked(b):
    date_picker.value = date_picker.value + pd.Timedelta(days=1) if date_picker.value else None

button_prev = Button(description="Previous Day")
button_next = Button(description="Next Day")
button_prev.on_click(on_prev_clicked)
button_next.on_click(on_next_clicked)

display(HBox([button_prev, button_next]))
display(date_picker)

# タイムゾーンを確認して適切に日付を表示する関数
def set_plot_title(ax, session_id, sleep_data_jst):
    jst = pytz.timezone('Asia/Tokyo')

    session_data = sleep_data_jst[sleep_data_jst['session_id'] == session_id]
    if not session_data.empty:
        if session_data['start_time'].dt.tz:
            start_time_jst = session_data['start_time'].min().astimezone(jst)
            end_time_jst = session_data['end_time'].max().astimezone(jst)
        else:
            start_time_utc = session_data['start_time'].min().replace(tzinfo=pytz.utc)
            end_time_utc = session_data['end_time'].max().replace(tzinfo=pytz.utc)
            start_time_jst = start_time_utc.astimezone(jst)
            end_time_jst = end_time_utc.astimezone(jst)

        title = f"Sleep Session from {start_time_jst.strftime('%Y-%m-%d %H:%M')} to {end_time_jst.strftime('%Y-%m-%d %H:%M')}"
        ax.set_title(title)
    else:
        ax.set_title("No data available for this session")

# キャプションを追加する関数
def add_caption(ax, session_id, full_session_data):
    record = full_session_data[full_session_data['session_id'] == session_id].iloc[0]
    
    # キャプションの初期部分
    caption = f"睡眠時間: {record['sleep_time']:.2f} 時間\n"
    
    # sleep_latencyがNaNやマイナスでない場合のみ追加
    if pd.notna(record['sleep_latency']) and record['sleep_latency'] >= 0:
        caption += f"睡眠潜時(布団に入ってから寝付くまでの時間): {record['sleep_latency']:.2f} 分"
    
    ax.text(0.01, 0.95, caption, transform=ax.transAxes, fontsize=12, verticalalignment='top')

# 睡眠データをプロットする関数
def plot_sleep_data(session_id, sleep_data_jst, full_session_data):
    session_info = full_session_data[full_session_data['session_id'] == session_id]
    session_data = sleep_data_jst[sleep_data_jst['session_id'] == session_id]

    if not session_data.empty:
        # 日時データのタイムゾーンを確認し、日本時間に設定
        if session_data['start_time'].dt.tz is None:
            session_data['start_time'] = session_data['start_time'].dt.tz_localize('UTC').dt.tz_convert('Asia/Tokyo')
        if session_data['end_time'].dt.tz is None:
            session_data['end_time'] = session_data['end_time'].dt.tz_localize('UTC').dt.tz_convert('Asia/Tokyo')

        fig, ax = plt.subplots(figsize=(20, 7))
        stage_height = {3: 5, 1: 4, 4: 3, 6: 2, 5: 1, 10: 6}
        stage_colors = {1: '#e0ffff', 3: '#ff5252', 4: '#03a9f4', 5: '#303f9f', 6: '#ab47bc', 10:'yellow'}
        data_sources = session_data['data_source'].unique()
        source_count = len(data_sources)
        alpha_value = 1 / source_count if source_count > 0 else 1

        # プロットの時間を日本時間に合わせて設定
        for index, row in session_data.iterrows():
            start_pos = mdates.date2num(row['start_time'])
            duration = mdates.date2num(row['end_time']) - start_pos
            ax.bar(x=start_pos, height=stage_height[row['sleep_state']], width=duration,
                   color=stage_colors.get(row['sleep_state'], '#FFFFFF'), edgecolor='black',
                   align='edge', alpha=alpha_value)

        ax.xaxis_date(tz=timezone('Asia/Tokyo'))
        ax.xaxis.set_major_locator(mdates.HourLocator(interval=1))
        ax.xaxis.set_major_formatter(mdates.DateFormatter('%H:%M', tz=timezone('Asia/Tokyo')))
        ax.set_ylim(0, 6)
        ax.set_yticks([1, 2, 3, 4, 5, 6])
        ax.set_yticklabels(['Deep Sleep', 'REM', 'Light Sleep', 'Awake', 'Out-of-bed', 'Mid Sleep Time'])
        ax.set_xlabel('Time of Day')
        set_plot_title(ax, session_id, sleep_data_jst)
        add_caption(ax, session_id, session_info)
        plt.tight_layout()
        plt.show()
    else:
        print("No sleep data available for this session.")

# 日付変更時のイベントハンドラ
def on_date_change(change):
    if change['new'] is not None:
        selected_date = pd.to_datetime(change['new']).date()
        session_id = next((sid for sid, date in full_session_data.set_index('session_id')['session_date'].items() if date == selected_date), None)
        if session_id is not None:
            plot_sleep_data(session_id, sleep_data_jst, full_session_data)
        else:
            print("No sessions found for this date.")

date_picker.observe(on_date_change, names='value')