www.ni4.jp
tag:www.ni4.jp,://69511
2023-12-16T02:54:32Z
北海道札幌市のウェブサイト制作会社 株式会社ジャクスタポジションの代表取締役 西山の個人ブログ。日々のネタを投下中。 MovableType.net
Movable Type カスタムブロック利用時の15万文字制限への対処アイディア
tag:movabletype.net,2003:post-2543411
2023-12-15T00:26:00Z
2023-12-16T02:54:32Z
凝ったカスタムブロックを作るようになって「壁」を知り、そもそも…と思い直した話
ジャクスタポジション 西山
<p><img src="https://www.ni4.jp/.assets/word-count-problem_ogp.jpg" alt="" width="1200" height="630" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>ども、どもども、西山です。<br>この記事は、<a href="https://adventar.org/calendars/8999">Movable Type Advent Calendar 2023</a>、15日目の記事です。</p><p>このブログでも数多く取り上げているMovable Typeのブロックエディタ、皆さん利用してますか?<br>私…というか<a title="株式会社ジャクスタポジションのウェブサイト" href="https://www.juxtaposition.co.jp/">弊社</a>では、めちゃくちゃ使ってます。</p><p>ブロックエディタが利用できるようになって以降、弊社はもちろん弊社クライアントからも大好評で、ウェブサイトの運営がかなり楽しくなっています。</p><p><strong>ただ、楽しくなるに連れ、少しづつ凝ったことをしたくなるのが人情…</strong></p><p>今年公開になったウェブサイトでもカスタムブロックをたくさん作って、とても更新しやすいウェブサイトができました。<br>…といいたいところですが、実はちょっと困ったことがありました。</p><p>それが今日のテーマ<strong>「カスタムブロックの15万文字制限」</strong>の問題です。</p>
<h2>カスタムブロックの15万文字制限とは</h2><p>例えば、こんな感じのアコーディオンで開閉するコンテンツがあったとします。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/word-count-problem_01.png" alt="" width="1280" height="723" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>アコーディオンが閉じた状態</figcaption></figure><p>この黒いバーの部分をクリック(タップ)することでアコーディオンが展開するボタンになっています。<br>クリックすると以下のようなカタチで開きます。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/word-count-problem_02.png" alt="" width="1280" height="723" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>アコーディオンが開いた状態</figcaption></figure><p>この部分はカスタムブロックで「アコーディオンメニュー」という親ブロックを作り、その中に「アコーディオンメニュー(コンテンツ)」という子ブロックを含むように作られています。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/word-count-problem_03.png" alt="" width="1280" height="689" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>カスタムブロック「アコーディオンメニュー」を利用した際のイメージ</figcaption></figure><p>これを使って、1つのウェブページ内に複数のブロック(ここではアコーディオンメニューブロックと呼びます)を設置するウェブページを作りました。<br>HTMLを書こうと思うと、なかなかしんどい数(トータル38個)ですが、ブロックエディタなのでサクサクと入力が進みます。</p><p>ところが、一通り入力を終えて保存しようとしたところ、<strong>「本文と続きはあわせて15万文字以内で入力してください」</strong>とエラーが出てしまいました。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/word-count-problem_04.png" alt="" width="1280" height="540" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>15万文字…?(汗)</figcaption></figure><p>状況がよくわからないまま、ブロックを1つ削っては保存を繰り返したところ、7〜8個以上のアコーディオンメニューブロックを保存しようとしたところで、このエラーが発生することがわかりました。</p><p>全部で38個を入力しようとしているのに、<strong>ぜんぜん足りない(汗)<br></strong>というか、7〜8個程度のブロックで15万文字も入力している??</p><p>そこで、素のHTMLでどれくらいの文字数になるのか確認したところ、全38個のブロックでも9.5万文字程度とわかりました。<br>単純計算だと、8個のブロックで2万文字程度しか保存していないのに、このエラーが出たことになります。</p><p>なにが原因かを確認していくと、1つの可能性を見つけました。</p><p>これ、なんだかわかりますか?</p><p><img src="https://www.ni4.jp/.assets/word-count-problem_05.png" alt="" width="1280" height="549" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>実はこれ、1つのアコーディオンメニューブロックを保存する際に<strong>実際に保存されているコード</strong>で、カスタムブロックの構造や、入力しているHTMLなどをJSON形式(?)で保存しているようです。</p><p>なにか適当なカスタムブロックを「コピー」して、テキストエディタ等に貼り付けると確認できると思います。<br>参考:<a href="https://movabletype.net/2022/07/block-editor.html">ブロックエディタの機能強化を行いました(2022.07.14)</a></p><p>そしてよく見ると、<strong>カスタムスクリプトで加工しているHTMLがすべてエンティティされている</strong>のがわかります。</p><pre><code class="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;</code></pre><p>おそらくカスタムブロックのプレビューを表示したり、入力内容を再編集したりするためにこのようなカタチで保存する必要があるのだと思いますが、この影響で、<strong>実際に出力したいHTMLよりもデータとして保存する文字数が増えている</strong>ようです。</p><p>1つのアコーディオンメニューブロックで実際に出力したいHTMLがおよそ2,500文字であるのに対し、保存される<strong>JSONデータはおよそ2万文字</strong>ありました。</p><p>そのため、<strong>アコーディオンメニューブロックを7つ保存した時点でJSONデータは14万文字となり、8個めで15万文字を超える</strong>ことになります。<br>よって、15万文字制限はこのJSONの影響じゃないかなと考えました。</p><p>なんとなく原因がわかったので、カスタムブロックやカスタムスクリプトを見直すことも考えましたが、<strong>納期まで時間がない…</strong><br>そこでひとまず、管理画面にHTMLコードをそのまま貼り付けることで凌ぐこととしましたが、これではせっかくのブロックエディタが活用できないので、なにか良い方法はないかと考えました。</p><h2>15万文字制限を回避するアイディア</h2><p>カスタムブロックの構造やカスタムスクリプトの中身を見直すことで解消できるかもと思いつつ、大幅な文字数削減にはならない気がしたので、他の方法を探していたところ、思い出したのが、<a href="https://movabletype.net/tags/2020/06/MTBlockEditorBlocks.html">MTBlockEditorBlocks</a>タグです。</p><p>以前、このブログでも紹介したとおり、このタグを使用すると、ウェブページ内にテンプレート・モジュールを読み込むことが可能となります。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.ni4.jp%2F2020%2F10%2F12-183100.html" title="【MovableType.net】同じフォルダに含まれる下層ページをウェブページ内で一覧表示するカスタムブロックを作ってみた | www.ni4.jp" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://www.ni4.jp/2020/10/12-183100.html" target="_blank">【MovableType.net】同じフォルダに含まれる下層ページをウェブページ内で一覧表示するカスタムブロックを作ってみた | www.ni4.jp</a></iframe><p>つまり今回の場合、アコーディオンメニューブロックを1つずつ下層ウェブページで登録し、親のウェブページからは下層ウェブページのHTMLを読み込む方法を考えてみました。</p><p>これなら、親のウェブページで大量のJSONデータを保存することはなくなるはずです。</p><h3>手順1:下層フォルダを作成</h3><p>まず、各アコーディオンメニューブロックを登録していく下層ウェブページを格納するフォルダを用意します。<br>今回は7つのカテゴリ(分類)が必要だったので、以下のようにフォルダを作りました。</p><p><img src="https://www.ni4.jp/.assets/word-count-problem_06.png" alt="" width="1280" height="329" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><h3>手順2:カスタムブロックを作成</h3><p>続けて、特定のフォルダに入っているHTMLを読み込むためのカスタムブロックを作ります。<br><a href="https://www.ni4.jp/2020/10/12-183100.html">先ほどの記事</a>にあるとおり、以下のように作成しました。</p><p><img src="https://www.ni4.jp/.assets/word-count-problem_07.png" alt="" width="1280" height="763" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><h3>手順3:ウェブページのテンプレートを編集</h3><p>ウェブページのテンプレートにある<mt:PageBody />部分を以下のように書き換えます。</p><pre><code class="html"><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></code></pre><p>カスタムブロック「治験内容」を使用すると、テンプレート・モジュール「治験内容」の内容を読み込みつつ、カスタムブロックで選択したオプション名(フォルダ名)がfolder_labelにセットされます。</p><p>カスタムブロックとテンプレート・モジュールの名前は分けるべきでしたね…</p><h3>手順4:テンプレート・モジュールを作成</h3><p>テンプレート・モジュール「治験内容」を以下の内容で作成します。</p><pre><code class="html"><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></code></pre><p>このテンプレート・モジュールが読み込まれたとき、カスタムブロックで選択した「オプション名」と同じ名前の下層フォルダに含まれるウェブページの<mt:PageBody />が出力されます。</p><h3>手順5:下層ウェブページにアコーディオンメニューブロックを設置</h3><p>下層フォルダに格納するウェブページ(アコーディオンメニューブロックが設置されるページ)を作っていきます。</p><p><img src="https://www.ni4.jp/.assets/word-count-problem_08.png" alt="" width="1280" height="763" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>一通り下層ページを作成すると、以下のようにウェブページが出来上がりました。</p><p><img src="https://www.ni4.jp/.assets/word-count-problem_09.png" alt="" width="1280" height="640" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><h3>手順6:親ページでカスタムブロックを設置</h3><p>最後に親ページでカスタムブロック「治験内容」を使用して、テンプレート・モジュールを読み込みます。</p><p><img src="https://www.ni4.jp/.assets/word-count-problem_10.png" alt="" width="1280" height="550" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>ここでは「悪性リンパ腫」というカテゴリだけですが、同じようにそれ以外のカテゴリも作っていくと、親ページの完成となります。</p><h2>親ページの文字数はどうなったか</h2><p>親のウェブページでは、モジュールを読み込むためのカスタムブロック(274文字程度)のみを設置するため、全7カテゴリあっても、2,000文字程度までダイエットすることができました!</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/word-count-problem_11.png" alt="" width="1280" height="40" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>カスタムブロック「治験内容」に保存されるJSONの中身(悪性リンパ腫のカテゴリ選択時)</figcaption></figure><p>これで15万文字制限を回避できそうです。</p><h2>留意点</h2><p>MovableType.netでは、すべてのコンテンツをsitemap.xmlに自動出力するので、今回作成した下層ウェブページがどこからもリンクされていなかったとしても、sitemap.xmlには記載されてしまいます。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmovabletype.net%2Fsupport%2Fdesign%2Fsitemap.html" title="サイトマップの利用について - マニュアル | MovableType.net" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://movabletype.net/support/design/sitemap.html" target="_blank">サイトマップの利用について - マニュアル | MovableType.net</a></iframe><p>今回のBlockEditorBlocksを使ったテンプレート・モジュールの読み込みを利用するアイディア、なかなか良いんじゃないかなと思いましたが、<strong>公開予定の無いページもGoogleさんに拾われる可能性がある</strong>ことだけは留意が必要かなと思います。<br>今回は、仮に下層ウェブページにアクセスしてもナビゲーション等が通常通り表示されるので大きな問題はないと判断していますが、場合によってはこれらのページだけ、少し加工する必要があるかもしれませんね。</p><h2>最後に</h2><p>今回も3年前の自分のブログ記事に助けられました。<br>アウトプット、とても大切…(笑)</p><p>ウェブページで保存できる文字数が15万文字に制限されている理由はわかりませんが、今後、コンテンツを作っていく際に同じ状況になった場合はこのアイディアが活かせそうです。</p><p>また、今回の対応を取っていて思ったのですが、そもそそも<strong>1ページ内に38個ものアコーディオンを設置するようなケース</strong>で、<strong>カスタムブロックを38個並べる</strong>のは、<strong>機能としては良くても、編集・更新時にはなかなか厳しい</strong>です(苦笑)<br>カスタムブロックをよく利用されている方であればわかると思いますが、途中でどこの入力欄を使用したらいいのかが分かりにくくなることもしばしば。<br>…というわけで、カスタムブロック利用時は、それを操作する際のことも考えて、あらかじめ上手く設計しておきたいですね(自戒)</p><p>あと、今回はMovableType.netでのみ確認をしていますが、この15万文字制限がMovableType.netの仕様なのか、ソフトウェア版やクラウド版でも同じなのか、その辺りも気になりますね。</p><p>以上、Movable Type カスタムブロック利用時の15万文字制限への対処アイディアでした!<br>明日からの<a href="https://adventar.org/calendars/8999">Movable Type Advent Calendar 2023</a>もお楽しみください。</p><p>サムネイル画像に使用しているのは、<a href="https://unsplash.com/ja/%E5%86%99%E7%9C%9F/%E7%99%BD%E3%81%A8%E9%BB%92%E3%81%AE%E7%B4%99%E3%81%AE%E3%83%AD%E3%83%83%E3%83%88-_dAnK9GJvdY?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Unsplash</a>の<a href="https://unsplash.com/ja/@anniespratt?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Annie Spratt</a>が撮影した写真です。</p>
MTDDC Meetup TOKYO 2023に参加してきました!
tag:movabletype.net,2003:post-2528849
2023-11-19T07:30:00Z
2023-11-19T13:19:29Z
4年ぶりのオフライン開催の今回、スピーカーや実行委員会など盛りだくさんで楽しんで来ました。
ジャクスタポジション 西山
<p><img src="https://www.ni4.jp/.assets/mtddc2023_ogp.jpg" alt="" width="1200" height="630" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>ども、どもども。<br>ご無沙汰ブログです、こんにちは。</p><p>去る11月11日(土)、4年ぶりのオフライン開催となった<a href="https://mtddc2023.mt-tokyo.net/">MTDDC Meetup TOKYO 2023</a>に参加してきました。<br>会場は、東京ガーデンテラス紀尾井町にあるLINEヤフー株式会社のセミナールーム。<br>今年も150名近くの方が会場に集っていて、久しぶりにイベントの楽しさを実感できる1日となりました!</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmtddc2023.mt-tokyo.net%2F" title="MTDDC Meetup Tokyo 2023【11/11(土)開催】" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://mtddc2023.mt-tokyo.net/" target="_blank">MTDDC Meetup Tokyo 2023【11/11(土)開催】</a></iframe><p>今日のブログ記事は、このイベントの参加レポートになります!<br>ブログを書くまでがMTDDDC、というわけで最後までお付き合いください。</p>
<h2>初めてのノベルティスポンサー</h2><p>今回のイベントで初めて、ノベルティスポンサーになりました。<br>イベント当日に配布された資料や、ノベルティを持ち歩くために使用されるバッグ。<br>弊社ロゴ入りで作成したのですが、思っていたよりもシックな雰囲気でいい感じの仕上がりに満足でした!</p><p>参加者の方々が、これを片手に会場内を歩いているのを見ると、とてもいい感じでしたよ。</p><p><img src="https://www.ni4.jp/.assets/mtddc2023_01.jpeg" alt="" width="1280" height="960" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>ちなみにこのバッグ、結構な枚数が余ったので、今後は弊社資料などを配る際にも使おうと思っています(笑)<br>もし欲しいという方がいれば、ご連絡くださいw</p><h2>セッションを担当</h2><p>また、私は今回もMovable Typeトラックでのセッションを担当させてもらいました。<br>準備に時間が取れず苦戦したのですが、結果的にいい感じの30分セッションができたのかなと思います。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/mtddc2023_02.jpg" alt="" width="1280" height="853" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>カメラマンの加藤さんに撮ってもらった写真</figcaption></figure><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmtddc2023.mt-tokyo.net%2Fspeaker%2Fmt02.html" title="西山 泰史 氏|Movable Typeトラック 14:20 - 14:50|MTDDC Meetup Tokyo 2023【11/11(土)開催】" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://mtddc2023.mt-tokyo.net/speaker/mt02.html" target="_blank">西山 泰史 氏|Movable Typeトラック 14:20 - 14:50|MTDDC Meetup Tokyo 2023【11/11(土)開催】</a></iframe><p>当日は、20名ちょっとくらいの方が、私のセッションに参加してくれていました。<br>初めてMovable Typeを知った人、またはこれまで特定の製品ラインナップに偏って利用してきた方などを対象にセッション内容を組み立てましたが、聴講いただいた方からは好評をいただけたので、ホッとしています。</p><p>当日のスライド資料は<a href="https://speakerdeck.com/nishi_yama/hazimetenomovable-type-zerokaranoshi-mefang-xuan-bifang">Speakerdeck</a>で公開しています。</p><iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/a755f42ca691420db6d84f92eada783a" title="はじめてのMovable Type 〜ゼロからの始め方・選び方〜" allowfullscreen="true" style="border: 0px; background: padding-box padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 100%; height: auto; aspect-ratio: 560 / 315;" data-ratio="1.7777777777777777"></iframe><h2>MT東京の実行委員会に参加</h2><p>そして今回は、初めてMT東京の実行委員会にも参加させてもらいました。<br>当日はスタッフとして、会場づくりとか来客誘導、打ち上げの幹事なんかをさせてもらいました。<br>オフラインイベント自体4年ぶりだし、なんだかこう「リアル開催している感」がとてもあってよかったです(笑)</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/mtddc2023_03.png" alt="" width="1280" height="495" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>MTDDC Meetup TOKYO 2023 実行委員会メンバー</figcaption></figure><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/mtddc2023_04.jpg" alt="" width="1280" height="720" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>懇親会の途中、宮永さんとなぜか2ショット写真を撮ってもらったときの写真(笑)</figcaption></figure><h2>久々のオフラインイベントはやはり楽しかった</h2><p>4年ぶりの開催ということで、私を含む弊社メンバー3名で参加した今回。<br>イベント前夜祭や、メンバーとの食事、イベント当日はもちろん、その打ち上げまで、とても楽しめた3泊4日でした。</p><p>今回は当日スタッフなどの都合もあり、セッションへの参加はほぼできませんでしたが、それでも十分にイベントを楽しめました。<br>やはり年に数回はこんな感じのイベント参加をしていきたいですね。</p><p>来年開催の<strong>MTDDC Meetup TOKYO 2024で実行委員長</strong>を務めることにもなりましたので、来年はできる限り全国のいろいろなコミュニティに参加したいなと思っております。</p><p>Movable Type コミュニティの皆さん、来年もよろしくお願いします!</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/mtddc2023_05.jpeg" alt="" width="1280" height="720" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>羽田空港「又こい家」のまぐろ寿司</figcaption></figure>
Facebookが不正アクセスで乗っ取られ、アカウント停止処分を受けました。
tag:movabletype.net,2003:post-2437304
2023-07-28T23:55:00Z
2024-03-20T05:05:59Z
Facebookから忽然と姿を消した私に、今、起こっていることをまとめた話。
ジャクスタポジション 西山
<p><img src="https://www.ni4.jp/.assets/fb_hacked_ogp.jpg" alt="" width="1200" height="630" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>ども、どもども。<br>…と、いつも通りな感じで書き始めましたが、<strong>心中はいつもどおりではありません…!</strong></p><p>実は、7月21日(金)の深夜に、10年以上利用していた<strong>Facebookアカウントの乗っ取り被害</strong>に遭い、それ以降、<strong>Facebookにまったくアクセスできない状況が続いている</strong>のです。</p><p>WEB関連の仕事していて、なんなら「コンサルティング業務」なんかもやっている私ですが、大変お恥ずかしい話ながら、<strong>何をしていてもやられるときはやられる</strong>んだな、と。<br>今は「まさか自分が…」という気持ちで、心がかなりざわついております。</p><p>少し気持ちの整理ができてきたので、不正アカウントがあったときのことから、アカウントが停止された後になにをしているかなど、この記事でまとめて行こうと思います。<br>この記事を書き始めた7月26日(水)現在、まだ復旧の目処は立っていませんが、進捗があり次第、追記していくカタチで残していきたいと思います。</p>
<h2>相次ぐ不正アクセスアラートとアカウントロック</h2><p>ことの発端は、7月21日(金)の14時28分の出来事でした。<br>この画像は、弊社Slackに投稿した際のものです。</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_01.png" alt="" width="1280" height="400" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>14時28分から、たびたび不正アクセスアラートがメールで入り、その都度、アカウントがロックされる状態が続きました。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/fb_hacked_02.png" alt="" width="838" height="558" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>アメリカ時間だから?なのか7月20日になっています。</figcaption></figure><p>ただこのときは仕事中だったこともあり、すぐに対処することができました。<br>上記の「スタート」をクリックして進むと、アカウントのスキャンが始まって、アクティビティチェック(何を投稿したかなど)の後、パスワード変更までを実施できます。</p><p>不正アクセスが検知されたのは4〜5回だったと記憶しています。<br>ただ、その後はアラートが来ることもなく、<strong>2段階認証も設定しているし、パスワードもその都度変更していた</strong>ので、ここで不正アクセスラッシュは終わったんだなと思っていました。</p><h2>再び届く不正アクセスアラート</h2><p>21日(金)の夜は友人と食事に出かけていたのですが、だいぶお酒も入った23時32分にまた不正アクセスアラートがありました。<br>そしてこのときは外出先だったこともあり、そのメールに気がつくことができませんでした。</p><p>自宅に帰り、そのメールに気がついた私は、夕方に対処したのと同じく「アカウントのセキュリティを保護しましょう」というリンクをクリックしました。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/fb_hacked_03.png" alt="" width="1280" height="494" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>「何者かがアカウントにアクセスした可能性があります」という件名の不正アクセスアラートメールの内容</figcaption></figure><p>しかし、このリンクをクリックして、事態の深刻さに気が付きます…<br>リンク先で表示されたのは、夕方に表示された「アカウントがロックされました」ではなく、以下の内容でした。</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_04.png" alt="" width="1280" height="628" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>え…アカウント停止?と思いましたが、この日はお酒が入っていた深夜だったこともあり、翌日に落ち着いて対処すればなんとかなるのでは?と考え、そのまま就寝しました。</p><h2>ハッキングされるまでの時系列</h2><p>不正アクセスアラートが届いてから、乗っ取りが完了したと思われる通知までは、以下のような流れでした。</p><div class="scroll"><table style="width: initial;"><colgroup><col style="width: 18.6578%;"><col style="width: 48.5074%;"><col style="width: 32.8406%;"></colgroup>
<tbody>
<tr>
<th>メールの受信時刻</th>
<th>メールの件名</th>
<th>内容</th>
</tr>
<tr>
<td>23:32</td>
<td>何者かがアカウントにアクセスした可能性があります</td>
<td>セキュリティ保護のため、終了するまであなたのページはFacebookで表示されません。</td>
</tr>
<tr>
<td>23:33</td>
<td>Chrome(Windows)のログインアラート(ログイン確認)</td>
<td>普段使用しているものとは異なるデバイスや場所からの不審なログインが検知されました。あなたが実行したものですか?</td>
</tr>
<tr>
<td>23:39</td>
<td>メールアドレスを削除しましたか?</td>
<td>メールアドレス <strong><登録アドレス1></strong> があなたのFacebookアカウントから削除されました。</td>
</tr>
<tr>
<td>23:39</td>
<td>電話番号を削除しましたか?</td>
<td>電話番号<<strong>000-0000-0000</strong>>があなたのFacebookアカウントから削除されました。</td>
</tr>
<tr>
<td>23:40</td>
<td>たった今メールアドレスを追加しましたか?</td>
<td>メールアドレス<strong>gaumerdanyelle@hotmail.com</strong>があなたのFacebookアカウントに追加されました。</td>
</tr>
<tr>
<td>23:41</td>
<td>Facebookアカウントのリカバリーコード:<strong>******</strong></td>
<td>Facebookパスワードのリセットがリクエストされました。<br>以下のパスワードリセットコードを入力してください。</td>
</tr>
<tr>
<td>23:41</td>
<td>パスワードをリセットしましたか?</td>
<td>あなたのパスワードがリセットされたことをお知らせします。</td>
</tr>
<tr>
<td>23:42</td>
<td>メールアドレスを削除しましたか?</td>
<td>メールアドレス<<strong>登録アドレス2</strong>>があなたのFacebookアカウントから削除されました。</td>
</tr>
<tr>
<td>23:45</td>
<td>何者かがアカウントにアクセスした可能性があります</td>
<td>セキュリティ保護のため、終了するまであなたのページはFacebookで表示されません。</td>
</tr>
</tbody>
</table></div><p>通知があったのは以上です。<br>わずか13分、私のログイン情報がすべて削除されるまでは、<strong>たった10分間の出来事</strong>だったようです。</p><p>23時33分の不正アクセスアラートで「Chrome(Windows)」となっていますが、私は基本的にMacからしかアクセスしていないので、これに気がついていれば、あるいは防げたのかもしれませんが…今となってはわかりません。<br><strong>2段階認証を設定しパスワードをかなり強固なものにしていたという安心感</strong>からか、それともお酒が入っていたからか、いずれにしても、この時点で気がつけなかったのが悔やまれます。</p><h2>翌日以降に行ったこと</h2><p>不正アクセスがあった翌日22日朝から、さまざまな方法でアカウント再開を試みました。</p><h3>本人確認書類のアップロード</h3><p>まずは、通知が来ていたメールアドレスを削除したという内容に「私は変更していません」と報告する対応から始めました。</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_10.png" alt="" width="766" height="351" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>表示されるのは以下のような画面。<br>上記のとおり、<strong>使用しているデバイスはWindows Chromeであるにも関わらず、「以前Facebookにアクセスしたデバイスから実行されました」というメッセージ</strong>が…</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_11.png" alt="" width="1280" height="476" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>当然、私ではないので「他の人です」を選択して手続きを進めるのですが、次画面で表示される「ログインコード」を入力しても、<strong>「入力されたログインコードは携帯電話に送信されたものと一致しません。コードをご確認の上、もう一度実行してください」</strong>と表示されます。</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_12.png" alt="" width="1280" height="354" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>そりゃそうですよね…<br><strong>すでに電話番号も変更されている</strong>ので、<strong>2段階認証アプリを入れている端末が違う</strong>から正しいわけがありません…。</p><p>そこで、その下にある<strong>「他の方法で本人確認を行う必要がありますか?」</strong>から手続きを進めます。</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_13.png" alt="" width="1280" height="617" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>他のデバイスから承認というのもありますが、<strong>そもそもログインできないから困っている</strong>わけで、別のブラウザや携帯電話からログインしてと言われても…というわけで「他のオプション」を開きます。<br>ここでやっと、<strong>本人確認書類のアップロードに移動</strong>が選択できるようになります。</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_14.png" alt="" width="1280" height="655" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>次画面で「次へ」を選択して、まずはメールアドレスを入力して認証コードを送信します。</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_15.png" alt="" width="1280" height="655" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>メールで届いた認証コードを入力して「次へ」をクリック</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_16.png" alt="" width="1280" height="641" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>次画面の本人確認書類の種類を選択する画面では「運転免許証」を選択しました。<br>(他に適当なのが見当たりませんでした)</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_17.png" alt="" width="1280" height="771" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>次画面以降で、ウェブカメラを使用して運転免許証を撮影します。</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_19.png" alt="" width="1280" height="858" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>撮影後「次へ」をクリックしましたが、<strong>本人確認書類の写真に問題があります</strong>と表示され、次のステップに進むことができません…</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_20.png" alt="" width="1280" height="594" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>最初は、撮影した内容がはっきり判別できない、あるいは4つ角のどれかが欠けているのかと、なんども繰り返し撮影を試みましたが、一向に先へ進む気配が無いので、この方法は一旦諦めることに。<br>この<strong>「現在この機能はご利用いただけません」</strong>というメッセージが気になりますね…</p><p>ただ、Facebookに個人用アカウントを誤って削除されたと思われる場合は、この「本人確認書類」を提出することでアカウントが再開できたという情報が多かったので、別の方法を試してみることにしました。</p><h3>停止された個人用アカウントの再審査リクエスト</h3><p>次に、<a href="https://ja-jp.facebook.com/help/103873106370583">個人用Facebookアカウントが停止された</a>場合に利用できる<strong>「審査リクエストフォーム」</strong>を使用してみました。<br>ここにアクセスして、<strong>自分のアカウントが誤って停止されたと思われる場合</strong>にある「こちらのフォームを使用して審査をリクエスト」へ進みます。</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_21.png" alt="" width="1010" height="237" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>次画面で表示されるフォームに「アカウントに登録されている氏名」を入力し、「ID(運転免許証)」をアップロードしましたが、ここでは以下のような内容が表示されました。<br><br></p><p><img src="https://www.ni4.jp/.assets/fb_hacked_22.png" alt="" width="1280" height="695" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>フォームには<strong>「Facebookコミュニティ規定違反によりアカウントが停止されている場合にのみこのフォームを送信してください」</strong>とあるのに、<strong>「この決定はすでに審査済みであり、撤回することはできません」</strong>とはこれいかに…</p><h3>別の画面から本人確認書類をアップロード</h3><p><strong>とても納得できるものではない</strong>ので、さまざまな方法でなんとか本人確認書類を送ろうと試みました。</p><p>例えば、通常通りログインしようとすると以下の画面になります。<br><strong>「アカウントがハッキング(不正アクセス)されたことが報告されました」</strong>とありますが、ここで「アカウントの安全を確保」しようとしても…</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_23.png" alt="" width="1280" height="483" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>表示されるのは非情なメッセージ…</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_24.png" alt="" width="1280" height="405" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>別の手段で本人確認書類を送ろうとするも「リクエストを処理できませんでした」と表示され、</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_25.png" alt="" width="1280" height="721" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>その挙げ句、<strong>「不正使用を防ぐため」</strong>という理由で、実行不可に。<br>私が不正利用されているのに…。</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_26.png" alt="" width="1280" height="773" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><h3>不正使用されたアカウントを報告</h3><p>Facebookに用意されている<a href="https://ja-jp.facebook.com/hacked">「不正使用されたアカウントを報告」</a>も利用してみました。</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_27.png" alt="" width="1280" height="344" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>アカウントが不正使用されたというリンクをクリックし、検索するよう促されるも、</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_28.png" alt="" width="1280" height="645" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>使用ペースが早すぎるという理由でブロックされてしまったり(汗)</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_29.png" alt="" width="1280" height="533" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>コミュニティ規定に違反した覚えは無いので、<strong>「Facebookにお知らせください」</strong>というところから進もうとしますが、アカウント検索からの<strong>無限ループ地獄</strong>に陥るだけでした…</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/fb_hacked_28.png" alt="" width="1280" height="645" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>繰り返されるアカウント検索</figcaption></figure><p><strong>アカウントがハッキング(不正アクセス)されたことが報告された</strong>とあるのが唯一の望みで、「それを信じて待つよ…」という気持ちになっていました。</p><h3>なりすましアカウントを報告</h3><p>乗っ取られた翌日、友人から<strong>「アカウントの名前が Rahul Ranade になっている」</strong>と情報を得ていたことを思い出しました。</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_32.png" alt="" width="1280" height="575" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>そこで少し時間をあけ、意味があるかはわかりませんが、<a href="https://www.facebook.com/help/contact/295309487309948">なりすましアカウントを報告</a>してみることに。</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_30.png" alt="" width="1280" height="617" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>コツコツと入力を進め、送信ボタンをクリックすると…<br><strong>そんなプロフィール(URL)はFacebookに存在しない</strong>と言われてしまいました(汗)</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_31.png" alt="" width="1280" height="617" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>こんな感じで7月26日(水)までいろいろ試しましたが、ここまでのとおり、<strong>どれもうまく行かない状態</strong>が続いています。<br>この間もウェブやTwitterで情報収集を試みますが、<strong>アカウント停止処分を受けたら諦めるしか無い</strong>という情報や、<strong>乗っ取られても本人確認書類をアップロードしたら再開できた</strong>という情報はあるものの、具体的な方法や、アカウント停止からの再開についての情報は得られませんでした。</p><h3>ご意見・ご要望としての連絡</h3><p>28日(金)、乗っ取り被害からもうすぐ1週間。<br>これはもうホントに最後の手段的な感じで、<a href="https://ja-jp.facebook.com/help/127103474099499">ご意見・ご要望</a>を送ってみることに。</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_33.png" alt="" width="1280" height="666" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>Facebookから、なにかしらリアクションがあるとは見込めない感じですが(苦笑)<br>まさに<strong>藁にもすがる思い</strong>で、Facebookに手紙をしたためました。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/fb_hacked_34.png" alt="" width="944" height="436" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>Facebookに届け!この想い!</figcaption></figure><p>この後、なんとか良い結果に向かってくれることを願っています。</p><h2>Facebookが利用できなくなってからの1週間</h2><p>今日は7月29日(土)です。<br>Facebookアカウントが乗っ取られてから1週間が経過しました。</p><h3>メッセンジャーが使えないのがつらい</h3><p>乗っ取り被害にあい、最初に困ったのは<strong>「メッセンジャーが利用できないこと」</strong>でした。<br>プライベートな連絡はもちろん、仕事でも利用していたのですが、<strong>「Facebookのアカウント以外、連絡先を知らない友人」</strong>が意外にも多いことに気が付きました。</p><p>よく会っていた友人たちはもちろん、過去にイベントなどで知り合い連絡を取っていた友人や知人との間で、<strong>一番便利に利用していた連絡手段が一瞬で絶たれてしまいました。</strong><br>運良く23日(日)に、友人たちと集まる機会があったので、そこで今さらながらLINE交換とかしてました(照)<br>8月の上旬にはオンラインセミナーの登壇も予定しているのですが、セミナー主催者さんとの連絡もメッセンジャーがメインだったので、これもどうしたものかと悩んでいます。</p><p>もちろん、メールなどで連絡することはできるのですが、<strong>慣れというのは怖いもの</strong>で、チャット形式のほうが遥かに使いやすい人間になってしまっていました。</p><h3>普通なら知り合えなかった友人たちと強制的に離れ離れになってしまう</h3><p>私はSNS、特にFacebookを利用するようになってから、一気に住む世界が広がりました。<br>東京や仙台、名古屋、大阪、京都、福岡、沖縄にいる、普通なら知り合うことは無かった友人たち。</p><p>Facebookがあることで得られたコミュニティ、そんな彼ら彼女らと、私だけがこれまでのような関係性は保てないのかも…と<strong>疎外感のようなもの</strong>を感じ始めています。<br>たとえ数年会っていなくても、ブラウザの向こうにはその存在をいつも感じられて、ひとたび会えばその時間とか距離とかを一瞬で忘れられていたのに。</p><h3>毎日のように投稿していた「1日の振り返り」が書き残せない</h3><p>私はかなりのFacebookヘビーユーザーだったと思うのですが、ちょっとしたことはもちろん、1日の終りにその日を振り返るような投稿をほぼ毎日していました。</p><p>それができなくなった最初の月曜日。<br>いつものように仕事を終えるわけですが、なんだか<strong>1日が終わった気がしない</strong>…<br><a href="https://twitter.com/nishi_yama">Twitter</a>もあるのですが、無意識に近いレベルで使い方を分けていたので、ログを残せないことがとてもモヤモヤした気持ちになっています。</p><p>ちなみに最近は、Twitterで毎日のように「今日の進捗」として、Facebookアカウント復活へ向けた投稿をしています(笑)</p><h3>過去の出来事が振り返られない</h3><p>私はFacebookを<strong>ライフログ</strong>のように使っていました。<br>面白いこともくだらないことも書いていますが、そのときどきの出来事を残すようにしていたので、毎日のように「○年前の今日」というカタチで過去の出来事を振り返っては、こんなこともあったなとか、これは面白い出来事だったなと楽しんでいましたが、これができなくなったのがとても寂しいです。</p><ul>
<li>車を買い替えた時、それまでの愛車に「今までありがとう」と伝えた投稿</li>
<li>次女や三女が生まれたときの投稿</li>
<li>長女のしりとりに付き合ったら、とんでもないボケをして大笑いした投稿</li>
<li>2013年と2018年に開催したMovable Typeのイベント(MTDDC Meetup)の投稿</li>
<li>異世界転生アニメへの提言を綴った投稿</li>
<li>会社での出来事、飲み会での出来事を綴った投稿</li>
<li>今では普通に付き合っている友人たちと、初めて会った日の投稿</li>
</ul><p>過去10年以上に渡るこれらのログ、それが<strong>すべてが消え去っている状態</strong>です。<br>正直、とてもつらい。</p><p>ここから先、もう投稿はできませんよと言われても、もしかしたら許せるかもしれませんが、過去のできごとが一切残らない状態は、とても虚しい気持ちになります。</p><h2>なぜアカウント停止処分になったのか</h2><p>今回の<strong>コミュニティ規定違反によるアカウント停止処分</strong>、なぜそんなことになったのかを考えているのですが、正直、さっぱりわかりません。<br>おそらく、乗っ取り犯がなにかしらの投稿などをしたか、あるいは誰かがアカウント乗っ取りに気がついたとき、<strong>なにかしらの「報告」がFacebookにあった</strong>のではないかと思います。</p><p>Facebook側は、<strong>一定数はあったであろうその報告に基づき、機械的にアカウント停止処分を下した。</strong></p><p>そう考えるのが自然で、妥当かなと思っています。</p><h2>SNSに関して思うこと</h2><p>初めてSNSアカウントが消されてしまう経験をしているのですが、思っていたよりもずっとショックで、そしてそれは突然やってくるのだなと思いました。</p><p>コミュニティ規定違反でアカウント停止処分、おそらくこれは乗っ取り犯の何かしらの行為が問題になっていると思います。<br><strong>私はなにも関与していないにもかかわらず、処分を受けているのは私</strong>という現実。<br><strong>2段階認証を設定していたにも関わらず、わずか10分程度でそれを突破されハッキングされた</strong>のに、<strong>一方的に「再審査は受け付けない」という姿勢</strong>は、10年以上も利用してきたユーザーに対して、あまりにも非情ではないかなと思います。</p><p>せめて、Facebookに直接連絡できる手段を残してほしい。<br>全世界で30億人ともいわれるユーザーを、1人1人相手にできないのはわかります。<br>とは言え、その手段を残していないというのは、残念というよりも、ちょっと怖い気持ちすらしました。</p><p>あくまでサービスを無償利用している立場なので、そのルールに則って利用するしか無いのは理解しています。<br>それに、サービスの名前が変わるとか、慣れ親しんだアイコンが変わるとか、SNSを提供している企業にも事情はあると思うので、それは受け入れなければならないとも思います。</p><p>ただ、<strong>仮にどこかのSNSがなくなったとしても、SNSがなくなる未来は考えにくい</strong>ので、SNS各社にはそういった文化や価値観というか、インフラを提供しているということを、もうちょっと誇りにしてサービスを提供してほしいなと感じています。</p><p>そして私たち利用している側は、<strong>1つのSNSだけに頼らない人間関係の構築</strong>も大切にする必要があると思い知らされました。</p><h2>これからどうするか</h2><p>ご存知のとおり、Facebookは実名登録を原則にしているので、アカウントを複数持つことはできません。<br>現在、アカウント停止にはなっていますが、すぐに利用履歴が消えるわけではないと思われるので、仮に<strong>別の電話番号やメールアドレスを利用して新しくアカウントを作成</strong>しても、<strong>同一人物と判定されたときにまたアカウント停止処分を受ける</strong>ことになるようです。(接続元IPアドレスとか、利用デバイスとかから機械的に判断していそう)</p><p>それに、今現在もまだ、アカウント復活を諦めたわけではありません。<br>そんな簡単に10年以上のライフログを捨てる気にはなれません(笑)<br>なので、アカウントを新しく作ることがあったとしても、まだもう少し先と考えています。<br>本当は、今すぐメッセンジャーだけでも使いたいのですけどね(苦笑)</p><p>今後、この問題がどうなっていくのか、私にもまだわかりませんが、なにか変化があったらまたこちらに書き足して行きます。<br>同じようにアカウントが突然停止されて困っている人や、これから先、乗っ取り被害に遭ってしまった方々のためにも、なんとかアカウント再開を成し遂げたいと、今は思っています。</p><h2>Facebookで繋がっていた友人たちへ</h2><p>現在、Facebookでのみ繋がっていた皆さんには、私から連絡する手段がありません。<br>先の通り、アカウント再開または新しくアカウントを作るにしても、まだ時間がかかると思うので、もう少しだけ待っていてくれると嬉しいです。</p><p>もしもこれをご覧になって、他のSNSなどの連絡先を交換しようと思っていただけた方は、メールやSMS、<a href="https://twitter.com/nishi_yama">Twitter</a>などを利用してご連絡いただくか、あるいは私の連絡先を知る共通の友人・知人を介して連絡をいただけると幸いです。</p><p>またいつものように、くだらなくも楽しい、そんな日常を共有できることを願って。</p><h2>乗っ取り被害発生から4ヶ月が経過しました。</h2><p>こんにちは、この部分を書いているのは、2023年11月23日(木)です。<br>Facebookアカウントの乗っ取り被害に遭ってから4ヶ月が経過しました。</p><p>この間もアカウント再開に向け、いろいろと取り組んで来ましたが、結論から言うと、現時点ではまだ再開に至っておりません。<br>今回は、この4ヶ月間のことを書いておこうと思います。</p><h3>Twitter(X)への投稿とそれにより見えてきたこと</h3><p>このブログ記事を最初に書いた7月29日、Twitter(X)に以下の投稿をしました。</p><blockquote class="twitter-tweet"><p lang="ja" dir="ltr">Facebookが乗っ取り被害に遭ってから1週間。<br>これまでの経過と、今考えていることをブログ記事にしました。<br><br>これをご覧の方で、Facebookでも繋がっていた方は、共通の友人への状況連絡として、この記事をシェアしてもらえると嬉しいです。<a href="https://twitter.com/hashtag/Facebook?src=hash&ref_src=twsrc%5Etfw">#Facebook</a><a href="https://twitter.com/hashtag/%E3%82%A2%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E4%B9%97%E3%81%A3%E5%8F%96%E3%82%8A?src=hash&ref_src=twsrc%5Etfw">#アカウント乗っ取り</a> <a href="https://t.co/FHRdZGTyxk">https://t.co/FHRdZGTyxk</a></p>— にちあま@ウェブディレクター (@nishi_yama) <a href="https://twitter.com/nishi_yama/status/1685078163645513728?ref_src=twsrc%5Etfw">July 29, 2023</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script><p>この投稿には多くの方からリアクションをいただきました。<br>同じようにアカウント乗っ取り被害に遭われている方からも連絡があり、その後、情報交換させていただいた方もいます。<br>また、インターネット検索でこのブログ記事を見つけたという方からも、DMやメールを数多くいただきました。</p><p>Facebookアカウントの乗っ取り被害は、何年も前から多く発生していたようですが、2023年2月頃から急に増えだし、6月〜8月くらいにピークになっていたようです。<br>中にはアカウント再開できた方もいましたが、私と同じようにFacebookへの報告もままならない状態になる方も多く、早々にアカウント再開を諦めてしまった方も多かったようです。</p><h3>アカウント再開できた方々の体験談</h3><p>ありがたいことに、私のもとには「ブログ記事に書いてある方法以外で、こんな方法でアカウントを取り戻すことができました」という体験談もお寄せいただきました。</p><ul>
<li>Facebookアカウントと連携していたInstagramアカウントから、再度連携するようFacebookにログインしたらアカウントが再開できた。(Instagramのアカウントセンターへアクセス)</li>
<li>disabled@fb.com に英文で「アカウント停止の解除」「アドレスの再登録」のメールを送った。</li>
</ul><p>ただ、残念ながら私の場合はこれらの方法でもアカウント再開には至りませんでした。</p><h3>私はMeta社の公式サポートを受けることに</h3><p>アカウント停止から2ヶ月ほどが経過したとき、ふと「Meta認証」のことを思い出しました。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fabout.fb.com%2Fja%2Fnews%2F2023%2F07%2Fmetaverified_globalexpansion%2F" title="InstagramとFacebookのサブスクリプション「Meta認証」を日本でも提供開始 | Metaについて" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://about.fb.com/ja/news/2023/07/metaverified_globalexpansion/" target="_blank">InstagramとFacebookのサブスクリプション「Meta認証」を日本でも提供開始 | Metaについて</a></iframe><p>これは月額費用を負担することで、アカウントの本人確認が行われ、適切なアカウント保護がなされるものです。<br>また、これを利用すると<strong>日本語でアカウントサポートデスクに連絡を取る</strong>ことができます。</p><p>9月13日、このことをふと思い出し、さっそくInstagramからMeta認証を受け、サポートへコンタクトを取ることにしました。<br>Facebookアカウントが乗っ取り被害に遭った旨のメールを送ってから1時間ほど経ったとき、サポートから返信がありました。</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_35.png" alt="" width="1280" height="1232" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>このメールは以下のように続いていました。</p><ol>
<li>これまでFacebookやInstagramなどのMetaのサービスや製品でご利用されたことがないメールアドレス<br>(その新しいメールアドレスが復旧後のログインメールアドレスとなります)</li>
<li>「現在はアカウントが停止されており、アカウント再開の再審査を行いたいのですが、重大なコミュニティ違反として再審査を受け付けない旨が表示されてしまい、打開策が見当たりません。」この部分のスクリーンショットをご提示頂ければ幸いでございます。</li>
</ol><p>この瞬間、真っ暗なトンネルの中を彷徨った2ヶ月間からやっと開放される!とものすごく興奮しました。<br>一筋の光明とは、まさにこのことだと思います。</p><h3>Meta Pro Teamとのやり取りが始まってからの2ヶ月</h3><p>先の通り、さまざまな解決方法を試すもうまく行かなかったこともあって、Meta社のサポートに連絡が取れるようになったのは、とても嬉しい出来事でした。<br>時間はかかってもアカウント再開が叶うのであれば…と、サポートから提供依頼のあった情報や資料をコツコツと送る作業を始めました。</p><p>サポートとの連絡を取り始めて2〜3週間後、もっと早くに解決するかと思っていましたが、なかなか進展がありませんでした。<br>とは言え、全世界30億ものアカウントがあるような巨大サービスですし、ある程度時間がかかるのは仕方がないのかと、この頃から連絡は週に1度くらいのペースになっていきました。</p><blockquote class="twitter-tweet"><p lang="ja" dir="ltr">調査開始から5週間…<br>ワタシのアカウントはどんなことになっているのだろう… <a href="https://t.co/I7Gvws9ida">pic.twitter.com/I7Gvws9ida</a></p>— にちあま@ウェブディレクター (@nishi_yama) <a href="https://twitter.com/nishi_yama/status/1714824375097270678?ref_src=twsrc%5Etfw">October 19, 2023</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script><h3>Meta社から、にわかには信じられない連絡が届く</h3><p>調査依頼を開始してからおよそ5週間後の10月28日、その後の状況を確認したところ、以下の返信がありました。</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_36.png" alt="" width="883" height="934" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>サポートから担当部署への調査依頼が却下されている…?!<br>ってことは、この5週間、調査はまったく進んでいなかったということ…??<br>これまで、調査や審査が続いていると言っていたのはなんだったの…</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_37.png" alt="" width="1280" height="392" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>挙げ句、この状況は変わる見込みが無いので、新しいアカウントを作ってはどうかと連絡がありました。<br>通常、複数のFacebookアカウントを利用することは規約違反になりますが、<strong>今回のようなケースではアカウントの作成が認められる</strong>ということでした。</p><h3>調査リクエストが却下されていると判明した後</h3><p>この連絡が届いた後、一向に話が進まなくなってしまいました。<br>実際に調査リクエストがなされているのか、それともそれすらなされていないのか、Facebook側でなにが起こっているのか、なにを信用すると良いのか…</p><p>Meta社のサポート担当曰く、今回のケースはかなり特殊らしく…</p><ul>
<li>サポートから担当部署へハッキング調査依頼をしているが、すべて却下されている。</li>
<li>依頼を繰り返しているが、未だ受け付けてもらえない。</li>
<li>アカウントは停止された状態のままデータベース上に残っているので、引き続き正規報告( <a href="https://facebook.com/hacked/">https://facebook.com/hacked/</a> )をお願いしたい。</li>
<li>なお、本件に関してはその特殊性から、別のアカウント作成が認められることを確認している。</li>
<li>従来のアカウントが再開した際は、どちらかを完全に削除する必要があることに注意してほしい。</li>
<li>以上を持って、本件をクローズとしたい。</li>
</ul><p>とのことでした。<br>いや、<strong>ツッコミどころが多すぎ</strong>ですが…</p><p>ハッキングされている事実は確認できているのに、その調査・対応依頼が受け付けてもらえないってどういうこと?<br>正規ルートで報告しようにも、名前やメールアドレスはもちろん、すべての情報が書き換えられているから、正規ルートでの報告もできないから困っているわけで。</p><h3>この先、どうするか</h3><p>いわゆる正規ルート( <a href="https://facebook.com/hacked/">https://www.facebook.com/hacked/</a> )は、私の場合「連続使用が多すぎるので一時的に利用停止している」旨が表示されるのですが、Meta社のサポート曰く、利用するデバイスを変え、利用間隔を空けて、報告を続けて欲しいとのことでした。</p><p>という感じで、正直なところ、アカウント再開への道筋がまったく見えていません。<br>なんとかならないのか、あらためてサポートに確認してみましたが、届いた返信は以下でした。</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_38.jpg" alt="" width="1170" height="1071" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>今回の件、<strong>Meta Pro Teamではもうどうにもできないので、調査リクエストができるようになるまで自力で頑張ってくれ</strong>、ということのようです。</p><p>このままでは仕事はもちろん、友人関係にも著しい弊害が出てしまうので、暫定的なアカウントを作ろうと思っています。<br>ただ、これまでのアカウントを諦めるつもりも今のところは無いので、手を変え品を変えではありませんが、今後もハッキング報告とサポートへの連絡は続けようと思っています。</p><p>アメリカではアカウント再開まで半年以上かかったという例もあるようです。<br>その間、Facebook側には一切連絡が取れなかったとか。<br>それに比べると、私の状況はまだ良いのかも…?</p><p>というわけで、現在はまだアカウント再開に至っていませんが、この4ヶ月間の状況を書いておきました。<br>また状況が変わったら、こちらに書き加えていこうと思います。</p><h2>乗っ取り被害発生から8ヶ月が経過しました。</h2><p>こんにちは、この部分を書いているのは、2024年3月20日(水)です。<br>Facebookアカウントの乗っ取り被害に遭ってから8ヶ月が経過し、前回この記事を更新してから4ヶ月が経過しています。</p><p>この4ヶ月も大きく状況は変わりませんでしたが、先日とうとう「最終宣告」をされてしまいました。</p><h3>検索結果から消えた登録メールアドレス</h3><p>2023年11月21日に「新しいアカウトを作ってくれ」と連絡が来たあと、私は暫定アカウントを作っていました。<br>かつてFacebookでつながっていた方々に、少しずつ少しずつ、申請をポチポチ送る日々。<br>あまり一度に大量申請すると良くないかと考え「友だちかも」に出てきた順番に少しずつ増やしていきました。</p><p>その1ヶ月後、あらためて <a href="https://www.facebook.com/hacked/">https://www.facebook.com/hacked/</a> で登録メールアドレスを検索し、対応を進めようとしたところ、このようなメッセージが表示されました。</p><blockquote>
<p>No Search Results<br>(検索結果がありません)<br>Your search did not return any results. Please try again with other information.<br>(検索結果は見つかりませんでした。他の情報で再度検索してください)</p>
</blockquote><p>もう1つの検索対象である電話番号は新しいアカウントに使用していたので、ここから先に進むことができなくなってしまい、あらためてMeta Pro Teamから最後に届いたメールに返信を送りました。<br>ただ、送られてくる回答は「ハッキング報告をしてくれ」の一点張り。<br>報告しようにも登録メールアドレスが見つからない状態なので困っているのに、どうしろと…。</p><p>2024年になり、あらためて「乗っ取り被害に遭っているアカウントのこと」「これまでの経緯」「電話番号は暫定アカウントに使用していること」を送ってみたところ、以下のような返事が届きました。</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_39.jpeg" alt="" width="1179" height="790" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>ここへ来て、私以外にも多くのアカウントで同様の現象となっていることを認めてくれました。<br>そしてシステムアップデートを待ってくれ、と…。<br>そしてこの返信には以下のように続いていました。</p><blockquote>
<p>可能な限り引き続きサポートさせて頂きますので、ご状況を正確に把握するために下記情報のご提示をお願い致します。<br><br>1.現在のご状況の詳細をできるだけ詳しくお伝え頂ければ幸いです。<br>2.該当の状況が分かる最新のスクリーンショット<br><br>上記情報を確認次第24時間以内にお返事させて頂きます。<br>新たなご質問に関しましては、改めてお問い合わせ頂ければご対応をさせていただきます。</p>
</blockquote><p>何度も繰り返し同じことを聞かれている…<br>とは言えここまで来たので、諦めずに連絡を行いました。<br>Meta Pro Teamからは、あらためて対応部署への依頼を行うと連絡がありました。</p><p>それが2024年1月11日のことでした。</p><h3>Meta Pro Teamから返信が来なくなる…</h3><p>2月に入り、その後どうなったかとメールを送ってみますが、返事が来ません。<br>それから数週間あけて連絡を入れてみますが、まったく返信が来なくなってしまいました。</p><p>1ヶ月以上も返信が来なくなってしまったので、あらためてInstagramからサポートに連絡をしましたが、届いたのは以下の内容でした。</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_40.jpeg" alt="" width="1179" height="1075" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>いやだから…<br><strong>Facebookアカウントが乗っ取り被害に遭って、アカウントが停止されて、Instagramとの連携も解除されちゃってる</strong>んですよ…<br>この人、ホントに公式サポートの人なのかという疑いすら芽生えてきました(苦笑)</p><p>もう何回目かわかりませんが、再度これまでの状況を伝えてみることに。<br>それに対する返信がこちら</p><blockquote>
<p>私も心苦しいですが、お客様のために担当部署に何回も依頼をしてみましたが、何回も失敗になりました。<br>https://www.facebook.com/hacked/<br>只今のご案内できるのが上記のURLとおりですが、もしメールアドレスの連携がなくなりましたら追加の方法として下記のURLをご試すことでございますね。<br>https://www.facebook.com/login/identify<br>ぜひごためしくださいませ。</p>
</blockquote><p>百歩譲って日本語があれなのは良いけれど、それもう諦めてません…?<br>なにか方法はないんですか…</p><h3>そして最後の連絡</h3><p>なぜ担当部署への連絡や調査依頼が失敗しているのか、理由を教えてもらえませんか</p><p><br>10年以上、Facebookを利用してきて、プライベートはもちろんビジネスにも利用してきました。<br>現在、弊社Facebookページの管理者も不在の状態で、アカウントを関連づけていたさまざまなサービスも利用できなくなっています。</p><p>自分でなにか過ちを犯したのならまだしも、一方的に乗っ取り被害に遭い、その理由も明らかにならずに解決ができないというのは理解できません。</p><p>以前のアカウントにアクセスさせてもらえるだけで良いんです。<br>必要なら身分証明書でもなんでも提出します。</p><p>私のアカウントがどうなっているのか、それだけでも教えてもらえませんか</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_41.jpeg" alt="" width="1179" height="1274" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>何度でも言うけれど、<strong>私は被害者であって「復旧に尽力している側」じゃないのよ…</strong><br>そしてその直後に届いたのがこちら</p><p><img src="https://www.ni4.jp/.assets/fb_hacked_42.jpeg" alt="" width="1045" height="1280" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>フィードバックと言われても…<br><br></p><h3>署名活動とかできないのかな…</h3><p>時を同じくして話題になったのがこちらのニュース</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgigazine.net%2Fnews%2F20240307-state-ags-meta-customer-support%2F" title="InstagramとFacebookアカウントがハッキングされ乗っ取りが爆増しているのにサポートが貧弱な件について41もの州司法長官の連合が運営元のMetaに対処を求める書簡を一斉に公表 - GIGAZINE" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://gigazine.net/news/20240307-state-ags-meta-customer-support/" target="_blank">InstagramとFacebookアカウントがハッキングされ乗っ取りが爆増しているのにサポートが貧弱な件について41もの州司法長官の連合が運営元のMetaに対処を求める書簡を一斉に公表 - GIGAZINE</a></iframe><blockquote>
<p>オンライン掲示板のRedditでは、アカウント乗っ取り被害を受けたユーザーに対し、最後の手段として地元の司法長官事務所に相談するようアドバイスすることがあり、実際に一部のユーザーは州の司法長官事務所が介入した結果、Facebookアカウントへのアクセス権限を取り戻せたことを報告しています。</p>
</blockquote><p>日本でもFacebook乗っ取り被害に遭った人たちで署名活動とかしたら、Facebookジャパンへの対応・対策依頼とかできないのかな</p><p><strong>「SNSなんて、そんなもんだろ」</strong></p><p>と言う人もいるし、それもわかるけれど、運営側がそうだとしたら、とんでもない話なんじゃないかと。<br>世界中のあらゆる「データ」を取り扱う企業が、あれだけ慎重になっていることを、もう一度考えて欲しい。</p><p>ここまで現在の状況です。<br>またなにか変化があれば書き足しますが…これはさすがに厳しいのかな…と思っています。</p>
GDPR対応もOK!「ウェブサイト向けCookie同意管理バナーツール」の導入と動作確認をしてみた。
tag:movabletype.net,2003:post-2404758
2023-06-17T09:08:00Z
2023-06-17T09:13:04Z
ユーザーローカル社が無料で提供しているCookie同意管理バナーツールを設置し、Cookie発行動作までを確認した話。
ジャクスタポジション 西山
<p><img src="https://www.ni4.jp/.assets/Cookie_banner_ogp.jpg" alt="" width="1200" height="630" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>ども、どもども。<br>先日このブログで、<a href="https://www.ni4.jp/2023/05/25-192400.html">「日本企業のウェブサイトに求められるCookie利用同意確認とCookieポリシーの設置」</a>という記事を書きました。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.ni4.jp%2F2023%2F05%2F25-192400.html" title="日本企業のウェブサイトに求められる「Cookie利用同意確認とCookieポリシーの設置」 | www.ni4.jp" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://www.ni4.jp/2023/05/25-192400.html" target="_blank">日本企業のウェブサイトに求められる「Cookie利用同意確認とCookieポリシーの設置」 | www.ni4.jp</a></iframe><p>その記事にもあるとおり、<strong>日本国内のウェブサイトであっても、GDPRの適用対象となる場合や、改正個人情報保護法が定める「個人情報の第三者提供」を行うと認められる場合、ウェブサイト閲覧時にCookieを発行することに同意を得る必要があります。</strong></p><p>GDPR以外へも対応が必要な場合や、ウェブサイト上でどのようなCookieを発行しているかが不明な場合などは、<a href="https://cookie.bizrisk.iij.jp/">OneTrust</a>などのCMP(Consent Management Platform)を利用するのが安心かと思いますが、GA4+GoogleTagManagerでアクセス解析等を実施しているだけのような場合には、ユーザーローカル社が無料提供している<a href="https://cookie.userlocal.jp/">「Webサイト向けCookie同意管理バナーツール」</a>の利用も選択肢の1つと思います。</p><p>そこで今回、このブログ記事では、<strong>ユーザーローカル社の「Webサイト向けCookie同意管理バナーツール」について、その導入方法と、導入した際のGA4+GoogleTagManagerの動作(Cookieの発行状況)</strong>について、まとめていこうと思います。</p>
<h2>Webサイト向けCookie同意管理バナーツールのダウンロード</h2><p>ユーザーローカル社のCookie同意管理バナーツールは以下からダウンロードできます。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fcookie.userlocal.jp%2F" title="Webサイト向けCookie同意管理バナーツール|株式会社ユーザーローカル" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://cookie.userlocal.jp/" target="_blank">Webサイト向けCookie同意管理バナーツール|株式会社ユーザーローカル</a></iframe><p>ウェブサイトへアクセスして、フォームに必要事項を入力すると、ツールのスクリプトと設置資料(マニュアル)がダウンロードできます。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/Cookie_banner_01.png" alt="" width="1280" height="409" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>ダウンロードしたデータの中身</figcaption></figure><p>スクリプトの設置方法が詳しく記載されたマニュアルがあるので、記載内容のとおりに ulcc_tag.txt を編集しておきましょう。</p><h2>GoogleTagManagerにCookie同意管理バナーツールのタグを登録する</h2><p>こちらもマニュアルにあるとおり、既存のワークスペースに「新しいタグ」として、Cookie同意管理バナーツールのタグを登録します。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/Cookie_banner_02.png" alt="" width="1280" height="596" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>GoogleTagManagerへのタグ登録</figcaption></figure><p>タグを登録して「公開」したら、GoogleTagManagerが設置されているウェブサイトにアクセスして、Cookie同意管理バナーツールが表示されているか、確認してみましょう。</p><p>以下のようにCookie同意管理バナーツールが表示されていれば、設置は完了です。</p><p><img src="https://www.ni4.jp/.assets/Cookie_banner_03.png" alt="" width="1276" height="903" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>バナーに表示される<strong>テキストやデザイン(配色)も変更可能</strong>となっていて、設置するウェブサイトにあわせて細かく変更できます。<br>また、<strong>GA4以外のCookieを制御する方法や、オプトアウト(Cookie受入拒否へ変更)も用意されている</strong>ので、マニュアルを確認することで、いろいろと対応できます。</p><h2>Cookie同意管理バナーツールの動作確認</h2><p>設置が完了したページで、Cookie同意管理バナーツールの動作を確認していきます。<br>今回は、Google Chrome / Safari の開発者ツールを使用して確認してみます。</p><h3>同意確認ボタンで「同意する/同意しない」を選択していない状態</h3><p>Google Chromeの開発者ツールで「Application」タブを開き、「Storage」にある「Cookies」で、確認するドメインを選択すると、発行されたCookieが表示されるようになります。<br>Safariでは、開発者ツールをで「Storage」タブを開き、左にある 対象ドメインの「Cookie」をクリックすると、発行されたCookieが表示されるようになります。</p><p>Cookie同意管理バナーツールで「同意する/同意しない」のいずれも選択していない初期の段階では、以下のようにCookieが発行されていないことが確認できます。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/Cookie_banner_04.png" alt="" width="1280" height="644" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>Google Chrome の場合</figcaption></figure><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/Cookie_banner_05.png" alt="" width="1280" height="600" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>Safari の場合</figcaption></figure><h3>同意確認ボタンで「同意」を選択した場合</h3><p>初期状態で「同意」した場合、_ul_cookie_consentの値がallow(許可)となり、GA4のCookieが発行されることを確認できます。</p><p><img src="https://www.ni4.jp/.assets/Cookie_banner_06.png" alt="" width="1280" height="644" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p><img src="https://www.ni4.jp/.assets/Cookie_banner_07.png" alt="" width="1280" height="600" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><h3>同意確認ボタンで「同意しない」を選択した場合</h3><p>一方、「同意しない」を選択した場合は、_ul_cookie_consentの値がdeny(拒否)となり、GA4のCookieが発行されていないことを確認できます。</p><p><img src="https://www.ni4.jp/.assets/Cookie_banner_08.png" alt="" width="1280" height="644" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p><img src="https://www.ni4.jp/.assets/Cookie_banner_09.png" alt="" width="1280" height="600" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>以上で期待する動作ができていることを確認できました。</p><h2>Cookie同意管理バナーツールの使いどころ</h2><p>ご覧いただいた通り、<strong>ユーザーローカル社のCookie同意管理バナーツールでは、同意する/同意しないの選択時に、GoogleTagManagerの動作を制御することで同意管理を実現している</strong>ようです。</p><p>そのため、GoogleTagManagerで管理していないもの(「GoogleTagManagerで設置したHTML=ulcc_tag.txt」に記載されていないスクリプト)は、同意する/同意しないの選択に関わらず、通常通り実行され、Cookieを発行してしまうことになります。</p><p>先のとおり、GA4+GoogleTagManagerのみを利用している場合や、すべてのタグをGoogleTagManagerで管理している場合は問題ありませんが、<strong>Cookieの発行を細かく設定・制御したい場合や、複数の担当者でウェブサイトを管理・運営していて、Cookieを発行するタグが多岐にわたるような場合は、注意が必要となりそう</strong>です。</p><p>実際の導入にあたっては、CMPの利用とあわせて検討するのが良さそうですが、一般的なコーポレートサイト等であれば、ユーザーローカル社のCookie同意管理バナーツールはとても便利に利用できると思います。</p><p>ユーザーローカルさん、このようなツールを無料提供してくれて、ありがとうございます!</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.userlocal.jp%2F" title="株式会社ユーザーローカル" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://www.userlocal.jp/" target="_blank">株式会社ユーザーローカル</a></iframe><p>最上部の写真は、<a href="https://unsplash.com/ja/%E5%86%99%E7%9C%9F/q7fMY7kBBz8?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>の<a href="https://unsplash.com/de/@prateekkatyal?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Prateek Katyal</a>が撮影した写真です。</p>
日本企業のウェブサイトに求められる「Cookie利用同意確認とCookieポリシーの設置」
tag:movabletype.net,2003:post-2381211
2023-05-25T10:24:00Z
2023-06-17T08:15:28Z
最近良く見る「Cookie利用同意確認ツール」と「Cookieポリシーの設置」について、GDPR/改正個人情報保護法、そして改正電気通信事業法の観点から、日本企業のウェブサイトに求められる対応をまとめてみた話。
ジャクスタポジション 西山
<p><img src="https://www.ni4.jp/.assets/Cookie_ogp.jpg" alt="" width="1200" height="630" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>ども、どもども。<br>先日、クライアント企業さんから、<strong>自社のウェブサイトにもCookie利用確認のボタンを設置したほうが良いだろうか?</strong>と相談を受けました。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/thumbnail/Cookie_04-800wri.png" alt="" width="800" height="115" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>Cookie利用確認のボタンの例</figcaption></figure><p>ここ数年でよく見かけるようになったこのボタン、EU加盟国で施行されたGDPRや、改正個人情報保護法への対応として設置されているものですが、どのようなときに必要となるかなど、明確に説明できるほど理解できていませんでした。</p><p>そこであらためて、<strong>GDPRのこと、改正個人情報保護法のこと、ウェブサイトでこのボタン(Cookie利用同意確認ツール)が必要になるケースを勉強し直した</strong>ので、このブログにも残しておこうと思います。<br>だいぶ長くなってしまいましたが、一通り理解できたのかなと思います。<br>間違いなどがあったら、優しく指摘してもらえると喜びます!</p>
<h2>GDPR対応で日本企業のウェブサイトに求められること</h2><p>2018年5月25日に、欧州で施行されたEU一般データ保護規則(General Data Protection Regulation)のことを「GDPR」と呼びます。<br>EU域内の各国に適用される「個人情報を保護するための法令」ですが、日本企業でも適用範囲内になる場合があり、これに違反すると、最大で「該当企業における全世界年間売上の4%」または「2,000万ユーロ」のいずれか高い方が制裁金として課される場合があります。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.hitachi-solutions.co.jp%2Fhibun%2Fsp%2Fcolumn%2Fleakage%2F03.html" title="GDPRとは?日本企業が対応すべき対策を考える|セキュリティ対策コラム|情報漏洩防止ソリューション 秘文|日立ソリューションズ" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://www.hitachi-solutions.co.jp/hibun/sp/column/leakage/03.html" target="_blank">GDPRとは?日本企業が対応すべき対策を考える|セキュリティ対策コラム|情報漏洩防止ソリューション 秘文|日立ソリューションズ</a></iframe><h3>GDPRで個人情報として扱われるCookie(クッキー)とは</h3><p>Cookieとは、ウェブサイトを閲覧した際に、ブラウザに一時的に保存されるユーザーの閲覧履歴などの情報で、訪問した日時や訪問回数などが含まれており、主に以下の用途に利用されます。</p><ul>
<li>ウェブサイトへのログイン情報を保存する(ログインID/パスワード入力を省略)</li>
<li>オンラインショップで商品をカートに入れた情報を保存する(時間を空けて購入する場合に対応)</li>
<li>メールフォームなどで入力した情報を保存する(名前や住所などの入力を省略)</li>
</ul><p>また、GoogleAnalyticsなどのアクセス解析ツールはもちろん、GA4とGoogleTagManagerを組み合わせて利用している場合もCookieを使用しており、<strong>GDPRではこのCookieが個人情報として保護する対象となるため、ウェブサイトで取得・利用するには閲覧者(ユーザー)の同意が必要になります。</strong></p><h3>GDPRで定められている個人情報の取り扱い</h3><p>GDPRが適用となるウェブサイトで、Cookieを含む個人情報を取得・利用する場合は、以下の対応が必要となります。 </p><ol>
<li>企業情報や利用目的を明確にした上で、<strong>ユーザーに同意を求める</strong>こと
<ul>
<li>連絡先など身元情報</li>
<li>処理の目的</li>
<li>第三者提供の有無</li>
<li>個人情報の保管期間</li>
</ul>
</li>
<li>取得した個人情報は、ユーザーの求めに応じて対処可能であること
<ul>
<li>ユーザーが個人データの<strong>削除を要求した場合に削除できる</strong>こと</li>
<li>個人データが侵害された場合ユーザーが迅速に知ることができること</li>
</ul>
</li>
<li>取得した個人情報を適切に管理すること
<ul>
<li>監視、暗号化、匿名化などの<strong>セキュリティ要件を明確化</strong>すること</li>
<li>必要な期間以上の個人情報保持の禁止</li>
<li>大量の個人情報を扱う場合のデータ保護責任者を任命すること</li>
</ul>
</li>
</ol><h3>日本企業はGDPRの対象となるか</h3><p>一見すると、EU域内のウェブサイトにだけ関係しそうですが、日本企業のウェブサイトでも以下の条件を満たしている場合、GDPRの適用対象となります。</p><ul>
<li>EU域内に子会社や支店、営業所などを有している</li>
<li>日本からEU域内に商品やサービスを提供している</li>
<li>EU域内から個人データの処理について委託を受けている</li>
</ul><p>また上記に加え、<strong>ウェブサイト上でEU域内にいるユーザーの行動データを取得している場合</strong>も対象となります。</p><ul>
<li>ウェブサイト上でCookieで得られる個人データを利用している場合</li>
<li>EU域内に個人データを扱うデータベースやサーバーが設置されている場合</li>
<li>ネット通販などでEU域内へ商品やサービスを販売している場合</li>
</ul><p>なお「EU域内にいるユーザー」の定義は、EUを居住地にしているユーザーだけを対象にするわけではなく、<strong>短期出張などでEU域内に滞在している場合も「EU域内にいるユーザー」に含まれます。</strong><br>つまり、EU域内に出張中の日本人も「EU域内にいるユーザー」に含まれるため、<strong>EU域内からのアクセスがあるウェブサイトは、日本企業のウェブサイトを含むすべてがその対象となります。</strong></p><h3>GDPRが適用となるウェブサイトで必要となる対応</h3><p>GDPR適用対象となるウェブサイトでは、以下の対応が必要で、これは日本企業であった場合も同じです。</p><ol>
<li>Cookieの取得・利用をユーザーから同意を得て行う(Cookie利用同意確認ツールの利用)</li>
<li>Cookieを取得・利用する企業の情報や利用目的を明確にする(Cookieポリシーの設置)</li>
<li>Cookieの削除方法などを案内する(Cookie利用同意確認ツールの利用/Cookieポリシーの設置)</li>
</ol><h2>改正個人情報保護法とCookieについて</h2><p>2022年4月1日に施行された改正個人情報保護法では、Cookieおよびインターネットの閲覧履歴、IPアドレスなどが「個人関連情報」(それ単体では特定の個人を識別しないが、特定の個人に関する情報)に該当するとしています。</p><p>また、この個人関連情報は「個人情報に照合し個人情報となることが想定されるデータ」を指しているため、単体では個人情報として保護対象にはならなくとも、<strong>Cookieを含む個人関連情報を第三者に提供し、さらに第三者が個人関連情報を個人データとして取得することが想定される場合</strong>は、改正個人情報保護法のもと、その<strong>取得・利用にユーザーの同意が必要</strong>とされています。</p><p>なお、現状では日本国内向けウェブサイトにおいて、<strong>第三者提供に該当しない場合の罰則はない</strong>ようです。</p><h3>第三者提供の該当要件</h3><p>例えば、GoogleAnalytics(GA4+GoogleTagManager)等で、ウェブサイトのアクセス解析を実施している場合、解析タグで取得される閲覧履歴等は、<strong>Google社が直接ユーザーから閲覧履歴を取得することになるため、第三者提供には該当しない</strong>とされています。</p><p>参考:「個人情報の保護に関する法律についてのガイドライン」に関するQ&A<br><a href="https://www.ppc.go.jp/files/pdf/2304_APPI_QA.pdf#page=97">https://www.ppc.go.jp/files/pdf/2304_APPI_QA.pdf</a>(Q8-10)</p><p>他方、<strong>ターゲティング広告を掲出している場合でかつ、以下に該当する場合は、第三者提供に該当</strong>します。</p><ul>
<li>広告配信のために提供されるデータと、自社保有している個人のデータを紐付けている場合</li>
<li>自社ウェブサイトで取得したデータを提供した先で、提供先が保有する個人のデータを紐付ける場合</li>
</ul><p>なお、個人情報を保有していないウェブサイト(会員登録などがないウェブサイト)で、<strong>Cookieなどの個人関連情報のみを用いてターゲティング広告を掲出する場合は、第三者提供に該当しません。</strong></p><h3>ターゲティング広告主として確認すべき内容</h3><p>よって、自身(自社)がターゲティング広告主である場合には、改正個人情報保護法に対応すべく、以下の点について確認を行う必要があります。</p><ul>
<li>提供している、またはされている個人関連情報やデータの内容、種類</li>
<li>提供先での個人関連情報の利用状況</li>
<li>プライバシーポリシーに記載されているCookieの利用目的、同意取得方法</li>
</ul><h3>GDPR適用対象外の日本企業ウェブサイトで、Cookie利用同意確認は必要か</h3><p>以上の通り、GDPR適用対象外であったとしても、<strong>改正個人情報保護法が定める「個人情報の第三者提供」を行うと認められる場合、Cookie利用同意確認が必要</strong>となります。</p><p><img src="https://www.ni4.jp/.assets/Cookie_01.png" alt="" width="842" height="595" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>なお、以下のように同意確認が不要となるCookieもあります。</p><ul>
<li>ウェブサイトの表示言語設定などを保存するもの</li>
<li>オンラインショップで買い物カゴに入れた商品を保存するもの</li>
<li>ユーザーのログイン状態を保存するもの など</li>
</ul><h2>Cookie利用同意確認ツールについて</h2><p>Cookieを取得・利用することについて、ユーザーに同意を求める際、それに<strong>同意が得られるまでCookieを取得することはできない</strong>ため、アクセス解析ツールなどを導入している場合も、この同意が得られるまではそれが<strong>動作しないように制御する必要</strong>があります。<br>そこで利用されるのが、Cookie取得同意確認ツールです。</p><h3>Cookie利用同意確認ツールとは</h3><p>ウェブサイトへアクセスした際、画面下部などに表示されるCookie取得への同意確認を得るツールを指します。<br>閲覧するユーザーが、Cookieの取得・利用(受け入れ)に同意しない場合、それを利用した機能が動作しないように制御することができます。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/thumbnail/Cookie_02-800wri.png" alt="" width="800" height="522" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>ソニーグループポータル https://www.sony.com/ja/</figcaption></figure><h3>Cookie利用同意確認ツールに必要な機能</h3><p>同意確認ツールには、以下の機能が求められます。</p><ul>
<li>明確な同意がない場合に、これを<strong>「みなし同意」としてCookieを取得しない</strong></li>
<li>Cookieの取得に<strong>同意しなかった場合もウェブサイトを閲覧可能</strong>とする(ゼロCookieロード)</li>
<li>Cookie取得に同意したユーザーが<strong>任意のタイミングでそれを拒否</strong>できる(オプトアウト)</li>
<li>ウェブサイトで取得したCookieを、<strong>その利用方法ごとに拒否</strong>できる(オプトアウト)</li>
</ul><p>たまに見かける<strong>「同意しないとウェブサイトへ進めない」</strong>ものや、<strong>「ボタンがあるだけでCookieを制御していない」</strong>ものは、<strong>同意確認ツールとしては意味のないもの</strong>となります。</p><h3>Cookie利用同意確認ツールの種類</h3><p><a href="https://cookie.userlocal.jp/">ユーザーローカル社が無料で提供しているCookie同意管理バナー</a>は、GoogleTagManagerとあわせて利用することで、これに同意しない場合のウェブサイト閲覧も可能としつつ、適切なCookieの管理が可能となります。<br>GoogleTagManagerの動作を制御するものとなるため、<strong>Cookieを利用するサービスごとにこれをコントロールすることはできません</strong>が、GA4のみの利用など、比較的少ないCookieを管理する場合に適しています。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fcookie.userlocal.jp%2F" title="Webサイト向けCookie同意管理バナーツール|株式会社ユーザーローカル" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://cookie.userlocal.jp/" target="_blank">Webサイト向けCookie同意管理バナーツール|株式会社ユーザーローカル</a></iframe><p>また、さまざまなベンダーが有料で提供しているCMP(Consent Management Platform)を利用すると、その<strong>利用目的ごとにCookie取得・利用をコントロールするなど、細かな設定が可能</strong>になります。<br>GDPRだけなくグローバルな対応が必要となる場合や、比較的多くのCookie(計測タグなど)をコントロールする場合に適しています。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fcookie.bizrisk.iij.jp" title="OneTrustクッキー同意管理バナー" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://cookie.bizrisk.iij.jp/cookie.bizrisk.iij.jp" target="_blank">OneTrustクッキー同意管理バナー</a></iframe><p><strong>GDPRや改正個人情報保護法における個人情報の第三者提供が認められる場合、これらのツールを利用する必要があります。</strong></p><h2>改正電気通信事業法とCookieポリシーの設置</h2><p>2023年6月に施行される改正電気通信事業法では、<strong>Cookieを含む閲覧履歴などの利用者情報を、第三者に提供している場合(個人情報との紐付けを問わない)や、ターゲティング広告などを運用している場合</strong>に、以下のいずれかの対応が必要となります。</p><ul>
<li>ウェブサイト上での通知・公表(Cookieポリシーの設置)</li>
<li>利用者本人の同意を得たうえでのCookie利用(Cookie利用同意確認ツール)</li>
<li>一度同意した場合も、後から拒否・削除できる仕組みの導入(オプトアウト)</li>
</ul><p><img src="https://www.ni4.jp/.assets/Cookie_03.png" alt="" width="842" height="595" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>Cookieなどの個人関連情報と個人データの紐づけを問わないため、例えば、<strong>GoogleAnalyticsなどのアクセス解析ツールを利用している場合も対象となり、最低限の対応としてCookieポリシーの設置・プライバシーポリシーの見直しが望ましい</strong>と考えられます。</p><h3>Cookieポリシーの掲載例</h3><p>このような状況から、日本企業のさまざまなウェブサイトでも、Cookieポリシーを明文化するようになってきました。</p><ul>
<li><a href="https://www.nttdata.com/jp/ja/info/cookie_policy/">クッキー(Cookie)ポリシー | NTTデータ - NTT DATA</a></li>
<li><a href="https://www.sony.com/ja/privacy/cookie.html">ソニーグループポータル | Cookieポリシー</a></li>
</ul><h2>まとめ</h2><p>GDPRと改正個人情報保護法、Cookie利用同意確認を可能とするツールについて、私が調べた内容をまとめてみました。<br>「あまり関係ないのかな?」と感じている方も多いと思いますが、漠然としたイメージだけでなく、自社に関係しているか、あるいはどのような対応を取るべきかを、あらためて確認しておく必要があるように思います。</p><p><strong>GDPRでは、Cookie利用同意確認ツールの導入に加え、「企業情報や利用目的、個人データの削除方法」も明記したプライバシーポリシー(Cookieポリシー)の見直しが必要</strong>となり、また、GDPRや改正個人情報保護法の第三者提供に該当せず、<strong>Cookie利用同意確認ツールの導入が不要なウェブサイトでも、改正電気通信事業法への対応、あるいは企業コンプライアンス・社会的責任として、プライバシーポリシー(Cookieポリシー)上で、Cookieの利用目的や個人関連情報の利用目的などを明示化しておくのが望ましい</strong>と考えています。</p><p>なお、プライバシーポリシー(Cookieポリシー)の具体的な内容については、法律の専門的な知識を必要とする場合もあるため、専門家へのご相談を含め検討ください。</p><p>以上、私が勉強した内容になります。<br>参考になれば幸いです!</p><h2>免責事項</h2><p>GDPRおよび改正個人情報保護法、CMPなどについて、できる限り正確な情報を提供するように努めておりますが、掲載内容の正確性・完全性・信頼性・最新性を保証するものではございません。<br>誤りが確認できた点については、随時修正を行いますが、この記事に掲載された内容によって生じた損害等の責任は負いかねますのでご了承願います。</p><p>最上部の写真素材は、<a href="https://unsplash.com/ja/%E5%86%99%E7%9C%9F/z8kriatLFdA?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>の<a href="https://unsplash.com/@vyshnavibisani?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Vyshnavi Bisani</a>が撮影した写真です。</p>
【MovableType.net新機能】月間50回まで使えるAIタイトル提案機能で、ブログのタイトル選びを効率化!
tag:movabletype.net,2003:post-2334047
2023-03-31T05:20:00Z
2023-03-31T05:20:22Z
話題のChatGPTを利用した新機能をさっそく試してみた話
ジャクスタポジション 西山
<p><img src="https://www.ni4.jp/.assets/ai-title_ogp.jpg" alt="" width="1200" height="630" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>ども、どもども。<br>このブログでも使用しているMovableType.netに、新たな機能が追加されました!</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmovabletype.net%2F2023%2F03%2Fopenai.html" title="タイトルのアイデアを提案する「AIタイトル提案機能」のベータ版を公開しました | MovableType.net" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://movabletype.net/2023/03/openai.html" target="_blank">タイトルのアイデアを提案する「AIタイトル提案機能」のベータ版を公開しました | MovableType.net</a></iframe><p>最近話題のAI、ChatGPTを利用した新機能!<br>昨年夏のMidjourney以降、私もちょこちょことAIを触っていて、ChatGPTでもいろいろと試していました。<br>そんな話題の新機能なので、さっそく試してみましょう!</p>
<h2>機能の概要</h2><p><img src="https://www.ni4.jp/.assets/ai-title_01.jpg" alt="" width="1280" height="605" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>詳しい説明は先ほどのリリース記事を確認していただくとして、大まかに以下のような内容になります。</p><ul>
<li>MovableType.net契約者であれば、どのプランでも利用可能</li>
<li>現在は、ウェブサイトごとに月間50回まで利用可能</li>
<li>どのようなタイトルにするか、5つの選択肢から選べる</li>
</ul><p>というわけで、私もさっそく<a href="https://www.ni4.jp/2023/03/25-130720.html">先日の記事</a>で試してみました!</p><h2>提案されるタイトルのバリエーション</h2><p>先ほどの記事を元に、それぞれの「雰囲気」でどう変わるか、AIから提案を受けてみました。<br>同じ雰囲気でも「もう一度タイトル案を出す」を利用すると、異なったバリエーションが生成されますが、ここでは1回ずつ試しています。</p><h3>注目を集めるようなタイトル</h3><p><img src="https://www.ni4.jp/.assets/ai-title_02.jpg" alt="" width="1280" height="778" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>ブログ記事、特にテクニカルなことを書いているブログで「よく見る」感じのタイトルが並びました。<br>カギカッコでキーワード部分を囲んだり、感嘆符(!)を使用しているのが特徴でしょうか。<br>思っていたよりもいい感じのタイトルを提案されました。</p><h3>問いかけるようなタイトル</h3><p><img src="https://www.ni4.jp/.assets/ai-title_03.jpg" alt="" width="1280" height="778" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>文末がすべて疑問形になっていますね(笑)<br>ブログ記事ではあまり見かけないかなーという印象のタイトルだし、ちょっと日本語としては違和感あるかもですね。<br>中学生英語の教科書にある日本語というか、英語の文法がベースになっているような気がします。</p><h3>シンプルなタイトル</h3><p><img src="https://www.ni4.jp/.assets/ai-title_04.jpg" alt="" width="1280" height="778" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>こちらはズバリわかりやすいですね。<br>ちょっとシンプル過ぎるかもしれませんが、要点は押さえている印象あるし、最後の「ディレクターでも」というのは、私には無かった発想なので、なるほど!と思いました。</p><h3>説明的なタイトル</h3><p><img src="https://www.ni4.jp/.assets/ai-title_05.jpg" alt="" width="1280" height="778" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>先ほどの「シンプルなタイトル」に少し肉付けしたような印象です。<br>わかりやすいし、どこか書籍タイトルのような印象もありますね。<br>ただ、ちょっと行き過ぎた表現(適したとか、メリット・デメリットなど)があるなーという気がします。</p><h3>夢のようなタイトル</h3><p><img src="https://www.ni4.jp/.assets/ai-title_06.jpg" alt="" width="1280" height="778" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>ちょっと笑ってしまいましたが、どれも「夢のような」とか「叶える」とかが含まれていて、雰囲気のキーワードをそのまま取り入れている感じありますね(笑)<br>40文字以内で叶える!とか、どうしてそうなった感が否めません。</p><h2>タイトル提案の元になっている情報</h2><p>先ほどまでの画像でも分かる通り、提案されたタイトルは、ブログ記事(本文・続き)から1,000文字程度を抽出したテキストをベースにしています。<br>この1,000文字というのは、ChatGPTで利用できる日本語文字数の上限から設定されているようですが、ChatGPT本体の利用時は以下のような方法でこれを回避することもできるみたいですね。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.dr-harv.com%2Fpost7862%2F" title="ChatGPTの文字数制限を突破する方法 - dr-harv-blog" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://www.dr-harv.com/post7862/" target="_blank">ChatGPTの文字数制限を突破する方法 - dr-harv-blog</a></iframe><p>ただ、ブログ記事が長くなってしまい、1,000文字を超えるケースも、それほど珍しくはないと思います。<br>今回利用した記事はおよそ2,300文字なんですが、それでも倍以上になってしまうので、記事の後半部分は加味されないことになってしまいます。<br>ChatGPTであれば、質問の仕方を変えたり、状況を限定したり、質問を何度か繰り返して精度を上げていくこともできますが、本機能ではそれは難しそうです。</p><h2>よりベターなタイトル提案を受けるには</h2><p>そこで、記事の中で特に言いたいことを、箇条書きにして情報源として与えてみました。</p><p><img src="https://www.ni4.jp/.assets/ai-title_07.jpg" alt="" width="1280" height="778" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>たったこれだけですが、かなり私の意図した雰囲気に近い提案を受けることができるようになりました。<br>このような感じで、タイトルの中に含めたい要素を任意で入力していき、絞り込む場合は、提案された内容をうけてその要素を入れ替えていくというのが良さそうです。</p><p>あるいは、先ほどの「ChatGPTの文字数制限を突破する方法」を使って、ChatGPTにブログ記事を1,000文字以内に要約してもらってから利用するのも良い方法かもしれませんね。(何度か試しましたが、上手くいきませんでした汗)</p><p>私もブログ記事のタイトルは最後に考えることが多いのですが、これがなかなか難しい(欲張ってしまう)ものです。<br>そんなとき、AIのサポートを受けてタイトルを決める材料が得られるのは、手軽で使い勝手も良さそうです!</p><p>ちなみに、今回の記事のタイトルも、AIから提案を受けたものを使用しています。</p><p><img src="https://www.ni4.jp/.assets/ai-title_08.jpg" alt="" width="1280" height="865" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>何度か試していて気がついたのですが、もしかしたらMovableType.netの場合は、筆者の「クセ」も参考情報にしている?ような印象も受けましたが…、さすがにそれはないですかね(笑)</p>
Macのローカルサーバー構築手順【SSL/バーチャルホスト編】
tag:movabletype.net,2003:post-2330473
2023-03-25T04:08:00Z
2023-03-25T04:13:30Z
ども、どもども。 前回・前々回と、MAMPを利用したローカル環境の構築と、利用す...
ジャクスタポジション 西山
<p><img src="https://www.ni4.jp/.assets/local-dev_ogp-03.jpg" alt="" width="1200" height="630" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>ども、どもども。<br><a href="https://www.ni4.jp/2023/03/25-130720.html">前回</a>・<a href="https://www.ni4.jp/2023/03/25-130810.html">前々回</a>と、MAMPを利用したローカル環境の構築と、利用するPHPバージョンの変更を実施してきました。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.ni4.jp%2F2023%2F03%2F25-130720.html" title="Macのローカルサーバー構築手順【MAMP導入編】 | www.ni4.jp" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://www.ni4.jp/2023/03/25-130720.html" target="_blank">Macのローカルサーバー構築手順【MAMP導入編】 | www.ni4.jp</a></iframe><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.ni4.jp%2F2023%2F03%2F25-130810.html" title="Macのローカルサーバー構築手順【PHP追加編】 | www.ni4.jp" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://www.ni4.jp/2023/03/25-130810.html" target="_blank">Macのローカルサーバー構築手順【PHP追加編】 | www.ni4.jp</a></iframe><p>続けてこの記事では、ローカル環境へのhttpsアクセスの設定と、SSL証明書の導入、そしてバーチャルホストを利用した複数環境の作成を進めていきたいと思います。</p><p>ローカル環境ではSSL証明書はなくとも良いかもしれませんが、ブラウザに警告(Chromeだと「保護されていない通信」)が表示され続けるのは落ち着かないので、SSL証明書を導入してみることにしました。<br>また、私のようにウェブサイト構築の仕事をしていると、ウェブサイト毎に開発環境が用意されていたほうが、なにかと便利だと思うので、今回はバーチャルホストの設定までやってみることにしました。</p><p>参考になるウェブサイトや記事はたくさんありますが、ここも自身の備忘録として、まとめておこうと思います。</p>
<h2>ローカル開発環境にSSL証明書を設定する</h2><p>ローカル環境でhttps通信(httpsでのアクセス)を行う場合、いわゆるオレオレ証明書(自己署名証明書)を用意することで、それ自体は可能になるのですが、ブラウザに「保護されていない通信」などと表示されてしまいます。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/local-dev_13.png" alt="" width="1280" height="575" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>Google Chromeの警告</figcaption></figure><p>これはインストールした証明書が、<strong>認証局(CA:Certification Authority)による証明を受けていないため、暗号化はできているけれど、証明書そのものは何の信用も無い</strong>ことを意味しているようです。</p><p>今回は、以下の記事を参考に、ローカル認証局の証明書も自動で発行・インストールできる mkcert というツールを利用して、https通信とSSL証明書の導入を進めることにしました。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fparashuto.com%2Frriver%2Ftools%2Fmkcert-for-local-ssl-dev-env" title="ローカル開発環境にSSLを設定できるmkcertがめちゃくちゃ便利だった | Rriver" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://parashuto.com/rriver/tools/mkcert-for-local-ssl-dev-env" target="_blank">ローカル開発環境にSSLを設定できるmkcertがめちゃくちゃ便利だった | Rriver</a></iframe><p>ここでもまた、Homebrewが登場しますね。<br>ほんとにこのツールを使う機会が増えてきました。<br>めちゃくちゃ助かります。</p><p>なお、上記手順の途中、mkcert -install というコマンドが出てきますが、これを実行した際、</p><pre><code class="html">The local CA is now installed in the system trust store! ⚡️</code></pre><p>とメッセージが表示されます。<br>これが、ローカル認証局を証明書ストア(Macではキーチェーンアクセス)に追加した、というメッセージになります。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/local-dev_14.png" alt="" width="1280" height="674" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>mkcertで作成したローカル認証局の証明書がキーチェーンアクセスに追加されていることを確認</figcaption></figure><p>最初この部分で誤ってしまい、mkcert install とコマンド入力していたために、ユーザーディレクトリのルートに install-key.pem と install.pem が作られてしまい、「保護された通信にならない…!」とかなり迷子になってしまいました…<br>(上記の完了メッセージが出ていないことに気がついていませんでした)</p><p>ともあれ、上記参考サイトの手順通り、httpd.conf / httpd-ssl.conf の設定を進めていくと、httpsでアクセスした際にもきちんと保護された通信という表示内容になります。</p><p><img src="https://www.ni4.jp/.assets/local-dev_15.png" alt="" width="1280" height="589" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><h2>バーチャルホストの設定</h2><p>ローカル環境でウェブサイトなどを構築していく際、ここまでの設定だとブラウザに入力するアドレスは、常に https://localhost/ となります。<br>MAMPでは、ドキュメントルートを変更することができますが、その都度、変更していくのもなかなか面倒です。</p><p>そこで、こちらの記事を参考に、MAMPにバーチャルホストを設定して、アクセスするアドレス毎に、参照するディレクトリを変更したいと思います。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fqiita.com%2Feryuus1%2Fitems%2F9300e6d56729799bae5d" title="MAMPを使って複数バーチャルホストのローカル環境を設定する - Qiita" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://qiita.com/eryuus1/items/9300e6d56729799bae5d" target="_blank">MAMPを使って複数バーチャルホストのローカル環境を設定する - Qiita</a></iframe><p>上記の記事で、hostsの編集についても記載されていますが、私は以前からhostsの編集には、iHostというツールを利用していたので、今回もこれを利用しました。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fliginc.co.jp%2F594226" title="ターミナルが苦手なあなたに!Macでhostsファイルを簡単に編集するアプリを紹介 | 株式会社LIG(リグ)|DX支援・システム開発・Web制作" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://liginc.co.jp/594226" target="_blank">ターミナルが苦手なあなたに!Macでhostsファイルを簡単に編集するアプリを紹介 | 株式会社LIG(リグ)|DX支援・システム開発・Web制作</a></iframe><p>今回、バーチャルホストのアドレスを skeleton-cart.local にしたかったので、iHostはこのように設定しています。</p><p><img src="https://www.ni4.jp/.assets/local-dev_16.png" alt="" width="812" height="540" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>ここまでの設定を終え、MAMPを起動して skeleton-cart.local にアクセスすると、思ったように表示することができました!</p><p><img src="https://www.ni4.jp/.assets/local-dev_17.png" alt="" width="1200" height="709" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><h2>バーチャルホストのアドレスにもSSL証明書をインストール</h2><p>せっかくなので、バーチャルホストに設定したアドレスにもSSL証明書をインストールして、https通信できるようにしたいと思います。</p><p>先ほどと同じように、mkcert で skeleton-cart.local の証明書を作成して、こちらの記事を参考に httpd-ssl.conf に必要な設定を追加していきます。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fweb-niar.com%2Fblog%2Fmamp-ssl-for-mac%2F" title="MAMPのバーチャルホストでSSLを使えるようにする for Mac | WEB制作事務所 NIAR" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://web-niar.com/blog/mamp-ssl-for-mac/" target="_blank">MAMPのバーチャルホストでSSLを使えるようにする for Mac | WEB制作事務所 NIAR</a></iframe><p>なお、私が httpd-ssl.conf に追加した内容は以下のとおりです。</p><pre><code class="html"><VirtualHost *:443>
DocumentRoot "/Applications/MAMP/htdocs/SkeletonCart"
ServerName skeleton-cart.local
SSLEngine on
SSLCertificateFile /Applications/MAMP/conf/apache/keys/skeleton-cart.local.pem
SSLCertificateKeyFile /Applications/MAMP/conf/apache/keys/skeleton-cart.local-key.pem
</VirtualHost></code></pre><p>上記が完了した後、httpsでアクセスすると、思っていたとおりにできました!</p><p><img src="https://www.ni4.jp/.assets/local-dev_18.png" alt="" width="1200" height="709" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><h2>キーチェーンの追加とhostsファイルの書き換えについて</h2><p>今回、ローカル環境のhttps化には、mkcertを使用してローカル認証局を登録する(キーチェーンアクセス/ローカルの証明書ストアの設定)を行い、その閲覧にはバーチャルホストの設定(hostsの変更)を行いましたが、手軽にできる反面、それらの設定を変えるべきか?という問題もありそうです。</p><p>ローカル認証局のインストールに失敗してSSL証明書が上手く使えずに困っていたときに、こちらの情報を教えてもらいました。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fblog.jxck.io%2Fentries%2F2020-06-29%2Fhttps-for-localhost.html" title="ローカル開発環境の https 化 | blog.jxck.io" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://blog.jxck.io/entries/2020-06-29/https-for-localhost.html" target="_blank">ローカル開発環境の https 化 | blog.jxck.io</a></iframe><blockquote>
<p>個人の場合、普段の開発でカジュアルに hosts や証明書ストアをいじるよりも、実在するドメインを用意し、本物の証明書を取ってしまうのが一番安全かつ完全だ。何も変えず何も騙さず、何の危険もなく正しく動く。</p>
</blockquote><p>ローカル環境をhttps化する方法を調べると、その多くがmkcertの利用(ローカルの証明書ストアの変更)とhostsの変更について触れていますが、実在するドメイン(サブドメイン)と、Let'sEncryptを利用すれば、これらを行う必要がないというのは、たしかに良い方法だなと思いました。</p><p>今回は「情報が多い」「手軽だ」という理由だけで、これらの変更を行う方法で進めましたが、その操作をどこまで許容すべきかを考えると、こちらのほうが良さそうとも考えています。</p><h2>ローカル環境構築のまとめ</h2><p>ここまで3回に分けて、私が行ったローカル環境の構築手順を備忘録としてまとめてきました。</p><p>いくつか躓いたところもありましたが、結果的にはこれまでよりもサーバーのことを少し理解した上で、ローカル環境を作ることができたと思います。<br>ターミナルを使用することにも慣れてきて、以前よりは「黒い画面」も恐くはありません(笑)</p><p>今後はこの環境を定期的にメンテナンスしつつ、必要なものを追加していくと、さらにいろいろなことが覚えられそうです。<br>私が主に利用するのは自社製品の動作確認や、ちょっとしたPHPプログラムの作成・確認などになりますが、以前よりも仕事がしやすいカタチにはできたかなと思います!</p>
Macのローカルサーバー構築手順【PHP追加編】
tag:movabletype.net,2003:post-2329956
2023-03-25T04:08:00Z
2023-03-25T04:12:29Z
MAMPのダウンロードパッケージに含まれていない、別のPHPバージョンを追加することに成功した話。
ジャクスタポジション 西山
<p><img src="https://www.ni4.jp/.assets/local-dev_ogp-02.jpg" alt="" width="1200" height="630" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>ども、どもども。<br>というわけで、<a href="https://www.ni4.jp/2023/03/25-130720.html">前回の記事</a>では、MAMPを利用したローカル環境構築と、そこからのメール送信部分までを進めました。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.ni4.jp%2F2023%2F03%2F25-130720.html" title="Macのローカルサーバー構築手順【MAMP導入編】 | www.ni4.jp" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://www.ni4.jp/2023/03/25-130720.html" target="_blank">Macのローカルサーバー構築手順【MAMP導入編】 | www.ni4.jp</a></iframe><p>ただ、前回記事の最後にあったとおり、MAMPでは現在、パッケージに同梱されているバージョンのPHPしか利用できないようで、それ以外のバージョンを利用したい場合は、自分でインストールするしか無いようでした。<br>いろいろ検索するも、同梱されているバージョンの切り替えは見つかるのですが、そもそも同梱されていない場合の手段が見つかりません。</p><p>そんな中、私と同じように困っていた方の記事を発見し、そこから <a href="https://gist.github.com/codeadamca/09efb674f54172cbee887f04f700fe7c">Adding Versions of PHP to MAMP on a Mac( 訳:MacのMAMPにPHPのバージョンを追加する )</a> という情報を見つけました。</p><p>これなら行けるかも!と試した結果、ダウンロードしたパッケージに同梱されていなかったPHP 8.0.28 の導入に成功したので、今回はその流れを備忘録として残しておこうと思います。</p>
<h2>Homebrewの環境を準備</h2><p>先ほどの記事に、Homebrewを使用してインストールしたPHPを、MAMPへコピーして利用する方法が書かれていたので、私もそれを試してみることにしました。<br>ちなみに、Homebrewのインストールについては、過去の記事で触れています。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.ni4.jp%2F2020%2F12%2F23-190500.html" title="MacのターミナルでSSL証明書取得申請に必要なCSRを作ってみた | www.ni4.jp" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://www.ni4.jp/2020/12/23-190500.html" target="_blank">MacのターミナルでSSL証明書取得申請に必要なCSRを作ってみた | www.ni4.jp</a></iframe><p>まずはMacにインストールされているPHPのバージョンを確認。</p><pre><code class="html">php -v</code></pre><p>ターミナルに上記を入力して、ターンッ!</p><pre><code class="html">zsh: command not found: php</code></pre><p>なんと!PHPが入っていない…でも考えてみたら、<strong>これまでPHPはインストールしたことなかった</strong>かも?<br>ちなみに、Macに標準でインストールされているPHPは、macOS12からはインストールされなくなったらしいです。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fguntablog.com%2Fmonterey%2F" title="【PHPが使えない!】MacをMontereyにアップデートした場合の解決方法 | Guntablog" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://guntablog.com/monterey/" target="_blank">【PHPが使えない!】MacをMontereyにアップデートした場合の解決方法 | Guntablog</a></iframe><p>というわけで、上記の記事を参考に、PHPのインストールから始めることにしました。</p><p>その前に、Homebrewのバージョンも上げておこうと思ったのですが、確認しようとすると、また以前のようなエラーとなりました…</p><pre><code class="html">Warning: Git could not be found in your PATH.
Warning: No developer tools installed.
Warning: You are using macOS 13.
Warning: Ruby version 2.6.10 is unsupported on 13.
Warning: Homebrew's "sbin" was not found in your PATH but you have installed formulae that put executables in /usr/local/sbin.</code></pre><p>どうやら、現在インストールしてあるHomebrewは、macOS13に対応していないようですね…<br>というわけで、過去の自分の記事を参考にアップデートを進めました。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.ni4.jp%2F2021%2F09%2F04-141000.html" title="Homebrewを使おうとしたら「Git must be installed and in your PATH!」とエラーが出てしまった | www.ni4.jp" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://www.ni4.jp/2021/09/04-141000.html" target="_blank">Homebrewを使おうとしたら「Git must be installed and in your PATH!」とエラーが出てしまった | www.ni4.jp</a></iframe><p>備忘録、大切…<br>上記のようにいろいろとWarningが出ていましたが、update と upgrade 、cleanupを順番に進めていき、無事にHomebrewはバージョン4.0.6になりました。</p><pre><code class="html">brew -v
Homebrew 4.0.6</code></pre><h2>HomebrewにPHPをインストール</h2><p>Homebrewの準備ができたので、こちらの記事を参考にPHPをインストールします。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fzenn.dev%2Fryuu%2Farticles%2Fsetup-php-brew" title="【macOS Monterey】HomebrewでPHPの実行環境をセットアップする" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://zenn.dev/ryuu/articles/setup-php-brew" target="_blank">【macOS Monterey】HomebrewでPHPの実行環境をセットアップする</a></iframe><p>2023年3月現在、brew search php で出てきたのはこちらでした。</p><pre><code class="html">brew search php
==> Downloading https://formulae.brew.sh/api/formula.jws.json
######################################################################## 100.0%
==> Downloading https://formulae.brew.sh/api/cask.jws.json
######################################################################## 100.0%
==> Formulae
brew-php-switcher php-cs-fixer@2 phpbrew phpstan
php php@7.4 phplint phpunit
php-code-sniffer php@8.0 phpmd pcp
php-cs-fixer php@8.1 phpmyadmin pup</code></pre><p>ひとまず、提供されている最新版 PHP8.1 をインストールしました。<br>インストールが進むと、PATHを通してと出るので、以下のようにコマンドを入れます。</p><pre><code class="html">echo 'export PATH="/usr/local/opt/php@8.1/bin:$PATH"' >> ~/.zshrc</code></pre><pre><code class="html">echo 'export PATH="/usr/local/opt/php@8.1/sbin:$PATH"' >> ~/.zshrc</code></pre><p>PATHを通したあとは、それが反映されるようにコマンドを入力します。</p><pre><code class="html">source ~/.zshrc</code></pre><p>その上で、PHPのバージョンを確認すると、以下のようにPHP8.1.17がインストールできました!</p><pre><code class="html">php -v
PHP 8.1.17 (cli) (built: Mar 16 2023 13:19:00) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.17, Copyright (c) Zend Technologies
with Zend OPcache v8.1.17, Copyright (c), by Zend Technologies</code></pre><h2>PHP 8.0.28 をインストール</h2><p>ここで喜んでいる場合ではない(汗)<br>当初の目的は、バージョン 8.0.28 を利用することだったので、こちらの記事を参考に、古いバージョンをインストールしてみることに。(ちなみに、8.1はMAMPをインストールした際にも同梱されていました。)</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fqiita.com%2Facinaces0519%2Fitems%2Fb8b1f460ede9b6c2e816" title="HomebrewでPHP7.3インストールする方法2022年版 - Qiita" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://qiita.com/acinaces0519/items/b8b1f460ede9b6c2e816" target="_blank">HomebrewでPHP7.3インストールする方法2022年版 - Qiita</a></iframe><p>まず、Homebrewで 8.0.28 が提供されているのかを調べてみると、こちらを発見。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fformulae.brew.sh%2Fformula%2Fphp%408.0" title="php@8.0 — Homebrew Formulae" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://formulae.brew.sh/formula/php@8.0" target="_blank">php@8.0 — Homebrew Formulae</a></iframe><p>上記で8.0.28 が提供されていることを確認できたので、先ほどの記事を参考に、インストールを進めます。</p><pre><code class="html">brew unlink php@8.1</code></pre><pre><code class="html">brew tap shivammathur/php</code></pre><pre><code class="html">brew reinstall shivammathur/php/php@8.0</code></pre><p>上記を順番に実施して、インストールが完了したら、PATHを修正します。</p><pre><code class="html">echo 'export PATH="/usr/local/opt/php@8.0/bin:$PATH"' >> ~/.zshrc</code></pre><pre><code class="html">echo 'export PATH="/usr/local/opt/php@8.0/sbin:$PATH"' >> ~/.zshrc</code></pre><pre><code class="html">source ~/.zshrc</code></pre><p>この状態でバージョンを確認すると、8.0.28が正常にインストールできていることが確認できました!</p><pre><code class="html">php -v
PHP 8.0.28 (cli) (built: Feb 15 2023 01:59:22) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.28, Copyright (c) Zend Technologies
with Zend OPcache v8.0.28, Copyright (c), by Zend Technologies</code></pre><h2>MAMP環境へ必要なファイルをコピー</h2><p>これでMacにインストールされたPHPを目的のバージョンにできたので、先ほどの記事を参考にMAMP環境へPHP8.0.28をインストールできるようになりました。</p><p>まずは以下のとおり、/usr/local/Cellar/php に入っている目的のバージョンのフォルダをコピーします。</p><blockquote>
<p>First we need to copy the installed PHP files to MAMP. Using Finder, navigate to /usr/local/Cellar/php and you should find a folder named after the installed version of PHP. For me it was 8.1.8. Copy this folder.<br><a href="https://gist.github.com/codeadamca/09efb674f54172cbee887f04f700fe7c">https://gist.github.com/codeadamca/09efb674f54172cbee887f04f700fe7c</a></p>
</blockquote><p>このフォルダへの移動はFinderの「移動」にある「フォルダへ移動」から進みます。</p><p><img src="https://www.ni4.jp/.assets/local-dev_06.png" alt="" width="1280" height="701" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>移動した先で、8.0.28 のフォルダをコピーします。</p><p><img src="https://www.ni4.jp/.assets/local-dev_07.png" alt="" width="1280" height="493" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>コピーしたフォルダを、MAMPのPHPを保存している場所へ貼り付けます。</p><blockquote>
<p>Navigate to the folder that MAMP stores PHP versions. For me this was /Applications/MAMP/bin/php. Paste this folder here.<br><a href="https://gist.github.com/codeadamca/09efb674f54172cbee887f04f700fe7c">https://gist.github.com/codeadamca/09efb674f54172cbee887f04f700fe7c</a></p>
</blockquote><p>貼り付けた後は、フォルダの名前をMAMPのルールにあわせてリネームしておきます。</p><p><img src="https://www.ni4.jp/.assets/local-dev_08.png" alt="" width="1280" height="531" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>続けて、PHPのmoduleファイルをコピーを進めます。</p><blockquote>
<p>Next we need the PHP modile file. Navigate to /usr/local/lib/httpd and copy the modules folder. Inside this folder is the PHP module file names libphp.so.<br><a href="https://gist.github.com/codeadamca/09efb674f54172cbee887f04f700fe7c">https://gist.github.com/codeadamca/09efb674f54172cbee887f04f700fe7c</a></p>
</blockquote><p>ただ、上記の /usr/local/lib/httpd には、module/libphp.so がありませんでした。<br>というか、httpdというフォルダが無かったです(汗)</p><p>あれこれと探してみたところ、/usr/local/opt/php@8.0/lib/httpd/ に発見!</p><p><img src="https://www.ni4.jp/.assets/local-dev_09.png" alt="" width="1280" height="298" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>このmodulesフォルダをコピーします。</p><blockquote>
<p>Navigate to /Applications/MAMP/bin/php/php8.1.8 and paste the modules folder.<br><a href="https://gist.github.com/codeadamca/09efb674f54172cbee887f04f700fe7c">https://gist.github.com/codeadamca/09efb674f54172cbee887f04f700fe7c</a></p>
</blockquote><p>先ほど作ったMAMP環境のPHPのフォルダ内へ貼り付けます。</p><p><img src="https://www.ni4.jp/.assets/local-dev_10.png" alt="" width="1280" height="530" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>以上でMAMP環境へのPHP8.0.28インストールが完了となります!</p><h2>MAMPを再起動</h2><p>MAMPを再起動すると、PHPバージョンで 8.0.28 が選択できるようになりました!</p><p><img src="https://www.ni4.jp/.assets/local-dev_11.png" alt="" width="1280" height="1079" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>PreferencesでPortsを設定して、サーバーを起動すると、無事にPHP 8.0.28 が利用できるようになりました。</p><p><img src="https://www.ni4.jp/.assets/local-dev_12.png" alt="" width="1280" height="578" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><h2>PHP追加編まとめ</h2><p>当初思っていたよりも遠回りになってしまいましたが、無事にMAMPのPHPを変更することができました。<br>HomebrewのアップデートとPHPインストールに時間がかかりましたが、それがなければもっとスムースだったと思います。<br>これでさまざまなバージョンのPHP環境を準備することができそうです。</p><p>あと、ターミナルともだいぶ仲良くなれてきた気がしています(笑)</p><p>次は、今回用意した環境で、SSLの設定や、バーチャルホストの設定を進めたいと思います!</p>
Macのローカルサーバー構築手順【MAMP導入編】
tag:movabletype.net,2003:post-2329931
2023-03-25T04:07:20Z
2023-03-25T04:07:20Z
MacでPHPやメール送信などの動作確認を行うべく、数年ぶりにMAMPでローカル環境を構築した話。
ジャクスタポジション 西山
<p><img src="https://www.ni4.jp/.assets/local-dev_ogp-01.jpg" alt="" width="1200" height="630" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>ども、どもども。<br>普段、ウェブサイト制作会社でディレクターとして仕事をしている私ですが、自社で開発・販売している<a href="https://www.juxtaposition.jp/skeleton-cart/">SKELETON CART(ショッピングカートシステム)</a>やMovable Type用プラグインで、リリース前の動作確認をすることも、私の仕事になっています。</p><p>新機能などの動作確認であればよいのですが、PHPのバージョンアップなど、サーバー環境に変化があった際の動作確認は、それと同じ環境を用意することが私には難しい場合も多く…。<br>そのようなときは開発担当に動作確認をお願いしていたのですが、業務の都合などでなかなかスムースに進められないことも多く、負担になっていないか、気になっていました。</p><p>そこで今回、数年ぶりにローカル環境を整えてみようと思い立ち、以下の条件を満たせる環境を構築してみました。</p><ul>
<li>先日<a href="https://www.sixapart.jp/movabletype/news/2023/03/15-1100.html">バージョンアップされたMovable Typeクラウド版の環境</a>にあわせ、PHPのバージョンは、7.4.33 / 8.0.28にしたい</li>
<li>上記の環境で、SKELETON CART(PHPプログラム)の動作確認ができるようにしたい</li>
<li>バーチャルホストで複数の環境を利用できるようにしたい</li>
</ul><p>最終的に目標は達成できたのですが、いろいろな作業をして初めて知ることも多かったので、いつものように「未来の自分への備忘録」として、ブログ記事にしておこうと思います。</p>
<h2>MAMPのインストール</h2><p>今回、ローカル環境の構築には、<a href="https://www.mamp.info/en/mamp/mac/">MAMP(無料版)</a>を選びました。<br>私のようなディレクターが、導入から日々運用していくことを考えた際、おそらくこれが一番手軽なのかなと思います。<br>インストールと初期設定は、こちらの記事を参考にさせてもらいました。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fcodeforfun.jp%2Fhow-to-install-mamp-windows-and-mac%2F" title="MAMPのインストール方法(Windows & Mac対応)|Code for Fun" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://codeforfun.jp/how-to-install-mamp-windows-and-mac/" target="_blank">MAMPのインストール方法(Windows & Mac対応)|Code for Fun</a></iframe><p>この記事にもありますが、インストーラーの指示に従っていけば、インストールから初期設定まで、簡単に進めることができます。</p><p>また、私がダウンロードした時点で、MAMPに同梱されていたPHPは、7.4.33 / 8.2.0 だったので、目標にしていたうちの1つ(PHP 7.4.33)はここでクリアすることができました。</p><p><img src="https://www.ni4.jp/.assets/local-dev_01.png" alt="" width="1280" height="573" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><h2>ローカル環境からのメール送信</h2><p>続けて、PHP7.4.33でのSKELETON CART動作確認を進めようとしましたが、マニュアルにあるとおりにSKELETON CARTをインストールしていて、ふと「メール送信ができない」ことに気が付き、こちらの記事を参考に、ローカル環境からでもGmailを利用してメール送信できるようにしました。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmito-lab.com%2Fmamp-email%2F" title="【わかりやすく解説】PHPを使ってローカル環境のMAMPからメールを送信するための設定方法|ミトラボ" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://mito-lab.com/mamp-email/" target="_blank">【わかりやすく解説】PHPを使ってローカル環境のMAMPからメールを送信するための設定方法|ミトラボ</a></iframe><p>Googleアカウントのアプリパスワードの設定場所が見つからなかったのですが、上記の記事(2021年9月)と現在では、ちょっと違っていて、2023年3月時点では、左ナビゲーションにある「セキュリティ」から、「2段階認証プロセス」を選択した先で見つけることができました。</p><p><img src="https://www.ni4.jp/.assets/local-dev_02.png" alt="" width="1280" height="638" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p><img src="https://www.ni4.jp/.assets/local-dev_03.png" alt="" width="1280" height="684" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>それ以外は参考記事の手順のままに進められました。<br>1点だけ、ターミナルでファイルを編集(INSERTモードで編集)した後、「wqを押して終了」とありますが、正確には <strong>:wq</strong> で編集モードを終了する(コロンが必要)部分だけ、気が付かずにちょっと困りました(汗)</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.koikikukan.com%2Farchives%2F2020%2F02%2F18-235555.php" title="vimのコマンド一覧: 小粋空間" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://www.koikikukan.com/archives/2020/02/18-235555.php" target="_blank">vimのコマンド一覧: 小粋空間</a></iframe><p>これで無事にメールを送信することができるようになり、PHP7.4.33環境でのSKELETON CARTの動作確認ができるようになりました。</p><h2>PHP8での動作確認</h2><p>ダウンロードしたMAMPに同梱されていたPHP8.2.0も、正常に動作していました。</p><p><img src="https://www.ni4.jp/.assets/local-dev_04.png" alt="" width="1280" height="605" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>MAMPには複数のPHPバージョンが同梱されていて、こちらの記事にあるように、好きなものを選択できるようになっています。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.kaname-gh.co.jp%2Fwordpress%2Fmamp-chang-phpversion%2F" title="MAMPでPHPのバージョンを追加(変更)する方法 | カナメグローバルホールディングス" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://www.kaname-gh.co.jp/wordpress/mamp-chang-phpversion/" target="_blank">MAMPでPHPのバージョンを追加(変更)する方法 | カナメグローバルホールディングス</a></iframe><p>ところが、私が利用したかったバージョン 8.0.28 は残念ながら同梱されていませんでした。<br>以下の記事では、同梱されていないPHPのバージョンもMAMPのウェブサイトからダウンロードできると書いてありますが、2023年3月時点では、そのダウンロードも見当たりませんでした。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fkazumich.com%2Fosx_free_mamp_php_change.html" title="OS X 無料版の MAMP で PHP のバージョンを標準から変更する方法 | kazumich.log" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://kazumich.com/osx_free_mamp_php_change.html" target="_blank">OS X 無料版の MAMP で PHP のバージョンを標準から変更する方法 | kazumich.log</a></iframe><p>調べてみると、<a href="https://www.php.net/downloads.php">PHPのウェブサイト</a>から、必要なバージョンをダウンロードして設置すると良いという記事も見かけましたが、残念ながら、そのままではMAMPが正常に起動してくれませんでした。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/local-dev_05.png" alt="" width="372" height="345" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>PHPのファイルを設置しただけだと、確認しろと言われてしまう…</figcaption></figure><h2>MAMP導入編まとめ</h2><p>というわけで、数年ぶりのローカル環境構築は、非常にスムースに進みました。<br>MAMPそのものも、以前より使いやすくなっているように感じましたし、ローカル環境からメール送信できるようになったのは嬉しかったです。<br>ターミナルの操作も、だんだんと慣れたのか、Gmailを利用したメール送信も問題なく進めることができました。</p><p>PHPのバージョンにこだわらなければ、これでローカル環境の準備は完了となりますが、PHP8.0.28でSKELETON CARTの動作確認を行うべく、引き続き環境構築を進めることに。</p><p>今回の記事はここまでですが、次は…</p><ul>
<li>PHP 8.0.28 の環境構築</li>
<li>SSL証明書の導入</li>
<li>バーチャルホストの設定</li>
</ul><p>これらを進めていくことになります。<br>長くなりそうなので、いくつかに分けて行きますが、自分はもちろん、誰かの参考になると幸いです!</p>
macOS版Chromeブラウザの言語設定は「システム環境設定」で変更できる
tag:movabletype.net,2003:post-2300137
2023-02-11T00:13:00Z
2023-02-11T00:14:01Z
Chromeブラウザの言語設定を変える方法を初めて知った話
ジャクスタポジション 西山
<p><img src="https://www.ni4.jp/.assets/form-language-test_ogp.jpg" alt="" width="1200" height="630" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>ども、どもども。<br>先日書いた <a href="https://www.ni4.jp/2023/02/09-130100.html">Gmailにメールが届かないときは、SPFレコードをDNSに登録しよう</a> という記事を、その道のプロの方が読んでくれて、「とても読みやすい」と言ってくれたことが嬉しい、そんなワタシです。</p><p>さてさて、このブログでも利用している <a href="https://movabletype.net/">Saas型CMS「MovableType.net」</a>、その関連サービスに <a href="https://movabletype.net/form/">MovableType.netフォーム</a> がありますが、このフォームは多言語対応が可能になっていて、日本語の他に英語と中国語(繁體中文/台湾)に対応しています。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/form-language-test_01.png" alt="" width="1280" height="800" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>言語設定を「英語」にしたフォームのサンプル</figcaption></figure><p>先日、クライアントさんから「英語版のフォームを用意したい」と依頼があったのですが、作ってみると<strong>エラーがあった際のメッセージが日本語で表示されてしまう</strong>ことに気が付きました。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/form-language-test_02.png" alt="" width="1280" height="864" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>英語設定なのにエラー部分に日本語が…</figcaption></figure><p>ちゃんと英語設定になっているのかな?と不安になり、シックス・アパート社の早瀬さんに確認すると、以下のマニュアルを教えてくれました。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmovabletype.net%2Fsupport%2Fform%2Falart-setting-lang-japanese.html" title="使用言語とアラート表示の言語について - マニュアル | MovableType.net" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://movabletype.net/support/form/alart-setting-lang-japanese.html" target="_blank">使用言語とアラート表示の言語について - マニュアル | MovableType.net</a></iframe><blockquote>
<p>MovableType.net フォームに入力時、「必須」にした項目が未記入、または未選択の場合に表示されるエラーメッセージは、フォーム作成時に設定した使用言語とは関係なく、ブラウザに設定された言語で表されます。<br><a href="https://movabletype.net/support/form/alart-setting-lang-japanese.html">https://movabletype.net/support/form/alart-setting-lang-japanese.html</a></p>
</blockquote><p>私はMacでChromeを使用しているので、それならと<strong>Mac版Chromeの言語設定変更</strong>を検索してみたのですが、見つかった情報はどれも上手くいきません。<br>そんな中、以下のようなヘルプを見つけました。</p><blockquote>
<p>Mac または Linux の場合: Chrome は、パソコンで使用しているデフォルトのシステムの言語で自動的に表示されます。<br><a href="https://support.google.com/chrome/answer/173424">https://support.google.com/chrome/answer/173424</a></p>
</blockquote><p>もしかしてMac本体の言語設定を変更するのか?…これはなかなかハードルが高い…と思っていると、タイミングよく鷹野さんのツイートを目にしました。</p><blockquote class="twitter-tweet"><p lang="ja" dir="ltr">Spotifyで洋楽がカタカナ表記されてしまうのがイヤ。しかし、デモの都合、Macの「優先する言語」は日本語にしておきたい。<br> ↓ ↓ ↓<br>システム環境設定の[言語と地域]-[アプリケーション]でアプリ、言語を指定。 <a href="https://t.co/vBVE3eUhcU">pic.twitter.com/vBVE3eUhcU</a></p>— 鷹野 雅弘 Masahiro Takano (@swwwitch) <a href="https://twitter.com/swwwitch/status/1618029886769352704?ref_src=twsrc%5Etfw">January 24, 2023</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script><p>これを試してみたところ、MovableType.netフォームの英語設定と中国語設定もちゃんと確認できたので、今日はその方法を残しておこうと思います。</p>
<h2>システム環境設定で言語を変更する</h2><p>まずはMacのシステム県境設定を開き、「言語と地域」を選択します。<br>なお、私はmacOS Montereyを使用していますが、Venturaを使用されている方は、先ほどの鷹野さんのツイートの続きを参考にしてください。</p><p><img src="https://www.ni4.jp/.assets/form-language-test_03.png" alt="" width="1280" height="1116" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>次の画面で、左下の「+」を選択し、アプリケーションを選びます。</p><p><img src="https://www.ni4.jp/.assets/form-language-test_04.png" alt="" width="1280" height="1055" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>今回使用するのはChromeなので、その言語設定を英語にします。</p><p><img src="https://www.ni4.jp/.assets/form-language-test_05.png" alt="" width="1280" height="482" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>上記の「追加」をクリックすると、Chromeブラウザの再起動を求められます。</p><p><img src="https://www.ni4.jp/.assets/form-language-test_06.png" alt="" width="744" height="724" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>再起動すると以下のように言語が英語になっていて、Chromeのメニューも英語になっていることが確認できると思います。</p><p><img src="https://www.ni4.jp/.assets/form-language-test_07.png" alt="" width="1280" height="1055" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><h2>英語版のMovableType.netフォームにアクセスしてみる</h2><p>この状態で先ほどのフォームを開き、エラーを表示させると、ちゃんと英語になっていることが確認できました!</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/form-language-test_08.png" alt="" width="1280" height="864" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>エラーの内容が英語表記になっている</figcaption></figure><p>中国語(繁體中文/台湾)も試してみると、こちらもちゃんと表示されていました。<br>ちなみに「ちゃんと」と言っていますが、<strong>中国語(しかも繁体字)は読めません(汗</strong></p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/form-language-test_09.png" alt="" width="1280" height="864" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>中国語で表示されるエラー</figcaption></figure><h2>もしかして他の言語もいける?</h2><p>先ほどのマニュアルに気になる表現がありました。</p><blockquote>
<p>フォーム作成時に使用言語を日本語にして作成した場合でも、ブラウザの設定言語が日本語なら日本語、英語なら英語、中国語なら中国語、スペイン語ならスペイン語で表示されます。</p>
</blockquote><p>スペイン語?<br>MovableType.netフォームの使用言語にスペイン語はないのに、それにも対応?<br>ブラウザの設定を変更すれば、どの言語でも行けるということか!</p><p>というわけで、<strong>Chromeの言語をアラビア語に設定変更</strong>して試してみました!</p><p><img src="https://www.ni4.jp/.assets/form-language-test_10.png" alt="" width="1280" height="864" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p><strong>まったく読めませんが、たぶんアラビア語になってますね!(笑)</strong><br>ちなみにアラビア語にすると、文字だけでなくブラウザのタブまで右から並ぶようになったのが面白かったです。<br>ぜひ試してみてください(笑)</p><p>という感じで、MovableType.netフォームの多言語設定を確認することができました。<br>その確認方法を調べていて、アプリごとの言語設定が変更できることを知ったのは良かったです。<br>英語と中国語以外はあまり使う機会はないかも知れませんが、知っておくと便利そうです!</p>
Gmailにメールが届かないときは、SPFレコードをDNSに登録しよう
tag:movabletype.net,2003:post-2298584
2023-02-09T04:01:00Z
2023-02-10T00:22:40Z
独自ドメインでメール運用する際に必要となるSPFレコードについて、いろいろと調べたことをまとめた話
ジャクスタポジション 西山
<p><img src="https://www.ni4.jp/.assets/spf_ogp.jpg" alt="" width="1200" height="630" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>ども、どもども。<br><a href="https://www.juxtaposition.co.jp/" target="_blank" rel="noopener">札幌のウェブサイト制作会社 ジャクスタポジション</a> 西山です。<br>先日リニューアルしたウェブサイト、さり気なく宣伝してみました。</p><p>さて、2022年の3月〜4月頃から、以下のようなご相談をいただくことが増えました。<br>Googleなどで検索してみても、多くの方が同じような状況になっており、対応策もいろいろと案内されています。</p><ul>
<li>独自ドメインを使用したメールアドレスから、Gmail宛にメールが送れなくなった</li>
<li>Gmail宛に届いたメールに「ご注意ください」や「問題がある」と警告が表示されている</li>
<li>メールフォームやショッピングカートなどのプログラムから、Gmail宛にメールが送れなくなった</li>
</ul><p>先日も同じようなご相談があったので、私が実施した対応を、自身の備忘録としてまとめておこうと思います。</p>
<h2>今回の前提条件</h2><p>今回は、「ウェブサイトとメールは<strong>同じ独自ドメインを使用</strong>しているが、<strong>ウェブサーバーとメールサーバーは異なるものを使用</strong>している」という前提条件になります。</p><div class="vertical"><table style="width: initial;"><colgroup><col style="width: 49.9443%;"><col style="width: 49.9443%;"></colgroup>
<tbody>
<tr>
<th>ウェブサイトのドメイン(ウェブサーバー)</th>
<td>example.com</td>
</tr>
<tr>
<th>ウェブサーバーのIPアドレス</th>
<td>198.51.100.1</td>
</tr>
<tr>
<th>メールサーバーのドメイン(メールサーバー)</th>
<td>example.co.jp</td>
</tr>
</tbody>
</table></div><p>上記の内容で、以下のようにDNSレコードを設定しているものとします。</p><div class="scroll"><table style="width: initial;"><colgroup><col style="width: 24.9721%;"><col style="width: 24.9721%;"><col style="width: 24.9721%;"><col style="width: 24.9721%;"></colgroup>
<tbody>
<tr>
<th>ホスト名</th>
<th>TYPE</th>
<th>VALUE</th>
<th>優先</th>
</tr>
<tr>
<td>example.com</td>
<td>A</td>
<td>198.51.100.1</td>
<td> </td>
</tr>
<tr>
<td>example.com</td>
<td>MX</td>
<td>example.co.jp</td>
<td>10</td>
</tr>
</tbody>
</table></div><h2>Gmailで受信したメールに「ご注意ください」「問題がある」と表示される</h2><p>2022年3月頃から、独自ドメインを使用したメール(例: info@example.com )からGmail宛にメールを送った際、以下のような警告が表示されるようになりました。</p><blockquote>
<p>このメールにはご注意ください<br>Gmail では、このメールが本当に info@example.com から送信されたものであることを確認できませんでした。メールに含まれるリンクのクリックや添付ファイルのダウンロード、または返信に個人情報を記載することは避けてください。<br>迷惑メールとして報告 | フィッシングを報告</p>
</blockquote><p>ちょうどこの頃、Gmail側で迷惑メールやフィッシングメールへの対策が強化され、独自ドメインを使用したメールの場合、そのメール送信元サーバーが認証・証明されていないと上記のような警告文が入るようになったようです。</p><p>認証や証明と言われても…となりますが、つまり info@example.com が送り主になっているメールが、メールサーバーの example.co.jp を利用して送信されていることを、Gmailが確認できれば上記のような警告文は入らない、ということになります。<br><strong>送信元アドレスのドメインと、送信元サーバーのドメインが異なっているけど、大丈夫?</strong>という確認の意味ですね。</p><h3>送信元サーバーが正しいという情報をDNSに追加する「SPFレコード」</h3><p>そこで登場するのがSPFレコードです。<br>SPFレコードとは、<strong>「このドメインからメール送信を許可されているのはどういったサーバなのか」</strong>を記載したもので、例えばGmailが<strong>「example.comのアドレスから送信されたメールは、example.co.jpのサーバーを利用することを許可している」</strong>と確認できれば、先ほどのような警告文が表示されなくなるわけです。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fsendgrid.kke.co.jp%2Fblog%2F%3Fp%3D3509" title="送信ドメインを認証するためのSPFレコードに詳しくなろう | SendGridブログ" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://sendgrid.kke.co.jp/blog/?p=3509" target="_blank">送信ドメインを認証するためのSPFレコードに詳しくなろう | SendGridブログ</a></iframe><p>今回の例でいうと、以下のようにDNSレコードを登録することになります。</p><div class="scroll"><table style="width: initial;"><colgroup><col style="width: 25%;"><col style="width: 12.4025%;"><col style="width: 37.5975%;"><col style="width: 25%;"></colgroup>
<tbody>
<tr>
<th>ホスト名</th>
<th>TYPE</th>
<th>VALUE</th>
<th>優先</th>
</tr>
<tr>
<td>example.com</td>
<td>A</td>
<td>198.51.100.1</td>
<td> </td>
</tr>
<tr>
<td>example.com</td>
<td>MX</td>
<td>example.co.jp</td>
<td>10</td>
</tr>
<tr>
<td>example.com</td>
<td>TXT</td>
<td>v=spf1 a:example.co.jp ~all</td>
<td> </td>
</tr>
</tbody>
</table></div><p>SPFレコードの書き方は、以下にも詳しく記載されています。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fbaremail.jp%2Fblog%2F2020%2F02%2F28%2F579%2F" title="SPFレコードの書き方とは?記述例を総まとめ - ベアメールブログ" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://baremail.jp/blog/2020/02/28/579/" target="_blank">SPFレコードの書き方とは?記述例を総まとめ - ベアメールブログ</a></iframe><p>これでGmailが<strong>「example.comのアドレスから送信されたメールは、example.co.jpのサーバーを利用することを許可している」</strong>と確認できるようになりました。</p><h2>サーバー上のプログラムからGmail宛にメールを送信できない</h2><p>先ほどの設定では、example.comドメインを使用して、メールサーバー example.co.jp からメールを送信する場合には有効ですが、ウェブサーバーからメールを送信した際に、Gmailから以下のようなメッセージが届き、Gmailにメールが届かない場合があります。</p><blockquote>
<p>550-5.7.26 This message does not pass authentication checks (SPF and DKIM both 550-5.7.26 do not pass).<br>SPF check for [example.com] does notpass with 550-5.7.26 ip: [198.51.100.1].<br>To best protect our users from spam, the 550-5.7.26 message has been blocked.<br>Please visit 550-5.7.26 https://support.google.com/mail/answer/81126#authentication for more 550-5.7.26 information.</p>
</blockquote><p>これは独自ドメインを設定している<strong>ウェブサーバー( IPアドレス: 198.51.100.1 )が、SPFレコードで送信を許可しているリストに含まれていないことが原因</strong>になります。</p><h3>ウェブサーバーをSPFレコードの許可リストに追加する</h3><p>そこで、先ほどのSPFレコードを編集して、ウェブサーバーのIPアドレスを追加します。</p><div class="scroll"><table style="width: initial;"><colgroup><col style="width: 25%;"><col style="width: 12.3884%;"><col style="width: 40.6216%;"><col style="width: 21.99%;"></colgroup>
<tbody>
<tr>
<th>ホスト名</th>
<th>TYPE</th>
<th>VALUE</th>
<th>優先</th>
</tr>
<tr>
<td>example.com</td>
<td>A</td>
<td>198.51.100.1</td>
<td> </td>
</tr>
<tr>
<td>example.com</td>
<td>MX</td>
<td>example.co.jp</td>
<td>10</td>
</tr>
<tr>
<td>example.com</td>
<td>TXT</td>
<td>v=spf1 a:example.co.jp ip4:198.51.100.1 ~all</td>
<td> </td>
</tr>
</tbody>
</table></div><p>最初、ホスト名( example.co.jp )とIPアドレス( 198.51.100.1 )を併記するにはどうしたら良いのかと悩みましたが、<strong>SPFレコードを複数登録するのではなく、SPFレコードの中に複数指定するのが正しい</strong>と、先ほど紹介した記事で知りました。</p><blockquote>
<p><strong>ひとつのドメインに対して複数行の設定がある</strong><br>SPFレコードは1つのドメインに対して1行になるように記載します。<br>したがって、複数行にわたる記載はエラーになります。<br><a href="https://baremail.jp/blog/2020/02/28/579/">https://baremail.jp/blog/2020/02/28/579/</a></p>
</blockquote><p>これで、ウェブサーバー上のメールフォームやショッピングカートからメールを送信する際も、GmailがSPFレコードを確認し正常に届くようになります。</p><h2>SPFレコードが正しく設定されているかをチェックする</h2><p>最後に設定したSPFレコードが正しいかを確認します。<br>確認するには、オンラインツールを使用する方法、Gmailのソースで確認する方法などがありますが、今回はオンラインツールを利用して確認しました。</p><p><a href="https://www.kitterman.com/spf/validate.html">https://www.kitterman.com/spf/validate.html</a> にアクセスして、確認したいドメインを入力し、「Get SPF Record」をクリックすると、チェック結果が表示されます。</p><p><img src="https://www.ni4.jp/.assets/SPF_01.png" alt="" width="1280" height="853" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><h3>誤っている場合</h3><p><strong>No valid SPF record found.</strong> と表示されます。<br>(その他、エラーの内容にあわせて表示されるようです)</p><h3>正しい場合</h3><p><strong>SPF record passed validation test with pySPF (Python SPF library)!</strong> と表示されます。</p><h2>やることが増えて大変だけれど…</h2><p>独自ドメインを取得すると、毎日何百通もスパムメール(迷惑メールやフィッシングメール)が届くようになり、正直なところとても困ります。<br>Gmailを利用している人にとって、このスパム対策はとても助かるもので正しい対応と思いますが、独自ドメインを使用してメールを運用している人、特にウェブサイトやECサイトを運営している方にとっては、悩ましいものです(汗)</p><p>今回の<strong>SPFレコード設定はドメインの所有や利用を証明するためのもの</strong>ですし、覚えてしまえばそこまで大変なものではないので、独自ドメインでウェブサイトやオンラインショップを運営している方は、対応しておくと良いと思います!</p>
弊社ウェブサイトをリニューアルしました!
tag:movabletype.net,2003:post-2262882
2022-12-30T09:02:00Z
2022-12-30T09:25:57Z
前回のリニューアルから14年半、ついに弊社ウェブサイトをリニューアルした話。
ジャクスタポジション 西山
<p><img src="https://www.ni4.jp/.assets/renewall-website_01.png" alt="" width="1280" height="650" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>ども、どもども<br>今日は12月30日(金)、2022年も残すところあと2日となりました。</p><p>そんな年末ではありますが、つい先日の2022年12月28日(水)に、弊社ウェブサイトをリニューアルしました!<br>このリニューアルにあわせコンテンツを一新、ドメインも新たに取得した juxtaposition.co.jp でスタートしています。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.juxtaposition.co.jp%2F" title="札幌のウェブサイト/ホームページ制作会社 ジャクスタポジション | Juxtaposition Inc." style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://www.juxtaposition.co.jp/" target="_blank">札幌のウェブサイト/ホームページ制作会社 ジャクスタポジション | Juxtaposition Inc.</a></iframe><p>これまでのウェブサイトは2008年6月に公開されたもので、当時はまだ法人化前だったこともあり、すべてを私1人で担当していましたが、今回は弊社メンバーに協力してもらうことで、それぞれの良いところを引き出せた、とても良い感じのウェブサイトになったと思っています。<br>14年半前には実施していなかった「念願のレスポンシブ対応」も行い、やっとウェブサイト制作会社らしいウェブサイトになったとも思います(苦笑)<br>本格的な構想開始から9ヶ月、構築着手からは4ヶ月半ほどで公開することができましたが、年末にかけ忙しいスケジュールの中、細かい要望に最後まで応えてくれたメンバーにはとても感謝しています。</p><p>なお、現在もまだ旧ウェブサイト <a href="https://www.lat43n.com/">www.lat43n.com</a> の閲覧が可能ですが、年明け数週間後にはクローズする予定となっています。</p><p>今回のリニューアルでは、私たちがこれまでに行ってきたウェブサイト制作業務で培ってきたものはもちろん、新しいアイディアや挑戦もふんだんに取り入れています。<br>その結果が出るには、まだ少し時間が必要と思いますが、今日はそのリニューアルにあたって考えていたことをいくつかご紹介しようと思います。</p>
<h2>リニューアルのコンセプトをしっかりと作る</h2><p>今回のリニューアルに先立って社内ミーティングを複数回実施、弊社の強み/弱み、なにができるか/なにをすべきか、そのためにはどんなウェブサイトであるべきかを、メンバーと話し合いました。</p><p>その中で得られたヒントを集め、リニューアルコンセプト(目的)としてまとめたドキュメントを作成、それをベースにコンテンツの構成とレイアウト・ワイヤーフレームの設計(導線設計)を進めていきました。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/renewall-website_05.png" alt="" width="981" height="367" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>ターゲット(ペルソナ)とリニューアルコンセプト、サイトマップなどのドキュメント</figcaption></figure><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/renewall-website_06.png" alt="" width="1280" height="698" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>レイアウトと導線を設計したワイヤーフレーム</figcaption></figure><p>もちろんこの作業はクライアント案件でも実施するものですが、自社サイトということもあり、いつも以上に細かく考えじっくりと時間を使ったように思います。<br>悪く言うとこの時点でスケジュールをちゃんと決めていなかったのですが笑…ともあれ、この作業をしっかりと行ったことで、完成段階までコアコンセプトの部分をあやふやにしないように意識できたのは、非常に良かったと思います。</p><p>リニューアルした弊社ウェブサイトにも掲載されていますが、この初期設計段階を弊社では大切に考えていて、それが良い形で実施できたと思っています。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/renewall-website_03.png" alt="" width="1280" height="650" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>UXの5段階モデルをベースにしたウェブサイト構築フロー<br/>https://www.juxtaposition.co.jp/service/website-construction/</figcaption></figure><h2>シンプルなデザイン、やりすぎないアニメーションを目指す</h2><p>レイアウト案と導線設計がまとまった後、デザイン作業へ入るのですが、今回は以下をポイントとしてデザイナーに要望を出しました。</p><ul>
<li>ウェブサイト全体を通して、あまり装飾しすぎない</li>
<li>余白などを多めに取り、白ベースの落ち着いた雰囲気にする</li>
<li>制作実績などの画像・写真が映えるような配色にする</li>
<li>見出しや背景などに、ちょっとした遊び心のあるアニメーションを入れる</li>
<li>閲覧環境に影響があるような派手なアニメーションは使用しない</li>
</ul><p>リニューアルしたウェブサイトでは、掲載文章にチカラを入れたいと思っていたので、見やすく、意図したところを読んでもらえる導線を実現できるように、デザイン確認を何度も行いました。<br>デザイン作業が一段落を迎えたのは、着手からおよそ1ヶ月後でしたが、この段階で私がイメージしていたものにかなり近い形で完成形が想像できるデザインとなり、ワクワクする気持ちが高まったのを覚えています。</p><p>アニメーションについても細かい要望を出して、いろいろと調整してもらいました。<br>フロントエンドエンジニアのメンバーは、今年4月入社の新人でしたが、新しいことにチャレンジしてくれて、当初の想像以上に良い結果が出せたと思います!</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/renewall-website_07.png" alt="" width="1280" height="480" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>アニメーションの要望をまとめた資料</figcaption></figure><h2>念願だったレスポンシブ対応を実施</h2><p>もう何年も前から、ウェブサイトはいわゆるレスポンシブ対応が当たり前となり、クライアント案件ではむしろ、スマートフォン等の小型スマートデバイスに最適化されたウェブサイトが少なくない状況でしたが、自社ウェブサイトではそれができていませんでした。</p><p>今回のリニューアルにあわせ、レスポンシブ対応できたのも良かったです。<br>また、スマートデバイスなどの小さなディスプレイはもちろん、想定よりも大きなサイズでの閲覧時も考慮し、部分的にリキッドレイアウトの要素も採用しています。</p><h2>Movable Typeのブロックエディタほか、CMSの機能を活用</h2><p>今回のウェブサイトもMovable Type(利用したプラットフォームはMovableType.net)で構築しました。<br>特に今回はブロックエディタ・カスタムブロックを活用することをメインとしたので、デザインやHTML/CSSコーディングの段階からそれを想定し、さまざまなモジュール(パーツ)を用意し、複数のモジュールを組み合わせることで、柔軟なレイアウトをエディタで作成できるよう構築しました。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/renewall-website_08.png" alt="" width="1236" height="803" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>複数のブロックを入れ子状にして構成できるカスタムブロック</figcaption></figure><p>このカスタムブロックのポイントについては、また別の機会にご紹介できればと思いますが、かなり自由度の高いブロックエディタを用意することができたと思います。</p><p>また、コンテンツ間の移動・誘導をしやすくするために、関連記事・ウェブページ機能を利用しました。<br>コンテンツごとに「関連するコンテンツ」を自由に組み立てられるので、今後のコンテンツ追加時にも柔軟に対応できそうです。</p><p><img src="https://www.ni4.jp/.assets/renewall-website_09.png" alt="" width="1280" height="704" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><h2>掲載する文章・画像にもこだわる</h2><p>リニューアルにあわせカメラマンにも協力してもらい、多くの場面で撮影した写真を使用しています。<br>弊社の雰囲気をより正確に伝え、オリジナリティを出す目的でしたが、とても良い感じに仕上がったと思います。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/renewall-website_04.png" alt="" width="1280" height="740" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>ミーティングスペースのイメージカット</figcaption></figure><p>また今回は特に掲載する文章にこだわってみました。<br>最初にコンセプトをまとめた際に、これまでのウェブサイトでの課題が浮かび上がってきたので、それを解消すべく公開直前まで文章校正を行い、このウェブサイトをご覧いただく方、弊社への依頼を検討されている方に、考えていることや想いが伝わるように、丁寧に作ってみました。</p><p>ライターさんのような文章は書けなくても、素直に示し、伝わるように言葉遣いなども細かく考えてみました。<br>あらためて、見出しなどはとても難しい…と感じましたが、少なくとも現時点では納得のできるものに仕上がったと思っています。</p><p><img src="https://www.ni4.jp/.assets/renewall-website_02.png" alt="" width="1280" height="650" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><h2>リニューアル公開を終えて</h2><p>この他にもたくさんの「こだわり」が詰まったウェブサイトとして完成した弊社ウェブサイト。<br>やりだしたらきりがない、良くも悪くも凝り性なところがある私ですが、満足の行くカタチで公開を迎えることができました。<br>冒頭にも書きましたが、長きにわたって最後まで付き合ってくれたメンバーには本当に感謝です。</p><p>2022年のうちに公開するか、2023年になってから公開するか<br>最後までメンバーに相談しながらでしたが、年内最終日に公開に踏み切り、多くの方からメッセージ等をいただけて、とても良い日になりました。</p><p>2023年のジャクスタポジションは、このウェブサイトとともに、もう1つ上のステージで仕事ができるように、私自身も運営をがんばりたいと思います。</p><p>それでは皆さん、良いお年をお迎えください。</p>
Movable Type ブロックエディタの「カスタムブロック設計パターン」
tag:movabletype.net,2003:post-2247600
2022-12-09T23:15:00Z
2022-12-09T23:27:37Z
Movable Type のブロックエディタ(カスタムブロック)を、もっと使いやすくできないかと考えてみた話
ジャクスタポジション 西山
<p><img src="https://www.ni4.jp/.assets/AdventCalendar2022_3.jpg" alt="" width="1200" height="630" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>この記事は <a href="https://adventar.org/calendars/7425">「Movable Type Advent Calendar 2022」</a>10日目の記事です。</p><p>ども、どもども。<br><a href="https://www.ni4.jp/2022/12/04-155800.html">先日の記事</a>でも触れましたが、<a href="https://mtddc2021.mt-tokyo.net/">MTDDC Meetup TOKYO 2021</a>の<a href="https://speakerdeck.com/nishi_yama/kasutamuburotukuzuo-cheng-shou-shun-falsebetapurakuteisu">「カスタムブロック作成手順のベタープラクティス」</a>というセッションで、<a href="https://www.ni4.jp/history-of-mtddc/complete.html">複雑なHTML構造のウェブページ</a>を、Movable Typeのブロックエディタで作る方法を紹介していました。</p><p>その後もカスタムブロックをどう使っていこうかと試行する中で、カスタムスクリプトを利用したカスタムブロックにも、ウェブサイトの運営状況(操作スキルや利用シーン)によって大きく2パターンあるなと考えるようになったので、今日はその<strong>2通りのカスタムブロック設計パターン</strong>について、ブログ記事にしてみようと思います。</p>
<h2>レイアウトと利用するブロックを固定しておくカスタムブロック</h2><p><a href="https://www.ni4.jp/history-of-mtddc/complete.html">先ほどのタイムラインを掲載するウェブページ</a>や、シックス・アパートさんの<a href="https://movabletype.net/blog/blockeditor/">「MovableType.net活用ブログ」</a>で紹介されているものがこちらに当たるかと思います。</p><p>例えば以下のようなカスタムブロック。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/AdventCalendar2022_3_1.png" alt="" width="1280" height="631" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>利用できるブロックが固定されているカスタムブロックの例</figcaption></figure><ul>
<li>2カラムレイアウト</li>
<li>左右いずれかのカラムに画像を掲載</li>
<li>他方のカラムにはテキストを掲載</li>
</ul><p>これを利用すると、こんな感じのレイアウトが簡単につくれます。</p><p><img src="https://www.ni4.jp/.assets/AdventCalendar2022_3_2.png" alt="" width="1280" height="1125" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>基本的な2カラムレイアウトを作成するならとても使いやすく、ブロックエディタを<strong>実際に利用する人の操作スキル</strong>によっては、<strong>レイアウトが固定化された入力フォーマット(Q&A式)</strong>のほうが、<strong>入力操作に迷わないというメリット</strong>があります。<br>(もっと簡単にするなら「画像を左に置くブロック」「画像を右に置くブロック」と分けるのも良いと思います)</p><p>ただ、このテキスト部分に<strong>見出しを入れたい</strong>ときや、<strong>テキストを段落に分けたい</strong>と思ったとき、あるいは<strong>レイアウトを変えたい</strong>と思ったときなど、このカスタムブロックでは事前に用意されたブロック以外を追加できず、それ<strong>専用のカスタムブロックを増やさなければならないことがデメリット</strong>となります。</p><h2>レイアウトとブロックが自由に追加できるカスタムブロック</h2><p>先ほどのカスタムブロックのデメリットである「ブロックを自由に追加できない」ことを解消し、「自由なレイアウト操作を実現する」には、<strong>複数の入れ子状のカスタムブロック</strong>を用意すると良さそうです。</p><p>例えば以下のようなカスタムブロック。</p><p><img src="https://www.ni4.jp/.assets/AdventCalendar2022_3_3.png" alt="" width="1280" height="1033" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><ul>
<li>レイアウトを決める親ブロック(子ブロックのみ追加可能)</li>
<li>親ブロックのカラム数を選択</li>
<li>テキストや画像を掲載する子ブロック(自由にブロックを追加可能)</li>
</ul><p><strong>レイアウトを決める「レイアウトブロック」</strong>と、テキストや画像などの<strong>「パーツブロック」</strong>に分けて考えることで、<strong>自由なレイアウトと自由なパーツの組み合わせ</strong>が実現できます。</p><p>そして、親ブロックや子ブロックには、任意のclassを追加できるようにしておくと、さらに自由度が増しそうです。<br>例えば現在構築中のウェブサイトでは、こんな感じのカスタムブロックを作っています。</p><p><img src="https://www.ni4.jp/.assets/AdventCalendar2022_3_4.png" alt="" width="1280" height="994" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>親ブロックの <em>section</em> の中に、2カラムになる子ブロックの <em>asymmetry_row</em> を追加、その中に <em>asymmetry_item</em> という子ブロックを追加することでブロックのレイアウトを作り、<em>asymmetry_item</em> では、見出しやテキスト、画像を自由に追加できるようになっています。<br><em>section</em> に追加できる子ブロックを <em>asymmetry_row</em> 以外にも用意しておくと、かなり自由度の高いレイアウトが作れます。</p><p><strong>レイアウトを固定化しないので自由度が高くなることがメリット</strong>ですが、今度は逆に<strong>利用する人のスキルが必要になるのがデメリット</strong>と言えるでしょう。</p><h2>ポイントは「操作スキル」と「利用シーン」の検討</h2><p>以上のように、実際に<strong>操作する人のスキルレベルや利用シーンに応じて使い分ける</strong>と、どちらのパターンでも使いやすいブロックエディタが作れると思います。</p><p>また、特に後者の「レイアウトとブロックが自由に追加できるカスタムブロック」の場合は、カスタムブロックを作る人が、<strong>レイアウト設計やデザイン、HTML/CSSコーディングの段階から一緒に参加する</strong>と、手戻りも少なくスムーズにカスタムブロックを作れるでしょう。</p><p>今回は<a href="https://movabletype.net/support/customblock/customscript.html">カスタムスクリプト</a>や<a href="https://movabletype.net/support/design/editcss.html">エディタCSS</a>には触れていませんが、それらも利用すれば、管理画面がより見やすく使いやすくなると思います。</p><p>まだまだ工夫の余地はありそうですが、私はこんな感じで考えてカスタムブロックを作っています。<br>Movable Typeのブロックエディタは触っていて楽しいですね!</p><p><a href="https://adventar.org/calendars/7425">Movable Type Advent Calendar 2022</a>、最終日までまだ半分残っていますので、明日からのエントリーも楽しみにご覧ください!</p>
MovableType.netで使用する独自ドメインでメールも利用する
tag:movabletype.net,2003:post-2247348
2022-12-08T06:26:00Z
2023-02-09T09:10:13Z
独自ドメインを使用して、ウェブサイトをMovableType.netで、メールをさくらインターネットで運用する話
ジャクスタポジション 西山
<p><img src="https://www.ni4.jp/.assets/AdventCalendar2022_2.jpg" alt="" width="1200" height="630" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>この記事は <a href="https://adventar.org/calendars/7425" target="_blank" rel="noopener">「Movable Type Advent Calendar 2022」</a>8日目の記事です。</p><p>ども、どもども。<br>今年10月、シックス・アパート社さんとの共催で、以下のセミナーを開催しました。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.sixapart.jp%2Fseminar%2Fsa%2F2022%2F09%2F09-1151.html" title="【オンラインミニセミナー】SaaS型CMS MovableType.net の効果的な使い方 2022 | シックス・アパート - CMSソフトウェア、サービスを提供" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://www.sixapart.jp/seminar/sa/2022/09/09-1151.html" target="_blank">【オンラインミニセミナー】SaaS型CMS MovableType.net の効果的な使い方 2022 | シックス・アパート - CMSソフトウェア、サービスを提供</a></iframe><p><a href="https://speakerdeck.com/nishi_yama/shou-qing-sayazi-you-du-nomeritutodakeziyanai-saasxing-cmsdezuo-ru-kuraiantokarazhi-chi-sareruuebusaito">参考)スライド資料</a></p><p>このセミナーでは、MovableType.netを利用して弊社がどのようにウェブサイトを構築しているか、その事例を踏まえご紹介させていただきましたが、そのセミナーの中で<strong>「MovableType.netを利用する際、同じドメインでメールを運用したい場合は、どのように対応しているか」</strong>と質問を受けました。</p><p>MovableType.netでは、利用する独自ドメインのCNAME、またはAレコードにIPアドレスを設定することで、独自ドメインによるウェブサイトの運営が可能になっています。<br>ただ、提供されるのはウェブサイト機能のみで、メール機能はありません。</p><blockquote>
<p>独自ドメイン(公開設定/追加ドメイン)<br><a href="https://movabletype.net/support/setting/domain.html">https://movabletype.net/support/setting/domain.html</a></p>
</blockquote><p>弊社では、ウェブサイトはMovableType.netで、メールは別のサーバーで運用するように独自ドメインを設定していますが、その点についてはMovableType.netのマニュアル等には記載されていません。<br>上記ページでも、<strong>独自ドメインをどのように設定すると良いのか、その具体的な方法については紹介されていない</strong>ので、ここがわからず不安になっているケースもあるのかと感じました。</p><p>そこで今回は、<strong>独自ドメイン側でどのように設定すると、MovableType.netで利用するドメインで、ウェブサイトとメールを利用できるのか</strong>を中心にご紹介したいと思います。</p>
<h2>そもそもウェブサーバーとメールサーバーはどう分けるのか?</h2><p>ウェブサイトを構築する際、一般的なレンタルサーバーだとその契約時に一緒にドメインを契約することで、利用開始時にはウェブサイトとメールが両方とも独自ドメインで利用可能になっていることも多いため、<strong>ドメインの設定を個別に変更した経験が無い</strong>というケースも少なくないと思います。</p><p>ドメインの設定(DNS設定)とは、そのドメインがどこのサーバーを利用するかを設定するものなので、これを変更することで、ウェブサーバーはこっちのサーバー、メールサーバーはこっちのサーバーと、分離することが可能です。<br>8年前の記事ですが、一般的なレンタルサーバーで<strong>ウェブサーバーとメールサーバーを分ける手順</strong>について、以下の記事でご紹介しているのでご覧ください。</p><iframe class="bookmarklet hatena-embed" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.ni4.jp%2F2014%2F09%2F22-125209.html" title="DNSサーバー、Webサーバー、Mailサーバーを分離してみる | www.ni4.jp" style="border:none;display:block;margin:0 0 1.7rem;overflow:hidden;height:155px;width:100%;max-width:100%;"><a href="https://www.ni4.jp/2014/09/22-125209.html" target="_blank">DNSサーバー、Webサーバー、Mailサーバーを分離してみる | www.ni4.jp</a></iframe><p>上記ではウェブサーバーにCPIさんのサーバーを利用していますが、ここをMovableType.netに置き換えるカタチになります。</p><h2>MovableType.netを独自ドメインで公開する際の設定内容</h2><p>ドメインはさまざまなサービスで取得できますが、ここではムームードメインとお名前どっとこむを例に、設定内容を紹介します。</p><h3>ムームードメインの場合</h3><p>以下の手順までは<a href="https://www.ni4.jp/2014/09/22-125209.html">先ほどの参考記事</a>と同じです。</p><ol>
<li>ムームーDNSをセットアップ</li>
<li>ネームサーバーをムームーDNSに変更</li>
<li>ムームーDNSカスタム設定の画面[設定2]へ移動</li>
</ol><p>以下のようにCNAMEとAレコードを設定します。</p><div class="scroll"><table style="width: 100%;"><colgroup><col style="width: 33.2967%;"><col style="width: 33.2967%;"><col style="width: 33.2967%;"></colgroup>
<tbody>
<tr style="height: 23.8516px;">
<th style="height: 23.8516px;">サブドメイン</th>
<th style="height: 23.8516px;">種別</th>
<th style="height: 23.8516px;">内容</th>
</tr>
<tr style="height: 23.8516px;">
<td style="height: 23.8516px;">www</td>
<td style="height: 23.8516px;">CNAME</td>
<td style="height: 23.8516px;">service-web.movabletype.net</td>
</tr>
<tr style="height: 23.8516px;">
<td style="height: 23.8516px;"> </td>
<td style="height: 23.8516px;">A</td>
<td style="height: 23.8516px;">52.198.153.39</td>
</tr>
<tr style="height: 23.8516px;">
<td style="height: 23.8516px;"> </td>
<td style="height: 23.8516px;">A</td>
<td style="height: 23.8516px;">52.199.127.131</td>
</tr>
</tbody>
</table></div><p><img src="https://www.ni4.jp/.assets/AdventCalendar2022_2_1.png" alt="" width="1280" height="865" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p><strong>公開するドメインが www.ni4.jp だけの場合、CNAMEだけの設定でOKです。</strong><br>ネイキッドドメイン(ni4.jp)でアクセスがあった際、www.ni4.jp へリダイレクトするようにMovableType.net側で設定する場合(以下の画像参照)、上記のようにAレコードも設定しておきます。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/AdventCalendar2022_2_2.png" alt="" width="1280" height="416" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>MovableType.net側の設定</figcaption></figure><p>さくらインターネットのメールサーバでメールを利用する場合、<a href="https://www.ni4.jp/2014/09/22-125209.html">参考記事</a>と同じようにDNSに設定します。</p><div class="scroll"><table style="width: 100%;"><colgroup><col style="width: 33.2236%;"><col style="width: 33.2236%;"><col style="width: 17.0519%;"><col style="width: 16.6118%;"></colgroup>
<tbody>
<tr style="height: 23.8516px;">
<th style="height: 23.8516px;">サブドメイン</th>
<th style="height: 23.8516px;">種別</th>
<th style="height: 23.8516px;">内容</th>
<th style="height: 23.8516px;">優先度</th>
</tr>
<tr style="height: 46.7031px;">
<td style="height: 46.7031px;">www</td>
<td style="height: 46.7031px;">CNAME</td>
<td style="height: 46.7031px;">service-web.movabletype.net</td>
<td style="height: 46.7031px;"> </td>
</tr>
<tr style="height: 23.8516px;">
<td style="height: 23.8516px;"> </td>
<td style="height: 23.8516px;">A</td>
<td style="height: 23.8516px;">52.198.153.39</td>
<td style="height: 23.8516px;"> </td>
</tr>
<tr style="height: 23.8516px;">
<td style="height: 23.8516px;"> </td>
<td style="height: 23.8516px;">A</td>
<td style="height: 23.8516px;">52.199.127.131</td>
<td style="height: 23.8516px;"> </td>
</tr>
<tr style="height: 23.8516px;">
<td style="height: 23.8516px;"> </td>
<td style="height: 23.8516px;">MX</td>
<td style="height: 23.8516px;">example.sakura.ne.jp</td>
<td style="height: 23.8516px;">10</td>
</tr>
</tbody>
</table></div><p><a href="https://www.ni4.jp/2014/09/22-125209.html">参考記事</a>ではmailサブドメインのAレコードも設定していますが、メールソフト等で設定する情報に example.sakura.ne.jp を利用する場合は、上記のとおりMXレコードだけでもOKです。</p><h3>お名前どっとこむの場合</h3><p>お名前どっとこむの場合、以下の手順でDNS設定を行うことができます。</p><h4>1. お名前.com Navi へログインして「ネームサーバーの設定」にある「ドメインのDNS設定」へ進む</h4><p><img src="https://www.ni4.jp/.assets/AdventCalendar2022_2_3.png" alt="" width="1280" height="689" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><h4>2. 設定を実施するドメインのラジオボタンにチェックを入れ、次へ進む</h4><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/AdventCalendar2022_2_4.png" alt="" width="1280" height="632" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>おや?</figcaption></figure><h4>3. DNS設定項目内の「DNSレコード設定を利用する(設定する)」で、次へ進む</h4><p><img src="https://www.ni4.jp/.assets/AdventCalendar2022_2_5.png" alt="" width="1280" height="667" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><h4>4. DNSレコードの設定情報を入力し、「追加」ボタンを押す</h4><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/AdventCalendar2022_2_6.png" alt="" width="859" height="400" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>むむ、このドメインは…?</figcaption></figure><p>一度に必要な数だけ「追加」していくことができます。<br>上記の画像では、最初にTYPEを選択するようにしていますが、お名前どっとこむでは、選択するTYPEによって入力フォームが自動で切り替わる(入力していたものが消える)ので、最初にTYPEを選ぶのが良いです。</p><h4>5. 設定する内容を確認する</h4><p>必要な設定を追加し終わったら、確認画面へ進んで内容を確認し、画面下部の「設定する」をクリックすることで、設定内容がドメインに反映されます。<br>以下の画像では、<a href="https://www.ni4.jp/2014/09/22-125209.html">参考記事</a>と同じくメールサーバーにさくらインターネットを使用する例として、設定しています。</p><figure class="mt-figure" style="display:inline-block"><img src="https://www.ni4.jp/.assets/AdventCalendar2022_2_7.png" alt="" width="1280" height="1204" class="asset asset-image" style="max-width:100%;height:auto"/><figcaption>こ、このドメインは…もしや!</figcaption></figure><h2>DNS設定の変更から、その内容が確認できるまでの時間</h2><p>以上の設定で、ウェブサイトをMovableType.netで、メールをさくらインターネットのサーバーで利用することが可能になります。<br>設定変更からそれが確認できるまでは、TTLの長さなどによって変わるので、以下などを参考にしてみてください。</p><blockquote>
<p>参考)【ドメイン】TTL設定とは?TTL値に設定可能な値は?<br><a href="https://help.onamae.com/answer/14500">https://help.onamae.com/answer/14500</a></p>
</blockquote><h2>最後に</h2><p><a href="https://www.ni4.jp/2014/09/22-125209.html">参考記事</a>とこの記事で、MovableType.netとメールサーバーをそれぞれ別々に利用する方法をご案内しました。<br>最初はちょっとわかりにくいかと思いますが、何度かやっていると慣れてくるので、一度試してみてくださいね。</p><p>ちなみに、ウェブサーバーとメールサーバーを分けておくと、ウェブサイトのリニューアル時にメールサーバーを変えずにリニューアルできたりするので、とても便利です!(www側の設定だけ変更すれば、メール側は一切変更しなくてOK)</p><p>さてさて、今日で8日目となった<a href="https://adventar.org/calendars/7425">Movable Type Advent Calendar 2022</a>、いろいろな記事が公開されているので、明日以降もお楽しみくださいね!</p>
MovableType.netのブロックエディタで「ブロックを追加」する場所をわかりやすくする
tag:movabletype.net,2003:post-2244084
2022-12-04T06:58:00Z
2022-12-09T06:31:35Z
ブロックエディタ、非常に気に入って使っているけれど、ここがもっとこうだったらなぁと思っていた箇所を、どうにかしてみようと思った話。
ジャクスタポジション 西山
<p><img src="https://www.ni4.jp/.assets/AdventCalendar2022.jpg" alt="" width="1200" height="630" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>この記事は <a href="https://adventar.org/calendars/7425" target="_blank" rel="noopener">「Movable Type Advent Calendar 2022」</a>4日目の記事です。</p><p>ども、どもども。<br>ワタシ、このブログはもちろん、仕事で構築しているウェブサイトでも、ここ最近は Movable Type のブロックエディタを活用しています。<br>カスタムブロックでとても使いやすい管理画面が作れるので、利用者さんからも好評です。</p><p>ブロックエディタを使えば、<a href="https://www.ni4.jp/history-of-mtddc/complete.html">こんな複雑な構造のページ</a>でも、HTMLを触ることなく編集することができます。<br>このブロックエディタの作り方は、<a href="https://mtddc2021.mt-tokyo.net/">MTDDC Meetup TOKYO 2021</a>の<a href="https://speakerdeck.com/nishi_yama/kasutamuburotukuzuo-cheng-shou-shun-falsebetapurakuteisu">「カスタムブロック作成手順のベタープラクティス」</a>というセッションで紹介しました。</p><p><img src="https://www.ni4.jp/.assets/AdventCalendar2022_1.jpg" alt="" width="1280" height="597" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>複雑な入れ子構造のHTMLでも、直感的に作れてとても便利なのですが、このようなレイアウトを作る際に、ひとつだけ気になっていたことがあります。</p>
<h2>どこに「ブロックを追加する」のか、わかりにくい</h2><p>ブロックエディタで何層かの入れ子構造を作成すると、「ブロックを追加」というボタンが並ぶように表示され、どの階層にブロックを追加すると良いのか、一見してわかりにくい状態になることがあります。</p><p><img src="https://www.ni4.jp/.assets/AdventCalendar2022_2.png" alt="" width="793" height="413" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>画面上部へ戻って、それがどのブロックなのかを確認する必要があるのですが、特に公開後にページを編集しようと思った際、とてもわかりにくいと感じています。</p><h2>DashboardUtilityで解決できないか</h2><p>そこで、私が個人的にリリースしているChrome拡張機能 <a href="https://chrome.google.com/webstore/detail/movabletypenet-dashboard/eolimfhbcldbfmmopdbcpfiihidhpjaf?hl=ja">MovableType.net DashboardUtility</a> でこれを解消できないかと考えました。</p><h3>利用イメージ</h3><p><img src="https://www.ni4.jp/.assets/AdventCalendar2022_3.png" alt="" width="793" height="413" class="asset asset-image" style="max-width:100%;height:auto;display:block"/></p><p>この拡張機能を使用すると、<strong>どのブロックを操作しているかをハイライト表示</strong>し、<strong>どこにブロックを追加するかをボタンに表示</strong>できるようになります。<br>これで先ほどの問題もかなり解消できると考えています。</p><p>実はこのブログ記事の公開に間に合わせようとしていましたが、残念ながら今日現在まだ完成に至っていません…(汗)<br>ブロックエディタがより使いやすくなると思うので、年内には完成させて、利用できるようにしたいと思います。<br>それまで、今しばらくお待ちください!(次回のブロク記事で正式公開できると良いな)</p><p><a href="https://adventar.org/calendars/7425">Movable Type Advent Calendar 2022</a>は、明日以降も続きますので、引き続きお楽しみください!</p>