240倍と30%が同じ資料に載っています
日立製作所は2026年7月24日、システムインテグレーションの全工程にAIエージェントを組み込むプラットフォームを発表しました。その資料には、次の数字が並んでいます（日立製作所 2026年7月24日 ニュースリリース）。
| 公表値 | 測った範囲 |
|---|---|
| 最大240倍 | 要件定義のうち、OT領域の実務者とIT部門が画面仕様を確定する作業 |
| 約200倍 | 設計からテスト（自社パッケージ製品の機能拡張を対象とした仕様駆動開発の試行） |
| 30%向上 | 工程全体（2027年度の目標） |
| 約25%・約30% | 顧客案件のコーディングと単体テストの工程 |
倍率と数十パーセントが同じ資料に並ぶと、どちらかが誇張に見えます。ただ、これは矛盾ではありません。測っている範囲が違うだけです。同社は倍率の数字に「当社内における特定の工程・条件下での実証値であり、効果はプロジェクトの規模・特性により異なります」と注記しています。
発注側が判断に使えるのは、最後の系列です。保険分野の基幹システム開発ではコーディングと単体テストの工程で約25%、オープン勘定系システムでは同じ工程で約30%と、顧客案件での実証値が示されています。工程を限定しても、社内実証の倍率とは桁が違います。
この構造は日立に固有のものではありません。AIの効果を測った数字は、範囲の取り方で桁が動きます。
倍率が出るのは作業、パーセントが出るのは工程全体です
240倍が出たのは、OT（制御・運用技術）領域の実務者とIT部門が画面仕様を確定する作業です。工程ではなく、工程の中の特定の作業です。この粒度まで絞ると、AIが担える割合が大きくなり、比較対象である人手の作業時間がそのまま短縮幅になります。
一方、工程全体の目標が30%にとどまるのは、AIが関与しない時間が残るからです。関係部署との合意、業務側の意思決定待ち、受入テストの日程調整、本番切替の承認。これらはAIを入れても短くなりません。全体の所要時間は、短縮できない部分の比率に頭を押さえられます。作業単位で240倍でも、その作業が全体の1%なら、全体の短縮は1%に届きません。
公開された実験でも同じ傾向が出ています。GitHub Copilotを対象にした対照実験では、募集した95人の開発者にJavaScriptでHTTPサーバーを実装させ、Copilotを使えた群が使えなかった群より55.8%速く完了しました（95%信頼区間21〜89%、arXiv:2302.06590）。平均所要時間は2時間41分に対して1時間11分です。
この数字はよく引用されますが、タスクの性質を見てください。ゼロから作る、自己完結している、既存コードの文脈がない、業務上の制約もない。AIが最も得意な条件が揃っています。基幹システムの改修とは前提が違います。
実務のコードでは、速くなったという体感も外れます
では、既存の大きなコードベースで同じことをするとどうなるか。これを測った無作為化比較試験があります。
METRは2025年、成熟したオープンソースリポジトリ（平均22,000スター以上・100万行以上）に数年間コミットしてきた開発者16人を対象に、実際の課題246件を「AI使用可」「AI使用不可」に無作為に割り当てました。結果は、AIを使えた場合に完了までの時間が19%長くなりました（95%信頼区間 +2〜+39%、arXiv:2507.09089）。
注目すべきは、その隣に並ぶ数字です。
開発者は開始前に「AIで24%短縮できる」と予測していました。そして実験を終えた後も、「AIで20%短縮できた」と回答しています。実測は19%の遅延です。経済学の専門家は39%短縮、機械学習の専門家は38%短縮と予測しており、こちらも外れました（METR 2025年7月10日）。
体感が実測と逆を向いた、という点が重要です。社内で試験導入して「速くなった実感がある」という報告が上がってきたとき、その実感は測定値の代わりになりません。
なお、この結果は2025年2〜6月時点のツール（主にCursor ProとClaude 3.5/3.7 Sonnet）での測定です。当時のAIの性能を示すもので、現在の性能ではありません。
測定そのものが難しくなっています
METRは2025年8月から、開発者57人・143リポジトリ・800件超のタスクで追跡調査を実施しました。ところが2026年2月、同社はこの調査のデータを「現在の生産性への影響を示す信号としては信頼できない」と自ら判断し、実験計画の見直しを公表しています（METR 2026年2月24日）。
理由が示唆的です。AIなしで作業したくないという理由で参加を辞退する開発者が増え、参加者の30〜50%が「AI不可に割り当てられたくないタスク」を調査に出さなかったと回答しました。つまり、AIの効果が大きいと本人が見込んだタスクほど、測定から抜け落ちます。エージェントを並行して走らせる開発者が増え、作業時間の自己申告そのものが不正確になった点も挙げられています。
同社は、2026年初頭の開発者は2025年初頭より速くなっている可能性が高いとしつつ、選択バイアスのため自社のデータはその大きさの弱い証拠にとどまる、と述べています。参考値として、元の研究の参加者では18%の短縮（信頼区間 -38〜+9%）、新規参加者では4%の短縮（同 -15〜+9%）が出ていますが、いずれも区間がゼロをまたいでいます。
ここから読み取るべきは「AIは効かない」ではありません。効果を正しく測ること自体が難しい、ということです。専門の研究機関が設計を組み直すほどの難しさが、ベンダーの社内実証や自社のPoCで解決されていると考える理由はありません。提案書の数字は、この難しさを踏まえて読む必要があります。
個人が速くなっても、組織の納品が速くなるとは限りません
工程や個人の速度が上がったとして、それが納品まで届くかは別の問題です。
DORAの2024年調査は、AI活用が25%増えるごとに、デリバリーのスループットが約1.5%、デリバリーの安定性が約7.2%低下すると推定しています（DORA 2024 Accelerate State of DevOps Report）。同じ調査で、AI活用は個人の生産性・フロー・仕事の満足度を高め、コード品質やドキュメント、レビューの速度も改善すると報告されています。個人と工程では改善し、組織の納品では悪化した、という結果です。
同レポートはこの原因を、AIによって同じ時間でより多くのコードが生まれ、1回あたりの変更が大きくなるためと推測しています。変更が大きいほど遅く、障害を生みやすいという関係は以前から報告されており、開発プロセスの改善は、小さい変更単位と堅牢なテストという基本を守らないかぎり、そのままデリバリーの改善にはならないと結論づけています。
2025年の同調査は、AIを増幅器と位置づけています。高い成果を出している組織の強みを増幅し、うまくいっていない組織の機能不全も同じように増幅する、という整理です（DORA 2025 State of AI-assisted Software Development Report）。
先の日立の資料が、工程全体の目標を30%に置いていたことを思い出してください。作業単位で240倍を出した組織が、全体では30%を目標にしている。この落差は、控えめな目標設定というより、ここまで見てきた構造と整合的です。
提案書では3つを確認します
ベンダーから生産性の数字が出てきたら、次の3点を聞いてください。数字の大小より、この3つに答えられるかどうかが判断材料になります。
提案書の「生産性◯倍」に対して確認する3点
- 測定範囲: どの工程の、どの作業を測ったか。工程全体か、その中の一作業か。前後の待ち時間や調整は含まれているか。
- 比較対象: 何と比べて何倍か。人手のみの状態か、既存の開発ツールを使った状態か。比較対象が明示されていない倍率は、解釈ができません。
- 測定条件: 自社内の実証か、顧客案件での実測か。対象システムの規模、既存コードの有無、品質要求の水準。自社の案件と条件が近いか。
ベンダー面談やコンペの評価シートにそのまま転記して使えます
そのうえで、自社の見積もりに反映するときは、工程別に分けます。実装工程で30%短縮できるとしても、要件定義と受入テストが変わらなければ、全体の工期短縮はその一部にとどまります。工期と費用の見積もりを工程別の内訳で受け取っておくと、後から効果を検証できます。この検証の設計は、PoCを本番に進める判断で成功条件を先に決めるのと同じ考え方です。
価格そのものの見方は安いAI受託開発に飛びつく前に、速くなった分の便益を誰が受け取るかという契約の論点は工数課金から成果対価へ移る契約設計で扱っています。効果の数字・価格・契約は連動するので、あわせて確認してください。
数字の大きさではなく、範囲を開示できるかで見ます
AIで開発が速くなること自体は、実験でも実務でも確認されています。問題は、その速さがどの範囲のもので、自社の案件にどこまで移るかです。
倍率を大きく見せることは難しくありません。効果の出る作業を切り出し、比較対象を人手のみに置けば、桁は簡単に動きます。むしろ、測定範囲と条件を明示している資料のほうが信頼できます。冒頭の資料が注記付きの倍率と工程全体の目標を併記していたのは、その意味で読み取りやすい部類です。
ベンダーから受け取った提案書の数字が自社の案件に当てはまるかを確かめたい段階でしたら、お問い合わせからご相談ください。工程別の内訳に分解するところからお手伝いします。