レポート:宮川 剛 - 実施日:2026年1月10日 13:00〜15:00 - 会場:富山国際会議場
はじめに：2年前の知識は通用するのか？
2026年1月10日、富山で開催されたエンジニアの祭典「Burikaigi 2026」。 私はそこで行われたセッション「さくらのAI Engineで学ぶ生成AIトレンドハンズオン」に参加しました。
テーマは、さくらインターネットが提供する「さくらのAI Engine」を使ったRAG（検索拡張生成）と、最新規格 MCP（Model Context Protocol）の実装体験です。
正直に参加前はこう思っていました。 「RAGか。2年前にI○MのインターンでPythonとLangChainを使って実装したし、大体の仕組みはわかっているつもりだ」と。
しかし、蓋を開けてみると、そこには私の知っているRAGとは全く異なる景色が広がっていました。 本記事では、ハンズオンを通じて痛感した「この2年間でのAIアーキテクチャの劇的な進化」について、特に「AIエージェント」というキーワードを中心に振り返ります。
1. RAGの実装：「職人芸」から「マネージド」へ
2年前（2024年頃）、私がチャットボットを自作していた頃、RAGの実装は「泥臭い前処理」の連続でした。 PDFを読み込むために PyPDF2 を書き、LangChain で「500文字で区切るか、いや300か？」と悩みながらチャンク分割のコードを書き、OpenAIのAPIに投げてベクトル化し……。コードの大半は「データの加工」に費やされていました。
しかし、今回のハンズオンで体験した「さくらのAI Engine」は違いました。
- ファイルをAPIに投げるだけ
- サーバー側が勝手にチャンク化・ベクトル化・DB保存まで完了
開発者は「どうデータを区切るか」という悩みから解放され、純粋に「そのデータをどう活用するか」に集中できる環境になっていました。
当時の私の実装（LangChainフル活用）と、今回のマネージドサービス（さくらAI Engine）の違いを整理すると、以下のようになります。
| 処理 | LangChain (一昨年) | さくらAI Engine (今回) |
|---|---|---|
| PDFの解釈・分割 | Pythonコード (LangChain) | さくらのサーバー |
| ベクトル化計算 | OpenAI API | さくらのサーバー |
| データベース管理 | あなた (ChromaDBなどを構築) | さくらのサーバー |
| 手軽さ | 低 (分割サイズなどを自分で調整可能) | 高 (ファイル投げるだけ) |
| 自由度 | 高 (カスタマイズ自在) | 低 (おまかせ) |
もちろん、複雑なオーケストレーションや細かい制御において LangChain は今でも必須の技術 です。しかし、「データの事前処理やDB管理」といったインフラに近い部分は、こうしたマネージドサービスに任せられるようになったことで、エンジニアはより本質的なロジックに時間を割けるようになったと感じました。
2. なぜ今、「DB」が必須なのか？ —— AIエージェントの本質
今回のハンズオンや最近のモダンな構成（LangGraphなど）では、TiDB Cloud や PostgreSQL といった「外部データベース」の利用が前提となっています。 「たかがチャットボットを作るのに、なぜわざわざDBが必要なのか？ メモリ（変数）でいいじゃないか」 2年前の感覚ならそう思ったでしょう。
しかし、セッションを通じて一つの重要な事実に気づきました。 それは、私たちが作ろうとしているものが、単なる「チャットボット」から「AIエージェント」へと進化したということです。
「Stateless（道具）」と「Stateful（同僚）」の違い
私がこの変化を腹落ちしたのは、以下の違いに気づいた時でした。
- 2年前のチャットボット (Stateless)
- 一問一答。ブラウザを閉じれば会話はリセットされる
- いわば「その場限りの道具」
- 現在のAIエージェント (Stateful)
- 「状態（State）」をDBに永続化して持っている
- タスクの進捗、過去の文脈、検索した結果を覚えている
- いわば「仕事を任せられる同僚」
エージェントと呼ばれる所以（ゆえん）
「メモリ上で処理するのではなく、永続性を持って会話を続けることができる仕組み」。 これこそが、AIエージェントの正体ではないでしょうか。DBによる「状態管理（State Management）」があるからこそ、AIは以下の振る舞いが可能になります
- 時間のかかるタスク
「調査しておいて」と頼んで、数時間後に「終わりました」と報告を受ける（非同期処理） - ヒューマン・イン・ザ・ループ
「メールの下書きを作ったので、承認待ちステータスで待機。人間がOKを出したら送信」という連携。 - 失敗からの復帰
エラーが起きても、DBに残った「セーブデータ」から続きを再開できる
BurikaigiでTiDB CloudのようなクラウドDBが採用されていたのは、単にログを残すためではなく、この「自律的なエージェント」を実現するための心臓部だったのです。
3. MCP：「脳」と「手足」の分離
そしてもう一つのトレンドが MCP (Model Context Protocol) です。 これまでは「社内データを検索させる」ために、APIを叩くコードを一生懸命書いていました。
ここで思い出すのが、2年前の苦労です。 当時、LangChainでチャットボットを作っていた時は、回答のトーンをコントロールするのも一仕事でした。「理論的に答えさせたい」時は temperature パラメータを 0.0 に設定し、「情緒的に寄り添わせたい」時は数値を上げたり、厳密なシステムプロンプトをコードに埋め込んだりと、「PythonコードでAIの性格を作る」調整をしていたのです。
しかし、MCPの時代では、この役割分担が明確になり、調整が劇的に楽になりました。
- 脳: Claude Desktop（普段使い慣れた賢いAI）
- 手足: さくらAI Engine（社内データの検索係）
これらが「MCP」という共通規格で繋がります。 さくらのサーバー（手足）は、淡々と検索結果のデータを返すだけ。それを受け取ったClaude（脳）が、ユーザーとの対話の文脈に合わせて「料理」します。
かつてコードで数値をいじって調整していた「理論的」か「情緒的」かという制御も、今はClaudeにチャットで「新入社員向けに優しく解説して」や「役員向けに結論から端的に」と指示するだけです。 ハンズオンでは、Claude Desktopに向かって「社内規定について教えて」と聞くだけで、裏側でさくらAI Engineが検索し、Claudeが自然な日本語で答えてくれる様子を学びましました。
「AIをアプリに組み込む」のではなく、「自分のAI（Claude）に、新しい能力（検索）をプラグインのように後付けする」感覚。そして、その検索結果をどう語るかの「コンテキスト」は、使い慣れたAI側で自由に制御できる。これがMCPの本質だと感じました。
まとめ
Burikaigi 2026 でのハンズオンは、単なるツールの使い方だけでなく、AI開発のパラダイムシフトを肌で感じる機会となりました。
- 手作り から マネージド へ
- オンメモリのチャット から DB駆動のエージェント へ
- 独自実装 から MCPによるエコシステム へ
2年前にPythonでコードを書いて苦労した経験があったからこそ、今の技術が「何を解決したのか」、そして「裏側で何が起きているのか」が手に取るように理解できました。あの時の泥臭い経験は、決して無駄ではなかったようです。
これからのAI開発は、コードをガリガリ書く力以上に、これらのコンポーネントを理解し、目的に応じてオーケストレーション（構成）する力が問われていくのだと感じました。
参考資料・技術リンク
今回のハンズオンで扱った技術や、関連する実装の詳細は以下のリンクにまとめられています。
基本・入門
-
さくらのAI Engine ハンズオン資料
- MCPの実装にはClaude Code等が必要ですが、まずはここから！
RAG (検索拡張生成) の実装
A2A (Agent to Agent) & MCP