  |
はてなキーワード:ディレクトリとは
ネット通販の無かった頃、マイナーなマンガの単行本の新刊を買うためにあちこちの本屋を一日中探し回ったり、技術書を買いに駅前の大きな本屋まで行ったが売っていなくて結局近く本屋で取り寄せてもらったりしたものだった
最近は縫物をする人がめっきり減った、つまり縫物をすることが普通のことでなくなったので、縫物の糸やら生地やらが手に入りにくくなり、自分で凧を作る人もいないからタコ糸も手に入らない
世間様はホットケーキをホットケーキミックスで作るからスーパーでベーキングパウダーが売っていない
ホームベーカリーが世に出て相当経つとはいえ、それほど自宅でパンを作るのが普及してるとは信じがたい
みんな、果物ジュースを買ってきて「発酵の実験」でもしてるんじゃなかろうか？
あと、PCをWindows11のやつに乗り換えたので、ホームディレクトリの名前を今まで使っていたものに変更するべく色々やってみたが、諦めた
Linuxを始めるには、まずはLinuxを体験してみて、それから基本的な操作を学ぶという2つのステップで進めるのがおすすめです。インストールにはいくつかの選択肢があり、初心者向けに作られたディストリビューションから始めるとスムーズです。
現在のPC環境を変えずにLinuxを試す方法は複数あります。
仮想マシンを使う:VirtualBoxやVMwareなどの仮想化ソフトウェアを使えば、WindowsやmacOS上でLinuxを動かすことができます。これは、現在の環境に影響を与えずにLinuxを試せる最も安全な方法です。
ライブUSBで起動する:Linuxのインストールイメージ（ISOファイル）をUSBメモリに書き込むと、「ライブ環境」としてPCを起動できます。この場合も、PCのストレージには何も変更が加えられません。
WSL (Windows Subsystem forLinux):Windows 10/11を使用している場合、WSLを使えばWindows内にLinuxの実行環境を構築できます。
ステップ2：初心者向けディストリビューションを選ぶ
Linuxにはさまざまな種類（ディストリビューション）があり、それぞれ特徴が異なります。初心者は以下の使いやすいものから始めるのがよいでしょう。
Ubuntu: 最も有名で、初心者向けのLinuxとして定番です。ユーザー数も多く、ネット上に情報が豊富にあります。
Linux Mint:Ubuntuをベースに、よりWindowsライクな操作感を目指して開発されたディストリビューションです。直感的な操作が可能なため、Windowsユーザーから乗り換える場合に適しています。
ZorinOS:WindowsやmacOSから移行するユーザー向けに、デザインや操作性を最適化したディストリビューションです。
ISOファイルをダウンロード: 選んだディストリビューションの公式サイトから、ISOファイルをダウンロードします。
ブータブルUSBを作成:Rufus（Windows）やBalenaEtcher（クロスプラットフォーム）といったツールを使い、USBメモリにISOファイルを書き込みます。
PCを再起動:作成したブータブルUSBからPCを起動し、インストールを開始します。
デュアルブート:Windowsなどの既存のOSと共存させる方法です。起動時にOSを選択できますが、少し複雑な作業になります。
単独インストール:PCのストレージをすべてLinuxで使用する方法です。
仮想マシンにインストール:ステップ1で試した仮想マシンに本格的にインストールします。
Linuxの真価を発揮するのは、コマンドライン操作です。ターミナルを開いて、以下の基本的なコマンドを試してみましょう。
オンライン学習サイト:Linux Foundationの無料コースやLinuxJourneyなど、無料で学べるオンラインリソースが多数あります。
書籍:初心者向けの入門書は、体系的に学習するのに役立ちます。
コミュニティ:Redditのr/linux4noobsや地域のLinuxユーザーグループに参加して、質問や情報交換をするのも効果的です。
確かに使ってた。使ってはいるけど解凍を使ってるのは自己解凍のところだけで、e,xオプションのところでは「ファイルを取り出す」表記。凍結表記もaオプションのところだけ。
(LHAになる前のバージョンだけど)LHarcソースコード内の日本語版の使い方
char use[] =
"LHarcversion 1.13cCopyright(c) H.Yoshizaki（吉崎栄泰）, 1988-89.\n"
"============================================================= 1989 - 5 - 21 ===\n"
" <<< 高圧縮書庫管理プログラム>>>\n"
"===============================================================================\n"
"使用法：LHarc [<命令>] [{/|-}{<スイッチ>[-|+|2|<オプション>]}...] <書庫名>\n"
" [<ドライブ名>:|<基準ディレクトリ名>\\] [<パス名> ...]\n"
"-------------------------------------------------------------------------------\n"
" 《命令》\n"
" a:書庫にファイルを追加 u:書庫にファイルを追加（日時照合付）\n"
" f:書庫のファイルを更新 m:書庫にファイルを移動（日時照合付）\n"
" d:書庫内のファイルの削除 e,x:書庫からファイルを取り出す\n"
" p:書庫内のファイルの閲覧 l,v:書庫の一覧表示\n"
" s:自己解凍書庫の作成 t:書庫内のファイルのCRC チェック\n"
" 《スイッチ》\n"
" r:再帰的収集を行う w: ワークディレクトリの指定\n"
" x:ディレクトリ名を有効にする m: 問い合わせを行わない\n"
" p:名前の比較を厳密に行う c: 日時照合を行わない\n"
" a: 全属性を凍結の対象とする v: 他のユーティリティでファイルを閲覧\n"
" n: 経過表示をしない k:自動実行のキーワードの設定\n"
"===============================================================================\n"
"転載・再配布などは自由です。Nifty-Serve PFF00253\n"
英語版の使い方
char use[] =
"LHarcversion 1.13cCopyright (c) Haruyasu Yoshizaki, 1988-89.\n"
"================================================================ 05/21/89 ===\n"
" <<< High-Performance File-Compression Program>>>\n"
"===============================================================================\n"
"usage:LHarc [<command>] [{{/|-}{<switch>[-|+|2|<option>]}}...] <archive_name>\n"
" [{<drive_name>:}|{<home_directory_name>\\}] [<path_name> ...]\n"
"-------------------------------------------------------------------------------\n"
" a:Add files to archive u: Update files to archive\n"
" f: Freshen files in archive m:Move new files into archive\n"
" d:Delete files from archive e,x: EXtract files from archive\n"
" p: disPlay files in archive l,v:View List of files in archive\n"
" s:make a Self-extracting archive t:Test integrity of archive\n"
" r: Recursively collect files w: assign Work directory\n"
" x: allow eXtended file names m: noMessage for query\n"
" p: distinguish fullPath names c:skiptime-stamp Check\n"
" a: allowany Attributes of files v:View filesbyanother utility\n"
" n: display No indicator k:Keyword for AUTOLARC.BAT\n"
" t: archive'sTime-stamp option\n"
"===============================================================================\n"
"Youmay copy or distribute withoutany donation to me.Nifty-Serve PFF00253\n"
" (See theUser'sManual for detailed descriptions.)ASCII-pcspcs02846";
AIの発達によってSEOが価値を落としているのでこれからはディレクトリ型の検索エンジンが再登場するんじゃないかと言われているので、それなら作ろうかなと思ってAIに聞いてみたら日本では違法になる可能性があり、特に手動登録の検索エンジンは人間が意図的に登録しているので違法となる可能性が高いそうだ。
一方botならひとつひとつ人間がチェックすることは不可能なので仮に訴えられてもうっかりミス程度の扱いになるとも言われた。
これは本当なんだろうか。
リンク集が違法とされた話は聞いたことないんだけどディレクトリ型の検索エンジンとディレクトリ型の巨大リンク集は何が違うんだろうか。
今日は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
しーかーしー。
そこでなぜディレクトリ構成とかいう、枝葉末節から話が始まるか理解できん。
というか、そういう具象しか理解できない頭しか持ち合わせてないのか？
中身を理解しないで、表面的HowToだけなぞったところで、手間が増えるだけ、不具合が増えるだけの、典型的炎上系カーゴカルトの教祖にしかなれんぞ。
で、そういうクズを作っておきながら、手に負えなくなったら「××社でアーキテクトをして云々」って転職して逃げ出すんだからなぁ……。
てめぇのケツくらい拭けねぇのかよ？
なんかあの同心円図を神聖なものみたいに崇めてるっぽいのを見ると、本当に哀れに思える。
あんなもん、書籍を出すときに見た目を整えるためにでっち上げた図以外の何物でもねーだろ w
よくある4象限とかのマトリクス図とか、意識高い系の本には大量に載ってるあれだよ。
そういう意味のない図に「雰囲気で当てはめる」から、そこで真に求められていることが実現できないんだよ。
クリーンアーキテクチャ採用していて、がっつりしたE2Eテストを予定している時点で矛盾だって理解しろ。
ただなぁ、こういう技術()話するのが好きなエンジニアは多い。
呆れるほど多い。
多いんだが、残念すぎることに内容が、
「知ってるか？東京都立呪術高等専門学校って奥多摩にあるんだぜ」
「生徒に知り合いがいる」
今時の厨二だってそんなアホみたいな話してマウント取り合いなんてしねぇぞ……。
そんな集団に「ただの漫画の創作だぞ」って言い放つより、静かに距離を置くことを選ぶよ。
プロンプトどうでもいい論を唱える奴がマジで理解できないんだよな
誰かが用意した物をコピペしてくるか、バイアスに従ったスタンダード出力しか必要としてないなら確かに考える事はほぼないのは分かる
ていうかそもそも「プロンプト」なんてCLIコマンドと一緒、と言い切るにはランダム性があるんで意味は共通だとしか言えないが
「ディレクトリ内のファイル一覧が欲しい」のか「サブディレクトリ一覧が欲しい」のかでコマンドが変わるように
結局ユーザーの望む出力を促すためのもんでしかないんだから「必要な出力を引き出すための手段」くらいの認識でいいってのに
プロンプトエンジニアリングという言葉を推進派とは逆ベクトルに大袈裟なもんだと考えてる傾向にあるんだよな、忌避してる奴は
簡単な例で行くと「テトリス作って」「Javascriptでテトリス作って」「C#でテトリス作って」全部得られるもんは違うわけだ
んでもって更に要件があるなら、それは指示に組み込まないとAIに伝わりようがない
「これ調べて」「これ調べて箇条書きで整理して」「調べて解説しつつブラックジョークを言って」これも全部成果が違うだろ
AIによっては日本語や特定の和製英語、独自の業界用語が理解できないものすらあるよな
じゃけん適切に指示を出しましょうねと
そういうもんでしかないものがどうでもいいも不要になるもあるかと
推論モデルであっても、勝手にCoT始めるからといって要件無しじゃAIの獲得した一般常識に従って動くだけだぞ
どこまで言ってもそれが仕様だ
まぁメモリーに色々埋め込んでおけば、言葉少なでも期待通り動いてくれるかもしれんが
イケイケなエンジニアがだいたいMacbookとイケイケコーヒーかイケイケ社内カフェのイケイケ無料ドリンクを手に社内の色んな場所を巡りつつ
つべとかで見れる。
ならない。なるわけがない、どうでもいい
VSCodeのルートディレクトリに配置されてるからおそらく実コードだと思うんだが、鼻で笑ってしまったのね。JSかよと
割愛するけどこれだけで最高に間抜けで、オブラートに包むと性格が悪い寄りの人種であることがある程度推測できる。
そこで気がつくんだが、俺はこのイケイケたちを見て羨ましがりながら、粗探しをしていたわけだ。
そうして目的がかなって、嬉しくなった。
ああ、俺はこんなにもダサくなったのか。
元からかもしれないが、そんなことはどうでもいい。
今この瞬間俺はダサい。それが少し悲しくなった。
そうだ。
課題かイシューかソリューションかタスクかわからん、いやなんでもいい。
とにかくそういったものがあればそれを解決するために動く、ないなら作る。
イケてないカフェでイケてないノートPCを広げてイケてないエディタとイケてないターミナルを開いて
今だったら DeepSeekR1 でもええやんな
増田においても、AIやりたい風の増田、AIで遊んでる（噓松）増田の投稿をよく見るけど、
どう考えてもそれ、NSFWフラグ立つでしょ・・・みたいなことを希望してんのよね
昔からAI画像生成とかで遊んでる増田が、彼／彼女らをフォローする風でもないので、
- WindowsOS のアプリ分離とコア分離を説明（超ざっくりで良い。コンテナー技術の基本原理とセキュリティ周りの設定やトラブル対応のベースを作る）
- コンテナ技術の基礎について説明（ざっくりで良い）
- LLMを目的別に説明
- PCに作業用のディレクトリを作成し、モデルをダウンロード、保存まで説明
- DockerDesktopをインストール、Dockerイメージの構築～Dockerコンテナの実行まで説明
需要あると思うで
詳しいなら、謎レスバしとらんで、
レガシーなWindowsOS の安定性の概念でWindowsOS を語ったり、
レガシーなWindowsOS でよくあったトラブルを懸念してチャレンジしない、
おっさんおばさんおじいさんおばあさんがいるから、WindowsOS のアプリ分離 と コア分離 を説明したげてよ
増田においても、AIやりたい風の増田、AIで遊んでる（噓松）増田の投稿をよく見るけど、
どう考えてもそれ、NSFWフラグ立つでしょ・・・みたいなことを希望してんのよね
昔からAI画像生成とかで遊んでる増田が、彼／彼女らをフォローする風でもないので、
需要あると思うで
同じコードを数年前にExcelVBAでしこしこ作ってたのがなつかしい
functionZip-Subfolders { param( [string]$directory ) #指定されたディレクトリ内のサブフォルダを取得 $subfolders = [System.IO.Directory]::GetDirectories($directory) | % { [System.IO.DirectoryInfo]::new($_) } foreach ($folder in $subfolders) { #圧縮ファイルの保存先パス $zipFilename = "$($folder.Name).zip" $zipFilepath =Join-Path -Path $directory -ChildPath $zipFilename # サブフォルダをZIP圧縮Write-Host "圧縮中..." [System.IO.Compression.ZipFile]::CreateFromDirectory($folder.FullName, $zipFilepath)Write-Host "$zipFilepath に圧縮しました。" }}#ユーザーにフォルダパスを入力させる$folderPath = Read-Host "圧縮する親フォルダのパスを入力してください"#パスが存在するか確認if ([System.IO.Directory]::Exists($folderPath)) {Zip-Subfolders -directory $folderPath}
