はじめに

ChatGPTの登場以降、あらゆる企業が「自社サービスへのAI組み込み」を模索しています。しかし、AI技術の進化はあまりにも速く、キャッチアップするだけでも一苦労だ。 AIチャットボットを作ってみたが、自社の独自仕様について嘘（ハルシネーション）をついて使い物にならなかったり、LLMの挙動を制御するために、延々とプロンプトエンジニアリングに時間を溶かしているといったことがある。私もdifyで自社のサポートAIチャットを作成したが、この辺りに時間をかけてしまっている。

それに対するアプローチとして本記事では「現在のAI技術の現在地」と、「我々開発者が本当にリソースを割くべき領域」について整理しました。

LLMとは何だったか

LLMは、書籍やWeb上の膨大なテキストデータを学習し、これまでの文脈から、次に来る確率が最も高い単語を予測して繋げていく機械学習モデル。自然な会話が成立するためAIとは意思を持った存在と錯覚しがちだが、実態は確率的予測マシン。

ハルシネーション

LLMは、世の中の一般的な知識は学習している。しかし、会社のサービスの独自の仕様などAIが学習していない情報については知らない。知らないことを聞かれたとき、LLMは「分かりません」と答えるのではなく、自分が知っている一般的な知識を元に、確率的に自然なもっともらしい誤った情報を出力する。これがハルシネーションだ。いかにこのハルシネーションを防ぎ、的確なコンテキストを与えて正確な回答・行動をさせるかが重要だと思う。

コンテキストサイズと計算量

「自社のマニュアルや仕様書を全部AIに読み込ませればいいのでは？」と考えることができる。しかし、LLMの核部分のTransformerアーキテクチャは、入力されたすべての単語（トークン）の関連性を総当たりで計算する。そのため、与えるトークンの長さに比例して、計算量は与えたトークンの2乗に比例して増大し、処理が極端に重くなるという構造的な課題がある。

ハルシネーションを防ぐための拡張技術

AIのハルシネーションを低減するために現在いくつかの技術がある。

RAG（検索拡張生成）

AIが知らない情報をあらかじめ自然言語からベクトルデータに変換してデータベースに保存（Embedding）する。そしてユーザが質問してきたときに、ユーザーの質問に関連する情報だけを検索してLLMに渡し、それをもとに回答させる。これの技術をRAGという。この際、巨大なドキュメントをそのまま渡すのではなく、文章を意味の塊ごとに小さく分割する「チャンキング」を行う。これにより、不要な情報を省き、LLMの計算負荷を下げつつ、精度の高い回答を得ることができる。

ReAct

ただ質問に答えるだけでなく、AIにツールを使わせて「作業」をさせる仕組み。「推論（Reasoning）」と「行動（Acting）」を交互に行う「ReAct」と呼ばれるフレームワークを与えることで、AIはユーザーの目的を達成するために「次は何を調べるべきか」「どのツールを使うべきか」を自律的に判断し、計画を実行する。

Function Callingから「MCP」へ

AIに外部ツールを使わせる技術も急速に進化している。従来は「Function Calling」と呼ばれ、AIが使える機能を開発者がプログラム内に直接書き込む必要があった。これに対し、最近Anthropic社などが提唱して大きな注目を集めているのがMCP（Model Context Protocol）だ。 MCPは、AIモデルと外部のデータソースやツール（slack、notionなど）を繋ぐための共通インターフェース規格であり、これを利用することでプログラムにベタ書きすることなく、プラグインのようにAIとツールを連携させることができる。

AIが利用できるツールの提供について

これまで多くの企業が、オープンソースのLLMをファインチューニングしたり、複雑なプロンプトを自前で設計したりして、独自のAIを作ろうと苦労してきたと思う。しかし、プロンプトの設計やモデルの挙動制御は高度な専門知識を要する。 OpenAIやAnthropicのようなAI専門の世界的なエリート集団が莫大な資金を投じて作る既製品のAIの賢さに、我々一般企業が単独で勝つことは不可能だ。だから、我々はAIを作るべきではなく、AIはChatGPTなどの最高峰のモデルをそのまま借りて、我々はそのAIが自社サービスを理解し、操作するための手足を作ることに全力を注ぐべきだと考える。

MCPではなく「CLI ＋ Skills」という選択

AIに自社のシステムを操作させるための手段として、先ほど紹介した画期的な規格であるMCPの採用を検討する企業が増えてきている。しかし、MCPツールを開発する際には困難があると思う。 MCPはAIが利用することを前提に設計されているため、人間が直接コマンドを叩いて動作確認することが困難だ。というのもMCPのデバッグには、MCP Inspectorなどの専用のクライアントが必要になり、開発とテストのハードルが高いという実務上の大きなデメリットがある。なので、MCPを開発するのではなくCLI（コマンドライン・インターフェース）ツール+Skillsの提供をするのがいいのではと考える。 CLIツールはもともと人間が利用するために作られているため、開発時のデバッグ・テストは簡単にできる。開発もしやすい。開発したCLIの利用方法をskillsの中で具体的なユースケースに合わせて説明することによって、AIはそのCLIツールを利用することができる。以上から、mcpではなくcliとskillsの組み合わせがAIエージェントのツールに最適ではないかと考える。