去年に一軒家に引っ越しました！ 🎉

良い感じの工務店を (妻が) 見つけて、高気密・高断熱な住宅を建てていただきました。

引っ越してからしばらく経ったので、実際に高気密・高断熱の効果ってどんなもんなのか、確認してみます。

体感

体感としては、以前に比べ非常に快適に感じます。

以前は特に冬は朝起きると窓が結露でずぶ濡れになっていましたし、私がアイアンベッドの上に敷いている木のすのこはすぐにカビが生えてしまっていました (なので朝起きたら布団乾燥機を布団とすのこの間に差し込んで乾燥させていた)。

※なお妻と子のすのこは乾燥機もかけていないのに一切カビず。うおォン 俺はまるで人間スチーム式加湿器だ。

引っ越してからは不気味なほどに結露がありませんし、部屋の温湿度が一定な気がしており、快適に感じます。人間スチーム式加湿器によるカビも生えなくなりました。

が、結露やカビはともかく、体感は住宅への思い入れ込みなんじゃないの？という気もするので実際の数値を見ていきます。

以前の住まいとの温湿度の比較

以下のように、書斎と寝室の温湿度を SwitchBot の温湿度計を使って Mackerel に記録しています。

Mackerel に部屋の温湿度を記録する

Amazon プライムデーだぜ！ということで SwitchBot の温湿度計を買いました。 https://www.amazon.co.jp/gp/product/B07L4QNZVF とりあえず仕事部屋に置いているのですが、いい感じです。寝室用にも欲しい。買い足そうかな…。 ただ置くだけでも温湿度が見れて便利なのですが、スマートホーム的な観点でメトリクスをとっていきたい。一年を通した記録を見ることで除湿・加湿器を買う際のスペックの参考にもなりそうですし、体調との関連性とかも見れたら面白そう。特に妻は頭痛持ちなので何か法則とか見出せたら役立ちそう (おそらく気圧が主な影響ぽいですが)。…

ゆるふわキャンパーLorentzca

これを前の年の同じ時期の記録と比較すれば、いい感じに比較ができそうな気がするのでやってみましょう。

Mackerel には式を書いてグラフをカスタマイズする神機能があります。

式で使える関数の一つに timeShift 関数があり、これを使うと指定した期間ずらしたメトリックを取得できます。

timeShift(metrics, duration)        指定した期間分時刻をずらしたメトリックを返します        timeShift(service(Blog, foo.bar), 1d)

また、group 関数を使うことで複数のメトリックを一つのグラフにまとめられます。

group(metrics, metrics, ...)        引数のメトリック列を１つにまとめます        group(service(Blog, foo.bar), service(Blog, foo.baz))

alias 関数を使い、メトリックにわかりやすい名前もつけられます。

alias(metrics, displayName)        メトリックの表示名をカスタマイズします        alias(service(Blog, foo.bar), 'Blog foo bar')

これらの関数を使い、一年前の温湿度と現在の温湿度を同じグラフに表示し、比較してみます。

式を作成していきます。以下は書斎の温湿度比較グラフを作っています。

group(
  alias(service(SmartHome, homeoffice.temphum.temperature), '温度'),
  alias(service(SmartHome, homeoffice.temphum.humidity), '湿度'),
  alias(timeShift(service(SmartHome, homeoffice.temphum.temperature), 1y), '温度 (一年前)'),
  alias(timeShift(service(SmartHome, homeoffice.temphum.humidity), 1y), '湿度 (一年前)')
)

するとこんな感じでグラフが取得できました。一年前のメトリックと重ね合わせて表示されており、わかりやすいですね。

同様に寝室の温湿度比較グラフも作ります。

こうして見ると、一年前 (に住んでいた住宅) と比較し明らかに温湿度の変化が少なくなっていることがわかります。

もちろん、その年や地域の気候差による部分もあるとは思いますが、そこまでかけ離れた気候差も無いと思いますので、住宅の性能によって一定の結果を得られていると考えても良いんじゃないかな〜と思います。

感想

体感だけでなく、数値として高気密・高断熱の効果を視覚的に確認でき、面白い結果になりました。

また、せっかくなのでこのグラフを埋め込みリンクとして公開し、Kibela の公開記事に埋め込み、工務店の方に共有しました。あまりこういったことをされる方はいないようで (まあそうですよね…自分もたまたまですし…) 思ったより喜んでいただけました。

こういったメトリックの収集やカスタマイズ、共有がさらっとできるのが Mackerel の良いところだな〜と思います。

Mackerel は業務だけでなく、プライベートな生活にも役立つということで、今後も思いつき次第色々試していく所存です。 😃

もう二月ですが明けましておめでとうございます！🎍

去年の終わりに引っ越したのですが、引っ越しを機に在宅ワーク環境を一新しようと、少しずつ準備してきました。

チェアからデスク、モニターや入力機器、大物が一通り揃いましたので俺の考えた最強のデスク環境 2025 (仮) としてここに記録しておきます。

(仮) なのはまだまだ細かい調整をしていきたいのと、恐らくデスク環境沼から脱することは難しいと今から半ば諦めているからです。😇

それではまずは書斎から。

書斎

3 畳の小さな書斎です。

私の性格上、広いと広いだけ物を置いてしまうので、仕事に集中しやすいよう強制的に物を増やせない広さとしています。実際収納はスリムなラック 2 つだけ (写っていませんが椅子の左側にもう 1 つある) で、そのラックに仕事で参照したい本、ガジェット類、重要な書類 (保険関連など) をまとめた書類入れを置いています。

確かに狭いは狭いのですが、仕事をするには十分な広さですし、快適です。

狭いながら、モニターの裏には景色を眺めつつ休憩するスペースもあります。配線整理の際にも裏側に回れると便利です。

まだ整理しきれてない部分もありますが、少しずつ進めております。

COFO Chair Premium

これについては、単独で記事を書いてます。

COFO Chair Premium を買った

ここ数年家で仕事をすることがほとんどであったにも関わらず、思い返してみるとあまり在宅ワーク環境に費用を掛けてきませんでした。 モニターは大学生の頃に買った 21.5 インチの安いやつだし、モニターアームも前職時代に職場用に買ったもの、机は実家から引っ越した時に買った IKEA の棚と一体化できるやつです。 KALLAX カラックス / LAGKAPTEN ラグカプテン デスクコンビネーション, ホワイト/ホワイトステインオーク調, 77x159x147 cm - IKEAKALLAX カラックス / LAGKAPTEN ラグカプテン デスクコンビネーション, ホワイト/ホワイトステインオー…

ゆるふわキャンパーLorentzca

その後も快適で、すっかり後継姿勢の楽さにハマってしまいました。腰が痛くなったりすることも無いですし良い感じです。

あえて気になる点を挙げるなら以下。

• キャスターの動きが重いのでもっと楽に動くと助かる。
• ヘッドレストの動きがもっとスムーズ (現状結構硬い)、かつ無段階になって欲しい。
• アームレストの高さの最低値をあと 5cm は低くしてほしい。私は腕が長めなのでまっすぐ肘を落とせない。
• アームレストの動きがもう少しスムーズかつ無段階になって欲しい。

アームレストについては自由度を追い求めるなら独立させた方が良さそうで、Ergorest が一番良さそうなのですが値段も一番高く、躊躇していますw

ERGOREST ONLINE STORE

数千円の同じような商品は Amazon 等の通販サイトで色々売られていますが、どれもクランプが下に突き出る形になるんですよね…。私の場合これだと絶対膝が干渉するので、使えません。あと配線いじりで天板下に潜り込んだ際に頭に刺さりそう。

もし Ergorest を導入した際には COFO Chair Premium からアームレストを取り外せば干渉せず使えそうです。

なお COFO Chair Premium で満足してますと言いつつハーマンミラーのエンボディチェアが最近気になっており、必死にチェア沼の深淵から目を逸らしております…。

FlexiSpot E7H

基本的に家で仕事をしているのですが以前からスタンディングデスクが気になっており、買いました。買ったのは去年の 9 月なので 4 ヶ月ほど経っていますが、良い感じです。

当時、以下を理由に購入を検討していました。

• 座りっぱなしだと疲れるので立って作業することに興味があった。
• 配線などやりやすそう。
• 掃除もしやすそう。

また、運よく会社のデスクが電動昇降デスクなので、事前に立って仕事をすることを試してみていました。自分に合わなくて結局立って仕事することが無い、となってしまったら残念なので…。

非常に気に入っており、買ってよかったです。

メリットとしては購入前に想定していた通りですが、以下を感じています。

• 座りっぱなしだとなんか疲れる (腰の痛みなどはないのですが、多分ずっと同じ姿勢でダルくなっている感じ) のですが立つとリフレッシュできる。
• 特に眠いときに立つと復活する。
• 配線いじりがめちゃくちゃ捗る。
• 掃除が非常にしやすい。
• キャスターもつけたところデスクを移動できて便利 (ただしデスクの最低高が数センチ高くなってしまうデメリットとトレードオフ)。

想定と違ったこととしては、家でしばらく立っていると会社で立っている時よりなぜか足が疲れました。踵に鈍い痛みも出てくるくらい。

恐らく会社は床がカーペット & 靴を履いているからでは？と思い調べるとどうやら同様の悩みを持った方はたくさんいるようで、評価の高かったウーフォスのリカバリーシューズ (やわらかサンダル) を買いました。

結果、足の痛みが解消したので、これからスタンディングデスクを検討される方はリカバリーシューズやスタンディングデスクマットも併せて検討した方が良いと思います。

ググると立ち作業は三日坊主で辞めちゃって結局ずっと座ってるから電動昇降デスクの意味なかった、みたいな話も散見されましたが、1 日 8 時間やら 10 時間やらデスク作業な人にはかなりいいんじゃないかな〜と思います。医学的なことはわかりませんが、少なくともずっと同じ姿勢でいるよりは体の負担が少ない気がしますし、長く集中できる感覚があります。

また、立つついでに軽く動きたい気持ちもあり、COFO LIFE バランスボードも導入しました。Makuake で応援購入したので定価よりだいぶ安く買えました。

バランスボードでゆらゆらしているとなかなか気分転換になります。

バランスボードはフットレストとしても使っています。私の場合デスクの高さとアームレストの高さを近くしたく、そうするとチェアを一番高くする必要があるのですが、その場合フットレストがあるとちょうど良いのです。座りながら足をゆらゆらできるのも良いです。

他の候補としてふみふみも検討していたのですが、ちょっと幅が狭く私の体格だと膝をすぼめて使うような形になると思われたため見送りました。ふみふみは COFO LIFE バランスボードを知る前から知っていたので、幅が広いタイプがあったらこちらを買っていたと思います。

その他の主な工夫色々は以下。

• コンセントから E7H への配線はケーブル 1 本 (そのうち LAN ケーブル含めた 2 本に)。
• 電源を天板裏に這わせた電源タップから取っているので、短いメガネケーブル (70cm) に変更。
• マグネットを使った配線でケーブルを垂れ下がらせずスッキリ這わす。
• マグネットのヘッドフォンスタンドやハンディワイパー入れを取り付け。
• PREDUCTS のトレイ取り付け (このトレイに MacBook を入れてクラムシェルモードで使ってる)。

E7H は足やビームが奥側にありかつパワーもあるので非常に良いです。足が当たらないし天板裏の有効面積も広いです。

ちなみに天板はセットではなく別で用意しており、木製 (杉) で 120cm x 70cm です。140cm 欲しかったのですが書斎の広さ的に断念。ただ私は広いと散らかすので 120cm が必要十分な気もしています。でも広い方が天板裏に色々配線やミニ PC や引き出しなどを仕込めるので羨ましさはありますね。

他、デスクの大本命としてはみんな大好き PREDUCTS のデスクがあったのですが、さすがのお値段なので今回は見送りました。そう、今回は… (そのうち天板だけ買うかもw)。

COFO Desk も良さそうだなと思ったのですが、天板下に PC 等重いものを取り付けたかったため、見送りました。COFO Desk は天板裏が金属板になっておりマグネットで色々取り付けられるのが特徴なのですが、流石にマグネットに PC をぶら下げるわけにはいかないのでそうすると金属板をぶち抜いてネジ穴を開ける必要があり、厳しい。全面金属板ではなく、ネジ穴も点在させるのはどうでしょう、COFO さん。あるいはビームの未使用ネジ穴をなんとか活用する、というのは現行品でもできるかな？

amesoba デスクシェルフ

机の上はどうしてもよく使う小物が散乱してしまいがちなので、それらをスッキリおさめるために amesoba のデスクシェルフを導入しました。

デスクシェルフといえばグローブメイド！…と思っていたのですが、なかなかのお値段、は納得できるとして、円安と送料でさらに天元突破してきたので断念しました…。

が、昨今の在宅ワーク流行りからのデスク環境改善ブームにより選択肢がどんどん増えてきました。Amazon を探索していたところ日本のブランドの amesoba が出しているデスクシェルフが目に入り、質感も良さそうで値段もハイエンドデスクシェルフに比べればだいぶ安いので、セール中にポチりました。

グローブメイドとの大きな違いとしては、中段の幅が半分なことです。中段の無いもう半分は高さが確保されていますので、中段があると入らないガジェットを収納したい人は amesoba デスクシェルフを選ぶメリットになります。

amesoba デスクシェルフを導入したことでペンやメモ帳、アロマディフューザー、バタフライボードや卓上カレンダー等をスッキリ収められて大変快適になりました。

amesoba のトレイも二つ購入し使っています。一つはデスクシェルフの中段、一つはその下に入れています。のりやハサミ、モニターアーム用のレンチ等の小物を収納しています。見た目もよくスッキリ収納できます。

カスタマイズしたこととして、天板裏にステンレスシートを貼り、マグネットで配線を這わせたり小物を設置できるようにしました。これのおかげで BALOLO のデスクシェルフのようにカッコよく iPhone を充電できるようになりました。

具体的には、ステンレスシートに MaGdget スタンドを付けて、MaGdget にはマグセーフ充電器を両面テープで貼り付けています。ケーブル抜き差しせず iPhone を好きな角度で充電でき、大変よろしいです。マグセーフ充電器への配線はもちろんステンレスシートに配線用マグネットを使用して綺麗に這わせています。

ただ、予算が許すならカスタマイズの極地としてはやはりみんな大好き PREDUCTS のデスクシェルフになるのかなと思います。

Dell U4924DW

49 インチ、解像度 5120 x 1440 のスーパーウルトラワイドモニターです。

10 年以上前に買った 21.5 インチのモニターをずっと使っていて、いいかげん大きいモニターが欲しかったので決断しました。今までは 21.5 インチのモニターと MacBook の 2 画面構成だったのですが、U4924DW 1 枚でそれらより遥かに広く、眩暈がするほど快適です。

Dell デジタル ハイエンド シリーズ 49 曲面 USB-C ハブ モニター - U4924DW | Dell 日本

IPSブラック パネル テクノロジーを採用したDellデジタル ハイエンド シリーズ49インチ デュアルQHDモニターです。曲面スクリーンであるほか、USB-Cハブを備えているため、簡単に接続できます。Dell.comで視聴

DellDell

候補として U4025QW と非常に悩みました。こちらは 40 インチですが解像度は 5120 x 2160 となっており、U4924DW より縦の解像度が高いのです。これは本当に迷った…。値段も U4924DW よりさらに高いですが U4924DW 買うならエイヤで手が届く範囲ですし…。

Dellデジタル ハイエンド シリーズ40インチ曲面Thunderbolt™ハブ モニター - U4025QW | Dell 日本

120Hzリフレッシュ レートの美しい5Kディスプレイを搭載したデジタル ハイエンド シリーズ40インチ曲面Thunderboltハブ モニター - U4025QWをぜひご購入ください。

DellDell

最終的に、会社のモニターの縦解像度が 1440 で U4924DW と同じであり、これに満足していたこと、インチ数に対して解像度が大きいと文字は小さくなり結局拡大して見ることになりそうで高解像度の情報量を享受できなそうなこと、ゲームもやりますが FF14 でありリフレッシュレート 120Hz も要らないことが判断材料となり U4924DW を選びました。

なおこの決断に至るまでに同僚の U4919DW (U4924DW の前モデル) 使いの方からいかに U4919DW が素晴らしいか熱弁いただいたことが強烈な後押しとなったことを申し添えておきます！w

画面のデカさに加え、U4924DW の推しポイントがドック機能です。ドックとしては CalDigit TS4 といった高性能ドック製品がありますが、そこまで端末から色々生やさない私としては U4924DW だけでドックとしても完結できる点が非常に良かったです。配線がかなりスッキリしました。

PIP や PBP で 2 台の端末と接続しモニター 2 枚のように使える点も便利だと思いますが、まだちゃんと使っていません。

カスタマイズ点として、まずは定番ですがモニターアームを使って浮かせています。U4924DW はとにかくでかいし重い (約 10kg) モニターなので、でか重モニター対応のアームでないと使えません。最初は定番のエルゴトロン HX を検討していたのですが、円安により値段が天元突破 (数年前のほぼ 2 倍…) していたので諦めました。

途方に暮れていたところたまたま快適ワークの LS112 を見つけました。でか重モニター対応で見た目も結構スタイリッシュ。

しかも当時セール中で 8250 円で買えました。僥倖ォ！！！

さらに、エルゴトロン HX と違い根本が垂直に上がっているタイプなので、デスクシェルフと干渉しません。エルゴトロン HX は超かっこいいのですが、根本から斜めに伸びているので、デスクシェルフを結構前に出さないと干渉してしまうのです。これは当初考慮できてなかったのですが、回避できて良かった… (エルゴトロン HX 買った後に気づいたら泣いてた)。

さらにさらに、LS112 はクランプが下に飛び出ない設計になっており、非常にスマート。クランプが飛び出てないおかげでケーブルトレーにも干渉せず、素晴らしいです。

が、その後 COFO 無重力モニターアーム Pro が発表されました。これ先に知ってたらこちらを買ってたかも。見た目も良いし機能性も良さそう。クランプも LS112 と同じく飛び出ない設計ですし。

ただセール中に買ったこともあり LS112 のコスパがぶっ飛んでいるので、後悔はしていない…！さらに、オプションの LS112 用ロングポールもポチりました。どうも自分の場合、モニターアームを高くして使うのが好みのようで、以前使っていたモニターアームも LS112 も、ちょっと高さが足りないシーンがあるんですよね (特に立って作業する際)、と思っていたらロングポールを発見しやはり LS112 は素晴らしい…！となったのでした。

次のカスタマイズとして、モニター裏の利便性向上です。世の中には VESA を拡張して便利に使っちゃおう！という概念があり、私はそんな変態的行為に興味はない、と思っていたのですが、大きいモニターを買ったことでめくるめく VESA ワールドに足を踏みれてしまいました…。

以下をポチりました。主な用途は、スピーカーと Web カメラの設置、いずれ買おうと検討している Mac mini の設置、その他配線整理等のためです。モニターとこれらを一体化させることでモニターを動かしまくっても配線等の干渉を気にしなくて良くなるのです。今はとりあえずスペーサーと VESA 規格増設プレートダブルだけ取り付けています。

• 長尾製作所 NBROS モニター 裏 凹凸用 VESA スペーサー 高さ15mm M4ネジ NB-VESA-SPACER-M4
• 長尾製作所 VESA規格増設プレート ダブル NB-VS7510PLUS-W
• イーサプライ サウンドバー マウントキット VESA取り付け 専用金具 スピーカーマウント テレビの上下 吊り下げ モニター設置 EEX-VESAIT03

ちなみに Mac mini はこういった VESA マウント対応のケースがあります。

• Fasgear 純アルミ金属 VESA マウント Mac-mini M4 2024、モニター マウント ブラケット デスク下用盗難防止機能付き、壁マウント VESA 互換 Mac-mini M4 Pro 2024(ブラック)

失敗談として、初めて高解像度モニターを買った人にはありがちなのかもしれませんが、個人用 PC から HDMI で繋いだら 5120 x 1440 の解像度が選択できず、あるぇ？となりました。その後調べて HDMI だと 5120 x 1440 ほどの高解像度には対応しておらず、DisplayPort を使えば良いということを知りました。DisplayPort くん、今まで「これ需要あるの？w HDMI で良くない？w」とか思っててすまん…！！

Keyball44

最後に、キーボード。

これまで Planck や Iris といった自作キーボードを愛用してきました。

Planck キーボードのキットを買った

追記: 組み立てました！ * キースイッチや半田付けグッズの購入編 * 組み立てと感想編 今年の初めくらいから自作キーボード界隈をじっと眺めていましたが、とうとう我慢できなくなって Planck を組み立てることにしました。 😭 * 突撃！隣のキーボード - Feedforce Developer Blog * 自作キーボードもくもく会を社内で開催しました - Feedforce Developer Blog * let’s split(レツプリ)を組み立てて自作キーボード沼に入った - はのちゃ爆発 Planck のパーツを注文するまでをまとめておきます(キーキ…

ゆるふわキャンパーLorentzca

Iris Keyboard の PCB を購入しました

現在 Planck という自作キーボードを使用しています。 * planck - ゆるふわキャンパー Planck は1年弱ほど仕事でもプライベートでも使っており、既に手に馴染み非常に良い感じなのですが、そろそろ分離型の自作キーボードに手を出してみます。(単に組み立ててみたいという気持ちもありますが)以下の理由からです。 * より疲労が少なそうな分離型を使ってみたい * Planck は半分お試しという目的があった * 40% キーボードが自分に合うか * 格子型のレイアウトが自分に合うか * はんだ付けする部分がキースイッチ(とオプショナルで LE…

ゆるふわキャンパーLorentzca

特に Iris は初めての分割キーボードで、肩の負荷が圧倒的に軽減され感動しました。

もうこれでゴールしていいよね…と思っていたのですが、恐ろしいことに知らぬ間にキーボード沼はより広く、深く、進化を遂げていたのです…。

YouTube で Keyball の存在を知り、気づいた時には Keyball44 のキットが家にありました。不思議なこともあるものですね。

Keyball39 にしなかった理由は、売り切れていたのと、いきなり Tab, Ctrl, Shift の列が消滅することに慣れる自信がちょっとなかったためです。Ctrl + A とか押したい場合どうすんの？と… (多分修飾キーは親指に集約するってことのかな)。

使い始めてから約 1 年経つのですが、もうこれゴールでしょ…という気持ちです。トラックボール自体初めてだったのですが、3 日くらいで慣れました。今までは Iris と Magic Trackpad でしたが、Keyball はキーボードとマウス/トラックパッド間の手の移動すらなくなり、尋常ならざる快適さです。

さらに Training&KBD さんの Keyball オプションパーツを買いまくり、至高のキーボードと化しました。

Keyball - BOOTH

3Dプリントによるキーボード関連商品を作製しております。

BOOTH

ダメ押しでキーケース底に緩衝マットを敷いたりキースイッチ部分に緩衝パッドを貼り付けて打鍵感を向上させたり、カメラ用の三脚やマグネット雲台を使用してテンティングさせています。

• Manfrotto ミニ三脚 POCKET L ブラック カメラ用 MP3-BK
• CFポッシュ(Cf Posh) インチサイズ ステンレスフランジ付ナット 1/4-20 4個入 866034
• UTEBIT 自由雲台 カメラ磁気スタンド 66MM マグネット雲台 360度回転可能 マグネット カメラスタンド 垂直耐荷重20kg カメラ 雲台 セット スマホクリップ ホットシュー付き カメラ用 マグネットスタンド アルミ合金 カメラ スタンド 強力 雲台マグネット

テンティング角度は 60 度くらいがちょうど良いです。テンティングで手首が楽になったのですが、デスクシェルフの下に入れることができなくなるのがデメリットです。書類作業の際にデスクマットごとサッとしまえないのがちょっと面倒。マグネットなので外すのは簡単ですが何度も繰り返すとちょっとだけ面倒。でも手首がかなり楽になるので総合的にテンティグは最高です。

あ、デスクマットで思い出したのですが、デスクマットは amesoba のウールデスクマット (30cm x 60cm) を使っています。…書いてて気づいたのですが私の環境、COFO と amesob にお世話になってますね。

入力デバイスが Keyball44 しかないので、ちょうど良いサイズです。が、FF14 をやる際はオンラインゲーム用マウスの G600 を使うので、その際は 30cm x 85cm サイズがちょうど良さそう。

また、マットを敷くことでテンティングさせずに Keyball を使う際、打鍵感が向上します。

…と悦に入っていたところ、またしても沼の深淵がこちらを覗いている事に気づいてしまいました。

そう、moNa2 です。

moNa2 - shakupan - BOOTH

moNaはkumakeyさん制作のroBaにインスパイアされ、pooh.poloさんとshakupanで作った小型分割キーボードです。 moNa : 左手トラボ版 moNa2 : 右手トラボ版 ・ZMK Firmware ・42キー ・ロープロファイル ・完全無線 ・17mmキーピッチ ・25mmトラックボール ・LEDインジゲータ ・背面マグネット ベアリングケースを使いたい場合は下記の商品がおすすめです。moNaで使うための追加部品をおまけでつけています。 https://kinoya.booth.pm/items/6064755

BOOTH

見た目は Keyball39 と似ていますが、なんと完全無線です。そしてキーピッチが狭くよりコンパクト。最初から背面に金属プレートが仕込まれており、上述のマグネットテンティングソリューションを使用できます。最初から組み立てられている点も楽ちんです。

想像通りかなりの人気で、再入荷後 10 秒で売り切れていきました。そのおかげで Keyball のように気づいたら家にあった、といった怪現象に遭わずに済んでいますが、それも時間の問題でしょう。

なぜなら既に moNa2 に合わせるキースイッチやキートップを検討し始めており (キースイッチは Lofree FLOW かな…)、私の右腕に封印されしポチりの荒ぶる力を抑えつけることはもはや出来ないからです。

デスクの写真

書斎の全体像でも写っていますが、デスク周りはこんな感じになってます。

モニター上部の Web カメラは Anker の PowerConf C200 です。モニターの縁に設置できるタイプですが、モニターが大きいゆえ縁も太く、無理やり引っ掛けてる状態です。のでなんとかしたいところ。

机上の右にある絵は子供が描いた絵です (写真に写ってるのは妻との合作)。たまに仕事中に絵を持ってくるので、そのまま飾っています。

普段は写真のように 3 ウインドウ (大抵ブラウザ + VS Code + 何か) を敷き詰めて使っています。モニターが横長なので 3 つ並べても十分な幅があり大変快適。Keyball のキーマップに Magnet のショートカットキーをいくつか割り当てており、適宜ウインドウを移動させながら使っています。

モニター裏 (VESA 拡張済み) はこんな感じです。配線を整えようと四苦八苦しています。ケーブルトレーは E7H に付属しているものを使っています。iMac がモニター裏に鎮座していますが、これももうだいぶ長いこと使っているので Mac mini に置き換え予定。Mac mini は VESA マウントか天板裏に固定する想定で、さらにデスク周りがスッキリする見込みです。iMac は妻にあげます。

まとめ

まだまだ改善の余地はあるものの、去年より遥かにデスク環境が向上しました！

今後も少しずつ盆栽を育てるようにデスク環境を育てていこうと思います。

Gmail にメールがたくさん溜まっているので多い順に削除すれば結構容量空くんじゃないか？と思い全メールアドレスを集計しようと思いました、が、Gmail にそのような機能 (受信数多い順に集計する等) はなかったので Gmail API で自前で集計してみました。

最初は Google Apps Script でやろうとしたのですが、スクリプトの実行時間 6 分という制限があり、数万件のメールを集計するのは不可能だったので、最終的には Python でスクリプトを作成しました。

Gmail API を使用する準備

事前に GCP にログインして、 Gmail API の有効化、OAuth 同意画面の作成、認証情報の作成を行う必要があります。

認証情報の作成時に credentials.json が取得できるのでこれを使用してトークンを取得し、トークンを使用して Gmail API を呼び出す、という流れになります。

この辺の流れは以下のクイックスタートを実行するだけです。

Python のクイックスタート | Gmail | Google for Developers

Google for Developers

Gmail メッセージを全部取得して集計するスクリプトを作成

要点は以下です。

• users().messages().list() を使用してメッセージのリスト (メッセージ ID 等) を取得
  💡 一度に最大で 500 メッセージまでしか取得できないので、next token から次のメッセージを取得していきますが、この時 list_next() を使用することで自分でページングを実装する手間が省けます
• メッセージ ID を元に users().messages().get() を使用してメッセージの詳細 (From メールアドレスやタイトル、本文等) を取得
• [{"<From メールアドレス>": <出現回数>}, ...] な配列と From メールアドレスを突き合わせて、合致する場合は <出現回数> をインクリメントしていく
• 配列を <出現回数> でソートして、トップ 10 など適当なところで出力

また、API を呼び出す部分はエラー時に再試行するようにしています。

retry という便利なライブラリがあるのでこれを使わせてもらっています。

再試行しないと、途中で処理が終わってしまい絶望します (数万件のメールの取得に数時間かかるので)。

コード全体は以下です。GItHub にも手順含め公開しています。

from google.auth.transport.requests import Request
from google.oauth2.credentials import Credentials
from googleapiclient.discovery import build
from googleapiclient.errors import HttpError
from collections import defaultdict
from retry import retry
import sys
import os
import re
SCOPES = [
    "https://www.googleapis.com/auth/gmail.readonly",
]
TOKEN_FILE_NAME = "token.json"
EMAIL_ADDRESS = sys.argv[0]

def creds():
    creds = None
    if os.path.exists("token.json"):
        creds = Credentials.from_authorized_user_file("token.json", SCOPES)
    if not creds or not creds.valid:
        if creds and creds.expired and creds.refresh_token:
            creds.refresh(Request())
        with open("token.json", 'w') as token:
            token.write(creds.to_json())
    return creds

def extract_email_addresses(text):
    match = re.search(r'<(.+?)>', text)
    if match:
        email = match.group(1)
        return email
    else:
        # マッチしない場合「"サンプル（EXAMPLE）" <info@example.com>」のような形式ではなく
        # info@example.com のようにアドレスのみの場合と判断。雑だけど。
        return text

def sort_email_counts(email_counts, top):
    print(f"\nTOP {top} は以下です。")
    sorded_email_counts_items = sorted(
        email_counts.items(), key=lambda x: x[1], reverse=True)
    for email, count in sorded_email_counts_items[:top]:
        print(f"{email}: {count}")

@retry(tries=3, delay=2)
def get_email_list(request):
    results = request.execute()
    return results

@retry(tries=3, delay=2)
def get_email_detail(service, message_id):
    txt = service.users().messages().get(
        userId='me', id=message_id).execute()
    return txt

def main():
    try:
        c = creds()
        service = build('gmail', 'v1', credentials=c)
        max_results = 500  # 最大 500
        email_counts = defaultdict(int)
        consumed_token = 0
        request = service.users().messages().list(
            userId='me', maxResults=max_results)
        while request is not None:
            results = get_email_list(request)
            consumed_token += max_results
            print(f"\n現時点で {consumed_token} 個のリストを取得しました。")
            messages = results.get('messages')
            for msg in messages:
                txt = get_email_detail(service, msg['id'])
                payload = txt['payload']
                headers = payload['headers']
                for d in headers:
                    if d['name'] == 'From':
                        sender = d['value']
                        sender_email_address = extract_email_addresses(sender)
                        email_counts[sender_email_address] += 1
                print("From: ", sender_email_address)
            # # 検証用に適当なところで切り上げるためのコード
            # if consumed_token > 19:
            #     break
            print("\n現時点の集計結果です。")
            sort_email_counts(email_counts, 10)
            request = service.users().messages().list_next(request, results)
        # 最終的にはトップ 50 を出す。
        sort_email_counts(email_counts, 50)
        return "end"
    except HttpError as error:
        print(f'An error occurred: {error}')

if __name__ == "__main__":
    main()

実行イメージ

以下のように集計したい Gmail アカウントのメールアドレスを指定して実行します。

• $ python main.py <Gmail アドレス>

実行イメージはこんな感じです。取得した From メールアドレスを逐一出力しながら進んでいきます。ページング毎に取得した From メールアドレスのその時点での集計結果上位 10 を出力しつつ、最終的に集計が完了したら上位 50 を出力します。

$ python main.py <Gmail アドレス>

現時点で 500 個のリストを取得しました。
From:  <メールアドレス色々>
From:  <メールアドレス色々>
From:  <メールアドレス色々>

...

現時点の集計結果です。

TOP 10 は以下です。
<メールアドレス色々>: <多い順にソートされた集計結果>
<メールアドレス色々>: <多い順にソートされた集計結果>
<メールアドレス色々>: <多い順にソートされた集計結果>

...

現時点で 33500 個のリストを取得しました。
From:  <メールアドレス色々>
From:  <メールアドレス色々>
From:  <メールアドレス色々>

...

現時点の集計結果です。

TOP 10 は以下です。
<メールアドレス色々>: <多い順にソートされた集計結果>
<メールアドレス色々>: <多い順にソートされた集計結果>
<メールアドレス色々>: <多い順にソートされた集計結果>

...

TOP 50 は以下です。
<メールアドレス色々>: <多い順にソートされた集計結果>
<メールアドレス色々>: <多い順にソートされた集計結果>
<メールアドレス色々>: <多い順にソートされた集計結果>
...

感想

実行から数時間かかりますが、上位 50 のランクをもとに多い順に削除を行ない、上位 5 くらいまでで数百 MB 空きが出来ました。 🎉

去年くらいに手動で頑張って削除して数 GB 空けたのですが、その時このスクリプトがあれば捗ったな…。

以前書いた通り、家族の LINE グループから ChatGPT を利用できるようにしています。

ChatGPT API を使って LINE ボットを作成した

少し前ですが ChatGPT API が公開されました。 以前から ChatGPT をいい感じに使いたいな〜と思っていて、ちょうど実家に帰った際に最近の AI は凄いぜ！的な話をしており、LINE の家族グループに「ボットくん」として参加させてみることを思い立ったというのがやってみた経緯です。 大まかな構成 使用する主要な各サービスは以下です。 * LINE Messaging API * API Gateway * Lambda * DynamoDB * ChatGPT API ざっくりとした図ではこんな感じ。 LINE の Messaging API を使用すること…

ゆるふわキャンパーLorentzca

今回、このボットに URL を渡すと内容を読んでくれる機能を追加しました。

なるべく課金しない方法を探す

ChatGPT は URL へアクセスすることはできませんが、ChatGPT Plus に課金することでプラグインを使えるようになり、URL へアクセスするプラグインを入れることでコンテンツを取得することが可能になります。

ただ月額 $20 とそれなりにするので、無料でできる方法を探してみます (もっと使用頻度増えたら課金したいと思っている)。

考えた方法

要はアクセス先のコンテンツを ChatGPT に渡せられれば良いので、ChatGPT へメッセージを送る前に URL 先のコンテンツを取得して、ペイロードに含めれば良さそうです。

こんな流れなイメージ。

1. URL を含むメッセージを LINE から受け取る。
2. URL を抽出してアクセスし、コンテンツを取得。
3. ChatGPT へ送るメッセージにコンテンツを追加する。
4. ChatGPT へメッセージを送信。

例えば、以下のメッセージが LINE から送られてくるとします。

ボットくん
以下の記事を要約して。
https://blog.lorentzca.me/creating-a-line-bot-using-the-chatgpt-api/

なるべく短く要約して。

URL が含まれているのでコンテンツを取得し、最終的に ChatGPT へ送られるメッセージは以下のようになります。

ボットくん
以下の記事を要約して。
https://blog.lorentzca.me/creating-a-line-bot-using-the-chatgpt-api/

なるべく短く要約して。
以下はこの URL の内容です。
少し前ですが ChatGPT API が公開されました。

以前から ChatGPT をいい感じに使いたいな〜と思っていて、ちょうど実家に帰った際に最近の AI は凄いぜ！的な話をしており、LINE の家族グループに「ボットくん」として参加させてみることを思い立ったというのがやってみた経緯です。

大まかな構成

…

「以下はこの URL の内容です。」からが追加したメッセージです。普通に URL を渡すだけだと「URL へはアクセスできません」的なことを言われるので、「以下はこの URL の内容です。」と枕詞を置くことで自然な流れでコンテンツを渡そうという魂胆です。

実装

まず URL を含んでいるかを判定します。含まれていなければそのまま処理を継続し、含まれている場合は URL を抽出してコンテンツを取得します。mssage はLINE から送られてきたメッセージが入っています。

    # URL 有無の判定。
    if 'http://' in message or 'https://' in message:
        print('URL が含まれています。')
        # url 部分のみを抽出。
        urls = get_website_contents.extract_urls(message)

get_website_contents.extract_urls() の実装は以下です。URLExtract というまんまなライブラリがあるので使わせてもらっています。cache_dir='/tmp' 部分は重要です。URLExtract はキャッシュ用のディレクトリを作成しようとしますが、Lambda 関数で動作させる場合、パーミッションのエラーが発生します。キャッシュディレクトリに関数で利用可能な /tmp ディレクトリを指定することで回避できます。

def extract_urls(message):
    extractor = URLExtract(cache_dir='/tmp')
    urls = extractor.find_urls(message)
    return urls

URL を抽出したら、コンテンツを取得して message に追加します。URL が一つの場合のみ処理を行うようにしています。複数 URL 渡して ChatGPT に比較してもらう、というように使うのも面白そうですがまずは単純な状態で試したいので。なので if len(urls) == 1 の条件を入れて urls[0] で一つだけ取り出して渡しています。

    if 'http://' in message or 'https://' in message:
        print('URL が含まれています。')
        urls = get_website_contents.extract_urls(message)

        # URL が一つの場合は、コンテンツを取得して message に追加。
        if len(urls) == 1:
            contents = get_website_contents.get_website_contents(urls[0])
            message = f"""{message}
以下はこの URL の内容です。
{contents}"""

get_website_contents.get_website_contents() の実装は以下です。

def get_website_contents(url):
    response = requests.get(url)
    if response.status_code == 200:
        soup = BeautifulSoup(response.content, 'html.parser')
        body_content = soup.body
        if body_content:
            return body_content.get_text()
        else:
            return 'コンテンツがありませんでした。'
    else:
        return f'コンテンツの取得に失敗しました。ステータスコードは {response.status_code} です。'

URL が複数ある場合は注意を返答して会話を終わらせています。

    if 'http://' in message or 'https://' in message:
        print('URL が含まれています。')
        urls = get_website_contents.extract_urls(message)

        if len(urls) == 1:
            contents = get_website_contents.get_website_contents(urls[0])
            message = f"""{message}
以下はこの URL の内容です。
{contents}"""

　　　　　　　# URL が一つ以外の場合は注意を返答する。
        else:
            line_api.reply_message_for_line(
                reply_token, '会話に含める URL は一つのみ記載してください。')

            return {
                'statusCode': 200,
                'body': json.dumps({'message': 'success'})
            }

早速動かしてみます。

動作イメージ

良い感じに動作しました！ 🎉

エラーの場合は以下のようなメッセージを送ることになるのでどうなるかな〜と思っていましたが、予想以上にいい感じに解釈して伝えてくれていますね…！ 🙏

ボットくん
以下の記事を要約して。
https://sp.m.jiji.com/english/show/hogehoge
以下はこの URL の内容です。
コンテンツの取得に失敗しました。ステータスコードは 404 です。

賢い！

感想

思ったよりあっさり実現できた。だいたい何を送りつけてもいい感じにやってくれる (ように見えるだけの場合もありますが) ChatGPT, 生成系 AI は本当に驚きますねぇ…。

URL を渡すのはボットくんを作成してからずっとやろうと思っていたことでしたので、これでより家族 LINE が使いやすくなると良いな〜。

我が家には Amazon Echo が 4 台あり、主に家電の操作と音楽の再生、天気予報の確認、Amazon で注文した荷物の確認に使用しています。

あと地味に便利なのがタイマー機能で、「ラーメンタイマー 3 分開始して」「卵タイマー 9 分開始して」のように並行して複数のタイマーに名前をつけて使用できるので、料理のお供に使用しています。

それ以外だとたまーに「今日は何の日？」みたいに暇つぶしで呼びかけるくらい。でもあまり自由な会話はできないのですぐ飽きちゃうんですよね…。いや十分便利なのでいいんですが…。

そこで、以前 LINE 経由で使えるチャットボットを作成した時と同じように、Echo でも使えたら便利かもしれないと思い、やってみました。

ChatGPT API を使って LINE ボットを作成した

少し前ですが ChatGPT API が公開されました。 以前から ChatGPT をいい感じに使いたいな〜と思っていて、ちょうど実家に帰った際に最近の AI は凄いぜ！的な話をしており、LINE の家族グループに「ボットくん」として参加させてみることを思い立ったというのがやってみた経緯です。 大まかな構成 使用する主要な各サービスは以下です。 * LINE Messaging API * API Gateway * Lambda * DynamoDB * ChatGPT API ざっくりとした図ではこんな感じ。 LINE の Messaging API を使用すること…

ゆるふわキャンパーLorentzca

動作イメージ

こんな感じで使えます。Alexa スキルは実行 (Lambda 関数の実行) が 8 秒でタイムアウトしてしまうので、8 秒経つ前にその時点での ChatGPT の返答を送っちゃうようにしています。会話の履歴は Alexa スキルのセッション機能で保持しているので、続きを依頼すれば続きをしゃべってくれます。

苦労した点

色々苦労したので書いていきます。

requirements.txt が動作しない

公式ドキュメントを読むと、Alexa-hosted スキル (自分の AWS アカウントの Lambda 関数等を使わず、Alexa サービス側のリソースを使う方法) の場合、Python を選択した場合は requirements.txt に必要な追加のパッケージを書いておけばデプロイ時にインストールされ使える、と書いてあります。

Python — requirements.txtファイルのdependenciesセクションに依存関係を追加します。例：
boto3==1.9.216

[依存関係の追加](https://developer.amazon.com/ja-JP/docs/alexa/hosted-skills/alexa-hosted-skills-create.html#dependencies)

しかし、この方法は現在動作していません。

いろいろ試しましたが、ログを見るとどうやっても [ERROR] Runtime.ImportModuleError: Unable to import module 'lambda_function': No module named 'openai' Traceback (most recent call last): となります。

ググるとどうやら少なくとも 2023 年の 2 月 ~ 7 月はできていたっぽいんですよね…。

• https://qiita.com/saeki4n/items/599e5af2a280325c3225

よくわからん。

ということで自分で依存パッケージも含めたコードをデプロイして解決しました。

が、ここでも注意点があって…。

コンソールからの ZIP ファイルのアップロードが不便

一応 Alexa スキルのコンソールから ZIP ファイルをアップロードできるのですが、なぜかアップロード後、デプロイしたいファイルを選択する必要があり、しかも 100 ファイルまでという制限があります。普通の Lambda 関数みたいに丸ごとアップロードしたものを使って欲しい…。

このため、たとえば openai パッケージは数百、もしかしたら数千くらいのファイルがあり、これを 100 ファイルずつ毎回 ZIP アップロードし直すところからやっていくのは正直現実的ではありません。苦行です。

この問題はコンソールからアップロードするのではなく、ASK (Alexa Skills Kit) CLI を使用して CLI からデプロイを行うことで解決できます。

• https://developer.amazon.com/ja-JP/docs/alexa/smapi/quick-start-alexa-skills-kit-command-line-interface.html
• https://github.com/alexa/ask-cli

ASK CLI を使用したインポートができない

ASK CLI には便利なインポート機能があり、既存のスキル ID を指定するとインポートしてくれます。めっちゃ便利じゃん！このオプションを見つけたときはそう思いました。

• https://developer.amazon.com/ja-JP/docs/alexa/smapi/ask-cli-command-reference.html#init-command

が、これがうまくいかない。実行すると 500 エラーになってしまう。--debug オプションをつけて実行すると、どうやらコードをインポートするエンドポイントへのアクセスが 500 エラーになっている模様。

不思議なことに他のスキルはインポートでき、何が問題だったのか不明。強いていえば他のスキルは Node.js でエラーになったものは Python という違いくらい。

面倒になったのでインポートするのではなく、新規作成してコードはコンソールからスキルをエクスポートして手で移植しました。

なお、ASK CLI を使用したスキルのデプロイ方法などは以下に書いてあります。

• https://developer.amazon.com/ja-JP/docs/alexa/hosted-skills/alexa-hosted-skills-ask-cli.html

openai パッケージバージョンの互換性

昔 (と言っても最近ですが…) の知識をもとに openai パッケージを使用するとうまく動かず、どうやら v1 から仕様が変わったようです。

丁寧な移行ガイドがあったのでこの問題についてはあんまり困らずに済みました。

• https://github.com/openai/openai-python/discussions/742

Alexa スキルの 8 秒問題

8 秒コードを実行できれば十分そうですが、ChatGPT のレスポンスが思ったより遅く、簡単な挨拶のような会話以外はほぼ全てタイムアウトしてしまう…。

何か良い方法はないものかとググったところ、 openai にはストリーミングモードというのがあって、まとめて回答を得るのではなく、回答が断片的にストリーミングで送られてくるというモードを使用し、8 秒経つ前にその時点での回答を送る、といった方法を考えられている方がいました。

Alexaスキル用のチャットボットを8秒以内に応答させたい

ZennTAKAHASHI Taro

これを参考にさせていただき、同じような実装をして解決。

ストリーミングモードのリファレンスの通り、 for 文でチャンクから断片的なメッセージを取り出し繋げていく感じで使用します。

• https://platform.openai.com/docs/api-reference/streaming

for 文開始前とブロック中で都度時間の差分を計算し 8 秒近くなったらその時点までで組み立てた文を返す実装です。

def chatgpt(message, start_time):
    # Get message from ChatGPT.
    try:
        completion = client.chat.completions.create(
            model="gpt-3.5-turbo",
            messages=message,
            stream=True
        )

        connected_message = ''
        for chunk in completion:
            elapsed_time = time.time() - start_time
            finish_reason = chunk.choices[0].finish_reason
            if finish_reason != 'stop':
                connected_message += chunk.choices[0].delta.content
            if elapsed_time > 7.5:
                connected_message += '。すみません、タイムアウトしました。続きを聞きたい場合は「続きを教えて」のように話しかけてください。'
                break

        return connected_message

    except Exception as e:
        logger.error(f"OpenAI API request failed: {e}")
        return "すみません、エラーが発生しました。しばらく時間をおいてからもう一度お試しください。"

Alexa スキルには会話毎にセッションがあり、セッションに会話を都度保存することで、文脈を保ったまま ChatGPT とやりとりできます。

• https://developer.amazon.com/ja-JP/docs/alexa/custom-skills/manage-skill-session-and-session-attributes.html

上記のブログではこのセッションも使用しておりこの部分も参考にさせていただきました。

class input_anyIntentHandler(AbstractRequestHandler):
    def can_handle(self, handler_input):
        return ask_utils.is_intent_name("input_any")(handler_input)

    def handle(self, handler_input):
        start_time = time.time()

        # セッションに既存のメッセージがある場合はそれを chatgptMessageBuilder() に渡す
        print(handler_input.attributes_manager.session_attributes)
        if 'MESSAGES' in handler_input.attributes_manager.session_attributes:
            session_messages = handler_input.attributes_manager.session_attributes["MESSAGES"]
        else:
            session_messages = None

        user_input = ask_utils.get_slot_value(
            handler_input=handler_input, slot_name="any")

        messages = chatgptMessageBuilder(user_input, session_messages)

        chatgpt_response = chatgpt(messages, start_time)

        # ChatGPT の回答をメッセージに追加
        messages.append({
            "role": "assistant",
            "content": chatgpt_response
        })

        # セッションにこれまでのメッセージを保存
        handler_input.attributes_manager.session_attributes["MESSAGES"] = messages

        directive = ElicitSlotDirective(
            slot_to_elicit='any',
            updated_intent=Intent(
                name="input_any",
                confirmation_status=IntentConfirmationStatus.NONE,
                slots={
                    "any": Slot(name="any", value="", confirmation_status=SlotConfirmationStatus.NONE)
                }
            )
        )

        speak_output = chatgpt_response

        return (
            handler_input.response_builder
            .speak(speak_output)
            .ask("他に何かお手伝いできることはありますか？")
            .response
        )

どんな発話も受け取るインテント

基本的に、Alexa スキルはある程度決まった流れに沿って会話します。例えば天気予報スキルなら予報を聞いたりある地域の天気を聞いたりと言った風に、会話の流れがある程度決まっています。

この会話の雛形のようなものがインテントです。

インテント内には変数としてスロットが設定できます。例えば「今日の天気予報は？」の「今日」の部分は変数 (「明日」が入るかもしれないし、「週末」かもしれない) なのでこれをスロットとして設定する感じです。

上のようにある程度決まった目的をもとに会話するのが Alexa スキル作りの定石なので、ChatGPT を呼び出して後は自由に会話する、のような使い方は多分あまり想定されてないです。

ではどのようにユーザーからの自由な発話を受け取るようにするかというと、いろいろ調べている方がいて自分はカスタムスロットを使っています。

• https://note.com/torusnote/n/n77896a394177

他にも方法はある模様。

• https://qiita.com/y_fujisawa/items/b443bd6c3667d8aa8443

その後…

この記事の下書きを書いてからしばらく経っているのですが、API の応答がよくわかりませんが早くなり、8 秒問題がほぼ発生しなくなりました。ナンデ…？ (API の従量課金を有効にしたから…？)

あと地味に AI モデルを gpt-4o に変更するなどしています。

completion = client.chat.completions.create(
    model="gpt-4o",
    messages=message,
    stream=True
)

感想

自由な会話ができるので、なかなか面白いです。8 秒問題回避のために 200 文字を目安に応答するよう指示しているので、テンポよく対話でき暇つぶしになりますw

def chatgptMessageBuilder(user_input, session_messages):
    template = """あなたは音声対話型チャットボットです。以下の制約にしたがって回答してください。
    制約:
    - ユーザーのメッセージに句読点を補ってから回答します
    - 200 文字以内を目安に簡潔な短い文章で話します"""

コード

最後に、参考にした記事のものを流用している感じですが、コード全体は以下のようになります。

# -*- coding: utf-8 -*-

import logging
import time
from openai import OpenAI

import ask_sdk_core.utils as ask_utils
from ask_sdk_core.skill_builder import SkillBuilder
from ask_sdk_core.dispatch_components import AbstractRequestHandler
from ask_sdk_core.dispatch_components import AbstractExceptionHandler
from ask_sdk_core.handler_input import HandlerInput
from ask_sdk_model.dialog import ElicitSlotDirective
from ask_sdk_model import (
    Response, Intent, IntentConfirmationStatus, Slot, SlotConfirmationStatus)

logger = logging.getLogger(__name__)
logger.setLevel(logging.INFO)

CHATGPT_API_KEY = '<ChatGPT の API キー>'

client = OpenAI(
    api_key=CHATGPT_API_KEY,
)


def chatgpt(message, start_time):
    # Get message from ChatGPT.
    try:
        completion = client.chat.completions.create(
            model="gpt-4o",
            messages=message,
            stream=True
        )

        connected_message = ''
        for chunk in completion:
            elapsed_time = time.time() - start_time
            finish_reason = chunk.choices[0].finish_reason
            if finish_reason != 'stop':
                connected_message += chunk.choices[0].delta.content
            if elapsed_time > 7.5:
                connected_message += '。すみません、タイムアウトしました。続きを聞きたい場合は「続きを教えて」のように話しかけてください。'
                break

        return connected_message

    except Exception as e:
        logger.error(f"OpenAI API request failed: {e}")
        return "すみません、エラーが発生しました。しばらく時間をおいてからもう一度お試しください。"


# ユーザーからの発話と既存の対話を元にメッセージを作成
def chatgptMessageBuilder(user_input, session_messages):
    template = """あなたは音声対話型チャットボットです。以下の制約にしたがって回答してください。
    制約:
    - ユーザーのメッセージに句読点を補ってから回答します
    - 200 文字以内を目安に簡潔な短い文章で話します"""

    if session_messages:
        messages = session_messages
    else:
        messages = [{
            "role": "system",
            "content": template
        }]

    messages.append({
        "role": "user",
        "content": user_input
    })

    return messages


class LaunchRequestHandler(AbstractRequestHandler):
    """Handler for Skill Launch."""

    def can_handle(self, handler_input):
        return ask_utils.is_request_type("LaunchRequest")(handler_input)

    def handle(self, handler_input):
        speak_output = "こんにちわ！私はボットくんです。何かお手伝いできることはありますか？"

        return (
            handler_input.response_builder
            .speak(speak_output)
            .ask(speak_output)
            .response
        )


class input_anyIntentHandler(AbstractRequestHandler):
    def can_handle(self, handler_input):
        return ask_utils.is_intent_name("input_any")(handler_input)

    def handle(self, handler_input):
        start_time = time.time()

        # セッションに既存のメッセージがある場合はそれを chatgptMessageBuilder() に渡す
        print(handler_input.attributes_manager.session_attributes)
        if 'MESSAGES' in handler_input.attributes_manager.session_attributes:
            session_messages = handler_input.attributes_manager.session_attributes["MESSAGES"]
        else:
            session_messages = None

        user_input = ask_utils.get_slot_value(
            handler_input=handler_input, slot_name="any")

        messages = chatgptMessageBuilder(user_input, session_messages)

        chatgpt_response = chatgpt(messages, start_time)

        # ChatGPT の回答をメッセージに追加
        messages.append({
            "role": "assistant",
            "content": chatgpt_response
        })

        # セッションにこれまでのメッセージを保存
        handler_input.attributes_manager.session_attributes["MESSAGES"] = messages

        directive = ElicitSlotDirective(
            slot_to_elicit='any',
            updated_intent=Intent(
                name="input_any",
                confirmation_status=IntentConfirmationStatus.NONE,
                slots={
                    "any": Slot(name="any", value="", confirmation_status=SlotConfirmationStatus.NONE)
                }
            )
        )

        speak_output = chatgpt_response

        return (
            handler_input.response_builder
            .speak(speak_output)
            .ask("他に何かお手伝いできることはありますか？")
            .response
        )


# これ以降はほぼデフォルト
class HelpIntentHandler(AbstractRequestHandler):
    """Handler for Help Intent."""

    def can_handle(self, handler_input):
        # type: (HandlerInput) -> bool
        return ask_utils.is_intent_name("AMAZON.HelpIntent")(handler_input)

    def handle(self, handler_input):
        # type: (HandlerInput) -> Response
        speak_output = "You can say hello to me! How can I help?"

        return (
            handler_input.response_builder
            .speak(speak_output)
            .ask(speak_output)
            .response
        )


class CancelOrStopIntentHandler(AbstractRequestHandler):
    """Single handler for Cancel and Stop Intent."""

    def can_handle(self, handler_input):
        # type: (HandlerInput) -> bool
        return (ask_utils.is_intent_name("AMAZON.CancelIntent")(handler_input) or
                ask_utils.is_intent_name("AMAZON.StopIntent")(handler_input))

    def handle(self, handler_input):
        # type: (HandlerInput) -> Response
        speak_output = "Goodbye!"

        return (
            handler_input.response_builder
            .speak(speak_output)
            .response
        )


class FallbackIntentHandler(AbstractRequestHandler):
    """Single handler for Fallback Intent."""

    def can_handle(self, handler_input):
        # type: (HandlerInput) -> bool
        return ask_utils.is_intent_name("AMAZON.FallbackIntent")(handler_input)

    def handle(self, handler_input):
        # type: (HandlerInput) -> Response
        logger.info("In FallbackIntentHandler")
        speech = "Hmm, I'm not sure. You can say Hello or Help. What would you like to do?"
        reprompt = "I didn't catch that. What can I help you with?"

        return handler_input.response_builder.speak(speech).ask(reprompt).response


class SessionEndedRequestHandler(AbstractRequestHandler):
    """Handler for Session End."""

    def can_handle(self, handler_input):
        # type: (HandlerInput) -> bool
        return ask_utils.is_request_type("SessionEndedRequest")(handler_input)

    def handle(self, handler_input):
        # type: (HandlerInput) -> Response

        # Any cleanup logic goes here.

        return handler_input.response_builder.response


class IntentReflectorHandler(AbstractRequestHandler):
    """The intent reflector is used for interaction model testing and debugging.
    It will simply repeat the intent the user said. You can create custom handlers
    for your intents by defining them above, then also adding them to the request
    handler chain below.
    """

    def can_handle(self, handler_input):
        # type: (HandlerInput) -> bool
        return ask_utils.is_request_type("IntentRequest")(handler_input)

    def handle(self, handler_input):
        # type: (HandlerInput) -> Response
        intent_name = ask_utils.get_intent_name(handler_input)
        speak_output = "You just triggered " + intent_name + "."

        return (
            handler_input.response_builder
            .speak(speak_output)
            # .ask("add a reprompt if you want to keep the session open for the user to respond")
            .response
        )


class CatchAllExceptionHandler(AbstractExceptionHandler):
    """Generic error handling to capture any syntax or routing errors. If you receive an error
    stating the request handler chain is not found, you have not implemented a handler for
    the intent being invoked or included it in the skill builder below.
    """

    def can_handle(self, handler_input, exception):
        # type: (HandlerInput, Exception) -> bool
        return True

    def handle(self, handler_input, exception):
        # type: (HandlerInput, Exception) -> Response
        logger.error(exception, exc_info=True)

        speak_output = "Sorry, I had trouble doing what you asked. Please try again."

        return (
            handler_input.response_builder
            .speak(speak_output)
            .ask(speak_output)
            .response
        )

# The SkillBuilder object acts as the entry point for your skill, routing all request and response
# payloads to the handlers above. Make sure any new handlers or interceptors you've
# defined are included below. The order matters - they're processed top to bottom.


sb = SkillBuilder()

sb.add_request_handler(LaunchRequestHandler())
# 追加したインテントハンドラー (input_anyIntentHandler()) を追記するのを忘れずに
sb.add_request_handler(input_anyIntentHandler())
sb.add_request_handler(HelpIntentHandler())
sb.add_request_handler(CancelOrStopIntentHandler())
sb.add_request_handler(FallbackIntentHandler())
sb.add_request_handler(SessionEndedRequestHandler())
# make sure IntentReflectorHandler is last so it doesn't override your custom intent handlers
sb.add_request_handler(IntentReflectorHandler())

sb.add_exception_handler(CatchAllExceptionHandler())

lambda_handler = sb.lambda_handler()

子供が生まれてから、土日に自分や妻の実家へ泊まりで出かけることが多いです。そんな小旅行に非常に使いやすいバックパックとして ULA の Dragonfly を愛用しています。

Robic Dragonfly

The ULA Robic Dragonfly is a pack that will take you flying through your travels! Designed with a quick weekend getaway in mind, this front-loading

ULA EquipmentStephen Boyd

このバックパックをとても気に入っていて、以下の動画の紹介がわかりやすいので貼っておきます。

この Dragonfly はウエストベルトは付属していないのですが、後からつけられるようにループが付いています。今回はこの Dragonfly にウエストベルトを自作してみたという話です。

が、タイトルの通り、ちょっとしたギミックのあるウエストベルトにしてみます。

RawLow Mountain Works の Nuts Pack

Nuts Pack はウエストバッグ (ファニーパックと呼ぶのがヤングの間でナウイっぽい) あるいはボディバッグとして使える小型のポーチです。

Nuts Pack - RawLow Mountain Works

わずか80gの軽量Funny Pack(ウエストバッグ）の完成です。素材はULギアでは昔からの定番インビスタ社CODURA silnylon 30Dを使用。サコッシュタイプでは大きすぎてブラブラして気になる方やクライミングセ

RawLow Mountain Works

私はハイキングや旅行時はもちろん、普段もちょっとコンビニや子供と散歩に行く際はサコッシュやボディバッグを使用します。Nuts Pack もそんなアクティビティや日常生活で使用しています。

この Nuts Pack はバンジーコードが付いていたり色々機能的なポーチなのですが、一つ面白いギミックとして、こんな感じで同 RawLow Mountain Works の Beetle というバックパックと連結できます。

これ、同じバックルを手に入れれば Beetle 以外のバックパックとも連結できるのでは…！？

バックルを調べる

バックルは製品によって微妙に形が違うので、単に大きさが同じというだけでは互換性がありません。

最初探すのに苦労したのですが (色々ググっても分からず…)、改めて Nuts Pack をよくみたらバックルに型番のような文字列が書いてありました！

型番的文字列は LB20LVD と書いてあり、これでググると YKK の製品であることがわかりました。

LB-LVD | YKK㈱ ジャパンカンパニー

従来のバックルと同等の強度を維持しつつ（当社比）、軽量化を実現したバックルです。両端にアジャスター機能を持たせたタイプです。

YKK㈱ ジャパンカンパニー

以下のサイトから買いました。

YKK　バックル　LB20LVD　両引きタイプ　黒　1個 | トーキョービニール powered by BASE

YKK プラスチックパーツバックル 両引きタイプⅤ字形になっているので、差し込みが楽です。品番 ：LB20LVD テープの幅：20mm 用色 ：黒単位 ：1個サイズ：A 21ｍｍB 26ｍｍC 50ｍｍD 8ｍｍ入荷に時間がかかる場合がありますので、お待たせすることがございます。お急ぎの場合は、事前にお問合せください。送料：この商品のみのご注文でしたら、9個まで送料220円でお送りします。 お急ぎの場合は佐川急便をお選びください

トーキョービニール

その他必要な道具

バックルが手に入ったので、あとはこのバックルが対応している 20mm のテープと、バックパックのループに取り付けるためのスリッククリップを買いました。

• https://www.amazon.co.jp/dp/B0795C2LX5
• https://www.yamatomichi.com/products/slik-clip

テープの終端処理として折り返して縫う必要がありますが (でないとバックルから抜ける)、普通の縫い針ではテープが固くて厳しそうですし、糸も普通の糸では心許ないです。ということで、以前帆布を縫う時に買った、レザークラフト用のスピードステッチャーと蝋引き糸を使います。

• https://www.amazon.co.jp/gp/product/B003MAACPS

作っていく

テープの長さは余裕めに左右それぞれ 70cm で作成しました。

折り目の長さを合わせてクリップで仮止めして、ステッチャーで縫っていきます。ステッチャーの使い方は以下のサイトがわかりやすいです。サイト内の動画で、縫い糸の終端処理方法も紹介されてます。

• https://repmart.jp/products/ro1125.html

一度使い方がわかれば、簡単に縫っていけます。

注意点は以下。

• 長い分には調整が効くので、テープはだいぶ余裕を持って切っておく。
• テープを折りたたんだ側が内側 (身体側) に来るようにするとちょっと見栄えが良い。
• バックルを通してから縫わないとバックルを通せなくなるので注意。

こんな感じで出来上がりました。Dragonfly に装着！

ウエストベルトとして使うと、ブレがかなり抑えられるので急いで移動する時などに快適になります。

Nuts Pack との連携もバッチリです！長めの距離を歩く際は Nuts Pack と連携するとかなり良さげです。軽食やスマホやモバイルバッテリー、ハンカチやティッシュ、サングラスなんかをすぐ取り出せて快適に移動できます。Nuts Pack は小さいので未使用時はそのままバックパックに入れれば良いです。

ウエストベルトが邪魔なときは…

本題とは逸れますが、私は通常時はウエストベルトをしない派なので、ぶらぶらしていると邪魔です。かといってスリッククリップをつけ外しするのも面倒です。

そこで、こんな製品があり、余分なベルトをいい感じに束ねられるので愛用しています。いっぱい入っているのでウエストベルト付きのバックパックは全部これを装着しています。

• https://www.amazon.co.jp/gp/product/B016CTJW1K

感想

ちょっとだけ手間がかかりますが、Nuts Pack を持っている人にはかなりおすすめなカスタマイズです。カスタマイズすると愛着も湧きますし楽しい！

Dragonfly のようにウエストベルトを後付けできるようなタイプのバックパックを複数所有しているなら、スリッククリップをつけ外しすることで使いまわせるので、一つ作っておくと非常に便利。

例えば山と道の MINI2 もスリッククリップでウエストベルトを装着するタイプなので、MINI2 も Nuts Pack と合体できるようになります。良い。

これから暖かくなり使う機会が増えると思うので、楽しみです！ ✨

ここ数年家で仕事をすることがほとんどであったにも関わらず、思い返してみるとあまり在宅ワーク環境に費用を掛けてきませんでした。

モニターは大学生の頃に買った 21.5 インチの安いやつだし、モニターアームも前職時代に職場用に買ったもの、机は実家から引っ越した時に買った IKEA の棚と一体化できるやつです。

KALLAX カラックス / LAGKAPTEN ラグカプテン デスクコンビネーション, ホワイト/ホワイトステインオーク調, 77x159x147 cm - IKEA

KALLAX カラックス / LAGKAPTEN ラグカプテン デスクコンビネーション, ホワイト/ホワイトステインオーク調, 77x159x147 cm

IKEAIKEA

椅子に至っては実家から引っ越してからしばらくは IKEA のダイニングテーブル付属の椅子を使っていました。

JOKKMOKK ヨックモック テーブル＆チェア4脚, アンティークステイン - IKEA

JOKKMOKK ヨックモック テーブル＆チェア4脚, アンティークステイン. シンプルで丈夫なダイニングセットは、軽く食事をするコーナーやこじんまりとしたダイニングにぴったり。パイン無垢材は長く使うほどに味わいが出て、テーブルでの家族の食事や行事に辛抱強く付き合ってくれることでしょう.

IKEAIKEA

その後キャスターが無くて椅子が動かせないのが面倒という理由で、適当な安いオフィスチェアを買って現在まで使っていました (19,550 円。オフィスチェアとしては安物と見做される価格帯っぽい)。

Amazon.co.jp: RayGoo オフィスチェア デスクチェア オットマン付き ハイバック 170度 リクライニング メッシュ コンパクト 可動式アームレスト 通気性 椅子 腰サポート クッション 360度回転 可動式枕 日本語説明書が付き : 文房具・オフィス用品

Amazon.co.jp: RayGoo オフィスチェア デスクチェア オットマン付き ハイバック 170度 リクライニング メッシュ コンパクト 可動式アームレスト 通気性 椅子 腰サポート クッション 360度回転 可動式枕 日本語説明書が付き : 文房具・オフィス用品

ブランド RayGoo

この椅子が最近バキバキ音が鳴るようになってきて若干不穏 (以前椅子のシリンダーが破裂する事故についてのニュースを見たことがあったので…) な雰囲気なので、これを機にちょっとしっかり目のオフィスチェアを買ってみようと思い立ちました。

要件

書き出してみるとこんな感じ。

• 少し休憩する際やリラックスしたい時にリクライニングやオットマン (フットレスト) はなんだかんだ使っていたので、リクライニングとオットマン、ヘッドレストがあるものが良い。
• どちらかというと前傾姿勢より後傾姿勢で作業することが多い。
• 自分の場合腰は長時間座っていても全然痛くならないので、腰のサポート (ランバーサポート) はそこまで高機能でなくても良い。
• アームレストはある程度自由度が欲しい (机と同じ高さにして腕を置いてキーボードを打つ派なので)。
• 蒸れるのが嫌なので背面はメッシュで。今回は座面もメッシュにしてみたい。
• 上述のように特に現状椅子に座ることによる腰痛などの不調はないので、そこまで高機能、高級なもの (有名なオカムラやハーマンミラーとか…) でなくても良い。
• 予算としては現状のものより良いものを買いたいので 4 万円 ~ 10 万円は超えたくない、くらい。

特にアームレストについては現状の安い椅子で唯一強めに不満を持っていたので、この条件はマスト！

候補

イトーキやオフィスコムなど色々探してみましたが、最終的にオフィスチェア界では新規参入となる COFO の COFO Chair シリーズか RASICAL の GrowSpica シリーズで迷い、値段も機能も近いので決定打は見た目の好みということで、COFO Chair Premium を選びました。

特に背面が COFO Chair Premium はイカしてると思いました。ネジ穴が一切見えないデザインになっていてスマート。

定価は 99,800 円ですが公式サイトから購入すると今は 79,800 円で、さらにいろんなインフルエンサーに 5,000 円 OFF のクーポンコードを配布しているようで、実質 75,800 円で買えます。私も YouTube 等でいろいろレビューを見させてもらったのでクーポンコードも使わせてもらいました。

GrowSpica の方はランバーサポートが上下だけでなく前後にも調節できて、背中を椅子から離した姿勢にしても腰のサポートは受け続けられるという COFO Chair Premium には無い機能があり、この辺も本当にどちらにするか最後まで悩みポイントでした。

一つのレバーでリクライニングや座面の昇降、前後調整を行えるのも GrowSpica の特徴ですが、自分の場合そんなに頻繁に各部を調整しないので不要と判断しました。いや、ロマン的な面ではこういうギミックかなり好きですがね…w

組み立て

これも方々で言われている通り、COFO Chair Premium はユーザー体験が作り込まれていてテンションが上がりますね。

特にこのレンチは一般的によく梱包されている L 字型のレンチと違って使い勝手が良いので今後も使い回したくなります。

感想

比較対象の以前の椅子が 2 万円以下の安い椅子だったこともあり、座り心地や機能性は申し分なく良いです。パーツ間の遊びも無く静粛性が高いのも地味ですが良いなと感じました (まともな椅子ならそれが当たり前なのかもしれませんが…)。

以前の椅子は座面がかなり広く、背面に背中をつけると膝裏に座面の端が当たる (そして血の巡りが悪くなりそのうち脚が痺れてくる) くらいだったので椅子の背面に背中を付けて座ることがリクライニングで休憩するとき以外ほぼ無く、作業中もしっかりと背中を付けて座れるのが新鮮に感じます。

マストだったアームレストの調節機能も良いです。👌

COFO Chair Premium はアームレストの角度調整幅が小さくてアームレストに肘を置いたままキーボードを打つことが難しい、みたいなレビューも見かけましたが、自分の場合左右分割キーボードを使っているので、この点も全く問題なし。

背面にジャケットハンガーがあるのもありがたいです。というのも、特に冬は大抵の場合部屋着として T シャツの上にフリースなどの防寒具を羽織っており、これをよく椅子の背面に掛けていたので。

ハンガーと一緒に小物フックもありますが、これはどう使うか悩み中。主にバッグを掛けることを想定しているようですが、自分の場合出社時に使うバッグはノート PC 以外の入れっぱなし道具だけでそれなりに重さがあり、掛けっぱなしにすると伸びてしまったり変な癖が付きそうで…。ちょっとした外出の際にはサコッシュやボディバッグを持っていくので、それらを掛けておくのがちょうど良さそうですかね。あるいは折り畳み傘をぶら下げておくとか。

座面をメッシュにした感想としては、お尻の冷えが思ったよりあります。以前の椅子は背面はメッシュで座面はクッションだったのですが、お尻の冷えを感じることはありませんでした。冷えがきつい場合は別途クッションを引く等の工夫が必要そうです。逆に夏はかなり快適になりそう！

今のセッティングとしては軽くリクライニングさせてオットマンを座面にベタ付け状態で展開し、足を軽く投げ出すような後傾姿勢で使ってみています。冬は寒い時はダウンソックスを履いているのですが、この足を投げ出す姿勢だと床への接地が無く、ダウンの潰れによる保温機能の低下がないので暖かいですね。思わぬメリット。ヘッドレストも調節して、後頭部と首の間に添えるくらいの状態にしてあります。ランバーサポートの位置はちょうど良い位置を探し中です。これ、位置が悪いとすぐ腰が痛くなりそうなので位置探しは重要そう。

まだ届いたばかりで長期的に使用した際の身体への負荷等は未知数ですが、元々どのような椅子でも困ったことがないので、自分の鈍い身体にとってはオーバースペックかもしれません…w

久しぶりに在宅ワーク環境を改善できたので嬉しい。✨

長く使っていければと思います。

Amazon プライムデーだぜ！ということで SwitchBot の温湿度計を買いました。

https://www.amazon.co.jp/gp/product/B07L4QNZVF

とりあえず仕事部屋に置いているのですが、いい感じです。寝室用にも欲しい。買い足そうかな…。

ただ置くだけでも温湿度が見れて便利なのですが、スマートホーム的な観点でメトリクスをとっていきたい。一年を通した記録を見ることで除湿・加湿器を買う際のスペックの参考にもなりそうですし、体調との関連性とかも見れたら面白そう。特に妻は頭痛持ちなので何か法則とか見出せたら役立ちそう (おそらく気圧が主な影響ぽいですが)。

構成

主な構成は以下です。

• Amazon EventBridge Scheduler
• AWS Lambda
• SwitchBot API v1.1
• Mackerel サービスメトリック

図だと以下。

EventBridge Scheduler で定期的に Lambda 関数を実行し、Lambda 関数で SwitchBot の API を呼び出し、取得した結果を Mackerel に送信する流れです。

今回、言語は JavaScript を使用しています。

デプロイは AWS SAM で行っています。

SwitchBot API について

去年 v1.1 が公開されていました。

【API】新バージョンAPI v1.1を公開しました - SwitchBot Magazine | スマートホームで暮らしをシンプルに

目次新バージョンについてSwitchBotAPIについて手引き：現在取得済みのデバイス一覧：注意事項詳細はこちらGitHub上で新バージョンAPI v1.1を公開！APIによるロックの解施錠を操作可能になりました。 ht […]

SwitchBot Magazine | スマートホームで暮らしをシンプルにSwitchBot

大きな変更として、今までは Authorization ヘッダーにトークンを指定するだけで API の認証を行っていましたが、v1.1 からはトークンとシークレット、タイムスタンプとナンス (使い捨ての値) を使用して一意の署名を作成する方法になりました。

署名の作成方法はいくつかの言語毎にサンプルコードが公開されておりほぼそのまま使えます。

GitHub - OpenWonderLabs/SwitchBotAPI: SwitchBot Open API Documents

SwitchBot Open API Documents. Contribute to OpenWonderLabs/SwitchBotAPI development by creating an account on GitHub.

GitHubOpenWonderLabs

まず curl コマンドで検証してみます。Python のサンプルコードを使用して署名を作成します。リクエストに必要な各情報が出力されます。

$ python3 sigh.py
Authorization: xxxx
t: 1111111111111
sign: yyyy
nonce: zzzz

これを使って curl コマンドでリクエストを送信します。デバイスの一覧を取得してみます。

$ curl \
-H "Authorization: xxxx" \
-H "sign: yyyy" \
-H "t: 1111111111111" \
-H "nonce: zzzz" \
https://api.switch-bot.com/v1.1/devices

上のコマンドでデバイスの一覧が取得でき、各デバイスのデバイス ID が取得できます。デバイス個別の情報はこのデバイス ID を使用して取得できます。

$ curl \
-H "Authorization: xxxx" \
-H "sign: yyyy" \
-H "t: 1111111111111" \
-H "nonce: zzzz" \
https://api.switch-bot.com/v1.1/devices/<デバイス ID>/status

今回の場合、温湿度計から情報を取得したいです。各デバイスの持つ情報は以下にまとめられています。

GitHub - OpenWonderLabs/SwitchBotAPI: SwitchBot Open API Documents

SwitchBot Open API Documents. Contribute to OpenWonderLabs/SwitchBotAPI development by creating an account on GitHub.

GitHubOpenWonderLabs

温湿度計の場合、以下ですね

GitHub - OpenWonderLabs/SwitchBotAPI: SwitchBot Open API Documents

SwitchBot Open API Documents. Contribute to OpenWonderLabs/SwitchBotAPI development by creating an account on GitHub.

GitHubOpenWonderLabs

temperature が温度、humidity が湿度です。

署名の取得はこんな感じで書いてます。ほぼサンプルの通りです。ナンスに UUID を使用してます。

const signToSwichbot = async (token, secret) => {
  const t = Date.now();
  const nonce = crypto.randomUUID();
  const data = token + t + nonce;
  const signTerm = crypto
    .createHmac("sha256", secret)
    .update(Buffer.from(data, "utf-8"))
    .digest();
  const sign = signTerm.toString("base64");
  return { sign: sign, t: t, nonce: nonce };
};

温湿度情報の取得はこんな感じ。

const getTempHum = async (switchbot_endpoint, switch_bot_token, sign) => {
  const res = await axios.get(switchbot_endpoint, {
    headers: {
      Authorization: switch_bot_token,
      sign: sign.sign,
      t: sign.t,
      nonce: sign.nonce,
    },
  });
  return res.data.body;
};

実装の雑な部分は許して…。

Mackerel サービスメトリックについて

自分の場合、こんな感じでサービスメトリックを使用してスマートホームのメトリクスを集約しています。SmartHome というサービスの配下に、スマートホーム関連の各メトリックを集約しています。

回線速度を Mackerel x Greengrass x Raspberry Pi で監視する

最近気持ちが忙しくてブログ更新久しぶりな気がする。。タイトルの通りネットワーク回線の速度を監視し始めたのでメモ。 モチベーション SNS の方で呟いてましたが引越しすることになりました。 引っ越すからベッド分解した´д` ; — †深淵の覚醒者† (@lorentzca) July 5, 2020 我々インターネットで生活している者たちにとって引越しで一番気になるのは回線の速度ですよね。次のおうちでも光回線が通っているのはもちろん確認済みなのですが、速度や安定性が気になるところです。 そこで回線速度を監視し、引越し後どれくらいの違いが出るか確認することにしました。結果は…

ゆるふわキャンパーLorentzca

今回、メトリック名の設計は以下のようにしてみます。

• homeoffice.temphum.temperature: 仕事部屋の温度
• homeoffice.temphum.humidity: 仕事部屋の湿度
• homeoffice.temphum.battery: 仕事部屋の温湿度計のバッテリー残量

Mackerel へ送信するコードはこんな感じ。

const sendTempHumToMackerel = async (
  temp_hum,
  mackerel_endpoint,
  mackerel_api_key
) => {
  const date = new Date();
  const sec = Math.floor(date.getTime() / 1000);
  const res = await axios.post(
    mackerel_endpoint,
    [
      {
        name: "homeoffice.temphum.temperature",
        time: sec,
        value: Number(temp_hum.temperature),
      },
      {
        name: "homeoffice.temphum.humidity",
        time: sec,
        value: Number(temp_hum.humidity),
      },
      {
        name: "homeoffice.temphum.battery",
        time: sec,
        value: Number(temp_hum.battery),
      },
    ],
    {
      headers: { "X-Api-Key": mackerel_api_key },
    }
  );
  console.log(res);
};

作成されたグラフ

順調に記録されていっていますね。🎉

バッテリーと湿度についてはパーセント表記にしたいですが、メトリックの単位はサービスメトリック単位で設定可能で、メトリック名個別の単位では設定できないので、とりあえず整数として設定してます。まあわかるとは思いますが、メモの部分に単位の説明書いておこうかな。

感想

全体を通して特に特別なことはしておらず、公式のサンプル等ほぼそのままで出来ました。今後は寝室等にも設置して、bedroom.temphum.* といった形で記録していければと思います。その際は今回作成した関数を使用し、コードもちょっと整理していい感じに使いまわせるようにしていければ！

しかしスマートデバイス、めっちゃ手軽になりましたね。Raspberry Pi で何かする気分にならないくらい… (良い感じの使い道考えないと…)。

少し前ですが ChatGPT API が公開されました。

以前から ChatGPT をいい感じに使いたいな〜と思っていて、ちょうど実家に帰った際に最近の AI は凄いぜ！的な話をしており、LINE の家族グループに「ボットくん」として参加させてみることを思い立ったというのがやってみた経緯です。

大まかな構成

使用する主要な各サービスは以下です。

• LINE Messaging API
• API Gateway
• Lambda
• DynamoDB
• ChatGPT API

ざっくりとした図ではこんな感じ。

LINE の Messaging API を使用することでユーザーとボットの双方向のやり取りが可能になります。Messaging API は Webhook を有効化することで、ユーザーが友だち追加したりメッセージを送信した際、指定した URL に対してイベントを送信できます。

今回は API Gateway の HTTP API で作成した API のエンドポイントが Webhook に指定する URL となります。

HTTP API で作成した API は統合先に Lambda 関数を設定してあり、この Lambda 関数で LINE から受け取ったメッセージを ChatGPT に送信したり、ChatGPT から受け取ったメッセージを LINE に返すなどしています。

DynamoDB は LINE から送られてきたユーザーのメッセージ、ChatGPT から返ってきたメッセージを逐一保存しています。以下の属性名で管理しています。

• id: UUID で生成した一意の値。
• content: LINE, ChatGPT から受け取ったメッセージ。
• createdAt: メッセージを受け取った日時。
• lineUserId: メッセージを送信した LINE ユーザーの ID。
• role: user, assistant のいずれかが入る (後述します)。

role について。ChatGPT API にメッセージを送信する際、メッセージに role (役割) を含める必要があります。role は user, assistant, system の 3 種類がありそれぞれ以下を意味します。

• user: ChatGPT にメッセージを送る人。大抵の場合人間。
• assistant: ChatGPT の中の人。つまり AI。
• system: assistant の動作を設定するのに使われる。例えば「あなたは絵文字を多用するおじさんです」のような内容を指定すればおじさん構文で返すようになる、みたいなイメージw

今回の場合特に system ロールは使わないので、user と assistant のみ DynamoDB に保管されるようにしています。

で、なぜ DynamoDB にいちいちメッセージを保管しているかというと、文脈を維持した会話を行いたいからです。ChatGPT では過去のやりとりを含めてメッセージを送信することで、文脈を維持した会話 (しりとり等) が可能になっています。

以下の例で user と assistant のやりとりをまとめて送信している部分がそれです。

import openai

openai.ChatCompletion.create(
  model="gpt-3.5-turbo",
  messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "Who won the world series in 2020?"},
        {"role": "assistant", "content": "The Los Angeles Dodgers won the World Series in 2020."},
        {"role": "user", "content": "Where was it played?"}
    ]
)

つまり、DynamoDB から過去何件か分の会話を取得し、最新の会話と一緒に送ることで文脈を維持した会話が可能になっています。全ての会話を取得するのは現実的でない (ChatGPT はトークンと呼ばれる、テキストデータを分割する最小単位ベースで課金があり、毎回全やりとり送っていたら破産するw) ので、今のところ 5 件分取得して送っています。

…ということはしりとりで 2 ターン半経過したら、それより前の単語は再び使えるようになってしまうんですかね？w

ちなみに API Gateway 等のバックエンドの各リソースは SAM で管理しています。Lambda 関数で使用する言語は Python を使用しています。

ボットを作っていく中でいくつか工夫、というほどのものではないかもですが、考えたものは以下です。

工夫した点

「ボットくん」と言う文字列が入っていないと反応しないようにした

グループに入れると全てのメッセージに反応してしまうので非常に鬱陶しく、「ボットくん」という文字列が入っていない場合は反応しないようにしてみました。単純にメッセージ中に「ボットくん」という文字列が入っていなければ return して終了するだけですが重要な機能です。

if 'ボットくん' not in message:
    print('「ボットくん」という文字列が含まれていないため終了。')
    return

文脈を維持するようにした

既に書いた通り、DynamoDB に会話の履歴を残すようにしており、最新の会話から数件分を取得しそれを ChatGPT へのメッセージに含めることで文脈を維持した会話が可能になりました。

また、DynamoDB からメッセージを取得する際、送信元の LINE ユーザー ID (lineUserId) でフィルタし取得しているので、例えばグループ内で複数のユーザーから同時に使用された場合も文脈が混ざっておかしなことにならないようにしています。

今書いてて思ったのですが、グループ ID も保存するようにすればさらに厳密に文脈維持できそうですね。例えば複数のグループで使用したとして、ユーザー ID でだけフィルタしていると、あるユーザーがグループで使用した際の文脈を別のグループでの会話に引き継いでしまうので。

LINE の署名検証

API Gateway で HTTP API を作成し LINE からの Webhook を受け取るインターフェースを作成することは既に書いた通りですが、そのままでは LINE 以外からのリクエストも受け付けてしまいます。それはよろしくないので LINE 以外からのメッセージは処理しないようにしたいです。

すぐ思いつくのは IP アドレス制限ですが、LINE のドキュメントを見ると、LINE プラットフォームで使用される IP アドレスは公開していないとのことです。

代わりの方法として、LINE から送られてくるリクエストに含まれる x-line-signature ヘッダーの署名を検証する方法が案内されています。

• 署名を検証する

署名の検証のサンプルコードも案内されており親切。以下は Python の例。

import base64
import hashlib
import hmac

channel_secret = '...' # Channel secret string
body = '...' # Request body string
hash = hmac.new(channel_secret.encode('utf-8'),
    body.encode('utf-8'), hashlib.sha256).digest()
signature = base64.b64encode(hash)
# Compare x-line-signature request header and the signature

この署名の検証を Lambda 関数で行えば LINE 以外から送られたメッセージの場合終了するように出来ます。

意図しないユーザー、グループから使われた場合通知

LINE の Messaging API には、プライベート向けに閉じるような機能がありません。つまり、誰でも友だち追加が可能です。身内でしか使っていないので、無いとは思いますが、念の為、意図しないユーザーやグループから使われた場合は LINE に通知メッセージを送信するようにしてみました。

Webhook から送られるイベントにはユーザー ID やグループ ID が含まれています。なのであらかじめユーザー ID やグループ ID をリストしておき、そこに含まれない ID から送られてきた場合には通知を送信する形で実現しています。通知は LINE Notify を使用して LINE に送っています。

なお、事前にユーザー ID やグループ ID を取得する方法は無いので、使用予定のユーザーやグループから実際に送信してみてログなどから確認する必要があります。

エラーが発生した場合はエラーを送信する

ChatGPT 使用時に何らかのエラーが発生した場合、LINE ユーザーから見ると単に時間がかかっているのか、エラーで停止しているのか判断できません。そこでエラーが発生した場合はエラーを返すようにしました。

早速家族グループに入れてみた

普段使っている LINE グループでそのまま使えるので、私の父や母の世代でも違和感なく使えておりボットくんとして親しまれております。😊

ChatGPT 面白いですねぇ。最近 ChatGPT が Plugin 対応したので、より便利に使うべく試してみようかなと思ってます。とりあえず提示した URL を読んでくれるようにしたい。けどこれサイトによってはスクレイピングに該当したりするのかな。そしたら微妙かも。とにかく、夢がひろがりんぐ✨でありますな。

課題

上で挙げたように LINE の署名を検証したり、「ボットくん」という文字列が入っていないメッセージは処理しないようにしたり、意図しないユーザーやグループからの使用を検知するようにしたり、これって本当は HTTP API の Lambda オーソライザーでやれたら綺麗だなと思うんです、が、Lambda オーソライザーはヘッダーやクエリ文字列は受け取れるもののボディは受け取れないんですよね。なので断念。ちなみに REST API でも同じくボディは渡せない。

あと上でもちらっと書きましたが現在 DynamoDB から過去のメッセージを取得する際に LINE のユーザー ID でフィルタしていますがグループ ID も使うことでより厳密な文脈の維持ができそう。

最近 SAYAMA works の Ω Tote 2G を購入しました。

これはトートバッグにもバックパックにもなり、またポケッタブルなので本体のポケットを裏返す形で、本体ごと納めることができます。つまり収納袋なしでコンパクトに持ち運べる形に変態できるということです。

他にもバックパック用のショルダーベルトが取り外し自由だったり、サイドのメッシュを絞るゴムがペットボトルを固定するためのループと兼用されていたり、細かい部分がよく考えられていて非常に使い勝手が良いです。詳細は Ω Tote 2G のページを見てね！！ギミックの説明は見るだけで面白い…。

自分の場合、主に子供と出かける際や近所へのピクニック、ちょっと買い出しに行く際に使用しています。外側のメッシュポケットに、使うシーンの多い子供用の携帯便座や飲み物、予備の着替えや上着など、子供関連のものを雑に放りこめて便利。いずれはサイクリングやキャンプ時のサブのバッグとして持っていったり、電車での釣行に使ったりする予定。

特に釣りは移動時はバックパック、釣り中はトートとして使える (ボックスやプライヤーなどの小道具をすぐ取り出せる) のでかなり良いのではなかろうか…。

自分用にカスタマイズしていく

非常に使い勝手の良い Ω Tote 2G ですが、しばらく使ってみた結果、さらに自分の用途に合わせて使いやすくするため以下が必要と感じました。

• バックパックモードの際、背面パッドが欲しい。特に買い出しの際、背中がゴツゴツして気になる。
• バックパックモードの際、チェストベルトが欲しい。ある程度の距離を歩くと、ショルダーベルトが滑ってくるのが気になる。

やっていきましょう。

背面パッドを作る

背面パッドの素材として、山ざぶとんを使用します。ざぶとんなのでクッション性もありますし、山用なので軽量です。また、出先で実際にざぶとんとして使うこともできて応用性があります。

山ざぶとんは以下の安いものを加工して使います。

• https://amzn.asia/d/gD3ImEk

Ω Tote 2G にはノートパソコン等を入れるためのポケットが背中側に用意されているので、ここに入れるのが良さそうです。山ざぶとんを切ってサイズを合わせます。

縦 25cm x 横 26.5cm の大きさにカットすると、ピッタリ収まります。

ペラい山ざぶとんを使ったパッドですが、あるのとないのではかなり違います。安価ですしおすすめ。

チェストベルトを付ける

チェストベルトは、それ単体で売ってます。今回は以下を使用しました。安い。

• https://amzn.asia/d/ff5KCHi

以下のように、留め具に切れ込みがあり、ここにショルダーベルトを通すことができます。付け外し自由で便利な仕組みです。

この製品にはサングラスなどを掛けることのできる D カンがついており、これも以下のようにニッパーで切れ込みを入れれば取り外し自由になり、より便利に使えます。

また、ベルトがかなり長いので、自分の場合バックルのメス側のベルトはほとんど切ってしまい、オス側のベルトだけで調整するようにしています。切り口をライターで炙れば、ほつれ防止になります。自分の持っている他のバックパックもそのような形態 (右端にメス側) なので、使い慣れた形に合わせたい意味もあります。

今回は採用しませんでしたが、その他のアイデアとして、バックルをホイッスルや方位磁針付きのものに入れ替えるとよりアウトドアみが増して楽しそうです。

以下とかホイッスル、方位磁針、温度計、マルチツール、メタルマッチ付きのバックルでしかも安いのでかなりロマンがありますね…方位磁針と温度計の精度は安物なのであてにできなそうですが…w

• https://amzn.asia/d/1I2uGmM

完成

より自分用に最適化された Ω Tote 2G になりました！

ガンガン使っていこうと思います。✨

恐面 (カイメン) という今は亡きインディーズのトップウォータールアーブランドがあり、昔から気になっていました。

先日その恐面のルアーをたまたまセカンドストリートで発見し、しかも値引きされていたので購入…！(ヤフオクにも一件あるのですが、ちょっと高い。)

恐面のルアーは上のように朝日をモチーフにしたカラーや、夜空や夕焼けといったカラーがあり大変良いです。風流！動きも良いみたいです (まだ投げに行けてない…)。

恐面との出会い

2002 年、自分が中学生の頃、バス釣り専門雑誌「バスワールド」で水面遊戯という連載がありました。これはその名の通り水面に浮くルアーしか使わない人たち、通称「トッパー」を取材する連載でした。

バスワールドを毎号買っていたわけではなかったので、自分が読んだ水面遊戯は 11 回目 (最終回) のみ。この回では埼玉県で「スクリーム」というトップウォーター専門店を営んでいた菊池良男さんの回で、いくつかピックアップされていた氏のおすすめルアーの中に恐面のルアー「バッズ」がありました。全部魅力的なルアーですが、明け方の空のような柄の「バッズ」が特に気になっていた記憶があります。これが恐面との出会い。

2000 年代初頭はトップウォーターのインディーズブランドが群雄割拠状態で、トップウォーターバブルのような状態だったようです (だったようです、というのは自分は当時からバス釣りをしていたもののこの手のハンドメイドルアーは数千円するので興味はあったが買えず、あまり詳しく調べることもなかったため)。

2023 年現在、この頃生まれた多くのインディーズのトップウォーターブランドはもう無くなっていると思います…。

ちなみにスクリームも今は無く、現在は接骨院になっているようです。雑誌の写真と見比べると、外壁や看板周辺に面影がありますね。兵どもが夢の跡。

スクリームのサイトも閉鎖済ですが、Wayback Machine からある程度見ることができます。スクリームオリジナルのバンブーロッドも制作されていたんですねぇ。オークションとかに流れてないかな…。

• www.scream.co.jp - 12 Apr 2005

恐面を追う (現代編)

恐面、現在ではググっても全然情報が出てこない…。一番情報量が多いのは恐面のルアーについていくつかレビューされている、以下の記事か。星空のような美しいカラーを塗ることもあれば、少々…いやだいぶ…お下品なおふざけカラーも塗られていた模様。

くまのつりぐ

The bear’s fishing tackle

くまのつりぐ

他には、現在も更新されているサイトの古い記事の中に、恐面のビルダーである高橋さんとの釣行日記がありました。2002 年の記事。これによるとどうやら少なくとも 2002 年時点では、恐面のルアーはスクリームにしか卸していなかった模様。

TOPBOKAN�@TB���|�[�g

しばらくすると上流方面からボッコム＆恐面艇が下ってきた。なんと恐面高橋さんが１本出した。ルアーを見せてもらうとなんとまぁスゲエきれいだ。埼玉のスクリームさんにしかないのが残念だ（確か入荷即完売してたような）。

ちなみに上記引用中のボッコムは現在も現役でルアーを制作されている！

その他は、オークションサイトで恐面のルアーがごく少数出品されていたり、中古釣具屋の入荷情報の中に恐面のルアーが含まれていたりする程度。

ということで 2023 年現在においては恐面がどういったブランドなのか、何種類のルアーをリリースされていたのか、等の情報は全くと言っていいほど無い状況…。

恐面を追う (過去編)

今ググっても見つからないなら、過去に行けばいいじゃない！ということで、恐面のサイトが当時なかったのか探してみます。現在見つかる情報からは恐面のサイトの URL などは見つからず。

そこで、上に挙げた Wayback Machine でアーカイブされているスクリームのサイトを開いて、サイト内に恐面のサイトか何かが無いか探してみます。当時であれば、自分の手作りサイトに「リンク集ページ」を作り、知り合いのサイトと「相互リンク」することが定番であった (インターネット老人会ネタだ…) ので、ある可能性は高い…。

果たして、ありました。この感じめっちゃ懐かしいですねw

• www.scream.co.jp/link.html - 5 Apr 2005

リンク集から辿った恐面のサイトは以下！もちろん現在は閉鎖済なので Wayback Machine からでないと見れません。

• www5f.biglobe.ne.jp/~kaimen/kaimen_001.htm - 5 Apr 2005

とりあえず目立つ位置にあった「皆様にお知らせとお詫び」を開いてみると不穏なお知らせが。行方不明…！？ですが文面がふざけているのでおそらく本人のジョークでしょう…。その後サイトのデザインも変わってますし。ただこの辺りの時期からもう制作活動をやめてしまったのかな〜。

より新しい (スナップショットの新しい) 恐面のサイトは以下。Wayback Machine は時期を指定して見れるので、閉鎖前の一番新しい状態のサイトを見てみることにします。

• www5f.biglobe.ne.jp/~kaimen/kaimen_001.htm - 2 May 2006

2006 年 5 月 (私が高校一年生の頃…) までは少なくとも存在していたようですね。サイトを見ていくと日記的なものが中心のサイトだったのかな。見ていくとルアーの情報もちらほらある感じ。

これとか。エンマというルアーの紹介ページ。これはオークション履歴の画像で見たことあるな。エンマっていう名前だったのか。

• www5f.biglobe.ne.jp/~kaimen/kaimen_004.htm - 29 Aug 2005

これは仏舎利の紹介ページ。3 作目とのことなので、1 作目がバッズ、2 作目がデカイメン、かな？

• www5f.biglobe.ne.jp/~kaimen/kaimen_004.htm - 12 Oct 2003

カラー一覧のページ。画像が半分くらい消えてしまっているのが残念。夜明けや夕焼けといったモチーフのカラーが美しいですね。それだけに他のおふざけカラーとの落差がすごい…。自分の購入した仏舎利のカラーもありますね。このページ、これより後の期間のページには無いんですよね。なんで消しちゃったんだろう。更新が大変だった？

• www5f.biglobe.ne.jp/~kaimen/gazou.html - 29 Apr 2004

コラム中から抜粋。ロッドもあったんですね！

• www5f.biglobe.ne.jp/~kaimen/kaimen_003.htm - 07 Dec 2004

あ、忘れてた
スクリームさんの４周年記念に恐面ロッドを作りました
名前は「卒塔婆」と書いてストューパと読みます
お墓にある「塔婆・トバ」とも言いますね
サンスクリット語の当て字らしいです
「バッズ＝マリファナの花穂の意」
「デカイメン＝あ、これはただデカかったからか・・・」
「仏舎利＝釈迦の遺骨」
「７（セブンス）ヘブン＝巷で有名なド○ッグ」←そのうち出します
何だか排他的と言うか、アンダーグラウンドて言うか・・・

恐らく、セブンスヘブンは結局リリースされて無いんじゃないかな…？もしくはエンマという名前で出したのがこれ？

ということで一通りサイト内や各時期のサイトも見てみましたが、制作されたルアーの一覧といった、情報が一箇所にまとまったページは無いみたいですね。情報が散らばっていて探すのがきつい。コラムがいっぱい書いてあるのでそれは面白かったのですが、各ルアーに対する詳細があまりなかったのがちょっと残念。あと、サイトの時期を変えるたびコンテンツの内容や位置が変わりまくっていて、試行錯誤の跡が見て取れました…。

翻って、再度スクリームのサイトも覗いてみよう。

上述の雑誌に載っていた、「バッズ」の入荷情報発見。ハンドメイドルアーで 3800 円て、現在のインディーズのトップウォーターブランドからは考えられない低価格ですね…。

• www.scream.co.jp/shinntyaku.html - 01 Oct 2002

お、卒塔婆の入荷情報発見。恐面特有の、山と空を描いたロッド。欲しい。

• www.scream.co.jp/shinntyaku.html - 07 Apr 2004

上記リンク内に、今回私がセカンドストリートで購入した仏舎利のカラーの情報もありました！エイプリルフールの洒落カラー「オークションカラー」だそうです。

恐面まとめ

ビルダーは高橋誠司氏。実際にリリースされたルアーは恐らく 4 種類。

• バッズ (ペンシルベイト)
• デカイメン (ペンシルベイト)
• 仏舎利 (ペンシルベイト)
• セブンスヘブン 恐らくリリースされなかったか、エンマとしてリリースされたのか
• エンマ (スイッシャー)

ロッドも制作されていた。スクリームにしか製品を卸していなかったらしい。

富士山や夕焼けといった景色が好き (ルアーのカラーもそうだし、コラムにもそう書いてあった)。

ということで一部ですがルアーの思想なども知れてよかった。個人的にはデカイメンの詳細読みたかったな。お尻の金属プレートの意味とか…。見つからなかったけどもっと探せばあるのかも。恐らく、保護のためとウェイトの意味もあったのではないかな…。最初はザウルスのヒップチャップみたいに音の要素があるのかと思ったけど、多分違う。あるとしたら、フックとの干渉音ですかね…。

手持ちの恐面ルアー、大事に使っていこうと思います。🎣

追記

その後早速フィールドで投げてみました！思ったよりスライド幅もあり、その場でネチネチもでき、重いので飛距離も出るしかなり使いやすかったです。ダブルフックなのでカバー近くでも使いやすい。

あまり見やすくは無いかもしれませんが、作成した動画内で使用しています。

気に入りましたのでこれからも見つけ次第回収しようと思います。

またまた追記

少し前に中古で購入した「トップウォータプラグ大全」に、恐面のプロトのルアーも含め複数掲載されていた！

のでデータとして記録しておきます。

恐面、結構色々なルアーを開発中だったようですね。しかし結局発売はされてなさそうなので、残念…。

このブログは Ghost というブログプラットフォームを使用し Nomad クラスター上で動作しています。

Nomad クラスター上で Ghost ブログを動作させる

このブログは数年間単一のサーバーで稼働していました。 学習も兼ねてわざわざ自前でサーバーを運用していたのですが、最近新しい構成に移したくなり、Kubernetes の流行もあってクラスターやマイクロサービスといった時代の流れに乗るべく、Nomad クラスターへの移行を行いました。 Nomad クラスターの作成までは下記記事にまとめています (インフラやクラスターの設定等はここからさらに変更しています)。 * Nomad クラスターを作成する 今回はこの Nomad クラスター上で Ghost を動かすところまでをまとめます。 構成 以下の通り、DigitalOcean のマネー…

ゆるふわキャンパーLorentzca

色々悩んだ結果、Docker イメージ上にブログのコンテンツを全て収めており、これを Nomad ジョブとして動かす形で運用しています。
これはメリットもあるのですが、一番大きなデメリットとして更新が面倒というものがあります。例えば記事を更新する場合の手順をざっくり挙げると以下です。

1. 最新の Docker イメージからコンテナを立ち上げる。
2. 記事を更新し、 docker commit する。
3. docker push し Docker Hub のイメージを更新する。
4. Nomad の動作しているサーバーに ssh し、Nomad のジョブファイルを編集して最新の Docker イメージに書き換える。

うーん…面倒。

多少負担を減らすためスクリプトである程度手順の簡略化を図っていますが、それでもまだ面倒…。

ブログ管理用のスクリプトを書いた (構成変更までの繋ぎ)。

現在このブログを Nomad のタスクとして Docker で動かしています。 Nomad クラスター上で Ghost ブログを動作させるこのブログは数年間単一のサーバーで稼働していました。 学習も兼ねてわざわざ自前でサーバーを運用していたのですが、最近新しい構成に移したくなり、Kubernetesの流行もあってクラスターやマイクロサービスといった時代の流れに乗るべく、Nomad クラスターへの移行を行いました。 Nomad クラスターの作成までは下記記事にまとめています (インフラやクラスターの設定等はここからさらに変更しています)。 * Nomad クラスターを作成する [https:/…

ゆるふわキャンパーLorentzca

そこで今回は Nomad UI を使用してジョブの書き換えをすることで手順 4 の簡略化を図ってみます。

以下の通り Nomad には標準で UI が付属します。

• Access the Web UI

これにインターネットを介してアクセスできれば、ちまちま ssh して nomad コマンド叩いて…をするよりだいぶ楽になります。

が、この Nomad UI には特にサインインによる認証機構はないので Web サーバーの設定を更新してアクセスできるようにするだけでは誰でもアクセスできてしまい危険です。

そこで今回は Basic 認証をかけてみます。

Basic 認証の設定

このブログにアクセスするための構成は以下のようになっています。

• ブラウザ → ロードバランサー (IaaS プロバイダーが提供するマネージドサービスを使ってます) → Nginx (Nomad ジョブで稼働) → Ghost (Nomad ジョブで稼働)

これと同じように、Ghost に加え Nomad UI へアクセスするようなルーティングを追加します。

Nginx の Nomad ジョブファイルから抜粋します。ジョブのタスクスタンザ内に Nginx の設定やらを定義しているので、タスクスタンザから抜粋します。

まず Docker の設定です。Nginx の設定ファイルと Basic 認証に必要な .htpasswd ファイルをコンテナ内で使用するためにボリュームの設定をしてします。

driver = "docker"
config {
  image = "nginx:1.15.12"
  ports = ["http"]
  volumes = [
    "custom/default.conf:/etc/nginx/conf.d/default.conf",
    "custom/.htpasswd:/etc/nginx/conf.d/.htpasswd"
  ]
}

次に、template スタンザを使用して上のボリュームで指定している custom/default.conf と custom/.htpasswd を作成していきます。

まず custom/.htpasswd から。.htpasswd の中身 の部分は htpasswd コマンドで作成したファイルの中身をそのまま入れています。ここも後々 Vault から取得するようにしたい。destination がファイルの吐き出し先ですね。

template {
  data = "<.htpasswd の中身>"
  destination = "custom/.htpasswd"
}

custom/default.conf はちょっと長いので今回必要な部分のみ。

{{}} の部分は Consul 統合を使用して Consul のサービスカタログから自動的に Nomad クライアントの IP アドレス・ポートを取得している部分です。めっちゃ便利。Consul UI にアクセスさせたいサーバー名へのリクエストが来たら、upstream で指定した Nomad クライアントの IP アドレス・ポートに流すようにしています。それ以外は普通に Basic 認証を設定する Nginx の設定です。

template {
  data = <<EOH
  ...
    upstream nomadbackend {
      ip_hash;
      {{ range service "nomad-client" }} server {{ .Address }}:{{ .Port }};
      {{ end }}
    }
    ...
    server {
      listen 80;
      server_name <Nomad UI にアクセスするためのサーバー名>;
      location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header HOST $http_host;
        proxy_set_header X-NginX-Proxy true;
        proxy_pass http://nomadbackend;
        proxy_redirect off;
        auth_basic "restricted";
        auth_basic_user_file conf.d/.htpasswd;
      }
    }
  EOH
  destination = "custom/default.conf"
}

Nomad UI の画面

こんな感じ。ジョブの情報やサーバー、クライアントの情報が見れます。なかなか細かく見れるので助かる！

このようにブラウザ上の UI からジョブ定義を書き換えて適用できるようになりました！

今後

ジョブの更新が ssh でアクセスするよりもかなり楽になりました。
が、もう少し楽にしたい…。

• Nomad UI を公開したことで Nomad API へのアクセスもできるようになったのでコマンド一発で更新できるようにしたい (ブログ運用スクリプトに組み込みたい)。

以下も改善したい。

• ジョブ定義ファイル内の .htpasswd の情報は機密情報なので Vault に保管し使用したい。
• Nomad の ACL を使用し UI の使用を制限したい。
• サインイン機能ではなく、表示される項目を制限するもの。Basic 認証と併用すればより安全になる。

完成車 (Trek 1.2 2014) のハンドル (Bontrager Race VR-C) から日東の M137SSB に変えてみました。

速度よりは長距離を快適に走りたいのと、キャンプ時に荷物を積載しても安定して走りやすいように幅が広いグラベル用ハンドルが気になっていて、変えてみました。本当は Trek 車なので Bontrager の Bontrager GR Elite Road Handlebar にしたかったのですが在庫が無さすぎてボツ。日東は気になるメーカーだったのもあり今回は日東を選択してみました。

M137SSB はグラベルロード向けのハンドルで、フレアハンドル。

サイズ選びに迷ったのでメモ。

現状の確認

Bontrager Race VR-C Road Handlebar の 440mm を使用。ロードバイク用の普通のハンドルなので、上ハンドルも下ハンドルも幅は変わらず 440mm。

この幅については特に不満は無い＆舗装路がメインなので上ハンドルについてはこれ以上広げる必要も今のところは無く、上ハンドル 440mm のもので合わせたい。

M137SSB のサイズを確認

サイズの種類は 480mm ~ 540mm で 20mm 刻み。このサイズ表記はハンドルバーの先端から先端までの幅で、フレアハンドルなので上部の幅はもっと狭い。が、その上部の幅については公式サイトに情報が無い。

ググると左右で 30mm ずつ広がっているようなので、合計 60mm 広がっている模様。とすると、500mm サイズを選べばいいはずということで購入。

が、ちょっと心配になってもう少し調べる。

日東のサイトを見ると上ハンドルからのフレアの角度は 15 度でドロップの高さは 128mm。

y = xtanθ 的な式でフレアによって生じる辺の長さを計算すると約 34.2mm。あれれ…？うーん、もしググって得た 30mm という情報が不正確なら、500mm より一つ上の 520mm にした方が良さそうかもですが…。日東のサイトに表記されているドロップ高の計測方法との誤差ならいいのですが…。ただ実際に握ってみないとなんとも言えない部分もあり難しい…。

とりあえず商品の到着を待つ！

装着後の感想

到着したので測ってみたところ、上ハンドルの幅は元のハンドルとほぼ同じでした！よかった！！

実物を見ると、写真で見たよりもフレアしてる感。かっこいい！

装着方法は複雑ではないけれど、中心合わせたりブラケットの位置や角度を左右対称にするのが難しかった。特に目安となる線等無いからね…。ボルトを締めたり緩めたりしながら納得がいくまで微調整、といった作業。

ちなみにバーテープは元のを再利用しています。後々 (といっても世界的な自転車のパーツ不足の影響でいつになることやらですが) コンポーネントのアップグレードをする予定でそれに合わせてバーテープも新調したいので。とりあえず巻く練習にはなった！化粧テープは持ってないので、テープの終端は絶縁テープで雑に固定されております。

早速近所の未舗装が混ざるような道路を走ってきました。

• 舗装路: 今までとそこまで変化なし。路面状態が悪い時は下ハンドル握ると結構安心感を得られた。荷物積載したり長距離走るともっと違いを感じられるかも。
• 未舗装路: これは明らかに楽！フレア角度はフレアハンドルの中では控えめな部類だと思うけど、それでもこんなに違うのか〜という感触。安定感が段違い。地面がデコボコでも怖くない。

ということで、日常的に使う分にも快適になって、フレアハンドル最高でした。

もっとフレアしててもいいかなと思えるくらい。

フィッシュテールグリップというグリップがあり、これに一目惚れ…。あまりにも良い。

E-No.Products という、メインはアクセサリーを制作されているショップから。代表の榎本さん自身が釣り人で元々自分用に作ったのがきっかけらしい。うーん良い。

このフィッシュテールグリップはサイズがオリジナルとナローの 2 種類あり、ナローの方がコンパクト。トップ用にダイレクトリールを使っている自分にはナローが合いそう。ダイレクトリールもコンパクトなので。

それで、このグリップは上の Instagram にあるようにハンドルとして完成品も売っているけど、グリップ単体としても売っている。私はグラスアイのハンドルを好んで使っているので、ハンドルブランクは、グラスアイのエルゴノハンドルと合わせたい。

エルゴノハンドル | バス釣り、トップウォーター【Glass Eye】ルアーやハンドル、ロッドなどの通販

ルアー＆クラフト【グラスアイ】ではバス釣りのトップウォーターをメインに釣具の通販・販売しています。トップウォーター用のウッド製のオリジナルルアーからグラスロッド、グラスアイスティックからオフセットのアルミハンドルまで取扱っています。

グラスアイインターナショナルグラスアイインターナショナル

でもエルゴノハンドルはオフセットが浅め (セミオフセット) なのでダイレクトリールを装着した際に親指が立っちゃって取り回しに問題が出ないかちょっと心配…。公式で ABU のアンバサダーとも合いますと書いてあるので恐らく大丈夫だと思うけど…。オフセットが浅めだとカルカッタコンクエストなどハイエンドのリールでも取り付けられるのが魅力なんですよねぇ。公式情報を信じるぞ！

ということでエルゴノハンドルに決定。しかしフィッシュテールグリップの付いたエルゴノハンドルは販売されていないので、個別で用意し自分で接着する必要がある。

接着の際、グリップの適合シャフトとハンドルブランクのサイズが合っているかがポイントとなるが、穴の径、長さ共にぴったし！

適合シャフト: 13mm x 90mm 以内

Fish Tail Grip　【ﾌｨｯｼｭﾃｰﾙｸﾞﾘｯﾌﾟ】

シャフトは13mm径×90mmです。

トップウォーター/エルゴノハンドル/シルバー/ブランク

と言うことで追加の加工無しでいけるはず。

ハンドルブランクとグリップの接着は、調べると 2 液性エポキシ接着剤で接着するのが一般的な模様。

• https://www.glasseye.co.jp/blog/2015/11/2-1.php?utm_source=pocket_mylist
• https://www.facebook.com/fishingtirol/posts/3155478721436556/
• https://www.ishiguro-gr.com/blog/detail.php?id=11816&utm_source=pocket_mylist

以前自作キーボードを組んだ際、Pro micro のもげ防止に買った 2 液性エポキシ接着剤がまだいっぱいあるのでこれを使えば良さそう。大容量タイプを買って良かった！

• https://www.amazon.co.jp/gp/product/B00476JFA4

接着する

まず改めてサイズの確認。接着剤を付けずに差してみて、問題無いかどうか。装着してみましたが意外に硬くて入っていかず大丈夫か！？となりましたがコツを掴んだら普通に挿せるようになった。下手に緩いより全然良い。

ちなみに、同じくグラスアイの通常の C ハンドルとのオフセットの比較は以下。

やはりセミオフセットだと多少リールの位置が高くなり、サミングした際に少し親指が立つ。一方でそもそもオフセットが無いハンドルもあるわけで、それで普通に使っている人もいるのであまり大した違いでは無いのかもしれないが、深いオフセットに慣れているとちょっと手が開いて握りが甘くなる感じがして、頼りない印象を受ける。とはいえ握って手首を色々返してみた感じ許容範囲内かな。違和感は無い。一日中投げた場合どう影響するかが問題ですがとりあえずはよかった。

ということで接着やっていく！

ハンドルブランクとグリップの中心を合わせる

ハンドルブランクとグリップの中心がズレたら嫌なのであらかじめ中心線を鉛筆で印をつけておいて、それに合わせて接着できるようにする。後から消せるよう黒鉛筆で印をつける。ハンドルブランク側は成形時の溶接跡？で中心線がわかるので便利w これがストレートのグリップなら点対称なので角度を気にする必要がなく、精神的に楽そう。

フィッシュテールグリップはハンドメイドなのでミリ以下単位での左右対称ではないため、あまり神経質に中心取ろうとしなくていいはず。ということで感覚でやってる。装着してハンドルブランクのネジとトリガーとフィッシュテールグリップの尻尾の中心が一直線上に並ぶように微調整してグリップに印を付けるだけ。考えるな感じろ！

接着剤の準備

エポキシを混ぜる。必要な量とかよく分からないので多めに…。シャフトにリブ？谷間？があるので隙間を埋めるように。2 液の分量は硬化不良とか起こされて釣りをしている最中に外れてしまっては困るので、ちゃんと 1:1 になるよう計量する。

ハンドルブランクのグリップとシャフトに接着剤を塗る

初めての作業なのでどんな感じで塗るのか軽く調べる。

完成品のグラスアイのハンドルを外した方の記事がありシャフトにこびりついた接着剤の写真があるので、これを目安にする。リブの隙間を埋めるように盛られてますね。グリップエンド側が多めで先頭部分は少なめな模様。接着剤が隙間から出てくるのを防ぐためかな？？

グリップの握り、交換しました。 : 脱力系水面風味

グリップは、最近こればっかり使ってます。グラスアイのグリップ。ブランクはＣタイプ、握りはコーデルラバータイプの組み合わせ。色はシルバーにブラウン。手に吸い付くような握り心地､､､しっくりくるサイズ感､､､絶妙な角度､､､手首の返しやすさから、バックハンドキャストも

脱力系水面風味HAKU

ブライトリバーのサイトでもグリップの接着の手順が紹介されている。

• http://blog.brightliver.com/?eid=1174072

参考にしつつグリップに接着剤を流し込み、シャフトにも塗り塗り…。

グリップにハンドルブランクを装着

印に合わせて入れる。余って出てきた接着剤は丁寧に拭き取る。

思ったより接着剤が溢れてきてしまったので、もっとしっかりグリップとハンドルを養生すべきだったな。

あとはこのまま立てて置いて完全に硬化するまで 24 時間ほど待つ…。

完成！

できた！

リールを装着。あまりにも良い…。これを肴に呑めます。🍶

肝心な使い心地ですが、不安だったサミングの位置の高さは慣れれば問題ない程度でした！自分の手のサイズだとちょっとグリップのサイズが小さい気もしましたが、1 日使ってみても特に手が痛くなることもなかったので、この点も問題なし。

ハンドルブランクとグリップを接着するのは初めてで互換性や接着方法など色々不安でしたが、なんとかできました。嬉しい。今年はこれで釣るぞ！！！！🎣

中古屋とかでやっすいハンドルブランク買ってきてグリップを自作してオリジナルのハンドルを作るのも楽しそう。

真冬にサイクリングする際の服装が固まってきたのでメモ。

真冬にサイクリングするようになる前から真冬ハイキング (低山) は行っていたので、初めはそのまま服装を流用していたのですが厳しい部分があったのでその部分だけサイクリング用に買い足した。

0 度くらいまでなら結構快適な服装です。0 度未満になると足先が寒くなってくる感じ。足先以外はまだいける。あと休憩時等、動かないと寒い。動いていれば全然平気という服装になります。

足

• 真冬のハイキング用の靴下: 厚手なので保温してくれる。ハイキング用のものを流用。
• SPD シューズ: 普通の SPD シューズ。
• シューズカバー: 靴の上から被せる防寒カバー。最初これの存在自体知らなかったのですが、真冬に走るとつま先が痛みを感じるほど寒くなることがわかったのでみんなどうしてるのかググったらカバーの存在を知って購入。ただし 0 度を下回るとカバーをつけてもだんだん寒くなってくる。

脚

• 真冬用のサイクリングタイツ: 初めは冬ハイキング用のトレッキングパンツとメリノウールタイツを履いていたのですが、ロードバイクのチェーンか何かに触れて裾が汚れてしまいしかも頑張って手洗いしてもなかなか落ちなく、ショックだったのでこれはダメだということでサイクリング用のタイツを購入。サイクリングタイツは下着を履かずに直で履くことが推奨らしく、下着なしで履いてますが快適です。

胴

• メリノウールシャツ: 汗を吸ってくれつつ発熱するので汗冷えもしにくく、防臭効果もあり快適の極み。ハイキング用に持っているものを流用。
• フリース: 保温目的。ハイキング用に使っているものを流用。
• 裏起毛ウインドブレーカー: 初めはハイキング用のダウンを着ていたのですがサイクリングの運動量だと瞬く間に汗びちゃになってしまうことがわかり、サイクリング用のウインドブレーカーを購入。裏起毛で保温性もプラス。ただダウンは休憩時に着るととても暖かく快適でしかも圧縮すれば嵩張らないので、外でお湯を沸かして食べるような長めの停滞を伴うサイクリングの場合は休憩用に持って行ってます。
• 腹巻: 走っていると意外にお腹が冷えることがわかったので購入。これはサイクリング用で前面は防風のゴアテックス、背面は汗を逃すためにメリノウールと工夫されている。今まで腹巻自体使ったことがなかったのですが、暖かいので日常でも使ってるしハイキングにも使えるしで、万能アイテム！かなり気に入ったので同じモンベルのサイクリング用じゃない普通のモデルの腹巻きを妻と母にもプレゼントした。とても喜んでもらえたので良かった。登山ブランドの腹巻き、しっかり暖かいし服の下に着るものだからデザインの好みも気にしなくて良いし、邪魔になるものでもないのでプレゼントとしてかなりいいのでは…。

頭

• ヘルメット: ロードバイクはスピードが出るし安全のため必須ですね…。
• サイクルキャップ: サイクルキャップってイメージ的には水泳用の帽子みたいな感じで頭にフィットし薄いので、ヘルメットの下に被れる。ヘルメットと合わせて、これらは真冬以外も使ってますね。真冬は耳が寒いので真冬用のサイクルキャップがいいかも…。
• ネックウォーマー: 普段使いやハイキングに使っているユニクロのヒートテックネックウォーマーを流用。有ると無いとではかなり違う。裾を上げれば耳もギリギリカバーできるので良い。

手

• インナーグローブ: 保温用の手袋。ハイキング用に使用しているものを流用。
• オーバーグローブ: インナーグローブだけだと防風性がないのでこちらを併用。これもハイキング用に使用しているものを流用。サイクリング用のグローブは手が痛くなりにくいようにシリコンか何かのサポートが手のひら部分に入っていたりするが、今のところこのグローブで問題を感じていない。

感想

アウター部分以外はハイキング用のものを流用できる印象。-3 度のサイクリングでは上記装備でも足先が厳しくなったので氷点下対応のサイクルシューズを買うか、アストロフォイルをシューズカバーの間に入れるなど工夫したい。