システム開発を外注するときのAI利用ルール｜開発会社に求める5つの約束と秘密情報の扱いARTICLE

「外注先の開発会社が、うちのソースコードを AI に読ませているらしい。大丈夫なのか」——システム開発を外部に任せている会社から、こうした相談が増えています。

実際、今の開発現場では、Claude Code、Cursor、GitHub Copilot、ChatGPT（Codex）などの AI ツールを使うのが当たり前になりつつあります。特に最近のツールは、エンジニアが貼り付けた文章に答えるだけでなく、自分でリポジトリの中のファイルを読み、コードを書き換え、コマンドを実行するところまで進んでいます。発注する側から見ると、「自社のコードや設定ファイルが、どこまで AI に渡っているのか」が見えにくくなっています。

前編では、全社員が業務で生成AIを使うときの社内ルールを扱いました。本記事（後編）では、システム開発を外注するときに、開発会社にどんな AI 利用ルールを約束してもらえばよいかを、発注する側の視点で整理します。

この記事の要点

• 開発会社の AI ツール利用は、禁止するのではなく条件を決めて約束してもらうのが現実的です。禁止すると生産性が落ちるか、ルールが守られなくなります
• 約束してもらうのは5つです。外部連携アプリの事前合意、AIツール利用の事前合意、秘密情報をプロンプトやログに載せない、AIの成果物は人がレビューしてからマージ、学習に使われない設定
• 秘密情報は「ファイルの種類」ではなく「書かれている値」で3つに分け、設定ファイルで読ませない仕組みと人の行動ルールを組み合わせます。設定には限界があることも前提にします
• 当社の現場では、そもそも社外のクラウドに出せない情報を扱う会社もありました。発注の最初に「どの情報を、どこで動く AI になら渡せるか」を決めておくと、見積もりと進め方がぶれません

開発で使われるAIツールは「チャット型」と「エージェント型」に分かれる

開発で使われる AI ツールは、発注する側から見たリスクの違いで、大きく2つに分けられます。

注意したいのは、エージェント型です。たとえば「ログインできない原因を調べて」と頼むと、AI は関係しそうなファイルを次々に開いていきます。その中に、本番環境のパスワードや API キーを書いた設定ファイルが含まれていれば、その値も AI に渡ります。エンジニア本人に悪意がなくても起こりうる点が、チャット型との大きな違いです。

なお、チャット型でもデスクトップアプリでローカルのファイルやアプリと連携する機能（MCP など）を有効にしている場合は、エージェント型と同じ扱いにします。

開発会社に約束してもらう5つの必須事項

ルールの中心は、次の5つです。いずれも開発会社の生産性を大きく下げずに守れるもので、契約時の合意事項として明文化しておくことをおすすめします。

K.S.Rogers の現場から

当社が開発をお受けする場面では、5の「学習に使われない設定」だけでは足りない会社もありました。製造業の技術資料や、医療機関の患者情報のように、社内の決まりでそもそも社外のクラウドに出せない情報を扱う場合です。こうした会社では、AI を社内の環境やオンプレミスで動かすことが前提になり、その費用が進め方を大きく左右しました。どの情報を AI に渡してよいか、どこで動く AI になら渡せるかを発注の最初に合意しておくと、見積もりも進め方もぶれません。

1と2の違い ― 「アプリ」と「ツール」は分けて考える

1の外部連携アプリは、リポジトリそのものに権限を持って組み込まれるため、影響が大きく、発注側の承認を必須にします。一方、2の AI ツールは、エンジニアの手元で使うものです。毎回発注側が承認すると開発が止まるため、承認済みのツールの一覧を先に合意しておき、その範囲なら開発会社の中の確認で使ってよい、とするのが現実的です。

承認済みのツールは、Anthropic（Claude・Claude Code）、OpenAI（ChatGPT・Codex）、Microsoft と GitHub（GitHub Copilot・Microsoft 365 Copilot）、Anysphere（Cursor）、Google（Gemini）のように、提供元の会社単位でリストにしておくと、新しい製品が出るたびに見直す手間が減ります。そのうえで、次のような条件を付けます。

• どのツールも、5の「学習に使われない設定」をしていることが前提
• GitHub Copilot は、法人向けのプランに限る（リポジトリ側から読み取りを制限する機能が、法人向けのプランにしかないため）
• リストにないツールは、個別に申請して承認を受けるまで使わない

4は「新しい手順」を作らない

AI が書いたコードのレビューは、既存のプルリクエスト（PR）のレビューに組み込みます。PR の説明に「AI利用あり」と書く、レビュー担当者が AI が書いた部分を見分けられないときは作成者に確認する、レビューなしのマージはしない、の3点で十分です。AI 専用の承認手順を新しく作ると、手間が増えて守られなくなります。

秘密情報は「書かれている値」で3つに分ける

3の「秘密情報をプロンプトやログに載せない」を守るには、何が秘密情報なのかを決めておく必要があります。ポイントは、ファイルの種類ではなく、そこに書かれている値で判断することです。同じ設定ファイルでも、ダミーの値なら秘密情報ではなく、本番の値なら秘密情報です。

区分Ⅰを「一部を伏せても不可」としているのは、伏せ方が人によってばらつき、伏せ忘れが起きやすいためです。認証情報は、そもそも AI に見せない前提で扱います。

区分Ⅱの業務データは、不具合の調査などでどうしても AI に見せたい場面があります。その場合は、次の基準をすべて満たしたものに限ります。

• 氏名・住所・電話番号・メールアドレス・会員IDなど、個人を直接特定できる情報を削除するか、ダミーの値に置き換えている
• 件数を必要最小限に絞っている（調査なら数件〜数十件）
• 金額や日時を、個人の特定につながらない粒度（日単位、千円単位など）に丸めている

迷ったときは入力せず、開発会社の品質責任者に確認する、というルールもセットにします。

仕組みで守る ― 設定ファイルで「読ませない」

人の注意だけに頼らないために、エージェント型のツールにはリポジトリ側で読み取りを禁止する設定を置きます。たとえば Claude Code では、リポジトリに置いた設定ファイル（.claude/settings.json）に読み取り禁止のルールを書いてコミットすると、そのリポジトリを扱う全員に同じ制限がかかります。Cursor、Gemini、Codex、GitHub Copilot（法人向けプラン）にも、それぞれ同じような仕組みがあります。

この方法のよいところは、メンバー個人の設定に依存しないことです。新しく参加したエンジニアも、リポジトリを取得した時点で同じ制限の下で作業することになります。設定の追加や変更も、通常の PR レビューを通すことで記録が残ります。

ただし、設定には限界があります。K.S.Rogers で Claude Code の読み取り禁止の設定を検証したところ、ファイルを直接開く操作や cat などのコマンドでの読み取りは止まる一方、ファイル名を指定しない検索（grep で全体を検索するなど）や、AI が書いたスクリプト経由の読み取りは止まりませんでした。

そのため、設定と合わせて、次のような人の行動ルールも決めておきます。

• 認証情報を、AI ツールのプロンプトやチャットに貼り付けない
• 業務データを、匿名化の基準を満たさずに入力しない
• 本番環境の設定ファイルの中身を、AI に読み上げさせたり要約させたりしない
• AI とのやりとりを、外部のサービスで共有・公開しない
• 誤って入力したときは、すぐに報告する

検証の詳しい結果（6つの読み取り経路で何が止まり、何が通ったか）と、各ツールの設定方法は、Claude Codeの秘密情報対策｜読み取り禁止（deny）設定で防げること・防げないことで解説しています。

運用を重くしない3つの原則

AI 利用のルールは、細かくするほど守られなくなります。AI ツールの仕様は数か月単位で変わるため、細則を増やすと改定も追いつきません。運用は次の3つに絞ります。

1. 申請で把握する ―― どのメンバーがどのツールを使っているかを、課題管理ツールの申請で記録する。承認の記録は申請の課題そのものとし、別の台帳は作らない
2. 設定ファイルで統制する ―― 秘密情報を読ませない設定をリポジトリ側に置き、個人の設定に依存しない
3. 既存のプロセスに乗せる ―― AI の成果物のレビューは既存の PR レビューに組み込み、新しい承認手順を作らない

申請の項目も、A4 で半分ほどに収まる量にします。

棚卸し・メンバーの入れ替わり・事故のとき

ルールを作って終わりにしないために、次の3つの場面の対応も決めておきます。

• 半年に1回の棚卸し ―― リポジトリに入っている外部連携アプリ、読み取り禁止の対象ファイル、承認済みツールの一覧、ツールのバージョンを確認する。発注側が求めたときは、結果を共有してもらう
• メンバーの参画・離脱 ―― 参画時にルールを案内し、学習に使われない設定を確認する。離脱時には、リポジトリの権限と連携アプリの権限を外す
• 事故のとき ―― 秘密情報を AI に入力した疑いがあるときは、発見した人がすぐに報告し、影響範囲を確認したうえで、必要なら認証情報を無効にして再発行する。発注側への報告の流れも決めておく

事故の対応で特に大切なのは、自分から報告した人を不利に扱わないと明記しておくことです。誤って入力したことを報告すると責められるルールでは、事故は隠れます。前編のサンプル条文でも、同じ考え方を入れています。

発注側の確認チェックリスト

開発会社と契約するとき、または今の契約を見直すときに、次の項目を確認します。

• 開発会社が使っている AI ツールの一覧（提供元の単位）を共有してもらった
• どのツールも、入力内容が学習に使われない設定で使っていることを確認した
• 自社のリポジトリに外部連携アプリを入れるときは、自社の承認が必要だと合意した
• 認証情報を AI に入力しないこと、業務データは匿名化の基準を満たした場合に限ることを合意した
• エージェント型のツールについて、リポジトリ側で読み取りを禁止する設定を置いてもらった
• AI が作った成果物は、人がレビューしてからマージすることを確認した
• 半年に1回の棚卸しの結果を、求めれば共有してもらえることを確認した
• 事故が起きたときの報告の流れと、連絡先を決めた

発注する側に技術の詳しい知識がなくても、この一覧を渡して「どう対応しているか」を聞くだけで、開発会社の管理の水準はかなり見えてきます。

K.S.Rogers の現場から

AI を使った開発を外部に任せるとき、当社の支援先で成果が続いているのは、丸投げにせず、計画・要件定義・開発を一緒に進めてノウハウを社内に残す会社です。作ったあとの運用が本番で、特定の外注先に頼り切りになると、担当者が変わったときに続きません。お客様自身が AI ツールで試作を作れる場合には、当社はゼロから作り直さず、その試作の精度を上げる役割に回ったこともあります。AI の利用ルールも同じで、発注側が中身を分かったうえで合意しておくことが、長く続けるための前提になります。

K.S.Rogers の考え方と支援

K.S.Rogers は、スタートアップスタジオ事業でお客様のプロダクト開発を担う立場でもあります。自社の開発でも、本記事と同じ考え方で AI ツールの利用ルールを定め、承認済みツールの管理、リポジトリ側の読み取り禁止の設定、PR レビューへの組み込みを運用しています。

AI ツールは、正しく使えば開発の速さと品質を大きく引き上げます。止めるのではなく、安全に使える条件を先に決めて、発注する側と開発する側が同じルールの上で進める——それが、AI 時代の開発の外注に必要な前提だと考えています。

「外注先の AI 利用について、何を確認すればよいか分からない」「開発を任せたいが、AI の扱いを含めて相談したい」という段階から、要件定義支援やスタートアップスタジオ事業でご相談いただけます。ご相談はお問い合わせからどうぞ。

まとめ

• 開発会社の AI ツール利用は、禁止ではなく条件を決めて約束してもらうのが現実的です
• 約束してもらうのは、外部連携アプリの事前合意、AIツール利用の事前合意、秘密情報をプロンプトやログに載せない、AIの成果物は人がレビューしてからマージ、学習に使われない設定、の5つです
• 秘密情報は書かれている値で、認証情報・業務データ・コードと設計の3つに分けます。認証情報は一部を伏せても入力しません
• エージェント型のツールにはリポジトリ側の読み取り禁止の設定を置き、設定の限界を人の行動ルールで補います
• 運用は、申請で把握する、設定ファイルで統制する、既存のプロセスに乗せる、の3つに絞ります