２つの記事に分かれていて、1つ目の記事は非開発者向けの記事。２つ目の記事は開発者向けのフォローアップ的な記事。もしあなたが開発者なら私とは異なる選択をするかもしれない。そのときはどのような取捨選択をするかを教えてほしい気持ちがある。
そして解説記事の価値について考えてみる気にもなった。後に出てくる公式サイトへの固執のことを考えてみると、実際に動作するという疎通確認こそが価値であるという結論になった。この記事もこれが動く間は価値があるし。動かなくなったら価値がなくなりQandAボットは確認しないので価値がない。そして公式サイトは利用者が多いのでメンテナンスされてる可能性が高い。
（以下は生成された文章。しかし試行錯誤が怠く1から自分で書いたほうが早かったのではとも思った。リンクを振った瞬間に親切になるが確認の手間が倍増する。ai君は小部屋という比喩に固執してた）
article1.md #Windowsだけで生活している方が、AIを使うときだけWSLを起動し、安全に対話・試行錯誤させるための手順書です。Linuxコマンドは cd / ls / pwd 程度が分かれば進められます。
※ 本手順は Windows 11（バージョン 22H2 以降） を対象としています。
---
Windows環境に直接AIツールをインストールすると、システムの重要なファイルや設定にアクセスできる可能性があり、意図しない変更やセキュリティリスクが生じることがあります。特に、AIが外部との通信を行う場合、個人情報や機密データが漏洩するリスクも考慮する必要があります。本手順では、WSL（Windows Subsystem for Linux）を利用して、AIの実行環境をWindows本体から分離し、より安全に利用する方法を説明します。
Windows側のシステムや設定を触らせないための「別の環境（Ubuntu）」を用意します。
1. スタートメニューを右クリックし、「ターミナル（管理者）」または「PowerShell（管理者）」を開きます。 2. 以下を実行します（公式手順：WSL のインストール）。
wsl --install3. 処理が終わったら、一度Windowsを再起動します。 4. 再起動後、もう一度PowerShellを開き、WSLを更新します（WSL の基本コマンド）。
wsl --update
wsl --versionwsl --install を実行しただけでは、Ubuntuがまだ入っていない場合があります。以下の手順でUbuntuを明示的にインストールします。
1. PowerShellを開き、インストール可能なディストリビューションの一覧を確認します（WSL の基本コマンド）。
wsl --list --onlineUbuntu または Ubuntu-24.04 などが一覧に表示されることを確認します。2. Ubuntuをインストールします。
wsl --install -d Ubuntuwsl --install でUbuntuが導入済みの場合は「指定されたディストリビューションは既にインストールされています」と表示されます。その場合はこのステップを飛ばして構いません。3. インストールが完了したら、Ubuntuが正しく登録されたか確認します。
wsl --list --verboseUbuntu が表示され、STATEが Stopped または Running、VERSIONが 2 になっていれば成功です。Microsoft Storeからのインストールについて: 上記のコマンドが何らかの理由で失敗する場合は、Microsoft Storeで「Ubuntu」を検索してインストールすることもできます。ただし、コマンドでの導入のほうがWSLとの整合性が取りやすく、非開発者でも手順を再現しやすいため、本手順ではコマンドを推奨しています。
再起動後、もう一度PowerShellを開き、WSLを最新版に更新します。
wsl --update
wsl --version1. スタートメニューから Ubuntu を起動するか、PowerShellで以下を実行します。
wsl -d Ubuntu2. 初回起動時のみ、Unixユーザー名とパスワードの設定を求められます。
user）を入力します。3. 設定が完了すると、Ubuntuのシェル（$ または # プロンプト）が表示されます。
WSL内で動かしたWebサイトをWindowsのブラウザから直接開けるようにします。
1. スタートメニューの検索欄に WSL Settings（または「Linux 用 Windows サブシステム設定」）と入力してアプリを開きます。
2. 左側の 「ネットワーク」 タブを開き、「ネットワーク モード」 を 「Mirrored」 に変更します（networkingMode=mirrored の公式説明）。
3. 設定は自動保存されるので、そのままウィンドウを閉じます。
PowerShell標準の黒い画面では、Ubuntuを動かしたときにTABキーによる文字補完がうまく働かず、タイポが多発します。作業用の専用画面を用意します。
1. スタートメニューから Microsoft Store を開きます。 2. 検索欄に「Windows Terminal」と入力してインストールします（すでに入っていればそのままでOKです）。 3. Windows Terminalを起動し、タブバーの「∨」マークから「設定」を開きます。 4. 「スタートアップ」項目にある「既定のプロファイル」を Ubuntu にして右下の「保存」を押します。
Ubuntuの基本ソフトを更新し、直感的に使えるメモ帳のようなエディタを入れます。
1. Windows TerminalでUbuntuを起動します。 2. まずシステムを最新化します。
sudo apt update && sudo apt upgrade -y3. エディタ（micro）をインストールします。
sudo apt install -y microCtrl + S、終了は Ctrl + Q です。これだけ覚えておけば問題ありません。4. Pythonが入っていることを確認します。
python3 --versionPython 3.x.x と出ればOKです（入っていなければ sudo apt install -y python3）。AIがWindowsのCドライブの中身を勝手に覗いたり、Windowsのプログラムを実行できないように壁を作ります。
1. Ubuntuの画面で、先ほど入れたエディタを使って設定ファイルを開きます。
sudo micro /etc/wsl.conf2. 画面が開いたら、以下の内容をそのまま入力（または貼り付け）します。
[automount]
enabled = false
[interop]
enabled = false
appendWindowsPath = false3. 入力したら、Ctrl + S（保存） を押し、続いて Ctrl + Q（終了） を押してエディタを閉じます。
設定を反映させるため、PowerShellを開いてWSLを完全に停止させます（wsl --shutdown の公式説明）。
wsl --shutdown再びWindows TerminalでUbuntuを開き、壁が機能しているかテストします。 1. WindowsのCドライブが見えないか確認：
ls /mnt/cNo such file or directory などエラーになれば成功です（WindowsのファイルがAIから見えなくなりました）。2. Windowsのコマンドが動かないか確認：
cmd.exeWSL Interoperability is disabled や command not found など、何らかのエラーになれば成功です（AIからWindowsのプログラムを直接操作できなくなりました）。ターミナルの画面内にいくつも窓が開いて迷子になるのを防ぐツールです（GitHub リポジトリ）。Windows Terminalのタブ切り替えだけで十分ならスキップして構いません。
curl -fsSL https://herdr.dev/install.sh | sh
source ~/.bashrcherdr と打っても見つからない場合は、ターミナルを一度閉じて開き直してください。AI作業用のツール「opencode」を導入します（ダウンロードページ / GitHub リポジトリ）。
curl -fsSL https://opencode.ai/install | bash
source ~/.bashrc
opencode --versionホストから隔離された安全な作業用フォルダを作って、そこでAIを立ち上げます。
mkdir -p ~/work
cd ~/work
opencode1. モデルの選択:
画面下部に /models と入力します。利用可能なモデル一覧が表示されるので、その中から 「free」や「無料」と表示されているモデル（DeepSeek系、GLM系、Qwen系など） を選んでください。
※無料で使えるモデル名は時期によって入れ替わるため、その時点で一覧に出ている無料モデルを選べば大丈夫です。
2. 最初の対話（疎通確認）:
モデルを選んだら、そのままの画面でAIに適当な質問を投げてみます。
端末の黒い画面ではなく、普段使い慣れているブラウザからAIとやり取りできるようにします。
Ubuntuのターミナルで以下を実行します（先ほどのopencode画面を Ctrl + C 等で抜けるか、別タブを開いて実行します）。
cd ~/work
opencode pairhttp://localhost:...）をコピーし、Windows側のブラウザ（EdgeやChrome） のアドレスバーに貼り付けて開きます。会話の引き継ぎについて:
opencode pairでブラウザを開いた際、端末側で行っていたさきほどの会話が引き継がれていない場合があります。その場合は、ブラウザ側のチャット欄でもう一度同じ依頼を入力すれば問題ありません。
ブラウザに開いたopencodeのチャット欄を使って、作業を依頼します。
「さきほど説明してくれたGitとGitHubの違いを、見やすいHTMLレポートにしてください。ファイル名は report.html にして、カレントディレクトリに保存してください」
「あなたはいまWSL上のUbuntu（mirroredネットワーク）で動いています。作成した report.html を私がWindowsのブラウザから閲覧できるように、HTTPサーバーをバックグラウンドで起動してください。起動したらアクセス用のURLを教えてください」
http://localhost:8000/report.html を開いてください」といった案内を返してきます。http.server）を使うケースが一般的です。案内されたURLをWindowsのブラウザの新しいタブで開きます。
確認が終わったら、チャット欄で「さきほど立てたHTTPサーバーを停止してください」と伝えて後片付けをさせます。
article2.md #本章は、非開発者向け手順書において採用・不採用とした技術的判断の背景および思想の記録（ADR / 備忘録）です。
vi のモーダル編集（ノーマル/インサート）、保存・終了コマンド（:wq / :q!）は非開発者にとって高すぎる壁であり、説明コストが合わない。micro は直感的なキーボード操作が可能であり、sudo apt install micro だけで素直に入る。ただし、Ctrl + S（保存）や Ctrl + Q（終了）もターミナル操作に不慣れな層は引っかかりやすいため、手順書側での明記を徹底している。conhost と readline の競合問題） #conhost.exe が「cooked mode」の行編集（履歴・TAB補完含む）を担当しており、入力をシェルに渡す前に横取りする。一方、Ubuntuのbash側も readline による補完機能を持っており、この二重の行編集レイヤーが競合することで、bash本来のTAB補完が正しく機能しなくなる（Windows Console と Windows Terminal の関係）。
Windows Terminal は後継の OpenConsole を使用しており、従来の conhost のように行編集を横取りしない。そのため、bashの readline が本来のTAB補完を安定して実行できる。winget コマンドを用いず Microsoft Store を案内したのは、非開発者に黒い画面でのパッケージ管理コマンドを叩かせないためである。opencode pair（Web UI）を主軸に据える構成に倒したことで、ターミナル作業自体が激減したため、必須要件から外し「任意」へ格下げした。opencode を選定した。opencode --web が使用されていたが、V2系において opencode pair サブコマンドへと移行された。ワンタイムリンク（約5分で失効）と30日有効なセッションクッキーによる接続方式を採用している（参照：opencode 公式サイト / GitHub リポジトリ）。opencode pair を立ち上げた際、セッションが自動継続されないケースがある。開発者であれば --continue（-c）や --session <id>（-s）でセッションを明示的に引き継げるが、非開発者にセッションIDの管理を強いるのは煩雑なため、手順書では「Web側で同じ依頼を再度入力する」運用で十分と割り切った。wslsettings.exe）の採用:
WSL 2.3.24以降で同梱された設定GUIを用いることで、非開発者が .wslconfig の構文エラーを起こすリスクを排除した。WSL Settingsは .wslconfig をリアルタイムに直接書き換えるため、競合を防ぐ目的でエディタとの同時編集を禁止事項として案内している。localhostForwarding=true）では、Windows側から localhost は引けても 127.0.0.1 へのバインドで不整合が起きやすく、サーバー起動時に 0.0.0.0 バインドが要求されるなどトラブルの温床になる。networkingMode=mirrored を採用することで、Linux側の 127.0.0.1 バインドがそのままWindowsホストに透過される（公式リファレンス）。localhost サービスもWSL内から透過的に見えてしまう。「WSL内のプロセスからホスト側サービスへの不要な到達経路ができる」というセキュリティ上の抜け穴であるため、非開発者向け手順の末尾にも警告を残している。AIが発展的な作業で npx やNodeランタイムを要求してきた場合、安易にUbuntuの apt で入れるとバージョンが古すぎて動かない問題に直面する。
個人の趣味的なapt運用を避け、必要になった段階で mise（旧rtx） を導入し、mise activate でシェル環境を整える方針を推奨する（インストール手順）。
非公式な技術ブログやQiita等のまとめ記事は、執筆時点での疎通確認が取れていても、ツールやWSLのバージョンアップで動かなくなっているケースが極めて多い。特に変化の激しいWSL・AI領域においては、公式のインストール手順（curl等）を愚直になぞらせることが最も確実である。
モデル名は流動的であるため固定しない。無料枠のDeepSeek、GLM、Qwenなどを用途や時期に応じて /models から試行錯誤させる構成とした。
社会人と学生、あるいは潤沢な企業予算を使える開発者と無課金ユーザーの間には、AIとの付き合い方に決定的な経済的・環境的断絶がある。
富裕な環境であれば、毎月トークンやサブスクリプション（Codex appやClaude Desktopなど）に課金し、フル権限を与えた専用PC上で高度なエージェントを回せば済むかもしれない。しかし、手元にある1台のWindows PCで、無課金でAIの恩恵を受けようとする「貧者」には別の付き合い方が求められる。
目指すべきは、「ブラウザのチャット窓に質問して、綺麗なテキストの答えを貰って終わるAI」ではない。 それは現実から遊離した単なるQ&Aマシンに過ぎず、環境を加味せずに誤った回答を自信満々に返すリスクがある。
本当に必要なのは、現実の環境（ファイルシステム、HTTP通信、ローカルのブラウザ）に足をつけて接地（グラウンディング）し、手足を動かして試行錯誤してくれるbotとしてのAIである。 多少不格好であっても、WSLという隔離された小部屋を与え、そこで実際にファイルを生成させ、サーバーを立ち上げさせ、吐き出されたレポートをブラウザから人間が眺めてフィードバックを返す。
答えを一発で当てさせるのではなく、ホスト環境を安全に守った状態で、AIが環境を加味せずに誤った回答を自信満々に返すことを防ぎ、現実のツールを動かしながら自動試行錯誤を繰り返す。この「接地した状態での試行錯誤の場」を最小のコストとリスクで非開発者に手渡すことこそが、本構成の真の目的である。