SimpplrのAIは誰が止める？｜機能とLLMを選ぶ線

「社内ポータルのAIは製品に付いてくる機能だから、使うか使わないかだけ決めればいい」「でも全部止めたら、社員はまた別のAIに社内の文書を貼り付けるのでは」——社内ポータルの入れ替えや更新を担う情報システムの部門で、よく聞く二つの声です。前者は手間を減らしたい気持ち、後者は抜け道を心配する気持ちで、どちらにも理由があります。ただ、ポータルのAIは一つの機能ではありません。検索の回答、文章の下書き、要約、社員向けのエージェントと機能ごとに外へ出るものが違い、どのLLMを誰の契約で動かすかまで決めないと、止めたいときに止められません。この記事では、米国の社内ポータル Simpplr の AI Control Center を例に、情シスが機能とLLMを選び、記録し、止める線を整理します。

Simpplr は、AIを組み込んだ米国の社内ポータル

Simpplr は、社内のお知らせ、規程や手順の文書、社員名簿、各種の申請の入口を一つにまとめる社内ポータル（イントラネット）の製品です。2026年10月時点の公式サイトは、自らを「AIを組み込んだ社内ポータル」と呼び、社内の連絡、社内検索、AIによる手助けを一つの体験にまとめると説明しています。

AIの機能は大きく四つに分かれます。一つ目は検索で、社内の文書とつないだ外部の仕組みを横断して探し、上位の結果を生成AIで要約して答えを返します。二つ目は社員向けのエージェントで、会話で質問に答えるだけでなく、休暇の申請や問い合わせの起票など、つないだ業務の仕組みへの操作まで行うとされています。

三つ目は文章の手助けで、社内広報の担当がお知らせを書くときに、口調に合わせた下書き、話題の提案、配信の工夫を出します。四つ目は内容の鮮度の管理で、公式のよくある質問によると、古いものや確認されていないものを自動で保管庫へ移し、AIが新しく信頼できる文書だけから答えるようにする仕組み（オートガバナンス）があります。

加えて、公式のAIのページは、プログラムを書かずに独自のエージェントや操作を作れる部品（エージェントスタジオ）を挙げています。社内の担当者が自分でエージェントを作れるということは、情シスが知らないところで、業務の仕組みに書き込むエージェントが増えうるということでもあります。誰がエージェントを作ってよいかも、AI機能をどう許すかと同じ場で決めておく必要があります。社内ポータルをどう作り直せば使われるかという入口の設計は、別の記事で扱っています。本稿は、ポータルにすでに組み込まれているAIの機能を、情シスがどう選び、どう止めるかに絞ります。

作っている会社と、国内でまだ知られていない理由

Simpplr の会社ページでは、創業者で最高経営責任者のディラージ・シャルマ氏と、共同創業者で最高技術責任者のピユシュ・ラージプート氏が紹介されています。資金の面では、複数回の調達で累計1億3,100万ドルを超えると記され、出資者として複数のベンチャーキャピタルと Salesforce の投資部門が並んでいます。2026年5月の報道発表はカリフォルニア州レッドウッドシティの日付で出ています。

報道発表によると、1,000を超える組織が利用し、英国の国民保健サービス（NHS）などの名前が挙がっています。公式サイトは調査会社による評価も掲げており、米国と欧州の大きな組織の社内ポータルとして使われている製品だと分かります。

国内でまだ知られていない理由は、確かめた範囲で三つあります。一つ目は、公式サイト・報道発表・資料が英語だけで、日本の顧客や国内の窓口への言及が見当たらないことです。二つ目は、国内の社内ポータルは、グループウェアに付いた掲示板や、マイクロソフトの共有サイトで済ませる会社が多く、専用の社内ポータル製品を別に買う文化がまだ薄いことです。

三つ目は言語です。公式のヘルプによると、日本語は対応言語の表に入っており、画面の文言は翻訳され、利用者が書いた記事は機械翻訳で読めます。一方で、検索の回答やエージェントが日本語の文書でどこまで正しく答えるかは、公式の資料では確かめられませんでした。国内で使うなら、最初に提供元へ確かめ、試行で確かめる項目です。

2026年10月時点のAI機能と、AI Control Center でできること

Simpplr は2026年5月27日に、AI Control Center を発表しました。報道発表は、IT管理者がポータルのすべてのAI機能、提供元、設定を一か所で統制する管理画面だと説明しています。公式のAIのページとあわせて、確かめた範囲を表にまとめます。

項目	中身（公式で確かめた範囲）
全体のオン・オフ	ポータル全体のAIを一か所で有効・無効にする
機能ごとの切り替え	検索の回答、社内広報のエージェント、文章作成の手助け、アプリのタイル作成、要約などを一つずつ有効・無効にする
機能ごとのLLMの選択	提供元が試験・検証したLLMの提供元から選ぶ。機能ごとに口調と長さの指示も設定できる
自社の契約の経由	要求を自社の Azure か Google Gemini の法人契約を通して流す。報道発表はデータの所在や取引先の要件がある組織向けと説明
監査ログ	設定の変更を時系列で記録し、誰がいつ変えたかを残す
データの扱い	顧客のデータは外部・公開の基盤モデルの学習に使わないと記載。保存場所の地域と保存期間の記載はない

報道発表は、AI Control Center を「Simpplr のプラットフォームの一部として提供」と書いており、ベータや早期提供の表記は見当たりませんでした。ただし、製品が選ぶ既定のLLMの名前や、自社の契約でつなげる先の範囲は公式の資料に書かれていません。契約の前に、自社の版でどの機能が切り替えの対象になるかを提供元に確かめてください。

CEO のシャルマ氏は発表の中で、AIを使えるようにすることと統制することのどちらかを選ぶべきではない、という趣旨を述べています。提供元が委託した調査会社の調査として、IT責任者の78%がAIを安全に広げるにはより良い安全の枠組みが要ると答えた、という数字も添えられています。これは提供元が委託した調査の数字で、国内の状況にそのまま当てはまるものではありません。

「AIはおまけだから二択でよい」が危うい理由

社内ポータルのAIを二択で決めたくなるのは自然なことです。ポータルは全社員が毎日開く場所で、細かく設定すればするほど、問い合わせと保守の手間が増えるからです。

ところが、全部許すと決めた場合、検索の回答は人事の規程を要約し、エージェントは申請の仕組みに書き込み、文章の手助けは社内広報の下書きを作ります。一つの「許可」の中に、触る文書も間違えたときの重さも違う機能がまとめて入ってしまいます。後から一つだけ問題が見つかっても、全部を止めるしかなくなります。

逆に全部止めると決めた場合、社員は社内の文書を探すのに苦労し、手元の生成AIに規程や議事録を貼り付けて要約させるようになりがちです。ポータルのAIを止めたことで、統制の効かない場所にデータが流れるという逆の結果になりかねません。

ソフトの更新でAIの機能が知らないうちに有効になる問題と、それに気づく仕組みは、別の記事で扱っています。本稿は、気づいた後に、どの機能を許してどのLLMで動かすかを選ぶ段階の話です。

機能ごとに、外に出るものと間違えたときの重さが違う

機能ごとに分けて判断する理由は、機能ごとにLLMへ渡るものが違うからです。検索の回答では、検索で当たった文書の断片と社員の質問が渡ります。文章の手助けでは、広報の担当が書きかけている下書きが渡ります。要約では、記事やページの本文が渡ります。

社員向けのエージェントは、さらに一段重くなります。公式の説明では、エージェントは業務の仕組みに直接つながり、申請の提出や記録の更新まで行います。答えを返す機能と、業務の仕組みに書き込む機能は、同じ「AI機能」でも別の判断が要ります。

間違えたときの重さも違います。広報の下書きの誤りは、公開前に担当者が読めば止まります。検索の回答の誤りは、社員がそれを信じて動けば、手続きの誤りにつながります。エージェントの誤りは、申請や記録の書き換えとして残ります。

このため、機能ごとの判断は「何が渡るか」と「誤りがどこで止まるか」の二つで考えると整理しやすくなります。人が読んでから外に出る機能は早めに許し、答えや操作がそのまま社員に届く機能は後から許すのが、多くの会社にとって無理のない順番です。

誰の契約でLLMを動かすか

AI Control Center のもう一つの柱が、LLMの選び方です。報道発表によると、管理者は提供元が試験・検証したLLMの提供元から選ぶか、自社の法人契約を経由して要求を流すかを選べます。公式のAIのページは、自社の契約の例として Azure と Google Gemini を挙げています。

製品が選んだLLMで動かす場合、LLMの提供元との契約は Simpplr が持ちます。自社は Simpplr との契約の条件だけを見ればよく、手間は少なくて済みます。その代わり、LLMの提供元とのデータの扱いの条件は、Simpplr を通した間接的な約束になります。

自社の契約を経由する場合、LLMの提供元との契約は自社が持ちます。すでに全社で Azure や Google の法人契約があり、データの所在地や保存の条件を自社で交渉済みなら、その条件の中でポータルのAIを動かせます。報道発表も、データの所在や取引先の要件が厳しい組織向けだと説明しています。

どちらが正しいということはありません。決め手は、自社の生成AIの利用の決まりが、契約の主体をどこまで求めているかです。社内の決まりで「生成AIは自社が契約した提供元だけ」と定めているなら、自社の契約を経由する道しか取れません。社内AIの窓口を共通の基盤にするか、各社の法人版にするかの選び方は、別の記事で扱っています。

三つの道を、4つの軸で比べる

ここまでの論点を、三つの道に整理して比べます。軸は、外に出るもの、費用の増え方、止め方、監査の残り方の四つです。

道	外に出るもの	費用の増え方	止め方	監査の残り方
ポータルのAIを全部止める	ポータル経由では出ない。社員が手元のAIに貼る分は見えなくなる	AIの費用はかからない。探す手間は残る	全体のオフのまま。再開の判断が要る	止めたという設定の記録だけ
製品が選んだLLMで機能ごとに許す	許した機能の入力と参照した文書の断片が、提供元が選んだLLMへ	製品の契約の中。機能や利用者を増やすと契約の見直しが要る可能性	機能ごとのオフ、全体のオフ	設定の変更はポータルの監査ログ。LLM側の記録は自社から見えにくい
自社の契約のLLMにつないで機能ごとに許す	許した機能の入力と断片が、自社が契約したLLMへ	製品の契約に加え、LLMの利用量の費用が自社の契約で増える	機能ごとのオフ、全体のオフ、自社の契約側での停止	ポータルの監査ログに加え、自社の契約側の記録も持てる

表の下の道ほど、自社が持つものが増えます。データの扱いの条件を自分で決められる代わりに、LLMの利用量の費用と、契約側の管理の手間を自社で持つことになります。費用は社員の数よりも、許した機能がどれだけ使われるかで増えます。

料金の体系は公式サイトで確かめられませんでした。報道発表や公式のAIのページにも、AI機能の追加の費用の記載はありません。どの道でも、見積もりの段階で、機能を一つ増やしたとき・利用者が増えたときに費用がどう動くかを提供元に確かめておきます。

道1：ポータルのAIを全部止める

全部止める道が合うのは、社内の生成AIの利用の決まりがまだ整っていない会社や、ポータルの文書の整理が追いついておらず、AIが古い規程を答える恐れが大きい会社です。決まりと文書が整うまでの一時的な選び方としては、十分に合理的です。

気をつけたいのは、止めている間の社員の動きです。ポータルで探せないまま、手元の生成AIに社内の文書を貼る社員が増えると、止めたつもりが、統制の効かない使い方を増やしていたということになります。止める期間には、社内で使ってよい生成AIの窓口を案内しておきます。

もう一つは、再開の条件を決めておくことです。「文書の整理が終わったら」「利用の決まりが承認されたら」など、何がそろえば一部を許すかを書いておかないと、全部止めたまま何年も経ちます。

道2：製品が選んだLLMで機能ごとに許す

製品が選んだLLMで機能ごとに許す道は、多くの会社にとっての出発点です。LLMの契約を自社で持たずに済み、AI Control Center で機能ごとにオンとオフを切り替えられるので、許す範囲を小さく始められます。

この道で確かめるのは、製品の契約の中でのデータの扱いです。公式のAIのページは、顧客のデータを外部・公開の基盤モデルの学習に使わず、安全な環境の中で処理すると書いています。一方で、どのLLMの提供元に、どの地域で処理されるか、記録がどれだけ残るかは公式の資料に書かれていないため、契約の前に提供元に書面で確かめます。

許す順番としては、広報の文章の手助けと記事の要約から始めるのが無理がありません。どちらも人が読んでから外に出る機能だからです。検索の回答は、文書の鮮度の管理が回り始めてから許し、業務の仕組みに書き込むエージェントは最後に許します。

道3：自社の契約のLLMにつないで機能ごとに許す

自社の契約のLLMにつなぐ道は、すでに全社で Azure か Google の法人契約を持ち、生成AIのデータの扱いを自社の契約で統一している会社に向きます。ポータルのAIも、ほかの社内AIと同じ条件の中で動かせます。

この道では、費用と管理の担い手が増えます。ポータルの契約とは別に、LLMの利用量の費用が自社の契約で発生します。利用の上限や予算の警告を、自社の契約側で設定しておくことが、費用が急に増えるのを防ぐ手立てになります。

もう一つの利点は、止め方が二重になることです。ポータルの管理画面で機能を止めるほかに、自社の契約側でポータルからの接続を止めることもできます。ポータルの管理者と契約の管理者が別の部門なら、どちらが止める判断をするかを決めておかないと、二重の止め方がかえって混乱のもとになります。

規程と人事の断定的な回答をさせない線

どの道を選んでも、検索の回答とエージェントに断定させない領域を決めておきます。代表は、就業規則や給与・評価の規程、休職や異動などの人事の手続き、法令の解釈です。

公式のAIのページは、AIは社員に影響する自律的な決定をしない、AIが作った内容には表示が付く、重要な連絡は公開前に人の承認が要ると書いています。ただ、これは製品の側の約束です。答えてよい範囲と断定させない範囲は、自社の人事と法務が決める必要があります。

• 就業規則の古い版がポータルに残ったまま検索の回答を許し、AIが改定前の条件で答える
• 給与や評価の扱いについて、AIの要約を社員が規程の正式な解釈だと受け取る
• 休職の申請をエージェントに任せ、事情の確認が必要な案件まで自動で受け付ける
• 広報の下書きの機能を許したのに、公開前の承認の手順を決めないまま全社に配信する
• 人事の文書の置き場所を検索の対象から外さないまま、回答の機能を全社に開く

どれも、AIの答えの質の問題ではなく、答えてよい範囲を決めなかったことで起きる失敗です。規程や人事の問いには、AIは該当する文書の場所を示すまでにとどめ、判断は担当部署に回す線を、回答の機能を許す前に決めておきます。社員ごとに見える文書の範囲（検索の権限）の設計は、別の記事で扱っています。

監査ログに残るものと、残らないもの

AI Control Center は、設定の変更を時系列の監査ログに残し、誰がいつ変えたかが分かるとされています。どの機能を誰がいつ有効にしたか、どのLLMに切り替えたかを後から確かめられるのは、統制の上で大きな利点です。

一方で、設定の変更の記録と、社員がAIに何を聞きAIが何を答えたかの記録は、別のものです。公式の資料からは、問いと答えの記録がどこにどれだけ残り、誰が読めるかまでは確かめられませんでした。社内の調査や問い合わせの対応で答えの記録が要るなら、提供元に確かめておきます。

自社の契約のLLMにつなぐ道を選べば、LLMの側の利用の記録を自社の契約で持てる可能性があります。ただし、ポータルのどの社員の要求かが契約側の記録で分かるかは、つなぎ方によります。法人向けの生成AIの製品ごとの監査ログの取り出し方は別の記事にまとめているので、ここでは設定の記録・問いと答えの記録・LLMの利用の記録の三つを分けて、どこに残るかを書き出しておくことを勧めます。

止め方を3段に分けて決めておく

止め方は、入れる前に3段に分けて決めておきます。1段目は、一つの機能だけを止めることです。検索の回答が古い規程を答えた、要約が誤っていた、というときに、その機能だけをオフにします。

2段目は、ポータル全体のAIを止めることです。データの扱いの約束に疑いが出た、LLMの提供元で事故が起きた、というときに使います。3段目は、自社の契約のLLMにつないでいる場合の、契約側での接続の停止です。段ごとに、止める判断をする人と、止めたことを社員に知らせる人を名前で決めておきます。

止めた後に戻す条件も決めます。原因が分かり、文書や設定を直した記録が残り、責任者が承認したら戻す、という流れです。監査ログで「誰がいつ止め、誰がいつ戻したか」が残ることを確かめておくと、後から説明がしやすくなります。

導入の前に決める順番

ここまでを、導入の前に決める順番として並べます。設定の操作は製品の版で変わるため、ここでは社内で決める項目だけを挙げます。

この順番で決めておくと、AI Control Center の画面を開いたときに、どのスイッチを入れるかで迷いません。スイッチの数だけ、社内で決めた理由が一行ずつある状態を目指します。

AIに任せる工程と、人が決める工程

最後に、ポータルのAIで任せてよいことと、人が持つことを分けておきます。左にAI、右に人という一覧でなく、人が持つことを確かめる形で並べます。

• 有効にする機能の選択と、その理由の記録は、情シスと業務部門の責任者が持っているか
• 使うLLMと契約の主体（製品の選択か自社の契約か）を、利用の決まりに照らして決めたか
• 規程・人事・法令の問いに断定させない線を、人事と法務が決めたか
• 検索・要約・下書き・古い記事の検出はAIに任せ、公開と判断は人が行う流れになっているか
• 広報の下書きの公開前に、人の承認が入っているか
• 機能ごとの停止・全体の停止・契約側の停止の判断者が名前で決まっているか
• 設定の変更の記録を、月に一度は誰かが読んでいるか

古い記事の検出と保管庫への移動は、AIに任せると効果の大きい仕事です。ただし、何を正式な文書とするかを決めるのは、文書の持ち主の部署です。自動で移された文書の中に現役の規程が混ざっていないかを、持ち主が月に一度など決まった周期で確かめる手順を置いておきます。

よくある質問

AI Control Center は追加の契約が要りますか

報道発表は、Simpplr のプラットフォームの一部として提供すると書いています。料金の体系や、版によって使える機能の違いは公式の資料で確かめられなかったため、契約の前に提供元に確かめてください。

日本語の文書で検索の回答は使えますか

公式のヘルプでは、日本語は画面と投稿の翻訳の対応言語に入っています。検索の回答やエージェントの日本語の品質は確かめられなかったため、自社の規程や手順の文書を使った試行で確かめてから許すかを決めてください。

製品が選んだLLMと自社の契約、まずどちらで始めるべきですか

社内の利用の決まりが契約の主体を求めていなければ、製品が選んだLLMで機能を絞って始めるのが手間の少ない道です。自社の契約に限るという決まりがあるなら、最初から自社の契約を経由する道を選びます。

社員ごとに見える文書の範囲はどう決めればよいですか

公式の説明では、役割にもとづくアクセス制御で、見る権限のある答えだけが返るとされています。検索の権限の設計は本稿の範囲を外れるため、社内検索の権限を扱った別の記事を参考にしてください。

まとめ

Simpplr の社内ポータルのAIは、検索の回答、文章の手助け、要約、社員向けのエージェントと、外に出るものも誤りの重さも違う機能の集まりです。2026年5月に発表された AI Control Center で、情シスは機能を一つずつ有効にし、製品が選んだLLMか自社の Azure・Google Gemini の契約かを選び、設定の変更を監査ログに残せます。選ぶときは、全部止める・製品のLLMで機能ごとに許す・自社の契約のLLMで機能ごとに許すの三つを、外に出るもの・費用の増え方・止め方・監査の残り方で比べる。人が読んでから外に出る機能から許し、規程と人事の断定はさせない。検索・要約・下書き・古い記事の検出はAIに任せ、機能の選択・LLMと契約の決定・断定させない線引き・止める判断は人が持ってください。

• 製品の機能と提供の状態は、Simpplr の公式サイト（ホーム・AIのページ・会社ページ）、2026年5月27日の報道発表、公式ヘルプの対応言語のページを2026年10月26日に確かめた範囲に基づきます
• 既定のLLMの名前、データの保存場所の地域と保存期間、問いと答えの記録の扱い、料金の体系、AI機能の日本語の品質は公式の資料で確かめられなかったため、契約の前に提供元に直接確かめてください

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