FinalがAI生成と実際の取引とのギャップを埋める仕組み
AI生成を使えば数分で動作するレジ画面を作成できますが、決済を確定することはできません。FinalがどのようにしてAI構築フローを、実際の資金を扱う決済、在庫、レポートなどのインフラにデプロイするのか解説します。

Finalは意図的な分離によってこのギャップを埋めています。AI生成はPOSのソフトウェアレイヤー(店舗ごとに固有であるべき画面、フロー、機能)を生成します。ポイントは、そのレイヤーが、Finalが手作業で構築したトランザクションレイヤー(すべての加盟店で同じように動作する決済、在庫管理、レポート出力、認定カードリーダー)上にデプロイされることです。モデルはレジ画面を設計しますが、お金の決済処理を行うことはありません。(本記事で言及しているAIツールやプロトコルの詳細は変化が早いため、公開時点の正確な情報としてお読みください。)
AI生成は実際に何を生成できるのか?
懐疑派が予想する以上であり、ビジネスが必要とするレベル未満のものです。優秀なモデルに明確な要件(ブリーフ)を与えれば、商品グリッド、カート、カスタマー画面、割引、書籍などのロジックを備えた動作するレジ画面が生成されます。その部分は本物であり、進化し続けています。POSのバイブコーディングを試したことのある人なら、最初の1時間は魔法のように感じられるでしょう。
しかし、出力されるのはどこまでもソフトウェアに過ぎません。生成されたアプリには、カードネットワークとの接続も、デバイス間で共有される在庫台帳も、経理担当者が受け入れられるようなレポート機能もありません。モデルの性能が高かろうが低かろうが、同じ壁が存在します。Webアプリをワンショットで生成できるモデルであっても、実際に稼働するPOSをワンショットで構築することはできません。取引のシミュレーションはできても、取引を完了させることはできないのです。
実際の取引には何が必要か?
生成ステップでは考慮されないすべての要素です。顧客がカードをタッチした際、決済は認定された端末ハードウェア(対面カード決済の承認を受けたリーダー)で承認され、決済プロセッサーを通じて清算され、1分1秒・1円単位で一致する帳簿(レジャー)に記録される必要があります。2つのレジで同時に最後の1個が売れた際にも、在庫は正確に維持されなければなりません。税金の計算、領収書の印刷や送信、返金時の正確な処理、そしてインターネットが切断された際にも動作し続けることが求められます。

これらは加盟店ごとに個別に生成されるべきものではありません。毎回同一で、着実で、正確である必要があり、これこそ加盟店ごとのコード生成が苦手とすることです。ギャップを1文で言えば「AIが生成できるのはビジネスごとに異なって良いレイヤーであり、その下のインフラレイヤーは一切異なってはならない」ということです。
Finalはどのようにしてこの2つを接続するのか?
「生成」ではなく「デプロイ」を製品化することによってです。FinalのプロンプトベースAIビルダーであるBuildでは、希望するPOSを説明すると作成されたフローがレジ端末にデプロイされ、実際のデータ(商品カタログ、カート、決済、印刷、オフライン処理を含む)に対して動作します。基本事項についてはBuildをはじめようで解説しています。
お好みのモデルを使いたいですか?その場合は「自分のAIを接続(MCP)」を選択すると、Buildが1つのテキストブロック(サーバーアドレス、ワンタイムキー、構築ブリーフ)を生成します。それをClaude Code、Cursor、ChatGPT、または外部システムとAIアプリケーションを接続するためのオープン標準であるMCPに対応したその他のクライアントに貼り付けます。ツールがフローを構築し、ライブプレビューで完成していくレジを確認しながら、Buildからデプロイできます。ステップバイステップのガイドはヘルプセンターにあります。これはAPI経由で既存アカウントを操作するのではなく、POSを構築・デプロイすることを意味しており、業界全体で重要な違いとなります。これについてはすべての小売プラットフォームにMCPサーバーが必要となる理由で詳しく解説しています。

ここからがギャップを埋める連携の瞬間です。カードがタッチされた瞬間、AIが設計したフローは、すべてのFinal加盟店が使用している同じFinal Payレールを呼び出し、モデルが触れることのない決済プロセッサーを通じて決済が完了します。AIはレジの見た目や挙動を決定しますが、お金がどこに流れるかを決定することはありません。
生成コードに決済APIを直接接続しない理由は?
オンラインでの非対面決済であれば、それも可能であり多くの人が行っています。難しいのは、実際に対面でカードが提示されたときです。対面決済には認定リーダーが必要であり、生成されたコードにそれを組み込むと、PCIの適用範囲(カード業界のセキュリティ規則)に入り、あなたがその責任を負うことになります。さらに、デモでは見せられない業務(適切な支払い方法への返金処理、一日の終わりの売上照合レポート、チャージバック、忙しい土曜日に認証途中で切断された決済の処理など)が発生します。

決済APIを貼り付けただけの生成アプリは、法的責任が伴うレジデモに過ぎません。Finalでは、これらの業務はプラットフォーム側の責任であり、価格設定にもそれが反映されています。コアプラットフォームに月額ソフトウェア料金はなく、加盟店はトランザクションごとに料金を支払います。取引そのものが製品だからです。入れ替え可能なAIレイヤーと堅牢なインフラレイヤーのこの分離こそが、Finalが単なるAIラッパーではない理由でもあります。
それでは、Finalはどのようにしてギャップを埋めるのか?
ビジネス独自であるべきレイヤーはAIに生成させ、常に正確でなければならないレイヤーはモデルの手が届かない場所に維持することによってです。あなたのプロンプト、または接続された独自のモデルがフローを生成します。その下でFinalのインフラが承認、決済、計上、照合を行います。基本原則:AIがあなたのPOSを構築したのなら、最初のカードがタッチされたときに何が起きるかを確認してください。その答えに認定ハードウェアと実際の決済処理が含まれているなら、ギャップは埋められています。一連の流れを確認してみましょう。Buildで希望するPOSを説明するか、MCP経由で独自のAIを接続し、実際の取引のために構築されたインフラストラクチャ上にデプロイしてみてください。
よくある質問
AIはFinal上で決済処理を行いますか?
いいえ。AIは画面、フロー、機能といったソフトウェアレイヤーの設計と組み立てを行います。決済は認定端末ハードウェアで承認され、モデルが一切介入しないFinal Payおよび決済プロセッサーを通じて清算されます。
Final上でPOSを構築できるAIツールは何ですか?
Final独自のビルダーであるBuildはプロンプトから動作します。また、Claude Code、Cursor、ChatGPT、CodexなどのMCPクライアントを接続して、ライブプレビューで確認しながらフローを構築し、Buildからデプロイすることもできます。
AI構築フローをデプロイするとどうなりますか?
Final POS端末上で実際のデータ(カタログ、カート、決済、印刷)を使用して動作し、オフラインでも機能し続けます。単なるデモではなく、ビジネスを支える本番システムとなります。
AIが生成したアプリに決済APIを追加するだけではダメなのはなぜですか?
オンライン決済なら可能です。対面決済には認定済みのカードリーダーが必要であり、自作のコードに接続すると自社がPCIコンプライアンスのスコープ対象となり、照合、返金、チャージバックの管理をすべて自ら行う必要があります。
これを使用するにはプログラミングの知識が必要ですか?
いいえ。構築はプロンプトベースで行えます。必要なPOSを自然言語で説明するだけです。独自のAIの接続も、生成された1つのブロックを既にお使いのツールにコピー&ペーストするだけです。
