13 人が閲覧(直近 30 日) データ分析・BI

r5rとは?R5で移動時間と到達圏を求める使い方【2.4.0・日本のGTFS対応】

r5rとは?R5で移動時間と到達圏を求める使い方【2.4.0・日本のGTFS対応】

r5rは、OpenStreetMapの道路データとGTFSの時刻表から交通ネットワークを組み立て、徒歩・自転車・自動車・公共交通の移動時間や到達圏をRで計算するパッケージです。計算の本体はConveyalのJava製経路探索エンジンR5で、r5rはそこへRのインターフェースを与えます。現行のCRAN版は2026年5月20日公開の2.4.0で、動作要件はJava JDK 21以上です。この記事は2.4.0を前提に、導入、日本のOSMとGTFSの入手、4つの分析関数の使い分け、旧コードの移行、公式が回答しているエラーの原因までを扱います。さらに、公式変更履歴で報告されている2.2.0〜2.4.0のJavaメモリ指定の不具合と、日本の地方別データが範囲の上限に当たるかの実測も載せています。

まとめ:r5r 2.4.0を使うときの要点

  • CRAN版は2.4.0(2026年5月20日公開)。動作要件はSystemRequirements: Java JDK (>= 21.0)、RはR 3.6以上、ライセンスはMIT。公式リポジトリはipea/r5rへ移転しています。
  • ネットワーク構築はbuild_network()。setup_r5()と引数r5r_coreはv2.3.0以降の非推奨です(まだ動きます)。
  • 2.2.0〜2.4.0ではoptions(java.parameters = "-Xmx…")が無視され、JVMは既定の最大ヒープ(物理メモリの4分の1、上限は約30GB)で動きます。修正は開発版に入っています。実際のヒープはmaxMemory()で確かめます。
  • 入力は.pbf(必須)、GTFS.zip(任意)、標高の.tif(任意)を同じフォルダへ置く形式です。
  • 日本の道路データはGeofabrikの地方別抽出が手軽ですが、九州(沖縄県を含む)は外接矩形が約111万平方キロメートルで、R5の上限975,000平方キロメートルを超えます。分析範囲で切り出してから使います。
  • 日本のGTFSはGTFSデータリポジトリから取れます。フィードごとの有効期間の内側にdeparture_datetimeを置かないと、公共交通が使われません。
  • 分析の入口は4つ。移動時間ならtravel_time_matrix()、経路の内訳ならdetailed_itineraries()、到達圏ならisochrone()、到達可能な機会の量ならaccessibility()です。

r5rとR5エンジンの関係

R5の正式名称と開発元

R5はConveyalの経路探索エンジンで、正式名称は「Rapid Realistic Routing on Real-world and Reimagined networks」です。公式READMEは冒頭で「R5 is the routing engine for Conveyal」と位置づけており、r5rのvignetteもR5を「a really fast and open source Java-based routing engine developed separately by Conveyal」と紹介しています。r5rとR5は別のチームの成果物で、r5rはブラジルのIpea(応用経済研究所)が中心に開発しています。

R5とOpenTripPlanner(OTP)の関係は、OTP1とOTP2を分けると正確に書けます。OTPの公式ドキュメントは、OTP1の分析機能を「an unmaintained and unsupported early prototype for later projects, specifically Conveyal's R5」と説明し、OTP2の公共交通ルーティングについては「Conveyal's R5 project, which informed and inspired the OTP2 transit routing system.」と述べています。OTP1の分析機能がR5の原型になり、そのR5の手法が今度はOTP2に取り込まれた、という順番です。現在は別々に開発されているプロジェクトで、R5をOTPの一部として扱う理由はありません。R5の設計目的は1対多・多対多の移動時間計算で、READMEは出発時刻を1点に固定せず時間帯の中で何度も探索する方式を「realistic」と呼ぶ理由に挙げています。これが後述するtime_window引数の存在理由です。

r5r 2.4.0が取得するR5のバージョン

r5rはインストール時にR5のJARを同梱せず、初回実行時にダウンロードしてキャッシュします。そのバージョンはパッケージ側にハードコードされていて、CRANの2.4.0のソースではR/onLoad.Rにr5r_env$r5_jar_version <- "7.5.1"と書かれています。CRANのr5rパッケージ情報に出るDESCRIPTIONの説明文には「This version of r5r depends on R5 v7.1.」という古い記述が残っているため、説明文と実際に落ちてくるJARが食い違います(2.4.0での更新はr5rの変更履歴(CRAN)に「Using new version of R5 v7.5.1.」と記載されています)。使っているR5の版を確かめるなら、説明文ではなく使用している版のソース配布物に含まれるR/onLoad.R、あるいはr5r_sitrep()の出力を見てください。

R5本体は2026年8月1日にv7.6が出ていますが、CRANの2.4.0が使うのは7.5.1のままです。開発版のonLoad.Rはすでに"7.6.0"へ上がっており、R5の更新はr5rの次のリリースを通じて届きます。版を記録に残すのは、記載差が誤記にとどまらないからです。Conveyal側のREADMEは「R5 does not currently expose a stable programming interface」と述べ、「third-party wrappers or language bindings (e.g., for R or Python) may need to continue using an older release of R5」と明記しています。「the Conveyal team does not provide technical support for third-party deployments」ともあるため、r5r経由の不具合をConveyalへ問い合わせる先もありません。再現性が要る分析では、r5rの版とR5のJARの版を両方記録に残してください。

動作要件とインストール

r5r本体はCRANから1行で入ります。先に片付けるのはJDK 21の用意と、JVMへ渡すメモリの指定です。

Java JDK 21の用意

2.4.0のDESCRIPTIONはSystemRequirements: Java JDK (>= 21.0)です。ランタイム(JRE)ではなくJDKが必要で、公式READMEはAdoptium(Eclipse Temurin)を推奨の選択肢、Amazon CorrettoとOracle OpenJDKを代替として挙げています。実装ごとに配布条件やサポート期間が違うので、社内標準を決めるときはJava仮想マシン(JVM)とは?仕組み・メモリ・JITとインストール手順を実機で解説で仕組みを押さえたうえでライセンスを確認してください。

OSへJDKを入れずにRの中だけで完結させたい場合は、r5rがSuggestsに挙げているrJavaEnvが使えます。READMEが示す手順は次のとおりです。

install.packages("rJavaEnv")

# 現在Rが見ているJavaの版を確認する
rJavaEnv::java_check_version_rjava()

# Java 21を導入し、もう一度確認する
rJavaEnv::java_quick_install(version = 21)
rJavaEnv::java_check_version_rjava()

CRAN版と開発版の選び方

安定版はCRANから、開発版はGitHubのサブディレクトリを指定して入れます。リポジトリはipeaGIT/r5rからipea/r5rへ移転しており、公式サイトもipea.github.io/r5rに移りました(旧ipeagit.github.ioのページは404です)。開発版はリポジトリ直下ではなくr-package配下にあるため、subdirの指定を落とすと失敗します。

# 以下の安定版と開発版は、どちらか一方だけを実行する
# 安定版(この記事の確認時点では2.4.0)
install.packages("r5r")

# 開発版(devtools が無い環境では先に入れる)
if (!requireNamespace("devtools", quietly = TRUE)) install.packages("devtools")
devtools::install_github("ipea/r5r", subdir = "r-package")

開発版を選ぶ理由は、公式変更履歴のBug fixesに挙がっている修正を先に取り込みたい場合です。次の節のメモリ指定の不具合がその代表です。ただし開発版の変更履歴は次版を2.5.0として準備中で、公共交通の計算ではdeparture_datetimeの明示が必須になる(2026年11月4日時点のmasterで、既定値に頼ると警告ではなくエラーで止まる実装に変わりました)、RはR 4.1以上になる、R5がv7.6に上がり結果がわずかに変わる、といった変更も同時に入ります。CRAN版で書いたコードがそのまま同じ数値を返すとは限らないので、開発版へ移るときは版を記録して比較してください。どちらにも当てはまらなければCRAN版で十分です。

JVMのメモリとCPUコア数の指定

公式READMEとvignetteは、library(r5r)より前にoptions(java.parameters = "-Xmx2G")でメモリを渡す手順を示しています。必要量は道路網の広さ、GTFSの本数、ODの組み合わせ数で変わります。rJavaはRのセッションごとにJVMを一度だけ起動するので、JVMが起動したあとにoptions()を書き換えても反映されません。

# 公式の手順。library(r5r) より前に置く
options(java.parameters = "-Xmx2G")

# 修正済み開発版でJVMの認識CPU数を4に制限する例
# 2.2.0〜2.4.0では、このjava.parameters指定も無視される
options(java.parameters = c("-Xmx2G", "-XX:ActiveProcessorCount=4"))

library(r5r)
library(sf)
library(data.table)

2.4.0で計算の並列数を抑えたい場合は、JVMのオプションではなく各分析関数のn_threads引数(既定はInfで、使えるスレッドをすべて使う)で指定します。分析が終わってメモリを解放したいときは、ネットワークを構築したあとの話になりますがstop_r5()とガベージコレクタを呼びます。

# 分析が終わったあと(r5r_network を構築済みの状態)で実行する
stop_r5(r5r_network)
rJava::.jgc(R.gc = TRUE)

2.2.0〜2.4.0でメモリ指定が無視される不具合

上の手順は、CRANの2.4.0ではJVMに届いていません。2.4.0のソースでJVMを起動しているstart_r5r_java()(R/utils.R)は、rJava::.jinit(parameters = c(log_path, r5_version, r5r_version))とログの出力先と版番号だけを渡しています。.jinit()のparametersは既定でgetOption("java.parameters")を読む引数なので、明示的に渡した時点でユーザーの-Xmxが置き換えられて消えます。開発版の変更履歴はこの不具合を「was ignored since r5r v2.2.0, so Java always ran with its default maximum heap (a quarter of the machine's RAM, capped at about 30 GB)」と記載しており、2026年10月9日のコミットでユーザーの指定を先頭に足す修正が入りました。

影響は2方向に出ます。16GBのPCでは、-Xmx16Gを指定しても最大ヒープは物理メモリの4分の1の約4GBにとどまり、広い範囲のネットワークでOutOfMemoryErrorになりえます。大きなサーバーでは逆に、-Xmx2Gで抑えたつもりが約30GBまで使われます。起動時のメッセージはgetOption("java.parameters")の値をそのまま表示するため、設定が効いているように見える点にも注意が要ります。実際のヒープは、ネットワークを構築したあとでJVM自身に尋ねて確かめます。

r5r_network <- build_network(data_path)

# JVM が実際に使える最大ヒープ(GB)
rJava::J("java.lang.Runtime")$getRuntime()$maxMemory() / 1024^3

# JVM に渡った起動オプション(-Xmx が含まれているか)
rJava::J("java.lang.management.ManagementFactory")$getRuntimeMXBean()$getInputArguments()$toString()

指定したヒープが出ていなければ、選択肢は2つです。物理メモリの4分の1で足りる規模ならCRAN版のまま進め、足りなければ修正済みの開発版を入れます。開発版には前の節で挙げた次版の変更も入るので、記録には版とコミットを残してください。

入力データの要件と置き方

r5rは個別のファイルパスを受け取らず、データを置いたフォルダのパスを受け取ります。build_network()のドキュメントは、そのフォルダに道路網ファイル(.osm.pbf)を1つだけ置くこと、GTFSが複数あれば自動で統合されること、標高のラスタはWGS 84(EPSG:4326)であることを要件として挙げています。

データ 形式 必須 日本での入手先の例
道路ネットワーク .pbf 必須 Geofabrik(地方別)
公共交通の時刻表 GTFS.zip 任意 GTFSデータリポジトリ
標高 .tif 任意 elevatr・SRTMGL1

道路データはOpenStreetMap(OSM)とは?使い方・商用利用の条件・APIを公式ポリシーで解説で扱っているOSMの抽出データを使います。GTFSを置かなければ徒歩・自転車・自動車だけの分析になり、置けば公共交通のダイヤに沿った経路が計算できます。標高の.tifを入れると坂道を考慮した所要時間になりますが、2.4.0のリリースノートはLTS(自転車の走行快適性レベル)のシナリオでは標高が無視される既知の不具合が残ると記載しています。座標系や形式の基礎はGISデータとは?形式・座標系・取り込み設計を実装目線で解説【2026年8月時点】で確認できます。

初回のbuild_network()実行時に、このフォルダへnetwork.datが書き出されます。2回目以降は既存のnetwork.datを読み込むため、入力データを差し替えたときはoverwrite = TRUEで作り直してください。

日本のOSM・GTFSの入手とネットワーク構築

公式のサンプルはブラジルのPorto Alegreなので、日本で使うときはデータの入手から自分で組みます。つまずくのは道路データの範囲と、GTFSの有効期間の2点です。

道路データ:Geofabrikの地方別抽出と範囲の上限

Geofabrikの日本のページは、北海道・東北・関東・中部・関西・中国・四国・九州の8地方に分けた.osm.pbfを配布しています。ただし地方単位のファイルをそのまま入れると、R5の範囲チェックに当たることがあります。R5はネットワークに取り込んだ道路の頂点から外接矩形を作り、その面積が975,000平方キロメートルを超えると構築を止めます(仕組みは後述のエラーの節)。

2026年11月5日に取得したkyushu-latest.osm.pbf(317MB)について、R5の道路取り込み条件を近似して抽出したhighway付きのwayの外接矩形を、R5と同じ式(GeometryUtils.roughWgsEnvelopeArea)で計算すると1,114,678平方キロメートルでした。九州のファイルには沖縄県が含まれ、西端が与那国島(東経122.93度)、南端が波照間島(北緯24.05度)、北端が対馬(北緯34.71度)まで広がるためです。同じ計算で関東のkanto-latest.osm.pbf(524MB)は513,894平方キロメートルでした。小笠原諸島の道路(南端は硫黄島の北緯24.75度)まで含むものの、上限の範囲内に収まります。上限に収まるかどうかは地方名ではなく、そのファイルに含まれる離島の位置で決まります。

切り出しには、Conveyalのドキュメントが例示しているOsmium Toolが使えます。範囲は最小経度,最小緯度,最大経度,最大緯度の順で指定します。次は福岡市周辺を切り出し、さらに経路探索に要るwayだけを残してファイルを小さくする例です。

# 福岡市周辺を切り出す(範囲は分析対象に合わせて変える)
osmium extract --strategy complete_ways --bbox 130.2,33.45,130.55,33.75 \
  kyushu-latest.osm.pbf -o fukuoka.osm.pbf

# 道路・ホーム・パークアンドライド・右左折制限だけを残す
osmium tags-filter fukuoka.osm.pbf \
  w/highway w/public_transport=platform w/railway=platform w/park_ride r/type=restriction \
  -o fukuoka-filtered.osm.pbf

切り出した.osm.pbfは、GTFSと同じフォルダに1つだけ置きます。元の地方ファイルを同じフォルダに残すと「1つだけ」の要件に反するので、別の場所へ移してください。

時刻表データ:GTFSデータリポジトリと有効期間

日本のバス・鉄道のGTFSはGTFSデータリポジトリにまとまっています。検索画面のほか、https://api.gtfs-data.jp/v2/files?pref=36のように都道府県コードを付けたAPIで、フィードごとのダウンロードURL(file_url)、有効期間の開始日と終了日(file_from_date・file_to_date)、ライセンス(feed_license_id)が一覧で取れます。2026年11月5日に徳島県(36)を引くと15フィードが返り、すべてCC BY 4.0でした。分析結果を公開するならクレジット表記が要ります。

# 徳島県のフィード一覧から、名前・有効期間・ダウンロードURLを確かめる
curl -s --compressed "https://api.gtfs-data.jp/v2/files?pref=36" \
  | jq -r '.body[] | [.feed_name, .file_from_date, .file_to_date, .file_url] | @tsv'

ここで見るべきは有効期間です。departure_datetimeがフィードのfile_from_dateからfile_to_dateの外にあると、そのフィードの路線は計算に使われません。2.4.0のtravel_time_matrix()・detailed_itineraries()・accessibility()などは計算前に指定日の運行状況を確かめ、GTFS全体で動いているサービスがゼロならエラーで止まり、2割未満なら警告を出します(ポリゴン出力のisochrone()はこの確認を通りません)。一部のフィードだけが期間外の場合は止まらないので、気づかないまま特定の事業者が抜けた結果になります。徳島県の15フィードでも期間は事業者ごとにばらばらで、2025年10月1日から2026年12月31日のものもあれば、2026年10月14日から始まるものもありました。複数のフィードを同じフォルダに置くとr5rは自動で統合しますが、各フィードの期間が重なる日でも、曜日設定や運休・臨時運行によって利用できるサービスは異なります。分析対象の曜日と運行条件に合う日を選んでください。日付を決めたら、check_transit_availability()でその日に動いているサービスの割合を確かめてから本番の計算に進みます。

起点と終点はid・lat・lonの列を持つCSVで用意すれば、fread()で読んでそのまま渡せます。idは日本語の施設名でもかまいません。

ネットワーク構築と移動時間マトリクス

r5rにはPorto Alegre(ブラジル)のサンプルデータが同梱されており、system.file()でパスを取れます。以下は公式vignetteの手順に沿った最小の流れです。日本のデータで動かすときはdata_pathを前の節で用意したフォルダに、departure_datetimeをGTFSの有効期間内の日時に置き換えます。

options(java.parameters = "-Xmx2G")
library(r5r)
library(data.table)

# 同梱サンプルデータのパス
data_path <- system.file("extdata/poa", package = "r5r")

# 交通ネットワークを構築する(network.dat が作られる)
r5r_network <- build_network(data_path)

# 起点・終点(id, lon, lat の列を持つ data.frame)
points <- fread(file.path(data_path, "poa_points_of_interest.csv"))

departure_datetime <- as.POSIXct("13-05-2019 14:00:00",
                                 format = "%d-%m-%Y %H:%M:%S")

ttm <- travel_time_matrix(
  r5r_network,
  origins = points,
  destinations = points,
  mode = c("WALK", "TRANSIT"),
  departure_datetime = departure_datetime,
  max_walk_time = 30,
  max_trip_duration = 60,
  time_window = 60,
  percentiles = c(25, 50, 75)
)

# CSV に保存する(Excel で開くなら bom = TRUE で文字化けを防ぐ)
fwrite(ttm, "ttm.csv", bom = TRUE)

起点・終点はid・lon・latの3列を持つデータフレームか、WGS 84のPOINT sfオブジェクトで渡します(投影座標系のsfは事前にsf::st_transform(4326)で変換します)。押さえる引数は3つです。time_windowは出発時刻を何分間の幅で探索するかの指定(既定10分)で、R5はその時間帯を毎分探索するため結果は単一値ではなく分布になります。そこから何パーセンタイルを取るかがpercentiles(既定50)で、中央値と75パーセンタイルの差は総移動時間のばらつきを表し、待ち時間だけでなく選択される経路や乗り換えの違いも含みます。max_trip_durationは既定120分で、これを超えるペアは結果から落ちます。速度の既定値は徒歩walk_speedが時速3.6キロ、自転車bike_speedが時速12キロ、公共交通の乗車回数上限max_ridesが3です(乗り換え回数ではなく乗車回数の上限で、3なら最大2回の乗り換えを含みます)。

処理速度の目安として、r5rの論文(2021年)はサンプル地域で1,227×1,227の所要時間行列を120分のtime_windowで計算した例を挙げ、1.9GHzのIntel i7・16GBのWindows機で「takes less than a minute」と報告しています(当時のr5r v0.3-2とR5 v6.0.1での測定です)。所要時間の内訳が必要ならexpanded_travel_time_matrix()をbreakdown = TRUEで呼びます。既定のFALSEでは時間帯の各分についての合計時間と利用路線だけが返り、アクセス・待ち・乗車・乗り換えの内訳は出ません。到着時刻から逆算する場合はv2.3.0で追加されたarrival_travel_time_matrix()を使います。

詳細経路・到達圏・アクセシビリティの使い分け

移動時間マトリクス以外の3関数は返ってくるものが違います。目的から選びます。引数の一覧はr5rのリファレンスマニュアル(CRAN)にあります。

detailed_itineraries():経路の内訳と線形の取得

1組または複数組のODについて、実際にたどる経路の区間、利用路線、区間ごとの所要時間、そして経路の線形(sfのLINESTRING)を返します。shortest_path = FALSEとsuboptimal_minutesを組み合わせると、最短経路より少し遅い代替経路も列挙できます。

det <- detailed_itineraries(
  r5r_network,
  origins = points[10, ],
  destinations = points[12, ],
  mode = c("WALK", "TRANSIT"),
  departure_datetime = departure_datetime,
  max_walk_time = 60,
  suboptimal_minutes = 8,
  shortest_path = FALSE
)

公式が避けるよう助言している使い方があります。travel_time_matrix()とdetailed_itineraries()は内部で別のルーティングアルゴリズムを使うため、FAQは「we advise not to use or combine the output of these functions」と述べています。実行は止められませんが、マトリクスで所要時間を出して代表例だけ詳細経路で可視化するという資料の作り方をするなら、両者の数値が一致しない前提で扱う必要があります。

isochrone():到達圏ポリゴンの生成

cutoffsで指定した分数ごとに、その時間内に到達できる範囲のポリゴンを返します。2.4.0でこの関数は内部実装が入れ替わり、ネットワーク全体に敷いたWeb Mercatorピクセルの規則格子から移動時間サーフェスを作り、marching squaresアルゴリズムでポリゴンを描く方式になりました。以前の版で到達圏の形が粗いと感じていた場合は、2.4.0以上に上げるだけで結果が変わります。

iso <- isochrone(
  r5r_network,
  origins = points[1, ],
  mode = c("WALK", "TRANSIT"),
  cutoffs = seq(0, 60, 10),
  departure_datetime = departure_datetime,
  max_walk_time = 30,
  # 探索時間の上限は max(cutoffs) の60分になる
  time_window = 60,
  zoom = 10,
  polygon_output = TRUE
)

# GeoJSON に保存する(QGIS や Web 地図でそのまま読める)
sf::st_write(iso, "isochrone.geojson")

zoomはピクセル格子の細かさで、polygon_output = FALSEにすると、到達可能な道路区間を移動時間帯別のLINESTRINGとして受け取れます。到達圏ポリゴンの境界線を返す指定ではありません。

accessibility():到達可能な機会数の計算

到達圏が「どこまで行けるか」を示すのに対し、accessibility()は「その範囲に何があるか」を数えます。施設数などの列はdestinationsに渡すデータへ持たせ、その列名をopportunities_colnamesで指定します。decay_functionは既定がstep(指定分数以内を等重みで合算する累積機会指標)で、距離減衰を効かせたい場合に他の関数形を選べます。

# 機会数(schools・healthcare)の列を持つ同梱データを読み込む
hexgrid <- fread(file.path(data_path, "poa_hexgrid.csv"))

access <- accessibility(
  r5r_network,
  origins = hexgrid,
  destinations = hexgrid,
  opportunities_colnames = c("schools", "healthcare"),
  mode = c("WALK", "TRANSIT"),
  decay_function = "step",
  cutoffs = 20,
  departure_datetime = departure_datetime,
  max_walk_time = 30,
  time_window = 60
)

運賃を条件に入れたい場合は、setup_fare_structure()で運賃体系を組み立ててfare_structureとmax_fareへ渡します。所要時間と運賃のトレードオフを列挙するならpareto_frontier()が専用の関数です。

2.x での破壊的変更と旧コードの移行

v2.2.0以前を前提に書かれたコードは、2.4.0では非推奨の警告つきで動くか、Javaの版で止まります。確認するのは関数名・引数名・Javaの版・自作コードの型判定の4点です。

項目 旧 新 変更が入った版
ネットワーク構築 setup_r5() build_network() v2.3.0(旧関数は非推奨・将来削除)
第1引数 r5r_core r5r_network v2.3.0(旧引数は非推奨)
Javaの要件 JDK 11以上 JDK 21以上 v2.0(破壊的変更)
# 旧コード
r5r_core <- setup_r5(data_path = "my_data")
ttm <- travel_time_matrix(r5r_core = r5r_core, origins = o, destinations = d)

# 2.4.0での書き方
r5r_network <- build_network(data_path = "my_data")
ttm <- travel_time_matrix(r5r_network, origins = o, destinations = d)

旧名も当面は動きますが、setup_r5()のドキュメントには「setup_r5() is being deprecated after r5r v2.3.0 and will be removed in a future release」とあり、実行すると非推奨の警告が出ます。r5r_core引数も「The r5r_core argument is deprecated as of r5r v2.3.0」の警告つきで受け付けられるだけです。v2.3.0からネットワークオブジェクトはr5r_networkクラスを持つので、自作関数で型を見ている箇所も直してください。

見落としがちなのがJavaです。1.1.0のDESCRIPTIONはJava JDK (>= 11.0)でしたが、2.0の変更履歴に「r5r uses now JDK 21 or higher (Breaking changes).」とあり、以降はJDK 21以上が必要です(同じ変更でApple Silicon機との非互換も解消されています)。Rのパッケージだけ更新してJavaを据え置くと、ネットワーク構築の時点で版チェックに止められます。R言語とは?統計解析特化の言語仕様・環境構築から採用判断まで実装視点で解説のとおりRのパッケージ更新自体は軽い作業ですが、r5rはJVM側の要件が同時に動く前提で計画してください。2.1.0以前から上げる場合は、前述のメモリ指定の不具合(2.2.0以降)も同時に入る点を見込んでおきます。

つまずきやすいエラーと公式の回答

次の3つは公式FAQに回答が載っています。入力データを直すもの、日付の指定を直すもの、座標を見直すものが混ざっているので、原因の切り分けから入ります。

Geographic extent of street layer exceeds limit:原因は入力範囲の広さ

「Geographic extent of street layer (5315196 km2) exceeds limit of 975000 km2」というエラーは、投入した.pbfの範囲が広すぎることを示します。この975,000平方キロメートルという上限はR5側にハードコードされているため、FAQも「this is a limit hardcoded upstream in R5 so we cannot change it in r5r」としてr5rでは変更できないと明言しています。判定されるのは陸地の面積ではなく道路網データの外接矩形の面積で、R5のソースでは定数の注記が「large enough for California」となっています。つまり離れた離島を含む抽出データは、実際に使う範囲が狭くても矩形が広がって引っかかります。日本の地方別データでの実測値と切り出し方は、前の「日本のOSMとGTFSでネットワークを作る」の節にまとめました。

公共交通と徒歩が同じ結果になる原因

modeにTRANSITを含めたのに結果が徒歩と変わらない原因は2つあります。FAQが挙げる1つ目は、departure_datetimeがその路線の運行日から外れているケースです。GTFS全体で運行サービスがゼロの日は2.4.0ではエラー(「There are no transit services available on the selected departure date」)で止まるので、徒歩と同じ結果が静かに返るのは一部の路線やフィードだけが運行日から外れている場合です。GTFSの運行日はcalendar.txtの基本パターンとcalendar_dates.txtの例外指定で決まり、calendar.txtを持たずcalendar_dates.txtだけで運行日を列挙するフィードもあるため、両方を見て有効日を判断します。サンプルデータの例が2019年5月13日という過去日付になっているのはこのためです。2.4.0で追加されたcheck_transit_availability()は指定日についてtotal_services・active_services・pct_activeを返すので(個々の便数ではなく運行サービスの数です)、日付が原因かどうかをここで切り分けられます。2つ目は、そのODでは公共交通を使っても徒歩より速くならないケースで、FAQも代替の説明として挙げています。この場合は日付を直しても結果は変わりません。

同一地点間で所要時間が出る原因:道路網へのスナップ

起点と終点が同じIDなのに所要時間が出る場合、その地点が道路網から離れていることを疑います。R5は入力点を最も近い通行可能な道路区間へスナップし、入力点からスナップ先までを直線距離の徒歩として計上します。FAQはこの挙動を「it will consider that the person would walk in Euclidean distance from the input point to the snapped location」と説明しています。スナップ先を確認したいときはfind_snap()を使い、大きくずれている点は座標を見直してください。

r5rを選ぶ場面と選ばない場面

r5rが向くのは、時刻表を持つ公共交通を含めて多数のODを一括処理する分析です。多対多の移動時間計算と時間帯を通した探索はR5の設計目的そのもので、都市圏の到達圏やアクセシビリティ指標を作る用途では強いです。運賃を制約に入れられる点や、new_carspeeds・carspeed_scale・new_ltsで渋滞や自転車インフラ整備のシナリオを組める点も、汎用の経路APIでは代替しにくい機能です。

逆に、次の条件なら別の道具を検討してください。GTFSを使わず道路だけの最短経路を出すのであればR5とJavaを抱える必要はなく、OSRMやGraphHopperのような道路向けのエンジンも候補になります(どちらが軽いかは既存のR環境やサーバー構成で変わるので、実際の運用形態で比べてください)。対象範囲の外接矩形が上限を超えるなら、そもそもネットワークを構築できません。そしてサービスの一部として常時稼働させる用途には勧めません。Conveyalが「R5 does not currently expose a stable programming interface」と述べ、サードパーティのラッパーは古いリリースに留まる必要があるかもしれないと明記している以上、長期運用するアプリケーションの依存先には向きません。r5rは分析パイプラインの中で版を固定して使い、結果を成果物として切り出すのが実態に合った使い方です。到達圏や移動時間の結果を業務システムの画面へ載せる場合も、r5rは事前計算に使い、配信側はフルスクラッチ開発のように要件から組むシステムで結果のファイルを読む構成にすると、R5の版更新に引きずられません。

Pythonが主のチームには、同じR5をラップしたr5pyがあります。PyPIの最新版は1.1.7(2026年6月29日公開・Python 3.10以上)で、R5の版が別管理という性質はr5rと同じです。結果をWebで配信する段階まで設計するなら、Web GISとは?タイル配信とベクタタイル・ライブラリ選定を実装目線で解説【2026年8月時点】の配信構成とあわせて検討してください。研究成果でr5rを使う場合の引用先はPereiraらの2021年のFindings論文(DOI: 10.32866/001c.21262)で、citation("r5r")で書式が取れます。

よくある質問

r5rを動かすのに必要なJavaのバージョンはどれですか?

CRANの2.4.0はSystemRequirements: Java JDK (>= 21.0)です。JREではなくJDKが必要で、公式READMEはEclipse Temurinを推奨に挙げています。OSへ入れたくない場合はrJavaEnv::java_quick_install(version = 21)でR内から導入できます。1.x系はJava 11で動いていたので、古い環境から上げるときはJavaの入れ替えも同時に必要です。

-Xmx16Gでメモリを増やしたのにメモリ不足になるのはなぜですか?

2.2.0〜2.4.0では、r5rがJVMを起動するときにこの指定を置き換えてしまい、JVMは物理メモリの4分の1を上限に動くためです。16GBの機械なら約4GBです。rJava::J("java.lang.Runtime")$getRuntime()$maxMemory() / 1024^3で実際の上限を確かめ、足りなければ修正済みの開発版を入れるか、範囲を切り出してネットワークを小さくします。

setup_r5()はまだ使えますか?

2.4.0でも動きますが非推奨です。ドキュメントに「setup_r5() is being deprecated after r5r v2.3.0 and will be removed in a future release」と明記されており、実行すると移行を促す警告が出ます。各関数のr5r_core引数も同時に非推奨なので、build_network()とr5r_networkへまとめて置き換えてください。

計算結果をそのまま地図にできますか?

detailed_itineraries()とisochrone()はsfオブジェクトを返すので、地図パッケージへ直接渡せます。背景に道路網や路線を重ねたい場合は、構築済みネットワークからstreet_network_to_sf()で道路、transit_network_to_sf()で公共交通の線形を取り出せます。travel_time_matrix()やaccessibility()は座標を持たない表を返すため、起点データの側に幾何情報を持たせて結合してください。

日本全国のデータを一度に読み込めますか?

読み込めません。日本全国の抽出データは離島を含む外接矩形がR5の上限975,000平方キロメートルを超えます。地方別のファイルでも九州(沖縄県を含む)は超えるので、都市圏や市町村の単位に切り出してから使います。GTFSは複数のフィードを同じフォルダに置けば統合されますが、有効期間の重なる日付を選んでください。

関連記事

お気に入りに入れた記事の一覧

一創の公式 SNS

X では毎朝の新着記事と IT ニュースの速報を、YouTube・TikTok・Instagram・LinkedIn・Facebook では記事の解説動画を配信しています。

この記事は以下の記事からリンクされています

資料請求

RELATED POSTS 関連記事

目次