ビジネス活用2026年10月更新

追加開発の見積もりを受け取ったら確認すること|当初範囲・影響範囲・優先順位を書類で確かめる

公開日: 2026/10/11
追加開発の見積もりを受け取ったら確認すること|当初範囲・影響範囲・優先順位を書類で確かめる

この記事のポイント

追加開発の見積もりを今の開発会社1社から受け取ったときの確認手順。当初範囲内か追加か、影響範囲と既存機能の再確認、必須・後回し・やめるの判断、合意前に着手させない書面の残し方を、IPAモデル契約と架空の見積2例で解説します。

この記事は、システムを外注済みで、今の開発会社から追加開発・仕様変更の見積もりを1通だけ受け取り、承認してよいか迷っている事業責任者・業務部門長に向けたものです。他社と比べられない状況では、金額が高いか安いかを当てようとするより、「その変更は当初の範囲内か」「影響範囲と既存機能の再確認が書かれているか」「必須・後回し・やめるのどれか」を書類で確かめ、合意するまで着手してもらわないほうが確実に判断できます。

確認の順番は次の4つです。

  1. 当初の契約書・見積書・要件定義書・議事録と、変更見積を1行ずつ照らし合わせる
  2. 変更見積に、影響範囲・試験・前提・対象外・スケジュールが書かれているかを確かめ、足りなければ聞き返す
  3. 変更の中身を「必須」「後回し」「やめる」に分け、必要なら範囲を絞って見積を出し直してもらう
  4. 合意した内容を書面(メールでも可)に残してから着手してもらう

契約前に追加費用を防ぐ取り決めや、開発途中の要望1件を画面・データ・連携・権限・再テストに分ける方法は、システム開発の追加費用の記事で扱っています。この記事では、変更見積の書面そのものの読み方と、比べる相手がいないときの確かめ方に絞ります。

この確かめ方が合う場合・合わない場合

すべての追加見積に、ここまでの確認が必要なわけではありません。

状況

合うか

代わりに取る手

契約後・公開後に、今の開発会社から変更見積が1通届いた。金額の根拠も、当初範囲に含まれるかも分からない

合う

この記事の手順で確かめる

公開後の保守契約中に、改修の見積が届いた。保守費に含まれる作業かが分からない

合う

後半の「保守契約書のどこを見るか」の表を使う

文言の修正や設定の変更など、小さな変更で、保守契約の範囲に入りそうなもの

合わない

まず今の会社に「保守の範囲内か」を聞くほうが早い

まだ契約前で、複数社の初回見積を比べている

合わない

AI開発の見積もりの比較方法を参照

追加費用を払うかどうかで、すでに争いになっている

合わない

契約の解釈や支払義務の判断は弁護士に相談する

追加見積が大きく、作り直しも考え始めている

一部合う

書類の照合は同じ。そのうえで改修とリプレイスの比べ方を参照

変更見積が出た場面を、まず3つに分ける

同じ「追加見積」でも、いつ出たかで見る書類が変わります。

場面

例

主に見る書類

最初に確かめること

① 開発途中(設計の承認後)の仕様変更・追加要望

画面案を承認した後に、承認の段階を増やしたくなった

要件定義書・外部設計書(画面や帳票の設計)とその承認日、議事録

承認した資料に、その動きが書かれているか

② 決めきれていなかった事項が、後から決まった

取引先とのデータ形式が、契約時には未定だった

契約書・見積書の「前提条件」「未確定事項」の欄

未確定のまま始めたことが書面に残っているか。確定したら費用が変わる、と合意していたか

③ 公開後・保守中の改修

運用を始めてから、一覧に項目を足したくなった

保守契約書(対象作業・軽微な変更の定義・対象外)

保守の月額に含まれる作業か、別見積の作業か

情報処理推進機構(IPA)が公開している「情報システム・モデル取引・契約書」(第二版)の解説では、外部設計の承認後に出た要件の追加・仕様変更や、未確定事項の確定は、追加・再見積を含む変更として変更管理の手続で扱う、という考え方が示されています(IPA モデル取引・契約書、2026-10-12確認)。最初に「設計を承認した後の話かどうか」を確かめるのは、このためです。

なお、モデル契約はひな形です。お手元の契約書に同じ条項があるとは限りません。以下の表は「自社の契約書にこの項目があるか」を探す目安として使ってください。

当初の範囲内か追加かを、手元の書類で照らし合わせる

木のテーブルに置かれたメモ用紙とペン。当初の書類と変更見積を照らし合わせる作業のイメージ

変更見積の1行ごとに、当初の書類のどこに書いてあるかを探します。書類ごとに見る箇所は次のとおりです。

書類

見る箇所

確かめること

見つからないときの聞き方

契約書

変更の手続、検収、契約不適合責任(納品後の不具合を直す責任)の期間

変更は書面で合意する決まりか。今回の件が不具合の修正にあたらないか

「今回の件は、契約書のどの条項に基づく変更として扱っていますか」

当初の見積書

前提条件、対象外、「一式」の行の中身

今回の作業が、当初の「一式」に入っていた可能性はないか

「当初見積の『◯◯一式』に、今回の作業は含まれていなかったという理解でよいですか」

要件定義書・外部設計書

該当する画面・帳票・データの記述と、承認日

承認した資料に書かれた動きと、今回の依頼が違うか

「承認済みの設計書の何ページの記述から変わる、という整理でしょうか」

議事録・メール・チャット

誰が、いつ、何を頼んだか。費用がかかると事前に言われたか

依頼の経緯。社内の誰かが口頭で頼んでいないか

(社内で先に確認する)

変更見積

工程別の行、前提、対象外、有効期限、スケジュール

次の節の8項目がそろっているか

次の節の表を参照

照らし合わせた結果は、次のように1枚にまとめておくと、社内の説明と開発会社とのやり取りの両方に使えます。

記入例(説明用の架空データ)

変更見積の行

当初の書類での記載

判定

次の対応

受注一覧に「出荷予定日」欄を追加

外部設計書(◯月◯日承認)の一覧画面に記載なし

追加

見積の内訳を確認する

倉庫から届くCSVの取込に出荷予定日を追加

要件定義書に「倉庫CSVは受注番号と出荷日のみ取り込む」とある

追加

倉庫側のCSVに出荷予定日の列があるかを社内で確認する

予定日を過ぎた受注を担当者にメールで通知

記載なし

追加

優先順位を決める(後述)

一覧の並び順の不具合修正

外部設計書に「受注日の新しい順」とあるが、古い順で表示されている

当初範囲内(不具合の可能性)

追加費用から外せるか確認する

最後の行のように、変更見積に当初範囲の修正が混ざっていることもあります。不具合か追加要望かの分け方は、追加費用の記事の「不具合か追加要望かを先に分ける」に表があります。

書面が無い依頼でも、経緯から追加の支払いが認められた裁判例があります(モノリス法律事務所の解説、2026-10-12確認。仕様変更の申出が新たな委託の申込みとされ、追加代金の合意がないまま作業が終わった分にも相当額の支払義務があるとされた大阪地裁 平成14年8月29日判決などが紹介されています)。「書面が無いから払わなくてよい」とも「言われたら払うしかない」とも決めつけず、まず記録を並べてください。個別のケースでの支払義務の判断は弁護士の領域です。

変更見積に足りない項目を、IPAの変更管理書の8項目で探す

独立行政法人情報処理推進機構(IPA)のロゴ画像

出典:独立行政法人情報処理推進機構(IPA)「情報システム・モデル取引・契約書」

IPAのモデル契約(第二版)第37条は、変更を協議するときに作る「変更管理書」に書く事項を8つ挙げています(条文抜き出し版で2026-10-12確認)。受け取った変更見積をこの8項目と並べると、聞き返すべきことが分かります。

#

変更管理書の記載事項

変更見積のどこに出るか

欠けていたら聞くこと

1

変更の名称

件名

何を変える見積かを1行で書いてもらう

2

提案の責任者

担当者名

質問の窓口と、承認権のある責任者

3

年月日

発行日・有効期限

いつまでに返事をすれば、この金額とスケジュールが有効か

4

変更の理由

備考・依頼の経緯

誰からのどの依頼に対する見積か

5

仕様を含む変更の詳細

作業項目・前提条件・対象外

どの画面・データ・連携・権限・帳票が変わるか。何は変えないか

6

費用の額

金額・工程別の内訳

調査・設計・実装・既存機能の再確認・本番反映・管理の内訳

7

検討期間を含めた作業のスケジュール

期間・納期

承認から何週間で本番に入るか。止める時間はあるか

8

契約条件(納期・委託料・契約条項等)への影響

備考

当初の納期・保守費・検収の日程が変わるか

8項目すべてが見積書に書かれていなくても、それだけで不誠実とは言えません。見積書の書式は会社ごとに違います。欠けている項目を「聞き返すことのリスト」として使ってください。

架空の変更見積2通を、同じ表に書き写して読む(説明用)

1社しか見積がないと「高いか安いか」を比べられません。そこで比べる対象を金額から判断に必要な情報がそろっているかに変えます。次は、同じ依頼に対して書き方の違う変更見積が届いたと仮定した、説明用の架空データです。実在の会社・案件の見積ではありません。

依頼の内容(架空): 公開から4か月たった受注管理システムで、受注一覧に「出荷予定日」欄を追加し、予定日を過ぎた受注を担当者にメールで知らせたい。出荷予定日は、倉庫のシステムから毎日届くCSVに含まれている前提。

確かめる項目

A案の書き方

B案の書き方

総額(税別)

80万円

128万円

内訳(人日=1人が1日でする作業量)

「受注一覧改修 一式」の1行

影響調査 1人日 8万円/設計 2人日 16万円/実装 6人日 48万円/既存機能の再確認 4人日 32万円/本番反映 1人日 8万円/進行管理 2人日 16万円(計16人日)

影響範囲

記載なし

受注一覧、倉庫CSVの取込、受注データ、メール送信(新規)。請求書の帳票は変更なし

既存機能の再確認

記載なし

受注の登録・検索・CSV出力・請求書出力を再確認

本番反映

記載なし

夜間に反映、停止は約30分の見込み

前提条件

記載なし

倉庫CSVの列の並びは変えない。メールの宛先は担当者マスタの登録内容を使う

対象外

記載なし

倉庫システム側の改修、メール送信サービスの利用料、公開前の過去データの補正

スケジュール

「別途調整」

承認から4週間

有効期限

記載なし

発行から30日

保守費への影響

記載なし

通知機能を保守の対象に加える場合、保守費の見直しを別途協議

※金額・人日はすべて説明用の架空の値です。B案は1人日8万円という架空の設定で計算しており、実際の単価や相場を示すものではありません。

この2通から読み取れるのは、「A案のほうが48万円安い」ことではありません。

  • B案は、金額が妥当かどうかを判断できる材料がそろっている。 例えば「既存機能の再確認に4人日は多い」と感じたら、その行だけを相談できる。メール通知をやめた場合の差額も聞きやすい
  • A案は、何が含まれているか分からない。 既存機能の再確認や本番反映が入っていなければ、後から別の見積が来るかもしれない。逆に、すべて含んだうえで80万円なのかもしれない。どちらかは、聞かないと分からない
  • A案を受け取ったら、B案の行の並びをそのまま質問に使える。 「影響調査・設計・実装・既存機能の再確認・本番反映・管理に分けると、それぞれ何人日ですか」と聞けば、比べる相手がいなくても中身を確かめられる

内訳が出てきた後で、規模感が依頼に見合うかを考えます。要望1件を画面・データ・連携・権限・再テストに分けて作業量を見積もる例は、追加費用の記事に載せています。

開発会社に返す質問の文例

聞き返すときは、相手を疑う言い方より「社内で説明するために必要」という言い方のほうが、詳しい答えが返ってきやすくなります。

確かめたいこと

文例

当初範囲との関係

「社内で承認を取るため、今回の変更が当初の見積・設計書のどこから変わるのかを教えていただけますか」

内訳

「『一式』の中身を、調査・設計・実装・既存機能の再確認・本番反映・管理に分けると、それぞれ何人日になりますか」

影響範囲

「今回の変更で動きが変わる画面・帳票・データ・連携先と、変わらないものを一覧でいただけますか」

既存機能の再確認

「既存のどの機能を、どの程度まで確認する前提でしょうか。当社側で確認する部分はありますか」

前提と対象外

「この金額の前提になっている条件と、含まれていない作業を教えてください」

範囲を絞った場合

「メール通知を外して、一覧への表示だけにした場合の金額と期間も出していただけますか」

時期の違い

「今入れる場合と、次の改修とまとめる場合で、費用や確認の手間は変わりますか」

着手の時期

「社内承認が◯月◯日になる見込みです。それまでは着手を待っていただけますか」

ChatGPTやClaudeなどの生成AIに見積書を読ませて、質問の下書きを作ってもらうのも有効です。ただし、見積書や契約書を外部のAIサービスに入力してよいかは、社内の規程と契約の秘密保持の条項を先に確認してください。

必須・後回し・やめるを決める判断表

ホワイトボードに書かれたメモとマーカー。変更の中身を必須・後回し・やめるに仕分けるイメージ

内訳がそろったら、変更の中身を1つずつ分けます。全部を承認するか全部を断るかの2択にせず、一部だけ進める選択肢を持っておくと、予算と業務の両方を守りやすくなります。

判断の問い

「はい」なら

法令や取引先との約束で、期日までに必要か

必須

無いと業務が止まる、または毎日の手作業が増え続けるか

必須

手作業や運用のルールで、当面しのげるか

後回し(再検討する時期を決める)

公開後や次の改修でまとめて入れると、確認の手間が増えるか

開発会社に聞いたうえで、必須か後回しかを決める

依頼した部署以外は使わない、または誰が頼んだか社内で確認できないか

やめる候補(依頼元に必要性を確かめる)

記入例(説明用の架空データ。上のA案・B案と同じ依頼)

変更の中身

判断

理由

受注一覧に出荷予定日を表示

必須

遅れの問い合わせのたびに、倉庫へ電話で確認している

予定日を過ぎた受注のメール通知

後回し

一覧を出荷予定日で並べ替えれば、毎朝の確認で当面しのげる。3か月後に再検討

公開前の過去データの補正

やめる

過去の受注は出荷済みで、予定日を見る場面がない

この結論を開発会社に伝え、「表示だけの範囲で見積を出し直してほしい」と頼みます。外した作業は「無くなった」ではなく「後回しにした」と記録しておくと、半年後に同じ要望が出たときに説明できます。他の機能と入れ替えて予算を変えない方法や、承認の記録に残す5点は、追加費用の記事の後半を参照してください。

公開後・保守契約中の改修見積は、保守契約書のどこを見るか

データセンターに並ぶサーバーの冷却ファン。公開後のシステム保守のイメージ

公開後に届いた改修の見積で「保守の月額に含まれるのでは」と感じたら、保守契約書の次の箇所を見ます。

保守契約書の箇所

確かめること

保守の対象作業

問い合わせ対応・不具合の調査と修正・軽微な変更のどれが含まれるか

「軽微な変更」「改修」の定義

文言・設定の変更までか、画面や項目の追加まで含むか。件数や時間の上限があるか

月額に含まれる作業時間・件数

上限があるなら、今月の残りはどれだけか。超えた分の単価はいくらか

対象外の作業

新機能の追加、外部連携先の仕様変更への対応、データの補正が対象外になっていないか

不具合の扱い

納品後の不具合を直す責任の期間(契約不適合責任)がまだ残っていないか

別見積にする場合の手続

見積の提示、発注書、承認の流れが決まっているか

保守契約書に定義が無い、または読んでも判断できないときは、「今回の作業は、保守契約のどの項目に当たらないため別見積になる、という整理でしょうか」と聞いてください。保守費そのものの考え方はシステム保守運用費の相場で扱っています。

合意するまで着手してもらわない・書面で残す

公正取引委員会のロゴ

出典:公正取引委員会

IPAのモデル契約(第二版)では、契約内容の変更は書面で変更契約を結ぶことで行い(第33条)、変更管理書の内容は双方の責任者の承認で確定し、納期や委託料などの契約条件に影響する場合は変更契約を結んだときに確定する、とされています(第37条)。また、協議がまとまらない間は、開発会社が作業を中断できるとも定めています(第37条4項)。合意前に着手してもらわないのは発注者の都合だけでなく、モデル契約が想定している手続でもあります。

打合せやチャットで「では進めておきます」と言われたときは、次のように返します。

「ありがとうございます。社内承認が必要なため、見積書を確認して◯月◯日までにお返事します。それまでは着手を待っていただけますか。急ぎで先に調べていただく必要がある部分があれば、その範囲と費用を教えてください」

合意したら、メールで次の項目を残します。変更の名称/対象にする作業と、後回し・やめると決めた作業/金額(税別)と支払いの時期/スケジュールと本番反映の日/既存機能の再確認の範囲と、当社側で確認すること/保守費や当初の納期への影響/双方の承認者と日付。

一方で、追加見積の協議そのものに応じなかったり、返事を先延ばしし続けたりするのは避けてください。発注者と開発会社の規模によっては、2026年1月に施行された取適法(中小受託取引適正化法)で、協議に応じない一方的な代金の決定が問題になりえます(公正取引委員会 よくある質問、2026-10-12確認)。自社が対象になるかの説明は追加費用の記事にあり、個別の判断は弁護士にご確認ください。

1社しかいないときの確かめ方:自社・生成AI・開発会社・第三者の分担

今の会社以外から見積を取りにくい理由の一つは、既存のソースコードや設計書を他社が見られないことです。確かめる手段を4つに分けると、どこまで自分たちでできるかが分かります。

誰が

できること

できないこと

自社

書類の照合、依頼の経緯の確認、必須・後回し・やめるの判断、社内承認

影響範囲や作業量が正しいかの判断

生成AI

見積書の行の意味の説明、8項目の欠けの洗い出し、質問の下書き。ソースコードを渡せる立場なら、影響しそうな箇所の下調べ

当初範囲内かの最終判断(契約と経緯の解釈)。見積書だけを渡した場合の、影響範囲が正しいかの確認

今の開発会社

影響範囲・作業量・既存機能の再確認の範囲の説明、範囲を絞った再見積

自社の業務上の優先順位の判断

第三者(別の開発会社など)

内訳と影響範囲の説明が筋の通ったものかの意見。資料やコードを見られれば、作業量の見立て

ソースコード・設計書・環境を見られない状態での作業量の判定

第三者に見てもらうなら、先に何を見せてよいかを確かめます。今の開発会社との契約で、ソースコードや設計書の利用権が自社にあるか、秘密保持の条項で第三者への開示が制限されていないかを確認してください。見積書だけを見せる場合は、社名や金額を伏せても、内訳と前提の書き方についての意見は聞けます。

今の会社以外に追加開発を頼む場合と、当社に頼める範囲

確認した結果、今の会社に続けて頼むのが最も早く、安く済むことは十分にあります。既存のコードと運用を知っているのは今の会社だからです。別の会社に頼むことを考えるのは、説明を求めても内訳や影響範囲が示されない、対応できる体制がない、作り直しも視野に入っている、といった場合です。

AI革命(当社)は、他社が作ったシステムの調査・引継ぎ・改修に対応できます。「調査のみ」と「調査+改修」のどちらでもお受けでき、言語やフレームワークを理由にお断りすることはありません。画面・帳票の追加、CSVやAPIでの連携、権限の変更、データ移行といった追加開発そのものもご相談いただけます。なお、他社の変更見積を確認した事例は、当社の公開実績には含まれていません。

費用は次のとおりです(すべて税別)。

頼む内容

価格(税別)

価格に含まないもの

進め方

既存システムの改修

100万円〜

クラウド・外部API・ライセンスなどの実費

資料を受け取った後に範囲と見積を示し、合意してから着手

他社が作ったシステムの調査(改修の前に必要な場合)

有償。着手前に範囲と金額を示して合意

ソースコードや環境の利用権の取得(今の会社との契約で決まる)

最初にソースコード・設計書・環境情報の有無と利用権を確認

作り直し・大きな機能追加

本開発は個別見積

同上の実費

要件の整理から相談

当社の価格は、今の会社の変更見積が高いか安いかを決める物差しにはなりません。システムの中身を知らない会社が引き継ぐ場合は、最初に調査が必要になるため、同じ変更でも費用の内訳が変わります。

今の会社に何を聞き返せばよいか、自社で確かめられる部分はどこか、別の会社に頼むならどこから始めるかを、今の状況を伺って一緒に切り分けます。初回の30分で、今の会社の見積が妥当かどうかを断定することはしません。

受け取った追加見積の前提と開発範囲を相談する

初回相談は無料・30分(オンライン)で、要件が決まっていなくても大丈夫です。相談後に、依頼範囲の候補・進め方・費用の目安をまとめた相談メモをお送りします。別の会社への依頼先を比べたい場合は、システム改修の会社の選び方も参考にしてください。

相談の前に手元にそろえておくもの

次のものの有無が分かっていると、30分の中で話が具体的になります。すべてそろっていなくても相談できます。

  • 受け取った変更見積(社名・金額を伏せたものでも可)
  • 当初の見積書の前提条件・対象外の部分
  • 契約書の変更手続、保守契約書の対象作業の部分
  • 要件定義書・設計書のうち該当する箇所と、その承認日
  • 依頼の経緯(誰が、いつ、何を頼んだか)のメモ
  • ソースコード・設計書の利用権が自社にあるかどうか(分からなければ「不明」で構いません)

初回の相談フォームには、本番環境のIDやパスワード、実際の顧客データ、社外秘の書類そのものは送らないでください。

よくある質問

Q1. 変更見積の有効期限が切れてしまいました。同じ金額で発注できますか?

開発会社の判断によります。有効期限は、担当者の空き状況や他の改修との順番を前提にしていることがあり、期限が切れると時期や金額が変わる場合があります。社内承認に時間がかかりそうなときは、見積を受け取った時点で「承認は◯月◯日の見込み」と伝え、期限の延長か、その時期で出し直してもらえるかを先に聞いておくと確実です。

Q2. 金額だけを下げてほしいと頼むのは問題がありますか?

交渉自体は問題ありません。ただ、範囲を変えずに金額だけを下げてもらうと、既存機能の再確認など、見えにくい作業が削られる可能性があります。下げたいときは「メール通知を外す」「次の改修とまとめる」のように、範囲を変えた見積を頼むほうが、何を諦めたかが記録に残ります。

Q3. 当初の見積書や設計書が手元に見当たりません。

開発会社に写しを依頼してください。それと並行して、社内のメール・チャット・請求書・検収の記録から、いつ何を発注し、何を受け取ったかをたどれます。書類がそろうまでは、変更見積への返事を保留して構いません。そのときも、確認に必要な日数を相手に伝え、協議そのものは続けてください。

Q4. 開発会社から「今すぐ着手しないと間に合わない」と言われました。

急ぐ理由が業務の期日(取引先の切替日など)なのか、開発会社の体制の都合なのかを聞いてください。どうしても先に動く必要があるなら、全体を承認する代わりに「影響調査だけ」「設計だけ」のように範囲と金額を区切って書面で発注し、残りは調査結果を見てから決める方法があります。

Q5. 社内の誰が承認すべきかが決まっていません。

追加見積は当初の稟議の後に出るため、誰が承認するかを当初の稟議で決めていないことがあります。当初の稟議で決めた予算の範囲に収まるか、超えるかで分けておくのが一つの方法です。予算内なら当初の決裁者が委ねた担当者、予算を超えるなら当初の決裁者、というように社内のルールに当てはめ、承認者と日付を合意メールに残してください。

Q6. 今の開発会社の見積書を、別の会社に見せてもよいですか?

まず、今の会社との契約の秘密保持の条項を確認してください。見積書や設計書を第三者に開示することが制限されている場合があります。判断がつかないときは、社名・金額・システム名を伏せ、行の並びと前提・対象外の書き方だけを見せる方法なら、意見を聞ける範囲が残ります。

追加見積を承認する前に、範囲と進め方を整理しませんか

変更見積は、内訳・影響範囲・前提がそろえば、比べる相手がいなくても判断できます。そろわないまま承認すると、後から別の見積が届いたり、社内で説明できなくなったりします。今の会社に何を聞き返すか、必須・後回し・やめるをどう分けるか、別の会社に頼むなら依頼範囲をどうするかを、お手元の状況に合わせて一緒に整理します。

受け取った追加見積の前提と開発範囲を相談する

初回相談は無料・30分(オンライン)で、要件が決まっていなくても大丈夫です。自社でAIを使って確かめられる部分と、任せる部分を一緒に切り分け、相談後に依頼範囲の候補・進め方・費用の目安をまとめた相談メモをお送りします。既存システムの改修は100万円〜(税別。クラウドや外部APIなどの実費は別)です。

依頼範囲と費用の目安を30分で整理します

開発について相談する

この記事の著者

AI革命

AI革命

編集部

AI革命株式会社の編集部です。最新のAI技術動向から実践的な導入事例まで、企業のデジタル変革に役立つ情報をお届けしています。豊富な経験と専門知識を活かし、読者の皆様にとって価値のあるコンテンツを制作しています。

AI・システム開発は、開始価格を公開しています

既存システムの改修 100万円〜・PoC 300万円〜(税別)。相談内容を送っていただくと、2営業日以内に担当者からご返信します