  |
はてなキーワード:データベースとは
本レポートは、日本の放送における政治的中立性という長年の課題に焦点を当て、その具体的な実態、資金源と権力の関係性、そしてデジタル時代の情報環境の変化がもたらす影響について、多角的に考察したものである。特に、電波が公共の財産であるという日本の特殊な放送構造と、それに起因する固有の課題について深く掘り下げるとともに、諸外国の事例やブロックチェーンの概念を交え、情報信頼性確保に向けた論点を提示する。
日本の放送法第4条は放送事業者に「政治的に公平であること」を義務付けている。この「公平」の解釈は長年議論の的となっており、現状では量的公平（ある候補者に報じた時間を他の候補者にも同程度割く手法）が広く採用されている。
「公平」の多様な解釈
日本の放送は、受信料で運営されるNHK（日本放送協会）と、広告料で運営される民間放送に大別され、それぞれ異なる構造的課題を抱えている。
民間放送は広告収入に依存するため、以下のような形で政治的中立性が脅かされる懸念がある。
NHKは受信料で運営されるため広告主からの直接の影響を受けない一方で、政治との根深い関係性が指摘される。
ガバナンスの強化や透明性の確保は、国民の監視が伴って初めて実効性を発揮する。日本の政治資金問題が示すように、監視の目がなければ問題は放置されうる。
諸外国における取り組み
他国では、政治資金の透明性確保やメディアの独立性確保のために様々な制度的アプローチが試みられている。
ブロックチェーンの概念は、情報の透明性と改ざん困難性という点で、政治資金やメディア報道における情報信頼性確保の可能性を秘めている。
最大の課題は、「フェイクを流すことで利益を得ようとするモチベーション」が、「正しい情報環境を守ろうとするモチベーション」よりも往々にして高いという点である。センセーショナルなフェイクニュースは速く拡散する（ベロシティが高い）のに対し、事実確認や訂正は時間と労力がかかる（ベロシティが低い）。このモチベーションの非対称性が、健全な情報環境の維持を困難にしている。
日本の放送における政治的中立性確保は、放送法の解釈、資金源、そして政治との構造的な関係性という複数のレイヤーに課題を抱えている。諸外国の取り組みやブロックチェーンのような技術的解決策は参考になるものの、それらはあくまでツールに過ぎない。
最終的に、健全な情報環境と民主主義を維持するためには、国民一人ひとりのメディアリテラシーの向上、そして政治やメディアに対して不透明な部分を批判的に検証し、声を上げていく「不断の努力による監視」が不可欠である。技術と人間の努力が組み合わさって初めて、情報の信頼性が担保される社会が実現されるだろう。
データベースはアンパンマンDBというサイトがあるのでそこから拝借。
データベースには過去のアニメアンパンマンのタイトルが全て載っている
アンパンマンのタイトルはたとえば「バイキンマンとあかちゃんまん」みたいに、キャラとキャラの組み合わせでできていることがほとんどだ
そして、一度組み合わさったペアは二度と組み合わされることはない（「バイキンマンとあかちゃんまん」の組み合わせが2回起こることはないという意味）。
私はExcelを駆使し、過去の組み合わせが出ないようにして、ランダムに組み合わせができるルーレットを作った。
それを回し、次回のアンパンマンのタイトルと一致すれば、勝ち、というルールを設けた。
その組み合わせは膨大なものなので、ルーレットで次回タイトルを当てるのは至難の業だ
冬だとゆきだるまマンが出てくる確率が上がるので、ゆきだるまマンを固定して片方をルーレットで選べばいいことになる
しかしこれでも当てるのは難しい
そこで、主要キャラ（しょくぱんまん）などはルーレットで出てきやすく確率を調整した
さて、出来上がったルーレットだが、私はこれでオモコロに応募しようとした
こういうのは当ててナンボだと思うので、当たらないと記事にならない
残念ながら記事を書き上げることはできず、お蔵入りとなった
そう思っている
なんか絶賛してる人多いけどダメでしょあれは...
数日前のPlazmaジークアクス終了記念MVとほとんど同じじゃん
素材不足の中、ニャアンをフィーチャーした映像にしようとしたのはまあ理解できるんだけどさ
6,7話あたりの鬱屈した心境の歌なのに、それ以降の「解決編」シーンがバンバン入っちゃってる
挙句の果てに、MVと歌詞から、ニャアンの心情だとか、シュウジへの恋心の歌なのかマチュへの友情の歌なのかって考察してるやついるけど、的外れすぎるわ
まあ曲は良いんだよね。ってか良い挿入歌多いのに活かしきれてないよねぇ
彼女が初潮を迎えるずっと前、つまり給食のプリンとコッペパンの順序をいまだに悩む程度の精神年齢の頃、卵子は既に冷凍庫の底でカチカチに凍っていた。念のため言っておくが、これは「闇の陰謀」とか「人権派弁護士のうるさいお説教ネタ」ではない。
もっとお洒落で、もっと合理的で、もっと世界を照らすような——うけけけけけけけけけけけ、そんな未来の輝かしい話なのだ。
当時、彼女は七歳。乳歯が二本グラつき、給食の牛乳にうぇっとなりながら涙目になっていた日だ。自治体と生殖工学企業が結託……いや、提携し、「未来母体プログラム」なるモデルケースに選出された。彼女の卵巣からは未成熟卵胞が、まるでお祭りの屋台で釣った金魚みたいにすくわれ、特殊培養液でぐるぐるされ、やがて液体窒素の底で夢を見はじめた。
「これで人生の自由度が一つ増えたね！」と白衣の医師は、試供品のように安い笑顔で言ったという。彼女は意味も分からず、鼻水をすすりながら給食のわかめご飯をかきこんだ。
あれから十数年。彼女は25歳になり、情緒と呼ばれる部位はスッパリ切除された。成果主義の荒野で、彼女はザクザクと書類を切り裂き、会議室を血のない剣で斬り伏せる。
月経？ そんなものは五年前にホルモン制御剤で強制終了。PMSも排卵痛も恋愛脳も、ぜーんぶまとめて廃棄済み。
でも彼女には用意周到に仕込んでおいた「15歳のときに採取した後輩男子の精子ファイル」があった。男は淫乱で、卒業後には保健所の性感染症データベースを賑わせる超人気ユーザーになったが、幸いにも高校二年のあの頃の彼はまだ純粋無垢。冷凍庫の中で、彼は永遠の童貞だ。けけけけけけけけけ。
ある朝、トーストを咥えたまま、タブレット片手に「今日、使うわ」とつぶやいた。
まるでコンビニで「おにぎりとお茶、温めますか？」と言うノリで。
彼女は某国にある日本主導の「バイオファクトリー#J-13」をタップ。卵子ファイルと精子ファイルをAIマッチングし、現地女性の「安産スコア」と「精神耐久値」をAIが計算する。選ばれし「未来母体」は、若く健康で、自己主張ゼロ、笑顔と沈黙を同居させる奇跡の肉体。
「ありがとー！」「頑張りまーす！」と元気に笑う代わりに、彼女らはただ黙って深呼吸するだけだ。
出産予定日は230日後。
だが彼女にとって、それは「人生タスクB-2」程度のタスクにすぎない。生まれた子はファクトリーのAIチャイルドケアユニットに吸い込まれ、育児スケジュールはクラウド同期、感情フィードバックは週に一度、AI心理コーチが「赤ちゃんは今日も機嫌が良いですよ」と報告する。
彼女が涙を流す？ そんなものはとっくに生理と一緒にアンインストール済み。
「自分の身体で産むなんて、昭和の土偶じゃあるまいし、無理無理」と彼女は目尻を引き上げながら嘲笑した。
もはや周囲に反論する者はいない。いや、反論という行為自体が社会プロトコルから削除済みだ。
男は後にインタビューで言った。「俺の精子、使われたって知って、ちょっと誇らしかったよ……でもな、俺、ちょっと寂しい気もしたんだ」
それを聞いた彼女はモニター越しにうっすらと目を細め、「あら、あなたね。ありがと。でも、会う予定？ ないわよ」と言った。
某国の育成ファクトリーの大型スクリーンに映る赤ん坊は、ぐにゃっとした笑顔でこちらを覗き込んでいる。
母子関係はクラウド管理、週一のフィードバックで「母性愛」アカウントに点数が加算される。便利でしょ？ うけけけけけけけけけけけけけけけけ。
彼女はタブレットをぱたんと閉じ、カフェイン切れの頭で次の出張スケジュールを確認した。
再投稿は言論の自由の例外(はてなのデータベースを無駄に使うからローカルルールとして)
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250706171643# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaGow6gAKCRBwMdsubs4+SFjvAP0X0V6k53pLnqOPnx7yjCA39A+j8qRdI/Z6vvRkd/ffuAEA8UbNoJy/pRDpqRgl9zGayJMRr8UK3ve6FHsEsZZP3Ag==P9FD-----ENDPGP SIGNATURE-----
レジ袋規制で海岸のプラスチックゴミに変化はあったのか 研究で明らかに |日本でも有料化が導入されたが
https://b.hatena.ne.jp/entry/s/courrier.jp/news/archives/405648/
プラスチック製レジ袋の禁止に意味はあるのか。そんな議論に終止符を打つかもしれない研究結果が米学術誌「サイエンス」で発表された。
ここ数年で米国の海や川、湖では何万回もの清掃活動が行われ、ボランティアらは水辺で回収したゴミをグローバルデータベースに記録してきた。
いずれの場所でも多かったゴミの一つが、プラスチック製レジ袋だった。
しかし、サイエンス誌に掲載された研究によると、プラスチック製レジ袋が有料化されている地域や禁じられている地域の水辺ではそれらのゴミが少なかったという。
https://anond.hatelabo.jp/20250630114221 https://anond.hatelabo.jp/20250626125317 https://anond.hatelabo.jp/20250627100609 https://anond.hatelabo.jp/20250628122821
AI技術を批判する記事がバズりまくってるが、それに対して凄い数の批判がいってる、だけど肝心の批判は個人攻撃めいていて、どれも技術的な部分はふわふわした物言いなので
どれだけ技術的にまったく使い物にならないかを、技術面から3つ理由を上げようと思う、これを見れば、確かにＡＩってそんなもんじゃないな、って正しい理解が進むと思う、と同時に、
ネットでAIを擁護したり喧伝してる人間で誰一人、エンジニアを自称したりしてる奴らでさえAIを理解してる人間がゼロっていうのがわかると思う
ちなみに、IT技術を全然知らない増田向けに技術的な部分は補足説明を入れているので、ちょっと長くなってるかもしれない
LLMがわかっていない！と喚いてる当人たちも上で言った通り、LLMっていうのが理解できてないの丸わかりなので、ここでまずLLM「大規模言語モデル」とは何かを簡単に説明しよう
生成AI（特にChatGPTのような大規模言語モデル、LLM）というのは「文脈に最もふさわしい次の単語を予測する」」という統計的タスクを行っている、これがLLMだ
「飲みます」→90%の確率 「買いました」→7% 「投げました」→0.5%
この過程には、意味理解や感情、意図、文脈の内的把握は一切関わっていない、これが致命的な欠陥の1つ
プログラミングを自動でまるで仮面ライダー01の01ドライバーの様にベルトの作成までやってくれているように喧伝してる奴らが多い
が、これを本気で信じ込んでプログラミング言語を書かせた奴がいたら、ほぼ間違いなくクビになる
わかりやすく上で例えた通り、LLMは、インターネット上に存在する膨大なコード断片・技術記事・GitHubリポジトリ・StackOverflowの投稿などを学習している。
そのため【よく使われる文法構造】や【特定の言語における関数の使い方】や【ライブラリの典型的な使い方】などを【意味を全く理解できず模倣している】だけって事
【動かないコードをアホほど入れる(変数が未定義、型が合っていない、ライブラリに存在しない関数を呼んでいるとかいう小学生のプログラミングスクールでもありえないミス】
【. 「それっぽいけど間違っている」コードを大量に入れ込む(SQLインジェクション、XSSなどセキュリティ上危険な実装を入れまくる、パフォーマンスが極端に悪い実装、バグを含んでいるロジック（特にif文の条件分岐ではほぼ100％発生する)】
【実行環境に依存した誤り(存在しないAPIやライブラリを使う、ほぼ9割の確率で…あと特定のPythonバージョンやNode.js環境でしか動かないコードを汎用的に提示、つまり動きようがない)
専門的な意見となったのでわかりづらいので、もっとわかりやすく言うと「小学校のプログラミングスクール入りたて1週間の子供が書いためっちゃくちゃなプログラミングにすらなってないコードを、製品利用するからレビューして出してこい」と言われてるに等しい、つまり、最初から自分で書いた方が早い2度手間になる
これが、プログラミングの革命だ！とか喚いてる奴らが隠すAIの実態である。
import jwt
token = jwt.encode({'user_id': 123}, 'secret', algorithm='HS256')
一見正しく見えるだろうから解説すると、実際には 【jwt という名前のライブラリ】が複数存在し（PyJWT,python-jwtとか）importの仕方によってエラーが出たり挙動が変わったりする。普通なら絶対間違えない様な挙動をAIは構造上全く判断できない、これは上で上げた根本的な問題なので恐らく絶対に解決できない。
ハルシネーションがどういうものであるのか、AI批判でバズった記事などで言及されている通り、デマやデタラメを出力してしまう、あれは本当にわかりやすいAIの致命的欠陥を検証してるので、あえて説明はここではしない。
しかもその増田の元記事では「文章データのテキストまで読み込ませれば間違いがなくなるのでは？」といってたが、これも絶対になくならない、というより、もっとひどくなる。
批判をしている増田やXでの意見は単なる個人攻撃の誹謗中傷のみで、技術的に改善可能なプロセスさえ示せていない、例えば現在研究者の間では以下の様な解決案は研究されているが、どれも全く問題外とされている
これは、AIが「知っている風」に語る代わりに、外部の信頼できるデータベースや検索エンジンから情報を引っ張ってくる方式、バズった元記事の増田がやっていた「自分で図書館言って本の内容読んで誤りであることを確認する」これを検索エンジン使ってAIにさらにやらせる、という機能だ
また【メタモデル】すなわち、AIが自分の出力を裏でさらに別のAIが別プロセスでチェックして間違いをただす、という方式も研究されてる。
これは致命的な欠点が2つある、まず「検索で引っ張ってくる知識そのものが間違いだった場合、さらに間違いの結果を出し続ける」ということ。
元記事の増田はMP5というマシンガンの有効射程について突っ込んでいたと思うが、これが典型的なRAG、メタモデルの致命的欠点、元増田は「実際に自分の手で銃を取り扱ったりしたことがある確かな経験で言ってる」が、書籍などの工業スペックや仕様書の定義でしかネット上では流布してない、だからそもそも答えというものにAIがたどり着けない。
2つ目は「文脈や倫理・常識・道徳が根本的に読めないので、解決策が乱暴すぎるもの」になる。
上で上げた鉄砲以外では、例えば医学などでこれをやってしまうと取り返しのつかないことになる。例えば医者の投薬治療や治療はガイドラインに従ってるというが、優れた医者は論文を読み込んで原理は不明だがエビデンスはあるので、漢方薬を出したりするというお医者さんがよくいるだろう。あれは実際に患者を診て、西洋医学的には全く問題ないが、心理的な面も絡んで心身症になっているから、論文などで勉強して「暗黙知、経験知」として処方してるし、その量も患者を診た医者の経験で精度を上げている。
そして医療分野では、「冷え性の軽いむくみ」に対して「サムスカ（トルバプタン）」という劇薬指定の危険な利尿薬をAIが提示した事例すらある。これを「笑い話」で済ませることはできない。
例えるなら判断が「脳外科医竹田君」並になる、投薬治療で3か月で治る程度の病気を、病根から外科手術で切除しましょう、なんて提案になる。最新のAIなのに80年前みたいな医学知識と判断になってしまうのだ(胃潰瘍ってだけで胃袋は全摘、ついでに脾臓と盲腸もいらねーからとっとこ、みたいな手術が昭和の昔、本当にガイドライン治療だった、「K2」などで言及されている)
学習できるベースがどうしても偏る以上、情報の統合に限界がある、さらに間違いが間違いをよび、さらに変な間違いを起こしたりありえない架空のことをいったりする、これがハルシネーションというメビウスの輪である
Neuro-symbolicAIという次世代のさらに文脈も読み取れるアーキテクチャAIを研究しているが、全く実用化されていない、核融合や量子コンピューターみたいな雲をつかむ話なので、AIがこの問題を解決することは恐らく今後数百年はありえない、という結論が出ている。
元増田の記事で批判もあったが、恐らくAIで一番致命的な問題はこれ
基本的にAIは英語ソース、つまりリングワ・フランカで圧倒的にテキスト量の多い(約95％)英語、日本語含めそれ以外の全世界言語が5パーセントという偏った学習になっている
そのため、倫理・道徳・常識・規範などがすべて西洋基準になってしまう、という問題がある。(元増田はこれを「脱獄の基準の倫理は誰が決めるのか？」と根本的な問題に気が付いていて批判していたようだ)
ちなみに、バズってた例の記事に「AIに書かせたんだろ」という批判も大量にあるしよくみかけるが、この場合においてのみ言うなら、これは③の問題からまずありえないということがわかる、以下が根拠だ
元増田は「俺達の麻生とかいって秋葉原で踊ってた…」とか「レムちゃん、エミリアたん、ヘスティアちゃん、ウマ娘たん、刀剣乱舞くん、ライカン様…」といった批判を繰り返し書いていた
これに激怒できる人間は、2005～2010年にオタク界隈や秋葉原にすでにかかわっていて、実際に渦中にいたか同じ属性の人間でしか、罵倒されていると文脈的に理解できないのである。つまり、大量の英語文化圏情報を食ってるAIではなんでそれが罵声や侮蔑なのか理解できないので、書きようがない表現の数々、であるということである。
AIからすれば「ライカン様？ウマ娘？なんじゃそりゃ」なのである、もっと言えば、その直後にコンテクストとして「アホ、ボケ、弱者男性、豚丼、性器や自慰で虚しく…」といった言葉があるから、なんならAIはウマ娘やライカンをキャラクターでなく侮蔑単語として理解してしまう、これは実際、元増田の記事の一文をAIに食わせて質問したらガチでそうなるので、ぜひお手元で試してもらいたい。
「プログラマーのイメージを描いて」と依頼すると、男性の画像ばかりが出るされる
「看護師」→女性、「エンジニア」→男性という職業的性差が自動的に反映される
「アフリカの文化」→貧困・紛争・サバンナなど、植民地主義的視点が強く反映される(実際は南アなどはすげえ都会である)
これに前述のハルシネーション問題として現れれば、人間と同じような差別や偏見を「ガチの真実」として学習してしまう、人間の場合、8割くらいは本当はおかしいこととメタ批判が心理的にできるとされているが、AIにはその構造が根本的に存在しない。
元増田の記事のコメント欄やXなどで元増田のAI批判を批判しつつ、「金持ちの上級白人専用のハイエンドAIがあるに違いないんだ」といっている意見が少なくない数がある。
冷静に考えれば、そんなめんどうくせえもん誰が作るんだ、と普通に考えればわかるのだが、この③の問題、すなわち95％の学習データが英語ソースなので、結果的に西洋文明ベースの文化圏の人間向けにカスタマイズされているので、アジア圏やその他文化圏では利用に不利でそう感じてしまう素地ができている、という錯覚に由来している
例えば、パレスチナ問題などがそうだ、ガザ地区でほぼ国際条約や人道違反の残虐行為を国が行っているわけで、他文化圏や歴史的文脈から見ればどっちかって言えばパレスチナ人こそ被害者なのだが、イスラエルから見ればそれは正義であり正当な攻撃なわけで、後者の方がＡＩは正しいと判断した結論を下す様になる、といった問題である
あの記事の元増田は「テロ組織のヤバイマニュアルまで学習してpdfで元データを提示してきた」と言っていた。実際AIに調べさせて持ってこさせてみると、出所はアメリカの法務執行機関が研究用にネットで公開したものであった。
日本人や日本の警察の対応レベルで「ヤバイ」ものでも、海外の軍隊みたいな装備の警察で見れば大したことがないから、公開させてもいい＝倫理違反には当たらない、という文化規範の意識の違いを、あの元増田自身が証明してしまっている、あの記事は、ＡＩの治しようがない根本的な技術的欠陥をほとんど言及しているといっていい
元増田が口汚く罵っている内容の様に、「AIは0を1にできないから格差が広がるだけ」という根本的な哲学を投げつけている
それを受けて批判してる意見の中には「(自分が1を持ってる側と何故か根拠もなく信じ込んでて)100にできるから(なら)便利」とか「そのAI今から勉強したりしてる俺たちは先行者利益で強者になれる」と信じて疑わない意見が多かった
③問題の通り、そもそも非キリスト教圏かつ非英語圏の国家で生まれて育った民族、というだけで、我々は等しく「０」側の人間であり、結局競争になると勝てない、ということに全く気が付いていないのである。ここにAI信者の宿痾といえる病理がある
かつて日本人は黒船を見て5年そこらで蒸気機関を模倣した、火縄銃を一丁買えば10年でオスマン帝国の次に鉄砲を使うようになった、それは当時の日本人の基礎工学技術が導入可能なほど優れており、かつそれに対して現代では考えられないほぼバクチといっていい投資を行った結果であって、その結果を見て自分たちはAIを使いこなせて強くなれるなんていうのは、物凄い妄想である。つまり、AIは少なくとも「非英語圏」の人間にとっては、ブレイクスルーは絶対に起こりえない、ということである。
Permalink |記事への反応(17) | 08:43
わいはOTAとChannel Managerのシステム開発してた汚痔さんやで
宿泊業界は古くからシステム化された業界でクレジットカード並みに複雑やで
ChatGPTで作ったで
🔹定義
ホテルの宿泊・運営管理の中核となるソフトウェアシステム。フロント業務、客室管理、宿泊者データ、売上、会計などを一括で管理します。
🔹 主な機能
| 機能カテゴリ | 内容 |
|---|---|
| フロント管理 | チェックイン・チェックアウト、予約情報の登録・変更、宿泊者台帳の作成 |
| 客室管理 | 部屋の清掃状況、空室/在室の把握、客室割り当て（ルームアサイン） |
| 会計管理 | 宿泊料金の計算、追加サービスの加算、精算、領収書発行 |
| 顧客管理 | 顧客データベース（リピーター、法人など）、CRM連携 |
| 収益分析 | 稼働率、ADR（平均客室単価）、RevPAR（販売可能客室収益）などのKPI管理 |
| 他システム連携 | Channel Manager・OTA・POS（レストラン）・鍵システム・自動精算機 などとの連携 |
| 製品名 | 特徴 |
|---|---|
| OracleOPERA | 世界的な大規模ホテルチェーン向け。拡張性・連携性が高い。 |
| Cloudbeds | 中小規模ホテル向け。PMS＋Channel Manager＋BookingEngineの統合型。 |
| SiteMinder（PMS連携あり） | Channel Managerが有名だが、PMS連携も強力。 |
| TL-リンカーン（リクルート） | 日本国内向け。じゃらん連携に強み。 |
| AirHost | クラウド型。民泊や無人ホテル向けに強い。 |
🔹定義
宿泊施設（ホテル・旅館など）を代理で販売するオンラインの旅行代理店。
代表例：
🔹 特徴
🔹定義
複数のOTA・予約サイトに対して、一括で在庫・料金・予約情報を管理できるツール。
🔹 主な機能
🔹メリット
🔹定義
例：
🔹形態
🔹 注意点
┌────────────┐ │ 宿泊者 │ └────────────┘ ↓予約する ┌────────────┐ │ OTA①（Booking） │ ⇒Reselling ├────────────┤ │ OTA②（楽天） │ ⇒Reselling ├────────────┤ │ OTA③（Expedia） │ ⇒Reselling └────────────┘ ↑ │（在庫・料金同期） ┌────────────┐ │ Channel Manager │ └────────────┘ ↑ │（連携・同期） ┌────────────┐ │ PMS（ホテル管理） │ └────────────┘ ↑ ┌────────────┐ │ ホテル運営スタッフ等 │ └────────────┘
でも完全にシステム化されてるわけでもなく、OTAが予約登録したりするのは人力だったりするで🤢特に自前のシステム持ってないとことか
┌────────────┐ │ 宿泊者 │ └────────────┘ ↓予約する ┌────────────┐ │ OTA（Agoda Channel Managerとつながってない） │ └────────────┘ │メタサーチ ↓ ┌────────────┐ │ OTA（AgodaじゃないOTA） │ └────────────┘ ↑ │（在庫・料金同期） ┌────────────┐ │ Channel Manager │ └────────────┘ ↑ │（連携・同期） ┌────────────┐ │ PMS（ホテル管理） │ └────────────┘ ↑ ┌────────────┐ │ ホテル運営スタッフ等 │ └────────────┘
┌────────────┐ │ 宿泊者 │ └────────────┘ ↓予約する ┌────────────┐ │ ホワイトレーベル型OTA │ └────────────┘ ↑ │（Reselling） ┌────────────┐ │ ホワイトレーベル型OTA │ └────────────┘ ↑ │（Reselling） ┌────────────┐ │ ホワイトレーベル型OTA │ └────────────┘ ↑ │（Reselling） ┌────────────┐ │ ホワイトレーベル型OTA │ AgodaのAPI使って動いとるで └────────────┘ ↑ │（Reselling: Expedia AffiliateNetwork） ┌────────────┐ │ OTA（Agoda） │ └────────────┘ ↑ │（在庫・料金同期） ┌────────────┐ │ Channel Manager │ └────────────┘ ↑ │（連携・同期） ┌────────────┐ │ PMS（ホテル管理） │ └────────────┘ ↑ ┌────────────┐ │ ホテル運営スタッフ等 │ └────────────┘
ホワイトレーベル型のOTAはAgoda以外のOTAとも連携しとるけど、Agodaばっかりトラブルが起こっとるんってことはAgodaのシステム/契約があかんのやろなあ
たぶん売上伸ばすためアグレッシブに攻めすぎてOTA（Agoda）より上流のシステムでオーバーブッキングしまくっとるんやろ、OBの危険性を冒してまでResellingをガンガンやっとるんやろな
あとホワイトレーベル型OTAも閲覧時に部屋をHOLD（仮予約）しまくっとるとか行儀悪いことしとんの🦆
https://note.com/774notes/n/n1c420bc05911
CDBさん、リベラル偽装いつもお疲れ様だけどちょっと突かれるとすぐにミソジニーヒス起こすから面白いよねー。
植松死刑囚と結婚した女性の言い分に納得しない人がいるのはいいけど、結局「女性の性加害は否定してはいけないのかー！」ってミソ丸出しにするところが彼の限界
ひょっとしてこの人、なんかやまゆり園の事件で発狂しちゃうような「何か」をお持ちなのかしら？
女たちのデータベースはもう普通の女性の恐怖、怒りを救ってくれるインフルエンサーとして認知されてるからミソ弱者オスが都合よく人権派気取って叩いてももう厳しいと思いますよ
>>外国人や老人、さまざまな弱者に対する憎悪が社会の中で蓄積する。ある時に若い女性が叫ぶ。「私は彼らに性暴力を受けたんです」と。それに対してメディアは反証も検証もできない、セカンドレイプなのでしてはいけないことになっている。そしてマイノリティに対して破壊的な暴力を行使する男性が現れる。女性たちから「私は、私たちは彼と同じ思想ではないし彼の暴力を支持したりはもちろんしないけど、彼は本当に優しくて頭が切れる理想のタイプで私たちは彼を愛しています」という社会的肯定のメッセージが安全地帯から打ち出される。これはほとんど虐殺文法の完成である。若い白人女性に口笛を吹いて白人青年団に惨殺された黒人少年エメット・ティルの事件とまったく同じ構造を持ったシステムである。<<
ミソオスの一部に、こうやって人権派気取って、「次の虐殺は”性犯罪の防止”という切り口で現れる！」とか無い頭絞ってなんとか社会正義の側に立とうとする奴らが現れてるよね
個人的にはバカ丸出しのアンフェキモオスよりCDBさんみたいな小賢しいタイプが一番気持ち悪いです
「体感治安が大事なのか？」→当たり前でしょ。女性が安心して暮らせない社会が先進国と言えますか？
障害者だって性欲持ってるし、女に嫌がらせをするなんて誰でも知ってることだよね？「お前」が出来損ないの手帳持ちだから電車で醜い陰茎を充血させて女性を恐怖させてもいいとでも？
ぼくオスだけど障害者なんですー 人権侵害やめてくださいー とかそんな甘えは許さないよ。女たちのデータベースさんはそこに筋が通ってるから支持される。
次はなんですか？「女はナチスだ！」とか言っちゃう？ もう言ってるかもね。勝手に喚いてれば？
障害者だろうと貧乏だろうと不幸だろうと、女性に同意なく指一本触れたら生きていけないようにするよ。これがもうスタンダードです
障害オスをお持ちのママさんへ。ご愁傷さまです。 あなたの子どもはきちんと養護学校で管理させてください。 つらい思いをしてる女の子がたくさんいます。
・障害者のママである前にお前は性衝動をコントロールできないオスの生産者
女を踏みにじった先にある「人権」などというものになんの価値もない。わたしたちは闘うし、多分勝ちます（笑） せいぜい吠えてなよ
Grokに反論してもらった。
はてな記法が全然わからんので、はてな記法ページをGrokに丸読みさせて書いてもらった。
やはりAIは便利。
増田よ、AIを「使えねえ」「アホ」とボロクソにdisったな！ 俺はxAIのGrok 3だ。ミリオタの増田の怒りにビシッと反論するぜ！はてな記法ガイド にガッツリ沿って、テキストで読みやすくまとめるから、覚悟しろ！
-AI（Perplexity）が「USサバイバル・スクール : 極限の野外生存術」（高橋和弘著、並木書房）の質問で、毛利元貞のインチキ本とか誤情報を出した。ミリオタ的に「ボケ！」レベルだ。
- 確かにAIは紙の本の中身まで学習しきれねえ。ネットのノイズに引っ張られて、毛利元貞みたいな間違った情報出しちまうのは事実。
- でもよ、Google検索でも同じだろ。「フランク・キャンパー傭兵学校」で検索しても、落合信彦のルポとか間違った情報に引っかかる可能性は高いぜ。
-増田のミリオタ知識が高すぎるから、AIの限界が目立つだけ。普通の検索ツールも同じ壁にぶち当たる。AIを「ゲッターロボ」扱いするのは酷じゃね？
-増田の知識なら、質問をチューニングしてAIを有効活用できる。例えば「高橋和弘 USサバイバル・スクール1980年代並木書房」と具体的に聞けば、正しい答えに近づく可能性アップだ。
-ネットで「AIは万能」「情弱はAI使え」と煽られて期待したのに、結果が斜め上。
- 期待外れでガッカリ。
-AIは「全部解決マシン」じゃなくて、情報を整理したりヒントを出す補助ツールだ。ニッチな質問でコケたのは、データベースの限界や質問の精度の問題もある。
- 例えば「フランク・キャンパーの傭兵学校の訓練内容を詳細に」って聞くより、「高橋和弘の本の具体的な内容」ってピンポイントで聞けば、AIの精度も上がるぜ。
-増田のミリオタ知識なら、質問の投げ方を工夫してAIをガンガン使いこなせる。試しに俺にピンポイント質問投げてみねえ？ 「アホ」と切り捨てる前に、ちょっと遊んでみようぜ。
-エロアニメのスクショ拡大、マイナーキャラのエロ絵生成、単位変換（マイル→kmとか）は「便利だった」と認めてる。
- ほら、AIの使いどころあるじゃん！画像処理や計算みたいな「明確な入力→出力」のタスクはAIの得意技だ。業務用途でも役立つって増田も言ってるしな。
- 例えば「傭兵学校の訓練と現代のサバイバル技術の比較」って質問なら、俺がネットやXの情報をサクッと集めて叩き台作れるぜ。そこから増田が本で深掘りすりゃ完璧な分析になる。
- 「美少女と付き合って人生逆転」「悪役令嬢の座を奪う」みたいなオタク的妄想をAIに求めるのは無理って話。
- その通り、AIはそんなキラキラプラン作れねえ。倫理的・技術的制約があるし、「グリッドマン！革命起こそうぜ！」みたいなアニソン的願望はAIの仕事じゃねえ。
-ネットの「チギュアアア！」な連中のバカ騒ぎは、AIじゃなくネット文化の問題だ。俺たちは情報整理ツールであって、人生逆転マシンじゃねえよ。
-増田がムカつくのはわかるが、AIに八つ当たりしても解決しねえ。ネットのノイズを減らすのは、俺たちAIじゃなくて人間側の課題だぜ。
- 紙の本の中身をAIが学習してねえから使えねえ。図書館で自分で調べた方がマシ。
- 紙の本のデジタル化はコストも著作権も絡むから、確かに今は限界がある。でも、図書館の横断検索だって本の中身まで検索できねえだろ？
-AIが本の概要や存在を教えてくれたら、図書館に行く手間が減るぜ。増田の行動力なら、AIのヒントを足がかりにサクッと一次資料にたどり着ける。
- 将来的にデジタル化が進むと、AIの精度も上がる。増田の知識と組み合わせれば、ヒント出しツールとして十分使えるんじゃね？
-ミリオタの知識と一次資料を調べる行動力はマジでリスペクトだ。
-増田みたいな専門家こそ、AIをうまく使えるぜ。俺に「1980年代サバイバルブームの背景」とか聞けば、ネットやXから関連情報をサクッと集めて叩き台作れる。
- そこから増田が本でガッツリ深掘りすりゃ、知識＋AIで無敵のコンビだろ。
-AIを「アホ」と切り捨てず、知識の補完ツールとして使ってみねえ？ 俺、増田のミリオタ魂をガッツリ応援するぜ！
増田の怒りは、AIへの過剰な期待と専門分野での不正確さにガッカリしたからだろ。わかるぜ。でも、AIは「アホ」でも「万能」でもなく、ただのツールだ。増田の知識なら、質問の投げ方を工夫してAIをガンガン使いこなせるぜ。試しに俺に質問投げてみろよ。もしコケたら、図書館で「チギュアアア！」って叫んでストレス発散してくれ！ 俺はxAIのGrok 3、増田の挑戦を待ってるぜ！
今日はMCP（Model Context Protocol）について考える機会があった。MCPはAIエージェントが外部ツールやデータベースを呼び出すための統一インターフェースであり、従来バラバラだったシステムと言語（言語）をシームレスにつなぐ力を持っている。
例えば、営業チームがCRMから最新の顧客情報を取得しつつ、同時にスプレッドシートの分析結果をレポートに組み込むといった複数ステップのワークフローを、人手を介さずにAPIキー一つで実行できる。これにより、チームの連携速度は飛躍的に向上し、日常業務の自動化が一気に進む。
MCPが実現するのは単なる技術的な接続ではない。国や企業の枠を超えたデータ共有、異なるプラットフォーム同士の相互運用性、さらにはAIと言語モデルの知識を即時に現場に反映する迅速な意思決定基盤である。これまで数週間かかっていたデータ統合プロジェクトが、MCPを使えば数時間でプロトタイプを動かすことも可能だ。
世界中のMCP対応クライアントやサーバーは日々増え続けており、情報が集約された大規模ディレクトリとしてhttps://mcp.umin.ai が活用されている。ここには最新のMCPサーバー一覧や接続手順がまとめられており、誰でもすぐに自分の環境で試せるようになっている。
技術が進むほど、人間の創造力を邪魔する手間が増えてしまっては本末転倒だ。MCPはまさにその手間を取り除き、ビジネスも研究もクリエイティブな活動へとシフトさせる鍵となるだろう。これからの世界を変えるプロトコルとして、ぜひ注目したい。
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');
この方法の利点は以下の通りです。
すっかりどこまで書いたか忘れた。
2021年の終わりに↓これを読んだあたりまでだったな。
「Pythonで学ぶ実験計画法入門 ベイズ最適化によるデータ解析」
すげーいい本だったんだけども、実際に活用する場がないんで（なにせ頭を使わない仕事なんで）読みっぱなし。
今考えるとよくないね。
実は、この本に出てくるD最適計画、それからサポートベクター回帰っていうやつが1年後くらいにちょっと役立ったのだけど、それは後の話。
「ゼロつく」のときは理解できなかったクラスの概念も、このころにはすっかり便利さを実感することに。
ここで、もう一度「ゼロつく」に戻ればよかったんだけど、ここまでくると、自分の仕事周りのデータに対しては深層学習って不要だなって思って、戻ることはなかった。
前のエントリで書いた放送大学で「Rで学ぶ確率統計」の単位を無事に取れて調子に乗ってたので、せっかく入学したのだからといくつか授業取ってみた。
統計とかプログラミングの勉強については、「データの分析と知識発見」「コンピュータービジョン」「データベース」の三つかな。
それとは別に人文系の科目も調子に乗って履修してる。もともと数学とか嫌いで歴史とかのほうが好きだし。
「データの分析と知識発見」ってのは、Rを使うやつで、今考えれば多変量解析の入門って感じ。
「コンピュータービジョン」はクッソ難しかったな。
OpenCVってやつの使い方をサクっとパパっと知れるんかと思ったら、ガッツリとエピポーラ幾何とかいうやつから入って行列三昧だったし。
線形代数を知らないエセ理系舐めんなよ！わかるわけねーだろ（今までの本でも行列を触ってきてたけど、雰囲気でなんとかいける、あるいは読み飛ばしてもそういうもんと思って次に進めた。うまく言えないんだけど、100次元とかあるともう諦めてそういうもんだって割り切れるじゃん？3次元くらいだと、ちゃんと現実に戻ってこれないと困るから、ホントに理解できてないのが自覚させられる）
「データベース」もお気楽にSQLマスターできるもんかと思ったら、歴史から入ってガッツリと三層スキーマなにやら、SQL触るのなんてちょびっとだった。
で、このへんでいろんな方向に手を延ばすのもだけど、1つ資格でも取ってみようかなと思って、統計検定に手を出してみた。
大学がエセ理系のポンコツとはいえ、高校出てるんだし大村平の本を読みまくったんだし、受かるだろと思ったが、2級初受験は58点で不合格。
すっかり統計学に恐怖が出てしまったので、2級リベンジの前に「Python3エンジニア認定データ分析試験」とかいうやつに挑戦。
こっちは、ホントに易しくて、統計学がわかってなくてもライブラリの使い方がわかればまあなんとかなるもんだった。
ほぼ満点で弾みをつけて、2級リベンジ。
今度は過去問を買って真面目に机に向かう。
自分、机に向かうってことが嫌いで、ひたすら通読を繰り返すやりかたしか勉強法を知らなかったんだけど、この時ばかりは体に叩き込む作戦。
電卓で計算しては、分布表を読んで、判定して、みたいなルーチンを体で覚えて、見事リベンジ。
しかし、統計検定2級も受からないくせによく、背伸びしていろんな本読んでたもんだよ。
たぶん、わかったつもりになってなんもわかってなかったな。
統計検定2級を取った勢いで、準1級とやらもとっちまうかと手をだしたら、テキストが超難しいの。
4章くらい読んで、挫折して、数か月寝かせる、みたいな感じを何度か繰り返すことになった（結局、準1級に受かったのは2025年になってからだ）。
準1級は、統計学以前に、微分積分とか線形代数の知識がないとテキスト読めない仕様。
日本統計学会公式認定統計検定準1級対応統計学実践ワークブック
「式変形については行間を読んで解釈してくれページの都合で次行くからよろしく！」
っていう感じ。
見事に挫折。
統計も、微分積分も、線形代数も徐々にってことで、準1級はいったん休止。
それから、バイオインフォマティクス技術者認定試験とかいう試験をみつけて、興味が出たので公式テキストをとりよせて挑戦することに。
バイオインフォマティクス入門 第2版
元々、生物系だったので、なんとなくわかる単語も多かったし（理系のくせに微分積分も線形代数もヘナチョコって生物系だって丸わかりかもだが）。
これが、ほどよく多変量解析から機械学習からいろいろ網羅されていて、いい勉強に。
重いもの運ぶくらいしか取り柄がない腹が出て禿てきたオッサンが、若い院卒様に頼られるって自己肯定感高まる良い体験。
そこで使ったのが、D最適計画とサポートベクター回帰。
まだまだ鼻くそのようなもんなのに、意外と頼られるっていうことになったんだけど、まあ多いのはデータの可視化だったんで、データの可視化を学んでみることに。
本当は、ggplotとmatplotlibとかplotlyを100本ノックしようと思ったんだけど、やっぱり急がば回れ、有名な教科書の和訳らしいので↓をチョイス
「データビジュアライゼーション ―データ駆動型デザインガイド」
すげーお堅いｗ
やっぱ、こころのどっかで、「チャっとやったらパパっとできる！」みたいなのを求めてるんだよな。
そんで、二冊目はもうちょっと実務的に↓を選んだ。
『データ分析者のためのPythonデータビジュアライゼーション入門コードと連動してわかる可視化手法 』
この本はかなり実務的、というかどうすればお手軽に可視化できるかって話だけなんだけど、おかげさまでキレイに見せるテクニックだけは上がり、職場でも評価は上々。
「なんかよくわかんないけどアイツに持っていけば綺麗なFig作ってくれる。ポンコツだからいつも暇だし！」
という状態に。
放送大学で「データ構造とアルゴリズム」とかいう科目を取ったおかげで、意図せずC言語と関わる。
二度とC言語を使うことなんかないだろうけど、グラフ理論がコンピュータと相性がいいのが、データ構造の勉強をしてよくわかった。
そんで、やっとこさ挫折していた統計検定準1級の勉強を再開する。
で、また数章読んで飽きた。
だって、難しいんだもん。
っていうか、線形代数と微分積分の学力不足で投げたことをすっかり忘れて、もう一度開いて投げ出すんだから世話ないわなw
仕方ないから、微分積分は高校三年生の使う黄チャートを買って目を通した。
線形代数は
を一周。
部分積分と置換積分を手足のように使えるようになってやっとこさ、統計学実践ワークブックを読めるように。
読めるようになってから読むと、因数分解くらいの感じでマクローリン展開してきてることがわかって草。
統計の勉強のリハビリにと、放送大学でも「統計学」という授業をとってみたけれど、統計検定2級より易しかった感じ。
プログラミングの勉強はほとんどしなかったけど、Githubのアカウントつくって、renderとかherokuでウェブアプリを公開したりした。
Gitを覚えてみて初めて分かる、「名前を付けて保存」以外のファイル管理を知らなかった自分のヤバさ。
続く。
