バクラク・楽楽精算 と経費データを MCP 経由で扱う論点｜証憑・個人情報・監査ログ（要仕様確認）

バックオフィス業務のDXが加速する中で、「バクラク」や「楽楽精算」といった経費精算SaaSに蓄積されたデータを、いかに安全かつ高度に活用するかという課題が浮き彫りになっています。特に、Anthropic社が提唱したMCP（Model Context Protocol）の登場により、LLM（大規模言語モデル）から社内SaaSのデータへダイレクトに、かつセキュアにアクセスする手法が現実味を帯びてきました。

しかし、経費精算データは「証憑（領収書等）」「個人情報」「監査ログ」という、セキュリティとコンプライアンスの塊です。本記事では、IT実務担当者の視点から、バクラクおよび楽楽精算のデータをMCP経由でハンドリングする際の具体的論点と、設計上の注意点を解説します。

バクラク・楽楽精算とMCP連携の全体像

まず、なぜ従来のAPI連携やiPaaSによる連携ではなく、MCPというプロトコルが注目されているのかを整理します。従来の連携は、あらかじめ決められたワークフローに従ってデータを流す「プッシュ型」でした。これに対し、MCPはLLMが必要な時に、必要なコンテキスト（経費データ）を取得しに行く「プル型」の柔軟なインターフェースを提供します。

なぜ今、経費精算SaaSにMCP（Model Context Protocol）が必要なのか

経理実務において、AIによる自動化のボトルネックは「データのサイロ化」でした。バクラクや楽楽精算の中に閉じ込められた証憑データや承認履歴を、AIが自由に参照・分析できるようになれば、予実管理の精度向上や、不適切な支出のリアルタイム検知が可能になります。MCPは、これらのSaaS APIを「AIが理解できる標準的なツール」として抽象化する役割を果たします。

バクラクと楽楽精算のAPI仕様・公開範囲の比較

MCPサーバーを構築する前提として、接続先となる各製品のAPI仕様を把握しておく必要があります。特に楽楽精算はオプション契約が必要となる点に注意が必要です。

バクラクは開発者フレンドリーなドキュメントが公開されており、MCPサーバーの実装が比較的スムーズです。一方、楽楽精算は歴史があるサービスゆえに、APIの利用には事前の設定確認とオプション契約の有無が重要になります。もし、既存のCSV運用からの脱却を検討している場合は、楽楽精算×freee会計の「CSV手作業」を滅ぼす。経理の完全自動化とアーキテクチャの記事も併せて参照し、API連携への移行の必要性を再確認してください。

MCP経由でのデータハンドリングにおける3つの論点

MCPを用いてLLMに経費データを渡す際、単純な文字列の受け渡しだけでは不十分です。実務上、以下の3つの論点をクリアしなければなりません。

【論点1】証憑（画像・PDF）の取り扱いとURIマッピング

MCPには「Resources」という、読み取り専用のデータを提供する仕組みがあります。経費精算における証憑（領収書PDFなど）をLLMに解析させる場合、以下の2つのアプローチが考えられます。

• Base64エンコード転送: 小さな画像ファイルであれば、MCPメッセージに直接バイナリを含めることができます。しかし、マルチページのPDFなどではトークン消費量とレスポンス速度に課題が残ります。
• 一時的署名付きURLの発行: バクラク等から取得したファイルを、S3やGoogle Cloud Storageの署名付きURL（期限付き）としてMCP Resourcesに登録する方法です。LLMはURLを参照し、必要に応じてVisionモデルで解析します。

実務的には、電子帳簿保存法の観点から「どのシステムが原本を保持しているか」を明確にする必要があるため、MCPサーバー側ではバイナリを永続保持せず、プロキシとして振る舞う設計が望ましいです。

【論点2】個人情報（PII）のフィルタリングとマスキング

経費データには、従業員の氏名、社員番号、時には振込先の銀行口座情報が含まれます。MCPサーバーを介して外部LLM（ClaudeやGPT-4など）にデータを送る場合、不必要な個人情報はMCPサーバー側でマスキング（匿名化）すべきです。

例えば、MCPサーバー内のロジックで以下のような処理を実装します。

• 「氏名」→「従業員A」のようにハッシュ化または抽象化
• 「銀行口座番号」→ APIレスポンスから除外（LLMには渡さない）
• 「住所」→ 市区町村レベルまでで切り捨て

【論点3】監査ログの統合：実行主体とアクションの記録

「誰が」「いつ」「何の目的で」MCP経由で経費データを抽出したか。これは内部統制上の重要事項です。バクラクや楽楽精算自体のログには「APIキーによるアクセス」としか記録されません。そのため、MCPサーバー側で以下の情報を構造化ログとして記録し、CloudWatch LogsやBigQueryへ集約する必要があります。

• MCP Session ID: LLMとのセッション識別子
• Invoked Tool: 実行されたツール名（例：get_expense_detail）
• User Context: LLMを操作している実ユーザーの識別子

実務における連携アーキテクチャの設計手順

ここでは、実際にMCPサーバーを立ち上げ、バクラク等のAPIと連携させるための具体的ステップを解説します。

ステップ1：APIクライアントの認証とMCPサーバーの構築

まずは、各SaaSのAPIに接続するための認証情報をセキュアに管理します。.envファイルやAWS Secrets Managerなどを用い、コード内にAPIキーをハードコードしないように徹底してください。

MCPサーバーは、Node.jsやPythonで実装可能です。@modelcontextprotocol/sdkを利用することで、比較的容易に基本構造を構築できます。

ステップ2：Tools・Resourcesの定義（Schema設計）

MCPの肝は、LLMに対して「何ができるか」を伝えるツールの定義です。以下のようなツールを定義します。

• list_unapproved_expenses: 未承認の経費一覧を取得する（承認督促AI用）
• get_receipt_image: 証憑画像を解析用に取得する
• validate_expense_policy: 社内規定と照らし合わせて経費内容をチェックする

この際、パラメータの型定義（JSON Schema）を厳密に行うことで、LLMによる「ツール呼び出しミス（ハルシネーション）」を防ぐことができます。

ステップ3：エッジケースへの対応（API制限とタイムアウト）

バクラクや楽楽精算のAPIにはレートリミットが存在します。LLMがループして短時間に大量のAPIコールを投げないよう、MCPサーバー側でスロットリング（流量制限）を実装することが不可欠です。また、SaaS側のレスポンスが遅延した場合に備え、適切なタイムアウト設定（例：30秒）を行い、LLMにエラーを適切にフィードバックする設計にします。

もし、これらのSaaS管理コストそのものに課題を感じている場合は、SaaSコストとオンプレ負債を断つ。バックオフィス＆インフラの「標的」と現実的剥がし方を参考に、SaaS全体の構成を見直すことも一つの手です。

セキュリティとガバナンス：管理者が遵守すべきチェックリスト

MCPという新しい技術を導入する以上、既存のセキュリティポリシーとの整合性を保つ必要があります。

電子帳簿保存法およびインボイス制度への影響

MCPを経由してデータを取得・加工したとしても、「国税関係書類の真実性の確保」はバクラクや楽楽精算側で担保されていなければなりません。AIが経費内容を「修正」してSaaS側に書き戻すツールを作成する場合、修正履歴がSaaS側に残ること、および再承認ワークフローが回ることを確認してください。

プロンプトインジェクションによる不正データ抽出の対策

ユーザーがLLMに対して「他人の経費データをすべて見せて」といった指示を出した場合、MCPサーバー側で実行権限をチェックする必要があります。LLMの判断に任せるのではなく、MCPサーバーに渡される「ユーザー識別子」に基づき、APIへのクエリ条件を強制的にフィルタリング（WHERE user_id = 'current_user'等）する実装が必須です。

このような権限管理の自動化については、SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャの知見が、アイデンティティ管理の面で役立ちます。

まとめ：AIと経理データの疎結合な連携を目指して

バクラクや楽楽精算のデータをMCP経由で扱うことは、単なる「便利」を超え、バックオフィス業務を「自律的な組織基盤」へと進化させる第一歩です。証憑のURIマッピング、個人情報のマスキング、そして厳格な監査ログ設計という3つの論点を押さえることで、エンタープライズ水準のAI活用が可能になります。

まずは、特定のチームや特定の申請区分（例：交通費のみ）に限定したスモールスタートから、MCPサーバーの構築を検討してみてはいかがでしょうか。仕様の詳細は各サービスの公式ドキュメントを常に確認し、最新のAPIアップデートに追従することを忘れないでください。