ニュース & インサイト News & Insights

LiferayとAI連携を語る ── AIを入れる前に、フロントツールを決める

2026.07.02

技術

※ 本記事は、Liferay AI Hubの公開情報がまだ限られている時点での所感です。組み合わせの可能性についても現時点での構想を含むため、詳細がわかり次第、改めて加筆・修正していく予定です。

AI導入がうまくいかない。その原因を「モデルがまだ賢くないから」と考えていると、たぶん遠回りになります。実際に多くのプロジェクトを止めているのは、モデルの賢さではなく、権限・ガバナンス・既存システムとのつなぎ込みのほうです。

だから本当は、「どのAIを使うか」より先に決めておいたほうがいいことがあります。AIを“どこから使わせるか”、つまりフロントです。この記事では、AIを実務で使える形にするための土台を整理し、その上で現場が具体的に何が変わるのかまでを見ていきます。

増えるAIを、ひとつの土台で管理する

ここ数年、企業のAI活用は「足し算」で進んできました。ここにチャットボット、あそこに要約機能、別の部署では翻訳ツール。一つひとつは便利なのですが、部署ごとにバラバラに増えていくと、権限の抜け漏れやコストの重複が、見えないところで静かに溜まっていきます。気づけば社内に似たようなAIツールが三つも四つも、という話は珍しくありません。

この流れに対してLiferayが出してきたのが、AI Hubです。ローコードでAIエージェントを作り、配備し、管理するための土台で、特徴的なのは特定ベンダーのモデルに縛られない設計になっていること。AnthropicでもGoogleでもOpenAIでも、必要なモデルをつないで使い、後から差し替えることもできます。

ポイントは、AIを「単発の機能として足す」段階から、「複数のAIをひとつの場所でつくって統治する」段階へと移ってきた、ということです。個別の機能の便利さを競う時期はそろそろ終わりで、これからは“どう束ねて運用するか”が問われます。

フロントにLiferayを置くと、裏のAIを差し替えられる

ここで効いてくるのが、ポータルをAIの「前面」に置くという発想です。

利用者がAIサービスを直接叩く運用だと、モデルを変えるたびに、利用者側の使い方や連携をつくり直すことになります。これは地味に重い。一方、ポータルを前面に置けば、利用者から見える入口は変わらないまま、裏側のモデルだけを世代交代させられます。ポータルが、体験とAIを切り離す“抽象化レイヤー”として働くわけです。

AIの進化は速く、半年で勢力図が変わります。今日のベストが来年もベストとは限らない。だからこそ、「どのモデルにも乗り換えられる入口」をあらかじめ持っておくことは、それ自体が投資の保険になります。

権限と監査が、そのまま効く

もうひとつ、企業にとって見逃せないのが権限と監査です。

AI Hubのエージェントは、認証されたポータル利用者の“代理”として動きます。つまり、その人が見てよいデータにしかアクセスしない。同じ質問を投げても、一般社員と役員では返ってくる答えの範囲が変わる、ということです。さらに、すべてのやり取りは監査証跡として記録され、機微な情報は自社の環境のなかに留まります。

「AI用にガバナンスを一からつくり直す」のではなく、何年もかけて積み上げてきた既存の権限・監査の仕組みを、そのままAIに被せられる。エンタープライズでAIが頓挫する一番の難所がここなので、この一点だけでも導入のハードルは大きく下がります。

データを外に出せないなら、オンプレでも動くAIを

ここまでが「フロント側」の話です。その裏側に置くAIにも触れておきます。

製造業の図面、医療データ、契約書、人事情報。クラウドの生成AIに「とりあえず全部投げる」ことができない企業は、実際にはかなり多いものです。規制、取引先との契約、社内ルール。理由はさまざまですが、結論は同じで、機微なデータは自社の外に出せない。

そこで必要になるのが、自社の環境のなかで動かせるAIです。弊社で取り扱っているArticul8は、まさにそうした、企業の環境内(オンプレミス)で動かせるAIプラットフォームです。データが施設の外に出ない前提のまま、AIの推論をその場で回せます。

そして、扱う内容に応じてAIの置き場所を選べるのも利点です。機微なデータは自社環境内(オンプレ)で、外に出して構わない汎用的なタスクはクラウドの高性能モデルで。同じポータルの裏側で、内容ごとに適切なAIへ振り分けられます。利用者から見える入口はLiferayひとつ。その裏で、Liferayがフロントとガバナンスを受け持ち、Articul8のようなAIが推論を受け持つ——役割分担が、きれいに分かれます。

ここまでが、AIを実務で使うための土台です。増えるAIをひとつの土台で管理し、裏のモデルはいつでも差し替えられ、既存の権限と監査がそのまま効き、データを外に出せない場合はオンプレで動くAIを同じ入口の裏に置く。どれも、フロントとガバナンスをポータルで持つことから生まれます。では、この土台の上で、AIは実際にどう“深く”考え、現場の何が変わるのか。ここからは具体的に見ていきます。

“似た言葉を探す”のではなく、“関係をたどる”

ひとつ、誤解を解いておきたいことがあります。社内データを使うAIというと、「質問に似た言葉や文章を探して貼り付ける」仕組みだと思われがちです。

実際、一般的な手法は、文書を細切れにして、質問に“似た断片”を引いてきます(これはいわゆる一般的なRAG〈検索拡張生成〉の考え方です)。便利ではありますが、関係をたどるのが苦手です。たとえば「この条項を過去に受け入れた契約をすべて挙げて」「A社で却下した理由は、B社の例外承認とどう繋がっているか」といった問いには、うまく答えられません。似た文章は出せても、点と点の“つながり”を追えないからです。

Articul8は、契約・顧客・条項・製品といった要素(エンティティ)と、その間の関係を、あらかじめ“知識のグラフ”として組み立てておきます。これが効いてくるのは、ひとつの問いに答えるのに複数の事実を順につなぐ必要があるときです。たとえば「この条項の変更 → 責任上限に関係する → その規制でA社では却下された → だがB社はこういう事情で例外が認められた」というように、いくつもの段を連ねて結論にたどり着く。この“複数の段を踏む”推論を、マルチホップ推論と呼びます。似た文章を一回引くだけ(いわば一段)では届かない問いに、関係を一歩ずつたどって答えられる、というわけです。グラフという構造を持っているからこそ、辿れるし、根拠も追える。ただ回答するだけでなく、なぜその回答が出てきたかまでがわかるのです。

さらにArticul8は、文章だけでなく、図面・スキャン・表・画像といった複数の形式をまたいで扱えます(マルチモーダル)。「関係をたどれる」「形式をまたげる」。この二つが、これから挙げる実務の問いに効いてきます。

時計と頭脳 ── ルールとAIの役割分担

「AIが先回りしてくれる」と聞くと、何もかもAIがやっているように見えますが、実際は二人三脚です。

ひとつはルール(イベント駆動)。これは“いつ動くか”を決める時計の役割です。日付が来た、ステータスが変わった、といった機械的なきっかけで発火します。もうひとつがAIの推論。こちらは“何をするか”を決める頭脳で、解釈したり、判断したり、文章を組み立てたりします。

契約更新を例にしましょう。ルールだけなら「満了の90日前に、定型の更新案内を送る」で、全顧客に同じ対応です。ここにAIの推論を足すと、その顧客の利用状況や過去のやり取りを読み、解約しそうかを見立て、その顧客向けの提案をつくり、値引き要求が来そうなら営業に先に知らせる。きっかけは同じ「90日前」でも、出てくる中身がまるで変わります。

“いつ”動くか(時計)と、“何を”するか(頭脳)。この二つを分けて考えると、設計がぐっと整理されます。

取引先に「先回り」する

取引先・顧客向けのポータルで効いてくるのが、この先回りです。

たとえば更新の先回り。満了が近づくと、その顧客向けの更新案をあらかじめ準備して差し出す。あるいはネクストベストアクション。購買履歴や利用状況から、次に役立ちそうな製品や資料を、聞かれる前にそっと提示する。さらにはつまずきの検知。操作に手間取っている様子を捉えて、問い合わせが来る前にヘルプを出す。

大事なのは、これらが「AIが勝手に賢いから」できるわけではない、という点です。信頼できる社内データ──契約、履歴、在庫──に根ざしたAIが、決められたきっかけに反応して、具体的な行動を起こす。だからこそ、出力が当てずっぽうにならない。先回りの精度は、つないだデータの確かさで決まります。

リーガル・コンプラの一次スクリーニング

社内向けで、地味ながら確実に効くのがここです。

ひとつは契約変更の前例チェック。営業が顧客から条項の変更を頼まれたとき、いきなりリーガルに回すと時間がかかります。その前に、AIで一次回答を出す。「過去に似た変更が受け入れられたか、それとも可能性はゼロか」。たとえば「過去◯件で受諾、平均△日で合意」あるいは「前例なし、却下理由は責任上限条項」。これがその場でわかるだけで、その後の交渉が段違いにやりやすくなります。

ここでこそ、先ほどの“関係をたどる”力が活きます。「この条項が、誰に、どんな条件で、どんな結果で受け入れられたか」は、まさに関係を何段も辿って初めて答えが出る問いだからです。

もうひとつは、ロゴやブランドの事前チェック。マーケティングが用意した共同ブランディングの素材が、ブランドポリシーに沿っているか。配置や余白、色を画像として見て照合し、明らかな違反を一次スクリーニングではじく。文章だけでなく画像を扱えるからこそできることです。

どちらも、最終判断はあくまで人間です。リーガルが、ブランドチームが、最後は目を通す。AIがやるのは、そこに至るまでの下調べと一次的な振り分け。最終決定をAIに委ねるのではなく、人が判断する前の作業を肩代わりさせる。この線引きこそが、安心して使えるかどうかの分かれ目です。

まとめ ── AIを“使える形”にするのはフロント

ここで挙げた先回りや一次スクリーニングは、賢いAIさえあれば実現するものではありません。社内データにつなぎ、利用者ごとに権限を効かせ、誰もが迷わず使える入口に載せて、はじめて現場で回りはじめます。

つまり、AIを“使える形”にするのは、フロントです。AIを入れたい企業ほど、AIそのものを選ぶ前に、フロントをLiferayでどう設計するかを考える。遠回りに見えて、この順番が、いちばん確実な近道になります。

最後までお付き合いいただき、ありがとうございました。