私たちマカルーデジタルでは、AIの活用を積極的に進めています。一方で、私たちが公開している「AI利用に関する基本方針」では、お客様からお預かりした機密情報や個人情報などを、AIサービスへ入力することを原則として禁止しています。
企業としてAIを利用する以上、扱う情報に応じたルールを設けることは当然必要です。ところが、前回の記事で紹介したように、AIを資料作成や文章の要約だけではなく、実際の業務に組み込もうとすると、別の課題が出てきます。
顧客からの問い合わせ対応をAIに手伝ってもらうなら、問い合わせには氏名やメールアドレスが含まれているかもしれません。社内業務なら、社外秘の情報を参照する必要があるかもしれません。
では、「AIに入力してはいけない情報」を扱う仕事では、AIを使えないのでしょうか？必ずしも、そうとは限りません。
「AIが使ってよい情報」は、いつも同じではない
そもそも、企業のシステムには、「この人には見せてよいが、別の人には見せてはいけない情報」がたくさんあります。社内ポータルなら、人事担当者だけが閲覧できる情報があるでしょう。会員向けサイトなら、ログインしている会員によって表示される情報が変わることもあります。
AIを業務システムに組み込む場合も同じです。「利用者には見せてよいが、AIには見せてはいけない情報」を考える必要があります。また、そのデータをAIが使ってよいかどうかは、データそのものだけでは決まりません。 誰が、どんな目的でAIを利用しているのかまで含めた設計が必要です。
セキュリティの世界には、システムとシステムの間で「どこまでを信頼し、どこから先を検証するのか」という境界をTrust Boundary（信頼境界）として捉える考え方があります。AIエージェントを業務に組み込むときにも、このTrust Boundaryをどこに置くかが重要になります。
この問題には、大きく二つの方向から対策ができます。AIが情報を受け取る側で守る方法と、AIに情報を渡す側で守る方法です。
AIが「受け取る側」で情報をチェックする
たとえば、お客様から届いた問い合わせをAIに分類させる仕組みを作ったとします。AIにお願いしたい仕事が「問い合わせの内容を分類すること」だけなら、問い合わせに含まれる氏名やメールアドレスは必要ありません。そこで、AIモデルへ送る前に個人情報を検出し、マスキングしてから渡すことができます。
AIの世界では、このように入力や出力をチェックし、望ましくない情報や動作を制限する仕組みをGuardrail（ガードレール）と呼びます。
私たちがAIエージェントの開発に利用している「Mastra」にも、このための仕組みがあります。その一つが、個人情報などを検出するPIIDetectorです。PIIDetectorを使うことで、「個人情報をAIに入力しないでください」というルールを利用者に守ってもらうだけでなく、個人情報が入力されても、そのままAIモデルには渡さないというルールをプログラムとして実装できます。
もちろん、何が機密情報なのかは業務によって異なります。会社独自の顧客番号や案件名なども含め、何を検出し、何をAIへ渡してよいのかを設計する必要があります。MastraとGuardrailについては、次回の記事でもう少し詳しく紹介します。
AIに「情報を渡す側」で、最初から必要な情報だけに絞る
たとえば、顧客管理システムには氏名や住所、契約情報、問い合わせ履歴などが保存されていても、AIの仕事が「最近どんな問い合わせが多いかを分析すること」なら、そのすべてをAIに渡す必要はありません。そこで、「分析に必要な問い合わせ情報を取得する」という専用の機能を用意して、AIにはその機能だけを使わせます。
AIエージェントの開発では、このようにAIから呼び出せる機能をTool（ツール）と呼びます。既存システムのAPIを利用することもありますし、必要に応じて専用のCLIやAPIを開発することもあります。Toolから取得できる情報を必要最小限にしておけば、AI自身の判断に頼らず、業務システムとの間に明確なTrust Boundaryを作ることができます。
「誰に見せてよいか」を、AIに判断させない
このTrust Boundaryの考え方をCMSとの連携に応用したものが、私たちが開発しているMacareux Atlas Frameworkです。
CMSには一般公開されている情報だけでなく、会員限定のコンテンツや特定の権限を持つユーザーだけが閲覧できる情報が保存されている場合があります。
Atlas Frameworkでは、AIとCMSの間にAdapter（アダプター）を置きます。AIがCMSの情報を必要としたときはAdapterを通じて検索し、CMSのログイン状態やアクセス権限に基づいて、そのユーザーに閲覧が許可されている情報だけをAIへ返します。
ここで重要なのは、「この情報をこのユーザーに見せてよいか」をAI自身に判断させないことです。AIに判断させると、間違うことがあります。その判断をするのは、これまで通りCMSに担わせます。
このように、既存システムが持っている「誰に何を見せてよいか」というルールをTrust Boundaryとして活かすことで、安全にAIをつなぐことができます。
どこに境界を作るかは、業務によって違う
ここまで紹介した二つの方法は、組み合わせることもできます。
業務システム側では、利用者の権限に応じてAIの仕事に必要な情報だけを返す。そのうえで、AIモデルへ渡す直前にも、不要な個人情報が含まれていないかGuardrailでチェックする、といった設計です。
一方で、個人情報を取り除いてしまったら成立しない仕事もあります。その場合には、利用するAIサービスや契約条件、データの取り扱いなども含めて別の方法を検討する必要があります。
ここまでの話を整理すると、AIエージェントを業務システムにつなぐ際には、
- AIに何の情報が必要なのか
- その情報を誰が利用してよいのか
- どこで情報や操作を制限するのか
を決め、そのルールが実際に守られる仕組みを作る必要があります。
ここに、AIエージェントを「使う」ことと「構築する」ことの大きな違いがあります。
私たちは、ずっと「境界」を設計してきた
Trust Boundaryは、AIによって新しく生まれた考え方ではありません。企業向けCMSでも、ユーザーの権限によって閲覧や編集できる範囲を変えたり、外部システムとの連携で必要な情報だけをやり取りしたりします。私たちが長年携わってきた企業のWebシステムでは、誰が、どの情報に、どこまでアクセスできるのかを設計することが欠かせませんでした。
AIエージェントでは、そこに「AI」という新しい登場人物が加わります。企業の業務や既存システムを理解したうえで、AIにどこまで情報を見せ、何をさせるのか。その境界を設計し、実際に動くシステムとして実装する必要があります。
CMSを中心に、会員情報や社内システム、外部サービスなど、さまざまな業務とデータの境界に携わってきた私たちの経験も、ここで活かすことができます。
「入力禁止」で、AI活用を諦めなくていい
どんな情報でも、技術的な工夫をすればAIに渡してよいというわけではありません。扱う情報や契約、法令、セキュリティ上の要件によっては、「この業務にはAIを使わない」という判断が適切な場合もあります。
それでも、「機密情報を扱う仕事だから、AIは使えない」と最初から諦める必要はありません。なぜその情報をAIに入力してはいけないのかを確認し、AIの仕事に本当に必要なのかを考える。そのうえで、必要な情報だけが適切な条件でAIに届く仕組みを設計します。「AIに入力禁止」というルールを、人が気をつけて守るだけではなく、システムが守るルールとして実装できる場合があります。
前回の記事では、AIエージェント構築を「仕事から逆算して、AIにどう手伝わせるかをあらかじめ設計する」と説明しました。安全性についても同じです。
AIエージェントを構築することは、AIにできることを増やすだけではありません。AIに見せないもの、AIにはできないことを、技術として設計することでもあります。
どうすれば安全にAIを業務へ組み込めるのかを考え、そのTrust Boundaryを実際に動く仕組みとして実装する。そこも、私たちマカルーデジタルが提供する「AIエージェント構築サービス」の重要な要素です。
次回は、これまで何度か登場したMastraについて、もう少し詳しく紹介します。
