Confluence向けGrok Bot:2026年にできることとできないこと

なぜ「Confluence向けGrok Bot」がそもそも検索されるのか

xAIが2026年8月11日にGrok Botをローンチしたとき、その謳い文句は、APIを一切必要とせず、実際のツールにサインインしてエンドツーエンドで作業をこなすエージェントというものでした。製品ページには、サポート業務を直接狙ったプロンプト例まで載っています。「Sign in to Zendesk so I can work the support queue.」ZendeskをConfluenceに置き換えれば、多くのナレッジマネージャーが今まさに検索窓に打ち込んでいる質問そのものになります。これは私のWikiを読んで、整理された状態に保ち、そこから質問に答えてくれるのか、というものです。

私はAIエージェントを作ることを生業にしているので、正直なところを先に伝えておきます。「デモでエージェントがページを編集できる」ことと、「監督なしでランブックに触れさせても構わないと信頼できるエージェント」の間には、途方もない隔たりがあります。Wikiは、自信満々な誤った編集が一人を困らせるだけでは済まず、次にみんなが読むソースを静かに汚染してしまう唯一の場所です。ナレッジが空で返ってきたときにボットが回答をでっち上げるのを私は見てきました。だからこそ、私が近くで関わったどの導入も、本番の何かに触れる前にいまでは実際の履歴に対してリハーサルされるのです。

だから、まったく新しい自律エージェントが私のConfluenceを管理すると言ってきたとき、最初の疑問は「クリックできるか」ではありません。「自信満々に間違えた最初の瞬間に何が起き、チーム全員がそれを読んでしまう前に誰が気づくのか」です。それがこの記事の視点です。Grok Botは、純粋に興味深い汎用ワーカーです。Confluenceにどう向けるか、何が得意か、そしてナレッジベース特有にどこで綻びが見えるかを見ていきましょう。

GrokをConfluenceに接続する2つの方法

経路は正確に2つあり、必要な作業量はまったく異なります。

経路A:Grok Botに画面を操作させる。 これが目玉機能です。Grok Botは管理されたクラウドコンピューターを起動し、あなたが「Confluenceにサインインしてこのwikiを手伝って」と伝えると、ブラウザを開き、あなたは画面の受け渡しの中で認証情報を入力します。そこから先は、Confluenceをログイン済みユーザーのようにクリックしていきます。スペースを開き、ページを読み、検索し、新しいコンテンツを下書きし、既存のページを編集します。あなたのインスタンス側から見れば人間が席を使っているだけなので、Confluence側で設定する必要は何もありません。それがすべての魅力であり、すべての問題でもあり、後で戻ってきます。

経路B:Grok APIを呼び出し、自前のつなぎコードを構築する。 もう一方の経路は、Grokをワーカーではなくモデルとして扱います。自前のミドルウェアからgrok-4.6を呼び出し、Confluence REST API経由でConfluenceのコンテンツを読み書きします。これは監査可能な道ですが、自前で構築する必要があり、書き込みのセマンティクスが噛みつく可能性がある道でもあります(詳しくは後述)。始める前に知っておく価値があるのは、Confluence純正のAIはRovoであり、Grokはアトラシアンがその中で公開しているモデルの一つではないということです。つまりAPI経路は、メニューから選ぶモデルではなく、自分で書いて保守するつなぎコードです。

ほとんどのチームにとって、経路Aこそが「Confluence向けGrok Bot」の実際の意味なので、そこに最も多くの時間を割きます。

Grok Botが本当に得意なこと

批判する前に公平でありたいと思います。デザインは巧妙だからです。Grok Botは人間と同じようにUIを操作することでツールに到達しますが、これはRPAの正直な後継です。あなたのConfluenceが、誰も文書化していない何十年物のスペース、マクロ、Marketplaceアプリの迷路であるなら、単に画面を使うだけのエージェントはそれをすべて回避します。連携プロジェクトは不要です。

また、ロングテールで単発のナレッジ作業も得意です。「onboardingタグの付いたページをすべて集めて、矛盾している3つを見つけ、その対立を新しい下書きにまとめて」というのは、彼がうまくこなせるアドホックな仕事の典型です。Confluence、Slack、Google Docsの間を1つのセッション内で、何も連携させずに行き来できるからです。パワーユーザー1人のためのリサーチアシスタントとしては、その柔軟性は本物です。

そして土台となるモデルは強力です。Grok 4.6は有能な推論モデルなので、書く文章はよく読めます。問題は「よく読める」ことと「正しい」ことが別のテストであり、ナレッジベースが評価するのは後者だけだということです。セキュリティランブックへの、もっともらしいが誤った編集は、編集しないよりも悪いです。なぜなら今度はそれが権威あるものに見えてしまうからです。

実際に何に向けることになるのか

リスクの前に、対象となる範囲をイメージしておくと役立ちます。Confluence側では、経路AはあなたのスペースとページツリーをGrokがクリックして回ることを意味し、それはあなたのチームが毎日使っているのと同じビューです。

そこには、会議メモ、意思決定ログ、製品仕様、人事ポリシー、そしてオンコールのエンジニアが午前3時に開くランブックが保管されています。その多くは本当に自動化可能な整理作業ですが、同時に間違ったアクションの影響範囲が大きいコンテンツでもあります。ページの上書き、セクションの削除、あるいは誰かが後で真実として扱ってしまう中途半端な下書きの公開などです。次のセクションのために、この範囲を頭に入れておいてください。

本番のナレッジベースにとってリスクが高くなる部分

ここで「画面を使うだけ」というデザインが、メリットから負債に変わります。これはGrokというモデルが弱いという話ではありません。共有ブラウザセッションを持つ汎用ワーカーが、本番のナレッジベースにとって間違った形であるという話です。

ドライランが存在しない

xAI自身のドキュメントははっきりと述べています。「A test run performs real work. It can navigate websites, change files, and call connected tools.」つまり、Grok BotをあなたのWikiに向けて、実際に行う前に、ページ群をどう再編成または書き換える予定だったかを確認する方法はありません。共有された正典に触れるものにとって、これは圧倒的に最大のギャップです。安全な導入という規律のすべてはリハーサルにあり、この経路はいきなり初日の本番へ、チーム全員が次に読むページの上で、飛び込んでしまいます。

1台の共有コンピューター、1つの使い回されるログイン

あるユーザーのすべてのボットは、単一のクラウドコンピューターを共有しており、いったんConfluenceにサインインすると、そのセッションは持続し、他のどのボットもそれを再利用できます。xAIはドキュメントの中で2度、こう述べています。「Do not use separate Bots as a security boundary.」ボットを削除しても、そのファイルとサインインは残ります。

では、Confluenceのセッションが実際に何を保持しているか想像してみてください。Wikiは社内ポリシー、セキュリティランブック、顧客リスト、未発表の計画が住む場所であり、そこへの持続的なログインは、その席が見られるすべてのスペースへの常設の鍵です。最近のある導入では、PIIを含むコンテンツが顧客の環境内にとどまることを示せるまで、購入者のセキュリティ審査は承認を出しませんでした。共有され、常にサインインされたブラウザセッションは、まさにそうした審査が検出するために設計されている表面そのものです。ナレッジベースのデータプライバシーを気にするなら、ここから始めてください。

AIにWikiへ書き込ませることこそが恐ろしい部分

これはConfluenceに固有の仮定の話ではありません。2026年の初め、チームがアトラシアン純正のRovo MCPコネクタ経由で初めてAIアシスタントをConfluenceに向けたとき、重大な欠陥がページの内容を静かに破壊しました。更新呼び出しがページ本文全体を対象としており、タイトルだけの「リネーム」が「本文をクリアする」と解釈されてしまったため、リネームされたページはその内容が消去されました。アトラシアンはこれを認め、2026年7月1日のプレビュー修正で細かい編集を提供したので、いまは修正済みですが、教訓は残ります。本文全体を置き換えるAPIでページを編集するAIは、ドライランもレビューのステップもなければ、混乱した1つの指示でページを消してしまう距離にあります。手動でエディタを操作する経路Aも、マウスを使うだけで、まったく同じ失敗モードを持っています。

監査証跡もコンプライアンスページも、ほとんど空白のまま

Grok Botのドキュメントは、未来形で「An audit view of Bot actions is coming.」と述べています。つまり今日の時点では、なぜそのようにページを編集したのかというアクションごとの記録がなく、これは変更管理下にあるあらゆるものにとって厳しい要件です。そして席全体を使う人間としてサインインしているため、「このスペースのページだけに触れて」や「私が明示的に頼んだときだけ動いて」というきれいな指定方法がありません。承認もこのギャップを完全には埋めません。xAIのドキュメントは、承認は「controls the proposed action. It does not reverse work already completed.」と述べているからです。

その自律性の問題こそ、購入者が反発するまさにその点です。あるサポートリーダーが、私よりうまく言葉にしていました。

「AIが100%の質問に答えられるようになることは決してありませんが、もしAIが答えようとして単に『すみません、わかりません』と返すだけなら、私は7,000件のチケットすべてを確認して、AIが実際に良い回答をしたかどうかを見て回ることはできません。そうなると、そもそもの目的が少し失われてしまいます。私が必要としているのは、自信を持って対応できるチケットだけを扱い、それ以外はすべて手を出さずに残しておいてくれるAIです。」

月間約7,000件のチケットを扱うDTCブランドのCXリーダー

サインインしたワーカーには、モードが1つしかありません。それは「働く」ことです。この購入者の要件のすべては、AIがほとんどのチケットに触れないことでした。それに加えて、Grok BotはSOC 2、ISO 27001、GDPR、HIPAAのいずれも謳っておらず、保持期間も公開せず、Cursorの規約に委ねています。あなたがConfluenceにコンプライアンス文書を保管している規制業種であれば、それだけで会話は終わります。

Confluenceがすでにネイティブで提供しているもの(とその限界)

既存のプレーヤーを名指ししておく価値があります。なぜなら「GrokにConfluenceを管理させられるか」と尋ねる多くのチームは、アトラシアンがすでに提供しているものをまだ完全には有効化していないからです。Confluence純正のAIは、いまやRovoです。Wiki全体を検索するRovo Search、あなたのナレッジに質問するRovo Chat、専門タスク向けのRovo Agentsです。

問題はゲート、そしてメーターです。Rovoには Standard、Premium、Enterpriseのいずれかのプランが必要で、Rovoクレジットで課金されます。Standard、Premium、Enterpriseでそれぞれ1ユーザーあたり月25、70、150クレジットです。これは消費速度を見るまでは寛大に聞こえます。チャットのクイックな回答は10クレジット、Deep Researchの実行は100クレジットなので、Premiumの席は使い切るまでにおおよそ月7回のチャット回答分しかありません。Confluence FreeにはRovoがまったくありません。つまりネイティブな経路は本物でよく統合されていますが、席単位で価格設定され、クレジットで上限があり、アトラシアンのエコシステムの中で完結します。完全にアトラシアンに寄せているなら素晴らしい一方、チームが日常的にAIの回答に頼っている場合や、あなたのナレッジがRovoの届かないツールに散らばっている場合は、見た目より窮屈です。

誰もスクリーンショットに撮らないコストの実態

経路Aは値札の上では安く見えます。Grok Botはx.ai/botによればCursor Ultraで月額200ドル、Cursor Premium Teamsで席あたり月額120ドルです。しかしそれは席の価格であり、ワーカーへのアクセスを買うのであって、完了した仕事を買うのではありません。その上に、超過分がモデルとトークンのコストで課金される週次のAIトークン割り当ても支払うことになります。Grok Bot固有の支出上限はまだなく、これは自律エージェントにとってそれ自体がリスクです。

経路Bは2つのメーターを重ねます。GrokのAPIを支払い(grok-4.6は100万トークンあたり入力2.00ドル/出力6.00ドルで、検索やツールには通話ごとに別途料金がかかります)、さらに、あなたのつなぎコードが読み書きするConfluenceの席の料金も引き続き支払います。それはStandardプランで1ユーザーあたり月額約6.70ドルから始まります。ポイントはGrokが高いということではありません。「席の価格に加えて上限のない利用料、さらに自前の構築・保守の時間」というのは、本当に予測が難しい数字であり、サポートROIを測るときに求めているものの正反対だということです。

代替案:Confluenceを操作対象の画面ではなくナレッジとして扱う

ここで私が押したい捉え直しがあります。あなたの本当のゴールが「Confluenceから信頼できる回答を得る」ことなら、うまくいく形は、共有ブラウザを操作してページを上書きしないことを願う汎用ワーカーではありません。それは、OAuth経由でConfluenceに接続し、それをソースとして読み取り、そこから回答する、ナレッジネイティブなレイヤーです。持続的なログインもなく、書き戻しのリスクもありません。eeselが属しているのはそのカテゴリーであり、Confluence向けClaudeについて私が述べてきたのと同じ「ナレッジを接続せよ、UIを操作するな」という主張です。

具体的には、Grok Botの経路では表現できない4つのことを意味します。あなたは持続的にログインした席を引き渡すのではなく、OAuth経由で接続します。

あなたは自分自身のナレッジで学習させます。Confluenceのスペースに加えて過去のチケット、そしてオプションでNotion、Google Docs、あるいはあなたのヘルプセンターです。これにより、エージェントは学習データから即興で答えるのではなく、あなたのコンテンツに回答の根拠を置きます。あなたは本番稼働前に実際の履歴でシミュレーションします。これはあなたの過去のチケット数百件を再生し、AIの回答をチームが実際に送った内容と照らして採点するもので、顧客や同僚が関わる前に、関わった後ではなく、本当の精度の読みを得られます。そしてあなたは範囲を絞ります。まずはドラフトまたは返信専用モードで動かし、どのソースとトピックに対して行動できるかを設定し、自動化したくないものを除外し、確信度が低いときには人間へのハンドオフを任せます。

また、あちら側ではいまだに「coming」な監査証跡も手に入ります。すべての回答は、その理由づけと使用した正確なConfluenceページとともに、アクティビティログに表示されるため、AIの回答はブラックボックスではなく、レビュー可能になります。

そして、経路Bを気に入っていた理由がプログラマビリティだったとしても、それを失うことはありません。eeselは本物のターミナル面を公開しています。ドキュメントに文字通り「everything on this site can be done from the terminal」と書かれているCLI(@eesel/cli)、Claude CodeやCursorのようなコーディングエージェントが同じワークスペースを操作できるMCPサーバー、さらに自前のAPIを呼び出すためのWebhookとNetwork Accessです。これにより、スクリプトやCIからエージェントを操作し、あらゆるコマンドからJSONを取得し、何かが実行される前にeeselの--dry-runで書き込みをプレビューできます。それはまさに、Grok Botが持っていないリハーサルのステップであり、しかもあなた自身でConfluenceのつなぎコードを構築・監視する必要がありません。ダッシュボードを使おうがターミナルを使おうが、同じエージェントです。

価格設定も意図的に異なるモデルです。eeselは対応したチケット1件あたり0.40ドルの定額で、エージェントごとの席料金はなく、あなた自身が設定する厳格な月次支出上限があります。1件のチケットは、返信が1回でも5回でも1度だけ課金され、「解決」ゲームは存在しません。これは、Grokの各経路も、席単位かつクレジット制のConfluenceのAIも、どちらも実現しづらくしている、まさに実際に完了した仕事に対する予測可能な数字です。

Confluence向けeeselを試す

GrokにあなたのConfluenceを管理してほしくてここに来たのなら、正直な結論はこうです。Grok Botはデモの中でつつくことはできますが、本番のナレッジベースが必要とするドライラン、範囲設定、監査、コンプライアンスを欠いた「Early beta」の汎用ワーカーであり、API経路は本物の書き戻しリスクを伴う自前構築です。Confluence向けeeselは、実際の仕事のために作られたバージョンであり、数分でOAuth経由であなたのWikiに接続し、あなたのコンテンツと過去のチケットで学習し、誰かに回答する前に実際の履歴でシミュレーションできる、AIヘルプデスクエージェントです。

ドラフトのみのモードで開始し、自分自身の質問にどう答えるかを見て、シミュレーションの数値に納得できたときだけライブ返信を有効にできます。無料トライアルはクレジットカード不要で50ドル分の利用枠を提供し、あなた自身のConfluenceとチケット履歴に対して実際のシミュレーションを実行し、何かにコミットする前に自分の目で数字を確かめるには十分です。