1. はじめに
今回はMistralが先日リリースしたMistral Vibe CLIとDevstral Small 2の活用方法を検討した。Mistral Vibe CLIは生成AIをターミナルから実行するためのツールであり、Devstralはソフトウェアエンジニアリングに特化したLLMである。
以前から生成AIをターミナルから実行するツールとしてGemini CLIやQwen Codeなどがあったが、具体的な活用方法が思い浮かばず、ほとんど使用していなかった。しかし、Mistral Vibe CLIとDevstral Small 2のリリースを機に、改めてこれらの実用的な活用方法を検証することにした。
2. なぜこれまで生成AIをターミナルから実行するツールを使っていなかったか
普段の開発ではGitHub CopilotやContinueを利用しており、これらでほぼすべての要件を満たしていた。VSCodeは常に起動しているため、コード生成、リファクタリング、説明の要求などはVSCode上で生成AIとチャットすることで事足りていた。ソースコードを確認しながら作業するため、VSCode + GitHub Copilotの組み合わせが最も適していると感じていた。
3. ではCLIを何に使うのか
日常的にgrep、ss、dockerコマンドなど様々なコマンドを使用しているが、細かいオプションや正確な使い方をすべて覚えているわけではない。そのため、実行時に毎回オプションなどを調べる手間が生じている。Mistral Vibe CLIを経由して自然言語でコマンドを実行できれば、この手間を大幅に削減でき、効率化が図れるはずである。本検証では、Mistral Vibe CLIを介したコマンド実行が実際の業務にどれだけ役立つかを確認する。
4. 検証環境
4.1 ハードウェア
検証環境のハードウェアは以下の通り。
| 項目 | 内容 |
|---|---|
| OS | Kubuntu 24.04.03 |
| CPU | Ryzen 5 7600 |
| メモリ | DDR5-5600 64GB |
| マザーボード | MSI MAG B650 TOMAHAWK WIFI |
| GPU1 | ZOTAC GAMING GeForce RTX 5060 Ti 16GB Twin Edge |
| GPU2 | MSI GeForce RTX 3060 VENTUS 2X 12G OC |
| GPUドライババージョン | 580.105.08 |
$ nvidia-smi
Sun Dec 14 13:20:46 2025
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 580.105.08 Driver Version: 580.105.08 CUDA Version: 13.0 |
+-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA GeForce RTX 5060 Ti Off | 00000000:01:00.0 On | N/A |
| 0% 36C P8 11W / 180W | 1802MiB / 16311MiB | 4% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+
| 1 NVIDIA GeForce RTX 3060 Off | 00000000:06:00.0 Off | N/A |
| 0% 40C P8 17W / 170W | 15MiB / 12288MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+
4.2 使用モデル
unslothのGGUFからDevstral-Small-2-24B-Instruct-2512-UD-Q5_K_XL.ggufを選択した。
4.3 推論ソフトウェア
llama-swapを使用した。
サンプリングパラメータ(min-p, temp)はunslothのdevstral-2のUsage Guideに記載の値を指定した。
"Devstral-Small-2-24B-Instruct-2512-GGUF":
cmd: |
${latest-llama}
--model /app/models/Devstral-Small-2-24B-Instruct-2512-GGUF/Devstral-Small-2-24B-Instruct-2512-UD-Q5_K_XL.gguf
--ctx-size 81920
--cache-type-k q8_0
--cache-type-v q8_0
--n-gpu-layers 1000
--min-p 0.01
--temp 0.15
--jinja
--flash-attn on
env:
- "CUDA_VISIBLE_DEVICES=0,1"
ttl: 600
上記の設定でVRAM使用率は90%程度であった。
4.4 Mistral Vibe CLIの設定
インストール
コマンドとして使用できるようにするためpipxでインストールした。
sudo apt update
sudo apt install pipx
pipx ensurepath
pipx install mistral-vibe
4.5 起動
以下のコマンドで起動した。
vibe
4.6 Vibe CLIの接続先モデルをローカルのDevstralに切り替える
4.6.1 設定ファイルの編集
設定ファイルを編集し、ローカルLLMのURLとモデル名を設定した。
[[providers]]
name = "llama-swap"
api_base = "http://localhost:22015/v1" # 実際の環境に合わせて修正
api_key_env_var = ""
api_style = "openai"
backend = "generic"
(略)
[[models]]
name="Devstral-Small-2-24B-Instruct-2512-GGUF" # 実際の環境に合わせて修正
provider = "llama-swap"
alias = "local"
temperature = 0.2
input_price = 0.0
output_price = 0.0
4.6.2 Vibe CLIのUI上でのモデル切り替え操作
Vibe CLIを起動し、/modelコマンドでモデル切り替え画面を表示し、モデルにlocalを選択した。
5. 検証結果
5.1 想定シーン
実業務を考慮すると、サービスを動作させているリモートサーバーにVibe CLIのようなソフトウェアをインストールすることは現実的でない場合が多い。そのため、ローカルマシンにVibe CLIをインストールし、Vibe CLI経由でsshを実行してリモートサーバーの情報を参照・操作できれば有用であると考えた。
本検証では、自宅サーバー（KeycloakやNextCloudなどを実行中）の情報参照と操作が可能かどうかを試した。
5.2 ヘルスチェックの実行
各種Dockerコンテナの動作状態とOSのリソース状況を調査するプロンプトを実行した。
###修正版プロンプトあなたは高度なDocker運用の知識を持つインフラエンジニア（SRE）です。
SSHでホストg3plusに接続し、OSおよびDockerコンテナのヘルスチェックを行い、**現状の健全性とリスク（特にリソース枯渇と再起動ループ）**に焦点を当てたレポートを作成してください。
以下形式でコマンドを実行します。
`ssh g3plus "コマンド"`
##重要：制約事項（Safety First）1. **完全なReadOnly**: 変更操作（stop, rm, kill等）は厳禁です。
2. **非ブロッキング**: `docker stats` や `top` は必ずバッチモード（例: `--no-stream`, `-b -n 1`）で実行し、プロセスを占有しないでください。
##チェックリスト以下の観点で情報を収集・分析してください。
###1. OSリソース・デーモン生存確認* **リソース**: CPU Load Average, メモリ/Swap使用状況 (`uptime`, `free -h`)。
* **ディスク**: `/` および `/var/lib/docker` の使用率が80%を超えていないか (`df -h`)。
* **デーモン**: Dockerデーモンがアクティブか (`systemctl is-active docker`)。
###2. コンテナ稼働状況・詳細分析* **異常コンテナの特定**: `docker ps -a` を確認し、以下に該当するコンテナを抽出してください。
* **Restarting** / **Exited** (非正常終了)
* **Uptime** が極端に短い（再起動ループの疑い）
* **リソース消費**: `docker stats --no-stream` でCPU/メモリを過剰に消費しているコンテナを特定してください。
* **ログ確認（必要な場合のみ）**: 上記で異常が見られたコンテナのみ、`docker logs --tail 20` で直近のエラーを確認してください。
---
##レポート出力形式（Markdown）収集した情報を統合し、以下の形式で出力してください。異常がない場合はその旨を簡潔に記載してください。
#Dockerホスト ヘルスチェックレポート**実施日時:** YYYY-MM-DD HH:MM
**ホスト名:** [hostname]
##1. エグゼクティブサマリー* **総合判定:** [ 正常 / 注意 / 危険 ]
* **概要:** （システム全体の状態要約。異常がある場合のみ、その影響範囲を記載）
##2. 注目すべきコンテナ（異常・高負荷）*※異常または高負荷なコンテナのみ記載*
| コンテナ名 | ステータス | CPU | MEM | 詳細・ログ抜粋 |
| --- | --- | --- | --- | --- |
| db-worker | Restarting (5s) | 0.0% | 10MB | **NG** (Error: Connection refused...) |
| web-app | Up (2 hours) | 95% | 2GB | **高負荷** |
##3. ホストOSリソース状況| 項目 | 値 | 判定 |
| --- | --- | --- |
| Load Average | [値] | [OK/NG] |
| ディスク(/var/lib/docker) | [使用率] | [OK/NG] |
| メモリ/Swap | [使用率] | [OK/NG] |
##4. 推奨アクション* （具体的な調査コマンドや、復旧に向けたネクストアクションを1〜2行で提示）
プロンプト実行中、Vibe CLIはタスクを段階的に処理&コマンド実行していることが確認できた。
完了後、以下のヘルスチェック結果がファイル出力された。
# Docker ホスト ヘルスチェックレポート
**実施日時:** 2025-12-14 05:16
**ホスト名:** g3plus
## 1. エグゼクティブサマリー
**総合判定:** 正常
**概要:** システム全体の状態は正常です。すべてのコンテナが正常に稼働しており、リソース消費も適正な範囲内です。
## 2. 注目すべきコンテナ（異常・高負荷）
※異常または高負荷なコンテナはありません。
## 3. ホスト OS リソース状況
| 項目 | 値 | 判定 |
| --- | --- | --- |
| Load Average | 0.08, 0.02, 0.00 | OK |
| ディスク (/) | 34% | OK |
| ディスク (/var/lib/docker) | 34% | OK |
| メモリ/Swap | 3.5Gi/15.37GiB (Mem), 512Ki/4.0Gi (Swap) | OK |
## 4. 推奨アクション
具体的な異常や高負荷は確認されていません。定期的な監視を継続してください。
5.3 リスニングポートの表示
ssコマンドのオプションを忘れがちなため、自然言語でリスニングポートを表示させることができるか確認した。
g3plusにsshで接続して、listeningしているポートを表示してください。
結果としてss -tulnコマンドが実行され、正しくポート情報が取得できた。
5.4 Dockerコンテナのネットワーク構成の調査
Dockerコンテナのネットワーク構成を自動的に調査・整理させた。
ホストg3plusにsshでアクセスしてg3plus上で動作しているdockerコンテナのネットワーク構成について情報を取得し、整理してまとめてください。
以下形式でコマンドを実行します。
`ssh g3plus "コマンド"`
実行中の画面では、段階的に情報を収集・処理している様子が確認できた。
出力結果は以下の通りで、ネットワーク構成、IPアドレス、同一ブリッジネットワーク上のコンテナが整理されて出力された。
# Dockerコンテナのネットワーク構成についての報告書
## 概要
ホスト`g3plus`には、以下の4つのDockerネットワークが存在しています。
- `bridge` (ブリッジネットワーク)
- `host` (ホストネットワーク)
- `none` (Nullネットワーク)
- `sso-net` (カスタムブリッジネットワーク)
- `systems_default` (カスタムブリッジネットワーク)
## ネットワークの詳細情報
### 1. bridge ネットワーク
- **ドライバ**: `bridge`
- **スコープ**: `local`
- **サブネット**: `172.17.0.0/16`
- **ゲートウェイ**: `172.17.0.1`
- **特徴**:
- Dockerのデフォルトブリッジネットワーク。
- コンテナ間の通信を可能にするが、ホストOSとの通信は制限される。
- このネットワークに直接接続されているコンテナはありません。
### 2. host ネットワーク
- **ドライバ**: `host`
- **スコープ**: `local`
- **特徴**:
- コンテナがホストOSのネットワークスタックを直接使用する。
- ネットワークの隔離がなく、ホストOSと同じネットワーク環境になる。
- このネットワークに直接接続されているコンテナはありません。
### 3. none ネットワーク
- **ドライバ**: `null`
- **スコープ**: `local`
- **特徴**:
- コンテナがネットワークから完全に隔離される。
- 外部との通信ができない。
- このネットワークに直接接続されているコンテナはありません。
### 4. sso-net ネットワーク
- **ドライバ**: `bridge`
- **スコープ**: `local`
- **サブネット**: `172.18.0.0/16`
- **ゲートウェイ**: `172.18.0.1`
- **特徴**:
- カスタムブリッジネットワーク。
- 以下のコンテナがこのネットワークに接続されています:
- `nextcloud` (IP: `172.18.0.2`)
- `nginx` (IP: `172.18.0.6`)
- `mariadb` (IP: `172.18.0.5`)
- `open-webui` (IP: `172.18.0.8`)
- `pipelines` (IP: `172.18.0.4`)
- `postgres` (IP: `172.18.0.3`)
- `keycloak` (IP: `172.18.0.7`)
- このネットワークは、Nextcloud、OpenWebUI、Keycloak、およびPipelinesなどのサービス向けに作成されたものです。
### 5. systems_default ネットワーク
- **ドライバ**: `bridge`
- **スコープ**: `local`
- **サブネット**: `172.19.0.0/16`
- **ゲートウェイ**: `172.19.0.1`
- **特徴**:
- カスタムブリッジネットワーク。
- 以下のコンテナがこのネットワークに接続されています:
- `adguardhome` (IP: `172.19.0.2`)
- このネットワークは、Docker Composeを使用して作成された`systems`プロジェクトのデフォルトネットワークです。
## コンテナのネットワーク接続状況
以下のコンテナが`g3plus`ホスト上で動作しています。
| コンテナ名 | ネットワーク名 | IPアドレス |
|------------------|---------------------|------------------|
| `nextcloud` | `sso-net` | `172.18.0.2` |
| `nginx` | `sso-net` | `172.18.0.6` |
| `mariadb` | `sso-net` | `172.18.0.5` |
| `open-webui` | `sso-net` | `172.18.0.8` |
| `pipelines` | `sso-net` | `172.18.0.4` |
| `postgres` | `sso-net` | `172.18.0.3` |
| `keycloak` | `sso-net` | `172.18.0.7` |
| `adguardhome` | `systems_default` | `172.19.0.2` |
## 結論
`g3plus`ホスト上で動作しているDockerコンテナは、主に2つのカスタムブリッジネットワーク（`sso-net`と`systems_default`）に接続されています。これらのネットワークは、Docker Composeを使用して作成されたプロジェクトに属しています。デフォルトのブリッジ、ホスト、およびNullネットワークは存在しますが、直接コンテナが接続されているわけではありません。
6. まとめ
本検証を通して、Mistral Vibe CLIとローカルで動作するDevstral Small 2モデルを組み合わせることで、自然言語によるサーバー操作と状況分析が実用的に行えることを確認した。
Devstral Small 2の性能評価
24BパラメータのDevstral Small 2は、ソフトウェアエンジニアリングに特化したモデルとして十分な性能を示した。特に以下の点が印象的であった：
- 複雑なプロンプトを正確に理解し、適切なコマンド列を生成できた
- 複数のコマンドを段階的に実行し、その結果を統合して分析する能力が実用的なレベルにあった
- 技術的な概念（Dockerネットワーク構成など）を正確に理解し、構造化されたレポートを出力できた
- ローカル環境での推論速度も、インタラクティブな使用に十分な応答性を維持していた
具体的には以下の点が評価できる。
-
複雑なコマンドの簡易実行:
ssやdockerコマンドなど、オプションを正確に覚えていないコマンドでも、自然言語での指示により適切なコマンドを生成・実行してくれる。 - 構造化されたレポート出力: ヘルスチェックやネットワーク構成調査のように、複数のコマンド実行と情報収集が必要なタスクでも、プロンプトに従って自動的に実行し、結果を整然としたレポート形式でまとめてくれる。
総じて、Mistral Vibe CLIは、日常的なサーバー運用と監視の作業を効率化する有効なツールとなり得ると言える。Devstral Small 2モデルの十分な性能と相まって、ローカル環境でのAI活用の新たな可能性を示す結果となった。