株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
LLMエージェントは「ツールを使ってタスクを進める仕組み」である
「AIエージェント」「自律AI」「LLMエージェント」――2025年から2026年にかけて、これらの言葉が企業DXの文脈で一気に前景化しました。ただし現場で話を聞くと、「チャットボットと何が違うのか」「ただのChatGPT連携ではないのか」「どこから触り始めればいいのか」――概念が混ざり合ったまま進んでいる組織が大半です。
LLMエージェントはチャットUIを入口にすることもできますが、特徴は「LLMがツールの使い方や手順を選び、結果を確かめながらタスクを進める」点です。Anthropicの設計資料も、事前に決めた手順をたどるワークフローと、LLMが手順・ツール利用を動的に決めるエージェントを区別しています。会話画面の有無と、裏側の実行方式は分けて考えます。本稿ではrenueが自社のMCPサーバー・Slackbot・Claude Code連携で運用してきた実装知見をベースに、LLMエージェントの仕組み・Tool Callingの実務・MCP（Model Context Protocol）の意義・失敗パターン・90日導入ロードマップを整理します。
LLMエージェントの4構成要素：Tool Calling・メモリ・プランナ・ガードレール
| 構成要素 | 役割 | 実装例 | なぜ必要か |
|---|---|---|---|
| Tool Calling | LLMが関数／API／DB／Webhookを呼び分ける機構 | OpenAI Function Calling / Anthropic Tool Use / MCP / OpenAI Agents SDK | テキスト生成だけでは業務は動かない。実世界に「手」を伸ばすため |
| メモリ | 短期／長期／会話履歴／ベクトル記憶の階層 | Vector DB（pgvector, Qdrant, Weaviate）＋KV＋会話履歴 | 1ターンで終わらない業務を追跡するため。メモリは会話・過去の情報の保持、RAGは検索した知識を生成に利用する仕組みで、保持した記憶の検索にも同じ検索技術を組み合わせられる |
| プランナ（ループ制御） | タスクを分解し、ツール順序と終了条件を決める | ReAct / Plan-and-Execute / OpenAI Agents SDK runループ / LangGraph | 「やるべきこと」を自分で組み立てさせるため。これがない＝ワークフロー自動化 |
| ガードレール | 権限・出力検閲・リトライ・上限・承認フロー | ポリシーエンジン・withRetry・dry-run・監査ログ・人間承認ステップ | 自律＝壊れたら自律的に壊す。壊れ方を制御するため |
「LLMエージェントを作りたい」と言ったとき、この4要素のどれを指しているのか、チームで合意できているかが最初の分水嶺です。Tool Callingだけなら関数呼び出しラッパーの話、プランナまで含めると実行エンジンの話、ガードレールまで含めると組織のガバナンス設計の話――それぞれスコープが桁違いに変わります。
MCP（Model Context Protocol）は何をもたらすか
2024年末にAnthropicが公開したMCP（Model Context Protocol）は、2026年時点でAIエージェント設計のデファクト候補になっています。端的にいえば「LLM⇔ツール」の接続プロトコルを標準化する仕組みで、エージェント実装の最大のペインポイントだった「モデルごと・SDKごとにツール定義を書き直す」問題を解消します。
renueでは自社バックエンドにMCPサーバーを組み込み、各種AIエージェントから社内データを参照できる基盤を運用しています。この経験で得た、MCPを採用する3つの実益はこうです。
- モデル中立性：Claude／GPT／Geminiのどれに切り替えても、ツール定義側はそのまま流用できる。半年ごとに変わるLLMコスパ序列にツール資産を引きずられない。
- 権限の集中管理：MCPサーバー層でユーザー単位の権限チェック・監査ログを一元化でき、LLM側の判断を信頼しないで済む。
- 社内エージェントの再利用：一度MCPツールとして公開した機能を、Claude Code／Slackbot／社内エージェント・Webフロントエンドのすべてから呼び出せる。ツール1つで4〜5箇所からの再利用が常態化しました。
Tool Callingの実装パターン：読み取り系から書き込み系へ
LLMエージェントを本番運用する現場で最も重要な設計判断は、「どのツールを、いつ、どの権限で解禁するか」です。一般に有効とされる3段階の解禁プロトコルを紹介します。
- 第1段階（0〜3か月）：読み取り専用ツールのみ。検索・要約・レポート生成・議事録参照・データ集計。事故っても「情報が出る／出ない」の差しかないため、LLMの出力品質とエージェントループの安定性の検証にフォーカスできる。
- 第2段階（3〜6か月）：dry-run前提の書き込み系。チケット起票／予約／メール下書き／DB更新を、dry-runモード（差分表示）＋人間承認をセットで実装。「承認すれば実行する」という境界を明確に置く。
- 第3段階（6か月〜）：完全自律の書き込み解放。十分にログとメトリクスが溜まり、再現率・精度・ガードレールの実測が揃った段階で、低リスクな書き込みから完全自律に切り替える。高リスクなもの（本番決済・顧客直接送信）は恒久的に人間承認を残す選択肢も十分にあり得ます。
書き込みを広げる前には、検証環境で失敗時の挙動を試し、承認・停止・復旧の手順を確かめます。Anthropicも自律エージェントでは誤りが連鎖する可能性を挙げ、サンドボックスでの十分な試験とガードレールを勧めています。誤更新が判明した際は、影響範囲の確認と必要な復旧、関係者への説明を進めます。段階設計は速度を落とすための保守的ルールではなく、最終的な立ち上がりを速くするための投資です。
AIエージェント導入でハマる10の落とし穴
- ツール乱立：なんでもツール化して50個以上登録し、LLMがどれを呼べばいいか混乱する。15〜25個が実用上の上限感覚。
- プロンプトインジェクション：社外入力をそのままLLMに流すと、埋め込まれた悪意の命令でツール呼び出しを乗っ取られる。2025〜2026年の実事故複数。
- Tool Calling結果のそのまま引用：DB結果や検索結果を無加工でユーザーに返すと、機密データ漏洩や表現トラブルにつながる。
- 無限ループ：終了条件が曖昧なプランナが同じツールを数百回呼んで従量課金を燃やす。必ずmaxTurns／タイムアウト／コスト上限を入れる。
- 監査ログがない：応答だけ保存してツール呼び出し引数を残していない。事故時に「誰が何を実行したか」が追えず致命傷。
- 権限の抜け穴：ボット共通トークンで動かす設計のため、本来アクセスできないデータにLLM経由でアクセスできてしまう。
- エージェント同士の責任分界点不明：複数エージェントを連携させると、どこが最終判断者かわからなくなる。必ず「最終責任エージェント」を1つ置く。
- モデル固有APIへの過度な依存：OpenAI固有パラメータでチューニングを積み、Claudeに乗り換えるとき全て書き直しになる。
- 評価指標が曖昧：「なんとなくうまく動いている」だけで、タスク完遂率・正答率・ツール選択正解率を測っていない。
- 運用担当不在：導入したのにプロンプト・ツール・ポリシーを触れる人が社内にいない。ベンダー依存が固定化する。
renueの実装知見：MCP×Slackbot×Claude Codeの内製運用から
renueではMCPサーバーを社内基盤に統合し、Slackbot経由で社員が「@bot 今週のプロジェクトリスクを要約して」「議事録から提案準備を作って」「成長課題を整理して」などを投げられる運用を続けています。ここで得た、2026年にLLMエージェントを導入する組織に向けた実学を5つ共有します。
- チャット画面を主戦場にしない：専用UIに加え、Slack／Teamsなど既存業務ツールから使う入口を検討します。例えばSlackにはエージェント用の会話画面や呼び出し口があります。導入時は入口別の利用人数・利用回数・タスク完了率を同じ期間で測定し、社員の業務に合う配置を選びます。
- ツール層を抽象化する（MCP的思想）：LLMとツール（社内API／DB／Webhook）の間に標準プロトコル（MCP）を置いておくと、LLMモデル乗り換え時もツール資産を流用できる。自社ラッパーでもMCPでも考え方は同じで、「LLMに直接つなぐ」は負債になります。
- 権限はユーザー単位で通す：ボット共通トークンで動かすと、「部長だけ見られる情報を新人が引ける」事故が起きます。LLMの出力を信じず、API層で権限チェックを強制する。これは技術論ではなく会社の情報統制の話です。
- 監査ログとプロンプトログを分離して永続化：LLM応答は運用改善に、API呼び出しログはコンプライアンス監査に使う。両方を紐付けて30〜90日保管する設計が最低ラインです。
- モデル抽象化を最初に入れる：GPT／Claude／Gemini／自社推論サーバーのどれでも差し替えられるレイヤーを最初から用意する。半年後のコスト見直しで必ず感謝します。
90日LLMエージェント導入ロードマップ
- 0〜30日：ユースケース棚卸しとアーキ決定。業務棚卸しで「LLMに投げたら効く定型タスク」を20〜50個リストアップ。その中から読み取り専用で完結するもの5〜8個を第1弾として選ぶ。並行して、MCP／OpenAI Agents SDK／LangGraph／自社ラッパーのいずれかでアーキを確定する。
- 31〜60日：読み取り専用エージェントPoC。Slack／Teams経由で動く読み取り専用エージェントを1本立ち上げ、社内10〜30名で使い倒す。タスク完遂率・ツール選択正解率・コストを数値化。失敗応答は全件人手レビューして、プロンプト／ツール記述／コンテキストのどこに起因したか分類する。
- 61〜90日：dry-run書き込み解放と運用体制。勝ちパターンを絞り、dry-run＋承認フロー前提で書き込み系ツールを1〜2個解禁。同時に、LLM抽象化・監査ログ・権限・コスト上限・プロンプト管理・評価ダッシュボードを本番仕様に整える。運用担当1名を専任アサイン。
「負債にならないLLMエージェント基盤」をrenueと一緒に作りませんか
LLMエージェントはツールと実行ループを組み合わせ、業務の手順を動的に進める仕組みです。チャットUIはその入口の一つで、会話以外の起動方法も選べます。運用を続けるには、構成・変更手順を文書化し、社内で確認できる担当者と改善の手順を決めておきます（運用設計の参考：Google Cloud）。renueはMCPサーバー・Slackbot・Claude Code連携の内製運用から得た知見をベースに、AIコンサル／新規事業AIの立ち上げを伴走しています。最初のユースケース選定から、モデル抽象化・権限・監査まで、3年先も負債にならない基盤を一緒に設計させてください。
まとめ：会話の入口と業務を実行する仕組みを分けて設計する
LLMエージェント（AIエージェント、自律AI）は、2026年の企業DXの本体です。チャットボットは会話の入口になり、エージェントはその裏側でタスクを進められます。本稿ではTool Calling・メモリ・プランナ・ガードレールの4要素から、その実行の仕組みを整理しました。導入するなら、①ユースケース選定、②アーキ（MCP／Agents SDK／LangGraph／自社ラッパー）の決定、③段階的解禁プロトコル、④権限・監査・コスト上限、⑤運用体制の5点をセットで組んでください。renueは自社のMCPサーバー内製運用で得た実学を、AIコンサル／新規事業AIの立ち上げ支援という形で還元しています。
