ビジネス向けAI：できること、（および）できないこと

現在、ビジネス向けAIの分野で最も急速に広がっている売り文句は、私たちが毎週のように耳にするものです。それは、「ソフトウェアベンダーとの面倒な交渉をすべてスキップして、週末の間にAIに独自のPOSシステムを作らせる」という起業家の話です。この話は一見、合理的に聞こえます。欲しい機能を説明し、モデルがコードを書き、月曜日には営業を開始する。人々はこの方法で、ランディングページ、社内ダッシュボード、モバイルアプリの骨組みなど、実に素晴らしいものを作り上げています。

しかし、いざ実際の決済を受け付けようとした瞬間、その「週末」は「四半期（3ヶ月）」の開発期間へと変わるのです（この言葉遊び、伝わりますか？）。

このisn't a warning against AI. 私たちはAIを常に活用していますし、AIが実際に何に優れているかを理解している加盟店は、そうでない加盟店の一歩先を行っています。しかし、現在コマースの現場で発生している特有の失敗パターンがあり、それが単に起こるという事実だけでなく、なぜ起こるのかを理解しておく価値は十分にあります。

時期に関する注記：本書は2026年7月に執筆されており、現在多くの人が使用しているモデルはClaude Opus 4.8、Gemini 3.5 Flash、GPT-5.5です。このラインナップはすぐに古くなるでしょう。これらのツールは月単位で変化しており、今日存在する限界が読まれる頃には解決されているかもしれませんし、まだ誰も指摘していない新たな癖が現れているかもしれません。以下の具体的な内容は現時点でのスナップショットとして扱い、実際に運用しているモデルの現在の機能と既知の弱点を確認する習慣をつけてください。

これらのモデルが実際に機能する仕組み

大規模言語モデル（LLM）は予測エンジンです。膨大な量のテキストとコードを読み込んでおり、その本質において1つのことを非常に得意としています。それは、これまでに書かれたすべての内容を踏まえて、次に続く最も可能性の高いテキストの塊を予測することです。それだけです。参照しているデータベースがあるわけでも、正しい事実を照合する内部の台帳があるわけでもありません。最もそれらしい続きを生成しているに過ぎません。

この設計こそが、特定のタスクにおいて魔法のように感じられる理由です。商品説明の作成、メールの下書き、ボタンがきれいに並んだReactコンポーネントの生成などは、パターン補完の問題であり、モデルはこれまでに何百万もの例を見てきました。出力が正しく見えるのは、統計的にそれが正しいからです。

問題は、「最もそれらしい」と「実際に正しい」が一致しなくなったときに始まります。

Hallucination, plainly

モデルが自信ありげに、しかし完全に間違った内容を生成することを、業界では「ハルシネーション（幻覚）」と呼びます。この言葉を聞くと、一時的な不具合（グリッチ）のように思えるかもしれません。しかし、そうではありません。システムが設計通りに動作し、それらしいテキストを生成した結果、そのそれらしさと真実が乖離してしまった状態なのです。

モデルに対して、一部返金を行うためのAPIメソッドを尋ねてみてください。もしモデルが正確な最新のドキュメントを見ていなければ、「分かりません」とは答えません。それは可能性の高い続きではないからです。代わりに、正しい命名規則と妥当なパラメータを備えた、本物そっくりのメソッド名を捏造します。それは非常に説得力があるように読めます。しかし、顧客が返金を求めた瞬間に、そのコードは何も言わずにエラーになります。

これがコマースにおいて他のどの分野よりも重要になるのは、わずかな間違いの代償が「お金の不正確な移動」につながるからです。ブログの導入文のハルシネーションは恥ずかしいだけで済みます。しかし、税金計算、返金フロー、在庫の差し引きにおけるハルシネーションは、チャージバック、監査、あるいは顧客への二重課金を引き起こします。

コマースシステムの構築が想像以上に難しい理由

「POSを作ってほしい」「オンラインストアを作ってほしい」と言うとき、多くの人は画面を思い浮かべています。商品グリッド、カート、チェックアウトボタンなどです。AIはそうした画面を素早く、プロフェッショナルな見た目で作成できます。

しかし、画面は全体の簡単な10%に過ぎません。それを単なるコマースシステムではなく、店舗の絵たらしめているのは、画面の裏側にあるすべての仕組みであり、そのほとんどはレイアウトではなく、状態（ステート）と統合（インテグレーション）です：

決済。お金を受け取るには、決済プロバイダー、加盟店アカウント、PCI準拠、トークン化されたカード処理、およびカードの拒否、一部売上確定、返金、紛争、通貨換算といった無数のエッジケースへの対応が必要です。モデルは決済APIを呼び出しているように見えるコードを書くことはできます。しかし、そのコードが安全で、コンプライアンスに準拠し、エラーケースを正しく処理できているかどうかは全く別の問題であり、それこそが最も重要な問題です。

在庫。在庫は単にページ上に表示される数字ではありません。2人の顧客が最後の1個を同時に購入しようとしたとき、返品が発生したとき、手動での棚卸しによる調整が行われたときにも、常に正確に維持されなければならない数字です。並行処理の制御を誤ると、実在庫以上の販売（オーバーセル）が発生します。モデルは、このような状態変化を伴い、レースコンディション（競合状態）が発生しやすいロジックを苦手とすることで知られています。なぜなら、ここでの正確性は、モデルが関与できない実行時の挙動に依存するからです。

注文履歴と照合。すべての取引は不変のデータとして一度だけ記録され、決済プロバイダーが実際に処理した内容と照合されなければなりません。これは退屈で地味な記帳ロジックですが、会計士や税務当局とのトラブルを防ぐために不可欠な部分です。

税金。税率は地域、商品カテゴリ、顧客の所在地によって異なり、頻繁に変更されます。それらしく見えるだけの税金計算機能は、機能が全くないよりも悪質です。なぜなら、確定申告をするまで気づかないような方法で間違っているからです。

これらはレイアウトの問題ではありません。時間の経過の中で正確性を維持する問題であり、「最もそれらしいコードを生成する」というアプローチは、長期的な正確性を保証するためのツールとしては構造的に間違っています。

AIが真に価値を発揮する領域

私たちはAIをビジネスから遠ざけるべきだと言っているわけではありません。むしろ逆です。小規模な店舗が日々行う業務の大部分は、AIが真の強みを発揮する領域に収まっており、これらにAIを活用していないとすれば、競合他社よりも余計な苦労をしていることになります。

AIに適したタスクの共通パターンは、自信に満ちた最初の下書きが時間を大幅に節約してくれ、その成果物が優れているかどうかを人間がひと目で判断できるというものです。マーケティングやコンテンツ制作は、このパターンに完璧に当てはまります。

広告用画像の生成。撮影費用やストックフォトのサブスクリプション料金を支払う代わりに、広告ビジュアル、商品のモックアップ、SNS用のグラフィックを数分で作成できます。季節限定のプロモーションや、2つのクリエイティブの簡単なA/Bテストにおいて、これは非常に有用であり、コストはほぼゼロです。

SNSの投稿やキャプションの作成。商品情報とブランドのトーンをインプットすれば、自分で1つの投稿を書くよりも早く、1週間分の投稿案を作成してくれます。最終的な編集を行うのは人間ですが、白紙から書き始めるというストレスから解放されます。

広告やニュースレターのアイデア出し。出力された内容がそのまま使えなくても、ブレインストーミングの相手として非常に優秀です。新学期キャンペーンの切り口を20個出すよう求めると、大半は平凡なものですが、2〜3個は採用する価値のあるものが見つかります。自分一人では20個もアイデアを出せなかったはずです。

意思決定の相談。ロイヤルティ特典の構成方法や、次にテストすべき施策など、一般的なビジネス上の質問に対する相談相手として活用します。神託（オラクル）としてではなく、時々自信たっぷりに間違える優秀な同僚として扱えば、非常に有益な思考のパートナーになります。

これらに加えて、レビューやサポートチケットを要約してパターンを特定する、人間が検証するための自動化ワークフローの下書きを作成する、すでに使用しているツールについて「〜する方法」を質問する、といった地味ながらも効果的な活用法があります。

Two caveats that separate good output from obvious AI slop

第一に、AIが生成したビジュアルには既視感という問題があります。デフォルトのスタイルである、光沢があり、少し完璧すぎるグラデーションのポスターは、今や非常に一般的になり、顧客に一瞬で見破られ、安っぽい印象を与えてしまいます。生成画像を使用する場合は、最初の結果で妥協せず、スタイルを変更し、自社のブランドカラーや実際の商品写真を読み込ませ、完成品ではなくスタートラインとしてトリミングや編集を行ってください。他のすべてのAIポスターと同じように見えるポスターは、ポスターがないよりもブランドイメージを損ねます。

第二に、公開する前に必ずすべての内容を校正してください。AIは正しいことと同じくらい自信たっぷりに間違ったことを主張するため、確認を怠ると、ハルシネーションによる誤った価格、架空の商品機能、偽の統計データがそのままニュースレターに掲載されてしまいます。ルールはシンプルです。下書きはAIが作成し、顧客に届く前に必ず人間が承認するということです。すべての言葉に責任を持つ覚悟で、一言一句を確認してください。実際に責任を問われるのはあなただからです。

これらすべてに共通する本質は、AIは自信に満ちた下書きが時間を節約してくれ、その結果を簡単に検証できる領域において極めて優秀であるということです。

逆に、わずかでも、自信たっぷりに間違っていることが金銭的損失につながり、その結果を簡単に検証できない領域においては危険です。

本当に重要な境界線

「AIが私のPOSを作ってくれた」という美談の多くが見落としている重要なポイントがあります。 there's a difference between asking AI to invent commerce logic from scratch and asking it to assemble a store on top of infrastructure that already handles the money correctly.

汎用的なモデルに決済処理、在庫計算、税金ロジックをゼロから書かせる場合、そのすべてにおいて「それらしくて間違っている何か」がハルシネーションされるリスクが常に付きまといます。正確でなければならない部分を予測エンジンに委ねてしまっているのです。これこそが、週末のプロジェクトが四半期に及ぶデバッグ作業へと泥沼化する原因です。

しかし、決済処理、在庫の差し引き、注文台帳、照合といった処理は、店舗ごとに再発明する必要はありません。これらはすべての加盟店が直面する共通の難題であり、エッジケースを熟知した専門家によって、一度だけ正確に解決されるべきものです。その土台がすでに存在し、正常に動作することが保証されているのであれば、AIに残された役割は、AIが本当に得意とする領域、すなわちインターフェースの構築、レイアウトの配置、フローの接続だけです。そこではそれらしさで十分です。なぜなら、人間が結果を目で確認でき、その下にあるお金の動きはすでに安全に処理されているからです。

したがって、教訓は「AIをコマースから遠ざけろ」ということではありません。 be very suspicious of any setup where AI is generating the logic that moves money, and much more comfortable where AI is building on top of infrastructure that already moves money correctly. 前者は予測エンジンに正確性を求めています。後者は、正確性のために構築されたシステムに残りを任せつつ、予測エンジンにその得意分野を遺憾なく発揮させています。

ストアフロントは正確でなければなりません。お金は毎回必ず正しく動く必要があります。大体いつもではありません。コマースにおけるAIの賢い使い方は、AIをどのレイヤーに配置すべきかを知り、その下のレイヤーが決して推測に委ねられないようにすることです。