BRiGHT STARS FESTIVAL 2026

tasasei

シャインポストのライブに行ってきた。 この思い出を記しておかねばならない。2日間の開催で、2日とも行ってきたのだ。

春風に乗って

この作品の中でも、トップクラスに好きな曲である。 Day1のみの曲であったが、聞けて満足である。両日参加した甲斐ある。 この手のゲームに関係するコンテンツは、ゲームの思い出を現実で追体験できることが、 醍醐味の一つである。ゲーム中では、サビ前にクラップが入っている。 それを現地でできたことは大変嬉しい。

久保田未夢

彼女は大変優秀な方である。 作品への愛がにじみ出ている。一ファンとしては大変うれしいことである。

Day1でのことだったと思うが、作中3姉妹でのパフォーマンスの後のMC中に、 「なぜこの三人なのか、と思っている人は、小説を読んでほしい。」 と発言されていた。二方から、宣伝上手と褒められていたが、 やはり上手い。実際に本番の適切なタイミングで、この言葉が出てくるのは、 それなりに凄いことだと思っている。ラブライブでの経験が活きている、 という側面もあるかもしれないが、逆にちゃんとこのような気が回るからこそ、 作品に愛を持って臨めるからこそ、ラブライブにキャスティングされていた、 とも言えるだろう。

鈴城紗弓

彼女個人のことは、今まであまり存じなかったのだが、大変優秀である。 Day2の最後、挨拶の後に両手を上ていた際に、銀テープが丁度、彼女の手に収まった。 その銀テープを、床などに置くことなく、最後の退場まで持っておられた。 正しい行動である。例え床に置くなどした場合に、 その銀テープが何かの間違いで客席に渡ってしまったならば、 争いが起きてしまう。そのようなことを気にするぐらいならば、 最後まで持っておいた方がいい。

Day1の最後にて、各グループから1人が代表して挨拶をする、という場面があった。 そこで、ラフダイの番が回ってきた、という時に、 「指名してもいいと言われている」ということを話したあと、 桃果ちゃん、と指名した。桃果は、シャインポスト内の、ラフダイのキャラクター名である。 それが瞬時にでてくるのが、まぁすごいと思う。 別に、アニメでもゲーム内でも彼女が担当する青天目春とは、関係があったわけではないのだ。一切。 覚えて来ているのである。意図的に。 恥ずかしい話、筆者だって名前が出てこなかったのである。 座長を務める以上、当たり前のことなのかもしれない。 しかし、そんな当たり前のことができるからこそ、任されているのだと思う。 そして、なぜ桃果、すなわち白河みずなを指名したのか、という所であるが、 その意図としては、若い人にチャンスを与えたい、という意図があったのではないかと 勝手に推察する。また、白河みずなならばそれをできる、と思っていたからこそ任せたのではないか。 そして、白河みずなはそれを全うした。自分が回ってくるとは思っていなかった、と言い、ほんの少し 長くなって、HY:RAINの挨拶がスキップされた(と思う)のだが、それぐらいはいいだろう。 ギリギリ許容できるラインだと思う。

東江凪

すごい人気である。ひまわりシンフォニーの中でもクール可愛い担当であるが、観客からの応援もすごい。 トークパートで、合間に観客席から聞こえる「なぎー!」「なぎー!」の声が、いい味を出していた。

木戸伊吹

とてつもなく優秀である。 ミリオン6th追加公演ビューイング、10th福岡現地と、何度か見てはいるのだが、ここまで入れ込んで、 これほど作品に愛情をもって臨んでくれる方とは存じ上げていなかった。感謝しかない。 木戸さん曰く、髪型をスプレーでガッチガチに固めてもらって山田を再現してくれているらしい。 石原PのSNS曰く、頼んでいないにも関わらず、してくれているらしい。 もちろん、見た目を再現することが大事なわけではないが、見た目わかりやすく再現してくれているのは、 ファンにとっては嬉しい。

また、コールレスポンスも素晴らしかった。熊沢さんからのパス「次は山田!」からの「花音だよ!?」 の流れが、表情含め素晴らしかった。 あそこまで流れが綺麗に決まっている、ということは事前に打ち合わせをしていたんだろうな。 台本にもあったのだろうか。わからないけれども、みんなありがとう。

IAM Identity Center管理下のユーザーがログイン時にパスキー認証を使用する

tasasei

操作

  1. IAM Identity Center > 設定 > アイデンティティソースに表示されるAWS access portal URLにアクセス。
  2. 右上のアカウント名からセキュリティを選択。
  3. 多要素認証 (MFA) デバイスのデバイスを登録を選択。
  4. 認証方法一覧が表示されるので組み込みの認証アプリを選択。

基本的にこれだけです。

できない場合

IAM Identity Centerの設定に問題がある可能性が高いです。

  1. IAM Identity Center > 設定 > 認証で多要素認証の設定を選択します。
  2. MFA設定のユーザーはこれらの MFA タイプで認証できます > セキュリティキーと組み込みの認証ツールにチェックを入れて変更を保存します。

以上です。

参考文献

写真のバックアップをS3にアップロードした際に思ったことのメモ

tasasei

個人写真のS3へのバックアップに際するキーポイント

iCloudの残量がなくなってきたので、写真のバックアップをS3にアップロードした。 これは、あまり良い方法ではなかったのだと思うが、一応記録に残しておく。

そもそも、プライベートなものをネット回線にさらすこと自体が多大なリスクである。 特に記録を残しておきたいのは以下の3点。

  • HASHの記録は「CRC64NVME(推奨)」で行う
  • ストレージクラスを標準でアップロード
  • ストレージクラスをGlacierに変える

HASHの記録は「CRC64NVME(推奨)」で行う

アップロードが成功したかどうかは、ファイルのハッシュを見る。 SHA256だと、multipartでアップロードされた各パケット全てから算出されるらしい。 これにより、ローカルでファイル単体を見た場合と、ハッシュ値が異なる。 そのため、パケット分割による影響を受けない、ハッシュ計算方法として提示されている、 CRC64NVMEを使用する必要がある。

ストレージクラスを標準でアップロード

言い換えるならば、最初からGlacierでアップロードしないことである。 なぜならば、標準->Glacier系は、リスクは無い。 アップロードに失敗して即削除した場合でも、料金は使用した時間、アクセス分しか請求されない。

しかし、Glacier->標準の場合は、 Glacierの最低日数90日分の使用料が必ず乗る。そのため、即座に切り替えた場合は、使用していない日数分の 料金を支払わなければならない。

そのため、このような手動バックアップの場合は、ストレージクラス標準でアップロードし、 完了後にクラスをGlacier系に切り替えるのが適切と思われる。

ストレージクラスをGlacierに変える

ストレージクラス標準でアップロードを完了したのちに、Glacierの希望のクラスに切り替える。 似たような名前が並んでいるので、この時は気を付けなければならない。

私の場合は、Glacier Flexible Retrieval(旧 S3 Glacier)にしたかったのだが、 誤って別のクラスにしてしまった。なんか、(旧)とかあって不安だったし。 その結果、ライフサイクルルールを設定して、90日後に切り替えるよう設定する羽目になった。

所感

この場合のこの方法は、おそらく適切ではない。

最も高いセキュリティは、インターネットに晒さないこと。 AWSのセキュリティは高いとはいえ、今この状態でも、簡単な操作で全て流出してしまう。 本当は、自宅のラズパイにNAS機能を追加してしまうのが、手間的にもセキュリティ的にも適切なのだと思う。 ただ、イニシャルコストと自分の不勉強が足を引っ張っている。 USBが空いているので、そこにHDDかSSDを入れてしまった方がいいのだろうか。気乗りはしないが。

S3の3つのデータセンターにバックアップされるほどの堅牢性を7円・年/GBで得られるなら安いとは思う。 ただ、それは100GB以内の話であって、1TBレベルになるなら、7000円/年なのだから、HDD1つ買った方がいいと思う。

また、今回のS3によるバックアップを初めて行う際に、調査するのも、記録するのも、多大なエネルギーを使用する。 実質、丸一日使用してしまった。その割には、得られた知識の拡張性は、そうない。 リターンが高い行動を選んでいかなければならない。行動について取捨選択しなければならない。

Velero復元テスト

tasasei

経緯

veleroのバックアップの復元テストをしたかったのだけれども、 あまりにも面倒くさくて、Claude Codeに丸投げした。

復元完了後、veleroのrestores/ に復元レポートが保存される。

使用モデル、かかったコストは以下。CLIからは、/statusからのSessionで表示可能。

/status
  Total cost:            $2.81
  Total duration (API):  8m 28s
  Total duration (wall): 36m 20s
  Total code changes:    362 lines added, 0 lines removed
  Usage by model:
      claude-haiku-4-5:  303 input, 24 output, 0 cache read, 0 cache write ($0.0004)
     claude-sonnet-4-5:  281 input, 22.3k output, 5.1m cache read, 252.0k cache write ($2.80)

Claude Code をAmazon Bedrock APIキー経由で導入する

tasasei

Claude Codeデビューしたので、備忘録として残しておく。

Claude Code のインストール

Windowsで。PowerShellで以下のコマンドを実行。1

irm https://claude.ai/install.ps1 | iex

今回は、v2.1.175がインストールされた。 その後、インストール先のパスが表示されるので、コンソールからそのまま起動。

C:\Users\YourName\.local\bin\claude.exe

初回セットアップが走る。 なんかいい感じに、表示テーマとか聞いてくるので、その辺は適当に進める。

ログイン方法を聞いてくるので、この場合は3rd-partyを選択する。

    1. Claude account with subscription · Pro, Max, Team, or Enterprise
    2. Anthropic Console account · API usage billing
  > 3. 3rd-party platform · Amazon Bedrock, Microsoft Foundry, or Vertex AI

RunPodではじめる画像生成

tasasei

格安クラウドGPUサービス、RunPodを用いた画像生成に成功したので、 その方法を備忘録として記しておく。

アカウント作成、入金などは割愛する。

方法

URLは以下から。右上の「Deploy X.X.X」をクリックすればできるはず。 https://console.runpod.io/hub/runpod-workers/worker-a1111

作成したendpointは、左メニューのResources->Serverless、またはデフォルトならトップ画面の右上から確認できるはず。 そこから、コマンドを確認できる。

$ curl -X POST https://api.runpod.ai/v2/{endpoint_id}/run \
    -H 'Content-Type: application/json' \
    -H 'Authorization: Bearer YOUR_API_KEY' \
    -d '{"input":{"prompt":"a photo of an astronaut riding a horse on mars","negative_prompt":"blurry, bad quality","width":512,"height":512,"num_inference_steps":20,"guidance_scale":7.5,"seed":42}}'

AirTagを買った

tasasei

先日、AirTagを買った。 タイトル通りなのだが、その際に調べたことを、 忘れてもいいように記しておきたい。

AirTagのしくみ

AirTagは、Appleから2021年に発売された、位置情報タグである。 これ自身はSIMも必要とせず、GPS機能も持っていない。

では、どのように位置情報を発信しているのかというと、AirTagが発するbluetooth電波を 他人のiPhoneなどが拾って、匿名で位置情報を伝えている。 以下、公式HPから引用。

あなたのAirTagは、近くにある「探す」ネットワーク上のデバイスが検知できるように、安全なBluetooth信号を送信します。 すると、信号を受け取ったデバイスは、AirTagの位置情報をiCloudに送信。 あなたは「探す」アプリを開いてマップ上で確認できるというわけです。このプロセスは完全に匿名で行われ、 情報は暗号化されるので、あなたのプライバシーは守られたまま。効率も良いので、バッテリー残量やデータ使用量を心配する必要はありません。1

この機能はAppleのFind Myというしくみに組み込まれている。 日本語では探すだったりデバイスを探すだったりする。

このFind Myに対応している機器であれば、AirTagと同じように使えたりする。 例えば、つい先日の2026年3月に発売されたXiaomi Tag(https://www.mi.com/jp/product/xiaomi-tag/) であれば、AirTagと同じように位置情報を確認することができる。 AirTagの持つ、正確な場所を見つける機能は、UWBチップ非搭載のため使えないものの、 音を出すことは可能なので十分だったりする。

AirTagは定価4980円、Xiaomi Tagは1980円であるため、買うなら安い方で良かったな、 と若干思ったりしている。追加購入するときは、考慮に入れたい。

Androidでは

先程まで、Apple圏の話をしてきたが、Androidでも同様のしくみが存在する。 Find Hubというものらしい。が、私はiPhoneユーザーであるため、あんまり調べていない。 先述のXiaomi Tagは、こちらにも対応しているらしい。

まとめ

この機能は便利で月額課金などもない。すごい。後々「サブスク限定!」みたいにならないといいな。

kopiaの挙動についての調査

tasasei

Veleroを使ってk8sをCloudflare R2にバックアップしている。

k8sシステムのバックアップは、backups/フォルダ内に日付フォルダが作成されて保存される。 私はバックアップを10日分と設定しており、それより前のフォルダはVeleroが勝手に消してくれる。

PVのバックアップにはVelero内部でkopiaが使われていて、差分バックアップしているらしい。

このバックアップのサイズが日に日に増えていっている。 Velero本体側は古いファイルは確実に消されているが、kopia側は内部がよくわかんない。 その原因を調査すべく、我々はアマゾンの奥地へと向かった。

まず、S3 Browser(https://s3browser.com/)を使用してバックアップサイズを確認する。 PV以外が原因の可能性もあるため(kopiaが原因でない可能性もあるため)、念のため

backups/
31.63 MB (33 166 071 bytes)

kopia/
730.84 MB (766 345 759 bytes)

この時点でkopiaが原因であることは確定だが、もう少し深堀してみる。 Veleroは、namespaceごとにkopiaのバックアップリポジトリを作るらしい。 リポジトリごとのサイズを見てみよう。

kopia/kube-system/
960.84 KB (983 897 bytes)

kopia/default/
149.79 MB (157 062 963 bytes)

kopia/commafeed-k8s/
580.12 MB (608 298 899 bytes)

commafeed-k8sのサイズが大きいので、原因が簡単にわからないか見てみよう。

まず、以下のコマンドでkopiaでリポジトリに接続する。

$ kopia repository connect s3 --bucket=velero-backup \
  --access-key=MY_ACCESSS_KEY \
  --secret-access-key=MY_SECRET_ACCESSS_KEY \
  --endpoint=my_endpoint.r2.cloudflarestorage.com \
  --prefix=kopia/commafeed-k8s/

「映画ドラえもん のび太の絵世界物語」を見に行った話

tasasei

少し前になるが、ドラえもんの映画を見に行った。 別に書くほどの内容でもないのだが、記憶容量を空けるために、その時のことを書いておく。

見に行ったのは4月12日土曜日。場所も書いてもいいのだが、ネットに晒すわけだし、伏せておこう。

見に行ったきっかけというか、ある人に、見に行ったほうがいいとラインが来て、見に行ったわけだ。 そいつに、具体的な感想を話そうかと思っていたのだが、 当分会う機会も無さそうなので、ここで吐いておく。

感想を書くと、まあ良かった。 シナリオは、シンプルオブシンプルである。 こいつは、敵と見せかけた味方だろうな、というやつは、やっぱり味方。 こいつは敵だろうなという奴は、やっぱり敵。

日常パートで変な使い方をしたひみつ道具は、最終決戦で使う。 ヒロインが変な動きをしたら、その理由は最後に明かされる。 ジャイアンは男前。何の捻りもない王道の筋書きである。

だが、それがいいのである。劇場版ドラえもんに変なことなんて望んでいない。 私が見たい劇場版ドラえもんがそこにあった。

そして、ドラえもん、劇場版ドラえもんへの愛が多分に感じられた。 ほんやくコンニャク、きせかえカメラ、と言った劇場版の定番道具はもちろん、 水加工用ふりかけ、かるがるつりざおといったマイナー道具、 そして、チンカラホイ、テケレッツノパー、といった作品内のオマージュ、 また、誰もが忘れているであろう、パパの絵が上手い設定、等、 ドラえもんコミックス内の情報を広く扱っている。 これはドラえもんファンもニッコリである。

結局、みんなはミームが大好き、ということなのかもしれない。 ドラえもんミームである。それが、ファンの見たい物だったのかもしれない。 ドラえもんファンが作ったドラえもんファンの映画。それが本作なのかもしれない。

調べたら、本作の脚本家は大変なドラえもんマニアだったようだ。 忘れてもいいようにリンクを貼っておく。(今、私が書いているこの記事は何の案件でもないしリンク先から1円たりとももらっていないことも念の為に書いておく)

NEWSポストセブン 『映画ドラえもん のび太と絵世界物語』制作陣インタビュー#2 『映画ドラえもん のび太の絵世界物語』脚本家が明かす「こだわりのオマージュ」、考え抜いた「王道の展開」

以上。

ラズパイ内のKubernetesでPodを動かす

tasasei

自分の RaspberryPi 4B でk8sを動かすことに成功したので、 備忘録としてその記録をまとめておく。

インストール

公式に出ているkubeadmでインストールする方法は、難しすぎて 実質不可能なので、おとなしくk3sを使う。

公式のクイックスタートのコマンドそのままだと書き込みできずにエラー発生するので、 以下のように権限644を付加する。1

curl -sfL https://get.k3s.io | K3S_KUBECONFIG_MODE="644" INSTALL_K3S_EXEC="server" sh -

もしくは、設定ファイル/etc/rancher/k3s/config.yamlで権限付加を明記し、サービス再起動でもいいだろう。

write-kubeconfig-mode: 644

サービス再起動は以下のコマンドでできる。2

停止

sudo systemctl stop k3s-agent

起動

sudo systemctl start k3s-agent

これでk8sのインストールは完了

PodとServiceの起動

基本的に公式のチュートリアル に従ってPodの導入とServiceの起動ができる。

しかし、imageはarmには対応していないようなので、別途指定する必要がある。 今回は、動かせばいいだけなので、適当にnginxのimageを使用した。

そして変更してできたmanifest、load-balancer-example.yamlが以下。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: load-balancer-example
  name: hello-world
spec:
  replicas: 5 # 1でも動きます
  selector:
    matchLabels:
      app.kubernetes.io/name: load-balancer-example
  template:
    metadata:
      labels:
        app.kubernetes.io/name: load-balancer-example
    spec:
      containers:
      - image: docker.io/arm64v8/nginx # arm対応imageを指定
        name: hello-world
        ports:
        - containerPort: 80 # Pod側の待受ポート