## はじめに
まだ日本語未対応ですが今後日本進出もありうるEC構築プラットフォーム”Big Commerce”を紹介します。

## Big Commerce会社概要
 ![](/uploads/Fire_Shot_Capture_130_Enterprise_ecommerce_simplified_Big_Commerce_www_bigcommerce_com_286606167b.png) 
[http://www.bigcommerce.com/]

2009年設立のアメリカの会社です。もともとはオーストラリアのシドニー設立ですが現在本社はアメリカのオースティンにあります。
2020年にNASDAQ上場してます。

## Big Commercの基礎情報

- ・150カ国で利用
- ・全世界55,000のEC店舗が利用
- ・Amazonやebayとの販売管理連携
-・Facebook, Pintarest, Google Shopping など主要SNSと連携

## Big Commerceの特徴
Big Commerceと比較検討されるのは、Shopifyです。
Shopifyはシンプル簡単ですぐにECサイト構築ができる。
Big CommerceはShopifyの少し上級者向けといった立ち位置です。
その代わりShopify以上にいろいろなカスタマイズができます。

またBig Commerceは月額の利用料のみで販売手数料がかかりません。
よってECの売上規模が上がれば、やりたいことも増えますし、販売手数料がかからないBig Commerceが乗り換え先のプラットフォームとして候補に挙がるようです。

## 料金
 ![](/uploads/Fire_Shot_Capture_133_Big_Commerce_Pricing_and_Plan_Information_Big_Commerce_www_bigcommerce_com_b28e78d517.png) 

[https://www.bigcommerce.com/essentials/pricing/]

- ・Standard: 39USD /月
- ・PLUS: 105USD /月
- ・Pro: 399USD /月

Shopifyより若干高めですがそこまで高額ではないですね。


## まとめ
今回はBig Commerceの概要を紹介しました。
日本のEC市場にもBig Commerceと同じターゲット規模感のEC事業者向けのEC構築プラットフォーム事業者がいます。
Big Commerceが日本市場にも攻めてきたらどういう戦いになるか注目です。



small_bigcommerce-logo.png

thumbnail_bigcommerce-logo.png

bigcommerce-logo.png

まだ日本語未対応　EC構築プラットフォームBigCommerceに注目

## はじめに
Reactでフロントエンドの開発を行う場合に、おそらく一度は誰でも状態管理に頭を悩ませるのではないでしょうか。  
2023年10月現在、Redux、React Hooks、zustand、そしてここで取り上げる Recoil、Jotai など、Reactの状態管理をするためのライブラリや方法は数多く存在ます。  
多くの開発者によりその使い方が模索・洗練されていますが、絶対的な正解というものは存在しません。  
故に、プロジェクトに導入する場合に、どれを選定するかで、とても迷う方は多いのではないでしょうか。  
このブログでは、私が状態管理のライブラリを選定するときに悩んだ内容から、案件の向き不向きについて考察し、ご紹介したいと思います。  

**[2024.6.3 追記] Recoilから正式に発表されているわけではありませんが、2023年3月以降アップデートがなく、Recoilの開発は実質的に打ち切られてしまったようです。そのため、Recoilを選択することは避けた方がよさそうです…  
参考: <a href="https://github.com/facebookexperimental/Recoil/issues/2318" target="_blank">React 19 support · Issue #2318 · facebookexperimental/Recoil</a>**

**→ [2024.7.19 追記] [Reduxへ移行する方法の記事](https://sterfield.co.jp/blog/recoil-to-redux/)を投稿しました。**

## まず Redux、zustand と Recoil、Jotai の違いについて
Redux は、Reactを作ったFacebookが提唱した[Flux](https://github.com/facebookarchive/flux/tree/main/examples/flux-concepts)というアーキテクチャをもとにした、初期から最も利用されている状態管理ライブラリです。  
Reactとは切り離して１つのストアに集約して管理するため、情報の流れが一方通行で辿りやすい特徴があります。WEBアプリ全体の一貫性を重視し、堅牢な作りにする場合、Reduxは有望な選択肢となります。  
しかしながら、Reduxは非同期通信を伴うような複雑な状態管理ではそのまま使うのはあまりにもコードが膨大になってしまうため、サードパーティのプラグインなどを導入することが現実的な選択肢となります。また、1つのストアで管理するため、コンポーネント単位でのカプセル化が苦手です。  
  
zustand はこのReduxの苦手な部分を補うことで、Reduxからの乗り換えが進んでいるライブラリです。  
基本的な思想はReduxと同じですが、Reduxで煩雑になるような記述をより簡潔に書くことができます。 
  
Recoil は Redux とは違う思想で、ストアを複数持ち、それぞれに対して別々のコンポーネントからアクセス可能です。ストアが一元管理されているReduxやzustandとちがい、コンポーネント単位でのカプセル化がしやすく、データとアプリ全体の結合を制限することに向いているので、柔軟性を重視するアプリに向いていると言えそうです。
ただ、複数のストアに別々のコンポーネントから双方向でアクセスできる特徴が故に、組み方によってはReduxと比べると情報の流れを辿りにくくなる可能性があることに注意が必要です。  
  
Jotai は Recoil をより簡潔に記述できるようにしたライブラリで、[npm trends](https://npmtrends.com/Jotai-vs-react-redux-vs-recoil-vs-zustand)を見ると、2023年10月現在、本家のRecoilを追い抜いています。  

## RecoilよりJotaiが向いている案件
RecoilとJotaiで同じ状態管理をするためのコードを比べてみましょう。
#### Recoil
```typescript
const exampleState = atom({
  key: "exampleState",
  default: 0
});
const exampleSelector = selector({
  key: "exampleSelector"
  get ({ get }) => `${get(exampleState)}個を選択中`
});
```
#### Jotai
```typescript
const exampleState = atom(0);
const exampleSelector = atom((get) => `${get(exampleState)}個を選択中`);
```
こうやって並べてみるとよく分かりますが、  
Jotaiの方が圧倒的にコード数が少なくなります。  
Recoilで用意されている機能の多くはJotaiでも利用できるので、よりシンプルに状態管理を行いたい場合は、  Jotaiが向いていると言えます。  
  
## JotaiよりRecoilが向いている案件
では、次の場合はどうでしょう。  
#### Recoil
```typescript
// Writable
const idState = atom({
  key: "idState",
  default: 1
});

// Read Only
const fetchState = selector({
  key: "fetchState",
  get: async ({ get }) => {
    const id = get(idState);
    try {
      const response = await fetch(`example.api.json?id=${ id }`);
      const json = await response.json();
      return json;
    } catch (error) {
      throw error;
    }
  }
});

// Writable (default value fetched)
const complexState = atom({
  key: "complexState",
  default: selector({
    key: "complexSelector",
    get: async ({ get }) => {
      const json = await get(fetchState);
      return {
        id: json.id,
        name: json.exampleName
      }
    }
  })
});
```
#### Jotai
```typescript
// Writable
const idState = atom(1);

// Read Only
const fetchState = atom(async (get) => {
  const id = get(idState);
  try {
    const response = await fetch(`example.api.json?id=${ id }`);
    const json = await response.json();
    return json;
  } catch (error) {
    throw error;
  }
});

// Writable (default value fetched)
const defaultComplexState = atom(async (get) => {
  const json = await get(fetchState);
  return {
    id: json.id,
    name: json.exampleName
  }
});
const overWrittenComplexState = atom(null as { id: number; name: stirng; });
const complexState = atom<number, [number], void>(
  async (get) =>
    (await get(overWrittenComplexState)) ||
    (await get(defaultComplexState)),
  (_get, set, update) => set(overWrittenComplexState, update)
);
```
このように初期値をフェッチしつつ、後からデータの上書きもできるようなストアを作ろうとするような複雑な処理をさせようとした場合、JotaiよりRecoilの方が分かりやすいコードになることがわかるかと思います（もっと上手な書き方があったらすみません）。  
また、フェッチしたデータをリセットできるようにする場合、  
  
#### Recoil
```jsx
const exampleState = atom({
  key: "exmapleState",
  default: 0
})
const ExampleComponent = () => {
  const [example, setExample] = useRecoilState(exampleState);
  const reseter = useResetRecoilState(exampleState);
  const handleAddClick = () => setExample(previousState => previousState + 1);
  return (
    <div>
      <p>{example}</p>
      <button onClick={handleAddClick}>追加</button>
      <button onClick={reseter}>リセット</button>
    </div>
  )
}
```
のように、Recoilはatomに対してそのままuseResetRecoil()を使うことでリセット可能ですが、  
  
#### Jotai
```jsx
const exampleState = atomWithReset(0);
const ExampleComponent = () => {
  const [example, setExample] = useAtom(exampleState);
  const reseter = useResetAtom(exampleState);
  const handleAddClick = () => setExample(previousState => previousState + 1);
  return (
    <div>
      <p>{example}</p>
      <button onClick={handleAddClick}>追加</button>
      <button onClick={reseter}>リセット</button>
    </div>
  )
}
```
のように、Jotaiでは、あらかじめreset用のutil（atomWithRest）を使ってatomを用意する必要があります。  
その他にも、Jotaiでは複雑な操作をしようとした場合に、Recoilと同様の操作をするためにより多くのutilを使ったり、helperを自前で用意しなければいけない場合に遭遇します。  
  
これらのことから、より複雑なデータ処理を扱うような使い方をする場合、Recoilの方が向いていると言えます。  

## まとめ
堅牢でアプリ全体を見通すことを優先するのであれば Redux。  
基本的な思想はReduxと同じだけど、よりシンプルに描きたいのであれば zustand。  
機能追加やコンポーネントの入れ替えが多いような柔軟性のあるアプリで、複雑なデータ管理が必要なら Recoil。  
柔軟性とシンプルさを重視するなら Jotai というのが、現時点での自分の選択基準でした。

## 参考リンク

- [Jotai](https://jotai.org/)
- [Recoil](https://recoiljs.org/)
- [Redux](https://redux.js.org/)
- [zustand](https://github.com/pmndrs/zustand)
- [npm trends: jotai vs recoil vs redux vs zustand](https://npmtrends.com/jotai-vs-recoil-vs-redux-vs-zustand)

medium_20231006_1.png

small_20231006_1.png

thumbnail_20231006_1.png

20231006_1.png

Reactの状態管理ライプラリはRecoilとJotaiならどちらをえらべばいいか？

## はじめに
　越境EC支援事業を行う中で、越境ECに挑戦したいものの、どのように越境ECを開始したらいいのかご相談いただくことがあります。今回は、越境ECプロジェクトの進め方についてご紹介します。

## 越境ECには何が必要？
　越境ECを実現するためには、大まかに①企画構想、②販売開始までの事前準備、③販売開始後の運営を組み立てる必要があります。越境EC開始後には運営業務に加えて売上拡大施策を平行して行っていきます。全体感は以下の図の通りです。

 ![](/uploads/EC_c8496c64fe.png) 

## 手順を追って抜け漏れのないように
　越境ECの実現に向けて必要な項目は、ある程度決まったものがあります。上記の項目を一つずつクリアしていけば、越境ECの開始と越境EC開始後の事業運営を行うことが可能です。

　越境ECでつまずいてしまうよくあるパターンなのですが、とりあえず越境ECを始めることがゴールになっており、販売開始後の目標が立っていない場合があります。このような場合、もう少し付け加えると、全体感を考える前にまず手を動かすことが優先されていて、何から手を付けていいかわからない状態で準備を開始されることが多くみられます。場当たり的にとにかく思い付いた項目を調査・準備して、結果として準備に抜け漏れが多く、なかなか越境EC販売に辿り着けないことが見受けられます。

　また、なんとか越境EC販売に辿り着いたものの、とりあえず既存社員で越境ECのカスタマー対応をやってみる方針の下で、外国語対応に挑戦。リソース不足が重なる中で外国語対応に苦戦してCS対応が遅れてしまい、販売者としての評価が下がってしまったケースもあります。

　いずれの場合もまずやってみようの精神でスピード感を感じられ、ポジティブな捉え方ができます。一方で、計画が機能せずに越境ECの組み立てをしっかり行うところまで逆戻りしてしまい、結果として本来あるべき姿に到達するまでに時間がかかってしまいます。

## 越境ECのプロを活用
　越境ECは海外販路の拡大に有効な手段の一つです。取扱商品の海外ニーズを見ながら、リソース管理を行って販売を組み立てていくことが大切です。越境ECのプロジェクトを進めるにあたって大切なことは、越境ECの目的を設定してチームに共有することです。目的を設定してから何を準備したらいいのかわからなかったり、社内リソースが足りなかったりした場合は、越境ECのプロにお任せしてみましょう。海外ECモールへの出店や自社ECサイトの準備、マーケティング活動まで中長期的に支援が可能です。越境ECのプロは、自社だけで準備するよりも販売開始までの立ち上げが早く、結果としてコストも抑えながら売上拡大に向けた将来像に向けて伴奏パートナー役を担います。

## まとめ
　越境ECは手順を踏めばしっかりと開始することができます。今は越境ECを実現する支援企業が充実しています。最初の相談は無料の事業者も多いので、お気軽に相談してみてください。


large_越境EC画像.jpg

medium_越境EC画像.jpg

small_越境EC画像.jpg

thumbnail_越境EC画像.jpg

越境EC画像.jpg

越境ECプロジェクトの進め方

<h2>はじめに</h2>
荷物を海外に送る、というのは日常生活ではなかなか経験しない事ですよね。

越境ECに初めて取り組む事業者様も、海外配送はしたことない！と
不安に思われる方も、非常に多いと思います。

国内郵便もそうですが、国際郵便で特に気を付けるべきなのは、「内容品」の書き方です。

本記事では、国際郵便の基本ということで、個人が個人へ国際配送する時の、ポイントをまとめてみました。

<h2>まずダメなもの</h2>
<img class="aligncenter size-large wp-image-11124" src="https://launchcart.jp/admin/wp-content/uploads/2022/10/38e47e783171fea68a5626cbf1474754-1024x567.png" alt="" width="1024" height="567" />
<h3>船便でも、航空危険物はNG</h3>
<img class="aligncenter size-large wp-image-11125" src="https://launchcart.jp/admin/wp-content/uploads/2022/10/5cfe4f20543f572cb3f5af2076af6c65-1024x739.png" alt="" width="1024" height="739" />
<h2>アルコール度数</h2>
アルコール度数24度以下

化粧水など、ものによってはアルコールが含まれているキーワードを「内容品名」に記載していると、アルコールが含まれていないか、聞かれます。
<ul>
 	<li>アルコール不使用の場合は「Non-alcoholic」</li>
 	<li>使用している場合は、「Alcohol 〇%」</li>
</ul>
と、明確にアルコール度数が基準以下であることを記載した方が良いです。
<h2>引火点</h2>
インカテン...
私（文系）は、郵便局の窓口で初めて聞きました。
引火する時の温度だそうです。

簡単に火が付いてしまうと危ないですよね。
そのため、摂氏60度(華氏140度)以下のものはNGとされています。
アロマオイル等、オイルを含む商品は、アルコール度数のみならず、引火点を聞かれる場合があります。
なので、アルコール同様、内容品の所に
<ul>
 	<li>Flash Point　〇℃, 〇℉</li>
</ul>
と記載した方が良さそうです。
<h2>他にも！お役立ち情報</h2>
壊れやすいから、気を付けて欲しい！
こちらの面を上にして置いて欲しい！など、色々な要望があると思います。
国内配送だと、シールを貼ったりなどをしますが、国際配送の場合は日本語のシールを貼っても意味がありません。
基本的には、段ボールに大きく英語で書く手が一番です。
<ul>
 	<li>壊れやすい！：Fragile</li>
 	<li>取り扱い注意！：Handle with Care</li>
 	<li>こちらが上：This Side Up</li>
 	<li>折り曲げ厳禁：Do not bend</li>
</ul>

<h2>まとめ</h2>
今回は、国際郵便における「内容品」の書き方、という事でまとめてみました。

海外配送は、ちゃんと届くかどうか、安全に届くかどうか、心配してしまいますが、しっかりと情報を事前に記載しておくことで、トラブルになる確率避けられると思います。

ご参考になれば幸いです。

参考：https://www.post.japanpost.jp/int/use/restriction/index.html

large_ismael-paramo-tnVdQGmWtb0-unsplash.jpg

medium_ismael-paramo-tnVdQGmWtb0-unsplash.jpg

small_ismael-paramo-tnVdQGmWtb0-unsplash.jpg

thumbnail_ismael-paramo-tnVdQGmWtb0-unsplash.jpg

ismael-paramo-tnVdQGmWtb0-unsplash.jpg

【国際郵便】窓口で慌てない！<br>国際郵便における「内容品」の書き方と注意点

## はじめに
恐らく、この記事をお読みいただいている方は全員使っているであろう、LINE。
日本国内のコミュニケーションツールとして、日々の生活に欠かせないものとなっています。
ただ、いざ海外に出てみると、Facebook MessengerやWhatsApp、WeChatなど、各国で利用されているツールが異なるので、「LINEは日本のツール」と思われている方も多いのではないでしょうか？

それは、違います。
LINEは、日本以外の国でも、日常生活で利用されています。
今回は、Zホールディングス社の発表した<a href="https://www.z-holdings.co.jp/strategy/13/" rel="noopener" target="_blank">記事</a>を元に、LINEのグローバル展開のすごさや、ローカライズの大切さ、越境ECで利用する可能性について考えてみたいと思います。

## LINEはアジアを中心にグローバルに利用されている！
 ![](/uploads/line_asia_01_8a8c70d6a7.png) 
アジア向けの越境ECに携わっていると、「台湾でLINEが広く使われている」という事は、よく知られています。
日本ではまだ少ないかもしれませんが、台湾ではLINEはビジネスでも多く用いられており、メールよりもLINEでコミュニケーションを取りたい、という企業様も多いです。

このように海外での利用率も高いLINEですが、特に利用されているのが、日本・台湾、そしてタイ！
各国総人口のうち、日本が7割、台湾9割、タイ8割の人が日常的に利用しているツールです。

こんなに成長してきた理由が何かというと、**「ハイパーローカライゼーション」** とのこと。
ハイパーローカライゼーションとは、世界共通に画一化されたグローバルサービスではなく、その地域の多様な文化や慣習を尊重し、徹底的にローカライズをしていくことで、これによりグングンと成長してきたそうです。

各国の習慣を尊重し、サービス提供側が合わせていく、というのは、越境ECの成功の秘訣にも繋がりますね。


### ハイパーローカライゼーションの例
ハイパーローカライゼーションの例で、色々と面白いものを見つけたので、併せてご紹介します。


 ![](/uploads/line_asia_03_4179169797.jpg) 
例えば、台湾。

台湾では、フェイクニュースが深刻な社会問題なので、怪しい文章やURLを投稿すると、フェイクニュースかどうか判断してくれるきのうだそうです。
日本にはない、面白いサービスですね。


また、交通渋滞がひどいタイでは、自分が外出して用事を済ませるのにハードルがあるそうです。
そこで、「LINE MAN」というサービスを利用すると、フードデリバリー、食料品・日用品デリバリー、速達郵便サービス、タクシー配車などができてしまうそうです！


## LINEの今後
レポートを読み進めていくと、LINEが今後強化する領域についても紹介されています。
特に、日本・台湾・タイのような利用者が多い地域では、LINEPayやEコマースなどの決済・コマース事業に力を入れて行くそうです。
現在も、台湾やタイ向けの越境ECで、LINE Payの利用が～～　と越境EC業界でも言われていますが、今後プラットフォームとしてのLINEというのも期待できるかもしれませんね！

 ![](/uploads/line_asia_08_bb7b9bc108.jpg) 



## まとめ
今回は、LINEのグローバルサービス展開について調べてみました。

特に、ローカライゼーションによって成功を収めてきた工夫については、越境ECに通じるものもあるのではないかと思います！

LINEとアジア越境ECの親和性がもっと高まると、マーケティング、決済、プラットフォームなど、多角的にLINEを活用できる日も、近いのではないかなと思いました。


参考文献・画像出典：https://www.z-holdings.co.jp/strategy/13/




large_adem-ay-zs-41Br0WhQ-unsplash.jpg

medium_adem-ay-zs-41Br0WhQ-unsplash.jpg

small_adem-ay-zs-41Br0WhQ-unsplash.jpg

thumbnail_adem-ay-zs-41Br0WhQ-unsplash.jpg

adem-ay-zs-41Br0WhQ-unsplash.jpg

LINEは日本だけのものではない！？<br>グローバルに成長するLINEの勢いが止まらない！

ツイートのいいね数やコメント数、YouTubeの投稿日時、Amazonなどネットショップのレビュー数、通貨ごとの適切な価格表示など、UX（ユーザーエクスペリエンス）の向上やコンテンツや商品の競争力を高めるためには、これらの数字をユーザーが一目で理解できるようにすることが一つのポイントになります。

また、数字が非常に長い場合は、簡潔に表示する方が読みやすいです。さらに、ユーザーの使用言語や文化に合わせて、数字を適切に表示することが良いでしょう。

上のように数字、日付、価格を簡潔に表示するために、外部ライブラリを使用せずに、JavaScript標準仕様にあるIntl APIを使用するとより簡便に実装できます。

### Intl API
**Intl** APIはinternationalization（国際化）APIの略で、下記はMDNからの引用です。

> **`Intl`** オブジェクトは、 ECMAScript の国際化 API の名前空間で、言語に依存した文字列の比較、数値の書式化と、日付の書式化を提供します。 **`Intl`** オブジェクトは、いくつかのコンストラクターに加え、国際化コンストラクターや他の言語に関する関数に共通する機能へのアクセスを提供します。
> 

また、internationalizationは始めのiから終わりのnまでの間に18文字入っていることで**i18n**と呼ばれています。

ほとんどの最新のブラウザでサポートされているため、互換性を心配せずに使用できます。

では、いくつかの使い方を紹介します。

## 数字を簡潔に表示
`Intl.NumberFormat`を使用します。
viewsに閲覧数を表す数字を入れています。このように大きな数字をそのまま表示すると読みにくくなります。
最初の引数には言語を指定するだけで良いので、日本語の場合は`ja-JP`を指定します。
```
const views = 9741275;
const formatter = new Intl.NumberFormat('ja-JP');

console.log(formatter.format(views));  // 9,741,234
```
より簡潔に表示するには、2番目の引数にさまざまなオプションを指定できます。オプションの中で`notation: 'compact'`を指定するとコンパクトになります。
```
const views = 9741275;
const formatter = new Intl.NumberFormat('ja-JP', {
    notation: 'compact'
});

console.log(formatter.format(views));  // 974万
```
さらに、1番目の引数に言語ブラウザのAPIでサポートされている`navigator.language`を指定すると、ユーザーがブラウザで設定した言語を自動的に取得でき、ユーザーが指定した言語に応じて数字を表示できます。
```
const views = 9741234;
const formatter = new Intl.NumberFormat(navigator.language, {
  notation: 'compact'
});

console.log(formatter.format(views));  // 974万
```
## 価格を通貨に合わせて簡潔に表示
同様に`Intl.NumberFormat`を使用します。
1番目の引数には同じく言語を、2番目の引数のオプションで`style: 'currency'`に設定し、currencyオプションで通貨`currency: 'JPY'`を指定します。
```
const price = 1000000;
const formatter = new Intl.NumberFormat('ja-JP', {
  style: 'currency', 
  currency: 'JPY'
});

console.log(formatter.format(price)); // ￥1,000,000
```
ここでも"compact"オプションを使用してコンパクトにすることができます。compactオプションは価格よりはいいねの数など大体の数を表す時にいいかもしれません
```
const price = 1000000;
const formatter = new Intl.NumberFormat('ja-JP', {
  style: 'currency', 
  currency: 'JPY',
  notation: 'compact'
});

console.log(formatter.format(price)); // ￥100万
```
## 相対時間をスマートに表示
商品や記事がいつ公開されたか、何日前、何時間前に投稿されたかを表す必要もあります。相対時間をスマートに表示するためには`Intl.RelativeTimeFormat`を使用します。
`format`の1番目の引数は数字で、2番目には日付か時間か月かなどを指定します。
```
const formatter = new Intl.RelativeTimeFormat('ja-JP');

console.log(formatter.format(1, 'day')); // 1 日後
```
オプションに`numeric: 'auto'`にすると言葉を変えてくれます。
```
const formatter = new Intl.RelativeTimeFormat('ja-JP', {
  numeric: 'auto'
});

console.log(formatter.format(1, 'day')); // 明日
```
入社して何日経ったかを示したい場合、今日を基準にして、入社日の日付を指定し、現在までの日数を計算し、フォーマッタを使用すると、"〜日前”と表示されます。
```
const today = new Date();
const startDate = new Date(2021, 4, 17); // 2021年5月17日　monthは0から始まるため5→4
const daysPassed = Math.ceil((startDate - today) / (1000 * 60 * 60 * 24));
const yearsPassed = Math.ceil((startDate - today) / (1000 * 60 * 60 * 24　* 365));
const formatter = new Intl.RelativeTimeFormat('ja-JP', {
  numeric: 'auto'
});

console.log(formatter.format(daysPassed, 'day')); // 857 日前
console.log(formatter.format(yearsPassed, 'year')); // 2 年前
```
ただし、2番目の引数は日か時間かのどちらか1つだけを指定できます。

この問題を補完できるライブラリ`timeago.js`がありますが、時間がどれだけ経過したかに応じて日か時間かを自動的に表示されるので、相対的な時間のみが必要な場合に便利かと思います。

## 日付と時間を正確に表示
時間を表示するときには、コンパクトにしてより読みやすい場合もありますが、正確な日付を表示する必要があるときもあります。その場合は`Intl.DateTimeFormat`または`toLocalDateString`を使用します。
```
const today = new Date(); // 作成日基準の今日

console.log(today.toString()); // Thu Sep 21 2023 12:05:01 GMT+0900 (日本標準時)
console.log(new Intl.DateTimeFormat('ja-JP').format(today)); // 2023/9/21
```
これをさらに簡略化した方法もあります。
```
const today = new Date();

console.log(
  today.toLocaleDateString('ja-JP', {
    minute: 'numeric',
    hour: 'numeric',
    day: 'numeric',
    month: 'short',
    year: 'numeric',
    weekday: 'short'
  })
); // 2023年9月21日(木) 12:18
```
日付にtoLocaleDateStringを使用するだけで、内部的にはIntl APIを使用するため、より簡単にフォーマットを使用できます。言語を指定するだけでその言語に合わせたフォーマットが表示されます。さらに、さまざまなオプションを指定することもできるので、より簡単にまたはより詳しく表示できます。

### まとめ

IntlはJavaScriptの標準仕様であるので、定期的に更新され常に最新の国際化に向けた実装が可能です。また、外部ライブラリに依存せずに使用できることも良い点です。もちろん一つの言語だけを対応するサイトでも使用でき、その言語に合わせたフォーマットにしてくれるので別途用意しなくて済みます。

日々の開発においても活用していきたいと思います。


#### 参考
- https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Intl
- https://cercopes-z.com/JavaScript/Object-Intl-js.html


【JavaScriptのIntl】数字や日付、価格の表示をスマートに

今回は、Chrome拡張機能の作成についての基本的なガイドをシェアしたいと思います。
「ChatGPT”の”Chrome拡張機能」ではなく、「ChatGPT”で”Chrome拡張機能」を作ってみたです。
Chrome拡張機能は、Google Chromeのブラウザに新しい機能を追加するためのプラグインのようなものです。
なので、ブラウザ上でこんなのあったら良いのになと思ったら、自分で割と簡単に作れてしまうのです。この辺りがChatGPTの革命的なところですね。

ちなみに、MicrosoftEdgeもChromeと同じChromiumベースなので、自作拡張機能を追加することが可能になっています。

## 拡張機能の基本的なファイル構成
 ![](/uploads/chrome_Extension_a9b20e3317.png) 
ファイル構成としては上図を準備します。
各ファイルの役割は以下です。
chatGPTに作ってもらう時もChrome拡張機能にしてとプロンプトに入れると大抵の場合、下記の基本ファイルの記述を教えてくれるので、それらをエディタに記述し、それぞれのファイル名と拡張子で保存をし、任意のフォルダに格納するだけです。
アイコンはchatGPTでは作ってくれないので画像ファイルとして別途用意して下さい。

簡単にリサイズできるサイトもご参考までに。
https://resizeappicon.com/

1. マニフェストファイル (manifest.json): 拡張機能のメタデータを提供します。名前、バージョン、権限、ブラウザアクションやページアクション、コンテンツスクリプトなどの拡張機能の主要な情報を含むJSON形式のファイルです。
2.  バックグラウンドスクリプト (background.js): ブラウザやページのイベントに反応して、拡張機能の主要な機能を制御します。
3. コンテンツスクリプト (content.js): 直接ウェブページにインジェクトされ、ページのDOMを変更する役割を持っています。
4. ポップアップ: ブラウザのツールバーにある拡張機能のアイコンをクリックしたときに表示される小さなウィンドウです。ポップアップのHTML (popup.html) とそれに関連するJavaScript (popup.js) が含まれます。
5. オプションページ: 拡張機能の設定をユーザーがカスタマイズできるページ。options.html と options.js が含まれます。
6. アセットや他のリソース: アイコンや画像、その他の必要なリソース。例えば、icon.png など。
 ![](/uploads/_2518b036c6.png) 

## Chrome拡張機能のインストール手順
 ![](/uploads/2_24dc3436fa.png) 
上述の構成に格納したフォルダを指定することで読み込みが完了すると拡張機能に自分の作ったものが表示されます。

1. Google Chromeブラウザを開きます。
2. URLバーに chrome://extensions/ を入力して、拡張機能のページを開きます。
3. ページの右上にある「デベロッパーモード」のトグルをオンにします。
4. 「パッケージ化されていない拡張機能を読み込む」ボタンをクリックして、作成した拡張機能のディレクトリ（フォルダ）を選択します。
## デバッグ方法
 ![](/uploads/3_b34eedf322.png) 
やっぱり最初の質問でいきなり動くものは作れないので、これもChatGPTにエラーの内容を修正してもらいながら進めます。各種デバッグの方法を記載します。
1. chrome://extensions/ にアクセスします。
2. インストールした拡張機能のリストから、デバッグしたい拡張機能の「詳細」ボタンをクリックします。
3. 「バックグラウンドページ」のセクションに「検証」または「background.html」のリンクが表示されている場合、それをクリックすることで、Chrome Developer Toolsが開きます。
4. ポップアップをデバッグするには、拡張機能のアイコンをクリックしてから右クリックし、「検証」を選択します。
5. コンテンツスクリプトのデバッグは、ページ上で右クリックして「検証」を選び、コンソールを開いてエラーやログを確認します。


## まとめ
 ![](/uploads/4_517f67b3ea.png) 
皆さんも是非、自分のChrome拡張機能を作成してみてください！
拡張機能欄に自分のアイコン（当社のロゴ）が表示された時はプチ感動しました。
構想中のものは、アクティブなタブに対して情報を取得し、日々の業務を楽にするような便利拡張機能なのですが、まだまだ試作中なので、具体的な拡張機能は次回としたいと思います。




large_439082_I made a Chrome extension with ChatGPT! _xl-1024-v1-0.png

medium_439082_I made a Chrome extension with ChatGPT! _xl-1024-v1-0.png

small_439082_I made a Chrome extension with ChatGPT! _xl-1024-v1-0.png

thumbnail_439082_I made a Chrome extension with ChatGPT! _xl-1024-v1-0.png

439082_I made a Chrome extension with ChatGPT! _xl-1024-v1-0.png

ChatGPTでChrome拡張機能を作ってみた！

## はじめに
処理水の問題などで、日中関係は、2023年9月現在決して良いと言えませんが、7月に日本の商品を売り込む大型販売施設がオープンしたというニュースを見つけました。いわゆるショールーミングストアです。

## 施設の概要
 ![](/uploads/cb52c7206e3a8ef0cfcaba048ca828aa_5b6acdb621.jpg) 
> 中国東北部の遼寧省大連市で19日、電子商取引（EC）と連動して日本商品を売り込む大型販売施設が開業した。地元新興企業の大連万衆雲倉科技孵化園が運営し、山口フィナンシャルグループ（FG）などと組んで商品を輸入する。中国で越境EC向けの常設施設は珍しい。

山口フィナンシャルグループは、山口・広島・北九州を中心に展開する銀行です。大連万衆雲倉科技孵化園の親会社は建設業が主力で、保税倉庫、通関、物流、サイトの運営など、越境ECに関わる幅広い領域を新規事業として進めているようです。


## 日本商品の調達方法
記事では、日本商品の調達方法についても書かれていました。
大企業の商品については、万衆雲倉が自社で調達するようです。
万衆雲倉は、2019年すでにこの地区内に保税倉庫を建設しており、あくまでも私の推測ですが、すでに日本企業ともパイプがあるのではないでしょうか。

また、中小企業の商品は、山口FGや中国銀行などが企業を発掘するそうです。中国に中小企業単独で進出するのは難しいので、普段取引をしている銀行を通じて、海外展開できるのは、面白い取り組みと感じました。

## ショールーミングストアについて
ECのデメリットは言わずもがな、商品を手に取ったり、触ったり、食品なら試食したりできないことです。越境ECでは単価も高くなりがちですから、文字情報と写真だけで、購入の判断をしなければなりません。
そういったデメリットを解消しつつ、越境ECを活気づける一つの案がショールーミングストアだと思います。
日経新聞の記事には、施設内の写真も掲載されていました。1枚だけなので限られた情報ではあるのですが、お酒や洗剤が展示されていることがわかります。
このような商材の場合、試飲できるようにしたり、匂いを嗅げるようにできてこそ、ショールーミングストアの真価が発揮されると思います。この施設が実施しているかどうかまでは、分かりません。    
        
## まとめ
ショールーミングストアは越境ECを身近にするよい取り組みと思いますので、この流れが中国のみならず、さらに広まっていくことを願います。

### 参考
日本経済新聞 
`https://www.nikkei.com/article/DGXZQOGM192A30Z10C23A7000000/`




large_volc-xia-nrPaNONc_0k-unsplash.jpg

medium_volc-xia-nrPaNONc_0k-unsplash.jpg

small_volc-xia-nrPaNONc_0k-unsplash.jpg

thumbnail_volc-xia-nrPaNONc_0k-unsplash.jpg

volc-xia-nrPaNONc_0k-unsplash.jpg

中国大連に登場　越境ECショールーミングストア

## はじめに
越境EC物流最大の味方、国際eパケットが2023年10月1日より廃止されることが決定しました。

これまで国際eパケットを利用してきた事業者様にとっては、輸送方法の切り替えをしなくてはいけません。

今回は、国際eパケットの代わりになりそうな日本郵便の輸送方法とその金額を簡単にまとめてみました。

## 小形包装物（Small Packet）
まず、国際eパケットの代わりに最適なのは「小型包装物」です。

サイズや重量の規定（2kgまで）等が国際eパケットと全く同じで、料金体系も、100gから2000gまで100g刻みなところも同じです。

異なるのは、地帯区分の分け方で、国際eパケットだと第4地帯までしかなかったのが、小型包装物は第5地帯まであります。

こちらでは、中国・台湾・韓国向けの第1地帯（国際eパケットの場合、他のアジア諸国も可）と、アメリカ向けの第4地帯を比較してみます。

※実際の料金表は、100gごとに料金体系が変わりますが、こちらでは一部のみの記載とさせていただきました。

<style>
table {
   table-layout: fixed;
   width: 100%;
}
</style>
<table>
<tbody>
<tr>
<th>重量</th>
<th>eパケット（第1地帯）</th>
<th>小型包装物（第1地帯）</th>
<th>eパケット（第4地帯）</th>
<th>小型包装物（第4地帯）</th>
</tr>
<tr>
<td>100g</td>
<td>690円</td>
<td>350円＋410円</td>
<td>1150円</td>
<td>830円＋410円</td>
</tr>
<tr>
<td>300g</td>
<td>870円</td>
<td>550円＋410円</td>
<td>1410円</td>
<td>1250円＋410円</td>
</tr>
<tr>
<td>500g</td>
<td>1050円</td>
<td>750円＋410円</td>
<td>1670円</td>
<td>1670円＋410円</td>
</tr>
<tr>
<td>1000g</td>
<td>1500円</td>
<td>1250円＋410円</td>
<td>2320円</td>
<td>2720円＋410円</td>
</tr>
<tr>
<td>1500g</td>
<td>1950円</td>
<td>1750円＋410円</td>
<td>2970円</td>
<td>3770円＋410円</td>
</tr>
<tr>
<td>2000g</td>
<td>2250円</td>
<td>2400円＋410円</td>
<td>3620円</td>
<td>4820円＋410円</td>
</tr>
</tbody>
</table>

小型包装物の金額で、+410円とされているのは、書留料金です。

国際eパケットにも書留料金が含まれていたので、輸送料だけを考えると、値上げどころか値下げですが、書留量も含むと、全体的に数百円程度値上がりしたことが分かります。

## EMS
次に検討されるのは、EMSでしょう。
国際配送で最も利用されているのがEMSかもしれません。
小型包装物や国際eパケットと違い、大きな荷物も送れる＆リードタイムも短い、というのが特徴的です。

<table>
<tbody>
<tr>
<th>重量</th>
<th>eパケット（第1地帯）</th>
<th>EMS（第1地帯）</th>
<th>eパケット（第4地帯）</th>
<th>EMS（第4地帯）</th>
</tr>
<tr>
<td>100g</td>
<td>690円</td>
<td>-</td>
<td>1150円</td>
<td>-</td>
</tr>
<tr>
<td>300g</td>
<td>870円</td>
<td>-</td>
<td>1410円</td>
<td>-</td>
</tr>
<tr>
<td>500g</td>
<td>1050円</td>
<td>1450円</td>
<td>1670円</td>
<td>3900円</td>
</tr>
<tr>
<td>1000g</td>
<td>1500円</td>
<td>2200円</td>
<td>2320円</td>
<td>5300円</td>
</tr>
<tr>
<td>1500g</td>
<td>1950円</td>
<td>2800円</td>
<td>2970円</td>
<td>6600円</td>
</tr>
<tr>
<td>2000g</td>
<td>2250円</td>
<td>3400円</td>
<td>3620円</td>
<td>7900円</td>
</tr>
</tbody>
</table>

ただ、国際eパケットからEMSに切り替えを検討する場合は、場所や重さによっては2倍近い金額の値上がりになる事が分かりました。

これまでリードタイムで受取人様からのクレームがない、重たい・大きい荷物ではない、という場合には、小型包装物の方が無難でしょう。

## まとめ
今回は、国際eパケット廃止に伴い、類似サービスのコスト比較をしてみました。

越境ECの難点が「輸送費用」。
毎年のように輸送費が値上がりしているので、いつになったら昔のように戻るんだろう・・と願うばかりです。

### こちらの料金表を参考に作成しました
https://www.post.japanpost.jp/int/download/epacket-charges.pdf
https://www.post.japanpost.jp/int/2023fee_revision_kokusai/pdf/charge04.pdf
https://www.post.japanpost.jp/int/charge/list/ems_all.html

※こちらでご紹介した料金表は、2023年9月時点の情報です。

実際に輸送される際には、日本郵便が発表している正しい料金表をご参照ください。

medium_h1.jpg

small_h1.jpg

thumbnail_h1.jpg

h1.jpg

【国際eパケット廃止】<br>代わりになるサービスと料金の比較！

<h2>はじめに</h2>
<p>日本でいうところの「zozotown」にあたる、ドイツ発最大手オンラインファッションECサイト「ザランド（Zalando）」。このZalandoのサスティナブル消費に対する取り組みには様々な形があります。</p>

[前回](https://sterfield.co.jp/blog/zalando-1-sustainability-platform/)はその取り組みの1つである、「サステナビリティプラットフォーム」を紹介しましたが、今回は新たな支払システム「SNBL」を紹介したいと思います。

<h2>BNPL 対 SNBL</h2>
最近よく見かける似た名前のサービスが「BNPL（Buy now pay later）」。顧客が先に商品を受け取り、後で支払うというこの、近年各国の買い物客の間で非常に人気があります。日本のECでもよく見かけるようになりました。
  
SNBL（Save now buy later）、つまり「今は貯めて後で買う」というこのサービスはその逆です。<br>
顧客は貯蓄目標を設定し、その目標を達成するために毎月お金を積み立てます。目標を達成すると、そのお金を使えるようなるだけでなく、Zalandoで使える「ボーナス（バウチャー）」も受け取ることができます。
 ![](/uploads/2023_09_08_180226_95f1bb532f.png) 

※写真は公式サイトのキャプチャ

もし購入したくない場合は、ボーナスなしでお金を引き出すことができます。<br>
また、途中で計画を変更することはできませんが、キャンセルすることはできるので、途中でお金が必要になったら、すぐに引き出せるので安心ですね。

## SNBLはサスティナブル？

購入者に「買わせない」期間を設けるといのは、販売者側からすると異質なサービスに見えるかもしれません。
しかし、世界的に借金やクレジットカード破産、短期ローンが増加する中で、貯蓄を促し、健全な購買活動を生み出すことは、持続可能な社会を実現するの一役買うと言えるではないでしょうか。

また、持続的に購買活動ができる消費者を育てることは、継続的に購入者数を維持・増加させることであり、長期的には売上増加につながっていきます。

実際、目標達成後に買い物をした額は以前より増加している購入者も少なくないのだとか。
 ![](/uploads/2023_09_08_174006_62c32be17f.png) 
※写真は公式サイトを機械翻訳したもののキャプチャ

## SNBLを提供するSavrrとは    
Savrrはドイツのスタートアップ企業です。まだ無名だったこの会社がSNBLを開発を終える前に、Zalandoは契約を結んだそうです。

Savrrは、消費者の金融行動にどのようにプラスの影響を与えることができるかを考え、消費者にもブランドにも利益を与えることを目指しています。

<h2>まとめ</h2>
ヨーロッパのEC業界においてZalandoが与えるインパクトは非常に大きいものです。そのような会社が牽引することで、ヨーロッパのファッションECは持続可能な社会に向けて進んでいくことでしょう。


参考：https://ecommercenews.eu/zalando-pioneers-with-save-now-pay-later/　<br>
https://www.savrr.de/zalando


medium_スクリーンショット 2023-09-08 180202.png

small_スクリーンショット 2023-09-08 180202.png

thumbnail_スクリーンショット 2023-09-08 180202.png

スクリーンショット 2023-09-08 180202.png

健全な購買活動を育てるZalandoの取り組み(2) SNBL導入

## はじめに

本記事では、これから TDD の導入を考えている方や、TDD を導入している案件に携わる方に向けて、私が実際に TDD をやってみて感じたメリット・デメリットをまとめたいと思います。

## テストの重要性

テストは、ソフトウェアの品質向上や開発効率化に欠かせないものになってきています。テストを効果的に活用することで、ソフトウェアの品質や信頼性を向上させ、開発コストを削減することができます。

## TDD(テスト駆動開発)とは

テスト駆動開発（Test-Driven Development、TDD）は、ソフトウェア開発の手法の一つで、テストの作成から始めて、その後にコードを実装するというサイクルを繰り返すことで、品質の高いソフトウェアを開発する手法です。
手動テストするのではなく、[Jest](https://jestjs.io/ja/)や[JUnit](https://junit.org/junit5/)などのテストフレームワークを使用します。

一般的な開発では、下図のように設計とテスト作成は分けて行うと思います。

 ![image](/uploads/20230908_2_b6073f3e4b.png) 

TDD では、最初にテストを作成します。
テスト作成 ≒ 設計のようなイメージです。

 ![image](/uploads/20230908_3_11d5709f45.png) 

## TDD の基本サイクル

TDD は「レッド」「グリーン」「リファクタリング」と呼ばれる工程で進められます。各工程で何をするのか、説明していきます。

### レッド

要件から、実装する機能のテストを作成します。この段階では実装をしていないので、テストはすべて失敗します。
テストツールを使っているときにテストが失敗すると赤色でエラー表示されるため、この工程はレッドと呼ばれます。

### グリーン　

レッドで作成したテストをもとに、実装を行います。
ここで重要なのは、完璧なコードを書くことではなく、先に設定したテスト条件を全てクリアさせるだけの「最小限」のコードを書くということです。
テストツールを使っているときにテストが通ると緑色でエラー表示されるため、この工程はグリーンと呼ばれます。

### リファクタリング

すべてのテストが通るようになったら、リファクタリングを行ってコードの可読性を高めます。
この工程は後回しになりがちですが、プログラムの規模が大きくなると大変になってしまうので、こまめにリファクタリングすることをお勧めします。

## TDD のメリット

TDD を実施すると、以下のようなメリットがあります。

### 安心して実装ができる

テスト条件を全てクリアさせるように実装することで、実装漏れやバグの発生を抑制できます。
また、何を実装すれば良いのかはテストを見ればすぐにわかるので、工数の削減が期待できます。

### 品質向上

テストが既にあることで、開発者がコードを変更する際にも、影響を受ける他の部分に対して問題がないかを確認できます。また、テストが十分にカバレッジされている場合、バグやエラーを早期に発見できるため、ソフトウェアの信頼性が向上します。

### ドキュメントとしての役割

テストコードはソフトウェアの仕様や振る舞いを示すドキュメントとして機能します。ソフトウェアの動作がテストによって明確になり、コードの理解が容易になります。
テストコードはソフトウェアの変更に伴って、常に最新の状態に保つ必要があります。そのため、テストコードはソフトウェアのバージョン管理システムに登録し、管理することが一般的です。

### リファクタリングのサポート

リファクタリングを行う前に、テストケースを実行して、リファクタリング後にもテストが通ることを確認することで、ソフトウェアの外部的な振る舞いを保てていることになるため、安全にリファクタリングを行うことができます。
また、リファクタリングで起きがちなデグレ(デグレード)やバグの発生を防止できます。

## TDD のデメリット

TDD は、ソフトウェアの品質向上や開発効率化に効果的な手法ですが、導入にはいくつかの課題があります。

### テストを作るのに時間(工数)がかかる

TDD は、テストコードを先に作成する必要があるため、開発プロセス全体において時間がかかることがあります。
ただし、長期的にはバグの減少や品質向上が見込めることから、開発全体で考えると時間の節約と考えることもできます。

### 熟練度と学習コスト

TDD は、初めて取り組む開発者にとっては学習コストがかかる場合があります。
効果的なテストを作成するためには、適切なテストケースを選択し、適切なカバレッジを持つことが必要です。
しかし、開発の初期段階に完璧なテストコードを書くのは難しいので、今思い浮かぶ機能の中でテストを作成し、仕様変更などのタイミングでより細かいテストを増やしていく方針で進めていました。

### テストの保守

ソフトウェアの変更に伴い、テストコードも頻繁に更新する必要があるため、テストの保守に工数がかかることがあります。
TDD を導入する際にはその負担をチームに理解してもらう必要があります。

## 課題の解決策

TDD の課題を解決するためには、以下のような対策が考えられます。

### テストコードの自動生成ツールを活用する

テストコードの自動生成ツールとは、ソフトウェアの設計や仕様を元に、テストコードを自動的に生成してくれるツールです。
例えば、テストフレームワークに[Jest](https://jestjs.io/ja/)を使用しているのであれば、[jest-test-gen](https://github.com/egm0121/jest-test-gen)などがあります。
テストコードの自動生成ツールを活用することで、テストコードの作成にかかる時間を短縮することができます。

### テストケースの標準化を図る

テストケースの標準化とは、テストケースの作成や評価に使用するルールや手法を定義することです。
テストケースの標準化をすることで、開発者の経験やスキルに依存することなくテストコードを作成できるため、テストコードの作成や保守の効率化を図ることができます。

### チームでのテスト文化を醸成する

チームでのテスト文化を醸成することで、テストの重要性や必要性を理解してもらい、テストへの協力を得やすくなります。

## まとめ

私は気になるところがあるとすぐにリファクタリングしたくなっちゃう性格なので、TDD にはとても助けられています。
TDD は、一見面倒な手法に思われるかもしれませんが、バグの早期発見や仕様の理解、コードの品質向上など、多くのメリットがあります。
メリットとデメリットを理解した上で、適切に活用していきましょう！

## 参考リンク

- [テスト駆動開発（TDD）とは？基本サイクルと運用時の注意点を解説！【ソフトウェア開発・テスト用語 】| Qbook](https://www.qbook.jp/column/713.html)
- [テスト駆動開発（TDD）入門](https://products.sint.co.jp/ober/blog/tdd)
- [テスト駆動開発（TDD）とは？目的やメリット・デメリット、やり方を解説 ｜ソフトウェアテストの SHIFT](https://service.shiftinc.jp/column/4654/)

medium_20230908_1.jpg

small_20230908_1.jpg

thumbnail_20230908_1.jpg

20230908_1.jpg

TDD(テスト駆動開発)について

<h2>はじめに</h2>
Shopeeを始める上で、事前に確認するべきことがいくつかあります。

1. 商品は販売できるか
2. 現地の類似商品に比べて、機能的な特徴や価格競争力がある（＝売れる見込みが少しだけでもあるか）
3. 輸送ができるか

などなど、かなり基本的な事が多いですが、越境ECを始めるとなると、沢山の事を考えないといけないので、意外と大切なことを見落としてしまう事も多いです。

今回は、その中でも配送、特にShopeeの独自配送サービスであるSLSについてまとめてみました。

<h2>SLSとは</h2>
Shopee Logistics Serviceの略で、Shopeeが海外顧客まで直接商品を安心安全に運んでくれるサービスの事を指します。
実際の物流業者名ではなく、サービスの総称をSLSと読んでいます。

<h2>SLS発送以外の違い・メリット</h2>
ちなみに、SLS以外の発送を、Other Logistics といいます。

<h3>国内配送だけで良い</h3>
SLSの一番のメリットは、日本国内にあるShopee倉庫に商品を送るだけで、顧客向けの配送も管理画面のステータス変更も、全て自動化してくれるという事です。

Shopeeの国内倉庫に商品が届き、後述のSLSラベルがスキャンされた段階で、Shipping（運送中）にステータスが変わる仕組みになっています。


<h3>関税のトラブルがなくなる</h3>
一般的な郵便で配送をすると、受取人（Shopeeで購入してくれたお客様）側に関税の請求がされてしまいます。

関税率の高い商品を販売しているショップさんにとっては、クレーム対策や事前の関税についての周知等、苦労されているでしょう。

SLSを利用すれば、Shopeeが立て替えてくれて、売上から相殺（マレーシア・フィリピン）だったり、事前に商品価格に上乗せ（シンガポール）したりすることで、購入者にShopeeの販売ページでの表示価格以上の請求がされないようになっています。


<h3>Shopeeの管理画面で貨物の追跡ができる</h3>
<img src="/uploads-archive/lc/2023/04/f5611327ef48879d9b73e31c08f6d466-300x269.png" alt="" width="300" height="269" class="aligncenter size-medium wp-image-11804" />

海外配送の場合、一般に荷物がどこまで届いているのか追跡できなかったり、できたとしても更新が遅かったりする場合があります。

SLSでは、Shopeeが荷物のステータスを細かく更新してくれるため、かなり正確に荷物の状況を把握できます。

また、不在で届けられなかった等、トラブルがあった際にも記録をしてくれているので、安心です


<h3>売上金のサイクルが早くなる</h3>
バイヤーが受け取りボタンを押すと、オーダー完了とみなされ、管理画面に売上が反映されます。
しかし、この受け取りボタンを押してくれるバイヤーは少なく、Shopee側で自動的にオーダー完了にしてもらうまで待たないといけません。

SLSの場合、配達が完了した時点で、貨物追跡ステータスが「Parcel has been delivered 」に更新されます。その後、3日後（Shopee Guarantee Period）には自動的にオーダー完了してくれます。

一方、Other Logisticsの場合は、EDD（Estimated Delivery Date）に加えて、台湾、タイどちらも7日間のShopee Guarantee Period が経たないと、オーダー完了にしてもらえません。

Shopeeの方で、配達した記録が残っているからこそ受け取られた注文の売上が早く入ってくる、というメリットがある、と言えるでしょう。


<h2>SLS発送の注意点・デメリット</h2>
良いことばかりのSLSですが、いくつかデメリットもあるので、共有します。

<h3>二重梱包が必須</h3>
SLS発送の注文は、各注文の梱包にラストワンマイルラベルを貼り付ける必要があります。加えて、それらの注文を１つにまとめて、日本国内のShopee倉庫に送らなければいけません。

Shopee専用のラベルの貼り付けに関しては、倉庫によっては対応できなかったり、別料金が発生する事があるでしょう。SLSが必須のシンガポール、マレーシア、フィリピン向けの販売を検討している人は、Shopeeを始める前にSLSの発送対応をどのようにするか、考える事がオススメです。


<h3>送料がダブルでかかる</h3>
国内倉庫への国内配送と、SLSの送料がかかります。
1回の発送で1注文しかない・・という状況だと、なかなか送料負担が大きくなってしまうので、たくさん売れるショップに早く育てて、1回の送料分を抑えられるようにしないといけません。

また、送料関連ではもう1つ注意すべきことがあります。

日本国内はサイズでの課金、国際配送は、一定のサイズ以下で重量課金です。
軽くて小さいものは、送料の面でかなり有利ですが、大きくて軽いもの、小さくて重いものなどは、国内・海外どちらかの配送料で少し悩むことになるかもしれません。


<h2>まとめ</h2>
ということで、本日はShopeeのSLSについてまとめてみました。

スターフィールドでは、Shopee運営にお困りの企業様向けに、Shopeeの支援サポートをさせていただいています。

一緒にShopeeで売り上げを上げて、アジア展開を目指していきたい企業様、お問い合わせお待ちしています！

large_arron-choi-kRK1Bne4xEw-unsplash-scaled.jpg

medium_arron-choi-kRK1Bne4xEw-unsplash-scaled.jpg

small_arron-choi-kRK1Bne4xEw-unsplash-scaled.jpg

thumbnail_arron-choi-kRK1Bne4xEw-unsplash-scaled.jpg

arron-choi-kRK1Bne4xEw-unsplash-scaled.jpg

【Shopee配送方法】<br>Shopee独自の配送サービス、SLSについてまとめてみた

<h2>はじめに</h2>
Xin chào（シンチャオ）！

ゴールデンウィークに初めてベトナムへ行きました。

ベトナム語って、アルファベット表記っぽいですが、見慣れない記号（こんなの⇒「ữ」や、こんなの⇒「ốc」）がいっぱいあって、その語源はなんなんだろう？と気になって調べてみました。
<h2>もともとは漢字を使っていた！</h2>
現在のベトナム語は、Xin chào（シンチャオ・意味：こんにちは）のようにアルファベット表記ですが、昔のベトナムは<strong>独自の言葉はあったものの、文字は存在しませんでした。</strong>

ベトナムの北部は紀元前111年から938年の約1,000年間、中国から属国のように支配されていました。この期間を「北属期」といいます。この間に中国語や漢字文化の強い影響を受けました。

938年に中国との闘いに勝利し、「北属期」から「独立期」になります。しかし独立後も<strong>しばらくの間、独自の文字は存在せず、公文書などは引き続き中国語を使っていました。</strong>
<h2>中国語をアレンジしたベトナム独自の文字の誕生</h2>
15世紀になると、ベトナム独自の文字を使用しようという動きが広がります。

そこで、中国語をアレンジしたベトナム独自の文字が生まれました。

その文字を<strong>「Chữ nôm（チュ ノム）」と言い、「漢越語」と言われる言葉です。</strong>

Chữは「字」、Nômは「ベトナム」という意味です。

<img class="aligncenter size-full wp-image-11864" src="/uploads-archive/lc/2023/05/FB_IMG_1473788779523.jpg" alt="" width="559" height="813" />

ベトナムの国旗のところにあるのが、チュ ノム（漢越語）で書かれた「漢字文化圏」という文字です。

<img class="aligncenter size-full wp-image-11865" src="/uploads-archive/lc/2023/05/4eeebcbe40297dd8172368581a96c70c.png" alt="" width="864" height="253" />

たしかに漢字っぽくて、意味がわかりそうでわからない・・・

チュ ノム（漢越語）は、漢字より複雑で一般層にあまり普及せず、識字率も低い状態が続きました。
<h2>いまのベトナム語文字に変化</h2>
17世紀初頭に転機が訪れます。

ポルトガル人宣教師がラテン語のアルファベットを応用した「アンナム語」を生み出します。

「アンナム語」は、チュ ノム（漢越語）よりかなりシンプルなため、一般層にもなじみやすい言語でした。

同時期にフランス人宣教師が、声調を付ける文字を考案し、現在のベトナム語を作り上げました。

<img class="aligncenter size-full wp-image-11866" src="/uploads-archive/lc/2023/05/img_20221220-2.jpg" alt="" width="1280" height="720" />
<h2>中国語由来の日本語・ベトナム語の共通点</h2>
日本語もベトナム語も中国語由来の言葉が多いため、発音が近い言葉が多くあります。

<img class="aligncenter size-full wp-image-11867" src="/uploads-archive/lc/2023/05/ad51b71f031db556f9cf812cc8870003.png" alt="" width="1174" height="591" />

似てますよね！
<h2>まとめ</h2>
言葉のルーツをたどっていくと、その国の歴史を知ることになり、楽しいですね。言葉は文化であり歴史だなと思いました。
<h3>参考文献</h3>
<a href="https://vietomato.com/han-viet-la-gi">https://vietomato.com/han-viet-la-gi</a>

<a href="https://www.arc-c.jp/translation/blog/20150604/">https://www.arc-c.jp/translation/blog/20150604/</a>

<a href="https://vietlovelog.com/4659/">https://vietlovelog.com/4659/</a>

small_hoian.jpg

thumbnail_hoian.jpg

hoian.jpg

ベトナム語の語源って？

## はじめに
この夏、マレーシアの東側の島、ボルネオ島の最大都市、コタキナバルへ行きました。コタキナバルで感じたことを書きます。

## コタキナバルとは
 ![](/uploads/Malaysia_Map_d8b4a74597.png) 
マレーシアは首都クアラルンプールがある西の半島側と、東のボルネオ島北部にある東マレーシアの2エリアに分かれます。
コタキナバルは、東マレーシア最大の都市です。

## 驚いたこと①トイレ
マレーシアの国教はイスラム教ですが、多宗教国家です。
###### イスラム教　61％
###### 仏教　20％
###### キリスト教　9％
###### ヒンズー教　6％
###### その他　4％

イスラム教の人はトイレットペーパーを使わず、トイレに備え付けのシャワーを使って、自分の左手でお尻を洗います。
 ![](/uploads/toiletin_Malay_a5c0949aac.jpg) 
なので、トイレは結構水でびちゃびちゃ。
トイレットペーパーがないトイレも多いので、常に携帯しておけばよかったなと思いました。

なお、コタキナバルの空港は、"WET"側と"DRY"側に分かれていました。　"DRY"側にしかトイレットペーパーはありません、と書いてありました。

## 驚いたこと②州またぎでパスポート
主に滞在したのは、コタキナバルがあるサバ州という州でした。
マレーシアは西の半島側に11州、東のボルネオ島側に2州、その他1つの連邦直轄領があります。
サバ州は州独自の出入境管理が行われていて、サバ州から同じマレーシア内の別の州へ出る際、またサバ州へ戻る際もパスポートチェックとスタンプが押されます。

↓出たとき
 ![](/uploads/IMG_3158_8f6a8a591c.png) 
↓入ったとき
 ![](/uploads/IMG_3159_5002e63953.png) 

特にサバ州へ入るときのチェックがものすごく厳しかったというか、チェックに時間が掛かりました。
ただ、何をチェックしているわけでもなさそうで、ずーっとパスポートとにらめっこしている感じでした。
あとから現地の人に聞くと、いろいろな歴史的背景もあり、サバ州は他の州と仲が悪いとのこと。
ここらへんはもう少し勉強したいところです。

## 驚いたこと③祝日の勤務協力体制
 ![](/uploads/member_blog_3066_5e240cb2a78db_6537f305c9.jpg) 
前述の通りマレーシアは多宗教国家です。　宗教が異なれば宗教毎に祝日も異なります。

### 祝日例
#### `イスラム教の祝日`
・断食明け大祭（**2023年は4月21日**）

・イスラムの新年（**2023年は7月19日**）
#### `キリスト教の祝日`
・イースターサンデー（**4月17日**）

・クリスマス（**12月25日**）

このように多宗教国家の場合、宗教によって祝日が異なるため、仕事はどうしているのかと聞いてみました。

すると、

> イスラム教が祝日の日：イスラム教以外の人たちで仕事をカバーする。


> キリスト教が祝日の日：キリスト教以外の人たちで仕事をカバーする。


という風にカバーする協力体制ができているとのことでした。



てっきり、どの宗教の祝日でもすべて休んでしまうのかと思ってましたが、これは素晴らしいですね。


## まとめ
コタキナバル滞在中に驚いたことを3つご紹介しました。

日本に留まらず海外へビジネス販路を求めるには、もっともっと海外へ出て、見て・聞いて・触って・感じて　が必要と思いました。

コタキナバルで日本人は多少見ましたが、その10倍くらいの韓国人を見ました。　もっともっと世界へ出ていきましょう。


small_shutterstock_149197103.jpg

thumbnail_shutterstock_149197103.jpg

shutterstock_149197103.jpg

コタキナバル（マレーシア）で驚いたこと

## はじめに
越境EC支援事業を行う中で、スイーツや生鮮品など保冷品の国際宅配便サービスについてご相談いただくことがあります。今回は、冷蔵品・冷凍品に関わらず、保冷品の小包配送についてご紹介します。

## 保冷品とは？
保冷品は、温度を一定の低温で保ちながら商品や食品を保存・運送するための製品や仕組みのことをいいます。例えば食品の場合、保冷品は食材や冷凍食品を冷たい温度で保存し、腐敗や品質の劣化を防ぐのに役立っています。

## 海外への保冷輸送手段
ここでいう海外への保冷輸送は、越境ECでの小包の直送モードについて言及します。国際宅配便各社について調べたところ、以下の結果となりました。

 ![](/uploads/_52886e389a.png) 

唯一保冷輸送が可能なのは、日本郵便が提供するクールEMSでした。発送前の確認と発送準備を以下の手順で進めていく必要があります。

- [ ] 希望する取扱い国の有無を調べる
- [ ] 取扱い国が該当する場合は配送料金を調べる
- [ ] 取扱い郵便局・引き受け可能曜日を確認する
- [ ] 発送可能日を確認する
- [ ] 事前予約申込書を記載する
- [ ] 差出希望日の5日前の正午までに差出郵便局にFAXで申し込みをする
- [ ] 申込締切日の翌日までに、郵便局から連絡がある
- [ ] 予冷、梱包準備の上発送する

現在クールEMSで配送できるのは、台湾、ベトナム、マレーシア、シンガポールの4か国(2023年8月現在)。香港とタイに関しては引き受け停止中となっています。なお、現在西日本地域ではクールEMSの受託が停止されています。
詳しくはこちらのリンクをご参照ください。
https://www.post.japanpost.jp/int/ems/cool/


保冷設備の整った状態で配送できるのはクールEMSでしたが、国際宅配便事業者によっては、事前に各社へ相談の上で荷物にドライアイスをつめた状態での輸送を受託することが可能な場合があります。この場合、通常要求されることのない以下を満たす必要があります。

・荷物外装へのマーキング

- 荷送人と荷受人の住所・氏名
- DRY ICE UN1845
- ドライアイスの正味量(kg)

・荷物外装へのラベル貼り付け

- クラス9のIATAの危険性ラベルの貼付

・送り状ラベルへの記載

- 　Dry Ice, UN1845, ドライアイス梱包の数 x ドライアイスの正味重量(kg)

梱包についても炭酸ガスの蓄積を防ぐために、荷物を完全に密閉しないようにする工夫が必要です。なお、危険物申告書は不要です。

ドライアイスを充填して輸送する場合は、上記のような別途準備が必要となることと、輸送料金とは別途手数料がかかること、ドライアイスを充填することで荷物の重量自体が重くなって輸送料金が高くなる点を考慮しなければなりません。

## まとめ
国際宅配便による保冷品の輸送手段は限られていることがわかりました。越境ECで販売する商材や商品単価、出荷の負荷を考慮した上で適切な配送手段を選択していきましょう。


small_72846cbcb5b523da8a4150515895e821_t.jpeg

thumbnail_72846cbcb5b523da8a4150515895e821_t.jpeg

72846cbcb5b523da8a4150515895e821_t.jpeg

保冷品の国際宅配便サービス

Shopeeの商品情報は非常に複雑で、そのため出力できるCSVデータも複雑であり正直わかりやすい状態ではありません。
なので出力できるファイルとその中身についてまとめます。

出力できるファイルは以下の5つです。

mass_update_basic_info
mass_update_sales_info
mass_republish_items
mass_update_shipping_info
mass_update_media_info

それぞれの内容と項目は以下のとおりです。

### mass_update_basic_info
Product ID: Shopeeの商品IDです
Parent SKU: 該当商品の登録情報「Parent SKU」が出力されます
Product Name: 商品名
Product Description: 商品說明
Fail Reason: 基本的に空欄

### mass_update_sales_info
Product ID: Shopeeの商品IDです
Product Name: 商品名
Variation ID: バリエーションIDです。バリエーションの有無に関わらず値が入ります        
Variation Name: バリエーション名です。バリエーションが2つある場合はセル内にカンマ区切りで2つ入ります     
Parent SKU: 該当商品の登録情報「Parent SKU」が出力されます
SKU	Price: バリエーションごとの価格です    
Stock; バリエーションごとの在庫です    
Fail Reason: 基本的に空欄

### mass_republish_items
Product ID: Shopeeの商品IDです
Product Name: 商品名
Parent SKU: 該当商品の登録情報「Parent SKU」が出力されます
Sales: 過去の販売件数
Stock: バリエーションごとの在庫    
Action: ステータスをDelist または Publish
Fail Reason: 基本的に空欄

### mass_update_shipping_info
Product ID: Shopeeの商品IDです
Parent SKU: 該当商品の登録情報「Parent SKU」が出力されます
Product Name: 商品名
Product Weight/kg: 重さ
Length: 長さ
Width: 横幅
Height: 高さ
Shipping Toggle: 配送切替onまたはoffを指定
I will cover shipping fee: 送料無料onまたはoffを指定
Shipping fee: 配送料
Fail Reason: 基本的に空欄

### mass_update_media_info
Product ID: Shopeeの商品IDです
Parent SKU: 該当商品の登録情報「Parent SKU」が出力されます
Product Name: 商品名
Category: カテゴリのIDと構造。例: 100893 - Beauty/Skincare/Facial Moisturize
Cover image: カバー画像のURL
Item Image 1〜8: 画像1〜8のURL
Size Chart: サイズチャート画像のURL
Variation Name1: バリエーション1の名前    
Option 1 Name〜Option 30 Name: オプション1〜30の名前
Option 1 Image〜Option 30 Image: オプション1〜30の画像URL
Fail Reason: 基本的に空欄


一括での引っ越し作業などの際参照いただければ幸いです。

Shopeeで出力できる商品CSVの種類と内容

# 軽量でセキュアなコンテナイメージを使ってみよう

## はじめに
みなさんは開発にDockerコンテナを使っていますか？ここでいうコンテナとはDockerやDocker互換のコンテナエンジンで動作させられるものを指します。
当社でもDockerコンテナを積極的に利用して開発環境から本番までシームレスな開発、運用ができるよう導入を進めています。

さてそんなDockerコンテナですが、コンテナイメージを管理するためのDockerfileは適切に管理できているでしょうか。
ファイルシステムが差分構成になっていることなどDocker特有の仕組みがあり、ネット上にあるサンプルをそのまま使っているだけで自分たちで中身を書くところまではできてない人が多いのではと想像します。

本記事ではそのような状態から一歩レベルアップするため、Distrolessというベースイメージを使うようDockerfileを書き換えるやり方とその結果どういうことが得られるかを解説していきます。

## Distrolessとは
そもそもDistrolessとはどういうもので、どういう利点があるのでしょうか？
開発元でGoogleのAIであるBardに聞いてみた内容を引用します。

> 引用：Bard（Google AI）

> 質問
> distrolessを使う利点はなんですか？
> 
> 回答
> Distroless は、Google によって開発された、Linux オペレーティングシステムを最小化した Docker コンテナイメージです。Distroless は、アプリケーションを実行するために必要な最小限のファイルとライブラリのみを含むため、軽量でセキュリティに優れています。
> 
> Distroless を使用する主な利点は次のとおりです。
> 
> - 軽量：Distroless は、従来の Linux ベースの Docker コンテナイメージよりも軽量です。これは、Distroless がアプリケーションを実行するために必要な最小限のファイルとライブラリのみを含むためです。
> - セキュリティに優れている：Distroless は、セキュリティに優れています。これは、Distroless がアプリケーションを実行するために必要な最小限のファイルとライブラリのみを含むため、攻撃対象領域が狭いためです。
> - スケーラブル：Distroless はスケーラブルです。これは、Distroless が軽量であるため、多くのコンテナを実行してもシステムに負荷がかかりにくいためです。
> 
> Distroless は、軽量でセキュリティに優れた Docker コンテナイメージを必要とするアプリケーションに最適です。たとえば、Web サーバ、データベースサーバー、アプリケーションサーバなどです。

「軽量でかつセキュリティに優れている」というところに着目してDistrolessを使って進めていきます。

## プログラム
実際の運用イメージにあわせるため、下記のようなExpressを使ったNode.jsアプリを動作させるコンテナを作るDockerfileを対象にします。

- app/app.ts
  ```
  import express from "express";

  const app = express();
  const port = 3000;

  app.get("/", (_req, res) => {
    res.send("Hello World!");
  });

  app.listen(port, () => {
    console.log(`Example app listening on port ${port}`);
  });
  ```
- package.json
  ```
  {
    "dependencies": {
      "express": "^4.18.2",
      "typescript": "^5.1.6"
    },
    "devDependencies": {
      "@types/express": "^4.17.17"
    },
    "scripts": {
      "build": "tsc"
    }
  }
  ```
- tsconfig.json
  ```
  {
    "compilerOptions": {
      "target": "es2016",
      "module": "commonjs",
      "outDir": "./dist",
      "esModuleInterop": true,
      "forceConsistentCasingInFileNames": true /* Ensure that casing is correct in imports. */,

      /* Type Checking */
      "strict": true /* Enable all strict type-checking options. */,
      // "noImplicitAny": true,                            /* Enable error reporting for expressions and declarations with an implied 'any' type. */
      // "strictNullChecks": true,                         /* When type checking, take into account 'null' and 'undefined'. */
      // "strictFunctionTypes": true,                      /* When assigning functions, check to ensure parameters and the return values are subtype-compatible. */
      // "strictBindCallApply": true,                      /* Check that the arguments for 'bind', 'call', and 'apply' methods match the original function. */
      // "strictPropertyInitialization": true,             /* Check for class properties that are declared but not set in the constructor. */
      // "noImplicitThis": true,                           /* Enable error reporting when 'this' is given the type 'any'. */
      // "useUnknownInCatchVariables": true,               /* Default catch clause variables as 'unknown' instead of 'any'. */
      // "alwaysStrict": true,                             /* Ensure 'use strict' is always emitted. */
      // "noUnusedLocals": true,                           /* Enable error reporting when local variables aren't read. */
      // "noUnusedParameters": true,                       /* Raise an error when a function parameter isn't read. */
      // "exactOptionalPropertyTypes": true,               /* Interpret optional property types as written, rather than adding 'undefined'. */
      // "noImplicitReturns": true,                        /* Enable error reporting for codepaths that do not explicitly return in a function. */
      // "noFallthroughCasesInSwitch": true,               /* Enable error reporting for fallthrough cases in switch statements. */
      // "noUncheckedIndexedAccess": true,                 /* Add 'undefined' to a type when accessed using an index. */
      // "noImplicitOverride": true,                       /* Ensure overriding members in derived classes are marked with an override modifier. */
      // "noPropertyAccessFromIndexSignature": true,       /* Enforces using indexed accessors for keys declared using an indexed type. */
      // "allowUnusedLabels": true,                        /* Disable error reporting for unused labels. */
      // "allowUnreachableCode": true,                     /* Disable error reporting for unreachable code. */

      /* Completeness */
      // "skipDefaultLibCheck": true,                      /* Skip type checking .d.ts files that are included with TypeScript. */
      "skipLibCheck": true /* Skip type checking all .d.ts files. */
    },
    "include": ["./src/**/*"]
  }
  ```

### Dockerfile(変更前)
```
FROM node:18-slim
WORKDIR /app
COPY . .
RUN npm install && npm run build

CMD [ "node", "./dist/app.js" ]
```
変更前のDockerfileは上記の通りで、公式で提供されているNode.jsのイメージをそのまま使うだけのDockerfileになります。

### Dockerfile(変更後)
```
FROM node:18-slim as builder
WORKDIR /app
COPY . .
RUN npm install && npm run build

FROM gcr.io/distroless/nodejs:18
ENV NODE_ENV production
WORKDIR /app
COPY --from=builder --chown=nonroot:nonroot /app/dist/app.js ./dist/app.js
COPY --from=builder --chown=nonroot:nonroot /app/node_modules ./node_modules
USER nonroot
CMD [ "./dist/app.js" ]
```
Distrolessを使うように書き換えたものがこちらになります。その中でも特に2点について下記で解説します。

### 変更内容のポイント
1. マルチステージビルド

    Distrolessには実行に必要な最低限のパッケージしか含まれていないため、npmコマンドどころかshell環境自体が存在しません。
    そのため、Dockerのマルチステージビルド機能を利用します。詳細な仕組みの説明は割愛しますが、Dockerfileの前半部分(1行目〜4行目)で
    標準Node.jsイメージを使ってアプリケーションをビルド(ライブラリのインストールとTypescriptのコンパイル)、
    後半部分(6行目〜12行目)でdistrolessに前半でビルドしたファイルのコピーするという2段階構成にします。
    このように変更することでnpmコマンドや、ソースファイルのようなアプリケーション実行に必要がないファイルをイメージファイルに含めないことを実現します。

2. 非root化

    Distrolessとは直接関係ないですが、Docker公式にもベストプラクティスとして書かれている非root化も一緒に行ってます。
    Distrolessイメージではrootユーザー以外にnonrootというユーザーが存在しているため、ファイルのコピー時とCMD実行前にnonrootを指定することでroot権限を持たないユーザーでプログラムを実行できるようになります。

### イメージのサイズの比較
まずはビルドしたイメージのサイズを比較してみます。

- 変更前→express-slim
- 変更後→express-distroless

となります。

```
➜ docker image ls
REPOSITORY           TAG       IMAGE ID       CREATED        SIZE
express-slim         latest    afe678706d58   37 hours ago   312MB
express-distroless   latest    6a1421f17b86   37 hours ago   207MB
```

3割程度小さくなっていることがわかります。
サイズが小さくなることでビルド後のイメージを保存する先のストレージ容量の節約や、デプロイ時間の短縮が期待できます。

### 脆弱性の数の比較
次に[Trivy](https://trivy.dev/)というコンテナイメージの脆弱性スキャナーをつかって検出される脆弱性の個数を比較してみます。

```
➜ trivy image express-slim
(省略)
Total: 51 (UNKNOWN: 0, LOW: 50, MEDIUM: 0, HIGH: 1, CRITICAL: 0)
(省略)

➜ trivy image express-distroless
(省略)
Total: 23 (UNKNOWN: 0, LOW: 11, MEDIUM: 8, HIGH: 4, CRITICAL: 0)
(省略)
```

今回は細かい内容までは追わずに単純な個数で比較しますが、脆弱性の数が半分以下になっていることがわかります
（HIGHが多いのが気になりますが・・）

## その他TIPSなど
### 開発中はSSHできないと不便
:debugタグをつけたイメージを利用することで一般的なコンテナイメージと同様にdocker runコマンドでsshログインが可能になります。

```
FROM gcr.io/distroless/nodejs:18
↓
FROM gcr.io/distroless/nodejs:18:debug
```

### 軽量なコンテナイメージとしてはAlpineのほうが有名なのになぜDistrolessを採用しているのか
Alpineは軽量にするため特殊構成をとっているディストリビューションであり、標準Cライブラリに一般的なglibcではなくmuslを採用しています。
Node.jsではmuslを採用しているプラットフォームで動作させる場合のサポートレベルはExperimentalとなっています(2023年8月現在)。
この点から、実運用時の安定性のことを考えて一般的なディストリビューションであるDebianベース(=標準Cライブラリがglibc)のDistrolessを使いました。

## まとめ
今回はNode.jsのアプリケーションを動かすコンテナをDistrolessを使って構築してみましたが、変更自体も簡単で、記事内で解説したとおり軽量かつセキュアなコンテナにするという目的が達成できそうです。

その要因として、Node.jsインストール済みのイメージがDistrolessで提供されていることが大きかったのですが、たとえばPHPのように標準で提供されてないアプリケーションのコンテナイメージを構築する場合、自前でミドルウェアを追加する作業が必要になり、軽量かつセキュアというメリットがあまり活かせないことになりそうです。

用途に応じた使い分けが必要だと感じました。

## 参考リンク
- [Distroless](https://github.com/GoogleContainerTools/distroless)
- [Best practices for writing Dockerfiles](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/)
- [DockerでNode.jsを動かすときのベストプラクティス](https://blog.shinonome.io/nodejs-docker/)
- [Node.js Docker baseイメージには alpine < distroless < ubuntu+slim 構成がよさそう](https://zenn.dev/jrsyo/articles/e42de409e62f5d)

large_20230825_1.png

medium_20230825_1.png

small_20230825_1.png

thumbnail_20230825_1.png

20230825_1.png

軽量でセキュアなコンテナイメージを使ってみよう

##  1.はじめに
GitHubは、ソフトウェア開発者にとって欠かせないツールの一つとなっています。Issue管理機能を活用すれば、プロジェクトのタスクやバグ、提案などを効率的に管理できます。今回は、GitHubのIssueを自動的にGoogleスプレッドシートに取得する方法を紹介します。

前回の記事では、RestAPIを通してIssueを取得するという方法を試みましたが、Issueの全件取得ができないなど課題を残すものになりましたが、もう一つの手法としてGraphQLにて取得する方法があり、GraphQLではIssueの全件取得に成功致しましたので、そのGASの全文もシェア致します。

https://sterfield.co.jp/blog/git-hub-gas/

### REST API と graphQLの違い

ChatGPTが教えてくれた違いを記載します。

REST (Representational State Transfer) APIとGraphQLは、クライアントとサーバー間でデータをやり取りするための方法として使用されるインターフェイスですが、設計思想や操作方法が異なります。以下に主な違いを挙げます。

設計思想:

REST: RESTful設計はリソース指向です。それぞれのリソース（例：ユーザー、記事など）に対して一つのエンドポイントがあります。HTTPメソッド（GET、POST、PUT、DELETEなど）を使ってリソースに対する操作を行います。
GraphQL: GraphQLはデータ指向です。クライアントは必要なデータの構造を指定し、サーバーはその構造に基づいてデータを返します。一つのエンドポイントを持ち、クエリ言語を用いてデータの取得や変更を行います。
データの取得:

REST: クライアントはサーバーから提供されるエンドポイントに従ってデータを取得します。このため、過不足のデータが返されることがよくあります。
GraphQL: クライアントは必要なデータだけを指定して取得できます。これにより、過不足のデータが返されることが少なくなります。
エンドポイント:

REST: それぞれのリソースや操作に応じて多数のエンドポイントが存在します。
GraphQL: 一般的には一つのエンドポイント（たとえば /graphql）で全ての操作をカバーします。
エラーハンドリング:

REST: HTTPステータスコード（200, 404, 500など）を使ってエラーの種類を示します。
GraphQL: ほとんどの場合、200のHTTPステータスコードで応答し、エラーの詳細はレスポンスボディの中に含められます。
バージョン管理:

REST: 新しいバージョンのAPIをリリースする際、URLにバージョン情報を含めるなどの方法で旧バージョンとの互換性を維持することがよくあります。
GraphQL: フィールドやタイプを非推奨にするなどの方法で、APIの変更をスムーズに管理できます。
フレキシビリティ:

REST: サーバーサイドで提供されるエンドポイントとその構造に従わなければなりません。
GraphQL: クライアントがどのデータを必要としているかを明確に指定できるため、クライアントサイドでのフレキシビリティが高まります。
それぞれの技術には独自の利点と制約があります。使用する場面やニーズに応じて最適なものを選ぶことが重要です。

## 2.必要なもの
Googleアカウント  
GitHubアカウント  
GitHubのPersonal Access Token (リポジトリへのアクセス権限を持つもの)

## 3. 事前準備
### 3.1 GitHubのPersonal Access Tokenの取得
 ![](/uploads/Fine_grained_Personal_Access_Tokens_861a8dbc65.png) 
GitHubにログインして、Settings > Developer settings > Personal access tokens に進む。
"Generate new token" ボタンをクリック。
必要な権限を選択し、トークンを生成。

### 3.2 Google Apps Scriptの準備
 ![](/uploads/Chat_GPT_GAS_Google_1_8c0845570a.png) 

Google Driveにアクセスし、新しいスプレッドシートを作成。
Extensions > Apps Script から、スクリプトエディタを開く。
## 4. スクリプトの作成
Google Apps Scriptのコードをスクリプトエディタにコピー&ペースト  
※最下部にGAS全文掲載しています。  
YOUR_GITHUB_TOKENとORGANIZATION_NAMEを、それぞれ適切な値に置き換える。

## 5. スクリプトの実行
スクリプトエディタの上部にある実行ボタンをクリック。
必要な権限を付与し、スクリプトを実行。

今回のGASでは実行できるメニューを追加しています。
 ![](/uploads/GAS_Github_Google_553126d37c.png)
 
## 6. 結果
 ![](/uploads/GAS_Github_Google_e97d4e37e8.png) 
Googleスプレッドシートに、GitHubのIssueの情報が自動で追記される。リポジトリ名、Issue番号、タイトル、作成日、更新日、URLなどの情報を取得できる。

## 7. まとめ
GitHubのIssueをGoogleスプレッドシートに自動取得する方法を紹介しました。この方法を利用することで、プロジェクトの進捗管理やレポート作成を効率的に行うことができます。さまざまなカスタマイズや拡張が可能なので、ご自身のニーズに合わせて活用してみてください。
当社では、一ヶ月毎にIssueの棚卸しに活用できそうだと話しています。

## 8. Google Apps Script全文

### 機能

- スプレッドシートのメニューに実行ボタンを追加
- アクティブなスプレッドシートを取得し、内容をクリア    
- リポジトリ名、Issue番号、タイトル、作成日、更新日、URLを列に追加

### 注意点

- リポジトリの中の最初の100件のIssueを取得します。(first: 100)の値を変えることができるかは未検証
- スクリプト実行の度にスプレッドシートの内容をクリアするため、書き込んだ内容も消えてしまいます。
- 
```
function onOpen() {
  var ui = SpreadsheetApp.getUi();
  
  // カスタムメニューを追加
  ui.createMenu('GitHub Menu')
      .addItem('Fetch GitHub Issues', 'fetchAllRepoIssuesAndAppendToSheetWithUrl')
      .addToUi();
}

function fetchAllRepoIssuesAndAppendToSheetWithUrl() {
  var GITHUB_API_URL = 'https://api.github.com/graphql';
  var GITHUB_TOKEN = 'YOUR_GITHUB_TOKEN';  // GitHubのPersonal access token
  var ORG_NAME = 'ORGANIZATION_NAME';
  
  var sheet = SpreadsheetApp.getActiveSpreadsheet().getActiveSheet();

  // スプレッドシートの内容をクリア
  sheet.getRange(1, 1, sheet.getLastRow(), sheet.getLastColumn()).clearContents();
  
  // リポジトリ一覧の取得
  var repoQuery = `
  {
    organization(login: "${ORG_NAME}") {
      repositories(first: 100) {
        edges {
          node {
            name
          }
        }
      }
    }
  }
  `;

  var headers = {
    'Authorization': 'bearer ' + GITHUB_TOKEN,
    'Content-Type': 'application/json'
  };

  var options = {
    method: 'post',
    headers: headers,
    payload: JSON.stringify({query: repoQuery})
  };

  var response = UrlFetchApp.fetch(GITHUB_API_URL, options);
  var jsonResponse = JSON.parse(response.getContentText());
  
  if (jsonResponse.errors) {
    Logger.log(jsonResponse.errors);
    return;
  }

  var repositories = jsonResponse.data.organization.repositories.edges;
  
  // 各リポジトリからIssueを取得してスプレッドシートに追加  
  repositories.forEach(function(repo) {
    var issueQuery = `
    {
      repository(owner: "${ORG_NAME}", name: "${repo.node.name}") {
        issues(first: 100, states: OPEN) {
          edges {
            node {
              number
              title
              createdAt
              updatedAt
            }
          }
        }
      }
    }
    `;

    options.payload = JSON.stringify({query: issueQuery});
    response = UrlFetchApp.fetch(GITHUB_API_URL, options);
    jsonResponse = JSON.parse(response.getContentText());

    if (jsonResponse.errors) {
      Logger.log(jsonResponse.errors);
      return;
    }

    var issues = jsonResponse.data.repository.issues.edges;
    
    issues.forEach(function(issue) {
      var issueUrl = `https://github.com/${ORG_NAME}/${repo.node.name}/issues/${issue.node.number}`;
      
      sheet.appendRow([
        repo.node.name,
        issue.node.number,
        issue.node.title,
        issue.node.createdAt,
        issue.node.updatedAt,
        issueUrl  // F列にURLを追加
      ]);
    });
  });
}

```



medium__744f5a47-585b-4840-a782-b47ed954000c.jpg

small__744f5a47-585b-4840-a782-b47ed954000c.jpg

thumbnail__744f5a47-585b-4840-a782-b47ed954000c.jpg

_744f5a47-585b-4840-a782-b47ed954000c.jpg

GitHubリポジトリからIssueを取得してスプレッドシートに追記するGAS(GraphQLバージョン)

Company

Our Solutions

Support

News

Blog

Blogブログ

カテゴリーから探す

年別から見る

記事一覧

2023/10/06

2023/10/05

2023/10/05

2023/09/29

2023/09/27

2023/09/22

2023/09/21

2023/09/14

2023/09/14

2023/09/08

2023/09/08

2023/09/01

2023/09/01

2023/08/31

2023/08/30

2023/08/25

2023/08/25

2023/08/24