BLOG

AIを使う開発会社に、コードを預けても大丈夫か ― 当社のルールと確かめ方

開発を外注するとき、相手がAIを使うなら「自社のコードや資料を預けても大丈夫か」は確かめておきたい問いです。答えは、その会社がAIをどんなルールで使い、守られていることをどう確かめているかで決まります。

当社は開発の多くを、Claude CodeなどのAIツールで進めています。お客様に、より早く届けられるからです。一方で、設定の誤りや、AIに貼り付けたAPIキー1つから情報が漏れることは現実に起こります。2026年も、委託先やクラウド事業者が入口になった情報漏えいが続きました。事案と共通する弱点は、セキュリティ・バイ・デザインの記事で整理しています。

この記事では、発注する方が気にする5つの点に、当社のISMS(ISO 27001に基づく情報セキュリティの仕組み)の「AIツール利用規程」と、その確かめ方で答えます。最後に、どの開発会社にも使える確認の質問をまとめました。

御社のコードは了承した範囲だけAIツールに入り、学習に使わない・秘密は入れない、変更は人がレビューしてから本番へ。毎年確認しISMSの記録に残す

この記事を書いた人

wesionaryTEAM 編集チーム

株式会社wesionaryTEAMのプロジェクトマネージャーとエンジニアで構成する編集チームです。業務システム開発、AI導入支援、DX推進の案件で日々得ている知見をもとに、検討中の方が判断に使える情報を、事例と数字を添えてお届けします。

1. コードはAIの学習に使われないか

AIサービスは、同じ製品でも契約や設定によって、入力した内容を学習に使うかどうかが変わります。当社は、入力が学習に使われない契約か設定のAIツールだけを使います。各社の規約の違いは、ChatGPT・Claudeを仕事で使う前に確認したい利用規約の注意点で詳しく説明しています。

新しいAIサービスを使い始めるときは、学習への利用、データの保持期間、保存場所、取得している認証を事前に確認して承認します。規約が変わったときは、確認し直します。

確かめ方も決めています。業務でAIを使う全員が、使っているツールが学習に使われない状態であることを会社のフォームで報告します。設定で切り替えるツールについては、設定画面のスクリーンショットを添えます。報告はISMSの記録として保管し、毎年更新します。その状態になっていないアカウントには、業務の情報を入れません。発注する側からは、開発会社のメンバー一人ひとりのAIの設定までは見えません。だからこそ、会社として確かめる仕組みがあるかどうかが分かれ目になります。

2. どこまでAIに入れるのか

御社のソースコードや設計書をAIツールに入れるのは、当社が承認したツールで、御社に了承をいただいた範囲だけです。キックオフで使うツールと入れる情報の範囲をご説明し、了承いただいた内容を議事録の決定事項として残します。記録に残すのは、担当者が替わっても、約束した範囲がそのまま引き継がれるようにするためです。

たとえば「リポジトリのコードと設計書は入れる。本番データと顧客情報は入れない」のように、範囲を具体的に決めます。契約や御社の社内規程でAIの利用が制限されていれば、それに従います。AIを使わない進め方にも対応します。範囲はプロジェクトの途中でも見直せますが、その場合も改めて了承をいただき、記録します。判断に迷う場面では、メンバーは自分で決めず、プロジェクトマネージャーに確認します。

3. パスワードや個人情報が漏れないか

学習に使われないツールでも、入れない情報があります。人はうっかり貼り付けることがあるので、ルールだけに頼らず、AIが読めない設定でも防ぎます。

  • 認証情報。パスワード、APIキー、鍵ファイルは入力禁止です。リポジトリの共有設定で、AIツールが.envファイルや鍵ファイルを読めないようにし、個人の設定で緩めることも認めていません。
  • 個人情報と業務データ。御社の顧客やユーザーの個人情報、本番の業務データは原則として入れません。調査にどうしても必要なときは、個人を特定できない形に置き換えてから使います。
  • 本番環境の鍵。本番の鍵やサービスアカウントは、AIエージェントが届く場所に置きません。
  • 資料の置き場所。業務の資料は、当社のプロジェクト管理システムと会社のGoogleドライブにだけ保存します。誰でも開ける公開リンクでの共有は禁止で、御社への共有は閲覧者を指定して行います。

退職するメンバーは、AIツールに残る業務の会話履歴と資料をすべて削除します。

4. AIが書いたコードは、誰が確かめるのか

コードに責任を持つのは、ツールではなく当社のチームです。AIが書いた変更も、人が書いた変更と同じくプルリクエストにし、当社の開発者がレビューしてからマージします。本番のブランチに直接反映することは禁止しています。AIは、指示に書かれていない認証や入力のチェックを省いたコードを書くことがあり、人の目で確かめる工程は欠かせません。

規程では、秘密情報の混入の検査と、使っているライブラリの脆弱性の監査を、CI(自動テストと検査の仕組み)の必須チェックと定めています。次の操作は、AIに自動で実行させず、人が確認してから実行します。

  • 本番データの削除や移行
  • 課金に関わる操作
  • 外部へのデータ送信と、権限の変更

AIに外部のリポジトリやWebページを読ませるときは、文書に紛れ込んだ指示でAIを操る「プロンプトインジェクション」が起こりうる前提で、出力と操作を確かめます。AIが提案したライブラリも、実在するか、作者と公開日はどうかを確認してから採用します。AIに任せる範囲の決め方は、AIに業務を任せるとはどういうことかでも紹介しています。

5. ルールが守られていると、どう分かるのか

ルールを書くことより、全員が守り続けることのほうが難しいものです。当社はAIの利用を、他のISMSの管理策と同じように運用し、東京とネパールの全員に同じルールを適用しています。

  • 確認フォーム。全員が会社のアカウントでフォームに回答し、各ルールを守っていることを確認します。未回答の人にはフォローします。
  • 教育。入社時と年1回、秘密情報の扱い、プロンプトインジェクション、レビューの方法を教育し、受講の記録を残します。
  • 証跡。プルリクエストのレビュー履歴、CIの記録、タスクの記録で、AIが書いたコードを人がレビューしたことを後から示せます。
  • 報告。AIツールが鍵や個人情報を送ってしまった、不審な操作をしたなどに気づいた人は、すぐに情報セキュリティ管理責任者に報告します。インシデントとして記録して再発を防ぎ、表に出た鍵はすぐに作り直します。

規程そのものも、年1回と、使っているAIサービスの規約が変わったときに見直します。見直しでは、経済産業省と総務省の「AI事業者ガイドライン」(第1.2版)も参照しています。

発注前に、どの開発会社にも聞いておきたいこと

経済産業省は2025年2月に「AIの利用・開発に関する契約チェックリスト」をまとめ、AIサービスに渡すデータの利用範囲を、契約の時点で確かめることを勧めています。開発会社に依頼するときも同じで、次の5つを聞いておくと安心です。

  • コードがAIの学習に使われない契約や設定か。それをどう確かめているか。
  • 自社のコードや資料を、どこまでAIに入れるか。範囲を事前に説明し、合意を記録に残すか。
  • パスワードや個人情報がAIに渡らない仕組みがあるか。ルールだけでなく、設定で防いでいるか。
  • AIが書いたコードを誰がレビューし、本番への反映に人の承認が入るか。
  • ルールが守られていることを、記録や監査で示せるか。

答えが具体的で、記録を見せられる会社なら、AIを使っていても任せやすいはずです。口頭の説明だけでなく、提案書や契約書の文面で確かめておくと、さらに確実です。

御社のプロジェクトでは

上の5つのご質問には、見積相談の段階からお答えします。御社に独自のセキュリティ規程やAI利用のルールがあれば、キックオフでお知らせください。その内容に合わせて、使うツールと入れる情報の範囲を決めます。

AIを業務にどう組み込むかは、AI導入支援のページで進め方を紹介しています。当社の情報セキュリティの考え方は、情報セキュリティ基本方針にまとめています。

よくあるご質問

AIを使うと、自社のコードがAIの学習に使われませんか?

使われません。入力が学習に使われない契約か設定のAIツールだけを使い、その状態を全員が毎年報告し、記録に残しています。

自社のプロジェクトではAIを使ってほしくない場合は?

キックオフでお伝えください。AIを使わない進め方や、使う範囲を限る進め方に対応します。

AIが書いたコードの品質には、誰が責任を持ちますか?

当社です。AIが書いた変更も、当社の開発者がレビューし、自動の検査を通してからマージします。

自社のセキュリティ規程に合わせてもらえますか?

はい。契約や御社の規程でAIの利用範囲が決まっていれば、それに従います。

まとめ

AIを使う開発会社にコードを預けて大丈夫かは、ルールがあるかどうかより、守られていることを示せるかで判断できます。当社は、学習に使わせない、了承した範囲だけ入れる、秘密は入れない、変更は人がレビューする、の4つをISMSの記録として毎年確かめています。

発注をご検討中の方は、無料見積相談で、AIの使い方を含めた進め方と費用の目安を担当PMにご相談ください。セキュリティについてのご質問だけでも、お問い合わせから承ります。

関連する記事とページ

出典

この記事の監修者

永田 一郎代表取締役

ヤフー(Yahoo! JAPAN)のエンジニア出身。スタートアップ、大手事業会社にて18年以上にわたり、toC/toB向けの新規事業開発、業務DX化など、多種多様なプロジェクトに従事。エンジニアとして自ら開発に携わる一方、体制構築やマネジメント、事業設計、仮説検証にも関わり、事業の立ち上げとグロースを幅広く体得。これまでに三回の事業売却を経験。共創でより効果的にプロダクトをつくり、アイディアをマーケットで検証できることを確信し、共創プラットフォームを提供するため wesionaryTEAM を創業。