フリーランス発注のセキュリティポリシー設計｜権限・契約・責任の決め方

エンジニア不足を外部のフリーランスで補おうと発注を検討したものの、上長から「セキュリティは大丈夫なのか」「もし情報漏洩したらどうするのか」と問われて、言葉に詰まった経験はないでしょうか。あるいは発注の直前に、「このフリーランスに社内システムやソースコードのアカウントをどこまで渡してよいのか」で手が止まってしまったかもしれません。

外部のフリーランスエンジニアには、社内システムやソースコード、ときには顧客データへのアクセスを与えることになります。しかし、どこまで許可してよいかの判断基準が社内になく、正社員向けのセキュリティルールはあっても外部人材にそのまま適用してよいか分からない。多くの発注担当者がこの段階で立ち止まります。情報セキュリティの専門家でなければ、何から手をつければ漏洩を防げるのか、そして万一漏洩が起きたら自社がどんな責任を負うのかが見えにくいのは当然です。

この記事では、フリーランスエンジニアへの発注で必要になるセキュリティポリシーの設計を、「入場前（権限の判断と契約）→ 稼働中（運用と監視）→ 退場時（アクセスの失効）」という時系列の実務手順に沿って解説します。抽象的な原則の羅列ではなく、「コードリポジトリ・インフラ・顧客データのどこまで許可してよいか」という判断軸や、専任のセキュリティ担当がいない小規模な体制でも回せる現実的なチェックリストを中心に整理します。

読み終えたときには、アクセス権限の付与方針・入退場の手順・契約に盛り込むべき条項・漏洩時の責任の考え方が一通り整理でき、上長にも説明できる状態を目指します。「次に契約法務の詳細を確認すれば発注に進める」という見通しを立てるための土台として活用してください。

フリーランスエンジニアへの発注でセキュリティポリシー設計が必要な理由

フリーランスエンジニアに発注すること自体は、もはや珍しいことではありません。問題になりやすいのは、「正社員と同じ感覚」でアクセス権限を渡してしまうことです。外部人材には、正社員にはない固有の論点がいくつもあります。まずはそこを押さえないと、どこに気をつければよいかの当たりがつきません。

外部フリーランスならではのセキュリティ論点

外部のフリーランスは、正社員と次の3点で大きく異なります。

• 物理的に社外で作業する：自宅やコワーキングスペースなど、自社が管理できない環境で作業します。社内ネットワークの境界防御や、オフィスの入退室管理といった前提が効きません。端末も基本的にはフリーランス本人の私物です。
• 複数のクライアントを並行している：フリーランスは同時期に複数の発注元と契約していることが一般的です。自社のソースコードや情報が、意図せず他社の作業環境と混在するリスクや、競合他社の案件を並行しているケースを想定しておく必要があります。
• 契約に期限がある：正社員と違い、契約は数か月単位で終了します。つまり「権限を渡す」だけでなく「確実に権限を回収する」ことが、最初から運用の前提に組み込まれていなければなりません。

これらは「フリーランスが危険だ」という話ではなく、正社員向けのルールがそのままでは当てはまらない、という構造的な違いです。だからこそ、外部委託向けに考え方を整理し直す必要があります。

ありがちな失敗

ポリシーが整備されていない状態で発注すると、次のような失敗が起こりがちです。

• 権限の過剰付与：「いちいち権限を絞るのは面倒だから」と、管理者権限や本番環境へのフルアクセスをまとめて渡してしまう。必要のない範囲まで触れる状態は、悪意がなくても事故（誤操作・誤削除）の温床になります。
• 権限の不足付与：逆に渡す権限を絞りすぎて作業が進まず、その都度追加付与を繰り返すうちに、誰が何の権限を持っているか分からなくなる。
• 退場時の失効漏れ：契約終了後も GitHub やクラウド、SaaS のアカウントが有効なまま残ってしまう。これは「アクセスできる人が増え続ける」状態であり、最も見落とされやすく、かつ漏洩リスクが高いポイントです。
• 属人的な口頭管理：「あの権限は私が渡したはず」と、付与の記録が担当者の記憶に依存している。担当者の異動や退職で、誰がどこまでアクセスできるかが分からなくなります。

これらの失敗は、いずれも「その場の判断」で進めてしまうことに原因があります。逆に言えば、発注前に判断基準と手順を決めておけば、ほとんどは仕組みで防げます。次の章から、その判断基準と手順を順番に見ていきます。

発注前に決めるアクセス権限の判断基準（最小権限の原則）

外部フリーランスへの発注で最初に決めるべきは、「どこまでアクセスを許可するか」です。ここがあいまいなまま発注すると、過剰付与にも不足付与にも振れてしまいます。判断の軸になるのが、セキュリティの基本原則である「最小権限の原則」です。

最小権限の原則とは（外部人材への当てはめ方）

最小権限の原則（Principle of Least Privilege）とは、「業務に必要な最小限の権限だけを与える」という考え方です。情報処理推進機構（IPA）も、中小企業の情報セキュリティ対策の基本としてアクセス権限の適切な管理を挙げています（IPA 中小企業の情報セキュリティ対策ガイドライン）。

外部人材に当てはめるときのコツは、発想を逆にすることです。正社員には「とりあえず標準権限を渡し、必要に応じて絞る」ことが多いですが、外部フリーランスには「まず全部閉じた状態から始め、依頼した業務に必要なものだけを開ける」と考えます。判断のたびに「この権限は、お願いした作業に本当に必要か」を問い直すことで、過剰付与を防げます。

権限を考えるときは、次の3つを分けて整理すると判断しやすくなります。

1. 何を見られるか（参照権限）
2. 何を変更・作成できるか（編集・書き込み権限）
3. 何を削除・公開できるか（破壊的・対外的な操作の権限）

下に行くほど影響が大きくなります。依頼業務に「3」が本当に必要なケースは多くありません。

3レイヤー別の権限判断（リポジトリ／インフラ・本番／顧客データ）

「最小権限」は抽象論で終わらせると実務に落ちません。アクセス対象を3つのレイヤーに分け、それぞれで「許可してよい範囲」「条件付きで許可する範囲」「原則避ける範囲」を決めておくと、発注時の判断が一気に楽になります。

ポイントは、管理者権限と本番への破壊的操作は原則として外部人材に渡さないことです。コードのマージはプルリクエストのレビューを介す、本番へのデプロイは社内のメンバーが実行する、といった形で「最後のひと押し」を社内に残すだけでも、リスクは大きく下がります。これは優秀なフリーランスを信用しないということではなく、事故が起きたときに被害が広がらないようにする仕組みです。

本番データを触らせないための工夫

3レイヤーの中でも、顧客データ・個人情報の扱いは最も慎重に設計したい部分です。開発作業で本物の個人情報が必要になる場面は、実は多くありません。次のような工夫で、本番データに触れさせずに作業を進められます。

• マスキング（匿名化）データを使う：氏名・メールアドレス・電話番号などを別の値に置き換えたデータを開発環境に用意します。データの構造や量は本番に近づけつつ、中身は実在しない値にします。
• ダミーデータ・テストデータを用意する：そもそも本番から持ってこず、開発用に生成したデータで作業してもらいます。
• 本番データを開発環境に持ち込ませない：「開発環境には本番の機密情報を置かない」という原則を明確にします。開発環境は本番ほど厳重に守られていないことが多く、ここが漏洩経路になりやすいためです（NRIセキュア 開発環境の内部不正対策）。
• 閲覧範囲を限定する：どうしても本番データの参照が必要な場合は、対象を必要な範囲に絞り、誰がいつアクセスしたかのログを残す前提にします。

「本番データを触らせない」という方針を最初に決めておくと、その後の権限設計がぐっとシンプルになります。

入場前から退場まで：アカウント・アクセスの管理フロー

権限の判断基準が決まったら、次は「誰が・何を・いつ付与し、いつ回収するか」という運用のフローを決めます。ここで属人的な口頭管理から抜け出せるかどうかが、退場時の失効漏れを防げるかの分かれ目になります。専任の担当がいない小規模な体制でも、簡単な棚卸し表とチェックリストがあれば十分に回せます。

入場時のアカウント発行チェックリスト

稼働開始時には、付与するアカウント・権限を一覧化し、棚卸し表に記録します。記録に残すことで「誰が何を持っているか」が可視化され、退場時の回収漏れを防げます。発行時のチェック項目は次のとおりです。

• 付与するアカウント・サービスを棚卸し表に列挙したか（GitHub、クラウド、VPN、SaaS、社内ツール、コミュニケーションツールなど）
• 各アカウントの権限を、依頼業務に必要な最小範囲に設定したか
• 本番環境・管理者権限を付与していないか（付与する場合は理由を記録したか）
• 共有アカウントではなく、本人専用のアカウントを発行したか
• 多要素認証（MFA）を有効にしたか
• 付与日・付与者・対象サービス・権限レベルを棚卸し表に記録したか

重要なのは、「付与した権限は、必ず退場時の失効リストに入れる」という原則です。発行時の棚卸し表が、そのまま退場時の回収チェックリストになるように作っておきます。

稼働中の基本運用

稼働が始まったあとも、最低限おさえておきたい運用上の基本があります。難しい監視ツールを導入しなくても、次の3点を徹底するだけで多くのリスクを減らせます。

• 多要素認証（MFA）を必須にする：パスワードだけのログインは、流出時にそのまま不正アクセスにつながります。MFA を有効にしておくと、パスワードが漏れても突破されにくくなります。
• 共有アカウントを禁止する：「複数人で1つのアカウントを使い回す」状態は、いざというときに「誰が操作したか」を特定できなくします。フリーランスごとに専用アカウントを発行します。
• 操作ログを残す：誰がいつ何にアクセスしたかの記録（操作ログ）を残せるサービスでは、記録を有効にしておきます。日常的に監視できなくても、何か起きたときに事実を確認できる状態にしておくことが大切です（IT MITENA 情報漏えいを防ぐ権限設計）。

これらは「フリーランスを疑う」ための仕組みではなく、お互いを守るための仕組みです。記録が残っていれば、万一のときに「誰の操作が原因ではないか」を切り分けることもでき、無用な疑いから双方を守れます。

退場時の失効チェックリスト

契約終了時に最も起こりやすいのが、アカウントの失効漏れです。入場時に作った棚卸し表を見ながら、付与したものを1つずつ確実に回収します。退場時のチェック項目は次のとおりです。

• 棚卸し表に記載した全アカウントを無効化・削除したか
• GitHub などのリポジトリから、コラボレーター・メンバー権限を削除したか
• VPN・社内ネットワークへのアクセス権を失効したか
• SaaS・クラウドサービスのアカウントを無効化したか
• 共有していた認証情報（APIキー・トークン・共有パスワード等）を無効化・再発行したか
• 貸与した端末・媒体があれば返却を受けたか
• 契約に基づく秘密情報・データの返却または破棄を確認したか
• 失効日・実施者を棚卸し表に記録したか

特に見落としやすいのが、APIキーやトークンといった「人に紐づかない認証情報」です。アカウントを消しても、共有していたキーが生きていればアクセスできてしまいます。契約終了時にはこれらを再発行（ローテーション）しておくと安全です。「付与したものは必ず失効リストに入れる」という原則を守れば、この回収作業は機械的なチェックで完了できます。

契約・NDAに盛り込むセキュリティ条項

権限設計と運用フローを整えても、それを担保する契約がなければ実効性は半減します。フリーランスへの発注では、業務委託契約と NDA（秘密保持契約）にセキュリティ条項を盛り込むことが欠かせません。専門家でなくても、何を確認すればよいかのポイントを押さえておきましょう。

NDA と業務委託契約のセキュリティ条項の役割分担

NDA と業務委託契約は、どちらも秘密情報を守るための文書ですが、役割が少し異なります。

• NDA（秘密保持契約）：秘密情報の取り扱いに特化した契約です。商談・打ち合わせの段階など、業務委託契約を結ぶ前から情報を共有する場合に、先行して締結することがあります。「秘密情報をどう扱うか」だけを切り出して合意する文書だと考えると分かりやすいでしょう。
• 業務委託契約のセキュリティ条項：実際の業務を委託する契約の中に、情報管理・秘密保持に関する条項を組み込むものです。NDA と内容が重なることもありますが、業務委託契約の中で改めて秘密保持や情報管理の義務を定めておくのが一般的です。

実務上は、業務委託契約の中に秘密保持・情報管理の条項を盛り込むか、業務委託契約とNDAを併用する形が多くなります。どちらの形をとるにせよ、「秘密情報の扱いについて書面で合意がある」状態を作ることが目的です。

最低限おさえる情報管理条項

発注者目線で、契約に盛り込んでおきたい情報管理条項の要点を整理します。すべてを自分で書き起こす必要はありませんが、契約書をレビューするときに「これらが入っているか」を確認できると安心です。

• 秘密情報の定義：何が秘密情報にあたるかを明確にします。ソースコード・顧客データ・設計資料・アカウント情報など、対象範囲をあいまいにしないことが大切です。
• 目的外利用の禁止：受け取った秘密情報を、委託した業務以外の目的（他案件への流用・自己の学習目的での蓄積など）に使わないことを定めます。
• 複製・第三者開示の禁止：秘密情報を無断で複製したり、第三者（フリーランスがさらに別の人に手伝わせる場合を含む）に開示したりすることを制限します。
• 返却・破棄義務：契約終了時に、預けた秘密情報やデータを返却または破棄することを義務づけます。前章の退場チェックリストと対応させると実効性が高まります。
• 再委託の制限：フリーランスが業務の一部をさらに別の人に委託すること（再委託）について、事前承諾を必要とするなどの制限を設けます。知らないうちにアクセスする人が増えるのを防ぐためです。
• 漏洩時の報告義務：万一の漏洩・インシデント発生時に、速やかに発注者へ報告する義務を定めます。発覚が遅れるほど被害は拡大するため、報告ルートを契約段階で決めておくことが重要です。

これらの条項は、フリーランスを縛るためというより、「お互いに何を守るかをあらかじめ合意しておく」ためのものです。契約の具体的な文言や、フリーランス新法を踏まえた契約全体のチェックについては、契約法務の観点で別途確認することをおすすめします。

情報漏洩が起きたときの責任と備え

ここまでは「漏洩を防ぐ」ための設計を見てきました。しかし発注担当者が本当に不安なのは、「もし防ぎきれず漏洩が起きたら、自社がどんな責任を負うのか」という点ではないでしょうか。この不透明さこそが、発注の意思決定を止める大きな要因です。責任の考え方を整理しておきましょう。

契約形態と責任分界

フリーランスへの発注でよく使われる契約形態には、「請負契約」と「準委任契約」があります。両者は責任の負い方が異なります。

• 請負契約：成果物の完成を約束する契約です。仕事の結果（完成した成果物）に対して責任を負い、成果物に欠陥があれば契約不適合責任を問われることがあります。
• 準委任契約：一定の業務を遂行することを約束する契約です。成果物の完成そのものではなく、専門家として求められる注意（善管注意義務）を払って業務を行うことに責任を負います。

セキュリティの文脈で重要なのが、準委任契約で問われる善管注意義務です。これは「善良な管理者の注意義務」の略で、その業務の専門家として通常期待される注意を払う義務を指します。フリーランスが故意または不注意で情報を漏洩させた場合、この義務違反や契約上の秘密保持義務違反として、損害賠償の対象となり得ます。

ここで誤解しやすいのが、「契約で全部フリーランスに責任を転嫁すれば、自社は安心」という考え方です。これは正しくありません。次に見るように、発注者自身も管理責任を負うためです。

発注者が負う管理責任

情報漏洩が起きたとき、責任はフリーランス側だけに留まりません。発注者（委託元）にも、委託先を適切に管理・監督する責任があります。

• 個人情報保護法の委託先監督義務：個人データの取り扱いを外部に委託する場合、委託元には委託先を必要かつ適切に監督する義務があります。委託先の選定や、契約による安全管理措置の取り決め、取り扱い状況の把握などが求められます（個人情報保護委員会 個人情報保護法ガイドライン）。つまり、フリーランスに丸投げして管理を怠れば、漏洩時に発注者側の監督責任が問われる可能性があります。
• フリーランス新法の観点：2024年11月1日に施行されたフリーランス・事業者間取引適正化等法（フリーランス新法）では、発注事業者に取引条件の書面等による明示などの義務が課されています（公正取引委員会 フリーランス法特設サイト）。セキュリティそのものを直接規定するものではありませんが、外部人材への発注では契約条件を書面で明確にしておくことが、新法対応の観点でも望ましい流れになっています。

これらは「発注者にも責任がある」という不安をあおるためではなく、だからこそ、ここまで述べてきた権限設計・運用・契約条項が「適切な管理」の実態になる、という話です。きちんとポリシーを設計して運用していること自体が、発注者が管理責任を果たしている証拠になります。

漏洩発生時の初動

万一インシデントが起きたときに、慌てずに動けるよう初動を決めておきます。完璧な体制でなくても、最低限の流れを共有しておくだけで被害を抑えられます。

• 報告ルートを決めておく：「フリーランスが異常に気づいたら、まず誰に連絡するか」を契約段階で決めておきます。前述の契約条項の「漏洩時の報告義務」と対応させます。
• 証跡を確保する：何が起きたかを後から確認できるよう、操作ログ・アクセス記録などの証跡を残しておきます。日頃から操作ログを有効にしておくことが、ここで効いてきます。
• 被害の拡大を止める：影響範囲を特定し、必要に応じてアカウントの停止・認証情報の再発行を行います。退場時のチェックリストと同じ要領で、アクセスを遮断します。
• 報告・連絡の義務を確認する：個人情報の漏えいが疑われる場合、個人情報保護委員会への報告や本人への通知が必要になるケースがあります。状況に応じて、専門家や関係窓口に相談します。

初動の流れをあらかじめ紙1枚にまとめておくだけでも、いざというときの対応速度が大きく変わります。

自社の状況に合わせたセキュリティポリシーの文書化

ここまでの判断基準・運用・契約条項は、担当者の頭の中にあるだけでは属人化してしまいます。次回以降の発注でも同じ品質を保ち、上長や他のメンバーにも説明できるよう、「外部委託向けセキュリティポリシー」として1枚に文書化しておきましょう。専任のセキュリティ担当がいなくても、最小構成なら十分に作れます。

最小構成のポリシー項目

まず、社内に外部委託向けのルールが何もない場合に、最低限そろえておきたい項目です。これだけでも文書化しておけば、発注のたびに迷わずに済みます。

• 適用範囲：このポリシーが誰に適用されるか（外部のフリーランス・業務委託先など）を明記します。
• 権限方針：最小権限の原則と、3レイヤー（リポジトリ・インフラ／本番・顧客データ）ごとの「許可してよい範囲／避ける範囲」を記載します。
• 入退場手順：アカウントの発行チェックリストと失効チェックリスト、棚卸し表の運用ルールをまとめます。
• 連絡体制：問い合わせ窓口と、インシデント発生時の報告ルートを記載します。

この4項目があれば、「誰に・何を・どこまで許可し・どう回収し・何かあったらどう動くか」が一通りカバーできます。最初から完璧を目指さず、まずこの骨格を作ることをおすすめします。

既存社内規定の外部委託向け適用・運用が回る粒度の保ち方

すでに正社員向けのITセキュリティ規定がある場合は、ゼロから作る必要はありません。既存規定から外部委託に関係する部分を抜き出し、外部人材ならではの論点（社外作業・複数案件並行・契約期限による失効）を追記する形で「外部委託向けの抜粋・補足」を用意します。

文書化で最も気をつけたいのは、過剰にしすぎないことです。ルールが細かすぎると、運用が追いつかず形骸化したり、優秀なフリーランスから「手続きが重い発注元」として敬遠されたりします。次の観点でバランスを取りましょう。

• 守れないルールは書かない（書いたのに運用しないと、かえって管理責任の観点で不利になります）
• チェックリストは「実際に毎回チェックする」前提の項目数に絞る
• 自社の事業規模・扱う情報の機微さに見合った水準にする（顧客の個人情報を大量に扱うなら厳しめ、社内ツールだけなら軽めに）

ポリシーは作って終わりではなく、運用が回ってこそ意味があります。「自社で無理なく続けられる粒度」を最優先に設計してください。

まとめ：発注前チェックリストと次のステップ

最後に、フリーランスエンジニアへの発注前に「これだけは決めておく」ポイントを、判断基準（権限）・運用（入退場）・契約（条項）・責任（漏洩時）の4本柱でまとめます。発注の意思決定の場で、このリストをそのまま確認材料として使ってください。

• 権限（判断基準）
  • 最小権限の原則に沿って、依頼業務に必要な範囲だけを付与する方針を決めたか
  • リポジトリ・インフラ／本番・顧客データの3レイヤーで「許可する範囲／避ける範囲」を整理したか
  • 本番データに触れさせない工夫（マスキング・ダミーデータ・閲覧範囲限定）を用意したか
• 運用（入退場）
  • 付与アカウントの棚卸し表と、入場・退場チェックリストを用意したか
  • 「付与した権限は必ず失効リストに入れる」原則を運用に組み込んだか
  • MFA 必須・共有アカウント禁止・操作ログの基本運用を決めたか
• 契約（条項）
  • 業務委託契約・NDA に情報管理条項（秘密情報の定義・目的外利用禁止・返却破棄・再委託制限・漏洩時報告）が入っているか
• 責任（漏洩時）
  • 契約形態（請負／準委任）と責任分界を理解したか
  • 発注者自身の委託先監督責任を踏まえ、適切な管理の実態を作れているか
  • 漏洩発生時の報告ルート・証跡確保の初動を決めたか

これらを整理できれば、上長から「セキュリティは大丈夫か」と問われても、自社の方針を根拠を持って説明できる状態になります。

次のステップとして確認したいのが、契約法務の詳細です。本記事では情報管理条項の「要点」を整理しましたが、実際の契約書では、秘密保持義務の具体的な文言、損害賠償条項の上限、フリーランス新法を踏まえた取引条件の明示など、踏み込んで確認すべき点が残ります。これらの契約・法務面のチェックポイントは、フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイドに発注者目線でまとめています。セキュリティポリシーの設計が一段落したら、こうした資料も参照しながら業務委託契約全体を契約・法務の観点で点検し、発注に進んでいきましょう。