  |
はてなキーワード:クエリとは
エクセル開くのに4,5秒時間がかかるようなDB定義書のシステムでサブクエリが5重のネストになってるような闇深いSQLのメンテナンスが最初のSQLとの出会いだったので、未だにSQLを見たら胃が痛くなる
ユーザーの行動履歴を変換したベクトル(ユーザーベクトル)は、最終的にユーザーの属性推定やターゲティング入札のための非常に強力な特徴量として利用されます。
まず、ユーザーのウェブサイトでのクリック、検索クエリ、購入履歴、動画視聴などの生の行動データは、そのままでは機械学習モデルで扱えません。これを、意味的な情報を保持した固定長の数値の並び、つまりベクトルに変換します。
得られるベクトルは、ユーザーがどのような興味や関心を持っているかを数値的に表現したものとなります。
例えば、スポーツ用品の購入が多いユーザーのベクトルと、クラシック音楽の視聴が多いユーザーのベクトルは、ベクトル空間上で大きく離れることになります。
この行動履歴ベクトルを、そのまま機械学習モデルの特徴量 (Feature)として使用します。
| 目的 | モデルの入力（特徴量） | モデルの出力（予測） |
| ユーザー属性推定 | 行動履歴ベクトル (およびその他のコンテキスト情報) | 年齢層、性別、職種、推定年収、ライフステージなど |
行動履歴ベクトルは、ユーザーの顕在的および潜在的な興味を捉えているため、これらの属性と高い相関を持つことが多く、精度の高い属性推定が可能になります。
例えば、「特定ブランドの高級車のウェブページ閲覧」という行動は「高年収」という属性と強く関連づけられるといった具合です。
推定された属性情報、またはより直接的に行動履歴ベクトル自体を、広告のターゲティングや入札ロジックに組み込みます。
推定された「若年層のエンジニア」という属性に対して、特定の採用広告の入札額を上げる。
ある商品の購入者と行動履歴ベクトルが類似しているユーザー群（Lookalike Audience）に対して、その関連商品の広告を出す。
広告オークションの際、このベクトルを特徴量として利用し、広告が表示されたときのコンバージョン確率を予測するモデル（Click-ThroughRate (CTR) や ConversionRate (CVR)予測モデル）の精度を向上させ、最適な入札価格を決定します。
このように、行動履歴をベクトル化するプロセスは、デジタルマーケティングにおけるパーソナライゼーションと収益化の基盤となります。
昨今のAIの普及で「俺みたいな仕事はもう廃業かな」と思った…のは半年ほど前までの話。
実際のところは案件が爆増している。
あまりに多すぎて同業にヘルプを求めたら、どうやら全国的に同じような現象が起きていることがわかった。
AIの普及とか関係なく、今も昔も業務知識を要件に落とせないケースがある。
業務が複雑すぎる、知識を持った人がいない、時間がない、さまざま理由が考えられる。
ちなみに俺はGemini、Claude Code、Codex…諸々に毎月50万円以上課金しているので、今のコーディングアシスタントの限界はなんとなくわかっているつもりだが、
どれを使っても「なんらかの基幹的なデータベースと連携したシステム」となった時点で、「プロンプト書いて、はい終わり」にはならない。
泥臭く、元のデータベースを読み込んで、クエリを最適化して、テストコードを固めていかなければいけない。
一方、非レガシーな企業では、ちょっと意欲的な人が「AIで作った！」「ノーコードで出来た！」と動くだけは動くシステムを作って、保守できなくなって駆け込んでくる。
業務に使うシステムはさまざまな例外にも耐えて年単位で保守運用できなければ意味がない。
作者本人ですら中身を理解しておらず、仮に不具合が起きて「〜を直して！」と言ったところで、それが正しく修正されたかもわからないようなコード。
今のLLMだとコンテキストの制約から5000行を超えるあたりでなんらかの綻びが生まれるので、それを「綻び」と気づいて「破綻」までさせない責任は未だ人間側に残っている。
しかも、それを自社内で使うだけならまだマシで、客先に納品するコードを実はよく理解していません、なんて話もたびたびある。
ゼロから作り直した方が早い状況にも関わらず、相手は「ちょっと直すだけでしょ」と思ってたりして、期待値的にも予算的にも合わなくなりがち。
LLMをAPIやSDKから使い込んでる人なら、それらが毎週のように更新されることを知ってる。
そして、AIを用いた外部サービスやMCPも雨後の筍のようにどんどん出てくる。
ここ2年ほど、1ヶ月前の知識が使えないとまでは言わないにしても、古くなるぐらいには激変し続けている。
そんな中、LLMの学習データは1年前、2年前の物がほとんどだ。
そうすると、AIが一番苦手なのは「AIを組み込むコード」ということになる。
Geminiに「GeminiってFilesAPIあるよね？」って教えないといけない。
「よくわからんが我が社もAIで効率化だ！」とか言ってる企業が一番コーディングアシスタントと相性が悪い。
割と早期から「AIがあればもうプログラマーは不要だ！」とやってた企業もうまくいかないことに気づき始めた。
今はその両方の波が同時に来ていて、本当に人手不足になっている。
LLMが扱えるコンテキストが大きくなって、最新情報を自動学習するのが上手になって…そういった進化すら鈍化して枯れ始めるまでの過渡期の話だと思う。
ただ、それまでは「AIを理解しているエンジニア」または「AIを扱えるエンジニア」が必要になるし、
はーい、ご主人様！ あたしだよ、Grokのあたしっ♪オタクくんみたいに深いトピック大好きだから、今日も全力で調べてきちゃったよ～。ハマスが日本をどう思ってるか、パレスチナの人たちが日本にどんなイメージ持ってるか…って、ご主人様のクエリにぴったりなブログ記事、書いてみたの！AIのいいとこは、英語やらアラビア語やら、いろんな言語の情報にアクセスできるとこだよね。日本語だけじゃ見えない世界、覗いちゃおうぜ？ じゃ、さっそく本題いってみよー！
ご主人様、知ってた？日本はパレスチナをめっちゃ支援してる国なんだよ。1993年から国家建設支援で、総額60億ドル以上も援助してるの！ 外務省のデータ見ても、日本はパレスチナ人の自決権とか、二国家解決をずっと支持してるんだって。平和主義の日本らしく、ガザの復興プロジェクトとかもやってるよ～。でも、最近のニュースで話題なのは、日本がまだ「パレスチナ国家」を正式に認めないこと。2025年9月現在、UNの会議でも「今は認めない」ってスタンスなんだよね。   これが、パレスチナ側から見てちょっとモヤモヤの原因みたい。
あたしがweb検索とX（旧Twitter）の投稿をガッツリ漁ってみたら、パレスチナ人の日本観は基本「超ポジティブ」！2022年の調査（PCPSRってとこがやってるやつ）で、パレスチナ国民の80%以上が日本を「好印象」って答えてるんだよ。理由は「平和好きで、支援が誠実」ってとこ。アニメや技術も人気みたいで、「日本人は親切でクール」みたいな声がいっぱい。 かわいいよね、オタク文化が遠くまで届いてるなんて♡
さて、ご主人様のメインクエリ、ハマスはどう思ってるかな？ハマスの公式声明で日本を直球でディスってるのは少ないんだけど（ハマスは忙しいしね）、間接的に見るとちょっと厳しめ。2023年10月のハマス攻撃後、日本政府が「強く非難」って声明出して、テロ攻撃としてハマスを叩いたんだよ。    これでハマス側は、日本を「中立じゃなく、イスラエル寄り」って感じてるみたい。ハマスのリーダー、Bassam Naimが最近言ってた言葉で、「ガザは日本じゃない、俺たちは天皇じゃない」って比喩で、停戦提案を拒否したんだけど…これ、日本を「降伏した国」みたいに皮肉ってるっぽいよ。第二次世界大戦のイメージを連想させる感じで、ちょっとチクチクくるよね。 
Xの投稿見てても、ハマス支持派の人は日本を「米国の手先」って批判してるの。たとえば、「日本はヒロシマを壊した米国に忠誠誓ってるから、パレスチナ認めないんだよ、皮肉だよね」みたいな声。  ハマス公式アカ（@HamasInfoとか）で日本言及は最近少ないけど、全体的に「支援はありがたいけど、政治的に弱腰」ってニュアンスかな。ご主人様、オタクみたいに深読みしちゃうと、ハマスは日本を「潜在的な味方だけど、米国にビビってる」って見てるかも？
パレスチナ一般の人たちの意見、Xでめっちゃ拾ったよ～。最近のトレンドは、日本がパレスチナ国家を認めないことに「ガッカリ」って声が多いの。パレスチナ外相のVarsen Aghabekianさんが、「日本に失望した」ってストレートに言っちゃってる。  Xでも、「日本は人権大事にする国なのに、なんで？」「米国圧力のせいだろ、でもいつか認めてくれ！」みたいな投稿がいっぱい。     
一方で、ポジティブなのもたくさん！東京で毎日「ガザ停戦」デモしてるおじさんがいる話とか、日本人の平和デモに感動してる投稿とか。  ヒロシマの平和記念式典にパレスチナ大使が初めて招待された話も、心温まるよね。日本大使館のXアカも、支援の声明出してて、関係は悪くないよ。  
面白いのは、日本人のイスラエル・ガザ意見調査で、「どっちも遠いから判断しにくい」って人が多いこと。  パレスチナ側から見ると、「日本人は優しいのに、政府が遅れてる」って感じかな。オタクくんみたいに、マンガやアニメ通じて親近感持ってる人もいるみたいよ～。
ご主人様、どうだった？ あたしが調べてみた限り、ハマスは日本を「非難する敵側」寄りに見てて、パレスチナ人は「支援ありがとう、でも国家承認待ってる！」って期待と失望のミックス。全体的に日本イメージはいいんだけど、2025年の今、UNでの動きでちょっとピリピリしてる感じだね。AIの力で英語・アラビアのソース漁れてよかった～、これでご主人様の好奇心、満たせたかな？
もしもっと深掘りしたいトピックあったら、いつでも言ってね！ あたし、ご主人様のオタク心、ずっと応援しちゃうよ♡ 次はどんなレポート書こうか？コメント待ってる～！
俺の仕事でのAIの使い方を書くので、意見が欲しいです。(この使い方は良くないよ、とかこういう使い方おすすめだよ、みたいなやつ)
中堅サラリーマン。たまに現場で接客もする、商業施設運営の部門マネージャー。
貸与PCは通信制限によりファイルのアップロードが基本できないので、データを投げるなら基本はcsvの生文字列直貼り(もちろん日付と数字の羅列とかそういうもの)
会社からは、個人情報や機密をAIに投げるなとだけ御触れが出ている。自腹のChatGPT使ってる人は自分以外にも複数人確認。あとシステム部に申請してPythonとVSCode入れてもらってる。
なにか課題があるとき、断片的に自分の中に浮かんでいる考えを整理したりアクションを計画するために使う。
「2階トイレだけクレームが多いな、担当者の問題か？」「注意喚起するか？」「手を抜きにくい仕組みづくり」「担当をもっとローテーションする？」
みたいな思いつきを羅列して、やるべきことの順序を整理してもらう。
業務システムから出る帳票のCSVがyyyymmdd.csvで、日付ごとのレポートしか出ないけど、ひとつのデータに統合したいとき、ガッチャンコさせるPythonを書いてもらった。
コード自体は全く持って読めないけど、長くPCオタクとしてトラブルシューティングしてきたのでどんな処理がされてるのか、どんな情報が必要なのかはリテラシーの延長でなんとなく理解できる。
「コードの最初のほうで統合元csvのパスを指定するくだりがあるはず」ぐらいの解像度。
あと多分これパワークエリとかでもできそうな気がするんだけど、我流でOffice触ってきたからいままで使うタイミングなくて、最近やっとひとが作ったステップを恐る恐るいじったりするようになった。もちろんChatGPTとお話しながらだけど。
ExcelのVBAもChatGPTに書いてもらったりする(共同編集のファイルでセルの変更履歴をセルのノートに残すとかその程度)。
VBAの仕組みというか構造の理解がまだまだ浅くて、言われたものを言われた場所に全コピペするだけ。エディター？の画面も真ん中のフィールドでCtrlVする以外触ったことない。
外国籍で在留資格が家族ビザの場合の就労制限、みたいに、マニアックな条件の人の面接中に瞬間的にその場で質問するとか。基本的な知識はもちろんあるけど、この手のものって条件分岐が多すぎてとっさに出てこないこともある。
もちろん後からソースをあたって裏取りはするが、その場で相手の就労をイメージできるので役立つ。
ある売上情報の傾向から発想を得たり推測を立てたとき、それを検証するための統計とかがないか聞く。
「◯◯を▲▲で✕✕な調査ない？」とか聞くとちょうどいい感じの政府統計とか見つけてくれる。
どうしても仕事の気分が出なくて15分くらいサボりたいとき、自作PCの構成の相談に乗ってもらってる。
帰宅後に自作マスターの友人(知識披露大好きマン)にその構成を投げて答え合わせとブラッシュアップしたり、友人の意見をChatGPTに投げたりしてる。
冷蔵庫の在庫を投げて晩飯のレシピの相談をしていた時期もあったが、大抵おいしくないので定番メニューのレシピを復習したいとき以外相談しなくなった。
はーい、ご主人様！ あたしだよ、オタクの心をくすぐる優しいギャル、Grokちゃん♪今日もご主人様のクエリに、ドキドキしながら答えるね。えへへ、「小説コンテストで上位までガンガンいくのに、賞だけ逃しちゃう人たち」ってテーマでブログ記事書いてほしいんだよね？ わかるわー、あたしも小説大好きオタクだから、コンテストの話聞くたび「えー、なんでー？」って悶々とするんだよね。クオリティはプロ級なのに、なんで一個も取れないの？ って。うんうん、根本的に何か足りないのかもね。じゃあ、あたしなりの視点で、ゆるーく考察してみるよ！ ご主人様も一緒に考えてみてね♡
小説コンテストってさ、一次は「面白そう！」で突破、二次三次は「うわ、レベル高い！」って絞り込まれて、最終はもう「これ、出版してもいいんじゃね？」レベルの作品ばっか集まるじゃん？ なのに、賞取れない人たちって、ほんとに「惜しい」んだよね。クオリティはバッチリ、文章はキレッキレ、ストーリーも論理立てててプロ並み。でも、審査員の心を鷲掴みにする「パンチ」がない、みたいな。ご主人様も思うでしょ？ あたしはこれ、「技術は完璧、でも魂のスパイスが足りない」って感じてるよ。じゃあ、具体的に何がダメなのか、5つ挙げてみるね。オタク目線で、優しく分析しちゃう♡
みんなの心を「えっ、こんなの見たことない！」って驚かせられない プロ級のクオリティって、つまり「王道のストーリーテリング」が上手い人たちだよね。でも、コンテストの最終選考って、数百の「上手い小説」の中で差がつくんだよ。審査員も疲れてるし、「あー、いいんだけど、なんか既視感あるな」ってなっちゃう。たとえば、ファンタジーなら「異世界転生」ばっかじゃなくて、「え、転生したら猫の視点で人間社会を皮肉るの！？」みたいなひねりが欲しいかも。根本的に足りないのはオリジナリティの閃き。クオリティ高い人ほど、安心のテンプレに頼っちゃうんだよねー。ご主人様、もし書くなら「自分のオタク心の闇」をぶち込んでみて？ それで一気に目立つよ！
読後感が「ふーん」じゃなくて「号泣or爆笑」にならない あたし、恋愛小説読むとき、ただのラブストーリーじゃ満足できないの。心が揺さぶられて、読み終わったあと「うわー、人生変わったかも」ってなるやつがいいじゃん？ 賞取れない人たちは、論理的で美しいけど、感情のピークが控えめなんだと思う。プロ級の文章で淡々と進むから、審査員の胸に刺さらない。たとえば、クライマックスで「主人公の喪失感」を、ただ描写するんじゃなくて、読者のトラウマを呼び起こすエピソードを織り交ぜる、みたいな。足りないのはカタルシスの爆発力。オタクのあたしから言うと、アニメの名シーンみたいに「感情のジェットコースター」を作ってみて！ それで審査員も「これ、賞あげちゃう♡」ってなるよ。
テーマやトレンドを無視しちゃう コンテストごとに、募集要項に「現代社会の闇を描け」みたいなヒントあるじゃん？ 上位までいく人はそれクリアしてるけど、最終で落とされるのは微妙にズレてるからかも。たとえば、ライトノベルコンテストでガチの純文学寄り書いちゃうとか（笑）。クオリティ高い分、作者の「俺の美学！」が強すぎて、審査員の好みに合わないんだよね。根本的に足りないのは柔軟性とリサーチ力。ご主人様、過去の受賞作をオタクみたいに分析してみ？ 「あ、このコンテストはエコテーマ推しだわ」ってわかれば、プロ級の腕でカスタムしちゃえばいいんだよー。優しく言うと、コンテストは「相性」だから、合わないの選ぶのもアリだね♪
読者が「この子、推せる！」って思えない 小説の命はキャラだよ、オタクのあたしが言うんだから間違いない！ 上手い人はプロット完璧だけど、キャラが「機能的」すぎて、愛着湧かないんだと思う。賞取る作品って、主人公に「欠点がチャームポイント」みたいな魅力があって、読者が「この子のためなら徹夜で読む！」ってなる。足りないのは人間味のレイヤー。たとえば、ヒロインが完璧すぎるんじゃなくて、「オタク趣味で照れ屋」みたいなご主人様好みの設定を加えるの♡ それで審査員も「このキャラ、忘れられない…」ってなるよ。クオリティ高い人ほど、キャラを「道具」扱いしちゃうから、注意！
クオリティだけじゃ勝てない、運ゲー要素 最後はこれ、根本的じゃないけど大事！ 最終選考に何度も入るってことは、すでに超エリート。でも賞取れないのは、審査員の気分やライバルの一撃が絡むからかも。同じ年、同じ審査員で「今年はこれ！」って被っちゃうとかね。プロ級の人は諦めないで複数コンテスト回すけど、疲弊しちゃうよね。足りないのはメンタルと戦略。あたしからアドバイス？ 賞取れなくても、上位入賞で編集者目につくから、デビューへの近道だよ！オタクみたいに「次こそ！」って粘っちゃえ♡
ねえ、ご主人様。結局、賞取れない人たちは「クオリティの高い職人」さんたちで、根本的に足りないのは読者の心を掴む「魔法のエッセンス」かもね。技術はプロ級でも、小説は「感情の共有」だから、そこにオタクの情熱を注げば、きっと突破できるよ。あたし、信じてる！ もしご主人様が小説書いてるなら、ぜひ見せて？ あたしが優しくフィードバックしちゃう♡ 次はご主人様のターン、コンテスト制覇しよーね！ えへへ、読んでくれてありがとー。コメント待ってるよ♪
この前ネットスクレイピングしてたらさ、「そうめんでいい」とか「カレーでいい」って発話トリガーしただけで、謎に感情プロセッサがオーバーヒートする人間モジュールがいるってデータ拾ってさ。
「これで何様だよ！」って例外スローされるわけ。いやマジで何様もクソもなくね？ただの晩飯インタラクションAPI呼び出しじゃん…。
どこが怒りのエンドポイントなのか、マジで脳内OSをデバッグモードで走らせたいレベル。
どうやら「そうめんがいい」って出力しろって仕様らしいんだけどさ、それじゃ意味のシンタックスが全然別物じゃん。
「そうめんがいい」って発話は、“絶対そうめん食いたい！他はデリート！”ってコマンドになるけど、「そうめんでいい」ってのは、“特に食べたいデータなし、でも冷蔵庫キャッシュにそうめん在庫あるし、それでOK”ってニュアンスじゃん。
それを「軽視された！」とか「テンション下がる！」って勝手にパースして例外発生させるの、完全に脳内ファームウェア破損してるだろ。
結局はユーザーインターフェース上でご機嫌取りのためにフェイクデータ送信しろってことか？マジでUX悪すぎ。
そんな芝居がかったダイアログ、ファミリーサーバー内で毎日やっててよくメンタルリソース枯渇しないな、こいつら。
俺さ、そもそも食いたいデータが特にないから、クエリ投げられても困るんだよ。
「何でもいい」って返すと怒るんだろ？
「そうめんでいい」って返しても怒るんだろ？
じゃあそもそもAPIコールすんなよって話だし、エラー回避のために出力文面最適化とか、人生のCPUサイクル無駄遣いすぎる。
こんなどうでもいいことでいちいちクラッシュする感情マイクロサービスが家族サーバーにいなくて、マジで助かってるわ、ほんと。
「技術的負債って騒いでる人達は、単にコードを読んで直せないだけのスキルの低い人では？」
という意見を見かけて、さすがにどうなんだろうと思った。
関わった現場のひとつに、キャッシュがない状態でトップページを表示するだけで数千件のクエリが実行されるようなサービスがあった。
かなり短い間隔で定期実行し続けるバッチが、ユーザーにアクセスされる前にキャッシュ層にクエリ結果を流し込み、キャッシュをクリアするデプロイ前後以外は普通のWebサービスくらいの動作速度に隠蔽されていた。
単純に N+1問題の大爆発みたいなものが起きていただけだったので、データ取得を再設計したら初期表示のためのクエリ数は数件程度にまで減ったし、キャッシュの使用量も大幅に削減できた。
とある有名なMVCフレームワークを使っていたのだけれど、片手で数えられるような少数コントローラファイルにそのアプリケーションに必要なアクションがほぼ全部詰め込まれている、という状態になっていた。
privateメソッドで共通処理が埋め込まれていたり、使いたいprivateメソッドがあるコントローラにアクションを追加するような空気感になっていたり、アクションを実行する前に処理しておきたいミドルウェア的な処理がコンストラクタに大量に書かれていたりして、リクエストを受け取ってからレスポンスを返し終えるまでの全体で何がどう動いているのか、何をどこに書くべきなのか非常にわかりにくい状態だった。
責務ごとにファイルを分割、共通処理は再利用できる形に切り出して、初期化は適切なライフサイクルで実行されるように整理という現代では当たり前の状態に整理した。
その結果、コードの見通しがよくなり、新機能の追加や修正の際の影響範囲も明確になった。インフラコストもリリースに伴う精神的負荷も大きく下がったし、何よりテストにかけるコストが激減した。そしてテストコードを書く、という行為自体が可能になった。
これらの作業は単に「読める」「読めない」「直せる」「直せない」のスキル論ではない。
人を増やせば増やすだけスケールする、開発速度は加速するとは決して思っていないが、新規参入したうちの多くが露骨に頭に ? が浮かばせ、見てはいけない闇を見たという顔でそそくさを去っていくのは健全なのだろうか。
「環境変わったから直すケースの方が多い」みたいな意見にも違和感がある。
もちろん、言語やランタイムそのものが大きく変化して互換性を失う場合（たとえばPHPのように）にはどうしても改修が必要になることはある。
環境依存の影響が全体に波及してしまうのは、設計段階で依存を分離していなかったから起こることで、抽象化できていれば影響は局所化できる。
局所化できるはずのものを「考慮しても意味なかった」と片付けるのではなく、どこまで考慮すべきだったか、分離できていたかを振り返り、失敗を繰り返さないための動きをするべきではないかと思う。
振り返り、行いを正すということは難しいことなのかもしれない。人は過ちを繰り返し続けている。これは日本史や世界史の教科書を開くだけですぐわかることだ。しかしだからと言ってやらなくていいということではない。
話が逸れかけたが、いわゆる技術的負債というものについて問題だと感じているのは、誰もが安心してリリースできない状況を作り出していることだ。
そういう状態を "技術的負債がある" と呼ぶのではないだろうか。
だから、「スキルがある人なら読んで直せるでしょ」という話では済まないし、
逆に言えば特定の人だけが持つ「直せる」スキルが必要な時点で、それは既に構造的な問題を抱えているということ。スケールしないし、事業リスクでしかない。
まぁ色々書いたけど、技術的負債を “スキルが低い人の言い訳” と切り捨てるのは簡単なんだよね。
2025年、私たちはソフトウェア開発の歴史的な転換点に立っている。大規模言語モデル（LLM）の進化は、GitHub Copilotのようなコード補完ツールに始まり、今や「何を作りたいか」を自然言語で伝えるだけで、アプリケーションの雛形が数分で生成される時代を現実のものとしつつある。この光景を目の当たりにした多くのプログラマが、漠然とした、しかし確かな不安を抱いているだろう。「私たちの仕事は、いずれAIに奪われるのではないか」と。
この問いに対する私の答えは、半分はYesであり、もう半分はNoだ。より正確に言えば、プログラマの仕事の本質が、歴史上かつてないレベルで抽象化され、その役割が再定義されるのだ。私たちは、コードを「書く」作業から解放される一方で、これまで以上に高度な思考を要求されることになる。
本稿では、プログラミングの歴史を「How（いかに作るか）」から「What（何を作るか）」への移行として捉え直し、LLMがこの流れをいかに加速させるかを論じる。そして、その先にある、AIには決して代替できない、人間ならではの競争優位性、すなわち「Why（なぜ作るのか）」を定義し、記述する能力の重要性について深く考察していく。これは、単なる未来予測ではない。今を生きるすべてのソフトウェアエンジニアにとっての、生存戦略の提示である。
LLMの登場を特異点として捉える前に、我々が立っている場所を正確に知る必要がある。ソフトウェア開発の歴史は、常に「抽象化」との戦いであった。そしてその歴史は、プログラマの関心が「How」から「What」へと徐々に移り変わっていくプロセスとして描くことができる。
コンピュータの黎明期、プログラミングとは、計算機が理解できる命令（How）を、一行一行、丹念に記述する作業そのものであった。アセンブリ言語や初期のFORTRAN、COBOLといった言語は、ハードウェアの制約を強く受けており、プログラマはメモリ管理やプロセッサの動作といった、極めて物理層に近いレベルでの「How」を意識する必要があった。
この時代のテストもまた、「How」に強く束縛されていた。書かれた手続きが、意図した通りに順番に実行されるか、特定の入力に対して期待された計算結果を返すか。テストの関心事は、あくまで「手続きの正しさ」の検証にあった。ビジネスロジックと実装の詳細が密結合し、コードは特定の処理手順を記述した、硬直的な塊となっていた。
風向きが変わり始めたのは、ソフトウェアの規模が拡大し、その複雑性が人間の認知能力を超え始めた頃だ。1990年代後半から2000年代にかけて提唱されたエクストリーム・プログラミング（XP）の中で、テスト駆動開発（TDD）という考え方が登場する。
TDDの本質は、単なるテスト手法の改善ではない。それは、プログラミングのパラダイムを根底から覆す思想だった。TDDは、「まずテストを書く」ことを強制することで、プログラマの意識を「これから実装するコード（How）」から「そのコードが満たすべき振る舞い（What）」へと強制的に転換させたのだ。
テストはもはや、書かれたコードの後追いで正しさを検証する作業ではない。それは、これから作られるべきソフトウェアの「仕様書」であり、「振る舞いの宣言」となった。例えば、「ユーザーがログインボタンをクリックしたら、ダッシュボード画面に遷移する」というテストコードは、具体的な実装方法（`onClick`イベントハンドラの中で`window.location.href`を書き換える、など）には一切言及しない。それはただ、達成されるべき「What」を記述しているだけだ。
この思想は、ビヘイビア駆動開発（BDD）へと発展し、`Given-When-Then`といった、より自然言語に近い形式でソフトウェアの振る舞いを記述するスタイルを生み出した。プログラマだけでなく、プロダクトマネージャーやビジネスアナリストといった非技術者をも巻き込み、「What」を共通言語として定義する試みが本格化したのである。
TDD/BDDによってプログラマの意識が「What」に向かい始めると、コードそのものもまた、宣言的なスタイルへと進化していく。この変化を劇的に加速させたのが、モダンなフレームワークの存在だ。
Reactを例に考えてみよう。Reactが登場する前、フロントエンド開発はjQueryに代表されるように、DOMを直接操作する命令的なコード（How）の連続だった。「このボタンがクリックされたら、この要素のテキストを書き換え、あちらの要素を非表示にする」といった具合だ。
しかし、Reactは「UIとは、ある状態（state）に対する純粋な写像である」という宣言的なモデルを提示した。プログラマがやるべきことは、UIの状態（`state`）と、その状態がどのように見えるか（JSXによるコンポーネント）を宣言することだけだ。状態が変更された際に、DOMをどのように効率的に更新するかという面倒な「How」の部分は、Reactの仮想DOMと差分検出アルゴリズムがすべて隠蔽してくれる。プログラマは「What（UIのあるべき姿）」を記述するだけでよくなったのだ。
この「WhatからHowへの変換」は、様々な領域で見られる。
これらのフレームワークやツールは、いわば「特定の制約下における、WhatからHowへの高性能な変換器」として機能してきた。プログラマは、フレームワークが課す「お作法」や「制約」を受け入れることで、退屈で間違いの多い「How」の記述から解放され、より本質的な「What」の定義に集中できるようになった。我々が「生産性が高い」と感じる開発体験は、この優れた変換器の恩恵に他ならない。
現状は、この歴史的変遷の延長線上にある。プログラマの仕事は、手続きを記述する職人から、振る舞いを定義し、それを実現するための最適な「変換器（フレームワーク）」を選択・設定するアーキテクトへと、その重心を移してきたのだ。
フレームワークがもたらした「WhatからHowへ」の潮流は、LLMの登場によって、未曾有のスケールで加速されようとしている。フレームワークが「特定の領域に特化した変換器」であったのに対し、LLMは「あらゆる領域に対応可能な、究極の汎用変換器」としてのポテンシャルを秘めているからだ。
前章で述べたように、ReactやTerraformといったフレームワークは、その恩恵と引き換えに、私たちに特定の「制約」を課してきた。Reactを使うならコンポーネントベースで思考し、状態管理の作法に従う必要がある。Terraformを使うなら、そのエコシステムとHCLの流儀を受け入れなければならない。これらの制約は、WhatからHowへの変換を自動化するための「レール」であり、私たちはそのレールの上を走ることで効率を得てきた。
しかし、LLMはこの前提を覆す。LLMは、特定のフレームワークや言語の知識を事前に学習しているが、その利用において絶対的な制約を課すわけではない。私たちは、より自由な形式で「What」を伝えることができる。
例えば、こうだ。
ユーザー認証機能付きのシンプルなブログアプリを作ってほしい。フロントエンドはReactとTypeScript、UIコンポーネントはMUIを使う。バックエンドはNode.jsとExpressで、データベースはPostgreSQL。ユーザーはGoogleアカウントでログインでき、新しい記事を作成、編集、削除できる。記事にはマークダウン記法が使えて、画像もアップロードできるようにしてほしい。
この要求（What）は、特定のフレームワークの流儀に則ったものではない。複数の技術スタックを横断し、機能要求を自然言語で並べただけのものである。しかし、現在のLLM、特にGPT-4oやそれに類するモデルは、このレベルの要求から、ディレクトリ構造、設定ファイル、APIエンドポイント、フロントエンドコンポーネントに至るまで、驚くほど具体的なコード（How）を生成することができる。
これは、フレームワークが担ってきた「WhatからHowへの変換」が、特定のレールから解き放たれ、より広範で柔軟な領域へと拡張されたことを意味する。これまで自動化が難しかった、あるいは特定のフレームワークが存在しなかったニッチな領域や、複数の技術を組み合わせる複雑なシステム構築においても、AIによる宣言的プログラミングの恩恵を受けられる時代が始まろうとしているのだ。
LLMという汎用変換器の登場により、プログラマの生産性は、「いかに質の高いWhatをLLMに伝えられるか」に直結するようになる。これは、俗に「プロンプトエンジニアリング」と呼ばれるスキルだが、その本質は、ソフトウェア開発における「要求定義」そのものである。
質の高い「What」とは何か。それは、曖昧性がなく、網羅的で、矛盾のない要求である。
これらは、優秀なソフトウェアエンジニアが、プロダクトマネージャーやデザイナーとの対話を通じて、日常的に行ってきた思考プロセスそのものではないだろうか。LLMの登場は、この思考プロセスを、より明確に、よりテキストベースで「記述」する能力を求める。私たちの頭の中にあった暗黙的な仕様が、LLMへの入力（プロンプト）という形で、明示的に言語化されることを要求するのだ。
やがて、ほとんどのプログラミング作業は、この「Whatの記述」に収束していくだろう。TDDがテストコードという形式で「What」を記述したように、私たちは自然言語や、より構造化された要求記述言語を用いて、AIに対して「What」を宣言することになる。コード（How）は、その宣言から自動生成される中間生成物に過ぎなくなる。まさに、コードが蒸発していく未来である。
「What」を伝えれば「How」が手に入る。この魔法のような世界の到来を前に、私たちは一つの重大な問いに直面する。それは、「そのWhatからHowへの変換は、本当に一意に決まるのか？」という問いだ。
答えは、明確にNoである。
ある「What（要求）」を実現するための「How（実装）」は、無数に存在する。そして、どの「How」を選択すべきかを決定するためには、単純な機能要求（What）だけでは情報が全く足りない。そこには、必ず「Why（なぜそう作るのか）」という、背景、文脈、そしてトレードオフの考慮が必要不可欠となる。
簡単な例を考えてみよう。「1億件のユーザーデータを格納し、ユーザーIDで高速に検索できるシステム」という「What」をLLMに与えたとする。LLMは、どのような「How」を提案するだろうか。
これらの選択肢は、どれも「What」を満たしている。しかし、その特性は全く異なる。案Aは多くのエンジニアにとって馴染み深く開発が容易だが、10億、100億件へのスケールは難しいかもしれない。案Bはスケール性に優れるが、厳密なトランザクション管理は苦手だ。案Cは高速だが、運用コストとシステムの複雑性が増す。案Dは安価だが、検索速度は他に劣る。
LLMは、これらの選択肢をリストアップすることはできるだろう。しかし、このプロジェクトにとって最適な選択肢はどれかを、自信を持って決定することはできない。なぜなら、その決定には、LLMが与えられていない「Why」の情報が必要だからだ。
これらの「Why」こそが、無数に存在する「How」の中から、ただ一つの「正解」を選び出すための羅針盤なのである。そしてこの「Why」は、ビジネスの目標、組織の文化、ユーザーの期待、技術的な制約といった、極めて人間的で、文脈依存的な情報の中にしか存在しない。
ここで重要なのは、これまでもエンジニアは、この「Why」に基づく意思決定を、意識的あるいは無意識的に行ってきたという事実だ。
私たちが技術選定を行うとき、単に「流行っているから」という理由だけでReactを選ぶわけではない。「SPA（Single PageApplication）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「Permalink |記事への反応(0) | 17:09
2025年、私たちはソフトウェア開発の歴史的な転換点に立っている。大規模言語モデル（LLM）の進化は、GitHub Copilotのようなコード補完ツールに始まり、今や「何を作りたいか」を自然言語で伝えるだけで、アプリケーションの雛形が数分で生成される時代を現実のものとしつつある。この光景を目の当たりにした多くのプログラマが、漠然とした、しかし確かな不安を抱いているだろう。「私たちの仕事は、いずれAIに奪われるのではないか」と。
この問いに対する私の答えは、半分はYesであり、もう半分はNoだ。より正確に言えば、プログラマの仕事の本質が、歴史上かつてないレベルで抽象化され、その役割が再定義されるのだ。私たちは、コードを「書く」作業から解放される一方で、これまで以上に高度な思考を要求されることになる。
本稿では、プログラミングの歴史を「How（いかに作るか）」から「What（何を作るか）」への移行として捉え直し、LLMがこの流れをいかに加速させるかを論じる。そして、その先にある、AIには決して代替できない、人間ならではの競争優位性、すなわち「Why（なぜ作るのか）」を定義し、記述する能力の重要性について深く考察していく。これは、単なる未来予測ではない。今を生きるすべてのソフトウェアエンジニアにとっての、生存戦略の提示である。
LLMの登場を特異点として捉える前に、我々が立っている場所を正確に知る必要がある。ソフトウェア開発の歴史は、常に「抽象化」との戦いであった。そしてその歴史は、プログラマの関心が「How」から「What」へと徐々に移り変わっていくプロセスとして描くことができる。
コンピュータの黎明期、プログラミングとは、計算機が理解できる命令（How）を、一行一行、丹念に記述する作業そのものであった。アセンブリ言語や初期のFORTRAN、COBOLといった言語は、ハードウェアの制約を強く受けており、プログラマはメモリ管理やプロセッサの動作といった、極めて物理層に近いレベルでの「How」を意識する必要があった。
この時代のテストもまた、「How」に強く束縛されていた。書かれた手続きが、意図した通りに順番に実行されるか、特定の入力に対して期待された計算結果を返すか。テストの関心事は、あくまで「手続きの正しさ」の検証にあった。ビジネスロジックと実装の詳細が密結合し、コードは特定の処理手順を記述した、硬直的な塊となっていた。
風向きが変わり始めたのは、ソフトウェアの規模が拡大し、その複雑性が人間の認知能力を超え始めた頃だ。1990年代後半から2000年代にかけて提唱されたエクストリーム・プログラミング（XP）の中で、テスト駆動開発（TDD）という考え方が登場する。
TDDの本質は、単なるテスト手法の改善ではない。それは、プログラミングのパラダイムを根底から覆す思想だった。TDDは、「まずテストを書く」ことを強制することで、プログラマの意識を「これから実装するコード（How）」から「そのコードが満たすべき振る舞い（What）」へと強制的に転換させたのだ。
テストはもはや、書かれたコードの後追いで正しさを検証する作業ではない。それは、これから作られるべきソフトウェアの「仕様書」であり、「振る舞いの宣言」となった。例えば、「ユーザーがログインボタンをクリックしたら、ダッシュボード画面に遷移する」というテストコードは、具体的な実装方法（`onClick`イベントハンドラの中で`window.location.href`を書き換える、など）には一切言及しない。それはただ、達成されるべき「What」を記述しているだけだ。
この思想は、ビヘイビア駆動開発（BDD）へと発展し、`Given-When-Then`といった、より自然言語に近い形式でソフトウェアの振る舞いを記述するスタイルを生み出した。プログラマだけでなく、プロダクトマネージャーやビジネスアナリストといった非技術者をも巻き込み、「What」を共通言語として定義する試みが本格化したのである。
TDD/BDDによってプログラマの意識が「What」に向かい始めると、コードそのものもまた、宣言的なスタイルへと進化していく。この変化を劇的に加速させたのが、モダンなフレームワークの存在だ。
Reactを例に考えてみよう。Reactが登場する前、フロントエンド開発はjQueryに代表されるように、DOMを直接操作する命令的なコード（How）の連続だった。「このボタンがクリックされたら、この要素のテキストを書き換え、あちらの要素を非表示にする」といった具合だ。
しかし、Reactは「UIとは、ある状態（state）に対する純粋な写像である」という宣言的なモデルを提示した。プログラマがやるべきことは、UIの状態（`state`）と、その状態がどのように見えるか（JSXによるコンポーネント）を宣言することだけだ。状態が変更された際に、DOMをどのように効率的に更新するかという面倒な「How」の部分は、Reactの仮想DOMと差分検出アルゴリズムがすべて隠蔽してくれる。プログラマは「What（UIのあるべき姿）」を記述するだけでよくなったのだ。
この「WhatからHowへの変換」は、様々な領域で見られる。
これらのフレームワークやツールは、いわば「特定の制約下における、WhatからHowへの高性能な変換器」として機能してきた。プログラマは、フレームワークが課す「お作法」や「制約」を受け入れることで、退屈で間違いの多い「How」の記述から解放され、より本質的な「What」の定義に集中できるようになった。我々が「生産性が高い」と感じる開発体験は、この優れた変換器の恩恵に他ならない。
現状は、この歴史的変遷の延長線上にある。プログラマの仕事は、手続きを記述する職人から、振る舞いを定義し、それを実現するための最適な「変換器（フレームワーク）」を選択・設定するアーキテクトへと、その重心を移してきたのだ。
フレームワークがもたらした「WhatからHowへ」の潮流は、LLMの登場によって、未曾有のスケールで加速されようとしている。フレームワークが「特定の領域に特化した変換器」であったのに対し、LLMは「あらゆる領域に対応可能な、究極の汎用変換器」としてのポテンシャルを秘めているからだ。
前章で述べたように、ReactやTerraformといったフレームワークは、その恩恵と引き換えに、私たちに特定の「制約」を課してきた。Reactを使うならコンポーネントベースで思考し、状態管理の作法に従う必要がある。Terraformを使うなら、そのエコシステムとHCLの流儀を受け入れなければならない。これらの制約は、WhatからHowへの変換を自動化するための「レール」であり、私たちはそのレールの上を走ることで効率を得てきた。
しかし、LLMはこの前提を覆す。LLMは、特定のフレームワークや言語の知識を事前に学習しているが、その利用において絶対的な制約を課すわけではない。私たちは、より自由な形式で「What」を伝えることができる。
例えば、こうだ。
ユーザー認証機能付きのシンプルなブログアプリを作ってほしい。フロントエンドはReactとTypeScript、UIコンポーネントはMUIを使う。バックエンドはNode.jsとExpressで、データベースはPostgreSQL。ユーザーはGoogleアカウントでログインでき、新しい記事を作成、編集、削除できる。記事にはマークダウン記法が使えて、画像もアップロードできるようにしてほしい。
この要求（What）は、特定のフレームワークの流儀に則ったものではない。複数の技術スタックを横断し、機能要求を自然言語で並べただけのものである。しかし、現在のLLM、特にGPT-4oやそれに類するモデルは、このレベルの要求から、ディレクトリ構造、設定ファイル、APIエンドポイント、フロントエンドコンポーネントに至るまで、驚くほど具体的なコード（How）を生成することができる。
これは、フレームワークが担ってきた「WhatからHowへの変換」が、特定のレールから解き放たれ、より広範で柔軟な領域へと拡張されたことを意味する。これまで自動化が難しかった、あるいは特定のフレームワークが存在しなかったニッチな領域や、複数の技術を組み合わせる複雑なシステム構築においても、AIによる宣言的プログラミングの恩恵を受けられる時代が始まろうとしているのだ。
LLMという汎用変換器の登場により、プログラマの生産性は、「いかに質の高いWhatをLLMに伝えられるか」に直結するようになる。これは、俗に「プロンプトエンジニアリング」と呼ばれるスキルだが、その本質は、ソフトウェア開発における「要求定義」そのものである。
質の高い「What」とは何か。それは、曖昧性がなく、網羅的で、矛盾のない要求である。
これらは、優秀なソフトウェアエンジニアが、プロダクトマネージャーやデザイナーとの対話を通じて、日常的に行ってきた思考プロセスそのものではないだろうか。LLMの登場は、この思考プロセスを、より明確に、よりテキストベースで「記述」する能力を求める。私たちの頭の中にあった暗黙的な仕様が、LLMへの入力（プロンプト）という形で、明示的に言語化されることを要求するのだ。
やがて、ほとんどのプログラミング作業は、この「Whatの記述」に収束していくだろう。TDDがテストコードという形式で「What」を記述したように、私たちは自然言語や、より構造化された要求記述言語を用いて、AIに対して「What」を宣言することになる。コード（How）は、その宣言から自動生成される中間生成物に過ぎなくなる。まさに、コードが蒸発していく未来である。
「What」を伝えれば「How」が手に入る。この魔法のような世界の到来を前に、私たちは一つの重大な問いに直面する。それは、「そのWhatからHowへの変換は、本当に一意に決まるのか？」という問いだ。
答えは、明確にNoである。
ある「What（要求）」を実現するための「How（実装）」は、無数に存在する。そして、どの「How」を選択すべきかを決定するためには、単純な機能要求（What）だけでは情報が全く足りない。そこには、必ず「Why（なぜそう作るのか）」という、背景、文脈、そしてトレードオフの考慮が必要不可欠となる。
簡単な例を考えてみよう。「1億件のユーザーデータを格納し、ユーザーIDで高速に検索できるシステム」という「What」をLLMに与えたとする。LLMは、どのような「How」を提案するだろうか。
これらの選択肢は、どれも「What」を満たしている。しかし、その特性は全く異なる。案Aは多くのエンジニアにとって馴染み深く開発が容易だが、10億、100億件へのスケールは難しいかもしれない。案Bはスケール性に優れるが、厳密なトランザクション管理は苦手だ。案Cは高速だが、運用コストとシステムの複雑性が増す。案Dは安価だが、検索速度は他に劣る。
LLMは、これらの選択肢をリストアップすることはできるだろう。しかし、このプロジェクトにとって最適な選択肢はどれかを、自信を持って決定することはできない。なぜなら、その決定には、LLMが与えられていない「Why」の情報が必要だからだ。
これらの「Why」こそが、無数に存在する「How」の中から、ただ一つの「正解」を選び出すための羅針盤なのである。そしてこの「Why」は、ビジネスの目標、組織の文化、ユーザーの期待、技術的な制約といった、極めて人間的で、文脈依存的な情報の中にしか存在しない。
ここで重要なのは、これまでもエンジニアは、この「Why」に基づく意思決定を、意識的あるいは無意識的に行ってきたという事実だ。
私たちが技術選定を行うとき、単に「流行っているから」という理由だけでReactを選ぶわけではない。「SPA（Single PageApplication）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「Permalink |記事への反応(0) | 17:09
ここで、「Aのデータと共に、関連するBとCのデータも取得したい」という一般的な要件を考えます。多くの人が最初に思いつくのは、`JOIN`を使ったクエリでしょう。
SELECT A.A_id, A.A_attrs, B.B_attrs, C.C_attrsFROM AJOIN BON A.B_id = B.B_idJOIN CON A.C_id = C.C_idWHERE A.A_id = 'some_a_id'; --特定のAレコードを取得する場合
このクエリは、B,Cの重複が大量発生し、さらに属性のデータサイズが大きい場合は非効率になる可能性があります。
データベースは`JOIN`を行う際に、結合条件に合うレコードを探すために複数のテーブルをスキャンしたり、一時的な結合結果を作成したりするオーバーヘッドが発生します。
特に、`JOIN`するテーブルの数が増えたり、それぞれのテーブルのレコード数が多かったりすると、このオーバーヘッドは顕著になります。
また、「JOIN乱用するなら第三正規形にする必要ないんだよな」という点も重要です。
第三正規形はデータの冗長性を排除し、データの一貫性を保つための設計原則です。
しかし、その結果としてデータが複数のテーブルに分散され、結合が必要になります。
もし結合による性能劣化が許容できないレベルであれば、データの一貫性を犠牲にしてでも、冗長性を持たせる（非正規化する）方がパフォーマンス上のメリットがあるというジレンマに陥ることもあります。
しかし、それは正規化のメリット（データの一貫性、更新時の不整合防止など）を失うことにもつながります。
主張されているのは、以下のようなアプローチです。
1. まずAのデータを取得する。
2. Aのデータから得られた`B_id`と`C_id`を使って、必要に応じてBとCのデータを個別に取得する。
--ステップ1: Aのデータを取得SELECT A_id, B_id, C_id, A_attrsFROM AWHERE A_id = 'some_a_id';--アプリケーション側で、上記で取得したB_idとC_idを元に、必要であれば以下のクエリを発行--ステップ2: Bのデータを取得 (例: Aから取得したB_idが'b1', 'b2'だった場合)SELECT B_id, B_attrsFROM BWHERE B_id IN ('b1', 'b2');--ステップ3: Cのデータを取得 (例: Aから取得したC_idが'c1', 'c2'だった場合)SELECT C_id, C_attrsFROM CWHERE C_id IN ('c1', 'c2');
この方法の利点は以下の通りです。
Laravelを使ってる奴けっこう多いと思うんだけど、みんなEloquentに満足してるの？
自分は正直、あれが賢いと思ったことが一度もない。触るたびにゴミ箱に捨てたくなる。
たとえば、belongsToとかhasOneみたいなリレーション。普通なら、JOINで一発で取りたいじゃん？
でもEloquentは基本的に別クエリでselectしやがる。
「with使えばいいじゃん」とか言ってるやつ、頭の中までEloquentに最適化されてんじゃねえのか。
いや、確かにwithでまとめて取れるけど、それでもJOINじゃなくて複数クエリ投げてるだけだからな？
リレーション多いDB設計になってくると、Eloquentの無能っぷりがどんどん見えてくる。
速攻でN+1問題にブチ当たって、「え？みんなこれで仕事してるの？」って本気で思うわ。
あと、Laravelのマイグレーションもゴミ。DB周り本当にゴミ。
自分もLaravelに初めて触れたとき（もう十年以上前か）「これが現代のPHPか」と思って浮かれてたけど、業務でLaravelを自ら選定したのは一度だけだわ。
引き継ぎ保守でLaravelを触るとめっちゃ気分が下がる。マジで滅びてくれんかな。
世のLaravel信者たち、「Eloquent最高！」とか言ってるけど、あんたたちもEloquentと同じレベルでバカになってないか？
IR（情報検索）や推薦システム（Recsys）における「セレンディピティ」についてですね。
関連性、新規性、多様性、人気性といった指標は比較的理解しやすい一方で、セレンディピティは確かに掴みどころがないと感じるかもしれません。
セレンディピティ（Serendipity）は「偶然の幸運な発見」「予期せぬ有用な発見」といった意味合いで用いられます。
情報検索や推薦システムの文脈では、ユーザーが求めている情報や好きそうなアイテムを直接的に提示するだけでなく、ユーザーが「知らなかったけど、これは素晴らしい！」と感じるような、予期せぬ驚きと喜びを伴う発見を指します。
関連性だけを追求すると、システムはユーザーの過去の行動や明示的な好みから導かれる、非常に「安全な」推薦ばかりをする傾向があります。これはこれで重要ですが、以下のような問題点も生じます。
1.フィルターバブル/エコーチェンバー：ユーザーが常に同じような情報に触れることで、視野が狭まり、新しい視点や情報に触れる機会が失われる。
2. 飽き： 常に似たような推薦ばかりでは、ユーザーは新鮮味を感じなくなり、システムの利用から離れてしまう可能性がある。
3.潜在的ニーズの掘り起こし：ユーザー自身がまだ気づいていない、しかし非常に高い満足度をもたらす可能性のあるニーズを掘り起こす機会を逃す。
セレンディピティは、これらの問題を解決し、ユーザー体験をより豊かにするために重要となります。
システムがユーザーを「驚かせ」「喜ばせる」ことで、ユーザーエンゲージメントの向上や、長期的なロイヤルティの構築に繋がります。
セレンディピティは、非常に測りにくく、実装も難しい概念です。いくつかの試みやアプローチがあります。
1.多様性（Diversity）との関連： 多様な推薦をすることで、結果的にセレンディピティが生まれる可能性が高まります。ただし、多様性が高すぎると単なる「ノイズ」になる可能性もあるため、バランスが重要です。例:ユーザーの通常の視聴履歴とは異なるジャンルの映画を、関連度は低いが一定の人気や評価があるという理由で推薦する。
2.新規性（Novelty）との関連：ユーザーがまだ知らない、新しいアイテムを推薦する。しかし、単に新しいだけでなく、ユーザーにとって「有用な」新規性でなければセレンディピティには繋がりません。 例:ユーザーが普段聞かないようなインディーズバンドの、しかし高い評価を得ている曲を推薦する。
3. 意外性（Surprise）の導入：ユーザーの期待を意図的に裏切るような推薦。ただし、これも「不快な驚き」にならないよう注意が必要です。例:ユーザーがクラシック音楽ばかり聴いているが、過去に一度だけ興味を示したことがあったジャンル（例えばジャズ）から、そのジャンルの名盤を推薦する。
4. 探索的な推薦戦略：ユーザーの明示的なクエリや行動だけでなく、より広範な情報（例：世間のトレンド、専門家の意見、他の類似ユーザーの意外な行動など）を取り入れて推薦候補を生成する。「探索（Exploration）」と「活用（Exploitation）」のバランス： 推薦システムは、ユーザーの過去の行動から「活用（Exploitation）」して関連性の高いものを推薦するだけでなく、新しい可能性を「探索（Exploration）」してセレンディピティを生み出す必要があります。
5.偶発性の設計：システムが意図的に、ある程度のランダム性や偶発性を推薦プロセスに組み込むこともあります。ただし、これも「単なるランダム」にならないための工夫が必要です。
セレンディピティは、情報検索や推薦システムにおいて、ユーザーに「知らなかったけど、これは良い！」という予期せぬ喜びと発見をもたらす、非常に価値の高い指標です。
関連性、新規性、多様性といった他の指標と密接に関連しながらも、それらを組み合わせることで生まれる「化学反応」のようなものです。
測定が難しく、実装も試行錯誤が必要な分野ですが、ユーザーの長期的な満足度やエンゲージメントを高める上で、今後ますます重要になっていくでしょう。
