中小企業がシステム開発を外注して「思っていたものと違う」「想定の数倍のコストになった」となる失敗パターンは、昔から大きく変わっていません。ただ、Claude などの AI を開発工程に組み込む会社が増えた今、外注先を選ぶときに見るべき軸も少しずつ更新されています。この記事では、典型的な失敗7パターンと、それぞれの対策を Claude 時代の文脈で再整理します。
この記事でわかること
- システム開発外注で陥りがちな7つの失敗パターン
- 各パターンに対する具体的な対策
- 外注先を選ぶときに見るべき「Claude 時代の新しい軸」
- 見積書・契約書で必ず確認したい項目
目次
- 失敗1：要件が曖昧なまま発注し、後で大幅な追加費用
- 失敗2：見積もりが「一式」で内訳が不透明
- 失敗3：完成後の保守・運用設計が抜け落ちている
- 失敗4：担当者がコロコロ変わり、引き継ぎ漏れが頻発
- 失敗5：受け入れテストの基準が曖昧で揉める
- 失敗6：データ・ソースコードの所有権が曖昧
- 失敗7：「AI 活用」を謳うが中身が伴っていない
- Claude 時代の新しいチェック軸
- 契約前に必ず確認したい項目
- まとめ：「設計」と「保守設計」を見れば外注先の質は分かる
失敗1：要件が曖昧なまま発注し、後で大幅な追加費用
最も多い失敗が「要件が曖昧なまま発注 → 開発中に『これも欲しい』が次々追加 → 追加見積もりで当初の2〜3倍に膨らむ」というパターン。発注側に明確な要件定義の経験がないと、開発会社任せにしてしまい、後から齟齬が表面化します。
対策は「要件定義に時間とお金を惜しまない」こと。理想は 開発費の10〜20%を要件定義フェーズに振り分けること。Claude のような AI が浸透した今、要件定義の叩き台を AI に作らせて関係者で詰める、というやり方も現実的です。弊社では、初回ヒアリングを Claude を使って構造化された要件メモにまとめ、それを叩き台にステークホルダーと合意形成する進め方を取っています。
失敗2：見積もりが「一式」で内訳が不透明
「業務システム開発一式 300万円」のような大雑把な見積もりは要注意。何にいくらかかっているか不明だと、後で「あれもこれも追加料金」という事態を招きます。
対策は、見積書に「機能ごと」「工程ごと」の内訳を必ず書いてもらうこと。具体的には「要件定義 / 設計 / 実装 / テスト / 導入支援 / 保守初期」の各工程と、機能別（ログイン、ユーザー管理、データ登録、検索、レポート出力 等）の積算が見える形が望ましいです。「内訳を出してください」とお願いして渋る会社は、その時点で候補から外す判断軸として有効です。
失敗3：完成後の保守・運用設計が抜け落ちている
新規開発に注力しすぎて、納品後の「障害対応・機能追加・脆弱性対応・サーバー保守」が見積もりに入っていないケース。納品後に「保守は別契約で月15万円から」と提示され、想定外の固定費が発生します。
対策は、契約前に「納品後3年間の総コスト」を確認すること。初期開発費だけでなく、月額保守費・年次更新費・追加機能の単価まで含めた TCO（総保有コスト）で比較するべきです。Claude や AI を使った業務システムの場合、API 利用料も月額コストに乗ってくるので、これも必ず内訳に含めてもらいます。
失敗4：担当者がコロコロ変わり、引き継ぎ漏れが頻発
大手開発会社にありがちなパターンが「営業 → ディレクター → 別のエンジニア → さらに別のエンジニア」と担当が連鎖して変わり、その都度引き継ぎ漏れで「以前話したのに伝わっていない」が頻発するケースです。
対策は「ヒアリングから納品・保守まで同じ担当者が一貫対応する体制か」を契約前に確認すること。中小企業向けの外注では、エンジニアと直接話せる体制のほうが、品質も意思決定速度も上です。「営業が窓口で、エンジニアと直接話せません」という会社は、要件のニュアンスが何度も伝言ゲームで歪む傾向があります。
失敗5：受け入れテストの基準が曖昧で揉める
「動けば OK」という曖昧な納品基準で進めると、納品時に「これは仕様」「これは不具合」で揉めます。特に AI を組み込んだシステムでは「期待した精度が出ない」を不具合とするか仕様内とするかの線引きが難しい領域です。
対策は、受け入れテスト項目（テストケース）を発注時点で合意しておくこと。Claude を使った業務システムなら、たとえば「特定の入力に対して期待される出力カテゴリが◯◯％以上の精度で返ること」のような 定量的な受け入れ基準を契約書に明記する。曖昧な「最善を尽くす」では事故の元です。
失敗6：データ・ソースコードの所有権が曖昧
納品物の所有権（ソースコードの著作権、データベース、AI モデルのプロンプト等）が契約書で明確化されていないと、後で他社に乗り換えるとき・自社で保守を引き受けるときに「ソースは渡せません」と言われるリスクがあります。
対策は、契約書の「成果物の権利帰属」条項を必ず確認し、納品物のソースコード一式・設定ファイル・Claude のプロンプト（system プロンプト等）・データベーススキーマ・運用ドキュメントが発注側に帰属することを明記すること。OSS ライセンス制約のある部分は別途明示してもらいます。Claude を使ったシステムでは「プロンプトエンジニアリングの成果物」も重要な資産なので、ここの権利関係は最重要です。
失敗7：「AI 活用」を謳うが中身が伴っていない
近年急増しているのが「AI 活用開発」「Claude 対応」を謳いつつ、実際は外注先に丸投げ・既製の SaaS を紹介するだけ、というケースです。発注側に AI の知識がないと見抜きづらく、料金だけ高く・品質は伴わない、という事態を招きます。
対策は、契約前に「具体的にどの Claude モデル（Opus / Sonnet / Haiku）を使うか」「Anthropic API か別の SaaS か」「Prompt Caching や Batch API のような最適化機能を使うか」を質問してみること。これらに即答できない会社は、AI を実装した経験が乏しいと判断していい指標です。逆に、モデル選定の理由・コスト試算・代替案まで説明できる会社は、実装経験があります。
Claude 時代の新しいチェック軸
従来の外注先選定軸（実績数・価格・人数 等）に加えて、AI 時代に新しく重要になった軸が4つあります。
1つ目は Claude Code 等の AI 開発ツールを実務で使っているか。Claude Code を活用している会社は、設計から実装までの工数が大幅に圧縮されており、その分料金を抑えられる傾向があります。「うちは AI を使って効率化しています」と言う会社には、具体的なツール名と使い方を聞いてみると判断できます。
2つ目は API キー・モデル選定の説明力。Anthropic Console での API キー管理、ワークスペース分離、利用量モニタリングといった運用面の知識があるかどうか。これらは Claude を本番運用する上で避けて通れない要素です。
3つ目は ハルシネーション・暴走対策の説明。Claude が誤った出力をするケース、エージェント型実装でループが暴走するケースに対して、どんな安全弁を設計しているか。max_turns やコスト上限、Citations での根拠提示、人間の最終確認フローなどを明確に説明できるかが判断材料です。
4つ目は 運用後の API コスト管理体制。Prompt Caching の活用、Batch API の使い分け、月次の利用量レビュー等を運用に組み込めているか。Claude のコストは構成次第で 1/10 まで変わるので、ここの設計力が長期 TCO を左右します。
契約前に必ず確認したい項目
外注契約を結ぶ前に、最低限以下を書面で確認しておきます。
- 機能ごとの内訳見積もり（「一式」を避ける）
- 3年 TCO（初期 + 月額保守 + API 料金 + 追加機能単価）
- 担当者の一貫対応の有無（営業 → 別エンジニアの伝言ゲーム回避）
- 受け入れテスト基準（定量的な合格基準）
- 成果物の権利帰属（ソース・プロンプト・データ）
- 使用する Claude モデル・API・周辺機能の明示（AI 部分の透明性）
- API コストの月次見積もり（変動費の予測）
まとめ：「設計」と「保守設計」を見れば外注先の質は分かる
システム開発外注の失敗の大半は、契約前の「要件定義」「保守設計」「権利関係」の3点を曖昧にしたまま発注したことに起因します。価格の安さや実績数だけで選ばず、これら3点について 具体的な質問にすぐ答えられる会社を選ぶのが鉄則です。
Claude 時代に入って「AI 活用度」「モデル選定の説明力」「コスト管理体制」といった新しい軸も加わっていますが、本質は変わりません。質問を投げて、その応答の具体性・誠実さを見ることが、外注先選びの最良の判断材料です。
弊社では中小企業さま向けに Claude を中心とした業務システム開発を行っています。要件定義のフェーズだけでもご相談いただけますので、これから外注を検討される方は、お気軽にお問い合わせください。
