社内wikiの権限設計｜AIを入れる前に決める5つのステップ

Q: グループはいくつくらい作るのが適切ですか？

明確な正解はありませんが、目安は情報システム部門の担当者が各グループの目的・管理者・棚卸し時期を説明できる数に収めることです。説明できない数まで増えたら、グループ管理者への委譲を前提とした設計に切り替える合図だと考えてください。数よりも重要なのは、増える仕組みと減る仕組みの両方があることです。

Q: 部署単位とプロジェクト単位、どちらでグループを作るべきですか？

部署単位を土台にすることをおすすめします。人事異動と連動して更新でき、管理の責任者が明確だからです。そのうえで部署をまたぐ案件については期間限定のプロジェクトグループを追加するとよいでしょう。ただしプロジェクトグループは原則としてアクセスを追加する用途に使い、目的・期限・管理者を明確にしたうえで運用するのがおすすめです。部署グループの範囲を狭める用途に使うと、権限の矛盾が生じやすくなります。

Q: AIを導入した後に権限を変更しても大丈夫ですか？

権限の変更自体は問題なく行えます。ただし、AIがすでに出力した回答を取り消すことはできません。権限を締める方向の変更はそれ以降のAI参照範囲には反映されますが、すでに社員が読んだ内容には影響しません。この非可逆性が、AIを入れる前に権限を設計すべき理由です。

Q: 業務委託や兼務者の権限はどう設計すればよいですか？

業務委託メンバーについては専用のグループを作り、そこに必要な情報だけを公開する方式が管理しやすい形です。案件グループに個別追加していく方式は柔軟ですが、契約終了時の削除漏れが起きやすくなります。兼務者についてはどの部署グループを主とするかを設計段階で決め、兼務が解消されたときに片方から外す担当者を明確にしておく必要があります。

Q: ISO 27001を取得しているツールなら、AIに学習利用される心配はありませんか？

セキュリティ認証の取得とAIの学習利用の可否は、独立した論点です。ISO/IEC 27001（ISMS）は情報セキュリティマネジメントの体制が国際規格に適合していることを示す認証であり、認証の対象は管理体制です。AIマネジメントシステムはISO/IEC 42001、プライバシー情報マネジメントはISO/IEC 27701が対応領域であり、ISO 27001の取得はAI学習利用の可否を直接示すものではありません。学習利用の可否は各サービスの利用規約とプライバシーポリシーで個別に確認する必要があります。

Q: 権限を厳しくすると、社内wikiが使われなくなりませんか？

その懸念は妥当です。権限を細かく設定しすぎた結果、必要な情報にたどり着けなくなり社内wikiが使われなくなる失敗は少なくありません。全体を厳しくするのではなく、AIに見せない情報を人事・評価、未公開の意思決定、個人情報、契約・法務の4分類で限定的に切り出すアプローチが有効です。厳しくする対象を最小限に絞ることが、利便性と統制を両立させる現実的な方法です。

最終更新日:2026年9月7日

社内wikiの権限設計は、AIを入れる「前」に済ませておくのがおすすめです。

AIが閲覧権限を勝手に突破するわけではありません。多くのツールは、設定された権限の範囲内で動きます。問題はその先です。これまで「検索されないから実質見えていなかった」情報が、権限の範囲内のまま、誰でも見つけられる状態に変わります。

社内wikiのAI対応は、ここ1年で一気に進みました。NotePMは2026年1月13日にAI検索機能をリリース、Kibelaも2026年5月28日にAI検索ベータ版の提供を開始しています。

この記事を読むと、次の3つがわかります。

AIに見せてはいけない情報の分け方と、制御する階層
権限設計を「棚卸し→分類→グループ設計→AI制御→監査」で進める手順
稟議・セキュリティ審査にそのまま添付できるチェックリスト

AI検索を入れると、権限設計の甘さが露呈します

結論から書きます。AIが権限を突破するというより、権限設計の甘さが露呈すると考えたほうが実態に近いです。

社内ナレッジを参照するAIの多くは、そのユーザーがもともと閲覧できる範囲の情報だけを回答の材料にします。マイクロソフトも公式ドキュメントで、Microsoft 365 Copilotは「個々のユーザーが少なくとも閲覧権限を持つ組織データのみを提示する」と説明しています。

ただし、これは自動的に保証されるものではありません。RAGを自社で構築する場合、元データのアクセス権限（ACL）はベクトルデータベースに自動では引き継がれず、実装して初めて成立します。既製のツールでも、アクセス経路によって制御の効き方が変わることがあります（この記事の後半で詳しく扱います）。

その前提を踏まえたうえで、稟議やセキュリティ審査で本当に問われるのはここです。「AIツールが危ないから止める」という判断は、問題の所在を取り違えています。実際に起きているのは、もともと広すぎた権限設定が、AIによって初めて可視化されるという現象です。

「検索されないから見えていなかった」情報が、見つかるようになります

従来のキーワード検索では、情報が事実上見えない状態が成立していました。ファイル名や見出しに含まれる語を正確に打ち込まなければヒットせず、どこに何があるかを知らない人は、権限上は閲覧できる情報にもたどり着けなかったからです。

この「探せないから実質的に見えていない」状態が、多くの組織で権限設計の甘さを覆い隠してきました。全社公開のまま放置された部門フォルダ、異動前のプロジェクトに紐づいたままの共有設定、退職者が作成して誰も管理していないドキュメント。いずれも権限上は多くの人が閲覧できるにもかかわらず、誰も探さないために問題になりませんでした。

AI検索やAIチャットを備えたツールでは、この前提が崩れます。AIは自然文の質問から意図を汲み取り、複数のドキュメントを横断して参照し、要約という形で答えを返します。「来期の組織再編ってどうなるんだっけ」と聞いた社員に対して、AIが権限上は閲覧可能な未公開の検討資料を見つけて要約してしまう。これがAI導入後に起こる典型的な事象です。

重要なのは、この時点でシステムは何も間違っていないことです。AIは与えられた権限の範囲内で正しく動作しています。間違っていたのは、その情報が全社公開のままだったという権限設計のほうです。

検索性が上がることは、情報の露出が増えることでもあります

AI検索の導入は「ナレッジ活用の促進」として社内で語られます。それは正しい説明です。ただし、同じ現象を情報管理の側から見ると、別の言い方になります。検索性が上がるとは、これまで到達されなかった情報に到達できるようになることであり、それは情報の露出が増えることと同じ意味です。

推進部門は前者の言葉で稟議を書き、情報システム部門は後者のリスクを引き受けます。この非対称が、AI導入プロジェクトで情シスが板挟みになる構造的な原因です。

だからこそ、権限設計は「AIを止める理由」ではなく「AIを進めるための前提条件」として提案する必要があります。権限を整えれば、AIの参照範囲を制御しやすくなり、回答品質の安定にもつながります。

順番が逆になると、取り返しがつきません

AIを先に入れて、問題が出てから権限を締める。この順番には、後から取り返せない性質があります。

第一に、AIが一度出力した情報は取り消せません。権限設定を後から修正しても、すでに回答として提示された内容は、それを読んだ社員の記憶からは消えません。ファイルの共有解除とは、この点が決定的に異なります。

第二に、権限が整理されていない状態のAIは、回答の精度も落ちます。古い版と新しい版、下書きと確定版、部門ごとに異なるルールが混在した状態でAIに参照させれば、AIはそれらを区別せずに要約します。「AIの回答が信用できない」という定着失敗の一因は、AIの性能ではなく参照範囲の設計にあることも少なくありません。

つまり権限設計は、セキュリティのためだけの作業ではありません。使えるAIにするための作業でもあります。この二重の意味づけは、稟議で予算と工数を確保する際の説明としても有効です。

AIに見せてはいけない情報の4分類

結論として、AIの参照範囲から外すべき情報は、代表的には次の4カテゴリから整理します。この分類を先に決めておくと、後続のグループ設計とAI制御の判断が機械的に進みます。

分類	具体例	AI導入で何が問題になるか
人事・評価情報	評価シート、等級・報酬、面談記録、異動検討リスト、採用選考の評価コメント	本人や同僚が自然文で質問した際に、要約という形で断片が露出する。範囲を限定していても、複数ドキュメントの横断参照で内容が推測できてしまう
未公開の意思決定	組織再編の検討資料、事業撤退・統廃合の議論、価格改定の検討、経営会議の議事録	決定前の検討段階の内容が「決定事項」として要約され、社内に既成事実として広がる。撤回されたはずの案が独り歩きする
個人情報・機微情報	従業員の連絡先や家族情報、健康・休職に関する記録、顧客の個人情報を含む問い合わせ記録	個人情報保護委員会は生成AIサービスの利用に関する注意喚起（2023年6月）で、個人データを含むプロンプトの入力について「特定した利用目的の達成に必要な範囲内か」の確認を求めている。入力内容が応答の出力以外の目的（機械学習など）で扱われる場合は法違反となる可能性がある
契約・法務情報	秘密保持義務のある契約書、係争・法務相談の記録、取引先固有の条件、M&A関連資料	取引先との秘密保持契約に違反するおそれがある。「社内共有は可、ただしAI処理は不可」という条件が契約に含まれる場合もある

分類に迷ったときの判断基準

上の4分類に当てはまるか判断しづらい情報は、実務上かならず出てきます。そのときは、次の2つの問いで切り分けてください。

問い1：この情報が、本人の知らないところで要約されて共有されたら問題になるか

「問題になる」と答えられるなら、AI参照範囲から外す候補です。人事・評価情報がここに該当します。

問い2：この情報は、現時点で社外・社内に対して確定した内容として説明できるか

「説明できない」なら、未公開の意思決定に該当します。検討中・下書き・草案の状態にあるものは、原則としてAIの参照対象から外すのが安全です。

この2問で判断できないものは、いったん制限側に倒しておくと安心です。後から段階的に開くほうが、情報が露出してから回収するより管理しやすいためです。

権限とAI制御を切り分ける4つの階層

結論として、社内wikiにおけるAI関連の統制は、次の4階層に分けて設計します。混同されやすいのですが、この4つはそれぞれ制御している対象が違います。

階層	何を制御するか	単位	DocBaseでの提供形態
① 公開範囲・グループ	誰がそのドキュメントを見られるか	全体／グループ／自分のみ	標準機能
② ドキュメント単位のAI除外	どのドキュメントをAIに読ませないか	ドキュメント	標準機能（DocBaseでは`no-ai`タグ）
③ グループ単位のAI利用制限	どのグループの情報をAIの対象外にするか	グループ	セキュリティパック（有料オプション）
④ 操作履歴のCSVエクスポート	誰が何をしたかを後から追えるか	操作ログ（180日間保存）	セキュリティパック（有料オプション）

①と②はまったく別の制御です。①は人に対する閲覧制御、②はAIに対する処理制御です。あるドキュメントを「全社員が読めるが、AIには読ませない」と設定できます。閲覧権限とAI処理の可否は、それぞれ独立して指定できます。この独立性を理解しておくと、設計の自由度が上がります。

標準機能とオプションの境界を、稟議前に確認してください

DocBaseの場合、追加費用なしで使えるAI関連の統制は次の3つです。

チーム全体でのAI機能のON/OFF切り替え
no-aiタグによるドキュメント単位のAI除外
AI利用履歴の確認（内蔵AI機能の利用と、MCP経由の外部AIアプリからのアクセスの両方が対象）

一方、次の機能はセキュリティパック（有料オプション）に含まれる機能の一覧に含まれ、別途契約が必要です。

グループ単位のAI利用制限
操作履歴のCSVエクスポート（180日間保存）
アクセストークン管理
シングルサインオン（SAML 2.0）、IPアドレス制限、2段階認証の必須化

ツール選定中の方は、検討している製品それぞれについて、同じ粒度で標準・オプションの別を確認しておくと安心です。

具体的な設定方法は、DocBase AIの機能とセキュリティ設定を説明したヘルプページにまとまっています。

権限設計の5ステップ

結論として、権限設計は次の順番で進めるのがおすすめです。順番を入れ替えると手戻りが発生します。特にSTEP1の棚卸しを飛ばしてグループ設計から始めると、ほぼ確実にやり直しになる可能性があります。

STEP1：棚卸し ― 何がどこにあるかを可視化する

やること：現在のナレッジがどこに、どの公開範囲で存在するかを一覧化します。

最初に確認すべきなのは、公開範囲が「全体公開」になっているドキュメントの総量と、その内訳です。多くの組織で、この数は担当者の想定を大きく上回ります。導入初期に「まずは全部オープンで」と始めた設定が、そのまま数年分蓄積しているためです。

アウトプット：ドキュメントの一覧（タイトル・作成者・公開範囲・最終更新日・閲覧可能グループ）。エクセルなどの表計算ソフトに書き出せる形にしておくと、STEP2の分類作業がそのまま続けられます。

つまずきポイント：全件を精査しようとすると、作業が終わらなくなりがちです。最終更新日が古く、閲覧数も少ないドキュメントは、個別判断せずにアーカイブ候補としてまとめて扱うとよいでしょう。判断に工数をかけるべきなのは、更新が続いている現役のナレッジです。

STEP2：分類 ― 機密度を3段階で決める

やること：棚卸しした情報に、機密度のラベルを付けます。

まずは3段階に絞ると、現場が判断しやすくなります。段階を増やすほど分類の精度は上がりますが、現場が判断に迷って運用が止まるリスクも上がります。

ラベル	定義	AI参照
公開	全社員が知っておくべき情報。制度、手順、マニュアル、共有ナレッジ	対象にする
限定	特定部門・特定役職のみが扱う情報。部門の業務手順、進行中の案件情報	グループを限定したうえで対象にする
非参照	前章の4分類に該当する情報。人事・評価、未公開の意思決定、個人情報、契約・法務	対象外にする

アウトプット：機密度ラベルが付いたドキュメント一覧。

つまずきポイント：分類をすべて自部門で抱え込まないことです。人事情報の機密度を判断できるのは人事部門であり、契約情報は法務部門です。用意するのは分類の枠組みまでにして、個々の中身の判断は各部門に委ねたほうがスムーズに進みます。この線引きを最初に合意しておくと、後の責任分界も明確になります。

STEP3：グループ設計 ― 誰が見られるかを決める

やること：STEP2の「限定」に該当する情報について、閲覧できる範囲をグループとして定義します。

グループ設計には、大きく2つの型があります。

部署ミラー型：組織図をそのままグループにする方式です。人事異動と連動させやすく、管理がシンプルです。組織変更の頻度が低く、業務が部署内で完結する組織に向いています。

職務ミラー型：職務や案件の単位でグループを作る方式です。部署横断のプロジェクトが多い組織に向いています。ただしグループ数が増えやすく、終了した案件のグループを消す運用を決めておかないと、管理不能な数まで膨れ上がります。

実務上は、部署ミラー型を土台にして、部署横断の案件だけ職務ミラー型のグループを追加する併用が扱いやすい形です。

アウトプット：グループ一覧（グループ名・目的・管理者・想定人数・棚卸し時期）。

つまずきポイント：グループ管理者を決めておくのがおすすめです。情報システム部門が全グループのメンバー管理を抱えると、人事異動のたびにボトルネックになりがちです。DocBaseではグループ管理者という役割が用意されており、グループのメンバーをCSVで一括追加・変更・削除する手順も提供されているため、異動シーズンの作業はこちらで進められます。

STEP4：AI制御 ― 何をAIに読ませないかを決める

やること：STEP2で「非参照」とした情報を、AIの処理対象から外します。

ここで前章の4階層が効いてきます。制御の粒度によって、使う手段が変わります。

ドキュメント単位で外したい：DocBaseの場合は該当ドキュメントにno-aiタグを付与します。標準機能で対応できます
グループ単位でまとめて外したい：グループ単位のAI利用制限を使います。DocBaseではセキュリティパックの契約が必要です
いったんチーム全体で止めたい：AI機能のON/OFFを切り替えます。標準機能です

no-aiタグの運用で決めておくべきことが2つあります。1つは、誰がタグを付ける責任を負うか。作成者に任せるだけでは漏れが出やすくなります。テンプレート側にあらかじめタグを含めておく、あるいは特定グループのドキュメントには一括で付与するといった、人の判断に依存しない仕組みにしておくと安心です。もう1つは、タグの付け忘れを定期的に検知する方法です。四半期に一度、「非参照」に分類したはずの領域を検索して、タグの有無を確認する運用を組んでおくと安全です。

アウトプット：AI参照対象外リストと、その制御手段の対応表。

STEP5：監査 ― 誰が何をしたかを追える状態にする

やること：権限変更とAI利用の記録が残り、後から確認できる状態を作ります。

権限設計は一度で完成しません。組織変更、異動、退職、新規プロジェクトのたびに実態がずれていきます。ずれを検知する仕組みがなければ、設計は半年ほどで形骸化しかねません。

DocBaseでは、操作ログの保存期間とダウンロード方法を含むセキュリティ機能の詳細がヘルプページに公開されています。操作履歴のCSVエクスポートと180日間の保存はセキュリティパックの機能で、外部AIアプリからのAPI呼び出しも記録の対象に含まれます。

アウトプット：レビューのサイクル（頻度・担当・確認項目）を定めた運用ルール。

つまずきポイント：ログを取得できる状態にするだけでは足りません。誰がいつ確認するかを決めていなければ、ログは事故が起きた後に初めて開かれる記録にしかなりません。監査ログの整備と運用については、社内AI統制の4つの柱とAI利用ポリシーの作り方で詳しく解説しています。

【落とし穴】認証方式によって、AI制限の効き方が変わります

ここからは、実際に運用してみないと気づきにくい論点を扱います。設計上もっとも見落とされやすく、稟議やセキュリティ審査でも指摘されにくい箇所です。

結論を先に書きます。no-aiタグやグループ単位のAI利用制限は、アクセス経路によっては適用されません。

同じ制限設定でも、認証方式で挙動が変わります

コマンドラインツールや外部AIアプリからナレッジにアクセスする場合、認証方式が複数用意されているのが一般的です。DocBaseのCLI（@krayinc/docbase-cli）の場合、OAuth認証とアクセストークン認証の2方式があり、AI利用制限の適用範囲が次のように異なります。

項目	OAuth認証	アクセストークン認証
グループ単位のAI利用制限	適用される	適用されない
`no-ai`タグによる制限	適用される	適用されない
主な用途	対話的な利用、AIコーディングツール	CI/CD、スクリプト

出典はDocBase CLIの認証方式とAI利用制限を説明した公式ヘルプです。同ページには「アクセストークン認証では、AI利用が制限されているグループのメモやno-aiタグ付きのメモにもアクセスできます」と明記されています。

これは不具合ではなく、用途に応じて認証方式を選ぶ設計です。アクセストークン認証はCI/CDパイプラインやバッチ処理といった機械的な用途を想定した仕組みで、対話的なAI利用を前提とした制限とは設計思想が異なります。公式ヘルプでも、AI向けの権限設定を効かせたい場合はOAuth認証、AI利用制限が不要な場合はアクセストークン認証、という使い分けが示されています。

ただし、権限設計を担当する側から見ると、この仕様は次の意味を持ちます。

no-aiタグを付けたから安心、ではありません。誰かがアクセストークンを発行してスクリプトに埋め込んだ時点で、閲覧権限の範囲内であっても、グループ単位のAI利用制限とno-aiタグによる制限は適用されなくなります。

だから、アクセストークンの発行そのものを管理します

この構造への答えは、AI制限を強化することではなく、トークンの発行と失効を管理下に置くことです。

DocBaseでは、セキュリティパックの機能としてアクセストークン管理が提供されており、チーム管理者はメンバーが作成したトークンを一覧で確認し、個別に有効・無効を切り替えられます。設計上の実務は、次の3点に整理できます。

発行の可視化：誰がいつトークンを発行したかを管理者が把握できる状態にする
用途の申請：トークンを発行する前に用途と対象範囲を申請させる運用を決める
失効の運用：退職・異動・案件終了のタイミングで無効化する担当と手順を決める

外部AIアプリとのMCP連携でも、管理者が連携状況を把握できる状態にしておく必要があります。DocBase公式リモートMCPサーバーの仕様と管理者向け機能によれば、管理者は誰がいつどのアプリと連携したかを確認・解除できます。MCPサーバー自体のセキュリティ設計については、MCPサーバーを安全に運用するためのセキュリティ対策で個別に解説しています。

この論点は、DocBaseに限った話ではありません

認証方式によって制御の効き方が変わる構造は、API・CLI・外部連携を提供しているナレッジツール全般に共通します。製品ごとに仕様は異なりますので、選定・審査の段階では次の質問を用意しておくことをおすすめします。

API・CLI経由のアクセスに、AI利用制限は適用されるか
適用されない経路がある場合、その経路の利用を管理者が制限・可視化できるか
発行済みのトークンや連携アプリを、管理者が一覧・失効できるか

この3問は、機能一覧表を眺めているだけでは出てこない質問です。セキュリティ審査でこれを聞けるかどうかが、実務の精度を分けます。

DocBaseがおすすめ｜AI利用前の権限設計に使える制御機能を確認できます

ここまで解説した権限設計を実際に進めるには、グループによる閲覧制御と、AI参照範囲の制御を独立して設定できるツールが必要です。DocBaseは、ドキュメント単位で除外できるno-aiタグとチーム全体のAI機能ON/OFFを標準機能として提供し、グループ単位のAI利用制限・操作履歴のCSVエクスポート・アクセストークン管理をセキュリティパックで提供しています。

情報セキュリティマネジメントの国際規格であるISO/IEC 27001（ISMS）認証を取得しており、お客様のコンテンツをAIの学習用データとして利用することはありません。外部専門会社による脆弱性診断を年1回実施しており、直近は2026年1月に実施済みです。稟議に必要な一次資料は、DocBaseのセキュリティ体制とISO 27001認証の詳細にまとめています。

30日間の無料トライアルを用意しています。クレジットカードの登録は不要です。実際の権限設定画面を見ながら、自社のグループ設計を試せます。

▶ DocBaseの30日間無料トライアルを始める

設計フェーズでよくある4つのつまずき

結論として、権限設計が失敗するパターンは、運用の失敗とは別に、設計そのものに起因するものが4つあります。運用ルールを厳しくしても、設計が間違っていれば解決しません。

つまずき1：グループを作りすぎて、誰も管理できなくなる

案件ごと、テーマごとにグループを作っていくと、グループが増え続け、管理しきれない状態になります。この状態になると、新しいドキュメントをどのグループに公開すべきか作成者が判断できなくなり、結果として「とりあえず全体公開」が選ばれます。権限を細かくしようとした結果、権限が消える皮肉な現象です。

対策：グループを新設する際の基準（誰の承認が必要か、最低何名から作るか）と、終了時にアーカイブする手順を、設計段階で決めておくと安心です。グループ数の上限を目安として決めておくのも有効です。

つまずき2：部署とプロジェクトの二重管理で、権限が矛盾する

部署ミラー型と職務ミラー型を無計画に併用すると、同じメンバーが複数の経路で同じ情報にアクセスできたり、逆に本来見えるべき情報が見えなくなったりします。特に問題になるのは、部署グループから外れた異動者が、プロジェクトグループ経由で元部署の情報を見続けているケースです。

対策：どちらを土台にするかを先に決めておくとよいでしょう。併用する場合は、「部署グループが基本、案件グループは目的・期限・管理者を明確にしたうえで運用する」といった役割分担を明文化します。

つまずき3：「原則すべて公開」のまま、AIを解放してしまう

ナレッジ共有ツールの導入初期には、「原則公開、例外のみ非公開」という方針が推奨されることがよくあります。情報共有の活性化という目的においては正しい方針です。

問題は、この方針をAI導入時にそのまま引き継いでしまうことです。人が探しに行く前提の「原則公開」と、AIが横断参照する前提の「原則公開」では、露出の範囲がまったく違います。

対策：AI導入をきっかけに、公開範囲の方針を一度見直しておくとよいでしょう。「原則公開」を維持する場合でも、前章の4分類に該当する情報だけは事前に洗い出し、AI参照対象から外してからAIを有効化します。方針を変えるのではなく、方針の例外を明確にする作業です。

つまずき4：兼務者・業務委託・退職予定者の扱いが未定義

グループ設計は正社員の常勤を前提に作られがちですが、実際の組織には複数部署を兼務するメンバー、業務委託のパートナー、退職日が決まっているメンバーがいます。この3種類の扱いを設計段階で定義していないと、現場の判断で例外的な権限付与が積み重なり、数か月で設計が崩れかねません。

対策：設計時に次を決めておきましょう。兼務者はどちらの部署グループを主とするか。業務委託メンバーは専用グループにまとめるか、案件グループに個別追加するか。退職予定者の権限をいつ縮小するか。この3点を決めておくだけで、例外運用はかなり減らせるはずです。

なお、退職者アカウントの管理や初期設定のまま運用してしまう問題など、運用フェーズの失敗パターンについては、社内wikiの情報漏洩を防ぐツール選びの5つの基準で扱っています。

稟議・セキュリティ審査に添付できるチェックリスト

以下は、社内wikiにAIを導入する前の権限設計チェックリストです。稟議書や審査資料に転記し、自社で検討中の製品名・標準機能かオプションかの別・確認日を追記してお使いください。判断が「いいえ」になった項目が、AI有効化までに片付けるべき課題です。

A. 現状把握

- [ ] 公開範囲が「全体公開」になっているドキュメントの件数を把握している
- [ ] 最終更新から1年以上経過したドキュメントの件数を把握している
- [ ] 退職済みアカウントまたは作成者不在のドキュメントを、人事・アカウント台帳と照合して特定できる
- [ ] 現在存在するグループの一覧と、各グループの管理者を把握している

B. 分類と方針

- [ ] 人事・評価情報の所在を特定し、AI参照対象外とすることを人事部門と合意している
- [ ] 未公開の意思決定に関する資料の扱いを、経営企画または該当部門と合意している
- [ ] 個人情報を含むドキュメントの所在を特定している
- [ ] 秘密保持義務のある契約関連資料について、AI処理の可否を法務部門に確認している
- [ ] 機密度の分類ラベル（3段階）を定義し、社内に周知する準備ができている

C. 制御手段の確認

- [ ] ドキュメント単位でAI参照から除外する手段があり、それが標準機能かオプションかを確認している
- [ ] グループ単位でAI利用を制限する手段があり、それが標準機能かオプションかを確認している
- [ ] チーム全体でAI機能を停止する手段があり、停止の権限を持つ役割を特定している
- [ ] API・CLI・外部AIアプリ経由のアクセスに、上記のAI制限が適用されるかを確認している
- [ ] CLIのOAuth認証ではAI制限が適用され、アクセストークン認証では適用されないことを確認している
- [ ] 発行済みのアクセストークンを、管理者が一覧・無効化できることを確認している
- [ ] 連携中の外部AIアプリを、管理者が確認・解除できることを確認している

D. 監査と運用

- [ ] 権限変更の操作履歴が記録され、保存期間を把握している
- [ ] AI利用履歴を確認する手段があり、確認の担当者と頻度を決めている
- [ ] 外部AIアプリからのアクセスも記録の対象に含まれるかを確認している
- [ ] 組織変更・異動時に権限を見直すサイクル（頻度・担当）を定めている
- [ ] グループの新設基準と、終了時のアーカイブ手順を定めている

E. 段階展開

- [ ] 最初にAIを有効化するパイロットグループを決めている
- [ ] パイロット期間中に確認する質問例・対象ドキュメント・判定担当を定めている
- [ ] 全社展開の判断基準と、問題発生時に停止する手順を定めている

ツール選定の段階にある方は、あわせて社内wiki導入前に確認すべきセキュリティチェックリスト8項目もご確認ください。認証方式や暗号化など、権限設計以外の要件を含めた確認項目をまとめています。

よくある質問（FAQ）

Q. グループはいくつくらい作るのが適切ですか？

明確な正解はありませんが、目安は「情シスの担当者が、各グループの目的・管理者・棚卸し時期を説明できる数」に収めることです。説明できない数まで増えたら、グループ管理者への委譲を前提とした設計に切り替える合図だと考えてください。

数よりも重要なのは、増える仕組みと減る仕組みの両方があることです。新設の基準だけを決めて、終了時にアーカイブする手順を決めていない組織では、グループ数は増え続けがちです。

Q. 部署単位とプロジェクト単位、どちらでグループを作るべきですか？

部署単位を土台にすることをおすすめします。人事異動と連動して更新でき、管理の責任者が明確だからです。

そのうえで、部署をまたぐ案件については、期間限定のプロジェクトグループを追加するとよいでしょう。ただしプロジェクトグループは、原則として「アクセスを追加する」用途に使い、目的・期限・管理者を明確にしたうえで運用するのがおすすめです。部署グループの範囲を狭める用途に使うと、権限の矛盾が生じやすくなります。

Q. AIを導入した後に権限を変更しても大丈夫ですか？

権限の変更自体は問題なく行えます。ただし、AIがすでに出力した回答を取り消すことはできません。

権限を締める方向の変更は、それ以降のAI参照範囲には反映されますが、すでに社員が読んだ内容には影響しません。この非可逆性が、AIを入れる前に権限を設計すべき理由です。導入後に問題が見つかった場合は、まずチーム全体のAI機能を停止して、権限を整理してから再度有効化する手順を検討してください。

Q. 業務委託や兼務者の権限はどう設計すればよいですか？

業務委託メンバーについては、専用のグループを作り、そこに必要な情報だけを公開する方式が管理しやすい形です。案件グループに個別追加していく方式は柔軟ですが、契約終了時の削除漏れが起きやすくなります。

兼務者については、どの部署グループを主とするかを設計段階で決めておきましょう。両方に所属させる場合は、兼務が解消されたときに片方から外す担当者を明確にしておく必要があります。

Q. ISO 27001を取得しているツールなら、AIに学習利用される心配はありませんか？

セキュリティ認証の取得と、AIの学習利用の可否は、独立した論点です。

ISO/IEC 27001（ISMS）は、情報セキュリティマネジメントの体制が国際規格に適合していることを示す認証です。認証の対象は管理体制であり、特定のデータ利用ポリシーを保証する仕組みではありません。

規格の対応領域は分かれています。AIマネジメントシステムはISO/IEC 42001（2023年発行）、プライバシー情報マネジメントはISO/IEC 27701が対応する領域です。したがってISO 27001の取得は、AI学習利用の可否を直接示すものではありません。学習利用の可否は、各サービスの利用規約とプライバシーポリシーで個別に確認する必要があります。

セキュリティ審査では、この2つを分けて質問するとよいでしょう。「ISMS認証を取得しているか」と「入力データがAIの学習に利用されるか」は、別々に確認すべき項目です。

Q. 権限を厳しくすると、社内wikiが使われなくなりませんか？

その懸念は妥当です。実際に、権限を細かく設定しすぎた結果、必要な情報にたどり着けなくなり、社内wikiが使われなくなる失敗は少なくありません。

この記事で提案している方法は、全体を厳しくするのではなく、「AIに見せない情報」を4分類で限定的に切り出すアプローチです。大部分の業務ナレッジは公開のまま、AI参照の対象として残ります。厳しくする対象を最小限に絞ることが、利便性と統制を両立させる現実的な方法です。

まとめ

社内wikiの権限設計は、AI検索やAIチャットを備えたツールを導入する前、あるいは社内wikiを外部AIに接続する前に済ませておくべき前工程です。AIの多くは設定された権限の範囲内で動きます。それでも、これまで「探されないから見えていなかった」情報が、見つかる状態に変わります。

この記事で解説した進め方をまとめます。

AIに見せない情報を4分類で特定する：人事・評価、未公開の意思決定、個人情報、契約・法務
制御の階層を分けて理解する：グループ（誰が見るか）とドキュメント単位のAI除外（AIに読ませるか）は別の制御。標準機能とオプションの境界を稟議前に確認する
5ステップで設計する：棚卸し → 分類 → グループ設計 → AI制御 → 監査
認証方式の落とし穴を押さえる：API・CLI経由ではAI制限が適用されない場合がある。トークンの発行と失効を管理下に置く
設計フェーズ固有の失敗を避ける：グループの作りすぎ、二重管理の矛盾、原則全公開のままの解放、非正規メンバーの未定義

権限設計は一度で完成するものではありません。組織が変われば実態はずれていきます。ずれを検知するサイクルを設計に含めておくことが、形骸化を防ぐうえで欠かせません。

AI時代の権限設計を、DocBaseで始める

DocBaseは、no-aiタグでドキュメント単位のAI除外を設定できる社内wiki・ナレッジ共有ツールです（グループ単位のAI利用制限はセキュリティパックで提供しています）。12,000社以上に導入され、継続率は99%です（自社集計）。ISO/IEC 27001（ISMS）認証を取得し、お客様のコンテンツをAIの学習用データとして利用することはありません。

30日間の無料トライアルで、実際のグループ設定画面と、no-aiタグによるAI除外の挙動をご確認いただけます。クレジットカードの登録は不要で、初期費用もかかりません。

▶ DocBaseの30日間無料トライアルに申し込む

導入前に確認したい点がある方は、DocBase導入前のよくある質問とDocBaseの料金プランとセキュリティパックの価格もあわせてご覧ください。

編集ポリシー

本記事はDocBase開発元である株式会社KRAYが作成しています。可能な限り客観的な情報提供を心がけていますが、自社製品に関する記事であることをあらかじめご了承ください。

参考・出典

NotePM「【新機能】いつでもAIが回答！チャット感覚で使えるAI検索機能を実装しました」（2026年1月13日）
Kibela公式ブログ「Kibela AI検索ベータ版を一部チームを対象に提供開始しました」（2026年5月28日）
個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」（2023年6月2日）
Microsoft Learn「Data, privacy, and security for Microsoft 365 Copilot」（既存アクセス権限の範囲内で動作する旨の記載）
Microsoft Learn「Document-level access control in Azure AI Search」（ACLはインデックスに取り込む必要がある旨の記載）
DocBaseヘルプ「DocBase CLI」「DocBase AI」「セキュリティパックについて」「DocBase公式リモートMCPサーバー」
DocBase「セキュリティ」（ISO/IEC 27001認証、脆弱性診断、AI学習利用に関する記載）

監修

DocBase編集部

情報共有に役立つ情報をお届けします。