ウォレット開発の費用相場。金額が変わる条件と、含まれる作業の範囲
ウォレット開発の費用相場を、1つの数字で言い切ることはできない。
私たちの場合、費用は機能の範囲で決まり、あなたの要件を聞いたうえで見積もりを出している。
見積もりも相談も無料だ。
どの条件が金額を動かすかを先に知っておけば、相談の時に伝えることがはっきりする。
ウォレット開発の費用相場は、何で決まるのか
金額を決めるのは、どこまでの機能を入れるかだ。
私たちは相場の数字を示さず、要件を聞いてから見積もりを出す。
見積もりは無料で、相談だけでも受けている。
基本の作業に含まれる範囲
基本の作業でまかなえるのは、ひとつのチェーンで送る、受け取る、残高を見るだけの口座機能までだ。
チェーンとは、仮想通貨の取引記録が刻まれる土台のネットワークを指す。
この範囲を超える要望は、すべて追加の見積もりになる。
逆に言えば、基本の作業に何が入っているかが分かれば、あとは足し算で考えられる。
追加見積もりになる4つの項目
| 項目 | 見積もりが増える理由 |
|---|---|
| 複数人での承認方式 | 決めた数の承認が集まって動く仕組みを足す |
| 複数のチェーンへの対応 | 扱うチェーンや通貨を増やす |
| ブラウザとスマホの両方 | 2つの形で利用者に届ける |
| 外部のセキュリティ監査会社への依頼 | 第三者による点検を加える |
4つとも、規模に応じて見積もりが変わる。
最初の公開にどこまで入れるかを決めると、見積もりの幅が一気に狭まる。
迷うなら、利用者が離脱している場面に直接効く機能から並べるとよい。
ウォレット開発で、見積もりとは別に負担するものは何か
ガス代、セキュリティ監査会社の費用、アプリストアの費用は、依頼側の負担になる。
開発の見積もりには含まれないため、予算を組むときは別枠で見ておく。
- ガス代（チェーン上で取引を動かすときの手数料）
- 外部のセキュリティ監査会社に頼む場合の費用
- アプリストアに公開するための費用
鍵を預からない設計と、復元できる範囲
私たちは秘密鍵やシードフレーズを預からない。
シードフレーズとは、鍵を復元するための単語の並びだ。
紛失したときに復元できるのは、利用者の手元にある情報の範囲に限られる。
公開の前には、分かっている弱点をつぶす。
これから現れる攻撃の手口まで、すべて食い止められるとは約束していない。
法律や規約の判断は、専門の窓口へ
交換業の登録が必要かどうかなど、法律や規約に関わる判断は私たちでは行わない。
専門の窓口に相談してもらう。
開発に入る前に確認しておくと、作る機能の線引きも決めやすい。
独自ウォレットでは、何を作ってもらえるのか
自社のサービスに組み込める口座機能を、鍵の管理方法から設計して作る。
送る、受け取る、残高を見るだけでなく、鍵の守り方や承認の手続きまでが対象だ。
鍵を守るための機能
- 鍵の生成と、端末の中での暗号化保管、失ったときに元へ戻す仕組み
- 何にサインしているかを人が読める形で見せる表示
- 送る金額の上限と、承認の手続き
- 決められた数の承認が集まってはじめて動く、複数人での管理方式
複数人での管理方式は、マルチシグと呼ばれる。
1人分の鍵だけでは資産が動かないため、1つの鍵が漏れても全額を失わない。
利用者への届け方は3通りある
| 届け方 | 利用者が使う場所 |
|---|---|
| ブラウザに追加する形 | 利用者のブラウザ |
| スマートフォンのアプリ | 利用者のスマートフォン |
| 他のアプリの内部に埋め込む形 | あなたのサービスの画面の中 |
取引所やチェーン上のアプリとのつなぎ込み、仮想通貨での支払いの受け取りにも対応する。
すでにあるウォレットの修正や、脆弱性の診断だけを頼むことも可能だ。
どの形が自社に合うか分からない段階でも、そこから一緒に決められる。
独自ウォレットは、登録の離脱と鍵の事故にどう効くのか
効く場所は2つある。
1つは、別のアプリを入れる手順で起きていた登録の離脱。
もう1つは、鍵が漏れて全額を失う事故への備えだ。
外部ウォレットへの誘導をやめる
外部のウォレットへ誘導する作りだと、利用者は別のアプリを入れる手順を挟む。
その時点で離脱する人が出る。
サービスの中だけで資産を持てるようにすれば、その手順がなくなり、登録が完了しやすくなる。
取りこぼしていた登録は、そのまま成果として積み上がる。
ウォレットの開発費は、この増えた登録で回収を考える投資になる。
鍵が1つ漏れても、全額を失わない
漏れた資産は取り返しがつかない。
だから、漏れた後の対応より、漏れても全額が消えない作りを先に用意する。
秘密鍵を端末内で暗号化し、マルチシグや鍵の分割保管を組み合わせる。
署名の内容を人が読める形で見せるため、意図しない送金も防ぎやすい。
資産を預ける利用者からの信頼を保つ土台にもなる。
鍵を預かる作りや、設計だけの提案と何が違うのか
私たちは、鍵を運営側が預からない。
生成も保管も利用者の端末で行い、運営側を含め誰も中身を見られない作りにする。
| 観点 | よくある作り | 私たちの作り |
|---|---|---|
| 鍵の置き場所 | 運営側が預かる | 利用者の端末で暗号化して保管 |
| 弱点への対応 | 公開後に穴が見つかる | 公開前にコードと外部ライブラリと設定を確認 |
| 鍵の扱い | 不慣れなまま作る | 取引所への注文に自分の鍵で署名して送る仕組みを毎日運用 |
| 守備範囲 | 設計だけで終わる | 既存サイトの点検と、取引の場とつながる鍵の運用まで |
実際に鍵を動かしている会社が作る
私たちは、資産の売買を4年にわたって続けている。
分散型取引所のHyperliquidで、自分のウォレットの秘密鍵で注文に署名して送るコピートレードの仕組みを組み、毎日動かしている。
鍵を実際に動かしているから、どこで事故が起きやすいかを設計に反映できる。
見積もりを依頼するときに、何を伝えればよいか
次の3点を教えてもらえれば、見積もりに進める。
見積もりも相談も無料だ。
- 希望する見せ方（ブラウザに追加する形、スマホのアプリ、他のアプリの内部、複数人管理の形など）
- 対応したい通貨とチェーン
- 組み込み先となるサービスの概要と、見込む利用者数
どの見せ方が向いているか判断できない段階でも構わない。
利用者がアプリの中だけで資産を持てるようになり、外部への誘導で取りこぼしていた登録がそのまま増えている。
そんな状態を目標に、一緒に範囲を決めていく。
公開後の点検や既存ウォレットの修正も、続けて相談してもらえる。
相談の入り口は、鍵管理を重視した独自ウォレット開発のページにある。
鍵管理を重視した独自ウォレットの開発自社のサービスに組み込める仮想通貨用の口座機能を、鍵の管理方法から設計して作るサービスサービスの詳細を見るよくある質問
既存のウォレットの診断だけを頼めるか
頼める。
既存のウォレットの修正や、脆弱性の診断だけの依頼にも対応している。
新しく作り直すかどうかは、診断の結果を見てから決められる。
最初から複数のチェーンに対応させるべきか
主要なチェーンには最初から対応させたほうがよい。代表的なチェーンに対応していないと、利用者が増えないからだ。
時価総額の上位50位ほどの暗号資産のチェーンから入れ、利用者が増えてから広げる進め方を勧めている。複数のチェーンへの対応は追加の見積もりになる。
見込む利用者の通貨を教えてもらえれば、優先順位を一緒に考える。
ブラウザ拡張とスマホアプリの両方が必要か
両方が必要とは限らない。
両方に対応する場合は追加の見積もりになる。
利用者がどちらで登録に来ているかを見て、片方から始めるかどうかを決めるとよい。
見せ方が決まっていなくても相談できるか
できる。
サービスの概要と利用者の動き方を聞き、向いている見せ方を一緒に選ぶ。
相談は無料だ。
ブラウザ拡張機能のウォレット開発には費用がいくらかかるか
決まった値段は無く、機能の範囲を聞いたうえで見積もりを出している。
ブラウザに追加する形のウォレット開発に対応している。
相談と見積もりは無料だ。
ウォレットの作成を依頼すると費用はいくらかかるか
決まった値段は無く、あなたの要件を聞いたうえで見積もりを出している。
費用は機能の範囲で決まる。
相談や見積もりは無料だ。
この記事のポイント
- 費用は機能の範囲で決まり、金額は無料の見積もりで出す
- 基本の作業は、ひとつのチェーンで送る・受け取る・残高を見る口座機能まで
- 複数人承認、複数チェーン、ブラウザとスマホ両対応、外部点検は追加の見積もり
- ガス代、セキュリティ監査会社、アプリストアの費用は依頼側の負担
- 鍵は利用者の端末で暗号化して保管し、運営側も中身を見られない
鍵管理を重視した独自ウォレットの開発自社のサービスに組み込める仮想通貨用の口座機能を、鍵の管理方法から設計して作るサービスサービスの詳細を見る
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Webサイト脆弱性の報告書と改善手順、危険度の高い順に直す方法
Webサイト脆弱性の報告書を受け取ったら、最初に危険度「高」の項目から手を付ける。
改善手順は、危険度の高い順に進めると被害が出る前に問題を減らせる。
報告書には問題ごとの直し方が並んでいる。
どこから着手するか、自社で直すか任せるかを決めるには、報告書の読み方を知っておく必要がある。
Webサイト脆弱性の報告書と改善手順、どこから読むか
Webサイト脆弱性の報告書を受け取ったら、最初に危険度「高」の項目を確認してほしい。
改善手順も、危険度の高い問題から進めるのが基本になる。
報告書の見方を間違えると、優先度の低い修正に時間を使い、危険な箇所を放置してしまう。
危険度の高、中、低が示す意味
危険度「高」は、攻撃が現実に通り、情報の流出やサイトの改ざんにつながる問題だ。
最初に直す。
危険度「中」は、特定の条件がそろうと危険な状態になる。
危険度「低」は、単独では大きな被害になりにくいが、別の弱点と組み合わさると危険になる場合がある。
報告書に書かれた問題を、そのまま置くとどうなるか
Webサイトの脆弱性を放置すると、情報の流出、サイトの改ざん、事業の停止といった事態が起きやすい。
客の個人情報や注文データが漏れれば、事業への信用が失われる。
報告書に載った問題は、危険度の高い順に直すのが安全だ。
報告書を受け取ってから、最初にやること
報告書を受け取ったら、最初に問題を再現できるか確かめる。
再現できれば、報告書の改善手順が今のサイトに合っていると判断できる。
再現できない場合は、条件が変わったか、報告の内容に食い違いがあるかを確認する。
報告内容が再現できるか確かめる
報告書に再現手順が書かれていたら、その通りに操作して問題が起きるか見る。
ログイン画面に問題があるなら、指摘された操作で本来見えない情報が出るかを試す。
再現には、本番とは別の確認用サイトを使うと安全だ。
本番のサイトで攻撃に近い操作をすると、負荷がかかったり、データを書き換えたままにしたりする。
影響のありそうなページと機能を名指しで確認する
報告書の問題ごとに、影響がどこまで及ぶかを確認する。
認証（ログインの仕組み）の不備なら会員情報や管理画面、通信の不備なら申し込みフォームや支払いの手続きが影響を受ける。
影響を受ける機能が分かれば、次の動作確認の範囲も狭められる。
改善手順を、サイトを止めずに進めるには
改善手順は、いきなり本番のWebサイト（実際に公開しているサイト）に適用しない。
まずテスト環境（本番と同じ構成の確認用サイト）を用意し、直した内容が動くかを確かめてから本番へ移す。
テスト環境があれば、サイトを止めずに修正を進められる。
本番の前に、テスト環境を用意する
テスト環境は、本番と同じ構成に近い場所を作る。
使っているWordPressやNext.js（JavaScriptのフレームワーク）の構成、サーバーの設定を揃えるほど、本番で起きる問題を先に見つけやすい。
社内にテスト環境が無ければ、開発担当者に相談するか、外部の技術者に環境の準備から頼む方法がある。
直した後の確認を、画面とログの両方で行う
修正をテスト環境に反映したら、画面の動きとサーバーのログを両方見る。
画面では、利用者の導線通りに動くか。
ログでは、意図しないエラーや不正なアクセスが残っていないかを確認する。
問題が消えていれば、本番環境へ反映する。
自社で直すか、修正まで任せるかを分ける
報告書の改善手順を自社で進めるか、外部に任せるかは、修正する範囲と社内の技術力で決める。
認証と認可（ログインと、ユーザーごとの権限の管理）、セッション（ログイン後の状態を覚えておく仕組み）のような外から見えない部分は、テストを整えないと直しにくい。
| 自社で直しやすいもの | 任せたほうがよいもの |
|---|---|
| 文言の修正 | 認証と認可の見直し |
| プラグインの更新 | セッション管理の修正 |
| 権限や公開範囲の変更 | APIと通信の見直し |
| 設定画面で完結する変更 | 依存パッケージの更新作業 |
自社で直せる範囲の見分け方
ユーザーの画面から見える文言の修正、プラグインの更新、ファイルの権限変更などは、手順が明確なら社内でも直しやすい。
認証と認可、セッションの扱い、API（外部のシステムとデータをやり取りする窓口）の設計は、動くことの確認に技術者が要るので、誰にでも直せる範囲ではない。
私たちに診断を依頼すると、どこまで進むか
私たちのウェブセキュリティ診断は、認証と認可、セッション、データの読み取り、APIと通信、依存パッケージ（サイトが使っている外部の部品）まで点検する。
見つかった問題は危険度の高、中、低に分け、問題ごとに具体的な改善手順を示した報告書を渡す。
報告で終わらせず、修正と対策の実施まで担当することもできる。
一般的なWebサイトに加えて、独自開発のシステムやNext.jsのモダンな構成も診断できる。
診断の前には、使用技術、サーバーとインフラの情報、これまでの事故の有無を確認する。
診断を依頼する前に確認しておくこと
Webサイトの脆弱性診断を依頼するときは、対象サイトの所有権または管理権限があることを確認してほしい。
サーバーやログインの情報は、正式な発注の後に共有する流れが安全だ。
所有権または管理権限のあるサイトだけが対象
私たちが診断するのは、依頼者本人に所有権または管理権限があるサイトに限る。
運営を委託されている場合も、管理権限があれば対象になる。
権限のないサイトは、診断すること自体が許可されていない操作になるため扱わない。
サーバーやログイン情報を渡すタイミング
サーバーやログインの情報は、正式な発注の後に共有してほしい。
見積もりや相談の段階では、対象のURLと使っている技術、気になっている箇所を聞かせてほしい。
情報の受け渡しを後にするのは、不要なログイン情報を渡す人を増やさないための手順だ。
よくある質問
報告書に載っている問題を、全部直す必要はあるか
危険度の高い順に直す。
危険度「高」と「中」は、ウェブサイトを公開しているなら早めに手を付ける。
危険度「低」は、直す手間と放置したときの影響を比べて、順番を決めればよい。
低と書かれていても、別の弱点と組み合わさるものは先に直すことがある。
自社で直す場合、どこから手を付ければよいか
報告書の改善手順を、危険度の高い順に1つずつ進める。
本番の前にテスト環境を用意し、再現の確認、修正、動作確認をその中で終わらせる。
テスト環境が無い場合は、作るか、外部の技術者に準備から頼むのが確実だ。
報告書の内容が分からない場合、どうするか
私たちの報告書は専門外の人にも分かる言葉で書く。
専門用語は、何が起きるかと、どう直すかという形で説明する。
読んで分からない箇所があれば、そのまま聞いてほしい。
独自開発のシステムやNext.jsのアプリでも診断できるか
診断できる。
一般的なWebサイトだけでなく、独自開発のシステム、Next.jsなどのモダンなWebアプリも対象にしている。
ソースコードを攻撃する側の視点で一行ずつ読み、プラグインに頼った点検では拾えない弱点まで洗い出す。
診断の結果、問題が無かった場合はどうなるか
問題が無ければ、その旨を報告書にまとめて渡す。
安心の根拠になる。
脆弱性はその後に見つかることもあるため、依存パッケージの更新や、設定の変更があったタイミングで再診断を受ける選択肢もある。
この記事のポイント
- Webサイト脆弱性の報告書は、危険度の高い順に読む
- 改善手順は、本番の前にテスト環境で試す
- 再現確認と影響範囲の切り分けを先に行う
- 自社で直せる範囲と、任せる範囲を分ける
- 診断は所有権または管理権限のあるサイトだけが対象
ウェブセキュリティ診断・対策認証から依存パッケージまで診断し、危険度と改善手順を報告書にまとめる。希望があれば修正まで担当するサービスの詳細を見る・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
セキュリティ診断は安くても大丈夫か。失敗しないために見る5つの点
セキュリティ診断を安さだけで選んでも大丈夫か。
答えは「安いこと自体が失敗の理由ではない」だ。
ただし、安い診断には調べる範囲が狭いことと、報告書だけで終わることが起きやすい。
この2つを見ておかないと、診断したのに穴が残ってしまう。
あなたが確かめたいのは、安いかどうかより、危険な場所から順に直せるところまで届くかどうかだ。
安い診断を選ぶときでも、中身と流れを確認すれば失敗は避けられる。
診断の失敗は、後から気づきやすい。
診断後に事故が起きて初めて「あの時、範囲を見ていなかった」と分かる。
そうならないための確認の仕方を、順を追って書く。
安いセキュリティ診断で起きる失敗
安い診断で起きる失敗は、大きく2つある。
調べる範囲が狭いことと、見つけた問題を直す手順まで手渡されないことだ。
どちらかが欠けると、診断を終えても「本当に安全か」を確かめられない。
自動ツールだけの点検で、見えない穴が残る
セキュリティ診断には、自動ツールだけのものと、人が攻撃する側の視点で調べるものがある。
自動ツールは、公開された脆弱性や設定のミスを素早く見つける。
一方で、認証やセッションの扱いのように、コードを一行ずつ読まないと分からない弱点は拾えない。
ログイン後に他の利用者の情報を見られてしまう欠陥も、このタイプだ。
安さの理由が「ツールだけ」である場合、表面は問題なしと出ても、深い場所に穴が残る。
報告書だけを受け取って止まる
診断結果が一覧で渡されても、何から直すかが分からなければ、報告書は棚に置かれたままになる。
危険度の高、中、低に分かれ、それぞれに具体的な直し方が付いていて、初めて手を付けられる。
自社に直す人員がいないなら、修正まで引き受けてくれるかも確認しておく。
| ありがちな形 | 確認したい形 |
| 自動ツールだけで表面を点検する | 認証やセッションまでコードを読んで点検する |
| 問題の一覧だけを渡す | 危険度の高・中・低と直し方を渡す |
| 報告書で終わる | 希望すれば修正まで進める |
安くても大丈夫かを見分けるチェック項目
安い診断だからといって、すべてが失敗につながるわけではない。
安くても、次の2つがそろっていれば判断材料としては十分に使える。
逆に、これが無いなら、安さの分だけ何かが省かれていることが疑わしい。
あなたのサイトの構成を診られるか
診断の範囲は、相手が普段診ている対象によって変わる。
一般的なWebサイト向けの点検では、独自に作ったシステムやNext.jsのようなモダンな構成の穴まで届かない。
診断前に、使用している技術、サーバーとインフラ、これまでに事故があったかを伝えられるかを見る。
あなたのサイトと同じ構成を診られるかも確認する。
危険度の順と直し方が付くか
報告書の中身が、後からの行動を決める。
見つかった問題が危険度の高、中、低に分かれて並び、それぞれにどう直すかが書かれているかを見る。
専門外の人が読んでも分かる言葉で書かれていると、社内で「どこから着手するか」を決めやすい。
見つけた箇所を並べただけの報告書では、優先順位が付かず、結局すべてが後回しになる。
診断の前後にやっておくこと
診断が失敗する原因には、前後の段取りもある。
用意する情報と、共有するタイミングを間違えると、診断が始まらないか、始まっても思った場所まで届かない。
順に整えておくと、安い診断でも大丈夫かを見極めやすくなる。
診断の前に用意する情報
診断を受ける前には、次の情報をまとめておく。
- 対象になるサイトのURL
- 使用している技術（言語、フレームワーク、ライブラリ）
- サーバーとインフラの情報
- これまでに事故があったかどうか
これらを先に整理しておくと、診断できる範囲とできない範囲がはっきりする。
サーバーやログイン情報は発注後に共有する
サーバーやログインの情報は、正式な発注が決まった後で共有すればよい。
見積もりの段階で機密情報を渡す必要はない。
診断する側も、発注前に詳しい情報を受け取るより、決まってから受け取る方が安全に扱える。
先に渡すように急かす相手には注意する。
私たちの場合も、サーバーやログイン情報は正式な発注の後に共有してもらっている。
診断後どこまで進むか
報告書を受け取った後にどうなるかを確認する。
自社で直せるなら、直し方の手順が具体的かを見る。
自社では直せないなら、修正と対策の実施までお願いできるかを確かめる。
報告書を受け取って終わりなのか、直すところまで進めるのかで、その後の安心感が変わる。
安さより中身で選ぶための考え方
セキュリティ診断を安さだけで選ぶと、後から「診たはずの場所が漏れていた」と気づく失敗につながる。
安いことが問題なのではなく、安さの理由を確認しないことが問題だ。
何が省かれているのかを知った上で選べば、安い診断でも失敗は避けられる。
あなたにとってのゴールは、診断を受けることではなく、危険な場所から順に手を打てる状態になることだ。
安さの裏で次の3つが消えていないかを確かめるのが、安い診断で失敗しないための最短の手順だ。
- 診断の範囲が自社の構成に合っている
- 危険度の順と直し方が報告書にある
- 必要なら修正まで進められる
私たちが診断をするときも、対象のサイトに所有権か管理権限があるかを先に確認し、サーバーやログイン情報は正式な発注後に共有してもらう。
安さで選ぶ前に、この流れを整えておくと、診断の失敗は避けられる。
よくある質問
安いセキュリティ診断でも、危険な場所は見つかりますか
自動ツールで見つかる公開された脆弱性や設定ミスは、安い診断でも見つかることがある。
ただし、認証やセッションのようにコードを読まないと分からない穴は、範囲に含まれていないと残る。
何を診るかを先に聞くと、見つかる範囲がはっきりする。
診断はWebサイトだけが対象ですか
一般的なWebサイトに加えて、独自開発のシステムやNext.jsのようなモダンなWebアプリを診られるかは、相手によって違う。
自社の構成を伝えて、対象になるかを確認する。
診断できるのは、依頼者本人に所有権または管理権限があるサイトに限られる。
サーバー情報はいつ渡せばよいですか
正式な発注の後で共有すればよい。
見積もりの段階でサーバーやログインの情報を渡す必要はない。
発注前に急かされたら、先に進む前に扱いを確認する。
報告書をもらった後、自社で直せない場合はどうすればよいですか
修正まで受け付けてくれる相手を選ぶ。
危険度の順と直し方が付いた報告書があれば、修正を外注する場合も、どの範囲から頼むかがはっきりする。
報告書だけで終わる相手と、修正まで進める相手の違いは、選ぶ段階で確認しておくと安心できる。
診断後に「問題なし」と言われました。信じても大丈夫ですか
「問題なし」は、何を診たかの裏付けがあって初めて信じられる。
自動ツールだけの点検なら、コードの内部に穴が残ったままだ。
診た範囲と方法が報告書に書かれているかを見ると、判断しやすい。
この記事のポイント
- 安い診断の失敗は、範囲が狭いことと報告書だけで終わること
- 安くても、対象の構成と危険度順の報告書があれば判断できる
- サーバーやログイン情報は正式な発注後に共有する
- 診断後、修正まで進めるかを確認すると安心できる
- 安さではなく、範囲と報告書と修正先の中身で選ぶ
ウェブセキュリティ診断・対策認証から依存パッケージまで診断し、危険度と改善手順を報告書にまとめる。希望があれば修正まで担当するサービスの詳細を見る・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験