SFAをAPI-firstで作り直した話 — AIエージェントから操作できる営業システム

既存のSFA（営業支援システム）から乗り換える、というプロジェクトをやりました。最終的に決めたのは、既存のSaaSに乗り換えるのではなく、API-firstの社内SFAを自社で作ること。理由は、SalesforceやHubSpotには「AIエージェントが直接操作する前提」の設計が無かったからです。今、社内で本番稼働しているSFA（Open SFA）の作り方を書きます。

既存SaaSのSFAを離れた理由

選択肢として既存SaaSのSFAも検討しました。機能は揃っているし、運用ノウハウも世の中に多い。普通の選択ならこれです。

ただ、私たちが欲しかったのは「AIエージェントから営業データを直接読み書きできる」状態でした。「今月のパイプライン状況を分析して、ボトルネックを教えて」と Claude に聞いて、Claude が直接SFAのAPIを叩いて答える。この体験を、既存SaaSのAPIで実装しようとすると、API設計がAIエージェント向けに作られていないので、間にラッパー層を作る必要があり、結局自分で作るのと同じくらいの手間になることが分かりました。

API-firstで全機能を設計し直した

新しいSFAは、最初から OpenAPI 仕様つきの REST API として設計しました。案件CRUD、取引先マスタ、予算管理、承認ルール、帳票・押印ワークフロー — 全部の機能が API として呼べます。Web UI は人間向けに最小限を作っただけで、業務上の機能は API 側にあります。

OpenAPI スキーマをそのまま Claude のツール定義に渡すと、何の設定もなく Claude が SFA を操作できます。「Stage4 以上で金額500万超の案件を一覧で」「未紐付け案件をマスタに統合して」のような操作が、自然言語からそのまま実行されます。

運用してわかったこと

効果が大きかったのは、営業分析のスピードが10倍以上速くなったことです。以前は「先週のパイプライン推移」「今月のステージ別の件数」のようなレポートを作るのに、データを CSV エクスポートして Excel で集計、というステップが必要でした。今は Claude に話しかければ、その場で答えが返ってきます。

もう一つは、営業担当者のSFA入力負荷が下がったこと。商談メモを Slack に流せば、Claude が解釈して該当案件のステージや次のアクションを SFA に書き戻す。手入力するエンジニアは時間が浮き、データ品質も上がりました。

設計判断のポイント

重要だった判断を3つ書きます。(1) 認証は Google OAuth で社内ドメイン限定。AIエージェントの暴走を防ぐため、API トークンは「人間と紐づいた発行」しかしません。(2) main 直 push 禁止・全 PR にレビュー必須。AIに修正させる場合も人間が必ず確認します。(3) OpenAPI スキーマを正としてコードを生成する。スキーマと実装がズレないように、コード生成を CI に組み込んでいます。

これらは、AIが直接データを触れるシステムを社内で稼働させるための、ガバナンス設計です。技術より、組織にどう馴染ませるかの方が時間を使いました。

これから外に出したいと思っている理由

Salesforce/HubSpot からの乗り換え相談が、ここ最近増えています。理由は「AIエージェント前提の運用にしたい」「既存SaaSの月額が事業規模に合わない」「営業のデータ入力負荷を下げたい」など様々です。

ベータテストでは、既存SFAからのデータ移行・組織構造の反映・承認ルールの実装まで、要件次第で個別に設計します。本番稼働中の構成をそのままご提供できます。サービスページに詳細を載せています。