業務委託の打ち合わせで、「アーキテクチャはお任せします。何かあったら相談させてください」と言われました。その「何か」がいつまでで、どこまでを指すのか、聞き返せないまま会議が終わります。フリーランスとしてアーキテクトの仕事を外から引き受けるとき、設計の判断の結果までどこまでも背負わされるのではないかという不安は、この曖昧さから生まれます。アーキテクトの仕事は、判断と一緒に、その根拠を納めます。

1. 外から関わるアーキテクトが迷う「どこまで」

組織の中と外での、手元に残るものの違い

組織の中のアーキテクトは、設計の判断を下したあとも、実装や運用の場に居続けます。判断の結果が想定と違ったときは、その場で設計を見直せます。判断の責任と、それを直す手段が、同じ手元にある状態です。

一方、業務委託で外から関わると、契約で決めた範囲が終わった時点で手が離れます。実装の進め方や運用中の判断は、委託元の事業者が持つ領域です。契約の範囲より外にある部分は、自分の手では直せません。ここは公的な資料にある規定ではなく、書き手の見立てです。

図の作成：Remogu編集部。書き手の見立てを整理したもので、統計データではありません

範囲を先に決めておく理由

「何かあったら相談」は、相談を受ける期間も、相談の中身も決めていない言い方です。相談がどこまで続くのか分からなければ、判断の結果をどこまでも背負うように見えます。冒頭の不安の正体は、アーキテクトの仕事の終わりが決まっていないところにある、と書き手は見ています。

そのため、業務委託では範囲を先に言葉にする作業が、設計そのものと同じ重さを持ちます。判断を下す範囲、実装に関わる範囲、運用に入った後に相談を受ける範囲を、別々に決めておきます。これも公的な資料の記述ではなく、書き手の推論です。

では、決めた範囲を何に残せばよいのでしょうか。次の節では、公的なガイドラインを参照点にして、設計書と判断の根拠の扱いを見ます。

2. 設計書と判断の根拠を成果物にする

政府調達の解説書にある設計書の扱い

この節で参照するデジタル庁の解説書は、政府情報システムの調達や運用を対象にしたものです。民間の案件の決まりではありません。ただ、外から設計を引き受けるときに「何を納めるのか」を考える参照点として、読める部分があります。

政府情報システムの調達では、設計・開発の工程でSaaSのサービスや機能をそのまま利用する場合、設計書の代わりに、設定情報と、設定情報を定めた根拠等を文書として取りまとめる例が、デジタル庁の解説書に挙げられています¹。挙げられているのは利用の仕方の一例で、設計書全般が不要という意味ではありません。

同じ解説書は、予算マネジメントの要素として、新規参入業者にとってリスク要因と捉えられないように、システム資産台帳や設計書等のドキュメント類の整備に努めることを挙げています¹。これは発注側の府省が努める事項として書かれたものです。フリーランスに設計書の整備を求める根拠としては使えません。

判断の根拠を残すという見立て

二つの記載は別の文脈で書かれています。それでも、設定や設計書を、あとから引き継ぐ側が読める形で残す考え方にはつながります。外から入るアーキテクトにとっては、なぜその構成を選んだのかという判断の根拠が、後任や委託元への引き継ぎで手がかりになる、というのが書き手の見立てです。

ただし、解説書に出てくるのは「設定情報を定めた根拠等」までです。設計上の意思決定を一件ずつ記録せよという指示は、引用した部分には書かれていません。民間の案件で何をどの形式で納めるかは、契約の前に委託元と話し合って決めることになります。

解説書の記載と、外から納める物の見立て

次の表は、解説書の二つの記載を、民間の案件で外から設計を引き受ける場合に置き換えて並べたものです。左の列は政府調達の場合の扱いで、解説書に書かれている範囲にとどめています。右の列は書き手の見立てで、契約の前に委託元と話し合う題材として使えます。判断の根拠に当たる行は、解説書には対応する記載がありません。

項目	政府調達の場合の扱い	外から納める物の見立て
SaaS利用時の設定情報と根拠	設計書の代わりに、設定情報と、設定情報を定めた根拠等を文書にまとめる例が挙げられています	設定の一覧と、その値を選んだ理由を一組にして納めます
設計書等のドキュメント類	発注側が、新規参入業者のリスク要因にならないよう整備に努める事項として挙げられています	後任が読んで引き継げる形かを、納める前に委託元と合わせます
なぜその構成を選んだか	引用した部分には記載がありません	選んだ構成と、見送った案の理由を、設計書の中に書きます

3. 調達仕様書に並ぶ成果物の取扱い事項

発注者が調達仕様書に書く3つの事項

政府情報システムの調達では、調達仕様書に「成果物の取扱いに関する事項」として、知的財産権の帰属、契約不適合責任、検収等を記載するとデジタル庁の解説書は述べています¹。書くのは発注者です。受注者が自分で決めて書き込む欄ではありません。

成果物の権利の細部は、この記事では扱いません。ここで見たいのは、成果物の話をするときに、権利、不具合への対応、受け取りの確認が、同じ場所に並んで書かれているという点です。

出典：デジタル庁「DS-110 デジタル・ガバメント推進標準ガイドライン解説書」（2026年6月12日）をもとに作成。記載事項は「検収等」とされており、3つで全部ではありません

3つを一つの規定として読まない

知的財産権の帰属、契約不適合責任、検収は、解説書では記載事項として並べられているだけです。一つの規定にまとまっているわけではありません。検収を済ませたことが契約不適合責任にどう影響するかは、引用した抜粋には書かれていません。

民間の案件でも、同じ三つの話題を契約の前に出しておけば、あとで行き違いが起きにくくなる、と書き手は考えています。これは見立てです。どの項目を、どの書類に、どの順で書くかは、案件ごとに委託元と決めます。

三つのうち、設計の成果物にいちばん近いのが検収です。次は、検収の基準をどの段階で合わせておくかを見ます。

4. 検収の基準を設計の段階で合わせる

検収を行うのは発注者

政府情報システムの調達では、情報システムの納品に当たって、受入テストを通じた修補等の措置を講じ、合否判定基準を満たすことを確認した上で検収を行うと、デジタル庁の解説書は述べています¹。確認して検収を行うのは政府側で、受注者が合否判定基準を一方的に決める仕組みとは書かれていません。

そこで、書き手の見立てです。外から設計を引き受ける側は、完了の条件を契約の前に書面で合わせておくと、納品のあとで「何をもって完了か」を争わずに済みます。合否判定基準を受注者側から提案して、委託元と合意する形です。解説書の記載から導いたものではありません。

設計の成果物で合わせる3つの点

次の表は、検収で確かめる内容を、設計の成果物に当てはめたものです。左は解説書に挙げられている要素で、中央に政府調達での扱いを置きました。右の例は書き手の見立てです。合否判定基準、受入テストの範囲、修補の扱いの三つが、契約の前に合わせておく題材になります。受入テストの進め方そのものは、別の記事で扱っています。

検収で確かめること	政府調達の場合の扱い	設計の成果物での例（書き手の見立て）
合否判定基準	満たすことを確認した上で検収を行います	設計書のどの項目が揃えば完了かを、契約の前に書面にします
受入テストの範囲	受入テストを通じて修補等の措置を講じます	設計の成果物のうち、受入テストの対象に入る部分と入らない部分を分けます
修補の扱い	受入テストを通じた修補等の措置が挙げられています	修補に応じる範囲と、別の依頼として扱う範囲を分けます

受け取りの拒否に関する例示

公正取引委員会のフリーランス法のパンフレットには、ハラスメント対策の説明のなかで、「過大な要求」の例として、明確な検収基準を示さずに、嫌がらせのためにフリーランスの給付の受領を何度も拒み、やり直しを強要することが挙げられています²。これは、いくつかの条件がそろった例の一つです。

検収を拒まれたこと自体が、この例に当たるわけではありません。ただ、基準を示さないまま何度も受け取りを拒むことが、例示として取り上げられている点は、基準を先に書面にしておく理由の一つになります。

検収の基準を決めたあとにも、運用に入ってから問題が見つかる場合があります。次は、運用に入った後の責任をどこで区切るかです。

5. 運用に入った後の責任の区切り

契約不適合のときの追完の請求

政府情報システムの調達では、納品された成果物が契約の内容に適合しない契約不適合が発見された場合、民法に基づいて成果物の修補などによる履行の追完を請求できると、デジタル庁の解説書は説明しています¹。請求する側は発注者です。

ただし、これは政府調達の解説書にある説明です。民間の案件で追完がどの範囲まで求められるかは、契約書の定め方で変わります。追完を請求される前提で身構えるより、契約書に何が書かれているかを、受ける前に読んでおきます。

責任を負う期間や上限は、引用した解説書の抜粋には書かれていません。期間の数え方は、契約不適合責任の期間を扱った別の記事で確かめられます。この記事では、期間ではなく、責任の範囲をどこで区切るかに話をしぼります。

設計の判断と運用の変更を分けて記録する

運用に入ってから問題が出たとき、何の問題かを切り分けられる状態にしておくと、委託元との話し合いが進めやすくなります。書き手の見立てです。設計の判断の誤りと、実装の不具合と、運用で前提が変わったことは、別の種類の出来事だからです。

たとえば、設計の時点で書いた前提が運用に入ってから変わった場合は、判断を下した時点の前提が変わったのであって、判断そのものの誤りとは限りません。判断の根拠を成果物に書いておけば、下した時点の前提が残ります。運用で前提が変わったのかどうかを、あとから比べられます。

図の作成：Remogu編集部。書き手の見立てを整理したもので、統計データではありません

契約の範囲に実装が含まれていなければ、実装の不具合は自分の範囲の外にあります。範囲に含めるなら、設計書との差を確かめる手順も、一緒に決めておきます。運用の変更は、委託元の事業者が持つ領域が中心です。運用に入った後の相談を受けるかどうかは、契約で決めます。

では、この区切りを契約に載せるには、受ける前に何を決めておけばよいのでしょうか。次は、受ける前に決めておく項目です。

6. 受ける前に決めておくこと

契約の前に合わせる5つの項目

これまでの節で出てきた論点から、外から設計を引き受ける前に委託元と合わせておく項目を5つ挙げます。右の列は書き手の見立てで、公的な資料の規定ではありません。成果物の一覧と納める時点まで書いておくと、何を納めれば仕事が終わるのかを、双方が同じ形で読めます。

決めること	例（書き手の見立て）
成果物の一覧	設計書、設定の一覧、判断の根拠の文書を挙げ、それぞれを納める時点を書きます
判断の根拠の書き方	選んだ構成、見送った案、その理由を、設計書のどこに書くかを合わせます
合否判定基準	設計書のどの項目がそろえば完了かを、契約の前に書面にします
修補の範囲	修補に応じる範囲と、別の依頼として扱う範囲を分けます
運用後の相談の窓口	相談を受ける期間と、相談の中身の範囲を決めます

5つの項目は、冒頭の「何かあったら相談」を言葉にし直したものです。いつまでの相談かは窓口の項目に、どこまでの相談かは修補の範囲の項目に、それぞれ当たります。

受け取りの拒否と、成果物の明示

フリーランス法の対象になる取引では、受領拒否は、フリーランスに責任がないのに、委託した物品や情報成果物の受取を拒むことを指し、7つの禁止行為の1つに数えられています²。自分の案件が対象になる取引かどうかは、公正取引委員会の資料で確かめます。引いた抜粋には、対象になる取引の条件は載っていません。

成果物と納める時点を契約の前に書面にしておくと、何をもって納品とするのかで行き違いにくくなります。これも書き手の見立てです。受領拒否の規定は、受け取りを拒まれる場面を直接防ぐものではありません。何を納めるかが明示されていれば、拒まれたときに、契約書のどの項目に戻って話せばよいかが分かります。

ただし、受領拒否の定義には「フリーランスに責任がないのに」の条件がついています。納めた成果物が契約の内容に合っていない場合の扱いは、前の節で見た契約不適合の話で、別の整理です。次は、これらを引き受ける順番に並べ直します。

7. 外から関わる働き方へ移る順番

範囲から契約まで、5つの順番

順番は、引き受ける範囲、成果物の定義、検収の基準、運用後の責任、契約の5つです。範囲が決まっていなければ、成果物の一覧は書けません。成果物が決まっていなければ、検収の基準を合わせる相手の項目が定まりません。書き手の見立てとして、この順に進めます。

図の作成：Remogu編集部。書き手の見立てを整理したもので、統計データではありません

最初に範囲を置くのは、冒頭の「何かあったら」が、範囲を決めていない言い方だったからです。判断を下す範囲、実装に関わる範囲、運用に入った後に相談を受ける範囲を分けておけば、「何か」は契約の言葉になります。

政府調達の解説書が成果物の取扱いに検収と契約不適合責任を並べていたように、成果物、検収、責任は、一つの契約のなかで順に決めていく項目です。契約は最後に置きます。前の4つが言葉になっていれば、契約書の文面は、それを写す作業になります。

引き受ける前の一歩

Remogu（株式会社LASSIC運営）は、リモートワーク案件特化のエンジニアマッチングで、案件の90%以上がフルリモート可能です。場所に縛られずに設計に関われる案件から、自分の経験に近いものを探せます。まず登録して、自分の経験に合う条件を確かめてみましょう。表の5つの項目を手元に置いて案件を読むと、範囲と成果物の書かれ方の違いが見えてきます。

外から設計を引き受けるとき、背負う範囲は、契約で決められます。範囲と成果物と検収の基準を先に言葉にしておけば、「何かあったら相談」の「何か」は、契約の言葉に置き換わります。アーキテクトの仕事は、判断と一緒に、その根拠を納めます。

8. よくある質問

アーキテクトの経験だけでフリーランスとして受けられる仕事はありますか

範囲を区切りやすい仕事として、設計レビューや技術選定の支援が考えられます。判断を下す範囲と、納める成果物を先に決めやすいからです。これは書き手の見立てで、実装や運用まで求める案件もあります。どの範囲を引き受けるかは、案件ごとに委託元と合わせます。

ソリューションアーキテクトやクラウドアーキテクトでも同じ考え方ですか

同じ考え方が使える、と書き手は見ています。範囲を決め、成果物と判断の根拠を納め、検収の基準を合わせる順番は、肩書きによって変わらないからです。デジタル庁の解説書は、SaaSのサービスや機能をそのまま利用する場合に、設定情報とその根拠等を文書にまとめる例を挙げています¹。

クラウドの設定を成果物にする仕事なら、この考え方が近くなります。ただし、解説書が挙げているのはSaaSを利用する場合の例です。クラウドの設定にそのまま当てはまるとは書かれていません。

設計した仕組みが運用に入ってから問題が出たら、いつまで責任を負いますか

期間は契約で決まります。デジタル庁の解説書は、契約不適合が発見された場合に、民法に基づいて修補などによる履行の追完を請求できると説明していますが、期間は引用した抜粋に書かれていません¹。民間の案件では、契約書の定めを受ける前に読みます。期間の数え方は、契約不適合責任の期間を扱った別の記事で確かめられます。

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

出典・参考情報

＊1 デジタル庁「DS-110 デジタル・ガバメント推進標準ガイドライン解説書」（2026年6月12日・2026年10月確認）
＊2 公正取引委員会「フリーランス・事業者間取引適正化等法」（2024年・2026年10月確認）