この記事の目的
弊社 Sionic AI では、AIエージェント作成ツール STORM Platform を提供しています。このツールは、Dify や n8n のようなローコード・ノーコードの AI エージェント作成プラットフォームです。
この製品のプロモーションをしていると、Copilot や Notebook LM と何が違うの？という質問や、実際のデモをすると Copilot とか Notebook LM でもできるけど？といった意見をたくさんいただきます。
これらの疑問に対して、自分自身にとっての備忘録の意味も含めてまとめてみました。
それぞれのツール・プラットフォームの特徴
AIを活用するツールには多種多様なものがありますが、今回は 人が対話しながら仕事を進めるもの と、複数の処理を一連の流れとして実行する ものを取り上げてみました。
本記事では、製品を排他的に分類するのではなく、代表的な利用形態として前者を「AIアシスタント型」、後者を「AIワークフロー構築型」に分けて整理します。同じ製品でも、利用する機能や構成によって、両方の使い方が可能です。
分類はするものの、機能の拡張に伴い、両者の領域は重なりつつある気がしています。
AIアシスタント型
AIアシスタント型は、人がAIに質問や指示を出し、返ってきた結果を確認しながら仕事を進める使い方です。
作業の目的や状況に応じて、利用者が指示や進め方を柔軟に変えられます。そのため、調査、資料の理解、文章作成、アイデアの検討など、毎回内容が変わる仕事で活用しやすいと考えられます。
Copilot
ここでは、主にMicrosoft 365 Copilotを指します。
Copilotは、Word、Excel、PowerPointなど、日常業務で使用するアプリと連携して作業を支援するAIです。利用できる範囲は契約や設定によって異なりますが、文章の下書きや要約、データの分析、資料作成などを支援します。
代表的な使い方は、「この資料の要点を整理して」「この内容をもとに提案書の下書きを作って」といった指示を出し、結果を確認・修正しながら成果物を仕上げることです。
利用者自身が仕事の流れを把握し、必要な場面でAIの支援を受けるため、既存の仕事の進め方に取り入れやすいのが特徴です。
なお、Copilot Studioなどを使えば、エージェントやワークフローを構築する使い方にも広げられます。
Notebook LM
NotebookLMは、取り込んだ資料をもとに、情報の理解や整理を支援するAIです。資料に対する質問、要約、複数の資料の比較などに利用でき、回答に示される引用から根拠を確認できます。
たとえば、複数の報告書を読み込ませて共通点を整理したり、マニュアルについて質問したりする使い方が考えられます。
Copilotが日常業務のさまざまな作業を支援するのに対し、NotebookLMは、特定の資料群を読み解き、理解を深める場面で特徴が出ます。
どの資料を使い、何を問い、結果をどう仕事に生かすかは、主に利用者が判断します。
AIワークフロー構築型
AIワークフロー構築型は、情報の取得、AIによる分析、結果の加工、外部システムへの登録などを、一連の処理として組み合わせる使い方です。
利用するたびに人が各工程を指示する負担を減らし、繰り返す作業を実行しやすくします。また、処理の手順を共有することで、担当者ごとの作業方法のばらつきを抑えることも期待できます。
ただし、手順を構築する自由度や、対象とする業務の範囲は、ツールによって異なります。
STORM
STORMは、LLMへの指示、社内資料などの知識検索、外部ツールの呼び出し、条件分岐などを組み合わせ、AIアプリケーションを構築するためのプラットフォームです。
主な機能として
- 社内文書の検索・回答生成を支援する RAG エンジン STORM Retrieval
- 画像・プレゼン資料・エクセルデータ等をパースしてAI Ready な形式に変換する STORM Parse
- 自然言語での会話を通じてワークフローを構築する STORM Act
- 質問に応じて検索方法や調査方法をAIがフローをダイナミックに生成して実行する Agentic RAG
があります。
たとえば、「質問を受け付ける→関連する社内資料を検索する→資料をもとに回答を生成する」という処理を組み合わせ、社内向けの問い合わせアプリを作ることができます。
利用者が毎回、資料や詳しい指示をAIに渡す代わりに、アプリの構築担当者が、参照する情報や処理の流れをあらかじめ設計します。
個人が工夫していたAIの使い方を、他の人も利用できるアプリにする場面で役立ちます。ただし、回答の品質を保つには、参照資料の整備や、出力の評価・改善も必要です。
Dify
Difyも STORM と同様に、LLMへの指示、社内資料などの知識検索、外部ツールの呼び出し、条件分岐などを組み合わせ、AIアプリケーションを構築するためのプラットフォームです。
n8n
n8nは、複数のアプリやシステムを接続し、データの取得、加工、登録、通知などを自動化するためのプラットフォームです。処理をノードとしてつなぎ、特定のイベントなどをきっかけに実行します。
たとえば、「問い合わせを受信する→AIで内容を分類する→管理システムに登録する→担当者に通知する」といった業務フローを構築できます。
DifyがAIアプリの処理を設計する場面に重心を置くのに対し、n8nは、複数のシステムにまたがる業務全体をつなぐ場面で特徴が出ます。AIを使わない、ルールに基づく処理も組み合わせられます。
業務で継続的に使う際には、正常に動く流れに加えて、失敗した処理の確認や、エラー発生時の通知も設計することが大切です。
実際の使われ方の違い
それぞれのグループ毎に大きな観点で比較してみます。
| 比較する点 | AIアシスタント型 | AIワークフロー構築型 |
|---|---|---|
| 主な目的 | 目の前の仕事や思考を支援する | 業務の手順を実装し、繰り返し動かす |
| 手順を組み立てる人 | 主に、その都度使う本人 | 主に、事前に仕組みを作る担当者 |
| 向いている仕事 | 調査、資料の理解、文章作成、比較、壁打ち | 受付、分類、情報抽出、システム登録、通知などの連続処理 |
| 動作きっかけ | 利用者の問いかけ | 任意（定期実行、メール受信等のイベントきっかけ） |
| 自由度 | 状況に応じて指示や進め方を変えやすい | 設計した手順や条件に沿って実行しやすい |
| 共有するもの | 資料、会話、ノート、指示の工夫 | 実行できるアプリや業務フロー |
| 必要な負担 | 利用するたびに指示・確認する時間 | 初期構築と、運用・保守の時間 |
AIアシスタント型 と AIワークフロー構築型 の境界は、固定されたものではありません。AIアシスタントが複数工程を実行するようになり、会話から業務フローを呼び出す仕組みも整うにつれて、両者の役割は近づいています。
そのため、今後は「自動化できるか」だけでは、両者の違いを説明しにくくなると考えています。比較すべきなのは、AIにどこまで手順を任せるか、どの部分を組織のルールとして固定するか、そして実行結果や例外をどう管理するか、という点です。
具体的な例
明日の顧客向けプレゼン資料を作成する
このような仕事では、AIアシスタントと対話しながら、「今回は導入効果を先に説明したい」「この表現は顧客の業界に合わせたい」と調整する方法が適しています。
人が顧客との関係や提案の意図を判断し、AIに情報整理や下書き、修正を手伝ってもらう使い方です。単発の依頼であれば、専用のワークフローを構築する負担も避けられます。
ただし、同じ形式の提案資料を大量に作成する場合は、データ取得や定型スライドの生成をワークフローにする価値があります。
月例の売上・在庫レポートを作成する
毎月、同じシステムからデータを取得し、同じ指標を集計して、決まった宛先にレポートを届ける仕事は、ワークフローに適しています。
たとえば、次のような流れを組み立てます。
データ取得 → 集計・前月比較 → グラフ作成 → AIによる説明文の下書き → 担当者確認 → 配信
この場合、売上合計や在庫数などの計算は、SQLやプログラムなどで処理し、AIは数値の変化を説明する文章の作成などに使う構成が考えられます。
定型処理を仕組みにすることで、担当者は毎月の転記や集計より、異常値の確認や結果の解釈に時間を使えます。ただし、数値が変化した原因まで説明するには、それを裏付ける情報が必要です。
注文書の受信をきっかけに受注処理を進める
顧客から注文書を受け取った際に、内容を確認し、受注システムへ登録して担当者に通知する仕事も、ワークフロー に適しています。
たとえば、次のような流れを組み立てます。
注文書メールの受信
→ 添付ファイルの読み取り
→ 注文情報の抽出
→ 商品マスターとの照合・必須項目の確認 → 担当者承認
→ 受注システムへの登録
→ 完了通知
AIは、顧客ごとに書式が異なる注文書から、商品名、数量、希望納期などを抽出する工程で活用できます。一方、商品コードの照合、金額の計算、重複注文の確認などは、ルールやデータベースに基づいて処理する構成が考えられます。読み取れない項目や不一致があれば、担当者の確認に回します。
AIアシスタントに注文書を渡し、情報を抽出してもらう方法でも、個々の作業は支援できます。しかし、注文のたびに人が指示し、結果を別システムへ転記する負担が残ります。
ワークフロー型では、メールの受信というイベントを起点に、あらかじめ設計した処理を開始できることが特徴です。人は各工程を開始する操作から離れ、内容の確認や例外への対応に集中しやすくなります。
社内規程のサポートボットを作成する
社内規程について自分が調べるだけなら、AIアシスタントに資料を参照させて質問する方法でも対応できます。
一方、従業員が共通して使うサポートボットを提供する場合は、回答に使う規程、回答方針、参照元の表示、答えられない場合の問い合わせ先などを、仕組みとして整える価値があります。
想定する流れは、次のようになります。
質問受付 → 閲覧権限に応じた規程の検索 → 根拠を示した回答 → 解決しない場合は担当部署へ案内
この用途では、DifyやCopilot Studioなど、知識検索と回答生成を組み込める構築基盤が候補になります。ただし、既存のAIアシスタントで必要な共有・権限管理を実現できるなら、専用ボットを新たに構築する必要性は下がります。
重要なのは、チャット画面を作ることに加えて、最新の規程を参照できること、利用者ごとの閲覧権限を守ること、判断できない質問を適切に引き継ぐことです。
Observability（可観測性）
AIを業務に組み込む際は、一度動く仕組みを作るだけでなく、運用しながら品質を改善することも重要です。
たとえば、RAGの回答が不適切だった場合、原因はプロンプトだけとは限りません。参照元の文書が古い、文書を適切に分割できていない、検索で必要な情報を取得できていない、取得した情報を回答に反映できていない、といった可能性があります。
ワークフロー型では、各工程の入力・出力、検索結果、参照した外部データ、使用したプロンプトなどを記録する設計により、問題が起きた箇所を追跡しやすくなります。こうした内部の動作を把握できる性質を、Observability（可観測性）と呼びます。
さらに、代表的な質問と評価基準を用意し、変更前後の結果を比較することで、プロンプト、検索方法、参照データなどの改善効果を検証できます。
このように、ワークフロー型では、各工程の実行履歴をもとに問題を切り分け、共通の評価基準で改善を検証する仕組みを設計できます。自動化に加え、組織として品質改善を継続しやすいことも利点です。ただし、そのためには、ログの保存、評価用データの整備、プロンプトや参照データのバージョン管理などが必要です。
まとめ
2026年Q4時点で、このテーマについてまとめると以下のようになるかなと考えます。
AIアシスタント型とAIワークフロー構築型は、仕事の進め方で使い分けると整理できます。
- AIアシスタント型：人が対話しながら、その都度、目的や状況に合わせて進める仕事に向いています。顧客向けプレゼン資料の作成などが該当します
-
AIワークフロー構築型：決まった手順を繰り返す仕事や、共通の仕組みを複数人に提供する用途に向いています。月例レポートの作成や、社内規程のサポートボットなどが該当します
そのため、必要性を左右するのは、個人・組織の違いやAIリテラシー（AIを使いこなす能力）だけではありません。業務の反復性、手順の標準化、システム連携、運用管理の必要性が判断の軸になります。
また、AIリテラシーによって状況が異なるという点もあると思います。例えば、Copilot をバリバリ使いまわせている人であれば、一度作ったフローを使いまわせて効率化できるので、再利用するからという理由だけで AIワークフロー を誰かに用意していただく必要性は低いのかもしれません。
一方で、まだ、使いこなせていない人にとっては、AIアシスタント 用途でも誰かに AIワークフロー を用意してもらって、簡単に使える環境を用意していただいた方が良いかもしれません。