Claude Code活用 #12 分厚いRFPを読み解いて見積もりまで──公共案件の「仕様の取りまとめ」をAIに任せた

2026年7月11日 2026年7月11日

blueleaf

公共系のシステム再構築案件で、概算見積もりを作る機会がありました。この手の案件は、渡される資料がとにかく多いのが特徴です。仕様書、募集要項、現行システムの設計書、利用者向けマニュアルが数種類、障害対応マニュアル、利用者アンケートの結果、全体構成図……PDFだけで20ファイル近くありました。

これを一枚ずつ読んで、「何を作るのか」「何が求められているのか」を把握し、機能を洗い出して、工数に落として、金額の根拠を組み立てる。まともにやると、資料を読むだけで丸1〜2日は溶けます。

今回はこの一連の作業を、Claude Code に手伝ってもらいました。金額そのものは人が決めましたが、資料の読み込み・仕様の取りまとめ・機能一覧の整理・見積もりの内訳と根拠づけは、ほぼAIに任せたという話です。

公共案件の見積もりは「読む」ところが一番重い

システム開発の見積もりというと、工数を積むところが本題に思えますが、実際に時間を食うのはその手前です。

分厚い仕様書のどこに「必須要件」が埋まっているのかを拾う
現行システムのマニュアルから、いまある機能を棚卸しする
セキュリティ要件（今回は ISO/IEC 27001 相当の体制、WAF、24時間365日の監視など）を読み落とさない
データ移行やアクセシビリティ（JIS X 8341-3 準拠）といった、金額に効いてくる条件を見つける

公共調達だと、これらが複数のPDFに分散しています。しかも「可能な限り準拠」「別途協議」といった曖昧な書きぶりも多く、読み手が論点として拾わないと見積もりから抜け落ちます。ここを人力で漏れなくやるのが、一番しんどいところでした。

まず「仕様の取りまとめ」をAIに作ってもらう

そこで最初にやったのが、大量の資料を Claude Code に読み込ませて、1枚のサマリにまとめてもらうことでした。

出来上がったのは、こんな見出しで整理されたドキュメントです。

事業の基本情報（発注者・委託期間・目的）
スケジュール（設計〜開発〜公開〜保守運用の区切り）
サイト利用者の種別（今回は5種類。うち1種類は新設）
現行機能の棚卸しと、追加される機能の一覧
サーバー要件・性能要件・セキュリティ要件
データ移行要件・テスト要件・納入成果物
著作権の扱い
提案書で答えるべき項目（提案依頼事項）

そして最後に、「見積もりに影響する重要論点」をAI側から質問の形で挙げてもらいました。たとえば「月額保守の範囲はランニングコストだけか、人的な監視やパッチ当ても含むのか」「初期費用と月額保守の切り分けはどこか」といった、金額を左右する分岐点です。ここが曖昧なまま数字だけ作っても意味がないので、先に論点として並べてもらえたのは効きました。

散らばっていた要件が1枚にまとまるだけで、案件の全体像が一気に見えるようになります。

人が読むのは「取りまとめ」から。求められている点と、提案できる点を探す

取りまとめができると、人がやることが変わります。20個のPDFと格闘するのではなく、整理済みのサマリを読んで「考える」ことに時間を使えるようになります。

このとき見ていたのは、大きく2つです。

1つは「求められていること」。必須要件、外してはいけないセキュリティ条件、移行の制約（今回は更新停止期間が1週間以内、といった縛りがありました）。ここを満たせない見積もりは、そもそも土俵に乗りません。

もう1つは「提案できること」。仕様書には「アンケート結果を踏まえた追加提案」を歓迎する項目がありました。そこで現行サービスの利用者アンケートも読み込ませて、「あったら喜ばれそうな機能」を検討しました。結果として、標準の再構築スコープに加えて、

団体向けの問い合わせ機能
会員のランク・ポイント機能
カテゴリ別のメール配信機能

といった追加提案を、それぞれ独立した見積もり項目として組み込みました。「言われたものを作る」だけでなく「こういう手もありますよ」と乗せられるのは、資料を早く読み解けたぶんの余力から生まれた部分です。

作るものの概要を設計しながら、機能一覧に落とす

見積もりの数字を出すには、「何を作るか」がある程度の粒度で見えていないといけません。ここも対話しながら進めました。

利用者が5種類いるなら、それぞれにどんな画面が要るのか。検索は5項目・複数条件で組めるようにするなら、公開面と管理側でどんな実装が必要か。応募から採否決定、活動証明書の発行までの動線をどう作るか。こうした「作るものの概要」を設計しながら、開発の単位に分解していきました。

最終的に見積もりは、こんな粒度の項目に落ちています。

要件定義・基本設計
API実装（会員・認証・団体・募集記事・応募・証明書発行）
管理画面・マイページ実装（利用者種別ごと）
公開面のフロントエンド実装・API連携
クラウド基盤の初期構築
テスト（単体・結合・受入支援）
データ移行支援

この機能一覧を先に作ってあると、後段の工数積みが一気に楽になります。「作るものの一覧」と「見積もりの明細」がほぼ地続きになるからです。

概算は人が決める。内訳と根拠はAIが書く

ここが今回の肝でした。

総額の概算は、人が決めます。 案件の規模感、相手の予算感、取りに行くかどうかの判断──ここはビジネスの意思決定なので、AIに丸投げする話ではありません。

一方で、その金額を「なぜその額なのか」に落とす作業、つまり内訳の割り付けと、各項目の根拠の言語化は、AIに任せられました。 決めた総額を、機能一覧に沿って人月に割り戻し、単価をかけて明細にする。各項目が何をやるものなのかを一行で説明する。追加提案なら、それぞれを要件定義・DB設計・実装・テストまで分解して積む。

こうした「数字を意味のある内訳にする」作業は、地味ですが手間がかかります。そこをAIが下書きしてくれるので、人は「この配分でいいか」「この根拠で相手に説明できるか」を確認するだけで済みました。見積書の説得力を保ったまま、作る時間はかなり圧縮できたと感じています。

どのくらい省力化できたか

体感で言うと、「資料を読んで全体像をつかむ」ところが、1〜2日かかっていたのが半日ほどになりました。しかも、取りまとめが手元に残るので、後から「あの要件どこだっけ」と資料を掘り直す時間も減ります。

ポイントは、単に速くなったことではなく、空いた時間を「提案を考える」ほうに回せたことです。読む作業に追われていると、どうしても「言われたものを見積もる」だけで手一杯になりがちです。そこをAIに巻き取ってもらえると、「どう提案するか」に頭を使えるようになります。見積もりの質そのものが上がる、という副次的な効果のほうが大きかったかもしれません。