なぜアプリにもIDが必要？ ─ はじめてのM365アプリ登録
OutlookとTeamsを普段使うだけの一般ユーザーが、AIで作ったWebアプリをMicrosoft 365の実データへつなぐまでを、ID、API、Microsoft Graph、トークン、権限、申請、認証の順にゼロから理解する。
なぜアプリにもIDが必要？
普段、Outlookでメールを読み、Teamsでチャットしているだけなら、Application IDを意識することはありません。ところがAIとライブコーディングしてWebアプリを作り、会社の実データへつなごうとした瞬間に、Application IDを求められます。なぜ自分のIDではだめなのか。今日はそこから始めます。
解説する人：胡田 昌彦
解説する胡田昌彦です。Microsoft MVPを14年連続で受賞し、Windows、Azure、Microsoft 365、生成AIを実機で検証してきました。この資料では管理者向けの難しい言葉を、普段Microsoft 365を使う人の目線へ翻訳します。
AIと一緒にWebアプリを作った
想定する主人公は開発者ではありません。AIへ会話で頼み、メール整理やSharePoint文書の要約を行うWebアプリを作れた人です。サンプルデータでは動きました。次は本物のMicrosoft 365データへつなぎたい、という場面です。
実データの直前で止まる
接続方法をAIへ聞くと、Microsoft Entra IDでアプリ登録し、Application client IDを設定してくださいと言われます。情シスへ相談すると、一般ユーザーには登録権限を付けていないと言われました。ここから未知の言葉を一つずつ説明します。
あなたは、すでにIDを使っている
OutlookやTeamsを開く前に、会社のアカウントと多要素認証などでサインインしています。これが人間としてのIDです。Microsoft 365はそのIDを見て、あなたが誰で何を利用できるかを判断します。普段はアプリが隠しているので意識しないだけです。
Outlookも、Microsoftが先にアプリ登録済み
Outlook、Teams、SharePointなどMicrosoft純正アプリも例外ではありません。Microsoftが自社のテナントでアプリ登録し、Application IDを持たせています。各顧客テナントには利用や同意に応じてService principal、管理画面でいうEnterprise applicationが作られます。顧客テナントの作成直後からMicrosoftの全アプリが並ぶという意味ではありません。
会社のデータは、誰にでも渡せない
会社のメール、ファイル、チャットは、誰にでも渡せるものではありません。だからMicrosoft 365は、データを利用させる前に「あなたは誰ですか」と確認します。その人が誰かを確かめるためにIDが必要です。まずはこの一点だけ押さえます。
自分のIDをアプリに貸せばいい？
アプリへ人間のパスワードを保存するのは避けます。漏えい時に人間のアカウントごと奪われ、アプリ単位の権限制御や停止も難しくなります。人とアプリは別々に識別します。
人のIDと、アプリのID
人間のIDは誰が使っているかを示します。Application IDはどのソフトウェアが接続しているかを示します。人がWebアプリへサインインすると、どの人がどのアプリを使うのかを区別できます。
アプリ登録は「アプリの身元届」
アプリ登録では、名前、対象組織、応答先URLなどの識別・サインイン設定を登録し、通常は利用したいAPIと操作も設定します。Delegated権限には実行時に段階的に要求できるものもありますが、情シスへ申請するときは必要なAPI権限を先に明示します。Application権限は事前設定が必要です。ソースコードはEntra IDへアップロードしません。APIは次で説明します。
クリックの裏では、アプリがAPIへ依頼
人がOutlookの画面をクリックすると、Outlookなどのアプリが裏側でサービスへ機械向けの依頼を送り、返った結果を人間に分かる画面へ表示します。このプログラム向けの受付窓口と依頼のルールがAPIです。ここでは特定の製品が必ず公開Microsoft Graphを内部利用する、とまでは断定せず、一般的な仕組みを示しています。
M365は、1つの製品ではない
Microsoft 365にはメール、ファイル、サイト、チャット、ユーザー管理など複数のサービスがあります。人は画面から利用し、アプリはサービスのAPIから操作します。歴史的にはサービスごとのAPIが中心でした。
そこで、共通入口のMicrosoft Graphへ
Microsoftは後から、Microsoft 365やEntra IDなどの多くのデータへ統一されたプログラミングモデルでアクセスできるMicrosoft Graphを中心に据えました。ただし完全な一本化ではなく、現在も一部の機能や管理操作には個別APIや専用の管理手段が残ります。
Webアプリからメールを読むまで
利用者がWebアプリを開いてMicrosoftでサインインします。Microsoft Entra IDが人とアプリを確認し、許可された範囲を示す期限付き通行証、アクセストークンを発行します。WebアプリはEntra IDから受け取ったトークンを添えてMicrosoft Graphへ依頼し、許可された場合だけデータが返ります。
パスワードではなく「期限付き通行証」
アクセストークンは保護されたAPIを呼ぶためのセキュリティトークンです。APIはその情報を検証して要求を受け付けるか判断します。トークンも機密情報なので、認証ライブラリを使って安全に扱います。
Access Tokenには、大きく2つの道
アクセストークンを使う場面には、人がサインインしてアプリが代理で動くユーザー委任と、人がいないところでアプリ自身が動くアプリ単独という大きな二つの道があります。次の二枚で順番に見ます。
人が操作するなら「ユーザー委任」
利用者がサインインしてボタンを押すWebアプリなら、まずDelegated、ユーザー委任を検討します。実際の到達範囲は、アプリへ同意された権限と利用者自身の権限の両方を満たす部分です。
人がいないなら「アプリ単独」
深夜の定期処理のように誰もサインインしていない場合はApplication-onlyです。アプリ自身のIDで動き、Application permissionを使います。Application permissionはすべて管理者同意が必要です。権限によってはテナント内の広いデータへ到達するため、認証方法・監視・停止方法まで設計します。
IDだけがあっても、何もできない
IDは誰かを区別するだけです。メールを読む、送る、ファイルを読むなど、何をしてよいかを決めるPermissionが別に必要です。最小限の権限だけを選びます。
「希望」と「許可」は別
アプリ設定へ権限を追加するのは要求を登録した段階で、許可とは別です。ユーザー同意の可否は組織ポリシーで決まり、Application permissionや多くの高権限Delegated permissionは管理者同意が必要です。
アプリを自分で登録できる組織／できない組織
組織によって一般ユーザーがアプリ登録できるかが違います。登録できるなら自分で作成し、必要な権限だけ管理者へ同意を依頼します。登録できないなら、用途、URL、API、権限を伝えて情シスへ作成を依頼します。登録可否と同意可否は別の設定です。
情シスに作ってもらうなら、運用権限も依頼
情シスに作成してもらう場合は、アプリ登録だけでなく、その後の運用方法を決めます。自分で設定を管理する必要があるなら、App registrationのApplication objectと、必要に応じてEnterprise applicationのService principalのOwnerへ追加してもらいます。組織方針でOwnerにできない場合は、情シス側の更新窓口を決めます。
認証情報は「シークレットを配る」で済ませない
Azure App ServiceなどManaged Identityを使える環境ではManaged Identityを第一候補にします。外部の信頼できるID基盤と連携できる場合はWorkload identity federationも、保存するアプリ資格情報をなくせます。それらが使えない本番環境では証明書を使い、秘密鍵をKey Vaultなどで保護します。Client Secretは開発・試験に限定し、本番では避けます。Managed IdentityへMicrosoft GraphのApplication権限を付与する場合は、そのService principalへ管理者が必要なapp roleを割り当てます。
情シスが守りたいもの
情シスは、アプリ、利用者、対象データ、読み書き、認証方法、責任者、停止方法を確認します。アプリ登録とEnterprise applicationを管理することで、アプリ単位に確認、記録、停止できます。
情シスには、こう説明する
AIで作った社内Webアプリで、サインインした本人が選んだSharePoint文書を要約したい。Delegatedを希望し、読み取りだけ。検証利用者は5名。具体的なGraph権限名と最大到達範囲を確認したい。実行URL、責任者、停止方法、動かす場所、希望する認証方法も伝えます。
Application IDは「アプリを区別するため」
人のIDは人間を、Application IDはソフトウェアを識別します。APIはアプリ向けの受付窓口、Microsoft Graphは多くのMicrosoft 365サービスへつながる共通受付です。ID、権限、同意、認証情報を分けて管理します。
覚えるのは、この3つ
本編の最後です。覚えることは三つです。人とアプリは別々のIDで確認する。APIへはMicrosoft Entra IDから発行されたアクセストークンを添えて依頼する。必要最小限の権限だけを選び、必要な人に同意してもらう。ここで解説本編はおしまいです。次のスライドはEbi Studyの案内です。
体系的に、順番に学びたい方へ
続けて体系的に学びたい方向けに、Ebi StudyでMicrosoft資格、Windows Server、Azure、Claude Codeの動画講座を提供しています。月額990円です。詳しくはebistudy.netをご覧ください。
Microsoft公式ドキュメント
ID、Microsoft純正アプリ、Microsoft Graph、アクセストークン、権限と同意に関する一次資料です。
申請・運用・認証の根拠
アプリ登録権限の委任、Enterprise applicationのOwner、Managed Identity、証明書、Client Secret、Microsoft Graph権限に関する一次資料です。実際のテナント設定は申請時に最新文書で確認してください。
ご視聴ありがとうございました！
最後までご視聴いただき、ありがとうございました。役に立ったら高評価とチャンネル登録をお願いします。これからもWindows、Azure、Microsoft 365、生成AIなどの難しいテーマを分かりやすく解説していきます。