市場調査に戻る
Pyplanは計画・分析アプリケーションを構築するプラットフォームです。業務チームと開発者は、Python計算、視覚的な依存関係図、フォーム、シナリオ、ワークフローを使い、需要、在庫、生産、配送、財務を計画します。ベンダーによるホスティングと顧客管理の導入形態を提供し、データ分析やアプリケーション変更が可能なエージェントを備えます。(1, 2, 9, 22)
サプライチェーン総合評価：5.2/10。
| 評価軸 | 得点 |
|---|---|
| サプライチェーンの深度 | 4.6/10 |
| 意思決定と最適化の実質 | 4.2/10 |
| 製品とアーキテクチャの整合性 | 5.6/10 |
| 技術的透明性 | 6.8/10 |
| ベンダーの真剣さ | 4.8/10 |
Pyplanは、計画ソフトウェアを構築するための、特に検査しやすい環境を提供します。決定的な弱点は、その環境と実証された経済的意思決定エンジンとの距離です。在庫ページは需要と供給の不確実性を認識していますが、期待金銭リターンにより購買、配分、生産を選ぶ同時確率計算を公開していません。需要分野の提供内容は、合意予測とシナリオ承認を中心としています。顧客はプラットフォームの背後にある意思決定モデルの多くを用意する必要があります。(3, 4, 5)
この区別は、生産性とリスクの両方に重要です。アプリケーションを速く作れれば開発作業を減らせますが、十分テストされていないコードを本番に入れやすくもなります。Pyplanは有用な実行隔離、バージョン管理、テストを文書化する一方、相当の開発規律を要するライブラリ導入、認証情報へのアクセス、テスト挙動も記載しています。したがってエージェントは、適切な導入プロセスの価値を高めますが、そのプロセスを自動的にはしません。(12, 14, 15, 19, 20)
PyplanとLokadの比較
部品の納入を早めるか、生産を遅らせるか、希少在庫を別の顧客へ配分するかを決めるメーカーを考えてください。Pyplanは計算を表現し、関連データをつなぎ、シナリオを比較し、アプリケーションで結果を提示できます。視覚モデルは個別ロジックを分かりやすくしますが、導入時に代替案、費用、不確実な将来、行動を選ぶルールを定義しなければなりません。共有予測では、この欠けた経済評価は得られません。(2, 4, 5)
Lokadの在庫最適化サービスは、不確実性の下で財務評価する反復的な意思決定を中心に作業を構成します。サプライチェーンサイエンティストが、データと費用の業務解釈を含む実行可能ロジックを構築・保守します。実務上の比較は、Pyplanアプリケーションを構築し維持する全期間費用と、専用意思決定システムを維持する費用の比較です。どちらも専門家の作業を不要にはしません。問題は、その作業が再利用可能な意思決定を改善するか、個別例外を繰り返し解決するかです。
Introduction to Supply Chainが示す視点は受入テストも変えます。良好な予測スコア、短い計画会議、エージェント作成のダッシュボードは、購買の経済性向上を証明しません。重要なのは、ソフトウェア、インフラ、専門作業、業務上の影響を計上した後の、実行済み意思決定のリターンです。
計画アプリケーションは実際に何を決めるか
在庫に関する説明は数値手法の開示より具体的
Pyplanの在庫計画ページは、需要、供給、納入時間の不確実性を明示的に含めます。最適化ページは安全在庫調整と、最小発注量、バッチサイズ、納入頻度、リードタイムのシミュレーションを説明します。これらは重要なサプライチェーン課題です。しかし確率モデル、不確実な数量間の依存関係、競合する資金と能力の用途を調整するアルゴリズムは開示していません。(3, 4)
大きな経済的空白が残ります。安全在庫の変更は、より利益の高い品目に必要な資金を消費しながら、個別品目を守ることがあります。小さいバッチは腐敗を減らしても、追加の段取りや輸送費を招き得ます。導入には、需要増と同時に供給が遅れる場合も含め、これらの影響を共通尺度で評価する必要があります。Pythonでそのモデルを表現できますが、記述できることは、宣伝される在庫アプリケーションがすでにそれを計算している証拠ではありません。
需要計画はより従来型の構造です。統計予測と機械学習予測を、合意した需要見通し、営業調整、シナリオ承認に取り込みます。見出しの約束には、MAPEと表示する予測精度の20%改善と、在庫・サイクル時間削減があります。対応するテスト母集団、予測起点、基準誤差、測定期間は示されません。また、相対的な誤差削減を絶対的な精度水準と読むことはできません。(5)
需要センシングに必要なのは新しい名称ではなく判断の期限
Pyplanは需要センシングを、注文、消費者への販売、在庫、販促、天候などの信号を使い、一～四週間先を頻繁に更新するものと説明します。一～二週間予測について一般に20～50%のMAPE削減を挙げますが、元の研究やテストデータは特定しません。(6)
有用な問いは、まだ判断で結果を変えられる間に、新情報が届くかです。昨日の販売は明日の推定を改善できても、六週間先の部品注文を変更するには遅すぎることがあります。公平な比較には、基準手法に同じ利用可能情報と更新頻度を与え、変わった意思決定の価値を測る必要があります。更新を「センシング」と呼んでも、独自の予測手法にも、この経済検証にもなりません。
顧客事例は業務改善と残存する計画担当者の仕事を示す
2025年12月のNestlé事例は、ブラジルの配送計画を扱います。Pyplanは、前年比340ベーシスポイントの可用性改善、販売機会損失50%減、在庫15%減を報告します。日次のデータ整合、所要量計算、供給元選択、可用性確認、比例配分、積載最適化を説明しています。数値手法と報告成果の寄与の内訳は公表されていません。(7)
同じ記事は、供給提案が計画担当者の承認を待ち、担当者が現在は時間の75%を分析に使うと述べています。これは自ら判断する計画という見出しに条件を付けます。準備と提案生成は自動化されても、人間がまだ判断を評価し承認しているからです。SKU・拠点あたりの残存作業、例外率、支える専門作業量は報告されません。(7)
2025年12月のAlpura事例は、15,000を超えるSKU・顧客・配送センターの組み合わせの需要管理を説明します。実行プロセスの業務時間70%減、平均サービス98%、需要管理の精度「+77%」を報告します。記載された仕事はデータ統合、許容範囲設定、警告、対応の優先付けです。サービスは需要充足の指標であり、定義のない精度値はSKU単位の予測比較に使えません。どちらも、導入と継続保守を差し引いた純経済リターンを証明しません。(8)
技術の歴史：持続するモデル基盤と拡大する自律性の物語
| 時期 | 公開記録 | 評価 |
|---|---|---|
| 2019～2020年 | 公開パッケージpyplan-ideはPythonノード、影響図、対話型インターフェース、共有分析アプリを提供。 |
視覚プログラミングの中核はエージェントの物語より早く、動くソフトウェアとして配布された。(23) |
| 2024年 | 7月のリリース履歴にAIエージェント機能とコード補完を記録。 | 言語モデル支援が特定可能な製品能力となり、後の修正も公開記録された。(11) |
| 2025年 | 6月に計画アシスタント、8月に分析アシスタントを追加。12月の顧客事例は自動化と生成AI支援を説明。 | 提供実績は見えるが、顧客の運用モデルには分析、例外、承認が残る。(7, 8, 11) |
| 2026年 | 7月にアシスタントを統合。現行文書はアプリ編集、個別エージェント、MCPアクセスを公開。 | ソフトウェア構築への拡張には実質がある。新しい在庫目的や同時不確実性モデルは証明しない。(9, 10, 11) |
Pythonを擁護する2026年7月の記事は、透明なルール、再利用可能なロジック、ロックイン回避を強調します。これは以前のPyplan設計と整合します。ただしPythonは依存関係でなく標準だという題名の主張は説得力が弱くなります。プラットフォームは依然としてランタイム、ライブラリ、独自アプリAPIに依存するからです。ソースが公開されていても、依存関係には保守が必要です。(24)
Pyplanの最も強い歴史的証拠は、詳細なリリースを伴う継続的なアプリプラットフォームです。弱いのは、計画支援から自律的な業務判断への話の膨張です。誰が数式を書くかが変わるのは有益ですが、その式が正しい経済問題を表すかは解決しません。
エージェント、アプリ保守、生産性
Pyplan Agentはノード作成、Python記述、フォームと入力キューブの編集、インターフェース構築ができます。個別エージェントはPythonツールを呼び、権限でアクセスを定めた専用ユーザーを通じて業務に参加できます。これらは既存ダッシュボードへの質問回答を越え、アプリ自体を改善できる機能です。(9)
MCPはOAuth認証セッションでアプリ探索、バージョン、モデル操作、保存を公開します。このコネクタは外部エージェントからPyplanを利用可能にしますが、生産的な資産は依然としてモデルと実行可能計算です。同じ計画画面へ会話要求を流しても、顧客業務の経済判断と繰り返される承認は消えません。(10)
バージョン管理はロジック、インターフェース、シナリオ、データ、設定をコピーします。有効版は編集可能、閉鎖版は変更をロック、アーカイブ版は以前の作業を保管します。これは開発と計画サイクルの土台ですが、どの版を業務利用に認め、変更をどう反映するかはチームが決める必要があります。APIエンドポイントはアプリの既定版を実行するため、この選択は外部システムに影響します。(17, 19)
自動化テストは計算値と期待値・範囲を比較し、部門アクセスを検査できます。注意すべき詳細が二つあります。引数なしHTMLコールバックのテストは実際にそれを呼び、データ書き込みや外部処理を起動する場合があります。権限の検査は実行キューでは動きますが、セッション内の同期実行では警告付きで省略されます。したがって成功したテスト結果の範囲は、作者の意図より狭い場合があります。(20)
プラットフォームはホリミゼーションの有用な道具を提供します。配分が悪い結果になれば、単に上書きせずロジックを検査し書き換えられます。欠けている業務上の証拠は、そうした失敗を、経済評価の修正、未見条件での再実行、管理されたリリースまで追う実例です。昨日の期待回答をテストすれば、昨日のモデル化の誤りを保持することもあります。
データ履歴は、確認済みのフォームとキューブ変更をデータと原子的に記録し、実行者、出所、変更前後の値を含めます。新規フォーム・キューブでは既定で有効ですが、既存のものは有効化が必要です。履歴自体で変更は取り消せず、保存記録は自動清掃なしに増えます。これは診断を改善する一方、保存容量と保管管理の仕事を加えます。(21)
ソフトウェア構成と保有費用
| 層 | 文書化された実装 | 保有・運用への影響 |
|---|---|---|
| アプリ実行環境 | KubernetesポッドのPythonエンジン。UI、API、WebSocket、Celeryを分離。 | 実行、バックグラウンド処理、アプリサービスを協調して運用する必要がある。(12) |
| 永続状態と調整 | PostgreSQL、Redis、クラウドストレージ | データ、キャッシュ、ジョブには異なる復旧・更新要件がある。(12) |
| AWS導入 | 三ゾーンのEKS、CloudFormation、Helm、Argo CD、Karpenter、RDS PostgreSQL 16、EFS、負荷分散、NATゲートウェイ | 個別計算の前から、参照設計に常設インフラが必要。(13) |
| アプリ依存関係 | アプリ別Python環境とrequirements.txt。プロセッサアーキテクチャごとに分離。 |
パッケージとランタイム互換性が各アプリの保守対象になる。(14) |
AWS参照構成は二～四台のアプリノードから始まり、計算エンジンノードを需要に応じて用意します。水平拡張はセッション数を増やしますが、単一の結合したサプライチェーン計算が各ノードにまたがって拡張するとは示しません。負荷評価には、計算、データ転送、メモリ、反復評価を含める必要があります。(13)
依存関係の費用はリリース記録にも見えます。2026年5月の修正は、Python 3.9アプリを開けなくするPydantic 2.xの非互換性に対処します。2月の更新はRust関連の不具合を解消するためPolarsの版を変更しています。ライブラリのライセンス料がなくても、スタックが作り出す具体的な保守義務です。(11)
Pyplanのアプリ環境は、アプリを開く際に不足パッケージを自動導入し、画面からライブラリを変えられます。同じIDを残した手動コピーは、意図せず環境を共有することがあり、文書はサポートされた作成コマンドを使うよう指示します。再現性にはPythonソースの保存だけでなく、アプリ識別、パッケージ版、本番移行の規律が必要です。(14)
費用モデルにはアプリ開発者、業務モデル責任者、統合作業、依存関係更新、テスト、担当者の継続レビューを含める必要があります。Pyplanのプラットフォームは、こうした仕組みをゼロから作る必要を減らします。公開事例は、意思決定システムを動かし続けるためのベンダー、パートナー、顧客を合わせた作業量を定量化していません。
セキュリティ：セッション分離はコード封じ込めの一部にすぎない
Pyplan Cloudは各利用者にCPU・メモリを割り当てた専用ポッドを与え、終了時に破棄し、共同入力には共有データベースを用います。ストレージ説明ではプライベートエンドポイントでアクセスを制限します。これはセッションとインフラの具体的な境界です。しかし実務者コードの中心的問題は残ります。悪意あるライブラリは、自分のセッションで正当に使えるデータと権限で何ができるのでしょうか。(12)
文書化された環境では、アプリコードは許可された秘密情報を文字列として取得できます。AWS導入はプライベートサブネットのインターネット通信をNATゲートウェイ経由にし、SAP統合ガイドは送信先を指定エンドポイントへ制限するよう求めます。しかしパッケージ承認、実行時の外向き通信の既定拒否、認証情報なしの計算、必須の本番昇格境界は、これらの資料からは確立しません。この環境へ任意のPythonを持ち込むことは、依然としてサイバーセキュリティ上のアンチパターンです。侵害された依存ライブラリは、自社データを損なうためにコンテナ脱出も他テナントへのアクセスも必要としません。(13, 14, 15, 18)
HTMLインターフェースには別のブラウザ境界があります。隔離されたオリジンのフレームはアプリのCookieやストレージを読めず、Pyplanのコールバック橋渡し機構を通じてモデルと通信します。外部資源はPyplanプロキシ経由で配信されます。これはブラウザの露出を減らしますが、Pythonコールバックには依然として適切なデータ・操作権限が必要です。(16)
API文書はAPIキー割り当てを任意とし、実行ユーザーを選択できます。SAPガイドは認証要求とネットワーク制限を推奨します。したがって外部から呼べる関数には、呼び出し元認証と実行権限の両方を明示設定する必要があります。一般的なエンドポイント資料は、安全な既定設定を必須とはしていません。(17, 18)
2026年11月3日のリリースは、MCP接続における会社・ドメイン制限の適用を修正します。修正を公表するのは有益ですが、この不具合は、会話上の指示と認証だけでテナント範囲を確立できない理由も示します。(11)
復旧にも具体的な限界があります。エージェント会話の復元はインターフェースのスナップショットをメモリに戻せますが、ファイル変更には明示保存が必要です。あらゆるツール効果のトランザクション巻き戻しが文書化されているわけではありません。別途、災害復旧計画はゾーン全体の災害後、データ損失の可能性24時間、アプリ復旧36時間を目標にします。日々の業務判断を支えるとされるシステムでは、これらの時間幅は重要です。(9, 25)
経済的責任
2026年7月の公開規約は、正確性・適合性保証を免責し、損害賠償を広く除外します。既定の総責任上限は直前十二か月の支払いに基づきます。矛盾する条項には別の利用契約が優先します。この公開規約には、測定可能なサプライチェーンリターンや、経済的に不適切なモデルの費用を負担する約束はありません。(22)
信頼できる受入合意は、対象判断、基準方針、評価期間、総反復作業量、有害な推奨を修正する責任を特定します。Pyplanの実名事例には有用な業務上の主張がありますが、こうした経済責任の配分はありません。柔軟性はより良いモデルを作るためのものであるべきです。失望する成果をすべて、顧客がプラットフォームをどう使ったかという反証不能な問題にしてはなりません。
サプライチェーン評価
サプライチェーンの深度
| 基準 | 得点 |
|---|---|
| 経済的な枠組み | 5/10 |
| 意思決定の最終成果 | 5/10 |
| サプライチェーン概念の明確さ | 5/10 |
| 時代遅れの中核的教義からの自由 | 4/10 |
| KPIの見せかけへの耐性 | 4/10 |
平均：4.6/10。
経済的な枠組み。 在庫方針のシミュレーションはサービス、資金、業務上のトレードオフを含みます。公開アプリは品目と資源をまたいで行動を選ぶ共通の金銭目的を示さず、主な経済設計を導入に委ねています。(3, 4)
意思決定の最終成果。 配送アプリは実行可能な調達・配分提案を作ります。計画担当者の承認が顧客業務に残り、経済的に競合する行動の選択ルールは説明不足です。(7)
サプライチェーン概念の明確さ。 変動する供給と需要、補充パラメータ、複数拠点の在庫を認識しています。相互作用の説明に比べて数量的な扱い、特に不確実な入荷日の意思決定への伝播は不明瞭です。(3, 4)
時代遅れの中核的教義からの自由。 合意予測、S&OPの整合、例外警告、シナリオ承認が依然として中心です。これらは担当者を調整しますが、再利用可能な意思決定ロジックで置き換える代わりに、多くの反復作業を残し得ます。(5, 8)
KPIの見せかけへの耐性。 定義のない予測改善の見出しと需要管理精度が、成果比較を難しくします。実名の充足・在庫成果はより関連性がありますが、測定と寄与の特定は不完全です。(5, 7, 8)
意思決定と最適化の実質
| 基準 | 得点 |
|---|---|
| 確率的モデリングの深度 | 3/10 |
| 独自の最適化またはMLの実質 | 3/10 |
| 現実の制約への対応 | 5/10 |
| 意思決定の自動化と労働生産性 | 5/10 |
| 現実の業務複雑性への耐性 | 5/10 |
平均：4.2/10。
確率的モデリングの深度。 需要・供給の不確実性の認識に、同時分布、校正、行動順位付けへの利用の文書化が伴いません。シナリオ比較と調整可能なバッファは、その計算を証明しません。(3, 4)
独自の最適化またはMLの実質。 個別計算は可能ですが、製品ページは在庫ソルバーや予測選択手法を特定しません。需要センシングの説明は入力と頻度を示す一方、同じ情報を使う管理された基準比較を示しません。(2, 4, 6)
現実の制約への対応。 最小発注、バッチ、納入予定、可用性に制約された配送を提供内容に含みます。単一計算がそれらをどう調整し、経済的に重要な非線形性を保持するかは未解決です。(4, 7)
意思決定の自動化と労働生産性。 実名事例は準備・実行業務の削減を報告します。比較可能な意思決定品質における総残存作業は定量化せず、分析レビューと優先付けは運用モデルの大きな部分に残ります。(7, 8)
現実の業務複雑性への耐性。 編集可能ロジック、バージョン、数値テストは失敗したモデルを修正する道具です。有害な推奨から経済評価変更とサンプル外再実行の成功へ至る業務例は文書化されず、権限テストの範囲も実行方式に依存します。(19, 20)
製品とアーキテクチャの整合性
| 基準 | 得点 |
|---|---|
| アーキテクチャの一貫性 | 7/10 |
| システム境界の明確さ | 6/10 |
| セキュリティへの真剣さ | 4/10 |
| ソフトウェアの簡潔さと保有費用 | 4/10 |
| プログラム運用とエージェント支援運用への適合性 | 7/10 |
平均：5.6/10。
アーキテクチャの一貫性。 Pythonノード、依存関係図、アプリ画面、文書化された実行環境が一貫したプラットフォームを形成します。主な断片化リスクは、無関係な買収製品よりも、別々に保守する顧客モデルと依存関係です。(2, 12, 14)
システム境界の明確さ。 統合文書は外部関数、実行者の識別、既定版の境界を特定します。各判断をどのシステムが担当し、実行をどう認証・照合するかはアプリ作者が決める必要があります。(17, 18)
セキュリティへの真剣さ。 セッション隔離とブラウザ封じ込めは具体的です。許可された本番データと取得可能な認証情報を使う任意パッケージ実行は、公開アーキテクチャで十分制限されていません。他テナントの保護では、顧客自身のアクセス可能資産は守れません。(12, 14, 15, 16)
ソフトウェアの簡潔さと保有費用。 クラウドスタックとアプリ別環境は実際の運用・保守作業を課します。事例は合計した専門作業を省き、互換性修正はオープンソース再利用でも開発費用が消えないことを示します。(11, 13, 14)
プログラム運用とエージェント支援運用への適合性。 APIとエージェントは実行可能アプリを作成・変更でき、ダッシュボードとの会話より広い自動化範囲があります。信頼できる無人作業には、モデル変更、権限、不可逆な外部影響の管理がまだ必要です。(9, 10, 17)
技術的透明性
| 基準 | 得点 |
|---|---|
| 公開技術文書 | 8/10 |
| ベンダーの仲介なしでの検証可能性 | 6/10 |
| 移植性とロックインの可視性 | 6/10 |
| 導入手法の透明性 | 8/10 |
| 技術的主張を支える証拠の密度 | 6/10 |
平均：6.8/10。
公開技術文書。 マニュアルは実行、導入、依存関係、テストをかなり詳しく公開します。サプライチェーンのアルゴリズムは、稼働先のアプリ基盤よりはるかに文書化が少ないものです。(4, 13, 14, 20)
ベンダーの仲介なしでの検証可能性。 公開マニュアルと過去のパッケージは具体的な挙動を示します。現行商用アクセスはPyplan経由で手配し、実名顧客モデルは独立検査・再実行に利用できません。(22, 23)
移植性とロックインの可視性。 Pythonロジックとバージョンのエクスポートは顧客の作業を保全します。依存グラフ、フォーム、ワークフロー、プラットフォーム関数は移行先で代替が必要です。共通言語の利用だけでアプリ全体が移植可能にはなりません。(2, 19, 24)
導入手法の透明性。 導入ガイドはインフラとアクセス経路を指定し、アプリマニュアルは重要な限界を含むライブラリとテストの挙動を記載します。この詳細によって、一般的な導入の約束より運用責任を評価しやすくなります。(13, 14, 20)
技術的主張を支える証拠の密度。 リリースノートと技術マニュアルは仕組みによって基盤の主張を支えます。数値・経済面の主張は、製品概要とベンダー作成の顧客成果により強く依存します。(4, 7, 11)
ベンダーの真剣さ
| 基準 | 得点 |
|---|---|
| 公開コミュニケーションの技術的真剣さ | 5/10 |
| 技術ロードマップの一貫性 | 6/10 |
| 概念の明確さ | 5/10 |
| 経済的責任 | 3/10 |
| エージェント型ソフトウェア時代の競争優位の持続性 | 5/10 |
平均：4.8/10。
公開コミュニケーションの技術的真剣さ。 具体的なマニュアルと、実証された判断プロセスを越える自律性・需要センシングの主張が並びます。この隔たりにより、宣伝表現は購入する数値能力の頼りない案内になります。(6, 7, 20)
技術ロードマップの一貫性。 元の視覚プログラミング概念が持続し、日付付きリリースは提供済みエージェント能力と修正を示します。公開史は自律的サプライチェーン経済性より、継続的な基盤開発を説得力をもって示します。(11, 23, 24)
概念の明確さ。 Pyplanは業務ロジックを検査・変更可能にすべきだと理解します。しかしサプライチェーン手法は、不確実性を実行可能行動へつなぐ経済ルールより、合意計画と予測改善をなお重視します。(2, 5)
経済的責任。 顧客成果には完全な費用基準と是正責任の配分が欠けます。公開規約は交渉契約に従いつつベンダーを大きく保護し、経済提案の失敗を定義しません。(7, 8, 22)
エージェント型ソフトウェア時代の競争優位の持続性。 一貫したモデル、アプリ開発道具、企業統合は有用な資産です。汎用エージェントがPythonアプリ構築を安くするにつれ、Pyplanには会話コネクタを越えた、安全な保守と経済的判断品質の実証済み優位が必要です。(9, 10, 14)
出典
[1] Pyplan | FP&AとS&OP向けAIネイティブ計画プラットフォーム
公開資料。2026年11月4日閲覧。
公開資料。2026年11月4日閲覧。
公開資料。2026年11月4日閲覧。
公開資料。2026年11月4日閲覧。
公開資料。2026年11月4日閲覧。
[6] 需要センシング：プロセス、ソリューション、消費財の例
公開資料。2026年11月4日閲覧。
[7] Nestléが従来モデルを脱し、自ら考え、予測し、決める計画を採用
公開資料。公開または更新：2025-12-05。2026年11月4日閲覧。
[8] Alpuraが予測知能と全面的な需要管理で意思決定連鎖を再定義
公開資料。公開または更新：2025-12-05。2026年11月4日閲覧。
公開資料。2026年11月4日閲覧。
公開資料。2026年11月4日閲覧。
公開資料。公開または更新：2023-11-05–2026-11-03。2026年11月4日閲覧。
公開資料。2026年11月4日閲覧。
公開資料。2026年11月4日閲覧。
公開資料。2026年11月4日閲覧。
公開資料。2026年11月4日閲覧。
公開資料。2026年11月4日閲覧。
公開資料。2026年11月4日閲覧。
公開資料。2026年11月4日閲覧。
公開資料。2026年11月4日閲覧。
公開資料。2026年11月4日閲覧。
公開資料。2026年11月4日閲覧。
公開資料。公開または更新：2026-07-27。2026年11月4日閲覧。
公開資料。公開または更新：2019–2020。2026年11月4日閲覧。
公開資料。公開または更新：2026-07-01。2026年11月4日閲覧。
公開資料。2026年11月4日閲覧。