バグ管理ツールの選び方｜小規模な開発で使う場合

バグ管理ツールを探している人の多くは、不具合の報告がメールやチャットに散らばり、どれが直ってどれが残っているのか分からなくなっています。結論から言うと、小規模な開発でツールを選ぶときに最初に決めるのは製品名ではなく、1件のバグに何を書き、どの状態を経て閉じるのかという記録の型です。型が決まっていれば、スプレッドシートでも専用の製品でも回ります。この記事では、記録する項目と状態の流れ、スプレッドシートで足りる場面、GitHub Issues、Jira、Backlog、Redmineなどの特徴と料金、外注先や業務委託の開発者とバグをやり取りするときの注意までを順に整理します。開発者でないメンバーも一緒に不具合と対応を追いかけたい場合の道具の1つとして、国産のプロジェクト管理ツールPinatecaの使いどころにも後半で触れます。

バグ管理とは何か、なぜ専用の仕組みが要るのか

バグとは、ソフトウェアが作った人の意図どおりに動かない不具合のことです。画面が崩れる、ボタンを押しても反応しない、計算の結果がずれる、といったものが代表的な例です。バグ管理とは、見つかったバグを1件ずつ記録し、誰が直すのか、いまどこまで対応したのか、本当に直ったのかを、閉じるまで追いかけることを指します。

小規模な開発では、最初はメールやチャットでバグを報告し合っても困りません。ところが、件数が10件、20件と増えてくると、次のような問題が出てきます。

• 同じバグが別々の人から報告され、二重に対応してしまう
• 「直した」と言われたバグが、実は別の環境では直っていなかった
• 報告したはずのバグが、誰の担当にもならないまま忘れられる
• 公開の直前になって、どのバグが残っているのかを誰も答えられない

こうした問題を防ぐために、バグを1件ずつ番号で区別し、担当と状態と履歴を記録する仕組みが使われます。この仕組みを、ソフトウェアの世界では「バグ管理システム」や「課題管理システム」と呼びます。1件のバグを「チケット」や「課題」、「イシュー」と呼ぶ製品もあります。

規模が大きなシステムでは、バグの件数が膨大になります。業務システムの開発会社の解説では、次のように書かれています。

規模の大きなシステムでは障害登録数が1万件を超えることもあります。登録数が多いと後で特定の機能の障害だけ見たいという場合に探すのが大変なので、任意のキーワード検索できる必要があります。 出典: products.sint.co.jp

小規模な開発では、ここまでの件数にはなりません。それでも、検索できること、機能ごとに絞り込めることは、件数が数十件の段階から役に立ちます。

1件のバグに記録する項目

バグ管理でいちばん大事なのは、1件ごとに何を書くかを決めておくことです。書き方がばらばらだと、直す人が状況を聞き返す手間が増えます。小規模な開発で最低限そろえておきたい項目は、次のとおりです。

項目	書く内容の例
件名	「会員登録の画面で、確認のメールが届かない」
再現の手順	どの画面で、何を入力し、どのボタンを押したか
期待した結果	本来どうなるはずだったか
実際の結果	実際にどうなったか。エラーの表示があればその文言
環境	端末、OS、ブラウザとその版、本番か試験の環境か
重要度	利用者への影響の度合い
優先度	いつまでに直すか
担当	直す人
状態	いまどの段階にあるか
添付	画面の写真や動画

特に「再現の手順」「期待した結果」「実際の結果」の3つは、どれか1つでも欠けると、直す人が困ります。「ボタンが動かない」とだけ書かれた報告では、どの画面のどのボタンか、どう動くはずだったのかが分かりません。報告する人には、この3つを書いてもらうことを最初に伝えておきます。

重要度と優先度は、似ていますが分けて考えます。重要度は、利用者にどれだけ影響があるかです。たとえば、支払いができないバグは重要度が高く、説明文の誤字は重要度が低くなります。優先度は、いつまでに直すかです。重要度が低い誤字でも、明日の公開のページにあれば優先度は高くなります。2つを分けておくと、限られた時間で何から手を付けるかを判断しやすくなります。

状態の流れを決める

次に、バグが報告されてから閉じるまでの状態の流れを決めます。小規模な開発なら、次の5つ程度で十分です。

1. 新規。報告されたが、まだ誰も確かめていない
2. 対応中。担当が決まり、原因を調べたり直したりしている
3. 確認待ち。直したので、報告した人や試験をする人に確かめてもらう段階
4. 完了。直ったことが確かめられた
5. 対応しない。仕様どおりだった、再現しなかった、今回は直さないと決めた

大事なのは、3つ目の「確認待ち」を設けることです。直した人が自分で完了にすると、別の環境では直っていなかった、という見落としが起きます。直した人とは別の人が確かめて、初めて完了にする、という流れにしておくと、直ったつもりのバグが残りにくくなります。

5つ目の「対応しない」も大事な状態です。報告されたものがすべてバグとは限りません。仕様どおりの動きだったものや、再現できなかったものを、いつまでも「新規」のまま残しておくと、一覧が膨らんで本当に直すべきバグが埋もれます。理由を書いたうえで「対応しない」にして閉じることで、一覧を健全に保てます。

状態を動かすのは誰か、も決めておきます。「対応中にするのは担当者」「確認待ちにするのは直した人」「完了にするのは確かめた人」と決めておけば、状態の変化がそのまま作業の受け渡しの合図になります。

スプレッドシートで足りる場面と、足りなくなる合図

関わる人が2〜3人で、バグの件数が数十件程度なら、ExcelやGoogleスプレッドシートでも管理できます。先に挙げた記録の項目を列にし、状態の列はプルダウンで選べるようにします。番号の列を作って1件ずつ番号を振っておけば、「12番のバグ」のように会話の中で区別できます。費用がかからず、誰でも開ける点が強みです。

ただし、次のような合図が出てきたら、専用の道具に移る時期です。

• 1件のバグについてのやり取りが長くなり、セルの中に収まらない
• 画面の写真や動画を添付したいが、表では扱いにくい
• 担当が替わったときに、過去の経緯を追えない
• 複数の人が同時に表を書き換えて、行がずれる
• 担当になったことや、状態が変わったことを、本人に知らせる手段がない

専用の道具は、1件ごとにコメントの履歴が残り、添付ができ、担当者に通知が届く点が表と違います。バグを1件ずつ追いかけて記録する仕組みについては、課題管理の製品の提供元が次のように説明しています。

バグを1件毎に履歴管理、詳細な情報「今のバグ数」「対応状況」「期限」「担当者別」など簡単に把握することが可能 出典: tracpath.com

表から移るときは、表の列の名前と状態の段階を、そのまま新しい道具に持ち込むと、メンバーが戸惑わずに済みます。

代表的なバグ管理ツールの特徴と料金

小規模な開発でよく使われる製品の特徴と料金を、2026年11月3日に各社の公式ページで確かめた内容で整理します。料金は改定されることがあるので、契約の前には必ず公式ページで最新の表示を確かめてください。

製品	無料の範囲	有料の表示（最も安いもの）	向いている場面
GitHub Issues	無料のプランで使える	有料プランは機能の追加	ソースコードをGitHubで管理している開発
Jira	10ユーザーまで	Standard 1ユーザーあたり月額1,250円からの表示	開発の手法に沿って細かく管理したいチーム
Backlog	10ユーザー・1プロジェクトまで	スターター 月額2,700円（税抜）	日本語の画面で課題とガントをまとめて扱いたいチーム
Redmine	無料のオープンソース	自分のサーバーで動かす費用	自前のサーバーで管理したいチーム

GitHub Issuesは、ソースコードを管理するサービスのGitHubに組み込まれたバグ管理の仕組みです。GitHubのドキュメントでは、Issueでバグの報告や新しい機能、アイデアなどを追跡できること、テンプレートやフォームを使って報告に必要な情報を書いてもらえることが説明されています。ソースコードの修正とバグを結び付けられるので、コードをGitHubで管理しているなら最初の候補になります。一方で、開発者でない人には画面や用語がなじみにくいことがあります。

Jiraは、ソフトウェア開発の課題管理で広く使われている製品で、10ユーザーまでは無料で使えます。状態の流れや項目を細かく設定でき、開発の手法に沿って運用したいチームに向いていますが、設定の自由度が高い分、最初の設計に時間がかかります。

Backlogは国産の課題管理の製品で、日本語の画面で使え、公式の料金ページによると、カンバンボードやドキュメントの機能がスタータープランから、ガントチャートがスタンダードプランから使えます。ただし、公式ブログで大きな変更が告知されています。2026年12月31日で現在のプランの新規契約が終わり、2027年1月1日から「エコノミー」「ビジネス」「プロフェッショナル」の3つのプランに変わります。エコノミーは月払いで月額21,000円（税抜、15ユーザー・30プロジェクトまで）です。フリープランのユーザー上限も10名から5名に変わります。これからBacklogを選ぶなら、2027年1月からの新しいプランの告知を読み、改定後の料金で比べてください。

Redmineは、オープンソースのプロジェクト管理の仕組みで、自分のサーバーに入れて使います。Redmineの公式サイトによると、GNU General Public License v2のもとで公開されており、課題の追跡、ガントチャート、カレンダー、時間の記録、カスタムフィールドなどの機能を持っています。ソフトウェア自体の費用はかかりませんが、サーバーの用意と、更新や保守の手間がかかります。保守を引き受ける人がいない小規模なチームでは、この手間が負担になることがあります。

小規模な開発でのバグ管理ツールの選び方のポイント5つ

製品を比べるときは、機能の一覧より、自分たちのチームに照らして次の5つを確かめるほうが、選び直しが少なくて済みます。

1. 誰が報告するか。開発者だけが報告するのか、営業や顧客対応の担当、発注した会社の人も報告するのか。開発者でない人が報告するなら、画面と用語の分かりやすさを優先する
2. ソースコードとの結び付き。修正のコードとバグを結び付けたいなら、コードを管理しているサービスと連携できるかを確かめる
3. 人数と料金の増え方。いまの人数で無料に収まるか、ゲストや閲覧だけの人が料金の人数に数えられるか
4. 記録の型を作れるか。この記事の前半で挙げた記録の項目を、テンプレートやカスタムの項目として用意できるか。報告のたびに書く内容がそろうかどうかが、バグ管理の質を決める
5. やめるときの出口。データを書き出せるか。料金の改定や提供の終了は実際に起きるので、移れる道を残しておく

迷ったら1を優先してください。小規模な開発では、バグを見つけるのは開発者よりも、実際に画面を触る営業や顧客対応の担当であることが多くあります。その人たちが迷わずに報告できる道具でなければ、バグは結局チャットで報告され、道具の外に散らばります。

バグ管理ツールを導入する手順

使う製品を決めたら、次の順番で導入すると、メンバーが迷わずに使い始められます。

1. 状態の流れと項目を決める。この記事の前半で挙げた5つの状態と、記録する項目を、製品の設定に反映する
2. 報告のテンプレートを用意する。次の節で紹介する形を、新しく登録するときの書式に設定する
3. いま残っているバグを移す。メールやチャットに散らばっている未解決のバグだけを登録し直す。解決済みのものは移さない
4. 報告の窓口を1つにすると伝える。「今日からバグはこの道具に登録する。チャットで報告されたものも、受けた人が登録する」と全員に伝える
5. 2週間後に見直す。登録されていない報告がないか、使われていない項目がないかを確かめ、設定を調整する

特に4つ目が大事です。道具を入れても、チャットでの報告を受け付け続けると、報告は二か所に分かれます。チャットで報告されたら、受けた人が道具に登録し、そのリンクをチャットに返す、というルールにしておくと、報告する人も自然に道具を使うようになります。

最初からすべての機能を使おうとしないことも大事です。自動で担当を割り振る、状態が変わったら別の道具に知らせる、といった機能は便利ですが、運用が固まる前に設定すると、後で直す手間が増えます。最初の1か月は基本の項目と状態の流れだけで回し、必要が見えてから機能を追加していきます。

バグ報告のテンプレートを用意する

道具を決めたら、報告のテンプレートを用意します。テンプレートとは、報告のたびに書く項目をあらかじめ並べておいたひな形のことです。多くの製品では、新しいバグを登録するときに、決まった書式が最初から入った状態にできます。

小規模な開発で使いやすいテンプレートの例を挙げます。

• 何をしようとしたか
• 再現の手順（1. 2. 3. と番号を振って書く）
• 期待した結果
• 実際の結果
• 発生した日時
• 端末とブラウザ
• 画面の写真や動画

テンプレートがあると、報告する人は空欄を埋めるだけで必要な情報を書けます。直す人は、聞き返さずに原因の調査を始められます。報告と確認の往復が1回減るだけで、1件のバグにかかる時間は大きく変わります。

テンプレートは、使いながら見直します。「いつも環境の欄が空になっている」と分かったら、選択肢から選べる形にする、といった調整を1か月ごとに行うと、報告の質がそろっていきます。

週に1回の振り分けで一覧を健全に保つ

バグ管理の道具を入れても、報告がたまる一方で誰も整理しないと、一覧はすぐに使い物にならなくなります。小規模な開発でおすすめなのが、週に1回、30分ほどの「振り分け」の時間を設けることです。振り分けとは、新しく報告されたバグを見て、重要度と優先度と担当を決める作業のことで、開発の現場では「トリアージ」と呼ばれることもあります。

振り分けでは、次の順番で一覧を見ます。

1. 「新規」のバグを1件ずつ開き、再現の手順で実際に再現するかを確かめる
2. 再現したものには重要度と優先度を付け、担当を決めて「対応中」に移す
3. 再現しないもの、仕様どおりのものは、理由を書いて「対応しない」にする
4. 情報が足りないものは、報告した人に質問を書き、返事を待つ
5. 「確認待ち」のまま1週間以上たっているものは、確かめる人に声をかける

振り分けに参加するのは、開発の責任者と、報告を受けることが多い担当の2人程度で十分です。全員で集まる必要はありません。

この作業を毎週続けると、一覧には「誰かが対応している」か「対応しないと決めた」バグだけが残り、誰の担当でもないバグがなくなります。公開の前に慌てて残りのバグを数える、ということも減ります。振り分けの時間を取るのは手間に見えますが、報告がたまってから一度に整理するより、毎週少しずつ片づけるほうが、結果として時間はかかりません。

顧客から届く不具合の報告を受け付ける流れ

公開しているサービスでは、利用者や顧客から不具合の報告が届きます。この報告をバグ管理にどうつなぐかを決めておかないと、問い合わせの窓口とバグの一覧の間で情報が途切れます。

小規模な会社で使いやすい流れは、次のとおりです。

1. 問い合わせの窓口で報告を受け取る。担当が、まず受け付けたことを顧客に返事する
2. 担当が、報告の内容を再現の手順と環境の形に整理して、バグの一覧に登録する。顧客からの報告であることと、問い合わせの番号などの照合できる情報を書いておく
3. 開発者が振り分けで重要度と優先度を決め、対応する
4. 直ったら、担当がバグの一覧の状態を見て、顧客に直ったことを知らせる

ここで大事なのは、顧客とのやり取りと、開発者とのやり取りを分けることです。開発者が直接顧客とやり取りすると、技術的な説明が顧客に伝わりにくく、開発者の作業も中断されます。顧客への窓口は担当が持ち、開発者とはバグの一覧を通してやり取りする、という分担にしておくと、双方の負担が減ります。

また、顧客の個人情報をバグの一覧にそのまま書き写さないことも大事です。再現に必要なのは、操作の手順と環境であって、顧客の氏名や連絡先ではありません。開発者や業務委託の人が見る場所には、照合に必要な最小限の情報だけを書いておきます。

バグを減らすための振り返り

バグ管理の目的は、バグを直すことだけではありません。たまった記録を振り返れば、同じ種類のバグが起きにくい作り方に変えていくことができます。

振り返りは、1か月か、大きな公開の後に1回行います。完了したバグの一覧を見て、原因をいくつかの種類に分けます。たとえば、仕様の伝え方のずれ、入力の確認の漏れ、特定のブラウザでの表示の崩れ、修正による別の箇所への影響、といった分け方です。

種類ごとに件数を数えると、どこに手を打てばよいかが見えてきます。仕様の伝え方のずれが多ければ、開発に入る前の打ち合わせで画面の動きを確かめる時間を取る。特定のブラウザでの崩れが多ければ、公開前に確かめるブラウザの一覧を決める。修正による別の箇所への影響が多ければ、修正の後に確かめる項目の一覧を作る。このように、記録から次の手を決めるのが振り返りの目的です。

振り返りは、誰かのミスを責める場にしないことが大事です。「誰がバグを作ったか」を問うと、次からは報告や記録をためらう人が出てきます。見るのは人ではなく、仕組みのどこに穴があったかです。

開発者でないメンバーとバグと対応を共有したい場合

小規模な会社では、開発者と、営業や顧客対応の担当が、同じ不具合を追いかける場面がよくあります。顧客から届いた不具合の報告を担当が受け取り、開発者に渡し、直ったら担当が顧客に知らせる、という流れです。この場合、開発者向けの製品だと、開発者でないメンバーが画面に慣れず、結局はチャットで「あの件どうなりましたか」と聞くことになりがちです。

こうした場面で、開発者でないメンバーも含めて、不具合の対応を担当と期限つきで共有したいときの候補の1つがPinatecaです。公式の料金ページによると、5人までのチームなら期限なしで無料で、ボードは10個まで作れ、クレジットカードの登録も要りません。カンバン、ガントチャート、カレンダー、リストなど8種類のボードと、チャット、カードごとのコメント、カスタムフィールドが無料プランから使えます。6人目、または11個目のボードからはスタンダードプランで、1人あたり月額500円（年払いなら1人あたり月額400円、税抜）です。閲覧だけのゲストは人数に数えない、と料金ページに書かれています。Pinatecaは、@SOHOを運営する株式会社ライフスケープが開発・提供しています。

使い方の例を挙げます。「不具合の対応」のボードをカンバンで作り、列を「新規」「対応中」「確認待ち」「完了」「対応しない」にします。1件の不具合を1枚のカードにし、担当者と期限を付け、重要度と優先度、環境はカスタムフィールドで項目を追加します。画面の写真はカードに添付し、開発者とのやり取りはカードのコメントに残します。顧客対応の担当は、カードの列を見るだけで、顧客に「直りました」と伝えてよいかを判断できます。

なお、Pinatecaはソースコードの修正とバグを自動で結び付けるような、開発者向けの専用の機能を持つ製品ではありません。開発者だけで使い、コードとの結び付きを重視するならGitHub IssuesやJiraが向いています。開発者でないメンバーも含めて、不具合の対応を担当と期限で追いかけたい場合の選択肢として考えてください。

外注先や業務委託の開発者とバグをやり取りするときの注意

小規模な開発では、開発の一部または全部を、外部の開発会社や業務委託のフリーランスに頼むことがよくあります。このとき、バグのやり取りで食い違いが起きやすいので、次の点を最初に決めておきます。

1つ目は、どこに報告するかです。発注する側のバグ管理の道具に開発者を招くのか、開発者側の道具に発注する側が報告するのかを決めます。メールとチャットと道具の3か所に報告が分かれると、漏れの原因になります。どちらの道具を使う場合も、相手に見せる範囲は、そのプロジェクトに関わる情報だけに絞ります。

2つ目は、何をバグとして扱うかです。発注する側が「バグ」だと思っていても、開発者から見ると「最初の仕様にない追加の要望」であることがあります。バグとして無償で直すのか、追加の作業として別に見積もるのかで、費用が変わります。報告するときは、仕様書や画面の設計のどの部分と違うのかを添えると、話がかみ合いやすくなります。

3つ目は、納品の後のバグをどう扱うかです。納品から何か月の間に見つかったバグを、どの範囲まで直してもらえるのかは、契約によって変わります。契約を結ぶ前に、修正の範囲と期間、追加の作業の扱いを確かめ、書面に残しておくのが安全です。法的な扱いは契約の内容や事情で変わるので、判断に迷うときは専門家に相談してください。

4つ目は、確認の担当です。開発者が直した後、本当に直ったかを確かめるのは発注する側の役目になることが多くあります。確認待ちの状態のバグを誰がいつまでに確かめるかを決めておかないと、確認待ちのまま何週間も残ることがあります。

公開の前後にバグの一覧をどう見るか

バグ管理の道具は、日々の記録だけでなく、公開の判断にも使います。公開の前には、残っているバグの一覧を重要度の順に並べ、公開してよいかを判断します。

判断の目安としては、「支払いやログインなど、利用者が目的を果たせなくなるバグが残っていないか」「個人情報が誤って表示されるようなバグが残っていないか」を最初に確かめます。こうした重要度の高いバグが1件でも残っていれば、公開を延ばすか、その機能を外して公開するかを検討します。重要度の低いバグは、公開後に直す予定を立てたうえで、公開してよいと判断することもあります。

公開の後は、利用者からの報告でバグが見つかることが増えます。公開の直後の1〜2週間は、新しいバグの一覧を毎日見て、重要度の高いものから対応します。同じバグについて複数の報告が届くこともあるので、新しい報告を登録する前に、似たバグがすでに登録されていないかを検索する習慣を付けておくと、二重の対応を防げます。

1人で開発するフリーランスのバグ管理

業務委託で開発を請け負うフリーランスが、1人で複数の取引先の開発を抱えている場合も、バグ管理の仕組みは役に立ちます。取引先ごとにバグの報告がメールやチャットで届くと、どの取引先のどのバグが残っているのかを頭の中だけで覚えておくのは難しくなります。

1人で使う場合は、取引先ごとにプロジェクトを分け、それぞれに同じ状態の流れと項目を設定しておくと、取引先が変わっても同じ手順で対応できます。ソースコードをGitHubで管理しているなら、取引先ごとのリポジトリのIssueで管理するのが手軽です。

取引先から届いた報告を自分で登録するときは、届いた文面をそのまま貼るのではなく、再現の手順と期待した結果と実際の結果に書き直しておきます。書き直す途中で情報が足りないことに気づけば、その場で取引先に質問できます。

また、直したバグの記録は、取引先への報告にも使えます。「今月はこの5件を直しました」と一覧で伝えれば、作業の内容が伝わりやすく、請求の根拠にもなります。記録が残っていれば、同じ取引先から似た不具合が届いたときに、過去の対応を探す時間も短くなります。

発注する側と開発する側の両方を見てきた運営者の視点

2004年から在宅ワークとフリーランスの仲介を続けてきた運営者として見てきた限りでは、業務委託で開発を頼む取引が長く続くかどうかは、不具合のやり取りの型が最初に決まっているかで大きく変わります。どこに報告し、何を書き、誰が確かめて閉じるのかが決まっていれば、発注する側は安心して任せられ、受ける側は聞き返しに時間を取られずに済みます。中間の手数料が乗らない直接の取引では、同じ予算で発注する側はより多くを頼め、受ける側の手取りも厚くなりますが、その関係を支えているのは、こうした地道な記録の型です。

小規模な開発の外注やバグ対応の仕事については、アプリケーション開発のお仕事で、どのような依頼があり、どのような経験が求められるかを紹介しています。セキュリティに関わる不具合の調査や対策の仕事に関心がある場合は、AI・マーケティング・セキュリティのお仕事も参考になります。開発の工程の管理やツールの導入を支援する仕事については、AIコンサル・業務活用支援のお仕事で紹介しています。

バグ管理ツールは、製品の名前より、1件ごとに書く項目と、閉じるまでの状態の流れを決めることで効果が決まります。まずは今あるバグを10件だけ選び、この記事の項目で書き直して、どの道具で回すのが合うかを試すところから始めてください。

よくある質問

Q. 小規模な開発でもバグ管理ツールは必要ですか？

関わる人が2〜3人で件数が数十件程度なら、スプレッドシートでも管理できます。1件のやり取りがセルに収まらない、画面の写真を添付したい、担当が替わると経緯が追えない、といった問題が出てきたら専用の道具を検討します。大事なのは道具より、件名、再現の手順、期待した結果、実際の結果などの記録の型を決めることです。

Q. 無料で使えるバグ管理ツールはありますか？

2026年11月時点の公式の案内では、GitHub IssuesはGitHubの無料のプランで使え、Jiraは10ユーザーまで無料、Backlogは10ユーザー・1プロジェクトまでのフリープランがあります。Redmineはオープンソースでソフトウェアは無料ですが、サーバーの費用と保守の手間がかかります。Backlogは2027年1月からフリープランの上限が5名に変わる予定です。

Q. 重要度と優先度はどう違うのですか？

重要度は利用者への影響の度合い、優先度はいつまでに直すかです。支払いができないバグは重要度が高く、説明文の誤字は重要度が低いのが一般的です。ただし、誤字でも明日公開するページにあれば優先度は高くなります。2つを分けて記録しておくと、限られた時間で何から手を付けるかを判断しやすくなります。

Q. 外注先とバグのやり取りで揉めないためにはどうすればよいですか？

報告の場所を1か所に決め、仕様書のどの部分と違うのかを添えて報告します。バグとして無償で直すのか、追加の作業として見積もるのかで費用が変わるため、契約の前に修正の範囲と期間、追加の作業の扱いを確かめて書面に残しておくのが安全です。直した後の確認を誰がいつまでに行うかも決めておきます。