自作MCPサーバーで事務所の業務データをAIにつなぐ7工程と守秘の線引き

自作MCPサーバーとは、事務所の業務データをAIにつなぐ自前の接続口のことです。

既製のMCPサーバーを入れるか、事務所で作るか。この分岐で悩む事務所が増えています。この記事では、顧客管理や進行管理のデータを生成AIから読ませるための自作サーバーの作り方を、設計から運用まで7工程で整理します。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、行政の見解は各府省庁の公表資料で確認しています。MCPの公式ドキュメントでは、サーバーが提供できる機能はリソース、ツール、プロンプトの3種類と説明されています（出典: Model Context Protocol「Build an MCP server」）。

既製のMCPサーバーでは足りない場面が2026年に増えた理由

自作を検討する事務所が増えた理由は、既製のサーバーが汎用のクラウドサービス向けに作られていて、事務所固有のデータ構造に合わないからです。会計ソフトやグループウェアの公式MCPサーバーは増えましたが、事務所が長年育ててきた案件管理のスプレッドシート、期限管理の台帳、過去の書式ライブラリは、どのベンダーもカバーしません。ここに接続口がないと、AIは事務所の一番濃い資産を読めないままになります。

MCP自体の仕様も、この1年で自作しやすい方向に動いています。2026年7月28日版の仕様では、サーバーが公開する機能がリソース、ツール、プロンプトの3層に整理され、Python と TypeScript の公式SDKがこの版に対応しています（出典: modelcontextprotocol/python-sdk、MCP TypeScript SDK v2）。仕様の変化そのものは、士業のチカラでもMCPが2026年7月に大改訂事務所のシステム連携7つの実務影響で扱いました。

もう一つの背景が権限管理です。企業管理型の認可が安定版になり、事務所の管理者側でAIから触れる範囲を一元的に制御する道筋ができました。この論点はMCPの企業管理型認可が安定版に事務所のAI権限を一元管理する7手順で詳しく整理しています。自作サーバーは、この権限設計の中に自分たちの手で置ける点が既製品との一番の違いになります。

逆に言えば、自作は事務所が設計責任を引き受けるということでもあります。外部ベンダーのサーバーであれば審査項目を並べて可否を判断すれば済みますが（外部MCPサーバーの安全性をどう審査するか士業事務所の導入基準7項目）、自作では審査される側の設計をこちらが書くことになります。どこまでを読み取り専用にするか、誰の資格で認証するか、ログをどこに残すか。この3点を決めずに動くコードだけ先に作ると、後から事務所規程に載せられなくなります。

案件台帳をAIから読ませる自作MCPサーバー7工程

ここからは、所員10人規模の事務所が案件管理台帳と書式ライブラリを対象にサーバーを1本立てる想定で、工程を追います。数値は本記事が置いた前提であり、根拠は各工程の説明のとおりです。有資格者の判断が要る部分は工程の中に明示します。

第1工程は対象データの棚卸しです。事務所内のデータを、顧問先を特定できるもの、特定できないもの、公開情報の3つに仕分けます。この仕分けが後の権限設計とそのまま対応するため、いきなりコードから入らずここに半日かけます。仕分け結果は表ではなく一覧として文書に残し、担当者と更新日を書いておきます。

第2工程は公開する機能の決定です。MCPではリソース、ツール、プロンプトの3種類を公開できます（出典: Model Context Protocol「Build an MCP server」）。最初の1本では、読み取り専用のリソースと、検索を担う1個か2個のツールに絞る作り方が扱いやすくなります。書き込み系のツールを最初から入れると、AIが台帳を更新できてしまい、誰が変更したのかの追跡が難しくなります。

第3工程は認証の設計です。事務所内のネットワークだけで動かすなら標準入出力による接続で足りますが、複数人が同時に使うなら通信経路を分ける構成に寄せることになります。ここで決めるのは、誰の資格で台帳にアクセスするかです。サーバーが事務所共通の管理者権限で全件読める作りにすると、担当外の顧問先データまでAIの手元に届きます。担当者ごとに見える範囲を分ける設計にしておくと、後の説明が楽になります。

第4工程は最小の実装です。公式SDKのチュートリアルは、2つのツールを持つ小さなサーバーを作る流れで書かれています（出典: Model Context Protocol「Build an MCP server」）。事務所版では、案件番号で1件を返すツールと、条件で候補を返すツールの2本から始める形が近いところです。返す情報は、氏名や住所を含めず、案件番号、種別、期限、担当者に絞っておくと、初期段階の情報漏れの幅を狭められます。

第5工程は出力の検証です。AIに台帳を読ませると、存在しない案件番号や、実際とずれた期限を混ぜて返すことがあります。ここで有資格者が確認する工程を入れます。具体的には、AIの回答に案件番号を必須項目として含めさせ、担当者が原本の台帳と突き合わせてから外部に出す運用にします。突き合わせをしない出力は事務所の内部メモまでにとどめる、という線引きを先に決めておきます。

第6工程はログの設計です。どのアカウントが、いつ、どの案件を読んだかをサーバー側で記録します。監査ログの考え方は記帳を担うAIエージェントの権限をどう分けるか会計事務所の内部統制7設計で扱った内部統制の設計と重なります。ログの保存先を事務所の管理下に置くこと、保存期間を規程に書くことの2点を先に決めます。

第7工程は運用への引き渡しです。作った本人しか触れないサーバーは、その人が抜けた瞬間に止まります。設定ファイルの置き場所、再起動の手順、接続が切れたときの一次対応を1枚にまとめ、事務所内で共有します。

プロンプト例を2つ挙げます。1本目は、自作サーバー越しに案件の期限を洗い出させるものです。

あなたは当事務所の案件管理を補助するアシスタントです。
接続されているMCPサーバーの案件検索ツールを使い、次の条件で候補を出してください。

条件: 種別が「許認可更新」で、期限が今日から45日以内のもの
出力: 案件番号、種別、期限日、担当者名 の順で、期限が近い順に一覧
制約:
- ツールが返した値だけを使い、推測で補完しない
- 該当が0件のときは「該当なし」とだけ返す
- 案件番号は必ず原文のまま表示する（担当者が台帳と突き合わせるため）

2本目は、書式ライブラリを読ませて下書きを作らせるものです。

接続されているMCPサーバーの書式リソースから、種別「株主総会議事録」の
ひな形を読み込み、以下の架空事案に合わせて下書きを作ってください。

事案: 甲社（架空）が2026年10月に臨時株主総会を開催し、取締役1名を選任
出力: ひな形の構成を崩さず、変更した箇所を末尾に箇条書きで列挙
制約:
- ひな形に無い条項を新たに追加しない
- 日付・氏名は仮の値とし、[要確認]を付す
- 法的評価や適否の判断は書かない（有資格者が判断するため）

どちらのプロンプトも、AIの役割を検索と下書きに限定し、判断を人に残す構造にしています。この構造を崩さないことが、自作サーバーを事務所に置くうえでの基本線になります。

自作サーバーを置く前に決めておく守秘と権限の線

自作サーバーで最初に決めるのは、AIに渡した情報がベンダー側でどう扱われるかです。MCPサーバーは事務所内で動きますが、そこから読み出した内容はAI側に送られます。したがって、利用するAIサービスのデータ利用ポリシーを確認する作業が起点になります。法人向けプランで入力を学習に使わない設定になっているか、保存期間はどうか。この確認結果を、サーバーの設計書と同じ場所に残しておきます。

守秘義務の根拠条文は職種ごとに置かれています。弁護士は弁護士法第23条が秘密保持の権利と義務を定めています。税理士は税理士法第38条、公認会計士は公認会計士法第27条、社会保険労務士は社会保険労務士法第21条にそれぞれ秘密を守る義務の規定が置かれています。自作サーバーは、これらの条文が想定する情報を機械的に読み出す仕組みですから、設計段階で条文を横に置いて考える意味があります。

顧問先の個人データを外部のAIサービスに送る局面では、個人情報保護法第27条の第三者提供の制限が論点になります。同条第5項は、利用目的の達成に必要な範囲内で取扱いを委託する場合について定めており、委託構成をとるのか本人同意を得るのかで整理の仕方が変わります。個人情報保護委員会も生成AIサービスの利用について注意喚起を出しており（個人情報保護委員会）、事務所としての整理を先に持っておくことが実務上の分かれ目になります。

事務所規程に落とすなら、書く内容は4つに集約されます。第一に、自作サーバーが読み出せるデータの範囲。第二に、接続を許すAIサービスの名称とプラン。第三に、担当者ごとのアクセス範囲と、その変更手続。第四に、ログの保存先と保存期間、閲覧できる人です。ここを規程に書いておくと、顧問先から尋ねられたときに、口頭ではなく文書で答えられます。

顧問先への説明は、技術の説明ではなく範囲の説明にします。どの情報がAIに渡り、どの情報は渡らないのか。渡った情報が学習に使われない設定になっているか。最終的な判断を誰が行うか。この3点を1枚にまとめて示す事務所が出てきています。説明の場で技術用語を並べるほど不安を招くので、範囲と責任者を先に言い切る形が伝わります。

自作MCPサーバーでつまずいた3つの場面

1つ目は、権限の作り込みを後回しにした場面です。試作段階で管理者権限のまま全件を読める作りにし、そのまま数か月使い続けた結果、担当外の顧問先データが日常的にAIの入力に混ざっていた、という形です。回避策は単純で、試作の時点から読み取り範囲を担当者単位で絞ることです。後から絞るより、最初から狭く作って広げるほうが手戻りが小さくなります。

2つ目は、AIが台帳に存在しない値を返した場面です。案件番号の桁数が近いものを取り違え、期限日を1か月ずらして出力した、といった形です。ツールが返した値だけを使うようプロンプトで縛っても、この種のずれは残ります。回避策は工程5で触れた突き合わせで、外部に出る文書は原本と照合してから出す運用を規程に書いておくことです。

3つ目は、作った担当者が退職して誰も触れなくなった場面です。設定ファイルの場所も、再起動の手順も本人の頭の中にあり、接続が切れた日から事務所全体でAI活用が止まりました。回避策は工程7の引き渡し文書と、担当者以外の所員も手順を実行できる状態にしておくことです。自作は属人化と表裏一体なので、ここを外すと投資が消えます。

初期構築と運用にかかる費用・工数の見積もり方

費用は、AIサービスのライセンス費と、構築の人件費に分かれます。ライセンス費は各社の公開価格を見れば済みますが、構築工数は事務所ごとの差が大きいところです。見積もりの根拠として置ける前提は3つあります。対象データの本数、公開するツールの本数、認証を事務所内で閉じるか外部に開くかです。読み取り専用のツール2本、事務所内ネットワークで完結という最小構成なら、設計と実装より、第1工程のデータ棚卸しと第3工程の権限設計に時間が寄ります。

体制は、作る人と運用を持つ人を分けるのが扱いやすい形です。作るのは外部のエンジニアでも構いませんが、運用を持つのは事務所内の人にします。理由は、権限変更の判断が事務所の内部事情に依存するからです。担当替え、退職、顧問先の増減のたびにアクセス範囲を変えることになるので、この判断を外に出すと止まります。

投資判断は、削減できた時間ではなく、探す時間が消えたかで見るのが実感に近いところです。過去の類似案件を探す、書式の最新版がどれか確かめる、期限が近い案件を洗い出す。この3つが数分で終わるようになれば、自作サーバーは仕事をしています。効果測定の設計そのものはAI導入後の士業事務所で評価制度をどう組み直すかで扱った指標づくりと重なります。

自前の接続口を持つ事務所と持たない事務所の差

今後の論点は、事務所のデータをどこまで機械可読にしておくかです。MCPは接続の規格であって、つなぐ先のデータが整理されていなければ効きません。案件台帳が担当者ごとに別形式で存在している事務所では、サーバーを作る前にデータの形をそろえる作業が先に来ます。この地味な整備が、そのまま数年後の差になります。

もう一つは、既製サーバーとの住み分けです。会計ソフトやグループウェアは公式のサーバーが出そろいつつあり、そこを自作する意味は薄くなりました。自作が効くのは、ベンダーが提供しない事務所固有の資産、つまり過去案件の蓄積と書式ライブラリです。ここに接続口を持つかどうかが論点になります。

規制の面では、AIが業務システムに直接アクセスする構成が広がるほど、記録の残し方が問われます。誰の判断で何が動いたのかを後から再現できるかどうか。自作サーバーはログの設計を自分で決められる分、この問いに答えやすい構造でもあります。

よくある質問

自作MCPサーバーは、プログラミングができないと作れませんか

現状では、公式SDKを使ったコードの記述が前提になります。PythonとTypeScriptの公式SDKが2026年7月28日版の仕様に対応しており（出典: modelcontextprotocol/python-sdk）、生成AIにコードを書かせながら進める事務所もあります。ただし、権限設計とデータの棚卸しはコードの外の作業なので、そちらは事務所側で決めることになります。

既製のMCPサーバーと自作、どちらを先に入れるべきですか

既製で足りるなら既製が先です。会計ソフトやグループウェアのように公式サーバーがある領域を自作しても、保守の負担が増えるだけです。自作の出番は、公式サーバーが存在しない事務所固有のデータに限られます。

顧問先の同意はどの段階で取りますか

サーバーを作る前、対象データを決める第1工程の段階で整理しておく形が実務では扱いやすくなります。個人情報保護法第27条の第三者提供の制限が論点になるため、委託構成で整理するのか本人同意を得るのかを先に決め、その結論に合わせて読み出す範囲を設計する流れになります。

事務所内のネットワークだけで動かせば、守秘の論点は消えますか

サーバー自体が事務所内にあっても、読み出した内容はAIサービス側に送られるため、論点は残ります。確認する対象は、サーバーの設置場所ではなく、接続するAIサービスのデータ利用ポリシーです。

ログはどのくらい残せばよいですか

法令で一律に決まった期間があるわけではないため、事務所の規程で定める運用になります。関連する考え方として、監査の分野では監査ファイルの整理を監査報告書日から60日程度を超えない期限内に完了する扱いが示されています（出典: 日本公認会計士協会監査基準報告書230「監査調書」）。他士業でも、書類の保存期間に合わせて設計する例があります。

自作サーバーが返した内容を、そのまま顧問先に出してよいですか

出力は下書きとして扱い、有資格者が原本と突き合わせてから出す運用が広く採られています。AIが実在しない値を混ぜる場合があるため、案件番号や日付を原本と照合する工程を手順に組み込んでおくと、事故の芽を早く摘めます。

参考文献

※士業のチカラでは、生成AIの導入支援から運用最適化まで、貴事務所の業務に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://shigyonochikara.jp/contact/

本記事の作成体制について

本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、行政の見解は各府省庁の公表資料で、それぞれ確認したうえで記載しています。引用元は本文中および参考文献にすべて明示しています。

本記事には特定の資格者による監修は入っていません。個別の事案について法令の当てはめや手続の可否を判断する必要がある場合は、当該分野の有資格者にご相談ください。本記事は一般的な情報提供を目的としたものであり、個別具体的な法律判断・税務判断・労務判断を提供するものではありません。

記載内容に誤りを見つけられた場合は、お問い合わせよりご指摘ください。確認のうえ速やかに訂正し、訂正履歴を記事内に残します。編集方針の詳細は運営者情報をご覧ください。