市場調査に戻る
ketteQは、需要、在庫、生産、保守部品、受注履行の計画用クラウドソフトウェアを提供しています。PolymatiQエンジンが計画シナリオを評価し、Quintusが対話インターフェースと、計画・実行システムを横断して作業できるエージェントを提供します。既存の計画基盤と併用することも、ketteQ独自のアプリケーションを利用することもできます。現在の構成ではSalesforceとの統合は任意です。(1, 2)
サプライチェーン総合評価：4.0/10
| 評価分野 | 点数 |
|---|---|
| サプライチェーン理解の深さ | 4.4/10 |
| 意思決定と最適化の実質 | 5.0/10 |
| 製品と構成の整合性 | 4.0/10 |
| 技術的透明性 | 3.2/10 |
| ベンダーの真摯さ | 3.6/10 |
ketteQのアプリケーション範囲は広く、名を挙げた顧客が業務改善を報告しています。一方、強い技術的主張の適用範囲は曖昧です。あらゆるサプライチェーン推論、意思決定ロジックの自動変更、数秒での最適解を約束しながら、その最適化の定式化や検証を公開していません。生成したPythonを業務システムに接続するため、実行境界の説明不足は特に重大です。回答が速いことも、シナリオが多数あることも、経済的に信頼できる意思決定を証明しません。(2, 3, 10)
最も信頼できる証拠は、より限定的で有用です。Partner in Pet Foodでの生産計画、quipでの需要の区別、Alliance Consumer Groupでの迅速な納期回答です。これらは実際に動くソフトウェアを示しています。同時に、導入済みの計画アプリケーションと、万能の自律型サプライチェーンシステムとの距離も示しています。(10, 11, 12)
ketteQとLokadの比較
ketteQは、Salesforce上の営業・業務フローを含む既存の企業環境に計画機能を追加します。アプリケーションは従来からある計画対象や業務フローをまとめ、Quintusはそれらの照会・操作方法を拡張します。Lokadの在庫最適化サービスは、繰り返す意思決定と、不確実性の下で生じる金銭的結果を中心に作業を組み立てます。
サービス目標、設備稼働率、運転資金、商業上の約束が衝突すると、この違いが重要になります。計画エンジンには、どれを優先するかを決める経済的な規則が必要です。そのトレードオフについて会話しても規則にはなりません。候補計画を増やしても、どれが最大の価値を生むかは証明できません。ketteQは、競合する行動を順位付けする実装済みの目的関数よりも、シナリオ探索やパラメータ調整についてはるかに多くを公開しています。(5, 8, 9)
Lokadのサプライチェーンサイエンティストは、意思決定ロジックを構築、運用、保守します。一見妥当な推奨が高くついたときに、経済的な評価を修正することも仕事です。例えば緊急輸送する部品は稼働を守る一方、より価値の高い複数の修理に必要な予算を消費するかもしれません。計算はそれらの結果を比較しなければなりません。Introduction to Supply Chainは、この運用モデルの背景にある考え方を説明しています。その成果は、すべての保守・運用作業を差し引いた実現収益で決まります。
PolymatiQが実際に示していること
シナリオには確率と経済的意味が必要
ketteQは需要変動とリードタイムの不確実性を明示的に認めています。2026年2月の計画エンジンの説明では、サービス目標、資材、生産能力、欠品ペナルティ、財務目標とともにそれらを評価するとしています。したがって、固定した供給仮定に基づく一点需要予測を超えようとはしています。(8, 9)
不明なのは、これらの量をどう整合した共同モデルにするかです。公開説明は、シナリオ確率の推定、需要と供給の依存関係の表現、裾にある事象が選択行動に与える影響を明らかにしていません。もっともらしい未来の集合は、まだ較正された確率分布ではありません。千通りの変形を実行しても、誤った仮定を何度も探索し、まれで高くつく事象を見落とすことがあります。
現在の製品ページは、予測範囲、在庫バッファ、発注方針の調整、予算制約下の多階層配分、制約付き生産計画を説明しています。関連性の高い機能ですが、PolymatiQの計算手法は分かりません。識別可能なソルバーの定式化、再現可能な意思決定ベンチマーク、公開技術資料のいずれも、宣伝される普遍的な最適解を裏付けていません。(4, 5, 6)
最初の問題は、ソルバーが十分速く終了するかではありません。モデルが正しい結果を評価しているかです。符号化された制約をすべて満たしていても、陳腐化在庫を積み上げ、高額なサービスを約束し、限られた能力を誤った製品に使う計画は作れます。速度は、良い意思決定規則と同じように、欠陥のある規則も増幅します。ロジックを書き換えられるという主張は、変化する定式化の検証を一層重要にします。
保守部品には実質的な深さと従来型の基礎がある
保守部品のページは、設置済み機器、故障率、返品、修理フロー、廃棄、循環修理部品のプール、部品代替の連鎖、購入・修理・再配置・回収といった選択肢を扱っています。この具体性から、ketteQは明確にサプライチェーンソフトウェアに分類できます。同時に、発注点方式、経済的発注量、設定可能な在庫対象リストの基準、サービスレベルのバッファも明記しています。(7)
この組み合わせは示唆的です。業務範囲は広い一方、自律性をうたうブランドの下には従来型の方針パラメータが残っています。発注点を自動調整しても、そのロジックが不規則な需要、修理の不確実性、共用部品、非対称な停止費用を適切に捉えるとは限りません。高度なインターフェースの下に、同じ制約の強いモデルが残ることがあります。
在庫アプリケーションにも合意による承認が残り、ユーザーが戦略を選べます。正当な役割を持つ管理機能ではありますが、日常的な選択作業がどれだけ計画担当者に残るかは不明です。全体の自律性は、介入なしに正常実行された意思決定の比率と価値で評価すべきであり、エージェント数やシナリオ数では測れません。(5)
顧客成果と経済的責任
Partner in Pet Food：有用な導入と、予測された金銭的収益
Partner in Pet FoodはKinaxisを残したままPolymatiQを追加しました。ketteQによれば、チームは既存のKinaxisの知識を用いて顧客の業務フローに統合し、最初の工場は六週間で稼働しました。初回の計画サイクルで設備稼働率が13%向上し、年間800万ドルの削減が見込まれ、その後欧州全体へ展開したと報告しています。(10)
この事例は既存アプリケーションの拡張が成功したことを裏付けます。周辺の説明が示唆するように、Kinaxisが数学的な根本限界に達していたことは証明しません。モデル化の選択、適用範囲、データ処理、導入作業の違いはいずれも生産計画を改善できます。公開事例は、こうした寄与と新ソルバーの計算を切り分けていません。
金銭的な主張も予測のままです。稼働率の上昇が価値を生むのは、需要、在庫、人件費、その他費用を考慮しても追加生産する価値がある場合です。年間推計と実現利益の突き合わせはありません。現在のQuintus FAQは別の箇所でこの予測削減額を繰り返す一方、顧客成果の説明を「予測ではなく実績」と断定して締めくくるため、この区別は重要です。(3, 10)
Alliance Consumer Group：営業につながる計画
ACGの事例では、200人を超える営業担当者がSalesforce経由で引当可能在庫に基づく納期回答を得ています。在庫回転率は約2.6から3.75へ、季節的なピークは約4.1になり、前年比で在庫が200万–500万ドル減少し、OTIFは60台または70台から90台後半に上がったとしています。営業に読み取り専用アクセスを与えたことで、計画担当者への照会も減りました。(11)
これは実際的な生産性向上の仕組みです。繰り返す質問に直接答えれば、チーム間のやり取り自体をなくせます。サービスの百分率は納品指標であり、予測精度ではありません。在庫削減は資本を解放しますが、自動的に同額の年間利益になるわけではありません。観察期間、需要変化の調整、費用計算がないため、業務変化を比較可能な純収益に変換できません。
quipとMobilityWorks：有用な具体性と不完全な費用計算
quipでは、全体の約20%を占める定期購入需要を他の売上と分けました。事例は、1700万ドルの在庫削減と、計画担当者を減らしながら150%の生産性向上を報告しています。確約済みの継続需要と不確実な新規購入を分けることは、実質的なモデル改善です。ただし、生産性の分母となる仕事量、計画担当者数、ベンダーの継続作業は示されていません。(12)
MobilityWorksの事例は、在庫の意思決定を金利上昇と需要減少に結び付けています。六か月で在庫費用が470万ドル減り、一年間で日々の補充警告が減ったと報告しています。在庫方針を変える経済的な理由が具体的です。しかし、ページは会計上の説明なしに在庫費用と節約額を使い分け、要約と成果欄ではフィルレートの改善幅も異なります。したがって、見出しの数値を精密な財務ベンチマークにはできません。(13)
これらを合わせると、実用的な計画アプリケーションと業務上の利益は裏付けられます。しかし、後から登場したQuintus機能と従来の計画導入は分離されず、導入・保守の全労働量も測定されていません。失敗した推奨の原因を誰に帰属させ、どう修正するかも分かりません。顧客名のある証言は有用ですが、これらの疑問は解消しません。
生産性、設定の保守、総保有費用
現在のホームページは、追加のユースケースにサービス契約は不要と述べています。より具体的な2026年6月のAI Studioの説明は、大きな開発工程を示します。二〜三週間で試作、四〜六週間で顧客データによる検証、その後の技術的な堅牢化を経て、本番まで約五か月です。パートナーは専門知識と実装を提供し、ketteQは開発を担い、収益を分けます。(14, 24)
どの新規用途にサービスが不要で、どれに数か月の製品開発が必要かは定義されていません。この境界によって、誰がシステムを変更できるか、変更費用はいくらか、データや業務が変わるなかで誰がロジックを保守するかが決まります。
Business Architectの求人は、その仕事量を裏付けます。要件の翻訳、統合とデータフローの設計、試験、利用定着、研修、本番稼働、導入問題の解決です。導入やその後の変更費用には、これらの責任を含めなければなりません。(16)
AI Studioは有用な自動化例を示しています。実演では29件の緊急注文中24件を一晩で処理し、残る五件を対応対象として提示しました。シナリオの処理量より、はるかに意味のある生産性の単位です。ただし実演であり、継続的な本番業務量や失敗費用の記録はありません。(14)
長期的な課題は意思決定モデルの保守です。混乱後のパラメータ変更と、モデルが費用、代替、業務制約を見落としていたと発見することは異なります。後者には、再定式化と、新しい意思決定が成果を改善することを示す試験が必要です。これがホリミゼーションの問題です。ketteQの開発工程にはこの作業を行う場がありますが、公開説明には経済的な回帰試験も、そのような修正の本番事例もありません。
ketteQが公表した人間主導AIの記事は、不完全な目的が悪い結果を生み、優先順位を継続的に見直す必要があると認めています。探索と実行の分離も推奨しています。妥当な問題意識です。しかし、制約も設定も不要な行動と、ロジックの自動的な組み替えをうたう新しい約束とは整合しません。未解決なのは運用上の取り決めです。どの意思決定が事前承認済みか、どの変更に検証が必要か、自動化の主張には誰の作業が含まれるかが不明です。(3, 15)
ソフトウェア構成要素と実行時のセキュリティ
| 証拠と対象範囲 | 記載された構成要素 | 帰結 |
|---|---|---|
| 現在の基盤説明 | リレーショナルデータベース、組み込みPython、JSON/Java | 識別できるアプリケーション構成ですが、独自の計画動作は製品インターフェースの内側に隠れています。 |
| 現在の基盤説明 | 交換可能な言語モデル用のAWS Bedrock | モデルのホスティングは一層を担います。アプリケーション権限とコード実行は別の責任です。 |
| 現在のSalesforce統合 | 任意の管理パッケージによるアクセスとシングルサインオン | 既存のSalesforce業務を再利用できますが、統合境界の運用責任は必要です。 |
| Business Architectの求人 | PostgreSQLを含むSQL、JSON、XML、Pythonの知識 | 採用情報はデータと統合の作業を裏付けますが、すべての本番データベースを特定しません。 |
| Quintusの発表 | 動的に生成・実行するPython | コードの封じ込めと本番権限の制限が設計上の中心要件になります。 |
既存の計画システムに意思決定層を追加すると、それ自体の保有費用が発生します。旧基盤を維持しながら、データ対応付け、権限、業務上の依存関係、計画ロジックが変わる場所が増えます。短期間で導入できても、両システムの整合を維持する継続費用は消えません。
構成上の最大の説明不足は生成コードです。Quintusの発表は、必要に応じてPythonを作り実行すると明記しています。ガバナンスの説明は、監査可能性、説明、人間による上書きを重視します。以前のエージェントページは、暗号化、アクセス制御、テナント分離も主張します。しかし、実行サンドボックス、許可するネットワーク接続先、ファイルシステムへのアクセス、依存関係の制御、リソース上限、生成プログラムに与える本番データ権限を記載した資料はありません。(2, 3, 25)
監査証跡は実行後に行動を記録しますが、データ流出や無権限の書き込みを防ぎません。自然言語でもっともらしく説明できても、実行コードが意図した権限に従った証明にはなりません。人間による介入でも、すべての外部効果を取り消せるわけではありません。企業システムを横断する動的実行ロジックを特色とする製品では、この境界の説明不足は公開技術提案の大きな弱点です。ホスティングの実績や適合認証では答えになりません。
プログラムによる運用には可能性がありますが、検査可能性は限られます。基盤はエージェント間統合と一般的な企業システム接続に言及しています。調査した資料には、購入者が計画動作全体を独立して検査・試験できる公開SDK、詳細な実行API、実行可能な例がありません。(1)
過去の約束と実装の継続
| 時期 | 公開された進展 | 記録が示すこと |
|---|---|---|
| 2021–2022 | AIによる需要・補充、Salesforce/AWS基盤 | 初期のAIという表現は計画と可視性の主張に伴っていましたが、自律推論の仕組みは公開されていません。2022年の経営陣発表はクラウド基盤と既存導入を示しています。 |
| 2023 | ChatGPTへの期待 | 企業記事は、一部をChatGPT自身による将来のサプライチェーン用途の説明に依存していました。推測であり、提供済み製品の証拠ではありません。 |
| 2024 | TokyoリリースとPolymatiQ | シナリオの自動試験、パラメータ調整、経済指標、対話インターフェースが明確な製品機能になりました。 |
| 2025 | Dubaiリリースと追加資金調達 | 二段階の生産計画、配分戦略、性能報告が加わりました。2000万ドルのシリーズBは、実装、顧客支援、パートナー能力にも充てられました。 |
| 2026年2月〜6月 | デジタルエージェント、人間主導の設計、AI Studio | 一般提供が発表される一方、技術・導入記事は安全策、検証、本番向けの堅牢化を説明していました。 |
| 2026年8月以降 | QuintusとFree-Range AI | より広範な自律推論と生成コードを主張し、その構成は2019年からこの動作を見越していたとも述べました。 |
出典：2, 14, 15, 17, 18, 19, 20, 21, 22, 23。
歴史面の弱点は、過去を遡って誇張することです。現在のFAQは、競合がまだロードマップに載せている能力について、七年間の本番運用を主張しています。日付付きのリリースは、機能が時期ごとに別々に追加されたことを記録しています。基盤の誕生時期から、最新機能の成熟度は証明できません。(3, 19, 20)
同じ誇張は約束の範囲にも及びます。PolymatiQの技術手法は公開されないまま、説明は計画支援から、あらゆる意思決定をリアルタイムで行える唯一の構成へと拡大しています。自社製品を中心に定義した商標付きの分類は、技術的なベンチマークではありません。何が、どの制約の下で、どの程度の失敗率で機能するかを証拠で示す必要があります。
経済的責任の定義も弱いままです。2025年の資金調達発表は、対象集団、受入基準、経済的な閾値を定義せずに100%の導入成功率を主張しています。AI Studioは、AI施策が失敗する原因はほとんどモデル品質ではないとして、基礎条件に注目します。データや統合の問題は実在しますが、モデルの適切さを事前に除外することはできません。そうしなければ、技術的には成功と宣言しながら、経済的な失望をいつまでも導入条件のせいにできます。(14, 22)
サプライチェーン評価
各分野は、0–10で評価した五基準の平均です。総合点は全25基準の平均です。
サプライチェーン理解の深さ
| 基準 | 点数 |
|---|---|
| 経済的な問題設定 | 5/10 |
| 具体的な意思決定への到達 | 6/10 |
| サプライチェーンに対する概念の明確さ | 5/10 |
| 旧来の中核的な教義からの独立 | 3/10 |
| 見せかけのKPIへの抵抗力 | 3/10 |
平均：4.4/10。
経済的な問題設定 — 5/10。 顧客事例は資本、無駄、運用費用の問題を示しています。競合する意思決定を順位付けする共通の経済目的は示していません。(10, 13)
具体的な意思決定への到達 — 6/10。 納期回答、生産計画、補充推奨は業務上の意思決定に達しています。測定成果から分かる承認・実行境界は一部にとどまります。(10, 11)
サプライチェーンに対する概念の明確さ — 5/10。 修理フローや生産の依存関係は、分野知識を示しています。万能の推論という約束は、その基礎となるアプリケーション説明より不明確です。(6, 7)
旧来の中核的な教義からの独立 — 3/10。 従来の在庫方針、バッファ、合意形成が引き続き中心にあります。自動調整しても、その基礎となる単純化を克服したことにはなりません。(5, 7)
見せかけのKPIへの抵抗力 — 3/10。 業務指標には具体的な顧客背景がありますが、予測削減額と未定義の成功率が経済的な突き合わせなしに宣伝されています。(10, 22)
意思決定と最適化の実質
| 基準 | 点数 |
|---|---|
| 確率モデルの深さ | 4/10 |
| 最適化または機械学習の独自性と実質 | 4/10 |
| 現実の制約への対応 | 7/10 |
| 意思決定の自動化と労働生産性 | 6/10 |
| 現実の業務の複雑さへの適応力 | 4/10 |
平均：5.0/10。
確率モデルの深さ — 4/10。 需要と供給の不確実性を明示的に認めています。シナリオの重み付け、依存関係、較正は未説明です。(8, 9)
最適化または機械学習の独自性と実質 — 4/10。 顧客での利用は有用なエンジンの存在を裏付けます。独自のアルゴリズムと最適性の主張を成立させる条件にはアクセスできません。(1, 10)
現実の制約への対応 — 7/10。 製品は重要な生産・保守部品制約を扱います。公開資料から得られる信頼は、共同の経済的処理よりも、表現する業務範囲の広さにあります。(6, 7, 20)
意思決定の自動化と労働生産性 — 6/10。 直接の納期回答と、計画チーム縮小の報告は、有用な労働削減を示します。より広い自律性の主張には、総仕事量の継続測定が欠けています。(11, 12)
現実の業務の複雑さへの適応力 — 4/10。 高くついた推奨がモデル修正とその後のより良い意思決定につながるかが重要です。このフィードバックの循環は裏付けられていません。(14, 15)
製品と構成の整合性
| 基準 | 点数 |
|---|---|
| 構成の一貫性 | 5/10 |
| システム境界の明確さ | 5/10 |
| セキュリティへの真摯さ | 2/10 |
| ソフトウェアの簡素さと総保有費用 | 4/10 |
| プログラム・エージェント支援による運用への適合性 | 4/10 |
平均：4.0/10。
構成の一貫性 — 5/10。 共通のアプリケーション群と計画エンジンは、認識できる構造を提供します。別の計画システムに重ねて導入すると、大きな統合責任が生じます。(1, 10)
システム境界の明確さ — 5/10。 既存システムとの共存は商業的に明示されています。ロジック、データ、外部への約束を変更する権限の説明は、それほど精密ではありません。(2, 15)
セキュリティへの真摯さ — 2/10。 動的生成コードは製品の中核機能ですが、調べた技術資料には封じ込め境界が記載されていません。ガバナンス上の保証はその仕組みを代替しません。(2, 25)
ソフトウェアの簡素さと総保有費用 — 4/10。 個別調整、二重システムの運用、継続的な実装作業は相当の費用になります。公開された構成は、組み合わせたアプリケーションの資源・保守要件を数量化していません。(1, 16)
プログラム・エージェント支援による運用への適合性 — 4/10。 自動化は明確な製品方針です。非公開の実行インターフェースは、動作の独立検査と管理された保守を制限します。(1, 2)
技術的透明性
| 基準 | 点数 |
|---|---|
| 公開技術文書 | 3/10 |
| ベンダーの仲介なしでの検査可能性 | 2/10 |
| 移植性とベンダー依存の可視性 | 3/10 |
| 導入手法の透明性 | 5/10 |
| 技術的主張を支える証拠の密度 | 3/10 |
平均：3.2/10。
公開技術文書 — 3/10。 機能説明は意図した用途を説明します。しかし、ソルバーの数学、実行時制御、独立利用できる実行仕様には達していません。(1, 8)
ベンダーの仲介なしでの検査可能性 — 2/10。 エンジンの実動作を理解するには、ベンダーを介した導入か実演が必要です。製品説明は再現可能な実験を提供していません。(2, 3)
移植性とベンダー依存の可視性 — 3/10。 一般的な言語と接続は統合を容易にします。しかし、意思決定ロジックの書き出し、モデル動作の移転、代替実行環境は証明しません。(1, 16)
導入手法の透明性 — 5/10。 購入者は相当の実装作業があることを確認できますが、将来のどの変更がソフトウェア価格に含まれ、どれが別プロジェクトを要するかは判断できません。(14, 16, 24)
技術的主張を支える証拠の密度 — 3/10。 名前付きの業務事例は有用です。万能の推論と最適性の主張には、はるかに強い技術的な記録が必要です。(2, 10)
ベンダーの真摯さ
| 基準 | 点数 |
|---|---|
| 公開発信の技術的真摯さ | 2/10 |
| 技術ロードマップの整合性 | 4/10 |
| 概念の明確さ | 4/10 |
| 経済的責任 | 3/10 |
| エージェント型ソフトウェア時代の競争力 | 5/10 |
平均：3.6/10。
公開発信の技術的真摯さ — 2/10。 無制限の能力と断定的な優位性の主張は、より具体的な製品証拠を損ないます。公開説明は、現実のソフトウェアが必ず持つ限界を定義していません。(2, 3)
技術ロードマップの整合性 — 4/10。 信頼できる成熟度の主張には、売っている能力の導入履歴が必要です。公開年表が裏付けるのは、現在の位置付けよりも狭い主張です。(3, 19, 20)
概念の明確さ — 4/10。 一部の文書は、目的と管理された実行の重要性を認めています。制約のないエージェントという説明は、これらの要件と約束された行動の自由を整合させていません。(2, 15)
経済的責任 — 3/10。 顧客事例は利益を報告しますが、費用の突き合わせ、失敗した推奨、導入成功の受入条件は未定義です。(10, 12, 22)
エージェント型ソフトウェア時代の競争力 — 5/10。 業務統合と分野固有の計画機能は有用な資産です。エージェントが進歩すると対話アクセスや生成コードの独自性は薄れます。追加基盤を正当化するには、信頼できる経済的な意思決定が必要です。(7, 11)
出典
出典の閲覧日は2026年11月4日です。以下の顧客成果は企業が公開した報告であり、元の測定範囲を保っています。
プラットフォーム構成。公開日不明、2026年11月4日閲覧。
Quintusの一般提供。2026年8月12日公開、2026年11月4日閲覧。
Quintus FAQ。公開日不明、2026年11月4日閲覧。
需要計画。公開日不明、2026年11月4日閲覧。
在庫計画。公開日不明、2026年11月4日閲覧。
供給計画。公開日不明、2026年11月4日閲覧。
保守部品計画。公開日不明、2026年11月4日閲覧。
PolymatiQと確率モデルのFAQ。公開日不明、2026年11月4日閲覧。
インテリジェントデジタルエージェントと計画の頭打ち。2026年2月25日公開、2026年11月4日閲覧。
Partner in Pet Foodの事例。公開日不明、2026年11月4日閲覧。
[11] Alliance Consumer Groupの事例
Alliance Consumer Groupの事例。公開日不明、2026年11月4日閲覧。
Quipの事例。公開日不明、2026年11月4日閲覧。
MobilityWorksの事例。公開日不明、2026年11月4日閲覧。
ketteQ AI Studioの内部。2026年6月16日公開、2026年11月4日閲覧。
人間主導AIの四原則。2026年5月19日公開、2026年11月4日閲覧。
Business Architectの求人。公開日不明、2026年11月4日閲覧。
2022年の自動車業界動向。2021年12月6日公開、2026年11月4日閲覧。
ChatGPTはサプライチェーンを変えるか。2023年3月28日公開、2026年11月4日閲覧。
Tokyoリリースの発表。2024年11月12日公開、2026年11月4日閲覧。
Dubaiリリースと半自律型計画。2025年5月6日公開、2026年11月4日閲覧。
インテリジェントデジタルエージェントの一般提供。2026年2月25日公開、2026年11月4日閲覧。
シリーズB資金調達の発表。2025年8月5日公開、2026年11月4日閲覧。
Mike Landryの就任。2022年8月15日公開（現在のページ）、2026年11月4日閲覧。
現在のホームページ。公開日不明、2026年11月4日閲覧。
デジタルエージェントとガバナンス。公開日不明、2026年11月4日閲覧。