MCPの監査ログとは、AIがどのツールをどの権限で呼んだかを追える記録のことです。

MCP（Model Context Protocol）の仕様に、監査ログという名前の標準機構は置かれていません。2026-07-28版では、むしろ従来の Logging 機能が非推奨になり、構造化された可観測性はOpenTelemetryに委ねる整理が示されました（Model Context Protocol Blog 2026-07-28リリース候補）。本記事は、士業事務所がAI利用の証跡をどこで取るかを扱います。士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、行政の見解は各府省庁の公表資料で確認しています。

2026-07-28版のMCPで証跡の置き場所がどう動いたか

結論から書くと、証跡はプロトコルの内側から外側へ移りました。2026-07-28版はローンチ以来で最大の改定とされ、ステートレスなコア、Extensionsフレームワーク、Tasks、MCP Apps、認可の強化、正式な非推奨ポリシーが同時に入っています（出典: MCP公式ブログ）。リリース候補が固まったのが2026年5月21日、最終仕様の公開は2026年7月28日と告知されました。

士業の証跡設計にとって最も重い変更は、セッションの廃止です。initialize と initialized のハンドシェイクが削除され（SEP-2575）、Mcp-Session-Id ヘッダーとそれに伴うプロトコルレベルのセッションも削除されました（SEP-2567）（出典: MCP公式ブログ）。セッションIDで一連の操作をひとまとめに追う設計は、この版から前提が崩れます。どのリクエストもどのサーバーインスタンスにも着地しうるため、証跡は自分で相関キーを持たせて取る形になります。

その相関キーの標準が W3C Trace Context です。_meta での Trace Context 伝播が文書化され、traceparent、tracestate、baggage のキー名が仕様上で固定されました（SEP-414）。これにより、ホストアプリケーションで始まったトレースが、クライアントSDK、MCPサーバー、その先の呼び出しまで追随し、OpenTelemetry互換のバックエンドで一つのスパンツリーとして表示されると説明されています（出典: MCP公式ブログ）。

そして Logging です。Roots、Sampling、Logging の3つのコア機能が新しいフィーチャーライフサイクルポリシーの下で非推奨になりました（SEP-2577）。Logging の代替として示されているのは、stdio トランスポートでは stderr、構造化された可観測性では OpenTelemetry です（出典: MCP公式ブログ）。これらは注釈のみの非推奨で、メソッド・型・ケーパビリティフラグはこの版でも、この版の公開から1年以内に公開されるすべての仕様版でも動き続けるとされています。フィーチャーライフサイクルポリシーは、非推奨から最短の削除までに少なくとも12か月を置くと定めています。

運用の入口が増えた点も押さえておきます。Streamable HTTP トランスポートは Mcp-Method と Mcp-Name ヘッダーを必須とし（SEP-2243）、ロードバランサーやゲートウェイ、レート制限がボディを覗かずに操作単位でルーティングできるようになりました（出典: MCP公式ブログ）。ヘッダーとボディが食い違うリクエストはサーバーが拒否します。事務所の側から見ると、これはどのツールが何回呼ばれたかをネットワーク層で数えられるという意味です。証跡の一次データを、アプリケーションを触らずに取れる余地が生まれました。

MCP Apps では、サーバーがサンドボックス化されたiframeでレンダリングされるインタラクティブなHTMLインターフェースを提供できます（SEP-1865）。ここで重要なのは、レンダリングされたUIがホストと同じJSON-RPC基底プロトコルで通信するため、UI起点のあらゆる操作が直接のツール呼び出しと同じ監査・同意の経路を通ると説明されている点です（出典: MCP公式ブログ）。画面から押したボタンも、証跡上はツール呼び出しとして扱えます。

認可の強化を証跡設計にどう結ぶか 7つの確認と実装ステップ

MCPの認可仕様は OAuth 2.1 を土台にしています。認可自体は実装にとって任意ですが、HTTPベースのトランスポートを使う実装はこの仕様に適合することが望ましいとされ、STDIOトランスポートを使う実装はこの仕様に従わず環境から資格情報を取得することが望ましいと書かれています（出典: MCP Authorization仕様）。

第1に、事務所が使うMCPサーバーの接続方式を棚卸しします。ローカルのstdio接続なのか、リモートのHTTP接続なのかで、証跡の取り方が根本的に変わります。stdio なら証跡はローカル端末側、HTTP なら認可サーバーとゲートウェイ側が主戦場です。この切り分けをせずにログ設計を始めると、取るべき場所を外します。MCPサーバーの構築手順そのものは士業事務所のMCPサーバー構築手順｜顧客管理と会計連携の7工程にまとめています。

第2に、トークンの宛先検証を確認します。MCPサーバーはOAuth 2.1のリソースサーバーとして、アクセストークンが自分自身を意図した対象として発行されたものかを検証することが求められ、他の宛先のトークンを受け付けたり中継したりしてはならないと規定されています（出典: MCP Authorization仕様）。証跡の観点では、どの資格情報でその操作が行われたかを後から言えるかどうかが、ここで決まります。

第3に、iss 検証の有無を見ます。クライアントは認可応答の iss を RFC 9207 に従って検証することが求められ、認可サーバーが authorization_response_iss_parameter_supported を true としているのに iss が無い応答は拒否する、という判定表が仕様に載っています（出典: MCP Authorization仕様）。将来の版で認可サーバー側の iss 付与が SHOULD から MUST に格上げされる見込みとも書かれています。

第4に、スコープの最小化を運用に落とします。仕様は最小権限の原則に沿ってスコープを要求することを推奨し、WWW-Authenticate ヘッダーに scope を含めることでクライアントに必要なスコープを示す方式を示しています。実行時にスコープが足りない場合は HTTP 403 と error="insufficient_scope" を返し、その操作に必要なスコープを1回のチャレンジでまとめて示すことが望ましいとされています（出典: MCP Authorization仕様）。段階的に1つずつ返すと認可の往復が増えて体験を損なう、という注記まで入っています。

事務所の権限設計をこの枠に合わせるためのプロンプト例を挙げます。

あなたはアクセス制御の設計に詳しいアナリストです。
以下の業務フローについて、MCPサーバーに与えるスコープを最小権限の観点で設計してください。

【業務フロー】
（ここに事務所の業務を貼る。顧客名・個人情報は伏字にする）

【出力条件】
- スコープ名の案、その操作で読み書きする対象、なぜその粒度が要るかを1行ずつ書く
- 「読み取りだけで足りる操作」と「書き込みが要る操作」を分けて並べる
- 過剰な権限になりうる箇所には「要検討」と印を付ける
- 法令の当てはめや適法性の判断は書かない

第5に、Trace Context を実際に流します。traceparent を発行するのはホストアプリケーション側なので、事務所が使うAIクライアントがこれを出すかどうかを先に確かめます。出さないクライアントを使っている場合、MCPサーバー側でリクエスト単位のIDを採番して記録する代替設計に切り替えます。セッションが廃止された以上、この相関キーが唯一の追跡手段になります。

第6に、ログの保存先と保存期間を決めます。MCPの仕様はログの保存について何も定めていません。定めていないということは、事務所側で決める余地があるという意味でもあります。誰がいつどのツールを呼び、どの引数を渡し、何が返ったか。この4点セットを、案件の保存期間に合わせて保持する方針を規程に書きます。AIベンダー側が提供する監査APIを使う選択肢もあり、その動向はClaude監査APIがCoworkとCodeに拡大 士業の記録4論点で扱っています。

第7に、取った証跡を読む担当を決めます。取りっぱなしのログは証跡として機能しません。月次で異常な呼び出しパターンを目視する担当を置き、確認した事実を1行で残す運用が最小構成です。

証跡の棚卸しに使えるプロンプトも示します。

以下のログ設計について、抜けている項目を洗い出してください。

【現状のログ設計】
- 記録している項目: （列挙する）
- 保存先: （記載する）
- 保存期間: （記載する）
- 確認する人と頻度: （記載する）

【観点】
1. 誰が（利用者の識別）
2. いつ（タイムスタンプと時刻同期）
3. どのツールを（ツール名と引数）
4. どの権限で（スコープ・トークンの宛先）
5. 結果は何か（成否とエラー）
6. 一連の操作をどう束ねるか（相関ID）

【出力条件】
- 各観点について「あり」「なし」「不十分」を判定し、理由を1行で書く
- 不足箇所への追加案を、実装難易度が低い順に並べる
- 断定は避け、「〜という運用例があります」の形で書く

顧客情報をMCP経由で流すときの守秘義務と規程の3点

MCPは、AIに事務所の業務システムをつなぐ規格です。つないだ瞬間、AIは顧客データベースにも会計データにも手が届く位置に立ちます。ここで事務所として決めておく論点が3つあります。

1つ目は、職種ごとの守秘義務の根拠条文です。弁護士法第23条は、弁護士または弁護士であった者が職務上知り得た秘密を保持する権利を有し義務を負うと定めています。税理士法第38条は、税理士が正当な理由なく税理士業務に関して知り得た秘密を他に洩らしまたは窃用することを禁じ、税理士でなくなった後も同様と規定しています。社会保険労務士法第21条も同趣旨の規定を置いています。事務所のAI利用規程には、自分の職種の条番号を明記しておく運用が向いています。

2つ目は、個人データの取扱いです。個人情報の保護に関する法律第27条は第三者提供の制限を定め、同条第5項第1号は、利用目的の達成に必要な範囲内で個人データの取扱いの全部または一部を委託することに伴って提供される場合を第三者に当たらないものとしています。MCP経由でクラウドAIに顧客データが渡る構成が委託として整理できるかは、契約とデータの取扱い実態で変わる論点です。個人情報保護委員会の公表資料を確認したうえで文書化する運用が現実的です（参考: 個人情報保護委員会）。

3つ目は、証跡が守秘義務の履行を説明する材料になるという発想です。顧問先から自社の資料がAIにどう扱われたのかを問われたとき、答えられる状態を作っておくのが証跡の実用的な価値です。逆に言えば、ログを取っていない構成は、疑義が生じたときに何も示せません。MCPの仕様はセッションを廃した代わりに Trace Context を標準化したので、追跡の道具は用意されています。使うかどうかは事務所の設計次第です。

規程に落とすときの運用例を挙げます。MCP経由で接続してよい業務システムを列挙し、それ以外への接続を禁じる。書き込み権限を持つツールは、有資格者のアカウントからのみ実行できるようにする。ツール呼び出しのログを案件の保存期間と同じ期間保持し、月次で確認記録を残す。この3点を規程本文に置き、運用手順書で操作を示す構成です。階層別の権限設計は士業事務所のAI権限ルールを階層別に設計するで扱っています。

MCP証跡設計でつまずく3つの失敗と回避策

1つ目の失敗は、セッションIDでログを束ねる前提のまま設計してしまうことです。2026-07-28版で Mcp-Session-Id は削除されました（出典: MCP公式ブログ）。旧版のドキュメントや記事を参照して設計を始めると、この一点で作り直しになります。相関キーは Trace Context か、自前で採番するIDに寄せます。

2つ目の失敗は、MCPのLogging機能を証跡の本体に据えてしまうことです。Logging は非推奨になり、代替として stderr と OpenTelemetry が示されています（出典: MCP公式ブログ）。当面は動き続けますが、非推奨から削除までの間隔が最短12か月と定められている以上、新規に組む証跡の土台に選ぶのは筋が良くありません。

3つ目の失敗は、認可を設定しないままリモートMCPサーバーを立てることです。仕様上、認可は任意とされているため、設定しなくても動いてしまいます。動いてしまうからこそ、誰でも叩ける状態が放置されます。HTTPベースのトランスポートを使うなら認可仕様への適合が望ましいとされていること、そしてMCPサーバーは OAuth 2.0 Protected Resource Metadata（RFC 9728）の実装が求められることを、構築の要件表に書き込んでおく運用が安全側です（出典: MCP Authorization仕様）。セキュリティ認証の読み方はAIツール選定でセキュリティ認証をどう読むか 士業の9確認手順にまとめています。

証跡基盤にかかる工数と体制をどう見積もるか

事務所側の作業は、接続方式の棚卸し、スコープ設計、ログ項目の定義、保存基盤の用意、月次確認の運用化の5つに分解できます。生成AIが効くのはスコープ設計の素案とログ項目の抜け出しで、認可の実装と保存基盤の選定は技術担当が押さえる領域です。

工数の目安を置くなら、接続方式の棚卸しに3時間、スコープ設計に5時間、ログ項目の定義に3時間、保存基盤の用意に8時間、月次確認の手順化に2時間という配分が組めます（参考: 編集部が想定した試算例であり、実測値ではありません）。OpenTelemetry互換のバックエンドをマネージドサービスで用意する場合、月額は数千円から数万円の帯に収まる例が多い領域です（参考: 各サービスの公表価格）。

体制面では、ログを読む人を決めることが実質的な要になります。5人規模の事務所であれば、有資格者1名が月次で確認し、確認した事実を1行残す運用で足ります。10人を超える規模になると、書き込み権限を持つツールの一覧管理を別担当に分ける形が現実的です。投資対効果の測り方は士業事務所のAI費用対効果をどう測るか｜ROI測定の7手順で手順化しています。

標準が薄い領域こそ事務所の設計力が出る 今後の論点

MCPが監査ログを標準化していないことは、欠陥というより設計上の割り切りです。プロトコルはツール呼び出しの規格に徹し、可観測性は OpenTelemetry という既存の標準に寄せる。この分業は工学的には筋が通っています。ただし、士業事務所の側から見ると、証跡の設計責任が丸ごと自分に回ってきたということでもあります。

今後の論点は三つ考えられます（参考: MCP公式ブログ）。第一に、Extensions が正式な枠組みになったことで、監査や証跡を扱う拡張が第三者から出てくる余地が生まれました。拡張は逆引きDNSのIDで識別され、独自のリポジトリで維持され、仕様とは独立にバージョニングされます。第二に、Standards Track の SEP が適合性スイートに対応シナリオが入るまで Final に到達できなくなったため、仕様の実装差が縮む方向に動きます。第三に、ステートレス化で任意のインスタンスにリクエストが着地する以上、証跡の集約は分散トレーシングの問題として扱うのが自然になります。

いずれにせよ、AIが代替できるのはログ項目の洗い出しや設計の素案までです。何を証跡として残すかは、その事務所がどこまで説明責任を負うかの判断であり、有資格者の領域として残ります。

よくある質問

MCPの仕様に監査ログの規定はありますか

監査ログという名前の標準機構は置かれていません。2026-07-28版では従来のLogging機能が非推奨となり、代替としてstdioトランスポートではstderr、構造化された可観測性ではOpenTelemetryが示されています（出典: MCP公式ブログ）。

セッションIDが無くなると証跡はどう束ねますか

W3C Trace Contextを使う方法が仕様上の道筋です。_meta での伝播が文書化され、traceparent、tracestate、baggage のキー名が固定されたため、OpenTelemetry互換のバックエンドで一つのスパンツリーとして追えると説明されています（出典: MCP公式ブログ）。

MCPの認可はOAuth 2.1ですか

認可仕様はOAuth 2.1のIETFドラフトを土台とし、MCPサーバーはOAuth 2.1のリソースサーバー、MCPクライアントはOAuth 2.1のクライアントとして位置づけられています（出典: MCP Authorization仕様）。認可の実装自体は任意です。

非推奨になった機能はいつ使えなくなりますか

フィーチャーライフサイクルポリシーにより、非推奨から最短の削除までに少なくとも12か月が置かれます。削除には別途SEPが要るとされています（出典: MCP公式ブログ）。

最終仕様はいつ公開されますか

2026年7月28日に公開されると告知されています。リリース候補は2026年5月21日時点で固定されました（出典: MCP公式ブログ）。

ログには何を残せばよいですか

一般的には、利用者の識別、タイムスタンプ、ツール名と引数、スコープやトークンの宛先、実行結果、相関IDの6項目が候補になります。仕様が定めていない領域なので、案件の保存期間や顧問先への説明責任の水準に合わせて事務所が決める設計になります。

顧問先に証跡の有無をどう説明すればよいですか

何を記録し、どこに保存し、誰がいつ確認しているかを、事実として示す形が扱いやすくなります。守秘義務の根拠条文（たとえば税理士法第38条）と、記録の運用をセットで説明すると、話が具体になります。

参考文献

• Model Context Protocol Blog The 2026-07-28 MCP Specification Release Candidate
• Model Context Protocol Authorization Specification（draft）
• e-Gov法令検索 弁護士法
• e-Gov法令検索 税理士法
• e-Gov法令検索 社会保険労務士法
• e-Gov法令検索 個人情報の保護に関する法律

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