AI はあなたを知るほど役に立つ：安全な範囲でエージェントに情報を渡す

エージェントはあなたを深く理解するほど、的確な助言やニーズに合ったサービスを提供でき、日々の仕事でも賢く感じられるようになります。

Meta の Muse から OpenAI の dot まで、AI アシスタントは好みを覚え、アプリを接続し、継続的にタスクを処理するようになっています。Meta Muse の公式紹介 · OpenAI dots の公式紹介

強力なモデルでも、あなたの目標、状況、制約を知る必要があります。個人向けのアシスタントには、カレンダー、メール、会話の記録、生活の好みに関する情報が必要です。企業向けには ERP、CRM、OA（オフィス業務の自動化）システムのデータと外部の市場情報が必要です。それらを踏まえて初めて、業務を熟知したコンサルタントのように助言し、許可された範囲で仕事を代行できます。

こうした情報を渡すことは、AI を業務に活用する前提です。安心して仕事を任せられるかどうかは、その情報をどう守るかにかかっています。

十分な情報が、行き届いた対応につながる

出張先だけを知るアシスタントは、ホテルを提案できます。会議の時間、顧客の住所、あなたの予定や移動の好みまで知っていれば、適切な便を選び、予定の重複を確認し、顧客向け資料の準備も促せます。

より多くのことに気を配れるのは、あなたの状況を知っているからです。

企業の問題はさらに複雑です。運営責任者が「来月はどの商品を重点的に売り込むべきか」と尋ねたとします。

エージェントには、CRM の顧客ニーズ、ERP の在庫と納品能力、OA の承認要件に加え、売上、代金回収、市場の変化に関する情報が必要です。需要だけを見れば、供給が追いつかない商品を提案するかもしれません。在庫だけを見れば、新たな市場機会を逃すかもしれません。売上だけを見れば、利益や代金回収の問題を見落とすかもしれません。

エージェントには詳細な情報と、業務全体を見渡す視点の両方が必要です。 顧客、供給、財務、市場の関係を理解してこそ、その会社に合った助言かどうかを判断できます。

十分な情報とは、正確で最新の業務データに加え、過去の経緯、組織の目標、意思決定上の制約も含みます。それらが業務の理解を支え、モデルの推論能力を仕事に生かします。

目標、好み、過去の経緯、業務上の制約
                   ＋
ERP：在庫と納品 · CRM：顧客ニーズ · OA：承認
                   ＋
          業界動向と市場情報
                   │
       ID とタスクに応じたアクセス許可
                   ↓
 エージェントが情報を関連付け、業務全体を理解
                   ↓
  根拠のある助言と、行き届いたサービス・行動

図：エージェントが文脈を使ってサービスを提供する流れ。モデルの能力とデータ品質は判断に影響するため、重要な意思決定には担当者の確認が必要です。

AI 活用を進めない企業が直面すること

ある企業はエージェントを使い、顧客の反応を継続的にまとめ、在庫を確認し、市場の変化を追っています。別の企業は、従業員が各システムを調べ、報告書を作り、情報を伝達しています。前者の仕事が速く安定するほど、対応速度と連携コストの差は広がります。

競合が効率を改善し続ける一方で、従来の方法にとどまれば、追いつくことは難しくなります。その差が顧客体験、運営コスト、意思決定の速度に蓄積すると、競争力を失い、市場から退出を迫られる可能性もあります。

企業は AI 活用を進めると同時に、データ接続に伴うセキュリティの問題を解決する必要があります。顧客との商談準備、在庫異常の分析、市場レポートの作成など、具体的なタスクから始められます。必要な情報をエージェントに渡し、成果を見ながら利用範囲を広げます。

外部からの保護：データと認証情報を守る

エージェントを業務システムに接続したら、外部からの保護と内部の権限管理の両方が必要です。

外部からの保護では、まず不正アクセスを防ぎます。業務データだけでなく、OAuth Token や API Key などの認証情報も保護対象です。認証情報が漏れると、攻撃者が元のシステムに継続してアクセスできるおそれがあります。モデルの文脈、タスク記録、ログに入ったデータも適切に扱う必要があります。

OOMOL のクラウドは、機密データをエンベロープ暗号化で保護します。データ暗号化キーでデータを暗号化し、別のキーでそのデータ暗号化キーを保護します。アプリの呼び出しは許可された範囲で実行され、メンバーはアカウントのパスワードや元の Token に触れる必要がありません。セキュリティとコンプライアンス

接続時には、どのモデルやサービスがデータを処理するのか、保存期間はどれくらいか、許可をどう取り消すのかも確認します。これらの取り決めが、元のシステムを離れた後のデータ保護を左右します。

内部の保護：権限を ID に結び付ける

企業の内部にあるデータも漏えいする可能性があります。

営業担当者が自分の顧客を閲覧できても、全社員の給与を見てよいわけではありません。在庫を照会できても、購買承認を変更する権限があるとは限りません。管理者が使った財務資料も、共有アシスタントのメモリに入っただけで他のメンバーから閲覧できてはいけません。

誰がどのデータを読み、どの操作を実行できるかを ID に結び付け、システムで確認する必要があります。 アクセス範囲の確認は、データがモデルに渡る前に行います。

OOMOL の管理者は、各接続で許可する操作と、その接続を使えるメンバーを設定できます。同じアプリのアカウントに複数の接続を作り、メンバーごとに異なる操作範囲を割り当てられます。最終的な権限は、アプリ側の許可と呼び出し元の ID にも制約されます。アクセス制御の説明

接続層は接続と操作の権限を管理します。個別の顧客や部門のデータへのアクセスには、元のシステムの権限とアプリの実装も関わります。アシスタント製品やワークフローでは、共有メモリと結果の受信者も管理する必要があります。例えば、財務報告書を読む権限があっても、エージェントに全社員向けのチャットへ送信させてよいとは限りません。

コンプライアンス：セキュリティ評価と個人データ保護

OOMOL は TAC Security の CASA/ESOF セキュリティ評価に合格し、GDPR の個人データ保護要件に従っています。プライバシーポリシーでは、データの処理方法、利用者の権利、プライバシーに関する請求窓口を説明しています。OOMOL のセキュリティとコンプライアンス · プライバシーポリシー

CASA/ESOF は対象範囲内のアプリケーションのセキュリティを評価します。GDPR は処理目的、データ最小化、個人の権利保護など、個人データの処理要件を定めています。TAC Security の評価説明 · EDPB のデータ保護ガイド

これらは開発と運営に反映する必要があります。用途と保存方法を定め、必要なデータだけを処理し、利用者が許可を管理してプライバシーに関する請求を行えるようにします。サービスを選ぶ企業も、評価範囲、データの流れ、双方の責任を確認できます。

オープンソース：重要な実装を検証可能にする

OOMOL はオープンソースの接続ゲートウェイ OpenConnector を保守し、oo CLI と Connector SDK のソースコードも公開しています。OpenConnector は Apache 2.0、oo CLI と Connector SDK の公開リポジトリは MIT ライセンスです。

開発者は呼び出しがどう送られるか、接続がどう実行されるか、どこで権限が確認されるかを調べ、問題を issue として報告したり、修正に参加したりできます。

ソースの公開は、コミュニティによるレビューと、企業による重要なコードの直接確認を可能にします。実際のデプロイがソースと一致しているか、設定がセキュリティ要件を満たしているかは、別途確認が必要です。

重要な実装を確認でき、問題と修正の経過を追えること。その透明性によって信頼を築きたいと考えています。

OpenConnector のソース · oo CLI のソース · Connector SDK のソース

一つのタスクから始める

エージェントに任せたいタスクを選び、必要な情報、実行できる操作、結果を見られる人を整理します。関連システムを接続して権限を設定し、成果が役立つかを確認します。

タスクが進んだら、不足する背景や他のシステムの情報を補い、新たなデータアクセスと操作権限も確認します。OOMOL は暗号化、アクセス制御、セキュリティ評価、主要コンポーネントのオープンソース化でこの過程を支え、個人や企業がより安心してエージェントを使えるようにします。

OOMOL のセキュリティとコンプライアンスを見る · 接続権限を設定する