月末になると、経理担当者はその月に発生したすべての請求書を1件ずつ開き、請求書番号は正しいか、日付は合っているか、為替レートは最新か、VATの設定は妥当か、言語は取引先の国に合っているか、明細の記載内容は規約通りか——といった項目を目視でチェックしていきます。
ミスがあれば、顧客に送ってから気づいて訂正する、という事態になりかねません。
かといって、この確認作業を単純に「AIに丸投げ」してよいわけでもありません。請求書は一度発行してしまえば取り消しが難しく、金額や為替レートの判断を誤ったAIの自動修正がそのまま顧客に届いてしまえば、取り返しがつかないからです。
ここで鍵になるのが、AIエージェントを「安全に、必要な範囲だけ」既存の業務システムに接続する仕組みです。
BunbuではこれをMCP（Model Context Protocol）というプロトコルを使って実装しました。本記事では、実際の請求書レビュー業務を例に、MCPとは何か、そしてAIを社内システムに統合する際に何を設計すべきかを紹介します。
I. MCP（Model Context Protocol）とは何か
MCPは、AIモデル（Claude などのAIエージェント）と外部のシステムやデータソースを接続するための標準プロトコルです。
これまでAIを業務システムに組み込む場合、多くは次のような方法が取られてきました。
- 個別のAPIを都度実装し、AIにその使い方をプロンプトで説明する
- AI向けの専用バッチ処理やスクリプトを別途用意する
- AIにDBへの直接アクセスを許可してしまう
これらはいずれも、システムごとに接続方法がバラバラになる、AIに与える権限の境界が曖昧になる、といった問題を抱えがちでした。
MCPは、この「AIエージェントと業務システムの接続部分」をServerという単位で切り出し、Toolという形で明示的に公開するという考え方を取ります。
MCP Serverは、いわば「AIエージェントに公開する業務APIの窓口」です。AIは、Server側が公開したTool（関数）だけを呼び出すことができ、それ以外の操作はできません。何ができて何ができないかが、コードとして明確に定義されます。
II. Bunbuが直面していた課題
Bunbuでは、社内CRMで顧客への請求書を管理しています。月末には、その月に発生した請求書を確認し、PDFを作成して顧客に送付する運用フローがあります。
このレビュー作業には、次のようなルールが存在します。
- 請求書番号は、プロジェクトごとに決まったルール（プロジェクトの略称＋年月など）で採番されているか
- 請求日・支払期日は取引の慣習と一致しているか
- 為替レートはシステム上の最新レートと乖離していないか
- VATの設定は顧客の国・契約内容に対して妥当か
- 請求書の言語は、顧客の国に合っているか
- 明細（Item）の記載内容は、社内の命名規約（対象年月の記載など）に沿っているか
- 現在アクティブなプロジェクトのうち、その月の請求書がまだ作られていないものはないか
これらは一つひとつは単純なチェックですが、件数が増えるほど見落としが起きやすくなります。一方で、そのすべてを自動修正してよいわけではありません。
例えば為替レートは、どの時点のレートを採用するかという事業判断が絡みます。明細の記載内容も、正しい表記が何かはプロジェクトの状況次第で変わります。ここをAIが勝手に「それらしく」書き換えてしまうと、かえって危険です。
つまり必要だったのは、「機械的に確実に正しいと言えることは自動化し、判断が必要なことは必ず人に委ねる」仕組みでした。
III. MCP Serverによる解決アプローチ
Bunbuでは、この請求書レビュー業務をMCP Serverとして実装しました。AIエージェント（Claude）は、このServerが公開するToolを呼び出すことで、CRM上の請求書データにアクセスします。
1. 業務をToolという単位に分解する
実装したToolは、例えば次のようなものです。
- list_month_invoices — 対象月の請求書一覧と、請求書が未作成のアクティブプロジェクトを取得する
- check_invoice — 1件の請求書をルールに照らしてチェックし、Issueのリストを返す
- fix_invoice — 機械的に確実に修正できるIssueだけを自動修正する
- update_invoice_currency_rate / update_invoice_item_name — 人が値を決めたうえで、その値を反映する
- create_invoice_pdf — レビューが完了した請求書のPDFを作成・押印する（送付はしない）
AIエージェントは、これらのToolを組み合わせて「今月の請求書を一覧し、1件ずつチェックし、直せるものは直し、判断が必要なものは人に確認する」という一連の業務フローを実行します。
2. 安全性は「運用ルール」ではなく「コード」で担保する
このServerの設計で最も重視したのは、AIの振る舞いを、指示文（プロンプト）ではなくServer側のコードで制約することです。
具体的には、次のような制約をServer側に実装しています。
- 修正・PDF再作成ができるのはdraft状態の請求書のみ。すでに顧客へ送付済み（unpaid / paid）の請求書は、内容もPDFも変更できない
- データを書き換えるToolは、権限を持つロール（admin）でなければ呼び出せない。閲覧・チェックのみのロール（accountant）は実行できない
- すべての変更操作は、誰が実行したかが分かる形で監査ログに記録される
- 為替レートの自動修正は行わない。ズレを検知した場合は「現在のレート」と「システム計算上のレート」を提示するだけで、どちらを採用するかは必ず人が指定する
- プロジェクトの略称が未設定など、必要な情報が欠けている場合、AIは請求書番号を推測しない。警告を出し、人が設定を行うよう促す
AIに「〜しないでください」と指示するだけでは、いずれ想定外の入力や解釈で境界を越えてしまう可能性があります。境界はプロンプトではなく、呼び出せるTool自体をコードで制限することで担保します。
3. 「顧客へ送る」という最後の一歩は、あえて自動化しない
PDF作成Toolまでは自動化していますが、そのPDFをメールで顧客に送付する操作は、意図的にAIエージェントの範囲外としています。
請求という、顧客との関係に直接関わる最後のアクションは、必ず人が最終確認したうえで実行する——これは技術的な制約というより、業務上の意思決定として明確に線引きしています。
IV. 設計で重視したポイント
今回の実装を通じて、社内業務にAIエージェントを組み込む際に重要だと感じたポイントは、大きく3つです。
1. 「自動化できること」と「自動化すべきこと」は別
技術的には為替レートの自動修正も、請求書の自動送付も実装できます。しかし、それが正しい判断とは限りません。どこまでを自動化し、どこから先を人の判断に委ねるかという線引きは、AIに聞くことではなく、業務を理解した人間が設計すべき部分です。
2. 安全性はプロンプトではなく仕組みで作る
AIエージェントの指示文をどれだけ丁寧に書いても、それは「お願い」でしかありません。draft状態でなければ変更できない、権限のないロールでは実行できない、といった制約をServer側のコードで実装することで、AIの振る舞いに関わらず安全性が保証されます。
3. 小さく、権限の明確なToolに分解する
「請求書を処理する」という大きな1つのToolを作るのではなく、一覧・チェック・修正・PDF作成という単位に分解し、それぞれに必要な権限と対象範囲（draftのみ、など）を個別に定義しました。これにより、AIが何を、どこまでできるのかが常に明確になります。
V. Bunbuからのメッセージ
MCPは、AIエージェントを既存の業務システムに接続するための標準的な方法を提供します。重要なのは、MCP自体が安全性を保証してくれるわけではないという点です。
どのToolを公開するか、それぞれのToolにどんな制約を持たせるか、どこから先は人の判断に委ねるか——こうした設計を行うのは、これまでと同じく、業務とシステムの両方を理解したエンジニアの仕事です。
Bunbuでは、既存の業務システムやCRM・ERPに対して、こうしたMCP Serverの設計・実装を支援しています。
既存システムの現状を把握する → どこまでをAIに任せられるかを整理する → 安全に自動化できる範囲をToolとして設計する → 段階的に業務へ組み込む
「AIに全部任せる」のではなく、「AIと安全に協働できる仕組みを作る」——これが、Bunbuが考えるAI時代の業務システム統合のアプローチです。
