点群OBJアップロードで非対応記述が問題になる理由
点群をOBJ形式で保存し、クラウドや閲覧環境へアップロードしようとしたとき、ファイル自体は存在しているのに読み込みが途中で止まったり、アップロード完了後に何も表示されなかったりすることがあります。こうした問題では、ファイル容量や通信状態だけでなく、OBJファイル内にアップロード先が解釈できない記述が含まれていないか確認することが重要です。
OBJはテキスト形式で形状情報を記録できるデータ形式です。代表的なのは頂点座標を示す「v」の記述ですが、それ以外にも法線、テクスチャ座標、面、線、点、グループ、オブジェクト名、材質参照、スムージング設定など、さまざまな情報を記載できます。さらに、用途によっては曲線や曲面などを扱うための記述が含まれることもあります。
ここで注意したいのは、OBJ形式として記述できる情報と、アップロード先が実際に読み込める情報は同じではないということです。OBJに含めることができる記述であっても、受け側のシステムがその記述を実装していなければ、無視される場合もあれば、読み込みエラーの原因になる場合もあります。
特に点群 OBJ アップロードでは、必要な情報が頂点座標を中心とした比較的単純なデータであるにもかかわらず、元の処理環境から書き出したOBJに面情報や材質情報、グループ設定、特殊な形状定義などが残っていることがあります。点群として利用したいだけなのに、不要な記述まで一緒に渡している状態です。
また、「非対応記述」という言葉は、OBJとして誤った記述という意味だけではありません。OBJの仕様上は扱える記述でも、アップロード先が対応していなければ実務上は非対応です。そのため、単純にファイルが壊れているかを見るのではなく、「アップロード先が必要としている情報に対し、このOBJには何が書かれているか」という視点で確認する必要があります。
OBJはテキストとして内容を確認できるため、この切り分けがしやすい形式でもあります。ファイルを複製したうえでテキストとして開き、各行の先頭にどのような記号やキーワードが使われているかを確認すると、読み込みトラブルの原因候補を絞り込めます。
ここからは、点群OBJをアップロードするときに確認したい非対応記述を、5つの観点から整理します。
チェック1｜OBJ内の記述キーワードを洗い出す
最初に行いたいのは、OBJファイルにどの種類の記述が入っているかを把握することです。いきなり一行ずつ内容を読もうとすると、大規模な点群では数十万行、数百万行以上になることもあり、確認作業が現実的ではありません。そこで、まず各行の先頭に使われているキーワードを見ることが重要です。
点群として最も基本になるのは「v」で始まる幾何頂点の座標です。通常はX、Y、Zに相当する3つの値が並び、標準OBJでは用途に応じて4番目の同次座標wを持つこともできます。一方、一部のソフトウェアでは「v」の後ろにRGBなどを追加する頂点カラー表現も使われますが、これは元来のWavefront OBJ標準に含まれる表現ではなく、実装依存の拡張として扱う必要があります。したがって、追加値がある場合は、値の個数と意味、アップロード先の対応範囲を確認することが重要です。
「vn」は頂点法線、「vt」はテクスチャ座標に関係する記述です。三角形メッシュなどを扱う場合には重要ですが、単純な点群表示では不要になる場合があります。「f」は面を表すための記述で、頂点番号を参照して三角形や多角形を構成します。「l」は線、「p」は標準OBJで点要素を定義するために利用される記述です。
このほか、「g」でグループ、「o」でオブジェクト、「s」でスムージング設定、「mtllib」で材質定義ファイルへの参照、「usemtl」で使用する材質を指定することがあります。これらが存在すること自体をエラーと考える必要はありません。重要なのは、アップロード先がそれらを必要としているか、対応しているかです。
点群OBJでトラブルが発生したときは、まず「v以外に何が入っているか」を把握すると原因を整理しやすくなります。たとえば、頂点座標だけのつもりで保存したファイルに大量の「f」が存在するなら、実際には点群ではなく面を持つモデルとして出力されている可能性があります。
逆に「v」しか入っていないOBJを、面を前提とする読み込み環境へ投入した場合には、頂点は存在していても表示対象として認識されない可能性があります。標準OBJで点要素を明示する記述は「p」であり、「v」だけを点群として表示するかどうかは読み込み側の実装に依存します。つまり、記述を少なくすれば必ず成功するわけではありません。アップロード先が頂点だけのOBJを点群として受け付けるのか、「p」を必要とするのか、あるいは面情報を持つOBJを前提としているのかを区別することが必要です。
ファイルを確認するときは、先頭付近だけで判断しないことも大切です。OBJは処理の途中でグループや材質が切り替わることがあり、ファイル後半に別の種類の記述が現れる場合があります。大容量ファイルであれば、使用されている行頭キーワードを種類ごとに抽出して確認できるテキスト処理環境を利用すると効率的です。
この段階では、まだ記述を削除しません。最初に「どの種類の記述が含まれているか」という全体像を作り、その後のチェックで不要な候補を絞り込むことが安全です。
チェック2｜面・線・点を表す記述が必要か確認する
次に確認したいのが、「f」「l」「p」など、頂点をどのように利用するか指定する記述です。点群OBJアップロードでは、この部分が読み込み結果を大きく左右することがあります。
「v」は幾何頂点の座標を定義しますが、標準OBJでは、それだけで点・線・面の要素を定義したことにはなりません。面を構成する場合に「f」、線を構成する場合に「l」、点要素を構成する場合に「p」などの記述を使用します。ただし、実際の点群向けインポーターの中には「v」の一覧だけを点群として解釈するものもあるため、対応状況はアップロード先ごとに確認する必要があります。
たとえば三角形メッシュでは、多数の「v」で頂点座標を記録した後、「f」で複数の頂点を参照して面を構成します。このファイルを点群として利用したい場合、面情報まで必要なのかを確認する必要があります。アップロード先が点群データとして頂点だけを利用する独自の仕組みを持つなら、面情報は使われない可能性があります。
一方、アップロード先がOBJを一般的な三次元モデルとして解釈し、面が存在することを前提としている場合、頂点だけを残すと何も表示されないことがあります。そのため、「点群だからfを全部削除すればよい」と単純に決めるのは危険です。
さらに確認したいのが、「f」に書かれている参照形式です。面の記述では、頂点番号だけを並べる形式のほか、テクスチャ座標や法線を合わせて参照する形式があります。区切り記号を用いて複数の番号を指定するため、受け側の実装によっては一部の形式だけを想定していることがあります。
同じOBJでも、「頂点番号のみの面」と「頂点、テクスチャ、法線を組み合わせた面」では行の構造が異なります。アップロードエラーが面情報のあるファイルだけで発生する場合は、面そのものだけでなく、面の参照形式も確認対象です。
また、OBJの頂点参照には、ファイル先頭からの順番を使う正のインデックスだけでなく、記述位置から前にさかのぼって参照する負のインデックスも仕様上利用できます。形式として有効な書き方でも、読み込み側が限定的な実装になっている場合には、期待どおり処理されないことがあります。
線を示す「l」や点を示す「p」についても同様です。標準OBJで点要素を定義するのは「p」ですが、実務上の点群用OBJでは、変換ソフトや読み込み側の仕様によって「v」だけを並べる構成が使われることもあります。したがって、「p」がないことだけをもってファイル不正とは判断できません。
このチェックで見るべきなのは「f、l、pがあるかないか」だけではありません。アップロードしたいデータの目的と、それぞれの記述が一致しているかを見ることが重要です。
点群として扱いたいのに、面や線に関する記述が大量に入っている場合は、変換元で別の出力設定を選んでいないか確認します。逆に、三次元モデルとして表示したいのに頂点座標だけしか存在しない場合は、アップロード先の仕様との不一致を疑います。
こうしてデータの意味とOBJ内の記述を対応させることで、「形式はOBJなのに読み込めない」という曖昧な問題を、「面情報の扱いに問題がある」「頂点だけでは表示できない」といった具体的な問題に分解できます。
チェック3｜自由曲面など利用していない高度な記述を探す
OBJは単純な頂点と面だけを記録する形式として知られていますが、実際にはそれ以外の形状表現に関する記述も存在します。点群OBJを扱う実務ではほとんど必要としない記述が、変換元の処理によって残っているケースもあるため注意が必要です。
代表的な確認対象の一つが、「vp」のようなパラメータ空間の頂点に関する記述です。通常の三次元座標を示す「v」と見た目が似ていますが、役割は異なります。点群を単純にXYZ座標として扱いたい場合、このような記述を利用する必要性は一般に低くなります。
さらに、曲線や曲面、自由形状を扱うための記述が含まれるOBJもあります。こうした機能はOBJの表現力を広げるものですが、すべての読み込み環境が対応しているとは限りません。特に、点群アップロードを目的としたシステムでは、頂点や基本的な面だけを対象として実装されていることがあります。
重要なのは、高度な記述を見つけたからといって、そのファイルが壊れていると判断しないことです。元の作成環境では正しく意味を持っている可能性があります。問題になるのは、アップロード先がそれを解釈できるかどうかです。
点群データとして必要なのが座標と、必要に応じてアップロード先が対応する色情報だけであれば、自由曲面に関連する情報を保持する意味がない場合があります。そのようなときは、元データを保管したうえで、アップロード用に必要最低限の情報へ変換したOBJを別に作成する方が安全です。
ここで避けたいのは、元ファイルを直接編集して特殊な行だけを次々に削除する方法です。OBJでは複数の記述が互いに参照関係を持つことがあります。一つの種類の行を削除すると、別の記述が存在しない情報を参照する状態になる可能性があります。
実務では、非対応の可能性がある記述を見つけたら、まず元ファイルを変更せず保存します。そのうえで複製ファイルを作成し、必要な情報だけを残した検証用データを用意します。アップロードに成功するかを比較すれば、その記述が原因だったのかを確認できます。
また、変換元にOBJの出力項目を選べる設定があるなら、手作業で削除するより、最初から必要な要素だけを書き出す方が望ましいです。手作業では行の削除漏れや参照番号の不整合が起こりやすいためです。
点群OBJアップロードで原因不明のエラーが発生した場合、「OBJなのだから全部読めるはず」と考えず、受け側がOBJのどの範囲まで対応しているかを見る必要があります。単純な検証ファイルは成功するのに、元ファイルだけ失敗する場合は、このような追加記述が切り分けの重要な手掛かりになります。
チェック4｜材質ファイルや外部参照に関する記述を確認する
OBJアップロード時に見落としやすいのが、OBJ本体とは別のファイルを参照する記述です。OBJは形状を一つのファイルに保存できますが、材質に関する情報を外部ファイルへ分け、OBJ側から参照する構成も利用できます。
OBJ内に「mtllib」がある場合、材質定義を記録したMTLファイルを参照している可能性があります。また、「usemtl」は、後続の形状にどの材質を使うかを指定するために使われます。
点群を座標中心で利用する場合、こうした材質情報が不要なケースもあります。一方で、色情報や見た目を維持するために必要なデータとして利用されているケースもあります。ここでも、材質記述そのものを一律に削除するのではなく、アップロード先で必要かどうかを確認することが基本です。
特に注意したいのは、OBJだけをアップロードし、参照先のMTLやテクスチャ画像を一緒に渡していない状態です。OBJ内に外部ファイルへの参照が残っていても、アップロード環境からそのファイルを利用できなければ、材質が再現されない可能性があります。読み込み側の動作によっては、参照先が見つからないことが警告やエラーにつながることも考えられます。
ファイル名の扱いにも注意が必要です。参照記述と実際のファイル名が一致しているか、余分なフォルダ階層を前提とした記述になっていないか、アップロード後にも同じ参照関係を維持できるかを確認します。
ローカル環境では正常に表示されるのに、クラウドへアップロードすると材質だけ消える場合は、外部参照の扱いが変わっている可能性があります。ローカルでは同じフォルダにあるファイルへアクセスできても、アップロード時にはOBJだけが保存されているという違いがあるためです。
点群の場合はさらに、色の保存方法が一定とは限らない点に注意します。標準OBJでは材質やテクスチャをMTLと組み合わせて表現しますが、実務では「v」行の末尾にRGB値を追加する頂点カラー拡張など、標準仕様外の方法が使われることもあります。こうした拡張は対応ソフトでは利用できても、すべてのアップロード先で互換性があるとは限りません。アップロード先が想定している色情報の持ち方と一致しなければ、形状は表示できても色が再現されないことがあります。
したがって、「色が出ない」という症状と「OBJ自体を読み込めない」という症状は分けて考える必要があります。外部参照が利用できなくても形状だけ読める環境がある一方、想定外の記述を厳密に処理する環境では読み込み処理に影響する場合もあります。
点群OBJをアップロードするときは、OBJ単体で完結しているのか、関連ファイルを前提としているのかを最初に整理しましょう。単体アップロードを前提とするのであれば、外部参照のないデータへ変換する方法も検討対象になります。
チェック5｜数値・インデックス・行構造の特殊な書き方を確認する
最後のチェックは、記述キーワードではなく、一行の中身です。同じ「v」や「f」であっても、数値や参照番号、区切り方がアップロード先の想定と異なると読み込みトラブルにつながる場合があります。
まず頂点座標では、一行に何個の数値があるかを確認します。基本的な幾何頂点はX、Y、Zの3値で表せますが、標準OBJでは用途に応じて4番目のwを持つことができます。また、一部の出力環境ではRGBなどを追加した非標準拡張も使われます。アップロード先が一定数の値しか想定していない場合は、追加された値の意味を正しく解釈できるか確認する必要があります。
数値の表現方法にも注意します。非常に大きな座標値や非常に細かな小数を扱う点群では、小数点以下の桁数が多くなることがあります。また、処理環境によっては指数を用いた数値表現が出力される場合もあります。数値として解釈可能な表現でも、読み込み側の実装が限定的なら問題になる可能性があります。
点群の座標が大きな値になっている場合は、非対応記述とは別に、座標系や原点からの距離も確認しておくとよいでしょう。ファイルとして読み込めても、表示環境側の数値処理や表示範囲の都合で、データが見えにくくなることがあります。アップロード失敗と表示位置の問題を混同しないことが大切です。
面情報では、頂点番号が実際に存在する範囲を参照しているかを確認します。たとえば、定義されていない頂点番号を参照する面が含まれていれば、読み込み側によってはエラーになります。ファイル変換や手編集の途中で行を削除すると、こうした参照不整合が発生しやすくなります。
参照番号の形式も確認対象です。OBJでは正の番号だけでなく、記述位置から前方の既出頂点を相対的に示す負の参照番号も仕様上利用できます。元の環境では問題なく開けても、アップロード先がその形式を実装していなければ、同じように解釈されるとは限りません。
空行、コメント、余分な空白についても、一般には問題にならないことが多いものの、切り分け時には確認しておく価値があります。標準OBJでは「#」で始まる行はコメントとして扱われますが、変換途中で独自の文字列や制御用の情報が通常のデータ行として挿入されている場合、それが標準的なOBJ記述として扱われないことがあります。
文字コードの違いも、ファイル内にオブジェクト名やグループ名などの文字列が含まれている場合に注意したいポイントです。元来のOBJはASCIIベースのテキスト形式として仕様化されているため、非ASCII文字を含む名称の扱いはソフトウェア間で差が出る可能性があります。座標だけのOBJでは問題になりにくいものの、名称に日本語などが含まれている場合は、アップロード先との組み合わせによって文字列処理に影響する可能性があります。
改行の扱いも確認します。異なる環境を経由して生成、編集、再保存されたファイルでは、行構造が意図せず変わることがあります。テキストとして開いたときに行が極端につながっている、途中で不自然に分割されている、特定の箇所だけ別の構造になっている場合は、変換工程を見直した方が安全です。
このチェックで重要なのは、「キーワードが正しいからOBJは正常」と判断しないことです。OBJは一行ごとのデータ構造が重要なので、同じキーワードでも値の個数、順番、参照先が異なれば結果が変わります。
非対応記述を見つけた後の安全な修正手順
非対応と思われる記述を見つけても、すぐ元ファイルを編集するのは避けます。最も重要なのは、元データを保持したまま原因を切り分けることです。
最初に元のOBJを変更禁止の原本として保存し、検証用のコピーを作成します。そのコピーから、原因候補になっている記述だけを変更します。一度に複数種類の記述を削除すると、アップロードに成功しても何が原因だったのか分からなくなります。
たとえば、材質参照が疑わしいのであれば、まず材質を利用しない形で再出力したファイルを試します。それで結果が変わらなければ、次に面情報や特殊な記述を確認します。このように一つずつ条件を変えることで、原因を絞り込めます。
手作業で行を消す方法は、小さな検証ファイルでは有効ですが、大規模なOBJでは注意が必要です。特に「v」の行を途中から削除すると、「f」や「p」などの参照番号との対応が崩れることがあります。頂点数を減らす場合は、単純な行削除ではなく、参照関係も含めて正しく再構成できる方法を使う方が安全です。
アップロード用データを簡略化する場合は、「何を残す必要があるか」を先に決めます。座標だけ必要なのか、色も必要なのか、面も必要なのか、法線が必要なのかを整理すれば、削除対象を判断しやすくなります。
また、アップロードエラーが発生しているからといって、必ずOBJ内部の記述が原因とは限りません。容量制限、ファイル名、通信状態、サーバー側の処理、関連ファイル不足など、別の原因も考えられます。非対応記述の確認は重要ですが、これだけに原因を限定しないことも必要です。
点群OBJを再出力するときに確認したいこと
非対応記述を手作業で除去するより、元の点群からOBJを再出力できる場合は、必要な情報だけを指定して書き出す方が管理しやすくなります。
再出力時には、最初に用途を明確にします。点群として位置を確認することが目的なのか、表面を持つ三次元形状として表示することが目的なのかで必要な記述が変わります。ここを曖昧にしたままOBJを作成すると、不要な面や材質まで含めたり、逆に必要な要素を省いたりする原因になります。
点群として利用するのであれば、頂点座標が正しく保存されていることが最優先です。点要素を標準OBJとして明示する必要がある環境では「p」も確認します。色が必要な場合は、アップロード先が対応する色情報の表現方法が標準MTLなのか、頂点カラーなどの拡張なのかも確認します。面表示が必要であれば、頂点だけでなく面の参照関係が正常である必要があります。
座標系も再確認します。OBJそのものが座標参照系の意味をすべて自動的に共有してくれるとは限りません。同じ数値でも、どの座標系や基準を想定しているかによって実際の位置は変わります。アップロードに成功した後の位置ずれを防ぐためにも、元データと出力データの座標条件を記録しておくことが重要です。
単位についても同様です。OBJ内の座標値だけを見ても、その数値をメートルとして扱うのか、別の単位として扱うのかを読み込み側が自動判断できない場合があります。アップロード先で想定する単位と出力時の単位をそろえておきます。
ファイル名も単純なものにして検証すると切り分けやすくなります。原因調査中は、複雑な名称や深いフォルダ構造を避け、OBJ本体と必要な関連ファイルだけをまとめた状態で試すと、外部要因を減らせます。
再出力後には、ファイルサイズだけでなくOBJ内部の記述も比較します。元ファイルに含まれていたキーワードが再出力後にどう変わったかを見ると、設定変更が実際のファイルへ反映されているか確認できます。
アップロード前に小さなOBJで切り分ける方法
大容量の点群OBJで問題が起きたとき、毎回ファイル全体をアップロードして確認する方法は効率的ではありません。そこで有効なのが、最小構成に近い小さなOBJを用意して、アップロード先の対応範囲を確認する方法です。
まず、少数の「v」だけを持つ単純なデータを用意し、アップロード先が頂点だけのOBJを点群として扱う仕様なら、その状態で試します。標準OBJの点要素を必要とする環境では「p」を追加し、一般的な三次元モデルとして面を必要とする環境では「f」を含む最小データを使います。最小構成のファイルがアップロードできるなら、OBJという拡張子そのものが拒否されている可能性は低くなります。次に、元ファイルで利用している追加要素を一つずつ加えます。
たとえば頂点だけのファイル、頂点と点要素を持つファイル、頂点と面を持つファイル、材質参照を追加したファイルというように条件を分ければ、どの段階で読み込み結果が変わるか確認できます。
ここで重要なのは、実際の点群から無理に一部を切り出さなくても、変換元から小範囲だけを書き出せるのであれば、その方法を利用することです。手作業で巨大なOBJの途中を切り取ると、頂点番号と面参照の関係が崩れる可能性があります。
小さな検証ファイルでは、内容を目視しやすいという利点もあります。巨大なOBJでは見逃していた特殊な記述も、数十行程度のデータなら確認しやすくなります。
検証用OBJが成功し、同じ構成の大容量OBJだけが失敗するのであれば、非対応記述ではなく容量や処理時間、頂点数、面数など別の制約を疑いやすくなります。逆に、小さなファイルでも特定の記述を追加した途端に失敗する場合は、その記述とアップロード先の互換性を重点的に確認できます。
この方法は、原因を「OBJ形式が悪い」という大きな括りから、「この記述を含む場合に問題が起きる」という具体的な状態へ絞り込むために有効です。
点群OBJアップロードを安定させる運用の考え方
点群OBJのアップロードトラブルを減らすには、問題が発生してからファイルを修正するだけでなく、書き出しからアップロードまでの運用を統一することが重要です。
まず、アップロード用OBJの作成条件を決めておきます。座標、色情報、面、法線、材質など、どの情報を含めるかを案件ごとに変えるのではなく、利用目的に応じた標準設定を用意しておくと確認しやすくなります。
次に、元データ、編集データ、アップロード用データを区別します。アップロードエラーのたびに同じOBJを直接編集すると、どの変更によって状態が変わったのか追跡できなくなります。原本を残し、変換条件ごとに別ファイルとして管理する方が安全です。
ファイル名に処理内容を反映させる方法も有効です。ただし、名称を複雑にしすぎると外部参照との対応を管理しにくくなるため、一定の命名規則に統一します。特に材質ファイルなど関連データがある場合は、OBJと関連ファイルの組み合わせが分かる状態にしておきます。
アップロード前の確認項目も固定すると効率が上がります。OBJ内に想定外の行頭キーワードがないか、関連ファイルはそろっているか、座標値に異常がないか、頂点参照に不整合がないか、検証用データで読み込めるかを同じ順序で確認します。
また、正常にアップロードできたOBJを基準ファイルとして保管しておくと便利です。問題のあるOBJと正常なOBJを比較することで、記述キーワードやデータ構造の違いを発見しやすくなります。
点群データは案件や計測範囲によって容量が大きく変化します。そのため、あるファイルで成功した方法が、別の大規模ファイルでも必ず同じ結果になるとは限りません。それでも、ファイル構造を統一しておけば、記述上の問題なのか、データ量の問題なのかを切り分けやすくなります。
実務で重要なのは、OBJを単なる拡張子として扱わないことです。同じ「.obj」であっても、中身に含まれる情報は異なります。アップロード前に内部構造を確認する習慣を持つことで、「OBJだから対応しているはず」という思い込みによる手戻りを減らせます。
まとめ｜OBJの全記述を必要と考えず用途に合わせて整理する
点群OBJアップロード時に読み込みエラーや表示不良が発生した場合は、OBJファイルの中にアップロード先が想定していない記述が含まれていないか確認することが重要です。
最初に行頭のキーワードを洗い出し、「v」「vn」「vt」「f」「l」「p」「g」「o」「s」「mtllib」「usemtl」など、どの種類の情報が含まれているかを整理します。そのうえで、点群として必要な情報と、面・線・材質・自由形状などの追加情報を分けて考えます。
さらに、キーワードだけでなく、頂点座標の数値表現、面の参照方法、追加値の有無、関連ファイル、文字列、改行なども確認することで、読み込み側との不一致を細かく切り分けられます。特に、「v」だけを点群として表示する挙動や「v」行末のRGB頂点カラーはソフトウェア依存になり得るため、標準OBJの記述と実装拡張を分けて確認することが重要です。
重要なのは、OBJで記述できる情報がすべてのアップロード環境で同じように扱われるわけではないという点です。OBJとして有効な情報でも、点群表示を目的とした環境では使われないことがあります。反対に、不要だと思って削除した情報が表示に必要な場合もあります。
そのため、非対応記述を探すときは、元ファイルを直接変更せず、複製した検証ファイルで一つずつ条件を変える方法が安全です。アップロード先の仕様に合う最小構成のOBJから試し、必要な要素を段階的に追加すれば、問題が発生する条件を特定しやすくなります。
点群 OBJ アップロードを安定させるには、エラーのたびに場当たり的な修正を行うのではなく、どの情報を必要とするか、どの形式で書き出すか、どの状態を正常と判断するかをあらかじめ整理しておくことが有効です。
現場で取得した位置情報や三次元データを、その後の確認や共有まで一貫して扱いたい場合は、ファイル変換だけでなく、取得段階からデータの位置基準や利用方法を整理することも重要になります。こうした点群や位置情報の取得、確認、共有をより現場に近いところから進めたい場合は、LRTK Phoneを活用した測位・三次元データ運用も次の選択肢として検討できます。