私たちはAIにサポートチケットを発行しました。するとAIは統合を再構築し、問題を解決しました。

Claude CodeとAPIANTが、複雑な複数決済同期バグを、最終的に人間が承認するだけで検証済みの修正へと導いた方法。

これは CRMConnect（シーアールエムコネクトAPIANTのターンキー統合ソリューションは、MindbodyとHubSpotを常に同期させます。クライアントデータ、重複排除、フィールドマッピングを処理するため、マーケティングチームは古いエクスポートデータではなく、実際の活動に基づいて作業を進めることができます。ここで特に注目するのは、Mindbodyの売上をHubSpotの取引に変換する部分です。これにより、収益が自動的にCRMに反映され、適切な金額が適切なクライアントに紐付けられます。

顧客は受付で約8,400ドルを支払いました。CRM上の取引額は400ドルでした。エラーは発生しておらず、システムにも異常は見られず、ほとんどの売上データは正常に同期されていました。しかし、この取引はMindbodyとHubSpot間のどこかで、いつの間にかその価値の大部分を失ってしまったのです。

最悪なのは、わずか2%の異常な取引に潜むバグです。今回はAIに任せ、診断から修正テスト、顧客への返信まで、すべてをAIに任せました。その過程をご紹介します。

チケット

ある小規模フィットネススタジオから、ちょっとした困った問題が報告された。彼らの売上のほとんどは、MindbodyからHubSpotへ問題なく流れていたのだが、この1件だけはそうではなかったのだ。

原因は、複数の支払い方法が混在していたことだった。支払いをカードと口座残高に分割した場合、従来の同期システムはすべての支払い方法が含まれていないレポートを読み込んでいた。そのため、顧客が実際に支払った金額のごく一部しか決済されなかったのだ。

これは通常、ゆっくりと苦痛を伴う解決策である。

このようなバグは通常、数日間のエンジニアリング時間を要します。統合の仕組みを再構築し、複数の同期パスのうちどれに問題があるのかを特定し、既に正常に動作しているパスを壊さずにロジックを変更し、そして実際に手を加えるのが難しい本番システムでテストを行う必要があります。POSソフトウェアは、「奇妙な分割払い販売を作成する」ボタンを備えたサンドボックス環境をそのまま提供してくれるわけではありません。

そのため、問題は放置されがちです。顧客は待たされ、修正にはリスクが伴います。稼働中のシステム統合に手を加えることには、誰もが多少なりとも不安を感じるものです。

代わりにAIに任せた

私たちはチケットをAPIANT上で動作するClaude Codeに渡し、実際に動作させました。「コードスニペットを提案する」のではなく、実際に動作させました。つまり、統合内容を読み、理解し、変更を加え、実際のMindbodyアカウントでテストし、結果を報告しました。以下は、人間が一行もコードを書かずに実行された結果です。

真の原因が判明した。 調査の結果、一つの症状の裏に隠れていた３つの別々の問題が判明した。同期処理が一部の支払いタイプを欠落させたレポートを読み取っていたこと、複数商品の販売が正しくカウントされていなかったこと、そして複数の販売が同じ識別子で重複して計上される可能性があったことである。

統合が正しく再構築されました。 応急処置ではなく、取引ロジックをリファクタリングして、即時同期（販売が発生した瞬間に起動）と夜間同期の両方で使用される共通コンポーネントにしました。同じロジックで2つのトリガーを使用するため、両者のずれはなくなりました。また、アカウント残高や会員残高を含むすべての支払いを網羅した、より豊富なデータソースに両者を移行しました。

それによって、大規模な処理も高速化できた。 キャッシュを追加することで、夜間ジョブが過去の数千件の販売データに対して時間のかかる検索を再度実行しないようにしました。最初の実行でキャッシュが構築され、それ以降の実行では負荷の高い検索がスキップされます。

顧客が求めていた詳細情報を追加した。 各取引には使用された支払い方法が記録されるため、スタジオは売上がどのように支払われたかを一目で確認できるようになった。

そして、実際のシステムでテストを行った。

この部分は、まだ少しSFっぽい感じがする。

AIはブラウザでMindbodyのPOSシステムを開き、テスト販売を自ら実行した。1つの商品を1回で支払う。1つの商品を2回に分けて支払う。複数の商品を1回で支払う。複数の商品を複数回に分けて支払う。顧客記録のない来店客。AIはまるで店員のようにレジ操作を行った。

次に、各販売が統合プロセスを通過する様子を監視し、結果を一行ずつ読み取りました。正しい数の取引が作成されたか？金額の合計は販売総額と一致したか？支払い方法は表示されたか？同期を2回実行したことで重複が発生したか、あるいは既に販売処理済みであることを正しく認識したか？

すべての支店で確認済み。金額は一致。重複なし。支払いは完了。

それは自らの間違いに気づいた

途中で、システム自体の変更によって小さな不具合が発生した。新しいフィールドが正しく設定されておらず、新規取引の作成がひっそりとできなくなってしまったのだ。

AIは、自身の作業が正しいと決めつけるのではなく、実際の実行データを読み取っていたため、問題に気づきました。正確な原因を特定し、配線を修正し、実際に失敗した販売を再実行し、修正によって正しい結果が得られたことを確認し、その過程全体を文書化しました。

それが、コードを生成することと、結果に責任を持つことの違いだ。

顧客とのやり取りを完結させた

修正が確認されると、AIは顧客への返信を平易な言葉で作成しました。何が起こっているのか、なぜ金額が間違っているように見えるのか、今後どのような変更があるのか、そして過去の売上は次回の同期時に自動的に修正されるという安心感を与える内容です。AIはそのメッセージをチケットに準備し、送信できるようにしました。

人間がそれを読んで同意し、送信しました。変更を本番環境に公開する最終承認も人間が行いました。これは意図的なものです。AIは重く、正確で、根気のいる作業を担当します。しかし、常に人間が判断すべき2つの決定、つまり顧客に何を伝えるか、そして実際に本番環境に何を公開するかについては、人間が責任を持って決定します。

1つの解決策で、すべてのお客様を

統合構築を生業としている人にとって重要なのはここです。これは単一のアカウントに付け足された単発のスクリプトではありません。MindbodyとHubSpotの同期は製品化されたものです。 APIアプリ：単一の統合が単一の場所で構築および保守され、それを使用するすべての顧客に適用されます。そのため、AIが取引ロジックを再構築したとき、この特定のスタジオだけを修正したわけではありません。その統合を利用するすべての顧客に対して、同じ分割払いのギャップを解消し、すべての新規顧客は初日から修正されたバージョンを利用できるようになります。

これこそ、システムインテグレーターが常に求めているモデルです。ソリューションを一度構築し、何度も販売し、一箇所で改善する。このような修正によって、インストールベース全体の製品品質が一斉に向上します。これこそが、製品化された統合を、顧客ごとに個別にカスタマイズする作業の山ではなく、真の継続的な収益を生み出す資産へと変える鍵となります。そうすることで、顧客が増えるにつれて脆弱性が増していくのを防ぐことができるのです。

APIANTがこれを可能にする理由

AIは、目に見えるものや触れることができるものしか操作できません。ほとんどの統合プラットフォームはブラックボックスであるため、AIは外部からの提案しか書き込むことができません。

APIANTは、これとは逆のアプローチで構築されています。すべての統合は、AIが実際に検査、編集、実行できる要素で構成されています。自動化、共有サブルーチン、フィールドマッピング、リアルタイム実行履歴、キャッシュ値などです。AIは、要素の一部を変更して実行し、各ステップで何が起こったかを正確に読み取り、調整することができます。これにソースシステムのブラウザ制御を組み合わせることで、推測ではなく現実に基づいたテストが可能になります。

その組み合わせこそが、一つの厄介な実務上のチケットを、完全かつ検証済みのリファクタリングへと変えることを可能にしたのです。

要点

これはおもちゃの問題ではなかった。2つの重要なシステム間のライブ統合における、複数の原因が絡み合った微妙なバグであり、通常であれば、神経質なエンジニアと閑散とした1週間を意味する類のものだった。

AIが最初から最後まで全てを処理しました。根本原因を診断し、正しい方法で統合を再構築し、実際の販売時点情報管理システムに対してあらゆる経路をテストし、自身のエラーを検出して修正し、顧客への返信文を作成しました。人間が介入したのは、メッセージの承認と展開のみでした。

これから向かうのはまさにこの方向です。単にコードを少し書いてくれるAIではなく、難解で具体的な問題を、まさにそのために構築されたプラットフォーム上で、動作確認済みのソリューションへと導くAIです。ほぼ完璧な統合機能や、ごくまれな2%のケースでしか発生しないバグがある場合、それらを解決する方法は、まさにこのような形になりつつあります。

APIANTについて教えてください