システム改修の依頼書の書き方｜開発会社に渡す項目・今の動きと変えたい動き・記入例【2026年10月】

既存の業務システムを直してほしい現場の責任者・情シスの方に向けて、開発会社へ渡す改修の依頼書の書き方をまとめます。依頼書はA4で1枚あれば足ります。肝心なのは「今の動き」「変えたい動き」「どうなれば完成か」を、誰が・どの画面で・何をするとどうなるかという操作の単位で書くことと、関係するシステムと、仕様書・ソースコードが手元にあるかを書き添えることです。

ここまで書いてあれば、開発会社が最初に聞き返しやすいことに、先に答えておけます。口頭やメールで「ここを直して」と伝えて見積が出るまで何往復もしている場合は、まずこの1枚を作るところから始めてください。

依頼書を書く前に：設定で済むか、改修を頼むか、調査から頼むか

改修の依頼書を書く前に、そもそも開発会社に頼む話かどうかを見分けます。パッケージ製品やクラウドの業務ソフト（SaaS）なら、設定画面で変えられる項目もあり、その場合は開発を頼まなくて済みます。

※この表は当社の整理です。契約や製品によって変わるため、最終的には保守契約書と提供元の案内で確かめてください。

2〜3社に同じ条件で見積を取って比べたい場合は、依頼書ではなくRFP（提案依頼書）の形にします。書き方は相見積もりのRFPテンプレートにまとめています。1社に1件の改修を頼むなら、この記事の依頼書で十分です。

改修の依頼書に書く8つの欄と、抜けたときに開発会社が聞き返すこと

依頼書の欄は次の8つです。右の列は、その欄が抜けていたときに開発会社が確かめに戻ることです。どの欄も「完璧に書く」ことより「抜けていない」ことのほうが、見積までの往復を減らします。

※「抜けると確かめに戻ること」は、この記事での説明用の整理です。往復の回数や日数を測った統計ではありません。

依頼書の下に「手元にあるもの」を1行添えます。仕様書、操作マニュアル、ソースコード、保守契約書、過去の見積書、社内でAIを使って作った試作など、あるものと無いものを書いておくと、見積の前に調査が要るかどうかの判断が早くなります。

「今の動き」と「変えたい動き」は操作の単位で書く

「使いにくい」「もっと早くしたい」のような感想の形で書くと、開発会社はどの操作を変えればよいかを特定するために聞き返すしかなく、往復が増えます。

「変えたい動き」には、例外のときにどうするかも1行書きます。たとえば「配送先が登録されていない得意先は、今までどおり手入力できる」のように書けば、開発会社は例外の扱いを聞き返さずに済みます。

完成の確かめ方を、依頼書の段階で決めておく

完成の確かめ方は、開発が終わってから決めると、「頼んだものと違う」ということが起きやすくなります。依頼書の段階で、次の3つを書いておきます。

• 何で確かめるか: テスト用のデータ（実際の顧客情報を含まない見本）を使う、など
• 何を見て「直った」とするか: 「改修前のExcel集計と、画面の月合計が一致する」のように、比べる相手を決める
• 誰が確かめるか: 現場で実際に使う人の名前か役職

あわせて「変えてはいけないもの」が改修後も元どおり動くことも、確かめる項目に入れます。改修した箇所以外が動かなくなる不具合は、確かめる範囲を決めていないと見落とされやすいからです。

記入例：架空の部品商社の受注管理システム（説明用）

以下は架空の会社・架空のデータによる説明用の記入例です。実在の案件ではありません。

この記入例でも、開発会社がまだ確かめることは残ります。

• ソースコードを受け取れるか、改修してよい権利があるか（作った会社と連絡がつかないため、契約書で権利の帰属を確かめる）
• 出荷CSVを倉庫システム側がどう読んでいるか（列を足すと倉庫システムの取込が止まらないか）
• 配送先2,000件を誰がどう登録するか（今の受注データから自動で起こすか、手で登録するか）

この3つは、依頼書を書いた側でも答えが分からないことがあります。分からないことは「不明」と書いておけば十分です。不明な点が見えていれば、開発会社は「まず調査から」と範囲を分けて見積を出せます。

前の会社が作った・仕様書が無いときに冒頭へ足す欄

出典: IPA 公式サイト

作った会社と別の会社に改修を頼む場合や、仕様書が残っていない場合は、依頼書の冒頭に次の欄を足します。

IPA（情報処理推進機構）は「情報システム・モデル取引・契約書」の見直しのポイント（最終更新 2026年9月11日）で、長く使ってきたシステムを作り直すときには、ドキュメントや詳しい人といった業務知識が失われていることが多く、要件を決める前に現行システムの調査が必要で、その調査には専門の技術とコスト・時間がかかると注意しています（IPA 公式サイト、2026年10月18日確認）。

これは作り直しについての記述ですが、仕様書の無いシステムの一部を改修する場合も、同じ理由で見積の前に調査が入ることがあります。調査を改修と別の見積にするか、改修に含めるかは会社によって違うため、見積を受け取ったら改修の見積書の見方で確かめてください。どの会社に頼むか自体を迷っている場合は、システム改修を頼む会社の選び方で、元の開発会社と別の会社の違いを整理しています。

依頼書に入れないもの・あとで渡すもの

依頼書は見積の前にメールやフォームで送る書類なので、次のものは入れません。

仕様書の本体、ソースコード、実データは、秘密保持の取り決めとデータの扱いの取り決めが済んでから渡します。

社内でAIを使って依頼書の下書きを作るとき

出典: Claude 公式サイト

依頼書の下書きは、ChatGPTやClaudeなどの生成AIでも作れます。箇条書きのメモや画面の写真（個人情報を伏せたもの）を渡して「今の動き・変えたい動き・完成の確かめ方の形に整えて」と頼めば、表の形にするところまでは手早く進みます。

一方で、次の欄はAIには埋められません。社内の人に聞いて書きます。

• 例外: 「配送先が登録されていない得意先」のような、現場だけが知っている例外とその件数
• 関係するシステム: どこにCSVを渡しているか、夜間に何が動いているか
• 権利と契約: ソースコードを誰が持っているか、改修してよいか
• 完成を確かめる人: 誰が、何と比べて「直った」と判断するか

AIが書いた下書きにもっともらしい項目が並んでいても、この4つが空欄なら、開発会社はそこを聞き返します。

依頼書を出してから見積までの流れと、開発会社が確かめること

依頼書を受け取ってから見積までに開発会社が確かめることを、段階ごとに整理しました（当社の整理です。順番や呼び方は会社によって違います）。それぞれ、発注側に聞かれることも並べました。

仕様書もソースコードも手元に無い場合は、2の段階が「調査」として別の見積になることがあります。見積の後で範囲が変わったときは、追加開発の見積の確認で、当初の範囲内か追加かの見分け方をまとめています。要件をもっと細かく決める必要が出てきたら、発注側の要件定義の進め方を参考にしてください。

改修の費用と、当社に頼める範囲

出典: AI革命 公式サイト

当社（AI革命株式会社）の公開価格は次のとおりです。

クラウドの利用料、外部サービスの利用料、ライセンス料などの実費は別です。調査・テスト・本番反映がどこまで含まれるかは案件ごとに見積でお示しするので、見積を受け取ったときに内訳で確かめてください。

上の記入例のように、データの項目を増やす（配送先を複数持たせる）、ほかのシステムへの受け渡しに関わる、仕様書が無い、作った会社と別の会社が直す、といった条件が重なるほど、調査とテストの範囲が広がって金額は上がります。何が金額を押し上げるかは、システム改修の費用と高くなる条件で詳しく扱っています。

反対に、文言の修正1か所のような100万円に届かない軽い変更は、当社の価格帯に合いません。今の保守会社か、作った会社に相談するほうが合っています。

当社は、言語やフレームワーク、作った会社を問わず既存システムの改修に対応できます。画面・帳票の追加、CSVやAPIでのデータ連携、kintone・freee・HubSpotなどの業務ソフトとの連携、権限の見直し、ほかの会社が作ったシステムの調査・引継ぎ・改修、社内でAIを使って作った試作を本番で使える形にすることも、ご相談ください。ほかの会社が作ったシステムは「調査のみ」でも「調査と改修」でもお受けでき、最初にソースコード・仕様書・環境の情報の有無と、改修してよい権利を確かめます。

価格の前提と依頼から改修までの進め方は、既存システムの改修の価格（100万円〜・税別）と進め方に載せています。

今の業務と使っているシステムを共有して、改修の範囲を相談する

初回相談は無料・30分（オンライン）です。依頼書が書き切れていなくても大丈夫です。

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

依頼書の8つの欄が全部埋まっていなくても相談できます。次のものがあれば、30分で改修の範囲の候補まで話せます。

• 対象のシステムの名前と、作った会社・今の保守会社
• 直したい画面の写真（個人情報は伏せる）と、今の動き・変えたい動きのメモ
• 仕様書・ソースコード・保守契約書が手元にあるかどうか
• 使いたい時期と、その理由

当社の初回相談は無料・30分で、オンライン（Google Meet）で行います。30分では、直したいこと・使う人・今のシステムを伺い、自社でAIを使って進められる部分と任せたほうがよい部分を切り分け、依頼の形（既存システムの改修／PoC／本開発／調査のみ）の候補をお話しします。相談後に、業務の棚卸し表・効果の見立て・簡易モックと、依頼範囲の候補・進め方・費用の目安をまとめた相談メモを無料でお送りします。簡易モックは画面のイメージで、動くシステムではありません。

資料を受け取ったあとの提案と見積までは無料です。既存コードの調査報告、要件定義書の作成、PoC、開発は有償で、始める前に範囲と金額をお示しして合意をいただきます。初回の30分で確定の見積はお出ししていません。

よくある質問

Q. 改修の依頼書に、決まった書式はありますか？

決まった書式がなくても依頼できます。社内の書式があればそれで構いません。どの書式でも、「今の動き／変えたい動き／困っていること」を横に並べて書くと、変更の前後を読み違えにくくなります。

Q. 直したいことが3つあります。1枚にまとめて書いてもよいですか？

1件ごとに分けて、1件1枚にするのがおすすめです。まとめて書くと、どの変更にいくらかかるのかが見積で分かれず、予算に合わせて一部だけ頼む判断がしにくくなります。分けたうえで、表紙に優先順位（必ずやる／できればやる）を書いておくと、開発会社は優先度の高いものから範囲を組めます。

Q. 不具合を直してほしいときも、同じ依頼書でよいですか？

使えますが、「今の動き」の欄を詳しく書きます。いつ（日時）・誰が・どの画面で・どの操作をして・どう表示されたか（エラーの文言や画面の写真）を書くと、開発会社が同じ状況を再現しやすくなります。また、不具合の修正は今の保守契約の範囲に入っていることがあるので、別の会社に頼む前に保守契約書を確かめてください。

Q. 依頼書を出すと、開発会社に発注したことになりますか？

なりません。依頼書は見積のための情報で、発注は見積と契約の条件に合意したときです。誤解を避けたい場合は、依頼書の冒頭に「見積のご依頼です」と書いておきます。複数の会社に同じ依頼書を出すこともできますが、その場合は比べ方をそろえるためにRFPの形にするほうが向いています。

Q. 今の保守会社に頼む場合でも、依頼書は必要ですか？

軽い変更なら、いつもの保守の依頼の形で足ります。画面・帳票の追加やデータ連携のように範囲が広がる改修では、今の保守会社に頼む場合でも依頼書を作っておくと役に立ちます。担当者が替わっても依頼の中身が残り、別の会社の見積と比べたくなったときにも同じ1枚を渡せるからです。

Q. 期限が法改正で決まっていて、全部は間に合いそうにありません。

「8. 期限とその理由」の欄に、期限が動かせない理由と、期限までに最低限必要な動きを分けて書きます。たとえば「4月1日の時点で新しい税率で計算できること」が必須で、帳票の見た目を整えるのは後でもよい、と書いておけば、開発会社は期限に間に合わせる範囲と後回しにする範囲を分けて見積を出せます。

改修の範囲が決めきれないときは

依頼書の欄が埋まらない、どこまで直せばよいか分からない、という段階でも相談できます。今の業務の流れと使っているシステム、直したい画面を伺い、改修の範囲の候補と費用の目安を相談メモでお返しします。

今の業務と使っているシステムを共有して、改修の範囲を相談する