Confidential · 2025
API 速度検証 完了

アタックリスト作成システム
検証結果・方式選定のご提案

FileMaker Data API を用いたリスト自動生成の速度検証が完了しました。
以下のとおり結果と今後の方針をご提案申し上げます。

担当：関川すず（PFS） 検証日：2025年9月30日
01 · Verification Results

検証結果サマリー

結論：APIでのリスト作成は、実用に十分な速度です。
対象は「アポシスフラグ＝税理士アポシス」の80,307件。条件絞り込みから件数確認まで、最速2秒台で完了しています。
80,307件
検証対象レコード数（税理士アポシス）
2.1秒
パターン1（最速）平均応答時間
4.1秒
前提除外のみ / パターン4 平均応答時間
最大10秒
長期未検索後の初回（ウォームアップ）
検証パターン 件数 平均応答時間 備考
前提除外のみ（12項目適用） 62,206件 約 4.1秒 ベースラインとなる絞り込み
パターン1 1,456件 約 2.1秒 最も絞り込みが効く
パターン4 8,967件 約 4.1秒 実用範囲内
パターン2・3 0件 — 「アポシスレコード作成日」「税理士ファイル【ユーザーフラグ】」が全件空のため。
項目・条件の確認が必要です。
速度のボトルネックについて： 検索時間の大半（約3.5秒）は「アポシスフラグ」の絞り込み処理です。この項目にインデックスを設定できれば、さらに高速化できる可能性があります。
02 · Method Comparison

2つの方式比較

リスト作成の仕組みとして、定期実行（API）とMCP（AI対話型）の2つの方式が考えられます。 それぞれの特性を整理しました。

推奨 · Option A

定期実行（API）方式

現在のリース期限リストと同じ仕組み。条件をルールとして固定し、自動でリストを生成・配信します。

  • +毎回同じ条件で確実に作成できる
  • +AI利用コストが発生しない
  • +スプレッドシートへ自動出力・Chatworkで件数通知
  • +既存の仕組みの延長線で開発できる
  • −条件の変更には設定修正が必要
例：毎週月曜 8:00 に4パターンのリストをGoogleスプレッドシートへ出力し、Chatworkで件数をお知らせ
Option B

MCP（AI対話型）方式

AIに話しかけることで条件を柔軟に変更し、その場でリストを生成・確認できます。

  • +「パターン1で関東だけ」のように言葉で条件調整が可能
  • +条件を試しながら件数確認・絞り込みができる
  • −AI利用コストが発生する
  • −1回のやり取りに数十秒前後かかる
  • −用途ごとに専用のAPI設計が必要
ルールが固定されている今回のアタックリストでは、MCPの柔軟性を活かしにくい状況です
03 · Recommendation

推奨方針

アタックリスト作成は「定期実行（API）方式」をご提案します。
いただいた前提除外条件と4パターンはルールとして明確に決まっているため、毎回同じ品質・コストゼロで作成できる定期実行方式が最適です。
MCPが向いているケース
  • 条件をその都度変えて試したい場合
  • 自然言語での複雑な変換が必要な場合
  • 1回限りの特殊な抽出をしたい場合
定期実行が向いているケース
  • 条件が固定されているルーティン業務
  • 毎週・毎日の定期的なリスト生成
  • コストを抑えて安定稼働させたい場合
将来的なMCP活用
  • 通話履歴の分析・サマリー
  • 複雑な条件の探索的抽出
  • ※用途が決まった時点で専用APIを構築
まずは定期実行で運用を開始し、「この業務にはAI対話が必要」という具体的なユースケースが出てきた段階でMCPを追加する進め方も可能です。
04 · Open Questions

構築にあたり確認が必要な事項

定期実行方式で構築を進めるにあたり、以下の点をご確認いただけますでしょうか。

項目・フィールドの確認

  • 1
    訪問日（アポ日）に使うフィールドはどれですか？
    「アポシス_訪問日」「訪問予定日」「顧客カルテ_訪問日」の3項目が存在します。
  • 2
    「退会フラグ」に相当するフィールドはありますか？
    該当する項目が見当たりませんでした。項目名をお知らせください。
  • 3
    「アポシスレコード作成日」「税理士ファイル【ユーザーフラグ】」は実際に値が入っていますか？
    検証では全件空のためパターン2・3が0件になりました。
  • 4
    「前回結果_〇〇_Cnt」は全期間の累計ですか、期間区切りの回数ですか？
    条件の意味が変わるため確認が必要です。
  • 5
    受注の除外に「最終特別プラン受注日」も含みますか？
    含める・含めないで件数が変わります。

判定ロジックの確認

  • 6
    「アポ禁・BPNG」の判定は「最終コール結果」（最後の1回）でよいですか？
    過去の全履歴を対象にする場合は、別途項目の追加が必要です。
  • 7
    「直近1ヶ月の返事待ち・再営業」は、どのフィールドの日付で判定しますか？
    現状、判定に使える日付項目が特定できていません。
  • 8
    「直近の連続留守3回以上」の「連続」はどう判定しますか？
    現在の「前回結果_留守_Cnt」は累計値のため、連続かどうかの判定ができません。
  • 9
    携帯番号の判定は「070/080/090始まり」でよいですか？
    ハイフン入り形式が多いため、この方法で対応する想定です。
  • 10
    再コール日時は「次回コール日」、長期見込みは「最終長期日」を使う想定でよいですか？
05 · Next Steps

今後のスケジュール

〜 10月10日（金）
方式の方向性確定
上記の確認事項をご回答いただき、定期実行 or MCP のどちらで進めるかを決定します。
10月10日（土）
技術詳細の打ち合わせ
方向性が決まった状態で、具体的な実装・スケジュール・費用感をご案内します。
10月19日 以降
開発・構築開始
ご確認いただいた仕様をもとに構築を進めます。
進め方の提案： 定期実行方式で構築を開始し、「通話履歴の分析」など具体的なAI活用ユースケースが出てきた際に、改めてMCPの追加構築をご提案します。 用途に応じて最適な方法を選ぶことで、コストと利便性のバランスが取れた運用が可能です。