生成AIを用いた Jira/Confluenceの機密情報検出

はじめに

業務に生成AIを活用する機会が増える中で、意図せず機密情報が AIツールを通じて外部に漏洩するリスクが現実味を帯びてきています。

特に、プロンプトインジェクションのような攻撃手法により、AIにアクセスできる範囲の情報が漏洩するケースも報告されています。

実際に、Atlassian製品（JiraやConfluenceなど）も攻撃対象となる可能性があることが、Cato Networksの調査によって明らかにされています。

参照元：Cato CTRL™ Threat Research: PoC Attack Targeting Atlassian's Model Context Protocol (MCP) Introduces New "Living Off AI" Risk

Jiraや Confluenceに保存された機密情報の保護は、弊社の課題であると同時に、お客様の業務安全性にも深く関わる問題です。

弊社が定義する機密情報には、以下のような項目が含まれます（一部抜粋）

• 顧客、取引先のデータ情報
• 認証情報(パスワード、APIキーなど)
• 個人情報
• 発注書、見積書

このような情報は、日常的に Jiraや Confluenceに記録・共有されているのが実情です。

検出方針とその背景

こうした情報を生成AIの予期せぬ挙動から守ることを目的として、AIを活用して社内の機密情報を検出・分類する試みを行いました。

Atlassian Guard Detectというサービスで機密情報を検出することは一定程度は可能ですが、以下の問題があります。

• 添付ファイルは対象外
• 更新時以外で既存のコンテンツをスキャンできない
• 検出対象を Atlassian製品の外に広げることはできない

事前の調査を待つまでもなく、社内の Jira/Confluenceには機密情報とみなされる情報が大量に保存されていることが明らかでした。

そのため、今回の検出作業では機密情報の隔離作業にかかる負荷を下げることを重視し、偽陰性（検出すべきものを検出しないこと）を減らすことよりも、偽陽性（検出すべきではないものを誤検出すること）を減らすことに重点を置きました。

この方針のもと実際に Jira/Confluenceの全体にわたって検出処理を実施しました。

本ブログでは、その技術的な取り組みと知見について、具体的な方法・モデル選定・実装上の課題とともにご紹介します。

Confluenceの検出作業

検出対象と範囲

対象：全ページを対象に処理を実施

社内Confluenceには、部門・プロジェクトごとに厳格な権限設定が施されたページが多数存在しており、こうしたページにも検出を適用する必要がありました。

そのため、組織管理者・サイト管理者権限でのみ使用可能な Admin Key APIを用いることで、すべてのコンテンツに対してアクセスを可能としました。

添付ファイルについても検出対象とすることを検討しましたが、技術的な制約により、今回はファイル本体の内容を直接解析する方式は採用しませんでした。

画像や PDFであれば OCR技術を使って内容を取得することも可能ですが、添付ファイルはフォーマットや内容が多岐にわたるため、全種類を網羅的に処理するのは非現実的であると判断しました。

代替策として、ファイル名に着目して機密情報の有無を検出対象とする方針を採用。簡易的ながら添付ファイルの検出もある程度カバーできる仕組みとなっています。

モデル選定と理由

Confluence上に保存されたコンテンツの機密情報を AIで検出するにあたって、最初の検討事項は「どのモデルを使うか」という点でした。

扱うデータの性質から、外部への情報流出リスクを最小限に抑えることと、コスト・実行速度のバランスが重要な判断基準でした。

当初は、外部の LLMサービスを使わずに、社内クラウド環境にオープンソースのモデルをデプロイして運用する案も検討しました。

これは情報管理の観点からは理想的に思えましたが、現実的な運用コストと処理時間を考慮した結果、外部サービスを活用した方が圧倒的に効率的であるという結論に至りました。

弊社内で既に利用実績のある OpenAIのモデルは、導入や検証の観点でもハードルが低く、またOpenAI社は提供されたデータを一定期間後に破棄することを明言しています。

これにより、ある程度の安心感を持って機密情報を処理することが可能です。OpenAIのモデルの中でも、軽量な o3-miniを採用しました。

このモデルは十分な精度とコストバランスを持ち、実用上問題のないレベルで信頼性の高い出力を得ることができました。

プロンプト設計と検証結果

実際に機密情報を含むと想定される Confluenceページをいくつか選定し、それらを対象に生成AIによる検出のテストを行いました。

結果、意図した情報が検出されないケースはほとんどなく、むしろ想定していなかった情報が検出される場面が多く見られました。

誤検知に関しては、出力結果とプロンプトの記述内容を照合・精査した結果、当該プロンプトの表現において誤検知が発生するのは合理的であると判断できるケースが大半を占めていました。

このことから、プロンプトにおいて意図を過不足なく正確に表現することの難易度の高さが改めて浮き彫りとなりました。

添付ファイルについては、「ファイル名のみから内容を推測して判断せよ」という、やや抽象的な指示を含むプロンプトを用いましたが、それに対しても AIは比較的一貫した振る舞いを見せ、意図通りの判断が行われていました。

この点は期待以上の成果でした。

入出力のフォーマット

入力には、Confluence標準の Storage Formatをそのまま使用しました。

ページ本文のみを抽出するのは手間と工数が大きいため、多少のトークン効率低下は許容し、納期優先の方針を取りました。

結果として、生成AIは Storage Formatでも十分に文脈を理解できることを確認できました。

大きいページにはスライディングウィンドウ方式でデータを分割して、出力は JSON形式とし、機密情報検出の結果を構造化して返すようにしました。

当初、Zero-shot(例示なしで出力させるプロンプト)ではスキーマが崩れることが頻発しましたが、Few-shot(いくつか例示するプロンプト)で具体的な例を提示することで、安定してスキーマ準拠の出力を得られるようになりました。

データ抽出用のスクリプト

Atlassianの REST APIを利用したデータ抽出では、安定性と効率性を確保するための工夫が欠かせません。

実際の運用では、APIが頻繁にエラーを返すことがあり、Internal Server Errorにとどまらず、HTTP接続そのものが切断されるケースも発生します。そのため、堅牢なリトライ処理を組み込むことが必須です。

さらに、長時間にわたって全ページを順次取得するプロセスでは、レートリミットを超過しないよう制御する仕組みも必要となります。

特に Confluence全体を対象にした検出処理では、数十万件規模のリクエストが発生する可能性があるため、再試行間隔の調整や指数バックオフの導入など、実運用に耐えうる設計が求められます。

これらを考慮し、スクリプトは「エラー耐性」と「効率的なページング処理」を両立させる形で実装しました。全ページを取得する処理は時間を要しますが、堅牢な仕組みとすることで、長時間の実行でも安定してデータを収集できました。

Jiraの検出作業

検出対象と範囲

対象：全プロジェクトに属するすべての課題

社内の Jiraには、プロジェクトごとの閲覧権限や課題セキュリティ設定によって制限されたタスクが多数存在します。

そのため、作業用アカウントに全プロジェクトおよび課題セキュリティレベルに対応できる権限を付与することで、包括的な検出を可能としました。

検出対象フィールドは、コメントを含むすべてのテキストデータに限定しています。

Jiraでは課題のあらゆる情報がフィールドに保存されますが、選択リストのようなフィールドはIDのみが保持されるため、検出対象とする必要がありません。

リッチテキスト形式のフィールドについては、JSONをそのままシリアライズしてプロンプトに入力しました。モデルは JSON構造を適切に理解し、内容を問題なく解析できることを確認しました。

添付ファイルについては、Confluenceの場合と同様に、ファイル名に基づいて機密情報の有無を推定する方式を採用しました。

モデル選定と理由

Confluenceでの検出作業においては OpenAIのo3-miniを用い、十分な精度とコスト効率を得られました。

その成果を踏まえつつ、Jiraの検出ではよりコストパフォーマンスに優れた選択肢を模索しました。

ちょうどその頃、Google主催のセミナーにて「o3-miniと Gemini 2.5 Flashは同程度の性能を持ちながら、後者はコストが入力コストが約1/4、出力コストが約1/2である」との知見を得ました。入力データを一定期間保持の後に破棄すると明示しています。

これを踏まえ、Jiraの検出には Gemini 2.5 Flash を採用しました。結果として、精度を維持しながら運用コストを大幅に削減することができました。

入出力のフォーマット

入力は、Markdownと JSONを組み合わせた形式を採用。

課題データ全体を JSON化するとトークン効率が悪いため、基本的には Markdownで与えつつ、リッチテキスト部分のみを JSONで与えました。

出力はConfluenceの場合と同様、JSON形式で構造化された検出結果を返す仕様としました。

実装上の工夫

実装フローやプロンプト設計の基本方針は Confluenceでの検出と共通しています。

Jira及び Confluenceの検出結果

今回の取り組みでは、Confluence約20万ページ、Jira約20万課題を対象に検出処理を実施しました。

コストはそれぞれおよそ20万円規模となり、大規模な運用でも現実的に実施可能であることを確認できました。

その結果、Confluenceでは約1万ページ、Jiraでは約10万課題に機密情報が含まれていると検出されました。

想定以上に大量の情報が対象となったことで、「生成AIによる機密情報検出は技術的に十分実用化できる」と同時に、「検出後にどのように対処するか」が次なる大きな課題であることが明らかになりました。

現在は検出された機密情報のカテゴリーごとに優先順位をつけて、人力での隔離作業を実施していますが、この方法では限界があります。

大量の機密情報が検出されているスペース・プロジェクトは別のスペースに隔離することや古い情報は無条件に隔離するなど検討を進めていますが、これといった決定打が無い状況です。

まとめ

いかがでしたでしょうか。生成AIを活用して Confluenceおよび Jira上の機密情報を検出するための技術的取り組みについてご紹介しました。

モデル選定、プロンプト設計、スクリプトの実装、そして大規模データに対する実運用の知見など、多くの試行錯誤を通じて、実用的な手法を構築することができました。

今回の検出作業によって、想定以上に多くの機密情報が蓄積されている実態が明らかになり、検出だけでなく「検出後の対応」が今後の重要な課題であることも再認識しました。

今後は、検出結果を基にした隔離や通知、権限管理の自動化などを視野に入れた、さらなる対策の高度化を進めていく予定です。

生成AIは、セキュリティリスクにも対処できる強力な武器となり得ます。本取り組みが、同様の課題に直面している他の組織の一助となれば幸いです。

生成AI×横断検索ツール「Rovo」

「あれ、あのファイルどこだっけ？BOX？ Google Drive? SharePoint?」
そんなふうに探す手間なく、横断で検索します。
さらに、AIエージェントが反復作業を代行してくれます。

Rovoについてもっと知る