AI Enablement

AIエージェント開発

AIエージェントを、PoCで終わらせない。

曖昧さはAIに。確実さはコードに。重要な操作は、人の承認に。

決定論×LLMのハイブリッド設計と評価駆動の運用で、

「監査できて、止められて、改善し続けられる」

AIエージェントを、本番運用まで引き受けます。

Our Approach

「賢さ」ではなく、
「任せられる構造」をつくる。

デモで動くAIエージェントと、業務を任せられるAIエージェントは、別物です。Gartnerは、エージェント型AIプロジェクトの40%超が2027年末までに中止されると予測しています。理由はコストの増大、ビジネス価値の不明確さ、そしてリスク統制の不備——つまずきの多くはモデルの賢さではなく、設計と運用にあります。

スパイスファクトリーのAIエージェント開発は、「何をAIに任せ、何を任せないか」の設計から始めます。計算・権限判定・確定操作など間違えてはいけない仕事は決定論的なコードに固定し、意図の解釈や言語化といった曖昧さの処理だけをLLMに委ねる。このハイブリッド設計により、ハルシネーションや悪意ある入力のリスクを「確率を下げる」のではなく「構造で封じ」ます。

そして、作って終わりにしません。版管理・評価ゲート・コスト可視化を備えた管理基盤を標準装備し、次々と世代交代するAIモデルを、業務を止めずに比較・切替できる状態でお渡しします。この設計と基盤は、当社自身が自社の営業DX基盤で本番運用してきたものです。

役割分担マップの図。決定論(コード)は計算・集計、権限判定、確定操作といった間違えてはいけない仕事を、LLMは意図の解釈や言語化・要約といった曖昧さの処理を、人間は承認・例外対応といった最終判断を担う。業務を分解し、各ステップを仕分ける。

そのお悩み、スパイスファクトリーで解決しませんか?

Issue 01

PoCでは動いたが、
品質とセキュリティが本番に耐えない。

課題

デモは動いても、
稟議が通らない

本番データでは数字を間違える。プロンプトインジェクションで想定外の動作をする。誤った操作が実行されるリスクを説明できず、稟議が通りません。

転換

「LLMに何をさせないか」
を先に設計する

まず業務を分解し、各ステップを「決定論(コード)/LLM/人間」に仕分ける役割分担マップを作ります。

解決策

危険な経路から、
LLMを構造的に外す

数字はコードが集計し、確定操作は人の承認かコードの検証を必ず通す。本番に耐える品質とセキュリティを設計段階で担保します。

Issue 02

モデルの世代交代と運用に、
追従できない。

課題

切り替えるのが怖いまま、
塩漬けになる

作った時点で最適だった構成はすぐに古くなる。プロンプトを少し直しただけで挙動が変わり、誰も品質を保証できません。

仕組み

合格しない版は、
公開できない

プロンプト・モデル・パラメータを版として管理し、新しい版はゴールデンセットの評価に合格しない限り公開できません。防ぐのは注意力ではなく、コードです。

解決策

新モデルの登場が、
「配当」に変わる

評価ゲートと版管理を標準装備し、業務を止めずに比較・切替できる状態でお渡しします。新モデルは脅威ではなく、安全に取り込める配当になります。

Issue 03

何をAIに任せてよいか、
誰が責任を持つのかが決まらない。

課題

向き不向きも、
責任の所在も曖昧

どの業務が向いているのか判断できない。事故が起きたとき誰が止めるのかが曖昧で、情報システム部門・法務の承認が得られません

設計

自律性は、
段階で設計する

「読み取る→下書く→承認付きで実行する→自律的に実行する」の段階で、どこから始め、何が確認できたら次へ進むかを設計します。

解決策

社内説明と監査に、
そのまま使える成果物

責任者・承認者・停止者・復旧者を定めた責任分界表、AIリスク台帳、停止・復旧設計を成果物として納品します。

Feature01

決定論×LLMのハイブリッド設計。ハルシネーションを構造で封じる。

LLMの出力する数字を信じてよいか?——当社の答えは「数字はLLMに作らせない」です。集計・計算は決定論的なコードが実行し、LLMは意図の解釈と結果の言語化だけを担う。メール下書きなら、本文の生成はLLM、URLや署名の挿入はシステム側です。

外部から来るテキストは「命令ではなく信頼できないデータ」として区切って扱い、最小権限・出力の検証・人間承認・攻撃ケース評価を重ねる多層防御で、プロンプトインジェクションの影響を抑えます。

この設計思想と実装パターンの詳細は、オピニオン記事「LLMに数字を作らせない」で公開しています。

メール下書きの役割分担図。本文の文章はLLMが生成し、宛先・件名・URL・署名はシステムが固定する。間違えてはいけない経路にLLMを入れない。

Feature02

評価駆動の開発と運用。ゴールデンセットが品質を守る。

構築の最初期に、正常系・境界ケース・攻撃ケース(プロンプトインジェクション等)を含むゴールデンセットをお客様の業務有識者と共同で作成します。これが受入基準となり、以後すべての版はこの評価に合格しない限り本番に出られません。

リリース後も、リスクに応じて評価の濃淡を使い分けながら、現場のフィードバックを評価ケースへ還流し続けます。作った瞬間がピークではなく、使うほど良くなるエージェントに育てます。

管理基盤の考え方は、オピニオン記事「AIエージェントは『作って終わり』にできない」で公開しています。

評価ゲートのフロー図。新しい版はゴールデンセット評価に合格したものだけが公開され、不合格はコードが公開を拒否する。本番運用からのフィードバックが評価へ還流する。

Feature03

責任と運用まで設計する。監査できて、止められる。

エージェントには最小権限を与え、すべての実行を監査ログに残し、いつでも止められるkill switchを備えます。

導入時には、責任者・承認者・停止者・復旧者を定めた責任分界表(Human-Agent Operating Model)と、OWASP LLM Top 10 や経産省AI事業者ガイドライン等を参照したAIリスク台帳を納品。「事故が起きたらどうするのか」に、仕組みと文書の両方で答えられる状態を作ります。

運用フェーズでは品質・コストの監視からモデル更改までを引き受け、ご希望に応じて内製化への移管も伴走します。

監査できて止められる運用の4項目。01 最小権限は必要な権限だけを付与、02 監査ログはすべての実行を記録、03 kill switchはいつでも止められる、04 責任分界表は誰が止めるかを明文化。

Service Menu

提供メニュー

  1. これから始める方に

    エージェント
    適合性アセスメント

    業務を分解し、「決定論/LLM/人間」の役割分担マップと自律性レベルを設計。データの整備状況も診断し、投資判断の材料をまとめて提供します。

    主な成果物

    • 役割分担マップ
    • 自律性設計書
    • データレディネス診断
    • ゴールデンセット初版
    • AIリスク台帳・責任分界表
    • 概算ROI・コスト試算
  2. PoCで止まっている方に

    PoC本番化診断

    他社開発・内製を問わず、既存のPoCを持ち込みいただけます。本番化を阻んでいる要因を診断し、活かせる資産と直すべき構造を仕分けた本番化ロードマップを提示します。

    主な成果物

    • 本番化阻害要因の診断レポート
    • 本番化ロードマップ
    • 概算見積り
  3. 本番導入を決めた方に

    エージェント本番構築

    管理基盤(版管理・評価ゲート・コスト可視化)を標準装備してエージェントを構築。評価ゲート合格を完成の定義とし、最小権限・監査ログ・kill switch を備えて段階的に本番へロールアウトします。

    主な成果物

    • エージェント本体+管理基盤
    • 評価レポート
    • 運用Runbook
  4. 運用と改善を続けたい方に

    エージェント運用・内製化移管

    品質・コストの監視、定期再評価、新モデルへの安全な切替、現場フィードバックの評価セットへの還流までを引き受けます。将来の内製化に向けた基盤移管・チーム立ち上げ支援も提供します。

    主な成果物

    • 月次品質・コストレポート
    • モデル更改の実施
    • 定着支援(利用率等のトラッキング)

すべてのメニューは段階ごとに完結し、各段階の終わりに継続・撤退をご判断いただけます。

Case Study

自社の営業DX基盤で、
本番運用しながら磨いた設計です

当社は全社で利用する自社開発の営業DX基盤の上で、営業データの分析Q&A、ホットリードへのメール下書き、名刺読み取りなど、複数のAIエージェント・AI機能を対象部門で本番運用しています。モデルの世代交代の際も、ゴールデンセットの評価ゲートを通して業務を止めずに切替えてきました。

数字はLLMに作らせずコードが集計する設計、版管理・評価ゲート・コスト可視化の管理基盤、攻撃ケースを同梱したゴールデンセットによる耐性検査——この実践から得た設計パターンと失敗の教訓を、お客様のエージェント開発にそのまま持ち込みます。

※自社プロダクトにおける実績です

よくあるご質問

Copilot Studio や Agentforce など、既存プラットフォームのエージェント機能との違いは何ですか?

既存プラットフォームは、そのSaaSが持つデータと権限の範囲では強力な選択肢です。一方、複数システムを横断する業務、自社固有の業務ルールや承認フロー、確定処理の厳密な作り込みが必要な業務は、プラットフォームの枠内では実現が難しい領域です。当社はその領域を、ハイブリッド設計と管理基盤で本番運用まで引き受けます。既存プラットフォームで足りる要件だと判断した場合は、その旨を診断段階で率直にお伝えします。

他社で開発したPoCの相談もできますか?

できます。「PoC本番化診断」は他社開発・内製を問わず持ち込み可能です。作り直しありきではなく、活かせる資産と直すべき構造を仕分けたうえで本番化の道筋を提示します。

特定のAIモデルやクラウドにロックインされませんか?

特定モデルへの依存を抑える設計を標準とします。プロンプト・評価ケース・監査ログは移管可能な形式で管理し、評価ゲートを備えているため、より良いモデルが登場した際は安全に比較・切替できます。基盤自体も、お客様のクラウド環境への展開や既存製品(クラウドベンダーのエージェント基盤・LLMOps製品)との統合を選択でき、内製化移管まで見据えた構成にします。対応するモデル・クラウド・移管の範囲は、案件の要件に応じて個別に合意します。

社内データが整備されていなくても始められますか?

アセスメントの中でデータレディネス(データ品質・権限・API有無)を診断します。エージェント導入より先にデータ整備が必要と判断した場合は、無理にエージェント開発を進めず、データ整備・API化を先行するプランをご提案します。

セキュリティや監査への説明はどうなりますか?

最小権限・監査ログ・停止手段(kill switch)を実装で担保し、責任者・承認者・停止者・復旧者を定めた責任分界表とAIリスク台帳を納品します。OWASP LLM Top 10 や経産省のAI事業者ガイドライン等を参照した対応表により、情報システム部門・法務・監査への説明にそのまま使えます。

どのような業務がAIエージェントに向いていますか?

判断の物差しは「間違えたときのダメージ」と「曖昧さの度合い」です。曖昧さの処理(自然言語の解釈・非定型入力)を含み、かつ確定操作を人の承認やコードの検証で守れる業務が適しています。完全自律で確定操作まで任せる構成は初手では推奨せず、「読み取り→下書き→承認付き実行」と段階的に自律性を上げる設計をとります。ダウンロード資料に業務判定表を収録していますので、ご活用ください。

費用はどのくらいかかりますか?

業務の範囲・自律性のレベル・接続するシステムにより異なるため、個別にお見積りします。アセスメント・診断は小さく始められる価格設定です。費用の目安(価格レンジ)はダウンロード資料「AIエージェント実践ガイド」に掲載していますので、あわせてご覧ください。

小さく試すことはできますか?

できます。すべてのメニューは段階ごとに完結し、各段階の終わりに継続・撤退を判断いただけます。アセスメントの結果「導入しない」という結論になった場合も、役割分担マップやリスク台帳は今後の投資判断の資産として残ります。

堅いご挨拶も、資料の準備もいりません。
まずはお話を聞かせてください。

お問い合わせをする お問い合わせをする