GeoJSONの道路データを扱うときに迷わない5項目

GeoJSONは、道路中心線、道路区域、歩道、交差点周辺の形状、管理用の点情報などを扱うときに便利なデータ形式です。一方で、実務で道路データを読み込み、表示し、編集し、共有しようとすると、線なのか面なのか、座標の順番はどう読むのか、属性名は何を信じればよいのか、縮尺や精度はどこまで期待してよいのかといった迷いが出やすくなります。この記事では、「geojson 使い方」で調べている実務担当者に向けて、道路データを扱う前に整理しておきたい5項目を、現場で確認しやすい流れで解説します。

目次

• GeoJSONの道路データは何を表しているかを最初に確認する

• 座標系と座標順序を取り違えない

• 線データと面データの違いを道路管理の目的に合わせて読む

• 属性情報を見て道路データの意味と限界を判断する

• 表示、編集、共有の前に品質確認の手順を決める

• まとめ：道路データを迷わず使うには現地確認と運用設計が重要

GeoJSONの道路データは何を表しているかを最初に確認する

GeoJSONの道路データを扱うとき、最初に確認したいのは、そのデータが道路の何を表しているのかという点です。道路データと聞くと、道路そのものの形が入っているように思えますが、実際には道路中心線、道路区域、車道の縁、歩道の範囲、道路台帳上の区間、交差点部の代表形状、管理用の点、距離標の位置など、さまざまな内容が含まれます。同じ「道路」という言葉でも、目的によって必要な形状は変わります。通行経路を確認したいのか、道路区域の範囲を整理したいのか、舗装面の管理をしたいのか、占用物や附属物との位置関係を見たいのかで、読むべきデータは大きく異なります。

GeoJSONは、地物を形状と属性の組み合わせで表します。道路中心線であれば、線形状として道路のおおまかな通り道を示すことが多くなります。道路区域であれば、面形状として道路として管理される範囲を示すことがあります。標識、照明、マンホール、距離標のような管理対象であれば、点形状として位置を示すことがあります。これらは同じファイルの中に混在している場合もありますし、別々のファイルとして分けられている場合もあります。そのため、ファイルを開いてすぐに地図上へ重ねるだけではなく、各データが何を対象にしたものかを確認することが重要です。

特に道路データでは、見た目の位置が似ていても、意味が異なる線や面が重なることがあります。たとえば、道路中心線は車道の中央を厳密に測った線とは限らず、道路ネットワークを表すための代表線として作られていることがあります。道路区域の面は、現地で見える舗装面だけでなく、法面、側溝、歩道、管理用地などを含む場合があります。逆に、実際に車が走る舗装範囲だけを表すデータでは、道路区域全体を示せないことがあります。この違いを見落とすと、現地の感覚と画面上のデータが合わない原因になります。

道路データを扱う前には、まずファイル名、属性名、作成目的、提供元の説明、更新時期、作成方法を確認します。提供元の説明が十分でない場合でも、属性名や形状の種類を見ることで、ある程度の推測はできます。たとえば、道路名、路線番号、区間番号、幅員、管理者、種別、延長、起点、終点のような項目があれば、台帳管理や区間管理に近いデータである可能性があります。高さ、勾配、縁石、舗装種別、側溝、歩道幅員のような項目があれば、より詳細な現況管理に近いデータである可能性があります。ただし、属性名だけで断定するのではなく、提供元の仕様書、実際の形状、現地状況と合わせて確認する必要があります。

また、GeoJSONの道路データは、必ずしも測量成果そのものではありません。既存の図面、台帳、現地調査、航空測量、車両計測、手入力、公開データの変換など、作成方法はさまざまです。作成方法が異なれば、期待できる精度も異なります。道路の中心を概略的に示す目的で作られたデータを、境界確認や施工位置の判断に使うのは危険です。反対に、詳細な測量成果を簡略化したデータであれば、表示上は軽く扱えても、元の精度や変換条件を確認する必要があります。GeoJSONという形式で保存されていることと、実務上どこまで正確に使えるかは別の問題です。

道路データを使う目的を決めると、必要な確認事項も整理しやすくなります。閲覧だけであれば、地図上で大きくずれていないか、必要な属性が見えるかが重要になります。資料作成であれば、凡例や注記を含めて、データの意味を誤解されないようにすることが必要です。現地確認に使う場合は、現在地との比較、写真との対応、目印との位置関係が重要になります。設計や協議に使う場合は、座標系、精度、作成時期、責任範囲を明確にしておく必要があります。最初に利用目的を曖昧にしたまま作業を始めると、後から「この線は何を表していたのか」という確認に戻ることになり、作業効率が下がります。

GeoJSONの使い方を覚えるうえでは、形式の読み方だけでなく、道路データの意味を読む姿勢が大切です。ファイルを開けること、地図に表示できること、色を変えられることは入り口にすぎません。実務で必要なのは、そのデータがどの範囲を、どの時点で、どの程度の精度で、何の目的のために作られたものかを説明できることです。この確認ができていれば、後の座標確認、属性整理、品質確認も進めやすくなります。

座標系と座標順序を取り違えない

GeoJSONの道路データで特に間違えやすいのが、座標系と座標順序です。GeoJSONでは、座標値が配列として記録されます。道路中心線のような線であれば、複数の座標点が順番につながって線を作ります。道路区域のような面であれば、外周を構成する座標点が並び、閉じた形状として表されます。この座標の読み方を誤ると、道路が意図しない場所に表示されたり、南北と東西が入れ替わったり、現地と合わない位置に配置されたりします。

まず意識したいのは、座標値の順序です。GeoJSONでは、座標配列は経度、緯度の順で読むのが基本です。日本国内の道路データを見ていると、緯度、経度の順で考えたくなる場面がありますが、GeoJSONの座標配列では経度が先、緯度が後という読み方を前提に確認します。たとえば、東経を表す値と北緯を表す値の順番を取り違えると、地図上でまったく違う場所に表示されます。道路データの表示が極端にずれている場合は、まず座標順序を疑うとよいです。

次に確認したいのは、座標参照の前提です。標準的なGeoJSONでは、経度緯度による位置表現を前提として扱います。一方、実務で受け取るデータの中には、平面直角座標系などのメートル単位の座標をそのまま入れた、標準的なGeoJSONとは扱いが異なるデータや、別形式から変換途中のデータが混じることがあります。そのまま一般的な地図表示に読み込むと、正しい位置に表示されない場合があります。道路データを受け取ったときは、座標値が経度緯度なのか、メートル単位の座標なのか、変換済みなのかを確認する必要があります。

座標値の桁や範囲を見ることも、初期確認に役立ちます。日本周辺の経度緯度であれば、経度はおおむね百を超える値になり、緯度は数十程度の値になります。一方、平面直角座標系などの座標では、数千、数万、数十万といった値になることがあります。もしGeoJSONとして受け取ったファイルの座標値が大きなメートル単位の値になっている場合、そのまま一般的な経度緯度のデータとして表示できるとは限りません。表示する前に、必要な座標変換が済んでいるかを確認します。

道路データでは、わずかな座標のずれが実務上の誤解につながることがあります。広域の路線図や概略図であれば数メートル程度のずれが大きな問題にならない場合もありますが、道路境界、占用物、排水施設、民地との接点、工事範囲の確認では、数十センチから数メートルの違いが判断に影響することがあります。GeoJSONの画面表示だけで正しいと判断するのではなく、元データの作成精度と利用目的を照らし合わせる必要があります。

また、道路データを別の地図や航空写真、現地写真と重ねる場合は、背景側の位置精度にも注意が必要です。GeoJSONの道路データが正しくても、背景地図や画像がずれていれば、見た目には道路データがずれているように見えることがあります。反対に、背景に合わせるためにGeoJSONの座標を安易に手修正すると、本来の測量成果や台帳情報との整合が崩れることがあります。表示上の見た目と、座標データとしての正しさは分けて考えるべきです。

座標系の確認では、代表点を数点選んで現地の既知点や基準となるデータと比較する方法が有効です。交差点の中心、橋梁の端部、道路の曲がり角、公共施設の出入口など、現地でも画面上でも判別しやすい場所を使うと、ずれの傾向が見えやすくなります。全体が同じ方向に平行移動しているのか、回転しているのか、場所によってずれ方が異なるのかを確認すると、単純な座標変換の問題なのか、元データの作成条件の問題なのかを判断しやすくなります。

座標の高さを扱う場合にも注意が必要です。GeoJSONでは、座標に三つ目の値として高さに相当する情報が含まれる場合がありますが、すべての道路データに高さが入っているわけではありません。高さが含まれていても、標高なのか、相対的な高さなのか、何を基準にした値なのかが不明なことがあります。道路勾配、排水、段差、構造物との取り合いを判断するために高さ情報を使う場合は、平面位置以上に慎重な確認が必要です。単に三つ目の数値があるからといって、そのまま設計判断や施工判断に使えるとは限りません。

GeoJSONの道路データを安心して使うには、座標順序、座標参照、単位、変換履歴、背景とのずれ、利用目的を一連の確認項目として扱うことが重要です。特に複数の部署や協力会社とデータを共有する場合は、座標の前提を口頭だけで伝えるのではなく、ファイル説明や運用資料に明記しておくと誤解を減らせます。座標の扱いは一度間違えると後工程のすべてに影響するため、道路データを読み込む最初の段階で時間をかけて確認する価値があります。

線データと面データの違いを道路管理の目的に合わせて読む

GeoJSONの道路データでは、線と面の違いを理解することが重要です。道路は現地では幅を持つ空間ですが、データとしては線で表されることも、面で表されることもあります。どちらが正しいというより、何を目的にしたデータなのかによって適切な表現が変わります。道路中心線のような線データは、路線のつながり、延長、経路、区間管理に向いています。道路区域や舗装範囲のような面データは、範囲、重なり、占用、工事範囲、維持管理対象の整理に向いています。

線データは軽量で扱いやすく、道路ネットワークの把握に適しています。複数の道路がどこで接続しているか、起点から終点までどのようにつながるか、路線番号や管理区間がどう分かれるかを確認する場合、線データは便利です。道路の延長を概算したい場合も、線の長さを使うことで確認できます。ただし、線データは道路の幅や区域を直接示すものではないため、道路敷地の範囲、歩道や車道の境界、民地との境、側溝の位置などを判断するには不十分な場合があります。

面データは、道路の広がりを視覚的に把握しやすい点が特徴です。道路区域、舗装範囲、歩道範囲、工事対象範囲などを面で表すと、他の地物との重なりや抜け漏れを確認しやすくなります。たとえば、道路区域と占用物の位置を重ねる場合、線データだけでは対象が道路内にあるか外にあるかを判断しにくいことがあります。面データであれば、範囲内外の確認がしやすくなります。一方で、面データは形状が複雑になりやすく、データ量が大きくなることがあります。境界の作り方や頂点の密度によっては、表示や編集が重くなることもあります。

道路中心線をもとに道路の幅を仮に持たせて面のように見せる方法もあります。この方法は概略図や説明資料では役立ちますが、道路区域そのものを表しているとは限りません。道路幅員が場所によって変わる場合、中心線から一定幅を広げただけでは実際の道路形状と合わないことがあります。交差点、曲線部、隅切り、橋梁部、拡幅部、歩道の有無などがある場所では、単純な幅設定では現地の形に追従できません。中心線から作った面と、実際の道路区域の面は別物として扱うべきです。

線データと面データを同時に扱う場合は、役割を分けて考えると整理しやすくなります。線データは道路の骨格を示すもの、面データは管理範囲や利用範囲を示すものとして扱うと、画面上で見たときの意味が明確になります。たとえば、線には路線番号や区間名を持たせ、面には区域種別や管理区分を持たせるように分けると、後から検索や集計をしやすくなります。すべての情報を一つの形状に詰め込むより、目的別にデータを分けたほうが運用しやすい場合があります。

道路データでは、点データも重要な役割を持ちます。距離標、標識、照明、排水桝、道路附属物、点検箇所、写真撮影位置などは、点として管理されることが多いです。点データは位置を示すには便利ですが、対象物の大きさや向きまでは表せないことがあります。標識であれば、設置位置だけでなく、どの方向を向いているか、どの車線に関係するかが必要になる場合があります。排水桝であれば、道路面との高さ関係や集水方向も重要になります。点、線、面のどれで表すかは、管理したい情報の内容によって選ぶ必要があります。

GeoJSONでは、複数の線や複数の面をまとめて扱うこともあります。道路データでは、一つの路線が複数の線分に分かれていたり、一つの道路区域が複数の面に分かれていたりすることがあります。分割されている理由は、行政界、管理区間、交差点、橋梁、作成時期、属性の違いなどさまざまです。画面上では連続して見えても、属性上は別の地物として扱われることがあります。集計や編集を行う前には、形状の連続性だけでなく、属性上の区切りも確認する必要があります。

線と面の違いを理解していないと、道路データの加工時に問題が起きます。線を結合したつもりで区間情報が失われたり、面を簡略化した結果として境界の形が変わったり、点を移動したことで現地写真との対応が崩れたりすることがあります。道路管理では、形状だけでなく、履歴や根拠も重要です。編集前のデータを保存し、どの作業で何を変えたのかを記録しておくと、後から確認しやすくなります。

実務で迷わないためには、道路データを表示したときに、これは線なのか、面なのか、点なのかを意識して見ることが大切です。さらに、その形状が現地の何を代表しているのかを説明できるようにしておく必要があります。道路中心線を道路境界の代わりに使わない、道路区域を舗装面と混同しない、点の位置を対象物全体の範囲と勘違いしないという基本を押さえるだけでも、GeoJSONの道路データは扱いやすくなります。

属性情報を見て道路データの意味と限界を判断する

GeoJSONの道路データでは、形状だけでなく属性情報が非常に重要です。属性情報とは、各地物に付けられた説明項目のことです。道路名、路線番号、管理者、幅員、延長、種別、区間番号、起点、終点、更新日、調査日、舗装種別、規制情報、備考などが属性として入っていることがあります。地図上に線や面が表示されていても、属性を確認しなければ、その道路データをどのように解釈すべきか判断できません。

まず確認したいのは、属性名が何を意味しているかです。属性名は必ずしも標準化されているとは限りません。同じ道路名を表す項目でも、ファイルによって名称が異なることがあります。路線番号や区間番号も、管理主体や作成目的によって意味が違う場合があります。略称や内部管理用のコードが使われている場合、初見では意味が分からないこともあります。属性名の意味が不明なまま集計や検索を行うと、意図しない対象を抽出してしまうことがあります。

属性値の表記ゆれにも注意が必要です。同じ道路種別を表しているのに、全角と半角、漢字とかな、略称と正式名、空白の有無が混在していることがあります。管理者名や地区名のような文字情報では、表記ゆれが集計結果に影響しやすくなります。たとえば、同じ分類の道路を集計したつもりでも、表記が少し違うだけで別分類として扱われることがあります。GeoJSONを実務で使う場合は、属性値をそのまま信じるだけでなく、表記の統一や欠損の確認を行うことが大切です。

数値属性にも確認が必要です。幅員、延長、面積、標高、勾配、距離などの項目が入っている場合、その単位を確認しなければなりません。メートルなのか、センチメートルなのか、別の管理単位なのかが分からないまま使うと、計算結果が大きくずれます。また、数値が文字列として保存されている場合もあります。画面上では数字に見えても、処理上は文字として扱われていることがあり、並べ替えや集計で期待どおりに動かないことがあります。単位、型、空欄、異常値を確認することが、属性利用の基本です。

更新日や調査日の属性がある場合は、道路データの鮮度を判断する手がかりになります。道路は工事、拡幅、舗装補修、区画整理、交通規制の変更、施設更新などによって状態が変わります。古いデータを現在の状況として使うと、現地と合わない可能性があります。ただし、更新日の項目があっても、それが形状の更新日なのか、属性の更新日なのか、ファイル作成日なのかは確認が必要です。更新日が新しいからといって、すべての地物が最新の現地状況を反映しているとは限りません。

属性情報を使うと、道路データを目的別に絞り込めます。特定の管理者の道路だけを表示したり、一定以上の幅員の道路を抽出したり、点検対象の区間を選んだりできます。これはGeoJSONを実務で使う大きな利点です。一方で、属性が不完全な場合、絞り込み結果がそのまま正しいとは限りません。空欄の地物、分類が未設定の地物、古い分類のまま残っている地物があると、必要な対象が漏れることがあります。抽出条件を決めたら、抽出されたものだけでなく、抽出されなかったものにも注意を向ける必要があります。

道路データの属性では、主キーに相当する識別情報も重要です。各地物を一意に区別できる番号やコードがあれば、写真、点検記録、補修履歴、協議記録、帳票などと結び付けやすくなります。識別情報がない場合、道路名や位置だけで対象を判断することになり、同じ名称の区間や近接する地物を取り違える可能性があります。継続的に管理するデータであれば、地物ごとの識別情報を整備しておくと、後からの運用が安定します。

属性情報は、表示用と管理用で分けて考えると扱いやすくなります。表示用の属性は、地図上で見た人がすぐに理解できる名称や分類です。管理用の属性は、内部コード、更新履歴、責任部署、確認状態、点検年度などです。すべての属性を画面上に表示すると見づらくなりますが、必要な属性を消してしまうと管理に支障が出ます。道路データを共有する際は、閲覧者に見せる項目と、管理者が保持する項目を整理しておくとよいです。

GeoJSONはテキスト形式で中身を確認しやすい一方、属性が多くなると人の目だけでは全体を把握しにくくなります。道路データの件数が増えるほど、属性の欠損や表記ゆれを手作業で見つけるのは難しくなります。実務では、まず代表的な数件を目視確認し、その後に全体の件数、空欄の数、分類ごとの件数、異常な数値の有無を確認する流れが現実的です。属性情報の品質を確認しておけば、後の地図表示、検索、集計、帳票作成が安定します。

属性情報を見るときに大切なのは、そのデータで判断できることと、判断できないことを分けることです。道路名が分かるデータでも、境界の正確な位置までは分からないことがあります。幅員が入っているデータでも、現地の有効幅員や一時的な障害物の有無までは分からないことがあります。点検年度が入っているデータでも、現在の損傷状態までは分からないことがあります。属性は便利ですが、属性に書かれていない情報を勝手に補って判断しないことが、道路データを安全に使ううえで重要です。

表示、編集、共有の前に品質確認の手順を決める

GeoJSONの道路データを扱うときは、表示、編集、共有の前に品質確認の手順を決めておくことが大切です。道路データは一度共有されると、複数の人がそれを前提に判断することがあります。表示の色や線の太さが分かりやすくても、元データにずれや欠損があれば、誤った判断につながる可能性があります。特に道路管理、工事調整、現地確認、占用協議、点検計画などに使う場合は、データの見た目だけでなく、中身の確認が欠かせません。

最初に確認したいのは、ファイルとして正しく読めるかどうかです。GeoJSONは構造が決まっているため、括弧やカンマ、座標配列、属性の書き方が崩れていると、読み込みに失敗することがあります。別形式から変換したデータでは、文字コード、属性名、空欄、特殊な文字、非常に長い属性値などが原因で問題が出ることがあります。読み込めたとしても、一部の地物だけが欠落している場合もあるため、ファイル全体の件数を確認し、変換前後で地物数が変わっていないかを見ることが有効です。

次に、形状の品質を確認します。道路中心線であれば、線が途中で切れていないか、不要な重複がないか、交差点で接続関係が不自然になっていないかを見ます。道路区域や舗装範囲の面であれば、面が閉じているか、自己交差がないか、細長い不要な面が発生していないか、隣接する面との隙間や重なりがないかを確認します。点データであれば、道路から大きく外れていないか、同じ位置に重複点がないか、明らかに異なる場所に飛んでいないかを見ます。

道路データでは、全体表示と拡大表示の両方が必要です。全体表示では、座標系のずれや広域的な欠落に気づきやすくなります。拡大表示では、交差点、曲線部、橋梁部、道路端部、区域の重なりなどの細かい問題を確認できます。全体では問題なく見えても、拡大すると線が道路外を通っていたり、面が建物や水路にかかっていたりすることがあります。逆に、拡大した一部だけを見ていると、全体的な座標ずれや区域の抜けを見落とすことがあります。道路データの確認では、縮尺を変えながら見ることが重要です。

編集を行う場合は、元データの保存と変更履歴の管理が欠かせません。道路データは、少し線を動かすだけでも意味が変わることがあります。交差点付近の中心線を調整したつもりが、路線延長や接続関係に影響する場合があります。道路区域の面を修正したつもりが、隣接する区域との重なりや隙間を発生させることもあります。編集前のファイル、編集後のファイル、編集理由、編集者、編集日を記録しておくと、後から確認や差し戻しがしやすくなります。

共有前には、受け取る相手が何を目的に使うのかを想定する必要があります。閲覧用であれば、必要な属性だけを見やすく整理し、凡例や説明文を付けることが大切です。分析用であれば、属性名や単位を分かりやすくし、欠損値の扱いを説明する必要があります。現地確認用であれば、現在地や写真、点検記録と結び付けやすい構成にしておくと便利です。設計や協議に使う場合は、精度や更新時期、使用上の注意を明記し、誤った用途に使われないようにします。

GeoJSONをそのまま共有すると、中身を編集できる相手が増える一方で、どのファイルが最新版なのか分からなくなることがあります。ファイル名に日付や版を入れる、管理台帳で版を記録する、共有用と編集用を分ける、確定版は不用意に上書きしないといった運用が必要です。道路データは複数人で扱うことが多いため、ファイルそのものの品質だけでなく、運用上の品質も重要です。

表示品質も軽視できません。線の色、太さ、透明度、ラベルの表示方法によって、道路データの印象は大きく変わります。道路区域の面を濃く塗りすぎると背景が見えなくなり、道路中心線を細くしすぎると確認しづらくなります。点データの記号が大きすぎると、実際の位置より広い範囲を占めているように見えることがあります。表示は単なる見た目の調整ではなく、誤解を防ぐための情報設計です。

品質確認の手順は、毎回その場で考えるのではなく、定型化しておくと効果的です。たとえば、読み込み確認、件数確認、座標確認、形状確認、属性確認、代表地点の現地照合、表示確認、共有前確認という流れを決めておけば、担当者が変わっても一定の品質を保ちやすくなります。道路データは扱う範囲が広くなるほど確認漏れが起きやすいため、個人の経験だけに頼らず、手順として残すことが重要です。

品質確認は、完璧なデータを作るためだけの作業ではありません。データの限界を理解し、どこまで使えるかを判断するための作業でもあります。道路データには、古い情報、概略的な形状、未確認の属性、作成目的に由来する制約が含まれることがあります。それらを把握したうえで使えば、実務に役立つ情報になります。反対に、限界を確認しないまま使うと、見た目が整っているほど誤解が大きくなることがあります。

まとめ：道路データを迷わず使うには現地確認と運用設計が重要

GeoJSONの道路データを扱うときに迷わないためには、形式の使い方だけでなく、道路データそのものの意味を理解することが大切です。最初に、そのデータが道路中心線なのか、道路区域なのか、舗装範囲なのか、管理用の点なのかを確認します。次に、座標順序、座標参照、単位、変換履歴を確認し、地図上で正しい場所に表示されているかを見ます。そのうえで、線、面、点の違いを目的に合わせて読み分け、属性情報からデータの意味と限界を判断します。最後に、表示、編集、共有の前に品質確認の手順を決めておくことで、実務での誤解や手戻りを減らせます。

GeoJSONは扱いやすい形式ですが、道路管理に必要な判断をすべて自動で保証してくれるものではありません。道路中心線を見て道路幅を判断したり、道路区域の面を見て現在の舗装状態を断定したり、属性の更新日だけを見て現地状況が最新だと決めたりすると、実務上のずれが生じます。データの作成目的、精度、更新時期、属性の意味を確認し、必要に応じて現地確認と組み合わせることが重要です。

特に道路の現地確認では、机上のGeoJSONデータと現場の状況をどう結び付けるかが課題になります。道路端、側溝、標識、距離標、舗装の切れ目、工事範囲、占用物などは、画面上の座標だけでは判断しきれないことがあります。現場で取得した位置情報や写真、点群、メモを道路データと結び付けられるようにしておくと、確認結果を社内共有や協議資料に活用しやすくなります。

GeoJSONの使い方を実務に落とし込むには、データを見る人、編集する人、現場で確認する人、資料にまとめる人の間で、同じ前提を共有することが重要です。どのファイルが最新版か、どの座標の前提で扱うか、どの属性を信頼するか、どこから先は現地確認が必要かを決めておけば、道路データは単なる地図表示ではなく、業務判断を支える情報になります。

道路データをより確実に扱うには、現場で取得した情報を位置付きで残し、GeoJSONなどの地理データと結び付けて確認できる運用を整えることが役立ちます。道路の現況確認、点検、施工前後の記録、協議用資料の整理までを見据えるなら、使用する機器、アプリ、測位条件、記録形式、共有方法をあらかじめ決めておくと、現地確認とデータ管理をつなげやすくなります。