  |
はてなキーワード:クエリとは
と質問とした所、
いい質問。ただ、**今回私が提示したC#コード（MemoryMappedFile + Parallel.For でCR を数える）**には、明確に一つの「このネット上の記事／リポジトリをそのままコピーした」元ネタはありません。
いくつか似たアイデアを使ってる部分と参考になる記事／ドキュメントはあるので、それらを紹介します：
---
*Microsoftドキュメント — Memory-Mapped Files (.NET)*
([Microsoft Learn][1])
*Kieren Johnstone: 高速に MemoryMappedFileからバイト列を読む方法（StackOverflow）*
`MemoryMappedViewAccessor` を使って unsafeコードからポインタを取得し、Marshal.Copy で効率よく読み出す方法。
([StackOverflow][2])
*Red-Gate: Sharingis Caring: Using Memory Mapped Files in .NET*
MemoryMappedFile を使ったキャッシングなどの応用。
*Stephen Cleary のブログ: Memory-Mapped Files と Overlaid Structs*
メモリマップトファイルへ構造体を重ねて（オーバーレイ）扱う方法など。
([blog.stephencleary.com][4])
---
もしよければ、**あなたのコード（CR を数えるもの）に特化した元ネタをさらに探してみます**。やりましょうか？
[1]:https://learn.microsoft.com/en-us/dotnet/standard/io/memory-mapped-files?utm_source=chatgpt.com "Memory-Mapped Files - .NET"
[2]:https://stackoverflow.com/questions/7956167/how-can-i-quickly-read-bytes-from-a-memory-mapped-file-in-net?utm_source=chatgpt.com "How can I quickly read bytes from a memory mapped file in ..."
[3]:https://www.red-gate.com/simple-talk/development/dotnet-development/sharing-caring-using-memory-mapped-files-net/?utm_source=chatgpt.com "Sharingis Caring: Using Memory Mapped Files in .NET"
[4]:https://blog.stephencleary.com/2023/09/memory-mapped-files-overlaid-structs.html?utm_source=chatgpt.com "Memory-Mapped Files and Overlaid Structs"
ChatGPT:
が、出てきて、やってくれと言ったら、こういうのが出てきた。
了解しました — 広く（英語・日本語・GitHub・ブログ・StackOverflow 等）再検索しました。結論と見つかった“近い”ソースをまとめます。
結論（要点）**
「あなたが求めている**MemoryMappedFile を使い、UTF-8バイナリ中の `CR`（0x0D）だけを数える・マルチスレッドで分割して処理する**」という **完全一致の“元ネタ”ソースコード**は、公開されたweb 上のリポジトリや記事の中では見つかりませんでした（複数の検索ワード／検索対象で確認）。([hyr.mn][1])
ただし、ほぼ同種の要素（メモリマップドファイルの読み方・大きなファイルの行数カウント・バイト単位カウントを高速化する手法）は複数見つかりました。これらを組み合わせれば、先に示した実装は典型的なパターンであることが確認できます。([Microsoft Learn][2])
見つかった“近い”・参考になりそうなソース（抜粋）**
1. .NET の公式ドキュメント（MemoryMappedFile の説明） — `MemoryMappedFile` の基本とCreateViewStream /CreateViewAccessor の使い方。必須の参照。([Microsoft Learn][2])
2. 「Countinglines withC#」というブログ記事（C# で改行（CR/LF）カウントに関する実装とGitHubリンク） — 行数カウントを目的とした実装パターンがある。([hyr.mn][1])
3. StackOverflow：MemoryMappedFileから高速にバイトを読む方法（`MemoryMappedViewAccessor` / unsafeポインタ / Marshal.Copy 等の議論） — 高速実装のヒント。([StackOverflow][3])
4. StackOverflow／Q&A：ファイル中のLF/CR の数を求める方法に関するスレッド（`grep -c $'\r'` 等のunix 例やC# でのカウント方法の議論）。([StackOverflow][4])
5.GitHub のサンプルリポジトリ（MemoryMappedFile のテスト／サンプル） —メモリマップドファイルを使う実装例。([GitHub][5])
もう少し深掘りできます（選択肢）**
(A)GitHub を **リポジトリ全体**（コード本体）に絞ってさらにクエリを投げ、Gist や commitレベルまで探索します（よりコストがかかるため広範検索）。
(B)ブログ・技術記事を対象に **全文一致（コード断片）検索** を行い、私が先に示したC#コードの実際の一節（たとえば `mmf.CreateViewStream(offset, size)` や `Interlocked.Add(ref totalCount, localCount)` など）を直接検索して完全一致を探します。
(C) 「オリジナルはGitHub にあるはず」と思われるなら、あなたが覚えている**リポジトリ名の断片／作者名／投稿日**などを教えていただければ、それを手がかりに探します（断片情報があるとヒット率がぐっと上がります）。
どれを優先して探しましょうか？（A:GitHub全探査 / B:コード断片で全文検索 / C:あなたからヒント提供）
※続けて深掘りする場合は、すぐにさらに広い検索を行って該当ソースを探します（そのまま実行します）。
[1]:https://hyr.mn/catching-flowers-with-a-net?utm_source=chatgpt.com "Countinglines withC# - hyr.mn"
[2]:https://learn.microsoft.com/en-us/dotnet/standard/io/memory-mapped-files?utm_source=chatgpt.com "Memory-Mapped Files - .NET"
[3]:https://stackoverflow.com/questions/7956167/how-can-i-quickly-read-bytes-from-a-memory-mapped-file-in-net?utm_source=chatgpt.com "How can I quickly read bytes from a memory mapped file in ..."
[4]:https://stackoverflow.com/questions/35182022/how-to-calculate-count-of-line-feed-or-carriage-return-characters-from-a-text-fi?utm_source=chatgpt.com "How to calculate count ofline feed or carriage return ..."
[5]:https://github.com/byGeek/MemoryMappedFileTest?utm_source=chatgpt.com "test csharp code for using memory mapped file."
けれど、結果は逆だった。
AIサービス各社は、燃えるような電気代とサーバーコストに追われた。
はじめは月額30ドルだった定額料金が、いつのまにか300ドルになり、
人々は「AIに話しかける」前に、まず財布の残高を気にするようになった。
内容欄には「生成目的」「想定トークン数」「倫理リスク」が並ぶ。
誰もそんな書類を出したがらず、やがて誰もAIを使わなくなった。
そう目算した中国企業は、
良い出力を引き当てるまで課金を繰り返した。
パソコン通信と同じように「昔は便利だった」と懐かしんでいた。
だが、若者たちは違った。
「AI？ あー、あのジジババが使ってたやつね」
誰もが使っていたものが、誰も使わなくなった。
ただ一つだけ違うのは──
誰ももう、「AIのように考える人間」を信用しなくなったということだ。
#SF #ディストピア #生成AI #未来予想 #はてな匿名ダイアリー
──
エクセル開くのに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
