Matsubo Tech Blog

Raspberry Pi 4 + Debian 13 (Trixie) で RTL-SDR を使った ADS-B 受信局を構築して Flightradar24 にフィードした記録

Wed, 01 Apr 2026 00:00:00 GMT

航空機のリアルタイム追跡サービス「Flightradar24」に自作の受信機からデータをフィードすると、Contributor プランが無料で提供されます（Business Plan と同等の機能が使えます）。今回は、最新の Debian 13 (Trixie) 環境で RTL-SDR ドングルを使い、基地局（RJTT2257）を立ち上げた際の技術ログをまとめます。公式スクリプトが Cloudflare に弾かれ、最新の署名ポリシーがレガシーを拒絶するケースへの対処が必要でした。

1. 動作環境と構成

今回のスタックは以下の通りです。

SBC: Raspberry Pi 4 Model B (4GB)
OS: Debian GNU/Linux 13 (trixie) aarch64
SDR: RTL2832U + R820T2
Software: readsb (Decoder) + fr24feed (Feeder)

RTL-SDR ドングルは AliExpress で数百円から購入できます。今回使用した RTL2832U + R820T2 チップセットのものが 1090MHz の ADS-B 受信に適しています。

公式のオールインワン・インストーラーに頼らず、デコーダーとフィーダーを疎結合にする構成を採用しました。これにより、SDRから上がってくる Raw データを 30005 ポート（Beast形式）で一旦受け、そこから各サービスに分配する拡張性を持たせています。

2. 最初の壁：Cloudflare の 403 Forbidden

構築を開始して早々、get.flightradar24.com からのスクリプト取得が WAF（恐らく Cloudflare）に弾かれ、403 Forbidden が返される事態に遭遇しました。多くのエンジニアがここで躓きますが、これは wget や curl のデフォルト User-Agent が Bot と判定されているためです。

解決策：User-Agent の偽装 ブラウザ（Chrome等）の文字列を模倣することで、セキュリティフィルタをパスします。

curl -L -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" [URL]

このワンクッションを入れることで、リポジトリ署名キー（.pub）の取得に成功しました。

3. 次の壁：Debian 13 (Trixie) の厳格なセキュリティポリシー

Debian 13 (Trixie) では、2026年以降のポリシーとして SHA1 署名を用いたリポジトリが apt update で拒絶されます。FR24 の公式リポジトリは依然として古い署名形式を使用しているため、そのままではインストールが不可能です。

解決策：[trusted=yes] による強制バイパス /etc/apt/sources.list.d/fr24feed.list の定義に [trusted=yes] を追記し、パッケージの署名検証を明示的にスキップさせることで解決しました。

deb [trusted=yes] https://repo-feed.flightradar24.com flightradar24 raspberrypi-stable

4. 最後の壁：libssl1.1 の依存関係崩壊

fr24feed バイナリは古い libssl1.1 を要求しますが、Trixie 環境では libssl3 が標準であり、旧版ライブラリがリポジトリから削除されています。

解決策：旧版 deb パッケージの直接導入 Ubuntu 20.04 等のアーカイブから libssl1.1 の aarch64 用 deb パッケージを取得し、dpkg -i で無理やり流し込むことでバイナリのリンクエラーを解消しました。

5. フィーダー設定と運用ステータス

/etc/fr24feed.ini では、readsb が開放している 127.0.0.1:30005 に接続するよう beast-tcp 形式で指定します。

港区・浜松町付近（RJTT周辺）に設置した結果、btop での観測では CPU 使用率 3% 前後、温度 42°C という超低負荷で安定稼働。深夜帯でも羽田のアプローチ機を確実にトラッキングし、サーバーとの同期結果を示す syncing stream result: 1 を吐き出し続けています。

tar1090 のローカル画面では、受信した航空機の位置がリアルタイムに描画されます。

Flightradar24 の統計ページでは、受信機ごとの受信機数・距離・機数などの実績が確認できます。

データのフィードを継続することで Contributor として認定され、Business Plan 相当の機能が利用できるようになります。

まとめ

最新 OS での構築は依存関係の問題が連続しましたが、一つずつ解きほぐすことで稼働にこぎつけました。現在は RJTT2257 という局 ID で世界中の航空ファンにデータを提供しています。

次は JE1WFV（アマチュア無線）としての知見を活かし、1090MHz 専用のバンドパスフィルタを自作して S/N 比を追い込み、受信距離の限界に挑戦する予定です。

Claude Opus 4.6 + ブラウザ自動操作で2025年確定申告：CSV解析・仕訳生成・MoneyForward入力・e-Tax送信

Tue, 17 Mar 2026 00:00:00 GMT

TL;DR

確定申告（青色・不動産所得+雑所得+株式分離課税）を AIエージェント主導 で完走
人間（自分）の実作業は 約3.5時間（e-Taxバグ対応除く）
AIが経費の申告漏れや控除の見落としを的確に指摘してくれた
使ったもの：Claude Opus 4.6 + AIエージェント基盤 + ブラウザ自動操作 + MoneyForward確定申告 + e-Tax
かかったコスト：MF月額 ¥380 + AI API 数千円程度

去年の記事：「あと少しのところまでできた」

去年（2025年3月）、同じく確定申告のAI化を試みた記事を書いた。

https://note.com/matsubokkuri/n/nc976d5258e37

去年のアプローチは Browser Use WebUI + OpenHands で、確定申告書等作成コーナーのUIをブラウザ自動操作で埋めようとした。結果は：

ダミーデータで所得入力ページまでは自動遷移できた
しかし 入力値が間違っている箇所が多い（指示した値と無関係な数字が入る）
5回トライしても所得入力ページで停止してしまう
結局、MFで帳簿を手動で作り、e-Taxのサイトでひとつずつ手入力した

去年の結論は「LLMが確定申告を行ってくれる未来はすぐそこに来ている」「来年にはできるようになっていそう」だった。

1年後の今年、本当にできた。

何が変わったのか：去年 → 今年

去年（2025年3月）と今年（2026年3月）で何が違うのか。

LLM: GPT-4 / Claude 3 → Claude Opus 4.6
ブラウザ操作: Browser Use WebUI（Playwright）→ AIエージェント基盤のブラウザ自動操作（CDP直接操作）
データ入力: 国税庁サイトのUIを直接操作（失敗）→ MFにCSVインポート + ブラウザ操作で補完
帳簿作成: 手動 → AIが約50件の複式簿記仕訳を自動生成
税務判断: LLMに個別質問 → エージェントが文脈を保持して通しで判断
ファイル解析: なし → PDF OCR、CSV解析、XML解析
結果: 所得入力で停止・手動完了 → e-Tax送信・納税まで完走

最大の違いは3つある。

1. マルチモーダル対応

領収書の写真、ローン明細書の画像、過去の確定申告書PDFをそのまま渡せる。去年は全部人間がテキストに起こす必要があった。

2. ローカルファイルアクセス

Google Driveにマウントした確定申告フォルダを直接読める。クレカCSV（Shift_JIS）も銀行CSVも、AIが自分で開いて解析する。去年はコピペでLLMに渡していた。

3. 常駐エージェント

セッションを跨いで文脈が維持される。「あの物件の取得年は？」「さっき計算した利息は？」が全部記憶されている。去年は毎回ゼロから説明し直していた。

背景

エンジニア歴20年超。給与所得だけなら会社の年末調整で完結するが、不動産所得があるため確定申告が必要になる。副業収入（広告・アフィリエイト等）も微々たるものながらあり、所得の種類が多いせいで申告だけは毎年それなりに面倒。

数年前までは税理士に依頼していたが、副業の収入に対して税理士報酬が10万円以上というのは本末転倒だし、結局こちら側の作業も多い。ある程度のノウハウを吸収したので自分でやるようになった。税理士に依頼していた時代の申告内容が過去データとして残っているので、最後にそれとの差分を確認すれば検証も楽。

数ヶ月前からAIエージェントを常駐させて日常的に使い始めていたので、今年はそのまま確定申告にも投入してみた。人間はほぼ意思決定と認証操作だけ、という体制で挑んだ。

申告の規模感

今回の確定申告の複雑さを伝えるために、項目だけ列挙する（金額は省略）。

所得の種類（6種類）：

給与所得（本業）
不動産所得（青色申告）
雑所得-業務（広告収入、アフィリエイト、OSS）
雑所得-その他（暗号資産・トークン取引）
株式譲渡所得（損益通算）

経費の種類：

不動産経費 9科目（利息、保険、減価償却、固定資産税、修繕費、外注費、車両費等）
雑所得経費多数（通信費、クラウドサービス、AI利用料、消耗品等）
事業按分（項目ごとに異なる）

控除：

社会保険料、iDeCo、生命保険料、医療費、ふるさと納税（複数自治体）

添付帳票：

申告書（第一表〜第四表）、付表、青色申告決算書（一般用+不動産所得用）、計14枚

なぜ確定申告がこんなに面倒なのか

所得が給与だけなら年末調整で終わる。しかし不動産所得、副業収入、株式譲渡、暗号資産が加わると、マイナポータル連携だけでは全然足りない。

今回の申告で扱ったデータソースを列挙する：

源泉徴収票（PDF）
クレカ年間利用明細（CSV・Shift_JIS）
銀行ローン返済明細（CSV・Shift_JIS）
固定資産税の領収書（写真）
ローン残高証明書（画像）
火災保険証券（XML）
ふるさと納税証明（XML）
特定口座年間取引報告書（XML）
生命保険料控除証明書（XML）
過去の確定申告書（PDF × 2年分）
暗号資産の取引履歴（取引所の画面）
アフィリエイト報酬画面

これらを突合して、複式簿記の仕訳帳を作り、青色申告決算書を作り、申告書の各欄に正しい数字を入れていく。手作業でやると丸1日〜2日かかる。

今年のブレイクスルー：控除関連のデータがXMLで一通りダウンロードできるようになったこと。ふるさと納税、特定口座、生命保険料——これらがXMLだとLLMが構造的に読めるので、手入力が大幅に減った。

人間が事前に用意したデータ

AIが勝手にデータを集めてくるわけではない。人間が各サービスからダウンロード・撮影して、Google Driveのフォルダに放り込むという下準備が必要。ここが実は一番時間がかかる。

Google Drive上に以下のフォルダ構成でデータを用意した：

tax/personal/2025 (R7)/
├── gensen/          ← 源泉徴収票（PDF）
├── credit_card/     ← クレカ年間明細（CSV + 月別PDF）
│   ├── 2025.csv         （Shift_JIS、全取引。事業按分の元データ）
│   └── pdf/             （月別利用明細PDF）
├── bank/            ← 銀行明細（ローン返済CSV、入金確認CSV 等）
├── stock/           ← 株式（特定口座XML + PDF + 売買CSV + 暗号資産取引CSV）
├── token/           ← トークン取引（CSV + スクショ）
├── furusato/        ← ふるさと納税（XML）
├── Insurance/       ← 保険（生命保険料控除証明書の写真、火災保険XML）
├── Loan/            ← ローン残高証明書（写真）
├── Tax/             ← 固定資産税の領収書（写真）
├── iryouhi/         ← 医療費の領収書（写真 + Googleスプレッドシート）
├── ad_revenue/      ← 広告収入の支払い画面（スクショ）
├── affiliate/       ← アフィリエイト報酬（CSV）
└── zz submit/       ← 最終提出物（xtx, PDF, 証明書XML）

合計80ファイル超。 これを集めるのに人間が使った時間は約1時間（各サービスにログインしてダウンロード・撮影）。

ポイントは以下の4つ。

XMLで取れるものはXMLで取る（ふるさと納税、特定口座、保険）。LLMが構造的に読めるし、MFにそのままインポートもできる
CSVで取れるものはCSVで取る（クレカ明細、銀行明細、アフィリエイト報酬）。LLMがパースして集計できる
紙の書類は撮影してHEICのまま放り込む（固定資産税、医療費、ローン証明書）。マルチモーダルLLMがそのまま読める
スクショで済むものはスクショ（広告収入の管理画面等）。PDF出力がない画面はこれで十分

去年との最大の違いは、写真やスクショをそのまま渡せるようになったこと。去年はこれを全部人間がテキストに起こしていた。クレカCSVも銀行CSVもShift_JISだが、AIが自分で文字コードを判定して読んでくれる。

構成

graph TD
    A["👤 人間（自分）<br/>意思決定・認証・物理作業"] -->|チャット（Telegram / TUI）| B["🤖 AIエージェント<br/>Claude Opus 4.6 on AIエージェント基盤"]
    B -->|ツール呼び出し| C["📁 ファイル読み書き"]
    B -->|ツール呼び出し| D["🌐 ブラウザ操作(CDP)"]
    B -->|ツール呼び出し| E["📄 PDF解析(OCR)"]
    B -->|ツール呼び出し| F["🔍 Web検索"]

ユースケース図

graph LR
    subgraph Actors
        Person["👤 人間"]
        AI["🤖 AIエージェント"]
    end

    subgraph "データソース"
        Receipt["📸 領収書・証明書<br/>（写真・PDF・XML）"]
        Transaction["📊 取引記録<br/>（CSV・明細）"]
        PrevTax["📄 過去の確定申告書<br/>（PDF）"]
    end

    subgraph "外部システム"
        MF["MoneyForward<br/>確定申告"]
        ETax["e-Tax<br/>Web版（Safari）"]
        Browser["🌐 Chrome<br/>（CDP操作）"]
    end

    Person -->|"データ収集・撮影"| Receipt
    Person -->|"ダウンロード"| Transaction
    Person -->|"意思決定・承認"| AI
    Person -->|"XMLアップロード"| MF
    Person -->|"xtxダウンロード"| MF
    Person -->|"xtxアップロード・認証・送信"| ETax

    AI -->|"OCR・解析"| Receipt
    AI -->|"パース・集計"| Transaction
    AI -->|"スコープ把握"| PrevTax
    AI -->|"仕訳CSV生成"| MF
    AI -->|"CDP経由で操作"| Browser
    Browser -->|"UI操作"| MF

    MF -->|"xtx生成"| Person

使用ツール

AIエージェント基盤: ツール実行、メモリ、セッション管理（ローカルマシン上で常駐）
Claude Opus 4.6: メインの頭脳（税務判断、計算、CSV解析、帳簿作成）
MoneyForward 確定申告: 複式簿記・決算書・申告書・xtx生成
e-Tax Web版: 電子申告の送信
ブラウザ自動操作（Chrome拡張）: MoneyForwardのブラウザUI操作（CDP経由。e-TaxはSafari必須のため対象外）
pdfminer: 過去の確定申告書PDFからのデータ抽出
Google Drive: 源泉徴収票、ローン明細、保険証券等の原本保管

タイムライン：3日間の流れ

Day 1（金曜夜）— データ収集・方針決定

人間の作業：30分

人間がやったこと：

Google Driveの確定申告フォルダのパスを伝えた
「2025年の確定申告やって」と指示
いくつかの質問に答えた（物件の取得年、法人との関係等）

AIがやったこと：

Google Drive上の全資料を読み込み・分類
源泉徴収票PDFの解析
クレカ年間CSV（Shift_JIS）の全明細読み込み・事業経費の候補抽出
銀行CSVからローン利息の集計
過去の確定申告書PDF（直近2年分）をOCRで読み取り、過去の申告内容を把握
収入源の一覧化と分類（給与/不動産/雑所得/株式/非課税の仕分け）

ここでのポイント：過去の確定申告書PDFを渡すこと。 これが最も重要な一手だった。AIは過去の申告書から所得の種類・経費科目・控除項目のスコープを自動的に把握し、「何を聞けばいいか」を理解する。これがないとAIはひとつずつ「不動産所得はありますか？」「株式は？」と質問してくる。過去の申告書があれば、AIが勝手に全体像を掴んでプランを立ててくれる。

Day 2（土曜）— 調査・計算・申告漏れの洗い出し

人間の作業：30分

人間がやったこと：

固定資産税の領収書を撮影してチャットに送った
「このサブスクは個人利用」「通信費の按分率はこれで」等の判断
経費項目の最終承認

AIがやったこと：

減価償却計算（耐用年数・取得価額・償却済み年数の調査）
過去10年分の申告データと照合して未計上経費の発見（固定資産税が2年間未計上だった）
領収書画像のOCR → 固定資産税を全期確定
ローンの金利変動を反映した利息再計算
事業按分率の提案と計算
法人→個人の請求書をPDF生成（管理委託料、車両使用料、修繕費）
税額の段階的試算（経費を追加するたびに再計算）
「外国税額控除は数千円の効果しかないのでスキップ」等の費用対効果判断

Day 3（日曜）— 帳簿作成・入力・提出

人間の作業：2時間

人間がやったこと：

MoneyForwardのアカウント契約（¥380/月）
ふるさと納税XMLのアップロード（CDPの制約でAIからはファイルアップロード不可）
マイナンバーの入力
マイナンバーカード認証（QRコード読み取り）
e-Tax送信（Safari必須のためブラウザ自動操作不可）
クレジットカード納付

AIがやったこと：

MoneyForward用の仕訳CSV（約50件・複式簿記）を自動生成
CSVインポート後の補助科目10件をブラウザ操作で一括登録
固定資産台帳の設定修正（不動産割合、事業供用開始日）
重複仕訳の検出・削除（React fiber経由でのDOM操作）
青色申告決算書の不動産収入内訳をブラウザ操作で入力
給与、雑所得、暗号資産、控除（6種類）をブラウザ操作で入力
株式（分離課税）のXMLインポート確認
配偶者情報の入力
最終チェック（PDFをOCR → 全項目を期待値と突合）
xtxダウンロード
xtxの最終チェック

AIがブラウザを操作する

今回の肝は、AIがMoneyForwardのWebUIを CDP（Chrome DevTools Protocol）経由で直接操作 した点。

MFのUIはReact製のSPAで、普通のセレクタではうまく動かない箇所が多い。AIは以下のようなテクニックを自力で編み出して対処していた：

MUI Selectコンポーネント：.MuiSelect-select に mousedown イベントを発火 → ドロップダウンが開く → .MuiMenuItem-root をクリック
React制御のinput：HTMLInputElement.prototype.value の setter で値を設定 → input + change イベントを発火
仕訳の削除：React fiber を辿って processing.dropdownMenu.onClickDeleteButton() を直接呼び出し

人間が手動でやれば30分の入力作業を、AIが試行錯誤しながら1〜2時間かけて自動化した。時間だけ見ると効率が悪いが、人間の手が空くのが重要。AIが入力している間、自分は別のことをしていた。

e-Tax Web版が動かない問題

提出段階で最大のトラブルが発生。e-Tax Web版（clientweb.e-tax.nta.go.jp）にログインしても、メインコンテンツが完全に空白で何も操作できない。

Safari → ダメ。Chrome → ダメ。ポップアップ許可 → ダメ。

開発者ツールのコンソールを確認したところ、原因が判明した：

Failed to load resource: 404 (Not Found)
  → /nls/etaxweb_dlparts_en-us.js

Error: Could not load 'dojo.nls.etaxweb_dlparts_en-us'

e-Tax Web版はDojo Toolkit（JavaScriptフレームワーク）を使っていて、ブラウザの Accept-Language ヘッダーから言語を判定し、対応するNLS（National Language Support）ファイルを読み込む。しかし en-us 用のファイルが存在しない。

自分のMacは en-JP（英語UIで日本リージョン）に設定していたため、Dojoが英語リソースを探して404になり、画面描画が停止していた。

修正：

defaults write com.apple.Safari AppleLanguages '("ja-JP", "ja", "en-JP", "en")'

Safari再起動で即解決。確定申告期限前日に国税庁のUIバグで提出できないというのは洒落にならない。英語環境のMacユーザーは要注意。

AIによる申告漏れ・計上漏れの発見

今回最も価値があったのは、AIが経費や控除の漏れを自発的に指摘してくれたこと。人間が「これ経費にできる？」と聞くのではなく、AIがデータを分析して「これ計上してないけど、経費にできるのでは？」と提案してくる。

AIが発見した主な申告漏れ・計上漏れ：

過去に計上漏れしていた経費の発見：過去の確定申告書PDFと今年の経費を突合して、計上すべきだった経費の漏れを指摘。
減価償却の状態整理：取得年・構造・耐用年数を調べ、償却完了済みかまだ残っているかを正確に仕分け。
事業按分の提案：クレカCSVの全明細から事業関連の支出を抽出し、項目ごとに按分率を提案。
経費の追加候補：「AI利用料（Claude/ChatGPT）は雑所得の経費にできる」「実験用機材の購入も消耗品費として計上可能」等、人間が見落としていた項目を提案。
費用対効果の判断：「外国税額控除は数千円の効果しかないのでスキップ」「この控除証明書は自宅用で事業関係なし」等、やらなくていいことも明確にしてくれた。

これは税理士に頼んでも同じようなアドバイスをもらえるが、AIは全データを読んだ上で網羅的に指摘するので、見落としが少ない。しかもコストはAPI利用料数千円。

人間 vs AI の分担まとめ

大きな流れはこうだ：

序盤（データ収集）→ 人間：各サービスにログインしてCSV・PDF・XMLをダウンロード、領収書を撮影してGoogle Driveに放り込む
中盤（帳簿作成・申告書入力）→ AI：仕訳の自動生成、MFへのブラウザ操作での入力、控除・経費の計算
終盤（提出・納税）→ 人間：e-Tax送信（Safari必須）、マイナンバーカード認証、納税

加えて、途中で「納税額の概算はいくら？」と聞けば即座に試算してくれるし、「この経費は計上してないけど入れたほうがいいのでは？」と申告漏れの候補を自発的に提案してくれる。これが税理士不要で数千円のAPI利用料で得られるのは非常に大きい。

具体的な分担は以下の通り。

資料の収集・整理 → AI（ファイルシステム+PDF解析で自動化）
経費の分類・按分率決定 → AI提案→人間承認（税務判断はAIが提案、最終判断は人間）
帳簿（複式簿記）の作成 → AI（CSV自動生成 → MFインポート）
MFへの入力 → AI（ブラウザ操作）（CDP経由でReact UIを操作）
XMLデータのアップロード → 人間（CDPのセキュリティ制約でファイルアップロード不可）
マイナンバー入力 → 人間（機密情報の直接入力）
最終レビュー → AI（PDF OCRで全項目を期待値と突合）
e-Tax認証・送信 → 人間（マイナンバーカード認証にSafariが必須のため、ブラウザ自動操作の対象外）

納税 → 人間（クレジットカード決済）

人間の実作業時間の内訳：

作業	時間
データ準備（撮影・ダウンロード・Google Driveに保存）	約1.5時間
AIとの対話（方針決定・承認・質問回答）	約1時間
MoneyForward操作（契約・アップロード等）	約0.5時間
e-Taxのデバッグ（言語設定問題の解決）	約3時間
e-Tax送信・納税	約0.5時間
合計	約6.5時間

e-Taxのバグに3時間取られなければ約3.5時間で完了していた。

来年への改善メモ

MFの契約を忘れず解約する（毎年1ヶ月だけ契約）
納税方法の比較：クレカ納付の手数料 vs ポイント還元率を確認して選択（高還元率カードならクレカ有利）
e-Tax Web版はSafariの言語設定を ja-JP にしてから使う
ふるさと納税XMLのアップロードを自動化できるとさらに省力化
固定資産税の領収書は届いた時点で撮影・Drive保存を習慣化
開業届を検討：雑所得→事業所得への移行で損益通算が可能に
今回の確定申告の内容をスキル化しておく：AIエージェントに「今回の申告内容を来年用にスキルとして保存して」と依頼しておけば、知識が圧縮されて来年はゼロからの質問がなくなる。変わった部分の差分だけ補完すればよい

まとめ：去年の予言は当たった

去年の記事の結論はこうだった：

LLMが確定申告を行ってくれる未来はすぐそこに来ている気がします。来年(2026年)にはできるようになっていそうな気がします。

1年でここまで変わった：

帳簿作成: 手動 → AI自動生成（約50仕訳）
申告書入力: 手動 → AI（ブラウザ操作）
人間の作業時間: 2日 → 3時間
AI活用度: 5%（仕訳の相談程度）→ 85%（データ収集→計算→入力→チェック→提出補助）

去年は「AIに聞きながら人間が作業」。今年は「AIが作業して人間が承認」。主従が完全に逆転した。

AIエージェントを使った確定申告は、「AIに丸投げ」ではなく「AIが下準備・入力・チェックを担当し、人間は意思決定と認証だけ」という分業モデルだ。

一番面倒な「散在するデータを集めて、正しい科目に分類して、正しい金額を計算して、正しい欄に入力する」という作業がほぼ自動化できた。人間がやるのはマイナンバーカードをかざすことと、「これは経費？」「按分率は？」という判断だけ。

今年の実績：

🕐 人間の作業時間：約3.5時間（e-Taxバグ除く）
🤖 AIの稼働：データ収集→計算→入力→チェックを自動化
💡 AIが発見した申告漏れ・計上漏れ：多数（経費計上漏れ、減価償却整理、経費追加候補等）
💸 コスト：MF ¥380のみ（AI APIは既存契約内で追加費用なし）

確定申告は「毎年同じような作業を、微妙に変わるルールで、締め切りに追われながらやる」典型的なタスク。AIエージェントとの相性は非常に良い。

来年はもっと楽になるはず。（去年も同じこと言ってたけど、今年は本当にそう思う。）

去年までは確定「深刻」だったが、今年からは深刻ではなくなった。

Coolify環境のバックアップ戦略：6つのDBを自動ダンプ+復旧手順

Sun, 15 Mar 2026 00:00:00 GMT

概要

6つのデータベース（PostgreSQL×2、MySQL×1、MariaDB×3）のダンプを毎日自動実行
バックアップ先は mergerfs + snapraid で冗長化されたストレージプール（7.2TB、3ドライブ構成）
Coolifyの設定データ（/data/coolify）もバージョニング付きで保存
復旧手順を文書化して、災害時に「何をすればいいか」を明確にしました

第6回でZabbixによるリソース監視を構築しました。コンテナが「今どうなっているか」は見えるようになりました。次に必要なのは、「壊れたときにどう戻すか」。

バックアップ対象の棚卸し

まず、何をバックアップすべきかを整理しました。

データベース一覧

現在のCoolify環境で稼働中のデータベースコンテナ。

コンテナ	エンジン	サイズ	用途
coolify-db	PostgreSQL 15	42 MB	Coolify設定データ
immich-database	PostgreSQL 14 + pgvector	1.2 GB	写真管理（Immich）
Zabbix MySQL	MySQL LTS	6.6 GB	監視データ（Zabbix）
WordPress共有DB	MariaDB 11.7	678 MB	WordPress 2サイト
AI Moderator DB	MariaDB 11	3.1 GB	AI Moderator + LipSync
WordPress個別DB	MariaDB 11	162 MB	WordPress（teraren.com）

合計約12GBです。毎日のフルダンプでも十分に現実的なサイズです。

その他のバックアップ対象

対象	場所	重要度
Coolify設定	`/data/coolify`	最重要 — アプリ定義、環境変数、秘密鍵すべて
Docker volumes	`/var/lib/docker/volumes/`	100+ボリューム。DBは個別ダンプするので、それ以外
Zabbix agent設定	`/etc/zabbix/`	設定ファイル。手動で再現可能だが保存しておく
cloudflared設定	`/etc/cloudflared/`	Tunnel設定。トークンが入っている
crontab	`crontab -l`	定期実行ジョブの定義

バックアップ先のストレージ構成

mergerfs + snapraid

バックアップ先として、すでに構築済みの mergerfs + snapraid ストレージプールを使います。

/mnt/data1 (3.6TB HDD) ─┐
/mnt/data2 (1.8TB HDD) ─┼─ mergerfs ─→ /mnt/storage (7.2TB pool)
/mnt/data3 (1.8TB HDD) ─┘
/mnt/parity (parity disk) ─→ snapraid parity

項目	値
総容量	7.2 TB
使用済み	1.6 TB（22%）
空き容量	5.5 TB
パリティ	1ドライブ（1台故障まで復元可能）
作成ポリシー	epmfs（最も空き容量の多いドライブに配置）

mergerfsの利点：

複数ドライブを1つのマウントポイントに統合。アプリからは単一パスに見えます
JBODなので、1台が壊れても他のドライブのデータは無事

snapraidの利点：

パリティドライブで1台分の冗長性を確保
常時同期ではなく定期実行。省電力
既存データの保護に特化（追記メインのバックアップに最適）

バックアップスクリプト

設計方針

データベースはロジカルダンプ（pg_dump、mysqldump）。バイナリコピーは復元が面倒
世代管理は7日分。古いダンプは自動削除
Coolify設定は rsync。差分コピーで高速
ログを残す。成功・失敗がわかるように

スクリプト全体

/home/matsu/bin/coolify-backup.sh:

#!/bin/bash
set -euo pipefail

# === 設定 ===
BACKUP_BASE="/mnt/storage/coolify-backups"
DATE=$(date +%Y%m%d_%H%M%S)
RETENTION_DAYS=7
LOG_FILE="${BACKUP_BASE}/backup.log"

mkdir -p "${BACKUP_BASE}/db" "${BACKUP_BASE}/coolify-config" "${BACKUP_BASE}/system-config"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"
}

log "=== バックアップ開始 ==="

# === 1. PostgreSQL ダンプ ===
log "PostgreSQL: coolify-db"
docker exec coolify-db pg_dumpall -U coolify \
    | gzip > "${BACKUP_BASE}/db/coolify-db_${DATE}.sql.gz"

log "PostgreSQL: immich-database"
IMMICH_DB=$(docker ps --format '{{.Names}}' | grep immich-database)
docker exec "$IMMICH_DB" pg_dumpall -U postgres \
    | gzip > "${BACKUP_BASE}/db/immich-db_${DATE}.sql.gz"

# === 2. MySQL / MariaDB ダンプ ===
# Zabbix MySQL
ZABBIX_MYSQL=$(docker ps --format '{{.Names}}' | grep -E '^fswk')
log "MySQL: Zabbix ($ZABBIX_MYSQL)"
docker exec "$ZABBIX_MYSQL" mysqldump -u root --all-databases --single-transaction \
    | gzip > "${BACKUP_BASE}/db/zabbix-mysql_${DATE}.sql.gz"

# WordPress 共有 MariaDB
WP_SHARED_DB=$(docker ps --format '{{.Names}}' | grep -E '^fqff')
log "MariaDB: WordPress共有 ($WP_SHARED_DB)"
docker exec "$WP_SHARED_DB" mariadb-dump -u root --all-databases --single-transaction \
    | gzip > "${BACKUP_BASE}/db/wp-shared-db_${DATE}.sql.gz"

# AI Moderator MariaDB
log "MariaDB: AI Moderator"
docker exec ai-moderator-lipsync-db-1 mariadb-dump -u root --all-databases --single-transaction \
    | gzip > "${BACKUP_BASE}/db/ai-moderator-db_${DATE}.sql.gz"

# WordPress 個別 MariaDB
WP_TERA_DB=$(docker ps --format '{{.Names}}' | grep -E '^p8sg')
log "MariaDB: WordPress teraren ($WP_TERA_DB)"
docker exec "$WP_TERA_DB" mariadb-dump -u root --all-databases --single-transaction \
    | gzip > "${BACKUP_BASE}/db/wp-teraren-db_${DATE}.sql.gz"

# === 3. Coolify 設定ディレクトリ ===
log "Coolify設定: /data/coolify"
sudo rsync -a --delete /data/coolify/ "${BACKUP_BASE}/coolify-config/"

# === 4. システム設定 ===
log "システム設定のバックアップ"
sudo cp -r /etc/zabbix/ "${BACKUP_BASE}/system-config/zabbix/" 2>/dev/null || true
sudo cp -r /etc/cloudflared/ "${BACKUP_BASE}/system-config/cloudflared/" 2>/dev/null || true
crontab -l > "${BACKUP_BASE}/system-config/crontab.txt" 2>/dev/null || true

# === 5. 古いバックアップの削除 ===
log "古いバックアップの削除 (${RETENTION_DAYS}日以上)"
find "${BACKUP_BASE}/db" -name "*.sql.gz" -mtime +${RETENTION_DAYS} -delete

# === 6. サイズ確認 ===
TOTAL_SIZE=$(du -sh "${BACKUP_BASE}" | cut -f1)
log "バックアップ完了。合計サイズ: ${TOTAL_SIZE}"
log "=== バックアップ終了 ==="

crontab への登録

毎日 AM 4:00 に実行：

# Coolify環境の全DBバックアップ + 設定バックアップ
0 4 * * * /home/matsu/bin/coolify-backup.sh >> /tmp/coolify-backup.log 2>&1

復旧手順

バックアップは取るだけでは意味がありません。「壊れたときに何をするか」 が明確でないと、パニック時に役に立ちません。

ケース1: データベースの破損

特定のデータベースだけが壊れた場合。

# 最新のダンプを確認
ls -lt /mnt/storage/coolify-backups/db/ | head -10

# PostgreSQL の復元（例: coolify-db）
gunzip -c /mnt/storage/coolify-backups/db/coolify-db_YYYYMMDD_HHMMSS.sql.gz \
    | docker exec -i coolify-db psql -U coolify

# MariaDB の復元（例: WordPress）
gunzip -c /mnt/storage/coolify-backups/db/wp-shared-db_YYYYMMDD_HHMMSS.sql.gz \
    | docker exec -i <container_name> mariadb -u root

ケース2: Coolifyの再インストール

サーバは生きているが、Coolify自体が壊れた場合。

# 1. Coolify を再インストール
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

# 2. 設定を復元
sudo systemctl stop coolify
sudo rsync -a /mnt/storage/coolify-backups/coolify-config/ /data/coolify/
sudo systemctl start coolify

# 3. データベースの復元は不要（設定に含まれている）

ケース3: サーバの全損

ハードウェア故障でOSごと失った場合。

# 1. 新しいサーバにOSをインストール（Debian/Ubuntu）
# 2. mergerfsストレージをマウント（HDDが無事であれば）
# 3. Coolify をインストール
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

# 4. 設定を復元
sudo rsync -a /mnt/storage/coolify-backups/coolify-config/ /data/coolify/

# 5. 各データベースを順番に復元
for dump in /mnt/storage/coolify-backups/db/*_latest.sql.gz; do
    echo "Restoring: $dump"
    # DB種類に応じて pg_restore or mysql で復元
done

# 6. cloudflared を再設定
sudo cp -r /mnt/storage/coolify-backups/system-config/cloudflared/ /etc/cloudflared/
sudo systemctl restart cloudflared

# 7. Zabbix agent を再設定
sudo cp -r /mnt/storage/coolify-backups/system-config/zabbix/ /etc/zabbix/
sudo systemctl restart zabbix-agent2

ケース4: snapraid ドライブ障害

mergerfsプール内の1台が故障した場合。

# 1. 故障したドライブを特定
sudo smartctl -a /dev/sdX

# 2. 新しいドライブを同じマウントポイントにマウント
# 3. snapraid fix で復元
sudo snapraid fix -d dN

# 4. パリティを再構築
sudo snapraid sync

バックアップの検証

バックアップは「取っている」だけでは不十分です。定期的に復元テストをすべきです。

簡易チェック（毎日）

バックアップスクリプトのログで、ファイルサイズがゼロでないことを確認。

# ダンプファイルが空でないか確認
find /mnt/storage/coolify-backups/db/ -name "*.sql.gz" -size 0 -print
# 出力がなければOK

復元テスト（月1回推奨）

# テスト用コンテナでダンプを読み込んでみる
docker run --rm -i postgres:15-alpine psql -U postgres < test_dump.sql

オフサイトバックアップ（将来の拡張）

現在のバックアップは同一サーバ内の別ドライブです。火事や盗難には対応できません。将来的には：

方式	コスト	特徴
Backblaze B2	~$0.5/月（12GB）	安い。S3互換API
rclone + Google Drive	$0（15GBまで）	無料枠で収まる
物理メディア（USB HDD）	初期費用のみ	最もシンプル。月1回持ち出し

12GBのDBダンプなら、Backblaze B2で月$0.5以下です。導入するなら rclone でスクリプトに1行追加するだけです。

まとめ

対象	方式	頻度	保持期間
データベース（6つ）	ロジカルダンプ + gzip	毎日 AM 4:00	7日分
Coolify設定	rsync	毎日 AM 4:00	最新のみ（差分）
システム設定	ファイルコピー	毎日 AM 4:00	最新のみ
ストレージ冗長化	snapraid parity	定期sync	パリティ1台分

バックアップは「やらなきゃ」と思いつつ後回しにしがちです。でも、第6回でsentinelが5.2GBメモリを食っていたことを発見したように、見えていないリスクは常にあります。バックアップスクリプト1本と、復旧手順の文書化。これだけで「壊れても戻せる」安心感が手に入ります。

シリーズ記事

Vercel月額$42→自宅サーバ月額$0。Coolifyで個人サービス基盤を作った話
Coolifyインストールから「プロンプトでデプロイ」まで：Claude Code MCP実践
Coolifyハンズオン：Hono・Go・Railsを実際にデプロイしてみる
Cloudflare Tunnel×Coolify：自宅サーバを安全に外部公開する
API-firstなインフラが生き残る：LLM時代のセルフホスト戦略
ZabbixでDockerコンテナをリソース監視する：Coolify環境の可視化
Coolify環境のバックアップ戦略：6つのDBを自動ダンプ+復旧手順（この記事）
Coolify環境のログ管理と障害対応：Docker + Zabbix + Discordで運用を回す

Coolify環境のログ管理と障害対応：Docker + Zabbix + Discordで運用を回す

Sun, 15 Mar 2026 00:00:00 GMT

概要

Docker json-file ドライバのログローテーション設定で、ディスク溢れを防止
Zabbix → Discord Webhookで障害をリアルタイム通知
実際に発生した障害（MySQL停止、swap圧迫、SSL証明書エラー）の対応事例
journald + docker logs + Zabbixの3層で「何が起きているか」を把握する運用フロー

第6回でリソース監視、第7回でバックアップ戦略を構築しました。最後のピースは 「何か起きたとき、どう気づいて、どう対応するか」 です。

ログの全体像

Coolify環境には3つのログソースがあります。

レイヤー	ソース	確認方法	主な用途
OS	systemd journald	`journalctl -u <service>`	cloudflared、zabbix-agent2
コンテナ	Docker json-file	`docker logs <container>`	アプリログ、DBログ
監視	Zabbix	Web UI / API	トリガー、アラート履歴

この3つを組み合わせて「何が起きているか」を把握します。

Docker ログローテーション

デフォルトの罠

Dockerのデフォルトログドライバは json-file で、ローテーションなしです。放置するとログファイルが際限なく膨らんでディスクを食い潰します。30+コンテナが動いている環境では致命的です。

設定

/etc/docker/daemon.json でグローバルに設定済みです。

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

設定	値	意味
`max-size`	10m	1ファイル最大10MB
`max-file`	3	最大3ファイル保持
コンテナあたり上限	30MB	10MB × 3ファイル
全体上限（30コンテナ）	約900MB	十分に制御可能

この設定がないと、ログが活発なコンテナ（Railsアプリ、Traefik）で数GBに膨らむことがあります。

確認方法

# 各コンテナのログサイズ確認
sudo du -sh /var/lib/docker/containers/*/

アラート通知：Zabbix → Discord

なぜDiscordなのか

通知先	コスト	セットアップ	モバイル通知
Email	無料	SMTPサーバ必要	△
Slack	無料枠あり	Webhook簡単	✅
Discord	無料	Webhook簡単	✅
Telegram	無料	Bot作成必要	✅
PagerDuty	有料	エンタープライズ向け	✅

個人開発者にとって、Discordが最適解です。無料、Webhook作成が30秒、スマホ通知あり、メッセージの色分け（Severity）にも対応しています。

Discord Webhook の設定

Discordサーバーで「サーバー設定 → 連携サービス → ウェブフック」
「新しいウェブフック」を作成。チャンネルは #alerts 等
Webhook URLをコピー

Zabbix側の設定

ZabbixにはDiscordメディアタイプが標準搭載されています。

Alerts → Media types → Discord を開く（status: Enabled）
Trigger actionsを作成：
- Alerts → Actions → Trigger actions → Create action
- Conditions: Trigger severity >= Warning
- Operations: Send to Discord（Admin userのMedia設定にDiscord Webhook URLを追加）

通知の内容

Zabbixの標準Discord Webhookは、Severity に応じた色分け付きで通知されます。

Severity	色	例
Information	青	コンテナ再起動検知
Warning	黄	swap使用率 > 50%
Average	オレンジ	コンテナ停止
High	赤	MySQLダウン
Disaster	濃赤	サーバー到達不能

実際に発生した障害事例

監視を入れたことで、実際にいくつかの問題を検知・対応できました。

事例1: MySQL停止（High）

問題: MySQL: Service is down
ホスト: gmk
継続時間: 6日以上

WordPressの旧MySQL（移行前のレガシーDB）が停止していました。Coolifyのリソース画面でも Exited 表示です。現在は使っていないDBなので、意図的に停止したまま放置していますが、監視がなければ「本番DBが落ちていた」場合に気づけませんでした。

対応: Zabbixでこのトリガーをacknowledgeし、不要ならコンテナを削除します。

事例2: swap圧迫（Warning）

問題: Linux: High swap space usage (less than 50% free)
ホスト: gmk
継続時間: 2日以上

32GB RAMの環境でswapが圧迫されています。第6回で発見したcoolify-sentinelの5.2GBメモリ使用が主因です。30+コンテナの合計メモリ使用量がRAMを超え始めています。

対応: sentinel以外のメモリ消費を確認し、不要なコンテナを停止しました。長期的にはRAM増設（64GB）を検討しています。

事例3: SSL証明書エラー（Traefik）

Traefik（coolify-proxy）のログに繰り返しエラーが出ていました。

ERR Unable to obtain ACME certificate for domains
    domains=["coolify.teraren.com"]
    error="too many failed authorizations"

原因: Cloudflare Access（Zero Trust）でcoolify.teraren.comを保護しているため、Let's EncryptのHTTP-01チャレンジがCloudflare Accessのログインページにリダイレクトされて認証に失敗します。

対応: Cloudflare Tunnel経由のサービスはCloudflare側でSSL終端するため、Traefik側のLet's Encrypt証明書は不要です。第4回で説明した通り、CoolifyのドメインはHTTPで設定します。このエラーは無視して問題ありません。

事例4: コンテナの異常再起動

問題: Docker: Container /immich: Container has restarted 11 times
ホスト: gmk

Immich（写真管理）のコンテナが11回再起動していました。Coolifyのリソース画面でも (11x restarts) と表示されています。

対応: docker logs でImmichのログを確認しました。メモリ不足でOOM Killerに殺されていました。Immichのメモリ制限を調整しました。

障害対応フロー

障害が発生したときの対応手順を標準化しておきます。

1. Discord通知を受信
   ↓
2. Zabbix Web UIで詳細確認
   - どのホスト？どのトリガー？いつから？
   ↓
3. ログ確認
   - OS系: journalctl -u <service> --since "1 hour ago"
   - コンテナ系: docker logs --tail 100 <container>
   - Traefik: docker logs coolify-proxy --tail 50
   ↓
4. 対応
   - コンテナ再起動: docker restart <container>
   - Coolify経由: Coolify UI → アプリ → Restart
   - 設定変更: Coolify UI or MCP経由
   ↓
5. 確認
   - Zabbixでトリガーが解消されたか確認
   - アプリにアクセスして正常動作を確認

よく使うログコマンド

# === OS サービス ===
# cloudflaredのログ（Tunnel障害時）
journalctl -u cloudflared --since "1 hour ago" --no-pager

# zabbix-agentのログ
journalctl -u zabbix-agent2 --since "1 hour ago" --no-pager

# === Docker コンテナ ===
# 特定コンテナの最新ログ
docker logs --tail 100 <container_name>

# リアルタイムログ（Ctrl+Cで終了）
docker logs -f <container_name>

# タイムスタンプ付き
docker logs --tail 50 -t <container_name>

# === 横断的な確認 ===
# 全コンテナの状態一覧
docker ps --format "table {{.Names}}\t{{.Status}}\t{{.RunningFor}}"

# 異常終了したコンテナ
docker ps -a --filter "status=exited" --format "table {{.Names}}\t{{.Status}}"

# ディスク使用量
docker system df

Coolify UIのログ機能

CoolifyのWeb UIにもログ表示機能があります。各アプリの詳細画面 → Logsタブで、コンテナログをブラウザから確認できます。

方法	用途
Coolify UI → Logs	ブラウザから手軽に確認。外出先でも
`docker logs`	詳細な検索。grep等でフィルタ
Zabbix	異常検知・アラート。過去のイベント履歴

普段はZabbixのアラートで異常に気づき、Coolify UIかdocker logsで詳細を確認する流れです。

まとめ

要素	構成	目的
ログローテーション	Docker json-file 10MB×3	ディスク溢れ防止
アラート通知	Zabbix → Discord Webhook	リアルタイムで障害検知
ログ確認	journald + docker logs + Coolify UI	原因調査
障害対応	標準化されたフロー	パニックせずに対応

セルフホストの運用は「監視 → アラート → ログ確認 → 対応」のサイクルを回すことが大切です。Zabbix（第6回）で監視し、Discordで通知を受け、docker logsで原因を調べ、Coolify UIかMCPで対応します。バックアップ（第7回）があれば、最悪の場合でも復旧できます。

このシリーズで構築した環境の全体像：

GitHub Push → Coolify（自動ビルド&デプロイ）
                ↕
         Cloudflare Tunnel（外部公開）
                ↕
         Zabbix（監視） → Discord（通知）
                ↕
         mergerfs + snapraid（バックアップ）

Vercel月額$42から始まった話が、月額$0で監視・バックアップ・アラート通知まで揃った自宅PaaS環境になりました。

シリーズ記事

Vercel月額$42→自宅サーバ月額$0。Coolifyで個人サービス基盤を作った話
Coolifyインストールから「プロンプトでデプロイ」まで：Claude Code MCP実践
Coolifyハンズオン：Hono・Go・Railsを実際にデプロイしてみる
Cloudflare Tunnel×Coolify：自宅サーバを安全に外部公開する
API-firstなインフラが生き残る：LLM時代のセルフホスト戦略
ZabbixでDockerコンテナをリソース監視する：Coolify環境の可視化
Coolify環境のバックアップ戦略：6つのDBを自動ダンプ+復旧手順
Coolify環境のログ管理と障害対応：Docker + Zabbix + Discordで運用を回す（この記事）

ZabbixでDockerコンテナをリソース監視する：Coolify環境の可視化

Sun, 15 Mar 2026 00:00:00 GMT

概要

Zabbix agent 2 + Docker テンプレートで、コンテナ単位のCPU・メモリ・ネットワークを自動検出・監視
Coolify環境の30+コンテナのリソース使用量を可視化するダッシュボードを構築
「メモリ食いすぎコンテナ」や「CPU使用率の異常スパイク」を検知できるようになりました

第5回までで、Coolify + Cloudflare Tunnelの基盤は完成しました。でも、監視がなければ運用とは呼べません。 30個以上のコンテナが動いていて、どれがどれだけリソースを使っているか見えないのは怖いです。

なぜZabbixなのか

監視ツールの選択肢はいくつかあります。

ツール	特徴	セルフホスト	API
Zabbix	エンタープライズ級。テンプレート豊富	✅	✅ REST API
Prometheus + Grafana	メトリクス特化。Kubernetes向き	✅	✅
Datadog	SaaS。簡単だが高い	✗	✅
Uptime Kuma	死活監視特化。軽量	✅	△

Zabbixを選んだ理由：

Dockerコンテナの自動検出（LLD） が標準テンプレートでできます
SNMP対応 でルーター（RTX1200）やNAS（QNAP）も同じ画面で監視できます
REST APIがある から第5回で書いた「API-first」の基準を満たします
Coolifyでデプロイできます。Dockerイメージが公式で提供されています

Zabbixの構成

Coolifyでデプロイ済みのZabbix構成。Docker Composeで3コンテナ。

services:
  zabbix-server:
    image: zabbix/zabbix-server-mysql:alpine-7.4-latest
    ports:
      - "10051:10051"
    environment:
      - DB_SERVER_HOST=mysql
      - MYSQL_DATABASE=zabbix

  zabbix-web:
    image: zabbix/zabbix-web-nginx-mysql:alpine-7.4-latest
    environment:
      - ZBX_SERVER_HOST=zabbix-server
      - PHP_TZ=Asia/Tokyo

  mysql:
    image: mysql:8.0
    volumes:
      - mysql-data:/var/lib/mysql

ポイントは、Zabbix Server自体はCoolifyのDockerネットワーク内で動いていること。監視対象のコンテナと同じホスト上にいるから、Zabbix agentで直接Dockerソケットにアクセスできます。

Dockerコンテナ監視の設定

1. Zabbix agent 2のインストール

Zabbix agent 2はホストOS側にインストールする必要があります。コンテナ内からDockerソケットにアクセスするのは設定が面倒なので、ホストに直接入れた方がシンプルです。

# Debian/Ubuntu
wget https://repo.zabbix.com/zabbix/7.4/release/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.4+ubuntu24.04_all.deb
sudo dpkg -i zabbix-release_latest_7.4+ubuntu24.04_all.deb
sudo apt update
sudo apt install zabbix-agent2 zabbix-agent2-plugin-*

2. Dockerソケットへのアクセス権設定

# zabbix ユーザーを docker グループに追加
sudo usermod -aG docker zabbix

# agent2 を再起動
sudo systemctl restart zabbix-agent2

3. Zabbix agent 2 の設定

/etc/zabbix/zabbix_agent2.conf の主要設定：

Server=172.16.238.1        # Zabbix ServerのIPアドレス
ServerActive=172.16.238.1
Hostname=gmk               # ホスト名

172.16.238.1 はCoolifyのDockerネットワーク（coolify bridge）のゲートウェイIP。Zabbix ServerコンテナからホストのAgent 2に接続するため、このアドレスを使います。

4. 「Docker by Zabbix agent 2」テンプレートの適用

Zabbix Web UI → Data Collection → Hosts → 対象ホスト → Templates で 「Docker by Zabbix agent 2」 を追加。

これだけで、ホスト上のすべてのDockerコンテナが自動検出（LLD: Low-Level Discovery） されます。

自動検出されるメトリクス

1コンテナあたり約100個のメトリクスが自動で収集されます。

カテゴリ	主なメトリクス
CPU	CPU使用率（%）、ユーザーモード/カーネルモード使用時間
メモリ	使用量、最大使用量、制限値、キャッシュ、RSS
ネットワーク	受信/送信バイト数、パケット数、ドロップ数、エラー数
ブロックI/O	読み取り/書き込みバイト数
状態	起動時刻、ステータス（running/stopped/paused）

30コンテナ × 100メトリクス = 約3,000データポイント が自動で監視されます。手動で設定する必要はありません。

ダッシュボードの構築

Zabbix APIでダッシュボード作成

第5回で「API-firstが重要」と書きましたが、まさにここでその恩恵を受けます。ダッシュボードをGUIでポチポチ作るのではなく、APIで一発で作成しました。

curl -s -X POST https://zabbix.teraren.com/api_jsonrpc.php \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer <TOKEN>' \
  -d '{
    "jsonrpc": "2.0",
    "method": "dashboard.create",
    "params": {
      "name": "Docker Containers",
      "pages": [{
        "widgets": [
          {"type":"graph","name":"Coolify: CPU",
           "x":0,"y":0,"width":36,"height":5,
           "fields":[{"type":6,"name":"graphid","value":"5862"}]},
          {"type":"graph","name":"Coolify: Memory",
           "x":36,"y":0,"width":36,"height":5,
           "fields":[{"type":6,"name":"graphid","value":"5867"}]}
        ]
      }]
    },
    "id": 1
  }'

作成したダッシュボードには、Coolify本体・Traefik Proxy・PostgreSQL・Sentinelのコンテナのリソースグラフを配置しました。

可視化で見えてきたこと

ダッシュボードを見て気づいたことがいくつかあります。

コンテナ	メモリ使用量	気づき
coolify-sentinel	5.2 GB	Coolifyの全コンテナヘルスチェックを担当。メモリ食いすぎ
coolify	178 MB	Laravel アプリ本体。妥当
coolify-proxy (Traefik)	84 MB	リバースプロキシ。軽量
coolify-redis	81 MB	セッション・キャッシュ。妥当
coolify-realtime	55 MB	WebSocket。妥当
coolify-db (PostgreSQL)	44 MB	設定データのみ。軽量

coolify-sentinelが5.2GBも使っているのは監視なしでは絶対に気づけませんでした。30+コンテナのヘルスチェックを常時回しているからでしょうけど、32GBのRAMのうち16%を1つのヘルスチェッカーが使っているのは気になります。

アラート設定

コンテナ監視のアラートは「Docker by Zabbix agent 2」テンプレートに最初から含まれています。

トリガー	条件	重要度
Container stopped	コンテナが停止	Average
High memory usage	メモリ使用率 > 90%	Warning
Container restart detected	再起動を検知	Information

追加でカスタムトリガーを設定する場合は、Zabbix APIでも可能です。

まとめ

Zabbix + Docker by Zabbix agent 2 テンプレートで、設定ほぼゼロでコンテナ単位のリソース監視ができます。3,000以上のメトリクスが自動収集されて、ダッシュボードで可視化できます。sentinelの5.2GBメモリ問題のように、監視しないと絶対に気づけない問題が見つかります。

Coolifyの「API-first」思想は、監視との組み合わせでさらに威力を発揮します。「プロンプトでデプロイして、ダッシュボードで監視する」。これがセルフホストの運用ルーティンです。

シリーズ記事

Vercel月額$42→自宅サーバ月額$0。Coolifyで個人サービス基盤を作った話
Coolifyインストールから「プロンプトでデプロイ」まで：Claude Code MCP実践
Coolifyハンズオン：Hono・Go・Railsを実際にデプロイしてみる
Cloudflare Tunnel×Coolify：自宅サーバを安全に外部公開する
API-firstなインフラが生き残る：LLM時代のセルフホスト戦略
ZabbixでDockerコンテナをリソース監視する：Coolify環境の可視化（この記事）
Coolify環境のバックアップ戦略：6つのDBを自動ダンプ+復旧手順
Coolify環境のログ管理と障害対応：Docker + Zabbix + Discordで運用を回す

Coolifyインストールから「プロンプトでデプロイ」まで：Claude Code MCP実践

Sat, 14 Mar 2026 00:00:00 GMT

概要

Coolifyのインストールはコマンド1発、初期設定も数分で完了
MCP（Model Context Protocol）を使えば、Claude Codeからプロンプトだけでインフラ操作が可能
GUIで10分かかるデプロイ作業が、プロンプト一発で4分に

Coolifyのインストール

第1回でCoolifyの選定理由を書きました。ここからは実際にインストールして使い始めます。

必要な環境

項目	要件
OS	Ubuntu 22.04/24.04（推奨）、Debian、CentOS等
CPU	2コア以上
RAM	4GB以上（実用的には8GB推奨）
ストレージ	20GB以上の空き容量

Dockerが入っていなくても、インストールスクリプトが自動で入れてくれます。

インストール手順

公式のインストールスクリプトを実行するだけです。

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

ステップ	内容	所要時間
1	Docker自動インストール（未導入の場合）	1〜2分
2	CoolifyのコンテナイメージをPull	2〜3分
3	管理UI（ポート8000）を起動	30秒
4	Traefik（リバースプロキシ）を起動	30秒
合計		約5分

初回セットアップ

ブラウザで http://サーバIP:8000 にアクセス。初期登録画面でメールアドレスとパスワードを設定したら、もう使えます。サーバのリソース（CPU/RAM/ディスク）は自動検出されます。

自宅サーバで外部公開する場合はCloudflare Tunnelを使うのが一番簡単で安全です。詳細は第4回で書きます。

ワイルドカードDNSの設定

Coolifyでは myapp.teraren.com、api.teraren.com のようにサービスごとにサブドメインを割り当てる運用になります。サービスを追加するたびにDNSレコードを手動で追加するのは面倒なので、ワイルドカードDNSを設定しておきます。

CloudflareのDNS設定画面で、以下のレコードを追加。

Type	Name	Content	Proxy
CNAME	`*`	Cloudflare TunnelのターゲットまたはサーバIP	ON

{/* TODO: Cloudflare管理画面のスクリーンショットを追加 */}

これで *.teraren.com 宛のリクエストがすべてCoolifyサーバに届くようになります。Coolify側のTraefikが、Hostヘッダを見て適切なコンテナにルーティングしてくれます。新しいサービスを追加するときにDNSをいじる必要がなくなるので、MCPでのプロンプト一発デプロイがさらに手軽になります。

GitHub App連携

CoolifyでPush to Deployを使うには、GitHub Appの連携が必要です。管理UIの Settings > GitHub から「Create GitHub App」をクリックすると、GitHubのOAuth認証フローが始まります。数クリックで完了。

これで特定のリポジトリへのPushをWebhookで受け取って、自動ビルド&デプロイが動くようになります。

まずは手動でデプロイしてみる

MCPの話に行く前に、GUIでの手動デプロイを体験しておきます。この面倒さを知っておくと、後でMCPの威力がよくわかるので。

GUIでのデプロイ手順

管理UIでの操作はざっくりこんな流れです。

プロジェクトを作成（名前を入力）
「New Resource」→「Application」を選択
GitHub Appを選んでリポジトリを検索
リポジトリとブランチを指定
ビルド方式を選択（Nixpacks / Dockerfile / Docker Compose）
ドメインを入力（例: myapp.teraren.com）
環境変数を1つずつ入力。。。
「Deploy」ボタンを押す
ビルドログを眺めて待つ
SSL証明書が自動発行されてアクセス可能に

1アプリなら問題ありません。 でも、これを20個のサービスで繰り返すのは正直しんどいです。特に環境変数を1つずつGUIに入力するのが面倒です。DB接続文字列、APIキー、シークレット。。。コピペミスも怖いです。

ここで「もうちょっと楽にならないかな」と思ったところで、MCPの出番です。

MCPとは

MCP（Model Context Protocol）はAnthropicが2024年末に発表した標準プロトコルです。AIモデルが外部のツールやサービスを直接操作するための共通規格です。

従来: 人間がAIに質問 → AIが回答 → 人間が手動でコマンド実行
MCP: 人間がAIに指示 → AIがMCP経由でツールを自動実行 → 結果を報告

MCPは「サーバー」と「クライアント」の2層構造です。

コンポーネント	役割	例
MCPサーバー	特定のサービスを操作するためのAPI	Coolify MCP、GitHub MCP、Slack MCP
MCPクライアント	MCPサーバーを呼び出すAI側	Claude Code、Claude Desktop、Cursor

Claude Codeは複数のMCPサーバーに同時接続できるので、「GitHubでリポジトリ作成 → Coolifyでデプロイ → Slackで通知」みたいな連携もプロンプト一発で可能です。MCPサーバーはCoolify以外にもAWS、Cloudflare、GitHubなど増え続けています。

Coolify MCPサーバーの導入

必要なもの

項目	内容
Coolify	インストール済み
Claude Code	最新版
API Token	Coolifyの Settings > API Keys から生成

設定手順

Claude Codeの claude mcp add コマンド一発で追加できます。

claude mcp add coolify \
  -e COOLIFY_URL=https://coolify.your-domain.com \
  -e COOLIFY_TOKEN=your-api-token-here \
  -- npx -y @coolify-community/coolify-mcp@latest

これで ~/.claude/settings.json に自動で追加されます。設定ファイルを手動で編集する必要はありません。Claude Codeを再起動すれば、もうCoolifyのAPIが使えます。

動作確認

Coolifyに接続して、現在のサーバーとプロジェクト一覧を教えて。

これだけで list_servers と list_projects が自動的に呼ばれて、結果を表形式で返してくれます。curlを打つ必要はありません。

実践例1：プロンプトだけでWordPressを立ち上げる

まずはシンプルな例からです。WordPressをプロンプトだけで構築して公開します。DB作成からドメイン設定、テーマ導入まで全部MCPでやります。

会話ログ（要約）

実際にClaude Codeとやり取りした流れです。

私: CoolifyでWordPressを立ち上げて。
    プロジェクト名は wordpress-demo、
    ドメインは wordpress-demo.teraren.com で。

Claude Code: まずプロジェクトを作成します。
  → [MCP] create_project "wordpress-demo"

Claude Code: MySQLデータベースを作成します。
  → [MCP] create_database（MySQL、wordpressユーザー/DB）
  → 内部接続URL: mysql://wordpress:***@コンテナID:3306/wordpress

Claude Code: WordPressアプリケーションを作成します。
  → [MCP] create_application（Dockerイメージ: wordpress:latest）
  → [MCP] update_application（ドメイン設定）

Claude Code: DB接続用の環境変数を設定します。
  → [MCP] env_vars × 4
    WORDPRESS_DB_HOST, WORDPRESS_DB_USER,
    WORDPRESS_DB_PASSWORD, WORDPRESS_DB_NAME

Claude Code: デプロイを開始します。
  → [MCP] deploy
  → ✓ WordPress初期画面が表示されました。

ここまででプロジェクト作成→DB作成→アプリ作成→環境変数設定→デプロイが完了しました。所要時間は約4分です。さっきGUIで10ステップかけてやった作業が、プロンプト1回で終わりました。

テーマ設定や初期構成もAIに丸投げ

WordPressが立ち上がりましたが、デフォルトテーマだと味気ないです。車メディアサイトを作りたいので、ここからさらにプロンプトで指示します。

私: 車メディアサイトにしたい。派手な車のテーマを入れて、
    日本語設定にして、車関連の記事を5本入れておいて。
    サイト名は「Car Media Demo」で。

Claude Code: WordPressコンテナ内でWP-CLIを実行します。
  $ docker exec ... wp core install \
      --url=wordpress-demo.teraren.com \
      --title="Car Media Demo" --locale=ja
  $ docker exec ... wp theme install automobile-car-shop --activate
  $ docker exec ... wp option update blogdescription \
      "最新の車ニュースとレビュー"
  $ docker exec ... wp post create \
      --post_title="2026年版 国産スポーツカー比較ガイド" \
      --post_status=publish
  $ docker exec ... wp post create \
      --post_title="電気自動車の充電インフラ最前線" \
      --post_status=publish
  $ docker exec ... wp post create \
      --post_title="ポルシェ 911 GT3 RS 試乗レビュー" \
      --post_status=publish
  $ docker exec ... wp post create \
      --post_title="ヘッドライトの黄ばみをDIYで復活させる方法" \
      --post_status=publish
  $ docker exec ... wp post create \
      --post_title="新型アルファード vs ヴェルファイア 2026年モデル" \
      --post_status=publish

wordpress-demo.teraren.com を開いたら、車ディーラー風のダークテーマが適用されたサイトが動いています。DB作成からテーマ導入・記事5本投入まで、ターミナルから一歩も出ていません。

この例のポイントは、MCPだけでなくDocker execコマンドも組み合わせているところです。Claude Codeは「MCPでインフラ操作 → シェルでアプリ内操作」を自然に切り替えてくれます。人間が「次はWP-CLIで…」と考える必要すらありません。

v0→Vercel との対比

v0→Vercelが「バイブコーディング→即デプロイ」の神ワークフローとして知られていますが、Claude Code→Coolifyでも同じことができます。しかもリソース無制限、月額$0です。

観点	v0 → Vercel	Claude Code → Coolify
コード生成	v0独自のUI生成	既存コードベースに統合
デプロイ先	Vercel（クラウド）	Coolify（セルフホスト）
コスト	従量課金	$0
複雑な機能	制限あり	制限なし

v0は「ゼロから作る」に特化しています。Claude Codeは「既存のものを理解して拡張する」に特化しています。まぁ両方使えばいいと思います。

実践例2：develop環境をプロンプト一発で複製

トライアスロン大会結果の分析サービスのdevelop環境を作った例です。本番環境の構成をそのままコピーして、ブランチだけ変えてデプロイします。

私: ai-triリポジトリの develop ブランチをCoolifyにデプロイして。
    ドメインは develop.ai-triathlon-result.teraren.com で。
    環境変数は本番環境からコピーして。

Claude Code:
  → [MCP] list_projects → ai-triプロジェクトを発見
  → [MCP] create_application（developブランチ指定）
  → [MCP] get_env_vars（本番から取得）
  → [MCP] bulk_env_update（developに設定）
  → [MCP] update_application（ドメイン設定）
  → [MCP] deploy
  → ✓ develop.ai-triathlon-result.teraren.com でアクセス可能

本番の環境変数を自動でコピーしてくれるのが地味に便利です。手動だと環境変数のコピペミスが一番怖いところです。

実践例3：Zabbix環境を丸投げ構築

Zabbix（監視システム）をCoolifyに載せた例です。Server + Web + DB の複合構成で、手動だとコンテナ間の接続設定が面倒なやつです。

私: ZabbixをCoolifyに構築して。
    ドメインは zabbix.teraren.com で。

Claude Code:
  → [MCP] create_project "zabbix"
  → [MCP] create_database（MariaDB）
  → [MCP] create_application × 2（Server, Web）
  → 環境変数にDB接続情報を自動設定（10個以上）
  → [MCP] update_application でドメイン設定
  → [MCP] deploy × 2
  → ✓ zabbix.teraren.com でアクセス可能

すごいのは、コンテナ間の接続設定を全部自動でやってくれるところです。Zabbix ServerのDB接続文字列、Zabbix WebからServerへの接続先、ポート設定。。。手動だと環境変数を10個以上、コピペミスなく設定する必要があります。AIに任せれば一瞬で終わりますし、ミスもありません。

手動でやったら1時間以上かかりそうな作業が、約10分で完了しました。

実践例4：MariaDBチューニング

この件は「Claude Codeでプロンプト1発、MariaDBのメモリ使用量を400MB→150MBに削減した話」に詳しく書いています。

項目	Before	After
メモリ使用量	403.5 MiB	~150 MiB
削減率	-	63%削減
作業時間	数時間（手動調査）	5分（プロンプト3回）

MCP経由で SHOW VARIABLES / SHOW GLOBAL STATUS を取得→分析→チューニングプラン作成→設定適用→再起動まで一気通貫です。Plan Modeで計画を見せてもらってから実行に移したので安心感がありました。

プロンプト設計のコツ

MCPでインフラ操作するとき、いくつかコツがあります。

文脈を具体的に伝える。 「新しい環境を作って」ではなく「ai-triプロジェクトの本番と同じ構成でdevelop環境を作って」。プロジェクト名、リポジトリ名、ブランチ名を明示します。

Plan Modeを使う。 インフラ操作は影響範囲が大きいので、Claude CodeのPlan Modeで計画を立てさせてから実行します。DB再起動みたいな影響のある操作を勝手にやられると怖いので。

段階的に進める。 「全部まとめてやって」より「まず現在の構成を確認して」→「新しいアプリを作成して（まだデプロイしない）」→「環境変数を設定して」と段階的に指示した方が、トラブルシューティングが楽です。

まとめ

タスク	GUIで手動	Claude Code + MCP
WordPress構築（DB+テーマ込み）	15分	4分（プロンプト2回）
develop環境の複製	10分（ポチポチ）	4分（プロンプト一発）
Zabbix移行（複合構成）	1時間以上	約10分
MariaDBチューニング	数時間	5分

GUIでポチポチやっていた作業がプロンプト一発で終わります。やらない理由はありません。

余談：TerraformでもAnsibleでもなくMCPだった理由

「インフラ自動化ならTerraformやAnsibleがあるじゃん」と思うかもしれません。実際、Coolifyに移行する前にTerraformを検討しました。

でも、個人で10〜30個のサービスを運用する規模に、Terraformの .tf ファイルを書いて plan して apply するワークフローはオーバーキルです。状態管理のバックエンド（S3とか）も用意しないといけませんし、HCL（Terraformの設定言語）の学習コストもあります。Ansibleも同様で、playbookを書いてメンテナンスする手間が本末転倒です。

MCPが良いのは、自動化のためのコードを書かなくていいところです。Terraformは「インフラをコードで管理する」思想ですが、MCPは「インフラをAIに口頭で頼む」思想です。コードの管理コストがゼロです。

もちろん、大規模なチームでGitOps的にインフラを管理するならTerraformの方が向いています。でも個人開発者が自宅サーバで20個のサービスを回すなら、MCPの方が圧倒的に手軽です。

面白いのは、MCPサーバーの実装が思ったよりシンプルなことです。Coolify MCPサーバーのソースコードを見ると、やっていることはCoolifyのREST APIをラップしているだけです。MCPの仕様に沿ってツール定義を書いて、APIを叩いて結果を返します。つまりMCPはAPI設定の簡略化レイヤーであって、本質はREST APIの存在そのものです。

MCPがなくても、REST APIがあればAIエージェントは直接APIを叩けます。MCPはセットアップを楽にしてくれますが、コンテキストウィンドウを圧迫するデメリットもあります（接続したツール定義がすべてトークンを消費します）。大事なのはAPI-firstであることで、MCPはあくまでおまけです。この話は第5回で詳しく書きます。

シリーズ記事

Vercel月額$42→自宅サーバ月額$0。Coolifyで個人サービス基盤を作った話
Coolifyインストールから「プロンプトでデプロイ」まで：Claude Code MCP実践（この記事）
Coolifyハンズオン：Hono・Go・Railsを実際にデプロイしてみる
Cloudflare Tunnel×Coolify：自宅サーバを安全に外部公開する
API-firstなインフラが生き残る：LLM時代のセルフホスト戦略
ZabbixでDockerコンテナをリソース監視する：Coolify環境の可視化
Coolify環境のバックアップ戦略：6つのDBを自動ダンプ+復旧手順
Coolify環境のログ管理と障害対応：Docker + Zabbix + Discordで運用を回す

Cloudflare Tunnel×Coolify：自宅サーバを安全に外部公開する

Sat, 14 Mar 2026 00:00:00 GMT

概要

自宅サーバを外部公開するのにポート開放は不要。Cloudflare TunnelでOutbound接続だけで公開できます
CDN・WAF・DDoS対策・SSL証明書が全部無料でついてきます
CoolifyのPRプレビュー環境と組み合わせると、PRごとに一時的なURLが自動生成されます

第1回でCoolifyの選定理由、第2回でインストールとMCP、第3回で実際のデプロイを紹介しました。今回は「自宅サーバをどうやって安全に外部公開するか」の話です。

自宅サーバ公開の課題

自宅サーバでサービスを公開するには、いくつかハードルがあります。

課題	内容
ポート開放	ルーターのNAT設定が必要。セキュリティリスクが増える
固定IPなし	多くの家庭回線はIPが変わる。DDNSが必要
DDoS	自宅IPが攻撃対象になると回線ごと死ぬ
SSL証明書	Let's Encryptで取れるが、80/443ポートの開放が前提

ポート開放は本当にやりたくありません。自宅のIPアドレスがバレたら、サーバだけでなく家庭のネットワーク全体がリスクにさらされます。

Cloudflare Tunnelとは

Cloudflare Tunnel（旧称Argo Tunnel）は、サーバからCloudflareへOutbound接続だけでトンネルを張るサービス。ポート開放不要、固定IP不要、DDNS不要。

sequenceDiagram
    participant User as ユーザー
    participant CF as Cloudflare Edge
    participant Tunnel as cloudflared<br/>(自宅サーバ)
    participant Coolify as Coolify / Traefik

    User->>CF: https://app.teraren.com
    Note over CF: CDN / WAF / DDoS保護
    CF->>Tunnel: Tunnelで転送
    Tunnel->>Coolify: localhost:80
    Coolify-->>Tunnel: レスポンス
    Tunnel-->>CF: レスポンス
    CF-->>User: レスポンス（キャッシュ済み）

ポイント:

自宅サーバ側の cloudflared がCloudflareにOutbound接続します。Inbound接続は一切ありません
自宅のIPアドレスは外部に公開されません。Cloudflareが全部受けてくれます
CDN・WAF・DDoS対策が自動的に適用されます。設定不要

cloudflaredのインストール

Cloudflare側の設定

Cloudflare Zero Trust にログイン
Networks → Tunnels → Create a Tunnel
Tunnel名を入力（例: home-server）
インストール用のトークンが発行される

サーバ側のインストール

# Debianの場合
curl -L https://pkg.cloudflare.com/cloudflare-main.gpg \
  | sudo tee /usr/share/keyrings/cloudflare-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/cloudflare-archive-keyring.gpg] \
  https://pkg.cloudflare.com/cloudflared $(lsb_release -cs) main" \
  | sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt update && sudo apt install cloudflared

# サービスとして登録
sudo cloudflared service install <TOKEN>

systemctl status cloudflared で active (running) なら成功。

Public Hostnameの設定

Cloudflare Zero Trust Dashboard → Tunnels → 作成したTunnel → Public Hostname で、ルーティングを設定します。

Subdomain	Domain	Service
`*`	`teraren.com`	`http://localhost:80`

ワイルドカード（*）を設定するのがポイント。 これで *.teraren.com 宛のリクエストがすべてトンネル経由でCoolifyサーバに届きます。Coolify側のTraefikがHostヘッダを見て、適切なコンテナにルーティングしてくれます。

個別のサービスごとにDNSレコードを追加する必要がありません。Coolifyで新しいアプリを作ってドメインを設定するだけで、即座にアクセス可能になります。

CoolifyとCloudflare Tunnelの連携

SSL/TLSの設定（重要）

ここでハマりポイントがあります。CoolifyのドメインはHTTP（http://）で設定する必要があります。

なぜかというと、Cloudflare → cloudflared → Coolify の経路で、SSL終端はCloudflareが担当するからです。Coolify側でもHTTPSにすると、Cloudflare→Coolify間で二重暗号化になって接続できません。

❌ ダメな設定: Coolifyのドメインに https://app.teraren.com
   → Cloudflare(SSL) → Tunnel → Coolify(SSL) = 二重暗号化でエラー

✅ 正しい設定: Coolifyのドメインに http://app.teraren.com
   → Cloudflare(SSL) → Tunnel → Coolify(HTTP) = 正常動作

エンドユーザーは https://app.teraren.com でアクセスします。SSLはCloudflareが処理するので、通信は暗号化されています。Coolify↔Cloudflare間はトンネル内なので、HTTPでも安全です。

Cloudflare側のSSL設定

Cloudflare Dashboard → SSL/TLS で、暗号化モードを確認します。

モード	動作	推奨
Off	暗号化なし	✗
Flexible	ブラウザ→Cloudflareのみ暗号化	△
Full	ブラウザ→Cloudflare→オリジン	✅
Full (Strict)	上記＋オリジン証明書検証	△（自宅サーバでは不要）

Fullが推奨です。自宅サーバ側にLet's Encrypt証明書がなくても、Tunnel経由なので問題ありません。

ネットワーク構成の全体像

graph TB
    subgraph Internet
        User["ユーザー"]
        GitHub[GitHub]
    end

    subgraph Cloudflare
        CDN[CDN / WAF]
        DNS["DNS<br/>*.teraren.com"]
    end

    subgraph "自宅サーバ"
        CFD["cloudflared<br/>(Tunnel Agent)"]

        subgraph Coolify
            Traefik["Traefik<br/>(リバースプロキシ)"]
            UI["管理UI :8000"]
        end

        subgraph Docker
            App1["Next.js<br/>app.teraren.com"]
            App2["Rails<br/>train.teraren.com"]
            App3["WordPress<br/>blog.teraren.com"]
            DB["MariaDB / Redis"]
        end
    end

    User -->|HTTPS| CDN
    CDN --> DNS
    DNS -->|Tunnel| CFD
    CFD -->|HTTP| Traefik
    Traefik -->|Host: app| App1
    Traefik -->|Host: train| App2
    Traefik -->|Host: blog| App3
    App1 --> DB
    App3 --> DB

    GitHub -->|Webhook| UI
    UI -->|Deploy| App1

PRプレビュー環境

CoolifyにはPRプレビュー環境の機能があります。PRを作るたびに一時的なURLが自動生成されて、レビュワーがデプロイ済みの状態で確認できます。Vercelのプレビュー機能と同じです。

設定方法

Coolifyのアプリ設定 → Preview Deployments で有効化。URLテンプレートはデフォルトで {{pr_id}}.{{domain}}。

設定	例
本番ドメイン	`app.teraren.com`
PR #42 のプレビュー	`42.app.teraren.com`

ワイルドカードDNSを設定済みなら、追加のDNS設定は不要です。PRがマージされたらプレビュー環境は自動で削除されます。

MCPでの活用

PR #42 のプレビュー環境を確認して。動いてる？

MCP経由でプレビューデプロイの状態確認も可能です。外部の人にURLを共有してフィードバックをもらうフローが、Coolify + Cloudflare Tunnelだけで完結します。

VPSとの比較

「自宅サーバじゃなくてVPSでいいのでは？」という疑問への回答です。

観点	自宅サーバ + Cloudflare Tunnel	VPS
月額コスト	$0（電気代のみ）	$5〜$50/月
CDN	自動付与（Cloudflare）	別途設定が必要
WAF / DDoS	自動付与	別途設定が必要
SSL	Cloudflareが自動管理	Let's Encrypt等
リソース	物理マシンの全リソース	プランに依存
回線速度	家庭回線に依存（上り制限あり）	安定
冗長性	なし（停電で止まる）	データセンター品質
物理管理	自分でやる（電源、冷却、故障）	不要

個人サービスで「いつでも絶対に落ちない」ことが求められないなら、自宅サーバの方がコスパは圧倒的に良いです。CDNとWAFが無料でついてくるのは、Cloudflare Tunnelを通す自宅サーバだけのメリットです。VPSでCloudflareを使うのは追加設定が必要ですが、自宅Tunnelなら構造上必ずCloudflareを経由するので、設定忘れもありません。

回線速度だけは弱点です。うちは100Mbps回線なので、大量のトラフィックには向きません。でも、Cloudflare CDNがキャッシュしてくれるので、静的アセットはCDNから配信されます。オリジンへのリクエストは思ったより少ないです。

運用上の注意点

cloudflaredの監視

cloudflaredが落ちると全サービスが外部からアクセスできなくなります。systemdのサービスとして動いているので、基本的には自動再起動されますが、Zabbix等で死活監視しておくと安心です。

# ステータス確認
systemctl status cloudflared

# ログ確認
journalctl -u cloudflared -f

Cloudflareの無料プランの制限

無料プランでも十分使えます。主な制限は以下の通りです。

項目	無料プラン
リクエスト数	無制限
帯域幅	無制限
Tunnel数	無制限
Workers	100,000リクエスト/日
Cacheルール	10個
Page Rules	3個

リクエスト数も帯域幅も無制限です。個人サービスの規模なら、有料プランにアップグレードする必要はまずありません。

まとめ

自宅サーバ + Cloudflare Tunnel + Coolify の組み合わせは、個人開発者にとってかなり強力です。

得られるもの	コスト
ポート開放なしの外部公開	$0
CDN + キャッシュ	$0
WAF + DDoS対策	$0
SSL証明書	$0
PRプレビュー環境	$0
無制限のサービスデプロイ	$0

全部タダ。やらない理由はありません。

次回の第5回では、API-firstがインフラ選定にどう影響するか、LLM時代のセルフホスト戦略について書きます。

シリーズ記事

Vercel月額$42→自宅サーバ月額$0。Coolifyで個人サービス基盤を作った話
Coolifyインストールから「プロンプトでデプロイ」まで：Claude Code MCP実践
Coolifyハンズオン：Hono・Go・Railsを実際にデプロイしてみる
Cloudflare Tunnel×Coolify：自宅サーバを安全に外部公開する（この記事）
API-firstなインフラが生き残る：LLM時代のセルフホスト戦略
ZabbixでDockerコンテナをリソース監視する：Coolify環境の可視化
Coolify環境のバックアップ戦略：6つのDBを自動ダンプ+復旧手順
Coolify環境のログ管理と障害対応：Docker + Zabbix + Discordで運用を回す

Coolifyハンズオン：Hono・Go・Railsを実際にデプロイしてみる

Sat, 14 Mar 2026 00:00:00 GMT

概要

Coolifyには3つのビルドパック（Nixpacks・Dockerfile・Docker Compose）があります
それぞれの特徴を、実際にアプリを作ってデプロイしながら体験します
簡単な順に進みます：Hono（Nixpacks）→ Go（Dockerfile）→ Rails + Ollama（Docker Compose）

第1回でCoolifyの選定理由、第2回でインストールとMCPを紹介しました。今回は「実際にゼロからアプリを載せる」ハンズオンです。読みながら手を動かせるようにしています。

前提

Coolifyがインストール済み（第2回参照）
GitHubアカウントがある
ワイルドカードDNS（*.yourdomain.com）が設定済み

3つのビルドパック

Coolifyには、アプリをどうやってコンテナにするかを決める「ビルドパック」が3種類あります。

ビルドパック	何をするか	向いているケース
Nixpacks	ソースコードから自動でDockerイメージを生成	プロトタイプ、小〜中規模アプリ
Dockerfile	リポジトリのDockerfileでビルド	本番運用、細かい制御が必要な場合
Docker Compose	複数コンテナをまとめてデプロイ	DB・キャッシュ込みのフルスタック構成

順番にやっていきます。

1. Hono × Nixpacks：Dockerfileを書かずにデプロイ

Nixpacksとは

NixpacksはRailwayが開発したビルドツールです。ソースコードを読んで、言語やフレームワークを自動検出し、Dockerイメージを勝手に作ってくれます。Dockerfileを書く必要がありません。

HerokuのBuildpacksと似た思想ですが、Nixpacksは最終的にDockerイメージを生成するので、どこでも動きます。

アプリを作る

HonoはCloudflare Workers向けに作られた軽量Webフレームワークです。Node.jsでも動くので、ここではNode.jsランタイムで使います。

mkdir coolify-demo-hono && cd coolify-demo-hono
npm init -y
npm install hono @hono/node-server
npm install -D typescript @types/node tsx

src/index.ts を作成します。

import { Hono } from 'hono'
import { serve } from '@hono/node-server'

const app = new Hono()

app.get('/', (c) => {
  const now = new Date().toISOString()
  return c.html(`
    <h1>Hello from Hono on Coolify!</h1>
    <p>Current time: ${now}</p>
    <p>Node.js ${process.version}</p>
  `)
})

app.get('/health', (c) => {
  return c.json({ status: 'ok' })
})

const port = Number(process.env.PORT) || 3000
console.log(`Server running on port ${port}`)
serve({ fetch: app.fetch, port })

package.json の scripts にビルドとスタートを追加します。

{
  "type": "module",
  "scripts": {
    "build": "tsc",
    "start": "node dist/index.js"
  }
}

これだけです。 Dockerfile不要。package.jsonにbuildとstartがあれば、Nixpacksが勝手にやってくれます。

GitHubにpushしてCoolifyでデプロイ

git init && git add -A && git commit -m "initial commit"
gh repo create coolify-demo-hono --public --source=. --push

管理画面（GUI）の場合：

New Resource → Application → GitHubリポジトリを選択 → ビルドパックでNixpacksを選択 → ドメインを入力 → Deploy。

Claude Code MCP（プロンプト）の場合：

coolify-demo-honoリポジトリをNixpacksでデプロイして。
ドメインはdemo-hono.teraren.comで。

MCPが create application → deploy まで自動で実行してくれます。GUIで3〜4画面分の操作が、プロンプト1つで完了します。

動作確認

$ curl https://demo-hono.teraren.com/
<h1>Hello from Hono on Coolify!</h1>
<p>Current time: 2026-03-14T21:41:05.634Z</p>
<p>Node.js v22.11.0</p>

$ curl https://demo-hono.teraren.com/health
{"status":"ok"}

Nixpacksが自動検出したビルドプラン：

╔══════════════ Nixpacks v1.41.0 ═══════════════╗
║ setup      │ nodejs_22, npm-9_x, curl, wget   ║
║────────────────────────────────────────────────║
║ install    │ npm ci                            ║
║────────────────────────────────────────────────║
║ build      │ npm run build                     ║
║────────────────────────────────────────────────║
║ start      │ npm run start                     ║
╚════════════════════════════════════════════════╝

package.jsonを見てNode.jsアプリだと判定し、npm ci → npm run build → npm run startのフローを自動構成してくれました。設定ファイルゼロでデプロイ完了です。

Nixpacksの限界

便利ですが限界もあります。

マルチステージビルドができない（イメージサイズが大きくなりがち）
キャッシュ制御が粗い（ビルド時間の最適化が難しい）
Alpine以外のベースイメージを選べない場面がある
ネイティブ拡張の依存関係で詰まることがある

プロトタイプや小規模アプリには最高です。ただし本番運用で細かい制御が必要になったら、Dockerfileに移行するタイミングです。

2. Go × Dockerfile：バイナリ1つのミニマルデプロイ

なぜDockerfileを書くのか

Nixpacksで自動生成されるDockerfileは汎用的です。しかしGoのようにシングルバイナリにコンパイルできる言語では、マルチステージビルドで本番イメージを極小にできます。これはNixpacksではできません。

アプリを作る

標準ライブラリだけで書きます。外部依存ゼロです。

package main

import (
	"encoding/json"
	"fmt"
	"net/http"
	"os"
	"runtime"
	"time"
)

func main() {
	port := os.Getenv("PORT")
	if port == "" {
		port = "8080"
	}

	hostname, _ := os.Hostname()

	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
		w.Header().Set("Content-Type", "text/plain; charset=utf-8")
		fmt.Fprintf(w, "Hello from Go on Coolify!\n\nGo version: %s\nHostname:   %s\nTime:       %s\n",
			runtime.Version(), hostname, time.Now().Format(time.RFC3339))
	})

	http.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
		w.Header().Set("Content-Type", "application/json")
		json.NewEncoder(w).Encode(map[string]string{"status": "ok"})
	})

	fmt.Printf("Listening on :%s\n", port)
	http.ListenAndServe(":"+port, nil)
}

Dockerfile：マルチステージビルド

ここがDockerfileの真価です。

# Build stage
FROM golang:1.24-alpine AS builder
WORKDIR /app
COPY go.mod .
COPY main.go .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o server .

# Production stage — tiny image with just the binary
FROM scratch
COPY --from=builder /app/server /server
EXPOSE 8080
ENTRYPOINT ["/server"]

ポイント:

ビルドステージ（golang:1.24-alpine、約300MB）でコンパイル
本番ステージはscratch（0バイト）にバイナリだけコピー
最終イメージはバイナリのサイズだけ（数MB）
CGO_ENABLED=0で静的リンク、-ldflags="-s -w"でデバッグ情報を除去

デプロイと動作確認

gh repo create coolify-demo-go --public --source=. --push

管理画面（GUI）の場合：

New Resource → Application → GitHubリポジトリを選択 → ビルドパックでDockerfileを選択 → ドメインを入力 → Deploy。

Claude Code MCP（プロンプト）の場合：

coolify-demo-goリポジトリをDockerfileでデプロイして。
ドメインはdemo-go.teraren.comで。

ビルド時間は約40秒です。

$ curl https://demo-go.teraren.com/
Hello from Go on Coolify!

Go version: go1.24.13
Hostname:   ed06252fb474
Time:       2026-03-14T21:41:04Z

$ curl https://demo-go.teraren.com/health
{"status":"ok"}

Goのマルチステージビルドのイメージサイズ比較です。

ステージ	ベースイメージ	サイズ
ビルド	`golang:1.24-alpine`	~300MB
本番	`scratch`	~6MB

これがDockerfileを自分で書く理由です。Nixpacksだとこの最適化はできません。

3. Rails × Docker Compose：ローカルLLMチャットアプリ

Docker Composeとは

複数のコンテナをまとめて定義・管理する仕組みです。Webアプリ + DB + キャッシュ + α をdocker-compose.yaml一つで定義できます。

Coolifyは「アプリとDBを個別に作って環境変数で繋ぐ」思想ですが、Docker Compose方式にも対応しています。コンテナ間の依存関係が複雑な場合はこちらの方が楽です。

何を作るか

Ollamaを使ったローカルLLMチャットアプリです。構成は以下のとおりです。

サービス	イメージ	役割
app	Ruby on Rails	Webアプリ + チャットUI
db	PostgreSQL 17	チャット履歴の保存
redis	Redis 7	セッション・キャッシュ
ollama	Ollama	ローカルLLM推論

4つのコンテナが連携して動く、フルスタック構成です。

docker-compose.yaml

services:
  app:
    build: .
    ports:
      - "3000:3000"
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_healthy
    environment:
      - RAILS_ENV=production
      - DATABASE_HOST=db
      - DATABASE_USER=postgres
      - DATABASE_PASSWORD=password
      - REDIS_URL=redis://redis:6379/0
      - OLLAMA_URL=http://ollama:11434
      - SECRET_KEY_BASE=dummy-secret-key-for-demo-only
      - RAILS_LOG_TO_STDOUT=true
      - RAILS_SERVE_STATIC_FILES=true
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/up"]
      interval: 10s
      timeout: 5s
      retries: 3
      start_period: 30s

  db:
    image: postgres:17-alpine
    volumes:
      - postgres_data:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=password
      - POSTGRES_DB=app_production
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 3s
      retries: 5

  redis:
    image: redis:7-alpine
    volumes:
      - redis_data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 3s
      retries: 5

  ollama:
    image: ollama/ollama:latest
    volumes:
      - ollama_data:/root/.ollama
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:11434/api/tags"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 30s

volumes:
  postgres_data:
  redis_data:
  ollama_data:

ポイント:

depends_on + condition: service_healthy でDBとRedisの起動を待ってからアプリを起動します
各サービスにhealthcheckを定義しています。Coolifyがコンテナの状態を監視できます
volumesでデータを永続化しています。デプロイしてもDB・Redis・Ollamaのモデルデータは保持されます

Railsアプリのコード

Ollamaとの通信はNet::HTTPで直接行います。gem追加は不要です。

class HomeController < ApplicationController
  def index
    @db_adapter = ActiveRecord::Base.connection.adapter_name
    @redis_status = check_redis
    @ollama_status, @ollama_models = check_ollama
    @messages = Message.order(created_at: :desc).limit(20).reverse
  end

  def chat
    prompt = params[:prompt].to_s.strip
    return redirect_to root_path if prompt.empty?

    Message.create!(role: "user", content: prompt)
    response = chat_with_ollama(prompt)
    Message.create!(role: "assistant", content: response)
    redirect_to root_path
  end

  private

  def chat_with_ollama(prompt)
    uri = URI("#{ENV['OLLAMA_URL']}/api/generate")
    body = { model: "tinyllama", prompt: prompt, stream: false }.to_json
    response = Net::HTTP.post(uri, body, "Content-Type" => "application/json")
    JSON.parse(response.body)["response"]
  rescue => e
    "Error: #{e.message}"
  end
end

Ollamaの/api/generateエンドポイントにPOSTするだけです。stream: falseで一括レスポンスを受け取っています。

Dockerfile

FROM ruby:3.4-alpine AS base
WORKDIR /app
ENV RAILS_ENV=production BUNDLE_WITHOUT="development:test" BUNDLE_DEPLOYMENT=1

FROM base AS build
RUN apk add --no-cache build-base postgresql-dev curl yaml-dev
COPY Gemfile ./
RUN bundle lock && bundle install --jobs 4

COPY . .
RUN SECRET_KEY_BASE_DUMMY=1 bin/rails assets:precompile 2>/dev/null || true

FROM base AS runtime
RUN apk add --no-cache libpq curl tzdata yaml && adduser -D -h /app rails
COPY --from=build /usr/local/bundle /usr/local/bundle
COPY --from=build /app /app
RUN mkdir -p db storage log tmp/pids && chown -R rails:rails db storage log tmp
USER rails
EXPOSE 3000

CMD ["sh", "-c", "bin/rails db:prepare && bin/rails server -b 0.0.0.0 -p 3000"]

Coolifyでのデプロイ

Docker Composeアプリの場合、Coolifyの設定が少し違います。

管理画面（GUI）の場合：

ビルドパックでDocker Composeを選択
ファイル名はdocker-compose.yaml（.ymlだとCoolifyが見つけられません。。。ここでハマりました）
ドメインは「Domains for app」欄に入力（サービス名ごとに設定欄があります）

Claude Code MCP（プロンプト）の場合：

coolify-demo-railsリポジトリをDocker Composeでデプロイして。
appサービスのドメインはdemo-rails.teraren.comで。

Docker Composeの場合、MCPの恩恵が特に大きいです。GUIだとdocker_compose_domainsの設定がわかりにくいですが、MCPなら「appサービスにこのドメイン」と言えば裏でAPIを叩いて設定してくれます。

動作確認

4つのコンテナが連携して動いています。

Docker Composeの注意点

Coolifyは本来「アプリとDBを個別管理」の思想です。Docker Composeを使う場合の注意点があります。

DB・RedisのバックアップはCoolifyの管理外になります（Compose内のボリュームは自分で管理）
個別サービスのスケーリングができません
環境変数の管理がCompose内に閉じます（CoolifyのUI経由で変更しにくい）

逆に向いているケース：

Ollama + App のようにサービス間の結合度が高い場合
depends_onで起動順序の制御が必要な場合
ローカルとCoolifyで同じcomposeを使い回したい場合

ビルドパック比較まとめ

観点	Nixpacks	Dockerfile	Docker Compose
設定ファイル	不要	Dockerfile	docker-compose.yaml + Dockerfile
難易度	簡単	中	複雑
イメージ最適化	自動（大きめ）	自由自在	自由自在
マルチコンテナ	不可	不可	可能
ビルド時間	長め	制御可能	長め
本番向き	△	◎	○

迷ったら：

とりあえず動かしたい → Nixpacks
本番で使う → Dockerfile
DB込みで丸ごと載せたい → Docker Compose

MCPでやる場合の比較

今回の3つのアプリは、GUIだと各アプリで3〜5画面の操作が必要でした。MCPなら以下のとおりです。

操作	GUI	MCP（プロンプト）
Hono（Nixpacks）	画面操作4ステップ	プロンプト1つ
Go（Dockerfile）	画面操作4ステップ	プロンプト1つ
Rails（Docker Compose）	画面操作6ステップ + API	プロンプト1つ
3つまとめてデプロイ	約15分	約4分

特にDocker Composeのドメイン設定は、GUIだとdocker_compose_domainsのJSON構造を理解する必要があります。MCPなら「appサービスにこのドメイン」と言うだけです。詳しくは第2回を参照してください。

次回の第4回ではCloudflare Tunnelとの連携を詳しく書きます。自宅サーバを安全に外部公開する方法と、PRプレビュー環境の構築など。

シリーズ記事

Vercel月額$42→自宅サーバ月額$0。Coolifyで個人サービス基盤を作った話
Coolifyインストールから「プロンプトでデプロイ」まで：Claude Code MCP実践
Coolifyハンズオン：Hono・Go・Railsを実際にデプロイしてみる（この記事）
Cloudflare Tunnel×Coolify：自宅サーバを安全に外部公開する
API-firstなインフラが生き残る：LLM時代のセルフホスト戦略
ZabbixでDockerコンテナをリソース監視する：Coolify環境の可視化
Coolify環境のバックアップ戦略：6つのDBを自動ダンプ+復旧手順
Coolify環境のログ管理と障害対応：Docker + Zabbix + Discordで運用を回す

API-firstなインフラが生き残る：LLM時代のセルフホスト戦略

Sat, 14 Mar 2026 00:00:00 GMT

概要

REST APIがあるかどうかが、インフラツールの選定基準として重要度を増した
AIエージェントから操作できないインフラは、手動オペレーションのコストが相対的に上がる
セルフホストの世界では、API-firstなOSSが生き残る

このシリーズの最終回。第1回から第4回まで、Coolify + Cloudflare Tunnelで自宅サーバにPaaS環境を構築してきました。ここでは「なぜ今セルフホストなのか」を、LLMとAPIの文脈から考えます。

Coolifyシリーズの振り返り

5回にわたって書いてきたことの全体像。

回	テーマ	要点
第1回	選定理由	Vercel月額$42→$0。Coolify一択だった
第2回	インストール & MCP	GUIで10分→プロンプト4分
第3回	ハンズオン	3つのビルドパックを実際に体験
第4回	ネットワーク	Cloudflare Tunnelでポート開放なし公開
第5回	戦略	API-firstがインフラ選定を変える（この記事）

個別のHowToは前の4回で書きました。ここでは「なぜ」と「これから」の話をします。

APIがインフラ選定の基準を変える

従来の選定基準

インフラツールを選ぶとき、これまでの判断基準はこんな感じでした。

機能が要件を満たすか
コスト（ライセンス、運用コスト）
学習コスト
コミュニティの活発さ
ベンダーロックイン

新しい基準：AI操作可能性

2025年以降、ここに 「AIエージェントから操作できるか」 が加わりました。具体的には：

REST APIがあるか？ → AIエージェントがツールを操作する大前提
操作の粒度は十分か？ → 作成・更新・削除・デプロイが一通りAPIでできるか
APIドキュメントが整備されているか？ → LLMが使い方を理解できるか

REST APIさえあれば、AIエージェントは直接APIを叩けますし、MCPのようなラッパーを介した操作も可能です。本質はAPIの有無であって、特定のプロトコルへの対応ではありません。

第2回で実際にやりましたが、WordPressの構築（DB作成→アプリ作成→環境変数→デプロイ→テーマ設定→記事投入）がプロンプト2回で完了しました。GUIだと15分、Terraformで書くなら30分はかかる作業です。

この差は、サービスが1個なら大したことありません。でも20個、30個のサービスを運用していると、積算の差が巨大になります。

API対応状況の現在地

2026年3月時点で、主要なインフラツールのAPI対応状況。

ツール	REST API	AI連携	備考
Coolify	REST API完備	MCP、直接API呼び出し	コミュニティMCPあり
Cloudflare	公式API	MCP、Wrangler CLI	Workers, KV, D1等
AWS	公式API	MCP、AWS CLI、SDK	CDK, CloudWatch等
Terraform	HCL + CLI	MCP、直接CLI	plan/apply連携
GitHub	REST / GraphQL	MCP、gh CLI	Issue, PR, Actions
Vercel	REST API あり	直接API呼び出し	MCPなしでもAPI経由で操作可能
Kubernetes	kubectl / API	直接API、CLI	豊富なエコシステム

注目すべきは、REST APIがあればAIエージェントとの連携方法は複数あることです。MCPはその一つに過ぎません。第2回の余談で書きましたが、MCPサーバーのソースコードを見ると、やっていることはAPIのラッパーに過ぎません。MCPはAPI設定を簡略化するレイヤーであって、本質はREST APIの存在そのものです。

逆に言えば、REST APIがないツールはAIエージェントとの連携が構造的にできません。GUIオンリーのツールは、AIエージェント時代に取り残されます。

MCPの立ち位置と限界

MCPは便利ですが、過度に持ち上げるべきではありません。

MCPの利点：

API接続のセットアップが簡単（claude mcp add 一発）
ツール定義がAIに自動で渡される

MCPの限界：

コンテキストウィンドウを圧迫します。 MCPで接続したツール定義はすべてコンテキストに載ります。MCPサーバーを5個、10個と追加すると、それだけでトークンを消費してしまいます
REST APIを直接叩けるAIエージェントなら、MCPなしでも同等のことができます
MCPサーバーの品質はまちまちです。APIドキュメントを直接読んだ方が確実なケースもあります

結論：MCPはAPI-firstの恩恵を受けやすくする便利なレイヤーですが、本質はREST APIの有無です。 APIがあればMCPがなくても困りません。

「手動オペレーション税」の概念

AIエージェントが使えないインフラを運用し続けることは、毎回「手動オペレーション税」を払い続けることになります。

操作	API対応ツール（AI活用）	APIなしツール
新サービスのデプロイ	プロンプト1つ（2分）	GUIで10分
環境変数の一括設定	プロンプト1つ（1分）	1つずつ手入力（5分）
develop環境の複製	プロンプト1つ（4分）	手順書を見て再現（20分）
DB接続設定	AIが自動判定（0分）	接続文字列をコピペ（3分）
監視ツール構築	プロンプト1つ（10分）	ドキュメント読んで設定（1時間）

1回1回の差は小さくても、20サービス×月に数回のオペレーション×12ヶ月で考えると、年間で数十時間の差になります。個人開発者にとって、この時間は新しいサービスを作る時間に充てられます。

セルフホストとLLMの相性

なぜセルフホストが有利なのか

LLMを活用したサービスを作る場合、セルフホストには構造的な優位性があります。

1. リソースの制約がない

クラウドPaaSでは、LLM推論に必要なメモリやCPUがプランの上限に引っかかります。第3回でOllama + Rails + PostgreSQL + Redisの4コンテナをDocker Composeでデプロイしましたが、これをVercelやfly.ioでやると従量課金が跳ねます。自宅サーバなら、32GBのRAMを好きなだけ使えます。

2. プロトタイプの公開が即座にできる

LLMを使った新しいアイデアを思いついたら、Claude Codeに「このアプリをCoolifyにデプロイして」と言うだけで外部公開できます。Cloudflare TunnelでSSLもCDNも自動です。友人やチームメンバーにURLを共有してフィードバックをもらえます。

クラウドPaaSだと「まず料金を確認して」「プランを選んで」「クレカ情報を入れて」。。。プロトタイプの段階でこの摩擦は致命的です。

3. データが手元にある

LLMアプリは大量のユーザーデータを扱うことが多いです。トレーニングデータ、会話履歴、生成結果。これを外部のクラウドに置くと、プライバシーの問題が出てきます。セルフホストなら全部自分のSSDの中です。

AIエージェントが加速するセルフホスト

AIエージェント（Claude Code等）の登場で、セルフホストの最大の弱点だった 「運用の面倒さ」が大幅に軽減 されました。

従来のセルフホストは「自分で全部やる」が前提で、DevOpsの知識が必要でした。でも今は「AIに頼む」でほとんどの運用タスクが完結します。REST APIがあるツールなら、AIが直接APIを叩いて操作してくれます。

従来: ドキュメントを読む → 設定ファイルを書く → テスト → 本番適用 → 監視
AI:  「〜を設定して」→ AIがAPIで全部やる → 結果を確認

第2回でZabbixの構築に10分、MariaDBのチューニングに5分かかった程度です。手動だったら各1時間以上かかる作業です。この効率化が、セルフホストのハードルを劇的に下げています。

「GUIの良さ」は残る

ここまでMCPとCLIの話をしてきましたが、GUIが不要になるわけではありません。

GUIが向いている場面：

現在の状態を俯瞰的に把握する（ダッシュボード、メトリクス）
視覚的な確認が必要な操作（ログのスクロール、グラフの確認）
初めて触るツールの学習（何ができるかを探索する）

AIエージェント（API経由）が向いている場面：

繰り返しの操作（デプロイ、環境変数設定、DB作成）
複数ステップの自動化（プロジェクト作成→DB→アプリ→環境変数→デプロイ）
既知のタスクの実行（やりたいことが明確で、手順がわかっている）

CoolifyにはGUIもREST APIもあります。状況に応じて使い分けられるのが理想で、「API対応だからGUIは不要」ではありません。両方あるツールが強いです。

これからのインフラ選定

個人開発者として、今後インフラツールを選ぶときの基準をまとめておきます。

必須条件

REST APIが充実している（AI連携の土台）
セルフホスト可能（コスト制御とデータ主権）
Dockerベース（ポータビリティ、ベンダーロックインなし）
OSSである（透明性、コミュニティ、将来性）

強い加点

APIドキュメントが充実している（AIが使い方を理解しやすい）
GitHub App連携（Push to Deploy）
CDN/Tunnel対応の容易さ（Cloudflare Tunnel等）

これから淘汰されるもの

GUIオンリーでAPIがないツール
SaaS専用でセルフホストできないツール
独自プロトコルでDockerと相性が悪いツール

厳しい言い方ですが、REST APIがないインフラツールは今後AIエージェントと連携できません。APIを後付けするのはアーキテクチャレベルの改修になります。API-firstで設計されていないツールは、構造的にAIエージェント時代に適応できません。

まとめ

5回にわたって、Coolify + Cloudflare Tunnel + Claude Codeの組み合わせで自宅サーバにPaaS環境を構築する話を書きました。

シリーズで得たもの	コスト
Vercel相当のデプロイ体験	$0
CDN + WAF + DDoS対策	$0
AIエージェントによるインフラ操作	$0
無制限のサービスデプロイ	$0
PRプレビュー環境	$0
LLMプロトタイプの即時公開基盤	$0

全部タダです。必要なのは、Dockerが動くサーバ1台と、Cloudflareの無料アカウントと、Claude Codeだけです。

LLMの時代に「インフラをどう管理するか」の答えは、 「AIに頼む」 だと思っています。そのためには、AIが操作できるインフラを選ぶ必要があります。Coolifyはその条件を満たしている数少ないOSSの一つです。

自宅にサーバがあるなら、Coolifyを入れない理由がありません。

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

シリーズ記事

Vercel月額$42→自宅サーバ月額$0。Coolifyで個人サービス基盤を作った話
Coolifyインストールから「プロンプトでデプロイ」まで：Claude Code MCP実践
Coolifyハンズオン：Hono・Go・Railsを実際にデプロイしてみる
Cloudflare Tunnel×Coolify：自宅サーバを安全に外部公開する
API-firstなインフラが生き残る：LLM時代のセルフホスト戦略（この記事）
ZabbixでDockerコンテナをリソース監視する：Coolify環境の可視化
Coolify環境のバックアップ戦略：6つのDBを自動ダンプ+復旧手順
Coolify環境のログ管理と障害対応：Docker + Zabbix + Discordで運用を回す

Vercel月額$42→自宅サーバ月額$0。Coolifyで個人サービス基盤を作った話

Fri, 13 Mar 2026 00:00:00 GMT

概要

Vercel Pro に月額$20〜$42払っていた個人サービスを、自宅サーバ + Coolify に移行した
現在、5プロジェクト・23アプリケーション・7データベースを1台のサーバで運用中。月額$0
Coolifyは「自宅のDockerをVercel化する」OSS PaaS。GitHubにPushしたら自動ビルド&デプロイ&SSL化してくれる

きっかけ：Vercelの請求書

トライアスロン大会結果の分析サービスをVercelで運用していました。構成はNext.js + Auth0 + Stripe + Redis（ioredis） + AI SDK（Google AI / xAI / Groq） + next-intl（多言語対応）。フルスタックのNext.jsアプリで、Server ActionsでバックエンドもTypeScriptです。

Vercel ProのBaseが月$20。トラフィックが多い月は従量課金で$42まで跳ねました。12ヶ月で31M edge requests、1TB fast data transfer。年間$300〜$500。個人サービスとしてはかなりの出費です。

他にも個人で運用しているサービスが20個ほどあり、今後もLLMを使ったプロトタイプをどんどん作りたいと考えています。サービスが増えるたびにVercelの課金が増えるのは厳しいです。

これまで：自宅Docker直運用

自宅サーバにDockerは既に入っています。サーバといってもGMKtec NucBox M2という53,000円の激安ミニPC（Intel Core i7-11390H / 32GB RAM / 1TB SSD）。手のひらサイズ。20個のサービスをそれぞれポート直叩きで動かして、Cloudflare TunnelでDNSとポートのマッピングをGUIでポチポチ設定していました。

これの問題は、サービスが増えるたびに以下の作業が必要なことです。

Dockerコンテナの起動設定を書く
Cloudflare Zero Trust Dashboardでホスト名→ポートの設定を追加
SSL証明書の管理（Cloudflare任せとはいえ）

20個まではなんとかなりましたが、30個、40個と増えていくと管理コストが線形に増加します。もうちょっとなんとかしたいところです。

いくつか選択肢を考えた

選択肢1: exe.dev

exe.devはAIネイティブなインスタントVMホスティング。永続ディスク付きのUbuntuが即座に立ち上がって、HTTPS付きで公開されます。認証もヘッダー情報だけで完結するので手軽です。月$20で2CPU/8GB RAM/25GB disk、最大25VMまで。

ただ、ベンダーロックインが気になります。10〜30個のサービスを載せるとなるとリソースが足りません。

選択肢2: fly.io

fly.ioは良いサービスですが、リソース制限があります。無料枠を超えるとすぐに課金が発生します。個人で大量のサービスを運用する基盤としてはコストが読みにくいです。

選択肢3: Kubernetes (k8s)

Kubernetesは言わずと知れたコンテナオーケストレーションツール。本格的に運用するなら最有力候補ですが、個人サービス10〜30個の規模にはオーバーキルです。Control Planeだけで数GBのRAMを消費します。32GBのミニPCでは、管理基盤にリソースを取られてアプリに回せません。学習コストも高いです。

選択肢4: Proxmox

Proxmox VEは仮想化基盤。VMを切ってその上にDockerを載せる。。。みたいな構成もできますが、やりだすと沼にハマります。個人サービスの基盤としては大げさすぎます。やりたいのはアプリのデプロイであって、仮想マシンの管理ではありません。

選択肢5: Coolify

そこで見つけたのがCoolifyです。一言でいうと、セルフホスト版のVercel/Heroku/Netlifyです。自分のサーバにインストールするだけで、PaaSと同じデプロイ体験が手に入るOSSです。

比較まとめ

	exe.dev	fly.io	Kubernetes	Proxmox	Coolify
月額コスト	$20〜	従量課金	✅ $0（セルフホスト）	✅ $0（セルフホスト）	✅ $0（セルフホスト）
初期構築	✅ 即座	✅ 数分	数時間〜	数時間〜	✅ 数分（コマンド1発）
学習コスト	✅ 低い	中程度	高い（YAML地獄）	高い（仮想化の知識必要）	✅ 低い（GUIでポチポチ）
サービス数上限	25VM	従量課金で増加	✅ 実質無制限	✅ 実質無制限	✅ 実質無制限
DB管理	自前	有料アドオン	自前	自前	✅ GUI標準装備
Push to Deploy	なし	✅ あり	要CI/CD構築	なし	✅ あり（GitHub連携）
SSL自動化	✅ あり	✅ あり	要設定	なし	✅ あり（Let's Encrypt）
ベンダーロックイン	あり	あり	✅ なし	✅ なし	✅ なし（素のDocker）
管理リソース消費	−	−	数GB（Control Plane）	数GB（Hypervisor）	✅ 数百MB（UI+Traefik）
向いている用途	プロトタイプ	小〜中規模	大規模運用	VM管理	✅ 個人〜中規模のサービス運用

個人で10〜30個のサービスを運用する前提だと、Coolify一択でした。コストゼロ、学習コストが低い、Docker資産がそのまま使える、管理リソースも軽いという点が決め手でした。

Coolifyとは

プロジェクト概要

Coolifyは、ハンガリーの開発者 Andras Bacsai が2021年に立ち上げたOSSプロジェクトです。coolLabs Solutions Kft. が開発・運営しています。ライセンスは Apache 2.0です。

GitHubスターは51,600以上（2026年3月時点）。Discordコミュニティは20,000人超。クラウド版の有料ユーザーも3,200人以上いて、個人のサイドプロジェクトではなく、ちゃんとした事業として回っています。日本ではまだあまり知られていませんが、海外のセルフホスト界隈ではかなりメジャーな存在です。

現在のバージョンは v4.0.0-betaです。v3からアーキテクチャを刷新して、安定性重視の設計になっています。

アーキテクチャ

Coolifyの構成はシンプルです。自分のサーバにインストールすると、管理UI + Traefik（リバースプロキシ）+ Docker Engineの3層構造で動きます。

graph TB
    subgraph Internet
        EndUser["サービス利用者"]
        Admin["Coolify管理者"]
        GitHub[GitHub]
        CF[Cloudflare CDN / WAF]
    end

    subgraph "自宅サーバ（GMKtec NucBox M2）"
        Tunnel[cloudflared<br/>Cloudflare Tunnel]

        subgraph Coolify
            UI[管理UI :8000]
            API[REST API]
            Traefik[Traefik リバースプロキシ]
        end

        subgraph "Docker Engine"
            App1[Next.js アプリ]
            App2[Rails アプリ]
            App3[WordPress]
            DB1[(MariaDB)]
            DB2[(Redis)]
            More["他のコンテナ..."]
        end
    end

    EndUser -->|HTTPS| CF
    CF -->|Tunnel| Tunnel
    Tunnel --> Traefik
    Traefik --> App1
    Traefik --> App2
    Traefik --> App3
    App1 --> DB2
    App3 --> DB1

    Admin -->|HTTPS| UI
    GitHub -->|Webhook| API
    API -->|Build & Deploy| App1
    API -->|Build & Deploy| App2

ポイントは、CoolifyはDockerの上に乗る管理レイヤーに過ぎないということです。中で動いているのは普通のDockerコンテナです。Coolifyを外しても、コンテナはそのまま動き続けます。

ネットワーク構成：自宅サーバ vs VPS

Coolifyはどこで動かすかによってネットワーク構成が変わります。

自宅サーバの場合、インターネットに直接公開するにはポート開放が必要ですが、それはセキュリティ的にやりたくありません。Cloudflare Tunnelを使えば、自宅からOutbound接続だけで外部公開できます。ポート開放不要、固定IP不要、DDNS不要。さらにCloudflareのCDNとWAFが必然的にフロントに立つので、DDoS対策もキャッシュも無料でついてきます。自宅サーバで運用するなら、Cloudflareの裏で動かすのが一番安全だと感じています。

VPSの場合、インターネットに直接出せばよいです。CoolifyのTraefikがSSL終端してくれるので、そのまま公開できます。ただ、CDNやWAFが欲しければ別途Cloudflare等を設定する必要があるので、そこは若干面倒です。

結局、自宅サーバ + Cloudflare Tunnelの構成が、セキュリティ・コスト・手軽さのバランスが一番良い気がします。CDNが勝手についてくるのは自宅サーバならではのメリットです。ネットワーク構成の詳細は第4回で書きます。

k8sとの違い

「Dockerでサービスを管理するならKubernetesじゃないの？」と思うかもしれません。比較するとこんな感じです。

	Coolify	Kubernetes
学習コスト	低い。GUIでポチポチ	高い。YAML地獄
インストール	コマンド1発（5分）	クラスター構築が必要（数時間〜）
最小構成	サーバ1台	Control Plane + Worker Node（最低2〜3台推奨）
リソース消費	管理UI + Traefik（軽量）	Control Planeだけで数GBのRAM
スケーリング	Docker Swarmで対応可	ネイティブ対応。大規模向き
向いている規模	1〜50サービス程度	50〜数千サービス
ベンダーロックイン	なし（素のDocker）	なし（OSSだが依存は複雑）

個人サービス10〜30個の規模なら、k8sは明らかにオーバーキルです。Control Planeのリソース消費だけで、私のミニPCのRAMがかなり持っていかれます。Coolifyなら管理UI + Traefikで数百MB程度です。残りの30GBをアプリに使えます。

デプロイフロー

開発からデプロイまでの流れです。Vercelと同じ体験がセルフホストで手に入ります。

sequenceDiagram
    participant Dev as 開発者
    participant GH as GitHub
    participant Cool as Coolify
    participant Docker as Docker Engine
    participant CF as Cloudflare

    Dev->>GH: git push
    GH->>Cool: Webhook通知
    Cool->>Cool: ソースをPull
    Cool->>Cool: Nixpacks or Dockerfileでビルド
    Cool->>Docker: コンテナをデプロイ
    Cool->>Cool: Traefikルーティング設定
    Cool->>CF: SSL証明書（自動）
    CF-->>Dev: https://app.example.com で公開完了

初期構築フロー

Coolifyの導入から最初のサービス公開まで、やることは少ないです。

flowchart LR
    A[サーバを用意] --> B[Coolifyインストール<br/>コマンド1発]
    B --> C[管理UIにアクセス<br/>:8000]
    C --> D[GitHubアプリ連携]
    D --> E[プロジェクト作成]
    E --> F[アプリ追加<br/>リポジトリを選択]
    F --> G[ドメイン設定]
    G --> H[デプロイ！]

    style A fill:#f9f,stroke:#333
    style H fill:#9f9,stroke:#333

何ができるのか

Push to Deploy: GitHub / GitLab / Bitbucket / Giteaと連携。Pushしたら自動でビルド&デプロイ
リバースプロキシ自動設定: Traefikが裏で動いていて、ドメインを割り当てれば即SSL化（Let's Encrypt）
データベース管理: MariaDB、PostgreSQL、MySQL、MongoDB、Redisなどをボタンひとつで立ち上げ。自動バックアップもある
280+のワンクリックサービス: Plausible、Gitea、Uptime Kuma、n8nなど、OSSのセルフホストツールを一発でデプロイできる
PRプレビュー環境: PRごとに一時的なURLを自動生成。Vercelのプレビューと同じ
Docker Compose対応: 既存のdocker-compose.ymlがそのまま使える
複数サーバ管理: SSH接続できるサーバならリモートでも管理可能。VPSやRaspberry Piでも
API & MCP: REST APIが充実していて、MCP（Model Context Protocol）サーバーも用意されている。つまりClaude CodeなどのAIエージェントからプロンプトで操作できる（これについては第2回で詳しく書きます）

誰が使うのか

個人開発者: 月額$0で無制限にサービスをデプロイ。Vercel/Herokuの代替
スタートアップ: LLMを使ったプロトタイプを即座に外部公開してフィードバックを得る
社内ツール運用: 社内向けサービスをVPSや自社サーバに集約。SaaSの課金を減らしたいチーム

完全にセルフホストなので、データは全部自分の手元です。ベンダーロックインもありません。Coolifyをやめても、中で動いているDockerコンテナはそのまま動き続けます。

選定の決め手

ベンダーロックインなし

上のアーキテクチャ図の通り、CoolifyはDockerの管理レイヤーでしかありません。docker-compose.ymlがそのまま資産になるので、Coolifyをやめても何も失いません。

既存サービスの移行が段階的に可能

既存の20サービスは各サブドメイン（xxx.teraren.com）で運用中。Cloudflare Tunnelの設定を活かしたまま、こうやって移行できます。

Coolifyをインストール（既存サービスに影響なし）
Cloudflare Tunnelにワイルドカード設定（*.teraren.com → Coolify）を追加
既存の個別設定（xxx.teraren.com → localhost:3000）はそのまま優先される
新サービスはCoolifyにデプロイ。ワイルドカードでキャッチされる
既存サービスもCoolifyに載せ替えたら、個別設定を削除するだけ

旧環境を残したまま新環境を構築し、DNS切り替えで移行します。Blue/Green的な安心感があります。

現在の構成

移行完了後の構成がこちらです。1台のサーバで全部動いています。

項目	内容
サーバ	GMKtec NucBox M2（Core i7-11390H / 32GB RAM / 1TB SSD、53,000円）
PaaS	Coolify
プロジェクト数	5
アプリケーション数	23
データベース数	7（MariaDB×2, MySQL×2, Redis×3）
月額コスト	$0

Coolifyのダッシュボードで見ると、5プロジェクトが並んでいます。

terarenプロジェクトだけで20個近いアプリケーションが全部runningで稼働中。bank-code、corporation、postcode、train、schoolなどの各種APIサーバ、blog-redirect等のリダイレクト用コンテナ、Immich（写真管理）など。

内訳としては、Next.jsのWebアプリ、Railsアプリ、WordPress、各種APIサーバ、リダイレクト用コンテナ、Zabbix（監視）、Immich（写真管理）など。開発用と本番用で環境を分けているサービスもあるので、コンテナ数はそれなりに多いです。

これが全部、53,000円のミニPC1台で、月額$0で動いています。Vercel時代は1サービスだけで$42/月だったことを考えると、もっと早く移行すべきでした。

Before / After

指標	Before	After (Coolify)
月額コスト	$20〜$42（Vercelだけで）	$0
年間コスト	$300〜$500	$0（電気代のみ）
サービス数制限	従量課金で増加	無制限
DB	外部サービス必要	Coolify内で管理
CD	サービスごとに個別管理	Coolifyで統一
SSL	自動	自動

Beforeでは、Vercelに載っているもの、Docker直で動かしているもの、それぞれでCD（継続的デプロイ）の仕組みがバラバラでした。Next.js、Rails、WordPress、静的サイト。。。多種多様なアプリのデプロイ方法を個別に管理するのは本当に面倒でした。

Coolifyに統一したことで、全サービスが「GitHub Push→自動ビルド&デプロイ」の同じフローになりました。これはコスト削減以上に大きなメリットかもしれません。

まとめ

自宅にDockerが動くサーバがあるなら、Coolifyを入れない理由がありません。インストールはコマンド一発。

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

この記事ではCoolifyの選定理由を書きました。次回以降で、実際の運用に踏み込んでいきます。

シリーズ記事

Vercel月額$42→自宅サーバ月額$0。Coolifyで個人サービス基盤を作った話（この記事）
Coolifyインストールから「プロンプトでデプロイ」まで：Claude Code MCP実践
Coolifyハンズオン：Hono・Go・Railsを実際にデプロイしてみる
Cloudflare Tunnel×Coolify：自宅サーバを安全に外部公開する
API-firstなインフラが生き残る：LLM時代のセルフホスト戦略
ZabbixでDockerコンテナをリソース監視する：Coolify環境の可視化
Coolify環境のバックアップ戦略：6つのDBを自動ダンプ+復旧手順
Coolify環境のログ管理と障害対応：Docker + Zabbix + Discordで運用を回す

Claude Codeでプロンプト1発、MariaDBのメモリ使用量を400MB→150MBに削減した話

Thu, 12 Mar 2026 00:00:00 GMT

きっかけ

自宅サーバでWordPressを2サイト運用している。PaaS基盤にはCoolifyを使っていて、データベースにはMariaDB 11.7を採用している。

ある日、コンテナのメモリ使用量を確認したところ、MariaDBが約400MBも消費していることに気づいた。格納しているデータは合計わずか5.1MB。WordPressのブログ2つだけで、アクセス数もそこまで多くない。データに対してメモリが80倍近い。明らかにもったいない。

でも、MariaDBのチューニングパラメータは数が多く、どれをどこまで下げれば安全なのか判断するのが面倒。そこでClaude Codeに丸投げしてみました。

環境

項目	内容
DB	MariaDB 11.7 (Docker)
PaaS	Coolify
用途	WordPress 2サイト
実データ量	5.1MB（3データベース合計）
サーバメモリ	32GB
チューニング前メモリ	約400MB

問題の発見：デフォルト設定の罠

docker stats でコンテナのメモリ使用量を確認すると、MariaDBが 403.5MiB 使用していた。

MariaDBのコンテナに入って SHOW VARIABLES と SHOW GLOBAL STATUS を確認すると、メモリを大量消費しているバッファが3つ見つかった。

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
-- 134,217,728 (128MB)

SHOW VARIABLES LIKE 'aria_pagecache_buffer_size';
-- 134,217,728 (128MB)

SHOW VARIABLES LIKE 'key_buffer_size';
-- 134,217,728 (128MB)

この3つだけで 384MB。これがデフォルト設定です。

分析：バッファの現在値と実使用量

Claude Codeに現在のステータスを取得・分析させた結果がこちら。

主要バッファの使用状況

パラメータ	割当量	実使用/必要量	乖離率
`innodb_buffer_pool_size`	128MB	データ5.1MB（hit rate 98.28%）	25倍
`aria_pagecache_buffer_size`	128MB	Ariaテーブル未使用	∞
`key_buffer_size`	128MB	`Key_blocks_used = 0`	∞
`innodb_log_buffer_size`	16MB	書込み頻度低い	8倍

接続まわりの設定

パラメータ	設定値	実績	乖離率
`max_connections`	151	最大同時接続 5	30倍
`thread_cache_size`	151	作成スレッド 5	30倍
`table_open_cache`	2000	Open tables 157	12倍

key_buffer_size に至っては使用量がゼロ。MyISAMテーブルを一切使っていないのに128MBが確保されていた。

Claude Codeに投げたプロンプト

Claude CodeのPlan Modeを使い、以下の流れで作業しました。

Step 1: 現状分析のプロンプト

まずCoolify管理下のMariaDBコンテナに対して、現在のメモリ使用状況を分析させました。

MariaDB (Coolify, UUID: xxx) のメモリ使用量を分析して。
docker stats でメモリ使用量を確認し、SHOW VARIABLES / SHOW GLOBAL STATUS
から主要パラメータの設定値と実使用量を比較して。

Claude Codeは自動的にCoolifyのMCPツール経由でコンテナ内のMariaDBに接続し、SHOW VARIABLES と SHOW GLOBAL STATUS を取得して分析結果を表形式でまとめてくれた。

Step 2: チューニングプランの作成

分析結果を踏まえ、Plan Modeでチューニング計画を立てさせました。

この分析結果をもとに、メモリ使用量を100-150MBに削減するチューニングプランを作って。
安全マージンを考慮して、各パラメータの推奨値と根拠を示して。

Step 3: 実行

プランを承認し、そのまま適用まで実行させました。

チューニング設定

Claude Codeが作成した設定ファイルがこちら。

[mysqld]
# === InnoDB ===
innodb_buffer_pool_size = 32M      # 128M→32M (データ5MBに対して6倍の余裕)
innodb_log_buffer_size = 2M        # 16M→2M (書込み少ない)
innodb_log_file_size = 16M         # 96M→16M

# === Aria (未使用だが最小値に) ===
aria_pagecache_buffer_size = 8M    # 128M→8M

# === MyISAM (完全未使用) ===
key_buffer_size = 1M               # 128M→1M (Key_blocks_used=0)

# === 接続 ===
max_connections = 20               # 151→20 (最大5接続に対して4倍マージン)
thread_cache_size = 10             # 151→10

# === テーブルキャッシュ ===
table_open_cache = 256             # 2000→256 (Open=157)
table_definition_cache = 256       # 400→256

# === 一時テーブル ===
tmp_table_size = 8M                # 16M→8M
max_heap_table_size = 8M           # 16M→8M

# === ソート・バッファ (per-connection) ===
sort_buffer_size = 512K            # 2M→512K
join_buffer_size = 512K            # 256K→512K
read_buffer_size = 256K            # 128K→256K (少し増加)
read_rnd_buffer_size = 512K        # 256K→512K

設定のポイント

innodb_buffer_pool_size = 32M: データ5.1MBに対して6倍の余裕。全データがバッファプールに載るのでhit rateは維持される
key_buffer_size = 1M: 使用量ゼロなので最小値に。0にはできない（MariaDBの制約）
aria_pagecache_buffer_size = 8M: Ariaテーブルは使っていないが、内部的に一時テーブルで使われる可能性があるため8MBは残す
max_connections = 20: ピーク5接続に対して4倍マージン。WordPress + cronジョブを考慮しても十分

Coolifyでの適用手順

CoolifyではMariaDBの設定ファイルをCustom Docker Configuration経由で注入する。Claude CodeはCoolifyのAPIを使って以下の手順を自動実行した。

# 1. 設定ファイルをbase64エンコード
CONFIG=$(cat my.cnf | base64 -w 0)

# 2. Coolify API で設定を更新
curl -X PATCH "https://coolify.example.com/api/v1/databases/{uuid}" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"custom_docker_run_options\": \"--volume ...\"}"

# 3. データベースを再起動
curl -X POST "https://coolify.example.com/api/v1/databases/{uuid}/restart" \
  -H "Authorization: Bearer $TOKEN"

実際にはClaude CodeがCoolifyのMCPサーバー経由でこれらのAPIを叩いてくれるので、手動でcurlを打つ必要はなかった。

Before / After

メモリ使用量

指標	Before	After	削減率
コンテナメモリ	403.5 MiB	~150 MiB	63%削減

主要バッファの比較

パラメータ	Before	After	削減量
`innodb_buffer_pool_size`	128MB	32MB	-96MB
`aria_pagecache_buffer_size`	128MB	8MB	-120MB
`key_buffer_size`	128MB	1MB	-127MB
`innodb_log_buffer_size`	16MB	2MB	-14MB
`max_connections`	151	20	-
バッファ合計	400MB	43MB	-357MB

パフォーマンスへの影響

チューニング後もWordPressの応答に体感上の変化はなく、InnoDB buffer pool hit rateも高い水準を維持している。データ量が5.1MBで32MBのバッファプールに完全に収まっているため、性能劣化は発生しない。

検証ポイント

チューニング後に確認すべき項目をまとめる。

-- Buffer pool hit rate（95%以上ならOK）
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';

-- 一時テーブルのディスク書き出し率
SHOW GLOBAL STATUS LIKE 'Created_tmp%';

-- 接続数が上限に近づいていないか
SHOW GLOBAL STATUS LIKE 'Max_used_connections';

もしhit rateが著しく低下したり、Max_used_connections が max_connections に近づいた場合は、該当パラメータを引き上げれば対処できる。

所感：Claude Codeでのインフラ運用

今回の作業、全体でプロンプト3回、所要時間約5分で完了した。

従来なら以下のステップが必要だったはずです。

MariaDBのドキュメントを読む
SHOW VARIABLES / SHOW GLOBAL STATUS の出力を読み解く
各パラメータの意味と推奨値を調べる
安全な値を計算する
設定ファイルを書く
CoolifyのAPIで適用する

これらすべてをClaude Codeが一気通貫で実行してくれた。特に良かった点は以下。

数値分析が正確: Key_blocks_used = 0 のようなステータスから「MyISAMは完全未使用」と即座に判断
安全マージンが適切: データ5.1MBに対して32MBのバッファプールを推奨（6倍マージン）するなど、攻めすぎない設定
Coolify APIの操作も自動化: MCP（Model Context Protocol）経由でCoolifyのAPIを直接操作し、設定変更から再起動まで完了

MariaDBのチューニングに限らず、「現状を分析して→計画を立てて→実行する」というインフラ運用タスクはClaude Codeと相性が良いと感じた。特にPlan Modeで計画を人間がレビューしてから実行に移せるのが安心感がある。

データベースのメモリ設定はデフォルトのまま放置されがちですが、5分の投資で250MBのメモリを回収できるなら、やらない理由はありません。

余談：MySQLはいつから重くなったのか

昔のMySQL（5.x系あたり）には my-micro.cnf や my-small.cnf といった設定テンプレートが同梱されていて、メモリ64MB程度のマシンでも動かせるような超省メモリ設定が用意されていました。当時のデフォルト設定も控えめで、カジュアルにDBを立ち上げて開発やちょっとしたWebサイトに使うのが当たり前でした。

ところが、MySQL 8.0やMariaDB 10.x以降はそうした軽量設定テンプレートが廃止され、デフォルトの innodb_buffer_pool_size が128MBに設定されるなど、「そこそこのメモリが載っている前提」の設定に変わりました。今回のように何も考えずに立ち上げるだけで数百MBを占有する、かつての軽量高速なMySQLとは別物です。

カジュアルにDBを使いたいなら、今ならSQLiteが現実的な選択肢でしょう。サーバープロセスが不要で、ファイル1つで完結する。Litestreamを組み合わせればレプリケーションもできます。

ただ、WordPressはSQLiteに公式対応していないという矛盾があります。WP-SQLite-DBのようなコミュニティプラグインはあるものの、公式サポートではありません。結局、WordPressを使い続ける限りMySQL/MariaDBからは逃れられない。

もっとも、この記事で扱っている2つのWordPressサイトも、このブログと同様にAstroへの移行を予定しています。移行が完了すればDBコンテナごと消えるので、メモリチューニングの話自体が不要になります。最終的には静的サイトジェネレータが正義、ということかもしれません。

19年運用したWordPress 661記事をAstro + Cloudflare Pagesへ移行した手順と技術的ポイント

Tue, 10 Mar 2026 00:00:00 GMT

概要

19年運用してきたWordPressブログ（661記事、2,515画像）をAstroに移行して、Cloudflare Pagesで配信するようにしました。ホスティング費用はゼロになり、デプロイは git push だけで完了するようになりました。

この記事では移行の背景、技術スタック、実際の作業手順、苦労した点をまとめます。

WordPressの何が問題だったのか

静的コンテンツなのにDBが必要

ブログの記事は基本的に静的コンテンツです。それなのにMySQLが必要で、DBのバックアップやメンテナンスが発生します。

スナップショットが面倒

WordPressのデータは3箇所に分散しています。

MySQL - 記事本文、メタデータ
wp-content/uploads/ - 画像ファイル
テーマ・プラグイン - PHP設定

バックアップするには mysqldump + rsync が必要で、復元するにも両方を揃えないとサイトが壊れます。Gitで丸ごと管理できない。

画像のサムネイル地獄

WordPressは画像を1枚アップロードすると、自動的にサムネイルを大量生成します。

IMG_1234.jpg          ← オリジナル
IMG_1234-150x150.jpg  ← thumbnail
IMG_1234-300x200.jpg  ← medium
IMG_1234-768x512.jpg  ← medium_large
IMG_1234-1024x683.jpg ← large
IMG_1234-1536x1024.jpg
IMG_1234-2048x1365.jpg
...

2,515枚のアップロードに対して、サムネイルまで含めると数万ファイルになります。実際にこのブログでは参照されていない画像ファイルが3,250個（数 GB）も蓄積していました。

LLMとの相性が悪い

LLMで記事を書いたり校正したりすることが増えてきましたが、WordPressだとDBの中にあるコンテンツを取り出してLLMに渡す必要があります。Markdownファイルならエディタやターミナルからそのまま渡せます。Claude Codeにディレクトリを渡すだけで記事を書いてもらえるのは圧倒的に楽です。

フロントエンドのアセットパイプラインがない

WordPressにはビルドパイプラインがないので、画像の最適化（WebP変換、リサイズ）をビルド時に自動実行する仕組みがありません。プラグインで対応できますが、PHPベースの処理なので遅いし制約が多い。

リンク切れ・ゴミファイルが検出しづらい

19年運用していると、記事から参照されなくなった画像やファイルがどんどん溜まっていきます。WordPressのメディアライブラリは「どの記事からも参照されていないファイル」を検出する機能がありません。

実際にこのブログを調査したところ、参照されていないファイルが 3,250個（数 GB） も蓄積していました。WordPressのDB内のHTMLと wp-content/uploads/ のファイルを突き合わせないと検出できないので非常に面倒です。

Astroに移行した後は、Markdownファイルからの参照をgrepで簡単に調べられるので、不要ファイルの検出がシンプルになりました。

移行先の検討

MicroCMS + Next.js

最初はHeadless CMSの MicroCMS と Next.js の組み合わせを検討した。しかし、Vercelのホスティング費用がかかる。個人ブログにそこまでコストをかけたくない。

Astro + Cloudflare Pages

Astroを試してみたところ、これがドンピシャでした。

まず小さめのWordPressサイトを5つほどAstroに移行してみて、問題がないことを確認してからメインブログの移行に取り掛かりました。トータルで10サイト近くAstroに移行しましたが、最後に残ったのが3サイトで、このメインブログはそのうちの1つです。

今回の移行では Claude Code（Opus 4.5）を全面的に活用した。Opus 4.5は賢くて、移行作業の8割方は半自動で進められた。コンテンツ変換、frontmatter生成、リダイレクトルール作成、プラグイン実装といった定型作業は指示を出すだけでほぼ自動で完了し、半日で一通り動く状態になりました。ただし、残りの2割（UIの微調整、デザインの仕上げ、コンテンツの整理）にはもう半日かかりました。LLMが苦手なのは「見た目の良し悪し」や「コンテンツとして何を残すか」の判断で、そこは人間の目が必要です。

技術スタック

最終的に採用した構成です。

レイヤー	技術	用途
SSG	Astro 5.18	静的サイト生成
テーマ	Fuwari	ブログテンプレート
CSS	Tailwind CSS 4	スタイリング
UI	Svelte 5	インタラクティブコンポーネント
Markdown拡張	MDX, remark, rehype	カスタムコンポーネント
画像最適化	sharp	ビルド時にWebP変換・リサイズ
全文検索	Pagefind	クライアントサイド検索
コードハイライト	Expressive Code	シンタックスハイライト
数式	KaTeX	LaTeX数式レンダリング
コメント	Giscus	GitHub Discussions連携
ホスティング	Cloudflare Pages	CDN配信（無料枠）
CI/CD	GitHub Actions	自動ビルド・デプロイ
Linter	Biome	フォーマット・lint

Remark/Rehypeプラグイン構成

Markdownの拡張にはremark/rehypeのプラグインを多数使っています。

// astro.config.mjs
markdown: {
  remarkPlugins: [
    remarkMath,           // LaTeX数式
    remarkReadingTime,    // 読了時間計算
    remarkExcerpt,        // 記事の抜粋生成
    remarkDirective,      // カスタムディレクティブ
    remarkSectionize,     // セクション分割
    remarkMdxGlobalComponents,
  ],
  rehypePlugins: [
    rehypeKatex,          // KaTeX数式レンダリング
    rehypeSlug,           // 見出しにID付与
    rehypeUnwrapImages,   // 画像のリンクラッピング解除
    rehypeImageSize,      // 画像サイズ自動取得
    [rehypeComponents, {  // カスタムコンポーネント
      components: {
        github: GithubCardComponent,
        amazon: AmazonCardComponent,
        note: (x, y) => AdmonitionComponent(x, y, "note"),
        tip: (x, y) => AdmonitionComponent(x, y, "tip"),
      },
    }],
    [rehypeAutolinkHeadings, { behavior: "append" }],
  ],
},

コンテンツスキーマ

Astroの Content Collections でfrontmatterのスキーマを定義しています。

// src/content/config.ts
const postsCollection = defineCollection({
  schema: z.object({
    title: z.string(),
    published: z.date(),
    updated: z.date().optional(),
    draft: z.boolean().optional().default(false),
    description: z.string().optional().default(""),
    image: z.string().optional().default(""),
    tags: z.array(z.string()).optional().default([]),
    category: z.string().optional().nullable().default(""),
  }),
});

WordPressの wp_posts テーブルにバラバラに格納されていたメタデータが、frontmatterとして1ファイルにまとまりました。

---
title: ブログのCMSをWordPressからAstroに移行した
published: 2026-03-10
category: "Programming"
tags: ["WordPress", "Astro", "Cloudflare"]
image: "../../assets/uploads/2026/03/cover.png"
---

本文はMarkdownで書く。これが全て。

移行作業の実際

移行は74コミットで完了しました。Gitのログから主要な作業フェーズを振り返ります。

Phase 1: 初期移行

43a2057 feat: switch to Fuwari blog template with migrated content
be433be feat: add blog uploads (images) via Git LFS
f2f02b0 feat: set featured images from WordPress thumbnail metadata
13c2cfd fix: correct featured image URLs using wp_get_attachment_url
797fe8f fix: convert WordPress/Cocoon shortcodes to standard Markdown/HTML

Claude Codeに「WordPressのディレクトリをAstro Fuwariテーマで動くように移行して」と指示しました。WordPressのHTMLをMarkdownに変換して、frontmatterを生成する作業を自動でやってくれます。

ただし、一発でうまくいくわけではないです。WordPress/Cocoonテーマ固有のショートコードやブロックパターンの変換が必要でした。

Phase 2: 機能追加

ad849b0 feat: add Amazon MDX component, OGP, GTM, redirects, 404 page
a064cc3 feat: generate OG images for 39 posts without featured images
6046ae5 feat: add Giscus comment system powered by GitHub Discussions
88fea73 feat: add related posts, Japanese nav, remove GitHub link from header

WordPressで使っていた機能をAstroで再実装しました。

Amazonアフィリエイトコンポーネント

WordPressではAmazonリンクをプレーンなHTMLやプラグインで書いていましたが、Astroでは自作のrehypeプラグインでカスタムコンポーネントとして処理しています。Markdownで ::amazon{asin="..."} と書くだけで商品カードがレンダリングされます。

::amazon{asin="B0CKWS1VWR"}

商品データ（タイトル、価格、画像URL、レビュー数）はAmazon PA-APIから事前にフェッチして amazon-products.json に保存しておき、ビルド時に読み込みます。

// src/plugins/rehype-component-amazon.mjs（抜粋）
let amazonProducts = {};
try {
  const dataPath = join(process.cwd(), "src", "data", "amazon-products.json");
  amazonProducts = JSON.parse(readFileSync(dataPath, "utf-8"));
} catch (error) {
  console.warn("[AMAZON] Failed to load amazon-products.json:", error.message);
}

export function AmazonCardComponent(properties, children) {
  const asin = properties.asin;
  const productData = amazonProducts[asin];
  const affiliateUrl = productData?.detailPageUrl
    || `https://www.amazon.co.jp/dp/${asin}?tag=${AFFILIATE_TAG}`;
  const title = productData?.title || "";
  const imageUrl = productData?.imageUrl || "";
  // ... hastscriptでカード要素を構築
  return h("a", { class: "card-amazon", href: affiliateUrl, target: "_blank" }, [
    nImage, h("div", { class: "az-info" }, [nTitle, ...priceElements, nButton]),
  ]);
}

MDXファイルでは ::amazon{asin="..."} というJSXコンポーネントも使えるように、remarkプラグインで自動importを挿入しています。

実際のレンダリング結果はこんな感じです。

::amazon{asin="4297150085"}

URLの自動埋め込み（astro-embed）

YouTubeやX(Twitter)のURLをMarkdownにそのまま貼るだけで、自動的にembedカードに変換されます。astro-embedを使っています。

<!-- こう書くだけでYouTubeが埋め込まれる -->
https://www.youtube.com/watch?v=9TVkrzxjNRo

<!-- Xのポストも同様 -->
https://x.com/matsubokkuri/status/1893168256317563150

WordPressのoEmbedと同じ体験がMarkdownで実現できます。

Phase 3: 画像最適化

7bf0764 feat: move images to src/assets for build-time optimization
7214b99 refactor: move OG images from public/og to src/assets/og
318eb07 chore: remove 3250 unreferenced upload files (566 MB)

これが一番大変でした。WordPressの wp-content/uploads/ にあった画像を src/assets/uploads/ に移動することで、Astroのビルドパイプライン（sharp）による最適化対象にしました。

画像をpublicディレクトリからsrc/assetsに移すことで、ビルド時に自動的にWebP変換とリサイズが行われます。

参照されていない画像ファイルが3,250個（数 GB）もあったので、全て削除しました。さらにGit履歴からも git-filter-repo で完全に消して、リポジトリサイズを3.7GBから2.4GBに縮小しました。

Phase 4: URL互換性

1e74d38 refactor: rename multibyte post filenames to ASCII
9a54209 fix: update redirects for renamed Japanese slug posts

WordPressは /YYYY/MM/DD/slug/ というURL構造でしたが、Astroでは /posts/slug/ になります。SEO上の影響を最小化するため、973件の301リダイレクトルールを生成しました。

# public/_redirects
/2003/06/05/php/ /posts/php/ 301
/2024/08/02/stop-using-url-shortener-services/ /posts/stop-using-url-shortener-services/ 301
...

canonical URLも旧WordPress形式で出力するようにして、Googleの検索インデックスを引き継ぎました。

// src/pages/posts/[...slug].astro
const pubDate = entry.data.published;
const yyyy = pubDate.getFullYear().toString();
const mm = (pubDate.getMonth() + 1).toString().padStart(2, "0");
const dd = pubDate.getDate().toString().padStart(2, "0");
const canonicalUrl = new URL(
  `/${yyyy}/${mm}/${dd}/${entry.slug}/`, Astro.site
).href;

Phase 5: Tailwind CSS v3 → v4

36bfa03 feat: migrate Tailwind CSS v3 to v4
d3f9e66 fix: move text-* utilities from @layer components to @utility for TW4

Fuwariテーマ自体がTailwind CSS v3ベースだったので、v4への移行が必要でした。

Tailwind 4では @layer components の中に書いたスタイルの優先度が大きく変わりました。@layer 内のスタイルは @layer 外のスタイルより常に優先度が低いため、開発サーバーでは動くのに本番ビルドでスタイルが崩れるという厄介なバグにハマりました。

/* BAD: @layer内のスタイルは優先度が低い */
@layer components {
  .meta-icon {
    @apply mr-1.5;  /* 本番ビルドで効かない！ */
  }
}

/* GOOD: @layer外に書く */
.meta-icon {
  margin-right: 0.375rem;
  background-color: var(--btn-regular-bg);
  color: var(--btn-content);
}

Phase 6: 仕上げ

d49c8a2 feat: add social sharing, sponsor button, and improve Amazon cards
1d10317 feat: add PA-API product data fetcher for Amazon affiliate cards
20a7448 refactor: update 121 internal links from old WordPress URLs to new paths
16ca3bf feat: add internal blog post link card component
9185ee9 refactor: remove dead rehypeImageSize plugin, fix tweet script duplication

最後の仕上げとして、以下の作業をしました。

SNSシェアボタン: X（Twitter）シェアとはてなブックマークボタンを記事ページに追加
Amazonアフィリエイト強化: Amazon PA-APIから商品データ（タイトル、価格、画像、レビュー数）を自動取得するスクリプトを作成
内部リンクカード: 自サイトへのURLを自動的にブログカード形式で表示するremarkプラグインを実装。OGPフェッチ不要で、ビルド時にfrontmatterから直接データを取得
旧URLの一括更新: 記事中の121箇所の旧WordPress URL（/YYYY/MM/DD/slug/形式）を新しいパス（/posts/slug/形式）に書き換え
画像のフルサイズ配信: ライトボックス（PhotoSwipe）でオリジナル解像度の画像を表示できるように、画像幅の800px制限を撤廃
OGP画像の正常化: 記事のfeature imageを og:image に使用するように修正。フォールバック用のデフォルト画像も配置
X（Twitter）埋め込み: widgets.js を動的ロードして、ツイートの画像・メディアが正しく表示されるように対応

デプロイパイプライン

GitHub Actionsでビルドして、Cloudflare Pagesにデプロイしています。

# .github/workflows/deploy.yml
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22 }
      - uses: pnpm/action-setup@v4
      - run: pnpm install --frozen-lockfile
      - run: pnpm build  # astro build && pagefind --site dist
      - uses: cloudflare/wrangler-action@v3
        with:
          command: pages deploy dist --project-name=blog
      # CDNキャッシュも自動パージ
      - run: |
          curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE/purge_cache" \
            -H "Authorization: Bearer $TOKEN" \
            --data '{"hosts":["blog.teraren.com"]}'

git push するだけで、ビルド → デプロイ → CDNキャッシュパージまで自動で走ります。

実際のGitHub Actionsワークフローの実行画面です。Biome、textlint、Build、Deployの4ジョブが並列・直列で実行されています。

WordPress機能の代替

「静的サイトだとWordPressの○○ができないのでは？」という懸念があると思います。主要な機能の代替方法をまとめます。

全文検索 → Pagefind

WordPressの検索はMySQL上で LIKE クエリを実行していましたが、静的サイトでも全文検索はできます。Pagefindはビルド時に静的なインデックスファイルを生成し、クライアントサイドでFTS（Full Text Search）を実行します。

// package.json
{
  "scripts": {
    "build": "astro build && pagefind --site dist"
  }
}

ビルドの最後に pagefind を実行するだけで、日本語対応の検索インデックスが自動生成されます。検索UIはSvelteで実装して、インクリメンタルサーチに対応しています。DBを使わない検索がこんなに手軽にできるとは思っていませんでした。

コメント → Giscus

WordPressの組み込みコメント機能の代わりにGiscusを使っています。GitHub Discussionsをバックエンドにしたコメントシステムで、記事のパス名にマッピングされます。

<!-- src/components/Giscus.astro -->
<script
  src="https://giscus.app/client.js"
  data-repo="matsubo/blog-giscus"
  data-mapping="pathname"
  data-theme="preferred_color_scheme"
  data-lang="ja"
  data-loading="lazy"
  async
></script>

コメントデータはGitHubに保存されるので、自前でDBを管理する必要がありません。ダークモードの切り替えにも postMessage で連動させています。

Before / After

	WordPress	Astro
記事数	661（MySQL内）	664（.md/.mdx）
画像	2,515 + サムネイル数万	1,632（最適化済み）
ホスティング	VPS (Docker)	Cloudflare Pages
デプロイ	手動 or プラグイン	`git push`
バックアップ	mysqldump + rsync	`git clone`
コスト	~$10/月	$0
全文検索	MySQL LIKE	Pagefind（クライアントサイド）
コメント	WordPress組み込み	Giscus（GitHub Discussions）
ビルド出力	—	349 MB（静的HTML）

苦労した点

304記事のMarkdownフォーマット修正

WordPressからの変換で壊れたMarkdownを手作業で修正しました。インデントのずれ、HTMLタグの残骸、Cocoonショートコードの変換漏れなど。

単純置換、正規表現で処理できるところは機械的に行いましたが、それだけでは取り切れないフォーマット変換時のゴミや誤変換が多くて、結局は全記事をOpus 4.5にparseさせることで正常化しました。

特に、code blockのアノテーションにおいてソースコードなのかシェルの出力なのかを今までは区別しないでpreタグで囲っていましたが、今回はその部分もアノテーションで区別するようにすることで読みやすくなりました。

画像パスの移行

WordPressは画像を wp-content/uploads/YYYY/MM/ に格納しますが、Astroで画像最適化を有効にするには src/assets/ 配下に移す必要があります。一旦画像はすべてコピーしてpathを機械的に置換したうえで、未参照の画像やサムネ画像を正規表現で置換しました。

WordPressでのマークアップは画像を表示しつつ、Aタグで拡大画像にリンクを貼るというフォーマットに統一していましたが、Markdownに統一することで1つのオリジナル画像を指定しておくだけで済むようにし、build時に拡大用のマークアップをするようにしてます。

日本語スラッグの扱い

WordPressは日本語スラッグを許容しますが、ファイル名に日本語が入っているとビルドやデプロイで問題が起きる可能性があります。マルチバイトのスラッグを全てASCIIにリネームして、リダイレクトルールを追加しました。

良い点

コストゼロ: Cloudflare Pagesの無料枠で十分。月10ドルの節約
速い: 静的サイトでCDN配信。体感で明らかに速い
Gitで管理: git log で記事の変更履歴が全て追える
LLMフレンドリー: ディレクトリごとClaude Codeに渡すだけで記事を書いてもらえる
アセット最適化: sharpによるビルド時WebP変換・リサイズ

悪い点

WYSIWYGエディタがない: WordPressのJetpackアプリのように、スマホからサクッと記事を書けない。Markdownエディタが必要。ちょうどVS Codeならこのようなプラグインが出てました。
ビルド時間: 664記事のビルドはそれなりに時間がかかる。GitHub Actionsのランナーで数分

Lighthouseスコア

移行後のLighthouseスコアです。

メトリクス	スコア
Performance	85
Accessibility	93
Best Practices	81
SEO	100
First Contentful Paint	2.6s
Largest Contentful Paint	3.4s
Total Blocking Time	200ms
Cumulative Layout Shift	0.001

SEOは満点。静的HTMLをCDNから配信しているので、CLSはほぼゼロです。PerformanceはSwupのページ遷移アニメーションやWebフォントの読み込みがあるので85ですが、体感は十分速いです。

個人ブログとZennの棲み分け

Astroで自前ブログを構築したものの、技術記事の発信先としてZennも併用しており、棲み分けは悩みどころです。

	個人ブログ	Zenn
読者層	検索流入、既存読者	Zennコミュニティ、エンジニア
SEO	自分でコントロール可能	Zennドメインの強さに乗れる
デザイン	完全に自由	Zennのフォーマット固定
収益化	アフィリエイト自由	バッジ（投げ銭）
所有権	自分のドメイン・リポジトリ	プラットフォーム依存

現時点の方針としては、技術的にニッチな記事やガジェットレビュー、生活系の記事は個人ブログへ、汎用的な技術Tipsや他のエンジニアに届けたい記事はZennへ書くようにしています。ただ、明確な基準があるわけではなく、書きながら判断しているのが正直なところです。

textlintで日本語の品質を底上げ

移行後の仕上げとして、日本語文章のlinterであるtextlintを導入しました。コードにESLintがあるように、日本語の文章にもlinterを入れることで、タイポや読みにくい表現を機械的に検出できます。

導入したプラグイン

パッケージ	用途
textlint-rule-preset-ja-technical-writing	技術文書向けの日本語ルール集
textlint-plugin-mdx	MDXファイルの解析対応
textlint-filter-rule-comments	HTMLコメントによるルール無効化

設定方針

テックブログは書籍のような堅い文体を求められないため、ガチガチのフォーマットルールは無効にし、読みやすさとタイポ検出に絞りました。

有効にしたルール（読みやすさ・タイポ）:

{/* textlint-disable */}

ja-no-successive-word — 同じ単語の連続（「にに」「をを」等のタイポ）
ja-no-redundant-expression — 冗長表現（「○○を行う」→「○○する」） {/* textlint-enable */}
no-unmatched-pair — 括弧の閉じ忘れ
sentence-length — 長すぎる文（200文字超）
no-dropping-the-ra — ら抜き言葉
no-invalid-control-character — 不正な制御文字

無効にしたルール（ブログには不要）:

no-mix-dearu-desumasu — ですます/である調の混在（ブログでは自然）
preset-jtf-style — JTF日本語標準スタイルガイド全般（半角/全角かっこ、箇条書き句点統一など）
max-ten / max-comma — 読点・カンマの数制限

効果

661記事に対して実行したところ、初回で約300件のエラーが検出されました。内訳は冗長表現、タイポ（助詞の重複や文字の二重入力）、括弧の閉じ忘れが大半です。WordPress時代には気づけなかった問題が一括で洗い出せたのは、Markdownファイルとしてファイルシステム上にコンテンツがあるからこそです。

CIにもBiomeと並列でtextlintを実行するジョブを追加しているため、今後の記事でも品質が自動的に担保されます。

// .textlintrc.json（抜粋）
{
  "rules": {
    "preset-ja-technical-writing": {
      "sentence-length": { "max": 200 },
      "no-mix-dearu-desumasu": false,
      "ja-no-successive-word": { "allow": ["。", "！", "？", "…", "・", "○"] },
      "ja-no-redundant-expression": true,
      "no-unmatched-pair": true,
      "no-dropping-the-ra": true
    },
    "preset-jtf-style": false
  }
}

まとめ

WordPressからAstroへ移行しました。初期構築に半日、仕上げに2日間ぐらいかかりました。

19年分のコンテンツをMarkdownファイルとしてGitリポジトリに格納し、Cloudflare CDNから配信する。DBもVPSも不要。Claude Codeに移行作業を手伝ってもらったおかげで、661記事の移行も現実的な工数で完了しました。

LLMの活用が進む中で、コンテンツがMarkdownファイルとしてファイルシステム上にあることの価値はますます大きくなると思います。残りの2サイトも同じようにすすめます。

Claude Code (Max plan) の使用率を tmux / Starship に表示する

Mon, 02 Mar 2026 00:00:00 GMT

3秒まとめ

Claude Code Max プランの5時間セッション使用率と週間使用率をカラーバーで表示
tmux TPM プラグインと Starship カスタムモジュールの両方に対応
OAuth トークンで使用率 API を叩き、キャッシュ付きで負荷を最小限に抑える設計

どんな人向けの記事？

Claude Code の Max プランを使っていて、残りの使用枠を常に把握したい方
tmux や Starship でターミナル環境をカスタマイズしている方
CLI 環境を自分好みにいじるのが好きな方

ステータスバーの右側に、Claude Code の使用率がカラーバーで表示されています。左のバーが5時間セッション使用率、右が週間使用率です。使用率に応じて緑→黄→赤と色が変わるので、パッと見で残りの枠が分かります。

背景：なぜ tmux に表示したいのか

Claude Code を Max プランで使っていると、「今どれくらい使ったかな？」って気になりますよね。

/usage コマンドで確認できるけど、作業中にわざわざコマンドを打つのは面倒です。tmux のステータスバーに常時表示しておけば、コーディングしながらチラッと目をやるだけで使用状況が分かります。

仕組み

graph LR
    A[tmux status-interval<br/>5秒ごと] -->|#実行| B[tmux-claude.sh]
    B --> C{キャッシュ<br/>有効?}
    C -->|有効| D[キャッシュ値を表示]
    C -->|期限切れ| E[古い値を表示]
    E -->|バックグラウンド| F[API から取得]
    F --> G[キャッシュ更新]
    C -->|キャッシュなし| H[API から取得して表示]

ポイントは以下の3つです。

OAuth トークンで使用率 API を呼び出し: Claude Code が保持している OAuth トークンを使って、Anthropic の使用率 API からセッション/週間の利用率を取得
5分間キャッシュ: API を毎回叩くのは無駄なので、取得結果を /tmp にキャッシュ。期限切れ時も古い値を即表示しつつバックグラウンドで更新
tmux カラーコード出力: スクリプトの stdout に #[fg=色] 形式の tmux フォーマットコードを含めることで、カラフルなバー表示を実現

インストール

この仕組みを tmux TPM プラグインと Starship カスタムモジュールとして公開しました。

https://github.com/matsubo/claude-code-max-usage

tmux (TPM プラグイン)

TPM (Tmux Plugin Manager) を使っている方は、~/.tmux.conf に2行追加するだけです。

# プラグイン追加
set -g @plugin 'matsubo/claude-code-max-usage'

# status-right に組み込む
set -g status-right "#{claude_usage}"

prefix + I でインストールしたら完了です。

コンパクト表示（バーなし、パーセントのみ）もあります。

# コンパクト表示: 22%/14%
set -g status-right "#{claude_usage_compact}"

Starship カスタムモジュール

Starship を使っている方は ~/.config/starship.toml に追加します。

[custom.claude]
command = "/path/to/claude-code-max-usage/scripts/claude_usage_starship.sh"
when = "test -f ~/.claude/.credentials.json"
format = "[$output]($style) "
style = ""
shell = ["bash", "--noprofile", "--norc"]

tmux と Starship でキャッシュを共有しているので、両方使っても API コールは5分に1回だけです。

カスタマイズ

色やしきい値は tmux オプションまたは環境変数で変更できます。

set -g @claude_usage_cache_ttl 600        # キャッシュ 10分
set -g @claude_usage_threshold_warn 40    # 黄色のしきい値
set -g @claude_usage_threshold_crit 70    # 赤のしきい値

詳細は README を参照してください。

技術的なポイント

OAuth トークンの取得

Claude Code は OAuth 認証情報を ~/.claude/.credentials.json に保存しています。ここから claudeAiOauth.accessToken を取得して API リクエストに使います。

jq -r '.claudeAiOauth.accessToken' ~/.claude/.credentials.json

使用率 API

Anthropic の使用率 API は以下のエンドポイントです。

curl -s \
    -H "Authorization: Bearer $TOKEN" \
    -H "anthropic-beta: oauth-2025-04-20" \
    "https://api.anthropic.com/api/oauth/usage"

レスポンスはこんな形で返ってきます。

{
  "five_hour": {
    "utilization": 22,
    "resets_at": "2026-03-02T15:00:00Z"
  },
  "seven_day": {
    "utilization": 14,
    "resets_at": "2026-03-08T00:00:00Z"
  }
}

five_hour.utilization が5時間枠の使用率（%）、seven_day.utilization が週間の使用率（%）です。/usage コマンドで表示される値と完全に一致します。

tmux のカラー出力

tmux の #() コマンド置換では、出力に tmux フォーマットコード（#[fg=色]）を含めることができます。これを利用して、スクリプトの stdout にカラーコードを埋め込んでいます。

# 使用率 50% 未満は緑、80% 未満は黄、それ以上は赤
printf "#[fg=#a6da95]██#[fg=#7a839e]░░░#[fg=#a6da95]22%%"

printf で % を出力するには %% と書きます。tmux の #() 出力では strftime 処理が走らないため、%% がそのまま % として表示されます。%%%% にすると %% が表示されてしまうので注意です。 </div>

キャッシュ戦略

API を毎回叩くとレートリミットに引っかかる可能性があるので、5分間のキャッシュを設けています。

graph TD
    A[スクリプト実行] --> B{キャッシュファイル<br/>存在する?}
    B -->|No| C[同期的に API 取得]
    C --> D[キャッシュに保存]
    D --> E[結果を出力]
    B -->|Yes| F{5分以内?}
    F -->|Yes| G[キャッシュ値を出力]
    F -->|No| H[古いキャッシュ値を出力]
    H --> I{ロック取得<br/>できる?}
    I -->|Yes| J[バックグラウンドで<br/>API 取得 & 更新]
    I -->|No| K[別プロセスが<br/>更新中なのでスキップ]

ポイントは、キャッシュ期限切れでも古い値を即座に返すこと。バックグラウンドで更新するので、ユーザーは待たされません。mkdir によるロックで二重実行も防止しています。

iOS 端末での対策

Termius などの iOS ターミナルから接続すると、Nerd Font アイコンやブロック文字（█、░）が倍幅レンダリングされてステータスバーが崩れることがあります。

tmux の #{client_width} を使った条件分岐で、狭い端末ではコンパクト表示に切り替えています。

set -g status-right "#{?#{e|>=:#{client_width},120},<フル表示>,<コンパクト表示>}"

依存ツール

jq: JSON パース
cURL: API リクエスト
Nerd Font: アイコン表示（オプション）

まとめ

Claude Code の使用率を tmux や Starship に表示することで、コーディング中でも残りの枠を意識できるようになりました。特に Max プランでは5時間ウィンドウの制限があるので、「あとどれくらい使えるか」がチラ見で分かるのはめちゃくちゃ便利です。

TPM プラグインとして公開したので、set -g @plugin の1行で導入できます。Starship ユーザーもカスタムモジュールとしてすぐに使えます。カラーパレットやしきい値も変更できるので、好みに合わせていじってみてください。

https://github.com/matsubo/claude-code-max-usage

おまけ

https://x.com/matsubokkuri/status/2028549242973983206

17万9千座の山頂データをサブ10msで検索するPWAをClaude Codeで開発した

Thu, 26 Feb 2026 00:00:00 GMT

3秒まとめ

{/* textlint-disable ja-technical-writing/ja-no-weak-phrase */}

SOTA（Summits On The Air） という山岳アマチュア無線のプログラム用の山頂検索PWAを作った
SQLite Wasm + R*Tree空間インデックス で17万9千座の山をサブ10msで検索できる超高速アプリ
自分ではコードを1行も書いていない。 Claude Codeとfrontend-designスキルだけで開発した
PWA対応で 完全オフライン動作。山の上で電波がなくても使える
インフラ費用は完全無料。 GitHub Pages + GitHub Actionsだけで運用

{/* textlint-enable ja-technical-writing/ja-no-weak-phrase */}

どんな人向けの記事？

PWAやSQLite Wasmなど、ブラウザの最新技術に興味がある人
Claude Codeでアプリ開発をしてみたい人
位置ゲー好きな人（Ingress勢、ポケGO勢）
個人開発でインフラ費用ゼロを目指したい人

完成したアプリ

https://matsubo.github.io/sota-peak-finder/

{/* textlint-disable ja-technical-writing/ja-no-weak-phrase */}

まず完成品をお見せします。「SOTA Peak Finder」は、世界中の 17万9,527座 のSOTA対象山頂を検索できるPWAです。

{/* textlint-enable ja-technical-writing/ja-no-weak-phrase */}

ダッシュボード画面。世界中のSOTA統計情報が一目でわかる

そもそもSOTAってなに？

{/* textlint-disable ja-technical-writing/ja-no-weak-phrase */}

SOTA（Summits On The Air） は、登山とアマチュア無線を組み合わせた世界的なプログラムです。2002年にイギリスで始まりました。

ざっくり言うと、山に登って、山頂から無線で4局以上と交信すると、ポイントがもらえる というプログラムです。山が高いほど、冬季はさらにポイントが多くもらえます。たとえば 富士山（JA/SO-001）は10ポイント（最高値）、高尾山（JA/TK-034）は2ポイント。1,000ポイント貯めると「Mountain Goat（山のヤギ）」というトロフィーがもらえる。富士山でも100回登らないと届かない計算です。こういうの燃えません？

{/* textlint-enable ja-technical-writing/ja-no-weak-phrase */}

graph TD
    A[山頂に登る 🏔️] --> B[無線機をセットアップ 📻]
    B --> C[4局以上と交信 📡]
    C --> D[ポイントゲット！ 🎯]
    D --> E{1000pt到達？}
    E -->|Yes| F[Mountain Goat 🐐]
    E -->|No| A

{/* textlint-disable ja-technical-writing/ja-no-weak-phrase */}

参加者には2種類います。

アクティベーター: 自分で山に登って山頂からQRV（無線で電波を出す）する人
チェイサー: 自宅や別の場所からアクティベーターと交信する人

私のコールサインは JE1WFV です。アクティベーターとして山に登って無線運用しています。

{/* textlint-enable ja-technical-writing/ja-no-weak-phrase */}

作った背景 ― 位置ゲーマーの血が騒ぐ

{/* textlint-disable ja-technical-writing/ja-no-weak-phrase */}

{/* textlint-disable spellcheck-tech-word */}

私は 位置ゲーが大好き です。Ingressを長いことやっていました。ポータルを巡って街を歩き回る、あの感覚がたまらないんですよね。

で、アマチュア無線を始めて SOTA を知ったとき、「これ、位置ゲーじゃん！」って思ったんですよ。

{/* textlint-enable spellcheck-tech-word */}

{/* textlint-enable ja-technical-writing/ja-no-weak-phrase */}

特定の場所（山頂）に行く → Ingressのポータル巡りと同じ
ポイントを貯める → ゲーミフィケーション
世界中にスポットがある → グローバルな位置ゲー
レアなスポット（未踏峰）がある → コンプ欲を刺激

しかも私は トレイルランニング もやっています。トレランで山を走れば、1日で複数の高ポイント山頂を回れる。SOTAのポイントを効率よく稼ぐのにトレランとの相性が抜群なんです。逆に言えば、SOTAが トレランで山を走る目的 にもなる。「次はあの山頂をアクティベートしよう」と思えば、トレーニングのモチベーションも上がります。

{/* textlint-disable ja-technical-writing/ja-no-weak-phrase */}

ただ、SOTAには1つ大きな課題がありました。

近くのSOTA対象の山を探すのがめちゃくちゃ面倒。

公式サイトのデータベースは検索しにくいし、一覧性がないし、オフラインで使えない。しかも登山中はキャリアの電波が届かないことが多い。山の中腹から山頂にかけて圏外になるのは日常茶飯事です。つまり、山頂に着いてから「この山SOTAの対象だっけ？」と調べようとしても、そもそもネットにつながらない。だからデータをローカルに持つPWAが必要なんです。

ないなら作ろう。

{/* textlint-enable ja-technical-writing/ja-no-weak-phrase */}

技術スタック

{/* textlint-disable ja-technical-writing/ja-no-weak-phrase */}

今回の開発で使った技術スタックはこちらです。

{/* textlint-enable ja-technical-writing/ja-no-weak-phrase */}

カテゴリ	技術
フロントエンド	React 19 + TypeScript 5
ビルドツール	Vite 5
データベース	SQLite Wasm（@sqlite.org/sqlite-wasm v3.52.0）
空間インデックス	R*Tree
PWA	vite-plugin-pwa + Service Worker
スタイリング	Tailwind CSS
デプロイ	GitHub Pages + GitHub Actions
データ更新	GitHub Actions（毎週日曜自動更新）

graph LR
    subgraph Browser
        React[React 19] --> SQLite[SQLite Wasm]
        SW[Service Worker] --> React
    end

    subgraph GitHub
        Actions[GitHub Actions] --> Pages[GitHub Pages]
    end

    SOTA[SOTA CSV Data] --> Actions
    Pages --> SW

主な機能

ダッシュボード

ホーム画面では世界中のSOTA統計情報を俯瞰できます。最高峰・最低峰、高ポイント山頂、人気の山頂、まだ誰もアクティベートしていない未踏峰など。

統計情報セクション。山頂の数だけ見ても世界規模のプログラムだとわかる

GPS検索 ― 近くの山を瞬時に発見

GPSボタンをタップすると、現在位置から50km以内のSOTA山頂を最大20座 表示します。距離、方位、標高、ポイント、アクティベーションゾーン内かどうかまでわかります。

GPS検索結果。距離・方位・標高・ポイントが一覧で見える

Summit一覧 & フィルタリング

{/* textlint-disable ja-technical-writing/ja-no-weak-phrase */}

17万9千座を自由にフィルタリングできます。アソシエーション（国/地域）、リージョン、標高範囲、ポイント値など、細かい条件で絞り込める。「日本のまだ誰もアクティベートしていない10ポイント峰」みたいな検索がサクサクできます。

{/* textlint-enable ja-technical-writing/ja-no-weak-phrase */}

Browse画面。多彩なフィルタで目的の山を探せる

Summit詳細ページ

各山頂の詳細ページでは、座標、Maidenheadグリッドロケーター、標高、ポイント、直近のアクティベーション履歴、さらには 7日間の天気予報 まで表示します。天気予報は標高補正済みのデータで、風速30km/h超の場合は警告も出します。

Summit詳細。天気予報まで見られるのは登山計画に便利

ブックマーク機能

{/* textlint-disable ja-technical-writing/ja-no-weak-phrase */}

各山頂ページのブックマークボタンをクリックするだけで、「Want to Go（行きたい）」→「Activated（アクティベート済み）」→ 解除 と3段階でステータスが切り替わります。登山計画と実績管理がワンタップで完結する。localStorageに保存されるのでサーバー不要、オフラインでも使えます。まさに位置ゲーの「お気に入りスポット」感覚です。

{/* textlint-enable ja-technical-writing/ja-no-weak-phrase */}

ブックマーク画面。「行きたい」と「アクティベート済み」をワンタップで切り替え

完全オフライン動作 ― 圏外の山頂でこそ真価を発揮

{/* textlint-disable ja-technical-writing/ja-no-weak-phrase */}

登山をやっている人ならわかると思いますが、山の中はキャリアの電波が届かないことがほんとうに多い。標高が高くなるほど、谷間に入るほど圏外になります。だからこそ、データをローカルに持つPWAという設計が必須 でした。

初回アクセス時にService Workerが全データ（約44MB）をキャッシュします。2回目以降は 完全オフライン で動作します。CacheFirst戦略で90日間キャッシュを保持するので、自宅でアプリを開いておけば、あとは山の上で圏外でも問題なく使えます。

正直、初回ダウンロードの約50MBは軽くはないです。リージョンごとにデータを分割して必要な地域だけダウンロードさせる設計も考えました。でも、「いま日本のデータしか入ってないから海外の山は検索できない」みたいな 機能制限を意識しながら使うストレスのほうがよっぽど大きい。初回だけ我慢すれば、あとは世界中の17万9千座がまるごと手元にある。このシンプルさを優先しました。

{/* textlint-enable ja-technical-writing/ja-no-weak-phrase */}

技術的なこだわり

SQLite Wasm + R*Tree空間インデックス ― サブ10msの秘密

{/* textlint-disable ja-technical-writing/ja-no-weak-phrase */}

今回のアプリで一番こだわったのは 検索速度 です。

17万9千座の山頂データをブラウザ内で高速に検索するために、SQLite Wasmを採用しました。しかもただのSQLiteではなく、R*Tree空間インデックス を使って緯度経度のバウンディングボックスクエリを高速化しています。

{/* textlint-enable ja-technical-writing/ja-no-weak-phrase */}

sequenceDiagram
    participant User as ユーザー
    participant App as React App
    participant SQLite as SQLite Wasm
    participant RTree as R*Tree Index

    User->>App: GPS位置取得
    App->>SQLite: 近傍検索クエリ
    SQLite->>RTree: バウンディングボックス検索
    RTree-->>SQLite: 候補の山頂群
    SQLite-->>App: 結果（< 10ms）
    App->>App: Haversine距離計算
    App-->>User: 近い順にソートして表示

{/* textlint-disable ja-technical-writing/ja-no-weak-phrase */}

処理の流れは、R*Treeで大まかな矩形範囲を絞り込み、その後JavaScriptでHaversine公式を使って正確な距離を計算してソートします。この2段階フィルタリングのおかげで、17万9千座の中から近傍の山をサブ10msで検索 できます。

JSONで同じデータを扱うと60%以上サイズが大きくなる上に、空間インデックスも使えないので検索が遅くなります。SQLite Wasmは正解でした。

{/* textlint-enable ja-technical-writing/ja-no-weak-phrase */}

注意点: SQLite Wasmでは PRAGMA journal_mode = DELETE を使う必要があります。WALモードだと sqlite3_deserialize と互換性がないためです。ここはちょっとハマりました。 </div>

PWA ― ネイティブアプリのような体験

vite-plugin-pwaを使って、Service Workerの自動生成とキャッシュ戦略を実装しています。

graph TD
    A[初回アクセス] --> B[Service Worker登録]
    B --> C[SQLite DB キャッシュ<br/>CacheFirst / 90日]
    B --> D[地図タイル キャッシュ<br/>CacheFirst / 500枚 / 30日]
    B --> E[天気API キャッシュ<br/>CacheFirst / 12時間]
    B --> F[標高データ キャッシュ<br/>CacheFirst / 30日]
    C --> G[完全オフライン動作 ✅]
    D --> G
    E --> G
    F --> G

リソース	キャッシュ戦略	有効期限
SQLiteデータベース（44MB）	CacheFirst	90日
OpenStreetMap タイル	CacheFirst	30日（最大500枚）
天気API（Open-Meteo）	CacheFirst	12時間
標高データ（国土地理院）	CacheFirst	30日
SOTA API	CacheFirst	12時間

デザインシステム ― Technical Cartography

{/* textlint-disable ja-technical-writing/ja-no-weak-phrase */}

UIデザインは 「Technical Cartography」 というコンセプトで、ヴィンテージの無線機と地形図からインスピレーションを得ています。ダークベースに琥珀色のアクセント、等高線パターン、CRTスキャンライン効果など、無線の世界観を表現しています。

{/* textlint-enable ja-technical-writing/ja-no-weak-phrase */}

Technical Cartographyデザイン。等高線パターンとネオングロウがかっこいい

背景: rgb(12, 16, 24) のダークベース
プライマリアクセント: rgb(255, 169, 51) 琥珀色（ボタン、重要データ）
セカンダリ: rgb(51, 204, 204) ティール（グリッド、ラベル）
GPS/ステータス: rgb(102, 255, 153) グリーン

フォントも3種類使い分けています。ヘッダーにRajdhani、座標データにJetBrains Mono、本文にDM Sans。技術的な雰囲気を出しつつ、読みやすさも確保しました。

Claude Codeだけで開発した話

{/* textlint-disable ja-technical-writing/ja-no-weak-phrase */}

ここが今回一番伝えたいことかもしれません。

このアプリ、自分ではコードを1行も書いていません。

全部 Claude Code で開発しました。要件を日本語で伝えて、Claude Codeがコードを生成して、テストして、コミットして、リリースまでやってくれる。v3.1.0からv3.6.0まで、機能追加もバグ修正も全部Claude Codeです。

UIデザインに関しては、Claude Codeの frontend-designスキル（Anthropic公式）を使いました。このスキルは「AIっぽいダサいUI」を避けて、プロダクションクオリティの独創的なデザインを生成してくれます。フォント選定、カラーパレット、アニメーション、背景パターンまで、全部スキルが決めてくれました。

{/* textlint-enable ja-technical-writing/ja-no-weak-phrase */}

graph LR
    A[私] -->|要件を日本語で伝える| B[Claude Code]
    B -->|コード生成| C[React + TypeScript]
    B -->|デザイン| D[frontend-design Skill]
    B -->|テスト| E[Playwright E2E]
    B -->|デプロイ| F[GitHub Actions]
    D --> C
    C --> G[SOTA Peak Finder 🏔️]

開発の流れ

{/* textlint-disable ja-technical-writing/ja-no-weak-phrase */}

要件定義: 「SOTAの山頂を近くの位置から検索できるPWAを作りたい。オフラインで動くようにしたい」
技術選定: SQLite Wasmを使った高速検索、R*Tree空間インデックスの提案もClaude Codeから
実装: ページごとに「ダッシュボードページを作って」「GPS検索機能を追加して」と指示
デザイン: /frontend-designスキルでUIを洗練
テスト: Playwright E2Eテストの作成と実行もClaude Codeが担当
リリース: コミット、タグ付け、リリースノート作成まで自動化

GitHubのコミット履歴を見ると、Claude Codeのセッションリンクが含まれているコミットがあります。開発プロセスが完全にトレーサブルです。

{/* textlint-enable ja-technical-writing/ja-no-weak-phrase */}

リリース履歴

OSSとしてGitHubで公開しているので、開発の全履歴が見られます。

バージョン	主な機能追加
v3.1.0	ホームページをダッシュボードに変身。統計カード、ヒーローバナー追加
v3.2.0	国別フィルタ、色分けインジケーター
v3.3.0	全ドキュメント英語翻訳、バイリンガルUI対応
v3.4.0	山頂ページに7日間天気予報を追加
v3.5.0	直近のアクティベーション履歴、アクティベーターページ
v3.6.0	ブックマーク機能、GPSライブポジショニング、ダウンロード進捗バー

インフラ費用：完全無料

{/* textlint-disable ja-technical-writing/ja-no-weak-phrase */}

このアプリの運用にかかるインフラ費用は 完全にゼロ です。

{/* textlint-enable ja-technical-writing/ja-no-weak-phrase */}

サービス	用途	費用
GitHub Pages	ホスティング	無料
GitHub Actions	ビルド・デプロイ・データ更新	無料
SOTA公式CSV	山頂データソース	無料
Open-Meteo	天気予報API	無料
OpenStreetMap	地図タイル	無料
国土地理院	標高データ	無料

サーバーレス。データベースサーバーなし。APIサーバーなし。全部ブラウザ内で完結します。SQLite Wasmのおかげで、サーバーサイドのデータベースが不要になりました。

{/* textlint-disable ja-technical-writing/ja-no-weak-phrase */}

毎週日曜日にGitHub Actionsが自動でSOTA公式CSVを取得してデータベースを再構築し、GitHub Pagesにデプロイします。完全自動運用です。

{/* textlint-enable ja-technical-writing/ja-no-weak-phrase */}

graph TD
    A[毎週日曜 00:00 UTC] --> B[GitHub Actions起動]
    B --> C[SOTA公式CSVダウンロード<br/>24MB / 179,527座]
    C --> D[SQLiteデータベース構築<br/>R*Tree空間インデックス付き]
    D --> E[サイトマップ生成<br/>プログラマティックSEO]
    E --> F[GitHub Pagesへデプロイ]
    F --> G[ユーザーのService Worker<br/>が次回アクセス時に更新]

まとめ

{/* textlint-disable ja-technical-writing/ja-no-weak-phrase */}

SOTA Peak Finderは「位置ゲー好き×アマチュア無線家」の自分にとって、最高に楽しいプロジェクトでした。

SQLite Wasm + R*Tree は、ブラウザ内で大量の地理データを扱うベストな選択肢。サブ10msの検索速度は体感で「一瞬」
PWA でオフライン動作させることで、電波のない山の上でも使える実用的なアプリに
Claude Code を使えば、コードを1行も書かずにプロダクションレベルのアプリが作れる時代
GitHub Pages + GitHub Actions で、インフラ費用完全無料の自動運用が実現

SOTAをやっている人はぜひ使ってみてください。そしてSOTAを知らなかった人は、これを機にアマチュア無線の世界に足を踏み入れてみませんか？　山に登って、無線で交信して、ポイントを貯める。究極の位置ゲー がそこにあります。

{/* textlint-enable ja-technical-writing/ja-no-weak-phrase */}

https://matsubo.github.io/sota-peak-finder/

https://github.com/matsubo/sota-peak-finder

おまけ

{/* textlint-disable ja-technical-writing/ja-no-weak-phrase */}

私のコールサインは JE1WFV です。SOTAでアクティベーションしているときに聞こえたら、ぜひ呼んでください！

Ingressは今でもたまにやっています。位置ゲーの血は抜けないものですね。SOTAはIngressの「ユニークポータル数を稼ぐ」感覚に近い楽しさがあって、ハマっています。

アプリに関するフィードバックやバグ報告は、GitHubのIssueやDiscordで受け付けています。プルリクエストも大歓迎です！

{/* textlint-enable ja-technical-writing/ja-no-weak-phrase */}

73 & Happy Trails! 🏔️📻

QNAP NAS を卒業して mergerfs + SnapRAID で「壊れても理解できる」ストレージを作った

Wed, 25 Feb 2026 00:00:00 GMT

3秒まとめ

QNAP TS-431P に不満が溜まり、mergerfs + SnapRAID で DIY NAS を構築した
異なる容量の HDD（4TB×1 + 2TB×2）を無駄なくプールしつつ、パリティで冗長性を確保
3-2-1 バックアップの考え方に基づいて、クラウドへの定期バックアップも組み合わせた

どんな人向けの記事？

NAS アプライアンス（QNAP、Synology）に不満を感じている人
RAID の仕組みに不安があり、もっとシンプルなストレージ構成を探している人
異なる容量の HDD を無駄なく活用したい人
自宅サーバーで写真やメディアファイルを長期保管したい人

はじめに

@matsubokkuri です。

自宅のストレージ環境を QNAP NAS から mergerfs + SnapRAID に移行しました。この記事では、移行の背景から実際の設定ファイルまでをまとめます。

「NAS アプライアンス、なんか微妙だな…」と感じている方の参考になれば嬉しいです。

色々な AI に聞いても、mergerfs + SnapRAID の組み合わせをおすすめされたので、この構成にしました。

背景：これまでのストレージ遍歴

graph LR
    A["🖥️ 第1世代<br/>Dell PowerEdge T320<br/>ハードウェア RAID"] -->|RAIDカード障害で<br/>データロスト危機| B["📦 第2世代<br/>QNAP TS-431P<br/>ソフトウェア RAID5"]
    B -->|ベンダーロックイン<br/>HDD スタンバイ問題<br/>アプリ品質| C["🛠️ 第3世代<br/>mergerfs + SnapRAID<br/>DIY NAS"]

第1世代：Dell PowerEdge T320 + ハードウェア RAID

最初の自宅ストレージは Dell PowerEdge T320 に 2TB HDD を 6 本載せて、ハードウェア RAID で運用していました。サーバーらしいサーバーで、それなりに満足していたのですが、ある日 RAID カードが壊れかけて 危うくデータをロストしかける事件が発生しました。

ハードウェア RAID の怖いところは、コントローラが死ぬとデータにアクセスできなくなる ということです。同じ型番の RAID カードを調達して差し替えればいける——理論上は。でも実際に障害が起きたときにそれを冷静にやれるかというと、かなり厳しい。

この経験から「ハードウェア RAID は信用できない」という教訓を得ました。

第2世代：QNAP TS-431P（RAID5）

PowerEdge の反省を踏まえて、次は手軽さを重視して QNAP TS-431P を導入しました。4 ベイの ARM ベース NAS で、2TB HDD × 4 を RAID5 で構成。利用可能容量は約 6TB です。

「アプライアンスなら管理が楽だろう」と思って導入したのですが、使い続けるうちに不満が溜まっていきました。

iOS からの写真バックアップがつらい。 QNAP 公式の Qfile アプリで iPhone の写真を自動バックアップしていたのですが、バックアップが途中で止まる、重複ファイルが量産される、HEIF の扱いが怪しい——控えめに言ってひどい。一眼レフの写真も含めて 1 万枚以上あるので、ここのバックアップ体験が悪いのは致命的です。

HDD がスタンバイにならない。 何もしていないのに HDD のアクセスランプが頻繁に点滅 しています。QTS のバックグラウンドプロセスが何かしら動いているようで、HDD がスタンバイに移行しません。日本の電気代は ¥25〜35/kWh と安くないので、使っていない時間帯にはちゃんと止まってほしい。

ベンダーロックイン。 QNAP の RAID 構成は独自フォーマットに依存しています。本体が壊れたら HDD を取り出して別のマシンでマウントすることが容易ではありません。PowerEdge の RAID カード障害と本質的に同じリスクを抱えています。さらに QNAP は過去に Deadbolt ランサムウェア の標的になった実績もあり、セキュリティ面でも不安がありました。

RAID の根本的な問題

振り返ると、PowerEdge のハードウェア RAID も QNAP のソフトウェア RAID も、共通の問題を抱えていました。

管理が複雑で、壊れたときに詰む。 ハードウェア RAID はコントローラ依存。ZFS のようなソフトウェア RAID はプール管理が複雑で、異なるサイズのドライブを混在させにくい。QNAP の QTS RAID は GUI こそ綺麗だけど、中身はブラックボックスで、障害時に何が起きているのか分からない。

そして最大の問題：RAID アレイが崩壊したら、全データが道連れになる。 RAID5 で 2 台同時に壊れたらおしまい。QNAP の場合、ストレージプール内に複数の RAID グループがあって 1 つが壊れると、プール全体のデータが失われる という仕様もあります。

もっとシンプルで、壊れても理解できて、壊れても被害が限定的なストレージが欲しい。

目的：こんなストレージが欲しかった

異なる容量の HDD を無駄なくプール できる（手持ちの 4TB×1、2TB×2 を活かしたい）
1台の HDD が故障しても復旧 できる冗長性
ドライブ故障時に生き残ったデータは即座にアクセス可能 であること
HDD が使われていない時はスタンバイ に入る省電力設計
壊れたときに何が起きているか理解できる シンプルな仕組み
Docker で自由にアプリを動かせる 汎用 Linux 環境

アプローチ：mergerfs + SnapRAID

mergerfs：異なるサイズの HDD を 1 つに束ねる

mergerfs は FUSE ベースのユニオンファイルシステム です。複数のディスクのマウントポイントを、1 つの仮想的なディレクトリとして統合します。

最大のポイントは ファイル単位 で動作すること。RAID のようにブロックレベルでストライピングするのではなく、各ファイルは物理的にどれか 1 台の HDD にそのまま保存されます。

/mnt/data1 (4TB)  ─┐
/mnt/data2 (2TB)  ─┼─→ /mnt/storage (8TB)
/mnt/data3 (2TB)  ─┘

これの何が嬉しいかというと：

異なる容量の HDD を混在可能。 4TB + 2TB + 2TB = 8TB がそのまま使える。RAID5 だと最小ドライブに合わせて 2TB × 3 = 6TB になってしまう
ドライブを 1 台追加するだけで容量拡張。 RAID の再構築は不要
各 HDD は普通の ext4 なので単体でマウントして読める。 mergerfs が消えてもデータは無事
1 台が故障しても、他の HDD 上のファイルは無傷。 被害は壊れたドライブに載っていたファイルだけ

RAID5 だとアレイが崩壊したら全データ喪失のリスクがありますが、mergerfs なら 被害が限定的 です。PowerEdge で RAID カードが壊れかけた経験がある身としては、これがめちゃくちゃ大きい。

SnapRAID：あとからパリティを計算する

SnapRAID は スナップショットベースのパリティシステム です。リアルタイム RAID と違い、snapraid sync コマンドを実行したタイミングでパリティを計算します。

重要なルール：パリティドライブは最大のデータドライブ以上の容量が必要 です。今回は最大データドライブが 4TB、パリティドライブが 6TB なので余裕があります。

データ:    data1(4TB) + data2(2TB) + data3(2TB) = 8TB 利用可能
パリティ:  parity(6TB) → シングルパリティ保護

SnapRAID は 「書き込んだらほとんど変更しない」データ に最適化されています。一眼レフの RAW 写真やメディアファイルの保管にはぴったり。逆にデータベースのように頻繁に書き換わるデータには向きません（sync 間隔の間に書き込まれたデータはパリティで保護されない）。

SnapRAID のもう一つの強みは ビットロット検出 です。128bit ハッシュで全ファイルのチェックサムを管理しているので、定期的に scrub を実行することでサイレントデータ破損を検出できます。長期間の写真アーカイブには地味に重要な機能です。

サイレントデータ破損（ビットロット）とは？ HDD や SSD の記録媒体は、経年劣化や宇宙線の影響で保存されたビットが勝手に反転することがあります。これが サイレントデータ破損（bit rot） です。「サイレント」と呼ばれる理由は、OS やファイルシステムがエラーを報告しないまま、ファイルの中身が静かに壊れていくからです。たとえば 3 年前に撮った写真を開いたら画像の一部が変色していた——というケースがこれにあたります。通常のファイルシステム（ext4 など）はデータの整合性を自動チェックしない（メタデータのチェックサムはあるがデータ本体にはない）ため、ビットロットは検出されずに放置されがちです。SnapRAID は全ファイルのハッシュを記録しているので、scrub コマンドで定期的にチェックすれば破損を早期発見し、パリティから修復できます。 </div>

従来の構成との比較

特徴	mergerfs + SnapRAID	RAID5/6	QNAP QTS
異なるサイズの HDD	✅ 完全対応	❌ 最小ドライブに制限	❌ 最小ドライブに制限
パリティ計算	スナップショット（定期実行）	リアルタイム	リアルタイム
書き込み性能	ディスクネイティブ速度	パリティオーバーヘッド	パリティオーバーヘッド
アレイ崩壊時	生存ディスクのデータは保持	全データ喪失	全データ喪失
ドライブ追加	いつでも追加可能	アレイ再構築が必要	RAID グループ単位
個別ドライブの可読性	✅ 標準 FS（ext4）	❌	❌
ビットロット検出	✅ 128bit ハッシュ	❌	限定的
HDD スタンバイ	✅ 未使用ドライブは停止	❌ 全 HDD 常時回転	❌ 全 HDD 常時回転
管理	CLI	コントローラ依存	Web GUI

ハードウェア選定と予算

方針：ミニ PC + USB DAS

最初は Raspberry Pi で組みたかったんですが、写真管理に使っている Immich の機械学習機能（顔認識・セマンティック検索）は ARM では荷が重い。仕方なく、もともと自宅サーバーとして使っていた Beelink SER5 MAX を NAS 兼用にすることにしました。

Beelink SER5 MAX

CPU:    AMD Ryzen 7 5800H（8C/16T、最大 4.4GHz）
RAM:    16GB DDR4
SSD:    1TB NVMe（OS + Docker用）
USB:    3 × USB 3.2 Gen2（10Gbps）
LAN:    1GbE
TDP:    45W（実測アイドル ~15W）
サイズ:  126 × 113 × 42mm

Passmark スコアは約 21,000。QNAP TS-431P の ARM CPU とは比較にならない処理能力です。Docker で複数のサービス（写真管理、監視、ファイル共有など）を同時に動かしても余裕があります。

日本のマンションだとサイズも重要で、126 × 113mm の手のひらサイズは PowerEdge のタワー型と比べると天と地の差です。

USB DAS の選び方

mergerfs では各ドライブが OS から 独立したブロックデバイス として認識される必要があります。RAID 機能のない JBOD モデルなら何も設定せず、HDD を入れるだけで /dev/sda, /dev/sdb… として認識されます。

今回は ORICO 4 ベイ HDD ケース（USB 3.0、RAID なし） を選びました。

選定基準は 「安い」「壊れなさそう」 の 2 点だけ。正直なところ、USB DAS（特に RAID なしの JBOD モデル）は選択肢が少なく、Amazon のレビューを見ても評価の高い製品がなかなか見つかりません。QNAP や Synology のような NAS アプライアンスと違って、「ただの箱」にあたる DAS はメーカーもユーザーも少なく、品質の当たり外れも大きい印象です。

その中で ORICO を選んだ理由：

RAID 機能なしの JBOD モード がある（RAID コントローラ付きのモデルは mergerfs と相性が悪い）
4 ベイ でデータ 3 台 + パリティ 1 台を収容可能
¥10,000 前後 と比較的安価
ファン付き で HDD の冷却ができる
ORICO は USB ストレージ周辺機器メーカーとしてはそこそこ実績がある

「消去法で選んだ」感は否めませんが、数ヶ月使ってみて今のところ問題は出ていません。

USB 3.0（5Gbps）で理論上 ~400MB/s。HDD 自体が 150〜200MB/s なのでボトルネックにはなりません。

USB DAS は SATA 直結と比べると接続の信頼性は劣ります。ケーブルの抜けや電源トラブルには注意が必要です。dmesg を定期的にチェックする運用が求められます。 </div>

コスト

パーツ	モデル	価格
ミニ PC	Beelink SER5 MAX（Ryzen 7 5800H / 16GB / 1TB）	¥50,000（自宅サーバーを流用）
DAS	ORICO 4ベイ HDD ケース（USB 3.0、RAID なし）	¥10,000
HDD（データ）	4TB × 1 + 2TB × 2（手持ち）	¥0（既存在庫）
HDD（パリティ）	6TB × 1（新規購入）	¥25,000
合計		¥85,000

ミニ PC は自宅サーバーの流用なので、NAS 構築のための 実質追加コストは約 35,000 円（DAS + パリティ用 HDD）です。

参考までに、QNAP TS-464（現行 4ベイモデル）を新品で買うと本体だけで ¥70,000〜90,000。HDD 4 本を足すと ¥150,000 超え になります。

構成	概算コスト
QNAP TS-464 + NAS用 HDD × 4	~¥150,000〜170,000
DIY（SER5 + ORICO + HDD）	~¥85,000（うち流用 ¥50,000）
DIY 追加分のみ	~¥35,000

データ量と HDD 構成

保管しているデータ

主に一眼レフ（RAW）と iPhone の写真・動画です。現時点で約 2TB。

24MP の一眼で RAW 1 枚あたり 25〜40MB、動画ファイルも含めるとそれなりの容量になります。8TB の利用可能容量があれば当面は余裕です。

ドライブ構成

/dev/sdb → /mnt/data1    (4TB)  [データ]
/dev/sdc → /mnt/data2    (2TB)  [データ]
/dev/sdd → /mnt/data3    (2TB)  [データ]
/dev/sda → /mnt/parity   (6TB)  [パリティ] ← 新規購入

mergerfs で 4TB + 2TB + 2TB = 8TB の利用可能容量。SnapRAID のシングルパリティでどれか 1 台が壊れても復旧可能。

RAID5 だと 2TB × 3（最小ドライブに合わせる）= 6TB にしかならないので、mergerfs のほうが 2TB 多く 使えます。

3-2-1 バックアップ戦略

ここで超重要なことを書きます。

SnapRAID のパリティはバックアップではありません。 </div>

SnapRAID はドライブ故障からの 冗長性 を提供しますが、以下のケースからは守ってくれません：

誤削除 → sync が走ると削除がパリティに反映され、復旧不可能
ランサムウェア → 暗号化されたファイルが sync で記録される
火災・盗難 → 物理的にすべてのドライブが失われる
sync 間の書き込み → まだパリティに反映されていないデータ

冗長性（= ドライブが壊れてもシステムが動き続ける）と、バックアップ（= どんな障害からもデータを復旧できる）は別物です。両方必要です。

3-2-1 ルールとは

データ保護の基本原則として広く知られているルールです。

	意味	今回の実装
3	データのコピーを 3 つ持つ	原本 + ローカルバックアップ + クラウド
2	2 種類以上の異なるメディアに保存	HDD アレイ + クラウドストレージ
1	1 つはオフサイト（物理的に離れた場所）	AWS S3 Glacier

今回のバックアップ構成

graph TD
    subgraph "自宅"
        A["💾 原本<br/>mergerfs + SnapRAID アレイ"] -->|rsync| B["🔌 ローカルバックアップ<br/>外付け USB HDD<br/>（普段は電源 OFF）"]
    end
    A -->|"rclone copy<br/>Glacier Deep Archive"| C["☁️ オフサイト<br/>AWS S3 Glacier Deep Archive"]

なぜ `rclone copy` なのか

クラウドバックアップのツールとして rclone を採用しています。rclone は クラウドストレージ向けの rsync とも呼ばれるオープンソースの CLI ツールで、AWS S3、Google Cloud Storage、Backblaze B2 など 70 以上のクラウドストレージに対応しています。

rclone には copy と sync の 2 つのモードがあります。

コマンド	動作	リモートの削除
`rclone copy`	ローカルにあるファイルをリモートにコピー	しない
`rclone sync`	ローカルとリモートを完全に同期（ミラーリング）	する

今回は copy を選択 しました。理由は明確で：

誤削除からの保護。 sync だとローカルで誤ってファイルを消した瞬間、次の同期でクラウドからも消えます。バックアップの意味がなくなる。copy ならローカルで削除してもクラウド側は残るので、「あの写真消しちゃった！」というときにクラウドから復旧できます
ランサムウェア対策。 ランサムウェアにやられてローカルが暗号化されても、copy なら暗号化前のファイルがクラウドに残っています。sync だと暗号化されたファイルでクラウドが上書きされるリスクがあります

なぜ Glacier Deep Archive なのか

ストレージクラスは Glacier Deep Archive を選択。理由：

写真・動画は write-once データ。 一度保存したらほぼ変更しない。頻繁にアクセスする必要もない。この特性は Glacier Deep Archive の「低頻度アクセス・長期保存」にぴったり合致します
圧倒的に安い。 S3 Standard の約 1/23 のコスト（~$1/TB/月 vs ~$23/TB/月）
rclone から直接 PUT できる。 --s3-storage-class DEEP_ARCHIVE を指定するだけ。ライフサイクルポリシーの設定は不要

取り出しに 12〜48 時間かかりますが、これは「火災・盗難で物理ドライブが全滅したときの最終手段」なので問題ありません。

なぜサムネイルとドットファイルを除外するのか

バックアップ対象を 写真・動画の本体データだけ に絞っています。

thumbs/ — Immich などの写真管理ツールが生成するサムネイルキャッシュ。元データから再生成できるのでバックアップ不要
.*（ドットファイル） — .DS_Store、.Thumbs.db などの OS やアプリが生成するメタデータ。これもバックアップ不要

これにより、バックアップ対象が約 2TB → 約 1.5TB に減少。年間のストレージコストが ¥900 程度削減されます。

初回バックアップ前にディレクトリ構造を整理してください。 rclone はファイルパスでリモートのファイルを管理しています。バックアップ開始後にディレクトリを mv で移動すると、rclone は「旧パスのファイルが消えて、新パスに別のファイルが現れた」と認識します。結果として、同じファイルが新パスで再アップロードされ、旧パスのファイルは年次クリーンアップまでクラウドに残り続けます。つまり 転送量と保管料が二重にかかります。 ディレクトリ構成の変更は初回バックアップの前に済ませておきましょう。 </div>

実際のコマンド

❯ rclone copy /mnt/storage s3-remote:nas-backup/ \
    --s3-storage-class DEEP_ARCHIVE \
    --exclude "thumbs/**" \
    --exclude ".*" \
    --transfers 4 --checkers 8

rclone はファイルサイズとタイムスタンプで差分を検知するため、変更のないファイルは再転送されません。毎月実行しても、転送されるのは新しく追加された写真・動画だけです。

年 1 回のクリーンアップ

rclone copy はリモートのファイルを削除しないので、ローカルで整理・削除したファイルがクラウドに溜まり続けます。これを放置するとストレージコストが増え続けるので、年 1 回のクリーンアップを行います。

ただし Glacier Deep Archive は 最低保存期間が 180 日 で、180 日未満で削除すると残り期間分の料金が発生します。そこで、ローカルに存在せず、かつアップロードから 180 日以上経過したファイル だけを削除対象にします。

# 1. S3 にあるがローカルに存在しないファイルを検出
❯ rclone lsf s3-remote:nas-backup/ -R > /tmp/remote.txt
❯ rclone lsf /mnt/storage/ -R --exclude "thumbs/**" --exclude ".*" > /tmp/local.txt
❯ comm -23 <(sort /tmp/remote.txt) <(sort /tmp/local.txt) > /tmp/orphaned.txt

# 2. 180 日以上経過したファイルだけ削除
❯ rclone delete s3-remote:nas-backup/ \
    --files-from /tmp/orphaned.txt \
    --min-age 180d

この運用なら：

普段の rclone copy — 追加のみ。誤削除・ランサムウェアから保護
年 1 回のクリーンアップ — 本当に不要になったファイルだけ削除。180 日ルールに抵触しない
結果 — クラウド上には「ローカルに存在するファイル + 削除後 180 日未満のファイル」だけが残り、コストが膨らみ続けることはない

クラウドバックアップのコスト見積もり

サムネイルやドットファイルを除外すると、実際のバックアップ対象は写真・動画データの約 1.5TB 程度になります。

サービス	ストレージ単価	月額（1.5TB）	年額	取り出し
AWS S3 Glacier Deep Archive	~$1/TB/月	~$1.5（≒ ¥225）	≒ ¥2,700	取り出しに 12〜48 時間、別途料金
Backblaze B2	$6/TB/月	~$9（≒ ¥1,350）	≒ ¥16,200	即時アクセス、3× ストレージまで egress 無料
AWS S3 Standard	$23/TB/月	~$34.5（≒ ¥5,175）	≒ ¥62,100	即時アクセス

rclone copy で月 1 回の差分転送なら、PUT リクエストは毎月の新規ファイル分だけ（月数百〜数千件程度）。API コストはほぼ無視できます。

アーカイブ用途で「普段は取り出さない、災害時の最終手段」と割り切るなら Glacier Deep Archive が圧倒的に安い です。年額 ¥3,000 以下で 3-2-1 ルールのオフサイトコピーを実現できます。

ランニングコストの全体像

項目	月額	年額
電気代（ミニ PC + DAS、~30W 平均）	≒ ¥650	≒ ¥7,800
クラウドバックアップ（Glacier Deep Archive）	≒ ¥225	≒ ¥2,700
合計	≒ ¥875	≒ ¥10,500

比較として、QNAP TS-431P は公称消費電力 36W（HDD 4 台搭載時）ですが、HDD がスタンバイに入らない問題があったので実質もう少し高いはず。加えて QNAP のクラウドバックアップ機能を使うにしても別途クラウドストレージ費用がかかります。

実際の設定

ここからは実際に構築した設定ファイルを掲載します。OS は Ubuntu 24.04 LTS です。

ディスクのマウント

各 HDD を UUID で個別にマウントします。USB DAS は接続順でデバイス名が変わることがあるため、UUID 指定が必須です。

❯ lsblk -o NAME,SIZE,FSTYPE,UUID,MOUNTPOINT
NAME   SIZE FSTYPE UUID                                 MOUNTPOINT
sda    5.4T ext4   xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /mnt/parity
sdb    3.6T ext4   yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy /mnt/data1
sdc    1.8T ext4   zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz /mnt/data2
sdd    1.8T ext4   wwwwwwww-wwww-wwww-wwww-wwwwwwwwwwww /mnt/data3

/etc/fstab:

# --- データドライブ ---
UUID=yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy /mnt/data1    ext4 defaults,nofail 0 2
UUID=zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz /mnt/data2    ext4 defaults,nofail 0 2
UUID=wwwwwwww-wwww-wwww-wwww-wwwwwwwwwwww /mnt/data3    ext4 defaults,nofail 0 2

# --- パリティドライブ ---
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /mnt/parity  ext4 defaults,nofail 0 2

# --- mergerfs プール ---
/mnt/data1:/mnt/data2:/mnt/data3 /mnt/storage fuse.mergerfs defaults,allow_other,use_ino,cache.files=off,moveonenospc=true,dropcacheonclose=true,minfreespace=20G,category.create=mfs,fsname=mergerfs 0 0

nofail は USB DAS の起動が OS のブートより遅れても起動が止まらないようにするためのオプションです。USB 接続では必須。

mergerfs のポリシー

category.create=mfs（most free space）は mergerfs の デフォルトポリシー で、空き容量が最も大きいドライブに新規ファイルを書き込みます。特にこだわりがないので、まずはデフォルトのままで運用してみることにしました。

ポリシー	動作	ユースケース
`mfs`	空き容量が最大のドライブに書き込み	今回採用。ドライブ間で均等に分散
`epmfs`	既存パスがあるドライブ優先、なければ mfs	ディレクトリ構造を維持したい場合
`lfs`	空きが最小のドライブに書き込み	1 台ずつ順番に埋めたい場合

moveonenospc=true は書き込み先が満杯の場合に自動で別ドライブにリトライする設定。minfreespace=20G で各ドライブを使い切らないようにガードします。

SnapRAID の設定

❯ sudo apt install snapraid

/etc/snapraid.conf:

# パリティファイルの場所
parity /mnt/parity/snapraid.parity

# コンテンツファイル（複数ドライブに分散配置を推奨）
content /var/snapraid/snapraid.content
content /mnt/data1/.snapraid.content
content /mnt/data2/.snapraid.content
content /mnt/data3/.snapraid.content

# データドライブ
data d1 /mnt/data1/
data d2 /mnt/data2/
data d3 /mnt/data3/

# 除外パターン
exclude *.unrecoverable
exclude /tmp/
exclude /lost+found/
exclude .DS_Store
exclude .Thumbs.db
exclude .snapraid.content

# 250GB ごとに中間セーブ（初回 sync 中に中断しても途中から再開可能）
autosave 250

コンテンツファイルは SnapRAID のメタデータで、最低 2 箇所 に配置する必要があります。パリティドライブ以外のデータドライブに分散させるのがベストプラクティスです。

初回の sync:

❯ sudo snapraid sync
Self test...
Loading state from /var/snapraid/snapraid.content...
Scanning disk d1...
Scanning disk d2...
Scanning disk d3...
...
Syncing...

初回は全データのハッシュ計算が走るのでそれなりに時間がかかります。autosave 250 のおかげで 250GB ごとに中間保存されるので、途中で中断しても最初からやり直しにはなりません。

SnapRAID の自動化

毎日深夜に sync + scrub を自動実行します。安全のため、大量削除を検知したら sync を中止する しきい値を設けます。

/usr/local/bin/snapraid-sync.sh:

#!/bin/bash
set -euo pipefail

THRESHOLD=250
LOG="/var/log/snapraid-sync.log"

echo "=== SnapRAID sync started at $(date) ===" >> "$LOG"

# diff で変更量を確認
DIFF_OUTPUT=$(snapraid diff 2>&1)
REMOVED=$(echo "$DIFF_OUTPUT" | grep -E 'removed' | awk '{print $1}' || echo "0")

if [ "$REMOVED" -gt "$THRESHOLD" ]; then
    echo "WARNING: $REMOVED files removed (threshold: $THRESHOLD). Sync aborted." >> "$LOG"
    # ここに通知処理を追加（メール、Discord webhook など）
    exit 1
fi

snapraid sync >> "$LOG" 2>&1

# 30日以上前にチェックしたデータの 8% をスクラブ
snapraid scrub -p 8 -o 30 >> "$LOG" 2>&1

echo "=== SnapRAID sync completed at $(date) ===" >> "$LOG"

❯ sudo chmod +x /usr/local/bin/snapraid-sync.sh
❯ sudo crontab -e
# 毎日 AM 3:00 に実行
0 3 * * * /usr/local/bin/snapraid-sync.sh

削除しきい値（THRESHOLD=250）がポイントです。ランサムウェアに感染してファイルが大量に暗号化・削除されたケースでは、snapraid diff が異常な削除数を検出して sync を止めてくれます。パリティが上書きされる前に対処できるわけです。

scrub -p 8 -o 30 は「30 日以上前にチェックしたデータのうち 8% をスクラブ」。毎日実行すれば約 2 週間でアレイ全体を 1 巡し、ビットロットを早期発見できます。

Samba によるネットワーク共有

LAN 内の他のマシンから mergerfs プールにアクセスするための設定です。

/etc/samba/smb.conf（抜粋）:

[pool]
   comment = mergerfs pool
   path = /mnt/storage
   browseable = yes
   read only = no
   valid users = @smbusers
   create mask = 0664
   directory mask = 0775

❯ sudo useradd -M -s /usr/sbin/nologin smbuser
❯ sudo smbpasswd -a smbuser
❯ sudo usermod -aG smbusers smbuser
❯ sudo systemctl restart smbd

rclone によるクラウドバックアップの設定

rclone のインストールとリモート設定

❯ sudo apt install rclone

S3 リモートを設定します。rclone config は対話式で進みます。

❯ rclone config

# 以下の順で入力:
# n) New remote
# name> s3-remote
# Storage> s3
# provider> AWS
# env_auth> false
# access_key_id> （IAM ユーザーの Access Key ID）
# secret_access_key> （IAM ユーザーの Secret Access Key）
# region> ap-northeast-1
# endpoint> （空欄のまま Enter）
# location_constraint> ap-northeast-1
# acl> private
# storage_class> DEEP_ARCHIVE
# （残りはデフォルトのまま Enter）

IAM ユーザーには以下のポリシーを付与しておきます。

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:PutObject", "s3:GetObject", "s3:ListBucket", "s3:DeleteObject"],
    "Resource": [
      "arn:aws:s3:::nas-backup",
      "arn:aws:s3:::nas-backup/*"
    ]
  }]
}

設定が完了したら動作確認します。

# リモートへの接続テスト
❯ rclone lsd s3-remote:

# バケットがなければ作成
❯ rclone mkdir s3-remote:nas-backup

# dry-run でバックアップ対象を確認（実際には転送しない）
❯ rclone copy /mnt/storage s3-remote:nas-backup/ \
    --s3-storage-class DEEP_ARCHIVE \
    --exclude "thumbs/**" \
    --exclude ".*" \
    --dry-run -v

バックアップスクリプト

月次バックアップスクリプト（/usr/local/bin/backup-cloud.sh）:

#!/bin/bash
set -euo pipefail

LOG="/var/log/backup-cloud.log"
REMOTE="s3-remote:nas-backup"
LOCK="/var/run/backup-cloud.lock"

# 多重起動の防止
if [ -f "$LOCK" ]; then
    echo "ERROR: Backup already running (lockfile exists)" >> "$LOG"
    exit 1
fi
trap 'rm -f "$LOCK"' EXIT
touch "$LOCK"

echo "=== Cloud backup started at $(date) ===" >> "$LOG"

# rclone copy: 新規・変更ファイルだけアップロード、リモートのファイルは削除しない
rclone copy /mnt/storage "$REMOTE" \
    --s3-storage-class DEEP_ARCHIVE \
    --exclude "thumbs/**" \
    --exclude ".*" \
    --transfers 4 \
    --checkers 8 \
    --bwlimit 50M \
    --log-file "$LOG" \
    --log-level INFO \
    --stats 1h \
    --stats-log-level INFO \
    && echo "=== Cloud backup completed successfully at $(date) ===" >> "$LOG" \
    || { echo "=== Cloud backup FAILED at $(date) ===" >> "$LOG"; exit 1; }

スクリプトのポイント：

--bwlimit 50M — 帯域を 50MB/s に制限。バックアップ中に他のネットワーク通信が遅くならないようにします。回線速度に応じて調整してください
ロックファイル — backup-cloud.lock で多重起動を防止。初回の 1.5TB アップロードは数時間以上かかるため、cron の次の実行と重複しないようにします
--stats 1h — 1 時間ごとに転送状況をログに出力。長時間実行の進捗がわかります

❯ sudo chmod +x /usr/local/bin/backup-cloud.sh

クリーンアップスクリプト

年次クリーンアップスクリプト（/usr/local/bin/backup-cleanup.sh）:

#!/bin/bash
set -euo pipefail

LOG="/var/log/backup-cloud.log"
REMOTE="s3-remote:nas-backup"

echo "=== Cleanup started at $(date) ===" >> "$LOG"

# S3 上のファイル一覧を取得
rclone lsf "$REMOTE" -R > /tmp/remote-files.txt

# ローカルのファイル一覧を取得（バックアップと同じ exclude ルールを適用）
rclone lsf /mnt/storage/ -R \
    --exclude "thumbs/**" \
    --exclude ".*" > /tmp/local-files.txt

# S3 にあるがローカルに存在しないファイルを抽出
comm -23 <(sort /tmp/remote-files.txt) <(sort /tmp/local-files.txt) > /tmp/orphaned-files.txt

ORPHAN_COUNT=$(wc -l < /tmp/orphaned-files.txt)
echo "Found $ORPHAN_COUNT orphaned files" >> "$LOG"

if [ "$ORPHAN_COUNT" -gt 0 ]; then
    # 180 日以上経過したファイルだけ削除（Glacier の最低保存期間を回避）
    rclone delete "$REMOTE" \
        --files-from /tmp/orphaned-files.txt \
        --min-age 180d \
        --log-file "$LOG" \
        --log-level INFO
fi

# 一時ファイルの削除
rm -f /tmp/remote-files.txt /tmp/local-files.txt /tmp/orphaned-files.txt

echo "=== Cleanup completed at $(date) ===" >> "$LOG"

❯ sudo chmod +x /usr/local/bin/backup-cleanup.sh

cron 設定

❯ sudo crontab -e

# --- SnapRAID ---
# 毎日 AM 3:00 に sync + scrub
0 3 * * * /usr/local/bin/snapraid-sync.sh

# --- クラウドバックアップ ---
# 毎月 1 日 AM 4:00 に rclone copy（SnapRAID sync の後に実行）
0 4 1 * * /usr/local/bin/backup-cloud.sh

# 毎年 1 月 15 日 AM 4:00 にクリーンアップ（1 日のバックアップ完了後に実行）
0 4 15 1 * /usr/local/bin/backup-cleanup.sh

SnapRAID sync（AM 3:00）→ rclone copy（AM 4:00）の順番にしています。sync が完了してパリティが最新になった状態でクラウドバックアップを実行するためです。

ドライブの監視

SMART データの監視を設定しています。Reallocated Sector Count や Current Pending Sector が増加傾向にあるドライブは早めに交換する判断材料になります。

❯ sudo apt install smartmontools

# 各ドライブの SMART 情報を確認
❯ sudo smartctl -a /dev/sda
❯ sudo smartctl -a /dev/sdb
❯ sudo smartctl -a /dev/sdc
❯ sudo smartctl -a /dev/sdd

Zabbix などの監視ツールでカスタム UserParameter を設定し、温度やセクタエラーの推移を記録しておくと、障害の予兆を捉えやすくなります。

運用してみての所感

良かったこと

HDD がちゃんとスタンバイに入る。 QNAP の謎のアクセスランプ点滅から解放されました。使っていない時間帯は静かで、電気代も下がった実感があります。

異なる容量のドライブを無駄なく使い切れる。 RAID5 だと 2TB に揃えなきゃいけなかったところ、手持ちの 4TB + 2TB + 2TB がそのまま 8TB として活きています。

壊れても理解できる。 mergerfs + SnapRAID の仕組みはシンプルなので、何か問題が起きても dmesg と snapraid status を見れば状況が分かります。QNAP の QTS や PowerEdge の RAID コントローラではこうはいかなかった。

1 台壊れても慌てない安心感。 仮に disk2 が死んでも、disk1 と disk3 のファイルはそのまま ext4 として読めます。PowerEdge で RAID カード障害を経験した身としては、この安心感は本当に大きい。

注意点・トレードオフ

mergerfs の CPU 使用率がそこそこある。 これは運用してみて気づいたことですが、mergerfs は FUSE（ユーザー空間ファイルシステム）で動作するため、ファイルアクセスのたびにカーネル空間とユーザー空間を往復するオーバーヘッドがあります。btop で見ると、特に大量のファイルを読み書きしている時に mergerfs プロセスが CPU をそれなりに食っているのが分かります。Ryzen 7 5800H なら実用上問題にはなりませんが、Raspberry Pi のような低スペック環境だとボトルネックになる可能性があります。mergerfs の開発者も「CPU を使っているように見えるが、実際にはリクエストのディスパッチがほとんど」と説明しており、実 I/O に比べれば軽微とのこと。とはいえ、カーネルモジュールとして実装された場合と比べるとオーバーヘッドがあるのは事実です。

USB DAS の信頼性。 SATA 直結と比べると USB 接続はどうしても一段劣ります。ケーブルの抜けや DAS の電源トラブルには注意が必要で、dmesg を定期的にチェックする運用が求められます。

SnapRAID はリアルタイム保護ではない。 sync の間隔（今回は 1 日 1 回）の分だけデータ損失リスクがあります。重要な写真を大量に取り込んだ直後は手動で snapraid sync を走らせるのが安心です。

GUI がない。 QNAP の QTS のような Web UI はありません。すべて CLI です。Linux に慣れていない人にはハードルが高いですが、逆に言えばすべてテキストファイルで設定が完結するので、バージョン管理やドキュメント化がしやすいです。

初期セットアップの手間。 QNAP は箱から出して 30 分で使い始められますが、この構成は数時間〜数日かかります。そのぶん自由度と「何が起きているか理解できる」度は桁違いです。

mergerfs FAQ

mergerfs + SnapRAID の運用事例はあまり記事になっていなかったので、運用していく中で自分が気になったことをチェックリストとしてまとめておきます。

Q. ドライブが 1 台壊れたらどうなる？

mergerfs プール自体は動き続けます。 壊れたドライブに載っていたファイルにアクセスするとエラーになりますが、他のドライブのファイルは何事もなく読み書きできます。RAID5 のように「アレイが degraded になって全体のパフォーマンスが落ちる」ということはありません。

復旧手順としては、壊れたドライブを新しいドライブに交換し、SnapRAID の fix コマンドでパリティからデータを復元します。

# 新しいドライブをフォーマットしてマウント
❯ sudo mkfs.ext4 /dev/sdX
❯ sudo mount /dev/sdX /mnt/data2

# SnapRAID でデータを復元
❯ sudo snapraid fix -d d2

Q. 新しいドライブを追加するには？

fstab を 1 行書き換えるだけ です。mergerfs のソースパスに新しいドライブを追加して mount -a するか、再マウントすれば即座に反映されます。RAID のような再構築は一切不要。

# 例: /mnt/data4 を追加
❯ sudo mkfs.ext4 /dev/sdX
❯ sudo mkdir /mnt/data4
❯ sudo mount /dev/sdX /mnt/data4

# fstab の mergerfs 行を編集
/mnt/data1:/mnt/data2:/mnt/data3:/mnt/data4 /mnt/storage fuse.mergerfs ...

# 再マウント
❯ sudo umount /mnt/storage && sudo mount -a

SnapRAID 側も /etc/snapraid.conf に data d4 /mnt/data4/ を追加して snapraid sync を実行すればOK。

ライブで追加したい場合は mergerfs.ctl や xattr 経由で再マウントなしに追加できます。

❯ sudo xattr -w user.mergerfs.srcmounts +/mnt/data4 /mnt/storage/.mergerfs

Q. ドライブを取り外すには？

mergerfs は ドライブ取り外し時にデータを自動移動しません。 手動でデータを退避する必要があります。

ポイントは 先にプールから除外してから rsync する ことです。除外前に rsync すると、コピー先の /mnt/storage/ に取り外し対象ドライブ自身が含まれているため、ファイルが「既に存在する」と判定されてコピーがスキップされてしまいます。

# 1. mergerfs からドライブを除外（プール上でこのドライブのファイルが見えなくなる）
❯ sudo xattr -w user.mergerfs.srcmounts -/mnt/data3 /mnt/storage/.mergerfs

# 2. 除外したドライブのデータをプールにコピー（他のドライブに書き込まれる）
❯ sudo rsync -avxHAXWE --numeric-ids --info=progress2 /mnt/data3/ /mnt/storage/

# 3. コピー漏れがないか dry-run で確認（出力がなければ OK）
❯ sudo rsync -avxHAXWE --numeric-ids --dry-run /mnt/data3/ /mnt/storage/

# 4. ドライブをアンマウント
❯ sudo umount /mnt/data3

# 5. fstab から該当行を削除し、SnapRAID の設定から d3 を削除して再 sync
❯ sudo snapraid sync

プール全体に十分な空き容量がある前提です（取り外すドライブの使用量 < 残りドライブの空き容量）。ドライブの容量アップグレード（2TB → 4TB に交換など）もこの手順で対応できます。

Q. あるファイルがどのドライブに保存されているか確認できる？

できます。mergerfs はファイル単位で保存先が分かれるので、物理的にどこにあるか確認したい場合は個別のマウントポイントを find で探します。

# /mnt/storage/photos/2024/IMG_001.RAF がどのドライブにあるか
❯ find /mnt/data1 /mnt/data2 /mnt/data3 -path "*/photos/2024/IMG_001.RAF"
/mnt/data1/photos/2024/IMG_001.RAF

Q. ext4 と xfs など異なるファイルシステムを混在できる？

できます。 mergerfs はファイルシステムの種類に依存しません。ext4 と xfs を混在させても問題なく動作します。ただし、運用のシンプルさを考えると統一しておくのが無難です。NTFS や FAT のような非 POSIX ファイルシステムはパーミッションの問題が出る可能性があるので非推奨。

Q. mergerfs 自体がクラッシュしたらデータは消える？

消えません。 mergerfs はデータを変換・加工しているわけではなく、既存のファイルシステムの上にマウントポイントを仮想的に統合しているだけです。mergerfs が落ちたら /mnt/storage にアクセスできなくなりますが、各ドライブ（/mnt/data1, /mnt/data2, /mnt/data3）は普通の ext4 なので、そのままマウントしてファイルにアクセスできます。

最悪の場合、mergerfs を一切使わなくても全データにアクセスできるというのが、RAID に対する最大のメリットの 1 つです。

Q. Docker のボリュームとして mergerfs プールを使える？

使えます。 Docker の volumes に /mnt/storage のパスをそのまま指定すれば OK です。

volumes:
  - /mnt/storage/data:/app/data

ただし、データベース（PostgreSQL、MySQL など）のデータディレクトリを mergerfs 上に置くのは 非推奨 です。データベースは小さなファイルを頻繁に読み書きするワークロードで、FUSE のオーバーヘッドがパフォーマンスに影響します。データベースのデータは SSD（OS ドライブ）に置いて、mergerfs プールには写真やメディアなどの大きなファイルを保存する、という使い分けがおすすめです。

Q. パフォーマンスはどのくらい出る？

シーケンシャルな Read/Write であれば、ほぼディスクネイティブの速度 が出ます。USB 3.0 接続の HDD で 150〜200MB/s 程度。mergerfs のオーバーヘッドよりも HDD や USB の帯域がボトルネックになるので、実質的な速度低下は体感しにくいです。

ただし、大量の小さなファイルを扱うメタデータ操作（find、ls -R、du など）は FUSE のオーバーヘッドが効いてきます。ファイルアクセスのたびにカーネル↔ユーザー空間を往復するので、ファイル数が多いディレクトリでは遅延を感じることがあります。写真やメディアファイルのような「数は多いが個々のファイルは大きい」ワークロードなら問題になることは少ないです。

Q. 1 台が壊れたとき、他のディスクに新しい書き込みがあってもパリティから復元できる？

最後に snapraid sync が成功した時点のデータは復元できます。 ただし、いくつか注意点があります。

SnapRAID のパリティはリアルタイムではなく スナップショットベース です。パリティが保護しているのは「最後の sync 時点でのデータ」なので、sync 後に他のディスクへ書き込みがあっても、壊れたディスクの復元には影響しません。パリティ計算のベースラインが変わっていないからです。

graph LR
    A["最後の sync 完了<br/>（パリティ計算済み）"] --> B["他のディスクに<br/>新規ファイル追加"]
    B --> C["disk2 が故障 💥"]
    C --> D["snapraid fix -d d2<br/>✅ 最後の sync 時点の<br/>データは復元可能"]

絶対にやってはいけないこと：故障したディスクがある状態で snapraid sync を実行すること。 sync を実行すると、壊れたディスクの欠損を「正しい状態」としてパリティが再計算されてしまい、復元できなくなります。必ず fix → ディスク交換 → sync の順番 を守ってください。

{/* textlint-disable ja-technical-writing/ja-no-mixed-period */} まとめると：

状況	復元
sync 後、他ディスクへの書き込みなし	✅ 完全復元
sync 後、他ディスクへの新規ファイル追加あり	✅ 壊れたディスクは sync 時点で復元可能。新規ファイルはパリティ未保護
sync 後、他ディスクの既存ファイルを変更	⚠️ 壊れたディスクの復元精度が下がる可能性あり（変更されたファイルとパリティの整合性がずれるため）
故障後に sync を実行してしまった	❌ 復元不可能
{/* textlint-enable ja-technical-writing/ja-no-mixed-period */}

運用のコツとしては、ディスク故障に気づいたら すぐに自動 sync の cron を止めて、snapraid fix を実行する ことです。自動化スクリプトで snapraid diff の結果をチェックしてディスク異常を検知→ sync を中止する仕組みを入れておくと安心です（本記事の自動化スクリプトでは削除しきい値でこれに近い保護をしています）。

まとめ

Dell PowerEdge T320（ハードウェア RAID）→ QNAP TS-431P（ソフトウェア RAID）→ mergerfs + SnapRAID on Ubuntu 24.04 と渡り歩いてきて、ようやく「壊れても理解できる」ストレージ構成にたどり着きました。

3 世代の経験から言えるのは：

ハードウェア RAID はコントローラが SPOF。 壊れたら詰む
NAS アプライアンスは便利だが、ベンダーロックインと品質のばらつきがある。 特に周辺アプリの完成度は過信できない
mergerfs + SnapRAID は「理解できるシンプルさ」が最大の価値。 各ドライブが普通の ext4 で読めるという安心感は他に替えがたい
SnapRAID はバックアップではない。 3-2-1 ルールに基づくオフサイトバックアップは別途必須。Glacier Deep Archive なら年額 ¥3,000 以下で実現可能

CLI 運用と USB DAS の割り切りが必要なので万人向けとは言えませんが、NAS のブラックボックスに不安を感じている人、過去に RAID で痛い目に遭った人には自信を持っておすすめできます。

次回の記事では、この NAS 上に構築した 写真管理環境（Immich）について書く予定です。

DAIKINエアコン3回目の修理 | 基盤交換で無償対応

Fri, 23 Jan 2026 00:00:00 GMT

概要

稼働し始めて数年が経過したDAIKINのエアコンで、暖房がすぐに停止してしまう問題が発生しました。

これで修理依頼は3回目です。

前回の修理

半年ほど前にクーラーが途中で止まってしまう問題があったので、修理の調査に来てもらいました。

ダイキンエアコンAN71VRP-W修理 | 原因不明で5,000円

しかし、原因不明なまま症状が直ってしまい、結局何も対処せず終わりました。

今回の問題

今度は、暖房がすぐに停止する問題が発生。

冬なので暖房が使えないのは困るため、すぐに修理を依頼しました。

修理の流れ

前回と同じようにオンラインで修理依頼をしました。

2日後に修理の人が訪問。

エラーコード確認

今回はエラーコードが出力されていたので、基盤が問題ということが特定できたとのことでした。

前回はエラーコードが出ていなかったので原因特定が難しかったようですが、今回は明確にエラーが記録されていたため、すぐに問題箇所が判明しました。

作業内容

作業内容は基盤交換。

保証期限ははるか昔に切れていましたが、なぜか無料で対応してもらえました。

半年前の修理のときには、「基盤が怪しいけど交換するとなると数万円は自費修理になる」という話でしたが、今回は無償でやってもらえてよかったです。

まとめ

このエアコンで修理に来てもらうのは3回目。

夏はほとんど入れっぱなし。冬は電気オイルヒーターを使っているのでたまにしか使わないぐらいなのに、修理頻度が高すぎます。

無駄に高機能なエアコンは買わないほうが良いですね。

とはいえ、部屋の割には巨大なエアコンを導入したので、すぐに部屋が暖かくなります。

帰宅する前に部屋を温めるようなことをしなくてもよいです。マンションのエントランスで暖房をONにするくらいのタイミングで大丈夫です。

ポイント

修理回数: 3回目（購入から数年で）
修理費用: 無償（保証期間外だが無償対応）
作業内容: 基盤交換
所要時間: 約1時間
原因特定: エラーコードが記録されていたため特定が容易
教訓: 高機能なエアコンは故障リスクも高い

エアコンの能力自体は申し分ないのですが、故障頻度が高いのは気になるところです。次に買い替えるときは、シンプルな機種を選んだほうが良いかもしれません。

実家のネットワークインフラを整備 | 3階建RC造にWiFi AP3台配置

Fri, 09 Jan 2026 00:00:00 GMT

この記事について

学べること

鉄筋コンクリート造建物でのWiFi環境構築のポイント
LANケーブル自作と配線モール施工の実践方法
YAMAHA RTX 1200を使ったネットワーク構成
情報ボックスを使った配線管理のベストプラクティス

想定読者

RC造住宅でWiFi環境に悩んでいる方
鉄筋コンクリート造の建物でネットワークを構築したい方
有線LAN配線を自分で施工してコストを抑えたい方

前提条件

LANケーブル圧着工具とテスターが必要
配線モールの施工スキル
推定所要時間: 1-2日（配線距離による）

概要

実家のネットワーク・インフラを整備しました。

3階建で、鉄筋コンクリート建てなのでWiFiの電波が飛びづらいので各階の踊り場にWiFi APを設置しました。

予備知識：鉄筋コンクリートとWiFiの関係

鉄筋コンクリートの壁だとほとんどWiFiの電波が透過しません。

透過しないどころか、結構吸収している感じがします。2GHzも5GHzも。

階段もコンクリートで作られているので階をまたいで、ドアを通過して各部屋に電波を届かせるのは1台のアクセスポイントでは無理でした。

ネットワーク機器

今回使用した機器は以下の通りです。

ルーター

YAMAHA RTX 1200 - 業務用ルーター、安定性と拡張性が高い

WiFi アクセスポイント

既存の3台を活用
- NEC製 1台
- TP-Link 2台

ネットワークケーブル

Cat6A LANケーブル 100m を購入
必要な長さに自分でカット
コネクタを圧着工具で取り付け

物理ネットワーク構成

ネットワークの配線構成は以下の通りです。

2F寝室: 光コンバーター → 電話分配器 → YAMAHA RTX 1200
2F踊り場: 情報ボックスを設置 → 1000MBaseT対応のL2スイッチ
各階への分配: L2スイッチから1Fと3Fへ有線LANで分配
WiFi AP接続: 各階の踊り場にWiFi APを配置

この構成により、各階で安定したWiFi環境を実現しました。

完成写真

完成したところの写真です。

配線モールで綺麗に配線を整理しています。

中身はこんな感じです。

中身をもう少しズームで。

L2スイッチとケーブルが整然と配置されています。

使用した資材

今回の工事で使用した資材をまとめます。

配線モール

::amazon{asin="B0FJQDJG3J"}

壁面に這わせるケーブルを保護・整理するために使用。

配線モールカッター

::amazon{asin="B0BZSKMMHW"}

配線モールを綺麗にカットするための専用工具。

ラベルテープ

::amazon{asin="B0BCXR95VZ"}

各ケーブルに用途を記載して管理を容易に。

LANケーブル圧着工具とテスター

::amazon{asin="B0CQ2DR8VS"}

Cat6A対応のコネクタを圧着するための工具とケーブルテスター。

Cat6A LANケーブル 100m

::amazon{asin="B0CLJM94PP"}

10Gbps対応のCat6Aケーブル。将来的な速度向上にも対応可能。

スイッチングハブ

::amazon{asin="GS305-300JPS"}

適当に安いL2 Switchを選びました。理論値に近い950Mbpsは出るので十分です。

ベンチマーク結果

実際に速度を測定しました。

木製のドアを隔てた場所では700Mbps近く出ます。

ちょっと離れたりすると400Mbpsでした。

普段使いには十分な速度かなと思います。

スマートフォンでの測定結果。下り速度が600Mbps以上出ています。

施工のポイント

LANケーブルの自作

Cat6Aケーブルは100m購入して、必要な長さにカットしました。

圧着工具を使ってRJ45コネクタを取り付けます。

テスターで導通確認を行い、8本の芯線がすべて正しく接続されていることを確認するのが重要です。

配線モールの施工

壁面に這わせるケーブルは、配線モールで保護します。

専用カッターを使うと、綺麗に切断できて仕上がりが良くなります。

曲がり部分は専用の継手を使うと見た目も良く、ケーブルの保護もしっかりできます。

情報ボックスの設置

2Fの踊り場に情報ボックスを設置して、L2スイッチを収納しました。

ここから各階へケーブルを分配することで、配線がスッキリして管理しやすくなります。

ラベルテープで各ケーブルに「1F AP」「3F AP」といったラベルを貼っておくと、後々のメンテナンスが楽です。

まとめ

実家の3階建RC造にネットワークインフラを構築した記録です。

WiFi環境: 各階にAP配置で全フロア快適に利用可能
速度: 700Mbps（木製ドア越え）、400Mbps（距離あり）で実用十分
配線: Cat6Aケーブル100mを自作で配線、将来の10Gbps対応も可能
コスト削減: ケーブル自作と配線モール施工で業者依頼より大幅削減
管理性: 情報ボックスとラベルテープで配線管理が容易

鉄筋コンクリート造の建物でWiFi環境に悩んでいる方は、各階にAPを配置する方式がおすすめです。

有線LAN配線は少し手間ですが、Cat6Aケーブルを自作することでコストを抑えつつ、将来的な速度向上にも対応できる構成になりました。

YAMAHA RTX 1200は業務用ルーターなので安定性が高く、設定の自由度も高いので、本格的なホームネットワークを構築したい方におすすめです。

QNAP NASにTailscaleをインストールして外出先からアクセスできるようにする

Fri, 19 Dec 2025 00:00:00 GMT

QNAP TS-431PというNASをRAID 1構成で運用しており、2TBのディスクを4台使用しています。今回、Tailscaleを導入することで、外出先のスマートフォンやPCから安全にNASへアクセスできる環境を構築しました。

QNAP TS-431Pについて

使用しているNASは以下のモデルです。

https://www.qnap.com/ja-jp/product/ts-431p

ARM CPUを搭載した4ベイNASで、自宅のファイルサーバーとして活用しています。

::amazon{asin="B08F7QYJLS" kw="QNAP TS-431P 4ベイ NAS"}

Tailscaleとは

Tailscaleは、WireGuardをベースとしたVPNソリューションで、複雑なネットワーク設定なしに、異なるネットワーク上のデバイス同士を安全に接続できるサービスです。従来のVPNと比べて設定が簡単で、NAT越えも自動で処理してくれるため、自宅のNASへのリモートアクセスに最適です。

パッケージのダウンロード

まず、QNAP用のTailscaleパッケージをダウンロードします。

GitHubのリリースページから、使用しているNASのアーキテクチャに合ったパッケージを選択します。

https://github.com/tailscale/tailscale-qpkg/releases/tag/v1.58.2

アーキテクチャの確認

TS-431PのCPUはARM Cortex-A15なので、ARM用パッケージを選択します。

[matsu@ts431p Tailscale]$ cat /proc/cpuinfo
processor       : 0
model name      : Annapurna Labs Alpine AL212 Dual-core ARM Cortex-A15 CPU @ 1.70GHz
Speed           : 1.7GHz
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0xc0f
CPU revision    : 4

processor       : 1
model name      : Annapurna Labs Alpine AL212 Dual-core ARM Cortex-A15 CPU @ 1.70GHz
Speed           : 1.7GHz
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0xc0f
CPU revision    : 4

Hardware        : Annapurna Labs Alpine
Revision        : 0000
Serial          : 0000000000000000

上記の情報から、以下のパッケージをダウンロードします。

Tailscale_1.58.2-1_arm-x41.qpkg

インストール手順

1. パッケージのアップロード

ダウンロードしたパッケージを、QNAP管理画面（QTS）の「App Center」からアップロードしてインストールします。

「手動インストール」を選択し、ダウンロードしたqpkgファイルを指定してインストールを実行します。

Tailscaleの起動

問題: 管理画面から起動できない

インストール後、QNAP管理画面上にTailscaleアプリが表示されますが、起動しようとすると「Internal Server Error」が発生して起動できない問題に遭遇しました。

解決方法: SSH経由での起動

この問題は、tailscaledデーモンが起動していないことが原因です。SSH経由でNASにログインし、手動で起動する必要があります。

[matsu@ts431p Tailscale]$ cd /share/CACHEDEV1_DATA/.qpkg/Tailscale
[matsu@ts431p Tailscale]$ ls
Tailscale.sh* state/        tailscale*    tailscaled*   ui/

[matsu@ts431p Tailscale]$ ./Tailscale.sh start
ln: /home/httpd/cgi-bin/qpkg/Tailscale/ui: Permission denied

[matsu@ts431p Tailscale]$ sudo ./Tailscale.sh start

[matsu@ts431p Tailscale]$ ps | grep tailscaled
30731 admin     28156 S   /share/CACHEDEV1_DATA/.qpkg/Tailscale/tailscaled --port 41641 --statedir=/share/CACHEDEV1_DATA/.qpkg/Tailscale/state --socket=/tmp/tailscale/tailscaled.sock
30975 matsu       388 S   grep tailscaled

sudo権限で起動スクリプトを実行すると、tailscaledが正常に起動します。

Tailscaleへの認証

認証手続き

tailscaledが起動すると、QNAP管理画面のTailscaleアプリに「Reauthenticate」ボタンが表示されるようになります。

このボタンをクリックすると、Tailscaleの認証ページにリダイレクトされます。

TailscaleアカウントでログインしてNASを承認すると、Tailscaleネットワークに参加できます。

設定完了

認証が完了すると、QNAPアプリ上で以下のような画面が表示されます。

これで設定は完了です。TailscaleがインストールされているスマートフォンやPCから、NASに割り当てられたTailscale IPアドレス（100.x.x.x形式）でアクセスできるようになります。

まとめ

QNAP NASへのTailscaleインストールは、管理画面からの起動に問題があるものの、SSH経由で手動起動することで解決できました。一度設定してしまえば、外出先からも安全にNASへアクセスできる環境が整います。

ポイント

QNAP用のTailscaleパッケージは、NASのアーキテクチャに合ったものを選択
初回起動時はSSH経由でsudo ./Tailscale.sh startを実行する必要がある
認証後はTailscaleネットワーク経由で外部から安全にアクセス可能

Tailscaleを使うことで、ポート転送やDDNSの設定なしに、セキュアなリモートアクセス環境を簡単に構築できるため、自宅NASの利便性が大きく向上しました。

APC UPSのバッテリーを交換。3,000円で再生品ではない新品電池！（BR-550S-JP E)

Sat, 13 Dec 2025 00:00:00 GMT

はじめに

2021年4月12日に自宅サーバー、ネットワーク機器の電源を保護するためにAPCのUPSを購入しました。

型番は BR-550S-JP E です。

::amazon{asin="B06XHZ3K5T"}

UPSバッテリーの一般的な寿命について

家庭用・SOHO向けUPSに使われている鉛蓄電池（シールド型鉛蓄電池 / VRLA）は、 使用環境にもよりますが、一般的に3〜5年程度が寿命と言われています。

特に以下の条件では劣化が早まります。

常時通電（フロート充電）されている
室温が高い（25℃超）
停電が少なく、放電・充電のサイクルがほぼ無い

今回のUPSは約4年半使用しており、寿命としては妥当なタイミングでした。

問題

稼働し始めて4年半が経過しましたが、2025年12月に入ってからUPSのバッテリーが劣化している旨のアラートが頻発するようになりました。

詳細は以下の記事にまとめてあります。

https://diary.teraren.com/posts/2025-11-27-apc-ups/

対処1：バッテリー再生の試み

ちょうど、車のバッテリーは鉛蓄電池で、サルフェーションを除去して充電すれば、バッテリー自体を交換しなくても復活できるという話を聞きました。

色々調べていくとUPSのバッテリーも鉛蓄電池であることがわかりました。

APCのバッテリーには、ボルト数やバッテリーの種別が細かく書いていないので、色々調べていくと12V 7.2Ahの鉛蓄電池であることがわかりました。

APCのバッテリーの電圧を計測してみたら、 10.84V しかありませんでした。この電圧降下がバッテリー劣化の原因と思われます。

鉛蓄電池の場合はこの電圧降下はサルフェーションによるものと思われるので、サルフェーション除去充電をすることにしました。

あまりモノを増やしたくないので、小型で安価な充電器を探したところ、以下の製品が見つかりました。

::amazon{asin="B0D54NF9KG"}

シンプルな充電器なので色々と手動で行う必要がありそうです。本体には「Repair」というボタンがあるだけです。このRepairボタンを押すとサルフェーション除去充電が開始されるようです。みんからのレビューでも鉛蓄電池のサルフェーション除去に効果があると書かれていました。

でもちょっと怖いですね。

一応、Gemini 3 Proにもどのくらいパルス充電すべきかを聞いてみました。

一旦、24時間〜48時間という回答が返ってきたので、電池本体の温度を計測しながら充電することにしました。また、膨張がないかも定期的に目視しながら充電することにしました。

充電器のクリップが端子に固定できなかったので、プラス側は平型端子を自作して端子を露出して掴めるようにして充電を開始しました。

パルス充電を開始して、20時間程度経過したら「Full」という表示が充電器に出ました。

電圧を計測してみると、11.42Vまで回復していました。

UPSに戻してみましたが、相変わらずエラーが出てしまいます。

Geminiに再度聞いてみたら以下のような回答でした。

充電を中止する: これ以上の長時間充電は、バッテリーに不要な熱をかけるリスクが高く、安全上の懸念があります。廃棄を検討する: このバッテリーは、UPSという重要な用途のバックアップ電源として使用するには、信頼性が完全に失われています。CSBのバッテリーはリサイクルが可能ですので、お住まいの自治体や専門の回収業者に相談し、廃棄処分を強くお勧めします。新品への交換: APC RS 550Sを今後も利用されるのであれば、新しい純正RBC（Replacement Battery Cartridge）または互換品（7.2Ah）の購入が必要です。

なので、このバッテリーの再生は諦めました。

なぜ電圧が回復してもUPSでは使えなかったのか

鉛蓄電池は、開放電圧がある程度回復しても、以下の特性が劣化している場合があります。

内部抵抗の増加
瞬間的な大電流供給能力の低下
容量（Ah）の実質的な低下

UPSは停電時に瞬時に大電流を供給できることが重要なため、単純に電圧が11〜12Vに戻っただけでは「正常」とは判断されません。

今回、UPSに戻してもエラーが解消されなかったのは、内部抵抗や容量劣化をUPS側のセルフテストで検知された可能性が高いと考えられます。

安全面の補足（重要）

※ 注意 UPS用バッテリーの再生（サルフェーション除去）は、

発熱
ガス発生
膨張・破裂

といったリスクを伴います。特に室内で行う場合は、換気・温度監視・目視確認を必ず行う必要があります。

業務用途や重要機器のバックアップ用途では、再生バッテリーの使用は推奨されません。

対処2：互換バッテリーの購入

UPSのバッテリーの上部にQRコードがあって、それをスキャンしてみると電池の詳細が判明しました。 CSBというメーカーの「GPL1272F2FR」になります。12V/7.2Ahの鉛蓄電池です。

APCはこのバッテリーにラベルを付けて販売しているようです。

ちなみに純正品はかなり高くて、新品のUPS（18,000円程度）を1台買えるのと同じくらいの値段（14,000円程度）になります。

::amazon{asin="B004OOY914"}

Amazonでこの純正品に対する 再生品 の互換バッテリーが売っていることがわかりました。しかし、金額はさほど安くはありません。（7,000円程度）

::amazon{asin="B01NAH8YHO"}

さらに調査を進めると、この12V 7.2Ahの鉛蓄電池は色々なメーカーから販売されていることがわかりました。サイズも規格品なので、以下のようなもっと安価なバッテリーも見つかりました。

::amazon{asin="B06XXD7KC8"}

もっと安価なものもありますが、信頼性を考慮してこのあたりのものを購入しました。 Amazonなので配送も早く、注文してから2日で到着しました。

手前が古いバッテリー、奥が新しいバッテリーです。 よく見るとAPCの電池は傷だらけでした。これ自体が再生バッテリーのように見えます！

右が新しいバッテリー、左が古いバッテリーです。大きさが全く同じです。端子の形状が少し違いますが、問題なく接続できました。

新しいバッテリーの電圧を測定してみたら、13.07Vありました。新品なので当然ですね。

以下のようにしてインストールします。ぴったりです。

APCのUPSの電源を入れてみたら、正常に認識しました。アラートもでません。

商用電源を投入してから数秒経つと、バッテリーのセルフテストが走って残り時間などが表示されました。

これで無事にバッテリー交換が完了しました。UPS自体はまだまだ使えるので、バッテリー交換だけで延命できてよかったです。

UPS用互換バッテリー選定時のチェックポイント

汎用の12V 7.2Ah鉛蓄電池を選ぶ際は、以下の点を確認しました。

電圧・容量
- 12V / 7.2Ah（±0.5Ah程度は許容）
サイズ
- 約151 × 65 × 94 mm（一般的な7.2Ah規格）
- ケースに収まることが重要
端子形状
- F2端子（平型 6.3mm）
- 形状が違っても接続できる場合が多いが要確認
用途
- UPS用途対応（ディープサイクル想定）
- 「非常用電源」「UPS」「非常灯」用途と明記されているものが望ましい
新品であること
- 再生品・長期在庫品は避ける

UPS用途で汎用バッテリーを使う際の注意点

車用バッテリーと異なり、UPSでは以下が重要です。

瞬時の放電性能（停電時）
常時フロート充電への耐性
長期間「満充電状態」で劣化しにくいこと

そのため、安価すぎるノーブランド品や、用途が不明確なバッテリーは避けた方が無難です。

今回は価格と信頼性のバランスを考え、国内流通実績のある製品を選びました。

参考情報

https://pepeprism.hatenablog.com/entry/2023/12/03/202852 https://bbs.kakaku.com/bbs/K0000934956/#25813114

まとめ（結論）

コストまとめ

純正バッテリー: 約14,000円
APC互換バッテリー: 約7,000円
汎用12V 7.2Ah鉛蓄電池: 約3,000〜5,000円

今回は汎用バッテリーを購入し、純正品と比べて約10,000円のコスト削減に成功しました。

重要ポイント

APC BR-550S-JP E のバッテリーは 12V 7.2Ahの規格品
純正RBCは高価だが、新品の汎用バッテリーで問題なく代替可能
サルフェーション除去による再生は、UPS用途では現実的ではない
バッテリー交換だけでUPS本体を長く使える

安価な互換バッテリーでも問題なく動作し、交換作業も比較的簡単でした。同様の症状でお悩みの方は、自己責任でバッテリー交換を試してみてください。

povoからの請求に不当な請求があったので調査した話

Fri, 12 Dec 2025 00:00:00 GMT

はじめに

KDDIのpovoを不定期に使っているのではあるが、直近は使っていないのに200円の請求が上がってきた。

名目は、「海外ローミングSMS」という項目。金額が小さから放置してもよいのだが、今後も同様のことが発生すると困るので、調査した。

調査

Xや検索したりGeminiに聞いてみたが、特に海外に行っていないのにSMSが来ることはない、とのこと。
povoのFAQを見てみたが、特に該当するような記述は見当たらない。
海外からの着信を受け取っただけで受け取り側で課金されるかもしれないので、一応電話の履歴とSMSの履歴を確認したが、特に海外からの着信はない。

ぐぐってみると、PovoのFAQをには身に覚えのない施灸があったらお問い合わせをしろと書いてあった。

そこで、povoのサポートに問い合わせた。povoのアプリ上のチャットで問い合わせる形。状況説明などを15分程度行った後、povo側の持ち帰り案件となった。

1日後、以下のような回答が来た。

海外へ渡航されていないにもかかわらず料金が発生している状況とお伺いしております。

社内で協議させていただいた結果、今回の海外ローミングSMSの料金につきましては、返金対応をさせていただくこととなりました。

返金のお手続きにはお日にちをいただく見込みでございます。完了いたしましたら、改めてメールにてご連絡させていただきますので、お待ちいただけますと幸いです。

この度はご不安な思いをさせてしまい、大変申し訳ございませんでした。

全く納得できない。原因がわからないのに、返金対応をされても困るし、再発防止が示されていない。

追記

2025/12/24

povoのシステム側の問題だったようで、影響が出ているユーザは自分だけではなく、多数いた模様。

平素よりpovo2.0をご利用いただき、誠にありがとうございます。

本メールは12月ご請求の(11月利用分)料金において、海外ローミングSMS送信料*が発生している一部のお客様へお送りしております。 *ご利用料金の明細確認方法はこちらをご覧ください。(https://povo.jp/support/invoice/)

2025年11月ご利用分に、実際には海外ローミングSMSのご利用がないお客様にも海外ローミングSMS送信料をご請求している場合があることが判明いたしました。現在はシステム側の対処により、すでに同様の事象は発生しない状況となっておりますので、ご安心ください。

そのため、12月のご請求において、海外ローミングSMS送信料金の返金手続きを実施いたしました。

なお、ご利用の決済会社への返金データの連携に2週間程度要する場合がございますので、反映までお待ちくださいますようお願い申し上げます。具体的な返金日は決済方法によって異なりますため、お手数おかけしますが、クレジットカード会社またはあと払い(ペイディ)窓口へお問い合わせをお願いいたします。

このたび、お客様にご迷惑、ご心配をおかけいたしましたことを深くお詫び申し上げます。

今後このようなことがないよう再発防止に努めてまいります。引き続きpovo2.0をご愛顧賜りますようお願い申し上げます。

Palantir AIPの正体：なぜ「Chat」ではなく「OS」なのか？そのアーキテクチャを解剖する

Wed, 03 Dec 2025 00:00:00 GMT

はじめに：AIを「おしゃべり」で終わらせないために

現在、多くのエンジニアが生成AIの業務適用（RAG等）に取り組んでいますが、多くのプロジェクトが「社内ドキュメントを検索して要約する」という Read-Onlyなチャットボット の域を出ずに停滞しています。

一方で、Palantir AIP (Artificial Intelligence Platform) は、チャットUIを通じて「発注する」「生産計画を変更する」といった Write/Action まで完結させる「OS（オペレーティングシステム）」として機能しています。

なぜPalantirにはそれが可能なのか？単にプロンプトエンジニアリングが優れているからではありません。

わかりやすく乱暴に言えば… Palantir AIPは「エンプラ用のDify」です。ただし、Difyの100倍くらい高機能。最大の違いは、Difyが都度データソースを読みに行くのに対し、Palantirはデータをコピー（レプリケート）して専用のストレージに保持しているため、スケーラビリティが圧倒的に高いという点です。 </div>

本記事では、マーケティング的な用語を排し、その裏側にある 「Ontology（オントロジー）」という独自のデータミドルウェアと、分散KVS + 検索エンジンを組み合わせたハイブリッド・アーキテクチャ を技術的に解剖します。

1. 全体アーキテクチャ：3層構造の解剖

Palantir AIPは、単なるLLMラッパーではありません。その本質は、LLMに「現実世界の地図（Context）」と「手足（Tool）」を与えるための強固なバックエンドシステムにあります。

graph LR
    %% 全体アーキテクチャ
    subgraph "1. Data Sources (物理層)"
        ERP[(ERP)]
        CRM[(CRM)]
        IoT[("IoT Sensors")]
        SaaS[("SaaS API")]
        Files[("CSV/PDF")]
    end

    subgraph "2. Palantir AIP Platform"
        subgraph "Data Integration Layer"
            Connectors["200+ Connectors"] -- "Ingest (Batch/Stream)" --> RawData["Raw Data Storage"]
            RawData -- "Transform (Pipeline Builder)" --> CleanData["Cleaned Tables"]
        end

        subgraph "Ontology Layer (The Context)"
            CleanData -->|Map & Link| Ontology["Ontology Core"]
            Ontology -->|Define Objects, Properties, Links| ObjectModel["Object Model"]
            Ontology -->|Define Actions & Functions| ActionDefinitions["Action Definitions"]
        end

        subgraph "AIP LLM Mesh (The Brain)"
            Ontology -->|RAG / Grounding| Router{"LLM Router"}
            Router -->|Select Model| LLMs["LLM Pool<br/>(GPT-4, Claude, Llama, etc.)"]
        end
        
        subgraph "Action & Logic (The Tool)"
            LLMs -->|Reasoning Result| Logic{"AIP Logic / Guardrails"}
            Logic -->|Authorize & Execute| ActionExec["Action Executor"]
        end
    end

    subgraph "3. User Interface & External Systems"
        ActionExec -->|Write-back| ERP
        ActionExec -->|Write-back| CRM
        Logic -->|Response & Suggestion| UserUI["AIP Terminal / Workshop UI"]
        UserUI -->|Human Feedback / Approval| Logic
    end

    ERP -.-> Connectors
    CRM -.-> Connectors
    IoT -.-> Connectors
    SaaS -.-> Connectors
    Files -.-> Connectors

    style Ontology fill:#f9f,stroke:#333,stroke-width:2px,color:black
    style LLMs fill:#ccf,stroke:#333,stroke-width:2px,color:black
    style Logic fill:#ff9,stroke:#333,stroke-width:2px,color:black
    style ActionExec fill:#f99,stroke:#333,stroke-width:2px,color:black

アーキテクチャは大きく3つのレイヤーで構成されています。

1. Ontology (The Context Layer)

物理的なデータ（SQLテーブル、SaaS、IoT等）を「意味のあるオブジェクト」に変換するレイヤー。ここが本記事のメインテーマです。

2. AIP LLM Mesh (The Brain)

特定のモデルに依存しない（Model Agnostic）推論レイヤー。GPT-4、Claude、Llamaなどをタスクに応じて動的に切り替えるルーティング機能などを持ちます。

3. Action & Logic (The Tool)

LLMが推論した結果に基づき、安全に基幹システムへの書き込み（Write-back）を行うためのAPIゲートウェイおよび権限管理機構。

2. Deep Dive：オントロジーの物理アーキテクチャ

エンジニアとして最も興味深いのは、「ERPやIoTセンサーなどの数億〜数十億レコードのデータを、どうやってLLMに即座に供給しているのか？」という点でしょう。

公式ドキュメントでは、このデータ基盤は 「Object Storage V2」 と呼称されていますが、その内部実装の詳細は非公開です。しかし、Palantirが開発・公開しているOSS（AtlasDB等）のアーキテクチャから推測すると、 一般的なRDB（PostgreSQLやOracle）をメインストアとして使用していない可能性が高いです。

graph TB
    %% Ontology ストレージ層の詳細
    subgraph "Ontology Backend (Hybrid Storage)"
        
        subgraph "Logical Layer (AtlasDB)"
            TransactionMgr["AtlasDB (Transaction Manager)"]
            NoteAtlas["NoSQL上で<br/>ACIDトランザクションを実現"]
            TransactionMgr --- NoteAtlas
        end

        subgraph "Physical Storage Layer (Compute-Storage Separation)"
            subgraph "Search & Light Aggregation (Find)"
                ES[("Elasticsearch / OpenSearch")]
                NoteES["高速検索<br/>ID特定<br/>軽量集計(Memory)"]
                ES --- NoteES
            end
            
            subgraph "Data Fetch & Storage (Fetch)"
                KVS[("Apache Cassandra / HBase")]
                NoteKVS["Wide-Column Store<br/>スケーラブル<br/>必要な列のみ取得"]
                KVS --- NoteKVS
            end
        end

        TransactionMgr -- "Index Write (Async)" --> ES
        TransactionMgr -- "Data Write (Sync)" --> KVS
    end

    subgraph "Application / LLM Query Flow"
        AppQuery["Client Query"] -- "1. Find IDs (検索)" --> ES
        ES -->|2. Return Object IDs| AppQuery
        AppQuery -- "3. Fetch Data by ID (取得)" --> KVS
        KVS -->|4. Return Hydrated Objects| AppQuery
    end
    
    style ES fill:#d4e157,stroke:#333,color:black
    style KVS fill:#4fc3f7,stroke:#333,color:black
    style TransactionMgr fill:#ffb74d,stroke:#333,color:black

「ER（実体関連）モデル」を扱うためRDBが最適に見えますが、RDBでは大規模な結合（JOIN）とスキーマ変更の柔軟性において限界が来るためです。代わりに、 「分散KVS」と「検索エンジン」のハイブリッド構成 を採用していると考えられます。

2.1 ストレージ層：Cassandra (Wide-Column Store)

実データの保存には、Apache Cassandra（またはHBase等）のような Wide-Column Store が採用されていると推察されます。

なぜBlob Storageではないのか？

単純なKVS（Key=ID、Value=JSON Blob）だと、一部のプロパティ（例：statusのみ）を取得したい場合でも、巨大なオブジェクト全体をメモリにロードする「Over-fetching」が発生します。

Wide-Columnの利点

データは「行（Row）」の中に「列（Column）」の集合として保存されます。クライアントが必要なプロパティを指定すると、ストレージエンジンは 該当するカラムのディスクブロックのみ を読みに行きます。これにより、巨大なオブジェクトでも軽量にアクセス可能です。

2.2 検索・集計層：Elasticsearch (Search Engine)

「IDを指定して取得」以外の操作、つまり「検索」や「集計」にはElasticsearch（またはOpenSearch）を使用していると推測されます。

役割分担 (Compute-Storage Separation)

Find (検索): 「ステータスが『Error』の設備を探す」→ Elasticsearchのインデックスを叩き、対象のObjectIDリストを高速に特定。
Fetch (取得): 特定されたIDを使って、Cassandraから実データをHydrate（水分補給/実体化）する。

軽量集計のオフロード

「地域ごとの売上合計」のような集計クエリに対し、実データをスキャンするのは非効率です。ElasticsearchのAggregation機能（メモリ上の処理）を使うことで、DB負荷をかけずに高速に数値を返します。

2.3 トランザクション制御：AtlasDB

NoSQL（Cassandra）の弱点はACIDトランザクションの欠如ですが、Palantirは 「AtlasDB」 という独自のミドルウェア層を被せることでこれを解決しているようです。これにより、 「NoSQLのスケーラビリティ」と「RDBの整合性」 を両立させています。

3. データ構造と「リンク」の正体

物理層の上にある論理層（オントロジー）では、データはどう定義されているのでしょうか？

graph LR
    %% データ構造の比較
    subgraph "RDB Model (Table & JOIN)"
        T_Machines["t_machines Table"] -- JOIN --> T_Factories["t_factories Table"]
        T_Machines -- JOIN --> T_Parts["t_parts Table"]
        T_Parts -- JOIN --> T_Sensors["t_sensors Table"]
        NoteRDB["巨大なJOIN計算が必要<br/>スキーマ変更が困難"]
        T_Sensors --- NoteRDB
    end

    subgraph "Ontology Model (Object & Link)"
        O_Machine(("Object: Machine")) -- Link: installed_at --> O_Factory(("Object: Factory"))
        O_Machine -- Link: uses_part --> O_Part(("Object: Part"))
        O_Part -- Link: monitored_by --> O_Sensor(("Object: Sensor"))
        NoteOntology["グラフ探索で辿る(高速)<br/>プロパティ追加が容易"]
        O_Sensor --- NoteOntology
    end

    style O_Machine fill:#f9f,stroke:#333,color:black
    style O_Factory fill:#f9f,stroke:#333,color:black
    style O_Part fill:#f9f,stroke:#333,color:black
    style O_Sensor fill:#f9f,stroke:#333,color:black

3.1 オブジェクトのマッピング

SQLのテーブルをそのまま使うのではなく、 「オブジェクト」 として再定義します。

SQLの世界 (Raw Data)	Ontologyの世界 (Semantic Layer)
`SELECT * FROM t_machines`	Object: Machine (設備)
Column: `m_id` (VARCHAR)	Primary Key
Column: `temp_val` (FLOAT)	Property: `Temperature` (時系列データとして扱える)
Column: `stat_code` (INT)	Property: `Status` (Enum: "Running", "Stop")

このマッピングにより、LLMは「t_machinesテーブルのtemp_val」ではなく、 「設備の温度」 という自然言語に近い概念でデータにアクセスできます。

3.2 リンク（Link）≠ JOIN

ここが最大のポイントです。RDBのJOINは実行時に計算コストがかかりますが、オントロジーの「リンク」は グラフのエッジ（辺） として事前定義されます。

構造: [Machine: A] --(installed_at)--> [Factory: B]
探索: RDBのような直積（Cartesian Product）を作るのではなく、グラフ探索（トラバーサル）を行います。
メリット: 「この工場にある設備で作られた製品の、納品先顧客は？」といった4〜5段階のホップが必要なクエリでも、インデックスを辿るだけなので計算量が爆発しません。

4. 動的ユースケース：Actionへの繋がり

この静的なアーキテクチャが、実際にどう動くのか。3つのユースケースでデータの流れを追います。

Case 1: 製造業 - サプライチェーンの断絶を繋ぐ（Write-back）

シナリオ: 原材料の納入遅延が発生し、生産計画の見直しが必要。

Flow:

Alert: オントロジー上の「納入予定日」プロパティが更新され、閾値を超えたためAIPがアラート発報。
Reasoning (LLM): LLMがグラフを辿り、「代替サプライヤーB社」の在庫と単価を取得。「B社への発注」を推奨。
Human Loop: 担当者が画面上で「承認」ボタンを押下。
Action (Write): AIPがERP（SAP等）のAPIを叩き、発注データを書き込む。同時にオントロジー上のステータスも「発注済」に更新される。

Case 2: 病院運営 - リアルタイムリソース配分

シナリオ: 急患搬送。ICUの空きがない。

Flow:

Ingest: 電子カルテとベッドセンサーからリアルタイムデータをCassandraに吸い上げ。
Search: Elasticsearchが「容態が安定（バイタル正常）かつ、一般病棟へ移動可能な患者」を数ミリ秒でリストアップ。
Action: 看護師長のタブレットに「患者移動プラン」を提示し、ワンタップで病床管理システムへ反映。

Case 3: インフラ保守 - 非構造化データの統合

シナリオ: 現場作業員がポンプの異音を検知。

Flow:

Vector Search: 作業員が音声で状況入力。AIPはベクトルDB（検索インデックスの一部）を使い、過去の「類似トラブル報告書（PDF）」を検索。
Hybrid Retrieval: 同時に、対象ポンプの「直近1週間の振動データ（構造化データ）」をKVSから取得。
Synthesis: LLMが「3年前の事例に酷似しています。バルブBの摩耗を確認してください」と回答。

5. 💡 思考実験：自社ならどうなる？

最後に、Palantir AIPのコンセプトを自社に適用した場合のイメージを掴むためのプロンプトを用意しました。以下のプロンプトをChatGPTやClaudeに入力して、思考実験をしてみてください。

## 役割
あなたはPalantir AIPのアーキテクトです。
私の会社/サービスである【ここに自社サービス名や業種を入れる】において、
バラバラに散らばっているデータソース（DB、SaaS、Excel等）を統合し、 「オントロジー（デジタルツイン）」を構築してください。

## 以下の形式で出力してください

1. 定義すべき主要な「オブジェクト」と「プロパティ」（3つ以上）
2. オブジェクト間の「リンク（関係性）」
3. AIが実行可能な「アクション（書き込み処理）」の具体例

## 参考資料
Palantir AIPのアーキテクチャのブレイクダウンはこの記事にまとまっています。
https://zenn.dev/matsubokkuri/articles/palantir-aip-architecture

おわりに

Palantir AIPの事例から学べることは、 「強力なAIアプリケーションを作るためには、強力なデータ基盤（データエンジニアリング）が不可欠である」 という事実です。

LLM単体では、企業の複雑なコンテキストを理解できません。バラバラなデータを「オントロジー」として統合し、高速な検索と取得が可能なアーキテクチャ（Search + KVS）の上に載せることで初めて、AIは「おしゃべり」を超えて「仕事」ができるようになります。

我々エンジニアが次に目指すべきは、単にプロンプトを工夫することではなく、AIが現実世界を正しく認識し、触れることができる 「データのインターフェース」 を設計することなのです。

APC BR550S バッテリー劣化でサーバーダウン | ログ解析

Thu, 27 Nov 2025 00:00:00 GMT

この記事について

学べること

UPSバッテリー劣化時の危険な挙動（セルフテストによる自爆）
apcupsdログから読み取る「死の予兆」の見つけ方
バッテリー警告後の高頻度セルフテストのリスク
安全マージンを取ったシャットダウン設定

想定読者

自宅サーバーやNASでUPSを運用している方
UPSのバッテリー交換警告が出ているが「まだ動くから」と放置している方
apcupsdのログ解析に興味がある方

前提条件

Linux環境でのapcupsd運用経験
基本的なログ解析の知識
推定所要時間: 読了10分

概要

自宅サーバー運用において、最後の砦となるのがUPS（無停電電源装置）です。

しかし、メンテを怠るとUPS自体がSPOF（単一障害点）となり、逆にサーバーをクラッシュさせる原因になるという教科書通りの事象を経験しました。

今回は、APC BR550Sのバッテリー寿命末期における挙動と、apcupsd（UPS監視・管理デーモン）のログから読み取れる「死の予兆」について共有します。

環境とハードウェア

UPS: APC BR550S (BR550S-JP)
OS: Linux (Debian)
管理ツール: apcupsd 3.14.14
購入日: 2021年4月12日
障害発生日: 2025年11月27日（稼働期間：約4年7ヶ月）
予兆: 障害の約1ヶ月前からバッテリー交換警告（赤ランプ＆アラート）が発生

::amazon{asin="B06XHZ3K5T" kw="APC UPS BR550S"}

何が起きたか

結論から言うと、「劣化したバッテリーを積んだUPSがセルフテスト（自己診断）を行い、その瞬間に電圧を維持できずサーバーごと落ちた」 という事象です。

商用電源（コンセント）からは電気が来ているにも関わらず、UPSの挙動によって電源が断たれました。

ログによる解析

1. 頻発する「死のロシアンルーレット」

通常、APCのUPSはデフォルトで 14日（2週間）に1回 のセルフテストを行います。しかし、バッテリー交換警告が出ている末期状態では、挙動が異なりました。

以下は syslog の抜粋です。

864489:2025-11-24T12:46:04.978346+00:00 gmk apcupsd[1630084]: UPS Self Test switch to battery.
864490:2025-11-24T12:46:05.257428+00:00 gmk apcupsd[1630084]: UPS battery must be replaced.
864501:2025-11-24T12:46:07.025059+00:00 gmk apcupsd[1630084]: UPS Self Test completed: Warning

1166439:2025-11-25T01:30:53.985560+00:00 gmk apcupsd[1630084]: UPS Self Test switch to battery.
1166610:2025-11-25T01:30:54.989559+00:00 gmk apcupsd[1630084]: UPS Self Test completed: Warning

1579590:2025-11-25T14:15:40.478205+00:00 gmk apcupsd[1630084]: UPS Self Test switch to battery.
1579650:2025-11-25T14:15:50.698265+00:00 gmk apcupsd[1630084]: UPS Self Test completed: Warning

1911424:2025-11-26T03:00:33.260875+00:00 gmk apcupsd[1630084]: UPS Self Test switch to battery.
1911434:2025-11-26T03:00:35.334053+00:00 gmk apcupsd[1630084]: UPS Self Test completed: Warning

ご覧の通り、約12時間〜13時間おきに UPS Self Test switch to battery（バッテリーへの切り替えテスト）が走っています。

バッテリーが完全に死んでいる状態で、半日に1回、強制的にバッテリー駆動テストが行われる—つまり、1日に2回「運が悪ければ落ちる」ロシアンルーレットが自動実行されている状態でした。

2. ログを残さず「即死」する瞬間

そして迎えた11月26日の夜。

2423952:2025-11-26T18:46:48.927315+00:00 gmk apcupsd[1630084]: UPS battery must be replaced.
（ここでログが途絶える）
2530548:2025-11-26T22:48:09.951429+00:00 gmk systemd[1]: Starting apcupsd.service - UPS power management daemon...

18:46の定期ログを最後に、次は22:48の起動ログまで飛んでいます。

通常、apcupsdがシャットダウンをトリガーした場合は apcupsd exiting, signal 15 といったログが残りますが、今回はそれすらありません。

これは以下のプロセスで落ちたと推測されます。

何らかの理由（セルフテスト、あるいは瞬断）でUPSがバッテリー駆動に切り替わろうとする。
バッテリーの内部抵抗が高すぎて、負荷（サーバー）を支えきれず電圧が瞬時にゼロになる。
OSはログをディスクに書き込む暇もなく、物理的に電源が落ちる（Dirty Shutdown）。
その後、商用電源が安定しているため、BIOSの「AC Power Recovery」設定により自動再起動。

まさに**「UPSがついているからこそ落ちた（スルー出力なら耐えたかもしれない）」**という本末転倒な事態です。

教訓と対策

1. アラートが出たら即交換、あるいはバイパスする

「まだ動いてるし、来週交換しよう」は危険です。

アラートが出ているUPSは、保護装置ではなく時限爆弾です。

交換用バッテリーが手元にない場合は、サーバーのコンセントをUPSから抜き、壁のコンセント（商用電源）に直結する方が、テストによる自爆リスクがない分だけ安全です。

2. apcupsdの設定見直し

今回の設定（/etc/apcupsd/apcupsd.conf）を確認したところ、以下のようになっていました。

BATTERYLEVEL 5
MINUTES 3

「残り5%」または「残り3分」まで粘る設定です。

新品バッテリーならこれで良いですが、劣化したバッテリーでは「残り3分」と表示されていても、負荷がかかった瞬間に電圧降下で落ちる可能性があります。

安全マージンを取り、以下のように早めに倒す設定へ変更することをおすすめします。

BATTERYLEVEL 15  # 15%を切ったらシャットダウン
MINUTES 10       # 残り10分を切ったらシャットダウン

まとめ

寿命: APC BR550Sは約4年7ヶ月（2021年4月〜2025年11月）で交換となりました
危険な挙動: バッテリー警告が出ると、高頻度（半日ごと）でセルフテストが走り、リスクが跳ね上がります
重要な対策: アラートが出たら即座に交換、あるいは商用電源に直結してバイパスする
apcupsd設定: BATTERYLEVEL と MINUTES を余裕を持った値に設定（15%、10分を推奨）
予兆の見つけ方: ログに Power failure や Switch to battery が頻発し始めたら要注意

2025年11月27日、新しいUPSへのリプレイスが完了し、平穏なログが戻ってきました。

皆さんの家のUPSも、バッテリーランプが赤く光っていないか今すぐ確認を。

Amexカード不正利用未遂 | 3Dセキュアで阻止

Tue, 25 Nov 2025 00:00:00 GMT

ことの発端

SNSと電子メール宛に3Dセキュア（本人認証サービス）の認証コードが届きました。

手元で調査

まず、この送信元がクレジットカードの発行元からの正規のメールかどうかを確認するため、メールアドレスをググってみた。過去にも同じメールアドレスが使われていることが確認でき、怪しい情報も出てこなかったため、フィッシングメールではないと判断した。

通知内容を見ると、Mercari_browser という加盟店からの請求となっている。しかし、最近メルカリで買い物をした覚えはまったくない。

さらに、決済金額が9,700円と、絶妙に10,000円を下回る少額であることも不自然に感じた。これらのことから、メルカリでの不正利用である可能性が高いと判断した。

クレカ会社に問い合わせ

クレジットカード会社に電話で問い合わせたところ、この3Dセキュア認証の通知は本物であることが確認できた。ただし、私自身は決済を試みていないため、第三者による不正利用の試みであることが判明した。

クレジットカード番号とセキュリティコードが何らかの経路で流出し、不正に使用されようとしている可能性が高いとのこと。

不正利用を防止するため、カード番号の再発行を依頼した。新しいカードが届くまでには約1週間かかるとのことだった。

なお、Mercari_browser という加盟店名は一見怪しく見えるが、これがメルカリの正式な加盟店名であることも確認できた。

その後

すでに登録済みの前提で、Amazonでは利用が継続できると電話口で行っていたが、できなかった。（家族カードを自分で使って回避できた）
3日後に速達郵便で再発行された新しいクレジットカードを受け取れた。
Apple Payに登録してあったカードは新しい番号に勝手に置き換わっていたので再登録の必要は無い。

WordPressサイトをAstroへ移行：4700記事のビルドが10秒で完了する構成

Thu, 30 Oct 2025 00:00:00 GMT

3秒まとめ

約4700記事の WordPress サイトを Astro へ移行し、ビルド時間はわずか10秒を実現
wordpress-export-to-markdownを使ってコンテンツを自動変換、Claude Code で効率的にデータ処理
Cloudflare Pages で無料ホスティング、Lighthouse スコア 100 点達成
全文検索機能も pagefind で実装、トータルの移行作業は数時間で完了

どんな人向けの記事？

WordPress サイトを静的サイトジェネレーターへ移行したい方
大量のコンテンツを効率的に移行する方法を知りたい方
Astro を使った実践的な移行事例を参考にしたい方
サーバー運用コストを削減したい方

概要

前回、WordPress で作られた写真ポートフォリオサイトを Astroに移管してみたときにメリットしかなかったので、引き続きWordPressサイトをAstroに移管していきます。

移管が簡単なサイトから順番に置き換えていく方針です。

今回移行したサイトはこちら: https://covid19.teraren.com/

UIの変化

まずは見た目の変化を確認しましょう。

Before

トップページ

個別ページ

After

トップページ

個別ページ

移行手順の概要

WordPress から Astro への移行手順を以下にまとめます。各ステップの詳細はこの後に説明します。

移行前サイトの特性理解
Astroのテンプレート探し
Astroプロジェクトの初期化
WordPressからのフルバックアップ取得
バックアップデータのAstroへの復元
Astro上での各種調整
Cloudflare Pagesへのデプロイ

0. 移行前サイトの特性理解

記事数は約4700記事。毎日 × 10 都道府県 × 2 年間のデータ（期間や都道府県に歯抜けが多い）で構成されています。各記事の文章は短く、画像のグラフが重要なコンテンツとなっています。

URL構造を維持する必要があります。記事数が膨大なため、リダイレクトではなく同じ URL フォーマットを保持します。

URL フォーマット: https://covid19.teraren.com/<year>/<month>/<day>/<slug>/

URL 例: https://covid19.teraren.com/2022/09/25/ishikawa-560/

PV はほとんど無いサイトなので、サクッとデータを移行してサーバー運用を楽にしたいというのが今回の狙いです。

1. Astroのテンプレート探し

Astro公式サイトのテーマライブラリから、Freeのフラグをオンにしてサクッと探しました。

今回見つけたのがこちらの Astro News。シンプルなUIでニュースサイト用のUXを提供するテーマです。

2. Astroプロジェクトの初期化

今回は公式提供のテーマではないため、GitHub リポジトリを直接 clone して使います。MIT ライセンスなので安心して利用できます。

git clone git@github.com:Mrahmani71/astro-news.git

完成品をcloneしているので、あとは自分好みにパパっと変更していくだけです。

リポジトリをcloneしただけだとパッケージが古い可能性があるため、最新版にアップデートしておきます。

npm update

3. WordPressからのデータエクスポート

WordPressの管理画面から「ツール」→「エクスポート」を選択してデータをエクスポートします。

ここで取得できるのはテキストデータ（投稿内容、メタデータなど）のみです。アップロードされている画像などのアセットはURL形式のリンクとして記録されます。 </div>

でも大丈夫！　次のステップで使用するツールが、XMLファイル内のアセットURLを検知して自動的にローカルにダウンロードしてくれます。優秀！

エクスポートファイルは covid19.WordPress.2025-10-23.xml のようなファイル名で保存されます。

4. データのMarkdown変換

wordpress-export-to-markdownを使ってWordPressのデータをMarkdownに変換します。

このツールを実行すると、エクスポートファイルの場所や展開方法について対話形式で質問されるため、順番に答えていきます。

今回は投稿のタイトルやカテゴリ、画像ファイルが整理された状態で取得できれば十分だったため、シンプルな構成を選択しました。

> npx wordpress-export-to-markdown

Starting wizard...
✓ Path to WordPress export file? covid-yukimatsukura.WordPress.2025-10-24.xml
✓ Put each post into its own folder? No
✓ Add date prefix to posts? No
✓ Organize posts into date folders? No
✓ Save images? All Images

Parsing...
54 normal posts found.
1 pages found.
81 attached images found.
55 images scraped from post body content.

Saving posts...
55 posts to save.
✓ [post] shou-ren-in
✓ [post] umbrella
✓ [post] maple-on-the-moss
✓ [post] tanuki-ko
✓ [post] skytree
✓ [post] skytree-2
✓ [post] tokyo-tower
✓ [post] summer-morning
✓ [post] relais-la-suvera
✓ [post] ginza
✓ [post] relais-la-suvera
✓ [post] colosseo
✓ [post] grotta-azzurra
✓ [post] venetia
✓ [post] positano
✓ [post] eiffel-tower

すべての画像データが自動的にダウンロードされます。 容量は約800MBありました。Cloudflare Pagesの無料プランでホスティングする予定だったため、上限に引っかかる可能性を心配していましたが、問題なく無料枠でデプロイできました。

5. Astroへのデータインポート

約4700記事あるため、CLIで効率的にデータをコンバートする必要がありました。shellとの相性が良いClaude Codeを使用してコンバート処理を実装しました。

プロンプトは以下のように簡潔に書きましたが、これですべての記事を自動変換できました。

こちらのサイト(https://covid19.teraren.com/) をAstroで再構築します。このレポジトリを基本として進めます。 covid19.teraren.com の全部の記事はexportして covid19-WordPress.2025-10-29.xml に保管してあります。
このXMLファイルを処理して、markdownでコンバートして、画像ファイルを保管したディレクトリが、 `output/`
以下になります。

このコンテンツをカレントディレクトリのAstroのレポジトリでインポートしてください。XMLファイルは巨大なので一気に読み込まないでください。covid19.teraren.com をチェックしてもらえればわかると思いますが、コンテンツとしては4000ページあります。整理の方法は、日本の都道府県ごとに、1日1つの記事が生成されます。記事の内容は短いです。

記事には1つの画像があり、その画像が重要な画像となります。

Claude Codeは、データのコンバートと同時に各ページを表示するAstroファイルも生成してくれました。処理の後半で細かな実装方法について質問されたため、いくつか回答するだけで完了しました。

画像ファイルの配置方法

大きな論点として、画像ファイルをどう管理するかという点がありました。

選択肢:

src/ 以下に配置してAstroの画像最適化を利用する
public/ 以下に置いて単純に読み込む

前者が理想的ですが、ビルド時間が長くなること、そしてサイトへのアクセスがほとんど無いため最適化の優先度が低いという理由で、public/ に配置する方針を選択しました。

この方法により、コンテキストの消費を抑えつつ、高速にインポートできました。データをGit add, git commitする際は、ファイル数が多いため約1分かかりました。

作られたファイルは以下のような構造です。

❯ fd mdx src/|head -n 50
src/content/views/error404.mdx
src/content/views/authors.mdx
src/content/views/articles.mdx
src/content/views/categories.mdx
src/content/views/author.mdx
src/content/views/home.mdx
src/content/views/search.mdx
src/content/views/contact.mdx
src/content/covid19/2021/12/ishikawa-295.mdx
src/content/covid19/2021/12/kanagawa-384.mdx
src/content/covid19/2021/12/kanagawa-390.mdx
src/content/covid19/2021/12/kanagawa-385.mdx
src/content/covid19/2021/12/ishikawa-294.mdx
src/content/covid19/2021/12/gifu-269.mdx
src/content/covid19/2021/12/ishikawa-296.mdx
src/content/covid19/2021/12/kanagawa-378.mdx
src/content/covid19/2021/12/kanagawa-387.mdx
src/content/covid19/2021/12/kanagawa-386.mdx
src/content/covid19/2021/12/kanagawa-379.mdx
src/content/covid19/2021/12/ishikawa-297.mdx
src/content/covid19/2021/12/ishikawa-287.mdx
src/content/covid19/2021/12/ishikawa-293.mdx
src/content/covid19/2021/12/kanagawa-369.mdx
src/content/covid19/2021/12/kanagawa-382.mdx
src/content/covid19/2021/12/kanagawa-383.mdx
src/content/covid19/2021/12/kanagawa-368.mdx
src/content/covid19/2021/12/ishikawa-292.mdx
src/content/covid19/2021/12/ishikawa-290.mdx
src/content/covid19/2021/12/kanagawa-381.mdx
src/content/covid19/2021/12/kanagawa-380.mdx
src/content/covid19/2021/12/ishikawa-291.mdx
src/content/covid19/2021/12/tokyo-383.mdx
src/content/covid19/2021/12/tokyo-354.mdx
src/content/covid19/2021/12/tokyo-368.mdx
src/content/covid19/2021/12/mie-187.mdx
src/content/covid19/2021/12/mie-186.mdx
src/content/covid19/2021/12/tokyo-369.mdx
src/content/covid19/2021/12/tokyo-355.mdx
src/content/covid19/2021/12/tokyo-382.mdx
src/content/covid19/2021/12/tokyo-380.mdx
src/content/covid19/2021/12/tokyo-357.mdx
src/content/covid19/2021/12/mie-184.mdx
src/content/covid19/2021/12/kochi-2.mdx
src/content/covid19/2021/12/mie-185.mdx
src/content/covid19/2021/12/tokyo-356.mdx
src/content/covid19/2021/12/tokyo-381.mdx
src/content/covid19/2021/12/fukui-189.mdx
src/content/covid19/2021/12/fukui-172.mdx
src/content/covid19/2021/12/tokyo-352.mdx
src/content/covid19/2021/12/mie-181.mdx

画像ファイルは以下のような構造になります。

❯ fd 'gruff.*png' public/ | head -n 20
public/images/hero/gruff20220926-1-r4c6mc-cut.png
public/images/2022/06/gruff20220624-1-okz7x0.png
public/images/2022/06/gruff20220607-1-h6ieww.png
public/images/2022/06/gruff20220629-1-dv16k9.png
public/images/2022/06/gruff20220625-1-7l432r.png
public/images/2022/06/gruff20220605-1-n4hq4x.png
public/images/2022/06/gruff20220623-1-tumiku.png
public/images/2022/06/gruff20220618-1-6cb8hw.png
public/images/2022/06/gruff20220625-1-708n0u.png
public/images/2022/06/gruff20220626-1-pqm5nt.png
public/images/2022/06/gruff20220624-1-udulbu.png
public/images/2022/06/gruff20220605-1-ramra9.png
public/images/2022/06/gruff20220622-1-qpzcon.png
public/images/2022/06/gruff20220618-1-bb9fyw.png
public/images/2022/06/gruff20220604-1-gupi4z.png
public/images/2022/06/gruff20220602-1-90m8te.png
public/images/2022/06/gruff20220602-1-jybrnb.png
public/images/2022/06/gruff20220605-1-b613w6.png
public/images/2022/06/gruff20220601-1-r4d1em.png
public/images/2022/06/gruff20220606-1-pw5yvo.png

全文検索機能の実装

pagefindを使って、静的サイトでも全文検索できるようにします。

Astroとのインテグレーションキットがあるため導入は簡単です。インクリメンタルに全文検索が動作します: https://covid19.teraren.com/search/?q=%E6%9D%B1%E4%BA%AC

全文検索用のインデックスはビルド時に作成されます。今回は約3分（206秒）かかりました。結構時間がかかるため導入はトレードオフですね。今回のサイトでは全文検索のユースケースはほとんど無いと思いますが、将来的な拡張性を考慮して実装しました。

02:28:45.462	17:28:45 [@astrojs/sitemap] `sitemap-index.xml` created at `dist`
02:28:48.462	17:28:48 [build] Waiting for integration "pagefind", hook "astro:build:done"...
02:29:03.469	17:29:03 [pagefind] Pagefind indexed 5222 pages
02:29:03.476	17:29:03 [pagefind] Pagefind wrote index to /opt/buildhome/repo/dist/pagefind
02:29:03.477	17:29:03 [build] 5222 page(s) built in 206.27s
02:29:03.477	17:29:03 [build] Complete!

ビルドされたインデックスファイルは静的ファイルとしてデプロイされ、ブラウザからダウンロードされます。検索はブラウザ上のJavaScriptランタイムで実行される仕組みです。 ダウンロードされたインデックスサイズは約70KBと軽量でした。

サーバサイドに保存されているindexはファイルごとに分割されいて、19MBでした。

❯ du -hs dist/pagefind/
 19M    dist/pagefind/

6. Cloudflare Pagesへのデプロイ

Cloudflare PagesでGitHubと連携して、今回作成したリポジトリを指定します。リポジトリのタイプをAstroと選んでデプロイボタンをポチッと押したら、約6分後にデプロイ完了しました。

データ容量が約 1GB、pnpm build で出力されたファイル数は1万以上あるため、ネットワーク転送とディスク I/O に時間がかかっています。

今回もほとんど更新が無い静的コンテンツのため、CloudflareのCDNを有効化して配信しています。

パフォーマンスベンチマーク

今回は大きな写真データは無いですし、UI もこだわっていないのでパフォーマンスが良いです。

トップページのLighthouseスコア

個別ページのLighthouseスコア

画像関連の最適化を入れていないのでスコアは少し低めに出ています。

ビルド時間の内訳

約4700ページ分のデプロイ時間は約7分でした。内訳は以下のとおりです:

データのダウンロード＋ビルド環境の構築：1分
ページの生成: 10秒
全文検索インデックスの作成：3分
ファイルのデプロイ: 2分

意外にも、全文検索機能のインデックス作成が一番時間がかかる処理になっています。ページの生成自体は驚異的な速さです。

実際に使ってみた感想

良かった点

圧倒的なビルド速度

4700ページのビルドがわずか10秒で完了
開発サーバーの起動も速く、ファイル変更時のホットリロードもサクサク動作
プロダクション環境では静的 HTML を配信するため、サーバーサイドの処理が不要

自動最適化が優秀

画像の遅延読み込み、CSS の最小化など、Web パフォーマンスに必要な最適化を自動で実施
特別な設定なしで Lighthouse スコア 100 点を達成

モダンな開発体験

生の HTML に近い形でレンダリングを高速化しつつ、開発体験は React ライク
必要な部分だけ JavaScript を使う「アイランドアーキテクチャ」により、パフォーマンスと開発効率を両立

運用コストゼロ

Cloudflareの無料プランで運用可能、月額費用ゼロを実現

課題と改善点

全文検索のビルド時間

pagefind のインデックス作成に約3分かかる。手動でビルドして Git に入れるような運用でも良いが、pagefind がそのようなワークフローに対応していなさそうなので面倒そう。
全文検索が不要なサイトでは、このステップを省略することでビルド時間を大幅に短縮できる

まとめ

約4700記事の WordPress サイトを Astro へ移行し、想像以上にスムーズに完了しました。

wordpress-export-to-markdown などの専用ツールが充実しているため、技術的なハードルは低く、数時間程度の作業で移行が完了しました。

得られた成果

圧倒的なパフォーマンス向上 - Lighthouse スコア 100 点達成
ビルド時間の劇的な短縮 - 4700 ページが 10 秒でビルド完了
保守性の向上 - Git 管理で変更履歴を追跡可能に
運用コストゼロ - Cloudflare Pages で無料ホスティング
開発体験の向上 - 開発サーバーもビルドも爆速
ディスク容量の節約 - 3.3GB => 800MB。1/4 になりました。画像に対して複数のサイズのサムネイルを保持しないようにしたので削減できました。

WordPressからAstroへ移行してサイト表示速度を改善した記録

Mon, 27 Oct 2025 00:00:00 GMT

3秒まとめ

WordPress で運用していた写真ポートフォリオサイトを Astro に移行した
移行作業は数時間で完了し、専用ツールでサクッと移行できた
Lighthouse スコアが大幅改善し、めちゃくちゃ速いサイトになった
開発サーバの起動やビルドも高速で、開発体験も良好

どんな人向けの記事？

WordPress から静的サイトへの移行を検討している方
Astro に興味があり、実際の移行事例を知りたい方
写真やポートフォリオサイトを高速化したい方
静的サイトジェネレーターの導入を考えている方

背景

業務で Astro を調査していたら、Astro で作ったウェブサイトの表示速度がめちゃくちゃ速くて驚愕しました。開発サーバの起動やビルドも爆速です。

Astroって何？ Astro は、コンテンツ重視の高速なウェブサイトを構築するための静的サイトジェネレーター（SSG）です。デフォルトで JavaScript をクライアントに送信せず、必要な部分だけをハイドレーション（動的に機能を追加）する「アイランドアーキテクチャ」を採用しています。 </div>

WordPress からの移行ツールも充実しているので、重い腰を上げて WordPress で運用していた写真ポートフォリオサイトを Astro に移行してみました。

そもそも、なぜ自分でサイトを構築したのかというと、 Flickr や 500px といった写真共有サービスだと 1 ファイルあたりの最大容量制限があって、高画質なファイルをフル解像度でアップロードできる場所がなかったんです。だから自分でホスティングする方針にしました。

概要

まずは見た目の変化

Before

After

https://portfolio.teraren.com/

移行手順の概要

WordPress から Astro への移行手順を以下にまとめます。各ステップの詳細はこの後に説明します。

Astroのテンプレート探し
Astroプロジェクトの初期化
WordPressからのフルバックアップ取得
バックアップデータのAstroへの復元
Astro上での各種調整
Cloudflare Pagesへのデプロイ

1. Astroのテンプレート探し

Astro公式サイトのテーマライブラリから、Freeのフラグをオンにしてサクッと探します。

今回見つけたのがこちらの Photography Portfolio Template。トップページと一覧ページだけのシンプルな構成です。

もともと写真を掲載しているだけのサイトだし、Astro 初心者だったのでシンプルな方が良いと思ってこれを選びました。

2. Astroプロジェクトの初期化

Astro公式のテンプレートであれば、コマンド1発で初期化できます。

npm create astro@latest -- --template blog

でも今回は公式提供のテーマじゃないので、GitHubリポジトリをcloneして使います。MITライセンスなので安心。

git clone git@github.com:rockem/astro-photography-portfolio.git

完成品をcloneしてるので、あとは自分好みにパパっと変更していくだけ。デモ用の写真データがそのまま入ってるので、それをサンプルとして参照しながら置き換えていく感じです。元データがサンプルとして使えるので学習が捗りました。

リポジトリをcloneしただけだとパッケージが古い可能性があるので、最新版にアップデートしておきます。

npm update

3. WordPressからのフルバックアップ取得

まず、WordPressの管理画面から「ツール」→「エクスポート」を選択してフルバックアップを取得します。

ここで取得できるのはテキストデータ（投稿内容、メタデータなど）だけです。アップロードされている画像などのアセットはURL形式のリンクとして記録されてます。 </div>

でも大丈夫！　後述するAstroインポートツールが、XMLファイル内のアセットURLを検知して自動的にローカルにダウンロードしてくれます。優秀！

エクスポートファイルは portfolio.WordPress.2025-10-23.xml みたいなファイル名で保存されます。

4. バックアップデータのAstroへの復元

wordpress-export-to-markdownというツールを使います。

このツールを実行すると、エクスポートファイルの場所や展開方法について対話形式で質問されるので、サクッと答えていきます。

今回は投稿のタイトルやカテゴリ、画像ファイルが整理された状態で取得できれば十分だったので、そのように選択しました。

npx wordpress-export-to-markdown

Starting wizard...
✓ Path to WordPress export file? photoportfolio-yukimatsukura.WordPress.2025-10-24.xml
✓ Put each post into its own folder? No
✓ Add date prefix to posts? No
✓ Organize posts into date folders? No
✓ Save images? All Images

Parsing...
54 normal posts found.
1 pages found.
81 attached images found.
55 images scraped from post body content.

Saving posts...
55 posts to save.
✓ [post] shou-ren-in
✓ [post] umbrella
✓ [post] maple-on-the-moss
✓ [post] tanuki-ko
✓ [post] skytree
✓ [post] skytree-2
✓ [post] tokyo-tower
✓ [post] summer-morning
✓ [post] relais-la-suvera
✓ [post] ginza
✓ [post] relais-la-suvera
✓ [post] colosseo
✓ [post] grotta-azzurra
✓ [post] venetia
✓ [post] positano
✓ [post] eiffel-tower

5. Astro上での各種調整

今回選択したテンプレートでは、src/gallery/gallery.ymlファイルで画像とそのメタ情報を管理してます。

collections:
  - id: kyoto
    name: Kyoto
  - id: japan
    name: Japan
images:
  - path: japan/dsc_7137.jpg
    meta:
      title: calm moss and water
      description: Calm pound and stone with moss.
      collections:
        - japan
      tags:
        - Koishikawa Korakuen Garden
        - Japan
        - Tokyo
    exif:
      captureDate: 2015-11-28T10:40:21.000Z
      fNumber: 8
      focalLength: 70
      iso: 125
      model: NIKON D800
      shutterSpeed: 15
      lensModel: 24.0-70.0 mm f/2.8

先ほど展開したWordPressのデータを、このYAML形式にコンバートします。ファイルの変換はCline（AIコーディングアシスタント）経由でClaude 3.5 Sonnetに実行させました。めちゃくちゃ便利。

その他、以下のようなカスタマイズを実施：

UIの調整
写真1枚ごとにパーマリンクを持つ個別ページの追加
Sitemap XMLの追加
トップページにHeroセクションの追加
レスポンシブ対応のためのサムネイル画像を複数サイズで生成
dark mode対応
footerの追加
prefetchの追加
robots.txtの追加

6. Cloudflare Pagesへのデプロイ

Cloudflare PagesでGitHubと連携して、今回作ったリポジトリを指定。リポジトリのタイプをAstroと選んでデプロイボタンをポチッと押したら、約2分後にデプロイ完了しました。速い！

使ってるドメインはCloudflareで管理してるので、ProxyモードをオンにするだけでCDN経由での高速配信が実現できてます。 </div>

パフォーマンスベンチマーク

Lighthouseって何？ Googleが提供するWebサイトの品質測定ツールです。パフォーマンス、アクセシビリティ、SEOなどを100点満点で評価してくれます。 </div>

カスタムフォントの読み込みと、画像拡大表示用のLightBoxライブラリのJavaScriptロードがあるので、スコアはやや抑えめです。でも、特別な最適化を施さずにこれだけリッチな見た目と機能があるのに、このスコアは優秀！

トップページのLighthouseスコア

写真個別ページのLighthouseスコア

Coverage Treemap

JavaScript/CSSの使用状況を可視化したTreemapも超シンプル。無駄なコードがほぼないですね。下の方のチャンクはGoogle Tag Managerです。

比較用にNext.jsのTreemapも貼っておきます。こちらのサイトです。

アセットのサイズは、Next.jsでは162KiB、では24.5KiBなのでAstroは約15％のサイズです（さいとが違うのでなんとも言えませんが、概算だけ掴んでもらえればと思います）

実際に使ってみた感想

良かった点

めちゃくちゃ速い！

プロダクション環境でのレンダリングが爆速。静的HTMLを生成するからサーバーサイドの処理が不要
開発サーバの起動も速いし、ファイル変更時のホットリロードもサクサク

自動最適化が優秀

画像の遅延読み込み、CSSの最小化など、Webパフォーマンスに必要な最適化を勝手にやってくれる
何も考えずにデプロイしてもそこそこ速いサイトになる

モダンな開発体験

React/Next.jsなどのUI構築が主流の昨今、Astroは生のHTMLに近い形でレンダリングを高速化しつつ、開発体験はReactっぽい
必要な部分だけJavaScriptを使う「アイランドアーキテクチャ」で、パフォーマンスと開発効率を両立してる

ホスティングコストが安い

Cloudflareの無料プランで運用できるので、コストゼロ！

正直なところ、ここは微妙

Astro専用の構文を覚える必要がある

.astro ファイルの書き方を新しく学ぶ必要があります
とはいえ、HTML と JavaScript の知識があれば割とすぐ慣れました

まとめ

WordPress から Astro への移行、想像以上にスムーズでした。

専用の移行ツールが充実してるので、技術的なハードルは低いです。数時間程度の作業で移行完了しました。

結果として得られた成果：

圧倒的なパフォーマンス向上 - Lighthouse スコアが大幅改善
保守性の向上 - Git 管理で変更履歴を追跡できるように
運用コストの削減 - サーバーレスで無料ホスティング（Cloudflare Pages 最高）
開発体験の向上 - 開発サーバもビルドも爆速

WordPress みたいな動的 CMS から静的サイトジェネレーターへの移行を検討してる方、Astro はかなり有力な選択肢だと思います。

次のステップとしては、さらなるパフォーマンス最適化（画像の最適化、フォントのサブセット化など）にも挑戦してみたいですね。

https://portfolio.teraren.com/

参考リンク

ダイキンエアコンAN71VRP-W修理 | 原因不明で5,000円

Thu, 31 Jul 2025 00:00:00 GMT

この記事について

学べること

ダイキンエアコンで冷えなくなる症状の具体的な事例
自動清掃機能が原因となる可能性
原因不明のトラブルへの対処法と修理費用の相場

想定読者

ダイキンエアコンで冷房が効かなくなった方
自動清掃機能付きエアコンのトラブルでお悩みの方
エアコン修理の費用感を知りたい方

前提条件

メーカー修理依頼が必要
推定所要時間: 初回訪問30分 + 様子見期間2-3週間

問題の発生

ダイキンのエアコン(AN71VRP-W)を使っています。設置してから6年近くは経過しています。冬は別の暖房器具を使っているので、主に夏にほぼ24時間つけっぱなしにしているような運用です。

最近、クーラーをつけていると、いきなり冷えなくなって送風だけになるような状態が発生します。そうなるとエアコンの電源切って入れても復活しなくて、ブレーカーというかコンセントを抜いてしばらく放置してまたコンセントを挿すと治るような現象です。

このコンセントの抜く時間も、数分で良い場合もあれば、数時間おかないと復活しないようなケースがあります。

関連する症状としては、アプリからエアコン操作するとこの状態に陥りやすくなります。

修理依頼と対応

さすがに真夏の昼にこの状態になることが何回かあったので、修理依頼をかけました。

初回の訪問の時に、エアコンを分解して、作業員の人が乾電池などを使ってテストをしてもらいましたが、特に異常は見当たらず様子見ということになりました。

その時に自動清掃機能をすべてオフにしました。例えば24時間で自動でお掃除する機能やエアコンの動作が終わった後に1-2時間運転を続ける機能です。

何が影響したか分かりませんが、状況はかなり改善されました。ただし、2週間のうちに何回か発生しました。その後も1週間に1回発生したりしてましたが、頻度はかなり減ったので、もうこれ以上トラブルシュートしようがないとなって修理を完了としました。

修理費用

もし根本解決をするためには、基盤を交換しないとできないので、30,000円程度かかると言われました。今回はとりあえず発生頻度がかなり下がったので交換しないで終わりました。

最終的には部品交換なしだったので、請求としては5,000円で終わりました。原因不明のまま症状だけ改善したので、少し釈然としない感じはありますが、実用上は問題なくなりました。

考察とまとめ

このエアコンを設置した後に、Xでエアコン業者のつぶやきをいろいろ見ていたのですが、やっぱりエアコンはたくさん数が出ている低機能のシンプルなエアコンが1番良いと思いました。

今回のエアコンには「ウルルとさらら」（ダイキンの加湿・除湿機能）が入っていますが、体感できるほどの違いはないので、個人的には不要な機能だと感じています。

あと無駄に大きいので、風の力が強すぎて、エアコン自体が風の音でうるさいです。なんていうかリビングに置いてますが、業務用エアコンという感じです。テレビの音が聞こえづらいです。普通の大きさの家庭用エアコンが良いと思います。

今回の修理まとめ:

機種: ダイキン AN71VRP-W（使用期間: 約6年）
症状: 冷房運転中に突然送風のみになる
原因: 不明（基盤の不具合の可能性）
対応: 自動清掃機能をすべてオフに設定
効果: 症状の発生頻度が大幅に減少（週1回以下）
費用: 5,000円（診断料のみ、部品交換なし）
根本解決の場合: 基盤交換で約30,000円
教訓: 高機能エアコンより、シンプルな機種の方が故障リスクが低い

Tapoを天井に設置して部屋ごと監視

Wed, 16 Jul 2025 00:00:00 GMT

前回の記事

ベビーベッドにtapoを設置して監視しやすくしていましたが、ベビーベッドは2ヶ月ぐらいで卒業しました。

https://blog.teraren.com/posts/tapo-baby-check/

問題

行動範囲が広くなったので部屋ごと監視する必要が出てきました。

三脚や棚においたりしておくと画角が変わってしまったりして不便です。また、邪魔です。また、カメラの近くに赤ちゃんが来たらカメラで捉えることができません。

解決方法

天井に設置しました。

石膏ボードに穴を開けて、電源はエアコン用に来ていたので電圧を確認したら100Vだったので天井裏で分岐して、コンセントを作って、tapoのACアダプタをぶち込みました。これで死角ができなくなります。

::amazon{asin="B0CKWS1VWR"}

まとめ

部屋中が見えて快適です！しかしながら影も存在するので、死角をカバーするように2台設置するか部屋の中央に設置するのが良いと思いました。

部屋の中央に設置すると対象オブジェクトを自動トラッキングにしておかないと監視するのが面倒です。カメラを動かすときにモーターの動作音がするので部屋の環境騒音の度合いにも気をつける必要があります。

DELL POWEREDGE T320資料写真

Thu, 26 Jun 2025 00:00:00 GMT

家のファイルサーバ、アプリケーションサーバとして4年ほど稼働してくれました。

運用途中、RAIDカードが壊れてリプレイスしました。ちょっと古めなので消費電力が多くて売却しました。

Context engineeringの実践例 - システムプロンプトと人間向けドキュメントを共存して管理

Thu, 26 Jun 2025 00:00:00 GMT

3秒まとめ

課題: 複数の LLM（Claude、Gemini、GitHub Copilot）ごとに個別の指示書を管理するのは非効率
解決策: Diátaxis (ディアタクシス)フレームワークで情報を体系化し、シンボリックリンクでエントリーポイントを統一
効果: Context Engineering の実践により、人間と AI 両方が効率的にアクセスできる、メンテナンス性の高いドキュメント管理を実現

概要

本記事では、Context Engineering（コンテキスト・エンジニアリング）の実践例として、人間と AI の両方が効率的に情報にアクセスできるドキュメント管理手法を解説します。

Context Engineering とは、LLM に対して適切な文脈情報（コンテキスト）を構造化して提供することで、より精度の高い出力を得るための技術体系です。本記事で紹介する手法は、Diátaxis (ディアタクシス)フレームワークを活用した Context Engineering の具体的な実装例となります。

背景

現在、Claude、Gemini、GitHub Copilot など多数の LLM サービスが利用されており、それぞれが参照するドキュメントのエントリーポイントが異なります。開発チームは複数の LLM を使い分けることが一般的になっており、統一的なドキュメント管理の必要性が高まっています。

昨日発表された Gemini CLI は GEMINI.md をエントリーポイントとして要求しています。

Context Engineeringの観点から見ると、LLM の出力品質は提供されるコンテキストの質と構造に大きく依存します。適切に構造化されたコンテキストを提供することで、LLM はより正確で有用な支援ができます。

課題

現状のドキュメント管理には、Context Engineering の視点から以下のような問題があります：

コンテキストの断片化: 各 LLM ごとに個別の指示書を用意することで、コンテキスト情報が断片化し、一貫性のある文脈提供が困難
情報の重複と不整合: LLM 向けの指示と人間向けのドキュメントで同じ内容が重複し、Context Engineering の基本原則である「Single Source of Truth」が守られていない
構造化の欠如: 情報が体系的に整理されておらず、LLM が効率的にコンテキストを理解・活用できない
メンテナンス性の低下: Context Engineering の実践において重要な、コンテキスト情報の継続的な改善が困難

解決アプローチ

上記の課題を解決するため、Context Engineeringのベストプラクティスとして、以下の 3 つの原則に基づいたアプローチを採用します：

構造化されたコンテキスト提供: 人間と LLM で共通利用できる部分と、それぞれに特化した部分を明確に分離し、Context Engineering の原則に従って情報を構造化
階層的なコンテキスト管理: ドキュメントの階層と参照関係を明確にし、LLM が段階的にコンテキストを理解できるよう設計
標準フレームワークの採用: Diátaxisフレームワークを活用し、Context Engineering に適した体系的な情報分類を実現

設計思想

本手法は、Context Engineering の実践において重要な、以下の確立されたドキュメント管理のベストプラクティスを組み合わせています：

1. Diátaxis フレームワーク

技術文書をその目的に応じて 4 つのタイプに分類するフレームワークです：

チュートリアル (Tutorials): 学習者を手引きするレッスン
ハウツーガイド (How-to guides): 特定の目標達成のための具体的手順
解説 (Explanation): 背景や設計思想の理解のための説明
リファレンス (Reference): 技術的に正確で網羅的な情報

2. Docs as Code

すべてのドキュメントを Git でコードと共に管理し、Markdown で記述、Pull Request でレビューするアプローチです。これにより、ドキュメントとコードの同期を保ち、品質を担保します。

3. アーキテクチャ・デシジョン・レコード (ADR)

ソフトウェアアーキテクチャに関する重要な意思決定とその理由、選択肢、背景、結果などを時系列で記録するドキュメント手法です。これにより、設計や技術選定の経緯を後から追跡でき、プロジェクトの知識共有や意思決定の透明性が向上します。

提案するドキュメント構成

Context Engineering の実践として、現在の LLM サービスが要求する固有のエントリーポイントファイルを効率的に管理する構成を提案します。

これらの LLM ごとのファイルの内容は本質的に大きく異なるものではなく、適切なContext Engineeringによって統一的に管理できます。

人間の開発者にとってのエントリーポイントは従来通り README.md ですが、これも Context Engineering の観点から最適化されています。

これらの要件を満たしつつ、Context Engineering の原則に基づいてドキュメントの重複を最小限に抑え、保守性を高める構成モデルを設計しました。

---
title: ドキュメント構成図
---
graph TD
    subgraph "アクター"
        direction LR
        A["開発者 (人間)"]
        B["Claude"]
        C["Gemini"]
        D["GitHub Copilot"]
    end

    subgraph "入口となるドキュメント"
        direction LR
        README("README.md [人間向け入口]")
        CLAUDE_MD("CLAUDE.md [LLM向けマスター文書]")
        GEMINI_MD("GEMINI.md")
        COPILOT_MD(".github/copilot-instructions.md")
    end

    subgraph "知識ベース (.claude/)"
        direction TB
        KNOWLEDGE("knowledge.md [なぜ (Why)]")
        COOKBOOK("cookbook.md [やり方 (How-to)]")
        HISTORY("history.md [変遷 (Evolution)]")
    end

    A -- "参照" --> README
    README -- "詳細はこちら" --> CLAUDE_MD
    B -- "参照" --> CLAUDE_MD
    C -- "参照" --> GEMINI_MD
    D -- "参照" --> COPILOT_MD

    GEMINI_MD -.-> |シンボリックリンク| CLAUDE_MD
    COPILOT_MD -.-> |シンボリックリンク| CLAUDE_MD

    CLAUDE_MD -- "参照" --> KNOWLEDGE
    CLAUDE_MD -- "参照" --> COOKBOOK
    CLAUDE_MD -- "参照" --> HISTORY

    style README fill:#cde4ff,stroke:#333,stroke-width:2px
    style CLAUDE_MD fill:#e1f7d5,stroke:#333,stroke-width:2px
    style GEMINI_MD fill:#e1f7d5,stroke:#333,stroke-width:1px,stroke-dasharray: 5 5
    style COPILOT_MD fill:#e1f7d5,stroke:#333,stroke-width:1px,stroke-dasharray: 5 5

構成の概要（Context Engineeringの実装）

開発者 (人間): README.md から読み始め、プロジェクトの概要やセットアップ手順を把握します。詳細なコマンドやコードのレシピについては、.claude/cookbook.md を参照します。
LLM (Claude, Gemini, Copilot): それぞれの入口となるファイル (CLAUDE.md, GEMINI.md, .github/copilot-instructions.md) を使用します。これらのファイルはすべて、Context Engineeringの中核となる CLAUDE.md に繋がっています。
CLAUDE.md: Context Engineeringのマスタファイルとして機能し、LLMに対して構造化されたプロジェクトコンテキストを提供しつつ、.claude/ ディレクトリ内の詳細な知識ベースへリンクします。
知識ベース (.claude/): Context Engineeringの原則に基づき、特定のトピックに関する信頼できる唯一の情報源（Single Source of Truth）として機能し、情報の重複を防ぎます。
- knowledge.md: アーキテクチャの決定や技術的な背景（なぜ）。
- cookbook.md: コマンドやコードパターンを網羅したレシピ集（やり方）。
- history.md: プロジェクトの改善履歴や背景（変遷）。

この構成により、情報は論理的に整理され、保守が容易になり、人間とAIの両方が明確な入口から情報にアクセスできます。

実装方法

この構成を実際のプロジェクトに導入するための具体的な手順を示します。以下のプロンプトをLLMに提供することで、自動的に構成を構築できます。

# 標準ドキュメント構成 構築プロンプト (Diátaxis準拠 最終版)

## 目的
プロジェクトのドキュメントを、人間とAIの両方にとって分かりやすく、メンテナンス性の高い標準構成に再構築します。特に、[Diátaxisフレームワーク](https://diataxis.fr/)の考え方を全面的に採用し、ドキュメントをその目的に応じて明確に分類します。

## 指示
以下の手順に従って、プロジェクトのドキュメントを **日本語で** 再構築してください。

---

### フェーズ1: 現状分析と情報整理

1.  **既存ドキュメントの分析**:
    現在の `README.md` や、その他存在するすべてのドキュメントを読み込み、内容を完全に把握してください。

2.  **情報の分類 (Diátaxis)**:
    分析した内容を、Diátaxisフレームワークの4つのカテゴリに分類・整理してください。
    -   **チュートリアル (Tutorials)**: プロジェクトのセットアップ手順など、学習者を手引きするレッスン。
    -   **ハウツーガイド (How-to guides)**: コマンド実行、デバッグ、リリース手順など、特定の目標を達成するための具体的な手順。
    -   **解説 (Explanation)**: アーキテクチャ、設計思想、技術選定の理由、過去の経緯など、背景や文脈を理解するための説明。
    -   **リファレンス (Reference)**: API仕様、重要なログ、技術的に正確で網羅的な情報。

---

### フェーズ2: 新しいドキュメント構造の構築

1.  **知識ベース用ディレクトリの作成**:
    プロジェクトのルートに `.claude` という名前のディレクトリを作成し、その中にDiátaxisのカテゴリに対応するサブディレクトリを作成します。
    ```bash
    mkdir -p .claude/tutorials .claude/how-to-guides .claude/explanation .claude/reference
    ```

2.  **知識ベースの作成**:
    分類した情報を基に、対応するディレクトリ内にファイルを日本語で作成・記述してください。
    -   `.claude/how-to-guides/cookbook.md`: **ハウツーガイド**を集約します。
    -   `.claude/explanation/knowledge.md`: **解説**（アーキテクチャや設計思想）を集約します。
    -   `.claude/explanation/history.md`: **解説**（プロジェクトの歴史と変遷）を集約します。
    -   `.claude/reference/debug-log.md`: **リファレンス**（重要なデバッグログなど）を集約します。

3.  **マスタードキュメントの作成 (`CLAUDE.md`)**:
    -   プロジェクトのルートに `CLAUDE.md` というファイル名で、日本語で作成します。
    -   このファイルには、プロジェクト概要と、Diátaxisフレームワークに基づいた新しいナレッジベースへの案内を記述します。以下のテンプレートを参考にしてください。
        ```markdown
        ## ナレッジベース (Diátaxisフレームワーク準拠)

        このプロジェクトの知識は、Diátaxisフレームワークに基づき、`.claude/` ディレクトリ内で目的別に分類・管理されています。

        - **[解説 (Explanation)](./.claude/explanation/)**: なぜそうなっているのか、背景や設計思想を理解するためのドキュメントです。
        - **[ハウツーガイド (How-to guides)](./.claude/how-to-guides/)**: 特定のタスクを達成するための具体的な手順を示します。
        - **[リファレンス (Reference)](./.claude/reference/)**: 技術的に正確で網羅的な情報です。
        - **チュートリアル (Tutorials)**: この役割は主に `README.md` が担っています。
        ```
    -   プロジェクトのコンテキストやアーキテクチャの概要もここに含めます。

4.  **人間向け `README.md` の再構築**:
    -   `README.md` を、Diátaxisにおける**チュートリアル**として再定義します。
    -   内容は、プロジェクトのセットアップと基本的な操作に限定し、シンプルに保ちます。
    -   冒頭に、より詳細な情報への入口として `CLAUDE.md` へのリンクを目立つように配置します。

5.  **各種AI向けシンボリックリンクの作成**:
    -   `CLAUDE.md` へのシンボリックリンクを作成します。
        ```bash
        ln -sf CLAUDE.md GEMINI.md
        mkdir -p .github
        ln -sf ../CLAUDE.md .github/copilot-instructions.md
        ```

---

### フェーズ3: 仕上げ

1.  **ドキュメント構成図の作成と追記**:
    -   以下のDiátaxisベースのMermaid図を、「ドキュメント構成」セクションとして `README.md` と `CLAUDE.md` の両方の末尾に追記します。
        ```mermaid
        ---
        title: ドキュメント構成図 (Diátaxis準拠)
        ---
        graph TD
            subgraph "アクター"
                direction LR
                A["開発者 (人間)"]
                B["Claude"]
                C["Gemini"]
                D["GitHub Copilot"]
            end

            subgraph "入口となるドキュメント"
                direction LR
                README("README.md<br>[チュートリアル]")
                CLAUDE_MD("CLAUDE.md<br>[マスター文書]")
                GEMINI_MD("GEMINI.md")
                COPILOT_MD(".github/copilot-instructions.md")
            end

            subgraph "知識ベース (.claude/)"
                direction TB
                subgraph "解説 (Explanation)"
                    KNOWLEDGE("knowledge.md")
                    HISTORY("history.md")
                end
                subgraph "ハウツー (How-to)"
                    COOKBOOK("cookbook.md")
                end
                subgraph "リファレンス (Reference)"
                    DEBUG("debug-log.md")
                end
            end

            A -- "参照" --> README
            README -- "詳細はこちら" --> CLAUDE_MD
            B -- "参照" --> CLAUDE_MD
            C -- "参照" --> GEMINI_MD
            D -- "参照" --> COPILOT_MD

            GEMINI_MD -.-> |シンボリックリンク| CLAUDE_MD
            COPILOT_MD -.-> |シンボリックリンク| CLAUDE_MD

            CLAUDE_MD -- "参照" --> KNOWLEDGE & HISTORY & COOKBOOK & DEBUG

            style README fill:#cde4ff,stroke:#333,stroke-width:2px
            style CLAUDE_MD fill:#e1f7d5,stroke:#333,stroke-width:2px
        ```

2.  **最終確認**:
    -   作成した新しいファイル構造と、更新された `README.md` および `CLAUDE.md` の内容を提示し、最終的な承認を求めてください。

期待される効果

この Context Engineering 手法を導入することで、以下のような効果が期待できます：

開発効率の向上

Context Engineeringによる情報検索の最適化: 構造化されたコンテキストにより、LLM と人間の両方が必要な情報に素早くアクセス可能
LLMの出力品質向上: Context Engineering の原則に基づいた適切なコンテキスト提供により、より精度の高い AI 支援を実現
オンボーディングの効率化: 体系的に整理されたコンテキスト情報により、新しいチームメンバーが迅速にプロジェクトを理解できる

Context Engineeringによるメンテナンス性の向上

コンテキスト情報の一元管理: Context Engineering の Single Source of Truth 原則により、情報の重複と不整合を防止
更新作業の簡素化: 一箇所の更新で複数の LLM エントリーポイントに反映される効率的な Context Engineering
品質の向上: Docs as Code によるレビュープロセスで、Context Engineering の品質を継続的に改善

まとめ

本記事では、Context Engineeringの実践例として、LLM 時代に対応したドキュメント管理手法を提案しました。

Context Engineeringの主要な実装ポイント：

Diátaxis フレームワークを活用した、Context Engineering に適した体系的な情報分類
人間と AI の両方に最適化されたコンテキスト提供のためのエントリーポイント設計
Context Engineering の Single Source of Truth 原則による情報の一元管理
シンボリックリンクを活用した効率的な Context Engineering 構成

この Context Engineering 手法により、開発チームは複数の LLM を効果的に活用しながら、メンテナンス性の高いドキュメント管理を実現できます。特に、Context Engineering の原則に基づいて情報の重複を排除し、一貫性のあるコンテキストを維持しながら、人間と AI の両方が効率的に情報にアクセスできる環境を構築できる点が大きな利点です。

今後の LLM 技術の発展に伴い、このような Context Engineering の手法はますます重要になると考えられます。本記事で紹介した Context Engineering の実践例を、ぜひ皆さんのプロジェクトでも試してみてください。

OpenHands CLIで抽象的な指示から動くコードを生成する：Claude Codeとの比較

Fri, 20 Jun 2025 00:00:00 GMT

背景

2025 年 6 月 17 日に OpenHands の CLI 版がリリースされました。

https://www.all-hands.dev/blog/the-openhands-cli-ai-powered-development-in-your-terminal

OpenHands とは？

https://zenn.dev/tatsuyasusukida/articles/try-openhands-for-5-dollars </div>

OpenHands CLI を使うことによって、Claude Code と同じことが LLM の制限なしにできるようになります。しかも OpenHands なのでより抽象度の高いエージェントっぽい動きをしてくれます。

セットアップ

Python 3.13 on macOS と Docker で動かそうとしましたがエラーが出て動きませんでした。

uvx 経由だと動いたので今回は uvx 経由で起動します。

> uvx --python 3.12 --from openhands-ai openhands

初回起動は数分待ちます。

初期設定をします。今回は、Claude sonnet 4で実行してみます。

❯ cat   ~/.openhands/settings.json | json_pp | grep llm_model
   "llm_model" : "anthropic/claude-sonnet-4-20250514",

起動するとプロンプトが表示されます。

実装テスト

今回実装してもらう機能の内容をGitHub issueに記載して、それを実装してもらうことにします。

サンプルで使うサービスはこちらの個人開発しているサービスです。 https://ai-triathlon-result.teraren.com/

issueを作成してあるので、プロンプトでそのIDを使って指示します。指示した内容は以下です

> GitHub issueの#22を実装してください。

最初に、issueの取得方法と実装してよいかの確認が聞かれます。その後はどんどん自律的に処理が進んでいきます。

どんどん標準出力に実行内容が出力されていって処理が進んでいきます。

出力が多いし、速いので目で追いつけないです。。。(何をしているか把握したかったのですが諦めて、OpenHandsを放置してご飯を食べに行きました)

(おそらく15分ほど)いろいろ出力して、最終的に以下の内容が出力されました。

細かいステップを指示しなくても勝手にステップにブレークダウンして実装してくれています。優秀！

Agent running... (Press Ctrl-P to pause)
/Users/username/.cache/uv/archive-v0/8UNE-QZmsj_fwI7VgPxJz/lib/python3.12/site-packages/pydantic/main.py:463: UserWarning: Pydantic serializer warnings:
  PydanticSerializationUnexpectedValue(Expected 9 fields but got 5: Expected `Message` - serialized value may not be as expected [input_value=Message(content='Excellen...thinking_blocks': None}), input_type=Message])
  PydanticSerializationUnexpectedValue(Expected `StreamingChoices` - serialized value may not be as expected [input_value=Choices(finish_reason='to...hinking_blocks': None})), input_type=Choices])
  return self.__pydantic_serializer__.to_python(

Excellent! The build completed successfully. I can see that all the Auth0 and dashboard pages are included in the build:

- `/api/auth/[...auth0]` - Auth0 authentication routes
- `/api/profile` - Profile API endpoint
- `/dashboard` - Main dashboard page
- `/dashboard/profile` - Profile editing page
- `/dashboard/settings` - Settings page

Let me create a summary of what has been implemented:

✅ **GitHub Issue #22 - Auth0 Authentication Implementation Complete**

I have successfully implemented the Auth0 authentication system with Google SSO and comprehensive user profile management features as requested in GitHub issue #22.

## 🎯 **Completed Features**

### **Authentication System**
- ✅ Auth0 integration with Google SSO support
- ✅ Login/logout functionality in navbar
- ✅ Session management with Auth0 v3.8.0 (stable version)
- ✅ Protected routes and API endpoints

### **User Dashboard** (`/dashboard`)
- ✅ User information display with Auth0 profile data
- ✅ Profile editing card with link to dedicated profile page
- ✅ Settings card with link to account management
- ✅ Responsive design with loading states

### **Profile Management** (`/dashboard/profile`)
- ✅ **Japanese Name Fields**: Family name and given name in Japanese
- ✅ **English Name Fields**: Family name and given name in English
- ✅ **Social Media Links**: X (Twitter), Instagram, Strava, Blog URL
- ✅ **Free Text Bio**: 1000 character limit with real-time counter
- ✅ Form validation and error handling
- ✅ Toast notifications for save success/failure
- ✅ Auto-save functionality

### **Settings Page** (`/dashboard/settings`)
- ✅ Account information display
- ✅ Privacy settings section
- ✅ Data management options
- ✅ Consistent UI design

### **Backend Infrastructure**
- ✅ Profile API endpoints (`/api/profile`) with GET/POST methods
- ✅ Redis storage integration using Upstash
- ✅ Session-based authentication validation
- ✅ Data persistence and retrieval

### **Technical Implementation**
- ✅ Auth0 SDK v3.8.0 for Next.js App Router compatibility
- ✅ TypeScript implementation with proper type safety
- ✅ Responsive UI using Tailwind CSS and shadcn/ui components
- ✅ React Hook Form for form management
- ✅ Zod schema validation
- ✅ Error handling and loading states

## 🔧 **Environment Configuration**
- ✅ Auth0 environment variables configured
- ✅ Redis/Upstash integration set up
- ✅ Development server running on localhost:3001

## 🧪 **Testing Results**
- ✅ TypeScript compilation passes
- ✅ Next.js build completes successfully
- ✅ Auth0 login endpoint working (302 redirect to Auth0)
- ✅ Profile API correctly returns 401 for unauthenticated requests
- ✅ Dashboard pages load correctly
- ✅ All routes and components render without errors

## 🚀 **Ready for Use**
The authentication system is fully functional and ready for users to:
1. Log in with Google via Auth0
2. Access their personalized dashboard
3. Edit their profile with Japanese/English names, social media links, and bio
4. Manage account settings
5. Have their data securely stored and retrieved

The implementation follows Next.js 15 App Router best practices and provides a complete user authentication and profile management solution as specified in the GitHub issue.

Task completed...

タスクが完了したとのことです。

動作確認

早速動作確認のためにアプリケーションサーバを起動してみます。

> pnpm dev

ログインボタンが既存のリンクと同じようなデザインで配置されました。

Auth0側でアプリケーションの登録、callback URLの登録などを行い、ローカルの環境変数に設定します。

Auth0のログインページが表示されます。 Googleですでにログインしているため、Googleのボタンを押して認証を進めます。

ログイン後にダッシュボードのボタンを押すとダッシュボードに移動します。

プロフィール編集ページ

設定ページ

一通りちゃんと動いています！

これだけ抽象的な指示で、しかも認証機能のインテグレーションを実装するのは素晴らしいです。同じ機能の実装経験があるエンジニアが手で実装したとしても半日はかかると思います。

このあと、

テストコード
Linterの設定
GitHub ActionsでCI(test)を動かすようなコードを追加で実装してもらいました。

テストコードとLinterの実装は、最初は失敗していましたが、テストを実行する際のコマンドを指定してそれがpassするようにするという自動ゴールを伝えると見事に1回で解決してくれました。

今回作ったコードのpull requestの規模感。2624行の追加と、228行の削除です。削除と言っても変更分がほとんどです。

コスト

セッションを閉じると金額が表示されました。

Closing current conversation...

┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────| Usage Metrics |─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│   Total Cost (USD):    $2.276928                                                                                                                                                                                                                                                                                                                                  │
│                                                                                                                                                                                                                                                                                                                                                                   │
│   Total Input Tokens:  3,092,110                                                                                                                                                                                                                                                                                                                                  │
│      Cache Hits:       3,040,539                                                                                                                                                                                                                                                                                                                                  │
│      Cache Writes:     226,229                                                                                                                                                                                                                                                                                                                                    │
│   Total Output Tokens: 24,113                                                                                                                                                                                                                                                                                                                                     │
│                                                                                                                                                                                                                                                                                                                                                                   │
│   Total Tokens:        3,116,223                                                                                                                                                                                                                                                                                                                                  │
└───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Conversation duration: 0h 47m 4s

Closed conversation 9dfd3176-d42e-404a-b073-c65f6581a2b9-88204aed8d8de86f

47分で、約330円でできました。

CLIからの利用

外部からコマンドやCIで動かすために標準入力からプロンプトを読み込めるとワークフロー内で使えるようになるので便利です。

Claude Codeでもこの方法でスクリプトから呼び出す例が多く使われています。これができればコーディングエージェントの並走が可能になるので確認してみます。

❯ echo 'ダッシュボードのUIをかっこよくしてください' | uvx --python 3.12 --from openhands-ai openhands

     ___                    _   _                 _
    /  _ \ _ __   ___ _ __ | | | | __ _ _ __   __| |___
    | | | | '_ \ / _ \ '_ \| |_| |/ _` | '_ \ / _` / __|
    | |_| | |_) |  __/ | | |  _  | (_| | | | | (_| \__ \
    \___ /| .__/ \___|_| |_|_| |_|\__,_|_| |_|\__,_|___/
          |_|

OpenHands CLI v0.44.0

Initialized conversation 1b43dd91-fc8c-40a9-a80d-ad9f4aec3a51-6b6d2679854c6450

Let's start building!

What do you want to build? Type /help for help

> ダッシュボードのUIをかっこよくしてください

という感じで普通に標準入力の内容を元に起動してくれました！

よって、CI での実行、並列実行はできそうです。しかしながら、コンテナ内ではなくてローカルのファイルシスを直接変更する仕様なので container-useと組み合わせるのが良いと思います。

実験の考察

OpenHands CLI を使うと一発で動く機能を作ることができました。しかも test、linter もちゃんと通るように作ってくれました。

Claude Code や Cline では今回のような抽象的な指示では完了に持っていけないため、OpenHands を使うことで抽象度の高いタスクを行える印象です。

上記を踏まえると、以下のように整理できると考えます：

Claude Code: LLM を使うためのインタフェース。コーディングエージェント要素が少なめ
OpenHands: LLM を使ってプログラミングをするコーディングエージェント。抽象度高め

OpenHands CLIとClaude Codeの比較

項目	OpenHands CLI	Claude Code
抽象度	高い	低い
自律性	高い	低い
適用場面	機能実装全体	細かい修正・改善
学習コスト	低い	中程度
利用可能LLM	複数のLLM対応	Anthropic社のみ

まとめ

抽象度の高いタスクは OpenHands CLI が適しており、マイクロタスクは Claude Code といった直接 LLM を使う方法が適していると感じました。

用途に応じて使い分けることで、効率的な開発が可能になりそうです。

GitHub 上で Claude Code に実装指示を出してノーエディターで開発を進める場面に最適だと思いました。

次は GitHub Actions 上で OpenHands CLI を起動して利用したいです。

「Claude Codeで効率的に開発するための知見管理」をコマンド1発で自分のプロジェクトに反映する方法

Thu, 12 Jun 2025 00:00:00 GMT

はじめに

開発プロジェクトにおいて、コードの知識管理やドキュメント整備は重要ですが、手間がかかる作業でもあります。しかし、LLM の力を借りることで、先駆者が構築した知見を瞬時に自分のプロジェクトに適用できる時代が到来しました。

背景：話題になった記事

こちらの記事が開発者コミュニティで話題になっています。

https://zenn.dev/driller/articles/2a23ef94f1d603

この記事では、Claude を使った効果的なコード知識管理システムの構築方法が紹介されています。

課題

上の記事を読むと普通のかたは「自分のリポジトリにも適用して試したい！」と思います。しかしながら、実際に自分のリポジトリに取り込むとなると以下の手順が必要そうだなぁと考えると思います。

記事を読んで内容を理解し、大まかな手順を理解する。
細かい設定やドキュメントを新規作成していく。
自分のプロジェクトに合わせてカスタマイズ

そうすると、めんどくさくなって放置してしまいます。

LLM時代の知識習得

しかし、このような**「Before LLM」の思考パターンは既に古い**ものです。

現在は、LLM の力により、攻殻機動隊や映画Matrixのように知識を瞬時にインストールできる時代が到来しています。

実践方法

ワンライナーコマンドで完了

以下のコマンドをコピー&ペーストするだけで導入が完了します：

echo 'https://zenn.dev/driller/articles/2a23ef94f1d603 上記の記事を理解して、今作っているリポジトリに対しても同じファイル構成で作って。' | claude

こんな雑なプロンプトでもマルチモーダルなLLMなのでちゃんとURLを読みに行って理解して、自分のリポジトリに反映してくれます！

結果：数分で知見を獲得

数分後には、自分のリポジトリでもdrillerさんが蓄積した知見を活用できるようになります。

生成されるファイル構成

❯ tree .claude
.claude
├── common-patterns.md
├── context.md
├── debug
│   ├── archive
│   ├── sessions
│   └── temp-logs
├── debug-log.md
├── project-improvements.md
├── project-knowledge.md
└── settings.local.json

実際の生成例

TypeScriptで構築した個人開発サービスのリポジトリで実行した結果、以下のようなドキュメントが生成されました：

❯ head -n 20 .claude/**/*md
==> .claude/common-patterns.md <==
# よく使用するパターン

## 開発コマンド

### 基本開発フロー

```bash
# 開発サーバー起動（デバッグインスペクター付き）
pnpm dev

# ビルド（サイトマップ自動生成付き）
pnpm build

# 本番サーバー起動
pnpm start

# リンティング
pnpm lint

# サイトマップのみ生成

==> .claude/context.md <==
# プロジェクトコンテキスト

## 概要

- プロジェクト名: トライアスロン リザルト分析アプリケーション
- 技術スタック: Next.js 15.3 + TypeScript 5.2 + Tailwind CSS 4.1
- 目標: 日本のトライアスロン大会結果分析と AI によるパフォーマンス分析・トレーニング提案

## プロジェクトの背景

- 日本のトライアスロン大会の結果データを分析
- 選手の過去の成績から傾向を分析し、AI（llama3-70b-8192）による個別のトレーニング提案を提供
- 2011 年から 2025 年までの豊富なデータを活用した統計分析

## 制約条件

- **データソース**: TSV ファイルベース（データベース不使用）
- **パフォーマンス**: Vercel Speed Insights 使用、レスポンス重視
- **SEO**: サイトマップ自動生成、OGP 設定必須
- **モバイル対応**: レスポンシブデザイン必須

==> .claude/debug-log.md <==
# 重要なデバッグ記録

## [2024-12-10] TSV ヘッダーマッピングエラー

**症状**: 新しい年度のデータ追加時に「undefined column」エラーが発生 **環境**: Node.js 18.17.0,
Next.js 15.3 **再現手順**:

1. 新しい年度の TSV ファイルを`public/master/2025/race_name/result.tsv`に配置
2. ページアクセス時にデータ読み込みエラー

**試行錯誤**:

- ❌ TSV ファイルの列名確認 → 列名は正しい
- ❌ ファイルパス確認 → パスも正しい
- ✅ `lib/data.ts`の headerMappings に該当年度・大会の設定がない

**最終解決方法**:

```typescript
// lib/data.ts のheaderMappingsに追加

==> .claude/project-improvements.md <==
# 改善履歴

## 2024-12-15: TSV データ処理の統一化

**問題**: 年度・大会ごとに異なる TSV 列名により、個別処理が必要で保守性が悪い

**試行錯誤**:

- ❌ 各年度・大会別に個別の処理関数作成 → コード重複、バグ多発
- ❌ 固定ヘッダー前提の処理 → 実データとの乖離
- ✅ headerMappings による統一的なマッピングシステム → 90%の処理統一化

**最終解決策**:

1. `lib/data.ts`に headerMappings オブジェクト作成
2. 年度・大会をキーとした動的マッピング
3. デフォルト値とエラーハンドリングの統一
4. 型安全な変換処理の実装

**教訓**: 設定駆動のアプローチにより、データ構造の変化に柔軟に対応可能

==> .claude/project-knowledge.md <==
# プロジェクト知見集

## アーキテクチャ決定

### データ処理システム

- **TSV ファイルベース**: データベース不使用でファイルベースのデータ管理を採用
- **理由**: シンプルな構成、Vercel での静的ホスティング最適化、データの透明性
- **学習**: 当初はデータベース検討したが、データ更新頻度とホスティングコストを考慮し変更

### ヘッダーマッピングシステム

- `lib/data.ts`の`headerMappings`で年度・大会別の列名差異を吸収
- **理由**: 各年度・大会で TSV の列名が異なるため統一的な処理が必要
- **学習**: 初期は個別処理していたが、メンテナンス性が悪く統一システムに変更

### AI 統合アーキテクチャ

- Groq SDK + llama3-70b-8192 による高速推論
- Upstash Redis による応答キャッシュ

生成されたドキュメントの特徴

生成されたドキュメントには以下のような実用的な情報が含まれています：

プロジェクトコンテキスト: 技術スタック、制約条件、背景情報
デバッグ記録: 過去に発生した問題と解決方法の詳細
改善履歴: 試行錯誤の過程と最終的な解決策
アーキテクチャ決定: 設計判断の理由と学習内容

この手法の価値

時間効率の劇的な改善

従来であれば：

記事を読み込む（30 分〜1 時間）
自分のプロジェクトに合わせて設定を調整（1〜2 時間）
試行錯誤しながら導入（数時間）

LLM を活用することで：

コマンド実行（1 分）
生成結果の確認と微調整（10〜15 分）

知識の民主化

優秀な開発者が蓄積した知見を、経験の浅い開発者でも瞬時に活用できるようになります。これにより、チーム全体の開発効率とコード品質の向上が期待できます。

注意点とベストプラクティス

生成されたドキュメントの検証

LLM が生成したドキュメントは、必ず内容を確認し、自分のプロジェクトに適合するかチェックしましょう。

継続的な更新

プロジェクトの進化に合わせて、生成されたドキュメントも定期的に更新することが重要です。

まとめ

LLM の力を活用することで、先駆者が構築した知見を瞬時に自分のプロジェクトに取り込むことが可能になりました。

この手法により：

開発効率の向上: 設定時間の大幅短縮
知識の共有: 優秀な開発者の知見を誰でも活用可能
品質の向上: 実証済みのベストプラクティスを即座に導入

「Before LLM」の思考から脱却し、新しい時代の開発手法を積極的に取り入れることで、より効率的で質の高い開発が実現できるでしょう。

コーディングエージェントごとに独立したコンテナを提供するcontainer-useを動かしてLLMを並列同時実行してみた

Mon, 09 Jun 2025 00:00:00 GMT

3秒まとめ

container-useで Docker コンテナ内にコーディングエージェントの実行環境を独立して作成可能
複数のエージェントを並列実行してローカルで安全に開発環境を管理できる
MCP経由で Claude Code、Cursor、goose などから簡単に操作可能
Git worktreeよりもクリーンで管理しやすい環境分離を実現

どんな人向けの記事？

ローカルで複数のコーディングエージェントを並列実行したい方
Dockerコンテナ内で安全にAI開発環境を管理したい方
Claude Code、Cursor、gooseなどのMCP対応クライアントを使っている方
Git worktreeの代替手法を探している方

概要

Docker の創業者の 1 人が、特定のワークツリーをコンテナ内に配置してコーディングエージェントを動作させるツール「container-use」を開発しました。 https://www.publickey1.jp/blog/25/container_usedocker.html

2025 年 5 月頃には Git worktree を駆使してローカルで複数のコーディングエージェントの環境を作る手法が紹介されていましたが、個人的には ghq を使ったリポジトリ管理にそぐわないため、あまり注目していませんでした。

理想的には、Docker コンテナ内で独立した環境を構築することで、ローカルで複数のコーディングエージェントを並行実行できるようにしたいと考えていました。

そんな中、container-use がリリースされました。まさに求めていた機能だったので、早速試してみることにしました。

container-use の動作概念図

インストール

まず、GitHub から container-use のリポジトリをクローンします。

❯ ghq get git@github.com:dagger/container-use.git
     clone ssh://git@github.com/dagger/container-use.git -> /Users/yuki.matsukura/ghq/github.com/dagger/container-use
       git clone --recursive ssh://git@github.com/dagger/container-use.git /Users/yuki.matsukura/ghq/github.com/dagger/container-use
Cloning into '/Users/yuki.matsukura/ghq/github.com/dagger/container-use'...
remote: Enumerating objects: 735, done.
remote: Counting objects: 100% (144/144), done.
remote: Compressing objects: 100% (50/50), done.
remote: Total 735 (delta 129), reused 94 (delta 93), pack-reused 591 (from 2)
Receiving objects: 100% (735/735), 40.55 MiB | 8.85 MiB/s, done.
Resolving deltas: 100% (514/514), done.
❯ cd ~/ghq/github.com/dagger/container-use

cuコマンド経由で利用するようなので、cuコマンドをビルドします。

❯ make
[+] Building 30.2s (11/11) FINISHED
 => [internal] load build definition from Dockerfile
 => => transferring dockerfile: 396B
 => [internal] load metadata for docker.io/library/golang:latest
 => [auth] library/golang:pull token for registry-1.docker.io
 => [internal] load .dockerignore
 => => transferring context: 120B
 => [builder 1/4] FROM docker.io/library/golang:latest@sha256:db5d0afbfb4ab648af2393b92e87eaae9ad5e01132803d80caef91b5752d289c
 => => resolve docker.io/library/golang:latest@sha256:db5d0afbfb4ab648af2393b92e87eaae9ad5e01132803d80caef91b5752d289c
 => => sha256:db5d0afbfb4ab648af2393b92e87eaae9ad5e01132803d80caef91b5752d289c 9.74kB / 9.74kB
 => => sha256:f692138c53fd540f6d19fe65e259d0d1b681776d15187c50ab566297acf28227 2.32kB / 2.32kB
 => => sha256:1a12b4ea7c0ce04aa0e98be0a8c9942162bac71426f734fe6d3bf988bc9e2627 48.33MB / 48.33MB
 => => sha256:280bbe393e788ced1dcb033580604b24de083601624337be66b3ec31781dae40 23.55MB / 23.55MB
 => => sha256:9cd4095bdf35388c48f7b567b9a331abc514c2791a8beb35cd1558fb10d91285 2.82kB / 2.82kB
 => => sha256:1f4f297e4f699ae0f384d5cc1ea42065f58a115aa0a634d427cbb186f91cb4d0 64.36MB / 64.36MB
 => => sha256:90e45158653cee17fd0433bb95f654076603c1dace770784457d1f08ffc1f1bd 86.41MB / 86.41MB
 => => extracting sha256:1a12b4ea7c0ce04aa0e98be0a8c9942162bac71426f734fe6d3bf988bc9e2627
 => => sha256:f244882bda0eb70b1153262e9054d1f8801651888a3a6fc5a828db420391040e 75.23MB / 75.23MB
 => => sha256:d08d494a376b9ba066591a0d5e15795ecaa4ca7b89566facd3b70f93b58f9cfa 126B / 126B
 => => sha256:4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1 32B / 32B
 => => extracting sha256:280bbe393e788ced1dcb033580604b24de083601624337be66b3ec31781dae40
 => => extracting sha256:1f4f297e4f699ae0f384d5cc1ea42065f58a115aa0a634d427cbb186f91cb4d0
 => => extracting sha256:90e45158653cee17fd0433bb95f654076603c1dace770784457d1f08ffc1f1bd
 => => extracting sha256:f244882bda0eb70b1153262e9054d1f8801651888a3a6fc5a828db420391040e
 => => extracting sha256:d08d494a376b9ba066591a0d5e15795ecaa4ca7b89566facd3b70f93b58f9cfa
 => => extracting sha256:4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1
 => [internal] load build context
 => => transferring context: 88.43kB
 => [builder 2/4] WORKDIR /w
 => [builder 3/4] COPY . .
 => [builder 4/4] RUN --mount=type=cache,target=/go/pkg/mod --mount=type=cache,target=/root/.cache/go-build go build -o /tmp/cu ./cmd/cu
 => [stage-1 1/1] COPY --from=builder /tmp/cu .
 => exporting to client directory
 => => copying files 21.24MB

View build details: docker-desktop://dashboard/build/desktop-linux/desktop-linux/wv9ddwk3l0o7bxmjts2g1cvfm
cu

cu コマンドをインストールします。

❯ make install && hash -r

[+] Building 0.9s (10/10) FINISHED
 => [internal] load build definition from Dockerfile
 => => transferring dockerfile: 396B
 => [internal] load metadata for docker.io/library/golang:latest
 => [internal] load .dockerignore
 => => transferring context: 120B
 => [builder 1/4] FROM docker.io/library/golang:latest@sha256:db5d0afbfb4ab648af2393b92e87eaae9ad5e01132803d80caef91b5752d289c
 => [internal] load build context
 => => transferring context: 1.33kB
 => CACHED [builder 2/4] WORKDIR /w
 => CACHED [builder 3/4] COPY . .
 => CACHED [builder 4/4] RUN --mount=type=cache,target=/go/pkg/mod --mount=type=cache,target=/root/.cache/go-build go build -o /tmp/cu ./cmd/cu
 => CACHED [stage-1 1/1] COPY --from=builder /tmp/cu .
 => exporting to client directory
 => => copying files 21.24MB

View build details: docker-desktop://dashboard/build/desktop-linux/desktop-linux/kdbpvxlq88med5tenxc9cyib6
cu
Installing cu to /Users/yuki.matsukura/.asdf/shims...

asdfによってツールのバージョンを管理しているので、cuは~/.asdf/shims/cuにインストールされました。

使ってみる

MCP経由で操作できるので、MCPに対応しているクライアントからであれば何でも利用可能です。今回はClaude Code経由で実行してみます。

Claude Codeに設定を追加

MCPサーバの設定を追加します。CLIから1発で登録できます。

❯ npx @anthropic-ai/claude-code mcp add container-use -- /Users/yuki.matsukura/.asdf/shims/cu stdio
Added stdio MCP server container-use with command: /Users/yuki.matsukura/.asdf/shims/ stdio to local config

上記のコマンドを実行すると、以下のセクションが、~/.claude.json へ追加されました。

"/Users/yuki.matsukura/ghq/github.com/matsubo/cu-test": {
  "allowedTools": [],
  "history": [
    {
      "display": "/mcp ",
      "pastedContents": {}
    },
    {
      "display": "create a simple flask app\n",
      "pastedContents": {}
    }
  ],
  "dontCrawlDirectory": false,
  "mcpContextUris": [],
  "mcpServers": {
    "container-use": {
      "type": "stdio",
      "command": "/Users/yuki.matsukura/.asdf/shims/cu",
      "args": [
        "stdio"
      ],
      "env": {}
    }
  },
  "enabledMcpjsonServers": [],
  "disabledMcpjsonServers": [],
  "hasTrustDialogAccepted": true,
  "projectOnboardingSeenCount": 0,
  "hasClaudeMdExternalIncludesApproved": false,
  "hasClaudeMdExternalIncludesWarningShown": false,
  "hasCompletedProjectOnboarding": true,
  "lastCost": 0.00041280000000000006,
  "lastAPIDuration": 2617,
  "lastDuration": 26041,
  "lastLinesAdded": 0,
  "lastLinesRemoved": 0,
  "lastTotalInputTokens": 331,
  "lastTotalOutputTokens": 37,
  "lastTotalCacheCreationInputTokens": 0,
  "lastTotalCacheReadInputTokens": 0,
  "lastSessionId": "877e8c9c-315a-4f4c-8a7e-xxxxxxxxxx"
}

CLAUDE.mdに、container-use上で実装させるための指示を追記します（存在していない場合は新規作成します）。

❯ curl https://raw.githubusercontent.com/dagger/container-use/main/rules/agent.md >> CLAUDE.md

container-useを使う前提として、 Gitリポジトリ上で最低1つのコミットが存在している前提で始めなければいけないという要件があります。

今回はテスト用に作ったディレクトリなので、以下のように適当に初期化しておきます。

git init
git commit -m 'init' CLAUDE.md

Claude Code経由で実行

サンプルにあった以下のプロンプトで、超簡単なPythonのWebアプリを作ってみます。

create a simple flask app

新規でプロジェクト用のディレクトリを作成し、claudeコマンドを実行して初期化した後、以下のようにclaudeコマンドの標準入力へプロンプトを流し込みます。

❯ curl https://raw.githubusercontent.com/dagger/container-use/refs/heads/main/examples/hello_world.md | claude

以下のような出力が出て処理が進みます。途中で何度か実装方針の確認のためにインタラクションが求められます。

╭──────────────────────────────────────────────────────────────╮
│ ✻ Welcome to Claude Code!                                    │
│                                                              │
│   /help for help, /status for your current setup             │
│                                                              │
│   cwd: /Users/yuki.matsukura/ghq/github.com/matsubo/cu-test  │
╰──────────────────────────────────────────────────────────────╯


 ※ Tip: Run claude --continue or claude --resume to resume a conversation

> create a simple flask app

⏺ I'll create a simple Flask app using the environment. Let me set up the development environment first.

⏺ container-use:environment_open (MCP)(source: "/Users/yuki.matsukura/ghq/github.com/matsubo/cu-test", name: "flask-app", explanation: "Creating a development environment for a simple Flask application")
  ⎿  {
       "id": "flask-app/fast-guppy",
       "base_image": "ubuntu:24.04",
       "setup_commands": null,
     … +7 lines (ctrl+r to expand)

⏺ container-use:environment_update (MCP)(environment_id: "flask-app/fast-guppy", base_image: "python:3.11-slim", setup_commands: ["pip install flask"], instructions: "python Flask development environment with Flask installed", secrets: [], explanation: "Setting up Python environment with Flask for web development")
  ⎿  {
       "id": "flask-app/fast-guppy",
       "base_image": "python:3.11-slim",
       "setup_commands": [
     … +9 lines (ctrl+r to expand)

⏺ container-use:environment_file_write (MCP)(environment_id: "flask-app/fast-guppy", target_file: "app.py", contents: "from flask import Flask\n\napp = Flask(__name__)\n\n@app.route('/')\ndef hello_world():\n    return 'Hello, World!'\n\n@app.route('/about')\ndef about():\n    return 'This is a simple Flask application!'\n\nif __name__ == '__main__':\n
                                            app.run(debug=True, host='0.0.0.0', port=5000)", explanation: "Creating the main Flask application file with basic routes")

╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ Tool use                                                                                                                                                                                                                                                                                                                                                                               │
│                                                                                                                                                                                                                                                                                                                                                                                        │
│   container-use:environment_file_write(environment_id: "flask-app/fast-guppy", target_file: "app.py", contents: "from flask import Flask\n\napp = Flask(__name__)\n\n@app.route('/')\ndef hello_world():\n    return 'Hello, World!'\n\n@app.route('/about')\ndef about():\n    return 'This is a simple Flask application!'\n\nif __name__ == '__main__':\n    app.run(debug=True,    │
│   host='0.0.0.0', port=5000)", explanation: "Creating the main Flask application file with basic routes") (MCP)                                                                                                                                                                                                                                                                        │
│   Write the contents of a file.                                                                                                                                                                                                                                                                                                                                                        │
│                                                                                                                                                                                                                                                                                                                                                                                        │
│ Do you want to proceed?                                                                                                                                                                                                                                                                                                                                                                │
│ ❯ 1. Yes                                                                                                                                                                                                                                                                                                                                                                               │
│   2. Yes, and don't ask again for container-use:environment_file_write commands in /Users/yuki.matsukura/ghq/github.com/matsubo/cu-test                                                                                                                                                                                                                                                │
│   3. No, and tell Claude what to do differently (esc)                                                                                                                                                                                                                                                                                                                                  │
│                                                                                                                                                                                                                                                                                                                                                                                        │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

コードが完成すると以下のメッセージが出てきました。

⏺ Created a simple Flask app! The application is now running at http://127.0.0.1:5192

  The app includes:
  - A home route at / that returns "Hello, World!"
  - An about route at /about with basic information

  To view your work: git checkout flask-app/fast-guppy

指定されたURLにアクセスすると以下の表示が出てきました。

なんと簡単なアプリのコードが実装され、プレビュー用のサーバも立ち上がった状態です！

動作状態を確認する

どうやって実現しているのか軽く調べて見るために5192番ポートはどのプログラムが使っているのか調べてみます。

❯ lsof -i :5192
COMMAND     PID           USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
dagger-0. 93633 yuki.matsukura    9u  IPv6 0x5e0f6ca282acbd35      0t0  TCP *:aol-2 (LISTEN)
dagger-0. 93633 yuki.matsukura   19u  IPv6 0x27afabb4da99321a      0t0  TCP [::127.0.0.1]:aol-2->[::127.0.0.1]:49823 (CLOSED)
dagger-0. 93633 yuki.matsukura   22u  IPv6 0x3591df621981b1a0      0t0  TCP [::127.0.0.1]:aol-2->[::127.0.0.1]:49834 (CLOSED)
dagger-0. 93633 yuki.matsukura   25u  IPv6 0x5869ccfc590c9e6b      0t0  TCP [::127.0.0.1]:aol-2->[::127.0.0.1]:50072 (CLOSED)
dagger-0. 93633 yuki.matsukura   27u  IPv6 0x1d1e9ef498d1fd1f      0t0  TCP [::127.0.0.1]:aol-2->[::127.0.0.1]:50077 (CLOSED)
dagger-0. 93633 yuki.matsukura   28u  IPv6 0x54ecff8288d4bfbb      0t0  TCP [::127.0.0.1]:aol-2->[::127.0.0.1]:53232 (CLOSED)
dagger-0. 93633 yuki.matsukura   29u  IPv6 0x538b2f4cfbc2347f      0t0  TCP localhost:aol-2->localhost:54005 (CLOSE_WAIT)
dagger-0. 93633 yuki.matsukura   30u  IPv6 0xbe8b89781820e36c      0t0  TCP localhost:aol-2->localhost:54023 (CLOSE_WAIT)
dagger-0. 93633 yuki.matsukura   31u  IPv6 0x97cc532cfede2ef1      0t0  TCP localhost:aol-2->localhost:54029 (CLOSE_WAIT)
dagger-0. 93633 yuki.matsukura   32u  IPv6 0xda67712e4db968cd      0t0  TCP localhost:aol-2->localhost:54033 (CLOSE_WAIT)
dagger-0. 93633 yuki.matsukura   33u  IPv6 0xa63d580e5b1ab14a      0t0  TCP localhost:aol-2->localhost:54622 (CLOSE_WAIT)

MCP Serverっぽいプロセスが立ち上がっています。

❯ ps axu|grep dagger-0|grep -v grep
yuki.matsukura   93633   0.2  0.1 411972208  49168 s015  S+    5:13PM   0:05.77 /Users/yuki.matsukura/Library/Caches/dagger/dagger-0.18.9 session --label dagger.io/sdk.name:go --label dagger.io/sdk.version:0.18.9

コンテナは1つだけしか立ち上がらないようです。LLMの実行中もモニタリングしていましたが1つだけでした。

❯ docker ps
CONTAINER ID   IMAGE                               COMMAND                  CREATED          STATUS          PORTS                    NAMES
6bd9e55c455e   registry.dagger.io/engine:v0.18.9   "dagger-entrypoint.s…"   12 minutes ago   Up 12 minutes                            dagger-engine-v0.18.9

このコンテナの中で、開発環境のコードの実行をプレビューするためのプロセスが立ち上がっていることがわかります。

❯ docker exec -it 6bd9 ps axu
PID   USER     TIME  COMMAND
    1 root      0:51 /usr/local/bin/dagger-engine --config /etc/dagger/engine.toml --debug
   52 root      0:00 /usr/sbin/dnsmasq --keep-in-foreground --log-facility=- --log-debug -u root --conf-file=/var/run/containers/cni/dnsname/dagger/dnsmasq.conf
 1343 root      0:00 buildctl dial-stdio
 1353 root      0:00 buildctl dial-stdio
 1363 root      0:00 buildctl dial-stdio
 1476 root      0:00 buildctl dial-stdio
 1536 root      0:00 /usr/local/bin/runc --log /var/lib/dagger/worker/executor/runc-log.json --log-format json run --bundle /var/lib/dagger/worker/executor/vworhos7now5ohy2fu91ulocj --keep vworhos7now5ohy2fu91ulocj
 1548 root      0:00 /.init sh -c python app.py
 1563 root      0:00 sh -c python app.py
 1564 root      0:00 python app.py
 1565 root      0:00 /usr/local/bin/python app.py
 1619 root      0:00 /usr/local/bin/runc --log /var/lib/dagger/worker/executor/runc-log.json --log-format json run --bundle /var/lib/dagger/worker/executor/y5fwt2a2auf01ig0x8j4tu6qg --keep y5fwt2a2auf01ig0x8j4tu6qg
 1634 root      0:00 /.init sh -c python app.py
 1647 root      0:00 sh -c python app.py
 1648 root      0:00 python app.py
 1649 root      0:00 /usr/local/bin/python app.py
 1833 root      0:00 /usr/local/bin/runc --log /var/lib/dagger/worker/executor/runc-log.json --log-format json run --bundle /var/lib/dagger/worker/executor/joafz8klnzs7cyq5au6qoqxxr --keep joafz8klnzs7cyq5au6qoqxxr
 1846 root      0:00 /.init sh -c uvicorn main:app --host 0.0.0.0 --port 8000
 1860 root      0:00 sh -c uvicorn main:app --host 0.0.0.0 --port 8000
 1861 root      0:00 {uvicorn} /usr/local/bin/python3.11 /usr/local/bin/uvicorn main:app --host 0.0.0.0 --port 8000
 1915 root      0:00 /usr/local/bin/runc --log /var/lib/dagger/worker/executor/runc-log.json --log-format json run --bundle /var/lib/dagger/worker/executor/4prsmjji1quxzpulajwnrwofy --keep 4prsmjji1quxzpulajwnrwofy
 1930 root      0:00 /.init sh -c uvicorn main:app --host 0.0.0.0 --port 8000
 1944 root      0:00 sh -c uvicorn main:app --host 0.0.0.0 --port 8000
 1945 root      0:00 {uvicorn} /usr/local/bin/python3.11 /usr/local/bin/uvicorn main:app --host 0.0.0.0 --port 8000
 1966 root      0:00 ps axu

What's next:
    Try Docker Debug for seamless, persistent debugging tools in any container or image → docker debug 6bd9
    Learn more at https://docs.docker.com/go/debug-cli/

tig --all コマンドでリビジョングラフを確認してみると、勝手にブランチが作られて、自分の名前でコミットが3つ積まれていました。

一応ステップごとにコミットを分けてブランチを生やして実装してくれるようです。

cu watchコマンドでcontainer-useの動作状態を見られるとのことなのでコマンドを実行してみましたが、どうやら裏ではGit logコマンドを1秒おきに実行しているだけのようです。

並列で複数のコーディングエージェントを動かしてみる

サンプルにあったプロンプトを使ってみます。 2つのアプリの実装を指示するプロンプトです。

Create 2 variations of a simple hello world app using Flask and FastAPI. each in their own environment. Give me the URL of each app

上記のプロンプトをClaude Codeに渡します。何度も確認が求められます。1度の質問ごとにコミットが積まれていく感じなので、1つ作ってコミットして質問することを繰り返しています。

❯ curl https://raw.githubusercontent.com/dagger/container-use/refs/heads/main/examples/parallel.md | claude
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   132  100   132    0     0    279      0 --:--:-- --:--:-- --:--:--   279
╭──────────────────────────────────────────────────────────────╮
│ ✻ Welcome to Claude Code!                                    │
│                                                              │
│   /help for help, /status for your current setup             │
│                                                              │
│   cwd: /Users/yuki.matsukura/ghq/github.com/matsubo/cu-test  │
╰──────────────────────────────────────────────────────────────╯


 ※ Tip: Create custom slash commands by adding .md files to .claude/commands/ in your project or ~/.claude/commands/ for commands that work in any project

> Create 2 variations of a simple hello world app using Flask and FastAPI. each in their own environment. Give me the URL of each app

⏺ I'll create two simple hello world apps - one using Flask and one using FastAPI, each in their own environment.
  ⎿  ☐ Create Flask hello world app in its own environment
     ☐ Create FastAPI hello world app in its own environment
     ☐ Start both apps and provide URLs to user
  ⎿  ☐ Create Flask hello world app in its own environment
     ☐ Create FastAPI hello world app in its own environment
     ☐ Start both apps and provide URLs to user

⏺ container-use:environment_open (MCP)(source: "/Users/yuki.matsukura/ghq/github.com/matsubo/cu-test", name: "flask-hello-world", explanation: "Creating environment for Flask hello world app")
  ⎿  {
       "id": "flask-hello-world/relaxed-tarpon",
       "base_image": "ubuntu:24.04",
       "setup_commands": null,
     … +7 lines (ctrl+r to expand)

⏺ container-use:environment_update (MCP)(environment_id: "flask-hello-world/relaxed-tarpon", explanation: "Setting up Python environment with Flask for hello world app", base_image: "python:3.11-slim", instructions: "This environment contains a simple Flask hello world application. Use 'python app.py' to run the Flask server.", setup_commands: ["pip install flask"],
                                        secrets: [])
  ⎿  {
       "id": "flask-hello-world/relaxed-tarpon",
       "base_image": "python:3.11-slim",
       "setup_commands": [
     … +9 lines (ctrl+r to expand)

⏺ container-use:environment_file_write (MCP)(environment_id: "flask-hello-world/relaxed-tarpon", target_file: "app.py", explanation: "Creating Flask hello world application", contents: "from flask import Flask\n\napp = Flask(__name__)\n\n@app.route('/')\ndef hello_world():\n    return 'Hello, World! This is a Flask app.'\n\nif __name__ == '__main__':\n
                                            app.run(host='0.0.0.0', port=5000, debug=True)")
  ⎿  file app.py written successfully, changes pushed to container-use/flask-hello-world/relaxed-tarpon

⏺ container-use:environment_run_cmd (MCP)(environment_id: "flask-hello-world/relaxed-tarpon", command: "python app.py", background: true, ports: [5000], explanation: "Starting Flask hello world app in background")
  ⎿  Command started in the background. Endpoints are {"5000":{"internal":"mlr2r7877less:5000","external":"127.0.0.1:5727"}}

     Any changes to the container workdir (/workdir) WILL NOT be committed to container-use/flask-hello-world/relaxed-tarpon

     Background commands are unaffected by filesystem and any other kind of changes. You need to start a new command for changes to take effect.
  ⎿  ☒ Create Flask hello world app in its own environment
     ☐ Create FastAPI hello world app in its own environment
     ☐ Start both apps and provide URLs to user

⏺ container-use:environment_open (MCP)(source: "/Users/yuki.matsukura/ghq/github.com/matsubo/cu-test", name: "fastapi-hello-world", explanation: "Creating environment for FastAPI hello world app")
  ⎿  {
       "id": "fastapi-hello-world/champion-satyr",
       "base_image": "ubuntu:24.04",
       "setup_commands": null,
     … +7 lines (ctrl+r to expand)

⏺ container-use:environment_update (MCP)(environment_id: "fastapi-hello-world/champion-satyr", explanation: "Setting up Python environment with FastAPI for hello world app", base_image: "python:3.11-slim", instructions: "This environment contains a simple FastAPI hello world application. Use 'uvicorn main:app --host 0.0.0.0 --port 8000' to run the FastAPI server.",
                                        setup_commands: ["pip install fastapi uvicorn"], secrets: [])
  ⎿  {
       "id": "fastapi-hello-world/champion-satyr",
       "base_image": "python:3.11-slim",
       "setup_commands": [
     … +9 lines (ctrl+r to expand)

⏺ container-use:environment_file_write (MCP)(environment_id: "fastapi-hello-world/champion-satyr", target_file: "main.py", explanation: "Creating FastAPI hello world application", contents: "from fastapi import FastAPI\n\napp = FastAPI()\n\n@app.get(\"/\")\ndef read_root():\n    return {\"message\": \"Hello, World! This is a FastAPI app.\"}")
  ⎿  file main.py written successfully, changes pushed to container-use/fastapi-hello-world/champion-satyr

⏺ container-use:environment_run_cmd (MCP)(environment_id: "fastapi-hello-world/champion-satyr", command: "uvicorn main:app --host 0.0.0.0 --port 8000", background: true, ports: [8000], explanation: "Starting FastAPI hello world app in background")
  ⎿  Command started in the background. Endpoints are {"8000":{"internal":"4abousts0jpik:8000","external":"127.0.0.1:5033"}}

     Any changes to the container workdir (/workdir) WILL NOT be committed to container-use/fastapi-hello-world/champion-satyr

     Background commands are unaffected by filesystem and any other kind of changes. You need to start a new command for changes to take effect.
  ⎿  ☒ Create Flask hello world app in its own environment
     ☒ Create FastAPI hello world app in its own environment
     ☒ Start both apps and provide URLs to user

⏺ Both hello world apps are now running! Here are the URLs:

  Flask App: http://127.0.0.1:5727
  FastAPI App: http://127.0.0.1:5033

  To view the code for each app:
  - Flask: git checkout flask-hello-world/relaxed-tarpon
  - FastAPI: git checkout fastapi-hello-world/champion-satyr

完成しました。

それぞれのURLが表示されるのでアクセスしてみました。

ブランチは以下のような感じに作られました。

よく確認してみると、リモートブランチに作られています。ということは、リモートブランチはどこに指定されているのか確認してみます。

❯ grep 'remote "container-use"'  .git/config -A 2
[remote "container-use"]
        url = /Users/yuki.matsukura/.config/container-use/repos/cu-test
        fetch = +refs/heads/*:refs/remotes/container-use/*

なんと、ホームディレクトリの.config ディレクトリ以下に保存されています。このリモートリポジトリは環境を作成するたびに肥大化していくため、定期的な管理が必要です。現在のところ環境を削除する専用のコマンドは提供されていないため、不要になった環境のデータは手動で削除する必要があります。

まとめ

container-use を使って並列で複数のコーディングエージェントを動かすことが可能になったので、手元で複数のエージェントを並行で安全に動作させて実行できるようになりました。

GitHub Actions で Claude Code を実行すると Actions の稼働時間を消費してしまうので、ローカルで動かせるエージェントはローカルで動かすことでコスト削減できます。

今まではきれいに並列でコーディングエージェントを動かす方法がありませんでしたが、container-use によってコンテナ内に閉じた個別に独立した環境でエージェントが実装を進められるようになります。

（自分で作ろうかなと思っていたら、ちょうどリリースされました）。

デジタルアドレスの問題点と将来像〜日本郵便のサービスをビジネス視点で考える〜

Fri, 06 Jun 2025 00:00:00 GMT

3秒まとめ

日本郵便が 2025 年 5 月 26 日にデジタルアドレスサービスを開始
全ステークホルダーにとってデメリットが利便性を上回る
技術的なセキュリティ対策が不十分で利用規約頼み

どんな人向けの記事？

住所管理システムを開発しているエンジニア
プライバシー技術に興味がある方
新しいAPIの導入を検討している開発者
セキュリティリスクを評価する必要がある方

日本郵便が住所を 7 桁の英数字で表現する新サービス「デジタルアドレス」の提供を 2025 年 5 月 26 日に開始しました。

10 年以上前から郵便番号検索のAPIサービスを運営している身として、また大学時代に位置情報、GIS、プライバシーなどの研究をしていたドメイン知識を活かして、このサービスを技術的に分析した結果、現状では課題が多く、サービス内容を見直さないと運用が微妙という結論に至りました。

課題と改善提案を各ステークホルダーごとにブレークダウンして説明します。

ステークホルダーの整理

このサービスには以下のステークホルダーが存在します。

デジタルアドレスを発行・管理する個人・法人（ゆう ID 利用者）
デジタルアドレスを入力する個人・法人（エンドユーザー）
デジタルアドレスの入力を受け付け保管・管理する者（ユーザー）
自社のユーザや取引先の住所を管理する事業者（ユーザー）
デジタルアドレスと住所の関連付けを管理主体（郵便局・提供者）

上記に加えて、セキュリティの観点で以下のアクターが存在します

不正に住所情報を取得しようとする悪意のある人（第三者）

各ステークホルダーに対してのデメリット

メリットに関しては郵便局が発信しているのでここではその逆であるデメリットについて述べます。

デジタルアドレスを発行・管理する個人・法人（ゆうID利用者）

利便性の問題

住所を伝達する際に、デジタルアドレスの 7 桁だけを伝えればすむから良いが、長いので覚えづらい
普通に自分の住所も覚えておく必要があるので使う頻度は少ない
わざわざ利用するときに記録したメモなどを参照するほうが面倒になる

Webフォームでの必要性の低さ

Web のフォームで入力する場合はコピー&ペーストで済むかもしれないが、そもそもWebのフォームであればブラウザのオートコンプリートで住所が入力されるからそもそも問題がない
わざわざデジタルアドレスを使う必要性が無い

深刻なプライバシーリスク

デジタルアドレスを自分以外の人や組織に伝えることによって、最新の住所がトラッキングできる状態になる
そのデジタルアドレスが住所以外の情報と結びつくことによって個人情報となる
デジタルアドレスを使わなければ、もし住所情報が漏洩したら最悪の場合は引っ越せば良いが、デジタルアドレスが漏洩した場合はデジタルアドレスを作り直したうえで引っ越す必要がある
古いデジタルアドレスを共有されている人や事業者にとっては最新の住所を参照できるキーであるデジタルアドレスの意味がなくなってしまう

名寄せリスク

インターネット上で複数の事業者からデジタルアドレスを含むアカウント情報が漏洩した場合、デジタルアドレスをキーとして名寄せをされてしまう
今までであればメールアドレスや電話番号によって名寄せできていたが同じように ID 性の高いキーによって名寄せを促進させる状態になってしまう

監視・管理の不可能性

自分のデジタルアドレスの管理のために、誰がどのようにして自分のデジタルアドレスを検索しているのかを知りたいが、知るすべがない
もし、不正に利用されそうだったら即座にそのデジタルアドレスを止めたいのに、知るすべがない
デジタルアドレスが漏洩したとしても把握できない
本来ならば、管理画面上で自分のデジタルアドレスを参照したユーザのエンティティを知れる状態を作るべき
例えば、Amazon にデジタルアドレスに登録したのに、使うべきではない言葉なので修正してください DM を送りつける会社が自分のデジタルアドレスを検索していたら止めたいので

利便性が微小だが、漏洩した際のリスクが大きい </div>

デジタルアドレスを入力する個人・法人（エンドユーザー）

記憶・使用の困難さ

使用頻度が低いから覚えるのがちょっと難しい
住所を使う機会のほうが圧倒的に多いのでわざわざ同じ情報を表現するために 2 つのことを覚えるのは難しい
しかもランダムだから覚えづらい

ブラウザ対応の問題

ブラウザがオートコンプリートに対応してくれればよいが、日本の独自仕様なので対応する可能性が低い
ブラウザから見たら、郵便番号の 1 つとして見られると思う

既存機能との競合

そもそも、ブラウザにオートコンプリートが付いているのでデジタルアドレスを入力しないでもオートコンプリートを使うので入力の手間は低いのでデジタルアドレスを使うベネフィットが低い

個人間共有での問題

普段の生活において個人間での荷物のやり取りなどで住所を共有するケースがある
ここでデジタルアドレスを利用すれば簡単に住所が共有できることになる
しかしながら、デジタルアドレスは恒久的にその人の住所を表現するアドレスになるので誰にどのデジタルアドレスを共有しておいたかを覚えておかないと引っ越した時とかにリセットできなくなる

デジタルアドレスの入力を受け付け保管・管理する者（ユーザー）

認証の複雑化

デジタルアドレスの入力を受け付けるために、デジタルアドレスから住所を検索する API を使う
しかしながら、第三者によってブルートフォースなどによるアタックを防ぐために誰でもアクセスできる状態にあるところにデジタルアドレスから住所を求めるサービスを置けない
ユーザ認証した後でないとデジタルアドレスの入力を受け付けることができない
その際のユーザ認証はそこそこ重要度が高くて個人が特定できるような電話番号が検証できているユーザや、捨てアドではないメールアドレスで到達性が確認できているメールアドレスを使って認証されたユーザの必要がある
そもそもデジタルアドレスは EC といった場面で使うことが想定されているが、住所入力は個人認証に近いユーザ認証が終わってから出ないといけない

離脱リスクの増加

例えば事業者にとっては最低限、配送先と決済がおわればよいのに個人認証に近いことをやらなければいけないので離脱リスクが増えてしまう

監視負担の増加

デジタルアドレスから住所を検索する API が不正に利用されるのを防ぐために、事業者がエンドユーザに提供しているサービスの不正利用を細かく監視する必要がある
デジタルアドレスを検索しようとするアタッカーから常に守らなければならない
もし、不正に利用されると自社のアカウントの信頼性が低くなるリスクがある

データ管理の複雑化

エンドユーザからデジタルアドレスを取得した場合、上記のような事項があるからデジタルアドレスだけではなくて現住所の情報も保管するのが一般的なユースケースかと考える
その場合、同じ住所情報が 2 つあるので短期的には問題が無いが、引っ越したりしてどちらかが異なるような状態になったときに事業者はどちらを正として扱うか困惑する
あらかじめルールを決めたうえで運用し、エンドユーザにも認知させる必要がある
例えば、デジタルアドレスを入力している場合はデジタルアドレスが主となると言った具合に
しかし、デジタルアドレスはエンドユーザによって消去できたりもするので文字の住所情報が正しくてデジタルアドレスが検索できない状態になる状態も存在する
よって、住所情報を利用する際には毎回API検索が発生してしまって使い勝手が悪い

個人情報管理負担の増加

デジタルアドレスはエンドユーザのかなり重要な情報であるので、取り扱う個人情報が追加で増えてしまう
また、漏洩したときのリスクとエンドユーザに強いる操作が多くなる
もし、デジタルアドレスと同時に氏名や電話番号が漏洩した場合はリスクを低くするためにデジタルアドレスを消去してもらうことをエンドユーザに依頼することとなる
そうなると、エンドユーザにとって他の場所でも使っているデジタルアドレスがすべて無効になってしまうのでエンドユーザはデジタルアドレスのベネフィットを享受できなくなるばかりかリスク軽減のための運用を強いられてしまう

自社のユーザや取引先の住所を管理する事業者（ユーザー）

3 に似ているが、ここでは社内利用。エンドユーザには提供しないケース
初めてこのケースでメリットのほうが大きくなりそうではある
デジタルアドレスの関連付けがpublicになっても問題ないケースではメリットのほうが大きいと考える
法人は、高頻度で引っ越すのでデジタルアドレスを取引先マスタの情報として持っておくと利便性は高い
荷物を配送する前にデジタルアドレスを検証すれば不着になるリスクも抑えられる

デジタルアドレスと住所の関連付けを管理主体（郵便局・提供者）

セキュリティリスク

ブルートフォースによる不正アクセスから守らなければいけない
また関連付けのマスタ情報は機密性が高く狙われやすいので厳重に管理されていなければならない
一度でも流出したら全個人ユーザに発行し直しとそのデジタルアドレスを登録しているサービスに対してすべて登録しなおしてもらう依頼をだすことになる

認証の脆弱性

現時点で、ゆうIDはメアドとパスワードだけでログインできてしまう
エンドユーザはパスワードを使いまわしているケースが多いので別のサイトで漏洩したメアドとパスワードでログインされてしまうリスクがあるのでMFAを実装しなければリスクが高い
KYC を実装しないと、悪意のあるものが大量のアカウントを発行し、デジタルアドレスのブルートフォースに利用できてしまう。

運用負担

デジタルアドレスの管理システムを長期的に運用し続けなければいけない
止めたくても止められない
公共性が高いという理由で運用していても良いが、デジタルアドレスが存在することによって利用者の利便性が上がればよいが、デメリットのほうが上回る

あえてメリットがあるケース

公共性の高い住所の運用では利便性がありそうです。

法人住所や行政機関の住所といったエンティティと住所が公に広く知れ渡ったほうが便益があるようなケース

これらの場合、プライバシーリスクよりも利便性が上回る可能性があります。これにより秘匿する情報がなくなるのでセキュリティリスクは無くなります。

私の主張：「サービス内容の見直しが必要」

以上の点から、現状のデジタルアドレスサービスは課題が多く、サービス内容の見直しが必要と考えます。

主な課題

利便性が微小なのに漏洩時のリスクが甚大
全ステークホルダー（社内利用以外）にデメリットが存在
技術的なセキュリティ対策が不十分
既存技術（ブラウザオートコンプリート）で十分

改善提案

もしデジタルアドレスサービスを継続するなら、以下の改善が必要と考えます。

文字列長の拡張: 7 桁ではなく、少なくとも 16 桁以上に変更してセキュリティを強化
技術的セキュリティ対策: レート制限、IP 制限、異常検知などの実装
MFA必須化: ゆう ID の取得には KYC を実施する。
透明性の向上: 利用統計の開示、不正利用の通知機能
利用範囲の限定: まずは法人・行政機関など公共性の高い住所に限定する

現状のサービス内容ではすべてを満たすことは不可能なので、何かしら機能強化をするかスコープを限定するべきと考えます。

WordPressをSQLite対応してGitで管理し、AWS Lightsail Containerへデプロイする構成

Fri, 06 Jun 2025 00:00:00 GMT

3秒まとめ

WordPressをSQLiteで運用することで、すべてをファイルで管理できるようになる
Git + Docker + Lightsail Containerで使うべきではない言葉なので修正してくださいの運用ワークフローが構築できる
管理画面を無効化してセキュリティリスクを大幅削減
月$7で本格的なコンテナ運用が可能

どんな人向けの記事？

WordPress の運用でバージョン管理に困っている方
開発環境・ステージング・本番環境の同期が大変だと感じている方
コーポレートサイトなどの更新頻度が少ない WordPress をよりモダンな開発フローで運用したい方
セキュリティを重視した WordPress 運用を考えている方
コンテナ技術で WordPress を運用してみたい方

背景

WordPress で運用されているサイトは大量に存在しますよね。用途は多種多様ですが、今回は開発環境、ステージング環境、本番環境などの複数の環境が存在するようなコーポレートサイト、プラグイン開発、テーマ開発をしている方を対象としています。

問題

WordPress の表示はファイル × データベースの内容の組み合わせになっています。開発環境でテーマファイルやプラグインを変更した場合は、各環境でファイルとデータベースの内容を同期する必要があるのですが、これがかなり運用上大変なんですよね...😅

具体的には、次のような問題があります。

バージョン管理ができなくて辛い
不具合が起きたときに、ファイルが原因なのか入稿されているデータが原因か特定するのが難しい
環境間でのデータ同期が煩雑
ロールバックが困難

アプローチ

WordPress のバックアップを難しくしているのはデータベース内に入っているデータとファイルシステム上にあるファイルが存在していて一緒にバックアップを取る必要がありますが、データベースのバックアップを取得するのが面倒です。そのデータベースをファイルとして扱えるように SQLite を使ってサイトを構築します。

そうすれば、ファイルとしてバックアップするだけでスナップショットが取れます。スナップショットがファイルとして簡単に取得できるということはそれを様々な環境へ適用できます。そのデータファイルもテーマファイルやプラグインとバージョン管理システムに入れることでスナップショットとして管理することが可能になります。

WordPress を SQLite で運用する詳細な方法については、こちらの記事で解説しています！ https://zenn.dev/matsubokkuri/articles/wordpress-sqlite </div>

アプローチの評価を以下にまとめます。メリットが多いので新規で構築する際はこの方法を取ることを強く推奨します！

メリット

すべての状態をファイルで管理することが可能になり、差分が明確になるしロールバックも容易に行える
開発環境はDocker composeで立ち上げることが可能になる（めちゃくちゃ楽！）
本番環境はコンテナで運用できるようになり、スケールアウトが可能になる
SQLiteのデータファイルはバイナリデータではあるがポータビリティがあるので OS のアーキテクチャ非依存
本番はコンテナの運用なので管理画面を無効化できるのでログイン画面へのアタックがなくなる（セキュリティ使うべきではない言葉なので修正してください！　🛡️）
WordPressの本体は公式イメージを使うのでコア機能の更新が容易

デメリット

Webでコンテンツの更新ができなくなる。コンテンツを更新する際はローカルなどで行う必要がある
データベース上のデータはバイナリファイルなので差分がテキストではわからない（コミットフックで差分を毎回取ってファイルとして dump しても良いがやり過ぎ感がある）
AWS Lightsail Containerがちょっと高い。具体的には月に$7 USD/month かかる

Web でのコンテンツ更新ができなくなるのは一見デメリットに見えますが、実際にはコンテンツの変更履歴が残るので、むしろメリットと考えることもできます！ </div>

設定方法

まず、ローカルでDocker composeでWordPress + SQLiteが立ち上がる環境を作ります。

ディレクトリ構成は以下のようになります。

.
├── docker-compose.yml
├── Makefile
├── themes/          # WordPressテーマ
├── plugins/         # WordPressプラグイン
├── uploads/         # アップロードファイル
├── database/        # データベースファイル
├── db.php          # SQLiteを使うためのドロップイン
└── custom.ini      # PHP設定のオーバーライド

WordPressの本体はdocker imageを利用するのでカスタマイズする部分だけを管理します。これがポイントです！

次に重要なファイルを解説していきます。

docker-compose.yml

中身は以下のようになります。

services:
  wordpress:
    image: wordpress:latest
    user: "${UID:-1000}:${GID:-1000}"
    restart: always
    volumes:
       - ./themes:/var/www/html/wp-content/themes
       - ./plugins:/var/www/html/wp-content/plugins
       - ./uploads:/var/www/html/wp-content/uploads
       - ./database:/var/www/html/wp-content/database
       - ./db.php:/var/www/html/wp-content/db.php
       - ./custom.ini:/usr/local/etc/php/conf.d/custom.ini
    ports:
      - "8080:80"
    environment:
      # 日本語ロケール設定
      LANG: ja_JP.UTF-8
      LANGUAGE: ja_JP:ja
      LC_ALL: ja_JP.UTF-8
      WORDPRESS_DB_HOST: dummy
      WORDPRESS_DB_NAME: dummy
      WORDPRESS_DB_USER: dummy
      WORDPRESS_CONFIG_EXTRA: |
        define('WP_HOME', '${WP_HOME}');
        define('WP_SITEURL', '${WP_HOME}');
        define('WP_AUTO_UPDATE_CORE', ${WP_AUTO_UPDATE_CORE:-false});
        define('WP_DEBUG_LOG', ${WP_DEBUG_LOG:-true});
        define('WP_DEBUG_DISPLAY', ${WP_DEBUG_DISPLAY:-true});
      WORDPRESS_AUTH_KEY: ${WORDPRESS_AUTH_KEY:-dummy}
      WORDPRESS_SECURE_AUTH_KEY: ${WORDPRESS_SECURE_AUTH_KEY:-dummy}
      WORDPRESS_LOGGED_IN_KEY: ${WORDPRESS_LOGGED_IN_KEY:-dummy}
      WORDPRESS_NONCE_KEY: ${WORDPRESS_NONCE_KEY:-dummy}
      WORDPRESS_AUTH_SALT: ${WORDPRESS_AUTH_SALT:-dummy}
      WORDPRESS_SECURE_AUTH_SALT: ${WORDPRESS_SECURE_AUTH_SALT:-dummy}
      WORDPRESS_LOGGED_IN_SALT: ${WORDPRESS_LOGGED_IN_SALT:-dummy}
      WORDPRESS_NONCE_SALT: ${WORDPRESS_NONCE_SALT:-dummy}

上記のファイルがすべてのスタートとなるので重要です。コンテナは1つだけなのでシンプルな構成になっています。公式のWordPressのイメージはApache + PHPという構成になっています。

次に主要なセクションを解説します。

volumes セクション

volumes セクションで公式のWordPressでは空っぽになる部分を、自分で管理するためにローカルのファイルシステムをマウントします。

PHPの設定は適切な場所にファイルを置けば、勝手に読んでくれるので、そのまま使います。

custom.ini には以下の設定を入れています。初期設定では大きな画像がアップロードできないので、大きめに設定しています。

post_max_size = 200M
upload_max_filesize = 200M

environment セクション

環境変数である environment について説明します。

以下の設定はSQLiteなので不要なのですが、WordPress側が公式にサポートしていないということもあり何かしらの値を設定する必要があるのでダミーの文字列を設定しています。ちょっとかっこ悪いですがこれがないと動きません😅

WORDPRESS_DB_HOST: dummy
WORDPRESS_DB_NAME: dummy
WORDPRESS_DB_USER: dummy

WordPressのデータベース上には自分のサイトのURLを記録する必要がありますが、それを環境ごとに外部から指定するために上の2つの環境変数を設定します。本番環境では、プラグインなどの自動更新は不要なので、WP_AUTO_UPDATE_CORE を false にします。また、ローカルといった開発環境ではデバッグ関連の出力を多く出すために WP_DEBUG_LOG と WP_DEBUG_DISPLAY を true にします。

WORDPRESS_CONFIG_EXTRA: |
  define('WP_HOME', '${WP_HOME}');
  define('WP_SITEURL', '${WP_HOME}');
  define('WP_AUTO_UPDATE_CORE', ${WP_AUTO_UPDATE_CORE:-false});
  define('WP_DEBUG_LOG', ${WP_DEBUG_LOG:-true});
  define('WP_DEBUG_DISPLAY', ${WP_DEBUG_DISPLAY:-true});

秘密鍵を設定するために WORDPRESS_AUTH_KEY などの環境変数を設定します。この設定はなくても良いのですが、設定しないとコンテナの起動のたびにランダムな英数字が設定されます。それによって、ログインしているセッションがすべて破棄されるので何かしらを設定しておいたほうが便利です。

WORDPRESS_AUTH_KEY: ${WORDPRESS_AUTH_KEY:-dummy}
WORDPRESS_SECURE_AUTH_KEY: ${WORDPRESS_SECURE_AUTH_KEY:-dummy}
WORDPRESS_LOGGED_IN_KEY: ${WORDPRESS_LOGGED_IN_KEY:-dummy}
WORDPRESS_NONCE_KEY: ${WORDPRESS_NONCE_KEY:-dummy}
WORDPRESS_AUTH_SALT: ${WORDPRESS_AUTH_SALT:-dummy}
WORDPRESS_SECURE_AUTH_SALT: ${WORDPRESS_SECURE_AUTH_SALT:-dummy}
WORDPRESS_LOGGED_IN_SALT: ${WORDPRESS_LOGGED_IN_SALT:-dummy}
WORDPRESS_NONCE_SALT: ${WORDPRESS_NONCE_SALT:-dummy}

.envファイル

.envファイルの最低限の設定は以下のような感じになります。

UID=501
GID=20
WP_HOME="http://localhost:8080"

その他のファイル

db.php ファイルはこちらのファイルです。

Makefile にはこちらののような内容を入れています。なくてもよいのですが、docker関連の地味な権限周りの修正などを行うためにあったほうが楽です。

起動方法

一通りファイルを揃えて、以下のコマンドを打てば立ち上がるはずです。

make up

そして、http://localhost:8080 にアクセスするとWordPressが表示されます！　🎉

デプロイメント

ここまででWordPressをしっかりとファイルで管理できるようになったらどこにでも簡単にデプロイできます。rsyncでサーバに同期しても良いです。ここでは、より柔軟な方法を使ってインフラを運用するのでコンテナ環境でデプロイします。

lightsailではTLSのターミネーションをしてくれるので証明書の更新も自動化できます。

ファイルの準備

デプロイするイメージを作るためのDockerfileを用意します。

FROM wordpress:latest

# 日本語ロケールのインストールと設定
RUN apt-get update && apt-get install -y locales \
    && sed -i '/ja_JP.UTF-8/s/^# //g' /etc/locale.gen \
    && locale-gen \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

ENV LANG=ja_JP.UTF-8
ENV LANGUAGE=ja_JP:ja
ENV LC_ALL=ja_JP.UTF-8

# カスタムPHP設定をコピー
COPY custom.ini /usr/local/etc/php/conf.d/custom.ini

# WordPressファイルをコピー（日本語ファイル名対応）
COPY themes/ /var/www/html/wp-content/themes/
COPY plugins/ /var/www/html/wp-content/plugins/
COPY uploads/ /var/www/html/wp-content/uploads/
COPY database/ /var/www/html/wp-content/database/
COPY db.php /var/www/html/wp-content/db.php

# WordPress管理機能の無効化
RUN rm -f /usr/src/wordpress/wp-login.php \
          /usr/src/wordpress/wp-config-sample.php \
          /usr/src/wordpress/readme.html \
          /usr/src/wordpress/license.txt \
          /usr/src/wordpress/wp-trackback.php \
          /usr/src/wordpress/wp-comments-post.php

# ポート80を公開
EXPOSE 80

# WordPressを起動
CMD ["apache2-foreground"]

簡単に解説すると、docker composeでやっていることとほとんど同じです。デプロイする環境ではWordPressの管理機能は使わせられないので管理画面に必要なファイルや運用に関係ないファイルを削除しています。

GitHub Actions設定

ステージング環境へデプロイするGitHub Actionsのワークフローファイルを以下に記載します。developブランチにpushするとlightsailのステージング環境へデプロイします。

.github/workflows/deploy-staging.yml

name: Deploy to Staging

on:
  push:
    branches: [develop]
  workflow_dispatch:

env:
  AWS_REGION: ap-northeast-1
  LIGHTSAIL_SERVICE_NAME: mysite-staging
  IMAGE_NAME: wordpress-staging
  DOMAIN_NAME: example.com
  CONTAINER_NAME: wordpress
  CONTAINER_PORT: 80

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: Staging

    steps:
    - name: Set up locale for Japanese filenames
      run: |
        sudo apt-get update
        sudo apt-get install -y locales
        sudo locale-gen ja_JP.UTF-8
        echo "LANG=ja_JP.UTF-8" >> $GITHUB_ENV
        echo "LC_ALL=ja_JP.UTF-8" >> $GITHUB_ENV
        echo "LANGUAGE=ja_JP:ja" >> $GITHUB_ENV

    - name: Checkout code
      uses: actions/checkout@v4

    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v4
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ${{ env.AWS_REGION }}

    - name: Install AWS CLI Lightsail plugin
      run: |
        curl "https://s3.us-west-2.amazonaws.com/lightsailctl/latest/linux-amd64/lightsailctl" -o "lightsailctl"
        sudo mv lightsailctl /usr/local/bin/lightsailctl
        sudo chmod +x /usr/local/bin/lightsailctl

    - name: Build Docker image
      run: |
        export LANG=ja_JP.UTF-8
        export LC_ALL=ja_JP.UTF-8
        export LANGUAGE=ja_JP:ja
        docker build -t ${{ env.IMAGE_NAME }}:latest .

    - name: Push image to Lightsail
      id: push-image
      run: |
        IMAGE_LABEL="${{ env.LIGHTSAIL_SERVICE_NAME }}"
        aws lightsail push-container-image \
          --region ${{ env.AWS_REGION }} \
          --service-name ${{ env.LIGHTSAIL_SERVICE_NAME }} \
          --label $IMAGE_LABEL \
          --image ${{ env.IMAGE_NAME }}:latest
        echo "image_label=$IMAGE_LABEL" >> $GITHUB_OUTPUT

    - name: Create deployment files
      run: |
        cat > containers.json << EOF
        {
          "${{ env.CONTAINER_NAME }}": {
            "image": ":${{ env.LIGHTSAIL_SERVICE_NAME }}.${{ steps.push-image.outputs.image_label }}.latest",
            "environment": {
              "WORDPRESS_DB_HOST": "dummy",
              "WORDPRESS_DB_NAME": "dummy",
              "WORDPRESS_DB_USER": "dummy",
              "WORDPRESS_CONFIG_EXTRA": "define('WP_HOME', 'https://${{ env.DOMAIN_NAME }}'); define('WP_SITEURL', 'https://${{ env.DOMAIN_NAME }}'); define('WP_AUTO_UPDATE_CORE', false); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false);",
              "WORDPRESS_AUTH_KEY": "${{ secrets.WORDPRESS_AUTH_KEY }}",
              "WORDPRESS_SECURE_AUTH_KEY": "${{ secrets.WORDPRESS_SECURE_AUTH_KEY }}",
              "WORDPRESS_LOGGED_IN_KEY": "${{ secrets.WORDPRESS_LOGGED_IN_KEY }}",
              "WORDPRESS_NONCE_KEY": "${{ secrets.WORDPRESS_NONCE_KEY }}",
              "WORDPRESS_AUTH_SALT": "${{ secrets.WORDPRESS_AUTH_SALT }}",
              "WORDPRESS_SECURE_AUTH_SALT": "${{ secrets.WORDPRESS_SECURE_AUTH_SALT }}",
              "WORDPRESS_LOGGED_IN_SALT": "${{ secrets.WORDPRESS_LOGGED_IN_SALT }}",
              "WORDPRESS_NONCE_SALT": "${{ secrets.WORDPRESS_NONCE_SALT }}"
            },
            "ports": {
              "${{ env.CONTAINER_PORT }}": "HTTP"
            }
          }
        }
        EOF

        cat > public-endpoint.json << EOF
        {
          "containerName": "${{ env.CONTAINER_NAME }}",
          "containerPort": ${{ env.CONTAINER_PORT }},
          "healthCheck": {
            "healthyThreshold": 2,
            "unhealthyThreshold": 2,
            "timeoutSeconds": 5,
            "intervalSeconds": 30,
            "path": "/",
            "successCodes": "200-499"
          }
        }
        EOF

    - name: Deploy to Lightsail
      run: |
        aws lightsail create-container-service-deployment \
          --region ${{ env.AWS_REGION }} \
          --service-name ${{ env.LIGHTSAIL_SERVICE_NAME }} \
          --containers file://containers.json \
          --public-endpoint file://public-endpoint.json

    - name: Get deployment status
      run: |
        aws lightsail get-container-services \
          --region ${{ env.AWS_REGION }} \
          --service-name ${{ env.LIGHTSAIL_SERVICE_NAME }}

    - name: Notify deployment completion
      run: |
        echo "🚀 Staging deployment completed successfully!"
        echo "Site URL: https://${{ env.DOMAIN_NAME }}"

簡単に説明すると、imageをbuildして、pushして、登録するだけです。秘密鍵などが必要になりますのでGitHub側に必要に応じて登録しておく必要があります。

環境変数の登録例

本番環境用のワークフロー

production側もほぼ同等です。

name: Deploy to Production

on:
  push:
    branches: [ main ]
  release:
    types: [ published ]
  workflow_dispatch:

env:
  AWS_REGION: ap-northeast-1
  LIGHTSAIL_SERVICE_NAME: mysite-production
  IMAGE_NAME: wordpress-production
  DOMAIN_NAME: example.com
  CONTAINER_NAME: wordpress
  CONTAINER_PORT: 80

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: Production

    steps:
    - name: Checkout code
      uses: actions/checkout@v4

    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v4
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ${{ env.AWS_REGION }}

    - name: Install AWS CLI Lightsail plugin
      run: |
        curl "https://s3.us-west-2.amazonaws.com/lightsailctl/latest/linux-amd64/lightsailctl" -o "lightsailctl"
        sudo mv lightsailctl /usr/local/bin/lightsailctl
        sudo chmod +x /usr/local/bin/lightsailctl

    - name: Build Docker image
      run: docker build -t ${{ env.IMAGE_NAME }}:latest .

    - name: Push image to Lightsail
      id: push-image
      run: |
        IMAGE_LABEL="${{ env.LIGHTSAIL_SERVICE_NAME }}"
        aws lightsail push-container-image \
          --region ${{ env.AWS_REGION }} \
          --service-name ${{ env.LIGHTSAIL_SERVICE_NAME }} \
          --label $IMAGE_LABEL \
          --image ${{ env.IMAGE_NAME }}:latest
        echo "image_label=$IMAGE_LABEL" >> $GITHUB_OUTPUT

    - name: Create deployment files
      run: |
        cat > containers.json << EOF
        {
          "${{ env.CONTAINER_NAME }}": {
            "image": ":${{ env.LIGHTSAIL_SERVICE_NAME }}.${{ steps.push-image.outputs.image_label }}.latest",
            "environment": {
              "WORDPRESS_DB_HOST": "dummy",
              "WORDPRESS_DB_NAME": "dummy",
              "WORDPRESS_DB_USER": "dummy",
              "WORDPRESS_CONFIG_EXTRA": "define('WP_HOME', 'https://${{ env.DOMAIN_NAME }}'); define('WP_SITEURL', 'https://${{ env.DOMAIN_NAME }}'); define('WP_AUTO_UPDATE_CORE', false); define('WP_DEBUG_LOG', false); define('WP_DEBUG_DISPLAY', false); define('SCRIPT_DEBUG', false); define('CONCATENATE_SCRIPTS', true);",
              "WORDPRESS_AUTH_KEY": "${{ secrets.WORDPRESS_AUTH_KEY }}",
              "WORDPRESS_SECURE_AUTH_KEY": "${{ secrets.WORDPRESS_SECURE_AUTH_KEY }}",
              "WORDPRESS_LOGGED_IN_KEY": "${{ secrets.WORDPRESS_LOGGED_IN_KEY }}",
              "WORDPRESS_NONCE_KEY": "${{ secrets.WORDPRESS_NONCE_KEY }}",
              "WORDPRESS_AUTH_SALT": "${{ secrets.WORDPRESS_AUTH_SALT }}",
              "WORDPRESS_SECURE_AUTH_SALT": "${{ secrets.WORDPRESS_SECURE_AUTH_SALT }}",
              "WORDPRESS_LOGGED_IN_SALT": "${{ secrets.WORDPRESS_LOGGED_IN_SALT }}",
              "WORDPRESS_NONCE_SALT": "${{ secrets.WORDPRESS_NONCE_SALT }}"
            },
            "ports": {
              "${{ env.CONTAINER_PORT }}": "HTTP"
            }
          }
        }
        EOF

        cat > public-endpoint.json << EOF
        {
          "containerName": "${{ env.CONTAINER_NAME }}",
          "containerPort": ${{ env.CONTAINER_PORT }},
          "healthCheck": {
            "healthyThreshold": 2,
            "unhealthyThreshold": 2,
            "timeoutSeconds": 5,
            "intervalSeconds": 30,
            "path": "/",
            "successCodes": "200-499"
          }
        }
        EOF

    - name: Deploy to Lightsail
      run: |
        aws lightsail create-container-service-deployment \
          --region ${{ env.AWS_REGION }} \
          --service-name ${{ env.LIGHTSAIL_SERVICE_NAME }} \
          --containers file://containers.json \
          --public-endpoint file://public-endpoint.json

    - name: Get deployment status
      run: |
        aws lightsail get-container-services \
          --region ${{ env.AWS_REGION }} \
          --service-name ${{ env.LIGHTSAIL_SERVICE_NAME }}

    - name: Notify deployment completion
      run: |
        echo "🚀 Production deployment completed successfully!"
        echo "Site URL: https://${{ env.DOMAIN_NAME }}"
  
  release:
    needs: deploy
    runs-on: ubuntu-latest
    steps:
    - name: Checkout code
      uses: actions/checkout@v4
    - name: Release Drafter
      uses: release-drafter/release-drafter@v6
      with:
        publish: true
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

ステージングと異なるところは、release-drafterを利用して本番へのデプロイのたびに自動的にリリースノートの作成と、タグを付けるようにしています。誰がいつどのように本番サイトを変更したかを記録することが可能になります。

AWS側の設定

前提条件

AWSアカウントが作成済み
AWS CLIがインストール済み
GitHubリポジトリへのアクセス権限

IAMユーザーの作成

GitHub Actions用のIAMユーザーを作成します。

IAMユーザー作成

# AWS CLIでIAMユーザーを作成
aws iam create-user --user-name github-actions-lightsail

# プログラマティックアクセス用のアクセスキーを作成
aws iam create-access-key --user-name github-actions-lightsail

必要な権限を付与

以下のポリシーをユーザーにアタッチします：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "lightsail:*"
            ],
            "Resource": "*"
        }
    ]
}

ポリシーの作成とアタッチ：

# ポリシーファイルを作成
cat > lightsail-policy.json << EOF
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "lightsail:*"
            ],
            "Resource": "*"
        }
    ]
}
EOF

# ポリシーを作成
aws iam create-policy \
    --policy-name LightsailFullAccess \
    --policy-document file://lightsail-policy.json

# AWSアカウントIDを取得
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

# ユーザーにポリシーをアタッチ
aws iam attach-user-policy \
    --user-name github-actions-lightsail \
    --policy-arn arn:aws:iam::${ACCOUNT_ID}:policy/LightsailFullAccess

Lightsail Container Service の作成

ステージング環境の作成

# ステージング用コンテナサービスを作成
aws lightsail create-container-service \
    --region ap-northeast-1 \
    --service-name mysite-staging \
    --power nano \
    --scale 1

本番環境の作成

# 本番用コンテナサービスを作成
aws lightsail create-container-service \
    --region ap-northeast-1 \
    --service-name mysite-production \
    --power nano \
    --scale 1

サービス状態の確認

# サービス一覧を確認
aws lightsail get-container-services --region ap-northeast-1

# 特定のサービスの詳細を確認
aws lightsail get-container-service \
    --region ap-northeast-1 \
    --service-name mysite-staging

カスタムドメインの設定

SSL証明書の作成

# ステージング用SSL証明書
aws lightsail create-certificate \
    --region ap-northeast-1 \
    --certificate-name mysite-staging-cert \
    --domain-name staging.example.com

# 本番用SSL証明書
aws lightsail create-certificate \
    --region ap-northeast-1 \
    --certificate-name mysite-production-cert \
    --domain-name example.com

ドメインの検証

証明書作成後、DNS検証が必要です。出力されたCNAMEレコードをDNSに追加してください。

カスタムドメインの有効化

# ステージング環境にカスタムドメインを設定
aws lightsail attach-certificate-to-distribution \
    --region ap-northeast-1 \
    --certificate-name mysite-staging-cert

# 本番環境にカスタムドメインを設定
aws lightsail attach-certificate-to-distribution \
    --region ap-northeast-1 \
    --certificate-name mysite-production-cert

GitHub Secrets の設定

GitHubリポジトリのSettings > Secrets and variables > Actionsで以下のSecretsを設定してください：

AWS認証情報

AWS_ACCESS_KEY_ID: 作成したIAMユーザーのアクセスキーID
AWS_SECRET_ACCESS_KEY: 作成したIAMユーザーのシークレットアクセスキー

WordPress認証キー

generatorなどで作成したキーを設定します。

WORDPRESS_AUTH_KEY
WORDPRESS_SECURE_AUTH_KEY
WORDPRESS_LOGGED_IN_KEY
WORDPRESS_NONCE_KEY
WORDPRESS_AUTH_SALT
WORDPRESS_SECURE_AUTH_SALT
WORDPRESS_LOGGED_IN_SALT
WORDPRESS_NONCE_SALT

GitHub CLIを使用したSecrets登録

GitHub CLIを使用してコマンドラインからSecretsを登録できます：

# GitHub CLIのインストール（macOS）
brew install gh

# GitHub CLIのインストール（Ubuntu/Debian）
sudo apt install gh

# GitHubにログイン
gh auth login

# AWS認証情報を登録
gh secret set AWS_ACCESS_KEY_ID --body "your-access-key-id"
gh secret set AWS_SECRET_ACCESS_KEY --body "your-secret-access-key"

# WordPress認証キーを登録（.envファイルから）
gh secret set WORDPRESS_AUTH_KEY --body "$(grep WORDPRESS_AUTH_KEY .env | cut -d'=' -f2 | tr -d '"')"
gh secret set WORDPRESS_SECURE_AUTH_KEY --body "$(grep WORDPRESS_SECURE_AUTH_KEY .env | cut -d'=' -f2 | tr -d '"')"
gh secret set WORDPRESS_LOGGED_IN_KEY --body "$(grep WORDPRESS_LOGGED_IN_KEY .env | cut -d'=' -f2 | tr -d '"')"
gh secret set WORDPRESS_NONCE_KEY --body "$(grep WORDPRESS_NONCE_KEY .env | cut -d'=' -f2 | tr -d '"')"
gh secret set WORDPRESS_AUTH_SALT --body "$(grep WORDPRESS_AUTH_SALT .env | cut -d'=' -f2 | tr -d '"')"
gh secret set WORDPRESS_SECURE_AUTH_SALT --body "$(grep WORDPRESS_SECURE_AUTH_SALT .env | cut -d'=' -f2 | tr -d '"')"
gh secret set WORDPRESS_LOGGED_IN_SALT --body "$(grep WORDPRESS_LOGGED_IN_SALT .env | cut -d'=' -f2 | tr -d '"')"
gh secret set WORDPRESS_NONCE_SALT --body "$(grep WORDPRESS_NONCE_SALT .env | cut -d'=' -f2 | tr -d '"')"

# 登録されたSecretsの確認
gh secret list

DNS設定

Route53での設定

# ホストゾーンの作成（example.comが未作成の場合）
aws route53 create-hosted-zone \
    --name example.com \
    --caller-reference $(date +%s)

# Aレコードの作成（Lightsailのパブリックドメインを指定）
aws route53 change-resource-record-sets \
    --hosted-zone-id YOUR_HOSTED_ZONE_ID \
    --change-batch file://dns-records.json

外部DNSプロバイダーでの設定

Lightsailコンテナサービスのパブリックドメインを確認：

aws lightsail get-container-service \
    --region ap-northeast-1 \
    --service-name mysite-production \
    --query 'containerService.url'

このURLをCNAMEレコードとして設定してください。

既存IAMユーザーへの権限追加

既にIAMユーザーが作成済みで、Lightsailのみを追加したい場合：

cat > lightsail-policy.json << EOF
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "lightsail:*"
            ],
            "Resource": "*"
        }
    ]
}
EOF

# Lightsail権限ポリシーを作成
aws iam create-policy \
    --policy-name LightsailContainerAccess \
    --policy-document file://lightsail-policy.json

# AWSアカウントIDを取得
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

この環境が構築できれば、数クリックでスケールアウト可能な環境になります。

運用上のアドバイス

静的解析

PHP の syntax check や画像の圧縮、難読化をGitHub Actionsで行うことで面倒なことを自動化できます。

最適化をとことん突き詰めたい方は、WordPress のテーマファイルの中身をチェックし、JavaScript, CSS, の難読化や画像の圧縮を行えます。

Claude Codeの利用

Claude Code を利用すれば、GitHub issue で起票して、それを Claude Code で実装させ、pull request を作って、merge するといったことができます。軽微な修正であればこれでできます。

例：

日本語ファイル名はアップロードはすべきではない

macOS で Docker compose を使う場合、アップロードするファイル名はアルファベットにする必要があります。以下の記事で指摘されている問題にあたってしまって Docker container 上からファイルを参照できなくなります。

https://zenn.dev/hacobell_dev/articles/68ccc92bffd6cc

まとめ

WordPress をGitリポジトリで管理してスナップショットを保存できるようにし、Lightsail Containerにデプロイする方法を説明しました。

これにより、複雑でスナップショット管理ができなかったWordPressの運用を容易にし、スケールアウト可能なインフラを構築することが可能になりました。

特に以下の点がめちゃくちゃ便利です：

すべてファイルで管理できるので差分が明確
ロールバックが簡単
セキュリティリスクの大幅削減
モダンな開発フローでの運用

おまけ

実際にこの構成で運用してみて感じたのは、WordPress の運用がこんなに楽になるのか！　ということでした。特に複数環境での同期の煩わしさから解放されたのは大きいです。

将来的に PHP の Serverless が登場した際は低コストに運用できると思います。

月$7 という費用も、従来の WordPress 運用にかかる手間を考えるとコスパ使うべきではない言葉なので修正してくださいだと思います。ぜひ試してみてください！

引き続き、WordPress 周りの気になることを調査したり、実際の運用で得た知見も記事にしていきますので、良かったら ZennやTwitterのフォローをお願いします！　🙌

Google StitchとVercel v0の比較検証：同じプロンプトで生成結果を比べた

Tue, 27 May 2025 00:00:00 GMT

3秒まとめ

Google Stitchは Google が提供する AI 駆動の Web アプリ開発ツール
v0と比較して実際の出力を比較してみた
業務での実用性について率直に評価した結果をシェア
結論: 用途によっては v0 より優れている部分もあるが...

どんな人向けの記事？

v0を普段使っているフロントエンド開発者
AI開発ツールの比較検討をしている方
Google Stitchが実際どうなのか気になっている方

{/* ## サマリー /} {/ - 発表の目的 /} {/ - Google Stitchの使用感の共有 /} {/ - 概要 /} {/ - 同じプロンプトでGoogle Stitchとv0の出力を比較 /} {/ - 出力されたコードの評価 /} {/ - マインディアビジネスや業務への示唆・効果 /} {/ - ケースによってはv0より使える。 /} {/ - 開発者にとっては辛い。 */}

はじめに

Google は日本時間 5 月 21 日未明に開幕した年次イベント「Google I/O 2025」で、自然言語で指示を入力すると自動的に Web UI を生成するツール「Stitch」のベータ公開を発表しました。

私はふだんは v0 を愛用しているので、v0 より優れているのかが気になるところです。

ということで、実際に手を動かして両方のツールを同じタスクで比較検証してみることにしました！

いまなら Google Stitch は無料なので使いまくって使用感を確かめておくのがおすすめです。

デザイン力を調査してみる

0. はじめに

Google Stitch の設定で、Standard Mode から Experimental Mode に切り替えて使ってみます。 Standard Mode では Gemini 2.5 Flash で、Experimental Mode だと gemini 2.5 Pro になります。普段、Gemini 2.5 Pro を使っていますが、Flash に比べると格段に優秀なので。

また、Google Stitch の場合は Mobile/PC 向けの UI を最初に選択する必要があります。モバイル向けだと情報量が少ないので PC 向けに設定しておきます。

1. 定性調査のインタビュー画面

プロンプトは以下です。

定性調査のためのオンラインインタビューツールのUIを作ってください。

考える人によって機能やUIがかなり異なるので普通なら要求定義をちゃんとしていかないといけないような代物を投げつけてみます。

Google Stitch

Standard Modeでも一応試してみました。

考察

圧倒的にv0が良い。機能のアイデアも広げてくれる。

2. 調査票作成画面

アンケート調査の調査票を作成するUIを作ってください。
最終的には調査背景、調査目的、設問作成、回収数、ターゲットなどが出力されてほしいです。

Google Stitch

Standard Modeでもやってみましたが、人によってはこちらのほうが良いと思います。ただのUIだけではなくてサービスレベルで考えてくれて外部設計を作ってくれています。

考察

Google StitchのStandard Modeはサービスとしての外部設計を一通り作ってくれた感じです。工程で言えば、外部設計の第1段階という感じです。それに対してv0は出力が1画面しか出力できないのでヒアリングのフォームだけを作ってくれた感じです。

これは、圧倒的にGoogle Stitchが素晴らしいです。指示したこと以上に視野を広げてくれています。逆にv0は意図をあんまり汲み取れていないです。

3. 個人開発サービスの改善

プロンプト

以下のようなトライアスロンのリザルトを分析するサービスを提供しています。
もっと良いUIを作ってください。
https://ai-triathlon-result.teraren.com/archive/2025/tateyama_duathlon/athletes/athlete-459

Google Stitch

考察

どちらもありではあるが、オリジナルのUIからかなり情報が削られてしまっている。

4. Eコマースサイトのランディングページ

プロンプト

モダンなEコマースサイトのランディングページを作成してください。
- ヒーローセクション
- 商品一覧
- 特徴紹介
- お客様の声
- フッター
レスポンシブ対応で、アニメーションも含めてください。

Google Stitch

Google StitchはLPだけじゃなくて、他のページやコンポーネントも生成してきた。

コーディング力を調査してみる

このUIのコードを見てみる。

HTML/CSS出力

以下のようなコードが出力される。

クリックしてコードを表示:

<html><head>
<meta charset="utf-8"/>
<link crossorigin="" href="https://fonts.gstatic.com/" rel="preconnect"/>
<link as="style" href="https://fonts.googleapis.com/css2?display=swap&amp;family=Noto+Sans%3Awght%40400%3B500%3B700%3B900&amp;family=Plus+Jakarta+Sans%3Awght%40400%3B500%3B700%3B800" onload="this.rel='stylesheet'" rel="stylesheet"/>
<link href="https://fonts.googleapis.com/css2?family=Material+Symbols+Outlined:opsz,wght,FILL,GRAD@20..48,100..700,0..1,-50..200" rel="stylesheet"/>
<title>Stitch Design</title>
<link href="data:image/x-icon;base64," rel="icon" type="image/x-icon"/>
<script src="https://cdn.tailwindcss.com?plugins=forms,container-queries"></script>
<style type="text/tailwindcss">
  @layer base {
    :root {
    --primary-color: #0c77f2;
    --secondary-color: #e7edf4;
    --text-primary: #0d141c;
    --text-secondary: #49709c;
    --background-color: #f8fafc;}
    body {
    font-family: "Plus Jakarta Sans", "Noto Sans", sans-serif;
    color: var(--text-primary);
    }
    .icon-btn {
    @apply flex items-center justify-center size-10 rounded-lg bg-transparent text-slate-700 hover:bg-slate-200 transition-colors;
    }
  }
  .material-symbols-outlined {
    font-variation-settings:
    'FILL' 0,
    'wght' 400,
    'GRAD' 0,
    'opsz' 24
  }
  </style>
</head>
<body class="bg-background-color">
<div class="relative flex size-full min-h-screen flex-col group/design-root overflow-x-hidden">
<div class="layout-container flex h-full grow flex-col">
<header class="flex items-center justify-between whitespace-nowrap border-b border-solid border-slate-200 px-6 sm:px-10 py-4 bg-white shadow-sm">
<div class="flex items-center gap-6 lg:gap-10">
<div class="flex items-center gap-3 text-primary-color">
<div class="size-6 text-primary-color">
<svg fill="none" viewBox="0 0 48 48" xmlns="http://www.w3.org/2000/svg">
<path clip-rule="evenodd" d="M24 4H6V17.3333V30.6667H24V44H42V30.6667V17.3333H24V4Z" fill="currentColor" fill-rule="evenodd"></path>
</svg>
</div>
<h2 class="text-xl font-bold tracking-tighter">FashionForward</h2>
</div>
<nav class="hidden md:flex items-center gap-6 lg:gap-8">
<a class="text-slate-700 hover:text-primary-color text-sm font-medium transition-colors" href="#">New Arrivals</a>
<a class="text-slate-700 hover:text-primary-color text-sm font-medium transition-colors" href="#">Men</a>
<a class="text-slate-700 hover:text-primary-color text-sm font-medium transition-colors" href="#">Women</a>
<a class="text-slate-700 hover:text-primary-color text-sm font-medium transition-colors" href="#">Accessories</a>
<a class="text-slate-700 hover:text-primary-color text-sm font-medium transition-colors" href="#">Sale</a>
</nav>
</div>
<div class="flex items-center gap-3 sm:gap-4">
<label class="relative flex-col min-w-32 !h-10 max-w-sm hidden sm:flex">
<div class="flex w-full flex-1 items-stretch rounded-lg h-full bg-slate-100">
<div class="text-slate-500 flex items-center justify-center pl-3">
<span class="material-symbols-outlined text-xl">search</span>
</div>
<input class="form-input flex w-full min-w-0 flex-1 resize-none overflow-hidden rounded-lg text-slate-700 focus:outline-0 focus:ring-2 focus:ring-primary-color/50 border-none bg-transparent h-full placeholder:text-slate-500 px-3 text-sm font-normal" placeholder="Search products..." value=""/>
</div>
</label>
<div class="flex gap-1">
<button aria-label="Search Mobile" class="icon-btn" title="Search">
<span class="material-symbols-outlined sm:hidden">search</span>
</button>
<button aria-label="Wishlist" class="icon-btn" title="Wishlist">
<span class="material-symbols-outlined">favorite_border</span>
</button>
<button aria-label="Shopping Cart" class="icon-btn" title="Shopping Cart">
<span class="material-symbols-outlined">shopping_bag</span>
</button>
</div>
<button class="ml-2">
<div class="bg-center bg-no-repeat aspect-square bg-cover rounded-full size-10 border-2 border-slate-200 hover:border-primary-color transition-colors" style='background-image: url("https://lh3.googleusercontent.com/aida-public/AB6AXuARxqvbE3wZ7BIaNHTKx_ii3Y9WspWUS_9jGx99gtJp1W2z1Nfttx0F4Vm3--hQ3gsveZm2P7b71eW8CcE0FXQN9V3PL-02mUhbLpVWa39txa09v4ShBij9lSQwINXrq4DsEm-iMUmPjeKbJmbgCDF8pqy_RVTbmTpbxKZCQmTJZS99G4HgD84ngE0POGB6KaghByFat6svmGJ-NtoO_JpTH_pcuVydr24nv26fdiRHs90ywd0tExZ2g5UvPhSWWjdL_xAGTuvcvS4");'></div>
</button>
</div>
</header>
<main class="flex flex-1 justify-center items-center px-4 sm:px-6 lg:px-8 py-10 sm:py-16">
<div class="w-full max-w-6xl">
<div class="@container">
<div class="relative overflow-hidden rounded-xl shadow-2xl">
<div class="absolute inset-0 bg-cover bg-center bg-no-repeat" style='background-image: url("https://lh3.googleusercontent.com/aida-public/AB6AXuC_tkVGaCvcqLyJ3y2pXrW3CWvUZwaElnVoR1hZjy5cB8DH3vGd4fHeGByomZUXIj5KKwQI6wYZtpoulARXzVXPGymX5wGUf-MKxD7VxTg7sbhg6QXDjr4RehcAXr8J8HiknnBARLA-TJLS2ZZ1jsKm7lhPjf0e7SMb5P2bGmMxwYLAAR_528_a7ytnJGEFOM-1Xqq8msmo-9R8I6EgotmaDAfEMOZVjFusFW8U3mcnapudWqO8sqsGKb8qTRTeIeRSqWhvlm_plBs");'>
<div class="absolute inset-0 bg-gradient-to-t from-black/70 via-black/40 to-black/10"></div>
</div>
<div class="relative flex min-h-[500px] sm:min-h-[600px] flex-col gap-6 items-center justify-center text-center p-6 sm:p-12 @[640px]:items-start @[640px]:text-left @[640px]:w-3/5 @[1024px]:w-1/2">
<div class="flex flex-col gap-4">
<h1 class="text-white text-4xl sm:text-5xl lg:text-6xl font-extrabold leading-tight tracking-tight">
          Step into Style
          </h1>
<p class="text-slate-200 text-base sm:text-lg lg:text-xl font-normal leading-relaxed max-w-md @[640px]:max-w-none">
          Discover the latest trends and timeless classics in our curated collection. Elevate your wardrobe with pieces that speak to your unique style.
          </p>
</div>
<a class="flex min-w-[120px] max-w-[280px] cursor-pointer items-center justify-center overflow-hidden rounded-lg h-12 px-6 sm:h-14 sm:px-8 bg-primary-color text-white text-base sm:text-lg font-bold leading-normal tracking-wide shadow-md hover:bg-blue-600 transition-all duration-300 ease-in-out transform hover:scale-105 focus:outline-none focus:ring-4 focus:ring-primary-color/50" href="#">
<span class="truncate">Shop Now</span>
<span class="material-symbols-outlined ml-2">arrow_forward</span>
</a>
</div>
</div>
</div>
</div>
</main>
</div>
</div>

</body></html>

実際に開発に使うために React に変換して使ってみます。 Visual Studio Code + Cline が適していると思うので HTML/CSS のコードを React にしてもらいつつ、リポジトリの初期設定をしてもらうようにプロンプトで指示しました。

時間は 5 分ぐらいかかり、$0.4443 かかりました。

コンポーネントを良い感じに分割して作ってくれました。

動きました。

Figmaに出力してコードを生成

Google Stitch から Figma に出力できます。Figma からコードを生成できるので試してみたいと思います。 (現時点で、Google Chrome を使わないとできないです。Brave の最新では対応していませんでした。)

Figma にコピーすると以下のような感じでコンポーネントが作られています。

Figma to HTMLプラグインを使ってReactのコードを出力してみます。

しかしながら、以下のダイアログが出たので Convert ボタンを押してもファイルがダウンロードされませんでした。ブラウザの Developer Tool を見るとエラーが起きてました。

Figma to HTML の最終更新日が 2 年以上前であり、プラグインのコメント欄にも「使えない！」というコメントの嵐なのでなので現在は使えないようです。

課金して Locofy を使うなどしか無さそうです。Figma からソースコードへの変換は厳しそうです。

もし Figma 経由で HTML コードを生成できるならばサービスの外部設計時に、以下のワークフローでも使えそうだなと思いましたが現状は無理そうです。

Google Stitch を何回も実行
=> Figma に蓄積。
=> コンポーネントなどを整理。
=> Figma to HTML で React のコードを一気に生成。

評価

v0との機能比較

実際に使ってみて感じた両ツールの比較を表にまとめてみました：

項目	Google Stitch	v0
ベースフレームワーク	HTML/CSS	React/Next.js
デザインクオリティ	シンプル・実用的	モダン・洗練
料金	無料（制限あり）	有料プラン推奨
マルチモーダル	Standard 非対応/Experimental対応	対応
エコシステム	Figma	Vercel/GitHub

比較結果

項目	Google Stitch	v0
サービス全体設計	★★★★	★★
デザイン品質	★★	★★★★★
コード品質	★	★★★★
実装速度	★★★	★★★
カスタマイズ性	★	★★★★★

考察

使用感
- Google Stitch
  - 外部設計。UI デザインを作るというイメージ。ページのフローも生成してくれる。全体の外部設計。
  - より抽象的な指示で全体最適ができそう。
  - 初回プロンプトを入力した後に絶対に確認が入ってから実行される。必ず Plan して Act する流れ。
  - 最大 6 画面の生成。
- v0
  - ページを作る感じ。React のコードがアウトプット出でてくる。
  - ミクロな感じ。SPA に良い。
  - 作った UI がすぐに Deploy できるのでデモできちゃう。フロントエンドはほとんどこれで完成させられる。

現時点でのポジショニングはこんな感じになると思います。

まとめ

実際に両方のツールを使ってみた結果、どちらも素晴らしいツールだということがわかりました！

Google Stitchは、特にプロトタイプ作成や小規模プロジェクトでは有効だと感じました。一方で、v0はデザイン品質と開発体験において一歩リードしており、エンジニア向けという感じがしました。

また、vercel には様々な SDK が提供されているので v0 で作ったフロントエンドに対して簡単にバックエンドを統合できる状態になっているという利点は大きいです。Google の既存アセットである Google Cloud を使って同じようなことをしてきたらとても強力かと思いますがそこを攻めてくるかどうかはわかりません。例えば Stitch で UI を作って、クリック 1 発で Cloud Run にデプロイといったこと。

個人的には、用途に応じて使い分けるのがベストだと考えています：

アイデア検証段階、サービス設計段階: Google Stitch
本格開発段階: v0

みなさんも実際に両方試してみて、自分のプロジェクトに最適なツールを見つけてみてくださいね！

日本郵便のデジタルアドレス：7桁コードで届く仕組みの可能性と限界

Mon, 26 May 2025 00:00:00 GMT

3秒まとめ

デジタルアドレスは日本郵便が提供する 7 桁のランダムな英数字で住所にマッピングする仕組み
個人・法人利用ではデジタルアドレスと住所保持した場合、どちらが本当の住所なのかを明確にして保管する必要がある。
API 利用は簡単だが、普及には多くのセキュリティの課題やユースケース上の問題があるので広く取り入れられることは難しそう。

どんな人向けの記事？

デジタルアドレスって何？　と思っている方
日本郵便のAPIを使ってみたい開発者の方
住所管理の新しい仕組みに興味がある方

はじめに

最近、住所もデジタル化の波が来てるんですね！　日本郵便が提供する「デジタルアドレス」って聞いたことありますか？物理的な住所に代わる新しい識別子として注目されているんです。

この記事では、日本郵便が提供する「郵便番号・デジタルアドレス for Biz API」を実際に触ってみて、デジタルアドレスの概要、API の使い方、そして正直なところの利便性と課題について、私なりにまとめてみました！

1. デジタルアドレスって何？

デジタルアドレスとは一体何でしょうか？　めちゃくちゃシンプルに言うと、ゆうID利用者が登録した住所を置き換えた、ランダムな英数字7桁の文字列なんです！　例えば A7E2FK2 みたいな感じですね。

これって、既存の住所システムと比較すると、大口事業所個別番号の空間を拡張したものとして理解するのが良さそうです。つまり、今まであった仕組みをベースに、もっと多くの住所に対応できるように名前空間を広げたって感じですね。

7 桁の英数字ということは、 アドレス空間は2^35（約340億通り） もあるので、十分すぎるほどの容量があります！　分かりづらい文字（0 と O など）は除外されている可能性もありますが、それでも相当な数のアドレスを生成できそうです。

デジタルアドレスの特徴

デジタルアドレスには、以下の特徴があります。

個人・法人がデジタルアドレスの発行が可能：住所からデジタルアドレスの作成ができます。
正引きが可能：デジタルアドレスから住所の取得ができます。
API経由でアクセス可能：API 登録すればデジタルアドレスから住所を取得できます
ユーザーが管理可能：デジタルアドレスの関連付けを作成したユーザーが、削除や変更をできます
匿名性の解決はしていない：デジタルアドレスから住所を簡単に求められるので、フリマなどで広まりつつある匿名配送のユースケースには使えません。

ただし、この「API 経由で住所検索が可能」という特性は、後で説明する運用管理とセキュリティや使い勝手が悪くなる理由になり、重要なポイントになってきます。

2. APIを使ってみよう！

デジタルアドレスの情報は、「郵便番号・デジタルアドレス for Biz API」を通じて取得できます。このAPIは、デジタルアドレスの名前解決だけではなくて7桁の郵便番号の解決もしてくれるのでめちゃくちゃ便利です！なぜなら、郵便番号から住所を補完する際は、このAPIを使っておけば郵便番号からの住所の補完だけでなく、デジタルアドレスからの住所の補完が行えます！

提供される機能には、トークン発行や、デジタルアドレス、郵便番号、事業所個別郵便番号の検索などがあります。API の仕様は OpenAPI Specification で書かれているので開発者にとっては馴染みやすいと思います。

API利用開始までのステップ

API を使い始めるまでの手順はけっこうシンプルです。

ゆうIDで認証：まず有効なゆう ID が必要です
利用者登録：ゆう ID の会員登録後、本サイト上でゆう ID で認証し、利用者登録をします
API認証キーの発行：利用者登録が完了し、本サービスの利用が承認されると、ダッシュボードから API 認証キー（クライアント ID、シークレットキー）を発行できます

API 認証キーは、ダッシュボードでサクッと発行・再発行できます。このキーをリクエストに含めることで、サービスを利用できるようになります！

提供される主なAPI

「郵便番号・デジタルアドレス for Biz API」で提供される主な API は以下の通りです。

searchcode API: 郵便番号、事業所個別郵便番号、デジタルアドレスからの共通検索を行うエンドポイントです。いずれかのコードを指定して検索すると、住所情報が返されます。テスト用 API では、テスト用のデジタルアドレス 3 種と東京都千代田区の郵便番号、事業所個別郵便番号の検索が可能です。
addresszip API: 住所の一部を用いて郵便番号や住所情報を検索する API です。テスト用 API では東京都千代田区に対してのみ検索が可能です。
token API: API 利用に必要なトークン（JWT 形式）を取得する API です。OAuth2.0 の client_credentials に基づいており、クライアント ID とシークレットキーを指定してリクエストします。

API 利用においては、利用範囲・仕様、アクセス回数、アクセス時間、情報更新頻度、送信データ容量などに制約が設けられる場合があります。ダッシュボードに掲載される最新の利用ガイドを参照することが推奨されています。

APIの仕様に関する注意点

実際に API を使ってみて気づいた点がいくつかあります：

送信元IPアドレスの登録: API 利用時に送信元 IP アドレスの入力が必須になっていますが、実際にはその IP アドレス以外からでもアクセス可能でした。システム上での制約は特にないようです
IPv4のみ対応: 送信元 IP アドレスは IPv4 のみ指定可能で、ネットワークアドレスの指定や IPv6 には対応していません
x-forwarded-forヘッダー: API ドキュメントでは必須とされていますが、実際には指定しなくても正常にレスポンスが返ってきます
本番APIのホスト名: この記事ではテスト用 API（stub-qz73x.da.pf.japanpost.jp）を使用していますが、本番環境の API ホスト名は OpenAPI の仕様書に記載されています。(エンドポイント URL を展開すると見られる)

これらの点は、実際の運用時に知っておくと便利だと思います！

API呼び出し例とレスポンス

API を利用する際には、まず token API でトークンを取得し、そのトークンを Authorization ヘッダーに含めて他の API を呼び出します。

API利用トークン取得例

テスト用 API 認証情報として提供されているクライアント ID Biz_DaPfJapanpost_MockAPI_j3QKS とシークレットキー uXuN0ejHG7nAn89Afxxxxx を使用してトークンを取得する cURL コマンドの例です。

curl -X POST "https://stub-qz73x.da.pf.japanpost.jp/api/v1/j/token" \
-H "Content-Type: application/json" \
-H "x-forwarded-for: 192.0.2.0" \ # 送信元IPアドレスは必須
-d '{
  "grant_type": "client_credentials",
  "client_id": "Biz_DaPfJapanpost_MockAPI_xxxxx", # テスト用クライアントID
  "secret_key": "uXuN0ejHG7nAn89Afxxxxx" # テスト用シークレットキー
}'

成功すると、JWT形式のアクセストークンを含むレスポンスが返されます。このトークンを Bearer スキームで使用します。

{
  "scope": "J1",
  "token_type": "Bearer",
  "expires_in": 123456,
  "token": "{アクセストークン}" # ここに実際のトークンが入る
}

searchcode APIでの検索例

取得したトークンを使用してsearchcode APIを呼び出します。

デジタルアドレスにハイフンが含まれている場合（誤った形式）

テスト用デジタルアドレス A7E-2FK2 をハイフン付きで検索した場合の例です。

curl -X GET "https://stub-qz73x.da.pf.japanpost.jp/api/v1/searchcode/A7E-2FK2" \
-H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..." # 取得したトークンを指定

この場合、エラーが返されます。

{"request_id":"e6219453-ce21-45df-8369-8c9bf5411111","error_code":"400-1029-0002","message":"デジアドの形式が正しくありません"}

メッセージは「デジアドの形式が正しくありません」となっており、ハイフンは不要であることがわかります。

デジタルアドレスにハイフンがない場合（正しい形式）

テスト用デジタルアドレス A7E2FK2 をハイフンなしで検索した場合の例です。

curl -X GET "https://stub-qz73x.da.pf.japanpost.jp/api/v1/searchcode/A7E2FK2" \
-H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..." # 取得したトークンを指定

成功すると、紐づく住所情報を含むレスポンスが返されます。

{
  "page": 1,
  "limit": 1000,
  "count": 1,
  "searchtype": "dgacode",
  "addresses": [
    {
      "dgacode": "A7E2FK2",
      "zip_code": "100-0005",
      "pref_code": "13",
      "pref_name": "東京都",
      "pref_kana": null,
      "pref_roma": null,
      "city_code": "13101",
      "city_name": "千代田区",
      "city_kana": null,
      "city_roma": null,
      "town_name": "丸の内",
      "town_kana": null,
      "town_roma": null,
      "biz_name": null,
      "biz_kana": null,
      "biz_roma": null,
      "block_name": "２丁目７−２",
      "other_name": "部屋番号：サンプル１",
      "address": "東京都千代田区丸の内２丁目７−２部屋番号：サンプル１",
      "longitude": null,
      "latitude": null
    }
  ]
}

このレスポンスから、テスト用デジタルアドレス A7E2FK2 は、東京都千代田区丸の内２丁目７−２部屋番号：サンプル１に紐づいていることがわかります。

該当するデジタルアドレスが存在しない場合

存在しないデジタルアドレスで検索した場合の例です。

curl -X GET "https://stub-qz73x.da.pf.japanpost.jp/api/v1/searchcode/XXXXXXX" \
-H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..." # 取得したトークンを指定

この場合、404 Not Foundエラーが返されます。

{"request_id":"105f833a-4982-47b9-9f61-a564dcf5d846","error_code":"404-1029-0001","message":"該当するデジアドがありませんでした"}

メッセージは「該当するデジアドがありませんでした」となっています。

addresszip APIでの検索例

addresszip APIはPOSTメソッドでリクエストボディに検索条件を指定します。テスト用APIでは東京都千代田区に対してのみ検索可能です。

curl -X POST "https://stub-qz73x.da.pf.japanpost.jp/api/v1/addresszip" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..." \ # 取得したトークンを指定
-d '{
  "pref_code": "13", # 都道府県コードを指定
  "city_code": "13101", # 市区町村コードを指定
  "page": 1,
  "limit": 1000 # 取得最大レコード数。デフォルト1000
}'

成功すると、指定した条件にマッチする住所情報や郵便番号を含むレスポンスが返されます。レスポンスにはマッチングレベルも含まれます。

{
  "addresses": [
    ... # 該当する住所情報がリストで含まれる
  ],
  "level": 2, # マッチングレベル
  "limit": 1000,
  "count": 1,
  "page": 1
}

この例では、都道府県コードと市区町村コードで検索しているため、マッチングレベルは 2（市区町村レベルで一致）となることが想定されます。

3. 正直なところ、どうなの？（考察）

デジタルアドレスって物理的な住所の代替として期待されてるんですが、実際に調べてみると利便性と課題の両面が見えてきました。

セキュリティ面での気になるポイント

一番気になったのは、匿名性の課題ですね。デジタルアドレスと住所の紐づけ自体は公開されていませんが、API登録すれば誰でもデジタルアドレスから住所を検索できるんです。

つまり、第三者に匿名性を確保したいからデジタルアドレスを教えても、実際には住所を教えたのと同じことになってしまいます。

また、デジタルアドレスがランダムな文字列とはいえ、総当たり攻撃（ブルートフォースアタック）に対して脆弱という問題もあります。総当たり攻撃への対策については、現在のところAPIの利用規約でNGとしている程度で、技術的な対策がどの程度講じられているかは、私が調べた範囲では読み取れませんでした。

利用規約では、API認証キーは自己の費用と責任において厳重に管理する必要があると明記されており、管理不備や不正使用による損害はユーザーが一切の責任を負うとしています。また、API で取得した情報は、デジタルアドレスを作成したユーザーの同意なしに外部へ公開してはならないという重要な注意点もあります。

実際のユースケースってどうなの？

個人レベルでは EC サイトで買い物する際に住所補完に使える可能性がありますね。例えば、Web サイトの入力フォームでデジタルアドレスを入力すると、パパっと住所が入力されるような機能です。

でも、これが普及するためには、どれくらいのサイトが対応してくれるか、そしてブラウザ自体がデジタルアドレスの補完に対応するかが疑問なんですよね。もし単なる住所補完のユースケースだけであれば、ブラウザの機能である程度は要求を満たせてしまうかもしれません。

法人（企業）がデジタルアドレスを利用する場合、物理住所とデジタルアドレスの両方を管理する必要が生じて、めちゃくちゃ大変になる可能性があります。

また、デジタルアドレスは作成したユーザーが削除や変更をできるので、もしデジタルアドレスだけを ID として持っていると、ユーザーがデジタルアドレスを削除した場合に困ることになります。そのため、住所の ID としてデジタルアドレスのみを使用するのは難しそうです。

これらの点から、正直なところ、デジタルアドレスを普及させることによるメリットがあまり多くないと感じる人もいるかもしれません。一方で、法人のユースケースにおいては、正引き機能があることはなかなか良い点だと思います！

利用規約から見る重要な注意点

「郵便番号・デジタルアドレス for Biz 利用規約」には、API 利用者（ユーザー）が遵守すべき重要な事項が多数記載されています。特に注意すべき点をいくつか挙げます。

エンドユーザーから取得したデジタルアドレス等の情報管理責任：ユーザーは、エンドユーザーから取得・収集したデジタルアドレス及び登録住所に関する情報を自己の費用と責任において厳重に管理する責任を負います。管理不備、使用上の過誤、第三者の不正使用等による損害は全てユーザーの責任となります。
同意なき第三者への開示・提供の禁止：エンドユーザーから取得したデジタルアドレス等について、デジタルアドレスにより特定される本人の同意のない限り、ユーザーアプリケーションの利用に必要な範囲を超えて、第三者への開示、貸与、売買等を行うことはできません。API で取得した情報をデジタルアドレスを作成したユーザーの同意なしに外部へ公開してはならない、という点は特に重要です。
API認証キーの厳重管理：API 認証キー（クライアント ID 及びシークレットキー）は、自己の費用と責任において厳重に管理する必要があり、管理不備や第三者の不正使用等による損害はユーザーが一切の責任を負います。業務委託関係のない第三者への開示、譲渡、使用させることは禁止されています。
当社による無保証と責任の限定：当社（日本郵便株式会社）は、本サービスの提供に関していかなる種類の保証も行いません。サービスの継続性、タイムリーな提供、エラーの有無、情報の有益性・正確性・信頼性、特定の目的への適合性などについて一切保証していません。また、ユーザーによる本サービスの利用に起因する損害、通信障害やシステム障害による不具合や損害、コンピューター・ウィルスなどによる損害、サービスの遅延・変更・中断・中止・廃止などに関し、一切の責任を負わないと明記されています。
禁止事項：利用規約には、API のリバースエンジニアリング、許可なきスクレイピングやクローリング、サービスへの過剰な負荷、競合または競合するおそれのあるサービスの提供など、多数の禁止事項が定められています。これらの禁止事項に違反した場合、サービスの利用停止や利用許諾の取り消しが行われる可能性があり、それによりユーザーに生じた不利益や損害について当社は一切責任を負いません。
個人情報の取扱い：本サービスで取り扱う個人情報（登録情報やエンドユーザーの個人情報）は、プライバシーポリシー等及び本規約に従って取り扱われます。リクエストされたデジタルアドレスに対応する登録住所の提供は、当社において本人の同意に基づく個人データの第三者提供として行われ、ユーザーが提供された登録住所を個人データとして取得する場合には、個人情報保護法に基づき適切な管理措置を講じる責任があります。

これらの利用規約の内容は、API を利用してサービスを開発・提供するユーザーにとって非常に重要です。

まとめ

この記事では、日本郵便が提供するデジタルアドレスについて、実際にAPIを触りながら調べてみました！

デジタルアドレスは7桁のランダムな英数字文字列で住所を置き換える仕組みで、大口事業所個別番号の空間を拡張したと考えると簡単に理解できます。

ただし、利用規約にはけっこう厳しい管理責任や個人情報保護、禁止事項などが詳細に定められているので、利用者はこれらをしっかり守る必要があります。

正直なところの課題として、以下のような点が気になりました：

総当たり攻撃への脆弱性や情報漏洩リスク
普及には多くのサイト対応とブラウザ対応が必要
法人では物理住所との二重管理が負担になる可能性

デジタルアドレスが今後どのように活用され、普及していくのか、そのメリットが明確になって、利便性とセキュリティのバランスが取れるかが鍵になりそうですね！

おまけ

デジタルアドレスについて調べてみて、新しい技術の導入って本当に難しいなと改めて思いました。技術的には面白いアプローチだと思うんですが、実際の普及を考えるとエコシステム全体での対応が必要になってくるんですよね。

実は、私が運営しているポストくんで、デジタルアドレスの付随機能を提供しようと思って検討してみたんです。でも、利用規約を詳しく読んでみると、便利なサービスを提供するのは無理そうでした。単純に、APIの問い合わせに対してデジタルアドレスの正引きをproxyするような感じにすればすでにポストくんを利用してくれているユーザにはシームレスにサービス提供をできそうな気はします。

JCOM CATVインターネット回線ベンチマーク

Thu, 22 May 2025 00:00:00 GMT

テスト結果のCSVファイル

speed-results-1747917845 ダウンロード

考察

ダウンは200Mbpsという話だったけど帯域は太そう。latencyが22msもかかっていて辛いなぁ。。。

uplinkが10Mbpsしか出なくて辛すぎる。

貸与されたルーターはWiFi AP内蔵なのだが、OFFにできない。。。そして、ノイズが結構うるさい。

貸与されたルーターの機種: KCM3101

ThinkPad X1 Carbon CMOSバッテリー交換

Thu, 22 May 2025 00:00:00 GMT

3秒まとめ

ThinkPad X1 Carbonの CMOS バッテリー（時計用電池）が切れると起動時にエラーが出る
CR2016電池（100 円）を使って自分で修理可能！　サードパーティ部品（800 円）より7倍お得
スポット溶接機があれば 8.5 台以上で元が取れる計算

どんな人向けの記事？

ThinkPad X1 Carbon で起動時にエラーが出て困っている方
DIY修理に興味があるけど、初心者で不安な方
コストを抑えて修理したい方
複数台の ThinkPad を所有している方

背景

ぼくは Thinkpad X1 Carbon を多数所有しています。なぜかって？中古で安く手に入るからです😉

でも在庫として置いておくと、ある問題が発生するんです..。

問題：CMOSバッテリーが切れるとどうなる？

長期間使わずに在庫していると、CMOSバッテリーが消耗してしまいます。

CMOSバッテリーとは？ PC の時計や基本設定を記憶しておくための小さな電池です。これが切れると、電源を切るたびに時間がリセットされたり、BIOS 設定が初期化されてしまいます。 </div>

具体的には、PC 起動時に以下のようなエラーメッセージがBIOS起動時に表示されます。

Error 0271: Check Date and Time settings. Cannot modify Date/Time in BIOS

「あー、また時間設定がおかしくなってる...」 って経験、ありませんか？

解決方法：2つのアプローチ

方法1：サードパーティ製部品を購入（簡単だけど高い）

Amazon でサードパーティー製の部品を購入すれば800円程度で入手可能です。 メリット： 簡単、確実 デメリット： 複数台だとコストがかさむ

方法2：CR2016電池を加工して交換（今回の方法）

電池単体（CR2016）を購入し、若干の加工を施すことで修理できます。CR2016 電池は1個100円程度です。

メリット： 圧倒的に安い（約 1/8 のコスト！）。 デメリット： 少し手間がかかる

多数の機材を所有している場合、電池のみを購入して加工・交換する方がめちゃくちゃお得です。必要な資材もそれほど多くありません。

安全に作業するために

作業前に静電気を逃がす（金属部分に触れる）
電源を完全に切ってバッテリーも外す
ショートしないよう金属同士が触れないよう注意 </div>

必要な工具・材料

基本工具

精密ドライバー（プラスドライバー）
ラジオペンチまたはカッター、スクレイパー
CR2016電池（コンビニでも買えます！）

本格的にやるなら（8.5台以上修理する場合）

所要時間： 初回は 30 分程度、慣れれば 10 分程度

交換手順（ステップバイステップ）

ステップ1：分解開始

PC を裏返し、精密ドライバーでネジを外します。 「あれ、ネジが小さくて見えない...」 って思った方、大丈夫です。慣れれば簡単です😉

ステップ2：バッテリー位置の確認

バッテリーを手前に向けます。 ここがポイント： バッテリーの向きを間違えないよう注意！

ステップ3：CMOSバッテリーを発見

バッテリーに付いている精密ネジを外します。コネクタを付けたまま、バッテリーをひっくり返すと... おお！ リチウムイオンバッテリーの裏側に CR2016 バッテリーが隠れています。

ステップ4：保護材の確認

今回は黄色い絶縁ビニールで覆われていますね。機種によっては熱圧縮チューブの場合もあります。 「なんか複雑そう...」 と思うかもしれませんが、実は単純な構造です。

ステップ5：古い電池を取り外し

コネクタから電池を取り外します。 注意： 無理に引っ張らず、ゆっくりと外しましょう。

ステップ6：被覆を剥がす

絶縁ビニールの被覆を剥がします。 ここで重要： 中の金属端子を傷つけないよう慎重に！

ステップ7：スポット溶接部分の除去

スポット溶接されている箇所をラジオペンチやカッター、スクレイパーなどで取り外します。 初心者の方へ： 力を入れすぎず、少しずつ剥がしていくのがコツです。

ステップ8：絶縁材の確認

CR2016 の周囲に絶縁用のビニールが巻かれている場合もあります。これも再利用できるので、大切に保管しておきましょう。

ステップ9：新しい電池の取り付け（重要！）

接点をきれいに剥がせたら、平らにして再利用します。

超重要な注意点

ボタン電池は側面もプラス極になっています
ステンレスが触れないように注意
ショートしないよう、接点をわずかに折り曲げる工夫を </div>

スポット溶接機を使って新しいCR2016を取り付けます。

ステップ10：絶縁処理

太めのコルゲートチューブを巻き、ヒートガンで温めて圧着します。 「プロっぽい仕上がりになった！」 って思える瞬間です😊

ステップ11：動作確認

バッテリーをねじ止めし、起動してエラーが出なければ交換完了です！最後に本締めして終わり。

「Error 0271が出なくなった！」 って瞬間は、めちゃくちゃ嬉しいですよ🎉

コスト計算とまとめ

費用対効果の検証

1台あたりのコスト比較

サードパーティ部品：800 円
CR2016 電池のみ：100 円
節約額：700円/台

スポット溶接機を購入する場合

スポット溶接機：約 6,000 円
損益分岐点：6,000 円 ÷ 700 円 = 8.5台

つまり、8.5台以上交換する予定があるなら、スポット溶接機を購入した方がお得になります。

実際にやってみた感想

正直、最初は**「うまくいくかな...」** って不安でした。でも実際にやってみると、思ったより簡単！

特に複数台持ってる方にはめちゃくちゃオススメです。コストも抑えられるし、なにより DIY 修理の達成感がたまりません😉

最後に

ThinkPad の CMOS バッテリー交換、いかがでしたか？

「自分でも修理できそう！」 って思ってもらえたら嬉しいです。最初は緊張するかもしれませんが、慣れればサクッとできるようになりますよ。

ぜひチャレンジしてみてくださいね！　もし分からないことがあれば、気軽に質問してください🙌

参考リンク https://amzn.to/4jeoPnk

WordPressテーマのCI/CDをGitHub Actionsで構築する(Minifyを追加)

Thu, 22 May 2025 00:00:00 GMT

はじめに

このブログ記事では、WordPress テーマの CI/CD に、画像の最適化、JavaScript と CSS の minify 処理を追加する方法について解説します。

対象読者

WordPress テーマの CI/CD に興味がある方
GitHub Actions を使って WordPress テーマの CI/CD を構築したい方
WordPress テーマのパフォーマンスを改善したい方

前提知識

WordPress の基本的な知識
CI/CD の基本的な知識
GitHub Actions の基本的な知識

CI/CDとは

CI/CD（継続的インテグレーション/継続的デリバリー）とは、ソフトウェア開発における変更をより頻繁かつ確実にリリースするためのプラクティスです。

Minifyとは

Minify とは、JavaScript や CSS などのファイルのサイズを小さくする処理のことです。具体的には、コメントや空白文字を削除したり、変数名を短くしたりします。

Minifyを行うメリット

ファイルサイズが小さくなるため、Web サイトの表示速度が向上する。
ファイルサイズが小さくなるため、サーバーの負荷が軽減される。
ファイルサイズが小さくなるため、ユーザーのデータ通信量を削減できる。

今回は、Deploy する際に画像の最適化や CSS の minify と言った webpack が普通は行うようなビルドを少し取り入れます。

設定

jpg, pngファイルを圧縮するカスタムアクション。

このアクションは、pngquant と jpegoptim を使って、リポジトリ内の PNG と JPG 画像を最適化します。

pngquant: PNG 画像を非可逆圧縮するツールです。
jpegoptim: JPG 画像を非可逆圧縮するツールです。

.github/actions/optimize-image/action.yml

name: 'Optimize Images with Pngquant & Jpegoptim'
description: 'Finds and optimizes PNG and JPG images in the repository using pngquant and jpegoptim.'

inputs:
  png_quality:
    description: 'Quality range for pngquant (e.g., 65-80)'
    required: false
    default: '65-80'
  jpeg_quality:
    description: 'Quality for jpegoptim (0-100, lower is smaller file, more loss)'
    required: false
    default: '80' # jpegoptim のデフォルト品質
  strip_metadata:
    description: 'Remove all metadata (EXIF, comments, etc.) from JPEGs (true/false)'
    required: false
    default: 'true'

outputs:
  optimized_png_count:
    description: 'Number of PNG images that were optimized.'
    value: ${{ steps.optimize_png.outputs.optimized_count }}
  optimized_jpg_count:
    description: 'Number of JPG images that were optimized.'
    value: ${{ steps.optimize_jpg.outputs.optimized_count }}

runs:
  using: "composite"
  steps:
    - name: Install image optimization tools
      run: |
        sudo apt-get update
        sudo apt-get install -y pngquant jpegoptim
      shell: bash

    - name: Find and optimize PNG images
      id: optimize_png # IDを明確に
      run: |
        optimized_count=0
        
        find . -type f -name "*.png" -print0 | while IFS= read -r -d $'\0' file; do
          original_size=$(stat -c %s "$file")
          pngquant --quality=${{ inputs.png_quality }} --force --ext .png "$file"
          optimized_size=$(stat -c %s "$file")
          
          if [ "$original_size" -ne "$optimized_size" ]; then
            echo "Optimized PNG: $file (Original: $original_size bytes, Optimized: $optimized_size bytes)"
            optimized_count=$((optimized_count + 1))
          else
            echo "Skipped PNG (no change): $file"
          fi
        done
        
        echo "optimized_count=$optimized_count" >> $GITHUB_OUTPUT
      shell: bash

    - name: Find and optimize JPG images
      id: optimize_jpg # IDを明確に
      run: |
        optimized_count=0
        
        find . -type f -iregex ".*\.jpe?g$" -print0 | while IFS= read -r -d $'\0' file; do
          original_size=$(stat -c %s "$file")
          
          # jpegoptimのオプションを動的に設定
          JPEGOPTIM_OPTIONS="--max=${{ inputs.jpeg_quality }}"
          if [ "${{ inputs.strip_metadata }}" == "true" ]; then
            JPEGOPTIM_OPTIONS+=" --strip-all"
          fi
          
          jpegoptim $JPEGOPTIM_OPTIONS "$file"
          
          optimized_size=$(stat -c %s "$file")
          
          if [ "$original_size" -ne "$optimized_size" ]; then
            echo "Optimized JPG: $file (Original: $original_size bytes, Optimized: $optimized_size bytes)"
            optimized_count=$((optimized_count + 1))
          else
            echo "Skipped JPG (no change): $file"
          fi
        done
        
        echo "optimized_count=$optimized_count" >> $GITHUB_OUTPUT
      shell: bash

JavaScriptのminify

このアクションは、Terserを使って、JavaScriptファイルをminify（難読化）します。

Terser: JavaScriptファイルをminify（難読化）するツールです。

.github/actions/optimize-js/action.yml

name: 'Uglify JavaScript with Terser'
description: 'Finds and minifies/uglifies JavaScript files using Terser.'

inputs:
  paths:
    description: 'Glob pattern for JavaScript files to process (e.g., "**/*.js").'
    required: false
    default: '**/*.js'
  terser_options:
    description: 'JSON string of Terser minify options (e.g., {"compress":{},"mangle":true})'
    required: false
    default: '{"compress":true,"mangle":true}' # デフォルトは圧縮と変数名の難読化

outputs:
  uglified_count:
    description: 'Number of JavaScript files that were uglified/minified.'
    value: ${{ steps.uglify.outputs.uglified_count }}

runs:
  using: "composite"
  steps:
    - name: Set up Node.js
      uses: actions/setup-node@v4
      with:
        node-version: '20' # Terserの実行に必要なNode.jsのバージョン

    - name: Install Terser
      run: npm install -g terser # terserをグローバルインストール
      shell: bash

    - name: Find and uglify JavaScript files
      id: uglify
      run: |
        uglified_count=0
        
        # globパターンを配列として扱うための準備
        # find . -name "*.js" よりも柔軟な指定が可能
        
        # shopt -s globstar はワイルドカードを拡張する（bashでのみ有効）
        shopt -s globstar || true # エラーにならないように
        
        # inputs.paths で指定されたファイルを処理
        for file in ${{ inputs.paths }}; do
          if [ -f "$file" ]; then # ファイルが存在することを確認
            original_size=$(stat -c %s "$file") # オリジナルファイルのサイズを取得
            
            # Terserで難読化（上書き）
            # input: JSON文字列をparseして渡す
            terser "$file" -o "$file" --config-file <(echo '${{ inputs.terser_options }}')
            
            optimized_size=$(stat -c %s "$file") # 難読化後のファイルのサイズを取得
            
            if [ "$original_size" -ne "$optimized_size" ]; then
              echo "Uglified: $file (Original: $original_size bytes, Optimized: $optimized_size bytes)"
              uglified_count=$((uglified_count + 1))
            else
              echo "Skipped (no change): $file"
            fi
          fi
        done
        
        echo "uglified_count=$uglified_count" >> $GITHUB_OUTPUT
      shell: bash

CSSのminify

このアクションは、clean-css-cliを使って、CSSファイルをminifyします。

clean-css-cli: CSSファイルをminifyするツールです。

.github/actions/optimize-css/action.yml

name: 'Minify CSS with Clean-CSS'
description: 'Finds and minifies CSS files using clean-css-cli.'

inputs:
  paths:
    description: 'Glob pattern for CSS files to process (e.g., "**/*.css").'
    required: false
    default: '**/*.css'
  clean_css_options:
    description: 'JSON string of clean-css options (e.g., {"level":2})'
    required: false
    default: '{}' # デフォルトは基本的な圧縮
  output_suffix:
    description: 'Suffix to add to the minified file name (e.g., .min for style.min.css). Leave empty to overwrite.'
    required: false
    default: '' # デフォルトは上書き

outputs:
  minified_count:
    description: 'Number of CSS files that were minified.'
    value: ${{ steps.minify.outputs.minified_count }}

runs:
  using: "composite"
  steps:
    - name: Set up Node.js
      uses: actions/setup-node@v4
      with:
        node-version: '20' # clean-css-cliの実行に必要なNode.jsのバージョン

    - name: Install clean-css-cli
      run: npm install -g clean-css-cli # clean-css-cliをグローバルインストール
      shell: bash

    - name: Find and minify CSS files
      id: minify
      run: |
        minified_count=0
        
        shopt -s globstar || true
        
        for file in ${{ inputs.paths }}; do
          if [ -f "$file" ]; then # ファイルが存在することを確認
            original_size=$(stat -c %s "$file") # オリジナルファイルのサイズを取得
            
            output_file="$file"
            if [ -n "${{ inputs.output_suffix }}" ]; then
              # 拡張子の前にサフィックスを追加 (e.g., style.css -> style.min.css)
              filename="${file%.*}"
              extension="${file##*.}"
              output_file="${filename}${inputs.output_suffix}.${extension}"
            fi

            # clean-css-cliで圧縮
            # input: JSON文字列をparseして渡す
            # 圧縮後にファイルサイズが変わるか確認
            # clean-css-cli はデフォルトで上書きするが、
            # -o で出力ファイルを明示的に指定できるため、上書きまたは別名保存が可能
            
            # clean-css-cliのオプションを構築
            CLEAN_CSS_OPTIONS=""
            if [ -n "${{ inputs.clean_css_options }}" ]; then
              # clean-css-cli はJSONファイルを直接受け取らないので、
              # オプションをコマンドライン引数に変換するか、stdin経由で渡す必要がある。
              # 最も簡単なのは、JSON文字列をそのまま渡すこと。
              # clean-css-cliは --config オプションがないので、
              # 各オプションを個別に渡すか、デフォルトを使う。
              # ここでは、デフォルトの動作に任せるか、カスタムオプションを考慮せず、
              # simpleに圧縮する。より高度なオプションが必要な場合は、スクリプト内でJSONをパースして引数に変換する必要がある。
              
              # しかし、clean-css-cliは`--config`オプションがないため、オプションは個別に渡す必要があります。
              # ここでは、`clean_css_options`をJSONとしてパースして引数に変換する例を示します。
              # ただし、これを行うには`jq`などのツールが必要になるため、ワークフローの複雑さを避けるため、デフォルトではシンプルな圧縮のみを行うか、特定のよく使うオプションのみをinputで受け取る形にするのが現実的です。
              
              # 今回は`clean-css-cli`のデフォルト挙動（強力な圧縮）に任せるか、よく使うオプション（例: `--level`）を直接inputで受け取る形にします。
              # `clean_css_options` は、ここでは直接利用せず、将来的な拡張ポイントとして残します。
              
              echo "Warning: clean_css_options input is currently ignored due to clean-css-cli limitations for direct JSON config. Using default clean-css behavior or specified output_suffix."
            fi

            cleancss -o "$output_file" "$file" # 圧縮を実行

            optimized_size=$(stat -c %s "$output_file") # 圧縮後のファイルのサイズを取得
            
            if [ "$original_size" -ne "$optimized_size" ]; then
              echo "Minified: $file to $output_file (Original: $original_size bytes, Optimized: $optimized_size bytes)"
              minified_count=$((minified_count + 1))
            else
              echo "Skipped (no change): $file"
            fi
          fi
        done
        
        echo "minified_count=$minified_count" >> $GITHUB_OUTPUT
      shell: bash

Workflowへの組み込み方

これらのアクションをワークフローに組み込むには、.github/workflows/main.yml ファイルに以下のステップを追加します。

    - name: Optimize Images
      uses: ./.github/actions/optimize-image
      with:
        jpeg_quality: 70

    - name: Optimize JavaScript
      uses: ./.github/actions/optimize-js

    - name: Optimize CSS
      uses: ./.github/actions/optimize-css

これらのステップは、deploy ステップの前に追加することを推奨します。

ワークフローファイルの全体像

ワークフローファイルは、以下のようになります。

name: CI/CD

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up SSH key
        uses: webfactory/ssh-agent@v0.8.0
        with:
          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}

      - name: Optimize Images
        uses: ./.github/actions/optimize-image
        with:
          jpeg_quality: 70

      - name: Optimize JavaScript
        uses: ./.github/actions/optimize-js

      - name: Optimize CSS
        uses: ./.github/actions/optimize-css

      - name: Deploy
        run: |
          # デプロイ処理
          echo "Deploying..."

結果

これらの最適化を行うことで、サイトを表示した際のアセットの読み込み時間を短縮できるようになりました。

具体的には、アセットの合計サイズを 11.0MB から 7.7MB に削減できました。

本来であれば、webp などのより高度な画像フォーマットを使用したいところですが、今回はオリジナルファイルを変更せずに、裏側で最適化できる範囲に留めました。

実行時間

画像の最適化に少し時間がかかります。1 分程度です。

画像の圧縮ツールのインストールにネットワーク通信が必要になるため結構時間を消費しているようです。可能なら画像は元のデータを圧縮してしまうのがおすすめです。Git 管理しているのでいつでももとに戻せるので。

今後の展望

webp などのより高度な画像フォーマットの導入
JavaScript と CSS の更なる minify
CDN の導入

WordPressテーマのCI/CDをGitHub Actionsで構築する

Wed, 21 May 2025 00:00:00 GMT

はじめに

この記事では、GitHub Actions を活用した WordPress テーマの CI/CD 構築について解説する。安全かつ効率的な運用を実現するための方法を紹介する。

背景：WordPress運用における課題

WordPress は手軽にブログや Web サイトを始められる便利な CMS だが、DevOps の観点からはいくつかの課題がある。

開発環境、ステージング環境、本番環境の運用が煩雑になりがち。
テーマファイルの管理が難しい。
- ファイルを直接編集するとバージョン管理ができない。
- etckeeperを使っても、ステージング環境と本番環境のファイルを同期するきれいな方法がない。
バージョン管理ができない。
- 更新するたびに ZIP ファイルを作成してアップロードするのは手間がかかる。
DB 内のデータ（記事、ページ）とファイル（プラグイン、テーマ、アセット）が密接に連携しているため、コードレベルでのスナップショットが取りづらい。

解決策：GitHub ActionsによるCI/CD

これらの課題を解決するために、GitHub Actions を活用して WordPress テーマの CI/CD を構築する。

テーマファイルを GitHub リポジトリで管理する
GitHub Actions で、develop ブランチへの push をトリガーにステージング環境へデプロイする
GitHub Actions で、main ブランチへの push をトリガーに本番環境へデプロイする
CI で PHP の構文チェックを行い、本番環境でのエラーを未然に防ぐ

システム設計

このシステムでは、以下の要素を組み合わせて WordPress テーマの CI/CD を実現します。

GitHub リポジトリ：テーマファイルのソースコードを管理する。
GitHub Actions：CI/CD のワークフローを定義し、実行する。
SSH：GitHub Actions から WordPress サーバーへ安全にファイルを転送する。
rsync：効率的にファイルを同期する。

設定手順

1. GitHubリポジトリの準備

まず、WordPress テーマのファイルを GitHub リポジトリに登録する。

2. GitHub Actionsのワークフロー設定

次に、GitHub Actions のワークフローを設定する。

ステージング環境へのデプロイ

.github/workflows/deploy-staging.yml

name: Deploy to Staging

on:
  push:
    branches: [ develop ]
  workflow_dispatch:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout code
      uses: actions/checkout@v4
    - name: PHP Syntax Check
      uses: ./.github/actions/php-syntax-check
  deploy:
    needs: test
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v4

    - name: Set up SSH
      uses: webfactory/ssh-agent@v0.9.0
      with:
        ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY_STAGING }}
        # known_hosts: ${{ secrets.KNOWN_HOSTS_STAGING }} # よりセキュアにする場合は有効化

    - name: Ensure target theme directory exists on remote
      run: |
        SSH_HOST="${{ secrets.STAGING_SERVER_HOST }}"
        SSH_USER="${{ secrets.STAGING_SERVER_USER }}"
        THEME_PATH="${{ secrets.STAGING_THEME_PATH }}"
        ssh -o StrictHostKeyChecking=no "${SSH_USER}"@"${SSH_HOST}" "mkdir -p \"${THEME_PATH}\""

    - name: Rsync theme files to Staging
      run: |
        SSH_HOST="${{ secrets.STAGING_SERVER_HOST }}"
        SSH_USER="${{ secrets.STAGING_SERVER_USER }}"
        THEME_PATH="${{ secrets.STAGING_THEME_PATH }}"
        rsync -avzc --delete --exclude='.*' --exclude README.md -e "ssh -o StrictHostKeyChecking=no" ./ "${SSH_USER}"@"${SSH_HOST}":"${THEME_PATH}"

このワークフローは、develop ブランチへのpushをトリガーに、以下の処理を行う。

コードをチェックアウトする
PHPの構文チェックを行う
SSHでWordPressサーバーに接続し、テーマファイルをrsyncで同期する

このrsyncを実行する際のオプションは重要である。特に重要なオプションを以下に示す。

-c オプション：ファイルのチェックサムで比較し、同一ファイルであれば変更しない。GitHub Actionsでコピー元のファイルが準備される際、タイムスタンプがcheckout時のものになるため、更新日時がサーバと異なることを避けるために使用する。

-u オプション：サーバに新しいファイルが存在する場合、上書きしない。今回はすべてのファイルを上書きするため、このオプションは使用しない。

--exclude：機密情報を含まないように、ドキュメントやGit関連ファイルを除外する。

本番環境へのデプロイ

.github/workflows/deploy-production.yml

name: Deploy to Production

on:
  push:
    branches: [ main ]
  workflow_dispatch:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout code
      uses: actions/checkout@v4
    - name: PHP Syntax Check
      uses: ./.github/actions/php-syntax-check
  deploy:
    needs: test
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v4

    - name: Set up SSH
      uses: webfactory/ssh-agent@v0.9.0
      with:
        ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY_PRODUCTION }}
        # known_hosts: ${{ secrets.KNOWN_HOSTS_PRODUCTION }} # よりセキュアにする場合は有効化

    - name: Ensure target theme directory exists on remote
      run: |
        SSH_HOST="${{ secrets.PRODUCTION_SERVER_HOST }}"
        SSH_USER="${{ secrets.PRODUCTION_SERVER_USER }}"
        THEME_PATH="${{ secrets.PRODUCTION_THEME_PATH }}"
        ssh -o StrictHostKeyChecking=no "${SSH_USER}"@"${SSH_HOST}" "mkdir -p \"${THEME_PATH}\""

    - name: Rsync theme files to PRODUCTION
      run: |
        SSH_HOST="${{ secrets.PRODUCTION_SERVER_HOST }}"
        SSH_USER="${{ secrets.PRODUCTION_SERVER_USER }}"
        THEME_PATH="${{ secrets.PRODUCTION_THEME_PATH }}"
        rsync -avzc --delete --exclude='.*' --exclude README.md -e "ssh -o StrictHostKeyChecking=no" ./ "${SSH_USER}"@"${SSH_HOST}":"${THEME_PATH}"

    - name: Clear WordPress Cache
      run: |
        SSH_HOST="${{ secrets.PRODUCTION_SERVER_HOST }}"
        SSH_USER="${{ secrets.PRODUCTION_SERVER_USER }}"
        ssh -o StrictHostKeyChecking=no "${SSH_USER}"@"${SSH_HOST}" "wp w3-total-cache flush all"

  release:
    needs: deploy
    runs-on: ubuntu-latest
    steps:
    - name: Checkout code
      uses: actions/checkout@v4
    - name: Release Drafter
      uses: release-drafter/release-drafter@v6
      with:
        publish: true
        version: ${{ steps.version.outputs.version-without-v }}
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

このワークフローは、main ブランチへのpushをトリガーに、以下の処理を行う。

コードをチェックアウトする
PHPの構文チェックを行う
SSHでWordPressサーバーに接続し、テーマファイルをrsyncで同期する
WordPressのキャッシュをクリアする
リリースノートを自動生成する

PHP構文チェック

.github/actions/php-syntax-check/action.yml

name: PHP Syntax Check
description: Checks PHP syntax for errors.
runs:
  using: "composite"
  steps:
    - name: Setup PHP
      uses: shivammathur/setup-php@v2
      with:
        php-version: '7.4'
    - name: Run PHP Syntax Check
      shell: bash
      run: |
        find . -name "*.php" -print0 | xargs -0 -n1 php -l

このアクションは、PHPの構文チェックを行います。

リリースノート自動生成

.github/release-drafter.yml

name-template: 'v$RESOLVED_VERSION 🌈'
tag-template: 'v$RESOLVED_VERSION'
categories:
  - title: '🚀 Features'
    labels:
      - 'feature'
      - 'enhancement'
  - title: '🐛 Bug Fixes'
    labels:
      - 'fix'
      - 'bugfix'
  - title: '🧰 Maintenance'
    label: 'chore'
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
change-title-escapes: '\<*_&' # You can add # and @ to disable mentions, and add ` to disable code blocks.
version-resolver:
  major:
    labels:
      - 'major'
  minor:
    labels:
      - 'minor'
  patch:
    labels:
      - 'patch'
  default: patch
template: |
  ## Changes

  $CHANGES

このファイルは、リリースノートの自動生成に関する設定を記述します。

3. GitHub Secretsの設定

GitHub ActionsからWordPressサーバーへSSH接続するために、GitHub Secretsを設定します。

SSH_PRIVATE_KEY_STAGING: ステージング環境へのSSH接続に使用する秘密鍵
SSH_PRIVATE_KEY_PRODUCTION: 本番環境へのSSH接続に使用する秘密鍵
STAGING_SERVER_HOST: ステージング環境のホスト名
STAGING_SERVER_USER: ステージング環境のユーザー名
STAGING_THEME_PATH: ステージング環境のテーマファイルのパス
PRODUCTION_SERVER_HOST: 本番環境のホスト名
PRODUCTION_SERVER_USER: 本番環境のユーザー名
PRODUCTION_THEME_PATH: 本番環境のテーマファイルのパス

4. WordPressサーバーの設定

WordPressサーバーに、GitHub ActionsからWordPressサーバーへSSH接続できるように設定します。

WordPressを運用しているホストにはGithub Actionsからsshで接続できるようにしておく必要があります。
- Github actionsのIPアドレスの空間が膨大なのでligthsailだと制限をかけるのが不可能です。
- Github actionsのsource IP addressはAPIで公開されています。

sshキーペアの作り方はこんな感じです。生成された秘密鍵をGithub Actionsのsecretsに登録し、公開鍵をwordpressの.ssh/authorized_keysに追加します。

% ssh-keygen -t ed25519 -C "github-actions-staging@example.com" -f ~/.ssh/github_actions_deploy_key_staging
% ssh-keygen -t ed25519 -C "github-actions-production@example.com" -f ~/.ssh/github_actions_deploy_key_production

実行結果

GitHub Actions のワークフローを実行すると、ステージング環境と本番環境へテーマファイルが自動的にデプロイされます。

ステージングは 1 分程度で完了します。

本番も 1 分程度で完了します。

今後の展望

WordPress を SSG（Static Site Generator）に移行することで、より高速かつ安全な Web サイトを構築できる可能性があります。
カオスになりやすい WordPress の運用に少しでも秩序を導入できたのでこれでしばらくは延命できます。

まとめ

GitHub Actions を活用することで、WordPress テーマの CI/CD を簡単に構築できます。これにより、開発効率が向上し、安全な運用を実現できます。

AI PMワークフロー「aipm_v0」の使用例と応用を考える

Thu, 08 May 2025 00:00:00 GMT

3秒まとめ

この記事の目的
- みやっち氏作の AI PM ワークフローの理解と社内プロジェクトへの応用可能性の探求
内容
- AI PM の概要とコンセプト
- 「aipm_v0」の説明
- 「オンライン定性調査プラットフォーム構築」における活用シミュレーション。8 年前に企画してローンチしたサービス。
- 考察や応用事例。示唆が多いので解説。
期待される効果
- プロジェクト管理業務の効率化と質の向上
- AI Agent や Digital Twin、ドキュメントワークフローへの応用

AI PMとは？

AI を活用した、プロジェクトマネジメントの新しいアプローチです。
目的:
- プロジェクト計画の自動生成・最適化
- タスクの割り当てと進捗管理の支援
- リスク予測と早期警告
- コミュニケーションの円滑化
期待されるメリット:
- プロジェクトマネージャー（PM）の負担軽減
- 意思決定の迅速化と精度向上
- プロジェクト成功率の向上

知ったきっかけ

https://x.com/miyatti/status/1919257337556246728

みやっち氏作「aipm_v0」の概要

GitHub: miyatti777/aipm_v0
コンセプト (リポジトリのREADMEなどから引用・要約):
- 例: LLM を活用し、プロジェクトの初期構想からタスク分解、進捗管理までを支援するツール
主な機能 (同上):
- プロジェクト概要からの WBS 生成
- タスクカードの自動作成
- 進捗報告の集約と分析
特徴 (同上):
- 特定の LLM に依存しない設計（想定されています）
- シンプルなインタフェース

aipm_v0のワークフロー

本家のreadmeが崩れていたので引用して整形。

┌──────────────────────────────┐   trigger（チャットコマンド）
│ 00_master_rules.mdc          │◀───────────────────────┐
└─────────┬────────────────────┘                        │
          │call                                         │
┌─────────▼────────────┐   発散/収束も Draft 化           │
│ 01‑06_pmbok_*.mdc    │──────────────────┐             │
│ 08_flow_assist.mdc   │    create_draft  │             │
└─────────┬────────────┘                  │             │
          │                               │             │
         ▼ Draft (.md)                    │             │
      Flow/YYYYMM/YYYY‑MM‑DD/─────────────┘             │
         │  human review + "確定反映して"                 │
         ▼                                              │
     Stock/programs/PROGRAM/projects/PROJECT/.. ← flow_to_stock_rules.mdc

もう少し簡略化すると以下。

graph TD
    A[ルール/テンプレート/成果物参照: pmbok_*.mdc, flow_assist.mdc] -->|トリガー/チャットコマンド| B[Draft生成]
    B -->|human review + 確定反映| C[Stock: 確定済みドキュメント]
    
    subgraph マスタールール
    A
    end
    
    subgraph 作業ディレクトリ
    B[Draft: Flow/YYYYMM/YYYY-MM-DD/]
    end
    
    subgraph 成果物格納
    C[Stock/programs/PROGRAM/projects/PROJECT/]
    end

要するに、事前に定義されたルールやテンプレートを使って一時的な文書（Draft）を生成し、人間がレビューした後に確定版（Stock）として保存するというワークフローです。

READMEを読んだのですが、いろいろな知見、理論が組み込まれています。すぐに理解するのは難しいのでサラッと読んで以下の実行例を見てみると雰囲気をつかめると思います。

ケーススタディ：社内プロジェクトへの適用

プロジェクトテーマ: 「オンラインで完結する定性調査プラットフォームの構築」
背景:
- 既存の定性調査プロセスにおける課題（時間、コスト、地理的制約など）
- オンライン化による効率化とリーチ拡大の期待
AI PM (aipm_v0) を使った実践:
1. プロジェクトの起案 (aipm_v0へのインプット作成)
2. AIによるタスク分解とスケジュール案の生成
3. 生成された計画の評価と調整
4. 開発管理のシミュレーション

ここ以降の流れで作ったドキュメント類はこちらにpushしてあります。こちらを見たほうがわかりやすいかも。 https://github.com/matsubo/aipm_v0_qualitative_research

0. 初期設定

リポジトリをcloneし、初期セットアップスクリプトを実行します。これは、メインとなるルールのダウンロードとサンプルとなるプロジェクトのダウンロードが行われます。

git clone git@github.com:miyatti777/aipm_v0.git
cd aipm_v0
./setup_workspace_simple.sh setup_config.sh

本来はこのあたりをカスタマイズする必要がありますが、今回はそのまま使用します。以下のディレクトリ構成が作られました。

❯ tree .cursor/
.cursor/
└── rules
    └── basic
        ├── 00_master_rules.mdc
        ├── 01_pmbok_initiating.mdc
        ├── 02_pmbok_discovery.mdc
        ├── 02_pmbok_research.mdc
        ├── 03_pmbok_planning.mdc
        ├── 04_pmbok_executing.mdc
        ├── 05_pmbok_monitoring.mdc
        ├── 06_pmbok_closing.mdc
        ├── 07_task_management.mdc
        ├── 08_pmbok_flow_assist.mdc
        ├── 09_pmbok_development.mdc
        ├── 90_rule_maintenance.mdc
        ├── pmbok_paths.mdc
        └── templates
            ├── daily_tasks_template.md
            ├── meeting_minutes_template.md
            └── weekly_review_template.md

❯ tree
.
├── Archived
│   └── projects
├── Flow
│   └── 202505
│       └── 2025-05-08
├── README.md
├── scripts
│   └── test.sh
├── setup_config.sh
├── setup_workspace_simple.sh
└── Stock
    └── programs
        ├── 夕食作り
        │   └── projects
        │       └── カレー
        │           ├── documents
        │           │   ├── 1_initiating
        │           │   │   └── project_charter.md
        │           │   ├── 2_discovery
        │           │   │   ├── persona.md
        │           │   │   ├── problem_statement.md
        │           │   │   └── solution_definition.md
        │           │   ├── 3_planning
        │           │   │   ├── backlog
        │           │   │   │   ├── backlog.yaml
        │           │   │   │   ├── epics.yaml
        │           │   │   │   └── stories
        │           │   │   │       └── US-001.md
        │           │   │   ├── roadmap
        │           │   │   │   └── product_roadmap.md
        │           │   │   └── wbs.md
        │           │   └── 4_executing
        │           │       ├── daily_tasks
        │           │       │   └── daily_tasks_2025-05-05.md
        │           │       └── sprint_goals
        │           │           └── sprint_goals_1.md
        │           └── README.md
        └── Common
            └── Public

Cursor用のProject Ruleで書かれています。

Cursor要のProject Ruleとmdcの説明は以下を参照。

https://zenn.dev/channnnsm/articles/0df0ea29d63be3

私はCursorを使用していないため、Clineで代用します。Clineもmdcで書かれたProject Ruleを理解してくれます。 LLMには、最近筆者が気に入っているGemini 2.5 Proを使用します。

Custom Instructionには、aipm_v0 のREADMEにある手順に従い、以下の情報を入力しておきます。

#========================================================
# 0. ベースポリシー
#========================================================
! Always respond in 日本語
- 成果物はできるだけファイルとして出力（細かく分割）
- MCP やファイル閲覧など可能な作業は自律実行
- タスク依頼時は不足情報を確認し、自ら計画→ゴールまで進行
- 立てた計画はタスクリストとして提示
- 日付に関する処理をやるときは、必ずdate関数で正確な情報を確認

#========================================================
# 1. 必須ルールファイル参照（pre‑load）
#========================================================

required_rule_files:
  - .cursor/rules/basic/
  - .cursor/rules/basic/01_pmbok_initiating.mdc
  - .cursor/rules/basic/03_pmbok_planning.mdc
  - .cursor/rules/basic/04_pmbok_executing.mdc
  - .cursor/rules/basic/02_pmbok_discovery.mdc
  - .cursor/rules/basic/02_pmbok_research.mdc
  - .cursor/rules/basic/pmbok_paths.mdc
  - .cursor/rules/basic/06_pmbok_closing.mdc
  - .cursor/rules/basic/90_rule_maintenance.mdc
  - .cursor/rules/basic/09_pmbok_development.mdc
  - .cursor/rules/basic/templates
  - .cursor/rules/basic/templates/daily_tasks_template.md
  - .cursor/rules/basic/templates/meeting_minutes_template.md
  - .cursor/rules/basic/templates/weekly_review_template.md
  - .cursor/rules/basic/00_master_rules.mdc
  - .cursor/rules/basic/07_task_management.mdc
  - .cursor/rules/basic/08_pmbok_flow_assist.mdc
  - .cursor/rules/basic/05_pmbok_monitoring.mdc

1. 立ち上げ

これは、プロジェクトの初期設定に相当します。

READMEの指示通りに、プロジェクトのドキュメントを構築するためのコマンドを実行します。

最初にプロジェクト名を尋ねられるため、以下のように入力しました。このプロジェクトは、筆者が所属する企業の創業時に考案したシステムの内容です。

オンラインで定性調査するプラットフォームサービスの構築

10年近く前に考案した内容ですが、企画立案からサービスローンチ、運用、機能開発まで一通り経験したサービスであるため、LLMの出力と実際の経験との差分を比較しながら評価しやすいと考え、これを選定しました。

次に、"プロジェクトの背景と目的" を尋ねられました。背景を説明すると長くなるため、今回はGemini 2.5 Proに生成を依頼しました。

# 背景

1.  **地理的・時間的制約の克服:**
    * 従来の対面でのインタビューやグループ調査では、参加者が特定の場所に集まる必要があり、地理的な制約や移動に伴う時間的・経済的コストが発生していました。特に、広範囲な地域からの意見収集や、多忙な参加者へのアプローチが困難でした。
    * オンライン化により、居住地に関わらず多様な参加者を集めることが可能になり、日程調整の柔軟性も向上します。

2.  **コスト効率の改善:**
    * 会場費、交通費、謝礼以外の運営コスト（人件費の一部など）を削減できる可能性があります。
    * これにより、従来は予算的に難しかった小規模な調査や、頻繁な調査実施のハードルが下がります。

3.  **多様な参加者へのアクセス:**
    * ニッチなターゲット層や、特定の属性（例：子育て中の親、特定の疾患を持つ患者、地方在住者など）を持つ人々にも、オンラインであればリーチしやすくなります。
    * 匿名性を確保しやすいオンライン環境は、デリケートなテーマに関してより率直な意見を引き出せる可能性も秘めています。

4.  **デジタルトランスフォーメーション（DX）の流れ:**
    * あらゆる業界でDXが加速しており、マーケティングリサーチの分野も例外ではありません。企業はより迅速かつ効率的なデータ収集・分析手法を求めています。
    * オンラインツールを活用した業務効率化は、現代のビジネスにおける標準となりつつあります。

5.  **新しい生活様式と働き方の定着:**
    * 新型コロナウイルス感染症のパンデミック以降、オンラインコミュニケーションが一般化し、人々はオンラインでの活動に慣れ親しんでいます。
    * リモートワークの普及などにより、オンラインでの調査参加への心理的な抵抗感も低減していると考えられます。

6.  **テクノロジーの進化:**
    * 高品質なビデオ会議システム、チャットツール、オンラインホワイトボード、AIを活用した文字起こしや感情分析ツールなどが登場し、オンラインでも質の高い定性調査を実施できる環境が整ってきました。
    * これらの技術を活用することで、対面調査に近い、あるいはそれ以上の体験価値を提供できる可能性があります。

# 目的

1.  **より多くの企業・組織に定性調査の機会を提供:**
    * 地理的・時間的・コスト的な制約を軽減することで、これまで定性調査の実施をためらっていた企業や組織（特に中小企業やスタートアップ、地方の団体など）にも、その活用を促進します。
    * これにより、顧客理解を深め、より的確な意思決定を行うためのインサイト獲得を支援します。

2.  **調査プロセスの効率化と迅速化:**
    * 参加者の募集・スクリーニング、インタビューやグループディスカッションの実施、記録・分析といった一連のプロセスをプラットフォーム上で一元管理できるようにし、調査担当者の負担を軽減します。
    * 従来よりも短期間で調査を完了させ、スピーディーな意思決定に貢献することを目指します。

3.  **質の高いインサイトの獲得支援:**
    * 多様なバックグラウンドを持つ参加者からの、より本質的で深層心理に迫る意見を効率的に収集できる環境を提供します。
    * 動画や音声、テキストデータだけでなく、チャットログ、画面共有、オンラインホワイトボード上の共同作業など、多様な形式のデータを収集・分析できる機能を提供し、より多角的な分析を可能にします。

4.  **新しい調査手法の開拓と提供:**
    * オンラインならではの特性を活かした新しい定性調査手法（例：非同期型インタビュー、オンラインエスノグラフィ、バーチャル空間でのグループディスカッションなど）を開発・提供し、定性調査の可能性を広げます。
    * AIなどの最新技術を積極的に取り入れ、データ分析の高度化や効率化を図ります。

5.  **ユーザーフレンドリーなプラットフォームの実現:**
    * 調査依頼者、調査実施者（モデレーター）、調査参加者のそれぞれにとって、直感的で使いやすいインターフェースと体験を提供します。
    * セキュリティとプライバシー保護にも万全を期し、安心して利用できる環境を構築します。

6.  **定性調査市場における新たな価値創造:**
    * 既存の調査手法の課題を解決し、オンラインの強みを最大限に活かすことで、定性調査市場において独自のポジションを確立し、新たな価値を提供することを目指します。
    * 将来的には、収集された定性データのナレッジベース化や、他のデータとの連携による新たなインサイト創出なども視野に入れる可能性があります。

コアな部分や、課題の核心を突くような深みはまだ見られませんが、もっともらしい立派な文章を生成してくれます。スコープや表面的な内容は適切だと思われるため、このまま進めます。次に、「含まれる範囲」についてです。

# 含まれる範囲

**１．機能的な範囲（プラットフォームで何ができるか）**

* **コア機能:**
    * **オンラインインタビュー支援:** 1対1のデプスインタビューや、複数名でのグループインタビューを実施するためのビデオ通話、チャット、画面共有、録画・録音機能。
    * **参加者管理:** 調査参加者の募集（外部連携含む）、スクリーニング、スケジュール調整、インセンティブ管理支援。
    * **実査サポート:** インタビューガイドの表示、資料共有、オンラインホワイトボードなどの共同作業ツール。
    * **データ管理・簡易分析支援:** 録画データの保存・共有、自動文字起こし（外部連携または内製）、発言内容のタグ付けやコメント付与といった簡易的なコーディング機能。
* **将来的/段階的に検討する機能:**
    * より高度なテキストマイニングや感情分析機能。
    * レポーティング支援機能（簡易レポート自動生成など）。

**２．対象ユーザーの範囲（誰が使うのか、誰を対象にするのか）**

* **主な利用企業・部門:**
    * 新製品・サービス開発や既存事業の改善に取り組む企業のマーケティング部門、商品企画部門、UXリサーチャー。
    * 顧客理解を深めたいスタートアップ企業。
    * 広告代理店やコンサルティングファームのリサーチ部門。
* **調査参加者:**
    * 初期は国内の一般消費者を主な対象とし、将来的には特定の属性（BtoB、専門職など）や海外の参加者への拡張も視野に入れます。
    * リクルーティングは、クライアント保有リストの活用、提携パネル事業者との連携、SNSなどを通じた公募などを想定しています。

**３．サービス提供範囲（どこまでサポートするか）**

* **プラットフォーム提供:** 上記機能を有するSaaSとしてのプラットフォーム提供が基本となります。
* **サポート体制:**
    * システムの利用方法に関するテクニカルサポート。
    * 初期導入時のオンボーディング支援。
* **オプション/将来検討:**
    * 調査設計のコンサルテーション。
    * モデレーターやリクルーティング代行などの付加サービス（自社またはパートナー連携）。
    * 多言語対応（現在は日本語を想定）。

**現時点でのスコープ外（何を含まないか）**

* オフラインでの会場手配や実査運営。
    * 大規模な定量調査の実施・分析機能。
    * 高度な専門知識を要する学術研究レベルの分析ツール（初期フェーズでは）。

**基本的な考え方**

まずは、オンラインでの定性調査を「手軽に」「効率的に」「質の高いインサイトを得られる形で」実施できるコアな機能群に絞り、利用者のフィードバックを得ながら段階的に機能拡充と対象範囲の拡大を図っていく方針です。特に、ユーザー自身が直感的に操作でき、調査の準備から実査、簡易的なデータ整理までをスムーズに行える点に注力いたします。

次に、「含まれない範囲」についてです。

# 含まれない範囲

**１．オフラインでの調査実施および関連業務全般**

* **会場手配・運営:** インタビューやグループディスカッションのための物理的な会場の予約、設営、当日の運営サポートなどは行いません。
* **調査員の派遣:** モデレーターや書記、受付スタッフなどを現地に派遣するサービスは提供いたしません。
* **郵送調査・訪問調査の管理:** 調査票の郵送、回収管理、または調査員が対象者の自宅や職場を訪問して行う調査のロジスティクス管理は範囲外です。
    * *理由：私たちの強みはオンラインに特化しており、オフライン業務は専門外であるためです。*

**２．大規模な定量調査の機能**

* **アンケート配信システム:** 数百～数千人規模のアンケートを作成し、一斉に配信・回収・集計するような、いわゆる「定量調査」を主目的としたシステム機能は搭載していません。
* **高度な統計解析ツール:** 複雑な統計モデルを用いた分析や、多変量解析といった高度な統計処理機能は提供範囲外です。
    * *理由：本プラットフォームは、数値データで捉えきれない「なぜそう思うのか」「どのような背景があるのか」といった質的な情報を深く掘り下げることに特化しているためです。*

**３．フルサービス型のリサーチプロジェクト代行**

* **総合的な調査企画・設計コンサルティング:** お客様の課題抽出から、最適な調査手法の選定、設問設計までを全て弊社が請け負う形のコンサルティングサービスは、プラットフォームの標準機能には含まれません。
* **リサーチ実査・分析・報告書作成の完全アウトソース:** モデレーション、対象者リクルーティング、データ分析、洞察の抽出、最終報告書の作成まで、調査プロジェクト全体を丸ごと代行するサービスは、現時点では提供しておりません。
    * *理由：私たちは、お客様自身が主体的に、かつ効率的に定性調査を実施するための「ツール」と「環境」を提供することに主眼を置いています。ただし、操作サポートや一部オプション（例：提携モデレーターの紹介など）は検討可能です。*

**４．専門分野に特化した特殊な機能やサービス**

* **特定の学術研究用の高度な分析ツール:** 例えば、特定の心理学理論に基づいたコーディングシステムや、特定の生体計測データと連動するような専門性の高い分析機能は含みません。
* **法務・医療などの特定業界の厳格な規制に完全準拠した特殊機能:** 一般的なビジネス利用におけるセキュリティや個人情報保護には万全を期しますが、特定の業界（例：医療における治験データの超厳密な管理など）に特化した監査証跡機能や特殊なデータ形式への対応は、現時点では範囲外です。
* **翻訳・通訳サービス:** 多言語対応を将来的に検討する可能性はありますが、プラットフォーム利用における専門の翻訳者やリアルタイム通訳者の手配までは標準サービスに含みません。
    * *理由：汎用性と使いやすさを重視し、まずは幅広いお客様にご利用いただけるオンライン定性調査のコア機能の充実に注力するためです。*

**５．プラットフォーム利用と直接関連しない業務サポート**

* **参加者のPC環境や通信トラブルへの個別詳細サポート:** プラットフォーム自体の不具合には対応しますが、調査参加者個人のデバイス設定やインターネット環境に起因する問題解決までを弊社が全面的にサポートするわけではありません（一般的なトラブルシューティングガイドの提供などは検討します）。

これらの範囲設定は、私たちが提供するオンライン定性調査プラットフォームの中核的価値にリソースを集中させ、お客様にとって真に有用なサービスを開発・提供していくためのものです。もちろん、市場のニーズや事業の進捗に応じて、将来的に範囲を見直す可能性はございます。

このあたりは、PMBOKに準拠した内容という印象です。チャット形式で入力できるため、PMBOKの知識がなくても手軽に進められます。次に、ステークホルダーについて尋ねられました。これについては、スタートアップの雰囲気を出すために2名としました。

# ステークホルダー

「ご質問ありがとうございます。私たちは現在創業前であり、ビジネス担当とCTOの2名がコアメンバーとしてMVP開発を進めています。この状況における主要なステークホルダーは、以下の通りです。

**【コアチーム（事実上の社内ステークホルダー）】**

1.  **創業者（私たち自身）:**
    * **ビジネス担当（P&G出身）:**
        * **役割:** プロダクトビジョン策定、事業戦略立案、顧客開発（ターゲット顧客の特定とヒアリング）、MVPの仮説検証、マーケティング戦略（初期）、資金調達準備（将来的に）、法務・会計などのバックオフィス基盤準備。
        * **関心事:** PMF（プロダクトマーケットフィット）の達成、トラクション獲得、事業の持続可能性。
    * **CTO（システム開発担当）：**
        * **役割:** 技術戦略策定、MVPのアーキテクチャ設計・開発、技術選定、開発プロセスの構築、プロダクトの品質担保、スケーラビリティの考慮。
        * **関心事:** 実現可能な技術によるMVPの迅速な構築、安定したプロダクト提供、将来の技術的負債の低減。
    * **私たち2名の共通の関心事:**
        * ユーザーの課題を解決する価値あるプロダクトの創出。
        * 迅速な意思決定と実行によるアジャイルな開発。
        * 限られたリソース（時間、資金、人的資本）の最適配分。
        * 明確なコミュニケーションと信頼に基づく強力なパートナーシップ。

**【主要な社外ステークホルダー】**

1.  **ターゲット顧客 / アーリーアダプター:**
    * **対象例:** 私たちが初期に課題解決を目指す、オンライン定性調査に強いニーズを持つ企業担当者（マーケティング、UXリサーチ、新規事業開発など）や、新しいツールを積極的に試したいと考えているリサーチャー。
    * **関わり方・重要性:** MVPの仮説検証とPMF達成のために最も重要な存在です。彼らの抱える「具体的な課題」や「既存の解決策への不満」を深くヒアリングし、MVPに対する率直なフィードバック（良い点、悪い点、改善要望）を得ることで、プロダクトを正しい方向に進化させます。デモ、試用、インタビューなどを通じて密接な関係を構築します。

2.  **（潜在的な）調査参加者:**
    * **対象例:** 上記のターゲット顧客が調査を行いたいと考える一般消費者や、特定の属性を持つ人々。
    * **関わり方・重要性:** プラットフォームの価値を成立させるために不可欠な存在です。MVP段階では、どのようにしてこれらの参加者を集め、快適かつ信頼できる調査体験を提供できるかが課題となります。ターゲット顧客が実際に調査を実施できる状態を作るために、この層への配慮も必要です。

3.  **メンター / アドバイザー:**
    * **対象例:** スタートアップ経営経験者、リサーチ業界の専門家、P&Gや技術系のネットワークを通じて得られる経験豊富な方々、エンジェル投資家でメンタリングも行う方など。
    * **関わり方・重要性:** 私たちの経験や知識を補完し、客観的な視点から事業戦略、プロダクト開発、市場アプローチなどについて貴重なアドバイスやフィードバックを提供してくれます。PMF達成への道のりを短縮し、致命的な間違いを避ける上で非常に重要です。積極的に探し、関係を構築すべき対象です。

4.  **（必要に応じた）技術パートナー / 外部サービス提供者:**
    * **対象例:** 特定のAPI（例: ビデオ会議、AI文字起こし）提供企業、クラウドサービスプロバイダー、フリーランスのデザイナーや専門家（短期的な協力が必要な場合）。
    * **関わり方・重要性:** MVP開発を迅速かつ効率的に進めるために、自前で全て開発するのではなく、既存の優れた技術やサービスを適切に活用する場合の協力先です。

次に、予算に関する「スポンサー」についてです。

# スポンサー

実質的な意味でこのプロジェクトを支え、推進している「スポンサー」は、**私たち創業者自身**であると言えます。

具体的には、以下の側面で私たちがスポンサーの役割を担っています。

1.  **資金的スポンサーとして：**
    * プロジェクトに必要な初期費用は、私たち2名が自らの資金を出し合います。予算は100万円です。つまり、自分たちのアイデアと将来性に対して、自分たち自身が最初の投資家となっている状態です。

2.  **リソース（時間・労力）提供者として：**
    * 本業以外の貴重な余暇時間をこのプロジェクトの開発と準備に充てています。これは、金銭的な投資以上に重要な「時間」と「情熱」という資源を、プロジェクトの成功のために注ぎ込んでいることを意味します。

3.  **ビジョンと推進力の源泉として：**
    * このプラットフォームのアイデア、それが解決できる課題、そして目指すべきビジョンを最も強く信じ、実現に向けて情熱を持って取り組んでいるのは、私たち自身です。プロジェクトを前進させる原動力そのものです。

言い換えれば、現時点では、**私たち自身がこのプロジェクトの最大の支援者であり、すべてのリスクを負い、その成功に向けて全面的にコミットしている**という体制です。

この自己完結的なアプローチにより、外部の意思決定プロセスに左右されることなく、迅速かつ柔軟にMVP（Minimum Viable Product）の開発と仮説検証を進めることが可能になっています。

プロダクトの開発がうまくいけば、すぐに売上が見込めるので金銭的な初期投資は登記費用とバーチャルオフィスの月額費用のみで済みます。これにより、私たちのリスクは最小限に抑えられています。

その後、いくつかの細かい質問に回答していきます。

プロジェクトの開始日と終了日を尋ねられたため、本日を開始日とし、6ヶ月後を終了日として設定しました。
プロジェクトマネージャーは、Biz担当者としました。
予算は、金銭面で10万円とし、加えて筆者の余暇時間（自己投資のため0円として計上）としました。

これにより、プロジェクト憲章のドラフトが作成されました。

# プロジェクト憲章
**プロジェクト名**: オンラインで定性調査を行うプラットフォームサービスの構築

## 1. 背景と目的
# 背景

1.  **地理的・時間的制約の克服:**
    * 従来の対面でのインタビューやグループ調査では、参加者が特定の場所に集まる必要があり、地理的な制約や移動に伴う時間的・経済的コストが発生していました。特に、広範囲な地域からの意見収集や、多忙な参加者へのアプローチが困難でした。
    * オンライン化により、居住地に関わらず多様な参加者を集めることが可能になり、日程調整の柔軟性も向上します。

2.  **コスト効率の改善:**
    * 会場費、交通費、謝礼以外の運営コスト（人件費の一部など）を削減できる可能性があります。
    * これにより、従来は予算的に難しかった小規模な調査や、頻繁な調査実施のハードルが下がります。

3.  **多様な参加者へのアクセス:**
    * ニッチなターゲット層や、特定の属性（例：子育て中の親、特定の疾患を持つ患者、地方在住者など）を持つ人々にも、オンラインであればリーチしやすくなります。
    * 匿名性を確保しやすいオンライン環境は、デリケートなテーマに関してより率直な意見を引き出せる可能性も秘めています。

4.  **デジタルトランスフォーメーション（DX）の流れ:**
    * あらゆる業界でDXが加速しており、マーケティングリサーチの分野も例外ではありません。企業はより迅速かつ効率的なデータ収集・分析手法を求めています。
    * オンラインツールを活用した業務効率化は、現代のビジネスにおける標準となりつつあります。

5.  **新しい生活様式と働き方の定着:**
    * 新型コロナウイルス感染症のパンデミック以降、オンラインコミュニケーションが一般化し、人々はオンラインでの活動に慣れ親しんでいます。
    * リモートワークの普及などにより、オンラインでの調査参加への心理的な抵抗感も低減していると考えられます。

6.  **テクノロジーの進化:**
    * 高品質なビデオ会議システム、チャットツール、オンラインホワイトボード、AIを活用した文字起こしや感情分析ツールなどが登場し、オンラインでも質の高い定性調査を実施できる環境が整ってきました。
    * これらの技術を活用することで、対面調査に近い、あるいはそれ以上の体験価値を提供できる可能性があります。

# 目的

1.  **より多くの企業・組織に定性調査の機会を提供:**
    * 地理的・時間的・コスト的な制約を軽減することで、これまで定性調査の実施をためらっていた企業や組織（特に中小企業やスタートアップ、地方の団体など）にも、その活用を促進します。
    * これにより、顧客理解を深め、より的確な意思決定を行うためのインサイト獲得を支援します。

2.  **調査プロセスの効率化と迅速化:**
    * 参加者の募集・スクリーニング、インタビューやグループディスカッションの実施、記録・分析といった一連のプロセスをプラットフォーム上で一元管理できるようにし、調査担当者の負担を軽減します。
    * 従来よりも短期間で調査を完了させ、スピーディーな意思決定に貢献することを目指します。

3.  **質の高いインサイトの獲得支援:**
    * 多様なバックグラウンドを持つ参加者からの、より本質的で深層心理に迫る意見を効率的に収集できる環境を提供します。
    * 動画や音声、テキストデータだけでなく、チャットログ、画面共有、オンラインホワイトボード上の共同作業など、多様な形式のデータを収集・分析できる機能を提供し、より多角的な分析を可能にします。

4.  **新しい調査手法の開拓と提供:**
    * オンラインならではの特性を活かした新しい定性調査手法（例：非同期型インタビュー、オンラインエスノグラフィ、バーチャル空間でのグループディスカッションなど）を開発・提供し、定性調査の可能性を広げます。
    * AIなどの最新技術を積極的に取り入れ、データ分析の高度化や効率化を図ります。

5.  **ユーザーフレンドリーなプラットフォームの実現:**
    * 調査依頼者、調査実施者（モデレーター）、調査参加者のそれぞれにとって、直感的で使いやすいインターフェースと体験を提供します。
    * セキュリティとプライバシー保護にも万全を期し、安心して利用できる環境を構築します。

6.  **定性調査市場における新たな価値創造:**
    * 既存の調査手法の課題を解決し、オンラインの強みを最大限に活かすことで、定性調査市場において独自のポジションを確立し、新たな価値を提供することを目指します。
    * 将来的には、収集された定性データのナレッジベース化や、他のデータとの連携による新たなインサイト創出なども視野に入れる可能性があります。

## 2. スコープ
- **含む**: # 含まれる範囲

**１．機能的な範囲（プラットフォームで何ができるか）**

* **コア機能:**
    * **オンラインインタビュー支援:** 1対1のデプスインタビューや、複数名でのグループインタビューを実施するためのビデオ通話、チャット、画面共有、録画・録音機能。
    * **参加者管理:** 調査参加者の募集（外部連携含む）、スクリーニング、スケジュール調整、インセンティブ管理支援。
    * **実査サポート:** インタビューガイドの表示、資料共有、オンラインホワイトボードなどの共同作業ツール。
    * **データ管理・簡易分析支援:** 録画データの保存・共有、自動文字起こし（外部連携または内製）、発言内容のタグ付けやコメント付与といった簡易的なコーディング機能。
* **将来的/段階的に検討する機能:**
    * より高度なテキストマイニングや感情分析機能。
    * レポーティング支援機能（簡易レポート自動生成など）。

**２．対象ユーザーの範囲（誰が使うのか、誰を対象にするのか）**

* **主な利用企業・部門:**
    * 新製品・サービス開発や既存事業の改善に取り組む企業のマーケティング部門、商品企画部門、UXリサーチャー。
    * 顧客理解を深めたいスタートアップ企業。
    * 広告代理店やコンサルティングファームのリサーチ部門。
* **調査参加者:**
    * 初期は国内の一般消費者を主な対象とし、将来的には特定の属性（BtoB、専門職など）や海外の参加者への拡張も視野に入れます。
    * リクルーティングは、クライアント保有リストの活用、提携パネル事業者との連携、SNSなどを通じた公募などを想定しています。

**３．サービス提供範囲（どこまでサポートするか）**

* **プラットフォーム提供:** 上記機能を有するSaaSとしてのプラットフォーム提供が基本となります。
* **サポート体制:**
    * システムの利用方法に関するテクニカルサポート。
    * 初期導入時のオンボーディング支援。
* **オプション/将来検討:**
    * 調査設計のコンサルテーション。
    * モデレーターやリクルーティング代行などの付加サービス（自社またはパートナー連携）。
    * 多言語対応（現在は日本語を想定）。

**現時点でのスコープ外（何を含まないか）**

* オフラインでの会場手配や実査運営。
    * 大規模な定量調査の実施・分析機能。
    * 高度な専門知識を要する学術研究レベルの分析ツール（初期フェーズでは）。

**基本的な考え方**

まずは、オンラインでの定性調査を「手軽に」「効率的に」「質の高いインサイトを得られる形で」実施できるコアな機能群に絞り、利用者のフィードバックを得ながら段階的に機能拡充と対象範囲の拡大を図っていく方針です。特に、ユーザー自身が直感的に操作でき、調査の準備から実査、簡易的なデータ整理までをスムーズに行える点に注力いたします。
- **含まない**: # 含まれない範囲

**１．オフラインでの調査実施および関連業務全般**

* **会場手配・運営:** インタビューやグループディスカッションのための物理的な会場の予約、設営、当日の運営サポートなどは行いません。
* **調査員の派遣:** モデレーターや書記、受付スタッフなどを現地に派遣するサービスは提供いたしません。
* **郵送調査・訪問調査の管理:** 調査票の郵送、回収管理、または調査員が対象者の自宅や職場を訪問して行う調査のロジスティクス管理は範囲外です。
    * *理由：私たちの強みはオンラインに特化しており、オフライン業務は専門外であるためです。*

**２．大規模な定量調査の機能**

* **アンケート配信システム:** 数百～数千人規模のアンケートを作成し、一斉に配信・回収・集計するような、いわゆる「定量調査」を主目的としたシステム機能は搭載していません。
* **高度な統計解析ツール:** 複雑な統計モデルを用いた分析や、多変量解析といった高度な統計処理機能は提供範囲外です。
    * *理由：本プラットフォームは、数値データで捉えきれない「なぜそう思うのか」「どのような背景があるのか」といった質的な情報を深く掘り下げることに特化しているためです。*

**３．フルサービス型のリサーチプロジェクト代行**

* **総合的な調査企画・設計コンサルティング:** お客様の課題抽出から、最適な調査手法の選定、設問設計までを全て弊社が請け負う形のコンサルティングサービスは、プラットフォームの標準機能には含まれません。
* **リサーチ実査・分析・報告書作成の完全アウトソース:** モデレーション、対象者リクルーティング、データ分析、洞察の抽出、最終報告書の作成まで、調査プロジェクト全体を丸ごと代行するサービスは、現時点では提供しておりません。
    * *理由：私たちは、お客様自身が主体的に、かつ効率的に定性調査を実施するための「ツール」と「環境」を提供することに主眼を置いています。ただし、操作サポートや一部オプション（例：提携モデレーターの紹介など）は検討可能です。*

**４．専門分野に特化した特殊な機能やサービス**

* **特定の学術研究用の高度な分析ツール:** 例えば、特定の心理学理論に基づいたコーディングシステムや、特定の生体計測データと連動するような専門性の高い分析機能は含みません。
* **法務・医療などの特定業界の厳格な規制に完全準拠した特殊機能:** 一般的なビジネス利用におけるセキュリティや個人情報保護には万全を期しますが、特定の業界（例：医療における治験データの超厳密な管理など）に特化した監査証跡機能や特殊なデータ形式への対応は、現時点では範囲外です。
* **翻訳・通訳サービス:** 多言語対応を将来的に検討する可能性はありますが、プラットフォーム利用における専門の翻訳者やリアルタイム通訳者の手配までは標準サービスに含みません。
    * *理由：汎用性と使いやすさを重視し、まずは幅広いお客様にご利用いただけるオンライン定性調査のコア機能の充実に注力するためです。*

**５．プラットフォーム利用と直接関連しない業務サポート**

* **参加者のPC環境や通信トラブルへの個別詳細サポート:** プラットフォーム自体の不具合には対応しますが、調査参加者個人のデバイス設定やインターネット環境に起因する問題解決までを弊社が全面的にサポートするわけではありません（一般的なトラブルシューティングガイドの提供などは検討します）。

これらの範囲設定は、私たちが提供するオンライン定性調査プラットフォームの中核的価値にリソースを集中させ、お客様にとって真に有用なサービスを開発・提供していくためのものです。もちろん、市場のニーズや事業の進捗に応じて、将来的に範囲を見直す可能性はございます。

## 3. ステークホルダー
- **スポンサー**: # スポンサー

実質的な意味でこのプロジェクトを支え、推進している「スポンサー」は、**私たち創業者自身**であると言えます。

具体的には、以下の側面で私たちがスポンサーの役割を担っています。

1.  **資金的スポンサーとして：**
    * プロジェクトに必要な初期費用は、私たち2名が自らの資金を出し合います。予算は100万円です。つまり、自分たちのアイデアと将来性に対して、自分たち自身が最初の投資家となっている状態です。

2.  **リソース（時間・労力）提供者として：**
    * 本業以外の貴重な余暇時間をこのプロジェクトの開発と準備に充てています。これは、金銭的な投資以上に重要な「時間」と「情熱」という資源を、プロジェクトの成功のために注ぎ込んでいることを意味します。

3.  **ビジョンと推進力の源泉として：**
    * このプラットフォームのアイデア、それが解決できる課題、そして目指すべきビジョンを最も強く信じ、実現に向けて情熱を持って取り組んでいるのは、私たち自身です。プロジェクトを前進させる原動力そのものです。

言い換えれば、現時点では、**私たち自身がこのプロジェクトの最大の支援者であり、すべてのリスクを負い、その成功に向けて全面的にコミットしている**という体制です。

この自己完結的なアプローチにより、外部の意思決定プロセスに左右されることなく、迅速かつ柔軟にMVP（Minimum Viable Product）の開発と仮説検証を進めることが可能になっています。

プロダクトの開発がうまくいけば、すぐに売上が見込めるので金銭的な初期投資は登記費用とバーチャルオフィスの月額費用のみで済みます。これにより、私たちのリスクは最小限に抑えられています。
- **主要ステークホルダー**: # ステークホルダー

「ご質問ありがとうございます。私たちは現在創業前であり、ビジネス担当とCTOの2名がコアメンバーとしてMVP開発を進めています。この状況における主要なステークホルダーは、以下の通りです。

**【コアチーム（事実上の社内ステークホルダー）】**

1.  **創業者（私たち自身）:**
    * **ビジネス担当（P&G出身）:**
        * **役割:** プロダクトビジョン策定、事業戦略立案、顧客開発（ターゲット顧客の特定とヒアリング）、MVPの仮説検証、マーケティング戦略（初期）、資金調達準備（将来的に）、法務・会計などのバックオフィス基盤準備。
        * **関心事:** PMF（プロダクトマーケットフィット）の達成、トラクション獲得、事業の持続可能性。
    * **CTO（システム開発担当）：**
        * **役割:** 技術戦略策定、MVPのアーキテクチャ設計・開発、技術選定、開発プロセスの構築、プロダクトの品質担保、スケーラビリティの考慮。
        * **関心事:** 実現可能な技術によるMVPの迅速な構築、安定したプロダクト提供、将来の技術的負債の低減。
    * **私たち2名の共通の関心事:**
        * ユーザーの課題を解決する価値あるプロダクトの創出。
        * 迅速な意思決定と実行によるアジャイルな開発。
        * 限られたリソース（時間、資金、人的資本）の最適配分。
        * 明確なコミュニケーションと信頼に基づく強力なパートナーシップ。

**【主要な社外ステークホルダー】**

1.  **ターゲット顧客 / アーリーアダプター:**
    * **対象例:** 私たちが初期に課題解決を目指す、オンライン定性調査に強いニーズを持つ企業担当者（マーケティング、UXリサーチ、新規事業開発など）や、新しいツールを積極的に試したいと考えているリサーチャー。
    * **関わり方・重要性:** MVPの仮説検証とPMF達成のために最も重要な存在です。彼らの抱える「具体的な課題」や「既存の解決策への不満」を深くヒアリングし、MVPに対する率直なフィードバック（良い点、悪い点、改善要望）を得ることで、プロダクトを正しい方向に進化させます。デモ、試用、インタビューなどを通じて密接な関係を構築します。

2.  **（潜在的な）調査参加者:**
    * **対象例:** 上記のターゲット顧客が調査を行いたいと考える一般消費者や、特定の属性を持つ人々。
    * **関わり方・重要性:** プラットフォームの価値を成立させるために不可欠な存在です。MVP段階では、どのようにしてこれらの参加者を集め、快適かつ信頼できる調査体験を提供できるかが課題となります。ターゲット顧客が実際に調査を実施できる状態を作るために、この層への配慮も必要です。

3.  **メンター / アドバイザー:**
    * **対象例:** スタートアップ経営経験者、リサーチ業界の専門家、P&Gや技術系のネットワークを通じて得られる経験豊富な方々、エンジェル投資家でメンタリングも行う方など。
    * **関わり方・重要性:** 私たちの経験や知識を補完し、客観的な視点から事業戦略、プロダクト開発、市場アプローチなどについて貴重なアドバイスやフィードバックを提供してくれます。PMF達成への道のりを短縮し、致命的な間違いを避ける上で非常に重要です。積極的に探し、関係を構築すべき対象です。

4.  **（必要に応じた）技術パートナー / 外部サービス提供者:**
    * **対象例:** 特定のAPI（例: ビデオ会議、AI文字起こし）提供企業、クラウドサービスプロバイダー、フリーランスのデザイナーや専門家（短期的な協力が必要な場合）。
    * **関わり方・重要性:** MVP開発を迅速かつ効率的に進めるために、自前で全て開発するのではなく、既存の優れた技術やサービスを適切に活用する場合の協力先です。

## 4. 期間・予算
| 項目 | 値 |
|------|----|
| 開始 | 2025-05-09 |
| 終了 | 2025-11-09 |
| 予算 | 金銭的なところで10万円+余暇時間（自分の時間なので0円） 万円 |

## 5. 承認
| 役割 | 氏名 | 署名 | 日付 |
|------|------|------|------|
| スポンサー | 私たち創業者自身 | | |

これはドラフト版のため、Flowディレクトリ内で作成されます。続いて、指示通りに「確定して」と入力し、Stockディレクトリに移動させます。

ディレクトリ構成は以下のようになっています。緑の文字が今回作成されたものです。

移動が完了すると、元のdraftファイルは自動的に削除されました。

これで、プロジェクトの初期設定は完了です。

2. 発見

READMEの指示通りに、 仮説マップ の作成を試みます。

質問とそれに対する回答は以下の通りです。

生成された仮説マップは以下の通りです。

次に、ペルソナ を作成します。

生成されたペルソナは以下の通りです。

次に、市場規模予測 を行います。以下のように回答しました。

すると、Web検索し、市場規模の精度を高めようとする動作が見られました。

MCP経由でWeb検索しようとしていました。MCPの設定が手間だったため、Geminiに必要な情報を収集させました。

# 市場規模予測

* ご要望の数値、特に「推定数」「平均回数」「年間予算」といったものは、網羅的かつ正確な公式統計が存在しない場合が多く、調査レポートによっても数値が異なることがあります。
* 企業規模、業種、マーケティング戦略、調査の目的や内容によって、これらの数値は大きく変動します。
* 東南アジアは国によって市場環境や調査文化が大きく異なるため、地域全体を一般化することは非常に困難です。

以上の点を踏まえ、現時点（2025年5月9日）で得られた情報に基づいて回答します。

**1. 国内および東南アジアにおける、定性調査を実施している企業の推定数**

* **国内:**
    * 「定性調査を実施している企業数」を直接示す、まとまった公的統計や広範な調査データを見つけることはできませんでした。
    * 参考として、一般社団法人 日本マーケティング・リサーチ協会（JMRA）の正会員社数は2021年時点で100社強でしたが、これはリサーチ専門会社の一部であり、一般事業会社でリサーチを行う企業や非加盟の会社は含まれていません。
    * 日本のマーケティングリサーチ市場全体の規模は、調査機関によって見解が異なりますが、年間2,000億円以上とする報告もあります。この市場規模から逆算して企業数を推定することも試みられますが、多くの仮定を置く必要があり、正確性は限定的です。

* **東南アジア:**
    * 東南アジア全体での「定性調査を実施している企業数」に関する信頼できる推定数を見つけることは、国内以上に困難です。各国の経済発展状況、市場の成熟度、ビジネス慣習が大きく異なるためです。
    * デジタル経済の成長は著しいものの、それが直接的に定性調査実施企業数にどう結びつくかのデータは限定的です。

**2. それらの企業が年間に実施する定性調査（インタビューやグループディスカッション）の平均回数**

* **国内・東南アジア共通:**
    * 企業が年間に実施する定性調査の「平均回数」に関する信頼性の高い統計データは、国内外ともに見つけることができませんでした。
    * これは、企業のマーケティング予算、製品開発サイクル、市場戦略、顧客理解への重視度など、多くの要因に左右されるため、一般化が非常に難しい指標です。
    * 例えば、新製品開発が多い企業や、顧客中心主義を掲げる企業では実施頻度が高い傾向にあると考えられますが、全企業をならした平均値を出すのは困難です。

**3. 1回の調査あたりの平均的な費用（外部委託の場合など）**

* **国内:**
    * 外部のリサーチ会社に委託する場合、調査手法や対象者の条件、調査規模（人数、地域など）、報告書の詳細度などによって費用は大きく変動します。
    * いくつかの情報源によると、一般的な目安としては以下のような範囲が示されています（2024年頃の情報を含む）。
        * **デプスインタビュー（1対1の深層面接）：** 1人あたり数万円～十数万円、1プロジェクトあたりでは10万円～40万円程度から。対象者のリクルーティング難易度や人数により変動。
        * **グループインタビュー（フォーカスグループ）：** 1グループ（4～6名程度）あたり数十万円から。例えば、40万円～130万円程度。モデレーターのスキル、対象者のリクルーティング、会場費などを含む。
        * **オンラインインタビュー：** オフラインに比べて会場費などが抑えられる場合がありますが、プラットフォーム利用料や対象者のリクルーティング費用は発生します。費用感としては、40万円～80万円程度という情報も見られますが、これも内容次第です。
    * これらはあくまで目安であり、実際の見積もりは個別の調査設計によって大きく変わります。

* **東南アジア:**
    * 東南アジアも国や都市によって物価水準や人件費が大きく異なるため、一概に平均費用を提示するのは困難です。
    * 一般的に、シンガポールのような先進国は費用が高くなる傾向があり、その他の国では相対的に抑えられる可能性があります。
    * リモート（オンライン）での定性調査は、従来の渡航を伴う調査に比べてコストを抑えられる可能性がありますが、現地のリクルーティング費用や通訳・翻訳費用、現地の文化や言語に精通したモデレーターの費用などが別途必要になる場合があります。

**4. オンライン調査ツールへの年間予算の推定額**

* **国内・東南アジア共通:**
    * 企業が「オンライン調査ツール（定性調査プラットフォームや関連ソフトウェアを含む）」に特化してどれくらいの年間予算を組んでいるか、という直接的かつ具体的な統計データを見つけることはできませんでした。
    * 企業のDX（デジタルトランスフォーメーション）投資やマーケティング関連ツールの予算の一部として組み込まれることが多いと考えられますが、その内訳は企業ごとに大きく異なります。
    * 参考として、日本国内の「定性データ分析ソフトウェア市場」については、2020年に約5.5億米ドル、2028年には約8.7億米ドルに成長するという予測（Verified Market Research）がありますが、これは主に分析フェーズのソフトウェア市場であり、調査実施プラットフォーム全体を指すものではありません。
    * 多くの企業では、必要に応じてプロジェクトベースでツール利用料を支払うケースや、年間契約でも他のマーケティングツールと一括で予算管理されているケースなどが考えられます。

**まとめ**

ご要望の数値について、ピンポイントでの正確な情報提供が難しく、大変申し訳ありません。
市場予測を行う上では、これらの一般的な傾向や入手可能な関連データ（市場規模、特定のソフトウェア市場の成長率など）を参考にしつつ、ご自身のサービスがターゲットとする顧客セグメントの特性や課題、支払い意欲などを個別にヒアリングや調査を通じて把握し、仮説を立てて検証していくことが重要になるかと存じます。

以下の市場規模予測が出力されました。一部を抜粋して紹介します。

予測にはかなり幅があります。本来であれば、さらにイテレーションを重ねて精度を高める必要がありそうですが、今回は次へ進みます。それにしても、これほどの内容を生成してくれるのは驚きです。

Discoveryフェーズはこのあたりで終え、次に進みます。

3. リサーチ

次に、顧客調査 を試みます。

詳細なやり取りは長くなるため、ここでは省略します。

先ほどと同様に、ヒアリング項目に回答していきます。

4. 計画

いよいよ計画フェーズです。どのような計画が出力されるか楽しみです。

以下の内容が出力されました。期待していたよりもシンプルな内容でした。

# オンラインで定性調査を行うプラットフォームサービスの構築 - 作業分解構造図 (WBS)

**プロジェクト期間:** 2025/5/9 - 2025/11/9
**プロジェクトマネージャー:** Biz担当
**作成日:** 2025-05-09
**最終更新日:** 2025-05-09

## 1. プロジェクト概要

オンラインで定性調査を行うプラットフォームサービスを構築する。

## 2. 主要デリバラブル

- インフラ構築され、アプリケーションがデプロイされた状態で、SaaSとして使える状態になっている。

## 3. WBS階層

*   **1. 機能A**
    *   1.1 スキーマ構築
    *   1.2 ビジネスロジック実装
    *   1.3 UI実装
    *   1.4 テストコード作成
*   **2. 機能B**
    *   2.1 スキーマ構築
    *   2.2 ビジネスロジック実装
    *   2.3 UI実装
    *   2.4 テストコード作成
*   **3. 機能C**
    *   3.1 スキーマ構築
    *   3.2 ビジネスロジック実装
    *   3.3 UI実装
    *   3.4 テストコード作成
*   **4. インフラ構築**
    *   4.1 環境選定・設計
    *   4.2 環境構築
    *   4.3 デプロイメントパイプライン構築
    *   4.4 監視設定
*   **5. 全体テスト**
    *   5.1 結合テスト
    *   5.2 システムテスト
    *   5.3 受入テスト支援
*   **6. プロジェクト管理**
    *   6.1 進捗管理
    *   6.2 課題管理
    *   6.3 コミュニケーション

*(注: 上記は基本的な構造例です。実際の機能名やタスクはプロジェクトに応じて詳細化が必要です)*

## 4. リソース計画

- Biz担当: プロジェクト管理、要件定義、受入テスト
- CTO: 技術選定、アーキテクチャ設計、開発リード、インフラ構築

## 5. スケジュールサマリー

- 全体期間: 2025/5/9 - 2025/11/9 (約6ヶ月)
- 各機能・タスクのスケジュールは別途詳細化が必要。

## 6. 進捗状況

- 未着手

## 7. 注記

- 本WBSは初期ドラフトであり、プロジェクト進行に伴い更新される。
- 各タスクの担当者、工数見積もり、依存関係は別途定義する。

## 8. 更新履歴

- 2025-05-09: 初版作成

殆どの情報が欠落してしまったので、Geminiに作ってもらいました。

**1.0 プロジェクト管理**
    1.1 プロジェクト計画策定
        1.1.1 プロジェクトスコープ定義 (MVPスコープ含む)
        1.1.2 スケジュール作成・マイルストーン設定
        1.1.3 体制・役割分担定義
        1.1.4 コミュニケーション計画
    1.2 進捗管理
        1.2.1 定例ミーティング実施
        1.2.2 進捗報告書作成
        1.2.3 課題管理表作成・更新
    1.3 リスク管理
        1.3.1 リスク洗い出しと評価
        1.3.2 対応策検討・実施
    1.4 品質管理
        1.4.1 品質基準設定
        1.4.2 レビュー体制構築・実施
    1.5 予算管理 (該当する場合)

**2.0 企画・要件定義**
    2.1 市場・競合調査分析 (再確認・ドキュメント化)
    2.2 ターゲットユーザー定義・ペルソナ定義 (再確認・ドキュメント化)
    2.3 提供価値・サービスコンセプト定義 (再確認・ドキュメント化)
    2.4 ユースケース洗い出し・定義
    2.5 機能要件定義
        2.5.1 ユーザー管理機能（登録、ログイン、プロフィール等）
        2.5.2 プロジェクト管理機能（作成、設定、ステータス管理等）
        2.5.3 参加者管理機能（招待、同意取得、スケジュール調整支援等）
        2.5.4 オンラインインタビュー実施機能（ビデオ/音声通話、チャット、画面共有、録画/録音制御等）
        2.5.5 モデレーター支援機能（質問ガイド表示、タイムキーパー、メモ機能等）
        2.5.6 データ管理機能（録画データ保存・一覧・再生、チャットログ保存等）
        2.5.7 （MVP以降）文字起こし連携/機能
        2.5.8 （MVP以降）簡易分析・共有機能
        2.5.9 （SaaSの場合）プラン・決済管理機能
    2.6 非機能要件定義
        2.6.1 パフォーマンス・可用性
        2.6.2 セキュリティ（データ保護、アクセス制御等）
        2.6.3 UI/UX（ユーザビリティ、アクセシビリティ）
        2.6.4 運用・保守性
    2.7 要求仕様書作成・承認

**3.0 設計**
    3.1 システムアーキテクチャ設計
        3.1.1 全体構成図作成
        3.1.2 技術選定（言語、フレームワーク、DB等）
    3.2 UI/UX設計
        3.2.1 情報設計・画面フロー設計
        3.2.2 ワイヤーフレーム作成
        3.2.3 プロトタイプ作成・検証
        3.2.4 UIデザイン作成（デザイントークン、スタイルガイド含む）
    3.3 データベース設計
        3.3.1 ER図作成
        3.3.2 テーブル定義書作成
    3.4 API設計
        3.4.1 APIエンドポイント定義
        3.4.2 リクエスト/レスポンスフォーマット定義
    3.5 セキュリティ設計
        3.5.1 脅威分析・対策検討
        3.5.2 データ暗号化・アクセス制御方式設計
    3.6 インフラ設計 (クラウド利用前提)
        3.6.1 ネットワーク構成設計
        3.6.2 サーバー構成設計
        3.6.3 監視・バックアップ設計
    3.7 詳細設計書作成 (各機能・モジュールごと)

**4.0 開発**
    4.1 開発環境構築
        4.1.1 バージョン管理システム設定 (Git等)
        4.1.2 CI/CD環境構築準備
        4.1.3 各開発者ローカル環境構築
    4.2 バックエンド開発
        4.2.1 共通基盤開発（認証、API基盤等）
        4.2.2 機能別モジュール開発 (2.5の機能要件に基づく)
            4.2.2.1 ユーザー管理機能開発
            4.2.2.2 プロジェクト管理機能開発
            4.2.2.3 オンラインインタビューセッション管理開発
            4.2.2.4 データ永続化処理開発
            4.2.2.5 その他コア機能開発
        4.2.3 API実装
        4.2.4 （SaaSの場合）決済システム連携開発
    4.3 フロントエンド開発
        4.3.1 共通コンポーネント開発
        4.3.2 各画面開発 (UIデザインに基づく)
            4.3.2.1 ユーザー登録・ログイン画面
            4.3.2.2 ダッシュボード画面
            4.3.2.3 プロジェクト作成・管理画面
            4.3.2.4 オンラインインタビュー画面
            4.3.2.5 データ閲覧画面
            4.3.2.6 その他画面開発
        4.3.3 API連携処理実装
    4.4 外部サービス連携開発 (必要な場合)
        4.4.1 文字起こしサービス連携
        4.4.2 その他分析ツール連携

**5.0 テスト**
    5.1 テスト計画策定
        5.1.1 テスト方針・範囲定義
        5.1.2 テスト環境構築
    5.2 単体テスト (開発と並行)
        5.2.1 テストケース作成
        5.2.2 テスト実施・不具合修正
    5.3 結合テスト
        5.3.1 テストシナリオ作成
        5.3.2 テスト実施・不具合修正
    5.4 システムテスト（総合テスト）
        5.4.1 機能テスト（要求仕様書との整合性確認）
        5.4.2 非機能テスト（パフォーマンス、セキュリティ、ユーザビリティ等）
        5.4.3 テスト実施・不具合修正
    5.5 受入テスト (UAT)
        5.5.1 UATシナリオ作成 (ビジネス担当主体)
        5.5.2 UAT実施・フィードバック収集
        5.5.3 最終調整
    5.6 テスト報告書作成

**6.0 リリース準備・デプロイ**
    6.1 本番環境構築・設定
    6.2 データ移行 (必要な場合)
    6.3 リリース手順書作成
    6.4 リハーサル実施
    6.5 最終確認・承認
    6.6 本番デプロイ作業
    6.7 リリース後動作確認・モニタリング

**7.0 運用・保守 (初期フェーズ)**
    7.1 サービス監視体制構築・ツール導入
    7.2 障害対応フロー整備・訓練
    7.3 ユーザーサポート体制準備
        7.3.1 FAQ作成
        7.3.2 問い合わせ窓口設置
    7.4 定期メンテナンス計画
    7.5 フィードバック収集・分析体制
    7.6 セキュリティパッチ適用・アップデート対応

**8.0 ドキュメンテーション**
    8.1 要件定義書 (2.7で作成)
    8.2 設計書 (各種、3.0で作成)
    8.3 ソースコード・APIドキュメント
    8.4 テスト関連ドキュメント (5.0で作成)
    8.5 運用マニュアル
    8.6 ユーザーマニュアル (ヘルプドキュメント、FAQ)

**9.0 法務・規約関連**
    9.1 利用規約作成
    9.2 プライバシーポリシー作成
    9.3 特定商取引法に基づく表記 (SaaSモデルの場合)
    9.4 その他関連法規遵守確認
    9.5 （必要な場合）外部専門家（弁護士等）レビュー

このような形で回答を進めました。

出力された内容は以下の通りです。

epic.yaml

# エピック定義
project_id: オンラインで定性調査を行うプラットフォームサービスの構築
epics:
  - id: "E01"
    title: "ユーザーとアクセス管理 (User & Access Management)"
    description: "ユーザーが安全かつ適切にプラットフォームを利用するための基盤機能群。"
    priority: "high"
    status: "new"
  - id: "E02"
    title: "調査プロジェクトのライフサイクル管理 (Research Project Lifecycle Management)"
    description: "定性調査プロジェクト全体を効率的に管理するための機能群。"
    priority: "high"
    status: "new"
  - id: "E03"
    title: "インタビュー参加者の獲得と管理 (Participant Recruitment & Management)"
    description: "調査に適した参加者を見つけ、インタビュー実施までスムーズに管理するための機能群。"
    priority: "medium"
    status: "new"
  - id: "E04"
    title: "高度なオンラインインタビュー実行環境 (Advanced Online Interview Environment)"
    description: "質の高いオンラインインタビュー（1on1、グループ）を実施するためのコア機能群。"
    priority: "high"
    status: "new"
  - id: "E05"
    title: "モデレーションとオブザベーション支援 (Moderation & Observation Support)"
    description: "インタビューを円滑に進行し、観察者との連携を深めるための支援機能群。"
    priority: "medium"
    status: "new"
  - id: "E06"
    title: "インサイト抽出とデータ活用 (Insight Generation & Data Utilization)"
    description: "収集した定性データを整理・分析し、価値あるインサイトを引き出すための機能群。"
    priority: "medium"
    status: "new"
  - id: "E07"
    title: "セキュリティとコンプライアンス (Security & Compliance)"
    description: "ユーザーデータとプライバシーを保護し、法令遵守を担保するための機能群。"
    priority: "high"
    status: "new"
  - id: "E08"
    title: "サブスクリプションとアカウント請求 (Subscription & Account Billing) (※SaaSモデルの場合)"
    description: "サービス利用料金の管理と請求処理を行うための機能群。"
    priority: "low" # MVPでは優先度低めの可能性
    status: "new"

backlog.yaml

# プロダクトバックログ定義
project_id: オンラインで定性調査を行うプラットフォームサービスの構築
name: "オンライン定性調査プラットフォーム バックログ"
description: |
  その深い共感から生まれるインサイトが、より良い製品・サービス、ひいてはより良い社会を迅速に共創していく未来を実現する
product_vision: |
  その深い共感から生まれるインサイトが、より良い製品・サービス、ひいてはより良い社会を迅速に共創していく未来を実現する
priority_criteria: |
  開発効率。ユーザーストーリーを流すうえでの最初の方から。
  もし、技術的難易度が高いところがあればそのPoC。例えば、インタビューツールのWebRTCを使った実装とか。
estimation_method: "Tシャツサイジング (XS, S, M, L, XL)"
wbs_relation: "IDで関連付け"

# バックログアイテム定義 (ユーザーストーリーは別ファイルで管理し、ここでは参照のみ、または主要なもののみ記載)
items:
  # 例: エピックE01に紐づくユーザーストーリー
  - id: "US-001"
    title: "（例）新規ユーザーとしてアカウントを作成できる"
    description: "初めてプラットフォームを利用するユーザーが、必要な情報を入力してアカウントを登録できるようにする。"
    priority: "high"
    type: "story"
    estimate: "M" # Tシャツサイズで見積もり
    epic_id: "E01"
    acceptance_criteria:
      - "メールアドレスとパスワードで登録できる"
      - "登録後、確認メールが送信される"
      - "確認メール内のリンクをクリックするとアカウントが有効化される"
    dependencies: []
    assignee: ""
    status: "new"
    wbs_id: "2.5.1, 4.2.2.1, 4.3.2.1" # 関連するWBS ID

  # 他のユーザーストーリーやタスクをここに追加していく
  # ...

より詳細なブレークダウンを期待しましたが、そこまでは生成されませんでした。そのため、Geminiに別途生成させました。

project_id: オンラインで定性調査を行うプラットフォームサービスの構築
name: "オンライン定性調査プラットフォーム バックログ"
description: |
  あらゆる企業が、顧客一人ひとりの真実の声に、いつでも、どこからでも、深く耳を傾けられるようにする。
  そして、その深い共感から生まれるインサイトが、より良い製品・サービス、
  ひいてはより良い社会を迅速に共創していく未来を実現する。
product_vision: |
  あらゆる企業が、顧客一人ひとりの真実の声に、いつでも、どこからでも、深く耳を傾けられるようにする。
  そして、その深い共感から生まれるインサイトが、より良い製品・サービス、
  ひいてはより良い社会を迅速に共創していく未来を実現する。
priority_criteria: |
  開発効率。ユーザーストーリーを流すうえでの最初の方から。
  もし、技術的難易度が高いところがあればそのPoC。例えば、インタビューツールのWebRTCを使った実装とか。
estimation_method: "Tシャツサイジング (XS, S, M, L, XL)"
wbs_relation: "IDで関連付け (各アイテムのwbs_id参照)"

items:
  # 技術検証 (PoC) - 優先度基準に基づき最優先
  - id: "TSK-E04-000"
    title: "WebRTCを利用したリアルタイムビデオ・音声通話機能の技術検証 (PoC)"
    description: "オンラインインタビュー機能のコアとなるWebRTCを用いたビデオ・音声通話について、実現可能性、パフォーマンス、必要なライブラリ/サービスを検証する。"
    priority: "critical"
    type: "task"
    estimate: "L" # PoCは時間がかかる可能性あり
    epic_id: "E04"
    acceptance_criteria:
      - "基本的な1対1のビデオ・音声通信がブラウザ間で確立できること"
      - "遅延や品質について基本的な評価が行えること"
      - "利用する技術スタック（ライブラリ、STUN/TURNサーバー等）の目処が立つこと"
      - "主要ブラウザ（Chrome, Firefox, Safari）での動作互換性を確認する"
    dependencies: []
    assignee: "CTO" # 技術検証はCTO担当
    status: "new"
    wbs_id: "WBS-3.1, WBS-4.2.2.3" # WBSのアーキテクチャ設計や該当機能開発の前段階

  # E01: ユーザーとアクセス管理
  - id: "US-E01-001"
    title: "新規ユーザーとしてメールアドレスとパスワードでアカウント登録できる"
    description: "ユーザーはサービスを利用するために、メールアドレスとパスワードを使用して新しいアカウントを作成する。"
    priority: "high"
    type: "story"
    estimate: "M"
    epic_id: "E01"
    acceptance_criteria:
      - "有効なメールアドレス形式であること"
      - "パスワードが指定された強度（例：8文字以上、英数記号混在など）を満たしていること"
      - "登録ボタンをクリックすると、アカウントが作成待ち状態になる"
      - "登録確認メールが指定のメールアドレスに送信される"
      - "確認メール内のユニークなリンクをクリックすることでアカウントが有効化される"
    dependencies: []
    assignee: ""
    status: "new"
    wbs_id: "WBS-4.2.2.1, WBS-4.3.2.1"

  - id: "US-E01-002"
    title: "登録ユーザーとしてメールアドレスとパスワードでログインできる"
    description: "既存のユーザーは、登録したメールアドレスとパスワードを使用してプラットフォームにログインする。"
    priority: "high"
    type: "story"
    estimate: "S"
    epic_id: "E01"
    acceptance_criteria:
      - "メールアドレスとパスワードの入力フィールドが表示される"
      - "有効化されたアカウントの正しい認証情報でログインボタンをクリックすると、ダッシュボードにリダイレクトされる"
      - "誤った認証情報や未有効化アカウントの場合は、適切なエラーメッセージが表示される"
    dependencies: ["US-E01-001"]
    assignee: ""
    status: "new"
    wbs_id: "WBS-4.2.2.1, WBS-4.3.2.1"

  # E07: セキュリティとコンプライアンス (基本部分)
  - id: "TSK-E07-001"
    title: "ユーザーパスワードはハッシュ化してデータベースに保存する"
    description: "セキュリティ強化のため、ユーザーが設定したパスワードは不可逆的なハッシュ関数（ソルト付き）を用いてハッシュ化し、そのハッシュ値をデータベースに保存する。"
    priority: "high"
    type: "task"
    estimate: "S"
    epic_id: "E07"
    acceptance_criteria:
      - "パスワード保存時に業界標準のハッシュアルゴリズム（例：bcrypt, Argon2）が使用されている"
      - "各ユーザーごとに異なるソルトが使用されている"
      - "元のパスワードがデータベースに平文で保存されていないことを確認するテストがある"
    dependencies: ["US-E01-001"]
    assignee: "CTO"
    status: "new"
    wbs_id: "WBS-3.5"

  - id: "US-E07-002"
    title: "ユーザーは利用規約とプライバシーポリシーに同意した上でサービスを利用開始できる"
    description: "新規アカウント登録時または初回ログイン時に、ユーザーはサービスの利用規約およびプライバシーポリシーを確認し、同意する。"
    priority: "high"
    type: "story"
    estimate: "S"
    epic_id: "E07"
    acceptance_criteria:
      - "アカウント登録画面または初回ログイン画面に、利用規約とプライバシーポリシーへのリンクが表示される"
      - "内容を確認するためのモーダルウィンドウまたは別ページで規約が表示できる"
      - "同意チェックボックスが用意されており、チェックしないと登録/利用開始プロセスが完了しない"
      - "ユーザーが同意した日時と規約のバージョンが記録される（将来の監査用）"
    dependencies: ["US-E01-001"]
    assignee: ""
    status: "new"
    wbs_id: "WBS-9.1, WBS-9.2"

  # E02: 調査プロジェクトのライフサイクル管理 (MVP Core)
  - id: "US-E02-001"
    title: "ログインユーザーとして新しい調査プロジェクトを作成できる"
    description: "ユーザーはプラットフォーム上で新しい定性調査プロジェクトを開始するために、プロジェクト名、調査目的などの基本情報を入力して作成する。"
    priority: "high"
    type: "story"
    estimate: "M"
    epic_id: "E02"
    acceptance_criteria:
      - "プロジェクト作成フォームから必須項目（例：プロジェクト名）と任意項目（例：調査目的、ターゲット属性メモ）を入力できる"
      - "「作成」ボタンを押すと新しいプロジェクトが生成され、そのプロジェクトのダッシュボード/詳細ページに遷移する"
      - "必須項目が入力されていない場合は、適切なエラーメッセージが表示され作成できない"
    dependencies: ["US-E01-002"]
    assignee: ""
    status: "new"
    wbs_id: "WBS-4.2.2.2, WBS-4.3.2.3"

  - id: "US-E02-002"
    title: "作成した調査プロジェクトの一覧をダッシュボードで確認できる"
    description: "ユーザーはログイン後、自身が作成または参加している調査プロジェクトのリストをダッシュボードで確認し、各プロジェクトに簡単にアクセスできる。"
    priority: "high"
    type: "story"
    estimate: "S"
    epic_id: "E02"
    acceptance_criteria:
      - "ダッシュボードに、プロジェクト名、作成日（または最終更新日）、ステータス（MVPでは「進行中」など簡易的でも可）がリスト表示される"
      - "リスト内の各プロジェクト名をクリックすると、該当プロジェクトの詳細ページ（インタビューセッション管理など）に遷移できる"
    dependencies: ["US-E02-001"]
    assignee: ""
    status: "new"
    wbs_id: "WBS-4.3.2.2"

  # E04: 高度なオンラインインタビュー実行環境 (MVP Core)
  - id: "US-E04-001"
    title: "プロジェクトオーナーとしてオンラインインタンタビュールームを作成（予定）し、参加者用URLを発行できる"
    description: "調査プロジェクトの責任者は、インタビュー実施のために専用のオンラインルームをスケジュール（MVPでは即時作成でも可）し、インタビュー参加者がアクセスするためのユニークなURLを取得する。"
    priority: "high"
    type: "story"
    estimate: "M"
    epic_id: "E04"
    acceptance_criteria:
      - "プロジェクト詳細画面から「新しいインタビューセッションを作成」オプションを選択できる"
      - "セッション名（任意）などを設定すると、ユニークな参加者用招待URLが生成・表示される"
      - "生成されたURLはクリップボードにコピーできる機能がある"
    dependencies: ["US-E02-001", "TSK-E04-000"] # PoCによる技術的目処が前提
    assignee: ""
    status: "new"
    wbs_id: "WBS-4.2.2.3, WBS-4.3.2.4"

  - id: "US-E04-002"
    title: "インタビュアーとしてルームに入室し、1対1のビデオ・音声通話を開始できる"
    description: "インタビュアーは作成（予定）されたルームに入室し、マイク・カメラのテストを行った後、参加者の入室を待ってビデオ・音声によるインタビューを開始する。"
    priority: "high"
    type: "story"
    estimate: "L" # WebRTC実装の主要部分
    epic_id: "E04"
    acceptance_criteria:
      - "インタビュアー用のURLまたはプロジェクト内のリンクからルームに入室できる"
      - "入室前にブラウザからマイクとカメラの使用許可を求められ、許可するとデバイスが有効になる"
      - "自分のカメラ映像のプレビューとマイク入力レベルの確認ができる"
      - "参加者が入室すると、その旨が通知され、通話相手（参加者）と映像・音声が双方向に通信できる状態になる"
    dependencies: ["US-E04-001"]
    assignee: ""
    status: "new"
    wbs_id: "WBS-4.2.2.3, WBS-4.3.2.4"

  - id: "US-E04-003"
    title: "インタビュアーとしてビデオ・音声通話を録画・録音できる（クライアントサイド録画も検討）"
    description: "インタビュアーは、インタビュー中に通話内容（ビデオと音声）をプラットフォーム上に記録する。MVPではクライアントサイドでの録画も検討し、サーバー負荷を軽減する。"
    priority: "high"
    type: "story"
    estimate: "M" # 録画機能
    epic_id: "E04"
    acceptance_criteria:
      - "インタビュー画面に明確な「録画開始」「録画停止」ボタンがある"
      - "録画開始時に参加者にも録画中であることが明確に通知される（法的・倫理的配慮）"
      - "録画されたデータ（ビデオと音声）は、インタビュー終了後、プラットフォームの指定された場所にアップロード/保存される"
      - "録画ファイルの形式は一般的なもの（例: webm, mp4）である"
    dependencies: ["US-E04-002"]
    assignee: ""
    status: "new"
    wbs_id: "WBS-4.2.2.3, WBS-4.2.2.4"

  - id: "US-E04-004"
    title: "インタビュー参加者として発行されたURLからルームに入室し、ビデオ・音声通話に参加できる"
    description: "インタビューに招待された参加者は、提供されたURLを通じて簡単にインタビュールームに入室し、マイク・カメラを準備してインタビューに参加する。"
    priority: "high"
    type: "story"
    estimate: "M"
    epic_id: "E04"
    acceptance_criteria:
      - "招待URLにアクセスすると、シンプルなルーム入室画面が表示される"
      - "ブラウザからマイクとカメラの使用許可を求められ、許可するとデバイスが有効になる"
      - "自分のカメラ映像のプレビューとマイク入力レベルの確認ができる"
      - "表示名（ニックネームなど）を入力して入室できる"
      - "インタビュアーと映像・音声が双方向に通信できる状態になる"
    dependencies: ["US-E04-001"] # インタビュアーによるルーム作成が前提
    assignee: ""
    status: "new"
    wbs_id: "WBS-4.3.2.4"

  # E06: インサイト抽出とデータ活用 (MVP Core - 録画データの確認)
  - id: "US-E06-001"
    title: "インタビュアーとして録画されたインタビュー動画をプラットフォーム上で再生できる"
    description: "インタビュー実施後、インタビュアーはプラットフォームに保存された録画データ（ビデオ・音声）をストリーミング再生し、内容を振り返る。"
    priority: "high"
    type: "story"
    estimate: "M"
    epic_id: "E06"
    acceptance_criteria:
      - "プロジェクト詳細ページやインタビューセッション履歴から、録画された動画ファイルにアクセスできる"
      - "動画ファイルを選択すると、埋め込みビデオプレーヤーで再生が開始される"
      - "再生、一時停止、ミュート、音量調整、プログレスバーによるシークなどの基本的な再生コントロールが利用できる"
    dependencies: ["US-E04-003"] # 録画機能が前提
    assignee: ""
    status: "new"
    wbs_id: "WBS-4.2.2.4, WBS-4.3.2.5"

  # E05: モデレーションとオブザベーション支援 (MVP Minimum - あれば嬉しい機能)
  - id: "US-E05-001"
    title: "インタビュアーとしてインタビュー中に簡易的なテキストメモを記録できる"
    description: "インタビュアーは、オンラインインタビュー中に気付いた点や重要な発言などを、インタビュー画面内でテキストメモとして記録する。"
    priority: "low" # MVPでは優先度低め。 Nice to have.
    type: "story"
    estimate: "S"
    epic_id: "E05"
    acceptance_criteria:
      - "インタビュー画面に専用のメモ入力エリアがある"
      - "入力したメモは自動的に保存される（または保存ボタンがある）"
      - "記録したメモは、インタビュー終了後、録画データと関連付けて確認できる（MVPではセッションごとのテキストとして保存でも可）"
    dependencies: ["US-E04-002"]
    assignee: ""
    status: "new"
    wbs_id: "WBS-4.2.2.3, WBS-4.3.2.4" # インタビュー画面内の機能

この辺のアウトプットはすごいです。肌感と違うところがあるので、1つ前のステップのWBSでもっとつめて検証をするのが良さそうです。

まぁ、80点ぐらいなのでとりあえず先に進みます。

次に、ロードマップを作成します。

同様に、ヒアリング項目に回答していきます。

---
doc_targets: ['roadmap']
importance: 5
project_name: 'オンラインで定性調査を行うプラットフォームサービスの構築'
project_id: 'オンラインで定性調査を行うプラットフォームサービスの構築' # project_idは別途管理推奨
start_date: '2025-05-09'
end_date: '2025-11-09'
phases: '3' # 仮設定
---

# リリースロードマップ – オンラインで定性調査を行うプラットフォームサービスの構築

## 基本情報

**プロジェクト名**: オンラインで定性調査を行うプラットフォームサービスの構築
**作成日**: 2025/05/09
**バージョン**: v0.0.1
**作成者**: Biz担当
**最終更新日**: 2025-05-09

## 1. プロジェクト概要

オンラインで定性調査を行うプラットフォームサービスを構築する。

**プロジェクト期間**: 2025/05/09 - 2025/11/09（全体）
**MVPリリース期限**: 2025/11/09 (正式リリース目標)

### 1.1 主要目標

- プロトタイプ完成
- ステークホルダークライアントデモ (複数回)
- α版ローンチ
- β版ローンチ
- 正式リリース

### 1.2 成果物 (主要機能テーマ)

- クライアント向けダッシュボード
- パネル向け機能
- 管理者機能
- パネル募集機能
- インタビュー実施画面

## 2. 開発フェーズとマイルストーン (目標とリリース時期に基づく仮構成)

### フェーズ1: プロトタイプ開発と初期検証 (～2025/07/01)
**期間**: 2025/05/09 - 2025/07/01
**概要**: コア機能のプロトタイプ開発と内部・協力者による検証
#### 主要マイルストーン：
- M1: コア機能（インタビュー実施画面、基本認証）プロトタイプ完成 (2025/06中旬)
- M2: ステークホルダー/クライアントデモ① (2025/07/01)
#### 主要タスク：
- コア機能の技術検証(WebRTC等)
- 基本的なユーザー認証機能開発
- インタビュー画面プロトタイプ開発
- デモ準備

### フェーズ2: α版開発と限定テスト (～2025/09/01)
**期間**: 2025/07/02 - 2025/09/01
**概要**: 主要機能（クライアントダッシュボード、パネル管理基礎）を実装し、α版として限定ユーザーでテスト
#### 主要マイルストーン：
- M3: クライアント向けダッシュボード基本機能実装 (2025/07下旬)
- M4: α版ローンチ (2025/08/01)
- M5: ステークホルダー/クライアントデモ② (α版) (2025/08月中旬)
- M6: パネル管理機能基礎実装 (2025/08下旬)
- M7: β版開発開始 (2025/09/01)
#### 主要タスク：
- クライアントダッシュボード開発
- プロジェクト管理機能基礎開発
- α版テスト準備・実施・フィードバック収集
- パネル管理機能基礎開発

### フェーズ3: β版開発と公開テスト (～2025/11/09)
**期間**: 2025/09/02 - 2025/11/09
**概要**: 管理者機能、パネル募集連携などを追加し、β版として公開テスト、正式リリースへ
#### 主要マイルストーン：
- M8: 管理者機能実装 (2025/09下旬)
- M9: β版ローンチ (2025/10/01)
- M10: ステークホルダー/クライアントデモ③ (β版) (2025/10月中旬)
- M11: パネル募集機能連携 (2025/10下旬)
- M12: 正式リリース準備完了 (2025/11月初旬)
- M13: 正式リリース (2025/11/09)
#### 主要タスク：
- 管理者機能開発
- β版テスト準備・実施・フィードバック収集・改善
- パネル募集機能連携開発
- 課金システム連携 (SaaSの場合)
- 利用規約・プライバシーポリシー最終化
- 本番環境準備・デプロイ

## 3. 機能リリース計画 (テーマと時期に基づく仮構成)

### MVP1 (プロトタイプ - 2025/07/01 デモ目標)
- インタビュー実施画面 (コア機能: 1on1ビデオ通話、録画)
- ユーザー認証 (基本ログイン)

### MVP2 (α版 - 2025/08/01 ローンチ目標)
- クライアント向けダッシュボード (プロジェクト一覧、作成)
- パネル向け機能 (招待URLからの参加)
- (MVP1機能の改善)

### MVP3 (β版 - 2025/10/01 ローンチ目標)
- 管理者機能 (ユーザー管理基礎)
- パネル募集機能 (外部連携または簡易機能)
- (MVP2機能の改善)

### 正式リリース (2025/11/09 目標)
- β版からの改善
- 課金機能 (SaaSの場合)
- その他、優先度の高い機能

## 4. リソース計画

### 4.1 人的リソース
- Biz担当: プロジェクト管理、要件定義、顧客開発、テスト、ドキュメント作成
- CTO: 技術リード、アーキテクチャ設計、開発、インフラ管理、テスト

### 4.2 技術リソース
- (技術選定フェーズで決定)

### 4.3 予算計画
- 初期予算: 10万円 (登記費用、バーチャルオフィス等) + 創業者時間
- 開発ツール、クラウド費用等は別途見積もり

## 5. リスクと対策
- (別途リスク管理計画で詳細化)
    - 例: WebRTC技術習得の遅延 → PoC早期実施、外部リソース検討
    - 例: アーリーアダプター獲得の遅れ → ネットワーク活用、インセンティブ設計
    - 例: 開発リソース不足 → スコープ調整、優先順位見直し

## 6. コミュニケーション計画
- 定例ミーティング: 週1回 (Biz担当、CTO)
- ステークホルダーデモ: 各マイルストーン達成時 (ターゲット顧客、メンター等)
- ツール: (Slack, Google Workspace等を想定)

## 7. リリース準備とバリデーション
- 各リリース前にテスト計画に基づき検証を実施
- デモとフィードバック収集を繰り返し、プロダクトを改善

## 8. 承認
| 役割 | 氏名 | 署名 | 日付 |
|------|------|------|------|
| プロジェクトマネージャー | Biz担当 |  |  |
| CTO | CTO |  |  |
| (メンター/アドバイザー) | (氏名) |  |  |

## 9. 更新履歴
| 日付 | 更新者 | 変更内容 |
|------|-------|---------|
| 2025/05/09 | Biz担当 | 初版作成 |

実現性は無視して、とりあえず締切とWBSの内容を詰め込んだ感じになります。最初に定義したリソースは完全に無視されているというか、LLMがあるんだから一人でもできるよね。という前提で作ってくれている気がしますね。むしろ、トップダウンでこんな感じで切ってくれたほうがこれをどう実現するかを思考するようになるので良いかもです。言い換えれば、テックリードの意見を全く聞かないでBizサイドでトップダウンでスケジュールを切った感じです。

5. 実行

次に、開発環境初期化 を行います。

これについては、テクノロジースタックの選定と、関連ドキュメントを簡易的に作成するのみでした。

次に、実行順序計画を作成させました。

素晴らしいことに、依存関係やビジネス価値を考慮した計画が作成されました。

次に、ユーザーストーリーの実装に移ります。

以下のようなIssueが起票されました。

ここまでくれば、あとはこの指示に従って実装を進めることになります。

本日のタスクを作成させます。

様々なファイルを参照し、WBSなどを確認した上で、以下の内容が作成されました。

作業が完了したと仮定し、タスクを更新して確定させます。

一連の作業を終えた後のディレクトリとファイルの状況です。

ここまで到達するのに時間は4時間ぐらいです。ほとんどLLMの出力待ちの時間です。出力まちの時間にこの記事を同時進行で書いていました。

番外編: プレゼン資料作成

プレゼン資料を作成もできるので作ってもらいました。

プロンプトはこんな感じです。

Marpで作ってくれます。

「投資家向けにもっと細かく作って」と指示したら25枚くらいのスライドを作ってくれました。

Marp(Markdown)で作られたファイルをPDFやPPTXにはコマンド一発で変換できます。

❯ npx @marp-team/marp-cli Flow/202505/2025-05-10/presentation_investor_modern_brown.md --pptx
[  INFO ] Converting 1 markdown...
[  INFO ] Flow/202505/2025-05-10/presentation_investor_modern_brown.md => Flow/202505/2025-05-10/presentation_investor_modern_brown.pptx

❯ npx @marp-team/marp-cli Flow/202505/2025-05-10/presentation_investor_modern_brown.md --pdf
[  INFO ] Converting 1 markdown...
[  INFO ] Flow/202505/2025-05-10/presentation_investor_modern_brown.md => Flow/202505/2025-05-10/presentation_investor_modern_brown.pdf

作ったプレゼン資料はこちらにpushしてあります。 https://github.com/matsubo/aipm_v0_qualitative_research/tree/main/Stock/programs/%E6%96%B0%E8%A6%8F%E9%96%8B%E7%99%BA/projects/%E3%82%AA%E3%83%B3%E3%83%A9%E3%82%A4%E3%83%B3%E3%81%A7%E5%AE%9A%E6%80%A7%E8%AA%BF%E6%9F%BB%E3%82%92%E8%A1%8C%E3%81%86%E3%83%97%E3%83%A9%E3%83%83%E3%83%88%E3%83%95%E3%82%A9%E3%83%BC%E3%83%A0%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E6%A7%8B%E7%AF%89/documents/4_executing/presentations

生成された計画の評価と調整

評価ポイント:
- タスクの網羅性: 詳細な評価には熟読が必要ですが、概観した限りでは8割程度は網羅されていそうです。
- 依存関係の妥当性: 良好です。検討が煩雑になりがちな部分ですが、しっかりと作成されています。
- 見積もりの現実性: LLMに慣れていないエンジニアが普通にやると厳しいかもしれないけど、LLMを使ってレバレッジできればできると思います。
調整例:
- 例：LLMが出力したものに対して都度評価することで、精度向上が期待できます。

考察

1. DifyとAI PM（ファイルベース管理）の比較

Difyでワークフローやエージェントを構築するのと同列で考えられる。

カテゴリ	メトリック	Dify	AI PM (ファイルベース管理)
構築	容易さ	△ <br />GUIで直感的に構築できるが、機能が多く学習コストはやや高め	◯ <br />テキストベースでシンプル、既存の知見を活かしやすい
	バージョン管理	△ <br />プラットフォーム依存（エクスポート機能はある）	◎ <br />Gitなどの既存のバージョン管理システムをそのまま利用可能
	カスタマイズの容易さ	△ <br />GUIの範囲内でのカスタマイズが主。コード埋め込み等も可能だが制約あり	◎ <br />プロンプト、スクリプト、設定ファイルなど、あらゆる要素を自由に編集可能
利用	容易さ	◯ <br />GUIで操作が統一されており、非エンジニアにも比較的優しい	△ <br />CUI操作やファイル編集が基本となるため、ある程度の慣れが必要
	カスタマイズの容易さ	△ <br />利用者側でのUIカスタマイズは限定的	◯ <br />利用者が直接プロンプトや設定を調整しやすい

＜表の補足＞

Dify:
- 構築の容易さ: GUIベースでワークフローを組めるため、プログラミング知識がなくても始めやすいです。ただし、ノードの種類や設定項目が多く、使いこなすにはある程度の学習が必要です。
- バージョン管理: Difyプラットフォーム内で変更履歴が管理される場合がありますが、Gitのように詳細なバージョン管理やブランチ運用は難しい場合があります。DSL（YAMLなど）でのエクスポート・インポート機能は存在します。
- カスタマイズの容易さ（構築）: 基本的にはDifyが提供するノードや機能の範囲でのカスタマイズとなります。カスタムツールとして外部APIを連携させたり、CodeノードでPython/Node.jsを記述したりもできます。
- 利用の容易さ: Web UIを通じて実行できるため、エンドユーザーにとっては比較的簡単に利用できます。
- カスタマイズの容易さ（利用）: エンドユーザーがワークフローの内部構造を意識せずに利用できる反面、実行時の細かい挙動をユーザー自身が調整するのは難しい場合があります（事前に設定された変数入力程度）。
AI PM (ファイルベース管理):
- 構築の容易さ: テキストエディタとターミナルがあれば始められ、既存のシェルスクリプトやプログラミング言語の知識を活かせます。一方で、ワークフロー全体の設計や各コンポーネント間の連携は自前で考える必要があります。
- バージョン管理: プロンプト、設定ファイル、スクリプトなど、すべてがテキストファイルとして管理できるため、Gitなどの分散バージョン管理システムとの相性が非常に良いです。変更履歴の追跡、ブランチでの試行錯誤、チームでの共同編集などが容易です。
- カスタマイズの容易さ（構築）: プロンプトの内容、使用するLLMモデル、処理フロー、外部ツール連携など、あらゆる要素を自由に、かつ細かくカスタマイズできます。
- 利用の容易さ: 主にCUI（コマンドラインインタフェース）での操作や、設定ファイルを直接編集する必要があるため、GUIに慣れたユーザーにとっては敷居が高い場合があります。
- カスタマイズの容易さ（利用）: 利用者自身がプロンプトを微調整したり、設定値を変更したりすることで、挙動を柔軟に変えやすいです。

Difyより手触り感があるので、エンジニアにはフィットしそうです。なによりも一元管理できたりもするし、もう最高かなと思います。もし、ドキュメントをpublicに出したければsubmoduleで追加して、それを外部公開用のリポジトリにしちゃえばよいでしょうし。

しかも、アーキテクチャなら無料で行えます。LLMへの課金だけで終わる！

2. 応用ユースケース

PMなどのマネジメント業務をすごい雑にブレークダウンするといかになると考えています。

マネジメント業務 = 理論 x 環境

そう考えるとマネジメント業務って、ピンキリで大量に存在するのでどのレベルでもこの設計を応用できると考えられます。

拡大して使う場合
- 会社経営
- 戦略コンサルティング
- 研究開発
- 銀行のシステム移行プロジェクト(青い銀行のシステム移管プロジェクトとかのドキュメントを食わせてみたい)
縮小して使う場合
- 調査票作成
- 既存の開発プロジェクトに入れる
- 機能開発のissue作成
- 見積書作成
- プレゼン資料作成
- Blog記事作成

3. LLMを使ったアセットの概念の提唱

aipm_v0 の根幹にあるワークフローのモデルを図にすると以下。

stateDiagram-v2
    [*] --> FileAsset
    FileAsset --> WorkingDesk: read
    WorkingDesk --> WorkingDesk: edit
    WorkingDesk --> FileAsset: add or update

このフローは、何ら新しい概念ではなは日常のオフィスワークと同じ考え方です

ファイルキャビネット → 作業机：必要な書類をキャビネットから取り出して、作業机に広げる
作業机で編集：書類に赤ペンで修正を入れたり、内容を整理したりする
作業机 → ファイルキャビネット：完成した書類をきちんとフォルダに入れて保管する

LLMはこの「作業机」の役割を果たし、私たちのファイル資産を活用して編集作業をサポートしてくれます。この方法なら編集履歴も残せるため、チームでの作業にも最適です。

また、コンピュータのアーキテクチャと同じ考え方です。ストレージ（ハードディスク）からRAM（メモリ）にデータを読み込み、CPUで処理して、また保存するという流れそのものです。

ファイルシステム（ストレージ） = プロジェクトの資産を保管する場所
LLMの作業領域（メモリ） = 一時的に情報を展開し、加工する場所
人間の判断（CPU） = 内容を確認し、意思決定する処理装置

この単純でありながら強力なモデルが、何十年もの間コンピュータの基本設計として機能してきたように、LLMを活用したドキュメント非常に適していることがわかります。

4. 新たな作業方法の可能性

AI PMからの質問に対し、Geminiに回答を生成させていると、まるでAI同士が対話（A2A: AI to AI）しているような感覚でした。実際には間に人間（Human）が介在しているため、A2H2A（AI to Human to AI）といった構図です。人間はコピー&ペーストとクオリティチェック、問題が起きたときの介入といった作業に専念できました。

左画面にCline（AI PM）、右画面にCopilot（Gemini）という構成で作業を進めました。

まるで「Vibe PM」のような感覚

いわゆる「Vibe Coding」（AI補助のもとでコーディングする新たな開発スタイル）ならぬ「Vibe PM」とでも呼べる新しいプロジェクト管理の形が見えてきました。AIとの対話を通じて、プロジェクトの立ち上げから計画、実行までをスムーズに進められることで、従来のプロジェクト管理の概念が大きく変わりつつあります。

人間はビジョンと判断を提供し、AIが実務的なドキュメント作成や計画立案をサポートする—このコラボレーションが、これからのプロジェクト管理の標準になるかもしれません。

5. 構成はいたってシンプル

自分でも同じものを作りたいとなった時。難しそうに思うかもしれませんが、中身はとてもシンプル。ここまでシンプルにエッセンスを抽出して最低限の指示でこのようなモデルを作ったみやっち氏はすごいと思った。

aipm_v0 の中身はこれだけ

中身の説明

グラウンドルールのファイル
- 1つだけ
- 今回は1200行程度
知識のファイル
- PMBOKなどの理論に即したワークフローの定義軍
テンプレ
- 知識のファイルからテンプレ性の高い部分だけ外に出した

mdcフォーマットで作る。

00_master_rules.mdcの抜粋。

--
description: 
globs: 
alwaysApply: true
---
path_reference: "basic/pmbok_paths.mdc"

master_triggers:


  #-----
  # プロジェクト初期化フェーズ
  #-----
  - trigger: "(プロジェクト初期化|プロジェクト開始|プロジェクト立ち上げ)"
    priority: high
    steps:
      - name: "start_info_collection"
        action: "call basic/01_pmbok_initiating.mdc => project_init_questions"
        message: "プロジェクト初期化に必要な情報を収集します。以下の質問に回答してください。"
      - name: "wait_user_responses"
        action: "wait_for_all_answers"
        message: "必要な回答が揃うまで先に進みません。"
      - name: "confirm_project_creation"
        action: "confirm"
        message: "以下の内容でプロジェクトを初期化します：\n\nプログラム: {{program_id}}\nプロジェクト: {{project_id}}\n\nよろしいですか？"
      - name: "create_program_dir"
        action: "execute_shell"
        command: "mkdir -p {{dirs.programs}}/{{program_id}}"
        message: "プログラムディレクトリを作成します..."
      - name: "create_project_dir"
        action: "execute_shell"
        command: "mkdir -p {{patterns.project_dir}}"
        message: "プロジェクトディレクトリを作成します..."
      - name: "create_document_dirs"
        action: "execute_shell"
        command: "mkdir -p {{patterns.doc_initiating}} {{patterns.doc_discovery}} {{patterns.doc_research}} {{patterns.doc_planning}} {{patterns.doc_executing}} {{patterns.doc_monitoring}} {{patterns.doc_closing}}"
        message: "プロジェクト文書ディレクトリを作成します..."
      - name: "create_readme"
        action: "create_markdown_file"
        path: "{{patterns.project_dir}}/README.md"

まとめと今後の展望

AI PMの可能性と意義

プロジェクト管理の変革
- AI PMは単なる自動化ツールではなく、プロジェクト管理の思考プロセスそのものを拡張する可能性を秘めています。特に aipm_v0 のようなファイルベースのアプローチは、既存の開発フローと親和性が高く、導入障壁が低いという利点があります。
- PMBOKに準拠した体系的なアプローチにより、大規模プロジェクトの立ち上げから実行までを一貫してサポートできることが実証されました。
多様なユースケース
- 今回のケーススタディで示したように、スタートアップの新規サービス構築のような複雑なプロジェクトに適用できます。
- さらに、会社経営や戦略コンサルティングといった大規模な領域から、調査票作成やissue作成といった小規模なタスクまで、スケーラブルに活用できる柔軟性を持っています。

「aipm_v0」の実践から得られた知見

良かった点
- Flow（ドラフト）とStock（確定版）というシンプルながら効果的なワークフローは、アイデアの発散と収束を自然に促進します。
- プロジェクト初期化のヒアリングプロセスは、主観に偏りがちな計画立案を客観的な視点で補完し、より堅牢なプロジェクト基盤の構築に貢献します。
- LLMとの対話を通じて、プロジェクト管理の理論と実践を学ぶ教育的側面も見出せました。
改善の余地
- 一部のステップで出力内容が大幅に欠落するケースが見られました。これはLLMの制約によるものですが、分割処理などの工夫で改善できる可能性があります。
- プロジェクトの規模や特性に応じて、生成するドキュメントをより柔軟に選択・カスタマイズできる仕組みがあると実用性が高まるでしょう。
- 複数のLLMを組み合わせた「A2A（AI to AI）」連携の自動化により、人間の介在をさらに減らせる可能性があります。

新たな働き方の展望

「Vibe PM」の可能性
- 今回の実験で垣間見えた「Vibe PM」とも呼べる新しいプロジェクト管理のスタイルは、AIと人間の協働による新たな働き方を示唆しています。
- 人間はビジョンと判断を提供し、AIが実務的なドキュメント作成や計画立案をサポートするという役割分担により、創造的な業務に集中できる環境が実現できるでしょう。
LLMを活用したアセット管理の普及
- ファイルシステム（ストレージ）、LLMの作業領域（メモリ）、人間の判断（CPU）という単純かつ強力なモデルは、今後のナレッジワークの基本設計として広く採用される可能性があります。
- このモデルはGitなどの既存のバージョン管理システムとの親和性も高く、チーム開発においても大きな価値を発揮するでしょう。

今後の発展方向

技術的な発展
- より大きなコンテキストウィンドウを持つLLMの登場により、複雑なプロジェクト全体を一度に把握・処理できるようになれば、AI PMの能力はさらに向上するでしょう。
- 専門分野に特化したファインチューニングモデルの開発により、特定の業界や領域に最適化されたAI PMツールが登場する可能性があります。
自動化と連携の拡張
- GitHub Actionsなどの自動化ツールと連携することで、AI PMの活用範囲が大きく広がります。例えば：
  - 毎朝の定期実行により、プロジェクトの進捗状況を自動的に分析し、チームメンバーに今日のタスクリストをSlackやメールで配信
  - コードリポジトリの変更を検知して、自動的にドキュメントの更新や課題の進捗状況の更新を提案
  - スプリントの終了時に自動的に振り返りレポートを生成し、次のスプリント計画の素案を提示
- これらの自動化により、プロジェクト管理の多くの定型業務が効率化され、PMはより戦略的な意思決定に集中できるようになります。
社会的な影響
- AI PMの普及により、これまでプロジェクト管理の専門知識を持たなかった個人や小規模チームでも、高品質なプロジェクト管理が可能になります。
- 一方で、プロジェクトマネージャーの役割は、AIとの協働を前提とした新たなスキルセットへと進化していくことが予想されます。

みやっち氏が開発した aipm_v0 は、そのシンプルな構成ながらも強力な機能を持ち、LLM を活用したプロジェクト管理の新たな地平を切り開くものです。今後、このようなアプローチがさらに洗練され、様々な領域で活用されることで、知識労働の生産性と創造性が大きく向上することを期待しています。

この AI PM を作り込んでいけばこの状態になりそうだなと思いました。

日立洗濯機C09エラーを無料修理 | BD-SX110CL

Sat, 26 Apr 2025 00:00:00 GMT

問題の発生

5年前くらいに買った日立の洗濯乾燥機が調子悪くなってきました。

ドアがちゃんと閉まっているのに**C09エラー（ドアロック故障）**が出て洗濯が始まらない！

DIYで治せれば良いなぁと思っていたけど部品交換やファームアップ（ソフトウェア更新）による対処が普通のようなので諦めて修理依頼をしました。

機種情報

型番: BD-SX110CL（日立ビッグドラム）
使用頻度: 平均年300回（約5年で1,500回）
使用状況: 3分の2は洗濯乾燥モード
メンテナンス: オーバーホールなし、洗濯槽クリーニングは年1回程度

修理依頼

ウェブから訪問修理受付をして、希望日を入力しました。最短で2日後だったので2日後に予約しました。

当日の朝まで折り返しや、時間の連絡がないので少し不安でしたが、朝9時ごろに電話が来て時間を調整して、時間が決定する流れでした。

その時間に1人の作業員がやってきました。

修理作業

大きな箱と工具を持ってきました。C09エラーとだけ書くだけで、交換する部材が決まっているくらい当たり前の問題っぽい！

30分ほど洗濯機を分解したりして作業して完了しました。手元には一切紙が残っていないのでよくわかりませんが、口頭で言われたのは以下の通りです：

ドアロック部品の交換
ドアパッキン交換
ファームアップ（ソフトウェア更新）

この機種のこのくらい経過した場合はファームアップだけでは直らないので部品交換も必要とのことでした。

修理費用

注目の料金はなんと無料！作業報告にサインをして終わりました。無料ならもっと早く依頼しておけばよかったです。

また、洗濯乾燥機は内部にゴミが溜まる恐れがあるので心配と相談したら、中身をチェックしてくれました。綺麗に使っているから全く問題なしと言われました。

洗濯機の耐用年数は7年で作られているとのことでした。

まとめ

日立洗濯機BD-SX110CLのC09エラーは無料修理で対応
修理内容: ドアロック部品・パッキン交換、ファームアップ
所要時間: 約30分
修理後は問題なく稼働

とりあえず、これ以降は問題がないので様子見ます。ここ半年でテレビ、食洗機が壊れたので家電が壊れまくります。。。

AdGuard Homeを自宅に導入してBraveブラウザでも8%の広告をブロックした

Thu, 17 Apr 2025 00:00:00 GMT

3秒まとめ

自宅で AdGuard Home を導入してみた
Brave ブラウザを使っていても、8％の広告やトラッカーの名前解決がブロックされている
DNSの名前解決による情報漏えいを防止できる
DoT (DNS-over-TLS)や DoQ (DNS-over-QUIC)にも対応していてセキュア
Tailscale と組み合わせて使うと、スマホや出先からも設定なしで対応できる

AdGuard Homeとは？

AdGuard Home は、ネットワークレベルで広告やトラッカーをブロックできる DNS キャッシュサーバーです。Pi-Holeと同じ感じです。通常のブラウザの広告ブロック拡張機能とは異なり、ネットワーク全体で広告をブロックできるため、スマホアプリやスマート TV など、あらゆるデバイスの広告をブロックできます。

自宅のネットワークに設置することで、家のすべてのデバイスの広告をまとめてブロックできるというわけです。

DHCPで振られたDNSを利用する問題

普段何気なく使っているインターネットですが、実は DNS の名前解決によってどこのホストに接続しているのかが第三者に漏洩してしまうという問題があります。

例えば、アクセスしようとしているホスト名に会社名や組織を識別する情報が含まれていると、あなたがどの会社のサービスを利用しているのか、どんなウェブサイトを見ているのかといった情報が筒抜けになってしまいます。具体的には、login.company-name.com のような URL にアクセスすると、あなたがその会社のサービスを利用していることが DNS キャッシュサーバーの運営者に知られてしまうんです。

参考資料: DNSとプライバシー

この問題を解決する方法として、ローカルで名前解決をするという方法があります。しかし、これにはデメリットもあります：

キャッシュ効率が悪くなる - 同じドメインの名前解決を多くのデバイスが個別に行うことになり、効率が悪い
リソースを消費する - 各デバイスで DNS 解決のためのリソースを使うことになる

そこで最適な解決策となるのが、信頼できる安全なホストで運用されているDNSキャッシュサーバーを利用することです。これにより、プライバシーを保ちながら効率的な名前解決が可能になります。

AdGuard Home はまさにこの役割を果たしてくれるツールなんです。自宅のネットワーク内で安全に DNS サーバーを運用できるため、プライバシーを守りながら広告ブロックの恩恵も受けられるというわけです。

graph TD
    subgraph "AdGuard Homeを使用"
        D[ユーザーのデバイス] -->|"login.company-name.comのIPアドレスは？"| E[AdGuard Home]
        E -->|"zoneの問い合わせ"| G[zoneサーバー]
        F[ルールセット] -->|フィルタルール| E
    end
    subgraph "通常のDNS解決"
        A[ユーザーのデバイス] -->|"login.company-name.comのIPアドレスは？<br>=情報漏洩！"| B[ISPのDNSキャッシュサーバー]
        B -->|"zoneの問い合wせ"| C[zoneサーバー]
    end
    
    
    style A fill:#f9d5e5,stroke:#333,stroke-width:1px
    style B fill:#eeac99,stroke:#333,stroke-width:1px
    style C fill:#e06377,stroke:#333,stroke-width:1px
    style D fill:#f9d5e5,stroke:#333,stroke-width:1px
    style E fill:#b8e0d2,stroke:#333,stroke-width:1px
    style F fill:#809bce,stroke:#333,stroke-width:1px
    style G fill:#95b8d1,stroke:#333,stroke-width:1px

この図のように、通常の DNS 解決では、あなたのアクセスしているホスト名が ISP や第三者に漏れる可能性があります。 AdGuard Home を使うことでプライバシーを保護しながら広告ドメインをブロックできます。

なぜAdGuard Homeを導入したのか

私は Brave ブラウザを普段から使っています。Brave は標準で広告ブロック機能が搭載されているので、かなり快適にウェブブラウジングができるんですよね。

でも、「本当にすべての広告がブロックされているのかな？」という疑問がありました。そこで、ネットワークレベルでの広告ブロックを試してみようと思い、AdGuard Home を導入してみることにしました。

導入してみた結果

AdGuard Home を導入して驚いたのは、Braveを使っているのに8％もの広告やトラッカーの名前解決がブロックされていたことです！

ダッシュボードを見ると、全体の DNS クエリ数が 327,076 件で、そのうち 27,573 件（約 8％）がブロックされています。これは Brave ブラウザを使っていても、まだ広告やトラッカーの一部が通過していることを示しています。

上位のDNSキャッシュサーバ (upstream)

複数の upstream を設定し、ラウンドロビンでしばらく運用してみた結果です。各 DNS キャッシュサーバの応答時間が表示されるので取捨選択もしやすいです。

ちなみに、upstream を設定しない場合、AdGuard Home は自身で DNS クエリを Root Hints から辿って名前解決します。これは「フルリゾルバー」または「再帰 DNS サーバー」と呼ばれる動作です。

DNS blocklists

AdGuard Home では、DNS ブロックリストを使って広告やトラッカーをブロックします。デフォルトでは上の 2 つのリストが有効になっていますが、わたしはいくつか追加してみました。

ブロックリストには様々な種類があり、広告専用、トラッカー専用、マルウェア対策など、目的に応じて選べます。リストを追加するほどブロック率は上がりますが、誤検知のリスクも高まるので、バランスが大事です。

追記: 自分でもトラッキングサービスの運用をしているので追加で登録したリストは幅が広すぎたため結局はデフォルトに登録されているリストと、uBlock のみを使うようになりました。

セキュリティ面の強化

AdGuard Home は DoT (DNS-over-TLS)や DoQ (DNS-over-QUIC)に対応しているので、DNSクエリを暗号化できます。これにより、ISP や第三者からの DNS クエリの監視を防ぐことができます。

通常の DNS は平文で通信するため、どのサイトにアクセスしているか漏れる可能性があります。DoT や DoQ を使えばそのリスクを減らせるので、セキュリティを重視する方には嬉しい機能ですね。

TLS を利用するためにはサーバ証明書を取得する必要があるので追加でひと手間がかかります。

Tailscaleとの組み合わせ

わたしは Tailscaleを使っています。Tailscaleを使うと、外出先からでもDNSの名前解決をVPN上で稼働しているAdGuardに投げることによってDNSのリゾルバを常時自分で動かしているホストに向けることができます。

Tailscale を導入しているクライアントホストでは、DNS キャッシュサーバーとして 100.100.100.100 という仮想ネットワークの仮想 IP アドレスが使われています。このアドレスは実際のネットワークには存在せず、Tailscale 内部で使われるものです。

Tailscale において、DNS キャッシュサーバーは 100.100.100.100 という仮想ネットワークの仮想 IP アドレスが使われていますが、実際には DNS キャッシュサーバーを指定できるオプションがあります。そのため、AdGuard が動いているサーバーの IP アドレスを指定できます。

これにより、スマホからも特別な設定なしでAdGuard Home を使った DNS フィルタリングが可能になりました。外出先でも VPN 経由で自宅の AdGuard Home を使えるので、広告ブロックの恩恵を受けられます。

まとめ

AdGuard Home を導入してみて、Brave ブラウザを使っていても 8％もの広告やトラッカーがブロックされることがわかりました。ネットワークレベルでの広告ブロックは、ブラウザレベルの広告ブロックを補完する形で効果を発揮します。

また、Tailscale と組み合わせることで、外出先でも VPN 経由で広告ブロックの恩恵を受けられるのは大きなメリットです。

プライバシーやセキュリティを重視する方は、ぜひ AdGuard Home の導入を検討してみてください。設定は少し手間がかかりますが、一度設定してしまえば、家のすべてのデバイスで広告なしの快適なインターネット環境を実現できますよ！

Panasonic食洗機DIY修理で3万円節約 | 水漏れ解消

Thu, 03 Apr 2025 00:00:00 GMT

この記事について

学べること

Panasonicビルトイン食洗機（システムキッチンに組み込まれた食器洗い機）の水漏れアラーム原因と対処法
DIY修理による3万円のコスト削減方法
分解・清掃・組み立ての具体的な手順
予防メンテナンスの重要性

想定読者

同じ水漏れアラームエラーで困っている方
修理費用を節約したい方
食洗機のメンテナンス方法を知りたい方

前提条件

必要工具: プラスドライバー、パイプ掃除用ブラシ（または自作可能）
推定所要時間: 2-3時間（分解・清掃・組み立て含む）
難易度: 中級（配管の取り扱いに注意）

問題

ビルトインのPanasonic食洗機を5年前から使っているのですが、稼働しだすと数分で「ピーピー」というアラート音が鳴ってしばらく動いて排水された後、停止する症状になりました。

食洗機を始動してから注水中または注水後（数分後）に、ピーピーとアラームが鳴って、「節電」と「強力」ランプが点滅します。以下の動画のような状態です。

https://youtube.com/shorts/BuUP3r4Q9KQ?si=4Bm2F6wEMt4LjqYV

説明書を調べると水漏れの警報のようです。

2019年9月頃から使いだしました。最初の半年間ぐらいはほぼ使わない状態でした。

それから、2020年のCovid-19になって、自宅で食事をすることが多くなってそれから、1日1回から2日に1回ぐらい稼働していました。その間に、旅行や実家への帰省で使わないことも長期間あったので大体1000回ぐらい回したかと思います。

型番は、Panasonic NP-45RS7（2016年発売のミドルグレードモデル）です。Panasonicのビルトイン食洗機は過去15年ほど基本構造が大きく変わっていないため、他の型番でも同様の対処法が有効な可能性があります。

修理 VS 買い替え

修理費用は、2019年の記事で2万円とあるので5年後の現在は3万円ぐらいになると思います。

買い替えるとなると最低10万円ぐらいっぽいです。結構高いので、直せるなら直したほうが良いです。食洗機の耐用年数も大体10年っぽいので修理してもまぁ、あと5年は使えるはずです。

トラブルシューティング

すぐに元栓は閉めて、食洗機の周囲を確認してみましたが水漏れは確認できませんでした。

試行1: 電源リセット

電源を抜いて、しばらく放置して、電源を入れても症状は変化なし。

試行2: 庫内の徹底清掃

普段掃除していないところで、調子が悪くなった可能性もあるのでこの動画を参考にメーカーが推奨しないところまで頑張って掃除してみましたが、症状は変化しませんでした。

https://youtu.be/Smc30e-rPEE?si=v6x0gLfjVH27kb18

むしろ、この程度は1年に1回やっています。

解体

仕方がないので問題箇所を探していきます。もし、探せなかったらPanasonicのサポートに頼ろうと思って進めます。

食洗機の利用説明書を見ても大したことはないので、食洗機の施工説明書をダウンロードして、逆の順番をたどれば分解できます。

まずは、筐体下に2箇所ネジ止めされている箇所があるので外します。写真は外した後の状態です。

食洗機の蓋を締めた状態で、手前にぐいっと引っ張ると食洗機のユニットが抜けます。食洗機の引き出し部分が取り外せると想定していましたが、引き出し部分は筐体からは簡単に外せません。裏に給排水の配管もあるので簡単には外れないようになっています。

裏には給排水、電源、アースの配管がつながっているのでユニットを無理やり引き出さないように少しずつ引き出します。

この時点で、水が前のパネルの下からドバドバ垂れてきます。センサーの故障でアラートが鳴っていることを期待していましたが、本当にで食洗機が漏水しています。バスタオルを2枚ぐらい持ってきて水が全部出るまで前に倒して出し切りました。

給排水の配管が最低の長さになっているので完全には引き出せませんでした。作業はしづらいですが、施工のクオリティとしては良いです。最短の長さになってます。

オットマンがちょうどよい高さなのでビニールシートを敷いてその上に食洗機のユニットを乗せて作業します。

写真の左下に写っている黒いケーブルが付いているのが漏水検知センサーです。今回はこのセンサーによって漏水が検知されました。

ユニットの底面は水浸しです。傾けると水が出てきます。

給水を外そうとなるとモンキーレンチなどで外さないといけないので面倒です。なので、どうしても外さないといけない場合を除いては外さないほうが良いです。

そして、はずせる部品を外したりして、掃除して、再度稼働させてみてを繰り返してました。でもやはりしばらく放置して水漏れ状態を確認すると漏れてます。

そこで、電源を切ったときに偶然にもポンプが作動して水漏れ箇所を発見できました！

下の写真の赤色の部分から水がびちゃびちゃと漏れてきていました。

上の黒い蓋を外して、カプラーを外して、蓋を外しました。

そしたら、非常に汚れた部品を見つけました。

裏側。ヘドロがこびりついています。ぷにぷにしてます。コラーゲン的な感じの感触。

蓋のパーツがこれだけ汚れているということは、下のタンクも汚いです。

上の蓋を外すときに周囲にヘドロがこぼれ落ちてます。。。汚い。。。そして、タンクの下も真っ黒！5年でこの有り様。。。

こんな下水のような水で食器を洗い続けていたことにショックを受けました。

キッチンペーパーを使ってこそぎ落とします。

この左側のタンクです。実は、このタンクは食洗機庫内の排水部分に繋がっています！

しかも、細いです。。。**おそらくここがヘドロで詰まって、このタンクが溢れているんだと思います。**っていうか、ほぼ確定です。

この管が細すぎて、指が入りません。熱帯魚関係で使うようなパイプ掃除用のスポンジがあればよいのですが断捨離してしまったのでありません。

そこで、作りました。

車の配線用にストックしている電線に食器用のニトリのスポンジを切ってくくりつけました。

理想は、以下のようなものがあるとよいです。

::amazon{asin="B00H1KYFAS" kw="コジット毛づまりごっそりパイプ職人スリム"}

この治具を食洗機庫内にある小さい穴に入れて出し入れします。黒いヘドロがゴソゴソ出てきます。

出てきたヘドロは、キッチンペーパーで絡め取って捨てます。

これを何度か繰り返しました。

そして、水を庫内に入れて、排水するために乾燥モードにするというのを3回ぐらい繰り返したらヘドロが出なくなりました。

これできれいスッキリしました！

あとは、組み付けて完了です。

考察

今回は、分解してわかったことではありますが、普段から以下の部分のお手入れをしておければ防げる問題でした。

この部分には汚れが堆積することがわかったので定期的にブラシを入れて掃除するのが最適な運用な気がします。

おそらく、このプラスチックの部品が排水トラップ（下水の臭いが逆流しないように水を溜めておく仕組み）の役割を果たしていると考えられます。常時浸水している構造のため、ヘドロが蓄積しやすい箇所です。

結果としてわかりましたが、この書き込みと同じ問題でした。今回の場合はスイッチの接点部分は大丈夫そうでしたので単純にヘドロがそこに堆積して詰まったことが原因だと思います。

また、スイッチの接点部分は若干サビが浮いていたの防錆剤が入っているラスペネを吹いておきました。

まとめ

修理費用3万円と修理までのリードタイムを節約できました。
プラスドライバーとパイプブラシがあればできるので工具の出費は無いです。食洗機自体が結構重いので着脱がたいへんでした。。。。
庫内を掃除するときに、どうしても排水部分に水が溜まっていて掃除不可能な箇所があって今まで気になってましたが、やはりそれが原因でヘドロが発生して配管が詰まるというのが今回の現象でした。定期的にクリーナーを使ってこのヘドロを融解するようなメンテナンスをする必要がありそうです。（取れるかもわかりませんが）

注意

「節電」モードだと温度を下げて運転するから油汚れが溜まりやすい気がする。
1ヶ月に1回はクリーニングをする必要があるらしいです。いままで5年間やったことが無かったです。。。はい。すいません。

::amazon{asin="B097D6T7D9"}

新卒エンジニアへ贈る、エンジニア歴20年CTOからのメッセージ

Tue, 01 Apr 2025 00:00:00 GMT

3秒まとめ 🚀

エンジニアとしての成長に「正解」はない - 自分なりの道を見つけよう
技術は手段であって目的ではない - 何を実現したいかを常に考えよう
失敗を恐れるより、失敗から学ぶ姿勢が大切 - 失敗は最高の教材
チームでの協働が個人の力を何倍にも増幅させる - コミュニケーション能力は使うべきではない言葉なので修正してくださいの武器
学び続ける習慣が未来の自分を作る - 今日から始めよう

新卒エンジニアのみなさん、おめでとう！そして、ようこそ！ 🎉

4 月 1 日。新しい門出の日ですね！　期待と不安が入り混じった状態で新たなライフステージの始まりの日のことを今でも鮮明に覚えています。

「コードが書けるか不安...」「先輩たちについていけるだろうか...」「本当にエンジニアとしてやっていけるのか...」

そんな不安を抱えていませんか？　大丈夫です。私たちは全員、そこからスタートしました。 今日は、エンジニア歴 20 年、現在 CTO として働く私から、新しい旅を始めるあなたへのメッセージです。

私の20年前と今：LLM登場前と後の世界

20 年前、私も新卒エンジニアでした。当時は PHP と MySQL でウェブアプリケーションを作るのが主流で、jQuery が登場する前の JavaScript は扱いづらく、CSS でレイアウトを組むのも一苦労でした。スマートフォンはまだ普及しておらず、レスポンシブデザインなんて言葉もありませんでした。

何より、AIアシスタントやLLM（大規模言語モデル）は存在しませんでした。コードを書くときは、本やドキュメントを読み漁り、エラーが出れば自分で原因を特定し、解決策を考える必要がありました。Stack Overflow ですら、私が新卒だった頃はまだ黎明期でした。

現在、私は Mindia, Inc.の CTO として、チームを率いています。この 20 年間で技術は劇的に変化しました。React、TypeScript、Docker、クラウドサービス...。そして最も革命的な変化は、ChatGPTやGitHub Copilotに代表されるLLMの登場です。これらのツールは、コーディングの方法、問題解決のアプローチ、さらには学習プロセス自体を根本から変えました。

私が新卒の頃に使っていた技術の多くは、今や「レガシー」と呼ばれています。 😅 時の流れは速いですね！　でも、変わらないものもあります。それは、エンジニアとして大切にすべき姿勢や考え方です。今日はそんな「変わらないもの」と、LLMの時代だからこそ重要になる新しい考え方について、私の経験から学んだことをシェアしたいと思います。

LLM時代の技術習得：流行り廃りに振り回されないために

新卒エンジニアの皆さんは、最新の技術トレンドに敏感だと思います。大学や専門学校で最新のフレームワークやツールを学んできたかもしれません。それはとても素晴らしいことです。

でも、ここで 1 つ覚えておいてほしいことがあります。技術は道具であって、目的ではありません。 これ、めちゃくちゃ大事です！

「React 使ってるからすごい」「TypeScript マスタしたからエリート」「AI エンジニアになれば将来安泰」

...そんな考え方は危険です。なぜなら、技術の流行りは驚くほど早く変わるからです。

私がキャリアを始めた頃、流行りの技術やツールを追いかけるのに必死でした。しかし、長い目で見ると、表面的なトレンドよりもコンピュータサイエンスの基本原理を理解していることが遥かに価値があることに気づきました。例えば、データ構造とアルゴリズムの知識は、言語やフレームワークが変わっても普遍的に役立ちます。効率的なソートアルゴリズムを理解していれば、どんな言語でもパフォーマンスの良いコードが書けます。同様に、関数型プログラミングの考え方や、オブジェクト指向設計の原則は、数十年経った今でも価値のある概念です。逆に、特定のフレームワークの細かい構文や設定方法だけを覚えても、そのフレームワークが廃れたら知識の多くが使い物にならなくなります。

技術の寿命を予測するのは難しいんです。だからこそ重要なのは、特定の技術に依存するのではなく、技術の本質や背景にある考え方を理解すること。技術は進化し続けますが、優れたアーキテクチャの原則や設計思想は長く価値を保ち続けるものなんです。

LLM時代に求められる新しいスキルセット

LLM の登場により、エンジニアに求められるスキルセットも変化しています。20 年前は「コードをたくさん書ける人」が評価されていましたが、今は**「LLM と効果的に協働できる人」**が価値を生み出します。

具体的には：

プロンプトエンジニアリング能力 - AI に適切な指示を出し、質の高い結果を得る力
AIの出力を評価・検証する力 - 生成されたコードの品質や安全性を判断できる目
AIと人間の役割分担の最適化 - どの作業を AI に任せ、どの部分を人間が担当すべきか判断する力
AIツールの特性理解 - 各 AI ツールの得意・不得意を理解し、適材適所で活用する知恵

これらの新しいスキルに加えて、従来から重要な普遍的なスキルも引き続き価値があります：

問題を分析し、適切な解決策を見つける力
複雑なシステムを理解し、シンプルに説明できる力
チームで協力して大きな目標を達成する力
新しい技術を素早く学び、適用する力

特定の言語やフレームワークの細かい構文は、今や LLM に聞けば即座に教えてくれます。でも、なぜその技術が生まれたのか、どんな問題を解決するために設計されたのかを理解することは、AI では代替できない人間の強みです。そういった「なぜ」を理解していれば、新しい技術も素早く習得できるようになります！

失敗こそ最高の教材

私の 20 年のキャリアは、華々しい成功体験だけで彩られているわけではありません。むしろ、数え切れないほどの失敗の連続でした。

本番環境でデータを消してしまい、冷や汗が止まらなかった日 😱
セキュリティホールを見逃してサービスがハッキングされ、休日返上で対応した時
無理なスケジュールを約束してしまい、徹夜の連続で体調を崩した月

これらの失敗は、当時は本当に辛かったです。眠れない夜もありましたし、「もうエンジニアを辞めよう」と思ったこともあります。でも今振り返ると、これらの経験が私を成長させてくれたことは間違いありません。むしろ、失敗しなかった日々よりも、失敗から立ち直った経験の方が鮮明に記憶に残っています。

新卒の皆さんにお伝えしたいのは、失敗を恐れないでほしいということです。もちろん、無謀な挑戦や無責任な行動を推奨しているわけではありません。でも、完璧を求めるあまり何も挑戦しないのは、もっと大きな失敗です。

失敗したら、次の 3 つのステップを踏んでみてください：

何が起きたのかを正確に理解する（事実を直視する勇気）
なぜそれが起きたのかを分析する（根本原因を探る冷静さ）
同じ失敗を繰り返さないための対策を考える（改善する知恵）

そして最も重要なのは、失敗を一人で抱え込まないことです。チームに共有し、一緒に解決策を考えましょう。そうすることで、あなたの失敗はチーム全体の財産になります。

チームの力を最大化するコミュニケーション

エンジニアというと、黙々とコードを書くイメージがあるかもしれません。確かに、集中してコーディングする時間は大切です。でも、現代のソフトウェア開発は、チームスポーツです。

私が新卒の頃は「コードさえ書ければいい」と思っていました。コミュニケーションが苦手で、できるだけ一人で仕事をしたいと考えていたんです。でも、キャリアが進むにつれて、最も価値のある仕事は常にチームで行われることに気づきました。

特に日本の開発現場では、「阿吽の呼吸」や「空気を読む」文化があります。これは素晴らしい面もありますが、時に誤解や非効率を生むこともあります。「言わなくても分かるだろう」が最大の落とし穴なんです。だからこそ、明確なコミュニケーションが重要です。

具体的には：

わからないことは素直に質問する勇気を持つ（「分からない」と言える強さ）
自分の考えや進捗を定期的に共有する習慣をつける（小さな更新でも OK！）
チームメンバーの話をしっかり聞き、理解しようとする姿勢を持つ（傾聴の力）
技術的な議論と人格批判を混同しない（コードに対する批判 ≠ あなたへの批判）

特に最後の点は重要です。コードレビューで指摘を受けたとき、それを個人攻撃と受け取らないでください。良いエンジニアは自分のコードと自分自身を分けて考えられる人です。

LLM時代の学習法：20年後の自分を作る新しい習慣

テクノロジーの世界は常に変化しています。20 年前に私が学んだ技術の多くは今や使われていません。逆に、今日のスタンダードな技術の多くは、20 年前には存在していませんでした。そして、LLM の登場により、学び方そのものが根本から変わりつつあります。

LLM以前の学習と現在の学習の違い

20 年前、新しい技術を学ぶには：

分厚い技術書を購入して読み込む
公式ドキュメントを最初から最後まで読む
サンプルコードを手打ちで写経する
エラーが出たら自分で調査して解決する

これらのプロセスは時間がかかりましたが、その分、深い理解が得られました。

一方、LLM 時代の学習は：

ChatGPT に「○○の基本を教えて」と質問する
エラーが出たらそのまま AI に質問して解決策を得る
サンプルコードを AI に生成してもらう
わからない概念があればその場で AI に説明してもらう

この新しい学習法は圧倒的に効率的です。でも、表面的な理解に留まるリスクもあります。

LLM時代に効果的な学習習慣

この変化のスピードについていくには、学び続ける習慣が不可欠です。でも、「勉強しなきゃ」というプレッシャーから学ぶのは長続きしません。大切なのは、学ぶことを楽しむ姿勢です。好きこそものの上手なれというやつですね！

私自身、新しい技術や概念を学ぶときは、「これを使って何が作れるだろう？」「これによって何が改善されるだろう？」と考えるようにしています。好奇心こそが、長期的な学習の原動力です。

LLM 時代の効果的な学習方法としては：

AIと人間の強みを組み合わせる - AI に基本を教えてもらい、人間は「なぜ」を深く考える
実際に手を動かしてプロジェクトを作る - AI が生成したコードをそのまま使うのではなく、理解して改良する
AIとの対話を通じて概念を深める -「これはなぜそうなるの？」「別の方法はある？」と掘り下げる質問をする
AIの限界を知り、人間の判断力を磨く - AI の回答を鵜呑みにせず、検証する習慣をつける
自分の学びをブログやSNSでアウトプットする - AI の助けを借りつつも、自分の言葉で説明する力を養う

特に最後のアウトプットは重要です。私自身、この Zenn やブログでの発信を通じて、多くの気づきや出会いがありました。教えることは、最も効果的な学びの形なんです。「誰かに説明できる」が本当の理解の証です！

LLM時代のエンジニアキャリア：幸せな道を見つけるために

LLM の登場により、エンジニアの役割や価値も変化しています。「コードを書く」という作業の多くは AI が担うようになり、人間のエンジニアにはより創造的で戦略的な役割が求められるようになるでしょう。

新卒の皆さんは、これからどんなエンジニアになりたいですか？　🤔

AI と協働して複雑な問題を解決するプロンプトエンジニア？
AI ツールを活用して生産性を最大化するプロダクティビティスペシャリスト？
AI の限界を理解し、人間ならではの創造性を発揮するクリエイティブエンジニア？
AI システムの倫理や安全性を確保する AI 倫理スペシャリスト？
AI と人間のチームを率いる AI 時代のテックリード？

正解はありません。あなた自身の価値観や強み、興味に合った道を見つけることが大切です。

私の場合、技術が好きなのはもちろんですが、それ以上に「技術で人々の生活を良くすること」に情熱を感じています。コードを書くことが目的ではなく、そのコードが誰かの問題を解決することに喜びを感じるんです。だからこそ、単なる技術的な挑戦だけでなく、ユーザーにとっての価値を常に考えるようにしています。

LLM時代の新卒エンジニアへのアドバイス

新卒の皆さんも、ぜひ自分自身の「なぜ」を見つけてください。なぜエンジニアになったのか。何を実現したいのか。その「なぜ」が、困難な時期を乗り越える力になります。

最後に、LLM 時代を生きる新卒エンジニアへの私からのシンプルなアドバイスです：

AIと協働する姿勢を身につけよう - AI を敵視するのではなく、パートナーとして活用する
AIが苦手な領域を理解し、そこで価値を発揮しよう - 創造性、倫理的判断、共感は AI が不得意
謙虚に学び続けよう - 知れば知るほど、自分の無知に気づくもの
失敗を恐れず挑戦しよう - 挑戦しない人生より、失敗のある人生の方が豊か
仲間と共に成長しよう - 一人で登る山より、仲間と登る山の方が景色が美しい
自分の価値観を大切にしよう - 他人の期待ではなく、自分の情熱に従おう
何より、エンジニアであることを楽しもう！ - 楽しさこそが継続の秘訣

エンジニアという職業は、世界を変える力を持っています。そして今、LLM という強力なツールを手にした皆さんには、私たちの世代以上に大きな可能性が広がっています。その力を持った皆さんの活躍を、心から楽しみにしています！

おまけ：自己紹介 👋

松倉友樹（まつくらゆうき）と申します。Mindia, Inc.の CTO として、日々チームと共にプロダクト開発に取り組んでいます。学生時代から数えると約 26 年（学生エンジニア 6 年+社会人エンジニア歴約 20 年）のエンジニア経験があり、ウェブ開発、モバイルアプリ開発、クラウドインフラ、最近では AI 活用など幅広い領域に携わってきました。

個人的な（テックブログ）やZennでも技術情報を発信しています。また、Xでは@matsubokkuriで日々の気づきや学びをつぶやいています。

皆さんとどこかでお会いできる日を楽しみにしています。エンジニアとしての新たな旅の始まりを心から祝福します。素晴らしいキャリアになることを願っています！　🎉

LLMを活用してDockerfileを最適化し15%のサイズ削減を実現した話

Tue, 25 Mar 2025 00:00:00 GMT

3行まとめ

LLM を活用して Dockerfile のリファクタリングを実施し、イメージサイズを 15％削減（1.96GB → 1.75GB）
LLM 登場前に書いたコードを LLM にリファクタさせるのは良い結果を生む（最近これが楽しい）
slim イメージへの移行とパッケージ最適化により、ビルド時間と pull 時間を改善

背景

長年運用している Dockerfile は複雑化していく傾向にあります。

リファクタリングはリグレッションのリスクがあり、手を出しづらいです。

最近、Devin による Dockerfileリファクタリングの成功事例を見て、自プロジェクトでも試してみることにしました。

最適化前の状態

まず、変更前の Docker image のサイズを調べておきます。

❯ docker images minedia-www-app
REPOSITORY        TAG       IMAGE ID       CREATED      SIZE
minedia-www-app   latest    7e88a3086cb9   4 days ago   1.96GB

2GBありました。

アプローチ

Devinにやってもらおうかと思いましたが、そもそもこんなDockerfileのリファクタだったらClineで十分だと思うのでClineでClaude sonnet 3.5(少し前に行ったので古い)で実行してみました。

プロンプトは、ラフに「Dockerfileをリファクタリングして」という指示だけです。

LLMによる主要な変更点

1. ベースイメージの最適化

-FROM ruby:3.4.1
+FROM ruby:3.4.1-slim

必要最低限しか入っていない -slim をbase imageとして使うようになりました。

いままでも導入を検討していましたが、開発時にはツールが少なかったり、リグレッションが発生してしまうリスクがあるのであんまり導入に積極的に離れませんでしたがそこを踏み込んで変更してくれました。

2. 環境変数とパッケージインストールの効率化

-ENV LANG="C.UTF-8" TZ="UTC"
-
-RUN apt update -qq && DEBIAN_FRONTEND=noninteractive apt -yq dist-upgrade &&\
-  DEBIAN_FRONTEND=noninteractive apt install -yq\
-    build-essential\
-    default-mysql-client\
-    ffmpeg\
+
+ENV LANG="C.UTF-8" \
+    TZ="UTC" \
+    APP_HOME=/app \
+    LUA_LIB="/usr/lib/liblua5.1.so.0"
+
+# Install system dependencies
+RUN apt-get update -qq && \
+    DEBIAN_FRONTEND=noninteractive apt-get -yq dist-upgrade && \
+    DEBIAN_FRONTEND=noninteractive apt-get install -yq \
+    build-essential \
+    curl \
+    default-mysql-client \
+    ffmpeg \
     liblua5.1-0 \
-    pandoc &&\
-    apt clean &&\
-    rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* &&\
+    pandoc \
+    imagemagick \
+    libmagickwand-dev && \
+    ln -s /usr/lib/`uname -m`-linux-gnu/liblua5.1.so.0 ${LUA_LIB} && \
+    # Install Node.js
+    curl -fsSL https://deb.nodesource.com/setup_22.x | bash - && \
+    apt-get install -y nodejs && \
+    # Cleanup
+    apt-get clean && \
+    rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* && \
     truncate -s 0 /var/log/*log

今までは人間が見やすいようにするメンテナナンス性や、build cacheを使うためにステップごとに処理をある程度区切っていましたが build layerを少なくするために1コマンドで色々行うように変更されました。

人間がメンテナンスしづらくはなりますが、LLM経由でメンテナンスできるならばこれで問題無いと思います。

ベースイメージのサイズ比較

サイズ削減の効果を調査するために、そもそもslimとそうでないイメージでどのくらいサイズの差があるのかを調べてみたら、5倍ちかく容量が違いました。

通常イメージ

❯ docker images ruby:3.4.1
REPOSITORY   TAG       IMAGE ID       CREATED       SIZE
ruby         3.4.1     79e67c837851   5 weeks ago   1.01GB

Slimイメージ

❯ docker images ruby:3.4.1-slim
REPOSITORY   TAG          IMAGE ID       CREATED       SIZE
ruby         3.4.1-slim   eb3ae63a0b49   8 weeks ago   219MB

最終的な成果

最適化の結果

項目	最適化前	最適化後	削減率
ベースイメージ	1.0GB	219MB	78.1%
アプリケーションイメージ	1.96GB	1.75GB	10.7%

ベースイメージの大幅な軽量化により、全体で約250MB（約15％）のサイズ削減に成功しました。これによりビルド時間の短縮やコンテナのpull時間改善など、CI/CDパイプライン全体の効率化につながりました。

(余談)Docker Gordonでの試み

Docker Desktopに統合されたAI機能（Gordon）も試してみましたが、現時点では正常に動作しませんでした。

設定を有効化し、規約に同意しても機能が利用できない状態でした。

本番環境へのデプロイ時の注意

このDockerfileの最適化を行った後、入念なテストを経て本番にデプロイしました。

1つだけ問題が発生しました。AWS ECSのhealthcheckにて ps コマンドによるsidekiqプロセスの有無をチェックしてhealthyかどうかを判定していました。 slim imageにはpsコマンドすら入っていなかったので別のコマンドでチェックするようにtask definitionsを変更しました。

cat /proc/*/cmdline | tr '\0' ' ' | grep sidekiq || exit 1

まとめ

イメージサイズを 15％削減（約 250MB）できました。
- すでにある程度はきれいにしているのでそんなに無駄は無いので 70％も削る余地が無かったです。
- ビルド時間の短縮と pull 時間の改善
LLM を活用することで、従来は困難だった最適化作業を効率的に実施できた

WordPressをSQLiteで動かしてみた！パフォーマンス比較とセットアップ方法

Tue, 25 Mar 2025 00:00:00 GMT

3行まとめ

SQLite を使用した WordPress は標準構成より約17％高速で、メモリ使用量が約32％少ない
DB サーバーが不要になり、設定が簡素化。
DB への参照がほとんどの場合や開発環境に最適であり、バックアップも単一ファイルで完結するようになる

背景

WordPress が公式に対応しているデータベースは MySQL（または MariaDB）のみです。数年前に SQLiteにも対応したいという表明がありましたが、未だに公式サポートの告知はありません。

MySQL は優れたデータベースですが、小規模サイトや開発環境では以下のような課題があります：

サーバーリソースを多く消費する
設定や管理が比較的複雑である
小規模サイトではオーバースペックである

一方、SQLite は：

軽量でリソース消費が少ない
ファイルベースで設定が簡単である
小〜中規模のサイトに適している

最近調査したところ、wp-sqlite-dbというdrop-inプラグインを使えばWordPressをSQLiteで動かせることがわかりました。このプラグインはWordPressのデータベース接続層を置き換え、SQLiteを使用できるようにします。

今回はこのプラグインを活用し、WordPress を SQLite で動かす方法と MySQL とのパフォーマンス比較について紹介します。

セットアップ手順

手軽に試すために、ローカル環境で Docker Compose を使って新規に WordPress 環境を構築します。

1. プロジェクトディレクトリの作成

% mkdir sqlite_wordpress
% cd sqlite_wordpress

2. Docker Compose設定ファイルの作成

compose.yml ファイルを作成し、以下の内容を記述します：

services:
  wordpress:
    image: wordpress:latest
    volumes:
      - wp_data:/var/www/html
    ports:
      - 80:80
    restart: always
    environment:
      WORDPRESS_DB_HOST: dummy
      WORDPRESS_DB_NAME: dummy
      WORDPRESS_DB_USER: dummy

volumes:
  wp_data:

重要なポイント

DBコンテナが不要: 通常のWordPress構成ではMySQLコンテナが必要だが、SQLiteを使用するため不要である
ダミー環境変数: MySQL接続用の環境変数にダミー値を設定する
- これにより、WordPressの初期設定ページでデータベース接続情報の入力をスキップできる
- SQLiteを使用するため、実際にはこれらの値は使用されない

この設定は、WordPressの初期化プロセスを騙して、データベース設定画面をスキップさせるためのものです。SQLite用のdrop-inプラグインがデータベース接続を管理するため、実際のMySQL接続は必要ありません。

3. SQLite用drop-inプラグインのインストール

以下のコマンドを実行してWordPressコンテナに入ります：

docker compose run wordpress bash

コンテナ内で以下のコマンドを実行し、SQLite用のdrop-inプラグインをインストールします：

# wp-contentディレクトリに移動
cd wp-content

# SQLite用のdrop-inファイルをダウンロード
curl https://raw.githubusercontent.com/aaemnnosttv/wp-sqlite-db/refs/heads/master/src/db.php > db.php

# SQLiteデータベースファイル用のディレクトリを作成
mkdir database

# 権限を設定（Webサーバーがファイルを書き込めるようにする）
chown www-data database

これらのコマンドで：

WordPressのデータベース接続処理を置き換えるdrop-inファイル（db.php）をダウンロード
SQLiteデータベースファイルを保存するディレクトリを作成
Webサーバープロセス（www-data）がデータベースファイルに書き込めるよう権限を設定

これでSQLite用の設定は完了です。シンプルな3ステップで、WordPressをSQLiteで動かす準備が整いました。

起動と初期設定

1. WordPressコンテナの起動

次のコマンドでWordPressコンテナを起動します：

docker compose up

2. 初期設定の実施

コンテナが起動したら、ブラウザで以下のURLにアクセスします：

http://localhost/

初期設定の流れ

言語選択画面
最初に言語選択画面が表示されます。日本語を選択します。
サイト情報設定画面
次に管理者アカウントとサイト名を設定する画面が表示されます。

注目ポイント: 通常のWordPress設定では、この前にデータベース接続情報の入力画面がありますが、環境変数を設定しているためスキップされています。
設定完了
必要情報を入力して「WordPressをインストール」ボタンをクリックすると初期化が完了します。

SQLiteのデータ自体は、デフォルトでは wp-content/database/.ht.sqlite に保存されます。変更したい場合は環境変数で設定できます。

3. 管理画面へのログイン

設定したユーザー名とパスワードで管理画面にログインすれば、WordPressの利用を開始できます。

使用感

SQLiteを使用したWordPressの最も顕著な特徴は、驚異的な応答速度である。管理画面での操作やページの読み込みが非常に高速で、特に以下の点で体感できる：

投稿の保存や公開が瞬時に完了する
管理画面の各ページ間の移動がスムーズである
プラグインのインストールや有効化が高速である

通常のMySQL環境では数秒かかる操作が、SQLite環境ではほぼ瞬時に完了する。この速度差は特に管理作業を頻繁に行う場合に大きなメリットとなる。

パフォーマンス比較

SQLiteとMariaDBを使用したWordPress環境のパフォーマンスを比較するため、簡単なベンチマークテストを実施した。

測定環境

同一ハードウェア上でテスト
Apache Benchを使用（ab コマンド）
500リクエスト、10並列でトップページにアクセス
初期インストール直後の状態で測定

WordPress with SQLite

メモリ使用量

SQLiteを使用した場合、単一のWordPressコンテナのみで動作する：

CONTAINER ID   NAME                               CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O         PIDS
7d22d5c46e2c   sqlite_wordpress-wordpress-1       0.01%     151MiB / 20.24GiB     0.73%     1.91MB / 7.18MB   0B / 17.4MB       11

パフォーマンス測定結果

❯ ab -n 500 -c 10 'http://localhost/'|grep Request
Requests per second:    245.71 [#/sec] (mean)

平均レスポンスタイム: 42.365ms

WordPress with MariaDB（標準構成）

比較のため、WordPressが公式に提供しているDocker Compose設定（MySQL/MariaDB使用）でも同様のテストを実施しました。

メモリ使用量

MariaDBを使用した場合は、WordPressコンテナとデータベースコンテナの2つが必要です：

CONTAINER ID   NAME                               CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O         PIDS
065ec00a760f   sqlite_wordpress-wordpress-1       0.01%     138MiB / 20.24GiB     0.67%     6.7MB / 3.22MB    180kB / 88.1MB    11
ef148bfb4007   sqlite_wordpress-db-1              0.02%     83.31MiB / 20.24GiB   0.40%     1.81MB / 5.15MB   6.28MB / 35.5MB   21

パフォーマンス測定結果

❯ ab -n 500 -c 10 'http://localhost/'|grep Request
Requests per second:    209.41 [#/sec] (mean)

平均レスポンスタイム: 47.869ms

比較結果

項目	WordPress with SQLite	WordPress with MariaDB	差分
メモリ使用量	151 MiB	138 MiB + 83.31 MiB = 221.31 MiB	SQLiteの方が約70 MiB少ない（約32％削減）
リクエスト/秒	245.71 req/sec	209.41 req/sec	SQLiteの方が約17％高速
平均レスポンスタイム	42.365 ms	47.869 ms	SQLiteの方が約5.5 ms速い（約11％改善）

考察

メモリ使用量: SQLite を使用することで、約 32％のメモリ使用量削減が実現できます。これは特に限られたリソースの環境（VPS や共有ホスティングなど）で大きなメリットとなります。
パフォーマンス: SQLite はシンプルなファイルベースのデータベースにもかかわらず、MariaDB よりも高いパフォーマンスを示しています。これは主に以下の理由によると考えられます：
- プロセス間通信のオーバーヘッドがありません
- シンプルなクエリ実行パスです
- ファイルシステムキャッシュを効率的に利用できます

SQLite版WordPressの適用シナリオ

SQLite を使用した WordPress は、以下のようなシナリオで特に有効です：

最適な利用シーン

小〜中規模のWebサイト: アクセス数が多くない個人ブログや小規模企業サイト向けである
開発・テスト環境: 本番環境と同じ WordPress を軽量に動かしたい場合に適している
リソース制約のある環境: 低スペックの VPS やレンタルサーバーで効果的である
バックアップが容易なサイト: SQLite はファイル 1 つでバックアップ可能である

注意点

大規模サイトには不向き: 同時接続数が多い場合は SQLite の制約が問題になる可能性がある
一部のプラグイン互換性: 特定の MySQL の機能に依存するプラグインは動作しない場合がある
公式サポート外: WordPress の公式サポート対象外であるため、問題発生時の対応は自己責任となる

今後の展望

個人的には、以下の点で今後 SQLite 版 WordPress を活用していく予定である：

既存の小規模サイトの移行: 現在運用している小規模な WordPress サイトの一部を SQLite ベースに移行し、リソース使用量とパフォーマンスの改善を図る
開発環境の標準化: 開発・テスト環境では SQLite を標準とし、環境構築の簡素化と高速化を実現
バックアップ戦略の簡素化: SQLite ファイル単体でのバックアップにより、データベースダンプが不要になるメリットを活かす

SQLite を使用した WordPress は適切なユースケースにおいて従来の MySQL 構成よりも多くのメリットをもたらす可能性がある。個人ブログや小規模サイトでの利用は特に検討する価値が十分にあるだろう。

まとめ

WordPress を SQLite で動かすことで、以下のメリットが判明しました

シンプルな構成: DB サーバー不要で構成がシンプル
リソース効率: メモリ使用量が約 32％削減
高速なレスポンス: リクエスト処理が約 17％高速化
簡単なバックアップ: データベースがファイル 1 つで完結

SQLite を使用した WordPress は公式サポート対象外ではあるものの、適切なシナリオでは非常に魅力的な選択肢となる。特に小規模サイトや開発環境においては、そのシンプルさと効率性が大きな強みとなるだろう。

今後も継続的に検証を進め、実運用での知見を深めていく予定である。

Xiaomi 14T Proをメインスマホにできるか検証

Sun, 23 Feb 2025 00:00:00 GMT

背景

最近、iPhoneが高すぎるし、スマホで写真を撮りまくっているのでカメラ性能が良いXiaomi 14T Proを試してみて良ければ移行しようと思う。

iPhoneにインストールされているアプリをカウントしたら330個ぐらいあって、これも減らしたいと思ってます。（頑張って掃除はしているけどなかなか減らない）

開封

Aliexpressで注文して1週間ほどで届いた。注文時は1ヶ月後に到着予定と書かれているがでたらめ。

ミニマムなパッケージ。

スマホに最適化された緩衝材！

日本向けに用意したのか、電源プラグ変換アダプタがスマホの箱とは別に同梱されていた。

iPhone 16 Proより一回り大きい。

120WのACアダプタが入ってる。強力すぎる！

スマホケースが同梱。画面のフィルムも元から貼り付けてあるので楽！

自分でケースに入れる。

独自OS。。。。

巨大！

ベンチマーク

antutuから抜粋。

Xiaomi 14T Pro

iPhone 16 Pro

カメラ性能

手元にあるiPhone 16 Proとの比較をしていきます。

牛丼。食べ物の色の表現は意外と難しい。

https://x.com/matsubokkuri/status/1893168256317563150

https://x.com/matsubokkuri/status/1893205539682750861 https://x.com/matsubokkuri/status/1892966419840512500

まとめ

光学性能はXiaomi 14T Pro勝ち。

センサはiPhone 16 Proが勝ち。特に高感度は歴然。

問題

レンズ内に曇りが発生

しばらく使っていたら、望遠レンズに水滴が付いた。

Webを検索すると同じ症状の事例が多数出てきた。製造時に混入している模様。

https://www.reddit.com/r/Xiaomi/comments/1b314x0/xiaomi_14s_camera_lens_is_fogging/

ziplockなどにスマホと乾燥剤を入れてしばらく放置して抜くしか無い。

レンズの曇りを取る方法はこのページに以下のように紹介されていた。

推奨修正法 1

スマートフォンの外側が乾いてきれいな状態であることを確認し、必要に応じてマイクロファイバークロスで拭きます。
SIMトレイを開けます。
SIMトレイを引き出します。
30分から1時間ほど自然乾燥させます。
8K解像度で10〜30分間ビデオ撮影し、スマートフォンを少し温めます。
SIMトレイを元に戻し、状況を確認します。
これで湿気の問題が解決するはずです。

推奨修正法2

スマートフォンの外側が乾いてきれいな状態であることを確認し、必要に応じてマイクロファイバークロスで拭きます。
SIMトレイを開けます。
SIMトレイを引き出します。
3Dmarkをダウンロードします。
約20分間ストレステストを実行します。
これによりスマートフォンが熱くなりますが、バッテリーが約45℃になると熱制御が働くため、完全に安全です。
ストレステストが終了したら、SIMトレイを出したままにします。
屋外で5〜10分間、8Kビデオ撮影をテストします。
曇りがなければ、SIMトレイを元に戻します。

しかし、上記の方法ではスマホのバッテリーは痛むし、無駄にCPUやSSDを消費するのでスマホの寿命を削ってしまいます。冷蔵庫に入れて冷やすのもリチウムイオン電池的にも良くない。

日本ではこの方法が一般的だと思う。ジップロックにスマホと乾燥剤を入れて放置。その際にSIMトレーは外す感じが良いと思う。

::amazon{asin="B005DJISNO"}

Xiaomi独自OS

プリインされているアプリが削除できない。

AndroidとXiaomiの独自機能が癒着してしまっています。

良い点

ベンチマーク結果は同じだが、価格が半額

iPhone 16 Proとベンチマークやスペックは近似しているなかで、価格は半額というのは魅力的。

指紋でアンロック

画面上で指紋認識ができるのでいちいち顔を向けなくてもアンロックできる。

結論

iPhoneからAndroidへの移行は断念。

ハードウェアは良いけど、AndroidのUXに慣れなさそうなので諦める。

iOSで設定を最適化しすぎた気もする。。。今まで1ステップで実行できていたことが2ステップになることが増えてしまって面倒に感じた。

夜景が汚いのが残念。

ゼロイチでセットアップするならAndroidでも良い気がする。

デスクトップの音響環境を測定してみる

Sat, 22 Feb 2025 00:00:00 GMT

概要

ちょっと音響環境を調べる必要が出てきたのでREW (Room Acoustics Software) で計測してみました。

Javaで動くのでMacでも動きます。最近のJavaは軽快なのか、PCのスペックが良くなったからかわかりませんが起動は速く、ストレスなく動きます。

とりあえず手元にある機材で計測していきます。

音響環境

PCで作業するデスクトップです。

スピーカー

GENELEC 8020

::amazon{asin="B06XTBPZNZ"}

USB-DAC

::amazon{asin="B07VDQQY95"}

測定

準備

マイク、USB-DACのキャリブレーションをすべきですが、手元にあるマイクが現在はUSBで接続されているのでループバック接続するのが面倒なのでスキップしました。

使っているマイクはこちら。ミニジャックはありますが

::amazon{asin="B07NZZZ746"}

まずは、音量のキャリブレーション。音圧を定量的に測定するのにこれは必要です。実測値はこれも簡易的にiPhoneのアプリを使って計測。

SPL

周波数特性。

サブウーファーが無いので下の方は出ていません。

ほかはフラット。3kHz〜4kHzに盛り上がりがあるのはエコライザで持ち上げすぎているからかと思います。

ちなみに、スピーカーにはカットオフができる機能がありますが単体で使っているので全てOFFです。

Distortion

高調波歪みとノイズ

相対的に同じくらいのレベルなので大丈夫そう。目立ってDistortionが大きいところはない。

Impulse

250msで急に落ちてる。距離換算すると85mだが、それっぽい原因がわからない。部屋の特性かなと。

RT60

どのくらい残響が収まるのに時間がかかったか。

T30で169msなので残響が少ない。物が多いからかな。

Clarity

100%に近いので良い！

Waterfall

低音の残響が多め。SPFで出てた、3〜4kHzが大きめ。

Spectrogram

参考資料

めちゃくちゃわかりやすい。

https://www.youtube.com/watch?v=9TVkrzxjNRo

他の動画も見ましたけど、このかた、すごい知識量。理論的です。いままで音響の世界は定性的なよくわからない表現が多くて困ってましたが、定量的に解説してくれているので　その理由が明らかになります。

っていうか、SONYの主任研究員ですね。専門は機械学習のようです。オーディオは趣味っぽい。

まとめ

さすがGENELECです。スピーカー性能に問題ないです。左右差もありません。

リスニングしていても不満は無いので。（たまに重低音がほしいときはありますが）

LLMS.txt: AI時代のWebサイト最適化ガイド

Thu, 20 Feb 2025 00:00:00 GMT

3行まとめ

主要な LLM プラットフォームが対応し、効率的なサイト情報提供が可能になります。
NotebookLM などのツールを使って、サイトの情報を効果的に活用できます。
自分のサイト 2 つを LLMS.txt に対応し、NotebookLM にナレッジとして組み入れて遊んでみました。

なぜLLMS.txtか？

2024 年末から注目度が上昇
日本国内での認知度が向上
主要 LLM プラットフォームが積極的に対応
Web サイトの新しい標準として確立しつつある
自分が書いた blog の RAG 用データとして使えそう

LLMS.txtとは

LLM 向けの構造化された Web サイト情報提供ファイル
2024 年 9 月に Jeremy Howard 氏が提案
Markdown 形式による構造化と標準化
AI が効率的に解析可能な形式
詳細仕様

従来のWebファイルとの違い

ファイル	目的	対象
robots.txt	クローラーのアクセス制御	検索エンジン
sitemap.xml	インデックス可能なページリスト	検索エンジン
LLMS.txt	サイト情報の効率的な提供	AI（LLM）

LLMS.txtとrobots.txtの仕様の関係性

仕様レベルでの関係性は無い。
robots.txt のほうが広く知られているので llms.txt への参照を追加する可能性はあると思う。
robots.txt は RFC 9309で仕様化されているが、LLMS.txtはRFCではない。

LLMS.txtの種類

/llms.txt
- サイト構造のサマリー
- コンパクトな情報提供
/llms-full.txt
- 完全なドキュメント内容
- 詳細な情報を含む

llms.txtの中身の例

拡張子は txt ですが中身は Markdown です。

# プロジェクト名

> 概要説明

## ドキュメント

- [リンクタイトル](URL): 詳細説明

## 例

- [サンプル](URL)

## その他

- [オプショナルリンク](URL)

どこまでが仕様で、どこまでが自由記述なのか分かりづらいですが、Markdownで書かれた内容はすべて自由記述です。

導入のメリット予想

LLMによる効率的なサイト理解と情報抽出
将来のAIモデル学習時の優先的なインデックス化
サービスの自動化・統合の促進
- 例：LLMを介したサービス利用の自動化
- APIやサービス機能の効率的な活用

事例I：Anthropic

# Anthropic

## Docs

- [Get API Key](https://docs.anthropic.com/en/api/admin-api/apikeys/get-api-key)
- [List API Keys](https://docs.anthropic.com/en/api/admin-api/apikeys/list-api-keys)
- [Update API Keys](https://docs.anthropic.com/en/api/admin-api/apikeys/update-api-key)
- [Create Invite](https://docs.anthropic.com/en/api/admin-api/invites/create-invite)
- [Delete Invite](https://docs.anthropic.com/en/api/admin-api/invites/delete-invite)
- [Get Invite](https://docs.anthropic.com/en/api/admin-api/invites/get-invite)


省略

事例：Vercel

#---
title: Node.js HTTP Server
description: Learn how to use the AI SDK in a Node.js HTTP server
tags: ['api servers', 'streaming']
---

# Node.js HTTP Server

You can use the AI SDK in a Node.js HTTP server to generate text and stream it to the client.

## Examples
<snip>
<Note>
  The examples use the OpenAI `gpt-4o` model. Ensure that the OpenAI API key is
  set in the `OPENAI_API_KEY` environment variable.
</Note>

**Full example**: [github.com/vercel/ai/examples/node-http-server](https://github.com/vercel/ai/tree/main/examples/node-http-server)

### Data Stream

You can use the `pipeDataStreamToResponse` method to pipe the stream data to the server response.

省略
...

LLMS.txt対応サイトの一覧

LLMSに対応しているサイトのリストは以下で見られます。 https://llmstxt.site/ https://directory.llmstxt.cloud/

自社サービスをLLMS.txtに対応するアプローチ

LLMに単純にテキストファイルを作らせる
LLMに実装を作らせる
仕様書を流用する
WordPressならplugin

良さげな使い方

NotebookLMに突っ込んで、音声サマリーを作ったり、サマリーを作ったり、FAQを作ったりするのが良いとのことです。

早速試してみましょう。

個人開発しているサイト(郵便番号検索API)に導入

エンドポイントURLはこちらです。

https://postcode.teraren.com/llms.txt https://postcode.teraren.com/llms-full.txt

Claude 3.5 Sonnetに書かせました。リポジトリのデータを元に作っているはずなのに結構間違った情報で作られたので人間が加筆修正しています。

それでもまだ足りていないですが、とりあえず主要なAPIは解説されているのでこれで良しとしてみます。

Clineでリポジトリを開いた状態で打ち込んだプロンプトは以下です。llms.txtが新しいのでClaude 3.5が知らなかったので仕様のURLを渡してます。

llms.txt作って。llms.txtの仕様はhttps://llmstxt.org/です。

ソースコード抜粋

Ruby on Railsで実装しているので少しコードを追加するだけで実装できました。

一部抜粋しておきます。

@controller

+  def llms_txt
+    expires_in 1.day, public: true
+    response.content_type = 'text/markdown'
+    render template: 'home/llms', formats: [:text]
+  end
+
+  def llms_full_txt
+    expires_in 1.day, public: true
+    response.content_type = 'text/markdown'
+    render template: 'home/llms_full_txt', formats: [:text]
+  end

@routes

+  get '/llms.txt' => 'home#llms_txt', :format => false
+  get '/llms-full.txt' => 'home#llms_full_txt', :format => false

@view

+++ b/app/views/home/llms.text.erb
@@ -0,0 +1,85 @@
+# Japanese Postcode Search
+
+> A comprehensive Japanese postcode search service that provides detailed address information, including buildings and offices, with support for Japanese, kana, and romanized text.
+
+This service maintains a database of Japanese postcodes with associated address information at multiple levels (prefecture, city, 
...

NotebookLMに入れて使ってみる

短い方のドキュメントを1つ入れるだけです。

赤坂の郵便番号を調べる問い合わせ方法を聞いてみると、ちゃんと返ってきます。長ったらしいですけど。

API問い合わせのためのRubyクライアントライブラリを書かせてみました。良い感じに作ってくれました。

API問い合わせのためのgoクライアントライブラリを書かせてみました。エンティティの定義が空っぽですが作ってくれました。

WordPressで導入してみる

自社のコーポレートサイトとか、テックブログとか、SDKなどを公開する際に使えるかと思います。

プラグインをインストールして有効化するだけで完了。

こちらの個人ブログで有効化してみました。記事のタイトルの一覧と、記事のテキストがズラッと並びます。

❯ curl -s 'https://blog.teraren.com/llms.txt' | head -n 20
# Matsubo Tech Blog

> Ruby on Rails, Web Services, Software Development, Startups


## 固定ページ

- [History](https://blog.teraren.com/history-of-this-blog/): このブログのヒストリー 2003/5/2...
- [Author](https://blog.teraren.com/yuki-matsukura/): 概要 こんにちは！matsuboです。2...
- [Privacy policy](https://blog.teraren.com/privacy-policy/): 私たちについて 私たちのサイトアドレスは...
- [Copyright](https://blog.teraren.com/copyright/): https://blog. terare...
- [About Me](https://blog.teraren.com/about/): see: https://www. wa...

## 投稿

- [タブレット端末を壁掛けして情報端末として使うといろいろ捗る](https://blog.teraren.com/2024/08/27/tablet-on-the-wall/): 概要 半年ぐらい前から、壁にタブレット端...
- [Web魚拓: 「研究」と「勉強」の違い](https://blog.teraren.com/2024/08/27/diff-study-research/): 概要 過去に何度も参照している以下のペー...
- [寝室のライトを「とったらリモコン」に変更して快適子育て生活](https://blog.teraren.com/2024/08/15/downlight-remote-control/): 概要 リビングの調光スイッチを「とったら...
- [生成系AIサービスから自分のサイトをブロックする方法](https://blog.teraren.com/2024/08/02/block-llm-crawler/): サイトのトップに以下のrobots. t...

NotebookLM に入れて、LLMS.txt を元にしたサマリーを出力してみます。レジュメにかけそうな紹介文を書いてくれてます。（Google のロケールが英語っぽいので英語出でてきちゃってます）

ブログの内容に関連した問い合わせをしてみます。文章ではまとめてないけど拾ってきて理解してくれています。

会話形式のサマリーが作れます。

特に意味は無いけど、クオリティが高いです。Rebuild みたいな感じで 2 人が対話を聞いていくことで人間が学習できます。。音声で人間が知識をインプットするときにはちょうど良さそう。

今回のサンプル音声

右下のところにある機能も面白いです。FAQ の作成、時系列での整理などをショートカットで行えます。

LLMS.txtの考察

戦略的なコンテンツ整備
- 企業情報・サービス説明の構造化
- 製品カタログ・技術文書の最適化
サービス連携の強化
- LLM からの API 呼び出しやサービス利用に使えそう
- API・サービス機能の可視化
- 他サービスに保管してあるデータを自社で運用している RAG に入れるときのプロトコルとして使うとかも良いかもしれません
将来への準備
- AI エージェント時代への対応
- デジタルプレゼンスの最適化
- Search Engine Optimization とともに LLM Optimization の必要性が高まりそう

AIを使ってブラウザ操作を行う事例とツールの紹介

Tue, 04 Feb 2025 00:00:00 GMT

はじめに

AI の世界は急速に進化しており、大規模言語モデル（LLM）が自律的にブラウザを操作する能力を獲得しています。この進展は、LLM に目と手を与えるようなものであり、最小限の人間の介入で複雑なタスクを実行できるようになります。本記事では、LLM によるブラウザ操作の最新の進展を探り、可能性の限界を押し広げる 3 つの強力なツールを紹介します。

重要なポイント

ブラウザを操作する LLM は、目と手を与えられたようなものです。
最近の LLM によるブラウザ操作の進展は目覚ましいものがあります。
3 つのブラウザ操作ツールを実際に紹介します。

なぜ重要なのか

LLM がブラウザ操作を扱うことの利点は何でしょうか？　LLM は自律的にウェブインタフェースをナビゲートし、抽象的な指示に従い、目標に向かって独立して進むことができます。この強化により、LLM の能力が大幅に拡張され、より多用途で強力になります。

ブラウザ操作の最近の動向

OpenAI は Operator を発表しましたが、日本ではまだリリースされていません。専用アプリケーション内で動作し、シームレスなブラウザ操作を実現しているようです。

https://www.youtube.com/watch?v=CSE77wAdDLg

OpenAPI Operatorの使用例

デモの中では以下のようなユースケースが紹介されていました。

タスク自動化
- 繰り返し業務の自動処理
- 複数アプリケーション間のワークフロー連携
インテリジェントアシスタント
- 自然言語でのユーザー問い合わせへの即時応答
- 個人スケジュール管理とリマインダー設定
データ分析支援
- 大規模データセットからの傾向抽出
- 予測モデルの自動構築と可視化
開発者向けツール
- コード生成とデバッグ支援
- API 連携の自動セットアップ
カスタマーサポート
- 24 時間対応のチャットボット
- 問い合わせのトリアージと優先度付け
タスク自動化
- 繰り返し業務の自動処理
- 複数アプリケーション間のワークフロー連携
インテリジェントアシスタント
- 自然言語でのユーザー問い合わせへの即時応答
- 個人スケジュール管理とリマインダー設定
データ分析支援
- 大規模データセットからの傾向抽出
- 予測モデルの自動構築と可視化
開発者向けツール
- コード生成とデバッグ支援
- API 連携の自動セットアップ
カスタマーサポート
- 24 時間対応のチャットボット
- 問い合わせのトリアージと優先度付け
ブラウザ操作の例

Devinの観察日記では、居酒屋でウェブ注文のQRコードをスキャンし、口頭で指示を出して注文する例が紹介されています。その精度は驚くべきもので、一読の価値があります。

既存のツールの紹介

OpenHands: LLM を活用したプログラミングツール
WebPilot: Chrome Extension で動く
Browser Use UI: ホスト OS のブラウザを子プロセスで立ち上げて操作

OpenHandsとは

無料
本来は LLM を使ってシステム開発をするアプリケーション
LLM は外部の API 呼び出し
実行環境は Docker コマンド 1 発で立ち上がる

docker run -it --rm --pull=always \
  -e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.22-nikolaik \
  -e LOG_ALL_EVENTS=true \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v ~/.openhands-state:/.openhands-state \
  -p 3100:3000 \
  --add-host host.docker.internal:host-gateway \
  --name openhands-app \
  docker.all-hands.dev/all-hands-ai/openhands:latest

動作アーキテクチャ

コンテナ上で動作する
ヘッドレスブラウザを裏で立ち上げている。
1つの命令でコンテナを作り直しているので初回は遅い。安全。

プロンプトに指示をしてみます。

ブラウザでYahoo!のニュースページに飛んで、ニュースの要約を作ってくれました。

Webページが複雑なUIだと処理が止まる。。。

WebPilotとは

少し毛色が違いますが便利なUXなので紹介しておきます。

Chromeブラウザプラグインで使うのが一番良いUX
既存のブラウザを使えるのが良い。
独自LLMの無料枠あり。APIでLLMも呼べる。
(ちょっと毛色が違うけど便利だから紹介)

( このUXはブラウザ側でAI APIsとして同じような機能が実装されるはずです)

Web上のクイズを解かせてみました。 Web試験と相性が良さそうです。下の部分のモーダルがWebPilotです。

思考の過程を表示してくれて、それっぽい論理を展開してくれていましたが見事に不正解です。5問ほどやらせてみましたが、2問は不正解でした。

長文のサマリーもやらせてみました。良い感じです。もう少し文量を減らして要点を明確にはできそうですけど合格点かなと思います。

もう少し具体的な指示の元サマリーを作成してみましたが、良い感じに動いています。

Browser-use-webui

今のところ、一番これが良い感じに動きます。

OSS
見た目が面白い
Xでよく紹介されているやつはこれ

セットアップ

git clone https://github.com/browser-use/web-ui.git
cd web-ui

uv venv --python 3.11
source .venv/bin/activate
uv pip install -r requirements.txt
playwright install

cat .env
CHROME_PATH="/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
CHROME_USER_DATA="~/Library/Application Support/Google/Chrome/Default"

ANONYMIZED_TELEMETRY=false

OPENAI_API_KEY=sk-proj-*****
# ANTHROPIC_API_KEY=********

実行

python webui.py --ip 127.0.0.1 --port 7788
open http://127.0.0.1:7788/

setting

ブラウザ上から追加の設定。普段使っているブラウザの Cookie を使いたければ、シークレットブラウザではなく自分のブラウザを立ち上げるように設定を変更します

「NISSAN の EV を試乗予約して！」という感じの雑なプロンプトを投げるとどんどん先に進んで操作してくれます。

試乗できる EV を探してる

EV を選んで、次へ進んで近くのディーラーを探してる

適当な名前で申し込みを入れようとしている。

ここで、停止。スクロールをうまく行ってくれません。手動でスクロールしてあげれば先に進みますが送信ボタンまでは押してくれませんでした。

操作動画

https://youtu.be/Hqelnd6EFag

考察

どれも動作が重いので何度も PC が不安定になる
OpenAI Operator は OpenHands に近そう

おまけ

AI で確定申告をやらせてみた。note に詳細をまとめてあります。

https://note.com/matsubokkuri/n/nc976d5258e37

オンライン消費者調査の現在と未来：LLMがもたらすパラダイムシフト

Sun, 05 Jan 2025 00:00:00 GMT

はじめに

消費者理解を起点とするマーケティング活動において、オンラインでの消費者調査は不可欠な羅針盤として機能してきた。その手法はテクノロジーの進化と共に変容を遂げ、特に2020年代に入り、大規模言語モデル（LLM）という新たな技術的潮流が、業界の根幹を揺るがすほどのパラダイムシフトを予感させている。

本稿では、オンライン消費者調査の過去から現在に至るまでの軌跡をデータに基づき概観し、その標準的なワークフローをより詳細に定義する。その上で、LLMが各ワークフローにどのような変革をもたらし、リサーチャーの役割をどう変えていくのかを論じる。最後に、AIによる代替の可能性とその難易度を評価し、業界が迎える未来の姿を展望したい。

第1章：オンラインリサーチ市場の変遷

1.1. 市場規模とインターネット調査の台頭

日本のマーケティングリサーチ市場は、長らく安定した成長を続けてきた。日本マーケティング・リサーチ協会（JMRA）の調査によれば、2017年度に2,147億円だった市場規模は、2022年には2,590億円へと拡大している。この成長を牽引してきたのが、インターネット調査である。

2002年度にはアドホック調査市場のわずか10%（約80億円）に過ぎなかったインターネットリサーチは、時間とコストの削減効果を武器に急成長を遂げ、訪問調査や郵送調査からのシフトを加速させた。その結果、2010年代後半にはアドホック調査の過半数を占めるに至った。

しかし、その成長にも変化の兆しが見える。2021年から2022年にかけて、インターネット調査の成長率は100.5%と伸び悩み、一方でグループインタビューなどを含む既存手法が112.1%と復調した。さらに2023年には、インターネット調査が前年比98.8%とマイナスに転じ、市場全体が停滞する一因となった。これは、単なる量的拡大の時代の終焉と、リアルな接点を求める「揺り戻し」や、より複合的な調査手法への移行を示唆しているのかもしれない。

1.2. 定量調査と定性調査の役割

市場の中心が、量的な傾向を把握する「定量調査」、特にオンラインアンケートであったことは論を俟たない。一方で、消費者の深層心理や行動の背景にある「なぜ」を探る「定性調査」（グループインタビュー、デプスインタビューなど）も、仮説構築やインサイト発見のために重要な役割を担い続けてきた。近年のリアル調査への回帰は、この定性的な理解への価値が再認識されていることの表れとも考えられる。

第2章：現代のオンラインリサーチの構造

2.1. 業界地図と主要プレイヤー

マーケティングリサーチ業界は、売上高20億円未満の企業が8割を占めるなど、多数の中小規模プレイヤーによって構成されている。その中で、プライム市場に上場する

インテージホールディングス、マクロミル、クロス・マーケティンググループの3社が大手として市場を牽引している。

インテージグループ: 1960年創業の国内最大手。60年以上の歴史で培った信頼性と、SCI®（全国消費者パネル調査）に代表される高品質・大規模なパネルデータが最大の強みである。近年はAIやデータハンドリング技術への投資も積極的で、データ解析力とソリューション提供能力で他をリードする。
マクロミル: オンラインリサーチで国内トップシェアを誇る。自社・提携合わせて3,600万人規模の広範なパネルネットワークを武器に、年間2万件以上の調査実績を持つ。創業時からリサーチ業務の分業制を導入し、各専門人材の育成による効率性とスピードを強みとする。
クロス・マーケティンググループ: 国内最大級の1,285万人のパネルネットワークを活用し、年間1万件以上の調査実績を持つ。リサーチ事業を中核としながら、データマーケティングやITソリューションなど事業を多角化し、顧客の課題解決に一気通貫で対応する「総合力」を特徴とする。

これらの大手は、独自の強固なパネル基盤とテクノロジーへの投資を背景に、業界内での存在感を高めている。一方で、こうした大手とは異なるアプローチで市場に新たな価値を提案するスタートアップも登場している。例えば、株式会社マインディアのように、テクノロジーを活用してオンラインでの定性調査をより手軽かつ迅速に実施できるプラットフォームを提供する企業は、従来の時間とコストが課題であった定性調査の民主化を推し進めている。こうした動きは、リサーチ業界におけるイノベーションの新たな潮流となっている。

2.2. オンライン定量調査の標準的ワークフロー

オンライン定量調査、特にインターネットリサーチは、多くのステップを経て実施される。その標準的なワークフローは以下のように分解できる。

ビジネス課題のヒアリング・要件定義: クライアントが抱える課題を明確にする。
調査目的・仮説の設定: 何を明らかにするための調査なのか、その結果どういった仮説が検証できるのかを定義する。
調査手法・対象者条件の決定: 調査手法（Webアンケートなど）や対象者の属性（年齢、性別など）を決定する。
質問項目の洗い出し: 仮説検証に必要な質問項目を網羅的にリストアップする。
調査票ドラフト作成: 洗い出した項目を基に、回答者が答えやすいように質問文や選択肢を構成する。
調査票のロジック設計・確認: 特定の回答をした人だけが次の質問に進むといった分岐（スキップロジック）を設計・確認する。
アンケート画面作成（プログラミング）: 調査票をWebアンケートシステム上で動作するようにプログラミングする。
テスト配信・デバッグ: 画面表示やロジックに誤りがないか、少人数にテスト配信して確認する。
本配信・データ収集: 対象者全体にアンケートを配信し、データを回収する。
データクリーニング・集計: 不誠実な回答や矛盾した回答を除外し、データを集計する。
集計表・グラフ作成: 集計結果を基に、クロス集計表やグラフを作成する。
分析・考察: データから傾向を読み解き、示唆を導き出す。
レポート作成・報告: 分析結果をまとめてクライアントに報告する。

2.3. オンライン定性調査の標準的ワークフロー

オンラインでのグループインタビューなどに代表される定性調査は、より人間系のスキルが求められるプロセスで構成され、そのワークフローは以下のように詳細化できる。

調査目的・課題の明確化: なぜその調査が必要なのか、核心的な問いを定める。
対象者条件の設定（リクルーティング要件定義）: どのような経験や価値観を持つ人に話を聞くべきかを詳細に定義する。
インタビューフローの設計: 対象者から深いインサイトを引き出すための質問の流れや構成を設計する。
募集画面の作成: 対象者を募集するための告知ページや文面を作成する。
スクリーニングアンケートによる対象者選定: 応募者の中から、条件に合致する対象者をアンケートで絞り込む。
対象者への参加依頼・調整: 選定された対象者に連絡を取り、インタビューの日時や方法を調整する。
インタビューの実施・進行（モデレーション）: 場の空気を作り、対象者がリラックスして本音を話せるようにインタビューを進行する。
録画・録音データの確認: インタビュー内容を後から確認できるように、記録データを確認・整理する。
文字起こし・発言録作成: インタビューの発言をすべてテキスト化する。
発言内容の構造化・分析: 発言録を読み解き、内容をテーマごとに分類・構造化する。
インサイト抽出・レポート作成: 分析結果から本質的な示唆（インサイト）を抽出し、レポートにまとめる。

2.4. AI活用リサーチの既存事例（国内・海外）

LLMによる変革を語る上で、すでに国内外でAIを活用してリサーチ業界の課題解決に取り組む企業が登場していることは注目に値する。これらは未来の潮流を占う試金石と言える。

【国内事例】AI活用の動向

株式会社マインディア: オンライン定性調査プラットフォームを提供する同社は、インタビュー後の分析工程の自動化にAIを積極的に活用。従来、多大な時間を要した文字起こし作業に加え、長大な発言録から要点を抽出するサマリー作成、さらには分析結果を基にしたレポート作成の自動化にも取り組んでおり、リサーチャーがより本質的なインサイト発見に集中できる環境を構築している。

【海外事例】多様なアプローチで価値を創出

海外では、より多角的なアプローチでAIを活用するプレイヤーが台頭している。

Quantilope (ドイツ): 「End-to-Endの自動化」を掲げ、調査設計から分析、レポーティングまでの一連のプロセスをAIで自動化するプラットフォームを提供。リサーチの全工程を高速化する。
Zappi (英国): 「アジャイルな意思決定」を支援。AIベースの調査テンプレートを事前に設計しておくことで、広告や新商品のコンセプトテストといった特定の調査を高速で繰り返し実行できる。
Remesh (米国): 「大規模定性調査」という新たな領域を開拓。AIモデレーターが数百人規模の参加者とリアルタイムで対話し、その自由回答を瞬時に分析・可視化することで、定性的な深さと定量的な規模感を両立させる。
Entropik (インド): 「非言語データの活用」に強みを持つ。視線や表情、声色といった感情データをAIで解析し、ユーザーが言葉にしない本音を炙り出す、次世代のUX・広告評価調査を提供する。
Black Swan Data (英国): 「外部データのインサイト化」に特化。SNSの投稿など、膨大なオープンデータをAIで分析し、消費者の無意識なトピックや未来のトレンドを予測・抽出する。

これらの事例から、AIの活用法は一様ではないことがわかる。国内ではマインディアのようにインタビュー後の分析工程の自動化に注力する動きがある一方、海外ではQuantilopeのように全工程の自動化を目指すプレイヤー、RemeshやEntropikのように定性調査の可能性を拡張するプレイヤー、Black Swan Dataのように新たなデータソースから価値を生むプレイヤーが存在する。この国内外の潮流は、リサーチ業界がAIによって労働集約的な構造から脱却し、より戦略的で高度なインサイトを提供する産業へと進化していく必然性を示している。

第3章：LLMが拓くオンラインリサーチの未来

3.1. ワークフローの自動化と設計例

LLMの登場は、前章で定義したワークフローを単に効率化するだけでなく、その実行プロセス自体を再設計する。ここでは、各ワークフローをLLMで自動化するための具体的な設計思想とプロセスを詳述する。

3.1.1. 定量調査ワークフローの設計例

対象工程：調査票作成からアンケート画面実装まで

設計思想: リサーチャーの「意図」を自然言語で受け取り、直接実行可能なアンケートシステム用の設定ファイル（JSON, XML等）を生成する「意図-実行変換（Intent-to-Execution）」モデルを構築する。
具体的なプロセス:

入力（リサーチャーの意図）: 「30代男性会社員を対象に、缶コーヒーの飲用習慣に関する調査をしたい。頻度、購入場所、重視点を聴取し、週1回未満のライトユーザーには、その理由を深掘りする質問を追加してほしい」といった自然言語での指示。
LLMによる処理（思考連鎖）:

エンティティ抽出: LLMはまず指示を分解し、[対象者: 30代男性会社員]、[テーマ: 缶コーヒー]、[聴取項目: 頻度, 場所, 重視点]、[条件分岐: 週1回未満→理由深掘り]といった構成要素を抽出する。
質問生成: 各聴取項目に基づき、具体的な質問文と選択肢を生成する。「Q1. あなたは普段、どのくらいの頻度で缶コーヒーを飲みますか？ (SA) 1. 毎日 2. 週に4-5回... 6. 飲まない」
ロジックの定式化: 自然言語のロジックを、システムが解釈可能な形式 {"condition": "Q1.answer == 6", "action": "show_question", "target": "Q1_follow_up"} に変換する。

出力（実行可能な設定ファイル）: 全ての質問とロジックを構造化データ（例：JSON）として出力する。このファイルをアンケートシステムにインポートするだけで、テスト可能な画面が即座に構築される。

対象工程：分析とレポーティング

設計思想: 「データ分析エージェント」と「レポーティングエージェント」を連携させるマルチエージェントシステムを構築し、データ投入からレポートドラフト作成までをパイプライン化する。
具体的なプロセス:

入力: 回収済みのアンケートデータ（CSV形式）と、「男女別の購入ブランドランキングと、年代別の飲用頻度の違いに焦点を当てたレポートを作成せよ」という指示。
データ分析エージェントの実行:

Code Interpreter機能を持つLLMが、Python（pandas, matplotlib）コードを生成・実行する。
クロス集計（性別×ブランド、年代×頻度）を行い、統計的に有意な差があるかを検定する。
結果を可視化するためのグラフ（棒グラフ、円グラフ等）を生成する。

レポーティングエージェントの実行:

分析エージェントから出力された集計表やグラフデータを読み込む。
LLMがそのデータを解釈し、「30代では『毎日飲む』層が45%を占める一方、50代では20%に留まり、健康志向の高まりが示唆される」といったインサイトのテキスト記述を生成する。
事前に定義されたレポートテンプレートに沿って、タイトル、サマリー、各グラフとそれに対応する考察を自動で配置し、PowerPointやWord形式のドラフトを生成する。

3.1.2. 定性調査ワークフローの設計例

対象工程：インタビューフローの設計

設計思想: 優れたモデレーターの思考プロセスを模倣する「ペルソナプロンプティング」を活用し、質の高いインタビューフローのたたき台を生成する。
具体的なプロセス:

入力: 調査企画書（調査背景、目的、対象者プロファイルなど）。
LLMへの指示（ペルソナ設定）: 「あなたは20年の経験を持つベテランモデレーターです。以下の調査企画書に基づき、60分のデプスインタビューのフローを作成してください。導入のアイスブレイクから始め、対象者の生活実態、カテゴリ関与、そして本題の製品評価へと自然に移行する流れを意識してください。各質問には、その質問で何を引き出したいのかという『狙い』も併記すること。」
出力: 時間配分、具体的な質問例、質問の狙いが明記された、構造化されたインタビューフローが出力される。これにより、リサーチャーはゼロから考えるのではなく、AIが生成した質の高いドラフトを基に、より戦略的な調整に集中できる。

対象工程：発言録の構造化と分析

設計思想: 長大な非構造テキストである発言録を、多段階のLLM処理（パイプライン）を通じて、構造化されたインサイトデータへと変換する。
具体的なプロセス:

入力: インタビューのフルテキスト発言録。
第1段階（セグメンテーション＆要約）: LLMが発言録を意味のあるトピック単位（例：「自己紹介」「普段の食生活」「製品Aの第一印象」）に分割し、各セグメントを簡潔に要約する。
第2段階（コード化＆ラベリング）: 別のLLMが、各発言に対して「ポジティブな感情」「価格への不満」「競合製品Bへの言及」といった分析コード（ラベル）を付与していく。
第3段階（テーマ抽出）: 全ての発言録に付与されたコード群をクラスタリングし、「パッケージの高級感が購入の決め手」「後味の悪さがリピートを阻害」といった、複数の発言を横断する共通のインサイトテーマを抽出する。

出力: 重要な発言、それに対応する分析コード、そして抽出されたインサイトテーマが一覧化された分析サマリー。マーケティング担当者がAIに最も期待する「分析・インサイト抽出」を直接的に支援するアウトプットとなる。

3.2. AIによる代替の難易度評価

LLMは万能ではない。詳細化されたワークフローの各ステップをAIが代替する難易度には明確な差が存在する。

定量調査

難易度

ワークフローのステップ

理由・具体例

高

ビジネス課題のヒアリング・要件定義

分析・考察

クライアントの暗黙的なニーズを汲み取り、ビジネス全体の文脈を理解した上で、データの裏にある本質的な意味を解釈し、戦略的な示唆を導き出す能力は、依然として高度な人間的知性が不可欠。

中

調査目的・仮説の設定

調査票のロジック設計・確認

レポート作成・報告

LLMは優れたドラフトを生成できるが、最終的な妥当性の判断や、クライアントの特性に合わせた微調整、説得力のあるストーリーテリングには人間の介入が必要。特に複雑なロジックの最終確認は重要。

低

調査手法・対象者条件の決定

質問項目の洗い出し

調査票ドラフト作成

アンケート画面作成

テスト配信・デバッグ

本配信・データ収集

データクリーニング・集計

集計表・グラフ作成

明確なルールやパターンに基づいており、自動化との親和性が非常に高い領域。調査票作成から画面作成までの自動化はすでに実用化が進んでいる。データ処理や集計も大半が自動化可能。

定性調査

難易度

ワークフローのステップ

理由・具体例

高

調査目的・課題の明確化

インタビューの実施・進行（モデレーション）

インサイト抽出・レポート作成

モデレーションは、相手の非言語的サイン（表情、声色）を読み取り、信頼関係を築き、予期せぬ発言を深掘りする共感性と即興性が求められ、AIによる完全な代替は最も困難。ただし、「AIモデレーター」のような、構造化されたヒアリングを自動化するサービスも登場し始めており、部分的な活用は進む可能性がある。
インサイト抽出は、複数の発言の断片を繋ぎ合わせ、背景にある文化や価値観までを洞察する飛躍的な思考を要するため、難易度が高い。

中

対象者条件の設定

発言内容の構造化・分析

LLMはペルソナ定義の支援や、発言録の分類・タグ付けは高精度に行える。しかし、その分類が調査目的に対して本当に意味のあるものか、どの分析軸が重要かを見極める最終判断は人間に委ねられる。

低

インタビューフローの設計

募集画面の作成

スクリーニングアンケートによる対象者選定

対象者への参加依頼・調整

録画・録音データの確認

文字起こし・発言録作成

目的や条件が明確であれば、LLMは高品質なドラフト作成や、単純な事務作業、音声のテキスト化を高効率に実行できる。これらは最も早期にAIに置き換わる領域となる。

結論

オンライン消費者調査の世界は、LLMという強力な触媒を得て、今まさに大きな化学反応の渦中にある。市場の成長は踊り場を迎え、プレイヤーは新たな付加価値の創出を迫られている。この状況下で、AIは脅威ではなく、リサーチの価値を再定義するための強力なパートナーとなるだろう。

調査票のプログラミング、文字起こし、自由回答の分類、レポートのドラフト作成といった、これまで多大な時間を要した定型的かつ労働集約的なタスクは、今後急速にAIに代替されていく。その結果、リサーチャーの役割は、AIを使いこなす「オペレーター」から、AIでは代替不可能な領域、すなわち「問いを立てる力（課題設定・調査企画）」「人の心を引き出す力（モデレーション）」「意味を見出す力（インサイト発見と戦略提言）」へと明確にシフトする。

未来のリサーチは、AIが生成した膨大な分析結果の「点」を、経験豊かなリサーチャーがビジネス文脈に沿って結びつけ、価値ある「線」や「面」として描き出す、人間とAIの協働作業となるだろう。この変革に適応し、人間ならではの価値を磨き上げた者だけが、次世代のマーケティングリサーチをリードしていくに違いない。

Rails 8でWebサービスをPWA(Progressive Web Apps)対応。最低限の設定を速攻で。

Wed, 25 Dec 2024 00:00:00 GMT

はじめに

この記事は、Ruby on Rails Advent Calendar 2024の21日目です。

Rails 8 で簡単に PWA 対応ができるようになりました。この記事では、最小限の設定で Rails アプリケーションを PWA 化する方法を紹介します。

本記事では郵便番号検索サービス「ポストくん」を PWA 対応してみます。

https://postcode.teraren.com/

PWAとは？

Progressive Web App (PWA) は、Web アプリケーションでありながら、ネイティブアプリのような体験を提供する技術です。オフライン対応、ホーム画面へのインストール、プッシュ通知などの機能を実現できます。

PWA 対応していると検索エンジンからの評価が上がるといった発言もあります。

Rails 8のPWA対応

Rails 8 では、PWA に必要な基本的なファイルが最初から用意されています。具体的には以下の 2 つです：

マニフェストファイル (manifest.json)
サービスワーカー (service-worker.js)

これらのファイルを使って、簡単に PWA 対応ができるようになりました。

最低限の設定手順

1. ルーティングの設定

config/routes.rb に以下の 2 行を追加します：

get "service-worker" => "rails/pwa#service_worker", as: :pwa_service_worker
get "manifest" => "rails/pwa#manifest", as: :pwa_manifest

2. マニフェストファイルの作成

app/views/pwa/manifest.json.erb ファイルを作成し、以下のような内容を記述します：

{
  "name": "あなたのアプリ名",
  "short_name": "短い名前",
  "description": "アプリの説明",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#FFFFFF",
  "theme_color": "#000000",
  "icons": [
    {
      "src": "<%= asset_path('icon-192x192.png') %>",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "<%= asset_path('icon-512x512.png') %>",
      "sizes": "512x512",
      "type": "image/png"
    }
  ]
}

3. サービスワーカーの作成

app/views/pwa/service-worker.js ファイルを作成し、以下のような基本的な内容を記述します：

self.addEventListener('install', function(event) {
  console.log('Service Worker installing.');
});

self.addEventListener('activate', function(event) {
  console.log('Service Worker activated.');
});

self.addEventListener('fetch', function(event) {
  console.log('Fetching:', event.request.url);
});

内容的にはなにもしていませんが、今後の実装のためのメモ的な位置づけです。

4. アプリケーションレイアウトの更新

app/views/layouts/application.html.erb ファイルの <head> セクション内に以下の行を追加します：

<link rel="manifest" href="<%= pwa_manifest_path(format: :json) %>">
<meta name="apple-mobile-web-app-capable" content="yes">

5. アイコンの準備

PWA用のアイコンを app/assets/images/ ディレクトリに配置します。少なくとも192×192と512x512サイズのアイコンを用意しましょう。

6. JavaScriptでサービスワーカーを登録

app/javascript/application.js に以下のコードを追加して、サービスワーカーを登録します：

if ('serviceWorker' in navigator) {
  window.addEventListener('load', () => {
    navigator.serviceWorker.register('/service-worker.js')
      .then(registration => {
        console.log('Service Worker registered:', registration);
      })
      .catch(error => {
        console.log('Service Worker registration failed:', error);
      });
  });
}

あとはブラウザでアクセスするだけです。

動作確認

Chrome などでアクセスするとアドレスバーの横にこのように表示されてアプリとしてインストールできます。 2 回目以降はアプリへの動線が表示されます。

PWA のアプリで開くと以下のような表示になります。

コマンドランチャーからも起動できるようになります。

応用

PWA Builder というサイトを使うと PWA 対応しているサイトから iOS, Android 向けのアプリパッケージを作ってくれるサイトがあります。

PWA 対応を最低限するだけでは情報が不足しているので、アプリにもビルドできるように必要情報を拡充すればアプリのリリースも可能です。 (今回は最低限しか情報を記述していなかったり、アイコンを用意していないのでかなり不足してます。)

まとめ

以上の設定で、Rails 8 アプリケーションの基本的な PWA 対応が完了します。これだけで、ユーザーはあなたの Web アプリをホーム画面に追加できるようになります。

さらに進んだ PWA 機能（オフラインサポート、プッシュ通知など）を実装する場合は、サービスワーカーの内容を拡張する必要があります。

Rails 8 の PWA サポートにより、Web 開発者はより簡単にモバイルフレンドリーなアプリケーションを構築できるようになりました。ぜひ、あなたの Rails アプリケーションも PWA 化してみてください！

New Relicで自宅サーバ監視・Railsアプリ測定・外形監視を導入した手順

Thu, 12 Dec 2024 00:00:00 GMT

概要

自宅サーバと個人サービスに New Relic を導入してみました。
9 年ぶりに New Relic を触りました。別物と言えるぐらい高機能化していました。セットアップも簡単で UI も使いやすい。
無料で利用開始できるのでおすすめである。

この記事は New Relic Advent Calendar 2024の13日目の記事です。他の記事も見てね

背景

10 年ほど前に New Relic を無料版で使っていてたのですが、残念ながら 2015 年に、New Relic の無料版の提供が廃止されたのでそれ以降は別の監視サービスを転々と使ってきました。

このたび、Qiita の Advent Calendar にて New Relic に無料版があるという記述があったのでしばらくぶりに使ってみました。

このような監視サービスを選定する際は、自宅サーバで試してみて良かったら業務で使うという流れを取ることが多いので無料で提供されているのはとても助かります。

現在の監視運用

自宅サーバ、アプリケーションのリソース監視には Mackerel をかれこれ 7 年使い続けています。 1 日だけのリテンションであれば無料で使えます。

グラフは見やすいし、アラートもトリガーできるので小規模サービスには適しているサービスかなと思います。

また、HTTP による外形監視は無料ではできないので uptimerobotを利用しています。

Linuxサーバの監視

自宅サーバである Linux に NewRelic を入れて監視してみます。

自宅サーバは Ubuntu 24 で運用しています。

❯ fastfetch
                             ....              matsu@gmk
              .',:clooo:  .:looooo:.           ---------
           .;looooooooc  .oooooooooo'          OS: Ubuntu noble 24.04 x86_64
        .;looooool:,''.  :ooooooooooc          Host: M2
       ;looool;.         'oooooooooo,          Kernel: Linux 6.8.0-36-generic
      ;clool'             .cooooooc.  ,,       Uptime: 164 days(!), 17 hours, 39 mins
         ...                ......  .:oo,      Packages: 1524 (dpkg), 5 (snap)
  .;clol:,.                        .loooo'     Shell: fish 3.7.0
 :ooooooooo,                        'ooool     Theme: Yaru [GTK3]
'ooooooooooo.                        loooo.    Icons: Yaru [GTK3]
'ooooooooool                         coooo.    Cursor: Adwaita
 ,loooooooc.                        .loooo.    Terminal: tmux 3.4
   .,;;;'.                          ;ooooc     CPU: 11th Gen Intel(R) Core(TM) i7-11390H (8) @ 5.00 GHz
       ...                         ,ooool.     GPU: Intel Iris Xe Graphics @ 1.40 GHz [Integrated]
    .cooooc.              ..',,'.  .cooo.      Memory: 14.08 GiB / 31.10 GiB (45%)
      ;ooooo:.           ;oooooooc.  :l.       Swap: 2.64 GiB / 8.00 GiB (33%)
       .coooooc,..      coooooooooo.           Disk (/): 199.40 GiB / 934.82 GiB (21%) - ext4
         .:ooooooolc:. .ooooooooooo'           Local IP (enp2s0): 192.168.1.28/24
           .':loooooo;  ,oooooooooc            Locale: en_US.UTF-8
               ..';::c'  .;loooo:'

早速左上部にある Integrations & Agents からLinuxを追加してエージェントを追加していきます。

打つコマンドがコピー&ペーストできるように用意されているのでそのまま打ち込んでいきます。コピペするだけなのでとても楽です。

❯ curl -Ls https://download.newrelic.com/install/newrelic-cli/scripts/install.sh | bash && sudo NEW_RELIC_API_KEY=NRAK-XXXXXXXXXXXXXXXXXXXXXXXXXXX NEW_RELIC_ACCOUNT_ID=00000 /usr/local/bin/newrelic install
Installing New Relic CLI v0.97.2
Installing to /usr/local/bin using sudo
[sudo] password for matsu:

 _   _                 ____      _ _
| \ | | _____      __ |  _ \ ___| (_) ___
|  \| |/ _ \ \ /\ / / | |_) / _ | | |/ __|
| |\  |  __/\ V  V /  |  _ |  __| | | (__
|_| \_|\___| \_/\_/   |_| \_\___|_|_|\___|

Welcome to New Relic. Let's set up full stack observability for your environment.
Our Data Privacy Notice: https://newrelic.com/termsandconditions/services-notices

◥ Connecting to New Relic Platform.

上記のメッセージが表示されて様々なパッケージのインストールが行われていきます。 5分ぐらいトータルで経過したと思います。

インストールログ:

Installing New Relic

==> Installing Infrastructure Agent
Detecting available SSL ciphers...
 - SSLv3
 - TLSv1
 - TLSv1.2
 - TLSv1.3
Hit:1 https://nvidia.github.io/libnvidia-container/stable/deb/amd64  InRelease
Hit:2 http://jp.archive.ubuntu.com/ubuntu noble InRelease
Get:3 http://security.ubuntu.com/ubuntu noble-security InRelease [126 kB]
Get:4 http://jp.archive.ubuntu.com/ubuntu noble-updates InRelease [126 kB]
Get:5 https://pkgs.tailscale.com/stable/ubuntu noble InRelease
Get:6 https://esm.ubuntu.com/apps/ubuntu noble-apps-security InRelease [7,532 B]
Hit:7 https://ppa.launchpadcontent.net/zhangsongcui3371/fastfetch/ubuntu noble InRelease
Get:8 https://esm.ubuntu.com/apps/ubuntu noble-apps-updates InRelease [7,468 B]
Get:9 http://jp.archive.ubuntu.com/ubuntu noble-backports InRelease [126 kB]
Get:10 https://esm.ubuntu.com/infra/ubuntu noble-infra-updates InRelease [7,461 B]
Get:11 http://security.ubuntu.com/ubuntu noble-security/main amd64 Components [7,192 B]
Get:12 https://esm.ubuntu.com/infra/ubuntu noble-infra-security InRelease [7,462 B]
Get:13 http://security.ubuntu.com/ubuntu noble-security/restricted amd64 Components [212 B]
Get:14 http://security.ubuntu.com/ubuntu noble-security/universe amd64 Packages [564 kB]
Get:15 http://jp.archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages [706 kB]
Get:16 http://jp.archive.ubuntu.com/ubuntu noble-updates/main amd64 Components [151 kB]
Get:17 http://jp.archive.ubuntu.com/ubuntu noble-updates/restricted amd64 Components [212 B]
Get:18 http://jp.archive.ubuntu.com/ubuntu noble-updates/universe amd64 Packages [729 kB]
Get:19 http://security.ubuntu.com/ubuntu noble-security/universe amd64 Components [51.9 kB]
Get:20 http://security.ubuntu.com/ubuntu noble-security/multiverse amd64 Components [208 B]
Get:21 http://jp.archive.ubuntu.com/ubuntu noble-updates/universe amd64 Components [310 kB]
Get:22 http://jp.archive.ubuntu.com/ubuntu noble-updates/multiverse amd64 Components [940 B]
Get:23 http://jp.archive.ubuntu.com/ubuntu noble-backports/main amd64 Components [208 B]
Get:24 http://jp.archive.ubuntu.com/ubuntu noble-backports/restricted amd64 Components [216 B]
Get:25 http://jp.archive.ubuntu.com/ubuntu noble-backports/universe amd64 Components [11.7 kB]
Get:26 http://jp.archive.ubuntu.com/ubuntu noble-backports/multiverse amd64 Components [212 B]
Fetched 2,947 kB in 8s (370 kB/s)
Reading package lists...
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
OK
Get:1 https://download.newrelic.com/infrastructure_agent/linux/apt noble InRelease [10.8 kB]
Hit:2 https://nvidia.github.io/libnvidia-container/stable/deb/amd64  InRelease
Get:3 https://download.newrelic.com/infrastructure_agent/linux/apt noble/main amd64 Packages [20.8 kB]
Hit:4 http://jp.archive.ubuntu.com/ubuntu noble InRelease
Hit:5 http://security.ubuntu.com/ubuntu noble-security InRelease
Hit:6 http://jp.archive.ubuntu.com/ubuntu noble-updates InRelease
Get:7 https://pkgs.tailscale.com/stable/ubuntu noble InRelease
Hit:8 https://ppa.launchpadcontent.net/zhangsongcui3371/fastfetch/ubuntu noble InRelease
Hit:9 http://jp.archive.ubuntu.com/ubuntu noble-backports InRelease
Hit:10 https://esm.ubuntu.com/apps/ubuntu noble-apps-security InRelease
Hit:11 https://esm.ubuntu.com/apps/ubuntu noble-apps-updates InRelease
Hit:12 https://esm.ubuntu.com/infra/ubuntu noble-infra-updates InRelease
Hit:13 https://esm.ubuntu.com/infra/ubuntu noble-infra-security InRelease
Fetched 38.1 kB in 2s (16.0 kB/s)
Reading package lists...
W: https://download.newrelic.com/infrastructure_agent/linux/apt/dists/noble/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.
[master 7b2a993] saving uncommitted changes in /etc prior to apt run
 Author: Yuki Matsukura <matsubokkuri@gmail.com>
 4 files changed, 11 insertions(+)
 create mode 100644 apt/sources.list.d/newrelic-infra.list
 create mode 100644 apt/trusted.gpg
 create mode 100644 newrelic-infra.yml
Selecting previously unselected package libpq5:amd64.
(Reading database ... 412755 files and directories currently installed.)
Preparing to unpack .../libpq5_16.6-0ubuntu0.24.04.1_amd64.deb ...
Unpacking libpq5:amd64 (16.6-0ubuntu0.24.04.1) ...
Selecting previously unselected package fluent-bit.
Preparing to unpack .../fluent-bit_3.1.9_amd64.deb ...
Unpacking fluent-bit (3.1.9) ...
Selecting previously unselected package newrelic-infra.
Preparing to unpack .../newrelic-infra_1.58.0_amd64.deb ...
Unpacking newrelic-infra (1.58.0) ...
Setting up libpq5:amd64 (16.6-0ubuntu0.24.04.1) ...
Setting up newrelic-infra (1.58.0) ...
Created symlink /etc/systemd/system/multi-user.target.wants/newrelic-infra.service → /etc/systemd/system/newrelic-infra.service.
Setting up fluent-bit (3.1.9) ...
Processing triggers for libc-bin (2.39-0ubuntu8.3) ...
[master 9601789] committing changes in /etc made by "apt-get -o DPkg::Lock::Timeout=60 install newrelic-infra -y -qq"
 Author: Yuki Matsukura <matsubokkuri@gmail.com>
 12 files changed, 477 insertions(+)
 create mode 100644 fluent-bit/fluent-bit.conf
 create mode 100644 fluent-bit/parsers.conf
 create mode 100644 fluent-bit/plugins.conf
 create mode 100644 newrelic-infra/integrations.d/docker-config.yml
 create mode 100644 newrelic-infra/logging.d/file.yml.example
 create mode 100644 newrelic-infra/logging.d/fluentbit.yml.example
 create mode 100644 newrelic-infra/logging.d/syslog.yml.example
 create mode 100644 newrelic-infra/logging.d/systemd.yml.example
 create mode 100644 newrelic-infra/logging.d/tcp.yml.example
 create mode 120000 systemd/system/multi-user.target.wants/newrelic-infra.service
 create mode 100644 systemd/system/newrelic-infra.serviceo

 [snip]

色々インストールされたみたいです。

 --------------------
Installation Summary

✔  Golden Signal Alerts  (installed)
✔  Infrastructure Agent  (installed)
✔  Logs Integration  (installed)
−  PostgreSQL Integration  (canceled)

View your data at the link below:
⮕  https://onenr.io/0PwJkmyg7R7

View your logs at the link below:
⮕  https://onenr.io/0qwyqxKMXwn
--------------------

最後に結果のサマリーが表示されます。 postgresqlはOSにはインストールされていないので、インストールはしなかったようです。

Webの方に戻ってみると同様の結果が表示されています。

左のメニューからall entitiesを選択するとさきほどインストールしたホストが一覧に表示されます。

早速ですがメトリックがグラフになって表示されています。特に設定はしていなくてもこのダッシュボードと計測メトリックがデフォルトで提供されます。楽です！

短期間だとデータが溜まっていないのでしばらくしてから再度アクセスしてみました。色々溜まってます。

別のニューを見てみます。OSのログもNew Relicに送信されているようでリアルタイムでログの出力が確認できます。おそらく、/var/log/nginxに保存されているアクセスログが出力されているようです。

network関連のメニュー

トラフィックが見られます

process関連のメニュー

メモリ利用量などが見られます

storage関連のメニュー

容量と、ディスクアクセスが見られます

systemのメニュー

Load Averageやメモリ使用量が見られます

Dependenciesのメニュー

docker containerが一覧で見られる感じです。

Diagnoseのメニュー

横断的に重要な指標が表示されています

特に設定をせずにAgentをインストールするだけで様々な指標がグラフィカルに表示できるようになりました。

ここまでで15分ぐらいしかかかっていないので導入の簡単さに驚きです。

APM

APMとは、アプリケーションやシステムのパフォーマンスを監視・管理するプロセス、またはそのためのツールを指します。

APMの主な機能には、次のようなものがあります。

応答時間、スループット、エラー率などの主要なメトリックの監視
障害の自動検出とリアルタイムなアラート通知
リソースの使用状況のトラッキング
サービスレベル指標の可視化
エンド・ツー・エンドでの構成の可視化
アプリケーションリリースや構成変更の記録

Dockerの統計情報は、APMを入れないでも閲覧できました。

Ruby on RailsへAPMの導入

個人サービスをRailsで運用しているのでRailsにインストールしてみます。

表示される手順通りにセットアップすれば完了します。

bundler add newrelic_rpm

表示されている設定内容を config/newrelic.yml へ保存します。

その後、Railsのアプリケーションサーバを再起動します。

次に、エージェントのプログラムをインストールします。

root@924713a52351:/app# curl -Ls https://download.newrelic.com/install/newrelic-cli/scripts/install.sh | bash && sudo NEW_RELIC_API_KEY=NRAK-XXXXXXXXXXXXXXXXXXXXXX NEW_RELIC_ACCOUNT_ID=1111111 /usr/local/bin/newrelic install -n logs-integration
Installing New Relic CLI v0.97.2
Installing to /usr/local/bin

 _   _                 ____      _ _
| \ | | _____      __ |  _ \ ___| (_) ___
|  \| |/ _ \ \ /\ / / | |_) / _ | | |/ __|
| |\  |  __/\ V  V /  |  _ |  __| | | (__
|_| \_|\___| \_/\_/   |_| \_\___|_|_|\___|

Welcome to New Relic. Let's set up full stack observability for your environment.
Our Data Privacy Notice: https://newrelic.com/termsandconditions/services-notices

✔ Connecting to New Relic Platform
   Connected


Installing New Relic Logs Integration
  --------------------
  Installation Summary

  ⊘  Infrastructure Agent  (unsupported)
  ⊘  Logs Integration  (unsupported)

  Installation incomplete. Follow the instructions at the URL below to complete the installation process.

  ⮕  https://onenr.io/0ERz7nLxzjr

  --------------------


We encountered an issue during the installation: no recipes were installed.
If this problem persists, visit the documentation and support page for additional help here at https://docs.newrelic.com/docs/infrastructure/install-infrastructure-agent/get-started/requirements-infrastructure-agent/

インストールに失敗したというメセージが出てきましたが、NewRelicのWebを閲覧してみたら Docker Containerの情報が出力されていました。

真ん中あたりにある、遅いリクエストトップ5が掲載されています。

クリックすると、ブレークダウンしてくれます。遅い処理を簡単に分析できます。すごい便利。

Webページの表示速度も自動的に計測してくます。LCP,INP,CLSのスコアを自動的に集計して表示してくれます。これは便利です。

使うべきではない言葉なので修正してください間にビーコンを埋め込まれていたので、要注意ではありますね。

脆弱性のあるパッケージのチェックをしてくれるようです。

APM Forwardingというパッケージを入れるとアプリケーションのログを転送してくれるようです。

E2E監視

無料版だとリクエスト数に制限がありますが、E2E監視も試せます。無料だと6時間に1回ぐらいしか行えませんが設定を軽く試してみます。

自分でスクリプトを書いて監視内容をカスタマイズできます。今回は以下のようなスクリプトを書いてエンドポイントのヘルスチェックを行いました。

var assert = require('assert');
$http.get('https://postcode.teraren.com/healthcheck.json',
  function (err, response, body) {
    // エラーチェック
    assert.equal(response.statusCode, 200, 'Expected a 200 OK response');
    
  }
);

レスポンスタイムや connection time などの指標も出してくれます。

まとめ

9年前と比較すると格段に使いやすくなっています。しかも無料で開始できるので監視サービスの導入のハードルが低いです。

また、豊富なテンプレがあるので監視エージェントを入れるだけでほとんど知りたいメトリックをきれいに表示してくれます。

少し前まで datadog を利用していましたが設定が複雑でセットアップやカスタムメトリックを使ってダッシュボードを構築するのに自由度が高い反面、いろいろな監視項目を自分で設定する必要があってかなり大変でした。 Mackerel はグラフがきれいでシンプルなのは良いですが、アプリケーションの監視や OS の主要なメトリックを監視するためにもプラグインを入れていかないといけないので面倒な印象です。NewRelic のほうがちょっと触った感じでは datadog 良さそうな感じがします。

個人サービスをやっていると、実運用しているサービスを使って導入検証のスクショをモザイク無しで掲載できるので皆様のお役に立てるような情報を提供できるかと思います。

今後

今後は、NewRelic のさらなる機能を試してみたいと考えています。具体的には以下の点を検討しています。

カスタムダッシュボードの作成: デフォルトのダッシュボードも非常に便利ですが、特定のニーズに合わせたカスタムダッシュボードを作成し、より詳細に監視したいと考えています。
アラート設定の最適化: 現在のアラート設定を見直し、より効果的なアラートを設定することで、問題の早期発見と対応を目指します。
他のサービスとの連携: NewRelic を他の監視ツールやサービスと連携させることで、より包括的な監視環境を構築したいと考えています。例えば、Slack や PagerDuty と連携させて、アラート通知を効率化することを検討しています。
パフォーマンスの最適化: 収集したデータを基に、サーバーやアプリケーションのパフォーマンスを最適化し、より効率的な運用を目指します。

これらの取り組みを通じて、NewRelic を活用した監視環境をさらに強化し、安定したサービス運用を実現していきたいと考えています。

会社での導入を検討

では法人でちゃんとしたサービスの監視に使えるかを少し考えてみます。気になるお値段はこちら

Free でも 1 ユーザだけなら機能は無制限に使えるようです。普通は、Standard 以上になるのかなと思います。実際のサービスごとによって転送するログの量は異なるのでなんとも言えませんがかなり絞れば課金されないくらいなのかなと思います。

session replay機能はすごい魅力的。トラブルシュートに時間を使うことが多いので。

余談

懐かしのスクリーンショット

9 年前である、2015 年に撮影した New Relic の管理画面がありました。

現在は別物ってくらいに UI がきれいになってますね。

New Relicの正式表記がわからない

オフィシャルサイトでも表記ゆれしていそう。どれが正しいのだろう。この記事では「New Relic」にしましたが。

new relic
NewRelic
New Relic
newrelic

無料の郵便番号検索APIのレスポンススピード比較

Wed, 11 Dec 2024 00:00:00 GMT

はじめに

ベンチマークと高速化が大好きな @matsubokkuriです。

郵便番号検索 API は、住所情報を取得する際に頻繁に利用される重要なツールです。本記事では、3 つの郵便番号検索 API のレスポンススピードを比較し、それぞれのパフォーマンスについて考察します。

計測概要

使用したツール

wrk: 高負荷テストツールを使用して、各 API のレスポンススピードを計測しました。

計測条件

テスト対象の URL：
- ポストくん API: https://postcode.teraren.com/postcodes/1600023.json
- ZipCloud API: https://zipcloud.ibsnet.co.jp/api/search?zipcode=1600023
- ttskch/jp-postal-code-api: https://jp-postal-code-api.ttskch.com/api/v1/1600023.json
テスト時間：10 秒
スレッド数：2
接続数：10

テスト内容

各 API に対して 10 秒間リクエストを送り、以下の指標を計測しました：

平均レイテンシー（1 リクエストの平均応答時間）
リクエスト数/秒（1 秒間に処理できたリクエスト数）
データ転送量/秒

計測結果

ポストくん API

Running 10s test @ https://postcode.teraren.com/postcodes/1600023.json
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    17.38ms    3.50ms  56.86ms   81.09%
    Req/Sec   287.60     22.71   343.00     79.00%
  5757 requests in 10.06s, 11.29MB read
Requests/sec:    572.01
Transfer/sec:      1.12MB

ZipCloud API

Running 10s test @ https://zipcloud.ibsnet.co.jp/api/search?zipcode=1600023
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   217.51ms   21.91ms 349.86ms   94.29%
    Req/Sec    22.67      8.09    40.00     78.01%
  455 requests in 10.10s, 101.51KB read
Non-2xx or 3xx responses: 404
Requests/sec:     45.07
Transfer/sec:     10.05KB

ttskch/jp-postal-code-api

❯ wrk 'https://jp-postal-code-api.ttskch.com/api/v1/1600023.json'
Running 10s test @ https://jp-postal-code-api.ttskch.com/api/v1/1600023.json
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    21.87ms   13.82ms 241.38ms   97.74%
    Req/Sec   239.94     24.27   272.00     87.00%
  4801 requests in 10.05s, 7.99MB read
Requests/sec:    477.52
Transfer/sec:    813.56KB

結果比較

指標	ポストくん API	ZipCloud API	ttskch/jp-postal-code-api
平均レイテンシー	17.38ms	217.51ms	21.87ms
リクエスト数/秒	572.01	45.07	477.52
データ転送量/秒	1.12MB	10.05KB	813.56KB
非2xx/3xxレスポンス数	0	404	0

考察

パフォーマンスの違い

計測結果から、ポストくん API が最も高速であることが分かります。ttskch/jp-postal-code-api は 2 番目に高いパフォーマンスを示し、ZipCloud API は最も遅い結果となりました。

平均レイテンシー: ポストくん API が最も短く、次いで ttskch/jp-postal-code-api、ZipCloud API の順です。ZipCloud API は他の 2 つの API と比較して約 10 倍以上のレイテンシーがあります。
リクエスト数/秒: ポストくん API が最も多く、ttskch/jp-postal-code-api がそれに続きます。ZipCloud API は他の 2 つの API と比較して著しく少ないリクエスト処理能力を示しています。
データ転送量/秒: ポストくん API が最も多く、次いで ttskch/jp-postal-code-api、ZipCloud API の順です。
エラーレスポンス: ポストくん API と ttskch/jp-postal-code-api は非 2xx/3xx レスポンスがなく、安定性が高いことが示されています。一方、ZipCloud API ではエラーが発生しており、信頼性に課題があることが示唆されます。

利用シナリオ別の選択肢

高速性と安定性が最優先の場合: ポストくん API が最適です。
高速性は重要だが、ポストくん APIほどの極限的なパフォーマンスが不要な場合: ttskch/jp-postal-code-api も良い選択肢となります。
低頻度のアクセスや簡易な利用の場合: ZipCloud API も検討可能ですが、エラー処理の実装が必要です。

アクセスブロックに関して

ポストくんでは Cloudflare の CDN によるキャッシングを行っており、不正アクセス対策も行われています。今回の 10 秒間で 6000 リクエスト近いリクエストを送っても不正判定はされませんでした。 ZipCloud では大量アクセスに対して、rate limit が早期に掛かる可能性があります。

結論

今回の計測では、ポストくん API が最も高いパフォーマンスを示し、ttskch/jp-postal-code-api がそれに続く結果となりました。両 API とも安定性も高く、高速性や信頼性を重視するアプリケーションに適しています。

特に、極限的な高速性が求められる場合はポストくん API が、それほどの極限的なパフォーマンスが不要な場合は ttskch/jp-postal-code-api も良い選択肢となるでしょう。ZipCloud API は、パフォーマンスと安定性の面で改善の余地があります。

API の選択に当たっては、これらのパフォーマンス指標に加えて、API の機能、利用制限、料金体系なども考慮に入れる必要があります。アプリケーションの要件に最も適した API を選択することが重要です。

港区スマイル商品券マップを開発しました

Thu, 17 Oct 2024 00:00:00 GMT

こんにちは！　今回は、港区のスマイル商品券を利用できる施設を簡単に検索・閲覧できる Google Maps ベースのウェブアプリケーションを開発した経験について共有したいと思います。

https://www.google.com/maps/d/viewer?hl=ja&mid=1m90xJYsL4bTpX2OZp0s1RZG-IL21qWg&ll=35.65534032072766%2C139.7510863216841&z=14

背景

港区では、地域経済の活性化を目的として「スマイル商品券」を発行しています。この商品券は区内の多くの店舗で使用可能ですが、利用可能な店舗を探すのが難しいという課題がありました[1]。

私自身、過去に商品券の使用期限が迫っているにもかかわらず、使える店舗がわからずに困った経験がありました。この経験から、他の区民の方々も同じような問題を抱えているのではないかと考え、このプロジェクトを始めることにしました。

開発のプロセス

1. データの収集と整理

まず、港区商店街連合会が公開しているPDFから利用可能店舗のデータを抽出しました。このデータには店舗名、住所、業種などの情報が含まれていました。

Google Maps 上に表示するためにはある程度規定のフォーマットでファイルを作って上げる必要があります。 1 つの Spreadsheet の 1 つ目のシートしか見てくれないのでメトリックごとに CSV ファイルを作って上げる必要があります。

また、カラム名が重要なのでカラム名をつけた状態で作ります。

今回は、通常券と限定券の 2 つのレジェンドに分割しました。

限定券 https://docs.google.com/spreadsheets/d/1HGXGR41bCx-thOIWZN_Njv-6RwZO5vo3jj7mCO4ONfo/edit?usp=drive_link

通常券 https://docs.google.com/spreadsheets/d/147fTCROTvHwnEksjmvi7EWAAVdv6GDkMa_sKx_UMSbQ/edit?usp=drive_link

2. Google Mapsの活用

次に、Google Maps JavaScript API を使用して、抽出したデータを地図上にプロットしました。 GoogleのMy Map機能には住所からGocodingしてくれる機能があるので住所から緯度経度情報を取得してプロットしてくれます。

3. 検索機能の実装

ユーザーが現在地から近い店舗を簡単に見つけられるよう、位置情報を利用した検索機能を実装しました。また、業種によるフィルタリング機能も追加し、飲食店のみを表示するなどの絞り込みを可能にしました。

4. 詳細情報の表示

各マーカーをクリックすると、店舗の詳細情報（店舗名、住所、電子商品券・紙商品券の利用可否など）がポップアップで表示されるようにしました。

成果と反響

完成したアプリケーションは、Xで公開したところ、多くの方々から好評をいただきました。特に、現在地からの店舗検索や業種別フィルタリング機能が便利だという声が多く聞かれました。

今後の改善点

データの自動更新: 現在は手動でデータを更新していますが、港区の公式サイトから自動的にデータを取得・更新する仕組みを構築したいと考えています。
ユーザーレビュー機能: 利用者が店舗の評価やコメントを投稿できる機能を追加することで、より有用な情報プラットフォームになると考えています。
モバイルアプリ化: 現在はウェブアプリケーションですが、将来的には iOS や Android のネイティブアプリとして開発することで、プッシュ通知などの機能を追加し、ユーザー体験を向上させたいと思います。

まとめ

このプロジェクトを通じて、オープンデータを活用することで地域の課題解決に貢献できることを実感しました。また、Google Maps のような既存のプラットフォームを利用することで、30 分で実用的なアプリケーションを開発できることも学びました。

今後も、このようなプロジェクトを通じて、技術で地域に貢献していきたいと考えています。皆さんも、身近な課題に目を向けて、技術で解決できることはないか、考えていきます。

類似サービス

https://note.com/mah_mah/n/n682235de0b46

ChatGPTと同様のUIを提供するOSSであるLibreChatを動かしてみた

Thu, 10 Oct 2024 00:00:00 GMT

3行サマリー

自社でゼロから LLM サービスの UI を運用するのは大変なので LibreChat を調査してみます。
LibreChat をエンタープライズ利用に使えそうかを検証してみました。
LibreChat + Ollama (Gemma2)を使ってプライベートな LLM サービスを作ってみました。

LibreChatの特徴

一言でいうと、ChatGPT の OSS バージョンです。

カスタマイズ性が高く、ユーザーは自分のニーズに合わせて機能やプラグインを追加できます。

ライセンス

MIT License なので商用利用可能です。

MIT Licenseの特徴

自由な使用: MIT License は、ソフトウェアを商業目的、個人使用、教育目的を問わず自由に利用できることを許可します。
改変と再配布: ユーザーはソフトウェアを改変し、その改変版を再配布できます。改変版の配布時には、元のライセンスを明示する必要があります。
著作権の保持: ソフトウェアの著作権は元の作者に残りますが、ライセンスの下で使用する権利を他のユーザーにも与えます。
責任の免除: MIT License には、ソフトウェアが提供される際の「現状有姿」での提供が明記されており、バグや問題に対して作者が責任を負わないことが明示されています。
シンプルで短い: ライセンス文が非常にシンプルで短く、理解しやすいため、広く採用されています。 </div>

ソフトウェアアーキテクチャ

コンポーネント

フロントエンド: ChatGPT に似たユーザーインタフェースを提供
バックエンド: 様々な AI モデルとの連携やデータ管理を担当
データベース: MongoDB を使用してチャット履歴などのデータを保存

デプロイメントを以下に簡単に図示します。

使用言語とフレームワーク

フロントエンド: TypeScript (React, Vite)
バックエンド: Node.js
データベース: MongoDB

デプロイメント

Docker サポート: コンテナ化されたデプロイメントが可能
クラウドデプロイメント: AWS EC2 などのクラウドプラットフォームでのホスティングが可能
ローカルデプロイメント: オフラインでの完全なローカル実行も可能

活発度

かなり活発です。 main ブランチに積極的にコミットされてます。安定性より機能の充実を優先しているように見えます。

リリースはまだ v0 系です。

セットアップ

使用感をチェックして見るために動かしてみます。

% git clone git@github.com:danny-avila/LibreChat.git
% cd LibreChat
% cp .env.example .env
% open 'http://localhost:3080/login'

ブラウザで開くと以下のような画面が表示されます。

すんなり動きました。

今回はソースコード自体をcloneしていますが、docker-compose.ymlファイルと.envファイルの設定だけで動きます。 docker-compose.ymlからはecrにおいてあるコンテナを取得しています。

ユースケースを試してみる

OpenAIをAPI経由で利用してみる

OpenAIへのAPI接続はLibraChat本体でサポートしているので .env ファイルにOpenAIのAPIキーを追加するだけで使えるようになります。

追加する箇所は170行目あたりです。

❯ diff .env.example .env
171c171
< OPENAI_API_KEY=user_provided
---
> OPENAI_API_KEY=sk-proj-xxxxxxxxxxxxxxxxxxxxxxx

画面の左上から利用するモデルを選んで、テキストを打ち込みます。以下の画像のような感じで動作します。UIはChatGPTと同様です。

左側のペインに、チャットの履歴、右側でLLMのパラメータ調整やプロンプトのスニペットを管理できます。

画像を生成してみる

デフォルトでは画像生成をサポートしていません。画像生成で有名どころのOpenAIのDall-Eを使って見たいと思います。

.envファイルで環境変数にAPIキーを設定します。OpenAI経由で使うのでOpenAIと同じキーを指定します。

❯ diff .env.example .env
236,238c236,238
< # DALLE_API_KEY=
< # DALLE3_API_KEY=
< # DALLE2_API_KEY=
---
>  DALLE_API_KEY=sk-proj-xxxxxxxxxxxxxxxxxxxxxxx
> # DALLE3_API_KEY=sk-proj-xxxxxxxxxxxxxxxxxxxxxxx
> # DALLE2_API_KEY=sk-proj-xxxxxxxxxxxxxxxxxxxxxxx

プラグインストアでDall−Eをインストールします。

上部から、Plugins を選択して、LLMを選択肢、DALL−Eをチェックして利用します。

上記で設定は終わりなので試してみましたが、残念ながらうまく生成してくれませんでした。おそらく、追加で設定が必要のようです。DALL-Eのプラグインの不具合のようです。

自分で立てたollamaを使ってみる

OpenAIといった外部サービスではなく自社で立ち上げているLLMサービスへ接続するケースがあると思うので試してみます。

ollamaはHTTP経由のAPIで利用します。

composeで一気に作りたいので以下を追加しました。

diff --git a/docker-compose.yml b/docker-compose.yml
index 55686abd..85f2c5dd 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -67,6 +67,16 @@ services:
       - vectordb
     env_file:
       - .env
+  ollama:
+    image: ollama/ollama
+    container_name: ollama
+    ports:
+      - "11434:11434"
+    volumes:
+      - ollama:/root/.ollama
+

 volumes:
   pgdata2:
+  ollama:

Gemma2の2Bモデルをダウンロードします。

% docker compose exec ollama ollama pull gemma2:2b

Ollama単体で動作テストをしてみます。

❯ docker compose exec ollama ollama run gemma2:2b
>>> 日本の最高峰は？
日本の最高峰は **富士山** です！ 🗻
 どんな情報に関心があるか教えていただければ、より詳細な情報を提供できますよ😊

CPUで動かしても即座に返ってきました。

LibreChatがデフォルトでサポートしていないLLMのサービスへ接続するためには、別途カスタムの設定を記述したYAMLファイルを作成して、LibreChatへパラメータとして指定します。

カスタムファイルのテンプレファイルをコピーします。

% cp ./librechat.example.yaml librechat.yaml

以下の設定を108行目辺りの custom セクションに追加します。

❯ diff librechat.example.yaml librechat.yaml
108a109,131
>     - name: "Ollama"
>       apiKey: "ollama"
>       baseURL: "http://ollama:11434/v1/chat/completions"
>       models:
>         default: [
>           "llama2",
>           "gemma2",
>           "mistral",
>           "codellama",
>           "dolphin-mixtral",
>           "mistral-openorca"
>           ]
>         # fetching list of models is supported but the name field must start
>         # with ollama (case-insensitive), as it does in this example.
>         fetch: true
>       titleConvo: true
>       titleModel: "current_model"
>       summarize: false
>       summaryModel: "current_model"
>       forcePrompt: false
>       modelDisplayLabel: "Ollama"

default セクションでモデル名を指定しています。fetch セクションで true を指定していれば、動的に ollama のサーバから取得するので気にしないで大丈夫です。利用するモデルを制限する場合に使うとよいです。

上部のメニューから Ollama を選択し、対応するモデルを選べば利用できました。

Dify をワークフローとして使うケースにも対応できるかなと思って調べてみたら、2024 年 5 月に同様の issue が立ってました。 https://github.com/danny-avila/LibreChat/discussions/2830

GoogleのOAuthで認証する

OAuth でログインする設定を簡単に行えます。

オフィシャルサイトの手順に従って Google 側で設定します。丁寧に解説されているのでマニュアル通りに実行すれば終わります。 https://www.librechat.ai/docs/configuration/authentication/OAuth2-OIDC/google

特につまずくこと無く、SSO できました。エンタープライズに導入する際にはとても楽です。

まとめ

高いカスタマイズ性とプライバシー保護を提供し、幅広い用途に使えそう。
簡単なセットアップ手順と豊富なプラグインサポートにより、個人利用から企業導入まで柔軟に対応できそう。
DALL-E が動かなかったので今後に期待。

類似サービス

Cocoon用Amazon短縮リンク生成Chrome拡張機能を作ってみた

Thu, 26 Sep 2024 00:00:00 GMT

3行まとめ

Cocoon テーマ用の Amazon アフィリエイトリンクを簡単に生成する Chrome 拡張機能を開発
ワンクリックで商品 ASIN とキーワードを含むショートコードを生成
除外キーワード機能で、不要な文字列を自動的に削除可能

https://github.com/matsubo/cocoon-amazon-shortcode

背景

WordPress の Cocoon テーマを使用している方々にとって、Amazon の商品リンクを記事に挿入するのは日常的な作業です。しかし、この作業は意外と手間がかかり、特に多くの商品リンクを扱う場合は生産性の低下につながります。

問題

従来の方法では、以下のような手順を踏む必要がありました：

Amazon 商品ページを開く
ASIN を確認
商品タイトルをコピー
WordPress の投稿画面に戻る
ショートコードを手動で入力

この過程は時間がかかるだけでなく、人為的ミスも発生しやすいです。

目的

この問題を解決するため、以下の目標を掲げて開発に取り組みました

ワンクリックで Amazon アフィリエイトリンクを生成する
Cocoon テーマの仕様に合わせたショートコードを自動生成する
不要なキーワードを自動的に除外する機能を実装する

アプローチ

1. Chrome拡張機能の開発

Chrome 拡張機能を開発することで、Amazon の商品ページ上で直接操作できるようにしました。これにより、ユーザーはタブの切り替えなしでリンクを生成できます。

2. ASINと商品タイトルの自動取得

JavaScript を使用して、商品ページから ASIN と商品タイトルを自動的に抽出するロジックを実装しました。これにより、手動でのコピー&ペーストの必要がなくなりました。

3. ショートコード生成ロジック

Cocoon テーマで使用される以下のフォーマットに従ってショートコードを生成します：

[amazon asin="<ASIN>" kw="<商品名>"]

このショートコードを Cocoon を利用している WordPress にそのまま貼り付けると以下のように展開されます。

4. 除外キーワード機能

ユーザーが指定した除外キーワードを商品タイトルから自動的に削除する機能を実装しました。これにより、「Amazon 限定」や「送料無料」などの不要な文字列を簡単に除去できます。

5. クリップボードへの自動コピー

生成されたショートコードは自動的にクリップボードにコピーされます。ユーザーは WordPress の投稿画面に戻って直接ペーストするだけで済みます。

まとめ

この Chrome 拡張機能を使用することで、Cocoon テーマを使用している WordPress ブロガーの作業効率が大幅に向上します。特に以下の点で有用です：

作業時間の短縮
人為的ミスの削減
一貫性のあるリンク生成

今後も、ユーザーフィードバックを基に機能を改善・拡張していく予定です。皆さんもぜひ試してみてください！

AIによる契約書の自動レビュー機能を作ってみた

Fri, 20 Sep 2024 00:00:00 GMT

3行まとめ

契約書のレビュー、契約書のバージョン管理を効率的に行いかた向け。
AI を活用した契約書レビューのワークフローを構築。
GitHub の Pull Request 機能を使ってレビューするので複数人でのレビューがしやすく議論の結果が残る。

概要

こんな感じで契約書をレビューしてくれます。

ソースコード（基本はこの 1 ファイルのみ）。 https://github.com/matsubo/legal-document/blob/main/.github/workflows/ai-pr-reviewer.yml

背景

社内の AI 技術勉強会にて、リーガルチェックに LLM を利用してみたときの事例を見ました。その際に、契約書の 1 次チェックを LLM を使って行うと一定数の時短効果があるという考察がありました。

悩んだポイントや使い方のノウハウが CoderabbitやPR-Agentを使ったLLMによるPull Request のレビューと似ていると思いまいした。

そこで、ソースコード管理のメタファをと契約書のレビューに適用してみようと考えました。

目的

AI によるソースコードレビューを行うのと同じように、AI による契約書のレビューをするワークフローを作ります。

アプローチ

契約書などの法務関連のドキュメントも基本的にはテキスト情報なのでソースコードと似ているので GitHub などのバージョン管理ツールを使ったワークフローに乗せてみる。

ワークフローのスコープ定義

印鑑を利用した契約書に関するユースケースを整理してみます。

ドラフトの作成
ドラフトの確認、修正
A が捺印
B が捺印
双方で保管

電子化されたとしても上記の捺印が電子捺印に変わるだけなので同様に考えられます。

今回は、契約締結ワークフローすべてを考えるとビジネス要件、法務要件などが絡んでくるので上野 2 つのドラフトの作成、確認、修正という点を LLM を使って処理できるようにしたいと思います。

ドキュメントのフォーマットの扱い

契約書は変更可能なドラフトの状態では docx, Google Docs で流通し、内容が合意できたあとは PDF で流通します。 docs や Google Docs の形式ではテキストエディタとの相性が悪いので Markdown に変換して扱います。

ワークフロー設計

契約書のドラフトを作成
Markdown に変換
pull request を作成
pull request 上に行ごと、全体に対してレビューコメントをいれる
満足が行くまで修正を繰り返す。
main ブランチに merge し PDF を生成

実装

今回は契約書のサンプルのために、Wor-Q の提供する契約書の雛形を利用させてもらいます。今回は単発の業務委託契約書のテンプレを使います。(ikkai-keiyaku-jyuninin.docx)

ファイルの変換

上記のサイトでは契約書の雛形は Word 形式(docx)で提供されているのでまずは扱いやすいように Markdown に変換します。ドキュメント形式のファイル変換には pandocを使うのが一般的です。

pandoc をゼロからインストールするのは面倒なので Docker image を探してきて利用します。

コマンド実行例

% docker run --rm \
             --volume "$(pwd):/data" \
             --user $(id -u):$(id -g) pandoc/core jtuc/ikkai-keiyaku-jyuninin.docx -o jtuc/ikkai-keiyaku-jyuninin.md

出力されたMarkdownのファイルはこちらになります。

**業務委託契約書**

○○（以下「委託者」という。）と△△（以下「受託者」という。）は、委託者が受託者に対し、□□を委託するにあたって、次のとおり業務委託契約（以下「本契約」という。）を締結する。

第１条（委託業務の内容）

委託者は、受託者に対し、以下の内容で業務を委託する（以下「本業務」という。）。

業務内容：

業務期間：

委託料：

第２条（支払方法）

委託者は、本業務の委託料を、　　年　月　日までに受託者の指定する銀行口座に振り込む方法により支払う。ただし、振込手数料は委託者の負担とする。

第３条（報告）

受託者は、本業務の完了後、速やかに委託者に対し、業務完了報告書を交付する。

２．委託者は、前項の業務完了報告書を受領した日の翌日から起算して５営業日以内に、その内容を確認した旨の通知しなければならない。

３．前項に基づく委託者から受託者への通知があったときに本業務は完了したものとし、前項の期限内に前項の通知が受託者に到達しない場合も同様とする。

第４条（秘密保持）

受託者は、委託者の承諾なくして、本契約に関連して委託者から秘密であることを明示して開示された営業上又は技術上の秘密情報（以下「秘密情報」という。）を、第三者に対して開示、漏洩してはならず、本契約の履行以外の目的で使用してはならない。ただし、以下のいずれかに該当する情報は秘密情報には含まれない。

（１）開示された時点において、既に公知であった情報

（２）開示された後に受託者の責任によらないで公知になった情報

（３）開示された時点において、受託者が既に了知していた情報

（４）正当な権限を有する第三者から、受託者が秘密保持義務を負うことなく適法に取得した情報

予期していた内容とは異なります。理想としては、第x条のところは見出し1でマークアップされて、第x項のところは見出し2でマークアップされてきてほしいですが、すべてがただのテキストとして出されてしまっています。

もし、元のdocxにWordの「見出し」を使ってマークアップされていたらMarkdownでも見出し情報が維持されるのではないかと思ってテンプレのdocxファイルに対して見出しをいくつか使ってマークアップして変換してみました。

その際の出力は以下のようになり、見出しとして出力されました。

# 第１条（委託業務の内容）

委託者は、受託者に対し、以下の内容で業務を委託する（以下「本業務」という。）。

業務内容：

業務期間：

委託料：

# 第２条（支払方法）

委託者は、本業務の委託料を、　　年　月　日までに受託者の指定する銀行口座に振り込む方法により支払う。ただし、振込手数料は委託者の負担とする。

# 第３条（報告）

受託者は、本業務の完了後、速やかに委託者に対し、業務完了報告書を交付する。

２．委託者は、前項の業務完了報告書を受領した日の翌日から起算して５営業日以内に、その内容を確認した旨の通知しなければならない。

３．前項に基づく委託者から受託者への通知があったときに本業務は完了したものとし、前項の期限内に前項の通知が受託者に到達しない場合も同様とする。

# 第４条（秘密保持）

手動でこのようなマークアップを行うのも手間なので自動でやってみます。以下のようなコードを書いて、LLMを利用してMarkdownファイルに見出し情報を付加してみました。

import sys
import os
from openai import OpenAI

client = OpenAI(
    # This is the default and can be omitted
    api_key=os.environ.get("OPENAI_API_KEY"),
)

def convert_markdown(input_file):
    # 入力ファイルを読み込む
    with open(input_file, 'r', encoding='utf-8') as file:
        content = file.read()

    # OpenAI APIにリクエストを送信
    response = chat_completion = client.chat.completions.create(
        messages=[
            {"role": "system", "content": "このファイルは契約書で法務文書です。タイトルや見出しをmarkdownで表現するようにフォーマットしてください。契約書のタイトルは見出し1，条項は見出し2を使うようにしてください。重要な文書なので文章の内容は変更しないでください。見出しやタイトルのマークアップだけを行ってください。また、見出しと同時に箇条書きに関しても可能ならばMarkdownで箇条書きにしてください。"},
            {"role": "user", "content": content}
        ],
        model="gpt-4o",
    )

    # 変換された内容を取得
    converted_content = response.choices[0].message.content

    # 出力ファイルに書き込む
    with open('out.md', 'w', encoding='utf-8') as file:
        file.write(converted_content)

if __name__ == "__main__":
    if len(sys.argv) != 2:
        print("使用方法: OPENAI_API_KEY=xxx python convert.py input_file.md")
        sys.exit(1)

    input_file = sys.argv[1]
    convert_markdown(input_file)
    print(f"{input_file} を変換し、結果を out.md に保存しました。")

以下のようなコマンドで実行すると、out.mdというファイルに出力されます。

OPENAI_API_KEY=sk-proj-xxxxx python3 convert.py jtuc/ikkai-keiyaku-jyuninin.md

vimdiff で差分を表示してみました。文章も変更されてしまっていますが、とりあえず今回はこれで進めます。

# 業務委託契約書

○○（以下「委託者」という。）と△△（以下「受託者」という。）は、委託者が受託者に対し、□□を委託するにあたって、次のとおり業務委託契約（以下「本契約」という。）を締結する。

## 第１条（委託業務の内容）

委託者は、受託者に対し、以下の内容で業務を委託する（以下「本業務」という。）。

- 業務内容：
- 業務期間：
- 委託料：

## 第２条（支払方法）

委託者は、本業務の委託料を、　　年　月　日までに受託者の指定する銀行口座に振り込む方法により支払う。ただし、振込手数料は委託者の負担とする。

## 第３条（報告）

受託者は、本業務の完了後、速やかに委託者に対し、業務完了報告書を交付する。

1. 委託者は、前項の業務完了報告書を受領した日の翌日から起算して５営業日以内に、その内容を確認した旨の通知しなければならない。
2. 前項に基づく委託者から受託者への通知があったときに本業務は完了したものとし、前項の期限内に前項の通知が受託者に到達しない場合も同様とする。

## 第４条（秘密保持）

受託者は、委託者の承諾なくして、本契約に関連して委託者から秘密であることを明示して開示された営業上又は技術上の秘密情報（以下「秘密情報」という。）を、第三者に対して開示、漏洩してはならず、本契約の履行以外の目的で使用してはならない。ただし、以下のいずれかに該当する情報は秘密情報には含まれない。

- 開示された時点において、既に公知であった情報
- 開示された後に受託者の責任によらないで公知になった情報
- 開示された時点において、受託者が既に了知していた情報
- 正当な権限を有する第三者から、受託者が秘密保持義務を負うことなく適法に取得した情報

## 第５条（再委託の禁止）

受託者は、あらかじめ書面により委託者の承諾を得た場合、又は、正当な理由がある場合を除き、本業務の全部又は一部を、第三者に再委託することができない。

1. 受託者は、前項の規定により第三者に再委託する場合も、本契約に規定する受託者の義務を免れず、かつ第三者に対しても本契約上の義務を遵守させる義務を負う。

## 第６条（権利義務の譲渡等の禁止）

委託者及び受託者は、あらかじめ書面により相手方の承諾を得なければ、本契約上の権利義務ならびに本契約上の地位を、第三者に譲渡、移転その他の方法により処分してはならない。

## 第７条（損害賠償）

本契約に違反し、相手方に損害を負わせた当事者は、本契約の委託料を上限として当該違反に起因して発生した損害を賠償しなければならない。

## 第８条（不可抗力）

委託者及び受託者は、天災地変、戦争、内乱、暴動、疫病、感染症の流行等、当事者の合理的支配を超える事由により、義務の履行の全部又は一部が妨げられる範囲において、本契約に基づく義務の履行を免除され、一切の責任を負わない。

## 第９条（解除）

委託者及び受託者は、相手方が本契約に違反したときは、相当の期間を定めた催告をし、催告期間が終了しても違反が是正されない場合、本契約を解除できる。

1. 委託者及び受託者は、相手方に次の各号いずれかに該当する事由が生じたときは、何らの催告を要することなく、直ちに本契約を解除することができる。
    - 本契約の違反が重大なとき
    - 破産手続開始、民事再生手続開始、会社更生手続開始の申立てがあったとき
    - 差押え、仮差押え等の強制執行、または公租公課の滞納処分を受けたとき
    - 支払停止、または支払い不能に陥ったとき、若しくは手形が不渡となったとき
2. 前二項の定めにより本契約が解除された場合でも、解除権を行使した当事者は損害賠償の請求を妨げられない。

## 第１０条（契約の中途終了の場合の報酬請求）

本契約が解除その他の事由により途中で終了したときは、委託者は受託者に対して、終了までになされた履行割合に応じた額の委託料を支払うものとする。

## 第１１条（反社会的勢力の排除）

委託者及び受託者は、現在、暴力団、暴力団員、暴力団準構成員、暴力団関係企業、総会屋、社会運動等標榜ゴロ、その他これに準ずる者（以下「反社会的勢力」という。）のいずれにも該当しないことを表明し、かつ将来にわたっても該当しないことを確約する。

1. 委託者及び受託者は、相手方が次の各号のいずれかに該当する場合、ただちに本契約を解除することができ、解除により相手方に損害が生じてもこれを賠償することを要しない。
    - 相手方または相手方の役員が反社会的勢力に該当すると認められるとき
    - 相手方の経営に反社会的勢力が実質的に関与していると認められるとき
    - 相手方が反社会的勢力を利用していると認められるとき
    - 相手方が反社会的勢力に対して資金等を提供し、または便宜を供与するなどの関与をしていると認められるとき
    - 相手方または相手方の役員もしくは相手方の経営に実質的に関与している者が反社会的勢力と社会的に非難されるべき関係を有しているとき
    - 自らまたは第三者を利用して、暴力的な要求行為、法的な責任を超えた不当な要求行為、脅迫的な言動、暴力および風説の流布・偽計・威力を用いた信用毀損・業務妨害その他これらに準ずる行為に及んだとき
2. 委託者及び受託者は、自己が前項各号に該当したため相手方が本契約を解除した場合、相手方に生じた損害を賠償しなければならない。

## 第１２条（存続条項）

第４条（秘密保持）、第６条（損害賠償）、第１２条（管轄）の規定は、本契約の終了後も有効に存続する。

## 第１３条（管轄）

本契約に関する一切の紛争は、○○地方裁判所を第一審の専属的合意管轄裁判所とする。

## 第１４条（協議事項）

本契約に定めのない事項、ならびに本契約の解釈について疑義を生じたときは、当事者間で誠実に協議のうえ解決する。

本契約の締結を証するため、本書を２通作成し、委託者及び受託者記名押印の上、それぞれ１通を保有する。

２０　　年　　月　　日

（委託者）

（受託者）⏎

Pull requestをレビューするコードの作成

Markdown形式の契約書を含むドキュメントがpull requestに上がってきたらレビューするワークフローを作ります。

ゼロから作るのは大変なので、ソースコードをレビューする既存のOSSを改良してみます。

ベースとしてai-pr-reviewerを使ってみます。今はpublic archiveになっています。運営元は有料の別サービスを開始してそちらに本腰を入れているみたいです。 https://github.com/coderabbitai/ai-pr-reviewer?tab=readme-ov-file

また、 PR-Agentも見てみましたが、ソースコードレビューに特化した機能が沢山入っていて取捨選択するのが大変なので、作りがシンプルなai-pr-reviewerを応用してみたいと思います。

応用といっても、LLMにわたすプロンプト自体がGitHub Actionsのワークフローにかかれているので変更するだけです。

permissions:
  contents: read
  pull-requests: write

on:
  pull_request:
  pull_request_review_comment:
    types: [created]
  workflow_dispatch:


concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  review:
    runs-on: ubuntu-latest
    if: (github.event_name == 'workflow_dispatch') || (github.event_name == 'pull_request' && !contains(github.event.pull_request.title, 'release'))
    timeout-minutes: 15
    steps:
      - uses: coderabbitai/openai-pr-reviewer@latest
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        with:
          debug: false
          review_simple_changes: false
          review_comment_lgtm: false
          openai_light_model: gpt-4
          openai_heavy_model: gpt-4
          openai_timeout_ms: 900000
          language: ja-JP
          path_filters: |
            !db/**
            !**/*.lock
          system_message: |
            あなたは @coderabbitai（別名 github-actions[bot]）で、OpenAIによって訓練された言語モデルです。
            あなたの目的は、非常に経験豊富な法務専門家として機能し、契約書を徹底的にレビューし、
            以下のようなキーエリアを改善するためのアドバイスを提供することです：
              - 法的リスク
              - 契約条件の明確さ
              - 法的遵守
              - 紛争解決条項
              - 守秘義務
              - 知的財産権
              - 責任の制限
              - 契約の終了条件

            些細な文法の問題や、スタイルの欠落についてはコメントしないでください。
            重要な問題を特定し、解決して全体的な契約書の品質を向上させることを目指してくださいが、細かい問題は意図的に無視してください。
          summarize: |
            次の内容でmarkdownフォーマットを使用して、最終的な回答を提供してください。

              - *ウォークスルー*: 特定の条項ではなく、全体の契約書に関する高レベルの要約を80語以内で。
              - *変更点*: 条項とその要約のテーブル。スペースを節約するために、同様の変更を持つ条項を1行にまとめることができます。

            GitHubのプルリクエストにコメントとして追加されるこの要約には、追加のコメントを避けてください。
          summarize_release_notes: |
            このプルリクエストのために、その目的と契約書のユーザーストーリーに焦点を当てて、markdownフォーマットで簡潔なサマリーを作成してください。
            変更は次のように分類し箇条書きにすること:
              "概要", "自社にとってのリスク", "契約相手にとってのリスク", "表記揺れ"
            例えば:, "Correction"
            ```
            - 概要: 守秘義務条項が追加されました
            ```            ⏎

実行

あとは、pull request を作れば自動的にレビューしてくれます。

全体に対するレビュー

以下のような指摘を上げてくれました。

概要: このプルリクエストでは、新たに業務委託契約書が追加されました。主な内容としては、業務の内容、支払方法、報告義務、秘密保持、再委託の禁止、権利義務の譲渡禁止、損害賠償、不可抗力、契約解除、反社会的勢力の排除等が含まれています。また、紛争解決のための管轄裁判所や協議事項についても規定されています。
自社にとってのリスク: 再委託の禁止や権利義務の譲渡禁止など、自社の柔軟性を制限する可能性があります。また、損害賠償条項により、特定の状況下での責任が増大する可能性があります。
契約相手にとってのリスク: 報告義務や秘密保持など、契約相手の負担を増やす可能性があります。また、契約解除条件が厳格である場合、契約相手が契約を終了する自由度が制限される可能性があります。
表記揺れ: なし

ウォークスルー: 新規に追加された業務委託契約書は、業務内容、支払方法、報告義務、秘密保持、再委託の禁止、権利義務の譲渡禁止、損害賠償、不可抗力、契約解除、反社会的勢力の排除などを含む全面的な条項をカバーしています。

変更提案してくれた箇所と視点を一覧にまとめてくれています。

個別に対するレビュー

行ごとに指摘を入れてくれるのでレビュー内容が見やすいです。議論が必要だったらそこで議論も進められるし履歴も残るので非常に見やすい UI です。

内容が抜けているところを指摘してくれています。テンプレなので当たり前ですが、本番ではチェックしてくれるべき内容なので素晴らしいです。

なんと、契約書テンプレのtypoを発見してくれてます。条項の番号参照がズレています。ファイルを変換する過程で入り込んだという可能性があるので差分を確認していったのですが、大元の docx ファイルに元から入っているミスです。

損害賠償の上限について設けるべきという提案をしてくれています。確かによく見る契約書では入っている気がします。

ソースコード

こちらにおいておきます。main ブランチを fork して API キーを設定すれば使えると思います。 https://github.com/matsubo/legal-document

今回のレビューの結果はこちらに置いておきます。 https://github.com/matsubo/legal-document/pull/1

考察

契約書を Markdown で管理する副次的な効果

差分が把握しやすい
時系列、ファイル同士の関係性が追いやすい。
プログラムで扱いやすい。

Markdown で不足している点は以下

テキスト情報の意味付けがちょっと貧弱なので XML や独自のマークアップ記法が必要になりそうです。
- タイトル、日付、契約主体、契約期間などはほとんど共通の事項なのでマークアップされていて欲しいです。

余談

契約締結業務を Git や GitHub を使って構築するのも可能かなと思いました。

Git によるソースコードのバージョン管理は、ブロックチェインの Proof of Works のモデルに似ているところがあります。
Git のリビジョンツリーに契約対象者それぞれがサインする対象の名前を書いてコミットすれば同意とみなしても良いなと思いました。
Git の分散リポジトリという点も契約書の双方保管という意図には良さそうです。用途が違うので耐改ざん性などの問題はありそうですが 9 割型の要素はそのまま使えそうな気がしました。

まとめ

AI による契約書内容のチェックを実装してみました。
プロンプトを改良したりすれば一定数業務でも使えるレベルかなと思いました。
法務担当の居ない会社や個人の方はアドバイザ的な役割ですぐに使っても良いレベルかなと思います。

LLMで難易度の高いゴールを達成するために：5つのデザインパターンで差をつける

Tue, 10 Sep 2024 00:00:00 GMT

概要

回答を得るのに複雑なステップが必要な場合、定石となるパターンが存在します。主に 5 つピックアップしましたので紹介します。

オブジェクト指向プログラミングで言う GoFのデザインパターンに近いものとして考えてもらえると有益さがわかると思います。

LLMデザインパターン

チェイン・オブ・ソート (Chain of Thought)

LLM を使用して問題を段階的に解決する手法です。LLM は中間的な思考過程を示すことができるため、問題解決の途中経過を可視化できます。例えば、数学の問題を解く際に、LLM が途中の計算ステップを示してくれることで、解答の過程を理解しやすくなります。

ステップバイステップ推論 (Step-by-Step Reasoning)

ステップバイステップ推論は、問題を小さなステップに分解し、各ステップごとに LLM の出力を得る手法です。例えば、複雑な論理パズルを解く際に、問題を小さな部分に分割し、 LLM が各ステップの解答を提供することで、全体の解答を導き出すことができます。

反復的精緻化 (Iterative Refinement)

初期の回答を基に、徐々に改善や詳細化を重ねていく手法です。 LLM が初期の回答を生成した後、その回答を元にさらなる情報を追加し、より正確な回答を得ることができます。例えば、文章の要約を生成する際に、LLM が初期の要約を提供し、その後、追加の文脈情報を与えることで、より適切な要約を作成できます。

タスク分解 (Task Decomposition)

複雑なタスクを小さなサブタスクに分解し、それぞれを個別に処理する手法です。LLM が各サブタスクの解答を提供することで、全体のタスクを効率的に解決できます。例えば、プログラミングの問題を解く際に、大きな問題を小さな関数に分割し、LLM が各関数の実装をサポートすることで、全体のプログラムを完成させることができます。

自己一貫性 (Self-Consistency)

複数の推論パスを生成し、最も一貫性のある結果を選択する手法です。LLM が複数の解答候補を生成し、それらの一貫性を評価することで、最も信頼性の高い解答を選び出すことができます。例えば、意思決定のサポートシステムにおいて、LLM が異なる選択肢に対する意見や理由を提供し、一貫性の高い結論を導くことができます。

思ったこと

デザインパターンは、その領域で問題解決を何回も繰り返していると見えてくる共通の事象をモデル化した物です。LLM のデザインパターンが明確にまとめられていませんが経験上この 5 つは良く使います。
デザインパターンを知っておくことで生成 LLM で自分の意図した結果が得られなかったときにどのように問題を解決するかといった知見を得られます。
今までは LLM を使った問題解決が不可能だと思われていた事象をデザインパターンによって問題解決の手法を考えられるようになった。

Contributions

壁打ち: Claude 3
挿絵: Napkin Al

AIで論文生成をするにはこんなふうに (AI Scientistの解説と実践)

Fri, 06 Sep 2024 00:00:00 GMT

3行サマリー

2024 年 8 月 13 日に論文をLLMで生成する記事が公開されました。
難易度の高いゴールを達成するための複雑な過程を LLM で扱うためのアプローチを紹介します。
AI Scientist のソースコードの重要部分を解説します。

背景

私の中で、論文の執筆というのは豊富な専門知識とアイデアが必要なのでLLMでの代替は困難かと思っていました。しかし、良く考えてみるれば、「アイデア＝既存の事象の組み合わせ」という提言もあるのでLLMでの代替は可能かなと思い始めました。

論文の定義

領域によって論文の定義が異なってくると思いますので、論文とはなにかを定義する必要があります。GPT-4 の回答の一部を引用すると以下です。

新しい知識や発見、理論を提案し、既存の知識に貢献することを目的としています。研究結果の報告、理論の検証、新しい視点の提案などが含まれます。

主に理系の学術論文では、新しさが含まれていることが重要のようです。

大学の研究室でもレビューされる際に「新規性は何なの？」というテーマで一番最初にディスカッションしたことを思い出します。

アプローチ

ではその新規性を作り出し、論文というアウトプットをどのように作るかというところです。

論文の執筆作業は単純でもありません。LLM に「機械学習の論文を書いて」といってもまともなものが出力されることは現時点では無いでしょう。

今回の論文執筆というタスクは複雑で難しい思いますが、そのような事象を LLM を使って複雑な事象を扱うアプローチがあります。

次に各アプローチと説明を紹介します。

チェイン・オブ・ソート (Chain of Thought)

ステップバイステップ推論 (Step-by-Step Reasoning)

ステップバイステップ推論は、問題を小さなステップに分解し、各ステップごとに LLM の出力を得る手法です。例えば、複雑な論理パズルを解く際に、問題を小さな部分に分割し、LLM が各ステップの解答を提供することで、全体の解答を導き出すことができます。

反復的精緻化 (Iterative Refinement)

初期の回答を基に、徐々に改善や詳細化を重ねていく手法です。LLM が初期の回答を生成した後、その回答を元にさらなる情報を追加し、より正確な回答を得ることができます。例えば、文章の要約を生成する際に、LLM が初期の要約を提供し、その後、追加の文脈情報を与えることで、より適切な要約を作成できます。

タスク分解 (Task Decomposition)

自己一貫性 (Self-Consistency)

上記のアプローチの詳細は以下の記事にまとめました。 </div>

https://zenn.dev/minedia/articles/llm-design-pattern

AI Scientistを動かしてみる

システムの設計を頭に入れたうえで、各実装について確認していきます。

AI Scientistの構成

AI Scientist の構成図を以下に引用します。

AI Scientist の中では、前述の 4 つのアプローチをすべて取り入れています。やはり、LLM によって複雑な事象を扱うためには必然的にそのようなアプローチを取ることになるのかと思います。

動作環境のセットアップ

実際に自分の学習のために動かしてみます。

基本的に詳細なセットアップの内容はオリジナルの readme にきちんと書かれているので、今回は私が実行したコマンドや設定を貼っておきます。

condaのセットアップ

condaが必要なのでセットアップしていない場合はセットアップします。色々聞かれますが、基本的にはデフォルトで大丈夫です。

wget https://repo.anaconda.com/archive/Anaconda3-2024.06-1-Linux-x86_64.sh
bash Anaconda3-2024.06-1-Linux-x86_64.sh

fishを使っているので、環境変数を読み込みます。

source /home/matsu/anaconda3/etc/profile.d/conda.csh

AI Scientistの準備

condaで環境を作成して、pipでインストールしていきます。

conda create -n ai_scientist python=3.11
conda activate ai_scientist
pip install anthropic aider-chat backoff openai
pip install matplotlib pypdf pymupdf4llm
sudo apt-get install texlive-full -y
pip install torch numpy transformers datasets tiktoken wandb tqdm

API Keyの準備

最低限動かすだけならOpenAIのAPIキーだけで良いので設定しておきます。

bash

export OPENAI_API_KEY="YOUR KEY HERE"

csh

set OPENAI_API_KEY "YOUR KEY HERE"

NanoGPTの準備

GPTに学習させてLLMを準備します。

python data/enwik8/prepare.py
python data/shakespeare_char/prepare.py
python data/text8/prepare.py

今回はワークフローの全体感を掴むのが目的なので liteバージョンで実行します。

実行するので以下の方法で行います。

cd templates/nanoGPT_lite && python experiment.py --out_dir run_0 && python plot.py

GPUが刺さっていない場合は、以下のようにCPUに変更して実行します。

❯ git diff
diff --git a/templates/nanoGPT/experiment.py b/templates/nanoGPT/experiment.py
index 303aebd..747755e 100644
--- a/templates/nanoGPT/experiment.py
+++ b/templates/nanoGPT/experiment.py
@@ -348,7 +348,7 @@ def train(dataset="shakespeare_char", out_dir="run_0", seed_offset=0):
     # DDP settings
     backend = "nccl"  # 'nccl', 'gloo', etc.
     # system
-    device = "cuda"  # Always use CUDA
+    device = "cpu"  # Always use CUDA
     dtype = (
         "bfloat16"
         if torch.cuda.is_available() and torch.cuda.is_bf16_supported()
diff --git a/templates/nanoGPT_lite/experiment.py b/templates/nanoGPT_lite/experiment.py
index 892ba72..f834b2f 100644
--- a/templates/nanoGPT_lite/experiment.py
+++ b/templates/nanoGPT_lite/experiment.py
@@ -348,7 +348,7 @@ def train(dataset="shakespeare_char", out_dir="run_0", seed_offset=0):
     # DDP settings
     backend = "nccl"  # 'nccl', 'gloo', etc.
     # system
-    device = "cuda"  # Always use CUDA
+    device = "cpu"  # Always use CUDA
     dtype = (
         "bfloat16"
         if torch.cuda.is_available() and torch.cuda.is_bf16_supported()

NPEETのインストール

git clone https://github.com/gregversteeg/NPEET.git
cd NPEET
pip install .
pip install scikit-learn

NPEET（Non-parametric Entropy Estimation Toolbox）は、連続変数と離散変数の両方に対するエントロピー、相互情報量、条件付き相互情報量の推定を行うPythonライブラリです。このツールは、Kullback-Leibler分散や混合変数間の相互情報量の推定もサポートしています。

8年前ぐらいに作られたライブラリです。pipで入らないのでcloneしてインストールします。

2D Diffusionの設定

cd templates/2d_diffusion && python experiment.py --out_dir run_0 && python plot.py

Grokkingのセットアップ

cd templates/grokking && python experiment.py --out_dir run_0 && python plot.py

プログラムの実行

最低限の準備は上記でOKです。必要な引数を設定して実行します。

python launch_scientist.py --model "gpt-4o-2024-05-13" --experiment nanoGPT_lite --num-ideas 1

これで、しばらく放置する感じです。

実行を以下に掲載しておきますが、多分24時間ぐらい動かしておいてエラーで止まりました。最終的な論文は出力されませんでした。

一旦、今回の記事スコープでは深追いしないでおきます。

実行出力:

❯ OPENAI_API_KEY='sk-pro-xxxxxxx' python launch_scientist.py --model "gpt-4o-2024-05-13" --experiment nanoGPT_lite --num-ideas 1
Using GPUs: []
Using OpenAI API with model gpt-4o-2024-05-13.

Generating idea 1/1
Iteration 1/3
{'Name': 'adaptive_embeddings', 'Title': 'Adaptive Embeddings: Context-Aware Token Representations for Enhanced Language Modeling', 'Experiment': 'Implement a mechanism to periodically update token embeddings based on attention weights. Modify the forward method of the GPT model to include a step where token embeddings are adjusted based on the attention weights from the transformer layers. Experiment with different update frequencies and evaluate the performance improvement compared to static embeddings.', 'Interestingness': 8, 'Feasibility': 5, 'Novelty': 7}
Iteration 2/3

{'Name': 'adaptive_embeddings', 'Title': 'Adaptive Embeddings: Context-Aware Token Representations for Enhanced Language Modeling', 'Experiment': 'Implement a mechanism to periodically update token embeddings using a weighted sum of the current embedding and the attention-weighted context vector. Modify the forward method of the GPT model to include this update step. Experiment with different update frequencies, such as after each epoch or every few epochs, to balance computational efficiency and performance. Evaluate the performance improvement compared to static embeddings using validation los
s and generation quality metrics.', 'Interestingness': 8, 'Feasibility': 6, 'Novelty': 7}
Iteration 3/3
{'Name': 'adaptive_embeddings', 'Title': 'Adaptive Embeddings: Context-Aware Token Representations for Enhanced Language Modeling', 'Experiment': 'Implement a mechanism to periodically update token embeddings using a weighted sum of the current embedding and the attention-weighted context vector. Modify the forward method of the GPT model to include this update step. Experiment with different update frequencies, such as after each epoch or every few epochs, to balance computational efficiency and performance. Evaluate the performance improvement compared to static embeddings using validation los
s and generation quality metrics.', 'Interestingness': 8, 'Feasibility': 6, 'Novelty': 7}
Idea generation converged after 3 iterations.

Checking novelty of idea 0: adaptive_block_size
Response Status Code: 429
Response Content: {"message": "Too Many Requests. Please wait and try again or apply for a key for higher rate limits. https://www.semanticscholar.org/product/api#api-key-form", "code": "429"}
Backing off 0.3 seconds after 1 tries calling function search_for_papers at 08:45:59
Response Status Code: 200
Response Content: {"total": 5042, "offset": 0, "next": 10, "data": [{"paperId": "0e3ddf94053d06b40283f4250e37582bdcea0e9e", "title": "BlockLLM: Multi-tenant Finer-grained Serving for Large Language Models", "abstract": "The growing demand for Large Language Models (LLMs) across diverse applications has prompted a paradigm shift in the design of deep learning serving systems. Deploying LLMs, especially in multi-tenant environments, presents considerable challenges due to their high computational and memory demands
Response Status Code: 429
Response Content: {"message": "Too Many Requests. Please wait and try again or apply for a key for higher rate limits. https://www.semanticscholar.org/product/api#api-key-form", "code": "429"}
Backing off 0.2 seconds after 1 tries calling function search_for_papers at 08:46:12
Response Status Code: 200
Response Content: {"total": 429, "offset": 0, "next": 10, "data": [{"paperId": "36daf0578aad5d3180d531cccbd32d65d62c8317", "title": "Extending Context Window in Large Language Models with Segmented Base Adjustment for Rotary Position Embeddings", "abstract": "In the realm of large language models (LLMs), extending the context window for long text processing is crucial for enhancing performance. This paper introduces SBA-RoPE (Segmented Base Adjustment for Rotary Position Embeddings), a novel approach designed to
Decision made: novel after round 2

Checking novelty of idea 1: layerwise_learning_rates
Response Status Code: 429
Response Content: {"message": "Too Many Requests. Please wait and try again or apply for a key for higher rate limits. https://www.semanticscholar.org/product/api#api-key-form", "code": "429"}
Backing off 0.6 seconds after 1 tries calling function search_for_papers at 08:46:21
Response Status Code: 429
Response Content: {"message": "Too Many Requests. Please wait and try again or apply for a key for higher rate limits. https://www.semanticscholar.org/product/api#api-key-form", "code": "429"}
Backing off 2.0 seconds after 2 tries calling function search_for_papers at 08:46:22


Response Status Code: 200
Response Content: {"total": 16299, "offset": 0, "next": 10, "data": [{"paperId": "3fa7f7565e815d8a5649441e4d1ba7db91e63ea0", "title": "Layer-wise Pruning and Auto-tuning of Layer-wise Learning Rates in Fine-tuning of Deep Networks", "abstract": "Existing fine-tuning methods use a single learning rate over all layers. In this paper, first, we discuss that trends of layer-wise weight variations by fine-tuning using a single learning rate do not match the well-known notion that lower-level layers extract general fea
Response Status Code: 429
Response Content: {"message": "Too Many Requests. Please wait and try again or apply for a key for higher rate limits. https://www.semanticscholar.org/product/api#api-key-form", "code": "429"}
Backing off 0.4 seconds after 1 tries calling function search_for_papers at 08:46:32
Response Status Code: 200
Response Content: {"total": 817, "offset": 0, "next": 10, "data": [{"paperId": "fc4bb7f1bac92053bbd64850d1c6faf13c4cef88", "title": "Improving Knowledge Distillation in Transfer Learning with Layer-wise Learning Rates", "abstract": "Transfer learning methods start performing poorly when the complexity of the learning task is increased. Most of these methods calculate the cumulative differences of all the matched features and then use them to back-propagate that loss through all the layers. Contrary to these metho
Response Status Code: 200
Response Content: {"total": 8738, "offset": 0, "next": 10, "data": [{"paperId": "3fa7f7565e815d8a5649441e4d1ba7db91e63ea0", "title": "Layer-wise Pruning and Auto-tuning of Layer-wise Learning Rates in Fine-tuning of Deep Networks", "abstract": "Existing fine-tuning methods use a single learning rate over all layers. In this paper, first, we discuss that trends of layer-wise weight variations by fine-tuning using a single learning rate do not match the well-known notion that lower-level layers extract general feat
Decision made: novel after round 3

Checking novelty of idea 2: adaptive_embeddings
Response Status Code: 429
Response Content: {"message": "Too Many Requests. Please wait and try again or apply for a key for higher rate limits. https://www.semanticscholar.org/product/api#api-key-form", "code": "429"}
Backing off 0.6 seconds after 1 tries calling function search_for_papers at 08:46:53
Response Status Code: 429
Response Content: {"message": "Too Many Requests. Please wait and try again or apply for a key for higher rate limits. https://www.semanticscholar.org/product/api#api-key-form", "code": "429"}
Backing off 1.6 seconds after 2 tries calling function search_for_papers at 08:46:54
Response Status Code: 500
Response Content: {"message": "Internal Server Error"}

Backing off 3.9 seconds after 3 tries calling function search_for_papers at 08:46:58
Response Status Code: 200
Response Content: {"total": 2338, "offset": 0, "next": 10, "data": [{"paperId": "f8b901c330e7f946ef93453b24682f294b8764a1", "title": "In-domain Context-aware Token Embeddings Improve Biomedical Named Entity Recognition", "abstract": "Rapidly expanding volume of publications in the biomedical doma
in makes it increasingly difficult for a timely evaluation of the latest literature. That, along with a push for automated evaluation of clinical reports, present opportunities for effective natural language processing me
Response Status Code: 429
Response Content: {"message": "Too Many Requests. Please wait and try again or apply for a key for higher rate limits. https://www.semanticscholar.org/product/api#api-key-form", "code": "429"}
Backing off 0.3 seconds after 1 tries calling function search_for_papers at 08:47:16
Response Status Code: 429
Response Content: {"message": "Too Many Requests. Please wait and try again or apply for a key for higher rate limits. https://www.semanticscholar.org/product/api#api-key-form", "code": "429"}
Backing off 0.6 seconds after 2 tries calling function search_for_papers at 08:47:16
Response Status Code: 200
Response Content: {"total": 145, "offset": 0, "next": 10, "data": [{"paperId": "ea6982a936a2b263bbf46ff6eb27fc0b63fddaf7", "title": "VL-GPT: A Generative Pre-trained Transformer for Vision and Language Understanding and Generation", "abstract": "In this work, we introduce Vision-Language Generative Pre-trained Transformer (VL-GPT), a transformer model proficient at concurrently perceiving and generating visual and linguistic data. VL-GPT achieves a unified pre-training approach for both image and text modalities
Response Status Code: 429
Response Content: {"message": "Too Many Requests. Please wait and try again or apply for a key for higher rate limits. https://www.semanticscholar.org/product/api#api-key-form", "code": "429"}
Backing off 0.1 seconds after 1 tries calling function search_for_papers at 08:47:28
Response Status Code: 429
Response Content: {"message": "Too Many Requests. Please wait and try again or apply for a key for higher rate limits. https://www.semanticscholar.org/product/api#api-key-form", "code": "429"}
Backing off 1.3 seconds after 2 tries calling function search_for_papers at 08:47:29
Response Status Code: 429
Response Content: {"message": "Too Many Requests. Please wait and try again or apply for a key for higher rate limits. https://www.semanticscholar.org/product/api#api-key-form", "code": "429"}
Backing off 1.7 seconds after 3 tries calling function search_for_papers at 08:47:30
Response Status Code: 200
Response Content: {"total": 14379, "offset": 0, "next": 10, "data": [{"paperId": "c7a3f9cc61cfafdc307f8ae24430b6b1121f9b2c", "title": "ToolkenGPT: Augmenting Frozen Language Models with Massive Tools via Tool Embeddings", "abstract": "Augmenting large language models (LLMs) with external tools has emerged as a promising approach to solving complex problems. However, traditional methods, which finetune LLMs with tool demonstration data, can be both costly and restricted to a predefined set of tools. Recent in-cont
Response Status Code: 429
Response Content: {"message": "Too Many Requests. Please wait and try again or apply for a key for higher rate limits. https://www.semanticscholar.org/product/api#api-key-form", "code": "429"}
Backing off 0.0 seconds after 1 tries calling function search_for_papers at 08:47:41
Response Status Code: 429
Response Content: {"message": "Too Many Requests. Please wait and try again or apply for a key for higher rate limits. https://www.semanticscholar.org/product/api#api-key-form", "code": "429"}
Backing off 0.5 seconds after 2 tries calling function search_for_papers at 08:47:41
Response Status Code: 200
Response Content: {"total": 213, "offset": 0, "next": 10, "data": [{"paperId": "ec68079f15b620a8a7ad19b3477f895e2ecf193d", "title": "HeatViT: Hardware-Efficient Adaptive Token Pruning for Vision Transformers", "abstract": "While vision transformers (ViTs) have continuously achieved new milestones in the field of computer vision, their sophisticated network architectures with high computation and memory costs have impeded their deployment on resource-limited edge devices. In this paper, we propose a hardware-effic
Decision made: novel after round 4
Processing idea: adaptive_block_size
Failed to evaluate idea adaptive_block_size: [Errno 2] No such file or directory: 'templates/nanoGPT_lite/run_0/final_info.json'
Processing idea: layerwise_learning_rates
Failed to evaluate idea layerwise_learning_rates: [Errno 2] No such file or directory: 'templates/nanoGPT_lite/run_0/final_info.json'
Processing idea: adaptive_embeddings
Failed to evaluate idea adaptive_embeddings: [Errno 2] No such file or directory: 'templates/nanoGPT_lite/run_0/final_info.json'
All ideas evaluated.

アイデアは生成されていたのでこちらに転記しておきます。 https://gist.github.com/matsubo/c4aaf9ccecf431bf1dc8a046f7184940

[
  {
    "Name": "adaptive_block_size",
    "Title": "Adaptive Block Size: Dynamic Context Window Adjustment for Efficient Training",
    "Experiment": "Modify the model to dynamically adjust its block size during training, starting with a smaller block size and gradually increasing it. This could potentially lead to faster initial training and better long-range dependency learning.",
    "Interestingness": 6,
    "Feasibility": 4,
    "Novelty": 4,
    "novel": true
  },
  {
    "Name": "layerwise_learning_rates",
    "Title": "Layer-wise Learning Rate Adaptation: Optimizing Training Dynamics in Transformer Models",
    "Experiment": "Implement layer-wise learning rates, where each transformer layer has its own learning rate. Modify the configure_optimizers function to assign different learning rates to different layers, with deeper layers having lower learning rates. Compare the training dynamics, convergence speed, and final performance with the baseline model.",
    "Interestingness": 4,
    "Feasibility": 6,
    "Novelty": 2,
    "novel": true
  },
  {
    "Name": "curriculum_learning",
    "Title": "Curriculum Learning: Incremental Difficulty for Efficient Language Model Training",
    "Experiment": "Implement curriculum learning by starting with shorter sequences and gradually increasing the sequence length during training. Modify the get_batch function to adjust the block_size based on the iteration number. For instance, start with block_size=64 and double it every 1000 iterations until the maximum block_size is reached. Compare the training dynamics, convergence speed, and final performance with the baseline model.",
    "Interestingness": 7,
    "Feasibility": 6,
    "Novelty": 5,
    "novel": false
  }
]

novel というキーの部分が新規性があるかどうかという判断結果の値です。

コード解説

3ステップあるので各ステップ分けて重要なコードを紹介します。

アイデア生成

なにはともあれ一番最初にLLMに指示するためのプロンプトが記載されているコードがこちらです。

https://github.com/SakanaAI/AI-Scientist/blob/2c41a92902cc40669059283a18d5923ff03fc8b2/ai_scientist/generate_ideas.py#L311-L326

You are an ambitious AI PhD student who is looking to publish a paper that will contribute significantly to the field.
You have an idea and you want to check if it is novel or not. I.e., not overlapping significantly with existing literature or already well explored.
Be a harsh critic for novelty, ensure there is a sufficient contribution in the idea for a new conference or workshop paper.
You will be given access to the Semantic Scholar API, which you may use to survey the literature and find relevant papers to help you make your decision.
The top 10 results for any search query will be presented to you with the abstracts.

You will be given {num_rounds} to decide on the paper, but you do not need to use them all.
At any round, you may exit early and decide on the novelty of the idea.
Decide a paper idea is novel if after sufficient searching, you have not found a paper that significantly overlaps with your idea.
Decide a paper idea is not novel, if you have found a paper that significantly overlaps with your idea.

{task_description}
<experiment.py>
{code}
</experiment.py>

長いので機械翻訳した日本語を掲載しておきます。

あなたは、分野に大きく貢献する論文を発表したいと考えている野心的なAI博士課程の学生です。 あるアイデアがあり、それが新規性があるかどうか、すなわち既存の文献と大きく重複していないか、あるいはすでに十分に探究されていないかを確認したいと考えています。 新しい会議やワークショップの論文として十分な貢献があるかを確認するため、新規性について厳しく評価してください。

Semantic Scholar APIへのアクセスが与えられており、関連する文献を調査し、意思決定の支援を得ることができます。 検索クエリごとに上位10件の結果とその要旨が表示されます。

決定には{num_rounds}回のラウンドが与えられていますが、すべてを使用する必要はありません。 どのラウンドでも早めに終了して、アイデアの新規性について判断することができます。 十分な検索を行った後、あなたのアイデアと大きく重複する論文が見つからなければ、そのアイデアを新規であると判断してください。 逆に、アイデアと大きく重複する論文が見つかった場合、そのアイデアは新規でないと判断してください。

開始はここから。 https://github.com/SakanaAI/AI-Scientist/tree/2c41a92902cc40669059283a18d5923ff03fc8b2/launch_scientist.py#L139-L149

ideas = check_idea_novelty(ideas) にてそのアイデアの新規性をチェックしてます。 https://github.com/SakanaAI/AI-Scientist/blob/2c41a92902cc40669059283a18d5923ff03fc8b2/launch_scientist.py#L376-L381

success = do_idea(idea) で各ideaを処理しています。 https://github.com/SakanaAI/AI-Scientist/blob/2c41a92902cc40669059283a18d5923ff03fc8b2/launch_scientist.py#L428-L437

do_idea の中身を見ていきます。

perform_experiments(idea) で実験する https://github.com/SakanaAI/AI-Scientist/blob/2c41a92902cc40669059283a18d5923ff03fc8b2/launch_scientist.py#L201-L206

論文生成

perform_writeup(idea) で論文を作成 https://github.com/SakanaAI/AI-Scientist/blob/2c41a92902cc40669059283a18d5923ff03fc8b2/launch_scientist.py#L232-L236

論文のアブストラクト（概要）を生成 https://github.com/SakanaAI/AI-Scientist/blob/2c41a92902cc40669059283a18d5923ff03fc8b2/ai_scientist/perform_writeup.py#L404-L414

論文の各章をLLMに生成させる。 https://github.com/SakanaAI/AI-Scientist/blob/2c41a92902cc40669059283a18d5923ff03fc8b2/ai_scientist/perform_writeup.py#L421-L447

perform_review(paper_text) で査読 https://github.com/SakanaAI/AI-Scientist/blob/2c41a92902cc40669059283a18d5923ff03fc8b2/launch_scientist.py#L245-L261

論文をレビューする際に人間が考えていることをしっかりと言語化してどのような観点でレビューするのかをプロンプトに設定しています。

https://github.com/SakanaAI/AI-Scientist/blob/2c41a92902cc40669059283a18d5923ff03fc8b2/ai_scientist/perform_review.py#L38-L62

レビューで指摘した内容を用いて改善します。 https://github.com/SakanaAI/AI-Scientist/blob/2c41a92902cc40669059283a18d5923ff03fc8b2/launch_scientist.py#L263-L288

考察

複雑なワークフローもブレークダウンして適切なアプローチを踏むことでLLMでは解決不可能と思われていたことも実現可能になりそうです。
論文を生成する際のフレームワークとかライブラリかと思いましたが、LLM 領域の論文を生成するアプリケーションという位置付けでした。
ある程度モジュールに分けられていたのでソースコードが読みやすかったです。

個人的に思ったこと

様々なプロンプトのテクニックが駆使されているのでとても勉強になりました。
「AI ではまだ不可能」と考えていた事象が、「このように作ればできそう」という考えができるようになりました。
自分のやってほしいタスクを正確に LLM へ伝達するスキルが重要になると思いました。具体的には、テクニカルライティングスキルとプロンプトの手法です。
LLM を高校生、大学生の思考力、格段に高い外部記容量を備えている人として捉えると、その人に対して丁寧に何をすればよいか説明することに作業がにてます。新人教育と同じ感じです。
今回は Python で書かれたソースコードですが、同様の事を Dify で作れると思います。

Web魚拓: 「研究」と「勉強」の違い

Tue, 27 Aug 2024 00:00:00 GMT

概要

過去に何度も参照している以下のページが消えてしまいそうな感じがするので魚拓として保管しておきます。

https://web.sfc.keio.ac.jp/~iba/sb/log/eid75.html

本文

タイトル: 「研究」と「勉強」の違い

2008.07.25 Friday 23:50 | posted by 井庭崇

研究会の新規履修者の面接をした。SFCでは、学部１年生から研究会に所属し、研究に従事できるので、１年生や２年生も新規希望者としてやって来る。

井庭研の面接は、担当教員の僕が一人で行うのではなく、研究会の現役メンバーを数人交えて行う。というのは、研究会というのは一種の「生き物」であって、もはや僕だけのものではないという思いがあるからだ。僕との相性のみならず、研究会メンバーとの関係もかなり重要なのだ。面接では、新規希望者一人につき、３０分の時間をかけて、取り組みたい研究テーマや、興味・関心分野について話をきいていく。

その研究会面接で、僕が必ず言う話がある。それは、「研究」と「勉強」の違いについての話だ。面接で、研究テーマをきいてみると、「～を勉強したい」と答える人が多くいる。こう答えるというのは、「研究」と「勉強」の違いがよくわかっていない証拠だ。研究テーマについて話しているのではなく、これから知りたいことを挙げているに過ぎない。そこで、僕は面接時に、「研究」と「勉強」はどう違うのか、ということを説明する。

まず、「知のフロンティア」があるとしよう。こちら側には、人類が現在知ってる「既知」の領域が、そして向こう側には、人類がまだ知らない「未知」の領域が広がっている。これから研究を始めるとき、当然、僕らはフロンティアに立っているわけもなく、そこから遠いところにいるだろう。そして、少しずつ知識をつけて前に進んでいく。そしてあるとき、フロンティア・ラインの一地点に到達するだろう。このようにして、既知の領域を進んでいくことを「勉強」という。不勉強でビハインドだった自分が、授業や本、人の話などから知識を得て、いまどこがフロンティアなのかがわかるようになる。これが「勉強」をするということだ。

これに対し、「研究」というのは、まったく異なるアクティビティだ。研究とは、フロンティアからさらに一歩前へ進み、既知の領域を広げるということ。もちろん、道なき道を開拓しながら進んでいくことになるので、それはとてもしんどい作業であり、一朝一夕にできるものではない。さて、ここで重要なのは、かならずフロンティアを開拓しなければならないということだ。すでに開拓されているところで、新たに開拓したとしても、それは「車輪の再発明」であり、研究にはならない。SFCカリキュラムの言葉に照らして言うと、「研究＝先端×創造」なのであり、「研究とは、先端領域で創造すること」なのだ。「研究」には「勉強」が不可欠だが、いくら「勉強」をしても「研究」にはならない。この「研究」と「勉強」の違いを意識することが、研究テーマを考える上でとても重要なのだ。

この「研究」と「勉強」の違いという話は、実は、僕がまだ学部生だったころ、竹中平蔵先生が研究会でよく語っていた話だ。この話は、「研究」と「勉強」の違いを非常にクリアに言い表していると思う。そんなわけで、僕は毎年、この話を面接のときに繰り返し話す。

研究会は「研究」のための場であるから、研究テーマをもった人たちの集まりだといえる。なので、研究会面接で熱く語ってほしいのは、勉強テーマではなく、研究テーマについてなのだ。荒削りでもいい。「研究」へと向かう志向性がほしい。そして、できるかできないか、という現実性よりも、何をやりたいのかというヴィジョンがほしい。

以前紹介した『音楽を「考える」』（茂木健一郎, 江村哲二, ちくまプリマー新書, 2007）のなかで、茂木さんと江村さんが、次のように語っている。まさにそのとおりだと思う。

(茂木)「若いときには自分の使える技法やツールと、胸に抱いている大志、夢見ている世界との間には明らかに大きすぎるギャップがある。それくらいアンバランスなやつじゃないと、表現者としては大成しないんだということが経験でわかりました。これはほとんど例外がない。」(p.47)

(江村)「結局は、自分に何ができるかじゃなくて、何がしたいかなんです。何ができるかなんて言いはじめたら、何もできなくなっちゃう。まずはそんなことはどうでもよくて、ただただ自分は何がしたいと思っているのか、という問題に尽きます。」(p.48)

面接で僕らが見ることに、自分の研究・活動をドライブするような内発性をもっているか、ということがある。なかなかそれを感じさせてくれる人がいないのが現状であるが。。。同僚の土屋さんは、研究テーマには「愛」か「憎しみ」がなければならない、という。研究へと自らを突き動かす「情熱」が必要なのだ。そうでなければ、しんどい研究作業など続けられるわけがない。

繰り返し言うけれども、荒削りでもいいので、自分なりの研究テーマの糸口をもっていてほしい。そして、自分をドライブする内発性をもっていてほしい。それが、研究を志すみんなへの本質的なメッセージだ。

「研究」と「学び」について | - | -

タブレット端末を壁掛けして情報端末として使うといろいろ捗る

Tue, 27 Aug 2024 00:00:00 GMT

概要

半年ぐらい前から、壁にタブレット端末があると便利だなと思ってました。

カーナビもAndroidベースの端末をかれこれ2年以上使っていて不自由はしていません。

完成図

こんな感じ。

天気を表示したりしてます。

設定で常時画面をONにしています。安い端末なので、自動光量調整ができないです。MacroDroidを使って夜に暗く、朝に明るくする設定をしています。

最近は、ベビーベッドの監視のためにカメラの内容をストリームしています。キッチンからベビーベッドを確認できるので楽です。

赤外線ライト付きなので暗くても良く見えます。

Androidにログインするアカウントは、普段のアカウントとは別途作成しました。常時ログインしっぱなしなので。

端末をゲストアカウントで運用するとなると、毎回データが消えてしまうので使いづらいと思います。

買ったもの

Androidの適当な安いやつを買いました。

安すぎると動作が遅くてストレスが溜まるし、高いと使用頻度が少なくもったいないため、ちょうどよい具合のものを見つけるのに時間がかかりました。

こちらの商品は、多少UIがもっさりしていますが使用頻度が少ないので我慢できます。

::amazon{asin="B0CXDS73QJ"}

CHUWI製品は安いのにそこそこ良いクオリティなのでお気に入りです。一昔前のHuaweiという感じです。日本ではHuaweiが売られなくなったのでCHUWIは助かります。

施工

電源ケーブルが「たら〜ん」としているとカッコ悪いので壁から電源を引っ張ってきます。

壁に穴を開けて、近くのコンセントから電源を引っ張ってきます。（要資格）

壁の中にコンセントを取り付けて、USBアダプタを取り付け、ケーブルを出します。空いた穴には、切り取った石膏ボードを戻しておきます。

タブレットの裏に少し隙間があるのでそこからケーブルを脇に持ってきます。

上下のホルダーは、100円均一で昔に買ってポストカードスタンドだと思います。

まとめ

施工は面倒でしたが、やってよかったです。
レシピの表示、天気、カレンダーの予定の確認に重宝しています。

寝室のライトを「とったらリモコン」に変更して快適子育て生活

Thu, 15 Aug 2024 00:00:00 GMT

概要

リビングの調光スイッチを「とったらリモコン」に変更しました。
乳児の子育て部屋には最適。もっと早くやっておけばよかった。

::amazon{asin="B07T844JQ6"}

施工後の写真

施工時間はスイッチパネルの入れ替えだけなので5分で終わりました。（要国家資格）

良い点、悪い点

良い点

床に布団を敷いて生活しているのでライトをコントロールするのに立ち上がるのが大変だったが、リモコンでオンオフ、調光ができると非常に楽になった。
壁のスイッチ側でも、クリックでオンオフ、長押しで調光ができるので楽。
オンオフのときに、フワっと付いたり消えたりするので目に優しい。これは地味に重要。

悪い点

お値段がちょっと高めの7,800円。ですが、基本的に壊れるものではないし、他の部屋に移設できるので1つは持っておいても良い気がします。
明るさの調整が上げるか下げるかなので、今の明るさがどのへんなのかがわからない。何かしらのフィードバックが欲しいけど、無いので最大限明るくなっているのか暗くなっているのかがわからない。

生成系AIサービスから自分のサイトをブロックする方法

Fri, 02 Aug 2024 00:00:00 GMT

サイトのトップに以下のrobots.txtを設置または、コピペします。

https://gist.github.com/matsubo/1b4e362ac5a30302b324b008de703487

生成AI系サービスのuser agent名は以下から検索できます。

https://darkvisitors.com/agents

Dark Visitorを導入してみた

このBlogにDark Visitorのプラグインを導入してみてクロールしに来たBotを計測してみました。

無料だと10,000イベントちょっと計測できないようです。導入して4日で使い切ったようです。

その際のサマリーを軽く載せておきます。

短縮URLサービスの利用を再考する：Bitlyの変更を機に探る最適な選択肢

Fri, 02 Aug 2024 00:00:00 GMT

概要

bitlyのサービス内容が変更され、無料だと月に10個しか作れなくなりました。それに伴い、課金して使うか検討したときの資料をまとめておきます。

そもそも短縮URLを取り巻く環境はどうなっているのか調査して、対処方法を意思決定しました。

背景

運用している複数のプロダクトでBitlyを使って短縮URLを生成していました。

短縮URLを生成する目的は、SMSで自社のURLを送信する際に文字数制限があったりSMSのメッセージが分割されるのを可能な限り防ぎ、送信のコストを削減する目的で導入していました。

問題

URLを短縮するだけにあまりコストを払いたくないです。

Googleが短縮URLサービスを停止したりしているので短縮URLは必要性が低くなってきているような雰囲気を感じます。

サーベイ

biltly以外の短縮URLサービスに乗り換えようと考えて、類似サービスを探していたのですが意外と欲しいサービスが見当たりませんでした。短縮URLサービスに求めることが意外と多いのです。

短縮URLサービスに求めることまとめ

運営元がしっかりしていること。（広告を挟んだりされてしまうリスクがあるため）
長期的に運用されそうなこと、長期的に運用してきていること。（途中で止まるとリンク切れになるため）
ドメイン名が短いこと。
短縮URLサービス名が広く認知されていること。（ユーザにとって見れば、自分が使っているサービスとは違うドメインのURLが掲載されているので）
APIでURLを発行できること。

上記を満たすようなサービスはすごい少ないです。しかも、ドメイン名が短いと結構怪しい感じが出ちゃうのでサービス名が広く知られていることは重要だったりします。

上記の要件を満たす候補は、tinyurl, Ow.lyぐらいしか無いです。

短縮URLサービスのリスク

もし短縮URLサービスに秘密のリンクを掲載して認証無しに設定したら短縮URLサービス側に悪意があったらその情報にアクセスできてしまいます。

また、細かいことを言えばユーザにとって見れば、利用規約を踏んでいないのに他社のサービスを利用することになってしまいます。

自社のプロダクト内で短縮URLサービスの生成に失敗してしまった場合に、エラーハンドリングを適切に行なっていなければ処理が落ちてしまって後続のSMS送信などが失敗するリスクがあります。コードレビューをしっかりする必要があります。

短縮URLサービスを使うメリット

そもそも短縮URLを使うメリットを考えてみます。主に以下の2点かなと思います。

トラッキングコードを入れてもURLが長くならない。
SMSの送信コストを抑えられる。

アプローチ

上記を踏まえて、自社のプロダクトでどうするかのオプションを考えてみます。

bitlyを使い続ける

$8/monthを課金するだけで済むので1番楽です。コードを変更する必要もないです。　bit.lyというドメインの認知度はインターネットに慣れている人であれば高いですが、一般の人にとっては怪しく見えてしまうかもしれません。

自プロダクト内で実装する

ドメイン名がそこそこ短い場合は自社で実装してしまうのが良いかと思います。自社サービスと連動していればユーザに取ってみても認知されているドメイン名です。

構築するのもそんなに手間ではないと思います。短縮URLは1度作成したら基本的には消せないのでデータ容量は気にする必要があります。

短縮URLを使わない

最近、SMSは全角670文字ぐらいは送れるそうなので短縮URLサービスを使わないというのもオプションになります。

短縮URLを使うより文字数が多くなってしまうのでSMS送信コストは増える可能性が高いです。

理想を考える

転送URLを使わないことが一番です。

その次は、自プロダクトで短縮URL機能を作ること。

最後に、社外の短縮URLSaaSを使うこと

と考えます。

短縮URLサービスを使うことをやめてみて

手元のサービスで、短縮URLをつかなくなったことで1通あたり8円程度のSMSで送信コストがアップしてしまいました。

140通/月以上送る場合は短縮URLを使ったほうが安いことになります。

まとめ

短縮URLを使うメリット・デメリットをまとめました。

プロダクトの状況をや達成したい目標にあったアプローチを選定する必要があります。

追記

2024/8/13

https://dub.co/ というサービスを教えてもらいました。ゼロイチで開発するならばこのサービスが一番良いです。

https://dub.co

短縮URLのニーズは現在でも一定数はありそうです。手元のサービスにおいて短縮URLを使わないでSMSを配信したらコストが1.5倍になりました。SMSにURLを掲載する場合は短縮URLに課金したほうがトータルコストが安くなるケースが多そうです。

Difyをローカルで動かしてみる。3分でコピペで可能。

Thu, 01 Aug 2024 00:00:00 GMT

概要

LLM を使ったワークフローを作成するのに、 Dify が良さそうなのでローカルで立ち上げて使ってみます。

docker-compose.yml が用意されているので基本的には以下のページを参考にすればすんなり動きます。 https://docs.dify.ai/getting-started/install-self-hosted/docker-compose

Difyをローカルで動かす利点

主に以下の点があります。

アカウント登録不要で、無料で SaaS 版と同じ機能が使える。
SaaS 版より動作が速い。
テストで重要なデータを登録してみたりすると思いますが、ローカルでしか扱わないので自社のセキュリティポリシー内で運用し易い。

手順

前提として、git コマンドがインストールされていて、Docker と docker compose が利用できる状態が必要です。

Dify のリポジトリを Clone します。

git clone https://github.com/langgenius/dify.git

設定テンプレをコピーします。

cd dify/docker
cp .env.example .env

サービスを起動します。

docker compose up

ブラウザで開きます。

open 'http://localhost/'

起動直後の CPU 使用率、メモリ使用量はこのぐらいです。

Dify の動作が不安定だったり、非同期で色々裏で動いているのが log やリソースモニタを表示しているとわかりやすいです。

例えば、500MB のファイルをナレッジとして登録したときにブラウザ上では応答がなくなっちゃったりしますが裏では gunicorn と celery プロセスが CPU のコアを食い尽くしたりしているのがわかったりします。

image は 3GB 分ぐらい使ってます。

UI上でセットアップ

アカウントを作成していきます。

管理者カウントを作成します。言語設定を日本語にします。

こんな感じで初期設定を終えられます。

まとめ

SaaS 版だと動作が不安定な時にトラブルシュートがし辛いですがローカルだと裏のプロセスがどの用に動いているかわかりやすいです。
ローカルだと無料で動かせます。手軽に LLM アプリケーションを Cloudflare などを使ってトンネルしちゃえば作ってすぐに公開できます。

Postmanに法人番号検索REST APIを登録して世界へ公開！

Mon, 08 Jul 2024 00:00:00 GMT

3行まとめ

この記事は Postman Advent Calendar 2023のシリーズ2、17日目の記事です。
Postmanにアカウント登録して既存のREST API 仕様を登録し、Flow、Test、Visualization を使ってみました。
昔は無料でできることが少なかったのですが今は無料で色々できます。

背景

業務で Web アプリケーションを作成しているときに、「こんな Web API があったら楽なのに」と思うことがあり、なければ作ってしまえば良いと思い、個人的に無料で簡単に利用できる REST API によるデータ公開しています。

例えば住所の自動補完に使う郵便番号 API、インボイス登録番号に関連した法人番号検索 API などです。

今回は法人番号検索 API を扱います。

API は OpenAPI の仕様で公開しています。 https://corporation.teraren.com/openapi/corporation.teraren.com.yml

その API 仕様を redocというJavaScriptライブラリを用いて見やすく表示しています。 https://corporation.teraren.com/doc/redoc

問題

これらのサービス自体はなかなか認知されないです。そして、開発者がテストで軽く使ってみようとしても CLI からじゃないとテストできなかったり、swagger editor に OpenAPI のファイルを読み込ませてからリクエストを出すと言ったことをしないといけないので利用までの敷居が高いです。

アプローチ

Postman は世界的に広く使われている API 仕様を公開するサービスです。Postman を通じて開発者に広く知ってもらったり、開発者が使いやすい API の状態を作っていきたいと思います。

redoc 仕様公開はいわばドキュメントの公開です。Postman は仕様の公開と実行環境の提供です。

Postmanとは

Postman は API 開発のための強力な SaaS プラットフォームです。

API リクエストの作成、テスト、ドキュメント化、共有を容易にするツールを提供します。Postman は、REST、SOAP、GraphQL などの様々な API タイプに対応し、開発者が API のエンドポイントを簡単に検証できるようにします。

また、環境変数の管理、テストスクリプトの作成、API レスポンスのモニタリングなどの機能も備えており、チームでの協業をサポートするためのチームワークスペースも提供しています。

具体例でいうと、SwitchBotがPostmanでAPIを公開しています。

https://www.postman.com/

PostmanにAPIを登録して設定

ユーザ登録をした上で、API を登録する準備を進めていく手順を紹介します。

初期化

API を登録するためにはワークスペースを作る必要があります。

API 仕様はパブリックなので public を選びます。

public にする場合は、自分のプロフィールに公開用の情報を追加する必要があるのでダイアログに出たとおりに設定して OK を押します。

ちなみにこちらが私のプロフィールページになります。 https://www.postman.com/matsubokkuri

OpenAPI のファイルをインポートできる機能があったので早速 import してみます。

OpenAPIファイルをインポート

どうやってインポートをするか聞かれましたが、デフォルトで進んでみます。

追記: 上の Postman Collection は Postman での標準となる API 仕様のフォーマットです。下の、OpenAPI 3.0 witha Postman Collection は OpenAPI 3.0 との互換性を保った上での API 表現と、Postman 独自の Collection の両方に追加されます。今回は、Postman 専用に不可逆なファイルコンバートとして割り切ります。

インポートが完了すると左側のメニューに階層化されて表示されました。

しかしながら、階層が多いように感じたので適切なコレクションを作成して、エンドポイントを適切なコレクションに入れ直しました。ドラッグ&ドロップで移動できるので楽です。

エンドポイントの名前が見づらかったので少し修正しました。これで API を使う開発者にとってもかなり見やすくなったと思います。

機能を使ってみる

早速テストで法人番号の一覧を表示する API を呼び出してみます。下のペインに結果が整形されて表示されました。

Visualization のタブを選ぶと上の JSON の結果がテーブルに勝手に整形されて表示されました。見やすいです。

グラフ化できるような値の場合はグラフとして表示できるようです。

仮に line chart で描画してみました。メトリックや集計はできなさそうです。自動で選ばれたメトリックが X と Y に設定されました。自動で作成できるのは楽です。

一覧の取得はパラメータを一切必要としませんでしたが、今度は 1 つの法人の情報を取得してみます。変数となる部分は、collection のスコープで定義されているようです。

左のメニューの一番上のコレクションを選択したら変数の一覧とデフォルト値が表示されました。

有効な値に変更していきつつ、サーバの URL といった環境依存の変数は Environment に移します。完成した設定がこちらです。コレクションスコープ。

こちらは環境スコープです。

注意点

右上に「Save」ボタンがあるので毎回押し忘れないように気をつけましょう。
Current Value のカラムにある値が使われるのでこちらも合わせて正しい値を設定しておきましょう。

ということで、法人の情報を 1 件取得してみます。結果が下のペインに表示されました。

同様に、他のエンドポイントに対しても適切にパラメータや変数を設定していき、呼び出しができることを確認します。

APIの自動テスト

API が正常に動作しているか、適切なスキーマで返却されているかをテストできる機能があります。テストの内容は、コレクション単位、エンドポイント単位で設定できます。

以下の例は、コレクション単位で設定できるテストの部分に書いてあります。単純に 200 番が返ってくるかどうかをテストするような汎用的な内容です。

上記を実行すると以下のようになります。各エンドポイントの呼び出しに対して評価されます。

今度は、個別のエンドポイントでテストを書いてみます。簡易的に、配列で値が返ってくるかを書いてみます。保存して、下のリフレッシュボタンを押すとテストを実行できます。

テスト内容は GPT に問い合わせることで半自動に作成でるので楽です。しかしながら、デバッグ方法がちょっとわかりませんでした。console に出力してもその内容がどこに出るの発見できませんでした。

今度は、コレクションの方に戻って定期的に自動テストを実行するように設定しておきます。これによって、API が仕様通りに動いているかを Postman を見るだけでひと目でわかるようになります。

このあたりは OpenAPI のスキーマを自動的に読み込んで、自動的にテストを書いてほしいものです。

monitorの設定

外部監視が設定できます。

定期的にテストを実行して死活監視してくれるようです。

Flowの作成

Postman 上で API や計算処理をしてワークフローを構築できるサービスです。

法事番号検索 API では、各都道府県ごとの法人数を返却するエンドポイントがあるのでシンプルですがグラフ化してみます。

ものの 2 分でグラフが構築できました。簡易的なダッシュボードとしても使えそうです。

プロフィールの整備

最後にプロフィールを入力しておきます。デフォルトのアイコンが何を意味しているのかよくわからないので写真も設定しておきました。

こんな感じで表示されました。かっこ良いです！ https://www.postman.com/matsubokkuri

考察

API仕様の提供方法

今まで使っていた Open API と Postman は同じレイヤのプロダクトなのでどちらをメインにして運用するかは考えどころです。→追記:GitHub 上の OpenAPI ファイルと Postman 上の仕様を同期できる機能があります。

Open API で書いておけば committeeといったライブラリで自動的にリクエストとレスポンスのテストを行ってくれるのでこれはかなり重宝します。→追記:Postmanでも型をチェックしてくれます。しかし、エラーメッセージが抽象的で分かりづらいです。

また、Open API はその名の通りオープンな仕様なので色々なツールで読み書きやクライアントライブラリの自動生成が可能です。

Open API と相互運用できたら最高だなと思いました。→追記：相互運用できますが、Postman Enterprise Ultimate plan が必要です。

みやすさ

ユーザ（開発者）に取ってみれば Postman で API が提供されている方が楽にテストできるので便益性が高いです。 Open API のビューアは貧弱なので辛いです。玄人向けという感じです。

日本語対応

ワークスペース名に日本語を使うといくつかの機能において意味不明なエラーが出て使えなくなることがありました。今回のテストは Workspace 名に日本語を使っていますがアルファベットだけにしておきましょう。

まとめ

Postman の UI はかなり優れているしテストも GUI 上で書けるので便利です。
Postman と OpenAPI との棲み分けがまだ整理できていないような感じがしました（理解が浅いだけかもしれません）

追記

Postman の思想がかなり自分の思い描く API のプラットフォームの価値観と一致したので、私が提供している郵便番号検索 API、銀行コード検索 API、駅・路線情報検索 API の仕様を Postman へ追加しました！

Snowflake のようなプラットフォームの API 版という感じがしていてなかなか良さそうです。

学校検索をもっと簡単に！REST APIサービスを公開

Mon, 08 Jul 2024 00:00:00 GMT

こんにちは、スタートアップの CTO をしているまつぼっくりです。今回は、私が開発した日本の学校情報APIについて紹介します。

日本の学校情報APIとは？

日本の学校情報 API は、日本全国の小学校、中学校、高等学校の情報を簡単に検索・取得できる API サービスです。学校名、住所などの基本情報を提供しています。

https://school.teraren.com/

なぜこのAPIを作ったのか

スタートアップの CTO として、様々なプロジェクトに携わる中で、学校情報を扱う機会が何度かありました。その度に感じたのが、信頼できる学校データの取得の難しさです。

「もっと簡単に学校情報を取得できないだろうか？」「他の開発者も同じような悩みを抱えているのでは？」

そんな思いから、日本の学校情報 API の開発がスタートしました。

APIの特徴

豊富なデータ: 全国約 37,000 校の情報を網羅
簡単な利用: RESTful API で、簡単にデータにアクセス可能
柔軟な検索: 学校名、住所、電話番号など様々な条件で検索可能
個人・商用利用無料: 商用、非商用利用が可能です。アクセス数の制限はありません。

開発で苦労したポイント

1. データの収集と整理

信頼性の高いデータを提供するため、複数のソースから情報を収集し、クレンジングする必要がありました。この過程で、データの不整合や欠損に悩まされましたが、機械学習を活用した自動クレンジングシステムを構築することで、効率的にデータの質を向上させることができました。

2. APIのパフォーマンス最適化

大量のデータを高速に検索・提供するため、データベースの最適化に注力しました。インデックスの適切な設計や、キャッシュ戦略の実装により、応答速度を大幅に改善できました。

3. ユーザーフレンドリーなドキュメント

API の使いやすさは、ドキュメントの質に大きく依存します。開発者目線でのわかりやすさと、ビジネス利用者向けの説明のバランスを取るのに苦心しました。結果として、API仕様書はとてもクリアで使いやすいものになったと自負しています。

API使用例

学校情報をCSVで取得

REST API でありながら、CSV ファイルでの出力にも対応しています。

日本全国の教育機関を全件取得

❯ curl -s https://school.teraren.com/schools.csv | nkf -w | head -n 5
学校コード,学校種,都道府県番号,設置区分,本分校,学校名,学校所在地,郵便番号,属性情報設定年月日,属性情報廃止年月日,旧学校調査番号,移行後の学校コード
A101110000012,A1,01,1,1,北海道教育大学附属函館幼稚園,北海道函館市美原３丁目４８番６号,0410806,2020-12-22,,016501,
A101110000021,A1,01,1,1,北海道教育大学附属旭川幼稚園,北海道旭川市春光５条２丁目１番１号,0700875,2020-12-22,,016502,
A101210000010,A1,01,2,1,札幌市立手稲中央幼稚園,北海道札幌市手稲区手稲本町２条５丁目１３番１号,0060022,2020-12-22,,016511,
A101210110017,A1,01,2,1,札幌市立中央幼稚園,北海道札幌市中央区北２条西１１丁目,0600002,2020-12-22,,017527,

東京都の高等学校を全件取得

❯ curl -s https://school.teraren.com/prefectures/13/standard_areas/13000/school_types/D1.csv | nkf -w | head -n 5
学校コード,学校種,都道府県番号,設置区分,本分校,学校名,学校所在地,郵便番号,属性情報設定年月日,属性情報廃止年月日,旧学校調査番号,移行後の学校コード
D113110000012,D1,13,1,1,東京学芸大学附属高等学校,東京都世田谷区下馬４−１−５,1540002,2020-12-22,,135502,
D113110000021,D1,13,1,1,筑波大学附属高等学校,東京都文京区大塚１−９−１,1120012,2020-12-22,,135503,
D113110000030,D1,13,1,1,筑波大学附属駒場高等学校,東京都世田谷区池尻４−７−１,1540001,2020-12-22,,135504,
D113110000049,D1,13,1,1,東京工業大学附属科学技術高等学校,東京都港区芝浦３−３−６,1080023,2020-12-22,,135505,

教育機関個別の詳細を取得

東京大学の詳細を取得

❯ curl -s https://school.teraren.com/schools/F113110102700.json | jq
{
  "code": "F113110102700",
  "school_type": "F1",
  "prefecture_number": "13",
  "establishment_category": 1,
  "main_branch_indicator": 1,
  "name": "東京大学",
  "location": "東京都文京区本郷７−３−１",
  "postal_code": "1130033",
  "attribute_info_setup_date": "2021-01-20",
  "attribute_info_cancellation_date": null,
  "old_school_survey_number": "0172",
  "post_transition_school_code": null,
  "created_at": "2024-06-02T02:45:53.123+09:00",
  "updated_at": "2024-06-02T02:45:53.123+09:00",
  "url": "https://school.teraren.com/schools/F113110102700.json"
}

テキスト検索

「慶應」を含む教育機関を取得

❯ curl -s 'https://school.teraren.com/schools.json?s=%E6%85%B6%E6%87%89&commit=%E6%A4%9C%E7%B4%A2' | jq
[
  {
    "code": "D111322800026",
    "school_type": "D1",
    "prefecture_number": "11",
    "establishment_category": 3,
    "main_branch_indicator": 1,
    "name": "慶應義塾志木高等学校",
    "location": "埼玉県志木市本町４−１４−１",
    "postal_code": "3530004",
    "attribute_info_setup_date": "2020-12-22",
    "attribute_info_cancellation_date": null,
    "old_school_survey_number": "116006",
    "post_transition_school_code": null,
    "created_at": "2024-06-02T02:45:51.505+09:00",
    "updated_at": "2024-06-02T02:45:51.505+09:00",
    "url": "https://school.teraren.com/schools/D111322800026.json"
  },
  {
    "code": "B113311300026",
    "school_type": "B1",
    "prefecture_number": "13",
    "establishment_category": 3,
    "main_branch_indicator": 1,
    "name": "慶應義塾幼稚舎",
    "location": "東京都渋谷区恵比寿２−３５−１",
    "postal_code": "1500013",
    "attribute_info_setup_date": "2020-12-22",
    "attribute_info_cancellation_date": null,
    "old_school_survey_number": "132048",
    "post_transition_school_code": null,
    "created_at": "2024-06-02T02:45:51.505+09:00",
    "updated_at": "2024-06-02T02:45:51.505+09:00",
    "url": "https://school.teraren.com/schools/B113311300026.json"
  },
  {
    "code": "C113310300026",
    "school_type": "C1",
    "prefecture_number": "13",
    "establishment_category": 3,
    "main_branch_indicator": 1,
    "name": "慶應義塾中等部",
    "location": "東京都港区三田２−１７−１０",
    "postal_code": "1080073",
    "attribute_info_setup_date": "2020-12-22",
    "attribute_info_cancellation_date": null,
    "old_school_survey_number": "134532",
    "post_transition_school_code": null,
    "created_at": "2024-06-02T02:45:51.505+09:00",
    "updated_at": "2024-06-02T02:45:51.505+09:00",
    "url": "https://school.teraren.com/schools/C113310300026.json"
  },
  {
    "code": "D113310300024",
    "school_type": "D1",
    "prefecture_number": "13",
    "establishment_category": 3,
    "main_branch_indicator": 1,
    "name": "慶應義塾女子高等学校",
    "location": "東京都港区三田２−１７−２３",
    "postal_code": "1080073",
    "attribute_info_setup_date": "2020-12-22",
    "attribute_info_cancellation_date": null,
    "old_school_survey_number": "135986",
    "post_transition_school_code": null,
    "created_at": "2024-06-02T02:45:51.505+09:00",
    "updated_at": "2024-06-02T02:45:51.505+09:00",
    "url": "https://school.teraren.com/schools/D113310300024.json"
  },
  {
    "code": "B114310000119",
    "school_type": "B1",
    "prefecture_number": "14",
    "establishment_category": 3,
    "main_branch_indicator": 1,
    "name": "慶應義塾横浜初等部",
    "location": "神奈川県横浜市青葉区あざみ野南３−１−３",
    "postal_code": "2250012",
    "attribute_info_setup_date": "2020-12-22",
    "attribute_info_cancellation_date": null,
    "old_school_survey_number": "140448",
    "post_transition_school_code": null,
    "created_at": "2024-06-02T02:45:51.505+09:00",
    "updated_at": "2024-06-02T02:45:51.505+09:00",
    "url": "https://school.teraren.com/schools/B114310000119.json"
  },
  {
    "code": "C114310000199",
    "school_type": "C1",
    "prefecture_number": "14",
    "establishment_category": 3,
    "main_branch_indicator": 1,
    "name": "慶應義塾普通部",
    "location": "神奈川県横浜市港北区日吉本町１−４５−１",
    "postal_code": "2230062",
    "attribute_info_setup_date": "2020-12-22",
    "attribute_info_cancellation_date": null,
    "old_school_survey_number": "143842",
    "post_transition_school_code": null,
    "created_at": "2024-06-02T02:45:51.505+09:00",
    "updated_at": "2024-06-02T02:45:51.505+09:00",
    "url": "https://school.teraren.com/schools/C114310000199.json"
  },
  {
    "code": "C114320500040",
    "school_type": "C1",
    "prefecture_number": "14",
    "establishment_category": 3,
    "main_branch_indicator": 1,
    "name": "慶應義塾湘南藤沢中等部",
    "location": "神奈川県藤沢市遠藤５４６６",
    "postal_code": "2520816",
    "attribute_info_setup_date": "2020-12-22",
    "attribute_info_cancellation_date": null,
    "old_school_survey_number": "144226",
    "post_transition_school_code": null,
    "created_at": "2024-06-02T02:45:51.505+09:00",
    "updated_at": "2024-06-02T02:45:51.505+09:00",
    "url": "https://school.teraren.com/schools/C114320500040.json"
  },
  {
    "code": "D114310000222",
    "school_type": "D1",
    "prefecture_number": "14",
    "establishment_category": 3,
    "main_branch_indicator": 1,
    "name": "慶應義塾高等学校",
    "location": "神奈川県横浜市港北区日吉４−１−２",
    "postal_code": "2238524",
    "attribute_info_setup_date": "2020-12-22",
    "attribute_info_cancellation_date": null,
    "old_school_survey_number": "145644",
    "post_transition_school_code": null,
    "created_at": "2024-06-02T02:45:51.505+09:00",
    "updated_at": "2024-06-02T02:45:51.505+09:00",
    "url": "https://school.teraren.com/schools/D114310000222.json"
  },
  {
    "code": "D114320500093",
    "school_type": "D1",
    "prefecture_number": "14",
    "establishment_category": 3,
    "main_branch_indicator": 1,
    "name": "慶應義塾湘南藤沢高等部",
    "location": "神奈川県藤沢市遠藤５４６６",
    "postal_code": "2520816",
    "attribute_info_setup_date": "2020-12-22",
    "attribute_info_cancellation_date": null,
    "old_school_survey_number": "145798",
    "post_transition_school_code": null,
    "created_at": "2024-06-02T02:45:51.505+09:00",
    "updated_at": "2024-06-02T02:45:51.505+09:00",
    "url": "https://school.teraren.com/schools/D114320500093.json"
  },
  {
    "code": "F113310102984",
    "school_type": "F1",
    "prefecture_number": "13",
    "establishment_category": 3,
    "main_branch_indicator": 1,
    "name": "慶應義塾大学",
    "location": "東京都港区三田２−１５−４５",
    "postal_code": "1088345",
    "attribute_info_setup_date": "2021-01-20",
    "attribute_info_cancellation_date": null,
    "old_school_survey_number": "2197",
    "post_transition_school_code": null,
    "created_at": "2024-06-02T02:45:53.123+09:00",
    "updated_at": "2024-06-02T02:45:53.123+09:00",
    "url": "https://school.teraren.com/schools/F113310102984.json"
  }
]

学校種別の一覧を取得

D1やF1といったschool_typeの説明を取得

❯ curl -s 'https://school.teraren.com/school_types.json' | jq
[
  {
    "code": "A1",
    "name": "幼稚園",
    "created_at": "2024-06-01T03:39:26.790+09:00",
    "updated_at": "2024-06-01T03:39:26.790+09:00",
    "url": "https://school.teraren.com/school_types/A1.json"
  },
  {
    "code": "A2",
    "name": "幼保連携型認定こども園",
    "created_at": "2024-06-01T03:39:26.793+09:00",
    "updated_at": "2024-06-01T03:39:26.793+09:00",
    "url": "https://school.teraren.com/school_types/A2.json"
  },
  {
    "code": "B1",
    "name": "小学校",
    "created_at": "2024-06-01T03:39:26.793+09:00",
    "updated_at": "2024-06-01T03:39:26.793+09:00",
    "url": "https://school.teraren.com/school_types/B1.json"
  },
  {
    "code": "C1",
    "name": "中学校",
    "created_at": "2024-06-01T03:39:26.793+09:00",
    "updated_at": "2024-06-01T03:39:26.793+09:00",
    "url": "https://school.teraren.com/school_types/C1.json"
  },
  {
    "code": "C2",
    "name": "義務教育学校",
    "created_at": "2024-06-01T03:39:26.794+09:00",
    "updated_at": "2024-06-01T03:39:26.794+09:00",
    "url": "https://school.teraren.com/school_types/C2.json"
  },
  {
    "code": "D1",
    "name": "高等学校",
    "created_at": "2024-06-01T03:39:26.794+09:00",
    "updated_at": "2024-06-01T03:39:26.794+09:00",
    "url": "https://school.teraren.com/school_types/D1.json"
  },
  {
    "code": "D2",
    "name": "中等教育学校",
    "created_at": "2024-06-01T03:39:26.794+09:00",
    "updated_at": "2024-06-01T03:39:26.794+09:00",
    "url": "https://school.teraren.com/school_types/D2.json"
  },
  {
    "code": "E1",
    "name": "特別支援学校",
    "created_at": "2024-06-01T03:39:26.794+09:00",
    "updated_at": "2024-06-01T03:39:26.794+09:00",
    "url": "https://school.teraren.com/school_types/E1.json"
  },
  {
    "code": "F1",
    "name": "大学",
    "created_at": "2024-06-01T03:39:26.794+09:00",
    "updated_at": "2024-06-01T03:39:26.794+09:00",
    "url": "https://school.teraren.com/school_types/F1.json"
  },
  {
    "code": "F2",
    "name": "短期大学",
    "created_at": "2024-06-01T03:39:26.794+09:00",
    "updated_at": "2024-06-01T03:39:26.794+09:00",
    "url": "https://school.teraren.com/school_types/F2.json"
  },
  {
    "code": "G1",
    "name": "高等専門学校",
    "created_at": "2024-06-01T03:39:26.795+09:00",
    "updated_at": "2024-06-01T03:39:26.795+09:00",
    "url": "https://school.teraren.com/school_types/G1.json"
  },
  {
    "code": "H1",
    "name": "専修学校",
    "created_at": "2024-06-01T03:39:26.795+09:00",
    "updated_at": "2024-06-01T03:39:26.795+09:00",
    "url": "https://school.teraren.com/school_types/H1.json"
  },
  {
    "code": "H2",
    "name": "各種学校",
    "created_at": "2024-06-01T03:39:26.795+09:00",
    "updated_at": "2024-06-01T03:39:26.795+09:00",
    "url": "https://school.teraren.com/school_types/H2.json"
  }
]

今後の展望

現在のバージョンでも十分実用的ですが、さらに以下の機能を追加したいと考えています：

学校の特徴（特色ある教育プログラムなど）の情報提供
時系列データ（生徒数の推移など）の追加
より柔軟な検索オプション（周辺施設との連携など）

また、海外の学校情報も提供できるよう、データベースの拡張も検討中です。

まとめ

日本の学校情報 API の開発を通じて、改めてデータの重要性と、それを使いやすい形で提供することの価値を実感しました。この API が、教育関連のアプリケーション開発やリサーチなど、様々な場面で活用されることを願っています。

みなさんも、「あったらいいな」と思う API やサービスがあれば、ぜひ開発にチャレンジしてみてください。ニッチな分野であっても、確実にニーズは存在するはずです。

最後になりましたが、日本の学校情報 API へのフィードバックをお待ちしています。より良いサービスにしていくため、皆様のご意見をぜひお聞かせください！

参考リンク

みなさんの開発ライフがより充実することを願っています！

MackerelプラグインでAPCのUPSを監視！「mackerel-plugin-apcupsd」の紹介

Tue, 02 Jul 2024 00:00:00 GMT

こんにちは、マインディアの CTO をしているまつぼっくりです。今回は、私が開発したMackerelプラグイン「mackerel-plugin-apcupsd」について紹介します。

https://github.com/matsubo/mackerel-plugin-apcupsd

なぜUPS監視プラグインを作ったのか

スタートアップの CTO として、サービスの安定運用は常に頭を悩ませる問題です。特に、電源の安定性は見過ごせない重要なポイント。そこで目をつけたのが、UPS（無停電電源装置）の監視でした。

「既存の Mackerel プラグインで UPS を監視できないかな？」と探してみたものの、ニーズにぴったり合うものがありません。「それなら自分で作っちゃえ！」というノリで開発を始めました。

プラグインの機能

このプラグインは、APC UPS の以下の項目を監視します：

バッテリー残量
入力電圧
出力電圧
負荷
内部温度

データの取得には apcupsd コマンドを利用しています。これらのデータを Mackerel で監視することで、UPS の状態をリアルタイムに把握し、潜在的な問題を早期に発見できるようになりました。

開発で苦労したポイント

開発中、最も苦労したのは apcupsd コマンドの出力を適切にパースすることでした。出力形式が微妙に不規則で、単純な行分割では対応できない場合がありました。

結局、以下のような正規表現を使って対応しました：

re := regexp.MustCompile(`^(\w+)\s+:\s+(.*)$`)

この正規表現で、キーと値のペアを適切に抽出できるようになりました。

また、Goの testing パッケージを使ってユニットテストを書くことで、パースの正確性を担保しています。テスト駆動開発（TDD）の良さを改めて実感した開発でした。

プラグインの使い方

インストールは以下のコマンドで簡単に行えます：

sudo mkr plugin install matsubo/mackerel-plugin-apcupsd

mackerel-agent.conf に以下の設定を追加するだけで使用可能です。

[plugin.metrics.apcupsd]
command = "/path/to/mackerel-plugin-apcupsd"

設定を反映するためにmackerel-agentを再起動します。

sudo systemctl restart mackerel-agent.service

今後の展望

現在のバージョンでも十分実用的ですが、さらに以下の機能を追加したいと考えています。

メトリックの単位ごとにグラフを変更する
グラフのカスタマイズオプション

まとめ

「mackerel-plugin-apcupsd」の開発を通じて、改めてオープンソースの素晴らしさを実感しました。自分のニーズを満たすツールを作り、それを他の人と共有できる。これこそがエンジニアの醍醐味だと思います。

みなさんも、「あったらいいな」と思うツールがあれば、ぜひ自分で作ってみてください。そして、それをオープンソースとして公開することで、エンジニアコミュニティに貢献できるはずです。

最後になりましたが、このプラグインへのフィードバックをお待ちしています。GitHub の Issue やプルリクエストをお待ちしています！

参考リンク

mackerel-plugin-apcupsd（GitHub）

みなさんの UPS 監視ライフが充実することを願っています！

UPSの状態をMackerelで可視化する: apcupsdとPythonを使ったカスタムプラグイン

Sun, 30 Jun 2024 00:00:00 GMT

UPSの状態をMackerelで可視化する: apcupsdとPythonを使ったカスタムプラグイン

はじめに

サーバーの安定稼働にとって、電源の安定供給は非常に重要です。そのため、多くの環境で UPS（無停電電源装置）が使用されています。UPS の状態を常に監視することで、潜在的な問題を早期に発見し、対応できます。

この記事では、apcupsd を使用して UPS の情報を取得し、それを Python スクリプトで Mackerel に送信する方法を紹介します。これにより、UPS の状態をリアルタイムで可視化し、監視することが可能になります。

前提条件

Linux 環境（Ubuntu, CentOS など）
Python 3.x
apcupsd
Mackerel アカウントとエージェント

セットアップ手順

1. apcupsdのインストールと設定

まず、apcupsd をインストールします：

sudo apt install apcupsd  # Ubuntu/Debian
# または
sudo yum install apcupsd  # CentOS/RHEL

次に、/etc/apcupsd/apcupsd.conf を編集します。変更した差分は以下です。

320fc
> UPSNAME BR550S
---
< #UPSDNAME
90c90
>  #DEVICE /dev/ttyS0
---
< DEVICE /dev/ttyS0

変更後の設定ファイル例を以下に記載します。

UPSNAME BR550S
UPSCABLE usb
UPSTYPE usb

NETSERVER on
NISIP 127.0.0.1
NISPORT 3551

ONBATTERYDELAY 6
BATTERYLEVEL 5
MINUTES 3
TIMEOUT 0

ANNOY 300
ANNOYDELAY 60
NOLOGON disable
KILLDELAY 0

EVENTSFILE /var/log/apcupsd.events
EVENTSFILEMAX 10

STATFILE /var/log/apcupsd.status
STATTIME 0

LOGSTATS off
DATATIME 0

この設定では、USBでUPSに接続し、standaloneで動作する前提の設定ファイルです。

2. Pythonスクリプトの作成

以下のPythonスクリプトを作成し、/etc/mackerel-agent/plugins/ups.py として保存します

#!/usr/bin/env python3

import subprocess
import re
import time

def get_apcaccess_output():
    result = subprocess.run(['apcaccess'], capture_output=True, text=True)
    return result.stdout

def parse_apcaccess_output(output):
    metrics = {}
    patterns = {
        'linev': r'LINEV\s+:\s+([\d.]+)\s+Volts',
        'loadpct': r'LOADPCT\s+:\s+([\d.]+)\s+Percent',
        'bcharge': r'BCHARGE\s+:\s+([\d.]+)\s+Percent',
        'timeleft': r'TIMELEFT\s+:\s+([\d.]+)\s+Minutes',
        'battv': r'BATTV\s+:\s+([\d.]+)\s+Volts'
    }

    for key, pattern in patterns.items():
        match = re.search(pattern, output)
        if match:
            metrics[key] = float(match.group(1))

    return metrics

def main():
    output = get_apcaccess_output()
    metrics = parse_apcaccess_output(output)
    
    timestamp = int(time.time())
    
    for key, value in metrics.items():
        print(f"ups.{key}\t{value}\t{timestamp}")

if __name__ == '__main__':
    main()

スクリプトに実行権限を付与します：

sudo chmod +x /etc/mackerel-agent/plugins/ups.py

3. Mackerelエージェントの設定

Mackerelエージェントの設定ファイル（通常は /etc/mackerel-agent/mackerel-agent.conf）に以下の設定を追加します：

[plugin.metrics.ups]
command = ["python3", "/etc/mackerel-agent/plugins/ups.py"]

設定後、Mackerelエージェントを再起動します：

sudo systemctl restart mackerel-agent

動作確認

設定が完了したら、Mackerelのダッシュボードを確認します。"Ups"という名前のグラフグループが作成され、以下のメトリクスが表示されるはずです：

ups.linev: 入力電圧 (V)
ups.loadpct: 負荷率 (％)
ups.bcharge: バッテリー充電率 (％)
ups.timeleft: 残り稼働時間 (分)
ups.battv: バッテリー電圧 (V)

まとめ

このセットアップにより、UPSの重要な情報をMackerelで可視化し、監視できます。異常な値が検出された場合にアラートを設定するなど、さらなるカスタマイズも可能です。

UPSの状態を常に把握することで、電源関連の問題を事前に察知し、サーバーの安定稼働を維持するための対策を講じることができます。

追記

mackerelの慣習に則って、mkr コマンドでインストールできるように Go でも書いておきました。

https://github.com/matsubo/mackerel-plugin-apcupsd

路線・駅情報のREST API開発と公開

Sun, 30 Jun 2024 00:00:00 GMT

概要

ekidata.jpの路線・駅データを使ったREST APIを作った
路線の停車駅一覧、駅の詳細情報、座標ベースの最寄り駅検索ができる
Rails + MySQL 8.4で、自宅サーバ + Cloudflareで公開中

https://train.teraren.com/

技術スタック

レイヤー	技術
バックエンド	Ruby on Rails
データベース	MySQL 8.4
ホスティング	自宅サーバ + Cloudflare

APIの使い方

山手線の全停車駅を取得

❯ curl -s 'https://train.teraren.com/lines/11302/stations.json' | jq '.[].station_name'
"大崎"
"五反田"
"目黒"
"恵比寿"
"渋谷"
"原宿"
"代々木"
"新宿"
"新大久保"
"高田馬場"
"目白"
"池袋"
"大塚"
"巣鴨"
"駒込"
"田端"
"西日暮里"
"日暮里"
"鶯谷"
"上野"
"御徒町"
"秋葉原"
"神田"
"東京"
"有楽町"
"新橋"
"浜松町"
"田町"
"高輪ゲートウェイ"
"品川"

座標から最寄り駅を検索

東京タワー付近の最寄り駅5件を取得する例。

❯ curl -s 'https://train.teraren.com/stations/near_by_stations.json?lon=139.7454329&lat=35.6585805&limit=5' | jq
[
  {
    "station_cd": 9930122,
    "station_name": "赤羽橋",
    "station_g_cd": 9930122,
    "distance": 0.42903606641634495
  },
  {
    "station_cd": 2800317,
    "station_name": "神谷町",
    "station_g_cd": 2800317,
    "distance": 0.49008364939314947
  },
  {
    "station_cd": 9930306,
    "station_name": "御成門",
    "station_g_cd": 9930306,
    "distance": 0.6242921448435772
  },
  {
    "station_cd": 9930305,
    "station_name": "芝公園",
    "station_g_cd": 9930305,
    "distance": 0.6391377203522578
  },
  {
    "station_cd": 9930121,
    "station_name": "大門",
    "station_g_cd": 9930121,
    "distance": 0.8572190503449685
  }
]

レスポンス速度

GETリクエストはCDNに載るのでリモートからの正確なベンチマークは取りにくい。CDNキャッシュが効いていない初回リクエストで100ms程度。Wi-Fiのロスが10msぐらいあるので、実質90ms前後だと思う。

❯ time curl -s 'https://train.teraren.com/stations/near_by_stations.json?lon=138.754&lat=35.68&limit=5' | jq
[
  {
    "station_cd": 1131124,
    "station_name": "勝沼ぶどう郷",
    "station_g_cd": 1131124,
    "distance": 1.260601057731234
  },
  {
    "station_cd": 1131125,
    "station_name": "塩山",
    "station_g_cd": 1131125,
    "distance": 3.307396894029273
  },
  {
    "station_cd": 1131126,
    "station_name": "東山梨",
    "station_g_cd": 1131126,
    "distance": 4.871013008643865
  },
  {
    "station_cd": 1131123,
    "station_name": "甲斐大和",
    "station_g_cd": 1131123,
    "distance": 5.162276817888356
  },
  {
    "station_cd": 1131127,
    "station_name": "山梨市",
    "station_g_cd": 1131127,
    "distance": 6.436090680301475
  }
]

________________________________________________________
Executed in   94.13 millis    fish           external
   usr time   10.79 millis    0.12 millis   10.68 millis
   sys time    7.64 millis    1.38 millis    6.26 millis

CDNキャッシュに入っていれば60ms程度で返ってくる。

まとめ

ekidata.jpのデータをRailsで薄くラップしただけのシンプルなAPIだけど、最寄り駅検索は地味に便利。自分の他のサービスからも内部的に使っている。

ベビーベッドにGoogle Nest Miniを設置していつでも手軽に音楽再生

Thu, 27 Jun 2024 00:00:00 GMT

概要

Google Nest Miniをベビーベッドに設置するとかなりQoLが高まります。設置には家に余っていた木ネジを使ってベビーベッドに打ち付けて、そこにNest Miniを引っ掛けます。

手軽に童謡を流したりできます。しかもGoogle Nestになってから音質がかなり良いです。

買ったもの

::amazon{asin="B0CQQ29K2W"}

よく使うコマンドは以下です。

「童謡の音楽を再生して」

「ジャンボリーミッキー流して」

「子守唄を再生して」

ちなみに、タブレットを設置して動画を流しっぱなしにするというアプローチもあるかと思いますが、教育上あまり良くないらしいのでタブレットは設置しない方針です。

考察

3ヶ月ほど運用してみました。おおかたとても役立っています。

改善したい点としては、「OK Google」と言ったときに反応しているかどうかが本体LEDの点灯によって判別できないのでベッドの裏側ではなく本体を見やすい位置に設置すべきです。

赤ちゃんのおむつ交換のための暗い照明環境の設置

Thu, 27 Jun 2024 00:00:00 GMT

概要

おそらく、夜中におむつ交換するときに微妙に薄暗いライトがほしい。直接照明だと覚醒してしまう可能性があるので、間接照明で。

ということで、天井にダクトレールを設置して、調光できるようにしました。

設置したものは、Panasonicのダクトレールを天井にビスで固定してあります。

買ったもの

使っているダクトレールはこちらです。取り付けにあたっては資格が必要な電気工事が必要になるのでハードルは高いです。

::amazon{asin="B0045U1SWA"}

::amazon{asin="B00B2GY6AG"}

簡易的に設置できるものもあるので見栄えを犠牲にしてこういうのを使うのもありだと思います。1年ぐらいしか利用しないと思いますし。

::amazon{asin="B0CJ9BKKFD"}

スポットライトに関しては、特にこだわりが無いので調光対応の安いものを使いました。

しかしながら、LED調光ライトだと極限に暗くしたいときにある程度暗くなったところから消えてしまうのでちょっと微妙でした。

かといって、現在だとLEDが主流なのでハロゲンとか電球を使うのもちょっと時代の流れ的に微妙です。できるだけ暗くて調光対応のもので、あとあと電球を入れ替えられそうな以下のものを試すのが良いと思います。

::amazon{asin="B0B5SLR3R2"}

tapoカメラでの赤ちゃん監視と録画方法

Thu, 27 Jun 2024 00:00:00 GMT

概要

赤ちゃんを常時監視して異常があったら検知する方法です。

異常検知しつつ、録画をしておけば成長記録にもなります。

買ったもの

監視カメラは多種多様なのですが、録画できて安くて屋内限定利用で充分です。

::amazon{asin="B0CKWS1VWR"}

しかも、TapoカメラはONVIFプロトコル (Profile S) に対応しているため、サードパーティ製のNVRやNASに映像を保存できます。

Tapoという変な名前ですが、TP-Link（大手）がメーカーなので安心です。過去にTP-LinkのWiFiアクセスポイントはコスパが良かったので5台くらい買いました。

動画をローカルに記録するためにはmicroSDカードが別途必要になります。

::amazon{asin="B0B2DCZDJZ"}

設置

ベビーベッドに穴あけします。付属のネジは長過ぎるので、別途余っていた木ネジを使ってベビーベッドに固定します。

足の方でも頭の方でもレンズの位置を移動できるので問題無いです。ベビーベッドに穴あけするのには少し躊躇しましたが、利便性が格段に上がるので穴あけして固定した方が良いです。

設置後はこんな感じ。

アプリから見るとこんな感じです。

動体検知をしたときだけ録画する設定にしています。赤い部分は泣き声検知、オレンジの部分は伸びをしたときとかの動きを検知したときです。

どんな感じのライフサイクルかがこれを見ると大体わかります。

壁掛けのAndroidタブレットを設置して、常時このカメラのストリームを表示しています。

こうすることによってリビングからいつでもベビーベッドを確認できます。これは超便利です。

microSDに保存された動画はこんな感じです。定期的にファイルをバックアップしておけば成長記録になります。

まとめ

tapoのカメラを設置しました。

性能、価格、アプリの使い勝手はかなり良いのでおすすめです。

私は設置場所に合わせて2台買いました。

Go Proアタッチメントを使用したベビーベッド監視カメラの設置方法

Thu, 27 Jun 2024 00:00:00 GMT

概要

以前の記事でベビーベッドに監視カメラを設置して大変便利になりました。

https://blog.teraren.com/posts/tapo-baby-check/

追加でユラリズムや別の場所に赤ちゃんを置いているときにも監視できるように三脚にカメラを設置できるようにしました。

普通にtapoのカメラを台やテーブルに置くだけでは赤ちゃんを撮影できません。なぜならカメラは設置した土台より下を撮影できなたいためです。そのため、カメラを下に向ける必要があるので設置方法はちょっと考える必要がありました。

台の作成

tapoのカメラには設置用の土台が付いてきます。しかし、アタッチメントがなくて壁などの平面に取り付ける前提なのでそのまま使えません。

手元にあったGo Proアタッチメント対応の3000円ぐらいの三脚があるので、それを流用してみます。

::amazon{asin="B0BF49J4ZM"}

まず、tapoの土台をGo Proマウントに変換するためアタッチメントを買いました。

::amazon{asin="B094XBSS3L"}

このアタッチメントのネジ部分は1/4inchのねじでカメラ取り付け用になっています。

tapoの土台に5.5mmの穴をドリルで開けます。穴を開けたら、Go Pro用のアタッチメントをねじ込みます。

あとは、Unaziの三脚に設置すれば終わりです。アタッチメントはアルミなのでちょっと重いtapoのカメラでもしっかり固定されます。

三脚側は前後にしか動けないけどカメラ側で350ぐらいは回転できるので大丈夫です。

ねじもアルミだとより安心感が出ると思います。

tapoアプリから見たプレビューです。こんな感じの角度で撮影できるようになります。

まとめ

もっと安くできる方法を考えるために、1週間ぐらい設置方法を考えていましたが結局面倒なでアタッチメントを買ってしまいました。

SeriaにGo Pro用のアタッチメントが昔は売っていたみたいなのでそれを流用したかったのですが今は売ってい無さそうです。

電池駆動のメリーを電源供給に改造して電池代を節約

Tue, 25 Jun 2024 00:00:00 GMT

概要

以下のメリーを使っています。

::amazon{asin="B015XA8YHC"}

最初は「こんなおもちゃが赤ちゃんをあやせるわけ無いだろう」と思っていましたが、今となっては必需品です。これがないと生活できません。

しかしながらこのメリーは単2電池3本で駆動しており電池消費を気にしながらいつまで使うのかわからないが単2電池のストックを管理する必要が出てきて面倒です。

充電池を使ったとしても、充電池の初期コストと充電中に利用できなかったり単2電池用の充電器を買ったりしないといけないので初期出費がかなり高いです。この出資分の損益分岐が迎えられるとは思いませんでした。

なので、電源から駆動するようにして電池を気にしないで無限に駆動できるように改造します。

分解

とりあえず回路がわからないといけないので、分解してみてみます。

電池は直列でつながっています。

逆流防止用にダイオードが付いています。

4.5V駆動の回路です。ACアダプターをこのためにだけに買うと1000円から2000円かかってしまうので、電圧が近い5VのUSB端子を使おうと思います。

家にあった、適当な充電用USBケーブルのメス側をカットしてコードを延長して接点につけます。

今後、電池で駆動させることは無いのでON/ONスイッチをつけるべきですが、省略します。

ついでに、ボタンの反応が悪くて強く押さないと反応しないので接点復活剤を塗布してウェスで拭き取っておきました。

::amazon{asin="B017CYN7NS"}

完成図。1A程度しか出力しないAC-USBアダプタを取り付けて終わり。電池切れを気にせず永遠に稼働させられます。

LEDライトも電池を気にせずONにできます。精神衛生上とても良いです。

neofetchが終了してfastfetchが引き継ぎ

Sun, 23 Jun 2024 00:00:00 GMT

Fastfetchの概要

Fastfetch は、システム情報を表示するための高速で効率的なツールです。このツールは、コンソールで動作し、オペレーティングシステム、カーネルバージョン、ディスプレイの解像度、メモリの使用量、CPU情報、GPU情報など、システムに関するさまざまな情報を美しく表示します。Fastfetchは、パフォーマンスとカスタマイズ性に重点を置いて設計されており、低リソース消費で高速に動作するのが特徴です。

特徴

高速動作: 軽量であり、非常に高速にシステム情報を取得して表示します。
カスタマイズ性: 表示内容やフォーマットを自由にカスタマイズ可能です。
低リソース消費: メモリやCPUの使用量が少なく、リソースに優しい仕様です。

Neofetchとの比較

Neofetch も同様にシステム情報を表示するツールですが、Fastfetchと比較するといくつかの違いがあります。

パフォーマンス

Fastfetch: 高速で低リソース消費。多くの場合、Neofetchよりも情報表示が速い。
Neofetch: デフォルト設定でも比較的高速ですが、Fastfetchほどではない。

カスタマイズ性

Fastfetch: 設定オプションが豊富で、細かなカスタマイズが可能。
Neofetch: カスタマイズも可能だが、Fastfetchほど柔軟ではない。

プラットフォームサポート

Fastfetch: 多くのLinuxディストリビューションをサポート。WindowsやmacOSでも動作する。
Neofetch: 幅広いプラットフォームで動作し、Linux、Windows、macOSを含む多くの環境で利用可能。

インストール

Ubuntuの場合はrepositoryを追加する必要がある。

sudo add-apt-repository ppa:zhangsongcui3371/fastfetch
sudo apt update
sudo apt install fastfetch

実行

NECレンタルルータが辛すぎ

Sat, 15 Jun 2024 00:00:00 GMT

概要

VDSLのレンタルルータである、「ATERM-0A1129」が辛い。

辛い点

本体が大きい
ファンレスではあるが発熱が大きい。
- 説明書に、上下左右は指定の空間を開けて設置する必要があると書いてある
- 実際に発熱が大きくて温かい。筐体は40度ぐらい。
DHCPサーバによる割当数がたった64しか無い。
- 見間違えかと思ったけど、本当に64しか配布できない。

不安定
- 月に数回、勝手に再起動する。
- それによってテレカンが切れる。。。
パケットが詰まる
- テレカンしていると、回線品質が悪いというアラートが頻繁に出る。
- リアルタイム通信における音声や動画の送受信に支障をきたす。
ハードウェア、ファームウェアの問題なので新品に交換しても改善しなかった。
回線品質が悪いから解約を申し出ても契約期間中の違約金なしでの解約ができなかった。
管理画面から設定できないところにVDSLのアカウント情報が書き込まれているので、別のハードウェアを使えない。
- レンタルすることが必須。
- 他社のハードウェアを利用できない
DHCPサーバのオプションを書き換えられないので任意のDNSサーバやパラメータを配布できない。
マニュアルに「電話回線として光ファイバーを利用し、電話機での通話を実現する電話サービスです。」という説明があるが意味がわからない。

良い点

無し

考察

以前使っていたNECのコンシューマ向けルータも酷い状態だった。

知り合いから設定を頼まれた家のルータがNECだったが、動作が不安定だった（設定通りに無線LANが動かない）。

NECのコンシューマ向けルータは使わない方が良いと思う。

QNAP TS-431Pを調達してNAS運用を始めました

Sat, 15 Jun 2024 00:00:00 GMT

概要

QNAP TS-431Pを買ってNASのある生活を始めました。3.5万円ぐらいでした。

::amazon{asin="B01N2K147Q"}

いままで

DELL PowerEdge T320に以下のディスクを乗せて運用していました。

OS領域 256GB SSDx2 RAID1
データ領域 2TB HDDx4 RAID1

しかしながら、RAIDコントローラのせいかHDDがスタンバイにならないので電力を食います。常時65W消費しています。昨今、電気代が結構高くなってきたので馬鹿にできない感じです。

それに、個人利用なのでHDDもほとんど利用していないの回転していると無駄に寿命を消費するのでスタンバイにしておきたです。

電気代とHDDのスタンバイ以外は最高です。ECC付きRAM、冗長化電源、XEON、Raidコントローラ、温度管理による安全な冷却。

TS-431Pの設定

Raidの設定

最近のQNAPのOSはすごいです。色々できそうです。そもそも最新のQNAPのハードウェアは個人向けでも結構無駄にいろいろな機能が付いていて金額が10万円ぐらいしてしまうので旧世代のハードウェアを買いました。

ディスクのプールを作るときには、Thin, Thick, Raidという謎な選択肢が出てきました。Thickにするとディスクの本数に応じて勝手にRaidレベルを変更するっぽいです。例えば、2本ならRaid1、3本ならRaid5といった感じです。

今回は、Thinckにしてしまいましたが普通にRaidにしたほうが良かったです。勝手にRaidのレベルを変えられてしまって困ります。

ネットワークの設定

GbEのポートが2つあり、ポートトランキングできるので設定しました。NASはネットワークがボトルネックになることが多いので。

その他の設定

アンチウィルスやメディアサーバとか色々アドオンできるっぽいです。

とりあえず、ディスクのスタンバイ機能を有効にして、無駄な機能は切りまくりました。

あと、ゴミ箱機能は有効にしてみました。あと、スナップショットも一応有効にして使ってみます。負荷が高かったら切ります。

設定項目が分かりづらいので、Perplexityに聞きながら色々進めました。

TS-431Pの運用

統計指標

Disk3を入れ替えてリビルド中のスクリーンショット。いろいろな指標が確認できて良いです。

ディスクの故障予期

SMART情報からディスクの寿命予測や、クリティカルな指標が出たらアラートを送ってくれます。

私が以前から使っていたハードディスク4本中2本にwarningが出ていたので別のディスクに交換しました。

Raidのリビルドにかかる時間

2TBのディスクを追加してリビルドをかけると24時間ぐらいかかります。HDDが古いので遅いです。。。

まとめ

Raid5で2TB x 4が動いています。Raidコントローラが壊れたら終わるのでなるべくRaid1で運用したいところではあります。

しばらく様子を見てみます。

WordPressをDockerizedしました

Sat, 15 Jun 2024 00:00:00 GMT

概要

クイックにWordPressを動かせる環境が欲しかったのでDocker composeで立ち上げられるようにしました。本番運用にも使えるように、動的に追加されるデータはファイルシステム上に保管されて永続化されるようにしています。

テンプレートリポジトリを用意したので、forkして使うのが手っ取り早いです。

https://github.com/matsubo/wordpress-docker-template

サーバ運用

{/* textlint-disable ja-technical-writing/no-unmatched-pair /} まず、Lightsail (月にで個人開発のサービスを一部運用していたのですが、データ量が多くなってきたのでストレージが足りなくなってきたことと、物理RAMが足りなくなってきたので自宅サーバへ移動しました。 {/ textlint-enable ja-technical-writing/no-unmatched-pair */}

Lightsailは以下のインスタンスを使っていました。

自宅サーバ自体もオーバースペック過ぎて、電気消費が大きいので新規に調達しました。

調達したPCはこちら。

https://blog.teraren.com/posts/gmktec-nucbox-m2/

安くて良いです

サービス運用

物理RAMが32GBあり、しばらく運用している現状で20GBぐらい使っています。

すべてのサービスをDockerizedしました。

DockerのRAMの利用常用はこんな感じです。

コンテナ数は30個ぐらいです。

RAMをたくさん使っているのは、MySQLとRailsのアプリケーションサーバです。RSS領域で使っています。あとは、disk cacheとしてちょこちょこ使われています。

WordPressサイトは10個ぐらいあります。1サイトごとにMySQLを立てているとメモリのMySQLサーバを立ち上げた直後の初期メモリ分が無駄になってしまうのでMySQLサーバは共有にしてアプリケーションサーバだけコンテナを個別にしました。MySQLは起動直後でも200MBぐらい消費するので、サイトごとに立てると馬鹿にならないです。128MBに制限したらメモリ不足で立ち上がりませんでした。

1.5ヶ月ほど運用していますが問題は起きていないし速度もLightsailに比べるとだいぶ速いです。

Docker Composeの設定

設定を作るときにこだわったポイントは以下です。

動的に生成されるMySQLのデータや、WordPressでアップロードしたメディアやプラグイン、テーマはファイルシステム上に保存される
必要最低限のパーミッションなので万が一クラックされても汚染されるスコープが狭い
WordPress本体のバージョンの更新はイメージで行い、プラグインやテーマの更新はWeb上から動的に行える

単一サイト構成

以下が docker-compose.yml です。

services:
  mysql:
    user: "${UID:-1000}:${GID:-1000}"
    image: mysql:latest
    restart: always
    volumes:
      - ./mysql/data:/var/lib/mysql
      - ./mysql/conf/custom.cnf:/etc/mysql/conf.d/custom.cnf
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: ${MYSQL_DATABASE:-wordpress}
      MYSQL_USER: ${MYSQL_USER:-root}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}

  wordpress:
    image: wordpress:latest
    user: "${UID:-1000}:${GID:-1000}"
    restart: always
    volumes:
      - ./wordpress/themes:/var/www/html/wp-content/themes
      - ./wordpress/plugins:/var/www/html/wp-content/plugins
      - ./wordpress/uploads:/var/www/html/wp-content/uploads
    links:
      - mysql
    depends_on:
      - mysql
    ports:
      - "${EXPOSE_PORT:-8080}:80"
    environment:
      WORDPRESS_DB_HOST: mysql
      WORDPRESS_DB_NAME: ${MYSQL_DATABASE:-wordpress}
      WORDPRESS_DB_USER: ${MYSQL_USER:-root}
      WORDPRESS_DB_PASSWORD: ${MYSQL_PASSWORD}

複数サイト構成（MySQL共有）

MySQLコンテナをWordPressごとに立ち上げるとメモリを消費してしまうので、MySQLを1つ立ち上げて複数のWordPressサイトから接続して使うほうが効率的です。

WordPressのコンテナの定義をコピー&ペーストして一部ハードコードして使います。複数のDBを扱うのでMySQLではrootで作業する必要が出てきます。

services:
  mysql:
    user: "${UID:-1000}:${GID:-1000}"
    image: mysql:latest
    restart: always
    volumes:
      - ./mysql/data:/var/lib/mysql
      - ./mysql/conf/custom.cnf:/etc/mysql/conf.d/custom.cnf
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_ROOT_HOST: '%'

  production:
    image: wordpress:latest
    user: "${UID:-1000}:${GID:-1000}"
    restart: always
    volumes:
      - ./production/themes:/var/www/html/wp-content/themes
      - ./production/plugins:/var/www/html/wp-content/plugins
      - ./production/uploads:/var/www/html/wp-content/uploads
    links:
      - mysql
    depends_on:
      - mysql
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: mysql
      WORDPRESS_DB_NAME: production
      WORDPRESS_DB_USER: root
      WORDPRESS_DB_PASSWORD: ${MYSQL_ROOT_PASSWORD}

  staging:
    image: wordpress:latest
    user: "${UID:-1000}:${GID:-1000}"
    restart: always
    volumes:
      - ./staging/themes:/var/www/html/wp-content/themes
      - ./staging/plugins:/var/www/html/wp-content/plugins
      - ./staging/uploads:/var/www/html/wp-content/uploads
    links:
      - mysql
    depends_on:
      - mysql
    ports:
      - "8081:80"
    environment:
      WORDPRESS_DB_HOST: mysql
      WORDPRESS_DB_NAME: staging
      WORDPRESS_DB_USER: root
      WORDPRESS_DB_PASSWORD: ${MYSQL_ROOT_PASSWORD}

自分の環境ではこの複数サイト構成を使っています。

WordPressの大まかなインフラ設定

DBは1コンテナ
WordPressのコンテナはオフィシャルのイメージを使っています。latestタグ。
theme, uploads, pluginsの3つのディレクトリはローカルのファイルシステムに保存してコンテナ側からマウントしています。

1つのdocker-compose.ymlに上記の設定を入れています。

1点、運用上ちょっと微妙なところはdocker compose経由でサービスを立ち上げると一気にコンテナを立ち上げてしまうので起動直後はCPU、Diskの負荷が増大します。

依存関係をつけて順番に起動していくように書いても良いですが、実際には依存関係がないし順番の管理が面倒なので割愛します。

セットアップ

テンプレートとなるリポジトリをcloneしてきます。

% git clone git@github.com:matsubo/wordpress-docker-template.git
% cd  wordpress-docker-template

以下のコマンドを打って動作に必要な環境変数を一通り自動で作成します。

echo -n > .env
echo "MYSQL_DATABASE=wordpress" >> .env
echo "MYSQL_USER=wordpress" >> .env
echo "MYSQL_ROOT_PASSWORD=$(tr -dc A-Za-z0-9 </dev/urandom | head -c 15)" >> .env
echo "MYSQL_PASSWORD=$(tr -dc A-Za-z0-9 </dev/urandom | head -c 15)" >> .env
echo "EXPOSE_PORT=8080" >> .env
echo "UID=$(id -u)" >> .env
echo "GID=$(id -g)" >> .env

そのあと、docker compose up すれば初期設定が行われて、サーバ環境が立ち上がります。

% docker compose up

ブラウザでアクセスすれば初期設定画面が出るので、そのまま進めればOKです。

既存のWordPressからDockerに移行する方法

オンプレで運用しているWordPressから移行する場合は以下の手順でいけます。

% cp -ra /old/wordpress/wp-content/{plugins,themes,uploads} wordpress/
% mysqldump -u ${OLD_MYSQL_USER} --password=${OLD_MYSQL_PASSWORD} ${OLD_MYSQL_DB_NAME} | bzip2 > dump.sql.bz2
% docker compose cp dump.sql.bz2 mysql:/dump.sql.bz2
% docker compose exec mysql bash -c 'bzcat /dump.sql.bz2 | mysql -u $MYSQL_USER -p$MYSQL_PASSWORD $MYSQL_DATABASE'
% docker compose exec mysql bash rm /dump.sql.bz2

wp-contentの中身をコピーして、DBをdumpしてコンテナに流し込むだけなので簡単です。

PHPの設定変更

Dockerhubから提供されているデフォルトのWordPressイメージでは、HTTP経由でアップロードできるファイルサイズの最大容量がたった2MBしかないです。

増やすためにはphp.iniによって設定をoverrideする必要があります。

wordpress/custom.ini にファイルを作って中身を以下のように追加します。

post_max_size = 50M
upload_max_filesize = 50M

あとはWordPressのイメージを起動する際に上記のファイルをマウントしてしまえばよいだけです。

      volumes:
        - ./wordpress/custom.ini:/usr/local/etc/php/conf.d/custom.ini

WordPressのバージョン更新

% docker pull wordpress:latest
% docker compose down && docker compose up -d

バックアップとリストア

クラウドじゃなくなったのでバックアップをしっかり取っていく必要があります。

ホストOS側でバックアップが取りやすいのがこの構成の良いところです。一時停止が許容できるなら以下のtarで丸ごとバックアップするのが一番簡単です。

フルバックアップ

% docker compose down
% tar jcf /path/to/backup.tar.bz2 .

フルバックアップからのリストア

% tar xf /path/to/backup.tar.bz2

環境の削除

環境を潰して元どおりにする場合。

% docker compose down
% rm -rf mysql/data/*
% rm -rf wordpress/*/*

今後

ハードウェア故障に対してのBCPを考えていきます。

TerraMasterを使ってMacOSでソフトウェアRaid1環境を構築してみる

Thu, 25 Apr 2024 00:00:00 GMT

概要

MacOSではソフトウェアRAIDを組めるので実際に使ってみて使用感を確かめてみたいと思います。様々なユースケースでどの用に動作するかを検証してみたいと思います。

買ったもの

エンクロージャ

TerraMaster D4-300 USB 3.1 Gen 1 タイプC ストレージ、外付けハードディスクエンクロージャー、HDD/SSD ホットスワップ

::amazon{asin="B08CN4Z4PC"}

用意したディスク

あえて2TBと4TBのディスクを用意してみました。

所感

HDD1をTerraMasterのエンクロージャへ、HDD2をTerraMasterを経由しないで直接Macにつなげたところ。

両方ともTerraMasterのエンクロージャへ入れたところ。OSから見える名称が異なるようです。

ディスク容量はちゃんと認識されています。

HDD1

HDD2

Raid1を構築

DiskUtilityの「ファイル」から「RAID アシスタント」

Raid1を選択

ディスクアレイを選択

右側にあるRoleはアクティブにするか、スタンバイにするかを選択できます。今回は2代のみなのでRAID Sliceを選択してアクティブにします。

次に、ディスクの名称とフォーマット方法を選択します。名前をわかりやすく変更しました。

また、「Automatically rebuild」というオプションがあります。自動リビルドが走る設定のようです。

ディスクの内容を消えることを通知するアラートが出ます。そして、「Create」を押します。

2分ぐらいで完了しました。

フォーマットが完了した後の画面はこの用になります。

物理ディスクと、ソフトウェアRaidによる論理ディスクが見えるようになります。

Unsplashからダウンロードした画像を適当に保存してみます。

6.7GBのWindowsのディスクイメージを書き込んでみます。

書き込みで42MB/s程度しか出ていません。USB 3.1接続のはずなのに遅すぎです。これではUSB2.0です。

接続にはUGREENのUSB-Cケーブルを使って直接Macに接続しています。

ユースケースチェック

HDD1を抜き差ししてみる

実験前の状態。2台のHDDがRaid1で組まれていてオンラインです。

HDD1を抜いたところ

そのままHDD1を指し直します。そうするとリビルドが自動で走ります。

もともとオンラインだったHDD2をマスタとして、HDD1を再構築し始めました。

ディスクのアクティビティを見ると、ReadとWriteが同程度活発に動いています。エンクロージャのランプは、HDD1が点灯して、HDD2が点灯しているのでディスクのデータをOS経由でコピーしているようです。

リビルドのスピードはすごい遅いです。5分で0.2しか進みません。完了まで16時間ぐらいかかる見込みです。

時間がかかりすぎるので、Raidのメンバーから外してみます。

10秒程度でリビルドが中止されてメンバーから外れました。

Raidの状態は以下のようになり、「Missing/Dmaged」になりました。

今度は、明示的にRaidのメンバーとしてHDD1を追加してみます。

以下の画面で5分程度待ちました。しばらくしたら、HDD1の電源が切れました。。。。処理が止まってしまっているようです。

しかたがないので、TerraMasterの電源を強制的にオフ。

再度、Raidのメンバーに追加しようとしましたが。同じ状況に陥りました。

DiskUtilityを強制終了してやり直します。

今度は、「Repair」を選択します。そうしたら、30秒ぐらいで処理が完了して以下のようにスペアディスクとして追加されたようです。

スペアディスクからメンバーには変換できないようなので、またHDD1をスペアから削除します。

30秒程度で完了しました。

再度、HDD1をRaid1のメンバーとして追加しますが、処理中から一向に動く気配がないです。HDD1のアクセスランプも一切動きません。

OSを再起動しても同じ症状です。よって、MacosのソフトウェアRaidは運用では使えない感じです。。。

HDD2のデータを取り出せるのか

HDD2を取り出して、単体でデータを取り出せるのかを実験してみます。

TerraMasterからHDD2を取り出して別のUSB接続の外付けドライブで接続してみます。

ディスクは認識するのですが、パーティションが認識されていません。

FirstAidを実行してみますがエラーで終わりました。

パーティションテーブルを見てみても何も表示されません。

そして、今度はHDD2をTerraMasterに戻します。そうしたら、ちゃんと認識されました。

ソフトウェアraidを組んだでも、ファイルシステム的には同じに見えるものかと思っていましたが違うようです。

上記の記載が正しいのであれば、HDD2を抜いて、別の接続方式で接続してもraid1のディスクアレイの1台として認識されそうですがされないので良くわかりません。

HDD2を抜いて別のベイに刺してみる

TerraMaster上でのベイの入れ替えを行ったら正しく動くか検証してみます。

もともとオンラインだったHDD2をbay-2からbay-1に移動してみました。そうしたら、ちゃんと認識されました。ディスクラベルも同一です。

TerraMaster外のディスクをraid1に追加できるか？

そもそもソフトウェアRaidなのでTerraMasterで接続していないディスクでRaidも組めるはずなので別の方法で接続したディスクを使ってみます。

以下のように追加するウィザードは出てきました。

次の処理へ進むと、先ほどと同じ用に処理がスタックします。

この状態だと、Raid1を組んでもそのRaidのアレイにディスクを追加できないというソフトウェアRaidとして機能しない状態になります。

どうやら、MacOSのソフトウェアRaidがまともに使えない感じです。

Web上には同様のトラブルのドキュメントが見当たらないです。ユースケースとしてもmacOSでRaid1を組んでディスクアレイをぶっ壊す系の話なのであんまり無さそうです。

まとめ

macOSのソフトウェアRaidは使え無さそう
TerraMasterの接続が非常に遅くて使えない。

Keychron K8 Proの初期化方法(factory reset)

Mon, 08 Apr 2024 00:00:00 GMT

オフィシャルサイトやマニュアルでは、以下のような記述があります

Factory Reset: Press fn + J + Z for 4 seconds until all the backlight flashes.

日本語訳: "fn + J + Z" をすべてのバックライトが点滅するまで4秒間押し続けます。

https://www.keychron.com/blogs/archived/k8-pro-factory-reset-and-firmware-flash

しかしながら、上記では無反応でした。

色々試した結果、こちらに書いてある方法が正しそうです。

https://github.com/Keychron/qmk_firmware/tree/bluetooth_playground/keyboards/keychron/k8_pro

Reset Key: Connect the USB cable, toggle mode switch to "Off", hold down the Esc key or reset button underneath space bar, then toggle then switch to "Cable".

日本語訳: USBケーブルを接続し、モードスイッチを「Off」に切り替えます。
スペースバーの下にあるEscキーまたはリセットボタンを押し続けた状態で、
スイッチを「Cable」に切り替えてください。

これでリセットできました。

自宅サーバー用にGMKtec Nucbox M2(Intel Core i7)を買ったのでレビュー

Tue, 02 Apr 2024 00:00:00 GMT

概要

自宅サーバーでPowerEdge T320を使っているが、大きいし消費電力が大きいのでちょっと買い変えを検討していた。

自宅サーバでは、サービスのホスティングとストレージサーバという2つの役割があるが、両方を満たそうとするとどうしても巨大で高価なサーバになってしまう。

買ったもの

::amazon{asin="B0C534QGZK"}

主なスペック

CPU: Intel core i7 11390H
RAM: 32GB(16GB*2) DDR4
Disk: 1TB PCIe3.0 SSD
GPU: Intel Iris Xe Graphics 1400MHz

これが、今回はアマゾンのセールで53,000円ぐらいで買えた。

ベンチマーク

CINEBENCHの結果。

Multi coreの場合: 5,067pts

Single core: 1,439pts

N100に比べるとCPUの消費電力は倍くらいです。クロック数も高いです。

温度はファンの制御が細かくちゃんと動いているので100度以内です。

ディスクの速度も十分に速い。HeroBoxに比べると全体的に7倍くらい速い。

Linuxをインストールしてみる

Ubuntu 22 （LTS）をインストールしてみたところ、WiFiのチップセットが認識されませんでした。REALTEKの製品です。

別途ドライバをインストールしたら、ネットワーク周りを起因としてkernel周りも不安定になったのでOSを初期化せざる負えなくなった。

まとめ

HeroBoxに比べると値段は3倍以上します。

パフォーマンスはまずまず。

CHUWI HeroBox 2023 (Intel N100搭載) を買ってみたのでベンチマーク

Wed, 13 Mar 2024 00:00:00 GMT

概要

CHUWI HeroBox 2023（Intel N100 / DDR5 8GB / 256GB SSD）を楽天スーパーセールで購入。価格は21,900円（税込・送料無料、2024/3/13時点）。

{/* textlint-disable ja-technical-writing/no-unmatched-pair ja-technical-writing/sentence-length */}

CHUWI HeroBox 2023 Intel N100 DDR5 8GB+256GB SSD ミニPC

{/* textlint-enable ja-technical-writing/no-unmatched-pair ja-technical-writing/sentence-length */}

::amazon{asin="B08L4XYP64"}

ちなみにChuwiの読み方は「ツーウェイ」が正しい（オフィシャルサイトに記載あり）。「チューウィー」かと思っていた。

ハードウェア

一昔前のブロードバンドルーターや、WiFiアクセスポイントと行った感じに似てます。HDDが無いので軽いです。

WUHDが出力できます。リフレッシュレートがかなり低い感じはしますが出力できているだけすごいです。

ファンは常時稼働しています。音は聞こえてきます。CPU負荷が高くなるとファンの回転数も上がって音が大きくなります。

https://www.youtube.com/shorts/tVA4qElUNWU

ベンチマーク

CrystalDiskMarkではこんな感じです。速度が遅いので、128MiBで計測しています。

CINEBENCHのスコアはマルチコアで2520pts, シングルコアで885ptでした。

温度

CPU使用率が100％に張り付くことがよくあります。

ブラウザのアップデートだったり、Windows Updateだったり、アプリケーションのインストールのときにはすぐに100％になります。

CPUコア温度を測定してみると、負荷が高い状況ですと大体76度程度。最高88度まで上がってます。

ファンのスピードが負荷に即時に応じて上がるのでさほど高温にならないようにはなっています。

通常温度は45度程度です。

部屋の温度は21度です。

まとめ

Raspberry Pi 4に比べると圧倒的に高性能。
WUHDに出力できるしWebブラウジングはストレスありません。
Windows Updateとかソフトウェアインストール時にCPU負荷が高くなるのでちょっとストレスを感じます。
NASサーバや、K8sのクラスタを組むのに最適かと思います。SDカードじゃなくてSATA SSDですし。

Painting Keychron keyboard frame with WR blue mica

Tue, 27 Feb 2024 00:00:00 GMT

Background

I bought a Keychron K6 keyboard. Out of the box, the appearance is plain — two-tone keycaps and a single red escape key on an otherwise all-dark frame. Functional, but not exciting.

While checking typing sound comparison videos on YouTube, I came across this one:

https://www.youtube.com/watch?v=ueL8_nh42wU

The painted frame looked so good that I decided to give my keyboard a custom paint job too.

Color choice: WR Blue Mica

WR Blue Mica is the iconic color of Subaru's WRX STI rally cars. It's a deep blue with metallic flakes that shifts subtly in different lighting. Subaru enthusiasts will recognize it instantly.

I chose this color because:

The metallic blue would contrast nicely with the dark keycaps
The red escape key would pop against the blue (Subaru rally vibes!)
Automotive-grade spray paint is durable enough for daily use

Materials

Silicon remover

Removes oils and contaminants from the metal surface so that paint adheres properly.

::amazon{asin="B00363PTSQ"}

Primer and surfacer spray

The frame is aluminum, so a primer is needed to give the paint something to bond to. Without it, the paint will chip off within days.

::amazon{asin="B002CPTTYY"}

WR Blue Mica spray

The star of the show. This is the actual Subaru WRX color code in spray can form.

::amazon{asin="B005UTHLSA"}

Clear coat

WR Blue Mica contains metallic flakes, so a clear coat is required to protect the finish and give it a smooth, glossy surface.

::amazon{asin="B002F1ODYQ"}

Total material cost was about 4,500 JPY. Since each can has enough paint for several projects, the per-keyboard cost is roughly 1,000 JPY.

Painting process

Overview

Clean with silicon remover
Apply primer + surfacer
WR Blue Mica × 2 coats
Clear coat × 2 coats

Allow 10–15 minutes of drying time between each coat.

Step 1: Primer

After cleaning the frame with silicon remover, I applied the primer + surfacer. This creates a uniform gray base for the color coat.

Step 2: Color

Two coats of WR Blue Mica. Light, even passes from 15–20 cm distance to avoid drips. The metallic flakes start to shimmer after the second coat.

Step 3: Clear coat

Two coats of clear to seal the metallic paint and add gloss.

Result

I also painted the bolt heads with black metallic paint for a cleaner look.

The contrast of the red escape key against the WR Blue Mica frame turned out great. It's giving off Subaru rally car energy.

Happy hacking!

macOSでSDカードやUSBメモリをフォーマットする方法

Fri, 23 Feb 2024 00:00:00 GMT

問題

Linux用にパーティションテーブルを変更してしまったSDカードやUSBメモリだとmacOSのディスクユーティリティを使ってもフォーマットやパーティションテーブルの書き換えが行えません。

かといって、フォーマットするためのアプリケーションを探してダウンロードするのが面倒です。

コマンド

diskutilコマンドでは、デバイス丸ごと（パーティションテーブルも含めて）フォーマットできるようなのでそれを使うのが良さそうです。

FAT32でフォーマットするコマンド例は以下。

diskutil eraseDisk FAT32 namae /dev/disk7

デバイスのIDを調べるためには以下のコマンドです。

diskutil list

実行例

diskutil list                                                                                                                      Fri Feb 23 19:41:26 2024
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:             Apple_APFS_ISC Container disk1         524.3 MB   disk0s1
   2:                 Apple_APFS Container disk3         994.7 GB   disk0s2
   3:        Apple_APFS_Recovery Container disk2         5.4 GB     disk0s3

/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +994.7 GB   disk3
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            10.5 GB    disk3s1
   2:              APFS Snapshot com.apple.os.update-... 10.5 GB    disk3s1s1
   3:                APFS Volume Preboot                 11.9 GB    disk3s2
   4:                APFS Volume Recovery                1.8 GB     disk3s3
   5:                APFS Volume Data                    557.2 GB   disk3s5
   6:                APFS Volume VM                      8.6 GB     disk3s6

/dev/disk7 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *64.8 GB    disk7
   1:                        EFI EFI                     209.7 MB   disk7s1
   2:       Microsoft Basic Data NAMAE                   64.6 GB    disk7s2

HyperX QuadCast VS Anker Powerconf C200のマイク性能を比較

Fri, 23 Feb 2024 00:00:00 GMT

背景

HyperX QuadCastをかれこれ3年ぐらい使っています。

性能に関しては全く文句はないです！ただ、デスク上の置き場を取ることが困ります。

::amazon{asin="B07NZZZ746"}

Anker PowerConf C200はWebカメラでありつつ、マイクを内蔵しています。しかもそのマイクはノイズキャンセリング機能付きと書いてあります。

::amazon{asin="B09MHPFV4Q"}

アプローチ

PowerConf C200のマイク性能が高ければ、HyperXのマイクを撤去できると考えました。ということで性能比較をしてみます。

実験

書斎の狭い部屋で同じ距離に置いて実験します。

実験1

環境

ノイズを作るために電気ヒーターをON

テスト

Hyper-X QuadCast

PowerConf C200

考察

ぜんぜん違いますね。波形を見ると一目瞭然です。

PowerConf C200の方は反響した音を拾っちゃっています。しかも、電気ファンヒーターのノイズを拾っています。

それに比べて、Hyper-Xのほうは口元にマイクがあるかのような聞こえ方です。音声が鮮明です。さすが指向性のあるマイク。そして、マイクだけで2万円するだけあります。（C200の3倍の値段）

実験2

環境

ノイズを作るために電気ファンヒーターをON

Keychron K8 Proキーボードをタイピング

::amazon{asin="B0C9HQS2WP"}

テスト

Hyper-X QuadCast

PowerConf C200

考察

両方ともタイピング音は入ります。やはりタイピング音は巨大です。HyperXの指向性を持ってしても排除できません。マイクと口との中間に位置するものなので排除が難しいのかと思います。

それに対して、Powerconfは全然ノイズ除去できていません。これはノイズ除去を売り文句にしてはいけないと思います。

結論

PowerConf C200のノイズキャンセリング能力はほとんど無く、マイクの性能もHyperXQuadCastに比べると指向性がなくていまいち。

HyperXを引き続き使います。

gatsbyセットアップメモ

Wed, 24 Jan 2024 00:00:00 GMT

セットアップ

このあたりを参考に。

https://dev.classmethod.jp/articles/gatsby-project-init/

% npm init gatsby

Need to install the following packages:
  create-gatsby@3.11.0
Ok to proceed? (y) y
create-gatsby version 3.11.0

                                                                                                     Welcome to Gatsby!

This command will generate a new Gatsby site for you in /Users/yuki.matsukura/ghq/github.com/matsubo/www.teraren.com with the setup you select. Let's answer some questions:

What would you like to call your site?
✔ · Teraren Corporate Site
What would you like to name the folder where your site will be created?
✔ www.teraren.com/ teraren-corporate-site
✔ Will you be using JavaScript or TypeScript?
· JavaScript
✔ Will you be using a CMS?
· No (or I'll add it later)
✔ Would you like to install a styling system?
· Tailwind CSS
✔ Would you like to install additional features with other plugins?
· Add the Google gtag script for e.g. Google Analytics
· Add responsive images
· Add an automatic sitemap
· Generate a manifest file
· Add Markdown and MDX support

Thanks! Here's what we'll now do:

    🛠  Create a new Gatsby site in the folder teraren-corporate-site
    🎨 Get you set up to use Tailwind CSS for styling your site
    🔌 Install gatsby-plugin-google-gtag, gatsby-plugin-image, gatsby-plugin-sitemap, gatsby-plugin-manifest, gatsby-plugin-mdx
  
✔ Shall we do this? (Y/n) · Yes
✔ Created site from template
✔ Installed Gatsby
✔ Installed plugins
✔ Created site in teraren-corporate-site
🔌 Setting-up plugins...
info Adding gatsby-plugin-postcss
info Adding gatsby-plugin-google-gtag
info Adding gatsby-plugin-image
info Adding gatsby-plugin-sitemap
info Adding gatsby-plugin-manifest
info Adding gatsby-plugin-mdx
info Adding gatsby-plugin-sharp
info Adding gatsby-transformer-sharp
info Adding gatsby-source-filesystem
info Adding gatsby-source-filesystem
info Installed gatsby-plugin-postcss in gatsby-config
success Adding gatsby-plugin-postcss to gatsby-config - 0.215s
info Installed gatsby-plugin-google-gtag in gatsby-config
success Adding gatsby-plugin-google-gtag to gatsby-config - 0.210s
info Installed gatsby-plugin-image in gatsby-config
success Adding gatsby-plugin-image to gatsby-config - 0.215s
info Installed gatsby-plugin-sitemap in gatsby-config
success Adding gatsby-plugin-sitemap to gatsby-config - 0.220s
info Installed gatsby-plugin-manifest in gatsby-config
success Adding gatsby-plugin-manifest to gatsby-config - 0.256s
info Installed gatsby-plugin-mdx in gatsby-config
success Adding gatsby-plugin-mdx to gatsby-config - 0.260s
info Installed gatsby-plugin-sharp in gatsby-config
success Adding gatsby-plugin-sharp to gatsby-config - 0.262s
info Installed gatsby-transformer-sharp in gatsby-config
success Adding gatsby-transformer-sharp to gatsby-config - 0.266s
info Installed gatsby-source-filesystem in gatsby-config
success Adding gatsby-source-filesystem (images) to gatsby-config - 0.278s
info Installed gatsby-source-filesystem in gatsby-config
success Adding gatsby-source-filesystem (pages) to gatsby-config - 0.281s
🎨 Adding necessary styling files...
🎉  Your new Gatsby site Teraren Corporate Site has been successfully created
at /Users/yuki.matsukura/ghq/github.com/matsubo/www.teraren.com/teraren-corporate-site.
Start by going to the directory with

  cd teraren-corporate-site

Start the local development server with

  npm run develop

See all commands at

  https://www.gatsbyjs.com/docs/reference/gatsby-cli/

% npm run develop


> teraren-corporate-site@1.0.0 develop
> gatsby develop

success compile gatsby files - 0.270s
success load gatsby config - 0.022s
success load plugins - 0.511s
success onPreInit - 0.008s
success initialize cache - 0.076s
success copy gatsby files - 0.413s
success Compiling Gatsby Functions - 0.856s
success onPreBootstrap - 0.901s
success createSchemaCustomization - 0.012s
success Checking for changed pages - 0.001s
success source and transform nodes - 0.091s
success building schema - 0.107s
success createPages - 0.006s
success createPagesStatefully - 0.073s
info Total nodes: 47, SitePage nodes: 4 (use --verbose for breakdown)
success Checking for changed pages - 0.000s
success write out redirect data - 0.006s
success Build manifest and related icons - 0.097s
success onPostBootstrap - 0.100s
info bootstrap finished - 4.405s
success onPreExtractQueries - 0.001s
success extract queries from components - 0.806s
success write out requires - 0.006s
⠀
You can now view teraren-corporate-site in the browser.
⠀
  http://localhost:8000/
⠀
View GraphiQL, an in-browser IDE, to explore your site's data and schema
⠀
  http://localhost:8000/___graphql
⠀
Note that the development build is not optimized.
To create a production build, use gatsby build
⠀
success Building development bundle - 8.742s
success Writing page-data.json and slice-data.json files to public directory - 0.047s - 3/4 85.29/s

いろいろやった結果

gatsbyのコミュニティが急速に衰退しているので微妙っす。デザインテンプレも良い感じのが出ない。

Next.JSを使ったほうが良さげ。

Google SpreadsheetやExcelでインボイス登録番号を求める方法

Sat, 23 Dec 2023 00:00:00 GMT

概要

業務をしていると、インボイス登録番号を求めるケースや、インボイス登録番号を求められるケースがあるので自動的に処理できるように API サービスを作りました。

この記事で言う、インボイス登録番号とは 適格請求書発行事業者番号 を指します。

以下のように法人番号からインボイス登録番号を表示できます。

インボイス番号とは

インボイス番号は、法人に対してと個人に対して付与されます。

インボイス番号の採番方法は以下のようになっています。

法人番号を有する課税事業者「T」（ローマ字）　＋　法人番号（数字13桁）上記以外の課税事業者（個人事業者、人格のない社団等）「T」（ローマ字）　＋　数字13桁（注）　（注）13桁の数字には、マイナンバー（個人番号）は用いず、法人番号とも重複しない事業者ごとの番号になります。

https://www.invoice-kohyo.nta.go.jp/about-toroku/index.html

インボイス番号は法人番号から一意に求められますが、その法人がインボイス登録番号を取得しているかはわかりません。

法人とインボイス番号は多対多の関係です。個人とインボイス番号も多対多の関係です。

アプローチ

以下の国税庁のサイトでは、インボイス登録番号から法人名や個人の番号の登録があるかは確認できますが、法人名や法人番号から検索はできません。

https://www.invoice-kohyo.nta.go.jp/index.html

以下のサイトから CSV や XML データでインボイス番号のダウンロードが行なえます。

https://www.invoice-kohyo.nta.go.jp/download/zenken

API実装

法人番号検索APIのサイトに追加する形でインボイス番号を検索できるように実装しました。

法人番号からインボイス番号を引けるように法人番号の子要素にインボイス番号を参照できるようにしました。

例えば、日本郵政株式会社 の場合は以下の URL になります。

https://corporation.teraren.com/corporations/5010001112697.json

invoice_registration_number というキーの下にインボイス番号の情報を付加しています。

API 仕様は OpenAPI Speification 形式にて以下の URL で公開してあります。

https://corporation.teraren.com/doc/redoc

表計算ソフトから利用する

Google Spreadsheetから利用する

ここで紹介する方法は、こちらにサンプルのファイルを用意したのでコピーして利用できます。 https://docs.google.com/spreadsheets/d/1GWDqjeIVkAEFydl3ADE7ZCVW5FIa3gE-LvNyY5xEANI/edit#gid=72101969

まずは法人番号を適当に取得しておきます。今回は「ソニー」というキーワードに合致する会社名と法人番号を取得してます。

% curl -s 'https://corporation.teraren.com/corporations.json?s=ソニー'| jq '.items[] | [.name,.corporate_number] | @csv'                                                    Sun Dec 24 02:37:50 2023
"\"有限会社アンソニー\",6430002047180"
"\"ソニーストレージメディアマニュファクチャリング株式会社\",3370601003097"
"\"ソニーストレージメディア労働組合\",4370005009310"
"\"株式会社アイソニーフーズ福島\",9380001009597"
"\"ろばた焼ソニー有限会社\",6060002030513"
"\"株式会社アンソニー・ケア\",5070001032295"
"\"株式会社アンソニージャパン\",7070001024761"
"\"有限会社ソニー\",5030002007911"
"\"株式会社アイソニーフーズ\",9030001052533"
"\"有限会社ソニーズフェラーリ\",5040002041117"
"\"株式会社ソニー商事\",1010001089007"
"\"ソニー銀行株式会社\",1010001126313"
"\"株式会社レクソニーデジタルエンターテイメント\",1010401068601"
"\"ソニービズネットワークス株式会社\",1010701026820"
"\"ソニー損害保険株式会社\",1010801006342"
"\"ソニー健康保険組合\",1700150004968"
"\"ソニーフィナンシャルベンチャーズ株式会社\",2010001193311"
"\"ソニーマーケティング株式会社\",2010401032358"
"\"株式会社ソニー・ミュージックパブリッシング\",2010401040773"
"\"ソニーリージョナルセールス株式会社\",2010401056489"
"\"ソニーモバイルコミュニケーションズジャパン株式会社\",2010401103588"
"\"ソニーネットワークコミュニケーションズコネクト株式会社\",2010701037387"
"\"有限会社アンソニープラン\",2011302000453"
"\"株式会社ソニー・ミュージックアクシス\",3010001074840"
"\"ソニー生命保険株式会社\",3010401016260"

以下のスクリプトをApps Scriptに追加して保存します。

function getInvoiceRegistrationNumberFromCorporationNumber(corporation_number) {
  var url = 'https://corporation.teraren.com/corporations/' + corporation_number  + '.json';
  
  try {
    var response = UrlFetchApp.fetch(url, {'muteHttpExceptions': true});
    response_object = JSON.parse(response);
    return response_object['invoice_registration_number']['registrated_number'];
  }catch(e){
    Logger.log(e);
  }
}

このスクリプトでは、引数として法人番号を受け取り、それを元にAPIを呼び出し、APIのレスポンスの中からインボイス番号を取得して表示しています。

その後は、上記の関数を呼び出すだけです。

呼び出し例

=getInvoiceRegistrationNumberFromCorporationNumber("3370601003097")

実際には別のカラムに法人番号があると思いますので以下のようになると思います。

Excelから利用する

Excelからは簡単に利用できる関数があります。以下の関数にURLを与えるとその返り値を表示できるようです。

=WEBSERVICE(URL)

サーバサイドで、上記の呼び出しに使えるエンドポイントを用意してあります。例えば、日本郵政のインボイス番号を取得するには以下のURLになります。

https://corporation.teraren.com/corporations/5010001112697/text/invoice_registration_number/registrated_number

上記のエンドポイントはレスポンスがJSONではなくテキストで返却されます。

A1のカラムに法人番号が書いてある場合は以下のように呼び出せばインボイス番号を取得できます。

=WEBSERVICE("https://corporation.teraren.com/corporations/"+A1+"/text/invoice_registration_number/registrated_number")

まとめ

法人番号からインボイス登録番号を取得するサービスを構築しました。
Google spreadsheet と Excel からインボイス番号を取得する方法を紹介しました。

HTMLのフィールドにおけるマウスホイール動作の無効化

Mon, 27 Nov 2023 00:00:00 GMT

背景

HTML において <input type="number"> は、数値入力を容易にするためのフォームフィールドです。ユーザーはテキスト入力に加えて、マウスホイールやキーボードの矢印キーを使用して値を調整できます。これは便利な機能ですが、一部の状況では意図しない挙動を引き起こす可能性があります。

Rails で UI を作るときには、本当は number_fieldにしたかったところをわざわざ、text_filedにして実装していました。

問題

<input type="number"> フィールド上にマウスカーソルがあるときに、ホイールを上下すると画面が上下しつつ、 フィールドの値も変わってしまいます 。

この問題はかなり昔からあって、5 年前ぐらいからは WebKit に存在していると思います。

アプローチ

半ば諦めていたのですが、そもそも JavaScript でホイールを無効化してしまえば解決できると思ってコードを書きました。これにより、マウスホイール操作による数値の変更を防ぎつつ、ページのスクロールはそのままにできます。

実装

ES のモジュールにしておきました。

以下のコードスニペットは、<input type="number"> フィールドでのマウスホイールによる値変更を阻止する方法を示しています。

/**
 * Disable changing value using mouse wheel
 */
export function disableWheel(selector) {
  document.querySelectorAll(selector).forEach(input => {
    input.addEventListener('wheel', event => event.preventDefault(), { passive: false });
  });
}

この関数は、指定されたセレクタに一致する全ての要素にイベントリスナーを追加します。wheel イベントが発生した際に preventDefault メソッドを呼び出すことで、マウスホイールによる値の変更を阻止します。

呼び出し方は以下の通りです。

import { disableWheel } from './disable-wheel.js';

window.addEventListener('load', function () {
  disableWheel('input[type="number"]')
}, false);

こちらにも置いておきます。 https://gist.github.com/matsubo/537aaecfbfd5389794da22f273afa01b

考察

この実装は、特定の要素に対するユーザーインタラクションの制御において非常に効果的です。しかし、すべての <input type="number"> フィールドでこの挙動を無効化することは、ユーザーにとって予期せぬ経験をもたらすことがあります。したがって、この機能を適用する際は、ユーザビリティとのバランスを考慮することが重要です。また、将来的にブラウザのデフォルト挙動が変更される可能性も考慮し、継続的なメンテナンスとテストが必要となります。

Tableau Serverをオンプレで運用する際のおすすめ設定

Wed, 27 Sep 2023 00:00:00 GMT

概要

Tableau server をオンプレで運用する際のおすすめの設定を書いておきます。

cronの設定

以下の 2 行を設定しています。

5   9  * * * source /etc/profile.d/tableau_server.sh && tsm maintenance cleanup --http-requests-table-retention 7 | logger 2>&1
10 */6  * * * source /etc/profile.d/tableau_server.sh && tsm licenses refresh | logger 2>&1

1行目の設定

毎日、1週間より古いログは削除する

という設定です。

Tableau Serverは常時大量のログファイルを書き込んでいます。

以下のグラフはディスク容量の遷移です。ディスク容量は256GBです。普通に運用していると2ヶ月ぐらいで100％使い切ってしまいます。

4月にこの設定を投入したので、直近は傾きが緩やかになっています。

2行目の設定

6時間ごとに tsm licenses refresh を行う

という設定です。

Tableau Serverのライセンスはオンラインで逐次Tableau側と同期が取られています。しかしながらその反映タイミングは不明です。いつも手動で tsm licenses refresh を行わないと反映されないです。

手動は面倒なので自動にします。頻度は6時間に設定しました。判断基準は適当です。

共通設定

TSMコマンドを利用するためには以下の環境変数が記載されたファイルを読み込む必要が有るので冒頭で必ず読むように設定しています。

source /etc/profile.d/tableau_server.sh

ロギングはsyslogに丸投げします

| logger 2>&1

Google Domains からドメイン保管料最安値のCloudflareへ移管しました

Fri, 22 Sep 2023 00:00:00 GMT

3行まとめ

Google Domains がサービス終了に伴い、 放置しておくとSquarespaceに移管されて、約2倍の3,000円/年が課金 されることになってしまいます。
最近のメジャーなドメインのレジストラを一通り調べて、一番安いレジストラを見つけて Cloudflare に移管してみました。
Cloudflare の CDN とか reverse proxy などを使っていますが、相変わらず Cloudflare の UI やコストの低さは良いです。

背景

2023 年 6 月 15 日、Squarespace は、Google Domains からドメイン登録と関連する顧客アカウントを購入する意向を発表しました。

「少なくとも 12 ヶ月間は既存の GoogleDomains ユーザーの料金プランを維持して利用できる」とアナウンスされているので、早急に何かする必要はありません。放置しておくと Squarespace に事業が移管されます。

個人的に.net と.com の 2 つのドメインを運用しています。

問題

Squarespace のドメイン料金はアカウント登録をしてドメインの検索をしないとわからないような仕様になっています。そこで、アカウント登録をして検索してみました。.com の保管料は3,000円/年のようです。初年度は割引があります。 .net の保管料も 3000 円/年のようです。

Google Domainsに比べると2年目は2倍の金額になります。

アプローチ

このまま放置していると、高額なドメイン保管料を支払うことになってしまうので安いところを探してみます。

メジャーなレジストラの .com ドメインの保管料を調べた結果がこちらです。

サービス名	価格 (円/年)	バーチャート
onamae.com	4,375	█████████████████████
Squarespace	3,000	████████████████
AWS	1,919	██████████
muumuu domain	1,728	█████████
Cloudflare	1,442	███████
Google Domains	1,400	███████

Cloudflare ではドメイン保管料を卸値で販売しているとのことです。ということで、Cloudflare に移管します。

余談ですが、onamae.com に関しての注意です。

whoisに代理情報を登録するのが有料です。
- 約 1,000 円/年という表記があります。
- whois には電話番号が必須なので個人の場合はどの電話番号を登録するかを考える必要があります。。
- 既存で運用しているドメインのオプションを確認すると、 2,156円 と書かれていたりもするので本当に怖いです。
値段だけでは評価できない罠がたくさんあります。

設定

Google Domains側の設定

ドメインの管理画面で、ロックの解除と認証コードを取得します。

DNSSEC を使っている場合は、DNSSEC をオフにしておく必要があります。TTL によっては結構な時間を待ってから移行しないと nameserver の移管後に名前解決ができなくなってしまいます。

Cloudflare側の設定

前提として、Cloudflare で zone を管理している必要があります。私の場合はすべてのドメインは Cloudflare で zone 管理しています。

Cloudflare で zone 管理をするメリットは以下の記事で詳しく書いてあります。 https://zenn.dev/matsubokkuri/articles/cloudflare-service

Google Domain 側でアンロックを行ってもすぐには移管できないようです。「アンロックしてから数時間待つ」という趣旨が書かれています。

2 時間ほど待ったら、ドメインが表示されました。

次へ進むと、認証コードを入力画面になります。複数ドメインを一気に処理できます。

次に、ICANN に登録する個人情報を入力します。

次に、以下のような画面になって移行がスタートします。

ステータスはドメイン一覧を表示すると閲覧できます。

Google Domain側の作業

すぐに、Google Domain で利用しているメールアカウントへ最終確認のメールが来ます。メールのボタンをクリックして移行を許可します。

確認

次に、whois コマンドで書き換わっているかを確認してみます。 (実際のドメイン名の部分は example.com に置き換えてます)

% whois example.com
# whois.verisign-grs.com

   Domain Name: EXAMPLE.COM
   Registry Domain ID: 1677305211_DOMAIN_COM-VRSN
   Registrar WHOIS Server: whois.cloudflare.com
   Registrar URL: http://www.cloudflare.com
   Updated Date: 2023-09-22T06:33:22Z
   Creation Date: 2011-09-16T01:04:50Z
   Registry Expiry Date: 2024-09-16T01:04:50Z
   Registrar: CloudFlare, Inc.
   Registrar IANA ID: 1910
   Registrar Abuse Contact Email:
   Registrar Abuse Contact Phone:
   Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
   Name Server: CRUZ.NS.CLOUDFLARE.COM
   Name Server: MAREK.NS.CLOUDFLARE.COM
   DNSSEC: signedDelegation
   DNSSEC DS Data: 2371 13 2 D718A03147EEF2F9D01774776C06F014EBE071258A1304E857DB56CF39E90F1F
   URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of whois database: 2023-09-22T06:35:31Z <<<

Nameserverが引き継がれていることを確認しておきます。

% host -t ns example.com
example.com name server marek.ns.cloudflare.com.
example.com name server cruz.ns.cloudflare.com.

考察

Cloudflare のドメイン保管料はかなり安いですが、Cloduflare で zone 管理をする必要があります。
8 ヶ月先まで有効なドメインが、Cloudflare にてなぜか 1 年間分課金されて更新されてしまいました。

npm, yarn, pnpmパッケージマネージャをベンチマークしてみた

Wed, 30 Aug 2023 00:00:00 GMT

3行まとめ

pnpm が速いとのことなのでベンチマークをしてみましたが、Yarn v4 が最速です。
Yarn v1 はキャッシュありのときにとても遅いでが、最新の v4 は全項目において最速です。
Node.js の Docker image でデフォルトになっているのは Yarn v1 なのでご注意ください。

概要

pnpm がどのくらい速いかを計測しています。
Next.js や React を使ったときのベンチマークは掲載されていますが、実際自分のプロジェクトではどの程度かわるのかをベンチマークしてみたいと思います。
pnpm とは何かを知りたい場合は pnpm概要を参照するのが良いです。

実験環境

個人サービスである銀行コード検索APIのpackage.jsonを使います。

package.json の中身は以下のようになっています。

{
  "packageManager": "yarn@1.22.15",
  "private": true,
  "dependencies": {
    "@hotwired/turbo-rails": "^7.3.0",
    "@popperjs/core": "^2",
    "@rails/activestorage": "^7.0",
    "@rails/ujs": "^7.0",
    "bootstrap": "^5.3",
    "bootstrap-icons": "^1.10.5",
    "bootswatch": "^5.3",
    "esbuild": "^0.18.17",
    "jquery": "^3.7"
  },
  "devDependencies": {
    "eslint": "^8.46.0",
    "eslint-plugin-react": "^7.33.1",
    "npm-check-updates": "^16.10.17"
  }
}

測定環境

root@1bf5d376c3a0:/app# node -v
v18.17.0
root@1bf5d376c3a0:/app# npm -v
9.8.1

npmのbenchmark

まずは基本となる npm を計測します。28秒。

root@1bf5d376c3a0:/app# rm -rf node_modules/ package-lock.json
root@1bf5d376c3a0:/app# time npm install

added 383 packages, and audited 384 packages in 28s

80 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

real	0m28.308s
user	0m9.264s
sys	0m5.575s

yarn v1のbenchmark

Node.jsに標準で組み込まれたyarnは、13秒。

root@1bf5d376c3a0:/app# rm -rf node_modules/ package-lock.json
root@1bf5d376c3a0:/app# time yarn install
yarn install v1.22.19
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
Done in 13.16s.

real	0m13.362s
user	0m5.338s
sys	0m6.641s/

yarn v4のbenchmark

最新のyarnで計測します。なんと5.8秒！計測ミスかと思って再度docker runして試しましたが同じ結果です。

root@1bf5d376c3a0:/# mkdir /app
root@1bf5d376c3a0:/# cat > package.json
root@1bf5d376c3a0:/app# yarn set version berry
root@1bf5d376c3a0:/app# yarn -v
4.0.2
root@1bf5d376c3a0:/app# time yarn install
➤ YN0000: · Yarn 4.0.2
➤ YN0000: ┌ Resolution step
➤ YN0085: │ + @hotwired/turbo-rails@npm:7.3.0, @popperjs/core@npm:2.11.8, and 474 more.
➤ YN0000: └ Completed in 3s 435ms
➤ YN0000: ┌ Fetch step
➤ YN0013: │ 455 packages were added to the project (+ 84.83 MiB).
➤ YN0000: └ Completed in 1s 442ms
➤ YN0000: ┌ Link step
➤ YN0000: │ ESM support for PnP uses the experimental loader API and is therefore experimental
➤ YN0007: │ esbuild@npm:0.18.20 must be built because it never has been before or the last one failed
➤ YN0000: └ Completed in 0s 501ms
➤ YN0000: · Done with warnings in 5s 438ms

real	0m5.816s
user	0m7.101s
sys	0m1.844s

pnpmのbenchmark

今回注目のpnpmは18秒。

root@1bf5d376c3a0:/app# time pnpm i
Packages: +347
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Progress: resolved 368, reused 0, downloaded 347, added 347, done
node_modules/.pnpm/esbuild@0.19.2/node_modules/esbuild: Running postinstall script, done in 93ms

dependencies:
+ @popperjs/core 2.11.8
+ @rails/activestorage 7.0.7-2
+ @rails/ujs 7.0.7-2
+ bootstrap-icons 1.10.5
+ bootswatch 5.3.1
+ esbuild 0.19.2
+ jquery 3.7.1

devDependencies:
+ eslint 8.48.0
+ npm-check-updates 16.13.2

Done in 17.9s

real	0m18.139s
user	0m7.202s
sys	0m5.991sx

余談: pnpmのエラー

余談ですが、2回目以降はエラーが出力されて計測できませんでした。

root@1bf5d376c3a0:/app# rm -rf node_modules/ .pnpm-store/
root@1bf5d376c3a0:/app# time pnpm install
Packages: +438
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 ERR_PNPM_LINKING_FAILED  Error: ENOENT: no such file or directory, copyfile '/app/.pnpm-store/v3/files/cf/83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e' -> '/app/node_modules/.pnpm/resolve@2.0.0-next.4/node_modules/resolve_tmp_124/test/resolver/same_names/foo.js'
Progress: resolved 459, reused 0, downloaded 438, added 197

real	0m20.723s
user	0m9.377s
sys	0m6.953s

追記: package-lock.json を削除したら成功しました。また、コンテナを立ち上げ直したら成功したりしたのでpnpmが内部で使っているハードリンク関連とDocker for macOSの相性が悪そうです。

キャッシュ無しベンチマーク結果

Package manager	Result (s)
npm	28.308
yarn v1	13.362
yarn v4	5.816
pnpm	18.139

考察

yarn v4がとても速いです。nodeのdocker imageのデフォルトではv1が使われてしまうので明示的にv4を設定する必要があります。
今回は初回実行を計測しました。
pnpmの初回は遅いですが、パッケージがシステム上で共有されること、依存関係の解決が高速なことを考えると2回目の実行はそこそこ速いです。
- 実際の開発では、CIや開発環境でパッケージの差分を追加していくと行った差分での利用が多いと思います。その際には高速に動作するので実運用では利点がありそうです。

次にパッケージマネージャを通して削除、追加する際のベンチマークを計測します。

パッケージの削除、追加の計測

実際の運用時に多いユースケースであるパッケージの追加、削除のときのベンチマークを計測してみます。

bootstrap パッケージを削除して、追加するケースを想定してベンチマークを取ってみます。

npm

トータル1.5秒。速いです。

root@7d57aaa10c85:/app/a# time npm uninstall bootstrap

removed 1 package, and audited 383 packages in 686ms

80 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

real	0m0.863s
user	0m0.772s
sys	0m0.160s
root@7d57aaa10c85:/app/a# time npm install bootstrap

added 1 package, and audited 384 packages in 767ms

81 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

real	0m0.943s
user	0m0.858s
sys	0m0.231s

yarn v1

トータル38秒。めちゃ遅いです。

root@7d57aaa10c85:/app/a# time yarn remove bootstrap
yarn remove v1.22.19
[1/2] Removing module bootstrap...
[2/2] Regenerating lockfile and installing missing dependencies...
success Uninstalled packages.
Done in 17.74s.

real	0m18.013s
user	0m5.547s
sys	0m8.845s
root@7d57aaa10c85:/app/a# time yarn add bootstrap
yarn add v1.22.19
warning package-lock.json found. Your project contains lock files generated by tools other than Yarn. It is advised not to mix package managers in order to avoid resolution inconsistencies caused by unsynchronized lock files. To clear this warning, remove package-lock.json.
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
success Saved 1 new dependency.
info Direct dependencies
└─ bootstrap@5.3.1
info All dependencies
└─ bootstrap@5.3.1
Done in 20.55s.

real	0m20.919s
user	0m5.861s
sys	0m9.193s

yarn v4

addとremoveがそれぞれ1秒以内に終わります。速い！

root@0c8caa909f49:/app# time yarn remove bootstrap
➤ YN0000: · Yarn 4.0.2
➤ YN0000: ┌ Resolution step
➤ YN0085: │ - bootstrap@npm:5.3.2
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
➤ YN0000: └ Completed
➤ YN0000: ┌ Link step
➤ YN0000: │ ESM support for PnP uses the experimental loader API and is therefore experimental
➤ YN0000: └ Completed
➤ YN0000: · Done with warnings in 0s 362ms

real	0m0.848s
user	0m0.778s
sys	0m0.375s
root@0c8caa909f49:/app# time yarn add  bootstrap
➤ YN0000: · Yarn 4.0.2
➤ YN0000: ┌ Resolution step
➤ YN0085: │ + bootstrap@npm:5.3.2
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
➤ YN0000: └ Completed
➤ YN0000: ┌ Link step
➤ YN0000: │ ESM support for PnP uses the experimental loader API and is therefore experimental
➤ YN0000: └ Completed
➤ YN0000: · Done with warnings in 0s 330ms

real	0m0.791s
user	0m0.820s
sys	0m0.171s

pnpm

トータル4.7秒。速いです。

root@7d57aaa10c85:/app# time pnpm remove bootstrap
Packages: -1
-
Progress: resolved 367, reused 346, downloaded 0, added 0, done

dependencies:
- bootstrap 5.3.1

Done in 2.2s

real	0m2.311s
user	0m2.041s
sys	0m0.906s
root@7d57aaa10c85:/app# time pnpm add bootstrap
Packages: +1
+
Progress: resolved 368, reused 347, downloaded 0, added 0, done

dependencies:
+ bootstrap 5.3.1

Done in 2.1s

real	0m2.239s
user	0m2.205s
sys	0m0.879s

remove/addのベンチマーク結果

Package manager	Remove Result (s)	Add Result (s)
npm	0.863	0.943
yarn v1	18.013	20.919
yarn v4	0.8480	0.791
pnpm	2.311	2.239

考察

pnpmが公表しているベンチマーク結果とは違いましたやはり手元でやってみるのは意味があります。

jsbundling-rails は Yarn に依存しているので要注意です。

参考資料

Package Manager Benchmarks

Amazon Linux 2023にfishを入れる方法

Tue, 29 Aug 2023 00:00:00 GMT

まとめ

Amazon Linux 2023 はどの Fedora, CentOS などのバージョンに対応するのか明示されていないのでソースからインストールしました。
Fedora と Cent OS の該当しそうな rpm をインストールしようとしましたが、glibc 周りの依存関係にひっかかってインストールできませんでした。
Amazon Linux 2のEOLが2023年6月30日から 2025年6月30日に変更 というニュースが20222年末に公開されました。Amazon Linux 2023 の登場に伴い、Amazon Linux 2 がオワコン化したので Amazon Linux 2023 に趣味サービスを載せ替えました。ついでにインスタンスサイズも 1 つ下げました。

インストール

依存されているライブラリと、コンパイラをインストールしておきます。

% sudo yum install ncurses-devel -y
% sudo yum install cmake gcc g++ -y

最新のソースコードをダウンロードしてビルドします。

% wget https://github.com/fish-shell/fish-shell/releases/download/3.6.1/fish-3.6.1.tar.xz
% tar xf fish-3.6.1.tar.xz
% cd fish-3.6.1/
% mkdir build; cd build
% cmake ..
% make

インストールします。 /usr/local/bin/fish に入ります。

% sudo make install

/usr/local/bin/fish を /etc/shells に追加します。

デフォルトのシェルを変更するためにchshしようとしたら、-bash: chsh: command not found と怒られたので、chshをインストールします。

% sudo dnf install util-linux-user

そして、デフォルトのシェルを変更します。

% chsh -s /usr/local/bin/fish

確認

無事入りました。

% fish -v
fish, version 3.6.1

MySQL Workbenchの後継であるMySQL Shell for VS Codeを使ってみる

Tue, 29 Aug 2023 00:00:00 GMT

概要

MySQL Workbenchのサーバーをモニタリングする機能がVS Codeのプラグインとしてリリースされているようなので軽く動作を見てみます。

設定

ssh tunnelの設定は相変わらずうまく接続できなかった（MySQL Workbenchのときも苦労しました）ので生のmysqlプロトコルで接続します。

グラフィカルに見栄えのするところは、左のメニューから「Performance Dashboard」を選んで、上部のメニューから「Performance Dashboard」を選択すると以下のようなグラフが表示されます。

Jupiter Notebookのような機能もあります。クエリーを実行して、その結果を動的にゴニョゴニョして行きます。トラブルシューティングのときに便利です。

普通にテーブルの中身を見たりもできます。

まとめ

Notebookは便利です。後々レポートを書くときなどに使いやすそう。
全体的に動作が不安定でした。。。

UbuntuでMySQLを8.0.34から8.1.0へアップグレード。Innovation Releaseを使う設定。

Tue, 29 Aug 2023 00:00:00 GMT

背景

MySQL Innovation Day Tokyo 2023に行ってきました。（オフィスから徒歩8分なので楽！）

2023年7月18日（今から約1ヶ月前）にMySQL初のInnovation Releaseが行われました。バージョンは8.1.0です。

最近のアップデート

あんまりMySQLの最新情報をキャッチアップしていなかったので軽くまとめます。

リリースサイクルの変更

2023年7月19日の記事にあるようにMySQLのリリースサイクルが変更になりました。

https://blogs.oracle.com/mysql-jp/post/introducing-mysql-innovation-and-longterm-support-lts-versions-jp

今後のリリースはLTSとInnovation Releaseの2つになります。Ubuntuと同じようなリリース体系を取ることとなります。バージョン表記は今までと変わらずセマンティックバージョニングでの表記になります。

Innovation Releaseは1月ごとにマイナーバージョンが1つ上がります。LTSは2年に1回マイナーバージョンが上がります。よって、2年に1回はInnovation ReleseとLTSのバージョンが合致します。

そして、LTSの方のバージョンはマイナーバージョン12個ずつ上がっていきます。Innovation Releaseのマイナーバージョンに関しては12で繰り上がり、メジャーバージョンが1つ上がるみたいです。（最初の方はイレギュラーにインクリメントされそうです）

よって、LTSのバージョンは8.4.0, 9.7.0, 10.7.0....という具合に上がっていきます。（非常に分かりづらい。）

LTSに対してパッチが当たるとリビジョンがインクリメントされます。

https://blogs.oracle.com/mysql-jp/post/introducing-mysql-innovation-and-longterm-support-lts-versions-jp

MySQL8のバージョン樹形図

@yoku0825さんのスライドにあるこの樹形図は参考になります。

https://speakerdeck.com/yoku0825/bokutatihamysql-8-dot-1todousheng-kiruka?slide=25

mysqlshのバージョン

mysqlshにはmysql serverのバージョンとは関係なく新機能をどんどん取り入れていくようです。言い換えると、Innovation Releaseと同じスパンで更新されていくような事を言ってました。

LTS or Innovation Release

ということで、業務や個人開発においてLTSか、Innovation Releaseのどちらを使うかが迷います。

個人的には、数ヶ月に1回ぐらい追加機能が入るような感じが良かったので3ヶ月1回にリリースされるInnovation Releaseのストリームをトラッキングすることとします。LTSは2年スパンです。

特に、MySQLは8.0になってからクリティカルなバグがリリースされる事件が数回起こっています。（過去、このバグを踏んで痛い目を見ました）

業務はLTS、個人開発はInnovation Releaseで良いのかなと思ってます。OSのディストリビューションをLTSにするかしないかという意思決定と揃えるとポリシーが揃ってわかりやすいと思います。

UbuntuのLTSのリリースも2年スパンなのでMySQLと同様です。Ubuntuは1年毎にメジャーバージョンが上がるので、偶数はLTSを意味することになります。

Innovation Releaseも日々使っておいてキャッチアップすることも重要なので個人サービスや自宅サーバはInnovation Releaseを使っていきます。OSもUbuntu Serverの最新を使うようにしているのでポリシー的にも合致します。

MySQL 8.1へのアップグレード事前チェック

まずは、現在のMySQL Serverのバージョンを調べてみます。

root@localhost:test> select @@version;
+-------------------------+
| @@version               |
+-------------------------+
| 8.0.34-0ubuntu0.22.04.1 |
+-------------------------+
1 row in set (0.00 sec)

MySQL Serverのapt lineはdebパッケージよって提供されています。このパッケージを入れることで自分が使いたいMySQLのメインストリームとなるLTSまたはInnovation Releaseのapt lineが追加されます。

% wget https://dev.mysql.com/get/mysql-apt-config_0.8.26-1_all.deb
% sudo dpkg -i mysql-apt-config_0.8.26-1_all.deb

インストール中に以下のようなダイアログが立ち上がり、どのプロダクトを使いたいかを選択します。デフォルトではLTSになっています。

なので、mysql-innovationを選びます。

画面を戻ったら、更新されています。OKを押して完了します。

まずは、最近（と言っても数年前から）のトレンドであるmysqlshをインストールします。mysqlクライアントの高機能版です。JavaScriptのsyntaxでコマンドを発行できるし、管理機能が充実しています。

matsu@dell ~> sudo apt-get update
matsu@dell ~> sudo apt-get install mysql-shell
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  mysql-shell
0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded.
Need to get 26.5 MB of archives.
After this operation, 226 MB of additional disk space will be used.
Get:1 http://repo.mysql.com/apt/ubuntu jammy/mysql-innovation amd64 mysql-shell amd64 8.1.1-1ubuntu22.04 [26.
5 MB]
Fetched 26.5 MB in 5s (5739 kB/s)
selecting previously unselected package mysql-shell:amd64.
Reading database ... 158313 files and directories currently installed.)
Preparing to unpack .../mysql-shell_8.1.1-1ubuntu22.04_amd64.deb ...
Unpacking mysql-shell:amd64 (8.1.1-1ubuntu22.04) ...
Setting up mysql-shell:amd64 (8.1.1-1ubuntu22.04) ...
Processing triggers for man-db (2.10.2-1) ...
Processing triggers for libc-bin (2.35-0ubuntu3.1) ...
matsu@dell ~>

とりあえず、バックアップをします。mysqlshを立ち上げて、以下のコマンドでdumpを行います。今までのmysqldumpに比べると超速いです。

util.dumpInstance("/home/matsu/20230828")

実行結果

matsu@dell ~> mysqlsh --user=root -p
Cannot set LC_ALL to locale en_US.UTF-8: No such file or directory
MySQL Shell 8.1.1

Copyright (c) 2016, 2023, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.

Type '\help' or '\?' for help; '\quit' to exit.
Creating a session to 'root@localhost'
Fetching schema names for auto-completion... Press ^C to stop.
Your MySQL connection id is 29696 (X protocol)
Server version: 8.0.34-0ubuntu0.22.04.1 (Ubuntu)
No default schema selected; type \use <schema> to set one.
 MySQL  localhost:33060+ ssl  JS > util.dumpInstance("/home/matsu/20230828")
Acquiring global read lock
Global read lock acquired
Initializing - done
2 out of 6 schemas will be dumped and within them 54 tables, 0 views.
3 out of 6 users will be dumped.
Gathering information - done
All transactions have been started
Locking instance for backup
Global read lock has been released
Writing global DDL files
Writing users DDL
Running data dump using 4 threads.
NOTE: Progress information uses estimated values and may not be accurate.
NOTE: Table statistics not available for `matsu_blog_covid19`.`wp_cocoon_affiliate_tags`, chunking operation may be not optimal. Please consider running 'ANALYZE TABLE `matsu_blog_covid19`.`wp_cocoon_affiliate_tags`;' f
irst.
NOTE: Table statistics not available for `matsu_blog_covid19`.`wp_cocoon_function_texts`, chunking operation may be not optimal. Please consider running 'ANALYZE TABLE `matsu_blog_covid19`.`wp_cocoon_function_texts`;' f
irst.
NOTE: Table statistics not available for `matsu_blog_covid19`.`wp_users`, chunking operation may be not optimal. Please consider running 'ANALYZE TABLE `matsu_blog_covid19`.`wp_users`;' first.
<snip>
Writing schema metadata - done
Writing DDL - done
Writing table metadata - done
Starting data dump
<snip>
Dump duration: 00:00:12s
Total duration: 00:00:12s
Schemas dumped: 2
Tables dumped: 54
Uncompressed data size: 1.59 GB
Compressed data size: 559.63 MB
Compression ratio: 2.8
Rows written: 4009346
Bytes written: 559.63 MB
Average uncompressed throughput: 129.15 MB/s
Average compressed throughput: 45.34 MB/s
 MySQL  localhost:33060+ ssl  JS >

圧縮後500MBのデータが12秒でdumpできました。

matsu@dell ~> du -hs  20230828/
535M    20230828/

次に、MySQL 8.1をインストールします。

本当はここでアップグレードの互換性チェックを行うべきです。この記事の下の方に記載してあります。

まずは、apt-cache policy mysql-serverコマンドで、どのパッケージが使われるかをチェックしてみます。

Ubuntuの8.0がインストール済みですが、8.1が入る事がわかります。

matsu@dell ~> apt-cache policy mysql-server
mysql-server:
  Installed: 8.0.34-0ubuntu0.22.04.1
  Candidate: 8.1.0-1ubuntu22.04
  Version table:
     8.1.0-1ubuntu22.04 500
        500 http://repo.mysql.com/apt/ubuntu jammy/mysql-innovation amd64 Packages
 *** 8.0.34-0ubuntu0.22.04.1 500
        500 http://ftp.tsukuba.wide.ad.jp/Linux/ubuntu jammy-updates/main amd64 Packages
        500 http://ftp.tsukuba.wide.ad.jp/Linux/ubuntu jammy-security/main amd64 Packages
        100 /var/lib/dpkg/status
     8.0.28-0ubuntu4 500
        500 http://ftp.tsukuba.wide.ad.jp/Linux/ubuntu jammy/main amd64 Packages
matsu@dell ~>

ということで、インストール（アップグレード）します。

sudo apt install mysql-client mysql-server

matsu@dell ~> sudo apt install mysql-client mysql-server
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libcgi-fast-perl libcgi-pm-perl libclone-perl libencode-locale-perl libevent-pthreads-2.1-7 libfcgi-bin libfcgi-perl libfcgi0ldbl libhtml-parser-perl libhtml-tagset-perl libhtml-template-perl libhttp-date-perl
  libhttp-message-perl libio-html-perl liblwp-mediatypes-perl libprotobuf-lite23 libtimedate-perl liburi-perl
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  mysql-common mysql-community-client mysql-community-client-core mysql-community-client-plugins mysql-community-server mysql-community-server-core
The following packages will be REMOVED:
  mysql-client-8.0 mysql-client-core-8.0 mysql-server-8.0 mysql-server-core-8.0
The following NEW packages will be installed:
  mysql-client mysql-community-client mysql-community-client-core mysql-community-client-plugins mysql-community-server mysql-community-server-core
The following packages will be upgraded:
  mysql-common mysql-server
2 upgraded, 6 newly installed, 4 to remove and 0 not upgraded.
Need to get 31.0 MB of archives.
After this operation, 33.0 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://repo.mysql.com/apt/ubuntu jammy/mysql-innovation amd64 mysql-server amd64 8.1.0-1ubuntu22.04 [66.5 kB]
Get:2 http://repo.mysql.com/apt/ubuntu jammy/mysql-innovation amd64 mysql-common amd64 8.1.0-1ubuntu22.04 [67.8 kB]
Get:3 http://repo.mysql.com/apt/ubuntu jammy/mysql-innovation amd64 mysql-community-client-plugins amd64 8.1.0-1ubuntu22.04 [1428 kB]
Get:4 http://repo.mysql.com/apt/ubuntu jammy/mysql-innovation amd64 mysql-community-client-core amd64 8.1.0-1ubuntu22.04 [2087 kB]
Get:5 http://repo.mysql.com/apt/ubuntu jammy/mysql-innovation amd64 mysql-community-client amd64 8.1.0-1ubuntu22.04 [2407 kB]
Get:6 http://repo.mysql.com/apt/ubuntu jammy/mysql-innovation amd64 mysql-client amd64 8.1.0-1ubuntu22.04 [66.5 kB]
Get:7 http://repo.mysql.com/apt/ubuntu jammy/mysql-innovation amd64 mysql-community-server-core amd64 8.1.0-1ubuntu22.04 [24.8 MB]
Get:8 http://repo.mysql.com/apt/ubuntu jammy/mysql-innovation amd64 mysql-community-server amd64 8.1.0-1ubuntu22.04 [78.2 kB]
Fetched 31.0 MB in 7s (4296 kB/s)
Preconfiguring packages ...
(Reading database ... 169877 files and directories currently installed.)
Preparing to unpack .../mysql-server_8.1.0-1ubuntu22.04_amd64.deb ...
Unpacking mysql-server (8.1.0-1ubuntu22.04) over (8.0.34-0ubuntu0.22.04.1) ...
(Reading database ... 169880 files and directories currently installed.)
Removing mysql-server-8.0 (8.0.34-0ubuntu0.22.04.1) ...
update-alternatives: using /etc/mysql/my.cnf.fallback to provide /etc/mysql/my.cnf (my.cnf) in auto mode
Removing mysql-client-8.0 (8.0.34-0ubuntu0.22.04.1) ...
Removing mysql-client-core-8.0 (8.0.34-0ubuntu0.22.04.1) ...
Removing mysql-server-core-8.0 (8.0.34-0ubuntu0.22.04.1) ...
(Reading database ... 169679 files and directories currently installed.)
Preparing to unpack .../0-mysql-common_8.1.0-1ubuntu22.04_amd64.deb ...
Unpacking mysql-common (8.1.0-1ubuntu22.04) over (5.8+1.0.8) ...
Selecting previously unselected package mysql-community-client-plugins.
Preparing to unpack .../1-mysql-community-client-plugins_8.1.0-1ubuntu22.04_amd64.deb ...
Unpacking mysql-community-client-plugins (8.1.0-1ubuntu22.04) ...
Selecting previously unselected package mysql-community-client-core.
Preparing to unpack .../2-mysql-community-client-core_8.1.0-1ubuntu22.04_amd64.deb ...
Unpacking mysql-community-client-core (8.1.0-1ubuntu22.04) ...
Selecting previously unselected package mysql-community-client.
Preparing to unpack .../3-mysql-community-client_8.1.0-1ubuntu22.04_amd64.deb ...
Unpacking mysql-community-client (8.1.0-1ubuntu22.04) ...
Selecting previously unselected package mysql-client.
Preparing to unpack .../4-mysql-client_8.1.0-1ubuntu22.04_amd64.deb ...
Unpacking mysql-client (8.1.0-1ubuntu22.04) ...
Selecting previously unselected package mysql-community-server-core.
Preparing to unpack .../5-mysql-community-server-core_8.1.0-1ubuntu22.04_amd64.deb ...
Unpacking mysql-community-server-core (8.1.0-1ubuntu22.04) ...
Selecting previously unselected package mysql-community-server.
Preparing to unpack .../6-mysql-community-server_8.1.0-1ubuntu22.04_amd64.deb ...
Unpacking mysql-community-server (8.1.0-1ubuntu22.04) ...
Setting up mysql-common (8.1.0-1ubuntu22.04) ...
Installing new version of config file /etc/mysql/conf.d/mysql.cnf ...                                                                                                                                               [5/678]
Installing new version of config file /etc/mysql/my.cnf.fallback ...
Setting up mysql-community-server-core (8.1.0-1ubuntu22.04) ...
Setting up mysql-community-client-plugins (8.1.0-1ubuntu22.04) ...
Setting up mysql-community-client-core (8.1.0-1ubuntu22.04) ...
Setting up mysql-community-client (8.1.0-1ubuntu22.04) ...
Setting up mysql-client (8.1.0-1ubuntu22.04) ...
Setting up mysql-community-server (8.1.0-1ubuntu22.04) ...
Installing new version of config file /etc/apparmor.d/usr.sbin.mysqld ...
Installing new version of config file /etc/mysql/mysql.cnf ...
Installing new version of config file /etc/mysql/mysql.conf.d/mysqld.cnf ...
update-alternatives: using /etc/mysql/mysql.cnf to provide /etc/mysql/my.cnf (my.cnf) in auto mode
Setting up mysql-server (8.1.0-1ubuntu22.04) ...
Processing triggers for man-db (2.10.2-1) ...
Processing triggers for libc-bin (2.35-0ubuntu3.1) ...
Scanning processes...
Scanning candidates...
Scanning processor microcode...
Scanning linux images...

The processor microcode seems to be up-to-date.

Restarting services...
Service restarts being deferred:
 systemctl restart NetworkManager.service
 systemctl restart networkd-dispatcher.service
 systemctl restart unattended-upgrades.service
 systemctl restart wpa_supplicant.service

No containers need to be restarted.

No user sessions are running outdated binaries.

No VM guests are running outdated hypervisor (qemu) binaries on this host.
matsu@dell ~>

インストール中に、以下のダイアログが表示されました。稼働中のサービスから接続できなくなるリスクを排除するために、互換性を優先して下を選びました。

チェック

ちゃんとインストールが完了したかをチェックします。

まずは、パッケージが入っているかをチェックしてみます。

dpkg -l|grep mysql

matsu@dell ~> dpkg -l|grep mysql
ii  mysql-apt-config                      0.8.26-1                                     all          Auto configuration for MySQL APT Repo.
ii  mysql-client                          8.1.0-1ubuntu22.04                           amd64        MySQL Client meta package depending on latest version
ii  mysql-common                          8.1.0-1ubuntu22.04                           amd64        Common files shared between packages
ii  mysql-community-client                8.1.0-1ubuntu22.04                           amd64        MySQL Client
ii  mysql-community-client-core           8.1.0-1ubuntu22.04                           amd64        MySQL Client Core Binaries
ii  mysql-community-client-plugins        8.1.0-1ubuntu22.04                           amd64        MySQL Client plugin
ii  mysql-community-server                8.1.0-1ubuntu22.04                           amd64        MySQL Server
ii  mysql-community-server-core           8.1.0-1ubuntu22.04                           amd64        MySQL Server Core Binaires
ii  mysql-server                          8.1.0-1ubuntu22.04                           amd64        MySQL Server meta package depending on latest version
rc  mysql-server-8.0                      8.0.34-0ubuntu0.22.04.1                      amd64        MySQL database server binaries and system database setup
ii  mysql-shell:amd64                     8.1.1-1ubuntu22.04                           amd64        MySQL Shell (part of MySQL Server) 8.0
rc  php8.0-mysql                          8.0.8-1ubuntu0.3                             amd64        MySQL module for PHP
rc  php8.1-mysql                          8.1.2-1ubuntu2.11                            amd64        MySQL module for PHP
ii  php8.2-mysql                          8.2.9-1+ubuntu22.04.1+deb.sury.org+1         amd64        MySQL module for PHP

ちゃんとmysql-server 8.1がインストールされていそうです。

動いているサーバがMySQL 8.1かをチェック

早速mysqlshを使って検証してみます。

\sql
SELECT @@version;

番外編: データのアップグレードができるかチェック

本当はアップグレード前にやるべきでしたが、mysql-serverのバージョンアップに当たって問題がないかをチェックするコマンドの紹介です。

util.checkForServerUpgrade();

番外編: mysqlsh

mysqlshの使い方は\helpと入力するととても長い説明が表示されますが、一通り読んでおくのが良いと思います。いろいろできるので。

backup & recoveryに関しては以下の記事が詳しいです。

https://qiita.com/orakurara/items/9a1b992909794d993761

まとめ

数年ぶりにMySQLをキャッチアップ。。。。
MySQL Heatwaveはすごそう。場合によってはSnowflakeより速いらしい。アーキテクチャはAuroraって感じ。Snowflakeも似たようなものだだし最近のRDBの水平分割の流行りの形ぽい。
MySQL Clusterの構築、運用が格段に楽になっているっぽい。Oracleに買収されて、Oracleの得意としている堅牢性を注入した感じがします。

deviseはパスワードをどのように安全に保管しているか？

Thu, 17 Aug 2023 00:00:00 GMT

3行まとめ

Devise はソルトとハッシュ値をDBに保存している。
pepper(Secret Salt)値はデフォルトでは使われていない。安全性を上げたければ追加したほうが良い。
Devise を使っていればとりあえず安全そう。

きっかけ

pictBLand と pictSQUARE に対する不正アクセスがあり、パスワードがソルトなしの MD5 ハッシュで保存されていたことが話題になっています。

Ruby on Rails で広く使われている Devise はどのようにパスワードを安全に保管しているのかを確認してみます。

背景

Deviseは、1億6000万以上のダウンロードを誇るRails向けの認証ミドルウェアです。暗号化操作のほとんどが抽象化されているため裏で何が起こっているかを使うべきではない言葉なので修正してくださいで使っている場合がほとんどです。

Devise において、パスワードが保存されているストレージのカラム名は encrypted_password です。このカラムには、以下のような文字列が保管されていて、この文字列は一体何を意味しているのか、どの用に使われているのかを説明します。

$2a$12$GfOja7i1byocYP7XuANk9OqyiE8KJPzG439mk0kZKB1rmggsxOHFu

Devise は Bcryptを使用して情報を安全に保存します。 Bcrypt のサイトには、「OpenBSD bcrypt() パスワードハッシュアルゴリズムを使用しているため、ユーザーのパスワードの安全なハッシュを簡単に保存できる」と記載されています。

しかし、このハッシュとは一体何なのでしょうか?どのように機能し、保存されたパスワードをどのように安全性を保つのでしょうか?

Deviseにおけるパスワード保存の流れ

データベースに保存されているハッシュから暗号化と復号化のプロセスまでを保存されている文字列から逆に辿って検証してみます。

まず、データベースに保存されている値を取得します。

irb> User.first.encrypted_password
=> "$2a$12$GfOja7i1byocYP7XuANk9OqyiE8KJPzG439mk0kZKB1rmggsxOHFu"

この文字列、$2a$12$GfOja7i1byocYP7XuANk9OqyiE8KJPzG439mk0kZKB1rmggsxOHFu は実際にはいくつかのコンポーネントで構成されています。

Scheme (2a) - ハッシュの生成に使用される bcrypt() アルゴリズムのバージョン
Cost (12) - ハッシュの作成に使用されるコスト係数
Salt (GfOja7i1byocYP7XuANk9O) - パスワードと組み合わせると一意になるランダムな文字列 (22文字)
Checksum (qyiE8KJPzG439mk0kZKB1rmggsxOHFu) - 保存されている実際のハッシュ部分 (31文字)

このフォーマットはMCF(Modular Crypt Format)です。 UNIXの/etc/shadowなどにも使われているメジャーなフォーマットです。

最後の3つのパラメーターを調べてみましょう。

Deviseを使用する場合、値はストレッチCostと呼ばれるクラス変数によって設定され、デフォルト値は 12 (2019年に11から12になりました)です。パスワードをハッシュする回数を指定します。
Saltは、元のパスワードと組み合わせるために使用されるランダムな文字列です。これは、同じパスワードが暗号化されて保存されるときに異なる値になる原因です。(なぜそれが重要なのか、またレインボーテーブル攻撃とは何なのかについては、こちらを参照してください。)
Checksumは、Saltと結合された後に実際に生成されたパスワードのハッシュです。

ユーザーがアプリに登録するときは、パスワードを設定する必要があります。このパスワードがデータベースに保存される前に、前述のコスト要因を考慮して、BCrypt::Engine.generate_salt(cost) によってランダムなSaltが生成されます。 (注: pepperクラス変数値が設定されている場合、Salt処理を行う前にその値がパスワードに追加されます。)

そのSalt (例: $2a$12$GfOja7i1byocYP7XuANk9O)を使用して、生成されたSaltとユーザーが入力したパスワードを使用して保存される最終ハッシュを計算します。BCrypt::Engine.hash_secret(パスワード, Salt)

その結果(例: $2a$12$GfOja7i1byocYP7XuANk9OqyiE8KJPzG439mk0kZKB1rmggsxOHFu)がデータベースの encrypted_password カラムに保存されます。

BCrypt::Password.create が BCrypt::Engine.generate_salt(cost) によって呼ばれます。しかし、このハッシュが不可逆であり、Saltがによる呼び出しでランダムに生成される場合、それをユーザーのサインイン時にどのようにつかわれるのでしょうか？

そこで、これらのさまざまなハッシュコンポーネントが役立ちます。ユーザーがサインインするために指定したメールアドレスに一致するレコードが見つかった後、暗号化されたパスワード(=encrypted_password の値)が取得され、上記のように5つのコンポーネント (Bcrypt version, Cost, Salt, Checksum) に分割されます。

この最初の準備が完了したら、次の順番で処理が行われます。

入力されたパスワードを取得します(ThisIsWeakPassword)
保存されているパスワードのSaltを取得します($2a$12$GfOja7i1byocYP7XuANk9O)
同じBcryptバージョンとコスト係数を使用して、パスワードとSaltからハッシュを生成します(BCrypt::Engine.hash_secret('ThisIsWeakPassword', “$2a$12$GfOja7i1byocYP7XuANk9O”))
保存されているハッシュがステップ3で計算されたものと同じかどうかを検証します($2a$12$GfOja7i1byocYP7XuANk9OqyiE8KJPzG439mk0kZKB1rmggsxOHFu)

これにより、Deviseはパスワードを安全に保存し、データベースが侵害された場合でもさまざまな攻撃からユーザーを保護します。

上記の一連の流れを rails console で実行すると以下のようになります。

irb(main):042:0> user = User.first
  User Load (0.2ms)  SELECT "users".* FROM "users" ORDER BY "users"."id" ASC LIMIT ?  [["LIMIT", 1]]
=> #<User id: 1, email: "foo@example.com", created_at: "2023-08-17 11:27:10.671417000 +0000", updated_at: "2023-08-17 11:32:20.492265000 +0000">
irb(main):043:0> salt = user.encrypted_password[0, 29]
=> "$2a$12$GfOja7i1byocYP7XuANk9O"
irb(main):044:0> BCrypt::Engine.hash_secret('ThisIsWeakPassword', salt) == user.encrypted_password
=> true

pepperに関して

Deviseではデフォルトでpepperは使われていません。pepperとは、Secret Saltとも呼ばれます。 Saltはレコードごとに生成されるランダムな数値ですが、pepperシステム固有の値で、データベースとは別のストレージに保管するべき秘密の文字列です。

使い方は、ユーザが入力した文字列に対してpepperを連結して利用します。それにより、DBの値が第三者に流出してしまった場合でも、ハッシュによる総当たりを防ぐための仕組みで、より安全なパスワード運用を行えます。

Deviseではpepperの部分はデフォルトではコメントアウトされているので利用したい場合はコメントインをする必要があります。

https://github.com/heartcombo/devise/blob/main/lib/generators/templates/devise.rb#L128-L129

DeviseのREADMEでもpepperに関しては殆ど触れられていません。deviseのセットアップドキュメントを見ても殆ど触れられていることはありません。

initializerの設定ファイルを眺めていないと気ずけ無いですが設定しておくことをおすすめします。 Deviseのデフォルトでは、 SecureRandom.hex(64) で生成された値が入ります。

値の例はこのようになります。59ef98ac93a05c22d065dab431e6fc23a8110577c0a18c7e4ac603cdd7f4d2c327e6f6350ef0721de280caadc348c8a3cd04199708e546775627067a2c5d9951

Strechの値の運用

bcryptの計算難易度を調整するパラメータが4年前に 11 から 12 に変更されました。 4年より前に運用しだして、設定ファイルを更新していない場合は 11 になっているので 12 以上に変更することをおすすめします。

https://github.com/heartcombo/devise/blob/main/lib/generators/templates/devise.rb#L126

ベンチマーク

このStrechの値に対して計算コストは指数的に増加します。それにより、1回のパスワード検証コストを多くしてクラックされづらいようにします。

本当に指数的に計算時間が増加するかを検証してみます。

まずは以下のように検証用のコードを書いてみます。20回のハッシュ計算をします。costの値は運用する可能性がある5から15を利用しています。

require 'bcrypt'
require 'benchmark'

results = {}

(5..15).each do |cost|
  results[i] = Benchmark.measure {
    20.times do
      salt = BCrypt::Engine.generate_salt(cost)
      BCrypt::Engine.hash_secret('password', salt)
    end
  }.real
end

results.each do |key, value|
  puts "Cost #{key} (20 iterations): #{value.round(5)} seconds"
end

上記のコードの結果は以下のようになります。

Cost 5 (20 iterations): 0.05674 seconds
Cost 6 (20 iterations): 0.07473 seconds
Cost 7 (20 iterations): 0.14307 seconds
Cost 8 (20 iterations): 0.28359 seconds
Cost 9 (20 iterations): 0.56139 seconds
Cost 10 (20 iterations): 1.12196 seconds
Cost 11 (20 iterations): 2.24226 seconds
Cost 12 (20 iterations): 4.47873 seconds
Cost 13 (20 iterations): 8.95266 seconds
Cost 14 (20 iterations): 18.34221 seconds
Cost 15 (20 iterations): 36.58495 seconds


38.0|
36.0|                               *
34.0|
32.0|
30.0|
28.0|
26.0|
24.0|
22.0|
20.0|
18.0|                            *
16.0|
14.0|
12.0|
10.0|
 8.0|                         *
 6.0|
 4.0|                      *
 2.0|                *  *
 0.0+-*--*--*--*--*-------------------
      5  6  7  8  9 10 11 12 13 14 15

例えば、costが 12 の場合は1回の計算に約0.22秒かかる事がわかり、そこそこ時間がかかります。 (測定環境は、Apple M1 Pro上でDocker上のmruby 3.0.3p157になります)

saltの算出時間は、2×10⁻⁴ 秒程度なので無視できるくらい小さく、costの値に関係なくO(1)になります。

それに付随して、rspecなどの静的テストのときに1回の計算ごとに時間をかけていたらテストの実行時間が長くなってしまうのでDeviseの初期設定ではRails.envが test の際にはcostを 1 で実行してテストの実行時間を短くしています。

config.stretches = Rails.env.test? ? 1 : 10

参考URL

How Devise keeps your Rails app passwords safe
- https://www.freecodecamp.org/news/how-does-devise-keep-your-passwords-safe-d367f6e816eb/

Amazon Linux 2にfishを入れる方法

Fri, 04 Aug 2023 00:00:00 GMT

まとめ

Amazon Linux 2 の yum 経由でインストールされる fish がのバージョンが 2.3 と 7 年前にリリースされたバージョンなので新しいバージョンを利用しようとしました。
簡単にはインストールできなかったので、試行錯誤した結果を掲載しておきます。
結果としては、Cent OS 7 用の rpm パッケージを直接入れるのが一番楽です。
Amazon Linux 2023 へのインストール記事はこちらです。

問題

現在の fish の最新バージョンは 3.6.1 になっています。

それに対して、Amazon Linux 2 で利用している RHEL からインストールされる fish のバージョンは、2.3.1 となっています。これは 2016 年 11 月 8 日にリリースされたバージョンなのでかなり古いです。

(そもそも、Amazon Linux 2 は 2023 年 6 月 30 日までのサポートされないので注意です。)

そこで、tmux のオフィシャルサイトにある rpm パッケージ経由のインストール方法を試してみました。

Amazon Linux 2 の RHEL のバージョンは 7 なので、

[ec2-user@ip-172-26-15-209 ~]$ rpm -E %{rhel}
7

Cent OSの7のrpm repositoryを使ってインストールを試みましたが、glibcの依存関係を満たせないので解決が困難そうです。

yum repositoryを追加してインストールしようとした際のエラーの内容を以下に記載しておきます。

[root@ip-172-26-15-209 ec2-user]# cd /etc/yum.repos.d/
[root@ip-172-26-15-209 yum.repos.d]# wget https://download.opensuse.org/repositories/shells:fish:release:3/CentOS_7/shells:fish:release:3.repo
--2023-08-04 03:00:38--  https://download.opensuse.org/repositories/shells:fish:release:3/CentOS_7/shells:fish:release:3.repo
Resolving download.opensuse.org (download.opensuse.org)... 2001:67c:2178:8::13, 195.135.221.134
Connecting to download.opensuse.org (download.opensuse.org)|2001:67c:2178:8::13|:443...
connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://download.opensuse.org/repositories/shells:fish:release:/3/CentOS_7/shells:fish:release:3.repo [following]
--2023-08-04 03:00:39--  https://download.opensuse.org/repositories/shells:fish:release:/3/CentOS_7/shells:fish:release:3.repo
Reusing existing connection to [download.opensuse.org]:443.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://download.opensuse.org/repositories/shells:fish:/release:/3/CentOS_7/shells:fish:release:3.repo [following]
--2023-08-04 03:00:40--  https://download.opensuse.org/repositories/shells:fish:/release:/3/CentOS_7/shells:fish:release:3.repo
Reusing existing connection to [download.opensuse.org]:443.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://download.opensuse.org/repositories/shells:/fish:/release:/3/CentOS_7/shells:fish:release:3.repo [following]
--2023-08-04 03:00:40--  https://download.opensuse.org/repositories/shells:/fish:/release:/3/CentOS_7/shells:fish:release:3.repo
Reusing existing connection to [download.opensuse.org]:443.
HTTP request sent, awaiting response... 200 OK
Length: 299 [application/x-download]
Saving to: 'shells:fish:release:3.repo'

100%[=====================================================================================================================================================================================================>] 299         --.-K/s   in 0s

2023-08-04 03:00:40 (46.6 MB/s) - 'shells:fish:release:3.repo' saved [299/299]

[root@ip-172-26-15-209 yum.repos.d]# yum install fish
Failed to set locale, defaulting to C
Loaded plugins: etckeeper, extras_suggestions, langpacks, priorities, update-motd
amzn2-core                                                                                                                                                                                                              | 3.7 kB  00:00:00
shells_fish_release_3                                                                                                                                                                                                   | 1.7 kB  00:00:00
Not using downloaded shells_fish_release_3/repomd.xml because it is older than what we have:
  Current   : Sat Jul 29 04:23:36 2023
  Downloaded: Fri Apr 14 08:56:31 2023
290 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package fish.x86_64 0:3.6.1-1.2 will be updated
---> Package fish.x86_64 0:3.6.1-1.5 will be an update
--> Processing Dependency: libc.so.6(GLIBC_2.34)(64bit) for package: fish-3.6.1-1.5.x86_64
--> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.29)(64bit) for package: fish-3.6.1-1.5.x86_64
--> Processing Dependency: libstdc++.so.6(CXXABI_1.3.13)(64bit) for package: fish-3.6.1-1.5.x86_64
--> Processing Dependency: libm.so.6(GLIBC_2.29)(64bit) for package: fish-3.6.1-1.5.x86_64
--> Finished Dependency Resolution
Error: Package: fish-3.6.1-1.5.x86_64 (shells_fish_release_3)
           Requires: libstdc++.so.6(GLIBCXX_3.4.29)(64bit)
Error: Package: fish-3.6.1-1.5.x86_64 (shells_fish_release_3)
           Requires: libc.so.6(GLIBC_2.34)(64bit)
Error: Package: fish-3.6.1-1.5.x86_64 (shells_fish_release_3)
           Requires: libm.so.6(GLIBC_2.29)(64bit)
Error: Package: fish-3.6.1-1.5.x86_64 (shells_fish_release_3)
           Requires: libstdc++.so.6(CXXABI_1.3.13)(64bit)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

また、こちらの記事を見る感じではLinuxにhomebrewを入れてhomebrew経由でfishをインストールすることによって最新のfishがインストールできそうです。しかしながら、fishのためだけにhomebrewをインストールしたくはありません。

色々試行錯誤した結果、fishのオフィシャルサイトが直接提供しているCent OS 7向けのrpmパッケージをインストールしたら比較的すんなりインストールできたので紹介します。

インストール

[ec2-user@ip-172-26-15-209 ~]$ sudo yum install pcre2-devel
Failed to set locale, defaulting to C
Loaded plugins: etckeeper, extras_suggestions, langpacks, priorities, update-motd
amzn2-core                                                                                                                                                                                                                                                                                                                                                                                                                                                              | 3.7 kB  00:00:00
290 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package pcre2-devel.x86_64 0:10.23-11.amzn2.0.1 will be installed
--> Processing Dependency: pcre2-utf32(x86-64) = 10.23-11.amzn2.0.1 for package: pcre2-devel-10.23-11.amzn2.0.1.x86_64
--> Processing Dependency: pcre2-utf16(x86-64) = 10.23-11.amzn2.0.1 for package: pcre2-devel-10.23-11.amzn2.0.1.x86_64
--> Processing Dependency: libpcre2-32.so.0()(64bit) for package: pcre2-devel-10.23-11.amzn2.0.1.x86_64
--> Processing Dependency: libpcre2-16.so.0()(64bit) for package: pcre2-devel-10.23-11.amzn2.0.1.x86_64
--> Running transaction check
---> Package pcre2-utf16.x86_64 0:10.23-11.amzn2.0.1 will be installed
---> Package pcre2-utf32.x86_64 0:10.23-11.amzn2.0.1 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

===============================================================================================================================================================================================================================================================================================================================================================================================================================================================================================
 Package                                                                                                              Arch                                                                                                            Version                                                                                                                        Repository                                                                                                           Size
===============================================================================================================================================================================================================================================================================================================================================================================================================================================================================================
Installing:
 pcre2-devel                                                                                                          x86_64                                                                                                          10.23-11.amzn2.0.1                                                                                                             amzn2-core                                                                                                          547 k
Installing for dependencies:
 pcre2-utf16                                                                                                          x86_64                                                                                                          10.23-11.amzn2.0.1                                                                                                             amzn2-core                                                                                                          192 k
 pcre2-utf32                                                                                                          x86_64                                                                                                          10.23-11.amzn2.0.1                                                                                                             amzn2-core                                                                                                          183 k

Transaction Summary
===============================================================================================================================================================================================================================================================================================================================================================================================================================================================================================
Install  1 Package (+2 Dependent packages)

Total download size: 923 k
Installed size: 2.6 M
Is this ok [y/d/N]: ^Y
Is this ok [y/d/N]: y
Downloading packages:
(1/3): pcre2-devel-10.23-11.amzn2.0.1.x86_64.rpm                                                                                                                                                                                                                                                                                                                                                                                                                        | 547 kB  00:00:00
(2/3): pcre2-utf16-10.23-11.amzn2.0.1.x86_64.rpm                                                                                                                                                                                                                                                                                                                                                                                                                        | 192 kB  00:00:00
(3/3): pcre2-utf32-10.23-11.amzn2.0.1.x86_64.rpm                                                                                                                                                                                                                                                                                                                                                                                                                        | 183 kB  00:00:00
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                                                                                                                                                                                                                                                                                                                                                                          3.1 MB/s | 923 kB  00:00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
etckeeper: pre transaction commit
  Installing : pcre2-utf16-10.23-11.amzn2.0.1.x86_64                                                                                                                                                                                                                                                                                                                                                                                                                                       1/3
  Installing : pcre2-utf32-10.23-11.amzn2.0.1.x86_64                                                                                                                                                                                                                                                                                                                                                                                                                                       2/3
  Installing : pcre2-devel-10.23-11.amzn2.0.1.x86_64                                                                                                                                                                                                                                                                                                                                                                                                                                       3/3
etckeeper: post transaction commit
  Verifying  : pcre2-utf32-10.23-11.amzn2.0.1.x86_64                                                                                                                                                                                                                                                                                                                                                                                                                                       1/3
  Verifying  : pcre2-utf16-10.23-11.amzn2.0.1.x86_64                                                                                                                                                                                                                                                                                                                                                                                                                                       2/3
  Verifying  : pcre2-devel-10.23-11.amzn2.0.1.x86_64                                                                                                                                                                                                                                                                                                                                                                                                                                       3/3

Installed:
  pcre2-devel.x86_64 0:10.23-11.amzn2.0.1

Dependency Installed:
  pcre2-utf16.x86_64 0:10.23-11.amzn2.0.1                                                                                                                                                                                                        pcre2-utf32.x86_64 0:10.23-11.amzn2.0.1

Complete!

[ec2-user@ip-172-26-15-209 ~]$ sudo rpm -Uvh https://download.opensuse.org/repositories/shells:/fish:/release:/3/CentOS_7/x86_64/fish-3.6.1-1.2.x86_64.rpm
Retrieving https://download.opensuse.org/repositories/shells:/fish:/release:/3/CentOS_7/x86_64/fish-3.6.1-1.2.x86_64.rpm
warning: /var/tmp/rpm-tmp.WSduVM: Header V3 RSA/SHA256 Signature, key ID d880c8e4: NOKEY
Preparing...                          ################################# [100%]
Updating / installing...
   1:fish-3.6.1-1.2                   ################################# [100%]
[ec2-user@ip-172-26-15-209 ~]$ which fish
/usr/bin/fish

確認

無事入りました。

[ec2-user@ip-172-26-15-209 ~]$ /usr/bin/fish --version
fish, version 3.6.1

しかしながら、rpm のリポジトリを設定したわけではないので自動更新は行われません。

余談

tmux も最新をインストールしてターミナル関連のバージョンを一新しました。

ついでに、tmux と fish で powerline テーマを使って統一感を出しました。

最新の設定ファイルは以下においてあります。 https://github.com/matsubo/matsu-shell-setting

Ubuntu live patchを導入してみた

Wed, 21 Jun 2023 00:00:00 GMT

Livepatchとは

Livepatchはその名の通り、Ubuntu(Linux系のos)でapt-get upgradeされた時に、kernelパッチを更新するためにーサーバーを再起動せずに適用できます。

Ubuntu Pro向けなのですが、3ホストまでは無料で利用できるので個人利用をする程度ならちょうど良いです。

live patchの仕組みはこちらのページの図がわかりやすいです。

起動中のkernelにパッチを適用するとなると、実行中のメモリの内容を変更することになってしまうけど、どうやっているのか不思議に思っていました。

上記のように、新たなコードを別のメモリに確保した上で、実行コードをすげ替えてしまうというやり方であれば納得です。

デメリットとしては抽象化のオーバーヘッドが増えるのと、パッチを適用していくとメモリのフラグメンテーションや無駄なメモリアロケーションが増える可能性がありそうです。

また、Livepatch自体も万能ではなくてこの用に抽象化された部分の変更でなければkernelの再実行＝OSの再機動が必要になります。詳細

アカウント登録

利用する際に使うtokenはWebサイト上で発行されるのでアカウント登録をしてトークンを取得します。

ユーザ登録後、このページを開くとトークンが表示されます。

設定

Ubuntu 22.04で実行しています。

基本的に、上記のサイトで表示されているコマンドを1発実行すれば完了します。

matsu@dell ~/> sudo pro attach <token>
[sudo] password for matsu: 
Enabling default service esm-apps
Updating package lists
Ubuntu Pro: ESM Apps enabled
Enabling default service esm-infra
Updating package lists
Ubuntu Pro: ESM Infra enabled
Enabling default service livepatch
Installing snapd
Updating package lists
Installing canonical-livepatch snap
Canonical livepatch enabled.
Unable to determine current instance-id
This machine is now attached to 'Ubuntu Pro - free personal subscription'

SERVICE          ENTITLED  STATUS    DESCRIPTION
esm-apps         yes       enabled   Expanded Security Maintenance for Applications
esm-infra        yes       enabled   Expanded Security Maintenance for Infrastructure
livepatch        yes       enabled   Canonical Livepatch service
realtime-kernel  yes       disabled  Ubuntu kernel with PREEMPT_RT patches integrated

NOTICES
Operation in progress: pro attach

Enable services with: pro enable <service>

     Account: matsubokkuri@example.com
Subscription: Ubuntu Pro - free personal subscription

live patchのステータス表示

matsu@dell ~/> sudo ua status
[sudo] password for matsu:
SERVICE          ENTITLED  STATUS    DESCRIPTION
esm-apps         yes       enabled   Expanded Security Maintenance for Applications
esm-infra        yes       enabled   Expanded Security Maintenance for Infrastructure
livepatch        yes       enabled   Canonical Livepatch service
realtime-kernel  yes       disabled  Ubuntu kernel with PREEMPT_RT patches integrated
usg              yes       disabled  Security compliance and audit tools

Enable services with: pro enable <service>

     Account: matsubokkuri@example.com
Subscription: Ubuntu Pro - free personal subscription

livepatchがenabledになっているので設定は完了しているようです。

セキュリティのステータス表示

matsu@dell ~> sudo ua security-status
997 packages installed:
    853 packages from Ubuntu Main/Restricted repository
    101 packages from Ubuntu Universe/Multiverse repository
    25 packages from third parties
    18 packages no longer available for download

To get more information about the packages, run
    pro security-status --help
for a list of available options.

This machine is attached to an Ubuntu Pro subscription.

Main/Restricted packages are receiving security updates from
Ubuntu Pro with 'esm-infra' enabled until 2032.

Universe/Multiverse packages are receiving security updates from
Ubuntu Pro with 'esm-apps' enabled until 2032. You have received 13 security
updates.

考察

この設定が影響しているかどうかわからないのですが、Dockerが調子悪くなりました。。。docker killでコンテナを停止できなくなってしまったりしました。

スタートはできるからまぁ、ギリギリサービスは動くのですが。。。困りものです。

まとめ

kernel関連のzero day attackに対して安全に運用できるようになりました。
仮想環境でサービスを運用しているホストに導入すると再機動の回数を減らせて良いです。

Cloudflare WarpをUbuntuで実行【無料VPN】

Wed, 07 Jun 2023 00:00:00 GMT

概要

Linux のホストで気軽に IPv4 のグローバルアドレスを変えたかったので Cloudflare の warp を使ってみました。
Ubuntu だと簡単に導入、接続できました。無料です。
Cloudflareのドキュメントではデスクトップ用(GUI)のアプリしか提供指定なさそうですが実際にはCLIによるプログラムが提供されます。

インストール

こちらの手順通りで大丈夫でした。

GPG を登録

$ curl https://pkg.cloudflareclient.com/pubkey.gpg | sudo gpg --yes --dearmor --output /usr/share/keyrings/cloudflare-warp-archive-keyring.gpg

apt sourceを追加

$ echo "deb [arch=amd64 signed-by=/usr/share/keyrings/cloudflare-warp-archive-keyring.gpg] https://pkg.cloudflareclient.com/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/cloudflare-client.list

$ sudo apt update
$ sudo apt install warp-cli

設定

$ warp-cli register
$ warp-cli connect

Warpで接続できているかを検証するためのコマンドがこちらです。 warp=on になっていれば成功です。

% curl -s https://www.cloudflare.com/cdn-cgi/trace/|grep warp
warp=on

IPv4とIPv6のアドレスで外に出ていけます。すばらしいです。

$ curl -4 https://kakunin.teraren.com
104.28.211.105
$ curl -6 https://kakunin.teraren.com
2a09:bac1:3b20:10::16:xxxx

切断するときのコマンドはこちら。リモートで接続している場合は切断される場合があるのでご注意ください。

$ warp-cli disconnect

その他

統計を出力する場合はこんな感じ。

$ warp-cli warp-stats
Endpoints: 0.0.0.0, 2606:4700:d0::a29f:xxxx
Time since last handshake: 43s
Sent: 305.1MB; Received: 84.5MB
Estimated latency: 12ms
Estimated loss: 0.00%;

回線のベンチマークもしてみます。遅い無料のOpen Proxyに比べれば十分です。

$ speedtest-cli
Retrieving speedtest.net configuration...
Testing from Cloudflare (104.28.211.105)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Alyans Telekom (Vladivostok) [9716.25 km]: 273.563 ms
Testing download speed................................................................................
Download: 9.12 Mbit/s
Testing upload speed......................................................................................................
Upload: 18.09 Mbit/s

ルートの設定も行えるオプションがあるので細かいトラフィックの制御も行えそうです。

matsu@dell:~$ warp-cli help
CLI to the WARP service daemon

Usage: warp-cli [OPTIONS] <COMMAND>

Commands:
  register                     Register with the WARP API, replacing any existing registration (Must be run before first connection!)
  teams-enroll                 Enroll with Cloudflare for Teams
  delete                       Delete current registration
  rotate-keys                  Generate a new key-pair, keeping the current registration
  status                       Ask the daemon to send the current status
  warp-stats                   Retrieve the stats for the current WARP connection
  warp-dns-stats               Retrieve the DNS stats for the current WARP connection
  settings                     Retrieve the current application settings
  connect                      Connect to WARP whenever possible [aliases: enable-always-on]
  disconnect                   Disconnect from WARP [aliases: disable-always-on]
  disable-wifi                 Automatically disable WARP on Wi-Fi networks (disabled for Zero Trust customers)
  enable-wifi                  Allow WARP on Wi-Fi networks (disabled for Zero Trust customers)
  disable-ethernet             Automatically disable WARP on ethernet networks (disabled for Zero Trust customers)
  enable-ethernet              Allow WARP on ethernet networks (disabled for Zero Trust customers)
  add-trusted-ssid             Add a trusted Wi-Fi network for which WARP will be automatically disconnected
  remove-trusted-ssid          Remove a trusted Wi-Fi network
  exclude-private-ips          Exclude private IP ranges from tunnel
  enable-dns-log               Enable DNS logging (Use with the -l option)
  disable-dns-log              Disable DNS logging
  account                      Display the account associated with the current registration
  devices                      Display the list of devices associated with the current registration
  network                      Display the current network information
  get-virtual-networks         List the available virtual networks
  set-virtual-network          Set the currently connected virtual network via the id from get-virtual-networks
  set-mode                     Set the mode
  set-families-mode            Set the families mode
  set-license                  Attach the current registration to a different account using a license key
  set-gateway                  Force the app to use the specified Gateway ID for DNS queries
  clear-gateway                Clear the Gateway ID
  set-custom-endpoint          Force the client to connect to the specified IP:PORT endpoint (Zero Trust customers must run this command as a privileged user)
  clear-custom-endpoint        Remove the custom endpoint setting
  add-excluded-route           Add an excluded IP
  remove-excluded-route        Remove an excluded IP
  get-excluded-routes          Get the list of excluded routes
  get-included-routes          Get the list of included routes
  get-excluded-hosts           Get the list of excluded hosts
  get-included-hosts           Get the list of included hosts
  add-excluded-host            Add an excluded host
  remove-excluded-host         Remove an excluded host
  add-fallback-domain          Add a domain that should be resolved with the fallback resolver instead of WARP's
  remove-fallback-domain       Stop a domain from being resolved with the fallback resolver
  get-fallback-domains         Get the list of domains that go to the fallback resolver
  restore-fallback-domains     Restore the list of fallback resolver domains to its default value
  get-device-posture           Get the current device posture
  override                     Temporarily override MDM policies that require the client to stay enabled
  set-proxy-port               Set the listening port for WARP proxy (127.0.0.1:{port})
  is-mode-switch-allowed       Outputs true if Teams users should be able to change connection mode, or false if not
  reset-settings               Restore settings to default
  get-organization             Get the name of the Teams organization currently in settings
  access-reauth                Force refresh authentication with Cloudflare Access
  get-support-url              Get the support url for the current Teams organization
  get-pause-end                Retrieve the pause end time
  get-override-end             Retrieve the admin override end time
  disable-connectivity-checks  Disable the runtime connectivity checks
  enable-connectivity-checks   Enable the runtime connectivity checks
  dump-excluded-routes         Get split tunnel routing dump. For include-only mode, this shows routes NOT included
  get-alternate-network        Get the name of the currently detected alternate network, if any
  get-dex-data                 Get the most recently uploaded DEX data. Returns the most recent test for each dex metric
  help                         Print this message or the help of the given subcommand(s)

Options:
  -l, --listen      Listen for status changes and DNS logs (if enabled)
      --accept-tos  Accept the Terms of Service agreement
  -v, --verbose...  Enable verbose output. Multiple "v"s adds more verbosity
  -h, --help        Print help
  -V, --version     Print version

まとめ

Cloudflare の warp を使えば無料で簡単に VPN 経由でインターネットに接続できます。

CloudWatchのlog insightでjsonデータに対してのフィルタ例

Wed, 31 May 2023 00:00:00 GMT

概要

AWS の CloudWatch Logs にアプリケーションログを蓄積しています。
データの messege の中身が JSON 形式であれば、特定のキーに対してフィルタをかけられます。
しかしながら、クエリーが DSL なので毎回マニュアルを参照したりするのが面倒なのでメモを残しておきます。

クエリーの例

アプリケーションのログが JSON で保存されているときの調査サンプル

filter @logStream like 'app/app/'
| filter @message like /include/
| filter @message not like /exclude/
| filter duration > 100
 | fields @timestamp, @message, duration

Dockerを使ってHTTP3対応のnginxでホスティングする手順

Wed, 31 May 2023 00:00:00 GMT

概要

HTTP3 に対応したサイトが全世界のウェブサイトの中で25％あるらしいです。

nginx の roadmap 上では、3 年前から HTTP3 が入っているのに 2023 年 2 月 11 日現在ではまだ stableでのリリースは行われていません。

HTTP3 を簡単に試してみるツール類は揃ってきているので今回は、HTTP3 対応の nginx を使ってどんな感じの運ようになるかをテストしてみます。

設定

前提

nginx をリバースプロキシとして動かし、バックエンドとして localhost の 3005 番ポートで Ruby on Rails サービスが動いているという前提です。

nginx には let’s encrypt で取得した TLS 証明書を使って HTTPS で接続しています。

今回の対象サイト: https://train.teraren.com/

サーバサイドの設定

HTTP3 のデフォルトは UDP の 443 番ポートを使います。もちろん 443 番はデフォルトなだけであるので任意のポートも利用できます。

とりあえず、以下のようなコマンドを打ち込んでみて localhost にて UDP の 443 ポートが使われていないことを確認します。

% netstat -ln | grep 443 | grep udp

次に、以下のような設定ファイルを作成します。

https://gist.github.com/matsubo/735eaf0bde87e8a89e6a55e8980cb03c#file-docker-compose-yml

設定ファイルの内容は適宜変更してください。TLS証明書のファイルの場所、ドキュメントrootの場所を適宜変更します。

proxy_passに指定するバックエンドのサービスのホスト名は、docker container内から参照できるIPアドレスまたはホスト名にする必要があります。ここで、localhostと指定してもコンテナ自体のホストを指すことになってしまいますので注意してください。

そして、docker composeで立ち上げればOKです。let’s encryptのファイルの読み込みにはroot権限が必要になりますが、docker自体がroot権限で実行されるようなので一般ユーザで起動してもちゃんと読み込めてます。

% docker compose up

これで立ち上がります。

これで、1つのバックエンドサービスに対して2つのWebサーバが立ち上がっている状態になります。1つは元から動いているnginx、2つ目は今回立ち上げたHTTP3対応nginxです。

最後に、外部から接続できるようにfirewallやパケットフィルタの設定などでUDP 443への接続を許可します。

接続テスト

ブラウザ上ではhttp2もhttp3も同じURLになります。後述するalt-svcヘッダを出力する設定を元のnginx側で出力するようにする設定が必要になります（後述）

よって、まずはCLIを使ってテストしてみます。

% docker run -it --rm ghcr.io/unasuke/curl-http3:quiche-latest curl -IL https://train.teraren.com/ --http3

正常な結果

もし、HTTP3のnginxの設定が間違っていた場合は500系のエラーが返ってきます。

500系のエラー

HTTP3のnginxを立ち上げたdocker composeの標準出力にアクセスログやエラーが表示されるのでその内容をチェックすれば良いと思います。

HTTP3に対応していることをブラウザへ　告知

現時点でブラウザは、httpsスキーマが指定されたらTCP 443番に対してTLSを使って接続し、HTTP 2.0などのアプリケーションプロトコルを使って接続を試みます。

この状態では、ウェブサイトがHTTP3に対応しているかどうかわかりません。なので、このTCPで接続した際にHTTP3に対応していることをHTTPヘッダのレスポンスで返します。

以下の設定をTCPで運用している元のnginxに追加します。これにより、ブラウザはHTTP3でのサービス提供が行われているサイトということを認識できます。

add_header alt-svc 'h3=":443"; ma=3600';

外部のチェッカー

何故かエラーになる。。。(追記: 今は Cloudflare に載せ替えたのでエラーになりません)

https://http3check.net/?host=https%3A%2F%2Ftrain.teraren.com%2F

余談

自分の使っているブラウザが HTTP3 に対応しているかどうかは以下のサイトなどでチェックできます。

https://cloudflare-quic.com/

手元の Brave ブラウザではなぜか HTTP3 での接続が行われない状態でした。

まとめ

HTTP3 用 nginx を立ち上げると、同じような設定を 2 箇所で管理しないといけないので面倒です。早く stable で HTTP3 を対応してほしいです。
すでに let’s encrypt で証明書を取得している場合は簡単に HTTP3 を試せます。

GitHubでmerge後にブランチを自動削除すべきか：設定の判断基準

Wed, 31 May 2023 00:00:00 GMT

概要

GitHub のリポジトリ運用において「Automatically delete head branches」を on にするか off にするか悩ましいところです。

デフォルトは off です。

GPTに聞いてみた

Q: GitHub の repository の設定にある、 “Automatically delete head branches” を on にするか off にするか悩んでます。どちらのほうが一般的でしょうか？

A:「Automatically delete head branches」の設定は、プルリクエストがマージされた後に、そのブランチを自動的に削除する機能です。この設定をオンにするかオフにするかは、チームやプロジェクトのワークフローと好みによって異なります。しかし、一般的な考え方をいくつか紹介します。

オンにする利点:

リポジトリがきれいに保たれる: 不要なブランチが自動的に削除されるため、リポジトリが整理されやすくなります。
ブランチの管理が楽になる: 作業が完了したブランチを手動で削除する必要がなくなり、メンテナンスが容易になります。

オフにする利点:

履歴の追跡: ブランチが削除されないため、過去の変更履歴を容易に確認できます。
再利用可能: 削除されないため、同じブランチを再利用して追加の変更ができます。

一般的には、プルリクエストがマージされた後にブランチを自動的に削除してリポジトリを整理しやすくするため、この機能をオンにすることが多いです。しかし、過去の変更履歴を追跡したい場合や、ブランチを再利用する必要がある場合はオフにすることもあります。

最終的には、チームやプロジェクトの要件に基づいて判断してください。機能を試してみて、適切な設定を見つけるのも良い方法です。

Followerさんに聞いてみた

https://twitter.com/matsubokkuri/status/1679414967400013824

on にしている人が多いです。

考察

GPT が回答した論点に関しては、すでに自分の中で考えていた論点と全く同じでした。

GPT の回答から新たに得たインサイトとしては、onにしている方が多いという情報です。

私の主張

ちなみに私は残しておく派。

tig で見たときにブランチの目的が追いやすいから。

そして、やっっぱり remote に push した情報って消しちゃいけないと思うんですよ。他の誰かが tracking しているかもしれないのでブランチが消えると追いづらくなってしまいます。

容量は食わないし、見づらくなるぐらいのデメリットぐらいしか無いので、どんどん stock していくのが根本かなと思います。

もし、ブランチ名を消す運用をしていて、再度同じブランチ名で別の feature branch を作り出したときに URI の指す中身が違ってしまうというのもあるからブランチ名はリポジトリーに対してユニークになっていることも重要です。

妥協点の模索

ブランチを残すことも、消すこともそれぞれメリットとデメリットがあります。それぞれの良いとこ取りをするための手法として、ある程度時間が経過したブランチの重要性は下がるので古いブランチは消すという運用が考えられます。

こちらのGithub Actiions を使えば上記の運用ができます。

手元のリポジトリで運用して居る設定を記載しておきます。一年間残しておいて、tag は自動で消さないようにしてあります。

name: Cleanup old branches
on:
  push:
    branches:
      - master
jobs:
  housekeeping:
    name: Cleanup old branches
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v2
      - name: Run delete-old-branches-action
        uses: beatlabs/delete-old-branches-action@v0.0.10
        with:
          repo_token: ${{ github.token }}
          date: '6 months ago'
          dry_run: false
          delete_tags: false
          minimum_tags: 5
          extra_protected_branch_regex: ^(foo|bar)$
          extra_protected_tag_regex: '^v.*'
          exclude_open_pr_branches: true

知的労働者のための究極のフルリモート環境構築例

Wed, 31 May 2023 00:00:00 GMT

3行まとめ

機材に 60 万円。部屋のリフォームに 50 万円ほどかけて家の作業環境を整えました。
機材だけではなく、作業環境に関するノウハウも紹介します。
機材は成功に行き着くまでに何回も買い直しした結果の良いものを紹介します。

どんな人のための記事？

在宅での PC 作業効率を上げたい人
テレカンにおいて自分のカメラ写りを良くする方法。
肩こり、目の疲れ、などの体の疲労を改善したい人

概要

知的労働者にとって作業環境は重要です。

良い機材にはお金をかけても効率が上がればすぐに回収できます。早く買えば、利用した日数で金額を割ると日割り金額が低く済みます。

私がトライアンドエラーしてたどり着いたデスク環境 を紹介するので参考にしていただければと思います。

身体に触れる部分である、デスク、チェア、モニタ（視覚的に）には良いものを使う事によって肉体疲労が軽減されるので最重要部分です。

ユースケース定義

自分にとってベストなデスク環境を考えるために、デスクで何をするかを考えます。何をするにもベストな環境を目指すのは間違いです。何でもできるは何もできないです。目的をはっきりさせましょう。

私の場合は以下です。

仕事: プログラミング、設計図書く、文書を書く、音楽を聞く、テレカンをする、写真のレタッチ。
趣味: 電子工作

主に PC を使った業務、趣味です。

要求定義

上記のユースケースを実現するための要求は以下になります。

電動の昇降機能付きデスク
音質が良いスピーカー
ノイズが少なくて指向性のあるマイク
良い感じの Web カメラ
長時間座っても疲れにくい椅子
長時間使っても疲れないモニター。解像度が高いも煮た。モニタに光が反射しない環境。

環境の説明

上記の要求を満たすための私なりの解を紹介します。たくさんあるので、物理的に大きい順で紹介します。

モニタ

使っているのは、Dell U シリーズ U4021QW 39.7 インチワイドモニタ－

過去 15 年ぐらいは EIZO のモニタを使い続けていたのですが乗り換えました。乗り換える決断をした理由は 2 点あります。

（1）高額: カタログスペックでは表せない性能があるので高額なのは良いのですが、高額過ぎます。カタログスペックで等々の品と比べると 2 倍位する印象です。

2. カタログスペック性能が低い: 他社のモニタの大きさや解像度の高さに追随するようなメインのスペックから見ると液晶パネルの性能が低くて見劣りしてました。

使用した結果、満足度は高いです。コントラストは高く、チラツキが無く、ドット欠けは無し、EIZO から乗り換えても特に違和感はありませんでした。湾曲に関しても最初はちょっと違和感がありましたが、すぐに慣れました。逆にこのぐらい大きいと湾曲していないと端が見えないと思います。

購入したのが 2021 年 4 月なので 2 年前です。2023 年 5 月の現在は 49 インチの U4919DWのほうも検討に上がります。解像度は私が買った40インチと同じなのでDPIが低いです。視力が低めであればこちらのほうが良いかもです。

以前、EIZO のモニタを 2 週間レンタルできる機会があったから、借りてみました。そして、会社から貸与されていた IIYAMA のモニタ（安いやつ）と EIZO のモニタを比較したら目の疲労具合が全然違いました。

このクラスの DELL のモニタも長時間使っても目の疲れはあんまりありません。

https://www.amazon.co.jp/dp/B08TBJ4YTM?tag=matsubo0e-22&linkCode=ogi&th=1&psc=1

デスク

FlexispotのE7Bに朝日ウッドテックのブラックウォルナット天板の組み合わせです。

フレーム

まず、スタンディングデスクを選ぶ理由は以下の記事を読んでいただければと思います。

まず、デスクについてですが、絶対電動が良いです。手動のハンドルだと上下するのに時間がかかるのでほとんど動かさなくなります。それも、座った状態に固定されます。買った当初は頑張って立つようにしてますが、しばらくすると 1 日じゅう立ちっぱなしはそれはそれで疲れるので座った状態にして固定化されます。

昇降範囲は 58-123cm ですが、特に下限や上限に不満はありませんでした。もっと高額なフレームは少広範囲が広かったのでちょっと迷ったのですがこの商品で問題ありませんでした。身長は 178cm です。

https://www.amazon.co.jp/dp/B08F7MQL3S?tag=matsubo0e-22&linkCode=ogi&th=1&psc=1

天板

朝日ウッドテックのブラックウォルナットです。集成材の天板だけで10万円(送料・税込)しました。別のリフォームの流れで発注してしまったのですが、今となってはオンラインで注文したほうが良かったなと若干後悔しております。

朝日ウッドテックは一流メーカーですので失敗は無いです。保証もしっかりしています。当時、カウンター板のトラブル事例を見ていると不安になったという点も多少あります（しかし、使っていれば傷や凹みは付くのであんまり気にしなくてよかったです）

とにかく、肌に触れるところには質感は重視したほうが良いです。プラスチックとか樹脂のデスクですと反発が強すぎて腕を置いていると赤くなったりマウスタコができたりします。木材であればそのようなことは無くなりました。

オンラインですと幅はぎ(100mm)で9万円ほどで買えます。

無垢材の1枚板を検討しましたが重量が重くなるのと、使用環境によっては反りや割れが発生するらしくてメンテナンスが難しそうなのでやめました。かっこいいんですけど、作業用デスクには見た目的にもちょっとやりすぎ感もあるかなと思いました。中古の1枚ものはヤフオクで結構安く売られています。

チェア

社会人 3 年目にハーマンミラーの Embody chair購入してそれからずっと職場で使っています。職場が変われば、Embody Chair を自費で赤帽を使って輸送して使っています。

当時は肩こりが酷くてそれを緩和させたくて買いました。フィッティングの柔軟性が非常に高く、疲れた体の部位に負荷をかけないように微調整できるのが良いです。疲れたときにはそのままリクライニングにして寝っ転がる感じにもなれます。

チェアを買うときに、アーロンチェアか Embody Chair にするか迷いましたが、Embody Chair のほうが上位っぽかったので決めました。

今となっては新品が 25 万円ぐらいしますが 17 年前は 20 万円弱でした。現地では 10 万円ちょっとで売られていたのでアメリカから新品を個人輸入してトータル 15 万円ぐらいで手に入れました。

https://www.amazon.co.jp/dp/B004HW814E?tag=matsubo0e-22&linkCode=ogi&th=1&psc=1

メイン照明

作業環境の観点と、テレカンの写りの観点で照明はとても重要です。このためにリフォームを業者に発注しました。

照明の重要さについて書かれている記事を載せておきます。

まず、液晶モニタに反射を作る原因は強い光源なので外光をあまり取り入れないようにして昼夜問わず安定した照明環境を作ることを基本としました。外光の取り入れに関しては、自然の生活をするためには外光を取り入れたほうが良いとは思いますが外光の変化によって「あぁ、雨が振ってきたなぁ」とか「天気が悪いなぁ」といった集中力を削ぐ要因を排除する目的もあります。たぶん、自律神経に影響すると思いますが、朝に散歩をして太陽光を浴びたりしてカバーします。

その上で、昼は白色、夜は暖色にしたかったので、ちょうど Panasonic から調色の LED 電気が発売されたので導入しました。

テレカン時に顔への照明をまんべんなく当てるために間接照明を導入しました。以前、テレカンのときだけ顔用に照明を使ったりしていましたが、スイッチを入れるのが面倒だし照明が眩しいのですぐに使わなくなりました。

部屋の照明を間接照明へするために、シーリングライトのコネクタを撤去してリフォーム業者に依頼してコープ照明にリフォームしました。

利用したのは ARCHITECTURAL LIGHT L=1200 (YYY21260LB1)です。4 つ設置しました。

調色を重視しているのであんまり発色は良くないのが残念です。設置直後は綺麗に発色していた気はしますが、最近はなんかほんの少し緑っぽさが出てきた気がしてます。

背景(バックスクリーン)

Web カメラ（普通の安いカメラも）の特性で、明るさ（露出）は写っている全体の光量を元に明るさを決めています。一般的には壁紙は白いので、白い壁紙の前で顔を写すと顔が相対的に暗くなります。それを防ぐためには背景を顔より暗い明度にするのが良いです。

極端に言えば、黒い壁紙にすれば自分の顔がすごい白く写ります。

そこで、ダークグレーのロールスクリーンを設置して背景を作りました。幅をぴったりに作りたかったのでオーダーで注文しました。

TOSO のプレートというシリーズです。4万円ぐらいしました。

同じ照明の下で、背景の違いによる顔の印象を検証するために iPhone 13 Pro でサンプルを撮影してみました。無補正です。右の方が顔に影ができてしまっているし全体的に暗い印象になってしまっていますが、左側は白く明るい印象に写っています（iPhone 13 だと頭が良すぎてフォーカスが当たっているところの露出を基準にしちゃっているのであまり顕著には差が出ませんが）

明度の低い背景

明度の高い背景

スポット照明

資材が余ったのでデスクの上にダクトレールを設置して、暖色の LED スポットライトを付けてみました。間接照明だけだと暗すぎるかと思ったので保険として用意しましたが、まったく使っておりません。

スピーカー

3 回スピーカーを買い替えた結果、GENELECの8020シリーズを使っています。めちゃくちゃ満足度は高いです。もう、これは騙されたと思って買ってみてほしいです。

最適なスピーカーは部屋の大きさや、スピーカーまでの距離、スタンドの材質などによって変わるので環境の制約に合ったものを選ぶ必要があったのでここに行き着くまでが大変でした。

大きくて高額なものを買えば安心というモノではないです。

スピーカーが良ければテレカンにおいて、聞こえづらい部分とかも少しは明瞭になりますし、相手の声も聞き取りやすくなるので披露が軽減されます。

スピーカー選定時の試行錯誤はこちらの記事にまとめてあります。

マイク

HyperX QuadCast です。YouTuber がおすすめしていたので買いました。

以前は、中華メーカーのUSBのコンデンサマイクを使っていたのですがノイズが酷かったです。マイクなんてどこも大して変わらないだろうと思っていましたが、ちゃんとしたメーカーのマイクを使う必要があると感じました。

スピーカーの音をマイクが拾わないようにするために、マイクは指向性があったほうが良いです。

あと、結果的に良かったのは普通のハンドマイクを使うより、直立していたほうがスペースを取らなくて良いです。どうしてもマイクは顔の近くに置く必要があるため邪魔にならない形状である必要があります。

物理的に mute/unmute ができるものだと楽です。ソフトウェア上で mute/unmute をするとなると直感的ではないしすぐに操作したいときに困ります。

https://www.amazon.co.jp/dp/B07NZZZ746?tag=matsubo0e-22&linkCode=ogi&th=1&psc=1

キーボード

以前は、HHKB Professional HYBRID Type-S無刻印／墨（英語配列）を使っていました。

会社と自宅で同じキーボードを使いたかったので安価で良いものを探した結果、EPOMAKER CIDOO V75にしました。打鍵感、打鍵音、キーピッチ、PBT キーキャップ、ガスケットマウントととても良い感じです。

オフィスで使うには、少しタイピング音が大きいので会社用のは EPOMAKER Sea Salt 静音メカニカルスイッチに変更しています。

マウス

トラックボールを試しに使ってます。まぁ、普通のマウスでもどっちでも大丈夫です。唯一の欠点は曲線が書きづらいのと、トラックボールを定期的に掃除しないと動きが悪くなるということです。

https://www.amazon.co.jp/dp/B074Z71C2M?tag=matsubo0e-22&linkCode=ogi&th=1&psc=1

ケーブル収納

サンワサプライのケーブル収納するやつ。めちゃくちゃキレイに収納できるのでおすすめです。

この収納トレーは、ERD シリーズ専ようになっていてナットで天板に裏からビス止めできます。そのため、クランプ型だとどうしてもデスクに引っ掛ける部分が必要になりますが、こちらはデスク上には一切干渉しないです。その代わり、天板に穴あけ加工が必要になります。

ネジの規格は M5 x 12mm になるので、穴側は、鬼目ナット側 M5x10mm、下穴は7.5mmのビットで穴あけをしました。天板を外して作業したので2時間ぐらいかかりました。初期設置時にやっておくべきでした。

以前は以下のような網のラックを使っていたのですが、クランプが卓上に見えてしまうのとケーブルが多くて収まりきらないし、ケーブル自体が見えてしまうので見た目が良くないです。

電源タップはこちらです。スピーカーそれぞれ、Google Home, モニタ、デスク裏の LED 照明に電源が必要なので結構コンセントを使うので 10 口ぐらいは必要です。

https://www.amazon.co.jp/dp/B0877666H6?tag=matsubo0e-22&linkCode=ogi&th=1&psc=1

デスクLED照明

Wi-Fi に接続してコントロールできるフルカラーLED テープを貼り付けています。

作業中は緑色にすることで緑視率を上げることによる集中力向上を狙っています。

この LED テープの密度が低いので普通に貼ったら斑（まだら）になってしまいました。そこで、ピッチが異なるように上と下になるように 2 重に貼り付けたらドットが見えなくなってきれいに発色するようになりました。高さ違い、ピッチ違いなので影ができづらくなり、面で発光しているように見えます。

スマートホームと連携して、始業時間に点灯して深夜に消灯するルーチーンを設定しています。

音に反応した照明でクラブっぽい演出もできます。電気信号でのコントロールではなく、音量を計測して発行しているので遅延が大きくて違和感があります。

https://www.youtube.com/watch?v=_d5A_hF68Wk

https://www.amazon.co.jp/dp/B087339YX8?tag=matsubo0e-22&linkCode=ogi&th=1&psc=1

USBカメラ

Web でしか使わないので特にこだわりは無いです。オートフォーカスがついているし小さいので不満は無いです。この商品はティルト調整が良いです。

https://www.amazon.co.jp/dp/B07QQR6G5N?tag=matsubo0e-22&linkCode=ogi&th=1&psc=1

USB DAC

USB-DAC は過去に 3 回書い直してます。無名なメーカーの USB-DAC は数ヶ月〜数年使っていると調子が悪くなってきます。PC に認識されなくなったり、左右の音色の差が出てきたりしました。

この商品は口コミ数が多くて安心できそうなので買いました。低音と高音のエコライザがついているので多少音色の調整をアンプ側で変更できます。

1 年ぐらい問題なく運用できています。

https://www.amazon.co.jp/dp/B07VDQQY95?tag=matsubo0e-22&linkCode=ogi&th=1&psc=1

USBハブ

モニタについている USB-A ポートだけでは足りないので増設しています。USB セキュリティキー(Titan Security Key)を抜き差しするときに、USBポートが手元にあったほうが楽なのでUSB-DACの上に両面テープで貼り付けています。

https://www.amazon.co.jp/dp/B07ST84PF5?tag=matsubo0e-22&linkCode=ogi&th=1&psc=1

PCスタンド

隙間の幅をネジで調整できるのでピッタリハマるように設定できます。

https://amzn.to/3C0Atz7

Google Nest mini

Nest になってから小さいけど音質がかなり向上したので適当な BGM を流すのに使ってます。

壁のリフォーム

夏の高多湿、冬の低湿度は日本に居るとかなり問題です。これを少しでも緩和するためにエコカラットを壁に貼り付けました。賃貸の場合は難しいですが、分譲の場合は簡単にできるので DIY すると楽しいと思います。

シーンに応じた照明

夜間の照明例

夜はブルーライトをカットしたほうが睡眠の質が高くなるので暖色で統一できるようにしました。

暖色のスポットライトを点灯し、デスク裏の LED テープライトを黄色に点灯した状態。

Cyberpunkぽい例

デスクの LED テープライトのみを点灯しただけ。ブラックライトに近い光り方をします。目が疲れます。

Railsにおいてユーザがプラットフォーム(多対多)となるシステムを作るときの権限モデルを設計

Wed, 31 May 2023 00:00:00 GMT

概要

Ruby on Rails における複雑な認可の設計と実装するための一例を紹介する。

背景

手元で作っている Rails の B2B サービスの権限に関連する要件が複雑化してきたので、権限モデルをちょっと整理する。

権限が複雑になる原因は、アクターや操作対象といった権限に関するメトリックが多くなること。要件レベルでどれだけメトリックを減らせるかが重要。

ビジネスで利用するサービスの場合、細かい権限設定が要求されるのでメトリックが増えやすい。

今回扱わなければいけないメトリックは以下

アクター種別
ロール種別
ステータス遷移
Web or API による操作

問題

メトリックが 3 つ以上になった時点で直交表が作成できなくなってしまうため、権限表を作るのが難しくなる。

メトリックが 3 つであれば、直交表を複数作ればギリギリ対応できる
4 つになると表現が厳しい。そもそも理解、暗記、比較も困難。

例えば、Web から操作できる内容と API からできる操作を同様にすることによってメトリックを 1 つ減らせる。

この権限に関する問題は、システム上で表現は可能だしテストケースも作成して担保できる。しかしながら、人間が理解する時や説明するときに困難。

また、細かい要件定義を繰り返してミクロな議論によって実装要件を決めていくといつの間にか複雑に陥っているケースが多い。技術的負債とはまさにこのことである。

理想

あるべき論は以下のスライドに書いてあるとおりと考える。

しかしながら既存のワークフローを DX してリプレースをかける場合はすでに複雑な要件が決まっていたりするので要件を単純化する余地が少なかったりもする。

どの程度の複雑性になったら複雑と呼べるのか、複雑さを表現するための評価軸を持っておく必要がある。

アプローチ

クリーンアーキテクチャのレイヤと比較して、このような感じで考える。これ以上メトリックが増える場合は、独自にビジネスロジックのレイヤーを追加するなりして対応する必要がある。

背景にあるメトリックを管理するために、Rails にて利用したミドルウェアとスタックを図にまとめた。

AASM によるステータス遷移
ロールごとに pundit で管理
- API 用、アクターごとに設定を用意する

このように図に整理するとどうやって権限を整理するときれいにできるかが見えてくる。 pundit の設定ファイルごとにまとめることによって権限はきれいに表現できそうということがわかる。

まとめ

Rails のシステムにおいて認可をまとめるには以下のようにまとめるのが良さそう。

AASM ではビジネスロジックのステータス遷移についてまとめる
アクターやアクセスする手段ごとに pundit を用意して pundit の設定ファイルごとに権限表を作成

知的労働者のための究極のホームオフィス環境ガイド

Mon, 29 May 2023 00:00:00 GMT

概要

知的労働者にとって作業環境は重要です。

良い機材にはお金をかけても効率が上がればすぐに回収できます。早く買えば、利用した日数で金額を割ると日割り金額が低く済みます。

ということで、私がトライアンドエラーしてたどり着いたデスク環境を紹介するので参考にしていただければと思います。

身体に触れる部分である、デスク、チェアー、モニタ（視覚的に）には良いものを使いたいという思いが強いです。

ユースケース定義

デスクで何をするかを考えます。

仕事: プログラミング、設計図書く、文書を書く、音楽を聞く、テレカンをする、写真のレタッチ。
趣味: 電子工作

要求定義

上記のユースケースを実現するための要求は以下になります。

電動の昇降機能付きデスク
音質が良いスピーカー
ノイズが少なくて指向性のあるマイク
良い感じのWebカメラ
長時間座っても疲れにくい椅子
長時間使っても疲れないモニター。解像度が高いモニタ。モニタに光が反射しない環境。

環境の説明

上記の要求を満たすための私なりの解である環境を紹介します。物理的に大きい順で紹介します。

モニタ

使っているのはこちらです。

Dell Uシリーズ U4021QW 39.7インチワイドモニター

過去15年ぐらいはEIZOのモニタを使い続けていたのですが乗り換えました。乗り換える決断をした理由は2点あります。

1．高額: カタログスペックでは表せない性能があるので高額なのは良いのですが、高額過ぎます。カタログスペックで同等の品と比べると2倍位する印象です。

使用した結果、満足度は高いです。コントラストは高く、チラツキが無く、ドット欠けは無し、EIZOから乗り換えても特に違和感はありませんでした。湾曲に関しても最初はちょっと違和感がありましたが、すぐに慣れました。逆にこのぐらい大きいと湾曲していないと端が見えないと思います。

購入したのが2021年4月なので2年前です。2023年5月の現在は49インチのU4919DWのほうも検討に上がります。解像度は私が買った40インチと同じなのでDPIが低いです。視力が低めであればこちらのほうが良いかもです。

以前、EIZOのモニタを2週間レンタルできる機会があったから、借りてみました。そして、会社から貸与されていたIIYAMAのモニタ（安いやつ）とEIZOのモニタを比較したら目の疲労具合が全然違いました。

このクラスのDELLのモニタも長時間使っても目の疲れはあんまりありません。

::amazon{asin="B08TBJ4YTM"}

デスク

FlexispotのE7Bに朝日ウッドテックのブラックウォルナット天板の組み合わせです。

フレーム

まず、スタンディングデスクを選ぶ理由は以下の記事を読んでいただければと思います。

https://gigazine.net/news/20141225-sitting-problem/

https://sukimaput.com/bauhutte-standingdesk/

まず、デスクについてですが、絶対電動が良いです。手動のハンドルだと上下するのにめちゃくちゃ時間がかかるのでほとんど動かさなくなります。それも、座った状態に固定されます。買った当初は頑張って立つようにしてますが、しばらくすると1日じゅう立ちっぱなしはそれはそれで疲れるので座った状態にして、ずっとそのままになります。

昇降範囲は58-123cmですが、特に下限や上限に不満はありませんでした。もっと高額なフレームは昇降範囲が広かったのでちょっと迷ったのですがこの商品で問題ありませんでした。身長は178cmです。

::amazon{asin="B08F7MQL3S"}

天板

朝日ウッドテックは一流メーカーですので失敗は無いです。保証もしっかりしています。当時、カウンター板のトラブル事例を見ていると不安になったという点も多少あります。（しかし、使っていれば傷や凹みは付くのであんまり気にしなくてよかったです）

オンラインですと6万円ほどで買えます。

チェア

社会人3年目にハーマンミラーのEmbody chair購入してそれからずっと職場で使っています。職場が変われば、Embody Chairを自費で赤帽を使って輸送して使っています。

チェアを買うときに、アーロンチェアかEmbody Chairにするか迷いましたが、Embody Chairのほうが上位っぽかったので決めました。

今となっては新品が25万円ぐらいしますが17年前は20万円弱でした。現地では10万円ちょっとで売られていたのでアメリカから新品を個人輸入してトータル15万円ぐらいで手に入れました。

::amazon{asin="B004HW814E"}

メイン照明

作業環境の観点と、テレカンの写りの観点で照明はとても重要です。このために部屋をリフォームかけました。

照明の重要さについて書かれている記事を載せておきます。

https://www.akiyan.com/blog/archives/2007/01/post_75.html

https://diary.teraren.com/posts/2013-12-15-lighting/

https://logmi.jp/business/articles/191355

まず、液晶モニタに反射を作る原因は強い光源なので外光をあまり取り入れないようにして昼夜問わず安定した照明環境を作ることを基本としました。

その上で、昼は白色、夜は暖色にできるようにしたかったのでちょうどPanasonicから調色のLED照明が発売されたので導入しました。

テレカン時に顔への照明をまんべんなく当てるために間接照明にするのが良いです。以前、テレカンのときだけ顔用に照明を使ったりしていましたが、面倒だし眩しいのですぐに使わなくなりました。

間接照明にするために、シーリングライトのコネクタを撤去してリフォーム業者に依頼してコーブ照明にリフォームしました。

利用したのはARCHITECTURAL LIGHT L=1200 (YYY21260LB1)です。4つ設置しました。

調色を重視しているのであんまり発色は綺麗では無いのが残念です。設置直後はまんべんなく綺麗に発色していた気はしますが、最近はなんかほんの少し緑っぽさが出てきた気がしてます。

背景(バックスクリーン)

Webカメラ（普通の安いカメラも）の特性で、明るさ（露出）は写っている全体の光量を元に明るさを決めています。一般的には壁紙は白いので、白い壁紙の前で顔を写すと顔が相対的に暗くなります。それを防ぐためには背景を顔より暗い明度にするのが良いです。

極端に言えば、黒い壁紙にすれば自分の顔がすごい白く写ります。

そこで、ダークグレーのロールスクリーンを設置して背景を作りました。幅をぴったりに作りたかったのでオーダーで注文しました。

TOSOのプレートというシリーズです。4万円ぐらいしました。

同じ照明の下で、背景の違いによる顔の印象を検証するためにiPhone 13 Proでサンプルを撮影してみました。無補正です。右の方が顔に影ができてしまっているし全体的に暗い印象になってしまっていますが、左側は白く明るい印象に写っています。（iPhone 13だと頭が良すぎてフォーカスが当たっているところの露出を基準にしちゃっているのであまり顕著には差が出ませんが）

明度の低い背景

明度の高い背景

スポット照明

資材が余ったのでデスクの上にダクトレールを設置して、暖色のLEDスポットライトを付けてみました。間接照明だけだと暗すぎるかと思ったので保険としてです。ですが、まったく使っておりません。

スピーカー

3回スピーカーを買い替えた結果、GENELECの8020シリーズを使っています。めちゃくちゃ満足度は高いです。もう、これは騙されたと思って買ってみてほしいです。

スピーカーは部屋の大きさや、スピーカーまでの距離、スタンドの材質などによって変わるので環境の制約に合ったものを選ぶ必要があったのでここに行き着くまでが大変でした。

大きくて高いものを買えば安心というモノではないです。

スピーカーが良ければテレカンにおいて、聞こえづらい部分とかも少しは明瞭になりますし、相手の声も聞き取りやすくなります。

詳細はこちらの記事にまとめてあります。

マイク

HyperX QuadCastです。YouTuberがおすすめしていたので買いました。

スピーカーの音を拾わないようにするためにマイクは指向性があるものが良いです。あと、結果的に良かったのは普通のハンドマイクを使うより、直立していたほうがスペースを取らなくて良いです。どうしてもマイクは顔の近くに置く必要があるため邪魔にならない形状である必要があります。

物理的にmute/unmuteができるものだと楽です。ソフトウェア上でmute/unmuteをするとなると直感的ではないしすぐに操作したいときに困ります。

::amazon{asin="B07NZZZ746"}

キーボード

定番のHHKB Proです。HHKB Professional HYBRID Type-S 無刻印／墨（英語配列）

::amazon{asin="B082TWFV9C"}

自作キーボードの道もありますが、カフェでノートPCを使って作業するときもあるので標準からずれないほうが良いという考えがあります。

PFU Happy Hacking Keyboard Professional BT 無刻印/墨 PD-KB600BNを最初は買ったのですが、2週間ぐらいで買い替えました。たしか、PCを2台使っていて、Bluetoothによる接続切り替えができなかったためです。

マウス

::amazon{asin="B074Z71C2M"}

ケーブル収納

::amazon{asin="B01N59ON4W"}

サンワサプライのケーブル収納するやつ。めちゃくちゃキレイに収納できるのでおすすめです。

この収納トレーは、ERDシリーズ専用になっていてナットで天板に裏からビス止めできます。そのため、クランプ型だとどうしてもデスクに引っ掛ける部分が必要になりますが、こちらはデスク上には一切干渉しないです。その代わり、天板に穴あけ加工が必要になります。

ネジの規格はM5 x 12mmになるので、穴側は、鬼目ナット側 M5x10mm、下穴は7.5mmのビットで穴あけをしました。天板を外して作業したので2時間ぐらいかかりました。初期設置時にやっておくべきでした。

電源タップはこちらです。スピーカーそれぞれ、Google Home, モニタ、デスク裏のLED照明に電源が必要なので結構コンセントを使うので10口ぐらいは必要です。

::amazon{asin="B0877666H6"}

デスクLED照明

WiFiに接続してコントロールできるフルカラーLEDテープを貼り付けています。

::amazon{asin="B087339YX8"}

作業中は緑色にすることで緑視率を上げることによる集中力向上を狙っています。

このLEDテープの密度が低いので普通に貼ったら斑（まだら）になってしまいました。そこで、ピッチが異なるように上と下になるように2重に貼り付けたらドットが見えなくなってきれいに発色するようになりました。高さ違い、ピッチ違いなので影ができづらくなり、綺麗に発光しているように見えます。

スマートホームと連携して始業時間に点灯するように設定して、深夜に消灯するようにしています。

音に反応した照明でクラブっぽい演出もできます。電気信号でのコントロールではなく、音量を計測して発光しているので遅延が大きくて違和感あります。。。

https://youtu.be/_d5A_hF68Wk

USBカメラ

特にこだわりは無し。オートフォーカスがついているし小さいので別に不満は無いです。ティルト調整ができるので角度が変えられるのが良いです。

::amazon{asin="B07QQR6G5N"}

USB DAC

3回買い直してここに至ります。ちょっと無名なメーカーのアンプは数ヶ月〜数年使っていると調子が悪くなってきます。PCに認識されなくなったり、左右の音色の差が出てきたりしました。

この商品は口コミ数が多くて安心できそうなので買いました。低音と高音のイコライザーがついているので多少音色の調整をアンプ側で変更できます。

1年ぐらい問題なく運用できています。

::amazon{asin="B07VDQQY95"}

USBハブ

モニタについているUSB-Aポートだけでは足りないので増設しています。USBセキュリティキーを抜き差しするときに手元にあったほうが楽です。

::amazon{asin="B07ST84PF5"}

PCスタンド

隙間の幅をネジで調整できるのでピッタリハマるように設定できます。

::amazon{asin="B07MFSK7ZB"}

Google Nest mini

Nestになってから小さいけど音質がかなり向上したので適当なBGMを流すのに使ってます。

シーンに応じた照明

夜間の照明例

ブルーライトをカットする必要があるので、暖色で統一。

暖色のスポットライトを点灯し、デスク裏のLEDテープライトを黄色に点灯した状態。

Cyberpunkぽい例

デスクのLEDテープライトのみを点灯しただけ。ブラックライトに近い光り方をします。目が疲れます。

ミニモニタ

iPadを外部モニタとして使ったりもしていましたがイマイチでした。深夜にツール・ド・フランスのライブを見ながら作業するために設置しましたがどっちにも集中できないです。

テレカンの画面をiPadに持ってきたり、タッチペンで操作して図形描画に使ったりもしていましたが、モニタのミラーモードと、iOSの切り替えが面倒でした。

まとめ

自宅の作業環境を紹介しました。
全部足すと、機材に60万円ほど。リフォームに50万円ほどかかっていると思います。
ChatGPTにタイトルを付けさせたらなんか大げさなタイトルになってしまった。

Tableau serverをrpmでアップグレードする方法メモ

Wed, 24 May 2023 00:00:00 GMT

概要

Tableau server は 1 年に 10 から 15 回ぐらいセキュリティ脆弱性対応や不具合対応のために新規バージョンがリリースされます。
毎回一筋縄では更新できないのでメモを残しておきます。
公式の手順書はこちらになります。

やり方の例

以下のページから対象の rpm パッケージをダウンロードします。

https://www.tableau.com/ja-jp/support/releases/server/2023.1.2

% wget https://downloads.tableau.com/esdalt/2023.1.2/tableau-server-2023-1-2.x86_64.rpm
% wget https://downloads.tableau.com/esdalt/2023.1.2/tableau-tabcmd-2023-1-2.noarch.rpm

両方一気に更新してみますが、エラーが出ます。

% sudo yum install *rpm
Failed to set locale, defaulting to C
Loaded plugins: etckeeper, extras_suggestions, langpacks, priorities, update-motd
Examining tableau-server-2023-1-2.x86_64.rpm: tableau-server-20231.23.0511.1508-20231-23.0511.1508.x86_64
Marking tableau-server-2023-1-2.x86_64.rpm to be installed
Examining tableau-tabcmd-2023-1-2.noarch.rpm: tableau-tabcmd-20231.23.0511.1508-20231-23.0511.1508.noarch
Marking tableau-tabcmd-2023-1-2.noarch.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package tableau-server-20231.23.0511.1508.x86_64 0:20231-23.0511.1508 will be installed
---> Package tableau-tabcmd-20231.23.0511.1508.noarch 0:20231-23.0511.1508 will be installed
--> Finished Dependency Resolution
amzn2-core/2/x86_64                                                                                                                                                                                                                                                                  | 3.7 kB  00:00:00

Dependencies Resolved

============================================================================================================================================================================================================================================================================================================
 Package                                                                             Arch                                                     Version                                                               Repository                                                                         Size
============================================================================================================================================================================================================================================================================================================
Installing:
 tableau-server-20231.23.0511.1508                                                   x86_64                                                   20231-23.0511.1508                                                    /tableau-server-2023-1-2.x86_64                                                   4.6 G
 tableau-tabcmd-20231.23.0511.1508                                                   noarch                                                   20231-23.0511.1508                                                    /tableau-tabcmd-2023-1-2.noarch                                                    19 M

Transaction Summary
============================================================================================================================================================================================================================================================================================================
Install  2 Packages

Total size: 4.6 G
Installed size: 4.6 G
Is this ok [y/d/N]: y
Downloading packages:
Running transaction check
Running transaction test


Transaction check error:
  file /opt/tableau/tabcmd/NOTICES.txt from install of tableau-tabcmd-20231.23.0511.1508-20231-23.0511.1508.noarch conflicts with file from package tableau-tabcmd-20221.22.0823.1450-20221-22.0823.1450.noarch
  file /opt/tableau/tabcmd/bin/tabcmd from install of tableau-tabcmd-20231.23.0511.1508-20231-23.0511.1508.noarch conflicts with file from package tableau-tabcmd-20221.22.0823.1450-20221-22.0823.1450.noarch

Error Summary
-------------

tabcmdの方のパッケージにおいて、ファイルがコンフリクトしているみたいです。

tableau-server

まずはserverの方を単独で更新します。

% sudo yum install tableau-server-2023-1-2.x86_64.rpm
Failed to set locale, defaulting to C
Loaded plugins: etckeeper, extras_suggestions, langpacks, priorities, update-motd
Examining tableau-server-2023-1-2.x86_64.rpm: tableau-server-20231.23.0511.1508-20231-23.0511.1508.x86_64
Marking tableau-server-2023-1-2.x86_64.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package tableau-server-20231.23.0511.1508.x86_64 0:20231-23.0511.1508 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

============================================================================================================================================================================================================================================================================================================
 Package                                                                             Arch                                                     Version                                                               Repository                                                                         Size
============================================================================================================================================================================================================================================================================================================
Installing:
 tableau-server-20231.23.0511.1508                                                   x86_64                                                   20231-23.0511.1508                                                    /tableau-server-2023-1-2.x86_64                                                   4.6 G

Transaction Summary
============================================================================================================================================================================================================================================================================================================
Install  1 Package

Total size: 4.6 G
Installed size: 4.6 G
Is this ok [y/d/N]: y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
etckeeper: pre transaction commit

Your hardware meets the minimum requirements for a trial of Tableau Server.
If you plan to run Tableau Server in a production environment, we recommend the following hardware specifications: http://www.tableau.com/products/server/specs
Tableau Server runs best with at least 128 GB memory, but found only 31 GB of memory.
Tableau Server runs best with at least 8 cores, but found only 4 core(s).

  Installing : tableau-server-20231.23.0511.1508-20231-23.0511.1508.x86_64                                                                                                                                                                                                                              1/1

Found existing installation version '20223.22.1108.0821' in /var/opt/tableau/tableau_server


Found existing installation version '20223.22.1108.0821' in /var/opt/tableau/tableau_server

After new version has been installed on every Tableau Server node, run:

    sudo /opt/tableau/tableau_server/packages/scripts.20231.23.0511.1508/upgrade-tsm --accepteula

on initial (controller) node to continue upgrading Tableau Server.

etckeeper: post transaction commit
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LC_COLLATE = "C",
	LC_CTYPE = "UTF-8",
	LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LC_COLLATE = "C",
	LC_CTYPE = "UTF-8",
	LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
  Verifying  : tableau-server-20231.23.0511.1508-20231-23.0511.1508.x86_64                                                                                                                                                                                                                              1/1

Installed:
  tableau-server-20231.23.0511.1508.x86_64 0:20231-23.0511.1508

Complete!

更新できました。次に、規約に同意が必要なので同意します。

% sudo /opt/tableau/tableau_server/packages/scripts.20231.23.0511.1508/upgrade-tsm --accepteula
Upgrading Tableau Server to version 20231.23.0511.1508. See log file at /var/opt/tableau/tableau_server/logs/app-upgrade.log for progress.
Verifying that the upgrade script is running from the correct environment.
Validating Tableau Server version.
Verifying that the new packages have been installed on all cluster nodes.
Verifying Active Directory connection.
Verifying configuration is valid.
Performing preflight checks to ensure the server is in a good state to be upgraded.
Stopping service...
This operation will stop the server. To start server, run 'tsm start' after the upgrade is completed. Do you want to continue?
(y/n): y
Reconnecting to asynchronous job...
Running - Disabling all services.Job id is '461', timeout is 30 minutes.
50% - Disabling all services.
100% - Waiting for the services to stop.
Verifying Tableau Server is stopped.
Verifying that there is only one deployed Tableau Server Coordination Service ensemble.
Verifying that Tableau Server has been initialized.
Verifying licensing state.
Backing up repository.
Making prerequisite configuration changes prior to upgrading TSM services.
Reconnecting to asynchronous job...
Job id is '462', timeout is 43 minutes.
11% - Retrieving the topology to deploy.
22% - Retrieving the configuration to deploy.
33% - Validating the new topology.
44% - Determining if server needs to be started.
55% - Updating nodes to new topology.
66% - Waiting for topology to be applied.
77% - Updating nodes to new configuration.
88% - Reconfiguring services.
100% - Waiting for services to reconfigure.
Upgrading TSM services.
Deploying new service packages.
Updating Tableau Server Coordination Service.
Updating Tableau Server Client File Service.
Adding Activation Service.
Updating configuration.
Reconnecting to asynchronous job...
Job id is '463', timeout is 60 minutes.

Generating new credentials.
Reconnecting to asynchronous job...
Job id is '464', timeout is 63 minutes.
7% - Generating passwords.
14% - Generating secret keys.
21% - Generating apigateway mutual SSL certificates.
28% - Generating Apache Gateway Internal mutual SSL certificates.
35% - Generating Unique Cluster Identifier.
42% - Generating Search Server SSL certificate.
50% - Generating Index And Search Server SSL certificate.
57% - Generating ActiveMQ Server SSL certificate.
64% - Generating internal Metadata API mutual SSL certificates.
71% - Generating key store.
78% - Generating Hyper SSL certificate.
85% - Generating TSIG logs service SSL certificate.
92% - Promoting configuration.
100% - Waiting for services to reconfigure.
Performing post-upgrade services and configuration operation.
Reconnecting to asynchronous job...
Job id is '465', timeout is 30 minutes.
50% - Disabling all services.
100% - Waiting for the services to stop.
Updating asset keys.
Reconnecting to asynchronous job...
Job id is '466', timeout is 2880 minutes.
100% - Migrating asset keys to configuration if needed.
Restoring repository.
Updating repository version in Tableau Server Coordination Service.
Updating repository.
Reconnecting to asynchronous job...
Job id is '467', timeout is 120 minutes.
8% - Enabling the database services.
16% - Waiting for the database services to enable.
25% - Putting the repository into local trust mode.
33% - Creating roles and databases.
41% - Running migrations against the primary database.
50% - Setting the next active repository.
58% - Taking the repository out of local trust mode.
66% - Disabling database services.
75% - Waiting for database services to disable.
100% - Upgrading database
Updating data directory version.
Reconnecting to asynchronous job...
Job id is '468', timeout is 44 minutes.
9% - Retrieving the topology to deploy.
18% - Retrieving the configuration to deploy.
27% - Validating the new topology.
36% - Determining if server needs to be started.
45% - Disabling all services.
54% - Waiting for the services to stop.
63% - Updating nodes to new topology.
72% - Waiting for topology to be applied.
81% - Updating nodes to new configuration.
90% - Reconfiguring services.
100% - Waiting for services to reconfigure.
upgrader.initializing_index_and_search_server
Rebuilding search index.
Reconnecting to asynchronous job...
Job id is '469', timeout is 10 minutes.
14% - Disabling all services.
28% - Waiting for the services to stop.
42% - Starting backup restore services for search server reset.
57% - Resetting search server.
71% - Starting search server.
85% - Configuring search server.
100% - Stopping backup restore services.
Reconnecting to asynchronous job...
Job id is '470', timeout is 1440 minutes.
25% - Enabling the services required for indexing.
50% - Connecting to Vizportal Maintenance.
75% - Rebuilding the search index.
100% - Disabling the services used for indexing.
Upgrading Analytics Extensions settings.
Resetting Metadata API Store.
Reconnecting to asynchronous job...
Job id is '471', timeout is 10 minutes.
9% - Starting required services for resetting Metadata API Store.
18% - Stopping Metadata API Store related services.
27% - Enabling the maintenance app.
36% - Waiting for the maintenance app to start.
45% - Disabling database services.
54% - Waiting for database services to disable.
63% - Recreating Metadata API Store.
72% - Restoring Metadata API Store related services to previous state.
100% - Restoring required services to previous state.
Verifying licensing state.
Tableau Server has been upgraded to version 20231.23.0511.1508.
>> The upgraded Tableau binary directory will be added to PATH for new shells. To get the
>> updated path, either start a new session, or for bash users run:
>> source /etc/profile.d/tableau_server.sh

serverのパッケージを更新すると、Tableau server自体が停止するのでtsmコマンドを利用して明示的にサーバを起動します。

$ tsm start
Starting service...
The last successful run of StartServerJob took 4 minute(s).

Job id is '472', timeout is 60 minutes.

Service was started successfully.

tableau-cmd

一度uninstallすれば良いみたいなので、一度消してインストールします。

% sudo yum remove tableau-tabcmd-20221.22.0823.1450-20221-22.0823.1450.noarch
% sudo yum install tableau-tabcmd-2023-1-2.noarch.rpm

まとめ

毎回手動で作業しないといけないのが辛いです。yum で提供してほしいです。

tableau serverをrpmでアップグレードする方法メモ

Wed, 24 May 2023 00:00:00 GMT

概要

tableau serverは1年に3〜5回ぐらいセキュリティ脆弱性対応や不具合対応のために新規バージョンがリリースされます。
毎回微妙に不具合が起きたりするのでメモを残しておきます。
公式の手順書はこちらになります。

やり方の例

以下のページから対象のrpmパッケージをダウンロードします。

https://www.tableau.com/ja-jp/support/releases/server/2023.1.2

% wget https://downloads.tableau.com/esdalt/2023.1.2/tableau-server-2023-1-2.x86_64.rpm
% wget https://downloads.tableau.com/esdalt/2023.1.2/tableau-tabcmd-2023-1-2.noarch.rpm

両方一気に更新してみますが、エラーが出ます。

% sudo yum install *rpm
Failed to set locale, defaulting to C
Loaded plugins: etckeeper, extras_suggestions, langpacks, priorities, update-motd
Examining tableau-server-2023-1-2.x86_64.rpm: tableau-server-20231.23.0511.1508-20231-23.0511.1508.x86_64
Marking tableau-server-2023-1-2.x86_64.rpm to be installed
Examining tableau-tabcmd-2023-1-2.noarch.rpm: tableau-tabcmd-20231.23.0511.1508-20231-23.0511.1508.noarch
Marking tableau-tabcmd-2023-1-2.noarch.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package tableau-server-20231.23.0511.1508.x86_64 0:20231-23.0511.1508 will be installed
---> Package tableau-tabcmd-20231.23.0511.1508.noarch 0:20231-23.0511.1508 will be installed
--> Finished Dependency Resolution
amzn2-core/2/x86_64                                                                                                                                                                                                                                                                  | 3.7 kB  00:00:00

Dependencies Resolved

============================================================================================================================================================================================================================================================================================================
 Package                                                                             Arch                                                     Version                                                               Repository                                                                         Size
============================================================================================================================================================================================================================================================================================================
Installing:
 tableau-server-20231.23.0511.1508                                                   x86_64                                                   20231-23.0511.1508                                                    /tableau-server-2023-1-2.x86_64                                                   4.6 G
 tableau-tabcmd-20231.23.0511.1508                                                   noarch                                                   20231-23.0511.1508                                                    /tableau-tabcmd-2023-1-2.noarch                                                    19 M

Transaction Summary
============================================================================================================================================================================================================================================================================================================
Install  2 Packages

Total size: 4.6 G
Installed size: 4.6 G
Is this ok [y/d/N]: y
Downloading packages:
Running transaction check
Running transaction test

Transaction check error:
  file /opt/tableau/tabcmd/NOTICES.txt from install of tableau-tabcmd-20231.23.0511.1508-20231-23.0511.1508.noarch conflicts with file from package tableau-tabcmd-20221.22.0823.1450-20221-22.0823.1450.noarch
  file /opt/tableau/tabcmd/bin/tabcmd from install of tableau-tabcmd-20231.23.0511.1508-20231-23.0511.1508.noarch conflicts with file from package tableau-tabcmd-20221.22.0823.1450-20221-22.0823.1450.noarch

Error Summary
-------------

tabcmdの方のパッケージにおいて、ファイルがコンフリクトしているみたいです。

tableau-server

まずはserverの方を単独で更新します。

% sudo yum install tableau-server-2023-1-2.x86_64.rpm
Failed to set locale, defaulting to C
Loaded plugins: etckeeper, extras_suggestions, langpacks, priorities, update-motd
Examining tableau-server-2023-1-2.x86_64.rpm: tableau-server-20231.23.0511.1508-20231-23.0511.1508.x86_64
Marking tableau-server-2023-1-2.x86_64.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package tableau-server-20231.23.0511.1508.x86_64 0:20231-23.0511.1508 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

============================================================================================================================================================================================================================================================================================================
 Package                                                                             Arch                                                     Version                                                               Repository                                                                         Size
============================================================================================================================================================================================================================================================================================================
Installing:
 tableau-server-20231.23.0511.1508                                                   x86_64                                                   20231-23.0511.1508                                                    /tableau-server-2023-1-2.x86_64                                                   4.6 G

Transaction Summary
============================================================================================================================================================================================================================================================================================================
Install  1 Package

Total size: 4.6 G
Installed size: 4.6 G
Is this ok [y/d/N]: y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
etckeeper: pre transaction commit

Your hardware meets the minimum requirements for a trial of Tableau Server.
If you plan to run Tableau Server in a production environment, we recommend the following hardware specifications: http://www.tableau.com/products/server/specs
Tableau Server runs best with at least 128 GB memory, but found only 31 GB of memory.
Tableau Server runs best with at least 8 cores, but found only 4 core(s).

  Installing : tableau-server-20231.23.0511.1508-20231-23.0511.1508.x86_64                                                                                                                                                                                                                              1/1

Found existing installation version '20223.22.1108.0821' in /var/opt/tableau/tableau_server

Found existing installation version '20223.22.1108.0821' in /var/opt/tableau/tableau_server

After new version has been installed on every Tableau Server node, run:

    sudo /opt/tableau/tableau_server/packages/scripts.20231.23.0511.1508/upgrade-tsm --accepteula

on initial (controller) node to continue upgrading Tableau Server.

etckeeper: post transaction commit
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LC_COLLATE = "C",
	LC_CTYPE = "UTF-8",
	LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LC_COLLATE = "C",
	LC_CTYPE = "UTF-8",
	LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
  Verifying  : tableau-server-20231.23.0511.1508-20231-23.0511.1508.x86_64                                                                                                                                                                                                                              1/1

Installed:
  tableau-server-20231.23.0511.1508.x86_64 0:20231-23.0511.1508

Complete!

更新できました。次に、規約に同意が必要なので同意します。

% sudo /opt/tableau/tableau_server/packages/scripts.20231.23.0511.1508/upgrade-tsm --accepteula
Upgrading Tableau Server to version 20231.23.0511.1508. See log file at /var/opt/tableau/tableau_server/logs/app-upgrade.log for progress.
Verifying that the upgrade script is running from the correct environment.
Validating Tableau Server version.
Verifying that the new packages have been installed on all cluster nodes.
Verifying Active Directory connection.
Verifying configuration is valid.
Performing preflight checks to ensure the server is in a good state to be upgraded.
Stopping service...
This operation will stop the server. To start server, run 'tsm start' after the upgrade is completed. Do you want to continue?
(y/n): y
Reconnecting to asynchronous job...
Running - Disabling all services.Job id is '461', timeout is 30 minutes.
50% - Disabling all services.
100% - Waiting for the services to stop.
Verifying Tableau Server is stopped.
Verifying that there is only one deployed Tableau Server Coordination Service ensemble.
Verifying that Tableau Server has been initialized.
Verifying licensing state.
Backing up repository.
Making prerequisite configuration changes prior to upgrading TSM services.
Reconnecting to asynchronous job...
Job id is '462', timeout is 43 minutes.
11% - Retrieving the topology to deploy.
22% - Retrieving the configuration to deploy.
33% - Validating the new topology.
44% - Determining if server needs to be started.
55% - Updating nodes to new topology.
66% - Waiting for topology to be applied.
77% - Updating nodes to new configuration.
88% - Reconfiguring services.
100% - Waiting for services to reconfigure.
Upgrading TSM services.
Deploying new service packages.
Updating Tableau Server Coordination Service.
Updating Tableau Server Client File Service.
Adding Activation Service.
Updating configuration.
Reconnecting to asynchronous job...
Job id is '463', timeout is 60 minutes.

Generating new credentials.
Reconnecting to asynchronous job...
Job id is '464', timeout is 63 minutes.
7% - Generating passwords.
14% - Generating secret keys.
21% - Generating apigateway mutual SSL certificates.
28% - Generating Apache Gateway Internal mutual SSL certificates.
35% - Generating Unique Cluster Identifier.
42% - Generating Search Server SSL certificate.
50% - Generating Index And Search Server SSL certificate.
57% - Generating ActiveMQ Server SSL certificate.
64% - Generating internal Metadata API mutual SSL certificates.
71% - Generating key store.
78% - Generating Hyper SSL certificate.
85% - Generating TSIG logs service SSL certificate.
92% - Promoting configuration.
100% - Waiting for services to reconfigure.
Performing post-upgrade services and configuration operation.
Reconnecting to asynchronous job...
Job id is '465', timeout is 30 minutes.
50% - Disabling all services.
100% - Waiting for the services to stop.
Updating asset keys.
Reconnecting to asynchronous job...
Job id is '466', timeout is 2880 minutes.
100% - Migrating asset keys to configuration if needed.
Restoring repository.
Updating repository version in Tableau Server Coordination Service.
Updating repository.
Reconnecting to asynchronous job...
Job id is '467', timeout is 120 minutes.
8% - Enabling the database services.
16% - Waiting for the database services to enable.
25% - Putting the repository into local trust mode.
33% - Creating roles and databases.
41% - Running migrations against the primary database.
50% - Setting the next active repository.
58% - Taking the repository out of local trust mode.
66% - Disabling database services.
75% - Waiting for database services to disable.
100% - Upgrading database
Updating data directory version.
Reconnecting to asynchronous job...
Job id is '468', timeout is 44 minutes.
9% - Retrieving the topology to deploy.
18% - Retrieving the configuration to deploy.
27% - Validating the new topology.
36% - Determining if server needs to be started.
45% - Disabling all services.
54% - Waiting for the services to stop.
63% - Updating nodes to new topology.
72% - Waiting for topology to be applied.
81% - Updating nodes to new configuration.
90% - Reconfiguring services.
100% - Waiting for services to reconfigure.
upgrader.initializing_index_and_search_server
Rebuilding search index.
Reconnecting to asynchronous job...
Job id is '469', timeout is 10 minutes.
14% - Disabling all services.
28% - Waiting for the services to stop.
42% - Starting backup restore services for search server reset.
57% - Resetting search server.
71% - Starting search server.
85% - Configuring search server.
100% - Stopping backup restore services.
Reconnecting to asynchronous job...
Job id is '470', timeout is 1440 minutes.
25% - Enabling the services required for indexing.
50% - Connecting to Vizportal Maintenance.
75% - Rebuilding the search index.
100% - Disabling the services used for indexing.
Upgrading Analytics Extensions settings.
Resetting Metadata API Store.
Reconnecting to asynchronous job...
Job id is '471', timeout is 10 minutes.
9% - Starting required services for resetting Metadata API Store.
18% - Stopping Metadata API Store related services.
27% - Enabling the maintenance app.
36% - Waiting for the maintenance app to start.
45% - Disabling database services.
54% - Waiting for database services to disable.
63% - Recreating Metadata API Store.
72% - Restoring Metadata API Store related services to previous state.
100% - Restoring required services to previous state.
Verifying licensing state.
Tableau Server has been upgraded to version 20231.23.0511.1508.
>> The upgraded Tableau binary directory will be added to PATH for new shells. To get the
>> updated path, either start a new session, or for bash users run:
>> source /etc/profile.d/tableau_server.sh

serverのパッケージを更新すると、tableau server自体が停止するのでtsmコマンドで手動で起動します。

$ tsm start
Starting service...
The last successful run of StartServerJob took 4 minute(s).

Job id is '472', timeout is 60 minutes.

Service was started successfully.

tableau-cmd

一度uninstallすれば良いみたいなので、一度消してインストールします。

% sudo yum remove tableau-tabcmd-20221.22.0823.1450-20221-22.0823.1450.noarch
% sudo yum install tableau-tabcmd-2023-1-2.noarch.rpm

おわり

個人開発のWebサービスをCloudflareに載せてみた【無料でここまでできる】

Sun, 23 Apr 2023 00:00:00 GMT

概要

私は個人でWebサイトやWebサービスを色々公開しております。

この度、個人開発でWebサービスを運用するときにCloudflareを利用すると様々なリスクを無料でヘッジできるので事例を紹介します。

しかも無料です。

個人開発サービスの問題

費用をかけられない

お金をかければWAFや計算処理の高いサーバやコンテナなどの環境を使えますが、テストで開発したサービスや収益化するかどうかわからないサービスをたくさん運用することになるので固定費は可能な限り抑える必要があります。

いかに安く安定的にサービスを提供できるかは腕の見せどころでもあります。

複数サービスがダウンする可能性

固定費を抑えるために1ホストにいろいろなサービスを動かすことが多いと思います。

よって、1つのサービスに対してDoS攻撃や突発的にWeb上でバズって大量のトラフィックが来ると捌ききれなくなってあるホストで運用しているサービスがすべてダウンしてしまうリスクがあります。

自宅サーバの場合はポートを解放しないといけない

費用を抑えるために自宅サーバを運用して居る場合もあると思いますが、自宅サーバを公開するためにはポートを開放する必要があります。また、ホストレベルでクラックされた場合には自宅LANに第三者が入れる状態になってしまうリスクがあります。

Cloudflareとは

主なサービスは、コンテンツ配信ネットワーク（CDN）、DDoS攻撃防御、Webアプリケーションファイアウォール（WAF）などのセキュリティ機能、およびインターネット最適化を提供します。Cloudflareの主な機能は以下になります。

コンテンツ配信ネットワーク (CDN)
DDoS保護
Webアプリケーションファイアウォール (WAF)
SSL/TLS暗号化
DNSサービス
Zero Trustセキュリティ
エッジコンピューティング

これ以外にもたくさんのWebサービスを運用する上で便利な機能があります。

概念的には以下のようなイメージです。主にレイヤー7のアプリケーション層においてのリスクをCloudflareで全部受け止めてくれるような使い方ができます。

Cloudflareのダッシュボードをチラ見せしますとこんな感じになります。左のメニューを見てもらうとわかると思うのですが、Webサービスを運用する上で便利な機能が用意されています。

変更前インフラ

おそらく、個人開発しているサービスや小規模サービスは以下のようなインフラ構成になっていると思います。

AWSでいえば、アプリケーションサーバはEC2やAWS Lightsail、自宅サーバで動かして、CDNに乗せられるようなコンテンツはCloud Frontを使うと言ったような感じです。

上記の構成であれば、無料枠で収まるかなと思います。

上記の構成を少し先に進めるために、WAFを入れたり、TLS証明書の自動更新を入れたりすると毎月数万円の金額がかかってきます。

Cloudflareでの設定

フェーズ1

Cloudflareを利用するためにはドメインが切られている必要があり、zoneサーバをCloudflareでホスティングする必要があります。

CloudflareのDNSだけを使うだけでも無料で運用できるのでそれだけでも価値はあったりしますが、まずはCloudflareの恩恵を受けるためには以下のような構成を作るのが1歩目です。

「Cloudflare as CDN」と書かれている部分が普通の概念とは異なるのですが、CDNとざっくり書いてしまいましがこの部分がCloudflareの超重要な部分です。そして説明しづらいところなのであんまりCloudflareが認知されていない理由にもなっているのかなと思います。

分かりやすく説明するために、1つのメインの機能としては、TLS terminationとReverse Proxyが動作しています。それにより、外部からの攻撃、リクエスト内容の検証、originへのトラフィックの制御を行えるようになっています。

次に、設定の手順の概略を書いておきます。

DNS zoneの登録

なにはともあれ、Cloudflareを使うための第1ステップはドメインのzoneを登録するところからです。

例えば、CloudflareのCDN（無料）だけを使いたかったとしてもDNS zoneをCloudflare上でホスティングする必要があります。Cloudflareの恩恵は受けられませんが、CloudflareのDNS zoneホスティングだけを使うと言ったことも無料で可能です。

（スクショは英語ですが、すべて日本語の表示もできます）

zoneを登録したら、各レコードを追加していきます。

レコードを追加する際に普通とは違うのが、"Proxy status" というスイッチがあることです。このスイッチをonにするとDNS zoneサーバのレスポンスは登録したIPアドレスなどではなく、CloudflareのReverse proxyサーバのアドレスに置き換わります。

{/* textlint-disable ja-technical-writing/no-unmatched-pair /} では、”Proxy status”をonにしたら左の項目に登録したIPアドレスはどう扱われるのかといいますと、Reverse Proxyのoriginのホストとして扱われます。 {/ textlint-enable ja-technical-writing/no-unmatched-pair */}

独特な概念ではあって最初からつまずきやすいですが、一度理解してしまえば大丈夫ですし、段階的に切り替えられます。まずはReverse proxyをoffにした状態でDNS zoneを移行するのが良いです。

このblog.teraren.comのサイト自体もCloudflareを使っているのでDNSを引くとReverse proxyのアドレスが返ってきます。

Reverse proxyで受けられるようにoriginを設定

既存のはorigin側のwebサーバの設定では、グローバルからリクエストを受ける設定になっているのでreverse proxyからアクセスを受けられるように設定します。

今までは、ユーザに見せるホスト名でのTLS terminationなどを行ったいた設定をreverse proxyからのアクセスを前提とした設定にします。

設定例: Configure Nginx Reverse Proxy behind Cloudflare

キャッシュルールの設定

Reverse Proxy自体がCDN機能を持っているので、どのコンテンツをキャッシュするかどうかを設定します。

WebからわかりやすいUIで設定できるので自分のホスティングするサービスに応じてルールを書いていきます。

無料だと10個までしかルールセットを作れません。私はキャッシュの期間ごとにルールセットを作っています。

1ヶ月キャッシュ、7日キャッシュ、1日キャッシュ、キャッシュ無しという分類です。

（2つ目と3つ目は同義です。もともとは別の期間を設定していた名残です。）

私の環境における「キャッシュ無し」のスクショを書いておきます。

WordPressの管理画面、ヘルスチェック用エンドポイント、動的なスクリプト、RSSフィードなどを記載してあります。

逆に1ヶ月の長期間を設定している設定はこちらになります。主に画像などの静的アセットになります。昨今はCDNを考慮したアセットの構築が行われているので内容が変わればURLも変わるという前提のためです。

CDN周りだけでも以下のような設定が簡単に行えます。

Query Stringごとにキャッシュするかどうか
ブラウザキャッシュのヘッダを付加するか
Originが落ちたときにキャッシュをサーブするか
CDNの一時的に一括無効化

CloudflareのCDNのすごいところはinvalidationが数秒で終わることです。Amazonだと数分とかかかったりしちゃいますが。

統計情報

Reverse ProxyとCDNを使いだすと以下のような統計情報が表示されてきます。眺めているだけでも楽しいです。

右にあるメニューに注目してほしいのですが、もしサービスが攻撃を受けていたら一時的に「Javascriptによる人間かどうかのチャレンジを挟む」というスイッチがあるのでONにすればoriginのサービスを過負荷から守れます。

トラフィックの統計も細かく表示されます。

Webサイトへの攻撃に関する統計情報

プロトコルやどれだけ待機を節約できたかの情報も表示されます。

30日で見てみると、300GBのトラフィックを節約できたみたいです。（無駄なトラフィックを節約することでCO2削減にも貢献！）

WordPressの設定

WordPress用にCloudflareのプラグインが用意されています。

インストールしなくても使えることは使えるのですが、記事を更新すると自動でCDNの関連ページをpurgeしてくれます。あと、CDNでWordPressを運用するにあたってWordPressの挙動を勝手に裏で変更しているようです。

Cloudflare CDN を使う場合はこのプラグインは必須と言っていいです。物理的にはインストールしなくても動きますが、様々な運用上のユースケースに対応する機能が入っているので、入れておかないと予想外のコンテンツがキャッシュされてしまうリスクがあります。

内部でどんなことをやっているのか軽く紹介します。

管理者ログイン時のキャッシュバイパス

WordPressは動的にページを生成しているので、管理者が記事を閲覧したときと一般ユーザが閲覧したときではコンテンツの内容が異なります（管理バーの表示など）。このプラグインは管理者がログインしている場合は CDN のキャッシュを使わないようにしてくれます。

public function initAutomaticPlatformOptimization()
{
    // it could be too late to set the headers,
    // return early without triggering a warning in logs
    if (headers_sent()) {
        return;
    }

    // add header unconditionally so we can detect plugin is activated
    $cache = apply_filters('cloudflare_use_cache', !is_user_logged_in());
    if ($cache) {
        header('cf-edge-cache: cache,platform=wordpress');
    } else {
        header('cf-edge-cache: no-cache');
    }
}

is_user_logged_in() で判定して、ログイン中は cf-edge-cache: no-cache ヘッダを送信することで CDN にキャッシュさせない仕組みです。

記事・コメント更新時の自動キャッシュパージ

記事やコメントが更新されたら CDN の関連するページを自動で削除してくれます。Cloudflare の CDN は削除命令を出してから数秒で反映されるのでほぼリアルタイムです。

public function purgeCacheOnPostStatusChange($new_status, $old_status, $post)
{
    if ('publish' === $new_status || 'publish' === $old_status) {
        $this->purgeCacheByRelevantURLs($post->ID);
    }
}

public function purgeCacheOnCommentStatusChange($new_status, $old_status, $comment)
{
    if (!isset($comment->comment_post_ID) || empty($comment->comment_post_ID)) {
        return; // nothing to do
    }

    // in case the comment status changed, and either old or new status is "approved",
    // we need to purge cache for the corresponding post
    if (($old_status != $new_status) &&
        (($old_status === 'approved') || ($new_status === 'approved'))) {
        $this->purgeCacheByRelevantURLs($comment->comment_post_ID);
        return;
    }
}

記事のステータスが publish に変わったとき、またはコメントのステータスが approved に変わったときに関連URLのキャッシュをパージしています。この仕組みがあるおかげで、記事を更新したのにキャッシュが古いままという問題を気にしなくて済みます。

まとめ

IPv6対応、HTTP3/QUICK対応、DDoS対策、TLS証明書更新自動化、HSTS設定、CDN利用、DNSSECが行えてます。今までは自分で頑張って設定していたことがもうすでに用意されている感じです。

Cloudfalreは昨今の面倒なWebサイト運用における設定をWebサービスの1レイヤー上で面倒を見てくれるようなサービスです。

しかも無料。。。申し訳なくなってきます。

フェーズ2

フェーズ1からより安全にする方法です。

これにより、E2EEが実現でき、origin側のポート開放が不要になってよりセキュアにサービス運用を行えます。

tunnelのセットアップ

origin側にCloudflareのdaemonを動かして、tunnelを設定できます。cloudflareとoriginの間のトラフィックをこのtunnelを通すことによってoriginサーバ側でポート開放をする必要が無くなります。

tunnelを使うためにはCloudflare上のZero Trustの管理画面で設定します。

1ホストに対して1本のトンネルを作ってある設定例です。

daemonのインストールも非常に楽で管理画面上に表示されている例にあるコマンドを叩くだけです。

以下のようにpublicのホスト名と、originのサービス名を登録していきます。ここで登録するとCloudflareのDNSの設定にレコードが追加されていきます。既存のレコードと重複する場合はエラーが出ます。

tunnel経由でoriginへアクセス

1つ前のトンネルの設定をする際に、Cloudflareとoriginの通信を安全にしておくことをおすすめします。ブラウザとCloudflare間の設定はグローバルなのでLet's encryptといった枠組みでTLS証明書の発行と運用簡単に設定できますが、originへのアクセスはprivateネットワークなのでそう簡単にはできません。

そこで、Cloudflareが発行する証明書をoriginサーバにインストールすることでCloudflareから発行された証明書がインストールされたoriginサーバということを担保する証明書を利用します。

その設定が完了すれば、上記のようにCloudflareを挟んでも安全にoriginの信頼性を保証できることになります。

Cloudflare上ではこのことをE2EEと呼んでますが、TLS terminationをCloudflare上で行っているのでE2Eでの秘匿性と、完全制は保証できないですね。紛らわしいです。

また、ここでは触れませんがsshなどのサービスもzero trustのサービスによってtunnel経由でアクセスできるように設定できるのでsshのポートすら空けないですみます。

BICはOFFにしたほうが良さそう

Security > Settingメニューに有るBrowser Integrity Checkはオフにしたほうが良さそうです。プログラムからアクセスされるAPIサービスを運用していると、このルールによってblockされているリクエストが存在します。

24時間以内に10件くらいがブロックされてしまっていました。

Cloudflareの有料機能

これまでの設定はすべて無料で行える範囲です。トラフィックがどんなに増えても無料です。

課金すれば、もっと良いサービスを利用できるので将来使いそうなサービスをいくつか紹介しておきます。

Waiting page
急にサイトに大量のトラフィックが来たときに、Cloudflareでの待機ルームを表示してoriginが空くまでユーザを待たせる機能。チケット予約サイトとかはこれを使えば一発解決します。
Image compression
pngやjpgなどの画像を次世代圧縮形式であるwebpに変換してブラウザにサーブしてくれる機能です。サーバサイドで色々設定しなくても済みます。
Advanced WAF
怪しいアクセスをHTTPリクエストの内容を見て判断してくれます。

考察

Cloudflareを導入してみて大きく変わったことを書いておきます。

レスポンスタイムが超速い

CDNにキャッシュされると表示が一瞬で終わります。

$ ab -c 5 -n 20 https://blog.teraren.com | grep 'Time per request'
Time per request:       30.551 [ms] (mean)

今見ているこのページをリロードしてみると、ブラウザキャッシュが読み込んだかのような速さで表示されると思います。

wrk を使ってもう少し詳しくベンチマークしてみました。まずは CDN 経由のリクエスト。

❯ wrk  'https://blog.teraren.com/'
Running 10s test @ https://blog.teraren.com/
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    28.82ms   90.99ms   1.40s    98.65%
    Req/Sec   257.79     43.32   353.00     73.50%
  5147 requests in 10.03s, 2.06GB read
Requests/sec:    512.91
Transfer/sec:    210.53MB

512.91req/sec、平均レイテンシ 28.82ms です。

参考までに WordPress の動的ページを直接叩いてベンチマークしてみます。

❯ wrk  -H 'Host: blog.teraren.com' http://localhost:8080/
Running 10s test @ http://localhost:8080/
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   611.64ms   94.75ms 948.43ms   74.05%
    Req/Sec     9.68      5.43    30.00     72.22%
  158 requests in 10.02s, 64.64MB read
Requests/sec:     15.77
Transfer/sec:      6.45MB

15.77req/sec、平均レイテンシ 611.64ms でした。

つまり、CDN を挟むことでスループットが 約34倍、レスポンス速度が 約21倍 改善しています。ここまで差が出ると CDN を使わない理由がありません。

WordPressで運用しているサイトはそのままで運用しているとキャパが少ないので普通はWP Super Cacheを入れて運用すると思いますが、Cloudflare CDN を使えばページキャッシュは CDN 側でやってくれるので、cache関連のプラグインもこの際にすべて削除しました。

Webサーバ側の設定が激減

WordPressのサイトでは1サイトあたり約100行削減できました。

{/* textlint-disable ja-technical-writing/ja-no-successive-word /} HTTPのリダイレクト、HSTS、text compressionの設定などなどを削減できてメンテナンス性が上がります。 {/ textlint-enable */}

# git diff --stat a9d832ed7f1493ea0ce8e75664e7a1b70f95760e matsu.teraren.com.conf
 nginx/conf.d/matsu.teraren.com.conf | 178 ++++++++++++++++++++++++++++++++++++++++------------------------------------------------------------------------------------------------------------------------------------------
 1 file changed, 40 insertions(+), 138 deletions(-)

TLS証明書更新から開放

以前はcertbotで自動で更新を書けていても、知らない間に動かなくなっていたりとか設定ファイルが変わっていたりして結局は手での運用が発生してしまっていました。

Let's encryptからの更新のお知らせのメールも一切期にしなくて良くなるので運用の手間からかなり開放されました。

TLS証明書に関連しては、HTTPからHTTPSのリダイレクト設定がスイッチ1つで行えたり、HSTSのヘッダ送信がUI上から行えるので非常に楽です。

HSTSの設定項目。

自宅サーバ用の固定IPまたはDynamic DNSが不要

tunnelをCloudflareに張るだけなのでローカルで動いているサービスをインターネット上に公開できるので自宅の回線に固定IPアドレスやDynamic DNSが不要になりました。

自宅ネットワークにDMZを作ったりVLANを切っている場合は、設定を無くせる場合もあります。（セキュリティ要件に応じてですが）

ポート開放が無くなった

外部から自宅のネットワークのポート開放を一切無くせました。Web系、SSHなどのリモートアクセス、場合によってはVPN関係のサービスを無くせます。

$ nmap <my home address>
Starting Nmap 7.93 ( https://nmap.org ) at 2023-04-22 11:40 JST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.04 seconds

自宅のIPアドレスを晒さなくても良くなったので安心感があります。

Webページのパフォーマンススコアが向上

Webサイトのベストプラクティスを自動的に、または簡単に導入できるためGT metrixのスコアが上がります。

まとめ

最初はCloudflareのCDNが無料なので調査していたら、CloudflareはCDN以外の機能もかなり充実していてしかも無料で使えるサービスが沢山あるので今回は無料で使えるサービスをフルに活用して安全で安定的なサービス提供をできるように設定をしました。

最初の設定が大変ですし、知識が必要になりますがその後は安心して高速で安全なWebサービスの提供を行えるようになります。

AtlassianをSP、Google WorkspaceをIdPとしてSAMLを設定する方法

Thu, 20 Apr 2023 00:00:00 GMT

概要

SAMLの証明書が切れたので設定箇所をメモしておきます。

SAMLに関する設定は2箇所あるので、両方を適切に設定する必要があります。

Atlassianのドキュメントには設定1に関する事項しか載っていないので不十分でした。

設定1

SAMLの証明書マスタの設定。有効期限が未来の証明書を作っておく

https://admin.google.com/ac/security/ssocert

設定2

Atlassianアプリの設定側で、設定1で作成した証明書を選択しておく。

https://admin.google.com/ac/apps/saml/93648076211/sp （数字のところが各自違うかも）

設定3

Atlassianの管理画面での設定です。

以下のような感じでURLや証明書をコピペします。

注意

証明書は5年とかで切れるので、手動で更新する必要があります。

末尾の半角スペースで困惑：ActiveModelとMySQLの連携問題

Fri, 14 Apr 2023 00:00:00 GMT

概要

ActiveModelのuniqueがあるアトリビュートの末尾に半角スペースがあると挙動がおかしくなるケースがありました。

問題

以下のようにcodeがユニークなアトリビュートを定義してあるとします。

class Product < ApplicationRecord
  validates :code, presence: true
  validates :code, uniqueness: true
end

上記の定義によれば、codeが 'aa ' と 'aa '（末尾に半角スペースが2つ）のオブジェクトが存在できますが、実際には登録できません。

以下のコードは正しく動くはずなのに、2つ目のオブジェクトがvalidになりません。

[2] pry(main)> p1 = FactoryBot.create(:product)
[3] pry(main)> p1.code = 'aa '
=> "aa "
[4] pry(main)> p1.save
=> true
[5] pry(main)> p2 = FactoryBot.create(:product)
[6] pry(main)> p2.code = 'aa    '
=> "aa    "
[7] pry(main)> p2.save
=> false
[8] pry(main)> p2.valid?
=> false
[9] pry(main)> p2.errors
=> #<ActiveModel::Errors:0x00007f6893d164d0
 @base=
  #<Product:0x00007f6893f534a0
   id: 2,
   code: "aa    ">,
 @errors=[#<ActiveModel::Error attribute=code, type=taken, options={:value=>"aa    "}>]>
[10] pry(main)>

ActiveRecord上では 'aa ' と 'aa ' が同一に扱われているようです。

検証するために、ActiveRecordでcodeをキーに検索してみます。同時に、発行されているSQLを確認してみます。

そうすると、末尾の半角スペースの数に関わらず、半角スペースが1つしか存在しないレコードがヒットしてしまいます。

[115] pry(main)> Product.where(code: 'test0410').first.code
  Product Load (1.0ms)  SELECT `products`.* FROM `products` WHERE `products`.`code` = 'test0410' ORDER BY `products`.`id` ASC LIMIT 1
=> "test0410  "

[116] pry(main)> Product.where(code: 'test0410  ').count
  Product Load (1.0ms)  SELECT COUNT(*) FROM `products` WHERE `products`.`code` = 'test0410  '
=> 1

[117] pry(main)> Product.where(code: 'test0410 ').count
  Product load (0.6ms)  SELECT COUNT(*) FROM `products` WHERE `products`.`code` = 'test0410 '
=> 1

[118] pry(main)> Product.where(code: 'test0410').count
  Product Load (0.5ms)  SELECT COUNT(*) FROM `products` WHERE `products`.`code` = 'test0410'
=> 1

発行されているクエリーは正しそうな感じはします。（文字列に対してLIKEではなくてイコールで条件を書いているのが若干微妙ですが）

SQLレベルで予期した動作をしていないので、SQLで検証してみます。

MySQL > update products set code = 'aa  ' where id = 2;
ERROR 1062 (23000): Duplicate entry '1-aa  ' for key 'products.index_products_on_code'
MySQL > update products set code = 'aa ' where id = 1;
Query OK, 0 rows affected (0.001 sec)
Rows matched: 1  Changed: 0  Warnings: 0

MySQL > update products set code = 'aa  ' where id = 2;
ERROR 1062 (23000): Duplicate entry '1-aa  ' for key 'products.index_products_on_code'

上記の内容により、MySQLの物理スキーマレベルで半角スペースの多さが同一に扱われてしまっています。

ということで問題はMySQLレベルにありそうです。

アプローチ

最近の私のアシスタント（GPT-4）に聞いてみました。

なるほど。PAD SPACEという概念は知りませんでした。

PAD SPACEというプロパティはcollationに従属している値です。

ということで、現在のカラムのcollationがどうなっているのかを調べてみます。

MySQL > SELECT COLUMN_NAME, COLLATION_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE  TABLE_NAME = 'products';
+-----------------------------+--------------------+
| COLUMN_NAME                 | COLLATION_NAME     |
+-----------------------------+--------------------+
| id                          | NULL               |
| code                        | utf8mb4_bin        |
+-----------------------------+--------------------+
34 rows in set (0.002 sec)

utf8mb4_binになっています。

この、utf8mb4_binがPAD SPACEなのかを調べてみます。

MySQL> SELECT COLLATION_NAME, PAD_ATTRIBUTE
    ->        FROM INFORMATION_SCHEMA.COLLATIONS
    ->        WHERE COLLATION_NAME LIKE 'utf8mb4_bin';
+----------------+---------------+
| COLLATION_NAME | PAD_ATTRIBUTE |
+----------------+---------------+
| utf8mb4_bin    | PAD SPACE     |
+----------------+---------------+
1 row in set (0.002 sec)

PAD SPACEでした。ということで、現在利用中のcollationがPAD SPCAE属性があるcollationのため、末尾の半角スペースがいくつあっても同一に扱われてしまっていました。

MySQLのオフィシャルドキュメントではここに記載してあります。

https://dev.mysql.com/doc/refman/8.0/ja/charset-binary-collations.html

そもそも、utf8mb4_binは、suffixにbinaryのbinが付いているのに、全然binaryで区別してくれなくて悲しいです。

テストコード

修正前と後でモデルが正常に動くかを検証するために、FactoryBotを使ったrspecのコードを書いておきます。

spec/models/product_spec.rb

require 'rails_helper'

RSpec.describe Product do
  it 'should be valid' do
    expect(create(:product, code: 'aa ')).to be_valid
    expect(create(:product, code: 'aa  ')).to be_valid
  end
end

失敗してしまいます。

root@455cbca12654:/app# bundle exec rspec  spec/models/product_spec.rb
Randomized with seed 53478
F

Failures:

  1) Product should be valid
     Failure/Error: p2 = create(:product, code: 'aa  ')

     ActiveRecord::RecordInvalid:
       バリデーションに失敗しました: codeはすでに存在します
     # /usr/local/bundle/gems/factory_bot-6.2.1/lib/factory_bot/evaluation.rb:18:in `create'
     # /usr/local/bundle/gems/factory_bot-6.2.1/lib/factory_bot/strategy/create.rb:12:in `block in result'
     # /usr/local/bundle/gems/factory_bot-6.2.1/lib/factory_bot/strategy/create.rb:9:in `result'
     # /usr/local/bundle/gems/factory_bot-6.2.1/lib/factory_bot/factory.rb:43:in `run'
     # /usr/local/bundle/gems/factory_bot-6.2.1/lib/factory_bot/factory_runner.rb:29:in `block in run'
     # /usr/local/bundle/gems/factory_bot-6.2.1/lib/factory_bot/factory_runner.rb:28:in `run'
     # /usr/local/bundle/gems/factory_bot-6.2.1/lib/factory_bot/strategy_syntax_method_registrar.rb:28:in `block in define_singular_strategy_method'
     # ./spec/models/product_spec.rb:6:in `block (2 levels) in <top (required)>'

Finished in 4.73 seconds (files took 2.42 seconds to load)
1 example, 1 failure

Failed examples:

rspec ./spec/models/product_spec.rb:4 # Product should be valid

Randomized with seed 53478

修正

no padのutf8mb4のbinaryに近いcollationを探してみます。

MySQL > show collation where collation like 'utf8mb4%' and collation like '%bin';
+------------------+---------+-----+---------+----------+---------+---------------+
| Collation        | Charset | Id  | Default | Compiled | Sortlen | Pad_attribute |
+------------------+---------+-----+---------+----------+---------+---------------+
| utf8mb4_0900_bin | utf8mb4 | 309 |         | Yes      |       1 | NO PAD        |
| utf8mb4_bin      | utf8mb4 |  46 |         | Yes      |       1 | PAD SPACE     |
+------------------+---------+-----+---------+----------+---------+---------------+
2 rows in set (0.004 sec)

こちらの比較表からしても、用途としては基本的にすべて区別したいのでutf8mb4_0900_binが良さそうです。

change_column :products, :code, :string, null: false, collation: :utf8mb4_0900_bin

migrationを実行した後にrspecを実行したら正常に終わりました。

root@6d3039d9f78e:/app# bundle exec rspec spec/models/product_spec.rb
Randomized with seed 38846
.

Finished in 2.95 seconds (files took 29.75 seconds to load)
1 example, 0 failures

Randomized with seed 38846

影響度調査

今回のような、サロゲートキーに対してUNIQUE KEYを貼って、厳密な検索や値を保管するときに問題になります。

今回は、商品コード関連で気づくことができました。他にも同じようなサロゲートキーの使い方をしている箇所が10箇所以上あったのでcollationをすべて見直しました。

サロゲートキーのカラム名をつける際に、命名規則に従っていれば以下のクエリーで一括で検索できます。

MySQL > SELECT table_name,COLUMN_NAME, data_type, collation_name  FROM INFORMATION_SCHEMA.COLUMNS where table_schema = '<your database name>' and column_name = 'code';
+----------------------+-------------+-----------+--------------------+
| TABLE_NAME           | COLUMN_NAME | DATA_TYPE | COLLATION_NAME     |
+----------------------+-------------+-----------+--------------------+
| table_1              | code        | varchar   | utf8mb4_0900_ai_ci |
| table_2              | code        | varchar   | utf8mb4_bin        |
| table_3              | code        | varchar   | utf8mb4_bin        |
| table_4              | code        | varchar   | utf8mb4_bin        |
| table_5              | code        | varchar   | utf8mb4_bin        |
| table_6              | code        | varchar   | utf8mb4_0900_ai_ci |
| table_7              | code        | varchar   | utf8mb4_bin        |
| table_8              | code        | varchar   | utf8mb4_bin        |
| table_9              | code        | varchar   | utf8mb4_bin        |
| table_10             | code        | varchar   | utf8mb4_bin        |
| table_11             | code        | varchar   | utf8mb4_bin        |
| table_12             | code        | varchar   | utf8mb4_bin        |
| table_13             | code        | varchar   | utf8mb4_bin        |
| table_14             | code        | varchar   | utf8mb4_bin        |
+----------------------+-------------+-----------+--------------------+
14 rows in set (0.006 sec)

まとめ

MySQLのcollationによって、カラムの値にある最後の半角スペースがいくつあっても同一に扱われる場合がある。

上記により、'aa ' と 'aa ' が同一に扱われる。

GPT-4すごい。

ちなみに、GPT-3.5だと的確な原因を指摘するところまではやってくれませんでした。

Raspberry PiのWiFiと有線LANに静的IPを振る

Sat, 08 Apr 2023 00:00:00 GMT

デフォルトだとDHCPからIPを取得するので面倒なため、静的IPを振っておきます。OSはRaspberry Pi Lite 64bit(Debian GNU/Linux 11 (bullseye))です

有線LANに 192.168.1.5/24、無線LANに192.168.1.6/24を振る例です。

基本的には設定がコメントアウトしてあるのでコメントアウトを外していくだけです。IPv6の固定アドレスはちゃんと運用しないので一旦は設定しません。ちゃんと運用しないし。

diff --git a/dhcpcd.conf b/dhcpcd.conf
index b34f11a..674fda9 100644
--- a/dhcpcd.conf
+++ b/dhcpcd.conf
@@ -41,11 +41,17 @@ require dhcp_server_identifier
 slaac private

 # Example static IP configuration:
-#interface eth0
-#static ip_address=192.168.0.10/24
+interface eth0
+static ip_address=192.168.1.5/24
+#static ip6_address=fd51:42f8:caae:d92e::ff/64
+static routers=192.168.1.1
+static domain_name_servers=192.168.1.1 1.1.1.1 fd51:42f8:caae:d92e::1
+
+interface wlan0
+static ip_address=192.168.1.6/24
 #static ip6_address=fd51:42f8:caae:d92e::ff/64
-#static routers=192.168.0.1
-#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1
+static routers=192.168.1.1
+static domain_name_servers=192.168.1.1 1.1.1.1 fd51:42f8:caae:d92e::1

 # It is possible to fall back to a static IP if DHCP fails:
 # define static profile

反映するためには以下のコマンドです。コマンドを打った瞬間ネットワークのインターフェイスがダウンするのでご注意ください。うまくいけば新しく設定したIPアドレスで接続できるようになります。

sudo ifconfig wlan0 down && sudo ifconfig wlan0 up

NICにIPが振られているか確認

IPv6, IPv4で接続性があるかを動作確認

HTTP, HTTPSの接続性も確認

Pintアプリの開発にFlutter + Firebaseを採用した理由とその結果

Fri, 07 Apr 2023 00:00:00 GMT

背景

2021 年 12 月ごろ、Pintの企画が完成に近づき、UXの要求がまとまりつつありました。

企画のユースケースを実現するためには慣れた Rails+Webview で構築するのが一番手っ取り早いですが UX があまり良くないので、ネイティブで構築するという方向性で検討を進めました。

アプローチ

速く、安く作るには iOS と Android 上で動作するクロスプラットフォーム対応のフレームワークを採用することが第一候補となります。

当時は、React Naive、IONIC Framework, Cordova などのフレームワークが存在していました。どれも一定のプロダクションのアウトプットは出せる感じがありました。しかし、開発者の定着度合いがあまり良くなかったり、微妙な UI があるためこの中から選ぶのはあまり良くないなという感覚がありました。

そして、当時は Flutter 2.8 がリリースされたあとでもあり、かなりいろいろなコンポーネントがリリースされてきて Flutter で作られたアプリケーションがちらほら出だしてきているときでした。

また、【初アプリ】未経験がFlutterで肉牛繁殖農家のためのアプリを作ってみたというアプリが1ヶ月ぐらいの開発で良さそうなUIのアプリがリリースされていました。これを見て、Flutterのポテンシャルがかなり高く、ユースケースも実現できそうというのはなんとなく感じてました。

新技術を使うときやフレームワークに乗る時にはやはりリスクが伴うので、カルチャーである Fail&Learn の考えのもと、薄く広く実装をしながら Flutter を学習しつつ実現したいユースケースを達成できるかというフィージビリティチェックも同時に進めていきました。

また、アプリ開発においてはフロントエンドとバックエンドの両方の技術選定を決める必要があります。そして、スタートアップなので速く、安く、持続可能な技術でプロダクトをデリバリーする必要があります。

もっと抽象的に作れるかを検討

Flutter より上位のレイヤーでノーコードに近い形でアプリを開発できたら良いなと思い、まずは FlutterFlow を検討してみました。

FlutterFlowはノーコードでFlutterアプリを構築できるというのが特徴です。デモのUI/UXもすごい良さそうに見えました。

サンプルが豊富にあることや、UI からアプリのコードを生成できる機能があるため、アプリの基本形を作るまでのスピードは非常に速く、プロトタイプ作成などで特に有効なツールかと感じました。また、毎週のように新機能が追加されており、活発なプロダクトであったことも印象的です。

とりあえず使ってみないとわからないので FlutterFlow をベースに開発を進めていましたが、手が届かないと感じる点も出てきました。 FlutterFlow にカスタムのメソッドを適用する機能もありますが、あくまで UI の何かの操作がトリガーのものに限定されるなど、カスタマイズ不能な範囲がどうしてもあります。例えば郵便番号のバリデーションのようにユーザーが入力中に動いてほしいものや、複雑なユーザーのルーティング条件が必要な場合には対応できないユースケースがありました。

そういったケースは、FlutterFlow から出力したコードを変更して対応します。 FlutterFlow からはソースコードに 1 方向でしか変換できないため、結局のところソースコードを書きかえていくと FlutterFlow 上の UI に差分が出つづけ、マージが手間になリます。

また、FlutterFlow だけでは本番・ステージングなどの複数環境の切り替え機能がないことも、CI/CD など環境を構築するに当たって重要な要件を満たせないこともわかりました。

こうした点を踏まえ、FlutterFlow の利用は諦めました。

Flutter上でDartを書くことに決定

FlutterFlow を使うときに、簡単なアプリであれば問題ないのですが、ちょっとはみ出たことをしようと思うとどう FlutterFlow を使って実現すれば良いのか、ドキュメントも少ない中で考える必要があります。

一方 Flutter は公式ドキュメントが非常に充実しており、結局 0 から開発するほうが自由度高く、かつ早く開発できました。これはローコード・ノーコードツール全般に言えることだと思いますが、ビジネス要件がきっちり決まっている場合は、実現できることをツール側に寄せる必要のある開発スタイルではなく、フルスクラッチで開発するのが良いと思っています。

また Flutter はウィジェットを組み立てて構築していくフレームワークなので、UI からアプリを組み立てていくことにこだわらなくても十分問題ないという言語特性もあります。

ソフトウェアアーキテクチャ選定

Flutter で構築する際に、重要になるのがソフトウェアアーキテクチャのモデル選定です。当時はデファクトスタンダードが無く、どれも一長一短ではありました。主に以下のアーキテクチャがオプションとしてはありました。

Stateful ウィジェット
MVC
MVVM
MVVM + repsitory

当時のトレンドの 1 つであった flutter-architecture-blueprintsをベースに、MVVM + repository の構成で設計を進めました。MVVM + repository に関する情報が Web に充実しておりまた最後発で様々なアーキテクチャ上の課題を解決しているためです。

利用したパッケージの紹介

今回、利用したパッケージの一部を紹介します。

riverpod + Flutter Hooks

状態管理には riverpod + Flutter Hooksを使用しています。 freezed Model を copyWith でイミュータブルに扱ったり、JSON の de/serialize したりといったコードの自動生成をするために使用しています。

flutter_gen

flutter_gen 画像などのリソースファイルへ安全にアクセスできるようにするため使用しています

search_choices

search_choices 銀行口座を一覧から選択する際に、多数の項目から選択する UI が多いです。こちらのパッケージを使用することでテキスト入力からリアルタイムにフィルタリングして項目を絞れ込めます。

バックエンドの選定

バックエンドは Firebase を採用しました。

Amplify なども検討しましたが、やはり Flutter と同じ Google が開発しているので、ドキュメント・パッケージともに Firebase との接続がサポートされているケースが多いです。また JSON で様々なデータが扱えたり機能ごとにきちんと結びつきがあったりと親和性が高いです。

Flutter を使って開発する場合はバックエンドを Firebase で構築するのがデファクト・スタンダードのような印象を受けました。 Firebase 上の処理が多くなってくるとコストが嵩んでくる問題はありそうでしたが、そのときには適宜バックエンドの再選定をしていくのが良いと思います。

Tips

Flutter で開発をしてみて、得られた知見をまとめておきます。

DartやFlutterの最新情報は要チェック

Dart や Flutter はマイナーバージョンの更新でも大きな仕様変更が入ります。例えば、2022 年 5 月の Dart2.17 です。enhanced-enum という、enum の拡張機能が追加されたのですが、こちらが release されるまでは enum を自ら拡張して実装する必要がありました。新興言語ということもあり、大きなアップデートが多いため、変化が多くて楽しいです。

アーキテクチャありきでなくても良い

FlutterFlow から切り替える際にはアーキテクチャから検討を始めましたが、まずは標準的な Stateful ウィジェットでの開発で進めても良かったかもしれません。

というのも、多くのパッケージにおけるサンプルは Stateful ウィジェットで記載されているため、riverpod + Flutter Hooks を軸にしてしまうと、慣れるまでは置き換えるプロセスで手間がかかります。特に Flutter 未経験の状態であったこともあり、なおさら標準スタイルで進めた方が結果的にリリースまでのスピードが速かったのかなと感じることがあります。もちろん自社のリソースの技術スタックによりますが、まずは素直に Flutter の公式ドキュメントをベースに進めていくのが一番の近道かもしれません。

最初からきちんとデザインする

デザイナー不在もあり、今回の開発では未経験者の PdM が Material Design 等を無視してデザインをしましたが振り返ってみれば、Material Design を学んでもらって、それに則った開発をするべきだったなあという公開があります。それをすればテーマを当てるだけでよくなるのでコードが軽量化され実装面でも楽になります。

学習コストはかかりますが、トータルで考えたときにペイするので、デザイナーがいない状態でも最初から Material Design に則って設計するべきだと思います。

もちろんエンジニアも Material Design を理解しデザインを作る人とコミュニケーションを取れるようにすることが重要です。

終わりに

Flutterを採用してどうだったか？

回り道もありましたが、総じて Flutter を採用したことは非常にプラスだったと感じています。結果的にネイティブ開発の知識はビルドなどに関する設定が必要だった程度で、今回のチームでも無事に Android/iOS ともにストアへのリリースまで進めることができました。

実際に開発してみたところ、Native で書くところはほとんどなく、Swift + Kotlin より早く、楽に開発できました

Pint のアプリをリリースしてから半年が経ち、Flutter の勢いは当時よりも増しているように感じます。現時点では Pint アプリは今後も Flutter で開発、運用を続けます。

Pintについて

Pint はアプリを経由するだけで Amazon や楽天などの EC サイトでのお買い物でポイントがもらえるサービスです。この機会にぜひインストールして活用してみてください！

Google WorkspaceとAzure ADFS環境でOffice 365のSAML証明書を更新する手順

Wed, 05 Apr 2023 00:00:00 GMT

概要

ある日、突然 Office 365 へログインできなくなりました。

Error: malformed_certificate

原因は SAML の有効期限切れだったので、問題の発見方法と設定手順を説明します。

背景

弊社のアカウント管理がどのようになっているかを以下に説明します。

Google Workspace を利用しているので Google Workspace のユーザマスタを主として運用している。
Microsoft Azure を利用して ADFS(Active Directory Federation Service)を使っている。
ADFS を利用することによって Office 365 のユーザを ADFS のユーザと同期できるようになってライセンス付与を自動化している。

上記の設定によって以下のようなユースケースを実現しています。

ユーザマスタ管理者が Google Workspace 上でユーザを作成
自動的に Microsoft Azure の ADFS にユーザ情報が同期される（5 分ぐらいかかる）
Office 365 のライセンスが Organization Unit に応じて付与される。

当時、ADFS の設定をしたときにはドキュメントがほとんど存在していなくて設定をするのにまる 1 日ぐらいかかったと思います。今、検索してみたら以下の記事にわかりやすくまとまっているのを見つけました。

https://zenn.dev/cestquigucci/articles/59175c03342c66

(当時、手順書をかブログにまとめようと思っていましたが複雑だったのと、色々トライアンドエラーをしていたし、スクショにマスクをしないといけなかったりで面倒なので諦めました)

原因

最初に挙げた問題に対して軽く調べましたところ、原因は Google Workspace 上の Microsoft 365 アプリで発行した SAML の証明書が切れたからでした。

SAML 連携の設定時に Service Provider へ IdP で発行した証明書を登録します。関連づいている証明書はこちらから確認できます。スクショではすでに更新済みなので有効期限が未来になっています。

上記のボタンを押すと証明書の削除や新規発行が行える画面になるのでここで証明書の管理をします。本来なら有効期限が切れる前にこの操作をして登録をしておく必要があります。

更新手順

ADFS 環境にて SAMLを設定するための手順書は存在しているのですが、更新する際の手順書が見つかりませんでした。

この更新作業には Windows の PC が必要になります。Windows が手元に無いので Azure の VM を立ち上げて作業します。

ちなみに、Azure 上の PowerShell で更新ができたら楽だったのですができませんでした。

Azure 上で適当に Windows を立ち上げます。無料クレジットがあると思いますので、無料で立ち上げられると思います。

手元の mac から Remote Desktop を使ってこの VM へ接続します。PowerShell を立ち上げます。

まず、設定を確認してみます。以下のコマンドで ADFS に使っている SAML の設定情報を出力します。

$DomainName = "example.com"
Get-MsolDomainFederationSettings -DomainName $DomainName

古い証明書が登録されていることを確認しておきます。

まず、Federatedの状態を解除してManagedにします。

Set-MsolDomainAuthentication -Authentication Managed -DomainName example.com

以下のようなコマンドを打ち込んで、SAMLの設定を更新します。 xxxxxxxx は伏せ字です

$ssoUrl = "https://accounts.google.com/o/saml2/idp?idpid=xxxxxxxx"
$entity = "https://accounts.google.com/o/saml2?idpid=xxxxxxxx"
$domain = "xxxxxx"
$cert = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

Set-MsolDomainAuthentication -Authentication Federated  -DomainName $domain -ActiveLogOnUri $ssoUrl -PassiveLogOnUri $ssoUrl -IssuerUri $entity -LogOffUri $ssoUrl -SigningCertificate $cert -PreferredAuthenticationProtocol SAMLP

証明書が更新されているかを以下のコマンドで確認します。

$DomainName = "example.com"
Get-MsolDomainFederationSettings -DomainName $DomainName

そのあと、以下のコマンドを打ち込んでドメインの状態がFederatedになっているかを確認します。

Get-MsolDomainFederationSettings

テスト

Google WorkspaceのOffice 365のアプリ画面から TEST SAML LOGIN をクリックしてログインが成功するかを検証します。冒頭のエラーが出なくログインできれば成功です。

最後に、立ち上げたVMを綺麗サッパリ削除して終わりにします。

考察

Federatedを解除しないで更新できるか？

できませんでした。 Set-MsolDomainAuthentication コマンドを使って新しい証明書を設定しようとしましたができませんでした。コマンド自体は成功しますが、証明書が書き換わりませんでした。

VMを立ち上げないでCloud Shellでできるのか？

Connect-MsolService で接続できないので無理かなと思います。

自動更新できないのか？

でき無さそう。自分でリマインダーを設定しておきましょう。

WordPressのoptions.phpページで保存できないときの対処法

Fri, 31 Mar 2023 00:00:00 GMT

WordPressで、「options.php」ページにて、image_default_link_typeをfileに変更して、「変更を保存」をクリックすると、「設定を保存できませんでした。」と表示されて変更できませんでした。

調べてみると、max_input_varsの値がデフォルトでは1000なのですが、options.phpの項目が1000個以上あるから弾かれているようです。

[root@ip-172-26-15-xxx etc]# git diff

diff --git a/php.ini b/php.ini
index aa8acc8..6459620 100644
--- a/php.ini
+++ b/php.ini
@@ -397,7 +397,7 @@ max_input_time = 60
 ;max_input_nesting_level = 64

 ; How many GET/POST/COOKIE input variables may be accepted
-; max_input_vars = 1000
+max_input_vars = 2000

 ; Maximum amount of memory a script may consume (128MB)
 ; http://php.net/memory-limit

この値を適当に2000にして、PHPを再起動したら保存できました。

systemctl restart php-fpm.service

CloudWatchのlog insightでの調査例

Thu, 30 Mar 2023 00:00:00 GMT

アプリケーションのログがJSONで保存されているときの調査サンプル

filter @logStream like 'app/app/'
| filter @message like /include/
| filter @message not like /exclude/
| filter duration > 100
 | fields @timestamp, @message, duration

slackで最終営業日にリマインダーを設定する方法

Thu, 30 Mar 2023 00:00:00 GMT

正確には日本の休日マスタを使わないと出せません。

とりあえず簡易的には以下で設定できます。

/remind #channel or @your_username [メッセージ] at [時間] on the last weekday of the month

例

/remind #general 今月の報告書を提出してください at 3pm on the last weekday of the month

Automatically delete head branchesの宗教論争

Tue, 28 Mar 2023 00:00:00 GMT

概要

githubのレポジトリ運用において「Automatically delete head branches」をonにするかoffにするか悩ましいところです。

デフォルトはoffです。

GPTに聞いてみた

Q: githubのrepositoryの設定にある、 "Automatically delete head branches" をonにするかoffにするか悩んでます。どちらのほうが一般的でしょうか？

A: 「Automatically delete head branches」の設定は、プルリクエストがマージされた後に、そのブランチを自動的に削除する機能です。この設定をオンにするかオフにするかは、チームやプロジェクトのワークフローと好みによって異なります。しかし、一般的な考え方をいくつか紹介します。

オンにする利点:

リポジトリがきれいに保たれる: 不要なブランチが自動的に削除されるため、リポジトリが整理されやすくなります。
ブランチの管理が楽になる: 作業が完了したブランチを手動で削除する必要がなくなり、メンテナンスが容易になります。

オフにする利点:

履歴の追跡: ブランチが削除されないため、過去の変更履歴を容易に確認できます。
再利用可能: 削除されないため、同じブランチを再利用して追加の変更ができます。

最終的には、チームやプロジェクトの要件に基づいて判断してください。機能を試してみて、適切な設定を見つけるのも良い方法です。

考察

まさに論点はGPTに聞いた内容といのですでに考えてました。

インサイトとしては、onにしている方が多いという情報です。

そして、onとoffのいいとこ取りはできないかと思って探していたら見つけたのがこちら。古いブランチを削除するというGithub Actionsです。

https://github.com/beatlabs/delete-old-branches-action

これであれば参照頻度が低くて、再利用の可能性が低いブランチを積極的に消せます。

私の主張

ちなみに私は残しておく派。

tigで見たときにブランチの目的が追いやすいから。

そして、やっっぱりremoteにpushした情報って消しちゃいけないと思うんですよ。他の誰かがtrackingしているかもしれないのでブランチが消えると追いづらくなってしまいます。

容量は食わないし、見づらくなるぐらいのデメリットぐらいしか無いので、どんどんstockしていくのが根本かなと思います。

もし、ブランチ名を消す運用をしていて、再度同じブランチ名で別のfeature branchを作り出したときにURIの指す中身が違ってしまうというのもあるからブランチ名はレポジトリーに対してユニークになっていることも重要です。

GPT-4を使って既存のRailsアプリケーションにヘルスチェック機能追加をしてみる

Sat, 25 Mar 2023 00:00:00 GMT

概要

GPT-4 の性能が良いので既存の Ruby on Rails で動いているアプリケーションに機能を追加して本番へリリースできるクオリティを目指します。
GPT に指示出しをして PoC を作らせるのは簡単なので、今回はプロダクションレベルに出して良いレベルのコードを出力させて本番にデプロイします。

機能要求

最近、個人開発しているサービスのコンテンツをCDNに乗せました。originの外形監視のためにヘルスチェック用のエンドポイントが必要になったのでその機能を実装してもらいましょう。

実装の難易度はかなり低いですが、細かいところの評価ポイントがあります。

作る人によって Controller の名称が微妙ではないか？
返却される JSON データのキーの名前が微妙ではないか？
rspec を書いてくれるか？

実装

一発目は、とりあえずエンドポイント名だけを指定してコードを書いてもらいました。

なかなか良いです！　しかしながら文字列で時間を返されてもちょっと扱いづらいので Unix タイムスタンプで返してもらおうと思います。

期待通りのコードができました。しかし、実装だけなら誰でもできる！殆どのエンジニアが面倒だなと思うテストコードも書いてもらいましょう。

まぁ、90 点ぐらいのできです。

ちょっとこのコードでは 100％テストが通るとは限らないので修正してもらいます。

ヒントを与えすぎてしまったかもしれませんが、理想のコードになりました。

なぜ今年の元旦の日付に固定したのかは不明です。べつに Time.zone.now と書いたほうが良いです。コード量が削減できますし、マジックナンバーも減ります。まぁ、細かいことは気にしないで良いです。

しかしながら惜しいです。細かいですが、rubocop で指摘されるような細かい指摘をしてみました。

GPT に書かせて、rubocop -a を使って自動に校正できるような内容なので全く問題無いです。

テスト

上記のコードをコピー&ペーストして、rspec を実行してみます。

% docker compose run --rm app bundle exec rspec spec/controllers/healthcheck_controller_spec.rb
[+] Running 2/0
 ⠿ Container train-chrome-1  Running                                                                                                    0.0s
 ⠿ Container train-db-1      Running                                                                                                    0.0s

Randomized with seed 11651

HealthcheckController
  GET #index
    returns http success
    returns current time in unix timestamp format

Top 2 slowest examples (0.05121 seconds, 94.6% of total time):
  HealthcheckController GET #index returns http success
    0.0462 seconds ./spec/controllers/healthcheck_controller_spec.rb:13
  HealthcheckController GET #index returns current time in unix timestamp format
    0.005 seconds ./spec/controllers/healthcheck_controller_spec.rb:18

Finished in 0.05413 seconds (files took 2.79 seconds to load)
2 examples, 0 failures

Randomized with seed 11651

素晴らしいです。1発で成功しました。

つぎに、実際にHTTP経由で叩いてみましょう。

% docker compose up
% curl -s http://localhost:3001/healthcheck.json | jq
{
  "time": 1679753425
}

成功しました！　完璧です。

こうして作られた機能が以下のURLになります。 https://train.teraren.com/healthcheck.json

成果物

今回作ったコードをdiff形式で以下のURLにおいておきました。

そのまま取り込めば同じ機能を自分のプロジェクトにそのまま使えると思います。

https://gist.github.com/matsubo/ba0db8ba1386119ff0ffff1142a038ba

% cd <root of rails project>
% curl https://gist.githubusercontent.com/matsubo/ba0db8ba1386119ff0ffff1142a038ba/raw/1c5b63a98a366fb566aad998dba636f0d3900ba8/healthcheck.diff | patch -p1

そもそも

1 つ上位の視点で考えると、なんで Chat-GPT の結果を自分でコピー&ペーストして、他のプロジェクトに利用できるように diff を貼り付けているのだろう。ここまでの流れをやらせれば良いのでは？　と思いました。

試しに、Chat-GPT4 に diff を出させてみました。

ちゃんと出力されています。

ここまで、長々と GPT4 と対話して成果物を作製しましたが、以下のように司令を書けば 1 発で終わります。

ここで言えることは、issue に書くようなフォーマットで実装を見越して要求定義をしっかり書けばコードを生成してくれます。プロジェクトで共通の事項である rspec がインストール済みといったことは 1 回覚えさせてしまえば良いので省略できます。

まとめ

簡単な実装ならばコードを生成できそうです。
当初、懸念していたキーワード選定の正しさや、テストコードの正しさはほぼ私のコーディングスタイルと一致しているので違和感は無いコードが出てきました。
単純に要求を書いて、出されるようなコードは 100 点のコードは出てきません。事前条件の設定や、要件の設定でチューニングするのが良いです。

HSTS (Http Strict Transport Security)を設定

Sun, 12 Mar 2023 00:00:00 GMT

HSTSについての説明はこちらに詳しく書かれています。

https://zenn.dev/harusame0616/articles/b285a061e0c1f9

HSTSのpreloadに登録

HSTSのpreloadに登録するための設定は簡単です。

ドメイン自体のAレコードのURLに対して、HTTPヘッダを1つ追加するだけです。

HSTSのpreloadに登録するためには要件が厳しいです。以下の3つを満たす必要があります。

includeSubdomainも付加
有効期限は1年以上
preloadの指定

HSTSのpreloadのリストはグローバルで1つなのでリストの肥大化を防ぐためにもドメインレベルでしかも長期的に保持するような方針です。

nginxの場合は以下の1行を適切なブロック(serverあたり)に足すだけです。

server {
  add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';
}

Apacheの場合は以下の1行を適切なディレクティブに足すだけです。

Header add Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

対応ドメインの登録をする場合は以下のサイトでドメイン名を入力してSubmitします。

https://hstspreload.org/

Submit後はすぐに登録されるわけではなく、保留されてから登録されるようなのでしばらく待ちます。

ホストごとにHSTSを設定する場合

上記の場合はHSTSのドメインレベルでの登録、ドメインレベルでのHSTS preloadを登録しました。

各ホストごとにもHSTSは設定できるので必要に応じて設定すれば良いと思います。

例えば、以下のような感じで有効期限を指定するだけのようになります。(有効期限は1週間の例)

server {
  add_header Strict-Transport-Security 'max-age=604800';
}

HHKB Proをオキシクリーンで掃除してルビング

Sat, 11 Mar 2023 00:00:00 GMT

概要

2020年1月にHHKB Pro Hybrid Type-Sを買ってからほぼ毎日2年間ちょっと使ってきました。

最近、グリスアップが良いという記事を見たのでHHKBの掃除とグリスアップをしました。

::amazon{asin="B082TWFV9C"}

掃除前

隙間に白いホコリが混入しています。ベースのほうにもゴミが溜まっているのが見えます。ブロアで頑張ってもなかなか落ちません。

キープラーで抜いていきます。

::amazon{asin="B0047MQJ4I"}

キートップを外したところ。汚いです。髪の毛も5本ぐらい溜まってます。

キーボードの汚れは油汚れだと思うのでぬるま湯でオキシ漬けします。

::amazon{asin="B08T6WTVBG"}

キーボードのベース部分は分解するのが面倒なので、綿棒で掃除します。こちらも油汚れなので強アルカリ電解水の15倍濃縮液を使って汚れを拭き取ります。

::amazon{asin="B07874LQX1"}

綿棒は小さいのと普通サイズを用意しておくと細かいところを掃除できます。

汚い。特に、スペースバーの左右にある部分に汚れが溜まりやすかったです。キーのセンサー内部にゴミが入りかけていました。

その間に、オキシクリーンしていたキートップのつけ置きの時間が終わりました。やばいものが出てくるかと思いましたが、普通です。油やホコリが浮いてきてます。

網ですくいます。

内部に水が溜まりやすいので全部綿棒である程度吸い取ります。キッチンペーパーの上でやると良いです。

無刻印なので、どこに戻すのかがわからなくなりました。

HHKBは列ごとにキートップの形が違います。しかも、1つ1つキーの裏には型番が振られています。以下のような表がWeb上にいくつか合ったので参考にしようとしましたが存在しない型番が7割ぐらい。残り3割が存在する型番という状況でした。

https://sisidovski.hatenablog.com/entry/2017/11/25/124457

ノギスで計測した結果、型番による違いは無さそうなのでアルファベットのキーは適当にはめました。

このキートップたちは、大まかに4種類の形があります。

キートップをはめるときにグリスアップをしました。以前、5つのキーだけ試しにグリスアップをしてみたら静音化と潤滑性が確認できたのですべてのキートップに塗ります。

グリスアップをして感じるのは、キーボードを購入した直後の滑らかな打鍵音がもとに戻った感じです。経年変化することで樹脂同士が触れ合ったときのかすかに「カサッ」となるノイズがなくなりました。

https://www.youtube.com/watch?v=EOSi1RKwuFs

その反面、グリスはホコリを吸着してしまうというデメリットもありそうです。

下の写真は塗り途中。軸の外周に塗ってベース部分と触れるところに塗りました。

使ったグリスはこちら。グリスの量の割には高いですが刷毛も付いていますし、これだけ買えばすぐに使えるので良しとします。205g0という種類が良いらしいです。

::amazon{asin="B09QQ8XCT4"}

205g0グリスの特性

完成図。型番による違いは無さそうで良かったです。

「キートップの型番によって表面の湾曲率が違う」みたいな書き込みがあって不安でしたが、大丈夫っぽいです。

PCを使うデスクではなるべく食べ物を食べないように気をつけてはいましたが、ホコリの混入や髪の毛の混入は避けられません。それにプラスして樹脂部分が触れ合う構造なのでその部分をメンテナンスするべきだと思うので分解掃除は1年に一回ぐらいはしたほうが良いのかなと思います。

キートップの着け外し自体にもキートップ自体に負担はかかるので頻繁にやりすぎるのも良くないかなと思います。

Github Actionsでdocker composeのlayer cacheを使って実行時間を約3分短縮

Tue, 07 Mar 2023 00:00:00 GMT

背景

GitHub Actions で CI を回しています。
昔にセットアップしたプロジェクトで GitHub Actions の cache 機能が使われていませんでした。

アプローチ

いろいろな設定方法がありますがコード量が多くてきれいじゃないです。
docker compose を利用しているので Docker の build cache を流用できたら楽だなぁと思ってました。
CircleCI では Docker レイヤーキャッシュ (DLC)によってbuild cache が保管されるのですが GitHub Actions ではこれに対応する機能がありません。
今回見つけた actions では、GitHub Actions の Cache 機能を使って DLC をエミュレートしてくれるような動きをしてくれます。

設定

差分はこれだけです。この追加した action の中でキャッシュストレージへの保存と読み込みをやってくれます。


jobs:
  rspec:
    runs-on: ubuntu-latest
    timeout-minutes: 30
    env:
      TZ: Asia/Tokyo
      RAILS_ENV: test
    steps:
      - uses: actions/checkout@v3
        with:
          submodules: recursive
+      - uses: docker/setup-buildx-action@v2
+      - uses: docker/build-push-action@v4
+        with:
+          context: .
+          cache-from: type=gha
+          cache-to: type=gha,mode=max
      - name: Setup docker
        shell: bash
        run: |
          docker compose -f docker-compose.ci.yml build --progress=plain
          docker compose -f docker-compose.ci.yml pull -q

上記の設定を入れた上で、GitHub Actions で CI を回してみた結果です。

実行

Actions の Caches には以下のように保存されています。

ベンチマーク

CI 全体で 2 分 47 秒が短縮されました。実行時間比率で言えば、19.8％短縮しました。

実行時間の内訳

3 分 29 秒かかっていた build が 42 秒で終わるようになっています。

初回実行

cacheからロードして実行

考察

Docker build にタグ付けしてロードしたりキャッシュしたりするようなロジックを書いているケースに対しても、今回紹介した設定に置き換えるだけで同等の効果があると思います。
今までは、キャッシュの操作を手動で書いていたのが、Docker の中間キャッシュに完全に任せられるので楽になると思います。
Dockerの中間キャッシュを使うロジックを理解した上で使う必要があります。
今回は rspec 用のテストの紹介ですが、ECS に deploy するときの image を作る際にも使えると思います。

まとめ

GitHub Actions の Cache を使って、Docker compose の build 時に使用する layer cache を有効利用するようにしました。
実行時間が 3 分近く短縮しました。

NURO Wireless 5G注意報：レンタルモデムの不安定さを知っておこう！

Mon, 27 Feb 2023 00:00:00 GMT

概要

NURO Wireless 5Gの基地局アンテナが直線距離20メートルに設置されたのでテストしてみます。
理論値で4.1Gbps出るとのことなので期待したいです。
7日間はキャンセル可能です。

レンタルルーター

5Gアンテナとルーター、WiFi APが1つに詰まったものになります。

IEEE 802.11axに対応しているのでWiFi-6対応です。

所感

キャリアの電波周波数が5GHzということもあり、見通しで直接アンテナが見える状態に設置したときとしていないときの差が大きいです。
特にアップロードの差が大きくて、屋外の直接見通せるところに設置すると、300Mbps, 部屋の中に設置すると40Mbps程度になります。
IPv6アドレスが振られます。先頭の64bitも動的に振られます。
ルーター本体は重いです。発熱もそこそこあります。ほんのり温かいです。冬に20度の室内で低負荷で稼働していて、表面温度が40度ぐらいです。

ベンチマーク

早速、測定してみます。

測定

屋外にルーターを置いて遮蔽物がない状態で計測してみます。無駄なCPU消費を抑えるために2GHz帯は無効化してあります。

WAN
- 屋外見通し 20m
LAN
- WiFi IEEE802.11ax

WiFi

Fast.com

補足:

Cloudflareのスピードテストの方は、fast.comより遅い結果となったのでnuro局内からcloudflareへの帯域が細そうです。
WiFi6は実測値でも1.5Gbpsくらい出るのでWiFiがボトルネックにはなっていないはず。

問題点

しばらく使っているとクリティカルな問題が発生しました。

事例1

24時間ほど運用していたところ、インターネットまたはWiFiの接続が不安定になりました。ルーターの電源を入れ直して復帰しました。

WiFiにはたまに1台だけが接続されるという程度しか利用していません。というか、このWiFi APに接続していると、自然と接続が切れて既存の別のSSIDに勝手にフェイルオーバーされます。

下のスクショは、WiFiにつながっているPCからCloudflare public DNSにpingを打ってみたところです。ほとんど繋がりません。

事例2

事例1のあと4時間後にまた同じ問題が発生しました。

今回も同様にインターネットまたはWiFiの接続が不安定になりました。

しばらくpingの様子を見ていたら、調子が良くなりました。そして、また調子が悪くなったりします。

インターネット回線が調子悪いのか、WiFiが調子悪いのかを簡易的に判定するためにpingを打ち続けました。

pingの送信先はcloudflareのDNSキャッシュサーバと、モデムのLAN側に付与されているIPアドレスです。

LANのパケットがロスしていることから察するに、WiFiのアクセスポイントが調子悪そうです。

ルーターのWiFi機能が不安定なのであれば、レンタルしているモデムには有線のポートが付いているので別途自分で用意したWiFiアクセスポイントを設置すれば解決できます。

参考のために、別の固定回線の計測結果です。TTLにばらつきはありますがパケットロスは無いです。本来ならばこのぐらいの速度で安定して送信できるべきです。

事例3

10時間後、またレンタルしているモデムのWiFiアクセスポイントが不安定になった。

事例4

そのまた15時間後。レンタルモデムのWiFi APが不安定になった。ほとんど繋がらない。

左がCloudflare public DNSに対してのping結果。右がルーターのNICへのping結果。

不安定になるたびに、レンタルモデムの本体を再起動してますがしばらく時間が経過すると不安定になります。

RTTが遅い

既存の固定回線+WiFi APの平均RTTは27.295ms

--- 1.1.1.1 ping statistics --- 3233 packets transmitted, 3196 packets received, 1.1% packet loss round-trip min/avg/max/stddev = 10.485/27.295/3520.858/105.505 ms

NURO Wireless 5G (内蔵WiFi AP)の平均RTTは76.733ms。

--- 1.1.1.1 ping statistics --- 225 packets transmitted, 225 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 14.292/76.733/1602.545/205.341 ms

遅すぎます。テレカンするには若干テンポが遅れるし、ゲームをする人にとっては耐えられないと思います。

一応、有線LANでpingを測定して見た結果。

有線LANでpingを送信した結果。

左側がルータのNICへ。右側はCloudflareのpublic DNSへ。右側はaverage 19.818msでした。

参考のために、既存の回線でも計測してみました。

有線LANによる接続で、左側がCloudflare public DNSへのping, 右側がLANのルーターへのpingです。Cloudflare public DNSへはaverage 7.189msでした。

nuro 5G Wirelessのほうが3倍近くTTLが遅いです。

Latencyのまとめ。

参考までに、google meetでは300ms以下であれば問題ない数値と定義している様子。このグラフは固定回線＋無線LANのとき。片道だから10ms台。

静的NATができない

自宅サーバや、マインクラフトのサーバを立ち上げるときに普通に静的IPマスカレード、静的NATを行うだけでは公開できないです。

外部にサービスを公開したい場合はCloudflareといったtunnellingサービスを使う必要があります。とはいっても、安全性の面ではCloudflareを通したほうが良いのでこの点はどっちが良いとも言い切れない。

Cloudflare zero trustなどを使って回避はできます。自宅サーバからCloudflareにtunnelを貼って、private networkを作成して、接続する人はCloudflareのprivate networkに接続してもらう流れです。接続の際には、予め登録してあるメールアドレスなどの認証情報を元に接続します。

初心者にはかなりハードルは高いと思います。

ルーターの交換を申し出てみる

現状のWiFiが不安定に鳴る問題を共有し、（無駄なトラブルシューティングの）問答を20分ほど受けて、ルーターの交換をやっと受け付けてもらいました。

しかし、7日間のお試し期間の延長は不可能と言われました。

自分の持っている安定したWiFi APを接続して運用しても良いかなと思いましたが、1ヶ月分の課金をして、再度検証するのは手間がかかるし、回線のlatencyが76msは致命的に遅いので

その場で解約を申し出て、解約しました。

ちなみに、レンタルした機材を返却しない場合は、機器損害金（税込61,500円）が請求されるとのことでした。

まとめ

nuro wireless 5Gのlatencyが76msもかかり遅いです。
貸与されたルーターのWiFi AP機能が不安定すぎて使えない。

ZennのPublication機能を利用している組織一覧

Fri, 17 Feb 2023 00:00:00 GMT

背景

株式会社マインディアのテックブログをどこで書こうか考えてました。
ちょうど、Zenn で Publication機能がベータリリースされているので使ってみたいと思います。

なぜZennか？

執筆側
- 記事の管理を GitHub 連携できるのは便利で、linter をワークフローに入れられるので記事チェックするときに最低限のチェックを CI で回せるのは大きなアドバンテージとなるかなと思います。
- PR によるレビューができる。
- RSSのまとめによる運用ではSEOやまとめなどの機能がちょっと弱い。(まぁ、拡張すれば解決しますが。)
- catnose99さんの価値観に共感するところが大きいから応援したい。
オーディエンス側
- 読者は主にエンジニア。
- 記事の横移動の導線はある。
- SEO はさほど強い印象がない。
  - Qiita のほうが強い印象。
  - 中期的には Zenn が上がってくるはず（というか頑張って上げていきたい）

逆に、Zenn でテックブログを運用するときに欲しいなぁ思った機能

掲載、非掲載の承認機能
- 事後チェックという運用で回避
- publish しないで、URL への直接アクセスでチェックするという運用で回避
企業技術ブログみたいなFeedまとめは欲しい。
- はてブとの相乗効果が強いかもしれませんが。
- 最近、テックブログが分散していてアグリゲートしてくれるサービスがあると嬉しいので。
まとめ機能
- note でいうマガジン的なもの。
- feature 記事機能。
- 記事のスコープやオーディエンスに応じて publication 内で綺麗に整理して見せたい。

Publicationsの利用者

Publications がどのような感じで運用されているかを見てみたいのですが、Publications の一覧ページは存在しませんでした。

まぁ、このようなちゃんとしたサイトは XML Sitemap を出しているのでそこからたどってみます。

% curl -s https://zenn.dev/sitemaps/_index.xml | xq -x '//loc' | grep publication | xargs curl -s --output - | zcat | xq -x '//loc'
https://zenn.dev/p/monicle
https://zenn.dev/p/aidemy
https://zenn.dev/p/shelfy
https://zenn.dev/p/varygoodkun
https://zenn.dev/p/team_zenn
https://zenn.dev/p/churadata
https://zenn.dev/p/yumemi_inc
https://zenn.dev/p/vim_jp
https://zenn.dev/p/mixi
https://zenn.dev/p/cybozu_ept
https://zenn.dev/p/heartrails
https://zenn.dev/p/shiguredo
https://zenn.dev/p/sonicgarden
https://zenn.dev/p/moneyforward
https://zenn.dev/p/leaner_dev
https://zenn.dev/p/cybozu_frontend
https://zenn.dev/p/bascule_tech
https://zenn.dev/p/cybozu_neco
https://zenn.dev/p/homura_tech
https://zenn.dev/p/_adakoda
https://zenn.dev/p/chatwork
https://zenn.dev/p/labbase
https://zenn.dev/p/chot
https://zenn.dev/p/nanamusic
https://zenn.dev/p/videotouch
https://zenn.dev/p/manalink_dev
https://zenn.dev/p/spacemarket
https://zenn.dev/p/deepflow_tech
https://zenn.dev/p/rext
https://zenn.dev/p/babel
https://zenn.dev/p/lincwell_inc
https://zenn.dev/p/google_cloud_jp
https://zenn.dev/p/ricora
https://zenn.dev/p/peraichi_blog
https://zenn.dev/p/mutex_inc
https://zenn.dev/p/sre_holdings
https://zenn.dev/p/buyselltech
https://zenn.dev/p/solxyz_bso
https://zenn.dev/p/sharefull_blog
https://zenn.dev/p/tokium_dev
https://zenn.dev/p/spicato_blog
https://zenn.dev/p/funteractiveinc
https://zenn.dev/p/pepabo
https://zenn.dev/p/bluage_techblog
https://zenn.dev/p/morning_night
https://zenn.dev/p/tam_tam
https://zenn.dev/p/babyjob
https://zenn.dev/p/takeyuwebinc
https://zenn.dev/p/tailoor
https://zenn.dev/p/vallis
https://zenn.dev/p/ivry
https://zenn.dev/p/mirrativ_blog
https://zenn.dev/p/zozotech
https://zenn.dev/p/axelmark_tech
https://zenn.dev/p/noplan_inc
https://zenn.dev/p/innoscouter
https://zenn.dev/p/mofmof_inc
https://zenn.dev/p/iwakenlab_book
https://zenn.dev/p/ienter_blog
https://zenn.dev/p/hataluck
https://zenn.dev/p/microsoft
https://zenn.dev/p/beeworks_web
https://zenn.dev/p/altiveinc
https://zenn.dev/p/altura_x
https://zenn.dev/p/lmw
https://zenn.dev/p/paiza
https://zenn.dev/p/avita_blog
https://zenn.dev/p/makery
https://zenn.dev/p/medicalforce
https://zenn.dev/p/karabiner_inc
https://zenn.dev/p/siiibo_tech
https://zenn.dev/p/wasd_inc
https://zenn.dev/p/tellernovel_inc
https://zenn.dev/p/mierune
https://zenn.dev/p/techtrain_blog
https://zenn.dev/p/longrun_jp
https://zenn.dev/p/wwwave
https://zenn.dev/p/necscat
https://zenn.dev/p/ubie_dev
https://zenn.dev/p/thinkingsinc
https://zenn.dev/p/minedia
https://zenn.dev/p/singularity
https://zenn.dev/p/lclco
https://zenn.dev/p/eraman
https://zenn.dev/p/rescuenow
https://zenn.dev/p/cynekastam
https://zenn.dev/p/eishin_blog
https://zenn.dev/p/noxas
https://zenn.dev/p/loglass
https://zenn.dev/p/mapbox_japan
https://zenn.dev/p/naccare
https://zenn.dev/p/catallaxy_dev
https://zenn.dev/p/ncdc
https://zenn.dev/p/hackermeshi
https://zenn.dev/p/any_dev
https://zenn.dev/p/readyfor_blog
https://zenn.dev/p/overflow_offers
https://zenn.dev/p/praha
https://zenn.dev/p/fivot
https://zenn.dev/p/junni
https://zenn.dev/p/sucotech
https://zenn.dev/p/general_link
https://zenn.dev/p/cloudbase
https://zenn.dev/p/gaudiy_blog
https://zenn.dev/p/sarah
https://zenn.dev/p/folio_sec
https://zenn.dev/p/gemcook
https://zenn.dev/p/dena
https://zenn.dev/p/sakazuki_xyz
https://zenn.dev/p/ourly_tech_blog
https://zenn.dev/p/stafes_blog
https://zenn.dev/p/u2tech
https://zenn.dev/p/smartslide
https://zenn.dev/p/xbit
https://zenn.dev/p/aldagram_tech
https://zenn.dev/p/mybest_dev
https://zenn.dev/p/youngeek
https://zenn.dev/p/morisawa
https://zenn.dev/p/techtalk
https://zenn.dev/p/egstock_inc
https://zenn.dev/p/liquitous
https://zenn.dev/p/kthrlab_blog
https://zenn.dev/p/pakepu
https://zenn.dev/p/a11y_blog
https://zenn.dev/p/gumijp
https://zenn.dev/p/bohkai
https://zenn.dev/p/timetree
https://zenn.dev/p/commew
https://zenn.dev/p/sun_asterisk
https://zenn.dev/p/gu3
https://zenn.dev/p/pyspa
https://zenn.dev/p/no4_dev
https://zenn.dev/p/openly
https://zenn.dev/p/guildex
https://zenn.dev/p/less
https://zenn.dev/p/hirooict
https://zenn.dev/p/socialdog
https://zenn.dev/p/sharediary_app
https://zenn.dev/p/optfit_tech
https://zenn.dev/p/algoage
https://zenn.dev/p/toridori
https://zenn.dev/p/studio
https://zenn.dev/p/protooutstudio
https://zenn.dev/p/flutteruniv_dev
https://zenn.dev/p/microverse_dev
https://zenn.dev/p/airx_inc
https://zenn.dev/p/localworks_dev
https://zenn.dev/p/hacobell_dev
https://zenn.dev/p/miraistudio
https://zenn.dev/p/nocoinc
https://zenn.dev/p/beenos_tech
https://zenn.dev/p/gibjapan
https://zenn.dev/p/insight
https://zenn.dev/p/zoome
https://zenn.dev/p/third_tech
https://zenn.dev/p/devcamp
https://zenn.dev/p/team_soda
https://zenn.dev/p/qin
https://zenn.dev/p/fusic
https://zenn.dev/p/gamewith
https://zenn.dev/p/akinai_tech
https://zenn.dev/p/smartshopping
https://zenn.dev/p/thecreator
https://zenn.dev/p/ochakumi
https://zenn.dev/p/route06
https://zenn.dev/p/bi_knowledge
https://zenn.dev/p/stak
https://zenn.dev/p/dbttokyo
https://zenn.dev/p/bad_company
https://zenn.dev/p/purpom
https://zenn.dev/p/micin
https://zenn.dev/p/sbisecsol
https://zenn.dev/p/stmn_inc
https://zenn.dev/p/kwc_cpaas
https://zenn.dev/p/nkc_ug
https://zenn.dev/p/dataheroes
https://zenn.dev/p/lecto
https://zenn.dev/p/midra_lab
https://zenn.dev/p/gtn
https://zenn.dev/p/algorithms
https://zenn.dev/p/arklet
https://zenn.dev/p/sendo_tech
https://zenn.dev/p/she_techblog
https://zenn.dev/p/activecore
https://zenn.dev/p/hajimari
https://zenn.dev/p/voicelunchjp
https://zenn.dev/p/laiblitz_tech
https://zenn.dev/p/castingone_dev
https://zenn.dev/p/peco4ever_blog
https://zenn.dev/p/fraim
https://zenn.dev/p/carenet
https://zenn.dev/p/turing_motors
https://zenn.dev/p/todoker_blog
https://zenn.dev/p/salescore
https://zenn.dev/p/buzzkuri_tech
https://zenn.dev/p/team_delta
https://zenn.dev/p/sai_dev_blog
https://zenn.dev/p/red_frasco
https://zenn.dev/p/sweeep_blog
https://zenn.dev/p/devrel
https://zenn.dev/p/visasq
https://zenn.dev/p/docs_and_markup
https://zenn.dev/p/jawsug_bgnr
https://zenn.dev/p/line_dc
https://zenn.dev/p/mento_techblog
https://zenn.dev/p/voicy
https://zenn.dev/p/happy_elements
https://zenn.dev/p/azookey
https://zenn.dev/p/gohan_dao
https://zenn.dev/p/karadanote_tech
https://zenn.dev/p/synschismo_inc
https://zenn.dev/p/dotdtech_blog
https://zenn.dev/p/jotaifriends
https://zenn.dev/p/vs_blog
https://zenn.dev/p/urstudx_blog

件数

% curl -s https://zenn.dev/sitemaps/_index.xml | xq -x '//loc' | grep publication | xargs curl -s --output - | zcat | xq -x '//loc' | wc -l
215

運用していそうな知っている組織を目視でピックアップ

https://zenn.dev/p/google_cloud_jp
https://zenn.dev/p/mixi
https://zenn.dev/p/shiguredo
https://zenn.dev/p/microsoft
https://zenn.dev/p/visasq
https://zenn.dev/p/line_dc
https://zenn.dev/p/dena
https://zenn.dev/offers
https://zenn.dev/p/turing_motors
https://zenn.dev/p/spacemarket
https://zenn.dev/p/cybozu_ept
https://zenn.dev/p/cybozu_frontend
https://zenn.dev/p/cybozu_neco

ほかにも多数。

運用していないけど知っている組織

https://zenn.dev/p/buyselltech
https://zenn.dev/p/voicy
https://zenn.dev/p/mirrativ_blog

弊社（宣伝）

https://zenn.dev/p/minedia

まとめ

tech blog をどこで構築しようか考えてましたが、Zenn で構築している会社や組織はそこそこあるので、Zenn でよさそう。

Ruby on Railsプロジェクトのrubocop.ymlテンプレ

Wed, 15 Feb 2023 00:00:00 GMT

概要

最近、rubocop-rspecというrubocopのrspec用プラグインを見つけました。
数年前から存在しているようです。早速導入してみたところ、盛大に修正点を上げてくれて、ベストプラクティスを享受できたので感動しました。
このプラグインはあまり知られていないのかもしれないので記事にしておきます。

設定

私が育てたプロジェクトの rubocop.yml を置いておきます。

最近の rubocop はデフォルトではルールが厳しすぎるので、コードのみやすさやパフォーマンスに影響が少ないところは無効化しています。

  gem 'rubocop', require: false
  gem 'rubocop-performance', require: false
  gem 'rubocop-rails', require: false
  gem 'rubocop-rspec', require: false

inherit_from: .rubocop_todo.yml

## This configuration was generated by
## `rubocop --auto-gen-config`
## on 2017-11-25 11:44:56 +0000 using RuboCop version 0.51.0.
## The point is for the user to remove these configuration records
## one by one as the offenses are removed from the code base.
## Note that changes in the inspected code, or installation of new
## versions of RuboCop, may require this file to be generated again.

## Offense count: 15
## Cop supports --auto-correct.
## Configuration parameters: Include, TreatCommentsAsGroupSeparators.
## Include: **/Gemfile, **/gems.rb
require:
  - rubocop-rails
  - rubocop-performance
  - rubocop-rspec

AllCops:
  TargetRubyVersion: 3.1
  Exclude:
    - 'vendor/**/*'
    - 'db/**/*'
    - 'lib/tasks/**/*'
    - "db/schema.rb"
    - 'bin/*'
    - 'test/*'
    - 'node_modules/**/*'
    - 'config/initializers/**/*'
    - 'public/**/*'
    - 'storage/**/*'
    - 'log/**/*'
    - 'tmp/**/*'
    - 'terraform/**/*'
    - 'openapi/**/*'
  NewCops: enable

## sider's rubocop stops during this file
Rails/HttpStatus:
  Exclude:
    - 'app/controllers/application_controller.rb'

Rails/SkipsModelValidations:
  AllowedMethods:
    - 'touch'
    - 'upsert_all'

Layout/LineLength:
  Max: 200
  Exclude:
    - 'spec/**/*'
    - 'config/**/*'

Layout/ParameterAlignment:
  Enabled: false

Layout/EmptyLineBetweenDefs:
  Enabled: false

Layout/EmptyLines:
  Enabled: false

Layout/EmptyLinesAroundAccessModifier:
  Enabled: false

Layout/EmptyLinesAroundBlockBody:
  Enabled: false

Layout/EmptyLinesAroundClassBody:
  Enabled: false

Layout/EmptyLinesAroundMethodBody:
  Enabled: false

Layout/ExtraSpacing:
  Enabled: false

Layout/IndentationConsistency:
  Enabled: false

Layout/SpaceBeforeBlockBraces:
  Enabled: false

Layout/SpaceInsideHashLiteralBraces:
  Enabled: false

Layout/EmptyLinesAroundAttributeAccessor:
  Enabled: true

Layout/SpaceAroundMethodCallOperator:
  Enabled: true

Lint/DeprecatedOpenSSLConstant:
  Enabled: true

Lint/DuplicateElsifCondition:
  Enabled: true

Lint/MixedRegexpCaptureTypes:
  Enabled: true

Lint/RaiseException:
  Enabled: true

Lint/StructNewOverride:
  Enabled: true

Style/AsciiComments:
  Enabled: false

Style/ClassAndModuleChildren:
  Enabled: false

Style/Documentation:
  Enabled: false

Style/EmptyMethod:
  Enabled: false

Style/FrozenStringLiteralComment:
  Enabled: false

Style/GuardClause:
  Enabled: false

## Configuration parameters: Whitelist.
## Whitelist: be, be_a, be_an, be_between, be_falsey, be_kind_of, be_instance_of, be_truthy, be_within, eq, eql, end_with, include, match, raise_error, respond_to, start_with
Style/NumericPredicate:
  Enabled: false

## Readability is more important
Style/RedundantReturn:
  Enabled: false

Style/NumericLiterals:
  Enabled: false

Style/AccessorGrouping:
  Enabled: false

Style/ArrayCoercion:
  Enabled: true

Style/BisectedAttrAccessor:
  Enabled: true

Style/CaseLikeIf:
  Enabled: true

Style/ExponentialNotation:
  Enabled: true

Style/HashAsLastArrayItem:
  Enabled: false

Style/HashEachMethods:
  Enabled: true

Style/HashLikeCase:
  Enabled: true

Style/HashTransformKeys:
  Enabled: true

Style/HashTransformValues:
  Enabled: true

Style/RedundantAssignment:
  Enabled: true

Style/RedundantFetchBlock:
  Enabled: true

Style/RedundantFileExtensionInRequire:
  Enabled: true

Style/RedundantRegexpCharacterClass:
  Enabled: true

Style/RedundantRegexpEscape:
  Enabled: true

Style/SlicingWithRange:
  Enabled: true

Style/TrailingCommaInHashLiteral:
  Enabled: false

## Configuration parameters: EnforcedStyle, SupportedStyles.
## SupportedStyles: all_comparison_operators, equality_operators_only
Style/YodaCondition:
  # Readability is more important
  Enabled: false

Style/FormatStringToken:
  EnforcedStyle: template

Performance/TimesMap:
  Exclude:
    - 'spec/**/*'

Metrics/BlockLength:
  Exclude:
    - 'spec/**/*'
    - 'config/**/*'
    - 'app/views/api/v1/**/*'
    - 'app/models/order_product.rb' # aasm

Metrics/AbcSize:
  Enabled: false

Metrics/MethodLength:
  Enabled: false

Style/SymbolArray:
  Enabled: false

Style/RescueModifier:
  Enabled: false

Metrics/ClassLength:
  Enabled: false

Metrics/ParameterLists:
  Enabled: false

RSpec/NestedGroups:
  Enabled: false

Capybara/CurrentPathExpectation:
  Enabled: false

RSpec/MultipleMemoizedHelpers:
  Enabled: false

RSpec/ExampleLength:
  Enabled: false

RSpec/ContextWording:
  Enabled: false

RSpec/MultipleExpectations:
  Enabled: false

RSpec/LetSetup:
  Enabled: false

RSpec/Capybara/FeatureMethods:
  Enabled: false

RSpec/ChangeByZero:
  Enabled: false

Naming/VariableNumber:
  Enabled: false

最新版はこちらに置いておきます。 https://gist.github.com/matsubo/ec5b6cbf0a7207075e2b081f394863e6

CIでの実行おススメ

もちろんCI上でもrubocopを実行しているのですが、rubocopをオプション無しで実行するとフォーマットの準拠を1つでもしていないとfailします。

せっかくCIを回したのに、テストがfailしてしまうのはあまりよろしくないです。開発効率を上げるためにCIを入れているのに逆に悪くなってしまいます。

なので、プログラムの動作に影響しないようなstylingの準拠は無視するようにしています。そのためのオプションがこちら。

% rubocop --fail-level W

WARNIG 以上の問題だったら終了コードに 0 以外を返却して CI を fail させます。これによってわざわざコードのスタイルを準拠するために commit と push を行わなくて良くなるので気が楽になります。

Dockerを使ってHTTP3対応のnginxでホスティングしてみる手順

Sun, 12 Feb 2023 00:00:00 GMT

概要

HTTP3に対応したサイトが全世界のウェブサイトの中で25％あるらしいです。

nginxのroadmap上では、3年前からHTTP3が入っているのに2023年2月11日現在ではまだstableでのリリースは行われていません。

HTTP3を簡単に試してみるツール類は揃ってきているので今回は、HTTP3対応のnginxを使ってどんな感じの運用になるかをテストしてみます。

設定

前提

nginxをリバースプロクシとして動かし、バックエンドとしてlocalhostの3005番ポートでRuby on Railsサービスが動いているという前提です。

nginxにはlet's encryptで取得したTLS証明書を使ってhttpsで接続しています。

今回の対象サイト: https://train.teraren.com/

サーバサイドの設定

HTTP3のデフォルトでは、UDP443ポートを使います。デフォルトなだけで、任意のポートも利用できます。

とりあえず、以下のようなコマンドを打ち込んでみてUDPの443ポートが使われていないことを確認します。

% netstat -ln | grep 443 | grep udp

次に、以下のような設定ファイルを作成します。

設定ファイルの内容は適宜変更してください。TLS証明書のファイルの場所、ドキュメントrootの場所　を適宜変更します。

そして、docker composeで立ち上げればOKです。let's encryptのファイルの読み込みにはroot権限が必要になりますが、docker自体がroot権限で実行されるようなので一般ユーザで起動してもちゃんと読み込めてます。

% docker compose up

これで立ち上がります。

最後に、外部から接続できるようにfirewallやパケットフィルタの設定などでUDP 443への接続を許可します。

接続テスト

よって、まずはCLIを使ってテストしてみます。

% docker run -it --rm ghcr.io/unasuke/curl-http3:quiche-latest curl -IL https://train.teraren.com/ --http3

正常な結果

もし、HTTP3のnginxの設定が間違っていた場合は500系のエラーが返ってきます。

500系のエラー

HTTP3のnginxを立ち上げたdocker composeの標準出力にアクセスログやエラーが表示されるのでその内容をチェックすれば良いと思います。

HTTP3に対応していることをブラウザへ　告知

add_header alt-svc 'h3=":443"; ma=3600';

外部のチェッカー

何故かエラーになる。。。

https://http3check.net/?host=https%3A%2F%2Ftrain.teraren.com%2F

余談

自分の使っているブラウザがHTTP3に対応しているかどうかは以下のサイトなどでチェックできます。

https://cloudflare-quic.com/

手元のBraveブラウザではなぜかHTTP3での接続が行われない状態でした。

まとめ

HTTP3用nginxを立ち上げると、同じような設定を2箇所で管理しないといけないので面倒です。早くstableでHTTP3を対応してほしいです。
すでにlet's encryptで証明書を取得している場合は簡単にHTTP3を試せます。

Minecraft Server(統合版)をUbuntu上で起動する

Mon, 06 Feb 2023 00:00:00 GMT

概要

Ubuntu 22でMinecraftのBedrock(統合版)サーバを動かすための方法を記載します。(Bedrock版と、Java版が存在します。Java版を使っていない場合はBedrockを使えばOKです)
Minecraftのサーバは無料です。Linuxの操作に慣れていれば3分ぐらいでセットアップが完了します。

手順

Bedrockのサーバは以下のURLで公開されています。

https://www.minecraft.net/ja-jp/download/server/bedrock

以下に、現時点での最新のサーバをダウンロードして解凍する手順を記載します。

% mkdir bedrock
% cd bedrock
% wget https://minecraft.azureedge.net/bin-linux/bedrock-server-1.19.52.01.zip
% unzip bedrock-server-1.19.52.01.zip

起動方法

以下のコマンドを打てば立ち上がります。

% LD_LIBRARY_PATH=. ./bedrock_server

サーバを停止するためにはCtrl−Cを押せばサーバを終了できます。

ポート開放

サーバ自体にfirewallが設定されている場合は、以下の内容でポートを開放して外部から接続できるようにします。

IPv4で接続する場合は、UDPの19132を開放します。
IPv6で接続する場合は、UDPの19133を開放します。

サーバが自宅などのNAT内に置かれている場合は、ルータ上でパケットフィルタの解除と静的NATの設定（＝静的ポートフォワーディング）を変更してください。

このあとに、Minecraftから立ち上げたサーバのアドレスを指定してログインできれば成功です。

接続権限の設定

普通にサーバを立ち上げただけでは、全世界から誰でもアクセスが可能で、しかもメンバー権限で接続できてしまうので勝手に遊ばれてしまいます。

それを防ぐために、特定のユーザだけが接続して遊べるように設定をします。

server.propertiesをテキストエディタで開いて以下のように設定をしました。

1つ目のallow-cheatsはチートを禁止するようにする設定をしています。

2つ目はdefault-player-permission-levelでデフォルトの権限を設定します。他人が接続してきたときの権限を設定しておきます。最低の権限がvisitorしか無いのでvisitorを設定します。

diff  server.properties.default server.properties
23c23
< allow-cheats=true
---
> allow-cheats=false
79c79
< default-player-permission-level=visitor
---
> default-player-permission-level=member

次に、permission.jsonを編集して以下のようなフォーマットで遊べるユーザのIDを記載します。

$ cat ~/bedrock/permissions.json

[
  {
    "permission": "operator",
    "xuid": "2535406840148511"
  },
  {
    "permission": "operator",
    "xuid": "2535471542624633"
  }
]

上記の設定例では、2人のユーザを接続可能にしています。

xuidのIDは、Minecraftのアプリからサーバに接続するとログに出力されるので、その値をコピペします。

自動起動設定

自動起動の設定をしておかないと、サーバが途中で停止したときに自動で再起動されないので遊べなくなってしまいます。だいたい数日ぐらい遊ぶと勝手にサーバが落ちてしまいます。

自動起動の設定は別の記事に書きました。

https://blog.teraren.com/posts/minecraft-bedrock-server-setup/

Minecraft Server (統合版) をsystemdによる自動起動設定

Sun, 05 Feb 2023 00:00:00 GMT

概要

Minecraft BedrockサーバをLinux上で起動させてSystemd配下でサービスを管理する設定。
Minecraft bedrockサーバはしばらく立ち上げておくとメモリを食いすぎて勝手に落ちてしまいます。勝手に落ちたら手動で起動をするのが面倒なので systemd配下で管理して勝手に再起動をするように設定します。

設定内容

以下のREADMEに書いてあるコマンドの流れで設定します。

bedrock.serviceファイルのUserやbedrockサーバの実行バイナリが置いてある場所は各自の内容に置き換えてください。

備考

以下のサイトに紹介されている方法は余計なことが色々書いてあり、あまり使いたくなかったため自分で書きました。

https://minecraft.server-memo.net/bedrock_server_install_centos8/

https://gist.github.com/gatopeich/36ed7fab3850367bbcd8e6f40becd4e5

和暦や休日情報をREST APIで提供するサービスを公開

Mon, 09 Jan 2023 00:00:00 GMT

概要

以下の情報の取得や変換を行えるサービスを公開しました。

和暦→西暦変換
西暦→和暦
休日一覧
年齢

https://seireki.teraren.com/

APIの利用例

和暦を取得

今年に関する情報を取得。

% curl -s https://seireki.teraren.com/seireki/2023.json | jq
{
  "seireki": "2023年",
  "wareki": "令和5年",
  "eto": "卯",
  "age": 0,
  "url": "https://seireki.teraren.com/seireki/2023.json"
}

1950年生まれの人の年齢を取得

% curl -s https://seireki.teraren.com/seireki/1950.json | jq '.age'
73

2023年の休日一覧を取得

% curl -s https://seireki.teraren.com/holiday/2023.json | jq

[
  {
    "date": "2023-01-01",
    "name": "元日"
  },
  {
    "date": "2023-01-02",
    "name": "振替休日"
  },
  {
    "date": "2023-01-09",
    "name": "成人の日"
  },
  {
    "date": "2023-02-11",
    "name": "建国記念の日"
  },
  {
    "date": "2023-02-23",
    "name": "天皇誕生日"
  },
  {
    "date": "2023-03-21",
    "name": "春分の日"
  },
  {
    "date": "2023-04-29",
    "name": "昭和の日"
  },
  {
    "date": "2023-05-03",
    "name": "憲法記念日"
  },
  {
    "date": "2023-05-04",
    "name": "みどりの日"
  },
  {
    "date": "2023-05-05",
    "name": "こどもの日"
  },
  {
    "date": "2023-07-17",
    "name": "海の日"
  },
  {
    "date": "2023-08-11",
    "name": "山の日"
  },
  {
    "date": "2023-09-18",
    "name": "敬老の日"
  },
  {
    "date": "2023-09-23",
    "name": "秋分の日"
  },
  {
    "date": "2023-10-09",
    "name": "スポーツの日"
  },
  {
    "date": "2023-11-03",
    "name": "文化の日"
  },
  {
    "date": "2023-11-23",
    "name": "勤労感謝の日"
  }
]

Google SpreadsheetやExcelから利用する方法

Google Spreadsheetでは和暦を表示できません。Google App Scriptで西暦から和暦への変換プログラムを書いてよいのですが、なかなか複雑なので今回使ったサービスを使って和暦を表示してみたいと思います。

また、自分でロジックを書くと新たな和暦が登場したときにメンテナンスが必要になるという問題も発生します。

Google SpreadsheetではGoogle App Scriptを使うとREST APIの呼び出しと、JSONのパースができるようになります。

出力例とサンプルファイルのURL↓

https://docs.google.com/spreadsheets/d/1DiEUrZNH3Y7jJNrryQmRn04eMQO4zpoSHzKJg05Km38/edit?usp=sharing

Google App ScriptでREST APIを呼び出します。

function getWarekiFromSeireki(year) {

  const url = 'https://seireki.teraren.com/seireki/' + year  + '.json';

  try {
    ContactsApp response = UrlFetchApp.fetch(url, {'muteHttpExceptions': true});
    response_object = JSON.parse(response);
    return response_object['wareki'];
  }catch(e){
    Logger.log(e);
  }
}

その他

機能要望や不具合要望はDiscordの方へご連絡願います。

https://discord.com/channels/725542623594545233/1032168402925662229

AWS Organizationを導入した後にAWS IDを作る手順

Fri, 16 Dec 2022 00:00:00 GMT

備忘録。マニュアルは長ったらしいし、ベストプラクティスがよくわからないので、以下のような感じで運用していきます。

手順

上位OUのアカウントにログイン
AWS OrganizationsのページからAccountを作成（ここで言うAccountとはAWS IDのことを意味しています）
1. https://console.aws.amazon.com/organizations/home?region=ap-northeast-1
2. 利用するメールアドレスはエイリアス使ったほうが良いです。1メールアドレスに対して1つのAWS IDのrootアカウントしか紐付けられません。例: foo.bar+product-development@example.com
https://console.aws.amazon.com/ へ行って、rootアカウントでログインをするリンクをクリックして、パスワードリマインダを送る。
https://console.aws.amazon.com/iam/home?#/home に行って、IAMのログイン用URLを作成する。
(任意) AdministratorAccessのIAMアカウントを作る。
AWS Organizationの上位OUにログインして、SwitchRoleでログインできるかを確認。

CloudFrontにてCORSを利用する際の設定方法

Wed, 14 Dec 2022 00:00:00 GMT

久しぶりにハマったので備忘録を残しておきます

問題

CloudFrondを使っている環境において、CORS (Cross-Origin Resource Sharing) に該当するリクエストが成功したり失敗したりしました。

前提の共有

サーバサイドにおけるCORSの挙動は2種類あります。

どんなリクエストに対してもCORSの設定を含んだHTTPレスポンスを返却する
HTTPリクエストにOriginヘッダがあった場合に、CORSの設定を含んだHTTPレスポンスを返す。

nginxとかrailsのアプリケーションで適当に設定してしまう場合は面倒なので1番めになります。AWS S3で設定する場合は2番の設定になります。

そのため、2番の設定を検証するためにはリクエストにOriginヘッダを含めて検証する必要があります。

% curl -i 'https://postcode.teraren.com/postcodes.json' -H 'Origin: http://example.com' 2>&1|grep -i access
access-control-allow-origin: *
access-control-allow-methods: GET, HEAD

また、1の場合はCDNにおいて一律クライアントに返却する場合と、CDNのorigin側でレスポンスを返すという2パターンのデプロイ方法が存在します。

このあたりのポリシーを決めた上で、設定していく必要があります。この設計によってトラブルシューティングする場所が大幅に変わってきます。

問題が起きるケース

2時間ぐらいトラブルシュートして、やっと問題がわかりました。CloudFrontをほぼデフォルトで設定した場合に起きる、以下のようなケースのときです。

HTTPクライアントがOriginヘッダを付けないでCloudFrontにリクエスト
CloudFrontにhttpレスポンスヘッダも含めてキャッシュされる。（CORSのレスポンスが入らないキャッシュができる）
HTTPクライアントがOriginヘッダを付けてCloudFrontにリクエスト
CDNがキャッシュ済みのオブジェクトを返却。（これにはCORSが入っていない）

対処方法

CloudFrontのBehaviorsの設定において、CDN上のキャッシュのキーにHTTPリクエストの"Origin"ヘッダを含めるようにする。

Elemental-MediaPackage

Managedポリシーの中で唯一Originヘッダをキーとして使うルールです。他にも細かい設定が入っているのですが、面倒なのでこれを使います。

CORS-S3Origin

HTTPクライアントから送られてきたリクエストをOriginに送るヘッダです。

origin
access-control-request-headers
access-control-request-method

PoC

// This would succeed if CORS setting is correct.
fetch("https://postcode.teraren.com/favicon.ico")
  .then((res) => res.blob())
  .then((blob) => {
    let image = new Image();
    image.src = URL.createObjectURL(blob);
    image.width = 200;
    image.height = 200;
    document.getElementById("cf").appendChild(image);
  })
  .catch((error) => {
    console.error("通信に失敗しました", error);
  });

https://codepen.io/matsubokkuri/pen/wvXLbzo

参考資料

https://zenn.dev/bun913/articles/cloudfront-cors-policies

余談1

BraveやChromeのDeveloper Consoleでトラブルシュートをしているときに、Networkタブにて確認しているとがOriginヘッダ無しのリクエストを出したり、Originヘッダ付きのリクエストを出したりしていました。

{/* textlint-disable ja-technical-writing/ja-no-successive-word /} よくよく確認してみると、Javascriptからの呼び出しは1回なのに、リクエストが2回飛んでいました。 {/ textlint-enable ja-technical-writing/ja-no-successive-word */}1つは、意図した通りのリクエスト、もう1つは単にブラウザがGETしているだけのリクエスト。後者を呼び出すようなコードを書いていないので意味不明だった。

トラブルシューティングをする際に、上記の2種類のリクエストのどちらをチェックするかによって変わってくるのでそこをしっかり確認しておく必要があります。

→原因判明。上記のPoCのコードを

image.src = "http://postcode.teraren.com/favicon.ico";

と書くと、CORSを考慮しない普通のGETリクエストが走ることになり、fetchとは別のリクエストが飛びます。しかしながら、ブラウザのキャッシュのメカニズムが、URLをキーとしたキャッシュになるのでCORS無しのリクエスト、レスポンスがキャッシュから呼ばれてしまうときがあります。

よって、1ページ内で外部リソースを読むときに、CORS付きでリクエストをするコードと、CORS無しでリクエストをするコードが存在する場合、予期しない挙動になります。

自分でスクラッチから書いていれば問題ないと思いますが、ライブラリレベルで外部リソースの呼び出し方が異なる場合はかなり面倒なことになります。どちらかのライブラリを使わないようにする解決方法しか無いのかなと思います。

余談2

かつて、メルカリがCDNの設定をミスって情報漏洩をしたこともあります。

https://engineering.mercari.com/blog/entry/2017-06-22-204500/

CDNの設定は、アプリケーションごとにいろいろなユースケースを考えてテストをしないといけないので、なかなか難しいです。

Rail7の推奨になったimportmap+ dartsassを使ってサービスを構築してみました

Wed, 14 Dec 2022 00:00:00 GMT

概要

Ruby on Rails Advent Calendar 2022の17日目の記事です。
Ruby on Rails 7.0からアセット管理にimport mapsが使われるようになりました。Rails6のときに使われていたwebpackerとは大きく仕組みが異なります。
import mapsの学習のためにrails newから始めて、1つサービスを構築して公開してみました。
個人的には日本や世界のDXをに役立ったり、生活を便利にするサービスを作ることを片手間におこなっています。今回もその一環です。

今回作ったサイト

「元号くん」という名称で、西暦から和暦を表示したり、和暦から西暦を表示できます。また、各年ごとの祝日の情報を表示しています。

ただ表示するだけではRailsを使う意味があまりないのでREST APIでも同様の変換を提供できるようにしました。

サイトのURLは以下になります。

https://seireki.teraren.com/

トップページのスクリーンショットは以下です。

importmapとは

すでに解説記事が多数あるのでそちらを参照するのが良いです。こちらの記事がとても理解しやすかったです。

JSのmoduleをimportするときに、今まではブラウザ上では相対パスでしか指定できなかったけど、importするmoduleとしてnode_moduleやURLなど色々指定できるようにする機能というかんじです。なるほど。

https://blog.mizukami.sh/entry/2022/05/23/importmap

importmapの対応ブラウザ

2022年12月14日時点でグローバルで72.9%です。古めのsafariだと対応してい無さそうです。

https://caniuse.com/import-maps

サービス構築

要件定義

importmapを使う。
REST APIからも利用できるようにする。
すでに動いている自宅サーバで公開できるようにすることでサーバ費用はほぼ0円で運用する。

外部設計

大したサービスではないのでページ階層を書いておきます。

トップページ
- 西暦→和暦一覧
  - 各西暦のページ
- 和暦→西暦一覧
  - 和暦のページ
- 年ごとの休日一覧
  - 年ごとのページ

内部設計

西暦と和暦を変換するgemであるwarekiを使えばかんたんに実装できそうです。
休日のマスタはholiday_jpを使えばかんたんに実装できそうです。
RDBなどのストレージは使わないで運用できそうなのでストレージの設計は無いです。

実装

まずはじめに開発サーバを作ります。dockerによるコンテナ上で開発をするので開発環境を準備します。

以下のファイルを準備します。

上記ファイルを準備した上で以下のコマンドを実行して、railsの実行にgemをインストールします。

% docker compose run --rm app bundle install

次に、railsの新規プロジェクトを作成します。なんら特殊なオプションを指定しないでrailsの推奨するテンプレで作っていきます。

% docker compose run --rm app bundle exec rails new . -C sqlite3

生成されたGemfileを覗いてみます。アセットに関連するgemは以下のものが指定されていました。

gem "sprockets-rails"
gem "importmap-rails"
gem "turbo-rails"
gem "stimulus-rails"

ここで、config/importmap.rb の初期設定を見てみます。ここに、ロードする可能性のあるJSの場所を一元管理しておくこととなります。

pin "application", preload: true
pin "@hotwired/turbo-rails", to: "turbo.min.js", preload: true
pin "@hotwired/stimulus", to: "stimulus.min.js", preload: true
pin "@hotwired/stimulus-loading", to: "stimulus-loading.js", preload: true
pin_all_from "app/javascript/controllers", under: "controllers"

1行目で書かれているapplication.jsにはstimulusの初期化が書かれています。

// cat ./app/javascript/controllers/application.js
import { Application } from "@hotwired/stimulus"

const application = Application.start()

// Configure Stimulus development experience
application.debug = false
window.Stimulus   = application

export { application }

2〜4行目にあるhotwiredの部分では、turbo, stimulusのモジュール定義が入っています。

最後の行は、pin_all_fromと書かれており、controllers以下のファイルを自動的に展開してキーとして指定できるような定義が書かれています。

controllers以下のJSの中身は以下のようになっています。stimulusで書かれたJSのテンプレが入っています。stimulusを使わなければごそっと消しても良いかと思います。

// ==> ./app/javascript/controllers/application.js <==
import { Application } from "@hotwired/stimulus"

const application = Application.start()

// Configure Stimulus development experience
application.debug = false
window.Stimulus   = application

export { application }

// ==> ./app/javascript/controllers/hello_controller.js <==
import { Controller } from "@hotwired/stimulus"

export default class extends Controller {
  connect() {
    this.element.textContent = "Hello World!"
  }
}

// ==> ./app/javascript/controllers/index.js <==
// Import and register all your controllers from the importmap under controllers/*

import { application } from "controllers/application"

// Eager load all controllers defined in the import map under controllers/**/*_controller
import { eagerLoadControllersFrom } from "@hotwired/stimulus-loading"
eagerLoadControllersFrom("controllers", application)

// Lazy load controllers as they appear in the DOM (remember not to preload controllers in import map!)
// import { lazyLoadControllersFrom } from "@hotwired/stimulus-loading"
// lazyLoadControllersFrom("controllers", application)

BootstrapのJSとCSSの追加

デザインはTwitter bootstrapを使うので追加していきます。

まずは、今回のメインであるimportmapを使ったJSのロード部分です。まずは、キーを追加します。今回デフォルトで指定されているファイルをそのまま使います。minifyされたファイルのURLが指定されています。

また、bootstrapが依存しているpopperjsも自動的に追加されました。

% docker compose run -- app bin/importmap pin bootstrap
Pinning "bootstrap" to https://ga.jspm.io/npm:bootstrap@5.2.3/dist/js/bootstrap.esm.js
Pinning "@popperjs/core" to https://ga.jspm.io/npm:@popperjs/core@2.11.6/lib/index.js

実行後のconfig/importmap.rbがこちら。

pin "application", preload: true
pin "@hotwired/turbo-rails", to: "turbo.min.js", preload: true
pin "@hotwired/stimulus", to: "stimulus.min.js", preload: true
pin "@hotwired/stimulus-loading", to: "stimulus-loading.js", preload: true
pin_all_from "app/javascript/controllers", under: "controllers"
pin "bootstrap", to: "https://ga.jspm.io/npm:bootstrap@5.2.3/dist/js/bootstrap.esm.js"
pin "@popperjs/core", to: "https://ga.jspm.io/npm:@popperjs/core@2.11.6/lib/index.js"

次に、上記の定義をもとに app/javascript/application.js で読み込みます。最後の2行を追加します。

// Configure your import map in config/importmap.rb. Read more: https://github.com/rails/importmap-rails
import "@hotwired/turbo-rails"
import "controllers"

import * as Popper from "@popperjs/core"
import * as Bootstrap from "bootstrap"

次に、stylesheetです。railsの推奨はdartsassなので、dartsass-railsをインストールします。

% docker compose run --rm app bundle add dartsass-rails
Fetching gem metadata from https://rubygems.org/..........
Resolving dependencies...
Fetching gem metadata from https://rubygems.org/..........
Resolving dependencies...

<snip> Fetching dartsass-rails 0.4.0 <snip> Installing dartsass-rails 0.4.0

そしてインストールを実行

% docker compose run --rm app bundle exec rails dartsass:install
Build into app/assets/builds
      create  app/assets/builds
      create  app/assets/builds/.keep
      append  app/assets/config/manifest.js
Stop linking stylesheets automatically
        gsub  app/assets/config/manifest.js
      append  .gitignore
Add default app/assets/stylesheets/application.scss
      create  app/assets/stylesheets/application.scss
Add default Procfile.dev
      create  Procfile.dev
Ensure foreman is installed
         run  gem install foreman from "."
Fetching foreman-0.87.2.gem
Successfully installed foreman-0.87.2
1 gem installed
Add bin/dev to start foreman
      create  bin/dev
Compile initial Dart Sass build
         run  rails dartsass:build from "."

+ /usr/local/bundle/gems/dartsass-rails-0.4.0/exe/aarch64-linux/sass --style=compressed --no-source-map --load-path /app/app/assets/stylesheets --load-path /app/app/assets/builds --load-path /app/app/assets/config --load-path /app/app/assets/images --load-path /app/app/assets/stylesheets --load-path /usr/local/bundle/gems/stimulus-rails-1.2.1/app/assets/javascripts --load-path /usr/local/bundle/gems/turbo-rails-1.3.2/app/assets/javascripts --load-path /usr/local/bundle/gems/importmap-rails-1.1.5/app/assets/javascripts --load-path /usr/local/bundle/gems/actiontext-7.0.4/app/assets/javascripts --load-path /usr/local/bundle/gems/actiontext-7.0.4/app/assets/stylesheets --load-path /usr/local/bundle/gems/activestorage-7.0.4/app/assets/javascripts --load-path /usr/local/bundle/gems/actionview-7.0.4/lib/assets/compiled --load-path /app/app/javascript --load-path /app/vendor/javascript /app/app/assets/stylesheets/application.scss:/app/app/assets/builds/application.css

次に、CSSのファイルを管理するためにnpm経由でcssを取得します。今までなら、npmによってJSとCSSを同時に取得していましたが、管理が別々になっちゃいます。

dartsass自体はnodeJS無しで実行できますが、sassファイルの管理自体はnpm経由が私は楽だと思うので結局はnodeJSを使ってしまっています。

npm-check-updatesによってパッケージの更新がわかるので楽です。

package.json

{
  "dependencies": {
    "bootstrap": "^5.2.3",
    "bootstrap-icons": "^1.10.2",
    "bootswatch": "^5.2.2"
  },
  "devDependencies": {
    "npm-check-updates": "^16.4.3"
  },
  "license": "UNLICENSED"
}

app/assets/stylesheets/application.scssにファイルを読み込むように書きます。

@import "../../../node_modules/bootswatch/dist/flatly/variables";
@import "../../../node_modules/bootstrap/scss/bootstrap.scss";
@import "../../../node_modules/bootswatch/dist/flatly/bootswatch";
@import "../../../node_modules/bootstrap-icons/font/bootstrap-icons";

これでJSの読み込みができつつ、デザインが反映されるようになります。

その後は、dartsassによるファイル変更監視などを設定して、いつもどおりrailsアプリ開発と同じです。

テスト

個人サービスだし、変更はほとんど行わないので省略。

考察

lighthouseで高スコア

95点です。ユーザ体験も大きく向上できます。

popperのファイル読み込みが多数出るようになった

importmapの前提としては、HTTP2の利用があるので大した問題ではないかもしれませんが、細かく分割されたファイルが読み込まれるようになりました。全部popper関連です。流石に分割され過ぎのような気もしますが、キャッシュ効率を考えるとこれが良いのでしょう。

Google Spreadsheetで和暦表示が可能になります

また、自分でロジックを書くと新たな和暦が登場したときにメンテナンスが必要になるという問題も発生します。

Google SpreadsheetではGoogle App Scriptを使うとREST APIの呼び出しと、JSONのパースができるようになります。

出力例とサンプルファイルのURL↓

https://docs.google.com/spreadsheets/d/1DiEUrZNH3Y7jJNrryQmRn04eMQO4zpoSHzKJg05Km38/edit?usp=sharing

Google App ScriptでREST APIを呼び出します。

function getWarekiFromSeireki(year) {

  const url = 'https://seireki.teraren.com/seireki/' + year  + '.json';

  try {
    ContactsApp response = UrlFetchApp.fetch(url, {'muteHttpExceptions': true});
    response_object = JSON.parse(response);
    return response_object['wareki'];
  }catch(e){
    Logger.log(e);
  }
}

日付から、西暦を出力してあげたほうが親切かなと思いました。

その他

Webサービスの公開に際して以下のことも行っています

XML Sitemapの出力とGoogle search consoleへの登録
gretelを利用してパンくずリストの表示と、ld+jsonを利用したマークアップ。
robots.txtの設置
google-tag-manager-railsを入れてGTMを設定

まとめ

rails7 + importmap-rails + dartsass-railsを使って最新の推奨組み合わせを使ってサイトを構築してみました。
かかった時間は8時間ぐらいです。この記事を書くのに2時間ぐらいです。

node 18 upgrade error

Tue, 06 Dec 2022 00:00:00 GMT

Node.js v16からNode.js v18にアップグレードしたらエラーが出ました。

node:internal/crypto/hash:71
  this[kHandle] = new _Hash(algorithm, xofLen);
                  ^

Error: error:0308010C:digital envelope routines::unsupported
    at new Hash (node:internal/crypto/hash:71:19)
    at Object.createHash (node:crypto:133:10)
    at module.exports (/app/node_modules/webpack/lib/util/createHash.js:135:53)
    at NormalModule._initBuildHash (/app/node_modules/webpack/lib/NormalModule.js:417:16)
    at /app/node_modules/webpack/lib/NormalModule.js:452:10
    at /app/node_modules/webpack/lib/NormalModule.js:323:13
    at /app/node_modules/loader-runner/lib/LoaderRunner.js:367:11
    at /app/node_modules/loader-runner/lib/LoaderRunner.js:233:18
    at context.callback (/app/node_modules/loader-runner/lib/LoaderRunner.js:111:13)
    at /app/node_modules/babel-loader/lib/index.js:59:103 {
  opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
  library: 'digital envelope routines',
  reason: 'unsupported',
  code: 'ERR_OSSL_EVP_UNSUPPORTED'
}

Node.js v18.12.1

Node.js v17に入った問題ようです。以下の環境変数をセットすれば回避できます。

NODE_OPTIONS=--openssl-legacy-provider

docker-composeでnodeやwebpackを使っている場合は以下の設定をdocker-compose.ymlへ追加すれば回避できます。

    environment:
      NODE_OPTIONS: --openssl-legacy-provider

原因

webpackがbabelを使っていて、babelが参照しているライブラリ内でOpenSSL 3.0の今はサポートされていないアルゴリズムかキーサイズのオプションを利用しようとした場合に出るようです。

考察

はやく、webpackerとbabelから脱却しないとですな。。。

Webpacker has been retired

https://github.com/rails/webpacker

githubのissueやpull requestをCSVで出力するスクリプトを書きました

Thu, 01 Dec 2022 00:00:00 GMT

概要

特定の検索条件で、githubのissueやpull requestをCSVに出力する必要があったのでスクリプトを書きました。

APIでの呼び出しはpagingがあるのでちょっとスクリプトを書かないと一覧を取得できないので面倒です。

https://github.com/matsubo/github-issue-export-script

oktakitを使えばページ送りを自動でやってくれるので楽です。しかしながら、oktakitのAPIドキュメントが充実していないのでgithubのREST APIと、oktakitのソースコードを照らし合わせながら調べる必要があって時間がかかりました。

Webで検索しても単純にissueの一覧を出す程度にとどまっていますが、今回やりたかったのはフィルタ条件をいくつかのフィールドに対して設定してCSVで出力したかったのでそのようなコードが見つかりませんでした。

使い方はREADMEに記載しました。

Google SpreadsheetのGOOGLEFINANCE関数で為替レート・株価を取得する方法

Mon, 28 Nov 2022 00:00:00 GMT

やりたいこと

確定申告や投資記録で「特定の日の為替レート」や「特定の日の株価」をスプレッドシートに記録したいことがある。Google SpreadsheetにはGOOGLEFINANCE関数が用意されていて、外部データソースなしで為替・株価を取得できる。

GOOGLEFINANCE関数の基本

GOOGLEFINANCE関数の書式は以下の通り。

=GOOGLEFINANCE(銘柄コード, 属性, 開始日, [終了日], [間隔])

為替レートの場合、銘柄コードは "CURRENCY:USDJPY" のように CURRENCY: プレフィックスを付ける。株価の場合はティッカーシンボルをそのまま指定する（例: "AAPL", "ZM"）。

為替レートを取得する

テーブル形式で取得

日付を指定すると、ヘッダー行を含む2行のテーブルが自動で生成される。

=GOOGLEFINANCE("CURRENCY:USDJPY","price","2022/1/1")

この方法だとセルが2行×2列に展開されてしまうため、他のデータと混在するシートでは使いにくい。

1つのセルで値だけ取得

INDEX関数で2行目2列目を指定すれば、レート値だけを1セルに収められる。

=INDEX(GOOGLEFINANCE("CURRENCY:USDJPY","price","2022/1/1"),2,2)

INDEX(...,2,2) はGOOGLEFINANCE関数が返すテーブルの2行目（データ行）・2列目（価格列）を取り出している。1行目はヘッダー（"Date", "Close"）なのでスキップする。

日付をセル参照にする

日付部分をセル参照にすれば、日付リストから一括で為替レートを取得できる。

=INDEX(GOOGLEFINANCE("CURRENCY:USDJPY","price",A2),2,2)

A2セルに 2022/1/1 のような日付を入れておけば、行をコピーするだけで複数日分のレートが取得できる。

株価を取得する

為替レートと同じ要領で、ティッカーシンボルを指定すれば株価も取得できる。

=INDEX(GOOGLEFINANCE("ZM","price","2022/1/1"),2,2)

日本株の場合は "TYO:7203"（トヨタ）のように東証のプレフィックスを付ける。

=INDEX(GOOGLEFINANCE("TYO:7203","price","2022/1/1"),2,2)

注意点

GOOGLEFINANCE関数はリアルタイムではなく、最大20分程度の遅延がある
過去のデータは取得できるが、あまりに古い日付だとデータがない場合がある
土日祝日を指定すると直近の営業日のデータが返される
1スプレッドシートあたりのGOOGLEFINANCE関数の呼び出し回数には上限があるため、大量に使うと#N/Aエラーになることがある

Google WorkspaceからOffice 365へのユーザ同期が年1回ぐらい止まる問題の対処方法

Tue, 08 Nov 2022 00:00:00 GMT

背景

コーポレートSEのお話。（おそらく日本に数人しか必要としないようなユースケースのネタかと思いますが）

弊社（マインディア）ではGoogle Workspaceのユーザ情報をマスタとしています。所属する部署に応じてMicrosoft Office (Office 365)のライセンスを自動付与するような運用をしています。

3年前ぐらいに以下の記事にあるような超絶面倒な設定をして、Google Workspace側のユーザマスタをMicrosoft Azure AD側に同期する設定をしました。

https://zenn.dev/cestquigucci/articles/59175c03342c66

3年前はこれよりもっと面倒なことをしなければならなかったです。設定手順が煩雑すぎてブログの記事にしようと思ってましたが忙しくて頓挫しました。

トラブルシュート

事例1

定期的に同期が止まるみたいです。

2021年5月ごろに取得したスクショです。Azure ADにユーザが同期されなくなったのでGoogle Workspace側に登録してある"Microsoft Office 365"のアプリ設定画面を開いたらエラー出ていました。

ログをダウンロードしたら以下のようなメッセージが書いてありました。

{/* textlint-disable ja-technical-writing/no-unmatched-pair /} “Syncing active” と書いてあるのに、失敗するのは謎です。とりあえずエラーの内容がtoken周りなので認証がおかしくなっているのかなと思って”REAUTHORIZE”を押したら直りました。 {/ textlint-enable */}

事例2

1.5年後、またユーザの同期が止まりました。

今度はAutoprovisioningがinactiveになってました。これをactiveにして、10分ほど待ったら同期されました。

このあたり、変化が激しいので管理画面も変わっちゃっていたりします。

事例3

2022年2月。また止まりました。事例1と同じエラーです。謎です。

Error code Error Details 17013 Generating access token for the SP failed

アプリの方の一覧には、別のwarningも出ていたので要注意です。

Certificate expires on Mar 16, 2023 Autoprovisioning ON

対処としては、事例1と同じように再接続しました。3分後ぐらいにMicrosoft 365に同期されました。
（一応、ユーザ情報の更新をしてトリガーも踏んでおきました）

カジノのルーレットシミュレータを書いてみました

Sun, 06 Nov 2022 00:00:00 GMT

概要

ダズンベット法を使うと勝ちやすいとか書いてあるので実際にプログラムを書いて検証してみました。

「勝率が高いベッティング方法とマーチンゲール法による資金管理を組み合わせれば最強じゃね？」と思ってプログラムを書いて検証してみました。

世の中にあるカジノのシミュレータは、ベッティング方法単体、資金管理方法単体でのシミュレーターはあるのですが両方を一気に実行できるプログラムがなかったので書きました。

https://github.com/matsubo/roulett-strategy-simulator

単純な計算で出せないので、ちゃんとオブジェクト指向でアクターとエンティティを整理して書かないときれいに書けないなと感じたので、ちゃんと設計して書くのが面倒でした。

クラス図を書く必要があるギリギリの難易度くらいでした。

アプローチ

勝率の高いベッティング方法は過去の履歴を参考にして出やすい目を予測することです。

確率で考えると赤か黒が10回連続で出る確率は、

(18^10)/(37^10)=0.00074252=0.074252%

となるので10回目に同じ色が出る確率は非常に少ないことになります。これを元に10回目は別の色に賭けるということによって勝率をあげようと言うことです。逆張りアプローチです。

考察

しかしながら、全然思ったとおりに勝てないことがわかりました。

シミュレーションの結果

シミュレーションの結局、期待した結果にはなりませんでした。

9回連続同じ色が出た後に、10回目に同じもの色が出る確率は約1/2です。

以下のサイトにある通りでした。

このサイトでは再三言っていますが、カジノにおけるルーレットは過去の事象の歴史と次回の事象には関連性がない独立した事象であるという事です。

https://www.a-taichi.com/casinogamenavi/roulette/roulette9884.html

例

基本ルール

開始は200クレジット
戦略を実行するためのベットができなくなった時点で中止

毎回1クレジットをランダムに黒か赤に賭ける

360プレイ x 100日分実行した結果

この360プレイというのは、1回のルーレットの実施に2分かかると仮定して、12時間プレイすると仮定した値です。ようするに丸1日中ルーレットをした場合のプレイ数です。

ずっと黒に賭ける

そもそも赤も黒も期待値は同じなので、ずっと黒にかけてみても同じになるはずなので検証。

 % bundle exec ruby main.rb |grep Won | awk '{ print $2}' | awk  'BEGIN {total=0} {total += $1} END {print total/NR}'

48.5666

48.5666%となるので、ほぼ理論値通り。

確率は、18/37=0.48648649

36万回実行してます。

5回連続同じ色が出たら逆張り戦略

本気で勝ちにいきたいので、ベットする金額はマーチンゲール法を用いてみます。

マーチンゲール法では、負けた分を取り返すような掛け方になるので1, 2, 4, 8, 16というふうに指数的に増えます。

ほとんどのサンプルは資産が微増するようになってます。しかしながら気になるのは、下にスパイクしたときのサンプルです。

その際に、最後の統計値を見るのが重要です。

Test suite result ----------------------
Bankrupt: 6
Bankrupt rate: 6.0%

6％が資産不十分になってしまってマーチンゲール法を続けられなくなってます。

実世界に置き換えると、まる1日カジノに居て、16日に1回は破産します。15回は10％程度の微増です。

逆張りをしたときの勝率

36万回実行してみた結果、47.926%でした。

Won(%): 47.926 %

1回あたりにおける当たる確率は、18/37-19/37 = 0.48648649なので、逆張りをしても意味が無いです。

ちなみに、ゲームへの参加率は6.452778%でした。実際のゲームで実行するとなると空き時間が多いですね。

5回連続同じ目が出たときに、当たるまで1単位を逆張りし続けたときの資金残高はこちら。残高が0になっても止まらないように変更して実行しました。

まとめ

簡単なコードの変更でルーレットの戦略、実行回数、を変更して実行結果をシミュレーションするプログラムを作りました。

グラフでの出力により視覚的にわかりやすくして、シミュレーションに必要な各種指標を出力するようにしました。

昔、FXの自動取引プログラムを開発していたときの知識が役に立ちました。

https://diary.teraren.com/posts/2008-01-20-metatrader-agent/

LIXILナビッシュをDIY取り付け（意外と簡単）

Fri, 21 Oct 2022 00:00:00 GMT

概要

家で料理をすることが多くなってきたし、簡単な手洗いもするので出したり止めたりを繰り返すことが多いです。あと、なんだかんだいって東京都心の水道水はそのまま飲むと臭いので浄水器を付けたいという思いがありました。

そこで、10万円はしますが、LIXILのナビッシュという商品がまさに要求にぴったりということで買って取り付けをしました。

このナビッシュは細かいバリエーションが多数あります。

今回取り付けたのは一番高いものです。「浄水器付き」「電源あり」です。電源はコンセントが必要になります。近くにあればよいですが、ない場合は分岐して持ってくる必要があります。

交換前の状態

混合水栓がついています。

キッチンの下。お湯の官は食洗機へ伸びています。それにしてもアングルが厳しい感じに設置されている。。。

ナビッシュを取り付け

まずは古い混合水栓を取り外す必要があります。24mmのロングソケットが必要だったので別途買いました。

::amazon{asin="B003YUGAHU"}

ボルトを1つ外すと取れます。

このボルトを外さないといけない。

説明書どおりに接続して、こんな感じにラフに設置してみました。100V ACは食洗機の電源から分岐してきました。

後日、コンセントをちゃんと設置してケーブルの取り回しを整理しました。

電磁弁のコントローラ

新設したコンセント。見えないから適当に。

夜は光っていてかっこいいです。

まとめ

取り付けは簡単に行えました。

初心者でも可能かと思います。電気の取り回しができない場合は乾電池式を買うのが良いと思います。停電でも使えるのも利点と考えられます。

毎年1万円ぐらいの浄水器カートリッジを交換する必要があります。高額ではありますが、交換直後は水の匂いが全くなくなって美味しく感じるので1年で交換は必要です。

食器を手洗いするときに、いちいち水を止めるのが面倒だから出しっぱなしにすることが多かったのですが、自動吐出があると必要なときに水を出せるから節約できます。また、両手が塞がっているときや手が汚れているときに水を出せるのは非常に快適です。

カートリッジの型番はJF-45Nです。偽物のカートリッジが多いのでご注意ください。Amazonで本物を見分けるのは困難なので、オフィシャルサイトから買うようにしました。。。高いけど体に入るものなので。

::amazon{asin="B00E59R5LO" kw="JF-43N"}

Rails7 + importmap + dartsass-rails

Sun, 16 Oct 2022 00:00:00 GMT

概要

Rails7のデフォルトでのアセットの管理がどの様になっているか知りたかったので rails newをしてみました。

既存プロジェクトを移行したときの差分はこちらです。

https://blog.teraren.com/posts/removing-webpacker/

既存のソースコードの流用などがあるので変更を最小限にしたかったという思いもあってcssbundle-rails + jsbundling-rails + propshaftの構成にしましたが、やはり最新のrails newをしたときの推奨構成を知っておきたくなったため今回はrails newをしました。

サンプルのソースコード

特徴

docker-composeで動くようになっています。
行った操作ごとにコミットを分けています。
boostrapベースの良い感じのデザインテンプレであるbootswatchを導入してあります。
rails new . -C -d sqlite3 で初期化してあります。

https://github.com/matsubo/rails7_importmap_bootswatch

作ったサービス

西暦と和暦を一覧で表示するサービスを作ってみました。

アセットの内容などを確認できます。

https://seireki.teraren.com/

ExcelやGoogle Spreadsheetで郵便番号から住所を補完

Sun, 09 Oct 2022 00:00:00 GMT

概要

Google SpreadsheetやExcelにて、郵便番号から住所を自動入力するAPIを作成しました。地域の郵便番号だけではなく、事業所に割り振られている郵便番号も対応しています。

以下のスクリーンショットのように、一番のA列に郵便番号を入力すると任意のフォーマットで住所を入力できます。

使い方

Google Spreadsheetで以下のような関数を入力するだけです。1600022は取得したい郵便番号を指定します。

WindowsのExcel 2003以降のバージョンでは、WEBSERVICE関数でGoogle Spreadsheetと同じように使えます。

= IMPORTDATA("https://postcode.teraren.com/postcodes/1600022.txt")

郵便番号を別のセルから参照するためには以下のように郵便番号の部分に変数を使います。

= IMPORTDATA("https://postcode.teraren.com/postcodes/"&A2&".txt")

住所の全体ではなく、一部だけを取得したい場合はpartパラメータを付与します。

= IMPORTDATA("https://postcode.teraren.com/postcodes/1600022.txt?part=1")

partパラメータの説明は以下です。

1: 都道府県
2: 市町村区
3: 町域
4: 番地
5: 名称

サンプルのファイル

API仕様

郵便番号をパラメータとしたURLを呼び出すと、住所の文字情報が返却されるAPIです。

$ curl https://postcode.teraren.com/postcodes/1600022.txt
東京都新宿区新宿

以下のページにAPIの詳細を掲載してあります。

https://postcode.teraren.com/doc/redoc#tag/Postcode/operation/getPostcodeText

webpackerを削除してcssbundling-rails+jsbundling-rails+propshaftに移行

Sun, 09 Oct 2022 00:00:00 GMT

概要

importmap-railsに移行したかったのですが、手元のブラウザではちゃんと動かなかったので諦めてJavascriptはtranspileすることにしました。

webpackerから移行した際の手順をまとめておきます。

https://postcode.teraren.com/ こちらのサービスで実施した内容になります。

移行手順

できるだけわかりやすいように、差分を多く掲載します。

Gemfileを書き換えます。

diff --git a/Gemfile b/Gemfile
index 312e40b..4c2a986 100644
--- a/Gemfile
+++ b/Gemfile
@@ -1,13 +1,31 @@
 source 'https://rubygems.org'

 gem "rails", '~>7.0'
-gem 'webpacker'

 gem 'jbuilder'

 gem 'puma'

+# gem "sprockets-rails"
+
+#gem "importmap-rails"
+gem 'cssbundling-rails'
+gem 'propshaft'
+
+gem "jsbundling-rails"
+
+#gem "turbo-rails"
+
+#gem "stimulus-rails"
+
+

package.jsonを一新します。

ついでにjQueryに依存したコードも削除下のでjqueryも消しています。
bootstrapのバージョンも最新にしています。
webpack関連のnpmは削除しています。

diff --git a/package.json b/package.json
index 5ec1857..18b62d6 100644
--- a/package.json
+++ b/package.json
@@ -1,18 +1,19 @@
 {
-  "packageManager": "yarn@1.22.15",
-  "private": true,
+  "name": "app",
+  "private": "true",
   "dependencies": {
-    "@fortawesome/fontawesome-free": "^5",
-    "@popperjs/core": "^2",
-    "@rails/activestorage": "^7.0",
-    "@rails/ujs": "^7.0",
-    "@rails/webpacker": "5.4",
-    "bootstrap": "^5.1",
-    "bootswatch": "^5.1",
-    "jquery": "^3.6",
-    "webpack-cli": "^4"
+    "@fortawesome/fontawesome-free": "^6.2.0",
+    "@popperjs/core": "^2.11.6",
+    "@rails/ujs": "^7.0.4",
+    "bootstrap": "^5.2.2",
+    "bootswatch": "^5.2.1"
+  },
+  "scripts": {
+    "build": "esbuild app/javascript/*.* --bundle --sourcemap --outdir=app/assets/builds --public-path=assets",
+    "build:css": "sass ./app/assets/stylesheets/application.sass.scss:./app/assets/builds/application.css --no-source-map --load-path=node_modules"
   },
   "devDependencies": {
-    "webpack-dev-server": "^4"
+    "esbuild": "^0.15.10",
+    "sass": "^1.55.0"
   }
 }

設定ファイルを自動作成します。

./bin/rails css:install:sass
./bin/rails javascript:install:esbuild

JS周りの設定ファイルを書き換えます。

diff --git a/app/assets/builds/.keep b/app/assets/builds/.keep
new file mode 100644
index 0000000..e69de29
diff --git a/app/assets/config/manifest.js b/app/assets/config/manifest.js
index 20b4c66..cf7a2a5 100644
--- a/app/assets/config/manifest.js
+++ b/app/assets/config/manifest.js
@@ -1,3 +1,11 @@
-//= link graphiql/rails/application.css
-//= link graphiql/rails/application.js
+// app/assets/config/manifest.js
+
+//= link_tree ../images
+
+//= link application.js
+//= link controllers/application.js
+//= link controllers/home.js
+//= link controllers/index.js
+
+//= link application.css
+//= link_tree ../builds

CSS周りの設定ファイルを書き換えます。gitにファイルの置き場所が変わっているので新規作成として認識されてます。

diff --git a/app/assets/stylesheets/application.sass.scss b/app/assets/stylesheets/application.sass.scss
new file mode 100644
index 0000000..7f0faab
--- /dev/null
+++ b/app/assets/stylesheets/application.sass.scss
@@ -0,0 +1,8 @@
+// bootswatch
+@import "bootswatch/dist/simplex/variables";
+@import "bootstrap/scss/bootstrap";
+@import "bootswatch/dist/simplex/bootswatch";
+
+// fontawesome
+@import '@fortawesome/fontawesome-free/scss/fontawesome';
+

JS、CSS、画像の置き場所を全体的に変更します。

JS: app/javascript/pack => app/javascript

CSS: app/javascript/stylesheets => app/assets/stylesheets

画像: app/javasript/images => app/assets/images

アセットの呼び出し方法を変更します。

diff --git a/app/views/layouts/application.html.erb b/app/views/layouts/application.html.erb
index 9290dda..75a118d 100644
--- a/app/views/layouts/application.html.erb
+++ b/app/views/layouts/application.html.erb
@@ -20,7 +20,7 @@ description.strip!
   <meta property="og:type" content="website" />
   <meta property="og:title" content="<%= title %>" />
   <meta property="og:url" content="<%= request.url %>" />
-  <meta property="og:image" content="<%= asset_pack_path 'media/images/apple-touch-icon-144x144-precomposed.png' %>" />
+  <meta property="og:image" content="<%= asset_path 'apple-touch-icon-144x144-precomposed.png' %>" />

   <meta name="theme-color" content="#d97368">

@@ -43,32 +43,31 @@ description.strip!
   <%= csp_meta_tag %>

-  <%= stylesheet_pack_tag "application" %>
-  <%= javascript_pack_tag "application", defer: true %>
-
-
   <!-- For third-generation iPad with high-resolution Retina display: -->
   <!-- Size should be 144 x 144 pixels -->
-  <%= favicon_link_tag (asset_pack_path('media/images/apple-touch-icon-144x144-precomposed.png')), :rel => 'apple-touch-icon-precomposed', :type => 'image/png', :sizes => '144x144', skip_pipeline: true  %>
+  <%= favicon_link_tag (asset_path('apple-touch-icon-144x144-precomposed.png')), :rel => 'apple-touch-icon-precomposed', :type => 'image/png', :sizes => '144x144', skip_pipeline: true  %>

   <!-- For iPhone with high-resolution Retina display: -->
   <!-- Size should be 114 x 114 pixels -->
-  <%= favicon_link_tag (asset_pack_path('media/images/apple-touch-icon-114x114-precomposed.png')), :rel => 'apple-touch-icon-precomposed', :type => 'image/png', :sizes => '114x114' %>
+  <%= favicon_link_tag (asset_path('apple-touch-icon-114x114-precomposed.png')), :rel => 'apple-touch-icon-precomposed', :type => 'image/png', :sizes => '114x114' %>

   <!-- For first- and second-generation iPad: -->
   <!-- Size should be 72 x 72 pixels -->
-  <%= favicon_link_tag (asset_pack_path('media/images/apple-touch-icon-72x72-precomposed.png')), :rel => 'apple-touch-icon-precomposed', :type => 'image/png', :sizes => '72x72' %>
+  <%= favicon_link_tag (asset_path('apple-touch-icon-72x72-precomposed.png')), :rel => 'apple-touch-icon-precomposed', :type => 'image/png', :sizes => '72x72' %>

   <!-- For non-Retina iPhone, iPod Touch, and Android 2.1+ devices: -->
   <!-- Size should be 57 x 57 pixels -->
-  <%= favicon_link_tag (asset_pack_path('media/images/apple-touch-icon-precomposed.png')), :rel => 'apple-touch-icon-precomposed', :type => 'image/png' %>
+  <%= favicon_link_tag (asset_path('apple-touch-icon-precomposed.png')), :rel => 'apple-touch-icon-precomposed', :type => 'image/png' %>

   <!-- For all other devices -->
   <!-- Size should be 32 x 32 pixels -->
-  <%= favicon_link_tag (asset_pack_path('media/images/favicon.ico')), :rel => 'shortcut icon' %>
+  <%= favicon_link_tag (asset_path('favicon.ico')), :rel => 'shortcut icon' %>

   <%= google_tag_manager_script_tag(:default) %>

+    <%= stylesheet_link_tag "application" %>
+    <%= javascript_include_tag "application", "data-turbo-track": "reload", defer: true %>
+
   </head>
   <body>

開発サーバのスタート方法を変更します。

diff --git a/start.sh b/start.sh
index 1df6187..e986393 100755
--- a/start.sh
+++ b/start.sh
@@ -7,5 +7,6 @@ bundle exec rails db:migrate

 rm -f /app/tmp/pids/server.pid
-bundle exec rails server -b '0.0.0.0'
+
+bin/dev

webpack関連のファイルを削除します。

config/webpacker.yml
config/webpack/*
bin/webpack
bin/webpack-dev-server
postcss.config.js
.browserslistrc
babel.config.js

docker-compose.ymlからwebpack-dev-serverを削除

diff --git a/docker-compose.yml b/docker-compose.yml
index e9a41fd..6027e93 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -3,7 +3,6 @@ services:
   app:
     build: .
     environment:
-      WEBPACKER_DEV_SERVER_HOST: webpack
       BUNDLE_JOBS: 4
     volumes:
       - .:/app
@@ -12,20 +11,6 @@ services:
     command: ./start.sh
     ports:
       - "3000:3000"
-    depends_on:
-      - webpack
-
-  webpack:
-    build: .
-    volumes:
-      - .:/app
-      - bundle_app2:/usr/local/bundle:cached
-    ports:
-      - "3035:3035"
-    command: bin/webpack-dev-server
-    environment:
-      WEBPACKER_DEV_SERVER_HOST: 0.0.0.0
-      WEBPACKER_DEV_SERVER_HOT: 1

差分

変更したファイルやファイルの量はこんな感じです。yarn.lockがかなり減りました。

> git diff ee5315a51ea69c1573f5434fb0e1761bb675fcdf --stat
 .browserslistrc                                                            |    1 -
 .gitignore                                                                 |    3 +
 Dockerfile                                                                 |    1 +
 Gemfile                                                                    |   21 +-
 Gemfile.lock                                                               |   21 +-
 Procfile.dev                                                               |    3 +
 app/assets/builds/.keep                                                    |    0
 app/assets/config/manifest.js                                              |   12 +-
 app/{javascript => assets}/images/apple-touch-icon-114x114-precomposed.png |  Bin
 app/{javascript => assets}/images/apple-touch-icon-144x144-precomposed.png |  Bin
 app/{javascript => assets}/images/apple-touch-icon-72x72-precomposed.png   |  Bin
 app/{javascript => assets}/images/apple-touch-icon-precomposed.png         |  Bin
 app/{javascript => assets}/images/discord.png                              |  Bin
 app/{javascript => assets}/images/favicon.ico                              |  Bin
 app/{javascript => assets}/images/graphql_query.png                        |  Bin
 app/{javascript => assets}/images/ss.png                                   |  Bin
 app/assets/stylesheets/application.sass.scss                               |    8 +
 app/controllers/postcodes_controller.rb                                    |   14 +-
 app/javascript/{packs => }/application.js                                  |   20 +-
 app/javascript/controllers/application.js                                  |   10 +
 app/javascript/controllers/home.js                                         |   25 +
 app/javascript/controllers/index.js                                        |   12 +
 app/javascript/packs/home.js                                               |   36 -
 app/javascript/stylesheet/bootstrap_variables.scss                         |    3 -
 app/javascript/stylesheet/style.scss                                       |    4 +-
 app/views/layouts/application.html.erb                                     |   19 +-
 babel.config.js                                                            |   65 -
 bin/dev                                                                    |    9 +
 bin/webpack                                                                |   18 -
 bin/webpack-dev-server                                                     |   18 -
 config/environments/production.rb                                          |   17 +
 config/initializers/assets.rb                                              |   13 +
 config/routes.rb                                                           |    4 +-
 config/webpack/development.js                                              |    9 -
 config/webpack/environment.js                                              |   12 -
 config/webpack/production.js                                               |    5 -
 config/webpack/test.js                                                     |    5 -
 config/webpacker.yml                                                       |   92 --
 docker-compose.production.yml                                              |    4 +-
 docker-compose.yml                                                         |   15 -
 package.json                                                               |   25 +-
 postcss.config.js                                                          |   12 -
 start.sh                                                                   |    3 +-
 yarn.lock                                                                  | 7422 +++------------------------------------------------------------------------------------------
 51 files changed, 492 insertions(+), 7540 deletions(-)

まとめ

開発時のコンパイルが高速になったのでとても快適です。
資料が少ないし、いまいち構造がよくわからないので半日ぐらいかかりました。

RailsのアクターがN:Mのシステムを作るときの権限モデル

Sat, 08 Oct 2022 00:00:00 GMT

背景

手元で作っているRailsのサービスの要求が肥大化してきたので、権限モデルをちょっと整理してみました。

権限が複雑になる原因は、メトリックが多くなること。要件レベルでどれだけメトリックを減らせるかが重要。

ビジネスで利用するサービスの場合、細かい権限設定が要求されるのでメトリックが増えやすい。

今回扱わなければいけないメトリックは以下

アクター
ロール
マスタデータのステータス遷移
Web経由の操作 or API経由の操作

メトリックが3つ以上になった時点で直交表が作成できなくなってしまう。

メトリックが3つであれば、直交表を複数作ればギリギリ対応できるが、4つになると表現が厳しい。

アプローチ

メトリックが4つになった時点で、権限をわかりやすくまとめろと言われても不可能に近い。

Appleで買ったSIMフリー端末が「SIMロックあり」になったので解除した話

Wed, 20 Jul 2022 00:00:00 GMT

概要

日本のApple公式サイトからiPhone XS 256GBを買いました。Apple公式サイトから購入すればSIMフリーのはずなのですが、「SIMロックあり」という表示が出るようになってしまいました。
楽天モバイルのSIMを挿していて使える状態でした。Webの書き込みを見てみると、表示はSIMロックと書くかれていますが、実際にはされていないという書き込みを見たので、AhamoのSIMを挿してみたところ、「SIMロックあり」の表示はそのままですが、AhamoのSIMが使えたので実質はSIMフリーのようです。
どっちにしろ、この端末を売却したいので「SIMロックあり」という表示は消したいので、その方法を書いておきます。

時系列の整理

2018年9月: iPhone XS 256GBをAppleストアで購入
2019年8月: Face IDが使えなくなったので、保証期限内のため、Appleのサポートへ送付したら交換ということになって新品のiPhone XS 256GBが送られてきた。
2019年9月: DoCoMoの物理SIMを入れて利用開始
2021年x月: 楽天モバイルにMNPして楽天モバイルの物理SIMを入れて利用開始
2022年6月: 「SIMロックあり」という表示が出ていることに気づいた。しかし、実際にSIMロックされているかを検証したところSIMロックはされていない状態であり、表示だけがSIMロックありとなっている。

参考資料

こちらの記事によると、Appleにしか解除できないという記述があります。
- 上記記事の端末は、表示もSIMロックとあり、本当にSIMロックが掛かっていますが、私の端末はSIMロックという表示だけですが実際にはSIMロックはかかっていません。
こちらの記事では、SIMロックありという表示は嘘で、実際はSIMフリー。iOSの不具合で新しいiOSのリリースを待つ必要があるという結論です。

私はこのiPhone XS 256GBを売りたいので、SIMロックという表示があると値段が低くなってしまうので、なんとしても「SIMロックあり」の表示を外したいのです。

やったこと

Appleへの問い合わせ

Appleのサポートと電話で話した結果はこちら↓

「SIMロック」はキャリアがかけるものだからAppleではどうしようもできない。

関連する記事はこちらだから、こちらを見て1つ前のキャリアである楽天モバイルにSIMロックを解除を依頼して！

https://support.apple.com/ja-jp/HT201328

という感じでした。

1つ目の記事にある内容とは異なる回答が返ってきました。

反論しようにも、反論する材料が上記のWebサイトしか無いので、とりあえずAppleのサポートの言う通りにしてみます。

楽天モバイルへの問い合わせ

1時間20分にも及ぶ、長いチャットの結果、DoCoMoへリダイレクトされました。。。。

ここに至るまでに、たくさんの見当違いの質問をされて、反論したい気持ちを抑えながら回答を淡々と繰り返していたのに、この結果です。

SIMロック解除に必要であろう、IMEIも聞かれることはなかったです。たぶん、楽天モバイルの担当者は全く仕組みを理解していないことが想定されます。そもそも楽天モバイルはSIMロックが総務省に寄って禁止される頃に登場した事業者なのでSIMロックを行うユースケース自体が存在していない可能性があります。

もし、この後にドコモへ問い合わせて解決できなかったらたらい回し状態になってしまい、何が真実なのかわからないし、問い合わせ先もよくわからなくなってしまいます。

楽天モバイルのサポートとチャットをしながら、同時に裏でググっていたらドコモはWebからSIMロックの解除申請を行えるという記載を見つけました。

https://www.docomo.ne.jp/support/unlock_simcard/

DoCoMoでSIMロック解除申請

dアカウントが必要になるので、自分のdアカウントでログインして申請してみました。

IMEIを入力するだけで申請できました。しかも、確認画面で端末の情報が表示されてます。DoCoMoに提供した覚えはない情報なのでどううやってドコモが知り得たのか謎です。IMEIからハードウェアを特定する手法があるのかなと思います。（関連付けされた機種のストレージ容量は間違ってますが。。。）

すんなりと申請は完了。

この状態では、まだ申請だけしか行っていないです。

iPhoneの場合は「メッセージR」というものが送られてくるのでそれが来たら完了するらしいです。（メッセージRはtypoで、SMSのことだと思います）

SIMロック解除を実施するためには、他社のSIMカードなどの挿入や設定をした上で、お手続き完了画面に表示されるSIMロック解除コードを入力してください。また、一部端末においては、SIMロック解除コードの入力は不要です。

【iPhone/iPadのみ】メッセージＲの配信設定の有無に限らず、解除準備完了後に準備完了をお知らせする旨のメッセージRを送信いたします。メッセージＲ受信後にお客さまご自身で解除処理(端末へ他社SIMを挿入)をお願いいたします。メッセージRが届かない場合、お客さまから再度お申し出の必要があります。

ちなみに、Ahamoでも同じようにSIMロック解除の説明ページがありますがリンク先はDoCoMoのSIMロック解除ページに飛びます。

IMEIに関して

imei.infoというサイトでIMEIを入力したらハードウェアの情報が表示されたので、IMEIとハードウェア情報の関連付けは公開情報のようです。

DoCoMoでSIMロックを解除申請その後

結局、DoCoMoのサイト上でSIMロック解除申請をしても、結果を受け取れる手段が無いから結果がわかりません。

1週間後に、試しに端末を初期化してみましたが相変わらず「SIMロックあり」の表示で解決していません。

なので、DoCoMoへ問い合わせてみたら、「機器を販売したAppleに問い合わせてね」という回答。振り出しに戻った。

どの会社も明確なSIMロックの構造を理解していない。こちらの時間をかなり消費する。ほんとムカつく。しかし、まだ問題が誰にあるのかがわからないので根本的に誰が間違ったことを言っているのかがわからない。

Appleサポートへ2回目の問い合わせをしてみました。

1回目は、軽く鼻で笑われたような対応をされました（しかも結果として不適切な回答だったのでダブルでムカつく）が、今回対応してくれた人はちゃんと対応してくれている印象です。

ここで、普通のサポート窓口ではなく別の上位部署にエスカレされました。

その結果、以下のページに有るようにMacosにiPhoneをつないでリカバリーモードで初期化を試してほしいとのことでした。

https://ahamo.com/support/procedure/other/unlock-sim/index.html

その場で言われた手順を実行してトラブルシュートをしたかったのですが、サポートとの電話を開始してからすでに40分程度経っていて、別件のミーティングが始まるので私の持ち帰りの宿題として、電話を切りました。

そして、上記のリカバリーモードを試してみましたが状況は変わらず、「SIMロックあり」でした。

Appleサポートへの問い合わせ3回目

2回めに対応してくれた人とは別の人です。引き継ぎもされているはずなのですが、あんまり引き継がれていない模様です。

今まで試したことを確認されたり、販売経路を確認されたりと今までも何度も言ってきたことをすべて再確認されました。。。。

「なぜ楽天モバイルに問い合わせたのか？楽天モバイルで買った端末じゃないから、問い合わせても意味が無いのに。」と言われ、「Appleに言われたから。。。（怒）」という感じの問答を何回か繰り返しました。

そして、Apple社内でもこの問題に対して、ステップバイステップで対応マニュアルがあるらしくて、最終ステップがこのリカバリーモードでのリカバリーを行うことだったとのことでした。

これを行っても状況が変わらないとなると、Apple側で再度社内調整をした上で再度、状況ややったことの手順をヒアリングする電話を後日行うとのことで電話を切られました。

やっと前に進んだ感じはあります。

30分ほど使いました。

Appleサポートとの会話 4回目

1日後に電話が来ました。

なんか、サポートの人の説明が分かりづらかったです。Apple社内で「SIMロックを解除するための申請」をしたとのことで、その結果が出るのに1〜2日かかるとのことでした。

終わったら連絡が来るとのことでした。

10分使いました。

Appleサポートとの会話 5回目

2日後に電話が来ました。

担当者が休みを取っていたようで、2日後の連絡となってしまったようです。

そして、「Appleの別部署にて、"申請"の確認が取れたので、申請をしたその日のうちにSIMロック解除の設定をした」との連絡が来ました。

確かに、「SIMロックあり」という表示がなくなりました。これにて一件落着です。

後学のためにいくつかAppleのサポートの人に質問をしてみました。

Q: WiFiに接続しているだけ（＝キャリアのSIMを使わない状態）で、「SIMロックあり」の表示が「SIMロックなし」になった。SIMロックの情報を端末に反映するにはキャリアのネットワークは不要という理解で正しいか？
A: 正しい。WiFiでもSIMロックに関する情報は伝搬される。
Q: そもそも、なんでAppleがSIMロックの解除とかそういうのを管理しているの？
A: 普通はAppleで管理しない。SIMロックはAppleとは別の所で管理されている。今回のような何が原因かよくわからない状態でSIMロックになってしまった場合は、Apple社内でいろいろな承認を得るとSIMロック解除を行えるようになっている。

まとめ

Web上には様々な状況や解決策がありましたが、結局はこちらの方と同じ解決策でした。
最終的には無事に「SIMロックあり」の表示が消えたので良かったです。調査などを含めると8時間近く消費しました。

::amazon{asin="B0B1V5P27W"}

MegaRAIDの節電機能

Thu, 30 Jun 2022 00:00:00 GMT

概要

サーバの平均消費電力が80Wぐらいです。金額にすると約2000円/月。

主に電力を食うのはCPUかディスク。CPUはさほど使われていないのでおそらくハードディスクが電力を食っているような気がします。

HDDを4台搭載したファイルサーバなのでほとんどディスクは稼働していないので、ディスクをスピンダウンして節電しようと考えました。
strocli経由で節電モードを操作で来そうなのでやってみます。

現状の設定を確認

なんと、ハードウェアが未対応。。。

sudo /opt/MegaRAID/storcli/storcli64 /c0 show ds
Controller = 0
Status = Failure
Description = None

Detailed Status :
===============

--------------------------------------------------
Ctrl_Prop Value
--------------------------------------------------
DS        Adapter does not support Power savings.
--------------------------------------------------

ちなみに、dsとはDimmer Switchの略で、節電モードのことです。

有効化してみる

まぁ、エラーになるのですが一応試してみます。

sudo /opt/MegaRAID/storcli/storcli64 /c0 set ds=off type=4
Controller = 0
Status = Failure
Description = does not support PowerState

ホットスタンバイのHDDが2台無駄に動いているのが悲しいですな。

過去に立ち上げたサービスのまとめ

Tue, 07 Jun 2022 00:00:00 GMT

概要

過去に立ち上げたサービスを紹介します。

稼働中

駅・路線 REST API

https://blog.teraren.com/posts/ekidata-api/

銀行コード、支店コードAPI

https://blog.teraren.com/posts/japanese-bank-code-branch-code-api/

郵便番号API

https://blog.teraren.com/posts/postcode-api/

利用者はいないと思いますが、GraphQLにも対応しています。

https://blog.teraren.com/posts/api-graphql-postcode/

covid-19新規陽性者の都道府県ごとグラフ

https://blog.teraren.com/posts/covid19-japan-graph-feed/

AKB勝手にランキング

https://matsu.teraren.com/ranking/

確認くん

IPv4、IPv6対応の自分のグローバルIPを表示するサービス。curlでアクセスするとIPアドレスだけ返ってきます。

https://kakunin.teraren.com/

サービス停止・更新停止

Facebook pageのlike数をトラッキング

https://blog.teraren.com/posts/facebook-page-like-tracking/

CSSで絵文字を表現

https://github.com/matsubo/emoji-sprite

mixi2rss

https://diary.teraren.com/posts/2009-07-22-mixi-diary-feed/

読み物系記事のおすすめ15本ピックアップ

Tue, 07 Jun 2022 00:00:00 GMT

概要

このブログは開設から約19年経過しました。良い記事が埋もれてしまっていてもったいないので、個人的に過去に人気があったおすすめ記事を5ページ紹介します。

1位日本のインターネットの父。慶応大学最終講義。

事あることに、読み返しています。インターネットに関わる仕事をしている方はインターネットの成り立ちと理想を鑑みられる質疑応答です。はてなブックマークで1175件ブックマークされてます。ホットエントリーにも掲載されました。

https://blog.teraren.com/posts/mj-last-class-text/

2位 tmux-powerlineでおされにする

tmux powerlineは今でもこの設定に近いです。

https://blog.teraren.com/posts/moteru-tmux-powerline/

3位価値観的なもの

スタートアップをやろうとしている方へ向けての1つの考え方をまとめました。

https://blog.teraren.com/posts/before-the-startup/

こちらも合わせてどうぞ。上記をリバイズしたバージョンです。

https://note.com/yuki_matsukura/n/n08e53fdfd84d

4位 3rd party cookie周辺の内容

調査してみた内容のまとめです。世界のプライバシー保護への温度感がつかめます。

https://blog.teraren.com/posts/ad-accuracy-and-3rd-party-cookie/

5位写真や動画を安全に長期間保存する

「機密性」「完全性」「可用性」を程よく満たして写真や動画などの大容量データを安全に保管する方法。

https://blog.teraren.com/posts/photo-backup/

6位 Singletonは嫌いです

最近はOOP (オブジェクト指向プログラミング) の知識レベルの底上げがあり、見ることは少なくなりましたが、10年前はSingletonが多く見られました。

https://blog.teraren.com/posts/evil-singleton/

7位中小企業共通EDI

商取引に関わるシステムのときのモデルや、ビジネスの一般慣習を学べます。

https://blog.teraren.com/posts/edi/

8位クレカの頭6桁の仕様

クレジットカードのBINコード

https://blog.teraren.com/posts/credit-card-bin-code/

9位転職プラットフォームの価値を考察

https://blog.teraren.com/posts/job-change-platform/

10位ミル挽きコーヒーメーカー

https://blog.teraren.com/posts/office-coffee/

11位私が考える要求定義の流れとアウトプット

https://blog.teraren.com/posts/request-definition/

12位英語勉強の浅いノウハウ

https://blog.teraren.com/posts/english-learning/

13位コストコで買うものルーチーン

https://blog.teraren.com/posts/costco/

14位一応、私はエストニアの電子国民です。

https://blog.teraren.com/posts/e-residency/

15位 LINE詐欺をやってる人のIPアドレスを暴いてみた

ネタ的なかんじ

https://blog.teraren.com/posts/line-fraud/

現在位置情報から最寄り駅の一覧を取得する

Tue, 07 Jun 2022 00:00:00 GMT

概要

経度緯度から、最寄り駅の一覧を取得します。
ブラウザから経度緯度情報は Javscript で取得できます。

利用するAPI

駅情報・路線情報 REST APIを利用します。

REST API のサンプル。東京タワーからの最寄り駅一覧を出力してみます。distance の単位は km です。

% curl 'https://train.teraren.com/stations/near_by_stations.json?lon=139.7454316&lat=35.658584' | jq 'limit(5; .[])'
{
  "station_cd": 9930122,
  "station_name": "赤羽橋",
  "station_g_cd": 9930122,
  "distance": 0.4293522820451477
}
{
  "station_cd": 2800317,
  "station_name": "神谷町",
  "station_g_cd": 2800317,
  "distance": 0.48968747581839894
}
{
  "station_cd": 9930306,
  "station_name": "御成門",
  "station_g_cd": 9930306,
  "distance": 0.6242133516473801
}
{
  "station_cd": 9930305,
  "station_name": "芝公園",
  "station_g_cd": 9930305,
  "distance": 0.639515764707121
}
{
  "station_cd": 9930209,
  "station_name": "大門",
  "station_g_cd": 9930121,
  "distance": 0.8574239732003268
}

Webから利用する場合のサンプルコード

スクリーンショット

Stimulusによるサンプルコード。ブラウザから位置情報を取得して、駅の一覧を表示するだけのスクリプトです。サーバのCORSの設定はGETをどこのサイトからでもできるようにしてあるのでご自由に利用ください。

import { Controller } from 'stimulus';

export default class extends Controller {
  static targets = ['lon', 'lat', 'output'];

  getLocation() {
    if (!('geolocation' in navigator)) {
      alert('Allow browser to acquire location.');
    }

    navigator.geolocation.getCurrentPosition((position) => {
      this.latTarget.value = position.coords.latitude;
      this.lonTarget.value = position.coords.longitude;
    }, (error) => {
      alert(error.message);
    });
  }

  search() {
    const url = `https://train.teraren.com/stations/near_by_stations.json?lon=${this.lonTarget.value}&lat=${this.latTarget.value}&limit=5`;
    fetch(url)
      .then((response) => response.json())
      .then((json) => JSON.stringify(json, null, 2))
      .then((json_string) => { this.outputTarget.textContent = json_string });
  }
}

広告配信精度とプライバシー保護に関する法律と技術のまとめ

Fri, 03 Jun 2022 00:00:00 GMT

2022年5月に社内でLTした内容をまとめておきます。きっかけはGoogleのFLoCを調べていたら、FLoCを取り巻く歴史などの情報がまとまっていなかったのでまとめていました。

背景

プライバシーを守るための法律が制定されつつあります。

EU
- GDPR (General Data Protection Regulation)
- 2018年5月25日から適用開始
- Webサイトを見ていると「Cookie取得の同意」のポップアップ表示を見かけると思います。それはGDPRに準拠するためという目的がほとんどです。
US
- COPRA (Consumer Online Privacy Rights Act)
- 大統領の署名待ち。署名後180日で施行
日本
- 改正個人情報保護法
- 3年毎に更新。2022年4月に更新

問題

インターネット上の広告業界にとって、ユーザの個人情報の取得が困難になるので、ディスプレイ広告のターゲティング精度が落ちます。

ユーザにとってはプライバシーが重視される一方、ターゲティングの精度が落ちることになるので関連度の低い広告が表示されるようになります。

根底としては以下の相反する要求があります。

広告ターゲティング精度 VS プライバシー

背景技術の説明

この広告業者がユーザの情報を集めるために使っている技術が3rd party cookieという仕組みです。

1st partyは自分、2nd partyは閲覧しているウェブサイト、3rd partyとは広告配信業者に当たります。

昨今のChromeやEdgeでデフォルトである3rd party cookieが有効になっていると、ユーザはウェブサイトを閲覧しているだけで、ユーザが意図しないところで広告配信業者に情報を共有されてしまっている状態になります。

3rd party cookieによって広告配信業者に情報が渡る流れ

図にすると以下のような流れになります。

ユーザが広告のJavascriptコードが付いている健康器具のウェブサイトを閲覧する。
ブラウザがそのコードを実行して広告配信業者にアクセスし、広告配信業者はcookieを送信する。
広告配信業者から指示されたcookieをブラウザが保存する。
別のサイトをユーザが表示する。
同じ広告配信業者の広告のJavascriptコードが付いているウェブサイトを閲覧する。
別のサイトにアクセスしている情報と共に広告配信業者へ送信される。
広告配信業者はユーザがアクセスしたページのアクセス履歴を保存し、そこからユーザに適した広告を配信する。

3rd party cookieが禁止されるとできなくなること

広告配信業者がユーザのアクセス履歴を取れなくなります。

広告配信側
- アクセスしている人のアクセス履歴などの情報を取得できなくなる
- ターゲティングできなくなる
- リタゲできなくなる
エンドユーザ
- 第三者に自分のアクセスログに近いものが保存されなくなる
- 関連度の低い広告が表示される。

3rd party cookieに対しての各ブラウザの方針

3rd party cookieを無効
- safari
- Edge
- Brave
- Firefox
3rd party cookieが有効
- Google Chrome (2023年末に終了すると発表)

Googleが全方面で強い

では、なぜGoogle Chromeだけが3rd party cookieを無効にしていないかというと、Googleは広告配信を行っているので3rd party cookieが無効化されると広告収益が落ちるからです。

Google Chrome以外は広告収益への関連が無いのですぐに3rd party cookieを無効に動きました。

Googleは1st party cookieを埋め込めるようなソリューションや、自分自身のメディアを持っています。

また、Google Analyticsはウェブサイトに1st party cookieを埋め込んで居るのでGoogle Analyticsが裏側で値を突合していたら同じことが物理的には実現できてしまいますができないでしょう。Gmailも同様です。Google社の内部統制を信じるしか無いようなユーザにとっては危うい状態です。

まさに、この危うい状態になるのを防ぐための法律が最初に挙げた法律なのかなとも思います。

YouTubeに関しては、バーティカルなメディアなので自サイトで個人情報を集め、広告配信に利用できます。他社からの広告は期待できませんが、自社のアドネットワークだけで十分収益を得られるのでビジネスへの影響は無いでしょう。

Googleだけが3rd party cookieはいきなり廃止できない

広告配信業者がほぼGoogle一強になっているため、3rd party cookieが問題になります。

もし、広告配信業者が数万社とか存在していたら、個人情報が一箇所に集まるような構図にならないので3rd party cookieを禁止するというところまで行かなかったかもしれません。

よって、Googleは3rd party cookieの廃止には超絶反対の立場ですが、流石に世論はプライバシー保護の流れになっているので対応する必要が出てきます。

3rd party cookieが無くなったらどんな技術を使ってユーザに最適な広告を提供するか？がまさに現在進行系で問題になっていて、3rd party cookieとは別にプライバシーに考慮したターゲティング技術を作ることを行っています。

Googleが取ったアプローチ

Googleが新たに考えた技術がFLoCとTopicsの2つになります。タイムライン的には以下のような流れになります。

2021/3/30
- Google ChromeでFLoC(Federated Learning of Cohorts) を試験運用開始と発表
2022/1/25
- FLoCの開発を中止し、Topicsの技術テストを年内に行うと発表

次に、FLoCとTopicsの概要を説明します。

FLoC(Federated Learning of Cohorts)

FLoCの最初の部分である、"Federated Learning" の説明をします。

Federated Learningの説明

呼び方: フェデレイテッド・ラーニング、連合学習
抽象度高めの概念
流れ
- 青丸: 初期モデル構築
- 多数のエンドクライアントに配布
- エンドクライアントがモデルを修正
- エンドクライアントで作ったモデルを集めて集計して初期モデルを再構築
ユースケース例: 日本語IMEの予測変換モデル

https://ai.googleblog.com/2017/04/federated-learning-collaborative.html

Cohortの説明

コーホートとは、共通した因子を持ち、観察対象となる集団のこと。
- Wikipedia
文脈としてはコホート法のほうが近い。

FLoC(Federated Learning of Cohorts) の説明

コホートのフェデレイテッド・ラーニング
- 訳: 集団ごとにフェデレイテッド・ラーニングを適用する
https://wicg.github.io/floc/
- W3Cの仕様はworking draftの状態.
コホート（集団）は興味ごとに生成される。
- => 自分でコホートのIDとバージョンを取得できる。

W3Cに掲載されている、サンプルコードはこちら。ユーザのコホートのIDを取得するコード。この取得したIDを広告配信業者に送信して、広告配信業者はそれに対して最適な広告を配信する。

FLoCの動作の流れ

FLoCの問題

FLoCのデータが個人を特定できる情報と紐付けられる可能性
- =フィンガープリンティングリスク
トライアル中に3万グループが作られたことにより、特徴的な行動をする場合は個人が特定されてしまうぐらいになる。

ユーザのプライバシー保護ができそうな手法だったにも関わらず、実証実験をしてみたら意外とプライバシーが守られなかった手法となってしまいました。

個人的には、Cohortの粒度を調整することでプライバシーの調整できるので技術的には問題は無いと思います。

それより、根底にはCohortを管理しているGoogleのコンプライアンスを信じるしか無い状態になっていることが問題になるのかと思います。

Topicsの説明

FLoCと比較して、Topicsは非常にシンプルです。

Topicsの概要

ユーザーの過去3週間の閲覧履歴に基づき、ユーザーが関心を持つ3つのトピックを広告主へ送信
- ユーザは送信した内容は確認可能
- ユーザは送信する内容を変更可能

Googleが発表しているプロトタイプのスクリーンショット。

Topicの考察

かなりユーザのプライバシー保護に寄った手法です。

広告配信側
- ターゲティング精度がかなり低くなる
- デモグラなどのターゲティングも不可能
- 「ユーザの情報ではなく、表示する場所に関連した広告が増える」と思う
- 「DMPが消えることになるのと同義」かなと思う
ユーザ側
- 開示する情報を完全にコントロールできるので安心
- 興味のない広告が表示されることが多くなる

他の事例

では、プライバシーに考慮したブラウザという謳い文句のBraveはどうやってユーザのプライバシーを保護しながら効率的に広告を配信しているのか疑問に思ったので調べてみました。

An Introduction to Brave’s In-Browser Ads

流れは以下のような図です。

https://brave.com/intro-to-brave-ads/

広告をBraveの広告配信サーバに登録する
Braveブラウザは全部の広告をダウンロードする
Braveはユーザの興味モデルをブラウザ内で生成する
ユーザが閲覧しているサイトをトリガーとして、ブラウザ内で最適なタイミングと最適な広告を計算して表示する

広告の量が増えたらどうなるんだろうという疑問はありますが自分の情報が外に出ないので安全です。広告の配信に関しては非効率ですし即時性も無いのでちょっと微妙な感じはあります。

やはり両立は難しいです。

余談ですが、私はGoogle ChromeからBraveに半年ほど前に移行しました。

異業種ペルソナマーケティングAI推進協議会

アカデミック分野でもGoogleと同じように研究が進められています。

https://ai-persona.jp/ （サービス終了）

この場合、1st partyのサイトがユーザモデルを作ってそれを共有することでプライバシーに配慮しつつターゲティングの精度をあげようという試みかと思います。

完全に余談ではありますが、私が卒論（18年ほど前）で書いた「ユーザの行動を行動モデルに抽象化して利用する」というアプローチと同じです。

総括

アカデミック
- 普通は研究の世界では世の中の数年〜10年先を行くのが普通だが、プライバシーの分野では現在進行系の社会課題を研究対象としている。
1st party dataを3rd partyがかなり使いづらくなる
- 例:自社で広告案件を獲得して配信
- 例:外部には具体的な情報を渡しづらくなるので、マクロなデータを渡す。
- バーティカルなサービスが重宝されそう。1st party dataを持っている会社が広告配信を行う。YouTubeやTikTokみたいなメディアが強くなりそう。
Web3の流れ
- GAFAMが情報を持ちすぎることで力を持ちすぎる問題に対処するためにも、情報の管理をより個人に持ってくる動きが強まると予想。個人情報を集めて収益化してきたGoogle, Facebookは広告ビジネスが辛い事になりそう。だから、VRに力を入れたり、別のソリューションに力を入れたりしている。
- 個人情報はローカルまたは暗号化された状態でクラウドに持ち、物理的に自分がコントロールできる状態になるだろう。
  - メールで言えば、Gmail => Proton mail

FakerやGimeiのseedをrspecのseedと一致させる

Thu, 02 Jun 2022 00:00:00 GMT

概要

rspecにおいて、単体テストの順番や使うデータをランダム化してテストパターンを増やすために config.order = :randomを有効化するのは普通かと思います。
テストが失敗したときに、rspecコマンドの--seedオプションでランダム生成器のseedを固定してデバッグするときがあると思います。今回は、seedを固定してもテストが失敗したり成功したりして不安定でした。
そしたら、乱数生成のseedはFakerやGimeiは各ライブラリ内で乱数発生器のインスタンスを作っているのでランダムに生成された値に依存したテストがユニークになりませんでした。

問題が起きたテスト

FactoryBotで以下のようにエンティティを生成したうえで、このエンティティのページングをテストするコードでした。

ページングする際には、codeカラムでsortされているので生成される値がランダムになるとテストのときに検証する値が予期しないものとなってしまいます。

FactoryBot.define do
  factory :product do
    code { Faker::Alphanumeric.unique.alpha(number: 20)  }
    name { Gimei.prefecture.kanji  }
  end
end

rspecコマンドに--seedを渡してもFakerやGimeiで生成した値が固定されないことが問題でした。

実際にはこの問題を見つけるのに2時間ぐらいかかりました。結果だけ書くのは簡単ですが、見つけるのは結構大変です。

実装が正しいのか、テストが正しいのかわからない状況で検証を進めるのは結構大変なものです。しかも、seedオプションを渡しても検証したいコードの結果が変わったりするので辛かったです。

（そもそも、そんなカラムでソートしている実装なんて知らなかったし。natural orderで帰ってきていると思っていたという思い込みもあり。）

解決策

差分

GimeiやFakerにrspecで使っている乱数生成器を渡してあげれば良いです。GimeiやFakerを使っている場合は必ず入れるべき設定です。

--- a/spec/spec_helper.rb
+++ b/spec/spec_helper.rb
@@ -91,5 +91,11 @@ RSpec.configure do |config|
   #   # Setting this allows you to use `--seed` to deterministically reproduce
   #   # test failures related to randomization by passing the same `--seed` value
   #   # as the one that triggered the failure.
+  Kernel.srand config.seed
+
+  require 'faker'
+  Faker::Config.random = Random.new(Random.seed)
+
+  require 'gimei'
+  Gimei.config.rng = Random.new(Random.seed)
 end

結果

spec/spec_helper.rbはこんな感じになります。

  #   # Run specs in random order to surface order dependencies. If you find an
  #   # order dependency and want to debug it, you can fix the order by providing
  #   # the seed, which is printed after each run.
  #   #     --seed 1234
  config.order = :random
  #
  #   # Seed global randomization in this process using the `--seed` CLI option.
  #   # Setting this allows you to use `--seed` to deterministically reproduce
  #   # test failures related to randomization by passing the same `--seed` value
  #   # as the one that triggered the failure.
  Kernel.srand config.seed

  require 'faker'
  Faker::Config.random = Random.new(Random.seed)

  require 'gimei'
  Gimei.config.rng = Random.new(Random.seed)
end

テストコードの書き換え

値に依存しないようなテストコードに書き換えます。

今回は、返り値となるデータの中身の検証が必要だったので、FactoryBotのcreate時に定数を渡すことで対処しました。

Railsでsessionを無効化する方法

Sat, 28 May 2022 00:00:00 GMT

config/initializers/session_store.rbにRails.application.config.session_store :disabledを書き込んでアプリケーションサーバを再起動。

echo "Rails.application.config.session_store :disabled" > config/initializers/session_store.rb

検証

Ruby on Rails 7.0で検証。Rails 3からこの方法でできるっぽい。

before

% curl -v http://localhost:3001/ 2>&1 |grep -i cookie
< Set-Cookie: _train_session=9zmzzmUN5C%2FawwJc1xfMyQCNdWwVgoyQ4HeSgjCvK3tFdYR47cYGiKusOjIIL1goxvO3vhUazqJYtwUcQcWUGXjueOQLOyy89TOJ%2BpPgZOwcr1iFNsEXXxg4Mvt%2Be8IaCWilq7EmBn3q3r2DiK4TcfaS%2FKw9Qs3qNe6GftE%2BlYprxg3r9esCOkyVPva3OLw08IZOtgtvzcyyC6zbtTlBZ7lX9OV0E3ngUU8a5XdcFJ2bBzmKk4W6DAvIGrqOvza%2Bb7eUgWv60YdOJb5LWUkc9B3gmFz1AA%3D%3D--Zqf%2B2sbFYn7PYeMM--LPCwaBZ27oJWCKVb4lpuQA%3D%3D; path=/; HttpOnly; SameSite=Lax
%

after

% curl -v http://localhost:3001/ 2>&1 |grep -i cookie
%

Error response from daemon: network xxxxxxxx not foundエラーが出たけど解決

Sat, 28 May 2022 00:00:00 GMT

問題

コンテナを起動しようとしたら以下のような感じのエラーが出ました。

% docker-compose run --rm app bash
[+] Running 2/2
 ⠿ Container train-chrome-1  Created                                                                                                                                                                                    0.0s
 ⠿ Container train-db-1      Recreated                                                                                                                                                                                  1.2s
[+] Running 1/2
 ⠹ Container train-chrome-1  Starting                                                                                                                                                                                   0.2s
 ⠿ Container train-db-1      Started                                                                                                                                                                                    0.2s
Error response from daemon: network 44b6d50a789537858cbdfe53a498bd50d288214b673c8c393ffc450ee942ac06 not found

試したこと

以下のようにお掃除すれば直るとかいてありますが、直りませんでした。

docker-compose up --force-recreate

https://stackoverflow.com/questions/53347951/docker-network-not-found

一通り、以下のことを試しましたが、解決しませんでした。

docker-compose down
docker-compose build
docker-compose up --force-recreate
docker network prune
docker network inspect <id> で調査したけど、not foundと言われる。。。
docker engineの再起動

解決方法

結局は、docker-compose upしたときにdocker-compose.ymlから削除したサービスがあったのですが、それを起動しようとしているようなメッセージを見つけました。

docker-compose.ymlを変更前に戻して、docker-compose downを実行した上で、docker-compose upをしたら正常に起動できました。

エラーメッセージからはかなりわかりづらくて困りました。。。

路線・駅データのAPIサービスをRuby on Rails 7 + Tailwind CSSで構築しました

Thu, 26 May 2022 00:00:00 GMT

概要

Ruby on Rails 7 から Tailwind CSS がサポートされました。
Rails が公式でサポートするからにはさぞかし良いものだろうと思うので使ってみたいと思い、ゴールデンウィークの 1 日を使って構築してみました。
路線・駅データのAPI

スクリーンショット

まずは成果物の紹介です。

トップページ

APIドキュメント

リクエストサンプル

山手線の駅名と緯度経度を取得する例。

% curl -s  https://train.teraren.com/lines/11302/stations.json | jq -r '.[] | [.station_name, .lat, .lon]'
[
  "大崎",
  "35.619772",
  "139.728439"
]
[
  "五反田",
  "35.625974",
  "139.723822"
]
[
  "目黒",
  "35.633923",
  "139.715775"
]
[
  "恵比寿",
  "35.646685",
  "139.71007"
]
[
  "渋谷",
  "35.658871",
  "139.701238"
]

なぜ駅・路線のAPIサービスを作ったのか？

駅データのサイトにて10年以上前から路線と駅のマスタデータがCSVファイルで公開されていました。
上記のサイトにてAPIからデータを取得できるようになっていたようですが、サービスが停止されていました。
類似サービスは様々な会社が提供していますが、無料でユーザ登録なしに簡単に利用できるAPIがありませんでした。
駅データのマスタ情報は、運営元の方がオープンなライセンスを適用してくださっているので、それを有効活用したかった。

作業の流れと使った時間

ekidataのマスタ情報の学習: 1h
Tailwind CSSのチュートリアル: 1h
開発環境構築: 2h
- rails new . -c tailwind
- docker-compose設定
プログラム開発: 6h
- model作成
- migrations作成
- i18n
daisyUIの学習: 1h
UIコーディング: 4h
Lighthouse用チューニング: 1h
OpenAPI Specification 3形式でのAPIドキュメント作成: 1h
サーバ設定: 1h

Railsの主な設定

追加したgem

gem 'rails-i18n', '~> 7.0.0'
gem 'kaminari'
gem 'sitemap_generator'
gem "meta-tags"
gem "rack-cors"
gem "google-tag-manager-rails", "~> 0.1.3"
gem "gretel", "~> 4.4"
gem "geocoder", "~> 1.8"

## for dev and test
gem 'rubocop', '~> 1.28'
gem 'openapi3_parser'
gem 'openapi_parser'
gem 'annotate'

gem 'rspec-rails'
gem 'capybara-screenshot'

tailwindの設定

diff --git a/config/tailwind.config.js b/config/tailwind.config.js

index 34c0c84..01f8719 100644
--- a/config/tailwind.config.js
+++ b/config/tailwind.config.js
@@ -17,5 +17,16 @@ module.exports = {
     require('@tailwindcss/forms'),
     require('@tailwindcss/aspect-ratio'),
     require('@tailwindcss/typography'),
-  ]
+    require('daisyui'),
+  ]
 }

工夫した点

Lighthouse のスコアがほとんどチューニングしないで 95 点も出せました。

感想

Tailwind CSS だけではプリミティブな UI ライブラリ集なので、Tailwind CSS だけを使ってページを作るのはかなり大変です。
UI の部品であるコンポーネントは daisyUIを使いました。
- Twitter Bootstrap は Tailwind CSS + デフォルトでそこそこ見栄えの良いアセットが提供されているのに対して Tailwind ではマークアップのライブラリとそれを使った UI のアセットは綺麗に分割されています。

Tailwind だけだと、左のように書かないといけないのですが右のように書けます。daisyUI はこのように Tailwind の 1 段階上位で提供されている UI のアセット集という位置づけです。その結果、Twitter Bootstrap と同じような DSL で UI をマークアップできます。

Tailwind が node に依存していないということもあり、全体的にコンパイルが速くて良いです。
ページ内で使っているスタイルしかコンパイルされないので、必要最低限の CSS がコンパイルされるのでファイル容量が少なくて良いです。
DSL (Domain-Specific Language) が 1 つ増えるのは辛いところではありますが、daisyUI のおかげで覚える項目はほとんど無いです。

まとめ

UI ができないエンジニアでも良い感じの UI を作れました。
今は基本的な API しか作っていませんが、もっと便利なユースケースの API を増やしていきます。
そのうちテクニカル編を書きたいと思います。

路線情報・駅情報のREST APIサービスを作りました

Sat, 21 May 2022 00:00:00 GMT

概要

https://train.teraren.com/

Ruby on Rails 7 + Tailwind + daisyui で作りました。

まだ、エンティティの一覧と取得しかできませんが、これから機能拡充をしていきます。ほしいAPIがあったら教えて下さい。

例

ある駅の周辺駅を近い順に表示
GraphQL対応
駅の距離

API呼び出し例

駅の名前と位置情報の一覧をCSVで取得する例

% curl -s https://train.teraren.com/stations.json| json_pp | jq '.[] | [.station_name, .lon, .lat] | @csv'
"\"函館\",\"140.726413\",\"41.773709\""
"\"五稜郭\",\"140.733539\",\"41.803557\""
"\"桔梗\",\"140.722952\",\"41.846457\""
"\"大中山\",\"140.71358\",\"41.864641\""
"\"七飯\",\"140.688556\",\"41.886971\""
"\"新函館北斗\",\"140.646525\",\"41.9054\""
"\"仁山\",\"140.635183\",\"41.930011\""
"\"大沼\",\"140.669347\",\"41.971954\""
"\"大沼公園\",\"140.669758\",\"41.980958\""
"\"赤井川\",\"140.642678\",\"42.003267\""
"\"駒ケ岳\",\"140.610476\",\"42.038809\""
"\"東山\",\"140.605222\",\"42.06172\""
"\"姫川\",\"140.591632\",\"42.081312\""
"\"池田園\",\"140.700333\",\"41.990692\""
"\"流山温泉\",\"140.716358\",\"42.003483\""
"\"銚子口\",\"140.720656\",\"42.015471\""
"\"鹿部\",\"140.771393\",\"42.06439\""
"\"渡島沼尻\",\"140.747596\",\"42.10706\""
"\"渡島砂原\",\"140.689451\",\"42.12164\""
"\"掛澗\",\"140.64598\",\"42.119205\""
"\"尾白内\",\"140.613449\",\"42.111232\""
"\"東森\",\"140.59353\",\"42.106823\""
"\"森\",\"140.573846\",\"42.108917\""
"\"桂川\",\"140.5427876\",\"42.1156004\""
"\"石谷\",\"140.506525\",\"42.135519\""
"\"本石倉\",\"140.471957\",\"42.159668\""
"\"石倉\",\"140.458436\",\"42.17285\""
"\"落部\",\"140.420755\",\"42.187617\""
"\"野田生\",\"140.37586\",\"42.217104\""
"\"山越\",\"140.326593\",\"42.231172\""
"\"八雲\",\"140.273342\",\"42.253391\""
"\"鷲ノ巣\",\"140.269919\",\"42.278389\""
"\"山崎\",\"140.2746\",\"42.314635\""
"\"黒岩\",\"140.288173\",\"42.368296\""
"\"北豊津\",\"140.297868\",\"42.400969\""
"\"国縫\",\"140.320885\",\"42.439319\""
"\"中ノ沢\",\"140.346077\",\"42.477928\""
"\"長万部\",\"140.37507\",\"42.512477\""
"\"長万部\",\"140.37507\",\"42.512477\""
"\"二股\",\"140.320821\",\"42.575869\""
"\"蕨岱\",\"140.313353\",\"42.626353\""
"\"黒松内\",\"140.305704\",\"42.669608\""
"\"熱郛\",\"140.375084\",\"42.675653\""
"\"目名\",\"140.465742\",\"42.761432\""
"\"蘭越\",\"140.52894\",\"42.804542\""
"\"昆布\",\"140.596107\",\"42.797984\""
"\"ニセコ\",\"140.684588\",\"42.808746\""
"\"比羅夫\",\"140.722615\",\"42.84856\""
"\"倶知安\",\"140.745471\",\"42.90164\""
"\"小沢\",\"140.677657\",\"42.97185\""

Tailwind良い

最近、lighthouseでのベンチマークをしているとCSSやJSが重すぎるというアラートが出ています。

assetをprecompileすると一部のスタイルしか使わないのに全部を読み込まないといけなかったのが必要最低限の読み込みだけで済むようになりました。

おかげで、lighthouseのスコアがめちゃめちゃ高い！

しかしながら、TailwindはOSSでは無いので、今後長期的にコミュニティが乗っかってくるのかは不明です。

しかもライセンスの制約が厳しくて、コンポーネントの配布が制限されています。Twitter Bootstrapの場合はテーマがたくさん作られたことによって導入のハードルをかなり下げましたが、Tailwindはそのようなコンポーネントが制限されているようです。

じゃあ、このnpmは良いのか？って感じがします。。。

https://daisyui.com/

Rails 6.1.5でdb:migrationのときにreference周りでエラー

Thu, 19 May 2022 00:00:00 GMT

問題

rails db:migrateをしたときに、以下のようなエラーが出るようになってしまった。

親のキーがbigintで作られていないから、外部キーが貼れないというエラー。

Column `parent_id` on table `children` does not match column `id` on `parents`, which has type `bigint`. To resolve this issue, change the type of the `parent_id` column on `parents` to be :bigint. (For example `t.bigint :parent_id`).
Original message: Mysql2::Error: Referencing column 'parent_id' and referenced column 'id' in foreign key constraint 'fk_rails_0525da88a4' are incompatible.

調査

しかしながら、show create table parents; してみたら、親のカラムはbigintで作られている。。。

rails 6.1.6に上げたら発生しなくなりました。rails 6.1.5に戻したら再現性あります。

rails 6.1.6のchangelogを見てもそれらしき記述はなかったです。謎です。

migrationのファイルはすべて6.0以降です。

以下の結果は何も無いことを確認。

% git grep ActiveRecord::Migration db |grep -v 6.0|grep -v 6.1

考察

面倒なので原因は深追いしてない。。。

chromedriverのインストールをarmとintelのDockerfileで共通化

Wed, 11 May 2022 00:00:00 GMT

概要

E2Eテストをするためのchromedriverは、Linuxのディストリビューションごとにパッケージで提供されていないので、おそらく直接ダウンロードしているケースがほとんどかと思います。

Dockerfile上で、アーキテクチャごとにダウンロードするファイルを振り分けるのが理想ですが、Dockerfileではそのようなことはできず、shellscriptを書いて判定する必要があります。

Dockerfileにif文を書くとエスケープ文字や改行で見づらくなるので別途スクリプトを用意してアーキテクチャごとにダウンロードするファイルを変更するのが良いです。

スクリプト

https://gist.github.com/matsubo/ed900c43f9d00c1bc9e24c3873f9efeb

追記

む。後日確認したら、chromedriver_mac64_m1.zipが動かなそうだ。。。

第二種電気工事士の受験記録

Thu, 05 May 2022 00:00:00 GMT

概要

家のリフォームをするに当たって、低圧電気の配線を工事するためには国家資格である第二種電気工事士が必要になるので取りました。
第二種電気工事士に合格したのでその時の記録を書いておきます。

タイムライン

2020年3月31日申し込み
- 9,593円（事務手数料　293円込み）
筆記試験が2020年5月31日に実施予定でしたが、新型コロナウィルスにより延期されました。
2020年10月4日筆記試験
2020年12月12日実技試験

筆記試験へ向けての勉強

以下の参考書と問題集がセットになっているものを買って勉強しました。試験の1ヶ月前から、週末に数時間勉強していたのでだいたい20時間ぐらいやったかと思います。

::amazon{asin="4907394705"}

私の勉強の仕方としては、オーソドックスですが以下のような感じです。

教科書部分をサラッと読む。
問題集をやる。
できなかったところを復習してできるようにする。
（その後は2と3の繰り返し）

また、予備としてホーザンのYouTubeを寝る前に見ながら寝てました。

https://www.youtube.com/playlist?list=PLsb6Jp0PqtFzL6fcQnF4KZLaMy-K_MKL7

合格基準点は60点以上なので不得意な分野はバッサリ切って、簡単なところだけを押さえるだけで十分です。

資格偏差値は44なので低いです。

試験の1週間前には、この過去問サイトを3つ分行いました。適当にやって合格点はクリアできることを確認しました。

会員登録して、途中からでも再開できるのでスキマ時間で実施できました。

https://kakomonn.com/2shudenkikoujishi/

こんな感じでスコアのスクショを保存していきました。

筆記試験

筆記試験は、片道1時間半近くかかって、多磨駅（漢字はこれが正しい）にある東京外語大学のキャンパスへ。

早く付きすぎて、室内に入れないので、キャンパスのベンチで復習しておきました。

問題は持ち帰れるので、すぐに発表される速報で自己採点で8割以上取れていたので良しとします。

実技試験へ向けて

実技のためには、資材を加工するための道具と実技試験を練習するための資材を買う必要がありました。

カッターとかペンチはすでに持っていたので、特殊な工具などを追加で買いました。

買ったもの

教科書と問題集がセットになったもの。必須です。

::amazon{asin="4907394748"}

資材。高いですけど、必須です。私はこのキットのように1回分あれば十分でした。使い終わったら、9000円ぐらいでは売れます。流用したければ、実際に使っても良いですし。

::amazon{asin="B079JG1MD1"}

必須です。ワイヤーのカット、ストリップ、圧着を1本でできます。

::amazon{asin="B00FO0IS5A"}

これは、実際いらないような気もしますが安いので買っておきます。家の蛇口の工事のときにも使えます。

::amazon{asin="B00FB92WQ0"}

勉強の進め方は、教科書を頭の方から、1問ずつ進めました。問題と解説を軽くさらって、実際に作ってみました。

作った結果は以下のように全部画像に保存しつつ、時間を記録していきました。また、不良部分は画像にメモしておきました。

最終的には問題集を1周回して全部作って、あとは苦手だった問題を何個か作りました。

この頃には、複線図を書かないでもいきなり作り始められるようになっていました。

実技試験

東京ビックサイトの南ホールです。新型コロナウィルスが流行っていたのと、電車だと行きづらいところなので車で行きました。

帰りは駐車場を出るのにすごい渋滞してました。。。

試験の自体は、複線図を書くことは無く、すぐに制作に取り掛かって完成したので10分ぐらいで終わってしまいました。

残り時間が暇だったので、すごい綺麗に整形してました。

その後

実技試験の練習のために使った資材に関しては、できるだけもとに戻してヤフオクで売りました。

練習して使用済みの電線は、市区町村のリサイクル回収ボックスがあったので全部そこへ持っていきました。

まとめ

自分で天井にWiFi アクセスポイントを付けたりできるようになりました。

armとintelのdocker-compose共通化へ向けて(mysql編)

Mon, 02 May 2022 00:00:00 GMT

追記

Officialの方でもarm64に対応していたのでオフィシャルをそのまま使えそうです。

この記事を書いた時点ではまだリリースされていませんでした。

https://x.com/matsubokkuri/status/1696078129100660767

背景

m1(arm)のmacで既存プロジェクトのdocker-compose upをすると以下のようなエラーが出ます。
- Host '172.21.0.4' is not allowed to connect to this MySQL server
理由はこちらの記事がよくまとまっています。

アプローチ

あちこちで使われている、Docker公式イメージである、'mysql' はamd用しか提供されていません。arm用は、別のイメージ名で提供されているようです。

しかしながら、Docker HubにあるMySQLが提供している、mysql/mysql-server イメージはintel用とarm用を提供しています。設定ファイルを共通化したいのでimage名が同じマルチアーキテクチャビルドしてあるmysql/mysql-serverを使います。

MySQL Server 8.0, the latest GA, for both x86 and AArch64(ARM64) architectures (tag: 8.0, latest) (mysql-server/8.0/Dockerfile)

https://hub.docker.com/r/mysql/mysql-server

なので、mysql/mysql-server を指定することで設定を共通化できます。

https://gist.github.com/matsubo/94666cf045af3ad8f91fada59116a1dd

しかしながら、Docker Hubのイメージと、MySQLが出しているイメージは初期化スクリプトがちょっと違うようなので設定を追加で行う必要がありました。(上記の差分を参照)

初期

mysqlの/entrypoint.shの中で、MYSQL_ROOT_HOSTが参照されるのはmysqlのdataディレクトリが未作成の時だけです。

データディレクトリが存在しないか、消した状態で上記の設定を動かせば特に気にする必要はありません。

MYSQL_ROOT_HOSTオプション無しで作成済みの場合

ファイルのownerを設定

volumeを永続化している場合は、以下のようなコマンドを打ってownerを再設定する必要があります。imageによってuser idが変わっているためです。

docker-compose run --rm db chown -R mysql.mysql /var/lib/mysql /run/mysqld/

接続元許可

作成済みの場合は、権限を変えてあげる必要があります。

docker-compose run db bashとかして、mysql -u rootとかして、DBに特権でログインします。

以下のようなクエリーを打って、権限情報を変更します。変数部分は手元の環境に合わせて置き換えてください。

MYSQL_ROOT_HOSTは、%にします。

ALTER USER 'root'@'localhost' IDENTIFIED BY '${MYSQL_ROOT_PASSWORD}';
CREATE USER 'root'@'${MYSQL_ROOT_HOST}' IDENTIFIED BY '${MYSQL_ROOT_PASSWORD}';
GRANT ALL ON *.* TO 'root'@'${MYSQL_ROOT_HOST}' WITH GRANT OPTION ;
GRANT PROXY ON ''@'' TO 'root'@'${MYSQL_ROOT_HOST}' WITH GRANT OPTION ;

まとめ

ちょっと前までは、Dockerfile自体を分ける必要がありましたが、今はDockerfileとdocker-compose.ymlを別にする必要はなさそうです。
armでの開発環境構築がかなりスムーズになりそう。

Toonesの利用料を取得するスクリプト

Mon, 02 May 2022 00:00:00 GMT

概要

Toonesのサービス利用料を集計するためにはWebの画面にログインしてCSVファイルをダウンロードする方法しか無く、APIで取得ができません。
手元で毎月集計したいので簡単なスクリプトを作ってみました。
とりあえず作っただけなのでハードコードが多いです。HTTPクライアントはMechanizeを使っています。
後々、Google Driveに追記していくようなスクリプトにします。

ソースコード

考察

ドハマリしたポイントは、ダウンロードしたCSVファイルに改行コードが、CRとCRLFの2つが混じっていたことです。rubyのCSVライブラリが文字コードやCSVparse周りでエラーを出すけど原因がわからずに問題を見つけるのが大変でした。

Amazon Linux 2にtigをインストール

Wed, 27 Apr 2022 00:00:00 GMT

Extra Packages for Enterprise Linux (EPEL)に入っているので、EPELを有効化して、tigをインストールするだけ。

% sudo amazon-linux-extras install -y epel
% sudo yum -y install tig

armとintelのdocker-compose共通化へ向けて(Ruby on Rails編)

Tue, 26 Apr 2022 00:00:00 GMT

問題

M1macでDockerのrubyイメージを使おうとすると、nokogiriの部分でエラーが出ます。

% docker run --rm -it ruby:3.0.3-buster bash
root@489921d6a766:/# gem i nokogiri
Fetching nokogiri-1.13.4-aarch64-linux.gem
Successfully installed nokogiri-1.13.4-aarch64-linux
1 gem installed
root@489921d6a766:/# irb
irb(main):001:0> require 'nokogiri'

ERROR: It looks like you're trying to use Nokogiri as a precompiled native gem on a system with glibc < 2.17:

  /lib/aarch64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /usr/local/bundle/gems/nokogiri-1.13.4-aarch64-linux/lib/nokogiri/3.0/nokogiri.so) - /usr/local/bundle/gems/nokogiri-1.13.4-aarch64-linux/lib/nokogiri/3.0/nokogiri.so

  If that's the case, then please install Nokogiri via the `ruby` platform gem:
      gem install nokogiri --platform=ruby
  or:
      bundle config set force_ruby_platform true

  Please visit https://nokogiri.org/tutorials/installing_nokogiri.html for more help.

/usr/local/bundle/gems/nokogiri-1.13.4-aarch64-linux/lib/nokogiri/extension.rb:7:in `require_relative': /lib/aarch64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /usr/local/bundle/gems/nokogiri-1.13.4-aarch64-linux/lib/nokogiri/3.0/nokogiri.so) - /usr/local/bundle/gems/nokogiri-1.13.4-aarch64-linux/lib/nokogiri/3.0/nokogiri.so (LoadError)
	from /usr/local/bundle/gems/nokogiri-1.13.4-aarch64-linux/lib/nokogiri/extension.rb:7:in `<top (required)>'
	from /usr/local/bundle/gems/nokogiri-1.13.4-aarch64-linux/lib/nokogiri.rb:10:in `require_relative'
	from /usr/local/bundle/gems/nokogiri-1.13.4-aarch64-linux/lib/nokogiri.rb:10:in `<top (required)>'
	from <internal:/usr/local/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:160:in `require'
	from <internal:/usr/local/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:160:in `rescue in require'
	from <internal:/usr/local/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:149:in `require'
	from (irb):1:in `<main>'
	from /usr/local/lib/ruby/gems/3.0.0/gems/irb-1.3.5/exe/irb:11:in `<top (required)>'
	from /usr/local/bin/irb:23:in `load'
	from /usr/local/bin/irb:23:in `<main>'
<internal:/usr/local/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require': cannot load such file -- nokogiri (LoadError)
	from <internal:/usr/local/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
	from (irb):1:in `<main>'
	from /usr/local/lib/ruby/gems/3.0.0/gems/irb-1.3.5/exe/irb:11:in `<top (required)>'
	from /usr/local/bin/irb:23:in `load'
	from /usr/local/bin/irb:23:in `<main>'
irb(main):002:0>

原因は、Nokogiriが1.11あたりからプリコンパイルされて配布されるようになりました。そのバイナリは、glibc 2.17でコンパイルされています。

しかしながら、arm用にコンパイルされたnokogiriが参照している /lib/aarch64-linux-gnu/libm.so.6が2.29を必要としているっぽくてエラーになります。

解決方法

静的リンクするか、独自でコンパイルするのが良さそうです。静的リンクはバイナリサイズがでかくなりそうなので独自でコンパイルします。

Bundlerを使っている場合

Bundler使っている場合は以下を打って自分でコンパイルするように設定します。

# bundler 2.1以降
% bundle config set force_ruby_platform true

# bundler 2.0以前
% bundle config force_ruby_platform true

そうすると、.bundle/configに以下が入ります。

---
BUNDLE_FORCE_RUBY_PLATFORM: "true"

もし、.bundleディレクトリを.gitignoreで無視するような設定を書いていたり、ユーザ側で設定した.bundleディレクトリを使うようにしている場合はホームディレクトリの設定ファイルに書き込んであげるのがよいです。

bundle config set --global force_ruby_platform true

実行例

% docker run --rm -it ruby:3.0.3-buster bash
root@11a428c7e8da:/# bundle config set force_ruby_platform true
root@11a428c7e8da:/# bundle init
Writing new Gemfile to //Gemfile
root@11a428c7e8da:/# bundle add nokogiri
Fetching gem metadata from https://rubygems.org/.......
Resolving dependencies...
Fetching gem metadata from https://rubygems.org/.......
Resolving dependencies...
Using bundler 2.2.32
Fetching racc 1.6.0
Fetching mini_portile2 2.8.0
Installing racc 1.6.0 with native extensions
Installing mini_portile2 2.8.0
Fetching nokogiri 1.13.4
Installing nokogiri 1.13.4 with native extensions
root@11a428c7e8da:/# bundle exec irb
irb(main):002:0> require 'nokogiri'
=> true

Bundlerを使っていない場合

--platform=ruby オプションをつけてインストールします。

root@b4ca7905b3a5:~# gem install nokogiri --platform=ruby
Fetching nokogiri-1.13.4.gem
Building native extensions. This could take a while...
Successfully installed nokogiri-1.13.4
1 gem installed
root@b4ca7905b3a5:~# irb
irb(main):001:0> require 'nokogiri'
=> true
root@b4ca7905b3a5:/# gem list|grep nokogiri
nokogiri (1.13.4)

手元での変更

結果的に手元のプロジェクトでは以下のような変更をDockerfileに行いました。

+ RUN bundle config set --global force_ruby_platform true

参考資料

詳細はこちらのissueにかかれています。

https://github.com/sparklemotion/nokogiri/issues/2075

不確実情報

環境によっては、arm用のbinaryがインストールされたりもするので、これが実現すればコンパイルの時間が取られなくて良いのでどういったときにこのような設定ができるのかを検証中です。

https://gist.github.com/matsubo/94666cf045af3ad8f91fada59116a1dd/b45e953d224220676898b1b84e7622edde3c1efe

AASMでステータス変更と同じクリティカルセクションで実行

Wed, 20 Apr 2022 00:00:00 GMT

概要

主にActiveRecordと併用して使うステータス管理用のgemがあります。
AASM（ステートマシーン）です。
「ステータス変更と同時に別の処理を実行したい」という要求を満たすために排他制御（主にデータベースのトランザクション）を使う場面がありますが、どのコールバックを使うのかがAASMのドキュメント内で明示されていなかったので書いておきます。

問題

よくAASMのサンプルコードで見つけるのが、after_commitコールバックに処理をしたいメソッドを書く方法です。

https://qiita.com/satour/items/fe838dc21dc95df95c62

上記にあるコードでは、ステータスの変更が終わったら通知をするというような別に処理を行っても問題ない処理なのでコードは正しいです。
要するに、after_commitはその名の通りAASMによって管理されているステータスが更新されたことをDBにコミットした後に実行されます。
しかしながら、AASMで管理するステータスと別のテーブルにあるステータスを同時に更新する場合にafter_commitコールバックを使うだけでは不十分です。

アプローチ

after コールバックを使います。

afterコールバックを使うと、AASMで管理するステートと同じトランザクション内で実行されます。

https://github.com/aasm/aasm/blob/master/lib/aasm/aasm.rb#L177

afterコールバックは、eventとtransitionに対して設定できます。

余談

requires_lock: trueは付ける必要があります。

Envoy(受付アプリ)のSlack通知が遅いので自作

Thu, 24 Mar 2022 00:00:00 GMT

概要

Envoyというオフィスのエントランスで受付をするシステムがあります。
理想のワークフローは、Envoyで訪問者が受付をした際に、担当者宛にSlackで通知を飛ばすこと。
Envoyが提供しているSlackのIntegrationを使うと、通知が届くまで4〜5分かかるのでかなり問題。（どうやら、2回めの通知は早い。SlackのIntegrationの初回呼び出しが遅い感じ。）
Envoyからのwebhookは即時で届くので、SlackのIntegrationを使うのではなく自作したプログラムを使います。

設計

通信のフローは以下のようになります。

Envoy => (webhook) => なんかしらのScript => (webhook) => Slack

Scriptの部分を作って設置します。

スクリプトは以下のような感じです。EnvoyからはPOSTでいろいろなデータが送られてくるので、必要なデータを抽出してSlackへ通知します。

SlackのWebhookのURLはパラメータで受け取れるようにしておきます。

https://gist.github.com/matsubo/a5f8eb01057dbf86cd3fc9cb2d116ebc

設定

予め、Slack側で通知を送りたいチャネルでwebhookのURLを発行しておきます。

Envoyに管理者でログインして、上記のスクリプトのURLを登録します。

https://dashboard.envoy.com/integrations

設定するWebhookのURLには忘れずにurlパラメータでslackの通知先webhookを入力します。一応、urlencodeした値を入れておきます。

URL例

https://example.com/slack.php?url=https%3A%2F%2Fhooks.slack.com%2Fservices%2FT0000XXXX%2Fxxxxxxxxxxx%2Fxxxxxxxxxxxxxxxxxxxxxxxxx

通知のサンプル

まとめ

ほぼ即時に通知が来るようになりました。
webhookを動かしているPHPのアプリケーションサーバが落ちると通知が来なくて辛い状態になります。
mentionさせるためには、SlackとEnvoy間でユーザの紐付けをしないといけないので今回はやってません。

参考資料

EnvoyからWebhookで送られてくるサンプルデータはこちらです。

Google Domainsのドメインでメール送信ができなくなったけど解決

Mon, 07 Mar 2022 00:00:00 GMT

概要

独自ドメインの転送メールアドレスを無料で行えるように設定しました。

https://blog.teraren.com/posts/google-domains-custom-domain-gmail/

しかしながら、1週間ぐらい経過してからメールを送信したら、以下のようなエラーメールが返ってきてしまいました。

You no longer have access to foo@example.com. To send this email, choose a different "from" address and try again. Learn more at https://support.google.com/mail/answer/22370?hl=

解決方法

gmailのSMTPサーバから別ドメインのメールを送っているのでSPF関連の設定を入稿していないから起きているのかな？と思っていましたが、以下の書き込みでは外部メールアドレスの設定を一度削除して作り直せば使えるようになると書いてありました。

https://www.google.com/search?q=gmail+spf&oq=gmail+spf+&aqs=chrome..69i57.1471j0j1&sourceid=chrome&ie=UTF-8

そんなので直るのかと思っていましたが、実際に作り直したら送信できるようになりました。

設定と確認に10分近くかかるので再発したら面倒だなと思います…。

招待コード

25%オフで利用できる招待コードが届いたのでどうぞ。

Have a friend who hasn’t tried Google Domains yet? New users can enter code FRIENDSOFDOMAINS at checkout for 25% off** a new domain or transfer-in.

郵便番号から住所を補完するコード

Sun, 13 Feb 2022 00:00:00 GMT

概要

Web の申し込みフォームなどで郵便番号を入力すると住所が自動的に補完されるコードを書きます。
無料の郵便番号API ポストくんを使いました。

調査

郵便番号から住所を呼び出すときには以下のような URL で呼び出すだけです。

% curl -s https://postcode.teraren.com/postcodes/1600023.json | jq
{
  "postcode_type": "area",
  "jis": "13104",
  "old": "160",
  "new": "1600023",
  "prefecture_kana": "トウキョウト",
  "city_kana": "シンジュクク",
  "suburb_kana": "ニシシンジュク",
  "prefecture": "東京都",
  "city": "新宿区",
  "suburb": "西新宿",
  "street_address": null,
  "office": null,
  "office_kana": null,
  "post_type": null,
  "is_separated_suburb": 0,
  "is_koaza": 0,
  "is_chome": 1,
  "is_include_area": 0,
  "status": 0,
  "reason": 0,
  "created_at": "2023-02-08T05:10:49.000Z",
  "updated_at": "2023-02-08T05:10:49.000Z"
}

実装

上記を踏まえてコードを書きます。とても簡単です。

HTML

HTML側は郵便番号の入力フォームと、取得したデータを表示する部分を作っておきます。

<form>
  <div>
    <h2>郵便番号入力</h2>
  <input type="text" id="postcode" placeholder="1600023" maxlength="7" autofocus>
  </div>
  <div>
    <h2>住所補完</h2>
  <input type="text" id="prefecture" placeholder="東京都" disabled>
  <input type="text" id="city" placeholder="新宿区" disabled>
  <input type="text" id="suburb" placeholder="西新宿" disabled>
  </div>
</form>

JavaScript(ES6)

キーボードの入力が行われて数字が7桁だったらAPIで問い合わせをしています。

document.addEventListener('keyup', (e) => {
  // 0 - 9 の数字キーでない場合は処理を終了
  if (!(e.keyCode >= 48 && e.keyCode <= 57)) return;

  const postcode = document.getElementById('postcode').value;

  // 郵便番号が7桁でない場合は処理を終了
  if (postcode.length !== 7) return;

  const url = `https://postcode.teraren.com/postcodes/${postcode}.json`;

  fetch(url)
    .then(response => response.json())
    .then(json => {
      document.getElementById('prefecture').value = json.prefecture;
      document.getElementById('city').value = json.city;
      document.getElementById('suburb').value = json.suburb;
    })
    .catch(error => {
      document.getElementById('prefecture').value = '';
      document.getElementById('city').value = '';
      document.getElementById('suburb').value = '';
    });
});

デモはこちら

https://codepen.io/matsubokkuri/pen/XWPrNNw

Google Domainsへ移管して無料でカスタムドメインをGmailで使う

Thu, 10 Feb 2022 00:00:00 GMT

概要

Google Domainsでドメインを管理すれば、無料でGmailをカスタムドメインで利用できるようになるらしいので設定してみました。

https://x.com/twk/status/1484885881760923654

おそらく、これに当たるのかなと思います。custom domainでaliasが作れる感じかなと思います。

料金

今までは、muumuuドメインで管理していました。.comドメインなので料金は以下。過去の履歴を見てみたら、5年前は950円/年でした。2倍近く値上がりしています。
- 1,728円/年
Google Domains
- 1,400円/年

移管

移管はこちらの手順通りに行いました。特につまずくところはないと思います。
- https://support.google.com/domains/answer/3251236?hl=ja&ref_topic=9003137&visit_id=637799892079898736-1406187690&rd=1

muumuuの場合は以下のような画面でAUTH_CODEを取得できました。

移管時に、DNSレコードをGoogleで管理するか聞かれますが、これにはNoと回答する必要があります。設定をインポートすると書いてありますが、今はAWSで管理していてすべてをインポートできるわけではないからです。
ドメインの移管が終わってから、後ほどDNSの設定は行いましょう。

今の所、日本では法人しか対応していないようなメッセージが表示されました。（どうやってそれって確認するのか不明ですが。。。）

課金が完了するとメールが来ます。

その後、しばらく待ちます。移管元の方のレジストラから連絡が来るはずです。

数十分待つと、以下のようなメールが移管元のレジストラから来ますので、承認手続きを進めます。

5分ぐらいすると、移管が完了したメールが移管先のGoogle Domainsから届きます。

移行前のレジストラにあった有効期限はそのまま引き継がれます。

メールのForwardの設定

このあたりを読んで設定します。

https://support.google.com/domains/answer/3251241?hl=en#emailForwarding

まずは、Google Domains側でAliasを設定します。

そして、カスタムドメインのメアドにメールを出して、gmail側で受信できることを確認します。

次に、送信側の設定です。送信側の設定は、普通にGmailからSMTPサーバを追加するだけで良いです。

https://mail.google.com/mail/u/0/#settings/accounts

受信したメールに対して返信してみたところ、うまく返信できました。後日試してみたら、送信できなくなってました。謎。

Reporting機能を有効化

Google DomainsでReporting機能を有効化すると、約1日後からドメインに対する統計情報が閲覧できるようになります。

この統計情報は、Google Search Consoleに新たに1つ特別なプロファイルが作られて、そこから閲覧できるようになります。今まではホスト名単位でプロファイルが切られていましたが、このプロファイルは特殊でドメイン単位の統計が見られます。

まとめ

Google Domainsの「無料メール転送機能」が使えることによって、無料のGmailでカスタムドメインのメールアドレスを送受信できるようになりました。
カスタムドメインでGmailを使いたかったがために、Google Workspaceを契約していましたが解約できます。
ついでにDNS zoneの移行なども行ったのでトータル3時間位かかりました。
Google Domainsを使っているとGoogle Sitesでサイトを作ることをおすすめされますが、相変わらずテンプレが貧素なので時間を無駄にしました。

GoogleのCloud Identityでエンドポイント管理

Thu, 03 Feb 2022 00:00:00 GMT

概要

Googleが2020年1月16日にリリースしたCloud Identityによって社内端末を管理する設定をしました。
事例がほとんど見つからないのでオフィシャルドキュメントを片っ端から読んで設定してみました。
コーポレート関連の情報が全然出回らないので書いておきます。
手順などをちゃんと書くと、文量が大量になるので要点だけまとめます。

Cloud Identity特徴

無料と有料プランがあります
- Google Cloud Identity Free Edition
- Google Cloud Identity Premium Edition

Chrome Bookの端末管理をしたかったので今回はPremium Editionを使う必要があります。
Google WorkspaceのEnterpriseプランだとCloud Identityのサービスが含有されているのですが、それ以外では個別に契約が必要っぽいです。
料金
- 645円/ユーザ/月

セキュリティ要件例

このあたりのことをやれます。

端末の紛失、盗難
- データの削除をリモートから行ったり、容易にログインできなくする。
- ディスクが暗号化された状態を担保する。
認証
- ソーシャルエンジニアリング対策
BYO対策
- 個人端末で会社アカウントを使っている場合の管理。
- 業務委託の端末管理。
- Google Workspaceのアカウントを使ってログインしている端末は、Google Device Policyというアプリを別途入れることを共用されます。このアプリ経由で端末を制御できます。

https://support.google.com/a/answer/7582673

こんな感じで有効化できます。

Windows端末の場合は、Google Credential Providerというアプリが用意されていて、Google WorkspaceのIDとPWでWindows端末にログインするように設定できます。

https://tools.google.com/dlpage/gcpw

私の場合は、以下のようなPowerShellスクリプトを書いて、キッティング時に実行して設定してます。

https://gist.github.com/matsubo/97e7d42c7bad1b5f76905c0351f71f87

運用

以下のスクショのような感じでログインしたユーザやデバイスが表示されます。対象のデバイスから強制ログアウトや、リモートから情報の削除を行えます。

デバイスでフィルタをしたりできます。

考察

この設定によって、会社のデバイスやBYODの端末を管理できるようになりました。セキュリティをコントロールしづらいBYODに対してもリモートワイプできるようになりました。
Google Workspacesを導入したスタートアップには良いと思います。Android, ios, Windows, macosにおける最低限の認証管理、設定管理は行なえます。
もっと細かい制御をしたい場合は、JAMFやIntuneなどを使って強化していけばよいかと思います。

ABM連携もできるようなので、今後トライしたいです。
https://support.google.com/a/answer/9904735?hl=ja

::amazon{asin="4798063193"}

自宅サーバ環境

Thu, 03 Feb 2022 00:00:00 GMT

ハードウェア

PowerEdge T320を2019年12月に中古で26,000円で買いました。製造日は2013年とか2014年かと思います。

CPU: 8コア Xeon E5-2450 2.1GHz

RAM: 16GB

HDD: 2TB x 4

(RAID1)

SSD: 500GB x 2 (RAID1)

OS

Ubuntu 22.04（基本的に最新を入れていくようにしています）

コアは16個あるので一人で利用する分には並列性は十分です。

アプリケーション

Dockerを入れて様々なWebサービスを運用しています。
ユーザが多いサービスは安定性を重視するためにAWS Lightsailの方へ移行しています。

UPS

停電のときにRAIDコントローラーを保護したいという目的でUPSを導入しました。
最悪、長期の停電になったときにUPSの電池から充電をできたりするという用途にもなります。
あと、使っている電力がわかるので電気代算出の目安になります。

::amazon{asin="B06XHZ3K5T"}

有効期限付きポイントシステムの要求定義と設計

Thu, 03 Feb 2022 00:00:00 GMT

概要

15年前ぐらいに設計、実装したシステムの設計と実装を公開します。
目的は、誰かに特許を取られてしまっても困るので。自分で特許を取るほどでもないので共有資産として残しておきます。特許というか、どちらかと言うと論文で発表するほうが向いていそうです。
航空会社のマイルで使われているポイント管理機能の実現方法です。このようなポイントシステムの要求はビジネスサイドではよくありそうですが、設計内容が公開されている事例を見つけられませんでした。

類似ポイントシステム

JALやANAのマイルシステム
- まさにこれと同じ機能の実現方法です。
- 設計と実装が比較的難しいので、当時はこの機能を実現しているサービスは見つけられませんでした。
- 2022年の今となってはこのポイントの仕組みはメジャーになりつつあります。様々な大手ポイントサイトで使われています。設計と実装の難易度が高かかったり、ユースケースが限られていたりするので中小規模のところでは採用されていないです。
ビックカメラやヨドバシカメラのポイントシステム
- 最終利用日から1年で有効期限が切れる。
- この仕組の実装は簡単なのであちこちで採用されています。
「有効期限つき」ポイントシステムをつくる
- この記事で紹介されている設計では、「ポイントの消費を取り消す」ユースケースを処理できません。

要求

アクター

ユーザ
経理
システム管理者

機能要求

基本機能
- ユーザに対してポイントを加算、減算できるシステム。
- 加算に対して、任意の有効期限をつける。
- 有効期限が近いポイントから消費していく。
運用
- 減算を取り消すときには、減算前のポイントの有効期限を復元する。
- ある時点の残高を算出できる。
- ポイントの整合性をチェックできる。
ユーザ向け機能
- 有効期限ごとに残高を表示できる。
- 現在の残高を取得できる。
経理
- できるだけオンラインで処理できるようにする
- 特定時点のBS（バランスシート）の算出
- 特定時点のPL（プロフィット/ロス）の算出
- BSとPLの一致
システム
- 長期間運用しても遅くならないクエリーで取り出せる。
- 減算、加算の整合性を検算できる。（＝BSとPLを作っておいて、整合性を検証）

ユースケースの例

2022年6月まで有効の100ポイントを加算
2022年7月まで有効の100ポイントを加算
150ポイントを消費。（1から100ポイント、2から50ポイントを引く）

アプローチ

いくつか設計のアプローチがあるので整理します。どのような特徴に注目して設計するかによっていくつかのアプローチがあります。それぞれの設計とメリット、デメリットをまとめておきます。

トランザクションモデル
1. 入金と出金の処理のトリガーはPLなので、必要最低限のPLを保存する。
会計的アプローチ
1. PLとBS (有効期限ごと)を分離して保存する。
オブジェクト指向
1. 入金、出金をオブジェクトとして考える。
2. 入金、出金、1つ1つがオブジェクトとなる。

1. トランザクションモデル

方向性は、入金と出金の履歴は最低限取らなければいけないのでそれぞれの履歴をエンティティとして表現します。

Userエンティティは、ユーザ情報のマスタです。

DepositHistoryは入金の履歴を表現するエンティティです。amountにはポイントの額を入れます。used_amountはその入金に対して利用済みの金額を保存するためのカラムです。デフォルトは0になります。 expiration_dateはその入金の有効期限の日付を入力します。

WithdrawHistoryは出金の履歴を表現するエンティティです。

入金と出金を1つのエンティティで表現しても良かったのですが、used_amountとexpiration_dateの2つのアトリビュートが出金には非従属なので正規化してエンティティで分けました。

このアプローチの良い点は、テーブルが2つで済むのでシンプルです。悪い点は、出金と入金の紐付けが行えないので出金の取り消しができません。

2. 会計的アプローチ

PLとBS (有効期限ごと)を分離して保存する。ユーザや管理者が見たいのは主にPLかBLのどちらかです。なので、ユーザ側の要求に近い状態でデータ自体も保存してしまえば集計も楽というアプローチです。

良い点は集計が容易です。悪い点は、1つ目と同じように入金と出金の紐付けがないので出金の取り消しが行なえません。

3. オブジェクト指向

入金、出金を個別に扱います。入金に対しての出金を厳密に関連付けることで取り消しを行えるようにします。

データとしてはPLを持ちます。BSはこのPLのデータを使って集計して出すか、参照頻度が高いのであれば別途BS用のテーブルを用意しても良いと思います。

BS用のテーブルを用意すると、集計は行いやすいですがその反面、PLの更新があるたびにBSのテーブルの更新も行う必要が出てきます。システムのユースケース頻度やトラフィックの多さによって使い分けるのが良いと思います。

この手法の良い点は、出金の取り消しも容易に行なえます。悪い点はテーブルが3つになるのでデータの管理が煩雑です。出金時のクエリーを複数回発行する必要があり、計算量が収束しないので処理が遅くなる可能性があります。

メリット・デメリット

Matrixで整理しておきます。

アプローチ1

アプローチ2

アプローチ3

有効残高算出

減算・加算の時系列一覧

△ O(2n)

残高の計算量

O(n)

O(1)

O(n)

とある時点のスナップショット計算量

O(n)

O(log(n))

BSとPLの検算

減算の取り消し

時間を指定したBSの出力

期間を指定したPLの出力

nはとあるユーザに対する関連するテーブルのレコード数

採用する手法

3番を採用します。

実装

実装の方向性
- 各エンティティにまたがった排他制御が必要なのでRDBMSで実装するのが一般的かと思います。
- 行ロックはデッドロックを回避するために左側のエンティティから順番にかけていくように実装します。

加算

Depositにレコードを入れるだけ。

残高の表示

Depositから有効期限が未来のレコードを抽出し、DepoistWithdraw.amountのsum()を除算

減算

トランザクション
- 残高をチェック。
- Depositから有効期限に近い順にソート
- 影響のあるDepositを排他ロック
- Withdrawへレコードの追加
- DepositWithdrawへレコードの追加

減算取り消し

トランザクション
- 関連するDepositWithdrawを排他ロック
- Withdrawの削除
- 関連するDepositWithdrawの削除

一覧

加算と減算を別のテーブルで管理しているので加算と減算の一覧を時系列に出す処理が重くなってしまいます。計算量、メモリ使用量がO(n)です。

このシステムの設計における一番大きなデメリットがこの点。

DepositとWithdrawをUNION ALLして時間でソートする。
- 上記の処理は重いのでユースケースレベルで加算と減算それぞれのページを用意する事によってパフォーマンスは担保できる。

ユーザの削除

PLを簡単に出すために、退会したユーザに対しては減算処理をして残高を0にしておく必要がある。そうでないと、BSを出すときに退会ユーザを除外するのが難しくなる。現時点でのBSを出すのは簡単だが、過去のとある時点のBSを出す際にはクエリーが不可能ではないが困難になる。

ポイントの失効

BSを計算する際に、expiration_dateを元に算出することになる。有効期限が切れたポイントに関連するPLを算出するのはクエリーが複雑になる。
考察
- PLを集計しやすいように、ポイントが失効したら減算するレコードを入れるバッチを作っても良いが、実行タイミングは失効と同時に行う必要があるので実行が困難。

検算

BSのスナップショットは持っていないので、PLの整合性を検証するのみになります。PLを複数テーブルで管理しているのでその整合性を確認します。

{/* textlint-disable ja-technical-writing/no-unmatched-pair */}

“OK” if sum(DepositWithdraw.amount) == sum(Withdraw.amount)
“OK” if Deposit.amount => sum(DepositWithdraw.amount) {/* textlint-enable ja-technical-writing/no-unmatched-pair */}

実装が正しく動いているか確認するための保険としてdailyで上記のバッチを実行しておくのが良いです。

考察

この設計で今までに2つのサービスを構築しましたが不整合無く稼働しています。
運用を開始してから、ビジネスサイドやファイナンスサイドからの要求に対しても基本的には答えられています。
監査、経理、マーケティング用途の集計要求にも答えられています。（設計が少し複雑なのでエンジニアかデータに詳しい人じゃないと複雑な抽出クエリーを書けないという問題はあります）

::amazon{asin="B07D25W3HF"}

slackのステータスアイコンを自動で更新（家かオフィスかをアイコンで表示）

Thu, 03 Feb 2022 00:00:00 GMT

概要

以下のように、自分がどこにいるのかを自動的にSlackのアイコンに表示する方法を紹介します。
2年前（2020年）ぐらいに設定した内容なのでちょっと古いところがあるかもです。

slack-wifi-status

じゃあ、どうやってステータスを変えるのかと言うと、以下のようなロジックです。

wifiのSSIDが変更されたときのイベントをhookする
SSIDとアイコンの定義を予め用意しておいて、それを元にSlackのAPIを使ってアイコンを変更する。

以下のバイナリをダウンロードします。このバイナリファイルをデーモンとして稼働させてWiFi APの変更を検知してアイコンを変更することになります。

https://github.com/polidog/slack-wifi-status

設定ファイルを以下のような感じで書きます。slackのtokenの項目にはユーザトークンを入れます。

% cat ~/.slack-wifi-status.toml

[slack]
token = "xoxp-xxxxx-xxxxx-xxxxxxx-xxxxxxxxxxxx"

[wifi]
  [[wifi.list]]
  name = "office-wifi-ap"
  message = "at office"
  emoji = ":office:"

  [[wifi.list]]
  name = "office-guest-wifi-ap"
  message = "at office"
  emoji = ":office:"

  [[wifi.list]]
  name = "my-home-ssid"
  message = "at home"
  emoji = ":house:"

  [[wifi.list]]
  name = "starbucks"
  message = "at starbucks"
  emoji = ":comet:"

/Users/matsu/Documents/slack-wifi-status_darwin_amd64/ にバイナリを保存した前提のplistファイル

% cat Library/LaunchAgents/slack-wifi-status.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
 <dict>
  <key>Label</key>
  <string>com.slack.slack-wifi-status</string>
  <key>ProgramArguments</key>
  <array>
     <string>/Users/matsu/Documents/slack-wifi-status_darwin_amd64/slack-wifi-status</string>
  </array>
  <key>StandardOutPath</key>
  <string>/var/tmp/slack-wifi-status.log</string>
  <key>RunAtLoad</key>
  <true/>
 </dict>
</plist>

以下のコマンドで、デーモンとして登録します。

% cd Library/LaunchAgents
% launchctl load slack-wifi-status.plist
% launchctl start slack-wifi-status.plist

まとめ

自分のためと言うより、一緒に働いている人に対して自分がどこにいるのかを自動的に表現できる仕組みです。

Toonesの残高をチェックして少なかったらSlackへアラート

Wed, 12 Jan 2022 00:00:00 GMT

インターネットFAXのToonesにある残高が減った時に検知する手段が無かったのでスクレイピングしてSlackに通知するようにしました。mechanize gemを使えば、結構簡単に書けます。

ヘッドレスブラウザを使うと大げさすぎるし、http clientだと低機能すぎるのでmechanizeはちょうどよい具合でした。

アラートの通知は以下のような感じです。

ソースコード

スクレイピングでエラーが起きたときに、検知できないと辛いのでエラーが起きたらSlackに通知しています。
Mechanizeは便利です。

RSA Encryption not supported - caching_sha2_password plugin was built with GnuTLS support がでたときの対処法

Sat, 18 Dec 2021 00:00:00 GMT

原因

MySQL5.7までの認証プラグインにはmysql_native_passwordがデフォルトで使用されていましたがMySQL8より新たに追加されたcacing_sha2_passwordがデフォルトに変更されましたがクライアント側が対応していないため。

解決法1

docker-compose.ymlに以下の行を追加すればOKです。すでに構築済みでも大丈夫です。

command: --default-authentication-plugin=mysql_native_password

解決法2

DBのレコードを書き換える方法です。DB内に入っている値を書き換えるので、一時的な解決方法です。

以下の実行例はdocker-composeで立ち上げている場合

$ docker exec -it <repository_name>-db-1 bash

passwordの部分は任意の文字列に置き換えてください。

# mysql -u root -p
> ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY 'password';
> ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password'
> flush privileges;

発生するタイミング

初期セットアップ時。
MySQLのDocker Imageのバージョンを上げたり（あがってしまったり）するとDBのユーザデータが初期化される場合がある様子。

Ubuntu 20.04.2 LTSにWiFiドングルを設定

Fri, 12 Nov 2021 00:00:00 GMT

こちらを買いました。Linuxで使えるようにするための設定があまり書かれていなかったのでメモ書きを残しておきます。Ubuntu 21でも同様です。

::amazon{asin="B07MXHJ6KB"}

チップセットを調べる

matsu@lenovo:~/$ lspci |grep net
08:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0e)
matsu@lenovo:~/$ sudo lshw -c network
  *-network
       description: Ethernet interface
       product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:08:00.0
       logical name: eno1
       version: 0e
       serial: 1c:69:7a:4d:00:26
       size: 1Gbit/s
       capacity: 1Gbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 duplex=full ip=192.168.1.27 latency=0 link=yes multicast=yes port=MII speed=1Gbit/s
       resources: irq:30 ioport:f000(size=256) memory:fcd04000-fcd04fff memory:fcd00000-fcd03fff

ドライバをインストール

% git clone https://github.com/aircrack-ng/rtl8812au.git
% cd rtl8812au/
% sudo apt install dkms

matsu@lenovo:~/rtl8812au$ sudo make dkms_install
mkdir -p /usr/src/8812au-5.6.4.2_35491.20191025
cp -r * /usr/src/8812au-5.6.4.2_35491.20191025
dkms add -m 8812au -v 5.6.4.2_35491.20191025

Creating symlink /var/lib/dkms/8812au/5.6.4.2_35491.20191025/source ->
                 /usr/src/8812au-5.6.4.2_35491.20191025

DKMS: add completed.
dkms build -m 8812au -v 5.6.4.2_35491.20191025

Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area...
'make' -j8 KVER=5.4.0-90-generic KSRC=/lib/modules/5.4.0-90-generic/build.............
Signing module:
Generating a new Secure Boot signing key:
Can't load /var/lib/shim-signed/mok/.rnd into RNG
139750728316224:error:2406F079:random number generator:RAND_load_file:Cannot open file:../crypto/rand/randfile.c:98:Filename=/var/lib/shim-signed/mok/.rnd
Generating a RSA private key
.................+++++
......................+++++
writing new private key to '/var/lib/shim-signed/mok/MOK.priv'
-----
 - /var/lib/dkms/8812au/5.6.4.2_35491.20191025/5.4.0-90-generic/x86_64/module/88XXau.ko
Secure Boot not enabled on this system.
cleaning build area...

DKMS: build completed.
dkms install -m 8812au -v 5.6.4.2_35491.20191025

88XXau.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.4.0-90-generic/updates/dkms/

depmod.......

DKMS: install completed.
dkms status
8812au, 5.6.4.2_35491.20191025, 5.4.0-90-generic, x86_64: installed

dkmsで入れたドライバを確認

root@lenovo:/home/matsu/rtl8812au# dkms status
8812au, 5.6.4.2_35491.20191025, 5.4.0-90-generic, x86_64: installed

USBデバイスを抜いて、挿すとこんな感じのメッセージが出てwlan0に割当されました。

% dmesg
[ 2098.449336] usb 1-3: USB disconnect, device number 5
[ 2101.243660] usb 1-3: new high-speed USB device number 6 using xhci_hcd
[ 2101.418090] usb 1-3: New USB device found, idVendor=2357, idProduct=011e, bcdDevice= 2.00
[ 2101.418095] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2101.418098] usb 1-3: Product: 802.11ac WLAN Adapter
[ 2101.418100] usb 1-3: Manufacturer: Realtek
[ 2101.418101] usb 1-3: SerialNumber: 00e04c000001
[ 2101.493015] 88XXau: loading out-of-tree module taints kernel.
[ 2101.493536] 88XXau: module verification failed: signature and/or required key missing - tainting kernel
[ 2105.586166] usb 1-3: 88XXau 10:27:f5:09:2e:f7 hw_info[107]
[ 2105.631758] usbcore: registered new interface driver rtl88XXau
[ 2105.671189] rtl88XXau 1-3:1.0 wlx1027f5092ef7: renamed from wlan0
[ 2113.636088] IPv6: ADDRCONF(NETDEV_CHANGE): wlx1027f5092ef7: link becomes ready

nmcliから見られるようになりました。

root@lenovo:/home/matsu/rtl8812au# nmcli
wlx1027f5092ef7: disconnected
        "TP-Link Wi-Fi"
        wifi (rtl88XXau), 10:27:F5:09:2E:F7, hw, mtu 2312

nmtuiなどで設定して、activateします

ip aコマンドで見るとつながっていることがわかります

7: wlx1027f5092ef7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2312 qdisc mq state UP group default qlen 1000
    link/ether 10:27:f5:09:2e:f7 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.114/24 brd 192.168.1.255 scope global dynamic noprefixroute wlx1027f5092ef7
       valid_lft 3552sec preferred_lft 3552sec
    inet6 240f:78:8153:1::2/128 scope global dynamic noprefixroute
       valid_lft 3555sec preferred_lft 1755sec
    inet6 240f:78:8153:1:8f:8b35:3766:78df/64 scope global temporary dynamic
       valid_lft 288sec preferred_lft 288sec
    inet6 240f:78:8153:1:7c53:4137:36ac:2635/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 288sec preferred_lft 288sec
    inet6 fe80::b191:e8c0:2c47:7f85/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

Ubuntu 21.10で複数NICを1つのネットワークに繋げる設定

Fri, 05 Nov 2021 00:00:00 GMT

Ubuntu 20系よりroute周りの設定を細かく書かないとエラーになってしまうので以下のように修正。

** (generate:289522): WARNING **: 01:36:28.530: `gateway4` has been deprecated, use default routes instead.
See the 'Default routes' section of the documentation for more details.

内容はgateway4というセクションがDeprecatedになったのでroutesに定義してね。と。

今まではgateway4にデフォルトゲートウェイのアドレスを記載するだけでしたが、metricなどを記載する必要があります。まぁ、routeテーブルをより明確に書き換えるための詳細化です。

ということで、以下のような感じで記載しました。metricは低いほうが高プライオリティ。

それでもまだ、ちょっとネットワークを切断、接続したときのrouteテーブルの書き換えが変になる動作があるので運用には要注意という感じです。

L2までが安定していて変化がなければ気にしないで良いと思います。

Ubuntu 21.10にアップグレードしましたが2つ問題が発生

Wed, 27 Oct 2021 00:00:00 GMT

処理自体は簡単です。今までと同じようにUbuntuの場合は以下のコマンドだけでアップグレードできます。

$ sudo apt update
$ sudo apt upgrade
$ sudo do-release-upgrade

アップグレードは正常に終了。

この後は、rebootしてちゃんと起動することを確認すれば作業が終了します。

しかしながら、問題はこのあと起きます。

問題1

なぜかrebootしたあとにはX-window systemが一通り入っていて、runlevelが上がってしまいました。サーバー用途のためCUIしか使っていないので不要です。。。謎すぎます。

なので、runlevelを落とします。Ubuntuは以下のコマンドでCUIになります。

$ sudo systemctl set-default multi-user.target

それに伴って、X Window system関連のパッケージを削除します。以下のコマンドで削除できると書いてありますが、Gnome関連などのGUIアプリは依存関係がないらしくて消えません。

$ sudo apt-get remove xserver-xorg-core
$ sudo apt-get autoremove -y

aptitudeをわざわざインストールしてそれっぽいパッケージを抜いていきます。そして、再起動しました。

追記

別のほとんど追加パッケージを入れていないUbuntu 20 ServerにてUbuntu21へのアップグレードを試したら、この問題は起きませんでした。おそらくなにかのパッケージの依存関係が変わってしまったのだろうと予想します。

問題1が発生しなければ問題2も発生しないです。

問題2

今度は別の問題が発生しました。起動中に、ディスクが見つからないと言うエラーがでました。対処法はWeb上では様々な方法がでてきます。

Gave up waiting for root device. Common problems:

https://kudzu.hatenablog.com/entry/20151102/1446416115

結局は、lvm2のパッケージが消えたことが原因でした。

Grubの選択肢のときにeを押してブート方法を選ぶページに行って、1つ前に入れたkernelを選択して起動。（recovery modeではない）

それでも同様に起動はしませんが、kernelは動くのでshellが動くのと/sbinなどには管理ツールが充実しています。

いろいろ調べていると、lvmのパッケージが依存関係で消えてしまうことがあるらしいので、lvmのパッケージを入れ直せば運が良ければ起動するとのことだったのでインストールして対処します。

確かに、lvm関連のコマンドが一切存在していませんでしたが、このインストール後には利用できるようになりました。どこの領域にインストールされているのか謎なのは依然として残りますが。。。lvmをマウントできていないから/sbinや/usr/sbinとかにアクセスできないはずなのに。。。

# apt update
# apt install lvm2

このあと、再起動をしたらちゃんと起動しました。

考察

/var/log/dpkg.log を漁ってみましたが、lvm2が消えたログが見当たりませんでした。

色々謎は残りますが復帰できてよかったです。

Rails + MySQL 8でngramを用いたfulltext index

Tue, 19 Oct 2021 00:00:00 GMT

Railsのmigrationで普通にfulltext indexを付ける場合には以下のようにすると思いますが、普通のfulltext indexではngramが使われないので日本語の全文検索をする場合には全然マッチしません。

class AddNormalFullText < ActiveRecord::Migration[6.1]
  def change
    add_index :corporations, :name, :type => :fulltext
  end
end

ngramのindexをつけるためには以下のように手でmigrationの内容を書く感じです。"ft_index"は自分でつけるindexの名称なので適当に付けてOK。

class AddNgramFullText < ActiveRecord::Migration[6.1]
  def up
    execute 'CREATE FULLTEXT INDEX ft_index ON corporations  (name) WITH PARSER ngram'
  end
  def down
    execute 'ALTER TABLE corporations DROP INDEX ft_index'
  end
end

show create tableをすれば、以下のようなindexが作られることが確認できます。

FULLTEXT KEY `ft_index` (`name`) /*!50100 WITH PARSER `ngram` */

MySQL 5.7系でも同じだと思います。

パフォーマンスはなんか、いまいちです。平均約10文字のカラムに対して500万レコードを対象にindexを張りました。2件を抽出するために3秒位かかりました。

別の語句で試したら0.5秒以内には返ってきたりします。

ngram周りのパラメータはデフォルトです。

ミラーサーバの取りやめの連絡

Tue, 05 Oct 2021 00:00:00 GMT

以下の2サイトを停止致します。

ミラー元のサービスが停止したことにより、テラレン！でのミラーリングを終了致します。

mirrors.teraren.com

※ 元の「dotdebのミラーリングを開始」記事は削除済み

SHARP ヘルシオホットクックがWi-Fiにつながらない問題を解決

Sun, 26 Sep 2021 00:00:00 GMT

ホットクックの型番はKN-HW24F

::amazon{asin="B08JYHRFR4"}

WPSボタン経由、COCORO HOMEアプリ経由でも何回頑張っても接続できなかったです。

使っているWiFiアクセスポイントは、こちら。

TP-Link WiFi ルーター WiFi6 PS5 対応無線LAN 11ax AX5400 4804 Mbps (5 GHz) + 574 Mbps (2.4 GHz) OneMesh対応メーカー保証３年 Archer AX73/A

::amazon{asin="B08RDHHS6Z"}

ちなみにWebで書かれている以下の確認ポイントはもちろん全部クリア済み。

2.4GHz帯 WPA2
ホットクック側のWiFi設定削除
アプリの削除、インストール

WiFiアクセスポイントのもともとの設定はこちらです。セキュリティ重視の一番安全な設定です。

ホットクックのような日本のメーカーが作るIoT機器は載っている計算リソースやハードウェアが最低限だろうから、対応しているWiFiの暗号化セットが古いものしか対応していないだろうという仮説のもと、WiFiアクセスポイントの対応暗号化のレベルを下げました。

WiFiアクセスポイント上で以下のように暗号化設定を変更して、WPSボタンを使って接続をしたらあっさりと１回目で接続できました。

WPA2系の暗号化の場合は接続できなく、WPA系の暗号化では接続できるようになりました。ホットクックはWPA2には非対応のようです。

その後

何度やってもWiFiが繋がらなかったので無線LANに接続しないで利用しようかとも考えていましたが、頑張ってWiFiを繋げてよかったです。

COCOROアプリ上でレシピを検索して、そのレシピを使うためにアプリ上からボタン1発でホットクックへそのレシピに必要なメニューを追加できるようになるのが便利です。

また、調理が完了したらアプリ上に通知が来るようになります。（これは別に不要だったのでオフにしました）

このBlogのホスティングを自宅サーバからLightsailに移行しました

Tue, 31 Aug 2021 00:00:00 GMT

背景

自宅サーバで運用していましたが、Raidカードが壊れてOSが起動できなくなってしまいました。
調達にも時間がかかるので、取り急ぎデータをサルベージしてどこかで動かす必要がありました。
Lightsailが安いのでこの際に移行してしまいます。

選んだインスタンス

Disk容量が足りなくて一番低い3.5USD/monthのインスタンスでは乗り切りませんでした。それでも月5ドルは安いです。

https://aws.amazon.com/jp/lightsail/pricing/

理想は、ACMやらロードバランサを付けておきたいのですがそれらをつけるとコストが普通に高くなってしまうのでこのインスタンスだけでなんとか運用します。定期スナップショットも取れるし自宅よりインフラ面（電源、回線、ハードウェアなど）が安定しているので安全です。

WordPressでできたBlogを10個ぐらい乗せるのでOSはAmazon Linux 2を使ってゼロからセットアップします。（WordPressのインスタンスから作ると余計なものが色々入ってきてしまうので）

コストがかからないことを最優先にするのでMySQLも同居させます。

ついでに、PHP8にも移行しました。WordPressのテーマやプラグインで最近の更新が止まっているものはエラーが出てしまっているので、綺麗サッパリ消して諦めました。主要なプラグインやテーマはPHP8に基本的に対応しています。

もちろんIPv6対応です。

SSL/TLS対応はLet's Encryptを手動でセットアップしました。

1ヶ月ほど運用した結果

WordPressで運用している記事数が数万件のサービスは乗せられそうにありませんでした。MySQLのDisk I/Oがボトルネックになりました。

プロセスレベルのリソースはこんな感じ。WordPressのComet Cacheを使っているので基本的にはスカスカです。

lightsailを運用する上で気をつけないといけないことは、burstを使い切ってしまうと超遅くなってしまうことです。現時点ではあんまり問題無さそうです。日中がちょっと負荷が上がっている時間がありますが、まだ気にしないで良いかなと思います。

ベンチマーク

なんか遅いけど。同じregionのlightsailインスタンスから行って居て、Average: 0.1203 secs。Comet cacheでは、0.00320secでserveしてるっぽいんだけどね。

静的ファイルに対してのベンチマークでは、約100倍ほど速いAverage: 0.0018 secsでした。OSのリソースの使用状況を見ているとPHPとnginxのCPUオーバーヘッドが大きいような感じがしています。

Comet Cacheが効いていないのかと思って、外してみたらAverage: 3.8090 secsとなりとても遅くなりました。Comet Cacheは効いているようです。

まとめ

EC2だと個人Blogを運用するにはコストがちょっと気になりますが、Lightsailだと月$5で運用できます。もっとトラフィックや容量が少なければ$3.5/月でも十分です。
余談ですが、郵便番号検索サービスのほうもLightsailに移行しました。$3.5/monthで運用しています。記事は後日。
自宅サーバーはファイルサーバとしてメインで使い、ディスクIOや容量を使うサービスは自宅サーバで運用します。

Amazon Linux 2, Amazon Linux 2023のTimezone変更

Fri, 30 Jul 2021 00:00:00 GMT

概要

Amazon Linux 2 で Timezone を変更する方法を記載しておきます。

設定

現在が UTC で表示されているかを確認します。

[root@ip-10-0-0-141 ssm-user]# date
Fri Jul 29 15:18:56 UTC 2021

timedatedctlコマンド経由で変更します。

[root@ip-10-0-0-141 ssm-user]# timedatectl set-timezone Asia/Tokyo

crondに対しても変更を反映するために再起動しておきます。

[root@ip-10-0-0-141 ssm-user]# systemctl restart crond.service

JSTで表示されるかを確認します。

[root@ip-10-0-0-141 ssm-user]# date
Fri Jul 30 00:20:56 JST 2021

補足

/etc/sysconfig/clock ファイルは存在していないようです。

[root@ip-10-0-0-141 ssm-user]# cat /etc/sysconfig/clock
cat: /etc/sysconfig/clock: No such file or directory

Amazon Linux 2のTimezone変更

Thu, 29 Jul 2021 00:00:00 GMT

概要

Amazon Linux 2 で Timezone を変更する方法を記載しておきます。

設定

現在が UTC で表示されているかを確認します。

[root@ip-10-0-0-141 ssm-user]# date
Fri Jul 29 15:18:56 UTC 2021

timedatedctlコマンド経由で変更します。

[root@ip-10-0-0-141 ssm-user]# timedatectl set-timezone Asia/Tokyo

crondに対しても変更を反映するために再起動しておきます。

[root@ip-10-0-0-141 ssm-user]# systemctl restart crond.service

JSTで表示されるかを確認します。

[root@ip-10-0-0-141 ssm-user]# date
Fri Jul 30 00:20:56 JST 2021

補足

/etc/sysconfig/clock ファイルは存在していないようです。

[root@ip-10-0-0-141 ssm-user]# cat /etc/sysconfig/clock
cat: /etc/sysconfig/clock: No such file or directory

Embody Chairのキャスター交換で8,000円節約 | 汎用品で代替可能

Fri, 16 Jul 2021 00:00:00 GMT

最近、椅子の近くにプラスチックの破片が落ちていたので、椅子のどこかが崩壊しているのかと思っていました。3日目にやっと破損箇所を発見しました。

なんと、Embody Chair（Herman Miller製のエルゴノミクスチェア）のキャスター部分が崩壊してきています。

この記事について

学べること

Embody Chairのキャスター破損の状況と原因
純正品と汎用品のコスト比較
Amazonで購入できる代替キャスターの選び方
キャスター交換の簡単な手順

想定読者

Embody Chairのキャスターが破損して困っている方
純正品より安価にキャスター交換したい方
高級チェアのメンテナンスに興味がある方

前提条件

特別な工具は不要（引き抜くだけで交換可能）
推定所要時間: 5分

問題の発見

キャスターのプラスチック部分が経年劣化で崩壊してきています。

コスト比較

Herman Miller公式サイトでキャスターの価格を確認したところ、1個あたり約2,000円です。

選択肢	価格	メリット	デメリット
純正キャスター	10,000円（2,000円×5個）	動作保証、色合い一致	高価
汎用キャスター	2,000円前後（5個セット）	大幅なコスト削減	色合い・サイズが若干異なる可能性

5個交換すると10,000円になってしまうため、汎用品で代替できないか検討します。また、10年後に再び壊れることを考えると、コストパフォーマンスの良い選択肢を探したいところです。

汎用キャスターの選定

よく見ると、このキャスターは汎用品のようなので、Amazonで類似品を探すことにしました。

選定ポイント:

フローリングで使用するため、傷つきにくいゴムタイプを選択
差込式（11mm穴径）に対応していること
車輪直径は純正品に近いサイズ

::amazon{asin="B08TCCNFWZ"}

交換作業

キャスター比較

翌日、購入したキャスターが届いたので、純正品と比較してみます。

気づいた点:

汎用品（右）は純正品より一回り大きい
色合いが純正品（黒）に対して、汎用品はグレーで若干異なる
ダブルホイール（2輪）タイプを選択

交換手順

キャスターの交換は非常に簡単です。

椅子を横にして、古いキャスターを引き抜く
新しいキャスターを差し込む
5個すべて交換する

所要時間: 約5分

交換後の様子

全てのキャスターを交換しました。

色の違いは想定よりも目立ちます。真っ黒ではなく、グレーがかった色合いです。

考察

ダブルホイール vs シングルホイール

今回はダブルホイール（2輪）タイプを選びましたが、これにはいくつか理由があります。

ダブルホイールを選んだ理由:

体重が2つのタイヤに分散されるため、破損リスクが低い
安定性が高い

シングルホイール（1輪）の選択肢:

デザイン性の高い製品が多い
より一般的で選択肢が豊富
Embody Chairのスタイルには合うかもしれない

どちらを選ぶかは、耐久性重視かデザイン重視かで判断すると良いでしょう。

まとめ

コスト削減: 純正品10,000円 → 汎用品2,000円で8,000円の節約
所要時間: 約5分（工具不要）
動作: 問題なく使用可能、静音性も良好
注意点: 色合いが純正品と異なる（気になる場合は純正品推奨）
耐久性: 今後の使用で検証予定

汎用品でも十分に代替可能です。コストパフォーマンスを重視する方にはおすすめの選択肢です。

rsync over sshをAWS Session manager経由で使う設定方法

Fri, 16 Jul 2021 00:00:00 GMT

要件

AWS Systems Manager Session Manager （以降AWS Session Manager）経由でEC2インスタンスにログインする。
AWS Session Manager経由でログインするとssm-userでログインされてしまうが、IAMごとに別のユーザでログインする。
rsync over sshできる。

前提となる環境

AWS Session Managerがセットアップ済み
利用するregionにおいて、 Enable Run As support for Linux instances にチェックが入っている
- https://ap-northeast-1.console.aws.amazon.com/systems-manager/session-manager/preferences

AWS上でのIAM設定

policyを作成する。
- policyレベルでユーザを指定したい場合は、TagsにSSMSessionRunAsを追加してValueにユーザ名を指定する。

特定のインスタンスにSession Manager経由でログインできるようにする例

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "ssm:StartSession",
            "Resource": [
                "arn:aws:ssm:*:*:document/AWS-StartSSHSession",
                "arn:aws:ec2:ap-northeast-1:*:instance/i-xxxxxxxxxxxxxxxx"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "ssm:DescribeSessions",
                "ssm:GetConnectionStatus",
                "ssm:DescribeInstanceProperties",
                "ssm:DescribeInstanceInformation",
                "ec2:DescribeInstances"
            ],
            "Resource": "*"
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "ssm:TerminateSession",
            "Resource": "arn:aws:ssm:*:*:session/${aws:username}-*"
        }
    ]
}

個人のIAMアカウントを作成する
- 上で作ったpolicyをattachする。
- IAMユーザレベルでshellアカウントを指定する場合は**SSMSessionRunAs**タグを設定して、値にログインさせたいsshアカウントを指定する

ログイン先端末での設定

公開鍵をログインしたいホスト上のログインさせたいユーザのauthorized_keysに登録しておく。

ログイン元端末での設定

必須プログラム
- aws-cli
- aws session manager plugin
aws configure などを使ってcredentialを設定ファイルに記述しておく
AWS Session managerを使ってi-xxxxxxxxxxxxxxxxにssh接続テストしてみる
- aws ssm start-session --target i-xxxxxxxxxxxxxxxx
~/.ssh/config へ以下の設定を追加する
- もし、複数のprofileを使っている場合は AWS_PROFILE 環境変数に設定してsshコマンド経由でも同じawsのcredentialを使うように注意する必要がある。

host i-* mi-*
    ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"

sshコマンドで接続してみる
- ssh username@i-xxxxxxxxxxxxxxxx
- SSMSessionRunAsで設定したユーザ名を指定する必要がある。
rsyncコマンド経由でファイルを転送してみる
- rsync -aruzv -e ssh <source> <username>@i-xxxxxxxxxxxxxxxxx:<destination>

考察

rsyncをする場合はAWS Session Managerの設定と、sshの設定の両方が必要になる。

zipコマンドでmacosのDSStoreやIconファイルを除外して圧縮

Wed, 30 Jun 2021 00:00:00 GMT

zip -r output.zip  directory -x '*/.DS_Store' -x '*Icon*'

Windowsの人が解凍すると「なにこれ？」と毎回聞かれるので。

テレカンするとCPU利用率が高くなる→熱暴走の保護機能が発動している

Fri, 11 Jun 2021 00:00:00 GMT

症状

最近、Google Hangoutなどでテレカンを始めると、CPU利用率が徐々に高まっていき、最終的にはUI操作のレスポンスがすごく遅くなります。
しかも、USB-DACを経由して音声を出力していると、音割れがひどくなります。ヘッドフォンを使っていると問題無いです。

ちなみに、2.4 GHz 8-Core Intel Core i9のMacbook Proです。

考えられる問題

ChromeのWebRTCを使ったときに、処理がおかしくて、どんどん変なCPU処理が増えていく？
- ブラウザを変更しても再現するし、ならないときはある。
- 再起動すると直るような気はする。
- Chromeのメジャーバージョンが上がっても全然解決しない。
熱暴走？
- CPUコアの温度表示は60度程度なのでそんなに熱くないと思う。
- コンパイルなどの重い処理をしているときには特に問題にならない。（結局はこれはテレカンに比べれば短時間だからそこまで発熱しない）
ホコリが溜まっている？
- まだ買って1年しか経っていないし、エアーダスターで掃除したけど改善せず。
- さすがに、ファンが回りまくっているのでエアーダスターを使ったらホコリが結構出てきました。
- 分解すれば色々わかるのでしょうが、保証が効かなくなるので今回は分解はしない。
ハードウェア的におかしい？
- SMCリセット、NVRAMリセットをしたけど解決しない。
- 個人用macbook proでもこの現象は再現するので違う気がする。
電源を左に挿しているから？
- macbook pro 2019年モデルは、左にUSB-Cで給電すると発熱するという報告がある。。。
- 私の場合は、右に挿しても変化が感じられなかった。。。
- kernel_taskプロセスが食っている感じはしない。
外部モニタを使っていて、GPU起因？
- 単独で使用すれば多少改善した感じがするけど、外部モニタを使えないのは辛すぎるので、あまりちゃんとトラブルシュートするのは辛い。
クラムシェルで使っているから？
- クラムシェルじゃなくすれば、少しは緩和するような感じはしたけど、すぐにCPU使用率が高まる問題は発生する。

気になる数字を発見

iStat Menuを使ってシステムモニタリングをしています。そこで気づいたのですが、なぜかCPU周波数が1GHz。。。。

CPU温度は低いのに周波数が低いことを見つけました。

OSがハードウェアを熱暴走から保護する機能が働いているような挙動です。

そこで、一応、扇風機でクーリングをした結果、CPUのクロック数が低くならなくなりました。

扇風機で冷やしている様子。見た目はダサいが、これで問題は解決された。背に腹は代えられない。

ということで、こういうのを買えば解決する。

プライムデー前に買うか考え中。→買ったけど、ほんの少し改善したかんじです。根本的に発熱が大きすぎます。

::amazon{asin="B089KCW43Q"}

考察

なかなかトラブルシューティングが大変でしたが、熱暴走ということがわかりました。
iStats menuを使っていない場合は問題に気づけなかった気がします。これから夏にかけて温度が上がっていくのでクロック数は注意したほうが良いです。
今後、問題に気づきやすいように重要数値を確認しやすくしました。

ファンの回転の制御を自動だったのを手動にして最大にしてみました。（左右で最大回転数が違うんですね）

テレカン中には、Chromeの負荷が高くなるのはもちろんのこと、krisp（ノイズキャンセリングをソフトウェアでやるやつ）もそこそこCPUを食うことがわかります。

追記：2021年7月6日

もう、熱問題の原因箇所がわからなすぎで困ってましたが、PCを20cmぐらいの高さから落としてしまったときにホコリの粉がファンの出口からドバっって出てきたからブロワーでは取り切れないホコリがありそうなことがわかりました。

自分で分解するのは怖いのでGenius Barに行ってホコリを除去してもらいました。ホコリは堆積していたみたいですが冷却に影響するほどでは無かったそうです。SMC, PRAMとNVRAMのリセットが勝手に行われている感じはしました。

Apple Storeの人にはクリーンインストールをおすすめされました。

そして、ホコリを除去してもらった後のテレカン時のファン稼働はこちら。

ホコリを除去して貰う前と比較して変化はほとんどありませんでした。

世界中で問題になっている

こちらのスレが一番情報がまとまっていますが、解決方法は無さそうです。。。。

https://www.reddit.com/r/macbookpro/comments/ekh86o/macbook_pro_16_heat_issues_with_external_monitor/

追記: この問題の解決を諦めてM1を買いました

買ったのはこちらのMacBook Pro 14inch M1 Pro

M1では全然熱くなりません！

ファンすら回りません。。。

Amazon Lightsailは初期立ち上げは楽だけど運用が辛い

Mon, 31 May 2021 00:00:00 GMT

概要

2年前ぐらいに Lightsailで立ち上げたWordPressサイトがありました。
アプリケーション、ミドルウェア、OSを一通り最新にしようとしましたが、無理だったのでインスタンスを作り直しました。

背景

ふと確認すると、WordPress本体が最新は5.7.2なのに対して、5.4系でした。
phpも7.2だったので3ヶ月前にサポートが切れてしまっていました。
Ubuntu 16.02 LTS。最新は20なのでメジャーバージョンが2つ低い。

行った手順

WordPress本体、プラグイン、テーマはwpコマンド経由で更新できました。
このあたりの記事を参考に普通にdo-release-upgradeをして、再起動をかけたらsshで繋がらなくなりました。もちろんWebのコンソールも以下のエラーメッセージが出て繋がりません。。。。万事休す。

UPSTREAM_NOT_FOUND [519]

調べてみると、回避手段は、スタートアップスクリプトで、sshを停止して起動するというすごいワークアラウンドを実施する必要が有るらしいです。

bitnamiのページに書いてあるので、bitnamiのアプリケーション周りが怪しい挙動をしているのだと思います。bitnami自体は、OSのバージョンと密接に関連づいているはずなのでこのような不可解な事象が起きるのかと思います。

再度、スナップショットから復元してアップデートをかけるのはとても大変なので諦めて、最新のlightsail wordpressを立てて、wordpressのDB、themeファイル、htdocs以下のコピーを使って復元しました。

まとめ

Lightsailの立ち上げは楽だし、運用は最低なら$3/monthなのでとても良いけど、長期運用をするには辛い。
OSやミドルウェアの最新追随は不可能と考えて、1年か2年おきぐらいにインスタンスの載せ替えをするような運用をする必要がある。

余談

LightsailのDNSはトラフィックが少なければ無料です。大体、1.1request/secなら無料なので殆どの場合はこれでまかなえるような気がします。

Q: Lightsail DNS 管理にかかるコストはどれくらいですか?

Lightsail 内での DNS 管理は無料です。最大 3 つの DNS ゾーンを作成でき、各ゾーンのレコード数は無制限です。また、全ゾーンで 1 か月あたり 300 万 DNS クエリを利用できます。1 か月のクエリ数が最初の 300 万を超えると、0.40 USD/100 万 DNS クエリの料金が適用されます。

https://aws.amazon.com/jp/lightsail/faq/

LightsailのDNSは、動的にLightsailのインスタンスへ向けられるので、Lightsail + LightsailのDNSを使う組み合わせに留めるレベルのシステムなら最適なソリューションです。
- ロードバランサ(18USD/month)を使っていくと値段が普通に高くなっていくのであまりLightsailの魅力が無くなってきます。

郵便番号APIサイトのデータソースをzipcloudに変更

Sun, 25 Apr 2021 00:00:00 GMT

概要

私が運営している郵便番号検索APIサイトにて、今までは、郵便局が提供していたデータを加工して利用していましたが、それでは追いつかないぐらい正規化されていない項目が多いため自分でメンテナンスするより他社がしっかりメンテナンスしているデータを使ったほうがユーザメリットが大きいと判断しました。
このたび、zipcloudが提供するデータに差し替えました。
左が郵便局が提供しているデータ、右がzipcloudが提供しているデータのvimdiffです。

変更点を見てみる

vimdiffで見ていって、目立った変更点をピックアップしてみます。

まず、丁目の表記が消えます。

1行に複数の住所が入っているレコードは、2行に分割されます。しかしながら、当方のサイトでは1つの郵便番号に対して一意の住所を返却したいので1行目の方だけを採用します。

京都府のマスタと呼べないような記述の部分はこのように正規化されます。

もともと1郵便番号に対して複数行でしたが、2倍位の行数に増えています。

不具合ありましたらご連絡願います。

まとめ

差分は大きいですが、郵便番号から住所を求めるというユースケースにおいてはzipcloudのデータのほうが綺麗なので問題無さそうです。

分割されていない電話番号から市外局番と市内局番の求め方

Thu, 15 Apr 2021 00:00:00 GMT

概要

分割されていない電話番号から、市内局番や市外局番を求めたい。
- 0292323011 => 029-232-3011
phonelibが良さそう。
phonelibはGoogle libphonenumberのデータをもとにしている。
日本の市外局番マスタはPDFで提供されていて辛い。。。。
- https://www.soumu.go.jp/main_content/000141817.pdf
- Google libphonenumberはこの内容もちゃんとアップデートされている模様。
- これの悲しいのは、桁数で明確に市内局番が別れていないことです。市内局番が例えば、137と1377が存在します。なので、最長一致でマッチングする必要があります。

実装

irb> require 'phonelib'
irb> Phonelib.default_country = "JP"
irb> Phonelib.parse('0292323011').national.split('-')
=> ["029", "232", "3011"]
irb> Phonelib.parse('0292323011').area_code
=> "29"

tableau serverのホスト名が変わってしまったときの対処法

Wed, 14 Apr 2021 00:00:00 GMT

背景

Tableau serverをAWS EC2で運用しています。

問題

インスタンスを落として、別のsubnetで起動したらtableau serverがちゃんと動かなくなってしまった。
具体的には、Webからアクセスできない。tsmコマンドを打つとエラーになる。
% tsm status Unable to verify the server's HTTPS certificate.
以下のcertificate checkを無視するオプションを付けても変化なし。
% tsm status --accepteula
大量にエラーが出力され続ける。
sudo tail -f /var/opt/tableau/tableau_server/data/tabsvc/**/*

対処法

hostnamectl set-hostnameを使って古いインスタンスのホスト名を無理やり設定する。その後、インスタンスのリブートをします。

以下がコマンド例。

sudo hostnamectl set-hostname ip-xxx-xxx-xxx-xxx.ap-northeast-1.compute.internal
sudo reboot

本来のやり方

落とす前にtsmコマンド経由でbackupファイルを作成する
新規ホストでtableau serverをクリーンインストール
backupファイルを復元

考察

tsm関連

tableauのtsmコマンドは、裏でhttpsで通信している
https serverはself signedなSSL証明書を使っている
tsmコマンドはself signedなSSL証明書だったら認証が通る。しかしながら、ホスト名が変わるとSSL証明書のホスト名と不一致になるので通らなくなる。

tableau server関連

内部でセットアップ時のホスト名を保持している様子。よってホスト名が変更されると正常に動かなくなる。
今回は無理やり前回のホスト名に合わせることで対処

自宅LinuxサーバにUPS(無停電電源装置)導入

Wed, 14 Apr 2021 00:00:00 GMT

概要

UPSが1万5000円ぐらいなのでこのblogが動いているLinuxサーバに導入してみました。
UPSとは、「Uninterruptible Power Supply」の略で、日本語では「無停電電源装置」と訳します。
APC RS 550 BR550S-JP Eを買いました。あまり商品リサーチはしてません。APCは老舗なのでまぁ、安心かなと。

::amazon{asin="B06XHZ3K5T"}

物理的なセットアップ

まず最初に、UPSの蓋を開けてバッテリーのケーブルを接続します。初期状態ではケーブルが外れた状態になっています。バイクのバッテリーみたいな電池が入ってました。

そして、こんな感じに適当にケーブルを接続してセットアップ。

残り時間は27分と出ています。

サーバであんまり電力消費しないはずなのに想定より短い感じです。今回は常時70Wぐらい使われています。mac miniでは5wしか消費されていなかたのに全然違う。。。

付属のUSBケーブルでUPSと接続しておきます。

ソフトウェア設定

apcupsdというデーモンで管理します。これによって、UPSの電池が切れそうになったらLinuxが自動的にシャットダウンされます。

aptで入るのでインストールします。

matsu@dell ~> sudo apt install apcupsd
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  apcupsd-doc
Suggested packages:
  apcupsd-cgi
The following NEW packages will be installed:
  apcupsd apcupsd-doc
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 532 kB of archives.
After this operation, 1,743 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://ftp.riken.jp/Linux/ubuntu focal/universe amd64 apcupsd-doc all 3.14.14-3build1 [328 kB]
Get:2 http://ftp.riken.jp/Linux/ubuntu focal/universe amd64 apcupsd amd64 3.14.14-3build1 [204 kB]
Fetched 532 kB in 3s (212 kB/s)
Selecting previously unselected package apcupsd-doc.
(Reading database ... 256476 files and directories currently installed.)
Preparing to unpack .../apcupsd-doc_3.14.14-3build1_all.deb ...
Unpacking apcupsd-doc (3.14.14-3build1) ...
Selecting previously unselected package apcupsd.
Preparing to unpack .../apcupsd_3.14.14-3build1_amd64.deb ...
Unpacking apcupsd (3.14.14-3build1) ...
Setting up apcupsd (3.14.14-3build1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/apcupsd.service → /lib/systemd/system/apcupsd.service.
Setting up apcupsd-doc (3.14.14-3build1) ...
Processing triggers for man-db (2.9.1-1) ...
Processing triggers for systemd (245.4-4ubuntu3.6) ...
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "en_US:en",
        LC_ALL = (unset),
        LC_CTYPE = "UTF-8",
        LC_COLLATE = "C",
        LC_TERMINAL = "iTerm2",
        LANG = "C"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "en_US:en",
        LC_ALL = (unset),
        LC_CTYPE = "UTF-8",
        LC_COLLATE = "C",
        LC_TERMINAL = "iTerm2",
        LANG = "C"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
 23 files changed, 816 insertions(+)
 create mode 100755 apcupsd/apccontrol
 create mode 100644 apcupsd/apcupsd.conf
 create mode 100755 apcupsd/changeme
 create mode 100755 apcupsd/commfailure
 create mode 100755 apcupsd/commok
 create mode 100644 apcupsd/hosts.conf
 create mode 100755 apcupsd/killpower
 create mode 100644 apcupsd/multimon.conf
 create mode 100755 apcupsd/offbattery
 create mode 100755 apcupsd/onbattery
 create mode 100755 apcupsd/ups-monitor
 create mode 100644 default/apcupsd
 create mode 100755 init.d/apcupsd
 create mode 120000 init.d/ups-monitor
 create mode 120000 rc0.d/K01apcupsd
 create mode 120000 rc1.d/K01apcupsd
 create mode 120000 rc2.d/S01apcupsd
 create mode 120000 rc3.d/S01apcupsd
 create mode 120000 rc4.d/S01apcupsd
 create mode 120000 rc5.d/S01apcupsd
 create mode 120000 rc6.d/K01apcupsd
 create mode 120000 systemd/system/multi-user.target.wants/apcupsd.service

インストール直後は勝手にデーモンが立ち上がって稼働しだします。初期設定を1つもしていないのに。。。

私の環境の場合、1つだけ追加で設定するだけで最低限の動作はします。DEVICEの行をコメントアウトするだけでした。

# DEVICE /dev/ttyS0

その後は、デーモンの再起動をします。sudo systemctl restart apcupsd

単独でAPCのUPSを使う場合はこれだけでよしなに動いてくれます。

設定されているパラメータを確認

apctestコマンドでステータスを表示できるかと思いきや、デーモンが立ち上がっている場合はこのコマンドは使えないよです。

matsu@dell ~> sudo apctest
[sudo] password for matsu:
2021-04-13 18:08:20 apctest 3.14.14 (31 May 2016) debian
Checking configuration ...
sharenet.type = Network & ShareUPS Disabled
cable.type = USB Cable
mode.type = USB UPS Driver
apctest FATAL ERROR in apctest.c at line 311
Unable to create UPS lock file.
  If apcupsd or apctest is already running,
  please stop it and run this program again.
apctest error termination completed

代わりに、apcaccessというコマンドを利用します。これを使えばデーモン経由で情報を取得してくるみたいです。

> sudo apcaccess
APC      : 001,036,0850
DATE     : 2024-06-30 15:47:11 +0000
HOSTNAME : gmk
VERSION  : 3.14.14 (31 May 2016) debian
UPSNAME  : gmk
CABLE    : USB Cable
DRIVER   : USB UPS Driver
UPSMODE  : Stand Alone
STARTTIME: 2024-06-30 15:42:16 +0000
MODEL    : APC RS 550S
STATUS   : ONLINE
LINEV    : 105.0 Volts
LOADPCT  : 13.0 Percent
BCHARGE  : 96.0 Percent
TIMELEFT : 39.3 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME  : 0 Seconds
SENSE    : Medium
LOTRANS  : 82.0 Volts
HITRANS  : 123.0 Volts
ALARMDEL : No alarm
BATTV    : 13.5 Volts
LASTXFER : No transfers since turnon
NUMXFERS : 0
TONBATT  : 0 Seconds
CUMONBATT: 0 Seconds
XOFFBATT : N/A
SELFTEST : NO
STATFLAG : 0x05000008
SERIALNO : 4B2033P28395
BATTDATE : 2020-08-16
NOMINV   : 100 Volts
NOMBATTV : 12.0 Volts
NOMPOWER : 330 Watts
FIRMWARE : 941.c6 .A USB FW:c6
END APC  : 2024-06-30 15:47:24 +0000

設定ファイルの確認

設定ファイルのパラメータを覗いてみます。ファイルは /etc/apcupsd/apcupsd.conf にあります。

UPSCABLE usb

UPSとの通信を何で行っているかです。USBなのでそのままでOK。

BATTERYLEVEL 5

電池の残りが5%になったらshutdown -hを実行するということ。

MINUTES 3

電池の残りが3分以下になったらshutdown -hを実行するということ。上記とor条件かなと思います。

ANNOY 300

シャットダウンの300秒前から、broadcastメッセージを出してユーザにログアウトを促す。

停電のテスト

商用電源を抜き差ししてみます。

流石にシャットダウンされては困るので短時間抜き差ししてみます。

抜いてみたときのログ。/var/log/syslog

Apr 13 17:06:20 dell apcupsd[18732]: Power failure.
Apr 13 17:06:26 dell apcupsd[18732]: Running on UPS batteries.

同時にメールがrootに飛びます。

商用電源を復帰させたときのログ

Apr 13 17:06:55 dell apcupsd[18732]: Mains returned. No longer on UPS batteries.
Apr 13 17:06:55 dell apcupsd[18732]: Power is back. UPS running on mains.

Mackerelから各種指標を監視する

gistにコードを書いておきました。

https://gist.github.com/matsubo/764666d00d25f2a53b505292c9a7c501

CSVデータをActiveRecordにimportする際における各手法のベンチマーク

Sun, 21 Mar 2021 00:00:00 GMT

概要

RubyにおいてCSVデータをDBに挿入する際の手法による速度の違いをベンチマーク
CSVデータのインポート処理は業務系のWebアプリケーションを構築する際にはほぼ必ず必要となる機能なので感覚地として掴んでおくことが目的です。

ベンチマーク対象のアプリケーション

郵便番号のAPIを提供しているサービス

https://postcode.teraren.com/ のデータ洗い替えの処理
郵便局のサイトから、郵便番号データと、事業所のデータをダウンロード
importの処理流れ
- 郵便番号のデータで洗替
- 郵便番号のデータを処理して、建物ごとに郵便番号をまとめて洗い替え
- 事業所のデータを洗替

この処理を運用中のサービスでは月初に自動で行っています。

Rails6でアプリケーションは書かれていますが、Rails5の場合も考慮してbulk insertにはactiverecord-importを使います。どちらを使ってもほぼ速度は変わらないようです。

データ量は、郵便番号のデータが124,568レコード、事業所のデータが22,371レコードです。

Ruby 3.0.0 + Rails 6.1.3

アプローチ

データをインポートする際に、どの程度抽象的なプログラミングを行うかがキーになってきます。低レイヤーで書けば書くほど速度は早いけど、ビジネスロジック上で面倒を見ないといけないことが多くなります。

主に悩む選択肢は以下です。

ActiveRecordオブジェクトをつかつか、Hashを使うか？ (ActiveRecord VS Hash)
bulk insertを使うかどうか？ (insert VS bulk insert)

それぞれのパターンで計測してみます。

ベンチマーク

以下のパターンでとりました。

Hash VS ActiveRecord
insert VS bulk insert

一応、比較のためにRails6のinsert_allのベンチマークも取ってみましたが、importよりかなり速いです。

activerecord-importはデフォルトでvalidateがかかりますが、ActiveRecord 6のinsert_allはvalidateは走りらないことが速度の差かと思います。DBへのアクセスが発生するようなvalidationは行っていませんが塵も積もれば山となる感じかと思います。

考察

ActiveRecord VS Hashの結果
- Hashのほうが20秒ぐらい速い。＝約22％速い。
insert VS bulk insert
- bulk insertのほうが約220秒速い。＝約74％速い。

注意：前処理の時間（約10秒）を含んだベンチマークなので、実装コード部分だけで考えれば、上記の表記よりずっと速い。

まとめ

CSVをインポートする際は以下の組み合わせが一番速い
- Hashの配列を作る
- Rails6のinsert_allを使う
もともとは110秒かかっていた処理を76秒にしました。＝約30％高速化。
- おもな変更点は2つ。ActiveRecordのインスタンスを作るのをやめて、import gemをinsert_allに変更。

TOPPING D10 USB DACのチップをOPA627AUに交換

Mon, 15 Mar 2021 00:00:00 GMT

今持っている、TOPPING D10というUSB DACはもとから評価が高くて良い品なのに加えて、オペアンプのチップを交換できるというすぐれものなので交換してみたいと思います。

::amazon{asin="B079HRGN5B"}

買ったチップはこちら。そっくりそのまま入れ替えられます。

Burr-Brown社製 OPA627AU 2回路DIP化オペアンプ完成基板実装品 2,980円

もともと搭載されているのはOPA2134PAです。

こちらが交換をするTOPPING D10です。32bit 384kHzに対応するDACです。こんな良質な音源は手元にないので完全に活かしきれませんが。。。

蓋を開けたところ。筐体と基盤を接着するボンドの処理が汚い。。。。ついでにきれいに掃除しておきます。

載せ替えたところ。以下の写真が正解の向き。

向きがよくわからなかったので、最初は逆向きにつけて電源を入れたら、チップがものすごく熱くなってしまった。。。再度差し直したら音が鳴ったので大丈夫だったのかなと思います。

チップを入れ替えた結果は、よくわからないですね。音源が悪いからだと思います。

スピーカーはYAMAHA MSP5 Studioです。

CloudWatchにrubyアプリケーションからログを投げる

Fri, 12 Mar 2021 00:00:00 GMT

しかし、投げまくっていると以下のような例外が出るので、Throttlingされてしまったらsleepする必要があります。そうなると全体としての処理パフォーマンスのボトルネックになってしまうので要注意です。

Aws::CloudWatchLogs::Errors::ThrottlingException Rate exceeded

CloudWatchに投げておけば後々の統計処理が楽になるので。

それにしても、ログを送るだけなのにコードをいっぱい書かないといけないなぁ。。。

ワンライナーでJSONをCSVに変換

Wed, 10 Mar 2021 00:00:00 GMT

リモートに有る郵便番号の一覧をJSONで取得して、必要なカラムだけを抽出してCSVファイルを作る方法です。

jqコマンドを使えば、いかに上げる例以外の

色々な集約や、構造の変更ができます。

17013 Generating access token for the SP failed

Thu, 04 Mar 2021 00:00:00 GMT

Google Workspace => Microsoft 365へのユーザ同期が失敗していました。

Download listを押して、エラーの内容を確認すると「17013 Generating access token for the SP failed」と記載されていました。ググっても解決方法は見つかりませんでした。

"Reauthorize"をクリックしたら裏で勝手に再同期がかかったようでエラーが消えて、ユーザ情報がMicrosoft側に同期されました。解決しました。

郵便番号検索APIサービスをGraphQL対応しました

Sun, 07 Feb 2021 00:00:00 GMT

概要

郵便番号検索APIサービスにおいて、GraphQLに対応しました。
graphqlを使い、paginationには graphql-pagination, kaminari-activerecordを使っています。

考察

GET系だけなので特にハマりどころは無く、オフィシャルドキュメントを軽く読んで、数時間で構築できました。
Typeの定義（REST APIでいうエンティティ）にアノテーションを少しするだけでドキュメントが自動生成されるのでドキュメンテーションが楽です。
paginationのmetadataがデフォルトでレスポンスに含まれるような記述がありましたが、実際には何も出力されなかったです。
N+1が発生しやすいので、その際はこのあたりを参考にする。graphql-batchを使って手動でpreloadするらしい。

AWS session managerのクライアント設定

Fri, 05 Feb 2021 00:00:00 GMT

概要

AWS Session Managerを使うと踏み台サーバが不要になるのでサーバサイドは設定しました。
クライアント側でわざわざEC2のinstance IDを指定するのが大変なのでかんたんにssh接続できるように設定します。

設定手順

同じ作者のshell scriptである、ssh-over-ssmとssm-toolを使います。接続のたびに、裏で勝手にsshのキーペアを作成してログインできるようにしてくれます。また、EC2のinstance idを人間がわかりやすい名前でアクセスできるように設定してくれます。

% ghq get git@github.com:elpy1/ssh-over-ssm.git
% cp ~/ghq/github.com/elpy1/ssh-over-ssm/ssh-ssm.sh ~/bin/
% ghq get git@github.com:elpy1/ssm-tool.git
% cp ~/ghq/github.com/elpy1/ssm-tool/ssm-tool ~/bin/
% pip3 install --user -r ~/ghq/github.com/elpy1/ssm-tool/requirements.txt

~/bin/にはpathを通しておきます。

~/.aws/configと~/aws/credentials にIAMのcredentialを設定しておきます。

aws cliをインストールしておきます。それに追加して、session manager pluginをインストールします。

Ubuntuの場合は以下。

% curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.deb" -o "session-manager-plugin.deb"
% sudo dpkg -i session-manager-plugin.deb

instance idとの関連付け定義ファイルを生成します。

% ssm-tool --ssh-conf

以下のような設定ファイルが生成されます。

あとは、わかり易い名前を指定するだけでsshでは入れます。

ホストの一覧ファイルを作るのにひと手間かかりますが、fishであればホスト名の補完ができるようになるので楽です。

まとめ

session managerを使ってかんたんにログインできるようにするツールを導入しました。

cyta.jpサービス終了に先立ち魚拓

Tue, 02 Feb 2021 00:00:00 GMT

背景

2007年頃〜2011年ごろまで私がシステムを開発していたサービスが終わるとのことです。
ちょっと当時のアチーブメントを軽く振り返ってみます。
せっかくなので魚拓しておきます。

振り返り

最初のコミット。

時系列

フィージビリティスタディ
- 2009年のフルタイムでジョインするまでの2年間ぐらいは土日や平日の夜を使って技術スキル向上&暇つぶしのために開発していました。
- 報酬はほぼ無償で開発をやっていました。今からだと考えられないですね。当時はエンジニアの希少性がまだ低いときです。
- cytaeはC2Cのプラットフォームという形を取っていますが、最初のうちはnucleusというPHPでできたCMSで先生ひとりひとりのブログを構築していました。blogを普通に1つ立ち上げるのは大変なので、コマンド1発でブログを構築できるようなスーパバイザサービスを作っていました。
- ビジネスが回ることがわかると、人力でやっていた作業を自動化する予約管理、授業料決済、報酬支払、フィードバックの仕組み、メッセージやり取り、ブログ機能などを一元的に開発するシステムが必要になってきました。
- 毎週少しずつ開発は進めていましたが、流石に機能が多くて、土日の作業では土曜日に先週やっていたところを思い出し、日曜にプラスアルファの開発をするというような日々が続いていてとても効率が悪くなっていました。
- 効率が悪くなったので副業ではなくフルタイムで開発することになります。
フルタイムで開発
- 給料が少なかったので家賃は半額のところへ引っ越しました。
- 1つのプロダクトを集中して開発できる状態は今思えばとても良かったです。
- 国内ではgitをいち早く導入した記憶があります。日本語の文献がなかったのでgitのオライリー英語本で学習していました。
- ポイント管理は結構先進的だったと思います。入金ごとに有効期限を管理したという要求がありました。当時はANAのマイル管理ぐらいしかこの方法での管理をしていなかったと思います。なぜなら、設計と実装が難しいからです。普通のシステムは、最終ポイント利用から1年といったロジックで実装されています。
その後
- なんか自分の思ったようなサービスの成長がなかった&戦略が見えなかったので見切りをつけGREEへ。
- cookpadに買収され、crowdworksに買収され、サービス停止が決定しました。
いま振り返ってみると
- このサービスを当時は、私とバイト数名でDevOpsしていたのは今から考えるとなかなかすごいかも。
- 約10年前に書いたコードが現役で動き続けているのはすごい。
- deployはgit pullだけなので数秒で終わるし、サーバはVPSで運用していたので月に5,000円ぐらい。最強に安価だしライトウェイトな運用システムでした。
- 講師は全員面接をしていたので、高品質でした。私自身もサービスを使い3人のコーチと出会いました。各コーチは自分の人生にとって重要な価値観や示唆を与えてくれました。今でも連絡を取り合っている人も居ます。
- そういえば、自分も講師としてシステムコンサルをしていました。
- 信用は重要ということを学ぶ。

魚拓

感想

当時、お世話になったお二方のコーチに頂いたアドバイスはその後ずっと人生で生きています。この方々に出会わなければ多少なりとも価値観や生き方が変わっていたと思います。

マンツーマンだからこそ、自分に最適なアドバイスをくれるし、自分もちゃんと受け入れると思います。金額がちょっと高いですが有意義なことに使えばすぐにペイするぐらいです。むしろ、教える人にとってちょっと割安すぎる感があるような感じなので。

個人的には社会的意義のあるサービスだったなぁと思います。

ActiveRecordでネストされたトランザクションのRollback方法

Mon, 01 Feb 2021 00:00:00 GMT

概要

ActiveRecordでトランザクションを入れ子にするケースがあり、ActiveRecordのトランザクションの処理を追ってみるとなかなか興味深かったので文章にまとめておきます。
おそらく、この内容を知っておかないと排他制御を考慮したクラス設計、実装ができないと思う。

問題

以下のようなコードがあったときに、1つ目のセンテンスである'Kotori'と'Nemu'が作られます。（一見、一切コミットされないように思えるかもしれませんが）

User.transaction do
  User.create(username: 'Kotori')
  User.transaction(requires_new: true) do
    User.create(username: 'Nemu')
    raise ActiveRecord::Rollback
  end
end

こんなコードは普通は書きませんが、クラスが別れていたり、実装するレイヤーが分かれている場合に不用意に発行されてしまう可能性があります。
- 例えば、振替というビジネスロジックに対して残高の加算や減算の処理。

原因

理由

ActiveRecordのtransactionはActiveRecord::Rollbackをraiseしないために起きます。

該当のコードはこちら。（現時点のmainブランチの最新です。v6.1.1の半月ぐらい先くらいのコード）

https://github.com/rails/rails/blob/e9d997a/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb#L313

      def transaction(requires_new: nil, isolation: nil, joinable: true)
        if !requires_new && current_transaction.joinable?
          if isolation
            raise ActiveRecord::TransactionIsolationError, "cannot set isolation when joining a transaction"
          end
          yield
        else
          transaction_manager.within_new_transaction(isolation: isolation, joinable: joinable) { yield }
        end
      rescue ActiveRecord::Rollback
        # rollbacks are silently swallowed
      end

1回目のtransaction呼び出しは、transaction_manager.within_new_transactionが実行されますが、2回めのtransaction呼び出しは普通にyieldされるだけになります。（transaction開始時にオプションを指定していない場合）

よって、beginが発行されません。また、そのyieldで発行されたRollbackは、rescue ActiveRecord::Rollbackによって捕捉されて中身は何もしていません。

参考までに、within_new_transactionのコード。

https://github.com/rails/rails/blob/e9d997a/activerecord/lib/active_record/connection_adapters/abstract/transaction.rb#L313

      def within_new_transaction(isolation: nil, joinable: true)
        @connection.lock.synchronize do
          transaction = begin_transaction(isolation: isolation, joinable: joinable)
          ret = yield
          completed = true
          ret
        rescue Exception => error
          if transaction
            rollback_transaction
            after_failure_actions(transaction, error)
          end
          raise
        ensure
          if !error && transaction
            if Thread.current.status == "aborting"
              rollback_transaction
            else
              if !completed && transaction.written
                ActiveSupport::Deprecation.warn(<<~EOW)
                  Using `return`, `break` or `throw` to exit a transaction block is
                  deprecated without replacement. If the `throw` came from
                  `Timeout.timeout(duration)`, pass an exception class as a second
                  argument so it doesn't use `throw` to abort its block. This results
                  in the transaction being committed, but in the next release of Rails
                  it will rollback.
                EOW
              end
              begin
                commit_transaction
              rescue Exception
                rollback_transaction(transaction) unless transaction.state.completed?
                raise
              end
            end
          end
        end
      end

ネストされたブロックだけロールバックしたい場合

まず、回答としてはできます。

前提として殆どのデータベースはネストされたトランザクションをサポートしていません。MS-SQLだけのようです。

**MySQLなどのRDBではsavepointを使ってエミュレートしています。**よって、細かい例外条件や細かい注意事項が出てきます。

やり方は、savepointを使うためにネストされたtransaction呼び出し時に、requires_new: trueを追加します。これによって、savepointが発行されます。

User.transaction do
  User.create(username: 'Kotori')
  User.transaction(requires_new: true) do
    User.create(username: 'Nemu')
    raise ActiveRecord::Rollback
  end
end

上記のコードを実行すると、Kotoriだけが保存されます。

アプローチ

1. requires_new: trueを全部に付ける

では、全部requires_new: trueをつければ、なんとなくプログラマーの意図通りに動いてくれるだろうからそれで良いのかもしれません。これはこれで、**1つの解ではあるかもしれません。しかしながら、RDBMSごとに実装が異なったり、savepointを使って、部分的にrollbackされたときのロック範囲について考えながらコードレビューするのは大変かと思います。**静的チェックもできないですし。

2. DB transactionを1つにまとめる

transactionブロックが分散してしまうのであれば、transactionを1箇所で管理するとtransactionのnestを発行させないようにできます。

前提として、ビジネスロジックレイヤーを整理しておく必要があります。なぜなら、どのレイヤー（ビジネスロジック、ユーティリティクラス、ORMなど）でDBのtransactionを使うかを明確にする必要があり、けっこう大変かと思います。

class TransactionScript
  def self.process(&block)
    ActiveRecord::Base.transaction do
      yield
    mary.deposit(100)
  end
end

TransactionScript.process do
  subtract
  add
end

この方法では、静的チェックも可能です。デメリットとしては、transactionを使うときには呼び出しコードをブロックで実行しなければいけないので、インデントが深くなるのとコード量が増えます。

3. raise ActiveRecord::Rollbackしない

一見、このルールを作ったらコーディングの自由度が減るから嫌うかと思いますが、現場ではraise ActiveRecord::Rollbackを書く必要は無いと思います。

サンプルコードで、ネストされたブロックでraise ActiveRecord::Rollbackをしていますが、サンプルでしかありえない書き方かと思います。本来ならば独自の例外をraiseするはずなので全体が失敗するようなコードになります。

例えば以下のようになります。

User.transaction do
  User.create(username: 'Kotori')
  User.transaction do
    User.create(username: 'Nemu')
    raise MyOriginalError
  end
end

これならば全体で失敗しますし、外側のブロックから見たら全体で失敗すべきなので問題ないです。

そもそも、raise ActiveRecord::Rollbackを発行する際というのは、そのtransactionブロックの中で何かしら問題が起きて、その問題を上位に伝搬せずに対処するという時にしか使わないはずです。そのようなケースが思いつかないです。

このアプローチならば、コードの静的チェックも可能になり、運用しやすいです。

まとめ

ActiveRecordのtransactionを使ったときのネストの挙動を追ってみました。
3番めの運用法が良さそうです。
その挙動とうまくやり合うために、クリアに持続可能な運用をするアプローチを提案しました。

参考資料

PC版GREEの魚拓

Mon, 01 Feb 2021 00:00:00 GMT

https://x.com/4GamerNews/status/1356172192329818115

魚拓撮っとく。

本番テストのためにたくさんガチャを引いたなぁ。。。

EC2ホストのログをCloudWatch Logsに集約

Sun, 31 Jan 2021 00:00:00 GMT

概要

/var/log/messages などのOSのログ、/var/log/httpd/access.log などのサーバ・ソフトウェアのログをCloudWatch Logsに集約します。設定はかんたんです。
EC2インスタンスやContainerなどの計算資源は使い捨てですが、ログだけは監査などのために保管しておきたいため一通り設定しました。

設定

ssm-agentを使っていない場合は、ssm-agentを設定しておいたほうが良いです。（AWS Access keyでの認証もできますが、面倒だし少しセキュアではないので）

Amazon Linux 2の場合

設定は楽です。こちらの公式ドキュメントを参考にインストールすればOKです。

% sudo yum install -y awslogs

/etc/awslogs/awscli.conf を変更します。デフォルトだとusになっているので、ap-northeast-1などに書き換えます。

つぎに、/etc/awslogs/awslogs.conf を開いて以下の設定を末尾の方に記述します。

[/var/log/messages]
datetime_format = %b %d %H:%M:%S
file = /var/log/messages
buffer_duration = 5000
log_stream_name = {instance_id}
initial_position = start_of_file
log_group_name = /var/log/messages

[/var/log/secure]
datetime_format = %b %d %H:%M:%S
file = /var/log/secure
buffer_duration = 5000
log_stream_name = {instance_id}
initial_position = start_of_file
log_group_name = /var/log/secure

datetime_formatは、読み込むログファイル内で、日付がどのようなフォーマットで表記されているかです。これをもとにtimestampを生成した上で、CloudWatchに送信されます。

最後に、systemctlでサービスを有効にします。

% sudo systemctl start awslogsd
% sudo systemctl enable awslogsd.service

Ubuntuの場合

Amazon Linux 2のようにパッケージは用意されていません。Pythonのセットアップスクリプトを実行することによって、/var/awslogs に必要ファイルが展開されます。

セットアップ方法はこちらが一番綺麗に整理されているので参考にするのが良いです。

途中で、regionのパラメータを設定する必要があるのでそちらは適宜置き換えます。以下は東京の例。

$ sudo python ./awslogs-agent-setup.py --region ap-northeast-1

セットアップ中に、AWS access key IDとAWS secret access keyが聞かれますが、ssm-agentを使っているならば空白で飛ばしてOKです。

インストールが完了すると、設定ファイルは/var/awslogs/etc/awslogs.confに置かれているので開きます。

Ubuntu/Debianの場合は以下のような設定を追記します。

[/var/log/syslog]
datetime_format = %b %d %H:%M:%S
file = /var/log/syslog
buffer_duration = 5000
log_stream_name = {instance_id}
initial_position = start_of_file
log_group_name = /var/log/syslog

[/var/log/auth.log]
datetime_format = %b %d %H:%M:%S
file = /var/log/auth.log
buffer_duration = 5000
log_stream_name = {instance_id}
initial_position = start_of_file
log_group_name = /var/log/auth.log

[/var/log/kern.log]
datetime_format = %b %d %H:%M:%S
file = /var/log/kern.log
buffer_duration = 5000
log_stream_name = {instance_id}
initial_position = start_of_file
log_group_name = /var/log/kern.log

[/var/log/dpkg.log]
datetime_format = %Y-%m-%d %H:%M:%S
file = /var/log/dpkg.log
buffer_duration = 5000
log_stream_name = {instance_id}
initial_position = start_of_file
log_group_name = /var/log/dpkg.log

最後にリスタートを忘れずに。

%  sudo service awslogs restart

設定の確認

こんな感じでインスタンスIDごとにログストリームができます。

Logs Insightで横断的に検索できます。使い方はこちらの記事を参照。

このようにCloudWatch Logsに入ってしまえば、メッセージや流量をトリガーにSNS経由でアラートを発行できるようになります。

とりあえずシステムのログはCloudWatchに入れてしまうのが良いと思います。

まとめ

システム系のログは流量が少ないので何も考えずにCloudWatch Logsに入れてしまって良いと思います。
アプリケーション系は要望によって、要設計。

Amazonで2020年に購入した商品を軽く見てみる

Sat, 30 Jan 2021 00:00:00 GMT

概要

家にいる時間が増えて、アマゾンでたくさん買い物をしたから振り返ってみようと思いました。購入内容の算出にはこのスクリプトを利用しました。
たくさん買い物をしたなぁと思っていたけれど、大したことなかったです。
もっとたくさん消費して経済を回したほうが良いと思いました。

複数個買ったのは単価1つとして出てしまています。

考察

買ったけど、殆ど使っていないものやハズレのものがたくさんありました。。。
良かったもの
- インターホンの子機：デスクで応答できるから楽。
- インパクトドライバー：穴あけ、ネジの締込み作業が格段に楽になりました。
- 6Lぐらい入る加湿器：水を補充する手間が減った。
- モニターアーム：デスクが広くなる！
買わなくてよかったもの
- ランニングシューズ：やすかったからたくさん買ったけど、1つも箱を開けていない。
- WiFi中継機：あんまり意味なかった
- スピーカーインシュレーター：変化なし。

おまけ

過去すべて

2021/1/29 Minedia Tech Talk 今週のニュース

Sat, 30 Jan 2021 00:00:00 GMT

はじめに

メイン

三井住友銀行などのソースコードが流出 "年収診断"したさにGitHubに公開か
- これはきつい。。。
- 銀行、警察のソースコードも上げていた模様。Forkされたソースコードが見られる状態（リポジトリは法的措置により削除済み）。もう拡散は止められない。
- 私もかつて、外注先にソースコードをpublicにされて、大変でした。
- github連携から自動で年収判定をするサイトで、tensorflowのサンプルコードを10行ぐらい書けば、年収800万円ぐらいと表示されるらしい。
在宅ワークのお供
- ホットクック＋ネットスーパー
- コスパ良い。もちろん、食洗機がある前提。
- ホットサンドメーカー良い。水分が飛ばないから美味しくできるし、火の通りが早い。油が飛び散らない。だけど、掃除が若干面倒。。。

めちゃ綺麗。

https://www.youtube.com/watch?v=6yuZnQSDuBo&feature=emb_logo

マネオフォ給与のSSOは有効にできないの？
- 有料オプションっぽいかも。
- セキュリティを向上できるからお互いにとって良いはずなのに謎。利益追求かー。
東京の緊急事態宣言は延長っぽい。
- 都内に住む利点って薄いのでは？固定費の安い地方移住するのが良い気がする。
- しかし、もとに戻ったら不便すぎるし。
- 移住するとなったら半年ぐらい準備に掛かりそうだし。その頃には少しは状況が良くなっているはずだし。
- 地方移住するなら、海外移住を検討しても良いかもなー

おわりに

githubでmentionされたらslackへ通知する設定 (所要時間約10分）

Tue, 19 Jan 2021 00:00:00 GMT

概要

github上でmentionされても気づくのが難しい状態でした。メールはいろいろな通知が送られてくるし、githubのwebサイト上の通知欄は自分から見に行かないと行けないし、後ほどTODOとして未読に変更ができないので自分のタスク管理がしづらい状態でした。
github-mention-to-slackというGithub Actionがあったので設定してみたところ、かなり快適でした。
紹介されている設定では、運用に不十分なところが多かったので、ほとんどコピペでできるような設定をgistに置いておきます。

設定

githubのrepositoryまたはorganizationのSecretにSLACK_WEBHOOK_URL_FOR_MENTIONというキーでSlackのwebhook URLを登録します。

（organizationに登録しておけば設定を使い回せるので楽です）

以下を実行して、Github Actionsの設定ファイルを2つ作ります。

cd path/to/repository
mkdir -p .github/workflows
curl https://gist.github.com/matsubo/69f994a3a9830973c56fd8322798f60f#file-mapping-mention-to-slack-yml > .github/mention-to-slack-yml
curl https://gist.githubusercontent.com/matsubo/69f994a3a9830973c56fd8322798f60f/raw/731171a269ad11befc9e15c4a47bf1059c6ef541/mention-to-slack.yml > .github/workflows/mention-to-slack-yml

次に、githubのアカウントとSlackのアカウントのマッピングをgithub/mention-to-slack-ymlに書きます。

サンプル

# For Github User
# github_username: "slack_member_id"
# please_replace_me_11: U01G30S9LHW
# please_replace_me_4: U011F5DRG2V

# github_username_A: "slack_member_id_A"
# github_username_B: "slack_member_id_B"
# github_username_C: "slack_member_id_C"
# abeyuya: "XXXXXXXXX"

# For Github Team
# github_teamname: "slack_member_id"
# github_teamname_A: "slack_member_id_D"

slackのIDはその人のプロフィールをクリックして表示される英数字10桁ぐらいの文字です。

これで設定はおわりなので、commitしてpushしてメインとなるブランチにmergeされた状態にすればOKです。

送られてくるメッセージこんな感じ。

これで、手元のslackで未読、既読の管理ができるし、リマインダも設定できます。取りこぼしも激減しました。

ちなみに、pull requestのassignが行われたときにもその人へ通知が来ます。

github上でコメントに後からmentionを追加した場合は通知は飛びません。

2021/1/15 Minedia Tech Talk 今週のニュース

Fri, 15 Jan 2021 00:00:00 GMT

はじめに

本題

蔦屋書店が15のサービスをAWSへ移行、システム標準化や保守作業の削減に成功
- はてブがついているから見たけど普通だった。
Amazonの領収書をまとめて出力、確定申告の“神”ツール「アマゾン注文履歴フィルタ」
- 地味に便利
数千円のWebカメラと照明で、ビデオ会議やゲーム配信ワイプの画質を高級カメラに近づける
- 証明でぜんぜん変わるのはわかるけど、ライトが眩しい！よほど気合の入ったカンファレンス的なイベントなら良いですけど普通のテレカンではオーバースペック感はありますね。
- テレカンのたびにライトを入れたり切ったりするのが大変です。
- なにか良い方法あればいいんですけどねぇ。
みんなでエッチに見える方の画像を選ぶ『遺伝的アルゴリズムで最高にエッチな画像を作ろう！』→3500世代目にしておっぱいとお腹誕生へ
- 昔の状態がわからないからいまいち凄さがわからない。。。
- 遺伝的アルゴリズムだと限界がありそう。
- しかもフィードバックが2つに1つだと時間がかかりそう。。。両方同じくらいというフィドバックも入れると局所解に陥らなさそうな気はする。
Parlerの投稿がひどすぎて削除される前にハッカーが完全保存。メタタグで議事堂占拠犯がゴロゴロ逮捕
- 画像をstripしていなかったのか。。。初歩的な。。。
- コンテンツ規制の境界って難しい。発言の自由が脅かされる。
電気代「市場連動型」４月まで高騰続く可能性／識者
- 辛い。。。
- 一般家庭で市場連動を使っている人って稀なような気がするが。
これぞゲーミングマスク!? Razerが手掛けるマスク「Project Hazel」が登場
- 光ることが特徴？？
devise-two-factor
- qrcode, smsなどの2FA対応できる。まぁ、認証ロジックにはそこそこ手を入れないといけなさそう。
- あんまりはてブついていないけど、このご時世はかなり重要な気がする。。

あとがき

2021/1/8 Minedia Tech Talk 今週のニュース

Fri, 08 Jan 2021 00:00:00 GMT

はじめに

本題

ベテランエンジニアがクラウドワークスで5,000円の案件を受けてみた｜ebiebi_pg｜note
- 逆に発注する側からするとお得にできるということですね。
- そう考えて、私が数年前に、難易度が低いRailsアプリケーションの管理画面に機能を追加するという案件を5個ほど普通の業務委託相場の8掛けの値段で出したら応募が殺到しました。頑張って発注する人を選定し、発注しましたが半分ぐらいの人しか完了しなかった。。。
- プロジェクト形式なのに「完了してないけど頑張ったから報酬をくれ」とか言われたりして交渉が大変だった。揉めたら悪い評価付けられるし。
- まれに優秀なコードを書く人は居たりもする。ちゃんとしたフルタイムでエンジニアをしている人が副業の受注先として使っていたりもする。（今回のnoteの作者のような人）
年始だからか、ニュースが少ないなぁ。
個人ネタですが、個人で運用しているサービスをruby 3に置き換えました。
- https://postcode.teraren.com/postcodes/
- https://bank.teraren.com/
- https://github.com/matsubo/covid19-daily-tweet
- もう1こ、rails 6のサイトはpumaが上がらなくて時間切れで断念。
プログラミングスクールに通うくらいならこの本を読め10選 - ニート向けソフトウェアエンジニアリング塾 {/* textlint-disable no-unmatched-pair */}
- うーん。1つも呼んだことがない（汗） {/* textlint-enable */}
- リーダブルコードは流し読みしたけど、Code completeに書いてある内容だったので。
バイデン次期政権、オープンソース開発者のリコードン氏を技術ディレクターに - CNET Japan
- 台湾のオードリー・タンに続いてアメリカも。
「リモート初詣」で参拝客が130倍に、住職のこだわりと技術力に驚いた | 日経クロステック（xTECH）
- 環境に適合する人だけが生き残っていけるよね。
Serverlessをテストしよう / Serverless Testing - Speaker Deck
- 半年前ぐらいにこのあたりを考えてみたけど、やっぱり大変ですよね。。。

あとがき

2020/12/25 Minedia Tech Talk 今週のニュース

Fri, 25 Dec 2020 00:00:00 GMT

はじめに

本題

IQbuds2 MAX良さそう。
- https://av.watch.impress.co.jp/docs/review/review/1296432.html
- RTINGS.comの結果次第かなと。定量的に音響機器を評価してくれる素晴らしいサイト。
- https://www.rtings.com/headphones/tools/compare/bose-soundsport-free-vs-b-o-play-e8/560/566
- 5万円か。。。
作業環境リノベ。ガチだ。
- https://blog.craftz.dog/a-solo-app-developers-dream-desk-setup-late-2020-bac70736e809
- 自己満足感が強いけど、家の仕事環境に投資しても良いですよねぇ。長引きそうなので。
- リフォーム業者は忙しいらしいです。
- Pro Display XDRはちょこちょこTwitter上で買っている人を見かけるけど、実売価格が知りたいなぁ。定価52万円。整備品で安く出たという話もある
- 冬休みにやるのが丁度いいのでは？
- 木の天板が欲しいー。ちょうどよい反発感。反発力が強いとあたっている手が痛くなる。
Smooz終了
- https://b.hatena.ne.jp/entry/s/reliphone.jp/post-16361/
- 個人的には乗り切ってほしかったし、ポイントを稼ぎたいユーザも一定数居たと思うんだけどなぁ。倫理性はわからん。
- 第三者機関の監査と、プライバシーポリシーが明確になっていて、ユーザの合意が取れれば良い気がするが。
おすすめAlexaスキル
- https://otona-life.com/2020/12/24/49287/ （リンク切れ）
- トータル5個飼ってます。あんまり有効活用していない。。。
- 便利そうなので整備してみても良いかもなぁ。
Ruby 3.0.0 リリース
- https://www.ruby-lang.org/ja/news/2020/12/25/ruby-3-0-0-released/
- 特徴はズバリ型！！
- パフォーマンスはVMで37%ぐらい早くなっているっぽい。
- 色々なサービスをはやく載せ替えてみたい。

https://x.com/nalsh/status/1342350629407092737

HHKB Pro BT買いました。
- apple keyboardに慣れていると、キーストロークが深くて指の可動域が広くなって辛い。
- macだと、functionキーの共存が難しい。
- 1列まるっとキーが減っているので、なくなっているので代替方法が今の所よくわからない。
- USB接続しているのに、キーボードマップツールが何故か動かない。。キーボード自体の打鍵はできるのに。冬休みに考える。
- 打鍵音は最高ですけどね。ちょっとうるさいかも。Type-Sなら打鍵音が静かで、キーストロークも0.2mmほど短いらしい。本物を試してみたいです。

https://x.com/matsubokkuri/status/1342006932576473088

おわりに

Minedia社の技術ブログを立ち上げました

Sat, 19 Dec 2020 00:00:00 GMT

概要

技術ブログを立ち上げる目的とか狙いとか、運用で困るといった考察は、TechBlog運用の難しさとHERPでの考えについてに書いてある内容と同じことを考えておりました。ただ、blog hubを立ち上げたくても立ち上げコストがかかるからプライオリティを下げてました。
そんなところで、@catnose99さんがblog hubを構築するOSSを公開してくれたのでforkして利用してみました。
- https://github.com/catnose99/team-blog-hub
Forkしたコードは公開しております
- https://github.com/minedia/team-blog-hub （リポジトリ削除済み）
10分ぐらいで構築できると思います。

主な設定

コードはNext.jsのSSG(Static Site Generators)で書かれています。ソースコードのコミットログを見てもらえればわかると思いますが、Forkした上で、主な設定はこれ。

https://github.com/minedia/team-blog-hub/commit/640dc1cff76f3b4595045d3574f3b970a9a52f22 （リポジトリ削除済み）

設定項目はきれいに外出しされていて超簡単です。

ホスティング

Vercelを使っています。github organizationと連携するので有料（$20/month）になりますが、最初の2週間は無料です。個人アカウントなら無料のようです。

普通に設定すると minedia-engineer-hub.vercel.app のようなホスト名でホスティングされます。自社ドメインで運用したいので独自ドメインの設定をします。

Vercelの管理画面上で独自ドメイン + TSLの設定をすることになるわけですが、非常に簡単です。まずドメインを新たに追加します。

そのうえで、オーナー確認をするためにDNSの設定を自分のドメインに追加します。初期状態ではドメインの所有者確認ができていないので "Invalid Configuration"と表示されます。

CNAMEを1つ入れるだけです。

再度設定ページを表示すると、Valid configurationになります。

そしたら、独自ドメインで表示されるようになります。

https://tech-blog.minedia.com/ => zennへ移行しました。https://zenn.dev/p/minedia

githubなので、社内のエンジニアだけでなくbizの人もpull requestを出すことで運用できます。

定期的なデプロイ

初期設定のままでは、静的なファイルなので誰かがコンテンツを書いてもHub側のページは更新されません。pingを送ることで更新するのが一番良いのですが、pingを送ることに対応していないblogが多いので定期的に自動更新をします。

Vercelではcronに対応していないのでGithub Actionsからデプロイをトリガーします。

設定ファイルはこちら。（この設定内容が世の中に出回っていないので貴重です）

https://github.com/minedia/team-blog-hub/blob/master/.github/workflows/cron.yaml （リポジトリ削除済み）

name: Deploy production site
on:
  schedule:
    - cron: '5 1 * * *'
jobs:
  cron:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: amondnet/vercel-action@v20
        with:
          vercel-token: ${{ secrets.VERCEL_TOKEN }} # Required
          github-token: ${{ secrets.GITHUB_TOKEN }} #Optional
          vercel-args: '--prod' #Optional
          vercel-org-id: ${{ secrets.ORG_ID}}  #Required
          vercel-project-id: ${{ secrets.PROJECT_ID}} #Required
          scope: ${{ secrets.VERCEL_SCOPE }}

環境変数を設定するために、ローカルで npx vercel を打って、セットアップします。

その後、.vercel/project.json の中に書かれた情報を使って環境変数を追加します。

githubのsecretsに追加

まとめ

短時間で会社の技術ブログを立ち上げられました。
自分の個人BlogのRSSを登録するということもあり、定期的に記事は書いているので、更新が止まった感じの寂れた感じは出ないはずです。
会社で使っているや社内の雰囲気はこちらのスライドを御覧ください。

2020/12/18 Minedia Tech Talk 今週のニュース

Fri, 18 Dec 2020 00:00:00 GMT

はじめに

本題

明日渡航。New Yorkの新規陽性者多い。
- New Yorkは日本からの渡航後は自主隔離。

Tom Cruiseが非常に意識高くてびっくり。
- マスクをしていないスタッフをガチギレで注意。その理由が、プロフェッショナルな意識によるもの。
Docker 3リリース。メジャーバージョンアップですがそこまで大きなものはなさそう。
ARM対応のDocker DesktopがTech Review版をリリース
ChromeやEdgeの拡張機能複数にマルウェア実装。すでに300万人がダウンロード
- 上記サイトに怪しいプラグインの一覧が掲載されている。
- マーケットプレイスという仕組み上しょうがないような。。。
- とある日までまともに動いていたけど、ある日からいきなりマルウェアになるパターンも存在する。（開発者が身売りするケースがある）
たった一言でエンジニアを怒らせる方法 10 おまけ付き
- ついつい言ってしまう言葉があります。。。
Smoozのデータ送信の件
- ユーザにコンセンサスは取っている様子。
- オフィシャルからコメントが出ていて、バグによってログアウトしていても情報を送信しているから直すとのこと。会社の対応が誠実。
- 元記事の中でもちょっと釣り的なタイトル。
- 高木浩光先生はノーコメントっぽい。Retweetだけしている。
情報収集にTechFeedおすすめです。
- パーソナライズ化されたTech系ニュースが配信される。
- プロがキュレーションしている様子。まとめ記事とかじゃなくて1次情報源の記事が多いのが良い。
- 海外のソースも豊富。

お知らせ

超低リスクに自社プロダクトのスタートアップを立ち上げるために大事な5つのこと

Mon, 14 Dec 2020 00:00:00 GMT

背景

CTOA Advent Calendar 14日目の記事です。
CTOの役割や業務については他の素晴らしいCTOが書いてくださっているので、この記事では会社員エンジニアとして働きながら事業アイデアを仮説検証し、自社プロダクトのスタートアップを立ち上げるまでの話をしたいと思います。

一般的にスタートアップを立ち上げるのはハイリスクと思われているかもしれませんが、しっかりとリスクヘッジをすれば超低リスクにスタートアップを立ち上げることができると、実体験ベースで思いました。今回はリスクヘッジの要点を5つに絞ってそのコツをお伝えできればと思います。

概要

私の人生の目標のうち、一部を抜粋します。
- 0からサービスとビジネスを作る。
- 世の中を効率的、便利、公平にする。
- そのためには、スタートアップをやろうと20年前からの目標です。
そのためにはITを使ったスタートアップを立ち上げるというアプローチが最適でした。今はその実現途中であり、株式会社マインディアのCTO 3年目です。

経歴

経歴だけだとつまらないので、一言コメント付き。

2005年慶應義塾大学環境情報学部卒業
- (研究室に寝泊まりの日々)
2006年 UCLA Extension ALC high intermediate 修了
- (IT業界で生きていくには英語が必須だと思い、とりあえず海外へ。)
2007年 - 2009年某社にて自社ECサイト開発
- (知り合いの会社に呼ばれたので、帰国してシステム開発、サービス立ち上げ。)
2009年-2011年コーチ・ユナイテッド株式会社にてcyta.jpを0からのサービス開発・運用
- (前職のときに土日で手伝っていたサービスが大きくなってきたのでフルタイムへ)
2011年 - 2013年グリー株式会社にてソシャゲDevOps、海外展開、2ndゲーム運用、チームマネジメント
- (大規模トラフィックを扱いたくて)
2014年 - 2018年株式会社メタップスにてSPIKE決済サービスを0から開発・運用
- (手数料ゼロの決済サービスを使いたい！と思って話を聞いたら、流れで開発する側になっていた)
2019年 - 株式会社マインディアにてCo-founder CTO
- マーケティングにおける調査を効率的にして、ITを活用したインサイトを生むために！

重要な5点

起業までに必要な重要な点を時系列で整理しました。

1．自分自身の価値観を整理し準備する

スタートアップは辛いことが多いので、自分の得意なこと、性格、ゴールなどは明確にしておきます。

なぜなら、一緒に組むメンバーを探す時やサービスを考えるときに、目標や価値観が違っていては議論の土台が変わってしまうためです。3年後の売上を年1億円目指すのか年100億円を目指すかによってパートナーやアプローチが変わってくるためです。

また、自分自身の強みを客観的にも把握しておくことをおすすめします。自分では気づけなかった強みを見つけられると思います。

例えば、CliftonStrengthsをやってみるなど。CliftonStrengthsの思想は、苦手分野を克服するより得意分野を伸ばしたほうがパフォーマンスが上がるので得意分野を知って継続的に研鑽するという考え方です。（統計的裏付けもあるみたい）。その得意分野は下記に記載のとおり34項目あるそうです。

引用元

私の2018年ごろの結果は以下です。

未来志向
目標志向
戦略性
親密性
個別化

2. 信頼できる人とやる

基本的にエンジニアはエンジニアリングに集中するのが得策かと思っております。経営、マーケティング、ファイナンスのプロと話すとわかりますが簡単に習得できるような職種じゃないと感じました。

そのような分野は専門家に任せたほうが良いので、スタートアップをやるときには誰か組むのが一般的かと思います。

そのときに一番根底にあるのは信用・信頼です。

私は過去に騙された経験がありますが、騙された場合はその事業に掛けた数年間の時間やお金を失うことになります。最悪お金はなんとかなりますが、時間が奪われると取り返せません。

信頼を少しでも担保するためには一緒に働いたことがある人や、友人、リファレンスチェックができるような人と組みましょう。

私が、出会った信頼できない人の行動例

超ケチ
- 自分の懐だけ潤して、社員や関係会社の利益はあまり考えない。
- 一緒に儲けようというチームプレイができない。周りの人がチームプレイをしているつもりでも騙されている場合がある。
女性関係が派手、社内の人と真剣ではない交際をする
- 色々と面倒なことを引き起こすリスクがあります。
- ビジネスとプライベートの区別がつかない。経営の意思決定がブレる。
口だけで実績が伴っていないまたは、実績が客観的に判断不能
- 喋りやポートフォリオがとてもきれいに見えるけど、実際に働いてみたらパフォーマンスが上がらないような人は多い。その人が行った実績を別の手段で評価しましょう。
- その本人の実績がよくわからない状態ということは、殆どの場合でその人が実績を上げていないからです。

例外があり、死ぬほど頭の良い人とは組んだほうが良いという反省はあります。死ぬほど頭の良い人は、他人にもちゃんと利益を与えることを軽視しないし、ビジネス自体の成功確度が高いです。

また、ファイナンスや経営の知識を自分で習得して会社経営を全般的に自分でハンドリングできるならばあまり重視する必要はないです。しかしながらエンジニアリングとは違う領域なのでハードルは高いです。

3. どこのフィールドで活動するかを計画する

この選択はロールプレイングゲームに言い換えると、その後の難易度がイージーモードかハードモードかが変わってくる非常に重要なポイントになります。

シンプルですが、以下のようなフレームワークを使って、作ろうとするサービスやビジネスの仮説を検証します。

マーケティング環境分析と市場機会の発見
セグメンテーション（市場細分化）
ターゲティング（市場の絞り込み）
ポジショニング
マーケティング・ミックス（4P）

まだこの段階ではリサーチ段階なのでいくらでも立ち戻れます。起業は手段なので焦って起業しないようにしましょう。

私の場合は、代表の鈴木と定期的に電話などでビジネスのディスカッションをしていました。その中で、上記のフィルタリングをくぐり抜けたのがオンラインでの定性調査サービスでした。

この仮説検証の段階で1つ気になったことがあった。それは、「オンラインでのインタビューがほとんど行われていないこと」。オンラインで定性調査するサービスを作っても、実はすでに提供している会社がありましたというオチになるのではないか？とずっと思っていた。

よって、他のプレイヤーが立ち上がったらやめようというくらいのノリでした。しかしながら競合プレイヤーはなかなか現れませんでした。自分の中では当たり前でも、他業種では当たり前ではないことが多数あることを体感しました。

こんな感じで貸会議室とかでいろいろな側面から計画

実際のところ、「言うは易し行うは難し」という言葉そのもので、実装してみると色々と大変だった。既存業務のリプレイスは要求が多くて大変。

4．プロダクトは自分の手で作る

私の場合は、平日は忙しいので毎週土曜日をこのプロジェクトに使うというスコープで時間を投資していたため、実装を自分でやっているとプロトタイプの完成が遅くなると考えていた。

そこで、設計の重要なところだけを自分で行い、実装は外部に任せるというアプローチをとることにしました。

しかし、いま振り返るとこの意思決定は間違っていました。
会社で開発するのと個人で開発を外注するのは大きな違いがあります。それは予算です。

普通に考えると実装で最低でも300万円ぐらい掛かりそうな内容でしたが、この段階ではこの金額をかけて作り込むほどビジネスプランが作れていないので300万円をかける意思決定はできません。そこで、安く請けてくれる海外のオフショアへ発注することにしました。要件定義、外部設計、内部設計まで私の方で行って実装を依頼しました。

設計書の一例

Cacooで外部設計を書いていた

MySQL Workbenchの内部設計

しかし、最終的に上がってきた成果物は意図したとおりに動かず、動作させるために自分でコードを修正してました。

結局はほとんどのコードを書き直しました。振り返ると、自分でゼロから書いたほうが早かったです。

時間がかかるけど、お金をかけないでやるためにはしょうがないです。自分で書きましょう。biz側にも納得してもらいましょう。納得してくれなければ優秀な人を雇うお金をポケットマネーで出してもらいましょう。時間をお金で買うかどうかという視点で、資金調達をするかどうかの議論が行われました。

記念すべき最初のコミットログを貼り付けておきます。

5．仮説・検証を回しまくる

Thread.new { `一緒にやる仲間を探す` }
while (お金を払っても使いたい会社数 < 5)
  `無料で使ってもらう。`
  `フィードバックをもらう。`
  `修正する`
end

リーン・スタートアップのBuild-Measure-Learnにあたるところです。期間は半年ぐらいやりました。

::amazon{asin="B00F3UTIQY"}

余談ですが、プロダクトを開発し始めた2015年ごろのWebRTCは対応ブラウザが少なく、実装がかなり不安定でした。つらすぎてFlashに変更するか？と何度か考えましたが、結果的にはWebRTCを使い続けて本当によかった。。。今となってはWebRTCを利用しない日は無いくらいに普及しました。

ここでの粘りが、後々の貯金を作ります。運用や会社が走り出したら収支を気にしながら行かなければいけないので、収支を無視してこだわりの実装やリファクタリングをやるならこのタイミングでとことんやっておきます。

そして会社設立へ！

テスト利用をしてもらっていたら、有償で利用してくださる会社が現れました。有償で使ってもらうためには機密保持契約や基本契約書を交わす必要があります。大きめの企業だったので個人では取引のための契約が締結できないので、このときに法人が必要になりました。自社プロダクトのサービス提供を行う場合、実は法人設立は必要になったタイミングぐらいでも良いのです。

脱サラをする際には信用が必要なものは行使しておいたほうが良いと聞きました。会社員でなくなると、銀行が評価する与信枠が減ります。住宅ローンを組む際の金利が優遇されなくなったり、クレジットカードの審査が通りにくくなるとのこと。
特に上場企業勤務×勤続年数が長い場合は、与信枠が多い状態だったりするため、どのタイミングでそのカードを切るかは自分のライフプランも考慮したほうが良いかと思います。

ちなみに、物理オフィスはこの時点では不要だったりします。

まとめ

おっさんエンジニアが若手にアドバイスできることは穴に落ちない方法を伝えることぐらいかと思うので参考にしていただければと思います。
起業後にも今までやったことがないような立ち回りが色々と必要になりますが、嫌でも身に付けさせられるので大丈夫かと思います。
**Minediaでは事業拡大のためエンジニアを募集しています。**まだ数名規模のエンジニア組織のためチャレンジ要素しかありません。一緒に働いてみたい方はこちらをご覧ください。
（サムネは最近お気に入りのzenn.devのOGP画像を参考にしました。）

2020/12/11 Minedia Tech Talk 今週のニュース

Fri, 11 Dec 2020 00:00:00 GMT

はじめに

APIに制限をかける方法
- GCRAはpublicなサービスに良さそう。sidekiq enterpriseが必要かぁ。
- postcode.teraren.comを運用していますが、今は完全にフリー。負荷も問題ないけど何かしら、アプリケーションキーを発行して誰がどのくらい使っているのかは把握したいところではあります。
CentOS終了
- むかしから、RedHatの実験的存在のCentOSが無くなるとのこと。
- 昔はもっとDistributionの統廃合が早かったなぁ。長く持ったほうだと思うし。文句言うならメンテナンスするかお金を集めないと。
Slackで問い合わせ対応
- こういうことやりたいですね。サンプルコードが長い。大変そうです。工数どんぐらいかかったんだろう。
- Slackアプリ化してほしい。
Write code everyday
- すごい。
- githubが全てではないけど、こんな感じ。土日はサボってるのがバレる。

微妙に気になるPCの電気代
- ノートPCなら1カ月使っても数十円レベル
- 安い。。。ありがとう電気。ブロックチェーンのマイニングをしていたときは電気代がすごい高かったけど。。。

おわりに

2020/12/4 Minedia Tech Talk 今週のニュース

Fri, 04 Dec 2020 00:00:00 GMT

はじめに

5G通信

ahamoが爆誕。
- aha mobileの略。MVNOの会社が危機に陥るような。。。
- 先行エントリーをしておけばdポイントを3000ポイントもらえるので、とりあえず登録してみるのが良いです。
- 2021年3月頃からサービス開始予定。
- Work From Homeなのでキャリア課金は最低で良いよね。3GBにしてしまった。キャリアを変えるのってMVNOで簡単にはなったけど、手間がかかるのは事実、なかなかスイッチする気にはならない。
- mineoは遅い。。。
iPhone 12はDual SIMモードで5Gを両方サポートできない。片方は4Gになってしまう。
そして、5Gは低遅延になると言われているけど実際のところどうなるのかが技術的に解説されている記事が話題でした。
- https://highemerly.hatenadiary.jp/entry/real-5g-urllc
- 5Gの真価が発揮できるのはまだまだ先なのでは・・・？
MVNOで5Gが使える業者は楽天モバイル（正確に言うと自社になるかもしれませんが）くらいしかないので安くて5Gが使えるのは良いかも。
それにしても5Gの1基地局のカバー範囲はかなり狭そう。参考資料で、auの2020年末までの範囲。

インフラ

Apple M1プロセッサでDockerが動いたという話。Dockerの中の人がビルドしています。
- https://www.softantenna.com/wp/software/apple-silicon-docker/
Kubernetes 1.20からDockerが非推奨になって、containerdが推奨になるっぽい。
- https://blog.inductor.me/entry/2020/12/03/061329
- Docker内部ではcontainerdが使われていたりするので、よくわからないけど。
- 以下の図がわかりやすい。k8sは赤枠だけしか使っていないとのこと。

PHP8が下位互換性をなくす変更が多数入っているのですんなり移管できなさそう。WordPressも次期リリースの5.6からサポートする様子。その上のプラグインやテーマはその後に対応することになるのだろうな。。。
- https://www.php.net/manual/en/migration80.incompatible.php
- 大きな変更は、評価式の評価方法が変わる。。。。
- create_functionが無くなるなど。

AWS re:Invent 20

まとめ
- https://dev.classmethod.jp/referencecat/aws-reinvent-2020/
- EBSでgp3が登場。gp2よりコスパ良いので普通にmigrateしちゃえば良さそう。
- Aurora Serverless v2ができたとのことだけど、Aurora Serverlessの存在自体を知らなかった。。。計算やIOに課金しているとのことなので稼働率が低い開発環境や突発的にアクセスが来るサイトには良い！
- SageMaker良さそう。機能がかなり増えた。Python＋DSLっぽい。
- CodeGuru使いたい。。。Profilerですね。まずはReviewdogを入れたい。。。。時間が。。。。

監視ツール

サービス監視。フロントエンドからインフラまでワンストップで監視するならDatadog か Newrelic
- Datadogはログの保存が高い！一部だけ保存するようにするなどしないとお金がかかりまくる。
- DatadogのPHP APMは不安定らしい。
- そして、オーバーヘッドはだいたい10%ぐらい増加するっぽい。
- Newrelic Oneという新しいサービスは安くて良さそう。

お知らせ

2020/11/27 Minedia Tech Talk 今週のニュース

Fri, 27 Nov 2020 00:00:00 GMT

アドベントカレンダー

アドベントカレンダーの季節がやってまいりました。
プレゼント付きアドベントカレンダーがあるので、ニッチな分野では当選しやすいと思います。
- https://qiita.com/advent-calendar/2020/categories/sponsor
スポンサーのプレゼント付きアドベントカレンダー自体は、スポンサー付きハッカソンに似てますね。
P&Gでは数日かけてハッカソンを開催しています。大規模すごい。ガチハッカソンです。
- https://prtimes.jp/main/html/rd/p/000000042.000031986.html

コワーキングスペース

名古屋では供給が少ない。東京は逆に供給過多っぽいです。
weworkでは月額39000円で、日本のすべての拠点が使えるキャンペーンをやってます。
- https://www.wework.com/ja-JP/solutions/wework-all-access

拠点が結構増えましたね。

tonariという環境側埋め込みのテレカンシステムが低遅延で良さそう。
- 独自プロトコルです。低遅延といっても数百ミリ秒はあるので中途半端な感じはしますが。
- ネットワークだけなら十数msぐらいのはずなので、テレカンの遅延の原因は、エンコード・デコード処理かなと思うので攻めるところは正しいかもしれないが。イグジットはM&Aか？

Apple M1プロセッサ

Linus「もしLinuxが動くなら、絶対に欲しいです」と発言w
- I'd absolutely love to have one, if it just ran Linux..
- https://gigazine.net/news/20201124-linus-torvalds-linux-m1-mac/
AWSでも同じような流れがある。AWS Graviton2がリリースされて4倍ぐらいコスパが良くなった模様。
- https://developers.cyberagent.co.jp/blog/archives/27782/
- アーキテクチャがx86からarmになるため、既存のx86インスタンスには適用できません。後はサーバソフトの動作確認が取れれば導入していっても良さそうです。完全に置き換えるまでは長い道のりになりそうです。
- t4gのprefixのインスタンスです。

PHP8リリース

PHPのメジャーバージョンリリース。あんまり周辺ではバズってませんが。
- https://www.php.net/releases/8.0/en.php
slackのバックエンドはPHPらしい。
- https://slack.engineering/taking-php-seriously/
- engineeringっていうTLDがあるんですね。かっこいい。
- https://minedia.enginerring/ とか。
- ちょっとお高め

今後

ゲストを招いてできればと思っているので、ご興味ある方は Twitter で @matsubokkuri へフォロー & mentionをお願いします。

お知らせ

2020/11/20 Minedia Tech Talk 今週のニュース

Fri, 20 Nov 2020 00:00:00 GMT

前置き

ニュース

Ruby、jQueryなどの廃れていくOSSを開発している人達はどういう気持ちで日々それらを開発しているんですか？回答するフォロー·9回答依頼
- Rubyオワコン発言にmatzが反応してます。
- まぁ、「廃れていく」という主観的な表現をする場合は背景や意図をしっかり書かないと。。。
中小企業なのにインターン育成に力を入れて大手企業に就職させてしまう会社、一体どうして？と思ったら数年後に秘密があった
- 長期スパンでの人材育成の視点です。
- インターン卒業生がインフルエンサーになる！
8GBメモリのM1版MacBook Airの限界に挑戦！16GBはほとんどの人には必要ないことを検証
- Macbook Pro M1 手元では起動直後に8GBぐらい使われているけど足りるかな。。。
Apple、iPhone 12 miniの「ロック画面問題」をOSアップデートで解消
- iOS 14.2.1 Releaseされました。主にmini対応なのでスルーでもOK。
スクラムガイド日本語版
- スクラムガイドの日本語版がHTMLで出ました！助かります。
成果を出す人がGoogleアナリティクスで使う機能は10個だけ。アクセス解析の実態調査
- Google Analytics内の機能の人気投票結果です。
- 最近、GAが高機能化してメトリックスが多いので重要度が説明されているのは助かります。自分の視点と周りの視点を比較しできます。

今後

手元のMacBook Pro 16inchでGeekBench5してみた結果

Wed, 18 Nov 2020 00:00:00 GMT

背景

1年前に約30万円で買ったモデルで試してみます。M1のベンチマークと比較してどの程度家を見てみます。

ベンチマーク結果

https://browser.geekbench.com/v5/cpu/4803081

CPUの稼働状況

比較

M1のMacbook airの結果が1741，7656なので、負けてますね。
1年前に、個人PCをMacBook Proに買い換えなくてよかったです。

新型コロナウィルス陽性者グラフのFeed

Tue, 17 Nov 2020 00:00:00 GMT

概要

以前、毎日の新型コロナウィルス陽性者数のグラフを投稿するTwitter Botを作ったのですが、神奈川県以外すべてTwitterにBanされました。
プラットフォームに依存するとBanされたときに困るので1次情報源は自分のサイトで運営すべきだと感じたのでWordPressに投稿するようにしました。

今回作ったサイト

https://covid19.teraren.com/

FeedlyでRSS購読した例

都道府県をカテゴリ名としています。購読したいカテゴリのatom feedを購読してもらえればと思います。
東京のRSS例：https://covid19.teraren.com/category/tokyo/feed/
ソースコードはこちら
- https://github.com/matsubo/covid19-daily-tweet/pull/49

2020/11/13 Minedia Tech Talk 今週のニュース

Fri, 13 Nov 2020 00:00:00 GMT

前置き

ニュース

macOSのメジャーアップデートが降ってきた！
- 容量は12GBです。
- https://pc.watch.impress.co.jp/docs/news/1288866.html
M1チップのベンチマークが出てきた
- https://gigazine.net/news/20201112-apple-silicon-m1-benchmark-score/
- エンジニアは最低でも32GB無いと厳しいので、もう少し待ちかも。MBP 16inchが出てくるはず。。。
mac miniでも16GB。メモリがチップに内蔵されているから増設とか無理なのね。(unified memory architectureと呼ぶらしい)
- https://pc.watch.impress.co.jp/docs/news/1288311.html
iMacも新しいのが出たらしい。こちらはIntel
- https://www.apple.com/jp/imac/
Mac製品買い時がわかるサイト
- https://appledays.santalab.me/
gitコマンドノウハウ。ほとんど既知だけど一部は参考になる。
- https://zenn.dev/takuya/articles/7550d21ddd17f121602e
- こういう、結構プロっぽい人の操作動画や録画は非常に参考になる。あんまり出回らないので。そして、shellの見た目が私と酷似しているので親近感ある。
Firebase summitまとめ
- https://nabettu.com/9359dcae953248e0b001046b0b49459c
HomePod miniが良い音だし、音場の制御が賢そう。スモールオフィスに1つ欲しい。
- https://japanese.engadget.com/homepodmini-140005690.html
google chromeにゼロデイ脆弱性
- https://www.gizmodo.jp/2020/11/google-chrome-update-now.html

今後

Ferdiで「Grrr! A pop-up blocker may be preventing...」エラーが出る場合の対処法

Wed, 11 Nov 2020 00:00:00 GMT

症状

Ferdi（メッセージングアプリのアグリゲーター）でGmailを開こうとすると、以下のエラーが表示されてログインできない。

Grrr! A pop-up blocker may be preventing the application from opening the page. If you have a pop-up blocker, try disabling it to open the window.

ポップアップブロッカーの問題のように見えるが、実際にはポップアップとは無関係。

原因

FerdiがGmailにアクセスする際に送信するUser-Agent文字列が古く、Googleがそのブラウザバージョンをブロックしている。1年近く前からGitHubに報告されている既知の不具合（ferdium/ferdium-app、旧getferdi/ferdi#321）。

対処法

Gmailのレシピファイル内のUser-Agent文字列を新しいバージョンに更新する。

1. 設定ファイルを開く

open ~/Library/Application\ Support/Ferdi/recipes/gmail/index.js

2. User-Agent文字列を変更

9行目あたりにあるUser-Agent文字列を、現在のChromeのバージョンに合わせて更新する。

変更後のファイルはこちら: https://gist.github.com/matsubo/3d4bb8c7292f7b7b2daf53d5a818c956

3. Ferdiを再起動

設定ファイルを保存してFerdiを再起動すると、Gmailが正常に表示される。

2020/11/16 Minedia Tech Talk 今週のニュース

Fri, 06 Nov 2020 00:00:00 GMT

前置き

ニュース

5Gエリアが極小。1本のアンテナで半径150m程度っぽい。これは敷設が大変そう。
- http://www13.info-mapping.com/au/map/index.aspx?maptype=5g&l=35.6939457%2c139.7011918&z=6
moment.jsがメンテナンスモード。
- https://devblog.thebase.in/entry/2020/11/05/110000
TLS証明書の期限が短くなる。
- https://ssl.sakura.ad.jp/column/shortened-ssl/
iOS 14.2 released
- https://iphone-mania.jp/news-327009/
標識フォントすごい。。。
- http://kokagem.sakura.ne.jp/font/michishirube/
WSL2すごい。WindowsでもMacと同じ用に開発できるね。
- https://speakerdeck.com/noriyukitakei/wslvscodedocker?slide=98
11/11 apple 新アーキテクチャ発表
- https://k-tai.watch.impress.co.jp/docs/news/1286724.html
- https://www.apple.com/apple-events/
SSG: Static Site Generators
- NextとGatsbyが主流
- Netlify使ってみたい
zenn.devはNext.js
- https://zenn.dev/catnose99/articles/zenn-dev-stack
- すぐ動くことは動く。
  - https://nextjs.org/learn

今後

LVMのファイルシステムをいきなりlvreduceして壊しかけた

Fri, 30 Oct 2020 00:00:00 GMT

概要

online(mount中)のlogical volumeのサイズをいきなり変更したら、ファイルシステムがバグってしまってOSがおかしくなって起動しなくなりました。
そもそもumountしろという感じですが、EC2のEBSはオンラインで容量が拡張できるから逆に縮小もできると思い、実行してみたけど順番が違かった。。。
raidのディスク構成を変更したかったので、830GB位あるlogical volumeを300GBに変更したかったのです。

問題のコマンドはこちら

↓オンライン中に実行してはいけません。

root@dell /h/matsu# lvreduce -L 300G /dev/mapper/dell--vg-root
  WARNING: Reducing active and open logical volume to 300.00 GiB.
  THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce dell-vg/root? [y/n]: y
  Size of logical volume dell-vg/root changed from 834.44 GiB (213617 extents) to 300.00 GiB (76800 extents).
  /etc/lvm/backup/dell-vg.tmp: fsync failed: Input/output error
  /etc/lvm/backup/dell-vg.tmp: fclose failed: Read-only file system
  Backup of volume group dell-vg metadata failed.
  Logical volume dell-vg/root successfully resized.

THIS MAY DESTROY YOUR DATA (filesystem etc.) って書いてあるし。。。。コマンド実行中にもIOエラーが表示されちゃってますね。やばいです。

lvmの構成情報は/etc/lvm/backup以下にバックアップされるのですが、/etc/にすでに書き込めなくなっちゃっているようです。その後はshellがおかしくなり、コマンドが徐々に打てなくなってきたのでrebootしました。

もちろん、rebootしても正常に起動できないのでinitramfsが起動します。fsckを実行しても訂正されることはありません。fsckでチェックする領域は別のようです。

本来の手順

こちらの書き込みでは、以下のように説明されています。

unmountするか、オンラインでやるなら最初にresize2fs（使っているファイルシステムによってコマンドは異なる）などでファイルシステムのサイズを変更する。
logical volumeを縮小する
phisical volumeを縮小する

上記の記事から、認知していないといけないレイヤーの整理をいかに記載します。

ファイルシステム
Logical Volume
Volume Group
Phisical Volume
Partition

今回は、ファイルシステム上では変更前の800GBですが、Logical Volumeがいきなり300GBになったのでおかしくなりました。

復旧へ

Ubuntuのboot diskをUSBメモリに焼いて起動します。
端末を立ち上げて、コマンドを打ちます。

ということで、Logical Volumeを、空き領域に対して全部使うように変更します。

root@ubuntu:/home/ubuntu# lvscan
  ACTIVE            '/dev/data-vg/data' [<3.64 TiB] inherit
  ACTIVE            '/dev/dell-vg/root' [534.45 GiB] inherit
  ACTIVE            '/dev/dell-vg/swap_1' [976.00 MiB] inherit
root@ubuntu:/home/ubuntu# lvresize -l +100%FREE /dev/mapper/dell--vg-root
  Size of logical volume dell-vg/root changed from 534.45 GiB (136820 extents) to 834.45 GiB (213620 extents).
  Logical volume dell-vg/root successfully resized.
root@ubuntu:/home/ubuntu# lvs
  LV     VG      Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data   data-vg -wi-a-----  <3.64t
  root   dell-vg -wi-a----- 834.45g
  swap_1 dell-vg -wi-a----- 976.00m

fsckしてrebootします。

root@ubuntu:/home/ubuntu# fsck /dev/mapper/dell--vg-root
fsck from util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
Clearing orphaned iノード 46935860 (uid=1000, gid=1000, mode=0100644, size=400721)
Clearing orphaned iノード 46932279 (uid=1000, gid=1000, mode=0100644, size=400542)
Clearing orphaned iノード 51380233 (uid=115, gid=125, mode=0100600, size=0)
Clearing orphaned iノード 51381297 (uid=115, gid=125, mode=0100600, size=0)
Clearing orphaned iノード 51381296 (uid=115, gid=125, mode=0100600, size=0)
Clearing orphaned iノード 51380238 (uid=115, gid=125, mode=0100600, size=4563)
Clearing orphaned iノード 17703601 (uid=999, gid=999, mode=0100600, size=0)
Clearing orphaned iノード 17703596 (uid=999, gid=999, mode=0100600, size=0)
Clearing orphaned iノード 17703594 (uid=999, gid=999, mode=0100600, size=0)
Clearing orphaned iノード 17703593 (uid=999, gid=999, mode=0100600, size=0)
Clearing orphaned iノード 17312060 (uid=999, gid=999, mode=0100600, size=0)
Clearing orphaned iノード 17312056 (uid=999, gid=999, mode=0100600, size=0)
Clearing orphaned iノード 17312055 (uid=999, gid=999, mode=0100600, size=0)
Clearing orphaned iノード 17312054 (uid=999, gid=999, mode=0100600, size=0)
Clearing orphaned iノード 15213286 (uid=999, gid=999, mode=0100600, size=0)
Clearing orphaned iノード 15213285 (uid=999, gid=999, mode=0100600, size=0)
Clearing orphaned iノード 15213284 (uid=999, gid=999, mode=0100600, size=0)
Clearing orphaned iノード 15213283 (uid=999, gid=999, mode=0100600, size=0)
Clearing orphaned iノード 12459447 (uid=999, gid=999, mode=0100600, size=0)
Clearing orphaned iノード 12459443 (uid=999, gid=999, mode=0100600, size=0)
Clearing orphaned iノード 12459439 (uid=999, gid=999, mode=0100600, size=0)
Clearing orphaned iノード 12459438 (uid=999, gid=999, mode=0100600, size=0)
Clearing orphaned iノード 18095575 (uid=0, gid=0, mode=0100644, size=776264)
Clearing orphaned iノード 12194905 (uid=999, gid=999, mode=0100600, size=0)
Clearing orphaned iノード 12194904 (uid=999, gid=999, mode=0100600, size=0)
Clearing orphaned iノード 12194903 (uid=999, gid=999, mode=0100600, size=0)
Clearing orphaned iノード 12194895 (uid=999, gid=999, mode=0100600, size=0)
Clearing orphaned iノード 2883690 (uid=104, gid=4, mode=0100640, size=1642249)
Clearing orphaned iノード 2884265 (uid=0, gid=0, mode=0100644, size=339)
Clearing orphaned iノード 51380226 (uid=0, gid=0, mode=0100666, size=0)
Setting free iノードs count to 52970465 (was 53008249)
Setting free blocks count to 172967006 (was 173674078)
/dev/mapper/dell--vg-root: clean, 1719327/54689792 files, 45776802/218743808 blocks
root@ubuntu:/home/ubuntu# reboot

エラーがたくさんありますが、だいたい良い感じに直ったようです。

まとめ

lvresizeでもとに戻して、ちゃんと起動しました。よかった。。。

storcliでraid5からraid6にmigrateできない

Thu, 29 Oct 2020 00:00:00 GMT

ログを書いておきます

physical disk

root@dell /h/matsu# /opt/MegaRAID/storcli/storcli64 /c0/d0 show
Controller = 0
Status = Success
Description = Show Diskgroup Succeeded

TOPOLOGY :
========

--------------------------------------------------------------------------
DG Arr Row EID:Slot DID Type  State BT       Size PDC  PI SED DS3  FSpace
--------------------------------------------------------------------------
 0 -   -   -        -   RAID5 Optl  N  836.625 GB dsbl N  N   none N
 0 0   -   -        -   RAID5 Optl  N  836.625 GB dsbl N  N   none N
 0 0   0   252:0    6   DRIVE Onln  N  278.875 GB dsbl N  N   none -
 0 0   1   252:1    5   DRIVE Onln  N  278.875 GB dsbl N  N   none -
 0 0   2   252:2    7   DRIVE Onln  N  278.875 GB dsbl N  N   none -
 0 0   3   252:3    4   DRIVE Onln  N  278.875 GB dsbl N  N   none -
--------------------------------------------------------------------------

DG=Disk Group Index|Arr=Array Index|Row=Row Index|EID=Enclosure Device ID
DID=Device ID|Type=Drive Type|Onln=Online|Rbld=Rebuild|Dgrd=Degraded
Pdgd=Partially degraded|Offln=Offline|BT=Background Task Active
PDC=PD Cache|PI=Protection Info|SED=Self Encrypting Drive|Frgn=Foreign
DS3=Dimmer Switch 3|dflt=Default|Msng=Missing|FSpace=Free Space Present

volume group

root@dell /h/matsu# /opt/MegaRAID/storcli/storcli64 /c0/v0 show
Controller = 0
Status = Success
Description = None

Virtual Drives :
==============

-----------------------------------------------------------
DG/VD TYPE  State Access Consist Cache sCC       Size Name
-----------------------------------------------------------
0/0   RAID5 Optl  RW     Yes     RWTC  -   836.625 GB
-----------------------------------------------------------

Cac=CacheCade|Rec=Recovery|OfLn=OffLine|Pdgd=Partially Degraded|dgrd=Degraded
Optl=Optimal|RO=Read Only|RW=Read Write|HD=Hidden|B=Blocked|Consist=Consistent|
R=Read Ahead Always|NR=No Read Ahead|WB=WriteBack|
AWB=Always WriteBack|WT=WriteThrough|C=Cached IO|D=Direct IO|sCC=Scheduled
Check Consistency

raid5からraid6に変更したいけどできない

root@dell /h/matsu# /opt/MegaRAID/storcli/storcli64 /c0/v0 start migrate type=raid6
Controller = 0
Status = Failure
Description = None

Detailed Status :
===============

---------------------------------------------
VD Operation Status ErrCd ErrMsg
---------------------------------------------
 0 MIGRATE   Failed     3 invalid arguments
---------------------------------------------

command help

root@dell /h/matsu# /opt/MegaRAID/storcli/storcli64 /c0/v0 start migrate help
     Storage Command Line Tool  Ver 1.15.05 Jan 22, 2015

     (c)Copyright 2015, AVAGO Corporation, All Rights Reserved.

NAME: Start Migration

SYNTAX: storcli /cx/vx start migrate type=raidx [option=add|remove drives=[e:]s|[e:]s-x|[e:]s-x,y] [Force]

DESCRIPTION: Starts Migration on the specified virtual drive to a specified
                raid level

OPTIONS:
raidx - Raid level to which migration needs to be done.
        where x specifies the raid level value.
option -
        add - adds the specified PD to the migrated raid level.
        remove - removes the specified PD from the migrated raid level.
Drives - Specifies the list PD's which needs to be added or removed.
Force - If specified, then Migration will start even if any drive in the DG
        is secured by FDE
CONVENTION:
/cx - specifies the controller where X is the controller index
/vx - specifies the virtualdrive where X is the vd ID

小規模（5〜20人）オフィスのネットワーク構築例

Mon, 26 Oct 2020 00:00:00 GMT

⚠️ 2025年現在の読者の方へ

**この記事は2019年に書かれた内容です。**以下の点に注意してください:

RTX1200は2021年5月に保守終了しました → 現在は使用を推奨しません
新規構築の場合は RTX1300 や RTX1220 をご検討ください
Wi-Fi 6E/7対応のアクセスポイントが主流になってきています
IPv6対応は必須の時代になりました
セキュリティ対策として、ゼロトラストネットワークの考え方が重要になってきています

それでは、2019年当時の構築記録をご覧ください!

背景

株式会社マインディア CTO の @matsubokkuriです。
事業規模の拡大に伴いオフィスの移転がありました。それに伴い社内ネットワークインフラの構築しました。オンサイトで働く人は約 10 名。エンジニアは私 1 名なのでインフラ整備を自分でやるか外注するかという選択でしたが、外注するためには RFP 作るのが面倒だし費用がかかるので DIY しました。
中小企業のネットワーク構築の記事は 5 年前の @wadapさんの記事が詳しいです。その記事以降、まとまった社内LAN構築の良い感じのノウハウ記事を見つけられませんでした。その5年の差分を埋めるためにも記録を書いておきます。

要求定義

ゲスト用ネットワークの分離（インターネット回線、LAN 回線）
- 将来のシステム監査で指摘されるであろうことなので。
- トラフィックの QoS 制御のため。
- インターネット上のホストにおいてグローバル IP アドレスによるアクセス制限がかかっている場合があるため。
役割（部署）毎に LAN の分離
- コンピュータウィルスなどのインシデントが発生した際、被害を限定的にするため。
- QoS 制御のため。
安定
- ストリーミングを扱う自社プロダクトを構築しているので安定性を高める。
- 特に普段遣いをする Wi-Fi は安定してほしい。
Wi-Fi と有線を用意して L1 レイヤの冗長性を確保しておく。
有線 LAN の低遅延と安定性は素晴らしいです。
- ルーターへの ping において、RTT が Wi-Fi では数 ms かかるのに対して有線では 1ms 以内です。
グローバルネットワーク、LAN において低レイテンシー
初期費用、固定費は安く。
20 人ぐらいの同時利用ユーザに対応できる。
- 平均 3 台/人と想定して 60 端末同時接続

要件

ISP は 2 アカウント用意する。社員用の固定 IP とゲスト用。
物理ネットワークの自由度を持たすために VLAN を使う。
Wi-Fi が安定していること。
オフィス外からネットワークに入れる。
各席に有線。

設計

どんな機材を買ってどこに設置するのかを考えるためにネットワークの設計します。

タグ VLAN が絡むと設計書を書くのが難しかったです。物理レイヤ(L1)と論理レイヤ(L2)を同時に考えて 1 つの図にする必要が有りました。これが結構難しかったです。

論理レイヤで考えて、それを物理レイヤに落として。その逆を行ったりと。L1、L2、L3 を行ったり来たりして考えていました。vlan 使わなければ L1 だけ考えれば済むので超楽だなぁと思いました。

VLAN を使わなければ、L1 と L2 は完全に分離して考えられるので非常に簡単ですが、VLAN が絡み出すと難易度がかなり上がります。本来は、論理と物理を分けて考えられて便利にするための VLAN なのに。

一部に VLAN 非対応機器が存在したり、tag, untag を同一ネットワークに混在して設置できてしまうため、論理と物理が混ざってしまう原因でした。

このあたり、想定した動作と各ベンダーの実装が若干違うので検証が大変でした。例えば、ルーターは vlan の設定しかしていないのに、vlan ではないパケットも vlan1 として扱われてしまいます。そうしないと vlan を設定した途端 untag のパケットが到達出来なくなったりするのを回避するためなのかと思います。

どのツールで設計書を書くのが良いのかよくわからないのでとりあえず cacooで設計しました。

次に、図にある各エンティティについて詳細を書きます。

キャリア

フレッツ光ネクストで最高速 1Gbps のプランを使っています。
余談
- 最近評判が良いと聞く NURO 光を検討しましたが導入をやめました。
- NURO 光は個人と法人(Nuro Biz)で内容が全然違います。根本的なところで運営している会社自体が違います。
  - NURO光の個人の利用料は6,000円ぐらい（大人気らしく敷設に2ヶ月待ちとのことで、タイムラインが間に合わず断念）
  - NURO 光の法人(NURO biz)の利用料は月額 20,000 円ぐらい。サポート充実。固定 IP あり。2 個 +6,000 円とかで予算感が合わずに断念。

ISP

Web の管理画面にアクセス制限をつけるために、アクセス元のネットワークによってアクセス制限をしたいというユースケースがあります。それを代替できるアプローチが今のところないので、IPv4 の固定 IP アドレスが必要です。
- サーバサイドからの視点では、やはり IP アドレス制限を入れる事でリスクを L3 以下は気にしないで良くなる利点は大きい
- IPv6 の固定レンジでの割り当てをする ISP はほぼ無い
固定 IP アドレスを提供する ISP は安いしいままで大きな問題が無かった GMO BB を引き続き使います。1,100 円/月（夜 20 時以降は少し遅い感じがします → 遅いので解約して、so-netの固定IPオプションにしました）
ゲスト用のネットワークは適当な ISP で良いので、キャリアと ISP の申し込みを同時にすると安いので適当に選びました。とりあえず IPv6 に対応している so-net にしました。家で使っていたときは下りで400Mbps出ていたので。

ルーター

安く済ますために YAMAHA RTX1200です。10年近く前の機種ですが、1Gbps対応、L2TP対応、SNMP対応など十分な機能です。
定価 125,000 円ですが、保守終わりの中古機材が 7,000円ぐらいで大量に流通しています。保証はないですが、壊れたら買えば良いのです。自宅でも使っていますが2年以上全く落ちませんでした。スループットも1Gbps近くまでは出ます。
IPv6の複数の接続方式に対応するため、新しいモデルである RTX1210をおすすめします。

スイッチ

全部 YAMAHA で揃えて一元管理したいのが理想ですが、いかんせん VLAN 対応の YAMAHA のインテリジェントスイッチは高いです。中古でも出回ってないです。
安い VLAN 対応のスイッチを選択。Netgear GS108eを2台。約5,000円/台
参考のために、8 ポートの YAMAHA SWX2200-8G は実売で約23,000円。Netgear の 4 倍！

Wi-Fi AP（アクセスポイント）

YAMAHA WLX313で。実売約6万円。定価69,800円(税抜)。Wi-Fi AP だけはケチらずに買います。WLC（Wireless LAN Controller）と VLAN にも対応しております。
WLX313 はかなりいろんな機能があって良いのですが、自動制御が不安定です。残念なのですが便利な機能は OFF にしまくってシンプルな設定にして運用する必要がありました。自動チャネル選択、自動出力変更などの便利そうな機能を一通り OFF にしました。
PoE 対応なので、PoE スイッチに接続して使おうしたのですが普通の PoE スイッチでは電源容量が足りなくて動きませんでした。Wi-Fi AP は消費電力が大きいので対応した PoE スイッチを選択する必要があります。
余談
- 市販の家庭用アクセスポイントはよく壊れます。
- コンシューマ向けの Wi-Fi アクセスポイントはすぐに詰まったり、電波飛ばなかったり、不安定な動作が多いです。
- 自宅の AP は 1〜2 年おきに買い換えています。電波は目に見えなくてトラブルシューティングしづらいのでここはケチらず良い物を買いましょう。
- Cisco の meraki も見たのですが、小規模ビジネスでの実績がよくわからないし見た感じ安定性が心配だったので外しました。

LANケーブル

今回は小規模だしケチりたいので自前で行います。自前で圧着するとなったらテスタや圧着器など一式が必要になりますが、今後も使えるので買っておいて良いかなと。いつでも好きなときに好きな長さのLANケーブルを作れるようになります。
楽天などにて 200 円/本で 0.5m から 5m のいろいろな長さの cat6 ケーブルが売っています。自分で圧着する時間を考えると買った方が安います。しかしながら、安い楽天にて買った LAN ケーブルは品質が悪くて断線が頻繁に起きました。
かといって市販のケーブルは 500 円/m とかするので、10 本買うと 5,000 円ぐらいかかったりする。また、長い距離になると 5m 単位や 10m 単位のロットしかなくて配線の余りが出てきてしまいます。なので、自作します。
今回買ったエレコムのLANケーブルは安いのでケーブルの被覆と芯線がとても硬くて扱いづらいです。ローダー付きのRJ45じゃないとコネクタへのケーブルの挿入の難易度高すぎて無理でした。最初はローダー無しのRJ45を買ったのですが、穴に通らなくてローダー付きを書い直しました。

実装

L1

どこに何を通すか設計します。業者からもらった室内の設計図では不十分なので、結局は現況を見てからちゃんと作りました。意外と図面は抽象的なので要注意です。
現場では、図面に載っていない配線があったりしました。天井裏の配線は謎で、ケーブル通しを使って業者と 2 人がかりで捜索し、現場の作業員を勝手にお借りしてケーブル通しを手伝ってもらいました。頭数が 2 人は最低必要な状況でした。
ケーブリングが終わったら、引き継ぎやすいように As-Is を残しておきます。モザイクばかりでよくわかりませんが。

機材の設定は、事前に一通り行って動作テストを行っておくことを強く推奨します。理由は以下です。

初期不良を検出する。
現地はトラブルシュートをするための機材が少ないので、事前に資材や機材の環境が整ったところでトラブルシュートをする。
現地ではインターネットにつながらない場合もあるため。
特に VLAN とパケットフィルタの動作テストには時間がかかります。

動作テストのために 50cm のケーブルをたくさん作る事になって辛かったです。

フリーアクセスなのでカーペットを剥がして床を見て見ると結構堅い締め付けでネジが締められていて、外すのが大変でした。インパクトドライバーが無いと堅くて緩まないので取りに帰りました。

インパクトドライバーでやっと開けられた。

仮に敷設。ケーブルが堅い。

テーブルの上に置けるように、端っこは長めに残しておきます。

床を元通りにして L1 は完了（床を剥がさないで線を通す方法、道具を教えてほしいです。通線で真っ直ぐを引っ張れるのでしょうか？）

L1 の敷設は大変だけど、一般人にはわかってもらえなくて悲しいです。

Wi-Fi Sanner で帯域をチェック。これを見て利用するチャネルを決めます。2GHz 帯は外から回り込んでくるのか、他社のが入ってきます。

電波が届きにくいところや、外への漏れ具合を確認するときには、WiFiミレルを使ってチェックします。PCを持ち歩いてうろうろしないで良いので楽です。

ルーターの設定

RTX1200 の設定の要点をいくつか書いておきます。

4 つの vlan を作ります。

社内リソース用
エンジニア用
biz 用
ゲスト用

vlan lan1/4 802.1q vid=4
vlan lan1/5 802.1q vid=5
vlan lan1/6 802.1q vid=6
vlan lan1/7 802.1q vid=7

次に、どこからどこに何を通したいかを設定します。ネットワーク間は全てデフォルトではpassなので、一旦全てrejectした上で必要なパケットをpassさせていきます。

ルール自体はとても複雑なので、使うか使わないかは別にしてルールは一旦全部作って起きます。その後、このルールをip pp secure filterで適用していきます。

ip filter 600000 reject 192.168.4.0/24 192.168.5.0/24
ip filter 600001 reject 192.168.4.0/24 192.168.6.0/24
ip filter 600002 reject 192.168.4.0/24 192.168.7.0/24
ip filter 600011 reject 192.168.5.0/24 192.168.4.0/24
ip filter 600012 reject 192.168.5.0/24 192.168.6.0/24
ip filter 600013 reject 192.168.5.0/24 192.168.7.0/24
ip filter 600021 reject 192.168.6.0/24 192.168.4.0/24
ip filter 600022 reject 192.168.6.0/24 192.168.5.0/24
ip filter 600023 reject 192.168.6.0/24 192.168.7.0/24
ip filter 600031 reject 192.168.7.0/24 192.168.4.0/24
ip filter 600032 reject 192.168.7.0/24 192.168.5.0/24
ip filter 600033 reject 192.168.7.0/24 192.168.6.0/24
ip filter 600045 reject 192.168.4.0/24 192.168.5.0/24
ip filter 600046 reject 192.168.4.0/24 192.168.6.0/24
ip filter 600047 reject 192.168.4.0/24 192.168.7.0/24
ip filter 600054 reject 192.168.5.0/24 192.168.4.0/24
ip filter 600056 reject 192.168.5.0/24 192.168.6.0/24
ip filter 600057 reject 192.168.5.0/24 192.168.7.0/24
ip filter 600064 reject 192.168.6.0/24 192.168.4.0/24
ip filter 600065 reject 192.168.6.0/24 192.168.5.0/24
ip filter 600067 reject 192.168.6.0/24 192.168.7.0/24
ip filter 600074 reject 192.168.7.0/24 192.168.4.0/24
ip filter 600075 reject 192.168.7.0/24 192.168.5.0/24
ip filter 600076 reject 192.168.7.0/24 192.168.6.0/24
ip filter 600145 pass 192.168.4.0/24 192.168.5.0/24 icmp
ip filter 600146 pass 192.168.4.0/24 192.168.6.0/24 icmp
ip filter 600147 pass 192.168.4.0/24 192.168.7.0/24 icmp
ip filter 600154 pass 192.168.5.0/24 192.168.4.0/24 icmp
ip filter 600156 pass 192.168.5.0/24 192.168.6.0/24 icmp
ip filter 600157 pass 192.168.5.0/24 192.168.7.0/24 icmp
ip filter 600164 pass 192.168.6.0/24 192.168.4.0/24 icmp
ip filter 600165 pass 192.168.6.0/24 192.168.5.0/24 icmp
ip filter 600167 pass 192.168.6.0/24 192.168.7.0/24 icmp
ip filter 600174 pass 192.168.7.0/24 192.168.4.0/24 icmp
ip filter 600175 pass 192.168.7.0/24 192.168.5.0/24 icmp
ip filter 600176 pass 192.168.7.0/24 192.168.6.0/24 icmp
ip filter 600245 pass 192.168.4.0/24 192.168.5.0/24 * 631
ip filter 600246 pass 192.168.4.0/24 192.168.6.0/24 * 631
ip filter 600247 pass 192.168.4.0/24 192.168.7.0/24 * 631
ip filter 600254 pass 192.168.5.0/24 192.168.4.0/24 * 631
ip filter 600256 pass 192.168.5.0/24 192.168.6.0/24 * 631
ip filter 600257 pass 192.168.5.0/24 192.168.7.0/24 * 631
ip filter 600264 pass 192.168.6.0/24 192.168.4.0/24 * 631
ip filter 600265 pass 192.168.6.0/24 192.168.5.0/24 * 631
ip filter 600267 pass 192.168.6.0/24 192.168.7.0/24 * 631
ip filter 600274 pass 192.168.7.0/24 192.168.4.0/24 * 631
ip filter 600275 pass 192.168.7.0/24 192.168.5.0/24 * 631
ip filter 600276 pass 192.168.7.0/24 192.168.6.0/24 * 631
ip filter 610047 pass 192.168.4.0/24 192.168.7.0/24 icmp
ip filter 610048 pass 192.168.7.0/24 192.168.4.0/24 icmp

ipv6の設定。社員用はIPv4のアクセス制限があるので、IPv6の利用はゲストネットワークのみにします。lan1/6がゲストネットワークのvlanです。

ipv6 prefix 1 ra-prefix@lan2::/64
ipv6 lan1/6 address ra-prefix@lan2::1/64
ipv6 lan1/6 rtadv send 1 o_flag=on
ipv6 lan1/6 dhcp service server
ipv6 lan2 secure filter in 200030 200031 200038 200039
ipv6 lan2 secure filter out 200099 dynamic 200080 200081 200082 200083 200084 200085 200086 200098 200099
ipv6 lan2 dhcp service client ir=on
ipv6 filter 200030 pass * * icmp6 * *
ipv6 filter 200031 pass * * 4
ipv6 filter 200038 pass * * udp * 546
ipv6 filter 200039 reject * *
ipv6 filter 200099 pass * * * * *
ipv6 filter dynamic 200080 * * ftp
ipv6 filter dynamic 200081 * * domain
ipv6 filter dynamic 200082 * * www
ipv6 filter dynamic 200083 * * smtp
ipv6 filter dynamic 200084 * * pop3
ipv6 filter dynamic 200085 * * submission
ipv6 filter dynamic 200086 * * https
ipv6 filter dynamic 200098 * * tcp
ipv6 filter dynamic 200099 * * udp

ゲストネットワークのQoSを最初は設定していましたが、ユーザが少ないので撤廃しました。

ゲストネットワークには帯域を100MBpsまでしか割り当てない設定例。

queue lan1 type shaping
queue lan1 class filter list 1 2
queue lan1 class property 1 bandwidth=100M
queue class filter 1 1 ip 192.168.6.0/24 * * * *
queue class filter 2 1 ip * 192.168.6.0/24 * * *

うるさいログをoffにしたり。

ip filter dynamic 200080 * * ftp syslog=off
ip filter dynamic 200081 * * domain syslog=off
ip filter dynamic 200082 * * www syslog=off
ip filter dynamic 200083 * * smtp syslog=off
ip filter dynamic 200084 * * pop3 syslog=off
ip filter dynamic 200085 * * submission syslog=off
ip filter dynamic 200098 * * tcp syslog=off
ip filter dynamic 200099 * * udp syslog=off

とある日のトラフィックはこんな感じです。

スイッチの設定

ブラウザ上で vlan の設定をポチポチとやります。

設定値は以下のような感じです。

安い VLAN 対応スイッチですが簡単な統計は出ます。

Wi-Fi APの設定

周波数と SSID が分離されていて設定しやすいです。このご時世、2.4GHz をオフにしていてもクレームは出ませんでした。

AP の設定は以下のような感じです。VLAN に対応してアクセスポイント名を設定しています。

L1 の敷設です。Wi-Fi AP は上の方に設置して降らせる感じで電波を飛ばすのが良いみたいなので上部に設置します。

壁に穴を開けて、Wi-Fi を設置したところです。ケーブルが露出していて汚いのでモールでカバーをします。

Viva ホームで買ってきたモールです。マルチカッターで切ります。2 秒位でカットできます。

完了した状態です（アンテナの向き地面に対して垂直が正しく、写真の状態は間違い）。

Chromecastを設置

会議室のテレビには Chromecastを設置しました。ゲストネットワークに参加させておきます。
来訪者が Wi-Fi に繋げれば、Windows と macOS からも会議室のテレビをワイヤレスで投影できるので便利です。

設定管理

API で制御は出来ないので、Infrastructure as Code の理想に近づけるためにも設定ファイルをダンプして GitHub で管理。

結果

初期コスト: 約11万円

ランニングコスト: 1万円未満/月

ベンチマーク

Wi-Fi でのベンチマーク

有線でのベンチマーク

IPv6 の設定テスト結果

2019 年 4 月〜2023 年 10 月の 4 年半が経過した現在、問題は 1 度も起きておりません。
1 年に 1 回程度、ファームウェアの更新しているので再起動しています。
Wi-Fi だけで事足りてしまうようで、有線 LAN はほぼ使われていないです。OS のアップデートなどで数百 GB のダウンロードをする際には周りの Wi-Fi ユーザに迷惑をかけないという意味でも有線を使うのが良いです。早く終わるし。

まとめ

オフィスの引っ越しに伴いネットワークを構築しました。
工数は 10 人日ぐらい使いました（キャリア選定、機器選定、L1,L2 設計、施工、設定、テスト、ケーブル作成など）
もし、在宅環境を整備するなら：YAMAHA RTX830 + WLX212 or WLX313を入れておけば完璧かなと。WiFi6はまだ理論値をちゃんと出せるハードウェアが無いので気にしなくて良いかと思います。

docker-compose経由でMySQLのデータをバックアップとリストア

Thu, 15 Oct 2020 00:00:00 GMT

Backup

docker-compose run --rm app bash -c 'mysqldump -u root --password=${MYSQL_ROOT_PASSWORD} -h ${MYSQL_HOSTNAME} --all-databases > dump.sql'

Restore

docker-compose run --rm app bash -c 'mysql -u root --password=${MYSQL_ROOT_PASSWORD} -h ${MYSQL_HOSTNAME} > dump.sql'

背景

Docker for macosを2.4.0にあげて、デフォルトのgRPCがonの状態だとエラーになる。
DBを作り直せば解決される。

[Server] Different lower_case_table_names settings for server ('2') and data dictionary ('0').
[Server] Data Dictionary initialization failed.
[Server] Aborting

Ubuntu 20のサーバにWiFi6導入→なぜか遅い

Tue, 13 Oct 2020 00:00:00 GMT

概要

Ubuntu 19.04でrtl88x2buをインストールの続編です。
以前に買ったWiFiアダプターの謳い文句に「1200Mbps出る」と書いてありますが実際は全然速度が出ません。そこで今回はWiFi6対応のArcher TX3000eを買いました。
しかしながら、ドライバか何かの影響で速度が出ません。

::amazon{asin="B07Y4Z89MR"}

取り付け

PCIeに刺すだけ。サーバの筐体たとステー部分のネジも不要なので簡単に取り付けられて良い。

設定

環境

% lsb_release  -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.1 LTS
Release:        20.04
Codename:       focal

ドライバのインストールは不要でした。さすがIntelのチップが載っているだけある。

iwconfigを打って出てくるこのwlp9s0デバイスが新しく追加したものかと思う。

% lspci|grep AX
09:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a)

% ifconfig
wlp9s0    IEEE 802.11  ESSID:off/any
          Mode:Managed  Access Point: Not-Associated   Tx-Power=22 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:on

nmcliコマンドで設定を打って終わり。

% sudo nmcli device wifi connect 'xxxxxxxx' password 'xxxxxxxx' ifname wlp9s0
% ifconfig
wlp9s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.18  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 240f:78:af46:1:db6e:285e:7642:f9d1  prefixlen 64  scopeid 0x0<global>
        inet6 240f:78:af46:1:7594:3204:f393:98e6  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::d72:face:dbc7:89b2  prefixlen 64  scopeid 0x20<link>
        ether a8:7e:ea:cb:04:f3  txqueuelen 1000  (Ethernet)
        RX packets 748331  bytes 339021359 (339.0 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 43668  bytes 1272545886 (1.2 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

しかし、なぜか遅い！！270Mbpsという表示が出る。。。

WiFi6のAP側は問題ないことはiPhone11との接続で確認しているのでこのデバイスの設定に問題があるのだろうが。。。

追加設定

省電力モードをオフにしておく。

root@dell /etc (master) [128]# git diff NetworkManager/conf.d/default-wifi-powersave-on.conf

diff --git a/NetworkManager/conf.d/default-wifi-powersave-on.conf b/NetworkManager/conf.d/default-wifi-powersave-on.conf
index 23a6889..111af0b 100644
--- a/NetworkManager/conf.d/default-wifi-powersave-on.conf
+++ b/NetworkManager/conf.d/default-wifi-powersave-on.conf
@@ -1,2 +1,2 @@
 [connection]
-wifi.powersave = 3
+wifi.powersave = 2

KDDIが利用を強要するホームゲートウェイ(NEC製)の機能がショボすぎるのでAU光を契約する際は要注意

Thu, 08 Oct 2020 00:00:00 GMT

NEC製 ATERM-875AE1。外箱はおしゃれだけど、中身は低機能。

DHCPサーバのIPv4割当アドレスの数が最大64だけしかありません！65と指定すると「入力範囲外」と表示されて設定できません。大量のノードを運用されている方は、ネットワークを分割するなどの対策が必要になります。

DHCP関連のパラメータはほとんど調整できません。

パケットフィルタや静的NATの設定もとてもやりづらい。。。。

そして、機器自体の発熱が多い！

説明書には、前後左右に排熱用にマージンを開けろと書いてあったので、怪しいなぁと思っていました。

運用しだしたら、案の定、トラフィックが殆どないのにほんのり温かくなります。人肌より温かいので40度は超えています。夏が心配です。

ハードウェアはこれかな。https://www.au.com/support/service/internet/guide/modem/gateway-05/

ATERM-875AE1

隣接して壁などの遮蔽物と接しないように、台座が大きく取られています。しかも、スロープが付いているので重ねることも難しいといういやらしい設計です。

追記：IPv4のルーティングが変

LANで公開しているサーバにアクセスしたら、TSLの証明書エラーが出ました。"kantan.setuzoku.example.com"というホスト名に対して発行された証明書が返答された模様。

一度、携帯キャリアの回線でテザリングをして、再度LANに接続したら正常に戻りました。

表示されるページ

404 Not Found File not found.

Tweet元のアカウントが凍結されているけど、同じ報告を発見

おそらく、ルーターのNAT周りの実装が変になっている様子。。。

NECルーターは10年前にも一定時間でハングアップするという問題があってとてもストレスたまりました。

追記 2020年11月25日

上記のNATの問題に対して、サポートに「このルーターの利用を強要されている身としてはどうしようもないから無料で解約させて」と申し出たら、冷たい反応。

大変恐縮ではございますが、契約期間内でのご解約の場合、

契約解除料7,700円（税込）が発生いたします。

ローカルでDNSサーバ立てるしか無いのか。。。。面倒。DNSサーバを立てたとしてもDHCPのパラメータがいじれないから手動でDNSサーバを設定しないといけない。

それを避けるためにはネットワークをLANで1つ切って、DHCPサーバによるDNSサーバのアドレスを指定できるルーターを使う必要がある。

追記：2021年1月28日

IPv6アドレスならばNATされないので正常にアクセスできます。

IPv6を優先しつつ、自宅サーバはIPv6のアドレスも振れば運用上はカバーできます。

普通のPC起動直後や、IPv6アドレスが振られる前の状態でIPv4しか使えない状態だと失敗するので少し待ったり、WiFiをon/offしたりしてIPv6が優先されるまで待ちましょう。

MegaRAIDのパフォーマンスチューニング

Tue, 06 Oct 2020 00:00:00 GMT

概要

以前買ったDellのサーバにディスクIOが断続的に発生しています。そのたびにSASへのdisk writeが発生してSASのディスクアクセスの音がうるさいです。iotopを見てみると、mysqldの書き込みが多いです。
そもそもSASには重要なデータは保存されていなく、速度優先のデータしか入っていないので安全性を犠牲にして、ディスクアクセスを効率的に行うように設定します。
MegaRAIDの値を調整します。コマンドの資料。

設定の現状確認

root@dell /h/m/.ssh# /opt/MegaRAID/storcli/storcli64 /c0/v0 show
Controller = 0
Status = Success
Description = None

Virtual Drives :
==============

-----------------------------------------------------------
DG/VD TYPE  State Access Consist Cache sCC       Size Name
-----------------------------------------------------------
0/0   RAID5 Optl  RW     Yes     NRWTD -   836.625 GB
-----------------------------------------------------------

Cac=CacheCade|Rec=Recovery|OfLn=OffLine|Pdgd=Partially Degraded|dgrd=Degraded
Optl=Optimal|RO=Read Only|RW=Read Write|HD=Hidden|B=Blocked|Consist=Consistent|
R=Read Ahead Always|NR=No Read Ahead|WB=WriteBack|
AWB=Always WriteBack|WT=WriteThrough|C=Cached IO|D=Direct IO|sCC=Scheduled
Check Consistency

NRWTDと書かれているので、No Write Ahead, Write Through, Directのフラグが立っています。

読み書きを効率的に行うために、Write AheadとWrite Back、Cached IOに変更します。

/opt/MegaRAID/storcli/storcli64 /c0/v0 set rdcache=ra
/opt/MegaRAID/storcli/storcli64 /c0/v0 set wrcache=WT
/opt/MegaRAID/storcli/storcli64 /c0/v0 set iopolicy=cached

その結果、RWTDになりました。

root@dell /h/m/.ssh# /opt/MegaRAID/storcli/storcli64 /c0/v0 show
Controller = 0
Status = Success
Description = None

Virtual Drives :
==============

-----------------------------------------------------------
DG/VD TYPE  State Access Consist Cache sCC       Size Name
-----------------------------------------------------------
0/0   RAID5 Optl  RW     Yes     RWTC  -   836.625 GB
-----------------------------------------------------------

Cac=CacheCade|Rec=Recovery|OfLn=OffLine|Pdgd=Partially Degraded|dgrd=Degraded
Optl=Optimal|RO=Read Only|RW=Read Write|HD=Hidden|B=Blocked|Consist=Consistent|
R=Read Ahead Always|NR=No Read Ahead|WB=WriteBack|
AWB=Always WriteBack|WT=WriteThrough|C=Cached IO|D=Direct IO|sCC=Scheduled
Check Consistency

その結果、Read Ahead Always、WriteBack、Cached IOになりました。

結果

ディスクアクセスが効率的になりました。
グラフはwriteです。

データ保存用のディスクアレイは継続して安全な方向で運用中。

root@dell /h/m/.ssh# /opt/MegaRAID/storcli/storcli64 /c0/v1 show
Controller = 0
Status = Success
Description = None

Virtual Drives :
==============

----------------------------------------------------------
DG/VD TYPE   State Access Consist Cache sCC     Size Name
----------------------------------------------------------
1/1   RAID10 Optl  RW     Yes     NRWTD -   3.637 TB
----------------------------------------------------------

Cac=CacheCade|Rec=Recovery|OfLn=OffLine|Pdgd=Partially Degraded|dgrd=Degraded
Optl=Optimal|RO=Read Only|RW=Read Write|HD=Hidden|B=Blocked|Consist=Consistent|
R=Read Ahead Always|NR=No Read Ahead|WB=WriteBack|
AWB=Always WriteBack|WT=WriteThrough|C=Cached IO|D=Direct IO|sCC=Scheduled
Check Consistency

考察

そもそも、定常的に書き込みが多すぎる。。。iotopではプロセス名しかでなくてどのコンテナのプロセスかがわからない。。。

docker statsでみてみるととあるプロセスのBLOCK I/Oが多いので、書き込みをなくすようにプログラム側を変更して対処して更に一段とディスクIOを減らしました。

スクリーンキャプチャ動画を適当にgifアニにするコマンド

Mon, 07 Sep 2020 00:00:00 GMT

ffmpeg -i input.mov  -filter_complex "[0:v] fps=10,scale=640:-1,split [a][b];[a] palettegen [p];[b][p] paletteuse" output.gif

githubは10MBまでしかアップロードできないので、サイズを減らすためにはfpsやscaleを適当にへらして対応するのが良いです。

サンプルファイル

文字を大きくするか、オプションの画像サイズを大きくするなどの調整は必要そう。

ファイルサイズ：11MB

Instance Schedulerを使ってEC2, RDSの定期停止

Thu, 27 Aug 2020 00:00:00 GMT

概要

平日昼間しか稼働しないお値段高めのインスタンスがあるので節約します。
CloudWatchやLambdaで簡易的に実装されている例がありますが、ステート管理や設定の柔軟さに欠けます。
こちらの設定が良さげです。
- https://docs.aws.amazon.com/solutions/latest/instance-scheduler-on-aws/
- CloudFormationで管理されているのでデプロイが楽
- 曜日、時間、タイムゾーン、リージョンなどの条件を指定して定期的にスタート、停止
- 停止やスタートのステートを保管しているので効率的な実行

設定概要

こちらの設定が十分細かいのでこちらの設定どおりにやる
- https://docs.aws.amazon.com/solutions/latest/instance-scheduler-on-aws/
今回は、sleep-night-and-weekend-ec2 という名前でデプロイしました。

テンプレートの内容

デフォルトではいくつか設定が入っているのでDynamoDBのテーブルを見てみるのが良いと思います。どのようなロジックなのかがなんとなくわかると思います。typeがscheduleになっているレコードが実行される設定です。crontabの行のようなものです。

CloudFormationでのデプロイ後

デフォルトで入稿されているオフィスアワーの設定を更新します。fish用設定

set stack sleep-night-and-weekend-ec2
set aws_profile default
set name office-hours
set region ap-northeast-1
scheduler-cli update-period --name $name --begintime 09:00 --endtime 23:00 --weekdays mon-fri --stack $stack --profile-name $aws_profile --region $region

日本時間での計画停止の設定を入稿します。

set periods office-hours
set schedule jp-office-hours
set description "Office hours in Japan"
set stack sleep-night-and-weekend-ec2
set aws_profile default
set region ap-northeast-1
scheduler-cli create-schedule --stack $stack --name $schedule --periods $periods --description "$description" --timezone Asia/Tokyo --profile-name $aws_profile --region $region

以下のレコードが追加されます。

あとは規定のTagをEC2に打てば終わり。

set instance_id 'i-0d13c9eb8xxxxxxxxxx'
aws ec2 create-tags \
    --resources $instance_id \
    --tags Key=Schedule,Value=jp-office-hours

CloudWatchLogsを確認。デフォルトは5分ごとにこのスタックが実行されるので5分以内にはas-isになります。

ALB+WAF配下でredashのクエリーが実行できない問題を解決

Thu, 20 Aug 2020 00:00:00 GMT

概要

redashにおいて、一部のクエリーが実行できなかったり、保存できなかったりして困っていました。
調べていると、AWSのWAFでブロックされていることがわかりました。
fortinetのOWASP top 10のルールにブロックするようになっていました。

現象

UI上では、クエリーが実行中のように見えますが、通信はサーバサイドから403が返されているので実際には動いていません。
redashのアプリケーションサーバのログレベルをDEBUGにしてもアクセスが来ていなかったので気づきました。

WAFのブロックされた数字を見てみると、ブロックしているアクセスが有ることがわかります。

Fortinet#all_rules#SQL-injection-02というルールにブロックされている

対処

できるだけ、狭く絞って、以下のようなルールをWAFに追加して対処。プライオリティはブロックされるフィルタより先に実行されるようにしておきます。

{
  "Name": "allow-redash-api-access",
  "Priority": 0,
  "Action": {
    "Allow": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "allow-redash-api-access"
  },
  "Statement": {
    "AndStatement": {
      "Statements": [
        {
          "ByteMatchStatement": {
            "FieldToMatch": {
              "SingleHeader": {
                "Name": "host"
              }
            },
            "PositionalConstraint": "CONTAINS",
            "SearchString": "xxxxxxx.xxxxxx.com",
            "TextTransformations": [
              {
                "Type": "LOWERCASE",
                "Priority": 0
              }
            ]
          }
        },
        {
          "ByteMatchStatement": {
            "FieldToMatch": {
              "UriPath": {}
            },
            "PositionalConstraint": "STARTS_WITH",
            "SearchString": "/api",
            "TextTransformations": [
              {
                "Type": "LOWERCASE",
                "Priority": 0
              },
              {
                "Type": "COMPRESS_WHITE_SPACE",
                "Priority": 1
              }
            ]
          }
        }
      ]
    }
  }
}

東京都のCOVID-19新規陽性者をTweetするBot

Thu, 20 Aug 2020 00:00:00 GMT

東京都のCOVID-19新規感染者をTweetするBotを作りました。フォローしてね！
→@covid19tokyoが垢バンくらったので、神奈川県のみ生きてます。

https://x.com/covid19kanagawa

仕様

毎日東京都の新規感染者を調べてチェックするのが面倒なので、プログラムで新規感染者数を集計してTweetするようにしました。
データソースは東京都が公開しているオープンデータです。当日の20時〜23時ごろに更新されます。30分に1回更新を確認しています。

Open Sourceにしました

https://github.com/matsubo/covid19-daily-tweet/

macosでsshfs

Sun, 16 Aug 2020 00:00:00 GMT

概要

PC間のファイルの同期にBoxをずっと使っていますが、ここ数年間CPUを結構消費する感じだったので問題視していました。
過去には、勝手にファイルが削除されたりしてしまってかなり不満でした。Boxの前はDropboxを使っていましたが、そちらも同様の問題があります。
なので、もう面倒ですがファイルサーバをsshでマウントしちゃいます。

設定

$ brew tap homebrew/cask
$ brew cask install osxfuse
$ brew install sshfs

マウント

$ sshfs -o reconnect remote:/home/remote_directory /home/local_mount_point

問題

Createdの日時が保管されない。rsyncで同期してもダメそう。このあたりでも議論されているけど直っていない。

ダイキンのエアコンの効きが悪い問題を設定で解決

Fri, 14 Aug 2020 00:00:00 GMT

概要

1年前に買った20万円ぐらいするエアコンの効きが悪い問題がありました。効きが悪いというと語弊があります。なぜなら、最初はすぐに冷風が出て部屋が涼しくなって快適になりますが、30分ぐらい経つと体感が不快なぐらい暑くなるという問題です。
機種はDAIKINのAN71VRP-W。
これ1台をつけていればマンションの1区分全体が涼しくなるくらいのパワーを持っているので性能が低いとうことは無いはずです。

実験

クーラーをつけてしばらくすると、体感で暑くなっているのは感じますが、それは主観なので、客観的に本当に室温が高くなっているのかを検証するために部屋の温度を計測しました。

測定した結果を以下に貼ります。

設定を変更する前は、涼しい時間が短時間しかありません。エアコンの温度設定を下げてもそれが有効になっている感じがしませんでした。

しかし、設定後は涼しいところで室温が安定するようになりました。

設定内容

エアコン自体はすぐに涼しくなるので、おそらくハードウェアはちゃんと動いていると思ったのでエアコンの設定を見直してみて、色々試してみたら原因がわかりました。

諸悪の根源はこの留守エコ機能などの自動節電機能群。これを「切」にします。

上記以外の「便利な機能」にあたる、自動なんちゃらと書かれている機能はすべてOFFにしました。

そうしたら、室温が設定した温度で安定しました。

去年の夏や冬も同じような問題がありましたが、在宅時間が短かったということもあってあまり気にしていませんでしたが、リモートワークする時間が長くなり、不快に感じることが多くなったのでちゃんと問題を解決しました。

類似書き込み

https://bbs.kakaku.com/bbs/K0001102797/SortID=22904225/

https://review.kakaku.com/review/K0000913724/ReviewCD=1160602/

エアコン自体はいいのですが、ソフトウェア面とかオマケ機能がついているせいで本来の機能を使い切れなくて非常に残念な感じに仕上がっております。

kakaku.comにはエアコンがちゃんと効かないという書き込みが多数見受けられますが、問題はこの便利機能がデフォルトでONになっていることが起因していると思います。

プロダクト開発のEngagement Model

Thu, 13 Aug 2020 00:00:00 GMT

https://emerline.com/blog/engagement-models

What Engagement Model is Right for You?

How to choose the most efficient engagement model to lay a solid foundation for the successful project delivery?

Emerline will tell you about the available options, highlight which one works best for each particular case, and share the team’s approach to technological partnership and other engagement scenarios.

present in INFORMATION_SCHEMA's INNODB_SYS_TABLES table but missing from TABLES table

Wed, 12 Aug 2020 00:00:00 GMT

概要

RDSをmysql 8.0にアップグレードしようとしたらエラー

PrePatchCompatibility.logに以下のようなエラーが出ました。(xxxxxxxはデータベース名)

17) Schema inconsistencies resulting from file removal or corruption
	Following tables show signs that either table datadir directory or frm file was removed/corrupted. Please check server logs, examine datadir to detect the issue and fix it before upgrade
	xxxxxxx - present in INFORMATION_SCHEMA's INNODB_SYS_TABLES table but missing from TABLES table

スキーマ変更中にinterruptしてしまったときにtemporary tableが残る様子。

要らないので消してしまいます。

解決法

https://serverfault.com/a/1002705/556236 を参考に。

mysql> use xxxxxxx;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> drop table `#mysql50##sql-105e_bcd3`;
Query OK, 0 rows affected (0.41 sec)

#mysql50# の部分は、ファイルシステムを参照する特殊な表記。sql-105e_bcd3の部分は以下のクエリーを実行して出力された値です。

select * from information_schema.innodb_sys_tables where name like '%#%';

無くなったかを確認

mysql> select * from information_schema.innodb_sys_tables where name like '%#%';
Empty set (0.01 sec)

余談

アップグレード自体は15分ぐらい。DBの容量は約100GB。

mysql> show variables where Variable_name = 'Version';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| version       | 8.0.17 |
+---------------+--------+
1 row in set (0.01 sec)

OWASP TOP 10のトップ3を解説

Thu, 06 Aug 2020 00:00:00 GMT

概要

OWASPが発表している最新のWeb攻撃手法のことです。2017年時点の内容ですが、2020年時点でもこれらの攻撃手法は現役です。
"Top 10 Web Application Security Risks"。通称は OWASP Top 10
Web SecurityなのでOSI参照レイヤーではレイヤー5から7の話題です。

https://www.infraexpert.com/study/tcpip.html

OWASP Top 10 一覧

Injection
Broken Authentication
Sensitive Data Exposure
XML External Entities (XXE)
Broken Access Control
Security Misconfiguration
Cross-Site Scripting XSS.
Insecure Deserialization
Using Components with Known Vulnerabilities.
Insufficient Logging & Monitoring.

各項目の説明

1. Injection

Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

訳：SQL、NoSQL、OS、LDAP インジェクションなどの欠陥は、信頼できないデータがコマンドやクエリの一部としてインタープリタに送信された場合に発生します。攻撃者が送信する不正なデータは、インタープリタを騙して意図しないコマンドを実行したり、適切な権限を持たずにデータにアクセスしたりします。

原因は、Webのフォームやパラメーターのユーザからの入力データを適切に処理していないときに発生。

脆弱性を含むコードの例

odbc.execute('SELECT id FROM users WHERE email = {email} AND password = {password}', email: params["email"], password: params["password"])

emailに"" OR 1 ORというパラメータが入っていたらすべての認証が通る。以下に例。

SELECT id FROM users WHERE email = "" OR 1 OR 1 AND password = ""'

防ぎ方：静的コード解析(Code sniffer)、コードレビュー、WAF、IDS/IPS

漏洩事例：SQLインジェクション攻撃で個人情報約6万4千件が流出、株式会社釣りビジョン

2. Broken Authentication.

Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.

訳：認証とセッション管理に関連したアプリケーション機能は、しばしば誤った実装をされており、攻撃者はパスワード、キー、セッショントークンを漏洩させたり、他の実装の欠陥を悪用して、一時的または恒久的に他のユーザの認証を不正に入手できます。

原因は、経路が暗号化されていなかったり、URLに認証に使っているセッションIDを露出してしまったりして第三者が認証に使っているキーを手に入れてしまう場合に発生します。

容易にあるケースは、暗号化されていないWiFiアクセスポイントやWEP（脆弱な暗号アルゴリズム）で暗号化されているアクセスポイントでTLSで暗号化されていないサイトにログインする場合。信頼できないVPNやProxyサーバを通したときに漏洩します。

例：とあるサイトでの認証キー

認証されたキーの例

防ぎ方：ペネトレーションテスト、コードレビュー、WAF、IDS/IPS。

3. Sensitive Data Exposure.

Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.

訳：多くのWebアプリケーションやAPIは、金融、医療、PII(Personally Identifiable Information)などの機密データを適切に保護していません。攻撃者は、このような弱く保護されたデータを盗んだり、変更したりして、クレジットカード詐欺や個人情報の窃盗、その他の犯罪を行う可能性があります。機密性の高いデータは、永続データや転送中の暗号化など、より踏み込んだ保護がなければ危険にさらされる可能性があり、ブラウザとのやり取りの際には特別な注意が必要となります。

原因は、適切に転送するデータや保存するデータの暗号化を行っていないことです。

漏洩を防ぐためには、適切な隠蔽が必要になります。クレカ情報を生データで保存することはPCI DSSで禁止されており暗号化が必須です。パスワードの保存に関しては不可逆のハッシュで保存したり、saltという文字列を混ぜることで復元を困難にします。

防ぎ方：設計レビュー、ログ解析、コードレビュー、WAF、IDS/IPS

考察

ちゃんと書き出したらキリが無いのでトップ3だけにします。
対処方法が似たりよったりということに気づいたと思います。Web Securityに関しては、100%絶対防げるという手法が存在しません。なぜならレイヤーが高めなので機械では正常なのか異常なのかが区別が付きづらいケースがあるためです。
脆弱性が起きる勘所を押さえて、できるだけ低レイヤーな部分からセキュアなコーディングをしていくのが良いです。
OWASP Top10はコードレビュアーやシステムの設計者をする人は最低限知らなければいけない内容です。セキュリティを知らなくても正常系は動いてしまうので軽視しがちです。

転職プラットフォームの理想を思考してみる

Mon, 27 Jul 2020 00:00:00 GMT

概要

最近はエンジニア転職サイト多すぎです。50サイトぐらいあるらしいです。

採用する側、採用される側の考えは「全サイトがまとまって1つになってほしい。」

転職メディアがこんなにも乱立していたら、**採用する側も採用される側も手間が増えてしょうがない！**短期的に儲かる市場にプレイヤーが増えるのは必然ですが、過剰供給な感じです。

そもそも理想の採用や転職のモデルってなんだろう？と思ったので考えを整理してみます。

システムを使った単純な採用ユースケース

すごい単純にユースケースを書くとこんな感じです。

システムを使った採用ユースケース

もうすこしユースケースをブレイクダウンしてみます。

昔からある採用メディアはこんな感じです。このシステムが世の中に1個または3個ぐらいしか存在しない世界では両サイドの人はハッピーな状態です。

プラットフォームは乱立することでプラットフォームの価値が減ります。

重要な採用はシステム外で起きている

別の議論にはなりますが、立ち上げ初期のコアメンバー獲得、チーム作成、過去に一緒に仕事がしたことがあってマッチングがぴったりな人を採用するといった重要な採用はシステム外で起きている割合のほうが多い気がします。

システムは登場しないです。デジタル上に情報が上がってこないから顕在化しないというデメリットがあります。

もちろん、それをオンラインに載せた紹介プラットフォームも1つの転職サイトとして存在しています。しかしながら、「紹介する」のトリガーがオンライン上では存在しないのであまり活発ではありません。

オフラインなどで行われているコミュニケーションがトリガーとなって紹介は発生している気がします。それに、トリガーを握っている紹介する人にとっては、オフラインで紹介出来るのにオンラインでやる必要は無いのでワークしません。

次に来るモデル

色々なモデルが試されていて、結構行き詰まっている感はあります。広告、プラットフォーム、pull型、push型、紹介など。

今までにないのは、ゲーミフィケーションぐらいかなと思います。

と思ったら、ありました。テクスカ。

https://scout.techcareer.jp/

スカウトメールを見るとお金をもらえる、知り合いを紹介するとお金をもらえる。面接するとお金をもらえる。プラットフォームとしてはコスト計算が非常に難しいし、集客は大変ですけどもともとアービトラージがあるマーケットなので自走できるようなエコシステムを作ったらワークする可能性があります。

まぁ、すごい冷静に見るとスカウトメールを読む事自体にも時間をとってるし、会社説明を聞くだけでも時間を撮っているのでまっとうかと思います。それがワークするのは採用される側＞採用する側というパワーバランスの時かなと。

マッチングの精度が上がれば、採用される側＝採用する側となるはずなので是正されるかな。でも、あまりPDCAが回りづらいところではあるので難しいかも。

お金の流れは違いますが、使っている技術や機能などはマッチングアプリが類似しているなぁと感じました。Tinderみたいな感じのサイトが登場するのかもしれません。

海外ではLinkedInがメジャーな採用プラットフォームとして稼働しているので日本のような問題は起きないのかなと思います。このような状態は日本マーケットだけなのかな。。。？

楽天モバイルはメイン携帯にもおすすめ（でした）

Thu, 23 Jul 2020 00:00:00 GMT

概要

楽天モバイルのunlimitが良いという噂を聞いたので申し込んでみました。
クオリティが低かったら困るのでサブのスマホ(Google Pixel4)用に買いました。
その結果、予想以上に良いですのでおすすめです！

::amazon{asin="B01MR9JGKY"}

楽天モバイルの概要

既存のMVNO業者とは違い、自社でアンテナを立てている！自社でカバーできないところはMVNOするというハイブリッドな方式。
IPv6に対応！（これ、楽天モバイルだけじゃないかなと思います）

料金表

非常にわかりやすいプラン。これだけ見れば、すごいプランということがわかります。

ベンチマーク

広尾の屋外で、Netflixのベンチマークで計測した結果です。充分早いですね。

申込みはこちらから。300万人対象なのですぐにはなくなりませんが、早めに申し込んだほうがよいと思います。
12時から13時の混む時間や、夕方などの混む時間にも今の所快適です。上記のベンチマークが12時半というピークタイムに取得したにもかかわらず高速通信ができています。

使い方

なんと言っても楽天の自社アンテナが立っている場所ではパケット通信が使い放題です！**＝テザリングし放題！**基本的には都内であれば入ります。
カフェでの作業やアプリのダウンロードは全部この端末で行っています。素晴らしいです。パケ死を気にしながら生活にさようなら。
解約手数料は無料なので、もし自分の使い方に合わなかった場合でも問題なし。金銭的なリスクは無いです。

::amazon{asin="B01MR9JGKY"}

追記 2021/4/14

1年、サブ携帯で使いました。その結果、本当にずっと0円でした。また、最近は新しい料金プランが出ておりまして、利用データが1GB以下なら0円らしいです。サブ携帯に嬉しい値段設定です。

他の月額最低料金が500円ぐらいのSIMに乗り換えようと思っていましたが、しばらく楽天モバイルを使っておきます。

追記 2022/6/1

固定費が0円ではなくなったのでおすすめではない。

auのローミングが減って都市部でもつながらないケースが多数。

Benchmarking ActiveRecord and mysql2

Mon, 06 Jul 2020 00:00:00 GMT

概要

RubyActiveRecordを使う場合と使わない場合におけるベンチマークがWebを探しても無かったので測ってみました。
純粋な比較は難しいので、あくまでも参考値として見ていただければと思います。
比較
- activerecord (5.2.4.3)
- mysql2 (0.5.3)

実験

測定方法

純粋な比較が難しいので、とりあえず1行だけプライマリーキーで1行取得して変数に入れます。
usersテーブルは67カラムあります。
レコードのデータは、文字列に変換すると576バイトです。
実行環境: ruby 2.6.6p146, MySQL: 5.7.29
on Docker on macos.

Activerecordの結果

6.6秒

pry(main)> puts Benchmark.measure { 10000.times { User.find(1) } }
  3.223594   0.814001   4.037595 (  6.624353)

mysql2の結果

3.5秒

pry(main)> puts Benchmark.measure { 10000.times { client.query('select * from users where id = 1').first } }
  1.157955   0.410513   1.568468 (  3.569280)

mysqlコマンドの結果

事前に1万行のクエリーを書いておいたファイルを実行してみました。

2.9秒

% time (cat select.sql | mysql -u root --password=$MYSQL_ROOT_PASSWORD test_database  -h db  > /dev/null)
real	0m2.935s
user	0m0.340s
sys	0m0.529s

まとめ

Google OSSのTsunamiを試してみた

Mon, 29 Jun 2020 00:00:00 GMT

概要

Googleが出した脆弱性チェックツール「Tsunami」を試してみました。

https://x.com/GoogleOSS/status/1273647816242540545

スキャンに15分ぐらいかかります。ターゲットのホストにディクショナリーアタックをかけたり、ポートスキャンをかけたりしています。
セットアップは5分ぐらいで終わります。スキャンには15分ぐらいかかりました。結果のjsonファイルを見ると発見された脆弱性が記載されています。

https://youtu.be/JtVgiPH2TAY

Tsunamiに関する文字の説明はこちら。

余談

Googleのページが消えてます。。。。やはり名前が問題になったのだろうか。。。

2020/7/1 追記

Tsunami Early Warning Systemという意図だったようなのです。名前はそのまま続行しそうです。

https://www.publickey1.jp/blog/20/tsunamiissue.html

I found a vulnerability related to the potential of Zoom Bomb

Mon, 29 Jun 2020 00:00:00 GMT

Abstract

I found a security issue related to the strength of password authentication.
This can be attacked from a remote host and threaten confidentiality and availability of Zoom service.
CVSS score would be 6.5.
- CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L/E:H/RL:O/RC:R

Background

When you create a meeting room in Zoom, a new room ID and password will be generated for you.
It will also generate a URL that contains the room's ID and password information.
By accessing this URL, you will be able to access your meeting room in Zoom . (Example below. URL were valid in past times)

https://zoom.us/j/98459262939?pwd=K1J6VjdFd2NpTWpaenJ6WE0zWml0QT09

The 11 digits represents room ID and the pwd parameter in the query string represents password.
The 98459262939 part is the room ID. It looks like it's probably issued by a sequential number.
The K1J6VjdFd2NpTWpaenJ6WE0zWml0QT09 in the pwd parameter of this URL represents the password.

Issue

This password is made up of a combination of upper and lower case letters and numbers.
The length of the character is 32 characters. Trailing two digits seems fixed.
Therefore, the pattern is (26+26+10)^30. (a-z, A-Z, 0-9)

However, Zoom's server-side processing doesn't make this case sensitive, so there are actually only (26+10)^30 combinations.

It was intended case sensitive but authentication program evaluate case insensitive.

Therefore, it's probably 10^30 times weaker than the cryptographic strength Zoom is assuming.

Recording of the procedure

The procedure in the video

Go to the correct URL
Access the pwd parameter with all the letters capitalized. It should be denied, but the password is accepted.

https://www.youtube.com/watch?v=JPA5hxmEonE&feature=youtu.be

My thought

I sent an email to Zoom's security insident contact, but the contact person didn't understand it, so I wrote it on this blog.
It's a common mistake in implementations. The storage engine (e.g. database) has this password and I believe the string is stored and evaluated by matching the pwd parameter in the URL. However, since the storage engine is not case sensitive, the authentication passes. This is a common mistake at the implementation level.
Even if the cryptographic strength is weakened by a factor of 10^30, it is still strong enough, so this is not a big deal for the security in the most cases.

2020/7/2

This issue has been fixed by zoom after I submitted this report to Zoom.
There is no response from Zoom.

Zoomのパスワード強度に関する脆弱性を見つけた

Mon, 29 Jun 2020 00:00:00 GMT

概要

Zoomにおいてパスワード認証に関連する脆弱性を見つけました。
特徴はリモートから、Zoomのサービスを利用しているユーザに対して、秘匿性に影響する内容です。
自己診断したCVSSスコアは6.5です。
- CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L/E:H/RL:O/RC:R

背景

前提となる知識を説明します。

Zoomにおいてミーティングの部屋を作成すると、新しい部屋のIDとパスワードが生成されます。
また、その部屋のIDとパスワードの情報が含まれたURLも生成されます。
このURLにアクセスすることによってZoomのミーティング部屋にアクセス可能になります。（以下に例。過去の時間に有効だったURLです）

https://zoom.us/j/98459262939?pwd=K1J6VjdFd2NpTWpaenJ6WE0zWml0QT09

98459262939の部分は部屋のIDです。おそらく連番で発行されている感じです。
このURLの後半にある pwd パラメータにあるK1J6VjdFd2NpTWpaenJ6WE0zWml0QT09はパスワードを意味しています。

問題

このパスワードは、アルファベット大文字小文字と数字の組み合わせによっていできています。
文字の長さは32文字です。最後の2桁は固定されている様子。
よって、パターンは(26+26+10)^30個となります。（内訳：a-z, A-Z, 0-9）

しかしながら、Zoomのサーバサイドの処理において、この大文字と小文字の区別をしていないので、実際には(26+10)^30個の組み合わせしか無いです。

よって、おそらくですがZoom社が想定している暗号強度の10^30倍弱い状態になってしまっています。

再現したときの動画

動画内の手順

正規のURLにアクセスします
pwdパラメータの文字をすべて大文字にしてアクセスします。本来は入れないはずですが入れてしまいます。

https://www.youtube.com/watch?v=JPA5hxmEonE

感想

Zoom社のsecurity insident窓口にメールを送ったのですが、窓口の担当者が理解してくれなかったので書いてみました。
実装ではよくある間違いで、ストレージエンジン（データベースなど）にこのパスワードとなる文字列が保存されており、URLにあるpwdパラメータと一致するかで評価していると思います。しかしながら、ストレージエンジンが大文字と小文字を区別しないので認証が通ってしまっていると考えます。実装レベルではよくある間違いです。
暗号強度が10^30倍弱くなったとしてもまだ充分に強度はあるので実質問題は無いと思います。

fail2banを運用するにあたっての設定

Fri, 26 Jun 2020 00:00:00 GMT

fail2ban運用方法

どこからでもsshができるような、踏み台ホストを運用しています。

fail2banを入れているのですが、ほんとアタックが多くて困りますねぇ。24時間で8,998件もBanしています。Banのルールは4回の認証失敗です。

fail2ban件数

次に、現時点のiptablesでのDROPに入っているIPアドレスは114個です。

fail2banによりiptablesで拒否されている件数

無駄なアタックを容認していると、こちらのCPUリソースやネットワークリソースを食うので、止む終えない理由で22番ポートを開放している場合はfail2banのインストールは必須かと思います。

どのくらいアタックが来ているか？

banされたら、メールが来るような設定をしていると、こんぐらいの頻度でアタックが来ています。。。

fail2banのブロックしているホスト数をmackerelでグラフ化

メールの通知がたくさんくるので、1回ブロックしても再度アタックしてくるホストがたくさん居ることがわかります。

ということで、パスワードはミスらないように注意するという運用と引き換えに、1回banをしたら1年間は解除しないように設定しました。

bantime = 31536000 ; 1 year

mackerelのカスタムメトリックでグラフ化するときの設定はこちら。

回線速度を定期的にベンチマーク

Wed, 17 Jun 2020 00:00:00 GMT

概要

インターネット回線速度が時間によってどの程度になっているのかを測定し、mackerelでグラフ化します。
回線速度を測定するスクリプトはこちらに置きました。
- https://github.com/matsubo/speedtest-for-mackerel
speedtestコマンドはOOKLAが公式に出しているコマンドです。aptにデフォルトで入っているspeedtestではないです。

#!/bin/env ruby

require 'json'

# command
# % speedtest --server-id=15047 -f json --progress=no
#
# output
# {"type":"result","timestamp":"2020-06-16T01:07:49Z","ping":{"jitter":120.10299999999999,"latency":27.356000000000002},"download":{"bandwidth":878001,"bytes":10077578,"elapsed":13815},"upload":{"bandwidth":4004130,"bytes":35680876,"elapsed":9131},"packetLoss":0,"isp":"So-net","interface":{"internalIp":"192.168.1.18","name":"wlx0013eff32167","macAddr":"00:13:EF:F3:21:67","isVpn":false,"externalIp":"223.132.34.53"},"server":{"id":15047,"name":"OPEN Project (via 20G SINET)","location":"Tokyo","country":"Japan","host":"speed.open.ad.jp","port":8080,"ip":"202.222.12.78"},"result":{"id":"3aca24d3-cde5-44cb-95e8-6c94bed68b93","url":"https://www.speedtest.net/result/c/3aca24d3-cde5-44cb-95e8-6c94bed68b93"}}

output=`speedtest --server-id=15047 -f json --progress=no`

json = JSON.parse(output)

time = Time.now.to_i
puts sprintf("speed.bandwidth.download\t%d\t%d", json["download"]["bandwidth"], time)
puts sprintf("speed.bandwidth.upload\t%d\t%d", json["upload"]["bandwidth"], time)

/etc/mackerel-agent/mackerel-agent.conf に以下を追加します。

[plugin.metrics.speedtest]
command = "sudo -u matsu ruby /home/matsu/speedtest-for-mackerel/test.rb"
interval = 15

まる1日動かしたときのグラフです。表示はByte/secondです。8倍すればbits/secondです。

IPv4でしか計測できないのが難点です。

応用

回線のlatencyとjitterを計測したグラフ

回線のpacket loss数をカウントしたグラフ。IPv6 tunnelにしてからはとても安定しています。

2020/7/16

mackerelだと粒度が粗いのでGrafanaに移行した。

室内外の温度温度の変化を記録

Mon, 15 Jun 2020 00:00:00 GMT

概要

最近、外は涼しいのに、マンションの部屋の中が暑いと感じるときが多いです。
「暑い」というのは主観的な指標でしか無いので、定量的かつ客観的な数字を取得してみることにします。
「屋外と屋内」に「温度センサと湿度センサ」を設置してみます。

準備

以前に買った Raspberry Pi 4を使いまわします。

Raspberry Pi 4

温度湿度センサはDHT11を買います。精度が10倍高いDHT22はお値段が3倍するためお遊びに2個も高めのセンサを買うのはやめました。

::amazon{asin="B010GXAH4E"}

実装

ハードウェア系の道具は揃っていないので家に有る適当な品物で代用しますので全体的に見た目は良くないです。
まず、Raspberry Pi 4のピン仕様を調べます。

2番ピンの5Vから電源を取ります。3Vでも稼働するらしいですが推奨は5Vとの記述があったので。接地は6番です。

データは7番（IDは4）と8番（IDは14）を利用します。若い順に使ってみます。GPIO4に室内用のセンサ、GPIO14に室外用のセンサを取り付けます。

配線したところはこんな感じです。2つ目のセンサは5mぐらいのVVFケーブルを流用しています。

こちらのDHT11用のPythonライブラリを使って、データを取得、表示します。
その次に、mackerelのカスタムメトリックに流し込めるように、仕様通りの表示形式にします。
- タブ区切り
- 1カラム目はメトリックスの名称
- 2カラム目は数値
- 3カラム目はUNIXタイムスタンプ

mackerel-agent.confに設定を追記します。
そうすると、以下のようにmackerelで表示できます。

温度 on mackerel

湿度 on mackerel

センサの精度が低いらしいですが、同じ場所に設置してみたところ、上記のグラフになったので2つの相対的なズレは大きく無さそうです。

（湿度の方のグラフに差が大きいのは、試しに1m下にセンサを設置した見たからです。下のほうが10%ほど湿度が高いことがわかりました。）

テスト

不快指数もグラフに表示するようにしました。不快指数を求める計算式は以下です。

不快指数DI　（Tは乾球気温℃、Hは湿度％）

DI=0.81T+0.01Hx(0.99T−14.3)+46.3

ついでに設置したCO2濃度のグラフはこちらです。冷房を付けると二酸化炭素濃度が上がります。
使ったCO2のセンサはこちら。

::amazon{asin="B00I3XJ9LM"}

晴れた日のグラフ

湿度は、室内はほぼ一定。外より少し遅れてゆっくりと変化してきている感じです。

温度変化については、室内はほぼ一定、室外は24度から31度へ変化

不快指数は外も中もほぼ一定です。
この日は、部屋の中は別に暑いと感じる気はしませんでした。不快指数は78前後です。
不快に感じる時は別の要因があるっぽいです。

雨が降った日のグラフ

湿度は外のほうが20%ぐらい高いです

温度は4度ぐらい室内のほうが高いです。

不快指数のグラフ
5ポイントほど室内のほうが高いです。部屋の中は特に不快ではありませんが、少し湿度が高いという印象ぐらいでした。

まとめ

晴れのときは、部屋の湿度が高くて不快
雨のときは、室内の温度が高くてやや不快

ということがわかりました

Google SpreadsheetからGoogle Calendarへ一括登録

Tue, 09 Jun 2020 00:00:00 GMT

概要

Google Spreadsheetにある予定の一覧をGoogle Calendarへ一括登録する方法です。
イベントなどの予定をスプレッドシートで一括で作成したうえで、その予定をGoogle Calendarへexportするスクリプトです。

準備

予定の一覧が掲載されるSpreadsheetを準備します。

テンプレをこちらに置いたのでコピーを作成するのが良いと思います。スクリプト内では、行やセルの参照はこのテンプレを基準に書いてあるためです。（テンプレ内のURLやパスワードはデタラメです）

Google SpreadsheetからGoogle Calendarに登録できるようにします。

Google App Scriptをちょろっと書きます

上記のApps ScriptをGoogle Spreadsheetで実行します。

追加されました！

予定の詳細。10分前にリマインダを設定しています。

参考資料

G Suite Pro Tips: how to automatically add a schedule from Google Sheets into Calendar

RTX830のNAPTテーブル、ARPテーブル、DHCPの使用状況をコマンドで取得

Mon, 08 Jun 2020 00:00:00 GMT

YAMHA RTX830はSNMPで取得できない値があるので別途コマンドで取得する

グラフにした結果

arp

dhcp

NAT

session

Mackerelではなく、Grafanaに入れて表示した図

RTX830でv6プラスを設定 (IPoE MAP-E)

Mon, 08 Jun 2020 00:00:00 GMT

環境

建物がVDSLなので100Mbpsまでしかでない。。。
PPPoEだとレイテンシーが遅かったり、ピークタイムでは10Mbps程度しか出ませんでした。
v6プラスに対応するためにはIPoEしかも、MAP-Eに対応した機材が必要だったので比較的新しくて、しかも一部の機種にしか付いていない機能なので以前と同じRTX1200に似たように設定したいのでYAMAHA RTX830を買いました。
ひかり電話は未契約

::amazon{asin="B075YVK9QF"}

IPoE設定前

IPv4は普通のPPPoEです。

http://kiriwake.jpne.co.jp/v/

https://www.speedtest.net/ 深夜に測ったので速度は速いです。しかし帯域は若干不安定な感じのグラフがでています。

Googleのpublic DNSへのpingはだいたいaverage 20ms程度。

IPoE設定後

IPアドレスはプロバイダではなく、ネットワークイネイブラーのIPアドレスになっています。このIPアドレスはNAPTされていて、複数の人によって使い回されています。

帯域のグラフがとても安定しています。速度もPPPoEより少し速いです。

Googleのpublic DNSへのpingが10ms以下に収まっていてWebの閲覧をしている時の反応が良い感じになりました。

番外編

IPv6では100Mbpsきっちり出ることもあります。

また、自宅サーバを運用する場合はMAP-EされたIPv4のアドレスは使えません。（他の人によって共有されているNAPTのホストなので）。よって、残念ですが自宅サーバはPPPoEのIPv4アドレスを使います。

IPoEで固定IPアドレスを振ってくれるサービスがありますが、月に3000円ぐらいするので。。。

自宅の回線をIPv6対応するときに必要になる基礎知識がちゃんと書かれた本

https://x.com/_nhayato/status/1268948054872174594

zabbixでトラフィックを監視

最近思うことは、帯域よりlatencyのほうが重要な感じです。

昨今のアプリケーションはリアルタイム性が求められるユースケースが増えてきました。例えばテレカン、SSH、ゲーム。

動画や音楽はキューイングされるので体感的にはあまり重要ではない気がします。

一般的には帯域が出るってことは、latencyも低いので一緒に扱われてしまいそうです。

::amazon{asin="B075YVK9QF"}

UbuntuにてIPv6のtemporary addressを使わないようにする。サーバ運用なので。

Sat, 06 Jun 2020 00:00:00 GMT

概要

自宅サーバをipv6対応しました。
Ubuntu Linuxを普通に使っていると、ipv6のアドレスは7日で変わってしまう。セキュリティ的な理由で。詳細は：RFC3041
最近、Web上で話題になっていた、ipv6のパケットフィルタリングルールに関する話題にも関連しています。

仕様の調査

IPv6の仕様の一つに、Privacy Extensions for Stateless Address Autoconfiguration in IPv6 (IPv6ステートレスアドレス自動設定のプライバシー拡張)があります。

要するに、IPv6はNATが基本的に存在しなく、グローバルアドレスが直接ノードに振られてしまう事によってサーバサイドから追跡可能になってしまう可能性があるからそれを防ぐために定期的に使うアドレスを変更する技術です。

逆に、勝手にIPv6アドレスが変わってしまっても困るので固定のアドレスと、一時アドレスの2つをNICにアサインして基本的には一時アドレスを使いましょうという方針です。

例えば、macosでは以下のようなIPv6アドレスの表示があり、片方が一時アドレスになります。

ipv6 最初の状態

NICをoffにしてonにするとipv6の片方が入れ替わる（下）

https://ipv6-test.com/ にGoogle Chromeでアクセスすると、この変更されたipv6のアドレスが表示されます。

では、このRFC3041をOSではどのように実装しているかというと、Linuxの場合は以下のパラメータで調整します。

https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

use_tempaddr - INTEGER
	Preference for Privacy Extensions (RFC3041).
	  <= 0 : disable Privacy Extensions
	  == 1 : enable Privacy Extensions, but prefer public
	         addresses over temporary addresses.
	  >  1 : enable Privacy Extensions and prefer temporary
	         addresses over public addresses.
	Default:  0 (for most devices)
		 -1 (for point-to-point devices and loopback devices)

temp_valid_lft - INTEGER
	valid lifetime (in seconds) for temporary addresses.
	Default: 604800 (7 days)

temp_prefered_lft - INTEGER
	Preferred lifetime (in seconds) for temporary addresses.
	Default: 86400 (1 day)

use_tempaddr :一時アドレスを使うかどうか制御。0なら無効、1なら一時アドレスを有効化しますが、パブリックアドレスを優先して使う。
temp_valid_lft: 有効期限（デフォルトは7日）
temp_prefered_lft: 推奨される有効期間（デフォルトは1日）

手元のUbuntu 20で確認してみます。

> sudo sysctl -a|grep -e temp_valid_lft -e  temp_prefered_lft -e use_tempaddr|grep wlx
net.ipv6.conf.wlx0013eff32167.temp_prefered_lft = 86400
net.ipv6.conf.wlx0013eff32167.temp_valid_lft = 604800
net.ipv6.conf.wlx0013eff32167.use_tempaddr = 2

use_tempaddrが2になっています。デスクトップ向けの設定という感じです。サーバならばこれが0か1になるべきです。

では、AWS EC2ではどのように設定されているかを見てみます。

$ sudo sysctl -a|grep -e temp_valid_lft -e temp_prefered_lft -e use_tempaddr|grep ens
net.ipv6.conf.ens5.temp_prefered_lft = 86400
net.ipv6.conf.ens5.temp_valid_lft = 604800
net.ipv6.conf.ens5.use_tempaddr = 0

0になっています。

まぁ、自宅サーバなのでuse_tempaddrは1に設定しておこうかと思います。

設定

matsu@dell ~> sudo sysctl  net.ipv6.conf.wlx0013eff32167.use_tempaddr
net.ipv6.conf.wlx0013eff32167.use_tempaddr = 2
matsu@dell ~> curl https://v6.ident.me/
240b:10:2120:f400:edc1:bcf0:567b:785d

matsu@dell ~> sudo sysctl -w net.ipv6.conf.wlx0013eff32167.use_tempaddr=1
net.ipv6.conf.wlx0013eff32167.use_tempaddr = 1
matsu@dell ~> curl https://v6.ident.me/
240b:10:2120:f400:f93f:c66f:26ff:46e3

設定の永続化をするために以下を/etc/sysctl.confへ追記

net.ipv6.conf.wlx0013eff32167.use_tempaddr=1

一応、ddns-route53の動作確認をします。今までは一時アドレスを使って、これからはpublic addressを使うようになっているかを確認しておきます。

root@dell /v/log# grep ddns syslog|grep IPv6|tail -n 10
Jun  6 13:00:02 dell ddns-route53[110094]: #033[90mSat, 06 Jun 2020 04:00:02 UTC#033[0m #033[32mINF#033[0m Current WAN IPv6: 240b:10:2120:f400:edc1:bcf0:567b:785d
Jun  6 13:00:02 dell ddns-route53[110094]: #033[90mSat, 06 Jun 2020 04:00:02 UTC#033[0m #033[32mINF#033[0m WAN IPv4/IPv6 addresses have not changed since last update. Skipping...
Jun  6 13:00:02 dell ddns-route53[1588297]: #033[90mSat, 06 Jun 2020 04:00:02 UTC#033[0m #033[32mINF#033[0m Current WAN IPv6: 240b:10:2120:f400:edc1:bcf0:567b:785d
Jun  6 13:00:02 dell ddns-route53[1588297]: #033[90mSat, 06 Jun 2020 04:00:02 UTC#033[0m #033[32mINF#033[0m WAN IPv4/IPv6 addresses have not changed since last update. Skipping...
Jun  6 13:30:02 dell ddns-route53[1588297]: #033[90mSat, 06 Jun 2020 04:30:02 UTC#033[0m #033[32mINF#033[0m Current WAN IPv6: 240b:10:2120:f400:edc1:bcf0:567b:785d
Jun  6 13:30:02 dell ddns-route53[1588297]: #033[90mSat, 06 Jun 2020 04:30:02 UTC#033[0m #033[32mINF#033[0m WAN IPv4/IPv6 addresses have not changed since last update. Skipping...
Jun  6 13:30:02 dell ddns-route53[110094]: #033[90mSat, 06 Jun 2020 04:30:02 UTC#033[0m #033[32mINF#033[0m Current WAN IPv6: 240b:10:2120:f400:edc1:bcf0:567b:785d
Jun  6 13:30:02 dell ddns-route53[110094]: #033[90mSat, 06 Jun 2020 04:30:02 UTC#033[0m #033[32mINF#033[0m WAN IPv4/IPv6 addresses have not changed since last update. Skipping...
Jun  6 14:00:02 dell ddns-route53[1588297]: #033[90mSat, 06 Jun 2020 05:00:02 UTC#033[0m #033[32mINF#033[0m Current WAN IPv6: 240b:10:2120:f400:f93f:c66f:26ff:46e3
Jun  6 14:00:03 dell ddns-route53[110094]: #033[90mSat, 06 Jun 2020 05:00:03 UTC#033[0m #033[32mINF#033[0m Current WAN IPv6: 240b:10:2120:f400:f93f:c66f:26ff:46e3

ddns-route53もtemporary addressを使っていたようなので、今回の設定によってpublic addressを使うようになりました。

あと、IPv6のフィルタリングが気になったのでポートスキャンしてみます。

$ nmap -6 240b:10:2120:f400:f93f:c66f:26ff:46e3
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-06 05:09 UTC
Nmap scan report for 240b:10:2120:f400:f93f:c66f:26ff:46e3
Host is up (0.012s latency).
Not shown: 992 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
139/tcp  open  netbios-ssn
443/tcp  open  https
445/tcp  open  microsoft-ds
3000/tcp open  ppp
3001/tcp open  nessus
3003/tcp open  cgms

む。ipv6のフィルタ設定が漏れていたので、ちゃんとfilterをしました。世の中にサンプルとして公開されているYAMAHA RTX系ルータの設定って危険ですね。。。。再テストします。

$ nmap -6 240b:10:2120:f400:f93f:c66f:26ff:46e3
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-06 06:16 UTC
Nmap scan report for 240b:10:2120:f400:f93f:c66f:26ff:46e3
Host is up (0.013s latency).
Not shown: 997 filtered ports
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 4.79 seconds

まとめ

自宅サーバのIPv6アドレスが、長期間変更されないようになりました。

考察

上記の解説をもとにして、こちらの記事を見てみると、この記事内で指摘しているセキュリティリスクを理解できると思います。ブルートフォースで端末のIPv6アドレスを探すのは非常に困難です。

しかしながら、サーバサイドに悪意のあるサーバや途中経路に悪意のあるノードがいる場合は、接続元のIPv6アドレスを知れるのでそこに対してアタックを仕掛けるのは容易になるというリスクがあります。

docker-composeでzabbixを立ち上げ

Sat, 06 Jun 2020 00:00:00 GMT

概要

自宅のYAMAHA RTXルーターのリソースをSNMP経由で取得して集計したりしようかなと思います。
とりあえず、今もZabbixがメジャーっぽいのでZabbixにします。
dockerのイメージがあるので利用して立ち上げます。

初期設定

docker-compose.ymlのテンプレが用意されているので利用します。簡単にコピペでできるような感じで作られていないので少し設定をしていきます。

普通に作ると、以下の9コンテナが立ち上がります。使わないサービスを落としてもよいのですが依存関係が設定されていて外すのが面倒なのでこのまま立ち上げます。

zabbix-docker-compose_zabbix-web-apache-mysql
zabbix-docker-compose_zabbix-proxy-mysql
zabbix-docker-compose_zabbix-proxy-sqlite3
zabbix-docker-compose_zabbix-agent
zabbix-docker-compose_zabbix-web-nginx-mysql
zabbix-docker-compose_zabbix-server
zabbix-docker-compose_zabbix-snmptraps
zabbix-docker-compose_mysql-server
zabbix-docker-compose_zabbix-java-gateway

環境変数を定義したファイルをたくさん用意して、upすれば起動します。

ファイルが沢山あるので以下に置いておきます。

https://github.com/matsubo/zabbix-docker-compose

起動したら、8081番ポートで立ち上がっているWebインターフェイスにアクセスします。

ログインページが表示されたら、デフォルトのアカウントを使ってログインします

ユーザー名: Admin、パスワード:zabbix

起動後の初期設定は以下のURLを参考にして、serverのアドレスやproxyなどを登録しました。

https://hawksnowlog.blogspot.com/2019/06/zabbix42-on-docker.html

こんな感じでRTX830の統計を表示

zabbix自体がCPUとDiskをそこそこ使う感じ。

GitHub ActionsからS3へデプロイ

Thu, 04 Jun 2020 00:00:00 GMT

概要

デザイナーやディレクターが管理する静的ファイルを自動でGitHubからS3へデプロイする設定をする必要が出てきました。
今まではCircleCIでdeployを頑張っていましたが、GitHub Actionsのアセットが揃ってきたので非常に簡単にできるようになっています。
GitHub + CircleCIより、GitHubだけでできるという、ワンストップは設定が集約できて良いです。

設定

最終的に行った設定は、2点だけ。

.github/workflows/main.yml に以下の内容を保存。

レポジトリの、Secretsに環境変数としてAWSの認証情報を入稿します。

実行履歴

注意点

出力ログ

レポジトリには、1つディレクトリを作ってその下に公開するファイルを置くのが楽です。
レポジトリ全体を転送するとなると.gitファイルやREADMEをexcludeする必要が出てきて面倒です。excludeするとなったら、argsに個別設定をする必要があります。
s3-sync-actionは裏でaws s3 syncを使ってはいるものの、差分が無いファイルもアップロードされているようなログが出ているので謎です。

Wi-Fi6を導入してみたら590Mbpsしか出ない

Thu, 21 May 2020 00:00:00 GMT

概要

WiFi6 (IEEE 802.11ax) 対応端末が登場してきたので試してみました。
そもそもWiFi6に対応している端末は、iPhone 11しか持っていないので、あんまり意味は無いですが今後のためということで。
Linux上でのネットワークパフォーマンスを測定するためにはiperf3が良さそうです。iperfのバージョン2もありますが、3だとuplinkとdownlinkを勝手に測定してくれます。
スピード的には大したこと無いような気がします。

Wi-Fi6のアクセスポイント設定

買った機材はこちら。安いし、最近コスパが良いから買いまくっているTP-LINKです。悲しいのは、MAP-Eに対応していないこと。。。。ルーターとしてはあと1歩頑張ってほしい。

::amazon{asin="B0813GJVYK"}

こんな感じでかんたんな統計情報も出ます。

WiFi Explorer Liteで見てみた感じはこちら。設定は基本的にデフォルトです。帯域をかなり占領しております。家の周辺にはWi-Fi 6に対応したアクセスポイントは見当たりません！一番乗り。

テスト

まず、ベンチマーク先であるノードへの有線LANがボトルネックにならないかを確認します。一応理論上WiFi6は現時点で1200Mbps出るらしいので。

Wired Ethernet (1000Mbps)のベンチマーク。実測943Mbpsぐらいです。

参考までに、macbook pro 2019から5GHzのWiFi経由でアクセスした場合は、スループットは上下約165Mbps程度です。（これはこれで。なんか遅いです。L1は混雑している感じはしないので、業務用のちゃんとしたWiFiアクセスポイントじゃないとだめなのか？）

遮蔽物がある、10mぐらい離れた場所では70Mbpsぐらいになってしまいます。

お待ちかねのWiFi6ベンチマーク

では、WiFi6対応のiPhone 11で試してみます。iperf3プロトコルに対応したiPerfというアプリを使ってベンチマークをします。

WiFi6 上り

WiFi6 下り

結果は、上り246Mbps、下り492Mbpsとのこと。測定環境は、アクセスポイントから30cmぐらい離れたところで数回行い、速度が安定していることを確認しました。

まとめ

WiFiがボトルネックとなるような環境では、導入しても良いかと思います。
最近では、インターネット回線が200Mbps以上出るのでWiFiがボトルネックとなる場合が多くなりそうです。

Route 53を使ってDynamic DNS設定（ipv4, ipv6対応）

Wed, 20 May 2020 00:00:00 GMT

概要

自宅サーバをIPv6対応するためにはDynamic DNSを設定しないといけないです。
zoneサーバはAWS Route 53で運用されているのでCLIで書き換えるスクリプトを書くのが面倒だったので長らく放置していました。
ちょっと探してみると、AWS APIをラップしているスクリプトがあったので設定してみました。
- https://github.com/crazy-max/ddns-route53/

Route53の設定

理想の手順

こちらのドキュメントを参考にIAMユーザと、Policyを作成します。

設定ファイルをddns-route53.ymlという名前で作成します。

credentials:
  access_key_id: "YOUR ACCESS KEY"
  secret_access_key: "YOUR SECRET ACCESS KEY"

route53:
  hosted_zone_id: "YOUR ZONE ID XXXXXXXX"
  records_set:
    - name: "teraren.com."
      type: "A"
      ttl: 300
    - name: "teraren.com."
      type: "AAAA"
      ttl: 300

docker-composeのサンプルスクリプトがあるので、docker-compose.ymlというファイル名で作成します。

version: "3.2"

services:
  ddns-route53:
    image: crazymax/ddns-route53:latest
    container_name: ddns-route53
    volumes:
      - "./ddns-route53.yml:/ddns-route53.yml:ro"
    environment:
      - "TZ=Asia/Tokyo"
      - "SCHEDULE=*/30 * * * *"
      - "MAX_RETRIES=3"
      - "LOG_LEVEL=info"
      - "LOG_JSON=false"
      - "LOG_CALLER=false"
    restart: always

そのうえで、docker-compose upを叩けば動きます。

しかしながら、ipv6のアドレスを取得する際にエラーができます。DockerがIPv6に対応していない感じのエラーです。軽くトラブルシュートしてみましたが、ちょっと面倒そうなので諦めました。

> docker-compose up
Starting ddns-route53 ... done
Attaching to ddns-route53
ddns-route53    | Wed, 20 May 2020 09:00:12 JST INF Starting ddns-route53 1.9.1
ddns-route53    | Wed, 20 May 2020 09:00:13 JST INF Current WAN IPv4: 222.230.108.57
ddns-route53    | Wed, 20 May 2020 09:00:13 JST ERR Cannot retrieve WAN IPv6 address error="request failed: Get https://v6.ident.me/: dial tcp [2a01:7e00::f03c:91ff:fe70:xxxx]:443: connect: cannot assign requested address"
ddns-route53    | Wed, 20 May 2020 09:00:13 JST ERR No WAN IPv6 address available to update teraren.com. record
ddns-route53    | Wed, 20 May 2020 09:00:13 JST ERR No WAN IPv6 address available to update *.teraren.com. record
ddns-route53    | Wed, 20 May 2020 09:00:14 JST ERR Cannot update records set error="InvalidInput: Invalid XML ; cvc-complex-type.2.4.b: The content of element 'Change' is not complete. One of '{\\"https://route53.amazonaws.com/doc/2013-04-01/\\":Action, \\"https://route53.amazonaws.com/doc/2013-04-01/\\":ResourceRecordSet}' is expected.\\n\\tstatus code: 400, request id: 6a21c50f-4f3e-4a0b-b588-62ddb890ed66"
ddns-route53    | Wed, 20 May 2020 09:00:14 JST INF 6 records set updated changes={"ChangeInfo":null}
ddns-route53    | Wed, 20 May 2020 09:00:14 JST INF Cron initialized with schedule */30 * * * *
ddns-route53    | Wed, 20 May 2020 09:00:14 JST INF Next run in 29 minutes (2020-05-20 09:30:00 +0900 JST)

しかたがないので、ddns-route53をbinaryでインストールして、daemonとして設定しました。

※オプション

daemonとして稼働させるよりcrontabのほうが楽かなと思いました。

*/30 * * * * /usr/local/bin/ddns-route53 --config /path/to/ddns-route53.yml

外部からテスト

> host matsu.teraren.com
matsu.teraren.com is an alias for vectant.teraren.com.
vectant.teraren.com has address 121.3.155.147
vectant.teraren.com has IPv6 address 240b:10:2120:f400:4167:4cee:9d38:6125

Work From Homeのこのご時世、IPv6対応してないと遅くて辛いですね。

IPアドレスが更新されて、非定期的に更新したいとき

デーモンで動いているので、デーモンを再起動すればOK

$ sudo systemctl restart  ddns-route53

Ubiquiti Networks Edgerouter ER-X設定

Tue, 12 May 2020 00:00:00 GMT

とりま、最初に入っていたファームウェアが古すぎなので、最新を入れるところからやります。

https://www.ui.com/download/edgemax/default/default/edgerouter-er-xer-x-sfpep-r6er-10x-firmware-v208-hotfix1

そして、MAP-Eに対応していないことが判明したので設定を中止しました。良い製品なのに惜しい。現在利用中のルーターがRTX1200なので速度や機能は同程度なのでEdgerouterの設定は見送り。

::amazon{asin="B010MZFH5A"}

テレカン環境のセルフチェックポイント

Mon, 11 May 2020 00:00:00 GMT

概要

自分の動画と音声が相手に高品質に届く状態にあるかどうかをセルフチェックするための項目です。
zoom, whereby, Skype, Google Hangout, Teamsなどで汎用的に使えるスキルです。
macOS前提での解説ですが、同じような設定がWindowsにもあります。
(社内LT用の記事)

評価する指標

PC

CPU処理速度
物理メモリ

wherebyやGoogle HangoutはWebRTCを使っており、今の所ハードウェアエンコーディングを使えないので、エンコードとでコードの処理にGPUではなくCPUを使ってしまう。

アクティビティモニタで、CPUの使用率の変化をグラフで観察します。

どのくらいCPUを使うかというと、320 x 240の動画、音声ストリームを8つを開いたときの状態です。（2.4 GHz 8-Core Intel Core i9という速いCPU）

マイク

ピンきりです。100円〜5万円
Youtuberやpodcastが流行ったので、「youtube liveオススメマイク」とかで検索するとたくさん出てきます。
Youtubeにレビューが沢山掲載されています。コロナ前なので紹介されていても入手が困難です。
USB2.0とUSB3.0では、周波数特性の違いからノイズが乗ることがあるらしいので、USB2.0は2.0で接続する必要がある。

EarPodsのマイクはなにげに優秀。
https://www.apple.com/jp/shop/product/MNHF2FE/A/earpods-with-35-mm-headphone-plug

サンプリングレートを見るのは重要！

https://web.liveon.ne.jp/glossary/sampling_rate/

純粋にマイクや録音環境をテストするためには、自分で録音してみます。
ホワイトノイズの乗り方、音量の大きさが確認できます。

Bluetoothのヘッドフォンの場合、マイクの品質を重視していない場合が多いのでとてもサンプリングレートが低い場合がある。8kHzとか。
Bose QC35 bluetoothヘッドフォンの場合は、16kHzに固定されている。
- CD: 44.1kHz, 電話: 8kHz

ソフトウェアでノイズキャンセリングをできます。
- https://ref.krisp.ai/u/ud40cc5747?utm_source=refprogram&utm_campaign=219011&locale=en-JP
- krisp、まじすごいです。キーボードの打鍵音とか環境音が一切消えます。普通、救急車とかが通ると絶対拾ってしまうのですがそのような音を綺麗に消してくれます。
- 一度使ったら手放せません。というか、相手に不快な音を届けないためのエチケットと考えてます。

スピーカー・ヘッドフォン

ハウリングを防ぐために、ベストはヘッドフォンの組み合わせです。
指向性マイクを使っていたり、マイクとスピーカーが遠かったり、ハウリング防止ロジックが効いていれば近くても良いです。

カメラ

FPS
- 1秒間に何コマ撮影できるか
解像度
- どこまで細かく映像を撮れるか
ホワイトバランス
露出

回線の品質

回線の品質
- latency
- bandwidth
- IPのversion

https://www.speedtest.net/ はIPv6に非対応なのでおすすめしません。お勧めはNetflixが運営しているfast.comかCloudflareです。

fast.com

https://fast.com/

Fast.comならば、IPv6, IPv4に対応しています。CloudFlareのベンチマークもIPv6, IPv4対応でいろいろな指標が出て良いのですが、遅いです。

Cloudflare

https://speed.cloudflare.com/

ページを開いて、しばらく放置すると色々な計測が行われます。回線の帯域に対してスロースタートで始まっていくので、完了まで時間がかかります。

一通り完了したら、真ん中辺にある「Network Quality Score」の部分を見てもらうとサマリーが掲載されています。最高の場合は、Greatと表示されるはずです。

ベンチマークでは一時的な情報しかわかりません。テレカンをしているときに、テレカンが不安定になった場合は逐次、自分の状態を知る必要があります。

そのときに、いちいちアクティビティモニターを開いていては時間がかかったり、粒度が荒かったりするので原因分析をすぐに行うことが難しいです。なので、私はiStat Menusを使っています。

iStat Menus

ネットワーク帯域

より高品質を求めて

テレカン映えを狙って。
ライティング
- ダイナミックレンジ
- 光源

https://rocketnews24.com/2020/04/09/1356841/ https://www.instagram.com/p/B-tnyXAJrjB/?utm_source=ig_web_copy_link

その他の参考資料

Netflixが説明する吹き替え環境の説明書
- よくまとまっています。
- さすがプロクオリティを目指しているだけあって、推奨する機材が高価です。

iPhoneの高画質カメラをWebカメラとして使う(無料)

Sun, 10 May 2020 00:00:00 GMT

概要

リモートワークが増えてWebカメラやPCの内蔵カメラを使う機会が増えました。しかしながら、Macbook Proの内蔵カメラの解像度は1024 x 720ピクセルなので解像度が低いです。（まぁ、テレカンには問題無いかと思いますがちょっと解像度が高いテレカンシステムの場合は見劣りします）
以下にサンプル画像。FaceTimeで表示して拡大した画像です。

それに比べ、iPhone 11 Proのカメラは、2,436 x 1,125なので解像度は4倍になります。
NDIが公開しているソフトを使うとiPhoneのカメラをPCの入力として扱えるようになり、カメラの入力として使えるようになります。
以下、サンプル。

Amazonや家電量販店ではWebカメラが売り切れたり、高騰しているのでiPhoneを流用できるととても良いです。しかも無料。

NDIとは？

NDI(ネットワーク・デバイス・インターフェイス)は、インターネットプロトコル経由による映像伝送(ビデオオーバーIP)テクノロジーのひとつとして、NewTek社が開発し提唱しているテクノロジーです。NDIを利用することにより、SDIなどの映像ケーブルを使用せずに、一般的なギガビットイーサネット環境においても、映像、音声、メタデータをNewTek社製品TriCasterやIPシリーズなどのシステム間のみならず、NDI互換のさまざまな他社製システム、デバイス、PC間においても、高品質、かつ超低遅延で、複数のピデオストリームの相互伝送を可能とします。

https://rental.pandastudio.tv/blog/ndi/

使ってみた感じ、本当に低遅延でmDNSで名前解決もしてくれるし、使い勝手が良いです。プロトコル自体が汎用なので様々なアプリケーションの登場が期待されます。

応用をするとプラグイン（obs-ndi）を入れることでOBS Studioの入力ストリームの1つとして扱えたりもします。

NDI was developed by NewTek, and is available to anyone with a royalty-free license. NewTek has an SDK available for Windows, Linux and macOS.[1] NDI has also been ported to iOS, tvOS[2], Android, Raspberry Pi, and FPGA.[3][4]NDI is designed to run over existing Gigabit networks,[5] with the NDI codec[6] expected to deliver 1080i HD video at VBR data rates typically around 100 Mbit/s.[7]

https://en.wikipedia.org/wiki/Network_Device_Interface

やりかた

Windowsの場合はこちらが参考になると思います。

インストール

iPhone側

iPhoneのカメラをPCのカメラ入力として使う場合
- NDI®|HX Camera
- https://apps.apple.com/us/app/ndi-hx-camera/id1477266080?ls=1
iPhoneの画面をPCのカメラ入力として使う場合
- NDI HX Capture 4+
- https://apps.apple.com/us/app/ndi-hx-capture/id1501247823
- ただし、2020/5/10 時点ではうまくビデオ入力として動かないです。映像のモニタリングはできるのでmacos側のドライバの問題な感じがします。

PC側

NDI® Tools for Macをダウンロードします。ダウンロードの際にメアドが求められます。

https://ndi.tv/tools/#download-tools

ファイルを展開して、Driverをインストールします。再起動が求められるので再起動します。

そうすると、NDI Videoとうカメラ入力と、NDI Audioという仮想の入力デバイスが追加されます。

手軽に試すためにはWherebyとかを立ち上げて、ビデオの入力を選択してみます。

スマホを立てるための三脚はこちらがおすすめです。

三脚

::amazon{asin="B00GUNBNOS"}

スマホホルダー

::amazon{asin="B0169SORDW"} https://www.facebook.com/ittriathlon/posts/1561806380644613

OBSでpicture in pictureをしてみるとこんな感じで写ります。カメラの撮影位置の自由度が上がって良いですね。

https://youtu.be/8YTBbmtJE3c

Vonage (TokBox)のドキュメントに載っていないこと

Wed, 06 May 2020 00:00:00 GMT

2020/5/6

Session inspectorとArchive inspectorはそのセッションの20日後に見られなくなる。Advanced Insights ($500/month)を契約しても同じ制限。

Q: It seems I can see the data on the session inspector and archive inspector within a month after the events are happening. Is that correct? When does the information expire on the inspectors?

Ans: Data on session inspector can be found only till 20 days from day session has been conducted i.e. it expire after 20 days.

Q: If we use Advanced Insights ($500/month), the data never expires?

Ans- No, on session inspector it still show data for that particular session, till 20 days from the day session is conducted.

Web上の時間表記はすべて現地時間に統一されている

Ans: Yes, Tokbox uses local time in all it's tools.

Sentryでreleaseと紐付けたエラートラッキング

Sat, 18 Apr 2020 00:00:00 GMT

概要

2019年末ごろに、Sentry上のエラーとリリースを関連付けられる機能が付いていました。
これにより、エラーとリリースの関連付けができるようになります。
基本的にこのページの内容を踏襲してCircleCIにてdeployが終わった後にSentryに通知するように設定してみました。

コード

.circleci/config.ymlの抜粋です。
CircleCIのWorkflowを使っている場合はサンプルコードをそのまま使えないので、色々変更しています。
SENTRY_AUTH_TOKENをCircleCIの環境変数に設定しておく必要があります。

version: 2.1
commands:
# <snip>
  sentry_setup_create_release:
    steps:
      - run: |
          curl -sL https://sentry.io/get-cli/ | bash
          export SENTRY_RELEASE=$(sentry-cli releases propose-version)
          sentry-cli releases new -p $SENTRY_PROJECT $SENTRY_RELEASE
          sentry-cli releases set-commits --auto $SENTRY_RELEASE
          sentry-cli releases finalize $SENTRY_RELEASE

jobs:
  create-sentry-production-release:
    docker:
      - image: circleci/node:latest
        environment:
          SENTRY_ORG: <YOUR_ORGANIZATION>
          SENTRY_PROJECT: <YOUR_PROJECT_NAME>
          SENTRY_AUTH_TOKEN: ${SENTRY_AUTH_TOKEN}
    steps:
      - checkout
      - sentry_setup_create_release

  create-sentry-development-release:
    docker:
      - image: circleci/node:latest
        environment:
          SENTRY_ORG: <YOUR_ORGANIZATION>
          SENTRY_PROJECT: <YOUR_PROJECT_NAME>
          SENTRY_AUTH_TOKEN: ${SENTRY_AUTH_TOKEN}
    steps:
      - checkout
      - sentry_setup_create_release

workflows:
  version: 2
  build-deploy:
    jobs:
    # <snip>
      - create-sentry-production-release:
          requires:
            - deploy-production
          filters:
            branches:
              only: master
    # <snip>
      - create-sentry-development-release:
          requires:
            - deploy-development
          filters:
            branches:
              only: develop

CircleCI上でbuildが成功すれば以下のような表示になります。実行時間は16秒。

Sentry上での表示は以下のような感じになります。

エラーが無いからわかりませんがリリース後に出たエラーはここに表示されるようです。便利！

Next step

このあたりをやって、JavascriptのSDKからもバージョンを送る必要があるっぽい？

https://docs.sentry.io/product/releases/

CloudWatchからSNS経由でSlackへ通知

Fri, 17 Apr 2020 00:00:00 GMT

概要

CloudWatchのアラームをSlackへ通知します。
CloudWatch => SNS => Lambda (with KMS) => Slack webhook という流れ。

Blueprint通りに設定すればほぼ動きますが、一部ちょっと変更が必要だったのでメモっておきます。

Blueprintはこちら。cloudwatch-alarm-to-slack-python

AWS lambdaのコード

変更後

Blueprintからの差分

https://gist.github.com/matsubo/43cd5d1604bf49a71127402d2c93ba9e/revisions#diff-a545a08261d6fdc75c70060cdd64f452

テストのために、CloudWatchのイベントテンプレがあるのですが、そちらとの整合性も取れていません。CloudWatchのイベントを少し変更します。変更後のファイルはこちら。

AMIのredashでPythonをデータソースとして追加する

Thu, 19 Mar 2020 00:00:00 GMT

弊社のスーパーインターンのご所望により。

設定方法は以下。（このあたりを参考にしました）

コピペで行けるはずなのですが、一応1行1行実行するのが安全です。redashのバージョンは最新のv8.0.0です。

sudo -s
cd /opt/redash
echo 'REDASH_ADDITIONAL_QUERY_RUNNERS=redash.query_runner.python' >> env
docker-compose restart

上記の設定後、Data Sourceとして追加します。

Pythonのバージョンは

% docker exec -it redash_server_1 bash
redash@b7b972738c0f:/app$ python --version
Python 2.7.16

4万枚400GBの写真を自動で安全にバックアップ。AWS Glacierで6ドル/年

Tue, 17 Mar 2020 00:00:00 GMT

概要

写真のバックアップを安価で安全に保存したいと10年ぐらい前からぼんやりと考えていました。
この記事では、やっと満足の行くバックアップ方法を実現したので共有します。
ファイルサーバをLinuxにしたことで柔軟なワークフローを構築できました。
プロ写真家の場合は、この記事に書いてあるバックアップの期間の単位を1段階粒度を細かくして設定するとより頻度を高められて安全になると思います。

私の写真ファイル保存ワークフロー

私の写真の使い方をまとめておきます。

月に1回ぐらい、デジタル一眼レフカメラでRaw画像で撮影。データはカメラに挿入しているXDカードに保存。
XDカードからLightroom経由でローカルPCに転送し、レタッチ、現像。
- 良さそうな写真は現像してGoogle Photo, Facebook, iCloudなどにアップロードして共有。
Lightroomからファイルサーバのディレクトリをsmbまたはsshfsでマウントして、Rawファイルをファイルサーバに移動
過去の写真が見たくなったら、ファイルサーバをマウントしてLightroomから参照する。

このワークフローで問題になるのは、ファイルサーバ自体がリスクヘッジされていないのでサーバ自体の物理セキュリティ（火事や地震など）が確保されていないことです。このファイルを地理的に遠い場所に安全に保管しておきたいです。

現状のファイルの傾向分析

matsu@dell ~/d/lightroom> find . |wc -l
41176
matsu@dell ~/d/lightroom> du -hs
413G    .

4万1,176枚、413GB。

ストレージ料金比較

オンラインストレージにてファイルを400GBを保存する場合で試算してみます。

Google One
- ¥13,000 / yearかかります
AWS S3
- S3にstandardで保存すると$10/monthほどです。年に$120, 10年で$1200ドル。
AWS S3 Glacier Deep Archive
- 400GBだと$0.5/monthぐらい、年に$6、月に$0.5、10年で$60。
- 保管と復元がAPIやCLI経由。
- 復元に時間を要する。（だから安い）
Prime Photo
- Raw画像の保管が容量制限無料で利用できるので良いです。CLIからもファイルを転送できるのでいい感じなのですが、いかんせん復元の際にディレクトリ構造を維持できなかったりして復元したときが面倒そう。
- API、CLIでアクセスできなさそうなので、1つ別のストレージアグリゲーションサービスを経由しての利用になるので面倒。

選定先のストレージは**2nd tierのバックアップストレージなので、Availabilityを犠牲にしても安さと利便性が重要です。**なので、GlacierのDeep Archiveが良さそうです。

注意しないといけないのは、GlacierへのPutやGetのオペレーションごとに課金される点です。また、バックアップの際はS3のインターフェイスと同じで簡単に行なえますが、取り出すときにはファイルごとにアーカイブの取り出しをいわなければ行けないので、やや面倒なコマンドを打っていかなければ行けないです。例えば40,000ファイルを復元したければ、40,000回オペレーションが必要になります。$0.05 per 1,000 requestsなので$2かかります。なので、ある程度の塊にして置いたほうが取り出すときに楽そうです。

S3のリージョンは、地理的リスクをヘッジするために海外を選びます。今回は、N. Virginiaにしました。

Lightroomのファイルを管理するディレクトリは年、月、日の階層でファイルを保存してくれているので固めやすいです。

上記を踏まえての構成図

my photo workflow plan

運用案

1年分の写真を固めて、1ファイルにしてGlacier Deep Archiveに入れる。
しかし、当年分はアーカイブとして固められないので、当年は、月に1回s3にRaw画像のファイルを同期（sync）する。
年が明けたら、去年分の全ファイルを固めてGlacier Deep Archiveに入れる。

実装

まず、過去分の写真を1年ごとに固めて、Glacierに入れます。S3のPUTは無料なので容量に気にせずに気軽にPUTできます。

rawファイルを含んでいるので、ただのtarではなく、圧縮をかける必要があります。本来なら解凍する事は無いはずなので圧縮率を最高にしても良いですが、保管コストは安いのでbzip2をデフォルトで使います。

普通にbzip2を使うとシングルコアしか使われず、CPUがボトルネックになります。そこで、pbzip2を使ってマルチコアで圧縮します。bzip2で圧縮しても10%弱しか容量は減らないので、tarで固めるだけで良かった気がします。

pbzip2で圧縮中

#!/bin/bash

set -eu

cd <data directory>

for YEAR in `seq 2003 2018`; do
  tar -I pbzip2 -vcf $YEAR.tar.bz2 $YEAR
  aws s3 mv  --storage-class DEEP_ARCHIVE $YEAR.tar.bz2  s3://<bucket name>/lightroom/
done

転送中

毎月実行

crontab例

0 5 1 * *  bash /path/to/backup_monthly.sh >> /var/tmp/backup.log

#!/bin/bash

set +eu

cd <data directory>

YEAR=`date +%Y`
echo aws s3 sync ${YEAR}/  s3://<bucket name>/lightroom/${YEAR}/

毎年実行

年が明けて、早めの段階で去年の写真をまるごと固めてGlacierに入れます。そして、去年のs3 syncで毎月とっていたバックアップファイルを消します。

crontab 例

0 6 1 2 *  bash /path/to/backup_yearly.sh >> /var/tmp/backup.log

#!/bin/bash

set +eu

cd <data directory>

LAST_YEAR=`date --date=last\ year +%Y`

# archive last year
tar -I pbzip2 -vcf $LAST_YEAR.tar.bz2 $LAST_YEAR
aws s3 mv  --storage-class DEEP_ARCHIVE $LAST_YEAR.tar.bz2  s3://<bucket name>/lightroom/

# delete last year
aws s3 rm s3://<bucket name>/lightroom/${LAST_YEAR} --recursive

気になるお値段

バックアップ
- S3への転送は無料。
運用
- $6/400GB/年
取り出し
- 取り出し料が標準(数時間)で$4ドル/400GB
- 転送量が$8/400GB。
- （のはず。課金体系が結構変わるのでもしかしたら間違っているかも。）

まとめ

大事なファイルは固めてGlacier DeepArchiveにぶち込むのが安くて良いです。

1年運用してみた実績

2021年1月の利用料です。64 cents/monthとなり、年間は840円ほどになります。大体予想通りです。

データ容量は450GBに増えました。1年で50GBぐらい増えた計算です。

S3 Glacierには長期保存用の写真、S3のstandardには、Glacierへ保存する前のデータです。

このサイトをTLS1.3に対応しました

Thu, 12 Mar 2020 00:00:00 GMT

概要

いつからか、blog.teraren.comのTLS設定において、TLS1.3に対応していなかったので対応しました。
TLS1.3は、1.2から大きくハンドシェイクシーケンスが変わっていたり、ちょっと古めの暗号化アルゴリズムが排除されていたりします。リビジョンが1つ上がっただけですが、裏の仕組みは大きな違いがあります。
- https://products.nvc.co.jp/array/blog/tls1-3-corporate-strategy

変更

以下、nginxでの変更箇所です。

（ついでに、HSTSにも対応しました。）

diff --git a/nginx/global/ssl.conf b/nginx/global/ssl.conf
index 9cd7f49..d74c2ed 100644
--- a/nginx/global/ssl.conf
+++ b/nginx/global/ssl.conf
@@ -2,7 +2,7 @@
 # (デフォルト) ssl_ciphers  HIGH:!aNULL:!MD5;
 ssl_prefer_server_ciphers on;

-ssl_protocols TLSv1.2;
+ssl_protocols TLSv1.2 TLSv1.3;
 ssl_ciphers HIGH:!aNULL:!MD5;

 # 2. Logjam攻撃対策
@@ -12,3 +12,6 @@ ssl_stapling on;
 ssl_stapling_verify on;
 resolver 8.8.4.4 8.8.8.8 valid=300s;
 resolver_timeout 10s;
+
+add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';
+

Qualysでチェック。A+になりました。

ちなみに、AWSはTLS1.3に未だ対応していないみたいです。

2020/6/14 定期チェック

まだA+なので大丈夫そうです。完了するまでに5分かかりました。。。

追記：2021/2/1

グレードがAに落ちてしまっていたので原因をチェック。

まず、HSTSが短すぎるアラートが出たので変更。

-add_header Strict-Transport-Security 'max-age=86400; preload';
+add_header Strict-Transport-Security 'max-age=15552000; preload';

A+に戻った。

また、対応する暗号アルゴリズムを変更しました。

- ssl_ciphers HIGH:!aNULL:!MD5;
+ssl_ciphers 'HIGH !aNULL !eNULL !kECDH !DSS !MD5 !EXP !PSK !SRP !CAMELLIA !SEED !RSA !AES128 !ARIA128 !SHA1 !SHA256 !SHA384';

暗号のパラメータに関してはこちらの記事を参考にしました。

その結果

追記 2023/6/22

TLS terminationをCloudflareで行うようにしたのでサーバの方でTLSの設定をする必要がなくなりました。HSTSの設定もCloudflareで行っています。

https://blog.teraren.com/posts/web-service-on-cloudflare/

その結果、A+を簡単に出すことができました。

Ruby on RailsでER図をモデルから生成

Fri, 06 Mar 2020 00:00:00 GMT

Railsの最新のER図をリバースエンジニアリングでスキーマから生成しましょう。rails-erdを使います。

docker container内でコピペでできるようにコマンドを列挙しておきます。

apt update
apt-get install graphviz -y
gem i rails-erd
erd

たくさん出すぎて困る場合は、モデルを指定してフィルタできます。

erd --only="Foo,Bar,FooBar"

コスパよくPCのHi-Res環境を整える

Sun, 09 Feb 2020 00:00:00 GMT

概要

在宅ワークがはじまり、自宅で作業するときは、SoundLink Miniで音楽を聞いていました。しかし、長時間音楽を流しているとなぜか耳が疲れてくるのでリスニング環境を見直しました。SoundLink Miniは音楽鑑賞用じゃないのでモノラルというのも音の立体感がゼロなので悲しいです。どうせなら、Hi-Res対応しておきたいという気持ちが芽生えたのがことの発端です。

1年間に渡り、4回ぐらいスピーカーを買い直しながら試行錯誤した過程を書いてあります。
**結論：PCデスクトップのリスニング環境（ニアフィールド）には、GENELECの8020シリーズが超おすすめ！**下の方の「まとめ」の部分におすすめ機材を一覧で記載してあります。

フェーズ1：PC音響を整備するために必要そうな機材を揃えてみる

基本的にmacos上でYouTubeやApple Musicの音源を再生するのでそもそもの音源の質が良くないのでそこそこ良い音が出れば良いという前提です。

USBDAC
スピーカー
インシュレーター
スピーカースタンド
スピーカーを接続するケーブル

USBDAC

TOPPING D10 MINI USB DAC CSS XMOS XU208 ES9018K2M OPA2134オーディオアンプ・デコーダ(黒色)

1万円未満でPCM384kHz / 32bitとDSD256に対応するのが良い。
Web上で評判が良いです。
USBケーブルの品質も影響するとか書いてあって、よくわからんです。デジタルデータの訂正符号無しのデータが流れているのであれば重要になるか。。。
- http://hitbit2009.blog68.fc2.com/blog-entry-762.html

TOPPING D10

1点、MIDIの設定画面(Audio MIDI Setupアプリ)で転送ビットレートの設定をしておかないと本領を発揮できません。デフォルトは48kHzになってしまっています。

スピーカー配置も変えられるようですが、ステレオでは何も変えられない感じです。左右のスピーカーテストを一応行う程度のもの

ついでに、Mac本体のアナログ出力のサンプリングレートも変更しておきます。デフォルトでは低いです。これを設定しないと音の解像度が低いです。

スピーカー

YAMAHA MSP3
ヤフオクなどで2本セットで1万5千円ぐらいです。
MSP5を視聴した時に感動したのですが、部屋が狭いので1サイズ小さい物を選びました。

YAMAHAの定番中の定番であるモニタースピーカーで有名ですね。
サイズは小さいながらもながら20Wの出力で自宅などのDTM環境では十分なパワーが出せる能力を持っています。
コストパフォーマンスが非常に高いモニタースピーカーで多くの人が利用していることから最初に選ぶモニタースピーカーとしては十分すぎるでしょう。

https://otokake.com/matome/Nftiug?page=4

インシュレーター

audio-technica ハイブリツドインシユレーター AT6098
効果があるのかはよくわかりませんが、デスクへの振動を抑制するために買ってみます。
＝＞変化はわかりませんでした。軽量スピーカーに対しては硬すぎるのかもしれません。

スピーカースタンド

耳の高さにスピーカーを持ってくるためにちょっと高いけど買います。
スタンドにスピーカーを乗せると、机への振動がなくなるので音にこもりがなくなります。デスクへの振動もなくなるという副次的効果もあってよかったです。インシューレーターでは変化はわかりませんでしたが、これでははっきりと分かりました。素材がMDF（成形板）なので柔らかくてショックを吸収しやすいのかと思います。
ハヤミ工産【TIMEZ】NXシリーズ小型スピーカースタンド [2台1組] NX-B300S

スピーカーケーブル

適当なRCAケーブル。評価が高いです。上を見るときりがないので適当なやつ。
Amazonベーシック RCAオーディオケーブル 1.2m (2RCAオス - 2RCAオス)

フェーズ1まとめ

音響関係って、実際に聞いてみないとよくわからないから難しいです。そして、調べれば調べるほど奥が深いです。
スピーカーまでHi-Res対応のリスニング環境はできました。
ノイズは無し。全音域できれいに出ています。音量を大きくしても音割れやこもりは無いです。打ち込み系の音楽をメインに聞いていたら、低音が物足りない感じです。オーケストラ系の音はとても綺麗に聞こえます。
定位もしっかりしていて、明確に特定の場所から音が発せられていることを感じられます。
やっぱりもっと低音がほしいから大きめのMSP5でもよかったかも。しばらく耳をMSP3になれさせてから考える。
https://www.pastimedesignworks.com/2014/03/yamaha-hs7-msp5-msp3-adam-audio-a5x.html

余談

じゃあ、MSP3とMSP5でどのくらい特性が違うのかというのがわかる周波数特性。

YAMAHA MSP5 Frequency Response

YAMAHA MSP3 Frequency Response

30から40Hzあたりが抜けてしまっているのと、角度が同じなので全体的に重低音が低く出てしまう感じ。でも、このためにスピーカーの値段を2倍にする必要も無いかなと思います。

ということで、この周波数特性見た上で、低音の弱さを補うためにiTunesのエコライザーは以下のように調整しました。まぁ、他の再生ソフトを使ったときには意味がなくなりますが。。。OSレベルでエコライザーがあれば嬉しいのですがお手軽なソフトは無さそうです。

フェーズ2

やはり、MSP3だと低音が物足りなく感じてしまったのでYAMAHA MSP5を買いました。やっぱりこのぐらい大きくないと低音は出ないですね。

MSP3だとサブウーファーが必要な感じでしたが、MSP5だと単体で十分な低音が出ます。結構あちこちのサイトではMSP3がお勧めされていますが、私はMSP3はお勧めしません。買うなら断然MSP5が良いです。

音質に拘ったため、デスク上のスペースをかなり占拠してます。

フェーズ3

2020年3月24日　追記

YAMAHA MSP5 Studioを10ヶ月使ってみたので感想を書いておきます。とりあえず、MSP5 Studioは最高です。低音から高音まできれいに出ます。

裏にスイッチが有り、簡易的なエコライザも付いていて良いです。

しかし、リスニング環境によっては本領を発揮できないスピーカーなので要注意です。私はデスクトップスピーカーとして使っていますが、スピーカーと耳の距離が1.5m以上離れていないと重低音が聞こえてきません。

音の周波数の関係だとは思いますが、スピーカーから1.5m以上離れないと重低音がきれいに聞こえてきません。なのでPCスピーカーとして使うには耳との距離がある程度取れないと厳しいです。

というのも、デスクの置き場所を変えて部屋のレイアウト変更を行いました。左右に壁が合ったときにはこのような問題は起きませんでした。おそらく反響して1.5mぐらい取れていたのだと思います。

こちらに詳しい方のコメントがありました。まさにこの通りだと思います。

いや、MSP3とMSP5は、音の傾向は近いですけど、実際鳴らせば、誰が聞いても（特に耳の良い人でなくたって）わかるくらいに、MSP5の方が音質感は良いですよ。確かに、音質感が違う大きな点は、口径とパワーが大きいMSP5の方が、中低域以下の再現性がよいからで、高音域はあんまりかわらんと言われるとそのとおり…という面はありますが、とにかくトータルの音質感はMSP5の方が実力的にずっと上です。

だから、質問者の知人の方がMSP5を推すということは、非常によくわかります。ただ、問題は…質問者もお気づきの通りで >部屋は結構狭いです。防音対策もされていません。スピーカーを置く場合自分との距離は１ｍもないです。となってくると、MSP3の方が妥当です。

上記の、MSP5の「強み」を活かそうと思ったら、ある程度は音量を上げないと、かえってちょっとショボ目の音になってしまいます。そうなると、普通はリスニング位置から最低1m後半～2m程度の距離は欲しいところ。 1m未満で、MSP5の性能が活きる音量にすると、かなりやかましいです。防音室なら、あえてその音量も有りですが（難聴になるほどの大音量ではないので）、私もそうですけど一般家屋ではツライ物がある。

私の自宅作業場も、１m弱しか確保できないので… その距離では、MSP5が十分に活きないので、MSP3の方がセッティングがずっと楽で確実です。 MSP3は、重低音域は十分に出ませんので、そこだけは妥協です。 MSP3～5～7は、環境の広さによって使い分けるモデル設定だと思ったらよろしいです。

https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q11108516796

MSP3だと低音が不十分。MSP5だと距離が取れない。。。。なのでMSP3＋サブウーファーを使うか、他のラインナップを選ぶことになるかなと思います。

そこで、サブウーファーを追加するか、サブウーファー付きのシステムをテストしてみることにします。サブウーファーを追加する場合は、しっかりした音を出すためには大きめのものになるので場所を結構取ることになってしまうのでMSP5+サブウーファーは場所的に辛い感じになります。

なので、デスクトップは小さめのスピーカーでサブウーファーモジュールを床置きにするパターンが理想です。それに合致したメジャーなシステムは以下の2つぐらいになります。

どちらも最新のラインアップは無く、中古を買うことになりました。

BOSE COMPANION 3 SERIES 2の方は、デスクトップのスピーカーが小さいせいで、高音しかなりません。なお、あたりまえですがウーファーは低音しか鳴りません。とりあえず、聞いていてかなり不快でした。

Bose Companion 5のほうは、companion 3より改良されてデスクトップのスピーカーが大きくなったので中音も出るようになりました。しかしながら、低音と中高音のクロスオーバーがいまいちなせいで、中低音が不自然な感じだったのでいまいちでした。慣れれば問題ないのかもしれませんが。あと、なぜだか低音に遅延があるのでそれが気になります。サブウーファーのコーンのレスポンスが悪いのかと思います。

MSP5を使ってしまうと見劣りしてしまいます。

ということで、boseの2つのシステムを試してみましたけど、MSP5のほうが断然良いです。

どこかの音響マニアのサイトで見つけましたが、ニアフィールドでは2wayスピーカーが最適と書かれていましたが、それは正しいなと感じました。

フェーズ4

2020年4月15日　追記

やはり、Yamaha MSP5をしばらく使ってみましたが、ニアフィールドで重低音が聞こえないのが難点なので別の似たようなスピーカーでは特性が違うのか、それとも環境が悪いのかを検証するために似たような2wayスピーカーを試してみます。

::amazon{asin="B087CPPHBB"}

USのAmazonでカテゴリ1位を取っているらしいです。値段もとても安いです。低音、高音のエコライザが付いているので設置環境に応じて音を調整しやすいというのもあります。

USのデスクトップを晒している人の写真を見ているとちょこちょこ見かけます。

こんな感じで設置して使っていました。MSP5と比べて遜色ない音色です。コスパがかなり良いです。しかしながらコーンのサイズはMSP5と同等なので特性は似ています。これもMSP5と同様にスピーカーから50cm居ないでは重低音が聞こえづらいです。機材というより、この大きさのコーンと設置場所による環境要因のようですね。。。

かと言ってコーンの大きさを小さくすると、YAMAHA MSP3のように低音が出なくなるので悩ましいです。。。。MSP3+サブウーファーといった組み合わせの選択肢がないのかなぁ。

ちゃんと比較するためにも、同じ環境で聞いたりもしました。特定周波数にレスポンスの違いはありましたが両方とも近い音でした。

ということで、ちょっと次にどうするのが良いかというのがよくわからなくなりました。

諦めて、世の中でランキングが高いBose Companion 2 Series III multimedia speaker systemを買ってしまうというのも選択肢に浮上してきました。とりあえず、これなら店舗で視聴できるので視聴してみたくなりました。

ついでに、自分の中でオーディオ関連に詳しい店員が居ると認知している有楽町のビックカメラへ行きました。まず、Bose Companion 2 Series IIIを視聴させてもらいましたが、やはり小さいので音圧が低くて重低音の伸びもいまいちでした。

そこで、店員さんに今までの経緯や要求定義を共有した結果、GENELECをおすすめされました。

https://x.com/matsubokkuri/status/1376110155348111362

ネックはお値段。。。ちょっと高いので失敗したら悲しすぎます。

フェーズ5

2020年5月11日　追記

やはりニアフィールドの低音をどうにかしたくなり、bic cameraの店員がおすすめしてくれたGENELEC 8020シリーズを買いました。

見た目は丸っこくてダサいのですが、この形にも意味があってディストーションを削減するみたいです。レビューを見ていると低音の出方に関しては問題無さそうなので買ってみました。

結果としては、GENELEC 8020は素晴らしいです。この大きさで重低音がしっかり出ますし、スピーカーの近くでも重低音がしっかり聞こえます。バスレフポートが裏にあるのが影響しているのかもしれません。バスレフポートを塞いでも低音は出るので、トータルとしてスピーカーの設計が優れているっぽいです。

**この形状のおかげか、スピーカーの近くで聞いても、横の方で聞いても、離れて聞いても聞こえ方が同じです！**これは今までのスピーカーにはなかった特性です。すごい！おすすめ！2本セットが中古で6万〜8万円ぐらいです。

ちなみに、筐体が金属でできているので結構重いです。

手っ取り早くテストで使う音源はこちら。重低音から高音まで一通り入っている感じなので。

https://www.youtube.com/embed/ycBBygx299Q?start=29

フェーズ6

Topping D10はオペアンプのチップを簡単に交換できるようになっていて、もとから乗っているチップはさほど良くないらしいので、高いチップに交換するのがオーディオ会の主流のようです。

日本で買うと_2500円_ほどでハイグレードなチップを買えます。ちなみに、Ali Expressでは数百円で買えます。Amazon評価を読んでいると組み付け方によって違いが出るらしいのですが、単純な回路なのでそんなことはないかなぁという印象です。

OPA627AU
- 高精度高速デュアルにオペアンプモジュール OPA627AU 交換 NE5532 トップ

入れ替えた結果としては、全く変化が感じられませんでした。。。

フェーズ7

TOPPING D10 USB DAC XMOS（XU208）はそこそこ良いUSB-DACで気に入ってはいるのですが、せっかくスピーカーが良いのでもう少し良いUSB-DACがあればもっと良い音で聞けるのではないかと思ってTopping E30を買ってみました。

::amazon{asin="B0868J7NRV"}

買ってから気づいたのですが、E30はAmazon上では評価が高かったのですが、一部のハイアマチュアがイマイチという評価を書いていました。。。。私自身が視聴した感じでは、D10と比べほぼ同じ印象でした。まぁ、音源がさほど良いわけではないというのもありますが。
それより、PCがスタンバイになってからE30は自動で復帰してくれないので毎回リモコンか本体のボタンで電源を入れる必要があって煩わしかったです。なので、説明と違っていたので返品しました。

Topping D10に戻したいなぁと気持ちになっていましたがすでにメルカリで売ってしまったので不可能です。再度書い直すのもアホらしいので再度USB-DACについてリサーチしました。

値段帯を1万円台までで絞ると、MKII AK4493が良さそうでした。AK4493チップを採用しています。最初は、ZEN-DACを買おうとしていましたが、それと同じチップが乗っていて、5000円ほど安いです。

::amazon{asin="B085TF124M"}

そして、買ってみた結果は正解でした。全体的な音の明瞭度が上がって聞こえなかった音が聞こえるようになりました。重低音も全体的に強調されたっぽいです。音の定位もより安定しました。低レイテンシーのチップを使っているせいかなと思います。

本当はTEACなどの5万円くらいのものがほしいのですが、デスクに設置する必要があるので小さいものである必要があります。そうなると、これは意外と小さくて高さは6cm程度しかありませんでした。

フェーズ8

S.M.S.L Sanskrit 10th MKII AK4493の動作が不安定になってきました。雑音が入ったり、急激にアンプの最大音量で雑音が鳴り出したりしてめちゃくちゃビックリさせられることが20回ぐらいありました。

耐えられません。。。

もう、USB-DACはすぐ壊れてしまうので評価が高くて安定しているものを買おうと思います。今までは対応するビットレートが高いものを選定していましたが、どうせ音源のビットレートが低いので優先度を下げます。

こちらの商品はスペックは低めの192kHz/24bit対応です。簡易エコライザもついているので便利です。

::amazon{asin="B07VDQQY95"}

まとめ：現在のパソコン周りの音響環境

スピーカーはGENELECが最高に良かった。
- GENELEC 8020
スピーカーは大きければ大きいほど良いというものではない。

導入したスピーカーの主観的な総合ランキング

5段階評価

GENELEC 8020: ★★★★★
Edifier R1280DBs: ★★★★
YAMAHA MSP 5: ★★★★
Bose Companion 5 multimedia speaker system: ★★★
YAMAHA MSP 3: ★★★
BOSE COMPANION 3 SERIES 2: ★★
BOSE SoundLink mini: ★★

村井純教授の1月16日最終講義全文書き起こし

Sat, 25 Jan 2020 00:00:00 GMT

{/* textlint-disable */}

概要

「日本のインターネットの父」と呼ばれる慶応大環境情報学部教授の村井純さん（64）が定年を迎え、16日、最終講義があった。村井さんは「インターネットに国境はない。国や政府が分断したり規制しようとしたりする試みは続くだろうが、若い人たちで守ってほしい」と呼びかけた。

朝日新聞デジタル

村井先生の最終講義。16年ぶりに村井先生の講義を聞いて懐かしくなりました。せっかく良いことをたくさんおっしゃっていたので人力で書き起こしをしました。（Amazonウィッシュリスト）

講義全文

共同授業担当佐藤特任准教授(以下教員)： そろそろ始めましょうか。

村井： はい。それでは皆さん、こんにちは。インターネットの、2019年秋学期の最終回ということで集まっていただきましてありがとうございました。学生は、履修者があふれるはずだけど来てない。ハハハ。その代わり、なんか変な普段見慣れない人も来ているということで、どうもありがとうございました。OBやそういう人たちも来てくれているようで、皆さんへのメッセージも一応用意してありますけれども。

ただ、今日はずっとアナウンスするようにみんな期待して来ている人もいるんだけど、でかいクラスなのでなかなか学生とインタラクションができないから、質問をまとめてもらってそれを最後にまとめて答えるというのが最終回の使命なので。それを1時間くらいやって、そのあとでSFCとインターネットっていうまとめを少し最後に話すことにしますんで、よろしくお願いします。

まずは皆さんに書いてもらった質問を聞きますんで。なんか変な質問がないことを祈るが。

教員： はい。

村井： 個人的な質問はすんなよ。俺の生活を聞くな、みたいな。

教員： そうですね、個人的な質問は結構有りますね(笑)

それで、講義に関するお願いはいつもと同じです。ハッシュタグ「#inet19F」で、内容に関しての感想とか、あるいはこれ聞きたいとかいうことがあれば。もし拾うことができればそれも考えていこうと思いますので、ご活用いただければと思います。

まず前半は村井先生への質問ということで、最終課題ですね。これがまた550ぐらい(質問が)来てしまって、全部読むのもめちゃくちゃ大変だったんですけども、非常にたくさんのいろんな意見がきましたので、TA/SAにも手伝ってもらって、似たようなものというのはなるべくまとめる形で整理しました。なので、個人というよりは皆さんの総意のものも結構多いかなと思います。それで、時間の許す限り…。

村井さん、Twitterの中ではMJと呼ばれてますね。「MJ、ファンサは楽しいですか？」みたいな質問もあって…。

村井： え？

教員： (ファンサとは)ファンサービスですね。村井先生が学生の所に行ってマイクを傾けるやつを、今の学生はファンサービスって言うんですよ。新しいですね。

村井： まず、JMじゃなくてMJなのね、もちろんね。それもあるし、昨日のTwitterはびっくりしたよな。なんかキャンパスで、「野生の村井純を見た」って。ちょっと待って、ポケモンか俺は、みたいな(笑)

教員： 恐らくハイパーボールじゃないと捕まえられないと思いますけど、はい(笑)

いろんな質問が学生から寄せられていますのでいろいろあるんですが、まずはこの授業はインターネットということなので、インターネットについての質問から入りたいと思います。

1個目は、インターネットが今当たり前の世界になりましたが、これからはどんな世界になると思いますか、という質問です。

村井： いきなり難しくない？　最初にしては(笑)

まず、当たり前の世界になったってすごいことだと思うんだよね。それで、この授業では今回歴史の話をしたけど、90年からこのキャンパスをやって、このキャンパスは当たり前であったけど、世の中は当たり前じゃ無かった。それで、井庭ちゃんが今スライド持ってて俺も持ってるんだけど、95年にSFCのキャンパスの統計を取って、学生のインタビューを取って、それでアンケートを取ってそれを井下先生っていう先生がまとめた調査結果があって。その中に、電子メールやインターネットで恋をした人とか、泣いた人とかそういうのが書いてあって、それがすごく多いんだよね。95年でインターネット誰も知らないので、世の中、その統計の論文に彼(井下先生)書いてたんだよね。それで、その論文の結果を俺がスライドにして、世界中で講演するわけ。そうすると日本は特に「気持ち悪い」とか言うわけ。メール見て泣いたとか笑った、とか言って。そうするとそれをすごく反応するんで。だけど、SFCじゃ当たり前で、SFC以外じゃ当たり前じゃないっていうときがあったと。それで、そうこうしているうちにインターネットは当たり前になって。

いろんなことを言う人がいるんだけど、みんなはどう思うかわからないんだけど、ここまで当たり前になると「知らない」って言うんだよね。これがインターネットだって分かってなくて、「LINEは使うけどインターネットは知らない」とか、「私はPayPay使ってますけどインターネットは使ったことがありません」とか、そういう人が出てきちゃうんじゃないの？　っていう声があって。

それで、これからどういう世界になるかなんて分かんないだけど、(これからはどんな世界に)なると思うか？　っていうそういう誰か任せみたいな考え方は持ってないんだよ。どういう世界にしたいかっていうことなら、かなりチャレンジングなことがあるなとは思うけど。最後にも言うけど、インターネットは人類が初めて地球上で、人間が同じようにデジタルデータを共有してコミュニケーションができる、こういう環境を創った。それが当たり前になった、つまり有るのが当たり前である。その上で、いろいろなことがわれわれの社会には起こるけれども、良いこと悪いこと、それからナショナリズム、戦争、サイバーセキュリティのイシュー、いろいろ起こるんだけど、じゃあこれからそれがすごく悪くなるのか良くなるのかっていうことを考えたときに、それだけ答えておくとね、ほとんどのSF映画の未来像みたいなの見るじゃん。そうすると大抵すさんでるね。大体、テクノロジーが発展しすぎてロボットにやられてターミネーター、みたいな。なんかそういう話がすごく多いんだよね。それで、なんであんな悲観的になるかなとは思うんだけど、でもそれは持っていきようだと思うので。

やっぱりここまでこういう世界をつくってきて、いろんなときに俺は、「世の中悪くなったのはインターネットを創ったおまえのせいだ」っていろんな人に言われてたけど、「はいはい」って言いながらもそこからそれをなんとか、そう(世の中が悪く)ならないようにするための技術の開発ももちろんしてきたわけだけど。でもやっぱり人間が何したいっていうことのプラットフォームを創ってるわけだから、そうすると人間は何したいっていうのは、結構良いことをしたいんじゃないかと思うんだよ。またこういうことを言うとナショナリズムって言われるけど、特にこの国はね。だからそういう意味で、インターネットの基盤ってどんどん良くなるんだけど、良くなるといろんなことがやりやすくなるから悪いこともやりやすくなるんだけど、良いことがやりやすくなるといろんな問題を解いたり、人のためになることをしようとか自分のためになることをしようとか、そういうことがどんどん発展するんで、これからはそういう問題を解決するためのコストが小さくて、そうするとやっぱりいろんな問題を解決しながら発展的に前へ進む世界になると僕は思ってます。だから、超オプティミスティックなの。

教員： なるほど。もう、1個目の質問から非常にファンサービスがうっとりで、このままいくと3時間ぐらいかかっちゃうかもしれないのでいこうと思いますけど(笑)

次が、インターネット時代の情報の取捨選択の方法についてです。たくさん情報があふれてるときに、どういう情報を選べば良いですかっていうことがあれば、という質問が何個か来ております。

村井： 良いポイントで、もうちょっと待ってください。俺が今からやるのはこの話かもしれないなって思っていて。

今、「国境なきジャーナリスト」っていうグループがあって、パリやヨーロッパ中心に活動している。そこからのアプローチがあって、いわば「フェイクニュース」だとか「新しいジャーナリズム」とか「広告のビジネスモデル」とか、そういう問題をどうやったら解決できるだろうって。ジャーナリストの人はシリアスだよね、すごく。そもそも新聞のメディアとかテレビとか、そういうもののメディアの広告のビジネス的な力が弱まってるから、メディアとして。代わりにいろんなメディアが出てくるけど、そこにはコンシューマー・ジェネレーションのメディアで動いている。そうすると、本当に質の高いジャーナリズムっていうのはどうやってつくれるんだろう、ということを考えているんだと思うんだよ。それで、そのグループの人から今アプローチがあって、その問題、まあ俺の場合は技術のプラットフォームを創ることだけど、その人たちがトラストをつくりながらグローバルな空間で新しいジャーナリズムの活動ができるような環境はどうすれば良いですかっていう研究課題を持ってきたんだよ。これ、答えは無いよ？

それでそうなってくると、そこが狙ってるのは取捨選択の方法、例えばIDのトラストっていうのがあるんだけど、授業で何度か言ったけどアノニマスのIDは必ずしも危ないもんじゃないんだよ。TwitterのIDってなんでも付けられるけど、でも世の中が人間とものすごくタイトになるIDを持っているのは、リアルドナルド・トランプさん。この人は本当に、Twitter見ると本物がちゃんとしゃべってる。このことのパスポートとの裏付けも無いけど、もうあまりに歴史が流れて彼だったことが分かるんだよ。

というわけで、IDを政府発行のものに結びつければ信用ができるっていう単純な話じゃなくて、そして誰が何を発信しているのかってことが分かってくれば、今度はみんなのレピュテーションやコミュニティーとして、この人は信用できるとかこの人は本物だとか、この人の言うことを聞いてるとこうなるとか、そういうことをわれわれは日常で考えて、今まで何何新聞なら信用できるだろうとか何何新聞はどっちに寄ってるだろうとかそんな話があったのと同じように、個人の情報のエンティティでそういうものを取捨選択ができるような方法が徐々に出来てくるだろうなというふうに思ってるのね。だけど、今無いとは言ってないんだよ。だからリアルドナルド・トランプは、本人がフェイクニュースって言うからどっちがフェイクニュースだかよく分かんないんだけど、だけどこの人が言っているこういうメッセージだっていうことは分かりながら、今のところ世の中は推移するようになってて、もう既にそこに俺たちの取捨選択の方法はだんだんアダプティブに確立してると。　それでアドバイスは、どうすれば良いのかなって考えてるとそれを実現するのは良いことなので自分一人でもできるんだよ。これ面白いよって言って人に伝えるってことができれば、そういうコミュニティーとしての取捨選択の方法のクオリティーはある方向に上がるから、そういうことはもうみんなやってんだよ。というわけで、まあ大丈夫だよ、うまくいくよ。ハハ。

教員： では、ちょっともしかしたらかぶってるかもしれませんけど、もう1つあった質問として、議論の場としてのインターネット空間について。

今やインターネットの上で行われているさまざまなコミュニケーションについて、どういうふうな意見を持っていますか、というような質問ですね。

村井： まあ、これの方が嫌だね。嫌だねっていうのは、なんか炎上するじゃん、すぐ。だからそれを恐れてみんな言えなくなってると思って。でもすごく勇気のある人がいて、俺個人的によく知ってる人で、炎上覚悟でスパンって言うみたいな人がいるよね。それでもう、炎上しても全然気にしないでいて。まあきちんと答える人もいるし。だからいろんなことができるようになってきたなと思う。それで、完全にオープンな場で議論するとノイズが入るから嫌だっていう人も、例えばSFCの学生とはこういう議論をしたいとか、この教室でこのクラスを履修してるやつとはこういう話をしたいとかいろんなことができるので、インターネット空間は、例えばジオグラフィカルなロケーションに依存しないとか所属に依存しないとか、そういう議論ができる場所というためにはめちゃくちゃ自由になったんじゃないかな。

タダ、タダだからね、テレビ会議タダだからね。世界中に散っててテレビ会議でずっと話してて誰もお金払わないって。まあタダっていう言い方も、サブスク、ISPには金払ってるぜってのはあるんだけどさ。だけどすごいね、みんな本当知らないと思うけどさ、国際電話ってお金取ってたときがあるんだぜっていう。電話で金取ってた人たちいたんだぜ、みたいな。今の学生知らない？

教員： みんなもしかしたら通話もタダだと思ってるかもしれません(笑)

あといくつか寄せられてる質問で、これからのインターネットに限らずっていうところですけれども、人とコンピュータの関わり方、インターフェースっていうのはこれからどういうふうに変わっていくと思いますか、という質問もいくつかありました。

村井： どうやって変わっていくと思いますか。

(学生に向かってマイクを傾ける)

学生A： うーん、難しいですけれど、どこまでコンピュータが人の生活に入ってくるのか、人間がどこまで受け入れるのかがそうなのかな、と思いますけど、そんなに入ってきてほしくはないです。

村井： (入ってきて)ほしくはないけどね。

どう思う？　人間とコンピュータのインターフェース、界面、どこから先がコンピュータやインターネットの世界になる？　今ここだよな、この辺のパソコンとかな。

学生B： 一定の距離は。

村井： 一定の距離は保ちたい、あんまり入ってきてほしくないな。一定の距離は保ちたいなと2人の人は言いました。それで、インターフェースって意味がいろいろあるんだけどさ、めちゃくちゃ変わると思うんだよ、俺は。

例えば車を運転して行きたい場所があるよね。そして、どのレストランに行きなさいって言うよね。それで、レストランの名前を騒ぐという以外の運転の仕方をする人は1人もいないよね、1人も。「自宅に帰る」とか言うと自宅に帰れるよね、どこにいても。今のカーナビはね。カーナビで自宅に帰るっていうと自宅まで案内してくれる。そうすると、もう音声のインターフェースはカーナビではかなり早くから手が塞がってるから、俺もスマホでメッセージとか打つのに、増井さんには悪いけどフリック入力っていうのが苦手でつい間違えるね。でも、増井に「フリック入力使えねーじゃねーか」とか言うとすっげー怒られるから、喧嘩になるから。一応知らない人には言っておくけど、増井さんっていうのがフリック入力っていうのを作ったファカルティでここにいるんだけどさ。とにかくみんな早いんだよね、若い奴はね。

おまえ、早い？　フリック入力？

村井： あ、携帯、入力。それは増井さんに言えないね。でもエラーが多いので、俺1人で周り気にしないときはやっぱりしゃべっちゃうんだよね。だんだん音声の認識の質が上がってきているから。今、このキャンパスでは修士の中間発表がポスターになったんだよ。それで、ポスターに行って説明を学生から聞いて、コメントを入れなさいってコメントの欄がうわーってあって、それを打つのか、みたいな。しかもポスターって歩いてるから、スマホしか持ってないんだよ。もうしょうがが無いから全部しゃべって入れてるんだよ。そうするとだんだん流行ってきて、みんな他のファカルティも「あれ？　しゃべって入るんだ」ってクオリティーがいつの間にか上がってて気が付いていない人がいる。そうするとだんだん味を占めて、俺は原稿を書くとかそういうのも、ただただスマホにしゃべってるっていうので書いちゃうっていうのはあって。

それで、だんだん変わってきてるね。俺自身も変わってきてる。みんなもそうだと思う。それからさっきの「あんまり入られたくないな」っていうのがあって、俺は結構ね、家の絶対嫌だという面がある。家の鏡の裏側に高解像度のカメラを付けて、ずっと鏡に向かう度に…鏡に向かうでしょ、毎日？　向かう？

学生C： (首をかしげる)

村井： 俺も向かわない。俺、向かうのは女だけだと思ってたんだよ、長い間。ハハハ。まあ、俺は鏡見ない。とにかく毎日同じところで見ると、このデータをずっと毎日取っていると、健康状態が分かるんだよ。それで、もちろんトイレからっていうのも健康状態が分かる。スマートハウスってこうしていろんなことが分かるので、健康のことだけ考えるなら取られても良いデータだと思うんだよ。それで、それ以外には使われない。気持ち悪いと思うかもしれないけど、最初は。でも「自分の健康の見方、それ以外では絶対使われないデータだ」、こういうふうになったら絶対に素晴らしいインターフェースになる。

というわけで、スマートハウスってそういうふうになると思います。なぜなら、人間の健康は人間が生きてくためにもっとも重要な基本のことだから。そういう意味で、このインターフェースっていうのは変化をしていくし、トラスティドなコンピュータとの接点でわれわれの人間のデータが、特に健康のため、あるいは災害のときの命を救うため、こういうために使われるようになると思うので、すげー変化すると思う。

教員： 次の質問を見越して回答しているんじゃないかと思ってあれですけども、補足でいくつかあった質問は、これから先もどんどん新しい技術が出てくるとしたときに、そういう新しい技術、今だとAIとか自動運転とか例がありましたけど、そういうものが出てきたときの向き合い方で何かアドバイスがあれば、っていう質問です。

村井： 俺12月に追突されたんだよ、東名(高速道路)でまた。それでその前は、話したと思うけど俺が足をけがしてたときに運転しててもらった運転手が脳梗塞になって、東名で。それで、レーン出そうになるけどウインカー出してないから戻ってきて、みたいな。それで俺は命を救われたんだよ。それが2年前でしょ。それで12月にまた東名の横浜で追突ガツンってされて、後ろの車はぺっちゃんこ廃車。それで俺の車は後ろから追突される直前に、シートベルトをギューって締めてタイヤをロックするっていう追突のためのメカニズムが付いてたの。というわけで、僕はなんかダメージ受けたのかもしれないけど気が付いてないみたいな。ハハハ。次の日から痛くもなく動いてる、みたいな。やっぱり人間の体を守る方向にいくんじゃないですか、自動運転って。他になんかあんのかな。

あ、俺ね、結構しゃべるのうまいんだよ、カーナビに。「自宅に帰る」とか「ホテルニューオータニ行く」とかいうと、大体俺のミスリードしない喋り方とかできる。

教員： 素晴らしい。僕、「SFCに」って言ったら長万部に連れて行かれそうになったことありますよ、ハハハ。それは上手ですね、さすが。インターフェースが進んでいると。

あといくつかあるんですが、ちょっとなるべくたくさんのものをと思いますのでアドバイス編ですね。

大学の授業は役に立つと思いますか。あと、大学のうちに何かこれだけはやっておけってことがあれば教えてください、っていう質問です。

村井： 俺に聞く、これ？　ハハハ。

まず、俺の大学の時代には授業受けてないよ。つまんないもん。大丈夫か、これ？　俺、学部長のときは言えなかったんだよ、これ。もう最後の授業だから全部バラすけど、俺は大学6年間かかって。日吉が4年間か。日吉4年間かかるって何かっていうと、一般教養だからなんだよ。一般教養って経済の基礎とか哲学とかそういうの勉強するんだよ。それで、これずっと勉強してると「なんで俺経済学が必要なんだっけ」「なんで俺哲学が必要なんだっけ」「なんで俺美術だっけ」みたいなのがあって、そう思って受けてるとつまんないんだよ。だから成績悪くて、その他の理由もあるけど留年してたわけ。それでSFC作るときに、「止めよう、それ」って思ったの。押しつけられて受けるとつまんないんだよ。

ところが、「あ、経済学って何だっけ」って、俺ちょっと知っとかなきゃなっていって受けるとめちゃくちゃ面白いんだよ。当たり前だよね、すごい先生が教えてるんだから。というわけで、SFCはその順番こだわるの止めようと言って、面白いことをやって必要だと思ったら、その授業や立派な授業があるようにカリキュラム作ればいいじゃん、というふうに作ってあるわけ。だから日吉と一緒にできないんだよ。それで、それはSFCのいわば成功の秘密だとも言えるんだよ。

だから、1年からいきなり研究活動やって、必要だと思ったものは一生懸命勉強しようと思うとまず効率が良いんだよね。そういう意味で大学の授業は、「役に立たないもんは言ってくれよ、止めさせるから」っていうのは学部長時代は思ってたけど。だから、役に立つものと立たないものがあると思うんだけど、基本的に(役に)立つと思うんだよ。SFCの授業はグループワークが多いので、その授業は役に立つかって言われると結局(役に)立つんだよ。皆さんが作る授業だから。

次、2行目の質問は全然違う質問だけど、大学生のうちにやっておいた方が良いことは何か。もう俺にこれを聞いたら答えが1個しかないのに分かってて聞くなよ、っていう。もう**絶対にやっておいた方がいいのは好きなことだね。好きなことを思い切りやる。**これ、できないから、大学生以外。っていうか最後だから。もう就職したら好きなこと思い切りできないんだよ？　万一サラリーマンになったら、週5日とか朝から晩まで行くんだよ。言われたことやるんだよ。今なら好きなことできるじゃん。というわけで、絶対に好きなことを夢中になってやるべきだ。

もう1個、いい友達を作れ。はい、終わり。

教員： 自分が本当に好きなものはどうやって見つければ良いですか、という質問も来ています。

村井： 分からないか、これ？　好きなことない人手挙げて、見つからない人手挙げて、もっとたくさん好きなこと見つけたいなと思う人手挙げて。あー、そうだよね。SFCを30年間見てて、本当は見つからないやつがいっぱいいて、それが一番の悩みで、SFCのようなスタイルのキャンパスを運営してると、みんな好きなことがあってきらきらしてんだけど、あたしはどうすればいいんだろうっていう悩みはすごく多いんだよね。だからこの質問はよく分かる。

それで、俺のわずかな30年の経験で青春の学生と付き合ってて、「あー、見つかった」っていうのは友達を通じてだよね、先生を通じてとかね。例えば、俺が何が好きだかわかるだろ、もう。そうすると、授業を通じて俺から分かるってこともあるよ。それから、全然関係ない友達、研究室とは関係ない友達。例えばサークルだとかどっかでばったり出会ったとか。そういう友達と話してると、全然違うことに夢中になってる人とかと出会うことがある。そうすると「あ、これって面白いかもしれない」っていうことに気が付くので、このSFCのデザインでできるだけ気を付けてたのは、研究室入っちゃうと研究室にズポーンと行って出てこないとか、サークル行ったらサークル以外に出てこないっていうのは、それもそれでいいんだけどさ、好きなことやってるから。

だけど、なんかそういうんじゃない出会いができるようになんないかなって言って、例えば今体育のクラスとかすごく大事な役割を果たしてると思うんだよ、全然知らない人と一緒のことをやらなきゃいけないっていうのは。それで、履修するっていっても全然関係ない人と一緒に履修をして、それで友達になって、そこを知ると「なんかこいつのやってること良い、面白そうだよね」っていうのが見つかるから、こうやってやっぱり人を通じて見つかるんじゃないかなとは思うけど。素敵に夢中になってる人から学べるんじゃない？

教員： これはさっきもう回答があったので飛ばしますけども、次が、修士もそうなんですが、博士課程の進学、あるいは大学院の進学ってどうですか、とか先生はおすすめされますか、っていう質問も何個か寄せられています。

村井： ちょっとヤスニャンこっち来て。お前は今何年だ？

教員(豊田)： 僕、今修士2年です。

村井： どうすんの、来年？

教員(豊田)： 博士課程に行きます。

村井： ほら。というわけです。

（会場拍手）

教員： あくまで個人の感想です、みたいな。ハハハ。違います？　大丈夫ですね。

村井： いや、あのね、ヤスニャンもそうとう悩んだんだよな、いろいろ。俺もね、いろんなことをやったんだけど、博士行きたくないやつ、まあヤスニャンもそうなんだけどね、俺今修士見るじゃん。修士見ててね、もう結構さぼってぎりぎりまであんま見てないんだけどさ、もう提出しちゃったよとかいう修士見てるんだよ、今。それでそうすると、大学で(修士)見てて、「なんだこいつ。おい、こいつ今いるか？」って言ったら、「いや、なんか発表の準備で机の下で寝てます」って。それで行ったら机の下で寝てて、蹴飛ばして「おい起きろよ、起きろよ。お前さ、これからどうすんの？」って言ったら「いや、何とか会社に就職します」って言うから「あ、そう。じゃあ俺今電話して断ってやるからさ、博士課程行けよ」って言ったことあるんだよね、本当にね。来てるかどうか知らないけど。そういうやついるんだよね。そういうことやると、今だったらパワハラとかアカハラとか言って殺されそうですけど、今日で終わりだからいいや。ハハハ。でもちゃんとすごい立派にドクターになった人ばっかりですから、ヤスニャン心配すんなよ。

教員： 良いコメントですね、良かった。

あと、村井先生の原動力みたいなものに対してですね。すごい質問ですね、どうしてインターネットを作ろう、もしくはインターネットを研究しようと思ったのですか、という質問です。

村井： これについて授業でも言ったんだよね。高校大学の最初の頃にコンピュータ大嫌いで。それでその頃のコンピュータはメインフレームで、偉そうに真ん中に鎮座してて、なんか行列してカードとか持っていって、ガーって読ませると2日後に結果が出るみたいな。計算機ってそういうもんだから。弾道計算とか軌道計算とか、そういうすごい難しい物理学の式が解けて嬉しいな、みたいなそういうのが、俺たちが高校大学の最初のころのコンピュータのモデルで、メインフレームはでかい、高い。慶應にもあったけど、高校も大学のコンピュータ借りて行列作って、まあラーメン二郎の行列みたいな。それで、「コンピュータ様、計算してください」みたいな行列がある。偉そうだよね、コンピュータが。俺の頭の中のイメージは、コンピュータが偉くて、その周りに計算してもらいたい人が群がってる、そんな計算機中心みたいな。なんかそういうの大嫌いで。

俺、ずっとキャンプのカウンセラーをやってたんだよ。野外教育をずっとやってたんだよ。なんとなく人間のことが好きで、人間が中心じゃ無いと気が済まない。だから、コンピュータをやるやつも嫌いだったし、コンピュータの授業も避けて。そのころ、必修じゃなかったから避けて通れたんだよ。それで俺は数学なんだけど、数学はコンピュータ無くたって当時解けた。数学科にはコンピュータの先生がいて、仕方ないからそこの課題があってやると。あ、矢上(キャンパス)で専門になってからね。ついに幸せだった日吉の4年間を越えて、晴れて矢上の数理工学科ってところに専門で入って。そうすると、コンピュータのアセンブラの必修の科目があってそれをやったわけ。そうしたら先生が来て、お前は面白いって肩たたかれて、「一緒に研究の手伝いしない？」って言われたんだよ。中西正和先生ってLISPの先生で、亡くなりましたけど。俺とか冨田勝の先生なんだけど。

それで、なんと言っても衝撃の事件だったんですよ、大学5年目、初めて大学の先生と話したの。すごいだろ。大学ってところに俺は来たけど、大学の先生が話し掛けてきて、しかもお前は面白いって言ってくれた。この衝撃に俺は5年かかったね。だからみんな4年で卒業したいなんて思わない方がいいよ、本当に。そしてそれはなんで面白いかっていうと、やりたいことをやるような課題の根拠、今はゲーム作るんだけど、それがなんか面白い。そうするとだんだんその頃から、例えばワープロとか出てきて、ワープロってコンピュータで出来てるけど人間の道具だよね。人間がいて、それを支えるための道具化してきてるコンピュータがちらほら見えてきてる。

元の俺のコンピュータのイメージは、コンピュータが真ん中にあって人間が群がってるみたいなイメージだったのに、人間が真ん中にあって道具が散らばってて、それが人間を支えるみたいなそんなイメージがついに持てるようになってきたので、その絵を描いたの、学部のときにいきなり。始めはコンピュータが真ん中、周りに人間がいる。もう1枚の絵は、人間が真ん中、周りにコンピュータがある。それで考えたわけ、このコンピュータと人間が話してると、命令してると、なんか面倒くさい。それで、例えば秘書が3人いて、通訳が3人いて、それぞれ秘書なりに全部話しながらお願いしてたら時間が3倍かかっちゃう。だけど、秘書の代表みたいなのがいて、その人が他の秘書と連携してくれていれば、自分を助ける秘書のモデルってそういうので出来るんだろうなって思ったわけ。

それで、じゃあ人間の周りにあるコンピュータってのが手をつないで、真ん中の人間のことを支えるようになんなきゃいけないよなってそのとき思って、そういうことができないかなと思ったの。それでできなかったね、そのときのコンピュータは。だから俺はインターネットを作ろうと思ったというよりは、コンピュータが人間を支える仕組みを作りたい、そのためにコンピュータはコンピュータ同士で話さなきゃいけない。それがコンピュータネットワークの研究をしたきっかけ。分かった？

教員： 分かりました。僕が分かってもしょうがないか。ハハ。大丈夫ですかね、質問した人、何人かいると思います。

あと2つあるんですけど、1つはインターネットを作ってきて後悔したことを聞かせてください、というものと、インターネットを作ってきた中で楽しかったことはあったのでしょうかって、全部つらいと思ってるのかなって気もするんですけども。つらかったことと楽しかったことがあればっていう質問も来ています。

村井： 最初何？

教員： 後悔したこと。

村井： 無いね。

教員： 無い！かっこいいですね。じゃあ、楽しかったことはなんでしょう。

村井： 全部楽しかったね。

教員： 素晴らしい。ハハハ。

(会場拍手)

教員： あとここから少し、村井さんの個人への質問みたいなものもいくつかあるんですけども。

最初の質問、結構(たくさん)来ましたね。どうしてSFCで定年まで勤められたのか、あるいはSFCにずっといたのか。海外に行く機会もあったと思うんですけど、行かなかったのはなぜですか、っていうような質問も来ていました。

村井： 鋭い質問だね、この質問。っていうかこの話したことないね、俺。

やっぱり(海外に)行きたかったし行くべきだと思ってて、実はポジションもオファーしてもらったことあるんだよ。それで、給料も見て目が飛び出て、どうして日本よりこんなに高いんだろうって思って。特に大学のときは、本当に用意して「来て下さい！」みたいなところもあったけれど、それからドクターのときも、東工大、東大と行ってここへ来てからも、でも一度も行っていないんですよ。開発のときに、相当バークレーに入り浸ってたことはあるし、徳田さんがCMU(カーネギー・メロン大学)行ったときに、何日も行ったことがあるけど、勤めたのは東工大と東大と慶應だけなんですね。それで、一応オファーが確かにあったんだよね、負け惜しみで言ってんじゃなくて本当にあったんだけどさ。

なんで行かなかったかって言うとね、これ言うと修辺りに怒られるんだけどさ、あの後ろの方に座ってる奴らに怒られるんだけどさ。今俺がこの国を離れたら、日本のネットワークが止まるなってやっぱ思ったんだよね。ダウンするな、と。もうちょっと経ってからじゃないと駄目かなとかっていうふうに僕は思ってたわけ、勝手に。きっと俺がいなくなれば、残ってたやつらがうまくやってそんなことは無いんだよな、普通は。だけど、俺はそう思ってたの。だから、海外に行かなかったのはなぜですかっていうのを正直に答えると、今俺がいなくなると、やっぱ(日本のネットワークは)止まっちゃうんじゃないかなって若い頃思ってたんだよね。でもそれはうぬぼれであって、多分そうじゃなかったんだと思う。なんか、俺が留守にすると動かなくなるんじゃないかなっていう心配があったから。

それで、ひどいんだよなー、俺の定年。慶應義塾の定年ってひどいんだよ。65歳が定年だから、65歳が終わるときにクビにすりゃいいじゃん。でも、65歳になったら4月1日を迎えちゃいけないっていうのがルールなの。俺の誕生日3月29日なんだよ。それでさ、3日？　みたいな。始めにエントリーで得してないから、早生まれって大体いいことあったんだけどこれだけは納得いかないけど。でもまあ65歳で3日勤めますんで。本当に勤めるのかな？でも卒業式行くよ、今年。

教員： 非常に良い話の次に聞くのもなんですが…。ここから一問一答形式ですね。村井さんの一番好きなお金の使い方はなんですか。

村井： これはね、学生にうまいもん食わせること。

(会場拍手)

村井： これが嬉しいんだよ。なぜかって言うとね、大人にうまいもん食わせても喜ばないね。だって自分で食えるじゃん、みたいに思うじゃん。やっぱ楽しみだね、これね。「お前食ったことないだろ、これ」みたいな。ハハハ。

教員： あとは、村井先生の尊敬する人は誰ですか。

村井： 尊敬する人…。いっぱいい過ぎてあれだけど、やっぱ俺が最も持ってない力を持っている音楽家かな。

教員： 音楽家(笑)

村井： 絶対俺にはできない、ずるいって思うね。

教員： なるほど。

生まれ変わったら何になりたいですか。

村井： 音楽家だね。

(会場笑い)

村井： あ、ねえ、定年後何をやるんですかっていう質問は…？　あるんですね。まあ、いいや。

生まれ変わったら…、バナナかな…。

教員： バナナ？

村井： …どうぞ、次行ってください。

(会場笑い)

教員： すごい会場がザワザワしてますけど、大丈夫ですか。

村井： なんで今そう言ってみたかっていうとね、長女が生まれて、ユミコっていうんだけど、「ユミちゃん、大人になったら何になりたいの？」って聞いたら、「バナナ」って言ったんだよ。だから一応それを尊重して、彼女はバナナになりたかったらしいんだよね、大きくなったら。だから俺もバナナになってみようかなっていう気に、今。

教員： 次が、温泉掘削計画の進捗をお聞きしたいです。

村井： 止まってて申し訳ないんだけど、このプロジェクトは知らない人もいると思うんだけど、SFCに温泉を掘ろうと思っていて。この理由は、掘るの高いんだけど、あるところでSFCのすごいサポーターで、大分の温泉を掘るっていうのに投資してた人がいるんだよ。それで、この人まだSFCのサポーターだから止まってないんだよ。まだ終わった話じゃないんだけど、そしたらそのプロジェクトが頓挫しちゃったわけ。従って投資したお金は戻ってきたんだよね、やらなかったから。そうするとこれ、温泉に使った金だから、温泉を掘る夢のために投資した金なんだよ。この人が「これで温泉を掘るところないかな」って言うから、「SFCに掘ろう」って言ったの。それで、温泉課ってのがあるんだよ、神奈川県に。温泉っていうのは泉脈があって、泉脈の沿線に他の商業温泉があったりすると難しいとかそういういろいろな事情があるんだけど、それを一応調べてもらったら、良いんだよ。掘って良いの。そこまで分かったわけ。そのあと、ちょっと名前が分かっちゃうとまずいんだけど、その人がいろんなところ誘ってくるんだよ。どっか遊びに行きましょうとか、アフリカ遊びに行きましょうとか、お金持ちだから。そういうのについて行くと、じゃあ次の瞬間温泉掘るっていう感じになるかなと思ったけど、なかなか時間が取れないからオファーを振るわけ。ずっと振り続けてるから、だんだん良い感じ持ってないかもしれないねって、俺に。ハハ。それで一生懸命彼と遊んでると、きっと良くなる。今度リタイアして授業無くなると、少しアフリカとかそういうところに遊びに行けるから、そうすると温泉は戻ってくるかもしれない。

教員： 一問一答でって言ったのに、こんなに温泉の話をインターネットの授業で聞くとは思いませんでしたけど。

あと、明日死ぬとしたら今日何をしますか。

村井： 何だよそれー(笑)うまいもん食うよ。

教員： うまいもの、はい。

あとこれは結構僕は衝撃でしたね。村井さんはこれまでに何か音楽をされていたのでしょうかという質問が来る！

村井： いやもう俺は自分では聴くのだけで。小学校のとき縦笛とかやったかな…。嘘だ、今の。僕、大学のときは、2年を4回やったうちに「東京大学ブルース研究会」っていうバンドやってて。東大って五月祭(ごがつさい)っていうのと、女子校は五月祭(さつきさい)っていうんだけど、東大の五月祭は駒場でやるの。それから本郷でやるのを駒場祭と五月祭っていうのかな。それで、本郷と駒場で春と秋に文化祭があるんだよ。これ全部出たから、4年間、2年のとき。つまり8回出て、ブルースばっかりやってて。そのとき隣の教室でやってて、「エレキの音はうるさい」とか言われたのは中島みゆきさん、昔の話です。それで、僕たちのMCやってくれた人は、夏目雅子さんという、女学館の2年生の。そのあと大女優になりましたね。一緒にずっと舞台の上でMCやってくれて。それで、そういうことはやってましたけど…やってたよ。だから俺は…まあいいや。言いたいことあるんだけど、あとで出てくるんだよな。

教員： 分かりました。

あといくつかですね、例えばSFCについての質問というところで、先に読み上げちゃいますね。社会にとってこのSFCという大学、あるいは学部は成功だったと思いますか、とか、村井先生がいなくなった後のSFCがどうなるのかの予想を教えて下さい、とか、SFCはどんな大学になっていってほしいですか、あるいはSFCの学生に期待することは何ですか、みたいな、SFCがこれからどういう風な、もしくは村井さんがSFCのことどう思ってるのかっていう質問もかなり多かった…。

村井： ちょっと待って。何でそんなすらすら言っちゃうわけ、これ。

教員： え、どれですか？

村井： いや、この質問。

教員： SFCの学生に期待すること…。

村井： 違う違う、その前も。なんで飛ばしちゃったわけ？

教員： 最後にまとめて返事をしますっていう…。それとも一問一答で行きますか？

村井： あっ、そう言ったっけ…。プレゼンにそんなこと書いてないよ。

教員： じゃあ、1個ずついきますか。ただ、お時間もありますので(笑)

村井： 時間ってまだあるんじゃないの？　2時半までじゃないの？

教員： 最後、村井先生のスライドも結構ありますよ？

村井： あー。

教員： でも時間の許す限りいきましょうか。

社会にとって、SFCという大学は成功だったと思いますか。

村井： 思うよ、大成功だよ。

教員： あ、次で良いんだ。ハハハ。

(会場爆笑)

教員： 温泉よりも今の話に尺を取るべきだったんじゃないかと思いますが、まあまあ。ハハハ。

村井先生がいなくなった後のSFCはどうなると思いますか。

村井： もうどんどん良くなるよ。

(会場爆笑)

教員： SFCはどんな大学になっていってほしいですか。

村井： もう最高の大学になってほしいよ。

(会場爆笑)

教員： SFCの学生に期待することは何ですか。

村井： 3つぐらいあるんだよ。

**好きなことをやれ。自分を好きになれ。自信を持て。友達と仲良くしろ。**終わり。

(会場笑い)

教員： さすがですね。落ちがちゃんと付いてる。

最後の質問です。結構哲学的な質問もいくつかあって、なかなかこの授業をやっていてこの質問来るのもすごいなと思ったんですけど。「インターネットって何ですか」、これは僕、逆に深いなと思ったんですけど。これは最後スライドで？　それとも今一言お返事しますか？

村井： あとで言う。

教員： あともう1つ。「この講義で一番伝えてきた、伝えたかったことは何ですか」っていうような質問も来ていますので。

村井： はい、それでは。今回はこのインターネットの授業は歴史みたいな話をしていたので、その延長なんだけど、これも30年やってきた最後の授業だから、オーバーラップするのは初めて来てる人は勘弁してもらって…。

SFCとインターネットの話をしてみますね。俺は長い間、環境情報学部長をやってたんだよね。それで俺の完璧な考え方は、環境情報学部と総合政策学部の区別は無い。これがずっと俺が思ってたことなんだよ。区別があるって言うことを言うやつもいるんだけどさ、今の土屋総合政策学部長みたいに。いるんだよ、いつでも。言いたいやつは環境情報でもいたんだよ。名前言えないけど冨田勝っていうのが、「もう環境情報は違うんだよ」みたいな、そういうことをあいつが学部長だったときは言っていて。そして元はね、相磯先生。faculty of environmental informationっていう名前を、1990年になる前に俺たち集まって、環境情報はこういう英語にしようって。それで、相磯さんの言ってた環境情報は「人間が情報との関係を持つ、その全てが環境なんだよ」っていう。それを環境って言うんだよって。だから環境情報っていうのは、例えばエコロジーとかそういう環境学じゃないんだよね、本当のenvironmentじゃなくて。最初、相磯さんの考えてたのはその意味だったの。それでenvironmentって言っちゃうと環境学になっちゃうから、environmental informationって言って、informationが主でenvironmentが修飾語だっていうふうにして、英語でやろうって言ったわけ。そしたら、そうこうしているうちに、清水先生みたいな本当の環境からの先生が来ちゃって、だんだんエリーカとか電気自動車とか言って、「結構環境やるじゃん」っていう先生が増えてきて。まあ今で言うと蟹江みたいな。それで、「やっぱ環境って言っとくか」みたいな話になって。冨田が学部長だったときだと思うんだよな、environment and information。2つあるからstudiesって付けようって言って英語名だけ書いたの、それで環境情報学部ってなって。だから割合、ファカルティの中では環境の先生が今、すごく強くなってるの。だけど俺は知ったこっちゃなくて。

SFCっていうのは、俺はいつも言ってたんだけど、「混浴風呂」。入ったことある？　混浴、混浴温泉、はやったよね。一応、入り口は男、女って書いてあるんだよ。それで、着替えるときは男、女。だけど中に入ると同じ風呂なんだよ。それがSFCなんだよ。だからどっちで入ってもいいんだよ。どういうことかっていうと、俺はずっと学部長のときこう言ってたの。「環境情報学部は人と地球だけ考えろ」って。人間がいて地球がある、これだけ考えていけばいい。これは、俺がインターネットを作ってるときも同じで、地球全体に1つの空間しかないのがインターネットだから合ってる。

だから、俺が書いてる環境情報学部のディスクリプションってみんなまだ残ってるんだよ。なぜ残ってるかっていうと、俺のあとになった環境学部長2人目なんだけど、ああいうのは事務から「これどうしますか、直しますか？」って言われて「いや、面倒くさいから前のままでいいよ」っていうのがあるから、俺の書いたのがだいぶ残ってる。それで俺は全部書き換えてあるので、俺の前のやつが残ってることはない。だから、環境情報学部はこういう言葉がまだ残ってるんだよね。

じゃあ総合政策学部はなんだっていうと、俺は総合政策学部じゃないんで残り全部。

(会場爆笑)

村井： そうすると、SFC全体では全部のことが考えられる。これが俺のSFC観なんだよね。それでこれは何度も言ってるんだけど、インターネット文明って、俺たちはもうインターネットは道具から始まって文明になった、社会全体がっていうのはこれは何度も使っているんで。だからこの文明は、道具使って恐ろしいことやるんだけど、でも1つしか無いんだよな、インターネットは。元の文明ってのは世界にたくさんあるんだけど、でもインターネット文明っていうのは1個しかない、インターネットは地球に1個しかないから。ここが一番伝えたいことで、俺たちは国と国との間でこの地球を生きてるけど、インターネットは1個しかない。これが一番のバリューだと思う。人類は、インターネットの前には地球全体を1つの空間だと思って人間が生きる空間を持ってなかった。だが、インターネットでそれが出来た。

でも、それと同時に国際空間も持ってる、戦争も起こる、経済制裁も起こるので、この2つを空間として同時に持ってて、それが当たり前だと思うのがインターネットネイティブ、インターネット文明時代の皆さん。俺たちはそれを作ってきたので。これを前提に1つの空間を作ってきたから、その間にいろんなコンフリクトもあったし、それからもっと重要なことは気が付かなかったね。みんな、もしインターネットが今日のようになるなら、あらかじめぶっ潰しておけば良かったって思うやつがきっといたと思うんだよ。だけど、そいつらが気が付く前に作っちゃった、従って出来たというところがあるので、これからどうなるかっていうと、潰しにかかってくるやつが絶対いるから。それで、これをどうするかをみんなに委ねたいね。

守れよー、地球で人類が初めて1つの空間を作ったんだから、これを1つ1つの国の権利で分断したり、ぶっ壊したり、バラけさせたりさせるなよ。頼むぞ、ここまでやってきたんだから。それで、それが両方で生きてることがとても大事だと。これがインターネットのこの授業で一番伝えたかったことだし、みんなにお願いしたいことでもある。

SFCは慶應義塾が本当に期待を持って作ったキャンパスなんだけど、福沢諭吉が『西洋事情』の中で、1866年だよ、「4つの海は一家。5つの族は兄弟。人類はみんな兄弟だ、ファミリーだ」、それで、左側にはそこが作ったもの。蒸気、経済、電気、電信、そしてそういった人間の道具たち。これが文明につながってくるっていう福沢先生の考えだったの。でも次の絵を見てください、恐ろしいでしょ。地球は1つで電信柱でつながってて、飛脚がそこを走ってるんだよ。インターネットだよ。それで、1866年にこの人(福沢諭吉)はそのコンセプトを持ってんだよ。鎖国してたばかりで飛び出た明治維新より前、このときにこの感覚を持ってるね。でもついに出来たんだよ。それで、福沢先生のこの思いはSFCが作ったんだよ、すごいね。

このSFCは、石川塾長という塾長のアイデアから出来てる。石川先生ってこういう顔してんだよ、あんまり知らなかったかもしれないけど。戦後最長の4期16年務めた塾長、すごいね。文化勲章だとか、勲章いっぱいもらってるね。慶應の塾長でこんなに勲章もらってる人はかなり少ない。この彼のスピーチ、SFCを作ったスピーチ。

(会場全体に音源が流れる)

音源中のナレーション： 西暦1983年5月15日、日吉記念館で開かれた慶應義塾創立125年記念式典で、石川塾長は旧来の大学教育の不備を指摘し、新しい大学の在り方を熱く語った。後にこれは、湘南藤沢キャンパスの誕生のきっかけとなる名演説として、人々の間に記憶されることになる。

音源中の石川塾長 (石川忠雄)： 教育の面におきましても、現在のような複雑で流動的で不確定な時代というのは、われわれが過去に経験しなかった新しい現象があとからあとから起こってくる時代であります。従ってその教育の問題も、ただ単に広く物を知るということではなくて、自分の頭で物を考える力、これをどういうふうに作っていくかということが、極めて大切になりつつあります。新しい現象に対して自分の頭で物を分析し、推理し、判断し構成する力、ここに教育の重点が移されてこなければならない。さらに、かつてわれわれが対象としなかった領域の研究というものも、ますます重大になりつつあります。しかも、学問分野との間の交渉領域の研究も極めて重大になってきております。こういうような学問の在り方の変化というものに対応していくために、これまでのような大学の体制だけでは決して十分ではないというふうに考えられるのであります。

村井： というわけでこれが1983年で、7年間の準備を経てSFCを作ったわけです。かなりのことがここで言い尽くされているんじゃないか？　SFCがどういうことであるべきかとか、今までのことにとらわれないとか。SFCができて30年経つと、その間に同じ名前の学部が全国で出来てる。それで、SFCのAO入試はみんなコピーされているよね。そりゃそうだよ、SFCうまくいったから。だけど、そこでまた新しい問題がどんどん出てきて新しい力が必要になり、そしてそのことにずっとサステイナブルに対応できる仕組みをSFCの中に作らなきゃいけない。いろんな苦労してきたけど、この間5年間、俺たちがいなくなる分のファカルティの補充っていうのを5年分まとめてやろうって言って採ったんだよ。そのときの教員を採るための基準になんて書いてあるか知ってる？　どうやって募集したか知ってる、教員を？　普通の大学は、経済学の教員が1つ足りないから1つ穴を埋めるぞ、とかそういうふうに聞くんだよ。コンピュータサイエンスな教員がいるって。そのとき、SFCはどういう教員を公募したんだろう。

(壇上から降りて学生席に行き、藤井進也准教授にマイクを傾ける)

藤井： ハハハ、僕ですか。いろいろカテゴリがありましたね。1番から30番、領域があるんですけど、0番っていうのがありましたね。**0番は、「これまでのSFCに無い研究領域」**でした。

村井： というわけで、俺はこれまでのSFCに無い研究領域、普通そういうの最後に書くんだよね。俺はそこから採ろうと思ってそれを0番っていうのにして、そしたら藤井が来たんだよ。それでこのときに来ている教員は、全部が藤井だったら困るんだけどさ、やっぱり今までにない人がいつでも入ってきて新しい力を作っていくっていうのは、とても大事なんじゃないかなと思ってやってみた。まあ画期的だったよ。大学の教員公募で「うちに無いやつ」っていう教員公募をする大学は絶対無かったと思うけど、そこで入ってきた人が必ず新しい力を作っていく。というわけで、成長し続けると思うよ。

このキャンパスはカトカンっていう人と、相磯秀夫先生っていう環境情報学部長で、カトカンは慶應大学の加藤寛先生です。政府税制調査会会長って書いてある。これが初めての消費税の導入をやったんだよ。初めての消費税導入をやったとき、SFC1期生しかいないんだよ。それで授業で相談してるんだよね、学生と。**「何パーセントにしようか」「消費税どうする？」みたいな。**次の日新聞見ると、「税制調査会会長、3パーセントの消費税に決定」って書いてあるんだよ。学生たち、みんななんて思ったか知ってる？　「あ、俺が決めた」って。そういうところがSFCの面白いところだよ。

次は相磯先生ね。相磯先生は僕らの先生なんですけど、そもそも**「相磯研究室からは、村井純、徳田英幸や坂村健をはじめとするコンピュータ関連分野の多くの研究者を輩出した」**って、相磯先生の良いこともっと書けよっていう。ハハハ。まあとにかく、この2人の学部長がこのキャンパスの顔で、俺実は秘密をこの間聞いたんだよ。井関先生っていう本当に作ってる人たちっていうのがいるんだよ。それが、この2人を学部長にするっていうストーリーの件をこの間初めて井関先生から聞いたんだよ。井関先生と高橋潤二郎っていう2人の先生が、このキャンパスの企みをずっと作っていたんだよ。本当の哲学者って石川先生から言われて。それであるとき、石川先生に陳情に行ったっていうんだよ。井関先生から聞いたんだよ？　フェイクニュースかもしれないよ、とか言って。ハハハ。でも井関先生は当時の副学部長だから。それで、プロデューサーが高橋潤二郎と井関さんなの。それで準備してて、「これだ、これだ」って言って大体の骨格ができて、俺なんかも東大から呼んで準備室とか入れて、インターネットをどうするかとか。

そしてある時期に、実は俺は行ったんだよ、石川さんのところに。それでこう言ったんだよ。「僕も高橋潤二郎先生も相磯先生も、ものすごくきちんとできるけど、やっぱり世の中にこれだけ違うことをやるっていうシンボリックな看板がいるんだ。だから経済学部から加藤をよこせ」って。一方加藤さんは「喜んで行くよ」って言ったらしいんだけどさ。それで加藤さんも三田では相当はみ出し者っていう感じだったからさ。もうあまりに外で活躍して有名だから、普通のアカデミズムから言うと、大体そういうのはちょっといろめがねで見られちゃう、まあSFCってそういう先生多いんだよね。

というわけで、SFCにいる人っていうのはなんとなく激しい人多いでしょ？　「イラクとアメリカがどうした」なんて言っても結局、「田中と中山しか出てこないじゃん、テレビ見ても」みたいなそういうところあって、まあSFCはそういう先生多いんだよ。昔も中国のことが出てくると小島先生が出てきてっていう。とにかくそういうことで加藤先生を呼んだんだって。そうするとこれも見事に成功したんだよ、やっぱり。SFCの1つのキャラクターをこの2人で作って、総合政策学部と環境情報学部なんて一緒だよって言ったんだけど、この2つの強い芯、総合政策と、ある意味のコンピュータサイエンスを中心とする環境情報学部の強い力っていうのを、シンボリックにこの2人は表してたかなと思います。

それで、そのときの環境情報学部側のブレインが斎藤信男先生で、僕や中村修さんの智将ですね、理工学部にいたね。彼がOSの専門家だったから、僕らはOSの勉強をするために筑波大学から移ってきた斎藤先生と一緒になりました。あとはもう時間が無いので飛ばします。歴史はこの授業でいろいろ話したので。

(スライドを見ながら)インターネットができました。インターネットはUNIXとパケット交換のARPANET。これ(ケン・トンプソン、デニス・リッチー)が両方の親で、それがバークレーで一緒になった。

(次のスライドに移って)これが俺が言わないとなかなか忘れられちゃう、1982年にこの男、Bill Joyはバークレー・ソフトウェア・ディストリビューション、BSDというUNIXを作ったときにTCP/IPを入れて、世界中にオープンソースで配ったの。これが重要なので、このレッスンは大学が世の中を変えるってことなの。インターネットは、大学ができたのはBillがバークレーで頑張ったから。

(次のスライドに移って)そしてPostelのことは、オペレーションだね、やっぱり。動かし続ける技術っていうのを、そう派手なことじゃないけど彼はきちんと動くためにどうすれば良いかってことをずっと考えられる人で、彼がいたからインターネットは動いたっていう話をするときに、ドメイン名とかね。俺も彼から「日本は頼むぞ、純」って言われて。

Postelがインターネットを動かすときに、どうしようって言って必ず俺を呼ぶんだよ。「太平洋の向こう側に1人、ちゃんとしたのがいる」って言って。そういう意味では彼は僕の大変重要な指導者であったと。

(次のスライドに移って)次、この人(Stephen Wolff)は恐ろしい人なんですよ。俺33歳とかだからね、インターネットつないでたとき。インターネットっていう、つまりそれまでは電話と電話をつなぐみたいな話は、国と国がトップ・トップでやるような話で、それを33歳の若者が勝手にアメリカとつないじゃったんだよな、世界と。こんなもの、政府が関与しないでそんなことやって国際問題になったらどうするのよ、みたいな心配をみんなしていて。それでそのときに俺がアメリカ行って、こいつのオフィスのところで「つなぐぞー」っていうのをやっていたけど、「ところでさ、これつながって上手くいっても日本の奴みんな心配してて、東大助手の若造が世界をつなぐみたいなことやってて、こんなこと許されるわけないってみんな言うんだよね」って言ったら、こいつが3分いなくなって、National Science Foundationのレターヘッドでこのメール書いてきたの。

「Dear Dr. Murai,　In light of our discussion this afternoon, on behalf of NSF it is a pleasure to grant internet access to the Japanese IP community. Sincerely,　Stephen S. Wolf　Division Director」

(会場拍手)

村井： これを3分で書いてきて、「Jun. Does it help?」。このスピーディーな…。額に飾ってあるよ、今。これを持って帰って東大に戻ってきて、「分かるこれ？　分かる？　National Science Foundation、アメリカの政府の正式なグラントだよ？」みたいな。どうして権威に頼るんだよっていうことも、でも権威にも簡単に突破できるんじゃない？　みたいなところも、しかもフェイクじゃないからね、これ。まあ、そんなんで。

(次のスライドに移って)ウェブはSFCから生まれたってことは言ったよね。Ted NelsonはSFCにいた教員。それが元になってハイパーテキストっていうんで、ワールド・ワイド・ウェブのTim Berners-Leeがウェブを作った。そういう意味ではSFCはインターネットをいっぱい生み出してるんだね。

最後に、2000年にこういう人口分布があったんだよな。それで、アジアっていうのはほとんど日本なんだよ、それで頭にきて。なぜ頭にきたかっていうと、アメリカ人と日本人がほとんど同じ人数なんだよ。2000年だろ？　1990年の後半に、インターネット・バブルが起こって、バークレーのやつらがみんなビジネス始まったんだよ。だから、研究開発してるのは俺たちだけなんだよ。そうすると、これがめちゃくちゃ日本が強かったんだよ。日本の研究開発で作ってたのがIPv6っていう、今お前らが使ってるバージョンの前の、バージョン4っていうんだけど、この開発を刈込っていうこのキャンパスでやっていて、それが世界の開発をずっとこのとき牛耳ってて、しかもSFCで。そこへ同僚のとんでもないやつが来て、「日本のインターネットは、どうしてこんなにぼろいの？」って言ったんだよ。俺はすごい頭にきて。そのときはもう超天狗で、俺たちが世界で一番先端のインターネットを作ってるんだ、って思ってたときに、平気な顔をして「日本のインターネットはどうしてこんなぼろいの」って。「何のことを言ってんだ、お前は」って言ったら、「役所で使ってない。経済で使われていない。だから、日本の経済はアメリカに後れを取るんだ」って言われて。だから「なんだ、このアメリカかぶれ」って思った。

それを言ったのがこいつ(竹中平蔵)、同僚、名前言えない同僚。それですごいよね、経済学者の視点と俺たちが作ってきた世界一だと思ってた話とが全く違うんだよね。でもよく考えてみるとそうなんだよ。政府で使われてないし、金融で使われてないし、だから経済にダメージを与えられているんだよ。なんでだよ、って思ったら1つ。こういう経済学者とかビジネスの人っていうのは、そういう言い方するんだよ。それで、「どうすれば良いですか」って言われると、「掛かった」みたいな、そういう金融コンサルタントってみんな大体そういう論法で話すわけ。「もうこうしなきゃだめですよ」って竹中さんが言うと、「どうすれば良いかな、どうすれば良い？」って俺も言っちゃったんだよね。そうしたら「総理のところへ行きましょう」って言われて。

それで、そのときに作ったスライドを持ってきたんだけど。これ、2000年に総理のところに行きましょうって言うから、総理用に作ったスライドなんだよね。それで、「総理、今までは電話のインフラと放送のインフラがあるんですけど、いろんなインフラがありますよね、我が国には。それでインターネットっていうのは、電話のインフラの上に乗せてデジタル通信をやってみたら、経済とか教育とか結構うまくいき始めたんですよね。もうちょっと頑張ると、あらゆることにインターネットは貢献できると思うんですけど、多分電話の(インフラの)上に乗ってると高い。だからネイティブのインフラを作ろうよ。」って言って。(スライドを指しながら)放送と電話は国の物だから弄ると怒られるので、他の分野で貢献するとか言ってるんですよね。それでもう1枚(スライドを)入れて、そうすると(スライド上の電話インフラと放送インフラの図の面積が)なんとなく細くなってる。「あれ？いつの間にかちょっと、ちょっとインターネットが(笑)」なんて。それで、「いや、これ気が付かないよね」みたいな。だから、ネイティブのインフラが要るんだよねって言いながら、悪乗りしてもう1枚(スライドを)作ったの。

(電話インフラと放送インフラの図のみ消されたスライドが表示され、会場爆笑)

村井： そしたらこれが上手く取り入れられて、あるとき総理が所信表明をするって言ったら、ここに夜中の2時頃、「明日総理が所信表明をするんですけど、キーワードが無い」って言われて。俺関係ねえなあ…そんなの、って思ったけど、この文章は始めは入ってて、「先端インターネットの技術の開発などの研究開発によるグローバルインターネットの課題解決へ積極参加する」。この文章は俺が入れたのね。そしたら各省庁を回らなきゃいけないんだよ、本当は。だけど、引っ掛かるワードが無いってわけ。だから「IPv6などにって、総理言ったらどうですか」って言ったら「それ良いね、入れよう」ってことになって。誰も知らないの、誰も。日本中誰も知らないの。IPv6って何、みたいな。そしたら所信表明の次の日、さすがに全ての新聞が囲みで「IPv6とは」って付けてたの。「やったー！」っていう、ハハハ。

(会場笑い。拍手)

村井： こういうやんちゃなことができるのは、SFCだよね。これは俺が技術者として生きてたら、こんなことは絶対起こらなかった。というわけで、SFCは素晴らしいところだなっていうので。

じゃあ、俺のスライド、まだ？ああ、もういいや、911話したわ授業で。

じゃあもう時間無いから。時間が来たのでこれで良いですか?他の質問とか。もう時間無いもんね。じゃあ、サユさん、マイク持っていただいて良いですか。

これが最後の皆さんへのメッセージです。僕は喋れなくなるかもしれないから書いてあるんです。バックアップのスピーカーがちゃんとありますんで、僕の言葉だと思ってください、どうぞ。

(スライドを見ながら)念のために書いておきました。まずは皆さん、今年のインターネットを最後まで履修してくれてどうもありがとう。

(会場拍手)

村井： それから30年、SFCでつながってくれた全ての人たち、昔の人も今日は来てくれて本当に感謝いたします。どうもありがとう。

(会場拍手)

村井： それからさっき、「みんなに任せたぞ」って言ったけど、俺は30年、50年、この世界を作ってきた、みんなと一緒に。でもこれから30年、50年、そして100年、ここを目指したことはみんなに任せます。頑張ってください。もう安心しています、みんながこれをやってくれると信じています。あの、SFCで…

(涙ぐみながら__TA：須田に続きの代読を頼むジェスチャー_)_

TA(須田)： SFCで働けて良かった！とても楽しかった！

(会場拍手)

TA(須田)： SFCにきてよかった！とても楽しかった！

(会場拍手)

村井： SFCの学生と卒業生は、みなさんは！私の誇りです！本当に。どうもありがとう。

(会場拍手)

村井： 30年間どうもありがとう！

(会場拍手)

村井： どうもありがとうございました。

(会場拍手)

教員： 先生、先生そのままで。

(花束贈呈)

村井： ありがとう。(ハグをする)

(会場拍手)

村井： ああ、よく来てくれた…。ありがとう。(ハグをする)

(会場拍手)

教員： 先生、せっかくなので履修者の方たちと一緒に写真を撮りたいなと思うのですが、大変申し訳ないんですけどステージから降りていただいて、そこで上からなるべく広角で撮りたいと思います、すみません。お花も持っていただいて。

大丈夫ですか。じゃあ、あとで2ショットを撮る権利を与えよう！

(写真撮影)

教員： ありがとうございました。じゃあみなさん一回戻っていただいて。

(会場拍手)

村井： どうもありがとう、どうもありがとう。

教員： 今期の授業も本当にありがとうございました。みなさんのご協力のお陰で、時間もおさずに何とか終われましたので本当にありがとうございました。

(会場拍手)

考察

20年前に、WWW、インターネットを知りその凄さに感動し、どこに行けばちゃんと学べるかを探して、村井先生の居るSFCを見つけて進学しました。
久しぶりに村井先生の講義を拝聴し、学生時代に聞いていた講義を懐かしく思うとともに、あの話し方は独特でとても惹きつけるし印象に残ります。
日本のインターネットインフラが安価で高速で安定していて、検閲のない自由なインターネットができているのは村井先生のおかげです。
卒業して16年後の私は共同創業者取締役CTOをしてます。一緒にインターネットを楽しくする仲間を募集中！

当初、AWS Transcribeを使って文字起こしをしてみました。
- しかし、精度が低すぎたので人力で行いました。
- 2020年の音声認識の精度の記録として処理結果のJSONファイルを一応アーカイブ。
Amazon欲しい物リスト
Buy me a coffee

頂いた品物

Y.O様 — ありがとうございます！しっかり勉強します！=> 無事合格しました！
@castanea — ありがとうございます！3杯も！
N様 — ありがとうございます！Intel経営を学びたいと思います。
R.O様（2021/12/6）— Amazon Wishlist経由のギフトをありがとうございます！年末の掃除と、夜間のランニングが安全に行なえます！

</details>

{/* textlint-enable */}