Aulvem Blog (日本語)

楽天APIがJANを返さない問題と、横断マッチングの3段階

Sat, 27 Jun 2026 00:00:00 GMT

楽天とYahoo!の商品APIを横断して同じ商品を比べようとすると、最初の壁が「そもそも同じ商品をどう同定するか」だった。価格をどう計算するかの前に、AモールのこれとBモールのこれが同一商品だ、と機械が判断できないと比較表が作れない。

ここで詰まったのが JAN（商品に付く 13 桁/8 桁のバーコード番号）の扱いだ。Yahoo! ショッピングは jan_code で正引きできるのに、楽天の商品検索APIはレスポンスにJANを返さない。同じJANで両モールを引けば一発で結べる、という前提が片側で崩れる。

個人でヤスゴロという価格ウォッチャーを作って公開した。複数モールの実質価格を横断で比べ、ウォッチした消耗品が安くなったら通知する、というものだ。その横断比較を成立させるために、JANが揃わない前提でマッチングを確実性で3段階に倒した。その設計を共有します。

楽天とYahoo!でJANの扱いは非対称

楽天とYahoo!は、JANの取得しやすさがそもそも違う。ここを揃っているものとして設計すると、楽天側で必ず破綻する。

Yahoo! ショッピングの商品検索は jan_code という専用パラメータを持ち、JANで直接引ける。レスポンスにも janCode が乗ることがある。つまりJANが分かっていれば、その商品ページを正引きできる。

楽天の商品検索APIにはJAN専用パラメータが無い。実装では JAN 文字列を keyword に投げる間接的なやり方になる。しかもJANはレスポンスの構造化フィールドではなく、商品説明文（itemCaption）の中に紛れていることが多い（Anker のような型番商品で実際にそうだった）。だから楽天側は「keyword=JANで出たヒットが、本当にそのJANの商品か」を後から確かめる工程が要る。

この非対称が出発点になる。Yahoo!は信頼してJAN確定に使え、楽天は確証を挟まないと使えない。

確実性で3段階に倒す

同一商品の同定を、確実性の高い順に3段階へ落とした。全件をJANで突合しようとせず、確実に結べるものだけを最上段に置く。

段	方法	横断比較に使う	通知を出す
① JAN突合	Yahoo! 正引き＋楽天 keyword=JAN を確証スコアで判定	使う（確定したものだけ）	出す
② 名前ファジー一致	型番・容量・ブランドでスコア化し候補提示→ユーザー確認	ユーザー確認後に使う	確認済みのみ
③ マッチ不能	単一モール（URL貼り付け等）として扱う	使わない	単一モールの値下げのみ

下段ほど確証が弱いので、横断比較と通知の権利を絞る。①で結べたものだけが「誰が見ても同じ商品」として比較表に並び、②③は確証の度合いに応じて扱いを下げる。

flowchart TD
  In[入力: JAN / 商品名 / URL]
  Kind{種別判定}
  Jan[① JAN突合]
  Score{確証スコア}
  Fuzzy[② 名前ファジー一致]
  Cand{候補あり?}
  Single[③ 単一モール]
  Cross[横断比較に採用・通知可]
  Pending[候補提示→ユーザー確認待ち]
  Watch[単一モールの値下げのみ追う]

  In --> Kind
  Kind -->|JAN| Jan
  Kind -->|商品名| Fuzzy
  Kind -->|URL| Single
  Jan --> Score
  Score -->|high ≥0.8| Cross
  Score -->|mid ≥0.5| Pending
  Score -->|low <0.5| Single
  Fuzzy --> Cand
  Cand -->|あり| Pending
  Cand -->|なし| Single
  Pending -->|確認| Cross
  Single --> Watch

入力がJANなら①、商品名なら②、URLなら③へ振り分ける。①の中でも確証が弱ければ②③へ落ちる、という二段構えにした。

①JAN突合: 楽天は「JANらしさ」を加点で確かめる

JAN突合といっても、楽天は「keyword=JANで出たヒットが本当に同じ商品か」を確証する必要がある。ここを確証スコアの加点方式にした。

Yahoo!は jan_code 正引きなのでそのまま確定（通知も発火可）に置ける。問題は楽天で、1ヒットごとに次を足し引きしてスコアを出す。

商品名か説明文にJAN文字列を含む … +0.5（最も直接的な証拠）
製品検索API由来の価格レンジ内 … +0.3 / レンジ外 … −0.4
型番か容量が読み取れる … +0.2

スコアの閾値で3つに割る。0.8 以上なら確定（jan・通知発火可）、0.5 以上は要確認（fuzzy に落として通知不可）、0.5 未満は破棄（横断に出さない）。確証の弱いヒットを確定扱いしないことが、誤名寄せを防ぐ一番効く制御だった。

// 楽天1ヒットのJAN確証スコア（抜粋）
let s = 0;
if (hit.itemCaption.includes(jan) || hit.itemName.includes(jan)) s += 0.5;
if (range) {
  const lo = range.minPrice * 0.7;   // 下振れ30%許容（型落ち・並行品）
  const hi = range.maxPrice * 1.5;   // 上振れ50%許容（送料込・セット品）
  if (hit.itemPrice >= lo && hit.itemPrice <= hi) s += 0.3;
  else s -= 0.4;                      // レンジ外＝異常マッチ強疑い
}
if (modelOrCapacityConsistent(hit)) s += 0.2;

価格レンジは楽天の製品検索API（productCode=JAN）が返す最小〜最大価格から作る。型落ちや並行輸入で下に外れるぶんは 0.7 倍まで、送料込みやセット品で上に外れるぶんは 1.5 倍まで許容する。レンジから大きく外れた価格は、容量違い・色違い・別商品の混入を疑って減点する。

ただ、この製品検索APIが実測でかなり404を返した。価格レンジが取れないヒットが多く、レンジ加点に頼り切れない。そこで横断相手（Yahoo!の同JANヒット）の代表価格を基準にした確証を足した。楽天ヒットの名前に、Yahoo!側から抜いた型番トークン（英数混在5字以上＝ほぼ一意）が含まれ、かつ価格が相手価格の ±40% 以内なら確定へ昇格させる。型番が一致しても価格バンドで偶然一致を弾く、という二重条件にしている。

実際に動く比較画面はヤスゴロのライブアプリで見られる（ログイン不要・無料）。同一商品が複数モールで並ぶのは、この①で確定したものだ。

②名前ファジー一致: 候補提示までで自動確定しない

商品名しか手がかりが無い入力は、型番・容量・ブランドでスコア化し、候補を出すところまでで止める。自動で同一商品と断定はしない。

ファジースコアの配点はこうした。型番が最も強いシグナルになる。

型番一致 … +0.5
ブランド一致 … +0.2
容量一致 … +0.2
残りトークンの重なり（Jaccard係数）… +0.1 × 係数

EH-NA0J のような型番は商品名から正規表現で抜き、容量は 54枚×3 を「1パック54枚 × 3パック = 合計162枚」のように分解して比べる。スコアが 0.6 以上の候補だけを提示し、一つも超えなければ最良の1件を③の単一モールへ落とす。

候補を確定するのはユーザーだ。提示された候補から「これは同じ商品」と確認したものだけをマスタ化する。逆に、誤って結ばれた組み合わせはワンタップで除外でき、その組は突合候補から永久に外れる（再び候補に上がってこない）。自動マッチの精度を上げ続けるより、確認導線と取り消し導線を素直に置くほうが、消耗品の横断比較では現実的だと思う。

③マッチ不能: 単一モールの値下げ通知に倒す

どの段でも結べなかった商品は、単一モール扱いにする。横断の最安比較には混ぜず、そのページ自身の値下がりだけを追う。

URL貼り付けで登録した単品も最初からここに入る。横断比較の土俵に乗らないので「他モールより安い」とは言わないが、「前より安くなった」は言える。比較できないものを無理に比較群へ入れて誤った最安を出すより、できることだけを正直にやる方針にした。

誤名寄せを防ぐのは「確定だけ通知する」設計

3段階に分けた一番の理由は、間違った同定のまま通知を飛ばさないためだった。通知が発火できるのは、JAN確定（jan）とユーザー確認済み（user_confirmed）だけ。ファジー段の要確認も、単一モールも、通知の発火条件からは外している。

価格を計算する前に、同定の確実性で通知の権利を握っておく。ここを握らないと、別商品の値下がりを「ウォッチ中の商品が安くなった」と誤報してしまう。横断比較の信頼は、結局この同定の足場が決めていた。

ポイント還元込みの実質価格をどう計算したか（確実性で価格を3層に分けた話）は、実質価格の計算メモに書いた。あちらが「価格をどう計算したか」、この記事が「同じ商品をどう同定したか」で、2つ揃って横断比較が成立する。動くものはヤスゴロで確かめてほしい。

よくある質問

楽天 API は JAN をまったく取得できないの？

商品検索APIのレスポンスにJAN専用フィールドはなく、JAN専用の検索パラメータもありません。実装上は keyword に JAN 文字列を投げる間接突合になり、JAN自体は商品説明文（itemCaption）に含まれていることが多い、という形です。一方 Yahoo! ショッピングは jan_code パラメータで正引きでき、レスポンスにも janCode が乗るので、この非対称が横断比較の出発点になります。

なぜ全部を JAN で突合しないの？

JANが揃わない商品で無理に突合すると、別商品を同一商品として束ねる誤名寄せが起きるからです。楽天はJANを直接返さないので、keyword=JANで出たヒットが本当に同じ商品かは別途確証が要ります。確実にJANで結べるものだけを①の確定層に置き、確証が弱いものは②の候補提示、結べないものは③の単一モール通知へ落とす、と確実性で段階を分けています。

名前ファジー一致を自動で確定しないのはなぜ？

型番・容量・ブランドが一致してもスコアは確率でしかなく、自動で同一商品と断定すると誤マッチのまま通知が飛ぶからです。ファジー段は候補を提示してユーザーが確認したものだけをマスタ化し、誤って結ばれた組み合わせはワンタップで除外（その組を突合候補から永久に外す）できるようにしました。通知が発火するのはJAN確定とユーザー確認済みだけに限っています。

マッチできなかった商品はどうなる？

③のマッチ不能として単一モール扱いになり、横断比較からは外して、そのページ自身の値下がりだけを追います。URL貼り付けで登録した単品もここに入ります。横断の最安比較には混ぜず、単独の価格ウォッチとして通知する形です。

ポイント還元込みの「実質価格」をどう計算したか — 3層に分けた設計メモ

Mon, 15 Jun 2026 00:00:00 GMT

個人で価格ウォッチャーを作って公開した。表示価格からポイント還元を引いた実質価格で複数モールを比べ、ウォッチした消耗品が安くなったら通知する、というものだ。作る前は「表示価格 − もらえるポイント」を出すだけ、と軽く見ていた。実際に手を動かすと、その一行がいちばん詰まった。

理由は3つあった。全部のポイントを引くと数字を盛れてしまう。確実にもらえるポイントと「たぶんもらえる」ポイントを同列に足すと、一番安いはずの店が実は条件付きだった、という事故が起きる。還元率の単位はモールでバラバラだし、端数の扱いを間違えると実額と数円ずれる。

この記事は、その実質価格をどう計算したか、設計で決めたポイントを共有するものです。結論から言うと、ポイントを確実性で3層に分け、層ごとに端数処理してから合算し、ランキングには確実な層だけを使う、という形に落ち着いた。同じように「ポイント込みでどっちが得か」を計算したい人の手がかりになればと思う。

まず「実質価格」を定義する

実質価格は、表示価格から「その買い物でもらえるポイント」を引いた金額だ。1,000 円の商品に 100 ポイント付くなら実質 900 円、と考える。表示価格そのものより、財布から最終的に減る額に近い。

ただしポイントは現金と完全には同じでない。使途が限られ、期限もある。今回は「次の買い物で 1 ポイント = 1 円として使える」という前提を置いて円換算した。この前提を最初に固定しないと、店をまたいだ比較がそもそも成立しない。定義に前提を含めておくところからが設計だった。

素朴な実装はどこで壊れたか

最初に書いたのはこれだ。

const effectivePrice = displayPrice - totalPoints; // これだと盛れる

短いが、3 つの穴があった。

もらえるか確実でないポイントまで引いてしまう。要エントリーのキャンペーンや、自分の SPU 倍率を当て込んだ分まで引くと、表示上いちばん安く見える店が「条件を全部満たして初めて届く価格」になる。
還元率の単位がモールで違う。楽天の倍率、Yahoo! のキャンペーン加算、期間限定ポイント。これを一括で掛けると桁がずれる。
端数。ポイントは多くの場合 floor（切り捨て）で付く。複数の還元をまとめて足してから floor すると、実際の付与額と数円ずれる。

数円のズレでも、1 位と 2 位が入れ替われば「どこで買うのが得か」の答えが変わる。盛らないことと、ズレないこと。実質価格はこの 2 つを同時に満たさないと、ただの参考値に落ちる。ここで一度作り直すことにした。

設計の軸: ポイントを確実性で3層に分ける

作り直しで据えた軸が、ポイントを「どれだけ確実にもらえるか」で3層に分けることだった。

層	中身	確実性	ランキングに使う
① 確定	API が返す実付与ポイント	確実	使う
② 条件付き	公知のキャンペーン（5 と 0 のつく日など）	要エントリー等で変わる	使わない
③ 仮定	ユーザー自身の SPU 倍率・買い回り	自己申告	使わない

確定層だけで順位を決め、②③は「最大でここまで下がる」という幅として見せる。並び順は誰にとっても同じ（確実な情報だけで決まる）で、上振れは各自の条件で変わる、という住み分けにした。

flowchart TD
  Price[税込表示価格]
  L1[① 確定: API実値ポイント]
  L2[② 条件付き: 公知キャンペーン]
  L3[③ 仮定: ユーザー設定]
  Rank[ランキング rankKey = 価格 − ①]
  Eff[表示する実質価格 = 価格 − ①②③]

  Price --> L1 --> Rank
  Price --> L2 --> Eff
  Price --> L3 --> Eff
  L1 --> Eff

計算結果には、含まれた最も弱い層を確実性ティアとして持たせた。型で言うとこれだけだ。

type CertaintyTier = 'confirmed' | 'conditional' | 'assumed';

③（仮定）を含む価格は通知を発火させない、というルールもここに紐づく。自己申告のポイントを根拠に「買い時です」とは断定できない。発火するのは確定だけ、もしくは要エントリーを開示した条件付きまで、と決めた。

端数は層ごとに floor してから合算する

ポイントの floor は、層をまたいで最後に一度だけ、ではいけない。各層で floor してから足す。

let pts = Math.floor(base * rate); // 層ごとに切り捨て
if (cap != null && pts > cap) {
  pts = Math.min(pts, cap); // 上限は floor 後のポイント円に適用
}

実際の付与も「キャンペーンごとに切り捨てて付く」ことが多く、合算してから floor すると実額と 1〜数円ずれる。上限（cap）の当て方も同じで、floor したあとのポイント円に対して Math.min を取る。先に cap してから floor すると、やはり 1 円ずれる。地味な順序だが、ここが表示の信頼に効いた。

倍率の持ち方にも癖がある。キャンペーンの「+4 倍」は、税込価格への追加付与分（増分）として持つ。等倍（1 倍）は増分 0 だ。倍率をそのまま価格に掛けると、標準でもらえるポイントを二重に数えてしまう。だから「増分だけ」を率として保持した。

送料はあえて実質価格に入れない

送料額は、どのモールの検索 API からも取れない。だから実質価格には足さないと決めた。推測で足すと、取れないものを埋めるための誤差を自分で持ち込むことになる。

代わりに、送料込み / 送料別 / 不明のフラグを持たせ、送料込みのものだけを同じ土俵で比較する。

// 送料込みのものだけを主比較群に入れる
function isComparableForRank(listing: Listing): boolean {
  return listing.postageFlag === 0; // 0=送料込, 1=送料別, null=不明
}

送料別と送料込みを混ぜて最安を出すと、送料で逆転するのに気づけない。送料別・不明のものは主比較群から外し、注記として開示する。入れられない情報を「入れない」と決めて、その判断を表に出すほうが、半端に推測するより誠実だと思う。

振り返り

実質価格は「表示価格 − ポイント」と一行で書けるのに、信用できる数字にしようとすると、確実性の層分け・層ごとの floor・ランキングキーの分離・送料の除外、と地味な判断が積み重なった。派手な処理はどこにもない。ただ、ここを雑にやると「一番安いはずが条件付きだった」で読み手の信頼を失う。時間を使ったのは、結局この計算の足場を固めるところだった。

この3層計算は、ウォッチした消耗品について毎日自動で回し、確定層ベースで本当に安くなったときだけ通知する、という形で動いている。公開したのはヤスゴロという価格ウォッチャーで、ログイン不要・無料で使える。

よくある質問

ポイントを全部引いた金額で比較してはだめ？

全部引くと数字を盛れてしまいます。要エントリーのキャンペーンや自分の SPU 倍率まで引いた価格は「条件を全部満たせば届く価格」で、誰にとっても確実な最安ではありません。確実にもらえる API 実値ポイントだけを引いた値でランキングし、条件付き・仮定のポイントは別枠のレンジとして見せています。

期間限定ポイントや要エントリーのキャンペーンはどう扱う？

実質価格の本体には乗せず、条件付きの層（②層）として分けて計算し、要エントリーや上限到達のフラグを付けて開示します。金額として断定するのは API が実値を返す確定ポイントだけ。期間限定や要エントリーは「最大でここまで下がる」という幅で見せ、通知の発火条件からも外しました。

送料を実質価格に入れないと最安が逆転しない？

逆転し得ます。ただし送料額はどのモールの検索 API からも取れないので、推測で足すとかえって誤差を持ち込みます。今回は送料を実質価格に算入せず、送料込み/送料別/不明のフラグを持たせ、送料込みのものだけを同じ土俵で比較しました。送料別のものは主比較群から外し、注記で開示する形です。

なぜランキングと表示する実質価格で使う層を変えるの？

並び順は誰が見ても同じであってほしいからです。ランキングのキーには確定層だけを使い、表示する実質価格は確定＋条件付き＋仮定を引いた値にしています。こうすると「一番安い順」は確実な情報だけで決まり、各自の条件で変わる上振れは表示価格側のレンジで伝わります。

llms.txt / llms-full.txt を Astro で多言語生成する — Aulvem の GEO 実装

Sun, 14 Jun 2026 00:00:00 GMT

AI 検索や LLM にサイトを読ませる入口として、llms.txt という提案がある。robots.txt や sitemap.xml と似た位置の、サイトルートに置くプレーンテキストの目次だ。仕様はまだ固まりきっておらず、主要な LLM ベンダーが公式に消費を保証しているわけでもない。それでも生成コストが小さいので、Aulvem では出すだけ出しておく方針にした。

この記事は、その llms.txt / llms-full.txt を Astro で動的生成し、英日 2 言語に分けて出すまでの実装記録です。効果があったかどうかの話はしない。現時点で計測できる流入は無く、断定できる材料が無いからだ。あくまで「何を、どう生成しているか」だけを書く。Zod schema で運用ルールを強制するや hreflang をリシプロカルに出すと同じ、「frontmatter と Content Collections を単一情報源にする」系列の続きにあたる。

llms.txt とは何か

llms.txt は、サイトルートに置く LLM 向けの Markdown 形式の目次だ。sitemap.xml が機械可読な URL 一覧なのに対し、llms.txt は「このサイトは何で、どこを読めばいいか」を自然言語の要約付きで並べる点が違う。

提案元（llmstxt.org）のスペックでは、ファイル先頭に H1 のサイト名と引用ブロックの概要を置き、その下に H2 でセクション分けしたリンク一覧を並べる、というゆるい構造が決まっている。各リンクには - [タイトル](URL): 一文の説明 の形で注釈を添える。

スペックはもう 1 つ /llms-full.txt という慣習を示している。こちらは目次ではなく、各ページの本文を展開した全文寄りのインデックスだ。LLM がリンクを辿らずに 1 ファイルで内容を把握できるようにするためのもの。Aulvem では両方を出している。

	llms.txt	llms-full.txt
役割	軽い目次（リンク + 要約）	全文寄りインデックス（抜粋 + 見出し + タグ）
載せる記事	代表記事を 7 本に絞る	全記事
言語	言語ごとに分ける（EN / JA）	1 本に英日を混ぜ、各エントリに言語タグ
サイズ	小さい	大きい

Astro で生成する基本形

Astro の file-based API ルートを使えば、src/pages/ 配下に .txt.ts を置くだけで動的にテキストを返せる。GET ハンドラから Response を返し、Content-Type を text/plain にするのが基本形だ。

// src/pages/llms.txt.ts
import type { APIContext } from "astro";
import { renderLlmsTxt } from "../lib/llmsTxt";

export async function GET(_context: APIContext) {
  const body = await renderLlmsTxt({ docLang: "en" });
  return new Response(body, {
    status: 200,
    headers: {
      "Content-Type": "text/plain; charset=utf-8",
      "Cache-Control": "public, max-age=3600",
    },
  });
}

.txt.ts という拡張子の付け方がポイントで、ビルド時に /llms.txt という URL に静的出力される。中身の生成ロジックは別ファイル（src/lib/llmsTxt.ts）に切り出して、ルート側は薄い入口だけにしている。こうすると言語別エンドポイントを足すときにロジックを再利用できる。

スタックはこれだけで足りる。

	パッケージ	用途
	`astro` (API routes + `astro:content`)	ルート定義と Content Collections の取得
	`typescript`	レンダラの型付け

Content Collections を単一情報源にする

llms.txt の中身は、記事一覧を手で書かない。Content Collections（astro:content の getCollection）から記事とプロダクトを取得して、その場で組み立てる。手書きのリストにすると記事を足すたびに更新を忘れて、本文と llms.txt がずれる。

// src/lib/llmsTxt.ts（抜粋）
export async function renderLlmsTxt(opts: LlmsTxtOptions): Promise<string> {
  const services = await getCollection("services");
  const blog = await getCollection("blog", ({ data }) => !data.draft);

  // 新しい順に並べる。プロダクトは status（active→preparing→archived）優先
  blog.sort((a, b) => b.data.pubDate.getTime() - a.data.pubDate.getTime());
  // ...セクションを組み立てて join("\n") で返す
}

getCollection("blog", ({ data }) => !data.draft) のフィルタで draft: true を落としているのが要点だ。これを忘れると、書きかけの下書きが llms.txt に載って、まだ公開していない URL を LLM に案内してしまう。sitemap や RSS と同じ除外条件をここでも揃えておく。

記事の説明文には、frontmatter の summary（無ければ description）をそのまま使う。summary は「AI 引用される短い答え」として全記事に必須で書いているので、llms.txt の注釈と本文側の TLDR が同じ情報源から出る。ここでも frontmatter が単一情報源になっている。

多言語をどう分けるか

ここが多言語サイトの肝で、Aulvem は filterLang と docLang の 2 軸でレンダラを動かしている。

filterLang: どの言語の記事・プロダクトを載せるか（ja なら日本語エントリだけ）
docLang: 見出し・概要・利用条件など、ドキュメント自体の文言をどの言語で書くか

この 2 軸を分けたことで、同じレンダラから 3 本のエンドポイントを出せる。

// src/pages/llms.txt.ts        → 英語見出し・全言語の記事
renderLlmsTxt({ docLang: "en" });

// src/pages/ja/llms.txt.ts     → 日本語見出し・日本語の記事だけ
renderLlmsTxt({ filterLang: "ja", docLang: "ja" });

英語ルートの /llms.txt は filterLang を指定していない。これは英語版を「サイト全体の入口」と位置づけて、両言語の記事を拾える状態にしているためだ。日本語版 /ja/llms.txt は filterLang: "ja" で日本語面に閉じる。

flowchart LR
  CC[Content Collections<br/>blog + services]
  R[renderLlmsTxt<br/>filterLang / docLang]
  EN["/llms.txt<br/>docLang=en"]
  JA["/ja/llms.txt<br/>filterLang=ja, docLang=ja"]

  CC -->|getCollection| R
  R --> EN
  R --> JA

代表記事は docLang の言語で絞る

1 つ設計判断がある。英語版 /llms.txt は記事自体は両言語を拾えるが、「代表記事（Featured posts）」のセクションだけは docLang の言語に絞っている。

// 代表記事は docLang の言語のものだけを出す
const featuredSource = filteredBlog.filter(
  (p) => entryLangLocal(p.id) === opts.docLang,
);

翻訳ペアの両方を代表枠に並べると、同じ内容が 2 言語で 2 枠を占めて、限られた枠の中のユニークなシグナルが半分になる。だから代表枠はドキュメント言語のものに揃えて、英日をまたいだ全集合は llms-full.txt 側に任せる。枠が有限なリスト（代表記事 7 本）では言語を絞り、容量の制約がゆるい全文ダンプでは両言語を載せる、という住み分けにしている。

llms-full.txt — 全文インデックスと言語の相互参照

llms-full.txt は別ルート（src/pages/llms-full.txt.ts）として、全記事の本文抜粋・見出し・タグを 1 ファイルに展開する。MDX 本文は stripMdx で記法を剥がし、clip で 500 字に切ってから載せる。

各エントリには言語タグ（(ja) / (en)）を付け、さらに対になる言語版があれば Lang-Alt でその URL を相互参照させている。

// 対になる言語版の URL を Lang-Alt として添える
const alt = altByBase.get(slug);
if (alt) {
  const otherLang = lang === "ja" ? "en" : "ja";
  const otherPath = alt[otherLang];
  if (otherPath) {
    lines.push(`Lang-Alt (${otherLang}): ${SITE}${otherPath}`);
  }
}

これは hreflang と同じ発想だ。HTML 側で両言語にある記事だけ alternate を相互に出す実装を hreflang の記事で書いたが、llms-full.txt でも「この記事には対になる言語版がここにある」を LLM 向けに明示しておく。同じ記事の英日が別物として扱われて重複カウントされるのを避けたい意図がある。

robots.txt との役割分担

llms.txt は robots.txt の代わりではない。クロールの可否を伝えるのは robots.txt で、llms.txt が伝えるのはサイトの内容と読みどころだ。学習や引用を許す/許さないの最終的な許諾は robots.txt 側が握っている。

Aulvem は llms.txt の中に利用条件（Usage & citation）セクションを置いて、引用は歓迎・引用時は元 URL へリンクしてほしい、学習も現時点では許可、という方針を自然言語で書いている。ただしその末尾に「最終的なボット方針は robots.txt を参照」と添えて、機械可読な権威は robots.txt にあると明示する。llms.txt はあくまで案内文で、規範を上書きするものではない、という立て付けにしてほしいところだ。

ここを曖昧にすると、llms.txt に「学習禁止」と書いたのに robots.txt は全許可、のような食い違いが起きる。2 つのファイルの方針は手で揃える必要がある。

落とし穴と運用ルール

実装で踏みかけた点を整理しておく。

draft 除外を 3 本すべてで揃える: getCollection のフィルタを共通レンダラに置いて、llms.txt・ja/llms.txt・llms-full.txt が同じ除外条件を通るようにする。1 本だけ素通しにすると下書きが漏れる
filterLang と docLang を混同しない: 「載せる記事の言語」と「文言の言語」は別軸。英語版で日本語記事も拾うために filterLang を未指定にしている設計を、後から読んでバグと勘違いして filter を足さないこと
代表記事の言語絞り込み: Featured だけは docLang で絞る。ここを外すと翻訳ペアで枠が埋まる
Cache-Control を付ける: 3 本とも max-age=3600 にしている。生成は軽いが、毎リクエスト再生成する必要は無い
利用条件と robots.txt の整合: 方針を変えるときは両方を直す。llms.txt 単体で完結させない

まとめ

llms.txt は、Content Collections を単一情報源にして Astro の API ルートから動的生成すれば、記事を足すたびの手動メンテが要らなくなる。多言語は filterLang（載せる記事）と docLang（文言）の 2 軸に分けると、1 つのレンダラから英語版・日本語版・全文版の 3 本を出せる。

効果があるかどうかは別の話で、ここでは触れない。llms.txt が AI 検索の流入にどう効くかは、まだ慣習も計測も固まっていない段階だと思う。Aulvem としては「コストが小さいので出しておく、権威は robots.txt に置く」という構えで運用している。

frontmatter を単一情報源にする設計は Aulvem ブログの作りから続く系列なので、合わせて読むと位置づけが分かりやすいかもしれない。

よくある質問

llms.txt と llms-full.txt は何が違う？

llms.txt は「このサイトは何で、どこを読めばいいか」を要約付きリンクで並べた軽い目次。llms-full.txt は各記事の抜粋・見出し・タグまで含めた全文寄りのインデックスです。Aulvem では前者を代表記事 7 本に絞ったキュレーション、後者を全記事の本文抜粋ダンプとして役割を分けています。

llms.txt を出せば AI に読まれて流入が増える？

現時点でそれは断定できません。llms.txt は提案段階の慣習で、主要な LLM ベンダーが公式に消費を保証しているわけではない。robots.txt と sitemap.xml が依然として権威的なボット向けシグナルです。Aulvem は生成コストが小さいので「出しておく」程度のスタンスで置いていて、流入効果を主張する材料は持っていません。

多言語サイトで llms.txt は言語ごとに分けるべき？

Aulvem は英語ルート（/llms.txt）とは別に日本語版（/ja/llms.txt）を出しています。見出しや利用条件の文言を読み手の言語に合わせたいのと、代表記事をその言語のものに絞りたいため。全文を 1 本に混ぜる llms-full.txt とは別系統として両方を持たせています。

robots.txt があるのに llms.txt も要る？

役割が違います。robots.txt はクロールの可否を伝えるルールで、llms.txt はサイトの内容と読みどころを伝える目次。学習・引用の最終的な許諾は robots.txt が authoritative で、llms.txt はあくまで補助的な案内です。Aulvem は llms.txt の利用条件セクションにも「最終方針は robots.txt を参照」と明記しています。

hreflang を両言語にある記事だけリシプロカルに出す — Aulvem の i18n カスタマイズ

Sat, 30 May 2026 00:00:00 GMT

Astro 標準の i18n はルーティングを生成してくれるが、hreflang は自分で出す必要がある。

素朴に「サイトの全 locale 分の alternate を出す」実装にすると、片方の言語にしか実体がない記事でも alternate が出てしまい、結果として 404 を指すリンクが hreflang として広告される。これは Google のリシプロカル hreflang ルール違反で、検索エンジンに壊れた多言語シグナルを送ることになる。

Aulvem では Content Collections を見て両言語に実体がある時だけ <link rel="alternate" hreflang> を出すヘルパを書き、Seo.astro が条件付き出力する構成にした。Aulvem ブログの作りの FAQ で予告した「hreflang は MDX frontmatter から独自実装した」の派生記事 3 本目です。

全 locale に alternate を出すと何が壊れるか

雑な実装でよく見るのが、「サイトがサポートする全 locale 分の <link rel="alternate" hreflang> を無条件で出す」パターンだ。EN / JA の 2 言語サイトなら、どの記事でも常に 2 本の alternate を吐く。

問題はここで、特定の記事が片言にしか存在しない場合に起きる。

JA だけ書いた記事に EN の alternate が出る → 指す URL は 404 になる
Google は「指された URL が alternate を返さない」と判断する（リシプロカル要件不成立）
結果としてその hreflang は無視される。最悪、サイト全体の多言語シグナルが薄まる

Google の hreflang ガイドラインは明示的に「相互参照が必要」「存在しない URL を指さない」を要件として挙げています。雑な実装は要件不成立で実質ノーカウントなので、出さない方がマシな状況も起きる。

Google が要求する 2 つの条件

hreflang を機能させるための必須条件は次の 2 つだ。

リシプロカル: A → B の hreflang を出すなら、B → A も同じ alternate を持つ
存在する URL を指す: 404 / noindex の URL を alternate に書かない

両方を満たすには「両言語に実体があるときだけ alternate を出す」が一番素直で safe な実装になる。サイトのビルド時に Content Collections を走査して、各記事がどの言語に存在するかを判定する仕組みが必要です。

実体存在判定ヘルパ 3 つ

Aulvem では 3 種類のページ系（個別記事 / プロダクト / カテゴリ paginated）に対応するヘルパを src/lib/posts.ts に置いている。

import { getCollection } from "astro:content";
import type { Lang } from "../i18n";

const LANGS: Lang[] = ["en", "ja"];

// 個別ブログ記事 → どの言語に存在するか
export async function blogAvailableLangs(slugWithoutLang: string): Promise<Lang[]> {
  const all = await getCollection("blog", ({ data }) => !data.draft);
  return LANGS.filter((lang) =>
    all.some((e) => e.id === `${lang}/${slugWithoutLang}`),
  );
}

// プロダクトページ → どの言語に存在するか
export async function serviceAvailableLangs(slugWithoutLang: string): Promise<Lang[]> {
  const all = await getCollection("services");
  return LANGS.filter((lang) =>
    all.some((e) => e.id === `${lang}/${slugWithoutLang}`),
  );
}

// カテゴリ paginated ページ → N ページ目が言語ごとに存在するか
export async function categoryPageAvailableLangs(
  category: string,
  pageNum: number,
  pageSize: number,
): Promise<Lang[]> {
  const results: Lang[] = [];
  for (const lang of LANGS) {
    const posts = await getPublishedBlog(lang);
    const inCat = posts.filter((p) => p.data.category === category);
    const lastPage = Math.max(1, Math.ceil(inCat.length / pageSize));
    if (pageNum <= lastPage) results.push(lang);
  }
  return results;
}

draft: true を除外しているのがポイントで、下書きしかない言語を「実体あり」と判定すると、本ビルドの sitemap や本文側と不整合になる。getCollection のフィルタ段階で落とす。

Seo.astro はビルド時にレンダリングされるので、ここでは Content Collections API が使える。astro.config.mjs での sitemap lastmod 実装では loader より早く評価される制約があって API が使えなかったが、layout から呼ぶ場合はその制約は無いです。

Seo.astro で条件付き出力

Seo.astro は availableLangs prop を受け取り、includes("en") / includes("ja") で <link rel="alternate"> を条件付き出力する。

---
interface Props {
  // ... 他の props
  availableLangs?: Lang[];
}
const { availableLangs = ["en", "ja"], lang: langProp } = Astro.props;
const lang: Lang = langProp ?? getLangFromUrl(Astro.url);

const currentPath = Astro.url.pathname;
const otherLangPath = altPathForOtherLang(currentPath, lang);
const enPath = lang === "en" ? currentPath : otherLangPath;
const jaPath = lang === "ja" ? currentPath : otherLangPath;
const enHref = new URL(enPath, Astro.site).toString();
const jaHref = new URL(jaPath, Astro.site).toString();
const hasEnVersion = availableLangs.includes("en");
const hasJaVersion = availableLangs.includes("ja");
// x-default points to EN when available; otherwise the only available lang.
const xDefaultHref = hasEnVersion ? enHref : jaHref;
---
{hasEnVersion && <link rel="alternate" hreflang="en" href={enHref} />}
{hasJaVersion && <link rel="alternate" hreflang="ja" href={jaHref} />}
<link rel="alternate" hreflang="x-default" href={xDefaultHref} />

デフォルト値を ["en", "ja"] にしているのは、top-level ページ（/、/about/ など）は両言語に必ず存在する前提だからだ。個別記事のレイアウトでは必ず availableLangs を上書きする ルールにして、上書きを忘れるとビルド時に 404 URL が hreflang に乗ってしまう失敗モードを潰しておく。

x-default は両言語にあれば EN にフォールバックする。Google は「サポート言語の 1 つを必ず明示する」を推奨しているので、片言にしかない記事でもその唯一の言語を x-default にしています。

使用側レイアウト

BlogPostLayout.astro から呼び出すときはこう書く。

---
import { entrySlug, blogAvailableLangs } from "../lib/posts";

const slug = entrySlug(entry); // "ja/2026-05-30-foo" → "2026-05-30-foo"
const availableLangs = await blogAvailableLangs(slug);
---
<Seo
  title={data.title}
  description={data.description}
  lang={lang}
  availableLangs={availableLangs}
  // ...
/>

entrySlug で言語プレフィクスを剥がしてから、ヘルパに渡す。プレフィクス込みで渡すと判定が空になるので、ここを間違うとサイレントに hreflang が出なくなる。

カテゴリ paginated 系（/blog/build/[...page].astro）は categoryPageAvailableLangs(category, page.currentPage, 12) を渡す。

全体図

flowchart LR
  MDX[blog MDX en+ja]
  Helper[blogAvailableLangs<br/>serviceAvailableLangs<br/>categoryPageAvailableLangs]
  Layout[BlogPostLayout<br/>ServiceLayout<br/>category route]
  Seo[Seo.astro<br/>availableLangs prop]
  HTML[hreflang 0~2 + x-default]

  MDX -->|getCollection| Helper
  Helper --> Layout
  Layout --> Seo
  Seo --> HTML

ヘルパは Content Collections を 1 回走査し、レイアウトに Lang[] を返す。レイアウトがその配列を Seo.astro に渡し、Seo.astro が条件付きで <link rel="alternate"> を 0〜2 本＋ x-default 1 本出力します。

ルーティングは Astro 標準のまま

@astrojs/i18n 系のルーティング（/ja/... プレフィクスの自動付与、locale 判定）は触っていない。Astro 5 標準で十分に成熟していて、書き換える理由がない。

Aulvem のスタンスは「公式統合で足りる部分は触らず、足りない部分だけ独自実装で薄く埋める」。hreflang は SEO 層の話なので Seo.astro 内に閉じる形にして、ルーティング層には手を入れない。これで Astro が将来 hreflang 自動生成を実装したときに、Seo.astro 側を剥がすだけで済む構造になる、と思う。

落とし穴と運用ルール

実装で踏みかけた、または踏んだ話を整理しておく。

availableLangs のデフォルトは ["en", "ja"]: top-level ページ前提。個別記事のレイアウトで上書きし忘れると、片言記事でも 2 本 alternate が出てしまう
entrySlug のタイミング: Content Collections の entry.id は ja/2026-05-30-foo の形なので、ヘルパに渡す前に必ず entrySlug で言語プレフィクスを剥がす
draft: true 除外: ヘルパ内の getCollection フィルタで落としている。これを忘れると、下書きしかない言語版を「実体あり」と判定する
paginated の片言ケース: /blog/build/3/ のような 3 ページ目以降は、EN と JA で投稿数が違うと片方しか存在しないことがある。categoryPageAvailableLangs で対応
x-default を片言にも出す: Google が「サポート言語を 1 つは明示する」を推奨しているため。片言の記事でも x-default だけは出して、サポート言語を明示する

まとめ

リシプロカル要件と存在チェックの 2 つを揃えないと、hreflang シグナルは検索エンジンに無視されます。Aulvem では Content Collections の実体を見て出すかどうかを判定し、Seo.astro が条件付きで HTML に流す構成にしました。ルーティングは Astro 標準のまま、SEO 層だけ 30 行ほどの追加で済んでいます。

frontmatter を単一情報源として扱う設計は Zod schema で運用ルールを強制すると sitemap の lastmod を MDX frontmatter から自分で差し込むでも同じ系列の話を書いたので、合わせて読むと位置づけが分かりやすいかもしれない。リシプロカルに参照を張る発想は LLM 向けインデックスにも持ち込めて、llms.txt を多言語生成するでも同じ考え方を使った。

よくある質問

Astro 標準が hreflang を自動で出さないのはなぜ？

Astro 5 の i18n はルーティング（URL の生成と locale 判定）に責任を絞っていて、SEO メタタグ生成までは持ちません。@astrojs/sitemap の i18n オプションで sitemap 内の hreflang は出ますが、HTML の <link rel="alternate"> は自分で書く必要があります。Aulvem ではここを Seo.astro に集約しています。

`@astrojs/sitemap` の i18n オプションで出る hreflang ではダメ？

sitemap.xml 内の xhtml:link は出ますが、HTML の <head> に入る <link rel="alternate" hreflang> は別系統です。Google は両方を併用して読みますが、<head> 側が無いと検索結果のスニペット段階で多言語認識が弱くなる、というのが運用上の判断です。

`x-default` は何を指すべき？

Google のドキュメントは「ユーザーがどの言語ページに着地すべきか不明なときの fallback」と説明しています。Aulvem は EN をデフォルトロケールに置いているので EN があれば EN、EN が無ければ唯一存在する言語版を指す実装にしました。両言語にある記事は迷わず EN にフォールバックでよいと思います。

1 言語にしか実体がない記事の SEO 評価は損なわれない？

hreflang を出さないこと自体が罰になるわけではありません。むしろ存在しない URL を alternate として出して Google に無視される方が、サイト全体の多言語シグナルを濁します。実体がある言語版だけ canonical を立て、ない言語の alternate は出さない、で評価上は問題ないという理解です。

sitemap の lastmod を MDX frontmatter から自分で差し込む — Aulvem の Astro 公式統合カスタマイズ

Mon, 25 May 2026 00:00:00 GMT

@astrojs/sitemap は MDX frontmatter の updatedDate を読まない。

何もしないと、Aulvem の sitemap.xml は各記事の lastmod をビルド時刻にしてしまう。「全記事が毎ビルド更新されている」というノイズシグナルを検索エンジンに送ることになって、鮮度判定で逆効果になる。

Aulvem では astro.config.mjs の中で MDX を直接走査して、updatedDate ?? pubDate をパスごとに引ける Map を作り、@astrojs/sitemap の serialize で差し込む構成にした。ついでに paginated noindex ページの除外も filter でやっている。これは Aulvem ブログの作りで予告した派生記事の 2 本目です。

lastmod がなぜ効くのか

lastmod は Google / Bing の sitemap プロトコルで「最終更新日」として渡る値で、検索エンジンが再クロールの優先度を決めるヒントとして読む。AI 検索（ChatGPT search / Perplexity / Claude search）も引用元の最新性根拠としてこの値を見にくる挙動が報告されている。

つまり lastmod は次の 2 つの局面で効いている。

クロール優先度: 直近で更新された URL を優先的に再取得させたい
AI 検索の引用判定: 「数日前に書かれた最新情報」として引用されやすくする

逆に、ここを嘘で塗ると逆効果になる。Google 公式の Sitemap docs も「lastmod の値が信用できないとサイト全体の信頼度を下げる」と書いている。実態と乖離した更新日を流せば、検索エンジンに「このサイトの lastmod は信用ならない」と学習させるだけなので、運用ルール（content-rules.md A-2-1）と一緒に締めておく必要がある。

ビルド時に MDX を走査して lastmod マップを作る

astro.config.mjs の中で async 関数を走らせて、src/content/blog/{en,ja}/ 配下の MDX を全部読む。

import { readdir, readFile } from "node:fs/promises";
import { join } from "node:path";

async function buildBlogLastmodMap() {
  const map = new Map();
  for (const lang of ["en", "ja"]) {
    const dir = join(process.cwd(), "src", "content", "blog", lang);
    let files = [];
    try {
      files = await readdir(dir);
    } catch {
      continue;
    }
    for (const file of files) {
      if (!file.endsWith(".mdx") && !file.endsWith(".md")) continue;
      const slug = file.replace(/\.(mdx|md)$/, "");
      const raw = await readFile(join(dir, file), "utf8");
      const fm = /^---\n([\s\S]*?)\n---/.exec(raw);
      if (!fm) continue;
      const front = fm[1];
      if (/^draft:\s*true/m.test(front)) continue;
      const updated = /^updatedDate:\s*(\S+)/m.exec(front);
      const pub = /^pubDate:\s*(\S+)/m.exec(front);
      const dateStr = (updated && updated[1]) || (pub && pub[1]);
      if (!dateStr) continue;
      const d = new Date(dateStr);
      if (Number.isNaN(d.getTime())) continue;
      const path = lang === "ja" ? `/ja/blog/${slug}/` : `/blog/${slug}/`;
      map.set(path, d.toISOString());
    }
  }
  return map;
}

const blogLastmod = await buildBlogLastmodMap();

ここで getCollection("blog") のような Content Collections API を使わないのは、astro.config.mjs が content loader より早く評価される からだ。config が走っている時点では Content Collections 側はまだ初期化されておらず、API が存在しない。

frontmatter は軽量 regex で読んでいる。MDX の構造を fully parse する必要はなく、欲しいのは updatedDate と pubDate の 2 行だけなので、依存を増やすメリットがない。型安全ではないが、型検証は本ビルド時に Zod schema が走るので、二重に網が張られている形になる。

draft: true の MDX はここで除外する。これを忘れると下書きの URL がサイトマップに乗ってしまうので、フィルタの位置が大事だと思う。

`serialize` でマップから lastmod を流す

@astrojs/sitemap の serialize オプションは、生成された各 URL エントリを書き換えるフック。マップから lookup して item.lastmod に詰める。

sitemap({
  i18n: {
    defaultLocale: "en",
    locales: { en: "en", ja: "ja" },
  },
  serialize(item) {
    const url = new URL(item.url);
    // /ja/blog/foo/ も /blog/foo/ も同じ slug なので、
    // /ja/ プレフィクスを剥がして path 種別だけで分岐する
    const pathname = url.pathname.replace(/^\/ja\//, "/").replace(/^\/ja$/, "/");
    if (pathname === "/") {
      item.changefreq = "daily";
      item.priority = 1.0;
    } else if (pathname === "/blog/") {
      item.changefreq = "daily";
      item.priority = 0.9;
    } else if (pathname.startsWith("/blog/")) {
      item.changefreq = "monthly";
      item.priority = 0.7;
      // ja URL も en URL も blogLastmod の key は元の url.pathname のまま
      const lastmod = blogLastmod.get(url.pathname);
      if (lastmod) item.lastmod = lastmod;
    } else if (pathname.startsWith("/products/")) {
      item.changefreq = "monthly";
      item.priority = 0.8;
    } else {
      item.changefreq = "monthly";
      item.priority = 0.5;
    }
    return item;
  },
});

changefreq と priority もパス種別ごとに分けて与えている。実は priority は Google が「無視している」と公言しているフィールドだが、Bing と他検索エンジン・AI クローラーは依然読みに来るので、整合の取れた値を出しておく方針にした。

/ja/ プレフィクスを剥がして path 種別だけで分岐するのは、JA と EN で同じカテゴリの記事に同じ changefreq / priority を当てるためだ。lastmod の lookup には元の url.pathname（/ja/blog/foo/ を含む）を使うので、Map のキーと整合する。

paginated noindex ページを `filter` で外す

ページ送りの 2 ページ目以降（/blog/build/2/ /blog/reviews/3/ など）には <meta name="robots" content="noindex, follow"> を入れている。1 ページ目だけがインデックス対象で、2 ページ目以降は「クロールはしてほしいがインデックスはいらない」状態にしておきたいからだ。

このとき、sitemap で 2 ページ目以降の URL も送ってしまうと mixed signal になる。「sitemap に載せた = インデックスしてほしい」と「meta robots = noindex」が同時に立つので、Google も Bing もこの矛盾を SEO 品質スコアに反映してくる。

filter で除外する。

sitemap({
  filter: (page) => {
    if (page.endsWith("/404/") || page.endsWith("/404")) return false;
    // Paginated category pages (/blog/build/2/, /blog/reviews/3/ ...)
    // are noindex, follow — drop them from the sitemap to avoid
    // contradicting the meta robots tag.
    if (/\/blog\/(build|reviews)\/\d+\/?$/.test(new URL(page).pathname)) return false;
    return true;
  },
  // ...
});

paginated 系を noindex にする運用と sitemap 除外はセットで考えないといけない。片方だけ直すと信号がねじれます。

全体の流れ

flowchart LR
  MDX[src/content/blog/&lt;lang&gt;/&lt;slug&gt;.mdx]
  Map[blogLastmod Map<br/>path → ISO date]
  Pages[@astrojs/sitemap<br/>URL リスト]
  Filter[filter:<br/>noindex 除外]
  Serialize[serialize:<br/>lastmod / changefreq / priority]
  SM[sitemap.xml]

  MDX -->|fs.readdir + regex| Map
  Map -->|lookup| Serialize
  Pages --> Filter
  Filter --> Serialize
  Serialize --> SM

astro.config.mjs の中で 2 つの経路が走る。MDX 走査経路でビルド前に Map を作り切り、Astro 本体のルーティングが生成する URL リストを filter で間引いて、serialize で Map と突き合わせて lastmod を当てる。最終的に sitemap.xml が出力される。

落とし穴と運用ルール

実装で踏んだ・踏みかけた話を整理しておく。

top-level await: astro.config.mjs で await buildBlogLastmodMap() を呼ぶには、config が ESM で評価される前提が要る。Astro 5 系はこれが効く前提なのでそのまま動くが、古い構成だと .mjs に揃えるか defineConfig を return する async function に包む必要がある
draft: true 除外: lastmod Map を作る段階で draft を抜かないと、下書き URL もサイトマップに混入する
regex の緩さ: /^updatedDate:\s*(\S+)/m は updatedDate: 2026-05-25 のような単純行を想定している。YAML 引用符 "..." を使っても (\S+) が "2026-05-25" を引用符ごと取り込み、new Date() はこれをそのままパースできる。ただし複数行やリスト形式の日付値を使う場合は注意
言語別フォルダの統合: en と ja を別ループで走らせて 1 つの Map に統合する。キーは /blog/<slug>/ と /ja/blog/<slug>/ を別物として持つ
updatedDate の運用基準: lastmod の実装を整えても、updatedDate を雑に打ち替えれば信頼度は崩れる。Aulvem は「実質改稿のときだけ更新、注記追加だけ・誤字修正だけでは打たない」のルールを content-rules.md A-2-1 で固めている

何を諦めたか / 公式統合に戻すべき境界

この実装は @astrojs/sitemap に PR を出すべき話だとも思う。Content Collections と sitemap を連動させる機能は他の Astro ユーザーにも需要があるはずで、汎用化する余地はある。

今は Aulvem 内に閉じて 30 行に収まる実装で済んでいるので、当面は config 内完結のままにしている。@astrojs/sitemap が将来 Content Collections 連携を入れた時点でこの実装は剥がせるはずなので、剥がしやすい形に保っておくのが当面のスタンスです。

まとめ

lastmod は SEO + AI 検索の両方で効く鮮度シグナルなので、ビルド時刻で塗らずに updatedDate の実日付を流す。paginated noindex ページは sitemap から除外して信号矛盾を作らない。この 2 つはセットで運用すると、サイトマップが「信頼できる更新情報の集合」になります。

実装の経路は別記事に書いた Zod schema で運用ルールを強制すると地続きで、frontmatter を単一情報源として扱う設計の派生です。

よくある質問

Astro 公式の sitemap が `updatedDate` を読まないのはなぜ？

@astrojs/sitemap はビルド済みの URL リストを受け取って sitemap.xml を出力するだけで、Content Collections の frontmatter まで触りに行きません。MDX の構造に踏み込むと collection 名・型・loader 種別への依存が増えるので、汎用統合の責務として持たない設計に見えます。

Content Collections の API を使わずに fs.readdir で読むのは型安全ではないのでは？

型安全ではありません。ただし astro.config.mjs は Content Collections の loader より先に評価されるので、ここでは API が未初期化です。frontmatter の中で必要なのは updatedDate と pubDate だけなので、軽量 regex で読む実装に倒しました。型検証は Zod schema 側で本ビルドのときに走るので、二重に網は張られています。

`noindex` のページを sitemap に送ってはダメなのか？

信号としてダメです。sitemap は「インデックスしてほしい URL のリスト」なので、noindex の URL を載せると mixed signal になります。Google も Bing も「sitemap で送ったのに noindex」という矛盾を見ると、サイト全体の品質シグナルとして減点する余地が出ます。

lastmod を実日付にすると AI 検索の引用率は本当に変わるのか？

数値での検証はしていません。ただ Google・Bing・各 AI 検索ベンダーのドキュメントはどれも lastmod を鮮度判定のヒントとして挙げており、嘘の lastmod は信頼を下げると明記されています。引用率の上振れより、雑な運用で評価を下げないための保険として考えるのが現実的だと思います。

Zod schema で運用ルールを強制する — Aulvem の Content Collections 設計

Sat, 23 May 2026 00:00:00 GMT

書いたルールは、忘れる。

Aulvem を 1 人で回していて最初に潰したかったのは、書き手（=自分）が書いた運用ルールを書き手（=自分）が破るパターンだ。category: reviews の記事に affiliate: true を入れ忘れて広告ディスクロージャーが表示されないまま公開、みたいな事故は、README に書くだけでは止まらなかった。

なので Aulvem では、ルールのうち機械で判定できるものは Astro Content Collections の Zod schema に寄せ、違反したらビルドが落ちる構造にした。ここで書くのは「何を schema で縛り、何を諦めたか」の境界線です。

Aulvem ブログの作りで予告した派生記事の 1 本目にあたる。

なぜ README だけでは守れないのか

README にチェックリストを書いただけでは、書き手が守らないことが起きた。

編集者が 1 人なので、書き手と読み手と pull request レビュアーが同じ人になる
数週間後に同じ手順を踏むとき、当時の README を律儀に読み返さない
過去の自分は信用していい一方で、未来の自分は素で忘れる

最初は記事追加チェックリストを docs/ 配下に置けば十分だと考えていたけれど、3 本目の記事を書いたあたりで「またあれをやり忘れた」が起きた。レビュアーが居ない状態でルールを守らせるには、運用フローの外側（= ビルド）にチェック装置を置くしかない、というのが Aulvem が schema 強制を選んでいる理由です。

Aulvem の schema 全体像

Content Collections の schema は src/content.config.ts に集約していて、blog と services の 2 コレクションを 1 ファイルで宣言している。collection ごとに別ファイルに割らないのは、コレクション間で共有したい型（pubDate, updatedDate, heroImage あたり）が出てきたときに 1 ファイルだと書き換えが完結するからだ。

骨格はこういう形になっている（記事用の blog 抜粋、一部省略）。

import { defineCollection, z } from "astro:content";
import { glob } from "astro/loaders";

const blog = defineCollection({
  loader: glob({ pattern: "**/[^_]*.{md,mdx}", base: "./src/content/blog" }),
  schema: z
    .object({
      title: z.string(),
      description: z.string(),
      summary: z.string().optional(),
      pubDate: z.coerce.date(),
      updatedDate: z.coerce.date().optional(),
      category: z.enum(["build", "reviews"]),
      tags: z.array(z.string()).default([]),
      draft: z.boolean().default(false),
      affiliate: z.boolean().default(false),
      heroImage: z.string().optional(),
      heroAlt: z.string().optional(),
      howto: z.object({ /* ... */ }).optional(),
      faq: z.array(z.object({
        question: z.string(),
        answer: z.string(),
      })).optional(),
    })
    .refine((data) => (data.category === "reviews") === data.affiliate, {
      message: "affiliate must be true iff category is 'reviews'",
      path: ["affiliate"],
    }),
});

z.enum でカテゴリを 2 値に固定し、z.coerce.date で日付の文字列表記揺れを吸収し、.optional() と .default() で必須/任意の境界を明示する。素朴な道具で 9 割の運用は閉じる。残りの 1 割が .refine() の出番で、これが次節の主役になります。

reviews ⇔ affiliate を `.refine()` で同期させる

category: reviews の記事は ASP 規約上「広告であること」を本文冒頭に明示する必要がある。Aulvem では affiliate: true の記事に対して、ディスクロージャーバナーを冒頭に自動挿入する rehype プラグインを走らせている。rel="sponsored noopener noreferrer" の自動付与も同じく affiliate: true をフラグにしている。

つまり「カテゴリは reviews だけど affiliate を false にし忘れた」記事が公開されると、ディスクロージャーも rel="sponsored" も付かないまま広告リンクを掲載することになる。これは ASP 規約違反であり、Google からは広告とユーザーコンテンツの区別がつかない記事として扱われる。

この事故を機械的に止める一行が次のコード：

.refine((data) => (data.category === "reviews") === data.affiliate, {
  message: "affiliate must be true iff category is 'reviews'",
  path: ["affiliate"],
})

両辺を === で比較しているので、どちらか一方だけが書き換わるとビルドが落ちる。XOR 条件を書く代わりに「等しいことを強制する」と書くと意図が読める形になる、と思って今の書き方に落ち着いた。

README に「reviews 記事には affiliate: true を必ず付ける」とだけ書いていた頃は、scripts/new-blog.mjs の雛形が affiliate を入れ忘れる → 書き手が気づかず公開 → 数日後に検索結果のサムネで違和感に気づく、というルートで事故が起きていた。今は雛形側にも自動挿入を入れているけれど、雛形を経由せず手で .mdx を新規作成された場合に効くのは schema 側の縛りのほうです。

howto / faq を frontmatter で型付けする

構造化データ（JSON-LD）の HowTo と FAQPage は、Google の検索結果でステップや質問が直接展開される枠を取れる。Aulvem ではこの 2 つを frontmatter から自動生成する経路を選んだ。

howto: z.object({
  name: z.string().optional(),
  description: z.string().optional(),
  totalTime: z.string().optional(),
  steps: z.array(z.object({
    name: z.string(),
    text: z.string(),
    image: z.string().optional(),
  })),
}).optional(),
faq: z.array(z.object({
  question: z.string(),
  answer: z.string(),
})).optional(),

代案として「本文 MDX をパースして見出しから抽出する」もあった。最初の数記事はこれで進めようとしたけれど、見出しの構造を変えると JSON-LD が壊れるリスクがあったので捨てた。frontmatter に明示するほうが、構造化データを意識した書き方を強制できる効果もある。

frontmatter で型付けされている限り、ステップ数 0 の howto やキーの違うオブジェクトは Zod が弾く。JSON-LD 側のジェネレータは frontmatter を信用して読めるので、後工程が薄くなる。

schema では検出できない — frontmatter と本文の文字列一致

ここから先は Zod の守備範囲を超える。

Google の検索品質ガイドラインは、「JSON-LD だけ豪華で本文に書かれていない」構造化データを mismatch とみなして、リッチリザルトの表示資格を剥奪する。frontmatter に書いた FAQ の question と answer が本文に存在しない記事は、たとえスキーマ検証を通っても SEO 上は地雷になる。

Zod は本文を見ない。なので別レイヤーで検出する必要がある。Aulvem は validate-schema-match.mjs という grep ベースのバリデータを書いた。

if (Array.isArray(data?.faq)) {
  for (const [i, item] of data.faq.entries()) {
    if (!item?.question) continue;
    if (!bodyNorm.includes(normalise(item.question))) {
      mismatches.push(
        `faq[${i}].question not found in body: "${item.question}"`,
      );
    }
  }
}

frontmatter の faq[].question と howto.steps[].name の文字列が本文の中に出現するかを正規化して比較する。出現しなければ exit code 1 を返してビルド前に止まる構造にしています。

ただしこの検出は文字列の存在だけで、意味の一致は見ない。同じ質問文の下で答えが入れ替わっていてもこのレイヤーでは通る。

schema 化しないと決めたもの

schema にも grep にも乗らないものは、自動化を諦めて別経路に逃がした。

FAQ の回答が事実として正しいか
ディスクロージャー文の強度（ASP ごとに微妙に違う）
文末が AI 臭くないか
結論部の主張が記事全体と整合しているか

ここは書き手が読み直さないと判断できないし、schema 化のコストが運用コストを上回る。代わりに公開前チェックリストに残し、lint-banned-phrases.mjs で機械的に拾える AI 臭フレーズだけは別途縛っている。

「全部を強制で縛れたら理想」ではなくて、ビルドが落ちる体験で何を守りたいかの優先順位を決めるほうが運用は安定すると思う。1 人で回している以上、自動化に投じられる時間にも上限があるので、効果と工数のバランスを取る箇所はある。

schema / lint / レビューの 3 層分担

ルールを 3 つのレイヤーに分けて、それぞれが何を担保するかを表にすると整理しやすい。

レイヤー	落とせるタイミング	守れること	守れないこと
Zod schema	`astro build` 時	型 / 列挙 / 必須・任意 / 値同士の関係	文章の意味 / 本文と frontmatter の文字列一致
Lint スクリプト	pre-commit, CI	禁止フレーズ / frontmatter と本文の語彙一致	意味の妥当性
書き手レビュー	公開前チェックリスト	意味の妥当性 / disclosure の強度 / AI 臭の総合判定	自動化できない

上のレイヤーで落とせるものは下に降ろさない、というのを判断基準にしている。schema で書ける関係を lint に置くと、ビルド時に落ちず lint を走らせ忘れる経路が増える。grep で十分なものを schema に積むと型定義が読みにくくなる。それぞれの層でできることに留めるのが、運用上は最短ルートだと思います。

まとめ

機械が判定できる構造制約は schema に寄せる。文字列の存在は lint に寄せる。意味の妥当性はレビューに残す。この 3 層分担を一度決めてしまえば、新しい運用ルールが出てきたときに「これはどの層で守らせるか」だけ考えればよくて、毎回 README を更新する運用にはなりません。

Aulvem サイトのスタック全体像は別記事に書いたので、合わせて読むと位置づけが分かりやすいかもしれない → このブログの作り — Astro 5 と Content Collections で組む Aulvem の構成。

frontmatter を「単一情報源」として扱う設計は sitemap の lastmod にも展開していて、こちらは別記事にまとめました → sitemap の lastmod を MDX frontmatter から自分で差し込む。

よくある質問

Zod の `.refine` と `.superRefine` はどう使い分ければいいか？

値同士の関係を 1 つだけ縛るなら .refine() で十分です。1 つのオブジェクトに対して複数の独立した制約をかけたり、エラーメッセージを場所ごとに変えたい場合は .superRefine() を使います。Aulvem は今のところ category と affiliate の連動だけなので .refine() 1 段で済んでいます。

howto / faq を別ファイルに分けない理由は？

frontmatter にまとめて型付けできるからです。別ファイルにすると、本文・JSON-LD・frontmatter の三者で出典が分かれ、同期コストが上がります。frontmatter が単一情報源で、JSON-LD は自動生成、本文には同じ文字列を埋める運用が一番事故が少ないと判断しています。

schema を後から変更したら既存記事のビルドは落ちるか？

落ちます。たとえば必須フィールドを追加すると、既存記事の全 frontmatter にそれを足さないとビルドが通りません。これは意図された挙動で、ルール変更の波及範囲を全件で確認させる仕組みになります。

本文と JSON-LD の整合チェックを Astro の build に組み込まないのはなぜか？

build 時間を伸ばさないためです。整合チェックは grep ベースのスクリプトに切り出し、pre-commit と CI で別途走らせています。ビルド本体に組み込むと、毎回の astro dev 起動が遅くなって執筆体験を損ねます。

このブログの作り — Astro 5 と Content Collections で組む Aulvem の構成

Sun, 17 May 2026 00:00:00 GMT

Aulvem サイトの構成について、技術スタックの紹介ではなく「何を schema で強制し、何を捨てたか」に絞ってまとめる起点記事です。スタック自体は Astro + MDX + Content Collections の組み合わせで、特別なことはしていません。書きたいのは典型構成の上で、書き手がうっかり忘れる類の運用ルールをどうビルド時に落とすか、です。

全体像のハブとしてここに集約しました。個別判断（schema 強制 / 構造化データ一致 / sitemap lastmod の独自実装）は派生記事に分けます。

スタックの全体像 — Astro 5 + MDX + Content Collections + R2

Aulvem は Astro 5（静的出力）+ MDX + Content Collections + Tailwind 3 + Pagefind + Cloudflare R2 で動いています。動的サーバーは使わず、生成済み HTML を Cloudflare Pages から配信するだけのシンプルな構成です。

選択の軸は次の 3 つに絞りました。

ビルド成果物が完全に静的であること
記事のメタデータを schema で縛れること
コアの依存数が少ないこと

Astro 5 はこの 3 つすべてに当てはまりました。部分ハイドレーションや UI フレームワーク連携などの機能は今のところ使っていません。

「Astro が良いか」は要件次第です。動的な認証・コメント・購読系を載せたいなら、Next.js のような選択肢のほうが向いているはず。

用語: Content Collections とは

Aulvem では blog（記事）と services（プロダクトページ）の 2 コレクションを定義していて、schema は 1 ファイルに集約し、ビルド時に両方を検証しています。

全体スタック — 主要パッケージ

本番依存は 8 個に絞っています。

パッケージ	用途	備考
`astro` ^5	SSG コア	静的出力のみ使用
`@astrojs/mdx` ^4	MDX サポート	記事は全て `.mdx`
`@astrojs/sitemap` ^3	sitemap 生成	`lastmod` は自前で差し込む
`@astrojs/rss` ^4	RSS 生成	全文 `content:encoded` 配信
`@astrojs/tailwind` ^6	Tailwind 統合	`applyBaseStyles: false`
`rehype-external-links` ^3	外部リンクに rel 付与	`noopener noreferrer`
`rehype-mermaid` ^3	mermaid 図の build 時 SVG 化	`inline-svg` strategy
`tailwindcss` ^3.4	スタイリング	v4 は様子見

dev 依存は pagefind（全文検索）、sharp（ローカル画像処理）、playwright（mermaid 図の build 時 SVG 化に必要）、typescript、@types/node のみ。React も Vue も Vite プラグインも入れていません。

「とりあえず後から要るかもしれない」を前提に依存を足さない、を入口の方針にしました。未使用の依存はビルド時間とセキュリティアラート対応のノイズに効いてくるので、入れる前に使うシーンを言語化できるかを確認しています。

譲れなかった 3 つの仕組み

1. ルールはスキーマで強制する

運用ルールを README に書かず、frontmatter schema で強制しています。書き手が忘れてもビルド時に落ちる構造にしておきたかった、というのが理由です。

たとえば category: reviews の記事は ASP 規約上「広告であること」を明示する必要があるので、affiliate: true を必須にしました。これを README に書くだけの取り決めにせず、Zod の .refine() で category === "reviews" と affiliate === true が常に等しいことを強制しています。片方だけ書き換えるとビルドが落ちる形にしておけば、書き手の記憶に頼らずに済みます。

同じ発想を howto / faq の構造化データにも適用していますが、これは派生記事で扱う予定です。

2. 構造化データと本文を一致させる

JSON-LD（howto / faq）の中身は frontmatter から自動生成しつつ、本文にも同じ内容を必ず書きます。理由は Google の structured data mismatch ペナルティを避けるためで、「JSON-LD だけ豪華にして本文に書かない」のは検索品質ガイドライン違反です。検出されると構造化データの表示資格を失います。

Aulvem では「frontmatter と本文の両側に同じ内容を書く」をルールにして、片側だけ更新する事故を最初から起こさない形にしています。

3. sitemap の lastmod は frontmatter から自分で読む

Astro 公式の sitemap integration は MDX frontmatter の updatedDate を読みません。そこで Aulvem では自前のロジックで全 MDX を走査し、updatedDate ?? pubDate を lastmod として sitemap に流しています。

これをやらないと sitemap の lastmod がビルド時刻に固定され、「全記事が毎ビルド更新されている」というノイズシグナルを検索エンジンに送ることになります。AI 検索の鮮度判定にも lastmod は使われるので、ここは雑にやらないようにしています。

同時に、noindex, follow を返している分割ページは sitemap から除外しています。「noindex なものを sitemap で送る」のは矛盾シグナルなので、両方を一緒に正しく扱う必要があります。

実装の中身（astro.config.mjs の中で MDX を走査する書き方、@astrojs/sitemap の serialize と filter の連動、運用上の落とし穴）は派生記事 sitemap の lastmod を MDX frontmatter から自分で差し込むにまとめました。

3 つはどうつながっているか

flowchart LR
  FM[frontmatter] --> Zod
  FM --> Sitemap
  FM --> Sync
  Body[本文 MDX] --> Sync

  Zod["Zod schema 検証<br/>category ⇔ affiliate"] --> Build
  Sitemap["sitemap lastmod 差し込み<br/>updatedDate を読む"] --> Build
  Sync["frontmatter ↔ 本文<br/>の整合"] --> Build

  Build[Astro build]

  Build --> HTML[HTML + JSON-LD + SVG]
  Build --> SM[sitemap.xml]

frontmatter と本文という 2 つの入力から別経路で 3 つの仕組みが走ります。frontmatter は Zod schema 検証と sitemap lastmod 差し込みを通り、frontmatter と本文の両方が「同じ内容が両側に書かれているか」の整合チェックに渡ります。

すべての結果が Astro build で束ねられ、HTML + JSON-LD + sitemap.xml として公開されます。どれか 1 つが落ちるとビルドが失敗するので、片方だけ整えても公開できません。

運用フローは単一情報源に集約する

記事追加・プロダクト追加・retire（記事削除）といった運用フローは、1 つの doc を単一情報源にしています。そこから雛形生成と整合性チェックのスクリプトを連動させる構成にして、毎回同じ手順を踏む前提にしました。これで「やり方が毎回バラつく」揺らぎは、執筆時の温度感以外の部分でほぼ吸収できると思います。

なお updatedDate を「冒頭注記の追加だけでは更新しない」「実質改稿時のみ更新する」というルールも明文化しました。検索エンジンと AI が dateModified を鮮度シグナルとして引くので、ここを甘く運用するとサイト全体の権威性が下がります。基準はあらかじめ決めておきます。

よくある質問

なぜ Astro 5 を選んだのか？

「Markdown 中心 / 完全静的出力 / frontmatter を型で縛れる / コア依存が少ない」の 4 条件で絞ったとき、Astro 5 が一番うまく当てはまりました。Content Collections と MDX が標準で入っており、追加プラグインを積まずに型付きコンテンツを扱える点で選んでいます。

ヘッドレス CMS（Sanity, Contentful 等）を入れないのはなぜ？

投稿頻度が週 1〜数本で、編集者が 1 名のため CMS の管理画面より MDX + git で書くほうが速いです。CMS を入れた瞬間に下書きの所在・スキーマ変更・API 認証など運用コストが乗ります。読者 1 万人規模を超えるか、複数編集者が入った時点で再評価する想定です。

全文検索はどう実装している？

Pagefind を astro build の後に走らせて、ビルド時に静的な検索インデックス（バイナリ化された辞書）を生成しています。フロントでは数十 KB の WASM ローダーから引いていて、サーバーレス関数も外部 API も使いません。

i18n は Astro 標準の機能をそのまま使っている？

ルーティングは Astro 5 の i18n（defaultLocale: en / prefixDefaultLocale: false）をそのまま使っています。一方で hreflang と sitemap の lastmod は MDX frontmatter から独自に取得する実装にしました。詳細は派生記事で扱います。

まとめ

全体像はここまでです。実際に作って回してみると、スタックを何で組むかより、frontmatter を schema でどこまで縛るかを決めるほうが、後の運用には効きました。

Figmaの使い方〜基礎編３〜スタイル登録とバリアンツでデザインを管理する

Tue, 05 Apr 2022 00:00:00 GMT

2026-05-16 追記: 初出から数年経過した記事です。骨子は今も参考になりますが、ツールの UI やバージョンは執筆当時のままで、最新版とは差異があります。

今回はFigma内でより管理しやすく、調整しやすくする機能を解説します。

デザインファイルまでの作成は前回紹介しましたので参考にしてください。

本記事の完成デザインは下画像になります。

カラースタイルの作成

前回までで画面内のパーツは揃ったので、色の登録を行って再利用しやすくしていきます。

まずはヘッダーの背景色を登録します。

Point

色の登録をしたい要素を選択

右ナビゲーション内のFillという項目を見つける

Fill項目の右に・が4つあるアイコンがあるのでクリック

出てくるColor Stylesの右にある+アイコンをクリック

モーダル内の入力欄に登録したい名前を入力

Create styleをクリック

これで色の登録ができました。

色の登録は他の要素で同色を利用している箇所で使用すると嬉しいことがあります。

ヘッダーの背景色はフッターの背景色でも利用しているので、フッターに先程登録した色を適用します。

Point

登録色を適応したい要素を選択

右ナビゲーション内のFillという項目を見つける

Fill項目の右に・が4つあるアイコンをクリック

出てくるColor Styles下の適応したい色をクリック

これでフッターに登録した色を適用できました。

このように各色をColor Stylesに登録し、各箇所に登録すると色を変えたい時に便利です。

下gifは他の色、要素全てColor Stylesで適応した状態でmain色を編集しています。

Point

何も要素が無いところをクリック

右ナビゲーション内のColor Stylesという項目を見つける

Color Styles項目の編集したい色までカーソルを持っていく

右に調整アイコンが表示されるのでクリック

カラーコードが下に表示されるのでクリック

カラーピッカーで任意の色を選択

デザインが煮詰まっていくにつれ、色を微調整する機会も増えていくので先行して色登録するのがオススメです。

またどの色をどんな役割で何個使用しているかもColor Stylesで把握できるので、変な色を使う可能性が減るメリットもあります。

フォントスタイルの作成

色登録のような機能はフォント設定も同様に存在します。

Point

フォントの登録をしたい要素を選択

右ナビゲーション内のTextという項目を見つける

Text項目の右に・が4つあるアイコンがあるのでクリック

出てくるText Stylesの右にある+アイコンをクリック

モーダル内の入力欄に登録したい名前を入力

Create styleをクリック

これでフォントスタイルも登録できました。

フォントスタイルの適応、編集はColor Stylesと同様です。

影の設定

ここまでは管理性の向上でしたが、今度は要素に影を付けていこうと思います。

試しにカードの枠に影を付けます。

Point

影を付けたい要素を選択

右ナビゲーション内のEffectsという項目を見つける

Effects項目の右に＋アイコンがあるのでクリック

Effects項目の右に太陽のアイコンがあるのでクリック

Drop shadow項目下の数値の変更をして指定したい値まで変更

方向キー↑↓で1ピクセル変更可

これでカードの枠に影を付けられました。

この影も他と同様にスタイルを登録できます。

Point

フォントの登録をしたい要素を選択

右ナビゲーション内のEffectsという項目を見つける

Effects項目の右に・が4つあるアイコンがあるのでクリック

出てくるEffect Stylesの右にある+アイコンをクリック

モーダル内の入力欄に登録したい名前を入力

Create styleをクリック

これで影のスタイルも登録できました。

影のスタイルの適応、編集はColor Stylesと同様です。

コンポーネントとオートレイアウトの組み合わせ

Web上に表示してあるボタンはクリックした瞬間色が変わったり、表示が変わったりします。

その状態変化をFigmaで表現したい時はバリアンツ機能が便利です。

今の状態だとバリアンツ機能が使いにくいので、バリアンツ機能の下準備としてオートレイアウト化してあるボタンをオートレイアウト機能を保持したまま別コンポーネント化していこうと思います。

このセクションには元素材としてコンポーネントとオートレイアウトを組み合わせる操作の GIF アニメーション (約 32 MiB) がありましたが、ホスティング (Cloudflare Pages) のファイルサイズ制限のため省略しています。実際の挙動は Figma 公式ドキュメントを参照してください。

Point

コンポーネント化したい要素を選択

フレーム外まで移動

［コンポーネント / オートレイアウト / 要素］の順に加工

要素のトップがフレームの場合はオートレイアウト化

子コンポーネントを1の元の場所まで移動

操作が複雑ですがこれでオートレイアウト機能を保持したままコンポーネント化できました。

バリアンツの作成

フレーム外にコンポーネントとしてボタンを用意できました。

ここからはボタンの状態変化をバリアンツ機能を用いて表現していきます。

Point: バリアンツの適応

オートレイアウト化したいコンポーネント化された要素を選択

右ナビゲーション内のVariantsという項目を見つける

Variants項目の右にある+アイコンをクリック

Variant2など表示されている入力欄に、サブ状態で登録したい状態名を入力

登録したい状態名の中の要素を選択

色などを変更

Point: バリアンツ状態の変化

状態を変化せたい要素を選択

右ナビゲーション内のコンポーネント名が書かれた項目をみつける

Property1などと書かれた右のドロップダウンをクリック

変化させたい状態名を選択

バリアンツ機能は適応するとコンポーネントの周りに点線が表示され、要素が複製されます。

そしてその複製された要素を編集することによってサブ状態が表現できる機能です。

ただしバリアンツ機能はコンポーネント化された要素のみ適応できるので注意です。

現状バリアンツに登録できるのはデフォルトの他１種類しか登録できないので、状態を追加します。

Point: 始点の変更

追加したいバリアンツ要素を選択

近くに＋アイコンが表示されるのでクリック

追加される場所は選択した要素の直下なので、なるべく一番下のバリアンツ要素から選択するのがオススメです。

完成

以上今回はFigmaの基礎編３を解説しました。

今後もスキル関係についての記事を投稿するのでお楽しみに！

Figmaの使い方〜基礎編２〜枠線・グループ化・コンポーネント・オートレイアウト

Fri, 01 Apr 2022 00:00:00 GMT

2026-05-16 追記: 初出から数年経過した記事です。骨子は今も参考になりますが、ツールの UI やバージョンは執筆当時のままで、最新版とは差異があります。

今回はFigmaの基礎編を解説します。

デザインファイルまでの作成は前回紹介しましたので参考にしてください。

本記事の完成デザインは下画像になります。

枠線の設定

前回はヘッダーとフッターを作成しました。

今回は最初にコンテンツ内のカードを作っていきます。

以下のgifは、フレームを作成後から始まっています。

Point

枠線を設定したい要素を選択

右ナビゲーション内のStrokeという項目を見つける

Stroke項目の右に＋アイコンがあるのでクリック

カラーコードが下に表示されるのでクリック

カラーピッカー or カラーピッカー下の色履歴で任意の色を選択

カラーコード下に表示されるので、三本線横の数字で線の太さを設定

これで枠線の設定ができました。

様々な要素の作成

カードの枠ができましたので中身を作成します。

下gifのようにタイトルテキストとコンテンツテキストを作っておきます。

次にコンテンツ下部に枠線とアバターアイコンを要素パーツを使用して設定します。

Point: 直線の作成

ヘッダーの四角アイコン横の∨をクリック

下にいくつか項目が出てくるのでLineをクリック

作成したい場所までマウスを持っていく

ドラッグアンドドロップで範囲指定

Point: 円の作成

ヘッダーの四角アイコン横の∨をクリック

下にいくつか項目が出てくるのでEllipseをクリック

作成したい場所までマウスを持っていく

ドラッグアンドドロップで範囲指定

中央や端まで移動すると補正が効きます
Shift + 移動でx軸とy軸を固定できます

これでコンテンツ下部に枠線とアバターアイコンができました。

グループ化

カードフレームの要素が多くなってきたので一つにまとめていきます。

Point

グループ化したい要素を選択（複数）

右クリックでメニューを表示

メニュー内のGroup selectionを選択

左ナビゲーション内でShift + 選択したい範囲をクリックすると範囲選択

要素を選択した状態で Ctrl + Gでグループ化

これで要素を一つにまとめられました。

丸みの変更

カード内の要素として最後にアバターアイコン横にボタンを作成します。

アバターアイコン横にフレームを作成して背景色を付けました。

ボタンフレームに丸みを付けたいのでボタンを丸くします。

Point

丸みを付けたい要素を選択

右ナビゲーション内のFrameという項目を見つける

Frame項目の赤枠内の数字をクリック

数値の変更をして指定したい値まで変更

方向キー↑↓で1ピクセル変更可

これでカード内の要素を全て作成し終わりました。

コンポーネントの作成

カードは通常、複数存在するので複製していきます。

しかし前回行ったコピペによる複製ではなく、より強化された複製コンポーネント機能を使用します。

Point

コンポーネント化したい要素を選択

右クリックでメニューを表示

メニュー内のCreate componentを選択

要素を選択した状態でCtrl + Alt + Kでコンポーネント化

コンポーネント化はgifの通り色々な機能があります。

マスターコンポーネントを調整すると子コンポーネントに反映
子コンポーネント内要素の調整（マスターコンポーネントには反映されない）
- 要素の表示、非表示切り替え機能
- 要素のテキスト変更機能

再利用しそうなフレームは積極的にコンポーネント化して、以後のデザイン調整を楽にするのがFigmaの最大メリットのひとつです。

オートレイアウトの作成

ボタン内のテキストを後から長い文言に差し替えたい場面が出てきました。

そこでオートレイアウト機能を使ってボタン内のテキストを変更していきます。

Point: オートレイアウト化

オートレイアウト化したい要素を選択

右クリックでメニューを表示

メニュー内のAdd auto layoutを選択

要素を選択した状態でShift + Aでオートレイアウト化

通常変更テキストが長くなると要素外に飛び出してしまうのですが オートレイアウト機能を使用するとgifの通り、上下左右の余白を保ってくれます。

フレーム内の要素の幅、高さが可変する時はオートレイアウト機能を使用します。

先程のオートレイアウトだとボタンが右に長くなっていき、右側の余白が小さくなってしまいます。

もうひと手間いれて右側の余白を維持したまま可変対応します。

Point: 始点の変更

始点の変更したい要素を選択

右ナビゲーション内のConstraintsという項目を見つける

四角図内になる青線を選択して、始点の変更

これでボタンオートレイアウトの始点を右下に変更し、右側の余白を維持したまま可変対応できました。

四角図の右にleftなど書かれている文字からも始点変更できます。

オートレイアウト機能にはもう一つ有効な機能があります。

その機能を利用して今度はカード周りの余白の大きさ、カード間の余白の大きさを調整します。

Point: オートレイアウトの調整

オートレイアウト化したい複数要素を選択

オートレイアウト化

右ナビゲーション内のAuto layoutという項目を見つける

Auto layout項目内の一番右の四角をクリック

要素の上下左右の余白ピクセルがでるので調整

三本線のアイコンをクリック

オートレイアウト化した要素間の広さを調整

右ナビゲーション内のAuto layoutは余白の調整ができます。

同一の要素が複数表示される時はオートレイアウト機能を使い、要素外の余白＆要素間の余白が楽に調整できるので積極的に使用します。

完成

以上今回はFigmaの基礎編２を解説しました。

次回はFigmaをもっと管理しやすくする機能を解説します。

関連記事: Figmaの使い方〜基礎編３〜

Figmaの使い方〜基礎編１〜フレーム・テキスト・整列など最初の基本操作

Wed, 30 Mar 2022 00:00:00 GMT

2026-05-16 追記: 初出から数年経過した記事です。骨子は今も参考になりますが、ツールの UI やバージョンは執筆当時のままで、最新版とは差異があります。

Figma の基礎編、その一回目。前回でデザインファイルまで作ったので、ここからは画面の中身を組んでいきます。

関連記事: Figmaの使い方〜準備編〜

完成形は下の画像のとおり。シンプルな画面ですが、フレーム・色・テキスト・整列という Figma の基本がひととおり詰まっています。

基本操作

画面のおおよその見方は以下の通りです。

ヘッダーは操作系統
左サイドバーは作成したオブジェクト
右サイドバーは選択したオブジェクトの調整

Flame

まずは大元になる画面範囲を作成します。

フレームというパーツを使用して画面を表現していきます。

フレームは画面の範囲、要素の外枠などで多様するパーツでテンプレートがいくつか用意されているので、最初はそれを使うと簡単に作成できます。

Point

ヘッダーのフレームアイコンをクリック

右ナビゲーションにフレームテンプレートが表示されるので、任意のフレームを選択

クリックすると中央にiPhone 13 Pro Maxに対応したフレームが作成できました。

右ナビゲーションには # iPhone 13 Pro Max と書かれたフレームが作成されてます。

大元になる画面範囲を作成できたので、ここからは画面内の要素作成に入ります。

まずはヘッダーを作成します。

先程はフレームのテンプレート機能を使いましたが、今回は自由作成でフレームを作成していきます。

Point

ヘッダーのフレームアイコンをクリック

作成したい場所までマウスを持っていく

ドラッグアンドドロップで範囲指定

自由作成では数ピクセル単位で作成するのは難しいので、大体の大きさで作成しましょう。

自由作成はヘッダーなどの大きな塊や、ボタンなどの小さな要素のベースを作成する時に使用します。

背景色の変更

自由作成で作成したフレームは真っ白の状態なので認識しやすいようにヘッダー用のフレームに背景色をつけようと思います。

背景色などの細かな調整は、右ナビゲーション内で行います。

Point

調整したい要素を選択

右ナビゲーション内のFillという項目を見つける

Fill項目の右に＋アイコンがあるのでクリック

カラーコードが下に表示されるのでクリック

カラーピッカーで任意の色を選択

これで背景色を黒く変更できました。

要素の移動、大きさの変更

ヘッダーの色は付けられましたが、位置も大きさもおかしいです。

持っていきたい位置と大きさに修正してきます。

Point: 位置の修正

調整したい要素を選択

ドラッグアンドドロップで持っていきたい場所まで移動

中央や端まで移動すると補正が効きます

Shit + 移動でx軸とy軸を固定できます

Point: 大きさの変更

調整したい要素を選択

大きさを変更したい要素の枠までカーソル移動

ドラッグアンドドロップで大きさを調整

これでヘッダーがある正しい位置と大まかな大きさにできました。

しかしヘッダーの高さが数ピクセルずれてしまったので、微調整します。

Point: 要素の高さ微調整

調整したい要素を選択

右ナビゲーションのFrame内にあるHのテキストを選択

数値の変更をして指定したい値まで変更

方向キー↑↓で1ピクセル変更可

Frame内のX, Yは位置、W, Hは横と高さの値が表示され修正できます。

テキスト入力

ヘッダーの枠を作成したので、ヘッダー内の要素を作っていこうと思います。

今回は解説用にヘッダー内にテキストを表示させます。

Point

ヘッダーのTアイコンをクリック

テキストを表示したい箇所でクリック

入力状態になるので、任意の文字を入力

これでヘッダー内に「ヘッダー」という文字を表示できました。

フォントサイズ変更

今の状態では文字が小さすぎるので見やすいようにフォントサイズを大きくします。

細かな調整なので他と同様、右ナビゲーション内で行います。

Point

調整したいテキストを選択

右ナビゲーション内のTextという項目を見つける

Text項目右下に数字が書いてある項目を見つける

数字をクリック

数値の変更をして指定したい値まで変更

方向キー↑↓で1フォントサイズ変更可

これで見やすいフォントサイズまで変更できました。

要素の揃え方

フォントサイズは見やすい大きさまで調整できました。次にテキストの表示位置を修正しようと思います。

細かな調整なので他と同様、右ナビゲーション内で行います。

Point: 要素の横中央揃え

調整したい要素を選択

右ナビゲーション内の中央に縦線が引いてあるアイコンをクリック

Point: 要素の縦中央揃え

調整したい要素を選択

右ナビゲーション内の中央に横線が引いてあるアイコンをクリック

中央揃えした時と同行の他アイコンは整列系のアイコンです。

ヘッダーは完成したので、フッターを作成していきます。

フッターのデザインはヘッダーと同じデザインを使用するので、ヘッダーをコピーします。

Point: 要素の複製

複製したい要素を選択

Ctrl + Cを入力

Ctrl + Vを入力

これでフッター用にコピーできました。

しかしヘッダーと同じ位置にあるので、一番下に持っていきます。

Point: 要素の縦下揃え

調整したい要素を選択

右ナビゲーション内の下部に横線が引いてあるアイコンをクリック

これでフッターも完成です。

ここまでで Figma の最初の操作はひととおり触れたはず。次回は、Figma を使うなら早めに押さえておきたい中核機能を扱います。

関連記事: Figmaの使い方〜基礎編２〜

Figmaの使い方〜準備編〜アカウント作成・チーム作成・デザインファイル作成まで

Tue, 29 Mar 2022 00:00:00 GMT

2026-05-16 追記: 初出から数年経過した記事です。アカウント作成・チーム作成・ファイル作成という骨子は今も同じですが、UI の細部や用語は当時のまま残しています。現在の Figma には Dev Mode、Variables、Auto layout の強化など、当時には無かった機能が追加されています。最新の画面と読み比べる前提でお読みください。

今回はFigmaの概要と、最初のデザインファイルが開くまでの準備を整理します。アカウント作成・チーム作成・ファイル作成の3つを順番に進めるだけで、UI デザインのキャンバスにたどり着けます。

Figma の概要を理解する

Figma はブラウザ上で動く UI デザインツールです。インストール不要で、URL を開けばすぐに編集画面に入れます。

他にもプロトタイピング用のツールはありますが、Figma の輪郭をつかむうえで押さえておきたい特徴は次の2つです。

クラウド上で作業する
複数人で同時編集できる

クラウドで作業する

Figma はファイルがクラウドに置かれ、編集も基本的にブラウザの中で完結します。

アカウントさえ作っておけば、ブラウザが動く PC からログインするだけで、編集中のデータを閲覧・編集できます。手元の環境にツールをインストールする必要はありません。

複数人で同時編集できる

Figma の最も特徴的な点は、複数人が同じファイルを同時に編集できることです。

個人で使う分には恩恵は薄いですが、仕事でプロトタイプを進める場合、ファイルを zip で渡す・最新版を取り違える、といった面倒がほぼなくなります。

※リモートワークの会議では特に効きます。画面共有しながらその場で直す、ができるためです。

アカウントを作成する

実際に使い始めるには、まず Figma のアカウントを作ります。

公式サイトを開いて、サインアップに進みます。

https://www.figma.com/

アクセスすると上の画面が表示されるので、赤枠の Sign up ボタンをクリックします。

クリックすると、アカウント新規作成モーダルが表示されます。

Google アカウントで新規作成するのが手間が少なく、おすすめです。メールアドレスでも問題ありません。

チームを作成する

アカウントを作成してログインできたら、最初にチームを作成します。

チームは PC のフォルダに近い概念です。先にチームというフォルダを作り、その中にデザインファイルを置く、という階層になります。

以下の赤枠箇所をクリックします。

クリックすると、チーム名入力画面が表示されます。

任意のチーム名を入力して、Create team ボタンをクリック。

次にチームに追加したいユーザーを入力する画面に進みます。

今回は一人で無料枠で作るので、画面下にある Skip for now をクリックして進めます。

最後に Figma のプランを選択します。

無料プランで進めるので、赤枠の Choose Starter を選択。これでチーム作成は完了です。

デザインファイルを作成する

チームができたので、実際に編集する場所、デザインファイルを作成します。

無料版では、デザインファイルは3つまでしか作成できない点に注意してください（執筆当時の制限。最新の上限は公式の料金ページを確認してください）。

デザインファイルの作成自体は簡単です。

左側に作成したチーム名が表示されているので、選択すると下の画面が表示されます。

赤枠をクリックすると、新規のデザインファイルが作成されます。

作成すると以下の画面が開き、これで準備は完了です。

ここまでで、Figma の概要を押さえ、空のキャンバスにたどり着くところまで進みました。

実際にこのキャンバス内で何をどう操作するかは、続編の基礎編で扱っています。

関連記事: Figmaの使い方〜基礎編１〜

デザイン思考とは？共感から真の問題を探すプロセスと仕事への活かし方

Sat, 19 Mar 2022 00:00:00 GMT

2026-05-16 追記: 初出から数年経過した記事です。骨子は今も参考になりますが、ツールの UI やバージョンは執筆当時のままで、最新版とは差異があります。

デザイン思考とは？

仕事で「デザイン思考」を使う場面が増えたので、自分なりの解釈も交えて整理しておきます。

デザイン思考はもともとデザイナーが創造の場面で使っていた考え方を、他分野の問題解決にも応用しようとしたアプローチです。

理論や数字を重視し「問題を解決する考え方」をする論理的思考に対し、

デザイン思考は共感や感情を起点に「真の問題を探索する考え方」と整理できます。

よく引かれる例が、自動車を世に出したフォードの逸話です。「速い馬が欲しい」というユーザーの要求を、馬という具体物ではなく「移動したい」という抽象的な欲求として読み替え、車という解を選んだとされています。

このように、提示された問題そのものを疑い、その奥にある真の問題を取りに行くのがデザイン思考の特徴です。

デザイン思考のプロセス

この考え方では、問題解決を「発散」と「収束」のパターンで進めます。これをダブルダイヤモンドモデルと呼びます。

プロセスは大きく四つの段階に分かれます。

正しい問題を見つけるための発散と収束 — 「探索」と「定義」
正しい解決策を見つけるための発散と収束 — 「展開」と「提供」

この 4 段階を素早く回しながら、製品の精度を上げていきます。

正しい問題を見つける発散

探索

探索フェーズはデザイン思考の核「真の問題を探索する考え方」を最も意識する場面です。

実際に使用するユーザーを観察したり、インタビューしたりして「ニーズを探索する」のがここでの仕事です。

なぜその操作（行動）を行ったのか
サービスを触る前後の心理状態（感情）はどうだったか
など

こうした問いかけで問題を発散させます。

当たり前で言わなくてよさそうなことから、奇抜で突飛なことまで、薄く広く出していきます。

定義

探索で仮説が出そろったら、今度は問題を絞り込みます。

ユーザーが最も強く感じている問題はどれか
根本的な原因・要因はどう抽象化できるか

ユーザー視点だけでなく、マーケティングや営業の視点も入れて、多面的に収束させます。

正しい解決策を見つける発散

ここから先は、ふだんの論理的思考に近い領域です。

アイデア出しでは、次の点に気をつけています。

アイデアは多ければ多いほどよい
当たり前のことほど質問する
早すぎる決定（固執）は危険
アイデアを否定しない

デザイン思考のデメリット

時間とコストがかかる

プロセスの特性上、どうしても時間とコストがかかります。

ビジネスとしての製品開発には締切がある以上、あらかじめタイムリミットを切ったうえで回すのが現実的です。

実践のハードルが高い

ユーザー視点と共感が肝心で、これは一朝一夕には身につきません。観察とインタビューを地道に重ねる訓練が要ります。

そのうえでアイデアを広げる発想力も求められるので、初学者がいきなりフルに回すのは難しい部類です。

ちょっとした改善には不向き

真の問題から探り直すデザイン思考は、新しいソリューションを生み出すのは得意な反面、既存機能の細かい改善にはコスト過剰になりがちです。改善寄りのタスクなら、論理的思考で淡々と詰めるほうが速い場面も多いと思います。

実際に用いるためには

ユーザー視点・共感・アイデア創出のいずれも訓練が要るため、明日からフルセットで回すのは現実的ではありません。

そこで、エッセンスだけ抜き出して普段の働き方に少しずつ混ぜる方法を考えました。

結局この考え方が言いたいこと

核は「真の問題を探索する」こと、言い換えると提示された問題から一歩引いて考えてみることだと受け取っています。

ユーザー視点が最も効きますが、そこに囚われず、対象の背景を想像するだけでも別の角度が見えてきます。デザイン思考はそういう「視点をずらす道具」として捉えると、肩肘張らずに使えると思います。

ユーザー視点を鍛える

ユーザー視点を鍛えるには、自分がふだん使っている類似商品を実際に触ってみるのが手早い方法です。

使い慣れた製品との違いに気づき、比較できるようになる。それがユーザー視点の第一歩になります。

ミクロデザイン思考

デザイン思考を看板に掲げて推進しなくても、考え方の一部分だけを日常の業務に差し込むことはできます。

たとえばミーティングのある議題について、そもそもこの議題設定は正しいのか、視点が局所的になっていないか、と疑ってみる。小さい単位で練習を重ねると、議論の解像度も少しずつ変わってくるはずです。

microSD カードの選び方 — 規格表記の読み方と用途別に必要な性能

Sat, 26 Feb 2022 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。SD アソシエーション側の表記体系自体は当時から変わっていないが、容量帯の相場と SDUC（4TB 超）対応カードの市場投入状況を 2026 時点で見直した。具体的な機種リンクは確認のうえ最新モデルへ差し替えること。

microSD カードを買おうとすると、棚に並ぶカードの表面にやたら記号が書いてある。「SDXC」「U3」「V30」「A2」「I」。同じ容量でも値段が倍違う。どれを買えばいいのか。

この記事では microSD カード表記の読み方を整理し、用途別（スマホ / ミラーレスカメラ / GoPro / Switch）に必要な最低ラインを示す。読み終える頃には、棚の前で迷う時間がなくなるはず。

結論 — 容量と速度を別々に読み、用途で必要ラインを決める

短い答え: microSD の性能は「容量規格（SDHC/SDXC/SDUC）」「速度クラス（Class/UHS/Video Speed Class）」「バス（UHS-I/II/III）」の3層で決まる。どれか1つだけ見ても判断できない。

用途別の最低ラインは以下:

スマホ（Android）: 128GB / A1 / UHS-I
ミラーレス静止画 + 連写: 64GB 以上 / UHS-II 対応カードと本体
GoPro / アクションカム 4K: 128GB / V30 / UHS-I U3
Switch / 携帯ゲーム機: 128〜256GB / UHS-I（速度より容量優先）
ドライブレコーダー: 64〜128GB / 高耐久（“High Endurance”）モデル

逆に言うと、用途を決めれば見るべき記号は2つか3つに絞れる。

SD カードの容量規格 — SDHC / SDXC / SDUC

短い答え: 容量規格は「カードが扱える上限容量」を示し、対応機器側との互換性に関わる。新しい機器なら基本気にしなくていい。

容量規格は3世代ある:

SDHC: 2GB 超〜32GB
SDXC: 32GB 超〜2TB
SDUC: 2TB 超〜128TB

規格用語の整理

SDHC / SDXC / SDUC は「カード自体の容量上限」と「採用しているファイルシステム」の組み合わせを規定する。SDHC は FAT32、SDXC は exFAT、SDUC も exFAT。古い機器に新世代カードを挿しても、ファイルシステム未対応で読めない場合がある。

互換性: 古い機器ほど狭くなる

機器側の対応は「下位互換あり、上位互換なし」が原則。2015年以降の機器であれば SDXC 対応がほぼ標準で、ここで詰まることは少ない。

機器が対応する規格	32GB 以下（SDHC）	64GB〜2TB（SDXC）	2TB 超（SDUC）
SDHC のみ	OK	NG	NG
SDXC まで	OK	OK	NG
SDUC 対応	OK	OK	OK

2026 時点で SDUC 対応カードは市場に出始めたばかりで、4TB 超のカードを使う場面は限られる。一般用途は SDXC 範囲（64GB〜1TB）で十分。

速度クラス — Class / UHS Speed Class / Video Speed Class

短い答え: 速度クラスは「最低書き込み速度」の保証値。Class（旧）、UHS Speed Class（U）、Video Speed Class（V）の3系統あり、新しいほど厳密。

混乱しやすいが、3系統とも「これ以下には落ちません」という下限の話で、最高速度の話ではない。動画録画のように途切れたら困る用途で効く。

速度クラスとは（定義）

SD Association が定める、連続書き込み時の最低速度の保証規格。「Class10」「U1」「V10」はいずれも最低 10MB/s を保証する別表記。同じ性能を違う記号で示しているだけのケースがある。

3系統の対応関係

最低書き込み	Class	UHS Speed	Video Speed
2 MB/s	C2	—	—
4 MB/s	C4	—	—
6 MB/s	C6	—	V6
10 MB/s	C10	U1	V10
30 MB/s	—	U3	V30
60 MB/s	—	—	V60
90 MB/s	—	—	V90

2026 時点で店頭に並ぶカードはほぼ U1 / U3 / V30 / V60 / V90 の表記が中心。古い Class2〜6 のカードはほぼ消えた。

バスインターフェース（UHS-I / II / III）は別の話

速度クラスが「下限の保証」なのに対し、バスインターフェース（カード裏の端子形状）は「上限の規格」。

UHS-I: 理論上限 104 MB/s
UHS-II: 理論上限 312 MB/s
UHS-III: 理論上限 624 MB/s

UHS-II 以上はカード裏に2列目のピンがある。本体側のスロットも UHS-II 対応でなければ、速度は UHS-I 相当に落ちる。スマホ・GoPro・エントリーミラーレスは UHS-I 止まりが多い。

アプリケーションパフォーマンスクラス（A1 / A2）

短い答え: スマホでアプリを SD に置く前提の規格。最低の連続書き込み速度に加え、ランダム I/O（IOPS）の下限が定義されている。

規格	最低書き込み（連続）	最低ランダム読み	最低ランダム書き
A1	10 MB/s	1,500 IOPS	500 IOPS
A2	10 MB/s	4,000 IOPS	2,000 IOPS

連続速度は同じだが、A2 は細かいファイル操作が速い。アプリを SD に移すなら A2 のメリットが出やすい。ただし A2 の真価は機器側のキャッシュ機構に依存するため、対応していない Android では A1 と差が出ないケースがある。

容量の選び方 — 用途別の現実的なライン

短い答え: 容量は「使い切れる最大」ではなく「容量単価が一番安い帯」で選ぶ。

容量単価は中容量（128〜256GB）が底になることが多い。32GB と 128GB の価格差は数百円〜千円程度のことが多いので、迷ったら大きい方を選んで損は少ない。

用途別の目安

スマホ（写真・動画・音楽）: 128GB が下限、256GB が安心
4K 動画録画（GoPro / カムコーダー）: 128GB で約2時間（4K60p、ビットレート 100Mbps 換算）
ミラーレス RAW 連写: 64GB で約 1,500〜2,000 枚（24MP RAW 換算、カメラ機種による）
Switch / 携帯機: 256GB あればダウンロード版ソフトを 20 本前後保持できる
ドライブレコーダー: 64〜128GB の High Endurance 推奨。標準カードは書き換え回数で壊れる

比較: 用途別の最低スペック早見表

用途	容量規格	容量目安	速度クラス	バス
スマホ（Android）	SDXC	128GB	A1 / U1	UHS-I
アプリを SD に移す Android	SDXC	128GB	A2 / U1	UHS-I
GoPro / 4K アクション	SDXC	128GB	V30 / U3	UHS-I
8K カムコーダー	SDXC	256GB+	V60 / V90	UHS-II
ミラーレス静止画 + 連写	SDXC	64GB+	V60 / V90	UHS-II
Switch	SDXC	128〜256GB	U1 / U3	UHS-I
ドラレコ	SDXC	64〜128GB	U1（High Endurance）	UHS-I

よくある質問

Q. 32GB と 128GB、迷ったらどちらを買うべき？ A. 迷ったら 128GB。容量単価（円/GB）は中容量帯が最も安く、32GB との価格差は数百円〜千円程度。動画やアプリ用途で容量不足になるリスクの方が大きい。

Q. Class10 と UHS-I U1 と V10 はどう違う？ A. 3つとも「最低書き込み速度10MB/s」を意味する別記号。Class は旧規格、U は UHS バス向け、V はビデオ向けに策定された。新しいカードは V 表記または U 表記が中心。

Q. Nintendo Switch には何が必要？ A. Switch 公式は UHS-I 対応の microSDXC を推奨。速度クラスより容量が体感に効くため、128GB〜256GB の UHS-I U1 / U3 を選べば十分。

Q. 高い UHS-II カードを買えば速くなる？ A. 対応機器側が UHS-II スロットを持たない限り速くならない。スマホ・GoPro・エントリーミラーレスはほぼ UHS-I 止まり。UHS-II が活きるのは高速連写の中〜上位ミラーレスや 8K カムコーダー。

まとめ

microSD カードの表記は「容量規格 / 速度クラス / バス」の3層で読むと迷わない。

用途を決めれば必要なラインは絞れる。スマホは 128GB + A1、4K 動画は 128GB + V30、ミラーレス連写は UHS-II 対応カード、Switch は容量優先。逆に、用途を決めずに「一番速いやつ」を買うと、本体側が対応していなくて速度が出ない、という典型的な無駄遣いになる。

棚の前で迷ったら、まず自分の用途を1つに絞ること。記号の読み方はその後でいい。

Manfrotto PIXI EVO レビュー — フルサイズも載る、バッグに入る自由雲台ミニ三脚

Wed, 16 Feb 2022 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。PIXI EVO は 2026 現在も Manfrotto の現行ラインアップに残っている定番モデル。レビュー観点（耐荷重・2 段開脚 + 4 段伸縮・自由雲台ロックの硬さ）は今も実用上の判断材料になる。スペック表記は執筆当時の公称値で、最新の公式表記とは差分があり得る。

ミラーレスを買ったタイミングで、机の上 / カフェ / 屋外スナップを 1 本で賄えるミニ三脚を探していた。条件は、フルサイズ機を載せても破綻しないこと、バッグに入ること、ロー / ハイの両方を一定範囲でカバーできること。

選んだのは Manfrotto PIXI EVO。同じ Manfrotto の PIXI 無印より一段重く、その代わり 4 段伸縮 + 2 段開脚を持つモデル。2 年以上、室内のブツ撮りから旅行先のスナップまで持ち歩いた範囲でレビューを残しておく。

結論 — フルサイズも載るミニ三脚を 1 本だけ持つなら有力

短い答え: 公称耐荷重 2.5kgでフルサイズ機まで載り、2 段開脚 + 4 段伸縮で机上ローから目線下のハイまで一台で賄える、実用派の自由雲台ミニ三脚。

理由は単純で、「載せられる重量」と「届く高さの幅」を同時に確保できるミニ三脚は意外と少ないから。多くのミニ三脚は耐荷重 1kg 前後・脚は固定長で、フルサイズ機が載らないか、載っても高さがほぼ動かせない。PIXI EVO は両方の弱点を片側ずつクリアしている。

ただし以下に該当する人は別候補を勧める:

柱や手すりに巻きつけたい人: フレキシブル脚の JOBY ゴリラポッドのほうが用途に合う
重量が 1g でも惜しい人: 270g（公称）は同クラスのミニ三脚の中では重め
動画の水平を 1° 単位で出したい人: 自由雲台ロックが硬く、微調整は苦手

外観 — 赤いロゴが目印、雲台一体型のずんぐりフォルム

短い答え: マットブラックの脚 + 赤い Manfrotto ロゴの自由雲台、という見覚えのある配色。雲台と脚は一体構造で、雲台のロックは天面のロゴ部を回す独特の方式。

分類としては 1/4 インチネジの自由雲台付きミニ三脚。脚の根元に開脚モード切替スイッチ、各脚に伸縮ロックボタンを備える。記憶に残りやすい独特のフォルムをしている。

項目	値
自重	約 270g（公称）
最大耐荷重	約 2.5kg（公称）
雲台	自由雲台（1/4 インチネジ天面）
脚伸縮	4 段
開脚モード	2 段（通常 / ロー）

雲台のロックは正面の赤い Manfrotto ロゴを回す方式。ロゴはそこそこ固く、勝手に緩むことはない。1/4 インチネジは雲台中央のダイヤルで締める。アルカスイス互換クランプも載るが、クランプ幅が雲台の倍近くあるので頭でっかちになりやすい。

脚の根元にあるスライド式スイッチで、通常開脚 / ロー開脚を切り替える。スイッチ下にモードの図がプリントされているので、初見でも迷わない。

ロー開脚にすると、脚が床にベタっと張り付くように開く。机の上で物撮りをするとき、被写体の正面に低く構えたいときに効く配置。

畳むと細長い棒状。脚の裏側が斜めにカットされているので、3 本がきれいに密着する。バッグの隙間や上着のポケットにも収まるサイズ感になる。

各脚にプッシュボタン式の伸縮ロックがあり、押しながら引き出して長さを変える。

伸縮は 4 段。途中で止めても固定できるが、実運用では「全伸ばし」か「全縮め」のどちらかで使う場面がほとんどで、中間段は微調整用と捉えると素直。

カメラ本体はレビュー時に撮影で使っているため、代わりに GoPro を載せた状態。GoPro クラスだと PIXI EVO は完全にオーバースペックだが、それでも安定感は気持ちいい。

良かった点

短い答え: フルサイズ機を載せても剛性が破綻しない / 2 段開脚 + 4 段伸縮で「届く高さの幅」が広い / 畳むと棒状になりバッグに入る。

耐荷重 2.5kg（公称） — フルサイズ機までは現実的に載る

ミニ三脚として珍しく、フルサイズ機 + 標準ズームでも雲台が負けない剛性を持つ。さすがに大三元の望遠ズームは重心が高すぎて推奨できないが、標準域までなら机上ブツ撮り・テーブルフォト・低ポジションスナップで実用範囲に収まる。

脚先はゴム接地で、フローリングや机の天板でも滑りにくい。屋外の砂利・コンクリ段差では脚の接地角を調整しないと滑るが、これは PIXI EVO というよりミニ三脚全般の制約。

2 段開脚 + 4 段伸縮 — 「届く高さの幅」が広い

一般的なミニ三脚は脚が固定長で、結果として「机に置く高さ」一択になる。PIXI EVO はロー開脚で床ベタ置き、通常開脚 + 全伸ばしで目線下くらいまで稼げる。

机上のブツ撮りでは「ロー開脚で被写体目線」、屋外のスナップでは「通常開脚 + 全伸ばしで腰位置」と、シーン別に高さを切り替えやすい。1 本のミニ三脚で 2 〜 3 シーンを賄うなら、この自由度が効く。

畳むと棒状 — バッグの隙間に収まる

脚の裏側が斜めカットで、3 本が密着して棒状にまとまる。カメラバッグの中仕切りの隙間や、デイパックのサイドポケットに刺せるサイズ感。フルサイズ機向けの可搬性としては優秀で、「重いけれど持ち運べる」のラインに収まっている。

自撮り棒の代用にもなる

脚を畳んだまま柄として握れば、簡易自撮り棒として成立する。脚を全伸ばしすれば、畳んだ状態でもさらに数十センチ稼げる。専用自撮り棒の長さ・軽さには負けるが、三脚と自撮り棒の両方を持ち歩く必要がなくなるのは旅行用途で効いた。

微妙だった点

短い答え: 270g（公称）はミニ三脚としては重め / 自由雲台のロックが硬く 1° 単位の微調整が苦手 / 雲台の 1/4 ネジは天面むき出しで、外したクランプ類が直接擦れる。

自重 270g（公称） — ポーチ運用では「あるな」と感じる重さ

「フルサイズ機まで載る剛性」と表裏一体だが、ミニ三脚としては重い部類。サコッシュや小型ポーチに入れると、出かける前に「これ持って行くか？」と一瞬迷う重さ感がある。

携行性を最優先するなら、フレキシブル脚で 50g 台の JOBY ゴリラポッド JB01542-PKK のような選択肢のほうが軽い。ただし耐荷重と剛性は別物なので、「軽さを取るか、載せられる重量を取るか」のトレードオフ。

自由雲台のロックが硬く、微調整が苦手

雲台ロックを担う赤いロゴ部はそこそこ固い。落下防止の意味では正しい設計だが、構図を 1° ずつ追い込みたいときに、ロックを緩めた瞬間に意図より大きく動いてしまうことがある。

動画で水平を厳密に出したい / パン操作で微妙な速度コントロールをしたい用途では、3way 雲台か、ロック圧を独立で持つ専用ボール雲台のほうが向く。スチル中心ならほぼ気にならない範囲。

雲台天面の 1/4 ネジがむき出し

クイックリリースは非搭載で、雲台天面に 1/4 インチネジがそのまま立っている。カメラを外して放置すると、ネジ天面とバッグ内壁が擦れる。布製インナーケースに入れるなど、ひと手間で回避できるが、設計上のクセではある。

比較

短い答え: 「フレキシブル脚」と比べると重いが剛性で勝つ。「PIXI 無印」と比べると重く高いが耐荷重と高さの幅で勝つ。「一般的な伸縮式ミニ三脚」と比べると脚は短いが、自由雲台込みのコンパクトさで勝つ。

vs JOBY GorillaPod JB01542-PKK — 「軽さ・変則設置」 vs 「剛性・耐荷重」

観点	Manfrotto PIXI EVO	JOBY GorillaPod JB01542-PKK
想定機材	スマホ〜フルサイズ標準ズーム	スマホ・Web カメラ・GoPro
自重	約 270g（公称）	約 52g（公称）
最大耐荷重	約 2.5kg（公称）	約 325g（公称）
設置場所	平らな床・机	床・柱・手すり・棚縁
高さ調整	2 段開脚 + 4 段伸縮	脚の曲げ方で都度調整
自由雲台ロック	あり（硬め）	あり（硬め・無段階）

PIXI EVO は 平らな場所で重い機材を据える、GorillaPod は 平らでない場所に軽い機材を引っかける。用途が真逆なので、選択は「重さを載せたいか / 変な場所に置きたいか」で決まる。詳しい比較は JOBY ゴリラポッド JB01542-PKK のレビューを参照。

vs PIXI 無印 — 「軽さ・安さ」 vs 「耐荷重・高さの幅」

観点	PIXI EVO	PIXI 無印
想定機材	フルサイズ標準ズームまで	ミラーレス標準ズームまで
最大耐荷重	約 2.5kg（公称）	約 1kg（公称）
脚伸縮	4 段	なし（固定長）
開脚モード	2 段	1 段
価格帯	中位	入門

スマホ・コンデジ・ミラーレス（標準ズーム）までで完結する用途なら PIXI 無印で十分。「いつかフルサイズ機を載せるかも」「ロー〜ハイで高さを切り替えたい」と感じるなら EVO の差額は意味がある。

vs 一般的な伸縮式ミニ三脚

観点	PIXI EVO	一般的な伸縮式ミニ三脚
高さ最大	脚 4 段伸縮 + 通常開脚	エレベーター式で高めまで
雲台	自由雲台一体型	3way 雲台モデルもあり
微調整	苦手（ロックが硬め）	3way なら得意
収納時	脚密着で棒状	雲台が出っ張りがち
携行性	バッグの隙間に入る	サイズ次第

「収納時の細さ」と「机上〜目線下の使い分け」を取るなら PIXI EVO、「高さ最大値」と「動画の微調整」を取るなら別ジャンル。同じ「ミニ三脚」でも狙う場面が違う。

よくある質問

Q. PIXI（無印）と PIXI EVO はどちらを選ぶべきですか？ A. 載せる機材で決めるのが素直。スマホ・コンデジ・ミラーレス（標準ズーム）までなら PIXI 無印で十分。フルサイズ + 標準〜中望遠まで視野に入れるなら、耐荷重 2.5kg（公称）と 4 段伸縮を持つ PIXI EVO のほうが安心。逆に「机に置いてスマホで Vlog を撮るだけ」なら EVO の重さと厚みはオーバースペック。

Q. GoPro やスマホ用の自撮り棒として使えますか？ A. 脚を閉じた状態で柄として握れば、簡易自撮り棒として成立する。最大伸長まで脚を伸ばせば、閉じたままでもさらに数十センチ稼げる。ただし専用自撮り棒のような長さ・軽さは出ないので、あくまで「三脚兼用」と割り切る用途向け。

Q. アルカスイス互換クランプを載せられますか？ A. 雲台天面は 1/4 インチネジ。市販のアルカスイス互換クランプを直接ネジ留めできるが、クランプ幅が雲台の倍ほどあるので頭でっかちになりやすい。アルカ運用が前提なら、雲台ごと交換せず最小サイズのクランプを選ぶのが無難。

Q. フルサイズ一眼を載せて屋外で使えますか？ A. 公称耐荷重 2.5kgの範囲なら載るが、地面の状態と風の影響を強く受ける。砂利の上やコンクリの段差では脚先ゴムが滑りにくくなるよう接地角を調整し、長秒露光時は重心を下げる（センターポールを伸ばさない・ストラップを巻きつけない）。風が強い日はバッグを下に置いて重しにするのが安全。

総評 — 「1 本だけミニ三脚を持つ」なら有力候補

PIXI EVO は、ミニ三脚に「耐荷重・剛性・高さの幅・畳んだときの細さ」を同時に求めたときに残る数少ない選択肢。スマホ専用の最軽量機よりは重く、フレキシブル脚の変則設置はできないが、その代わり「フルサイズ機を載せて室内・屋外を一台で賄う」という現実的な使い方が成立する。

2 年以上の常用で、雲台のロックが緩む / 脚伸縮ロックが滑る、といった経年劣化は出ていない。多少重くても、長く使える方をひとつ持っておきたい人向きの三脚。

逆に「とにかく軽く」「柱に巻きつけたい」用途なら、別ジャンルを当てたほうが満足度が高い。用途が「平らな場所に少し重めの機材を据える」と決まっているなら、後悔の少ない 1 本。

Minecraft 用 PC の推奨スペック — Bedrock は中堅 GPU、MOD/Java は中級 GPU + 16GB が現実解

Tue, 27 Apr 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。執筆当時（2021年）は GTX 1650 / Core i5 世代を前提に書いていた。Bedrock Edition が主流になり、Java はむしろ MOD 用に残る位置づけになった現状を踏まえて全面改稿。

Minecraft を PC で遊びたい。けれどゲーミング PC は種類が多くて、どこまでスペックを盛ればいいのか分かりにくい。

この記事は、Minecraft 用 PC を「Bedrock のバニラを軽く遊ぶ」「Java で MOD を大量に入れる」「配信もする」の 3 つの用途に分けて、必要なスペックの目安をまとめる。2026 年時点での現実的なラインで見ていく。

結論 — Bedrock なら 8〜10 万円、Java + MOD なら 15 万円〜が現実ライン

短い答え: Minecraft はゲームとしては軽い部類だが、Java 版に MOD を積み始めた瞬間に要求スペックが跳ね上がる。

2026 年時点での現実的な目安はこの 3 段階。

Bedrock のバニラ中心: GTX 1650 / RTX 3050 クラス + 16GB RAM + Ryzen 5 / Core i5。完成品で 8〜10 万円台
Java + MOD / 影 MOD: RTX 4060 クラス + 32GB RAM + Ryzen 5 / Core i5（6 コア以上）。15〜20 万円台
配信もする: RTX 4060 Ti 以上 + 32GB RAM + Ryzen 7 / Core i7（8 コア以上）。20 万円〜

逆に、激安ノート（CPU 内蔵 GPU のみ）はバニラでも描画距離を切り詰める前提になる。長く遊ぶなら最初から独立 GPU 搭載機を選んだほうが結果的に安い。

推奨スペックの読み方 — 公式値は「動く最低ライン」

短い答え: Mojang 公式の推奨スペックは「ストレスなく動く下限」であって、快適に遊べる線ではない。

公式の Java 版推奨スペック（2026 年時点）はおおむね以下のとおり。

CPU: Intel Core i5-4690 3.5GHz / AMD A10-7800 APU 3.5GHz 相当
RAM: 8GB
GPU: GeForce 700 シリーズ / Radeon Rx 200 シリーズ（OpenGL 4.5 対応）
ストレージ: SSD 4GB
OS: Windows 10 以降 / macOS 10.12 以降 / 主要 Linux

ここで読み取るべきは「Java 版は CPU と RAM を見ている」という点。GPU は控えめでも動く一方、レッドストーン回路や大規模建築の処理は CPU 単一スレッド性能に依存する設計のため、CPU を削るとワールド読み込みやチャンク生成で詰まりやすい。

Bedrock 版は要求が下がる、ただし RTX ON は別

Bedrock Edition は DirectX 12 ベースで最適化されており、同じグラフィック設定なら Java より軽い。一方で公式の RTX レイトレーシング機能は GPU 側にレイトレ対応コアが必要で、実質 RTX 20 シリーズ以降が前提になる。

Java 版は「MOD を入れた瞬間」が本番

Java 版は MOD 前提で見たほうがいい。MOD/影 MOD を入れると、

影 MOD（OptiFine, Iris + Sodium 系）: GPU 負荷が一気に増える
大型 MOD パック（200〜400 MOD）: RAM 使用量が 8GB → 12〜16GB に増加
大規模工業 MOD / 自動化: CPU シングル性能と RAM 帯域が効く

公式の推奨スペック表は「バニラ Java」の値なので、MOD を入れる前提なら 1〜2 ランク上を見ておく。

MOD/Java vs 統合版 — 2026 年の選び方

短い答え: 2026 年時点では Bedrock がデフォルト、Java は MOD と影 MOD のために残す位置づけ。

PC ストアで Minecraft を買うと Java & Bedrock Edition がセットで付いてくるのが主流なので、「どちらを買うか」ではなく「主にどちらで遊ぶか」で考える。

Bedrock を選ぶ理由

クロスプレイ: Switch / PS / Xbox / スマホとマルチプレイできる
公式 RTX 対応: レイトレーシング標準
マーケットプレイス: 公式ストアからスキン・ワールド購入

Java を選ぶ理由

MOD エコシステム: Forge / Fabric を中心に MOD 文化が成熟
影 MOD（シェーダー）: Iris + Sodium で軽量化しつつ見栄えを上げられる
過去ワールドの互換性: 2010 年代の Java ワールドはそのまま読める

Bedrock の RTX とは別物として、Java の影 MOD は表現力が高い反面 GPU を強く要求する。同じ「Minecraft をきれいに遊びたい」でも、Bedrock RTX と Java + 影 MOD で必要なスペックの方向が違うのは押さえておきたい。

比較表 — 用途別の推奨スペック

観点	軽量プレイ（Bedrock バニラ）	MOD 多用（Java + 影 MOD）	配信もする
CPU	Ryzen 5 / Core i5（6 コア）	Ryzen 5 / Core i5（6 コア以上）	Ryzen 7 / Core i7（8 コア以上）
GPU	GTX 1650 / RTX 3050	RTX 4060	RTX 4060 Ti 以上
RAM	16GB	32GB	32GB
ストレージ	SSD 500GB	SSD 1TB（MOD パック・ワールド領域）	SSD 1TB + 録画用に追加 SSD
描画距離の目安	16〜24 チャンク / 60fps	24〜32 チャンク / 60fps	16〜24 チャンク + 配信 60fps
価格帯（完成品）	8〜10 万円	15〜20 万円	20〜30 万円

数値は 2026 年時点のミドルレンジ構成を基準にした目安。

CPU は「コア数より単一スレッド性能」

Java 版のチャンク生成・レッドストーン演算は単一スレッドに寄る性質があるため、コア数を増やすより 1 コアあたりの性能（クロック × IPC）を見たほうが体感に効く。配信を載せる場合だけ、エンコード用にコア数が効いてくる。

GPU は「Bedrock RTX か / Java 影 MOD か」で分かれる

Bedrock RTX: RTX 20 系以降が前提、4060 で十分快適
Java + Sodium + 影 MOD: 中設定なら RTX 3060、高設定なら RTX 4060 以上が目安

「とりあえず RTX 4060」を選んでおけば、Bedrock RTX も Java の重めの影 MOD も両方こなせる。

RAM は MOD パックの規模で決める

バニラのみなら 16GB で足りる。MOD パックを入れるなら 32GB を選ぶ。Java の起動引数（-Xmx）でゲームに割り当てる RAM を指定するため、システム側に残す分も含めて余裕を持たせる設計になる。

ストレージは SSD 一択、容量はワールドと MOD で決まる

OS と Minecraft 本体だけなら 100GB もあれば足りるが、MOD パックと大規模ワールド（数 GB / ワールド）を残していくとあっという間に埋まる。SSD 1TB を最初から積むほうが後悔が少ない。

項目	スペック
画面	15.6 インチ FHD
CPU	Core i5 / Ryzen 5（最新世代）
RAM	16GB
GPU	GeForce RTX 3050 Ti / 4050
ストレージ	SSD 512GB

項目	スペック
CPU	Ryzen 5 / Core i5（最新世代、6 コア以上）
RAM	32GB
GPU	GeForce RTX 4060
ストレージ	SSD 1TB

よくある質問

Q. Bedrock 版と Java 版、どちらを買えばいいですか？ A. クロスプレイや RTX 公式対応を取るなら Bedrock 版、MOD や影 MOD を入れたいなら Java 版を選ぶ。2026 年時点ではどちらか片方を買えば Minecraft: Java & Bedrock Edition として両方が付いてくる構成が主流。

Q. ノート PC でも MOD は動きますか？ A. GeForce RTX 3050 Ti / 4050 以上を積んだゲーミングノートなら動く。ただし影 MOD + 描画距離 32 チャンクのような重い構成では発熱とサーマルスロットリングで動作が不安定になりやすいので、本気で MOD を回すならデスクトップを勧める。

Q. RAM は 16GB と 32GB どちらが適切？ A. Bedrock + バニラ Java なら 16GB で足りる。MOD パック（200 個超）や大規模レッドストーン回路、配信ソフトを同時に動かすなら 32GB を選ぶ。後から増設できる機種かどうかも判断材料になる。

Q. 統合 GPU（CPU 内蔵グラフィックス）でも遊べますか？ A. 最新の Ryzen AI 系や Intel Arc 内蔵 GPU なら Bedrock のバニラは 1080p / 中設定で動くレベルにはなった。ただし Java 版や影 MOD はフレームレートが落ちるので、長く遊ぶつもりなら最初から独立 GPU 搭載モデルを選んだほうが安い。

まとめ

Minecraft 用 PC は「何で遊ぶか」で必要スペックが大きく変わる。

Bedrock バニラ中心 → GTX 1650 / RTX 3050 + 16GB、8〜10 万円
Java + MOD / 影 MOD → RTX 4060 + 32GB、15〜20 万円
配信もする → RTX 4060 Ti + 32GB + 8 コア CPU、20 万円〜

2026 年時点では Bedrock が主流だが、MOD と影 MOD のために Java も残っている。両方を視野に入れるなら RTX 4060 + 32GB の構成が一番つぶしが効く。

モニター側の選び方は別の記事でまとめている。

SONY ウォークマン NW-A105 レビュー — Type-C と Android で乗り換えた DAP の、2026 年からの再評価

Sat, 24 Apr 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事（初出 2021 年、購入から半年程度の使用感を書いていた）。2026 年現在、A シリーズの現行は NW-A300 シリーズ（NW-A306 国内 / A307 海外、2023 年発売）。NW-A105 自体は生産完了で、新品流通は在庫限り。骨子は今も参考になるが、購入を検討するなら現行モデルとの比較で読むこと。

通勤と外出時の音楽再生用に、5 年以上 SONY のウォークマン NW-A105 を使ってきた。USB Type-C と microSD と Android が揃った最初期のウォークマンで、当時としては「ようやくまともな端子になった」モデル。

ただし 2026 年の視点で振り返ると、長所と短所がはっきり分かれる端末でもある。この記事は、長期使用での実感と、現行の NW-A300 シリーズ・スマホ単体運用との比較を整理する。

結論 — Type-C / microSD / Android が揃った最初期 DAP、新規購入なら現行 A300 を勧める

短い答え: NW-A105 は「ウォークマンに Type-C と Android が載った最初の世代」として価値があったモデル。音質設定の細かさは今も通用する。ただし CPU とバッテリー周りが弱く、新品で買うなら 2026 年現行の NW-A300 シリーズを勧める。

理由は、NW-A105 の弱点（もっさり動作・待機消費の大きいバッテリー）が、いずれも内部パーツに依存する性質のもので、ソフトウェアアップデートで根本解決できる類ではないから。バッテリーセーバーで運用面はマシになったが、根の問題は残る。

買って良い人 / 避けたほうがいい人を整理する:

買って良い: 中古で安く手に入り、有線イヤホン + microSD + 細かい音質設定を使い倒したい人
避けたほうがいい: 新品で買おうとしている人、スマホ単体で音楽が完結している人、バッテリー持ちを最優先する人

外観

短い答え: 3.6 インチタッチパネルの小さな Android 端末。右側面に物理ボタンが集中し、下部に 3.5mm イヤホンジャック・USB Type-C・microSD スロットが並ぶ。

ハイレゾ対応、Android OS のウォークマン。操作はほぼタッチパネル。

項目	スペック
液晶	3.6 インチ
サイズ	55.9 × 98.9 × 11 mm
重量	103 g
OS	Android 9（発売時）
端子	USB Type-C / 3.5mm イヤホンジャック / microSD

（公称）

背面はマット仕上げで Walkman のロゴ。指紋は目立ちにくい。

左側面はボタン類なし。

右側面に操作ボタンが集中。左から「ロック / 戻る / 再生・停止 / 進む / 音量− / 音量+ / 電源」の順。鞄やポケットに入れたまま、ブラインドで再生制御できる物理ボタンの並びは DAP として正解の設計。

下部に 3.5mm イヤホンジャック・ストラップホール・USB Type-C・microSD スロット。3.5mm が残っているのは、有線派にとっては大きい。

ホーム画面は Android 標準に近い構成。アプリも自由に追加できる（Google Play 対応）。

良かった点

短い答え: USB Type-C・microSD・Android の3拍子と、ソニー独自の音質処理機能の細かさ。

USB Type-C — これだけで乗り換えた

NW-A105 を選んだ最大の理由がここ。旧モデルまでのウォークマンは WM-PORT という独自端子で、専用ケーブルを持ち歩く必要があった。

Type-C 化で、スマホ・タブレットと同じケーブルで充電できるようになる。出張先や旅行先で「ウォークマン用のケーブルを忘れた」事故が消える効果は大きい。

microSD で容量を後付けできる

本体ストレージは 16GB と控えめ。ハイレゾ音源を本体だけで管理するのは無理がある。

逆に言えば、microSD 前提の設計。本体は OS とアプリだけに使い、音源は microSD に逃がす運用が現実解。最大 1TB の microSDXC まで使える（公称）ので、ライブラリ拡張に余裕がある。

音質設定の引き出しが多い

ソニー製 DAP の本領が出る部分。

イコライザーは 10 バンド近くで細かく調整できる。ジャンル別プリセットも用意されている。

ノイズキャンセリングは対応イヤホン（IER-NW500N など）と組み合わせる前提。通勤電車での騒音はかなり抑えられる。

音質処理機能の主要なものは以下:

DSEE HX: 圧縮音源をハイレゾ相当にアップサンプリング
DC フェーズリニアライザー: 位相特性を補正してアナログアンプ風の音にする
ダイナミックノーマライザー: 楽曲間の音量差を均す
バイナルプロセッサー: アナログレコード風の音に加工
ClearAudio+: ソニー推奨の自動最適化プリセット

「全部 ON」が必ずしも良くない、というのは使い込んでわかる。曲ジャンルごとに DSEE HX のオン・オフを切り替える、といった調整がハマると音は化ける。

Android なので拡張が効く

Android 9 ベース。Google Play 経由で Spotify / Apple Music / YouTube Music が入る。ローカル音源と並行して、ストリーミングも 1 台で完結できる。

Bluetooth でスマホからプレイリストや音源を流すような連携もそのまま使える。

微妙だった点

短い答え: バッテリー持ちと CPU 性能。どちらもパーツ依存でソフトでは解決しない。

バッテリー消費が大きい

最大の不満点。

電源を入れているだけで目に見えてバッテリーが減る。再生していない待機状態でも、1 日放置で残量が大きく削れる。

公称ではハイレゾ再生で約 26 時間あるが、実使用では「使っていない時間の消費」が体感を下げる。後日のアップデートでバッテリーセーバー（一定時間後の自動電源オフ）が追加され、運用面はかなり改善した。それでも根本解決ではない。

通勤・通学用途で「家か職場で毎日充電できる」前提なら問題ないが、丸 2 日持ち歩く出張にはやや厳しい。

全体的にもっさり

CPU 性能が控えめで、アプリ起動・画面遷移・大きなライブラリのスクロールが引っかかる場面がある。

スマホと違って常時いじる端末ではないので致命的ではないが、Spotify アプリを開いて検索バーで日本語入力、のような操作はストレスを感じる。

ソフトウェアサポートが終わっている

2026 年現在、NW-A105 の Android 9 はメジャーアップデートが止まっており、セキュリティ的にもメインのスマホ用途には向かない。

音楽プレーヤー専用機として割り切る前提なら問題ないが、ストリーミングアプリの将来的な互換性は保証されない。

比較 — NW-A105 vs NW-A300 シリーズ vs スマホ単体

短い答え: 新品で買うなら NW-A300、コストと割り切りで選ぶなら NW-A105 中古、すべて完結したいならスマホ単体。

観点	NW-A105（2019）	NW-A300 シリーズ（2023〜）	スマホ単体運用
OS	Android 9	Android 12 ベース	各機種最新
CPU 体感	もっさり	改善	機種次第で快適
バッテリー（公称ハイレゾ）	約 26 時間	約 36 時間（公称）	音楽再生に占有される
本体ストレージ	16GB	32GB（公称）	機種次第
microSD	あり（最大 1TB）	あり	なし（多くの機種）
端子	USB Type-C / 3.5mm	USB Type-C / 3.5mm	Type-C のみが主流
ノイキャン（独自イヤホン）	対応	対応	非対応
DSEE HX 等の音質処理	あり	あり（DSEE Ultimate に進化）	なし
価格（2026 想定）	中古中心	新品 4 万円台後半〜	スマホ代に含まれる

判断軸はシンプル:

音質処理と有線環境にこだわる + スマホのバッテリーを音楽で消費したくない → NW-A300 を勧める
同じ要件を最小コストで満たしたい → NW-A105 中古
ストリーミング中心 / 完全ワイヤレスイヤホン / 1 台で完結したい → スマホ単体で十分。DAP は要らない

よくある質問

Q. NW-A105 を 2026 年に新品で買う価値はありますか？ A. 新規購入なら現行の NW-A300 シリーズ（NW-A306 / A307）を勧める。NW-A105 は 2019 年発売で、CPU 性能とバッテリー持ちが弱い。中古で安く手に入り、microSD と Type-C と Android が揃った DAP が欲しいだけなら選択肢にはなる。

Q. スマホで音楽を聴くのと比べて、NW-A105 を持つ意味はありますか？ A. ノイズキャンセリングや DSEE HX などソニー独自の音質処理を使いたい人、スマホのバッテリーを音楽再生で消費したくない人にはまだ意味がある。プレイリストはストリーミングで完結し、有線イヤホンも使わないなら、スマホ単体で十分。

Q. バッテリーはどのくらい持ちますか？ A. 公称はハイレゾ再生で約 26 時間。実測では電源を入れた状態の待機消費が大きく、再生しなくても 1 日放置すると目に見えて減る。後日アップデートで自動電源オフのバッテリーセーバーが追加されている。

Q. microSD は何 GB まで対応しますか？ A. 最大 1TB の microSDXC まで対応（公称）。本体ストレージは 16GB と少ないので、ハイレゾ音源を入れるなら microSD 前提で運用する設計。

総評 — 「DAP に Android が乗った最初の世代」を体験する端末

NW-A105 は「ようやくウォークマンが Type-C になった」と「ウォークマンが Android で動く」が同時に来た世代の端末。当時の購入動機としては十分で、5 年以上使ってもライブラリの母艦として困らなかった。

ただし新規購入を勧めるかと言うと、勧めない。CPU とバッテリーは内部パーツの設計に依存していて、後継世代で素直に改善している。中古で安く済ませる、もしくは現行の NW-A300 を選ぶ、のどちらかが現実解。

ストリーミングと完全ワイヤレスイヤホンでスマホ単体で完結できているなら、そもそも DAP を増やす必要はない。「有線イヤホン + 細かい音質処理 + microSD」のどれかを譲れない人だけが、DAP を持つ価値がある。

HDD と SSD の違い — 2026 年は SSD が基本、HDD は大容量アーカイブ用に

Wed, 21 Apr 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。執筆当時（2021年）は「OS は SSD、データは HDD」のハイブリッドが現実解だったが、2026 年は SSD 価格が下がり、ノート PC・自作 PC ともに SSD がデフォルトになった。HDD はバックアップや動画素材など、数 TB 級のアーカイブ用途に役割が絞られている。骨子（仕組みの違い）は今も有効。

PC の動作が重い、買い替え時に SSD と HDD どちらを選べばいいか分からない — このあたりで足が止まる人は多い。仕組みの違いを一度押さえると、判断が早くなる。

この記事は、HDD と SSD の違いを速度・容量単価・寿命・静音性・衝撃耐性の観点で並べ、2026 年時点での選び方をまとめる。

結論 — システム用は SSD、大容量保管は HDD

短い答え: 2026 年に新しく買う・組むなら、OS とアプリを置くシステムドライブは SSD（できれば NVMe）一択。HDD は1台あたり数 TB を安く確保したいときの補助ストレージとして使う。

理由は、SSD 価格がこの5年で大きく下がり、1TB クラスが普及帯に収まったため。一方で HDD は1TB あたりの単価では今も SSD より安く、4TB / 8TB といった大容量帯ではコスト優位が残っている。

例: ノート PC を1台買い替えるなら SSD 単体構成で十分。自作 PC で動画素材や写真の RAW を貯めるなら、システム = SSD 1TB + データ = HDD 4TB の2台構成が現実的。

注意点: 古い HDD だけの PC を使い続けるより、SSD への換装が体感的に一番効く投資。買い替えより安く済むことも多い。

HDD と SSD の主な違い

短い答え: 6つの観点で並べると、SSD は「速い・静か・衝撃に強い」、HDD は「安く大容量・実績が長い」と整理できる。

観点	HDD	SSD
読み書き速度	遅い（順次100〜200MB/s 程度）	速い（SATA で〜550MB/s、NVMe で数千 MB/s）
容量単価（GB あたり）	安い（4TB 以上で優位）	高め（ただし1TB 帯は普及価格に低下）
寿命	機械部品の摩耗で故障	書き込み回数の上限あり、衝撃には強い
静音性	回転音・シーク音あり	無音
衝撃耐性	弱い（動作中の落下で故障しやすい）	強い（可動部なし）
価格目安（1TB）	数千円〜	1万円前後〜（NVMe は上振れ）

理由は、両者は内部構造そのものが違うから。HDD は物理的に回転する円盤に磁気で記録するのに対し、SSD は半導体メモリに電気的に記録する。この差が全観点の優劣を決めている。

注意点: 表は一般傾向。NVMe SSD と SATA SSD では速度がさらに数倍開く。詳しくは FAQ の項を参照。

HDD とは — 回転する円盤に磁気で記録する装置

短い答え: HDD（Hard Disk Drive）は、回転する金属円盤にデータを磁気で書き込む / 読み出す記憶装置。可動部を持つ機械装置で、CD プレイヤーに近い構造。

理由は、円盤を高速回転させ、その上で磁気ヘッドを移動させて該当位置にアクセスするため、物理的な動きが介在する。これが「読み書きが遅い」「動作音が出る」「衝撃に弱い」の根本原因になっている。

例: 一般的な 3.5 インチ HDD は 5400rpm または 7200rpm で回転する。シーク音（ヘッドが動く音）と回転音が常に出ているため、静音 PC を組むなら扱いが難しい。

注意点: HDD のメリットは大容量の安さ。4TB / 8TB / 16TB といった帯では2026 年でも SSD より単価が低い。バックアップ・動画素材保管・NAS 用途では現役。

SSD とは — 半導体メモリに電気で記録する装置

短い答え: SSD（Solid State Drive）は、フラッシュメモリ（半導体）にデータを電気的に書き込む / 読み出す記憶装置。可動部が一切なく、USB メモリの大型版に近い。

理由は、半導体に電子の有無で 0 / 1 を記録する仕組みのため、物理的な移動が発生しない。これが「高速」「無音」「衝撃に強い」「軽い」の根本理由になっている。

例: 同じ OS の起動でも、HDD 機が30〜60秒かかるところ、SSD 機は10秒前後で立ち上がる。古い PC を SSD 化したときの体感差が大きいのはこのため。

注意点: SSD は書き込み回数に上限がある（TBW = Total Bytes Written で表記）。ただし普通のオフィス / ゲーム / 開発用途で寿命を使い切ることは稀。日常用途では機械的に壊れる HDD のほうが先に故障する事例が多い。

SSD と HDD の使い分け — 2026 年版

短い答え: システムドライブ（OS / アプリ）は SSD、データ倉庫（写真・動画・バックアップ）は HDD。これが2026 年の標準解。

理由は、起動とアプリ立ち上げの速さは SSD が明確に効き、データ保管はアクセス頻度が低いので速度差が体感されにくいから。容量単価で勝る HDD を「冷たいデータ」用に回すのが合理的。

ノート PC / 一般用途 — SSD 単体でよい

ノート PC や一般的なデスクトップなら、SSD 1台（512GB〜1TB）で完結する構成が主流。HDD を併用しない分、軽量・静音・低消費電力のメリットが取れる。

ゲームや動画編集をするなら 1TB か 2TB を目安にする。

自作 PC / クリエイター — SSD + HDD の2台構成

写真の RAW、動画素材、ゲームの大量ライブラリを抱える人は SSD（システム）+ HDD（データ）の2台構成が今でも合理的。

システム = NVMe SSD 1TB
データ = HDD 4TB 以上

古い HDD 機の延命 — SSD 換装が最も効く

「PC が重い」と感じる原因の多くは HDD の遅さ。メモリ増設より、HDD → SSD の換装のほうが体感差は大きい。買い替え予算が出せない場合の現実的な選択肢。

換装には SATA SSD と、データ移行用の USB 接続ケースを使うのが定番。

よくある質問

Q. SSD と HDD を併用するハイブリッド構成は今でも有効ですか？ A. 自作 PC やデスクトップで大容量を必要とするなら有効。システムは SSD、データ・バックアップは HDD という分担は合理的なまま。一方でノート PC は物理的に SSD 1台のスロットしかないモデルが多く、ハイブリッド構成は組みづらい。

Q. NVMe SSD と SATA SSD はどちらを選ぶべきですか？ A. マザーボード / ノート PC が M.2 スロット（NVMe 対応）に対応していれば NVMe が第一候補。順次読み書きで SATA SSD の数倍速い。ただし OS の起動やオフィス用途では体感差は小さく、大量のファイルコピーや動画編集で効いてくる。コストを抑えるなら SATA SSD でも実用上困らない。

Q. SSD の寿命はどのくらいですか？ A. メーカー公称の TBW（総書き込み量）は1TB クラスで 300〜600TBW 程度。日常用途（1日 50GB 書き込みでも年間 18TB）なら10年以上の計算になり、寿命より先に容量不足や規格陳腐化で買い替えるのが普通。HDD のように突然壊れるリスクは低めだが、ゼロではない。

Q. HDD から SSD へのデータ移行はどうやりますか？ A. 主に2通り。(1) クローンソフト（メーカー提供のものが多い）で OS ごと丸ごとコピー、(2) OS を新規インストールし、データは外付けケース経由でコピー。クローンが手軽だが、Windows のライセンス / ドライブレターまわりでつまずくこともある。OS を入れ直す手間が惜しくないなら (2) のほうが結果的にきれい。バックアップを取ったうえで作業すること。

まとめ

2026 年の標準は「システムは SSD、大容量データは HDD」。ノート PC や一般用途なら SSD 単体で完結する。

HDD の役割は、5年前と比べて明確に縮んだ。バックアップ・動画素材・写真 RAW など、容量を安く確保したい用途に絞られている。

古い HDD 機の体感を上げたいなら、メモリ増設より SSD 換装のほうが先。買い替えに踏み切る前に検討する価値がある。

映像端子の違いまとめ — 迷ったら HDMI、4K 高リフレッシュなら DisplayPort

Sat, 17 Apr 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。骨子（端子ごとの位置づけ）は今も有効だが、HDMI 2.1 / DisplayPort 2.1 / USB4 など最新世代のスペックは最新の公式表記を確認してほしい。

PC とモニターを買ったはいいけど、ケーブルの端子が合わない。HDMI、DisplayPort、USB-C、DVI、VGA — どれを挿せばいいのか。

この記事は、映像端子5種類の違いと選び方を、用途別に整理する。読み終える頃には、自分の環境で買うべきケーブルが1本に絞れているはず。

結論 — 迷ったら HDMI、4K 高リフレッシュなら DisplayPort

短い答え: 普及度と性能のバランスで HDMI が無難。テレビ・ゲーム機・大半のモニターに付いているので、ケーブル1本で大体つながる。

ただし用途次第で最適解が変わる:

4K / 高リフレッシュレート / 複数モニター: DisplayPort
ノート PC を1本のケーブルで映像 + 給電したい: USB-C（DisplayPort Alt Mode）
オフィス用途で映ればいい: 余っているケーブルでよい（HDMI でも DVI でも可）

逆に DVI と VGA を新規購入で選ぶ理由はほぼない。古い機器を延命する場面だけ検討する。

映像端子は実用上5種類に絞られる

短い答え: PC 周辺で今も使われる映像端子は HDMI / DisplayPort / USB-C（Alt Mode） / DVI / VGA の5種類。Thunderbolt は物理的に USB-C と同じコネクタなので、ここでは USB-C 側に含める。

端子別の立ち位置

HDMI — 家電・PC ともに最普及。迷ったらこれ

DisplayPort — PC とグラボ寄り。高解像度 / 高リフレッシュに強い

USB-C Alt Mode — ノート PC で映像 + 給電 + データを1本にまとめる

DVI — デジタル映像の先駆け。新規購入はほぼ不要

VGA — アナログ。古い機器の延命用

HDMI — テレビ・ゲーム機・PC で共通の標準端子

HDMI とは

映像と音声を1本で伝送するデジタル端子。2002 年に策定されて以降、テレビ・モニター・ゲーム機・PC まで横断的に採用されている、いま最も普及度の高い映像端子。

短い答え: 普及度が高く、対応機器が幅広い（家電・PC・ゲーム機を横断）ので、迷ったときの第一候補。

理由は2つある。1つは音声を同じケーブルで送れること（最大8ch、Dolby / DTS 対応）。S/PDIF など音声専用端子と違ってサラウンド規格をそのまま通せる。もう1つは家電側（テレビ・レコーダー・ゲーム機）が HDMI 前提で設計されていること。

バージョン差は「4K で何 Hz 出るか」が分かれ目

HDMI はバージョンによって最大解像度・リフレッシュレートが変わる。

Ver	1.2	1.4	2.0a	2.1
最大解像度	FHD	4K	4K	10K
HDR	×	×	○	○
FHD 時の最大 Hz	60 Hz	120 Hz	240 Hz	240 Hz
4K 時の最大 Hz	—	30 Hz	60 Hz	120 Hz 以上

FHD で使う分にはバージョンを気にしなくていい。4K で 60Hz 以上を狙うなら Ver.2.0a 以上、ゲーミング用途で 4K 120Hz / 8K を視野に入れるなら Ver.2.1 を選ぶ。

ケーブル単体の選び方は別記事にまとめている。

→ HDMI ケーブルの選び方 3点（長さ・端子・規格）

DisplayPort — PC・グラボ・高リフレッシュ用途の標準

DisplayPort とは

PC 業界の標準化団体 VESA が策定した映像端子。グラフィックボードや一部の Mac、ゲーミングモニターに搭載される。高解像度・高リフレッシュレートで HDMI より先行することが多い。

短い答え: 4K 以上の高解像度、120Hz / 240Hz の高リフレッシュレート、複数モニターを1本でつなぐ MST (Multi-Stream Transport) — このどれかを狙うなら DisplayPort。

理由は規格設計の出発点が PC 用ディスプレイだから。HDMI が家電寄りなのに対し、DisplayPort は最初から高解像度 / 高フレームレート / 帯域効率を優先している。同世代で比べると DisplayPort のほうが先行している場面が多い。

バージョン差は HDMI より緩やか

Ver	1.2	1.4	2.0
最大解像度	4K / 5K	8K	16K
HDR	×	○	○
FHD 時の最大 Hz	240 Hz	240 Hz	240 Hz 以上
4K 時の最大 Hz	60 Hz	120 Hz	240 Hz 以上

旧バージョンでも 4K 60Hz には対応するので、HDMI ほどバージョンで迷わなくていい。

注意点: 電源オフでウィンドウ配置がリセットされる

DisplayPort には PC ユーザー側に1つクセがある。モニター側の電源を切ると、PC が「モニターが外れた」と判定する。

結果として、デュアルモニター環境ではウィンドウやアイコンの配置がプライマリ側に寄せられる。電源を入れ直しても元には戻らない。

対策は「モニターの電源を切らずスリープに任せる」「DisplayPort の代わりに HDMI を使う」「DDC/CI を無効化する設定を探す」など。気にする人は購入前に把握しておく価値がある。

USB-C（DisplayPort Alt Mode）— ノート PC を1本にまとめる

USB-C Alt Mode とは

USB Type-C コネクタの一部ピンを使って DisplayPort 信号を流す仕組み（DisplayPort Alternate Mode）。映像 + データ + 給電（USB Power Delivery）を1本のケーブルでまとめられる。Thunderbolt も物理的にこの形。

短い答え: ノート PC をモニター1台で完結させたい人に向く。映像・周辺機器・給電（最大100W 程度）を1ケーブルでまかなえる。

理由はケーブル本数の削減効果が大きいから。デスクに戻って USB-C を1本挿せば、外部モニター・キーボード・マウス・充電が同時に復活する構成が組める。

注意点: 端末側の対応次第で出せる性能が変わる

USB-C は物理コネクタの名前であって、映像を流せるかは「DisplayPort Alt Mode」または「Thunderbolt」に端末が対応しているかで決まる。

ノート PC 側の USB-C ポートが映像出力対応か（仕様表で「映像出力」「DisplayPort Alt Mode」「Thunderbolt 3/4」を確認）
ケーブルが映像対応か（充電専用ケーブルでは映らない）
モニター側に USB-C 入力があるか（無ければ USB-C → HDMI / DisplayPort のアダプタが必要）

この3点が揃わないと映像は出ない。スペック表を読む手間は HDMI より多い。

DVI — デジタル映像の先駆け、新規購入は不要

DVI とは

1999 年に登場したデジタル映像端子。VGA の後継として PC 業界に普及した。Windows 系デスクトップ PC やビジネスモニターでは今も搭載例があるが、ノート PC やテレビではほぼ採用されない。

短い答え: DVI は FHD（1920×1080）程度なら問題なく映る。すでに DVI 機器が手元にある場合の延命用と割り切る。

理由は端子サイズが大きく、最新世代の機器では HDMI / DisplayPort に置き換わったから。4K には基本対応せず（DVI Dual-Link で一部対応）、新規の選択肢としては積み残しになる。

会社のデスクトップ PC をモニターにつなぐ、古いグラボから映像を出す、といった場面では現役で使える。新しく機器をそろえるなら、HDMI か DisplayPort を選んで DVI は避ける。

VGA（D-Sub）— アナログ、古い機器の延命用

VGA（D-Sub 15ピン）とは

1987 年に IBM が策定したアナログ映像端子。2000 年代までは PC とモニターの標準だったが、デジタル化（DVI → HDMI / DisplayPort）の流れで採用は減った。プロジェクターや古い会議室設備で今も見かける。

短い答え: アナログ伝送なので解像度・画質ともに現代水準に届かない。新規の選択肢から外していい。

理由は信号がアナログのため、ケーブル長や品質で画質が劣化すること。解像度も実用上 FHD が上限（公称はもっと出るが、滲みが目立つ）。

それでも会議室のプロジェクターが VGA のみ、というケースは現役で残っている。ノート PC 側が USB-C しかない場合は、USB-C → VGA のアダプタを1つ持っておくと出張時に困らない。

比較表 — 5種類を解像度 / 用途別ベスト / 普及度で並べる

端子	最大解像度（最新世代）	用途別ベスト	普及度
HDMI	10K（Ver.2.1）	テレビ・ゲーム機・一般 PC	最高
DisplayPort	16K（Ver.2.0）	ゲーミング・高解像度・マルチモニター	中（PC 中心）
USB-C Alt Mode	4K〜8K（端末依存）	ノート PC + 外部モニター1台構成	増加中
DVI	FHD / 一部 4K	既存 PC の流用	減少
VGA	FHD（実用上）	古い機器・古いプロジェクター	減少

（数値は各規格の最新版公称値。実効性能はケーブル品質と機器側実装に左右される）

選び方 — 3つの問いに順番に答える

短い答え: 「テレビ / ゲーム機にもつなぐか」→「ゲーミングや 4K 高リフレッシュか」→「ノート PC で1本にまとめたいか」の順に当てはめる。

1. テレビ・ゲーム機にもつなぐ → HDMI

家電側の端子は HDMI 一択に近い。PS5 / Switch / Apple TV / レコーダー、これらと共有するなら HDMI で揃えるとケーブル類が共通化できる。

2. ゲーミング・4K 120Hz・マルチモニター → DisplayPort

PC ゲーマーで 144Hz / 240Hz を狙う、4K 120Hz でゲームしたい、3枚以上のモニターを1本のケーブルで分配したい（MST） — このどれかなら DisplayPort。

3. ノート PC を1本のケーブルでドッキングしたい → USB-C

帰宅後に USB-C を1本挿すだけで、外部モニター・キーボード・マウス・充電が復活する構成を組みたいならこれ。USB-C → HDMI / DisplayPort 変換ケーブルを使えば、モニター側が USB-C 非対応でも対応できる。

よくある質問

Q. HDMI と DisplayPort、画質に差はありますか？ A. 同等のバージョン同士・同じ解像度・同じリフレッシュレートで使う限り、目で見て分かる画質差はほぼない。差が出るのは「対応する最大解像度 / 最大 Hz」が上回るかどうか。普段使いの FHD / 4K 60Hz 域では実質互角。

Q. USB-C で映像を出したいのに映りません。何を確認すればいいですか？ A. 3点ある。（1）ノート PC 側のスペック表で「映像出力対応」「DisplayPort Alt Mode」「Thunderbolt」のいずれかが書かれているか。（2）使っているケーブルが充電専用ではなく映像対応か（USB-C のロゴと帯域表記を見る）。（3）モニター側が USB-C 入力対応か、または USB-C → HDMI / DisplayPort 変換アダプタを挟んでいるか。

Q. DVI ケーブルを HDMI に変換しても 4K は映りますか？ A. 基本的には映らない。DVI Single-Link の帯域は FHD 60Hz 程度が上限で、4K に必要な帯域に届かない。4K を狙うなら、PC 側 / モニター側ともに HDMI か DisplayPort のネイティブ端子を使う。

Q. ゲーミング用途で迷っています。HDMI 2.1 と DisplayPort 1.4、どちらを選べばいいですか？ A. グラボとモニターの両方が HDMI 2.1 に対応していれば、4K 120Hz / 可変リフレッシュレート (VRR) で揃えやすい。古めのモニター・グラボ構成なら DisplayPort 1.4 のほうが選択肢が広い。手元のグラボ側ポートとモニター側ポートを先に確認してから決めると失敗しにくい。

まとめ

映像端子5種類の使い分けは、用途で1本に絞れる。

迷ったら HDMI。テレビ・ゲーム機を含めた家電一式と互換性があるので、ケーブル1本で大体動く。

PC ゲーミングや 4K 高リフレッシュレートを本気で使うなら DisplayPort。ノート PC をデスクで1本のケーブルにまとめたいなら USB-C Alt Mode。

DVI と VGA は手元の機器を活かすためだけの選択肢として扱う。新規購入で積極的に選ぶ場面はほぼない。

ケーブル単体の選び方（長さ・端子形状・規格バージョン）は、HDMI を例に別記事でまとめている。

→ HDMI ケーブルの選び方 3点（長さ・端子・規格）

Peak Design キャプチャー V3 ＆プロパッドレビュー — 一眼カメラを腰ベルトに固定するクリップ

Fri, 16 Apr 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。Peak Design キャプチャーは 2026 時点でも現行ラインで、後継世代（V3 以降のマイナーチェンジ）が継続販売されている。レビュー観点（ベルト運用の快適さ・ロックの堅牢性・プレート公差由来の金属音）は今も参考になる。

一眼カメラを持って出かけると、毎回バッグから出し入れする手間で撮影機会を逃す。リュックの中で寝かせていると、出した瞬間にはもう被写体がいなくなっている、というやつ。

これを物理的に解決するために、Peak Design キャプチャー V3（CC-BK-3） と プロパッド（PP-2） を導入して数年使った。腰ベルトやリュックのショルダーに一眼カメラを直付けして、片手で外してそのまま構える運用に変わる。

結論 — 一眼を頻繁に構える人なら投資価値あり

短い答え: ストラップ運用から脱却したいなら買い。ロックは堅牢で、走っても外れないし、数年使ってもボタン破損などのトラブルがない。

理由は、「カメラを構えるまでのアクション数」が劇的に減るから。バッグを下ろす → ファスナーを開ける → カメラを出す、の3アクションが、ボタンを押して持ち上げる、の1アクションになる。子連れ・動物園・運動会のように被写体が止まってくれない場面では効果が大きい。

ただし以下に該当する人は注意:

手ぶら派 + たまにしか撮らない人: 数千円のストラップで足りる
フルサイズ + 大三元レンズ常用者: 腰に重量級をぶら下げると歩行で揺れる。ショルダー側で逃がす運用が現実的
静音性が必要な場面で撮る人: プレートとクランプの公差で金属音が出ることがある（後述）

外観と質感

短い答え: アルミ削り出しの黒一色、エッジは丸めてあるが手触りは硬質。質感はカメラアクセサリの中でも上位。

正面はシンプル。中央にロック解除ボタン、左右にクランプを締め込むネジ（六角穴）が見える。

項目	キャプチャー V3
大きさ	約 13 × 13 × 3 cm
重量	約 144 g（公称）
素材	アルミ削り出し
対応ストラップ厚	〜6.4mm 程度（公称）

裏面はフラット。ベルトに直接当たる側で、引っかかりがない設計。腰運用だとこの面が肌・腰骨に近づくのでクッション（プロパッド）が要る。

側面から見ると奥行きは薄い。腰に付けてもジャケットの裾で隠れる程度には抑えてある。

下面は凹型のプレート受け。ここにカメラ側に付けたクイックリリースプレートを台形状にスライドさせて差し込む。

プロパッド PP-2

腰ベルトに付けるときの補助パッド。クッションで荷重を分散させる。

項目	プロパッド PP-2
大きさ	約 17 × 9 × 3 cm
重量	約 36 g（公称）
素材	クッション材 + ベルクロ

クッションは厚すぎず、ベルトを締めれば腰に密着する。汗をかいてもベルクロが緩むことはなかった。

良かった点

短い答え: 構えるまでの動作が最短化される / ロックが本気で堅牢 / 数年使っても壊れない。

カメラを構えるまでが片手1アクション

最大の利点。ロック解除ボタンを押しながらカメラを上に引き抜く、で完了。

バッグから出すと違って、構えると同時にもう撮れる体勢になっている。子どもや動物が予測不能に動く場面では、この 2〜3秒の差で撮れる・撮れないが分かれる。旅行・運動会・動物園・登山あたりで一番効果が大きかった。

ロック解除は意図的にしないと外れない

片手1アクションだと逆に「歩いてるうちに勝手に外れないのか」が心配になる。これは数年使った範囲で一度も発生しなかった。

ロック機構は、解除ボタンを押し込まないと垂直方向にも抜けない構造。走ってもジャンプしても、ボタンに触れなければカメラは固定されたまま。意図的にボタンを押せばスッと抜ける、というオン/オフが明確で、誤解除のストレスがない。

ボタンが本体に組み込まれていて紛失リスクがゼロ

以前使っていた別ブランドの汎用カメラクリップは、ロック解除ボタンが取り外せる構造で、半年で紛失して使えなくなった。

Peak Design 側はボタンが本体に完全に組み込まれていて、外そうとしても外れない。修理性は犠牲になるが、フィールドでの紛失リスクがゼロなのは現場運用で効いてくる。

アルカスイス互換プレートも使える

純正のスタンダードプレートはアルカスイス互換の溝形状をしているので、手持ちの三脚側がアルカスイス互換クランプなら、プレートを付け替えずに三脚に直載せできる。

別ブランドのアルカスイス互換プレートを使い回すこともできた。新規でセットを組むなら純正で揃えるのが無難だが、既に三脚周りでアルカ系を統一している人は移行コストが低い。

微妙だった点

短い答え: 互換プレート次第で金属音が出る / 重い機材だと腰運用は揺れる / 純正プレートはそれ単体だと底面が滑る。

互換プレートとの公差でカタカタ音が鳴る

プレートを差し込む凹部は、互換プレートを広く受けるためか公差に余裕がある設計。

純正の Peak Design プレートだとほぼガタつかないが、汎用のアルカスイス互換プレートだとカチャカチャと金属音が出ることがある。歩く速度が上がるほど顕著。野鳥撮影など静音性が要る現場では純正プレートに揃えるか、薄手のテフロンテープで遊びを埋める運用が必要になる。

重量級レンズだと腰運用は揺れる

フルサイズ + 70-200mm f/2.8 クラスを腰に付けると、歩行のたびに上下に揺れる。これはキャプチャーの問題というより、腰ベルトに重量物を吊るすこと自体の物理的な限界。

実運用ではこういう重量級はリュックのショルダーストラップ側にキャプチャーを移すか、ストラップを併用したほうが体が楽。腰運用が快適なのは、ミラーレス + 単焦点・標準ズームくらいまでの組み合わせ。

純正プレートの底面は三脚で滑りやすい

純正プレートは底面が平らで、滑り止めのコルク・ゴムなどが付いていない（個体差ありの可能性）。

カメラを直接置いたり、滑らかな雲台に載せたりすると、わずかに滑る感触がある。三脚に固定するときはクランプを締めれば問題ないが、机にポンと置くと滑り出すことがあるので注意。

装着・運用方法

短い答え: クランプを開いてベルトに通す → 締める、で 30秒。プレートは三脚穴に付けたら基本付けっぱなしでいい。

まずクランプの左右ネジを六角で緩める。両側どちらからでも操作できる。緩めると上側のプレートが回転するので、ベルトを通すスペースを作る。

腰運用ならプロパッドを開いて、内側の取付ガイド（イラスト印刷あり）に沿ってキャプチャーを挟む。そのままプロパッドごとベルトに通す。

プロパッドを閉じて、回転させていたキャプチャー上部を元位置に戻し、ネジを締め直す。これで完了。慣れれば 30 秒。

カメラプレートの取り付け

カメラ側はクイックリリースプレートを 1/4 インチネジで三脚穴に固定する。一度付けたら基本そのままで、外す必要はほぼない。

横から見ると底面が台形（アルカスイス互換）になっている。この凸が、キャプチャー側の凹にスライドして噛み合う構造。

キャプチャー側面の黒い円筒ボタンを押し込みながら、プレートを上から差し込む。

奥まで差し込んでボタンを放すと、ロック完了。逆にロック解除も同じボタンで一発。

GoPro でも 1/4 インチネジ経由のマウントがあればキャプチャーで固定できる。実運用としてはアクションカム用途より、ミラーレス・一眼レフを腰に付ける用途が中心になる。

比較: キャプチャー vs カメラベルト・速写ハーネス

短い答え: 「身体に密着固定」のキャプチャー、「肩から提げて素早く構える」のハーネス、「シンプルに首から」のネックストラップ — それぞれ用途が違う。

観点	Peak Design キャプチャー V3	速写ハーネス（一般）	ネックストラップ（一般）
取付位置	腰ベルト or ショルダー	肩〜脇下	首
構えるまでの動作	ボタン押す → 引き抜く	提げてるカメラを持ち上げる	同左
両手を完全に空けられるか	可能（カチッと固定）	提げたまま揺れる	提げたまま揺れる
走る・ジャンプの安定性	高い（揺れない）	中（ストラップ反動あり）	低（カメラが暴れる）
重量級レンズの相性	腰運用だと揺れる	良い（肩で逃がす）	普通
静音性	プレート公差で音が出る場合あり	静か	静か
価格帯（執筆当時）	約 1.8〜2 万円	約 5,000〜1.5 万円	約 2,000〜5,000円

「とにかく構えるまでを速くしたい」「両手を完全に空けたい」ならキャプチャー一択。「カメラを長時間提げっぱなしで歩く」運用がメインならハーネスのほうが疲れにくい。

参考までに同じカメラ周辺機器カテゴリでは、軽量機材向けに JOBY ゴリラポッド JB01542-PKK のレビューも書いている。机や柱に巻きつける固定運用なので、キャプチャー（身体に固定）とは別レイヤーの選択肢になる。

よくある質問

Q. どんなカメラ・リュックに対応していますか？ A. クランプは厚み 6.4mm までのストラップ・ベルトに装着できる仕様（公称）。多くのカメラリュックのショルダーストラップや、ベルト幅 5cm 程度までの腰ベルトであれば取り付け可能。カメラ側は 1/4 インチネジに対応していれば、ミラーレス・一眼レフ・コンデジ問わず使える。重量級の機材（フルサイズ + 望遠など）は肩や腰への負担が大きいので、ショルダーストラップを併用したほうが現実的。

Q. ハーネスや速写ストラップとどちらがいいですか？ A. 用途が違う。ハーネス・速写ストラップは「肩から提げて素早く構える」運用で、カメラは常に身体から垂れる。キャプチャーは「身体に密着固定」運用で、両手を完全に空けたいハイキングや子ども連れ撮影に強い。重さの逃がし方も違っていて、ハーネスは肩、キャプチャーは腰（プロパッド経由）に荷重を分散する。三脚撮影が多い人や、レンズ交換が頻繁な人は、両者を併用するケースも珍しくない。

Q. プロパッドは本当に必要ですか？ A. 腰ベルトに付ける運用なら実質必須。キャプチャー単体だとクランプの裏側がベルトに直接食い込み、長時間歩くと腰骨に当たって痛い。プロパッドはクッションでベルトを挟み込み、荷重を腰回りに広く分散させる構造になっている。一方、リュックのショルダーストラップに付ける運用ならクッションは不要で、キャプチャー単体で十分。「腰運用ならプロパッド込み、ショルダー運用ならキャプチャー単体」と覚えておけばいい。

Q. 数年使って壊れませんか？ A. 数年常用してロック機構が壊れたことは一度もない。クランプ部のネジ、ロックボタン、本体アルミ — どれも目立った劣化はない。比較対象として、以前使っていた別ブランドの汎用クリップはロックボタンが取り外せる構造で、半年でボタンの紛失・破損が発生した。Peak Design 側はボタンが本体に組み込まれていて取り外せないので、構造的に紛失リスクがゼロな点は大きい。

総評 — 一眼を頻繁に出し入れする人は世界が変わる

人を選ぶアクセサリだが、ハマる用途で使うと、もうストラップだけの運用には戻れない。

特に 子ども連れ・旅行・動物園・登山 あたりで、両手を空けたまま一眼を即座に構えたい人には強くおすすめできる。逆に、カメラを構える機会が月に数回なら、数千円のネックストラップで十分。

注意点はプレート公差由来の金属音と、重量級レンズでの腰揺れの2つ。前者は純正プレートで揃えるか、後者はショルダーストラップ運用に切り替えれば回避できる。

Vue.js 入門 - v-if と v-for を解説

Thu, 15 Apr 2021 00:00:00 GMT

2026-05-16 追記: 初出は Vue 2 / Options API 時代の記事です。2026 現在は Vue 3 と Composition API（<script setup>）が標準ですが、v-if / v-else / v-for といったテンプレート構文の書き方は変わっていないので、骨子はそのまま参考になります。

Vue.js を初めて使う方に向けて、今回は条件分岐と繰り返し描画にあたるディレクティブを整理します。

mustache タグと v-bind は以下の記事で解説しています。

Vue.js 入門 - mustache タグと v-bind

結論

v-if: 条件が真のときだけ要素を描画する。v-else / v-else-if も使える
v-show: 表示・非表示を CSS の display で切り替える。頻繁に出し入れする要素向き
v-for: 配列を繰り返し描画する。:key を忘れずに指定する

v-if

v-if は条件式が真のときだけ要素を描画するディレクティブです。

実務でもよく使います。スマートフォンと PC で出し分けたい要素、ログイン状態で切り替えたい UI などが典型例です。

v-if の基本的な使い方

v-if は対象要素の属性として書き、値に評価式を渡します。

以下のコードは HTML 内で判定し、表示非表示を処理しています。

実際に実行すると サンプルです。 と表示されます。

<template>
  <div v-if="sampleNum === 1">
    サンプルです。
  </div>
</template>

<script>
export default {
  data() {
    return {
      sampleNum: 1
    };
  },
};
</script>

v-else

v-if は通常の if 文と同じように else も書けます。

v-else を後続要素の属性に書くだけです。

実際に実行すると else が表示です。 と表示されます。

<template>
  <div>
    <div v-if="sampleNum === 0">
      サンプルです。
    </div>
    <div v-else>
      elseが表示です。
    </div>
  </div>
</template>

<script>
export default {
  data() {
    return {
      sampleNum: 1
    };
  },
};
</script>

注意点として、v-else は v-if の直後の要素に置く必要があります。間に別の要素が挟まると認識されません。

v-else-if

else の他に else-if も使えます。

書き方は同じで、属性に v-else-if を記述します。

実際に実行すると sampleNum は 1 です。 と表示されます。

<template>
  <div>
    <div v-if="sampleNum === 0">
      サンプルです。
    </div>
    <div v-else-if="sampleNum === 1">
      sampleNumは1です。
    </div>
  </div>
</template>

<script>
export default {
  data() {
    return {
      sampleNum: 1
    };
  },
};
</script>

v-show

v-show は v-if と似た見た目の出し分けを行いますが、内部の仕組みが違います。

書き方は v-if と同じく属性に v-show="..." と書きます。

v-if と v-show の違いは DOM ごと出し入れするか、CSS の display で隠すだけか です。

v-if は条件が真になったタイミングで要素を生成し、偽になれば DOM ごと取り除きます。v-show は最初から DOM を作っておき、display: none の付け外しだけで切り替えます。そのため切り替えコストは v-show のほうが軽く、初回描画コストは v-if のほうが軽くなります。

使い分けの目安は次のとおりです。

初期表示のときに条件が偽になりやすく、めったに出さない要素 → v-if
表示・非表示を頻繁に切り替えるトグル UI → v-show

なお、v-show は display プロパティに依存する都合上、<template> 要素や v-else との組み合わせには使えません。その場合は v-if 側で書きます。

v-for

v-for は配列やオブジェクトを繰り返し描画するためのディレクティブです。

JavaScript の for 文に近い感覚で、配列の要素分だけ同じテンプレートを並べてくれます。

書き方は属性に v-for="(item, index) in list" のように記述します。あわせて :key に一意な値を渡しておくと、Vue が差分検知を正しく行えます。

実際に実行すると 中身は 1, index は 0。中身は 2, index は 1。 と表示されます。

<template>
  <div>
    <div v-for="(num, i) in numList" :key="i">
      中身は{{ num }}, indexは{{ i }}。
    </div>
  </div>
</template>

<script>
export default {
  data() {
    return {
      numList: [1, 2]
    };
  },
};
</script>

まとめ

v-if は条件で要素を生み出すか消すか、v-show は要素を残したまま CSS で隠すか。v-for は配列を繰り返すときに :key を添える。テンプレート構文は Vue 3 でも変わっていないので、ここを押さえておけば Composition API に移っても同じ書き方で済みます。

関連記事:

Vue.js 入門 - エンジニアが解説する v-bind 基礎

Wed, 14 Apr 2021 00:00:00 GMT

2026-05-16 追記: 初出から数年経過した記事です。骨子は今も参考になりますが、ツールの UI やバージョンは執筆当時のままで、最新版とは差異があります。

Vue.js を初めて使う方に向けて、今回は Vue.js で追加された独自の HTML 記法について解説します。

結論

mustache タグ ({{ }}) で script 内の変数を HTML に出力できる
v-bind は属性に対して動的な処理を加えるディレクティブ
: プレフィックスで v-bind: を省略可能
配列記法を使えば複数の class / style を同時に適用できる

mustache タグ

script 内で定義した変数や関数を HTML 上で使用したい時に mustache タグが使えます。

mustache タグは {{ }} を HTML 上に記述すると使用できます。

以下のコードは displayText を script 内で定義し、HTML で呼び出しています。

実際に実行すると 文字列です。 と表示されます。

<template>
  {{ displayText }}
</template>

<script>
export default {
  data() {
    return {
      displayText: '文字列です。'
    };
  },
};
</script>

これが最もシンプルな記法です。

上記例は文字列の変数ですが、オブジェクト型の変数でも、もちろん使用できます。

<template>
  {{ displayObj }}
</template>

<script>
export default {
  data() {
    return {
      displayObj: {
        text: '文字列です。'
      }
    };
  },
};
</script>

注意したいのは、上記コードを実行すると { text: '文字列です。' } と表示される点です。

文字列です。 と表示したい場合は、displayObj.text と記述しましょう。

v-bind

今回の記事で最も大事なのが v-bind です。

v-bind は属性に対して動的な処理を簡単に加えられます。

特に class は動的に変えることでページに表現を大幅に加えられるのでよく使用します。

v-bind の基本的な使い方

以下のコードは activeClass というクラスを isActive の真偽値で適用するかどうか判定しています。

実際に実行すると文字色が白い 文字列です。 が表示されます。

<template>
  <div v-bind:class="{ activeClass: isActive }">
    サンプルです。
  </div>
</template>

<script>
export default {
  data() {
    return {
      isActive: true
    };
  },
};
</script>

<style lang="css">
  .activeClass {
    color: #fff;
  }
</style>

script 内のコードで isActive を定義し、HTML の v-bind:class 内で判定しています。

今回のコードは isActive が true になっているので、false にすると黒文字で表示されます。

v-bind の省略記法

v-bind は省略記法ができます。

記述方法は : を属性の先頭に書くと v-bind が適用されます。

以下のコードは activeClass というクラスを isActive の真偽値で適用するかどうか判定しています。

実際に実行すると黒文字で 文字列です。 が表示されます。

なぜ黒文字なのかは、属性内の判定で ! の not 処理をしているからです。

<template>
  <div :class="{ activeClass: !isActive }">
    サンプルです。
  </div>
</template>

<script>
export default {
  data() {
    return {
      isActive: true
    };
  },
};
</script>

<style lang="css">
  .activeClass {
    color: #fff;
  }
</style>

複数の v-bind

属性で 2 つ以上の v-bind をしたい場合、class 内を配列で記述すると複数設定できます。

以下のコードは activeClass と sampleClass の両方のクラスが適用されます。

実際に実行すると白文字で 文字列です。 が表示されます。

<template>
  <div :class="[{ activeClass: isActive }, { sampleClass: sampleNum === 1 }]">
    サンプルです。
  </div>
</template>

<script>
export default {
  data() {
    return {
      isActive: true,
      sampleNum: 1
    };
  },
};
</script>

<style lang="css">
  .activeClass {
    color: #fff;
  }

  .sampleClass {
    width: 100%;
  }
</style>

class は他と同じく通常の判定処理ができるので、比較演算子も使用できます。

基本的に v-bind は全ての属性に適用できます。しかし使用頻度が高いのは class、style、src です。

まとめ

今回は Vue.js の mustache タグと v-bind を紹介しました。

Vue.js の基礎中の基礎なのでしっかりマスターしましょう。

関連記事:

ゼンハイザー HD 598 SR レビュー — 開放型らしい広がりと、長時間でも疲れにくい掛け心地

Tue, 13 Apr 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。HD 598 SR は Amazon 限定色（黒）の派生モデルで、2026 年時点では新品流通がほぼ終了している。後継系として開放型は HD 599 / HD 560S が現行ラインに残っている。レビュー観点（開放型の音場・装着感・密閉型との使い分け）は今も参考になるはずなので、骨子はそのまま、表現と構成だけ整えた。

仕事と私用で長く使ってきた開放型ヘッドホン、ゼンハイザー HD 598 SR を改めてレビューする。

開放型を選んだことが無い人にとって最初の壁は「音が漏れる・外の音も入る」という点で、ここを許容できるかどうかで評価が真っ二つに割れる。逆にそこを許せる環境（自宅の自室・在宅作業）なら、同価格帯の密閉型より素直に音楽を楽しめる選択肢になる。

結論 — 自宅据え置きで使うなら今でも実用

短い答え: 開放型らしい広がりと長時間装着の楽さが強み。代わりに遮音性ゼロ・音漏れ前提で、外や家族と同じ部屋で使うには向かない。

理由は3つ。

音場が広い: 開放型のため、頭の中で鳴る感じが薄い。映画・配信・ライブ音源で効く
掛け心地が軽い: 側圧が強くなく、耳をすっぽり覆うオーバーイヤー型なので長時間でも疲れにくい
イヤーパッドが脱着可能: 掃除と交換がしやすく、長期運用に向く

逆に以下に当てはまる人は別機種を勧める。

通勤や外でも使いたい人: 開放型は音漏れと外音流入が大きく、公共空間では使えない
同居人と同室で深夜も聴く人: 隣に座っている人にうっすら聞こえるレベルの漏れがある
ワイヤレスが前提の人: HD 598 SR は有線のみ。Bluetooth 非対応

外観と付属品

短い答え: 黒基調で落ち着いた印象。Amazon 限定色なので、クリーム色の通常版 HD 598 が苦手な人向け。

HD 598 SR は Amazon 限定の派生色で、通常版 HD 598 のクリーム色が黒に置き換わったモデル。インテリアや在宅ワーク環境に合わせやすいのは SR のほうだと思う。

ハウジングは縦長の楕円。一般的な丸型ヘッドホンに慣れていると最初は違和感があるが、耳の形に沿うので装着すると素直に収まる。

ケーブルは着脱式で、右側のハウジング底面から生える。断線時にケーブルだけ交換できるのは長期運用上ありがたい。

付属品は以下。

付属品

3m / 6.3mm ステレオ標準プラグケーブル（据え置きアンプ・オーディオインターフェース向け）

1.2m / 3.5mm ストレートプラグケーブル（PC・スマホ向け）

6.3mm → 3.5mm 変換プラグ

ヘッドバンドの内側はクッション入り。L / R 表記も内側にあり、暗い部屋でも触ればわかる。

長さ調整は無段階に近い構造で、頭が大きめの人でも問題なく収まる（画像は最大伸長時）。

良かった点

短い答え: 音場の広さ、長時間の掛け心地、メンテのしやすさの3点が特に効く。

開放型らしい音場と素直なバランス

HD 598 SR は開放型なので、密閉型にありがちな「頭蓋骨の内側で鳴る詰まった感じ」が少ない。スピーカーで聴いているような空気感がある。

低音は開放型の構造上どうしても密閉型より弱くなる傾向だが、HD 598 SR は必要量はきちんと出ている。ベースやキックが埋もれることはなく、ジャンルを問わず破綻しない。

EDM やヒップホップなど低音で押し切る音楽を主食にする人には不向き。それ以外（ボーカル系・アコースティック系・映画・ゲーム）では素直に楽しめる。

オーバーイヤー型で長時間でも疲れにくい

耳を完全に覆うオーバーイヤー型 + 開放型 + 適度な側圧、という組み合わせで、装着疲労が少ない。

イヤホンや密閉型と違って耳の中・耳の周りに熱がこもらないので、夏場でも比較的快適。在宅作業で半日付けっぱなしにしてもストレスが少ない。

イヤーパッドが工具なしで脱着できる

イヤーパッドはロゴを下にして垂直に引き抜くと外れる（カチッと音がする）。掃除・交換が容易で、長く使うほどこの作りに助けられる。

数年使った後にイヤーパッドだけ交換すれば、本体はそのまま延命できる。Sennheiser は HD 598 系の交換用パッドを長く供給してきた。

微妙だった点

短い答え: 開放型ゆえの遮音ゼロと、有線のみ・現行では入手難という運用上の制約。

遮音性ゼロ — 外でも夜でも使いにくい

開放型の構造上、音漏れと外音流入はほぼフルに起きる。

隣の人にうっすら音が聞こえる
外の声や生活音が普通に入ってくる
ノイズキャンセリングは当然非搭載

これは設計上の特性で、欠点というより「向いていない使い方」を確認しておく必要がある項目。自宅の自室で一人で使う前提なら問題にならないが、オフィス・カフェ・寝室の隣に家族、といった環境ではそもそも選んではいけない。

有線のみ・Bluetooth 非対応

2026 年の主流はワイヤレス。HD 598 SR は有線専用で、PC・据え置きアンプ・スマホに直接刺す前提。

スマホ側に 3.5mm 端子が無くなった現代では、USB-C / Lightning DAC を挟むひと手間が要る。

価格帯と現行入手性

執筆当時の実売は約2万円前後。エントリー価格帯ではない。

加えて 2026 年時点では新品流通がほぼ終了しており、新品で買いたい人には選びにくくなっている。後継系の HD 599 / HD 560S を素直に検討するのが現実的。

比較: 開放型 HD 598 SR vs 同価格帯の密閉型 / ワイヤレス

短い答え: HD 598 SR は「自宅で据え置き・有線・音場優先」のときに勝つ。それ以外なら別カテゴリのほうが快適。

観点	HD 598 SR（開放型・有線）	同価格帯の密閉型	同価格帯のワイヤレス（NC 付き）
音場の広がり	広い	狭め	モデルによる（一般に狭め）
低音の量感	必要十分	強い	強い（DSP 補正前提）
遮音性	なし（開放型）	高い	高い（NC 込み）
音漏れ	大きい	小さい	小さい
装着疲労（長時間）	少ない	こもりやすい	バッテリ重で重め
ケーブル	有線のみ	有線中心	無線中心
屋外・通勤利用	不可	可	最適
自宅在宅作業	最適	可	可（充電必要）

HD 598 SR の勝ち筋は「自宅・自室・有線で OK・音場が広いほうがいい」という、絞り込めば狭い領域。逆にこの条件にハマる人にとっては、同価格帯の密閉型や安価なワイヤレスより明確に音楽体験が良くなる。

通勤や外で使う想定が少しでもあるなら、最初から密閉型かワイヤレス NC を買ったほうが後悔が少ない。

よくある質問

Q. スマホに直接挿して使えますか？ A. スマホ側に 3.5mm 端子があれば 1.2m ケーブルで直挿し可。最近の機種は 3.5mm 端子が無いものが多いので、USB-C / Lightning の DAC アダプタを別途用意する必要がある。インピーダンス的にはスマホ直挿しでも十分鳴る部類。

Q. 密閉型ヘッドホンと比べて何が違いますか？ A. 一番違うのは「音場」と「遮音性」。HD 598 SR のような開放型は、スピーカーで鳴らしたような空気感があり、頭の中で音が詰まらない。代わりに音漏れ・外音流入が大きい。密閉型はその逆で、遮音性が高く低音もしっかり出るが、長時間装着で耳がこもりやすい。家の自室で一人で聴くなら開放型、外や同室の人がいる環境なら密閉型、という使い分けになる。

Q. ワイヤレスヘッドホンと比べてどうですか？ A. 音質傾向は別物として、運用面の差が大きい。ワイヤレスは充電・接続・遅延の管理が必要で、その代わりケーブルが無い自由がある。HD 598 SR は有線なので充電不要・遅延ゼロ・接続安定だが、ケーブルが常に付きまとう。在宅作業で席に固定して使うなら有線のほうがむしろ楽、というケースは多い。

Q. 長時間つけても疲れにくいですか？ A. オーバーイヤー型 + 開放型 + 軽めの側圧という組み合わせで、装着疲労は同価格帯の中では少ない部類だと感じている。耳を中に押し込むイヤホンとは違い、耳の周囲を覆うだけなので圧迫感も少ない。とはいえ個人差があるので、可能なら店頭で 10〜15 分試着してから決めるのが安全。

総評 — 「自宅で据え置き」と割り切れる人向け

HD 598 SR は、用途を絞れば今でも実用に足る開放型ヘッドホン。

向いているのは、自宅の自室で在宅作業・音楽・映画・ゲームをじっくり楽しむ層。広い音場と長時間の掛け心地、メンテのしやすさが効いてくる。

向いていないのは、外で使いたい人・同室の家族と時間を共有する人・ワイヤレス前提の人。これらの用途では構造上どうしても勝てない。

新規購入を検討するなら、2026 年時点では新品流通が細っているので、後継ライン（HD 599 / HD 560S）も同時に見ておくと選択肢が広がる。中古や在庫品を狙うなら、HD 598 SR は「黒い HD 598」というだけで音は通常版と同等なので、色の好みで選んでよい。

エレコム EX-G Bluetooth M-XGL10BBBK レビュー — 安価帯で“握りの違い”を一番感じるマウス

Mon, 12 Apr 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。M-XGL10BBBK は 2026 時点でも現行ラインの低価格 Bluetooth マウスとして流通中。レビュー観点（サイズ展開・握り心地・無線安定性）は今も参考になる。スペック値は当時のメーカー公称値を引用しているため、購入前に最新の製品ページを確認してほしい。

仕事用に1年ほど使っていたエレコム EX-G Bluetooth M-XGL10BBBK を、当時の使用感と 2026 年に見直した観点でレビューする。

「マウスにそこまで出したくない、でも付属マウスからは脱したい」価格帯で、握り心地の差を一番分かりやすく感じられるモデル。サイズが S/M/L から選べるのも、この価格帯では珍しい。

結論 — サイズ展開ありの“最初のステップアップ”として最適

短い答え: 付属の安マウスから乗り換えるなら、この価格帯で握り心地の差をはっきり体感できる一台。S/M/L のサイズ展開があり、手が小さい人にもおすすめしやすい。

理由は、エルゴ形状とサイドボタンが揃っていて、握ったときの“設計の違い”が指で分かるから。無印・付属マウスから移ると、長時間使ったときの手の張りが目に見えて減る。

ただし以下の用途では別候補を検討したい:

無線安定性を最優先する人: Bluetooth 接続なので、USB レシーバー型ほど安定はしない
ボタンを細かくカスタムしたい人: 専用ソフトの自由度は Logicool Options 系より控えめ
ゲーミング用途: 反応速度・センサ性能は事務用途向け

外観 — 平べったい中間サイズのエルゴ形状

短い答え: 立体型と平べったい型の中間のフォルム。右クリック側が落ち込んだ非対称デザインで、手のひら全体で乗せて握るタイプ。

上から見たフォルム。写真は L サイズ。手のサイズに合わせて S/M/L から選べる。

裏側に電源スイッチ・ペアリングボタン・電池蓋。電源は単3電池1本で、公称電池持ちは約402日（購入前に最新の仕様を確認）。

前から見ると右クリック側が大きく落ち込んでいる。完全な平面でも完全な立体型でもない、中間サイズのエルゴ形状。

後方から。山の高さは控えめで、手のひら全体で乗せる持ち方になる。つかみ持ち専門の人は MX MASTER 系のほうが合うはず。

右側面はゴム素材で覆われていて、小指と薬指が滑らず止まる。長時間握っても汗で滑りにくい。

左側面に親指置き場とサイドボタン2つ。親指の自然な形状に合わせて凸型にデザインされているので、意識せずに親指が乗る。

良かった点 — 価格を超える“握り”とサイドボタン

短い答え: 設計された握り心地、サイドボタン搭載、S/M/L サイズ展開、軽い重量。低価格帯マウスに必要な要素が一通り揃っている。

握りを意識したエルゴ形状

このマウスの最大の特徴は、価格に対して握り心地に振っていること。

付属マウスや千円台のシンプルなマウスから乗り換えると、最初に握った瞬間に差が分かる。右側のゴムパーツ、親指置き場の凸、右クリック側の落ち込み — 単体では地味だが、合わさると長時間作業の手の張り方が変わる。

サイドボタン搭載で「戻る」が指1本

サイドボタンは作業効率に直結する装備。

主用途はブラウザの「戻る・進む」。Web 閲覧・ファイラー・IDE どれでも使う頻度が高いので、ある／なしの差は大きい。付属マウスから乗り換える理由としても十分。

S / M / L のサイズ展開

低価格帯では珍しく、3 サイズから選べる。

L は手のひらが大きめの男性向け、S は子供や手が小さい人向け、M はその中間。手のサイズが合わないマウスはどれだけ高くても疲れるので、サイズ展開があるのは実用上ありがたい。

電池抜きで約87g の軽量設計

公称重量は電池抜きで約87g。

100g 超のマウスを長時間使うと腕の疲労が違うので、軽さは事務用途では正義。単3電池を入れても感覚的には“軽め”の部類に収まる。

微妙だった点 — Bluetooth ゆえの不安定さ

短い答え: 接続方式が Bluetooth のみなので、USB レシーバー型より無線が不安定。スリープ復帰直後の認識遅延が出やすい。

スリープ復帰時の接続遅延

最大の不満点。

PC スリープ復帰直後の数秒、マウスが反応しないことがある。Bluetooth 全般の挙動なのでこのマウス固有の欠点ではないが、USB レシーバー型から移ると気になる。

頻繁にスリープ復帰を繰り返す使い方（ノート + ドック構成など）の人は、USB レシーバー併用モデル（ロジクール Unifying 対応機など）も検討すると安全。

ボタン割り当てソフトの自由度は控えめ

Logicool Options 系のような細かいジェスチャー設定はできない。サイドボタンを単純に「進む／戻る」以外に割り当てたい場合は、Windows 側のサードパーティ製ツールに頼ることになる。

ただしマウスの基本動作（DPI、ボタン）は安定して動くので、凝った割り当てをしない事務用途なら不便はない。

比較 — 同価格帯・上位帯のどこに位置するか

短い答え: 安価帯では“握り”重視で抜けている。上位帯（Logicool MX 系）と比べるとサイドホイール・カスタム性で差が大きい。

観点	M-XGL10BBBK	Logicool 中価格帯（M650 など）	千円台の安価マウス
価格帯	約2,000円前後	約4,000〜6,000円	約1,000円前後
接続	Bluetooth のみ	Bluetooth + USB レシーバー	Bluetooth または有線
サイズ展開	S / M / L	M / L（モデルにより）	なしが多い
握り心地	エルゴ形状、ゴムグリップ	エルゴ寄り、より滑らか	フラットが多い
サイドボタン	2 ボタン	2 ボタン + カスタム	なし〜2 ボタン
サイドホイール	なし	モデルにより搭載	なし
電池	単3 × 1（公称約402日）	単3 × 1 / 充電式	単3 / USB 給電
ボタン割り当てソフト	あり（控えめ）	Logi Options+（高機能）	なしが多い

要するに、「安マウスから一段だけ上に行きたい」用途で M-XGL10BBBK、「もう一段上で Excel / 横スクロールも視野」なら Logicool MX 系という棲み分け。Logicool MX MASTER 系の上位帯との比較はロジクール MX MASTER 2S レビューを参照。

よくある質問

Q. PC だけでなくスマホやタブレットでも使えますか？ A. Bluetooth 接続なので、Bluetooth マウスに対応した OS（Windows / macOS / iPadOS 13.4 以降 / 一部 Android）で使える。USB レシーバーがない分、対応の幅は接続側 OS の Bluetooth 対応次第。

Q. 専用ソフトでボタン割り当てはどこまでカスタムできますか？ A. メーカー提供の「エレコムマウスアシスタント」でサイドボタン等の割り当て変更ができる（Windows のみ、対応 OS は最新仕様を要確認）。Logicool Options 系ほどの細かさはなく、ジェスチャー方向別に複数アクション、のような設定は不可。シンプルな「戻る／進む／コピー／貼り付け」程度の用途なら十分。

Q. 手が小さくても疲れにくいですか？ A. S サイズを選べば疲れにくい。L サイズはむしろ手が小さい人だと指が届かず疲れやすいので、サイズ選びは要注意。可能なら店頭で握って決めるのが一番後悔がない。

Q. ゲーミング用途で使えますか？ A. 反応速度・センサ性能は事務用途想定のため、FPS や精密操作が必要なゲームには向かない。ブラウザゲームや MMO のような操作量が穏やかなゲームなら問題ない。

総評 — 「最初の一台目の格上げ」にちょうど良い

価格 × 握り心地の比率で見ると、低価格帯のなかでは抜けている一台。

特に「付属マウスや千円台のフラットマウスから乗り換えたい」「サイズが合うマウスを安く試したい」用途では、迷ったときの第一候補に置いていい。

注意点は Bluetooth ゆえの接続安定性とソフト周りの控えめさの2つ。Excel の横スクロールやカスタムジェスチャーを多用するなら、Logicool MX 系のほうが結果的に満足度が高い。

イラスト用 iPad の選び方 — 本気で描くなら iPad Pro、入門なら iPad Air が現実解

Sun, 11 Apr 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。骨子（モデル選びの観点）は今も有効だが、各モデルのスペック・価格・世代名は執筆当時のもの。Heavy リライト中 — 公開前に最新世代へ確認すること。

イラスト用にタブレットを買うとき、最初に詰まるのが「無印 iPad / iPad Air / iPad Pro のどれを選べばいいか」。値段は2倍以上、画面サイズも違う、Apple Pencil の世代も違う。

この記事は、iPad でイラストを描く前提に絞ってモデル選びをまとめる。読み終える頃には、自分が買うべき1台と、必要な周辺機器の輪郭が見えているはず。

結論 — 本気で描くなら 12.9 インチ iPad Pro、入門なら iPad Air

短い答え: 「液タブの代わりに長時間描く」なら 12.9 インチ iPad Pro。「趣味で描き始める」なら iPad Air が現実解。無印 iPad は安いが、Apple Pencil 第1世代しか対応していないモデルがあり、イラスト用途では一段落ちる。

ただし、どのモデルを選ぶ場合でも以下の3点は共通の判断軸になる:

画面サイズ: 11 インチ以上が目安。10 インチ前後は線を引くストロークが窮屈
Apple Pencil 対応世代: 第2世代対応モデルを選ぶ（マグネット充電・ダブルタップ）
容量: 256GB 以上。イラストの psd / clip ファイルは1枚で数百 MB に達することがある

逆に言うと、この3点を満たしていれば価格帯はそれほど神経質に選ばなくていい。

モデル選び — 3モデルの立ち位置を理解する

短い答え: 無印 iPad は「タブレットとして安い」、iPad Air は「描けて軽い」、iPad Pro は「液タブ代替」。価格ではなく用途で選ぶ。

理由は、iPad シリーズは同じ「iPad」でも処理性能・画面品質・Apple Pencil 対応が大きく違うから。イラスト用途では特に画面サイズと Pencil 対応が体験を分ける。

無印 iPad — 入門には十分、長時間の本気描きには物足りない

無印 iPad はもっとも安価なライン。電子書籍や動画視聴をメインに、ときどき落書きする程度なら十分。

ただし世代によっては Apple Pencil 第1世代にしか対応しておらず、Pencil 側の充電方法（Lightning 直挿し）が古い。「イラスト専用機」として買うなら次の Air 以上を勧める。

iPad Air — 描き始めるなら現実解

iPad Air は「描ける iPad の入り口」。Apple Pencil 第2世代対応、画面サイズも 10.9 インチ前後で実用範囲に入る。

無印 iPad より2〜3万円高いが、Pencil 込みでの体験差は大きい。趣味〜セミプロ用途まではここで足りる。

iPad Pro — 液タブ代わりに長時間描く人向け

iPad Pro は液タブ代わりに長時間描く人向けのライン。120Hz の高リフレッシュレート（ProMotion）に対応していて、ストロークの追従性が他モデルと体感で違う。

11 インチと 12.9 インチの2サイズがあり、本気で描くなら 12.9 インチを勧める。価格は無印 iPad の2倍以上になるが、画面の広さは「キャンバスを切り替えずに描ける」という点で生産性に直結する。

Apple Pencil は「第2世代対応モデル」を選ぶ

短い答え: イラスト用途では Apple Pencil 第2世代が必須要件に近い。第1世代対応モデルは避ける。

理由は、第2世代がマグネット式の側面充電・ダブルタップでのツール切り替え・遅延の少なさで体験が一段違うから。第1世代は本体下部の Lightning 端子に直接挿して充電する形で、運用がかなり煩雑。

確認ポイント:

候補のモデルが「Apple Pencil（第2世代）対応」と明記されているか
iPad 本体側面にマグネット吸着部があるか（商品写真で確認できる）

容量は 256GB から、Wi-Fi モデルで十分

短い答え: イラスト用なら 256GB 以上。Wi-Fi モデルで足りる人がほとんど。

理由は、psd / clip / procreate ファイルは1枚で数百 MB、シリーズ作品をまとめると数十 GB に到達するから。64GB / 128GB は OS とアプリで埋まる。

Cellular モデルは「外で常時ネット接続して描く」前提の人だけ。家とカフェの Wi-Fi で十分という人は、約 1〜2 万円の差額を Pencil やケースに回したほうが満足度が高い。

周辺機器 — 最低限そろえるもの

短い答え: Apple Pencil（第2世代）、保護フィルム、スタンド or キーボードカバーの3点。これだけで描く環境はだいたい揃う。

Apple Pencil（第2世代）: 必須。本体と別売り
ペーパーライク保護フィルム: 紙のような描き心地に近づける。ペン先の減りは早くなる
スタンド or キーボードカバー: 机に置いて描く角度を作る。長時間の作画姿勢が楽になる

液タブと違って外部モニターやドライバの設定はいらない。買ったその日から描き始められるのが iPad の強み。

比較: 無印 iPad / iPad Air / iPad Pro（イラスト用途）

以下は執筆当時（2021年）のラインナップ基準。2026 時点では後継モデルの最新スペックを必ず確認すること。

観点	無印 iPad	iPad Air	iPad Pro 12.9”
画面サイズ	約 10.2 インチ	約 10.9 インチ	12.9 インチ
Apple Pencil	第1世代	第2世代	第2世代
リフレッシュレート	60Hz	60Hz	120Hz（ProMotion）
メモリ目安	3〜4GB	4GB	6〜8GB
価格目安	約 4 万円〜	約 7 万円〜	約 12 万円〜
向いている用途	入門・落書き	趣味〜セミプロ	液タブ代替・本気描き

よくある質問

Q. iPad mini でもイラストは描けますか？ A. 描けないことはないが、画面が 7.9〜8.3 インチと小さく、長時間の作画には窮屈。電子書籍やゲーム用途と兼ねたいなら iPad mini、イラストを主目的にするなら Air 以上を勧める。詳しくは iPad mini の選び方を参照。

Q. 11 インチ iPad Pro と 12.9 インチ、どちらがいい？ A. 本気で描くなら 12.9 インチ。価格差は約 2 万円だが、画面の広さは「拡大縮小せずに描ける範囲」に直結する。携帯性を重視する人だけ 11 インチを検討する。

Q. iPad だけでイラストの仕事は完結しますか？ A. Procreate や Clip Studio Paint があれば、ラフ〜仕上げまで iPad で完結できる。ただし入稿用の細かい調整や複数モニターでの作業を考えると、長期的には PC との併用が現実的。

Q. メモリは何 GB あれば足りますか？ A. レイヤー数が増えるとメモリが効いてくる。Air の 4GB でも趣味用途なら回るが、商業レベルの大きいキャンバスを扱うなら iPad Pro の 6〜8GB を勧める。

まとめ

イラスト用 iPad は、本気で描くなら 12.9 インチ iPad Pro、入門〜趣味なら iPad Air。無印 iPad は安いが、イラスト専用機としては Pencil 対応の世代差で一段落ちる。

判断軸は「画面サイズ 11 インチ以上か」「Apple Pencil 第2世代対応か」「容量 256GB 以上か」の3点。価格より、この3点を優先したほうが買ったあとの後悔が少ない。

買ったその日から描き始められるのが iPad の強み。液タブと PC の組み合わせより導入がずっと軽い、というのは長く描き続ける上で地味に効いてくる。

Windows 用テンキーの選び方 — ノート PC 内蔵 / USB / Bluetooth、どれを選ぶか

Sat, 10 Apr 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。テンキーの基本構造は2021年から大きく変わっていないため骨子は今も使えるが、具体的な商品リンクは最新モデルへ差し替えること。

Excel で数字を打ち続けていると、フルキーボード上段の数字列に指を伸ばすコストが地味に効いてくる。経理・在庫管理・データ入力など、1日に何度も数字を入れる作業ならテンキー独立の方が早い。

この記事は、Windows で使うテンキーの選び方を「ノート PC 内蔵で足りるか」「外付けなら USB か Bluetooth か」の順で整理する。読み終える頃には、自分が買うべき1台の形が見えているはず。

結論 — 数字入力が多いなら USB 2.4GHz の外付けが第一候補

短い答え: ノート PC 内蔵テンキーで足りるかをまず確認する。足りないなら、Windows で使うテンキーは USB 2.4GHz の無線・薄型・電卓キー付き が基本構成。

理由は次の3点。

USB 2.4GHz は Bluetooth より遅延が出にくい — 専用レシーバー経由のため環境に左右されにくい
薄型（シザースイッチかパンタグラフ）はノート PC のキー高さと揃う — 並べて置いたときの段差が小さい
電卓キー付きは1日に何度も電卓を呼ぶ人に効く — 視線移動なしで起動できる

逆に、ノート PC で完結する作業しかしない人や、デスクが Windows / iPad で兼用の人は別の判断軸が要る。以下で順に見ていく。

ノート PC 内蔵テンキーで足りるか — 先にここを確認する

短い答え: 数字入力が1日に数十回までならノート PC 内蔵テンキーで足りる。毎日まとまった量を打つなら外付けに切り替えた方が手の負担が軽い。

理由は、テンキー付きノート PC は本体幅が広い分、ホームポジションが本体中央より左にずれる構造になっているから。長時間打つと右肩がやや前に出る姿勢になりやすい。

確認ポイント:

数字入力の頻度: 1日に何百回も打つなら外付け、たまになら内蔵で十分
本体サイズ: 15.6インチ以上の機種でないと内蔵テンキーは付かないことが多い（モデルによる）
キー配列: メーカーごとに NumLock や 00 キーの配置が違うため、慣れているメーカーがあればそのまま使える

内蔵で足りないと感じたら、外付けに切り替える。次節で接続方式の話に入る。

接続方式 — USB 2.4GHz、Bluetooth、有線

短い答え: PC で固定して使うなら USB 2.4GHz、スマホ・タブレットと併用したいなら Bluetooth、絶対に遅延ゼロが欲しいなら有線。

理由は、それぞれ得意な場面が違うから。

USB 2.4GHz（無線レシーバー式）

専用の USB レシーバーを PC に挿して使う方式。Bluetooth より遅延が出にくく、スリープ復帰直後の打鍵抜けも少ない。

USB ポートを1つ占有する代わりに、ペアリングの手間がない。Windows なら挿すだけで認識される。

デスクトップ・ノート PC でテンキーを固定運用するなら、まずこの方式を勧める。

Bluetooth

PC 内蔵 Bluetooth で接続する方式。レシーバーが要らないので、USB ポートを潰さない。

iPad やスマホとも同じ機材を使い回したい人には便利。ただし通信が混雑する環境では打鍵が一瞬抜けることがある。スリープ復帰直後にワンテンポ待たされる挙動もある（環境依存）。

USB 有線

ケーブルで PC に繋ぐ方式。遅延ゼロを保証できる。

代わりに机の取り回しが悪く、テンキーレスキーボードの右側に置くとケーブルが手の動線に絡みやすい。会計事務所のように1日中数字を打つ業務でなければ、無線で十分。

比較: USB 2.4GHz / Bluetooth / ノート PC 内蔵

3つを並べて整理する。価格・遅延の体感は購入当時の参考値（モデル・環境によって変動）。

観点	USB 2.4GHz	Bluetooth	ノート PC 内蔵
接続方式	USB レシーバー	PC 内蔵 Bluetooth	本体一体
遅延の懸念	低い	やや高め（環境依存）	なし
安定性	◯	△	◯
汎用性（他デバイス）	△（PC 向け）	◯（スマホ・タブレット可）	✕（本体専用）
USB ポート占有	1ポート	不要	不要
価格目安	2,000〜4,000円	3,000〜6,000円	本体価格に含む
携帯性	レシーバー込みで持ち運べる	単体で持ち運べる	ノート PC と一体
電卓キー有無	モデルによる	モデルによる	ない機種が多い

選び方の目安:

Windows デスクトップ／固定運用のノート PC → USB 2.4GHz
iPad・スマホとも併用したい / USB ポートが足りない → Bluetooth
ノート PC を買い替えるタイミング・数字入力が軽め → 内蔵テンキー付きモデルを検討

キー配列で外せない3点 — Tab、Backspace、電卓

テンキー本体のキー配列で、Excel 中心の作業者が外したくないキーは3つ。

Tab: Excel のセル横移動。Enter（下移動）と組み合わせると、テンキーだけで表入力が完結する
Backspace: 桁ミスの即時修正。数値入力では必ず使うので独立キーが欲しい
電卓: Windows の「電卓」アプリを1キーで起動。経費精算で効く

00（ゼロ2連打）キーは、金額入力が多い人にだけ刺さる。会計用途以外では優先度は下がる。

これらが入っているかは商品ページのキー配列写真で確認できる。スペック表記だけでは「Tab」「Backspace」の有無が分からないことがあるため、必ず画像でレイアウトを見る。

キータッチ — ノート PC と並べるならシザースイッチ

短い答え: ノート PC の隣に置くなら、キー高さの揃うシザースイッチかパンタグラフが扱いやすい。

メンブレン: 安価。キーストロークが深く、ノート PC と並べると段差で違和感が出やすい
パンタグラフ: ノート PC で広く採用されている薄型方式。コンパクトだが押し心地は製品差が大きい
シザースイッチ: パンタグラフの打鍵感を改善した方式。薄型でクリック感もある。長時間打鍵でも疲れにくい

数字入力に特化するなら、シザースイッチを第一候補にする。

具体的に何を買うか

USB 2.4GHz・シザースイッチ・電卓キーの3点を満たすモデルとして、別記事で Belis のワイヤレステンキーをレビューしている。実機の打鍵感・LED の主張具合・電池持ちまで踏み込んで書いたので、ここで挙げた条件に合うか具体的に確認したい人は併読してほしい。

関連記事: Belis ワイヤレステンキーレビュー — 電卓キー付き・USB 2.4GHz の薄型テンキー

よくある質問

Q. ノート PC のテンキー付きモデルを買えば外付けは要らない？ A. 数字入力が1日に数十回までならテンキー付きノート PC で足りる。本体が広くなる・ホームポジションが右にずれる・キー配列がメーカーごとに違うという欠点があるため、毎日まとまった量を打つなら外付けの方が手の負担が軽い。

Q. USB 2.4GHz と Bluetooth、どちらが安定する？ A. PC で固定して使うなら USB 2.4GHz の方が安定する。レシーバー経由の専用接続なので遅延が少なく、スリープ復帰直後でも待たされにくい。Bluetooth は環境ノイズや混雑で打鍵が一瞬抜けることがある。

Q. テンキーに電卓キーは付いていた方がいい？ A. 経費精算や在庫数の概算など電卓を頻繁に立ち上げる人なら、専用電卓キー付きを勧める。ショートカット割り当てに比べて視線移動が少なく、押した瞬間に電卓が出る動線が作れる。

Q. Mac でも同じテンキーを使える？ A. 数字キー部分は基本的に動くが、電卓キーや一部のファンクションキーは macOS で反応しないか別キーとして認識されることがある。Mac で使うなら商品ページで Mac 対応の明記を確認してから買う方が安全（製品・OS バージョンによる）。

まとめ

Windows で使うテンキーは、まずノート PC 内蔵で足りるかを確認する。足りなければ、PC 固定運用なら USB 2.4GHz、他デバイス併用なら Bluetooth、という分かれ方になる。

キー方式はシザースイッチかパンタグラフ。Tab・Backspace・電卓の3キーが入っているかは商品画像で確認しておく。

条件を絞れば、テンキー選びで大きく外すことは少ない。具体的なモデルで打鍵感まで知りたい場合は Belis ワイヤレステンキーレビューを併読すると、買う前のイメージが具体的になる。

Vue.js 入門 - エンジニアが解説する Component 基礎

Fri, 09 Apr 2021 00:00:00 GMT

2026-05-16 追記: 初出から数年経過した記事です。骨子は今も参考になりますが、ツールの UI やバージョンは執筆当時のままで、最新版とは差異があります。

Vue.js、JavaScript フレームワークを初めて使う方に向けて、今回はキモとなる Component について解説します。

Component の概念から説明していますので、初心者の方にも読みやすい内容です。

結論

Component は使いまわし可能なパーツで、メンテナンス性と再利用性を高める
親子間のデータ受け渡しは Binding で実現する
単方向バインディング (v-bind / v-on) と双方向バインディング (v-bind + v-on / sync) を使い分ける

Component とは？

Vue.js や Angular には Component という概念があります。

Component を使用して Vue.js などはコードの共通化を高めています。共通化を行うとメンテナンス性の向上やコード量の削減ができます。

どんなプロジェクトでも必ず Component は使用するので、Vue.js を理解するのには必須です。

使いまわし可能なパーツ

Component は簡単に説明すると使いまわし可能なパーツです。

vue ファイルの中で他の vue ファイルを呼び出して使用することができます。

例えばボタンを使いまわし可能な状態で実装すれば、呼び出すだけで同じデザイン、同じ処理を呼び出し側で実装できます。

例：ボタン

実現したいこと: 幅と高さが 20px の「ここをクリック」と表示されたボタンを使いまわしたい。

実装方法:

A ファイルで幅と高さが 20px の「ここをクリック」と表示されたボタンを作成。

B ファイルでボタン Component を呼び出す。

結果: B ファイルでボタンが表示される。

この呼ばれた側 (A ファイル)、呼び出し側 (B ファイル) は親と子で呼ぶことが多いです。

以下からは

呼び出し側 = 親
呼ばれた側 = 子

で説明していきます。

Binding とは？

上記の説明だと、ボタンの場合は次のような不満点があります。

ボタンのテキストが固定
クリック後の処理を子で書く必要がある

Binding はその不満点を解消する機能です。

Component 間のデータ受け渡し機能

Binding は簡単に説明すると Component 間のデータ受け渡し機能です。

Binding を行うと

親で子のテキストを変更可能にする
子でイベントトリガーを親に引き継ぐ

などができます。結果的に上記で起きていた不満点は、Binding を行うと解決します。

これらの Binding は親と子の関係性が重要で、

親から子、子から親の一方通行な Binding は一般的に単方向バインディング
親と子の双方向な Binding は一般的に双方向バインディング

と呼びます。

Binding の概念が理解できないと Component は上手く扱えないので頑張りましょう。

実際の使用例

ここからは実際に Vue.js のコードを見ながら実装方法を解説します。

vue ファイルの基本については以下の記事で解説していますので、わからない方は参考にしてください。

Vue.js 入門 - Vue の基礎

Component の使用

まずはベースとなる Component の呼び出しを解説します。

上記の例の Binding をしていないボタンの実装方法です。

子で string 文字列を表示する vue ファイルを作成し、親で子を読みます。

子: ChildComponent.vue

<template>
  string
</template>

子では処理不要なので、文字を書いているだけです。

親: ParentComponent.vue

<template>
  <ChildComponent />
</template>

<script>
import ChildComponent from "xxxx/ChildComponent.vue";

export default {
  components: { ChildComponent },
};
</script>

親では子の vue ファイル、ChildComponent.vue を使用するために ChildComponent.vue を import します。

そのうえで、html 側で実際に使用する箇所に <ChildComponent /> と記述すれば OK です。

v-bind (単方向バインディング: 親 → 子)

Component の呼び出し方法がわかったので、次に親 → 子の Binding を説明します。

親で子のテキストを変更可能にするイメージです。

以下のコードは親で設定したテキストを子で表示します。

子: ChildComponent.vue

<template>
  {{bindName}}
</template>

<script>
export default {
  props: ["bindName"],
};
</script>

子では親からのデータを受け取るため、props を用意します。

受け取るデータの名前は親と子で連携させる必要があります。今回は bindName と名付けます。

props は配列型なので、親から受け取るデータを複数持つこともできます。

親: ParentComponent.vue

<template>
  <ChildComponent :bindName="dataName" />
</template>

<script>
import ChildComponent from "xxxx/ChildComponent.vue";

export default {
  components: { ChildComponent },

  data() {
    return {
      dataName: 'string'
    };
  },
};
</script>

親では html 側で呼び出します。呼び出す時に :bindName="dataName" と属性が設定されています。

ここで親と子のデータをバインド、連携させています。

bindName は子の props で設定した名前
dataName は親で扱っているデータの名前

これで、親 → 子の Binding は完了です。

v-on (単方向バインディング: 子 → 親)

次に、子 → 親の Binding を説明します。

子で発生したイベントを親に検知、引き継ぐイメージです。

以下のコードは子のテキストをクリックすると親でイベントを検知して、親で表示されているテキスト内容が string → モジ に変更します。

子: ChildComponent.vue

<template>
  <div>
    <div @click="clickText()">
      クリックして変更
    </div>
  </div>
</template>

<script>
export default {

  methods: {
    clickText() {
      this.$emit('onName', 'モジ');
    }
  }
};
</script>

子ではクリックイベントを設定します。@click がクリックイベント設定です。

script 側では対象の Function 内で emit と記述しています。これが、子から親にイベントを検知させる方法です。

第一引数の onName は検知させたい名前
第二引数のモジは実際に送るデータ (オブジェクト型でも OK)

これで「クリックして変更」をクリックすると親の onName に伝播します。

親: ParentComponent.vue

<template>
  {{dataName}}
  <ChildComponent @onName="changeName"/>
</template>

<script>
import ChildComponent from "xxxx/ChildComponent.vue";

export default {
  components: { ChildComponent },

  data() {
    return {
      dataName: 'string'
    };
  },

  methods: {
    changeName(item) {
      this.dataName = item
    }
  }
};
</script>

親では基本的に v-bind と同様のことをしています。

他の追加処理はテキストの変更処理です。methods 内の changeName 引数に emit で設定した値が梱包されています。

これで、子 → 親の Binding は完了です。

応用編

今までは単方向バインディングのみだったので、双方向にデータを受け渡すことができません。

そこで以下からは、双方向バインディングの実装方法を解説します。

双方向バインディングが最も難しいので頑張りましょう。

v-bind と v-on (双方向バインディング)

Vue.js の双方向バインディングは大きく 2 種類の方法があります。

最初に最もベーシックな方法を解説します。

上記で解説した

v-bind (単方向バインディング: 親 → 子)
v-on (単方向バインディング: 子 → 親)

を組み合わせる方法です。

以下のコードの概要です。

親で子で表示する文字列を設定 (string)
子でクリックすると親にクリックイベントを送る (モジと書かれたデータを送信)
親で文字列が string → モジに変更
子の string がモジに変更

先程までは子、親の順に書きましたが、理解しやすさ優先でここからは親、子の順に書きます。

親: ParentComponent.vue

<template>
  <ChildComponent :bindName="dataName" @onName="changeName"/>
</template>

<script>
import ChildComponent from "xxxx/ChildComponent.vue";

export default {
  components: { ChildComponent },

  data() {
    return {
      dataName: 'string'
    };
  },

  methods: {
    changeName(item) {
      this.dataName = item
    }
  }
};
</script>

行っていることは v-bind と v-on をやっているだけです。親はそこそこシンプルです。

子: ChildComponent.vue

<template>
  <div>
    {{bindName}}
    <div @click="clickText()">
      クリックして変更
    </div>
  </div>
</template>

<script>
export default {
  props: ["bindName"],

  methods: {
    clickText() {
      this.$emit('onName', 'モジ');
    }
  }
};
</script>

子も同様に v-bind と v-on をやっているだけです。

分かりづらい場合は、上で書いた順序通りに処理を追うと理解しやすいです。

sync (双方向バインディング)

v-bind と v-on で双方向バインディングすると処理が少し複雑になります。

そこで、超応用の sync の登場です。

sync は簡単に説明すると v-bind を同期処理に変換します。

以下のコードでも先程と同じような処理を行っています。

親で子で表示する文字列を設定 (string)
子でクリックすると親にクリックイベントを送る (モジと書かれたデータを送信)
親で文字列が string → モジに変更
子の string がモジに変更

親: ParentComponent.vue

<template>
  <ChildComponent :bindName.sync="dataName" />
</template>

<script>
import ChildComponent from "xxxx/ChildComponent.vue";

export default {
  components: { ChildComponent },

  data() {
    return {
      dataName: 'string'
    };
  },
};
</script>

親の処理がスッキリしましたね。

ポイントは bindName.sync です。sync を書くことで v-on で行っていた代入処理を省略できます。

子: ChildComponent.vue

<template>
  <div>
    {{bindName}}
    <div @click="clickText()">
      クリックして変更
    </div>
  </div>
</template>

<script>
export default {
  props: ["bindName"],

  methods: {
    clickText() {
      this.$emit('update:bindName', 'モジ');
    }
  }
};
</script>

子も少し変化しています。emit の第一引数に update が追加されています。

update を書くことで、親の sync に通知がいく仕組みです。

v-on と sync の違い

紹介したとおり sync だと処理を省略して書けるので便利ですが、注意点もあります。

sync は同期処理なので、フィルター処理をはさみたい時などデータを加工したい時は使用できません。

双方向バインディングは以下の使い分けをおすすめします。

vue ファイル間でデータを加工するなら v-bind と v-on
vue ファイル間でデータを加工しないなら sync

まとめ

今回は Vue.js の Component と Binding を紹介しました。

とても重要な機能なので、何回も読み直してマネぶことをおすすめします。

関連記事:

ブログ用 MacBook の選び方 — Air で十分、Pro はクリエイター向け

Thu, 08 Apr 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。骨子（Air で十分 / Pro はクリエイター向け）は今も有効だが、具体的なモデル名・価格・スペックは執筆当時（2021 年）のもの。Apple Silicon 世代の刷新が続いているので、購入前に最新モデルを必ず確認すること。Heavy リライト済み — 公開前に商品リンクの差し替えを確認する。

ブログを始めようとして MacBook を見にいくと、Air・Pro・13 インチ・14 インチ・16 インチと選択肢が多くて手が止まる。値段差は10万円以上開くこともあって、いきなり Pro を選ぶのも怖い。

この記事は「ブログを書く」という用途に絞って、MacBook Air と Pro のどちらを選べばいいかをまとめる。結論から言うと、ほぼ全員 Air で足りる。

Windows ノートと比較したい人は併せてブログ用のノートパソコンの選び方を読むと、OS をまたいだ判断軸が見える。

結論 — ブログ用なら MacBook Air、Pro はクリエイター兼用のときだけ

短い答え: ブログ執筆だけが目的なら MacBook Air の一番安いモデルで十分。Pro との差額（おおむね5〜10万円）を払うのは、動画編集・写真現像・プログラミングを兼用するときだけでいい。

理由はシンプルで、WordPress 執筆はブラウザ上で完結するから。ブラウザがストレスなく動けばよく、Air の Apple Silicon は当時のエントリーノートとしては余裕がある性能だった。

判断軸は2つだけ:

MacBook で何をするか — ブログ「だけ」なら Air、動画・写真・開発も兼ねるなら Pro
持ち運ぶか — Air は軽い、Pro 16 インチは2kg を超える

逆に言うと、この2点を整理すれば迷う余地はあまり残らない。

MacBook 選びで見るべき3つのポイント

短い答え: ブログ用なら「メモリ」「重量」「画面サイズ」だけ見ればいい。CPU の世代やコア数は気にしなくていい。

理由は、ライティング作業の負荷が CPU よりメモリ側に効きやすいから。ブラウザのタブを何十枚も開きながら書く人は CPU よりメモリで詰まる。

メモリは 8GB が下限、16GB なら長く戦える

メモリは PC が「一度に作業できる量」を決める。ブラウザのタブを増やすほど消費が増えるので、ブログ執筆中に資料タブを30枚開きっぱなしにする人はここで詰まる。

8GB: WordPress 編集画面 + 資料タブ10枚程度なら問題なし
16GB: 4〜5年使うなら推奨。タブ運用がラフでも詰まらない

Apple Silicon の MacBook はメモリを後から増設できない。買うときに決め切る必要がある。

重量 — 家中心なら無視、持ち運ぶなら 1.3kg 以下

家でしか書かないなら重量は気にしなくていい。

外で書くなら、MacBook Air が現実的な選択肢になる。Pro は 14 インチでも 1.5kg、16 インチで 2kg を超える。毎日カバンに入れるとこの差は腰にくる。

画面サイズ — 13 インチで足りる、家用なら外部モニターを足す

ブログ執筆は文字中心なので、13 インチでも作業はできる。

家で長時間書くなら、ノート本体のサイズより外部モニターを足す方が体感差が大きい。資料を片方の画面に置きっぱなしにできるので、タブの切り替え操作が消える。

モデル別おすすめ

短い答え: ブログ「だけ」なら MacBook Air 13 インチ。動画編集や開発も兼用するなら MacBook Pro 14 インチ。Pro 16 インチはブロガー向けではない。

MacBook Air 13 インチ — ブロガーのデフォルト

ブログ執筆だけが目的ならこれ一択。執筆当時（2021 年）の M1 MacBook Air は税込 115,280 円から、メモリ 8GB / SSD 256GB の構成で発売されていた。

メモリだけ 16GB にカスタマイズすると2万円前後上乗せになるが、4〜5年使う想定ならここはケチらない方がいい。

MacBook Pro 14 インチ — 兼用するなら

以下のどれかに当てはまるなら Pro 14 インチを検討してもいい。

動画編集（4K 書き出しを日常的にやる）
写真の RAW 現像
iOS / macOS アプリ開発、機械学習
外部モニター2枚以上を常時つなぐ

逆に言えば、ブログだけならこの性能はオーバースペック。価格差は外部モニターやデスク環境に回した方がリターンが大きい。

MacBook Pro 16 インチ — ブロガー向けではない

重量2kg 超 / 価格30万円超のラインで、ブログ用途では明確に過剰。デスクトップ代替として据え置き運用する人向けで、ブロガー1台目の選択肢には入らない。

比較: MacBook Air vs Pro（ブログ用途で見たとき）

観点	MacBook Air 13”	MacBook Pro 14”	MacBook Pro 16”
メモリ（標準）	8GB	16GB	16GB
重量	約 1.29kg	約 1.55kg	約 2.1kg
バッテリー駆動	最大 15〜18h	最大 17h	最大 21h
価格（2021 時点）	11.5万円〜	23万円〜	30万円〜
ブログ用途の余裕度	十分	過剰	完全に過剰
兼用向き	軽作業のみ	動画・写真・開発	重い動画編集

ブログだけで使う前提なら、Air と Pro 14 インチの差額（10万円超）は外部モニターや椅子に回した方が執筆体験は確実に上がる。

よくある質問

Q. MacBook Air のメモリは 8GB と 16GB どちらを選ぶべき？ A. 4〜5年使う予定なら 16GB。Apple Silicon は後から増設できないので、ここは将来の自分への保険と考える。2〜3年で買い替える前提なら 8GB でも問題ない。

Q. Mac か Windows か、ブログ執筆だけならどちらがいい？ A. ブログ執筆の作業効率は OS で変わらない。普段使っている OS に合わせるのが摩擦が少ない。Windows 機との比較はブログ用のノートパソコンの選び方にまとめてある。

Q. iPad Pro + Magic Keyboard でブログは書けますか？ A. 短文ならいけるが、WordPress の管理画面・プラグイン設定・画像の一括処理はノート PC の方がはっきり速い（と言うか、iPad はブラウザ拡張が貧弱なところで詰まりやすい）。長期的にはノート PC を勧める。

Q. 中古の MacBook を買うのはアリですか？ A. アリ。ただし Apple Silicon 世代（M1 以降）に限る。Intel 世代は OS サポート期間が短くなる可能性が高いので、安くても避けたほうが無難。

まとめ

ブログ用 MacBook 選びは、Pro か Air かで悩む前に「MacBook で何をするか」を整理すれば9割決まる。

執筆だけなら Air 13 インチで十分。Pro が要るのは動画編集・写真現像・開発を兼用するときだけ。価格差を外部モニターやデスク環境に回す方が、最終的な執筆体験は確実に上がる。

Windows ノートと迷っているなら、姉妹記事のブログ用のノートパソコンの選び方も併せて読むと判断材料が揃う。

Logicool MX Master 2S vs 3 比較レビュー — どっちを買うべきか

Wed, 07 Apr 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。MX Master 2S は現行ラインからは外れ、2026 年時点の後継は MX Master 3S。とはいえ 2S と 3 の差分は、3S を選ぶ判断にもそのまま流用できる。スクリーンショットは執筆当時のまま。

仕事用にいいマウスが欲しい。候補に Logicool が挙がる。問題は MX Master 2S と MX Master 3 のどちらを選ぶか、というところで止まる。

実機を半年以上ずつ使ったうえで、両者の差分を整理する。

結論 — 迷ったら MX Master 3

短い答え: 新規購入なら MX Master 3（または現行の 3S）を選ぶ。

理由は次の3点に集約される。

サムホイール（サイドホイール）が大きく、横スクロールが指1本で完結する
給電が USB Type-C に変わり、他デバイスとケーブルを共用できる
メインホイールがスクロール量を検知して感度を自動で切り替える

ただし「手のひらをべったり置く持ち方が好き」「手が大きい」人は MX Master 2S が合う可能性がある。詳しくは MX Master 2S 単体のレビューと MX Master 3 単体のレビューも参考にしてほしい。

比較表 — スペックと操作感

短い答え: 形状・サムホイール・給電の3点が主な差分。価格差はおよそ 3,000〜4,000 円。

観点	MX Master 2S	MX Master 3
形状	平べったく曲線的	縦に長く直角的
推奨される持ち方	手のひらを置く	親指と小指で挟む
サムホイール	小さい	大きい
サブボタン配置	上下	左右（前後）
メインホイール	機械式（手動切替）	MagSpeed（自動切替）
給電	microUSB Type-B	USB Type-C
バッテリー公称	約 70 日	約 70 日
価格帯（執筆当時）	約 9,400 円	約 13,000 円〜

スペックだけ見ると 3 が全方位で上だが、形状の好みは別軸の問題なので、表だけで判断しない方がいい。

形状と持ちやすさ

短い答え: 2S は平べった、3 は縦に高い。持ち方そのものが変わる。

2S は左側面が丸く、手のひらを置くように使う。手の重さでマウスを押さえる感覚に近い。

3 は左側面が直線的で、背が高い。親指と小指でくびれをつまみ、持ち上げるように動かす形になる。

後ろから見ると 3 のほうが明確に高い。これが「掴む持ち方」の根拠になる。

左側面の角度が違うので、サムホイールへの親指の届き方も変わる。3 のほうがホイールを「腹で押す」感覚で操作できる。

サムホイール — 横スクロールの主役

短い答え: 3 のサムホイールは明確に使いやすい。Excel やコードを横に長く扱う人には差が出る。

サムホイールは主に水平スクロールに使う。Excel の右方向の移動、コードの長い行の確認、動画編集のタイムライン送り、Figma の横方向パン。どれもキーボード補助なしで指1本で済む。

2S のサムホイールは小さく、親指の腹だと「探す」動作が要る。3 は大きく、自然に親指が乗る位置にある。

メインホイール（縦）とサムホイール（横）で XY 2軸を同時に動かせるのは、両者に共通する強みではある。

サブボタンの位置

短い答え: 2S は上下、3 は前後（左右）。前後のほうが直感的。

2S のサイドボタンは「上下」配置で、これは Logicool 内でも珍しい。慣れると押し分けが速いが、戻る・進むに割り当てると誤爆が出やすい。

3 は前後（左右）配置で、一般的なマウスと同じ感覚で使える。他のマウスと併用していても混乱しない。

メインホイールと給電

短い答え: 3 のメインホイールは自動切替。給電は Type-C で、ケーブル共用が楽。

メインホイールは両者とも「ノッチあり（ギアが噛むような感触）」と「フリースピン（無段階）」の2モードを持つ。2S はホイール上のボタンで手動切替。3 は MagSpeed と呼ばれる電磁機構で、スクロール量に応じて自動で切り替わる。

短い距離は丁寧に、長い距離は一気に。これがスイッチを意識せずに切り替わるのは、思った以上に効く。

給電は 2S が microUSB Type-B、3 が USB Type-C。2026 年の周辺機器は Type-C が前提なので、ケーブルを1本に統一できる 3 のほうがケーブル管理上は楽。充電頻度は 2〜3 ヶ月に1回なので、致命的な差ではない。

使い分け — タイプ別の選び方

短い答え: 用途と手のサイズで選ぶ。Excel 多用なら 3、家用の据え置きなら好み次第。

家用・据え置きで Excel やコードを書く

おすすめ: MX Master 3

サムホイールが大きいので、横スクロールが頻発する作業との相性がいい。メインホイールの自動切替も、長いシートを上下する人ほど効果が出る。Type-C も机周りの統一には地味に効く。

手のひらをべったり置きたい / 手が大きい

おすすめ: MX Master 2S

3 は「掴む持ち方」前提なので、手のひらを置く持ち方が好みの人にはやや窮屈に感じることがある。手が大きく、平べったいマウスに慣れているなら 2S の形状が手に馴染む。

持ち運び中心 / 鞄に入れて移動する

どちらも非推奨

MX Master シリーズは据え置き向けの大型マウス。持ち運ぶなら MX Anywhere 3 系の小型モデルのほうが鞄を選ばない。

ゲーム中心

どちらも非推奨

反応速度は普通のマウス相当。FPS や精密操作が必要なゲームには専用ゲーミングマウスを勧める。2S は過去にジェスチャーボタンの強度問題が出た事例もあり（2S 単体レビュー参照）、激しい操作とは相性が悪い。

よくある質問

Q. 手が小さくても MX Master 3 は使えますか？ A. 3 は「掴む持ち方」が基本なので、手のひらの大きさより指の長さが効く。指でつまめれば操作はできる。気になるなら店頭で握ってから決めるのが一番確実。

Q. Mac でも使えますか？ A. 両方とも使える。Logi Options+（旧 Logicool Options）が Mac 版も提供されている。Bluetooth または専用 USB レシーバーのどちらでも接続できる。

Q. iPad で使えますか？ A. iPadOS 13.4 以降ならマウス対応で、Bluetooth ペアリングで動作する。サムホイールやジェスチャーは一部の機能が iPad 側でサポートされていない可能性があるので、用途次第。

Q. 2026 年に買うなら 3S を選んだほうがいいですか？ A. 新規購入なら 3S を勧める。3 の改良版で、センサー解像度とクリック音が改善されている。本記事の「3」の評価は 3S にもおおむね当てはまると考えてよい。

まとめ

MX Master 2S と MX Master 3 はシリーズ名こそ同じだが、形状から操作感まで別物に近い。

新規購入なら MX Master 3（または現行の 3S）が無難。手のひらを置く持ち方が好きで、サイズに不満がなければ 2S も選択肢に残る。

個別の使い込みレビューは MX Master 2S レビューと MX Master 3 レビューにまとめてあるので、判断材料が足りないと感じたら併せて読んでほしい。

iPad mini の選び方 — 片手で持てる 8.3 インチが効くのは読書・ゲーム・現場メモの3用途

Mon, 05 Apr 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事（初出 2021 年、iPad mini 6 発売前の世代を前提に書かれていた）。2026 年現在の現行モデルは mini 7（A17 Pro、2024 年 10 月発売）。骨子は今も使えるが、価格・仕様は Apple 公式の最新値で確認すること。

iPad mini は「小さい iPad」と片づけられがちで、無印 iPad との違いがわかりにくい。値段だけ見ると mini のほうが高く、画面は無印より小さい。それなのに mini を選ぶ理由はどこにあるのか。

この記事は、iPad mini が効く用途を3つに絞り、無印 iPad / iPad Air と並べてどれを選ぶべきかを整理する。

結論 — 片手で長時間持つ用途があるなら mini、なければ無印 iPad

短い答え: iPad mini は「片手で持ったまま使い続ける」場面で価値が出る。具体的には電子書籍・ゲーム・現場メモの3用途。それ以外なら無印 iPad のほうが画面が広く、価格も安い。

理由は、mini の差別化要素が 8.3 インチというサイズそのものにあるから。CPU や画面品質で勝つわけではなく、片手で持てる重量とフォームファクタが本体価値。机に置いて使うなら、その価値は消える。

判断基準を3点にまとめる:

持ち方: 片手で持つ時間が長いか — Yes なら mini、No なら無印 iPad
容量: 写真・動画を端末本体に貯めるか — 貯めないなら最小構成で足りる
接続: 外で単独でネットに繋ぐ必要があるか — Wi-Fi で足りるか、テザリングで足りるか

用途別判断 — mini が効くのは3つだけ

短い答え: 電子書籍・ゲーム・現場メモ。この3つに当てはまらないなら、mini を選ぶ理由は弱い。

理由は、それ以外の用途（動画視聴、ノート、イラスト、書類確認）では画面の広さが効くから。同じ価格帯なら無印 iPad のほうが体験が良い。

電子書籍を読む

8.3 インチは文庫本〜単行本の中間サイズ。マンガの完全版より一回り小さい。

片手で 30 分以上持っていても腕が疲れにくいのが大きい。重量は mini 7 で 293g（Wi-Fi モデル、公称）。無印 iPad（約 477g）と比べると、長時間読書での腕の負担が体感で違う。

ゲームをする

タップ移動距離が短くて済むのが mini の隠れた利点。

大画面タブレットでアクション系ゲームをやると、両手の親指が画面端まで届かず、持ち替えが発生する。mini なら端から端まで親指圏内に収まる。

現場でメモを取る・資料を出す

立ち話で資料を相手に見せる、片手で持ったまま書き込む、ジャケットの内ポケットに入れて持ち歩く — こうした使い方は mini の独壇場。

無印 iPad だと両手で持つ前提になり、ポケットに入らない。

スペック — 現行 mini 7 と旧 mini 6 の違い

短い答え: mini 7（2024）は A17 Pro、Apple Intelligence 対応。mini 6（2021）は A15 Bionic。日常用途では体感差は小さいが、長く使うなら 7。

項目	mini 7（2024）	mini 6（2021）
チップ	A17 Pro	A15 Bionic
Apple Intelligence	対応	非対応
ストレージ	128 / 256 / 512GB	64 / 256GB
Pencil	Apple Pencil Pro / USB-C	Apple Pencil 2 / USB-C
重量（Wi-Fi）	293g	293g
発売	2024 年 10 月	2021 年 9 月

（数値は Apple 公式の iPad mini 仕様ページ準拠）

mini 6 の中古や整備済品が安く出ていれば、読書・ブラウジング中心の用途なら十分使える。ただし最小ストレージが 64GB しかなく、現代のアプリ事情では手狭。長期運用を考えるなら mini 7 の 128GB がスタート地点。

比較 — iPad mini vs 無印 iPad vs iPad Air

短い答え: 携帯性なら mini、コスパなら無印 iPad、作業用なら Air。

観点	iPad mini 7	無印 iPad（A16）	iPad Air（M3）
画面サイズ	8.3 インチ	11 インチ	11 / 13 インチ
重量（Wi-Fi）	293g	477g	460〜617g
携帯性	抜群（片手）	普通（両手）	普通〜やや重い
作業用途	厳しい	こなせる	快適
Pencil	Pro / USB-C	USB-C	Pro / USB-C
価格帯（参考）	中	低	高

（価格・スペックは Apple 公式サイトで確認）

携帯性・読書・ゲーム → mini
コスパ重視・家中心 → 無印 iPad
メモ取り・イラスト・サブ機として作業もする → Air

イラスト用途で iPad を検討している場合は、画面サイズと筆圧表現の話が別軸で必要になる。詳細はイラスト用 iPad の選び方を参照。

容量と Cellular の選び方

短い答え: 写真と動画を端末本体に貯めない運用なら 128GB / Wi-Fi で足りる。判断基準は単純なので、悩む時間を短くする。

容量 — 128GB か、それ以上か

iPad mini 7 の容量は 128 / 256 / 512GB。価格差は世代やキャンペーンで変動する。

写真・動画を iCloud / クラウドに逃がす運用 → 128GB
動画素材や大型ゲームを複数持ち歩く → 256GB 以上
動画を長期保存したい → そもそも iPad より外付け SSD のほうが向いている

Wi-Fi か Cellular か

Cellular モデルは本体価格が上がり、別途回線契約も必要。

家・職場の Wi-Fi で完結 → Wi-Fi モデル
外で頻繁に単独利用、スマホのテザリングが面倒 → Cellular / eSIM
判断がつかない → Wi-Fi モデル + テザリングで運用してみる。後から不便を感じたら次回機で Cellular にする

よくある質問

Q. iPad mini と無印 iPad、どちらを買うべきですか？ A. 片手で持ったまま長時間使うなら mini、机に置いて作業するなら無印 iPad。携帯性に明確な用途（読書・ゲーム・現場メモ）がないなら、画面が広く価格も安い無印 iPad のほうがコスパが良い。

Q. mini 6（2021）と mini 7（2024）、まだ売っている旧型を買っても大丈夫ですか？ A. 読書とブラウジング中心なら mini 6 でも実用上の差は小さい。ただし mini 7 は Apple Intelligence 対応・A17 Pro 搭載で長く使える前提なら 7 を勧める。

Q. 容量は 128GB と 256GB / 512GB どちらが安全ですか？ A. 写真と動画を端末本体に貯めないなら 128GB で困らない。iCloud 写真や Google フォトに逃がす運用なら最小構成で十分。動画素材を持ち歩くなら 256GB 以上。

Q. Cellular モデルは必要ですか？ A. 家とオフィスの Wi-Fi だけで使うなら不要。外で地図・原稿・資料を即出せる必要があるなら Cellular か eSIM。スマホのテザリングで足りるかを先に試してから決めると無駄が少ない。

まとめ

iPad mini を選ぶ理由は、性能でも画面でもなく「片手で持てるサイズ」そのもの。

電子書籍・ゲーム・現場メモの3用途のどれかに当てはまるなら mini 7 の 128GB Wi-Fi が起点。当てはまらないなら、無印 iPad のほうが画面の広さと価格で勝る。

iPad シリーズ全体での選び分けは、用途を「片手で持つか」「机に置くか」「絵を描くか」の3軸に分解すると迷いが減る。イラスト前提で買うなら別記事のイラスト用 iPad の選び方も合わせて確認したい。

ロジクール MX MASTER 3 レビュー — 2S からの正統進化、Type-C 給電と MagSpeed ホイール

Sat, 03 Apr 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植・改稿した記事。MX MASTER 3 自体も 2026 時点では旧モデルで、現行は MX Master 3S（センサー解像度とクリック静音性が改善）。給電端子・MagSpeed ホイール・サムホイールといった本記事の評価軸は 3S にも引き継がれているので、3 / 3S どちらを検討する人にも読める内容にしてある。本文中のスクリーンショットは執筆当時の Logicool Options のもの（現在は Logi Options+ に世代交代）。

ロジクール MX MASTER 3 を仕事とプライベートで1年以上使った視点でレビューする。

前モデルの MX MASTER 2S のレビューを別記事に書いた。今回はその姉妹記事として、2S から何が変わったか・変わらなかったかを軸に書く。新規購入で 3 / 2S / 3S のどれにすべきか迷っている人にも判断材料になるはず。

結論 — 2S を持っていないなら 3 (or 3S) でいい

短い答え: 給電端子が USB Type-C になっただけでも 2S からの乗り換え価値はある。さらに MagSpeed ホイールとサムホイールの形状変更が加わり、Excel / コード編集 / Figma で「縦横を同時に動かす」体験が一段滑らかになっている。

2S からの主な差分は以下の3点。

給電端子が microUSB → USB Type-C
メインホイールが 機械式 → MagSpeed（電磁式） で、回転量に応じて自動で段階/無段階が切り替わる
サムホイール（横スクロール）の形状が大きくなり、親指で回しやすくなった

逆に変わらなかったのは、サイズ展開（フルサイズのみ）と独特のフォルム。手の小さい人にとっては相変わらず大きく、ここは 3S になっても同じ。

外観と質感

短い答え: 2S と並べると見分けがつく程度には角が立った造形。前方に USB Type-C 端子、左側面に大型サムホイール。

左クリックにロジクールのロゴ。メインホイールの直上にスクロールモード（段階 / 無段階）固定切り替えボタン、親指側にジェスチャーボタン。

接続は Bluetooth と Unifying 後継の USB レシーバーの2系統。レシーバーは付属する（MX MASTER 3 の初期出荷分は同梱、3S では別売の構成もある）。

裏側に電源スイッチとデバイス切替ボタン（最大3台ペアリング）。センサーは公称 1000dpi（3S では 8000dpi に引き上げ）。

前方に給電用 USB Type-C。2S の microUSB Type-B からの最大の変更点で、机の上で Type-C 1本に統一できるのが地味に効く。

後ろから見るとボディ中央にくびれがある。親指と小指でくびれを挟む持ち方になる点は 2S と同じ。

左側面に進む/戻るのサイドボタン2つと、横スクロール用のサムホイール。サムホイールはメインホイールと同等サイズまで大きくなり、2S の細いホイールよりも回しやすい。電源を入れると緑のインジケーターが短く光る。

右側はボタン類なしのシンプル面。

良かった点

短い答え: MagSpeed ホイールの「勝手に切り替わる」感覚と、太くなったサムホイール。Type-C 給電。

MagSpeed ホイール — 段階と無段階が自動で切り替わる

MX MASTER 3 を象徴する機能。少しずつ回せばラチェット（カチカチ）感のある段階スクロール、勢いよく回すと無段階のフリースピン状態になり、一気にページの底まで飛ぶ。

切り替えは回転速度に応じて自動。固定したいときはメインホイール上のボタンで段階 / 無段階を明示的に切り替えられる。

実用面で効くのは、コードや長い記事を上下に走り回る場面。2S では「Shift 押しっぱなしで上ボタン押す」「フリースピン用に別マウスを使う」みたいな迂回をしていたが、3 では1つのホイールでまかなえる。

サムホイールが太くなって回しやすい

機能としては 2S と同じ「横スクロール専用ホイール」だが、形状が大きくなり親指の腹で安定して回せる。

Excel の横方向移動、Figma のキャンバスパン、動画タイムラインのスクロール — このあたりは 2S 時点で既に快適だったが、3 ではさらに少ない指の動きで済む。メインホイールとサムホイールを同時に動かせば縦横2軸同時操作になるのは、慣れると戻れない。

充電が USB Type-C

2S 最大の欠点だった microUSB Type-B から Type-C に。充電頻度は2〜3ヶ月に1回程度なので大した違いではない、と書きかけて消した。ケーブルが机の上で1本に統一できることの効用は、想像以上に大きい。

バッテリー持ち

公称 70日。実使用では2〜3ヶ月に1回の充電で支障なし。フル充電後の使用感は 2S と体感差なし。

微妙だった点

短い答え: サイズはフルサイズのみ、価格は据え置きで高め、ジェスチャーボタンの強度は 2S から「劇的に改善」ではなく「やや改善」程度。

サイズ展開がない

3 もフルサイズの1サイズ展開。手の小さい人にはやはり大きい。

コンパクトを優先するなら同じロジクールの MX Anywhere 3 が選択肢になる。ただし Anywhere 3 にはサムホイールがない（メインホイールは MagSpeed）ので、本記事の「横スクロール快適」の話は当てはまらない。

価格は据え置きで高い

執筆当時で約 13,000円前後。2S からの差分（Type-C・MagSpeed・サムホイール改良）に見合うかは、横スクロールをどれだけ使うかで決まる。

Excel / Figma / 動画編集を毎日触る人なら回収は早い。ブラウジング中心の用途では 2S の中古や、後述の 3S を待ったほうが満足度が高いことが多い。

ジェスチャーボタンの強度

2S のレビューで書いた「ゲーム中に強く押したら戻らなくなった」問題。3 でも構造自体は引き継がれており、激しく操作するゲーミング用途では同じリスクがある（執筆者の個体では再現せず）。

ゲーミング用途には素直に専用マウスを推奨する。

比較: MX MASTER 2S vs 3 vs 3S

3兄弟を表で並べる。

観点	MX MASTER 2S	MX MASTER 3	MX Master 3S
給電	microUSB Type-B	USB Type-C	USB Type-C
メインホイール	機械式（段階）	MagSpeed（電磁式・自動切替）	MagSpeed（電磁式・自動切替）
サムホイール	あり（細い）	あり（大型化）	あり（大型化、3 と同等）
センサー解像度	公称 4000dpi	公称 1000dpi	公称 8000dpi
クリック静音性	通常	通常	静音クリック
バッテリー公称	70日	70日	70日
サイズ展開	フルサイズのみ	フルサイズのみ	フルサイズのみ
設定ソフト	Logicool Options	Logicool Options / Options+	Logi Options+
発売年	2017	2019	2022

新規購入なら 3S を勧める。型落ち狙いで実勢価格に差があるなら 3 も依然合理的な選択。2S は中古以外では入手が難しく、Type-C を求めるなら避けるのが無難。

ソフト（Logicool Options / Logi Options+）

専用ソフトで各ボタンの挙動とホイール感度をカスタマイズできる。執筆時点では Logicool Options だったが、2026 年現在は Logi Options+ に世代交代している。

マウス画面で各ボタンのアクションを変更。サムホイールには水平スクロールのほか、「次へ/前へ」「音量」「タブ切替」などを割り当てられる。

ジェスチャーボタンには上下左右4方向にアクションを割り当てられる。執筆者は使用頻度が低いので Enter にしている。

ポインタ速度・サムホイールの感度・スクロール方向を細かく調整可能。Excel 用にスクロール量を控えめにする、といったアプリ別チューニングも効く。

よくある質問

Q. Mac でも使えますか？ A. 使える。Logi Options+ の Mac 版が提供されている。Bluetooth・USB レシーバーどちらでも接続でき、macOS のジェスチャー（Mission Control など）も割り当てられる。

Q. MX MASTER 2S と比べて買い替える価値はありますか？ A. 給電が USB Type-C になった点と、MagSpeed ホイールでフリースピンが効くようになった点が大きい。横スクロールを多用するなら買い替え推奨。逆にブラウジング中心で 2S の充電端子も気にならないなら、急ぐ理由は薄い。

Q. MX Master 3S が出た今、3 を買う意味はありますか？ A. 実勢価格に明確な差があるなら 3 は依然合理的。3S の主な改善点はセンサー解像度（公称 1000→8000dpi）とクリック静音化で、横スクロールやサムホイールの体験は 3 と同等。静かなオフィスや夜間作業を重視するなら 3S を、価格差を重視するなら 3 を選ぶ。

Q. ジェスチャー機能はどのくらい使い物になりますか？ A. 親指のジェスチャーボタンを押し込みながら上下左右にマウスを振ると、それぞれにアクションを割り当てられる。Mission Control / 仮想デスクトップ切替などには便利だが、押し込みの感触が独特で、慣れに数日かかる。執筆者は最終的に頻度が下がり、単押し（Enter）に落ち着いた。

総評 — 横スクロールを毎日使う人なら回収できる投資

短い答え: 2S の弱点だった Type-C 給電を埋め、メインホイールの体験を一段引き上げた正統進化モデル。新規購入なら 3S を、価格差で迷うなら 3 を選んで損はない。

Excel・Figma・コードエディタを毎日触り、画面を縦横に動き回るタイプの人にとっては、価格分の時間は数ヶ月で回収できる。逆に、ブラウジング中心・手が小さい・静音性を最優先 — このどれかに当てはまるなら、3S や Anywhere 3 を含めて選び直したほうがいい。

姉妹レビューとして MX MASTER 2S のレビューも合わせてどうぞ。

Vue.js 入門 - 現場で使用したエンジニアが解説する Vue の基礎

Fri, 02 Apr 2021 00:00:00 GMT

2026-05-16 追記: 初出から数年経過した記事です。本文は Vue 2 / Options API（data() { return ... } + methods: {} を並べる書き方）を前提にしています。2026 年現在の主流は Vue 3 + Composition API（<script setup> と ref / reactive / computed）で、ライフサイクルも onMounted / onUnmounted といった関数で書きます。骨子としての 3 ブロック構造（template / script / style）と「created と mounted の使い分け」の考え方は今も通じますが、コードは新規プロジェクトでそのまま使うものではありません。

Vue.js を使用して 1 年以上経過したので、経験も踏まえながら Vue.js の超基礎を解説します。

結論

Vue ファイルは HTML / JavaScript / CSS の 3 言語が 1 ファイルに同居
template / script / style の 3 ブロック構造を押さえれば書ける
script ブロックは data・methods・ライフサイクルの役割を理解するのが第一歩
ライフサイクルは主に created と mounted の使い分けを覚える

Vue ファイルの構造

まずは Vue ファイルの構造を理解するところから始めます。Vue ファイルは 3 つの言語が全て入っています。

HTML
JavaScript
CSS

具体的には以下の通りです。

<template>
  <div>
    html記述
  </div>
</template>

<script>
  export default {
    name: "XXX",
    data() {
      return {
        xxx: yyy
      }
    }
  }
</script>

<style lang="css">

</style>

各言語ごとに分離可能ですが、今回は省略します。
script と style は他の言語に変更可能です。

筆者は主に script は TypeScript、style は SCSS か Stylus を採用しています。

template

template に HTML を記述する箇所です。

基本的に普通の HTML と同じ記法ですが、Vue 独自の記述があります。

Vue 独自の記述については別途記事で解説します。

script

JavaScript 系を記述する箇所です。ここでは script に data と methods を書くのが入口になります。

今回は JavaScript を例に解説します。

以下が基本の記述です。

export default {
  data() {
    return {
      xxx: "yyy"
    }
  },

  methods: {
    hogeMethod(str) {
      return str
    },
    hugaMethod() {
      let test = this.xxx;
      test = this.hogeMethod(test);
      return test;
    }
  }
}

data は Vue ファイル内で利用可能な変数を宣言・初期化することができます。
HTML に加工データを表示したい時などに頻繁に使用します。

※オブジェクト型で return しているので注意です。

methods は一般的な関数です。

同ファイル内の変数・関数を呼び出す際は this. を先頭に付けてください。
同関数内のローカル変数には this. は不要です。

以下の箇所が該当します。

hugaMethod() {
  let test = this.xxx;
  test = this.hogeMethod(test);
  return test;
}

ライフサイクル

ライフサイクルは今回の記事で最も理解しにくい箇所です。ライフサイクルでタイミングを制御する、という観点で読んでください。
公式では以下のページで確認できます。

Vue.js 公式: ライフサイクルダイアグラム

Vue ファイルが読み込まれてから破棄されるまでのタイミングを 8 つで区切り、JavaScript 内でタイミングごとに処理をコントロールできます。

タイミングは以下の通りです。

beforeCreate - インスタンス前
created - インスタンス後
beforeMount - マウント前
mounted - マウント後
beforeUpdate - 更新前
updated - 更新後
beforeDestroy - 破棄前
destroyed - 破棄後

対応する記述は以下の通りです。

export default {
  data() {},
  beforeCreate() {},
  created() {},
  beforeMount() {},
  mounted() {},
  beforeUpdate() {},
  updated() {},
  beforeDestroy() {},
  destroyed() {},
  methods: {}
}

主に使用するのが created と mounted です。
created と mounted の違いは、DOM 要素の読み込みタイミングです。

created は DOM 要素が読み込まれる前
mounted は DOM 要素が読み込まれた後

となっています。

基本は created で初期化などの script 処理を行い、mounted で HTML に関連する処理を行いましょう。

style

style に CSS を記述する箇所です。
普通の CSS と同じ記法なので、問題なく書けると思います。

.display-flex {
  display: flex;
}

まとめ

今回は Vue.js の超基礎を紹介しました。

メイン所である Component と Binding については別記事で解説します。

関連記事:

1 年以上使用したエンジニアからみる Angular と Vue.js の違い

Wed, 31 Mar 2021 00:00:00 GMT

2026-05-16 追記: 初出は 2021 年で、当時は Vue 2 / Angular 11 前後が主流でした。現在は Vue 3（Composition API / <script setup>）と Angular 17+（Signals・standalone components・新しい制御フロー構文）が標準で、TypeScript 周辺の事情も Vue 側でかなり改善しています。本文の骨子（Angular = 全部入り / Vue = 最小構成）は今も大筋で当てはまりますが、コード例や API は当時のままなので、最新版の挙動とは差があります。

JavaScript フレームワークで有名なのは 3 つありますが、筆者は内 2 つを業務で使用した経験があります。

使用経験が無い React を除いた Angular、Vue.js の違いについて紹介します。

結論

Angular
- 全部のせ
- 記法ルールがしっかりしている
Vue.js
- 最小限の構成
- 記法ルールは自由度高め

Angular

概要

Angular は Google が開発しているフレームワークです。Ver 1 系は AngularJS と名称が違い、Ver 1 以降から Angular と呼ばれています。

Angular は半年ごとにメジャーアップデートがされるとアナウンスされています。メジャーアップデートは互換性が無いと宣言されているので注意です。

※筆者の経験では心配に反し、大きな影響はありませんでした。

筆者が感じた特徴としては:

フルスタックフレームワーク
TypeScript

です。

フルスタックフレームワーク

Angular は元からルーティング機能などがデフォルトで入っています。インストールしてしまえば、環境構築ができてしまうのは便利でした。また調べる時も公式を見れば解決する可能性が高いのも良かったです。

component のフォルダ構成は以下です。

component
  ├── component.ts
  ├── component.html
  ├── component.css
  └── component.spec.ts

1 ファイル内に言語が混在しないようになっているのは管理しやすいです。

フルスタックのデメリットとしては不要なコードが含まれる可能性が高い点です。パフォーマンスの影響は避けられません。

TypeScript

Angular の推奨言語は TypeScript です。TypeScript は Microsoft が開発している言語なので、Google と Microsoft の組み合わせは強そうに感じます。

静的型言語なので記述方法がガッチリしています。

TypeScript を書いたことが無い人にとっては、Angular と同時に学習することになるので学習コストが高いです。

Vue.js

概要

Vue.js は有志の方が開発しているフレームワークです。近年採用率が高く注目されています。

筆者が感じた特徴としては:

最小限の構成
自由度の高さ

です。

最小限の構成

Vue.js は Angular と違い、デフォルトでルーティング機能などは入っていません。ライブラリは個別で入れる必要がありますが、Vue Cli を使用すると簡単に導入できます。

component のフォルダ構成は以下です。

component
  └── component.vue

すごくシンプルです。vue ファイルの中に HTML・JS・CSS が記入されています。

JS と CSS は別ファイルに分離できます。

component
  ├── component.vue
  ├── component.js
  └── component.css

ただし、分離は手動で行う必要があります。

最小限の構成のデメリットはフルスタックの逆でライブラリは自分で探して導入する必要があります。ただし、最小限の構成なのでパフォーマンスが高いです。

自由度の高さ

Vue.js は JavaScript をデフォルト言語にしています。TypeScript も勿論導入できますが、しっかり導入するには少し手間がかかります（※現状補足: Vue 3 と <script setup> 以降は TypeScript サポートが改善され、2026 年時点では当時ほどの手間はかかりません）。

Angular との決定的な違いは自由度の違いです。プロジェクトは使用者の難易度・用途によって構成を変えられるのが Good です。

自分で調べる必要がありますが、敷居が低いのは明らかでした。

まとめ

今回は自分の経験も入れつつ Angular と Vue.js の違いについて紹介しました。

筆者としては Vue.js + TypeScript をおすすめします。設定は手間ですが可読性も高いですし、良いコードが書けます。

関連記事: Vue.js 入門 - Vue の基礎

YAMAHA TW-E3A レビュー — 通勤で1年使った完全ワイヤレスの“素直な”音と操作の癖

Tue, 30 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。TW-E3A は 2026 時点では旧モデルで、後継として TW-E3B / TW-E3C などが出ている。レビュー観点（音の素直さ、フィット感、物理ボタンの癖）は今も参考になる。スペック数値は執筆当時のメーカー公称値ベース。

通勤で1年ほど使ってきた YAMAHA の完全ワイヤレスイヤホン TW-E3A を、生活導線の中で見えた強み・弱みからレビューする。

YAMAHA が「初めて世に出した完全ワイヤレスイヤホン」という前提込みで評価する記事なので、最新の競合モデルとの絶対比較ではなく、価格帯・想定用途と噛み合うかどうかを軸にまとめた。

結論 — “癖のない音”を最優先する人に向く

短い答え: 音はメーカーのチューニング通りでクセが少なく、通勤での装着安定性も問題ない。一方で、物理ボタンの押し込みと、左右で割り当てが分かれる操作仕様は人を選ぶ。

理由はシンプルで、TW-E3A は「派手な低音」「強いノイズキャンセル」のような“振り切った特徴”を持たない代わりに、長時間聴いても疲れにくいバランスにまとめてあるから。音楽鑑賞というより、通勤・作業中の BGM 用途で安定して使える設計に寄っている。

ただし以下に該当する人は別モデルを検討した方がよい:

タッチ操作 / 多ボタンに慣れている人: TW-E3A は片側1つの物理ボタンで全機能を兼ねる
アクティブノイズキャンセリング前提の人: TW-E3A は ANC 非搭載（メーカー仕様ベース）
ランニングなどの激しい運動で使いたい人: フィットはするが、運動向けのフィン形状ではない

外観と質感

短い答え: ケースは“ミニチュア弁当箱”のような小ぶりな矩形で、胸ポケットに収まる。本体はやや横長で耳に深く差し込む形状。

蓋にはマットな YAMAHA ロゴ。指紋が目立ちにくい仕上げ。

ケース外寸はおおよそ 70 × 35 × 35mm（メーカー公称値）。同価格帯の競合と比べてもコンパクトな部類で、ジャケットの胸ポケットにすっぽり入る。

蓋は軽く押すだけでパカッと開き、閉じると自重で戻ってロックがかかる。鞄の中で勝手に開く心配はなかった。

本体はノズル（イヤーピース側）が深い。装着すると人差し指の第一関節分くらいまで入る感覚で、これが後述のフィット感に効いている。R / L 表記が筐体内側に刻印されているので暗所でも判別しやすい。

イヤホン単体だと横にやや長い印象。重量は片側 6.3g（メーカー公称値）。

ケース背面に USB Type-C ポートと充電ステータス LED。2021 年初頭発売の機種で Type-C を採用していたのはありがたく、2026 年現在も他デバイスとケーブルを統一しやすい。

良かった点

短い答え: 音の素直さ、通勤レベルのフィット感、Bluetooth 5.0 ベースの接続安定性の3つ。

YAMAHA らしいフラットで疲れにくい音

低音を盛らず、中高域もシャープに切り立たせない方向のチューニング。ボーカルとアコースティック楽器の質感が自然に出る一方で、EDM など低域の押し出しを期待するジャンルでは物足りないと感じる人もいる。

長時間（2〜3時間連続）使っていても耳が疲れにくいのは、このチューニングの恩恵が大きい。

通勤・徒歩通勤レベルでは外れない

ノズルが深く入る設計のおかげで、満員電車での乗り降りや小走り程度では落ちなかった。1年使った範囲では片側だけ落ちた事故はゼロ。

ただし運動向けのスポーツフィン等は付属しないので、ジムや本格的なランニングは別モデルを検討する余地がある。

Bluetooth 5.0 で混雑時も切れにくい

Bluetooth 5.0 対応（メーカー仕様ベース）で、都心の駅構内や電車内など電波が混みやすい場所でも、ぶつ切りや片側ロストの頻度は低かった。同価格帯で 4.x 世代のモデルを使っていた頃に比べて明確に安定している。

微妙だった点

短い答え: ボタンの押し込みが固い、左右で操作が分かれている、ANC 非搭載。

物理ボタンを“深く押し込まないと”反応しない

タッチセンサーではなく物理ボタン式。これ自体は誤タップが減るメリットがあるが、TW-E3A は押下に必要なストロークがやや深い。耳の奥に本体をグッと押し込む形になり、装着位置がズレるたびに密閉が崩れる感覚があった。

タッチセンサーか、少なくとももう少し軽い押下感だと使いやすかった。

左右で操作が違って覚えづらい

片側にボタンが1つずつしかないため、再生・音量・曲送りを左右の押し方で割り振る仕様になっている。

操作	割り当て
再生 / 停止	左右どちらか 1 クリック
音量 +	右 2 クリック
音量 −	左 2 クリック
次の曲	右長押し
前の曲	左長押し

「音量は右、曲送りも右」のように方向で統一されていれば直感的だが、現状は丸暗記する必要がある。1日数回しか触らない人には負担に感じやすい。

アクティブノイズキャンセリング非搭載

カナル型の物理的な遮音はあるが、いわゆる ANC は載っていない（メーカー仕様ベース）。電車内のレールノイズや空調音を完全に消したい用途には不向き。

比較 — ミドルレンジ完全ワイヤレスの中での立ち位置

短い答え: 「音のクセのなさ × 装着安定性」を軸に据えるなら同価格帯で競争力がある。一方、ANC や多機能タッチ操作が必須なら他を見たほうがよい。

観点	YAMAHA TW-E3A	同価格帯ミドル一般	YAMAHA 上位モデル（TW-E5B / E7B 系）
音のチューニング	フラット寄り、疲れにくい	低音強調が多い	リスニング志向、低音と解像感を両立
アクティブノイズキャンセリング	非搭載	搭載モデルが増加	搭載モデルあり
操作系	物理ボタン1つ × 左右	タッチ操作が主流	タッチ操作 + アプリ連携
接続	Bluetooth 5.0	5.0 〜 5.3	5.2 以降が主流
充電端子	USB Type-C	Type-C が主流化	Type-C
連続再生（本体）	約 6 時間（公称）	5 〜 8 時間	6 〜 10 時間（公称）

新規購入で「YAMAHA の音作りに惹かれている」のであれば、上位の TW-E5B / E7B 系を含めて比較するのが素直。逆に中古・型落ち市場で安く手に入る場面では、音と装着感の素性がしっかりしている TW-E3A は依然として実用的な選択肢になる。

よくある質問

Q. iPhone と Android、どちらでも問題なく接続できますか？ A. Bluetooth 5.0 対応機なら基本的に問題ない。マルチポイント接続には非対応（メーカー仕様ベース）なので、PC とスマホで頻繁に切り替える運用には向かない。1台で完結させるか、その都度ペアリングし直す前提で使う。

Q. バッテリーはどのくらい持ちますか？ A. 公称で本体単体約6時間、ケース込みで合計約24時間（メーカー公称値）。通勤片道 1 時間 × 往復で運用しても、平日 3〜4 日に 1 回ケースを置きに戻す程度のペース。

Q. テレワークの Web 会議用途には使えますか？ A. マイクは搭載されており通話自体は成立するが、ノイズリダクションを期待するレベルではない（メーカー仕様ベース）。静かな自宅環境での 1on1 などには使えるが、カフェやオープンオフィスからの会議用としては別途ヘッドセットを用意したほうが無難。

Q. ランニングや軽い運動には使えますか？ A. ノズルが深く入る形状で外れにくいので、通勤時の小走り程度なら問題なかった。一方、激しい上下動を伴うランニングや汗を多くかくジムワークアウトは想定外で、長期使用の耐汗性も保証されていない（防水等級はメーカー仕様で確認のこと）。本格的な運動用途には専用機を勧める。

総評 — “YAMAHA の音”を日常運用したい人向け

短い答え: 派手さで売るタイプではなく、音作りと装着感の地味な良さで日常運用に効く一台。「初代だからこそ無理をしていない」モデル、という見方が近い。

注意点はボタンの押下感と操作仕様の覚えづらさの2つ。家電量販店で実機があれば、装着して左右の操作を一通り試してから決めると後悔が少ない。最新世代との比較も検討するなら、上位モデルや後継機の仕様（ANC・マルチポイント・タッチ操作）も併せて見ておくと判断がブレない。

Anker PowerCore 10000 レビュー — スマホ2〜3回ぶんを手のひらサイズで持ち運ぶ定番モバイルバッテリー

Mon, 29 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。Anker PowerCore 10000 は 2026 時点では旧モデル扱いで、現行の主力は USB Type-C 入出力対応の PowerCore シリーズに移っている。10000mAh クラスを選ぶ基準（容量・サイズ・端子）の観点は今も参考になる。

外出先でスマホの電池切れに備えるためのモバイルバッテリーとして、Anker PowerCore 10000 を数年間メインで使ってきた。10000mAh クラスは「スマホ2〜3回ぶん」と「持ち運べる大きさ」のバランスがとりやすく、最初の1台として選びやすい容量帯。

ただし入出力端子はこの世代の弱点でもある。2026 年の視点で振り返ると、どこが今も通用してどこが見直し対象なのかを整理しておきたい。

結論 — 容量とサイズのバランス重視なら定番、ただし端子は古い

短い答え: 10000mAh をポケットに入る大きさにまとめた点は今も評価できる。Anker らしく充電挙動が安定しているので、外出時の保険として扱いやすい。ただし入力 USB Type-A / 出力 micro-B の構成は、2026 年現在の周辺機器とは噛み合いが悪い。

理由は、最近のスマホ・ノート PC・ワイヤレスイヤホンが USB Type-C に統一されつつあるから。Type-C ケーブル1本で揃えたい人にとって、このモデルのためだけに micro-B ケーブルを持ち歩くのは現実的でない。

以下に該当する人は注意:

手持ちのケーブルを USB Type-C に統一したい人: 同シリーズの Type-C 対応モデルを選ぶほうが整理しやすい
PD（Power Delivery）でノート PC を充電したい人: 本機の出力は USB-A / 2.4A までで、ノート PC の急速充電には対応しない
新品で買い直す人: 現行ラインの後継モデルのほうが、長期的に使い回しがきく

外観と大きさ

短い答え: 10000mAh としてはコンパクト寄り。高さを抑えて厚みに寄せた形なので、ジーンズのポケットにも収まる。

外装はマットなブラックで、指紋や擦れが目立ちにくい。Anker のモバイルバッテリーで共通して採用されている仕上げ。

公称スペックは以下のとおり（パッケージ表記準拠）。

項目	値
サイズ	約 92 x 60 x 22mm
重量	約 180g
容量	10000mAh
出力	最大 2.4A（PowerIQ 対応）
入力端子	USB Type-A
出力端子	micro-B

重量は 10000mAh クラスの平均的な値。高さが低い分、手で握ったときに収まりが良い。

端子は本体充電が USB Type-A、出力が micro-B。執筆当時（2021 年）は USB Type-A が一般的だったが、現在は古い世代の構成になる。

電源ボタンは側面。押すと青色 LED が4段階で残量を示す。スマホを接続してボタンを押せば給電が始まる、迷いどころのない仕様。

良かった点

短い答え: Anker らしい充電挙動の安定感と、10000mAh としてのコンパクトさが効く。

充電挙動が安定している

Anker 製のバッテリーを数台持っているが、給電中に切れる・接続が認識されないといったトラブルに当たったことがない。日常的に何度も抜き挿しする用途で、ここが安定しているのは大きい。

独自仕様の PowerIQ（接続機器に応じた電流調整）も、出力 2.4A の範囲内では素直に効く印象（体感ベース）。

10000mAh クラスとしてはポケットに入るサイズ

10000mAh あればスマホ2〜3回分、タブレットでも1回弱は充電できる容量帯。ここを「ポケットに入る大きさ」でまとめた点は、執筆当時から今も変わらず評価点。

カバンを持たずに外出する日でも、ジャケットや後ろポケットに入れて1日もつ。

LED 4段階のシンプルな残量表示

ボタン1回押しで残量が4段階で見える。スマホアプリ連携などはないが、その代わり挙動が読みやすい。バッテリー本体の電池切れに気付かず外出してしまう、というケースを減らせる。

微妙だった点

短い答え: 端子が USB Type-A / micro-B、PD 非対応、本体充電が遅め。

入出力が USB Type-A / micro-B

2021 年時点では一般的だったが、2026 年の視点では明確に弱点。手持ちのケーブルを USB Type-C に統一している人にとって、このモデル専用の micro-B ケーブルを持ち歩くのは負担になる。

新規購入なら、同じ Anker の Type-C 対応モデル（PowerCore III 10000 など）を勧めたい。

USB PD 非対応

出力は最大 2.4A の USB-A 単発で、USB Power Delivery（PD）には対応しない。

スマホの急速充電や、ノート PC・タブレットへの給電を想定する人には力不足。スマホを「念のため充電する」用途なら必要十分。

本体への充電が遅い

micro-B 入力で、付属の壁面アダプタを使っても満充電まで時間がかかる印象。

寝る前に挿して翌朝には満タン、という運用なら気にならないが、出発直前に継ぎ足したい用途には向かない。

比較: 10000mAh クラスの選び方

10000mAh クラスは「最初の1台」として選ばれることが多い容量帯。同じ容量帯の中での観点を整理する。

観点	PowerCore 10000（本機）	Type-C 対応の後継 PowerCore	20000mAh クラス
入出力端子	USB-A / micro-B	USB-C 入出力	モデルによる
重量	約 180g	約 190g 前後（公称）	約 350g 前後
容量	10000mAh	10000mAh	20000mAh
主用途	スマホ 2〜3 回	スマホ + 軽いタブレット	スマホ + ノート PC
価格帯（執筆当時）	約 2,500〜3,500 円	約 3,500〜5,000 円	約 5,000〜8,000 円

判断軸はシンプルで、「ケーブルを Type-C に統一したいか」「ノート PC まで給電するか」の2つ。両方 No ならこのクラスで十分、片方でも Yes なら別モデルを検討。

よくある質問

Q. iPhone / Android どちらでも使えますか？ A. 使える。出力は USB Type-A なので、それぞれの端末用ケーブル（Lightning / USB-C / micro-B）を用意すれば対応できる。本機側の出力ポートは USB-A 1口のみ。

Q. 飛行機に持ち込めますか？ A. 機内持ち込み可。容量 10000mAh は概算 37Wh 前後で、主要航空会社の上限（100Wh）に余裕で収まる（航空会社・路線によって扱いが異なるので、利用便の最新規定を要確認）。預け入れは不可なので注意。

Q. スマホは何回充電できますか？ A. スマホのバッテリー容量と充電ロスにもよるが、3000〜4000mAh のスマホで実用 2〜3 回ぶんが目安。本体に表示される LED 4段階のメモリで残量を把握しながら使う。

Q. ノート PC は充電できますか？ A. 基本的に向かない。出力が USB-A / 2.4A で USB PD 非対応のため、ノート PC の急速充電要件を満たさない。ノート PC まで給電したい場合は、USB PD 対応・出力 30W 以上のモデルを別途検討。

総評 — 「最初の1台」としては今も実用、新規購入なら後継モデル

10000mAh クラスの定番として、扱いやすさは今も変わらない。Anker の安定した挙動と手のひらサイズに収まる外形は、外出時の保険用として素直に使える。

一方で、新品で買い直す前提なら 2026 年の主流である USB Type-C 入出力のモデルを選ぶほうが、ケーブル運用の面で後悔が少ない。

既に PowerCore 10000 を持っているなら、micro-B ケーブルを常備してそのまま使い続けてよい。買い替えタイミングが来たら、後継の Type-C 対応モデルへ素直に移行するのが妥当な落としどころ。

プログラミング用 Windows ノート PC の選び方 — メモリ16GB・Core i5 / Ryzen 5 以上が現実的なライン

Sun, 28 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。骨子は今も参考になるが、CPU 世代と価格は執筆当時のまま。最新の世代・在庫状況は購入前に必ず確認すること。

プログラミングを学び始めるとき、最初に詰まるのが PC 選び。スペック表のどの数字を見ればいいか、どこまでお金をかければ無駄にならないかが分かりにくい。

この記事は、Web 系の学習・副業・転職を想定して、Windows ノート PC を買うときのスペック基準を整理する。MacBook と迷っている人向けに比較表も置いた。

結論 — メモリ16GB・Core i5 / Ryzen 5 以上、10万円前後が現実ライン

短い答え: 学習・副業用途なら、メモリ16GB・Core i5（第11世代以降）または Ryzen 5（第4世代以降）・SSD 512GB を満たすモデルを選ぶ。価格帯は10万円前後。

理由は2つ:

メモリは IDE・ブラウザ・Docker / 仮想環境を同時に立ち上げる時点で8GB だと窮屈。16GB あれば数年は持つ
CPU は中位グレード（i5 / Ryzen 5）で IDE のビルドやテスト実行に体感ストレスがない

逆に i7 / Ryzen 7 以上や32GB メモリは、機械学習や動画編集を兼ねないなら過剰。費用対効果が落ちる。

MacBook 派の人は別記事にまとめている。

プログラミング用 MacBook の選び方

メモリは16GB を基準にする

短い答え: 16GB。8GB は学習開始時点ではいけるが、半年〜1年で頭打ちになる。

プログラミング中にメモリを食う要素は次のとおり:

IDE（VS Code / IntelliJ など）— 拡張機能を入れると数 GB
ブラウザのタブ — 開発中は十数タブが普通
Docker / 仮想環境 — コンテナ1つあたり数百 MB〜
ローカル DB / 開発サーバー — 同時起動する

これらを並走させた瞬間に8GB は枯れる。スワップが発生すると SSD 寿命にも効くので、最初から16GB を入れておくほうが結果的に安い。

32GB が要るケース

機械学習・大規模なデータ処理・動画編集を兼ねるなら32GB。それ以外の Web 開発・スマホアプリ開発（Android 寄り）には16GB で足りる。

CPU は Core i5 / Ryzen 5 以上、世代を必ず確認する

短い答え: 中位グレード（i5 / Ryzen 5）の 新しめの世代 を選ぶ。世代の差はグレードの差より体感に効く。

ノート PC 用 CPU の現実的な下限ライン（2021年当時）:

Intel: 第11世代 Core i5 以上
AMD: Ryzen 5 第4世代（5000番台） 以上

2026 時点では当然もっと上の世代が出ているので、購入時は最新2世代以内に絞れば外さない。

i5 と Ryzen 5 の使い分け

プログラミング用途では体感差はほぼない。決め方の目安:

同価格でコア数が多いほうがいい → Ryzen 5
バッテリー駆動時間と電力効率を取りたい → Intel Core i5
法人サポートや在庫の安定 → Intel Core i5

i7 / Ryzen 7 以上は機械学習・動画編集を兼ねる場合の選択肢。プログラミング単体の用途では恩恵が薄い。

モデル別の判断 — 学習用 / 副業用 / 機械学習用

短い答え: 用途で3パターンに分かれる。価格帯と必要スペックは大きく違う。

学習用（Progate / Udemy → ポートフォリオ制作）

CPU: Core i5 / Ryzen 5（中位）
メモリ: 16GB
SSD: 512GB
GPU: 内蔵で十分
価格目安: 8〜10万円

最初の一台ならここで足りる。型落ち・直販アウトレットを使うとさらに2〜3万円下がる。

副業・転職用（実務寄り、Docker / 仮想環境を回す）

CPU: Core i5 / Ryzen 5（中位の新世代）
メモリ: 16GB（できれば後から32GB に拡張可能なモデル）
SSD: 512GB〜1TB
GPU: 内蔵で十分
価格目安: 10〜13万円

Docker・複数の仮想環境・ローカル DB を並走させる場面が出てくる。メモリ拡張可否を必ず確認する。

機械学習用（ローカルで学習を回したい）

CPU: Core i7 / Ryzen 7
メモリ: 32GB 以上
SSD: 1TB
GPU: NVIDIA GeForce RTX 系（VRAM 8GB 以上）
価格目安: 15万円〜25万円超

ノート PC でやり切るのは正直しんどい。学習タスクの規模が一定を超えるなら、最初からクラウド GPU を併用する前提で組むほうが現実的。

比較 — Windows ノート / MacBook / Linux ノート

短い答え: Web / バックエンド用途で同スペックなら Windows が一番安い。Apple Silicon の電力効率を取りたいなら MacBook、ハードウェアごと開発環境にしたいなら Linux ノート。

観点	Windows ノート PC	MacBook（Apple Silicon）	Linux ノート（ThinkPad など）
同スペック価格	安い（基準）	+2〜3万円	Windows と同等
開発環境構築	WSL2 で大半カバー	macOS（UNIX 系）で素直	ネイティブで素直
iOS / macOS 開発	不可（Xcode が動かない）	可	不可
バッテリー / 静音	モデルによる	強い	モデルによる
拡張・修理	しやすい（モデルによる）	しにくい	しやすい
機械学習（GPU）	NVIDIA 搭載モデルあり	MPS / Metal 経由（限定的）	NVIDIA 搭載モデルあり
学習リソース	多い（業務 PC が Windows）	多い	少なめ

iOS アプリ開発を視野に入れないなら、Windows は無難な選択。Linux ネイティブが好きな人は ThinkPad / Dell XPS あたりに Ubuntu を入れる構成が安定する。

モニターを足すほうがコスパが良い

ノート PC のスペックを1ランク上げるより、外部モニターを1枚足したほうが体感の作業効率は上がる。コードとブラウザ（プレビュー / ドキュメント）を並べられるかは生産性に直接効く。

外で書きたい人向けの軽量モデル選びは別記事にまとめている。

よくある質問

Q. プログラミングにメモリ8GB では足りないですか？ A. 学習目的・小規模な個人開発なら8GB でも動く。ただし IDE・ブラウザ（タブ多め）・Docker / 仮想環境を同時に立ち上げると一気に厳しくなる。買い替え前提でないなら最初から16GB を選ぶほうが結果的に安い。

Q. MacBook と Windows、プログラミング用ならどちらが良いですか？ A. iOS アプリ開発をしないなら、どちらでもよい。同スペック比で Windows のほうが2〜3万円安く、Linux 系の開発は WSL2 で十分こなせる。Apple Silicon の電力効率を取るか、価格と拡張性を取るかの選択。

Q. Core i5 と Ryzen 5、どちらを選ぶべきですか？ A. プログラミング用途で体感差はほぼない。同価格帯ならコア数で勝る Ryzen 5 が有利だが、バッテリー駆動時間や省電力性は Intel のほうが安定する傾向。価格・在庫・バッテリー要件で決めて構わない。

Q. 機械学習をやるならどんな構成が必要ですか？ A. ローカルで学習回すなら NVIDIA GPU（VRAM 8GB 以上）+ メモリ32GB が現実的な下限。本気でやるならクラウド GPU（Colab / RunPod など）に課金するほうが結局安い。ノート PC で完結させる構成はおすすめしない。

まとめ

プログラミング用 Windows ノート PC は、メモリ16GB・Core i5 / Ryzen 5 以上・SSD 512GB・10万円前後 を基準にすれば外しにくい。ここから上は機械学習・動画編集など兼用したい用途があるかで決まる。

MacBook と迷っているなら、iOS 開発をやるかどうかが分岐点。やらないなら同スペックで2〜3万円安い Windows 側で十分。

外部モニターを足せる予算があるなら、ノート本体のグレードを上げるより先に1枚買うほうが体感の差は大きい。

プログラミング用 MacBook の選び方 — Air で大半は足りる、ML や iOS 兼用なら Pro

Sat, 27 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事を全面リライト。Intel 時代の前提を Apple Silicon（M1〜M4）世代の現状に合わせて書き直した。具体的な価格・スペックは Apple 公式や量販店で必ず最新値を確認すること。

プログラミングを始めようとして MacBook を見にいくと、Air・Pro 14・Pro 16 と並んでいて、しかも各モデル内でも CPU / メモリ / SSD の組み合わせで数万円ずつ値段が動く。最初の1台でいきなり40万円コースを選ぶのも怖い。

この記事は「プログラミング学習・実務」という用途に絞って、Apple Silicon 世代の MacBook をどう選ぶかをまとめる。結論から言うと、ほとんどの人は Air で足りる。

Windows ノートと迷っている人はプログラミング用 Windows ノートの選び方、ブログ執筆を主目的に MacBook を見ている人はブログ用 MacBook の選び方も併読すると判断が早い。

結論 — Web / モバイルなら Air、ML や iOS の本格用途なら Pro

短い答え: プログラミング学習および Web / モバイルアプリ開発の大半は MacBook Air（M シリーズ・メモリ 16GB） で足りる。Pro が必要なのは、機械学習でユニファイドメモリを多く使う人、Xcode で長時間ビルドを回す iOS 開発者、外部モニターを2枚以上つなぐ人だけ。

判断軸は3つだけ:

何を作るか — Web / モバイルかぎりで Air、ML や重い iOS 開発なら Pro
メモリ — 16GB を基準。学習 + 仕事兼用や ML を見据えるなら 24GB / 32GB
画面と拡張性 — 外部モニター複数枚を常用するなら Pro 14 / 16

逆に言えば、8GB モデルと 256GB SSD の組み合わせは現代のプログラミング用途では避けたほうがいい（SSD 容量が依存ファイルとシミュレーターですぐ埋まる）。

用途別の判断 — Web / モバイル / ML で要求が変わる

短い答え: 「プログラミング」と一括りにしないで、自分が何を書くかで切り分ける。Web 系・モバイル系・機械学習系で必要なリソースは違う。

Web / バックエンド開発 — Air で十分

Node / Python / Go などのバックエンドや React / Vue などのフロントエンド開発は、MacBook Air で問題なくこなせる。Docker を複数コンテナで動かしても、メモリ 16GB あれば学習〜小規模実務までは余裕がある。

VS Code・ブラウザ・ターミナル・1〜2個のコンテナという典型構成なら、Air の冷却性能で長時間ファンが回ることもない。

モバイル開発 — iOS は Pro 14 が安心、Android は Air でも可

Android Studio は Air でも動くが、エミュレーター起動中はメモリを大きく食う。16GB を必須と考える。

iOS（Xcode）は Air でも開発可能で、業務でなく学習段階なら Air で困らない。ただし業務で1日中ビルドを回すなら、Pro 14 の冷却と SoC 性能が体感差になる。実機を複数つなぐ・長時間連続ビルドする用途は Pro 推奨。

機械学習 — ユニファイドメモリの大きい Pro 14 / 16

ローカルで推論やファインチューニングを試すなら、Apple Silicon のユニファイドメモリ（CPU/GPU 共有）が GPU メモリとして使える。これは Apple Silicon の強みで、24GB / 32GB / 64GB 構成の Pro なら、同価格帯の Windows ノート GPU では載らないモデルもオンデバイスで回せる場面がある。

本格的な学習（fine-tuning など）はクラウド GPU を併用するのが現実的。MacBook はあくまで推論・プロトタイプ用。

メモリと CPU の現実的な目安

短い答え: メモリは 16GB を起点、CPU（SoC）グレードは Air = 無印 M、Pro 14 = M Pro、Pro 16 = M Pro / M Max という棲み分けで考える。

メモリ — 8GB は今は避ける、基準は 16GB

Apple Silicon の 8GB は、Intel 時代の 8GB より粘る。しかし2026 年現在、ブラウザ・エディタ・コンテナ・チャット系常駐アプリを並行で動かすと、8GB ではスワップが日常的に発生する。

学習段階のみ・軽い用途: 16GB
業務 + 学習を兼用: 16〜24GB
ML / iOS 本格 / 動画兼用: 32GB 以上

メモリは購入時にしか選べない（Apple Silicon は半田付けで増設不可）ので、迷ったら一段上を選ぶのが後悔が少ない。

CPU（SoC）— Air の無印 M で大半は足りる

Apple Silicon の無印 M シリーズは、世代を重ねて Intel 時代の i7 を上回る性能になっている。Web / モバイル開発の通常作業では、無印 M で性能不足を感じる場面はほぼない。

M Pro / M Max は、長時間連続でフルロードをかける用途（動画書き出し・大規模ビルド・ML 学習）で差が出る。短時間のビルドや IDE 操作では Air と Pro の差は体感しづらい。

比較表 — Air / Pro 14 / Pro 16（プログラミング用途）

観点	MacBook Air	MacBook Pro 14	MacBook Pro 16
想定用途	Web / モバイル学習・業務	iOS / ML / 動画兼用	長時間ビルド・外部画面複数枚
SoC	無印 M	M Pro / M Max	M Pro / M Max
メモリ推奨	16GB	18〜24GB	24〜32GB 以上
SSD 推奨	512GB 以上	512GB 以上	1TB 以上
ディスプレイ	13 / 15 インチ	14 インチ ProMotion	16 インチ ProMotion
外部モニター	最大1〜2枚（世代依存）	複数枚可	複数枚可
冷却	ファンレス（M3 以前）/ 静音	アクティブ冷却	アクティブ冷却
重量	約 1.2〜1.5kg	約 1.6kg	約 2.1kg
価格レンジ	15〜25 万円	25〜40 万円	35〜60 万円

※価格・スペックは世代によって変動するので、Apple 公式サイトで購入時点の最新値を確認すること。

よくある質問

Q. メモリは 8GB と 16GB のどちらを選ぶべきですか？ A. 2026 年時点では 16GB を基準にする。Apple Silicon の 8GB は体感では Intel 時代より粘るが、Docker / 仮想環境 / ブラウザのタブを並行して開くとスワップが発生する。長く使うなら 16GB 以上が安心。

Q. MacBook Air で iOS アプリ開発はできますか？ A. できる。Xcode は Air でも問題なく動く。ただしシミュレーター起動と実機ビルドを繰り返す本格的な業務開発では、Pro の冷却性能のほうが体感速度で勝る場面がある。

Q. 機械学習をやるなら MacBook で足りますか？ A. 学習用途やローカル LLM 推論を真剣にやるなら、GPU メモリ（ユニファイドメモリ）の大きい Pro 14 / 16 が現実的。学習目的の入門なら Air でも始められるが、本格運用はクラウド GPU との併用を推奨する。

Q. Windows と MacBook、プログラミング用にはどちらがいいですか？ A. 業務で macOS / iOS / Apple 系開発をするなら MacBook 一択。Web / バックエンドだけなら Windows + WSL2 で十分。同じ価格帯では Windows のほうがスペック上は得だが、開発環境の整備しやすさと中古リセールでは MacBook が勝つ。詳細はプログラミング用 Windows ノートの選び方を参照。

まとめ

プログラミング用 MacBook は、Web / モバイル学習が中心なら Air（メモリ 16GB）で大半が片付く。Pro 14 / 16 が要るのは、ML でユニファイドメモリを多く使う・iOS で長時間ビルドする・外部モニターを複数枚つなぐ、のいずれかに当てはまるとき。

価格差をどこに振るかで言えば、最初の1台は Air をメモリ 16GB / SSD 512GB 構成にし、差額で外部モニターを用意する ほうが日常の作業効率に効く。

ブログ執筆用途で MacBook を見ている人はブログ用 MacBook の選び方、Windows ノートと比較したい人はプログラミング用 Windows ノートの選び方も参考になる。

タイプ別おすすめ iPhone 12 機種 — 5G 普及初年度モデルを今あえて選ぶ視点

Fri, 26 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。iPhone 12 は 日本市場で 5G が本格的に普及し始めた最初の iPhone（2020年秋発表）であり、ミリ波対応モデルが米国向け、Sub-6 のみが日本向けという棲み分けが定着した世代でもある。2026 年現在、新品で買う一線級ではないが、中古・型落ち購入の判断材料としては今も骨子が有効。具体的な価格や在庫情報は購入前に必ず確認すること。スペック表記は執筆当時の公称値で、最新の公式表記とは差分があり得る。

iPhone 12 は新品で買うフェーズを過ぎた一方で、中古・整備済みで「いま安く iPhone を持ちたい」候補としてはまだ現役。シリーズ内に mini / 無印 / Pro / Pro Max の4機種があり、サイズもカメラ構成も違う。

この記事は、iPhone 12 シリーズの4機種を 画面サイズと光学望遠の有無 という2軸で整理し、用途別にどれを選ぶかを示す。iPhone 11 と迷っている読者は、5G を使うかどうかで結論が変わるので最後の FAQ まで読んでほしい。

結論 — mini か Pro 系か。無印と Pro Max は中間で迷いやすい

短い答え: 片手で使いたいなら mini、望遠や夜景を撮りたいなら Pro 系。それ以外の人は無印で十分。Pro Max は「大画面で望遠も要る」人だけが選ぶ機種。

iPhone 12 シリーズの差は、突き詰めると以下の3点に収束する。

画面サイズ: 5.4 / 6.1 / 6.7 インチの3段階
光学望遠と LiDAR の有無: Pro 系のみ搭載
5G ミリ波対応: 日本向けモデルは全機種 Sub-6 のみ

価格やストレージで決めるよりも、まずこの3点で候補を絞るほうが速い。

iPhone 12 世代で何が進化したか

短い答え: 5G 対応、有機 EL 全機種化、MagSafe、A14 Bionic、ボディ設計の刷新。iPhone 11 世代から見ると「世代交代」と呼べる変化量がある。

5G 対応（日本では Sub-6 のみ）

iPhone 12 は 日本で発売された最初の 5G 対応 iPhone。日本向けは Sub-6 のみで、ミリ波（mmWave）対応モデルは北米向けに限られる。

体感的には、5G エリアにいれば下り速度が伸びるが、エリア外では 4G LTE にフォールバックするので「5G だから速い」と単純化はできない。2026 年時点では 5G エリアが広がっているので、当時より恩恵は受けやすい。

全機種が有機 EL（Super Retina XDR）に

iPhone 11 では無印が IPS 液晶、Pro 系のみ有機 EL という分かれ方だった。iPhone 12 からは mini / 無印を含めて全機種が有機 EL になり、黒の沈み込みと HDR 表示が共通の体験になった。

MagSafe ワイヤレス充電

背面に磁石のリングが入り、純正・サードパーティの MagSafe 充電器やアクセサリが吸着する。iPhone 12 以降のシリーズで共通の規格になっており、長く使う前提なら資産化しやすい。

ボディが直線的なデザインに戻った

iPhone 4 / 5 系を想起させるフラットエッジ。iPhone 11 までの丸みのある側面とは持ち心地が大きく違う。手の小さい人は実機を触って確認したほうがいい。

用途別の判断 — どれを選ぶか

短い答え: 「片手か / 望遠か / 大画面か」のどれを優先するかで機種が決まる。

片手で使いたい — iPhone 12 mini（5.4 インチ）

iPhone 12 mini は シリーズ内で最も小さい 5.4 インチ。同世代 Android のフラッグシップを含めても希少なサイズで、片手操作を最優先するならこれ一択。

ただし mini はバッテリー容量が小さく、ヘビーに使うと夕方には残量が厳しい場面がある。長時間外で使う人は無印以上を推奨。

望遠 / 夜景 / LiDAR が欲しい — iPhone 12 Pro / Pro Max

Pro 系のみ 光学望遠カメラと LiDAR スキャナ を搭載する。望遠は静物の寄りやポートレートで効き、LiDAR は暗所のオートフォーカス速度に直接効く。

iPhone 12 Pro: 光学2倍ズーム
iPhone 12 Pro Max: 光学2.5倍ズーム + センサーシフト式手ブレ補正

「ちょっと寄りたい」程度なら無印のデジタルズームでも足りるが、暗い場所で人物を撮る頻度が高いなら Pro 系の差は大きい。

大画面が欲しい — iPhone 12 Pro Max（6.7 インチ）

6.7 インチは動画視聴やゲームで効く。ただし片手では完全に握れないサイズなので、両手前提で使う割り切りが要る。

それ以外 — iPhone 12（無印, 6.1 インチ）

「サイズも光学望遠も特に強い要望はない」人は無印で過不足ない。iPhone 11 からの買い替えで一番自然な選択肢。

iPhone 12 シリーズ比較表

機種	画面サイズ	カメラ	光学望遠	LiDAR	重量
iPhone 12 mini	5.4 インチ	広角 + 超広角	なし	なし	約 133g
iPhone 12	6.1 インチ	広角 + 超広角	なし	なし	約 162g
iPhone 12 Pro	6.1 インチ	広角 + 超広角 + 望遠	2倍	あり	約 187g
iPhone 12 Pro Max	6.7 インチ	広角 + 超広角 + 望遠	2.5倍	あり	約 226g

スペックの数値は Apple 公表値。重量はケース無しの本体実測ではなく公称値。

iPhone 11 と iPhone 12、どちらを買うか

短い答え: 5G を使うかどうか、有機 EL に価値を感じるかどうかで決まる。

iPhone 11 シリーズの選び方はタイプ別おすすめ iPhone 11 機種にまとめている。両方の記事を読み比べると、12 で何が変わったかが見えやすい。

観点	iPhone 11	iPhone 12
5G	非対応	Sub-6 対応（日本向け）
無印の画面	IPS 液晶	有機 EL
MagSafe	非対応	対応
最小サイズ	5.8 インチ（Pro）	5.4 インチ（mini）
中古価格（2026目安）	より安い	やや高い

5G と有機 EL に価値を感じない、価格優先という人は iPhone 11 で十分。逆に「mini の片手サイズ」「無印で有機 EL」を欲しがる人は iPhone 12 を選ぶ意味がある。

よくある質問

Q. 2026 年から iPhone 12 を新品で買う意味はありますか？ A. 新品流通はほぼ終わっており、整備済品か中古が中心。バッテリーの劣化状況を確認できる前提なら、サブ機やライト用途では選択肢に入る。メイン機で長く使うなら新世代を勧める。

Q. iPhone 12 mini はバッテリーが弱いと聞きますが本当ですか？ A. 公称ビデオ再生時間で無印より短いのは事実。ヘビーユースだと夕方に残量が厳しい場面はある。片手サイズと引き換えの仕様として割り切るか、無印を選ぶかの判断になる。

Q. iPhone 12 の 5G は日本で意味がありますか？ A. 2020 年発売時は 5G エリアが限定的だったが、2026 年時点ではエリアが広がっているので恩恵を受けやすい。ただし日本向けは Sub-6 のみで、ミリ波の高速通信は対象外。

Q. iPhone 11 から iPhone 12 に買い替える価値はありますか？ A. iPhone 11 がまだ快適に動いているなら、無理に買い替える必要はない。買い替えの動機になりやすいのは「5G を使いたい」「無印でも有機 EL が欲しい」「mini の片手サイズが欲しい」のいずれか。

まとめ

iPhone 12 シリーズは「5G 普及初年の iPhone」として歴史的な位置づけがあり、全機種有機 EL 化と MagSafe 導入で世代としてのまとまりも良い。

2026 年から買うなら、新品ではなく中古・整備済品が現実的なライン。選ぶときは画面サイズ・光学望遠の有無・5G エリアの3点を確認しておけば、買ってから後悔する確率は下げられる。

iPhone 11 と迷っている人はタイプ別おすすめ iPhone 11 機種と読み比べると、世代差の輪郭がはっきりする。

iPhone 11 シリーズの選び方 — Pro / Pro Max / 無印を、用途別に絞り込む

Thu, 25 Mar 2021 00:00:00 GMT

2026 追記: この記事は 2021 年 3 月、iPhone 11 が「型落ち直後の狙い目モデル」だった時期に書いたもの。2026 年時点では iPhone 12 / 13 以降の機種も中古市場で十分に安く、iPhone 11 を新品で選ぶ理由はほとんどない。以下は 2021 年当時の購入判断のスナップショット として読んでほしい。骨子（Pro / Pro Max / 無印の差分の捉え方）は今も使える。

iPhone 11 シリーズは、発売から年数が経って「型落ち枠の狙い目」になった頃に一気に売れたモデル。Pro / Pro Max / 無印の3機種があり、価格差もそこそこ大きいので「どれを選ぶか」で迷う人が多い。

この記事は、3機種の差分を「画面サイズ・カメラ・ディスプレイ品質」の3軸に絞って整理する。読み終える頃には、自分が選ぶべき1台が決まっているはず。

結論 — Pro 系か無印か、判断は3点だけ

短い答え: iPhone 11 シリーズの選び分けは「3眼カメラ（望遠レンズ）が要るか」「有機 EL の鮮やかさが要るか」「6.5 インチの大画面が要るか」の3点で決まる。

逆に言うと、この3つに当てはまらない人は 無印 iPhone 11 で十分。Pro 系との性能差は普段使いではほぼ感じない。

機種	画面サイズ	カメラ	ディスプレイ	想定価格帯（2021 年）
iPhone 11 Pro Max	6.5 インチ	3 眼（望遠あり）	有機 EL・HDR	高
iPhone 11 Pro	5.8 インチ	3 眼（望遠あり）	有機 EL・HDR	中〜高
iPhone 11	6.1 インチ	2 眼（広角＋超広角）	IPS 液晶	中

タイプ別の結論を先に書くと、こうなる。

望遠で撮りたい / 暗所と動画にこだわる → Pro 系
画面の鮮やかさ（HDR 動画・写真編集）を重視 → Pro 系
ゲームを快適にやりたい → Pro 系
とにかく大画面が欲しい → Pro Max
上のどれも当てはまらない → 無印 iPhone 11

iPhone 11 シリーズの基本スペックを比較

短い答え: 3機種は SoC（A13 Bionic）が共通で、CPU 性能には差がない。差が出るのはカメラ・ディスプレイ・画面サイズ・バッテリーの4点。

CPU は A13 Bionic で共通

Pro / Pro Max / 無印すべてに同じ A13 Bionic が載っている。普段使いやアプリ起動の体感速度はどれを選んでもほぼ同じ。

「Pro のほうがゲームで快適」と感じる場面があるとすれば、それは CPU ではなく ディスプレイのリフレッシュ感 と 発熱時のサーマルスロットリング の差から来る部分が大きい。

差が出るのはカメラ・ディスプレイ・サイズ・バッテリー

観点	iPhone 11 Pro Max	iPhone 11 Pro	iPhone 11
SoC	A13 Bionic	A13 Bionic	A13 Bionic
画面サイズ	6.5 インチ	5.8 インチ	6.1 インチ
ディスプレイ	Super Retina XDR（有機 EL）	Super Retina XDR（有機 EL）	Liquid Retina（IPS 液晶）
カメラ	3 眼（広角・超広角・望遠）	3 眼（広角・超広角・望遠）	2 眼（広角・超広角）
バッテリー駆動目安	最も長い	中間	中間（無印は Pro より長持ちする報告あり）
重量	226 g	188 g	194 g

スペック表だけ見るとほぼ同じに見えるが、カメラの望遠レンズと有機 EL の2つは日常使用で体感差が出やすい。

用途別に判断する

短い答え: 「写真・動画で稼ぐ／趣味にする」なら Pro 系、「画面の大きさが何より優先」なら Pro Max、それ以外は無印で困らない。

写真・動画にこだわるなら Pro 系

3眼カメラの恩恵は 望遠レンズ（2倍光学ズーム） と ナイトモードの安定感。SNS に料理写真や旅行写真を上げる頻度が高い人は Pro 系のほうが満足度が高い。

ただし望遠は 2 倍程度なので、「遠くを大きく撮る」用途には足りない。あくまで「もう一歩寄れる」レベルだと思っておくと期待を外さない。

動画視聴・ゲームの没入感が欲しいなら Pro 系の有機 EL

Pro / Pro Max の Super Retina XDR は有機 EL + HDR 対応。Netflix の HDR タイトルや Apple TV+ のドルビービジョン作品で、黒の締まりとハイライトの伸びがはっきり違う。

無印 iPhone 11 の Liquid Retina（IPS 液晶）も十分キレイだが、HDR 動画を頻繁に見るなら Pro 系を選ぶ価値がある。

大画面で動画を観たい・電子書籍を読みたいなら Pro Max

6.5 インチは iPhone 11 シリーズで最大。電子書籍の見開きや動画視聴に向いている反面、重量 226 g は片手操作で疲れる。ポケットに入れて持ち運ぶ前提なら覚悟が要る。

上のどれにも当てはまらないなら無印 iPhone 11

普段使い（メッセージ・SNS・カメラ・動画視聴）が中心で、「望遠も HDR も大画面も特に要らない」なら無印で十分。価格差ぶんを別の出費に回した方が満足度が高い。

iPhone 11 と前後の世代を比較

短い答え: 旧モデル（iPhone XR / Xs）と比べると A13 + 超広角カメラ が乗ったぶん明確に上、iPhone 12 と比べると 5G 非対応と MagSafe 非搭載 が差。

iPhone XR / Xs から見ると素直に進化

CPU が A12 → A13 になり、処理速度・電力効率ともに改善
カメラに 超広角レンズ が追加（XR は単眼、Xs は望遠＋広角）
ナイトモードが追加され、暗所撮影が一段強くなった

XR からの買い替えなら体感差ははっきり出る。Xs からの買い替えはカメラ重視でなければ「急いで替えるほどではない」のが正直なところ。

iPhone 12 シリーズと比べると

iPhone 12 は 5G 対応、iPhone 11 は 4G まで
iPhone 12 は MagSafe（マグネット式アクセサリー）対応、iPhone 11 は非対応
ディスプレイは iPhone 12 が全機種有機 EL、iPhone 11 は無印のみ IPS 液晶
価格は iPhone 11 のほうが安い（2021 年時点）

詳しくは別記事の iPhone 12 シリーズの選び方で整理している。価格差を取るか、5G + MagSafe を取るかが iPhone 11 と 12 の分かれ目。

比較まとめ

観点	iPhone 11 シリーズ	iPhone 12 シリーズ	iPhone Xs / XR
SoC	A13	A14	A12
5G	非対応	対応	非対応
MagSafe	非対応	対応	非対応
超広角カメラ	あり（全機種）	あり（全機種）	XR はなし
有機 EL	Pro 系のみ	全機種	Xs のみ

よくある質問

Q. 2026 年に iPhone 11 を新品で買う意味はある？ A. ほとんどない。Apple 公式の販売は終了しており、中古市場でしか手に入らない。同じ価格帯で iPhone 12 / 13 が選べるなら、5G 対応や有機 EL ディスプレイがあるそちらを優先したい。サブ端末・キッズ用途・割り切った乗り換えなら中古の選択肢として残るレベル。

Q. iPhone 11 Pro と Pro Max、どちらを選ぶべき？ A. スペックは同じなので「6.5 インチが要るか」だけで決めていい。電子書籍・動画視聴メインなら Pro Max、片手操作のしやすさを取るなら Pro。重量差 38 g は持ってみるとそれなりに体感差がある。

Q. 無印 iPhone 11 の IPS 液晶は、Pro の有機 EL に比べてどれくらい劣る？ A. 横に並べて見ない限り「劣る」と感じる場面は少ない。違いがはっきり出るのは 真っ黒な背景の表示（有機 EL は完全に消灯）と HDR 動画の明暗差。普段の Web ブラウジングや SNS では差を意識することはほぼない。

Q. ゲーム用途で Pro と無印の差は出る？ A. SoC が同じ A13 なのでフレームレートの差は基本的に出ない。ただし長時間プレイで発熱した際、Pro 系のほうが筐体構造的に熱を逃がしやすいという報告がある。原神のような重量級ゲームを長時間やるなら Pro 系のほうが安定する可能性がある、くらいの差。

まとめ

iPhone 11 シリーズの選び方は、シンプルに「望遠カメラ・有機 EL・6.5 インチ大画面のどれかが要るか」で決まる。3つとも要らないなら無印 iPhone 11 で十分、写真・動画・ゲームに踏み込むなら Pro 系を取る。

2021 年時点ではコストパフォーマンスの良い選択肢だったが、2026 年現在は中古市場で iPhone 12 / 13 と比較できる価格になっているので、新品にこだわらず一段上の世代も候補に入れるのが現実的。

iPhone 12 を含めた比較は iPhone 12 シリーズの選び方を参考にしてほしい。

プログラミング用モニターの選び方 — 24インチ・フル HD・縦置きできる1枚から始める

Wed, 24 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。骨子（プログラミング向けに足すべき条件）は今も有効だが、製品リンクと相場感は執筆当時（2021年）の情報。価格・型番は最新を確認のうえ差し替えること。

プログラミング学習やエンジニアとしての就職をきっかけにモニターを買い足す人は多い。ただ、検索すると「ウルトラワイドが至高」「縦置きが必須」と極端な意見が並びがちで、最初の1枚としては判断材料にしにくい。

オフィス用途の基準（PC モニターの選び方）に、プログラミング向けの2点を足すだけで迷いはほぼ消える。コードを読む時間を増やしたいだけなら、24インチ・フル HD・非光沢・ピボット対応の1枚で十分に戦える。

結論 — 24インチ・フル HD・非光沢・ピボット対応の1枚から

短い答え: プログラミング用モニターは、オフィス用の選び方に「ピボット（縦置き）対応」と「文字の見通し」の2点を足したものになる。具体的には以下4点を満たす1枚から始めるのが現実的だ。

サイズ: 24インチ前後（机に置きやすく、フル HD でも文字が潰れない）
解像度: フル HD（1920×1080）— 24インチならスケーリング不要で扱いやすい
表面処理: 非光沢（ノングレア）— 長時間でも目の負担が小さい
ピボット対応: 縦置きできる土台、または VESA 対応（後でモニターアームに載せる前提）

デュアルにするか、縦置きで使うか、4K に投資するかは「あとで足す」で構わない。最初の1枚をこの条件で選んでおけば、どの方向にも拡張できる。

サイズと解像度 — 24インチ・フル HD が扱いやすい

短い答え: プログラミング用途で最初に揃えるなら、24インチ・フル HD。理由は、追加設定なしでコードがそのまま読めるサイズだから。

24インチでフル HD（1920×1080）なら、IDE のデフォルトフォントサイズ（13〜14pt 前後）でちょうど80〜100カラムが快適に並ぶ。スケーリングを 100% のまま使えるので、Linux や古いツールでの表示崩れに巻き込まれにくいのも実務的な利点だ。

27インチでフル HD にすると、ドットピッチが粗くなって文字の縁がにじむ感じが出る。逆に 27インチ以上で快適に使いたいなら 4K が前提になる（→ FAQ 参照）。

机の奥行きが60cm未満なら、24インチを基準に。それ以上の奥行きがあれば27インチ 4K も選択肢に入る。

縦置き（ピボット）と横置きの使い分け

短い答え: 横置きが基本、縦置きは「縦に長いものを読む時間が長い人」だけ追加で考える。

理由は、プログラミングの作業時間のうち、コードを書く時間より「ログ・差分・ドキュメントを読む時間」のほうが長いから。読む対象が縦長（ログ、Markdown、Git の diff、PDF）なら、縦置きにすると1画面に収まる情報量が増えて、スクロール回数がはっきり減る。

横置き — 標準。最初の1枚はここから

横置きは IDE / ブラウザ / ターミナルを横並びに置く構成と相性がよい。マルチカラムの IDE（左にツリー、中央にエディタ、右にプレビュー）を素直に使うなら、横置きで困らない。

縦置き — ログ・長いコード・PR レビュー向け

縦置きが効くのはこういう人:

サーバーログを長時間追う（SRE / バックエンド寄り）
GitHub の PR レビューが日課（diff の縦スクロールが減る）
長文ドキュメント・仕様書を読む時間が多い

縦置きには ピボット対応の土台 または VESA 対応 + モニターアーム が必要。買う時点でどちらかを確保しておくと、あとから「やっぱり縦置きしたい」となったときの追加コストがゼロになる。

デュアルにするなら「同型・横並び」

デュアルディスプレイはコード行き来の時間を確実に削る。ただし上下に重ねるより左右に横並びのほうが、視線移動が水平で済むぶん目の疲れが軽い。

並べる2枚は同型で揃えるのが無難。型番が違うとフチの厚みや色味が揃わず、視線を移すたびに微妙な違和感が残る。

比較表 — 一般オフィス用途 vs プログラミング向け

オフィス用と比べて、プログラミング向けで追加・変更したいのは「ピボット対応」と「2枚目への拡張余地」の2点に絞られる。

観点	一般オフィス用	プログラミング向け推奨
サイズ	22〜24インチ	24インチ（行数が伸びる）
解像度	フル HD	フル HD（24インチ）／ 4K（27インチ以上）
表面	非光沢	非光沢（必須）
表示方式	VA か IPS	IPS 推奨（横から見ても色が安定）
ピボット	お好み	対応（または VESA で後付け）
枚数	1枚で十分	1枚 → 同型をもう1枚（横並び）
価格目安	1.5〜3万円	2〜4万円 ×1〜2枚

オフィス基準の3点（表示方式・サイズ・表面処理）は PC モニターの選び方と共通。プログラミング向けは「ピボット対応」と「2枚目を足せる余地」を足すだけだ。

項目	スペック
サイズ	24インチ
表示方式	IPS
解像度	フル HD
表面	非光沢
ピボット	対応
VESA マウント	対応

項目	スペック
サイズ	24インチ
表示方式	IPS
解像度	フル HD
表面	非光沢
ピボット	スタンド非対応（アーム前提）
VESA マウント	対応

よくある質問

Q. デュアルディスプレイは必須ですか？ A. 必須ではない。1枚でも、IDE のタブ切り替えとウィンドウ分割で十分に書ける。ただし PR レビューや資料を見ながら書くのが日常的なら、2枚目で作業時間がはっきり短くなる。最初は1枚から始めて、机のスペースと予算に余裕が出たら同型を足すのが無理がない。

Q. 縦置き（ピボット）にすると本当に効きますか？ A. 効く人は限定的。ログを長時間追う・PR レビューが多い・長文ドキュメントを読む人にははっきり効く。一方、フロントエンド開発やデザイン作業中心なら、横置き2枚のほうが体感は上。買う時点では「VESA 対応」だけ確保しておけば、あとからアームで縦置きに切り替えられる。

Q. 4K モニターは必要ですか？ A. 24インチではほぼ不要。24インチ 4K はドットピッチが細かすぎてスケーリング前提になり、設定が増える割に得るものが少ない。4K が生きるのは 27インチ以上で、文字が滲まずに広い作業領域を取れる場合。最初の1枚なら 24インチ・フル HD のほうが扱いやすい。

Q. Mac にどう接続すれば失敗しないですか？ A. 最近の MacBook は USB-C / Thunderbolt 出力なので、モニター側が USB-C 入力（DP Alt Mode） に対応していると、ケーブル1本で給電と映像を同時に処理できて配線が減る。USB-C 入力がないモニターを買うなら、HDMI または DisplayPort 入力を持つモデルを選び、USB-C → HDMI / DP のアダプタを別途用意する。M シリーズ初期の MacBook Air には外部モニター1枚までの制限があるので、デュアル運用を前提にするなら本体側の出力数も確認しておく。

まとめ

プログラミング用モニターは、オフィス用の基準（24インチ・フル HD・非光沢・IPS）にピボット対応と2枚目を足せる余地を加えるだけで足りる。

最初の1枚は欲張らず、24インチ・フル HD・非光沢・VESA 対応のスタンダードな機種を選ぶ。デュアル化と縦置きはあとから低コストで足せるので、買う時点で全部決め込まなくていい。

オフィス用途と共通する選び方は PC モニターの選び方に分けて書いている。表示方式（VA か IPS）やサイズ・表面処理の話をもう一段詳しく知りたい場合はそちらを併読すると効率がいい。

HDMI ケーブルの選び方 — バージョン (1.4 / 2.0 / 2.1) と用途で決める

Tue, 23 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。当初は HDMI 2.0a までを前提に書いていたが、4K120Hz / 8K / VRR を扱う HDMI 2.1 が一般化したため、本文を全面的に書き直した。商品リンクは確認のうえ最新モデルへ差し替えること。

「テレビとゲーム機をつなぎたい」「PC のモニター用に追加で買いたい」「4K のはずなのに 4K に見えない」。HDMI ケーブルを買おうとして手が止まる理由は、だいたいこのどれかだ。

ケーブル自体は数百円から数千円までと幅があり、見た目もほとんど変わらない。違いは外箱に小さく書かれた バージョン と 端子形状 にある。この記事は、その2点を中心に「自分が今買うべき HDMI」の輪郭を出すことが目的。

結論 — バージョンと長さと端子形状の3点で決まる

短い答え: HDMI 選びは難しくない。用途に合うバージョン × 必要十分な長さ × 機器に合う端子形状 の3点を順に決めるだけで終わる。

用途別の最短ルート:

フル HD（1080p）まで → HDMI 1.4 で十分
4K60Hz / HDR → HDMI 2.0 （プレミアムハイスピード）
4K120Hz / 8K / VRR（ゲーム機・最新 GPU） → HDMI 2.1 （ウルトラハイスピード）

長さは机回りなら 1〜3m を基準に、配線距離より少しだけ長めを選ぶ。端子は両側の機器で「タイプ A（標準）／ Mini ／ Micro」を必ず確認する。これだけで失敗はほぼなくなる。

HDMI バージョンとは — 帯域幅と対応機能のセット

HDMI バージョンとは

HDMI ケーブルおよび端子の規格世代を示す番号。世代ごとに 最大帯域幅（Gbps） が決まっており、それに応じて 対応する最大解像度・リフレッシュレート・HDR / VRR などの機能 が変わる。新しい世代のケーブルは古い世代の機能を含む後方互換だが、逆は成り立たない（古いケーブルで新しい機能は使えない）。

ここを押さえないと「4K テレビなのに 4K に見えない」「ゲームで 120Hz が出ない」が起きる。ケーブルが帯域不足だと、機器側が自動的に下位の信号にフォールバックするからだ。

各バージョンの代表的な仕様は次の通り。

HDMI 1.4 — フル HD / 4K30Hz まで

2009 年に策定された世代。最大帯域は約 10.2Gbps で、フル HD（1920×1080）60Hz、4K（3840×2160）30Hz までを実用範囲とする。

3D 映像やイーサネット機能もこの世代から入った。今となっては フル HD のテレビや古めのモニター向けの最低ライン という位置づけ。

HDMI 2.0 — 4K60Hz / HDR の主力

2013 年策定。最大帯域は 18Gbps で、4K60Hz と HDR10 に対応する。

2026 年現在、4K テレビや 4K モニターと一般的な機器を組み合わせるなら、まずこの世代を基準にすれば失敗しない。プレミアムハイスピード と書かれているケーブルが該当する。

なお、HDR を確実に使いたい場合は HDMI 2.0a 以降 を選ぶ。2.0 と 2.0a の違いは HDR メタデータ対応の有無で、外箱に「HDR 対応」と明記されているかが見分けの近道。

HDMI 2.1 — 4K120Hz / 8K / VRR

2017 年策定。最大帯域は 48Gbps と一気に跳ね上がり、4K120Hz、8K60Hz、可変リフレッシュレート（VRR）、自動低遅延モード（ALLM） に対応する。

PlayStation 5 や Xbox Series X / S、最新の GPU で 4K120Hz を出したい場合は、ケーブル側もこの世代でないと帯域が足りない。ケーブル名としては ウルトラハイスピード HDMI として売られている。

HDMI 2.1 を名乗っていても帯域が 48Gbps に満たない製品があるため、購入時は 「Ultra High Speed HDMI Cable」認証ラベル の有無を見るのが安全。

用途別の選び方 — 5パターンで分解

短い答え: 何につなぐかで答えは決まる。手元のケースに当てはめて選べばいい。

テレビ＋レコーダー（フル HD）なら HDMI 1.4

フル HD の地デジを録画再生する用途であれば、HDMI 1.4 で必要十分。安価なベーシックモデルで問題ない。

4K テレビ＋ Blu-ray / 配信デバイスなら HDMI 2.0

4K60Hz / HDR の映像が中心になる。プレミアムハイスピード認証のケーブルを選ぶ。家電量販店で「4K 対応」と書かれているケーブルは、ほぼこのクラス。

PC ＋ 4K モニター（クリエイティブ用途）なら HDMI 2.0

写真・動画編集やデザイン作業なら 4K60Hz で十分。HDMI 2.0 を基準にする。

なお、PC モニター側に DisplayPort 入力があるなら、DisplayPort のほうが世代的に有利なことが多い。HDMI に縛られない場合は選択肢として検討の余地あり。

ゲーム機（PS5 / Xbox Series X）なら HDMI 2.1

4K120Hz や VRR を活かしたい場合は HDMI 2.1 が必須。PS5 には HDMI 2.1 ケーブルが同梱されているので、追加で買うときも同等品を選ぶ。

ノート PC ＋プロジェクター（一時利用）なら HDMI 1.4 でも可

会議室や出張先での投影は、解像度が WUXGA 程度に落ちるケースが多い。長さは 3m 以上必要になりがちなので、ケーブル品質（シールド・芯線） のほうが世代より体感に効く。

比較表 — HDMI 1.4 / 2.0 / 2.1

最大解像度・リフレッシュレート・代表的な用途を1枚にまとめた。

項目	HDMI 1.4	HDMI 2.0 / 2.0a	HDMI 2.1
最大帯域幅	10.2 Gbps	18 Gbps	48 Gbps
最大解像度	4K30Hz	4K60Hz	8K60Hz / 4K120Hz
HDR	非対応	対応（2.0a 以降）	対応（Dynamic HDR）
VRR / ALLM	非対応	非対応	対応
別名	ハイスピード	プレミアムハイスピード	ウルトラハイスピード
主な用途	フル HD テレビ／レコーダー	4K テレビ／ 4K モニター	PS5 / Xbox Series X / 8K テレビ

長さは「配線距離 + 余裕分」で選ぶ

短い答え: ケーブルは短すぎると届かず、長すぎるとたるんで邪魔になる。実測距離に 0.5〜1m の余裕を足した長さ が現実的な落とし所。

常設なら 2〜3m

机の裏や壁裏を回す常設配線は、見た目より配線距離が伸びる。デスク回りで実測 1.5m なら、ケーブルは 2〜3m を選ぶ。

一時利用なら 1〜2m

ノート PC とモニターを直接つなぐような一時利用は、機器同士が近い。1〜2m で十分。

5m を超える長距離は要注意

HDMI は規格上は長距離でも動くが、5m を超えるあたりから 4K60Hz / HDR の信号が落ちやすくなる。長距離が必要な場合は、光ファイバー HDMI ケーブル（アクティブ光ケーブル、AOC）を検討する。

端子形状 — 両側の機器で必ず確認する

短い答え: HDMI 端子には タイプ A（標準）／ Mini HDMI（タイプ C）／ Micro HDMI（タイプ D） の3種類がある。買う前に 両側の機器の端子形状 を確認する。

家庭用機器は基本的にタイプ A だが、以下のケースでは Mini / Micro が混ざる:

一眼カメラ／ビデオカメラ — Mini か Micro が多い
小型ノート PC や 2-in-1 — Mini HDMI のことがある
アクションカメラ — Micro HDMI が多い

また、HDMI ではなく DisplayPort や USB Type-C（DP Alt Mode） の機器も増えている。映像出力が「USB-C のみ」のノート PC は HDMI ケーブルでは直結できないので、USB-C → HDMI 変換アダプタが必要になる。

よくある質問

Q. HDMI 2.1 のケーブルを買えば、古い機器でもアップグレードされますか？ A. されない。HDMI は 両側の機器とケーブルすべて が同じバージョンに対応していて初めてその世代の機能が使える。古いテレビに 2.1 ケーブルをつないでも、テレビ側の仕様で頭打ちになる。

Q. プレミアムハイスピードとウルトラハイスピード、見分け方は？ A. パッケージの認証ラベルで判別する。「Premium High Speed HDMI Cable」が HDMI 2.0 / 2.0a 相当、「Ultra High Speed HDMI Cable」が HDMI 2.1 相当。ラベルなしの「4K 対応」表記だけでは帯域が保証されない。

Q. 1000円のケーブルと5000円のケーブル、何が違いますか？ A. 大きく分けて、芯線の素材・シールドの厚み・端子の作りが違う。フル HD や 4K60Hz 用途なら認証付きの安価品で十分問題なく、5000円クラスの差が体感に出るのは 長距離 / 4K120Hz / 8K / プロ用機材 の文脈が中心。

Q. ケーブルだけで遅延は変わりますか？ A. ほぼ変わらない。映像の遅延（インプットラグ）はテレビ・モニター側の処理に依存する部分が大きく、ケーブルが直接的に遅延を増やすことは通常はない。ゲーム用途は ALLM / VRR 対応の HDMI 2.1 機器を選ぶほうが効く。

用途別おすすめモデル

以下は執筆当時の選定と 2026 年時点で同等帯のモデル。具体的な商品は購入時点の最新世代を確認すること。

4K60Hz / HDR 用途 — HDMI 2.0 プレミアムハイスピード

家庭用 4K テレビと PC / ゲーム機をつなぐ一般用途は、認証付きのプレミアムハイスピードが第一候補。2m 前後で十分。

4K120Hz / 8K / VRR 用途 — HDMI 2.1 ウルトラハイスピード

PS5 / Xbox Series X / 最新 GPU で 120Hz を出したい場合は、Ultra High Speed 認証付きを選ぶ。

5m 超の長距離 — 光ファイバー HDMI (AOC)

会議室の天井プロジェクターや、テレビと AV ラックが離れた配置に向く。価格は同長の銅線品より高いが、4K60Hz / HDR の信号を安定して通せる。

まとめ

HDMI ケーブルは見た目で差がつかない分、バージョン × 長さ × 端子形状 の3点を意識するだけで選び方が一気にシンプルになる。

フル HD なら 1.4、4K60Hz / HDR なら 2.0、4K120Hz や 8K / VRR を扱うなら 2.1。長さは実測 + 0.5〜1m、端子は両側で確認。これさえ守れば「買ったのに本来の画質が出ない」事故は避けられる。

迷ったら、いま使っている機器の最大解像度・リフレッシュレートを先に確認するのが近道。ケーブルは機器の性能を引き出す道具で、機器以上のものは出してくれない。

モニターアームの選び方 — VESA・耐荷重・クランプの3点で外さない買い方

Mon, 22 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。骨子（選び方の観点）は今も有効だが、製品リンクと価格帯は執筆当時（2021年）の情報。型番・価格は最新を確認のうえ差し替えること。

モニターアームを入れると、デスクの天板が一気に広くなる。書類や飲み物を置くスペースが戻り、画面の高さも姿勢に合わせて自由に動かせる。

ただし安いものから高いものまで価格帯が広く、選び方を間違えるとモニターが下がってきたり、最悪設置できないこともある。この記事では、長時間 PC 作業で使う前提のモニターアームを、VESA・耐荷重・設置方式の3点に絞って整理する。

結論 — VESA 100×100、耐荷重1.5倍、クランプ式

短い答え: モニターアーム選びは以下の3点で外さない。

VESA マウント: モニター側が VESA 100×100mm に対応していること
耐荷重: モニター実重量の 1.5倍 を目安に余裕を持たせる
設置方式: クランプ式（天板に挟むタイプ）

予算と寿命のバランスで言うと、長く使うならエルゴトロン LX 級のガススプリング式（1万円台後半〜2万円台）、短期で割り切るなら低価格帯のガス式（5000円〜1万円）。バネ式やボルト固定の安価モデルは「動かして使う」用途には不向き。

モニターアームは何のために導入するか

短い答え: デスクの天板を広く使うため、そして画面の高さを姿勢に合わせて動かすため。

理由は、モニターを台座で置くとスタンドの足が天板の手前まで張り出し、奥行きの3〜5割を占有するから。アームに替えると天板手前は完全に空く。

副次効果として、地震で倒れにくくなる、ケーブルが整理しやすくなる、複数モニターの位置合わせが楽になる、といった点もある。1人で正面に座って使う前提なら、ここはおまけと考えていい。

VESA マウントとクランプ vs グロメット — 用語を先に整える

VESA マウント（VESA mount）とは

モニター背面のネジ穴規格。VESA 100×100mm は、4つのネジ穴が縦横100mm 間隔で配置された規格を指す。22〜27インチクラスの一般的なモニターはほぼこの規格に対応する。 32インチ以上では VESA 200×200mm など別規格になることがあるので、購入前にモニター仕様書を確認する。

クランプ式とグロメット式の違い

クランプ式: 天板を上下からクリップのように挟み込む方式。天板を傷つけにくく、工具なしで設置できる。デスク奥に十分なクリアランス（5cm 前後）が必要。

グロメット式: 天板にあらかじめ開けた穴（または既存の配線穴）にボルトを通して固定する方式。デスクの端でなくても設置できる代わりに、穴を開ける加工が必要になる。

家庭用デスクの大半はクランプ式で問題なく設置できる。グロメット式は、デスク中央や、天板の奥が壁に密着していてクランプの隙間が確保できない場合に検討する。

設置方式 — クランプ式が無難

短い答え: クランプ式を選んでおけば、家庭用デスクで困る場面はほぼない。

理由は、天板に穴を開けずに済むため賃貸でも使いやすく、引っ越しや配置換えにも対応しやすいから。グロメット式は穴あけが前提なので、デスクを手放すときに加工が残る。

クランプ式が向くケース

賃貸で天板を加工したくない
デスクの奥行きが65cm 以上ある（クランプ部の張り出し分を確保できる）
モニターをデスク奥側の端に置きたい

ほとんどの家庭用 PC デスクはこの条件を満たす。

グロメット式が向くケース

デスクに配線穴がすでに開いている
壁にデスクを密着させたい（クランプ部が壁と干渉するため）
モニターをデスク中央寄りに置きたい

業務用デスクや、配線穴付きのスタンディングデスクで採用が増えている。

耐荷重 — モニター実重量の1.5倍

短い答え: モニターの実重量に 1.5倍 の余裕を見ておけば、ガススプリングがへたっても画面が下がりにくい。

理由は、ガススプリング式は内部のガス圧で重量を支えており、上限ギリギリで運用すると経年でガス圧が落ちたとき支えきれなくなるから。耐荷重の上限値ぎりぎりで使い続けると、半年〜1年で「気付くと画面が下がっている」状態になりやすい。

重量の目安

22〜24インチ: 3〜4kg
27インチ: 5〜7kg
32インチ: 7〜10kg

つまり24インチなら耐荷重5〜6kg 以上、27インチなら耐荷重8〜10kg 以上のアームを選ぶと、1.5倍の余裕を確保できる。

サイズではなく重量で見る

製品スペックに「対応サイズ27インチまで」のような表記があるが、これは目安にすぎない。同じ27インチでも重量は機種で2倍違うことがあるので、必ずモニター側の仕様書で実重量を確認してから耐荷重と突き合わせる。

可動方式 — ガススプリング式が標準

短い答え: 上下に頻繁に動かすならガススプリング式。固定位置で使うだけならバネ式やボルト固定でもいいが、価格差は1000〜2000円程度なのでガス式が無難。

理由は、ガス式は片手で軽く高さを変えられるのに対し、バネ式は強度調整がシビアで、ボルト固定式は工具が要るから。「動かさないなら何でもいい」と思っていても、姿勢が変わると高さを変えたくなるので、結果的に動かしやすい方が長く使える。

ガススプリング式 / バネ式 / ボルト固定式の違い

ガススプリング式: 内部のガス圧で支える。片手で動かせる。最も一般的。
バネ式（メカニカルスプリング）: 金属バネで支える。ガス式より安価だが、調整ネジで強度を合わせる必要がある。重量がぴったりだと使えるが、重さが変わると再調整が要る。
ボルト固定式: 関節を六角ネジで固定するタイプ。一度合わせたら動かさない前提。価格は最安だが、姿勢を変える運用には不向き。

価格帯と製品の比較

短い答え: 5000円〜2万円台の幅がある。長く使うならエルゴトロン LX、短期割り切りなら低価格帯のガス式、固定運用ならボルト固定式、という棲み分け。

観点	エルゴトロン LX 級	低価格中華ガス式	バネ式	ボルト固定式
価格目安	1.7〜2.5万円	5000〜1万円	4000〜8000円	3000〜6000円
可動方式	ガススプリング	ガススプリング	メカニカルスプリング	ボルト固定
耐荷重目安	〜11kg	〜8kg	〜8kg	〜10kg
動かしやすさ	片手で軽い	片手で動くが個体差あり	強度調整が要る	動かさない前提
保証	10年（公称）	1年前後（公称）	1年前後	1年前後
向く人	5年以上使う前提	試してみたい / 短期	同上	固定位置のサブ用途

長く使うなら、保証期間と部品の入手性が効いてくる。低価格帯はガス圧が落ちたら買い替え、と割り切る運用になりやすい。

よくある質問

Q. VESA マウントに対応していないモニターでも使えますか？ A. 一部メーカーは VESA 変換アダプターを別売している。ただしモニター背面のスタンド取付方式は機種固有で、変換アダプターが用意されていない場合は実質使えない。購入前にモニターの仕様書で VESA 対応を確認するのが確実。

Q. クランプ式は天板が薄くても使えますか？ A. アーム側のクランプには対応天板厚（例: 10〜60mm）が記載されている。薄すぎる天板はクランプが噛まず固定が甘くなる。逆に厚すぎると挟めない。天板厚を測ってから対応範囲を確認する。

Q. デュアルモニター用は1本のアームで2画面を支えるタイプを選ぶべきですか？ A. 1本2画面のアームは見た目はすっきりするが、耐荷重と可動範囲がシビアになる。長く使うなら、シングルアームを2本並べて設置するほうが将来の入れ替えや単独運用に対応しやすい。

Q. モニターアームを使うと振動でぐらぐらしませんか？ A. クランプの締め込みが十分で、天板の厚みと素材が適切（合板やスチール）なら、キー入力程度の振動でぐらつくことはほぼない。極端に薄い天板や中空のデスクでは振動が出るので、その場合は天板側を変えるか、ボルト固定式に切り替える。

まとめ

モニターアームは VESA 100×100mm 対応・耐荷重がモニター実重量の1.5倍・クランプ式の3点を満たせば、価格帯が違っても外さない。

長く使う前提ならエルゴトロン LX 級、短期で試すなら Amazon ベーシック級のガス式が現実的。バネ式やボルト固定式は、固定位置で使う前提なら選択肢に入る。

モニター本体を先に選んでからアームを合わせる流れがおすすめ。モニター選び自体は別記事で整理している（PC モニターの選び方 — 失敗しない3点と、お好みで1点）。

モニターのパネル種類を用途で選ぶ — IPS / VA / TN / OLED の違いと使い分け

Sun, 21 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。骨子（パネル別の使い分け）は今も有効だが、価格帯と OLED の普及状況は当時から大きく動いている。相場感の数字は最新を必ず確認すること。

モニターのスペック表に並ぶ「IPS」「VA」「TN」「OLED」というアルファベット。違いを正確に説明できる人は意外と少ない。

それでも、選び方の軸は単純だ。仕事も動画も普通にこなしたいなら IPS、とにかく安く済ませたいなら VA、競技系ゲームの反応速度を取りたいなら TN、映画や HDR の見え方を最優先するなら OLED。この記事は、その判断を5つの観点（色再現・視野角・応答速度・価格・用途）で1ページに整理する。

結論 — 迷ったら IPS、目的が決まっているなら別パネル

短い答え: 何を選んでいいか分からないなら IPS を選んでおけば外しにくい。色のバランスがよく、視野角も広く、価格もこなれてきている。

ただし、目的が明確なら他のパネルが正解になる場面がある。

IPS — 仕事 + 動画 + 軽いゲームの「万能枠」。迷ったらこれ
VA — 価格優先、または暗いシーンの多い動画視聴
TN — FPS / 格闘ゲームなどフレームレートを最優先する競技用途
OLED — HDR 映像や映画体験を取りたい、予算に余裕がある人

「パネルの種類」で大枠が決まるので、ここを最初に決めると後のスペック比較が早い。

パネル種類とは — 液晶の駆動方式と自発光の違い

短い答え: パネルとは画面を構成する「絵を出す層」のこと。液晶（IPS / VA / TN）は背後のバックライトを液晶分子で透過制御し、OLED はピクセル自身が発光する。

用語まとめ

液晶パネル: バックライト + 液晶層で構成。光をどう曲げて通すかで色を出す

IPS（In-Plane Switching）: 液晶分子を水平方向に駆動。視野角と色再現に強い

VA（Vertical Alignment）: 液晶分子を垂直方向に駆動。黒の表現に強い

TN（Twisted Nematic）: 液晶分子をねじって駆動。応答速度に強く、価格が安い

OLED（Organic Light-Emitting Diode）: 有機 EL。ピクセル自身が光るのでバックライト不要、黒は完全に消灯できる

液晶3種の違いは「液晶分子の動かし方」だけだが、これが色・視野角・速度のトレードオフを決める。OLED は仕組みが根本から違うので別カテゴリと考えていい。

IPS — 万能枠、迷ったらこれ

短い答え: 色がきれいで視野角が広く、価格もこなれてきた。仕事 + 動画 + 軽めのゲームを1台でやりたい人の第一候補。

IPS の特徴

色再現: 良好。sRGB ほぼフルカバーが普通

視野角: 広い（左右ともに 170° 以上、公称）

応答速度: ふつう（5〜8ms クラスが標準、ゲーミング向けは 1ms 表記もある）

価格: 中。23〜27インチで 2〜4万円台が量販ライン

弱点は、強いコントラストが必要な場面で黒が浮きやすいこと。完全な暗室で映画を観るなら OLED に分があるが、明るい部屋で日常的に使うぶんには気にならない。

「最初の1台」「リモートワーク用」「写真や軽い動画編集も触る」あたりはほぼ IPS で答えが出る。

VA — 価格優先、黒が締まる動画向き

短い答え: 同サイズ帯で最安クラスが多く、黒の表現が強い。1人で正面に座って動画を観る用途と相性がよい。

VA の特徴

色再現: ふつう。コントラスト比は高め（3000:1 前後が多い、公称）

視野角: やや狭い。斜めから見ると色が薄くなる

応答速度: 中〜遅。動きの速いシーンで残像（黒挿入なし時）が出やすい

価格: 安い。23インチ前後で 1〜2万円台の選択肢が豊富

近年は MVA / AMVA など改良版が増え、IPS との視野角差は小さくなってきている。とはいえ、複数人で覗き込む会議用途や、デスク上でモニターを斜めから見る配置では IPS のほうが扱いやすい。

予算 2 万円以下で 1 台揃えたい場合、現実的な選択肢は VA に寄る。

TN — 競技系ゲーム特化、応答速度に全振り

短い答え: 応答速度と価格の安さに振り切ったパネル。FPS や格闘ゲームのフレーム単位の反応を取りたい人向けで、普段使いには色と視野角の弱さが効いてくる。

TN の特徴

色再現: 弱い。色域カバー率は IPS / VA より一段落ちる

視野角: 狭い（特に上下方向）

応答速度: 速い（1ms 表記が普通）

価格: 安い。ゲーミング機能込みで 2 万円台のモデルが多い

「TN は古い」と言われがちだが、240Hz / 360Hz クラスのゲーミングモデルでは今も TN が現役。色を捨ててでもフレームを取りたい競技勢が選ぶパネル、と割り切るのが正しい。

逆に、ライティングや表計算を長時間やる用途では、視野角の狭さで姿勢が固定されがちなのでおすすめしない。

OLED — HDR と映画体験、ただし価格と焼き付きに注意

短い答え: ピクセル自発光で黒が完全に消える。HDR 映像の階調と、映画館的なコントラストを取りたいなら一択。ただし価格は液晶の数倍で、長時間の固定表示で焼き付きのリスクがある。

OLED の特徴

色再現: 非常に良い。DCI-P3 ほぼフルカバーが普通

視野角: 広い。自発光なので斜めからも色崩れが少ない

応答速度: 非常に速い（液晶の応答速度とは別軸、画素応答が 0.1ms クラスとされる）

価格: 高い。27〜32インチで 10〜20 万円台が中心

注意点は焼き付き。タスクバーやウィンドウの枠など、同じ位置に同じ画像が長時間出続けると、その輪郭が画面に残ることがある。最近のモデルはピクセルシフトやスクリーンセーバーで対策しているが、業務でずっと同じ画面を映す用途には今でも向かない。

「映画と HDR のためのモニター」「予算に余裕があり、見え方に投資したい人」向けの選択肢。

比較 — IPS / VA / TN / OLED を5観点で並べる

短い答え: 色再現・視野角・応答速度・価格・用途別ベストの5観点で並べると、自分の優先順位に合うパネルが見える。

観点	IPS	VA	TN	OLED
色再現	良い	ふつう	弱い	非常に良い
視野角	広い	やや狭い	狭い	広い
応答速度	ふつう〜速い	中〜遅	速い	非常に速い
価格	中	安い	安い	高い
用途別ベスト	仕事 + 動画の万能枠	動画中心、価格優先	競技系ゲーム	HDR / 映画体験

価格と色再現はおおむねトレードオフ。視野角と応答速度は IPS と OLED の両取りに近い。TN は「速さと安さ」の特化、VA は「黒と安さ」の特化、と覚えておくと整理しやすい。

数値の細かい差（応答速度 1ms vs 4ms など）は、競技ゲームをしないなら体感差が出にくい。まずはこの表で大枠を決め、そこから個別モデルを比較するのが効率的。

用途別の判断 — どれを買えばいいか

短い答え: 用途が決まっているなら、パネル選びは下のチャートで終わる。

用途	選ぶパネル	理由
仕事 + 動画 + たまにゲーム	IPS	万能。視野角と色のバランスがよい
とにかく安く 1 台	VA	同サイズ帯で最安クラス。動画視聴とも相性がよい
FPS / 格ゲー競技	TN	応答速度と価格。色は捨てる前提
映画 / HDR / 写真鑑賞	OLED	黒の表現と色域。予算が許すなら
写真 / 動画編集	IPS（広色域モデル）	sRGB / DCI-P3 のカバー率を仕様で確認
マルチディスプレイ追加	既存と同じパネル種	並べたとき色味が揃いやすい

「複数枚を並べる」場合、パネル種が違うと同じ画像でも色味が変わって見える。仕事で 2 枚以上使うなら、メーカーまで揃えなくてもパネル種だけは合わせると作業ストレスが減る。

FAQ

Q. パネル種類はスペック表のどこを見れば分かりますか？ A. 商品ページの「パネル種類」「表示方式」「パネル方式」あたりの欄に記載がある。記載がない場合は、メーカー公式のスペックシート（PDF）を確認するのが確実。

Q. IPS と書かれていても、メーカーによって品質に差はありますか？ A. ある。同じ「IPS」表記でも、色域カバー率（sRGB / DCI-P3 のパーセンテージ）や輝度の数値はモデル差が大きい。仕様欄の数値で比較するのが安全。

Q. OLED の焼き付きはどのくらいで起きますか？ A. 使用パターン次第。タスクバーやアプリの UI が同じ位置に長時間出続ける環境では、数百〜数千時間で輪郭が見え始めるとされる。映画視聴中心なら気になりにくい。気になる場合は、自動非表示タスクバーやスクリーンセーバーの設定で軽減できる。

Q. ゲーミングモニターでも IPS は選べますか？ A. 選べる。最近は 144Hz / 240Hz で応答速度 1ms 表記の IPS モデルが増えている。競技勢でなければ、TN ではなく IPS のゲーミングモデルで色と速度の両取りを狙うのが現実的。

まとめ

パネル選びは「何を優先するか」で決まる。色と視野角を平均的に取りたいなら IPS、価格を取りたいなら VA、フレーム速度を取りたいなら TN、HDR と黒の表現を取りたいなら OLED。

仕様表の数字を細かく比較する前に、まず4種類のどれに寄せるかを決める。ここが決まれば、あとはサイズ・表面処理・接続端子の確認だけで済む。

モニターの選び方そのもの（サイズや表面処理の決め方）は別記事で扱っている。あわせて読むと、製品ページの仕様欄が一目で読めるようになるはず。

ゲーミングモニターの選び方 — 144Hz・1ms・パネル種別で9割決まる（2026年版）

Sat, 20 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。骨子（リフレッシュレート / 応答速度 / パネル）は今も有効だが、2026 年時点では 240Hz が普及帯に降りてきており、OLED ゲーミングモニタも10万円前後で選択肢に入る。具体的な商品リンクは確認のうえ最新モデルへ差し替えること。

PS5 や最新の PC ゲームに合わせてモニターを買い替えたい。けれど「Hz」「ms」「IPS」「G-Sync」と用語が並ぶだけで、どれを基準に選べばいいのか分かりにくい。

この記事は、ゲーミングモニターを「リフレッシュレート」「応答速度」「パネル」「同期技術」の4軸で整理する。読み終える頃には、自分のジャンルと予算に合う1台の輪郭が見えているはず。

結論 — FPS / 格ゲーなら 144Hz・1ms・IPS が現実的な最低ライン

短い答え: 速度を競うジャンル（FPS・格ゲー・対戦アクション）を遊ぶなら、購入前にチェックすべきは以下の4点。

リフレッシュレート: 144Hz 以上（PS5 含む据置きは120Hz が上限のことが多い）
応答速度: GtG 1ms 前後
パネル: IPS（バランス重視）/ TN（最速・安価）/ OLED（最高峰・高価）
同期技術: FreeSync（AMD）または G-Sync Compatible（NVIDIA）対応

逆に RPG / シミュレーション / ターン制ゲーム中心なら、上の数値はオーバースペック。一般的な作業用 IPS モニター（60Hz）で十分にきれいに遊べる。

この記事のポイント

リフレッシュレートは 144Hz 以上（2026 年は 240Hz が普及帯）

応答速度は GtG 1ms を目安に

パネルは IPS が万能、最速なら TN、画質最優先なら OLED

PC は FreeSync / G-Sync 対応で必ず合わせる

用語の整理 — Hz / ms / FreeSync とは

短い答え: スペック表に並ぶ3つの用語は、それぞれ「滑らかさ」「残像」「ティアリング対策」を測る別物の指標。

ゲーミングモニター用語

Hz（リフレッシュレート）: 1秒間に画面が書き換わる回数。144Hz なら毎秒144回更新される。数値が高いほど動きが滑らかに見え、相手の動きにいち早く気づける。

ms（応答速度 / GtG）: ピクセルが「Gray to Gray（中間色から別の中間色）」へ切り替わる時間。1ms に近いほど残像（ゴースト）が少ない。カタログ値と実測値は乖離することがある。

FreeSync / G-Sync（同期技術）: GPU の描画タイミングとモニターの書き換えタイミングを合わせ、画面のズレ（ティアリング）やカクつき（スタッタリング）を抑える仕組み。FreeSync は AMD 由来、G-Sync は NVIDIA 由来だが、近年は相互互換が進んでいる。

リフレッシュレート — 144Hz が標準、2026 年は 240Hz が現実圏

短い答え: FPS / 格ゲー目的なら 144Hz が現実的な下限。2026 年は 240Hz クラスが3〜5万円台に降りてきており、コスト効率が高い。

理由は、リフレッシュレートが高いほど1秒あたりの情報量が増え、敵の動きに反応するまでの遅延が短くなるから。60Hz と 144Hz の差は体感で明確に分かるが、144Hz と 240Hz の差は競技勢以外には小さい。

60Hz から 144Hz への乗り換えは効果が大きい

普段使いの一般モニターはほぼ 60Hz。ここから 144Hz に上げると、マウスカーソルの動きから違いを感じる。FPS の振り向きで「敵がどこにいたか」を把握できる範囲が広がる。

240Hz 以上はジャンルと環境を選ぶ

240Hz / 360Hz の効果を引き出すには、GPU 側が安定してそのフレームレートを出せる必要がある。PS5 や Xbox Series X は 120Hz が上限なので、家庭用ゲーム機メインなら 144Hz で頭打ち。

接続規格にも注意

高リフレッシュレートは映像ケーブルの規格に依存する。4K 144Hz を出すには DisplayPort 1.4 以上、または HDMI 2.1 が必要。古い HDMI 2.0 ケーブルだと帯域が足りずに 60Hz に落ちることがある。

応答速度 — GtG 1ms 前後を目安に

短い答え: 速度を競うジャンルなら応答速度は GtG 1ms 前後を選ぶ。これより遅いと、動きの速いシーンで残像が見える。

理由は、応答速度が遅いとピクセルが前のフレームを引きずったまま次のフレームに重なり、敵のシルエットがブレて見えるから。FPS で残像があると、相手がどこを向いているかの判定が遅れる。

カタログ値と実測値はズレることがある

「1ms（GtG）」と表記されていても、実測ではモードによって倍以上ばらつくケースがある。レビューサイトの実測値も合わせて確認するのが安全。

オーバードライブ機能の使いどころ

多くのゲーミングモニターは「オーバードライブ（OD）」設定でピクセル切替を強制的に速める機能を持つ。強くかけすぎると逆残像（オーバーシュート）が出るので、付属の中庸モードから試すのが現実的。

パネル種別 — IPS が標準、TN は最速、OLED は新しい選択肢

短い答え: 2026 年時点のおすすめは IPS（バランス）/ TN（最速・最安）/ OLED（画質最優先）。

理由は、パネル方式によって応答速度・視野角・色再現・価格のバランスが大きく異なるから。同じ 144Hz・1ms でも、見え方と価格は別物。

IPS — 万能、迷ったらこれ

色の鮮やかさと視野角に優れる。応答速度は以前は TN に劣ったが、ゲーミング向け IPS（Fast IPS など）は 1ms クラスまで詰まっており、FPS でも実用に耐える。価格帯は3〜7万円が中心。

TN — 最速・最安、ただし画質と視野角を諦める

応答速度は依然として最速級、価格も最も安い。一方で色がくすみ、横から見ると色が変わる。デスクの正面に固定して使うソロプレイ向き。

VA — コントラスト重視、競技用には向かない

黒の沈み込みが深く映画やシングルプレイ RPG に向く。ただし応答速度は IPS / TN より遅く、暗部での残像（ブラックスメア）が出やすいので競技ゲーム用途には外す。

OLED — 2026 年の新しい選択肢

QD-OLED / WOLED を採用したゲーミングモニターが普及してきた。応答速度 0.03ms 級、コントラスト無限の領域で、映像表現は液晶を大きく超える。価格は 10〜20 万円が中心で、焼き付きリスクは残るものの保証が手厚いモデルが増えた。

FreeSync / G-Sync — PC ゲームでは GPU と必ず合わせる

短い答え: PC でゲームをするなら、自分の GPU メーカーに合う同期技術が載ったモニターを選ぶ。

理由は、GPU の描画速度とモニターの書き換え速度がズレるとティアリング（画面の横ズレ）やスタッタリング（カクつき）が出るから。同期技術はこれを自動で吸収する。

NVIDIA GPU 中心: G-Sync / G-Sync Compatible 対応モデル
AMD GPU 中心: FreeSync / FreeSync Premium 対応モデル
両対応モデル: 近年は1台で両方に対応する機種が増えており、GPU を将来買い替える可能性があるなら両対応が安全

PS5 / Xbox は HDMI VRR に対応しており、これは FreeSync 系統と互換がある。

比較表 — 60Hz / 144Hz / 240Hz+

観点	60Hz（一般用）	144Hz（ゲーミング標準）	240Hz+（競技 / 最新世代）
想定ジャンル	RPG / 作業	FPS / 格ゲー全般	競技 FPS / e スポーツ
滑らかさ	普通	明確に滑らか	144Hz との差は体感小
必要 GPU	内蔵 GPU でも可	ミドルレンジ以上	ハイエンド GPU 推奨
PS5 / Xbox 適合	適合	120Hz 出力で恩恵あり	オーバースペック
価格帯（24インチ）	1〜2万円	3〜5万円	5〜8万円
パネルの選択肢	IPS / VA 中心	IPS / TN / VA	IPS / OLED

オススメモニター — 用途別

以下は執筆当時（2021年）に選定したモデル。2026 時点では後継 / 同等価格帯の最新モデルを必ず確認すること。

最速重視 — TN 144Hz

応答速度を最優先したい競技勢向け。色味は妥協する前提で、価格と速度を取りに行く構成。

項目	スペック
大きさ	23.6インチ
パネル	TN
解像度	フル HD
表面	非光沢
応答速度	GtG 1ms
リフレッシュレート	144Hz
同期技術	FreeSync
VESA マウント	◯

バランス重視 — IPS 144Hz

FPS も RPG も遊ぶマルチジャンル向け。視野角と色の鮮やかさを確保しつつ、応答速度も実用域に収める。

項目	スペック
大きさ	23.8インチ
パネル	IPS
解像度	フル HD
表面	非光沢
応答速度	GtG 1ms
リフレッシュレート	144Hz
同期技術	FreeSync / G-Sync Compatible
VESA マウント	◯

画質最優先 — OLED 240Hz（2026 年の選択肢）

予算が許せば検討したい上位帯。映像表現と応答速度を両立する。WQHD 以上の解像度と組み合わせるのが現実的。

よくある質問

Q. PS5 では 144Hz / 240Hz の恩恵はありますか？ A. PS5 は HDMI 2.1 で 4K 120Hz / フル HD 120Hz が上限。144Hz 以上の出力はできないが、120Hz 対応モニターであれば対応タイトルで効果がある。VRR（HDMI VRR）対応モデルだとフレーム変動時のカクつきも抑えられる。

Q. 4K 144Hz とフル HD 240Hz、どちらを選ぶべきですか？ A. ジャンルで決める。フレームレートが直接勝率に効く競技 FPS ならフル HD 240Hz、ストーリー / アクション中心で映像の精細さを取りたいなら 4K 144Hz。両立したいなら WQHD 165〜240Hz が折衷案。

Q. 応答速度 1ms と 0.5ms の違いは体感できますか？ A. 大半の人は体感できない。パネル切替の差より、ケーブル規格・GPU 出力フレームレート・モニター内部処理遅延（インプットラグ）の方が体感差が大きい。

Q. ゲーミングモニターは普段使い（仕事 / ブラウジング）にも使えますか？ A. 問題なく使える。むしろ 144Hz の滑らかさはスクロール時にも体感できる。ただし色の正確さが求められる写真編集や映像制作には、別途キャリブレーション対応の専用モニターが向く。

まとめ

ゲーミングモニター選びは「リフレッシュレート」「応答速度」「パネル」「同期技術」の4軸で整理すると判断しやすい。

FPS / 格ゲー中心なら 144Hz / GtG 1ms / IPS / FreeSync または G-Sync Compatible が現実的な最低ライン。2026 年は 240Hz クラスが普及帯に降りており、画質を取りに行くなら OLED ゲーミングモニタが上位の選択肢になる。

ジャンルが RPG / シミュレーション中心なら、これらの数値はオーバースペック。用途に合わせて買うのが、結局いちばんコスト効率が高い。

4Kモニターは万人向けではない — 用途別に4K / WQHD / FHD を選ぶ判断基準

Fri, 19 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植したうえで、2026 視点で骨子をリライトした記事。2021 年当時より4Kモニターは安く・普通になったが、「全員が4Kを買うべき」かは依然として用途依存。具体的な機種リンクは公開前に最新モデルで差し替えること。

「4Kモニターが欲しいけれど、どれを選べばいいかわからない」「コスパのいい4Kを知りたい」— こうした相談を受ける機会が増えた。ただ、話を聞いていくと「そもそも4Kが必要なのか」が曖昧なまま機種比較に入ってしまっているケースが多い。

この記事は、4Kを選ぶ前に立ち止まって判断するための観点をまとめる。買う・買わないの線引きと、買う場合の4つのチェックポイントを順に書いた。

結論 — 4Kは万人向けではない、用途で選ぶ

短い答え: 4Kモニターは「写真・動画編集」「4K映像視聴」「28インチ以上で広い作業領域がほしい」のいずれかに当てはまる人向け。文章中心の作業や軽いゲームならWQHDのほうが費用対効果が高い。

理由は3つある。

画面が小さいと差を体感しづらい — 27インチ以下ではスケーリング前提になり、4Kの解像感を活かしきれない
GPU負荷が跳ね上がる — ゲームやリアルタイム3Dは4Kだと描画コストが2倍以上になる
ケーブル・接続規格の要件が増える — HDMI 2.0a / DisplayPort 1.4 以上が必要で、古いPCだと出力できない

逆に4Kが効くのは、写真の現像で原寸プレビューしたい / 4K 動画素材を等倍で確認したい / 28インチ以上の大画面で文字を細かく置きたい、といった「精細さが直接成果物に効く」用途。

4Kとは

4K（UHD）: 解像度 3840×2160 ピクセル。FHD（1920×1080）の縦横2倍、面積で4倍の情報量。「DCI 4K」（4096×2160、映画館規格）とは別物で、市販モニターのほぼ全ては3840×2160のUHD。

比較: 4K / WQHD / FHD はどう違うか

短い答え: 解像度が上がるほど作業領域は広がるが、必要なGPU性能・モニター価格・スケーリングの手間も上がる。

観点	FHD (1920×1080)	WQHD (2560×1440)	4K (3840×2160)
画面の使いやすさ	24インチでドット感なし。文字中心なら十分	27インチに最適。スケーリング不要で扱いやすい	28インチ以上が前提。27以下はスケーリング必須
価格目安（27インチ IPS）	2〜3万円台	3〜5万円台	5〜8万円台
必要 GPU 性能（ゲーム時）	エントリーGPUで60fps	ミドルレンジ必要	ハイエンド推奨
用途別ベスト	文章・事務・軽いゲーム	プログラミング・配信・eスポーツ	写真/動画編集・大画面・映像視聴

価格は2026年5月時点の量販店実勢価格の感覚値。為替と新製品サイクルで動くので、購入時に必ず再確認する。

4Kを選ぶときのチェックポイントは4点

短い答え: 4Kを買うと決めたら、「画面サイズ」「HDR対応」「色再現度」「パネル方式」の4点を確認する。HDMIケーブルだけは買った後の落とし穴なので、加えて注意。

理由は、この4点が外れていると「せっかく4Kを買ったのに体感が変わらない」という結末になりやすいから。順に見ていく。

画面サイズ: 28インチ以上で4Kの効果が出る

短い答え: 4Kの解像感を活かすなら28インチ以上。27インチ以下だとスケーリング前提になり、メリットが薄れる。

理由は、4KはFHDの4倍の情報量だが、画面が物理的に小さいと1ドットが細かすぎて文字が読めなくなる。OS側でスケーリング（拡大表示）をかけて読めるサイズに戻すことになり、結局「広い作業領域」というメリットが消える。

例として、24インチ4Kは100%スケーリングだと文字が極小で常用が難しい。150%にすると実効解像度はWQHDに近づく — それなら最初からWQHDで十分という話になる。

目安サイズ: パソコン用なら28〜32インチ。35インチ以上はリビングTVの距離感に近くなり、デスクで近づいて見るには大きすぎる。

注意: ノートPCの内蔵モニターは別物

ノートPCの13〜15インチで4Kを選ぶ意味は「Retina的な高精細さ」が目的のときだけ。作業領域は広がらない。

HDR対応: 映画・ゲーム用途なら必須、文書用途なら不要

短い答え: 暗部の表現を広げる機能。映像コンテンツを楽しむなら効くが、文章作業には恩恵が薄い。

理由は、HDR（High Dynamic Range）が白から黒までの輝度レンジを通常より広く扱う規格だから。暗いシーンの夜空や、明暗が同居する逆光のシーンで違いが出る。

例として、HDR非対応のモニターで暗いシーンを見ると黒が潰れて何が映っているかわかりにくい。HDR10対応なら同じシーンで物体の輪郭が見える。

カタログ表記の見方: 「HDR10」「HDR10+」「Dolby Vision」のいずれかが書かれていれば対応。記載がなければ非対応。なお「HDR Ready」や「HDR Compatible」は信号を受けられるだけで実効的なHDR表示ができない場合があるため、注意。

注意: HDRはOS・コンテンツ側の対応も必要

モニターが対応していても、Windows の HDR 設定と再生側コンテンツがHDR対応していないと効かない。

色再現度: クリエイティブ用途なら 90% 以上を目安に

短い答え: 写真・動画・イラストを扱うなら sRGB 100% または NTSC / Adobe RGB 90% 前後を目安にする。文章用途なら気にしなくていい。

理由は、色再現度（色域）はモニターが表現できる色の範囲を示す指標だから。低いモニターでは、本来鮮やかな赤や緑がくすんで見える。

例として、sRGB 70%程度の安価なモニターで写真を編集すると、別の端末で見たときに「自分が編集したより派手な色」になっていることがある。色域が広い側で確認するほうが安全。

カタログ表記の見方: 「sRGB カバー率 100%」「Adobe RGB 90%」「NTSC 90%」のように%表記。記載がなければ広色域対応ではないことが多い。

パネル方式: 文章・写真・動画はIPS、競技ゲームは TN / OLED

短い答え: 一般用途はIPS一択。視野角が広く色変化が少ない。応答速度を最優先する競技ゲームだけ TN や OLED を検討する。

理由は、IPSは斜めから見ても色が変わりにくく、写真や動画の確認に向いているから。TNは応答速度が速いが視野角が狭く、色が浅い。VAは黒の表現に強いが応答が遅め。

例として、デュアルモニター構成で1台を斜め向きに置いた場合、TNパネルだと色味が画面の角度で変わって違和感がある。IPSなら同じ色で揃う。

OLED は選択肢に入ってきた

2021年時点では「ほとんど出ていない」と書いていたが、2026年現在は27インチクラスのOLEDモニターが10万円台で入手できるようになった。黒の表現と応答速度はIPSを上回るが、焼き付きリスクがあるため文字を長時間表示する用途では注意が必要。

落とし穴: HDMIケーブル / DisplayPort の規格

短い答え: 4K HDR を 60Hz で出すなら HDMI 2.0a 以上または DisplayPort 1.4 以上。古い規格のケーブルだと FHD にダウンスケールされる。

理由は、HDMI / DisplayPort は規格バージョンで伝送できる解像度・リフレッシュレート・色深度が決まっているから。ケーブル単体は見た目で判別できない。

信号	必要規格
4K 60Hz SDR	HDMI 2.0 / DisplayPort 1.2
4K 60Hz HDR	HDMI 2.0a / DisplayPort 1.4
4K 120Hz HDR	HDMI 2.1 / DisplayPort 1.4 (DSC)

モニター付属ケーブルでも非対応のことが稀にある。買ってすぐ「色が薄い」「FHDにしかならない」場合は、まずケーブルとPC側の出力端子規格を疑う。

オススメ機種（用途別）

以下は執筆時点で選定した参考機種。2026 視点では後継モデル / 同等価格帯の最新製品を必ず確認すること。

sRGB 100% / 文章・写真用途 — I-O DATA 27インチ 4K

sRGB 100% カバーで写真の色味確認にも使える27インチ4K。非光沢でデスク照明の映り込みが少ない。VESA対応でアームに付け替えられる。

項目	スペック
サイズ	27インチ
パネル方式	ADS（IPS相当）
解像度	4K (3840×2160)
表面	非光沢
色再現度	sRGB 100%
HDR	HDR10 対応
VESA	対応

NTSC 90% 前後 / 動画・映像編集向け — I-O DATA 28インチ 4K

NTSC 88%で映像系の色域に振った28インチ。サイズが大きいぶん4Kの解像感が活きる。

項目	スペック
サイズ	28インチ
パネル方式	IPS
解像度	4K (3840×2160)
表面	非光沢
色再現度	NTSC 88%
HDR	HDR10 対応
VESA	対応

よくある質問

Q. 4Kモニターはどんな人に必要ですか？ A. 写真・動画編集、4K映像視聴、28インチ以上の大画面で作業領域を広げたい人。逆に文章中心や競技ゲーム用途ならWQHDで足りる。

Q. 4Kモニターのスケーリングは必要ですか？ A. Windows / macOS 共に 27インチ以下の4Kでは125〜150%のスケーリングがほぼ必須。スケーリングを使う前提なら、最初からWQHDのほうが素直に映ることが多い。

Q. 21:9 ウルトラワイドと 16:9 の4K、どちらがいいですか？ A. 横に広い作業領域がほしいなら21:9のWQHD相当（3440×1440）が扱いやすい。縦の情報量と高精細さを取るなら16:9の4K。用途で選ぶ。

Q. HDMIケーブルは何を選べばいいですか？ A. 4K HDR を出すなら HDMI 2.0a 以上、4K 120Hz を狙うなら HDMI 2.1。モニター付属ケーブルが対応していないことが稀にあるので、スペックを確認する。

まとめ

4Kモニターは「精細さが成果物に直結する人」のための機材。当てはまるなら、画面サイズ28インチ以上 / HDR対応 / 色再現度90%前後 / IPSパネルの4点を確認すれば外しにくい。

当てはまらないなら、WQHDのほうが価格・GPU負荷・スケーリングの手間で優位。判断の起点は「4Kだから買う」ではなく「自分の用途に4Kの解像感が要るか」のほうに置きたい。

液晶タブレットの選び方 — 14〜16インチ・色域・応答速度・視差の4点で決める

Thu, 18 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。骨子（選び方の観点）は今も使えるが、具体的なスペック数値や価格帯は2021年当時の市況がベース。最新モデルでは数値が改善しているため、購入前に各メーカーの公式スペック表を確認すること。スペック表記は執筆当時の公称値で、最新の公式表記とは差分があり得る。

液晶タブレット（以下「液タブ」）は、ペンタブ（板タブ）からの買い替え候補としてここ数年でかなり身近になった。Wacom 一強だった頃と比べると、XP-Pen や HUION といったメーカーの選択肢が増え、価格レンジも幅広い。

ただ選択肢が増えた分、「結局どれを買えばいいのか」が見えにくい。この記事は、液タブを選ぶときに押さえるべき観点と、板タブ・iPad との違いを整理する。

結論 — サイズ・色域・応答速度・視差の4点で決める

短い答え: 液タブ選びは以下の4点で決まる。残りの仕様は「あれば嬉しい」レベル。

サイズ: 14〜16インチ（描きやすさと机の専有面積のバランス点）
色域: 印刷物用途なら Adobe RGB / NTSC 90%前後、Web 中心なら sRGB 100%前後
応答速度: 14〜25ms 程度（公称）
視差（パララックス）: フルラミネーション加工有りを選ぶ

逆に言うと、メーカーが Wacom かどうかや筆圧レベル（8192段階など）はこの4点ほど致命的には効かない。最新世代の液タブはどれも筆圧レベルは8192以上が標準（公称）。

用途別の判断 — 板タブ・iPad と比べてから決める

短い答え: 「液タブが最善」とは限らない。板タブと iPad には液タブにない長所がある。

紙のように描きたい → 液タブ

画面に直接ペンを置いて描けるのが液タブの本質的な価値。アナログ作画からの移行や、線画の取り回しが多い人ほど恩恵が大きい。

ただし接続ケーブルが多く、外への持ち出しには向かない。常時机に置きっぱなしになる前提で考える。

安く始めたい・腕の負担を減らしたい → 板タブ

板タブ（ペンタブ）は手元と画面が分離する分、慣れが要る。ただし慣れてしまえば腕を持ち上げずに描けるので、長時間作業では疲労が少ない。

価格も液タブの1/3〜1/5に収まる（同メーカー同サイズで比較した場合）。「絵を描き始めたばかり」「予算を抑えたい」なら板タブで十分。

外でも描きたい・iPad 持ち → iPad + Apple Pencil

iPad + Apple Pencil は事実上「持ち運べる液タブ」。Procreate / Clip Studio Paint for iPad の完成度も上がっている。

弱点はソフトウェア面で、フォトショなど一部の PC 専用ツールが使えない。PC ベースのワークフローに組み込むときは追加の手間が要る。

スペックの観点 — それぞれの数値が何に効くか

短い答え: スペック表の数値はどれも独立で見ても意味が薄い。「自分の使い方で何が起きるか」と紐付けて読む。

サイズは14〜16インチが折り合い点

サイズが大きいほど描きやすいが、机の専有面積と価格が比例で上がる。

サイズ	幅×高さ目安	向く用途
〜13インチ	約28×17cm	携帯前提、サブ機
14〜16インチ	約31×20cm	大半のイラスト・漫画作業
21インチ以上	約47×27cm	商業作画、机が広い人

13インチ未満は長時間描くと手が窮屈になりやすい。21インチ以上は腕を大きく動かす必要があり、価格も10万円超になる。

色域は「どこに出すか」で決める

色域（Adobe RGB / NTSC / sRGB のカバー率）は「現実の色をどこまで再現できるか」を示す指標。

印刷物に出す: Adobe RGB または NTSC 90%前後。印刷の色域は sRGB より広いため、ここで合わせないと納品データと印刷物の色がズレる
Web / SNS 中心: sRGB 100% で十分。むしろ Adobe RGB 機で sRGB 環境を見ると色が浅く見えることがある

「迷ったら高色域」と言われがちだが、出力先が Web 中心なら過剰スペックになる。

応答速度は14〜25ms あれば描画には支障なし

応答速度は「ペンを動かしてから画面に反映されるまでの時間」に効く部分。

応答速度 14〜25ms（公称）
レポートレート 200RPS 以上が現行モデルの標準（公称）

これより遅い旧モデルは、描画の遅延がそのまま線のヨレに出る。

視差はフルラミネーション加工で消える

視差（パララックス）は「画面のガラス面と発光面の間に隙間があることで、ペン先と線が少しズレて見える」現象。

「フルラミネーション加工」または「ラミネーション」と明記されているモデルは、この隙間が極小化されている。中古や格安モデルは加工なしのものが残っているので、製品ページのスペック欄を確認する。

比較: 液タブ vs 板タブ vs iPad

短い答え: 「机に据え置きで紙感」なら液タブ、「予算重視・長時間作業」なら板タブ、「持ち運び」なら iPad。

観点	液タブ	板タブ	iPad + Apple Pencil
価格目安	4〜10万円	1〜3万円	10万円〜（本体+ペン）
描き心地	画面に直接	手元と画面が分離	画面に直接
持ち運び	× ケーブル多数	△ 板単体は軽い	◯
長時間作業	腕を上げて描くので疲れる	慣れれば最も楽	iPad の重さ次第
ソフト互換	PC アプリ全般	PC アプリ全般	iPad 版に限定
初期投資	中〜高	低	高

液タブの強みは「画面に直接描ける + PC のソフトをそのまま使える」点。板タブと iPad のいいとこ取りに見えるが、価格と据え置き前提というコストを払う。

よくある質問

Q. Wacom じゃないと駄目ですか？ A. 駄目ではない。Wacom は安定性とドライバの完成度で評価が高いが、XP-Pen や HUION の現行モデルも実用域に入っている。価格差を許容できるかと、サポート体制をどこまで重視するかで決める。

Q. 板タブから液タブに買い替える価値はありますか？ A. 「画面と手元が連動しない違和感」が消えるのは大きい。一方で「腕を上げて描くので長時間だと疲れる」「ケーブルが増えて机が散らかる」というデメリットもある。板タブで作業に支障がないなら、急いで買い替える必要はない。

Q. 筆圧レベルは何段階あればいいですか？ A. 現行モデルはほぼ8192段階以上で横並び（公称）。この数値で機種を選ぶ場面はほとんどない。それより色域と視差を優先する。

Q. iPad Pro があれば液タブは要らないですか？ A. 用途次第。iPad の絵描きアプリで完結する人には不要。一方、Photoshop や After Effects など PC 専用ツールを併用するなら、PC ワークフローに直結する液タブの利点は残る。

まとめ

液タブ選びの軸は「サイズ14〜16インチ・色域は出力先で決める・応答速度14〜25ms・視差はラミネーション加工で消す」の4点。残りの仕様差は描画体験には大きく効かない。

そのうえで、「机に据え置きで PC アプリをそのまま使う」なら液タブ、「予算と腕の負担」なら板タブ、「持ち運び」なら iPad、と用途で選ぶのが現実的。

イラスト用モニターの選び方も別記事で整理しているので、ディスプレイ側の観点もあわせて検討するときに参考になる。

関連記事: イラスト用モニターの選び方

イラスト用モニターの選び方 — 色域・パネル・サイズの3点だけ押さえる

Wed, 17 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。骨子（選び方の観点）は今も有効だが、製品スペック・価格・ツールの UI は執筆当時（2021年）のまま。具体的な商品リンクは公開前に最新モデルへ差し替える。

ペンタブレットや液晶タブレットの価格が落ち着き、外付けモニターも合わせて整える人が増えた。とはいえ、家電量販店の棚にはゲーミングも 4K HDR も混ざっていて、どれがイラスト向けなのか分かりにくい。

この記事は、イラスト制作用モニターを選ぶときに見るべき点を5つに絞ってまとめる。ゲーミングや写真現像のような尖った要件は外し、ペンタブ / 液タブと組み合わせて長時間描くための条件を中心にした。

結論 — 見るべきは5点、ゲーミングと 4K HDR は不要

短い答え: イラスト用モニターは「色域 / パネル / サイズ / 表面 / VESA」の5点だけ押さえれば足りる。ゲーミング向けの高リフレッシュレートや HDR 対応は、イラスト制作では効かない。

理由は、イラスト用途で効くのは「色の見え方」と「長時間見て疲れないか」の2軸だから。動きの滑らかさ（リフレッシュレート）やコントラスト（HDR）にコストを振っても、線画や塗りの品質は上がらない。

確認する5点:

色域: どこに公開するかで変える（ネット中心 / 印刷込み）
パネル方式: IPS（または同等の ADS など）
画面サイズ: 22〜24インチ
表面処理: 非光沢（ノングレア）
VESA 対応: モニターアームを使う / 将来使う可能性があるなら必須

逆に言うと、この5点が揃っていれば「イラスト向け」をうたっていない汎用モニターでも問題なく使える。

色域は「誰に向けて描くか」で決める

短い答え: ネット公開中心なら sRGB 100%、印刷を含めるなら Adobe RGB / NTSC 90% 前後 を目安にする。色域は高ければ高いほどいい、ではない。

理由は、見る側のデバイス側の色域がバラバラだから。閲覧者のスマホやモニターが sRGB 相当なら、こちらが Adobe RGB で描いても伝わるのはおおむね sRGB の範囲に圧縮されたものになる。

ネット公開中心なら sRGB 100%

Web に出すイラスト・SNS 投稿・配信のサムネイルなどは、閲覧環境を sRGB と想定するのが現実的。製品スペックに「sRGB 100%」または記載なし（標準的な発色）と書かれていれば足りる。

印刷・同人誌・グッズ制作を含めるなら Adobe RGB / NTSC 90% 前後

印刷物は CMYK で再現されるが、入稿前のチェックで Adobe RGB に近い色域のモニターがあると差分の見当がつきやすい。スペック上「Adobe RGB カバー率 90% 前後」「NTSC 比 90% 前後」を目安にする。

液タブを併用するなら役割を分ける

液晶タブレットを使うなら、液タブ側に色再現の高いモデルを置き、デスクの外付けモニターは普及帯の sRGB モデルでよい、という分け方がコストと閲覧側の感覚の両方に合う。

パネル方式は IPS（または同等の ADS）

短い答え: イラスト用途では IPS パネルを選ぶ。視野角と色の安定性が、ペン作業の長時間視聴に向いている。

理由は、TN パネル系は応答速度に振った設計で、上下方向に視点が動くと色が変わってしまうから。タブレットを膝に置く、ペンを持つ手を頬杖につく、などの姿勢で色がブレるとレタッチ判断が狂う。

I-O DATA などが採用する「ADS」方式は IPS と同等の特性で、スペックシート上「ADS / IPS 系」と書かれていれば候補に入る。VA パネルはコントラスト重視で写真・動画向きで、線画のエッジ視認性では IPS のほうが扱いやすい。

画面サイズは 22〜24インチ

短い答え: 22〜24インチが普及帯で、価格・設置性・作業領域のバランスがいい。

理由は、27インチ以上になると視線移動が増えて目が疲れやすく、価格も一段上がる。一方で 21.5 インチ未満は作業領域が狭く、パレットやレイヤーパネルを置くと描画領域が圧迫される。

サイズの実寸目安（16:9 想定）:

23.8 インチ: 幅約53cm / 高さ約30cm
21.5 インチ: 幅約48cm / 高さ約27cm

設置前に確認する点:

デスク幅が モニター幅 + 5cm 以上あるか（フチが厚い製品もあるため余裕を持つ）
奥行きはスタンドのフット部分を含めて 20cm 以上あるか
視距離 50〜70cm を確保できるか

表面処理は非光沢（ノングレア）

短い答え: 長時間描くなら非光沢を選ぶ。光沢は照明や自分の顔の映り込みが視界に入り、線の判別を妨げる。

理由は、イラスト制作は同じ画面を数時間見続ける作業で、映り込みによる微小な視線移動が積み重なると疲労につながるため。

光沢のメリットは発色の鮮やかさと黒の締まり。写真鑑賞や動画視聴には向くが、ペンタブ作業ではトレードオフが合わない。

VESA 対応はモニターアームの前提条件

短い答え: モニターアームを使う、または将来使う可能性があれば VESA マウント対応のモデルを選ぶ。VESA 非対応だと後付けのアーム化ができない。

理由は、モニターアームの取り付け面は VESA という共通規格（100×100mm が一般的）に従っているため。非対応のスタンド一体型モデルだと、机の上のスペース確保や高さ調整の自由度が下がる。

液タブを手前に置きたい構成では、外付けモニターをアームで浮かせるとデスクの奥行きが活きる。

イラスト向け仕様 vs 一般用途モニターの違い

イラスト制作で効く仕様と、汎用モニターでよくある仕様を並べておく。

観点	イラスト向け推奨	一般用途 / ゲーミングでの典型
色域	sRGB 100% 以上（印刷込みなら Adobe RGB 90%）	sRGB 95% 前後で十分
パネル方式	IPS / ADS	TN（ゲーミング）/ VA（汎用）も多い
画面サイズ	22〜24インチ	24〜27インチ
表面処理	非光沢	光沢も選択肢に入る
リフレッシュレート	60Hz で十分	144Hz 以上（ゲーミング）
HDR	不要	動画・ゲームでは有効
VESA 対応	あると良い	モデルによる

候補モデル（参考）

以下は執筆当時の参考モデル。後継機や同等価格帯の最新モデルを必ず確認すること。

sRGB 100% 帯 — PHILIPS 23.8 インチ

項目	スペック
大きさ	23.8インチ
表示形式	IPS
解像度	フル HD
表面	非光沢
色域	sRGB 102%
VESA	対応

sRGB 102% / 23.8 インチ / IPS / 非光沢で、5点の条件を満たす。

Adobe RGB / NTSC 90% 帯 — I-O DATA 23.8 インチ

項目	スペック
大きさ	23.8インチ
表示形式	ADS（IPS 系）
解像度	フル HD
表面	非光沢
色域	Adobe RGB 90%
VESA	対応

Adobe RGB 90% / 23.8 インチ / ADS / 非光沢。印刷を視野に入れるならこちら。

よくある質問

Q. 4K モニターはイラスト制作で必要ですか？ A. 必須ではない。フル HD で描く絵を 4K で表示しても解像度は変わらず、UI が小さくなる分の拡大調整が要る。4K の恩恵が大きいのは写真現像や動画編集寄りの作業で、ペンタブ中心ならフル HD で過不足ない。

Q. カラーキャリブレーターは買ったほうがいいですか？ A. 印刷物の入稿や商業案件を継続して扱うなら導入候補に入る。趣味〜SNS 公開中心であれば、まずは sRGB 100% のモニターを工場出荷時設定で使い、必要を感じたタイミングで検討すれば足りる。

Q. ゲーミングモニターをイラストにも使えますか？ A. パネルが IPS で非光沢、色域が sRGB 100% 前後であれば兼用できる。ただしリフレッシュレートや応答速度の高さは制作品質には効かないため、その分の価格上乗せをどう見るかという話になる。

Q. ノート PC の内蔵ディスプレイで描くのは無理がありますか？ A. 始めるだけなら問題ない。ただしモバイル機の標準パネルは色域が狭く（sRGB 60〜70% 帯のモデルもある）、長期的には外付けの sRGB 100% モニターを足したほうが色判断のブレが減る。

まとめ

イラスト用モニターは、5点を見る:

色域は公開先で決める（ネットなら sRGB 100% / 印刷込みなら Adobe RGB 90% 前後）
パネルは IPS / ADS
サイズは 22〜24 インチ
表面は非光沢
VESA 対応

ゲーミング向けの 144Hz や HDR、4K の解像度は、イラスト制作の品質にはほぼ寄与しない。価格を抑えたければ、これらを外した普及帯モデルから選べば十分。

液タブを使う場合は、液タブ側に色再現の高いモデルを置き、外付けモニターは閲覧側の感覚に寄せる、という分担にすると無駄が少ない。

PC モニターの選び方 — 失敗しない3点と、お好みで1点

Mon, 15 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。骨子（選び方の3点）は今も有効だが、製品リンクと相場感は執筆当時（2021年）の情報。価格・型番は最新を確認のうえ差し替えること。

リモートワークが定着して、自宅に PC モニターを買い足す人が増えた。家電量販店に並ぶ製品は1万円台から10万円超まで幅があり、何を基準に選べばいいか分かりにくい。

オフィス用途で長時間使うだけなら、判断軸は3点に絞れる。表示方式・サイズ・表面処理。スピーカー内蔵は「お好み」枠で、基本的には不要だ。

結論 — 押さえるのは3点、お好みで+1点

短い答え: メーカーや細かいスペックを比較しなくても、以下の3点だけ満たしていれば、オフィス用途で困るモニターはほぼ買わずに済む。

表示方式: IPS（仕上がり重視）か VA（価格重視）
サイズ: 22〜24インチ
表面処理: 非光沢（ノングレア）

お好みで足すのが スピーカー内蔵の有無。配線をひとつでも減らしたいならアリ、音質を求めるなら別買いのほうが現実的。

メーカーは特に気にしなくていい。最近は各社の品質差が縮まっており、初期不良対応さえできれば実害は少ない。

表示方式は予算で決める — VA か IPS

短い答え: 価格優先なら VA、見え方を優先するなら IPS。この2つで選んでおけば、オフィス用途の表示方式選びは終わる。

理由は、見え方の差の大半が表示方式（パネル種別）で決まるから。応答速度や色域などの細かい数値は、ゲームや写真編集をしないなら体感差が出にくい。

価格差はおおむね VA → IPS で1〜2万円ほど。失敗を避けたいなら IPS を選んでおくと安全寄りに倒れる。

VA — 安く、黒が締まる

VA は同サイズ帯で最安クラスが多い。黒の表現は強く、暗いシーンを多く扱う動画視聴と相性がよい。

弱点は視野角。正面から外れると色が薄く見えるので、テレビ用途や複数人で覗き込む場面には向かない。1人で正面に座って使う想定なら気にならない。

IPS — 色がきれい、視野角が広い

IPS は色の見え方が安定する。横から見ても色が崩れにくいので、複数人での確認や、デスクのレイアウト上モニターを斜めから見る配置でも扱いやすい。

価格は VA より1〜2万円ほど上がる。仕事で長時間向き合うなら、ここに払う価値は感じやすい。

VA と IPS の比較

観点	VA	IPS
価格	安い	やや高い
黒の表現	締まる	普通
視野角	狭い（正面向け）	広い
色の安定	やや崩れる	安定
向く用途	1人で正面、価格優先	仕事、複数人、レイアウト自由度

サイズは22〜24インチ — オフィス用途のスイートスポット

短い答え: 22〜24インチが、机に置きやすく文字も読みやすい範囲。これより小さいと作業がきつく、大きいと机を圧迫する。

理由は、22〜24インチが幅およそ49〜53cm、高さ27〜30cmに収まり、一般的な PC デスクの奥行きと相性がよいから。オフィスや学校で広く採用されているのもこのレンジだ。

机に置く前に、設置幅 +5cm 程度の余裕で寸法を確認しておくと安心。最近のモデルはフチが薄いが、古いモデルや業務用にはフチの厚いものもあるので、商品ページの実寸表記を必ず見る。

「もっと大きいほうがいい」は別問題

27インチ以上は表示領域が広く魅力的に見える。ただし距離が近いと視線移動が増えてかえって疲れる。机の奥行きが60cm未満なら、まずは24インチで様子を見るのが無難。

表面処理は非光沢（ノングレア）

短い答え: オフィス用途なら非光沢一択。光沢は照明や窓の映り込みが出て、長時間使うと目が疲れやすい。

理由は、光沢面が周囲の光を反射するため、輝度を上げる必要が出てくるから。輝度を上げると目への負担も増える。スマートフォンが光沢なのは、屋外で短時間使う前提だからで、デスクで長時間向き合うモニターとは前提が違う。

写真や動画の最終チェックを自宅で行う、といった用途でなければ、非光沢を選んでおいて困らない。

スピーカー内蔵は基本いらない

短い答え: モニター内蔵スピーカーは音質が中途半端になりがち。ノート PC や外付けスピーカーで出したほうが満足度は高い。

理由は、内蔵スピーカーは筐体の厚みに制約があり、価格帯を抑えた製品では音作りに余裕がないから。会議の声出しなど「聞こえればいい」用途ならアリだが、音楽や動画を腰を据えて聞く用途には弱い。

内蔵が向く人 / 向かない人

配線を1本でも減らしたい、会議用に音が出ればいい → 内蔵アリで OK
音楽・動画を日常的に聞く、音にこだわりたい → 内蔵なしを選び、別途スピーカーを買う

数千円帯の USB / Bluetooth スピーカーでも内蔵を上回ることが多い。

条件を満たすモデルのスペック例

以下は具体的な製品名ではなく「この条件を満たすモデルを選ぶ」という指標。価格や型番は購入時に最新を確認すること。

IPS — 23インチクラス

23インチ・IPS・非光沢を満たすエントリー帯の狙いどころ。価格を抑えつつ仕上がりを取りたいなら、このスペックを基準にする。

項目	スペック
サイズ	23インチ
表示方式	IPS
解像度	フル HD
表面	非光沢
スピーカー	なし
VESA マウント	非対応

VESA 非対応なのでモニターアームを使う予定があるなら別モデルを検討する。

VA — 23.6インチクラス

23.6インチ・VA・非光沢で、VESA 対応のスペック。価格を抑えたい、将来モニターアームを導入する余地を残したい場合の狙いどころ。

項目	スペック
サイズ	23.6インチ
表示方式	VA
解像度	フル HD
表面	非光沢
スピーカー	なし
VESA マウント	対応

よくある質問

Q. フル HD と 4K、どちらを選ぶべきですか？ A. オフィス用途・23〜24インチならフル HD で十分。4K はサイズが27インチ以上で生きるが、表示スケーリングや GPU 性能の制約が出る場合がある。最初の1枚はフル HD が無難。

Q. 曲面モニターは仕事に向きますか？ A. 1人で正面に座って広い表示領域を確保したい、複数ウィンドウを横並びにしたい場合は有効。文字中心のオフィス用途では恩恵が小さく、価格も上がる。最初の1枚としては平面で十分。

Q. ノート PC につなぐとき、注意点はありますか？ A. ノート PC 側の映像出力端子（HDMI / DisplayPort / USB-C のどれか）と、モニター側の入力端子を必ず一致させる。USB-C 1本で給電と映像をまかなえるモデルなら配線が減って快適。

Q. モニターアームは必要ですか？ A. 必須ではないが、机の奥行きが浅い・高さ調整したい場合は効果が大きい。導入する可能性があるなら、購入時点で VESA 対応モデルを選んでおく。

まとめ

オフィス用途の PC モニターは、表示方式・サイズ・表面処理の3点で選べば困らない。

価格優先なら VA、仕上がり優先なら IPS。サイズは22〜24インチ、表面は非光沢。スピーカー内蔵は基本不要で、必要なら別買いのほうが満足度が高い。

画質に強くこだわる人や、ゲームで応答速度を詰めたい人には別の選び方がある。それ以外なら、この3点で十分にハズレは避けられる。

VuePress でブログを公開するまでのロードマップ — 2021 年の手順と 2026 年に転用できる考え方

Sun, 14 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。手順 UI のスクリーンショットは 2021 年当時のもので、Netlify / お名前.com の画面は現行 UI と差分がある。VuePress 1.x 自体は新規構築に向かないため、本文は「2021 年の構築記録 + 4 段ロードマップとして転用できる骨子」という二重構成で書き直してある。

2021 年当時、Aulvem の前身ブログは VuePress 1.x で組み、GitHub にソースを置いて Netlify でビルド・配信し、お名前.com で取った独自ドメインを当てていた。よくある「無料でブログを公開する」記事を読みながら手を動かしたが、どこで何をやっているのかの全体像が見えるまでに時間がかかった。

この記事は、当時の自分が最初に欲しかった「全体ロードマップ + ステップ別の責務」をまず提示する。VuePress 1.x はもう新規採用の選択肢ではないが、ロードマップ自体は Astro + Cloudflare Pages の組み合わせにそのまま転用できる。

VuePress のディレクトリ構成そのものについては別記事に分けてある（VuePress/blog のディレクトリ構成 — 2021 年の構築メモ）。ここでは「個別ファイルの中身」ではなく「サイト全体を公開状態に持っていくまでの段取り」に絞る。

短い答え — 4 段ロードマップに分けて 1 段ずつ片付ける

短い答え: VuePress ブログを独自ドメインで公開するまでは、(1) ローカル開発 → (2) GitHub にソースを置く → (3) Netlify が自動ビルドして配信 → (4) お名前.com のネームサーバーを Netlify に委任、の 4 段に分けて 1 段ずつ片付けるのが一番早い。

理由は責務の分離。1 つのサービスにまとめると「どこで失敗したか」が分かりづらくなる。書く・保管する・ビルドする・公開する、を別レイヤーに置くと、トラブル時の切り分けがしやすい。

全体図にするとこうなる。

[ローカル PC]
   │ git push
   ▼
[GitHub] ──── ソースの正本
   │ webhook
   ▼
[Netlify] ──── ビルド & 静的配信（xxx.netlify.app）
   │ DNS (ネームサーバー委任)
   ▼
[お名前.com のドメイン]
   │ 独自ドメインで公開
   ▼
[読者]

注意点: この 4 段は VuePress 固有ではない。Astro でも Hugo でも、Markdown を静的 HTML に変換して配信するタイプの SSG なら同じ並びになる。VuePress 部分は (1) と (3) のビルド命令にしか出てこない。

用語: SSG と Jamstack — このロードマップが成り立つ前提

SSG（Static Site Generator）: Markdown や JSON をビルド時に静的 HTML に変換するツールの総称。VuePress / Astro / Next.js (output:static) / Hugo / Jekyll などが該当する。リクエスト時にサーバーで動的に組み立てる WordPress 等の CMS と対になる概念。

Jamstack: JavaScript / API / Markup（プリビルドされた静的ファイル）の頭文字。SSG で作った HTML を CDN に置き、必要な動的処理だけ外部 API で補う構成のことを指す。Netlify はこの Jamstack を前提に設計されたホスティング。

このロードマップが成り立つのは、出力物が「単なる静的ファイル」だからこそ。GitHub にソースだけ置けば Netlify がビルドし直して CDN に撒く、というシンプルさが Jamstack 側の前提に支えられている。

ステップ 1 — ローカルで VuePress プロジェクトを開発・執筆する

短い答え: ローカルで VuePress プロジェクトを開発・執筆するフェーズでは、vuepress dev src でホットリロードしながら Markdown と Vue コンポーネントを書く。

理由は反復速度。デプロイ後に直すより、ローカルで完結する方が一桁速い。ビルド時間も短いので、書きながら整える運用が現実的だった。

具体的には次の構成で開発した。

src
├─ _posts                   各記事 Markdown
│  └─ category
│     └─ page.md
└─ .vuepress
   ├─ components            記事用コンポーネント vue
   ├─ public                画像・robots.txt
   ├─ theme                 layouts / components / styles
   ├─ config.js             VuePress 本体の設定
   └─ enhanceApp.js         Vue プラグインの差し込み口

_posts/ が記事、.vuepress/ がフレームワーク設定とテーマ、という二分割。詳細はVuePress/blog のディレクトリ構成に書いた。

注意点: 開発中は vuepress dev src --host 0.0.0.0 --port 8080 で LAN 内の別端末から開いてスマホ表示を確認できる。Markdown の見た目はデスクトップだけ見ていると詰めが甘くなりやすい。

ステップ 2 — GitHub にリポジトリを作りソースをプッシュする

短い答え: GitHub にリポジトリを作りソースをプッシュするフェーズでは、空のリポジトリを作り、ローカルから git remote add → git push -u origin main でソースだけを上げる。

理由はソースとビルド成果物の分離。dist/ や node_modules/ を Git に乗せると履歴が肥大化して、Netlify 側で再ビルドする意味も薄れる。

具体的には .gitignore で以下を除外していた。

node_modules/
src/.vuepress/dist/
src/.vuepress/.cache/
src/.vuepress/.temp/
.env
.env.local

ビルド成果物は Netlify が毎回作り直すので、リポジトリには src/ と package.json / package-lock.json だけ入っていれば足りる。

注意点: 公開リポジトリにする場合、API キーやアクセストークンを誤コミットしないこと。当時は GitHub Secrets と Netlify の環境変数のどちらに置くかで迷ったが、結論「ビルド時にしか使わない値は Netlify 側、ランタイムから漏れる前提なら持たない」のが安全。

ステップ 3 — Netlify にリポジトリを接続して自動ビルドさせる

短い答え: Netlify にリポジトリを接続して自動ビルドさせるフェーズでは、Netlify の Add new site → Import an existing project で GitHub リポジトリを選び、ビルドコマンドと公開ディレクトリを指定する。

理由は webhook 駆動の自動化。GitHub への git push を Netlify が検知して、毎回最新ソースから vuepress build を回し直してくれる。手で npm run build → サーバーへ FTP、という昔ながらの流れがまるごと消える。

具体的な設定は以下だった。

項目	値
Branch to deploy	`main`
Build command	`vuepress build src`
Publish directory	`src/.vuepress/dist`
Node.js version	14 系（環境変数 `NODE_VERSION` で固定）

Netlify ログイン後の流れは、ざっくり以下のとおり（UI は 2021 年当時のもの）。

リポジトリ選択後、ビルド設定で vuepress build src と src/.vuepress/dist を入力するとデプロイが走る。

注意点: 初回ビルドは Node のバージョン違いで落ちることが多い。NODE_VERSION 環境変数を 14 のように固定するか、リポジトリ直下に .nvmrc を置いておくと事故が減る。詳しい手順はVuePress / 静的サイトを Netlify にデプロイするに分けている。

ステップ 4 — お名前.com で独自ドメインを取得する

短い答え: お名前.com で独自ドメインを取得するフェーズでは、希望のドメイン名を検索 → サーバー契約は「利用しない」を選択 → 決済する、までで完結する。サーバーを同時契約する必要はない。

理由は責務分離。お名前.com の役割は「ドメインの所有」だけで、ホスティングは Netlify が担う。サーバー契約までセットで案内されがちだが、Jamstack 構成では不要。

実画面はこうなっていた。

サーバー選択欄では「利用しない」を選んで進む。

注意点: Whois 情報公開代行は無料の範囲で必ず有効化する。個人情報がそのまま Whois に載るのを避けるため。更新料はドメインによって新規登録料より高くなる場合があるので、長期運用前提なら .com / .net など標準的な TLD の方が後で読みやすい。

ステップ 5 — Netlify とお名前.com をネームサーバー委任でつなぐ

短い答え: Netlify とお名前.com をネームサーバー委任でつなぐフェーズでは、Netlify 側で Add custom domain → Set up Netlify DNS を実行し、表示された 4 つのネームサーバーをお名前.com Navi の「ネームサーバー変更」に貼り付ける。

理由は DNS の管理を Netlify に寄せるため。ネームサーバーを委任すると A / CNAME レコードや SSL 証明書（Let’s Encrypt）の発行を Netlify が肩代わりしてくれる。お名前.com 側で自分でレコードを書く必要がなくなる。

Netlify の overview から Domain settings を開く。

Add custom domain を進めると、最終的に 4 つのネームサーバーが表示される。

お名前.com Navi にログインし、対象ドメインの「ネームサーバーの変更」で「その他のネームサーバーを使う」を選び、控えた 4 つを貼り付ける。

反映は数分〜最大 48 時間。半日経って独自ドメインで開けない場合、別ネットワーク（モバイル回線など）からアクセスして DNS キャッシュの影響かどうかを切り分ける。詳しい注意点はNetlify にお名前.com の独自ドメインをつなぐに分けて書いた。

注意点: ネームサーバー委任後は、お名前.com 側の DNS レコード設定画面はもう触らない。Netlify DNS が正本になるので、サブドメインの追加やメール用 MX レコードもすべて Netlify の DNS Records UI から行う。

比較表 — 2021 年の VuePress 構成と 2026 年の Astro 構成

ロードマップ自体は変わらないが、各レイヤーで選ぶ道具は 5 年で入れ替わった。Aulvem 自身も VuePress から Astro に移行している。

レイヤー	2021 年: VuePress 構成	2026 年: Astro 構成（Aulvem 現行）
ローカル開発	VuePress 1.x + Node 14 系	Astro 5 + Node 20 系
記事の型	frontmatter（型なし）	content collections + zod スキーマ
Git ホスティング	GitHub	GitHub
CI / ビルド & 配信	Netlify	Cloudflare Pages
ドメインレジストラ	お名前.com	お名前.com or Cloudflare Registrar
DNS 管理	Netlify DNS	Cloudflare DNS
SSL 証明書	Let’s Encrypt（Netlify 自動発行）	Cloudflare 自動発行
画像配信	Netlify からそのまま	Cloudflare R2 + 画像最適化

ここで言いたいのは新しい方が「優れている」ではなく、4 段のロードマップは変わらず、各段の実装だけ差し替えていけばよい、ということ。VuePress から Astro への移行も、レイヤーごとに区切って 1 つずつ置き換える形で進めた。

注意点: Netlify は 2026 年でも有効な選択肢で、Forms / Identity / Edge Functions など独自機能を使う前提なら今も第一候補になる。Cloudflare Pages との優劣はユースケース次第。

よくある質問

Q. VuePress 1.x で今からブログを始める意味はあるか？ A. 新規ブログの第一候補としては勧めない。VuePress 1.x はメンテが実質止まっており、依存パッケージの脆弱性対応も期待しづらい。Markdown 中心の静的ブログなら Astro + content collections や VitePress の方が学習コストに見合う。Vue を維持したい個人的な理由がある場合のみ、VitePress を候補に入れる。

Q. GitHub と Netlify を分ける必要は本当にあるか？ A. 原則ある。GitHub は「ソースの正本」、Netlify は「ビルド済み HTML の配信」と責務が違うため、片方が落ちてももう片方が残る。GitHub Pages や Cloudflare Pages のように両方を兼ねるサービスもあり、その場合は一元化してもよい。ただし Pages 系は CI のカスタマイズに制約があるので、ビルド工程を細かく組みたい場合は分けたほうが楽。

Q. ドメイン取得を後回しにしても公開はできるか？ A. できる。Netlify は無料で xxx.netlify.app のサブドメインを発行するので、独自ドメインを買う前にビルドと内容の確認まで進められる。実装上、ドメイン接続は最後に切り替えるのが安全。先にドメインを買って待ち時間が長くなるより、サイトが動くことを確認してから DNS をいじる方が事故が少ない。

Q. 2026 年に同じ構成を組むなら何に置き換える？ A. VuePress → Astro、Netlify → Cloudflare Pages、お名前.com → そのまま（または Cloudflare Registrar）が個人的な置き換え案。ロードマップの 4 段（ローカル開発 → Git ホスティング → ビルド & 配信 → DNS 接続）はそのまま流用できる。逆に言うと、この 4 段を意識せずにサービス名だけ覚えても、別のサービスに移るときに毎回最初からやり直すことになる。

まとめ

VuePress でブログを独自ドメインで公開するまでは、書く場所・置く場所・ビルドする場所・配信する場所を別々のレイヤーに分けて、1 つずつ片付けるのが結局いちばん早かった。

2026 年現在、VuePress 1.x のままで新規構築する人は多くないと思う。それでも、ローカル → GitHub → ビルド & 配信 → DNS という 4 段の責務分割は、Astro + Cloudflare Pages の今でも同じ形で生きている。具体的なコマンドや UI のスクリーンショットは古くなっても、骨子は転用できるという例として残しておく。

ブログ用のノートパソコンの選び方 — 5万円台で十分、外で書くなら重さとバッテリーで決まる

Sat, 13 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。執筆当時（2021年）の機種選びをベースにしているため、具体的な商品リンクは確認のうえ最新モデルへ差し替えること。骨子（選び方の観点）は今も有効。

ブログを始めようとすると最初に困るのが「どんなパソコンを買えばいいか」。スマホだけで書くのはしんどいし、会社支給機を私用に使うのもまずい。

この記事は、ブログ専用のノートパソコン選びを「家で書くか / 外で書くか」を軸にまとめる。読み終える頃には、自分が選ぶべき1台の輪郭が見えているはず。

結論 — 直近5年のモデルなら基本どれでもOK、ただし3点だけ確認

短い答え: ブログ用途なら高性能 CPU や大容量メモリは要らない。直近5年（2021年から見て）に発売されたノートパソコンなら、ライティング用途では性能は十分。

ただし以下の3点だけは購入前に確認する:

書く場所: 家中心か、外でも書くか — 重さとバッテリーの要件が変わる
キーボード配列: 日本語（JIS）配列か — 英語配列だと全角半角切り替えが面倒
画面サイズ: 14インチ以上 — 12インチ未満は長文ライティングがつらい

逆に言うと、この3点が満たされていれば5万円台のエントリーノート PC で十分にブログは書ける。

書く場所で求める性能が大きく変わる

短い答え: 家で書くか、外で書くか。これが PC 選びを9割決める。

理由は、外で持ち運ぶなら重量とバッテリーの2点が制約になり、コストが跳ね上がるから。家中心なら制約が緩く、同じ予算で性能のいい機種が買える。

家で書く: 重さ・バッテリー無視で OK

家中心なら、重量とバッテリーは気にしなくていい。

その分、画面サイズと CPU 性能にコストを振れる。15インチクラス / Core i3〜i5 で5〜7万円台が現実的なラインに収まる。

外で書く: 重量1.5kg以下、駆動時間12時間以上

外で書くなら、軽さとバッテリーが直接生産性に効く。

目安:

重量: 1.5kg 以下（徒歩移動が多いならこれより軽く）
バッテリー駆動時間: スペック表記で12時間以上
画面サイズ: 14インチ（携帯性と作業効率の折り合い点）

軽量モデルは同等性能でも価格が1〜2万円高い傾向がある。

キーボードは「日本語（JIS）配列」を必ず確認する

短い答え: 安いノート PC には英字キーボード搭載モデルが混じっている。日本語配列か必ず確認する。

理由は、英字配列だと「全角/半角」キーがなく、日本語入力の切り替えが面倒。ブログ執筆では致命的に効く。

確認ポイント:

スペックに「JIS」または「日本語」と書かれているか
商品写真でキーボード左上に「全角/半角」キーがあるか

画面サイズは14インチ以上、可能なら外部モニターを追加

短い答え: 12インチ未満は長文ライティングでつらい。14インチ以上を基準にする。

理由は、ブログ執筆中に資料 / プレビュー / 本文を並べる場面が多いから。狭い画面では切り替え操作だけで時間を取られる。

家中心の場合は、ノート PC + 外部モニターの構成が体感差が大きい。資料を片方の画面に出しっぱなしにできるので作業速度が上がる。

用途別おすすめ機種

以下は執筆当時（2021年）に選定したモデル。2026 時点では後継 / 同等価格帯の最新モデルを必ず確認すること。

家で書くなら — 15インチクラスの低価格ノート

15インチで5万円台のエントリーモデルが第一候補。CPU は Core i3 で十分、ライティング作業なら性能不足を感じない。

外で書くなら — 1.5kg、14インチクラス

携帯性重視。1.5kg 程度・14インチ・バッテリー駆動時間長めのモデル。

比較: 家用 vs 外用ノートパソコン

観点	家中心	外でも書く
重量	気にしなくて OK	1.5kg 以下
バッテリー	短くて OK	駆動時間12時間以上
画面サイズ	15インチ推奨	14インチ
価格目安	5〜7万円	7〜10万円
外部モニター	あれば作業効率↑	不要（持ち運ばない前提）

よくある質問

Q. iPad Pro でもブログは書けますか？ A. 最新の iPad Pro なら、外付けキーボードを付ければ書けないことはない。ただし WordPress 管理画面の操作や画像編集を考えると、長期的にはノート PC を勧める。

Q. Mac か Windows か、どちらがいい？ A. ブログ執筆だけならどちらでも変わらない。普段使っている OS で選ぶのが摩擦が少ない。

Q. メモリは何 GB あれば足りますか？ A. ブログ執筆のみなら 4GB でも動くが、ブラウザのタブ数が増えるとスワップが発生して遅くなる。8GB を目安にする。

Q. SSD と HDD どちらを選ぶべきですか？ A. SSD 一択。HDD 搭載モデルは起動とアプリ立ち上げが遅く、日常的なストレスが大きい。

まとめ

ブログを始めるためのノート PC は、直近5年のモデルなら基本どれでもいい。

確認すべきは「家で書くか / 外でも書くか」「キーボードが日本語配列か」「画面サイズ14インチ以上か」の3点。これさえ押さえれば、エントリークラス（5〜7万円台）で十分にブログ運営は回る。

外部モニターを足せる予算があるなら、家中心の構成は生産性で一段上がる。

エアダスター缶 + 除電ブラシでPC掃除 — エレコム ECO とサンワサプライブラシのレビュー

Thu, 11 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。エレコムエアダスター ECO とサンワサプライ除電クリーニングブラシは現在も現行品だが、価格・型番は変動している可能性あり。レビュー観点（缶ダスターの強み弱み、除電ブラシの使い所、電動エアダスターとの選び分け）は今も参考になる。

PC内部やキーボード周りのほこりは、放置するとファン詰まり・熱暴走・キー入力の引っかかりの原因になる。月1回サッと掃除しておけば寿命がだいぶ違う。

ここでは数年使い続けている エレコムエアダスター ECO と サンワサプライ除電クリーニングブラシ の組み合わせを、缶式・電動式・アルコール+綿棒の3方式と比較しながらレビューする。

結論 — 「缶ダスター + 除電ブラシ」が手早くて安い

短い答え: 月1〜2回のライトな掃除なら、エアダスター缶で大きいほこりを飛ばし、除電ブラシで細部を払うのが時間対効果で一番いい。電動式は週1で掃除する人向け。

理由は、缶ダスターは1本1,000円前後で導入コストが低く、噴射の勢いも電動より強いことが多い。除電ブラシはCPU・メモリ周りなど静電気で壊れる可能性のあるパーツを安心して触れる。

以下に該当する人は別の組み合わせを検討してもいい:

掃除頻度が週1以上: 缶のランニングコストが効いてくる。電動エアダスターのほうが長期的には安い
ガス臭に敏感 / 換気しづらい部屋で作業: 電動に乗り換えるか、屋外作業を検討
基板の汚れが油脂・ヤニ系: 風と毛では落ちない。無水エタノール + 綿棒の併用が必要

エレコムエアダスター ECO の外観

短い答え: 一般的なスプレー缶サイズ。赤いノズルとキャップが付属する。

キーボードの隙間、PCケース内部、ノート PC の通気口など、ブラシでは届かない箇所の掃除に使う。筆者の使用頻度は月1回程度で、半年で1本のペース。

赤い細口ノズルは購入時に缶のラベル部分にテープで留められている。狭い隙間に風を集中させたいときに装着する。

噴射ボタンには透明のキャップが被せてある。鞄や引き出しに入れたまま誤噴射しないための物。

エレコムエアダスター ECO の良かった点

短い答え: 噴射の勢いが強く、価格が安いので気軽に使える。

噴射の勢いが強い

トリガーを押すと「ブシャーッ」と一気に出る。キーボードの隙間に溜まったほこり、PCケースのファン周りのほこりは、ノズルを近づけて軽く吹くだけでほぼ飛ぶ。

電動エアダスターも持っているが、ピーク風量だけで言うと缶のほうが上に感じる。

価格が安く気軽に使える

1本1,000円前後で買えるので、ほこりを見つけたら遠慮なく吹ける。「もったいないから後でまとめて」と思わずに済むのが地味に効く。

掃除のハードルが下がる → 結果として頻度が上がる → PC が長持ちする、というサイクルになる。

エレコムエアダスター ECO の微妙だった点

短い答え: ガス臭が残る / 缶は使い捨てなのでランニングコストがかかる。

ガス臭がする

噴射ガスの匂いが、使用後しばらく部屋に残る。1〜2秒の短い噴射では気にならないが、連続で5秒以上吹くと匂いが立つ。

換気できる環境なら問題ないが、深夜の集合住宅でフルパワー掃除はやりにくい。

ランニングコストがかさむ

カンは1回使い切り。月1ペースなら半年1本で済むが、週1で吹くと年間4〜6本になる。1本1,000円換算で年間4,000〜6,000円。電動エアダスター（1万円前後）なら2年で元が取れる計算。

筆者は現在缶を継続使用しているが、ヘビーに掃除する人には電動が選択肢に入る。

サンワサプライ除電クリーニングブラシの外観

短い答え: 大小2サイズのブラシが両端に付いた除電仕様のブラシ。3本セットで売られていることが多い。

PC内部のほこりを払うのに使う。柄の中に除電素材が入っているとされ、静電気の発生を抑える。

CPU・メモリ・GPU 基板は静電気で破損する可能性がある。普通の合成繊維ブラシで擦るのが怖い箇所でも、除電ブラシなら安心感がある。「裸でお風呂場で組む」みたいな民間療法（笑）に頼らずに済むのがメリット。

反対側には狭所用の小さいブラシが付いている。ヒートシンクのフィン間、I/O パネル裏、SATA コネクタの根元など、大ブラシでは入らない場所はこちらの担当。

サンワサプライ除電クリーニングブラシの良かった点

短い答え: 除電機能で基板を安心して触れる / 小ブラシ併設で狭い場所にも届く。

除電機能で基板に触れやすい

CPU ピン折れ・メモリ破損のニュースは見るが、静電気破壊の事例も無視できない。除電ブラシなら「触っていいのか怖い」というブレーキが外れる。

実際に静電気で壊れる確率がどれだけかは分からないが、保険として持っておく価値はある。

小ブラシで狭所まで届く

PC 内部は指が入らない隙間が多い。小ブラシは爪楊枝より少し太い程度の毛束で、ヒートシンクの溝や端子の根元まで毛先が入る。

エアダスター缶で飛ばしきれなかった毛玉状のほこりも、小ブラシでつまみ出せる。

サンワサプライ除電クリーニングブラシの微妙だった点

短い答え: 大ブラシ側のサイズがやや大きい。

大ブラシのサイズが過大

PCケース内では「ふた回り小さい」ほうが取り回しが効くと感じる場面が多い。マザーボード上のヒートシンク列をなぞるとき、隣のコネクタに毛先がぶつかる。

大ブラシ単体ではキーボード掃除には便利なので、用途を分けて考えれば不満ではない。

比較: エアダスター缶 + 除電ブラシ vs 他の掃除方式

観点	缶ダスター + 除電ブラシ（本記事の組み合わせ）	アルコール + 綿棒	エアダスター缶単体	電動エアダスター
初期コスト	約2,000円前後	約500円〜	約1,000円	約1万円〜
ランニングコスト	缶の使い捨て分のみ	消耗品（綿棒・エタノール）	缶の使い捨て	電気代のみ
得意な汚れ	乾いたほこり全般	油脂・指紋・ヤニ汚れ	乾いた粗いほこり	乾いたほこり全般
静電気対策	あり（除電ブラシ）	なし	なし	機種による
静音性	噴射音のみ	静か	噴射音のみ	モーター音が大きい
環境負荷	缶の廃棄あり	少	缶の廃棄あり	少（本体寿命まで再利用）
ガス臭	あり	アルコール臭あり	あり	なし

電動エアダスターは月数千円のランニングコストを節約できるが、初期投資1万円と作動音の大きさがネック。月1〜2回掃除の人には缶のほうがトータルで楽。

油脂汚れ（キーキャップの皮脂、ファンに付いたヤニ）は風では落ちない。アルコールと綿棒、または無水エタノールで拭き取る工程を別に挟む必要がある。

よくある質問

Q. エアダスター缶と電動エアダスター、どちらを買えばいい？ A. 月1〜2回しか掃除しないなら缶で十分。週1以上で掃除する、または屋外で他の機械（カメラ・楽器・3Dプリンタ）にも使う予定があるなら電動が候補。ランニングコストの分岐点はおおむね2〜3年（使用頻度に依存）。

Q. 電動エアダスターは缶より風が弱いと聞きますが本当ですか？ A. 機種と缶の残量による。新品満タンの缶はピーク風量が強いが、缶は使うにつれて気化熱で冷えて風量が落ちる。電動は安定した風量を継続して出せるので、長時間掃除では電動のほうが楽な場面もある。

Q. 除電ブラシは本当に静電気を防げますか？ A. 完全には防げない。除電ブラシは内部の素材で静電気を逃がす設計だが、絶対安全とは言えない。基板を触る前に金属部に手を触れて自分の静電気を放電する、湿度の低い真冬は作業を避ける、などの基本対策と併用するのが安全。

Q. PCの中にエアダスターを吹くとファンが回って壊れませんか？ A. ファンの羽根を高速で回すと軸受けにダメージを与える可能性がある。指やブラシの柄でファンを軽く押さえてから吹くのが定番のテクニック。CPU クーラーのファンも同様に固定してから掃除する。

総評 — 「ほどよく安く、ほどよく安全」な組み合わせ

短い答え: 月1ペースのライト掃除なら、缶ダスター + 除電ブラシのコンビが時間・コスト・安全性のバランスでまず外さない。

PC内部の掃除手順は以下で固まっている:

エアダスター缶で大きいほこりをまず飛ばす（ファンは指で押さえる）
大ブラシで残ったほこりを払い落とす
小ブラシでヒートシンクの溝や端子周りを仕上げる
油脂・指紋汚れがある箇所だけ無水エタノール + 綿棒で拭く

毎月これをやっておくと、年に1回の本格清掃でも「中はそれほど汚れていない」状態を保てる。

掃除頻度が上がってきたら電動エアダスターへの乗り換え、油脂汚れが目立つようになったらアルコール清掃の追加 — というふうに段階的に道具を増やすのがおすすめ。

ロジクール MX MASTER 2S レビュー — サイドホイールでExcel横スクロールが劇的に楽になるマウス

Tue, 09 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。MX MASTER 2S は 2026 時点では旧モデルで、現行は MX Master 3S。レビュー観点（サイドホイールの有用性、サイズ感、ジェスチャーボタンの注意点）は今も参考になる。

仕事で日常的に使っていた Logicool の MX MASTER 2S を、半年以上使った視点でレビューする。

「マウスにしては高い」と感じる価格帯（執筆当時で約9,400円）だが、Excel やクリエイティブ系ソフトを多用するなら、その差額分の生産性を取り戻せる類のマウス。

結論 — Excel 横スクロールを毎日使う人なら買い

短い答え: サイドホイールでの横スクロールが快適すぎる。Excel やデザイン系ソフトで縦横にスクロールする頻度が高い人なら、価格分の価値はある。

理由は、「Shift + ホイール」「マウス両端へドラッグ」のような操作がサイドホイールひと回しで済むから。1日に何百回も発生する操作のコストが1〜2秒ずつ短縮される。

ただし以下に該当する人は注意:

手が小さい人: MX MASTER 2S は大型で、サイズ展開がない
頻繁にゲームでマウスを激しく操作する人: ジェスチャーボタンに強度不足の事例あり（後述）

外観と質感

短い答え: 立体的でモノクロ調の高級感ある質感。マウス先端がやや鋭利な独特のフォルム。

横から見ると「H を横にしたような」形状で、親指と小指で挟む持ち方になる。

裏側に電源スイッチとデバイス切り替えボタン（最大3台までペアリング）。

左側面に親指置き場 + ジェスチャーボタン、サイドホイール、上下ボタン2つ。給電は microUSB Type-B（このモデルの数少ない欠点のひとつ）。

良かった点

短い答え: サイドホイールが最大の差別化要素。デザインと持ちやすさも上位互換。

サイドホイール — Excel 横スクロールが一発

他のマウスとの最大の違い。横スクロール専用のホイールが左側面にある。

Excel の横方向移動、Figma のキャンバスパン、動画編集ソフトのタイムラインスクロール — どれもキーボード補助なしで指1本で済む。

サイドボタンが上下配置で押しやすい

普通のマウスのサイドボタンは「前後配置」で進む・戻るに割り当てるのが定石。MX MASTER 2S は上下配置で、最初は混乱するが慣れると押し分けが楽。

デザインがオフィスで浮かない

モノクロ調の落ち着いた外観。家でも仕事場でも違和感なく使える。

微妙だった点

短い答え: サイズが大きい / 給電が microUSB Type-B / ジェスチャーボタンが弱い。

手が大きい人向け、サイズ展開なし

握りやすさは個人的にはこれまでで一番だったが、手が小さい人にはおすすめしづらい。サイズ展開がないので、店頭で握ってから決めるのが安全。

充電が microUSB Type-B

2026 年現在、周辺機器の主流は USB Type-C。充電頻度は2〜3ヶ月に1回なので致命的ではないが、ケーブル管理上は不便。

ジェスチャーボタンの強度不足

執筆者がこのマウスから乗り換えた直接の原因。

ゲーム中に勢いよくジェスチャーボタンをクリックしたら、クリックしっぱなしの状態で固まった。分解すれば直るレベルだが、強くクリックしたつもりはなく、構造的に弱い可能性が高い。

長時間 / 頻繁に激しく操作するユーザーは要注意。

比較: MX MASTER 2S vs 3 / 3S

観点	MX MASTER 2S	MX MASTER 3 / 3S
給電	microUSB Type-B	USB Type-C
ホイール	機械式	MagSpeed（電磁式）
サイドホイール	あり	あり（より滑らか）
ジェスチャーボタン強度	弱め	改善傾向
価格帯（執筆当時）	約9,400円	約13,000円〜

新規購入を検討するなら、現行の MX Master 3S を勧める。中古や型落ち狙いでも、ジェスチャーボタンを多用しないなら 2S は実用上問題ない。

ソフト（Logicool Options）

専用ソフト Logicool Options でほぼ全ボタンの挙動をカスタマイズできる。

ジェスチャーボタンには上下左右4方向にアクションを割り当てられる。

ホイール感度・ポインタ速度も細かく調整可。Excel 用にホイールスクロール量を変える、などのチューニングが効く。

よくある質問

Q. Mac でも使えますか？ A. 使える。Logicool Options for Mac が提供されている。Bluetooth または USB レシーバーどちらも対応。

Q. バッテリーはどのくらい持ちますか？ A. 公称70日。実使用でも2〜3ヶ月に1回の充電で間に合った。

Q. ゲーミング用途で使えますか？ A. 反応速度では普通のマウス。FPS や精密操作が必要なゲームには専用ゲーミングマウスを勧める。ジェスチャーボタンの強度問題もあるので、激しい操作を伴うゲームは避けた方が無難。

Q. iPad に接続できますか？ A. iPadOS 13.4 以降ならマウス対応。Bluetooth でペアリング可能。

総評 — 「ハマる人にはハマる」マウス

人を選ぶマウスだが、ハマる用途で使うと手放せなくなる類。

特に Excel / Figma / 動画編集など横スクロールを多用する作業では、ほかのマウスに戻れなくなる。

注意点はサイズ感とジェスチャーボタンの強度の2つ。可能なら店頭で握って決めるのが一番後悔がない。

Netlify にお名前.com の独自ドメインをつなぐ — DNS 切り替え手順と注意点

Mon, 08 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。手順の骨子は変わっていないが、Netlify / お名前.com の UI スクリーンショットは2021年当時のもの。現在は Cloudflare Pages + Cloudflare DNS の組み合わせも一般的で、本文末で比較を追加している。

お名前.com で取った独自ドメインを Netlify のサイトに割り当てる作業は、UI に慣れていないと一度で迷う。原因はだいたい「ネームサーバーを書き換える場所が分からない」「反映が遅くて成功したか分からない」の2つに集約される。

この記事は、その2点を先に潰してから手を動かせるように、DNS の仕組み・接続手順・反映確認のコツを順に並べた。前提として、Netlify 側のデプロイ自体はVuePress / 静的サイトを Netlify にデプロイするで済んでいるものとする。

結論 — Netlify DNS にネームサーバーごと委任するのが最短

お名前.com で取得したドメインを Netlify につなぐ最短ルートは、お名前.com のネームサーバーを Netlify DNS の4つに書き換えること。

理由は、Netlify が DNS レコード（A / AAAA / CNAME）の管理を肩代わりしてくれるため、SSL 証明書の発行・apex ドメインの扱い・サブドメイン追加までほぼ自動で進むから。レコードを自分で書く必要があるのは、ドメインを Cloudflare DNS など別の DNS に委任して、CNAME で Netlify を指す構成を選んだ場合だけ。

迷ったら Netlify DNS で委任、複数サービスを同じドメインで束ねたいなら Cloudflare DNS、という切り分けでいい。

DNS 委任の仕組み — 「住所録の所有者」をどこにするか

DNS は「ドメイン名 → サーバーの IP」を引くための分散データベース。ネームサーバーは、その引き先を持っている正本にあたる。

お名前.com でドメインを買った直後は、お名前.com 自身が正本（プライマリ DNS）になっている。これを Netlify DNS に書き換える操作が「ネームサーバーの変更」で、書き換えると以降の A / CNAME レコードは Netlify 側で管理される。

お名前.com DNS vs Netlify DNS vs Cloudflare DNS

観点	お名前.com DNS（既定）	Netlify DNS（委任）	Cloudflare DNS（委任）
設定の手間	A / CNAME を手で書く	自動で必要レコード生成	自分で CNAME を書く
Netlify との相性	可	公式の最短ルート	良（CNAME flattening 対応）
HTTPS 証明書	Netlify 側で自動	Netlify 側で自動	Netlify 側で自動
CDN / WAF 追加	不可	不可	可（Cloudflare 側で）
メール / 他サービス併用	やや面倒	面倒	楽
2026年の主流度	△	◯	◎

迷ったら一番上から順に「Netlify しか使わない → Netlify DNS」「メールや別サービスも乗せたい → Cloudflare DNS」と決めるとブレない。

接続手順 — 実作業10分、反映待ち最大48時間

ここからが本作業。所要時間は、実際にクリックする部分が10分前後、DNS が世界に行き渡るまで最大48時間（実測では数時間で済むことが多い）。

ステップ1: お名前.com でドメインを取得する

お名前.com のトップで取得したいドメイン名を入力する。.com 以外を取りたいときは TLD を明示的に選ぶ。

検索結果から取得したい TLD にチェックし、料金確認に進む。

次のサーバー選択画面では、ホスティングは Netlify を使うので利用しないを選ぶ。ここで余計なレンタルサーバーを契約しないこと（年額がそのまま無駄になる）。

決済まで終わるとドメイン取得が完了する。Whois 代行は無料で付くので付けたままでよい。

ステップ2: Netlify で Add custom domain を実行する

Netlify の対象サイトの overview から Domain settings に入る。

Add custom domain をクリックして、取得したドメイン（example.com のように apex で入れる）を入力。Verify を押すと、所有確認の画面に進む。

ステップ3: Netlify DNS を有効化してネームサーバーを控える

ドメインを追加した直後は Check DNS configuration が出る。Options → Set up Netlify DNS を選んで Netlify DNS を有効化する。

確認ダイアログが何枚か出るが、内容を読みつつ進める。最後に Name servers として4つの FQDN（dns1.p0X.nsone.net のような形式）が表示されるので、ここでブラウザのタブを残したままコピーしておく。

ステップ4: お名前.com でネームサーバーを Netlify に変更する

別タブでお名前.com Navi にログインする。画面上部のメニュー一覧 → ネームサーバーの変更。

対象ドメインにチェック → 「その他」タブを選び、ネームサーバー欄に Netlify から控えた4つを上から貼り付ける。

確認ボタンを押すと、変更受付完了のメールが届く。ここまでで作業自体は終わり。

ステップ5: DNS 反映と HTTPS 証明書発行を待つ

反映は数分〜最大48時間。Netlify 側では、DNS が伝播し終わると Let’s Encrypt の証明書発行が自動で走り、HTTPS で取得ドメインにアクセスできるようになる。

確認のコツ:

30分待っても見えないとき、nslookup example.com 1.1.1.1 で名前解決ができているか別の DNS で確かめる
自宅回線だけ見えないときはルーター / OS の DNS キャッシュを疑う
半日経っても証明書が pending のままなら、Netlify の Domains 画面で Renew certificate を一度押すと再キックされる

注意点 — つまずきがちな4つの落とし穴

短い答え: ネームサーバーの貼り間違い・反映を待たずに再設定・お名前.com の更新メールの誤クリック・メールを同ドメインで運用していたケースの4つ。

ネームサーバーの貼り間違い: 4つすべてを正確にコピーする。順番は気にしなくていいが、末尾の . の有無や先頭の空白に注意
反映前に何度も設定をやり直す: 反映待ちの最中に「効いてない」と思ってお名前.com 側を再変更すると、TTL がリセットされてさらに遅延する。まず半日待つ
更新メールの誤クリック: お名前.com からは類似ドメインの広告メールが頻繁に届く。本物の更新案内かどうか、Navi にログインして契約一覧で確認するクセを付ける
メールを同ドメインで運用している場合: ネームサーバーを Netlify DNS に丸ごと移すと、MX レコードを Netlify DNS 側で再設定し直す必要がある。メールがあるなら Cloudflare DNS 委任の方が安全（各社の MX 設定 UI は2026年時点で変更が入る可能性あり）

よくある質問

Q. Netlify DNS を使わずに、お名前.com の DNS のままつなげますか？ A. 可能。お名前.com の DNS レコード設定で apex は A レコード 75.2.60.5、www は CNAME で <site>.netlify.app を指せばつながる。ただし Netlify 側のロードバランサ IP は将来変わる可能性があるため、長期運用なら Netlify DNS か Cloudflare DNS への委任が安全。

Q. Cloudflare DNS 経由で Netlify につなぐのは何が違いますか？ A. ネームサーバーを Cloudflare に委任し、CNAME で Netlify を指す構成。CDN や WAF を Cloudflare 側でかけられ、複数サービス（メール、別ホスティング）を同居させやすい。Aulvem 自身も現在 Cloudflare Pages を使っており、DNS は Cloudflare 側で管理している。

Q. ネームサーバーを変えてからどのくらいで反映されますか？ A. 実測では数分〜数時間で大半は反映、最大で48時間程度。反映途中はキャッシュの効いた回線とそうでない回線で見え方が変わるので、半日経って見えなければ別ネットワークから確認する。

Q. Netlify は2026年でも選択肢に残りますか？ A. 選択肢としては有効。ただし2026年時点では Cloudflare Pages と Vercel の方が新規プロジェクトのデフォルトになりやすい。Netlify Forms や Identity を使う前提なら Netlify が依然強い。

まとめ

お名前.com のドメインを Netlify につなぐ作業の本質は、「ドメインの正本をどの DNS に置くか」の選択。Netlify しか使わないなら Netlify DNS への委任が一番楽で、複数サービスを束ねたいなら Cloudflare DNS 経由を選ぶ。

UI のスクリーンショットは2021年当時のままだが、ネームサーバー委任という基本フローは2026年でも変わっていない。Netlify 自体は健在で、Forms や Identity を使うプロジェクトでは今も第一候補になる。

Netlify 側の初期セットアップから振り返りたい場合はVuePress / 静的サイトを Netlify にデプロイするを参照。

ラトックシステム RS-WFIREX4 レビュー — 1万円以下で始めるスマートホーム入門機

Sun, 07 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。本体スペックや UI は執筆当時のもの。後継機 RS-WFIREX5 が出ているので、新規購入時はラインナップを確認すること。

リモコン操作したい時に限ってリモコンが行方不明になる、という現象がよく起きていた。そこで導入したのが、赤外線で家中の家電をスマホとスマートスピーカーから操作できるラトックシステムの RS-WFIREX4。数年間使った視点でレビューする。

価格は1万円を切る帯。スマートリモコンの中ではエントリー寄りだが、できることは Nature Remo や SwitchBot ハブと大きく変わらない。

結論 — 初めてのスマートリモコンなら手堅い選択肢

短い答え: 1万円以下で Alexa / Google Home / Siri に対応する赤外線スマートリモコンとして、入門機の役割を十分果たす。家電をリモコンで操作する生活を一段階楽にしたいなら買い。

理由は3つ。

小型・白色で壁に掛けても部屋に馴染む
温度計 / 湿度計 / 照度計が内蔵されていて、家電操作の自動化条件に使える
スマートスピーカー3系統全部に公式対応

ただし以下に該当する人は注意。

物理リモコンと同じ即応性を求める人: 2〜3秒の遅延あり
設定が苦手な人: 初期設定はアプリ任せでは進まず、説明書併読が前提
赤外線の見通しが取れない部屋: 壁や扉の陰の家電は届かないことがある

外観 — 白い小箱、壁掛け前提のデザイン

短い答え: 白色プラスチック筐体の小型ボックス。壁掛け用フックが背面にあり、設置場所を選ばない。

正面はロゴと小さなインジケーター以外、ほぼ無地。壁の白に溶けるので、リビングに置いても主張しない。

手のひらに収まるサイズ。高さは約4cm。側面に排熱用のスリットがある。

背面に壁掛け用フックと紐通し穴。底面に滑り止めゴム。机置きでも壁掛けでも違和感がない作り。

給電は microUSB Type-B。2026 年現在は USB Type-C が主流なので世代を感じるが、常時給電で抜き差ししない使い方なら実害は小さい。側面にステータス LED とリセットボタン。

良かった点

短い答え: 赤外線リモコンを置き換えるという基本機能の完成度が高い。スマートスピーカー連携と環境センサーが付いてくるのが嬉しい。

赤外線で操作できる家電にほぼ何でも対応

リモコン信号を学習させればテンプレート外の家電も動く。実用上、家にあるリモコン家電のほとんどはアプリ1本で操作できる状態に持ち込める。

導入してから「リモコンがどこにあるか」を探す回数が激減した。家電を新調するときに「リモコン付き or スマート対応」を購入条件に入れるようになったほど、運用が固定化した。

テンプレートが用意されている代表的な家電は以下。

エアコン
テレビ
照明
扇風機

アプリのダウンロードリンクは下記。

iOS: Wi-Fi 学習リモコン (App Store)
Android: Wi-Fi 学習リモコン (Google Play)

外出先からスマホで操作できる

スマホ側のネットワークが Wi-Fi でなくても、本体さえ自宅 Wi-Fi につながっていれば外出先からアプリで操作できる。帰宅前にエアコンを入れる、消し忘れた照明を外から切る、といった運用が現実的になる。

温度・湿度・照度センサー内蔵

家電選択画面の下部に、本体設置場所の温度・湿度・照度が常時表示される。照度は3段階表示で数値より直感的（個人的にはこの粒度のほうが好き）。

これらの値をトリガーにして「気温28度を超えたらエアコン ON」のような自動化を組める。

家電別に専用デザインのリモコン UI

テンプレート対応家電は、その家電向けにレイアウトされた専用 UI が出てくる。テンプレートにないボタンは自分で追加できる。

汎用リモコンアプリにありがちな「ボタン10個並んだだけの画面」ではなく、家電の見た目に寄せた UI なのが地味に効く。

Alexa / Google Home / Siri すべてに対応

スマートスピーカー3系統に公式対応している。アプリ内から連携設定を済ませれば、声で家電を操作できる。

手が塞がっている料理中、スマホを別室に置いてきた夜中、リモコンが見つからない朝 — このあたりで一番効く。

微妙だった点

短い答え: クラウド経由ゆえの2〜3秒遅延 / 赤外線の物理的な遮蔽問題 / 初期設定の難度。

操作レスポンスが2〜3秒かかる

スマホで押す → ラトックのクラウド → 自宅本体 → 家電、という経路を踏むので、物理リモコンと同じ即応性は出ない。

「あれ、効いた？」と感じて連打すると重複コマンドが届き、エアコンが ON / OFF / ON のように飛ぶことがある。1回押して数秒待つ、を癖にすると安定する。

赤外線なので遮蔽物に弱い

製品というより赤外線の性質。本体と家電の間に厚い扉や壁があると届かない。

出力を上げれば届く範囲は広がるが、今度は近隣の同型機が反応する可能性が出てくる。これはどのスマートリモコンも抱える構造的な制約。

設置場所は「操作したい家電群を見通せる中心点」を探す前提で考える。

初期設定が説明書併読前提

Wi-Fi 設定 → 本体登録 → 家電登録 → 連携設定、と工程が多い。アプリの UI だけで完結する作りではないので、説明書か公式の手順ページを並べて進めるのが結局一番早い。

慣れたユーザーには大した手間ではないが、「箱を開けたら数分で動く」タイプのデバイスではないことは前提に置きたい。

給電が microUSB Type-B

2026 年時点では型落ちの端子。常時給電で抜き差ししない運用なら問題はないが、ケーブル管理上は USB Type-C の方が嬉しい。

比較 — RS-WFIREX4 vs SwitchBot ハブ / Nature Remo

短い答え: コア機能はどれも同等。差は付加機能（Matter / ハブ機能 / セット販売）と価格帯で出る。

観点	RS-WFIREX4	SwitchBot ハブ 2	Nature Remo 3 / mini 2
価格帯（参考）	1万円以下	8,000〜10,000円前後	6,000〜13,000円前後
温度センサー	あり	あり	あり
湿度センサー	あり	あり	mini 2 はなし
照度センサー	あり（3段階）	あり	Remo 3 はあり
人感センサー	なし	なし	Remo 3 はあり
Alexa / Google / Siri	全対応	全対応	全対応
Matter 対応	非対応	一部対応	一部対応
エコシステム	単独	SwitchBot ボタン押し器など豊富	単独寄り
給電	microUSB Type-B	USB Type-C	USB Type-C

※スペック・価格は変動するため最新情報は各メーカー公式を参照。

選び方の目安は以下。

値段重視で入門機がほしい: RS-WFIREX4
物理ボタン押し器など SwitchBot 周辺機器も組みたい: SwitchBot ハブ 2
人感センサーで自動化を組みたい: Nature Remo 3

逆に言えば、コア機能（赤外線リモコン + センサー + スマートスピーカー連携）に絞れば、RS-WFIREX4 で大きな不足はない。

よくある質問

Q. Alexa と Google Home の両方に対応していますか？ A. 対応している。アプリ内の連携設定からスキル / アクションを有効化すれば、両方から同じ家電を操作できる。Siri ショートカットも公式サポート対象。

Q. 外出先からスマホで操作できますか？ A. できる。RS-WFIREX4 本体が自宅 Wi-Fi 経由でメーカーのクラウドに接続しているため、スマホの回線が 4G / 5G でもアプリから操作できる。自宅のルーターが落ちると当然届かない。

Q. ボタンを押してから家電が反応するまでどのくらいかかりますか？ A. 実使用での体感は2〜3秒。スマホ → クラウド → 本体 → 家電という経路を辿るので、物理リモコンと同じ即応性は出ない。連打すると重複コマンドが届くので、1回押して待つ運用が無難。

Q. どの家電に対応していますか？ A. 赤外線リモコン付きの家電なら基本的に何でも登録できる。テンプレートが用意されているのはエアコン / テレビ / 照明 / 扇風機など主要ジャンル。テンプレート外でもリモコン信号を学習させれば動く。

総評 — 「最初の一台」としてちょうどいい

派手さはないが、スマートリモコンに求められる基本機能をひととおり押さえた手堅い製品。

1万円以下で Alexa / Google Home / Siri 全対応・センサー3種内蔵・小型筐体、というスペックの組み合わせは入門機として無難。レスポンス遅延と初期設定の難度は構造上の制約なので、買う前に許容できるか確認したい。

逆に、Matter ベースのエコシステムや人感センサーによる自動化まで踏み込みたい人は、SwitchBot ハブ 2 や Nature Remo 3 を含めて比較することをおすすめする。

VuePress-GitHub-Netlifyで環境構築

Sat, 06 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。Netlify の管理画面 UI と料金プランは 2021 年から変わっており、現行の手順とは一部ズレている。骨子としての「GitHub 連携 → ビルドコマンド指定 → 自動デプロイ」という流れは現在も同じなので、考え方の整理として残している。

静的サイトのホスティング先として Netlify を選び、GitHub のリポジトリを連携して自動デプロイを動かすまでの初期設定をまとめる。当時のスクリーンショットをそのまま貼っているが、現在の Netlify の管理画面とはレイアウトが違うので、その点は割り引いて読んでほしい。

この記事で扱うのは「アカウント作成」「リポジトリ連携」「ビルド設定」「2段階認証」「無料枠の確認」の 5 点。独自ドメインの設定は別記事に分けている。

使用するサービス

短い答え: GitHub をコード管理、Netlify を静的ホスティングに使う最小構成。

GitHub — コード管理
Netlify — 静的サイトホスティング

理由は、GitHub にプッシュした内容を Netlify が検知して自動でビルド・公開してくれるから。ローカルで書いて、push して、確認する、というシンプルな流れが作れる。

全体的な流れは以下。

ローカルで開発・執筆
GitHub にソースコードを push
Netlify が検知してビルド・配信

注意: 以降の手順は GitHub のアカウント登録と 2 段階認証が済んでいることを前提に書いている。

Netlify にアカウントを作る

短い答え: Netlify のトップから GitHub アカウントでサインインする。

理由は、Netlify と GitHub を別々のアカウントで管理するより、OAuth 連携で済ませた方が後の手順が短いから。Netlify 側で個別のパスワードを作る必要もない。

Netlify にアクセスすると以下の画面が出るので、GitHub のアカウントでログインする。

注意: 2026 年現在は Netlify の UI が刷新され、サインアップのレイアウトとボタン位置は当時と異なる。OAuth で GitHub と連携する流れ自体は同じ。

GitHub のリポジトリを連携する

短い答え: ダッシュボードの New site from Git から GitHub を選び、対象リポジトリを指定する。

理由は、Netlify は Git リポジトリの内容を起点に動くから。ローカルからの直接アップロード（drag & drop）も別の選択肢としてあるが、自動デプロイにしたいなら Git 連携が前提になる。

ログイン後、New site from Git をクリックするとデプロイ元の選択画面が表示される。GitHub を選び、対象リポジトリを選択する。

注意: プライベートリポジトリも同じ手順で連携できる。組織所有のリポジトリの場合は、組織側で Netlify アプリの承認が必要になることがある。

ビルド設定を入力する

短い答え: Branch・Build command・Publish directory の 3 つを入力して Deploy site を押す。

理由は、Netlify はこの 3 つを起点に「どのブランチを」「どうビルドして」「どこを公開するか」を決めているから。フレームワーク（VuePress / Next.js / Astro など）によって値が変わる項目はここだけと言ってよい。

リポジトリを選ぶと、ビルド設定の画面が出る。

VuePress 製サイトの場合の例:

項目	値の例
Branch	`master` または `main`
Build command	`npm run build`（VuePress の場合）
Publish directory	`docs/.vuepress/dist`（VuePress 既定）

入力後、Deploy site をクリックするとビルドが走る。ステータスが Published になればデプロイは成功。

注意: ビルドコマンドを後から変更してデプロイが落ちるのはよくある事故。動いている設定を不用意に書き換えない ようにする。Publish directory のパスを 1 階層間違えるだけで真っ白な画面になる。

自動デプロイと HTTPS

短い答え: 対象ブランチに push すると Netlify が自動でビルドし、HTTPS も自動で有効になる。

理由は、Netlify は Let’s Encrypt を内部で扱っていて、独自ドメイン設定後も証明書の取得・更新を自動でやってくれるから。手動での設定操作は基本的に不要。

具体的には、

対象ブランチに push したタイミングでビルドが走る
ビルド成功後、配信用の CDN に反映される
独自ドメインを設定すると、Netlify 側で証明書が自動発行される

注意: 独自ドメインを当てた直後は反映に時間がかかる。当時の感覚では半日ほどで安定するが、DNS 伝搬の状況によって変わる。

2段階認証を有効化する

短い答え: User settings の Security から Two-factor authentication を有効にする。

理由は、Netlify アカウントはサイトのデプロイ権限と独自ドメイン設定の権限を握っているから。乗っ取られると公開中のサイトを差し替えられる。最初の段階で 2FA を入れておく方が後悔が少ない。

手順:

右上の自分のアイコンをクリックし、User settings を開く
左メニューの Security をクリック
Two-factor authentication の項目を有効化する

直リンクは以下。

https://app.netlify.com/user/security#two-factor-authentication/

注意: 認証アプリ（Authy / 1Password / Google Authenticator など）のバックアップを取らずに端末を機種変更すると、自分でログインできなくなる。リカバリーコードは別の場所に保管しておく。

無料枠について

短い答え: Netlify の Starter プランは容量 100GB / ビルド時間 300 分/月（2021 年当時）。

理由は、個人ブログ用途であれば、画像をある程度抑えていれば無料枠でほぼ収まる規模感だから。商用や高頻度更新になると話が変わる。

当時の Starter プラン:

帯域: 100GB / 月
ビルド時間: 300 分 / 月
サイト数の上限: 個人利用範囲

参考までに、動画や非圧縮 PNG を大量に置くと帯域とビルド時間の両方が一気に削れる。WebP に変換する、外部の画像配信サービスに逃がすといった対策で、無料枠の範囲に収めやすくなる。

注意: 2026 年現在は料金体系が改定されている。最新の上限は公式の Pricing を確認する。

よくある質問

Q. ビルドが失敗するときに最初に見るのはどこ？ A. Deploy ログの「Build command」の出力。ローカルでは動くが Netlify で落ちる場合、Node.js のバージョン違いか、package-lock.json と環境変数の差が原因になっていることが多い。

Q. ビルドコマンドを変更してサイトが見えなくなった。戻せる？ A. Deploys タブから過去の成功ビルドを開き、「Publish deploy」で巻き戻せる。先にロールバックしてから、原因のあるコミットを修正する流れが安全。

Q. 独自ドメインの設定はこの記事の範囲？ A. 含めていない。お名前.com で取得したドメインを Netlify に当てる手順は別記事に分けている。

Q. Netlify と Vercel / Cloudflare Pages はどう違う？ A. 静的サイトを GitHub から自動デプロイする、という核の体験は近い。料金体系・ビルド時間・エッジ機能の作りで差が出る。2021 年の選定理由は「日本語情報が当時揃っていた」「VuePress のサンプル設定が見つかりやすかった」の 2 点だった。

まとめ

Netlify の初期設定は、GitHub と OAuth で繋ぎ、リポジトリを選び、ビルドコマンドと公開フォルダを 1 行ずつ指定する、それだけで一通り動く。HTTPS と再ビルドは自動で、最初に詰まりやすいのはビルドコマンドの指定ミスと、本人 PC からのアクセス除外漏れくらい。

次の作業として、独自ドメイン設定は別記事に分けている。アクセス計測の除外設定や、画像配信先の選び方は、別の機会に書き直す予定。

カップヌードルリフィル用フタ付マグカップレビュー — 底が広くデスクでこぼれにくいマグ

Fri, 05 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。リフィル用マグカップ自体は現在も日清の公式オンラインショップやカップヌードルミュージアムショップで取り扱いがある。スペック表記は執筆当時の公称値で、最新の公式表記とは差分があり得る。Heavy リライト済み。

カップヌードルミュージアムに行った帰り、ネタ半分で買って帰った「リフィル用フタ付マグカップ」。麺の詰め替え用に作られた製品なのだが、結局デスクの常駐カップとして毎日使うことになった。

本来の麺用途より、デスクのコーヒー / 茶用マグとしての方が向いている気がしている。理由を以下にまとめる。

結論 — デスクで倒れにくいマグが欲しい人向け

短い答え: 底が広く重心が低いので、デスクでキーボードのそばに置いてもひっくり返しにくい。フタ付きでホコリが入らず、ポリプロピレン製で軽い。デザインのネタ性を許容できるなら、価格帯（1,000円未満）の割に実用性は高い。

理由は3つ:

底面が一般的なマグより広い: カップヌードル容器をそのまま再現した形状で、腕や袖が当たっても倒れにくい
フタ付き: 蒸気穴付きのフタが付属するので、放置中にホコリが入らない
軽い: ポリプロピレン製で陶器のマグよりかなり軽く、移動時の取り回しが楽

ただし以下に当てはまる人にはおすすめしない:

見た目の主張が強いのが嫌な人: カップヌードルのデザインそのままなので、職場やお客様の前で出したくない場面もある
冷たい飲み物を結露込みで使いたい人: 樹脂製なので保冷力は陶器より弱い

外観

短い答え: カップヌードル容器に取っ手を付けたデザイン。素材はポリプロピレンで、麺の詰め替え用に作られた製品なので底が広い。

正面はカップヌードルのパッケージそのまま。知らない人が見ると「カップヌードルを飲んでいる」ように見える。

サイズはノーマルサイズのカップヌードルとほぼ同じ幅・高さ（公称）。一般的なマグカップとして見ると、やや幅広・低めのプロポーション。

内側には「お湯を注ぐ線」のリブが成形されている。底面は外径が広く、設置面積が大きい。一般的なマグカップが「上が広く下がすぼまる」プロポーションなのに対し、こちらは逆に近い。

素材はポリプロピレン。耐熱は140℃と記載されている（公称）。

良かった点

短い答え: 底面の広さによる安定感、フタによる防塵、軽さの3点。

底が広く倒れにくい

最大の差別化要素。マグカップをデスクに置いていて、腕や袖が当たって倒すミスを何度も経験してきたが、このマグに変えてから半年以上ひっくり返したことがない。

理由は、カップヌードル容器がそもそも「不安定な床に置いてもひっくり返らない」前提で設計されているから。重心が低く、底面が広い。

フタが付いていてホコリが入らない

蒸気抜き穴が空いたフタが標準で付属する。ロック機構は無いので「持ち運んで通勤」用途には不向きだが、デスクに置きっぱなしの状況では十分。

席を外している間にゴミやホコリが入らないだけで、衛生面の安心感がぜんぜん違う。

軽くて取っ手が大きい

ポリプロピレン製なので陶器のマグよりかなり軽い。取っ手も指3本がしっかり入るサイズで、満タンに入れて運んでも持ちやすい。

電子レンジ対応と記載されているので、冷めたコーヒーの再加熱もそのままできる。

微妙だった点

短い答え: 詰め替え用カップヌードルが割高 / 樹脂特有のニオイ移り / 見た目を職場で出しにくい場面がある。

詰め替え用カップヌードル（リフィル）が普通のカップヌードルより割高

本来の用途である「リフィル麺をこのマグに入れてお湯を注ぐ」運用は、コスト面で割に合わない。普通サイズのカップヌードルを買う方が安いことが多い。

生産規模を考えればリフィルが割高なのは仕方ないが、本来用途で使うつもりで買うと肩透かしを食らう。

樹脂のニオイ移りがゼロではない

ポリプロピレンなので、コーヒー・紅茶を入れたあとに洗っても若干の色 / ニオイ残りがある。陶器マグと比べた場合の話で、日常使用に困るレベルではない。

職場で見た目を出しにくい場面がある

カップヌードルのデザインそのままなので、客先での会議や、堅めの職場では出しにくい。自席で1人で使う分には問題ないが、共有スペースで使う前提なら無地マグの方が無難。

比較 — 他のデスク常駐マグとの違い

短い答え: 「倒れにくさ」と「フタ付き」を両方満たす1,000円未満のマグカップは少ない。

観点	カップヌードルリフィル用フタ付マグ	一般的な陶器マグ	サーモス等タンブラー（フタ付き）
倒れにくさ	底が広く倒れにくい	上下同径〜やや上が広く倒れやすい	底径次第、細身は倒れやすい
フタ	あり（蒸気穴あり、ロック無し）	別売り	あり（ロック可なものもある）
重さ	軽い（樹脂）	重い	中（金属）
保温	弱い（単層樹脂）	中	強い（真空二重）
電子レンジ	可（公称）	物による	不可（金属）
デザインの無難さ	主張強め	無難なものが多い	無難
価格帯	1,000円未満	数百円〜数千円	2,000円〜

「保温も完璧にしたい」ならサーモス系タンブラー、「無難な見た目で電子レンジも使いたい」なら普通の陶器マグ。「とにかくデスクで倒れないフタ付きを安く」が要件ならこれが刺さる。

FAQ

Q. 食洗機は使えますか？ A. パッケージ表記では非対応の場合がある。樹脂製なので高温の食洗機を繰り返すと変形リスクがあり、手洗いの方が安全。

Q. どこで買えますか？ A. 日清食品のオンラインショップ、カップヌードルミュージアムのミュージアムショップ、各 EC モール。実店舗の販路は限定的なので、オンラインが現実的。

Q. 容量はどのくらいですか？ A. ノーマルサイズのカップヌードルとほぼ同じ容量。普段使いの飲み物用としては、マグカップとしてやや大きめ。

Q. 子ども用にも使えますか？ A. 軽くて割れない樹脂なので、陶器より子ども向きではある。ただしフタがロック式ではないので、こぼれ防止用途で使うならロック付きのキッズマグの方が安心。

総評 — ネタで買って実用品として残った

短い答え: 本来用途（リフィル麺）はコスト的に微妙だが、デスク常駐のフタ付きマグとして見ると価格対実用性が良い。

カップヌードルミュージアムのおみやげとして買ったものが、半年以上経った今もデスクで毎日使われている。これは想定外だった。

選定基準として「倒れにくいフタ付きマグを1,000円未満で」と設定すると、この製品は意外と競合が少ない。見た目のクセを許容できるかどうかで評価が分かれる。

職場の自席用にもう1個追加するか、検討中。

VuePress で画像配置と sitemap を設定する — 2021 年の構築メモ（アーカイブ）

Thu, 04 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。VuePress 1.x も vuepress-plugin-sitemap もメンテはほぼ停止しており、新規構築の参考にはならない。当時の image sitemap / 画像ディレクトリ設計の考え方として残している。コード片はすべて 2021 年時点の VuePress 1.x 前提。

VuePress 1.x で個人ブログを組んでいた頃の、画像配置と sitemap 設定をまとめた記録。Markdown 記事と同じフォルダ構造で画像を管理し、favicon は config.js の head に直書きし、sitemap は vuepress-plugin-sitemap で出力する、という当時の定番構成をそのまま残している。

この記事で扱うのは「画像ディレクトリの切り方」「favicon の指定」「sitemap プラグインの設定」「robots.txt の配置」の 4 点。大きな枠としての VuePress のディレクトリ構成は VuePress/blog のディレクトリ構成で別に書いている。

結論 — public 直下と public/resources を分ける

短い答え: 画像と sitemap 関連のファイルは、配信ルートに直接出すものと、記事ごとに整理するものを物理的に分ける。

VuePress 1.x は src/.vuepress/public 配下を dist のルートへそのままコピーする。つまり public 直下に置いたファイルは、ビルド後にサイト直下から配信される。favicon・robots.txt・sitemap.xml のように「ルート直下にあること自体に意味があるファイル」は public 直下に、記事画像のように「記事ごとに整理したいファイル」は public/resources 配下に分ける、という切り方にしている。

理由は、両者を同じ階層に置くとファイル数が増えたときに見通しが落ちるから。public 直下に何百枚も記事画像を置くと、favicon が画像群に埋もれてしまう。

対象ファイル

短い答え: 今回触るのは src/.vuepress 配下の public フォルダと config.js の 2 か所。

具体的には以下の構成。

src
└─ .vuepress
   ├─ public
   │  ├─ resources
   │  │  └─ category
   │  │     └─ page
   │  │        └─ img.jpg
   │  ├─ top.jpg
   │  ├─ favicon.ico
   │  ├─ favicon.png
   │  └─ robots.txt
   └─ config.js

注意: より大きいスコープでのディレクトリ全体像は VuePress/blog のディレクトリ構成を参照。

なぜ image sitemap を整理するか

短い答え: 画像の所在をクローラに伝えるためと、執筆側で画像を見失わないため。

image sitemap は sitemap.xml の中で各 URL に対して「このページにこの画像がある」を並べる拡張仕様。普通の sitemap はページ URL の一覧だが、image sitemap は画像 URL までクローラに渡せる。これにより画像検索からの流入経路が増える、というのが理屈上の利点。

ただし VuePress 1.x の vuepress-plugin-sitemap 2.x は、標準では image エントリを sitemap に出力しない。本記事の構成は「画像が正しく配信され、ページ単位の sitemap が出ている」状態までで、image エントリ込みの厳密な image sitemap はカバーしていない。

比較: image sitemap と通常 sitemap

観点	通常 sitemap (sitemap.xml)	image sitemap
伝える対象	ページ URL の一覧	各ページ URL + そのページに含まれる画像
Google への提供方法	Search Console / robots.txt	同左（拡張要素として埋め込む）
vuepress-plugin-sitemap 2.x の対応	標準で生成	標準では非対応
個人ブログでの効きやすさ	必須レベル	画像検索流入を狙うなら追加で検討

理由として、画像検索からの流入は写真メディアでは効くが、テキスト主体の技術ブログでは大きく動かないことが多い。最初は通常 sitemap だけ整え、画像検索からの流入が見えてきた段階で image sitemap に踏み込む順序で十分だった。

記事画像のディレクトリを決める

短い答え: src/.vuepress/public/resources 配下に、記事ごとのフォルダを切って画像を置く。

src
└─ .vuepress
   └─ public
      └─ resources
         └─ category
            └─ page
               └─ img.jpg

理由は、Markdown 記事のフォルダ構成と画像のフォルダ構成を 1 対 1 に揃えると、後で記事を移動・削除したときに画像の所在を辿りやすいから。記事 1 本に画像が複数枚入るケースが多いので、ページ単位でフォルダを切っている。

注意: フォルダ名は記事のスラッグと一致させる。記事側のリネームと画像フォルダのリネームを別タイミングでやるとリンク切れが起きる。

共通画像と favicon を public 直下に置く

短い答え: トップ画像・プロフィール画像・favicon は src/.vuepress/public 直下にまとめる。

src
└─ .vuepress
   └─ public
      ├─ favicon.ico
      └─ favicon.png

理由は、まだ共通画像が 2〜3 枚しか無く、フォルダを切るほどでもない規模だから。共通画像が増えてきたら以下のように public/resources/common を切って引っ越す予定にしていた。

src
└─ .vuepress
   └─ public
      └─ resources
         ├─ category
         └─ common
            └─ img.jpg

favicon は VuePress に index.html が無いため、config.js の head 配列に link タグを書いて読ませる。

module.exports = {
  head: [
    ["link", { rel: "icon", href: "/resources/favicon.ico" }],
  ],
}

PWA 化を狙うなら ico とは別に PNG の favicon を用意して、同じ階層に置いておく。当時はサイトの PWA 対応が中途半端だったため、その辺りの記述は省いている。

注意: head の指定はビルド後の HTML すべてに反映される。href のパスを 1 階層間違えるとサイト全体で favicon が読まれなくなる。

vuepress-plugin-sitemap を入れて hostname を設定する

短い答え: vuepress-plugin-sitemap を plugins 配列に追加し、hostname と exclude を指定するだけで sitemap.xml が自動生成される。

当サイトは vuepress-plugin-sitemap を使用していた（記事執筆時は vuepress-plugin-sitemap: ^2.3.1）。設定は config.js で完結する。

module.exports = {
  plugins: [
    [
      "sitemap",
      {
        hostname: "https://xxxx",
        exclude: "https://xxxx/404.html"
      },
    ]
  ],
}

理由として、hostname は sitemap 内の URL 組み立てに使われるため必須。exclude は 404 ページのようにクロール対象から外したい URL を書く。それ以外の細かいオプションは個人ブログ規模では触らなくても困らなかった。

注意: vuepress-plugin-sitemap 2.x は VuePress 1.x 向け。VuePress 2.x 系を使う場合は別パッケージになっており、設定 API も別物。

robots.txt を public 直下に置く

短い答え: robots.txt は必ず src/.vuepress/public 直下に置く。

src
└─ .vuepress
   ├─ public
   │  └─ robots.txt
   └─ config.js

理由は、VuePress では public 配下が dist のルートにコピーされる仕様だから。サブフォルダに置いてもルート直下から配信されず、クローラからは「robots.txt が無いサイト」として扱われる。

中身は他のフレームワークと同じで構わない。

User-agent : *
Disallow :
Sitemap : https://xxxx/sitemap.xml

Sitemap 行を入れておくと、Search Console を介さなくてもクローラが sitemap.xml の場所を拾える。

注意: Disallow を空のままにしているのは「全部許可」のつもりだが、後でステージング環境などを同じ仕組みで公開する場合は、環境ごとに robots.txt を切り替える運用にしておくと安全。

注意点 — 当時詰まったところ

短い答え: 画像パスのつもりが favicon のパスとぶつかる、sitemap.xml のキャッシュが効きすぎる、の 2 点に当時引っかかった。

画像参照を /img.jpg のように書くと、public 直下にあるファイルとパスがぶつかる。記事画像は /resources/category/page/img.jpg のようにフルパスで書くルールに統一した
sitemap.xml は CDN とブラウザの両方でキャッシュされやすく、デプロイ直後に Search Console から見ると古い内容のままになることがある。再ビルド後の URL を再送信して反映を確認する
robots.txt と sitemap.xml はビルド後の dist 直下に出力されているかを毎回確認する。public 配下の置き場所をうっかり間違えると、ビルドは通るがルートに出ない、という最も気付きにくい事故になる

よくある質問

Q. image sitemap と普通の sitemap.xml は別物？ A. image sitemap は sitemap.xml の中で各 URL に image:image エントリを並べる拡張仕様。普通の sitemap がページの一覧だけなのに対し、image sitemap は「そのページにどんな画像があるか」までクローラに伝える。vuepress-plugin-sitemap 2.x は標準では image エントリを出力しないため、画像も含めて伝えたい場合は別途プラグインで拡張するか、自前で sitemap を生成し直す必要があった。

Q. なぜ public 直下ではなく public/resources を切ったのか？ A. public 直下に全部置くと、記事画像・共通画像・favicon・robots.txt が同じ階層に混ざって見通しが悪くなる。public/resources を 1 階層挟むことで、記事画像（resources/カテゴリ/記事名）と公開ルート直下に置く必要があるもの（favicon・robots.txt）を物理的に分けられる。

Q. VuePress 1.x の sitemap プラグインは 2026 年でも使えるか？ A. 技術的にはまだ動くが、vuepress-plugin-sitemap も VuePress 1.x 自体もメンテはほぼ止まっている。新規構築なら Astro や Next.js のように sitemap 生成が公式に組み込まれている SSG を選んだ方が短期的にも長期的にも楽。既存サイトの保守なら、Node の LTS とプラグインのバージョンを固定して延命する形が現実的。

Q. robots.txt を public 直下以外に置くとどうなる？ A. ビルド後の dist 配下に robots.txt が出力されないので、ルート配信されず、クローラからは「robots.txt が無いサイト」として扱われる。VuePress では public 配下が dist のルートにコピーされる仕様のため、robots.txt を sitemap.xml と同じ階層で配信したいなら public 直下が唯一の置き場所になる。

まとめ

VuePress 1.x の image / sitemap 周りの初期設定は、public 直下と public/resources の役割を分け、favicon を config.js の head で読ませ、vuepress-plugin-sitemap で hostname と exclude を指定し、robots.txt を public 直下に置くだけで一通り回る。

設定そのものは小さいが、画像ディレクトリの切り方は記事数が増えてから直すと痛みが大きい。最初に「記事画像と共通画像は別の階層」という線だけ引いておくと、後で困りにくい。

2026 年現在の VuePress 1.x は新規構築の選択肢としては勧めにくいので、この記事は当時の構成思想を Astro などと比較するための資料として残している。

JOBY ゴリラポッド JB01542-PKK レビュー — Web カメラを柱に巻きつけて固定するための小型三脚

Wed, 03 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。JOBY のゴリラポッド JB01542-PKK は 2026 現在も現行ラインの一部として流通しているが、後継・派生モデル（GorillaPod Mobile / Magnetic / 1K 等）も増えている。本記事はあくまで「Web カメラ固定」という個別ユースケースのレビューとして読んでほしい。

リモートワークが始まった頃、机の脇にある柱に Web カメラを巻きつけて、目線より少し上に固定したかった。手持ちの汎用三脚ではどれも脚が伸びるだけで「柱に巻く」ができず、結局 JOBY のゴリラポッドを買い足した。

買ったのは JOBY ゴリラポッド JB01542-PKK（自由雲台 + 1/4 インチネジ、ミニサイズの可変脚タイプ）。半年ほど Web カメラ用途で常設したうえでのレビューを残しておく。

結論 — Web カメラを柱や手すりに固定したい人にはハマる

短い答え: 可動域の広い 3 本脚を柱に巻きつけて、目線より上に Web カメラを固定する用途には素直に強い。一方で、ミラーレスのような重い機材を載せる三脚としては自重 50g 台と軽すぎるし、ボール雲台は微調整が利かない。「軽い機材を、変な場所に固定する」専用機と割り切ると満足度が高い。

向く人:

在宅勤務で Web カメラやスマホを 柱・手すり・棚 に巻きつけて固定したい
旅行に 1 本だけ三脚を持っていきたい（スマホ・GoPro 用途）
モニター縁や机の脚に 変則的な置き方 をしたい

向かない人:

ミラーレス + 標準ズーム以上を載せたい（耐荷重と自重がともに足りない）
ボール雲台で 1° 単位の微調整をしたい
クイックリリースで頻繁にカメラを脱着したい

外観 — 全身プラスチック + 脚先ゴム、自重 50g 台の小型三脚

短い答え: 全体はプラスチック成形、脚の関節は球状で 360° 回転、脚先には滑り止めのゴムと小型磁石。手のひらにすっぽり収まるサイズ感で、Web カメラと組み合わせるとちょうど良いバランスになる。

分類としては 1/4 インチネジの自由雲台付き ミニ三脚。脚の関節がボール状に多数連なっていて、それぞれが独立して回転するので、結果として全体が自由に曲げられる。

可動域は手すり程度の太さ（直径 4cm 前後）なら脚 3 本で余裕で巻きつけられる。雲台のティルトはおおむね 90° までで、横倒し撮影もこなせる。

GoPro を載せるとこのくらいの大きさ。自重は約 52g（公称）、最大耐荷重は約 325g（公称）。ミラーレスでは重心が上に行きすぎてバランスを崩しやすい一方、スマホや GoPro、コンデジ、Web カメラとは相性がいい。

良かった点

短い答え: 「柱に巻く」「モニター縁に挟む」「机の脚に絡める」のような 置き場所を選ばない柔軟さ が、ふつうの三脚との最大の差。

脚の可動域が広い — 柱・手すり・棚に巻きつけられる

ふつうの三脚は床に置いて使う前提だが、JB01542-PKK は脚 3 本がそれぞれ自在に曲がるので、円柱状のものに 巻きつけて固定する のが現実的にできる。リモートワークの常設用途では、机横の柱に巻きつけて Web カメラを顔より少し上に置く、という配置が一発で決まった。

実際の常設状態。脚 1 本だけを柱の上に引っかけ、残りの 2 本を巻きつけて固定している。3 本全部を巻きつけても固定はできるが、脚 1 本を上向きに引っかけたほうがズレ落ちにくい。

軽い — 顔の高さに長時間置いても落下の罪悪感が薄い

自重 50g 台。Web カメラ（100g 前後）と合わせても 200g に届かない。頭の高さに長時間ぶら下げる 構成では、重さは即落下リスクなので、軽いこと自体が安心材料になる。震度 3 程度の揺れでもズレなかった（個人の試行範囲）。

脚先の磁石でスチール棚やキャビネットに簡易固定できる

脚先端に小型磁石が内蔵されている。スチール棚やキャビネット天板にコトッと置くだけで軽い吸着があり、巻きつけられない場所での簡易固定に役立つ。ただし吸着力単体でカメラを保持できるほど強くはないので、あくまで補助。

クイックリリース非搭載が、1/4 インチネジ機材だけ持つ人には逆に利点

Web カメラ・GoPro マウント・コンデジなど、自分が持っているカメラ側がすべて 1/4 インチネジ前提なら、クイックリリースは余計な変換を挟むだけ。JB01542-PKK は素直にネジ直結なので、変換アダプターを噛ませる必要がない。

微妙だった点

短い答え: 自重が軽すぎてミラーレスを載せると重心が上に行きすぎる / ボール雲台が硬く微調整が苦手 / クイックリリースがないので頻繁な脱着には向かない。

ミラーレスは重心が上に行きすぎる

耐荷重 325g（公称）はカタログ上クリアできるエントリー級ミラーレスもあるが、現実には 重心が高くなるほど倒れやすい。標準ズームを付けたミラーレスを試したところ、雲台のロックではなく脚の関節がたわむ方向にゆっくり倒れた。仕様外と割り切るのが安全で、ミラーレス以上は素直に大型三脚にしたほうがいい。

ボール雲台が硬く、1° 単位の微調整が苦手

雲台の角度ロックは 調節ネジを持たない圧入式 で、最初から強めの抵抗で固められている。落下防止には効くが、構図の微調整をしたいときに 5°〜10° 単位でしか動かしづらい。動画の水平を厳密に出したい人には不向き。

クイックリリース非搭載は脱着頻度が高い人にはマイナス

「1/4 インチネジ直結のメリット」と表裏一体。複数機材を頻繁に載せ替える運用だと、毎回ネジを回す手間が出る。常設運用前提なら問題にならない。

比較

短い答え: 「床に置く三脚」と比べると 置き場所の自由度 で圧勝。「他のフレキシブル三脚」と比べると、価格は安いが耐荷重と剛性で上位機（GorillaPod 1K / 3K 等）に劣る。

vs 一般的な伸縮式三脚

観点	JB01542-PKK	一般的な伸縮式ミニ三脚
設置場所	床・柱・手すり・棚縁	平らな床のみ
高さ調整	脚の曲げ方で変える	エレベーターで段階調整
自重	約 52g（公称）	200〜500g 前後
耐荷重	約 325g（公称）	1〜3kg クラスが一般的
微調整	苦手（ボール雲台が硬い）	3way 雲台モデルなら得意
価格帯	安価	同価格帯〜上位まで幅広い

伸縮式は 平らな床で重い機材を据える のが得意。JB01542-PKK は 平らでない場所に軽い機材を引っかける のが得意。用途が違うので、選択は「どこに置きたいか」で決まる。

vs 他のフレキシブル三脚（GorillaPod シリーズ内）

観点	JB01542-PKK	GorillaPod 1K Kit	GorillaPod 3K Kit
想定機材	スマホ・Web カメラ・GoPro	ミラーレス（軽量）	中型一眼レフ
耐荷重	約 325g	約 1kg	約 3kg
雲台	簡易ボール	ボール + パン	ボール + パン + アルカスイス互換
クイックリリース	なし	あり	あり
サイズ	ミニ（手のひら）	中型	大型
価格帯	最安	中位	上位

JB01542-PKK は GorillaPod シリーズ内では最も小型・軽量・安価なエントリーモデルという位置づけ。ミラーレス以上を想定するなら 1K 以上が安全圏。逆に「Web カメラとスマホしか載せない」なら 1K の重さと価格はオーバースペックになる。

よくある質問

Q. ミラーレス一眼を載せても大丈夫ですか？ A. メーカー公称の最大耐荷重は 325g 程度。エントリー級ミラーレス本体だけならギリギリだが、レンズを含めると超過することが多い。実用上はスマホ・コンデジ・Web カメラ・GoPro など 300g 以下の機材に絞ったほうが安心。

Q. 1/4 インチネジ以外のカメラでも使えますか？ A. 雲台は 1/4 インチネジのみ。クイックリリースは非搭載。一眼用のアルカスイス互換クランプを別途追加すれば実質的に共用できるが、自重が増えるので軽さの利点は薄れる。

Q. 脚の磁石はどのくらい強力ですか？ A. 脚先端に小型磁石が内蔵されており、スチール棚やキャビネット天板など金属面に軽く吸着する。これ単体でカメラを保持するほどの強さはなく、巻きつけや脚開きの補助として使う想定。

Q. 屋外撮影や旅行用途に向いていますか？ A. 自重 50g 台と軽く、バッグの隙間に入る大きさなので携行性は高い。一方で風には弱いので、屋外で長秒露光やタイムラプスをする用途では石やバッグで重しをするか、フルサイズの三脚を併用するのが無難。

総評 — 「軽い機材を、変な場所に置く」専用機

汎用三脚としては力不足だが、Web カメラを柱に巻きつける のような変則的な固定をしたい人にとってはこれ以外の選択肢がない、というタイプの製品。

半年常設で使った範囲では、Web カメラ + JB01542-PKK の組み合わせはトラブルなく動いた。震度 3 程度の地震でもズレ落ちず、ボール雲台のロックも緩まなかった。

逆にミラーレスを載せたい / 微調整したい / 頻繁に機材を載せ替えたい人には、上位の GorillaPod 1K Kit か、素直な伸縮式三脚のほうが満足度が高い。用途を絞れば強い、絞れないと弱い 三脚。

VuePress の Markdown 拡張メモ — Component / Slots / frontmatter（2021 アーカイブ）

Tue, 02 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。VuePress 1.x は新規構築の選択肢ではなくなったため、本文は「2021 年時点の Markdown 拡張メモ」として archive する目的で残す。Container や frontmatter の発想は MDX + Astro / Next.js にも引き継がれているので、比較資料として読んでもらえれば。

2021 年当時、Aulvem の前身ブログは VuePress 1.x で組んでいた。素の Markdown だけでは目次・補足ブロック・記事メタを扱いきれず、VuePress 独自の Markdown 拡張に何度か触ることになった。この記事はそのときの設定メモを、2026 年の視点で整理し直したもの。

VuePress 1 系は 2026 年現在ほぼメンテが止まっており、新規プロジェクトでの採用は勧めない。それでも Container や Component 埋め込みの考え方は MDX 系に引き継がれているので、当時の決め方を残しておく価値はある。

短い答え — VuePress の Markdown 拡張は3層に分けて考える

短い答え: VuePress 1.x の Markdown 拡張は「Vue Component 埋め込み」「名前付き Container（カスタムブロック）」「frontmatter」の3層に分けて捉えると整理しやすい。

理由は、それぞれの層で関わる設定ファイルと責務が違うから。Component は .vue ファイル側、Container は index.js のプラグイン設定とスタイル、frontmatter は記事メタとテンプレート側、と分けて考えると settings を見失わずに済む。

例として、繰り返し使う目次やフッターは Component、補足ボックスは Container、記事タイトル・カテゴリ・タグは frontmatter で表現する、という配分になる。

注意: 2026 年現在は MDX + フレームワーク（Astro / Next.js）が同じ役割をもっと素直に扱えるため、ここから先は「当時の VuePress 1.x ではこうだった」という archive として読んでほしい。

extendMarkdown — markdown-it の挙動を上書きする入口

短い答え: config.js の markdown.extendMarkdown で markdown-it インスタンスを直接いじれる。

VuePress 1.x は内部で markdown-it を使って Markdown をパースしており、extendMarkdown はその設定を上書きするためのフック。改行の扱い、リンクの target、シンタックスハイライト周りなどをここで調整した。

実際に使っていた設定は次のもの。エディタで改行した位置を <br> に変換する breaks: true を有効にしている。

markdown: {
  extendMarkdown: md => {
    md.set({ breaks: true })
  }
},

注意: breaks: true は1文ごとに改行する日本語ブログでは便利だが、英文段落をひとかたまりに書く運用とは相性が悪い。記事の書き方に合わせて選ぶ設定で、デフォルトでオンにすべきものではない。

Markdown 中に Vue Component を埋め込む

短い答え: VuePress では Markdown ファイルの中に Vue Component をそのまま書ける。

理由は、VuePress のビルドが Markdown を一度 Vue SFC に変換してからレンダリングしているため。.vue ファイル内と同じ記法でタグを書けば、ビルド時にコンポーネントとして解決される。

<Component名 />

繰り返し使うブロック（記事下の関連リンク、フッター、目次など）はこの方法で Component 化していた。

注意: Markdown と JSX 的な構文が同居するので、書き手側の前提知識が増える。読み手が編集者だけ・運用が小規模、というケースで効く設計で、外部ライターにも書いてもらうなら向かない。MDX も同じトレードオフを持つ。

名前付き Container でカスタムブロックを作る

短い答え: ::: type タイトル 〜 ::: 記法で、独自スタイルのブロックを定義できる。

VuePress 1.x はデフォルトで tip / warning / danger の3種類を持っており、index.js の container プラグイン設定で type を増やせる。中身は通常の Markdown として書ける。

書き方は次の通り。

::: 表示タイプ タイトル名
中はMarkdown形式で記述出来ます。
:::

これを書くと、type 名に応じた CSS が当たるブロックとしてレンダリングされる。例:

タイトル名

中はMarkdown形式で記述出来ます。

表示タイプは index.js のプラグイン設定で定義する。type が表示タイプ名、defaultTitle がタイトル未指定時のラベル、'/' キーは言語ごとに切り替えるための prefix（当サイトは日本語デフォルトなので / のままで動く）。

src   
└─ .vuepress
   └─ theme
      └─ index.js

module.exports = (options, ctx) => {
  return {
    plugins: [
      ['container', {
        type: 'type名',
        defaultTitle: {
          '/': 'デフォルトタイトル名',
        }
      }],
    ]
  }
}

スタイル定義は custom-blocks.styl 側に置いていた。tip / warning / danger の隣に、追加した type 名のセレクタを書き足す形。

src   
└─ .vuepress
   └─ theme
      └─ styles
         └─ custom-blocks.styl

  &.tip
  &.warning
  &.danger

注意: Container は markdown-it-container プラグインの仕組みであり、Markdown 寄りの軽量な拡張。JSX 的に任意のコンポーネントを呼び出したいなら、Component 埋め込みか MDX 側に倒すほうが向く。

frontmatter — 記事メタを Markdown の先頭に置く

短い答え: YAML 形式の frontmatter で、記事のタイトル・公開日・カテゴリ・タグ・画像などを定義する。

VuePress 側のテンプレートと plugin-blog の frontmatters 設定が、ここで宣言した値を読み取り、一覧ページや個別ページにメタを反映する。当時使っていた frontmatter は次のような形。

title: 【使い方】VuePress/plugin-blogを使用してブログを自作｜Markdown編
date: 2021-03-02
category:
  - skill
tag: 
  - VuePress
image: {{Path}}
location: japan

tag は plugin-blog の frontmatters に登録した名前を入れると、$tag や $currentTag に集計されて一覧に出る。category は登録なしで使えるが、内部の分類用に手で揃えていた。image は OG 画像兼サムネ。

注意: frontmatter のキー名はフレームワークごとに違う。VuePress 1.x は date / tag / category（単数形）だったが、Aulvem 現行（Astro）は pubDate / tags / category で揃えており、移植時にここでつまずきやすい。

Markdown 系フォーマット比較（2026 年視点）

観点	素の Markdown	VuePress 1.x Markdown	MDX
ベース	CommonMark / GFM	markdown-it + 拡張	Markdown + JSX
コンポーネント埋め込み	不可	Vue Component を直書き	任意の JSX / コンポーネント
カスタムブロック	引用 / リスト程度	`::: type` 記法（Container）	JSX コンポーネントで代替
frontmatter	ツール依存	あり（YAML）	あり（ツール依存）
2026 年の主な使い所	README / Issue	既存 VuePress 1.x サイト保守	Astro / Next.js などの静的サイト

VuePress 1.x の Container や Component 埋め込みは「Markdown を JSX 寄りに拡張する」発想の先駆けで、MDX が今ほぼ同じ役割を担っている。

よくある質問

Q. VuePress の Markdown と普通の Markdown は何が違うか？ A. VuePress は markdown-it ベースの Markdown に、Vue Component の埋め込み・名前付き Container（::: tip など）・frontmatter・PrismJS によるコードハイライトを追加した拡張版を出力する。素の Markdown より表現力は高いが、ビルド時に Vue ランタイムが前提になる点が違う。

Q. VuePress の Container（::: tip など）と MDX のコンポーネントの違いは？ A. Container は markdown-it-container プラグインで実装された記法で、Markdown 寄りの軽量な拡張。MDX は Markdown の中に JSX をそのまま書ける別仕様で、任意の React / Vue コンポーネントを式として埋め込める。Container はカスタムブロック、MDX は完全な JSX、と責務の広さが違う。

Q. 2026 年に VuePress 1.x を新規採用する意味はあるか？ A. ほとんどない。VuePress 1 系はメンテが実質止まっており、Vue 系で続けるなら VitePress、汎用なら Astro や Next.js + MDX のほうが情報量も拡張性も多い。既存サイトの保守目的でのみ残す形が現実的。

Q. extendMarkdown の breaks: true は必要か？ A. 好みによる。エディタで改行したところを <br> に変換する設定で、日本語ブログのように1文ごとに改行する書き方では便利。一方で英文のように段落をひとかたまりに書く場合は不要で、むしろ意図しない改行が増える原因になる。

2026 年に同じことをやるなら何を選ぶか

短い答え: Vue を残したいなら VitePress、フレームワーク非依存で書きたいなら Astro + content collections + MDX が近い体験になる。

理由は、VuePress 1 系がメンテほぼ停止である一方、VitePress は VuePress の後継として Vue チームが整理した形で、Astro は Markdown / MDX をネイティブに扱えるよう設計されているため。Aulvem は最終的に Astro に移行している。

注意: 2026 年時点での各ツールの正確な状態（最新版、メンテ体制、デフォルト機能）は公式ドキュメント側で確認してほしい。本記事はあくまで「2021 年に VuePress 1.x で書いた人が、後から振り返って整理した」観点のメモであり、現行ツール選定のリファレンスではない。

まとめ

VuePress 1.x の Markdown は、素の Markdown に Component 埋め込み・名前付き Container・frontmatter を足した拡張版で、当時は小〜中規模のドキュメント / ブログ用途に十分な表現力を持っていた。

2026 年現在、その役割は MDX + Astro / Next.js + content collections に置き換わっている。VuePress 時代の発想（記事メタを frontmatter で持つ、補足ブロックを記法で書く、再利用はコンポーネント化する）はそのまま新しいスタックでも通用するので、当時の設計記録としてこの記事を残しておく。

Belis ワイヤレステンキーレビュー — 電卓キー付き・USB 2.4GHz の薄型テンキー

Mon, 01 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。Belis ブランドのテンキーはロット違いで型番・スペックが変動するため、購入前に商品ページで「USB 2.4GHz」「電卓キー」「シザースイッチ」の3点を必ず確認すること。本文中のスペック値は執筆当時の購入個体のもの。

テンキーレスのキーボードで電卓的な数字打鍵をしていると、ホームポジションから指を伸ばすコストが地味に効いてくる。数字入力を1日に何度も挟む作業なら、独立したテンキーを横に置く方が早い。

そこで買ったのが Belis のワイヤレステンキー。価格帯としては手頃な部類で、USB 2.4GHz・電卓キー・薄型筐体という条件を満たしている。半年ほど使った視点で整理する。

結論 — 電卓キーを毎日叩く人なら買い

短い答え: 電卓キーが独立していて、USB 2.4GHz レシーバーで遅延なく繋がり、薄型でデスクの端に置きやすい。電卓を業務で立ち上げる頻度が高いなら、価格分の価値はある。

理由は、Windows のアプリケーションキーに電卓を割り当てて使っていた手間が、専用キー1発に置き換わるから。1日に十数回発生する操作が、毎回1〜2秒短縮される。

ただし以下に該当するなら別候補も検討した方がよい:

打鍵中に視界に光るものが入るのが嫌な人: 電源 ON 中は赤 LED が常時点灯する
薄型ではなく機械式の打鍵感が好きな人: シザースイッチのため、メカニカル相当のクリック感はない
Mac で使いたい人: 電卓キーが Mac で動くかは個体・OS バージョン依存

外観 — 黒の半光沢、6 度の傾斜、単4電池駆動

短い答え: 黒の半光沢仕上げで、薄型筐体に約 6 度の傾斜がついた、シザースイッチ採用のワイヤレステンキー。

天面は黒の半光沢。安っぽさはなく、デスクに置いたときの存在感は控えめ。

側面から見ると手前が薄く、奥に向かって約 6 度ほど立ち上がる形状（実測）。打鍵時に手首が反りすぎないちょうどよい角度。

裏面左上に電源スイッチ。給電は単4電池2本で、滑り止めのゴム足は機能している。充電池ではなく乾電池式なので、ケーブル取り回しの心配がない代わりに、電池の在庫管理は必要。

良かった点 — 電卓キー、無線の安定性、シザーの打鍵感

短い答え: 電卓キーが押したい瞬間にすぐ叩けること、USB 2.4GHz が想像以上に安定していること、シザースイッチの打鍵感がパンタグラフより気持ちいいこと。

電卓キーが独立している

このテンキーを買った一番の理由でもあり、使ってみての一番の満足点でもある。

それまでは Windows のアプリケーションキーに「電卓を起動」を割り当てて使っていたが、専用アイコン付きのキーが独立していると、視線で位置を確認しなくても押せる。押したい瞬間にスッと押せて、パッと電卓が立ち上がるこの動線が気持ちいい。

経費精算・在庫数の概算・簡単な四則演算など、1日のなかで「今ちょっと電卓欲しい」と感じる回数は意外と多い。割り当てキーから専用キーへの差は、1回あたりは小さいが累積すると効いてくる。

USB 2.4GHz レシーバーで遅延を感じない

無線テンキーには Bluetooth 式と USB 2.4GHz 式があるが、過去に Bluetooth キーボードで「打ったのに数十ミリ秒遅れて画面に反映される」感覚があったので、今回は USB レシーバー式を選んだ。

結果、半年使って数字入力時に遅延を感じた場面はゼロ。スリープ復帰直後でも待たされない。レシーバーを1ポート占有するのが許せるなら、安定性は Bluetooth より素直。

シザースイッチの打鍵感が思いのほか良い

事前にはノートPC のパンタグラフキーボードに近いものを想像していたが、実物はもう少しクリック感がある。シザースイッチを使うのは初めてだったが、薄型キーボードとメカニカルの中間くらいの感触で、長時間打っても指先が疲れにくい。

数字入力に特化した用途なら必要十分。

微妙だった点 — LED が打鍵中に主張する

短い答え: 電源 ON 中は本体の赤 LED が常時点灯し、視界の端で気になる。

写真だと控えめに写るが、実機を目の前に置くと、入力中に視界の隅で赤い点が常に光っている状態になる。電池消費の目安としては機能しているのだろうが、打鍵中の視覚ノイズとしては正直邪魔。

回避策としては、テンキーをモニターから少し離した位置に置く、視線方向に LED が入らない置き方にする、くらい。LED の物理的なオフ機能はない（ロットによって仕様が異なる可能性あり）。

長時間モニターと向き合う作業をするなら、置き場所で工夫する前提で考えた方がよい。

比較: Belis ワイヤレステンキー vs ほかの選択肢

USB 2.4GHz・電卓キー・薄型という条件で比較対象になりやすい構成を並べる。価格・スペック値は執筆当時の参考値で、ロットや時期により変動する。

観点	Belis ワイヤレステンキー	エレコム TK-TDM017 系（有線・電卓キー付き）	サンワサプライ Bluetooth テンキー
接続方式	USB 2.4GHz	USB 有線	Bluetooth
電卓キー	あり	あり	モデルによる
キー方式	シザースイッチ	メンブレン中心	パンタグラフ／メンブレン
給電	単4電池×2	USB バスパワー	内蔵充電池 or 乾電池
遅延の懸念	低い	なし（有線）	やや高め（環境依存）
デスクの取り回し	良い（無線・薄型）	ケーブル取り回しが要る	良い

スペックは執筆当時の購入個体・公開情報を参考にした概観で、最新ロットでは構成が変わっている可能性がある。

Bluetooth 遅延が気にならない人 → サンワサプライ系で OK。USB ポートを潰さない
絶対に遅延ゼロが欲しい人 → 有線のエレコム TK-TDM017 系。電卓キー付きの選択肢が豊富
無線で USB ポートを1つ犠牲にできる人 → Belis のような USB 2.4GHz 機。安定と取り回しの両取り

よくある質問

Q. Mac で電卓キーは動きますか？ A. macOS 側で「電卓」アプリにキー割り当てが行えない場合、専用電卓キーは反応しないか別のキーとして認識される可能性がある。Windows での動作は確認済みだが、Mac は OS バージョン・ロット依存で挙動が変わるため、買う前に商品ページで Mac 対応の明記を確認した方が安全。

Q. 電池はどのくらい持ちますか？ A. 単4電池2本で、毎日数字入力を挟む使い方をして、購入当初に入っていた電池が約2〜3ヶ月（個体差あり）。使い終わりに電源スイッチを切る運用にすれば持ちはさらに伸びる。

Q. ノートPC のキーボードと並べて使えますか？ A. 薄型筐体なので、ノートPC の右側に並べてもキーボード面の段差が小さく、手の移動が自然。デスクトップの薄型キーボードと並べる場合は、傾斜角がほぼ揃うので違和感が少ない。

Q. テンキーの配列はフルキーボードと同じですか？ A. 数字部分の配列はフルキーボードのテンキー部と同じ。NumLock の挙動も標準的。ファンクションキーや一部の記号キーは独自配置になっているので、フル配列を完全再現したい人は事前に商品画像でレイアウトを確認すること。

総評 — 「電卓キー」と「USB 無線」が刺さるなら選んで損はない

人を選ぶ製品ではある。

電卓キーが独立していること、USB 2.4GHz の無線で遅延が出にくいこと、薄型でデスクに馴染むこと — この3点が刺さるなら、価格に対する満足度は高い。事務作業で数字を多く扱う人、テンキーレスキーボードと組み合わせたい人には向いている。

逆に、LED の主張が気になりやすい人、メカニカルの強い打鍵感が好きな人、Mac 中心の人は別候補を検討した方が後悔は少ない。

VuePress/blog のディレクトリ構成 — 2021 年の構築メモ（アーカイブ）

Mon, 01 Mar 2021 00:00:00 GMT

2026 追記: 旧 VuePress ブログから移植した記事。VuePress 1.x はすでに新規開発の選択肢ではないため、本文は「2021 年時点の構築記録」としてアーカイブする目的で残している。ディレクトリの責務分割という考え方自体は Astro など現行の SSG にも通じるので、比較資料として読んでほしい。

2021 年当時、Aulvem の前身となる個人ブログは VuePress 1.x と @vuepress/plugin-blog で組んでいた。公式ドキュメント以外の情報が薄く、ディレクトリの切り方やプラグイン設定で何度も詰まったので、運用に乗せた時点でメモとして書き出したのがこの記事。

2026 年の今は Astro 5 に乗り換えており、VuePress 1.x はメンテも実質止まっている。なので以下は「当時の決め方の記録」として読んでもらえれば。

短い答え — VuePress 1.x の構成は _posts と .vuepress の二分割

短い答え: 記事 Markdown を _posts/、設定とテーマを .vuepress/ 配下に置く。これが plugin-blog を使う場合の定番だった。

理由は責務分離。コンテンツ（書く頻度が高い）とフレームワーク設定（書く頻度が低い）を別ディレクトリに分けると、デプロイログや git diff の見通しが良くなる。

具体的には次のような並びになる。

src
├─ _posts                   各記事 Markdown
│  └─ category
│     └─ page.md
└─ .vuepress
   ├─ components            記事用コンポーネント vue
   │  └─ Component.vue
   ├─ public
   │  └─ img.jpg
   ├─ theme
   │  ├─ components         コンポーネント vue
   │  │  └─ Component.vue
   │  ├─ layouts            ページレイアウト vue
   │  │  └─ Layout.vue
   │  └─ styles
   │     └─ style.styl
   ├─ config.js             vuepress 設定 js
   └─ enhanceApp.js         vue のプラグイン js

構築フェーズで触るのは config.js / enhanceApp.js / theme/ の 3 つ。運用フェーズで触るのは _posts/ と public/。役割が違うので、構築が終わったら触るファイルが自然に切り替わる。

注意点: この構成は VuePress 1.x + plugin-blog 1.9 系の前提。VuePress 2 系では設定ファイルの場所もテーマの仕組みも変わっているので、当時の設定をそのまま 2 系に持っていくと動かない。

用語: 静的サイトジェネレーター（SSG）とは

SSG (Static Site Generator): Markdown などのソースをビルド時に静的 HTML に変換するツールの総称。リクエスト時に毎回サーバーで動かす CMS（WordPress 等）と違い、出来上がった HTML を CDN に置くだけで配信できる。VuePress / Astro / Next.js (output:static) / Hugo / Jekyll などが該当する。

VuePress はこの SSG の一種で、Vue.js をベースに「Markdown を中心としたドキュメントサイト」を作ることに最適化されていた。plugin-blog はそこへ「ブログ的なルーティング（タグ・カテゴリ・記事一覧）」を後付けするプラグイン、と理解しておけばよい。

config.js — サイト全体の設定ファイル

短い答え: config.js は VuePress 本体と plugin-blog の設定を一緒に書く場所。サイトの言語・タイトル・ルーティングをここで決める。

理由は集約。プラグインや locale を別ファイルに散らすこともできるが、1 ファイルにまとめておくと「サイトの仕様書」として読める。

具体例は次のとおり。

module.exports = {
  locales: {
    '/': { lang: 'ja' }
  },
  title: 'Title(config.js)',

  plugins: [[
    '@vuepress/blog',
    {directories: [
      {
        id: 'home',
        dirname: 'home',
        path: '/',
      },
      {
        id: 'tech',
        dirname: '_posts/tech',
        path: '/tech/',
        itemPermalink: '/tech/:slug'
      }
    ],
    frontmatters: [
      {
        id: "tag",
        keys: ["tag"],
        path: "/tag/",
        layout: "Tag",
        scopeLayout: "Tag"
      },
    ],},
  ]]
}

locales — デフォルト言語

locales でサイトの既定言語を決める。日本語サイトなら / を lang: 'ja' にしておけば足りる。多言語化したい場合は /en/ を別キーで足す形になる。

title — サイトタイトル

title はサイト名として使う。Vue ファイル側からは $siteTitle で参照できる。OG 画像生成やヘッダーロゴ差し替えのときに参照点になるので、ここを直接ハードコードしないのが運用上は楽。

plugins — VuePress プラグインの登録

plugins 配列に VuePress プラグインを足していく。@vuepress/blog を含む各プラグインは、設定オプションを渡したい場合に「文字列単体」ではなく [name, options] のタプルにする、というのが当時のルールだった。

詳細オプションは各プラグインのドキュメント側に当たる必要がある。ここに全部書こうとすると config.js が肥大化するので、当時はコメントで参照先 URL を残していた。

plugins/directories — URL のディレクトリ構成

directories で「どの Markdown フォルダをどの URL に出すか」を決める。Aulvem 前身ブログではカテゴリ構成をそのまま URL に落としたかったので、カテゴリ単位で配列要素を足していた。

{
  id: 'tech',
  dirname: '_posts/tech',       該当カテゴリの記事を置くファイル Path
  path: '/tech/',               /tech/{{記事のpath}}
  itemPermalink: '/tech/:slug'  {{記事のpath}}のフォーマット。:slug は日付を除いたファイル名
}

注意点: dirname: '_posts/tech' の探索は 直下までしか効かず孫ディレクトリは拾わない（plugin-blog 1.9 系での挙動）。つまりカテゴリの階層は実質 1 段までだった。サブカテゴリを切りたい場合は directories を増やすしかない。

itemPermalink は日付パートを含めるかどうかを切り替えられる。私の場合は URL に日付を入れたくなかったので :slug のみで運用した。SEO 上「URL に日付があると古さが出る」という当時の通説に従ったかたち（検索順位への影響の有無はケースバイケース）。

plugins/frontmatters — タグ機能

frontmatters でタグを生成する。keys: ["tag"] と書くと、Markdown の frontmatter に書いた tag がタグページとして扱われるようになる。

{
  id: "tag",
  keys: ["tag"],          Markdown の frontmatter に設定する Key
  path: "/tag/",
  layout: "Tag",
  scopeLayout: "Tag"
}

これを書くと、グローバルに $tag と $currentTag という変数が生える。

$tag は全タグの一覧と、それぞれに紐づく記事リスト。タグ一覧ページを作るときに使う。
$currentTag は個別タグページを開いたときの「現在のタグ」の情報。

$currentTag の中身はこういう形だった。

現在のページの`$currentTag`オブジェクト内
key: "Vue"
pageKeys: ["xxxxxx"]
pages: [{...}]
path: "/tag/Vue/"
scope: "tag"

注意点: この種の「グローバル変数生成」型 API は、TypeScript との相性が悪い（型がつかない）。Astro の content collections のように、スキーマで型を強制する方が今は主流という感覚がある。

enhanceApp.js — Vue プラグインの差し込み口

短い答え: 通常の Vue プラグインを VuePress に組み込むためのエントリ。Vue.use を書く場所だと思えばよい。

理由は VuePress 自体が裏で Vue インスタンスを生成しているため、ふつうの SPA のように main.js で Vue.use() できない。代わりに enhanceApp.js が引数で Vue インスタンスを渡してくれる。

import VScrollLock from 'v-scroll-lock'

export default ({
  Vue,
  options,
  router,
  siteData
}) => {
  Vue.use(VScrollLock)
}

注意点: ここに重い処理を書くと、すべてのページの初期化が遅くなる。基本は Vue.use だけに留めて、本格的なロジックはコンポーネント側に書く方がよかった。

theme — レイアウトと CSS の置き場

短い答え: theme/ は記事以外の Vue ファイルと CSS を置くディレクトリ。npm run eject でデフォルトテーマをコピーして上書きする運用だった。

理由は VuePress のデフォルトテーマがそのままでは出力されないから。eject を叩くと .vuepress/theme/ 配下にデフォルトテーマ一式が展開され、好きに書き換えられる。

eject 直後のディレクトリはこうなる。

theme
├── `global-components`
│   └── xxx.vue
├── `components`
│   └── xxx.vue
├── `layouts`
│   ├── Layout.vue _(**Mandatory**)_
│   └── 404.vue
├── `styles`
│   ├── index.styl
│   └── palette.styl
├── `templates`
│   ├── dev.html
│   └── ssr.html
├── `index.js`
├── `enhanceApp.js`
└── package.json

画面パーツの編集や追加は components/ 以下、CSS は Vue ファイル内か styles/ で書く。layouts/Layout.vue は必須なので、消したり名前を変えたりすると即ビルドが落ちる。

注意点: eject すると以後のテーマアップデートを自動で追従できなくなる。当時の私はそれを承知で乗せたが、今やるなら「最小限のオーバーライド」だけ書いて本体テーマを使い続ける構成の方が保守は楽（VuePress 2 系では別の仕組みになっている可能性あり）。

比較表 — VuePress 1.x と 2026 年の主要 SSG

当時の VuePress と、2026 年現在で同じ用途に使われやすい SSG の責務感を並べておく。

観点	VuePress 1.x (2021)	Astro 5 (2026)	Next.js (App Router)	Hugo
主言語	Vue 2	フレームワーク非依存	React	Go テンプレ
ターゲット	ドキュメント / 小規模ブログ	コンテンツサイト全般	アプリ含む広範囲	大量ページの静的サイト
設定ファイル	`.vuepress/config.js`	`astro.config.mjs`	`next.config.js`	`config.toml`
記事の配置	`_posts/**`	`src/content/**`	`app/**` または MDX 配置自由	`content/**`
型安全	なし（グローバル変数）	content collections で zod	TS と RSC	なし
部分ハイドレーション	全体が SPA	islands（既定で静的）	RSC + Client Component	静的のみ
2026 のメンテ状況	1 系は実質停止	アクティブ	アクティブ	アクティブ

ここで言いたいのは優劣ではなく、責務の切り方が違うということ。「Markdown 中心のブログを静的に出力する」というユースケースだけなら VuePress 1.x の構成は十分機能していた。Aulvem 自体は記事数の増加と型安全を理由に Astro へ移った。

よくある質問

Q. VuePress 1.x は 2026 年でも使えるか？ A. 動かすこと自体は可能。ただし plugin-blog を含めメンテはほぼ止まっており、依存パッケージの脆弱性対応も期待しづらい。新規構築では選ばない方が無難で、既存サイトの延命なら Node のバージョンと npm のロックファイルをきっちり固定するのが最低条件。

Q. VuePress と Astro / Next.js の違いは？ A. VuePress は Vue 2 ベースで「Markdown 中心のドキュメントサイト」が出発点。Astro はフレームワーク非依存で部分ハイドレーション（islands）を採用し、Markdown と動的部分を混在しやすい。Next.js は React 製で、静的サイトから動的アプリまで広く扱える。同じ「静的サイト」でも、扱える範囲と前提が違う。

Q. _posts と .vuepress を分ける意味は？ A. 「記事コンテンツ」と「フレームワーク設定」の責務分離。書く頻度の違うものを別ディレクトリにまとめる発想自体は、Astro の src/content/ と src/layouts/ の分割にも引き継がれている。逆に Next.js の App Router のように app/ 配下にすべて並べる思想もあり、ここは設計趣味の領域。

Q. 今から似た構成を組むなら何を選ぶ？ A. Markdown 中心のブログなら Astro + content collections が体験的に最も近い。Vue を維持したい場合の後継候補は VitePress や Nuxt Content だが、それぞれカバー範囲が違うので、用途に合うかは公式ドキュメントで要確認。

まとめ

VuePress 1.x の構成は「_posts に書く、.vuepress で設定する」というシンプルな責務分割の上に成り立っていた。当時はその素直さに助けられ、運用に乗せるまでこぎ着けられた。

2026 年現在、Aulvem 本体は Astro 5 で動いている。同じディレクトリ分離の思想は形を変えて残っているので、この記事は「過去のスナップショット」として、現行 SSG との比較資料に使ってもらえればと思う。

項目	スペック
サイズ	15.6インチ
表示形式	IPS
解像度	フル HD（1920×1080）
色域	NTSC 88%
応答速度	14ms
ラミネーション加工	有り
斜め検知	有り

Aulvem Blog (日本語)

楽天APIがJANを返さない問題と、横断マッチングの3段階

楽天とYahoo!でJANの扱いは非対称

確実性で3段階に倒す

①JAN突合: 楽天は「JANらしさ」を加点で確かめる

②名前ファジー一致: 候補提示までで自動確定しない

③マッチ不能: 単一モールの値下げ通知に倒す

誤名寄せを防ぐのは「確定だけ通知する」設計

よくある質問

楽天 API は JAN をまったく取得できないの？

なぜ全部を JAN で突合しないの？

名前ファジー一致を自動で確定しないのはなぜ？

マッチできなかった商品はどうなる？

ポイント還元込みの「実質価格」をどう計算したか — 3層に分けた設計メモ

まず「実質価格」を定義する

素朴な実装はどこで壊れたか

設計の軸: ポイントを確実性で3層に分ける

端数は層ごとに floor してから合算する

ランキングのキーと表示価格を分ける

送料はあえて実質価格に入れない

振り返り

よくある質問

ポイントを全部引いた金額で比較してはだめ？

期間限定ポイントや要エントリーのキャンペーンはどう扱う？

送料を実質価格に入れないと最安が逆転しない？

なぜランキングと表示する実質価格で使う層を変えるの？

llms.txt / llms-full.txt を Astro で多言語生成する — Aulvem の GEO 実装

llms.txt とは何か

Astro で生成する基本形

Content Collections を単一情報源にする

多言語をどう分けるか

代表記事は docLang の言語で絞る

llms-full.txt — 全文インデックスと言語の相互参照

robots.txt との役割分担

落とし穴と運用ルール

まとめ

よくある質問

llms.txt と llms-full.txt は何が違う？

llms.txt を出せば AI に読まれて流入が増える？

多言語サイトで llms.txt は言語ごとに分けるべき？

robots.txt があるのに llms.txt も要る？

hreflang を両言語にある記事だけリシプロカルに出す — Aulvem の i18n カスタマイズ

全 locale に alternate を出すと何が壊れるか

Google が要求する 2 つの条件

実体存在判定ヘルパ 3 つ

Seo.astro で条件付き出力

使用側レイアウト

全体図

ルーティングは Astro 標準のまま

落とし穴と運用ルール

まとめ

よくある質問

Astro 標準が hreflang を自動で出さないのはなぜ？

@astrojs/sitemap の i18n オプションで出る hreflang ではダメ？

x-default は何を指すべき？

1 言語にしか実体がない記事の SEO 評価は損なわれない？

sitemap の lastmod を MDX frontmatter から自分で差し込む — Aulvem の Astro 公式統合カスタマイズ

lastmod がなぜ効くのか

ビルド時に MDX を走査して lastmod マップを作る

serialize でマップから lastmod を流す

paginated noindex ページを filter で外す

全体の流れ

落とし穴と運用ルール

何を諦めたか / 公式統合に戻すべき境界

まとめ

よくある質問

Astro 公式の sitemap が updatedDate を読まないのはなぜ？

Content Collections の API を使わずに fs.readdir で読むのは型安全ではないのでは？

noindex のページを sitemap に送ってはダメなのか？

lastmod を実日付にすると AI 検索の引用率は本当に変わるのか？

Zod schema で運用ルールを強制する — Aulvem の Content Collections 設計

なぜ README だけでは守れないのか

Aulvem の schema 全体像

reviews ⇔ affiliate を .refine() で同期させる

howto / faq を frontmatter で型付けする

schema では検出できない — frontmatter と本文の文字列一致

schema 化しないと決めたもの

schema / lint / レビューの 3 層分担

まとめ

よくある質問

`@astrojs/sitemap` の i18n オプションで出る hreflang ではダメ？

`x-default` は何を指すべき？

`serialize` でマップから lastmod を流す

paginated noindex ページを `filter` で外す

Astro 公式の sitemap が `updatedDate` を読まないのはなぜ？

`noindex` のページを sitemap に送ってはダメなのか？

reviews ⇔ affiliate を `.refine()` で同期させる

Zod の `.refine` と `.superRefine` はどう使い分ければいいか？

Figmaの使い方〜基礎編３〜スタイル登録とバリアンツでデザインを管理する

Figmaの使い方〜基礎編２〜枠線・グループ化・コンポーネント・オートレイアウト

Figmaの使い方〜基礎編１〜フレーム・テキスト・整列など最初の基本操作

Figmaの使い方〜準備編〜アカウント作成・チーム作成・デザインファイル作成まで