Why I Stopped Guessing at Linux Distros and Started Asking AI to Reason Through It

AIでLinuxを攻略する: 全4回シリーズ

第1回: ディストロを選ぶ → 第2回: ストレージと暗号化 → 第3回: 手動インストール → 第4回: サービスとGPU

Linuxをインストールした回数は数えきれないほどある。毎回、ディストロの選択は直感か、前回使ったものに頼っていた。だが、特定の目的のために構築するなら、直感では通用しない。DockerとPostgreSQL、ローカルAIモデル、3台の暗号化ディスクにまたがるパケットキャプチャが必要なセキュリティ用ブレインノードとなれば、それはアーキテクチャの問題であって、感覚の問題ではない。

この章では、AIが実際のアーキテクチャを提示してくれるよう、会話をどう組み立てるかを解説する。Wikipediaの要約ではなく、実際のワークロードを入力として与え、構造化された推論を引き出し、ハードウェアをストレージ計画に対応させ、ファームウェアの落とし穴を事前に発見して何時間もの無駄を防ぐ方法だ。最終的には、どんな構成、どんなハードウェア、どんなディストロにも応用できる再現性のある手法が手に入る。

最初のプロンプトが最も重要

Linuxについて考えるとき、多くの人がChatGPTに入力するのはこんな文章だ:

「どのLinuxディストロをインストールすればいいですか?」

そして返ってくるのは、予想通りのものだ。各ディストロを表面的に説明したリスト。Ubuntuは初心者向け。Fedoraはパッケージが新しい。Archは苦しむのが好きな人向け。まったく役に立たない。

問題はAIではない。プロンプトだ。漠然とした質問をすれば、漠然とした答えが返ってくる。「何をインストールすべきか」から「このマシンに必要なことはこれだ」へと切り替えた瞬間、会話は一変する。

実際に機能するプロンプトのパターンはこれだ:

1I'm setting up a Linux machine for [specific role].
2My requirements are: [list workloads].
3The machine needs to support: [list services].
4What distribution should I consider and why?

シンプルな構造。しかし出力の質は大きく変わる。AIが暗記ではなく推論できるだけの文脈を与えているからだ。

構築するものに本当に必要なもの

プロンプトを送る前に、役割を具体的に定義しよう。「Linuxサーバー」ではなく、何をするのかを明確にする。このシリーズで扱うセキュリティ用ブレインノードの場合、ワークロードのリストはこうなる:

• 複数のセキュリティツールとサービスを動かすDockerコンテナ
• 構造化データとキャッシュのためのPostgreSQLとRedis
• ローカルでAIモデルを実行するためのOllama（クラウド依存なし）
• 推論の高速化に向けた将来的なNVIDIA GPUパススルー
• 適切な証拠保全の分離を伴う攻撃アーティファクトのストレージ
• NVMe、SSD、HDDにまたがる暗号化マルチディスクストレージ
• 最新パッケージの追いかけによる常時破損なしの長期安定性

これはもはや「どのディストロ?」という質問ではない。アーキテクチャの問題だ。そのように組み立てると、AIはパッケージエコシステム、カーネルサポートのタイムライン、ドライバの可用性、コミュニティのツール群について考え始める。制約を提供するのはあなたの仕事。それを論理的に整理するのがAIの仕事だ。

推論がどのように展開されるか

このようなワークロードリストをAIに渡すと、単なる答えではなく、各選択肢の背後にある推論が返ってくる。期待できる内容はこうだ:

Kali Linuxが最も強く推薦される。Debianベースであるため、パッケージ管理が堅牢で互換性も広い。セキュリティツールは最初から入っているか、apt install一発で揃う。ローリングリリースによりツールを最新に保てるが、Archのような不安定さはない。そしてコミュニティが、このマシンが行う種類の作業に特化している。

Ubuntu Serverは次点。Dockerサポートが優秀で、コミュニティも大きく、LTSリリースもある。ただしセキュリティ重視の構成では、Kaliが標準で提供するツールのインストールに最初の2日間を費やすことになる。専用の基盤が必要なところに、汎用の基盤を使うことになる。

Debian Stableは保守的すぎる。パッケージのバージョンが、OllamaやNVIDIAの新しいドライバが必要とするものより古い。バックポートとの戦いが絶えなくなる。

Arch Linuxはパッケージが最新だが、本番データベースとDockerサービスを動かすマシンにローリングリリースの不安定さを持ち込むのはリスクが高い。pacman -Syuが一度失敗すれば、PostgreSQLインスタンスが落ちる。

Fedora Serverは興味深いが、RPMベースのツール群は、ほとんどのセキュリティツールが対象とするKali/Debianエコシステムと合わない。

この構成ではKaliを選ぶ。流行っているからでも、YouTubeの動画がそう言っていたからでもなく、ワークロードのプロファイルがKaliの設計目的に直接合致しており、DebianベースがDockerとPostgreSQLに必要な安定性を提供するからだ。あなたの構成では別の選択肢が浮かび上がるかもしれない。それこそが、感覚で決めるのではなくAIに推論させる意味だ。

ハードウェア調査の会話

ディストロが決まったら、すぐにISOに手を伸ばしてはいけない。まず、使用するハードウェアを正確に把握する。ここでAIとの会話が本当に力を発揮する。

次のプロンプトを試してほしい:

1You are a security expert and are setting up a clean Kali Linux
2install. I'm sitting in front of the terminal. What commands do
3you want me to run to get you all the specs and hard drives
4available to plan this?

もう一度読んでほしい。「CPUの確認方法は?」と聞いているのではない。AIに調査シーケンス全体を設計させているのだ。計画のために何が必要かに基づいて。これは根本的に異なるやり取りだ。調査の主導権をAIに渡し、あなたはコマンドを実行して結果を報告する。

AIが求めるもの(そして各カテゴリが重要な理由)

コマンドのリストが返ってくる。カテゴリ別に整理された、バラバラなコマンドではなく、意図的な調査プロトコルだ。期待できる内容はこうだ:

ファームウェアモード(ls /sys/firmware/efiまたはBIOS設定の確認): ブート戦略全体を決定する。UEFIならGPTパーティションテーブルとESPパーティションが必要。レガシーBIOSならMBRと異なるブートローダー設定が必要。ここを間違えると再インストールになる。

CPUとRAM(lscpu、free -h): コア数とメモリ量により、Dockerコンテナを同時にいくつ動かせるか、ローカルAIモデルがメモリに収まるか、PostgreSQLの設定をどこまで積極的にできるかが決まる。

ディスクの一覧(lsblk -o NAME,SIZE,TYPE,ROTA,TRAN,MODEL、fdisk -l): 各ディスクのサイズ、インターフェースの種類(NVMe、SATA)、回転の有無。ストレージアーキテクチャの基盤となる。

コントローラーモード(BIOS設定、dmesg | grep -i ahci): AHCIかRAIDかIDEモードかによって、ディスクのパフォーマンスとLinuxとの互換性が変わる。RAIDモードのコントローラーは、インストーラーから個別のディスクを隠してしまうことがある。

GPUハードウェア(lspci | grep -i vga、lspci -nn | grep -i nvidia): 2つの理由で重要だ。第一に、NVIDIAのGPUは適切に対処しないとインストーラーがクラッシュすることがある。第二に、正確なGPUモデルを知ることで、後で必要なドライバのバージョンが決まる。

ネットワークデバイス(ip link、lspci | grep -i net): インストール中にパッケージをダウンロードするためにネットワーク接続が必要だ。Intel、Realtek、Broadcomのどれかによって、ファームウェアパッケージが必要かどうかが決まる。

既存のパーティションテーブル(fdisk -l、blkid): 何かを消去する前に、既存のデータやパーティション構成を把握しておく必要がある。

SMARTヘルス(smartctl -a /dev/sdX): ディスクのヘルスデータにより、長期ストレージとして信頼できるドライブと、高負荷のワークロードで故障しそうなドライブが分かる。

ワークフローのパターン

実際にはこのように進む:

1. AIがコマンドのバッチを提示する
2. ターミナルで実行する
3. 出力をチャットに貼り付ける
4. AIが結果を解釈し、追加の質問をする
5. 全体像が見えるまで繰り返す

lspciの出力の各行が何を意味するか理解する必要はない。AIが読み取り、関連する部分を指摘し、構成への影響を教えてくれる。協調的なトラブルシューティングと考えればいい。あなたが手を動かし、AIがアナリストとして機能する。この役割分担が機能するのは、AIが密度の高い技術的な出力を、ほとんどの人間が読むより速く処理できるからだ。

AIがハードウェアを解釈する

調査コマンドを一通り実行したら、次のような機器一覧が手元に揃う(これはこのシリーズの構成における実際のハードウェアだ):

• NVMe SSD、1TB: Samsung 970 EVO Plus、シーケンシャル読み取り約3,500 MB/s
• SATA HDD、1TB: Western Digital Blue、5400 RPM、機械式
• SATA SSD、128GB: 旧型のKingston、性能はそこそこだが容量が小さく、SMARTに温度上昇イベントが記録されている
• GPU: Intel内蔵 + NVIDIA GeForce(ハイブリッド/Optimus構成)
• RAM: 32GB DDR4
• CPU: Intel i7、8コア/16スレッド

生のスペックは単なる数字だ。重要なのは、AIがそれをワークロードにどう対応させるかだ。ハードウェアの出力をチャットに貼り付けると、各ディスクの特性が先ほど説明した要件にどう合致するかに基づいて、ストレージアーキテクチャが導き出される。

3層ストレージアーキテクチャ

マルチディスク構成では、各ディスクが最も得意とするワークロードを担う階層型システムをAIが提案する:

第1層: NVMe(主力)は速度が必要なすべてのものに使う。オペレーティングシステム、Dockerコンテナのストレージ、PostgreSQLデータベース、Redisデータ、OllamaのAIモデル。これらのワークロードはランダムI/Oが多く、NVMeはそれを難なくこなす。このディスクにはLVMによる柔軟なパーティション管理を伴うLUKS暗号化を適用する。

**第2層: SATA SSD(ホットワークスペース)**はアクティブな分析に使う。調査作業中は、抽出したサンプル、ツールの一時出力、進行中のデータへの高速アクセスが必要だ。128GB SSDはSSD速度のアクセスを提供しつつ、一時ファイルで主要なNVMeを汚染しない。こちらもLUKS暗号化を施し、専用ワークスペースとしてマウントする。

**第3層: SATA HDD(コールドアーカイブ)**は長期保存に使う。パケットキャプチャ、フォレンジックエクスポート、証拠アーカイブ、存在する必要はあるが高速アクセスは不要なものすべて。機械式ドライブはここに最適だ。大容量で安価、シーケンシャル書き込みに対して信頼性が高い。別のキーでLUKS暗号化する。

「データベースを回転ディスクに置くな。年に2回しか開かないファイルにNVMeの帯域を無駄にするな。ストレージ層をアクセスパターンに合わせろ。」

小さなSSDがルートディスクとして却下される理由

陥りやすい罠がある。NVMeを「データ用に空けておく」ために小さなSSDをルートディスクとして使うというものだ。論理的に聞こえる。しかしAIは強く反論する。その理由はこうだ。

Dockerイメージとコンテナボリュームだけで、セキュリティワークステーションでは40〜60GBを消費することがある。PostgreSQLのデータディレクトリ、Ollamaのモデルファイル(1つあたり4〜8GBになることもある)、システムパッケージを加えると、余裕のあるルートパーティションには最低80〜100GBが必要だ。128GBのディスクでは、成長の余地がほとんどない。大きなDockerイメージを1つ取得するだけで使用率が95%に達する。

SMARTデータもさらなる懸念材料だ。SSDがサーマルスロットリングイベントを記録しているなら、故障しているわけではないが、システムルートとして使いたいディスクでもない。

NVMeが明らかな第一候補だ。より高速で、より大容量で、より健全であり、Dockerとデータベースを抱えるルートパーティションが生成する混合ランダム/シーケンシャルワークロードのために設計されている。深く考えすぎる必要はない。

何時間もの無駄を防ぐファームウェアの確認

ここで、調査プロセスがディスクに1バイトも書き込む前にその価値を証明する。

調査コマンドの1つで、マシンがレガシーBIOSモードで動作していることが判明することがある。レガシーモードでもマシンは問題なく動作する。しかし暗号化マルチディスク構成には適していない。これはまさに、あなたが気づかないかもしれないことをAIが発見する例だ。その理由はこうだ:

レガシーBIOS + MBRでは、ディスクあたりのプライマリパーティションが4つに制限される。LVMを使った3ディスク暗号化構成では、これが実際の制約になる。拡張パーティションと論理ボリュームを不必要に複雑な方法で使うことになる。

UEFI + GPTはパーティション数の制限がなく、大容量ディスクをネイティブにサポートし、よりクリーンなブートプロセスを提供する。暗号化マルチボリューム構成には、GPTが正しい基盤だ。

AIがこれを指摘した場合の次の手順: インストール前に3つのファームウェア変更を行う。

1. BIOS設定でUEFIモードに切り替える
2. セキュアブートを無効にする(Kaliのインストーラーはセキュアブートをサポートしているが、初期セットアップ中、特にNVIDIAのドライバインストール時に摩擦が生じる)
3. SATAコントローラーがAHCIモードになっているか確認する(すでに設定されているかもしれないが、確認する)

これは知らなければ気づかない種類の問題だ。USBドライブを焼く前の調査段階で発見することで、実際の時間と労力を節約できる。ファームウェアの切り替えはBIOS設定で5分で済む。インストールの途中で問題に気づけば、最初からやり直しになる。

再現性のある手法

このプロセス全体が行き着くのは、どんな構成、どんなハードウェア、どんなディストロにも使える手法だ。保存しておいてほしい。

ステップ1: 目標を具体的に説明する。「Linuxが欲しい」ではなく、「これらのサービスを動かし、これらのワークロードを処理し、このタイプのデータを保存するシステムが必要だ」と伝える。具体的であるほど、AIはより適切に推論できる。

**ステップ2: AIに調査を設計させる。**個別のコマンドをGoogleで調べるのではなく、AIに役割を伝え、調査を設計させる。あなたが確認しようとは思わなかったことも尋ねてくれる。

**ステップ3: 実行して報告する。**コマンドを実行し、出力を貼り付ける。あなたが手を動かし、AIがアナリストとして機能する。この役割分担が機能するのは、AIが密度の高い技術的な出力を、ほとんどの人間が読むより速く処理できるからだ。

**ステップ4: AIに目標と照らし合わせて解釈させる。**生のスペックは文脈なしには意味がない。128GB SSDはメディアサーバーのルートパーティションとして問題ない。しかしDockerを多用するセキュリティワークステーションには危険なほど小さい。AIはハードウェアをワークロードの要件に対応させ、見落としがちな不一致を指摘する。

**ステップ5: 全体像が見えるまで繰り返す。**調査は1回で終わることはほとんどない。AIは追加の質問をする。「その古いSSDのsmartctlの結果は?」や「NVIDIAのGPUがプライマリディスプレイアダプターですか?」といった具合に。各ラウンドで計画が洗練される。

「Linuxのコマンドを暗記する必要はない。何を構築しているかを知ればいい。AIが目標と実装の間の翻訳を担う。」

この手法は、ホームメディアサーバー、開発用ワークステーション、ネットワークアプライアンス、ペネトレーションテストリグのどれを設定する場合でも機能する。コマンドは変わる。パターンは変わらない。

これでディストロが決まり、ハードウェアの完全な一覧が揃い、階層型ストレージ計画ができ、ファームウェアの設定もクリーンになった。ここから先はすべて実行だ。第2回では、これらすべてを実際のパーティション構成に落とし込む。暗号化ボリューム、LVMのレイアウト、マウントポイント、そしてインストーラーがディスクに触れる前にすべてを検証する準備スクリプトだ。そこで構築が現実になる。

**次回: 第2回: ストレージと暗号化**では、暗号化ボリュームの設計、LVMのレイアウト、そしてインストール開始前にハードウェアを検証する安全確認スクリプトを扱う。ターミナルを用意して臨んでほしい。