Data Direction Groupブログリレー3日目の記事です。
2025年4月よりData Direction Groupにジョインした齊藤です。データエンジニアリングやアナリティクスなどをやりつつ、その延長線上でAIエージェント開発に取り組んでいます。
前回記事では、データエンジニアリングのリズムを活かして「依頼を価値に変えるサイクル」をプロダクト開発に持ち込み、"屋台骨（コア体験）に最短で辿り着く"ために引き算して検証を回すお話をしました。
今回の記事は、その続きとして「体験を広げながら深掘りしていくフェーズ」では避けて通れない、AIエージェントの設計論についてです。前回記事のStep 4では「エージェントがどのようにデータを扱うか（RAGか、ツール利用か）」を具体的なユースケースに沿って深掘りしていく、と触れられていました。この記事では、その深掘りの一つとして、AI エージェント開発において議論になりがちな "Agentic（動的推論）" と "Workflow（明示的制御フロー）" をどう使い分けるか を、開発中のプロダクトである営業支援AIエージェントに寄せて整理します。
1. 何を作っているか
企業情報、営業活動、案件管理、過去の取引といった散らばったデータソースから必要な情報を取得し、統合してユーザーに回答するAIエージェントを開発しています。たとえばユーザーが「A社の商談準備をしたい。直近の動きとリスク観点をまとめて」「今月の重要案件、優先度順に並べて根拠も付けて」「XX業界で競合が強い領域ってどこ？」といった自然言語の依頼を投げると、複数のソースから関連データを収集し、統合された形で回答を返します。
このプロダクトで重要なのは、ハイパフォーマーの商談準備の方法を使いやすい形で横展開することです。営業活動において、成果を出している担当者は独自のノウハウや情報収集の型を持っていますが、それが属人化しているとチーム全体としての成果が安定しません。AIエージェントを通じてハイパフォーマーの方法論を再現可能な形に落とし込み、誰でも同じレベルの商談準備ができる仕組みを作ることが、プロダクトとしての価値につながると考えています。そのためには、再現性のある手順と品質を担保する、システムとしてのAIエージェント設計が必要になります。
では、このプロダクトを実現するために、AIエージェントはどのような要請に応える必要があるのでしょうか。
2. 営業支援AIエージェントに求められる2つの要請
営業支援AIエージェントには大きく2つの要請があります。
第一に、標準化・再現性です。同じ依頼をしたら同じ構成・観点で結果が返ってくること、抜け漏れが少ないこと、根拠が揃うこと、チームで共通言語化できることが求められます。これは営業組織における「繰り返し可能な手順・行動・ベストプラクティス」［1］の確立と同じ課題です。商談準備の標準フォーマットや優先度スコアリングの基準など、型として確立できたパターンを確実に実行することが重要です。
第二に、探索的なニーズです。「XX業界で注目すべき動きは？」「新しい市場機会はあるか？」「想定外のリスクは？」といった問いは、型がない場面での柔軟な対応を求めています。これはAd-hoc reporting、つまり「その場の意思決定に合わせて掘る」［2］問いです。営業の意思決定は状況に依存するため、探索すること自体が価値であり、必ずしも型化を目指すわけではありません。
この2つの要請はどちらも重要で、両方に対応する必要があります。
3. AgenticとWorkflowの役割：対立ではなく適材適所
標準化と探索性という2つの要請に対応するため、AIエージェント開発では広くAgenticとWorkflowという2つのアプローチが整理されています［3］［4］。この区別は「誰が次の手順を決めるか」という観点で捉えられます。Workflowは「事前に決めたコードパス」で進み、エージェントは「状況に応じて自ら手順を決める」というものです。
Agenticは動的な推論、探索、仮説検証が得意です。探索的ニーズや、型では対応できない曖昧さ、状況依存の判断が必要な場面で力を発揮します。
一方で、Workflowは型の再現、標準化、効率化が得意です。型化できた領域で再現性を担保し、「型の横展開」という価値の中核を担います。参照範囲・実行順序・抽出方法・出力構成を固定することで、同じ条件で同じ結果を生み出します。
ただし、現実のシステムではこの2つが混在します。分岐やリトライが複雑でも列挙可能ならWorkflow側、実行中に観察に応じて手順を変えるならAgentic側［5］です。つまり、これらは二項対立ではなく、それぞれが異なる役割を持つスペクトラムです。
4. Agentic：探索と適応が価値を生む場面
では、Agenticアプローチが特に有効なのはどのような場面でしょうか。営業支援の文脈では、主に2つの場面で力を発揮します。
第一に、探索的ニーズです。「固定パスをハードコードできないopen-ended problems」［3］、つまり市場動向の把握、リスク発見、新しい機会の探索など、定型的なDBクエリに落とし込めない問いです。状況依存の判断と文脈理解が求められます。
第二に、型では対応できない曖昧さです。データの欠損、表記ゆれ、前提条件の不明確さなど、型が崩れる瞬間をカバーする適応能力が必要です。
こうした場面では、ReAct［6］のパターンが有効です。意図を仮置きする（Reason）→DBから材料を取る（Act）→結果を見て次の論点を更新（Reason）→また取りに行く（Act）という往復で、クエリが確定していない状況でも前に進めます。営業情報の収集・統合は、複数ソースから情報を集めて分析する「Agenticなsearch task」［3］として位置づけられます。想定外の質問に耐えられ、不足情報があっても会話で進められ、企業×案件×活動 のように横断で"状況"を掴むのに向いています。
一方で、Agenticは「柔軟だが非決定的」［7］という側面もあります。同じ依頼でも経路が変わってブレる傾向があり、ユースケースが増えるほど制約も増え、プロンプトだけで制御しきれなくなります。そのため、ツール/DBクエリをallowlist（許可制）にして引数バリデーションを施すこと、参照範囲を出力に含めて後で追えるようにすること、といったガードレールは最低限設ける必要があります。
5. Workflow：標準化と再現性が価値を生む場面
Agenticの柔軟性に対して、Workflowが力を発揮するのは、繰り返し出現するパターンを型として固定化し、安定した再現性を担保する場面です。「明確に定義されたタスクではWorkflowが予測可能性・一貫性を提供する」「3］とされており、商談準備の型を守る、品質を担保するという要請がこれに当たります。
具体的には、参照範囲（どのDB・期間・定義）、実行順序（何をどの順で取るか）、抽出方法（テンプレSQL、検索クエリ、観点）、出力の構成（章立て、必須項目、スキーマ）を固定します。文章自体はLLMが生成するため揺れますが、観点・構成が揃うだけでも効果的です。こうした再現性は、三つの層に分解して考えることができます。第一に、DBから引き出すデータの再現性です。テンプレSQL＋固定定義で、同じ条件で同じデータを取得できます。第二に、Web調査方法の再現性です。参照先や観点をテンプレ化し、情報収集の手順を標準化します。第三に、レポートの構成の再現性です。スキーマや章立てを固定することで、「壊れない成果物」を作れます。「繰り返し可能な結果が必要ならstructured workflows」［7］というのが実装面での指針です。
一方で、ユースケースを個別に増やすとテンプレが爆発して保守が困難になります。この問題への対処は、ユースケースを抽象化してパラメトリックにすることです。「企業要約」「競合比較」「直近活動サマリ」のような"目的クラス"を定義し、入力をパラメータ（企業、期間、業界など）で吸収し、SQL/調査/レポートを"テンプレ＋パラメータ"で共通化します。こうした抽象化を適切に行えば、新しいユースケースを追加する際のコストが下がり、保守性が向上します。ただし、実装の泥臭さ（SQLテンプレの設計やパラメータの妥当性チェック）をちゃんとやるほど効いてくる領域です。
6. プロダクトの成長戦略：型の発見と進化
ここまでWorkflowによる型化の重要性を述べてきましたが、そもそも「型」は最初から存在するわけではありません。ハイパフォーマーのノウハウは暗黙知として属人化しており、明文化されていないのが通常です。ここで重要になるのが、AgenticとWorkflowを進化のプロセスとして捉える視点です。
プロダクトの初期段階では、型が明確でないためAgenticで対応します。この過程で、ユーザーの質問パターン、必要なデータソース、有効な分析観点などが見えてきます。ログやフィードバックを分析することで、繰り返し出現するパターンを抽出できます。
発見されたパターンはWorkflow化していきます。Workflowは「agents, tools, control-flow logicの組み合わせ」［8］であり、AgenticとWorkflowは対立ではなく、探索で得た知見をWorkflowに封じ込める関係です。たとえば、商談準備において「目的・前提」「直近の動き」「争点・論点」「リスク」「次アクション」「根拠」という章立てが有効だと分かれば、これを型として標準化します。
ただし、すべてが型化できるわけではありません。探索的ニーズや状況依存の判断が必要な領域は、Agenticのまま残します。また、型化された領域でも例外や新しい状況が出現すれば、Agenticで対応し新たなパターンを発見します。Agenticで探索→パターン発見→Workflow化→例外にAgenticで対応、という循環が継続的に回ることで、プロダクトが成熟していきます。「最もシンプルな解を探し、必要なときだけ複雑化する」［3］という方針は、まさにこのプロセスを表しています。
7. AgenticとWorkflowを組み合わせる
こうした進化のプロセスを踏まえると、実際のユースケースではAgenticとWorkflowのどちらか一方だけで完結することはほとんどありません。標準化が必要な領域でも、データの欠損や表記ゆれといった「型が崩れる瞬間」は必ず発生します。逆に、探索的なニーズでも、最終的な回答を分かりやすく提示するにはある程度の構造が必要です。
AgenticとWorkflowを組み合わせることで、再現性と柔軟性を両立できます。この組み合わせには2つのパターンがあります［5］。Workflow-in-Agentは、Agentが決定するが実行は決定的なスキル（サブワークフロー）に委譲する形です。Agent-in-Workflowは、Workflowを背骨にし探索が必要なノードだけAgentに委譲する形です。「繰り返し可能な結果が必要な部分はWorkflow、探索が必要な部分はAgentic」［7］という使い分けで、Workflowをコンテナ、Agenticをコンテナ内で動く探索アルゴリズムとして捉えられます。
組み合わせ方は依頼の性質で変わります。型が確立している領域（商談準備の標準フォーマット、優先度スコアリングなど）では、Workflow主体で情報の補完や例外処理にAgenticを使います。探索的な領域（市場動向の把握、リスク発見など）ではAgentic主体で結論の構成や見せ方にWorkflowを使います。第1章の例で言えば、「A社の商談準備」や「重要案件の優先度順」はWorkflow主体＋Agentic補助、「XX業界で競合が強い領域」はAgentic主体＋Workflowで構成化、という構造です。このように、依頼の性質に応じて主従を変えながら組み合わせることが実践的な設計の鍵です。
今回の記事では踏み込むことができませんでしたが、こうしたAgenticとWorkflowの特性を整理した上で、プロダクトとして一つのMulti-Agent/Workflowシステムを手探りながら設計しています。また別の機会に記事としてまとめたいと思います。
一緒に作りませんか
AIエージェントはまだまだ価値の可能性が広がっている技術です。不確実な部分も多いですが、仮説を立てて検証しながら、着実にプロダクトとして形にしていくプロセスは刺激的かつ野心的でとても楽しいです。
こうした技術的な探索とプロダクト開発を一緒に進めてくれる仲間を募集しています。Agenticなシステムやデータ×AIのプロダクトに興味がある方、不確実性の中でも前に進むことを楽しめる方、ぜひ一緒に働きましょう。
Sansan技術本部ではカジュアル面談を実施しています 
Sansan技術本部では中途の方向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
参考リンク
［1］ Seismic – Execute Sales Plays at Scale
https://www.seismic.com/solutions/use-cases/sales-plays/
［2］ HubSpot Glossary – Ad hoc reporting
https://www.hubspot.com/glossary/ad-hoc-reporting
［3］ Anthropic – Building effective agents (Dec 19, 2024)
https://www.anthropic.com/research/building-effective-agents
［4］ LangChain/LangGraph Docs – Workflows and agents
https://docs.langchain.com/oss/python/langgraph/workflows-agents
［5］ Hugging Face Community – Workflow vs. Agent: a Policy-vs-Script Perspective (Sep 16, 2025)
https://huggingface.co/blog/MengkangHu/workflow-vs-agent
［6］ ReAct: Reasoning and Acting in Language Models (arXiv:2210.03629)
https://arxiv.org/abs/2210.03629
［7］ Vercel AI SDK Docs – Agents: Overview
https://ai-sdk.dev/docs/agents/overview
［8］ OpenAI API Docs – Agent Builder
https://platform.openai.com/docs/guides/agent-builder
