Claude Codeで行政データを分析する際の注意点、MCP導入で直面する認可設計の課題

デジタル庁が公開した行政手続きの棚卸データ75,071件をMCPで分析した。Claude Codeで読み込ませると、出生関連の手続き509件を瞬時に集計できた。

MCPを常駐させると環境に負荷がかかる。プロセスが13組立ち上がり、メモリ消費量は1.1GBを超えた。頻繁な認可ダイアログにより、操作の判断力が低下する事態も発生した。

AIエージェントの実用化には、ツール接続だけでなくリソース制限と認可UIの設計が関わる。直面した副作用と解決策をまとめた。

行政MCPの登場と現場で浮き彫りになった運用上の二大障害

デジタル庁は行政手続きの棚卸調査データ75,071件をAIエージェントで分析できるMCPサーバーを公開した。配布形式はMITライセンスだ。

このMCPは巨大なExcelデータを即座に集計する。国の法令上の手続きで「出生」に紐づくものは509件あり、オンライン化されていても利用件数が0件の手続きも可視化された。データはParquet形式へ変換され、元データから77.6%の軽量化が図られている。

しんたろー：
行政データがMCPで分析できる点は興味深い。一方で、開発環境でMCPを常駐させた際に別の問題に直面した。

開発現場では二つの副作用が浮き彫りになっている。

一つ目は、ローカル環境のメモリを圧迫するプロセス肥大化だ。

多くのMCPで採用されるstdio方式では、エージェント起動のたびにプロセスが立ち上がる。複数のAIエージェントを動かすと、バックグラウンドで同じツールのプロセスが13組重複起動した。このとき消費されたメモリは1.1GBを超え、開発用PCの動作に影響を与えた。

この問題に対し、共有サーバー経由のStreamable HTTP方式への切り替えや、プロファイル機能によるオンデマンド読み込み、Cloudflareの軽量ブラウザエンジン「Kitesurf」のような代替手法が検討されている。

二つ目は、AIのツール実行ごとに確認を求める認可疲れだ。

セキュリティ維持のため「ファイル読み込み」「解析」「書き出し」ごとにダイアログが表示される。短時間に大量の許可を求められると、ユーザーは文章を読まず反射的にOKを押すようになる。セキュリティ機能が形骸化する悪循環が生じている。

現在開発者の間では、プロセスの常駐を抑えるアーキテクチャや、目的単位で許可を束ねる認可設計が関心を集めている。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

あわせて読みたいAIエージェントを自作して本番運用する方法｜最小構成の実装とサブエージェント設計 →

MCP接続の裏に潜むリソース肥大化と認可疲弊のリアル

行政データのMCPを動かすと、データの裏にある現実が見える。

75,071件の行政手続きデータのうち、出生届の年間件数は約74万6千件だが、実際のオンライン申請件数は0件という乖離がある。

このデータと実態のギャップを対話で炙り出せるのがMCPの特性だ。しかし、開発者はふたつの壁に直面する。

ひとつはローカル環境のメモリ枯渇だ。

標準的なstdio方式では、エージェントごとにMCPサーバーが立ち上がる。Claude Codeを複数立ち上げて並行作業すると、バックグラウンドでブラウザプロセスが大量発生する。

プロセスが13組同時に走り、メモリ消費量が合計で1.1GiBを超えるケースもある。AIエージェントのツールを増やすと、開発環境の動作が重くなる。

ここでリソースの分離が求められる。すべてのツールを常時ロードせず、プロファイル指定や、1つのプロセスを共有するStreamable HTTP方式への切り替えが有効だ。重いブラウザをローカルで動かさず、外部の軽量なAPIベースのブラウザ処理へ逃がす手法も存在する。

しんたろー：
Claude Codeで並行作業中にPCのファンが回り始めた。原因を調べると裏でMCPのプロセスが大量に増殖していた。プロセス管理を怠るとローカル環境が先に潰れる。

もうひとつの問題が認可疲れだ。

「ファイルを開く」「データを解析する」「結果を書き出す」というステップごとに認可ダイアログが表示されると、集中力が削がれる。ダイアログが連続すると、人間は確認文言を読まず反射的に「許可」を押すようになる。

これを防ぐには、「ユーザーの意図単位」で認可を設計し直す必要がある。「行政データを集計する」という1つの目的として束ねて許可を求める手法だ。

低リスクな閲覧処理は控えめなUIでログを残し、高リスクなファイル書き換えだけを強く警告するような危険度に応じたUI分岐が求められる。

リソース消費を抑えるアーキテクチャの最適化と、ユーザーの判断力を削らない認可デザイン。このふたつを考慮しなければ、AIエージェントは実務で使いものにならない。

エージェント構築で見直すべき3つの実務指針

これからの開発では、リソース消費の最適化と認可UXの設計が必須になる。明日から意識すべき実務上の指針は3つのアプローチに整理できる。

ひとつ目は、MCPサーバーの常駐登録（グローバル設定）の見直しだ。

Claude Codeで使わないMCPまでグローバルに常駐させると、Agent起動のたびにプロセスが生成される。無駄なプロセスが蓄積してメモリを数百メガバイト単位で圧迫する原因になる。

対策として、特定のタスク時だけ読み込む設定プロファイル（profile）の分割を実施する。複数のAgentから同じツールを呼び出すなら、Streamable HTTP方式への移行が有効だ。

しんたろー：
Claude Codeで複数のTerminalを立ち上げるとMacが重くなった。原因は裏で残ったMCPのプロセスだった。ブラウザ操作系の設定を別ファイルに切り出すとメモリの持ちが改善した。

ふたつ目は、重い処理をローカルの実行環境から分離することだ。

Webブラウザの自動化をローカルのChromiumで動かすと、Agentの数だけインスタンスが立ち上がる。外部の軽量なブラウザ APIサービスを経由してクラウド上でレンダリングさせる構成が現実解だ。

みっつ目は、ユーザー向けエージェント開発における「意図単位」の認可UI設計だ。

「ファイル取得」「データ抽出」「画面表示」と3回の確認ダイアログを出す設計は、ユーザーを麻痺させる。「行政データを集計して結果を出力する」という1つの目的でまとめて確認を求める形へ改修する。

低リスクな処理は一括許可や履歴確認で済ませ、高リスクな処理だけを画面で強調するUI分岐を徹底する。開発者がリソース管理を最適化し、安全な認可設計を組み込んで初めて、AIエージェントは実務で耐えうるシステムになる。

あわせて読みたい【2026年版】AI活用1人SaaS開発の完全ロードマップ｜5ステップで始める個人開発 →

よくある質問

MCPサーバーを複数起動するとメモリが枯渇するのですが対処法はありますか？

Agentごとにstdio方式でサーバーを起動していることが原因だ。プロファイル機能を使い、必要なセッションでのみ接続を読み込む構成に改める。複数Agentで共有できるStreamable HTTP方式へ移行するのも効果的だ。ブラウザ操作などの重い処理は、Cloudflare Kitesurfなどの軽量なクラウドAPIに逃がすとメモリ消費を抑えられる。

AIエージェントの認可ダイアログが多すぎてユーザーが疲弊しています

認可疲れは、システムの内部処理をそのままダイアログとして突きつけていることが原因だ。解決策は処理をユーザーの意図単位でひとまとめにすることだ。危険度の低い処理は控えめなUIで一括許可し、外部送信などの高リスク処理のみ詳細理由を出すUIの段階分けを徹底する。

行政MCPのような大量データを扱う際、Token消費やAPI料金が高騰しませんか？

MCP側で事前処理していれば料金は跳ね上がらない。Claude Codeで試した際、データ自体をParquet形式で約3MBまで圧縮し、ローカルで検索処理を完結させた。LLMには抽出した必要最小限のテキストだけを渡す。全件データを直接AIに読ませず、MCPツールのローカルクエリで絞り込んでから渡すのがコスト削減の鉄則だ。

まとめ

行政MCPで75,000件のデータを分析する体験は有用だ。しかし、裏で動くプロセスのメモリ圧迫や、毎回ダイアログを叩く認可疲れは無視できない課題だ。

エージェントを動かすなら、プロセスの軽量化とユーザー視点のUI設計がセットだ。AIエージェントの「認可疲れ」を解消し、効率的なMCP運用を実現するための設計指針を、自身のプロダクト開発で意識する。

👉 ThreadPostでSNS運用を自動化する