1. 元の会社と別の会社を、引き継ぎの負担も含めて比べる
画面の項目を一つ増やすだけでも、保存先、検索、帳票、他のシステムへの連携に影響することがあります。見た目の変更量だけで「簡単な修正」と決めず、対象と影響を確認します。
| 選択肢 | 候補になる条件 | 相談で確認すること |
|---|---|---|
| 元の開発会社 | 構成や業務ルールを把握していて、必要な時期に対応できる | 保守契約内か追加見積りか、対応時期、変更後の保守範囲 |
| 別の会社 | 元の会社が対応できない、保守窓口も見直したい、別の提案を比較したい | 調査と引き継ぎの費用、動作を再現できるか、元の会社との責任分担 |
| 社内で対応 | 改修する権限があり、担当者が確認・公開・復旧・保守まで担える | 担当時間、不在時の対応、他の担当者へ引き継げる手順 |
元の会社の回答が遅い場合も、別の会社にすぐ本番環境を渡すのではなく、まず資料で対応可否を相談します。契約や必要な資料が不明なら、改修より先に確認・引き継ぎの調査を依頼する方法があります。
初めてのAI導入で社内と外部の分担を決める話は、内製・外注の判断基準で解説しています。この記事は、すでに外注して動いているシステムの改修と保守窓口の変更に絞ります。
自社の停止記録から、画面以外の影響も確認する
hirostaの自社サイトでは、2026年10月8日、運用手順のファイルを別のファイルへの参照リンクに変更したことで、自動作業の安全確認が止まりました。ページの表示を変えない変更でしたが、調査の課題は作業開始直後に停止しました。
参照リンクを含むファイルの扱いが安全確認の条件に合っていなかったため、安全確認は維持したまま、参照リンクを通常のファイルへ置き換えました。複数箇所で使う手順の内容は同じ変更で揃える、というルールも運用資料に残しました。修正の取り込みは同日11時16分15秒（日本時間）ですが、停止した調査がその後最後まで完了したかは、出典の記録では未確認です。
これは自社サイトの運用記録です。外注システムの改修や他社への引き継ぎを実施した事例ではありません。詳しい経緯はAIチームでサイトを運営した記録・第1回をご覧ください。今回、2026年10月10日に確認したのは、この記録の変更・原因・修正・未確認の範囲です。契約に関する外部資料の確認日は、出典欄の2026年10月8日のままです。
改修の相談では、この経験を「変更するファイルを、どの仕組みが読んでいるか」まで確認する判断につなげます。画面に変化がなくても、連携・定期処理・自動作業などが影響を受ける場合があります。依頼・見積りには、読む側の制約と変更後に確認する処理を含め、確認を担う人と費用の範囲を依頼先と揃えます。
2. 別の会社へ渡す前に確認する5つの項目
IPAのモデル契約は、開発と保守運用の契約を扱い、仕様や検収方法などを双方で合意するための資料です。自社の既存契約を置き換えるものではありません。以下は改修相談のために整理した確認項目で、個別契約の法的な結論を示すものではありません。
- 契約と成果物の扱い：契約書・発注書・仕様書で、成果物の範囲、権利の帰属、利用・改変・第三者への開示の条件を確認します。費用を払ったという理由だけで、自由に別の会社へ渡せると判断しません。不明な条項は契約担当者や法律の専門家へ確認します。
- ソースコードと構築手順：プログラムの元になるファイル、利用する部品とその版、設定方法、公開手順があるかを確認します。コードが手元にあっても、必要な設定や部品がなければ別の環境で動かせないことがあります。
- 管理するアカウントと権限：サーバー、ドメイン、データベース、外部連携の管理者と契約名義を確認します。依頼先へは必要な範囲の権限を個別に付与し、パスワードの共有を相談資料に含めないようにします。
- データと接続先：保存する項目、バックアップ、外部への送信・書き込み、データを取り出す方法を確認します。初期相談は画面の説明や機密を除いた資料から始め、顧客情報などの共有が必要なら目的と扱いを先に合意します。
- 保守と切り替えの分担：別の会社による変更が既存の保守にどう影響するか、障害時に誰へ連絡するかを確認します。元の会社への引き継ぎ依頼、契約終了、管理権限の整理は、復旧手段を確保してから進めます。
IPAの公開ページは、参照法規が資料公表当時の版に基づくことにも注意を促しています。モデル契約の存在だけで現在の自社契約に改修の許可があると判断せず、実際の契約と必要な法令を確認してください。この記事で確認したのは、公開ページの構成・説明・注意事項であり、添付契約書の全条項や個別案件の権利関係ではありません。
3. AIを使う場合も、確認と保守の担当を決める
AIは、コードの説明、変更案、修正の下書きなどを補助する使い方が考えられます。ただし、古い仕様や独自の業務ルールを正しく理解すること、変更後も従来の動作を保つことは、AIを使うだけでは保証されません。
依頼先には、AIを使うかだけでなく、次の点を聞きます。
- ソースコード・設定・業務資料をAIサービスへ送るか。送るなら、契約と社内ルールで許される範囲、利用サービス、保存や学習利用の条件をどう確認するか。
- AIが出した変更を誰が読み、計算・権限・外部連携への影響を確認するか。
- 本番とは分けた環境で何を確認し、誰が利用開始を承認するか。
- 公開後の不具合、元に戻す作業、依存する部品の更新を誰が担うか。
認証情報や本番データをそのままAIへ渡す進め方は避けます。情報の入力可否を決める手順は、顧客情報を生成AIへ入力する前の確認も参考になります。AIを使う契約でも、依頼先と社内の責任分担は明文化します。
4. 想定シナリオ：受注一覧に「納品予定日」を追加したい
以下は依頼の進め方を説明する想定シナリオです。hirostaや顧客が実際に行った改修・検証・成果ではありません。
外注した受注管理システムに、担当者が納品予定日を入力し、一覧とCSVへ出せるようにしたい会社を想定します。注文の確定や請求処理は従来どおり残す条件です。
まず、変更する画面と判断条件を伝える
相談内容を「日付の欄が欲しい」から、次のように具体化します。
- 入力画面：受注詳細に納品予定日を追加。未定なら空欄にできる。変更できる担当者と変更履歴の要否を決める。
- 一覧画面：受注番号・取引先・納品予定日を表示。予定日が空欄の受注をどう表示するか、絞り込みが必要かを決める。
- CSV出力：列名・日付の形式・列の位置を決める。既存CSVを取り込む別のツールがあれば、列追加の影響を確認する。
- 既存データ：過去の受注は空欄のままか、確認した予定日だけ入力するかを社内で決める。AIに予定日を推測させて埋めない。
最初の相談では、この説明と機密を除いた画面イメージ、現行の仕様が分かる資料を渡します。既存契約の条件が未確認なら、その旨も伝え、第三者への資料共有が可能かを先に確認します。
改修と調査の見積りを分ける
元の会社には追加費用と対応時期を確認します。別の会社には、まず構成調査・動作の再現・引き継ぎが必要かを聞きます。両社を比べるときは、同じ入力画面・一覧・CSV・確認範囲を対象にします。
費用は「現状調査」「画面・保存先・出力の修正」「動作確認」「公開・復旧準備」「引き継ぎ・保守」に分けて見ます。AIの利用料や環境の利用料、元の会社による資料準備が別費用になるかも確認します。資料不足がある場合は、調査の上限と、調査後に改修へ進むかを判断する区切りを決めると、発注範囲を整理できます。
期間はコードの修正時間だけでなく、資料の取得、環境の再現、社内確認、切り替え可能な日時で変わります。この記事では金額や完成日数を保証する相場は示しません。希望日を伝え、調査の回答日と改修・確認・公開の予定を分けて提示してもらいます。
本番を変える前に、戻せることを確認する
本番とは分けた環境で、日付あり・空欄・変更時の表示とCSVを確認します。業務担当者は、既存の金額・注文確定・請求処理に影響がないかを確認し、技術担当者は権限と保存・出力の動作を確認します。検証側から実際の取引先へ送信したり、本番へ書き込んだりしない接続にします。
公開前にバックアップと復旧手順を確認し、不一致や処理エラーが起きたら切り替えを止める条件を決めます。新旧の仕組みを比べる場合も、受注の更新や送信を行う側は一つに決め、二重処理を防ぎます。元のプログラムへ戻すだけでは追加・変更したデータが戻らない場合があるため、データを含む復旧方法も合意します。
検収では、修正の取り込みと業務の復旧を分ける
自社の停止記録では、修正が取り込まれた日時だけでは、調査が最後まで動いたかを判断できませんでした。改修を依頼するときも、「修正を取り込んだ」と「業務が元どおり動くことを確認した」を別の完了条件として、検収の項目に書きます。以下は依頼先との合意に使う項目で、今回の想定シナリオを実施・検収した記録ではありません。
| 完了条件 | 依頼先と合意する確認・記録 |
|---|---|
| 修正の取り込み | 合意した変更が対象環境に反映されたか。変更内容、反映した版・日時、確認者を残す |
| 業務の復旧・動作確認 | 影響を受ける処理が最後まで動き、結果が業務の条件に合うか。対象処理、確認条件・結果、確認者・日時を残す |
納品予定日を追加する想定シナリオなら、画面とCSVの変更の反映だけでなく、既存CSVを読むツールや注文確定・請求処理の確認も別項目にします。公開前の確認に加え、公開後に誰がどの処理・結果を確かめるかを決めます。確認できない項目は、未確認の範囲と確認担当を引き継ぎ資料に残し、修正の取り込みだけを理由に復旧済みと扱わないようにします。
5. 修正を重ねるか、仕組みを見直すか
改修のたびに全体の調査が必要、資料が残らない、部品の更新に対応できない、といった状態なら、小さな修正と一緒に保守体制の見直しを検討します。一方で、困りごとがCSVの整形など一工程なら、既存システムを変えずに周辺の作業を補う案も比較できます。使える出力や接続の条件は個別に確認してください。
作り直しやSaaSへの移行は、データ・履歴・操作手順の移行負担を含めて判断します。SaaS導入と個別自動化の選び方で比較の観点を整理しています。独自ルールを実装した工程の参考にWeb勤怠と給与計算の自動化の事例もありますが、AIを使わない導入事例であり、今回のような引き継ぎ改修の費用や期間を示すものではありません。
hirostaへの改修・連携の相談はシステム開発、支援内容と料金はサービス・料金をご覧ください。改修先が決まっていなくても、無料相談で今の困りごとと資料の状況から整理できます。
6. よくある質問
Q. 元の開発会社以外に改修を頼めますか？ 契約上の改修・資料共有の条件、必要なソースコードや構築手順、保守への影響を確認したうえで検討します。別の会社が対応可能かは、システムの状態と引き継げる資料によります。
Q. ソースコードがあれば、すぐに直せますか？ コードだけでは足りない場合があります。利用する部品や設定、構築・公開手順、外部連携、業務ルールを確認し、本番とは分けた環境で動作を再現できるか調べます。
Q. AIを使えば、改修は安く早くなりますか？ AIの利用だけでは判断できません。変更範囲に加え、調査・確認・引き継ぎ・保守を含む見積りで比較します。確認担当者と復旧方法も必要です。
Q. 契約書や設計書が見つからない場合は？ 発注時の担当者や元の会社に保管先・提供可否を確認し、分からない点を相談先へ伝えます。権利や管理権限を推測して本番を変更せず、先に調査範囲を決めます。