www.ni4.jp

MovableType.net Dashboard Utility ver0.9.3 リリースしました！

2025-12-13T00:04:00Z

ども、どもども、西山です。
この記事は、Movable Type Advent Calendar 2025の13日目の記事です。

先日、個人開発しているChromeブラウザの拡張機能「MovableType.net DashBoardUtility」の新バージョン、version 0.9.3をリリースしました。

6月にもアップデートしていましたが、今回もあると便利だなと思った機能を追加しています！

MovableType.net DashBoardUtilityとは

MovableType.net DashBoard Utilityは、Chromeブラウザのエクステンション（拡張機能）で、これをご利用いただくと、MovableType.netの管理画面をより使いやすくできる拡張機能です。
Chromeウェブストアから無料でインストールできます。

この拡張機能をChromeにインストールすると、以下のことができるようになります。

ダッシュボードから直接、ウェブサイト／ブログのテンプレート編集画面へ移動できる
ファイルマネージャ内で画像のサムネイルを表示する
ダッシュボードで「新しく〜を作る」をサイドバーに移動
プレビュー／確認のボタンをスクロール追随型に変更
記事・ウェブページ編集時のサイドバーをソータブルに変更
カスタムスクリプトおよびエディタCSSのコードをハイライト表示
編集中のブロックを強調表示（ON/OFF切替）
追加するブロックが属する親ブロックを表示
ウェブページ／記事の作成時、左右サイドバーを非表示にし本文部分を最大幅で表示 [NEW]

この記事では、今回追加した機能「フルスクリーンモード」についてご紹介します。

MT9で実装された「左サイドバーの折りたたみ機能」

今年10月22日に、Movable Type 9がリリースとなりました。

Movable Type 9 の提供を開始 | Movable Type ニュース

その際に提供されたUI改善の1つに「コンテンツ編集を行なう中央のスペースをより広く確保できるように左サイドバーを折りたたむ」という機能があります。

※ 画像はベータ版のものです

リッチテキストエディタだけじゃなくブロックエディタを使用するときも、本文エリアが狭く感じることがあると思うので、とても便利そうです！

MovableType.netの場合

ただ、この左サイドバーの折りたたみ機能はソフトウェア版のみでの提供となっていて、MovableType.netでは利用できません。

例えば、MovableType.netで複数カラムを使用するレイアウトの場合。

実際に作成したいレイアウト

編集画面では、以下のような感じになります。

3カラムブロックを利用する編集画面

カスタムブロックの作り方にも寄りますが、このように各ブロックの入力欄がエディタ部分をはみ出してしまったり、入力欄が狭くなってしまうことがあります。

また、エディタCSSを利用している場合は、こんな感じになってしまうこともあります。
以下の例はテキストと画像を横並びにするブロックですが、エディタCSSのレスポンシブ対応が適用されてそれらが上下に重なっています。

通常のMovableType.net管理画面

スマートフォンなどでの見栄えを確認しつつ入力していくにはこれも良いのですが、画面の大きなサイズを確認したい場合は、その都度「プレビュー」をしなければなりません。
エディタCSSにレスポンシブ対応部分を含めないなどの方法も取れますが、運用上、それもちょっと面倒ですよね（汗）

MovableType.netにもサイドバーを折りたたむ機能が欲しい…

先日のMTDDC Meetup TOKYO 2025で、シックス・アパート社の早瀬さんのセッションを聞いていて、以前にDashBoardUtilityで実装しようと思ったことがあったのを思い出し、左サイドバーを折りたたむ機能と同等の機能をMovableType.net DashBoardUtilityに実装することにしました。

フルスクリーンモードの実装

左サイドバーを非表示にするだけでも良かったのですが、コンテンツを作成しているときは右サイドバーもなくていいですよね。
そこでテンプレート編集画面で「フルスクリーンモードにする」という機能があったのを思い出し、それに倣うカタチにしました。

通常時の記事／ウェブページ編集画面

MovableType.net DashBoardUtilityをインストールすると、ウェブページ／記事の作成・編集画面の右上に「フルスクリーンモードにする」というボタンが追加されます。

フルスクリーンモード時の編集画面

この「フルスクリーンモードにする」をポチッとすると、左右のサイドバーが非表示になります。

大きなサイズの画面も管理画面から移動することなく確認できるので、これは便利！（自分で言います笑）
戻すときは「フルスクリーンモードを終了」をクリックすると戻ります。
これでプレビューをその都度確認する必要がなくなったので、コンテンツ作成も捗ります。

また、先ほどの3カラムブロックを利用する編集画面もこんな感じになります。

フルスクリーンモード利用時の3カラムブロック

これならどこに何を入力するのかもはっきりします。
フルスクリーンモード、便利！（もう一度自分で言います笑）

バージョン0.9.3のダウンロードはこちら

Chromeウェブストアより無償ダウンロードすることができるので、MovableType.netユーザーの方でChromeブラウザをご利用中の方は、ぜひお試しください。
（12月10日にリリースしたので、現在この拡張機能をご利用中の方は自動アップデートしていると思います）

MovableType.net Dashboard Utility

これ便利だな！と思ったら評価をつけてくれると嬉しいです！
あと、この記事下部にある「ビールをごちそうする」で100円からのカンパもお待ちしています（笑）

今回の開発パートナーたち

前回の0.8.3ではChatGPTとあれこれ相談しながら作りましたが、今回はCursorにも加わってもらいました。
ChatGPTでおおよその構造を相談して、その後、Cursorに拡張機能と管理画面のHTMLを読み込ませて作った感じですが、ChatGPT単体よりも早かったかなと思います。

いやぁ、AIってすごいですね（笑）

明日以降のMovable Type Advent Calendar 2025もお楽しみに！

“未完成を設計する” 挑戦、HalfMadeThemes 開発録

2025-11-16T05:30:00Z

ども、どもども、西山です。
気がつくと前回の記事から4ヶ月も経っていました（汗）

というのも…
実は今年5月頃から11月にかけての約半年間、それまで温めていた弊社新プロダクト「MovableType.net専用テーマ」の開発に取り組んでいたのです。

そして先日、11月10日（月）に「MovableType.net専用テーマシリーズ HalfMadeThemes」を正式リリースすることができたので、今日はその開発ストーリー的なところをご紹介していきます。

PRTIMESで配信したプレスリリースはこちら

MovableType.net専用テーマ『HalfMadeThemes TYPE: ALPHA』を正式リリース | 株式会社ジャクスタポジションのプレスリリース

弊社のリリース記事はこちら

MovableType.net専用テーマシリーズ「HalfMadeThemes」を正式リリース
その第1弾となる『TYPE: ALPHA』のリリースを記念して、2025年12月末まで本体ライセンスおよび拡張ライセンスが、30％OFFになるキャンペーンを実施中
https://www.juxtaposition.co.jp/new-arrivals/2025/11/10-093000.html

ちなみに偶然が重なった結果ですが、11月10日は私が崇拝してやまないデーモン閣下のご発生日。
しかも今年は大安という、なんともめでたい（忌まわしい？笑）日にリリースすることができました（笑）

閣下、10万63歳のご発生日、謹んでお呪い申し上げます。

HalfMadeThemesシリーズとはなにか

HalfMadeThemesシリーズは、ウェブサイトの制作時に「最小のコストと最大のパフォーマンスを、最短で実現する」ことを目指したプロダクト。
0でもなく100でもない、フルスクラッチ構築とデザインテーマ構築の間を埋める「カスタマイズを前提としたテーマ」をコンセプトにしたMovableType.net専用テーマシリーズです。

MovableType.netにインストールすることで、デザイナーやマークアップエンジニアの方々が、MTテンプレートに触れることなく柔軟なカスタマイズを実施できるのが最大のポイントで、カスタムフィールド／カスタムブロックの操作のみで、柔軟なウェブサイト構築に対応できるテーマとなっています。

HalfMadeThemesはデザインテーマの形を取っていますが、この「デザイン」は装飾を意味するそれではなく「設計」を意味しており、初期構築コストを大幅に削減しつつ、高い品質と拡張性を備えたウェブサイトを構築することを可能にするプロダクトとして開発しました。

HalfMadeThemes TYPE: ALPHA

その第1弾としてリリースしたTYPE: ALPHAは、一般企業はもちろん、医院や士業などさまざまな業種での利用を想定した汎用テーマ。
およそ5ヶ月間、こだわり抜いて開発した、シリーズ第1弾にふさわしい出来となっています。

HalfMadeThemes TYPE: ALPHAの製品概要や仕様詳細などは、こちらのデモ・ドキュメントサイトでご覧いただけます。

2025年12月31日（水）まで、リリース記念キャンペーン（ライセンス費用30%OFF）も実施していますのでお見逃しなく。

なぜ今、デザインテーマなのか？

弊社がデザインテーマの提供を始めたことをうけ、少なくない方が「なぜ今さらデザインテーマなの？」と思ったことでしょう（苦笑）
あるいはMovable Typeユーザーであればなおのこと、そのような疑問を持つことも不思議ではないとワタシも思います。

結論から先に言うと、特にMovable Typeを用いたウェブサイト制作の現場において、私は第三の選択肢が必要になったと考え、HalfMadeThemes構想をスタートしました。

Movable Type の文化的背景

そもそもMovable Typeは、リリースされてからの二十余年、その自由度の高さと堅牢なセキュリティ性能からフルスクラッチ構築が主流となっていて、数多くの中〜大規模なウェブサイト構築案件で利用されてきましたが、それゆえサッと作って公開する用途では使われにくい傾向にありました。

フルスクラッチ構築が中心となり、デザインテーマを活用した構築が限定的なものとなっていた結果、Movable Typeを用いたウェブサイト制作の現場では「デザインテーマを利用する＝簡易ウェブサイトを作る」という印象が定着してしまっていたんじゃないでしょうか。

また、2014年11月に登場したSaaS型CMS「MovableType.net」は、保守性やセキュリティ面での評価が高く、コストパフォーマンスにも優れていたことから、小〜中規模案件での導入が進みましたが、やはり制作現場では依然としてフルスクラッチ構築が一般的で、シックス・アパート社が提供する公式テーマも存在していたものの、それらを活用した構築手法はあまり利用されていなかったように思います。

他方、WordPressには美しく機能豊富なサードパーティ製のデザインテーマが数多く揃っており、フルスクラッチ構築とデザインテーマ構築のいずれもが自然と受け入れられ、WordPressを利用するウェブサイトの規模を選ばない土壌が多かったことも、数多くのウェブサイトで導入されるようになった要因の1つになったのだろうと思います。

制作現場が抱える2つの選択肢

先のようなMovable Typeにおける文化的背景もあり、少なくとも弊社においては、フルスクラッチ構築とデザインテーマ構築の間で悩むことも少なくありませんでした。

例えば創業したばかりの企業や、事業規模がまだ大きくない企業からのご相談や、あるいは一時的な情報公開を目的とするウェブサイトの相談などでは、フルスクラッチ構築におけるコスト（費用・時間）がネックになってしまうことが何度かありました。

フルスクラッチ構築は、顧客の望むものを提供しやすい反面、必要となるコストを一定以下に下げることが難しいケースも多く、「顧客の要望は叶えたいが、コストが圧倒的に見合わない」といった状況になっていました。

どうしても叶えたいと思う要望であれば、限界以上に価格を下げたり、寝る間を惜しんで構築作業を続けるということも不可能ではないかもしれませんが、その状態を長く続けることは難しいでしょう。

他方、それらの条件をクリアする手段としてデザインテーマを利用した場合、確かにウェブサイトは完成するかもしれませんが、デザインテーマの制約にあわせ、ちょっと手を加えた程度のカスタマイズとなってしまうことも少なくなく、結果的にそれが思っていた成果を生むのか、という点においては多くが疑問を残さざるを得ない状況になっていました。

そのためデザインテーマを使用する際も、「短納期・低価格だけれど高品質で拡張性の高いもの」を作ろうとすると、やはりそれなりのコストをかける必要があり、手段の1つとしてデザインテーマを選択するのが難しいものとなっていた側面もありました。

時代の変化と技術の進歩

ウェブサイト制作の現場における前提が、大きく変わりつつあります。
ここ数年で、STUDIOやWixのようなノーコード・ローコードと呼ばれるツールが普及し、特別な知識を有することなく、誰でも一定レベルのウェブサイトを構築できるようになりました。
また生成AIの普及により、デザインやコーディングにおいてもそれらを支援するツールが数多く登場し、その流れに拍車をかけたと言えるでしょう。

そのような影響もあり、比較的小規模なウェブサイトの制作現場では「短納期・低コスト」が当たり前の期待値として認識されるようになってきました。

Movable Typeを用いたウェブサイト構築のように、フルスクラッチ構築を当たり前としている現場において、これを実現するのは簡単なことではありません。
また、それらを用いた成果物についても、少なくとも今はまだ納得できる水準を満たすにはある程度のコストをかけざるを得ないというジレンマを感じている方も多いのではないでしょうか。

高い品質と構造化のニーズ

2024年4月の「障害者差別解消法」改正により、民間事業者にも「合理的配慮の提供」が義務化されたことをうけ、ウェブサイトにおいてもそのアクセシビリティ対応が強く求められるようになりました。
ウェブサイトにおけるアクセシビリティ対応については、技術的には決して難しいものではないと考えられる一方、一定以上のアクセシビリティ基準を満たす品質を確保するには相応の知識とコストが必要となります。

また、先ほどもあった生成AIの登場は、これまで主流となっていたブラウザ検索（SEO）や地図検索（MEO）、SNSからのウェブサイトへの流入に加え、生成AI検索（GEO／LLMO）によるウェブサイトへの流入を増やすことにつながり、マシンリーダブルな構造への対応（セマンティックな構造／構造化データ／Schema.org）が、これまで以上にウェブサイト構築時に求められるようになりました。

アクセシビリティ対応やマシンリーダビリティな構造への対応を踏まえると、ウェブサイトを「ちゃんと作って」「ちゃんと運営していく」ことが思っているよりも簡単ではない時代になったと言えるでしょう。

MovableType.net ブロックエディタの可能性

2020年にMovableType.netで導入され、現在はMovable Type（ソフトウェア版／クラウド版）でも利用可能となっているブロックエディタ。
私はそれを利用していく中で、ここまでに書いてきた背景と時代のニーズを合致させたプロダクトが、MovableType.netであれば提供可能ではないかと考えるようになりました。

ブロックエディタのリリース当初から、弊社ではクライアントからの依頼に基づくウェブサイト構築業務で利用していましたが、そのノウハウを蓄積していく過程で、「どのウェブサイトにも共通して利用できるブロックエディタの構築方法」のようなものが具体化してきました。

誤解を恐れずに言うのなら、ナビゲーション構造やデザインなどの違いはあれど、コンテンツを構築する構造部分（ブロックエディタ構造）に限って言えば、ほぼすべてのウェブサイトにそれほど大きな違いはないと思うようになってきたのです。

その結果、弊社では汎用的なブロックエディタ構造を準備することで、初期構築における大部分（詳細なレイアウト設計等）の時間的コストを削減し、コンセプト立案や動線設計、コンテンツの制作に時間を費やすようになり、それまでよりも質の高いウェブサイトを構築することができるようになりました。

HalfMadeThemesが目指すもの、目指すこと

2004年の創業以来、Movable Typeを使い続けてきた弊社にとって、先述した文化的背景と2つの選択肢はとても悩ましいものでした。
また、技術の進歩によるウェブサイト構築手法の変化や、時代に求められるクオリティの担保もまた、制作におけるコストバランスを考えたときに悩ましい部分がありました。

そのような中で、MovableType.net（Movable Type）のデザインテーマを用いた「短納期／低コストでありながら高い品質と拡張性を保持したウェブサイト構築手法」の確立に至ったと言えます。

私は、HalfMadeThemesを製品化して開発・提供することで、MovableType.netをプラットフォームとしてウェブサイト構築を行っている制作会社、あるいはデザイナー・マークアップエンジニアの方々、自身でウェブサイトを構築する事業者さんと、MovableType.net（Movable Type）とHalfMadeThemesを利用したウェブサイト構築のエコシステムを実現できると考えています。

HalfMadeThemesを使用して「デザインテーマにおける制約のもと短納期・低コストを実現する」のではなく、「カスタマイズを前提としつつ必要なところへコストを投資するためのツール」として、このデザインテーマを存在させたい。

そのために、ウェブサイト構築時の初期構築コスト（特に設計部分）に割いていたコストを、本来取り組むべきコンテンツの制作に充てられるだけでなく、それに付随して短納期／低コスト、高い品質と拡張性を担保するウェブサイト設計の新しい選択肢として、HalfMadeThemesを育てていきたいと考えています。

冒頭にも書いた通り、HalfMadeThemesはデザインテーマの形を取っていますが、この「デザイン」は装飾を意味するそれではなく「設計」を意味しています。
つまり、いわゆるデザインテーマではなく設計されたテーマこそが、フルスクラッチ構築でもデザインテーマ構築でもない、HalfMadeThemesの目指す「新しい第三の選択肢」であると言えます。

今後の展開・展望

第1弾としてリリースしたTYPE: ALPHAに加え、今後以下のテーマをリリース予定です。

TYPE: GAMMA
一般企業や各種施設など向けに幅広く利用可能なテーマ
TYPE: MU
スマートフォンでの閲覧に特化したレイアウトを採用したテーマ
TYPE: SIGMA
各種団体や比較的規模が大きめのサイトを想定したテーマ

また、これは少し先になる想定ですが、デザインカスタマイズを前提としたHalfMadeThemesに加え、完成されたデザインテーマ：ReadyMadeThemes構想も進めています。

ここまで読んでくれた皆さんへ

およそ6,500文字、原稿用紙にして16枚もの文章をここまで読んでくれてありがとうございます！
久々にここまで長い記事を書きましたが、書きたいことが次から次へと溢れ出てきて、正直なところ収拾がつかないのでこの辺にしておきます（苦笑）
このHalfMadeThemesが、皆さんの役に立つことを願っています。

開発に関わってくれた弊社のメンバーへ

この半年間、HalfMadeThemesのリリースという目標に向け、一緒に頑張ってくれたデザイナー、マークアップエンジニア、MTテンプレートエンジニアには本当に感謝しています。
小さなことにもすごくこだわって、およそ妥協した部分はないと言える状態で、TYPE: ALPHAをリリースできたことは非常に嬉しく、皆がいたからこそ完成できたと誇らしい気持ちになっています。あらためてありがとう。

これから関わってくれるかもしれないあなたへ

そして、HalfMadeThemesに興味を持ってくれた皆さんにもとても感謝します。
Movable Typeの周囲ではあまり聞き馴染みがないと言って良いであろうデザインテーマへの挑戦はまだ始まったばかり。
ただ、きっと近い将来、皆さんに選んでもらい、HalfMadeThemesがあって良かったと思ってもらえるプロダクトになるよう、ブラッシュアップを続けていきますので、機会があればぜひ利用してみてください。

さらに詳しく知りたい方へ

まだリリースしたばかりのHalfMadeThemes、弊社ウェブサイトでのご紹介も現状はシンプルなものになっています。
製品について詳しく知りたい、自分たちが関わるウェブサイト構築のフローがどう変わるのか知りたい、そうお考えの方はぜひ、HalfMadeThemes TYPE: ALPHAのデモ・ドキュメントサイトをご覧ください。

そして、2週間後の11月29日（土）に開催されるMTDDC Meetup TOKYO 2025では、HalfMadeThemes開発に至った経緯や目指しているところ、その設計思想までをご紹介するセッションを私が行いますので、こちらもぜひご参加ください。

MTDDC Meetup Tokyo 2025【11/29（土）開催】

私のセッションは、RoomC 14:40〜 "未完成"というもう1つの選択肢、MovableType.net専用テーマ「HalfMadeThemes」です。

こちらもどうぞお楽しみに！

Web illustrations by Storyset

【ブログ記事が販売可能】MovableType.netのブログに、投げ銭機能 codoc を導入しました！

2025-07-21T05:24:00Z

ども、どもども、西山です。

昨年の秋、Stripeユーザーコミュニティ「JP_Stripes」のイベントに参加し、codocというウェブコンテンツの販売プラットフォームを知りました。

codoc | WEBメディアのためのコンテンツ販売サービスコードク

このブログはかれこれ10年ほど続けていますが、ここ数年はウェブ技術系の話やMovableType.netのTipsなども書くようになり、月間2,500名ほどのアクティブユーザーさんに読んでもらっています。
4〜5年前に書いた記事にもアクセスしていただくことが多く、せっかくなので投げ銭システムとしてこのcodocを導入してみようと思いたち、今回実装をしてみました！

とても簡単に導入できるサービスですが、この記事ではその導入ステップを書いてみようと思います！

codocの導入ステップ

導入方法は至って簡単。

codocにアクセスして「無料で始める」からクリエイターアカウントを作成
登録メールアドレスに届くURLを利用して認証完了
サポート機能（投げ銭）のウィジェットを作成
必要に応じてデザインをカスタマイズ
貼り付けタグをブログに設置して完了

たったこれだけで投げ銭システムを導入できます。
デザインカスタマイズで凝ったことをしようと思わなければ、数十分とかからず投げ銭システムの導入が可能となります。
ちなみに私はデザインカスタマイズを行って、およそ1時間半ほどで設置完了しました。
（この記事の下部にも入っています）

codocの利用料

気になる利用料ですが、通常プランの場合は初期費用「０円」＋月額費用「０円」＋販売手数料「15％」と、とてもわかりやすい感じです。
なお、売上金（販売手数料を差し引いた金額）を出金する際は、振込手数料として300円がかかります。

私のように販売目的ではない場合、100円から投げ銭を受け取れるので投げ銭していただく方にとってもハードルは低いかなと思います。

また、投げ銭（サポート）をする方はアカウント不要なのも手軽でいいですね。

この決済画面には「コンテンツはメールで送信されます。WEBで閲覧するにはアカウントが必要です。」と書いてありますが、おそらく投げ銭に関してはメールは届かない（あるいはお礼のメールが届く）んじゃないかな…？

デザインカスタマイズについて

テーマカラーなどがいくつか用意されているほか、ボタンなどの配色を中心にCSSで細かく調整できました。

ちなみに私が追加したCSSの内容は以下のような感じです。

.codoc-support {
    background: none !important;
}
.codoc-entry .codoc-support {
    background: none !important;
    padding: 32px 0px !important;
}
.codoc-entry .codoc-support .codoc-support-title {
    color: unset !important;
    font-weight: normal !important;
    font-size: unset !important;
}
.codoc-entry .codoc-support .codoc-btn {
    max-width: 100% !important;
    background: #ffd95e !important;
    color: #ffe08a !important;
}
.codoc-support .codoc-btn:before {
    background: #4a3a12 !important;
}
.codoc-support .codoc-btn:hover {
    background: #ffe082 !important;
    color: #3a2a00 !important;
}
.codoc-support .codoc-btn:hover:before {
    background: #ffe082 !important;
}

（すべてに !important がついていますが、これがないとうまく反映されませんでした）

上記のCSS保存時、「貼り付けタグを貼り直して」とメッセージが出ますが、CSSだけの変更の場合はそれも不要のようです。
ボタン上部のテキストや、ボタンラベルなどを変更した際には貼り付けタグの中身も変わるので、再度貼り付ける必要があるという意味のようですね。

MovableType.netへの設置

このブログはMovableType.netで作っているので、以下のようにすべての記事に設置しました。

テンプレートモジュールに、codocスクリプトを貼り付けたものを用意
カスタムフィールドで「codoc投げ銭を設置」のチェックボックスを用意
記事テンプレートで、上記カスタムフィールドがONの場合にテンプレートモジュールを読み込むよう記載

最初、いくつかの記事でテストしようかと思って上記のようにしましたが、結果、初期設定をONにしてしまいました（笑）
なにがいつ読まれるかわかりませんからね（苦笑）

経過報告

今後、もし投げ銭が入ったら、こちらでその続きを書いていこうと思います。

あなたが最初の1人になってくれてもいいんですよ！
ありがとうございます！（笑）

MovableType.net Dashboard Utility ver0.8.3 リリースしました！

2025-06-09T09:16:00Z

ども、どもども、西山です。

数年前から個人開発しているMovableType.net DashBoardUtilityの新バージョンをリリースしました！
およそ3年ぶりとなるリリースです（汗）

この記事では、MovableType.net DashBoardUtilityで提供される機能について、ご紹介したいと思います。
皆さんがMovableType.netをご利用になる際の、ちょっとした手助けになれば幸いです！

MovableType.net とは

20年以上の歴史をもつCMS「Movable Type」をSaaS型CMSとして提供しているサービスです。
サーバーへのインストールはもちろん、サーバー保守やバージョンアップ作業なども不要となるため手軽に利用でき、かつMovable Typeの充実の機能や操作性を受け継ぐサービスとなっています。

MovableType.net | 安心・高速・すぐに使える！サーバー不要のSaaS型本格CMS

弊社でウェブサイトを構築する際も、そのほとんどがこのMovableType.netを利用しています。

MovableType.net DashBoardUtility とは

この拡張機能をChromeにインストールすると、以下のことができるようになります。

ダッシュボードから直接、ウェブサイト／ブログのテンプレート編集画面へ移動できる
ファイルマネージャ内で画像のサムネイルを表示する
ダッシュボードで「新しく〜を作る」をサイドバーに移動
プレビュー／確認のボタンをスクロール追随型に変更
記事・ウェブページ編集時のサイドバーをソータブルに変更
カスタムスクリプトおよびエディタCSSのコードをハイライト表示
編集中のブロックを強調表示（ON/OFF切替）
追加するブロックが属する親ブロックを表示

各機能をご紹介しますので、ご利用ください！

ダッシュボードから直接、テンプレート編集画面へ

管理画面ダッシュボードからは、ウェブサイトのテンプレート管理画面へ直接移動できます。

また、ウェブサイトのダッシュボードからは、ブログのテンプレート管理画面へ直接移動できます。

ファイルマネージャ内で画像のサムネイルを表示

ファイルマネージャ内の画像をサムネイル表示します。

なお、限定公開画像の場合、以下のように表示されます。
その場合は、一度ブラウザ内でアクセス認証を実施のうえ、リロードしてください。

ダッシュボードの「新しくサービスを追加する」をサイドバーに移動

ウェブサイト、フォーム、サーチを追加するリンクがサイドバー最上部に移動します。

プレビュー／確認のボタンをスクロール追随型に変更

記事／ウェブページの作成中、プレビューするボタンをスクロール追随型にします。
また、記事／ウェブページのステータスも追随するので、差し替え予約中の記事編集時など、うっかりミスを防げます。

記事・ウェブページ編集時のサイドバーをソータブルに変更

公開ステータスやカテゴリ、アイテムなどのパネル並び順を任意に変更できます。

並び順を変更した場合、Chromeブラウザのストレージにその情報が保存され、次回以降、別の記事／ウェブページを作成・編集する際も、並び順が保持されます。
並び順を初期値に戻したい場合は、「記事（ウェブページ）の操作」にある「パネル順をリセット」を利用してください。

なお、パネル順を初期状態にする際は、管理画面のリロード（再読み込み）が入るので注意してください。

カスタムスクリプトおよびエディタCSSのコードをハイライト表示

カスタムスクリプトやエディタCSSを編集する際、そのコードをハイライト表示します。

編集中のブロックを強調表示

現在編集しているブロックをアウトラインとバルーンで強調表示します。
入れ子構造になっているブロックなどを利用している際に便利です。

なお、この強調表示は「表示／非表示」と「表示時間」を設定でコントロールできます。
拡張機能のアイコンをクリックして、オプション設定をご利用ください。
（初期設定は以下のとおりとなっています）

追加するブロックが属する親ブロックを表示

ブロックを入れ子構造で作成する場合、以下のように「＋ブロックを追加」が多重表示され、どこに追加すべきか迷うことがあります。

MovableType.net DashBoardUtilityを利用すると、この「＋ブロックを追加」に、そのボタンが属するブロックの名称を表示することができるようになります。

特に記事編集時などは、先ほどの強調表示（アウトラインとバルーン）と併用することで、現在どのブロックを編集しているかが一目瞭然となります。

お気づきの点やご要望などお聞かせください

約3年ぶりとなるアップデートで、上記を提供する拡張機能となりました。
今回追加となった「編集中のブロックを強調表示」と「追加するブロックが属する親ブロックを表示」は、およそ2年半前に着手していたのですが、私のスキル不足から完成に至っていませんでした（汗）

MovableType.netのブロックエディタで「ブロックを追加」する場所をわかりやすくする | www.ni4.jp

今回、なんとか実装できて良かったです！

また、この間の小さなアップデート（v7.1）では、MovableType.net側で実装された以下の機能について、提供を止めております。

各ウェブサイト／フォームのパネルが開閉式になり、高さが極端に狭められる
新しくウェブサイトを作るためのリンクが最上部へ移動する
新しく作成したウェブサイトが最上部に追加される
ウェブサイトの順序を任意に変えられる
パネルの開閉、ウェブサイトの順序をCookieに保存できる（1年/変更の都度延長）

今回、拡張機能に実装されたものも、今後は提供停止となるものが出るかと思いますが、順次アップデートを行う予定でおりますので、お気づきの点などがございました際は、弊社お問い合わせフォームよりご連絡願います。
「こんな機能あったらいいな」などのお声もいただけると嬉しいです。

また、今回の機能実装にあたっては、ChatGPTを利用して作成している部分が多々あります。
私自身がJavaScriptを得意としているわけではないためこのような形になっておりますが、その部分でもお気づきの点などがございました際はご連絡ください。

MovableType.netをご利用中の皆さん、ぜひDashBoardUtilityもご利用ください！

みんな快適！オンライン参加者に優しいハイブリッドミーティングのコツ

2025-01-18T07:51:00Z

Online illustrations by Storyset

ども、どもども。

リモートワークが増えたコロナ禍を経て、オンラインミーティングも一般的になりましたが、今はオフィスに出勤するワークスタイルに戻った企業・団体も多く、会議室などに複数名が集まって参加する「オフライン側」と、リモートワークなどで個別に参加する「オンライン側」が一緒にミーティングを開催する「ハイブリッドミーティング」も多く見かけるようになりました。

一見便利に思えるハイブリッドミーティングですが、リモートワークなどで参加する側では「会議室側の表情が見えない」「声が聞こえづらい」といった不満を感じることも少なくありません。

この記事では、そんな「一対多」の課題を解消し、お互いにとって快適なミーティング環境を構築する方法について、私見を交え書いていきたいと思います。

よくあるハイブリッド型「一対多」のデメリット

会議室などに複数名が集まり、リモートでつなぐ相手（1人または複数人）とミーティングを開催するとき、このようなカタチになることはないでしょうか。

会議室などに大型のモニタを用意して1台のパソコンでミーティング画面を共有し、会議室側の参加者が全員映るような広角のウェブカメラを用意したり、全員が映るようにカメラを離れた位置に設置するようなケースです。
ハイブリッドミーティングの開催方法を紹介する記事などでも、一対多で実施する場合にこれを紹介することが多い印象です。

一見すると特に問題ないように見えますが、この状態をリモートワーク側から見るとこのようなカタチになってしまい、いくつかの不都合が出てきます。

会議室側参加者の表情がよく見えない

会議室側で1台のカメラを共有すると、参加者が全員映っていたとしても、その表情が判別できない状態になり、コミュニケーションが一方的になってしまうことが多いように感じます。

オンラインミーティングに限りませんが、話し合いの場ではその表情や視線も重要な情報源の1つで、自分の発した内容について相手がどのように受け取っているのか（納得したのか疑問が残っているのか）など、その理解度や感情を汲み取る手がかりとなり、それが見えると会話をスムーズに進めることができます。
会議室側の参加者からはリモートワーク側の表情がよく見えるので気にならないかもしれませんが、リモートワーク側にとってはかなりストレスが溜まる状況と言えるでしょう。

オンラインミーティングの実施方法などを解説する記事で「カメラは常にONにしましょう」と見かけますが、これはONにしていれば良いということではなく、相手に自分の表情を伝えることがコミュニケーションのうえで大切であることを指しているように思います。

会議室側の発言がよく聞こえない

会議室側のマイクが1台のPCで賄われている場合、少し離れた参加者の声が聞き取りにくいことがあります。
会議室で一緒にいると気が付きにくいですが、リモートワーク側にはかなり大きな影響があります。

電話などでも電波状況や周囲の雑音などで声が聞き取りにくかったりするとストレスが溜まったりしますが、それとまったく同じ状況と言えます。
オンラインミーティングの実施方法を解説する記事では「通信環境の良い場所を選ぶ」といったことが書いてありますが、通信環境が良い状況でも、そもそも音量が小さいなどの場合は意味がありません。

誰に向けての発言なのかがわかりにくい

ミーティングが盛り上がってくると次々と発言が出てきたりしますが、会議室側がそのような状況になるとリモートワーク側では、その発言が誰に向けてのものなのかがわかりにくかったり、会議室側で複数の方々が話をしだすと、そもそもなにを話しているのか聞き取れない状況になりがちです。

会議室の中だけでミーティングが行われているような雰囲気になってしまい、リモートワークの参加者が置いてけぼりな状況になってしまうことも少なくありません。

一対多のデメリットをなくす方法

では、これらのデメリットを解消するにはどのようにハイブリッドミーティングを実施するのが良いのか。
私が一番望ましいと思う環境セッティングは以下のようなカタチです。

1人1台のパソコン（カメラ）を使用する

同じ会議室やオフィスの中であっても、1人1台でオンラインミーティングに参加するのがベストと言えます。
パソコンに外部接続するウェブカメラの中には、自動的に声を出している人にズームアップする機能を持ったものもあるようですが、そのようなものを用意しなくてもこれで解決できます。

ただ、これを実際にやると以下のような問題が起きます。

会議室参加者の間でハウリングが発生してしまう
会議室での発言と、オンラインミーティングからの音声に遅延が出て、会議室側で会話がわかりにくくなる

ハウリングの問題はヘッドセットなどを使うことで解消できますが、それでも「遅れて聞こえてくるオンラインミーティングの音声」の問題は残ってしまいます。
会議室は使わずに、自分のデスク等から参加すると良さそうにも思いますが、それができないケースもあることを考えると、会議室側では以下のようなセッティングにするのがベターとなります。

会議用のスピーカーフォンを使用する

先ほどの1人1台のパソコンを使用している状態で、以下のようにセッティングしてみましょう。

全員がそれぞれのパソコンでカメラをONにする
会議室側参加者の1名がパソコンをスピーカーフォンをつなげ、会議室の中央付近に置く
スピーカーフォンがつながったパソコン以外は、マイクを消音にする

最近のスピーカーフォンであれば、その多くが360度の集音機能を持っているので、よほど離れていない限りはこれで問題なく音声も届くと思います。

お値段も数千円から1〜2万円くらいで購入できるのでお勧めです。

Anker PowerConf S3 スピーカーフォン会議用マイク
https://amzn.to/4fYNGtL

会議室側でこのようにセッティングすることで、ハウリングの問題や音声の遅延などを解消することができ、リモートワーク側のパソコンにも各参加者が表示され、それぞれの表情もわかるようになります。

1つ気をつけたいポイントがあるとするなら、上記のとおり会議室側では1人だけがマイクONの状態なので、会議室側が発言している最中、それが誰の声なのか画面上ではわからないことになります。（マイクONの人が話しているように表示される）
スピーカービュー（話している人の顔が大きく表示される）を使用していない限り、これまでの経験上、あまり困ることはないように思いますが、この点だけはお互いが理解しておく必要がありそうです。

そのほかのオンラインミーティングおけるポイント

以下はハイブリッドミーティングに限った話ではありませんが、これらにも注意するとよりミーティングがスムーズで効率的になるように思います。

画面共有もいいけれど、事前に資料を配布しておくとよりベター

オンラインミーティングツールを使って画面共有することも多いと思いますが、その場でいきなり資料を見ながら説明をするのではなく、事前に参加者に配布しておくと資料への理解度も高まり、質問や意見なども準備しやすいのでミーティングの質が高まります。

カメラのアングルは、できるだけ「目線と平行」にしよう

ノートパソコンなどに付属しているカメラをそのまま使用すると、どうしても下アングルからの映像になってしまいます。
そのような角度だと相手側を見下ろすような威圧的な目線になってしまうこともあるので、できるだけカメラと目線は平行のアングルにすると良いでしょう。
ノートパソコン用のスタンドを使用するのはもちろん、ノートパソコンの画面部分を垂直になるようにする（パソコンの下に本などを置く）だけでも違うと思います。

あと、光の当たり方によっては、下からのアングルだと老けて見えることもあるので注意が必要です（笑）

あれこれそれなどの指示代名詞に気をつけよう

画面共有されて見ている画面（資料）や、自分のマウスポインタの位置は自分にしか見えていません。
ついつい「あれ」とか「これ」と言ってしまいがちですが、少し面倒でも相手側がすぐに判断できるような言葉を使うようにすると良いでしょう。

私もよく「ここなんだけどさ」と自分だけの目線で言ってしまいがちなので、普段から気にしています…（汗）

相手の話を遮らないように注意しよう

ハイブリッドミーティングで起こりがちですが、生の声とオンラインから聞こえる声には遅延が発生しやすいので、相手が話しているときは最後まで聞き、少し間をあけてゆっくり目に話し出すと良いです。
ヒートアップしてくると会話を重ねてしまうこともありますが、オンライン上で会話が重なると、オフラインのそれよりも判別しにくいものなので、意識的にタイミングを図るとスムーズな会話をしやすくなります。

ミーティングも会話なので、相手を尊重しつつ聞く姿勢が大切ですね。

ミーティングで大切なのは発言内容だけではない

少し横道にそれてしまいましたが、オンラインミーティングではその発言内容だけでなく、表情や仕草といった非言語的な情報も重要なコミュニケーションの1つとなります。
お互いの表情やリアクションを見て、発言に対する理解度や感情を汲み取ることができるのが、オンラインミーティングの良いところ。

電話やメールにはない良さがあるので、それらを効率よく伝えスムーズなコミュニケーションを取るためにもウェブカメラとマイクの使い方をちょっと工夫してみると良さそうです。

オフィスへの出勤とリモートワークのハイブリッドなカタチが定着しつつある今、一対多のオンラインミーティングの機会も増えると思いますが、ちょっと配慮するだけでミーティングの質が向上すると思いますので、ぜひ試してみてくださいね。

これでもう記事URLが重複することはない！？MovableType.netのアーカイブマッピング機能を発見

2024-12-15T00:30:00Z

ども、どもども。
ジャクスタポジション　西山です。

この記事は、Movable Type Advent Calendar 2024の15日目の記事です。
今回、これで3つ目の投稿となります（1人でたくさん書いてすみません汗）

今日はMovableType.netのアーカイブマッピングで気がついたことがあったので、それを書いていこうと思います。
（知らなかったのが私だけだったら恥ずかしいけれど、知らなかったんだもの！笑）

Movable Typeのアーカイブマッピング

さて、Movable Typeで「いわゆるブログ記事」を作成する際、どんなアーカイブマッピングを利用していますか？

アーカイブマッピングの設定 | CMSプラットフォーム Movable Type ドキュメントサイト

アーカイブマッピングというのは、例えば記事を作成した際に、どのようなURLで記事が公開されるのかを設定するもの（記事以外にも存在する）で、事前に用意されたアーカイブマッピング以外に任意に定義する（カスタムする）こともできます。

アーカイブマッピングを作成する際に「カスタム」で任意の定義が可能

また、アーカイブマッピングで利用できる定義を組み合わせることで比較的自由にパス（URL）を作ることも可能になっています。

アーカイブマッピングで利用するアーカイブファイル名の定義 | CMSプラットフォーム Movable Type ドキュメントサイト

さらにこのアーカイブマッピングには一部のMTタグを使用することもできるので、条件にあわせて出力されるパスを分岐する…なんてこともできたりします。（ご利用は計画的に）

アーカイブマッピングでテンプレートタグを使えますか - Movable Type Q&A | CMSプラットフォーム Movable Type ドキュメントサイト

というわけで、ブログ記事のアーカイブマッピングにはいろいろなやり方があるのですが、仮に同じURLで記事が公開されてしまうと、後から公開された記事が先に公開された記事を上書きしてしまうので、弊社ではそのURLが重複してしまわないように、記事のエントリーID（記事固有のID）や、記事が公開された年月日と時分秒を使っています。

MovableType.netのアーカイブマッピング設定例

MovableType.netでは、記事のアーカイブマッピングを%y/%m/%d-%h%n%s.html（年/月/日-時分秒.html）とすることが多いです。
エントリーIDの使用も考えたのですが、MovableType.netのエントリーIDって長いのですよね…（汗）
それがだめというより、どういう意味なのかわからないのでちょっと落ち着かない感じです。

設定内容	アーカイブパスの例	出力例
エントリーIDを利用	%y/%m/%E.html	https://www.ni4.jp/2024/12/2832285.html
年月日時分秒を利用	%y/%m/%d-%h%n%s.html	https://www.ni4.jp/2024/12/04-093000.html

ちなみに、MovableType.netではアーカイブマッピングの定義にMTタグを使用することはできません。

MovableType.netの予約投稿では「秒」が出力されない

ただ、年月日と時分秒で設定していて気がついたのですが、MovableType.netで「予約投稿」を行う際は、アーカイブマッピングに秒（%s）を入れていてもそれが出力されることはなく決まって「00」となってしまうのです。

以下は2024年12月14日14時28分15秒を設定して予約投稿をした場合の例です。

秒まで指定して「予約投稿」を実施

出力されるパーマリンク（記事のURL）がこちら

秒の部分が「00」になってしまう

上記のように、秒を入力したとしてもパーマリンク（記事のURL）の秒の部分は「00」になってしまいます。
ソフトウェア版などでは問題なく秒を指定できていたので盲点でした。

MovableType.netの予約投稿を使うと重複するURLができてしまう？

もし仮に同じ日時に複数の記事を予約投稿（公開）したい場合、ソフトウェア版では「秒」を変えることで対応できていたのですが、MovableType.netの場合はそれができない…？と気が付きました。（秒という考え方も万全ではないのですけどね）

レアなケースかもですが、たまたま現在構築中のウェブサイトではその可能性が出てくることが予想されたので、実際にテストしてみることに。

MovableType.netで同じURLとなる記事を予約投稿してみる

というわけで、実際に同じURLとなる記事を予約投稿してみた結果がこちらです。

同じ時刻に予約投稿した場合のパーマリンク

あとから作成した記事のファイル名末尾に「-1」という番号が自動付与されました。
なお、更に同じURLとなる記事を作成した場合は「-2」が付き、以降それが続くようです。

ちなみにこれは、%y/%m/%-f（yyyy/mm/entry-basename.html）とした場合も同じでした。

さらに…%y/%m/index.html とした場合でもフォルダ名に連番が付くことを確認できました。

フォルダで終わる場合も連番が付く

これは知らなかった…！
（私だけ？汗）

結論：MovableType.netでは同じURLで記事を上書きしてしまうことはない

以上のことから、MovableType.netではアーカイブマッピングの設定によって、仮に同じURLとなってしまうケースであっても、自動的に連番を付けてそれを回避してくれることがわかりました。
これはソフトウェア版にはない機能だと思います。

ただ、最初の記事には連番がなく2つ目の記事に「-1」と付くのは、個人的には違和感がありますが…、最初の記事が公開になった時点で同じURLの記事は存在しないので、これはどうしようもなさそうでうね（-2からスタートとかのほうが気持ち良いかも？）

最初は秒が指定できないことがちょっと不便かもと思いましたが、記事中に「秒」を掲載することはほぼ無いし、重複するURLが出てこないのであれば、これはこれで問題ないかなと感じました。

が…個人的にはファイル名に秒を入れられるほうが良いかな（笑）

以上、MovableType.netのアーカイブマッピングで発見したことでした！

この記事は、Movable Type Advent Calendar 2024の15日目の記事です。
明日は hanami さんの記事が公開予定となっておりますので、お楽しみに！

Movable Type 3.2 からMovableType.netへ

2024-12-10T00:30:00Z

ども、どもども。
ジャクスタポジション　西山です。

この記事は、Movable Type Advent Calendar 2024 の10日目の記事です。

弊社でMovable Typeを使い続けて20年。
Movable Typeを採用してウェブサイトを構築した中で現存する最古の1つ、そのウェブサイトが今まさにリニューアルを迎えようとしています。
現在使用されているのは…Movable Type version 3.2！
諸般の事情があり長らくこの状況が続きましたが、やっとこの時を迎えようとしています。

そして18年ぶりのリニューアルにあたって、弊社が得意としているMovableType.netを採用することに。
公開はまだ少し先ですが、今日はそのMovable Type version 3.2 からMovableType.netへ、950件ほどの記事を移行した手順を書いていこうと思います。

正直なところあまり需要はない…というか、あっても困る気がしますが、version3.2のころを知っている方は、懐かしむように読んでもらえたらと思います（笑）

懐かしいMovable Type 3.2の管理画面

今日現在まだ利用されているので、弊社ではたまに見かけていた管理画面ではありますが、こう見ると時代を感じずにはいられませんね…
そして今も、管理画面にはMTクラウドのことや、2024年から2025年にかけてのサポートのことなど、最新ニュースが配信されています。

20年ほど前のCMSが現役で動いているのって結構すごいことですよね…

利用しているプラグインはこちら

Better File Uploaderとかめちゃくちゃ懐かしい（笑）

Movable Type 3.2 からの記事エクスポート

懐かしんでばかりもいられないので、早速記事データの移行へ進みます。
ふと思ったのですが、MT3.2のころには「ウェブページ」という存在がなかったのですよね…、今では普通に使っていますが、当時はFTPソフトと併用する感じだったのだなぁと思いました。

記事の移行については、まずは普通に「書き出し（エクスポート）」から進めることにしました。
このブログでは562件ほどの記事があったのですが、MT3.2は動作がめちゃくちゃ早いです（笑）

一瞬でMovable Type形式のテキストファイルを取り出せました。

インポートと改行問題の解消

先ほど出力したテキストファイルをMovableType.netへインポートします。

インポート - マニュアル | MovableType.net

上記手順のとおり、アイテムをインポートしつつ進めますが、ここで1つ目の問題が発生。
先ほどのテキストファイルでインポートすると、記事の中で「本文の改行」が反映されていませんでした。
調べてみると、テキストデータに記載された以下の点が問題だったようです。

CONVERT BREAKS: __default__

CONVERT BREAKSは改行に関するフラグなのですが、ここがdefaultとなっていました。
MT3.2では、管理画面内でこれを設定できる箇所がなかったように思うので、もしかしたらmt-configなどで設定できるのかもですが、今回はテキストファイル内で「CONVERT BREAKS: 1」と置換して対応することにしました。

Movable Type のブログ記事インポートフォーマット | CMSプラットフォーム Movable Type ドキュメントサイト

そして改めてインポートを実施。
ところがそれでも改行は反映されません。

原因を調べる時間もなかったので、今回は「インデックス・テンプレート」でインポート用のファイルを作成することにしました。
これなら本文中にHTMLタグが入るはずと考え、先ほどのドキュメントにも記載されているテンプレートを用いて、以下のように出力することに。

<MTEntries lastn="99999">AUTHOR: <$MTEntryAuthor$>
TITLE: <$MTEntryTitle$>
BASENAME: <$MTEntryBasename$>
STATUS: <$MTEntryStatus$>
ALLOW COMMENTS: <$MTEntryFlag flag="allow_comments"$>
CONVERT BREAKS: <$MTEntryFlag flag="convert_breaks"$>
ALLOW PINGS: <$MTEntryFlag flag="allow_pings"$>
<MTIfNonEmpty tag="MTEntryCategory">
PRIMARY CATEGORY: <$MTEntryCategory$></MTIfNonEmpty>
<MTEntryCategories>
CATEGORY: <$MTCategoryLabel$>
</MTEntryCategories>
DATE: <$MTEntryDate format="%m/%d/%Y %I:%M:%S %p"$>
-----
BODY:
<$MTEntryBody$>
-----
EXTENDED BODY:
<$MTEntryMore$>
-----
EXCERPT:

-----
KEYWORDS:

-----


--------
</MTEntries>

そのうえで、先ほどの改行設定を「CONVERT BREAKS: 0」へ置換してインポートを実施（今思えば出力時に固定しても良かった）
すると、意図したとおり改行が反映されたままインポートすることができました。

タグ閉じ忘れ問題を解消

このインポート作業をしている時に、テンプレート実装をしていた他のメンバーから「記事の中にaタグの閉じ忘れがあるみたいでレイアウト崩れが発生している」と連絡が。

確認してみると、複数の場所でaタグの閉じ忘れを確認できました。
MT3.2（Better File Uploaderかも）では、最後にHTMLを表示してそれをコピーして本文中に貼り付けることができるのですが、もしかするとその際にコピーミスなどがあったのかもしれません…。

1つ1つ確認するのは流石に手間だったので、ChatGPTさんに相談して正規表現による検索と置換を教えてもらい、なんとか洗い出しを終えました。
aタグ以外にも閉じ忘れがあると困るので、最終的に正規表現ですべてのHTMLタグをチェックすることに。

画像ポップアップ表示の問題を解消

あらためてインポート作業を実施して、記事とアイテム（画像等）が正常にインポートできたところで表示確認をしてみると、今度は一部の画像で以下のように画像がポップアップウィンドウで表示するようになっていることを見つけました。

<a href="http://www.example.com/DSC00705.php" onclick="window.open('http://www.example.com/DSC00705.php','popup','width=400,height=300,scrollbars=no,resizable=no,toolbar=no,directories=no,location=no,menubar=no,status=no,left=0,top=0'); return false">
  <img src="http://www.example.com/DSC00705-thumb.JPG" width="180" height="135" alt="http://www.example.com/DSC00705-thumb.JPG" />
</a>

これ、Better File Uploaderの機能でしたっけね…（拡張子がPHPになっているのはたぶん個人的な設定の問題）
今となってはこのような対応をする必要もないかと思うし、そもそもMovableType.netではPHPなどを利用できないので、この部分をまるっと削除することにしました。

再度、ChatGPTさんに相談して正規表現による検索と置換を実施、imgタグ部分だけを残してこれらを一括除去することに成功。
ちょっとだけコードの構成が違うところなどがあったので、何度か繰り返してこれらをきれいにしていきました。

日本語ファイル名のエンコード問題を解消

画像のポップアップ部分を削除することに成功したあと、念のため、他にPHPへリンクしている部分などが無いか正規表現でチェック。
存在した場合はそのリンクタグを除去するように進めました。

…が、ここで以下のようなリンクが残ってしまうことが判明。

<a href="http://www.example.com/%A3%D6%8E%BD%8E%B8.php" >
  <img src="http://www.example.com/%A3%D6%8E%BD%8E%B8-thumb.JPG" width="80" height="60" alt="http://www.example.com/%A3%D6%8E%BD%8E%B8-thumb.JPG" />
</a>

日本語ファイル名のまま画像などをアップロードした際に、エンコードされてしまったファイル名が検索対象から漏れてしまったようです。
この部分もChatGPTさんに相談して、画像タグだけを残すことに成功。

エンコードされたアイテムがインポートができていない問題を解消

あらためてインポートした結果を確認してみると、旧サーバー上でエンコードされたファイル名のアイテムが、MovableType.netにインポートできていないことが判明。

この辺りまで来ると、「MT3.2の管理画面、懐かしいー」とか言っている余裕がなくなってきました…
思い起こせば、こんなことがたくさんあって疲れたので、弊社でその後、ImageUploadUtilityをリリースすることになったのでした（笑）

ImageUploadUtility - Movable Type用画像アップロード機能補助プラグイン

ここはもう手作業でやるしか無い…と判断して、インポートするテキストファイルから、1つ1つエンコードされた部分を探して、旧サーバー内のファイルを参照、インポートできていないものは手動でバックアップしてMovableType.netへアップロードする…という原始的な作業に入りました（汗）

結果的には40個ほどのファイルがインポートできていなかったのですが、これもなんとかクリア。

旧サーバー内にも見当たらないファイルについては、画像部分を削除するかあるいは「File Not Found」という画像を用意して代替することに。
ここは今後、クライアントさんとも相談が必要ですが…、その多くが数年前のものだったりするので、ひとまずこれで作業を終えることに。
40個くらいなので、後日、旧サーバーから画像をダウンロードしてリネームのうえでリンクを再設定することになるかもな…

インポートした記事で「最古の記事」がインポートされない問題を解消

これですべての作業が終わったー
と思ったのですが、インポートした記事の数を確認してみると、いくつか足りない（数字が合わない）ことに気が付きました。

今回のインポートファイルはテンプレートとして書き出したのですが、調べている中で、Movable Typeはドラフト（下書き）の記事を出力しないことを思い出して、それを数えてみるとおおよそ数字が合うことが判明。

小粋空間さんのプラグイン「AllEntries」を使用するかとも考えたのですが、残念ながら現在はNotFoundだったので今回は断念。
ドラフト状態の記事は直近のものを除き、インポートしないことに。

ただ、それでも3記事分だけ合わないことがわかりました。
今回は3つのブログから記事インポートを実施していたのですが、確認してみると、それぞれのブログ記事で最古の1件（最初の1件）だけがインポートできていないことが判明。

MT3.2から出力したファイルには記載されているのですが、なぜかMovableType.netでそれをインポートしていないようでした。
おそらく出力したMovable Type形式のテキストデータに不備が合ったのだと思いますが…ここまで来ると

「たった3件なら手動で登録してしまえｗ」

という判断に（苦笑）
こうして無事に、対象となった950件ほどの記事移行作業は完了したのでした。

古いMovable Typeからの記事移行を終えて

正直なところ、思っていたよりも疲れました（苦笑）

HTMLに小さいサイズで埋め込まれた画像をポップアップウィンドウで原寸表示するとか、Movable Typeがどうこうというよりも、確かに当時はそんな対応とかしてましたよね…
インターネット回線が今みたいに高速・大容量じゃなかったので、このような対応をみんなが考えていたと思います。

あと、日本語ファイル名ね（苦笑）

サーバーを移設する際などにFTPソフトでダウンロードしても、移設先のサーバーにそのままアップしただけじゃリンクが切れちゃうとか、なんか色々あったのを思い出しました。
いやー、そう考えると我ながらImageUploadUtilityの「マルチバイトリネーム機能（日本語ファイル名を強制的に半角英数字に変換する機能）」って、良いですよね（笑）

あと、ChatGPTさんをはじめとするAIさんたちってすごくありがたいなと思いました。
今回、その助けがなかったら、正規表現とかでめちゃくちゃ苦労していたと思います…（汗）
ありがとう。

というわけで、18年分の950件の記事移行も無事に完了。
今後はMovableType.netで運営されるので、今回のような作業はもう発生しないだろうし今回やれて良かったかな、と。

さすがにMovable Type 3.2を現在も利用しているケースはそうそう無いと思いますが、もし似たような状況があった時に、この記事が参考になれば幸いです。

こちらの記事は以上です！
このウェブサイトがリニューアル公開されたら、またお知らせしますねー
お疲れさまでした！（笑）

この記事は、Movable Type Advent Calendar 2024の10日目の記事です。
明日は @pot_au_feu さんの記事が公開予定となっておりますので、お楽しみに！

「DEEP DIVING SESSION - Movable Typeの未来と可能性を深く探る」を開催しました！

2024-12-04T00:30:00Z

ども、どもども。
ジャクスタポジション　西山です。

この記事は、Movable Type Advent Calendar 2024 の4日目の記事です。

去る2024年11月23日（土）、東京ガーデンテラス紀尾井町にあるLINEヤフーさんの会場で、MTDDC Meetup TOKYO 2024が開催されました。
この日、私は実行委員長としてイベント運営に関わっており、例年のようなセッションは担当していなかったのですが、その代わりに「MTDDC Meetup 特別企画 DEEP DIVING SESSION」のモデレーター・ファシリテーターとして、トークセッションを開かせてもらいました。

MTDDC Meetup Tokyo 2024【11/23（土）開催】

この記事では、そのトークセッションについて当日の様子などをまとめたいと思います。

トークセッションの概要

DEEP DIVING SESSION - Movable Typeの未来と可能性を深く探る
Movable Typeユーザーのための特別トークセッションを開催します！
シックス・アパート社のCEO & CTOである平田大治さん、製品企画シニアマネジャーの早瀬将一さんをお招きし、Movable Typeが目指す未来について語り合います。
ユーザーから寄せられた質問や疑問に答えつつ、今後の開発方針や方向性についてリアルな声をお届け。
また、最近話題のノーコードCMSや他のウェブプラットフォームと比較しながら、Movable Typeがどのように進化し続けているか、その価値を改めて考えます。
さらに、Movable Typeユーザーコミュニティの価値と成長に対するシックス・アパート社のビジョンも徹底討論。
Movable Typeの新たな可能性を知りたい方、ユーザー同士のつながりを大切にしている方は、ぜひご参加ください！

https://mtddc2024.mt-tokyo.net/speaker/lodge04.html

イベント公式サイトにもあるとおり、当日はシックス・アパート社の平田さんと早瀬さんをお招きし、事前に集めておいたトークテーマを中心に私から質問を投げかけ、お二方に回答してもらうカタチで進みました。

また、ゲストとしてMTAppjQueryの提供元であるbit partの柳谷真志さん、奥脇知宏さんも登場。
お二人とも海外在住（シンガポールとニュージーランド）なので、会場とZoomでつなぐという新しいカタチでトークセッションを進めました。

シックス・アパート社さんのXアカウント（@sixapartkk）より

主なトークテーマ

当日の模様を録画していたわけではない（録画しておけばよかった…！）ので正確さは今ひとつかもですが、以下のような話題が繰り広げられました。

ヘッドレスCMSが増えてきて、MT6から登場したDataAPIのような機能が再認識されていると思うが、今後、DataAPI周りの拡張は予定されているか

すべてのエンドポイントを作成したので大きな拡張は考えていないが、ユーザー管理なども含め操作可能なAPIなので利用範囲は広いと思う
デジタルサイネージや外部システムとの連携はもちろん、管理画面そのものを作り直せるので広く利用してほしい
Movable TypeはヘッドレスCMSではないが、テンプレートを利用して自由なカタチでデータを取り出せるので、そのようなカタチでも利用してもらいたい

真剣に向き合って話してくれる早瀬さん

コンテンツタイプ、カスタムフィールド、カスタムブロックの使い分けと今後の展望は？

カスタムフィールドは記事やウェブページを拡張する機能、コンテンツタイプはより柔軟なウェブサイトの構造設計ができる機能と考えて利用してほしい
カスタムブロック（ブロックエディタ）もその入力値をMTタグで取り出すことはできるが、カスタムフィールドのように構造化されたものではないので、事前に情報整理が可能な場合はカスタムフィールドで設計するなど使い分けると良い
Movable Typeの中から「ブログ」という言葉は消えた（サイト＞子サイトという扱いになった）が、細かな情報設計なしにそのまま使える記事とウェブページは今後も無くならない
カスタムフィールドは情報の再利用性が高いが、すべてが情報整理できるコンテンツばかりではないので、カスタムブロック（ブロックエディタ）と併用できると良さそう
カスタムブロック（ブロックエディタ）の大幅な機能拡張は予定していないが、利便性向上などは今後も進めていきたい
コンテンツタイプは作りすぎると管理画面のパフォーマンスが低下することがあるので、今後はコンテンツタイプのパフォーマンス改善も進めていく
MovableType.netの「かんたんデザイン編集」でカスタムフィールドを使いたいという要望を聞くので今後検討したい

Movable Typeは「枯れたCMS」と言われることも多いが、今後の展開についてどう考えているか

Perlで書かれているからと言って古いわけではなく、今後もPerl5とその後継で開発を進めていく予定（PHPも良いが性能としての大きな差はない）
20年前に書かれたテンプレートも動作するほどMTタグの互換性を重視しているため枯れたと表現されることも少なくない。
継ぎ足しで書かれたコードはメンテナンスが大変なところもあるが、テスト駆動開発やCI（継続的インテグレーション）を取り入れ、品質と生産性を向上させていく工夫をしている
ウェブサイトは5〜10年ほど運営されるケースが多いように思うが、それに耐えうるだけのCMSでなければならないと考えている
長くお客様と向き合っていくために、安心して利用してもらうために、新しいものを取り入れた「枯れたCMS」も悪くないと考えている

枯れたCMSについて熱く想いを語る平田さん

シックス・アパート社として、Movable Typeユーザーコミュニティとの関わりをどう考えているか

Movable Typeはメーカーだけで成り立っているものではないと認識している
ウェブサイト制作会社さんやユーザーの皆さんからの声やフィードバックはありがたく、一緒に作っている感覚が嬉しい
オープンソースじゃないから貢献できないというものではないので、バグかも？と思ったものはQA（Quality Assurance／製品やサービスの品質を保証する担当）にフィードバックをもらえたら確認を進めるので気軽に投げてほしい
コミュニティの高齢化についても声を聞くが、今後はドキュメントを動画化するなど、若い世代でも触れやすい環境を準備していきたい
Perlであってもドキュメントがきちんと整備されていればチャレンジできると思うので、ドキュメント整備も進めていきたい

今後、Movable Typeをどのようなプロダクトに育てていきたいか

早瀬将一氏
世の中のウェブサイトで、その7〜8割がMovable Typeを利用しているような製品にしていきたい

平田大治氏
より長く、より使いやすく、ウェブの発展に貢献できるような製品にしていきたい

トークセッションを終えて

以上、かなり抜粋した感じではありますが、当日の模様を書き起こしてみました。

シックス・アパート社の方々とMovable Typeについて話すことは少なくありませんが、こういうイベントである程度まとまった時間を使って深ぼっていく感じ、とても楽しかったです。
個人的にはもうちょっと突っ込んだ話を…と思っていた部分もありましたが、なかなか難しいですね（笑）

トークセッションは16:30〜18:10の2セッション分（100分）を予定していたのですが、当初は「途中で話題がなくなったらどうしよう…」とかなり焦っていました（苦笑）
ところが実際に始めて見ると、用意していたトークテーマの半分ほどしか取り上げられないほど話が止まらない100分間となり、ゲスト出演してくれたbit partのお二人も交え、なかなか盛り上がったのではないかと思います。

会場には40〜50名ほどの方が参加してくれていたと思うのですが、数あるセッションの中から選んでもらえたのも嬉しかった…！
弊社メンバーや友人・知人たちも「思っていたよりずっと面白かった」「もっと聞いていたかった」「難しい話もあったが楽しかった」など、高評価をくれたので、それもとても嬉しかったです。

会場となったLINEヤフーさんの「Lodge」の様子

実はトークセッションやパネルディスカッションのモデレーター・ファシリテーターを務めたのは今回が初めてで、事前に練習というかリハーサルのようなものもあまりできなかったのですが、会場で参加してくれた大勢の方々が真剣に聞いてくれているのが伝わってきて、あまり緊張せずに進められたのが良かったです。
一度、こういうのやってみたかったので、個人的にもとても満足のいくトークセッションになりました！

あらためて協力してくれたシックス・アパート社の平田さん、早瀬さん、そしてbit partの柳谷さん、奥脇さん、参加してくれた皆さんに感謝です。
またどこかでやってみたいなぁ（笑）

この記事は、Movable Type Advent Calendar 2024 の4日目の記事です。
明日は @redamoon さんの記事が公開になるので、お楽しみに！

小樽市のウェブサイト制作会社7社と、ウェブサイト構築を依頼する時の5つのポイント

2024-08-17T09:48:00Z

ども、どもども。
ジャクスタポジション　西山です。

弊社（株式会社ジャクスタポジション）は今から20年ほど前に、ウェブサイトの構築事業をメインに小樽市で創業しました。
現在は所在地を札幌市に移していますが、今も小樽市内の事業者さんとお取引をさせていただいているほか、個人的には小樽青色申告会連合会の副会長を務めさせていただいたり、過去には小樽商工会議所さんの専門家派遣を通して小樽市内の事業者さんのところに訪問させていただいたこともありました。

そんなこともあって小樽への思い入れは強いほうと自負しているのですが、小樽市の事業者さんがウェブサイト制作会社を探そうと検索した際、検索結果に出てくるまとめ記事では所在地を北海道外に置く企業も多く掲載されていて、一部には小樽市内の事業者が一切掲載されていない記事まで見受けられることがあり、少し残念に感じていました。

そこでこの記事では「小樽市にゆかりがあるウェブサイト制作会社」だけをピックアップして、制作会社の目線で紹介していきたいと思います。

弊社創業当時と比べて状況も変わり、弊社含め同業者の方々にも個性が出てきた感じがありますので、小樽市でウェブサイト制作を依頼したいとお考えの事業者さんは、それぞれの会社さんの紹介とウェブサイトをご覧いただき「お！」と思ったところに問い合わせてみてはいかがでしょうか。

この記事がその参考になれば幸いです。

1. 株式会社ジャクスタポジション

まずは、弊社を紹介させてもらいます。
弊社は2004年に小樽市で個人事業として創業したウェブサイト制作会社で、2013年に法人化したのにあわせ札幌市へ移転しましたが、現在も複数の小樽市内の事業者さんとお取引させていただいています。

弊社は創業当時から「ウェブサイトは事業運営の柱となるもの」と考え、ウェブサイトを制作して公開することと同じかそれ以上に、事業に役立つようウェブサイトを運営していくことを大切に考え、ウェブサイトの企画・構築はもちろん、その後の運営サポートに力を入れています。
主にMovable TypeというCMS（コンテンツマネージメントシステム）を専門に扱っており、クライアント企業の方々が自ら更新や運営を行えるウェブサイトを構築しています。

URL	https://www.juxtaposition.co.jp/
会社所在地	北海道札幌市
小樽市内の主な構築実績	株式会社光合金製作所小樽市社会福祉協議会小樽観光振興公社（小樽観光船）北照高等学校 Hands on Toy's キンダーリープ回転寿し和楽おたる案内人検定（小樽観光大学校）ほか
価格帯	50万円（税別）〜 ※ウェブサイトに記載あり
小樽市内への訪問対応	可

2. 有限会社ウェブプロモート

弊社が創業する少し前から、ウェブサイトの構築事業をされている企業さんです。
代表の能登さんとは個人的に友人でもあり、古くからご活躍されているのを拝見しています。

ウェブプロモートさんでは、ウェブサイトの構築はもちろん、システム開発やスマートフォン向けアプリ開発なども手掛けられており、長い歴史があるだけに、その技術力などに定評と安心感があります。
ウェブサイト上に、ウェブサイト構築プラン（費用感）が詳細に記載されているので、どの作業にどれくらいの金額が必要なのか参考になると思います。

URL	https://www.webpromote.jp/
会社所在地	北海道札幌市・小樽市
小樽市内の主な構築実績	おたる水族館小樽商科大学オサワイナリー阿部建設株式会社学校法人浄暁学園（朝里幼稚園）小樽職人の会
価格帯	56万円（税別）〜 ※ウェブサイトに記載あり
小樽市内への訪問対応	可

3. 株式会社シナジークエスト

弊社が創業した少し後に設立され、DrupalというオープンソースCMSの活用に長けた企業さんです。
こちらの代表の白根さんとも個人的に友人で、さまざまなイベントなどでもお会いしています。

先程の通り、DrupalというオープンソースCMSを活用されており、導入に関する知識や技術は間違いないと思います。
また、IT技術者向けのトレーニング教材の開発や、IT関連セミナーの企画・運営などもされており、昨今のDX推進にも力強いパートナーになってくれそうです。

URL	https://synergyquest.jp/
会社所在地	北海道小樽市
小樽市内の主な構築実績	非掲載
価格帯	非掲載
小樽市内への訪問対応	要問合せ

4. 株式会社KOO

2019年に設立され、ウェブサイト制作のほか、音楽制作やドローンなどを使用した映像制作を手掛けられている企業さんです。
この記事を書いている今、5周年を迎えられているようです！祝！

北海道小樽市を拠点に「音楽」「デザイン」「VR/ドローン」を主としたコンテンツ企画・制作を行っていて、小樽ドローン協会を設立するなど、新しい技術の導入にも積極的に活動されているようです。
今の時代、SNSなどでもそうですが、動画が持つチカラはウェブ施策にも欠かせないので、心強いパートナーになってくれそうですね！

URL	https://koo-inc.jp/
会社所在地	北海道小樽市・札幌市
小樽市内の主な構築実績	小樽雪花火2023（小樽雪花火プロジェクト）西條産業株式会社小樽サマーフェス2022（オタルサマーフェス実行委員会）たる旅（株式会社アートクリエイト）おたるdeテイクアウト（小樽商工会議所）アルビレオ工房
価格帯	非掲載
小樽市内への訪問対応	要問合せ

5. 株式会社K2

2012年に設立された企業さんですが、それ以前にも別の会社でウェブサイトの構築事業をされていたので、業界歴はかなり長いと思います。
代表の中山さんとも面識がありますが、私が創業以前からこの業界でお仕事を頑張っていらっしゃいました。

ウェブサイト制作のほか、システム開発やサーバー・ネットワーク構築、アプリ開発、パソコン関連機器販売など、幅広く事業を行っておられるので、ウェブサイト以外の部分についても相談に乗ってくれそうです。

URL	https://kxk.co.jp/
会社所在地	北海道小樽市
小樽市内の主な構築実績	小樽商工会議所
価格帯	10万円（税別）〜 ※ウェブサイトに記載あり
小樽市内への訪問対応	要問合せ

6. 株式会社オープラン

昭和58年（1982年）創業の長い歴史をもつ老舗企業さんです。
マーケティング及びプロモーション（企画、デザイン、編集、ホームページ制作、調査・取材、広告代理、商品開発）を主な事業とされており、さまざまな企業・団体さんなどとお取引があるようです。

ウェブサイト制作のほか各種広告やパンフレットやカタログなどの編集なども手掛けられていて、小樽市内にも数多くのお取引先があるようなので安心感がありますね。

URL	https://o-plan.com/
会社所在地	北海道小樽市
小樽市内の主な構築実績	小樽建設協会美容室 fu-la.+ 一般社団法人北海道中小企業家同友会しりべし・小樽支部
価格帯	非掲載
小樽市内への訪問対応	要問合せ

7. 小樽総合デザイン事務局

トップページのデザインがとてもかわいらしい企業さん。
ウェブサイトのほか、名刺やフライヤー、イラスト・ロゴなどを手掛けられているようです。

2014年に設立されたようで、この記事を書いている今、ちょうど10周年を迎えられたようです！祝！
イラストがとても可愛らしく、LINEスタンプの制作などもされています。
企業情報が掲載されていなかったのが少し残念ですが、気になる方は要チェックですね！

URL	https://otarunet.com/
会社所在地	詳細非掲載
小樽市内の主な構築実績	株式会社アースビルド河辺石油株式会社蔵宿末広株式会社小樽スロゥスタイル一般社団法人小樽青年会議所
価格帯	非掲載
小樽市内への訪問対応	要問合せ

小樽市でウェブサイト制作の依頼を考えているなら

以上、7社をご紹介させていただきました！
弊社が創業した頃は、4〜5社だったと記憶しているので、今では1.5倍ほどになっていますね。
また、それぞれに実績もあるので、小樽市内でウェブサイトの制作を依頼する際も、自社にあった制作会社を選べそうです。

最後に、ウェブサイト制作を依頼するときのポイントをご紹介しますね。
これを事前に考えておくと、きっと制作会社さんへの相談やその後の運営もスムーズに進むと思います。

ポイント1. ウェブサイトで実現したいことをまとめておく

ウェブサイト構築の明確な構想や要望をお持ちの場合、それを事前にまとめておくとスムーズに相談できると思います。
ウェブサイトで実現・課題解決したいこと（自社の紹介をしたい、商品を販売したい、採用活動に使いたいなど）、ウェブサイトをいつまでに公開したいのか、そこにかけられる大まかな予算などを資料にまとめておくと良いでしょう。
これを提案依頼書といいますが、フォーマットに決まりがあるわけではないので、箇条書きのようなものでも問題ありません。

ポイント2. 制作会社の人に実際に会ってみる

提案を受ける前に、まず制作会社の方とお話をしてみることをお勧めします。
提案依頼書だけでは書ききれなかったことや、制作会社さんからの意外な質問や指摘などがあるかもしれません。
これをヒアリングといいますが、形式張ったものでなく、雑談のような感じで気軽に相談してみると良いと思います。

ポイント3. 提案内容について説明を受ける

その後、提案資料を受け取った際は、送られてきた資料や概算見積だけで判断せず、それが要望したものとは異なっていたとしても、一度内容について説明を受ける機会を設けましょう。
書類だけではわからない考えや思いなどを聞く機会を持つことは、制作会社の人と意思疎通するうえでとても大切です。
疑問に思ったことや、内容に関する確認などをすぐに行える意味でも良い機会になると思います。

ポイント4. 実現の可能性をよく検討する

提案内容の説明を受けた後は、それがどれくらい実現可能かよく検討しましょう。
自社がどこまで対応できるか、制作会社がどこまでサポートしてくれるのか、提示された予算が自社にとって妥当なものかなど、様々な角度から検討が必要です。
また、提案を受けた制作会社さんのウェブサイトであらためて構築実績を確認したり、代表者や担当者のブログやSNSなどから情報を集めるのも、その制作会社さんの個性や考えていることが見えて良いと思います。

ポイント5. 公開後の運営体制なども想像してみる

もう1つ、ウェブサイト公開後の運営についてもイメージしてみると良いと思います。
今の時代、便利なオンラインツールも多く対面で会うことが難しくても大きな問題にはなりませんが、実際に会える距離にいるかどうかは大切です。
それは「なにかあったときにサポートしてくれるか」という話だけではなく、例えば「自社の状況はもちろん、小樽市内や北海道内の情勢をどれくらい理解しているか」など、ウェブサイトを利用した施策を進めていくうえでパートナーとなる制作会社との共通認識を持つためにもとても大切なことと思います。

以上、大まかではありますが、ウェブサイトの制作を依頼する際のポイントをご紹介させていただきました。
小樽市内の事業者さんがウェブサイト制作を依頼する際の参考になれば幸いです！

DKIM署名とDMARCポリシーで、メールの信頼性を高めてみよう

2024-04-07T07:39:00Z

ども、どもども。
気がつくと2024年も3ヶ月が過ぎ、4月に入っていました。
あけましておめでとうございます…。

さて、1年ほど前になりますが、Gmailにメールが届かないときは、SPFレコードをDNSに登録しようという記事を書きました。

Gmailにメールが届かないときは、SPFレコードをDNSに登録しよう | www.ni4.jp

この記事では、独自ドメインを使用したメールがGmailに届かなくなってしまった場合への対処として、SPFレコードを登録する方法について書いていました。
送信されたメール（ドメイン）が、その送信元として許可されているメールサーバー／ウェブサーバーから送信したものであることを、受信側で確認できるようにする仕組みです。

これで独自ドメインを使用したメールがGmailに届かなくなることはなくなりましたが、その後、Gmailのガイドラインがアップデートされ、Gmailに対し1日5,000件以上のメールを送信する場合には、SPFレコードに加え、DKIM（ディーキム）レコード／DMARC（ディーマーク）レコードの登録が必要と変更されました。

メール送信者のガイドライン - Google Workspace 管理者ヘルプ

Gmail宛に1日5,000件もメールを送信することは現時点では考えにくかったので、特にこの設定はしていなかったのですが、弊社でも利用しているオンライン決済サービス Stripeから、このようなメールが届きました。

Stripe をご利用いただきありがとうございます。
この度、カスタムメールドメインの設定が変更されることをお知らせいたします。現在、お客様のメールはカスタムメールドメインから送信されていますが、ご利用のドメイン juxtaposition.jp に有効な DMARC ポリシーが設定されていませんので、以下の内容をご確認ください。

変更点
2024 年 2 月より、Google と Yahoo は迷惑メールに対処するための変更を順次実施しています。一括メール送信者に義務付けられる要件の 1 つに、SPF と DKIM と共に有効な DMARK ポリシーを併用してメールの認証を実行することがあります。
Stripe では、貴社のカスタムドメインから送信されるメールの認証に、すでに SPF と DKIM を使用しています。今回の新しい要件に完全に準拠するには、カスタムメールドメインを利用するための有効な DMARC ポリシーを保持していただく必要があります。

必要なご対応
ご利用のドメイン用の DMARC ポリシーをできる限り早く公開してくださいますようお願いいたします。このご対応により、お客様から Google および Yahoo のメールユーザーへのメール送信が中断されずに継続されます。DMARC ポリシーの設定方法については、Stripe のドキュメントをご覧ください。
2024/04/10までにご対応いただけない場合、お客様のメールの送信元はカスタムメールドメインではなく、stripe.com となります。

弊社製品の購入時、Stripeのクレジットカード決済／コンビニ決済を利用してお支払いいただいた際に、Stripeから送信されるメールを juxtaposition.jp で送信するようにしていたのですが、この機能（カスタムドメイン）を引き続き利用するにはDMARCポリシーの公開（DMARCレコードをドメインに登録する）が必要とのことでした。

これを良い機会と考え、Stripeでカスタムドメインに設定していた juxtaposition.jp に加え、同じく運用している juxtaposition.co.jp にもDKIM署名とDMARCポリシーを設定することにしました。

弊社では、ドメイン管理に「お名前どっとこむ」を、メールサーバーに「さくらインターネットのサーバー」を利用しているので、この記事ではそれらにあわせた内容で、設定を進めた手順をまとめておこうと思います。

DKIM署名の設定

DKIM署名とは、独自ドメインを使用したメールを送信した際に、ドメインのDNSレコードに登録されている公開鍵と、メールサーバーに設定されている秘密鍵を照合できるようにしておくことで、そのメールが正しい経路で送信されたものであると証明できる署名のことです。
例えば、誰かが送信元ドメインを詐称してメールを送信しても、その送信に利用されたサーバーにあるはずの秘密鍵が存在しなかったり、異なったもので照合できない場合に、受信側で正規の経路でないことを確認できる（なりすましと判断できる）ようになります。

弊社が使用していたさくらインターネットでは、2024年1月31日のアップデートで、このDKIM署名を設定できるようになっていたので、今回はこれにならってDKIM署名の設定を進めました。

Gmail宛てにメールを送信するお客様へ・メール送信者のガイドライン変更(Gmail)に伴う設定変更のお願い | さくらのサポート情報

さくらインターネットでのDKIM設定

こちらのマニュアルに記載のあるとおりに進めると、すぐにサーバー側の設定は完了します。
弊社はネームサーバーにお名前どっとこむを利用していたので、「DKIM署名、DMARCを設定する（他社のネームサーバー利用の場合）」の項を参照して進めていきました。

DKIM署名、DMARCを設定したい | さくらのサポート情報

設定が完了した画面で、セレクタ名と公開鍵の内容を以下の形式でメモしておきます。
後ほど、DNSレコード登録時にこれを使用します。

ホスト名	セレクタ名._domainkey.juxtaposition.co.jp
TYPE	TXT
VALUE	v=DKIM1; k=rsa; p=DKIM公開鍵

DKIM公開鍵の部分は、設定完了画面に表示されている公開鍵の -----BEGIN PUBLIC KEY----- と -----END PUBLIC KEY----- の間に記載されている暗号化された部分を1行に編集して記載します。

DMARCポリシーの設定

DMARCポリシーとは、送信したメールがDKIM署名などで迷惑メール（なりすましメール）と判定された際にどう処理するかを定めたものです。
あらかじめDNSレコードにそのような際の挙動を登録しておくことができます。

Stripeでカスタムドメインを利用する際にこのポリシーが必要になるのは、決済関連のメールを送信した際にもしそれが迷惑メールと判定されてしまうと、管理者（今回なら弊社）ではその状況を知るすべがなく、以降の対応ができなくなってしまうためと思われます。
今回はStripeの話ですが、他にも同じように独自ドメインを使用してメールを送るケース（例えばメールマガジンとか）はあると思うので、そのときにもDMARCポリシーの設定は必要になってくると思います。

DMARCポリシーの準備

DMARCポリシーの準備には、こちらを参考にしました。
書き方はもちろん、注意点などもわかりやすく記載されています。

DMARCレコードの書き方は？設定・確認方法や設定例も解説 - ベアメールブログ

上記を参考に、以下のように決めました。

ホスト名	_dmarc.juxtaposition.co.jp
TYPE	TXT
VALUE	v=DMARC1; p=none; aspf=r; adkim=r; rua=mailto:＊＊＊＊＊; ruf=mailto:＊＊＊＊＊

上記の「＊＊＊＊＊」にはメールアドレスを記載します。

DNSレコードの登録

上記のとおり、DKIM公開鍵とDMARCポリシーの情報が揃ったので、これらをDNSに登録していきます。
DNSレコードの登録方法はこちらの記事にも書いているのでここでは省略します。

DNSサーバー、Webサーバー、Mailサーバーを分離してみる | www.ni4.jp MovableType.netで使用する独自ドメインでメールも利用する | www.ni4.jp

DNSレコードの登録内容を確認

DNSレコードの内容はオンラインツールなどでも確認できますが、Windowsであればコマンドプロンプト、Macであればターミナルから確認できます。

SPF, DKIM, DMARCのDNSレコードの登録情報をdig, nslookupで確認する #mail - Qiita

上記でDNSの登録状況を確認できたので、実際にGmail宛にメールを送信してみました。
受信したメールで「メッセージのソースを表示」を開くと、以下のようになっていることが確認できます。

また、メールの送信者部分からも以下のようにDKIM署名が確認できます。

署名元として利用しているドメインが表示されると、なんだか安心しますね。

これでDKIM署名の設定と、DMARCポリシーの公開が完了となります。

DMARCレポートの確認

今回は設定しただけなのでまだ確認はできていないのですが、DMARCポリシーにrua（集計レポート）の通知先と、とruf（失敗レポート）の通知先を設定しておいたので、今後はレポートが届くと思います。
そのレポートを確認して、SPF/DKIMアライメントにPASSする必要があるようなんですが、今回はここまでにしておきます（苦笑）

DMARCのアライメントとは？ SPF・DKIMアライメントをPassするためのポイント - ベアメールブログ

独自ドメインでメールを運用するなら

最初はちょっと敷居が高いように感じた今回の件ですが、順序立てて進めていくと1〜2時間で終えることができました。

独自ドメインを使用してビジネスを行う場合、SPF／DKIM署名／DMARCポリシーは、自社だけでなく顧客も含め「なりすまし」から守ることができるので、メールの信頼性を高めて「安全なインターネット環境」を手に入れるためにも、ぜひ設定しておきたいですね！

Movable Type カスタムブロック利用時の15万文字制限への対処アイディア

2023-12-15T00:26:00Z

ども、どもども、西山です。
この記事は、Movable Type Advent Calendar 2023、15日目の記事です。

このブログでも数多く取り上げているMovable Typeのブロックエディタ、皆さん利用してますか？
私…というか弊社では、めちゃくちゃ使ってます。

ブロックエディタが利用できるようになって以降、弊社はもちろん弊社クライアントからも大好評で、ウェブサイトの運営がかなり楽しくなっています。

ただ、楽しくなるに連れ、少しづつ凝ったことをしたくなるのが人情…

今年公開になったウェブサイトでもカスタムブロックをたくさん作って、とても更新しやすいウェブサイトができました。
…といいたいところですが、実はちょっと困ったことがありました。

それが今日のテーマ「カスタムブロックの15万文字制限」の問題です。

カスタムブロックの15万文字制限とは

例えば、こんな感じのアコーディオンで開閉するコンテンツがあったとします。

アコーディオンが閉じた状態

この黒いバーの部分をクリック（タップ）することでアコーディオンが展開するボタンになっています。
クリックすると以下のようなカタチで開きます。

アコーディオンが開いた状態

この部分はカスタムブロックで「アコーディオンメニュー」という親ブロックを作り、その中に「アコーディオンメニュー（コンテンツ）」という子ブロックを含むように作られています。

カスタムブロック「アコーディオンメニュー」を利用した際のイメージ

これを使って、1つのウェブページ内に複数のブロック（ここではアコーディオンメニューブロックと呼びます）を設置するウェブページを作りました。
HTMLを書こうと思うと、なかなかしんどい数（トータル38個）ですが、ブロックエディタなのでサクサクと入力が進みます。

ところが、一通り入力を終えて保存しようとしたところ、「本文と続きはあわせて15万文字以内で入力してください」とエラーが出てしまいました。

15万文字…？（汗）

状況がよくわからないまま、ブロックを1つ削っては保存を繰り返したところ、7〜8個以上のアコーディオンメニューブロックを保存しようとしたところで、このエラーが発生することがわかりました。

全部で38個を入力しようとしているのに、ぜんぜん足りない（汗）
というか、7〜8個程度のブロックで15万文字も入力している？？

そこで、素のHTMLでどれくらいの文字数になるのか確認したところ、全38個のブロックでも9.5万文字程度とわかりました。
単純計算だと、8個のブロックで2万文字程度しか保存していないのに、このエラーが出たことになります。

なにが原因かを確認していくと、1つの可能性を見つけました。

これ、なんだかわかりますか？

実はこれ、1つのアコーディオンメニューブロックを保存する際に実際に保存されているコードで、カスタムブロックの構造や、入力しているHTMLなどをJSON形式（？）で保存しているようです。

なにか適当なカスタムブロックを「コピー」して、テキストエディタ等に貼り付けると確認できると思います。
参考：ブロックエディタの機能強化を行いました（2022.07.14）

そしてよく見ると、カスタムスクリプトで加工しているHTMLがすべてエンティティされているのがわかります。

<p>北海道がんセンター</p>
↓
<!-- mt-beb --><p>北海道がんセンター</p><!-- /mt-beb -->
↓
&lt;!-- mt-beb --&gt;&lt;p&gt;北海道がんセンター&lt;/p&gt;&lt;!-- /mt-beb --&gt;
↓
&amp;lt;!-- mt-beb --&amp;gt;&amp;lt;p&amp;gt;北海道がんセンター&amp;lt;/p&amp;gt;&amp;lt;!-- /mt-beb --&amp;gt;

おそらくカスタムブロックのプレビューを表示したり、入力内容を再編集したりするためにこのようなカタチで保存する必要があるのだと思いますが、この影響で、実際に出力したいHTMLよりもデータとして保存する文字数が増えているようです。

1つのアコーディオンメニューブロックで実際に出力したいHTMLがおよそ2,500文字であるのに対し、保存されるJSONデータはおよそ2万文字ありました。

そのため、アコーディオンメニューブロックを7つ保存した時点でJSONデータは14万文字となり、8個めで15万文字を超えることになります。
よって、15万文字制限はこのJSONの影響じゃないかなと考えました。

なんとなく原因がわかったので、カスタムブロックやカスタムスクリプトを見直すことも考えましたが、納期まで時間がない…
そこでひとまず、管理画面にHTMLコードをそのまま貼り付けることで凌ぐこととしましたが、これではせっかくのブロックエディタが活用できないので、なにか良い方法はないかと考えました。

15万文字制限を回避するアイディア

カスタムブロックの構造やカスタムスクリプトの中身を見直すことで解消できるかもと思いつつ、大幅な文字数削減にはならない気がしたので、他の方法を探していたところ、思い出したのが、MTBlockEditorBlocksタグです。

以前、このブログでも紹介したとおり、このタグを使用すると、ウェブページ内にテンプレート・モジュールを読み込むことが可能となります。

【MovableType.net】同じフォルダに含まれる下層ページをウェブページ内で一覧表示するカスタムブロックを作ってみた | www.ni4.jp

つまり今回の場合、アコーディオンメニューブロックを1つずつ下層ウェブページで登録し、親のウェブページからは下層ウェブページのHTMLを読み込む方法を考えてみました。

これなら、親のウェブページで大量のJSONデータを保存することはなくなるはずです。

手順1：下層フォルダを作成

まず、各アコーディオンメニューブロックを登録していく下層ウェブページを格納するフォルダを用意します。
今回は7つのカテゴリ（分類）が必要だったので、以下のようにフォルダを作りました。

手順2：カスタムブロックを作成

続けて、特定のフォルダに入っているHTMLを読み込むためのカスタムブロックを作ります。
先ほどの記事にあるとおり、以下のように作成しました。

手順3：ウェブページのテンプレートを編集

ウェブページのテンプレートにある<mt:PageBody />部分を以下のように書き換えます。

<mt:BlockEditorBlocks tag="PageBody">
  <mt:If name="type" eq="custom-trials_module">
    <mt:Include module="治験内容" folder_label="$__value__" />
  <mt:Else>
    <mt:Var name="__value__" replace="$dev_url","$website_path" />
  </mt:If>
</mt:BlockEditorBlocks>

カスタムブロック「治験内容」を使用すると、テンプレート・モジュール「治験内容」の内容を読み込みつつ、カスタムブロックで選択したオプション名（フォルダ名）がfolder_labelにセットされます。

カスタムブロックとテンプレート・モジュールの名前は分けるべきでしたね…

手順4：テンプレート・モジュールを作成

テンプレート・モジュール「治験内容」を以下の内容で作成します。

<mt:PageID setvar="this_id" />
<mt:Pages folder="$folder_label" include_subfolders="1">
     <mt:If tag="PageID" ne="$this_id">
        <mt:PageBody />
    </mt:If>
</mt:Pages>

このテンプレート・モジュールが読み込まれたとき、カスタムブロックで選択した「オプション名」と同じ名前の下層フォルダに含まれるウェブページの<mt:PageBody />が出力されます。

手順5：下層ウェブページにアコーディオンメニューブロックを設置

下層フォルダに格納するウェブページ（アコーディオンメニューブロックが設置されるページ）を作っていきます。

一通り下層ページを作成すると、以下のようにウェブページが出来上がりました。

手順6：親ページでカスタムブロックを設置

最後に親ページでカスタムブロック「治験内容」を使用して、テンプレート・モジュールを読み込みます。

ここでは「悪性リンパ腫」というカテゴリだけですが、同じようにそれ以外のカテゴリも作っていくと、親ページの完成となります。

親ページの文字数はどうなったか

親のウェブページでは、モジュールを読み込むためのカスタムブロック（274文字程度）のみを設置するため、全7カテゴリあっても、2,000文字程度までダイエットすることができました！

カスタムブロック「治験内容」に保存されるJSONの中身（悪性リンパ腫のカテゴリ選択時）

これで15万文字制限を回避できそうです。

留意点

MovableType.netでは、すべてのコンテンツをsitemap.xmlに自動出力するので、今回作成した下層ウェブページがどこからもリンクされていなかったとしても、sitemap.xmlには記載されてしまいます。

サイトマップの利用について - マニュアル | MovableType.net

今回のBlockEditorBlocksを使ったテンプレート・モジュールの読み込みを利用するアイディア、なかなか良いんじゃないかなと思いましたが、公開予定の無いページもGoogleさんに拾われる可能性があることだけは留意が必要かなと思います。
今回は、仮に下層ウェブページにアクセスしてもナビゲーション等が通常通り表示されるので大きな問題はないと判断していますが、場合によってはこれらのページだけ、少し加工する必要があるかもしれませんね。

最後に

今回も3年前の自分のブログ記事に助けられました。
アウトプット、とても大切…（笑）

ウェブページで保存できる文字数が15万文字に制限されている理由はわかりませんが、今後、コンテンツを作っていく際に同じ状況になった場合はこのアイディアが活かせそうです。

また、今回の対応を取っていて思ったのですが、そもそそも1ページ内に38個ものアコーディオンを設置するようなケースで、カスタムブロックを38個並べるのは、機能としては良くても、編集・更新時にはなかなか厳しいです（苦笑）
カスタムブロックをよく利用されている方であればわかると思いますが、途中でどこの入力欄を使用したらいいのかが分かりにくくなることもしばしば。
…というわけで、カスタムブロック利用時は、それを操作する際のことも考えて、あらかじめ上手く設計しておきたいですね（自戒）

あと、今回はMovableType.netでのみ確認をしていますが、この15万文字制限がMovableType.netの仕様なのか、ソフトウェア版やクラウド版でも同じなのか、その辺りも気になりますね。

以上、Movable Type カスタムブロック利用時の15万文字制限への対処アイディアでした！
明日からのMovable Type Advent Calendar 2023もお楽しみください。

サムネイル画像に使用しているのは、UnsplashのAnnie Sprattが撮影した写真です。

MTDDC Meetup TOKYO 2023に参加してきました！

2023-11-19T07:30:00Z

ども、どもども。
ご無沙汰ブログです、こんにちは。

去る11月11日（土）、4年ぶりのオフライン開催となったMTDDC Meetup TOKYO 2023に参加してきました。
会場は、東京ガーデンテラス紀尾井町にあるLINEヤフー株式会社のセミナールーム。
今年も150名近くの方が会場に集っていて、久しぶりにイベントの楽しさを実感できる1日となりました！

MTDDC Meetup Tokyo 2023【11/11（土）開催】

今日のブログ記事は、このイベントの参加レポートになります！
ブログを書くまでがMTDDDC、というわけで最後までお付き合いください。

初めてのノベルティスポンサー

今回のイベントで初めて、ノベルティスポンサーになりました。
イベント当日に配布された資料や、ノベルティを持ち歩くために使用されるバッグ。
弊社ロゴ入りで作成したのですが、思っていたよりもシックな雰囲気でいい感じの仕上がりに満足でした！

参加者の方々が、これを片手に会場内を歩いているのを見ると、とてもいい感じでしたよ。

ちなみにこのバッグ、結構な枚数が余ったので、今後は弊社資料などを配る際にも使おうと思っています（笑）
もし欲しいという方がいれば、ご連絡くださいｗ

セッションを担当

また、私は今回もMovable Typeトラックでのセッションを担当させてもらいました。
準備に時間が取れず苦戦したのですが、結果的にいい感じの30分セッションができたのかなと思います。

カメラマンの加藤さんに撮ってもらった写真

西山泰史氏｜Movable Typeトラック 14:20 - 14:50｜MTDDC Meetup Tokyo 2023【11/11（土）開催】

当日は、20名ちょっとくらいの方が、私のセッションに参加してくれていました。
初めてMovable Typeを知った人、またはこれまで特定の製品ラインナップに偏って利用してきた方などを対象にセッション内容を組み立てましたが、聴講いただいた方からは好評をいただけたので、ホッとしています。

当日のスライド資料はSpeakerdeckで公開しています。

MT東京の実行委員会に参加

そして今回は、初めてMT東京の実行委員会にも参加させてもらいました。
当日はスタッフとして、会場づくりとか来客誘導、打ち上げの幹事なんかをさせてもらいました。
オフラインイベント自体4年ぶりだし、なんだかこう「リアル開催している感」がとてもあってよかったです（笑）

MTDDC Meetup TOKYO 2023 実行委員会メンバー

懇親会の途中、宮永さんとなぜか2ショット写真を撮ってもらったときの写真（笑）

久々のオフラインイベントはやはり楽しかった

4年ぶりの開催ということで、私を含む弊社メンバー3名で参加した今回。
イベント前夜祭や、メンバーとの食事、イベント当日はもちろん、その打ち上げまで、とても楽しめた3泊4日でした。

今回は当日スタッフなどの都合もあり、セッションへの参加はほぼできませんでしたが、それでも十分にイベントを楽しめました。
やはり年に数回はこんな感じのイベント参加をしていきたいですね。

来年開催のMTDDC Meetup TOKYO 2024で実行委員長を務めることにもなりましたので、来年はできる限り全国のいろいろなコミュニティに参加したいなと思っております。

Movable Type コミュニティの皆さん、来年もよろしくお願いします！

羽田空港「又こい家」のまぐろ寿司

Facebookが不正アクセスで乗っ取られ、アカウント停止処分を受けました。

2023-07-28T23:55:00Z

ども、どもども。
…と、いつも通りな感じで書き始めましたが、心中はいつもどおりではありません…！

実は、7月21日（金）の深夜に、10年以上利用していたFacebookアカウントの乗っ取り被害に遭い、それ以降、Facebookにまったくアクセスできない状況が続いているのです。

WEB関連の仕事していて、なんなら「コンサルティング業務」なんかもやっている私ですが、大変お恥ずかしい話ながら、何をしていてもやられるときはやられるんだな、と。
今は「まさか自分が…」という気持ちで、心がかなりざわついております。

少し気持ちの整理ができてきたので、不正アカウントがあったときのことから、アカウントが停止された後になにをしているかなど、この記事でまとめて行こうと思います。
この記事を書き始めた7月26日（水）現在、まだ復旧の目処は立っていませんが、進捗があり次第、追記していくカタチで残していきたいと思います。

相次ぐ不正アクセスアラートとアカウントロック

ことの発端は、7月21日（金）の14時28分の出来事でした。
この画像は、弊社Slackに投稿した際のものです。

14時28分から、たびたび不正アクセスアラートがメールで入り、その都度、アカウントがロックされる状態が続きました。

アメリカ時間だから？なのか7月20日になっています。

ただこのときは仕事中だったこともあり、すぐに対処することができました。
上記の「スタート」をクリックして進むと、アカウントのスキャンが始まって、アクティビティチェック（何を投稿したかなど）の後、パスワード変更までを実施できます。

不正アクセスが検知されたのは4〜5回だったと記憶しています。
ただ、その後はアラートが来ることもなく、2段階認証も設定しているし、パスワードもその都度変更していたので、ここで不正アクセスラッシュは終わったんだなと思っていました。

再び届く不正アクセスアラート

21日（金）の夜は友人と食事に出かけていたのですが、だいぶお酒も入った23時32分にまた不正アクセスアラートがありました。
そしてこのときは外出先だったこともあり、そのメールに気がつくことができませんでした。

自宅に帰り、そのメールに気がついた私は、夕方に対処したのと同じく「アカウントのセキュリティを保護しましょう」というリンクをクリックしました。

「何者かがアカウントにアクセスした可能性があります」という件名の不正アクセスアラートメールの内容

しかし、このリンクをクリックして、事態の深刻さに気が付きます…
リンク先で表示されたのは、夕方に表示された「アカウントがロックされました」ではなく、以下の内容でした。

え…アカウント停止？と思いましたが、この日はお酒が入っていた深夜だったこともあり、翌日に落ち着いて対処すればなんとかなるのでは？と考え、そのまま就寝しました。

ハッキングされるまでの時系列

不正アクセスアラートが届いてから、乗っ取りが完了したと思われる通知までは、以下のような流れでした。

メールの受信時刻	メールの件名	内容
23:32	何者かがアカウントにアクセスした可能性があります	セキュリティ保護のため、終了するまであなたのページはFacebookで表示されません。
23:33	Chrome（Windows）のログインアラート（ログイン確認）	普段使用しているものとは異なるデバイスや場所からの不審なログインが検知されました。あなたが実行したものですか？
23:39	メールアドレスを削除しましたか？	メールアドレス＜登録アドレス1＞があなたのFacebookアカウントから削除されました。
23:39	電話番号を削除しましたか？	電話番号＜000-0000-0000＞があなたのFacebookアカウントから削除されました。
23:40	たった今メールアドレスを追加しましたか？	メールアドレスgaumerdanyelle@hotmail.comがあなたのFacebookアカウントに追加されました。
23:41	Facebookアカウントのリカバリーコード:＊＊＊＊＊＊	Facebookパスワードのリセットがリクエストされました。以下のパスワードリセットコードを入力してください。
23:41	パスワードをリセットしましたか？	あなたのパスワードがリセットされたことをお知らせします。
23:42	メールアドレスを削除しましたか？	メールアドレス＜登録アドレス2＞があなたのFacebookアカウントから削除されました。
23:45	何者かがアカウントにアクセスした可能性があります	セキュリティ保護のため、終了するまであなたのページはFacebookで表示されません。

通知があったのは以上です。
わずか13分、私のログイン情報がすべて削除されるまでは、たった10分間の出来事だったようです。

23時33分の不正アクセスアラートで「Chrome（Windows）」となっていますが、私は基本的にMacからしかアクセスしていないので、これに気がついていれば、あるいは防げたのかもしれませんが…今となってはわかりません。
2段階認証を設定しパスワードをかなり強固なものにしていたという安心感からか、それともお酒が入っていたからか、いずれにしても、この時点で気がつけなかったのが悔やまれます。

翌日以降に行ったこと

不正アクセスがあった翌日22日朝から、さまざまな方法でアカウント再開を試みました。

本人確認書類のアップロード

まずは、通知が来ていたメールアドレスを削除したという内容に「私は変更していません」と報告する対応から始めました。

表示されるのは以下のような画面。
上記のとおり、使用しているデバイスはWindows Chromeであるにも関わらず、「以前Facebookにアクセスしたデバイスから実行されました」というメッセージが…

当然、私ではないので「他の人です」を選択して手続きを進めるのですが、次画面で表示される「ログインコード」を入力しても、「入力されたログインコードは携帯電話に送信されたものと一致しません。コードをご確認の上、もう一度実行してください」と表示されます。

そりゃそうですよね…
すでに電話番号も変更されているので、2段階認証アプリを入れている端末が違うから正しいわけがありません…。

そこで、その下にある「他の方法で本人確認を行う必要がありますか？」から手続きを進めます。

他のデバイスから承認というのもありますが、そもそもログインできないから困っているわけで、別のブラウザや携帯電話からログインしてと言われても…というわけで「他のオプション」を開きます。
ここでやっと、本人確認書類のアップロードに移動が選択できるようになります。

次画面で「次へ」を選択して、まずはメールアドレスを入力して認証コードを送信します。

メールで届いた認証コードを入力して「次へ」をクリック

次画面の本人確認書類の種類を選択する画面では「運転免許証」を選択しました。
（他に適当なのが見当たりませんでした）

次画面以降で、ウェブカメラを使用して運転免許証を撮影します。

撮影後「次へ」をクリックしましたが、本人確認書類の写真に問題がありますと表示され、次のステップに進むことができません…

最初は、撮影した内容がはっきり判別できない、あるいは4つ角のどれかが欠けているのかと、なんども繰り返し撮影を試みましたが、一向に先へ進む気配が無いので、この方法は一旦諦めることに。
この「現在この機能はご利用いただけません」というメッセージが気になりますね…

ただ、Facebookに個人用アカウントを誤って削除されたと思われる場合は、この「本人確認書類」を提出することでアカウントが再開できたという情報が多かったので、別の方法を試してみることにしました。

停止された個人用アカウントの再審査リクエスト

次に、個人用Facebookアカウントが停止された場合に利用できる「審査リクエストフォーム」を使用してみました。
ここにアクセスして、自分のアカウントが誤って停止されたと思われる場合にある「こちらのフォームを使用して審査をリクエスト」へ進みます。

次画面で表示されるフォームに「アカウントに登録されている氏名」を入力し、「ID（運転免許証）」をアップロードしましたが、ここでは以下のような内容が表示されました。

フォームには「Facebookコミュニティ規定違反によりアカウントが停止されている場合にのみこのフォームを送信してください」とあるのに、「この決定はすでに審査済みであり、撤回することはできません」とはこれいかに…

別の画面から本人確認書類をアップロード

とても納得できるものではないので、さまざまな方法でなんとか本人確認書類を送ろうと試みました。

例えば、通常通りログインしようとすると以下の画面になります。
「アカウントがハッキング（不正アクセス）されたことが報告されました」とありますが、ここで「アカウントの安全を確保」しようとしても…

表示されるのは非情なメッセージ…

別の手段で本人確認書類を送ろうとするも「リクエストを処理できませんでした」と表示され、

その挙げ句、「不正使用を防ぐため」という理由で、実行不可に。
私が不正利用されているのに…。

不正使用されたアカウントを報告

Facebookに用意されている「不正使用されたアカウントを報告」も利用してみました。

アカウントが不正使用されたというリンクをクリックし、検索するよう促されるも、

使用ペースが早すぎるという理由でブロックされてしまったり（汗）

コミュニティ規定に違反した覚えは無いので、「Facebookにお知らせください」というところから進もうとしますが、アカウント検索からの無限ループ地獄に陥るだけでした…

繰り返されるアカウント検索

アカウントがハッキング（不正アクセス）されたことが報告されたとあるのが唯一の望みで、「それを信じて待つよ…」という気持ちになっていました。

なりすましアカウントを報告

乗っ取られた翌日、友人から「アカウントの名前が Rahul Ranade になっている」と情報を得ていたことを思い出しました。

そこで少し時間をあけ、意味があるかはわかりませんが、なりすましアカウントを報告してみることに。

コツコツと入力を進め、送信ボタンをクリックすると…
そんなプロフィール（URL）はFacebookに存在しないと言われてしまいました（汗）

こんな感じで7月26日（水）までいろいろ試しましたが、ここまでのとおり、どれもうまく行かない状態が続いています。
この間もウェブやTwitterで情報収集を試みますが、アカウント停止処分を受けたら諦めるしか無いという情報や、乗っ取られても本人確認書類をアップロードしたら再開できたという情報はあるものの、具体的な方法や、アカウント停止からの再開についての情報は得られませんでした。

ご意見・ご要望としての連絡

28日（金）、乗っ取り被害からもうすぐ1週間。
これはもうホントに最後の手段的な感じで、ご意見・ご要望を送ってみることに。

Facebookから、なにかしらリアクションがあるとは見込めない感じですが（苦笑）
まさに藁にもすがる思いで、Facebookに手紙をしたためました。

Facebookに届け！この想い！

この後、なんとか良い結果に向かってくれることを願っています。

Facebookが利用できなくなってからの1週間

今日は7月29日（土）です。
Facebookアカウントが乗っ取られてから1週間が経過しました。

メッセンジャーが使えないのがつらい

乗っ取り被害にあい、最初に困ったのは「メッセンジャーが利用できないこと」でした。
プライベートな連絡はもちろん、仕事でも利用していたのですが、「Facebookのアカウント以外、連絡先を知らない友人」が意外にも多いことに気が付きました。

よく会っていた友人たちはもちろん、過去にイベントなどで知り合い連絡を取っていた友人や知人との間で、一番便利に利用していた連絡手段が一瞬で絶たれてしまいました。
運良く23日（日）に、友人たちと集まる機会があったので、そこで今さらながらLINE交換とかしてました（照）
8月の上旬にはオンラインセミナーの登壇も予定しているのですが、セミナー主催者さんとの連絡もメッセンジャーがメインだったので、これもどうしたものかと悩んでいます。

もちろん、メールなどで連絡することはできるのですが、慣れというのは怖いもので、チャット形式のほうが遥かに使いやすい人間になってしまっていました。

普通なら知り合えなかった友人たちと強制的に離れ離れになってしまう

私はSNS、特にFacebookを利用するようになってから、一気に住む世界が広がりました。
東京や仙台、名古屋、大阪、京都、福岡、沖縄にいる、普通なら知り合うことは無かった友人たち。

Facebookがあることで得られたコミュニティ、そんな彼ら彼女らと、私だけがこれまでのような関係性は保てないのかも…と疎外感のようなものを感じ始めています。
たとえ数年会っていなくても、ブラウザの向こうにはその存在をいつも感じられて、ひとたび会えばその時間とか距離とかを一瞬で忘れられていたのに。

毎日のように投稿していた「1日の振り返り」が書き残せない

私はかなりのFacebookヘビーユーザーだったと思うのですが、ちょっとしたことはもちろん、1日の終りにその日を振り返るような投稿をほぼ毎日していました。

それができなくなった最初の月曜日。
いつものように仕事を終えるわけですが、なんだか1日が終わった気がしない…
Twitterもあるのですが、無意識に近いレベルで使い方を分けていたので、ログを残せないことがとてもモヤモヤした気持ちになっています。

ちなみに最近は、Twitterで毎日のように「今日の進捗」として、Facebookアカウント復活へ向けた投稿をしています（笑）

過去の出来事が振り返られない

私はFacebookをライフログのように使っていました。
面白いこともくだらないことも書いていますが、そのときどきの出来事を残すようにしていたので、毎日のように「○年前の今日」というカタチで過去の出来事を振り返っては、こんなこともあったなとか、これは面白い出来事だったなと楽しんでいましたが、これができなくなったのがとても寂しいです。

車を買い替えた時、それまでの愛車に「今までありがとう」と伝えた投稿
次女や三女が生まれたときの投稿
長女のしりとりに付き合ったら、とんでもないボケをして大笑いした投稿
2013年と2018年に開催したMovable Typeのイベント（MTDDC Meetup）の投稿
異世界転生アニメへの提言を綴った投稿
会社での出来事、飲み会での出来事を綴った投稿
今では普通に付き合っている友人たちと、初めて会った日の投稿

過去10年以上に渡るこれらのログ、それがすべてが消え去っている状態です。
正直、とてもつらい。

ここから先、もう投稿はできませんよと言われても、もしかしたら許せるかもしれませんが、過去のできごとが一切残らない状態は、とても虚しい気持ちになります。

なぜアカウント停止処分になったのか

今回のコミュニティ規定違反によるアカウント停止処分、なぜそんなことになったのかを考えているのですが、正直、さっぱりわかりません。
おそらく、乗っ取り犯がなにかしらの投稿などをしたか、あるいは誰かがアカウント乗っ取りに気がついたとき、なにかしらの「報告」がFacebookにあったのではないかと思います。

Facebook側は、一定数はあったであろうその報告に基づき、機械的にアカウント停止処分を下した。

そう考えるのが自然で、妥当かなと思っています。

SNSに関して思うこと

初めてSNSアカウントが消されてしまう経験をしているのですが、思っていたよりもずっとショックで、そしてそれは突然やってくるのだなと思いました。

コミュニティ規定違反でアカウント停止処分、おそらくこれは乗っ取り犯の何かしらの行為が問題になっていると思います。
私はなにも関与していないにもかかわらず、処分を受けているのは私という現実。
2段階認証を設定していたにも関わらず、わずか10分程度でそれを突破されハッキングされたのに、一方的に「再審査は受け付けない」という姿勢は、10年以上も利用してきたユーザーに対して、あまりにも非情ではないかなと思います。

せめて、Facebookに直接連絡できる手段を残してほしい。
全世界で30億人ともいわれるユーザーを、1人1人相手にできないのはわかります。
とは言え、その手段を残していないというのは、残念というよりも、ちょっと怖い気持ちすらしました。

あくまでサービスを無償利用している立場なので、そのルールに則って利用するしか無いのは理解しています。
それに、サービスの名前が変わるとか、慣れ親しんだアイコンが変わるとか、SNSを提供している企業にも事情はあると思うので、それは受け入れなければならないとも思います。

ただ、仮にどこかのSNSがなくなったとしても、SNSがなくなる未来は考えにくいので、SNS各社にはそういった文化や価値観というか、インフラを提供しているということを、もうちょっと誇りにしてサービスを提供してほしいなと感じています。

そして私たち利用している側は、1つのSNSだけに頼らない人間関係の構築も大切にする必要があると思い知らされました。

これからどうするか

ご存知のとおり、Facebookは実名登録を原則にしているので、アカウントを複数持つことはできません。
現在、アカウント停止にはなっていますが、すぐに利用履歴が消えるわけではないと思われるので、仮に別の電話番号やメールアドレスを利用して新しくアカウントを作成しても、同一人物と判定されたときにまたアカウント停止処分を受けることになるようです。（接続元IPアドレスとか、利用デバイスとかから機械的に判断していそう）

それに、今現在もまだ、アカウント復活を諦めたわけではありません。
そんな簡単に10年以上のライフログを捨てる気にはなれません（笑）
なので、アカウントを新しく作ることがあったとしても、まだもう少し先と考えています。
本当は、今すぐメッセンジャーだけでも使いたいのですけどね（苦笑）

今後、この問題がどうなっていくのか、私にもまだわかりませんが、なにか変化があったらまたこちらに書き足して行きます。
同じようにアカウントが突然停止されて困っている人や、これから先、乗っ取り被害に遭ってしまった方々のためにも、なんとかアカウント再開を成し遂げたいと、今は思っています。

Facebookで繋がっていた友人たちへ

現在、Facebookでのみ繋がっていた皆さんには、私から連絡する手段がありません。
先の通り、アカウント再開または新しくアカウントを作るにしても、まだ時間がかかると思うので、もう少しだけ待っていてくれると嬉しいです。

もしもこれをご覧になって、他のSNSなどの連絡先を交換しようと思っていただけた方は、メールやSMS、Twitterなどを利用してご連絡いただくか、あるいは私の連絡先を知る共通の友人・知人を介して連絡をいただけると幸いです。

またいつものように、くだらなくも楽しい、そんな日常を共有できることを願って。

乗っ取り被害発生から4ヶ月が経過しました。

こんにちは、この部分を書いているのは、2023年11月23日（木）です。
Facebookアカウントの乗っ取り被害に遭ってから4ヶ月が経過しました。

この間もアカウント再開に向け、いろいろと取り組んで来ましたが、結論から言うと、現時点ではまだ再開に至っておりません。
今回は、この4ヶ月間のことを書いておこうと思います。

Twitter（X）への投稿とそれにより見えてきたこと

このブログ記事を最初に書いた7月29日、Twitter（X）に以下の投稿をしました。

Facebookが乗っ取り被害に遭ってから1週間。
これまでの経過と、今考えていることをブログ記事にしました。

これをご覧の方で、Facebookでも繋がっていた方は、共通の友人への状況連絡として、この記事をシェアしてもらえると嬉しいです。#Facebook #アカウント乗っ取り https://t.co/FHRdZGTyxk
— にちあま@ウェブディレクター (@nishi_yama) July 29, 2023

この投稿には多くの方からリアクションをいただきました。
同じようにアカウント乗っ取り被害に遭われている方からも連絡があり、その後、情報交換させていただいた方もいます。
また、インターネット検索でこのブログ記事を見つけたという方からも、DMやメールを数多くいただきました。

Facebookアカウントの乗っ取り被害は、何年も前から多く発生していたようですが、2023年2月頃から急に増えだし、6月〜8月くらいにピークになっていたようです。
中にはアカウント再開できた方もいましたが、私と同じようにFacebookへの報告もままならない状態になる方も多く、早々にアカウント再開を諦めてしまった方も多かったようです。

アカウント再開できた方々の体験談

ありがたいことに、私のもとには「ブログ記事に書いてある方法以外で、こんな方法でアカウントを取り戻すことができました」という体験談もお寄せいただきました。

Facebookアカウントと連携していたInstagramアカウントから、再度連携するようFacebookにログインしたらアカウントが再開できた。（Instagramのアカウントセンターへアクセス）
disabled@fb.com に英文で「アカウント停止の解除」「アドレスの再登録」のメールを送った。

ただ、残念ながら私の場合はこれらの方法でもアカウント再開には至りませんでした。

私はMeta社の公式サポートを受けることに

アカウント停止から2ヶ月ほどが経過したとき、ふと「Meta認証」のことを思い出しました。

InstagramとFacebookのサブスクリプション「Meta認証」を日本でも提供開始 | Metaについて

これは月額費用を負担することで、アカウントの本人確認が行われ、適切なアカウント保護がなされるものです。
また、これを利用すると日本語でアカウントサポートデスクに連絡を取ることができます。

9月13日、このことをふと思い出し、さっそくInstagramからMeta認証を受け、サポートへコンタクトを取ることにしました。
Facebookアカウントが乗っ取り被害に遭った旨のメールを送ってから1時間ほど経ったとき、サポートから返信がありました。

このメールは以下のように続いていました。

これまでFacebookやInstagramなどのMetaのサービスや製品でご利用されたことがないメールアドレス
（その新しいメールアドレスが復旧後のログインメールアドレスとなります）
「現在はアカウントが停止されており、アカウント再開の再審査を行いたいのですが、重大なコミュニティ違反として再審査を受け付けない旨が表示されてしまい、打開策が見当たりません。」この部分のスクリーンショットをご提示頂ければ幸いでございます。

この瞬間、真っ暗なトンネルの中を彷徨った2ヶ月間からやっと開放される！とものすごく興奮しました。
一筋の光明とは、まさにこのことだと思います。

Meta Pro Teamとのやり取りが始まってからの2ヶ月

先の通り、さまざまな解決方法を試すもうまく行かなかったこともあって、Meta社のサポートに連絡が取れるようになったのは、とても嬉しい出来事でした。
時間はかかってもアカウント再開が叶うのであれば…と、サポートから提供依頼のあった情報や資料をコツコツと送る作業を始めました。

サポートとの連絡を取り始めて2〜3週間後、もっと早くに解決するかと思っていましたが、なかなか進展がありませんでした。
とは言え、全世界30億ものアカウントがあるような巨大サービスですし、ある程度時間がかかるのは仕方がないのかと、この頃から連絡は週に1度くらいのペースになっていきました。

調査開始から5週間…
ワタシのアカウントはどんなことになっているのだろう… pic.twitter.com/I7Gvws9ida
— にちあま@ウェブディレクター (@nishi_yama) October 19, 2023

Meta社から、にわかには信じられない連絡が届く

調査依頼を開始してからおよそ5週間後の10月28日、その後の状況を確認したところ、以下の返信がありました。

サポートから担当部署への調査依頼が却下されている…？！
ってことは、この5週間、調査はまったく進んでいなかったということ…？？
これまで、調査や審査が続いていると言っていたのはなんだったの…

挙げ句、この状況は変わる見込みが無いので、新しいアカウントを作ってはどうかと連絡がありました。
通常、複数のFacebookアカウントを利用することは規約違反になりますが、今回のようなケースではアカウントの作成が認められるということでした。

調査リクエストが却下されていると判明した後

この連絡が届いた後、一向に話が進まなくなってしまいました。
実際に調査リクエストがなされているのか、それともそれすらなされていないのか、Facebook側でなにが起こっているのか、なにを信用すると良いのか…

Meta社のサポート担当曰く、今回のケースはかなり特殊らしく…

サポートから担当部署へハッキング調査依頼をしているが、すべて却下されている。
依頼を繰り返しているが、未だ受け付けてもらえない。
アカウントは停止された状態のままデータベース上に残っているので、引き続き正規報告（ https://facebook.com/hacked/ ）をお願いしたい。
なお、本件に関してはその特殊性から、別のアカウント作成が認められることを確認している。
従来のアカウントが再開した際は、どちらかを完全に削除する必要があることに注意してほしい。
以上を持って、本件をクローズとしたい。

とのことでした。
いや、ツッコミどころが多すぎですが…

ハッキングされている事実は確認できているのに、その調査・対応依頼が受け付けてもらえないってどういうこと？
正規ルートで報告しようにも、名前やメールアドレスはもちろん、すべての情報が書き換えられているから、正規ルートでの報告もできないから困っているわけで。

この先、どうするか

いわゆる正規ルート（ https://www.facebook.com/hacked/ ）は、私の場合「連続使用が多すぎるので一時的に利用停止している」旨が表示されるのですが、Meta社のサポート曰く、利用するデバイスを変え、利用間隔を空けて、報告を続けて欲しいとのことでした。

という感じで、正直なところ、アカウント再開への道筋がまったく見えていません。
なんとかならないのか、あらためてサポートに確認してみましたが、届いた返信は以下でした。

今回の件、Meta Pro Teamではもうどうにもできないので、調査リクエストができるようになるまで自力で頑張ってくれ、ということのようです。

このままでは仕事はもちろん、友人関係にも著しい弊害が出てしまうので、暫定的なアカウントを作ろうと思っています。
ただ、これまでのアカウントを諦めるつもりも今のところは無いので、手を変え品を変えではありませんが、今後もハッキング報告とサポートへの連絡は続けようと思っています。

アメリカではアカウント再開まで半年以上かかったという例もあるようです。
その間、Facebook側には一切連絡が取れなかったとか。
それに比べると、私の状況はまだ良いのかも…？

というわけで、現在はまだアカウント再開に至っていませんが、この4ヶ月間の状況を書いておきました。
また状況が変わったら、こちらに書き加えていこうと思います。

乗っ取り被害発生から8ヶ月が経過しました。

こんにちは、この部分を書いているのは、2024年3月20日（水）です。
Facebookアカウントの乗っ取り被害に遭ってから8ヶ月が経過し、前回この記事を更新してから4ヶ月が経過しています。

この4ヶ月も大きく状況は変わりませんでしたが、先日とうとう「最終宣告」をされてしまいました。

検索結果から消えた登録メールアドレス

2023年11月21日に「新しいアカウトを作ってくれ」と連絡が来たあと、私は暫定アカウントを作っていました。
かつてFacebookでつながっていた方々に、少しずつ少しずつ、申請をポチポチ送る日々。
あまり一度に大量申請すると良くないかと考え「友だちかも」に出てきた順番に少しずつ増やしていきました。

その1ヶ月後、あらためて https://www.facebook.com/hacked/ で登録メールアドレスを検索し、対応を進めようとしたところ、このようなメッセージが表示されました。

No Search Results
（検索結果がありません）
Your search did not return any results. Please try again with other information.
（検索結果は見つかりませんでした。他の情報で再度検索してください）

もう1つの検索対象である電話番号は新しいアカウントに使用していたので、ここから先に進むことができなくなってしまい、あらためてMeta Pro Teamから最後に届いたメールに返信を送りました。
ただ、送られてくる回答は「ハッキング報告をしてくれ」の一点張り。
報告しようにも登録メールアドレスが見つからない状態なので困っているのに、どうしろと…。

2024年になり、あらためて「乗っ取り被害に遭っているアカウントのこと」「これまでの経緯」「電話番号は暫定アカウントに使用していること」を送ってみたところ、以下のような返事が届きました。

ここへ来て、私以外にも多くのアカウントで同様の現象となっていることを認めてくれました。
そしてシステムアップデートを待ってくれ、と…。
そしてこの返信には以下のように続いていました。

可能な限り引き続きサポートさせて頂きますので、ご状況を正確に把握するために下記情報のご提示をお願い致します。

１．現在のご状況の詳細をできるだけ詳しくお伝え頂ければ幸いです。
２．該当の状況が分かる最新のスクリーンショット

上記情報を確認次第24時間以内にお返事させて頂きます。
新たなご質問に関しましては、改めてお問い合わせ頂ければご対応をさせていただきます。

何度も繰り返し同じことを聞かれている…
とは言えここまで来たので、諦めずに連絡を行いました。
Meta Pro Teamからは、あらためて対応部署への依頼を行うと連絡がありました。

それが2024年1月11日のことでした。

Meta Pro Teamから返信が来なくなる…

2月に入り、その後どうなったかとメールを送ってみますが、返事が来ません。
それから数週間あけて連絡を入れてみますが、まったく返信が来なくなってしまいました。

1ヶ月以上も返信が来なくなってしまったので、あらためてInstagramからサポートに連絡をしましたが、届いたのは以下の内容でした。

いやだから…
Facebookアカウントが乗っ取り被害に遭って、アカウントが停止されて、Instagramとの連携も解除されちゃってるんですよ…
この人、ホントに公式サポートの人なのかという疑いすら芽生えてきました（苦笑）

もう何回目かわかりませんが、再度これまでの状況を伝えてみることに。
それに対する返信がこちら

私も心苦しいですが、お客様のために担当部署に何回も依頼をしてみましたが、何回も失敗になりました。
https://www.facebook.com/hacked/
只今のご案内できるのが上記のURLとおりですが、もしメールアドレスの連携がなくなりましたら追加の方法として下記のURLをご試すことでございますね。
https://www.facebook.com/login/identify
ぜひごためしくださいませ。

百歩譲って日本語があれなのは良いけれど、それもう諦めてません…？
なにか方法はないんですか…

そして最後の連絡

なぜ担当部署への連絡や調査依頼が失敗しているのか、理由を教えてもらえませんか

10年以上、Facebookを利用してきて、プライベートはもちろんビジネスにも利用してきました。
現在、弊社Facebookページの管理者も不在の状態で、アカウントを関連づけていたさまざまなサービスも利用できなくなっています。

自分でなにか過ちを犯したのならまだしも、一方的に乗っ取り被害に遭い、その理由も明らかにならずに解決ができないというのは理解できません。

以前のアカウントにアクセスさせてもらえるだけで良いんです。
必要なら身分証明書でもなんでも提出します。

私のアカウントがどうなっているのか、それだけでも教えてもらえませんか

何度でも言うけれど、私は被害者であって「復旧に尽力している側」じゃないのよ…
そしてその直後に届いたのがこちら

フィードバックと言われても…

署名活動とかできないのかな…

時を同じくして話題になったのがこちらのニュース

InstagramとFacebookアカウントがハッキングされ乗っ取りが爆増しているのにサポートが貧弱な件について41もの州司法長官の連合が運営元のMetaに対処を求める書簡を一斉に公表 - GIGAZINE

オンライン掲示板のRedditでは、アカウント乗っ取り被害を受けたユーザーに対し、最後の手段として地元の司法長官事務所に相談するようアドバイスすることがあり、実際に一部のユーザーは州の司法長官事務所が介入した結果、Facebookアカウントへのアクセス権限を取り戻せたことを報告しています。

日本でもFacebook乗っ取り被害に遭った人たちで署名活動とかしたら、Facebookジャパンへの対応・対策依頼とかできないのかな

「SNSなんて、そんなもんだろ」

と言う人もいるし、それもわかるけれど、運営側がそうだとしたら、とんでもない話なんじゃないかと。
世界中のあらゆる「データ」を取り扱う企業が、あれだけ慎重になっていることを、もう一度考えて欲しい。

ここまで現在の状況です。
またなにか変化があれば書き足しますが…これはさすがに厳しいのかな…と思っています。

GDPR対応もOK！「ウェブサイト向けCookie同意管理バナーツール」の導入と動作確認をしてみた。

2023-06-17T09:08:00Z

ども、どもども。
先日このブログで、「日本企業のウェブサイトに求められるCookie利用同意確認とCookieポリシーの設置」という記事を書きました。

日本企業のウェブサイトに求められる「Cookie利用同意確認とCookieポリシーの設置」 | www.ni4.jp

その記事にもあるとおり、日本国内のウェブサイトであっても、GDPRの適用対象となる場合や、改正個人情報保護法が定める「個人情報の第三者提供」を行うと認められる場合、ウェブサイト閲覧時にCookieを発行することに同意を得る必要があります。

GDPR以外へも対応が必要な場合や、ウェブサイト上でどのようなCookieを発行しているかが不明な場合などは、OneTrustなどのCMP（Consent Management Platform）を利用するのが安心かと思いますが、GA4＋GoogleTagManagerでアクセス解析等を実施しているだけのような場合には、ユーザーローカル社が無料提供している「Webサイト向けCookie同意管理バナーツール」の利用も選択肢の1つと思います。

そこで今回、このブログ記事では、ユーザーローカル社の「Webサイト向けCookie同意管理バナーツール」について、その導入方法と、導入した際のGA4+GoogleTagManagerの動作（Cookieの発行状況）について、まとめていこうと思います。

Webサイト向けCookie同意管理バナーツールのダウンロード

ユーザーローカル社のCookie同意管理バナーツールは以下からダウンロードできます。

Webサイト向けCookie同意管理バナーツール｜株式会社ユーザーローカル

ウェブサイトへアクセスして、フォームに必要事項を入力すると、ツールのスクリプトと設置資料（マニュアル）がダウンロードできます。

ダウンロードしたデータの中身

スクリプトの設置方法が詳しく記載されたマニュアルがあるので、記載内容のとおりに ulcc_tag.txt を編集しておきましょう。

GoogleTagManagerにCookie同意管理バナーツールのタグを登録する

こちらもマニュアルにあるとおり、既存のワークスペースに「新しいタグ」として、Cookie同意管理バナーツールのタグを登録します。

GoogleTagManagerへのタグ登録

タグを登録して「公開」したら、GoogleTagManagerが設置されているウェブサイトにアクセスして、Cookie同意管理バナーツールが表示されているか、確認してみましょう。

以下のようにCookie同意管理バナーツールが表示されていれば、設置は完了です。

バナーに表示されるテキストやデザイン（配色）も変更可能となっていて、設置するウェブサイトにあわせて細かく変更できます。
また、GA4以外のCookieを制御する方法や、オプトアウト（Cookie受入拒否へ変更）も用意されているので、マニュアルを確認することで、いろいろと対応できます。

Cookie同意管理バナーツールの動作確認

設置が完了したページで、Cookie同意管理バナーツールの動作を確認していきます。
今回は、Google Chrome ／ Safari の開発者ツールを使用して確認してみます。

同意確認ボタンで「同意する／同意しない」を選択していない状態

Google Chromeの開発者ツールで「Application」タブを開き、「Storage」にある「Cookies」で、確認するドメインを選択すると、発行されたCookieが表示されるようになります。
Safariでは、開発者ツールをで「Storage」タブを開き、左にある対象ドメインの「Cookie」をクリックすると、発行されたCookieが表示されるようになります。

Cookie同意管理バナーツールで「同意する／同意しない」のいずれも選択していない初期の段階では、以下のようにCookieが発行されていないことが確認できます。

Google Chrome の場合

Safari の場合

同意確認ボタンで「同意」を選択した場合

初期状態で「同意」した場合、_ul_cookie_consentの値がallow（許可）となり、GA4のCookieが発行されることを確認できます。

同意確認ボタンで「同意しない」を選択した場合

一方、「同意しない」を選択した場合は、_ul_cookie_consentの値がdeny（拒否）となり、GA4のCookieが発行されていないことを確認できます。

以上で期待する動作ができていることを確認できました。

Cookie同意管理バナーツールの使いどころ

ご覧いただいた通り、ユーザーローカル社のCookie同意管理バナーツールでは、同意する／同意しないの選択時に、GoogleTagManagerの動作を制御することで同意管理を実現しているようです。

そのため、GoogleTagManagerで管理していないもの（「GoogleTagManagerで設置したHTML＝ulcc_tag.txt」に記載されていないスクリプト）は、同意する／同意しないの選択に関わらず、通常通り実行され、Cookieを発行してしまうことになります。

先のとおり、GA4+GoogleTagManagerのみを利用している場合や、すべてのタグをGoogleTagManagerで管理している場合は問題ありませんが、Cookieの発行を細かく設定・制御したい場合や、複数の担当者でウェブサイトを管理・運営していて、Cookieを発行するタグが多岐にわたるような場合は、注意が必要となりそうです。

実際の導入にあたっては、CMPの利用とあわせて検討するのが良さそうですが、一般的なコーポレートサイト等であれば、ユーザーローカル社のCookie同意管理バナーツールはとても便利に利用できると思います。

ユーザーローカルさん、このようなツールを無料提供してくれて、ありがとうございます！

株式会社ユーザーローカル

最上部の写真は、UnsplashのPrateek Katyalが撮影した写真です。

日本企業のウェブサイトに求められる「Cookie利用同意確認とCookieポリシーの設置」

2023-05-25T10:24:00Z

ども、どもども。
先日、クライアント企業さんから、自社のウェブサイトにもCookie利用確認のボタンを設置したほうが良いだろうか？と相談を受けました。

Cookie利用確認のボタンの例

ここ数年でよく見かけるようになったこのボタン、EU加盟国で施行されたGDPRや、改正個人情報保護法への対応として設置されているものですが、どのようなときに必要となるかなど、明確に説明できるほど理解できていませんでした。

そこであらためて、GDPRのこと、改正個人情報保護法のこと、ウェブサイトでこのボタン（Cookie利用同意確認ツール）が必要になるケースを勉強し直したので、このブログにも残しておこうと思います。
だいぶ長くなってしまいましたが、一通り理解できたのかなと思います。
間違いなどがあったら、優しく指摘してもらえると喜びます！

GDPR対応で日本企業のウェブサイトに求められること

2018年5月25日に、欧州で施行されたEU一般データ保護規則（General Data Protection Regulation）のことを「GDPR」と呼びます。
EU域内の各国に適用される「個人情報を保護するための法令」ですが、日本企業でも適用範囲内になる場合があり、これに違反すると、最大で「該当企業における全世界年間売上の4％」または「2,000万ユーロ」のいずれか高い方が制裁金として課される場合があります。

GDPRとは？日本企業が対応すべき対策を考える｜セキュリティ対策コラム｜情報漏洩防止ソリューション秘文｜日立ソリューションズ

GDPRで個人情報として扱われるCookie（クッキー）とは

Cookieとは、ウェブサイトを閲覧した際に、ブラウザに一時的に保存されるユーザーの閲覧履歴などの情報で、訪問した日時や訪問回数などが含まれており、主に以下の用途に利用されます。

ウェブサイトへのログイン情報を保存する（ログインID/パスワード入力を省略）
オンラインショップで商品をカートに入れた情報を保存する（時間を空けて購入する場合に対応）
メールフォームなどで入力した情報を保存する（名前や住所などの入力を省略）

また、GoogleAnalyticsなどのアクセス解析ツールはもちろん、GA4とGoogleTagManagerを組み合わせて利用している場合もCookieを使用しており、GDPRではこのCookieが個人情報として保護する対象となるため、ウェブサイトで取得・利用するには閲覧者（ユーザー）の同意が必要になります。

GDPRで定められている個人情報の取り扱い

GDPRが適用となるウェブサイトで、Cookieを含む個人情報を取得・利用する場合は、以下の対応が必要となります。

企業情報や利用目的を明確にした上で、ユーザーに同意を求めること
- 連絡先など身元情報
- 処理の目的
- 第三者提供の有無
- 個人情報の保管期間
取得した個人情報は、ユーザーの求めに応じて対処可能であること
- ユーザーが個人データの削除を要求した場合に削除できること
- 個人データが侵害された場合ユーザーが迅速に知ることができること
取得した個人情報を適切に管理すること
- 監視、暗号化、匿名化などのセキュリティ要件を明確化すること
- 必要な期間以上の個人情報保持の禁止
- 大量の個人情報を扱う場合のデータ保護責任者を任命すること

日本企業はGDPRの対象となるか

一見すると、EU域内のウェブサイトにだけ関係しそうですが、日本企業のウェブサイトでも以下の条件を満たしている場合、GDPRの適用対象となります。

EU域内に子会社や支店、営業所などを有している
日本からEU域内に商品やサービスを提供している
EU域内から個人データの処理について委託を受けている

また上記に加え、ウェブサイト上でEU域内にいるユーザーの行動データを取得している場合も対象となります。

ウェブサイト上でCookieで得られる個人データを利用している場合
EU域内に個人データを扱うデータベースやサーバーが設置されている場合
ネット通販などでEU域内へ商品やサービスを販売している場合

なお「EU域内にいるユーザー」の定義は、EUを居住地にしているユーザーだけを対象にするわけではなく、短期出張などでEU域内に滞在している場合も「EU域内にいるユーザー」に含まれます。
つまり、EU域内に出張中の日本人も「EU域内にいるユーザー」に含まれるため、EU域内からのアクセスがあるウェブサイトは、日本企業のウェブサイトを含むすべてがその対象となります。

GDPRが適用となるウェブサイトで必要となる対応

GDPR適用対象となるウェブサイトでは、以下の対応が必要で、これは日本企業であった場合も同じです。

Cookieの取得・利用をユーザーから同意を得て行う（Cookie利用同意確認ツールの利用）
Cookieを取得・利用する企業の情報や利用目的を明確にする（Cookieポリシーの設置）
Cookieの削除方法などを案内する（Cookie利用同意確認ツールの利用/Cookieポリシーの設置）

改正個人情報保護法とCookieについて

2022年4月1日に施行された改正個人情報保護法では、Cookieおよびインターネットの閲覧履歴、IPアドレスなどが「個人関連情報」（それ単体では特定の個人を識別しないが、特定の個人に関する情報）に該当するとしています。

また、この個人関連情報は「個人情報に照合し個人情報となることが想定されるデータ」を指しているため、単体では個人情報として保護対象にはならなくとも、Cookieを含む個人関連情報を第三者に提供し、さらに第三者が個人関連情報を個人データとして取得することが想定される場合は、改正個人情報保護法のもと、その取得・利用にユーザーの同意が必要とされています。

なお、現状では日本国内向けウェブサイトにおいて、第三者提供に該当しない場合の罰則はないようです。

第三者提供の該当要件

例えば、GoogleAnalytics（GA4＋GoogleTagManager）等で、ウェブサイトのアクセス解析を実施している場合、解析タグで取得される閲覧履歴等は、Google社が直接ユーザーから閲覧履歴を取得することになるため、第三者提供には該当しないとされています。

参考：「個人情報の保護に関する法律についてのガイドライン」に関するQ&A
https://www.ppc.go.jp/files/pdf/2304_APPI_QA.pdf（Q8-10）

他方、ターゲティング広告を掲出している場合でかつ、以下に該当する場合は、第三者提供に該当します。

広告配信のために提供されるデータと、自社保有している個人のデータを紐付けている場合
自社ウェブサイトで取得したデータを提供した先で、提供先が保有する個人のデータを紐付ける場合

なお、個人情報を保有していないウェブサイト（会員登録などがないウェブサイト）で、Cookieなどの個人関連情報のみを用いてターゲティング広告を掲出する場合は、第三者提供に該当しません。

ターゲティング広告主として確認すべき内容

よって、自身（自社）がターゲティング広告主である場合には、改正個人情報保護法に対応すべく、以下の点について確認を行う必要があります。

提供している、またはされている個人関連情報やデータの内容、種類
提供先での個人関連情報の利用状況
プライバシーポリシーに記載されているCookieの利用目的、同意取得方法

GDPR適用対象外の日本企業ウェブサイトで、Cookie利用同意確認は必要か

以上の通り、GDPR適用対象外であったとしても、改正個人情報保護法が定める「個人情報の第三者提供」を行うと認められる場合、Cookie利用同意確認が必要となります。

なお、以下のように同意確認が不要となるCookieもあります。

ウェブサイトの表示言語設定などを保存するもの
オンラインショップで買い物カゴに入れた商品を保存するもの
ユーザーのログイン状態を保存するもの　など

Cookie利用同意確認ツールについて

Cookieを取得・利用することについて、ユーザーに同意を求める際、それに同意が得られるまでCookieを取得することはできないため、アクセス解析ツールなどを導入している場合も、この同意が得られるまではそれが動作しないように制御する必要があります。
そこで利用されるのが、Cookie取得同意確認ツールです。

Cookie利用同意確認ツールとは

ウェブサイトへアクセスした際、画面下部などに表示されるCookie取得への同意確認を得るツールを指します。
閲覧するユーザーが、Cookieの取得・利用（受け入れ）に同意しない場合、それを利用した機能が動作しないように制御することができます。

ソニーグループポータル https://www.sony.com/ja/

Cookie利用同意確認ツールに必要な機能

同意確認ツールには、以下の機能が求められます。

明確な同意がない場合に、これを「みなし同意」としてCookieを取得しない
Cookieの取得に同意しなかった場合もウェブサイトを閲覧可能とする（ゼロCookieロード）
Cookie取得に同意したユーザーが任意のタイミングでそれを拒否できる（オプトアウト）
ウェブサイトで取得したCookieを、その利用方法ごとに拒否できる（オプトアウト）

たまに見かける「同意しないとウェブサイトへ進めない」ものや、「ボタンがあるだけでCookieを制御していない」ものは、同意確認ツールとしては意味のないものとなります。

Cookie利用同意確認ツールの種類

ユーザーローカル社が無料で提供しているCookie同意管理バナーは、GoogleTagManagerとあわせて利用することで、これに同意しない場合のウェブサイト閲覧も可能としつつ、適切なCookieの管理が可能となります。
GoogleTagManagerの動作を制御するものとなるため、Cookieを利用するサービスごとにこれをコントロールすることはできませんが、GA4のみの利用など、比較的少ないCookieを管理する場合に適しています。

Webサイト向けCookie同意管理バナーツール｜株式会社ユーザーローカル

また、さまざまなベンダーが有料で提供しているCMP（Consent Management Platform）を利用すると、その利用目的ごとにCookie取得・利用をコントロールするなど、細かな設定が可能になります。
GDPRだけなくグローバルな対応が必要となる場合や、比較的多くのCookie（計測タグなど）をコントロールする場合に適しています。

OneTrustクッキー同意管理バナー

GDPRや改正個人情報保護法における個人情報の第三者提供が認められる場合、これらのツールを利用する必要があります。

改正電気通信事業法とCookieポリシーの設置

2023年6月に施行される改正電気通信事業法では、Cookieを含む閲覧履歴などの利用者情報を、第三者に提供している場合（個人情報との紐付けを問わない）や、ターゲティング広告などを運用している場合に、以下のいずれかの対応が必要となります。

ウェブサイト上での通知・公表（Cookieポリシーの設置）
利用者本人の同意を得たうえでのCookie利用（Cookie利用同意確認ツール）
一度同意した場合も、後から拒否・削除できる仕組みの導入（オプトアウト）

Cookieなどの個人関連情報と個人データの紐づけを問わないため、例えば、GoogleAnalyticsなどのアクセス解析ツールを利用している場合も対象となり、最低限の対応としてCookieポリシーの設置・プライバシーポリシーの見直しが望ましいと考えられます。

Cookieポリシーの掲載例

このような状況から、日本企業のさまざまなウェブサイトでも、Cookieポリシーを明文化するようになってきました。

まとめ

GDPRと改正個人情報保護法、Cookie利用同意確認を可能とするツールについて、私が調べた内容をまとめてみました。
「あまり関係ないのかな？」と感じている方も多いと思いますが、漠然としたイメージだけでなく、自社に関係しているか、あるいはどのような対応を取るべきかを、あらためて確認しておく必要があるように思います。

GDPRでは、Cookie利用同意確認ツールの導入に加え、「企業情報や利用目的、個人データの削除方法」も明記したプライバシーポリシー（Cookieポリシー）の見直しが必要となり、また、GDPRや改正個人情報保護法の第三者提供に該当せず、Cookie利用同意確認ツールの導入が不要なウェブサイトでも、改正電気通信事業法への対応、あるいは企業コンプライアンス・社会的責任として、プライバシーポリシー（Cookieポリシー）上で、Cookieの利用目的や個人関連情報の利用目的などを明示化しておくのが望ましいと考えています。

なお、プライバシーポリシー（Cookieポリシー）の具体的な内容については、法律の専門的な知識を必要とする場合もあるため、専門家へのご相談を含め検討ください。

以上、私が勉強した内容になります。
参考になれば幸いです！

免責事項

GDPRおよび改正個人情報保護法、CMPなどについて、できる限り正確な情報を提供するように努めておりますが、掲載内容の正確性・完全性・信頼性・最新性を保証するものではございません。
誤りが確認できた点については、随時修正を行いますが、この記事に掲載された内容によって生じた損害等の責任は負いかねますのでご了承願います。

最上部の写真素材は、UnsplashのVyshnavi Bisaniが撮影した写真です。