Ryu｜Shopifyアプリx AI駆動開発

🎉 テックギーク受講生が、Shopify App Storeに公開アプリをリリースしました！ 今回、受講生の「 @nadeshikoweb さん」にインタビュー 受講前は、 「Shopifyアプリって、何をどの順番で作ればいいの？」 という状態 そこから... ↓続きはブログから techgeek-school.com/blogs/%E… #テックギーク

Shopifyアプリを開発しているなら、今週1時間くらいはセキュリティの見直しに使うべき！！ AIのおかげで開発スピードは格段に上がったけど、アプリが本当に安全かどうかは、まだ人間がしっかり確認する必要がある 自分も新しい機能をリリースする前には、こうしたガイドラインと実装を一つずつ照らし合わせてチェックしている これからのAI駆動開発は、速く作れるだけじゃダメ！ 開発スピードと安全性はセットで考えないといけない

Shopifyアプリの開発と受託をしている立場で、今週のEC×AIの動きを整理してみた 
結論から言うと、「AIのお客さん」への対応は、もう将来の検討事項ではなく、今からお店づくりとアプリ設計に入れるべきテーマになったと判断している 根拠は4つ Shopifyは、AIが商品探しから購入まで進められるよう、商品情報や購入の仕組みをAI向けに開いていく方針を出した。
Amazonは、日本でも生成AIを積んだ新しいAlexaの先行提供を始めた。
Googleは、AIが人の代わりに画面を操作する機能を、開発者向けに正式提供した。
そしてマイクロソフトのアクセス解析ツール「Clarity」が、AIが関わったサイト訪問の実データを公開した。 この中で、実務に一番効くのはClarityのデータだ。 520万件の訪問を分析した結果、AIが関わる訪問で一番多い行動は「購入手続き」で25%。
人間は15%だった。
人間の1位は「よそのサイトへのリンクをクリック」で27%、AIはその半分ほど。
AIが関わる訪問は、3週間で88%増えている。 ここから読み取れるのは、AIのお客さんは比較のために来るのではなく、購入のために来ているということだ。
お店にとっては、購入に近いお客さんが増えていることを意味する。 一方で、注意すべき点もある。
このデータには、途中で人間に交代した訪問が含まれている。
AIは購入画面までは来るものの、どこかで止まって人間に引き継いでいるケースがある、ということだ。 その止まる場所は、実際に検証するとわかる。
テスト用のお店で、AIに画面を操作させて注文完了まで進めてみたところ、カートまでは問題なく進んだ。
止まったのは、クーポンのお知らせが表示されたところと、確認のチェック欄だった。
どちらも、人間向けに売上を上げる目的で入れているものだ。 Shopifyのお店には、こうした「購入の前に何かを表示するアプリ」が複数入っていることが多い。
人間相手には効果がある。
ただ、AIのお客さんにとっては、購入を止める壁になる。
しかも普通のアクセス解析では人間とAIの区別がつかないため、お店側は離脱の原因に気づけない。 この状況を踏まえて、お店を運営している方への提案はシンプルだ。 まず、自分のお店で商品ページから注文完了まで進んで、「閉じる」を押した回数と入力した項目の数を確認する。
次に、それぞれがどのアプリから出ているかを洗い出す。
そのうえで、購入を止めてまで出す必要があるものかを判断する。
アプリを外す必要はない。
「閉じなくても進める」状態にするだけで、AIのお客さんの取りこぼしは減らせる。 アプリを作っている方には、設計で次の3つを判断基準にすることを勧めたい。 表示を出しても、それを処理しないと購入に進めない作りにはしない。
ボタンや入力欄には、文字だけで役割がわかる名前をつける。AIは画面の文字を手がかりに操作するからだ。
相手がAIだと判別できる場合は、余計な表示を出さずに通す。 これは技術的に難しい話ではない。
AIを使った開発なら、小さなチームでも十分に対応できる範囲だ。
だからこそ、早く手を打ったお店とアプリから差がつく。 AIのお客さんは、すでに購入画面まで来ている。
あとは、そこで止めないお店とアプリにできるかどうかだ。

Two dates for every Shopify app team's calendar: Jan 1, 2027: move to expiring offline tokens Mar 1, 2027: replace Script Tags The bigger shift is making the security check block every release. The more code AI writes for us, the more that gate matters. nitter.cf/ShopifyDevs/status/211…

Right call. AI made building an app fast and cheap, and I love that. It also made shipping empty apps cheap. The scarce part now is a real merchant problem. My rule: if I can't name the merchant and their pain in one sentence, the app doesn't ship. nitter.cf/blairbeckwith/status/2…

受託の信頼づくりは、作業を始める前の申請画面からもう始まっている。 ストアの管理権限をもらう申請に、申請した側の情報が表示されるようになった。 ・Shopifyでの活動歴の長さ ・登録した国 ・申請がどこから送られたか ・おおよその担当ストア数 開発者向けの管理画面で事業情報を登録し、本人確認を済ませると自動で付く。 誤解されがちなのは、「申請さえ送れば承認される」という感覚。 ストア運営者から見れば、知らない相手に店の中身を見せる判断だ。 情報が空っぽの申請は、それだけで不安材料になる。 受託の現場でも、権限の承認待ちで作業開始が遅れるのはよくある話。 相手が安心できる材料を最初から出しておけば、そのやりとりが減る。 運営者が「誰に権限を渡すか」をきちんと判断できるのは、セキュリティの面でも健全だと思う。 制作会社やフリーランスの人は、今日のうちに事業情報の登録と本人確認を済ませておこう✅

テーマのコードは、人間だけでなくAIも読む前提で書く時代に入った。 新しいテーマの仕組みでは、ページの構成がテンプレートの中に直接書かれるようになった。 これまでは、別の設定ファイルとパーツの組み合わせから全体を読み解く必要があった。 AIに作業方針を伝える説明ファイルや、よく使われるデザインの書き方（Tailwind）も標準で入る。 見落としがちなのは、これが人間のためだけの改善ではないこと。 AIにテーマを触らせると、どのファイルがどこに効いているか追いきれず、関係ない場所を壊すことがある。 上から順に読めば全体がわかる構造は、AIにとっても事故が減る構造だ。 自分もAIにテーマの修正を頼んで、別のページの表示が崩れていたことがある。 ストア運営者が管理画面のAIでテーマを編集する機能（Canvas、先行提供中）も、この仕組みが前提になっている。 AIでテーマを触る人みんなに関係する変化だ。 テーマを扱う人は、次の新規案件を新しい構造で作れるか、今のうちに検証しておこう🧩

Shopifyのストアは、もう「AIが買い物しに来る場所」になった。準備していないとやばい。 秋の大型アップデートで、すべてのShopifyストアと決済画面に、AIが商品検索・カート操作・購入まで進められる窓口が標準で付いた。 購入は買い手が承認してから進む。 AIは画面を眺めてクリックをまねるのではなく、整理された商品データを直接受け取る。 誤解されがちなのは、「AI対策＝AI向けに特別な何かを作ること」だと思われていること。 AIが読むのは、商品名、説明、価格、在庫といった今ある商品データそのもの。 差がつくのは商品データの質だ。 受託で商品データを移行すると、説明文が空だったり、サイズや色の表記がバラバラだったりするのはよくある。 人間のお客さんは写真で補ってくれても、AIは補ってくれない。 同じタイミングで、販売チャネルごとに商品データの不足を確認できる機能も出ている。 ストアを運営する人も、アプリを作る人も全員当事者だ。 まず主力商品を1つ選んで、説明文を「写真なしでも伝わるか」で読み直してみて🛒

Shopifyの自動化ツール「Flow」の作成・更新・削除・オンオフを、外部のAIから自分のストアに対して行えるようになった ただ、AIに自動化を作らせる時代こそ、「何を書き換えられるか」は人間の判断が必須 同じタイミングで、Flowのテストや稼働には、操作する人自身がその処理に必要な権限を持っていることが求められるようになった。 この2つはセットで読むべきだと思う。 AIが自動化を作れるほど、「その自動化が何を変更できるのか」は見えにくくなる。 正直、自分もAIに作らせた処理が「ちゃんと動くか」は確認しても、「どこまで触れるか」は後回しにしたことがある。 これはAIで開発する人みんなに起きる。 ちなみに今動いている自動化は止まらないので、慌てなくて大丈夫。 AIに自動化を作らせたら、有効にする前に「この処理は何を変更できる？」と必ず一度聞こう🔐

まだまだアプリのリリースは続く！ Shopifyアプリ開発に興味がある方は、私がやってるテックギークにご連絡ください！ techgeek-school.com/

アプリは「入れてもらう」より「使い続けてもらう」ほうがずっと難しい。その武器が公式から来た。 Shopifyアプリが、アプリで起きたこと（記事を公開した、問い合わせが来た、など）をShopifyの分析画面に送れるようになった。 ストア運営者は、売上などのストアのデータと並べてアプリの働きを確認できる。 決済画面や会員ページに出すアプリの部品からも、自前のサーバーなしで送れる。 見落としがちなのは、解約されるとき「効果がよくわからないから」と言われることが多いという点。 アプリの中にどれだけ立派な数字を出しても、運営者が毎日見るのはShopifyの分析画面だ。 自分のブログ作成アプリでも、「記事を何本出したか」と「売上」が同じ場所で見えたら、説得力がまるで違うと思っている。 注意点は、買い手の同意が取れるまで送られないことと、個人情報を入れてはいけないこと。 ここは品質の話としてちゃんと守りたい。 アプリを売る人は、まず「運営者に見せたい成果の数字」を1つ決めよう📊

これからのShopifyアプリは「AIに呼ばれる入口」が必要 Shopifyの管理画面にいるAIアシスタント「Sidekick」に、アプリ側から質問を渡して会話を始められるようになった。 対応しているアプリのデータを、Sidekickが改善提案の材料に使えるようにもなった。 見落としがちなのは、これが「便利機能が1つ増えた」だけの話ではないこと。 ストア運営者が最初に相談する相手が、アプリの画面からAIに移り始めている。 自分のブログ作成アプリでも、設定画面の説明を丁寧に書くほど読まれないと感じていた。 迷ったその場でAIに「この記事どう直せばいい？」と聞ける導線のほうが、確実に使われる。 アプリを作る人みんなに関係する変化だ。 今日できるのは、自分のアプリで「ユーザーが一番迷う画面」を1つ決めておくこと。 そこがAIへの入口の一等地になる🚪

会員連携のずれは、新しいデータではなく「過去のデータ」から生まれる。 新しい顧客アカウントで初めてログインした顧客は、Shopify上で「アカウント有効」に変わり、外部システムへの通知も届くようになった。 テーマ側の「アカウントを持っているか」の判定にも反映される。 ここに見落としがちな落とし穴がある。 すでにログインしたことがある顧客は、まとめて「有効」に更新済みで、その分の通知は来ない。 しかも更新日時も変わらない。 つまり「通知が来たら同期する」「更新日時で差分を拾う」作りだと、既存の会員がまるごと漏れる。 受託で外部の会員システムとつなぐとき、この「過去分だけ知らせてくれない」パターンには何度もハマってきた。 新しい動きだけ追っていると、古いデータとずれていく。 通知で同期している人は、一度だけ全顧客の状態を読み直す処理を入れておこう🔁

ついにEditionsの季節がやってきた！ shopify.com/jp/editions/fall…

Shopifyアプリの鍵は「盗まれる前提」で守る時代に入った。 自分のサーバー以外からの操作をはじく制限が、新しく使えるようになった。 正しい鍵を持っていても、登録した住所（IPアドレス）以外から来たらShopifyが門前払いする。 万一鍵が漏れても、他人の手元では使えない。 ただ、見落としがちな点がある。 必要な時だけ立ち上がる「サーバーレス」型の仕組みは、住所が毎回変わるので今はまだ対象外。 公式も「近日対応」としている段階だ。 うちの受託開発もこの構成が多い。 つまり一番恩恵を受けたい人ほど、今は使えない。 だからそれまでは、鍵の置き場所を固めるしかない。 コードの中に直書きしていないか。 誰でも見られる場所に残っていないか。 住所が固定の人は今日設定、そうじゃない人は今日棚卸し。 みんなは鍵をどこに保管してる？

Next Engine 攻撃を検知したら、一旦サービス停止してでも対策したのは英断だったな 脆弱性があったのか、攻撃を検知しただけかはわからんが、リスクを承知の上でのんびり検討するような企業じゃなかったってだけで安心できるな

Polaris Web Components が 2.0 安定版に！ shopify.dev/changelog/posts/…