Onyxを社内検索に入れる前の確認項目｜権限と運用の責任

「オープンソースの社内検索があるなら、ライセンス費用なしで全社に配れるのでは」「社内のサーバーで動かせば、資料が外に出ないから安心だと聞いた」——生成AIで社内の資料を探せるようにしたい情シスや、AI導入の担当者からよく出てくる声です。どちらも、出発点としては間違っていません。けれども、オープンソースなら無料で社内検索が作れる、というのは半分の話です。本当は、自社で動かすということは、元の権限を正しく引き継ぐ責任と、更新や脆弱性に対応する運用の責任を、自社で引き受けることです。この記事では、Onyx を例に、社内検索を自社で動かす前に確かめておく項目を整理します。

Onyx とは何か（2026年10月時点の公式の説明）

Onyx は、社内のさまざまなアプリにある資料を取り込んで索引にし、生成AIのチャットから引用付きで答えさせるオープンソースの製品です。公式GitHub の説明では、50以上のアプリにつながり、資料を権限などの情報ごと取り込みます。公式サイトは、取り込んだ資料を元の権限に沿って、問い合わせのときに絞り込むと説明しています。

旧名は Danswer で、公式GitHub のライセンスの著作権表示には、いまも旧名の会社名が残っています。2026年10月14日時点で、GitHub のスターは3万2千を超え、10月8日に v4.8.5、10月13日に v5.0.0 のベータ版が公開されるなど、更新は活発です。

検索のほかに、複数の手順で調べて報告をまとめる機能、知識の範囲と指示を絞ったエージェント、外部のアプリで操作をさせる機能もあります。使う入口も、Web の画面、Slack や Discord の対話ボット、MCP サーバーとしての接続、ブラウザの拡張と、複数用意されています。公式GitHub は、索引を持つ標準の構成のほかに、資料の索引を持たず画面とエージェントだけを動かす軽い構成（メモリ1GB未満）も案内しています。社内検索として使うなら、索引を持つ標準の構成が前提になります。

答えを作る生成AIのモデルと、文章を検索用の数値に変えるモデルは、利用者が選べます。公式GitHub は、大手の提供元のモデルにも、自社で動かすモデルにも対応するとしています。どのモデルを選ぶかで、資料の中身が社外に出るかどうかが変わる点は、後の節で扱います。

国内でまだ知られていない理由

Onyx を日本語で詳しく解説した記事は、2026年10月時点でほとんど見当たりません。理由として考えられるのは、公式サイトと文書が英語で書かれていること、そして文書の中心が、自社の環境に組み立てる技術者向けの手順になっていることです。

もう一つは、接続先の顔ぶれです。公式の文書が権限を同期できる接続先として挙げているのは、Confluence、ジラ、Salesforce、GitHub、Box、Teams、アウトルック、Slack、Google ドライブ、シェアポイントなど、海外の業務アプリが中心です。国内のグループウェアや文書管理を主に使っている会社では、そもそも索引したい資料に届くかを最初に確かめる必要があります。

製品の提供状況については、公式GitHub はアーカイブされておらず、確かめた範囲では、公式サイト・公式GitHub に終了や新規受付停止の告知は見当たりません。提供元の体制に関わる情報は、公式の発表で確かめられたものだけを判断材料にしてください。

なお、複数の生成AIを1つの画面で社員に配る話は、別の記事で扱います。この記事は、社内の資料を権限つきで検索させる部分に絞ります。

「無料で作れる」が半分しか当たらない理由

Onyx のライセンスは、公式GitHub の ライセンスの文書に書かれています。それによると、ee という名前のフォルダの中は Onyx の企業向けライセンスで、それ以外の部分が MIT です。組み込まれている第三者の部品は、それぞれ元のライセンスに従います。

問題は、社内検索で一番大事な機能がどちらに入っているかです。公式の文書が企業向け版の機能として挙げているのは、元のアプリから権限を自動で引き継ぐ接続先、SAML などによるSSO、ユーザーグループと役割ごとの権限、グループ単位の権限、利用の分析、資格情報の暗号化などです。元の権限を自動で引き継ぐ仕組みは、無償の版ではなく企業向け版の機能として案内されています。

つまり、MIT の部分だけで社内検索を組むと、接続先ごとに「全員に見せる」か「指定した人だけに見せる」かを手で決める形になります。元のアプリで人ごとに細かく分けている権限を、そのまま反映させたいなら、企業向け版の契約か、提供元の雲での利用を検討することになります。公式の文書は、提供元の雲は企業向け版の機能をすべて含むと説明しています。

費用の増え方も、この分かれ目で変わります。無償の版では、費用はほぼサーバーと運用する人の手間です。企業向け版や提供元の雲では、契約の費用が加わります。どちらが安いかは一概に言えず、人の手間を時間で見積もって並べることが必要です。

3つの形を、5つの軸で比べる

社内の資料をAIで検索させる方法は、大きく3つに分かれます。Onyx を自社の環境で動かす形、提供元の雲で使う形、そして検索の機能を持った別の製品を買う形です。どれを選ぶかは、権限・データの置き場・脆弱性への対応・ライセンス・止め方の5つで比べると整理しやすくなります。

比べる軸	自社で動かす	提供元の雲で使う	製品の社内検索を買う
権限の引き継ぎ	無償の版は接続先ごとに手で設定。自動の同期は企業向け版	企業向け版の機能をすべて含む（公式の説明）	製品ごとの仕様。同期の間隔を確かめる
データの置き場	索引・DB・処理を自社の環境に置ける	提供元の環境に置く	提供元の環境に置くことが多い
脆弱性への対応	勧告を見て自社で版を上げる	提供元が対応	提供元が対応
ライセンス	MIT と企業向けの境目を読む	契約の条件に従う	契約の条件に従う
止め方	接続先の鍵を外し、索引と記録を自社で消す	契約の終了とデータの削除の手順	契約の終了とデータの削除の手順

表を見ると、自社で動かす形の利点は、データの置き場を自社で決められることにほぼ集中しています。その代わり、ほかの4つの軸では、提供元が引き受けていた仕事が、そのまま情シスに移ってきます。

どの形にするかは、扱う資料の機微さで決まります。外に置けない資料を検索させたいなら自社で動かす価値がありますが、そうでないなら、雲や製品のほうが運用の負担は軽くなります。社内検索の製品を比べる話は別の記事にあるため、ここでは自社で動かすと決めた場合に確かめる項目を、次の節から順に見ていきます。

確認1：権限の引き継ぎが、どの接続先で効くか

公式の文書では、接続先ごとに3つの見せ方を選びます。全員が見られる「公開」、作成者と指定した人やグループだけが見られる「非公開」、そして元のアプリから見られる人の一覧を取り込んで絞る「権限の自動同期」です。

気をつけたいのは「公開」です。公式の文書は、公開にした接続先が元のアプリで非公開の資料を読み込むと、Onyx の利用者全員がその資料を見られると警告しています。たとえば、人事の共有フォルダを読み込む接続先を公開にすると、元のアプリでは人事しか開けない資料が、検索の答えとして全員に出てしまいます。

権限の自動同期ができる接続先も、条件つきのものがあります。Google ドライブとメールはサービスアカウントか、管理者の権限での認可が必要で、シェアポイントは証明書による認証が必要です。どの接続先がどの見せ方に対応しているかは、導入する版の文書で一つずつ確かめ、接続先の一覧表に書き込んでおきます。

一覧表には、接続先の名前、見せ方、読み込む範囲（どのフォルダやチャンネルか）、元のアプリでの権限の持ち主を並べます。見せ方を「公開」にした接続先には、公開にした理由を書く決まりにしておくと、うっかり機微な場所を公開で読ませる事故を防ぎやすくなります。

確認2：権限が変わってから反映されるまでを試す

権限を同期できても、元のアプリで権限を変えた瞬間に検索の結果が変わるとは限りません。公式の文書では、新しい資料を取り込む間隔の既定は30分、元のアプリで消えた資料を索引から消す間隔の既定は30日と書かれています。一方、権限そのものを同期する間隔は、確かめた範囲の文書には書かれていません。

書かれていない以上、自社で試して測るしかありません。異動や退職で見られる範囲が変わったとき、検索の答えから資料が消えるまでにどれだけかかるかは、情シスが説明を求められる部分です。試験は次の順で進めます。

測った時間は、そのまま社内への説明に使います。「権限を外してから最大でこれだけの時間は、検索に出ることがある」と書いておけば、人事や法務も判断できます。時間が長すぎる場合は、機微な資料をそもそも索引に入れない、という次の確認につながります。

確認3：接続先ごとの鍵を、誰が持ち、どこに置くか

Onyx は、接続先ごとに資格情報を登録して資料を読みにいきます。権限の同期をするなら、多くの場合、元のアプリの広い範囲を読める管理者寄りの鍵を渡すことになります。社内検索の仕組みは、社内で最も多くの資料を読める鍵を集めた場所になる、ということです。

このため、鍵の扱いは最初に決めておきます。誰が鍵を作り、どこに保管し、何か月ごとに作り直すか。鍵を作った人が異動したら誰が引き継ぐか。公式の文書は、資格情報の暗号化を企業向け版の機能として挙げているため、無償の版で動かす場合は、鍵の保管の守り方を自社の環境の側で考える必要があります。

鍵に関わる不備も実際に見つかっています。公式GitHub のセキュリティ勧告では、2026年7月に、利用者ごとに登録した MCP サーバーの認可の鍵が、他の利用者から取得できてしまう不備（CVE-2026-71424）が重大と評価され、v4.0.0 で修正されたと公表されています。鍵を預かる仕組みである以上、不備が出たときの影響は大きくなると考えて、更新の体制を組みます。

鍵ごとに、読ませる範囲を絞れるかも確かめます。元のアプリ側で、読み取りだけの権限や、特定のフォルダに限った権限を作れるなら、そちらを使います。Onyx の画面からではなく、元のアプリ側の設定で範囲を絞るほうが、確実に効きます。

確認4：更新と脆弱性への対応を、誰がいつまでにやるか

自社で動かす場合、提供元が修正を出しても、自社の環境の版を上げるまでは不備が残ります。公式GitHub のセキュリティ勧告を見ると、2026年だけでも次のような不備が公表されています。

• 他の利用者の会話を途中で止められてしまう不備（CVE-2026-42276・2026年4月公表・3.0.9／3.1.6／3.2.6で修正）
• 他の利用者が上げたファイルを取得できてしまう不備（CVE-2026-42277・同時期・同じ版で修正）
• 利用者ごとの MCP サーバーの認可の鍵が漏れる不備（CVE-2026-71424・2026年7月公表・重大）
• グループの管理役が他のグループの所属を変え、別のグループの資料が見えてしまう不備（CVE-2026-63178・2026年7月公表・4.3.0で修正）

どれも修正済みですが、ここから読み取れるのは、権限まわりの不備は活発な製品でも繰り返し見つかるということです。社内検索は権限の仕組みそのものが価値なので、権限の不備は、資料の漏えいに直結します。

体制として決めておくのは3つです。勧告を誰が見るか（GitHub の通知を担当者と予備の2人で受けるなど）、重大度ごとに何日以内に版を上げるか、版を上げる前に何を試すか（確認2の試験を回すなど）です。更新は頻繁で、10月だけでも複数の版が出ています。毎回すべてを追うのは難しいため、勧告が出たときは必ず追い、それ以外は月に一度まとめて上げる、といった線を引きます。

大きな版の切り替えにも備えが要ります。v5.0.0 のベータ版が10月に公開されていることから、近く大きな版の更新があると考えられます。大きな版の切り替えでは設定や接続先の扱いが変わることがあるため、試験用の環境で先に動かしてから本番を上げる手順にしておきます。

確認5：ライセンスの境目を、使う機能ごとに読む

ライセンスの文書の通り、ee のフォルダの中は企業向けライセンスで、それ以外は MIT です。自社で動かす場合、どの機能が ee 側にあるかで、契約が要るかどうかが変わります。

確認の手順は単純です。まず、使いたい機能を書き出します。次に、公式の文書の企業向け版の機能の一覧と突き合わせます。一覧に入っている機能を自社で動かす版で使いたい場合は、提供元に問い合わせて、契約と試用の条件を書面で確かめます。公式の文書は、自社で動かす企業向け版の試用を問い合わせで受け付けると案内しています。

MIT の部分だけで使う場合も、確かめることがあります。MIT は改変や再配布を広く認めるライセンスですが、著作権表示とライセンスの文面を残す条件があります。社内で手を加えて使うなら、どこを変えたかの記録と、表示を残していることの確認を、運用の手順に入れておきます。

ライセンスの扱いは、版が変わると動くこともあります。版を上げるたびに ライセンスの文書に変更がないかを見ることを、確認4の更新の手順に含めておくと安心です。判断に迷う場合は、法務の担当者と一緒に原文を確かめてください。

確認6：答えを作るモデルに、何が渡るか

公式GitHub は、索引・データベース・処理を自社の環境の中で完結させ、外部と切り離した構成でも動かせると説明しています。ただし、自社で動かしても、答えを作るモデルに外部の提供元を選べば、検索で見つかった資料の一部はその提供元に送られます。

社内検索の答えは、検索で見つかった資料の一部を生成AIに渡し、それをもとに文章を作らせて出します。つまり、どのモデルを使うかで、資料の中身が社外に出るかどうかが決まります。外部の提供元のモデルを使うなら、その提供元の法人向けの契約で、入力の扱い（学習に使われないか、保存期間はどれだけか）を確かめます。

文章を検索用の数値に変えるモデルも同じです。こちらは索引を作るときに、取り込んだ資料のほぼすべてを通します。公式GitHub によると、どちらのモデルも手元で動かすことができます。外に出せない資料を扱うなら、両方のモデルを自社の環境で動かす構成を選び、必要な計算機の能力を見積もります。

公式サイトは「誰もあなたのデータで学習しない」と書いていますが、これは Onyx 自体についての説明です。外部の提供元のモデルを選んだ場合は、その提供元の条件が適用されます。部署ごとに使えるモデルを分けられるかも、導入する版で確かめておきます。

確認7：見せてはいけない資料を、索引に入れない

権限の引き継ぎがどれだけ正確でも、不備が出たり、元のアプリの権限そのものが緩かったりすれば、資料は見えてしまいます。だから、見せてはいけない資料は、最初から索引に入れないことを、権限の設定より先に決めます。

具体的には、接続先の読み込む範囲を、置き場の単位で絞ります。人事・給与・健康に関わる場所、法務の係争の資料、未発表の決算の資料などは、接続先の読み込む範囲から外します。どの置き場を外すかの考え方は、別の記事「社内AIに読ませない置き場の一覧」で詳しく扱っています。

元のアプリ側の権限の棚卸しも欠かせません。社内検索を入れると、これまで誰も気づいていなかった「全社に公開されたままの機微な資料」が、検索の答えとして急に表に出てきます。これは社内検索の不具合ではなく、元のアプリの権限の問題が見えるようになっただけですが、利用者からは社内検索の事故に見えます。

導入の前に、索引に入れる予定の場所について、全社公開になっている資料を洗い出し、持ち主に確かめてもらう期間を設けます。この作業は情シスだけでは終わらないため、各部門の資料の持ち主を巻き込む段取りを、導入の計画に最初から入れておきます。

確認8：MCP サーバーとして開くかは、別に決める

公式GitHub によると、Onyx は MCP サーバーとして、外部のAIの道具から接続させることができます。README では、Claude Code や Codex などの道具を Onyx につなぐと、動かしている人と同じ権限で社内の知識を使える、と説明しています。

便利な一方で、社内検索の窓口が、画面とボットに加えてもう一つ増えることになります。AIの道具が社員の代わりに社内の資料を大量に読みにいく形になるため、どの道具からの接続を許すか、誰に許すかを、画面での検索とは分けて決めます。

確認3で触れた通り、利用者ごとの MCP サーバーに関わる鍵の不備は、2026年7月に重大として公表されています。外部の道具とつなぐ部分は、不備が出たときの影響が広がりやすい場所です。最初は画面とボットだけで運用を始め、MCP サーバーとしての接続は、利用の記録を見ながら対象を絞って開くのが安全です。

MCP の接続そのものの確認項目は、別の記事「MCPで外部とつなぐ前の確認項目」にまとめています。ここで決めるのは、社内検索をその接続先の一つとして開くかどうかと、その範囲です。

止め方と畳み方を、入れる前に書いておく

社内検索を止めるときにやることは、画面を閉じるだけではありません。自社で動かす場合、止めるときに残るものは、接続先ごとの鍵、取り込んだ資料の索引、利用者の会話の記録、アップロードされたファイルの4つです。どれも自社の環境に残り、消すのは自社の仕事です。

手順として書いておくのは、次の順です。まず各接続先の取り込みを止め、元のアプリの側で Onyx に渡していた鍵やサービスアカウントを無効にします。次に、対話ボットや MCP サーバーとしての接続を外します。最後に、索引とデータベースと保存されたファイルを消し、消したことを記録します。

ここで大事なのは、元のアプリの側で鍵を無効にする工程を、必ず最初に置くことです。Onyx の側を先に消しても、元のアプリに鍵が生きていれば、その鍵は管理の外に残ります。鍵の一覧は確認3で作った表がそのまま使えます。

一部の部門だけ止める場合も考えておきます。ある部門の資料だけを外したいときは、該当する接続先の取り込みを止めるだけでなく、索引に残った資料を消す手順も要ります。元のアプリで消えた資料を索引から消す間隔の既定は30日なので、待たずに消す方法を確かめておきます。

回答の引用元を開いて確かめるのは人

社内検索のAIは、資料を探し、要約して答えるところまでを速くしてくれます。けれども、答えが正しいかどうか、その資料がいまも有効かどうかは、AIには判断できません。古い規程や、すでに終わった商品の資料をもとに、自信を持って答えることもあります。

そのため、運用のルールとして、答えには必ず引用元を出させ、引用元を開いて確かめるのは人、と決めておきます。特に、社外に出す文書や、契約・人事に関わる判断に使う場合は、引用元の資料の日付と持ち主を確かめてから使う、という一文を利用のルールに入れます。

利用の記録の扱いも決めます。公式GitHub は、質問の履歴を監査に使える機能を企業向けの機能として挙げています。誰が何を検索したかは、社員にとって機微な情報でもあるため、記録を残すか、誰が見られるか、何日で消すかを、導入の前に社内に示しておきます。

AIに任せてよいのは、探すことと下書きの要約です。どの資料を索引に入れるか、答えを業務の判断に使ってよいかは、人が決めます。この線を、利用者向けの案内の最初に書いておきます。

導入前の確認項目

ここまでの確認を、導入の判断の前に情シスが埋める項目としてまとめます。すべてに答えが書けてから、試験の利用を始めるのが目安です。

• 使いたい機能が、無償の版と企業向け版のどちらに入っているかを、公式の文書で確かめた
• 自社で動かす・提供元の雲・製品を買う、の3つを、人の手間の見積もりも含めて比べた
• 接続先ごとの見せ方（公開・非公開・権限の自動同期）と、公開にした理由を一覧に書いた
• 権限を外してから答えに出なくなるまでの時間を、試験で測った
• 接続先ごとの鍵の作成者・保管場所・作り直しの周期・引き継ぎ先を決めた
• セキュリティ勧告を受け取る担当者と予備、重大度ごとの更新の期限を決めた
• 答えを作るモデルと検索用のモデルを決め、資料が社外に出るかを確かめた
• 見せてはいけない置き場を索引の範囲から外し、全社公開の資料の持ち主に確認を頼んだ
• MCP サーバーとして開くかどうかと、開く場合の対象を決めた
• 止めるときの手順（鍵の無効化を最初に、索引と記録の削除を最後に）を書いた
• 答えの引用元を人が確かめるルールと、利用の記録の扱いを社内に示した

項目の多くは、社内検索の製品を買っても考えることです。ただ、製品を買えば提供元が引き受ける部分が、自社で動かすと情シスの仕事になります。自社で動かす価値は、外に置けない資料を検索させられることにあるので、その価値が手間に見合うかを、この一覧で判断してください。

まとめ

Onyx は、50以上の接続先を索引し、元の権限に沿って引用付きで答える、オープンソースの社内検索とAIチャットです。中核は MIT で、自社の環境で外部と切り離して動かすこともできます。一方で、元の権限を自動で引き継ぐ仕組みや SAML のSSOは企業向け版の機能として案内されており、無償の版だけでは権限の設定を手で担うことになります。自社で動かすと決めたなら、接続先の見せ方、権限の反映にかかる時間、鍵の持ち主、勧告への対応の期限、モデルに渡る資料、見せない置き場、MCP サーバーとしての開き方、止め方を、入れる前に決めておきます。答えの引用元を開いて確かめるのは人です。まずは、索引に入れたい置き場を書き出し、それぞれを公開・非公開・権限の自動同期のどれで読ませるかを一覧にするところから始めてみてください。

• 製品の機能・ライセンス・セキュリティ勧告は、Onyx の公式サイト、公式文書、公式GitHub を2026年10月14日に確かめた範囲に基づきます。版の更新で機能の範囲や名称が変わることがあるため、導入の前に最新の公式情報を確かめてください
• ライセンスの解釈や、資料を外部のモデルに渡してよいかの判断は、必要に応じて法務の担当者と一緒に確かめてください

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。