プレフィックス（prefix）とは｜IT での意味6種と接尾辞との違いを実測で

「プレフィックス」は、どの分野でも「先頭に付いていて、そこを見れば種類や範囲が分かるもの」です。分野ごとに、何の先頭に何を付けるのかが変わります。

flowchart LR
    P[プレフィックス<br>先頭に付けて意味を示す] --> S[文字列・名前<br>img_ / feat:]
    P --> C[CSS<br>-webkit-transform]
    P --> I[IPアドレス<br>192.168.1.0/24]
    P --> U[単位<br>kB と KiB]
    P --> D[データベース<br>LIKE 'abc%']

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS の上で、文字列の例は Python 3.13.18・Node.js 22.23.4・bash 5.2.21 で実行しました。CSS のベンダープレフィックスは、127.0.0.1 に置いた自分のページを Chromium 153.0.8010.12（playwright 1.63.0）で開き、CSS.supports() で1つずつ確かめ、Autoprefixer 10.6.2（browserslist 4.29.5・caniuse-lite 1.0.30001820）の出力と比べました。IP アドレスは Python の ipaddress モジュールと、自分の ip netns の中に作った経路表（ip route get）で、単位の接頭辞は GNU coreutils 9.4 の ls・du・df・numfmt で確かめました。データベースは、作業用の場所に展開した MySQL 8.0.46 と PostgreSQL 16.15 を 127.0.0.1 の専用ポートに起動し、30万〜100万行の表で EXPLAIN を取りました（終わったら DROP して停止）。コミットメッセージは git 2.43.0 です。定義は MDN・PostgreSQL・MySQL・Python の公式ドキュメント、電話番号の「0」は総務省のページで確かめました。図は mermaid 11.16.0 で描画を確かめています（確認日 2026年10月29日）。

プレフィックスとは（意味とサフィックスとの違い）

この節では、プレフィックスという言葉の意味と、サフィックス（接尾辞）との違いが分かります。

プレフィックス（prefix）は「前に（pre）固定する（fix）」が語源で、日本語では接頭辞と訳します。 英語の un-happy の un-、re-start の re- のように、先頭に付いて意味を足す部分です。IT では「番号・符号・名前の先頭に付けて、種類や意味、範囲を示す短い部分」という意味で使い、ファイル名の img_、関数名の get、IP アドレスの /24 がどれもプレフィックスです。

なお、先頭でも末尾でもなく語の途中に入るものはインフィックス（接中辞）と呼び、1 + 2 のように演算子を間に書く記法を中置記法と言います。IT で「プレフィックス」とだけ言われたら、まず「先頭に付いているもの」と考えれば外れません。

IT でのプレフィックスの使い分け一覧（6つの意味）

この節では、IT の文脈で「プレフィックス」が指すものを分野ごとに一覧で確かめられます。

どの分野でも「先頭にあり、そこを見ると種類か範囲が分かる」点は同じですが、何の先頭かが違います。 検索で出会ったときに、どの意味で使われているかをこの表で当てはめます。

文字列のプレフィックス：startswith・removeprefix の実行結果

この節では、プログラムで「先頭がこの文字列か」を調べる方法と、先頭を取り除く方法の実行結果が分かります。

先頭の判定は startswith、取り除くのは removeprefix（Python 3.9 以降）で、どちらも「無ければ何もしない」のが決まりです。 Python 3.13.18 で次の通り動きました。

s = "https://www.r-jc.jp/news-blog/840/"
print(s.startswith("https://"))                 # True
print(s.startswith(("http://", "https://")))    # True（タプルでどれかに一致）
print(s.removeprefix("https://"))               # www.r-jc.jp/news-blog/840/
print("report.pdf".removeprefix("img_"))        # report.pdf（無ければそのまま）
print("img_img_a.png".removeprefix("img_"))     # img_a.png（1回だけ外す）

似た名前の lstrip は「先頭から、指定した文字の集まりに含まれる文字を削る」関数で、プレフィックスを外す関数ではありません。手元では次のように、意図しない文字まで消えました。

print("image.png".lstrip("img_"))        # 'age.png'  ← i・m が削られた
print("image.png".removeprefix("img_"))  # 'image.png' ← img_ で始まらないので変わらない

JavaScript（Node.js 22.23.4）と bash（5.2.21）にも同じ考え方の書き方があります。bash の ${変数#パターン} は「先頭から最短で一致した部分を外す」で、## にすると最長一致になります。

const s = "https://www.r-jc.jp/news-blog/840/";
console.log(s.startsWith("https://"));      // true
console.log(s.startsWith("www", 8));        // true（8文字目から見る）
console.log(s.replace(/^https:\/\//, ""));  // www.r-jc.jp/news-blog/840/（removePrefix は無いので正規表現の ^ で）

v=img_report.pdf
echo "${v#img_}"      # report.pdf   （先頭の img_ を外す）
echo "${v##*_}"       # report.pdf   （最長一致：最後の _ まで外す）
[[ $v == img_* ]] && echo "img_ で始まる"

Python の文字列メソッド全体は、関連記事「Python 文字列操作 一覧｜全メソッド逆引きと3.14実行結果」で扱っています。

最長共通接頭辞と前方一致検索の速さ（実測）

この節では、複数の文字列に共通する先頭部分の求め方と、「前方一致は並べ替えておくと速い」理由が数値で分かります。

最長共通接頭辞（Longest Common Prefix）は、Python なら os.path.commonprefix で求まります。 名前の通りパス用の関数ですが、中身は文字単位の比較なので任意の文字列に使えます（パスとして区切りを守りたいときは commonpath）。

import os
print(os.path.commonprefix(["flower", "flow", "flight"]))     # fl
print(os.path.commonprefix(["/usr/local/bin", "/usr/lib"]))   # /usr/l   ← 文字単位
print(os.path.commonpath(["/usr/local/bin", "/usr/lib"]))     # /usr     ← パス単位

前方一致には「辞書順に並べると、同じ接頭辞を持つ文字列が隣り合う」という性質があります。8文字のランダムな文字列100万件から abc で始まるものを探す処理を、先頭から1件ずつ見る方法と、並べ替えてから二分探索で範囲を切り出す方法で比べました。

import bisect
r1 = [w for w in words if w.startswith("abc")]           # 1件ずつ見る
words.sort()
lo = bisect.bisect_left(words, "abc")                    # abc 以上の最初
hi = bisect.bisect_left(words, "abd")                    # abd 以上の最初（= abc… の次）
r2 = words[lo:hi]

「abc 以上 abd 未満」という範囲の切り出しが、後で見るデータベースの B-tree 索引が前方一致 LIKE を速く処理できる理由そのものです。PostgreSQL の実行計画にも email >= 'abc' AND email < 'abd' という条件がそのまま出てきます。

命名規則のプレフィックス（is_・get・ファイル名・環境変数・電話番号）

この節では、名前の先頭に付けて役割を伝えるプレフィックスの代表例と、やりすぎたときの害が分かります。

命名規則のプレフィックスは「読む人が先頭だけ見て、型や役割、用途を当てられる」ようにするためのものです。 統一されていれば読みやすく、混ざっていればかえって混乱の元になります。

電話番号にも同じ言葉が使われます。総務省のページでは、固定電話番号の初めの「0」を「国内プレフィックスと呼んでおり、国内通話を示す『合図』」と説明しています。日本から国際電話をかけるときに先頭に付ける「010」は国際プレフィックス、「00XY」の形で先頭に付けて通信事業者を選ぶ番号は事業者識別番号です。どれも「相手の番号の前に付けて、つなぎ方を示す」ので、意味はプログラミングの接頭辞と同じです。

コミットメッセージのプレフィックス（feat・fix・docs）

この節では、Git のコミットメッセージの先頭に付ける種類の印と、付けておくと何ができるかが分かります。

Conventional Commits では、1行目を 種類(範囲): 要約 の形にし、種類に feat・fix・docs・chore などを置きます。 この種類の部分がプレフィックスです。手元の git 2.43.0 で5つのコミットを作り、履歴と絞り込みを確かめました。

$ git log --oneline
feat!: /api/v1 を廃止し /api/v2 のみにする
chore(deps): autoprefixer を 10.6.2 に更新
docs: READMEにKBとKiBの説明を追加
fix: removeprefix が2回効いていた不具合を直す
feat: 検索欄に前方一致の候補を出す

$ git log --oneline --grep='^fix'
fix: removeprefix が2回効いていた不具合を直す

プレフィックスが揃っていると、--grep で種類ごとに履歴を絞れるほか、変更履歴（CHANGELOG）の自動生成や版番号の自動決定に使えます。種類の一覧と日本語の例文は、関連記事「コミットメッセージの書き方｜ルール・例文・プレフィックス一覧」で扱っています。

CSS のベンダープレフィックス：-webkit- は今も要るか（Chromium 153 で確認）

この節では、CSS の -webkit-・-moz-・-ms-・-o- の意味と、2026年10月29日時点でどれが今も要るのかが分かります。

ベンダープレフィックスは、ブラウザの開発元が標準化前の機能を先行して実装するときに付けた印です。 MDN は -webkit-（Chrome・Safari・Edge など WebKit 系）、-moz-（Firefox）、-ms-（Internet Explorer と以前の Edge）、-o-（WebKit 導入前の Opera）の4つを挙げ、transition の例について「最後の行（プレフィックス無し）以外は除去しても問題ない」と説明しています。今の実験的な機能はフラグで制御され、新しいプレフィックスは増えません。

127.0.0.1 の自分のページを Chromium 153.0.8010.12 で開き、CSS.supports() でプロパティごとに「プレフィックス無し」と「プレフィックス付き」が受け付けられるかを確かめました。

擬似要素も同じで、::placeholder と ::-webkit-input-placeholder はどちらも使え、::-moz-placeholder は Chromium では使えませんでした。::-webkit-scrollbar のように、プレフィックス付きしか無いものも残っています。

Autoprefixer の出力で「今の既定」を見る

手で付けるのではなく、対象ブラウザの一覧（browserslist）から必要なプレフィックスだけを足すのが Autoprefixer です。同じ CSS を、既定の対象（defaults）と、以前のブラウザまで含めた対象（last 12 versions, ie 11）で変換しました。

/* 入力 */
.a { display: flex; transform: rotate(1deg); transition: all 1s; user-select: none;
     backdrop-filter: blur(2px); appearance: none; background-clip: text; }
::placeholder { color: gray; }

/* 既定（defaults）での出力：flex・transform・transition には何も付かない */
.a { display: flex; transform: rotate(1deg); transition: all 1s;
     -webkit-user-select: none; -moz-user-select: none; user-select: none;
     backdrop-filter: blur(2px);
     -webkit-appearance: none; -moz-appearance: none; appearance: none;
     -webkit-background-clip: text; background-clip: text; }
::-moz-placeholder { color: gray; }
::placeholder { color: gray; }

/* last 12 versions, ie 11 での出力（抜粋）：-ms- や -webkit-box まで付く */
.a { display: -webkit-box; display: -ms-flexbox; display: flex;
     -webkit-transform: rotate(1deg); -ms-transform: rotate(1deg); transform: rotate(1deg);
     -webkit-transition: all 1s; transition: all 1s; ... }
::-webkit-input-placeholder { color: gray; }
:-ms-input-placeholder { color: gray; }

• 1手で -webkit- を書かない対象ブラウザは変わる。Autoprefixer（PostCSS）か、Vite・Next.js など同梱のビルドに任せる
• 2プレフィックス無しを最後に書く後に書いた宣言が勝つ。標準の書き方を最後に置くと、対応したブラウザで標準が使われる
• 3今も必要なものを覚えておく-webkit-line-clamp・-webkit-text-stroke・::-webkit-scrollbar は無し版が Chromium 153 で false だった
• 4browserslist の対象を見直すdefaults の中身は caniuse-lite の版で変わる。npx browserslist で一覧を出して確かめる

IP アドレスのプレフィックス長：/24 と /25 でホスト数はどう変わるか

この節では、192.168.1.0/24 の「/24」が何を表すのかと、長さを1つ変えると使えるアドレスがいくつになるかが分かります。

IP アドレスのプレフィックス長は、32ビットのうち先頭何ビットがネットワーク部（どのネットワークか）を表すかの数です。 /24 なら先頭24ビットがネットワーク部で、残り8ビット（256通り）がそのネットワークの中の機器（ホスト部）に使えます。サブネットマスクで書けば 255.255.255.0 で、先頭から1が24個並びます。CIDR（RFC 4632）で決まった表記で、長いほど小さなネットワークです。

Python 3.13 の ipaddress モジュールで、長さごとのアドレス数・使えるホスト数・範囲を出しました。

import ipaddress as ia
for p in ["192.168.1.0/24", "192.168.1.0/25", "192.168.1.128/25", "192.168.1.0/26", "192.168.1.0/30"]:
    n = ia.ip_network(p); h = list(n.hosts())
    print(p, n.netmask, n.num_addresses, len(h), h[0], h[-1], n.broadcast_address)

/24 を /25 に1つ伸ばすと、ネットワークは2つに割れ、使えるホストは254から126に減ります（ネットワークアドレスとブロードキャストの2つが各ネットワークで消えるため）。ip_network("192.168.1.5/24") のようにホスト部が0でない書き方は ValueError: 192.168.1.5/24 has host bits set になり、strict=False を付けると 192.168.1.0/24 に丸められました。IPv6 では /64 が1つのネットワークの標準的な長さで、ホスト部だけで 2 の 64 乗（約1,845京）個になります。

ロンゲストマッチ：長いプレフィックスが勝つ

経路表に重なる範囲があるとき、ルーターは「プレフィックスが最も長い（範囲が最も狭い）経路」を選びます。自分の ip netns の中に3つの経路を作り、ip route get で確かめました。

$ ip route
192.168.0.0/16 dev v1 scope link
192.168.1.0/24 dev v2 scope link
192.168.1.128/25 via 10.1.0.2 dev v1

$ ip route get 192.168.5.5
192.168.5.5 dev v1 src 10.1.0.1            ← /16 だけに当たる
$ ip route get 192.168.1.5
192.168.1.5 dev v2 src 10.2.0.1            ← /16 と /24 に当たり、長い /24 が勝つ
$ ip route get 192.168.1.200
192.168.1.200 via 10.1.0.2 dev v1 src 10.1.0.1   ← /25 が最も長い

/0〜/32 の一覧表と計算は関連記事「CIDR計算・サブネット早見表｜/0〜/32一覧とPython計算コード」、2進数での計算の手順は関連記事「サブネットマスクとは｜計算方法・早見表・確認方法を図と実例で解説」で扱っています。

単位の接頭辞：KB と KiB（1,000 と 1,024）の差を ls・df で実測

この節では、k・M・G と Ki・Mi・Gi の違いと、同じファイルがコマンドによって違う大きさに見える理由が分かります。

SI 接頭辞の k・M・G は 1,000 倍ずつ、2進接頭辞の Ki・Mi・Gi（キビ・メビ・ギビ）は 1,024 倍ずつです。 IEC が定めた 2 進接頭辞は NIST のページにまとめられており、1 KiB = 1,024 B、1 MiB = 1,048,576 B です。差は桁が上がるほど開きます。

ちょうど 1,000,000 バイトのファイル a と、1,048,576 バイトのファイル b を作り、表示を比べました。

$ ls -l a b              # バイト数そのまま
1000000 a
1048576 b
$ ls -lh a b             # 1024 刻み（K・M と書くが中身は Ki・Mi）
977K a
1.0M b
$ ls -lh --si a b        # 1000 刻み
1.0M a
1.1M b
$ numfmt --to=iec 1000000 1048576 ; numfmt --to=si 1000000 1048576
977K / 1.0M              1.0M / 1.1M
$ df -h /dev/shm ; df -H /dev/shm
tmpfs  7.9G ...          tmpfs  8.5G ...
$ free -h | head -2 ; free --si -h | head -2
Mem: 7.8Gi ...           Mem: 8.4G ...

「1 TB の SSD を買ったのに 931 GB しか無い」の正体は、製品が 10 進（10^12 バイト）で、OS の表示が 2 進（1024^4）だからで、どちらも間違いではありません。文書に書くときは、1,024 刻みなら KiB・MiB・GiB と書くと誤解がなくなります。

データベースの前方一致 LIKE 'abc%' と EXPLAIN（MySQL・PostgreSQL）

この節では、前方一致の検索が索引を使えて、後方一致・部分一致が使えない様子が、実行計画の原文で分かります。

B-tree 索引は値を並べ替えて持つので、「abc で始まる」は「abc 以上 abd 未満」の範囲として一気に取り出せます。 一方「abc で終わる」は、先頭が何でもよいので並び順が役に立たず、全行を見ることになります。先ほどの二分探索の実測と同じ理屈です。

MySQL 8.0.46（30万行、email に B-tree 索引）

mysql> EXPLAIN SELECT * FROM users WHERE email LIKE 'abc%'\G
         type: range
possible_keys: users_email_idx
          key: users_email_idx
         rows: 300
        Extra: Using index condition

mysql> EXPLAIN SELECT * FROM users WHERE email LIKE '%@example.com'\G
         type: ALL
possible_keys: NULL
          key: NULL
         rows: 298899
        Extra: Using where

mysql> EXPLAIN SELECT * FROM users WHERE LOWER(email) LIKE 'abc%'\G
         type: ALL            ← 列を関数で包むと前方一致でも使えない
          key: NULL

SHOW PROFILES での所要時間は、前方一致（300件）が 0.0007 秒、後方一致（1件）が 0.228 秒でした。件数が少ない方が、全行を見るぶん遅くなっています。

PostgreSQL 16.15（100万行）：ロケールが C でないと text_pattern_ops が要る

PostgreSQL では、既定の B-tree 索引がロケール（照合順序）の規則で並べるため、データベースが「C」ロケールでないと前方一致 LIKE に索引が使われません。公式ドキュメントは、その場合に text_pattern_ops という演算子クラスで索引を作るよう説明しています。手元の C.UTF-8 ロケールのデータベースでも、既定の索引では使われませんでした。

t112db=# CREATE INDEX users_email_idx ON users(email);
t112db=# EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF) SELECT * FROM users WHERE email LIKE 'abc%';
 Gather (actual rows=1000 loops=1)
   ->  Parallel Seq Scan on users (actual rows=333 loops=3)     ← 索引があっても全行走査
         Filter: (email ~~ 'abc%'::text)
         Rows Removed by Filter: 333000

t112db=# CREATE INDEX users_email_pat_idx ON users(email text_pattern_ops);
t112db=# EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF) SELECT * FROM users WHERE email LIKE 'abc%';
 Bitmap Heap Scan on users (actual rows=1000 loops=1)
   ->  Bitmap Index Scan on users_email_pat_idx (actual rows=1000 loops=1)
         Index Cond: ((email ~>=~ 'abc'::text) AND (email ~<~ 'abd'::text))   ← 範囲に変換された

t112db=# EXPLAIN ... WHERE email LIKE '%abc1000@example.com';
   ->  Parallel Seq Scan on users ...                            ← 後方一致は text_pattern_ops でも使えない

\timing での所要時間は、前方一致が 0.52 ms、後方一致が 76.9 ms でした。後方一致をどうしても速くしたいときは、reverse(email) に索引を作って「ひっくり返した前方一致」にする方法があり、手元でも reverse(email) LIKE 'moc.elpmaxe@0001cba%' が Bitmap Index Scan になりました。

索引の「プレフィックス」：MySQL の col(20) と複合索引の左端

データベースには、検索語の前方一致とは別に「索引のプレフィックス」という言い方が2つあります。1つは MySQL のプレフィックス索引で、長い文字列（TEXT・BLOB・長い VARCHAR）の先頭 N 文字だけを索引にする仕組みです。TEXT 列はこの長さを付けないと索引を作れません。

mysql> CREATE INDEX users_bio_idx ON users(bio);
ERROR 1170 (42000): BLOB/TEXT column 'bio' used in key specification without a key length

mysql> CREATE INDEX users_bio_idx ON users(bio(20));     -- 先頭20文字だけ
mysql> SHOW INDEX FROM users WHERE Key_name='users_bio_idx'\G
  Column_name: bio
     Sub_part: 20          ← プレフィックス長

もう1つは複合索引の左端プレフィックス（leftmost prefix）です。INDEX(dept, joined) は「dept だけ」「dept と joined」の条件には使えますが、「joined だけ」には使えません。

mysql> EXPLAIN SELECT * FROM users WHERE dept = 7\G
         type: ref
          key: users_dept_joined_idx          ← 左端の列だけなら使える

mysql> EXPLAIN SELECT * FROM users WHERE joined = '2021-03-01'\G
         type: ALL
          key: NULL                           ← 2列目だけでは使えない

LIKE のワイルドカードとエスケープは関連記事「SQL LIKE部分一致とエスケープ｜%・_の扱いをDB別にコピペ解説」、索引が使われない書き方の全体は関連記事「SQLのインデックスが効かない10のパターンと確認方法」で扱っています。

よくあるつまずき（原文つき）と判断表

この節では、プレフィックスまわりで手元に出たエラーや、思った結果にならなかった例と、その直し方が分かります。

どの「プレフィックス」の話か決める判断表

1. 1文字列や名前の話 → 接頭辞（startswith・命名規則・feat:）「〜で始まる」「先頭に付ける」が出てきたらここ
2. 2CSS のプロパティの前に -webkit- → ベンダープレフィックス今は Autoprefixer に任せ、手では書かない
3. 3IP アドレスの後ろに /24 → プレフィックス長先頭何ビットがネットワーク部か。長いほど狭い
4. 4KB・MB・GiB の文字 → 単位の接頭辞k＝1,000、Ki＝1,024。表示ツールで違う
5. 5LIKE や INDEX の話 → 前方一致・プレフィックス索引・左端プレフィックスEXPLAIN で type / Index Cond を見る
6. 6電話番号の先頭の 0・010・00XY → 国内・国際・事業者のプレフィックス相手の番号の前に付けてつなぎ方を示す

よくある質問

Q. プレフィックスとサフィックスの違いは何ですか？ A. 付く位置の違いです。先頭に付くのがプレフィックス（接頭辞）、末尾に付くのがサフィックス（接尾辞）です。Python では startswith / endswith、removeprefix / removesuffix が対になっています。

Q. プレフィックスの読み方と綴りは？ A. 英語は prefix で、カタカナでは「プレフィックス」が一般的です。「プリフィックス」と書かれることもあり、同じものを指します。

Q. -webkit- や -moz- は、もう書かなくてよいのですか？ A. transform・transition・flex など多くは、プレフィックス無しだけで主要ブラウザが対応しています。ただし -webkit-line-clamp・-webkit-text-stroke・::-webkit-scrollbar のように、手元の Chromium 153 でプレフィックス無しが使えなかったものも残っています。手で書かず、Autoprefixer に対象ブラウザを渡して任せるのが確実です。

Q. /24 と 255.255.255.0 は同じ意味ですか？ A. 同じです。/24 は「先頭24ビットがネットワーク部」というプレフィックス長の書き方、255.255.255.0 は同じことを2進数で 1 が24個並ぶマスクとして書いたものです。

Q. プレフィックス長を長くすると何が変わりますか？ A. ネットワークが小さくなり、使えるホスト数が減ります。手元の計算では /24 が254台、/25 が126台、/26 が62台でした。ルーターは重なる経路のうち最も長いプレフィックスを選びます（ロンゲストマッチ）。

Q. KB と KiB はどちらを使えばよいですか？ A. 1,024 刻みで数えているなら KiB・MiB・GiB と書くと誤解がありません。Linux の ls -lh・df -h は 1,024 刻みで K・M・G と表示するので、文書に写すときは単位に注意します。

Q. LIKE '%abc%' を速くする方法はありますか？ A. B-tree 索引では無理です。後方一致だけなら reverse() の索引で前方一致に変えられます。部分一致は PostgreSQL の pg_trgm や、MySQL の全文検索など、別の仕組みを使います。

Q. PostgreSQL で前方一致 LIKE に索引が使われません。 A. データベースのロケールが C（または POSIX）でないと、既定の B-tree 索引は LIKE に使われません。手元の C.UTF-8 でも使われませんでした。CREATE INDEX ... (col text_pattern_ops) で索引を作ると、Index Cond に範囲条件が出て使われます。

Q. コミットメッセージのプレフィックスは必ず付けるものですか？ A. 決まりではなく、チームの約束です。付けると git log --grep での絞り込みや、変更履歴と版番号の自動化ができます。種類の一覧を決めて揃えることが大事です。

Q. 「プレフィックス和（累積和）」のプレフィックスも同じ意味ですか？ A. 同じ「先頭からの部分」という意味です。配列の先頭から i 番目までの和を先に求めておく手法で、区間の合計を引き算1回で出せます。

Q. 電話番号の「0」はなぜ取るのですか？ A. 先頭の「0」は国内通話を示す国内プレフィックスなので、海外から日本にかけるときは国番号 81 の後ろに「0」を取った番号を続けます。

まとめ

• プレフィックスは「先頭に付けて、意味・種類・範囲を示す部分」。末尾に付くサフィックスと対になる。
• 文字列は startswith / removeprefix。lstrip は文字の集まりを削る別物で、image.png が age.png になった。
• CSS の -webkit- は多くが不要になったが、-webkit-line-clamp など無し版が使えないものが Chromium 153 でも残る。手では書かず Autoprefixer に任せる。
• /24 は先頭24ビットがネットワーク部で使えるホストは254台、/25 で126台。経路は長いプレフィックスが勝つ。
• k は 1,000、Ki は 1,024。ls -lh では 1,000,000 バイトが 977K、TB では 10% 違う。
• 前方一致 LIKE 'abc%' は索引が使え（MySQL 0.0007 秒）、後方一致は全行走査（0.228 秒）。PostgreSQL は C ロケール以外で text_pattern_ops が要る。

参考・出典

確認日はいずれも 2026年10月29日です。

• Python 公式ドキュメント「組み込み型 — str.removeprefix / str.startswith」：https://docs.python.org/ja/3/library/stdtypes.html#str.removeprefix
• Python 公式ドキュメント「ipaddress — IPv4/IPv6 操作ライブラリ」：https://docs.python.org/ja/3/library/ipaddress.html
• MDN「ベンダー接頭辞（Vendor Prefix）」：https://developer.mozilla.org/ja/docs/Glossary/Vendor_Prefix
• Autoprefixer（GitHub）：https://github.com/postcss/autoprefixer
• browserslist（GitHub）：https://github.com/browserslist/browserslist
• IETF「RFC 4632 Classless Inter-domain Routing (CIDR)」：https://www.rfc-editor.org/rfc/rfc4632
• NIST「Prefixes for binary multiples」：https://physics.nist.gov/cuu/Units/binary.html
• Apple サポート「How storage capacity is measured on Apple devices」：https://support.apple.com/en-ie/102119
• GNU coreutils「Block size」（-h と --si の違い）：https://www.gnu.org/software/coreutils/manual/html_node/Block-size.html
• PostgreSQL 16「11.10. Operator Classes and Operator Families」（text_pattern_ops）：https://www.postgresql.org/docs/16/indexes-opclass.html
• MySQL 8.0「Column Indexes」（Index Prefixes）：https://dev.mysql.com/doc/refman/8.0/en/column-indexes.html
• MySQL 8.0「Multiple-Column Indexes」（leftmost prefix）：https://dev.mysql.com/doc/refman/8.0/en/multiple-column-indexes.html
• Conventional Commits 1.0.0（日本語）：https://www.conventionalcommits.org/ja/v1.0.0/
• Vite「環境変数とモード」（envPrefix）：https://ja.vite.dev/guide/env-and-mode
• 総務省「電気通信番号指定状況」（固定電話番号の「0」は国内プレフィックス）：https://www.soumu.go.jp/main_sosiki/joho_tsusin/top/tel_number/number_shitei.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。