ClaudeでSharePointドキュメントライブラリを自動タグ付けして整理する方法

結論から言うと： ClaudeはMicrosoft Graph APIを通じて文書を読み、人手より遥かに速くメタデータを提案できます。ただし先に列構成を決め、アプリ登録の権限はテナント全体ではなくSites.Selectedに絞り、そして「ライブラリを見つけやすくすることは、誰が実際に何を見つけるかを変える」ことを理解してください。タグ付けは簡単な方の半分です。

一定の年数を経たSharePointテナントには、必ず同じライブラリがあります。4万件のファイル、誰が設計したか誰も覚えていないフォルダー階層、「Proposal_v3_FINAL_updated(2).docx」のようなファイル名、そしてすべてを返すがゆえに何も返さない検索ボックス。メタデータ列は存在します——移行時に誰かが作りました——が中身は空です。入力はいつも「誰か他の人の仕事」だったからです。文書を読んで何であるかを推定できるAIは、まさに適した道具に見えますし、実際おおむねそのとおりです。以下は、労力を無駄にせず、かつ元々なかった問題を作り出さずにこれを行う方法です。

なぜSharePointライブラリは検索できなくなるのか

メタデータの代わりにフォルダーを使った。 SharePointはファイル共有のふりをしたデータベースですが、組織はファイル共有の側だけを使います。深いフォルダー階層は分類をひとつ——たいていはチーム別か年度別——しか符号化せず、それ以外のあらゆる問いに答えられなくします。

メタデータ列はあるが空。 任意入力の列は納期の前で必ず飛ばされます。入力率が20%になった時点で、その列での絞り込みは無意味を通り越して有害です。残りの80%を静かに隠すからです。

本当のメタデータはファイル名にある。 バージョン、顧客、ステータス、日付は、各チームが独自に考案し、適用も一貫しないファイル名規約の中に生きています。情報は確かに存在しています——ただ、問い合わせできないだけです。

ライブラリの持ち主がいない。 構造を作った人は異動しました。「このコンテンツタイプは何を意味するのか」を決める人がいないため、構造は硬直し、コンテンツだけが届き続けます。

検索そのものが犯人であることはまれです。Microsoft 365の検索はそれなりに優秀で、単に使えるものが何もないだけです。

Claudeがライブラリの内容を読み、分類し、タグ付けする仕組み

作業の形は素直です。ライブラリ内の文書を列挙し、各文書のテキストを取得し、分類スキームを説明したプロンプトとともにClaudeへ送り、構造化された値を受け取り、その値を項目のメタデータ列へレビュー用に書き込む。読解と判断——「これはSOWで、顧客区分はX、日付はY、より新しい版に置き換えられている」——をClaudeが担い、そこが人員では規模を出せない部分です。

出力が価値あるものになるかを決めるのは2点あり、どちらもモデルではありません。

自動化の前にメタデータ戦略を決める

タグを1つも生成する前に、そのライブラリに何を問いたいのかを決めてください。多くのライブラリに必要な列は、チームが提案する数より少なくて済みます。通常は文書種別、所管チームまたは事業領域、ステータス（下書き・有効・失効）、日付、そして該当する場合は顧客や案件の参照番号です。よく入力された5列は、いつでもまばらな15列に勝ります。

自由入力ではなくSharePoint自身の構造を使います。値が閉じているものは選択肢列にして表記を揃えます。分類がサイトを跨いで共有され中央で統制すべきなら、用語ストアの管理されたメタデータを使います。文書種別ごとに本当に異なる列が要るならコンテンツタイプを使います。そして各値の定義を文章で残してください——ある文書を「報告書」と呼ぶか「レビュー」と呼ぶかで人間2人の意見が割れるなら、モデルもまったく同じ箇所で揺れます。曖昧さはモデルではなくスキームの側にあるからです。

Graph APIアクセス、アプリ登録、最小権限の設計

SharePointへのプログラムからのアクセスはMicrosoft Graph API経由で行い、Microsoft Entra IDでのアプリ登録が必要です。ここは慎重に扱う価値があります。既定の経路は権限が広すぎるからです。

アプリケーション権限でSites.Read.Allを持つ登録は、テナント内のすべてのSharePointサイトを読めます。タグ付けの案件でそれが必要になることはまずありません。Sites.Selectedはまさにこのために存在します。アプリは既定でサイトへのアクセスを持たず、管理者がサイトコレクション単位で明示的に付与します。ここから始め、パイロット対象のサイトだけを許可し、意図をもって広げてください。

アプリケーション権限がパイプラインの可視範囲に何を意味するかも押さえてください。アプリはユーザーとしてではなく自身の識別子で読み取るため、付与された範囲内であれば、誰が何にアクセスできるかに関係なくすべての文書を読めます。欠陥ではありませんが、このパイプラインが特権コンポーネントであることを意味します。専用の識別子、資格情報のボールト保管、可能ならクライアントシークレットではなく証明書認証、そして活動ログの取得と定期的なレビューを伴わせてください。

実践的な進め方：パイロット、レビュー、それから拡大

重要で、かつ範囲が閉じたライブラリを1つ選ぶ。 ある事業領域の数千件で、うまくいくかどうかを気にする人がいる場所です。最初からテナント全体に広げる試みが失敗する理由は、たいてい技術と無関係です。

まず提案モードで走らせる。 提案値は本番のメタデータではなく、レポートか一時列に書き出します。内容を知る2人に100件のサンプルをレビューさせてください。探すべきは個別の外れではなく系統的な誤りです。失効した下書きを一貫して有効と判定するなら、直すべきはプロンプトではなくステータスの定義です。

スキームを直してから再実行する。 この段階の修正の大半は、モデルへの指示ではなく分類定義に属します。コストが安いこの場所で反復してください。

監査証跡を伴って書き戻す。 値を確定する際は、何を、いつ、どの処理が書いたかを記録します。SharePointのバージョン履歴には自社アプリの識別子による変更として残り、追跡には足りますが説明には足りません。実行ログを保管してください。

そして過去分だけでなく新規文書も扱う。 一度きりのクリーンアップは1年で劣化します。持続する形は、文書が到着した時点でタグを付けることです。誰もが最初に手を付けたがる過去分の一括処理より小さく、はるかに価値のある自動化です。

AI自動タグ付け、SharePoint Syntex、手作業の比較

• 雑然として不揃いなコンテンツへの対応 — Claudeが強い領域です。人が読むように文書を読み、決まったレイアウトを要求しません。Syntexの構造化文書処理は認識可能な帳票やレイアウトを前提とし、手作業は正確ですが量をこなせません。
• Microsoft 365の中に留まること — Syntexの明確な勝ちです。テナント内でネイティブに動き、外部API呼び出しがなく、文書の内容がテナントから出ません。外部モデルを使うなら内容は境界を越えます。後から気づくのではなく、明示的に下すべきガバナンス判断です。
• 導入の手間 — 手作業は初期ゼロ、運用コスト無限。Syntexはライセンスとモデル訓練が要りますがコードは不要。Claudeパイプラインはアプリ登録、コード、運用担当者が必要で、Syntexが苦手なほど非構造なコンテンツか、抽出ではなく内容についての推論が欲しい場合に正当化されます。
• コスト構造 — 手作業は人件費。Syntexはユーザー単位または従量課金。APIパイプラインはトークン課金で、数万件なら安価ですが、テナント全体で走らせる前に試算する価値があります。
• 時間を通じた一貫性 — 自動化の圧勝です。ライブラリが劣化する理由は初回のタグ付けが誤っていたからではなく、40,001件目に誰も手を付けなかったからです。どの経路を選ぶにせよ、継続処理の方が過去分の一括処理より重要です。
• 説明可能性 — 手作業のタグは本人に聞けば理由が分かります。Syntexは信頼度を提示します。外部モデルの判断は3つの中で最も検証しづらく、保持や法務上の帰結を伴うものには人によるレビューを置くべき理由になります。

誰も言わないリスク：継承された権限と過剰共有

ここが飛ばされがちな部分です。タグ付けは権限を変えません——が、人が何を見つけるかを変えます。

成熟したライブラリには、権限継承が切れている箇所が十数か所、何年も前に作られた「リンクを知っている全員」の共有リンク、そして意図よりはるかに多くの人が技術的にアクセスできる文書が少数あります。誰も気づかないのは、そもそも誰も何も見つけられないからです。メタデータを埋め、検索が機能し始めた途端——継承の隙間にずっと置かれていた給与査定が、「HR / 2024」で絞り込んだ誰の目にもきれいに現れます。

これはタグ付けへの反対論ではなく、順序の話です。パイロットのライブラリを見つけやすくする前に、そのライブラリの権限の全体像を見てください。 どこで継承が切れ、なぜそうなったか。どの共有リンクが存在し、誰が作ったか。「外部ユーザーを除く全員」が付くべきでない場所に付いていないか。ライブラリが検索可能になるのなら、このレビューは事後のインシデント対応ではなく、事前に行うべきものです。

保持ポリシーも同じです。文書が一度も分類されていなかったなら、保持ポリシーも正しく適用されていません。タグ付けはPurviewの保持ラベルを意味あるものにする分類を与えます——好機ではありますが、削除の判断がタグ付け精度の下流に置かれることも意味します。両者を接続する前にレビューしてください。

ここを外さない：権限の衛生、APIキー、そしてITを呼ぶタイミング

照らす前に監査する。 前段の権限レビューこそが本丸であり、範囲の定まった作業です。切れた継承、共有リンク、ゲストアクセス、権限過多のグループ、そして所有者が退職した孤立サイト。多くの組織は一度も実施しておらず、出てくる結果は例外なく予想より興味深いものです。

パイプラインの識別子は特権です。 付与範囲のすべてを横断して読み取ります。専用のアプリ登録、Sites.Selectedによる範囲限定、証明書ベースの認証、設定ファイルではなくボールトに置いた資格情報、そして誰かが実際に回す定期レビューを与えてください。

コンテンツの境界を明示的に決める。 文書テキストを外部APIへ送ることは、内容がテナントを出ることを意味します。マーケティング資料のライブラリなら大した話ではありません。人事記録、顧客機密、あるいは展開している市場で規制対象となる内容を含むライブラリなら、記録の残る判断です。契約中のプランに適用されるモデル提供者の現行のデータ取り扱い条件を確認し、データ保護の責任者をパイロットの後ではなく前に巻き込んでください。

所有者を決める。 ライブラリには、コンテンツタイプの意味を決め、境界事例を裁定する人が必要です。それがなければスキームは漂流し、タグ付けもともに漂流します。

BrocentのITアセスメント＆監査は、本稿が「先にやるべき」と述べたMicrosoft 365レビューそのものを実施します——ID、アクセス、エンドポイント、権限構造を対象に、所見を事業展開市場ごとにPDPO、PDPA、PIPL、ISO 27001へ対応付けます。同一テナントが香港・シンガポール・中国本土の法人を異なる規則の下で支えている場合、この点が効いてきます。AI+サポートはAPIおよびRAGの連携構築を担い、パイプラインを社内要員で抱えるのではなく構築と運用ごと任せたい場合に向きます。マネージドITサポートはアプリ登録、資格情報管理、運用を受け持ち、稼働後も安全に保ちます。ClaudeによるMicrosoft 365自動化に広く関心があるなら、ClaudeとMicrosoft 365のメール自動化の記事がメール側で同じガバナンスの型を扱っています。Brocentは2007年の北京での創業以来アジアでマネージドITとセキュリティを提供し、本社はシンガポール、2016年から香港オフィスを構えています。

よくある質問

Claudeはユーザーがアクセスすべきでない文書まで見ますか？

アプリケーション権限を使う場合、パイプラインは自身の識別子で付与範囲のすべてを読み取ります——ですから、はい、個々のユーザーより多くを見ます。Sites.Selectedによる範囲限定が重要な理由であり、パイプラインを特権的なシステム構成要素として扱うべき理由でもあります。ユーザーに新たなアクセス権を与えるわけではありませんが、この連携自体が機微な資産だということです。

まず1つのライブラリだけで試せますか？

できますし、そうすべきです。Sites.Selectedはまさにそのための仕組みです。1つのサイトコレクションにだけアクセスを付与し、実際のコンテンツで分類スキームを検証し、修正が系統的でなくなってから広げてください。最初からテナント全体で走らせると、自信満々に誤ったメタデータが大量に生成されます。

既存のメタデータはどうなりますか？

意図的に決めてください。どちらの答えにも理があります。空欄にだけ書き込むのが最も安全で、人の作業も保全されます。既存値が不揃いだと分かっている場合は上書きが正しいこともありますが、レビュー済みのレポートに基づいて行い、決して盲目的に行わず、変更前の状態を保存してください。SharePointのバージョン履歴に変更は残りますが、そこから4万件分の旧値を復元する作業は引き受けたくないはずです。

Microsoft Graphのアプリ登録は必要ですか？

自動化パイプラインである限り必要です。プログラムからのSharePointアクセスはGraph経由であり、Entra IDでのアプリ登録と管理者による権限の同意が要ります。小規模な対話利用ならユーザー委任型でも動作し、その場合パイプラインはそのユーザーのアクセス範囲に限定されます。それが望ましい場合もあります。

Microsoft Syntexとは何が違いますか？

Syntexはマイクロソフト純正の文書処理機能で、テナント内で動き、内容が外に出ず、レイアウトが認識可能な構造化・半構造化文書に強みがあります。外部モデルは非構造なコンテンツと、「その文書が何を意味するか」の推論に優れます。ライブラリの中身が形式の揃った帳票や契約書中心なら、まずSyntexを評価してください。境界の議論だけでも十分な価値があります。

ライブラリが再び劣化するのをどう防ぎますか？

過去分の一括処理だけでなく、到着時にタグを付けることです。業務が許す範囲で重要な列をアップロード時の必須にし、新規文書への分類処理を定期実行し、ライブラリに名前のある所有者を置いてください。一括処理は目に見えるプロジェクトですが、18か月後に同じ場所に戻るかどうかを実際に決めるのは継続処理の方です。

まずどこから

他の何より先に、1つのライブラリで権限レビューを実施してください。タグ付けのパイプラインを最終的に導入するかどうかに関係なく行う価値があり、その後のすべての順序を変えます。次に5つの列とその意味を定義し、同じライブラリで提案モードのパイロットを行い、修正が系統的なものから個別のものへ変わってから拡大します。Microsoft 365の監査こそ手が回っていない部分だというなら、お問い合わせください。範囲の定まった作業であり、最初に手を付けるべきものです。