本記事の目的
AIエージェントを作る手法はいくつかあり、日々増えていっています。特にノーコード・ローコードの手法もいくつか存在し、AIエージェント自作への障壁はだいぶ下がってきています。
しかし、ノーコードであっても、処理フローの設計や各ステップへの指示には試行錯誤が必要です。
本記事では、その作成作業をAIが支援する、弊社 Sionic AI の STORM Act を紹介します。まずは前提として、AIエージェントの定義と作成方法を整理します。
そもそも AI エージェント ってなんだ？
このお題、シンプルすぎて人や会社・組織によって定義に違いがあるトピックだなと感じます。AIを使ったシステムに関わっていても、この問いに一言で答えるのは意外と難しいものです。
重要なのは、少なくとも自分自身がAIエージェントをどんなものだととらえているのかを明確にしておいて、他の人が「AIエージェント」といったときにその人は何をAIエージェントとしてとらえているのか？（もしくはAIが絡んだものをすべてAIエージェントと呼んでいるか？）を考慮に入れながら話を進めることが大事だと言えます。
Anthropic が定義する AIエージェント
こういう文章あるとありがたいですよね。
Anthropic によると
AIエージェントとは、LLMが作業の進め方やツールの使い方を動的に判断し、タスクの遂行を主導するシステム。
あらかじめ定めた手順で動く「ワークフロー」と区別しており、フローの複雑さよりも、LLMが実行方法を動的に決める点がポイントです。
Microsoft が定義する AI エージェント
またしてもありがたいリファレンス。
AIエージェントとは、特定の業務プロセスの実行やビジネス課題の解決に特化したAIツール。
Microsoftの記事は、質問応答型から自律型までを幅広くAIエージェントとして扱っています。以下は、同記事の分類を参考に、本記事で扱う用途を筆者なりに整理したものです。
| 種類 | 本記事での整理 |
|---|---|
| Prompt-and-response | ユーザーの質問に対し、参照できるデータをもとに情報を検索・要約して回答する。 |
| Task | 特定の業務フローを実行し、反復的なタスクを自動化する。 |
| Autonomous | 目標と状況に応じて計画・実行・見直しを行い、必要に応じて他のエージェントと連携したり、人に判断を求めたりする。 |
この３つの分類は非常にありがたいなぁと思います。
本記事では、特定の用途に合わせた質問応答型から自律型までを含む、広い意味で「AIエージェント」という言葉を使います。
弊社 Sionic AI では、STORM という AIエージェント 生成プラットフォームを提供しておりますが、RAG を使用してその情報をもとに回答をするエージェントを作るとこんなシンプルなフローになります。
ただ、どこかで
こういう複雑性を持つフローを見たらしく「そんな単純なの（最初のシンプルな例）はAIエージェントじゃねえ」と言われたこともあります。
そういう時は、「Microsoft がいう Prompt-and-response に分類される AI エージェントです」というと波風立てずに話を進められるかもしれません。
AI エージェント Platform/Framework が活躍するユースケース
先にご説明したような「ある資料を参考にして、AI が質疑応答する」というシンプルなユースケースの場合、必ずしも AIエージェント を用意しなくてもよいかもしれません。
例えば、ChatGPT のアプリを開いて、参照するドキュメントをアップロードし、そのドキュメントに関連する質問をするとChatGPTは、ドキュメントの内容を理解して回答を返してくれるのでそれで充分かもしれません。（注１）
一方で、何かのイベントや定期的に発生している作業に、日々多くの人手をかけているのならば AIエージェント を導入する価値が高いです。
例えば
- 毎日 23:00 にメッセージをチェックして、レポートを作成する
- 商品の発注メールを受信時に在庫を確認して回答をする
- 週に一度、システムの更新情報をまとめてリリースノートを作成する
等。。。
注１
個人が少数の資料について、その場で質問するだけなら、汎用の対話型AI（ChatGPTのアプリ）で十分な場合もあります。一方、継続的なデータ参照や複数人での利用、外部システムとの連携が必要になると、専用のエージェントや実行基盤を用意する価値も高まります。
AI エージェント作成手法
AIエージェントを作る方法を「何を自分で実装し、何を基盤に任せるか」という観点で分類すると以下が考えられます。
| 作成方法 | 代表例 | 特徴・強み | 制約・負担 | 向いている用途 |
|---|---|---|---|---|
| ① API・モデルSDKで独自実装 | LLMのAPI、ベンダーのAPIクライアントSDK | モデル呼び出し、ツール実行、繰り返し処理を自分で設計できる | 状態管理、再試行、停止条件、ログなどを実装する必要がある | 独自要件の強いアプリ、構成を小さく保ちたいシステム |
| ② エージェント用SDK・フレームワークで開発 | LangChainなど | エージェントの基本動作やツール連携を再利用し、実装量を減らせる | フレームワークの設計や抽象化を理解する必要がある | 独自アプリへのエージェント機能の組み込み |
| ③ 実行制御・状態管理のフレームワークで開発 | LangGraph | 分岐、ループ、状態の保存、人の承認、中断・再開を細かく設計できる | 処理の流れや状態を設計する負担がある | 長時間の処理、承認を伴う業務、複雑なエージェント連携 |
| ④ ノーコード・ローコード基盤で構築 | Dify、Copilot Studio | 画面上でモデル、知識、ツール、処理を組み合わせられる | 独自処理や細かな制御は、拡張コードや外部APIが必要になる場合がある | 社内向けアプリ、試作、業務部門と共同での開発 |
| ⑤ 既存のAIサービスを設定・拡張 | Microsoft 365 Copilotの宣言型エージェント | 既存の実行基盤や画面を利用し、指示・知識・利用可能なアクションを設定する | モデル、画面、実行方法などの自由度はサービスに依存する | 部門別のアシスタント、社内情報の検索・業務支援 |
| ⑥ 業務自動化基盤にAIを組み込む | n8nなど | イベント起動や外部サービス連携を中心に、必要な箇所へAIの判断を組み込める | 長い自由探索より、業務フローに沿った設計が中心になる | メール処理、問い合わせの振り分け、システム間の更新 |
①,②,③ は、もともと開発能力の高い方にとっては、それほど大きな障壁は無いかもしれません。
④,⑤,⑥ は、ローコード・ノーコードで開発できるので、最初の一歩という点では心理的にハードル低いかもしれません。
AIエージェントを作成するうえでの課題
結局、難しいんじゃない？ってのがなんやかんやありますよね？
④のノーコード・ローコード基盤なんかも逆にどうやったらいいかわからなかったり、プロンプト（LLMに対する指示）なんかは、いわゆるプロンプトエンジニアリングと言われる専門的な知識が必要になったりします。
STORM Platform
STORM Platform は、弊社 Sionic AI が提供する AI エージェントを開発するためのプラットフォームで、先ほどの分類でいうと ④ ノーコード・ローコード基盤で構築 に分類されます。
ノーコード・ローコード
ノーコード・ローコードって言っても難しいんじゃないの？
実際問題、私も使ってみて逆に LangChainやLangGraph の方が勘所をつかみ易く・自由度も高いというところでやりづらさを感じることもありました。（学習が進むと、ノーコード・ローコードでのやりやすさという点は劇的に向上しては行きます）
コードを書かずに済んでも、処理の分け方、ツールの選択、各ステップへの指示、出力の検証は必要です。ノーコード化だけでは、こうした設計の難しさは残ります。
STORM Act
STORM Platform の 機能である STORM Act は、「結局難しいやん」という課題を解決するために、Platform とユーザーの間に AI を介在させて自然言語で会話することで AIエージェントが作れてしまう機能です。
実際には、こんな形でどんなエージェントを作りたいか自然言語で話しかけるだけでエージェントが作れます。
最初にエージェントの目的をざっくり説明
エージェント作るうえで、詳細にしなければいけない点をAIがフォローアップ
一旦出来上がった AI エージェントのワークフロー
上記の例のようなやり取りの後、フロー、ノード設定、プロンプトが生成されています。
まとめ
今回は、弊社 STORM プラットフォームの STORM Act 機能のご紹介をさせていただきました。
STORM Act は、自然言語での対話を通じてフロー・ノード設定・プロンプトを生成し、ノーコードでも残る設計・設定の負担を軽減する機能です。
次回以降で、具体的な機能の内容や実際の作り方についてご説明していきます。