Gleanレビュー【2026年】社内検索から企業AIの土台へ。非公開料金の読み方

best

UXリサーチャー/AIツール評価
Gleanレビュー【2026年】社内検索から企業AIの土台へ。非公開料金の読み方

Gleanは、米国Glean社が開発する企業向けAIプラットフォームです。公式サイトの冒頭には「Enterprise AI that Works | Agents, Assistant & Search」とあり、社内検索ツールという位置づけから、検索を土台にしてその上にアシスタントとエージェントを載せる体制へ組み替わっています。料金は非公開で、公式ページからはデモの申込みに進む形です。ここでは公開情報の範囲で整理します。実際に社内環境へ導入して確かめた実機検証は行っていないため、動作の感触や日本語の検索精度は未検証とお考えください。

位置づけと料金で押さえるべき点

  • 現在の位置づけは「Enterprise AI that Works | Agents, Assistant & Search」。社内検索の道具から、企業AIの土台へ役割を広げている
  • 検索は権限を理解する(permission-aware)。閲覧権限のない文書は結果に現れず、AIへの質問でも同じ扱いになる
  • 料金は非公開。公式ページはデモ申込みへの導線で、金額も課金の単位も公開されていない
  • 導入事例の数値は自己申告。公式サイト掲載の数値をそのまま性能の証拠にはできない
  • セキュリティ認証はISO 42001、SOC 2 Type II、ISO 27001、HIPAA、GDPR、TX-RAMP Level 2の表示。日本語精度は未検証

Gleanとは何か。社内検索の道具から「企業AIの土台」へ変わった実態

Gleanは、米国のGlean社が開発する企業向けAIプラットフォームです。2026年時点の公式サイトでは、「Enterprise AI that Works | Agents, Assistant & Search」という表現が最前面に置かれています。読み下すと、Search(検索)、Assistant(アシスタント)、Agents(エージェント)の三つを一式そろえ、そのまとまりを「企業AI」として売る体制です。かつてのような「社内のファイルを探す道具」という単独の説明では、現状を言い表せなくなっています。

この変化は軽く受け流してよいものではありません。社内検索は、会社の知識がどのデータ置き場に散らばっていても横断して探せる点が価値でした。生成AIを業務で使うときの壁も、実は同じ場所にあります。モデルそのものの性能よりも、社内の文脈をどれだけ渡せるかが成果の質を決める。検索の仕組みを持つ製品が企業AIの土台になりやすいのは、この構造上の理由からです。Gleanの位置づけの変化は、偶然ではなく理屈に合った動きだと考えています。

なぜ社内検索が企業AIの土台になるのか

会社の知識は、ドライブ、チャット、課題管理、営業管理などの場所に分かれて積もります。生成AIに業務を任せようとすると、まず「その仕事に必要な情報をAIに渡せるか」が最初の関門になります。外向けの検索サービスは社内の文書を持っていないため、ここが空欄のままです。一方、社内検索を長くやってきた製品は、データをつなぐ配線と権限の処理をすでに抱えています。その土台の上にアシスタントとエージェントを載せるのが、Gleanの示す進み方です。

項目 内容
提供元 Glean(米国)
現在の位置づけ 「Enterprise AI that Works | Agents, Assistant & Search」
主な要素 権限を理解した検索(permission-aware)、Assistant、Agents
接続先の例 Slack、Google Drive、Jira、Confluence、SharePoint、GitHub、Salesforceなど
ガバナンス Glean Protect(監視・ガバナンス)、Work AI Institute/Work AI Indexの運営
認証の表示 ISO 42001、SOC 2 Type II、ISO 27001、HIPAA、GDPR、TX-RAMP Level 2
料金 非公開。デモ申込みのみ

表の読み方で一点だけ補足します。認証の欄が多いのは、売り込み先が大企業の情報システム部門だからです。調達の審査では、この欄が空だと議論が始まる前に止まりがちです。つまり認証一式は機能ではなく、大企業との商談を成立させるための前提条件だと捉えるのが正確です。企業AIの成否は、モデルの性能よりも「社内の文脈を渡せるか」で決まる。この一文が、Gleanの現在地を最も短く言い表すと考えています。

接続先の一覧は、導入検討の出発点として活用するのがよいと考えます。自社で使っているデータ置き場が、公式の接続先の例に含まれているかどうか。含まれていなければ、その時点で対象外の可能性が出ます。含まれているなら、次の確認は「つなぐ範囲をどこまで広げるか」です。全社一気につなぐのが理想に見えますが、権限の棚卸しが済んでいない段階では、部門単位で段階的につなぐ方が事故は減ります。Glean Protectの監視が製品側にあるとはいえ、つなぐ範囲の決定は社側の判断として残ります。

権限を理解した検索とは何か。許可のない文書をAIが読まない設計

Gleanの説明で繰り返し登場するのが、権限を理解した検索(permission-aware)です。仕組みは単純で、検索した人に閲覧権限がない文書は結果に現れません。そして検索だけではなく、AIへの質問でも同じ扱いになります。質問の答えを作るとき、答える側に権限のない情報は材料に入らない。この二層で同じ規律を守るのが、公式説明の上での設計です。

この点が大げさに語られがちなのは、理由があります。社内文書をAIに渡すことへの懸念の多くは、「本来見えない人が見えてしまう」の一点に集まります。部門の名簿、未公開の契約条項、人事の評価資料のように、外に出したくない情報はどの会社にも積もっています。検索の段階から権限を反映する設計は、この懸念への正面からの答えです。成果の良し悪し以前に、導入の議論を成立させるための基礎だと理解するのがよいでしょう。

同じ発想はGlean Protectにもつながっています。公式の説明では、監視とガバナンスを担う仕組みとして案内されています。エージェントを社員それぞれが作れる時代には、作った側の意図と実際の動きがずれる場面が出ます。動きを監視する窓口が製品側にあるかどうかは、組織で使うときの重みが違います。加えてWork AI InstituteやWork AI Indexといった取り組みの運営が示されており、単に道具を売るだけでなく、社内でAIをどう運用するかの知見側にも手を伸ばしている体裁です。

権限を理解した検索が効く場面・効かない場面

効くのは、組織が大きく、権限の設定が細かい会社です。部門ごとに知識が分かれ、共有範囲が役職やプロジェクトで変わる環境では、権限に忠実な検索は単なる安全装置ではなく、「自分に関係する情報だけが返ってくる」利便性にもなります。反対に、数十人程度の規模でドライブの共有が緩い職場では、権限の差そのものが小さいため、この設計の恩恵は薄くなります。さらに言えば、権限の設定自体が乱れている会社では、権限に忠実な検索は乱れをそのまま映します。道具の導入前に権限の棚卸しが必要かどうか、ここは見積もりの段階で確認しておきたい部分です。

整理すると、permission-awareは「安全のための付加機能」ではなく、製品の前提そのものです。社内の権限設計がきちんとしている会社ほど、この前提は利点に転じます。逆に、権限の管理が形だけになっている会社では、利点も半分になりがちです。公開情報の上ではこの仕組みの詳細な挙動まで確認できないため、ここは未検証として、デモの場で「権限のない文書が本当に答えに出ないか」を確かめる手順を組むのがよいと考えます。

AgentsとAssistantで何ができるか。公式事例の数値は自己申告と読む

Agentsは、業務ごとに作るエージェントです。公式サイトでは、コードを書かずに作れる方式が前面に示されています。外部の評価として、Gartnerの「Emerging Market Quadrant for No-Code Agent Builders」でMarket Shaperと紹介された旨が公式サイトに記載されています。この種の呼称は公式サイトの記載として扱うのが正確で、ノーコードのエージェント構築という市場区分の中で位置づけを持つ、という程度に読むのが安全です。

Assistantは、日常の窓口に近い存在です。検索とセットで、質問に対して社内の情報を材料に答えます。Agentsとの違いは、Assistantが「聞いたことに答える」場、Agentsが「仕事を引き受けて進める」場という理解で足りるでしょう。どちらも材料となるのは、接続したSlack、Google Drive、Jira、Confluence、SharePoint、GitHub、Salesforceなどの情報です。接続先の一覧は公式に示されており、よく使うデータ置き場はおおむね入ると考えてよさそうです。

公式サイトの導入事例には、具体的な数値が並んでいます。予約サイト大手のBooking.comでは14,000人、不動産情報のZillowでは採用の8割に達したという表示、通信機器のEricssonでは20,000人を研修したという記載です。これらは公式サイト掲載の自己申告であり、第三者が検証した数値ではありません。事例の大きさを参考にするのは構いませんが、自社での成果を約束する材料には使えない点を、最初に線を引いておきます。

事例(公式サイト掲載) 表示されている内容
Booking.com 14,000人での利用と表示
Zillow 採用の8割に達したという表示
Ericsson 20,000人を研修したという表示

事例の数値を検討材料にどう扱うか

自己申告の数値の使い方は二つに分けられます。使えるのは「同程度の規模の組織でも回るのか」という規模感の参考です。14,000人や20,000人という単位は、大企業での運用実績の目安としては意味があります。使えないのは「自社でも同じ成果が出る」という推論です。成果は社内の文書の整い方、権限の設定、運用のしつけで変わります。数字は規模の参考に留め、成果の部分は自社での試験に委ねる、この切り分けを最初に決めておくのが安全です。

なお、エージェントの作りやすさについても同じ態度でよいと考えます。ノーコードの構築は導入の壁を下げますが、作った後の保守の責任は社側に残ります。誰でも作れるということは、誰でも壊れるものを作れるということでもあります。Glean Protectの監視が製品側にあるのは安心材料ですが、作る側のルールを社内で決めないと、監視の結果が溜まるだけで処理されません。導入の検討では、作る側と見る側の役割を先に決めておくのがよいでしょう。

料金はいくらなのか。非公開のまま読む、課金の考え方

料金は非公開です。公式ページの料金案内は、デモの申込みへの導線で構成されており、金額も課金の単位も表示されていません。本稿で金額を記さないのは、数字が公開されていないからです。「見積もりを取るまで総額が見えない」状態は、検討の初期段階でつまずきやすい点なので、読み方を先に用意しておくのが現実的です。

一般論として、この種の企業向けAIは、席の数と利用量の両方で金額が決まる構造が多く見られます。ただし、これは業界の慣行の話であって、Glean固有の料金設計の記載ではありません。そのため、契約の判断では「何の単位で課金されるのか」という質問を最初に投げる必要があります。席なのか、接続数なのか、エージェントの利用量なのか。単位が分からないまま見積もりを受け取ると、金額の内訳を説明できない稟議書ができ上がるだけです。

見積もり前に確認したい質問 なぜ確認するか
課金の単位は何か 席か利用量かで、人数が増えたときの費用の伸び方が変わるため
接続先の追加は料金に含まれるか JiraやSalesforceなど、つなぐ対象が増えたときの費用感が変わるため
Agentsの利用量はどう数えるか エージェントは動かすほど利用量が伸びるため、運用後の増え方を試算したい
日本語のサポート体制はあるか 社内展開のときの問い合わせ先が、言語面で支えになるため
既存の検索基盤とどこまで置き換わるか 重複する道具を解約できるかどうかで、総額の読みが変わるため

見積もりの依頼は何をそろえてから出すか

分かれ目は、社内の条件をどれだけ先に文章化できるかです。利用する人数、つなぎたいデータ置き場、最初に任せたい仕事の例、この三点をそろえてからデモに申し込むのと、話を聞くだけの状態で申し込むのとでは、見積もりの精度が変わります。料金が非公開の製品ほど、こちらの条件が見積もりの精度を決めます。条件を書けない段階で依頼しても、出てくるのは想定だけで返金にはならない、くらいの心づもりで進めるのがよいと考えます。

もう一点、総額の読みに効くのが、既存の道具との置き換え範囲です。社内検索は、Microsoft 365やGoogle Workspaceの内蔵検索、部門単位の検索ツールなど、すでにどこかで動いています。Gleanがどこまで置き換えて、どこが残るのかを描けないと、道具が二重に課金される形になります。この検討は機能の優劣よりも、社内の運用をどれだけ変えられるかの問題です。デモの場では「置き換えの線引きをどう描くか」を聞く時間を取ることを勧めます。

商談の準備に関係して、稟議書の側の工夫も述べておきます。料金が非公開の製品は、稟議の段階で「見積もりの金額欄が空」になるため、承認が滞りがちです。対策としては、類似の企業向けAIの相場の帯を別途調べて参考値として記載する方法がありますが、この場合、参考値の算出根拠を注記しておくことが重要です。根拠のない金額を書くと、あとで本見積もりが出たときに稟議全体の信頼性を損ないます。あくまで参考値と本見積もりの二段構えで稟議を組み、実数が出た時点で差額を差し戻す手順にしておくのが、堅実な形だと考えます。

評価できる点(公開情報からの判断)

  • 社内検索から企業AIの土台へ位置づけを広げた体制が、公式の説明として筋が通っている
  • 権限を理解した検索(permission-aware)が、検索とAIへの質問の両方で適用される設計
  • 接続先の一覧が実務向き。Slack、Google Drive、Jira、Confluence、SharePoint、GitHub、Salesforceなど主要どころを押さえている
  • セキュリティ認証の一式が明示されている(ISO 42001、SOC 2 Type II、ISO 27001、HIPAA、GDPR、TX-RAMP Level 2)
  • Glean Protectによる監視とガバナンスが製品側に組み込まれている
  • ノーコードのエージェント構築が案内され、No-Code Agent Buildersの市場区分でMarket Shaperと紹介されている(公式サイトの記載)

第一に評価したいのは、位置づけの変化が理屈に合っている点です。社内検索の仕組みを持つ製品が企業AIの土台に進む道筋は、前述のとおり、生成AIが業務で成果を出す条件と整合します。検索の仕組みを後から足す製品とは、土台の完成度が違います。配線と権限の処理が最初からあるかどうかは、導入後の運用の重みに直結する部分です。

第二に、権限の規律が検索と質問の二層で同じ扱いになっている点です。検索では守っていても、AIへの質問ではゆるい、という状態がいちばん事故につながります。この二層を一つの設計として語っているのは、公開情報の上で筋のよい構成だと感じます。加えて監視の仕組みが製品側にあり、認証の一式もそろっているため、大企業の調達審査を通るための材料は見た目上そろっています。

第三に、導線の設計です。料金が非公開の反面、デモの申込みは公式ページの前面にあり、検討の入り口を狭くしていない点は評価できます。事例の規模感も示されているため、「自社の規模で話が通るのか」という最初の絞り込みはつけやすいでしょう。検討の初期段階で、話を聞く相手が見つかる製品かどうかは、意外と重要な条件です。

気になった点・条件付きの評価

  • 料金が一切公開されていない。金額も課金の単位も、見積もりを取るまで見えない
  • 導入事例の数値は自己申告。第三者検証の材料として使えない
  • 日本語UI・日本語検索の精度は未検証。公開情報の上で判断材料が足りない
  • 既存の検索基盤との重複が起こりやすい。置き換えの線引きを利用者側で描く必要がある
  • エージェントを社員が作れる反面、作成後の保守と運用ルールは社側の負担になる

もっとも大きいのは、料金の見え方です。非公開自体は大企業向けの商流ではよくあることですが、検討側の負担として「見積もりを取るまで、そもそも対象になり得るかも分からない」という状態が続きます。社内の稟議では、まず概算の帯を示す必要がある場面が多く、ここが滑り出しの壁になるでしょう。デモに申し込む前に、社内で概算の想定を一つ用意しておくのが実務的な対策です。

日本語については、率直に言って判断材料が足りません。社内文書の検索は、文書の言語の割合が成果に直結します。日本語の文書が中心の会社では、検索の精度もエージェントの答えも、日本語での品質がそのまま成果になります。この点は公開情報の上では確認できず、未検証として保留するしかないのが現状です。デモの場で、自社の文書に近いサンプルでの質問を用意して試すことが、唯一に近い確認の方法だと考えます。

既存の検索基盤との重複はどう裁くか

判断が割れるのはここです。すでにMicrosoft 365やGoogle Workspaceを本格的に使っていて、内蔵の検索と生成AIの組み合わせで不満がないなら、Gleanを足す理由は弱くなります。反対に、知識が複数の道具に分かれて横断できず、生成AIに社内の文脈を渡せていないなら、Gleanの狙いどころがはっきり現れます。重複の判断は機能の比較ではなく、「今の検索で困っている場面を具体的に三つ書けないか」という作業から始めるのがよいと考えます。書けないなら導入は急がない。書けるなら、その三つがデモの確認項目になります。

もう一つの条件は、運用のしつけです。エージェントの作成が自由になると、便利な反面、質のばらつきと放置された作りかけが社内に積もります。監視の仕組みは製品側にありますが、作る側の基準は社側の仕事です。導入時期の判断に含めるなら、「作る側のルールを社内で決められる段階にあるか」を一つの目安にすることを勧めます。ルールがない段階での導入は、道具だけが先行して運用が追いつかない形になりやすいでしょう。

PerplexityやChatGPTと何が違い、どこで住み分けるか

比較で必ず並ぶのがPerplexityとChatGPTです。Perplexityは外部のウェブ情報を材料にした検索型の回答が持ち味で、ChatGPTは汎用の対話と文章の道具です。いずれも社内の権限を理解しない点で、Gleanと役割が分かれます。ClaudeやGoogle Geminiも同様で、モデルの性能は高くても、社内の文書を材料にできるかは別の話です。逆に言えば、外の情報を調べる仕事はPerplexityやExa Websetsのような外部検索側の得意分野で、ここをGleanと比べても比べ方が間違っていると考えます。

仕事の記録という側面では、Otter.aiのような議事録の道具が土台の材料側を支えます。議事録が溜まって初めて、検索とエージェントに材料が渡るため、道具同士は競うより連携です。業務全体を任せる新しい形の道具では、Manusのような万能型のエージェントも登場していますが、社内の権限を前提にするかどうかで、Gleanとは置く場所が違います。法律業務に絞った特化形としてHarveyがあり、営業と顧客管理の土台としてSalesforce AI、HubSpotのような業務システム側の選択肢もあります。いずれも「社内の情報を材料にする」という点では近く、どの業務の範囲を土台にするかで分かれています。

状況 Gleanが向くか 理由
知識が複数の道具に分かれて横断できない 向く 権限を理解した横断検索が、社内の文脈をAIに渡せるから
外部のウェブ情報を調べる仕事が中心 向かない 外部検索はPerplexity系の得意分野で、社内の権限が絡まないから
部門ごとの権限が複雑で情報漏えいが心配 向く permission-awareの設計が検索と質問の両方で働くから
数十人規模で共有も緩く権限も単純 迷う 権限の差が小さいため、この設計の利点が出にくいから

導入候補の向き不向き

向くのは、人数が多く、データ置き場が多く、権限が細かい組織です。加えて、生成AIをすでに個人レベルで使っていて、「社内の情報が絡むと急に役に立たなくなる」という不満が溜まっている組織なら、土台の価値がはっきり現れます。向かないのは、知識が一つの道具に収まっていて、共有の習慣が緩い小規模な職場です。この場合、既存の道具の内蔵機能で足りる可能性が高く、新しく土台を足す費用を正当化しにくいでしょう。

道具の選択を分ける視点として、情報の向きの確認があります。外向けの検索は、ウェブに出ている情報を集めて答えます。社内の検索は、権限の中にある情報を集めて答えます。この二つは答えの性質が違うため、同じ道具で両方を満たそうとすると、どちらも中途半端になりがちです。外の情報の調べ物には外向きの道具、社内の知識の探し物には土台型の道具、と仕事の向きで分けた方が、それぞれの道具が本来の強さを発揮します。Gleanを選ぶかどうかの前に、「自分の困りごとがどちらの向きか」を確認する工程を入れることを勧めます。

検討の進め方を一段階で整理します。最初の窓口は公式ページからのデモ申込みで、そこに持っていく条件を事前に書き出しておくのがよいと考えます。人数、接続先、任せたい仕事の例、そして「今の検索で困っている場面」の三点です。基本情報はこの後の関連リンクからも参照できますが、判断の本体は社内の条件整理にあります。道具が社内の文脈を理解できるかを確かめる前に、社側が自社の文脈を書けているか。この順序を守れば、非公開料金の製品との商談も、ぶれない形で進められるはずです。

よくある質問

Q. Gleanは無料で試せますか?

A. 公式ページの案内はデモ申込みへの導線で構成されており、無料トライアルの有無は公開情報からは確認できていません。料金そのものが非公開のため、試用の条件も見積もりの段階で確認する必要があります。デモの際に試用の可否と条件を合わせて聞くのが、手数の少ない進め方だと考えます。

Q. 料金はいくらですか?

A. 非公開です。公式ページに金額も課金の単位も表示されておらず、本稿でも金額を記していません。一般論として企業向けAIは席と利用量で金額が決まりやすいのですが、これは業界の慣行の話であってGlean固有の記載ではありません。見積もりを取る前に、人数と接続先と任せたい仕事の例を書き出しておくと、商談の精度が上がります。

Q. 日本語の社内文書でも使えますか?

A. 日本語UI・日本語検索の精度は未検証で、公開情報の上では判断材料が足りません。社内文書の言語の割合が成果に直結するため、日本語の文書が中心の会社では、デモの場で自社の文書に近いサンプルを使った質問を用意して確かめるのが唯一に近い方法です。この部分だけは、事例の数字では代用できません。

Q. 導入事例の数字は信頼できますか?

A. Booking.comの14,000人、Zillowの採用8割、Ericssonの20,000人研修といった数値は、公式サイト掲載の自己申告であり、第三者が検証したものではありません。規模感の参考には使えますが、自社での成果を約束する材料には使えないと考えるのが正確です。

Q. セキュリティ面の評価はどうですか?

A. 公式サイトにはISO 42001、SOC 2 Type II、ISO 27001、HIPAA、GDPR、TX-RAMP Level 2の表示があり、大企業の調達審査を想定した材料はそろっています。加えてGlean Protectという監視とガバナンスの仕組みが製品側にあります。ただし認証は前提条件であって成果の保証ではないため、自社の権限設計との相性は別途確認が必要です。

Q. PerplexityやChatGPTとどう違いますか?

A. 社内の権限を理解して検索と回答を行うかどうかが最大の違いです。Perplexityは外部のウェブ情報を、ChatGPTは汎用の対話を得意とし、いずれも社内の権限を材料にしません。Gleanは接続した社内のデータ置き場を横断して、権限の範囲内で検索と回答を行う土台です。外の情報を調べる仕事と、社内の知識を探す仕事、この二つで道具を分けるのが現実的な住み分けだと考えます。

まとめ

Gleanの検討で最初に決めるべきは、「検索として入れるのか、土台として入れるのか」という問いの立て方です。社内検索の不満が主なら、既存の道具との置き換え線引きが先になります。生成AIに社内の文脈を渡せていないという不満が主なら、権限を理解した検索とエージェントの土台として意味が出ます。料金は非公開のため、人数と接続先と任せたい仕事の例を書き出してからデモに申し込むのが、見積もりの精度を上げる唯一の実務的な対策です。事例の数値は自己申告として規模感の参考に留め、日本語の精度は自社のサンプルでの確認に委ねる。実務的な結論として、社内の権限設計が整っていて、検索の不満が具体的に三つ書ける会社だけが、Gleanの対象になり得ると考えます。書けないなら導入は急がず、書けた時点でデモの確認項目としてその三つを持ち込む。この順序が、非公開料金との商談を最も無駄なく進める形です。

主な参照元:Glean公式サイトの製品説明および料金案内(glean.com)。現在の位置づけ・接続先・認証表示・Gartnerの記載・導入事例の数値は2026年10月24日時点の公式サイト掲載にもとづく。事例の数値は自己申告。実機検証は未実施。



メールマガジン

最新のAI情報をメールで受け取る

新着のAIツール比較・ランキング・ニュースを、まとめてお届けします。

ご登録後、確認メールをお送りします。配信停止はいつでも可能です。

週1回・無料

AEO診断・AIクローラー最新情報を、
週1回お届け

AI Botの仕様変更やAEO対策のノウハウ、よくあるトラブル事例を編集部が厳選しメール配信。いつでも配信停止可能です。

  • 新Bot・仕様変更AIクローラーに新しいBotが追加されたとき、判定仕様が変わったときの速報
  • 障害事例と対処AEO診断で多い障害事例と、その対処方法を実例で解説
  • AEO活用術Web制作会社・SEO担当者向けのAEO活用テクニック

登録により 利用規約に同意したとみなされます。確認メールのリンクを押すと登録が完了します。

My-Best.AI|AIツール比較・ランキング・おすすめ最新AI情報
Logo