[Solr]ChatGPTにスキーマを作らせてみた

Solrによる検索環境を構築するにあたって、スキーマの設定ファイルを作るところは意外と面倒です。
その部分を試しに ChatGTP に手伝ってもらいました。

以下の内容で依頼しました。

Apache Solr で以下の文書のインデックスを作成します。デフォルトのスキーマ設定にスキーマAPIを使って必要な設定を追加するための JSON ファイルを作成してください。
インデックス対象の文書は以下の形式の JSON ファイルで与えられます。
[{“id”:”10″,”type”:”官公庁”,”area”:”住之江区”,”name”:”軽自動車検査協会大阪主管事務所”,”address”:”住之江区南港東3-4-62″,”address_p”:”34.6164938333333,135.438210722222″},
{“id”:”11″,”type”:”官公庁”,”area”:”住之江区”,”name”:”大阪陸運支局なにわ自動車検査登録事務所”,”address”:”住之江区南港東3-1-14″,”address_p”:”34.6190439722222,135.442191833333″}]

インデックス対象は、いつもの大阪の施設情報です。具体例として与えたのは2レコード分だけですが、以下のように適切なスキーマを作ってくれました。

以下は、Apache Solr でこの JSON ファイルをインデックスするためのスキーマ定義の例です。この例は、id、type、area、name、address、address_p の6つのフィールドをインデックスすることを想定しています。

{
  "add-field": [
    {
      "name": "id",
      "type": "string",
      "indexed": true,
      "stored": true,
      "required": true,
      "multiValued": false
    },
    {
      "name": "type",
      "type": "string",
      "indexed": true,
      "stored": true,
      "required": true,
      "multiValued": false
    },
    {
      "name": "area",
      "type": "string",
      "indexed": true,
      "stored": true,
      "required": true,
      "multiValued": false
    },
    {
      "name": "name",
      "type": "text_general",
      "indexed": true,
      "stored": true,
      "required": true,
      "multiValued": false
    },
    {
      "name": "address",
      "type": "text_general",
      "indexed": true,
      "stored": true,
      "required": true,
      "multiValued": false
    },
    {
      "name": "address_p",
      "type": "location_rpt",
      "indexed": true,
      "stored": true,
      "required": true,
      "multiValued": false
    }
  ]
}

このスキーマ定義によって、以下のようにインデックスを作成することができます。

  1. Apache Solrの管理画面にアクセスします。
  2. 左側のメニューから「コアの作成」をクリックして、新しいコアを作成します。
  3. 新しいコアの名前を入力し、「コアを作成する」をクリックします。
  4. 新しいコアの管理画面に移動し、「スキーマ」をクリックします。
  5. 「スキーマ」のページで、「スキーマAPI」をクリックし、「スキーマ定義の追加」をクリックします。
  6. 上記のスキーマ定義をコピーして、「スキーマ定義の追加」のテキストボックスに貼り付けます。
  7. 「送信」をクリックしてスキーマを追加します。
  8. 左側のメニューから「ドキュメント」をクリックして、新しいドキュメントを追加します。
  9. 新しいドキュメントのJSON形式のデータを入力し、「追加」をクリックしてインデックスを作成します。
  10. インデックスが作成されたことを確認するために、左側のメニューから「クエリ」をクリックして、クエリを実行して結果を確認します。

短い文字列には string、 長めの文字列には text_general、緯度経度には location_rpt とデータの内容に合わせてフィールドタイプを選んでくれているように見えます。 address_pという名前がヒントになったかもしれないので hoge にして試してみましたが、やはり location_rpt になりました。

このようにインデックス作成までの準備の部分を AI に手伝ってもらえると、いろいろと楽になりそうです。

Adobeの新たなジェネレーティブAI「Adobe Firefly」で何ができるのか

3月21日ついにAdobeがAI画像生成ツールを発表しましたね。
その名も「Adobe Firefly」

 
アドビ、新たなジェネレーティブAI「Adobe Firefly」を発表
https://www.adobe.com/jp/news-room/news/202303/20230321_adobe-unveils-firefly.html
 
まだ、Bata版ですが、製品版が出るのが楽しみです。
Bata版を触りたい場合は「 https://firefly.adobe.com/ 」の右上のボタン「Request access」から、申請をすることができます。
大きな特徴として「商業利用に特化したジェネレーティブAI」という点。
(現在、プライベートベータ版)
 
今までの画像生成ツールなどは、どの画像を使ってAI訓練されているか未公開なので、著作権もグレーな状況。
 
「Adobe Firefly」は「Adobe Stockライブラリ」や「著作権切れ」などのコンテンツを利用するなどしてかなり安心して利用できそうです。
Adobe Stockの画像や一般に公開されているライセンスコンテンツや著作権が失効しているパブリックドメインコンテンツを対象としており、画像やテキストエフェクトを中心に、商業利用として安全性を考慮したコンテンツを生成するように設計されています。
https://www.adobe.com/jp/news-room/news/202303/20230321_adobe-unveils-firefly.html
 
では具体的に何ができるか見てみましょう。
(すぐ申請はおりないようで、私はまだ触れるように触れてません。なので、同じ紹介動画の該当箇所をペタペタ貼っているのでご了承を…)

Text to image

テキストを入力するだけで画像を生成できます。
https://youtu.be/_sJfNfMAQHw?t=4
今まではAI画像生成などは操作や準備が大変なのですが、わかりやすい操作画面で使いやすそうですよね。
写真風なのかアート風なのかなども細かく設定できるようです。

Extend image

画像の足りない部分も簡単に増やしてくれます。
https://youtu.be/_sJfNfMAQHw?t=10

Inpainting

人が着ている服を指定して、テキスト入力するだけで、その内容に沿った服に変更できるようです。
https://youtu.be/_sJfNfMAQHw?t=14

Smart Portrait

人の表情や年齢も簡単に変えれそうです。
https://youtu.be/_sJfNfMAQHw?t=24

Depth to image

写真をアップロードして、変更したいイメージのテキストを入力するだけで、写真のイメージが変更できるようです。
https://youtu.be/_sJfNfMAQHw?t=30

3D to image

3Dオブジェクトとテキストを組み合わせるだけでそのイメージ画像が簡単にできるようです。
「芝生の丘お城」にしたり「お菓子のお城」にしたり。
https://youtu.be/_sJfNfMAQHw?t=36

Text to template

デザインテンプレートもたくさん作ってくれるようです。
例えば「ハッピーバースデーのテンプレートを作って」と書くだけで様々なデザインパターンを作ってくれます。
https://youtu.be/_sJfNfMAQHw?t=43
それ以外にも様々なことが簡単にできるようになるようです。
安心して商用利用できるようになるのも心強いですよね。

セキュリティキーを使ってパスキーを体験する

はじめに

前回の記事では、認証器として指紋認証付きのスマートフォンを利用してパスキーによる認証を体験しました。その後、Google が販売する FIDO セキュリティキーである Titan Security Key を購入したので、そちらを使うパターンのパスキー認証を試してみました。

PCでのパスキー登録と認証

今回も WebAuthn.io のデモページを利用させてもらいます。

まず登録です。セキュリティキーをUSBポートに挿しておきます。

ユーザ名を入力して”Register”を押し、パスキーの作成方法として「USBセキュリティキー」を選択します。

セキュリティキーをタップします。

登録完了です。物理的に接続されている分、スマートフォンを利用する場合に比べてステップが少なくて済みます。

次に認証。

ユーザ名を入力して”Authenticate”を押し、セキュリティキーをタップします。

認証成功です。
ユーザ登録を実行したPC以外でも、セキュリティキーを挿しさえすれば、非常にスムーズにログインできます。

スマートフォンでのパスキー認証

スマートフォンで認証を行う場合はセキュリティキーを NFC デバイスとして利用します。

ユーザ名を入力して”Authenticate”を押します。

セキュリティキー使用の確認画面が出るので「開始」を押します。

「NFCでセキュリティキーを使用する」を選択します。

セキュリティキーをスマートフォンのNFC読み取り箇所に当てます。

正しく読み取れたら認証完了。

おわりに

PCでは認証器としてスマートフォンを使うよりもセキュリティキーを使う方が、全体的に手順が簡略に済みます。
ただ、スマートフォン自体で認証を実行するときにはスマートフォン自体の生体認証を使う方が楽なのは間違いないです。一つのアカウントで一つの認証器でしか登録できないということはないので、両方で登録しておいて状況に応じて使い分けるのが便利かなと思います。

「ひとり広報の戦略書」を読んでみた

ひとり広報の戦略書

ここ最近、部署間の異動で広報業務を兼務するようになりました。簡単に言うならプレスリリースやメルマガなどを作成する訳なんですが、なにせ初めて携わる種類の業務なので、

  • そもそも広報って何?何をやって、どうなったら成功なの?
  • 一人でやるものなの?チームでやるとかあるんじゃないの?

と言った素朴な疑問が浮かびます。

どんなことでも基礎的な型や手法が確立されているものですし、それを学ぶことでその分野の全体像がなんとなくわかったり、成長までの道筋やどのような考え方で取り組めばいいのかがわかります。ただ闇雲に進むのではなく、何か道しるべが欲しい。そこで手に取ってみたのがこの書籍。

ひとり広報の戦略書 – 認知と人気を全国レベルにする「知ってもらえる」すごい方法 –
小野茜 (著)

著者の小野茜さんは、企業で5年間広報を担当しPR支援会社を設立。現在は、企業の外側から「広報」をサポートする仕事をされていて、実際に30社以上の様々な企業で広報業務をサポートされてらっしゃるそうです。広報とはなんぞやというエピソードやノウハウが詰まっていて大変勉強になりました。


この記事では、本書で私が気になった箇所や良かったところをピックアップしてみましたので、同じような境遇でお困りの方に届けばいいなと思います。

広報業務を取り巻く状況

まずこの書籍を読んでみてわかったことが「広報をひとりや少人数でやっている企業が大半」ということ。著者が様々な企業に入って広報業務のサポートをされてるからこそ見えてくることですし、様々な企業の広報担当が悪戦苦闘している状況があるから、こんなタイトルで刊行することになったんだろうなと思います。

更には、以下のような悩みを抱えている方が多いようで、私ひとりじゃないんだなと少し安心しました。

  • ひとりや少人数でやっている企業が大半
  • 基本的な業務はプレスリリース
  • 片手間でやっているため忙しくてリリース配信を思うように回せていない。もしくはリリースを配信するのが精一杯
  • リリースを出しているが反応がない、成功しているかわからない

ひとり広報を取り巻く状況は厳しいですが、メディアの多様化・細分化により、テレビや新聞などのマスメディア活用は限定的になった昨今、様々なネタやコンテンツが求められていたり、地方の小さな企業のニッチなネタでもメディアに取り上げられることも多く、著者は「広報活動をする上でベストな時代」であると言います。ひとりであることは逆に強みでもあると。

では、ひとり広報にはどんな強みがあるのでしょうか?

広報業務をひとりでやるメリットとデメリット

ひとり広報のメリット

  • 複数人や大人数から成る広報チームの場合、分業制になり、プレスリリースのテーマを決めるのも、企画書を書くにも、確認や承認やコンセンサスが必要になる
  • ひとりでやれば柔軟性の高さを担保できて、トライ&エラーのPDCAを速く回せる
  • 刹那的な話題が一気に注目を集めるような時代では、承認が必要な組織では対応がどうしても遅くなるが、ひとり広報であれば、意思決定のスピードは高まる
  • 上司や経営者に対してひとり広報の良さを理解してもらい、ある程度自由な裁量をもらえることが大切にはなる

ひとり広報のデメリットは?

「ひとりで全てをやるため、特に片手間で対応している場合も多いと思いますので、業務に追われて成果がでない」やはりここが最大の壁のようです。そのためにはどうすればいいのか?

  • やらないことを決める
  • 何をどこまで何時間でやるか
  • 時間配分は3:6:1 (3情報の整理と価値化:6社外への伝達:1社内への伝達)

要するに実行するタスクを見極めて質より量で回すことしかなさそうではあります。
目安としては、最低でも週に1本計算で月4本配信できていれば積極的な広報活動が行えているようです。

広報の本当のあり方とは

広告が「対ユーザーに対して購買につながる」が最重要な目的であることに対して、広報=PR(Public Relations)は社会とのつながり(関係性)をつくることが目指すべきものであると言います。「対ユーザーに対して購買につながる」だけでなく、「対メディアに対して取材につながるネタを提供」して関係作りも狙えることは素敵なお仕事だなと思いました。

一番大切なことは「自社にとって必要な広報活動を見つけ出し、実践する」ではありますが、PRの本質として関係を作るためには、情報を伝達するだけでなく、面白いプレスを打つことで社内外に魅力を伝えることも重要な要素だそうです。

だからこそインプットが大切だと。目と耳の両方で、ツールを駆使してインプットの時間を作る。あらゆることに「なぜ」「どうして?」と、ちょっとした情報でも背後に何が起きているのかを意識する。そういった積み重ねで時代の流れを掴むことができるのかもしれないです。

そういえば最近、雑誌の「meets」 で焼肉の特集が組まれてました。これも何か意図や流れがあるかもしれませんね。

終わりに

コロナ以降、費用対効果の高いウェビナーの活用などオンラインでの活動も盛んになってきていて広報業務の裾野は広がっているのではないでしょうか。ひとりで頑張る担当の方々と情報の共有というカタチでつながりができればと思い記事にしてみました。
弊社が提供するWebサービスについてもプレスリリースを定期的に行なっておりますので、興味を持ったメディアやライターの方がいらっしゃればお話させていただければ幸いです。

パスワードに塩かけ?

こんにちは。開発担当のマットです。

今回の記事で、ウェブサービス等の開発者がパスワードを安全に保存するための塩かけ(ソルト)の概念を説明したいと思います。

むかしむかし…

大昔、ウェブサービスにアカウントを作成した際、そのウェブサービスが登録したユーザ名とパスワードをそのまま保存しました。
データベースを覗いてみると、各ユーザのユーザ名とパスワードはそのまま見れていました。

user_name password
田中 一郎 123456789
山田 太郎 hogehoge
鈴木 花子 qwertyuiop
村田 次郎 hogehoge

もちろん、サイトがハッキングされてしまった場合、全ユーザのパスワードが丸見えです。
これを使って、ログインすることもできますし、ユーザ様が別のウェブサイトで同じパスワードを利用している場合、そのウェブサイトにもログインされてしまうことは考えられます。
とても、不安全な方法でした。

ハッシングで隠す

こういう問題が明らかになった時、多くのウェブサービスがハッシングを使うようになりました。

ハッシングとは?

ハッシングとは一方的の暗号関数です。
その関数にパスワードを渡したら、暗号された文字列が生成されます。

いくつかのハッシング・アルゴリズムは存在しますが、md5 というものを使ってみると、”hello” が “5d41402abc4b2a76b9719d911017c592” に変換されます。

特徴として、似たようなものを暗号化しても、その結果(ハッシュ)が全然違います。
例:
“bat” => 5f3f4681121b460e3304a1887f42f1c3
“cat” => d077f244def8a70e5ea758bd8352fcd8
“あいうえお” => 86deb27a32903da70a7b2348fcf36bc3
“あいうええ” => 5c6a3a46075a5617cd570ee1c583e528

パスワードを直接データベースに保存する代わりに、パスワードのハッシュを保存する時代になりました。

user_name password
田中 一郎 25f9e794323b453885f5181f1b624d0b
山田 太郎 329435e5e66be809a656af105f42401e
鈴木 花子 6eea9b7ef19179a06954edd0f6c05ceb
村田 次郎 329435e5e66be809a656af105f42401e

ユーザ様がログインする際、入力したパスワードを同じアルゴリズムでハッシングして、データベースで保存されているものと一致する場合のみ、正しいパスワードと言えます。

この方法で、データベースにパスワードを直接保存することなく、ウェブサービスを作ることはできるようになりました。

…ところで、ちょっとした問題はまだあります。見えますでしょうか?

ハッシングだけの問題

上記の例で、山田 太郎さんと村田 次郎さんは同じパスワードを使いました。
同じパスワードを使っているため、ハッシュも当然同じです。

つまり、サービスがハッキングされてしまった場合、パスワードはバレませんが、「山田 太郎さんと村田 次郎さんは同じパスワードを使っています」というのがバレてしまいます。
もし、山田 太郎さんのパスワードが別の方法でバレてしまった場合、村田 次郎さんのパスワードもわかってしまいます。

あと、多くのユーザ様がいる場合、重複が多いパスワードを推測することも可能になります。
“password1” や “12345678” など、多くの人が使いそうなパスワードはあるので、重複数が多いユーザはこういうようなパスワードを使っていると言えますね。

塩かけ(ソルト)で解決

調理する時、塩を少し加えるだけで味がグッと変わりますよね。
同じく、ハッシングをする時、パスワードだけではなく、「ちょっとした何か」を加えると、全く違う結果になります。

例として、2人のユーザが同じパスワード (“password123”)を設定するとします。
そのままハッシングすると、2人とも同じハッシュになりますが、ユーザAのパスワードに「abc」を付け加えてからハッシングして、ユーザBのパスワードに「xyz」を付け加えてからハッシングすると、2人とも全く違うハッシュになります。

この「ちょっとした何か」を「ソルト」と呼んでいます。
ソルトは乱数でも、ランダムな文字列でも大丈夫です。とにかく全てのユーザに違うソルトが振られたら問題ありません。

そうすると、仮に全員が同じ「password123」を設定したとしても、データベースに保存されるパスワードが全く違います。

user_name salt password
田中 一郎 PJTBCTwz a021144f7dec828d515f372d6d239f5f
山田 太郎 5g0VkWF1 19ead4c6deca667db146d9a1c478e4d6
鈴木 花子 p9nfzkBT 411fec4ff70554cded8b48ab9bc3b8c3
村田 次郎 BoqWcL59 5487529bd4deb8003b6a46bbbaf03332

ユーザがログインする時、入力したパスワードにソルトを付け加えてハッシングすると、その結果が password として保存されている値と同じ場合、ログインをさせるという処理になります。

私のパスワードは安全ですか?

ご利用のウェブサービスが正しくソルト付けとハッシングをしているかどうかは判断しにくいですが、「パスワードを忘れました」などのリンクを押した場合、自分のパスワードがメールで送信されたら、安全に保管されていないと言えます。

パスワードを正しく取り扱っているウェブサービスはユーザのパスワードをわかる方法がないはずです。どこにも保存してはいけないデータとなります。

なので、ウェブサービスが自分のパスワードをメールで送信できる場合…アウトです。
ご注意ください。