基幹は、そのまま。
仕事は、もっと軽く。

1基幹・1業務領域・外部接続先1つ、単純Read最大3本程度、単純Write最大1本程度、Web画面最大2つ、承認1フローなどの最低構成です。機能の本数だけでなく難易度の条件があります。複雑な在庫引当、原価、締め、AI/OCRなどを同じ料金に一律で含むものではありません。対象と受入基準をGate 2で具体化します。

公開商品はLegacy Bridge Standardです。ReadとWriteは、照会から検証し、必要な範囲の更新へ進む順序です。Readのみで価値が成立する案件は、読み取りの範囲と運用条件を設計し、費用を個別に固定します。使わないWriteを必ず実装するという意味ではありません。

本数だけでは決まりません。単純な在庫照会と、承認・関連データ更新・取消・バッチ依存のある処理では工数が異なります。業務目的、入力・出力、権限、受入条件と難易度を組み合わせて見積もります。単純な検索条件の追加を無条件に別APIとは数えません。

通常導入ではGate 1完了時に、前提条件付きの価格帯と上限レンジを提示し、Gate 2完了時に初期総額と月額を固定します。最初の無料相談だけで正確な総額を確定するものではありません。前提が変わらない限り、合意した上限レンジ内で仕様と金額を固定する条件です。

通常導入でGate 3以降へ進む場合、Gate 1の80万円とGate 2の120万円は、固定する初期総額の内数です。二重加算はしません。各Gateの完了後に終了する場合は完了分の累計額、途中中止は開始前に合意した精算条件によります。事前確認済みの内容と追加工程は別途整理します。

10万円〜は基盤運用の最低月額です。Write本番運用は有人保守10万円〜を合わせ、合計20万円〜が最低条件。本番稼働後12か月は有人保守を原則必須とします。十分な保守体制への移管などの例外は、個別契約で確認します。いずれも税別の最低価格です。

はい。必要な入力データ、計算ルール、APIの仕様、確認用テストがそろう範囲なら、ロジックを再実装して差し替える設計ができます。ただし、同じ項目名だけでは足りず、単位・対象・基準時点・例外の意味を合わせる必要があります。実際の工数は対象ロジックと依存関係を調べて判断します。

その判定に必要な情報を取得できれば可能です。例えば期限で対象を分けるなら、合計在庫だけでなくロット別の数量や期限、販売可否が必要です。ロジックを後から実装することと、その材料が初期APIで取得できることは別なので、将来移したい処理の入力条件を先に確認します。

APIは利用側との境界をつくるもので、基幹内部の業務処理やデータを自動で移行するものではありません。新基幹の実装、データ移行、更新・帳票・バッチの依存関係、切り替えと復旧は別途必要です。APIの仕様と意味を保つことで、周辺システムへの変更を抑えやすくするのが狙いです。

すべて終える必要はありません。業務として切り分けられ、移行効果を説明できる範囲から接続と仕様を整え、その部分を置き換える進め方を検討します。新旧が共存する間は、どちらが正しいデータの管理元か、同期や更新をどう扱うかを設計する必要があります。

一律では含みません。AI/OCR・メール解析・FAX読取・自動受注案などは、対象帳票、精度、確認修正の作業、利用料、例外処理を個別に設計する拡張範囲です。標準のWeb・API基盤と、顧客業務でAIが処理する範囲を分けて見積もります。

主対象はIBM i・AS/400です。RPG・COBOLなどの既存処理も、ソースや仕様、利用できる接続経路、保守条件を確認します。ほかの基幹でも相談は可能ですが、すべてのバージョン・プログラムを同条件で接続できるという保証ではありません。適合性と必要な体制を個別に整理します。

読み取りでも、検索や集計によるCPU・I/Oの負荷、同時利用、夜間処理への影響を確認する必要があります。対象を限定し、最小権限、件数上限、応答条件、時間帯などを検証します。Readだから無条件に安全と判断せず、合意した条件で数値と負荷を確認してから広げます。

直接更新を標準方式にはしていません。既存プログラム、既存API、キューなど、業務ルールを維持できる経路を優先して調査します。代替経路がないときは、関連データや更新競合、トランザクション、復旧への影響を検討し、顧客の承認を得た範囲で個別に判断します。

結果が不明なまま無条件に再送すると、二重登録の原因になります。要求の識別情報と状態を使い、実行済みか未実行かを確認する設計です。確認不能な場合は成功に見せず保留し、合意した担当者が確認する流れと、再試行できる条件を定めます。

標準の24時間365日は自動監視です。最低構成の有人保守は平日受付、原則1営業日以内の初動、月3時間程度を目安とし、具体条件を固定します。初動目標は復旧時間の保証ではありません。時間外の高リスクWriteは制限・保留か、追加の有人体制を合わせて検討します。

顧客の生データや固有ルールを、他社案件や基盤AIモデルの学習に流用しない方針です。API化だけでAIへの送信が始まることもありません。AIを使う案件では、利用する事業者、送信項目、保存・学習利用条件を確認し、案件ごとに書面で合意します。AIを使わない構成も検討します。

API仕様・構成・運用手順などを、内製化や他社移管で使える形にする方針です。ただし、新規開発ソース、共通基盤、外部ライセンスの提供・改変範囲は契約で区分します。担当者の経験、アカウント、復旧手順、移管テストと費用を確認し、資料を渡すだけで移管完了とはしません。

現在の基幹と困っている業務を伺い、対象になる可能性、接続前に確認すること、次に必要な資料や担当者を整理します。接続可否の確定や詳細見積は、資料・環境の調査を伴う有料工程で確認します。

はい。各Gateの結果を確認し、終了・範囲縮小・次工程への移行を判断する設計です。完了した工程の累計費用、途中中止時の精算、成果物の利用条件は、開始前に合意します。初回相談から有料開発へ自動移行することはありません。

現時点のこのサービス案では、公開できる実機接続の証拠と、担当者の経験・役割の裏付けをこれから整える段階です。ブラウザ内デモを実機性能の証明にはしません。実証開始前に技術レビュー担当、停止判断者、顧客承認者を確認し、体制と安全条件が整わなければ開始しない方針です。

現行システムを把握する担当者との連携が必要です。保守会社が管理している場合は、接続権限、業務ルール、負荷・バッチ、作業範囲を協議します。既存ベンダー側の対応費は、CETの見積に自動では含まれません。協力や許可が得られない場合は、無理に接続を進めません。

回答待ちの短縮、属人化の軽減、追跡可能性、次の連携を追加しやすくすることにも価値があります。ただし、空いた時間をそのまま支出削減には換算しません。財務回収が弱い場合はそう示したうえで、現在値・目標・期限・責任者をそろえた業務目標を別に評価します。

現在の基幹の種類、困っている業務、使う人、希望時期が分かる範囲であれば、最初の相談を始められます。詳細資料や生データをいきなり送る必要はありません。無料相談で確認論点を整理し、接続・実証の前に必要な権限、担当者、検証環境とデータを個別に確認します。