フロント担当のTIL 2025/04

こんにちは。

「Today I Learned（今日学んだこと）」を記録するTIL、4月もいくつか印象に残ったトピックがありました。フロントエンド周りだけでなく、運用・インフラ系やツール選定など幅広く触れています。以下、ピックアップした内容を紹介します。

[前 2025/03]

2025年4月のピックアップ

プライバシー保護を意識した代替ツールの調査 (04/01)

プライバシー保護の観点から、大手テック企業が提供するサービスからの乗り換えを検討し、いくつかのオルタナティブなツールを調査・試用しています。いわゆる「脱Google」的な動きです。

1. 検索エンジン

Googleの代わりにDuckDuckGoを試しています。プライベートでは既に切り替え済みで、仕事用にも変更を検討中です。検索結果の精度には多少の差がありますが、プライバシー面でのメリットは大きいと感じています。

2. ブラウザ

Chromeから、仕事用にはArc、プライベート用にはVivaldiに乗り換えました。どちらも独自の便利な機能があり、思った以上に使い勝手が良いです。

3. メール

GmailやiCloud Mailの代替としてProton Mailを検討中です。プライベートでは既にGmailをやめてiCloudの「メールを非公開」機能を活用していますが、よりセキュアな選択肢としてProton Mailが魅力的です。ただ、コスト面がややネックです。

4. パスワード管理

1PasswordからVaultwarden（セルフホスト）に移行しました。プラン更新のタイミングだったこともあり、この機会に乗り換えました。運用コストが下がり、データの管理も自分でできるようになりました。

5. クラウドストレージ

エンドツーエンド暗号化に対応したProton Driveが候補ですが、 Dropboxと比べ、容量が少ないのが課題です。現在は自宅NASのバックアップ先としてもDropboxを利用しているので、ファイルを暗号化した上でS3のようなストレージを利用すれば、容量問題を解決しつつプライバシーも確保できるかもしれません。

完全に移行するには時間と手間がかかりますが、少しずつ自分に合ったツールを見つけていきたいと考えています。

Capacitorのライブリロード設定 (04/03)

モバイルアプリ開発フレームワークCapacitorでライブリロードを試してみました。

Viteのような開発サーバーを利用している場合、開発サーバーを起動した状態で、以下のコマンドを実行することでLive Reloadが有効になります。（Viteのポートが5173の場合は--port 5173のように指定）

npx cap run ios -l --host localhost --port 8080

現時点ではiOSシミュレータでのみ動作を確認しています。実機でLive Reloadを利用する場合、PCのIPアドレスを指定する必要がありますが、HTTP接続では一部機能に制限が生じる（Secure Contextでないと利用できないAPIがあるなど）ため、HTTPS化するか、他の手段を検討する必要がありそうです。

ブラウザのアドレスバーからのサイト内検索 (04/09)

多くのブラウザでは、アドレスバーにキーワードを入力するとデフォルトの検索エンジンで検索できますが、これに加えて特定のウェブサイト内の検索機能を直接呼び出せるように設定できることを知りました。すでに使っている方も多いかもしれませんが、今までスルーしていた機能でした。

例えば、社内で利用しているGitリポジトリや、ドキュメント共有ツールの検索窓をブラウザのアドレスバー検索に登録しておくと、git<tab>検索ワードやdoc<tab>検索ワードのように入力するだけで、目的のサイト内を素早く検索できるようになります。

iOSシミュレータのステータスバー調整 (04/14)

アプリケーションのスクリーンショットを撮影する際、iOSシミュレータのステータスバーの表示（時刻や電波強度など）を特定の値に固定したいケースがあります。これを実現するためにxcrun simctl status_barコマンドが利用できることを知りました。

# 時刻を9:41に固定する
xcrun simctl status_bar "iPhone 16 Pro" override --time '9:41'

# セルラー回線の強度を変更
xcrun simctl status_bar "iPhone 16 Pro" override --cellularBars 4

デモやドキュメント作成時に統一感のあるスクリーンショットを撮影する際に役立ちます。

OpenAI API の新モデル (04/15)

OpenAIから新しいモデル群が発表されていました。

Introducing GPT-4.1 in the API: https://openai.com/index/gpt-4-1/

低価格モデルとしては「GPT-4o mini」を継続使用するか、新しい「GPT-4.1 nano」に切り替えるかの選択肢があります。「GPT-4.1 nano」は微妙に安価になっており、性能面ではベンチマークによって優れている点と劣っている点があります。

また、「GPT-4.1 mini」が「GPT-4o」に迫る性能であれば、コストパフォーマンスが良い選択肢となる可能性があります。

AI用マシンの選定 (04/24)

社内で「AIをみんなで使えるマシンが欲しい」という要望があり、その選定を行いました。AIと言っても用途によって求められるスペックが異なりますが、選定にあたって検討したポイントをまとめておきます。

生成AI（LLMの実行、画像生成など）
GPU性能、特にVRAM（ビデオメモリ）の量が重要になります。
機械学習（モデルのトレーニングなど）
GPU性能に加え、メインメモリ（RAM）の量も大量に必要となる場合があります。

その上で、主に以下の選択肢で比較検討しました。

Mac (Apple Silicon)

RAMとVRAMがユニファイドメモリとして共有されるため、比較的大きなモデルも扱える。
消費電力あたりの性能が高く、（特定の条件下では）コストパフォーマンスに優れる。
ソフトウェアがMLXに最適化されていないと、GPUのフルパワーを活かせない場合がある。

独立GPU搭載マシン

NVIDIA製のGPUであればCUDAを利用できる。CUDAはAI/機械学習分野で広く採用されているため、対応ソフトウェアや情報が豊富。
高性能なGPU、特にVRAMが多いモデルは非常に高価。
ハードウェア、ソフトウェアの選択肢が豊富で、Macよりも自由度が高い。

現状ではCUDAエコシステムの優位性が大きいため、多くのケースでNVIDIA製GPUが選択肢の中心となります。どのGPUを選ぶかについては、以下のような種別があります。

コンシューマー向けGPU (GeForce RTXシリーズなど)

比較的安価に入手可能。
VRAMは多くても24GB〜32GB程度、お手頃な価格帯のモデルでは16GB程度。

ワークステーション向けGPU (NVIDIA RTXシリーズ ※旧Quadro)

非常に高価。
大量のVRAMが必要な場合。
サーバー用途での安定性・信頼性、仮想環境向けの機能が必要な場合。

今回は最終的にNVIDIA製GPUを搭載したマシンを発注しました。また別の機会にご紹介できればと思います。

Grafana + Prometheus + Loki のセルフホスト環境構築 (04/25)

社内の実験用環境向けに、Grafana + Prometheus + Lokiのセルフホスト環境を構築しました。

普段はGrafana Cloudを利用していますが、社内環境でも同様の監視基盤が必要になったため、セルフホストを試してみました。

通常、PrometheusはPull型でメトリクスを取得しますが、今回はGrafana Alloyを使ってPush型にしました。Prometheusの起動時に--web.enable-remote-write-receiverオプションを指定することで、Alloyからのメトリクス受け取りが可能になります。

この3つの組み合わせで、Grafana Cloudとほぼ同等の機能を実現できました。ただし、Cloudで提供されているIntegrationはセルフホスト版では利用できないため、Grafana Alloyの設定やダッシュボードの作り込みは手動で行う必要があります。今回は、Grafana Cloud側で必要な設定を作成し、その設定値を参考にセルフホスト環境へ移植する形で対応しました。

Grafana のアラート戦略 (04/28)

上記の監視環境を整えた流れで、アラートについても検討を進めました。対象はProxmox VEホストおよびその上で稼働する仮想マシン（Linux）です。

ホスト環境（Proxmox VE）

CPU / RAM
ホスト環境自体は比較的安定して稼働しているが、スペックが低いこともあり、リソースが常時高負荷になりがちなため、単純な閾値でのアラートは誤検知が多く、実用的ではありませんでした。
ロードアベレージ
一方で、ロードアベレージは今回の環境では比較的安定しており、極端な負荷がかかった場合のみアラートが発報されるように設定できました。
温度
物理ホストであるため、温度は気にしたい項目です。今回の環境では、CPU使用率が温度に影響を与えることが多く、ルールの待機時間を長めに設定することで、誤検知を減らすことができました。
ストレージ
ホストはディスク使用量の変動が少ないため、ダッシュボードでの定期的な目視確認で十分だと判断しています。

ゲスト環境（Linux仮想マシン）

アプリケーション監視
すでに外形監視やSentryを利用していて、アプリケーションレベルの監視はこれらのサービスに任せているため、Grafanaでのアラートは必要ないと判断しました。ログやメトリクスの収集は行っているので、必要があればダッシュボードで確認できるようにしています。
課題：エージェント導入の手間
正直なところ、ゲストごとに監視エージェントを入れるのは手間がかかるため、ゲスト環境の監視はあまり進めていません。ただし、Cloud-Initなどの自動化ツールを使えば、エージェントの一括導入・設定も現実的になるため、今後の改善ポイントとして検討したいと思っています。

LM Studio でローカルLLMを試す (04/30)

ローカルでLLMを手軽に試せるツールとして、「LM Studio」を使ってみました。

LM Studio: https://lmstudio.ai/

これまではローカルLLMの試用にOllamaを使っていましたが、LM StudioはGUI付きで導入が簡単、モデルのダウンロードや実行もスムーズで、初心者にも扱いやすい印象です。

LM Studioにも「ヘッドレスモード」があり、Ollamaと似たようなAPIベースの運用も可能です。サーバー用途としては、どちらが最適かは検討の余地があります。Ollamaには使っていないモデルを自動でアンロードする機能があり、メモリ管理の面では有利に思えます。

用途や規模によって選択肢が分かれそうですが、「ちょっと試す」「複数モデルを簡単に試用したい」といったニーズには、LM Studioがかなり便利でした。

おわり

今回は、フロントエンドに直接関係する話題は少なめでした。5月は実験中のネタやAIマシンの運用など、紹介できそうな内容が増えると思うので、よろしくどうぞ。