はじめに こんにちは！ BASEでバックエンドエンジニアをしている、かがの（ @ykagano ）です。 昨年まではCartチームにいたのですが、今年から部署名が変わりまして、現在はCheckout Reliabilityチームにいます。 これはBASEのECカートの信頼性を守るためのチームです。 決済の安定性を高めるために日々活動をしていますが、それについてはまた別の記事で書かせてください。 さて、QRコード決済サービスとして日本で一番シェアの大きいPayPayといえば、皆さまもご存知かと思います。 今回は、2026年1月28日にサービスリリースしたこのPayPay導入についてお話しさせていただきます。 BASEはなぜ決済手段を増やすのか まずBASEがなぜ決済手段を増やすのかですが、そもそも決済手段が増えるとどういう良いことがあるのかからお話ししたいと思います。 ECにおいて購入体験の中で最も重要なポイントのひとつが「決済」です。 商品を見つけてカートに入れても、最後の支払いでつまずいてしまうと、その時点で購入は完了しません。 特に近年はクレジットカードだけでなく、QRコード決済や後払いなど、ユーザーごとに「普段使っている支払い方法」が多様化しています。 そのため、ショップ側が対応している決済手段が少ないと、それだけで購入機会を逃してしまう可能性があります。 SBペイメントサービス株式会社による「決済手段のEC利用実態調査結果」でも、「よく利用する決済手段がない場合、男女ともに約6割が購入せず離脱する」という結果になっています。 www.sbpayment.jp ECサイトで物品もしくはデジタルコンテンツ・サービスを支払う際に、よく利用する決済手段がない場合どうするかを尋ねたところ、男女ともに56.5％以上が、そのECサイトでは購入せず離脱する傾向にあることが分かりました。また、そのうち44.8％以上※2の人は他のECサイトもしくは実店舗で購入する意向があることから、購買意欲が高い人でも決済手段の不足が要因で離脱しており、ユーザーのニーズに応じた決済手段を取りそろえることは購買率を上げる重要な要素であると言えます。 つまり、決済手段を増やすことは単に「選択肢を増やす」というだけではなく、ユーザーが安心して購入を完了できる環境を整えることにつながります。 これはショップオーナーにとっては購入率の向上につながり、BASEにとってもより多くの取引を支える基盤を強化することになります。 今回PayPayがBASEに導入されたことは、こうした背景からも多くのショップ様にとって望まれていた機能追加だったと考えています。 BASEでのPayPay導入方法 PayPayは「BASEかんたん決済」に追加される形で提供されます。 PayPayを利用するには、この「BASEかんたん決済」の利用申請が必要です。 「BASEかんたん決済」の利用申請をもとに、PayPayで審査が行われます。 その後、可決された場合はPayPayを利用開始いただけます。 なお決済手数料は 4.6% + 40円 です（グロースプランの場合、決済手数料は 3.9% のみ）。 これは既存のAmazon Pay や PayPal決済と同じ決済手数料となります。 その他、詳細については下記ヘルプページをご参照ください。 help.thebase.in BASEでの支払い方法 BASEのカート画面で支払い方法に「PayPay」を選択して、購入完了ボタンを押していただく形となります。 その後、「PayPay」の手続き画面に遷移しますので、「PayPay」アプリで認証・支払いすると、BASE側に自動で戻り、購入が完了します。 PayPayは現在、BASEのWebショップのみが利用可能となっていまして、Pay IDアプリには未対応となります。 またPayPayで支払いが可能な商品は通常商品のみとなっており、デジタルコンテンツや予約販売や抽選販売など、通常商品以外の商品には利用できないようになっていますのでご注意ください（取り扱いについては今後変更になる場合があります）。 その他、詳細については下記ヘルプページをご参照ください。 help.thebase.in PayPay導入の開発について PayPayの導入はService Reliabilityチーム（以降SRチーム）にて開発いただいてます。 私自身はPayPay導入の開発に直接関わっていたわけではないのですが、導入後のカートシステムの運用を行う前提で設計や実装レビューに入らせていただきました。 今回BASEにPayPayが導入されることになり、システムの開発が始まったのが、2025年10月8日になります。この日に開発メンバーでキックオフを行い、設計を始めていきました。 実装にはPayPayのスマートペイメント機能を利用しています。 初回はユーザーの連携が必要ですが、2回目以降は同じ端末からの操作であれば再度連携せずに支払いをすることができます。 詳細はPayPayの公式ドキュメントをご参照ください。 developer.paypay.ne.jp PayPayはクレジットカード決済とは異なり、ユーザー操作後にBASEとは非同期で決済結果が確定するフローを含んでいます。 そのため「決済をいつ確定させるか」「どの状態をもって成功とみなすか」を慎重に設計する必要がありました。 今回は「注文が完了した時には決済も確定している」というBASEの体験を維持するために、PayPayの画面で決済をしたあと、BASEの画面に戻ってきた後にPayPayの決済結果が正常に完了していることを確認してからBASEに注文を作成するようにしました。 BASEでは複数の決済手段を扱っているため、特定の決済に依存しすぎない形での実装が求められます。 PayPayも既存の決済と同じインターフェースに乗せることで、カート・注文・発送といった関連機能への影響を最小限に抑えています。 私がレビューをしている中で特に意識したのは、「PayPay側で一時的な障害が発生しても、注文や決済状態が不整合を起こさないこと」です。 この辺りは特に注意してレビューをさせていただきました。 もし何らかの原因によって決済が失敗した場合も不整合が起こらない仕組みとなっておりますので、安心してご利用いただければと思います。 おわりに 開発期間としては約3ヶ月でリリースすることができたのですが、これほど早くリリースできたのもSRチームの皆さまの頑張りのおかげです。 本当にありがとうございました。 PayPay決済はまだBASEで開始したばかりですが、今後利用数、利用率ともに高くなるものと思いますので、より安定的に運用できるように改善を重ねていきます。 BASEではこうした決済の仕組みにも関わっていけますので、ご興味がありましたら採用情報をぜひご覧ください。 binc.jp

はじめに NTTデータの奥村です。今回は私が実際にやってしまったOCI（Oracle Cloud Infrastructure）での高額請求を受けてしまった失敗事例について紹介したいと思います。正直まだ傷は癒えてないのですが、記事にして執筆することで気を紛らわせたいと思います。私のような失敗をしてしまう方が少しでも少なくなればと願ってやみません。 ! 本件は私個人の過失であり、OCIには何ら過失はございません。その前提で記事をご覧ください。 背景 まずは少し背景について述べたいと思います。OCIでは、他のハイパースケーラー（Amazon Web Services（AWS）、Az

「AIアシスタントに任せよう」、そんな言葉が日常的に使われる時代がやってきました。 例えば、PerplexityとPayPalが提携し、AIが「探す→比べる→支払う」までをつなぐエージェント型コマースを実装するとされ、個人の買い物体験がチャット完結に近づいています。また、2024年には企業のAI導入率が70%を超え、AIは単なる便利ツールから共に考え働くパートナー、同僚という位置にへと変化しています。 その背景には「LLM」「RAG」「Agentic」「MCP」「A2A」といった進化の階段があります。本記事では、それぞれがどのように繋がり、未来を形作っているのかを整理します。 後半に、Elasticが、AI時代の波にどのように対応し、進化してきたのかについて軽く見ていきます。 目次 発射台「LLM（大規模言語モデル）」 意味を扱う「ベクトル＆セマンティック検索」 外部知識を統合する「RAG」 自律的に動く「エージェント」 連携を統一する「MCP」 MCPを使う意味 AI同士が協力する「A2Aプロトコル」 なぜA2Aが重要？ Elastic と AI まとめ 発射台「LLM（大規模言語モデル）」 LLMは、与えられた文脈から統計的に「次に来そうな単語」を選ぶことで文章を生成します。つまり、「理解している」のではなく、膨大な学習データの中から最も自然な応答を選び出している仕組みなのです。 GPT‑4o、Claude 3.5 Sonnet、Gemini 1.5 Proなど最新のモデルは、テキストに加えて画像や音声にも対応するマルチモーダル機能を備えています。この進化により、人と自然に対話でき、複雑な状況や文脈も鋭く捉えるようになりました。 ただし、LLMには限界があります。単体では常に最新情報を持つわけではなく、ハルシネーション（誤情報）を出すこともあります。それでも、「すぐに答えが欲しい」「シンプルなチャットやQ&Aで十分」「リアルタイム性やコストを最優先にしたい」といった場面には、非常に頼りになる存在です。 意味を扱う「ベクトル＆セマンティック検索」 LLMの力を支えるのは、「ベクトル化」によって得られる検索精度です。文章や画像、音声などを多次元の数値（ベクトル）に変換し、それらの意味的な「近さ」で関連性を判断できるようにします。たとえば「AIの最新動向」という検索語でも、単語の一致に縛られず、意味的に近い論文や記事を高い精度で抽出できる、これが「セマンティック検索」の肝です。つまり、キーワードが違っても“意味が近ければ見つかる”という価値があり、企業のグローバル知識探索や多言語対応の内部データ検索で特に威力を発揮します。 しかし、KNNによるベクトル検索自体はそこまで新しい話でもありません。では、なぜこれがエージェントの進化に重要な貢献をしたのでしょうか。 セマンティック検索の概念は90年代後半に遡りますが、実用化への道のりは長いものでした。2012年のGoogleによるナレッジグラフの導入で注目を集め、2013年にはWord2Vecがニューラルネットワークを用いた初の単語埋め込み技術として登場しました。この頃からビッグデータの活用が本格化し、大量のデータで言語モデルを訓練できるようになったのです。そして現代的なセマンティック検索は、BERTやTransformerの登場により2018年頃から実用レベルに到達しました。つまり、アルゴリズム的基盤（KNN）は数十年前から存在していたものの、意味理解に必要な高品質な埋め込み技術とコンピューティング能力が揃ったのは比較的最近のことなのです。 外部知識を統合する「RAG」 LLMの弱点を補完するのが「RAG」です。RAG（Retrieval‑Augmented Generation）では、モデルに答えを生成させる前に、外部データベースから関連情報を検索（Retrieval）し、その内容を踏まえて応答（Generation）を構築します。これにより、回答に根拠が加わり、誤情報（ハルシネーション）のリスクを減らすことができます。 さらに進化した「マルチモーダルRAG」では、文章だけでなく画像や音声、動画なども対象に含めて検索・生成ができます。たとえば画像をCLIPでベクトル化し、テキストや映像と一緒に最適な情報を取り出すことが可能です。 こうしたRAGは、専門知識が必要で、常に最新情報を参照したい場合や、回答の品質と信頼性が特に重要な場面で真価を発揮します。つまり、単なるチャットではなく、内容の正確さと根拠を重視する「現場の頼れるAIアシスタント」として活躍します。 自律的に動く「エージェント」 RAGが「正確に答える力」を与える一方、エージェントには「自ら行動する力」が与えられます。つまり、ユーザーの意図を読み取り、最適なツールを選び出し、複数の手順を組み合わせてタスクを自律的に実行する存在です。さらに高度な形として、Agentic RAGでは「検索→生成」という静的な流れにとどまらず、AI自身が動的に検索戦略を立て、文脈を見ながら知識を取得・活用して応答を進化させます。 例えば、 GitHub Copilot の「Agent mode」（VS Code）は、自然言語の指示からコード理解・テスト・修正のループを支援する“自律的な相棒”として進化している。 さらに Copilot agent mode では、VS Code上でコードベースの読み取り、テストの自動実行、エラー修正をループで進行し、自律的なピア・プログラマーとして動作します。 現状では、ツールや仕組みの呼び方が乱立しており、統一された定義がありません。 ここから示すのは、 あくまでも私自身の理解に基づいた整理 です。 AI Agent LLMをコアに、利用可能なツールを呼び出して処理を自動で進める自律的システム。比較的「静的」で、あらかじめ設定された動作に従う存在。 Agentic AI 複数のエージェントがチームのように協力し、異なるLLMや外部リソースとつないで複雑な目標を達成する仕組み。 連携を統一する「MCP」 ここまで、「LLM × 検索」で知識を補強し、「エージェント × ツール」でタスクを自律的に遂行する進化を見てきました。しかし、現場では“どのツールに、どうつなぐのか”が統一されていないという課題があります。そこで登場したのが、MCP（Model Context Protocol）です。 MCPは、エージェントがツールやデータソースに接続するための標準的な「接続口」を提供する、Microsoft Build 2025でも、MCPが「エージェント時代のHTTPのようなプロトコル」として紹介されました。ツールやサービスごとに専用インテグレーションを書かなくても、共通仕様でつなげるようにします。 MCPを使う意味 開発・保守の効率化 ：使用するLLMやツールの数が増えるにつれて発生する、大量のカスタム接続を記述する必要がなくなるため、N×M問題が解消されます。結果として、開発コストを大幅に削減できます。 再利用可能なエコシステム ：一度つなげたツールは、他のエージェントやプロジェクトでもそのまま使えます。更新の波及もスムーズです。 サードパーティとの接続も容易 ：OAuthや認証仕組みを備えた安全で柔軟な接続設計がしやすくなり、導入障壁が下がります AI同士が協力する「A2Aプロトコル」 今や、エージェントがツールに接続する方法が「MCP」で標準化された一方で、エージェント同士の“対話”や“協調”には別の基盤が必要です。そこで注目されるのが、 A2A（Agent‑to‑Agent）プロトコル 。これは、エージェント間の「共通言語」となる通信ルールを定めた仕組みです。 A2Aの主な機能は以下の通りです： Discovery（発見） ：各エージェントが自分の役割やスキルを“Agent Card”として公開し、他のエージェントから見つけられるようになります。 Negotation（交渉） ：どの通信形式（テキスト、フォーム、音声など）や認証方式を使うかを、お互いにすり合わせられます。 Task／State Management（タスク／状態管理） ：タスクの進捗や状態（送信済み・実行中・完了など）をJSON‑RPCやSSEを用いてリアルタイムに共有できます。 Collaboration（協力） ：必要に応じて他のエージェントに処理を依頼し、結果を取得することで、連携した処理が可能になります。 たとえば、旅行手配エージェントが、スケジュール確認を担当するエージェントを見つけてやり取りし、空き時間を確認した上で予約を自動的に確定するような流れが、人の介在なしに完結できるようになります。 なぜA2Aが重要？ 標準化された協調設計 ：各社・各フレームワークで別々に組まれるエージェント連携を、統一された仕様で実現できます。 マルチエージェントの未来が見通せる ：AccentureなどはすでにA2Aをベースに、複数のエージェントが協働する仕組みを導入し始めています。 このように、MCPが「ツールへの接続口を揃える」役割とすれば、A2Aは「エージェント同士の会話や協調を可能にする土台」。それぞれの強みを活かすことで、「ツールを使うエージェント」から「互いに話し合いながらタスクを完遂できるエージェント」へと進化する設計が実現できます。 Elastic と AI 2022年： Elasticsearch 8.0がリリースされ、近似最近傍検索機能と最新自然言語処理モデルのネイティブサポートを搭載。2022年を通して、ベクトル検索はテクニカルプレビューの段階でした。 Elasticsearch 8.4で kNN検索を _search API に統合するなど実運用に向けた大きな前進になり、フィルタリング、再ランキング、レキシカル検索とセマンティック検索を組み合わせたハイブリッド検索が可能になりました。 2023年： Elasticが学習済みスパースモデルELSERを公開。追加学習なしで”意図”に基づくセマンティック検索を実現し、同年の8.9ではRRF（Reciprocal Rank Fusion）によるハイブリッド検索を導入してBM25／ベクトル／セマンティックを安定統合。 2024年： Open/Inference APIを拡充し、OpenAI・Azure・Anthropic・Mistral・Hugging Faceなど外部推論／埋め込み・リランクを公式に統合。RAG実装の柔軟性が大きく向上。 Elastic AI Ecosystemを発表。Elasticsearchベクターデータベースと主要AI企業の事前統合（モデル、クラウド、MLOps、データ準備など）により、RAGアプリ開発の立ち上げと運用投入を加速。Google Cloud／Microsoft／Hugging Face／LangChainなどと連携。 2025年： 社内向けジェネレーティブAIアシスタントElasticGPTを公開。Elasticsearchを中核にしたRAGと観測基盤の組み合わせで、安全で文脈を踏まえた知識探索を従業員に提供。プラットフォーム一体運用の実例に。 セキュリティ領域でのエージェント活用を強化。Elastic AI Assistant for Securityによる自然言語クエリ生成や調査支援、Attack Discoveryによる大量アラートの要約・優先度付けなど、Search AI × RAG × エージェントの実運用を具体化。 現在のポジション: Elasticsearchは2022年8月のバージョン8.4で本格的なベクトルデータベースとして名乗りを上げました。セマンティック検索が主流になってから3-4年遅れでの参入でしたが、既存の大規模ユーザーベースと、従来のBM25検索とベクトル検索を組み合わせたハイブリッド検索機能を武器に、この分野で確固たる地位を築きました。現在、Elasticは「Search AI Platform」として、ベクターDB／ハイブリッド検索（RRF）／リランク／Inference APIを統合し、「見つかる・根拠づける・守る」を土台に、RAGやエージェント実装を本番水準で支える位置づけを確立しています。 まとめ AIアシスタントの進化は、 LLM ：言語を扱う力 セマンティック検索 ：意味を捉える力 RAG ：外部知識を統合する力 エージェント ：自律的に行動する力 MCPとA2A ：連携と協力の力 これらの要素が順に積み重なることで、AIは「人に命令される存在」から「人と一緒に考え、動く存在」へと進化しました。この変化のスピードは早すぎて、今後どんな技術が現れ、私たちの仕事や生活がどう変わるかは、まだ見通しが立ちません。 The post 2025年のAIアシスタント：LLMからAIエージェント（Agentic AI）へ first appeared on Elastic Portal .