注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

トラブルシューティングガイド

このガイドの手順に沿って、Python 環境の作成時によく発生する問題をデバッグしてください。

トラブルシューティングガイド

パッケージの依存関係解決中にチェックに失敗する

以下のチェックの失敗については、コードリポジトリ内の「チェック」タブでチェックログを表示できます。これらのログから、チェックに失敗した原因を確認できます。

新しい Mamba エラーメッセージ

Palantir は、環境の初期化時のエラーメッセージの書式を改善することで、オープンソースの Mamba コミュニティに貢献しました ↗。2023年2月以降、Foundry サービスでは、環境の作成失敗の原因となる依存関係ツリーの制約違反をより正確に示すエラーメッセージが利用されています。

依存関係ツリー

次の例では、

packageA
   ├─ packageB
   └─ packageC
        └─ packageD

パッケージ packageB と packageC は packageA の直接的依存関係です。packageD は packageC の直接的依存関係ですが、packageA の推移的依存関係です。packageA は packageD に対する直接的な制約を持ちませんが、packageA が packageC に対して持つ直接的な要件によって、packageD にも間接的に制約が課されます。この概念の実際の例を以下に示します。

statsmodels
├─ numpy
├─ scipy
├─ matplotlib
│  │  ├─ libpng
│  │  ├─ setuptools
│  │  ├─ cycler
│  │  ├─ dateutil
│  │  └─ kiwisolver

statsmodels が libpng に制約を課すことは、一見するとわかりにくいかもしれませんが、matplotlib に対する制約を通じて推移的に制約を課しています。

直接的な競合

直接的な競合は、同じ環境で同じパッケージの異なるバージョンが要求されたときに発生します。python 3.7 と python 3.8 の両方を含む単純な環境を要求する場合を考えてみましょう。これは直接的な競合であり、環境の作成に失敗します。新しいエラーメッセージには、次の情報が表示されます。

  Could not solve for environment specs
  The following packages are incompatible
  ├─ python 3.7**  is requested and can be installed;
  └─ python 3.8**  is uninstallable because it conflicts with any installable
   versions previously reported.

上記のメッセージは、python 3.7 自体はインストールできることを正しく説明しています。ただし、そのバージョンをインストールした場合、さらに別のバージョンをインストールしようとすると競合が発生します。この環境の依存関係は、環境から Python のいずれかのバージョン制約を削除することで解決できます。

ただし、直接的な競合は、依存関係や推移的依存関係によって生じる競合と比べて、かなりまれです。

直接的依存関係の競合

NumPy のドキュメント ↗ には、numpy >=1.22.0 が python >=3.8 を必要とすることが明記されています。そのため、python 3.7.* と numpy 1.22.0 の両方を要求する環境を作成しようとすると、直接的依存関係の競合が発生します。次のエラーメッセージが表示されます。

Could not solve for environment specs
The following packages are incompatible
├─ numpy 1.22.0**  is installable with the potential options
│  ├─ numpy 1.22.0 would require
│  │  ├─ python >=3.9,<3.10.0a0 , which can be installed;
│  │  └─ python_abi 3.9.* *_cp39, which can be installed;
│  ├─ numpy 1.22.0 would require
│  │  ├─ python >=3.10,<3.11.0a0 , which can be installed;
│  │  └─ python_abi 3.10.* *_cp310, which can be installed;
│  └─ numpy 1.22.0 would require
│     ├─ python >=3.8,<3.9.0a0 , which can be installed;
│     └─ python_abi 3.8.* *_cp38, which can be installed;
└─ python 3.7**  is uninstallable because there are no viable options
   ├─ python [3.7.10|3.7.11|...|3.7.9] conflicts with any installable versions previously reported;
   ├─ python [3.7.0|3.7.1|3.7.2|3.7.3|3.7.6] would require
   │  └─ python_abi * *_cp37m, which conflicts with any installable versions previously reported;
   └─ python [3.7.10|3.7.12|...|3.7.9] would require
      └─ python_abi 3.7.* *_cp37m, which conflicts with any installable versions previously reported.

このエラーメッセージは、numpy 1.22.0 が Python 3.8、3.9、3.10 のいずれかであればインストールできるものの、要求されたバージョン 3.7.* とは競合することを示しています。この環境の依存関係は、Python または NumPy のいずれかの制約を緩和することで解決できます。たとえば、python 3.8.* と numpy 1.22.0、または python 3.7.* と numpy 1.* のいずれの組み合わせでも、環境の作成に成功します。

環境のトラブルシューティングにおいては、python と python_abi のバージョンは連動していると考えて差し支えありません。環境で python_abi を指定する代わりに、python のバージョンを調整することで、python_abi のバージョンを調整できます。

推移的依存関係の競合

同様に、推移的依存関係によってパッケージの競合が発生することもあります。推移的依存関係の性質上、わずかな数のパッケージを要求するだけで、環境の依存関係解決処理に数百の制約が追加されることがあります。statsmodels パッケージを例に考えてみましょう。

statsmodels
├─ numpy
├─ scipy
├─ matplotlib
│  │  ├─ libpng
│  │  ├─ setuptools
│  │  ├─ cycler
│  │  ├─ dateutil
│  │  └─ kiwisolver

特定のバージョンの statsmodels を要求すると、このパッケージが matplotlib に依存しているため、使用できる setuptools のバージョンに制約が課されます。その結果、statsmodels 自体が setuptools に制限を課す仕組みによって、互いに対応しないバージョンの statsmodels と setuptools を環境で要求すると、推移的依存関係の競合が発生する可能性があります。

たとえば、huggingface-adapter 0.1.1* と transforms 1.645.0 を要求する次の環境を考えてみましょう。

The following packages are incompatible
  ├─ huggingface-adapter 0.1.1** * is installable and it requires
  │  └─ palantir_models >=0.551.0 *, which requires
  │     └─ pyspark-src >=3.2.1,<3.3.0a0 *, which can be installed;
  └─ transforms 1.645.0 * is uninstallable because it requires
     └─ pyspark-src 3.2.1_palantir.36 *, which conflicts with any installable versions previously reported

この2つのパッケージが互いに対応していない理由は、一見するとわかりにくいかもしれません。エラーメッセージから、huggingface-adapter の推移的依存関係が、transforms の pyspark-src に対する直接的依存関係と競合していることが原因だとわかります。この環境の依存関係は、transforms または huggingface-adapter のいずれかの制約を緩和することで解決できます。これにより、Mamba は pyspark-src の要件が両立するバージョンの組み合わせを特定できます。

新しいエラーメッセージを解釈する

新しい mamba エラーメッセージに表示される可能性のあるすべての表現と、その解釈、および対処方法を以下に示します。

The following packages are incompatible または The following package could not be installed：通常、詳細なエラーメッセージの最初の文には、これらのいずれかが表示されます。これは、問題全体が、互換性のないバージョンによるパッケージの競合なのか、必要なパッケージのインストール自体に関する問題なのかを示します。
- 対処方法：この文の直下にある必要な情報を確認します。
can be installed：この文は通常、依存関係ツリーの最上部に表示され、パッケージ自体は追加の制約なしでインストールできることを意味します。ただし、この特定のバージョンがインストールされたと仮定すると、ほかのパッケージの依存関係がそのインストール済みバージョンと競合するため、競合が発生する可能性があります。たとえば、python 3.7** is requested and can be installed は、環境に Python 3.7 をインストールできることを意味します。この文の直下に表示されるほかの競合はすべて、環境に Python 3.7 がインストールされていることを前提としています。
no viable options：インストール可能なバージョンのいずれも、要求された環境のほかの指定によって課される制約を満たせません。たとえば、python 3.7** is uninstallable because there are no viable options というメッセージは、別のパッケージまたは制約が異なる Python バージョンを明示的に要求していなければ、python 3.7.* のバージョンをインストールできることを示します。
- 対処方法：このパッケージで利用可能な選択肢の範囲外に許容バージョン範囲を限定しているパッケージの制約を緩和します。
does not exist, perhaps a (typo or a) missing channel：インストールするパッケージが見つかりませんでした。これは、パッケージの指定が誤っているか、設定済みのどのチャネル（Code Repositories の設定 > ライブラリ、または Code Workbook の環境設定）にもパッケージが含まれていない可能性が高いことを意味します。たとえば、python 3.423.*（存在しないバージョン）と pthon 3.8.*（明らかな入力ミス）を含む環境を要求すると、次のエラーメッセージが表示されます。

 Could not solve for environment specs
  The following packages are incompatible
  ├─ pthon 3.8**  does not exist (perhaps a typo or a missing channel);
  └─ python 3.423** does not exist (perhaps a typo or a missing channel).

対処方法：パッケージの指定に入力ミスがないこと、または要求されたすべてのパッケージが環境で利用可能であることを確認してください。Foundry でパッケージの存在を検索する方法については、Python ライブラリを見つけるを参照してください。
is installable and it requires：パッケージとその指定バージョンは環境にインストールできますが、環境に追加の制約が課されます。
is uninstallable because it requires：依存関係の一部が環境内で競合を引き起こすため、パッケージとその指定バージョンをインストールできません。
- 対処方法：メッセージの下に表示される依存関係の要件のうち、問題の原因となっているものを確認し、それらの制約か、この特定のパッケージの制約を緩和します。
is installable with the potential options：このパッケージには、環境にインストール可能で、競合しないバージョンがいくつかあります。これらのバージョンのいずれかを選択すると、さらに制約が課される可能性があります。
conflicts with any installable versions previously reported：通常、上の行で言及されたバージョンとの対比で表示されます。そのパッケージについて、can be installed とすでに仮定されているバージョンが別の箇所で決まっているため、このバージョンの要件は満たせないことを示します。
- 対処方法：同じ環境で、直接的にも推移的にも、同じパッケージの異なる2つのバージョンを要求していないことを確認してください。
is missing on the system：これは特に、仮想パッケージ ↗がないことを指します。一部のパッケージは、特定の OS 環境でのみ実行できます。たとえば、cudatoolkit ↗ パッケージでは、既存のアーキテクチャでパッケージを実行できるようにするため、システムレベルの機能である __cuda の特定のバージョンが、仮想パッケージとして環境に存在する必要があります。
which cannot be installed (as previously explained)：すでに前述の競合があるか、別のパッケージに前述の制約と完全に同じ制約が含まれているため、パッケージをインストールできません。

レガシー Mamba エラーメッセージ

新しい Mamba エラーメッセージの導入前に使用されていたレガシーエラーメッセージのうち、よくあるものを以下に示します。

パッケージが見つからない

この場合、設定済みのどのチャネルからも依存関係であるパッケージ A が提供されていません。

Copied!1
Problem: nothing provides requested A.a.a.a

これは、固定したパッケージのバージョンが存在しない場合に発生することがあります。その場合は、meta.yml 内のパッケージのバージョン指定を緩和するか、削除してみてください。たとえば、matplotlib 1.1.1 を matplotlib に変更します。

外部リポジトリでは Conda のラベル ↗に対応していないため、ラベル内のパッケージは Palantir リポジトリから発見可能ではありません。

このエラーが発生した場合は、以下のアプリケーション別の手順に従ってパッケージを追加できます。

foundry-add-dependencies

依存関係が見つからない

この場合、パッケージ A に必須の依存関係 B が含まれていますが、どのチャネルからも提供されていません。

Copied!1
Problem: nothing provides B-b.b.b needed by A-a.a.a:

B は、ユーザーが明示的に要求したパッケージ（meta.yml/foundry-ml/vector プロファイル内）、または推移的依存関係である可能性があります。

これは、お使いのエンロールメントで B をインストールできない場合に発生することがあります。たとえば、B の公開が停止されたため、インストールできなくなっている可能性があります。

その場合は、すべての依存関係を利用できる A のバージョンが存在する可能性があるため、A のバージョン固定を解除してみてください。または、Palantir の担当者に連絡して、必要なパッケージを Foundry にインポートしてください。

パッケージの重複エラー

Copied!1
cannot install both X.a.b.c and X.d.e.f

このエラーは、同じパッケージ X をインストールしようとしたときに、異なる2つのバージョン固定がある場合に発生します。たとえば、meta.yml で python 3.9.* と python 3.10.* の両方を固定しようとすると、このエラーが発生することがあります。重複したパッケージのバージョン固定を1つ削除すると、この問題を解決できます。

権限エラーをデバッグする

Copied!1
CondaService:ReadRepositoryPermissionDenied

このエラーが発生した場合は、必要なアセットやパッケージの一部がエンロールメントで利用できない可能性があります。すべてをエンロールメントにインストールしたら、必ず再デプロイしてください。

パッケージの競合

この場合、パッケージ A にパッケージ B のバージョン要件がありますが、その B のバージョンがほかのパッケージと競合しています。

Copied!1
Problem: package A-a.a.a requires B >=2.2.5,<2.3.0a0, but none of the providers can be installed

パッケージ B は、meta.yaml ファイルに要件として明示的に記載していない、A の推移的依存関係を指している可能性があります。推移的依存関係について詳しくは、環境作成の概要を参照してください。

パッケージの競合をデバッグする

依存関係の解決に失敗する例を、控え目な構成で作成します。環境の依存関係を正常に解決できるまでパッケージを削除し、その後、解決を妨げているパッケージが特定できるまでパッケージを追加し直します。
制約の緩和（パッケージのバージョン固定の解除）を試します。
- この作業をより速く進めるには、複数のリポジトリや同じリポジトリの複数のブランチを別々のウィンドウで開く（Code Repositories の場合）か、プロファイルを使う（Code Workbook の場合）ことができます。
- 問題を特定するには、二分探索を使用することを推奨します。1つのリポジトリではすべての制約を削除し、別のリポジトリでは半分の制約を削除し、さらに別のリポジトリでは残りの半分を削除する、というように試します。
Code Workbook では、pandas、matplotlib、numpy に最小バージョンを指定して、デフォルトの pandas=0、matplotlib=2、numpy<1.20 が使用されないようにできます。これらのデフォルトよりも高いバージョンが必要な場合は、環境 > Spark 環境をカスタマイズ > プロファイルをカスタマイズに移動し、各パッケージのドロップダウンメニューからバージョンを選択して、バージョン要件を満たします。
Mamba が生成するログの詳細度を上げることもできます。これにより、依存関係ツリーのさらに下位にある推移的依存関係を追跡しやすくなります（注：チェックの実行速度は低下します）。詳細度を上げるには、CI ログで Execution failed for task ':transforms-python:<task-name>'. という行を探し、チェックに失敗したタスクを特定します。たとえば、失敗したタスクが condaPackRun の場合は、内側の transforms-python/build.gradle ファイルの末尾に次のブロックを追加します。

Copied!1
2
3
tasks.condaPackRun {
    additionalArguments "-vvv"
}

バージョン固定を解除しても依存関係の解決に失敗するのはなぜですか？

制約を完全に緩和しても、要件リストに必要なパッケージまたはパッケージのバージョンが、次のいずれかに該当する可能性があります。

利用できない。パッケージタブで、利用可能なパッケージとバージョンを確認できます。必要に応じて、Palantir の担当者に連絡し、これらのパッケージの追加を依頼できます。
互換性がない。公開済みのすべてのバージョンにアクセスできたとしても、これらのパッケージ定義の組み合わせには互換性がない可能性があります。たとえば、依存している Conda パッケージの1つが、問題のある新しいバージョンにアップグレードされている可能性があります（アップグレード PR を参照）。
meta.yml 内の Python バージョンに対応していない。

この状況に該当するか確認するには、成功したチェックに関連付けられた Conda ロックファイルと、失敗したチェックのロックファイルを比較します。Conda ロックファイルにアクセスするには、設定の歯車アイコンで非表示のファイルとフォルダーを表示の選択肢を選択し、transforms-python/conda-versions.run.linux-64.lock に移動します。成功した実行と失敗した実行の間で変更されたライブラリについて、meta.yaml ファイルで別のバージョンに固定します。

要求したパッケージに変更がない場合の失敗

これが発生する主な理由は2つあります。

トランスフォームが外部パッケージに依存している場合（公開管理されている Conda チャネルを参照）、残念ながら、上流で何かに問題が生じると失敗する可能性があります。
アップグレード PR をマージすると、チェックの実行時に環境の依存関係が再解決されます。まれに、特に環境の制約が厳しすぎる場合、パッケージの依存関係の解決に失敗することがあります。これは、アップグレード PR によって新しい依存関係が追加され、環境の再計算が必要になることがあるためです。アップグレード PR が適用されたコミットを元に戻したときにチェックが成功するかどうかをテストすることで、アップグレード PR が原因だったか確認できます。その後、上記のセクションに沿って作業し、アップグレード PR を再適用できます。

`meta.yml` に変更がない場合の処理速度低下をデバッグする

Code Repositories の場合：

このブランチをアップグレードします（詳しくは、ブランチの手動アップグレードを参照してください）。
引き続き処理速度が遅く、@transform_df タグの外側でコードを変更している場合は、そのコードによってチェックの速度が低下した可能性があります。該当する場合は、このコードのパフォーマンスを評価します。

`meta.yml` に変更があった場合のジョブのタイムアウト

長時間実行されるジョブでメモリー不足（OOM）エラーが発生している場合、パッケージのバージョンに互換性がなく、環境の依存関係を解決できないことが原因の可能性があります。解決するには、まずこのブランチをアップグレードし、その後、上記のデバッグ手順を実行します。

Conda エラーによるビルドの失敗

Copied!1
CondaEnvironmentSetupError

ビルドエラーが発生した場合は、次の手順で解決します。

ドライバーログでエラーを確認します。
コードや meta.yml に変更を加えた場合（変更の確認にはジョブ比較ツールを使用します）、変更を元に戻してビルドの問題が解決するか確認します。meta.yml の変更を元に戻すことで問題が解決する場合は、パッケージの競合が発生している可能性が高く、上記の説明に従ってデバッグできます。meta.yml を変更していない場合は、ビルドの Python モジュールのバージョンを確認します（次の手順を参照）。それでもビルドの問題が解決しない場合は、ブランチのアップグレードまたは基盤のアップグレード（アップグレード PR を参照）に伴う依存関係の解決によって、依存関係を解決できない環境になった可能性があります。その場合は、上記のデバッグ手順を確認してください。
変更を加えていない場合、成功したビルドを実行した Python モジュールのバージョンは、失敗したビルドのものと異なっていませんか？「インフラストラクチャの詳細」、「環境」、*「SparkModuleVersion」*の順に確認します。このバージョンに戻すことについて、Palantir の担当者にお問い合わせください。

spark-module-version

複数ダウンロードの失敗

Copied!1
RuntimeError: Multi-download failed

このエラーは、パッケージのダウンロード元のアーティファクトチャネルにアクセスできないか、エンロールメントでアーティファクトを利用できないことを示しています。実際の失敗の内容はドライバーログで確認できます。

このリポジトリをテンプレート化しようとしている場合は、Conda チャネルの一覧に移動し、一覧にあるチャネルに警告が表示されていないか確認します。警告が表示されているチャネルがある場合は、次の手順に従います。

問題のあるチャネルを削除します（必要に応じて、Palantir の担当者に権限をリクエストしてください）。
チェックを再実行します。
ビルドを再実行します。

Entry Point Error によるビルドの失敗

Copied!1
transforms._errors.EntryPointError: "Key {name} was not found, please check your repo's meta.yaml and setup.py files"

このエラーは、ビルドの実行に必要なルートファイルに、必要な情報が不足していることを示しています。データセットプレビューは使用できる場合がありますが、ビルドは失敗します。

この問題をデバッグするには、meta.yaml または setup.py に必要な情報が不足していないか確認します。参考として、新しい Python コードリポジトリを作成し、そのリポジトリの meta.yaml ファイルと setup.py ファイルを確認できます。

不足している情報を meta.yaml や setup.py に追加したら、変更をコミットし、チェックが成功するのを待ってから、ビルドを再実行します。

Conda パッケージと JAR の両方を必要とするパッケージ

一部のパッケージは、利用するために Conda パッケージと JAR の両方を必要とします。一般的な例として graphframes パッケージがあります（Conda パッケージには Python API が含まれ、JAR には実際の実装が含まれています）。Conda パッケージのみを追加し、必要な JAR を追加しない場合、次のエラーが発生することがあります。

o257.loadClass.: java.lang.ClassNotFoundException:<Class>

または、次のエラーが発生することがあります。

Java のクラスパス（classpath）参照エラーです - 使用中の Python の依存関係が、クラスパスに含まれていない Java jar を参照しようとしています。最近追加した Python の依存関係を確認し、build.gradle ファイルに必要な Java パッケージ（JAR）への依存関係を追加してください。

このようなパッケージを追加するには、次の2段階の手順が必要です。

パッケージタブから、通常の方法でリポジトリに Conda パッケージを追加します。
設定の歯車アイコンで、隠しファイルとフォルダーを表示するオプションを選択し、内部の transforms-python/build.gradle ファイルを選択します。ファイルの末尾に、次のブロックを追加します。

Copied!1
2
3
dependencies {
    condaJars '<group_name>:<name>:<version>'
}

これらのパッケージがユニットテストにも必要な場合は、テスト時に利用できるようにする必要があります。そのためには、gradle ファイルに次のブロックを追加します（テスト用プラグインは sparkJars の依存関係より前に宣言する必要があります）。

Copied!1
2
3
4
5
6
7
// テスト用プラグインを適用します
apply plugin: 'com.palantir.transforms.lang.pytest-defaults'

dependencies {
    condaJars '<group_name>:<name>:<version>'
    sparkJars '<group_name>:<name>:<version>'
}

Conda パッケージと JAR の両方を必要とする外部ライブラリの別の例として、Spark-NLP ↗ パッケージがあります。このパッケージの JAR の依存関係は、build.gradle ファイルに追加する必要があります。

まず、Spark-NLP を外部ライブラリとして追加します。

spark-nlp-conda-add-button

上記で追加したライブラリのバージョンに対応する JAR を、サブプロジェクト内の build.gradle ファイル（通常は transforms-python/build.gradle）に追加します。たとえば、上記の Spark-NLP のライブラリバージョンは 5.0.2 なので、次の手順では、このバージョンの要件を満たす JAR を追加します。<group_name>:<name>:<version> の形式を使用すると、次のコードで build.gradle スクリプトに JAR を追加できます。

dependencies {
     condaJars 'com.johnsnowlabs.nlp:spark-nlp_2.12:5.0.2'
 }

名前で指定されている対象バージョンが不明な場合は、Maven ↗ にアクセスして目的のライブラリを検索し、Foundry で確認したライブラリのバージョンに対応する対象バージョンを見つけてください。

依存関係の競合を回避するためのベストプラクティス

上記のエラーで最も多い原因は、依存関係の競合です。依存関係の競合を減らすには、次のベストプラクティスに従ってください。

依存関係の競合を回避するためのベストプラクティス：Python

Python のバージョン指定は major.minor 形式にしてください。

Code Repositories では、Python 3.9.*、3.10.*、3.11.* を利用できます。Python のバージョンは固定せず、パッケージ名 python のみを指定することを推奨します。ただし、特定のバージョンの Python でコードを実行する必要がある場合は、build セクションと run セクションの両方で、選択したバージョンに固定してください。Python 3.8.* は現在非推奨です。引き続き使用できますが、2025年1月以降はサポート対象外となります。Python 3.6.* と 3.7.* はサポート対象外となりました。

build-and-run-python-versions-same

build セクションと run セクションの Python の依存関係が同一であることを必ず確認してください。Python の依存関係が一致していないと、意図しない結果や失敗につながる可能性があります。

Python のバージョンには、python >=3.9 や python >3.9,<=3.10.11 のような範囲指定は利用できません。サポート対象外の Python バージョンが指定された場合は、非推奨の Python 3.6.* がデフォルトになります。そのため、meta.yaml ではサポート対象の Python バージョンを有効な形式で固定してください。

Code Workbook では、自動を必要なバージョン指定に変更することで、バージョン指定を切り替えられます。

code-workbooks-python-versioning

Python バージョンのサポート

Python 3.9 以降、Foundry は Python End Of Life ↗ で定義されているスケジュールに従います。つまり、サポート終了が宣言された Python バージョンは、プラットフォームでもサポート対象外となります。詳細については、Python のバージョンページを参照してください。

依存関係の競合を回避するためのベストプラクティス：Python 以外のパッケージ

依存関係の競合を引き起こす可能性があるため、バージョンの明示的な固定は避けてください。major.minor 形式のバージョン指定でも、競合が発生する可能性があります。

Code Workbook では、自動設定時のデフォルトが pandas=0、matplotlib=2、numpy<1.20 になるため、pandas、matplotlib、numpy に最小バージョンを指定できます。

その他の問題

上記のガイダンスだけでは問題を解決できない場合、またはこのガイドの範囲外の問題が発生した場合は、試したデバッグ手順の詳細を添えて、Palantir の担当者にお問い合わせください。

←

PREVIOUS環境作成の概要

NEXTライブラリ / Python ライブラリの検索と使用

→