公共のWebサイト案件には、独自のルールが数多くあると耳にする一方で、その中身がはっきり見えないまま提案書を書くことになりがちです。決まりは工程のあちこちに散らばっているのではなく、調達・運用・廃止という区切られた場面ごとに置かれています。どこに何が書かれているかをつかめば、見積りや提案の場でも根拠を示しながら話せるようになります。この記事では、公共のWeb案件で押さえておきたい技術要件を、資料に沿って整理します。

1. 公共のWeb案件で最初に効いてくるのは技術の寿命

調達の時点で、既に条件は決まっている

公共のWebサイト案件では、提案の段階で使おうとしていた技術がそのまま通るとは限りません。ウェブサイトガイドラインには、調達にあたって原則としてサポートが終了している技術等を対象にしないよう努める、と記載されています¹。つまり技術選定の余地は、企画や設計の前ではなく、調達という早い段階で既に絡んでいます。

ここで問われているのは、個々の技術の名称ではなく、その技術がいつまで手を入れられる状態にあるかという点です。サポートが終了している技術を選んでしまうと、不具合が見つかっても直せない状態のまま運用を続けることになりかねません。だからこそ、提案する技術がいつまで更新され続けるのかを、見積りの前に確認しておくと話がスムーズに進みます。

新しい技術を取り入れることよりも、その技術が今後も手を入れ続けられるかを見極めることのほうが、公共のWeb案件では重視されます。話題性のある技術よりも、更新の見通しが立つ技術のほうが評価されやすい場面です。

提案書の中でこの観点を明示できるかどうかは、技術力そのものとは別の評価につながります。技術の詳細を説明する前に、その技術がいつまで手を入れられるのかを一文添えておくだけで、読み手の受け止め方は変わります。

技術選定で確認しておきたい観点

提案や見積りの前に確認しておきたい観点を整理すると、技術そのものの継続性だけでなく、更新の見通しや将来の移行のしやすさまで含まれます。ウェブサイトガイドラインが示しているのは技術等の対象範囲についての考え方であり、具体的な製品名や版数までは指定していません¹。そのため、提案する技術がこの3つの観点に当てはまるかどうかを、自分の言葉で説明できる状態にしておくと、質疑の場でも落ち着いて答えられます。

確認する観点	具体的に確認すること	説明できると安心な理由
技術の継続性	提案する技術に、更新や不具合対応が続いている状態があるか	調達の入口条件に関わる観点だからです
更新の見通し	今後どのくらいの期間、更新が続く見込みか	運用期間中に更新が止まる技術を避けるためです
移行のしやすさ	将来別の技術に置き換える場合、どの程度手間がかかるか	長期の運用を前提にした設計かどうかが伝わるからです

この3つの観点は、提案書の技術選定の章に、そのまま項目として置くことができます。技術の継続性、更新の見通し、移行のしやすさを一つずつ触れておくと、読み手にとって分かりやすい説明になります。

出典：デジタル庁「ウェブサイトガイドライン」（2025年9月30日）をもとに作成

調達の入口を越えたあとも、技術をめぐる要件は終わりではありません。今度は、作ったサイトを何年先まで読める状態に保つかという課題が控えています。

2. 作ったあとも読める形にする

技術の更新や組織の変化で、情報が読めなくなることがある

サイトを公開した直後は、情報が問題なく表示されます。ところが年数が経つと、閲覧環境や社内の体制が変わり、以前は当たり前に読めていたページが急に開けなくなることがあります。ウェブサイトガイドラインは、時間の変化に伴う技術の更新や組織の変化によって、人間及び機械による情報の再生（可読性）、理解のしやすさ、信頼性等が毀損しないよう留意する、と記載しています²。

ここで注目したいのは、「機械による情報の再生」という言葉です。人が目で見て読めるだけでなく、検索エンジンや別のシステムが情報を正しく取り込める状態も含まれています。見た目が保たれていても、裏側の構造が古い書き方のまま残っていると、この要件を満たしていない状態になりかねません。

毀損の要因は、技術の話だけではない

可読性が失われる要因は、技術更新だけに限りません。担当部署の再編や体制の見直しが起きると、更新を引き継ぐ人がいなくなり、同じ理由で情報が読みにくくなることがあります²。技術の話と組織の話を、別のリスクとして両方見ておく必要があります。

可読性を保つ工夫は、公開後に担当者が変わったときにも効きます。設計や実装の意図を記録に残しておくと、体制が変わっても情報が失われにくくなります。誰が見ても同じ理解に至れるように整理しておくことは、機械が情報を取り込む場面でも役に立ちます。

公開後にサイトを引き継ぐ際は、変更履歴や設計の背景がまとまっているかどうかで、引き継ぎにかかる時間が大きく変わります。担当が変わることを前提に記録を残しておくと、可読性を保つ実務的な備えになります。

出典：デジタル庁「ウェブサイトガイドライン」（2025年9月30日）をもとに作成

技術の寿命と長期の可読性を押さえたところで、次に問われるのは日々の通信そのものの信頼性です。

3. 通信の信頼性は「利用者が確かめられる状態」を作ること

設計の段階からセキュリティを組み込む

通信の信頼性は、公開の直前に対策を加えれば整うものではありません。ウェブサイトガイドラインは、設計にあたってセキュリティ・バイ・デザインなどセキュリティの確保に関する文書も参考にすることと記載しています⁴。設計の早い段階から組み込む発想は、後から手直しをするよりも手間が少なく済みます。

後から対策を足すことよりも、設計の段階でセキュリティを組み込んでおくことのほうが、公共のWeb案件では前提として求められています。案件に入る早い時期に、この考え方を提案に反映できるかどうかが、信頼を得る分かれ目になります。

設計段階の話は、契約が始まってからでは間に合わないことがあります。提案の時点で、セキュリティを組み込む前提を示せるかどうかが、案件の初期段階での信頼につながります。

暗号化・電子証明書・鍵管理を分けて確認する

具体的に何を整えるかというと、ウェブサイトと利用者間の通信の暗号化、電子証明書の利用、そして暗号鍵管理を通じて、適切な通信データ管理を行うことが求められます⁵。さらに、電子証明書による認証によって、ウェブサーバーの正当性を利用者が確認できるようにすることも記載されています⁶。

3つの言葉は似ていますが、確認する対象は異なります。暗号化は通信の内容そのものを守る仕組みです。電子証明書はサーバーの正当性を利用者が確かめられるようにする仕組みです。鍵管理はその証明書や暗号化の鍵を適切に保つ運用です。証明書を導入した時点で満足してしまうと、鍵の管理という運用側の要件が抜け落ちやすくなります⁵。3つを分けて確認しておくと、提案の中で抜けなく説明できます。

提案の場では、この3つのうちどこまでを担当するのかを明確にしておくと、役割分担の話がスムーズに進みます。暗号化や証明書の設定だけを担当する案件もあれば、鍵の管理体制まで含めて任される案件もあります。どちらを求められているかは案件ごとに異なるため、早い段階で確認しておくと後の手戻りを避けられます。

観点	目的	見落としやすい点
通信の暗号化	通信の内容を第三者に読み取られないよう保護する	導入後も継続して見直す運用が必要な点
電子証明書	ウェブサーバーの正当性を利用者が確認できるようにする	有効期限の管理や更新の手続き
暗号鍵管理	証明書や暗号化に使う鍵を適切に管理する	証明書を入れただけでは完了しない点

出典：デジタル庁「ウェブサイトガイドライン」（2025年9月30日）をもとに作成

通信の信頼性を保つ仕組みは、サイトが動いている間だけの話ではありません。サイトを閉じる場面にも、同じように設計が求められます。

4. 閉じるときにも設計が要る

ドメインの管理は、公開中も終了後も続く

ドメインの管理は、公開している間だけ意識すればよいものではありません。ウェブサイトガイドラインは、ドメイン管理ガイドラインに基づき、運用の見直しと管理プロセスの整備を行った上で、ドメインの運用や命名等の管理を適切に行うことと記載しています⁷。サイトを立ち上げる時点だけでなく、動いている間も見直しの対象になります。

運用の見直しというと、日々の更新作業を思い浮かべやすいですが、対象にはドメインそのものの管理体制も含まれます。誰が更新の権限を持ち、いつ見直すかという運用のルールを整えておくことが、この要件の中身です⁷。

ドメインの管理者は、引き継ぎのタイミングで変わることもあります。誰が更新の権限を持ち、いつ見直すかを記録に残しておくことが、運用の見直しを続けるための土台になります⁷。この記録が整っていないと、担当が変わった瞬間に管理そのものが止まってしまいます。

移行・廃止でも利用者を守る

サイトを移行したり廃止したりする場面では、別の要件が加わります。ウェブサイトガイドラインは、非goドメインを移行又は廃止する場合、利用者が不正なウェブサイトへ誘導されないよう、必要な対策を講じることと記載しています⁸。閉じる作業を後回しにすると、この対策が抜けたまま公開が終わることになりかねません。

移行や廃止の計画は、契約の終盤ではなく、契約の初期段階で提案の中に含めておくと、後になって対策が漏れる事態を避けやすくなります。

サイトを作るときの設計よりも、閉じるときの設計のほうが忘れられやすい領域です。始まりの提案書には書かれても、終わりの手続きは案件の後半になって初めて具体的になることがあります。

出典：デジタル庁「ウェブサイトガイドライン」（2025年9月30日）をもとに作成

技術の寿命、長期可読性、通信の信頼性、閉じるときの設計。ここまでの4つは、いずれも文書として決まっている場所がある要件でした。次に確認したいのは、これらをリモートで進めるフリーランスの案件に、実際どう関わっていくかという点です。

5. リモート・フリーランス案件でどう関わるか

提案・見積りの前に、確認する文書を決めておく

公共のWeb案件では、案件ごとに従うべき文書が既に存在しています。各府省は統一基準群に基づき作成した情報セキュリティポリシーに従って、情報セキュリティ対策を実施することと記載されています³。つまり、何を守るかは案件の担当者の裁量ではなく、あらかじめ決まっている場所を確認すれば分かる話です。

「公共は決まりが多い」と聞くと身構えてしまいますが、実際には決まりごとが多いわけではなく、決まっている場所がはっきりしているというだけです。提案や見積りの前に、対象となるガイドラインや情報セキュリティポリシーを確認する、という手順を先に組み込んでおけば、案件が進んでからの手戻りを減らせます。この手順を癖にしておくと、初めて関わる府省の案件でも迷わず動けるようになります。

リモートでも関われる領域

技術の寿命、長期可読性、通信の信頼性、ドメイン管理は、いずれも現地に常駐しなければ確認できない要件ではありません。文書を読み、設計や運用の方針にどう反映するかを詰める作業は、リモートでも十分に進められます。Remoguは案件の90%以上がフルリモート可能なリモートワーク案件特化のエンジニアマッチングです⁹。公共のWeb案件に関わる経験を積みたい場合も、まずは自分の経験に近い案件がどのくらいあるかを確かめてみると、次の一歩が具体的になります。

公共のWeb案件では、大規模なシステム開発の経験だけが評価されるわけではありません。運用や保守を通じて、可読性の維持や通信の管理に向き合ってきた経験も、同じように活かせる場面があります。積み上げてきた運用の経験を、公共の案件という新しい環境でどう活かせるかを考えてみると、案件の幅が広がります。

提案書や見積りを作る前に、次の3点を前提として置いておくと、質疑の場でも慌てずに答えられます。ひとつは技術選定の根拠で、調達にあたって参照する考え方はウェブサイトガイドラインに記載されています¹。もうひとつは参照する文書の存在で、案件ごとに従うべき情報セキュリティポリシーがあることも記載されています³。この2点を確認したうえで、通信やドメインの管理体制を合わせて整理しておくと、抜けの少ない提案になります。

確認項目	具体的に確認すること	関連する要件
技術選定の根拠	提案する技術に更新の見通しがあるか	調達段階の技術の寿命
参照する文書	案件で従うべき情報セキュリティポリシーがどれか	各府省の情報セキュリティ対策
通信・ドメインの管理体制	暗号鍵管理やドメインの運用ルールが整っているか	通信の信頼性とドメイン管理

ここまでの内容を、案件に入る前の確認事項として整理します。

6. まとめ

公共のWeb案件で押さえておきたい技術要件は、4つの場面に分かれています。調達の時点では技術の寿命が問われます¹。公開後は長期の可読性が問われます²。日々の運用では通信の信頼性が問われ、サイトを閉じる場面ではドメインの管理が問われます。

いずれも、決まりごとの多さではなく、決まっている場所の分かりやすさとして捉えると、提案や見積りに落とし込みやすくなります。案件に入ってから資料を探すのではなく、入る前にこの4つの場所を確認しておくと、質疑の場での答え方が変わります。同じ資料を土台にして話せると、発注元との対話も一段階スムーズになります。

これらの前提を押さえた上で、公共のWeb案件にリモートでどう関わるかを考えてみると、次の一歩が具体的になります。まずは自分の経験と技術要件が噛み合う案件がどのくらいあるか、Remoguで確かめてみることから始められます⁹。

7. よくある質問

公共のWeb案件では技術を自由に選べないのですか

自由に選べないというより、選ぶ際に確認する観点が決まっています。特に、サポートが終了している技術等を対象にしないよう努めることが記載されているため、この点を外さない技術であれば、提案の幅は残っています¹。

どの文書を読めばよいですか

この記事で扱った内容は、デジタル庁のウェブサイトガイドラインに基づいています¹。実際の案件では、その案件が従う情報セキュリティポリシーなど、府省ごとに指定される文書も合わせて確認することになります³。この記事で紹介した範囲を超える内容は、案件ごとに提示される資料で確認してください。

古い技術を使っている既存サイトはどうすればよいですか

この記事で扱った資料は、主に新たに調達する場面を念頭にした内容です。既存サイトの改修をどこまで求めるかについては、この記事で紹介した範囲には記載がありません。案件ごとの要件を、担当者や発注元と確認する必要があります。提案の段階で改修の範囲がどこまで求められているかを早めに確認しておくと、後戻りを避けられます。

証明書を入れれば通信の要件は満たせますか

証明書の導入だけでは十分ではありません。ウェブサイトガイドラインは、通信の暗号化や電子証明書の利用に加えて、暗号鍵管理を通じた適切な通信データ管理を求めています⁵。証明書を入れたあとの鍵の管理まで含めて、要件と捉えておくと安心です。鍵の更新や保管の手順まで案件の中で確認しておくと、証明書だけを整えて終わる状態を避けられます。

リモートでも公共のWeb案件に関われますか

関わることができます。技術の寿命や長期可読性、通信の信頼性といった要件を確認し、設計や提案に反映する作業は、現地への常駐を前提としないためです。Remoguは案件の90%以上がフルリモート可能なリモートワーク案件特化のエンジニアマッチングです⁹。公共のWeb案件に関心がある場合は、まず登録して自分の経験に合う案件を確かめてみることから始められます。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 デジタル庁「ウェブサイトガイドライン」DS-680.1 6.3 サポートが終了する技術等の取扱い（2025年9月30日）
＊2 デジタル庁「ウェブサイトガイドライン」DS-680.1 6.3.1 可読性の維持（2025年9月30日）
＊3 デジタル庁「ウェブサイトガイドライン」DS-680.1 5 ウェブサイトの情報セキュリティの確保（2025年9月30日）
＊4 デジタル庁「ウェブサイトガイドライン」DS-680.1 5 ウェブサイトの情報セキュリティの確保（2025年9月30日）
＊5 デジタル庁「ウェブサイトガイドライン」DS-680.1 5.1 通信データ及び情報発信源の信頼性確保（2025年9月30日）
＊6 デジタル庁「ウェブサイトガイドライン」DS-680.1 5.1.1 TLSの利用（2025年9月30日）
＊7 デジタル庁「ウェブサイトガイドライン」DS-680.1 3.1 適切なドメイン管理の実施（2025年9月30日）
＊8 デジタル庁「ウェブサイトガイドライン」DS-680.1 3.1.1 非goドメインサイトの移行又は廃止（2025年9月30日）
＊9 Remoguサイト公開情報（フルリモート可能案件の割合）