Googleがプライバシーポリシーを更新、GmailやフォトのデータがAIモード広告に影響
Googleがプライバシーポリシーを更新し、GmailやGoogleフォト、Googleドライブの情報がパーソナライズド広告の表示に使われる可能性が出てきた。同ポリシーは2026年10月16日から適用されている。
影響を受けるのは、Personal Intelligenceをオンにしてアプリを接続したユーザーに限られる。広告主向けに新しいターゲティング設定が追加されるわけではないが、AIモード広告の配信ロジックに関わるため、仕組みを把握しておく必要がある。
Googleのプライバシーポリシーで何が変わったのか
今回の変更点は、長年維持されてきた原則に例外を加えたことだ。Googleはこれまで「GmailやGoogleドライブ、Googleフォトのコンテンツに基づいてパーソナライズド広告を表示しない」と明記していた。無料版Gmailのスキャンによる広告配信は2017年に終了しており、それ以降はこの原則が維持されてきた。
従来のポリシーと新しい例外
更新後のポリシーでは、従来の記述を残したまま次の例外が追加された。「これらのサービスのデータを、パーソナライズド広告に対応する他のGoogleサービスで利用できるよう選択した場合は除く」という内容だ。
新たに加わった説明では、ユーザーが検索やGeminiアプリに他のGoogleアプリの情報へのアクセスを許可できるとしている。その情報がどう使われるかは、アクセスを受けるサービスの設定とポリシーに依存する。Googleは特に、検索がパーソナライズのためにその情報の一部を使う可能性があると明記した。広告もその対象に含まれる。
上の比較が示すとおり、プライバシーポリシーの変更は「無条件で広告に使わない」から「接続した場合に限って使われる可能性がある」への転換だ。
Personal Intelligenceが広告に与える影響
Personal Intelligenceとは
Personal Intelligenceは、Googleが2026年1月に米国で提供を始めたオプトイン機能だ。Geminiと検索のAIモードが、接続したアプリの情報を文脈として参照できるようになる。対象はGoogle AI ProとAI Ultraのサブスクリプション契約者で、個人アカウントに限る。Workspaceのビジネス、エンタープライズ、教育アカウントは対象外だ。
検索者がPersonal Intelligenceを使うと、AIモードはGmailにあるホテル予約や航空券の確認情報と、Googleフォトにある旅行の写真を参照して回答を調整できる。ショッピングでは、よく購入する商品の種類や利用する店舗を踏まえた提案が可能になる。GoogleのSearch担当バイスプレジデントであるRobby Stein氏は、2026年1月の発表で「自分の旅程と好みをすでに把握しているパーソナルショッパーのようなもの」と説明している。
AIモード広告でのデータの扱い
3月に機能を拡大した時点では、Personal Intelligenceの体験に広告は表示されないとGoogleは説明していた。一方で、接続ユーザー向けに将来は同じような形で広告が機能する可能性にも言及していた。今回のテストは、その方針が具体化したものだ。
検索ヘルプの説明によると、広告はメールや写真ライブラリの生データと直接照合されるわけではない。検索は接続元の情報から作成した要約、抜粋、推論を参照してパーソナライズを行い、同じ情報が広告表示にも使われる可能性があるとされている。
この図にあるように、広告主が生データに触れる経路は存在しない。あくまでAIモードが生成した要約や推論が広告表示の判断に使われる。
ユーザーが選べるオプトアウト
Googleはデータの扱いについて、いくつかの境界線も示している。広告主がユーザーのGmailの受信トレイやGoogleフォトのライブラリに直接アクセスすることはない。人種、宗教、性的指向、健康といったセンシティブカテゴリに基づくパーソナライズド広告は引き続き表示しない。
ユーザーはMy Ad Centerで広告のパーソナライズを無効にするか、Googleアカウントの検索パーソナライズ設定から「接続コンテンツアプリ」を選択して接続を解除できる。注意点として、My Ad Centerで広告のパーソナライズをオフにしても、接続アプリのデータがAI機能に渡ることは止まらない可能性がある。GmailやフォトをPersonal Intelligenceから完全に切り離すには、アプリの接続解除が必要だ。
さらに、接続アプリの要約、抜粋、推論はGoogleの生成AIモデルのトレーニングに使われる可能性があり、AIモードとAsk Mapsで処理されたデータの一部は人間のレビュアーによって確認されることがある。この点もヘルプページに記載されている。
広告主にとっての意味
広告主にとって重要なのは、Google広告の管理画面に新しいターゲティングトグルやオーディエンスセグメントが追加されない点だ。Personal Intelligenceは検索者側の機能であり、Googleは広告主向けの新しいコントロール、ターゲティングオプション、専用レポートを発表していない。
Google広告の管理画面で確認できること
キャンペーンの対象条件は、既存のAIモード広告のルールが適用される。GoogleがAIモード広告テストの対象に挙げたのは、Performance Max、Shopping、部分一致を使用するSearchキャンペーンだ。Search向けのAI Maxも含まれる。ただし、対象キャンペーンだからといってPersonal Intelligenceユーザーに配信された実績があるとは限らない。このテスト専用の参加条件も発表されていない。
上記のとおり、広告主側で新しく操作できる項目はない。効果を測る手段も限られている。
レポートの制限
対象となる広告主にとって、接続アプリはクエリに含まれていない購買ニーズの情報を補う可能性がある。しかし、その情報が配信や成果にどう貢献したかを確認する手段は限られている。現時点のレポートには2つの制約がある。
- 接続アプリの情報がインプレッションに影響したタイミングを示す専用レポートが存在しない
- AI Maxの検索語句、アセット、ランディングページレポートでは、Gmailやフォトの情報が貢献したかどうかを特定できない
つまり、キャンペーンがPersonal Intelligenceユーザーに配信されたとしても、その内訳を管理画面から切り分けることはできない。AI Maxのレポートはパフォーマンスの全体像を示すが、接続アプリ由来の信号かどうかは判別されない。
まだ明らかになっていないこと
Googleは、Personal Intelligenceを有効にしたユーザー向けのAIモード広告がいつテスト段階を終えるかを発表していない。広告主向けの専用レポートや配置コントロールが提供されるかどうかも未定だ。
接続アプリの信号が広告をパーソナライズする範囲も明確ではない。テストはAIモードについて説明されているが、The Keywordの記事では、Googleのヘルプページが広告パーソナライズの質問に対して「検索サービス」全体で回答していると指摘している。同ページは検索サービスをGoogle検索（AIモードとDiscoverを含む）、マップ、ショッピング、フライト、ホテル、翻訳、ニュースと定義している。
さらにGoogleは今後数カ月かけて、Web & App ActivityとSearch Personalizationの設定を、Search Services HistoryとPersonalized Recommendationsという2つの新しい設定に置き換える予定だ。この移行が広告の透明性にどう影響するかは、追加の情報を待つ必要がある。
この記事のポイント
- Googleがプライバシーポリシーを更新し、Gmail、Googleフォト、Googleドライブのデータが条件付きでパーソナライズド広告に使われる可能性が出てきた
- 対象はPersonal Intelligenceをオンにしてアプリを接続したユーザーに限られ、広告主が生データに直接アクセスすることはない
- Google広告に新しいターゲティング設定や専用レポートは追加されず、既存のキャンペーンタイプが対象になる
- 接続アプリの情報が広告配信に与えた影響を広告主が確認する手段は、現時点では提供されていない
スクレイピング開発を依頼する費用は何で決まる？見積もりの中身
スクレイピング開発を依頼する費用は、収集先の数、ログインの有無、分散収集や可視化まで含めるかで変わる。
金額は作業量に応じた見積りで決まり、私たちは見積もりも相談も無料で受けている。
同じ「データを集める」依頼でも、1つのサイトから集めるのか、ログインが要るサイトを何か所も回るのかで、作る中身がまったく違う。
費用の動き方を先に知っておけば、見積書を見たときに何にお金がかかっているのかが読める。
スクレイピング開発の依頼費用は何で決まるのか
費用は、作業量で決まる。
私たちの場合、標準的な規模で1つのサイトからデータを集める範囲までを基本の作業とし、それを超える分を追加の見積りとして積み上げる。
料金表に決まった金額を並べる形にしていないのは、依頼ごとに集めたいデータも、取得元の条件も、件数も違うからだ。
あなたの依頼を聞いてから、必要な作業だけを見積もる。
基本の作業と、追加の見積りの分かれ目
分かれ目は、次の表のとおりだ。
左が基本の作業、右が作業量に応じて追加の見積りになるものである。
| 区分 | 内容 |
|---|---|
| 基本の作業 | 標準的な規模で1つのサイトからデータを集める |
| 追加の見積り | 収集先が複数ある |
| 追加の見積り | ログインが要るサイトから集める |
| 追加の見積り | 複数のサーバーで分散して集める |
| 追加の見積り | 可視化まで含める |
つまり、収集先が1つでログインも要らない依頼は作業が少なく、条件が重なるほど作業が増える。
逆にいえば、本当に必要な条件だけに絞れば、見積りも絞れる。
サーバー費用は実費として別にかかる
サーバー費用などの実費は、依頼する側の負担になる。
開発の見積りとは別の項目なので、見積もりの相談では、動かし続けるサーバーの構成も一緒に話す。
ログインや分散収集で、なぜ作業量が増えるのか
ログインの自動化、アクセス制限への対策、分散収集、データベース化、可視化は、それぞれが独立した作り込みになるからだ。
条件が1つ増えるたびに、設計と確認の作業が1段増える。
集める段階で手間が増える3つの条件
- ログインが必要なサイトは、人が毎回行っているログインと操作を自動で回す作りにする必要がある
- アクセス制限を受けにくくするには、ブロックされない収集の設計から行う
- 数万件以上の規模では、1台で回さず複数のサーバーに分けて収集する
既存のツールが途中でブロックされて止まる、件数が数万件になると時間がかかりすぎて回らない。
こうした悩みは、この3つの作り込みで解決する。
止まらずに集め続けるには、ツールの設定より先に、収集の設計から見直す。
集めた後で手間が増える3つの条件
集めて終わりにしないのが、私たちのデータ収集・分析基盤の構築だ。
集めたデータはデータベースに入れる。
データベースは、データを項目ごとに整理して溜めておく置き場で、表計算ソフトのように散らばらず、集計にそのまま使える。
その上にダッシュボードを作り、数字をグラフで見られるようにする。
さらに定期実行を組み込むので、決まった間隔で自動的に集め続ける。
CSVを開いて同じ加工をやり直す作業は、ここでなくなる。
| 段階 | 増える作業 |
|---|---|
| 集める | ログイン自動化、制限対策、分散収集 |
| 溜める | データベース化、集計できる形への整理 |
| 見る | ダッシュボードでの可視化 |
| 続ける | 定期実行によるモニタリング |
依頼前に何を決めておくと見積もりが早く出るか
決めておくのは4つある。
必要なデータの種類、取得元、件数と頻度、ログインの要否だ。
私たちは着手前に、この4つを必ずすり合わせている。
4つの項目と、見積りへの影響
| 決めること | 見積りに効く理由 |
|---|---|
| データの種類 | 集める項目の数で作業が変わる |
| 取得元 | 収集先の数が追加見積りに直結する |
| 件数と頻度 | 分散収集や定期実行が必要か分かれる |
| ログインの要否 | 自動化の作り込みが必要か分かれる |
全部が固まっていなくてもよい。
「競合の価格を毎日見たい」といった目的から話してもらえれば、4つの項目は一緒に整理する。
見積もりも相談も無料なので、まず聞いてみるところから始められる。
引き受けられない依頼は、先に線引きする
私たちは、対象サイトの利用規約に反する収集と、権限のないアカウントへのアクセスは行わない。
違法行為や著作権侵害、競争上の加害にあたる依頼も引き受けない。
この線引きは、着手前に伝える。
途中で「やはりできない」とならないよう、できる範囲を先に決めてから設計に入る。
規約に反する収集を前提にした仕組みは、作った後で止まるリスクを抱えるので、あなたにとっても得にならない。
費用をかけて集めたデータは、事業の何に変わるのか
変わるのは、値付けと仕入れの判断だ。
市場と競合の動きが数字で残り続けるので、勘に頼らず判断できる。
同時に、同じ加工と手作業のコピーをやり直す時間が要らなくなる。
手作業の時間が、判断の時間に変わる
ログインが要るページを人が毎回コピーし、CSVを開いて同じ加工をやり直す。
この作業は、依頼費用を考えるときに見落とされやすい。
毎週の作業時間は見積書に載らないが、積み上がれば確実にコストになっている。
収集が自動になれば、その時間は集計を見て考える時間に使える。
一度きりではなく、時系列で追えるようになる
一度きりの収集では、その日の状態しか分からない。
定期実行で集め続ければ、競合の価格や市場の動きが時系列で残る。
値下げのタイミングや、品揃えの変化が数字で見える。
ダッシュボードがあれば、社内の誰もが同じ数字を見て話せる。
データはあるのに誰も見ていない、という状態から抜け出せる。
見積もりを依頼するとどう進むか
集めたいデータの種類と取得元、件数と頻度、ログインの要否を聞かせてもらえれば、実現できる形を私たちから伝える。
既存のツールでブロックされて集まらない場合も、分散収集と制限に強い設計で対応できる。
見積もりも相談も無料だ。
基盤が動き始めたあとも、収集先を増やしたい、ダッシュボードに指標を足したいといった相談は続けて受けられる。
作って終わりではなく、データが増えるのに合わせて一緒に育てていく関係を想定している。
基盤が動いたあとのあなたは、勘で決めていた値付けと仕入れを、数字で裏づけて決めている。
同じ商品でも、判断の精度が変わることで手元に残る利益が変わっていく。
サービスの詳細と相談の窓口は、データ収集・分析基盤の構築のページにまとめている。
データ収集・分析基盤の構築数万件規模のデータを集め続け、データベース化して集計と可視化まで行う基盤を作るサービスの詳細を見るよくある質問
見積もりだけでも依頼できるか
できる。
見積もりも相談も無料だ。
依頼を決めていない段階でも、集めたいデータの内容を伝えてもらえれば、実現できる形を返す。
今使っているツールでブロックされていても集められるか
止まっていた収集を進められるように作る。
私たちはアクセス制限を受けにくい収集の設計を行い、必要に応じて複数のサーバーに分けて収集する。
ただし、対象サイトの規約に反する収集は行わない。
サーバー費用は見積りに含まれるか
含まれない。
サーバー費用などの実費は、依頼する側の負担になる。
開発の見積りとは別項目として扱う。
規約で禁止されているサイトからも集めてほしい場合は
引き受けられない。
利用規約に反する収集と、権限のないアカウントへのアクセスは行わないと決めている。
着手前にできる範囲を伝え、その範囲で設計する。
スクレイピングやデータ収集の自動化を外注する費用の相場はいくらか
スクレイピング開発の費用は、収集先の数やログインの有無、分散収集や可視化まで含めるかで変わる。
金額は作業量に応じた見積もりで決まり、決まった値段はない。
見積もりと相談は無料で受けている。
この記事のポイント
- スクレイピング開発の費用は作業量で決まり、標準的な規模の1サイト収集までが基本の作業である
- 収集先の追加、ログイン、分散収集、可視化は、作業量に応じて追加の見積りになる
- データの種類、取得元、件数と頻度、ログインの要否を決めておくと見積もりが進めやすい
- サーバー費用などの実費は依頼側の負担で、見積もりと相談は無料である
- 規約に反する収集や権限のないアクセスは引き受けず、着手前に線引きを伝える
データ収集・分析基盤の構築数万件規模のデータを集め続け、データベース化して集計と可視化まで行う基盤を作るサービスの詳細を見る
WordPressで更新に失敗しました サーバーから有効な応答を取得できませんでしたと出る時の対処法
ブロックエディターで「更新に失敗しました。サーバーから有効な応答を取得できませんでした」と表示されて固定ページや投稿を保存できない場合、原因はエディターとサーバー間をつなぐREST APIの通信エラーだ。パーマリンク設定の再保存とWordPressアドレス、サイトアドレスの一致確認から始めると解決できることが多い。
なぜ「更新に失敗しました」と表示されるのか 原因を切り分ける
編集画面でこのエラーが出るとき、書いた内容がサーバーに届いていない。ブロックエディターは保存処理をREST API（レストエーピーアイ / エディターとサーバーがデータをやり取りする仕組み）経由で実行する。この通信が通らなければ「有効な応答が取得できない」状態になる。原因として多いのは次の4つだ。
- パーマリンク設定の乱れ（書き換えルールの不整合）
- WordPressアドレスとサイトアドレスの不一致（httpとhttpsの混在など）
- WAF（ウェブアプリケーションファイアウォール）による /wp-json/ の遮断
- サーバー側のPHP設定やメモリ上限による処理停止
Twenty Twenty-Fourなどのブロックテーマを使い、プラグインを入れていない環境でもこのエラーは発生する。テーマやプラグインの競合だけに原因を絞らず、サーバーとエディターの通信経路を疑うのが最短の解決につながる。
「ブラウザーに保存されたバックアップが現在の内容と異なる」というメッセージが出る場合も、保存処理自体が失敗していることを示す副次的な症状だ。バックアップを復元しても保存に失敗するのは、エディターからサーバーへの通信が断たれているためである。
上から順に確認すると原因を特定しやすい。次から各手順を詳しく見ていく。
最初に試すのはパーマリンク設定の再保存
管理画面の「設定」→「パーマリンク設定」を開き、「投稿名」を選択した状態で「変更を保存」を押す。見た目上は何も変わっていなくても、内部の書き換えルールが再生成されてREST APIの経路が修復されることがある。「昨日まで普通に保存できていたのに急にエラーになった」という場合の定番対処だ。
パーマリンク設定の画面に「.htaccessを更新できません」という趣旨のメッセージが表示されていれば、サーバー上の .htaccessファイルの書き込み権限を確認する必要がある。FTPまたはサーバー管理画面のファイルマネージャーで権限を確認し、必要なら664や666に変更してから再度保存を試す。
WordPressアドレスとサイトアドレスの一致を確認する
「設定」→「一般」を開くと「WordPressアドレス (URL)」と「サイトアドレス (URL)」の2つの欄がある。この2つが完全に一致していることを確認する。特にhttpとhttpsが混在している、片方だけサブディレクトリが付いている、といった不一致があると保存処理が失敗しやすい。
ここで重要なのは、この2つの欄を管理画面から安易に変更してはいけないという点だ。間違えて変更すると、サイト全体と管理画面にアクセスできなくなることがある。値が食い違っているのを見つけても、すぐに手を加えず、次の復旧方法を読んでから作業するのが安全だ。
サイトヘルスでREST APIエラーを特定する
「ツール」→「サイトヘルス」を開き「REST APIでエラーが発生しました」という表示を探す。この表示が出ていれば、サーバー側のファイアウォール（WAF）が /wp-json/ への通信を遮断している可能性が高い。レンタルサーバーの管理画面からWAF設定を一時的に無効にするか、サーバー会社に問い合わせて「/wp-json/ へのリクエストがブロックされていないか」を確認する。
サイトヘルスにエラーが出ていない場合でも、通信が不安定なケースはある。ブラウザーの開発者ツールで「ネットワーク」タブを開き、保存ボタンを押したとき /wp-json/ へのリクエストが403や500になっていないかを確認する方法も有効だ。ここで明確なステータスコードが出れば、サーバー会社に伝える情報として使える。
サイトアドレスを変更してサイトが開けなくなった時の復旧
「WordPressアドレス」と「サイトアドレス」の値を管理画面から変更したあと、サイトも管理画面も開けなくなることがある。この状態はwp-config.phpまたはデータベースから直接修正すれば復旧できる。まずはwp-config.phpに定数を追記する方法が簡単だ。
wp-config.phpに定数を追記して復旧する
FTPまたはサーバー管理画面のファイルマネージャーでwp-config.phpを開き、以下のコードを追記する。example.comの部分は実際の独自ドメインに置き換える。
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );この2行を追記すると、データベースに保存された値より優先してWordPressがURLを認識するようになる。管理画面に再ログインできたら「設定」→「一般」で正しい値を入力し、追記した2行を削除する。
phpMyAdminからオプション値を直接修正する
wp-config.phpを編集できない環境なら、phpMyAdminでwp_optionsテーブルを開き、siteurlとhomeの2つのオプション値を正しいURLに直接変更する。こちらも修正後に管理画面へアクセスできるようになる。
誤ったアドレス変更をしても、ファイルまたはデータベースから正しい値を戻せばサイトは復旧する。慌てずどちらかの方法を試す。
ブロックテーマのテンプレートとヘッダー警告への対応
Twenty Twenty-Fourはブロックテーマなので、固定ページのレイアウトはすべてテンプレートで決まる。新しいページを追加したときに同じテンプレートが自動適用されるのは仕様であり、異常ではない。エディター右側の設定サイドバーを開き、「ページ」タブにある「テンプレート」プルダウンで別のテンプレートに切り替える。「タイトルなし」や「ブランク」などの選択肢が用意されている。
「ヘッダーが削除されました」という警告は、テンプレートパーツのヘッダーが編集されて整合性が取れなくなっている状態を示す。テンプレートパーツ内のタイトルを直接編集した場合などに起きやすい。「外観」→「エディター」→「パターン」→「テンプレートパーツ」→「ヘッダー」を開き、三点メニューから「リセット」を選ぶと初期状態に戻る。この操作でテンプレートパーツの問題は解消する。
よくある質問
パーマリンク設定を再保存しても直らない場合はどうすればよいか
次にWordPressアドレスとサイトアドレスの一致を確認する。それでも直らなければサイトヘルスでREST APIのエラーを調べ、WAFによる遮断がないかサーバー会社に問い合わせる。
サイトヘルスに「REST APIでエラーが発生しました」と表示されたら
サーバー側のファイアウォールが /wp-json/ への通信を遮断している可能性が高い。レンタルサーバーの管理画面でWAF設定を確認するか、サーバー会社に /wp-json/ へのブロック解除を依頼する。
サイトアドレスを間違えて変更して管理画面に入れなくなった
wp-config.phpにWP_HOMEとWP_SITEURLの定数を追記して強制的に正しいURLを指定する。FTPが使えない場合はphpMyAdminからwp_optionsテーブルのsiteurlとhomeを修正する。
ブロックテーマで固定ページごとに違うレイアウトにする方法
エディター右側の設定サイドバーを開き、「ページ」タブの「テンプレート」プルダウンからページごとに別のテンプレートを選ぶ。Twenty Twenty-Fourには複数のテンプレートが標準で用意されている。
「ヘッダーが削除されました」という警告の直し方
外観＞エディター＞パターン＞テンプレートパーツ＞ヘッダーを開き、三点メニューから「リセット」を選ぶ。テンプレートパーツが初期状態に戻り、警告は消える。
この記事のポイント
- 保存エラーの主因はエディターとサーバーをつなぐREST API通信の失敗
- 最初にパーマリンク設定を再保存して書き換えルールを修復する
- WordPressアドレスとサイトアドレスの一致を確認し、安易に変更しない
- 誤ってアドレスを変更して開けなくなったらwp-config.phpで復旧する
- ブロックテーマのテンプレート切替とテンプレートパーツのリセットでレイアウトを整える
WordPress 7.2 Beta 1が公開。テキストシャドウやSecrets APIなど主要変更点を解説
WordPress 7.2 Beta 1が10月20日に公開された。今回のベータではレスポンシブデザイン制御の拡張、テキストシャドウ機能、Secrets APIの導入など、編集体験と開発者向け機能の両面で大きな変更が含まれている。
正式版のリリースは12月8日を予定している。ベータ版は本番環境での使用を想定しておらず、テスト専用の環境で新機能を試すことが推奨される。
この記事ではWordPress 7.2 Beta 1の主要な変更点とテスト方法を解説する。企業サイトの運用担当者やWeb制作会社のエンジニアにとって、次期バージョンがサイトにもたらす影響を先取りできる内容だ。
テスト方法とリリーススケジュール
WordPress 7.2 Beta 1を試す方法は4つ用意されている。最も手軽なのはWordPress Playgroundで、ブラウザを開くだけで設定不要でテストできる。既存のテスト環境がある場合は、Beta Testerプラグインを使うか、zipファイルを直接ダウンロードしてインストールする方法が一般的だ。
WP-CLIに慣れている開発者であれば、コマンドラインから wp core update --version=7.2-beta1 を実行するだけで更新できる。いずれの場合も、本番サイトではなくステージング環境やローカル環境を利用することが前提になる。
上の図は4つのテスト方法をまとめたものだ。開発経験が少ない場合はPlaygroundが最も手軽で、テスト環境を構築済みの場合はプラグインか手動インストールを選ぶとよい。
編集体験を強化する新機能
WordPress 7.2ではブロックエディタの編集体験が大きく変わる。特にレスポンシブデザインとタイポグラフィの制御が強化され、サイト全体のデザイン管理が柔軟になる。
レスポンシブデザイン制御とテキストシャドウ
WordPress 7.1で導入されたビューポート別スタイリングが、より多くのブロックとデザインツールに拡張された。画面サイズごとにブロックの設定を変えられる範囲が広がり、ギャラリーのカラム数や画像の切り抜き、アスペクト比まで端末別に調整できる。
テキストシャドウ機能も新しく追加された。ブロック設定からテキストに影を付けられるほか、theme.json というテーマ設定ファイルでプリセットを定義できる。サイト全体でタイポグラフィの一貫性を保ちながら、見出しやラベルに奥行きを加えられる。
このデモではテキストシャドウの有無による見た目の違いを示している。実際のエディタでは影のオフセット、ぼかしの強さ、色をスライダーで調整できる。テーマ側でもプリセットを定義しておけば、投稿者はワンクリックで適用できる。
メディアアップロードの高速化
メディアライブラリへの画像アップロード処理が変わる。従来は画像をサーバーに送信してからサーバー側でリサイズや圧縮を行っていたが、WordPress 7.2では処理の一部をブラウザ側で実行する。クライアントサイド処理と呼ばれるこの仕組みにより、アップロードの待ち時間が短縮され、サーバーリソースの消費も抑えられる。
この変更は特に画像処理能力が限られた共用サーバーや、大量の画像を扱うメディアサイトにとって効果的だ。ブラウザ側で処理が済むため、サーバーのCPU負荷が下がり、同時に複数のアップロードを行っても安定しやすくなる。
Notes機能のコラボレーション強化
Notes機能はWordPress 7.2で大きく使いやすくなる。コメント機能のような位置づけで、編集画面内にメモを残してチームメンバーとやり取りできる。今回のアップデートでは絵文字リアクションが追加され、Notesを開くためのツールバーアイコンも新設された。
さらに、Notesがエディタのキャンバス上に移動し、ブロック設定サイドバーと同時に開けるようになった。レビュー内容を確認しながら編集を続けられるため、デザインフィードバックを反映する際の行き来が減る。折りたたんで表示を最小化するモードも用意され、画面が狭い環境でも快適に使える。
管理画面とパフォーマンスの改善
編集体験だけでなく、WordPress管理画面全体の使い勝手も向上している。特にリソースの読み込み方法が見直され、管理画面の表示速度が改善する見込みだ。
管理画面のリソース読み込み最適化
従来のWordPressは複数のJavaScriptやCSSファイルを大きな統合ファイルにまとめて読み込んでいた。ファイル数は減るが、実際には使わないスクリプトも読み込まれるため、初回表示が遅くなる問題があった。
WordPress 7.2では、これらのリソースを個別のファイルに分割して読み込む方式へ変更される。ブラウザキャッシュが効きやすくなり、さらに先読みメカニズムも導入された。ユーザーが次に開きそうな管理画面を予測し、必要なリソースを事前に読み込むことで、画面遷移が高速化される。
この改善は管理画面を日常的に使う運用担当者にとって嬉しい変更だ。特にページ数が多いサイトや、複数人でコンテンツを更新する環境では、画面遷移の待ち時間が短縮される効果を実感しやすいだろう。
新しいダッシュボードウィジェット
WordPress 7.2では「On This Day」ウィジェットがダッシュボードに追加される。過去の同じ日に公開された投稿を表示する仕組みで、以前書いた記事を再発見したり、更新や再共有のきっかけを見つけたりできる。
長期間運用しているサイトでは、過去のコンテンツが埋もれがちだ。このウィジェットはコンテンツの棚卸しを促す役割を果たす。季節性のある記事や、更新が必要な古い記事を発見する手助けになるだろう。
管理画面の一貫性向上
従来の管理バーやサイドバーで使われていたDashiconsが、WordPressのアイコンライブラリに置き換えられる。新しいアイコンセットに統一されることで、従来のダッシュボードと新しいブロックエディタの間で視覚的な一貫性が生まれる。
あわせて、DataFormコンポーネントを基盤とした新しいブロック設定インスペクタも導入された。設定コントロールの表示が統一され、今後の拡張もしやすい基盤になる。ユーザーにとっては設定パネルの操作感が予測しやすくなる。
開発者向けAPIの変更
WordPress 7.2では開発者向けの新しいAPIも複数追加された。特にSecrets APIはプラグインやテーマのセキュリティ強化に役立つ大きな変更だ。
Secrets APIで機密情報を安全に管理
Secrets APIは、APIキーや認証トークンなどの機密情報を安全に保存するための標準化された仕組みだ。暗号化による保存、クレデンシャルのローテーション、カスタマイズ可能なストレージプロバイダをサポートする。
従来は各プラグインが独自の方法でAPIキーを保存しており、セキュリティレベルにばらつきがあった。Secrets APIの導入により、開発者は安全な保存方法を一から設計する必要がなくなる。プラグイン同士の連携も統一された方法で行えるようになるため、エコシステム全体のセキュリティ底上げが期待できる。
Abilities APIとInteractivity APIの拡張
Abilities API（アビリティAPI）は、WordPressデータへのアクセスとクエリ機能を提供する仕組みだ。7.2では新しい機能が追加され、統合・自動化・AIツールとの連携の土台が強化された。
Interactivity APIは、インタラクティブなブロックを作るための仕組みで、信頼できるHTMLの描画方法やリアクティブナビゲーションの管理が改善された。動的なブロックを開発するエンジニアにとって、より柔軟な選択肢が増える。
ランダムコンテンツリダイレクトとHTML APIの改善
指定したURLからランダムに投稿へリダイレクトする機能も追加された。ブログの「おまかせ表示」ボタンを作るなど、サイト内のコンテンツ探索を促進する用途に使える。
HTML APIは、WordPress内でHTMLを安全に処理するための仕組みだ。マークアップ処理の信頼性が向上し、カスタムブロックの表示制御も柔軟になった。ブロック開発者にとっては、より複雑なレイアウトやデザインを実装しやすくなる。
この記事のポイント
- WordPress 7.2 Beta 1は10月20日に公開され、正式版は12月8日予定
- テキストシャドウとレスポンシブデザイン制御で編集体験が拡張される
- メディアアップロードのクライアント側処理でサーバー負荷が軽減される
- 管理画面のリソース読み込み最適化でナビゲーションが高速化する
- Secrets APIにより機密情報の管理が標準化される
DApps開発の費用相場は何で決まる？見積もりの内訳と実費
DApps開発の費用相場は、1つの金額で言い切れない。
作る範囲が違えば、費用も変わるからだ。
私たちの見積もりは、ウォレットとの接続と1つの画面を作る範囲を出発点にして、契約プログラムやNFT、複数のチェーンへの対応を足していく形で決まる。
見積もりも相談も無料なので、金額を知りたければまず作りたい仕組みを伝えてほしい。
DApps開発の費用相場は、何で決まるのか
費用は、どこまで作るかで決まる。
私たちの基本の作業は、ウォレットとの接続と1つの画面を作る範囲までだ。
契約プログラムの作成や点検、NFTや独自の通貨の発行、複数のチェーンへの対応を含めるなら、規模に応じて追加の見積りになる。
基本の作業に入っているもの
基本の作業は、利用者のウォレットをサイトにつなぎ、1つの画面を動かすところまでだ。
ウォレットは、利用者が自分の暗号資産や会員証を入れておく財布のようなアプリを指す。
この画面では、ウォレットとの接続、署名の確認、送金や承認の操作ができる。
署名とは、利用者が「この操作を自分が行う」と本人の鍵で示す手続きだ。
追加の見積りになるもの
基本の作業に足していくものは、次の3系統に分かれる。
| 追加するもの | 中身 |
|---|---|
| 契約プログラム | 設計、作成、動作確認、公開、点検 |
| NFTや独自の通貨 | NFTの発行と販売、通貨の配布 |
| 複数のチェーン | 対象のチェーンを増やす対応 |
契約プログラムは、チェーン上で自動的に動くプログラムだ。
条件が満たされると、人の手を介さずに処理が進む。
投票や会員証の仕組みも、ここに載せて作る。
私たちが対象にしているのはイーサリアム系のチェーンだ。
複数の主要な暗号資産での支払いと、着金の検知にも対応している。
DApps開発の見積もりとは別に、依頼側が払う実費は何か
見積もりとは別に、依頼側が払う実費が4つある。
取引にかかる手数料（ガス代）、点検を依頼する会社への費用、サーバーの費用、ドメインの費用だ。
予算を組むときは、開発費にこの4つを加えて考えてほしい。
実費として別にかかるもの
- ガス代は、チェーン上で取引や公開を行うたびにかかる手数料
- 点検の費用は、外部の会社に契約プログラムの点検を頼むときの費用
- サーバーの費用は、画面や管理画面を動かす環境の費用
- ドメインの費用は、サイトのアドレスを持つための費用
公開の作業は、依頼側のウォレットで行ってもらう。
私たちは取り出せる鍵を受け取らないからだ。
公開の操作を自分の手で行う分、ガス代の支払いもあなたのウォレットから出ていく。
約束しないこと、引き受けられないこと
発行した通貨の値段や売れ行きは約束しない。
証券としての扱いや税金の判断は、専門の窓口に相談してもらう。
法律やチェーン側の決まりに反する依頼も引き受けられない。
作るのは仕組みであり、その仕組みが生む価値の保証ではない。
ここを最初に分けておくと、見積もりの話が早く進む。
見積もりを取る前に、何を決めておけばよいか
決めておくのは、作りたい仕組み、対象にするチェーン、手直しなら今あるコードの3つだ。
ただし、決まっていなくても相談できる。
何をチェーン上に置くべきかが見えていない段階から、私たちは話を聞いている。
新しく作るときに伝えること
作りたい仕組みは、NFTの発行、独自の通貨の配布、投票、会員証、支払いのどれに近いかを伝えてほしい。
複数に当てはまるなら、そのまま並べて構わない。
対象にするチェーンは、イーサリアム系か、まだ未定かだけで足りる。
ここが費用に響くのは、複数のチェーンへの対応が追加の見積りになるからだ。
手直しのときに伝えること
すでにあるアプリの手直しも引き受けている。
つながらなくなったウォレット接続の復旧や、契約プログラムの更新がその例だ。
この場合は、いま動いているコードや契約プログラムがあるかどうかが最初の材料になる。
手元に何があるかで、調べる範囲が決まる。
プラットフォームの手数料と、自前でDAppsを持つ違いは何か
違いは、手数料を引かれ続けるか、自分の基盤で会員と売上を持つかにある。
外部のプラットフォームでは、売れるたびに手数料が引かれ、規約が変われば事業を止められることもある。
DAppsなら、利用者のウォレットと直接つながる基盤を自分で持てる。
今の状態と、自前の基盤を比べる
| 見るところ | プラットフォーム任せ | 自前のDApps |
|---|---|---|
| 手数料 | 売れるたびに引かれる | 引かれ続ける状態から離れる |
| 規約 | 変更されると事業が止まりうる | 規約変更に左右されない |
| 会員 | 外へ持ち出せない | ウォレットで直接つながる |
囲い込まれていた会員が、自分の資産として扱えるようになる。
これが費用を判断するときの比較の相手になる。
開発費は一度の支出だが、引かれ続ける手数料は事業を続ける限り出ていく。
自前の基盤で持てる仕組み
目的に応じて、NFTの発行と販売の窓口、独自の通貨の配布、チェーン上の投票、会員証を作れる。
チェーンに刻まれた記録を取り出して見せる管理画面や、取引所側のデータとのつなぎ込みも対応範囲だ。
画面から仕組みまで一式で任せられるので、複数の窓口に発注する手間も減る。
DApps開発を頼む先は、何で見分ければよいか
見分けるところは、鍵の扱い、画面と裏側の担当、公開前の点検、実際の運用経験の4つだ。
金額を並べて比べても、ここが違えば中身は同じにならない。
私たちがこの4つをどう扱っているかを示す。
4つの違い
| 見るところ | 私たちのやり方 |
|---|---|
| 鍵の扱い | 鍵は受け取らず、権限と署名の範囲を絞る |
| 画面と裏側 | 使い勝手まで含め、ひとりで通して作る |
| 公開前の点検 | 危険な点を公開前に潰す |
| 運用経験 | 暗号資産の取引を4年間続けている |
それぞれの中身
鍵については、取引所への注文に自分のウォレットの鍵で署名を付けて送る仕組みを組み、毎日動かしている。
利用者の鍵そのものは受け取らない作りにするので、資産の管理を握られずに済む。
画面と裏側は、長年のウェブ開発の経験を活かして、ひとりで通して作る。
見た目の担当と裏側の担当に分けないので、使い勝手の食い違いが起きにくい。
点検では、再入可能な処理、権限の持ち方、数値のあふれといった観点から契約プログラムを見直す。
公開後に穴が見つかる事態を、公開前の段階で減らすためだ。
設計だけで終わらせないのも違いだ。
分散した取引の場と鍵の署名でつながる仕組みや、値動きに応じて自動で売買する仕組みを、実際に作って動かしている。
DApps開発を相談するとき、何を伝えればよいか
作りたい仕組みと、対象にしたいチェーンの種類を教えてほしい。
見積もりも相談も無料だ。
何をチェーン上に置くべきかまだ見えていない段階でも、そのまま話してもらって構わない。
手直しなら、いま動いているコードや契約プログラムがあるかどうかも知らせてほしい。
内容を受け取ってから、基本の作業と追加の見積りに分けて費用をお返しする。
公開した後も、不具合やウォレット接続の不調、契約プログラムの更新は続けて相談できる。
プラットフォームに頼らずに会員と売上を握り、規約変更に振り回されず、自分のペースで事業を伸ばしている。
そんな状態を目指す相談から始めてほしい。
依頼の窓口はWeb3アプリ・オンチェーン連携の開発のページにある。
Web3アプリ・オンチェーン連携の開発ウォレットをつないで動くWeb3向けの仕組みを、画面とチェーン上の処理まで一括で組み立てるサービスサービスの詳細を見るよくある質問
金額の目安が無いまま、予算を決められるか
見積もりが無料なので、先に作りたい範囲を伝えて金額を出してもらうのが早い。
基本の作業と追加の見積りに分けてお返しするため、どこを削れば費用が変わるかも見える。
範囲を絞って始め、後から足す進め方もできる。
チェーンの種類が決まっていなくても頼めるか
頼める。
契約プログラムの対象はイーサリアム系のチェーンなので、まずそこを前提に、目的に合う構成を一緒に考える。
複数のチェーンに広げる場合は、追加の見積りになる。
すでにあるDAppsの手直しだけでも頼めるか
頼める。
つながらなくなったウォレット接続の復旧や、契約プログラムの更新も引き受けている。
いま動いているコードがあるかどうかを最初に教えてほしい。
発行した通貨の値段や、税金の扱いも見てもらえるか
通貨の値段や売れ行きは約束していない。
証券としての扱いや税金の判断も、専門の窓口に相談してもらう。
私たちが担当するのは、仕組みを作って動かすところまでだ。
Web3サイトや独自トークンの配布システム、イーサリアムのスマートコントラクトを作ってもらう開発費用はいくらか
Web3サイトや契約プログラムなどの開発費用は、決まった金額がなく見積もりで決まる。
ウォレットとの接続と1つの画面を作る範囲を出発点にして、イーサリアム系の契約プログラムや独自トークンの配布システムなどを足していく形で金額が変わる。
この記事のポイント
- 費用は、ウォレット接続と1つの画面という基本の作業に、何を足すかで決まる
- 契約プログラム、NFTや独自の通貨、複数のチェーンは追加の見積りになる
- ガス代、点検の費用、サーバーとドメインの費用は依頼側の負担になる
- 見積もりも相談も無料で、チェーンや仕組みが未定でも話せる
- 頼む先は、鍵の扱いと公開前の点検で見分ける
Web3アプリ・オンチェーン連携の開発ウォレットをつないで動くWeb3向けの仕組みを、画面とチェーン上の処理まで一括で組み立てるサービスサービスの詳細を見る
プラットフォームの取引トラブル対策、代金の預かり方と本人確認から設計する
プラットフォームの取引トラブル対策は、代金の預かり方を先に設計するところから始まる。
利用者どうしが直接やり取りする流れのままだと、代金を払ったのに商品が届かない、商品を送ったのに支払いが来ないといった問題が起きやすい。
対策の順番は、エスクロー型の代金預かり、本人確認、通報とブロックの3つだ。
いずれも公開前に仕組みとして組み込むことで、運営側が手作業で対応する負担を減らせる。
プラットフォームの取引トラブル対策は何から始めるか
代金の受け渡しから設計するのが最短だ。
利用者どうしに任せず、取引が終わるまで運営側で預かるエスクロー型にすると、支払い済みなのに連絡が途絶える、商品を送ったのに支払いが来ない、といった問題を防げる。
取引が終わるまで代金を預かる
エスクロー型の流れは、次の順で進む。
- 利用者が代金を支払うと、運営側が取引の完了まで預かる
- 商品やサービスが届いたことを確認して、相手へ送金する
- 取引が成立しなかった場合は、代金を支払い側へ返す
取引が終わるまで代金を預かっているため、「支払ったのに何も来ない」「送ったのに支払われない」という2つの不安を同時に解消できる。
利用者にとっては、相手が確実に取引を進める理由にもなる。
手数料の差し引きと送金を自動化する
決済のたびに手数料を自動で差し引き、送金まで自動で回す仕組みにしておく。
取引の件数が増えても、振込や請求の手作業が増えないため、人を足さずに運営を回せる。
Stripe Connectのような送金サービスを使うと、出品者や提供者への振込を自動化できる。
手数料の回収を人の手で行っていると、件数が増えたときに処理しきれなくなる。
決済代行やサーバーの利用料は、プラットフォームを運営する側が実費として支払う。
本人確認と年齢確認はどこまで組み込めばよいか
本人確認と年齢確認は、公開する前に組み込む。
後から追加すると、それまでの登録者を再度確認する手間が発生する。
扱う商品や法律によって、どこまで確認するかが変わる。
どこまで確認するかは、扱う商品と法律で決まる
本人確認の方法は、運転免許証やマイナンバーカードの提出、スマートフォンでの撮影、オンラインでの確認サービスなど複数ある。
どこまで求めるかは、扱う商品やサービスによって判断する。
年齢確認が必須のサービスでは、公開前に組み込んでおく必要がある。
資金決済法などの法規制が関係する場合は、その要件を踏まえたうえで決済の方式を決める。
なりすましと業者の登録を防ぐ
本人確認を登録時に求めることで、なりすましや業者による不正な登録を防ぐ。
取引の前に確認が済んでいるため、利用者同士が安心して取引を始められる。
確認を簡易なものにすると、本物の利用者と業者を分けることが難しくなる。
扱う商品に合わせて、必要な確認を最初から設計しておくことが大切だ。
通報とブロックをどのように仕組み化するか
通報やブロックを手作業で回すと、利用者が増えるほど運営の負担が膨らむ。
通報から対応までを自動で回す仕組みをサイトに備えておく。
通報から対応までの流れを機械で回す
通報を受けたら、内容を自動で振り分け、対応の記録を残す。
問題のある利用者をブロックする機能も備えておく。
運営側は、最終的な判断だけを行えばよい状態にする。
不正防止の仕組みも重要だ。
同一人物による複数アカウントの作成や、不審な取引のパターンを機械的に検知できれば、トラブルが大きくなる前に対処できる。
利用規約でトラブル時の役割をどう決めるか
利用者間の取引でトラブルが起きたとき、プラットフォームがどこまで責任を持つかを規約で明確にしておく。
これを決めておかないと、運営側の対応がその場でぶれてしまう。
プラットフォームがどこまで責任を持つか
利用者間の取引では、プラットフォーム利用契約と利用者間契約が相互に関連している。
しかし、プラットフォームが介在する取引全体を対象とする特別法は存在しない。
トラブルが起きたときは、個別の法律を当てはめて考えることになる。
運営側がどこまで対応するかは、この構造を踏まえて規約で決める必要がある。
商品の品質や取引の結果そのものをどこまで保証するのか、返金の判断基準、通報後のアカウント停止など、運営側が介入する範囲を明記しておく。
迷ったら公的な相談窓口を使う
取引トラブルの対策について迷ったら、公的な相談窓口を利用できる。
経済産業省が委託するデジタルプラットフォーム取引相談窓口では、専門の相談員が無料でアドバイスを提供している。
経済産業省の窓口と無料相談
デジタルプラットフォーム取引相談窓口では、事業者からの相談を専門の相談員が受け付け、必要に応じて弁護士による法的なアドバイスも受けられる。
利用規約の変更や手数料の引き上げ、返品の受け入れを求められたといった相談が寄せられている。
ほかにも、日本通信販売協会（JADMA）が運営する相談窓口があり、過去の事案を踏まえた対応のアドバイスを受けられる。
プラットフォームを運営する側が直面する取引上の問題を、一人で抱え込まずに相談できる場がある。
よくある質問
決済代行やサーバーの費用は誰が負担するのか
Stripeなどの決済代行やサーバーの利用料は、プラットフォームを運営する側が支払う実費になる。
私たちが開発を請け負う場合も、外部サービスの実費は依頼側の負担になる。
エスクロー型にすると、取引の流れはどう変わるのか
利用者が支払った代金を、取引が完了するまで運営側で預かる形になる。
商品やサービスの提供が確認できたら相手へ送金し、取引が成立しなければ支払い側へ返す。
支払い済みなのに連絡が途絶える問題や、提供済みなのに支払いが来ない問題を防ぐ。
本人確認はどの段階で組み込めばよいのか
公開する前に組み込む。
後から追加すると、それまでの登録者を再度確認する手間が発生する。
扱う商品や法律に合わせて、必要な確認を最初から設計しておく。
利用者間のトラブルで、運営側が対応すべきことは何か
通報の受け付け、ブロック、代金の返金や送金の判断が主な対応になる。
どこまで介入するかは利用規約で明確にし、利用者にも提示しておく。
運営側の役割をあらかじめ決めておくことで、トラブル時の判断がぶれずに済む。
この記事のポイント
- 代金は取引の完了まで運営側で預かるエスクロー型が、トラブル対策の土台になる
- 本人確認と年齢確認は、公開する前に組み込む
- 通報とブロックは、手作業ではなく仕組みで回す
- トラブル時の役割は、利用規約で明確にしておく
- 迷ったら、経済産業省の相談窓口を利用できる
マッチングサイト・プラットフォーム開発利用者どうしをつなぎ、決済と手数料の差し引き、送金まで回るマッチングサイトを開発するサービスの詳細を見る
EAを買うか作るか迷ったら、まず売買ルールを数値化する
EAを買うか作るかで迷うとき、最初に確認すべきは、自分が描く売買ルールが数値で説明できるかどうかだ。
ルールが曖昧なままどちらを選んでも、あとで「思っていたのと違う」というズレが起きる。
判断の軸を先に固めることが近道になる。
EAを買うか作るかで迷うのはなぜか
迷いの正体は、買うか作るかの違いではない。
あなたがどんな条件で売買したいのかを、自分で説明できないことにある。
「移動平均線がクロスしたらエントリーする」では、どちらも動かない。
どの期間の移動平均線を使うのか、何本の移動平均線を組み合わせるのか、クロスの判定に価格の位置を含めるのか。
ここまで数値と言葉で書けなければ、買ったEAも作ってもらうEAも、期待どおりに動かない。
ルールを数値で書き出す
まず、エントリー条件とイグジット条件を、箇条書きにして書き出す。
ロスカットの幅、利確の目標、トレーリングストップの有無、時間帯の制限もすべて数値に落とす。
チャートに描き込んでもよい。
手書きの図でもかまわない。
同じ条件で迷うなら、自動化より先にルールの見直しを
同じ場面でも、その日の気分で入ったり入らなかったりするなら、ルール自体に自信がないということだ。
先に売買の手順を見直し、自分が検証できる形に直す。
それができたなら、買うにしても作るにしても、迷わず進める。
買う場合、中身が分からないリスクとは何か
売られているEAは、多くが中身を見せない。
結果が出ないときに原因を特定できず、改善のしようがなくなる。
購入前に、何が確認できるかを見る必要がある。
バックテストの成績が良くても、それは過去の値動きに合わせた数字である可能性がある。
リアルタイムではサインが消えるリペイントを起こす商品もある。
表示された結果が、実際の売買で再現されるとは限らない。
購入前に確認したい中身
そのEAが、どんな条件で注文を出すのかを説明した資料があるかを確認する。
エントリーとイグジットの条件、リスク管理の方法、動く時間帯と通貨ペア。
これらを質問して、答えが返ってこないなら、使う前に見直したほうがよい。
結果が出ないとき、原因を特定できるか
購入後に負けが続いたとき、設定を変えられるか、ロジックを検証できるかが分かれ目になる。
中身がブラックボックスのままでは、何を直せばよいか分からない。
購入した側に残るのは、お金の流れだけだ。
作る場合、あなたが用意するものは何か
EAを自作するために、必ずしもプログラミングの知識は必要ではない。
ただし、売買ルールを言葉と数値で伝える力は欠かせない。
これが用意できれば、自分でコードを学ぶか、開発を外注するかを選べる。
プログラムより、言葉で伝える力
開発者に作ってもらう場合、伝える情報はあなたの頭の中にしかない。
移動平均線の期間、クロスの向き、損切りと利確の位置、エントリーを避ける時間帯。
これらを箇条書きにすると、そのまま仕様書になる。
手書きのチャート画像を添えると、認識のズレが起きにくい。
外注する場合に用意するもの
外注の前に、以下をまとめておくとスムーズだ。
- 使うプラットフォームはMT4かMT5か
- エントリー条件の数値と判断の順番
- イグジット、損切り、利確の条件
- 通知が必要かどうか
- バックテストで検証したい期間
買う・作る以外に、既存のEAを改修する道があるのか
過去に作ったEAやインジケーターが手元にあるなら、買い直す必要も、ゼロから作り直す必要もない。
ソースコードが残っていれば、改修で済むことが多い。
ソースコードがあるかどうか
まず確認したいのは、.mq4や.mq5といったソースコードの有無だ。
コンパイル済みの.ex4や.ex5しか残っていない場合、中身を読み解いて修正するのは難しい。
ゼロから組み直す方が確実になる。
改修で済むなら、ゼロから作るより短い
ソースコードがあれば、数値の変更や機能追加は、一から作るより短い時間で終わる。
エントリー条件を変えたい、アラートを追加したい、時間帯の制限を入れたい。
こうした小さな変更から、大きな改修まで対応できる。
よくある質問
EAを買うより作った方がいいのはどんな人か
売買ルールが数値で決まっていて、同じ場面で同じ判断を機械にさせたい人に向く。
条件を言葉で説明できる人ほど、作った後の調整もスムーズに進む。
プログラミングができなくてもEAは作れるか
自分でコードを書くには学習が必要だが、ルールを整理して伝えられれば、開発を外注する道がある。
用意するのは、エントリーとイグジットの条件と、チャートの画像でよい。
既存のEAを直したいが.ex4しか残っていない
コンパイル済みのファイルだけでは、内部のロジックを解析して修正するのは困難だ。
ソースコードが手元にないなら、新しい条件で作り直す方が確実なことが多い。
この記事のポイント
- 買うか作るかで迷う原因は、売買ルールが曖昧なことにある
- 購入するEAは中身が見えないため、結果が出ないときに原因を特定しにくい
- 作る場合に必要なのは、プログラミングではなく条件を言葉で説明できる力
- 既存のEAはソースコードがあれば、改修で対応できる
MT4/MT5 の EA・インジケーター開発頭の中にある売買ルールを、MT4とMT5で動くEAやインジケーターのソースコードにするサービスの詳細を見る
Metaが更新版ビジネス規約の発効を11月20日に延期。クローリング条項は維持
Metaが更新版の商業規約（Commercial Terms）とセルフサービス広告規約（Self-Serve Ad Terms）の発効日を10月30日から11月20日に延期した。出版社や広告主から強い反発を受けていたクローリング条項は、今回の延期後も両方の規約に残ったままだ。
この記事では延期の内容と、問題になっているクローリング条項の詳細、EU・英国の規制当局の動き、そしてSEO・サイト運営者がいま確認すべき実務的なポイントを整理する。
Metaが規約更新を11月20日に延期、その概要
延期の対象と発効日
対象となるのは商業規約とセルフサービス広告規約の2つだ。商業規約はFacebookページの管理を含む、あらゆるビジネス用途をカバーする。米国英語版のプレビューでは、いずれも11月20日が発効日として表示されている。一方、10月25日時点では英国英語・ドイツ語・フランス語のプレビューが10月30日のままだった。
Meta広報の説明
Metaの広報担当者は延期の理由について、パートナーや関係者に何が変わり何が変わらないのかを説明する時間を確保するためだと述べている。この説明にはWebクローラーの利用方法も含まれるという。
延期しても変わらないクローリング条項の中身
延期の発表があっても、規約の中身そのものは発効日以外に変更がない。Nieman Labの報道によれば、10月23日時点でMetaは日付を除いて規約を変更していない。
このデモはクローリング条項の主要な3点を整理したものだ。特にrobots.txtへの言及がない点は、後述するようにサイト運営者にとって確認が必要な論点になる。
旧規約では既に広告主向けのクローリングが可能だった
2025年8月22日付の現行セルフサービス広告規約は、広告注文が確定したあとに、広告主のドメイン上のコンテンツを「調査とトレーニング」を含む用途でクローリングすることを既に認めている。今回の更新は、その範囲をビジネス利用全般に広げる点が焦点になっている。
EU・英国の規制当局と出版社の反応
Movement for an Open Webの申し立て
広告主と出版社を会員に持つ団体Movement for an Open Webは、欧州委員会と英国の競争・市場庁（CMA）に対し、調査が完了するまでの間、暫定措置としてMetaの新規約を差し止めるよう申し立てた。Metaはロイターに対し、この申し立てに同意しないと述べている。
規制当局のコメント
延期の発表後、CMAの広報担当者は規約を精査し、次の対応を検討しながらMetaなどと協議を続けるとコメントした。欧州委員会は申し立てを評価するとしており、10月23日にはこの延期を歓迎し、EU法（TFEU第102条とデジタル市場法を含む）への準拠をMetaに求めていく姿勢を示している。
ただし、規制当局のいずれも延期や規約調整を命じていない。Metaが自主的に延期を決めたという点は押さえておきたい。
WAN-IFRAとEANAの要請
世界新聞協会（WAN-IFRA）は、ニュース出版社向けにクローリング条項の一時停止と、規約内でrobots.txtを拘束力のあるものにすることを求めた。WAN-IFRAのCEOは「今回の延期は歓迎するが、懸念には応えていない」と述べている。欧州通信社連合（EANA）も同日、条項の完全撤廃を改めて求め、新しい期限を有意義な対話につなげたいとの期待を示した。
SEO・サイト運営者が確認すべきポイント
今回の変更は、SEO担当者やサイト運営者にも実務的な影響がある。とくにrobots.txtの設定と、規約への同意の仕組みを理解しておくことが欠かせない。
この3ステップは、規約の発効日を前にサイト運営者が実施できる最低限の確認事項だ。とくにSTEP 3の「規約とrobots.txtの関係」は、現時点で解釈が定まっていない。
規約更新後も利用を続けると自動同意になる
商業規約の条項では、Metaから通知を受け取ったあともビジネス製品を使い続けると、クローリング許可を含むすべての更新に同意したとみなされる。つまり、特に拒否の手続きを取らない限り、11月20日以降もFacebookページや広告アカウントを運用していれば、自動的に新しいクローリング条項に同意した扱いになる。
Metaのクローラーの種類を把握する
Metaは用途ごとに異なるクローラーを運用している。広告用、AIモデルトレーニング用、Meta AI検索用などだ。Metaの公式説明によれば、ウェブマスターはrobots.txtを通じてクローリングの優先動作を指定できる。ただし、新しい規約ではrobots.txtの設定が、ビジネスが同意したクローリング許可をどこまで制限できるのか明示されていない。
この点が出版社や広告主の懸念の中心にある。規約への同意という契約上の義務と、robots.txtという技術的な指示が衝突した場合、どちらが優先されるのかがはっきりしていないためだ。
この記事のポイント
- Metaが更新版商業規約とセルフサービス広告規約の発効日を10月30日から11月20日に延期した
- クローリング条項は延期後も維持されており、自動クローリングとテスト用認証情報の作成が認められている
- 規約本文にはrobots.txtへの言及がなく、技術的な制御と契約上の同意の関係が不明確だ
- EU・英国の規制当局や出版社団体は規約の変更または差し止めを求めているが、規制当局が延期を命じたわけではない
- サイト運営者は11月20日までにrobots.txtの設定と、規約更新後も使い続けると自動同意になる点を確認する必要がある
ウォレット開発の費用相場。金額が変わる条件と、含まれる作業の範囲
ウォレット開発の費用相場を、1つの数字で言い切ることはできない。
私たちの場合、費用は機能の範囲で決まり、あなたの要件を聞いたうえで見積もりを出している。
見積もりも相談も無料だ。
どの条件が金額を動かすかを先に知っておけば、相談の時に伝えることがはっきりする。
ウォレット開発の費用相場は、何で決まるのか
金額を決めるのは、どこまでの機能を入れるかだ。
私たちは相場の数字を示さず、要件を聞いてから見積もりを出す。
見積もりは無料で、相談だけでも受けている。
基本の作業に含まれる範囲
基本の作業でまかなえるのは、ひとつのチェーンで送る、受け取る、残高を見るだけの口座機能までだ。
チェーンとは、仮想通貨の取引記録が刻まれる土台のネットワークを指す。
この範囲を超える要望は、すべて追加の見積もりになる。
逆に言えば、基本の作業に何が入っているかが分かれば、あとは足し算で考えられる。
追加見積もりになる4つの項目
| 項目 | 見積もりが増える理由 |
|---|---|
| 複数人での承認方式 | 決めた数の承認が集まって動く仕組みを足す |
| 複数のチェーンへの対応 | 扱うチェーンや通貨を増やす |
| ブラウザとスマホの両方 | 2つの形で利用者に届ける |
| 外部のセキュリティ監査会社への依頼 | 第三者による点検を加える |
4つとも、規模に応じて見積もりが変わる。
最初の公開にどこまで入れるかを決めると、見積もりの幅が一気に狭まる。
迷うなら、利用者が離脱している場面に直接効く機能から並べるとよい。
ウォレット開発で、見積もりとは別に負担するものは何か
ガス代、セキュリティ監査会社の費用、アプリストアの費用は、依頼側の負担になる。
開発の見積もりには含まれないため、予算を組むときは別枠で見ておく。
- ガス代（チェーン上で取引を動かすときの手数料）
- 外部のセキュリティ監査会社に頼む場合の費用
- アプリストアに公開するための費用
鍵を預からない設計と、復元できる範囲
私たちは秘密鍵やシードフレーズを預からない。
シードフレーズとは、鍵を復元するための単語の並びだ。
紛失したときに復元できるのは、利用者の手元にある情報の範囲に限られる。
公開の前には、分かっている弱点をつぶす。
これから現れる攻撃の手口まで、すべて食い止められるとは約束していない。
法律や規約の判断は、専門の窓口へ
交換業の登録が必要かどうかなど、法律や規約に関わる判断は私たちでは行わない。
専門の窓口に相談してもらう。
開発に入る前に確認しておくと、作る機能の線引きも決めやすい。
独自ウォレットでは、何を作ってもらえるのか
自社のサービスに組み込める口座機能を、鍵の管理方法から設計して作る。
送る、受け取る、残高を見るだけでなく、鍵の守り方や承認の手続きまでが対象だ。
鍵を守るための機能
- 鍵の生成と、端末の中での暗号化保管、失ったときに元へ戻す仕組み
- 何にサインしているかを人が読める形で見せる表示
- 送る金額の上限と、承認の手続き
- 決められた数の承認が集まってはじめて動く、複数人での管理方式
複数人での管理方式は、マルチシグと呼ばれる。
1人分の鍵だけでは資産が動かないため、1つの鍵が漏れても全額を失わない。
利用者への届け方は3通りある
| 届け方 | 利用者が使う場所 |
|---|---|
| ブラウザに追加する形 | 利用者のブラウザ |
| スマートフォンのアプリ | 利用者のスマートフォン |
| 他のアプリの内部に埋め込む形 | あなたのサービスの画面の中 |
取引所やチェーン上のアプリとのつなぎ込み、仮想通貨での支払いの受け取りにも対応する。
すでにあるウォレットの修正や、脆弱性の診断だけを頼むことも可能だ。
どの形が自社に合うか分からない段階でも、そこから一緒に決められる。
独自ウォレットは、登録の離脱と鍵の事故にどう効くのか
効く場所は2つある。
1つは、別のアプリを入れる手順で起きていた登録の離脱。
もう1つは、鍵が漏れて全額を失う事故への備えだ。
外部ウォレットへの誘導をやめる
外部のウォレットへ誘導する作りだと、利用者は別のアプリを入れる手順を挟む。
その時点で離脱する人が出る。
サービスの中だけで資産を持てるようにすれば、その手順がなくなり、登録が完了しやすくなる。
取りこぼしていた登録は、そのまま成果として積み上がる。
ウォレットの開発費は、この増えた登録で回収を考える投資になる。
鍵が1つ漏れても、全額を失わない
漏れた資産は取り返しがつかない。
だから、漏れた後の対応より、漏れても全額が消えない作りを先に用意する。
秘密鍵を端末内で暗号化し、マルチシグや鍵の分割保管を組み合わせる。
署名の内容を人が読める形で見せるため、意図しない送金も防ぎやすい。
資産を預ける利用者からの信頼を保つ土台にもなる。
鍵を預かる作りや、設計だけの提案と何が違うのか
私たちは、鍵を運営側が預からない。
生成も保管も利用者の端末で行い、運営側を含め誰も中身を見られない作りにする。
| 観点 | よくある作り | 私たちの作り |
|---|---|---|
| 鍵の置き場所 | 運営側が預かる | 利用者の端末で暗号化して保管 |
| 弱点への対応 | 公開後に穴が見つかる | 公開前にコードと外部ライブラリと設定を確認 |
| 鍵の扱い | 不慣れなまま作る | 取引所への注文に自分の鍵で署名して送る仕組みを毎日運用 |
| 守備範囲 | 設計だけで終わる | 既存サイトの点検と、取引の場とつながる鍵の運用まで |
実際に鍵を動かしている会社が作る
私たちは、資産の売買を4年にわたって続けている。
分散型取引所のHyperliquidで、自分のウォレットの秘密鍵で注文に署名して送るコピートレードの仕組みを組み、毎日動かしている。
鍵を実際に動かしているから、どこで事故が起きやすいかを設計に反映できる。
見積もりを依頼するときに、何を伝えればよいか
次の3点を教えてもらえれば、見積もりに進める。
見積もりも相談も無料だ。
- 希望する見せ方（ブラウザに追加する形、スマホのアプリ、他のアプリの内部、複数人管理の形など）
- 対応したい通貨とチェーン
- 組み込み先となるサービスの概要と、見込む利用者数
どの見せ方が向いているか判断できない段階でも構わない。
利用者がアプリの中だけで資産を持てるようになり、外部への誘導で取りこぼしていた登録がそのまま増えている。
そんな状態を目標に、一緒に範囲を決めていく。
公開後の点検や既存ウォレットの修正も、続けて相談してもらえる。
相談の入り口は、鍵管理を重視した独自ウォレット開発のページにある。
鍵管理を重視した独自ウォレットの開発自社のサービスに組み込める仮想通貨用の口座機能を、鍵の管理方法から設計して作るサービスサービスの詳細を見るよくある質問
既存のウォレットの診断だけを頼めるか
頼める。
既存のウォレットの修正や、脆弱性の診断だけの依頼にも対応している。
新しく作り直すかどうかは、診断の結果を見てから決められる。
最初から複数のチェーンに対応させるべきか
主要なチェーンには最初から対応させたほうがよい。代表的なチェーンに対応していないと、利用者が増えないからだ。
時価総額の上位50位ほどの暗号資産のチェーンから入れ、利用者が増えてから広げる進め方を勧めている。複数のチェーンへの対応は追加の見積もりになる。
見込む利用者の通貨を教えてもらえれば、優先順位を一緒に考える。
ブラウザ拡張とスマホアプリの両方が必要か
両方が必要とは限らない。
両方に対応する場合は追加の見積もりになる。
利用者がどちらで登録に来ているかを見て、片方から始めるかどうかを決めるとよい。
見せ方が決まっていなくても相談できるか
できる。
サービスの概要と利用者の動き方を聞き、向いている見せ方を一緒に選ぶ。
相談は無料だ。
ブラウザ拡張機能のウォレット開発には費用がいくらかかるか
決まった値段は無く、機能の範囲を聞いたうえで見積もりを出している。
ブラウザに追加する形のウォレット開発に対応している。
相談と見積もりは無料だ。
ウォレットの作成を依頼すると費用はいくらかかるか
決まった値段は無く、あなたの要件を聞いたうえで見積もりを出している。
費用は機能の範囲で決まる。
相談や見積もりは無料だ。
この記事のポイント
- 費用は機能の範囲で決まり、金額は無料の見積もりで出す
- 基本の作業は、ひとつのチェーンで送る・受け取る・残高を見る口座機能まで
- 複数人承認、複数チェーン、ブラウザとスマホ両対応、外部点検は追加の見積もり
- ガス代、セキュリティ監査会社、アプリストアの費用は依頼側の負担
- 鍵は利用者の端末で暗号化して保管し、運営側も中身を見られない
鍵管理を重視した独自ウォレットの開発自社のサービスに組み込める仮想通貨用の口座機能を、鍵の管理方法から設計して作るサービスサービスの詳細を見る
エクセル管理の限界に気づいたら、システム化でまず考えること
あなたがエクセル管理に限界を感じたとき、最初に考えるべきは「全部をシステム化すること」ではない。
どの作業をエクセルから手放すか、どの数字を人から仕組みへ移すかを切り分けることだ。
この切り分けを先にやらないと、エクセルと同じ内容を、画面だけ変えて入力し続けることになる。
作ったシステムが現場で使われず、結局エクセルに戻る失敗も、ここから始まる。
エクセル管理の限界は、どんなときに表面化するか
エクセル管理の限界は、ある日突然来るのではない。
「1つのファイルを複数人で開き始めたとき」と「計算式がその場その場で増えていったとき」の2つが重なって、少しずつ表面化する。
1つのファイルを複数人で開き始めたとき
担当者が1人で完結しているうちは、エクセルは強い道具だ。
表の形も、計算式の場所も、その人が分かっていればいい。
ところが、同じファイルを複数人で開き、上書き保存の順番を気にしながら使う段階に入ると、道具としての強みが薄れ始める。
最後に保存した人の内容だけが残り、ほかの人の入力が消える。
編集中の数字が、集計のタイミングによって変わってしまう。
計算式が、その場その場で増えていったとき
関税の計算、送料とポイントの加算、在庫の回転率。
こうした計算をエクセルで続けるほど、セルの中の式は長く複雑になる。
一度作った式が正しいのか、誰も検証できなくなる。
シートをコピーして別の場所に貼り付けた式が古いまま残り、数字が合わない原因を探すのに時間がかかる。
計算の正しさが、作った人にしか確認できない状態が、限界の始まりだ。
| エクセルが強い場面 | エクセルに限界が出る場面 |
|---|---|
| 担当者が1人で完結する作業 | 複数人で同じファイルを開く作業 |
| 計算の内容が単純で数が少ない | 関税、送料、ポイントなど条件が多い計算 |
| 表の形を毎回自由に変えたい | 取引先や商品が増えて集計が追いつかない |
エクセルのまま回すと、どんな失敗が起きるか
エクセルのまま回すと、失敗は遅れて発覚する。
その間に、発注の数が違っていたり、支払いの予定が抜けていたりする。
目先の手間を残す分だけ、数字の信頼が先に落ちていく。
入力ミスと更新漏れが、そのまま数字になる
エクセルは、入力した値がそのまま結果に反映される。
打ち間違えた数量、貼り忘れた行、古いシートからコピーした式。
どれも画面では気づかず、あとから帳尻が合わなくなる。
人が指摘するまで、間違った数字が正しい数字として使われてしまう。
担当者にしか分からない管理になる
式の場所、シートの並び、マクロの動き。
これらが担当者の頭の中にだけあると、その人が休んだ日は業務が止まる。
別の人が代わりに見ても、どこを直せばいいか分からない。
エクセル管理の限界は、ファイルの中よりも、人にしか分からない暗黙のルールが増えることにある。
システム化の前に、やるべき切り分け
システム化を進めるとき、私たちは最初に、エクセルで回している作業を3つに切り分ける。
「人がやらなくてよい作業」「エクセルでなくてもよい作業」「システムでしかできない作業」の3つだ。
「人がやらなくてよい作業」を仕分ける
手で転記している作業、締め切りごとに同じ集計をしている作業、ファイルを開いて内容を確認するだけの作業。
こうした作業は、システムに置き換えられる余地が大きい。
ブラウザ操作の自動化や、定期的なデータ収集の仕組みを入れるだけで、人の手を離れていく。
「エクセルでなくてもよい作業」を仕分ける
エクセルでなくてもよい作業とは、データベースに向いている作業だ。
商品マスタ、取引先の一覧、受発注の履歴。
こうしたデータは、エクセルのシートに置くより、システムのデータベースに置いた方が、検索も集計も速い。
同時に複数人が触っても、上書きで消える心配がない。
「システムでしかできない作業」を残す
関税と為替の計算、在庫回転率、込み入った収支シミュレーション。
こうした数字の正確さが要る作業は、エクセルの計算式ではなく、プログラムとして実装する方が安全だ。
計算の途中を人が見たり直したりしなくても、同じ入力から同じ結果が返ってくる。
海外取引に要る多通貨の表示も、この段階で仕組みにできる。
- 人がやらなくてよい作業は、転記、集計、確認だけの作業
- エクセルでなくてもよい作業は、マスタ、一覧、履歴
- システムでしかできない作業は、関税や為替、在庫回転率などの正確な計算
システム化で変わることと、変わらないこと
システム化は、何もかも自動化することではない。
変わるのは「手でやっていた作業」で、変わらないのは「人が判断する作業」だ。
この2つを分けると、エクセルの限界を超えた後の姿が見えてくる。
入力、集計、転記の手間は減る
在庫の数を毎日入力している作業、売上を月ごとにまとめる作業、取引先ごとの一覧に転記する作業。
これらはシステムに置き換わると、入力する場所が1つになり、集計は自動で済む。
人がやらなくてよい作業が減る分、入力ミスも減る。
説明書なしで使える操作性にしておくと、現場のスタッフもエクセルに戻らずに使い続ける。
判断、商流の理解、現場への声かけは人が残す
仕入先ごとの条件をどうするか、為替が動いたときに何を優先するか、在庫が合わない原因をどう追うか。
こうした判断は、システムでは置き換えられない。
商流を理解したうえで、どう利益を上げるかを考えるのは人の仕事だ。
システム化で自動化できる部分と、人が残す部分。
この切り分けを間違えなければ、現場で使われる仕組みになる。
エクセル管理からシステム化に進む準備
システム化に向けて準備することは、大きなことではない。
むしろ、あなたがエクセルの管理で今困っていることを、作業単位で書き出すところから始まる。
困りごとを、作業単位で書き出す
「在庫の数が合わない」ではなく、「どの作業の、どのタイミングで、数字が合わなくなるか」まで書き出す。
在庫をエクセルに入力する作業で、どの列が抜けやすいか。
月次で集計するときに、どのシートのどの式が古いか。
作業単位まで落とすと、システム化する範囲が自然に決まる。
数字が合わない場所を先に特定する
システム化の前に、数字が合わない場所を先に特定しておくと、設計がぶれない。
どこで間違いが起きやすいか、どこで確認の手間が増えているか。
この場所が分かっていれば、システム化した後に「ここは自動で合うようになったか」を確かめられる。
逆に、この場所が分からないままだと、作った後も何を直せばいいか分からなくなる。
進める場合に、あらかじめ知っておくこと
システム化を進める場合、サーバー費用などの実費は依頼側の負担になる。
仕様を固めること自体に工数がかかる場合は、別にコンサルティング費用を提案することもある。
これらは、進める前に確認しておくことだ。
私たちは、エクセル管理に限界を感じた経営者から、「何をどう仕組みにすればいいか分からない」という相談を受ける。
まずは目の前の作業を一緒に切り分けて、置き換えられる部分から手をつけている。
アイデアの段階からの壁打ちにも応じる。
よくある質問
エクセル管理の限界かどうか、どう判断する？
複数人が同じファイルを開いて、上書きの順番を気にし始めたら、限界に近い。
計算式が担当者にしか分からなくなったら、判断はもっと単純だ。
その時点で、システム化を検討してもよい。
システム化すると、エクセルは完全に廃止になる？
完全に廃止しなくてよい。
人が自由に表を作り、一度きりの分析をする場面では、エクセルは便利なままだ。
システム化は、毎日または毎月繰り返す作業と、正確さが要る計算をエクセルから移すことを指す。
使いどころを分ければよい。
エクセルのままでも、工夫すれば回せる？
回せる作業と、回せない作業がある。
入力する人数が1人のまま増えず、計算も単純なら、エクセルを続けても困らない。
作業が増えて、確認のたびに人に聞くようになったら、工夫では間に合わない。
限界を感じたときが、切り分けを始める合図だ。
まず何から話せばよい？
エクセルで数字が合わなくなる場所と、その作業を毎日誰がどう回しているかを教えてほしい。
困っている作業が作業単位で分かっていると、システム化する範囲を一緒に切り分けやすい。
技術的な可否も、相談の段階で答えられる。
この記事のポイント
- エクセル管理の限界は、複数人でファイルを開き、計算式が複雑になったときに表面化する
- エクセルのまま回すと、入力ミスが数字になり、担当者にしか分からない管理になる
- システム化の前に、人、エクセル、システムの3つに作業を切り分ける
- システム化で減るのは入力、集計、転記。残るのは判断、商流、声かけ
- まずは困りごとを作業単位で書き出し、合わない数字の場所を特定する
利益直結型システム開発・ウェブアプリ開発・SaaS構築輸入やEC、金融の実務に17年取り組んできた経営者エンジニアが、現場で使われて利益を生む業務システムとSaaSを開発するサービスの詳細を見る