技術的制約は、なぜ納品直前に表面化するのか
技術的制約が遅れて表面化するのは、営業段階でそれを口にする動機が誰にもないためです。提案書や契約書は機能とスケジュールが中心で、「このシステムにできないこと」が独立した項目として書かれることはあまりありません。
開発会社にとって、制約を伝えることは提案を弱めるように感じられます。競合が「すべて対応可能です」と提案している場合はなおさらです。一方、発注側も何を確認すべきか分からなければ、照らし合わせる材料がありません。その結果、双方が暗黙のうちに受け入れる「沈黙」が生まれ、「まずは稼働させて、運用でカバーしましょう」という言葉で締めくくられます。
この沈黙は、主に次の3つの形で破綻します。
- 本番直前の費用増加：開発終盤になってDB構造が実際の負荷に耐えられないと判明し、中核部分の再設計が必要になる。
- 稼働後の障害：アクセス集中時の処理限界が一度も計測されておらず、大型キャンペーン当日にシステムが過負荷に陥る。
- AIチャットボットのハルシネーション（事実と異なる回答）：AIが回答してよいデータ範囲が定義されておらず、実際のお客様に誤った情報が伝わる。
制約が共有されないと、誰が損害を受けるのか
最初に共有されなかった技術的制約は、発注企業だけでなく、プロジェクトに関わる3者すべてに損害を与えます。
開発会社が制約を伝えない理由は、主に2つあります。案件を失うことへの不安と、制約を早期に見極めるアーキテクチャ分析力の不足です。後者のほうがより深刻です。その場合、開発会社は隠しているのではなく、本当にまだ把握できていないからです。
契約前に技術的制約を引き出す5つの質問
技術的制約を確実に把握するには、検証可能な形で直接質問することが最も有効です。以下の5つの質問は、VAONを含むどの開発会社に対してもお使いいただけます。
- 「提案内容のうち、過去のプロジェクトで実稼働済みの部分と、PoCが必要な部分はどこですか？」
良い回答は、この2つを明確に分けています。PoC（Proof of Concept、実現可能性検証）とは、本格導入の前にお客様の環境で行う試験運用です。注意すべき回答：すべての項目が「対応可能」で、検証が必要な項目がひとつもない。 - 「システムはどの程度の負荷に耐えられますか？その数値はどのように計測しましたか？」
良い回答には、数値、計測条件、計測時期が含まれています。注意すべき回答：数値のない「十分に耐えられます」、または条件の示されていない数値。 - 「AIはどのような場合に回答を控えますか？」
チャットボットやRAG（検索拡張生成）を含むすべての案件で確認すべき質問です。良い回答は、参照データの範囲と、AIが「情報がありません」と答える条件を定義しています。注意すべき回答：「AIはあらゆる質問に回答できます」。 - 「現行システムのうち、手を加えない部分はどこですか？」
レガシーシステムの刷新では、良い回答は基幹DBなどの「手を出さない領域」を明示しています。注意すべき回答：移行リスクの評価がないまま、全面的な作り直しを提案している。 - 「仕様書そのものに誤りがあった場合、修正費用はどちらが負担しますか？」
良い回答は、開発会社の仕様の誤りとお客様による仕様変更を区別し、それを契約書に明記しています。注意すべき回答：すべての追加費用がお客様負担になっている。
5つの質問すべてに書面で回答できる開発会社であれば、お客様の手元には提案書よりも価値のある資料が残ります。それが「技術的制約ドキュメント」です。
実際の「制約事項ドキュメント」はどのようなものか
良い制約事項ドキュメントは、短く、具体的で、検証可能です。以下は、VAONが自社開発した多言語対応の識別番号抽出OCRサービスについて公開している制約事項です（2026年）。
本サービスには54件の自動テストがあります。内訳は42件の単体テストと、実モデルで実行する12件の結合テストです。開発中、新しく追加したルートにアップロード容量の上限が設定されていないことが判明しました。この不具合はリリース前に修正済みで、現在は11MBのファイルが設計どおり拒否されます。制約事項は、次の3点をそのまま記録しています。
この制約事項によって、サービスの価値が下がるわけではありません。どこで使えるのか、別の用途で使うには何を追加すべきかを、利用者が正確に判断できるようになります。詳細は多言語対応 識別番号抽出OCRの事例をご覧ください。
VAONはプロジェクト文書に制約をどう記載しているか
VAONは、ご相談の段階から、機能一覧と並行して「技術的制約ドキュメント」を作成します。その内容は、次の3つの規範に基づいています。
規範①：「検証済み領域」と「PoCが必要な領域」を分けて記載する。
VAONは「確実に対応できます」という言葉を感覚で使いません。過去の案件で実稼働済みの項目は別に記載し、お客様固有の環境に依存する項目は、検証計画とあわせて「PoCが必要」と明記します。
規範②：AIチャットボット「ONEBOT」のデータ範囲と回答を控える条件を定義する。
ONEBOTの導入時、VAONはRAGが参照してよい文書の範囲と、AIが推測で答えずに「情報がありません」と回答する条件を定めます。これにより誤回答のリスクは大きく下がりますが、どのAIシステムもそのリスクを完全になくすことはできません。そのため、残るリスクについても事前にお伝えします。ONEBOT向けベトナム語OCRの事例では、抽出精度が70%から、検証済みデータセット上で誤りが確認されない水準まで向上しました。同記事では、この結果がすべての文書に当てはまるものではないことも明記しています。
規範③：レガシーシステム刷新では「手を出さない領域」を事前に提示する。
レガシーシステムに対して、VAONはStrangler Figパターン（既存部分を壊さず、周囲に新しい層を構築する手法）を採用します。[20年稼働したCMSの刷新事例](https://vaon.com.vn/ja/blog/legacy-cms-modernization-zero-downtime)では、安定稼働している基幹DBには手を加えないことを最初にお約束しました。プロジェクトは4か月で完了し、システム停止はゼロでした。この結果はあくまで同案件の規模に基づくもので、すべての案件の標準値ではありません。
これらの規範は、VAONの「仕様確定フェーズ」の一部です。仕様の誤りが原因の場合の責任分担については、「やらないこと」を先に伝える設計規律で詳しくご説明しています。
制約の開示で解決できないこと
技術的制約を開示することで想定外の事態は減らせますが、すべてのリスクがなくなるわけではありません。事前にご理解いただきたい点が3つあります。
- 制約事項ドキュメントの精度は、共有いただいた情報に左右されます。 ご相談の段階で明文化されていない業務ルールが共有されなかった場合、ドキュメントにも反映できません。
- 「PoCが必要」な領域は、依然として未知の領域です。 明記することでリスクの所在は分かりますが、PoCの結果、当初の方式が実現困難と判明する可能性はあります。
- 5つの質問は、法務・セキュリティ面の審査に代わるものではありません。 認証取得や再委託に関する要件がある案件では、別途の確認プロセスが必要です。
おわりに
制約を先に伝える開発会社は、「すべて対応可能」と約束する開発会社より弱いわけではありません。いずれ明らかになることを、早い段階でお見せしているだけです。
ソフトウェアやAIのプロジェクトをご検討中でしたら、構築予定のシステムの概要をVAONにお送りください。上記5つの質問に、お客様の案件に即して書面で回答いたします。OEMの技術パートナーをお探しのSIer・代理店様からのご相談も承っております。
無料相談で、自社案件の技術的制約を確認する: https://vaon.com.vn/ja/contact