WordCamp Kansai 2025 ふりかえり

2025年11月1日(土)〜2日(日)に開催された WordCamp Kansai 2025 に実行委員として参加しましたので、ふりかえり記事をここに残しておきたいと思います。

私の役割としては、委員長チーム・スポンサーチーム・会場/当日チームを担当しました。
また、自社株式会社Webの相談所はブロンズスポンサーとして参加しました。

今回の WordCamp はイベント全体を通して、関西の WordPress コミュニティらしさを感じられるいい WordCamp だったのではないかと思っています。

その証拠に開催から1週間が経過した今でも、X のハッシュタグ #wckansai2025 に「ふりかえりのブログ記事を投稿した!」というポストがあることは、実行委員としてとてもうれしいことです。(ふりかえりブログ記事一覧は公式サイトにもまとめられています。)

参加者のみなさんにお願いしたアンケートにも快くご回答いただき、満足の声を続々と寄せてもらって、安堵しています。本当にありがとうございます。

私はYouTubeにアップロードされたセッション動画をゆっくりと視聴しながら、停滞している仕事に追われる日々を過ごしています。

アフター・ドラマで日本初開催の WordCamp としてのふりかえり

WordCamp Kansai 2025 は WPDrama が起こった WordCamp US 2024 (2024/09/20)よりも前から企画が進められていました。

運悪く?このタイミングに当たってしまった WordCamp の実行委員としてはこの点にも触れておかないといけないという想い、そして日本国内で開催されるこれからのWordCamp のために私たちが何をしてきたのかを残しておきたいと思います。

この記事にたどり着いた人の中には、通称「WPDrama」をご存知でない人も多いと思うので、その場合は国内で最も信頼できる WordPress メディアの Capital P の記事をどうぞ。

会場予約・予算レビュー

「WordCamp を開催するぞ」という気持ちだけでは、WordCamp Central へ開催予定を掲載することはできず、金額の最も大きい会場の予約やイベント全体の予算計画の審査を経ていくことになりますが、ドラマ直後の最も混乱したタイミングと重なって、とても複雑な気持ちで進めたことをよく覚えています。

WordCamp の予算レビューを担当してくれる Automattic の担当の人には「グローバルスポンサーの費用をあまりあてにせず、ローカルでしっかりスポンサーを集めるように」と言われる中、WordCamp にはドラマの影響で様々な方針変更が加えられてくことになったのでした・・・。

参加者への変更点(2024/12/20あたり)

WordCamp の参加チケットを購入するには WordPress.org へのアカウント登録が必須となりました

この変更は一部の WordCamp 参加者への参加ハードルを引き上げ、主催者としては制限の多いWordCampサイトの中で、せめてもと注意文を掲載する対応を実施しました。

WordCampに参加するためにチケットを購入するにはWordPress.orgへのアカウント登録が必須となったせいでWordCampのチケット購入ページに掲載された注意文。「チケットの購入にはWordPress.orgのアカウントが必須となります。こちらのリンクより事前に作成をお願いします。」と記載されている
WordCampに参加するためにチケットを購入するにはWordPress.orgへのアカウント登録が必須となったせいでWordCampのチケット購入ページに掲載された注意文。

参加者としてチケット購入をしようと思ったら、WordPressのログイン画面が表示された時にどのように感じるでしょうか?

ある人は、ご自身の管理する WordPress のユーザーID・パスワードを入力してエラーになり、またある人は「なんでイベントに参加するためによく分からない WordPress にユーザー登録をしないといけないの?」と思ったことでしょう。
そして、パイナップルをピザに〜云々のチェックボックスの意味が分からずに離脱してしまった人もいるでしょう。

参加者アンケートにもその点について触れる声を寄せて頂いていますが、実行委員としては何も手を討つこともできず、「 WordCamp は変わった・・・」としか言えなかったもどかしさがあります。

※ちなみに、経緯・目的は依然としてすっきりしない感じです

※ WordCamp と同じく、WordPress 公式コミュニティの WordPress Meetup への参加には WordPress.org へのアカウント登録の必要がありません・・・。

スポンサーへの変更点(2025/1/1から)

事前に聞いていたものの、Matt 氏からのお年玉となった、

今後の WordCamp スポンサーは全部俺たち( Matt 氏 & Mary 氏 )が審査するよ宣言

・・・正直なところ、頭を抱えました。

WordCamp の予算レビューを担当してくれる Automattic の担当の人にも「一部の国ではスポンサー集めに苦戦している」ということを聞かされる一方で、ほんのり厳しくなったことを感じさせる予算レビューでは、「やりたいことを全部やるならローカルのスポンサーを集めよ」とのプレッシャーもありました。

例年 WordCamp にスポンサーとして参加してくれる企業さんには、スポンサー申し込みを開始する前から事前に連絡して経緯を説明したり、実行委員内で事前審査をしたりもしました。

いちボランティアが企業の Web サイトをチェックし、 WordPress という単語・ WordPress ロゴの使用状況をチェックし、修正依頼をする・・・。

・・・正直なところ、「これはボランティアでやっていいことなのか?」と何度も思いました。(今でもその思いは変わらず

最終審査は Matt 氏・Mary 氏のどちらかで行われているらしいが、多忙な彼らが世界中の WordCamp スポンサーをくまなく審査する余裕があるはずもなく、実際は Automattic の社員が日本語の Web サイトを翻訳しながら「仮チェック」をしていく運用がおこなわれていました。

その「仮チェック」の結果をそのままスポンサーに伝えるべきか、実行委員内で解釈を汲み取ってから伝えるか、いろいろな悩みがありました。(なんせ相手は機械翻訳で審査して、機械翻訳で変更指示を伝えてくる。)

・・・正直なところ、「これはボランティアでやっていいことなのか?」と何度も思いました。(今でもその思いは変わらず

そんな中でも、WordCamp を支えてくれるためにご対応いただき、参加いただいたスポンサー企業のみなさまには心からの感謝を申し上げたいと思います。本当にありがとうございました。

また、WordPressコミュニティとしては「WordPress に関連するビジネスを展開していない企業の方が審査が通りやすく、スポンサーになりやすい」という事実と向き合う必要があると思っています。

これは、WordPress に関連するビジネスを展開していない企業であれば、100%GPLの宣誓や商標の問題を難なく乗り越えることができてしまうということですが、そのような企業が WordCamp のスポンサーになること自体は何の問題でもなく、結局はその時の実行委員が判断するしかありません。
関連ビジネスを展開していなくても、 WordPress ユーザーとして応援してくださる企業さまもいらっしゃいますしね。

どのような企業が WordCamp へのスポンサーになるのがふさわしいかについては、WordCamp オーガナイザーハンドブックの資金の調達ページに記載されている内容を引用しつつ自分の想いを書き出しておくことにしますので、あなたが判断に迷ったときに思い出してもらえると嬉しいです。

スポンサーの金銭的支援は寄付金であり、イベントを応援するために支払われるものです。資金を提供してくれる方々を「スポンサー(出資者)」と捉えるのではなく、「サポーター(支援者)」と考えましょう。

実行委員内部でも「スポンサー」ではなく「サポーター」と呼ぼうか?という意見はありました。

過去のイベントにおいてこういった企業はスポンサーと呼ばれ、WordCamp 運営チームによって様々な段階のスポンサーシップレベルが設定されていました。貢献する金額のレベルが上がるほど特典(多くはマーケティング向け)が高くなるというケースが一般的でした。しかし、この傾向によって多くの WordCamp が商業的になりすぎるという弊害が生まれました

「商業的になりすぎた WordCamp 」はあまり見たくないと個人的には思っています。

スポンサーになってもらう企業に金銭的支援をしてもらう対価としてイベントの参加者に対してマーケティングや広告をしても良いという考え方はしないでください。こういったことをすると、結果的には WordCamp のスポンサーシップが広告の購入であるという形になり、WordCamp Foundation や WordCamp 運営チームの非営利性が失われることにつながります。

ローカルの WordCamp はビジネスイベントではないので、参加者としてもスポンサーとしても、こういった商業的な目的での参加は Flagship WordCamp と呼ばれる WordCamp への参加をお勧めするのがよさそうです。
WordCamp Asia 2025(フィリピン・マニラ)・WordCamp EU 2025(スイス・バーゼル)・WordCamp US 2025(ポートランド・アメリカ)と2025年に開催されたFlagship WordCamp 全てに参加した者としての意見です。

最後に

「せっかく楽しかったイベントなのに愚痴っぽい」と感じられてしまったら大変申し訳ありませんが、私個人的には今後の日本国内での WordCamp が都市圏だけではなく、以前のように地方でも開催されることを楽しみにしていますし、そのために協力できることがあれば、これからも喜んでお手伝いしたいという前向きな気持ちでいます。

Simple GA Ranking For Shifter Static

Shifter Advent Calendar 2020の20日目の記事。Simple GA RankingをShifter Static でも使いたい!という検証です。

この記事はShifter Advent Calendar 2020の20日目の記事です。

Shifterって?という方はShifterの中の人の赤塚さんによる1日目の記事を読むとよいでしょう。


Simple GA Ranking ?

Simple GA RankingはWordPressとGoogle Analyticsを連携させて人気記事ランキングを取得するプラグイン。

Google Analyticsからデータを取得するので、記事へのアクセスごとにデータベースに書き込むプラグインと比べて軽量に動作する。

公式サイトにはマニュアル動画も用意されていて、セットアップもこの手順通りにやればだいたい迷わずに設定できる。

Simple GA Ranking の設定マニュアル動画。クセになるBGMだ。

mt8もプラグインメンテナーとしてこのプロジェクトに参加している。(更新ができていないのは追々、、、)

Shifter Static でも使える(、、だが!)

Shifter StaticでもSimple GA Rankingを設定して使用することは可能だ。

ただし、表示されるランキングはShifterでジェネレート(静的書き出し)を行った時点で取得したものとなる。

つまり、ジェネレートを頻繁に行わないサイトの場合だとランキングの表示が次にジェネレートするまで変わらないということになる。

・・・惜しい。これはどうにかしたい。

Shifter Staticで静的化されたWordPressサイトからGoogle Analyticsの最新データが取得できれば人気記事だけではなく、関連記事なども実現できる可能性がある

これはどうにかしたい、、、!


ちなみに

静的化する上で避けられないWordPress運用における動的処理の代表格である「お問い合わせフォーム」・「サイト内検索」・「コメント」については

Shifterが公式ブログで外部サービスとの連携する方法を紹介してくれているので是非確認してほしい。

https://support.getshifter.io/en/collections/1394677-contact-forms

https://support.getshifter.io/en/articles/762156-integrating-algolia-search-with-wordpress

https://support.getshifter.io/en/collections/1394686-wordpress-comments

解決したい内容を整理してみる

「Shifter Staticで人気記事ランキング」を実現させるために必要となる要件を書き出しておく。

  • 静的化されたサイトに人気記事ランキングを埋め込む
  • ランキングデータはGoogle Analyticsと連携する
  • サイトアクセス時の最新のランキングを表示する

以上を実現するために、この記事ではSimple GA Ranking for Shifter Staticができないか実験していく。


Simple GA Ranking for Shifter Static

STEP1:WordPressの設定

Shifterにサインアップ・サイト追加をし、WordPressを立ち上げたらパーマリンク設定を以下にしておいた。

/%post_id%/

これで https://example.com/{記事ID}/ で静的書き出しが行われる。

STEP2:Google Analyticsアカウント

アカウント作成時の注意点としては「プロパティ」をユニバーサルアカウントとして作成すること。

手順は以下

①、「プロパティの設定」で”詳細オプションを表示”する

「プロパティの設定」から、詳細オプションを表示する

②、「ユニバーサルアナリティクス プロパティの作成」にチェックを入れる

「ユニバーサルアナリティクス プロパティの作成」にチェックを入れる

STEP3:カスタムディメンションの設定

記事の詳細ページへのPVのみをランキングデータとするためにGoogle Analyticsのカスタムディメンションを設定しておく。

ここでは次のように設定しておいた。

名前post
範囲ヒット
アクティブチェック(有効化しておく)
カスタムディメンションの設定
カスタムディメンションを定義

この設定をしておくことでGoogle Analyticsに記事詳細ページのPVであることを明示的に送信することができる。

作成したカスタムディメンションの「インデックス」の数値はこのあと使うので覚えておく。(スクショの場合は1)

STEP4:WordPressからGAにPVカウントを送信

以下のコードで、記事詳細へのアクセス時にGoogle AnalyticsにPVカウントを送信した。

https://gist.github.com/mt8/42b9bf291a968a29a161608f85ce2677#file-1-php

参考記事:gtag.jsでページビューのときにカスタムディメンション送信

カスタムディメンションが意図した通りに送信されているかは

Google Analtytics > 行動 > サイトコンテンツ > すべてのページ にアクセスし

「セカンダリディメンション」から作成したカスタムディメンションを選択する


もしくは、公式レポートツールのQuery Explorerを使ってもよいだろう。

次のようなパラメータで実際にサイトで取得したいランキングを問い合わせてみる。

idsga:から始まるビューID
start-dateyesterdayPV集計期間From
end-datetodayPV集計期間To
metricsga:pageviewsPVを取得
dimensionsga:pagePath, ga:pageTitleパス, タイトルを取得
sort-ga:pageviewsPVの降順で取得
filtersga:dimension1==postカスタムディメンションはpost

実行してデータが取得できていればカスタムディメンションが計測されていることになる。


Google Analytics APIをどのように実行するか

サイト訪問者がアクセスした時点でのランキングをリアルタイムに表示させたいので、Google Analytics APIはブラウザ側(javascript)から実行させることにする。

しかし、通常API実行のためのアクセストークン取得にはOAuth2認可を行う必要がある。これにはGoogleログインが必要で取得できるトークンには期限がある。

また、javascriptはソースコードが公開されるため、取得したトークンをソースコードで公開するのは問題がある。

そんなときに、GoogleのEmbed APIのページにServer-side Authorizationというページを見つけた。

具体的には以下のような手順となっていた。

  • GCPでサービスアカウントを発行しキーのjsonファイルを取得する
  • GAでサービスアカウント 発行時に作成されたメールアドレスに表示と分析権限を付与する
  • サービスアカウントのキーjsonファイルからサーバーサイドでAPIへのアクセストークンを取得する

※サービスアカウント 取得からAPI実行まではこちらの記事が参考になる:【2019年版】Google Analytics API v4 の使い方(PHP)

この例では取得したトークンをjavascriptソースに記述するようになっており、注釈として以下が添えられていた。

Important!  When you add an access token to the source code of your page, your site’s visitors could use that access token to run any query the service account could run. If your account contains sensitive information, considering adding the service account only to a specific view. You may also want to add a view filter to limit what data the service account can access.

Embed API Server-side Authorization

・・・サーバーサイド?

サーバーレスなShifterを使っているのにサーバーを用意するなんてとんでもない

そこで、今回は以下のようなAPIをserverless frameworkで構築することにした。

  1. サービスアカウントのAPIアクセストークンを取得
  2. アクセストークンを使ってGoogle Analyticsからランキングデータ取得

(このAPIを SGA4SS API と呼ぶことにする。)

SGA4SS APIをserverless frameworkで構築

serverless framework ?

Serverless Advent Calendar 2020の18日目の記事:Serverless Framework はじめの一歩という記事を読んでみるといいだろう。

ここではserverless frameworkの詳しい解説はしないが、ソースコードはGithubに上げておいた。

https://github.com/mt8/sga4ss

※なんでPython?:Embed APIのサーバーサイド認証のサンプルコードがそうだったから

このAPIの注意点

実際にAPIを公開するときにはスロットリングやキャッシュなどをきっちり管理した方がよいと思われる。(APIのURLは公開するので誰でも実行可能)

GA側ではフィルタ機能などを使って、「見られてもいいビュー」を作っておくのがよいと思われる。

***ご利用は自己責任でお願いする***


SGA4SS WordPress Pluginでデータ取得・表示

用意したSGASS APIはWordPress側では [sga4ss] というショートコード でデータを取得してリスト表示することにした。

コードは以下のようなものになる。

https://gist.github.com/mt8/42b9bf291a968a29a161608f85ce2677#file-2-php

・・・記事ランキングにアイキャッチ画像も付けたい

アイキャッチの取得についてはShifterの場合だと少し工夫が必要だった。

なぜならGoogle Analyticsから取得できるのはページパス(投稿ID)だけで、javascriptからでは投稿IDだけ取得できてもアイキャッチ画像を取得することはできない

Shifterサポートのお兄様たちに相談したところ、以下の方法を教えてもらった。(1時間で解決した)

①、/wp-json/wp/v2/posts/{ID} にアイキャッチ画像のURLを含める

以下のコードで、WP REST APIの/posts/{ID}にアイキャッチ画像のURLを追加することができる。

https://gist.github.com/mt8/42b9bf291a968a29a161608f85ce2677#file-3-php

②、/wp-json/wp/v2/posts/{ID} も静的書き出し対象に含める

以下のコードでShifterの静的ファイル出力対象にアイキャッチがある投稿については/post/{ID}をjsonファイルとして含めることができる。

https://gist.github.com/mt8/42b9bf291a968a29a161608f85ce2677#file-5-php
参考:Appending URLs to the artifacts

これでGA APIから取得した投稿IDからアイキャッチ画像を取得することができた。

抜粋になるが、コードだと以下の部分になる。

https://gist.github.com/mt8/42b9bf291a968a29a161608f85ce2677#file-6-js

最後に

実際にShifter Staticで書き出したサイトを貼っておく。

ページ最下部の人気記事ランキングの部分が紹介した方法で実装した部分だ。

https://dazzling-mestorf7276.on.getshifter.io/

いつまで残すかは未定

今回作ったコードは以下に上げているので同じようなことにチャレンジする人の参考になれば嬉しい。

SGA4SS API (Serverless framework): https://github.com/mt8/sga4ss

SGA4SS (WordPress Plugin): https://github.com/mt8/sga4ss-wp

***ご利用は自己責任でお願いする***

re:Invent に初参加してきました

この記事は、AWS re:invent 2018 Advent Calendar 2018の18日目の記事です。

2018年11月26日〜2018年11月30日にアメリカのネバダ州ラスベガスで開催されたAWSのカンファレンス「re:Invent 2018」に参加してきたのでレポートしたいと思います。

来場者数50,000+、一日のイベント予算約10億円というビッグカンファレンスです。


初めてのre:Invent、2回目のラスベガス

NExT Seasonの安藤さんとHugTechの伊東さんと一緒に、AWSのユーザーグループJAWS-UG神戸のコアメンバーをさせていただくこと約2年。

その間に、re:Inventは2016・2017と開催されていたのですが、ライフイベント的に参加することができず悔しい思いをしてきましたが、ついに今年は参加することができました。(行ってこいと言ってくれた家族に感謝です)

初めてのre:Invent参加でしたが、ラスベガスは20年前に一度訪れたことがあって当時の印象とどれぐらい変わっているかも楽しみにしつつ渡米してきました。

観光など

次にいつ行けるか分かりませんから観光もしてきました。

ドローンで空撮したかったので、いろいろ準備してから現地入りしました。

天気もよくいい写真が撮れたので大満足でした。

レンタカーの予約

ツアーに参加することも考えたのですが、ドローン持ち込みNGのツアーが多かったので、自分でレンタカーを手配して観光することにしました。

ラスベガス、というよりもアメリカでのレンタカー予約はRentalcars.comが日本語にも対応していて簡単でした。

アプリでも予約等できますが、ラスベガスの場合だと空港以外のホテルなどの細かい出発・返却場所の指定ができなかったのでwebサイトからの予約の方がおすすめでした。

レンタカー会社もAVISや、Hertzなどの大手を予約する方が安心です。

アメリカでレンタカーを運転するには国際免許が必要なので、警察管轄の免許センターなどで事前に発行してもらう必要があります。

また、注意点としては国際免許だけではなくて日本の免許証も必ず携帯する必要があります。(ないとレンタカーを借りれません)

アメリカの交通ルールについて調べる

アメリカは右側通行で、車は左ハンドルが一般です。

日本と何もかも逆なので注意が必要です。(最後までワイパーを誤操作していたのは内緒です)

あとは、「NO TURN ON RED」という標識がなければ赤信号でも右折可能でした。(日本もこうなったら便利なのに)

ドローンを連邦航空局(FAA)に登録

アメリカで趣味でのドローンを飛行させるにはFAAでの登録が必要です。

https://faadronezone.faa.gov/

3年間有効で登録費用は$5です。発行された登録番号を機体に貼り付けることが義務付けられています。

ちなみに、日本での飛行の場合はDIPSという国土交通省管轄のサイトから登録することができます。申請は無料ですが、サイトが遅いし、分かりにくいです。(申請内容や許可の内容が違うので当然なのですが、日本はいちいちややこしい印象)

FAAのサイト内で普通にクレジットカード決済ができてしまうあたり、日本の行政サイトも見習って欲しいですね。

以下、FAAサイトが対応している決済方法。

Accepted Payment Methods:

  • Bank account (ACH)
  • Amazon account
  • PayPal account
  • Debit or credit card

飛行可能エリアの確認

グランドキャニオンをはじめとする国立公園でのドローン飛行は禁止となっていました。

調べてみるとラスベガスから車で30,40分で行けるレッドロックキャニオンはドローン飛行がOKとなっていました。

Yes, visitors can fly drones for recreational purposes at Red Rock Canyon. Please do not disturb wildlife or visitors while flying your drone.

Visitors are prohibited from launching and landing drones and other unmanned aircraft systems (UAS) in Red Rock Canyon’s Wilderness Areas (La Madre Mountain Wilderness Area & Rainbow Mountain Wilderness Area).

The Las Vegas Soaring Club also has flying space nearby. To find out more information, please visit  www.lvsoaringclub.org

 

Frequently Asked Questions

実際に駐車場にいたスタッフの人とかに「ドローン飛ばしていいですか?」と聞いてみたら「もちろん!」と言ってもらえたので安心して飛行させることができました。

 

その他の飛行エリアはFAAが出しているスマホアプリ「B4UFLY」で確認しました。

https://www.faa.gov/uas/where_to_fly/b4ufly/

ラスベガスの主要エリアは空港が近かったり、観光ヘリが飛び交っているので、ほぼドローン飛行はNGでした。

郊外なら大抵飛ばすことができたので、こんな感じで日本ではなかなか撮ることのできない荒野を撮影することができました。

 

re:Invent 2018

ここから本題です。

レジスト&SWAGをGET

イベント前日にregistrationへチェックインをしにいく必要があります。

チェックインをして参加者であることを証明するためのバッヂをGETします。

5万人以上が参加するカンファレンスなので、マッカラン国際空港にもre:Inventのレジストポイントが設けられていたあたりが規模の違いを感じさせます。

 

レジストが済んだらSWAG(お土産)をもらいに行きます。

今年の参加者に配られたパーカーはグレーでした。

アメリカサイズですが、試着コーナーがあったのでちょうどいいサイズのをGETできました。

認定者ラウンジ

AWS 認定の資格を持っていると、資格保有者のみが入れるラウンジを利用することができます。

資格者限定のお土産ももらえました。

意外とこういう情報は公式サイトからではなく参加者間で共有されて知ることが多かったので、参加する方は”取りこぼし”に気をつけましょう。

DAY1

いよいよイベント初日。

Use Amazon Rekognition to Power Video Creative Asset Production

Amazon Rekognitionの動画解析を使用したwebアプリのデモを見ながら、その解説を行うセッションでした。AlexaのTV CM の動画から動画内に写っている対象を解析したタグ付けしたオブジェクトをタイムラインで確認したり、その情報をもとにして、いかにコンバージョンを向上させるか?という実践的な内容でした。

Build AWS Skills Through Community-Led User Groups

“ユーザーグループを通じてAWSスキルを構築する”と題されたセッション。

各国のUGが登壇して座談会的に開催されました。

コミュニティを通じて成長させてもらっていることを改めて感じる時間となりました。

Using Amazon SageMaker and AWS DeepLens with Teams New to Machine Learning

昨年のre:Invent 2017で発表されたAWS Deep Lensのワークショップを運良く予約できたので参加してきました。

去年のワークショップでは参加者全員にDeep Lensがお土産として配布されたので期待が高まりましたが、今年は$99で買えるクーポンの配布でした。

Amazon.comで普通に販売されているので、わざわざばらまく必要がないということですね。

https://www.amazon.com//dp/B075Y3CK37/

$249での販売なので、$150割引でも十分太っ腹だと思います。

Airbnb滞在だったので、Amazon.comアカウントを現地で作ってPrimeお試し30日に申し込んで無事にGETすることができました。

ちなみに、ラスベガスへのAmazon Prime配送は平均で3,4日といったところでした。(配送元にもよると思いますが)

 

ワークショップの内容は、あらかじめ用意された鳥の写真をAmazon SageMakerで学習させ、DeepLensに写った鳥の写真がどの種類かを判別するというものでした。

GitHubに用意されたREADMEを読みながらAWSマネージドコンソールで進めていきますが、事前にSageMakerを触ったことがない状態だとついていくのが難しい内容だと思いました。

なんとか頑張ったものの、DeepLensのセットアップでタイムアップとなりました。

GitHubの内容は手元にCloneしているので時間を見つけて再トライしてみたいと思います。

Monday Night Live

AWSアップデートの発表第一弾の時間でした。

発表内容はアマゾン ウェブ サービス ジャパン、プロダクトマーケティングのエバンジェリストである亀田さんが詳しくまとめられているので、要チェックです。

「re:Invent 2018 / 11月27日 アップデートのまとめ」

https://aws.amazon.com/jp/blogs/news/reinvent-2018-11-27-updates/

個人的に一番衝撃だったのは、Armベースの新しいプロセッサ「AWS Graviton」を搭載したA1インスタンスの発表ですね。

DAY2

Deploy Alexa for Business in Your Organization, & Build Your First Private Skill

こちらは前回のDeepLensのようにタイムアップにならないようにワークショップに集中したため写真はありません。

東京リージョンではまだ使えないAlexa for Businessを使ったプライベートAlexaスキルの作り方でした。

Service Nowにあらかじめ用意された課題管理に音声で登録を行うというスキルを手順通りに作っていく内容でした。

A4Bの設定からユーザーの招待から、スキルのデプロイはASK-CLIを使って行うというなかなか実践的な内容でしたね。

ワークショップを無事に完走して、モデレーターの方とハイタッチできたので一安心です。

作ったスキルの会話内容はこんな感じでした。

  • ユーザー:「Alexa 課題管理開いて」
  • Alexa:「どんな問題がありましたか?」
  • ユーザー:「○○が壊れた」
  • Alexa:・・・カタカタカタ・・・チーン!(効果音)
  • Alexa:「課題を登録しました!」

 

ちなみに、Amazon.co.jp・Amazon.comのアカウント問題に直面しないようにワークショップに参加される際は、以下の準備をしておくと安心かなと思います。

  • re:Invent 専用のAWSアカウントを作成
  • re:Invent 専用のAmazon Developperアカウントを作成
  • re:Invent 専用のAmazon.comアカウントを作成

あと、スマホの言語設定を英語にしておいた方がいいです。このワークショップではEchoデバイスではなく、Alexaのスマホアプリを使ってテストをしたのですが、スマホの言語設定を変更しないと英語版スキルが使えませんでした。

ドイツのアカウントでもco.jpアカウントと同じ問題があるようで、「どうにかならんかなー」と言ってました。

気づくと英語で会話していたことに驚きました笑

DAY3

Build a Game for Echo Buttons – an Alexa Gadget!

こちらもタイムアップを避けるために集中参加。写真はありません。

まずはGitHubに用意されたスキルをデプロイして動作確認を行い、それぞれのアイディアでオリジナルのゲームを作ってみようというワークショップでした。

日本未発売のecho buttonsがお土産として配布されました!

DAY4

Expo

スポンサーブースを回るEXPOに参加してきました。

大量のTシャツやステッカーなどのお土産をGETすることができました。

EXPOの様子をタイムラプス撮影していたのですが、保存に失敗して紛失したのでデータがありません・・・。

有名どころだと以下のブースに立ち寄りました。

  • Cloudflare
  • Netlify
  • CircleCI
  • Data Dog
  • Nginx
  • Redis
  • O’Reilly
  • GitHub
  • Netflix

re:Play

この日はいくつかのセッションに参加したのですが、re:Playの記憶しかなく・・・。

一番前のど真ん中で堪能させて頂きました。

LAST DAY

最終日はUGへのお土産収集や、人も減ってきたので記念撮影をしたりしながら過ごしました。

最終日ともなると歩きすぎで足がパンパンでしたね。

会場間で移動距離が長い場合などはTransportationを積極的に利用しましょう。

ただし、交通事情やバス乗り場からセッション会場が遠かったりするので時間に余裕を持った行動が大切です。

 

一日平均で25,000歩ぐらい歩いているので普段の運動不足が解消されました。

が、以下でカロリー過多になっているので、体重は+2kgでした。

初参加した感想

初参加となったre:Invent 2018。

わからないことだらけでしたが、参加経験のあるUGメンバーに色々教えてもらいつつ楽しく過ごすことができました。

日本とラスベガスだと17時間の時差があるので仕事との調整はなかなかハードでした。

一緒に仕事をしているメンバーには迷惑をかけた面もあるかと思いますが、ご理解を頂いて本当に感謝しています。いつもありがとうございます。

特に印象に残っているのは現地水曜日に行われた、re:Invent User Group Leader Private Eventです。

世界中のAWS UGとの交流の時間でした。

まずはじめにいくつかのUGからLTタイムがあり、日本からはAWS Samurai 2017で特別賞を受賞された伊藤さんが英語でスピーチを行なってくれました。

堂々と発表されている姿が本当にかっこよかったです!事前の練習風景を知っていることもありこみ上げるものがありました。

英語にはあまり自身はありませんが、そんなことを言っていたら「今回参加した意味がない!」と言い聞かせ、様々な国のUGメンバーと交流しました。

  • 韓国
  • 台湾
  • タイ
  • ドイツ
  • ノルウェー
  • フィンランド
  • アメリカ
  • ブラジル

つたない英語でのコミュケーションでしたが、コミュニティの運営についてなど貴重なディスカッションの時間となりました。

ドイツのCommunity HeroのMichaelさんから「これで英語勉強してみたらいよ!」という優しい言葉とともに、ご自身が執筆されたAWSの本をもらいました!ありがとうございます!!

最後に

心残りは、Keynote, Andy JassyとKeynote, Dr. Werner Vogelsに現場参加できなかったことです。

仕事とか体力的な問題でAirbnbの部屋でストリーミングで観ていました。。

次回は現場参加できるように鍛えておきたいと思います。

 

フリーランスが自腹でre:Inventに参加するというのはなかなかハードルの高いことです。

  • 参加費:$1,799
  • 航空券:80,000〜100,000円
  • ホテル:10,000〜15,000円/泊 × 5〜7日
  • 食事代:$20〜30/回(朝・昼食はイベント会場内で無料)
  • その他:お土産とか、カジノとか・・・

re:Inventで発表される内容はほぼ即日に日本語でまとめられますし、内容を知るだけならわざわざ現地にいく必要はないのかもしれません。

でも、今回初めて参加して現場の熱気を肌で体感することができて本当によかったと思います。むしろこれが一番の価値ではないかと思いました。

今回、自分に課していたミッション「グローバルコミュニティとの交流」も無事に果たすことができたので大満足です。

 

ここまで書いて、「次にいつ行けるか・・・」と先述しておきながらすでにもう行きたい気持ちになっています笑

すでに来年のスケジュールも決まっているので、機会があればre:Inventに参加してみてはいかがでしょうか?

 

ラスベガスで出会ったみなさん、本当にありがとうございました!

ドタバタ話もたくさんあるので、お会いした時にコソッと聞いてみてください!

WooCommerce + WooCommerce Stripe Payment Gateway で「Sorry, we are unable to process your payment at this time. Please retry later.」というエラー出たら

WordPressでECサイトに変えてしまうWooCommerce

WooCommerceでstripe決済を可能にするのが、 WooCommerce Stripe Payment Gatewayです。

プラグインをWooCommerceが公式プラグインとしてリリースしてくれているので簡単に導入することができます。また、世界中のフィードバックを受けながら進化・改善されているので運用面でも安心して利用できそうです。

stripeのテストモードを使って決済をすると以下のようなエラーに出くわしました。

Sorry, we are unable to process your payment at this time. Please retry later.

WooCommerce Stripe Payment Gatewayのログ出力を有効にして、WooCommerce – [ステータス] – [ログ] より確認してみると以下のようなログファイルが作成されていました。

woocommerce-gateway-stripe-20XX-XX-XX-xxxxxxxxxxxxxxxx

ログファイルには以下のような内容が記録されていました。

====Stripe Version: 4.1.9====
====Start Log====
charges request: Array
(
[currency] => jpy
[amount] => 1000
[description] => [文字化けしてる]
[statement_descriptor] => [文字化けしてる]
[capture] => true
[expand[]] => balance_transaction
[metadata] => Array
(
[customer_name] => test tarou
[customer_email] => test@example.com
[order_id] => 10
)
[source] => src_xxxxxxxxxxxxxxxxxxxxxxxx
)

====End Log====

descriptionstatement_descriptorあたりが文字化けしているのが気になります。

エラー内容でプラグインのフォーラムを検索してみるとドンピシャの内容がヒットしました。

https://wordpress.org/support/topic/sorry-we-are-unable-to-process-your-payment-at-this-time-please-retry-later/

解決策はこちらに書かれていました。

https://wordpress.org/support/topic/sorry-we-are-unable-to-process-your-payment-at-this-time-please-retry-later/page/2/#post-10212383

Thanks!! Now strip check-out got to work!
As you say, I checked statement discriptor, and changed to only alphabets, now it works.
And I tried to have Japanese letters, it also works.
But, when I have a special letter “|” in statement descriptor that maybe only Japanese has, the error massage appears. It seemed to be a cause of the error.

Anyway, thank you very much for your help and taking your time!!

to Japanese users
今回の原因は、woocommerce>設定>購入手続き>Stripe
の中の設定で、「ステートメント記述子」の箇所に「|」という記号を入れていたことが
原因だったと思われます。
アルファベットと日本語のみの記載にしたところ、エラーが消え、決済できるようになりました。

[ステートメント記述子] の設定を確認してみると、以下のように「クレジットカード」としていました。

これを以下のように「stripe」とすることでエラーなく決済ができるようになりました。

<追記>ステートメント記述子はカスタマーのクレジット明細に載るようなので、実際には会社名やサービス名の英字表記がよいかと思います。(5〜22文字)

 

こちらも参考:WooCommerceでStripe決済を導入する時のエラーの解決方法

これはStripeのステートメント記述子をアルファベットにしろということです。Stripeの設定画面から該当の箇所を見ると日本語で入力されていたため、こちらをアルファベットに変更したところ無事決済ができました。

ただし、WooCommerce Stripe Payment Gateway 4.1.9では上記記事のエラーは出ませんでした。

 

ちなみに、これはstripeのAPIの仕様なのでしょうがない。

stripeのAPI仕様ではステートメント記述子「」は以下のように定義されている。

Statement descriptors are limited to between 5 and 22 characters. They must contain at least 5 letters and cannot use the special characters <, >, \, ‘, or “.

https://stripe.com/docs/connect/statement-descriptors

つまり、5〜22文字で「 <, >, \, ‘, or “.」などの特殊文字は使えない。

同じく日本語も使えないようなので「クレジットカード」とするとエラーとなる。

しかし、画面の表示上、「stripe」と表記してもカスタマーがどのような決済方法か分からず購入に至らない可能性がある。

そのような場合、以下のコードを使うことでステートメント記述子を「クレジットカード」としつつ、内部的には「stripe」としてAPI送信することが可能。

https://gist.github.com/mt8/05c5d0cf1a2267adcf6e60ff773a0cdf

 

職人工房さんのブログにも紹介してもらいました。ありがとうございます。

https://wc.artws.info/2018/09/05/woocommerce-stripe-payment-gateway-statement-descriptor-error/

WordPressの書籍を執筆しました。

WordPressの書籍を執筆しました。