独立系開発者としてすでに適用されているセキュリティ義務
独立系開発者の間には、セキュリティやプライバシーに関する規制は企業に降りかかるものであって、法人化したり、DPO(データ保護責任者)を雇ったり、エンタープライズ契約を結んだりして初めて義務が発生する、という根強い思い込みがあります。それは事実ではありませんし、何年も前から事実ではありませんでした。もしあなたがフリーランスやインディー開発者としてクライアントのデータを扱っているなら、いくつかの義務は今この瞬間、個人として、現在の規模のままあなたに適用されています。この記事では、それらの義務が何であるか、どの規制に由来するのかを順を追って説明し、最後に重要な実務的な問いにたどり着きます――今この瞬間、あなたのアカウントには具体的に何が露出しているのか、という問いです。
この記事が述べないことが一つあります。それは、いかなる法律もセキュリティツールの購入を義務付けている、という主張です。そのような法律はありません。法律が実際に求めているのは、自分が処理しているデータについて何をしているかを把握し、適切に保護することです。そして、その正直な出発点となるのが、クライアントの作業が置かれているアカウントにどのようなアクセス権が存在するのかを把握することです。
GDPRの下では、クライアントデータを処理するフリーランサーは「処理者」であり、直接的な義務を負います
EU域内のクライアント(あるいはユーザーがEU域内にいるクライアント)が、あなたに個人データを渡す場合――移行対象のユーザーデータベース、デバッグ対象の本番システム、分析対象のエクスポートなど――あなたはほぼ常にGDPRにおけるデータ処理者(data processor)として行動していることになります。また案件によっては(何を、なぜ収集するかをあなた自身が決定する場合)管理者(controller)として扱われることもあります。いずれの地位も、法人であることを要件としていません。GDPR第4条の定義は「自然人または法人」に適用されるものであり、ノートパソコン一台を持つ個人でも該当します。
この地位には、直接的かつ個人的な義務が伴います。
- 第28条は、クライアントのための処理が契約によって規律されることを求めています――エンタープライズクライアントが繰り返し送ってくるデータ処理契約(DPA)は官僚的な儀式ではなく、双方に課された法的要件であり、あなたを特定のセキュリティ上の約束事に拘束するものです。
- 第32条は、処理する個人データを保護するために「適切な技術的および組織的措置」を実施することを求めています――これはリスクに応じたものであり、誰が・何がそのデータにアクセスできるかを管理することも含まれます。
- 第33条は、処理者が個人データ侵害を認識した後、「不当な遅滞なく」管理者に通知することを求めています――これは、あなたがそもそも侵害に気づける立場にあることを前提としています。
- 第82条は、規制に違反する処理によって生じた損害について、データ主体に処理者への賠償請求権を与えており、第83条はこの枠組み全体を行政制裁金によって裏付けています。最も重大な違反の場合、その上限は2,000万ユーロまたは全世界年間売上高の4%のいずれか高い方に達することがあります。
監督当局がフリーランサーに対して最初に取る措置が法定上限額だ、と言いたいわけではありません。要点はもっとシンプルです。これらの義務は現実のものであり、あなた自身に直接付随するものであり、「自分はたった一人だから」という言い分は、規制の条文のどこにも認められた免除事由ではない、ということです。
EU AI法は、AIシステムの「デプロイヤー」に対する義務を追加します
もしあなたのクライアントワークに、製品にAIを組み込む作業――クライアントのアプリ内のアシスタント、ワークフローを自動化するAIエージェント、人に影響を与える意思決定を行うモデルなど――が含まれるようになったなら、EU AI法はあなたに関係します。同法はモデルを訓練する企業だけを規制するものではなく、デプロイヤー(deployers)――専門的な文脈において自らの権限の下でAIシステムを使用する者――にも義務を課しています。
第26条は、高リスクAIシステムに関するデプロイヤーの義務を定めており、システムをその使用説明書に従って使用すること、適切な人的監視を確保すること、稼働状況を監視することなどが含まれます。第4条は、提供者とデプロイヤーの双方に対し、自らに代わってこれらのシステムを操作する人々に十分なAIリテラシーを確保することを求めています。そして第99条は、この枠組みを違反に対する行政制裁金によって裏付けています。ある案件にどの義務が適用されるかは、システムが何を行い、どのリスク区分に該当するかによって異なります――ですが、「自分は組み込んだだけで、作ったわけではない」というのは、まさにデプロイヤーという区分が想定している役割そのものです。
ここには、私たちがAIエージェントガバナンスの分野で常に目にする、実務上の皮肉があります。独立系開発者は、AIコーディングエージェントや自動化ボットの最も積極的な採用者でありながら、それらのエージェントが何にアクセスできるかの棚卸しをしている可能性が最も低い層でもあるのです。もしAIエージェントがあなたの所有するすべてのリポジトリにプッシュできる状態にあるなら、それは規制当局が問い合わせをしてくるかどうかに関わらず、あなたのセキュリティ態勢に関する紛れもない事実です。
あなたのエンタープライズクライアントはすでに規制対象であり、その義務はあなたにも及びます
仮にあなたがEUの個人データに一切触れず、AIシステムを一切デプロイしないとしても、あらゆる規模の企業と仕事をするほぼすべてのフリーランサーに適用される、第三のセキュリティ義務の源があります。それは契約です。エンタープライズクライアントは、SOC 2レポート、ISO 27001認証、GDPR第28条の処理者要件、そして監査人が実際にチェックするベンダー管理プログラムの下で運営されています。これらのプログラムは、従業員500人のベンダーと1人のベンダーを区別しません。ベンダーはベンダーです。
これが、契約書よりも先にセキュリティ質問票が届き続ける理由です。あなたのクライアントは、自社のフレームワーク、監査人、あるいは自社の顧客によって、データを渡す相手からセキュリティ上の証拠を収集することを義務付けられています。そこにはあなたも含まれます。「自分の開発環境に何がアクセス権を持っているか、それをどう管理しているか、その証拠はこれだ」と説得力を持って答えられるフリーランサーは、その場しのぎで対応する人々よりも早く案件を成立させています。私たちはこの力学の組織側のバージョンについて、2026年に監査人がAIガバナンスに求めるものという記事で書きました。ベンダー側のバージョンは、質問票としてあなたの机に届くのです。
インシデントが独立系開発者に実際にもたらすコスト
ここではリスクという観点で捉えるのが正直な捉え方です。クライアントプロジェクトにおけるセキュリティインシデントは、契約上の補償条項に基づく直接的な金銭的責任を意味する可能性がありますし、個人データが関わっていた場合はGDPR第82条に基づく処理者としての責任を意味する可能性もあります。そして、フリーランサーにとって最も具体的なのは、クライアントとの関係と、それに伴う推薦(リファレンス)の終わりを意味する可能性があるということです。一人だけのコンサルタント事業にとって、評判という資産こそがビジネスそのものです。これは何も特殊な仮定の話ではなく、侵害されたクレデンシャルや過剰な権限を持つ連携が、クライアントデータのインシデントへと転じるときに生じる、ごく普通の因果の連鎖なのです。
では、今この瞬間、あなたのアカウントには実際に何が露出しているのか
ここで、この問いの居心地の悪い、具体的なバージョンをお示しします。あなたのクライアントワークは、ほぼ間違いなく個人のGitHubアカウント上に存在しています。そのアカウントには、何年にもわたるプロジェクトを通じて、次のようなものが蓄積されています。
- インストール済みのGitHub App――デプロイボット、CIツール、AIアシスタントなど、それぞれがあなたが一度承認し、おそらく二度と見直していない権限付与を保持しています。中には、あなたが所有するすべてのものに対する書き込みまたは管理者権限を持つものもあります。中には2024年に終了したプロジェクトに属するものもあります。
- デプロイキー――サーバー上に放置された無人のSSH認証情報で、中には読み取り専用のはずのリポジトリに対して書き込み権限を持つものもあります。そのサーバーが侵害された場合、読み書き可能なデプロイキーは、クライアントの製品へのコード注入経路となります。
- コラボレーター――すでに終了した協業の際に追加された人々で、いまだに書き込み権限を保持しており、その中には公開リポジトリも含まれます。
- リポジトリの露出――どのリポジトリが公開されており、その中に何が含まれているかということ自体が、ほとんどの開発者が記憶だけでは答えられない棚卸し課題です。
これらはいずれもGitHub自身のAPIを通じて機械可読であり、つまり記憶に頼るのではなく、今現在実際に何がアクセス権を持っているかを列挙することによって、すべて検証可能だということです。その棚卸しこそ、8200.devのGitHubコネクタが現在、組織アカウントだけでなく個人アカウント向けにも提供しているものです。自分のGitHubログインを接続すると、スキャンによってインストール済みAppとその権限付与、デプロイキーとそれぞれが読み取り専用かどうか、リポジトリごとのコラボレーター、そしてそのグラフから浮かび上がる検出結果――忘れられた管理者権限を持つボット、書き込み可能なデプロイキー、1年間誰も触れていない古びたApp――が一覧表示されます。
無料の個人ティアでは完全なスキャンを実行し、最も深刻な検出結果を表示します。有料の個人ティア――コード補完サブスクリプションのような価格設定で、エンタープライズソフトウェアのような価格ではありません――では、継続的な監視とアラートを備えた完全なリストが解放されます。そして、あなたが成長して組織アカウントを持つエージェンシーになった場合でも、同じスキャン、同じルール、同じ証拠の記録があなたの成長とともにスケールします――それがプロダクトの組織側であり、同じコネクタです。
上記の義務は、あなたがスキャンを実行するかどうかに関わらず適用されます。スキャンが変えるのは、それらの義務が暗に問いかけている問いに――何がアクセス権を持っているのか、なぜそうなっているのか、そして正当化できないアクセスに対して何をしたのか――答えられるかどうかです。まずは無料ティアから始めて、あなたのアカウントに静かに蓄積してきたものを確認し、そこから判断してください――料金は公開されており、セルフサービスで、ゼロから始められます。
*この記事は、独立系開発者に一般的に適用される規制についての一般的な情報であり、法的助言ではありません。各規制がお客様の具体的な状況にどのように適用されるかは、スキャナーには知り得ない事実関係によって決まります。その点については弁護士にご相談ください。*
関連記事
- 存在しないAIオプトアウト:17のSaaSプラットフォームを調査してわかったこと
8200.devのコネクタライブラリにある17のプラットフォームすべてを調査し、初期設定でコンテンツをAI学習に利用しているのは誰か、各社のオプトアウトが実際にどこにあるのかを確認しました。
- Lovableで作った、それでデータが漏洩したら誰の責任なのか?
LovableやBase44でのアプリ開発は速い一方、それを導入した企業がデータ管理者となります。AI製アプリのセキュリティと責任について解説します。
- AIガバナンスコンプライアンス:2026年に監査人が求めるもの
AIガバナンスは今や監査の標準項目です。2026年に監査人が期待する内容と、事前に証拠を準備する方法を解説します。