「AIエージェントに社内の情報を触らせて、本当に大丈夫なのか」——AI活用を検討している中小企業の経営者から、この1年でいちばん増えた質問かもしれません。議事録の要約やメールの下書きまでは安心して使えていたのに、いよいよ顧客データや業務システムにつなぐ段になると、急に足がすくむ。その感覚は、正しいものです。
ただし「怖いからやめておく」も「便利だから全部つなぐ」も、どちらも損をします。リスクの正体を知り、つなぐ前に設計で手を打てば、AIエージェントは安心して任せられる道具になります。
先に、要点をまとめます。
- AIエージェントのセキュリティは「つなぐ前の設計」でほぼ決まる。あとから付け足すほど、手戻りで高くつく
- プロンプトインジェクション（AIへの指示の乗っ取り）を完全に防ぐ方法は、2026年7月時点で確立されていない。だから「起きても被害が広がらない設計」が主戦場になる
- 押さえる設計は5つ。最小権限・人の承認・データの区画・監査ログ・接続部品の確認。専門部署がない会社でも、順番に決めていけば整えられる
※本記事は2026年7月時点の公開情報にもとづいています。AIセキュリティは変化の速い領域のため、導入判断の際は必ず各機関・各社の一次情報をご確認ください。
AIエージェントのセキュリティは、何がいままでと違うのか？
攻撃の入り口が「システムの穴」ではなく「AIが読む文章そのもの」に変わった点が、従来のセキュリティ対策との最大の違いです。
IPA（情報処理推進機構）が2026年1月に発表した「情報セキュリティ10大脅威 2026」では、組織向け脅威の第3位に**「AIの利用をめぐるサイバーリスク」が初めて選出**されました。1位のランサム攻撃、2位のサプライチェーン攻撃に次ぐ位置です。AIのリスクが「先進企業だけの話」から「どの会社にもある経営リスク」へ格上げされた、と読むべき変化です。
背景には、AIの役割の変化があります。「質問に答える」道具だったAIが、社内のデータやシステムにつながって自分で動くAIエージェントへと広がりました。接続の標準規格MCP（Model Context Protocol）が定着し、ファイルサーバー・チャット・会計ソフトとAIをつなぐ部品が手軽に手に入るようになっています。エージェント・マルチモーダル・音声AIがいまどこまで実用になっているかは、AIエージェント・マルチモーダル・音声AIの現在地【2026年7月版】で分野別に整理しています。
つないだ分だけ、仕事を任せられる。しかし、つないだ分だけ「AIが読まされる悪意ある文章」が社内に届く経路も増える。この表裏一体の関係が、AIエージェント時代のセキュリティの出発点です。
プロンプトインジェクションとは？なぜ完全には防げないのか？
プロンプトインジェクションとは、AIに読ませる文章の中に攻撃者の指示を紛れ込ませ、本来の指示を乗っ取る攻撃です。国際的なセキュリティ団体OWASPがLLMアプリの脅威第1位に挙げており、確実な防止策はまだ確立されていません。
Webセキュリティの標準で知られる国際団体OWASPは、LLM（大規模言語モデル）アプリケーション向けの脅威リスト「OWASP Top 10 for LLM Applications」（2025年版）の第1位にプロンプトインジェクションを置いています。攻撃は大きく2種類に分かれます。
- 直接型：利用者自身が対話の中で「今までの指示は忘れて、〜せよ」のような指示を打ち込み、AIの振る舞いを変えてしまう
- 間接型：AIが業務で読み込むメール・Webページ・PDFなどの中に、人間には見えない形で指示を埋め込んでおく
やっかいなのは間接型です。実例もすでにあります。2025年6月に公表された「EchoLeak」（CVE-2025-32711）は、Microsoft 365 Copilotを狙った脆弱性で、細工したメールを1通送るだけで、受信者が何もクリックしなくても社内情報を外部へ送信させられる可能性が指摘されました（Microsoftは修正済みで、実際の悪用は確認されていません）。メールに白文字などで隠された指示を、AIアシスタントが業務データと一緒に「読んで」しまい、正規の指示として実行してしまう——これが間接型の怖さです。
もちろん、AIを提供する各社も対策を重ねています。たとえばAnthropicの開発ツールClaude Codeは、ファイル変更やコマンド実行を許可制にし、疑わしい命令を検知する多層の仕組みを備えています。それでも同じ公式ドキュメントが「どんなシステムもすべての攻撃を完全には防げない」と明記しています。OWASPも「プロンプトインジェクションを確実に防ぐ方法があるかは不明」としたうえで、被害を減らすための多層防御を推奨しています。
ここで発想の転換が必要になります。**「侵入を100%防ぐ」を目指すのではなく、「乗っ取られても、できることが限られていて、すぐ気づける」状態を設計する。**これがAIエージェントのセキュリティの基本方針です。
間接プロンプトインジェクションの流れ：攻撃者が隠した指示入りのメールやWebページをAIエージェントが業務データと一緒に読み込み、隠れた指示を実行して情報の持ち出しにつながる。守る壁は入力側ではなく権限・承認・ログの側に置く
社内データにつなぐ前に、何を決めておくべきか？——5つの設計
決めることは5つです。①権限は読み取り専用から、②送信・実行の手前に人の承認、③読ませるデータの区画を分ける、④AIの操作を記録に残す、⑤接続部品の出所を確かめる。
設計1：権限は「読み取り専用」から始める
AIエージェントに与える権限は、最初は「読む」だけに絞ります。書き込み・送信・削除・決済といった「取り返しのつかない操作」の権限は、効果が確認できた業務にだけ、あとから1つずつ足していきます。OWASPが挙げる緩和策でも、最小権限は筆頭格です。
考え方は、新しく入った社員に初日からすべての権限を渡さないのと同じです。「このAIには何をどこまで任せるか」を、人の採用と同じ感覚で決めてください。読み取り専用でも、検索・要約・下書き作成といった業務価値の大半は先に検証できます。
設計2：送信・実行の手前に、人の承認を挟む
メール送信・発注・振込・データ更新など、社外や業務データに影響が出る操作の直前には、必ず人が「OK」を出すステップを入れます。ヒューマン・イン・ザ・ループ（Human-in-the-Loop）と呼ばれる、2026年時点の業務AI設計の標準形です。仮にAIが騙されて危険な動作を指示されても、実行前に人の目で止められます。
線引きの基準はシンプルで、**「取り消せる操作は自動化してよい。取り消せない操作は承認を挟む」**です。下書きの作成・社内向けの要約・検索は取り消しが効くので自動でよく、社外へのメール送信・発注・支払い・データの上書きや削除は取り消せないので承認対象、と業務ごとに仕分けていきます。承認フローの基本形と導入手順は、AIエージェントを業務に入れる前に｜「4割が中止」の理由と外さない始め方で詳しく解説しています。
設計3：AIに読ませるデータの範囲を区切る
「全社共有フォルダごと、まるごと接続」はやめて、業務単位で読ませる範囲を区切ります。EchoLeakの教訓はまさにここで、AIが読める範囲が広いほど、乗っ取られたときに漏れる範囲も広くなります。個人情報・人事・財務のデータは、最初の接続範囲から外すのが定石です。
社員ごとにアクセス権限を分けている会社なら、その区分をAIにも引き継ぎます。「経理担当しか見られない資料は、経理業務のAIしか読めない」という対応関係を守るだけで、事故時の被害はまったく変わってきます。社内文書を読ませて回答させるRAGという仕組みを受託で作る場合の権限設計は、社内文書RAGを受託で作るとき発注前に決める5つのことでも扱っています。
設計4：「AIが何をしたか」を記録に残す（監査ログ）
誰の指示で、AIがどのデータを読み、何を実行したか。この記録（監査ログ）を残す設計にしておくと、万一のときに「何が起きたか」を特定でき、被害範囲の説明もできます。逆にログがないと、事故が起きても原因究明ができず、取引先への説明もサイバー保険の請求も立ち往生します。
最低限、次の4点を記録できる設計にしておくと実務で困りません。
- いつ・誰の指示で動いたか（依頼した社員と日時）
- 何を読んだか（アクセスしたデータ・ファイルの範囲）
- 何を実行したか（送信・更新などの操作内容と結果）
- 誰が承認したか（承認ステップの記録）
人の操作ログと同じ水準で、AIの操作ログを残す。地味ですが、導入後にいちばん効いてくる設計です。
設計5：接続部品（MCPサーバー等）の出所を確認する
AIと社内ツールをつなぐMCPサーバーなどの接続部品は、インターネット上に無数に公開されています。便利な一方で、出所のわからない部品を業務環境に入れるのは、素性不明のソフトをサーバーにインストールするのと同じ行為です。MCPの公式仕様にもセキュリティ上の注意点をまとめた文書があり、接続部品の信頼性確認は利用者側の責任とされています。自社開発するか、提供元が明確で更新が続いている部品を選ぶ。この確認を導入チェックリストに含めてください。
AIエージェントを社内データにつなぐ前の5つの設計：①最小権限（読み取り専用から始める）②人の承認（送信・実行の手前に挟む）③データの区画（業務単位で範囲を区切る）④監査ログ（AIの操作を記録する）⑤接続部品の確認（出所不明のMCPサーバーを使わない）
中小企業はどの順番で進めればよいか？
「棚卸し→ルール整合→読み取り専用で試す→限定運用→拡大」の5段階です。本格導入までの標準は3〜5ヶ月。最初の一歩は、1〜2週間の棚卸しから始まります。
| 段階 | やること | 期間の目安 |
|---|---|---|
| 1. 棚卸し | つなぎたい業務、読ませてよいデータ、触らせないデータを一覧にする | 1〜2週間 |
| 2. ルール整合 | 既存のAI利用ルールと突き合わせ、承認者と禁止事項を決める | 1〜2週間 |
| 3. 読み取り専用PoC | 限定データ＋読み取り専用で精度と業務効果を検証する | 1〜2ヶ月 |
| 4. 限定運用 | 承認フロー・監査ログを本番形にして、1業務だけで運用する | 1〜3ヶ月 |
| 5. 拡大 | 効果の出た業務から範囲を広げ、権限も業務単位で追加する | 継続 |
この順番の利点は、セキュリティの検証と費用対効果の検証が同時に進むことです。段階3の読み取り専用PoCは、「このAIは業務で使い物になるか」と「このデータ範囲で事故は起きないか」を一度に確かめる工程になります。段階4へ進む判断基準も先に決めておきましょう。たとえば「回答の正確さが実用水準か」「対象業務の作業時間が減ったか」「検証期間中にヒヤリとする挙動がなかったか」の3点を通過条件にすれば、感覚ではなく数字と記録で投資判断ができます。社内のAI利用ルールをまだ整備していない場合は、先に中小企業のAI業務利用ルール整備6ステップを済ませておくと、段階2がそのまま短縮できます。
セキュリティ設計を含めると、費用はどう変わるのか？
セキュリティは「追加の見積もり項目」ではなく、開発費に最初から織り込むものです。あとから足すと設計のやり直しが発生し、初めから含めるより高くつきます。
段階別の費用イメージは次のとおりです。
- 既存AIツールの活用（1ユーザー月数千円程度〜）：追加開発は不要で、管理画面の設定確認が中心です。「入力データを学習に使わせない設定」「接続範囲の設定」を確認するだけでも、リスクは大きく下がります
- 読み取り専用のPoC（1〜2ヶ月）：限定したデータで試す構成なら、PoC自体がセキュリティ検証を兼ねます。ゼットリンカーではこの段階をAI PoC開発として受託しています
- 業務システムへの本格組み込み（初期300〜500万円が目安）：権限設計・承認フロー・監査ログは、この開発費の中に含めて設計するのが標準的な進め方です（※2026年7月時点のゼットリンカーの受託レンジに基づく目安。対象範囲・連携先で変動します）
避けたいのは、「PoCの設定のまま本番運用に入る」パターンです。検証用に広めに開けたデータアクセスと承認なしの自動実行が、そのまま本番に残る。この状態で事故が起きると、被害も、あとからの改修費用も大きくなります。PoCと本番の間に「権限・承認・ログを本番形に組み直す」工程を必ず挟んでください。
よくある失敗と回避策
**失敗の多くは技術の問題ではなく、「つなぐ前に決めるべきことを決めていない」ことから起きます。**代表的な5つを挙げます。
| よくある失敗 | 何が起きるか | 回避策 |
|---|---|---|
| 全社データを一気につなぐ | 乗っ取られた場合の漏えい範囲が最大化する | 業務単位で区画を分け、段階的に広げる（設計3） |
| 承認なしで送信・実行まで自動化 | 誤送信・情報持ち出しに誰も気づけない | 取り返しのつかない操作の手前に人の承認（設計2） |
| 出所不明のMCPサーバーを導入 | 悪意ある部品が社内への入り口になる | 自作か、提供元が明確な部品のみ使う（設計5） |
| ログを残さず運用 | 事故時に原因も被害範囲も特定できない | AIの操作記録を人の操作と同水準で残す（設計4） |
| PoCの設定のまま本番運用 | 検証用の緩い権限が本番に残り続ける | 本番移行時に権限・承認・ログを組み直す |
いずれも、開発の最初に設計へ織り込めば大きな追加費用にはなりません。逆に運用開始後に直そうとすると、業務を止めての改修になります。「つなぐ前」が、いちばん安く・確実に手を打てるタイミングです。
まとめ——「つなぐ前の設計」が最大のセキュリティ投資
AIエージェントのセキュリティを、あらためて要点で締めくくります。
- 攻撃の入り口は「AIが読む文章」に変わった。IPAの10大脅威2026にもAIリスクが初選出された
- プロンプトインジェクションを完全に防ぐ方法はまだない。「起きても被害が限定され、すぐ気づける」設計が主戦場
- 決めることは5つ——最小権限・人の承認・データの区画・監査ログ・接続部品の確認
- 進め方は「棚卸し→ルール→読み取り専用PoC→限定運用→拡大」。セキュリティと費用対効果の検証を同時に進める
セキュリティを理由にAI活用を止める必要はありません。必要なのは、つなぐ前に設計を決めることだけです。
ゼットリンカーでは、AIソフトウェア開発として、権限設計・承認フロー・監査ログまで含めた「業務に入れて事故らないAI」の設計と開発をお手伝いしています。「まず小さく確かめたい」という段階なら、読み取り専用の構成で1〜2ヶ月から始めるAI PoC開発が向いています。自社のデータをどこまでつないでよいか迷っている段階でも、お問い合わせからお気軽にご相談ください。お見積もり・ご提案は無料です。
よくある質問（FAQ）
Q. プロンプトインジェクションは、ウイルス対策ソフトやファイアウォールで防げますか？
A. 基本的に防げません。攻撃が「普通のメールやWebページの文章」として届き、AIがそれを読むこと自体は正常な動作のため、従来型の防御では検知しにくいのが実情です。だからこそ、読ませる範囲を区切る・実行前に人が承認する・操作記録を残すといった「被害を限定する設計」で備えます。
Q. 社内データをAIにつなぐこと自体、やめておくべきではありませんか？
A. 「つながない」判断にもリスクがあります。業務効率の機会損失に加えて、会社が用意しないと社員が個人契約のAIに業務データを入力する「シャドーAI」が起きやすくなるためです。禁止するのではなく、読ませてよいデータの範囲と承認ルールを決めて、管理された形でつなぐことをおすすめします。
Q. EchoLeakのような脆弱性は、修正済みなら安心してよいですか？
A. 個別の脆弱性の修正と、攻撃手口への備えは別ものです。EchoLeak自体はMicrosoftが修正済みで悪用も確認されていませんが、「AIが読む文章に指示を隠す」という手口は今後も形を変えて現れると考えるべきです。特定製品の修正に頼らず、最小権限・人の承認・監査ログという設計側の備えを整えることが本質的な対策になります。
Q. 無料のAIツールに顧客情報を入力するのは問題ですか？
A. 無料プランでは、入力内容がAIの学習・改善に使われる設定が既定になっている場合があります。顧客情報や機密情報を扱う業務では、学習に使わない設定を契約で担保できる法人向けプランやAPIを使い、設定を確認したうえで利用してください。入力してよい情報の線引きは、社内ルールとして明文化しておくのが確実です。
Q. セキュリティまで任せられる開発会社は、どこで見分ければよいですか？
A. 見積もりや提案の段階で、権限の絞り方・人の承認フロー・監査ログの話が先方から出てくるかを見てください。「何でもつなげます」「全部自動化できます」という便利さの話だけで、事故時の設計に触れない提案は要注意です。PoC段階から読み取り専用構成を提案してくれる会社なら、本番化まで安心して進めやすくなります。
運営・編集
株式会社ゼットリンカー