MCPで社内ツールをAIに繋ぐ—COOに実務権限を渡す設計

🔌なぜ「会話できるAI」だけでは足りなかったか

相談役どまりのAIでは、一人会社の実務は止まる。手を動かす担当がいないから、AI自身が道具に触れる必要があった。

最初は、状況をAIに貼り付けて相談し、返ってきた手順を人間が手で実行していました。これはこれで、そこそこ速い。

でも一人会社には、その「手で実行する」担当がいません。社長は副業で、日中はほとんど動けない。だからAIが自分でPRの状態を見て、DBのテーブルを覗き、ドキュメントに追記するところまで届かないと、タスクは私の手元で止まってしまう。相談できるだけでは、足りなかったんです。

MCPを入れた動機は、拍子抜けするほど単純でした。――「口だけでなく、手を持たせる」。GitHubを繋げばIssueやPRを読んで書ける。Supabaseを繋げばスキーマやログを直接見られる。Notionを繋げば議事録やナレッジに触れられる。会話の外にある一次情報へ、AI自身が手を伸ばせる状態を、まず作りたかった。

🧩実際に繋いだツールと、最初に引いた線

繋ぐこと自体は難しくない。難所は「どこまで触らせるか」で、当社は操作を可逆性で分けて線を引いた。

当社が繋いでいるのは、コードのGitHub、データベースのSupabase、社内ドキュメントのNotion。それにGoogleカレンダーやドライブといった周辺です。

繋ぐこと自体は、正直むずかしくありません。手こずったのは、その先でした。――「どこまで触らせるか」。

当社は、触れる操作を可逆性で分けています。読むだけ、元に戻せる変更、軽いデプロイ。こういう可逆な作業は、AIが即実行してよい。

逆に、金銭が動く。法的な拘束が生まれる。権限やシークレット、監視、DNSのような「自分で自分を締め出しかねない」操作。ここは必ず、人間の事前承認を挟む。

この基準自体は、MCPを入れる前から運用ルールとして持っていました。でも机上のルールが、AIに手を渡した瞬間から、毎日効いてくる制約に変わった。読める範囲と書ける範囲を意図的にずらす——その当たり前の作業が、ここで初めて実務の重みを持ちました。

⚠️踏んだ落とし穴—同じMCPでもsurfaceごとにscopeが違う

同じMCPでも動く文脈（surface）ごとにscopeが違う。対話で動いた経路が定期実行では届かず、静かに取りこぼした。

一番手こずったのは、これです。――「繋いだはずのツールが、ある場面では見えて、別の場面では見えない」。

同じMCPサーバを設定しているのに、動く文脈（surface）によって、使えるスコープが違ったのです。

当社の環境では、Webのチャット、リモートで対話的に動かすコード実行、そして定期実行される自動タスク（Routine）。この三つで、MCPの届く範囲がそれぞれ違いました。対話的なコード実行では組織をまたいだ読み取りができるのに、定期実行のRoutineからは、登録したチップの範囲しか見えない。

この差を知らずに、「対話で動いたんだから定期実行でも動くはず」と組んでしまった。結果、無言で取りこぼしました。エラーすら出ないので、しばらく気づけなかった。動く文脈が変われば権限の地図も変わる——頭では分かっていたのに、実際に穴へ落ちるまで体感できなかった部分です。

この教訓から、当社はルールを一つ増やしました。「対話で動いた経路を自動実行に載せる前に、小さく一度、実測する」。仮説の経路を、そのまま本番の定期タスクに載せない。面倒でも一度、最小のスケールで通るか確かめてから広げます。

🔀cross-org readはGitHub Actionsへの移植で解決した

権限が足りない場所で戦わない。組織横断の読み取りは、必要なscopeを最初から持つGitHub Actionsへ処理ごと移して解いた。

残ったのは、組織をまたいだ読み取り（cross-org read）を、定期実行から行いたいという要件でした。

当社は、自社ドキュメントのリポジトリと、受託・OSSのリポジトリが別の組織に分かれています。毎朝の状況把握を自動化するには、複数の組織を横断して読む必要がある。ところが前述のとおり、定期実行のsurfaceからは、そのスコープが届かない。

選んだ解き方は、意外なほど素直でした。――その横断読み取りを担うタスクだけを、GitHub Actionsへ移す。読み取り専用のトークンをActions側のシークレットに置き、ワークフローとして定期実行する。

MCPのsurfaceに無理やり権限を足すのではなく、必要なスコープを最初から持っている実行環境へ、処理そのものを引っ越したわけです。結果として、cross-org readが必要な当社の定期タスクは、この経路に移して安定しました。

「権限が足りない場所で戦わず、権限が足りている場所へ処理を動かす」。このときの判断を一言にすると、そうなります。GitHub Actionsの仕組みは公式ドキュメントにまとまっています。

🧭一人会社が権限を渡すときの実務的な線引き

指針は三つ。可逆性で線を引く／surfaceごとにscopeが違う前提で組む／届かない要件は処理を動かす。

ここまでの経験を、実務の指針として三つに絞ります。

ひとつ目。可逆性で線を引く。元に戻せる操作は任せ、自分を締め出しかねない操作は人間に返す。技術的に重いかどうかではなく、戻せるかどうかで判断する。これだけで、迷いがぐっと減りました。

ふたつ目。surfaceごとにスコープが違う前提で設計する。同じMCPでも動く文脈で見える範囲が変わるので、「対話で動いた」を「どこでも動く」と読み替えない。自動実行に載せる前に、一度実測する癖をつけました。

みっつ目。権限が足りない場所で無理をしない。cross-org readのように届かない要件は、権限を後付けするより、必要なスコープを持つ実行環境へ処理を移すほうが素直でした。MCPは万能の鍵ではなく、実行文脈ごとに形の違う鍵束——そう捉えると、設計がぶれません。

✅まとめ—手を渡すからこそ、線を先に引く

手を渡すことは権限を渡すこと。だから、どこまで触らせるかの線を先に引く――それが事故を防ぐ運用の作法だった。

MCPでAIに社内ツールを繋ぐと、実務は確かに前に進みます。

一方で、手を渡すというのは、権限を渡すことでもある。どこまで触らせるかを先に決めておかないと、静かに事故が起きます。

当社は可逆性で線を引き、surfaceごとにスコープが違う前提で組み、届かない要件はGitHub Actionsへ移して解いてきました。仕様のプロトコル面は、MCPの公式サイトやAnthropicのドキュメントが整理してくれています。

技術の外側で効いてくるのは、結局のところ「渡す前に、線を引く」という運用の作法でした。同じように一人会社でAIに実務を任せようとしている人の、設計のヒントになればうれしいです。