本ブログでは、 AWS Summit Japan 2026 （2026年6月25日〜26日、幕張メッセ）の Physical AI ブースで展示するデモを題材に、AWS のクラウドサービスと産業用ロボットを組み合わせた自律オペレーションの実現方法をご紹介します。 はじめに Physical AI とは、ハードウェアを通じて物理世界を知覚し、ソフトウェア側で理解・推論・学習を行い、再びハードウェアを通じて物理世界に働きかける技術です。テキストの内容を返すデジタル AI とは異なり、ロボットやヒューマノイド、AGV といったハードウェアを通じて、物理的なアクションを自律的に実行します。AI とロボティクスの双方が同時に進化しブレークスルーを迎えた今、製造・物流・インフラ管理など、あらゆる産業の現場オペレーションが変革されようとしています。 従来の産業用ロボットは事前にすべての動作をプログラミングする必要があり、予期せぬ状況や形状が変化する対象物には対応できないという壁がありました。Physical AI は状況を自ら判断し、不確実性の高い環境にも適応できます。ここに、AI エージェントが自律的に「調査し、判断し、実行する」能力が加わることで、真に自律的なオペレーションが可能になります。 Physical AI とは — Agentic AI が現実世界に出るとき 本デモにおける Physical AI の中核 — Agentic AI 本デモにおける Physical AI の中核は、AI エージェント（Agentic AI）です。ソフトウェアの世界で発展してきたエージェントの能力 — ツール呼び出し、メモリへの学習蓄積、計画立案と実行 — を、カメラやセンサーによる「知覚」とロボットアームや自律走行車両による「行動」へと拡張し、知覚 → 判断 → 行動のループを自律的に回します。 なぜ今 Physical AI なのか Physical AI が注目される背景には、いくつかの技術的ブレークスルーがあります。 LLM の推論能力の飛躍的向上 — 複雑な状況判断や計画立案が可能に Agentic AI フレームワークの成熟 — ツール呼び出し、メモリ管理、マルチエージェント協調が実用レベルに クラウド-エッジ連携の高度化 — 低遅延通信と安全な制御の両立 協働ロボットの普及 — 人と同じ空間で安全に動作するロボットが入手可能に これらが揃った今、AI エージェントが現実世界で自律的にオペレーションを遂行する時代が到来しています。 デモコンセプト — 「知らない状態」から自律的に解決する 概要 現実世界とつながった AI エージェントが、想定外の障害に対して自ら調査し、自ら考え、ロボットを動かして解決する。 私たちが構築したデモは、空想の街に Amazon のラストワンマイル配送を模した配送網を作り、来場者が自由に障害を仕掛けることで、AI エージェントの自律的な問題解決能力を体験してもらうものです。 重要なのは、これが 事前にプログラムされたシナリオではない という点です。来場者が自由に障害物を配置するため、毎回異なる状況が発生します。AI エージェントは障害の存在も位置もあらかじめ知らない「ゼロ」の状態から、調査・判断・実行を自律的に回していきます。 来場者体験の設計 来場者の目の前には2つの画面が並びます。 画面 内容 AI エージェントの思考 AI エージェントがいま何を考え、次に何をしようとしているかをリアルタイム表示 AI が認識している世界 AI エージェントが現時点で認識している世界。調査が進むにつれて実際の状態に近づく この2つを見比べることで、AI がまだ何を知らず、いま何を考え、どう行動しようとしているかが一目でわかります。リアルタイムダッシュボードではエージェントの調査計画・復旧方針が逐次可視化されます。 デモフロー — 5ステップの自律オペレーション デモは1サイクル約3〜4分で、以下の5ステップで進行します。 Step 1: 通常配送（デモの起点） 空想の街で、配達車両（TurtleBot）が物流・倉庫エリアから配送先へルートを巡回しています。配送網は正常に動いており、来場者にはまずこの「通常状態」を見てもらいます。 Step 2: 来場者が障害を発生させる 来場者が配送ルート上に障害物を配置すると、配達車両が障害物を検知して停止し、配送が止まります。障害の場所は来場者が自由に決めるため、毎回パターンが異なります。 Step 3: AI エージェントが調査を開始する 配送停止を検知した AI エージェントが、障害の特定に動き出します。FANUC CRX-20iA/L 協働ロボットのアーム先端カメラ（FRAMOS D435e）でトラブルが起きた通りを探索し、段階的にデータを収集します。 以下のループで段階的に進みます。 周辺調査 — トラブルが起きた通りをカメラで撮影する 認識の更新 — 得られたデータをもとに AI が自分の地図を更新する 次の調査計画 — 追加で調べるべき箇所があるかを判断する 一発で全容がわかるわけではなく、このループを繰り返しながら障害を見極めます。 Step 4: 復旧の実行 障害物を特定した AI エージェントが、FANUC ロボットに除去を指示します。ロボットが障害物を把持し、ステージ上の回収エリアへ移動させることで道路を開通させます。把持できない障害物を発見した場合は、オペレーターに支援を要請します。 Step 5: 配送再開 復旧が完了すると、AI エージェントは配達車両に配送再開の指示を出します。来場者が止めた配送網が、目の前で復旧されます。 システムアーキテクチャ 設計原則 本システムは以下の原則に基づいて設計されています。 知性が必要な処理はクラウドで実行 — 物体認識、コンテキスト判断、アーム制御指示、車両の再開指示は LLM の推論力を活かしクラウドから発行 物理的な動作実行はエッジで処理 — クラウドからの指示を受けたモーションプランニング（MoveIt 2）やセンサー処理はエッジ PC 上で実行 通信断に耐える設計 — クラウドとの通信が切れた場合、アームは安全停止し、復旧後にクラウドから再開指示を受ける 全体構成 ▲ 知性が必要な処理はクラウド（Amazon Bedrock AgentCore / Amazon Bedrock / Amazon Polly）で実行し、物理的な動作実行はエッジ（ROS 2 / MoveIt 2）で処理。AWS IoT Core がクラウドとエッジをセキュアに接続します。 通信方式 通信経路 プロトコル 理由 FANUC ロボット AI エージェント AWS IoT Core（MQTT 5）Request/Response 低遅延・双方向制御。TLS 相互認証による安全性 配達車両 クラウド AWS IoT Core（Device Shadow） Named Shadow で走行状態・停止/再開・バッテリー・温度などを管理 ダッシュボード UI クラウド AWS IoT Core（MQTT 5）+ HTTPS エージェントの思考過程をリアルタイムに配信 使用する AWS サービス Amazon Bedrock AgentCore Runtime — AI エージェントの実行基盤 Amazon Bedrock AgentCore は、AI エージェントをインフラ管理不要でデプロイ・運用できるマネージドサービスです。本デモでは、AgentCore Runtime 上で動作する AI エージェントが、推論モデルに Amazon Bedrock の Claude Sonnet 4.6 を使用し、ツール呼び出し（ロボット制御 API）、メモリ（調査結果の蓄積）、データ（地図情報）を統合的に管理して、調査計画の立案から復旧指示までを自律的に遂行します。 Amazon Bedrock（Claude 4.5 Haiku）— 視覚認識と推論 Amazon Bedrock 上の Claude 4.5 Haiku が、D435e カメラから取得した画像をもとに周囲の状況を認識します。障害物の有無や周囲の状況を考慮した最適な行動の推論を担当します。 AWS IoT Core — エッジとクラウドの架け橋 AWS IoT Core が、会場内のロボットとクラウド上の AI エージェントをセキュアに接続します。MQTT 5 の Request/Response パターンによるアーム制御と、Device Shadow による配達車両の状態管理を実現します。通信断が発生しても最後の既知状態から安全に復帰できます。 Amazon Polly — AI の声 Amazon Polly により、AI エージェントの判断内容を音声で来場者に伝えます。「状況を確認します」「障害物を探します」「障害物を発見しました」「障害物を取り除きます」といったナレーションがデモの臨場感を高めます。 ハードウェア構成 FANUC CRX-20iA/L 協働ロボット × 2台 FANUC CRX-20iA/L は、可搬質量 20kg、リーチ 1,418mm の協働ロボットです。人と同じ空間で安全に動作します。 項目 仕様 リーチ 1,418 mm 制御装置 R-30iB Mini Plus 安全機能 接触検知による即時停止 ロボットハンド OnRobot 2FG7（ストローク 最大 68mm） カメラ FRAMOS D435e（RGB + Depth） 2台の CRX はそれぞれ担当エリアを持ち、AI エージェントの指示のもとで協調動作します。調査時はアーム先端の FRAMOS D435e カメラで隣接エリアを撮影し、復旧時はロボットハンド（OnRobot 2FG7）で障害物を把持して回収エリアへ移動します。 TurtleBot3 Burger — 配達車両 配送網を走行する自律走行ロボットです。 項目 仕様 経路追従 赤外線ラインセンサー（TCRT5000 × 3ch）によるライントレース 区間認識 停止ライン検知（3センサー同時白）による区間識別 障害物検知 赤外線距離センサー（IRSS-10）による前方障害物検知 通信 AWS IoT Core Named Shadow（mTLS）+ MQTT ログ送信 障害物を検知して停止すると、その情報がクラウド側のエージェントに伝達され、調査フローが起動します。復旧完了後、エージェントからの再開指示で走行を再開します。 項目 仕様 経路追従 赤外線ラインセンサー（TCRT5000 × 3ch）によるライントレース 区間認識 停止ライン検知（3センサー同時白）による区間識別 障害物検知 赤外線距離センサー（IRSS-10）による前方障害物検知 通信 AWS IoT Core Named Shadow（mTLS）+ MQTT ログ送信 障害物を検知して停止すると、その情報がクラウド側のエージェントに伝達され、調査フローが起動します。復旧完了後、エージェントからの再開指示で走行を再開します。 ジオラマステージ 3,640mm × 3,640mm の木工ステージ上に、3D プリンタで製作したミニチュアの街を配置します。周回トラックには「オレンジ通り」「ブルー通り」「グリーン通り」「パープル通り」の4つの通りがあり、配達車両の走行ルートとしています。 道路は黒地マット仕上げの上に白線（幅 30mm）を敷設し、配達車両がライントレースで追従します。配送・積荷のポイントには配達車両のための停止線を配置しています。 AI エージェントの意思決定 — 調査し、学習し、適応する 1ターン = 1アクション AI エージェントは毎ターン、以下のアクションから1つを選択して実行します。 アクション 内容 調査 FANUC ロボットの FRAMOS D435e カメラで対象エリアを調査 障害物除去 FANUC ロボットで障害物を把持し、回収エリアへ移動 エージェントは MAP の構造（道路レイアウト）とスタート/ゴール位置は既知ですが、障害物の位置は一切知りません。 調査の選択 調査を行うかどうかは、AI エージェントが自律的に判断します。配達車両が障害物を検知した後、AI エージェントは FANUC ロボットのカメラで状況を確認し、把持可能な障害物かどうかを見極めてから行動を計画します。これは事前にプログラムされた手順ではなく、状況に応じた AI エージェントによる自律的な判断です。 障害物除去戦略の判断 障害物を発見した AI エージェントは、カメラ画像から障害物の形状・サイズを認識し、ロボットハンドで把持可能かを判断します。把持可能と判断すれば、ロボットに除去を指示し道路を開通させます。把持が困難と判断した場合は、オペレーターに支援を要請します。 まとめ 本ブログでは、AWS Summit Japan 2026 の Physical AI ブースで展示するデモを通じて、AI エージェントが現実世界で自律的にオペレーションを遂行する仕組みをご紹介しました。 このデモのポイントは以下の通りです。 想定外への対応力 — 事前に定義されたシナリオではなく、予測不能な状況に AI が自律的に対応する 調査から解決まで一気通貫 — 障害の検知・調査・判断・復旧までを AI エージェントが自律的に完走する リアルタイム可視化 — ダッシュボードにより、エージェントの思考と行動が常に可視化される クラウド AI × ロボットの協調 — クラウド上の AI エージェントが判断し、現場のロボットが実行する新しいオペレーションモデル Physical AI は、AI が「考える」だけでなく「行動する」時代の到来を示しています。AWS のクラウドサービスとロボティクスの組み合わせにより、この未来は今まさに実現可能になっています。 体験機会のご案内 Physical AI デモの実物は、 AWS Summit Japan 2026 （2026年6月25日〜26日、幕張メッセ）の Physical AI ブースでご覧いただけます。AI エージェントが現実世界で自律的に問題を解決する様子を、ぜひ目の前で体験してください。 AWS を活用した Physical AI ソリューションにご興味のある方は、ぜひ お問い合わせ ください。 このブログは AWS Japan のソリューションアーキテクト 西田 光彦 、水野 貴博 が執筆しました。 西田 光彦は、エンタープライズのお客様をご支援しているソリューションアーキテクトです。自動車・製造業を専門領域とし、Generative AI/Physical AI など最新テクノロジーを活用してお客様の組織と業務変革のお手伝いしています。 Kiro と 信頼できる同僚達 に支えられながら仕事しています。 水野貴博は、製造業のお客様をご支援しているソリューションアーキテクトです。サプライチェーン領域を得意としており、好きな AWS サービスは Amazon Connect Decisions (旧AWS Supply Chain) です。趣味は、ドラマや映画のエキストラに参加することです。

LY Corporationの技術カンファレンス Tech-Verse 2026 の公式記事です。はじめにこんにちは。社内クラウドサービス Verda および社内モニタリングツール IMON に In...

開発会社から見積書を受け取ったものの、提示された金額が高いのか安いのか判断できず、困るケースは少なくありません。 複数社に見積もりを依頼しても、会社ごとに項目や金額が大きく異なり、単純に総額だけを比較できないこともあります。 システム開発の費用は、必要な作業量だけでなく、担当者の単価、機能の複雑さ、求める品質、納期、開発体制など、さまざまな条件によって変わります。 そのため、見積書を確認するときは、金額の大小よりも、 どの作業が、どのような条件で、どこまで含まれているか を見ることが重要です。 算出方法や費用内訳を理解すれば、専門的な技術知識が十分になくても、見積もりの妥当性を判断しやすくなります。 開発会社ごとの違いも整理できるため、社内への予算説明や依頼先の選定にも役立つでしょう。 そこで今回は、システム開発の見積もり方法と費用内訳、見積書の確認ポイントを実務の流れに沿ってまとめました！ 予算超過や追加請求を防ぎ、納得できる開発計画を立てるための参考にしてください。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼システム開発の流れに関する記事はこちら▼ システム開発の全体像をわかりやすく解説！工程と役割を入門ガイド システム開発の見積もりが決まる仕組みを理解しよう！ システム開発には、店頭で販売されている製品のような一律の価格がありません。 同じ「顧客管理システム」や「予約システム」という名称でも、必要な機能や利用条件が違えば、開発に必要な作業量も変わるためです。 見積金額は、主に 工数、担当者の単価、使用する製品やサービスの費用、リスクへの備え を組み合わせて算出されます。 要件が明確であるほど必要な作業を細かく洗い出せるため、見積もりの根拠も具体的になります。 一方、企画段階で仕様が固まっていない場合は、一定の仮定や金額の幅を設けて算出するのが一般的です。 見積書を正しく読むには、最初に金額が決まる基本的な仕組みと、見積もり時点での確定度を理解しておく必要があります。 まずは見積もりの基本となる「工数×単価」を押さえよう！ システム開発費を算出するときの基本は、 工数×人員単価 です。 工数とは、設計やプログラミング、テストなどに必要な作業量を指します。 工数の単位には、1人が1日作業する量を表す「人日」や、1人が1か月作業する量を表す「人月」がよく使われます。 たとえば、ある作業に2人月が必要で、担当者の人月単価が100万円であれば、単純計算した費用は200万円です。 ただし、人月は人数と期間を機械的に置き換えられる単位ではありません。 2人で1か月かかる作業に4人を投入しても、情報共有や確認作業が増えるため、必ず半月で終わるとは限りません。 また、同じ機能数でも、複雑な計算処理、外部サービスとの連携、高度なセキュリティ、厳しい品質基準があれば工数は増えます。 担当者の単価も、プロジェクトマネージャー、設計者、エンジニア、デザイナーなどの役割や経験によって異なります。 見積書に「開発一式」としか記載されていない場合は、 工程別の工数、担当者の役割、単価の根拠 を確認しましょう。 見積もりの精度は依頼するタイミングで変わる！ システム開発の見積もりには、企画段階で費用感をつかむための概算見積もりと、要件を整理した後に提示される正式見積もりがあります。 初期段階では、必要な画面や機能、データ量、外部連携などが決まっていないため、正確な作業量を算出できません。 そのため、概算見積もりでは「500万～800万円」のように幅を持たせたり、不確定な作業に備えた予備工数を加えたりします。 要件定義が進み、利用者数、機能一覧、画面構成、品質条件、移行対象などが明確になると、作業を細分化できるため精度が高まります。 注意したいのは、初期の概算金額をそのまま確定予算として扱わないことです。 要件定義を進めた結果、想定していなかった機能やデータ移行が必要になり、開発費が増える場合があります。 見積書を受け取ったら、 概算なのか正式見積もりなのか、どの要件を前提に算出したのか を確認しましょう。 再見積もりが行われる時期や、金額が変わる条件も事前に整理しておくと、予算計画を立てやすくなります。 開発会社が使う代表的な見積もり方法を知ろう！ 開発会社は、プロジェクトの段階や要件の確定度に応じて、複数の見積もり方法を使い分けます。 類推法 は、過去に開発した似たシステムの実績をもとに、今回の費用や工数を予測する方法です。 短期間で概算を出しやすい反面、機能数、品質、開発環境などの違いが大きいと、実際の工数とずれる可能性があります。 専門家判断 は、経験豊富な担当者が仕様や難易度を確認し、経験にもとづいて工数を見積もる方法です。 実務では使いやすい方法ですが、判断する人によって結果が変わりやすいため、根拠や類似実績の確認が欠かせません。 トップダウン見積もり は、プロジェクト全体の予算や規模を先に設定し、各工程へ配分する方法です。 企画段階では便利ですが、細かな機能や作業が十分に洗い出されていないと、作業漏れが起きるおそれがあります。 ボトムアップ見積もり は、機能や工程を細かく分解し、それぞれの工数を積み上げる方法です。 精度を高めやすい一方で、要件整理と見積作業に時間がかかります。 方法の名称だけで判断せず、 使用した前提、参考にした実績、工数を算出した根拠 まで確認することが重要です。 同じシステムでも見積金額が変わる理由を押さえよう！ 同じ種類のシステムでも、機能や開発条件が違えば見積金額は大きく変わります。 たとえば、単純な会員登録だけを備えたシステムと、本人確認、決済、通知、外部サービス連携まで備えたシステムでは、必要な設計やテストの量が異なります。 新規開発、既存システムの改修、パッケージ製品の利用など、採用する開発方法によっても費用は変わります。 短納期で多くの人員を確保する場合や、止められない業務を扱う場合は、管理や品質保証に必要な工数が増えやすくなります。 大量の既存データを移行する案件では、データの整理、変換、移行テストも必要です。 国内開発、海外開発、常駐、リモートといった体制の違いも、単価やコミュニケーション工数に影響します。 さらに、開発会社ごとに想定する品質水準やリスクへの備えが異なるため、同じ依頼内容でも金額差が生まれます。 大幅に安い見積もりを見つけた場合は、値段だけで判断せず、 省かれている工程や対象外となる作業がないか を確認しましょう。 費用内訳と見積書のチェックポイントを確認しよう！ 見積書の妥当性を判断するには、総額だけでなく、工程ごとの費用内訳を見る必要があります。 システム開発では、要件定義、設計、実装、テスト、導入、運用保守など、複数の工程が発生します。 直接システムを作る作業だけでなく、会議、進捗管理、調査、環境構築、データ移行などにも工数が必要です。 安く見える見積書でも、必要な作業が対象外になっていれば、開発開始後に追加費用が発生する可能性があります。 反対に、金額が高く見えても、調査や品質管理、導入支援、保守まで含まれていれば、実質的には割高とは限りません。 各項目について、 作業内容、成果物、担当範囲、前提条件 を確認し、費用に何が含まれているかを明確にしましょう。 要件定義・調査費は開発の土台として確認しよう！ 要件定義は、開発するシステムの目的や必要な機能、業務上の条件を整理する工程です。 現場へのヒアリング、現在の業務フローの確認、既存システムの調査、課題の整理などが含まれます。 この工程が不十分だと、発注側と開発会社の認識がずれ、設計や実装を始めてから仕様変更や手戻りが生じやすくなります。 見積書では、ヒアリング回数、調査対象、会議の参加者、作成される資料などを確認しましょう。 成果物としては、要件定義書、業務フロー、機能一覧、画面一覧、非機能要件などが想定されます。 既存システムを改修する場合は、ソースコードやデータ構造、外部連携の調査費が別途必要になることもあります。 要件定義だけを先に契約し、その結果をもとに開発費を正式に見積もる進め方もあります。 この場合は、 要件定義後に再見積もりを行う条件と、開発契約へ進む判断基準 を事前に確認することが大切です。 設計・デザイン費は「何を決める工程か」で判断しよう！ 設計工程では、要件定義で整理した内容を、実際に開発できる仕様へ落とし込みます。 基本設計では、画面の構成、機能の動き、入力項目、帳票、データ、外部システムとの接続方法などを決めます。 詳細設計では、プログラムがどのような処理を行うかを、実装できる粒度まで具体化します。 利用者が操作するシステムでは、画面デザインや操作性の設計も重要です。 パソコンとスマートフォンの両方へ対応する場合や、複数の利用者権限を設ける場合は、その分だけ設計対象が増えます。 設計工数が極端に少ないと、実装中の確認や修正が増え、結果的に納期遅延や追加費用につながる可能性があります。 見積書では、基本設計と詳細設計の範囲、デザイン案の数、修正回数、スマートフォン対応の有無などを確認しましょう。 あわせて、 設計書が納品されるか、追加開発や保守に利用できる状態か も確認しておく必要があります。 開発・実装費は工数と担当範囲を細かく見よう！ 開発・実装費は、設計内容にもとづいてプログラムやデータベースを作るための費用です。 画面の作成、業務処理の実装、データベース構築、外部サービスとの連携、管理機能の開発などが含まれます。 妥当性を確認するには、機能別、画面別、作業別に工数が分かれているかを見ることが大切です。 「システム開発一式」とまとめられている場合は、どの機能にどれほどの工数がかかるのか判断しにくくなります。 使用するプログラミング言語、開発基盤、クラウドサービス、外部製品などの条件も確認しましょう。 既存の部品や共通機能、パッケージを利用する場合は、すべてを新規開発する場合より工数を抑えられる可能性があります。 一方で、既存製品を利用しても、設定変更や他システムとの連携に費用がかかることがあります。 見積書では、 新規開発する範囲、既存機能を利用する範囲、発注側が準備するもの を分けて確認することが重要です。 テスト・品質管理費を削りすぎていないか確認しよう！ テストは、システムが設計どおりに動作し、業務で安全に利用できるかを確かめる工程です。 一般的には、個々のプログラムを確認する単体テスト、機能同士の連携を確認する結合テスト、システム全体を確認する総合テストなどがあります。 最終的には、発注側が実際の業務で利用できるかを確認する受入テストも必要です。 見積書では、実施するテストの種類、対象となる機能、担当者、使用環境を確認しましょう。 Webシステムであれば、対象となるブラウザ、端末、OSの範囲も重要です。 大量アクセスへの対応やセキュリティが重視される場合は、性能テストや脆弱性に関するテストが必要になることもあります。 テストデータの準備、テスト環境の構築、不具合の修正、修正後の再テストが含まれているかも確認してください。 テスト費用が極端に少ない見積書 は、リリース後の障害や業務停止につながるリスクがあるため、安易に削らないことが大切です。 管理・インフラ・移行・保守費まで漏れなく確認しよう！ システム開発では、プログラムを作る費用以外にも多くの費用が発生します。 プロジェクト管理費には、進捗確認、課題管理、品質管理、定例会議、関係者間の調整などが含まれます。 管理費が計上されていない場合は、誰が全体を管理し、問題が起きたときに誰が対応するのかを確認しましょう。 インフラ費には、サーバー、クラウド、ネットワーク、ドメイン、SSL証明書、ソフトウェアライセンスなどがあります。 既存システムからデータを引き継ぐ場合は、データの整理、変換、移行、移行後の確認にも費用がかかります。 導入時には、リリース作業、操作マニュアル、利用者向け研修、初期設定などが必要になることもあります。 リリース後は、監視、障害対応、問い合わせ対応、アップデートなどの保守運用費が継続的に発生します。 見積もりを比較するときは、初期費用だけでなく、 月額費用や年額費用を含めた総保有コスト で判断しましょう。 見積書では金額以外の条件もチェックしよう！ 見積書で特に重要なのは、金額の前提となる作業範囲です。 要件定義からリリースまで含まれるのか、設計以降だけを担当するのかによって、総額の意味は大きく変わります。 対象外となる作業も確認し、発注後に別料金となる項目を把握しましょう。 利用者数、データ量、画面数、対応端末、外部連携数など、見積もり時に想定された条件も重要です。 条件を超えた場合の費用や納期への影響を明確にしておけば、後のトラブルを防ぎやすくなります。 仕様変更や追加開発が生じたときは、変更内容、追加工数、金額、納期への影響を確認し、合意したうえで進めるルールが必要です。 納品物、検収方法、検収期間、支払時期、見積有効期限についても確認しましょう。 さらに、ソースコードや設計書の権利、利用可能な範囲、契約終了時のデータ返却も重要です。 責任範囲と変更時の手続きが明文化されているか まで確認すると、発注後の認識違いを抑えられます。 危険な見積書のサインを早めに見抜こう！ 注意したい見積書の代表例は、「開発一式」「テスト一式」のような記載が多く、作業の中身がわからないものです。 内訳が不明なままでは、金額の妥当性を判断できず、後から対象外の作業が判明する可能性があります。 作業範囲や対象外項目、前提条件が書かれていない見積書にも注意が必要です。 要件定義、設計、テスト、管理など、品質を支える工程が極端に少ない場合は、必要な作業が省かれている可能性があります。 他社より大幅に安い場合は、価格差の理由を質問し、担当者の体制、成果物、テスト範囲、保守内容などを比較しましょう。 不確定な要素が多いにもかかわらず、追加費用が一切発生しないような断定的な説明にも慎重な確認が必要です。 見積もりの根拠を尋ねても明確な回答がなく、類似案件の経験や算定方法を説明できない場合は、発注後の意思疎通にも不安が残ります。 安さではなく、説明の具体性と透明性 を、信頼できる開発会社を見極める基準にしましょう。 複数社の見積もりは同じ条件にそろえて比較しよう！ 複数社の見積もりを比較するときは、各社へ同じ条件を伝えることが基本です。 依頼内容が異なれば、提示された金額も異なるため、公平な比較ができません。 開発目的、必要な機能、利用者、希望納期、予算、品質条件などをまとめた資料を共通して渡しましょう。 比較表を作り、総額だけでなく、工程別の工数、担当者の単価、作業範囲、成果物、保守内容を並べると違いが見えやすくなります。 各社の見積書に含まれる項目と含まれない項目を整理し、追加費用を加えた実質的な総額も確認してください。 金額が安い会社には安い理由を、高い会社には高い理由を質問しましょう。 品質管理の方法、人員体制、リスクへの備え、導入後の支援などに差がある場合があります。 要件への理解度、質問に対する回答の速さ、説明のわかりやすさも重要な判断材料です。 最安値を選ぶのではなく、 費用、品質、納期、対応力、継続支援のバランス で依頼先を決めましょう。 精度の高い見積もりを取るための準備を進めよう！ 精度の高い見積もりを得るには、開発会社へ伝える情報をできるだけ整理する必要があります。 まずは、システムを開発する目的と、解決したい業務上の課題を明確にしましょう。 機能については、絶対に必要なもの、できれば必要なもの、将来追加したいものに分けて優先順位を付けます。 利用者の種類、利用人数、対応端末、想定データ量、外部システムとの連携、セキュリティ条件も共有してください。 希望納期や予算上限に加え、納期と機能のどちらを優先するかなど、調整可能な条件も伝えると提案を受けやすくなります。 現行システムの資料、業務フロー、画面イメージ、使用中の帳票、データのサンプルがあれば、調査や見積もりに役立ちます。 すべての要件を確定できない場合は、未確定事項を隠すのではなく、そのまま共有することが大切です。 開発会社が置いた仮定と、条件変更による金額への影響 を見積書に記載してもらうと、追加費用のリスクを管理しやすくなります。 予算を抑えるときは機能を削る順番を考えよう！ 見積金額が予算を超えた場合は、単純な値引き交渉よりも、作業範囲や機能の優先順位を見直すほうが効果的です。 最初からすべての機能を作らず、業務やサービスを始めるために最低限必要な機能へ絞る方法があります。 初期版を公開した後、利用者の反応や業務上の効果を確認しながら追加開発すれば、不要な機能への投資を抑えられます。 既存のクラウドサービスやパッケージ製品を利用できる部分がないかも検討しましょう。 独自性の低い機能まで新規開発すると、開発費だけでなく、将来の保守費も増える可能性があります。 複雑な例外処理や独自の業務ルールを見直し、標準的な流れへ合わせることも工数削減につながります。 データ整理、マニュアル作成、受入テストなどを発注側で担当できる場合は、役割分担を調整する方法もあります。 ただし、 品質、セキュリティ、障害対策を安易に削ることは避ける 必要があります。 事業効果の低い機能から順番に調整し、必要な品質を保ちながら予算内に収めましょう。 まとめ システム開発の見積金額は、主に工数と担当者の単価を軸に算出されます。 ただし、必要な機能、品質、納期、開発体制、データ移行、外部連携などの条件によって金額は大きく変わります。 そのため、一般的な相場や総額だけを見ても、見積もりが妥当かどうかを正確に判断することはできません。 見積書では、要件定義、設計、開発、テスト、プロジェクト管理、インフラ、データ移行、保守まで、必要な工程が含まれているかを確認しましょう。 作業範囲、前提条件、対象外項目、成果物、責任分担、仕様変更時の費用算定方法も重要なチェックポイントです。 複数社を比較するときは、同じ条件で見積もりを依頼し、含まれる作業と含まれない作業を一覧化してください。 依頼先は最安値だけで選ばず、要件の理解度、説明の具体性、品質管理、リスク対応、導入後の支援まで含めて判断することが大切です。 不明点を残したまま発注せず、 金額の根拠と変更時のルールに納得できる状態 を整えてから開発を始めましょう。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）