市場調査に戻る
OPTANOはネットワーク設計、生産、輸送、在庫、人員計画の最適化アプリケーションを開発する。基盤はデータ連携、シナリオ管理、画面、顧客固有の数理モデルを組み合わせる。OPTANO Modelingは別の.NETプログラミングインターフェースで、開発者がモデルを構築し最適化ソルバーを呼び出す。会社は2022年からKearney傘下にある。(1, 2, 18, 24)
サプライチェーン総合評価：5.3/10
| 評価軸 | 得点 |
|---|---|
| サプライチェーンへの理解の深さ | 5.2/10 |
| 意思決定と最適化の実質 | 5.0/10 |
| 製品とアーキテクチャの整合性 | 5.0/10 |
| 技術的透明性 | 6.0/10 |
| ベンダーの真摯さ | 5.2/10 |
OPTANOは検査可能なモデリングツールと相当なアプリ開発を提供する。主な弱点は数理計画への依存であり、計算可能性と経済的妥当性を業務ごとに立証しなければならない。ソルバーは、実際の利益を決める不確実性、非線形な帰結、選択可能な行動を見落としたまま、符号化した目的を最適化できる。速度の包括的な宣伝は、自社が公表した産業事例がどれほど難しいかを覆い隠す。(4, 10, 25)
慎重な出版物は、モデル修正、現実的比較、追加便益が小さいと結論した実現性調査まで含め、こうした限界を認める。この実績は幅広いAI宣伝より有用だ。未解決の商業的問題は、モデリング、シナリオ審査、連携、保守の全作業を数えたうえで、経済的に健全な判断を持続できるかにある。(8, 9, 15)
OPTANOとLokadの比較
OPTANOは顧客の計画問題の数学的表現を中心にアプリを作る。計画担当者はシナリオを比較し、得られた計画で業務を調整する。Lokadの在庫最適化サービスは、反復する判断、その金銭的帰結、将来の需要と供給の不確実性を中心に仕事を組み立てる。
違いは目標値が経済価値と衝突するときに重要になる。最低在庫の維持は高額な生産を強い、サービス最大化はより価値の高い需要に必要な在庫を使いかねない。OPTANOは費用と競合する目的を表現できるが、選んだ階層や重みが、許されるトレードオフを決める。数理的最適解は、それらの優先順位が事業の経済性を反映する証明にはならない。
Lokadのサプライチェーンサイエンティストは、費用のかかる提案を出す定式化の修正も含め、判断ロジックの構築と保守を担う。Introduction to Supply Chainはその考え方を展開する。比較には各手法を運営する人員も含まれる。技術的に高度なモデルでも、計画担当者やコンサルタントが判断を絶えず点検・修復しなければならないなら、多くの反復作業を課し得る。
最適化の中核が立証するもの
公開モデリングツールと限定された数学的能力
OPTANO Modelingは.NET API経由で数理計画を表し、公開文書、例、MITライセンスを備える。複数ソルバーに対して線形、混合整数、二次最適化を扱う。NuGetパッケージは2026年9月に3.31.0.685となり、リリース記録は複数目的でのCPLEXギャップ報告の誤りを修正する。保守され、技術的な中身を確認できるソフトウェアである。(2, 3, 4)
限界はモデルの種類にある。サプライチェーンには離散選択、非線形費用、代替、不確かな歩留まりと入荷、変動する機会がある。線形計画法は強い単純化を強いる。混合整数なら表現できる選択は増えるが、細部の追加で探索が膨らみ、有用な解を得にくくなる。容易な局所問題へ業務を分割すると、経済価値を生む依存関係そのものを捨てかねない。
将来シナリオを追加しても解決しない。既に計算が厳しい定式化を拡大し、ソルバーが自ら供給しない確率的な未来像も要する。重要なのは、実用規模で大切な経済的選択を保てるかだ。小さな最適性ギャップは、符号化した問題だけについてのものにすぎない。
自社研究が無条件の高速化宣伝と矛盾する
現行のソルバーページは、数百万の判断変数と数千の仮想シナリオを数秒で処理すると約束する。その負荷、定式化、ハードウェア、近似は特定していない。(25)
2024年のアルゴリズム調整論文は、ずっと厳しい産業の現実を記す。ネットワーク計画の実例は変数470,000超、うち整数50,000超で、数日かけても最適まで解くのは現実的でなかった。Gurobi 8.1の標準設定では、実例と乱数シードを組み合わせた三十回のうち二回が、最初の実行可能解までほぼ八時間かかった。調整後の報告最大値は四分、ひとつを除外する検証では九分だった。研究は顧客の三実例と、一部の判断を先に固定した小規模な訓練用コピーを使った。(10)
これは外部ソルバーをつなぐだけを超えた本物の開発だ。同時に、変数数だけでは規模の指標として弱い理由を示す。ある定式化で有効な設定でも、ネットワーク、不確実性モデル、意思決定空間の変更後に安定した性能が出るとは限らない。実行可能解を速く見つけても経済的な判断の改善は証明できず、定式化には高価な失敗要因が抜けているかもしれない。
より広いOPTANO Algorithm Tunerはコードと手法を公開する。遺伝的手法などの探索で、対象アルゴリズムのパラメータ設定を探す。これは選択したアルゴリズムの実行を改善するが、業務問題を正しく定式化したかは判断しない。(11)
階層的な目的は誤った優先順位を守る場合がある
公開Modeling文書は階層最適化を正確に説明する。ある目的を最適化し、その後の低優先目的が結果を悪化させないよう制約を加える。同順位の目的は重み付きで合成できる。(5)
Daimler Truckの公表アプリでは、需要充足、ネットワークの頑健性と最低在庫、その後に費用最小化という順序を設ける。計画を在庫・予測情報、SAP連携、データウェアハウス、工場での実行追跡に結び付ける。(6)
この階層には経済的な帰結がある。少し譲れば多額の費用を減らせても、高優先の目標は守られ続ける場合がある。本当の義務なら厳格な制約に置くべきだが、経営上の希望なら費用と価値を比較すべきだ。事例はその区別や、経済的に悪い計画が出た際の優先順位修正を明らかにしていない。
不確実性と在庫
OPTANOの現在の在庫説明は、需要とリードタイム双方に分布モデルを明示的に使う。同時に安全在庫、発注周期、最低在庫ルール、倉庫戦略比較も維持する。供給不確実性を実質的に認識しているが、較正、不確実性間の依存、在庫判断の共同経済方針は開示されていない。(13)
2026年10月の能力計画インタビューは、一般的な仮想シナリオ宣伝より慎重に判断を論じる。今日の確約を複数の未来で共通にし、後からも実行可能な変更だけを許し、数学的境界と既存計画比の節約を区別する。当時使えた情報に基づく比較や、提案から欠けたルールや古い仮定が判明した際のモデル修正も求める。(9)
いずれも必要な規律だが、大規模な確率的サプライチェーン全体で動く実装の証明ではない。公開説明には、較正した需要・供給の共同予測、判断単位の検証、拡張モデルの保守費がない。シナリオの整合性は一種類のモデル誤りを防ぐが、不十分な未来集合を完全にはしない。
強化学習研究が未解決の設計問題を示す
OPTANO社員が共著した2026年10月の研究章は、ML4SafetyStockを報告する。過去のネットワークデータから需要・リードタイム分布を導き、受注残、費用、サービス要件のあるPython/NumPyシミュレーターを作る。個々の倉庫のエージェントが報酬関数を共有する。報告された多段階比較では、分解ヒューリスティクスより在庫が多くなる傾向がある一方、難しい構成でも運営を保った。著者は結果を明確にシミュレーションとし、需要、リードタイム、ネットワーク構造の仮定を残す。(14)
この研究は古典手法の実際の限界を扱う。しかし本番の確率的サプライチェーンサービスではない。有用な方針を学習するには、シミュレーターが行動の帰結を十分正確に予測し、報酬がそれを正しく評価しなければならない。在庫を増やして崩壊を避けるネットワークでも、資本消費や陳腐化で価値を損なう可能性がある。研究は観測と報酬のさらなる改善を継続課題として残し、本番での金銭的比較は示していない。
顧客の証拠と経済的な責任
Holcim：導入済みネットワークモデルと不完全な収益計算
Holcimの事例は、セメントのネットワーク生産・配送を扱い、販売価格、生産・物流費、能力、内製・調達の代替を含む。営業、生産、物流、財務の参加を記す。ソフトウェアは戦略・戦術シナリオを支え、最適化を五分以内に終える要件があった。(7)
事例は部門横断のモデル化と業務導入を示す。利得は費用・在庫削減、需給整合、より良い選択という定性的なものだ。正規化した財務基準、保守費、継続的な計画作業量はない。時間の上限はそのアプリの要件であり、任意に拡大したモデル全般の結果ではない。
Lavazza：珍しく有用な、投資効果が乏しい事例
Lavazza Professionalは三年分の過去注文で技術者の巡回計画調査を依頼した。既存の担当区域、経験豊かなスタッフ、チーム調整が既に良好で、最適な割当てによる追加改善はわずかだった。公表された対応は大規模導入より知識移転と組織を重視した。顧客はモデルを過剰に作り込むリスクも指摘した。(8)
この結果を公表することは、OPTANOの経済的主張をより信頼できるものにする。技術的可能性と投資価値を分ける姿勢がある。残る限界は比較基準の範囲だ。最適に近いという結論はモデル化した巡回業務に限る。停止時間や補修部品の入手性を含むサービス全体の経済的最適性は示せない。
反復する生産順序は柔軟性を低い調整費用と交換する
Rhythm Wheelは通常八〜二十週にわたる製品の反復順序を固定し、現在の在庫と予測で数量を調整する。計画担当者は追加製品を挿入できる。三か国五ラインの匿名試験は、在庫10–15%減、ライン当たり一〜二シフト減、運営費5–10%減を報告する。(20)
順序の安定は切替えと調整の費用を下げ得る。同時に、需要が分かる前に可能な行動を制限する。経済的に優れるかは、その制限の費用が得られる安定性より小さいかによる。試験は観測期間、会計基準、計画・開発の全労力を開示しない。その率だけでは、低頻度品、発売、需要の大変動に同じ規則が適切かは示せない。
生産性、モデル保守、総保有コスト
OPTANOのアプリ業務は、シナリオ作成、比較、協働が中心だ。公開プラットフォームはウェブ画面、ダッシュボード、Excel交換、Power BI連携を含む。データ操作を減らせても、その存在だけでは日常判断が担当者の審査なしで正しく実行されるとは証明できない。(1)
重要なのは計画作業を速めることと、計画作業そのものを減らすことの違いだ。大量の代替案を素早く出しても、比較、優先度調整、変更説明をするチームは残り得る。事例には、顧客の計画者、OPTANO専門家、コンサルタントを含む総労働時間当たりの判断数がない。Kearney傘下という事情からも、この合計運営費は特に重要だ。
個別開発のインタビューは分業を示す。コンサルタントが目的と制約を特定し、数理の専門家がモデルを作り、開発者がアプリにする。再利用可能な基盤機能で反復開発を減らしつつ、判断モデルは顧客固有のままにする。(15)
この体制は難しい要件に対応できるが、導入後も責務は続く。供給者追加、品種構成変更、サービス確約の見直しで、データの意味、制約、目的値の変更が必要になり得る。問題構造が変わればソルバー調整も保守作業となる。モデルとアプリのコードは業務とも互いとも整合する必要がある。
OPTANO Modelingは、バージョン管理、単体・統合テストなど通常の開発実務を支援する。変更を検査しやすくする仕組みだが、定式化に抜けた費用を発見したとは証明しない。(22)
10月のインタビューの修正工程はホリミゼーションに直接関わる。担当者の異議が、欠落ルール、古い仮定、見逃した機会を明らかにし得る。なお不足するのは、経済的失敗を再定式化、試験、その後の判断改善まで追う本番事例だ。それなしでは継続改善の費用と有効性は不確かである。(9)
ソフトウェア構成とセキュリティ
| 層と証拠 | 文書化された要素 | 保有上の意味 |
|---|---|---|
| モデリングパッケージ、2026年9月 | .NET Standard 2.0、FParsec、FSharp.Core、MathNet依存 | 本番アプリ全体と異なる、比較的読み解きやすいモデル化ライブラリ。 |
| ソルバー連携 | Gurobi、CPLEXなど商用・オープンソースの選択肢 | ライセンス、互換性、性能が運用上の依存として残る。 |
| 現行アプリ基盤 | ウェブ画面、設定可能な取込み、Excel交換、Power BI、OIDC | 共通機能は重複作業を減らすが、連携と権限管理は必要。 |
| Algorithm Tuner | .NET、Akka、ログ、数学ライブラリ、ソルバーアダプター | 独自の実行環境と依存物を持つ別の調整ツール。 |
| 2021年4月IT Assistant求人 | Windowsサーバー・クライアント管理、仮想化、クラウド基盤 | 過去の内部基盤作業の証拠で、現在の顧客実装の構成は特定しない。 |
| ML4SafetyStock研究 | Python/NumPyシミュレーター | 商用運用への移行が未指定の実験環境。 |
ソルバー選択は案件ごとに異なる。全費用は、納品アプリのデータウェアハウス、接続、モデル実行、帳票、支援契約に依存する。公開資料はその規模や代表的な本番業務で必要な資源を定量化していない。
プラットフォームは役割別アクセスと、既存IDを再利用するOpenID Connectを文書化する。認証ページはISO、TISAX、SOC 2を強調するが、それで計算プロセスの隔離、連携資格情報が読めるデータ、変更モデルを配備できる人は分からない。(1, 17)
個別最適化アプリで重要なのは、通常の計画権限と、実行ロジック・本番データを変える権限の境界だ。公開設計は、封じ込めを評価できるほど詳しくその境界を記述しない。
移植性はアプリ層よりモデル化層で高い。MITライセンスのAPIと明示的なソルバー連携は技術依存を見えるものにする。本番アプリを移すには、データ対応、顧客ロジック、連携、運用知識がなお必要だ。業者変更時のこれらの移転方法は公開提案にない。(2, 15)
過去の約束とその実現
| 時期 | 公表された進展 | 評価 |
|---|---|---|
| 2009–2022年 | 最適化事業、その後Kearney買収 | 2022年発表は三十件超の共同案件を記すが、広範なAI・万能最適化も主張する。 |
| 2021年 | Algorithm Tuner 2.1.0 | 公開手法とコードが、過去のアルゴリズム重視に実質を与える。 |
| 2024年 | 調整研究を公表 | 外部ソルバーの挙動を改善する具体的貢献と、厳しい規模限界を示す。 |
| 2024年の技術宣伝 | 継続学習AIと高速最適化 | 宣伝はアプリ単位の学習・性能の公開証拠より広い。 |
| 2025年 | デジタルツインとRhythm Wheel解説 | 抽象化と実際の計画ルールを論じるが、モデルの予測妥当性は未測定。 |
| 2026年 | Modeling保守、在庫研究、慎重な能力計画の議論 | 特定できる進歩だが、シミュレーション結果と概念的指針には本番検証が残る。 |
出典：3, 9, 10, 12, 14, 18, 19, 20, 21。
2022年の買収発表は2009年以来のAIソリューションを宣伝し、どんな問題にも最適解があると主張した。公開技術が支持するのは、もっと狭い数理モデル化とアルゴリズム設定の歴史だ。初期AIの位置付けは能力範囲を誇張しており、今日の汎用推論や自律実行の証拠と読んではならない。(18)
現在のAI資料は、定義したベンチマークや更新工程の開示なしに、継続学習と予測改善を加える。対して在庫研究は仮定と残作業を明示する。最も強い技術発信のほうが商業概要より抑制的である。(19, 14)
デジタルツインの説明も、モデルが事業の選択した部分を表し、複雑さを抑えるため抽象化を選ぶことを認める。有用な出発点だ。しかし遅延や対策が費用・サービスをどう変えるか予測するなら、その条件付き予測を検証しなければならない。記事にはその検証がない。整合した仮想ネットワークでも、経済的帰結を系統的に誤予測し得る。(21)
開発実績が支える主張は、万能の速さ、継続学習、包括的最適化より狭い。商業上の約束は、技術出版物が立証した負荷と成果に合わせるべきだ。
サプライチェーン評価
各評価軸は0–10の五項目の平均である。総合点は全25項目を平均し、5.28を5.3に丸める。
サプライチェーンへの理解の深さ
| 項目 | 得点 |
|---|---|
| 経済的な捉え方 | 6/10 |
| 最終成果としての意思決定 | 6/10 |
| サプライチェーンについての概念の明確さ | 6/10 |
| 時代遅れの中心的教義からの独立 | 3/10 |
| KPIの見せかけへの耐性 | 5/10 |
平均：5.2/10。
**経済的な捉え方 — 6/10。**モデルは意味のある費用と商業的選択を含む。階層的目標は、優先の根拠を示さず経済的トレードオフを覆せる。(5, 6, 7)
**最終成果としての意思決定 — 6/10。**アプリは業務・戦略計画を生成し、実行も追跡できる。公開提案は無人の判断生成より、計画担当者を支える選択を明確に説明する。(6, 24)
**サプライチェーンについての概念の明確さ — 6/10。**公表例は共有資源、時期、部門横断の帰結を扱う。不確実性の共同経済処理は、既知の制約の調整ほど確立されていない。(7, 9)
**時代遅れの中心的教義からの独立 — 3/10。**安全在庫ルール、サービス目標、固定計画パターンが中核に残る。パラメータの最適化だけでは、選んだ方針が最も価値のある行動を捉えるとは示せない。(13, 20)
**KPIの見せかけへの耐性 — 5/10。**一部出版物は、価値ある投資と魅力的な数理結果を区別する。匿名の改善率と広範な性能主張の条件は、なお不十分だ。(8, 20, 25)
意思決定と最適化の実質
| 項目 | 得点 |
|---|---|
| 確率モデルの深さ | 4/10 |
| 最適化・MLの独自の実質 | 5/10 |
| 現実の制約への対応 | 7/10 |
| 意思決定の自動化と労働生産性 | 4/10 |
| 現実の業務の複雑さへの耐久性 | 5/10 |
平均：5.0/10。
**確率モデルの深さ — 4/10。**研究は需要と供給の不確実性を明示する。商業規模で、較正済みの共同モデルを本番利用し、判断を経済的に検証したという公開証拠はない。(13, 14)
**最適化・MLの独自の実質 — 5/10。**アルゴリズム設定には識別できる技術的貢献がある。選んだ定式化内の計算を改善するが、そのサプライチェーン上の限界は解決しない。(10, 11)
**現実の制約への対応 — 7/10。**実名事例は重要な生産、在庫、ネットワーク制約を表す。計算の難しさが、共同で保持・探索できる詳細を制限する。(6, 7, 10)
**意思決定の自動化と労働生産性 — 4/10。**データ処理と計算は自動化できる。シナリオ確認と個別モデル支援は多く残り、持続的生産性を示す総作業量の測定はない。(1, 15)
**現実の業務の複雑さへの耐久性 — 5/10。**OPTANOは不完全モデルの修正を明確に論じる。経済的失敗と、その後の再定式化の成功を記録すれば、今の方法論説明より強い証拠になる。(9, 22)
製品とアーキテクチャの整合性
| 項目 | 得点 |
|---|---|
| アーキテクチャの一貫性 | 6/10 |
| システム境界の明確さ | 6/10 |
| セキュリティへの真摯さ | 4/10 |
| ソフトウェアの簡素さと保有費用 | 4/10 |
| プログラム運用・エージェント支援への適合 | 5/10 |
平均：5.0/10。
**アーキテクチャの一貫性 — 6/10。**モデル化層、ソルバー連携、再利用可能なアプリ機能が理解可能な構造を成す。各顧客の統合アプリの整合性は継続的な開発に依存する。(1, 2, 15)
**システム境界の明確さ — 6/10。**モデル構築者、ソルバー、計画アプリの役割は区別できる。本番権限と失敗処理の説明は不十分だ。(6, 9)
**セキュリティへの真摯さ — 4/10。**ID連携とアクセス役割は文書化された仕組みである。モデル配備、計算プロセスの隔離、連携権限は十分に説明されない。(1, 17)
**ソフトウェアの簡素さと保有費用 — 4/10。**モデル化ライブラリは検査できるが、アプリ全体と保守は定量化されない。顧客ロジックとソルバー調整は専門家の継続労力を要し得る。(3, 10, 15)
**プログラム運用・エージェント支援への適合 — 5/10。**開発者向け接続とテスト可能なモデルは自動開発を支える。顧客向け判断プロセスの無人運用を証明するものではない。(2, 22)
技術的透明性
| 項目 | 得点 |
|---|---|
| 公開技術文書 | 7/10 |
| ベンダーを介さない検査可能性 | 6/10 |
| 移植性とロックインの可視性 | 6/10 |
| 導入方法の透明性 | 6/10 |
| 技術的主張を裏付ける証拠の密度 | 5/10 |
平均：6.0/10。
**公開技術文書 — 7/10。**API、例、リリース記録、研究が実際の仕組みを開示する。公開技術資料は、納品するサプライチェーンアプリよりツールについて充実している。(2, 5, 23)
**ベンダーを介さない検査可能性 — 6/10。**開発者はモデル化インターフェースと調整コードを直接調べられる。顧客環境の挙動を再現するには非公開モデル、データ、アプリ設定がなお必要だ。(2, 10, 11)
**移植性とロックインの可視性 — 6/10。**ライセンスとソルバー境界は明確だ。周囲のアプリと業務知識の移転は、モデル化層の再利用ほど透明ではない。(2, 4, 15)
**導入方法の透明性 — 6/10。**開発責任の分担は見える。公表事例は継続人員、変更労力、商業的な受入条件を大部分明示していない。(6, 15)
**技術的主張を裏付ける証拠の密度 — 5/10。**研究と実名アプリは実際の技術活動を支える。広いソルバー・AIの主張は、公表実演の範囲を大きく超える。(10, 14, 19, 25)
ベンダーの真摯さ
| 項目 | 得点 |
|---|---|
| 公的発信の技術的な真摯さ | 4/10 |
| 技術ロードマップの一貫性 | 6/10 |
| 概念の明確さ | 5/10 |
| 経済的な説明責任 | 6/10 |
| エージェント型ソフトウェア時代の競争力 | 5/10 |
平均：5.2/10。
**公的発信の技術的な真摯さ — 4/10。**万能性能の言葉は技術記録の限界と矛盾する。買い手に必要なのは、包括的宣伝ではなく研究が示す範囲を区切った説明だ。(10, 18, 25)
**技術ロードマップの一貫性 — 6/10。**ソフトウェア保守と公開手法は継続性を示す。新研究と納品済み機能は区別可能だが、AIの営業説明は境界を曖昧にする。(3, 12, 14, 19)
**概念の明確さ — 5/10。**慎重な出版物は計算結果と事業成果を区別する。広い提案は、計算可能なモデルに経済的に重要な挙動を残す難しさを過小評価する。(9, 21, 25)
**経済的な説明責任 — 6/10。**追加利得が小さい調査結果を公表するのは、節度の意味ある証拠だ。契約責任、総費用との照合、本番で期待外れの収益となった際の是正は未指定である。(8, 15)
**エージェント型ソフトウェア時代の競争力 — 5/10。**業務モデル化と保守された連携は有用な資産だ。手軽なコード生成は一般的なアプリ構築を圧迫する。専門基盤を正当化するには、信頼できる経済性と少ない総運用労働が必要だ。(2, 15, 22)
出典
出典の参照日は2026年11月4日。
OPTANOプラットフォームの設計。公表2025-09-18（技術索引）、参照2026年11月4日。
OPTANO Modeling文書。公表日不明、参照2026年11月4日。
[3] OPTANO Modelingパッケージ3.31.0.685
OPTANO Modelingパッケージ3.31.0.685。公表2026-09-03、参照2026年11月4日。
対応ソルバーのインターフェース。公表日不明、参照2026年11月4日。
階層的・重み付き最適化。公表日不明、参照2026年11月4日。
Daimler Truckの世界的な生産計画。公表日不明、参照2026年11月4日。
Holcimのネットワーク最適化。公表日不明、参照2026年11月4日。
[8] Lavazza Professionalの実現性調査
Lavazza Professionalの実現性調査。公表日不明、参照2026年11月4日。
[9] ローリング能力計画：OPTANO・Gurobiインタビュー
ローリング能力計画：OPTANO・Gurobiインタビュー。公表2026-10-07、参照2026年11月4日。
大規模問題に向けた混合整数計画ソルバーの設定。公表2024-05-30、参照2026年11月4日。
OPTANO Algorithm Tuner文書。公表日不明、参照2026年11月4日。
Algorithm Tuner変更履歴。公表2021-11-12（記載された最新リリース）、参照2026年11月4日。
サプライチェーン、在庫、生産機能。公表日不明、参照2026年11月4日。
[14] ML4SafetyStock：生産・配送網の安全在庫の機械学習
ML4SafetyStock：生産・配送網の安全在庫の機械学習。公表2026-10-23、参照2026年11月4日。
複雑な計画に個別ソフトウェアが必要なとき。公表2026-02-04、参照2026年11月4日。
OPTANO IT Assistant求人。公表2021-04-13、参照2026年11月4日。
OPTANOの認証。公表日不明、参照2026年11月4日。
Kearneyの買収発表。公表2022-11-09、参照2026年11月4日。
OPTANOのAIと機械学習。公表2024-04-05（技術索引）、参照2026年11月4日。
Rhythm Wheel生産計画。公表2025-08-22、参照2026年11月4日。
輸送から成功へ：デジタルモデルの境界。公表2025-02-17、参照2026年11月4日。
OPTANO Modelingの開発実務。公表2026-03-12（技術索引）、参照2026年11月4日。
OPTANO Modeling変更履歴。公表2025-11-21（記載された最新リリース）、参照2026年11月4日。
サプライチェーン最適化の提案。公表日不明、参照2026年11月4日。
OPTANOのソルバー技術の主張。公表2024-04-05（技術索引）、参照2026年11月4日。