認証は「それが誰かを確かめること」、権限は「その人に何をしてよいか決めること」。AIが外に出て動くときに不可欠な設計です。

この記事でわかること

• 認証（「誰か」の確認）と権限（「何をしていいか」の制御）の違い
• 「読み取り」と「書き込み」ではリスクの重さがまったく違う理由
• 実務での「確認フロー」の入れ方

AIが外部ツールとつながれるようになると、急に現実味を帯びてくる問いがあります。

「このAI、どこまで触っていいの？」「見るだけならいいけど、書き込みはさせていいの？」「そもそも、誰の権限で動いているの？」「接続できるのは分かったけど、安全なの？」

この違和感は正しいです。MCPの話をすると、つい「つながる便利さ」に目が行きます。でもつながるということは、AIが外の世界に触れられるということです。社内文書を読む、カレンダーを見る、チケットを作る、データを更新する、メッセージを送る。こういうことができるようになる可能性がある。

だからMCPの次に必ず必要になるのが認証と権限の話です。最初にひとことで言うと、認証は「それが誰かを確かめること」、権限は「その人に何をしてよいか決めること」です。

認証は「入口」、権限は「柵」

認証という言葉は少し堅いですが、やっていることは日常的です。ログインする、社員アカウントで入る、パスワードを確認する、2段階認証を通る。こういうものは全部広い意味で認証です。つまり認証は「そのアクセスをしているのが本当にその人かを確かめること」です。

AIが外部ツールにつながるときにも、その先のシステムは「あなたは誰ですか？」を確認したい。相手が誰か分からないまま文書もカレンダーもDBも触らせるわけにはいかないからです。

でも「誰か」が分かっても、それだけでは足りません。社員であること、ログインできることと、人事情報を全部見られること、経理システムを書き換えられること、全社一斉メールを送れることは同じではありません。「誰かが分かること」と「何をしていいかが決まること」は別です。ここで出てくるのが権限です。

権限は「この人はどこまでやっていいか」を決めること。このフォルダは読める、このデータベースは見られる、このチケットは作れる、でも削除はできない、このカレンダーは参照だけ。認証が「あなたは誰か」の話だとすれば、権限は「そのあなたに何を許すか」の話です。

感覚的に覚えるなら、認証は「入口」、権限は「柵」です。入口でその人が誰かを確認する。そのあと、どこまで入ってよいか、どこを触ってよいかを柵で区切る。

読み取り権限と書き込み権限は、重さがまったく違う

AIに何かをさせるとき、よく一括で「アクセスできる」と言ってしまいがちです。でも実際にはアクセスの中身が違います。

特に大きいのが「読むだけ」と「書く・変える」の違いです。社内FAQを読む、ドキュメントを検索する、カレンダーを参照する。これは比較的「読み取り」です。一方でチケットを作る、予定を入れる、レコードを更新する、メッセージを送る。これは「書き込み」や「実行」に近い。

読むだけなら多少の誤りがあっても影響が限定されることがある。でも書き込みや実行は、現実の状態を変えてしまう。だからAIに何かを接続するときは、まず「読ませるだけなのか、行動までさせるのか」を分けて考えた方がいいです。

便利なAIほど「勝手にやってしまう怖さ」が出てきます。普通のソフトウェアならボタンを押すのはたいてい人間です。でもAIは依頼を受けると「じゃあ必要そうな手順を進めますね」という振る舞いに近づいていく。本人は読むだけのつもりだったのにAIは「必要だと思って」作成まで進めた、ということも起こりうる。だからAIに権限を考えるときは「この人はアクセスできます」だけでは足りません。AIに何を「自動で進めてよいか」まで含めて考える必要があります。

権限設計で大事なのは「全部できる」より「必要なものだけできる」です。AIが便利だからといって最初から広く権限を渡すのは危険です。まずは検索だけ、まずは閲覧だけ、まずはドラフト作成まで、本送信や更新は人の確認後。こういう段階分けです。AI活用で問題が起きるときは、多くの場合、能力不足よりも「許しすぎ」が原因です。

「確認フロー」をどこに入れるかが実務では重要

AIに権限を考えるとき重要なのが、人の確認をどこに入れるかです。

認証と権限だけでは「この人はここまでできる」までは決められても、「本当に今その操作をしてよいか」までは決まりきらないことがあります。

これはAIに全部任せるか全部任せないかではなく、どこで人が握るかを決める話です。

OAuthのような仕組みが出てくるのも、「パスワード共有」で済ませないためです。AIや外部アプリが他のサービスにつながるとき、単純にIDとパスワードをそのまま渡すのでは危ない。OAuthは「本人のパスワードをそのまま渡さずに、許可した範囲だけ使わせるための仕組み」くらいの理解で十分です。

権限と認証が分かると、「AIに何をさせていいか」の会話がしやすくなる

ここまでの話をシンプルにまとめます。

AIの権限問題は「AIを信じるか」ではなく「どこまで任せる設計にするか」です。読み取りだけ許すのか、下書きまで許すのか、作成まではよいのか、本送信・本更新は人が握るのか。ここを分ける。

つまり権限と認証の話は「危ないからやめよう」という話ではありません。安全に使うために、境界を設計しようという話です。

権限レベルの段階を比較する

よくある疑問

AIの権限設計は難しいですか？

考え方は人のアクセス権設計と同じです。「最初は読み取り専用から」を原則にすれば、段階的に広げられます。

OAuthとは何ですか？

「本人のパスワードをそのまま渡さずに、許可した範囲だけ使わせるための仕組み」くらいの理解で十分です。AIや外部アプリが他のサービスにつながるときによく使われます。

「確認フロー」を入れれば安全ですか？

大きくリスクを下げられます。ただし確認を省略する運用が定着してしまうと意味がなくなるので、運用ルールもセットで設計する必要があります。

まとめ

• 認証は「誰か」の確認、権限は「何をしていいか」の制御。人のアクセス権設計と同じ発想が使える
• 「読み取り」と「書き込み」ではリスクがまったく違う。導入初期は「読み取り専用」から始めるのが安全
• 権限と認証が分かると、AI活用の会話が「便利そう／怖そう」から「どこまで任せる設計にするか」へ進む

次回の記事は「Skillsとは何か」です。今回の記事では、認証は「誰かを確かめること」、権限は「何をしていいかを決めること」であり、AIが外に出て動くための境界設計であることを説明しました。次回は、AIに再利用できる「仕事の型」を持たせるSkillsについて取り上げます。