Ubuntu 24.04のaptミラーを日本国内に変える手順

2026.07.102026.10.28

グレープフルーツ編集部

グレープフルーツ編集部です。

先日、WSL2のUbuntuにPDF処理用のpoppler-utilsを入れようとして、sudo apt updateが思うように進まなくなりました。履歴を見返すと、同じコマンドを5回以上打ち直しています。

5回も打てば、さすがに何かを変えたくなります。

その日のうちに「aptのリポジトリを日本国内のミラーに変える」をやって、poppler-utilsは1分かからず入りました。ただ、やり方を一部間違えていたことに、この記事を書くために設定を見直して気づきました。

先に言うと、変えるファイルは1つ、コマンドは1行です。間違えたのは「securityの行まで書き換えてしまった」ところでした。順番に書きます。
詰まったところなどの記録として書いておきます。

環境はWSL2上のUbuntu 24.04.5 LTS（apt 2.8.3）です。

apt updateを5回打ち直した

最初にやったのは、archive.ubuntu.comをjp.archive.ubuntu.comに置き換えることでした。

「jp.を付けると日本のミラーになる」という話は昔から聞いていて、私もそう思い込んでいました。ところが体感はまったく変わらず……。理由は後で分かります。

このとき、findとsedで/etc/apt/配下のファイルをまとめて置換しました。これが後々の失敗の種です。置換の対象にsecurity.ubuntu.comまで含めてしまい、security用の行もjp.archiveに書き換えていました。当時はまったく気づいていません。

次に、IPAのICSCoEが公開しているミラーに、sedの1行で切り替えました。

poppler-utilsは1分かからず入りました。

jp.を付けても、行き先は本家と同じだった

日本からの接続がjp.archiveでも海外の本家サーバーに向かう様子を示した図

getent hostsで名前を引くと、jp.archive.ubuntu.comとarchive.ubuntu.comは同じアドレス群を返します。

getent hosts jp.archive.ubuntu.com
getent hosts archive.ubuntu.com

私の環境では、どちらの結果にも2620:2d:4000:1::101が含まれていて、アドレスの集合は同じでした（返る順番は引くたびに変わります）。WSL2にはdigが入っていないので、getentで引いています。

行き先は本家と同じでした。

体感が変わらなかったのは当然ですよね。jp.を付けた作業は、ファイルの文字列を変えただけで、通信の相手は何も変わっていなかったことになります。

Ubuntuの仕組みでは、国ごとに「カントリーミラー」が1つ割り当てられていて、jp.archive.ubuntu.comはそのための名前です。Ubuntuのプロジェクト文書には、国内に第三者のミラーが無い国では、カントリーミラーが本家のアーカイブそのものを指す、と書かれています。

Canonicalがいつ、なぜjp.を本家に向けたのか、公式の告知は見つけられませんでした。根拠は、手元で引いた名前解決の結果です。

jp.を付けても、今は日本のサーバーには行きません。

24.04のsources.listにはコメントしか無い

Ubuntu 24.04ではsources.listが空で、ubuntu.sourcesにTypes・URIs・Suites・Componentsを書く形式に変わったことを示す図

当時/etc/apt/sources.listを開いたら、4行のコメントしかありませんでした。

Ubuntu 24.04から、Ubuntu本体のリポジトリ設定は/etc/apt/sources.list.d/ubuntu.sourcesに移っています。24.04のリリースノートに「deb822 sources management」として書かれていて、DEB822と呼ばれる、キーと値を1行ずつ並べる形式です。

まず今の中身を見てください。

cat /etc/apt/sources.list.d/ubuntu.sources

Types:から始まるブロックが2つ出てくるかと思います。上が通常の更新用で、URIsはhttp://archive.ubuntu.com/ubuntu/。下がnoble-security用で、URIsはhttp://security.ubuntu.com/ubuntu/です。

下のブロックの手前にはコメントがあって、原文は「Mirror your choices (except for URIs and Suites) in the security section below」。URIsとSuites以外の選択は下にも反映せよ、という意味で、URIsはsecurityブロックへ写さない設計になっています。「変えるな」と直接書いてあるわけではありませんが、securityのURIsを別扱いにする意図は読み取れます。

当時の私はここを読み飛ばしていました……。

22.04以前は従来どおり/etc/apt/sources.listに1行形式で並んでいます。手順は分けて書きます。

国内ミラーに変える手順

切り替え先はICSCoEにしました。

IPA（情報処理推進機構）の産業サイバーセキュリティセンターとサイバー技術研究室が公開しているミラーで、Launchpadのミラーページでは帯域100Gbps、HTTPSとrsyncに対応、登録は2022年3月です。

ただし運営元のトップページには「学術的・試験的な実証実験として提供」「保守作業等のため予告なく停止することがあります」とあります。保証付きのサービスではなく、善意で公開されているものだと私は受け取っています。

国内ミラーは今のところLaunchpadの日本セクションに14本（ports専用や同じ運営元の重複登録を含みます）あって、理研、つくばWIDE、JAIST、山形大なども載っています。速さは後で比べます。

変更前に確認すること

catで今のubuntu.sourcesを見て、securityブロックのURIsがsecurity.ubuntu.comか
.bakがすでにあるなら、その中身も先に見る（sed -i.bakを再実行すると、置換が0件でも.bakは上書きされる）
getent hosts archive.ubuntu.comが即返るか

24.04の場合

sudo sed -i.bak -r 's@http://(jp\.)?archive\.ubuntu\.com/ubuntu/?@https://ftp.udx.icscoe.jp/Linux/ubuntu/@g' /etc/apt/sources.list.d/ubuntu.sources

-i.bakで置換前のファイルがubuntu.sources.bakとして残ります。

amd64の標準構成が前提で、ubuntu-portsの行が同じファイルにあると/Linux/ubuntu/-ports/に壊れます。portsを使う環境では対象を絞ってください。

(jp\.)?が付いているので、すでにjp.archiveにしてある環境でも通ります。security側のURIsはsecurity.ubuntu.comなので一致せず、無傷のままです。

逆に言うと、security側をすでにarchiveやjp.archiveに変えてある環境では、一緒に置換されます。私の失敗はこれでした。

実は、最初に試したのは(jp\.)?が無い版の正規表現でした。私のファイルはすでにjp.archiveになっていたので、何も置換されず空振り。(jp\.)?付きで通りました。

22.04以前の場合

sudo sed -i.bak -E '/-security/! s@http://(jp\.)?archive\.ubuntu\.com/ubuntu/?@https://ftp.udx.icscoe.jp/Linux/ubuntu/@g' /etc/apt/sources.list

-securityを含む行は除外して置換します。

sources.listはsecurityの行も同じファイルに並ぶので、除外の指定が要ります。-securityを含む行は丸ごと飛ばす雑な条件なので、行末コメントやコメントアウト済みの# deb行がある場合は、実行後に目で確認してください。こちらは手元に22.04が無く、サンプルファイルで動作を確認した範囲です。

反映と確認

sudo apt update

出力のHit:やGet:の行に並ぶURLが、意図したミラーになっていれば成功です。sudoなしで行き先だけ確かめるなら、こちらが楽でした。

apt-get update --print-uris | grep InRelease

変更後に確認すること

noble-securityの行だけsecurity.ubuntu.comのまま
それ以外の行がftp.udx.icscoe.jpになっている
末尾にW:やE:が出ていない

触るのはubuntu.sourcesの1ファイルだけにしてください。sources.list.dには、Ubuntu Pro用のubuntu-esm-*.sourcesや、Tailscaleなど外部リポジトリの.listが同居していることがあります。前者はProクライアントが管理するファイルで、手で書き換えても書き戻されます。

私はPro契約が無いので手元にはありませんが、sedの対象をファイル1本に絞っていれば、どちらにしても物理的に触れないかと思います。

securityの行は触らない

通常のリポジトリ行だけを書き換え、securityの行は鍵をかけて触らないことを示す図

この記事を書くためにubuntu.sourcesを開いたら、securityブロックのURIsもICSCoEになっていました。

原因は最初のfind+sedです。先にsecurity.ubuntu.comをjp.archiveに変えてしまっていたので、その後のICSCoEへの置換にも一致して、ICSCoEまで一緒に進んでしまった。半年近く、そのまま使っていたことになります。

なぜ触ってはいけないのか。UbuntuのSecurity TeamのFAQには、securityポケットは常に有効にしてsecurity.ubuntu.comを使うこと、他のポケットはarchive.ubuntu.comでもミラーでもよい、と書かれています。理由はミラーの同期に遅れがあるから。

さらにプロジェクト文書には、security.ubuntu.comはarchive.ubuntu.comと同じサーバーを指していて、別名にしているのは「ユーザーやスクリプトが誤ってミラーに変えてしまうのを防ぐため」だとあります。

まさに私がやったことです。

誤解しやすいところを1つ。ミラーにもsecurityポケット自体は同期されています。ICSCoEのnoble-securityのInReleaseを本家と見比べたら、日付は同じでした。「ミラーにはsecurityが無い」のではなく、「遅れる可能性があるから本家直を推奨」という話です。

もう1つ、ミラーに変えても署名の検証は効きます。aptはReleaseファイルの署名をSigned-Byに書かれたキーリングで確認し、そこからPackages、個々のdebへとチェックサムで辿ります（apt-secure(8)）。信頼している鍵の署名と合わない改ざんは、ここで検出されます。

ただし万能ではなく、鍵そのものが漏れた場合や、過去の正規ファイルをそのまま出し続けられる場合までは守れません。

HTTPSは何を落としているかを経路上で見られにくくする層で、署名検証の代わりではありません。ICSCoEはHTTPSに対応しているので、使って損は無いかと思います。

私の戻し方は、エディタでsecurityブロックのURIs:をhttp://security.ubuntu.com/ubuntu/に書き直して、sudo apt update。これで--print-urisの出力も、noble-securityだけ本家に戻りました。

securityブロックのURIsは、本家のままにする。

amd64の標準構成での話です。portsや社内ミラーで運用している環境は、また別の設計になります。

どのミラーが速いのか

同じファイルを各ミラーから3回ずつ落としテストしました。

対象はdists/noble/Contents-amd64.gz、51,301,092バイトのファイルです。WSL2から、5分ほどの間にcurlで取って速度を記録しました。

ミラー	速度（MB/s、3回）	所要時間
archive.ubuntu.com（本家）	12.9 / 7.9 / 9.6	4.0〜6.5秒
jp.archive.ubuntu.com	10.8 / 10.6 / 7.4	4.7〜6.9秒
ICSCoE（ftp.udx.icscoe.jp）	20.3 / 22.6 / 25.8	2.0〜2.5秒
理研（ftp.riken.jp）	20.1 / 35.2 / 22.3	1.5〜2.6秒
つくばWIDE（ftp.tsukuba.wide.ad.jp）	19.1 / 20.0 / 17.4	2.6〜2.9秒
JAIST（ftp.jaist.ac.jp）	1.5 / 2.4 / 2.9	17〜35秒
山形大（ftp.yz.yamagata-u.ac.jp、Launchpad登録名はlinux.yz.yamagata-u.ac.jp）	6.0 / 9.2（2回のみ）	5.6〜8.6秒

本家とjp.は、やはりほぼ同じ速度です。ICSCoE、理研、つくばWIDEは2倍前後で、この3つは同じ水準でした。JAISTはこの日は遅く、山形大は中間。

もう1つ、dists/noble/Release1本の応答時間も見ました。本家とjp.が1.6秒台、国内ミラー（ICSCoE、理研、つくば、JAIST）は0.18〜0.27秒。apt updateは小さなファイルを何度も取りに行くので、体感に効くのはこちらかもしれません。

ただし、1日・1回線の計測です。

「国内最速」みたいな話ではなく、この日このくらいの差があった、という記録として見てください。JAISTが遅かったのもこの日の話で、翌週は逆かもしれません。本家への接続はIPv6でつながっていました。

うまくいかないときに見るところ

getent hosts archive.ubuntu.comが即返らない環境は、ミラー以前の問題です。

最初に疑うのは名前解決です。WSL2のDNSまわりはMicrosoftの文書にも設定項目がありますが、aptとの関係を明文化したものは見つけていません。断定はしません。

でも、私なら先にここを見ます。

「Hash Sum mismatch」が出るときは、ミラーの同期途中に当たった可能性があります。時間を置いて再実行し、続くならsudo apt cleanに加えて、updateが使う索引/var/lib/apt/lists/も消してからもう一度（apt cleanが消すのはダウンロード済みのdebだけで、索引は残ります）。

それでも続くなら別のミラーへ。

「Release file for … is not valid yet」は、端末の時計がずれているときのメッセージです。WSL2は休止からの復帰で時計がずれやすい、という報告が多く、ミラーとは関係ないところで止まります……。

戻したいときは.bakを使えます。ただし、戻す前に中身を見てください。

cat /etc/apt/sources.list.d/ubuntu.sources.bak
sudo cp /etc/apt/sources.list.d/ubuntu.sources.bak /etc/apt/sources.list.d/ubuntu.sources && sudo apt update

私の.bakは最初の置換直前の状態なので、中身はjp.archiveとsecurity誤置換済みの組み合わせでした。「.bakを戻せば元通り」が成り立たない例です。どこが元かは、自分の置換の履歴でしか分かりません。

戻してから思ったこと

securityの行を本家に戻しても、通常の更新はICSCoEから来るので、速さの面で失うものは少ないと思っています。

mirror://で複数ミラーを自動で振り分ける方式は、固定で足りているので試していません。

Ubuntu公式のミラーリストhttp://mirrors.ubuntu.com/JP.txtを見ると、15行のうちarm64などports向けのミラーが3本混ざっていて、aptは優先度を書かなければランダムな順で試します。自分で優先順位を書く人向けかな、と個人的には見ています。

nalaやGUIの「ソフトウェアとアップデート」も使っていません。コマンド1行で済んだからです。

半年近くずれたまま使っていて、実害があったかは分かりません。今日見た限りでは、ICSCoEのsecurityは本家と同じ日付・同じ中身でした。ただ、過去半年ずっとそうだったかは確かめようがありません。それでも「公式が分けている理由」を知ってから見ると、自分の設定がずいぶん雑に見えました。

設定は1ファイル、1行で終わります。終わったら--print-urisで、noble-securityの行だけ本家に残っているかを見てください。私はそれを半年やらなかったので。

apt updateの際の参考になると幸いです！！

参考・出典

ナレッジ開発・技術

Written by