市場調査に戻る
SkyPlanner APSは、フィンランドのSkycode Oyが提供するクラウド型生産スケジューリングソフトウェアである。製造業者は、工程の作業ステーションへの割当、作業順序の決定、資材の利用可能性と勤務シフトの考慮、現場への作業待ち行列の送信に利用する。Arcturusエンジンは、工場の注文、生産モデル、優先順位から日程を再計算する。ERP連携と時間記録が、計画と実行を結び付ける。1
サプライチェーン総合評価：5.5/10
| 評価分野 | スコア |
|---|---|
| サプライチェーンへの理解の深さ | 5.6/10 |
| 意思決定と最適化の実質 | 5.0/10 |
| 製品とアーキテクチャの一貫性 | 6.0/10 |
| 技術的透明性 | 5.8/10 |
| ベンダーの真摯さ | 5.0/10 |
SkyPlannerには、相互依存する生産作業の手動配置をなくすという、説得力のある目的がある。公開マニュアルは実際のスケジューリング上の選択を説明し、実名顧客は工場計画から取り除かれた仕事を報告する。弱点は、その選択を支配する基準である。利用者は納期、リードタイム、顧客の重要性、段取り替えの選好を調整するが、文書は不確実性の下で各選択肢の経済的結果を金額評価する目的を確立していない。そのため、設定した選好をすべて守る実行可能な順序でも、財務的には劣り得る。
新しいエージェントインターフェースは、モデルの変更と検証に有用な仕組みを追加する。同時に、同じ優先順位駆動エンジンの利用範囲を広げる。重要な未解決点は、その優先順位がどれほど確実に金銭価値を表すか、供給と加工時間の不確実性が選ばれる日程をどう変えるか、工場の変化に合わせて誰がその解釈を維持するかである。
SkyPlannerとLokadの比較
SkyPlannerは工場モデルから出発し、詳細な作業順序を生成する。Lokadは経済的意思決定問題から出発する。不確実な将来と共通制約の下で、どの購買、配分、生産数量、その他の行動が最良の期待収益をもたらすかという問題である。注文遅延、追加段取り、遊休能力の金銭的結果が大きく異なる場合、この違いは重要になる。
SkyPlannerの公開スケジューリング設定は、相対的な強さで選好を表す。計画担当者は特定顧客を優遇したり、生産リードタイムを短縮したりできるが、商業的な状況をその選好へ翻訳しなければならない。Lokadの定量的サプライチェーンのアプローチは、その経済的翻訳を数値モデルに組み込み、確率的予測を意思決定計算に使う。遅延費用が変われば、その経済的影響を通じて意思決定が変わるべきであり、誰かが適切なスライダー位置を探すことに依存すべきではない。2
保守義務も異なる。SkyPlannerは設定、連携、独自開発のサービスを提供するが、運用モデルを定義し、いつ改訂するかを判断するのは顧客である。Lokadのサプライチェーンサイエンティストは、在庫最適化サービスの一部としてデータ解釈と意思決定ロジックを構築・維持する。どちらも技術開発の仕事からは逃れられない。比較すべきなのは、ホリミゼーションで説明されるように、どれだけの反復的な労力で、検証済みの意思決定改善を生み出せるかである。8
機械への手動負荷配分を置き換える製造業者にとって、SkyPlannerは具体的で比較的限定された問題を扱う。より広い経済的最適化プロジェクトでは、需要、納入、歩留まりが不確実なときに何を生産、購入、延期するかも決めなければならない。公開されたSkyPlannerの仕組みは、その広い能力を確立していない。
Arcturusが実際に決めること
優先順位が妥協点を決める
動的優先順位のマニュアルは、混同しやすい二つの目的を区別する。納期順に並べることで他の作業が遅れる場合がある一方、期限内完了件数を最大化すると、複数の注文を守るために一つを遅らせる場合がある。同じ操作パネルには、リードタイム短縮、顧客と作業の重要性、開始の可否、段取り削減のための類似作業の集約も含まれる。2
これは実質的なスケジューリングロジックである。同時に、不完全な経済モデルでもある。遅れた作業を数える方法では、誰かが補正する優先順位を加えない限り、軽微な不便と顧客の生産ライン停止を同じように扱う。段取り時間の削減は、ある状況では残業、大ロット、前倒し生産を正当化し、別の状況では価値を破壊する。相対的優先順位は、これらの結果を交換する比率を隠す。
ベンダーは、Arcturusの数学的定式化、探索手法、再現可能な性能ベンチマークを公開していない。したがって、高速計算の主張は、厳密な最適解も特定のソルバー系統も証明しない。決定的に欠けているのは、同じ業務制約の下で、選んだ日程が妥当な代替案より経済的に優れると示す比較である。
資材と能力はモデル化されるが、不確実性は計算の外に残る
資材利用可能性のオプションは、倉庫在庫と入荷予定をスケジューリングに組み込む。文書はさらに踏み込み、これで資材不足による中断を防ぐとする。しかし、到着予定日ではその保証はできない。サプライヤーは遅延、数量不足、使用不能な資材の納入を起こし得る。3
作業ステーションの効率は、相対的な加工速度を変える百分率で設定される。マニュアルは、その効率を変更する前に、すでに計画された作業を日程から外すよう求める。これは明示的な生産パラメータであり、加工時間の公開確率モデルではない。4
重要な確率的問題は同時に考える必要がある。遅れた部品、失敗した工程、緊急注文が、同じ残余能力を奪い合うことがある。出来事のたびの再計画は復旧に役立つが、事前にどの予防策を取る価値があったかは決めない。検証した文書には、需要、サプライヤーのリードタイム、歩留まり、加工時間の同時分布も、それらを合わせた結果を評価する意思決定手順もない。
制約処理にはより多くの実質がある。SkyPlannerは、工程の依存関係、代替作業ステーション、工具、シフト、資材の利用可能性、段取りに関わる属性をモデル化する。これらは、明らかに不可能な日程を防ぎ、連動する工程を調整し得る。価値は、生産モデルの正確さと、競合を解決する優先順位に依存する。1
自動化、エージェント、残る仕事
自動再計算は、現在のエージェントという表現より前からある。2025年4月のマニュアルは、再スケジューリング間隔を選べると説明する。したがって日程を繰り返し生成するために、計画担当者が繰り返しクリックする必要はない。5
現在のMCPインターフェースは、外部アシスタントによる生産データの参照・変更とArcturusの呼び出しを可能にする。表計算からのモデル作成や連携開発も支援できる。各クラウド環境には本番をコピーしたサンドボックスがあり、試行後に一部の計画設定と全社規則を本番へ戻せる。設定変更の提案から検証済み日程までの、実用的な経路が生まれる。6
対話型アクセスだけでは、スケジューリングエンジンの知的な実質はほとんど増えない。優先順位を上げるようアシスタントに頼むことは、従来の計画担当者の介入を再現する。より大きな機会は、反復する失敗を診断し、一度モデルを直して、その介入を不要にすることだ。SkyPlannerのコピー型サンドボックスはこれを支えるが、公開資料は、過去データの再実行、経済的受入基準、版管理されたリリース、ロールバックまでを含む完全な修正サイクルを示さない。
この区別は、生産性の基準も変える。担当者の質問への回答が速いことは有用だが、永続的な規則修正は将来の何千もの質問をなくせる。MCPは、この後者の可能性と、計画、連携、モデル保守に残る総労力で評価すべきである。
顧客の証拠は実際に削減された仕事を特定する
Eino Korhonen Oyは、射出成形機26台、金型約500個の工場を説明する。従来、翌日の日程準備には毎日三〜四時間かかっていた。事例では、次の金型と機械を指定する作業一覧を伴う自動負荷配分によって、およそ一人分の年間業務量が解放されたと報告する。一回の成形で異なる品目を作るファミリーモールドも、選定時に検証した要件に含まれていた。11
KJH-Compは、納期遵守率が約50%から2026年には最大98%へ上がり、日程作成の仕事が監督者二人から一人へ減ったと報告する。導入には、購入部品の準備状況確認、技能の対応付け、C9000 ERPとの接続が含まれた。これらは、便利な計画画面というだけではない、生産業務の具体的な変化である。12
どちらも、大量の手動調整から離れつつある製造業者の事例であり、その状況での省力化の可能性を支える。ただし、ソフトウェア、連携、顧客側の開発労力、その他の業務変更を分けた純収益の計算は、どちらも公開しない。98%は納期遵守の指標であり、予測精度ではない。その意味は、達成時の約束と生産条件に依存する。
技術の歴史とロードマップの一貫性
| 時期 | 公開された訴求 | 実装の証拠と残る問い |
|---|---|---|
| 2022年 | AIスケジューリング、高速再計算、問題シナリオの予測 | 情報資料は、ERPデータを取り込み、利用者の優先順位で動く生産モデルを説明した。予測という表現には、文書化された確率的仕組みがなかった。 |
| 2023–2024年 | 工場導入 | KJH-Compは数か月間、既存プロセスと並行稼働し、全面採用後も共同の機能開発を継続した。 |
| 2025年 | 卓越したAI能力と迅速な導入 | パンフレットは比較ベンチマークなしで市場最強級のAIを主張し、マニュアルは具体的規則、資材制約、定時再計算を文書化した。 |
| 2026年 | エージェント型スケジューリングとMCP | ツールへのアクセスとサンドボックス設定に加え、通常のAPS自動化が何を示し、何を示さないかについて、より精密な説明が公開された。 |
2022年の資料はすでに、生産作業の順序付けをAIと呼び、問題シナリオの先読みを宣伝していた。学習方法、予測評価、経済ベンチマークは示していなかった。この初期のAI表現は、伴う技術証拠より広かった。2025年のパンフレットは、公開比較なしのまま、市場で最も強力なAIという表現へとさらに拡大した。16 17
情報発信には実質的な改善もある。2026年10月10日更新のJussi Mäntyläの記事は、定時再計画と広範なエージェント業務フロー、既知注文から算出する将来能力と予測、受信した更新への反応と障害予測を、明確に区別する。説明用シナリオをそのように表示し、ソフトウェアと連携費用を含む、同程度の業務量での導入前後測定を求めている。18
現在の説明は技術的に有用性が高い。残る意欲的な主張は、提供された意思決定の質と開発生産性で評価すべきである。言語モデルを接続しても、欠けている経済的目的は埋まらず、入荷予定日が確率的供給予測になるわけでもない。
ソフトウェア部品表と連携の一貫性
利用可能な資料は、比較的対象を絞ったアプリケーションとそのインターフェースを示す。本番データベース、アプリケーション実行環境、スケジューリング実装、依存関係の完全な一覧は公開していない。フィンランド企業の公開採用資料を調べても、この不足は解消しなかった。
| 範囲 | 文書化された構成 | 業務への影響 |
|---|---|---|
| SkyPlannerの中核 | 独自スケジューラーArcturus、ブラウザーアプリケーション、設定済み生産データ | 顧客は運用モデルを変えられるが、文書化された設定ではスケジューリング手法を検証・置換できない。 |
| 2025年パンフレットのホスティング | Amazon Web Services | 基盤運用はベンダーの提供費用と責任に含まれる。 |
| 現在のデータ所在方針 | EU内保存を要する顧客にはEU・ドイツの標準ホスティング、その他の合意済み導入も可能 | 実際の所在地と提供者は、契約対象の環境ごとに確定する必要がある。 |
| ERPと現場の連携 | バージョン管理されたREST API、テナント文脈、注文・工程・時間ログのリソース | ID対応付け、再試行、状態の管理主体、照合は技術開発の義務になる。 |
| 任意のエージェントアクセス | 外部アシスタントが使用するMCPツール | 権限とデータ開示が、もう一つのアプリケーション境界を越える。 |
2026年10月28日更新のAPI V4ガイドは、連携の重要な失敗パターンを明らかにする。外部参照は作成の冪等性を保証せず、タイムアウトした書き込みは再試行前に照合が必要である。ページ分割された読取は変動中のデータセットのスナップショットではなく、注文のタイムスタンプでは子要素や時間ログのすべての変更を検出できない。7
これらの詳細は経済的に重要である。重複注文は、見かけ上の能力を二重に消費し得る。修正の見落としは、完了作業についてERPとスケジューラーの不一致を残す。JSONを正常に転送するコネクタでも、誤った工場計画を生成し得る。ガイドがこの問題を明示していることは長所だが、照合コードは導入済みソリューションの費用に残る。
Arcturusの計算資源消費は不透明である。公開された速度の主張には、計算費用がどう増えるかを判断するために必要な、業務量、制約の密度、ハードウェア、意思決定品質の測定がない。アーキテクチャの不確実性は、独自の中核と、その周囲の連携品質に集中している。
設定保守と所有費用
現在のサブスクリプションは、作業ステーション五つで月額199ユーロから、追加一ステーションごとに20ユーロで、利用者数は無制限である。作業ステーションは日程に割り当てる資源を指し、人や外注先も含み得る。したがって課金単位は、物理的機械の台数より広い。連携と専門サービスは別料金となる。9
SkyPlannerは1,000を超える設定項目を宣伝し、設定で足りなければ別途範囲を定めた独自開発を提供する。サービス手順は、書面の前提、見積もり、実際の生産例による検証を求める。将来の要件は、改めて範囲を定める。これは具体的な開発サービスであり、工場モデルが変わる際には反復的な費用が生じる。8
導入支援パッケージも、それぞれ境界を定める。八時間の選択肢は、サンプルデータ、設定、研修を含む。五日間のパッケージは、相手システムのAPIの理解と連携見積もりを含むが、その日数で本番連携が完成すると示すものではない。10
KJH-Compは、経過した作業期間の有用な実例である。並行稼働は2023年9月から翌年4月まで続き、顧客が機能の優先順位付けに積極的に関わり、その後も開発を継続した。12 複雑な導入については、一般的な短期設定の約束より、この履歴の方が参考になる。
継続費用は専門家の時間を購入するだけではない。所要時間の推定がずれたことを検知し、反復する遅延が悪いデータに由来するのか、目的の誤りなのかを判断し、修正を他の注文に対して検証する人が必要になる。千の設定項目は表現力と膨大な相互作用の空間を生む。サンドボックスの実験は役立つが、その実験が保守可能なロジックとして蓄積されるかは、反復可能なテストと検証可能な変更履歴によって決まる。
セキュリティ境界と経済的責任
利用者ロールのマニュアルは、現場の時間記録と管理機能を分離し、スケジューリング規則の変更を最上位ロールに限定する。API V4は、指定テナントに紐付いたAPIキーを要求する。MCPは、本番とサンドボックスで別々の、利用者ごとの読取・書込権限を加え、呼び出しを記録する。これらは具体的なアクセス境界である。15 7 6
未解決なのは、権限を持つエージェントや認証情報が侵害された後の被害である。公開資料は、本番変更の規模を独立して制限する仕組み、機微な変更の承認、誤った一括書き込みからの復旧を説明しない。コピーしたサンドボックスが実験を保護するのは、危険な操作が本番外に留まる間だけだ。ログは調査を助けるが、それ自体は破壊的変更を止めない。
プライバシー文書の整合も改善が必要である。10月の記事は、顧客データをAIモデルの学習に一切使わないと述べる。6月の方針は、匿名化または集計した業務情報の製品改善への利用を認め、別途合意しない限り他顧客向けの学習を除外する。5月の規約は、匿名化・集計データによるAIモデル改善を許す。これらは異なる約束である。契約上の許可は実際の学習を証明しないが、公開された絶対的な表現は、保持される許可を説明していない。18 14 13
経済的責任は、より明確である。規約第9節は、AI出力を助言とし、顧客の独立判断を要求し、その結果となる意思決定と事業成果を顧客に帰属させる。賠償責任の上限は、リスクにさらされる生産価値ではなく、サブスクリプション料金で決まる。13 製品が結果の日程を自動化する一方で、悪い経済モデルの負担は購入者へ置かれる。
したがって信頼できる導入では、失敗を経済的に定義し、SkyPlannerが直すべきモデル欠陥を特定し、顧客に続く仕事量を測るべきである。現在の記事の測定助言は有用な出発点だが、利益を生む意思決定ロジックを維持するという契約上の約束ではない。
サプライチェーン評価
サプライチェーンへの理解の深さ
| 評価基準 | スコア |
|---|---|
| 経済性に基づく問題設定 | 3/10 |
| 最終的な意思決定への到達 | 8/10 |
| サプライチェーンに関する概念の明確さ | 6/10 |
| 時代遅れの中核的な考え方からの脱却 | 5/10 |
| KPIの見せかけに対する耐性 | 6/10 |
平均：5.6/10。
経済性に基づく問題設定 — 3/10。 スケジューリング上の選好は実際のトレードオフに影響するが、文書化された目的は、遅延、段取り、在庫、販売機会損失をまとめて金額評価しない。選んだ優先順位の金銭的意味は、公開計算の外で与え、維持する必要がある。2
最終的な意思決定への到達 — 8/10。 製品は、作業者が実行できる割当と作業順序を作る。EKOYの金型・機械の作業一覧は、そのつながりを具体的に説明する。より広い調達と生産数量の判断は、実証された最終出力の外に残る。11
サプライチェーンに関する概念の明確さ — 6/10。 資材の準備状況と生産依存関係を、実際の制約として扱う。ただし、入荷日はサプライヤーの不確実性にさらされるため、実行可能な計画も、工場が完全には制御できない入力を条件としている。3
時代遅れの中核的な考え方からの脱却 — 5/10。 自動スケジューリングは手動負荷配分をなくすが、顧客が選ぶ重要度と時間の優先順位が、なお妥協点を決める。この選好調整を、一貫した経済的判断基準に置き換えたとは示されていない。2
KPIの見せかけに対する耐性 — 6/10。 顧客報告は、納期遵守を予測精度と呼ぶのではなく、業務指標と仕事量を特定する。ただし、費用の寄与の切り分けと業務量の比較可能性が欠けるため、報告された改善から一般的な純収益は確立できない。11 12
意思決定と最適化の実質
| 評価基準 | スコア |
|---|---|
| 確率的モデリングの深さ | 2/10 |
| 最適化または機械学習の独自性と実質 | 4/10 |
| 現実の制約への対応 | 7/10 |
| 意思決定の自動化と労働生産性 | 7/10 |
| 実際の業務の複雑さに対する耐性 | 5/10 |
平均：5.0/10。
確率的モデリングの深さ — 2/10。 予想される資材利用可能性と設定済みの加工効率は、不確実な供給、生産、需要の同時予測を提供しない。その将来像がなければ、予防的な能力や在庫の費用を、複数の未来にわたり一貫して評価できない。3 4
最適化または機械学習の独自性と実質 — 4/10。 Arcturusには明確なスケジューリングの役割があるが、探索手法と比較性能は非公開である。パンフレットの卓越したAIという主張には、アルゴリズムの優越性を示すベンチマークが伴わない。17
現実の制約への対応 — 7/10。 複数の生産資源と資材依存関係は、単純な納期順の並べ替えを超えるモデルを作る。公開例は工場スケジューリングの深さを支えるが、歩留まり変動と一体的な調達判断は確立していない。1 11
意思決定の自動化と労働生産性 — 7/10。 自動再計画は文書化され、顧客報告は削減された計画労務を示す。公開証拠は保守人員全体を測らず、新しいエージェントインターフェースによる追加削減も切り分けていない。5 12
実際の業務の複雑さに対する耐性 — 5/10。 サンドボックスと定義されたカスタマイズ手順は、生産モデルの修正を支える。しかし、悪い経済判断の診断から、データや目的の改訂、再実行、受入、安全なリリースまでを通した実証済みの流れはない。6 8
製品とアーキテクチャの一貫性
| 評価基準 | スコア |
|---|---|
| アーキテクチャの整合性 | 6/10 |
| システム境界の明確さ | 7/10 |
| セキュリティへの真剣さ | 5/10 |
| ソフトウェアの簡素さと所有費用 | 5/10 |
| プログラムによる運用とエージェント支援運用への適合性 | 7/10 |
平均：6.0/10。
アーキテクチャの整合性 — 6/10。 日程計画と現場進捗は、文書化されたアプリケーションモデルを共有する。データベースと計画内部が非公開なため、サービス内の重複計算と障害伝播の評価は制限される。1 7
システム境界の明確さ — 7/10。 連携ガイドはフィールドの管理主体を明示し、照合要件を説明する。ERPとスケジューラーを一致させる仕事が見える一方、実装の成功は、なお顧客固有の対応付けに依存する。7
セキュリティへの真剣さ — 5/10。 異なるロールと環境ごとの権限がアクセスを制限する。公開説明は、侵害された本番書込アクセスへの十分に細かな制限や、重大なモデル変更からの検証済み復旧手順を示さない。15 6
ソフトウェアの簡素さと所有費用 — 5/10。 サブスクリプション料金は分かりやすく、独自作業の範囲も定める。設定の数と継続的な連携責任は、公開事例で定量化されない保守費用を生む。9 8
プログラムによる運用とエージェント支援運用への適合性 — 7/10。 APIとエージェントツールは、業務状態とスケジューリング操作に届く。大きな自動化を可能にするが、安全な無人実行には、なお確実な照合と限定された権限が必要である。7 6
技術的透明性
| 評価基準 | スコア |
|---|---|
| 公開技術文書 | 7/10 |
| ベンダーの仲介なしでの検証可能性 | 5/10 |
| 移植性とロックインの可視性 | 5/10 |
| 実装方法の透明性 | 7/10 |
| 技術的主張を裏付ける証拠の密度 | 5/10 |
平均：5.8/10。
公開技術文書 — 7/10。 公開マニュアルは、計画の動作、設定の依存関係、連携の失敗パターンを説明する。しかし、エンジンの数値的定式化と、本番依存関係の完全な一覧までは届かない。2 4 7
ベンダーの仲介なしでの検証可能性 — 5/10。 利用者はパラメータを確認し日程を比較できるが、中核手法を独立に検証できない。プライバシーポリシーは、Arcturusを汎用言語モデルではなく独自スケジューリングエンジンとしている。14
移植性とロックインの可視性 — 5/10。 規約は通常のデータ出力と解約後の取得期間を定める。生産記録を出力できても、設定した挙動の移植性やArcturusの代替を確立するわけではない。13
実装方法の透明性 — 7/10。 導入支援とカスタマイズのページは、調査、範囲、見積もり、検証を定める。これらはサービス境界を明らかにするが、長年のモデル変更に伴う費用と反復可能性は顧客ごとに異なる。10 8
技術的主張を裏付ける証拠の密度 — 5/10。 マニュアルと実名導入事例は、実務的なスケジューリングを支える。市場最先端のAIと極めて高速な計算という主張には、特定の業務量での意思決定価値を比較する統制された評価がない。17
ベンダーの真摯さ
| 評価基準 | スコア |
|---|---|
| 公開発信の技術的な真摯さ | 5/10 |
| 技術ロードマップの一貫性 | 6/10 |
| 概念の明確さ | 6/10 |
| 経済的責任 | 3/10 |
| エージェント型ソフトウェアの世界での競争力の持続性 | 5/10 |
平均：5.0/10。
公開発信の技術的な真摯さ — 5/10。 具体的な文書と、卓越したAIの主張が共存する。現在のエージェント記事は利用可能な機能についてより精密だが、商業的な優越性は比較証拠なしで主張されている。17 18
技術ロードマップの一貫性 — 6/10。 従来のスケジューリング提案は、実名の工場導入と、より明示的になった制御を生んだ。当初の予測の主張はなお裏付けが弱いが、日付のあるエージェント表現の明確化は有用な修正である。16 18
概念の明確さ — 6/10。 ベンダーは現在、既知の生産負荷、反応的な再計算、予測を区別する。一方、商業的な意思決定モデルは、競合する目的間の交換を計画担当者の判断に残している。18 2
経済的責任 — 3/10。 契約は事業成果を顧客の責任とし、提供者のリスクを限定する。公開された省力化は、経済的に欠陥のあるモデルを診断・修復する義務を確立しない。13
エージェント型ソフトウェアの世界での競争力の持続性 — 5/10。 工場固有の制約、連携知識、現場での定着には価値がある。アシスタント画面は容易に再現でき、持続的な差別化はより良い意思決定と安価なモデル改善に依存するが、どちらにも公開比較による実証はない。8 11
出典
以下は本レビューに使用した公開文書であり、閲覧日は2026年11月4日である。
出典を読む。現在の生産機能範囲、資源、スケジューリング設定。
出典を読む。2025年6月11日のマニュアル。納期順、期限内完了件数、相対優先順位の違い。
出典を読む。2025年6月11日のマニュアル。資材在庫と入荷予定の制約。
出典を読む。2025年9月9日のマニュアル。相対的な加工効率と再計画の前提条件。
出典を読む。2025年4月8日のマニュアル。間隔指定の再計算。
[6] SkyPlanner — 生産スケジューリング用MCPサーバー
出典を読む。現在のエージェントツール、コピー型サンドボックス、選択的な本番反映、アクセス権限。
[7] SkyPlanner — API V4による最初の連携開発
出典を読む。2026年10月28日の連携チュートリアル。API V4の管理責任、認証、照合、更新動作。
出典を読む。前提と検証を含む、設定と別途範囲を定める開発。
出典を読む。現在のサブスクリプション課金単位とサービス境界。
出典を読む。八時間、五日間、個別対応の導入パッケージ。
[11] SkyPlanner — Eino Korhonenの顧客報告
出典を読む。機械負荷配分、金型、解放された計画業務を説明する実名のEKOY事例。
[12] SkyPlanner — KJH-Compの顧客報告
出典を読む。導入時期、その後の開発、2026年の業務指標を説明する実名のKJH-Comp事例。
[13] SkyPlanner — 利用規約、バージョン2.1
出典を読む。2026年5月7日のバージョン2.1。データ権利、賠償責任、サービス責任、終了時の取り決め。
出典を読む。2026年6月5日。ホスティング、スケジューリングエンジン、データ利用、任意のAI依存関係。
出典を読む。2025年6月13日。スケジューリング設定へのロール別アクセス。
[16] SkyPlanner — SkyPlanner APS情報資料
出典を読む。2022年9月のアップロードパスで配布された過去のPDF。スケジューリングと予測の主張。
[17] SkyPlanner — SkyPlannerパンフレット
出典を読む。2025年のパンフレット。AIの主張、ホスティング、サービス、実名顧客の証言。
[18] SkyPlanner — エージェント型生産スケジューリング：自動化と制御
出典を読む。2026年10月10日更新の記事。APS自動化、エージェント業務フロー、成果測定に関する現在の明確化。