導入
「今のプロジェクトの要件定義書を読み込ませて、最適なAWSのアーキテクチャ図を描かせてみたい」
開発現場からそんな声が上がってきたとき、マネージャーであるあなたは即座に許可を出せますか？ それとも、漠然とした不安を感じて「ちょっと待ってくれ」とブレーキを踏みますか？
もしあなたが後者なら、その直感は正しいと言えます。近年、多くの企業がAI技術の利用を検討していますが、特にシステム構成図の自動生成に関しては、慎重な検討が必要です。
近年、Mermaid記法やPlantUMLを出力させることで、テキストからシステム構成図を自動生成する手法が注目されています。確かに便利です。これまで数時間かかっていた作図作業が、ほんの数分で終わるかもしれません。しかし、その「便利さ」の裏側には、テキスト生成AI特有のデータ流出リスクと、画像生成AIにも通じる複雑な権利問題が絡み合っています。
多くの企業が「AI活用」を掲げる一方で、現場レベルでの具体的なガードレール（安全策）は整備されていません。禁止すれば現場の反発を招き、野放しにすれば企業の存続に関わる事故につながる。このジレンマに頭を抱える方は多いはずです。
この記事では、AIによるシステムアーキテクチャ設計支援ツールを導入する際に、必ず押さえておくべき「法務・セキュリティ上のリスク」を解きほぐします。そして、単にリスクを並べるだけでなく、どうすればそれらを回避し、安全にテクノロジーの恩恵を受けられるのか、実務に即した具体的なガイドライン策定のヒントを解説します。
「なんとなく怖い」を「正しく恐れて、賢く使う」へ。企業の信頼を守りながら開発効率を上げるための、最初の一歩を踏み出しましょう。
なぜ「AIによる設計図生成」が法務・セキュリティの懸念事項になるのか
まず、根本的な問題の所在をはっきりさせましょう。なぜ文章の要約や翻訳なら許容される場面でも、「システム設計図の生成」となると、一段高い警戒レベルが必要になるのでしょうか。
それは、システムアーキテクチャ図が、企業の「技術的な急所」を可視化したものだからです。攻撃者にとって、これほど有益な情報はありません。
テキストから図面を起こすプロセスに潜む罠
AIで図面を作る現在の主流な方法は、最新のLLM（大規模言語モデル）に自然言語で要件を伝え、そこから作図用コードを出力させ、それをレンダリングツールで図にするというプロセスです。
ここで重要なのは、「自然言語で要件を伝える」という最初のステップです。AIモデルの推論能力が飛躍的に向上した現在、詳細な指示を与えれば与えるほど、驚くほど精緻な設計図が出力されます。その結果、エンジニアはより具体的で詳細な情報を入力したくなる誘惑に駆られます。
「Webサーバーは特定のインスタンスタイプを2台構成で、データベースのバージョンは指定のもの。VPCのIPアドレス帯は10.0.0.0/16で、社内ネットワークからはVPNで接続する」
このように、プロンプト（指示文）の中に、具体的なバージョン情報、IPアドレス、社内システムとの接続方式などが無意識に含まれてしまうのです。これらは単なる「文章」ではなく、セキュリティインシデントに直結する「機密パラメータ」の塊です。AIが賢くなればなるほど、ユーザーはより多くのコンテキスト（文脈情報）を提供しようとし、結果として情報漏洩のリスクが高まるというパラドックスが生じています。
「便利さ」の裏にあるブラックボックス問題
一般的に利用されているAIサービスの裏側で、データがどう扱われているか完全に把握できている人は少ないでしょう。
多くの無料版や個人向けプランの生成AIサービスでは、ユーザーが入力したデータは、次のモデルを賢くするための「学習データ」として利用される規約になっています。つまり、入力した自社のシステム構成情報が、AIという巨大な知識の海に取り込まれ、巡り巡って他社の誰かが「一般的なシステム構成の例を教えて」と聞いたときに、自社の構成が「回答の一部」として出力される可能性も否定できません。
これは「ブラックボックス」の問題です。一度AIモデルの中に学習されてしまった情報は、特定のデータだけを後から「削除」することが技術的に極めて困難です。「機械学習による忘却（Machine Unlearning）」の研究も進んでいますが、実用段階には至っていません。一度飲み込まれた情報は、取り返しがつかないと考えておくべきです。
現場の暴走と企業の社会的責任
エンジニアは悪気があって情報を漏らすわけではありません。むしろ「良いものを作りたい」「効率的に仕事を進めたい」というポジティブな動機で動いています。だからこそ厄介なのです。
特に近年の開発ツールは進化が著しく、AIコーディングアシスタントは、単なるコード補完だけでなく、自律的なエージェント機能やワークスペース全体を理解する機能を備えるようになりました。これにより、課題の内容から修正案を自動生成したり、複雑なコード整理を対話形式で実行したりすることが可能です。
しかし、こうした「高度な利便性」は諸刃の剣です。ツールが強力になればなるほど、開発者は無意識にリポジトリ全体の読み取り権限を与えたり、機密性の高いドキュメントをコンテキストとして読み込ませたりしてしまいます。組織全体として見たとき、個人のPC画面の中でAIエージェントがどのようなデータを処理しているのかが管理不能になる、高度な「シャドーAI」化が進行しています。
もし、顧客から預かった機密情報や、自社の未発表サービスの構成案が、AI経由で流出したとしたらどうなるでしょうか。企業としての社会的信用は地に落ち、損害賠償請求に発展する恐れもあります。技術的な利便性を追求する前に、企業として守るべき「コンプライアンスの防波堤」を築くことが、経営層やプロジェクトマネージャーの責務なのです。
リスク1：入力データと機密情報の取り扱い
では、具体的にどのようなデータが危険で、どう扱えばよいのでしょうか。ここでは「入力データ」に焦点を当てて、セキュリティリスクを深掘りします。
プロンプトに入力してはいけない情報とは
AIに対して「いい感じの図を作って」と頼むだけならリスクは低いですが、実務ではそうはいきません。しかし、以下の情報はプロンプト（入力指示）に決して含めてはいけません。
- 固定IPアドレスやドメイン名: 攻撃の標的を特定する情報になります。
- 認証情報: APIキー、パスワード、秘密鍵の一部などは、たとえテスト用であっても入力すべきではありません。
- 具体的な顧客名やプロジェクトコード: 「特定顧客向けの金融システム」といった記述は、その構成が該当企業の弱点であることを示唆してしまいます。
- 未公開の脆弱性対応: 「このセキュリティホールを塞ぐ構成にして」といった指示は、現状の脆弱性を暴露しているのと同じです。
- 個人情報: 担当者の氏名やメールアドレスなどが図面のメタデータに含まれる可能性があります。
これらは「当たり前」に見えるかもしれませんが、対話型のAIを使っていると、ついチャット感覚で「あ、ついでにここのIPは〇〇にしておいて」と追記してしまうケースが後を絶ちません。人間相手のチャットツールと同じ感覚で接するのは危険です。
「学習データとして利用される」設定の落とし穴
利用するAIツールの契約形態と設定を正しく理解していますか？ ここが運命の分かれ道です。
例えば、一般的な生成AIの無料版や個人有料版では、デフォルトで入力データがモデルの改善（学習）に使用される設定になっていることがあります（設定でオプトアウト可能ですが、個人のリテラシーに依存します）。
一方で、法人向けプランやAPI経由での利用では、デフォルトで学習データとして利用されない規約になっています。ここを混同して、「有料版だから大丈夫だろう」と個人向けプランのアカウントを業務で使い回しているケースが散見されますが、これは非常にリスクが高い状態です。
また、サードパーティ製の「AI作図ツール」を利用する場合も注意が必要です。そのツール自体が裏側でどのAIモデルを呼び出しているのか、そしてそのツールベンダーがデータをどう扱っているのか（ログとして保存しているのか、学習に回しているのか）を利用規約やプライバシーポリシーで確認する必要があります。「AI機能搭載」と謳う便利なツールの裏側で、データがどう流れているかを追跡するのは容易ではありません。
API利用とWebブラウザ利用のセキュリティ差異
セキュリティ強度を保つためには、Webブラウザからチャット形式で利用するよりも、API経由で自社専用のインターフェースを構築する方が安全な場合が多いです。
API利用では、企業向けのSLA（サービス品質保証）が適用され、入力データが学習に使われないことが契約で明記されているケースが一般的です。また、データの保存期間やログの監視権限も企業側でコントロールしやすくなります。
もし社内で「AIで図面を描きたい」という要望が出たら、個々人にWebサービスのアカウントを作らせるのではなく、会社として契約したAPIを利用できる「社内ポータル」や「認可されたツール」経由でのみ利用を許可する。これが、技術的にデータを守るための定石です。
リスク2：生成されたアーキテクチャ図の著作権と商用利用
次に、AIが生成した「成果物（図面）」にまつわる権利の問題です。ここは法的な解釈がまだ流動的な部分ですが、ビジネスを行う上での「安全側の判断基準」を解説します。
AI生成物は「著作物」として認められるか
現在の日本の著作権法や文化庁の見解では、AIが自律的に生成したものは「思想又は感情を創作的に表現したもの」とは言えず、著作物として認められない可能性が高いとされています。
つまり、AIに「クラウドの構成図を描いて」と指示して出てきた図面そのものには、著作権が発生しない可能性があります。これはどういうことかというと、その図面を誰かに勝手にコピーされても、「著作権侵害だ」と訴えることが難しいかもしれないということです。
ただし、人間が詳細に指示を出し、生成されたものに対して人間が加筆・修正を行い、そこに「創作的な寄与」があれば、その部分は著作物として保護される可能性があります。システム設計図の場合、AIが出した下書きをそのまま使うことは稀で、エンジニアが修正を加えることがほとんどでしょう。その意味では著作権が発生する余地はありますが、「AI丸投げ」で作った資料は権利保護が弱い、という認識は持っておくべきです。
他社の設計図に似てしまった場合の侵害リスク
逆に、AIが生成した図面が、偶然にも他社の著作権を侵害してしまうリスク（依拠性と類似性）はどうでしょうか。
画像生成AIが特定のアーティストの画風を模倣してしまう問題と同様に、システム構成図でも、学習データに含まれていた特定の企業の独創的なアーキテクチャ図や、書籍・教材に含まれる図版と酷似したものを生成してしまう可能性はゼロではありません。
一般的な「Web 3層構造」のようなありふれた構成であれば、誰が描いても似たような図になるため著作権侵害にはなりにくい（アイデアの範疇）ですが、特殊なアイコンの使い方や、独自性のあるレイアウトデザインまで酷似していた場合は注意が必要です。
特に、Web上の画像を検索して参照する機能を持ったAIの場合、既存の図面を「見て」きているため、依拠性が認められやすくなるリスクがあります。
納品物として顧客に提供する際の法的注意点
システム受託開発の現場では、納品物として「システム設計書」を顧客に提出します。この中にAI生成の図面が含まれている場合、契約上のトラブルになる可能性があります。
多くの開発委託契約では「納品物の著作権は発注者に帰属する」あるいは「受注者が著作権を持つが、発注者には利用許諾を与える」といった条項が含まれています。しかし、そもそもAI生成部分に著作権が発生していない場合、この「権利譲渡」が法的に成立しない矛盾が生じます。
また、顧客側が「AI生成物の利用」に関してガイドラインを設けている場合もあります。「権利関係が不明確なAI生成コードや図面の使用を禁止する」という条項が契約書に追加されるケースも増えてきました。
トラブルを避けるためには、納品物にAI生成コンテンツが含まれることを事前に顧客へ開示するか、あるいはAIはあくまで「下書き」や「アイデア出し」に留め、最終的な図面は人間が清書するというプロセスを徹底することが、現時点での最も安全なビジネス慣習と言えます。
リスク3：説明責任と品質保証の境界線
3つ目のリスクは、コンプライアンスというよりは「エンジニアリングの信頼性」に関わる問題です。AIが描いた図面は、果たして技術的に正しいのでしょうか。
AIが提案した構成に欠陥があった場合の責任
AIはもっともらしい図面を生成しますが、その構成が機能要件や非機能要件（可用性、セキュリティ、性能など）を本当に満たしている保証はありません。
例えば、AIが「コスト削減」を優先して冗長化構成を勝手に省略したり、逆に「高可用性」を重視して過剰なスペックのサービスを配置したりすることがあります。また、互換性のないサービス同士を線で繋いでしまうこともあります。
もし、AIが提案した構成図をそのまま採用し、後にシステム障害やセキュリティ事故が発生した場合、「AIがこう提案したから」という言い訳は通用しません。責任は100%、その図面を承認し、実装した人間にあります。
「AIが作ったから」は通用しないプロの現場
プロフェッショナルとして最も恐れるべきは、思考停止です。「AIがきれいな図を描いてくれたから、これでいいだろう」と、構成の意味を深く考えずにスルーしてしまうこと。これが最大のリスクです。
AIツールは「ドラフティング（下書き）ツール」であって、「アーキテクト（設計者）」ではありません。アーキテクトの仕事は、ビジネス要件を技術要件に翻訳し、トレードオフを判断することです。AIにはまだ、ビジネスの文脈や背景にある微妙なニュアンスを完全に理解することはできません。
AIが生成した図面は、あくまで「レビュー対象」の一つに過ぎません。新人エンジニアが描いてきた図面をシニアエンジニアがレビューするように、AIの成果物に対しても厳格なチェックが必要です。
ハルシネーション（もっともらしい嘘）の見極め
LLM特有の「ハルシネーション（幻覚）」は、図面生成でも起こります。
- 存在しないクラウドサービス名: ありそうで存在しないサービス名を捏造して図に配置する。
- 不可能な接続: ネットワーク的に接続できない領域間で線を繋ぐ。
- 古い仕様: すでに廃止された機能や、非推奨となった構成パターン（アンチパターン）を「ベストプラクティス」として提示する。
これらは一見すると非常に整った図に見えるため、知識が浅い担当者だと騙されてしまう危険があります。AIを使う人間には、AIが嘘をついていることを見抜けるだけの基礎知識と経験が、これまで以上に求められるのです。
安全な導入のための「社内ガイドライン」策定ステップ
ここまでリスクばかりを強調してきましたが、AI活用を否定しているわけではありません。むしろ、これらのリスクを正しく管理できれば、AIは設計業務を劇的に効率化する強力な武器になります。
最後に、組織として安全にAI図面生成ツールを導入するための、実践的なガイドライン策定ステップを提案します。
利用可能ツールのホワイトリスト化
まず、「何を使ってもいい」という状態を脱しましょう。情報システム部門やセキュリティ部門が審査し、安全性が確認されたツールのみを「ホワイトリスト」として公開します。
審査基準の例:
- 入力データが学習に利用されない契約（オプトアウト）が可能か。
- データセンターのリージョン（保管場所）が明確か。
- エンタープライズレベルのセキュリティ認証（SOC2, ISO27001等）を取得しているか。
- 万が一の際のログ監査が可能か。
入力データの匿名化・抽象化ルール
ツールを使う際の「入力ルール」を明確化します。現場に判断を委ねず、具体的なNG例を示すのがコツです。
ルールの例:
- 固有名詞禁止: プロジェクト名、顧客名は「仮のプロジェクト名」「仮の顧客名」などに置き換える。
- ネットワーク情報の抽象化: 具体的なIPアドレスは書かず、「Private Subnet」「Public Subnet」などの役割名で記述する。
- 個人情報の完全排除: 担当者名などは入力しない。
「機密情報は『[MASKED]』や『変数』に置き換えてからプロンプトに投げる」という手順をワークフローに組み込むことを推奨します。
生成物の利用範囲とレビュー体制の義務化
生成された図面をどこまで使って良いか、出口のルールも定めます。
- 内部検討資料: 利用可（ただし「AI生成」である旨を明記）。
- 顧客提案資料: 原則として、人間による清書と検証を経たもののみ可。
- 契約納品物: 顧客との契約内容を確認し、法務部門の承認を得る。
そして、必ず「有識者によるレビュー」を必須プロセスにします。AIが描いた図面に対して、セキュリティ担当やインフラ担当がチェックを行い、署名（承認）した段階で初めて「公式な設計図」として扱う。この人間による承認プロセス（Human-in-the-loop）こそが、品質と責任を担保する最後の砦です。
まとめ
AIによるシステム図面生成は、設計業務のスピードを劇的に向上させる可能性を秘めています。しかし、それは「魔法の杖」ではなく、扱い方を間違えれば怪我をする「鋭利な刃物」でもあります。
今回解説した3つのリスク——「情報の流出」「権利の侵害」「責任の所在」——は、どれも技術的な問題というよりは、運用とガバナンスの問題です。つまり、適切なルールと教育があれば、十分にコントロール可能です。
- 入力データ: 学習されない環境を選び、機密情報をマスクする。
- 権利関係: AI生成物は「下書き」と割り切り、人間が仕上げる。
- 品質責任: AIの提案を鵜呑みにせず、専門家が必ず検証する。
この3点を徹底することで、チームはリスクを最小限に抑えながら、AIのパワーを最大限に引き出すことができるでしょう。
コメント