防災プラットフォーム（仮称）構築業務委託
神奈川県 横浜市 / 令和8年度
本サービスは案件情報を整理するだけでなく、この案件で何を提案書に入れると勝ちやすいかを考察し、すぐ使える文案と判断材料まで返します。
採用した考察は完成版の代筆ではなく、1つでも3つでも自社提案へ転記・要約・社内説明に使える素材として提示します。
10の考察から、提案として相応しい5つを選び、案件理解ではなく提案判断として提示しています。
案件の要件を読み解く
発注者が求めている成果、評価方式、納品物を最初に整理し、何を外せない案件かを把握します。
基本スペック
横浜市総務局危機管理室が、防災情報を一元化するWebプラットフォームの構築を委託するもの。 クラウドサービス（ISMAP対応）上にCMS・ウェブサイトを構築。 370万人同時アクセス対応、24/365稼働、SLA 99.9%。 危機管理システム・よこはま防災e-パークとのREST API連携を含む。
配点の山を把握する
どの評価項目に厚く書くべきかを先に決めることで、提案全体の密度と優先順位が定まります。
評価基準
配点の山を先に把握し、どこを厚く説明するかを決めます。
| 評価項目 | 配点 | ウェイト |
|---|---|---|
| 人員体制 | 20点 | 8.1% |
| 本業務趣旨の理解 | 15点 | 6.1% |
| 意欲 | 15点 | 6.1% |
| 本システムの全体構成 | 25点 | 10.2% |
| 取組情報の一元化、視覚的にわかりやすい掲載 | 25点 | 10.2% |
| 外部サイトによる検索において、上位に表示される工夫をしていること | 20点 | 8.1% |
| 災害時の迅速な情報取得・軽量化 | 25点 | 10.2% |
| 利用者の属性に応じた情報の提供 | 20点 | 8.1% |
| 利用者と職員の双方にとって使いやすい仕組み | 20点 | 8.1% |
| 他のシステムとの将来的な連携に向けた拡張性 | 20点 | 8.1% |
| 強靭で安全なウェブサイト | 20点 | 8.1% |
| 業務実績 | 15点 | 6.1% |
| ワークライフバランス/障害者雇用、健康経営に関する取組 | 6点 | 2.4% |
| 合計 | 246点 | 100% |
根拠を集め、論点ごとに束ねる
件数だけではなく、どのカテゴリの根拠をどの論点へつなげたかまで確認できるようにしています。
提案設計パック概要
公募資料だけでは弱い論点を、公開データと計画文書でどう補強しているかを先に掴める要約です。
- 根拠資料数
- 9件
- カバレッジ
- 100%
収録エビデンス
仮説G1: 横浜市の人口規模と防災情報の分散状況が、防災プラットフォーム統合の根拠となる
単独サイトの新設として見せるより、既存情報の入口を束ねる統合ハブとして提案し、提案冒頭で全体像を先に言い切る方が評価項目2.1/2.2に直結する。
- 18行政区に分散した行政組織
- 高齢化率: 約26%（約98万人が65歳以上）
- 世帯数: 約180万世帯
- 横浜市避難ナビのDL数: 67万（2024年9月末時点、目標100万）
全国最大級の人口と行政区分散を示し、単独機能ではなく市全体を束ねるプラットフォーム設計が必要だと提案冒頭で説明できる。
人口規模と行政区分散を調べ直さずに、統合ハブが必要な前提条件を提案冒頭へそのまま置ける。
- 現状の課題②: 取組情報の数や種類、量が多く、情報が羅列されている
- 現状の課題③: 防災に関する補助金・助成金等の申請が対面・電話・郵送中心
- 既存情報掲載媒体: 横浜市公式HP、よこはま防災e-パーク、防災情報ポータル、電子申請システム
- 関連システム: 危機管理システム（稼働中）、避難者支援システム（検討中）、被災者生活再建支援システム（LGWAN環境）、よこはま防災e-パーク（稼働中）
散在する防災情報を一つの入口に束ねる必要性を、横浜市固有の現況課題としてそのまま提案冒頭で言い切れる。
現況課題の棚卸しと「なぜ統合が必要か」の説明を自分で整理し直す時間を省ける。
- 2025年3月31日に最終更新
- 横浜市避難ナビ: 2022年3月リリース、2023年4月本格稼働、67万DL（2024年9月末）
- 避難ナビ機能: AR浸水体験、マイ・タイムライン、避難所情報
- 「意識の醸成」「事前の備え」「避難行動の支援」の3軸で防災DX推進
横浜市自身が進める防災DX方針と既存サービスを踏まえ、単なる新規開発ではなく市方針に沿う拡張型提案として位置づけられる。
市方針との整合確認と「拡張型であるべき理由」の説明を一から作る作業を省ける。
仮説G2: 災害時アクセス集中と大規模災害要件が、高可用CDN設計の根拠となる
平時の使いやすさより先に、災害時でも止まらない基盤を提案の主軸として言い切り、CDN・キャッシュ・軽量トップの設計まで約束すると評価項目2.4/2.8に効く。
- 近畿地方の地震（最大震度6弱）でガス会社サイトがアクセス集中によりダウン
- 東京都「アクセス集中対応のためのガイドライン」でCDN対策を推奨
- 練馬区: CDN導入後、災害時に安定接続を実現
- 那覇市: 災害専用トップページを軽量化（図・写真省略）で対応
- 日立社会情報サービス: J-Stream CDNextを自治体に導入し安定情報提供を実現
- CDN（Content Delivery Network）による負荷分散が標準的対策
災害時でも止まらない基盤を提案の主軸に置き、CDN・キャッシュ・軽量トップを標準対策として約束する根拠になる。
CDNや軽量トップを採用すべき理由を先行事例ベースで説明する作業を省ける。
- 想定災害: 地震（震度5以上）、風水害、テロ、大規模障害
- SLA要件: 稼働率99.9%以上、レスポンス3秒以内（最長5秒）
- 障害発生一時通知: 30分以内、障害回復: 6時間以内
- RPO: 障害発生前日時点までのデータ復旧
- RTO: 6時間以内のシステム復旧
- マルチリージョンでのデータ冗長化が必須
負荷対策だけでなく、99.9%稼働率・RPO/RTOを満たす高可用構成を提案責任として明記する根拠になる。
SLAやRPO/RTOを読み解いて、高可用構成の約束事項へ変換する作業を省ける。
仮説G3: 先行自治体事例と国の防災DX戦略が、横浜市向け防災プラットフォーム構成の根拠となる
既存システムを置き換える提案ではなく、危機管理システムや防災e-パークを接続して価値を増幅する構成として描くことで、評価項目2.1/2.7の説得力を上げられる。
- 内閣府: 「防災デジタルプラットフォーム」の中核として「新総合防災情報システム（SOBO-WEB）」を構築中
- 骨太方針2025にSOBO-WEBの強化と活用が明記（2025年6月閣議決定）
- NTTデータ関西「EYE-BOUSAI」: 都道府県/市町村/中小自治体向け4パッケージ
- 扶桑電通「BO-SAInavi Difesa」: 防災専用ポータルサイトで情報一元化
- 横浜市は政令指定都市最大の人口を持ち、先行事例を超える規模の設計が必要
先行自治体事例を踏まえつつ、横浜市はそれ以上の規模と接続要件を持つため、接続型で拡張可能な設計が必要だと差別化できる。
先行事例との差分を抜き出し、横浜市ならではの規模要件へ言い換える作業を省ける。
- SOBO-WEB: 防災情報を一元的に集約・共有する国レベルのシステム
- ISMAPクラウドサービス: 政府情報システムのセキュリティ評価制度
- クラウドバイデフォルト原則: ガバメントクラウドの活用推奨
- 自治体のDX推進計画: 総務省が2025年度までのDX推進目標を設定
国の防災DX戦略とガバメントクラウド方針に接続することで、横浜市案件を全国標準に沿うプラットフォーム提案として説明できる。
国方針との接続整理と、全国標準に沿う説明の下書きを作る時間を省ける。
仮説G4: 横浜市の外国人住民構成が、多言語対応とやさしい日本語設計の根拠となる
多言語対応を付加機能として扱わず、地区や属性に応じて迷わず必要情報へ届く導線とセットで示すと、利用者体験とアクセシビリティの提案として強く見せられる。
- 主要国籍: 中国、韓国・朝鮮、フィリピン、ベトナム、ネパール等
- 中区（約1.5万人）、南区、鶴見区に集中
- 多言語対応の優先: やさしい日本語、英語、中国語、韓国語、ベトナム語
多言語対応を付加機能ではなく必須要件として扱い、やさしい日本語を含む導線設計を提案に組み込む根拠になる。
多言語対応をオプションではなく必須要件として位置づける説明を自分で組み立て直す時間を省ける。
仮説G5: 既存防災関連システムの連携要件が、API中心のアーキテクチャ設計の根拠となる
API中心の接続型アーキテクチャとして全体構成図に落とし込み、令和8年度以降の連携ロードマップまで示すことで、将来拡張と実装現実性の両方を評価者へ伝えやすくなる。
- ②避難者支援システム（検討中）: 総務局防災企画課所管、令和7年度検討・令和8年度以降構築
- ③被災者生活再建支援システム: 総務局防災企画課所管、外部クラウド・LGWAN環境
- ④よこはま防災e-パーク（稼働中）: 消防局予防課所管、外部サーバ・インターネット環境。令和8年度以降にお知らせ情報を連携
- 連携方式: REST API（数秒〜1分以内）、JSON形式（Lアラート用XMLも可）、HTTPS通信
- 実際の情報連携は令和8年度以降を想定
既存システムを置き換えずに API 連携で価値を増やす接続型アーキテクチャを、全体構成図つきで提案する根拠になる。
既存システム連携の対象・方式・実現時期を整理し、構成図へ落とし込む作業を省ける。
提案へ導く5つの考察
本サービスは案件に対して10の考察を行い、その中から提案として有効な5つを選んで提示します。 1つだけでも、3つ組み合わせても、自社の提案書を強くするための考え方として活かせます。
Editorial Lens
このサービスは、考察を提案として返します
案件理解を整理するだけではなく、提案として効く論点を選び直して返します。 単なる情報のまとめではなく、読者が自社提案を一段強くするための考察です。
Selection Policy
考察の選び方
仕様書の言い換えではなく、評価に効き、実務として成立し、案件差を生みやすい視点を残しています。 読者はこの中から、自社提案に必要な考察を選んで反映できます。
- 01
分散した防災情報の入口を一つに束ねる
そのまま使える提案文案: 横浜市では散在する防災情報を一つの入口に統合し、既存サイトや申請導線を束ねるプラットフォームとして再編する。
なぜ有効か: 既存情報を活かしながら使いやすさを上げる提案として説明できる。
これで省ける作業: 提案冒頭のコンセプト文と、統合ハブ構成を説明する書き出しを一から考える作業を省ける。
- 02
アクセス集中時でも止まらない構成を先に語る
そのまま使える提案文案: 災害時のアクセス集中を前提に、CDN・キャッシュ・軽量トップで止まらない基盤を構成する。
なぜ有効か: 災害時の信頼性を軸に、技術提案の説得力が上がる。
これで省ける作業: 高可用構成の主張、構成図の説明、SLAへの言い切りを一から整理する作業を省ける。
- 03
既存システムを生かす接続型プラットフォーム
そのまま使える提案文案: 危機管理システムや防災e-パーク等をAPIで連携し、既存投資を生かす接続型プラットフォームとして実装する。
なぜ有効か: 既存投資を生かす提案として、導入ハードルを下げて説明できる。
これで省ける作業: 既存システム連携の説明と、置換ではなく接続型で提案するロジック整理を省ける。
- 04
地区・家族構成に応じて必要情報を変える
そのまま使える提案文案: 地区別入口と属性別導線を組み合わせ、情報量の多い都市でも必要情報へ迷わず到達できる利用者体験を設計する。
なぜ有効か: 都市規模が大きくても、自分ごとの防災情報として説明しやすくなる。
これで省ける作業: 利用者導線図の考え方と、地区別・属性別で見せ分ける説明を一から組み立てる作業を省ける。
- 05
外国人住民も迷わない高可用・高可読設計
そのまま使える提案文案: やさしい日本語と多言語対応を前提に、外国人住民を含む全住民が平時も災害時も読み取れる高可読UIを実装する。
なぜ有効か: 多様な住民に届くプラットフォームとして説明できる。
これで省ける作業: 多言語・やさしい日本語対応を提案でどう約束するか、対象言語とUI要件を一からまとめる作業を省ける。
Public Proof
公開結果で裏付けたこと
横浜市の防災DX方針とアクセス集中対策の公開事例を重ねることで、「散在する防災情報を一つの入口に統合し、災害時も止まらない基盤として構築する」という提案冒頭文を、そのまま提案書へ置ける一文として補強した。 消防庁手引きで周辺チャネル連携を全国標準に接続し、「入口で終わらせず詳細情報へ送客する」「既存システムをAPI連携で生かす」という約束事項を、そのまま構成方針として持ち帰れる状態にした。
この商品を買うと、そのまま使える提案文案と成果物
- 分散した防災情報の入口を一つに束ねる: 横浜市では散在する防災情報を一つの入口に統合し、既存サイトや申請導線を束ねるプラットフォームとして再編する。 / 省ける作業: 提案冒頭のコンセプト文と、統合ハブ構成を説明する書き出しを一から考える作業を省ける。
- アクセス集中時でも止まらない構成を先に語る: 災害時のアクセス集中を前提に、CDN・キャッシュ・軽量トップで止まらない基盤を構成する。 / 省ける作業: 高可用構成の主張、構成図の説明、SLAへの言い切りを一から整理する作業を省ける。
- 既存システムを生かす接続型プラットフォーム: 危機管理システムや防災e-パーク等をAPIで連携し、既存投資を生かす接続型プラットフォームとして実装する。 / 省ける作業: 既存システム連携の説明と、置換ではなく接続型で提案するロジック整理を省ける。
補助メモ: 根拠と仮説のつながり
考察の主役はこのサービスからの提案です。必要に応じて、根拠と仮説の関係を補助的に確認できます。
提案ストーリー
横浜市は約377万人・18行政区を抱える大規模自治体であり、防災情報が複数媒体に分散している。統合ポータルの必要性は十分に裏付けられる。
単独サイトの新設として見せるより、既存情報の入口を束ねる統合ハブとして提案し、提案冒頭で全体像を先に言い切る方が評価項目2.1/2.2に直結する。
裏付け: EP-01, EP-02, EP-03
災害時のアクセス集中によるサイトダウン事例と、横浜市が想定する最大370万人同時アクセス・99.9%稼働率要件を確認でき、高可用設計の必要性が明確である。
平時の使いやすさより先に、災害時でも止まらない基盤を提案の主軸として言い切り、CDN・キャッシュ・軽量トップの設計まで約束すると評価項目2.4/2.8に効く。
裏付け: EP-04, EP-05
自治体防災ポータルの先行事例と、SOBO-WEB を含む国の防災DX戦略を確認でき、横浜市でも統合基盤とデータ連携を前提にした設計が妥当である。
既存システムを置き換える提案ではなく、危機管理システムや防災e-パークを接続して価値を増幅する構成として描くことで、評価項目2.1/2.7の説得力を上げられる。
裏付け: EP-06, EP-07
統計ポータルの概要値だけでも約11万人規模の外国人住民と主要国籍・集中区を把握でき、多言語対応の優先順位設計に十分な代替根拠となる。
多言語対応を付加機能として扱わず、地区や属性に応じて迷わず必要情報へ届く導線とセットで示すと、利用者体験とアクセシビリティの提案として強く見せられる。
裏付け: EP-08
横浜市の既存システム群と連携方式・時期を確認でき、REST API/JSON を軸とした連携設計の妥当性が裏付けられる。
API中心の接続型アーキテクチャとして全体構成図に落とし込み、令和8年度以降の連携ロードマップまで示すことで、将来拡張と実装現実性の両方を評価者へ伝えやすくなる。
裏付け: EP-09
提出前に見落としを潰す
案件ごとに納品物と評価方式を再確認し、提案書に何を反映すべきかを最後に整理します。
提出前に再確認する項目
- 契約種別と履行期間が提案内容と矛盾していないか
- 評価方式と最低基準の理解が章構成へ反映されているか
- 納品物一覧に対して、根拠と実施体制の記述が不足していないか
この案件で確認したいこと
- 提案書提出前に、案件固有の提出要件と評価の山を再確認する
この考察を自社案件へどう活かすか
- ✓公開結果と考察を踏まえ、どの論点を自社提案に採用するかを整理
- ✓評価基準13項目に対して、どの考察を厚く扱うと提案が強くなるかを整理
- ✓考察を提案書へどう取り込むかの整理
- ✓提出前に見落としやすい確認ポイント
1案件につき1社のみ販売
同一案件の提案設計は、1社のみにご提供します。公開事例で理解を深めたうえで、 個別相談では競合と重ならない進め方と必要資料を整理します。
公開事例を踏まえた活用方法や、自社案件への当てはめ方は、お問い合わせいただければ担当者からご説明します。
※ この案件の提案期限は終了しています。公開可能な範囲の詳細を掲載しており、お問い合わせも引き続き受付中です。