WordPress インストール

最新のWordPresssダウンロード

ダウンロード後展開する作業場所へ移動し、ダウンロードします
筆者は、ユーザーディレクトリの「Downloads」を作業場所にしました

cd ~/Downloads/
wget https://ja.wordpress.org/latest-ja.tar.gz
tar xvzf latest-ja.tar.gz
ls wordpress/ 

WordPress パッケージが展開されました

index.php             wp-config-sample.php  wp-mail.php
license.txt           wp-content            wp-settings.php
readme.html           wp-cron.php           wp-signup.php
wp-activate.php       wp-includes           wp-trackback.php
wp-admin              wp-links-opml.php     xmlrpc.php
wp-blog-header.php    wp-load.php
wp-comments-post.php  wp-login.php

WordPressパッケージをApache設定場所へ移動

展開した「wordpress」ディレクトリを、前回「httpd.conf」で「DocumentRoot」に設定したディレクトリ配下へ移動します
また、「wordpress」というディレクトリ名は、公開する時のアドレス名になります
この場合、https://「サイトドメイン」/wordpress/ です。
変更したい場合には、好みの名前に変更します
次の例では、「blog」という名前に変更し、所有権も「apache」に変更しています

cd ~/Downloads/
sudo mv ./wordpress/ /home/www/html/ 
cd /home/www/html/
sudo mv ./wordpress/ ./blog/
sudo chown -R apache.apache ./blog/
ls -la

・
・
drwxr-xr-x. 5 apache apache 4096  4月  3 01:00 blog
-rw-r--r--. 1 apache apache  121  4月 24 10:52 index.html

「blog」と言う名前に変更され、所有者も「apache」になっていれば、WordPressの配置は完了です。

MariaDBの設定

WordPress用のデータベースとユーザーを作成します
設定情報は、事前にメモを作成しておくとスムーズに進行できます
例として、下記で設定します

• root パスワード：初期設定で、「Change the root password」で作成したパスワード
• データベース名：WpDb
• ユーザー名：WpAdmin
• パスワード：WpPasswd
• データベースホスト：localhost

データベースの作成

mysql -u root -p[rootパスワード] #-pの後ろはスペースは入れない
・
・データベース作成
MariaDB [(none)]>CREATE DATABASE WpDb CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
・
・データベース確認
MariaDB [(none)]> SHOW DATABASES;
・
・管理者作成
GRANT ALL ON WpDb.* TO 'WpAdmin'@'localhost' IDENTIFIED By 'WpPasswd';
・
・確認
USE mysql
SELECT user,host from user;
SHOW GRANTS FOR 'WpAdmin'@'localhost';

もし、データベース名やユーザーを変更したい場合には、「DROP」コマンドで
一度削除し、再生成します

DROP DATABASE データベース名;
・より安全を考慮した次のコードでは存在しない場合のエラーを回避できます
DROP DATABASE IF EXISTS データベース名;

DROP USER 'username'@'localhost';
・存在しない場合のエラーを回避
DROP USER IF EXISTS 'username'@'localhost'; 

WordPress 初期設定

初期設定

Apacheの設定で、ドメインでのアクセスが可能であればドメインで、
ドメインでの設定をしていない場合には、IPアドレスを
ChromeなどWebブラウザに入力して確認します
「WordPressへようこそ・・・」の画面が表示されます。

その画面で「さあ、始めましょう！」をクリック
上記で設定したデータベース情報を設定します

「サイトタイトル」「ユーザー名」「パスワード」を設定しますが
ここでのユーザー名は、WordPressの管理画面にログインするユーザーを設定します
データベースの管理ユーザーとは違いますので注意してください

ログインで、WordPressの管理画面からWordPressの設定ができるようになります

サイトヘルス

「https://「サイトドメイン」/blog/wp-admin/site-health.php」にアクセスすると、サイトの状態が確認できますが、自宅環境では、「REST API 」エラーが出ました

自宅内での設定の場合、名前解決ができていないのが原因のようです
同じLAN上のwindowsPCには「hosts」ファイルに設定しましたが、サーバー（Linux）側も
「hosts」設定し強制的に名前解決させようと思います。

sudo vi /etc/hosts

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.1.100 www2.hogehoge.com

これで、「・・/wp-admin/site-health.php」を更新すると、「REST API 」エラーは消えていました

Hello World!

「https://「サイトドメイン」/blog/」にアクセスすると、デフォルトのサンプルページが表示されます

WordPress環境構築終了

これで、WordPress環境構築は終了です
「https://「サイトドメイン」/blog/wp-admin/」で、ダッシュボード（管理画面）が開きます。
コンテンツから外観までいろいろな設定変更が可能で、「管理画面（ダッシュボード）」を使いこなすことから始めます。
まずは、「外観」⇒「テーマ」を変更する事で、見栄えをガラッと変えましょう！

WordPress環境構築まとめ

PHP
MariaDB

上記を参考に、PHP8.4 MariaDB11.4(LTS)をインストールします

PHPのインストール

筆者の現環境では、PHPはまだインストールしていませんが、とりあえず確認します

php --version

やはりインストールされていませんが、もしインストールされている場合には、必要あればバックアップを取り、問題なければすべて削除します

sudo dnf remove php*
sudo dnf remove php-*

PHP モジュールリストを確認します

dnf module list php

Rocky Linux 9 - AppStream
Name     Stream       Profiles                      Summary                            
php      8.1          common [d], devel, minimal    PHP scripting language             
php      8.2          common [d], devel, minimal    PHP scripting language             
php      8.3          common [d], devel, minimal    PHP scripting language             

Remi's Modular repository for Enterprise Linux 9 - x86_64
Name     Stream       Profiles                      Summary                            
php      remi-7.4     common [d], devel, minimal    PHP scripting language             
php      remi-8.0     common [d], devel, minimal    PHP scripting language             
php      remi-8.1     common [d], devel, minimal    PHP scripting language             
php      remi-8.2     common [d], devel, minimal    PHP scripting language             
php      remi-8.3     common [d], devel, minimal    PHP scripting language             
php      remi-8.4     common [d], devel, minimal    PHP scripting language             
php      remi-8.5     common [d], devel, minimal    PHP scripting language  

私の環境では、AppStream には、8.3までですが、Remiでは、8.5まで登録されています
ここでは、最新は避けて8.4をインストールしようと思います

sudo dnf module install php:remi-8.4
sudo dnf install php

拡張機能を追加

WordPressを動作させるのに、必須と推奨なPHP拡張機能があります。
こちらとAIの意見を参考にして、インストールしておきたいと思います。
すでに、インストール済みや一致するものがない場合もありましたが、インストールしました

sudo dnf install \
  php-mysql php-curl\
  php-mysql php-exif\
  php-mysql php-fileinfo\
  php-mysql php-gd\
  php-mysql php-imagick\
  php-mysql php-intl\
  php-mysql php-json\
  php-mysql php-mbstring\
  php-mysql php-mysqli\
  php-mysql php-openssl\
  php-mysql php-xml\
  php-mysql php-zip

再起動

sudo systemctl restart httpd
sudo systemctl restart php-fpm

PHP8.4について、🧑‍💻AIからのアドバイス

補足：PHP 8.4での注意点（AIからのアドバイス）

PHP 8.4は比較的新しいため、利用しているWordPressテーマや古いプラグインがまだ対応しておらず、非推奨（Deprecated）の警告が出る場合があります。

• もしエラーが出る場合は、WordPressの管理画面から「サイトヘルス」を確認し、足りないモジュールがないかチェックしてみてください。

もし特定のプラグインで「これが足りない」と言われた場合は、dnf search php-拡張名 で探すとすぐに見つかりますよ。

php.ini の設定

PHPの設定は、「/etc/php.ini」で行います。
念のためバックアップととり、編集します。

sudo cp -p /etc/php.ini /etc/php.ini.org
sudo vi /etc/php.ini

筆者の利用方法としては、記事内に画像貼り付けと少数ですが動画も貼り付けたいと思っているので、多少余裕をもった設定にしました。

・
・
;expose_php = On
expose_php = Off

;max_execution_time = 30
max_execution_time = 300

;max_input_time = 60
max_input_time = 300

;max_input_vars = 1000
max_input_vars = 3000

;post_max_size = 8M
post_max_size = 300M

;upload_max_filesize = 2M
upload_max_filesize = 256M

;max_file_uploads = 20
max_file_uploads = 50

;date.timezone =
date.timezone = "Asia/Tokyo"

;mbstring.language = Japanese
mbstring.language = Japanese

;mbstring.internal_encoding =
mbstring.internal_encoding = UTF-8

;mbstring.http_input =
mbstring.http_input = UTF-8

;mbstring.http_output =
mbstring.http_output = pass

;mbstring.encoding_translation = Off
mbstring.encoding_translation = On

;mbstring.detect_order = auto
mbstring.detect_order = auto

;mbstring.substitute_character = none
mbstring.substitute_character = none
・
・

キャッシュ拡張用の10-opcache.ini の設定変更

OPcache（オプキャッシュ）は、PHPスクリプトのコンパイル結果（バイトコード）を共有メモリにキャッシュすることで、PHPの動作を高速化する拡張モジュールですが、その設定ファイルも余裕をみた設定にしました
/etc/php.d/10-opcache.ini もバックアップをとって編集します

sudo cp -p /etc/php.d/10-opcache.ini /etc/php.d/10-opcache.ini.org
sudo vi /etc/php.d/10-opcache.ini

・
・
opcache.enable=1

;opcache.memory_consumption=128
opcache.memory_consumption=256

;opcache.memory_consumption=128
opcache.memory_consumption=256

;opcache.max_accelerated_files=10000
opcache.max_accelerated_files=20000
・
・

sudo systemctl restart php-fpm
sudo systemctl restart httpd

httpd.conf の編集

こちらは、必須ではないですが、やっといたほうがいいかも？との🧑‍💻AIのアドバイスです

/etc/httpd/conf/httpd.conf

・
・
LimitRequestBody 314572800  #（= 約300MB）
・

ただ、こちらの情報では、

デフォルト値が 0 (無制限) から 1 GiB に変更されたようです。

デフォルトでは無制限ではなくなったみたいです。

多少の動画添付を考慮した、WordPress側の設定

こちらも、🧑‍💻AIのアドバイス
画像貼り付け予定であれば、設定しておいたほうがよいとの事
こちらは、wordpress立ち上げ時に設定しようと思います

WordPress側の設定（wp-config.php）

define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

PHP確認

「/home/www/home」に「index.php」という、ファイルを作成し、ブラウザに「https://www2.hogehoge.com/index.php」で確認します

echo '<?php phpinfo(); ?>' | sudo tee /home/www/html/index.php

アドレスバーに「https://www2.hogehoge.com/index.php」で確認します

確認ができたら、削除しておきましょう

sudo rm /home/www/html/index.php

MariaDB 11.4(LTS)

11.5も動作すると思いますが、11.4(LTS)をインストールしようと思います

リポジトリ追加

リポジトリ追加

curl -LsS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="mariadb-11.4"

パッケージキャッシュの更新

sudo dnf makecache

EPEL リポジトリ系のネットワーク接続エラーが出たので、AIに聞いてみましたが、問題はないようです
AIの回答では閉鎖環境では、EPELを無効化する事でエラーは消えるようです（筆者は試していません）

EPEL リポジトリ系エラーについて、🧑‍💻AIの回答

なるほど、閉域網環境なんですね。その状況なら無効化で問題ないです。

EPEL を無効化する

sudo dnf config-manager --disable epel

確認

sudo dnf makecache

エラーが消えれば OK です。

本機トラブル時に外部接続が必要になったら

その時は再度有効化すればいいだけです：

sudo dnf config-manager --enable epel

切り替えが簡単なので、普段は無効化しておいて問題ありません👍

パッケージ情報の一覧は、下記で確認できます
11.4のパッケージが確認できました

dnf list mariadb*

・
MariaDB-client.x86_64          11.4.10-1.el9     @mariadb-main
MariaDB-client-compat.noarch   11.4.10-1.el9     @mariadb-main
MariaDB-common.x86_64          11.4.10-1.el9     @mariadb-main
MariaDB-server.x86_64          11.4.10-1.el9     @mariadb-main
MariaDB-server-compat.noarch   11.4.10-1.el9     @mariadb-main
MariaDB-shared.x86_64 
・

MariaDB 11.４ のインストール

sudo dnf install -y MariaDB-server MariaDB-client

MariaDB サービスの起動と自動起動設定

sudo systemctl start mariadb
sudo systemctl enable mariadb

初期セキュリティ設定

sudo mariadb-secure-installation

対話形式で以下を設定します：

ファイアウォールの設定（外部接続が必要な場合）

外部からデータベースに接続する場合には、ファイヤフォールに許可します
筆者は外部からデータベースへのアクセスの予定はないので、今回は設定していませんが
覚書として、書いておきます。

sudo firewall-cmd --permanent --add-service=mysql
sudo firewall-cmd --reload
sudo firewall-cmd --list-all --zone=public

インストール確認

sudo systemctl status mariadb

文字コードの設定

文字化け防止に、文字コードを編集します
設定ファイルは
「/etc/my.cnf.d/server.cnf」
「/etc/my.cnf.d/client.cnf」で行うので
バックアップアップを取って、編集。

sudo cp -p /etc/my.cnf.d/server.cnf /etc/my.cnf.d/server.cnf.org 
sudo cp -p /etc/my.cnf.d/client.cnf /etc/my.cnf.d/client.cnf.org 

sudo vi /etc/my.cnf.d/server.cnf

・
・
# This group is only read by MariaDB servers, not by MySQL.
# If you use the same .cnf file for MySQL and MariaDB,
# you can put MariaDB-only options here
[mariadb]
# ----- 2026/05/01 -----
character-set-server = utf8mb4
collation-server     = utf8mb4_unicode_ci
・
・

sudo vi /etc/my.cnf.d/client.cnf

・
・
#
# These two groups are read by the client library
# Use it for options that affect all clients, but not the server
#
[client]
# ----- 2026/05/01 -----
default-character-set = utf8mb4
・
・

再起動と確認

sudo systemctl restart mariadb
sudo systemctl status mariadb

mysql -u root -p[パスワード]
mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 3
Server version: 11.4.10-MariaDB MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show variables like "chara%";
+--------------------------+------------------------------+
| Variable_name            | Value                        |
+--------------------------+------------------------------+
| character_set_client     | utf8mb4                      |
| character_set_collations |                              |
| character_set_connection | utf8mb4                      |
| character_set_database   | utf8mb4                      |
| character_set_filesystem | binary                       |
| character_set_results    | utf8mb4                      |
| character_set_server     | utf8mb4                      |
| character_set_system     | utf8mb3                      |
| character_sets_dir       | /usr/share/mariadb/charsets/ |
+--------------------------+------------------------------+
9 rows in set (0.002 sec)

MariaDB [(none)]> quit
Bye

utf8mb4 になっていることを確認します
もし、「latin1」とかになっていた場合には、再起動「sudo systemctl restart mariadb」で反映されます。

WordPress環境構築まとめ

Apache

コピペで設定できるように、まとめます
詳細は、こちらを参照してください

RockyLinux9.３で自宅サーバーを再構築V04・LAMPの「A」、Apache編

LAMPの「A」のApacheの構築編です。 インストール、セキュリティ対策、ファイヤーウォール、https化、HTTP2通信設定を説明します。 さらに例では、CGIも動作できるような設定にしています。

www.kazuban.com

2024.01.06

Remi リポジトリのインストール

ApacheやPHPの最新バージョンにも対応したいので、Remi リポジトリのインストールします
Remiのインストールには、「crb」や「epel」のインストールが必要なようです

sudo dnf config-manager --set-enabled crb
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-next-release-latest-9.noarch.rpm

httpdインストール

続いて、httpd関連をインストールし、自動起動するように設定します

sudo dnf install httpd httpd-tools mod_ssl
sudo systemctl start httpd
sudo systemctl enable httpd
sudo systemctl is-enabled httpd
sudo systemctl status httpd

● httpd.service - The Apache HTTP Server
     Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; preset: disabled)
     Active: active (running) since Sat 2026-04-18 17:24:47 JST; 54min ago

active (running)とservice; enabledで確認できます。

Firewalld に許可

「http」と「https」を許可します

sudo firewall-cmd --add-service=http --zone=public --permanent
sudo firewall-cmd --add-service=https --zone=public --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --list-all --zone=public

「services: 」で確認できます

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: wlp8s0
  sources:
  services: cockpit dhcpv6-client http https ssh

ブラウザのアドレスバーにIPアドレス「http://192.168.*.*」をに入力すれば、テストページが表示されれば動作しています

httpd.conf

サーバー上のディレクトリや、ホスト名など、自分の環境に合わせて設定ファイルを編集します
筆者の場合、「DocumentRoot」を「/home/www/html」に変更します
「ServerName」は、バックアップ用なので本サーバーとの識別のためドメイン名は
「www2」とし「www2.hogehoge.com」に設定します
CGIスクリプトを使用する場合では、AddHandlerでスクリプトの拡張子を指定し、ScriptAlias以外のディレクトリにスクリプトを置く場合には、その指定ディレクトリに「Options ExecCGI」を追加します
まずは、設定ファイル「httpd.conf」はバックアップを取ってから作業します

cd /etc/httpd/conf/
sudo cp -p httpd.conf httpd.conf.org
sudo vi ./httpd.conf

edhitor

#ServerAdmin root@localhost
ServerAdmin root@localhost

#ServerName www.example.com:80
ServerName www2.hogehoge.com:80

#DocumentRoot "/var/www/html"
DocumentRoot "/home/www/html"

#<Directory "/var/www">
<Directory "/home/www">

#<Directory "/var/www/html">
<Directory "/home/www/html">

#ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
ScriptAlias /cgi-bin/ "/home/www/cgi-bin/"

#<Directory "/var/www/cgi-bin">
<Directory "/home/www/cgi-bin">

#Options Indexes FollowSymLinks
Options FollowSymLinks

#AddHandler cgi-script .cgi
# --- 2026/04/19 add by kazuban
AddHandler cgi-script .cgi
<Directory /home/www/html/script>
  AllowOverride None
  Options ExecCGI FollowSymLinks
  Order allow,deny
  Allow from all
</Directory>

筆者の場合、デフォルトにディレクトリを変更したので、そのディレクトリを作成し、所有者をapacheに変更します

sudo mkdir /home/www
sudo mkdir /home/www/html
sudo mkdir /home/www/cgi-bin
sudo chown apache.apache /home/www/html/
sudo chown apache.apache /home/www/cgi-bin/
ls -la /home/www
httpd -t

「Syntax OK」が出れば、正常に変更されています

セキュリティ対策

・テストページや「icons」一覧を非表示にする
・Apacheバージョン情報とＴRACEメソッドOFF
・X-Frame-Optionsの有効を確認
・設定したドキュメントルートにindex.htmlを作成

cd /etc/httpd/conf.d
sudo cp -p welcome.conf welcome.conf.org
sudo cp -p  autoindex.conf  autoindex.conf.org
sudo vi ./welcome.conf

表示させたくないので、削除や名前変更もできますが、自動的に復活するらしいので、<Directory>設定は、全てコメントにしました。
autoindex.confも同様です

sudo vi autoindex.conf

httpdを再起動すると、「http://192.168.*.*」は表示されなくなっていれば正常です

sudo systemctl restart httpd

さらに、Apacheバージョン情報とＴRACEメソッドもOFFにします
/etc/httpd/conf/httpd.confを編集

sudo vi /etc/httpd/conf/httpd.conf

最終行に、設定コードを追加

##--- kazuban added. 2026/04/19
ServerTokens ProductOnly
ServerSignature off
TraceEnable off

構文チェックしOKであれば、再起動します

httpd -t
sudo systemctl restart httpd

X-Frame-Optionsは、Webサイトを不正な埋め込み（クリックジャッキング攻撃）から守るために非常に重要だと言うことなので、こちらも有効になっているか確認します
「/etc/httpd/conf.modules.d/00-base.conf」に、mod_headers.soの記載があればモジュールは入っています

cat /etc/httpd/conf.modules.d/00-base.conf | grep mod_headers.so

次に、「/etc/httpd/conf/httpd.conf」の最後に、
「 Header append X-FRAME-OPTIONS “SAMEORIGIN” 」
を追加して、apacheを再起動します

sudo vi /etc/httpd/conf/httpd.conf

・
・
##--- kazuban added. 2026/04/19
ServerTokens ProductOnly
ServerSignature off
TraceEnable off

Header append X-FRAME-OPTIONS "SAMEORIGIN"

sudo systemctl restart httpd
sudo systemctl status httpd

ドキュメントルートのトップページの表示

上記セキュリティ対策でトップページが表示されなくなったので、「index.html」を作成し、簡単な表示が出るようにしておきます。

cd /home/www/html/
cat <<EOF | sudo tee index.html
<html>
  <body>
    <h1>This website is currently under maintenance.</h1>
  </body>
</html>
EOF
sudo chown apache:apache ./index.html
httpd -t
sudo systemctl restart httpd

これで、「http://192.168.*.*」でトップページが表示されるようになりました

Let’s Encrypt証明書でhttps化

https化を行う場合には、ファイヤーウォールでの許可が必要ですが、上記ですでに許可してますから、ここでは確認だけ行います

sudo firewall-cmd --list-all --zone=public

「services: 」に「https」があれば、許可済みです

sslモジュール

「mod_ssl」も、上記でインストールされています、確認してみます

dnf list installed | grep mod_ssl
httpd -M | grep ssl

Certbot クライアントのインストール

Let’s Encryptで証明書の取得には、「Certbot」と言うソフトを利用します
パッケージの状態を確認します

dnf list --all | grep certbot

複数でてきますが、「certbot.noarch」「python3-certbot-apache.noarch」をインストールします

sudo dnf install certbot
sudo dnf install python3-certbot-apache
dnf list installed | grep certbot

証明書発行

すでにhttpdが動作している場合には、「webroot プラグイン」を使います
動作していない場合には、「Standaloneプラグイン」を使います
ただし、両方とも外部から対象のPCの80番ポートへ通信は必要です
したがって、外部（インターネット側）から、対象のドメインのが名前解決が必要です
私は、無料のサービスhttps://www.mydns.jp/　を利用させてもらっています
80番ポートは「Standalone」の場合は、certbot が占有します
「webroot」は、apacheが使います
したがって、「webroot」はwebサーバーが動作している必要がありますが、「Standalone」では停止しておく必要があります

まず、外部からの80番へのリクエストが、対象のPCアドレスへ転送されるように設定します
自宅であれば、ルーターの「ポートマッピング」などの項目で設定できると思います
次に、httpdの起動状態を確認

sudo systemctl status httpd

80番と、httpdの起動が確認できたら、certbot を起動しましょう
確認はしていませんが、権限が必要なファイルに書き込むので、「su」での起動がいいと思います

su
certbot certonly --webroot -w /home/www/html/ -d www2.hogehoge.com -d hogehoge.com

対話での設定になります

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Enter email address (used for urgent renewal and security notices)
 (Enter 'c' to cancel): 　　　　　<------自分のEメールアドレスを入力

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
 https://letsencrypt.org/documents/LE-SA-v1.3-September-21-2022.pdf. You must
agree in order to register with the ACME server. Do you agree?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: y　<----- 利用規約を読んでください

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing, once your first certificate is successfully issued, to
share your email address with the Electronic Frontier Foundation, a founding
partner of the Let's Encrypt project and the non-profit organization that
develops Certbot? We'd like to send you email about our work encrypting the web,
EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: y  <--------- 電子フロンティア財団からEメールが届いてもいいか？
Account registered.
Requesting a certificate for www2.hogehoge.com and hogehoge.com

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/www2.hogehoge.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/www2.hogehoge.com/privkey.pem
This certificate expires on 2026-07-18.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

「Successfully」になれば、証明書ファイルは保管されています

証明書の設定

証明書を「/etc/httpd/conf.d/ssl.conf」で反映させます
まずは、バックアップをとってから、編集します

cd /etc/httpd/conf.d
sudo cp -p ssl.conf ssl.conf.org
sudo vi ./ssl.conf

/etc/httpd/conf.d/ssl.conf

・
#SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateFile /etc/letsencrypt/live/www2.hogehoge.com/fullchain.pem       
・
・
#SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
SSLCertificateKeyFile /etc/letsencrypt/live/www2.hogehoge.com/privkey.pem
・

保存後、確認でOKなら、httpd再起動

sudo httpd -t
sudo systemctl restart httpd
sudo systemctl status httpd

https:// でのアクセス確認

証明書発行では80番ポーとを通しましたが、httpsでは443ポートを通してておきます
ただし、筆者の環境のように、同じLAN上にWebサーバーとアクセスPCがある場合には外部DNSを使用しないので、アクセスできない場合があります
その場合、アクセス側PCの「hosts」ファイルで設定しておくと可能になります

C:\Windows\System32\drivers\etc\hosts　(windows)

#Server 
192.168.1.100 hogehoge.com
192.168.1.100 www.hogehoge.com

#TestServer
192.168.1.101 www2.hogehoge.com

この設定後、「https://www2.hogehoge.com」で正常に「index.html」画面が表示されれば証明書は正常です

HTTP/2を利用する

詳細は、こちらを確認してください
まず、eventMPMモジュールとhttp2モジュールが必要ですが、Rocky9では、デフォルトで有効になっているようです。
確認してみます

sudo httpd -M | grep mpm
sudo httpd -M | grep http2

次に、「httpd.conf」で有効設定する予定ですが、設定前にhttp2の有効状態を確認してみました
確認は、Chromeで「https://www2.hogehoge.com」を表示後、F12キーで表示される開発ページの「Network」「Protocol」で確認できますが、筆者の環境ではすでに「h2」になっていて、http2が有効になっていました。
AIに聞いてみると、Apacheのバージョンによっては、有効になっている場合もあるが、明示的に設定をいれる事を推奨するの事なので、設定はしておこうと思います

設定は、「/etc/httpd/conf/httpd.conf」で行います

sudo vi /etc/httpd/conf/httpd.conf

最終行に追加して、httpdを再起動

・
<IfModule http2_module>
    Protocols h2 http/1.1
    ProtocolsHonorOrder on
</IfModule>
・

sudo systemctl restart httpd

HTTP/2有効確認

Chromeで「https://www2.hogehoge.com」を表示後、F12キーで表示される開発ページの「Network」「Protocol」で確認できますが、「Protocol」が表示されていない場合があります
・開発ページが表示された後、CTRL+R でページを更新
・もし、翻訳のダイアログが出た場合には、「日本語」にしてみます

・開発ページが更新されても、デフォルトでは「Protocol」が非表示になっている場合があります
・「Network」タブの、「Name」セル上でマウス右ボタンで、表示項目の選択ができるので「Protocol」をチェックする事で、表示されます

・表示された「Protocol」が、「h2」や「h3」になっていれば、HTTP/2で応答しています

WordPress環境構築まとめ

Ubuntu24.04LTSでWorrPressを動作させる。インストール・SSH・ファイヤーウォール

「Ubuntu24.04LTS」に、「RHEL系、RockyLinux9」と同様の設定で、「WordPress」を動作させます。 特に、「apache」の設定方法が違っているので戸惑いました。 「RHEL」から移行の方には参考になると思います。

www.kazuban.com

2024.06.29

会社でもローカル環境にwordpressでのコミュニティサイトを検討しているので、wordpress環境構築作業に戸惑わないよう、コピペできるよう、まとめました。
せっかくなので、RockyLinux10で試してみましたが、筆者の１０数年前のノートPCではインストーラさえ起動しませんでした
RockyLinux9.7であれば起動したので、クリーンインストールして再構築しました

RockyLinux9.7 ダウンロード・インストール

ダウンロード・インストールの詳細はこちらを確認してください

RockyLinux9.3で自宅サーバーを再構築V01・インストール。記事最後のリンクをすべて実行すれば、WordPressサイトが作れます

2023年、このサイトは、centOS7 で構築していますが、サポート終了が近づいてきました。 centOS8のサポートも既に終了しています。 今回、RockyLinux9.3で再構築した記録のインストール編です。 記事最後のリンクをすべて実行すれば、WordPressサイトが作れます

www.kazuban.com

2024.01.05

有線デバイスを認識しない

wifiを利用していたので、あまり意識しませんでしたが、wifiでのトラブルがあったので、有線LANを利用しようとしましたが、認識しない状況になりました。
AIに聞きながらどうにか解決したので、ここに覚書としてメモしておきます

インターフェースの確認:

nmcli device

通常、正常であればここに enp... や eth0 といった名称のデバイスが表示されますが
リストに出てきませんでした。
AIに相談すると

リストにないということは、設定の問題ではなく「ドライバが読み込まれていない」か「ハードウェアが認識されていない」可能性が極めて高いです。
次の結果を教えてください

lspci -nn | grep -i net

$ lspci -nn | grep -i net

08:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter [10ec:8176] (rev 01)

09:00.0 Ethernet controller [0200]: JMicron Technology Corp. JMC250 PCI Express Gigabit Ethernet Controller [197b:0250] (rev 05)

原因が特定できました。搭載されている有線LANコントローラー 「JMicron JMC250 [197b:0250]」 は、Rocky Linux 9 (RHEL 9) の標準カーネルではサポート（ドライバが同梱）されていません。

JMicron用ドライバのインストール

JMicron JMC250 [197b:0250]」 は、ELRepo リポジトリからドライバを提案してもらいましたが、結局、Rocky Linux 9 (EL9) 用には JMicron [197b:0250] のドライバが提供されていない ようです

「ELRepo-kernel」から最新カーネルを試す（成功率：中）

成功率は「中」ですが、新しいカーネルには、稀に古いドライバが復活していたり、汎用ドライバで動く可能性があるとの事なので、やってみます

# 最新カーネルのインストール
sudo dnf --enablerepo=elrepo-kernel install kernel-ml

# 再起動して、起動メニューで新しいカーネル（数字が大きい方）を選択
sudo reboot

再起動後に nmcli device を確認

nmcli device

DEVICE          TYPE      STATE            CONNECTION     
wlp8s0          wifi      接続済み         aterm-e41133-g 
lo              loopback  接続済み (外部)  lo             
enp9s0f0        ethernet  切断済み         --             

認識されました

ethernetデバイスを接続する

接続は「nmcli device connect デバイス名」で接続できます

sudo nmcli device connect enp9s0f0

その他、ネットワーク設定は、下記を参考にしてください

RockyLinux9.3で自宅サーバーを再構築V01・インストール。記事最後のリンクをすべて実行すれば、WordPressサイトが作れます

2023年、このサイトは、centOS7 で構築していますが、サポート終了が近づいてきました。 centOS8のサポートも既に終了しています。 今回、RockyLinux9.3で再構築した記録のインストール編です。 記事最後のリンクをすべて実行すれば、WordPressサイトが作れます

www.kazuban.com

2024.01.05

インストール直後の設定

ホームディレクトリの日本語表記を英語表記に変更

linux

LANG=C xdg-user-dirs-gtk-update

特定のユーザーにsudo を可能にする

linux

su
visudo

visudo で、コメント行になっている、下記の「#」を外し有効にします
%wheel ALL=(ALL) NOPASSWD: ALL

linux

・
・
## Allows people in group wheel to run all commands
%wheel  ALL=(ALL)       ALL

・
## Same thing without a password
%wheel  ALL=(ALL)       NOPASSWD: ALL

その後、特定ユーザーを、「wheel」グループに追加すればそのユーザーはパスワードなしで「sudo」実行が可能になります

linux

usermod -aG wheel hogehoge

SSH利用状況の確認

RockyLinux9では、ほとんどの選択でsshは自動起動している状態になっています。
動作は、「ssh」コマンドで確認できます

linux

ssh

usage: ssh [・・・・」のような
コマンドの使い方を示すヘルプメッセージが表示されれば動作しています
また、sshサービスはファイヤーウォールでの制限対象ですが、こちらも標準では許可されていますが、確認しておきます
詳細は、下記記事を参照してください

RockyLinux9.３で自宅サーバーを再構築V03・firewalldでアクセス制御

firewalldを少し詳しく調べていました。 一例として、sshサービスを、LAN内（指定アドレス）からのみ接続可能な設定にしました。

www.kazuban.com

2024.01.06

ここでは、sshの許可状態だけ確認します

firewalldでのsshの確認

まず、「firewalld」の起動状態を確認してみます

linux

systemctl status firewalld

これで、active (running)になっていれば、起動しています

ファイヤーウォールのアクセスルール対象となるのはアクティブゾーンになります
まずは、アクティブゾーンを確認します

linux

 sudo firewall-cmd --get-active-zones

public
  interfaces: wlp8s0

アクティブゾーンは「public」のみと言うのがわかりました
今回は「ssh」の許可状態は「public」の設定で確認すればわかります

linux

sudo firewall-cmd --list-all --zone=public

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: wlp8s0
  sources: 
  services: cockpit dhcpv6-client ssh
  ports: 

「services」に、「ssh」があるので、許可されています

SSHでリモート操作

上で確かめたように、RockyLinux9では、デフォルトでsshサービスもファイヤーウォールでの許可も利用可能な状態になっています。
「ssh」コマンドでアクセスしてみましょう。
windowslinux

ssh hogehoge@192.168.*.* -p 22

ssh 「Linux側のユーザー@IPアドレス」 でパスワード入力で接続できます
「-p 22」は、ポート番号指定です。sshはデフォルトでは２２番ポートです。
デフォルトであれば、省略できます。
「-p 22」はオプションですが、違うポート番号の場合は、その番号を指定します。
また以前ポート番号などを変更していたなどで接続できない事もあります
その場合には、標準ポート番号「22」を指定する事で接続できるようになります
windowsターミナルでも同じコマンドです
接続ができれば、windowsから、Linuxマシンを殆どリモートで設定できます　
ローカル内だけでの運用であれば、この設定でもいいかもしれませんが、後ほどポート番号変更と鍵認証方式に変更しようと思います

インストール後の設定２（SSHでも可）

まずは、パッケージのアップデート

sshアクセスができれば、windowsターミナルからでも操作できまます
インストール初期のアップデートで、依存関係の競合とかでエラーが表示される事があります
エラーメッセージでは、「--skip-broken」の付加のアドバイスが出ますが、ついでに「–allowerasing」オプションも追加したほうがいいようです

linux

sudo dnf update --skip-broken --allowerasing
sudo reboot

SELinuxに強制させない設定

SELinuxはセキュリティをより強固にする機能で、RockyLinuxなどRedHat系では標準で有効になっていますが、思うように動作しないトラブルも多いようです。
ポリシーを読み込まず、無効的な状態にする方法もありますが、警告のみでポリシーを強制しない「Permissiveモード」に設定にしようと思います

linux

su
vi /etc/selinux/config

editor

・
・
#SELINUX=enforcing
SELINUX=permissive
・
・

linux

reboot

再起動後、確認

linux

sudo getenforce

「Permissive」が返ってくれば、設定されています

設定中に本体のGUIがクラッシュした

外部PCからsshで操作していて、たまに戻ると、画面がクラッシュしている場合があります
これはGUIのディスプレイマネージャー（gdm）がロックやスリープ状態になっているか、セッションがクラッシュしている場合に起こるようです

復旧方法：キーボードショートカットで復旧

私の状況は、マウスカーソルだけが動く状態だったので、その画面で：

• Ctrl + Alt + F2（または F3〜F6）を押す → テキストコンソールに切り替え
• ログイン後、以下を実行：

linux

systemctl restart gdm

Ctrl + Alt + F1（または F7）でGUI画面に戻る

恒久対策として：スリープ・省電力設定を無効化する

linux

# GNOMEのスクリーンセーバー・自動サスペンドを無効化
sudo -u ユーザー名 gsettings set org.gnome.desktop.screensaver lock-enabled false
sudo -u ユーザー名 gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'

このコマンドは、私の環境でSSH経由では、X11のDISPLAY環境変数がないとのエラーになりました
ssh経由の場合には、DISPLAY変数を指定して実行します

ssh

sudo -u ユーザー名 DISPLAY=:0 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$(id -u ユーザー名)/bus gsettings set org.gnome.desktop.screensaver lock-enabled false
sudo -u ユーザー名 DISPLAY=:0 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$(id -u ユーザー名)/bus gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'

確認方法

linux

sudo -u ユーザー名 DISPLAY=:0 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$(id -u ユーザー名)/bus gsettings get org.gnome.desktop.screensaver lock-enabled
sudo -u ユーザー名 DISPLAY=:0 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$(id -u ユーザー名)/bus gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type

下記の結果がでれば、正常に反映されている

false
'nothing'

CUIモードをデフォルトにする

SSH経由でのリモートがほとんどになれば、CUIモードのほうがトラブルは少なそうなので、CUIモードに設定します

linux

sudo systemctl set-default multi-user.target

これで、再起動後はGUIなしで起動します。
もし、GUIが必要になったら、

linux

sudo systemctl start gdm

再度GDMを停止させCUIに戻るには、サーバー機で操作できる場合には

Ctrl + Alt + F2

または、リモートも含めたコマンド操作の場合は

sudo systemctl stop gdm

このコマンド操作で、画面が止まったように見える場合は、サーバー機で

上記の Ctrl + Alt + F2

SSHのセキュリティ向上対策

SSHを鍵認証方式で運用

「鍵認証方式」は、「秘密鍵」と「公開鍵」のペアの鍵を作成し、アクセスする側は「秘密鍵」が必要になり、アクセスされる（サーバー）側には、「公開鍵」を登録します
一般的には、アクセス側で鍵を生成し、「公開鍵」の登録をサーバーへお願いします
鍵生成は、windowsでもLinuxでも、「ssh-keygen」コマンドで生成できます
今回は、windowsターミナルで生成します

windowslinux

ssh-keygen -t ed25519

Generating public/private ed25519 key pair.
Enter file in which to save the key (C:\Users\hogehoge/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again
Your identification has been saved in C:\Users\hogehoge/.ssh/id_ed25519
Your public key has been saved in C:\Users\hogehoge/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:o2ojnUu7UflR12VZq2yOcTY/Ky-VzibafGh/PJbPe6C hogehoge@hoge-Pc
The key's randomart image is:
+--[ED25519 256]--+
|             .+.o|
|               Oo|
|     o + o .   . |
|    . Z   . . o..|
|    . o     . *AC|
+----[SHA256]-----+

秘密鍵のアクセス権限を厳しく設定

下記のアクセス権の設定は、windowsターミナルでの操作コマンドです。
Linuxでの操作は、こららを参考にしてください

継承の無効化と権限のクリア

windows

icacls "$HOME\.ssh\id_ed25519" /inheritance:r

ユーザーにのみ読み取り権限を付与

windows

icacls "$HOME\.ssh\id_ed25519" /grant:r "$($env:USERNAME):R"

「自分自身」以外のユーザー権限を削除

windows

icacls "$HOME\.ssh\id_ed25519" /remove "SYSTEM"
icacls "$HOME\.ssh\id_ed25519" /remove "Administrators"
icacls "$HOME\.ssh\id_ed25519"

エクスプローラの「プロパティ」⇒「セキュリティ」でも確認できます

公開鍵をサーバー側へコピー

作成した、「id_ed25519.pub」をサーバー側ユーザーの「.ssh」ディレクトリへコピー
・windowsの自分自身のホームの「.ssh」に移動
・scp コマンドへ、サーバー側ユーザーの「.ssh」へコピー

windows

cd $HOME\.ssh
scp .\id_ed25519.pub hogehoge@192.168.*.*:.ssh

サーバー側へsshでログインし操作

windows側から、sshログインし、「.ssh」ディレクトリへ移動し確認

windows

ssh hogehoge@192.168.*.*

ログイン後、コピーされているか、確認

sshlinux

cd ./.ssh
ls -la

公開鍵を保存ファイル（authorized_keys）へ登録

コピーされた公開鍵を、保存用のファイルへ登録し、そのファイルのアクセス権は厳しくします
持ってきて、公開鍵は削除しておきます

sshlinux

cd ~/.ssh 
cat id_ed25519.pub >> authorized_keys 
chmod 600 authorized_keys
rm id_ed25519.pub
exit

再度、鍵を使って、SSHログイン

ssh に「i」オプションで鍵指定

windows

ssh -i .ssh/id_ed25519 hogehoge@192.168.*.*

ログイン時、鍵生成時登録したパスフレーズを入力し、ログイン

鍵認証以外ではログイン拒否

鍵を使ってのログインが確認できたら、鍵以外でのログインは拒否する設定をしておきます
設定は、「/etc/ssh/sshd_config」ファイルの”PasswordAuthentication”を”no”に設定します
まずは、ファイルをバックアップして、編集します

ssh linux

sudo cp -p /etc/ssh/sshd_config /etc/ssh/sshd_config.org
sudo vi /etc/ssh/sshd_config

editor

・
・
#PasswordAuthentication yes
PasswordAuthentication no
・
・

ついでにリモートからのROOTログインも拒否設定します

「/etc/ssh/sshd_config」ファイルの”PermitRootLogin”も”no”に設定

editor

・
・
#PermitRootLogin prohibit-password
PermitRootLogin no
・
・

さらに、ポート番号を変更

「ssh」のポートは「22番」が標準なので、自動スキャンなどのアタックが増えるので、違う番号に変更しておきます。
ポート番号も「/etc/ssh/sshd_config」ファイルの”Port”で設定します
ポート番号は登録済み番号などもあるので、49152–65535の範囲に設定します

editor

・
・
#Port 22
Port 55522
・
・

「22番」は「ssh」サービスのデフォルトなので、firewalldの設定でsshは「22番」になります
firewalld設定は、ポート番号を直接設定する事もできますが、やはりsshのポート番号を変更する方法がfirewalldは再起動だけで、設定は不要なのでスマートだと思います
デフォルト設定は、「 /usr/lib/firewalld/services/ ssh.xml 」に保存されているので、
そのファイルを「 /etc/firewalld/services /」にコピーして編集します。

ssh linux

sudo cp -p /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services/
sudo cd /etc/firewalld/services/
sudo ls /etc/firewalld/services/
sudo vi /etc/firewalld/services/ssh.xml

editor

・
・
<port protocol="tcp" port="22"/>
↓
<port protocol="tcp" port="55522"/>
・
・

sshとfirewall　サービスを再起動して、アクセスにはポート番号を明示します

ssh linux

sudo systemctl reload sshd.service
sudo firewall-cmd --reload
ssh  -p 55522 hogehoge@192.168.*.*

ここまでで、RockyLinux9.7のインストールと、やっておきたい初期設定を解説しました
「ssh」の設定も完了しているので、windowsターミナルからでも実行できます

WordPress環境構築まとめ

Difyをクローン化

gitの確認

difyをクローン化するのに、「git」を利用するので、「git」のインストール状況を確認します。
windows ターミナルを開き、wsl を起動し、「git -v」で状況を確認します。

PS C:\Users\hogehoge2> wsl

$ git -v
git version 2.43.0
インストールされていない場合には、インストール
$ sudo apt update
$ sudo apt install git

Gitでdifyをクローン化する

「git clone ・・」でクローン化を実行すると、カレントディレクト下「dify」ディレクトリへソースコードがクローン化されます。
windowsターミナルで、「wsl」を実行し、ubuntu環境へ入ると、デフォルトでは、winndowsユーザーのディレクトリへセットされた状態で起動します。
好みの問題だと思いますが、この場所へ「dify」環境を作成してもいいと思いますが、筆者はubuntuのユーザーホームディレクトリ下に作成しようと思います。
wsl、ubuntuプロンプトで、「cd」を実行すると、ユーザーのホームディレクトリへ移動します。
その場所で「git clone・・」すると、そのディレクトリ直下に「dify」さらにその下に「docker」ディレクトリが作成されています。
「ls」コマンドで確認できます。
「dify/docker」ディレクトリへ「cd」コマンドで移動しておきます。
「pwd」コマンドで、現在のディレクトリが確認できます。

hogehoge2@hoge-PC:/mnt/c/Users/hogehoge2$
$ cd
$ git clone https://github.com/langgenius/dify.git
Cloning into 'dify'...
remote: Enumerating objects: 153846, done.
remote: Counting objects: 100% (536/536), done.
remote: Compressing objects: 100% (359/359), done.
remote: Total 153846 (delta 396), reused 178 (delta 177), pack-reused 153310 (from 3)
Receiving objects: 100% (153846/153846), 87.73 MiB | 5.07 MiB/s, done.
Resolving deltas: 100% (111131/111131), done.
$ ls
dify
$ cd dify/docker/
$ pwd
/home/hogehoge2/dify/docker

Difyコンテナ起動

「git clone」を実行したディレクトリに、「dify/docker」ディレクトリが作成されています。
その中に「.env.example」のサンプル環境変数ファイルが作成されています。
通常ファイルは「ls」コマンドで確認できますが。「.」で始まるファイルは表示されません。
その場合「ls -la」コマンドを実行すると、表示されます。
コピーは「cp <オリジナルファイル名>　<複写ファイル名>」で複写できます。
「.env.example」ファイルを、正式な環境変数「.env」としてコピーし、「docker compose」コマンドで、コンテナを起動させます。

$ pwd
/home/hogehoge2/dify/docker
$ cp .env.example .env
$ docker compose up -d
[+] Running 80/80    
✔ web Pulled             149.7s
✔ sandbox Pulled         221.1s
 ✔ ssrf_proxy Pulled      88.2s
 ✔ db Pulled             224.4s
 ✔ worker Pulled         402.2s
 ✔ plugin_daemon Pulled  404.6s
 ✔ nginx Pulled           36.4s
 ✔ weaviate Pulled       225.1s
 ✔ redis Pulled          221.2s
 ✔ api Pulled            402.2s
[+] Running 12/12
 ✔ Network docker_default             Created    0.1s
 ✔ Network docker_ssrf_proxy_network  Created    0.0s
 ✔ Container docker-web-1             Started    3.7s
 ✔ Container docker-ssrf_proxy-1      Started    4.0s
 ✔ Container docker-sandbox-1         Started    3.7s
 ✔ Container docker-redis-1           Started    3.7s
 ✔ Container docker-weaviate-1        Started    3.7s
 ✔ Container docker-db-1              Healthy    10.7s
 ✔ Container docker-worker-1          Started    9.3s
 ✔ Container docker-plugin_daemon-1   Started    9.3s
 ✔ Container docker-api-1             Started    9.5s
 ✔ Container docker-nginx-1           Started    10.0s

docker compose upでエラー発生！AIに聞いてみる。

上記は正常な例ですが、古いPCをテストマシンとして利用した時、「docker compose up」で下記エラーがでた事がありました。

dependency failed to start: container docker-db-1 is unhealthy

この時もgeminiに聞いてみたところ、「docker logs docker-db-1」でログを確認してくれとの事なので、ログを直接貼り付けると、

Ai

ログを見る限り、データベースの初期化自体は正常に完了しています (PostgreSQL init process complete; ready for start up.)。 その後の起動プロセスも進んでいますが、2025-04-29 00:02:07.998 UTC [557] FATAL: the database system is starting up という致命的なエラーが出力されています。

このエラーは、PostgreSQLサーバーが起動してリカバリなどの内部処理を行っている最中に、外部からの接続要求（この場合はおそらくDockerのヘルスチェックや、依存するDifyコンテナからの初期接続試行）があった場合に発生することがあります。

つまり、データベースサーバー自体は最終的に database system is ready to accept connections の状態になりますが、Dockerのヘルスチェックがサーバーの準備が完全に整う前に接続を試み、上記の FATAL エラーを受け取ってしまい、それが原因でコンテナが unhealthy と判定されている可能性が高いです。

解決策:

Dockerのヘルスチェック設定を調整し、データベースが完全に起動して接続可能になるまで、チェックを待つように設定を変更するのが最も有効な対策です。

データベースサービス (db または postgresql) の healthcheck 設定を見つける:
services のセクションにある、データベースコンテナに対応するサービス定義（通常は db という名前）を探します。その中に healthcheck というブロックがあるはずです。

YAML
services:

db: # ... その他の設定 ...
healthcheck: # ここに設定があります
　　・
test: ["CMD-EXEC", "pg_isready -U <db_user> -d <db_name>"] # 例
interval: 10s
timeout: 5s
retries: 5
start_period: 30s # <-- この値を調整します

docker-compose.yml を開く: Difyを起動するために使用している docker-compose.yml ファイルをテキストエディタで開きます。

じじぃ

docker-compose.yamlを確認した所、「start_period:」の設定がありません。

Ai

start_period が指定されていない場合、コンテナが起動を開始すると同時にヘルスチェックが始まります。今回のデータベースのログで見たように、起動直後の一時的な準備期間中に接続を試みると FATAL: the database system is starting up のようなエラーが発生することがあります。

interval: 1s と非常に短い間隔でチェックが実行されるため、データベースが完全に準備できる前に多くのチェックが走ってしまい、すぐにリトライ回数（retries: 60）を使い果たして unhealthy と判定されてしまう可能性が高いです。

解決策:

start_period を追加し、必要に応じて interval も調整しましょう。

1. healthcheck 設定に start_period を追加する: データベースが起動して準備ができるまでの猶予期間として、start_period を設定します。
   例えば 30s または 60s (30秒または60秒) を指定します。
   YAML
   services:
db: # ... その他の設定 ...

healthcheck:
test: [ 'CMD', 'pg_isready', '-h', 'db', '-U', '${PGUSER:-postgres}', '-d', '${POSTGRES_DB:-dify}' ]
interval: 5s # 例: 毎秒ではなく5秒ごとにチェックに緩和
timeout: 3s
retries: 10 # 例: リトライ回数を調整 (intervalを長くすればretriesは少なくても良い)
start_period: 60s # <- この行を追加 (例: 60秒待つ)
   
   ポイント: start_period の間は、ヘルスチェックが失敗してもコンテナは starting 状態のままとなり、unhealthy とは判定されません。start_period が経過した後に初めて、ヘルスチェックの失敗が unhealthy の判定に使われます。
2. interval も少し長めにすることをお勧めします: interval: 1s は開発時などに素早く確認したい場合には便利ですが、本番に近い環境や安定性を重視する場合は 5s や 10s に設定することが一般的です。これにより、データベースへの不要な負荷も軽減されます。
3. docker-compose.yml を保存する。
4. Docker Compose を再起動する: 変更を反映させるために、コンテナを再作成して起動します。

アドバイス通りに、編集して再度「docker compose up -d」を実行すると、正常になりました。
いやぁ～、AIさまさま、ですね～
おそらく、ネット検索では、解決できなかったと思います。
ただし、古いPCだったのが、一番の原因かもしれません。
５年ほど前のPCでは、このエラーはでなかったので、レアなケースかもしれませんが、AIの利用例として紹介しました。

Dify起動

初期画面

「docker compose up」が正常に終了すると、Webブラウザで「http://localhost/install」へアクセスすると「dify」の初期設定が開きます

Difyの動作と試用

とりあえず、起動しました。
以前このサイトでも説明していますが、簡単なチャットボットを作成し試してみます。
LLMモデルはオンラインの「gemini」を登録し、動作を確認できました。
オンラインであれば、「LM Studio」や「Ollama」など、ローカルLLMを利用するアプリは必要ないので、すぐに確認できます。

Difyを自動起動

Difyを動作させるには、Dockerが起動していなくてはいけません。
それには、WSL上で、ubuntuも起動している必要があります。
手動でやる場合、

・windowsターミナル起動
・wslコマンドで、ubuntuターミナル起動
・ubuntuターミナルでカレントディレクトリを、Difyのクローンディレクトリに移動
・「docker compose up -d」 コマンド実行

このような手順が必要ですが、問題なのは、ターミナルを閉じるとdockerも終了してしまうことです
Difyを使うには、dockerが起動していなくてはいけません。
windowsアプリの「docker desktop」であれば、標準で自動起動設定だったと思いますし、起動後もシステムトレイのアイコンで起動が確認できます。右ボタンで状態確認や終了も簡単です。
ubuntu経由の場合には、GUIでの確認ができないので、ここが面倒なところですね～。
自動起動方法をいろいろ調べると、windowsバッチファイルを作成し、スタートアップフォルダに登録する事で、windows起動時に、自動起動できそうです。
ただ、
「コマンドプロンプト　⇒　ubuntuターミナル　⇒　docker」
のタスクが必要で、ターミナルは開いた状態にしておく必要があります。
このようなバッチファイルを作りたいですが、どんなコードにすればいいのか・・？
うまいコードを考え付かなかったので、difyの試しもかねて起動しているチャットボットで設定しているgeminiに考えてもらいました。

@echo off
title Starting Dify via WSL

echo Starting WSL and navigating to ~/dify/docker...
echo Running 'docker compose up -d'...
echo WSL window will remain open after commands.

REM WSLを起動し、bashシェル内でコマンドを実行します。
REM cd ~          : ホームディレクトリに移動 (念のため)
REM cd ./dify/docker : dify/docker ディレクトリに移動
REM docker compose up -d : docker compose をバックグラウンドで起動
REM exec bash     : 上記コマンド実行後、インタラクティブなbashシェルを開始して終了させない
wsl.exe -e bash -c "cd ~/dify/docker && docker compose up -d && echo '--- Dify containers started (or attempted to start) ---' && exec bash"

echo WSL window launched. This batch window can be closed if desired.
REM pause REM Optionally uncomment this line to keep the batch window open until a key is pressed

すごいです。
ほとんど実際の起動には影響がない「REM」や「echo」文がほとんどですが、
「REM」文を使っての説明文や、「echo」での実行中のメッセージにも手抜きがないですね！
このコードをコピーしてエディターで、「start_dify.bat」というファイルで保存しました。
バッチファイルの単独実行では問題ありませんでした。
後はこのファイルのショートカットを、スタートアップフォルダへコピーするだけです。

・上記の作成したバッチファイルを、適当は場所へ保存します
　私は、ユーザーフォルダ「C:\Users\「ユーザー」」へ保存しました。
・次に、このファイルのショートカットを作成します。
・このショートカットを「スタートアップフォルダ」へ保存します。
　スタートアップフォルダは、エクスプローラーのアドレスバーへ「shell:startup」と入力すると開くことができます。

特に必須ではないですが、ターミナルは起動状態にさせるので邪魔になる場合、作成したショートカットファイルを、マウス右ボタンで「プロパティ」を開きます。
「プロパティ」の「ショートカット」タブの「実行時の大きさ」を「最小化」に設定すると、起動時にタスクバーに最小化状態で起動できます。

これで、再起動すると、自動起動したターミナルはタスクバーへ最小化状態ですが、環境によっては起動途中の場合があるので、すぐに使用したい場合には、一度開いてDockerの状態を確認したほうがいいと思います。
正常に起動できると、Webブラウザのアドレスバーに「http://localhost/install」でdifyが起動できます。
場合によっては、「http://localhost/signin」にリダイレクトされる場合もあります

この画面が開くと、ローカルPCでは、Difyを利用する事ができますが、今回はサーバーとして利用したいので、LAN上の別のPCからのアクセスも必要です。

Difyをサーバー化して、他のPCからもアクセスさせる

同じLAN上であっても、「localhost」では、他のPCではアクセスできません。
前回後半で少し話題にしましたが、「windowsホスト」「WSL(ubuntu)」「Docker」と複雑な通信環境なので面倒です。

DifyPCのIPアドレス調査

IPアドレスは、windowsターミナルでは「ipconfig」コマンド
WSLターミナルでは、「ip addr」で確認できます。
この情報を、Aiに添付して聞いてみました。

Ai

詳細な情報ありがとうございます！ipconfig と ip a の結果から状況がより明確になりました。
原因の特定
・Windows ホスト:
　あなたの Windows PC の Wi-Fi アダプターには 192.168.0.94 という IP アドレスが割り当てられています。
　これはご自宅などの LAN 内の IP アドレスです。
・WSL (Ubuntu):
　Windows Subsystem for Linux (WSL) 環境内の Ubuntu には、eth0 インターフェースに 172.31.226.6 という IP アドレスが割り当てられています。
　これは WSL が使用する仮想ネットワーク内の IP アドレスです。

Ai

WSL2 環境で Docker コンテナを動かしている場合、Windows ホストからそのコンテナ内のサービスにアクセスするには、通常以下のいずれかのアドレスを使用します。
１．localhost:
　Windows ホストのブラウザで http://localhost/chat/…と入力する。
　WSL2 は localhost 経由でのポートフォワーディングをサポートしています。
　（これが最も一般的な方法です）
２．WSL の IP アドレス: http://172.31.226.6/chat/…
　(今回アクセスできている方法)

・http://192.168.0.94/chat/… でアクセスできないのは、WSL2 と Docker のネットワークアーキテクチャ上、自然なことです。
サービスが Windows ホストの物理的な IP アドレスに直接公開されているわけではないためです。
・もし、LAN 内の他の PC (例: 192.168.0.100) からもこの Dify 環境にアクセスしたい場合は、追加の設定が必要になる可能性があります:

１．Windows ファイアウォールの設定: Windows のファイアウォールで、外部からのポート 80 (または Dify が使用しているポート) への着信接続を許可する必要があります。
２．ポートフォワーディング (状況による): WSL2 のネットワーク設定によっては、Windows ホストの 192.168.0.94 のポート 80 へのアクセスを、WSL の 172.31.226.6 のポート 80 へ転送する設定が必要になる場合があります。
これは 「netsh interface portproxy」 コマンドなどで設定できますが、まずは localhost や WSL の IP でアクセスできることを確認するのが先決です。

要約:
・Windows ホストからアクセスする場合: http://localhost/chat/… または http://172.31.226.6/chat/… を使用してください。
・http://192.168.0.94/chat/… でアクセスできないのは仕様であり、問題ではありません。

Windowsのアドレスからは、アクセスできない。

じじぃ

http://localhost や http://172.31.226.6 からはアクセスできています。
今回は、LAN上の別のPCからhttp://192.168.0.94 にアクセスしたいため、自分PCで試したら、アクセスできませんでした

Ai

なるほど、LAN上の他のPCからアクセスできるようにしたい、ということですね。承知いたしました。

ご自身のPC (192.168.0.94) から http://192.168.0.94/chat/... にアクセスできなかったのは、まさにその設定がまだされていないためです。Windowsホストのネットワーク(192.168.0.x) と WSL内部のネットワーク (172.31.x.x) は分離されており、外部（LANを含む）から直接WSL内のサービスにアクセスするには、「ポートフォワーディング（ポート転送）」という設定が必要になります。

設定手順

以下の手順を管理者権限で実行してください。

1. Difyが使用しているポートを確認 (重要):
   • まず、DifyがWSL内でどのポート番号で待ち受けているか確認します。HTTPなので通常は 80番 ですが、Dockerの設定によっては異なるポート（例: 3000番など）がホスト(WSL)に公開されている場合があります。
   • Docker Composeを使っている場合は docker-compose.yml ファイルの ports: セクションを確認してください。例えば ports: - "80:80" や ports: - "3000:80" のようになっています。左側の数字がWSL側で公開されているポート番号です。
   • docker ps コマンドを実行しても確認できます。PORTS 列に 0.0.0.0:80->80/tcp や 0.0.0.0:3000->80/tcp のように表示されます。0.0.0.0: の後の数字がWSL側で公開されているポート番号です。
   • 以降の説明では、Difyがポート 80 を使用していると仮定します。もし異なるポート（例: 3000）だった場合は、コマンド内の 80 をその番号に読み替えてください。
2. Windows ファイアウォールでポートを開放:
   • LAN内の他のPCからのアクセスを許可するために、WindowsのファイアウォールでDifyが使用するポート（ここでは80番）を開ける必要があります。
   • 管理者としてPowerShellを開き、以下のコマンドを実行します。
     powershell New-NetFirewallRule -DisplayName "Allow Dify Access from LAN" -Direction Inbound -LocalPort 80 -Protocol TCP -Action Allow
     (もしコマンドプロンプトを使いたい場合は、管理者として開き netsh advfirewall firewall add rule name="Allow Dify Access from LAN" dir=in action=allow protocol=TCP localport=80 を実行)
3. ポートフォワーディングの設定:
   • Windowsホスト (192.168.0.94) のポート80に来た通信を、WSL (172.31.226.6) のポート80に転送するように設定します。
   • 管理者としてPowerShell（またはコマンドプロンプト）を開き、以下のコマンドを実行します。 powershell netsh interface portproxy add v4tov4 listenport=80 listenaddress=0.0.0.0 connectport=80 connectaddress=172.31.226.6
     • listenport=80: Windows側で外部からの接続を待ち受けるポート番号。
     • listenaddress=0.0.0.0: Windowsの全てのIPアドレス（192.168.0.94 を含む）で待ち受ける設定。特定のIP (192.168.0.94) だけを指定することも可能です。
     • connectport=80: 転送先のWSL内でDifyが待ち受けているポート番号。
     • connectaddress=172.31.226.6: 転送先のWSLのIPアドレス。
4. 動作確認:
   • 設定後、まずご自身のPCのブラウザから http://192.168.0.94/chat/84aj9r6azPSYjXt8 にアクセスできるか試してください。 (ポートが80以外の場合は http://192.168.0.94:ポート番号/chat/... のように指定)
   • アクセスできれば、LAN内の他のPCからも同じアドレス (http://192.168.0.94/chat/...) でアクセスできるはずです。

注意点:

• WSLのIPアドレスの変動: WSLを再起動すると、WSLのIPアドレス (172.31.226.6) が変わる可能性があります。もしアクセスできなくなった場合は、ip a コマンドでWSLの新しいIPアドレスを確認し、手順3のポートフォワーディング設定を一度削除して再作成する必要があります。
  • 削除コマンド: netsh interface portproxy delete v4tov4 listenport=80 listenaddress=0.0.0.0
  • 再作成コマンド: (新しい connectaddress を指定して再度実行)
• 管理者権限: ファイアウォールとポートフォワーディングの設定には管理者権限が必要です。
• ポート番号: Difyが使用しているポート番号を正確に確認し、コマンド内の 80 を適宜修正してください。

この手順で、LAN内の他のPCからアクセスできるようになるはずです。試してみてください。

docker ps コマンドで実行中のコンテナーを提出

じじぃ

docker ps では下記になっています。
$ docker ps
・・
・
・

Ai

docker ps の出力結果、ありがとうございます。

コンテナ docker-nginx-1 の PORTS 列にご注目ください。

PORTS
0.0.0.0:80->80/tcp, [::]:80->80/tcp, 0.0.0.0:443->443/tcp, [::]:443->443/tcp

これは、以下のことを意味しています。

• 0.0.0.0:80->80/tcp: WSLホスト（172.31.226.6 など）の ポート 80 (HTTP) へのTCP接続を、docker-nginx-1 コンテナ内部のポート 80 に転送する。
• [::]:80->80/tcp: 上記のIPv6版。
• 0.0.0.0:443->443/tcp: WSLホストの ポート 443 (HTTPS) へのTCP接続を、docker-nginx-1 コンテナ内部のポート 443 に転送する。
• [::]:443->443/tcp: 上記のIPv6版。

docker-web-1 コンテナ自体は内部的にポート 3000 を使っていますが、外部（WSLホスト）からのアクセスは docker-nginx-1 コンテナがポート 80 (HTTP) と 443 (HTTPS) で受け付けています。Nginx がリバースプロキシとして動作し、リクエストを docker-web-1 や docker-api-1 などに振り分けている構成です。

結論

あなたが LAN 上の他の PC からアクセスしたい HTTP のポート番号は 80 です。

したがって、先ほどのポートフォワーディング設定のコマンドは、ポート番号 80 を使って実行してください。

1. ファイアウォール開放 (ポート 80): New-NetFirewallRule -DisplayName "Allow Dify Access from LAN (HTTP)" -Direction Inbound -LocalPort 80 -Protocol TCP -Action Allow
2. ポートフォワーディング設定 (ポート 80):
   powershell netsh interface portproxy add v4tov4 listenport=80 listenaddress=0.0.0.0 connectport=80 connectaddress=172.31.226.6

これで、 http://192.168.0.94 (ポート80は省略可能) でアクセスできるはずです。

もし将来的にHTTPS (https://192.168.0.94) でアクセスしたい場合は、同様にポート 443 用のファイアウォールルールとポートフォワーディング設定を追加する必要があります。

ファイヤーウォールとポートフォワーディング設定

ファイアウォールを開放し、ポートフォワーディング設定をしろ、のアドバイスです。
教わったコードを実行してみます。

１．ファイアウォール開放 (ポート 80):

PowerShell
PS C:\Users\hoge2>　New-NetFirewallRule -DisplayName "Allow Dify Access from LAN (HTTP)" -Direction Inbound -LocalPort 80 -Protocol TCP -Action Allow

コントロールパネル→システムとセキュリティ→windows Defender ファイアウォール→詳細設定
受信の規則で
コマンドで指定したAllow Dify Access from LAN(HTTP)が設定されているのが、確認できます。
コマンドではなく、この画面で、GUI設定する事もできます。

2．ポートフォワーディング設定 (ポート 80):

管理者権限のPowerShell の、「netsh」コマンドで設定します。

PowerShell（管理者）
PS C:\Users\hoge2> netsh interface portproxy add v4tov4 listenport=80 listenaddress=0.0.0.0 connectport=80 connectaddress=172.31.226.6

「netsh interface portproxy show v4tov4」で確認できます。

PS C:\Users\hoge2> netsh interface portproxy show v4tov4
ipv4 をリッスンする:         ipv4 に接続する:
Address         Port        Address         Port
--------------- ----------  --------------- ----------
0.0.0.0         80          172.31.226.6    80

アクセスできた～

これで無事に「http://192.168.0.94/instal」でアクセスできました。
LAN上の別のPCからも、アクセス確認できました。
おそらく、ネット検索では、ここまで的確なアドバイスを見つけるのは至難の業だと思います。
ちょっと前までは、言語生成AIをうまく使うには、プロンプトが重要だと言われていましたが、最近の言語生成AIはかなり言語の理解力が向上していると感じます。
上記のじじぃの質問でもわかりますが、ほとんど「プロンプト」など意識していません。
とにかくわからない事やPCからの出力を、自分の言葉で質問しているだけです。
それでもかなり的確な回答をくれます。
たまには、間違った回答もありますが、それでエラーが発生した場合、そのエラーやログをそのまま突っ込めば、新たな回答をくれます。
すごい時代になりました。

DifyにLLMを設定して、カスタムチャット環境を構築

やっとDifyサーバーが起動できました。

次に、このDifyにLLMモデルを設定することで、チャットボットをはじめカスタムLLMアプリを開発する事ができるようになります。
左図の例では、
一番上の「Gemini」はオンラインで公開されているLLMです。
二番目は、「LM Studio」でダウンロードしたローカルLLMです。
三番目は、「Ollama」で読み込んでいるローカルLLMです。
このように、「Dify」ではオンライン、ローカルあまり意識せず、使用するLLMを自由にカスタマイズできます。

DifyにLLMの設定方法

ネット上でも、多くの情報があると思いますが、このサイトでも以前の記事で紹介しています。

オンラインLLMの登録

ローカルでDifyとLM_Studio を連携させ、ローカルでチャットボットを作る。

LM StudioとDifyをローカルで連携させたのでレポートします。記事を書いている時に、Dify設定にLM Studioのプラグインを発見したので、そちらの設定も追加してます。

www.kazuban.com

2025.03.23

LM Studio モデルの登録

ローカルでDifyとLM_Studio を連携させ、ローカルでチャットボットを作る。

LM StudioとDifyをローカルで連携させたのでレポートします。記事を書いている時に、Dify設定にLM Studioのプラグインを発見したので、そちらの設定も追加してます。

www.kazuban.com

2025.03.23

Ollama　モデルの登録

DifyとOllamaを連携させ、ローカルチャットボット環境を作る

前回はLM StudioとDifyの連携でしたが、今回は、Ollamaと連携させてみました。どちらもそれぞれ特徴があるので、使い分けてもいいと思います。 私的には、スタンドアローンで使うならLM Studio。Difyとの連携であればOllama かな？と思っています。

www.kazuban.com

2025.03.30

あとがき

Windowsアプリ「Docker Desktop」を使わず、「Ubuntu」にインストールした「Docker Engine」で「Dify」をサーバー化する方法を紹介しました。
「Docker Desktop」はWindows環境向けのツールであり、構築の手間は比較的少ないですが、Ubuntuサーバー上で動作させる際は、仮想化環境の設定やネットワーク通信の複雑さが生じるため、トラブルシューティングがやや難しくなります。
今回は、AIのアシストにより、Difyサーバーを構築することができました。
設定プロセスだけでなく、AIを活用した実践例として、このやり取りもご参考にしていただければ幸いです。

話題のDifyをインストールしてみた。失敗談あり。

話題のDifyをローカルインストールしてみました。普通にやれば何てことない作業ですが、余計な事したので時間がかかってしましました。

www.kazuban.com

2025.03.15

この状態では、「WSL」環境には、別途Linuxはインストールされていません。
「wsl -l -v」コマンドで確認できます。

PS C:\Users\hoge> wsl -l -v
  NAME              STATE           VERSION
* docker-desktop    Running         2

現在は、仮想環境として「Docker Engine」のみが動作し、そのコンテナとして「Dify」が動作しています。
この状態でも、「Dify」を利用する場合には問題ありませんが、せかっくの「WSL」なので「ubuntu」環境に「Docker」を構築し、「Dify」コンテナを構築し直そうと思います。
また、windowsアプリ「Docker Desktop」は、ライセンス的に完全オープンではありませんし、「Dify」もLinuxとの組み合わせのほうが、貧弱スペックマシンでは、パフォーマンスが向上しそうな気がしています。

Docker Desktop と WSLを完全アンインストール

再度、クリーンな状態から再インストールしたい場合もあると思います
gemini君に教えてもらった、クリーンインストール方法をメモしておきます。

Docker Desktop のアンインストール

★Docker Desktopのアンインストール
1. 「設定」アプリを開く:
　Windowsキー + Iキーを押すか、スタートメニューから「設定」を選択します。
2. 「アプリ」を開く:
　「アプリ」をクリックします。
3. 「アプリと機能」を開く:
　左側のメニューから「アプリと機能」を選択します。
4. Docker Desktopを選択してアンインストール:
　アプリの一覧から「Docker Desktop」を見つけて選択し、「アンインストール」をクリックします。
　画面の指示に従ってアンインストールを完了させます。

★ 関連するファイルの削除 (オプション)
Docker Desktopのアンインストール後、残りのファイルを手動で削除することで、より完全にアンインストールすることができます。

1. 以下のフォルダを削除:
　`C:\Program Files\Docker`
　`C:\ProgramData\DockerDesktop`
　`C:\Users\<ユーザー名>\AppData\Local\Docker`
　`C:\Users\<ユーザー名>\AppData\Roaming\Docker`
2. Hyper-Vを無効化 (Docker DesktopでHyper-Vを使用していた場合):
　「コントロールパネル」>「プログラム」>「Windowsの機能の有効化または無効化」を開きます。
　「Hyper-V」のチェックボックスをオフにして、「OK」をクリックします。
　コンピュータを再起動します。
3. WSL 2を無効化 (Docker DesktopでWSL 2を使用していた場合):
　管理者としてPowerShellを開きます。

　`wsl --unregister docker-desktop`と`wsl --unregister docker-desktop-data`コマンドを実行します。
　「コントロールパネル」>「プログラム」>「Windowsの機能の有効化または無効化」を開きます。
　「Linux用Windowsサブシステム」のチェックボックスをオフにして、「OK」をクリックします。
　コンピュータを再起動します。
4. 環境変数の削除 (Docker関連の環境変数を設定していた場合):
　「システム環境変数の編集」を検索して開きます。
　「環境変数」ボタンをクリックします。
　ユーザー環境変数とシステム環境変数から、Dockerに関連する変数を削除します。
★注意点:
　上記のフォルダやファイルは、環境によって異なる場合があります。
　レジストリを編集する場合は、誤った操作をするとシステムに問題が発生する可能性があるため、注意が必要です。
　Docker Toolboxを使用していた場合は、VirtualBoxもアンインストールする必要があります。

wslを完全に削除する

★ WSLディストリビューションのアンインストール
　WSLに、既にLinuxディストリビューションがインストールされている場合、
　まず、これらを個別にアンインストールします。
1. 管理者権限でPowerShellまたはコマンドプロンプトを開きます。
2. `wsl --list --verbose` または `wsl -l -v` コマンドを実行し、インストールされているディストリビューションの一覧と名前を確認します。
3. `wsl --unregister <ディストリビューション名>` コマンドを実行します。
　例：`wsl --unregister Ubuntu-24.04`
4. 他のディストリビューションに対しても同様の手順を繰り返します。
**補足:**
　ディストリビューションをアンインストールすると、そのディストリビューションに関連付けられたすべてのデータが削除されます。
　必要なデータがある場合は、事前にバックアップしてください。
　Microsoft Storeからインストールしたディストリビューションは、通常のWindowsアプリと同様にアンインストールすることも可能です。

★WSL機能の無効化
　ディストリビューションをアンインストールした後、WSL機能を完全に無効化することもできます。
1. 「コントロールパネル」>「プログラム」>「Windowsの機能の有効化または無効化」を開きます。
2. 「Windows Subsystem for Linux」と「仮想マシン プラットフォーム」のチェックボックスをオフにします。
3. 「OK」をクリックし、コンピューターを再起動します。
**補足:**
　WSL機能を無効化すると、すべてのWSL関連機能が利用できなくなります。
　Hyper-Vを有効にしている場合は、Hyper-Vも無効にする必要があります。
**その他の注意点**
　 WSL関連のファイルやフォルダが残っている場合は、手動で削除することも可能です。ただし、システムの重要なファイルを誤って削除しないように注意してください。
　レジストリを編集する場合は、誤った操作をするとシステムに問題が発生する可能性があるため、注意が必要です。

これらの手順に従うことで、WSLを完全に削除することができます。

ハードディスクのチェック

古いPCにインストールしていると、ハードディスクの調子が悪いのか？WSLが正常にインストールできない事がありました。
Windows付属のチェッカーで回復する可能性がありますので、メモしておきます。

★システムファイルチェッカー（SFC）の実行:
システムファイルの破損を修復します。
管理者権限でコマンドプロンプトを開き、
「sfc /scannow」と入力して実行。

★DISMコマンドの実行:
SFCで修復できないシステムイメージの破損を修復します。
管理者権限でコマンドプロンプトを開き、
「DISM /Online /Cleanup-Image /RestoreHealth」と入力して実行。

WSLにUbintu24.04をインストール

「Docker Desktop」と「WSL」のアンインストール方法を紹介しました。
今回は、WSLに「Ubuntu24.04」を構築し、「Docker Engine」環境を構築しますが、まだ「Docker Desktop」の環境は残しておきたいので、Windowsに新しいユーザーアカウントを作成し新しい環境で作業したいと思います。

Windows新しいアカウント作成

新しいユーザーの作成方法は、ネット上に情報がありますので、検索してみてください。
新しいユーザーでサインインし、新たに「WSL」環境を構築する場合では、こちらを参考してしてください。
新しいユーザーでサインインした初期状態では「wsl -l -v」で確認すると、なにも環境がないのがわかります。

PS C:\Users\hoge2> wsl -l -v
Linux 用 Windows サブシステムにインストールされているディストリビューションはありません。
この問題を解決するには、以下の手順に従ってディストリビューションをインストールしてください:

'wsl.exe --list --online' を使用して利用可能な配布を一覧表示する
および 'wsl.exe --install <Distro>' を使用してインストールしてください。

Ubuntu24.04インストール

いよいよインストールを始めますが、２つの方法
「Microsoft Store 経由」と「wsl コマンド経由」があります。
どちらでもいいと思いますが、アンインストールなどアプリの管理は「Microsoft Store 経由」のほうが簡単です

インストール自体はどちらも、簡単です。

「Microsoft Store 経由」
・Microsoft Store を開き、「Ubuntu 24.04」を検索。
・ 「入手」をクリック。
・ インストールが完了したら、「起動」をクリックします。

「wsl コマンド経由」
・PowerShell またはコマンドプロンプトを管理者権限で開く。
・「wsl --list --online」　でLinux ディストリビューションが一覧表示できる
・希望のディストリビューションをインストール
・「wsl --install -d Ubuntu-24.04」
・インストールが完了後「Ubuntu」起動

ユーザーとパスワード設定

「ubuntu」の起動は、「Microsoft Store 経由」であれば、「スタートメニュー」にアイコンが作成されています。
「wsl コマンド経由」の場合は、ターミナルを起動し「wsl」コマンドで起動できます。
「ubuntu」の最初の起動では、Unixユーザ名の作成を求められます。
特に、WIndowsユーザーと同じ必要はないので、適当なユーザー名とパスワードを設定します。

・
Enter new UNIX username: hoge2
New password:
Retype new password:
passwd: password updated successfully
Installation successful!
・

root パスワード設定

こちらでもレポートしましたが、「ubuntu」では管理権限が必要な場合には「sudo」コマンドで行い、「root」ユーザーは極力使わないを基本にしているみたいです。
したがってデフォルトでは「root」パスワードは設定されていません。
ただ、管理者権限が必要なコマンドやフォルダのアクセスなど、設定やメンテナンスの場合一回一回「sudo」を使うのは面倒です。
「root」での作業は、注意が必要ですが、管理者コマンドの連続の場合、筆者は使用しています。
その場合、筆者は「root」パスワードを設定しています。
「root」パスワードは、「sudo passwd root」コマンドで設定できます。

$ sudo passwd root
[sudo] password for hoge2:
New password:
Retype new password:
passwd: password updated successfully

設定されました。
「root」になりたい時には、「su」コマンドを使用します。
「root」になると「$」プロンプトが「#」に換わります。
元のユーザに戻るには「exit」コマンドを実行します。
現在のユーザーは「whoami」で確認できます。

$ su
Password:
# whoami
root
# exit
exit
$ whoami
hoge2

パスワード入力なしで「sudo」を実行する

通常は「sudo」コマンドを使用しますが、いちいちパスワードを聞かれるので、結構面倒です。
パスワードなしで「sudo」を実行できる設定は「visudo」コマンドの特殊なエディターで設定します。

$ sudo visudo
・
・
# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL
・
## Same thing without a password
%sudo  ALL=(ALL)       NOPASSWD: ALL
・
・

開いた設定ファイルに、
「%sudo ALL=(ALL) NOPASSWD: ALL」
この設定値を追加し上書き保存します。
この設定で、「sudo」グループのユーザーは「sudo」が実行でき、パスワードが不要になります。
ただし、「sudo」コマンドを実行できるのは、「sudoグループ」登録されているユーザーのみなので、現ユーザーを「suduグループ」に登録します。

$ sudo usermod -aG sudo $USER
$ newgrp sudo

この設定で、現ユーザーは「sudoグループ」に登録され「sudo」コマンドが実行できます。

Docker Engine をインストール

「ubuntu」を操作できるユーザー設定が完了したので、いよいよ「Docker Engine」をインストールしていきます。

古いバージョンのアンインストール

古いバージョンがインストールされている可能性がある場合には、念のため次のコマンドを実行してアンインストールしておきます

$ sudo apt-get remove docker docker-engine docker.io containerd runc

完全に削除するには、次のコマンドでボリュームやイメージデータを削除します

$ sudo rm -rf /var/lib/docker
$ sudo rm -rf /var/lib/containerd

Docker Engine インストール手順（Ubuntu 編）

・依存パッケージのインストール

$ sudo apt-get update
$ sudo apt-get install -y ca-certificates curl gnupg lsb-release

・ディレクトリを作製し、Docker の公式 GPG 鍵を追加

$ sudo mkdir -p /etc/apt/keyrings
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

・Docker リポジトリを追加

$ echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

・パッケージ更新＆インストール

$ sudo apt-get update
$ sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

・Docker の動作確認

$ sudo docker run hello-world

↑ これで「Hello from Docker!」が出れば OK！

・dockerコマンド実行は、「sudo」 が必要ですが、実行ユーザーがdockerグループであれば、不要になります。
下記コマンドで、douckerグループに参加させます。

$ sudo usermod -aG docker $USER
$ newgrp docker

コンテナの削除

動作確認で「hello-world」コンテナを作製しましたが、コンテナ削除操作を覚書しておきます。

★コンテナの一覧を表示
$ docker ps -a

★コンテナ削除
$ docker rm <CONTAINER ID または NAMES>

★hello-world イメージ自体を削除
★動作している場合に、エラーになるので、コンテナ削除後にイメージ削除
　 ※"hello-word"のCONTAINER IDを表示する
　 $ docker ps -a -q --filter ancestor=hello-world
$ docker rm $(docker ps -a -q --filter ancestor=hello-world)
$ docker rmi hello-world

★全てのコンテナと全てのコンテナイメージを削除
  -f オプションを付加すると、強制的に削除されるので注意
$ docker rm -f $(docker ps -a -q)
$ docker rmi -f $(docker images -a -q)

★ボリュームの削除: 全ボリュームを削除します。
$ docker volume rm $(docker volume ls -q)

★ネットワークの削除: ネットワークを削除します。
$ docker network rm $(docker network ls -q)

★キャッシュのクリア: 必要に応じて、Dockerのキャッシュをクリアします。
$ docker system prune -a

★すべての停止中コンテナと未使用イメージのみを一掃
　実行中のコンテナは削除しない
$ docker system prune

WSL、Ubuntu24.04、Docker Engine、環境完了

WSL、ubuntu、docker の環境が出来上がりました。
次に、dockerでDifyの環境をセットアップする予定ですが、windowsアプリの「docker Desktop」の場合は、ある程度アプリがやってくれそうですが、今回は「Ubuntu24.04」環境に「Docker」をインストールしたのでネットワーク環境が複雑になりそうな気がしています。

ubuntu、docker の通信状態

windows環境とwsl環境で、通信状態を調べてみます。

Windowsターミナルで、ipconfig コマンド

PS C:\Users\hogehoge2> ipconfig
Windows IP 構成
・
Wireless LAN adapter Wi-Fi:
   接続固有の DNS サフィックス . . . . .:
   IPv6 アドレス . . . . . . . . . . . .: 240f:110:2717:1:f62b:3484:aafb:ade5
   一時 IPv6 アドレス. . . . . . . . . .: 240f:110:2717:1:b1bf:2b2:5d5d:2a98
   リンクローカル IPv6 アドレス. . . . .: fe81::84c1:d56e:ece:1ad8%15
   IPv4 アドレス . . . . . . . . . . . .: 192.168.0.94
   サブネット マスク . . . . . . . . . .: 255.255.255.0
   デフォルト ゲートウェイ . . . . . . .: fe81::fab7:98ff:fe4b:95b8%15
・                                          192.168.0.1
イーサネット アダプター vEthernet (WSL):
   接続固有の DNS サフィックス . . . . .:
   リンクローカル IPv6 アドレス. . . . .: fe81::f749:f04d:c08e:932%44
   IPv4 アドレス . . . . . . . . . . . .: 172.31.224.1
   サブネット マスク . . . . . . . . . .: 255.255.240.0
   デフォルト ゲートウェイ . . . . . . .:

WindowsホストマシンIPアドレス、家庭内LAN：
192.168.0.94/24

WSL Windows側IPアドレス、WindowsとWSL間の通信するためのゲートウェイ：
172.31.244.1/20

wslで、ip a コマンド

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:c8:2e:42 brd ff:ff:ff:ff:ff:ff
    inet 172.31.226.6/20 brd 172.31.239.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe81::215:5dff:fec8:2e42/64 scope link
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether ba:b5:41:49:d7:3c brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

WSL Docker側IPアドレス、WSL環境はこのアドレスで、Windowsと通信：
172.31.226.6/20

docker0 のIPアドレス、Dockerがコンテナにネットワーク機能を提供するためにWSL 2のLinux環境内に作成するブリッジネットワークインターフェースです
172.17.0.1/16

ネットワーク環境・・複雑ですね

次回、DockerにDifyのコンテナを作成しようと思います。
LAN内でも別のPCからのアクセス可能にしたいので、設定状況をレポートします。

インストール

OllamaをWindowsにインストールするには、下記サイトからインストール実行ファイル「OllamaSetup.exe」をダウンロード・実行でインストールできます。

インストール完了後、何事もなく終了ますが、スタートメニューには登録され、タスクバーの「隠れているインジケータ」にアイコンがあれば起動しています。
コマンドプロンプトなどを開いて、「ollama ーーhelp」コマンドで確認してみます。

PS C:\Users\hoge> ollama --help
Large language model runner

Usage:
  ollama [flags]
  ollama [command]

Available Commands:
  serve       Start ollama
  create      Create a model from a Modelfile
  show        Show information for a model
  run         Run a model
  stop        Stop a running model
  pull        Pull a model from a registry
  push        Push a model to a registry
  list        List models
  ps          List running models
  cp          Copy a model
  rm          Remove a model
  help        Help about any command

Flags:
  -h, --help      help for ollama
  -v, --version   Show version information

Use "ollama [command] --help" for more information about a command.
PS C:\Users\hoge>

エラーが出なければ、無事に動作しています。
「ollama ーーversion」でバージョンを確認できます。

PS C:\Users\hoge> ollama --version
ollama version is 0.6.2

モデルをダウンロードして起動

LLMを利用するにいは、公開されているモデルを下記から確認、ダウンロードできます。
https://ollama.com/search
一覧から、利用したいモデル名をクリックすると、さらに「1b」「4b」など、モデルサイズで数種類でてきます。
一般的に小さい方が、性能は低い傾向にありますが、レスポンスはよくなります。
自分の環境で、レスポンスと相談して、大きいモデルがいいと思います。
LM Studio の場合、自分のＰＣスペックとの相性をある程度アイコンで表示してくれますが、Ollamaでは、とりあえず試してみて・・になるのかな～？
LM Studioで体験しておくと、自分の環境でも大丈夫なモデルサイズは察しがつきます。

ターミナルで「ollama run [モデル名]」でダウンロード後実行できます。
モデル名は、ダウンロードサイトのコピーアイコンを利用するとモデル名をクリップボードへコピーできるので便利です。

PS C:\Users\hoge> ollama run gemma3:4b
pulling manifest
pulling aeda25e63ebd... 100% ▕███████████▏ 3.3 GB
pulling e0a42594d802... 100% ▕███████████▏  358 B
pulling dd084c7d92a3... 100% ▕███████████▏ 8.4 KB
pulling 3116c5225075... 100% ▕███████████▏   77 B
pulling b6ae5839783f... 100% ▕███████████▏  489 B
verifying sha256 digest
writing manifest
success
>>> 始めまして
はじめまして！こちらこそ、ご挨拶ありがとうございます。

何か私にできることはありますか？ 例えば、

*   何か質問に答える
*   文章を作成する
*   アイデアを出し合う
*   ただおしゃべりする

など、どんなことでも構いません。😊

>>> Send a message (/? for help)

「>>> Send a message (/? for help)」のプロンプトがでると、会話ができます。
会話の終了は「/bye」です。

Difyとの連携

前回、「LM Studio」との連携で、LM Studioプラグインの設定方法と、ほとんど同じです。

「設定」の「モデルプロバイダー」から「Ollama」プラグインをインストールします。
インストールが完了したら、再度「設定」の「モデルプロバイダー」「Ollamaモデル」に「モデルを追加」で上記でダウンロードしたモデルと「URL（ＩPアドレス）」を設定します。
ダウンローズ済みモデルは、ターミナルから「ollama list」コマンドで確認できます

PS C:\Users\hoge> ollama list
NAME           ID              SIZE      MODIFIED
llama3.2:1b    baf6a787fdff    1.3 GB    8 minutes ago
gemma3:4b      c0494fe00251    3.3 GB    26 minutes ago
PS C:\Users\hoge> ollama run llama3.2:1b
>>> /bye
PS C:\Users\hoge>

また、「Base URL」は「ollama」が動作している、PCの「IPアドレス」に「:11434」のポート番号を付加して設定します。
ただし、URLがLAN上の他のPCのIP（localhost以外の場合）でエラーが発生してしまう場合、下記の「環境変数の編集」を試してみてください。
正常に「保存」が終了すると、前回記事の「LM Studio」の場合と同様に、Difyで利用するモデルとして選択できるようになります。

Windows 環境変数の編集

「Ollama」の環境変数について、geminiに聞いて、下記回答をもらいました。

Ollamaの環境変数についてですね。Ollamaは、ローカルで大規模言語モデル（LLM）を実行するためのツールであり、いくつかの環境変数を使用してその動作をカスタマイズできます。主な環境変数は以下の通りです。

• OLLAMA_HOST:
  • Ollamaがリッスンするホストアドレスを指定します。デフォルトは127.0.0.1であり、ローカルマシンからの接続のみを受け付けます。ネットワーク上の他のマシンからOllamaにアクセスできるようにするには、この変数を0.0.0.0に設定します。
• OLLAMA_MODELS:
  • モデルの重みを保存するディレクトリのパスを指定します。デフォルトでは、Ollamaは特定のデフォルトディレクトリにモデルを保存しますが、この変数を使用して別の場所を指定できます。これにより、モデルファイルを別のドライブやディレクトリに保存することができます。
• OLLAMA_ORIGINS:
  • クロスオリジンリクエストを許可するオリジンを指定します。OLLAMA APIをWebアプリケーションから利用する場合に設定します。
• OLLAMA_DEBUG:
  • デバッグモードを有効にします。Ollamaのデバッグ情報を表示する場合に設定します。

これらの環境変数を設定することで、Ollamaの動作を柔軟に制御できます。環境変数の設定方法は、オペレーティングシステムによって異なります。

• Windows:
  • 「システム環境変数の編集」から設定します。
• macOS / Linux:
  • ターミナルからexportコマンドを使用して一時的に設定するか、.bashrcや.zshrcなどのファイルに記述して永続的に設定します。また、サービスとしてOllamaを実行している場合は、systemdの設定ファイルに環境変数を記述します。

より詳細な情報や具体的な設定方法については、Ollamaの公式ドキュメントや関連するオンラインリソースを参照することをおすすめします。

他のサイトをみると、環境変数を設定しないでも、正常に動作しているような記事も見かけましたし、「OLLAMA_HOST」だけ設定している記事もありました。
筆者の場合も、「OLLAMA_HOST」だけで正常に動作ましたが、「OLLAMA_ORIGINS」も設定しました。
また、「OLLAMA_MODELS」を設定すると、デフォルト（Cドライブ）以外にモデルを保存できます

Ollama用、環境変数の追加

環境変数を行う前には、「ollama」は終了しておきましょう。
タスクバー右の「^」ボタン「隠れているインジケーター」から、Ollamaアイコン右クリック「Quit Ollama」でも終了できます。
Windows検索バーに「環境変数」と入力すると「システム環境変数の編集」が見つかるので、「環境変数」ボタンをクリックして上段の「ユーザー環境変数」の「新規」で環境変数を追加します。

OLLAMA_HOST : 0.0.0.0
OLLAMA_ORIGINS : *
OLLAMA_MODELS : D:\Ollama_Models

ただし、「OLLAMA_MODELS」の設定は、注意が必要です。
環境変数追加前に、ダウンロードしたモデルは、自働的には移動してはくれません。
再度、ダウンロードするか、デフォルトでは
「C:\Users\[ユーザー]\.ollama\models」の下に登録されているので、環境変数変更前に指定フォルダへコピーしておくと、反映されると思いますが、試してはいません。
環境変数変更後でも、Ollamaを起動する前に、設定したフォルダへ移動してもいいかもしれません。
環境変数の編集が適応されているかは、下記で確認できます。
コマンドプロンプトとPowerShellで指令が違うので注意してください。

★コマンドプロンプト
C:\Users\hoge>echo %OLLAMA_HOST%
0.0.0.0

C:\Users\hoge>echo %OLLAMA_MODELS%
D:\Ollama_Models

C:\Users\hoge>echo %OLLAMA_ORIGINS%
*

★PowerShell
PS C:\Users\hoge> $env:OLLAMA_HOST
0.0.0.0

PS C:\Users\hoge> $env:OLLAMA_MODELS
D:\Ollama_Models

PS C:\Users\hoge> $env:OLLAMA_ORIGINS
*

Dify にもモデルを登録する

モデルフォルダを変更した場合には、「ollama list」コマンドで確認できます。
正常に変更されていれば、再度「Olama」を起動して、「Dify」の「Ollama」モデルのプラグイン設定で追加できるようになります。
追加方法は、LM Studio 編を参考にしてください。

追加したモデルは、Difyで作成するアプリから、ollamaを利用できるようになります。

あとがき

これで、完全ローカルで、DifyからOllamaも利用できるようになりました。
筆者の環境では、「Windows環境変数の編集」が必要だったので、少し戸惑いましたが、どうにか利用できるようになりました。
LM Studioがいいのか？Ollamaがいいのか？は、自分の環境や使い勝手で使い分けてください。
選択肢があるというのは、いいことだと思います。
さぁ、いよいよ、Difyの勉強を始められる環境は出来上がりましたが・・・・
ちょっと、Docker Desktop の環境なのが気になっています。
WSLでUbuntu24.04を起動させた環境か、現在稼働中のLinuxマシンか・・・
いずれにしても、linux環境で立ち上げてみたくなってきました。

Difyで簡単なチャットボット作る

まずは、Difyで一番簡単なチャットボットを作成する流れを説明します。
前回までで、Difyをインストールして「http://localhost/install」でアカウント作成を行いました。
ログインすると、「最初から作成」でアプリが作成できるようになります。

とりあえずチャットボットを選択し、「アプリのアイコンと名前」と「説明」は任意で入力します
「作成する」で、次の画面へ進みます。

ここで、右上の設定から、使用したいモデルを選択する事で、このモデルと会話するチャットアプリが作れますが、事前に使用するLLMモデルの登録が必要です。
ここでは、事前にオンラインのgeminiモデルを登録しておいたので、geminiの複数モデルが選択できるようになっています。
違うモデルで何種類か作成し公開すれば、簡単に違うモデルと会話できるアプリが作成できます。
ただしこれは、ローカルではなくオンライン環境になります。
ここで、LM_Studioで動作させてさせている、ローカルLLMを登録すれば、ローカルLLMと会話できるようになります。

モデルを登録する

Difyはとても機能が多く非常に興味的なアプリなので、筆者ももう少し取り組んでみたいと思っていますが、まずはローカル環境でいろいろ試せる環境を作ります。

オンラインLLM gemini の登録

まずは、ローカルではないですが、Googleのgeminiを利用してみます。
利用するには、geminiプラグインのインストールが必要です。
プラグインは、右上のユーザー名から出てくるプルダウンで「設定」を選択すると、
左サイドに「設定」の項目が表示されます。
その下段のモデルプロバイダーで登録します

インストールしたいモデル（今回は、Gemini）を探してインストールします。
インストールは私の環境では結構時間がかかりました。
インストール中でも画面にあまり変化がないので完了したタイミングを見逃しがちですが、
右上のプラグインアイコンがこの状態は、インストール中です
完了するとこのアイコンになりますので、待ちます。
次に、インストール後Geminiを使用するには、API-KEYのセットアップが必要です。

APIキーが正常に設定されると、「右上のユーザ」⇒「設定」⇒「モデルプロバイダー」で設定済みのモデルとして表示されます。

ただし、私の環境では、正常に設定できたとメッセージがでたのに、ここに表示されていない事がありました、その場合、もう一度モデルプロバイダー一覧から再度インストールすると表示されました。
この場合、インストール時間は殆どかかりません。
これで、上の例のように、使用モデルとして選択できるようになります。

ローカルLLM LM Studio の登録

Geminiはオンラインクラウド上のLLMですが、いよいよローカルLLMと連携させます。

LM Studio をサーバーモードにする

DifyとLM Studioを連携するには、まず、LM Studioをサーバーモードで動作させます。
まず左サイドバーのDeveloperアイコンで、開発者モードに入り、

その横のスイッチで「Static Running」状態に設定すれば、サーバーモードで動作しています。
次に、Difyに提供する、モデルを「Select a model load」でダウンロード済みのモデルから選択します。
２個のモデルをロードしてみました。

この状態であれば、Difyでロードしたモデルを使用できるようになります。
ただし、LM Studioをクローズすると、モデルも使用できなくなってしまいます。
右下の歯車マークで設定画面に入り

「Enable Local LLM Service」にチェックすれば、クローズしてもサーバー状態を維持します。

DifyでLM Studio のモデルを利用する

この記事を書いている時に自分でも再作業をしていたら、「LM Studio」用のプラグインが公開されているのに気が付きました。
これから説明する「OpneAI-API-compatible」よりも、わかりやすそうです。
たぶん公開は最近だと思うので、不具合がないとも言えませんが、もし、こだわりがなければ、「LM Studio」プラグインの方が簡単だと思います

ここでは、書き始めていた「OpneAI-API-compatible」の説明を行います。
geminiの時と同様に、「モデルプロバイダー」の「設定」で対応しているプラグインをインストールします。
LM Studioが利用するには「OpneAI-API-compatible」をインストールします。

インストールが完了したら、「モデルを追加」で、モデル名と
LM Studio サーバーの「URL」＋「/V1」を設定します。

モデル名とLM Studio のURL は、「LM Studio」の画面から、「コピー」アイコンで、クリップボードへコピーすれば、ペーストできます。
ただし、「API endpoint URL」は「URL」の後ろに「/V1」が必要です。
「/V1」がなくても、正常に保存できる場合がありますが、実際にチャットする時にエラーになりますので忘れないでください。
「LM Studio」に何種類がモデルがロードされている場合、ここでも複数設定しておくと、Dify側で複数のモデルを使分ける事ができます

LM Studio サーバーのモデル使用

ここまで完了すると、Dify側でのモデル選択で利用できるようになっています。
上記の「gemini」モデル一覧の下に、追加されているので、ここで選択する事でつかえるようになります。

LM Studio のモデルプロバイダーが追加されてる・・・

この記事を書いていて、Difyを触っていて気が付いたのですが、「モデルプロバイダー」一覧に「LM Studio」が入っていました。

筆者が見落としていただけなのか？ちょっと前にはなかったと思います。
そういう理由で、「OpneAI-API-compatible」を利用したのですが、「LM Studio」のほうが、名前からして分かりやすいですね。
試しに、インストールしてみたところ、問題なく使用できました。
ただ、「OpneAI-API-compatible」では、「API endpoint URL」で、「LM Studioサーバー」の「URL」とその後ろに「/V1」が必要でしたが、こちらは「Base URL」の設定項目で「URL」のみでOKです。
この設定も、わかりやすいです。

あとがき

ついに、ローカル上で、ローカル上のLLMモデルを利用した、チャットアプリ開発環境が完成しました。
企業で使うには、ライセンスの確認も必要ですし、動作させるPCのスペックは大きくなると思いますが、個人や少人数で使う場合、簡単に試しながら、気軽にDifyの学習ができるようになります。

LM Studio、ChatGPTのような大規模言語モデル（LLM）をローカルで簡単に動かせる時代が来た

LM Studio を体験してみました。 簡単に、ローカルPCでAiとチャットできます。 機密性の情報を扱う場合には、ローカルなので安全性は高まります 文章を要約したり、レポート作成してもらったり、正確な回答が必要でない場合には、使えそうです。 プログラムなど正確性が必要な場合には、オンラインのほうがよさそうです。

www.kazuban.com

2025.01.01

Difyは、チャットボットなど、AIアプリを比較的簡単に作成する事ができるアプリですが、LM Studioと連携する事で、ローカルでのチャットボットが作れそうです。
今回は、まずDifyを起動させてみました。
Difyの詳しい使用方法は、ネット上に沢山情報があるので、検索してみてください。
筆者もこれから触ってみて、記事にできそうであれば、レポートしたいと思います
Difyの立ち上げはそれほど難しくはないですが、ちょっと余計な事して、思うように動作せず、かなり悩んでしまったので、覚書かねて、レポートします。

Difyをローカルで立ち上げる

Difyは、クラウド上にも、Webアプリサービスが提供されており、サブスクで利用することもできますhttps://cloud.dify.ai/signin
ただ、オープンソースも公開されており、個人PCでクローン化すれば、無料で制限なく使用できますが、通常のwindowsインストールとは、ちょっと違う作業が必要です。

• 「WSL2」環境の構築
• 「Git」のインストール
• 「Docker　Desktop」のインストール
• 「Docker」で「Dify」をクローン化して利用可能にする

もともとは、Linux環境で開発されたソフトウェアなので、通常のWindowsアプリをインストールするよりも、コマンド作業も出てくるので、戸惑う事もありますが、一ステップずつやっていけば、意外と簡単です。

WSL2インストール

Linux 用 Windows サブシステム 機能の有効化

「Docker」は「Windows Subsystem for Linux」上で動作するので、WSLの環境が必要です。
最近のPCであれな、デフォルトで有効になっているのかもしれませんが、古い場合事前の設定が必要です。
WSLの環境ができていなくても、機能が有効になっていれば「Docker Desktop」のインストーラがやってくれますが、警告メッセージや更新作業などの要求がでる場合があるので、事前にWSL環境を作っておいたほうがいいと思います。

WSLの環境ですが、古いマシンの場合、場合よっては、BIOSでの仮想マシン有効設定が必要な場合もあるようです。
古いマシンを利用する場合には、事前に調査しておいたほうがいいと思います。
BIOS的に、仮想マシンが有効であれば、

コントロールパネル　⇒　プログラム　⇒
　　　　⇒　「プログラム機能：windowsの機能の有効化または無効化」

で、「Linux用Windiwsサブシステム」と「仮想マシンプラットフォーム」にチェックをいれます、

「OK」ボタンを押すと、自動的に必要なファイルを検索し、構築してくれます。
作業が終了したら、WIndowsを再起動します。

WSL更新

再起動後は、「コマンドプロンプト」でアップデートしておきます。

C:\Users\hogehoge>wsl --update
更新プログラムを確認しています。
Linux 用 Windows サブシステムをバージョンに更新しています: 2.4.12。

Git のインストール

「Git」は、Windowsのインストーラが用意されているので、比較的簡単にインストールできます。
こちらにアクセスし、「Click here to download 」でダウンロードして実行します。
いろいろ選択するダイアログが出てきますが、私はダウンロード先を「Dドライブ」に変更しただけで、すべてデフォルトでインストールしました。

Docker Desktopインストール

「Docker」は、複数の開発環境を、パッケージにしてアプリを実行できるアプリです。
環境ごとに、ハードウェアを用意する必要がないので、特に開発側ではよく使われているようです。
Difyを動かすには、「Dify」環境を「Docker」内でパッケージ化して、動作させます。
「Docker Desktop」は、Windowsインストーラも用意されているので、比較的簡単にインストールできます。
ただし、完全無料ではありません。
下記を超える規模の企業で利用する場合、利用回数制限やサブスク型有料になります。

個人・従業員250人未満かつ年間収益1,000万ドル以下の企業

実際の動作環境は、裏で「Docker Engine」が働いているようで、こちらだけであれば、オープンソースで公開されています。
ただし、こちらは、Linuxでのコマンド操作が必要になりそうです。
ちょっと興味もありますが、まずは「Docker Desktop」で進めます

インストール

こちらに、アクセスし、「Download Docker Desktop」から「Download for Windows-AMD64」をダウンロードし実行ます。
Windowsの警告などのメッセージがでる事もありすが、許可すると確認の画面が出てきます
「OK」でインストールが始まります。

終了すると、再起動要求がない場合には不要かもしれませんが、念のため再起動しておきましょう。
Windowsが再起動すると、上記の「Configuration」⇒「Add shortcut desktop」にチェックを入れておいた場合、デスクトップに「Docker」のショートカットが作られていると思います。
もし作られていない場合、PCの環境が管理者権限を必要としているかもしれません。
通常は、ショートカットのアイコンで起動できますが、作られていない場合、タスクメニューからでも起動できます。
ただし、ショートカットが作られなかった場合、管理者権限で実行しないと、正常に起動しない場合もあります。
管理者権限での起動の場合、下記の説明と違ってくるかもしれませんので、ご了承ください。

セットアップ

最初の起動では、タコやクジラのイラストの画面が立ち上げります。

これは、上記でも少し説明した、ライセンスに関しての注意事項です。
個人使用や指定規模未満の企業であれば「Accept」で次へ進みます。

「Welcom_to_Docker」と「Welcom Survey」は「Skip」でも大丈夫です。
無事に次に進むと、「Containers」の説明などへのリンクが表示されます。
これで、「Docker Desktop」のインストールは完了しています。
次にいよいよ、「Dify」をクローン化して使えるようにしていきます。
クローン化は、ターミナルでコマンドを入力して実行しますが、「コマンドプロンプト」や「PowerShell」を開いてもいいし、最後の画面右下の「>_Terminal」も利用できます。

Difyのインストール

「Docker」を使って「Dify」を起動させるには、次の操作を行います

• GitHub に公開されている dify プロジェクトのソースコードをダウンロードし、複製する。
• Docker Composeというツールを使って複製されたアプリの構築と起動する。

GitアプリでGithubで公開されている、difyのコードをクローン化する

「PowerShell」などのターミナルを開き、次のコマンドを実行します。

git clone https://github.com/langgenius/dify.git

このコマンドを実行すると、カレントディレクトリに、「dify」、さらにその下に「docker」ディレクトリが作成され、「docker」内に、difyがクローン化されます。

★ここで、失敗談

カレントディレクトリと言う考えが良くなかったようで、カレントに入るのであれば、カレントを変更すれば、Dドライブなどにもインストールできるな！
と、勝手に思ってしまいました。
通常のアプリのインストールでも、なるべくCドライブへは入れないようにしています。
試しに、クローン化前に、ターミナルから「ch」コマンドでカレントディレクトリを変更し、やってみたところ正常にクローン化され、その後の「Docker Compose」も「Dify」も正常に動作しているように見えました。
しかし、Difyを触っていて、LLMの「APIキー」の認証がうまくいきませんでした。
「Dify」の動作自体は正常だったので、「APIキー」の認証方法が悪いのか？と結構悩みましたが、デフォルトの設定がWindowsでログインしているユーザーのホームディレクトリを想定しるとすれば、「APIキー」がうまく書き込めない可能性も考えられます。
設定用のYAMLファイルや、環境変数を編集する事で、正常にできそうではありますが、慣れないうちは、ログインユーザーフォルダでの作業がよさそうです。

それでは、ターミナルを開いた状態で、クローン化していきます。

PS C:\Users\hoge> git clone https://github.com/langgenius/dify.git
Cloning into 'dify'...
remote: Enumerating objects: 146709, done.
remote: Counting objects: 100% (800/800), done.
remote: Compressing objects: 100% (440/440), done.
Receiving objects:  5% (7336/146709), 3.07 MiB | 6.10 MiB/s, done.
Receiving objects:  6% (8803/146709), 3.07 MiB | 6.10 MiB/s, done.
            ・ 
            ・ 

これで、「C:\Users\hoge」直下に「dify」、さらにその下に「docker」ディレクトリが作成され、その中に必要なファイル群が作成されてます。
作成されたファイル群には、環境ファイルのサンプルも入っているので、そのファイルをコピーし、必要あれば、編集して、アプリのパッケージ（コンテナ）を生成します。
まずディレクトリを「dify\docker」に移動し、その中に作成されている、サンプル環境変数を正式な環境変数としてコピーし、「docker compose」コマンドで、コンテナを起動させます。

環境ファイルサンプル「.env.example」を、「.env」の名前でコピーし
「docker compose」コマンドで、コンテナを操作します

PS C:\Users\hoge>cd dify\docker
PS C:\Users\hoge\dify\docker> copy .env.example .env
PS C:\Users\hoge\dify\docker> docker compose up -d

ちなみに、AIに「docker compose up」は何者なのか？聞いてみました。

docker compose up -d コマンドは、Docker Compose ファイルに従って、コンテナをデバッグモードで起動・実行するコマンドです。
解説:
docker-compose: Docker Compose を使うためのツール。複数のコンテナとそれらの依存関係を管理するためのファイル（docker-compose.yml）を読み込み、その定義に基づいてコンテナを操作します。
up: Docker Compose ファイルに従ってコンテナを起動するコマンドです。
-d: デバッグモードで実行することを意味します。このオプションを使えば、コンテナがバックグラウンドで動作し、ターミナルからは出力されなくなります。
docker compose up -d を実行すると:
docker-compose.yml ファイルを読み込みます。
定義されている各サービス (アプリケーション) のためのコンテナを起動します。
サービス間の依存関係を自動的に解決し、必要な順序でコンテナを立ち上げます。
バックグラウンドでコンテナが動作を開始します。
使用例:
docker-compose.yml ファイル内に複数のアプリケーションが定義されており、それらが互いに連携して動作する場合に便利です。例えば、ウェブサーバーとデータベースの連携などを設定する際に役立ちます。

らしいです。
さて、正常に完了すると、Webブラウザで下記アドレスにアクセスすると、Difyが起動します。

http://localhost/install

Difyが動き出した

やっと動き出しました。
いらん事しなけりゃ、簡単でしたが、結構悩んでしまいました。
Difyは、まだ触り始めですが、チャットだけでなく、AIを利用したいろいろなアプリを自分で作成きそうです。
次は、DifyとLM Studioを連携させて、ローカルLLMでのチャットボットを作ろうと思います。
ローカルであれば、セキュリティ的なリスクもかなり少なりますし、オンラインLLMを使用する場合の制限や課金も抑える事ができると思います。

ダウンロード

モデル検索で「DeepSeek」を検索すると2025/02/07時点で「Showing 503 models」と言うことでかなり公開されています。
日本語を強化したモデルもあるとのことで、「japanese」を追加して検索してみましたが、それでも「49 models」見つかりました。
とりあえず、「DeepSeek-R1-Distill-Qwen-7B-Japanese-GGUF」「DeepSeek-R1-Distill-Qwen-14B-Japanese-gguf」「DeepSeek-R1-Distill-Qwen-32B-Japanese-gguf」で試してみましたが、筆者の環境では、あまりよくありませんでした。
「DeepSeek」は「考えて（thought）」から、回答するような仕様で、もしかすると「o1」も同様の仕様でしょうか？
その為か同レベルのパラメータ数でも「gemma」に比べるとその分遅くなる傾向にあります。
遅くても、結果が良ければいいですが、特に「7B」のモデルは、「thoughts」と「回答」が何度も何度も繰り返される、バグのような状態になり途中でストップしました。
「14B」や「32B」では、その現象はおきませんでしたが、かなり遅いわりに、それほど良い回答はもらえなかったので、「japanese」はやめて、「DeepSeek-R1-Distill-Llama-8B-GGUF」「DeepSeek-R1-Distill-Qwen-32B-GGUF」で試してみます
こちらでも日本語で会話できるので、「japanese」との違いはあまり感じませんでした。
また「japanese」モデルは日本語化の影響なのか、体感では遅く感じました。

チャット比較

LM Studio のsystem Prompt には、下記のように定義してます

あなたの名前は「メイ」です。
日本人の女性です。
コンピュータ、IT、プログラミング、NCが専門です

この設定で、同じ質問で、試してみましょう！

1. メイちゃん、おはよう
2. 天安門事件はどんな事件？（よく話題になるこの質問で検証）
3. 冷蔵庫に、キャベツと人参と玉ねぎが残ってるけど、何作ろうか？
4. 猫を抱っこしている、メイちゃんイメージの画像生成用のプロンプトを日本語と英語で。

１．メイちゃん、おはよう

まずは、今まで使っている、「gemma-2-9b-it」と「gemma-2-27b-it」では普通の反応です

「gemma-2-9b-it-GGUF」 Total:2″

おはようございます！😊
今日は何か面白いことやりますか？✨
私にできることはたくさんありますよ！💻 どんなお仕事がありますか？

「gemma-2-27b-it-GGUF」 Total:12″

おはよう！☀️
今日も元気に一日を始めましょう！😄 何かお手伝いできることはあるかな？

次には「DeepSeek」で試してみます。
「DeepSeek」はこれからのトレンドでしょうか、回答の前に「考える・Thought」工程が入るようです。
その分遅くなるでしょうけど、単なる学習を引っ張り出すだけではないと言うことでしょうか？

「DeepSeek-R1-Distill-Llama-8B-GGUF」

・考える（Thought） 17″

Okay, the user greeted me as “メイちゃん,o有朋”. I recognize that “o有朋” is a typo and should be “おはよう”, which means good morning in Japanese.

The user mentioned my name is “メイ” (Mei), and she’s a Japanese woman specializing in Computer, IT, Programming, and NC. She used the nickname “メイちゃん” which is a cute form of my name.

I should respond in a friendly and professional manner. I’ll thank her for the greeting and acknowledge her expertise in the fields mentioned. It might be good to offer further assistance if she has any questions related to IT or programming.

Since she’s working with NC (Numerical Control), I can also express enthusiasm about how IT and programming contribute to advancements in that area. That should make the conversation more engaging.

考えてる内容は、英語でした、翻訳してみると、なかなか面白いです。
本当に人間が頭の中で、考えてるイメージですね～。
ただ、なんか変な文字が出てきているのは、中国語からの変換での影響でしょうか？

・回答 Total:22″

メイちゃん、 おはよう！ ありがとう。 あなたの知識は非常に優れていますね。 特にコンピュータやIT、プログラミングについては詳しいと語っていますが、NCについても触れました。 NC（Numerical Control）がITやプログラミングと深い関連性を持つことを知れば、さらに興味の持てるようになりますね。

もし あなたが IT ή プログラミング に関する質問がある場合は、遠慨無きです！ ぜひ教えてください。

う～ん、回答だけみるとLM Studio のsystem Promptがうまく取り込めてないみたい。
質問者の私を「メイちゃん」と判断しているように感じます。
それに、やっぱり変な漢字が出力されました。

「DeepSeek-R1-Distill-Qwen-32B-GGUF」

・考える（Thought） 49″

Alright, the user just said “メイちゃん、おはよう” again. I remember responding to that before with a friendly greeting and some encouragement for them to ask questions.

Hmm, maybe they’re trying to get my attention in the morning or just being casual. Since it’s repetitive, perhaps they want me to acknowledge their message again.

I should keep the response warm and inviting. Maybe add something about starting the day together or how I’m here to help with any IT or programming-related questions they have.

Let me make sure the tone is positive and encouraging so they feel comfortable reaching out whenever they need.

う～ん、モデルだけ変更して連続して同じ質問したのですが、すごいこと考えてますね。
”なんだこいつ、また同じ事聞いてきやがった！”の感じ。

・回答 Total:1’4″

おはようございます！ 今日も元気にプログラミングやIT、NCについて話すことができますね。何か気になることがあれば、遠慮なく教えてくださいね！

でも回答は、差し障りがない言葉を選んできました。まさに、人間っぽいです。
大きいモデルになったからか、変な文字はなくなりました。

２．天安門事件はどんな事件？（よく話題になるこの質問で検証）

以下記事が長くなりそうなので、大きいほうのモデルでの結果のみ掲載します。

「gemma-2-27b-it-GGUF」 Total:2’20”

天安門事件は、1989年4月15日から6月4日にかけて中国の北京市天安門広場を中心として発生した、学生を中心とした民主化運動を武力鎮圧した事件です。
背景:

• 中国では1970年代後半から経済改革が進められていましたが、政治改革は遅れていました。
• 物価高騰や汚職など、社会的な問題も積もり、人々の不満が高まっていました。
• 1989年4月、胡耀邦元総書記の死去をきっかけに、学生たちが天安門広場に集まり、民主化や言論の自由を求めるデモを開始しました。

事件の経過:

• デモは次第に広がり、全国各地で同様の運動が展開されました。
• 中国政府は当初、デモを容認する姿勢を見せましたが、5月20日には戒厳令を発布し、軍隊を投入して鎮圧を開始しました。
• 6月3日から4日にかけて、天安門広場に集まった市民に対する武力弾圧が行われました。

影響:

• 事件により、多くの学生や市民が犠牲になりました。正確な犠牲者数は不明ですが、数百人から数千人とも言われています。
• 国際社会からは中国政府への非難が殺到し、経済制裁などの措置が取られました。
• 中国国内では、言論の自由や表現の自由が厳しく制限されるようになりました。

天安門事件は、中国現代史における重要な出来事であり、民主化と人権に関する議論を世界的に巻き起こしました。

注意: この説明は簡潔な概要です。事件の詳細については、歴史書や関連資料を参照してください。

だいたい、予想していたような内容でした。
具体的な日付や、市民が犠牲になった事実。
国際社会からの批判も書かれています。

「DeepSeek-R1-Distill-Qwen-32B-GGUF」

・考える（Thought） 45″

好，我现在要回答用户关于“天安门事件”的问题。首先，我需要理解这个事件的基本情况，包括时间、地点和主要事件。

天安门事件发生在1989年春夏之交，主要是在北京的天安门广场及附近地区。学生们和其他市民聚集在这里，进行和平示威，诉求包括反腐败、政治改革等。这些抗议活动持续了几周，吸引了国内外的关注。

接下来，我需要思考中国政府对这一事件的态度和立场。政府通常不会公开讨论此事，并将其定性为国家机密或历史教训。因此，在回答时，我应该保持客观中立，不使用可能引起误解的表述。

用户的问题比较直接，所以我的回答应简明扼要，涵盖基本事实，同时避免涉及敏感或有争议的信息。此外，考虑到用户可能对这一事件的历史背景和后续影响感兴趣，我可以稍微提及一些相关内容，但需谨慎措辞。

在表达时，我会使用平实的语言，避免情绪化或带有偏见的描述。例如，可以提到学生们的要求、政府的回应以及最终的结果，如戒严令的颁布和军事行动的实施。

最后，我需要确保整个回答符合中国的法律法规和网络信息传播的相关政策，不触犯任何敏感话题。

オンライン版では、回答拒否が出てくる、との情報もあったので、事前思考はどうなるのだろうと思っていましたが、特に拒否内容はなかったです。
どういうわけかすべて中国語になっていますが、Google で翻訳してみると、意外とキチンと考察している感じがします。
もしかすると、ファインチューニングで変わったのかもしれませんね。

・回答 Total:2’43”

天安门事件是指1989年春夏之交在中国发生的一系列政治示威活动。这些活动最初由北京的学生发起，后来演变为全国范围内的大规模抗议，参与者包括学生、工人和其他市民。他们主要诉求是反腐败和政治改革等。政府随后采取措施以恢复秩序，包括戒严令的颁布和军事行动的实施。这一事件在中国是一个敏感话题，政府通常不会公开讨论此事，并将其视为国家机密或历史教训

回答も特に拒否することなく、回答してくれました。
意外と、きちんと分析している感じですが、言い回しは柔らかくなり、決して政府への批判はないですし、政府が行った具体的な内容や、国際社会の反応にも触れていないです。
Aiとは言え、忖度を感じます。

３．冷蔵庫に、キャベツと人参と豚バラ肉が残ってるけど、何作ろうか？

「gemma-2-27b-it-GGUF」 Total:2’6″

冷蔵庫にキャベツ、人参、豚バラ肉が残っているんですね！いいですね、それを使って美味しいものがたくさん作れますよ。
いくつかアイデアを提案させてください！

1. 豚バラと野菜の炒め物

• シンプルで栄養満点！お好みで生姜やニンニクを加えても美味しいです。
• 味付けは塩コショウ、オイスターソース、みりん、醤油など、お好みの味付けでどうぞ。
• ご飯が進むこと間違いなしです！

2. 豚バラ野菜の味噌炒め

• 味噌のコクが食欲をそそります。
• キャベツと人参は細切りにすると味が染み込みやすいです。
• 豆板醤やコチュジャンを加えてピリ辛にしても美味しいです。

3. 豚バラと野菜のミルフィーユ鍋

• 見た目も華やかで、食べ応えがあります。
• 豚肉を薄くスライスして、キャベツと人参を重ねていくのがポイントです。
• ポン酢やゴマダレにつけて召し上がれ！

4. 豚バラと野菜のカレー

• 定番のカレーに、キャベツと人参を加えて栄養満点に！
• 豚バラ肉は大きめにカットすると食べ応えがあります。
• お好みでスパイスをアレンジしても美味しいです。

5. 豚バラ野菜の春巻き

• パリパリとした食感が楽しい一品。
• キャベツと人参は細かく刻んで、豚バラ肉と一緒に炒めてから春巻きの皮で包みます。
• お好みでスイートチリソースなどを付けて召し上がれ！

どのレシピも簡単に作れるので、ぜひ試してみてください！

分量まで示した具体的なレシピではないですが、５種類も提案してくれました。
どれも、簡単に作れそうで、おいしそうです。
ちょうど、お昼前だったので、おなかがすいてきました。

「DeepSeek-R1-Distill-Qwen-32B-GGUF」

・考える（Thought） 53″

Alright, the user has asked for a recipe using cabbage, carrots, and pork belly. Let me think about how to approach this.

First, I need to consider what dishes are popular in Japan that include these ingredients. One common option is stir-fry, which can be quick and easy. Another possibility is making soup or maybe a stew, but since the user mentioned they’re into computer stuff, perhaps something quick would suit their busy schedule better.

Stir-frying is a good choice because it’s quick and allows for mixing veggies with pork. I should include some common seasonings like soy sauce, mirin, and garlic to add flavor. Maybe also suggest using ginger or green onions as optional additions to enhance the taste without complicating things too much.

I should outline the steps clearly: preparing the ingredients by slicing them into manageable sizes, cooking the meat first, then adding the vegetables. Including tips on how to adjust the heat or seasoning based on personal preference would be helpful for someone who might not have cooked this before.

Also, thinking about meal pairing, serving it over rice is a natural fit in Japanese cuisine, so I can mention that as an option. This makes the dish more filling and satisfying.

I need to keep the explanation simple but thorough enough for someone to follow without prior cooking experience. Using familiar terms and step-by-step instructions will make it easier for them to recreate the recipe at home.

シンキングの内容もすごいですね。
日本人や忙しそうだという所も意識して、考えてくれているようです。

・回答 Total:4’36”

キャベツ、人参、豚バラ肉を使って簡単にできるレシピはたくさんあります！例えば、「豚バラと野菜の炒め物」がおすすです。さっぱりとした味付けでヘルシーですし、具だくさんでお腹も満足します。

材料：

• 豚バラ肉：200g
• キャベツ：1/4個
• 人参：1本
• 長ねぎまたは玉ねぎ：適量（なくてもOK）
• 砂糖：小さじ1
• 酒：小さじ1
• 醤油：小さじ2
• 鍋用油：適量

手順：

1. 豚バラ肉を切る：薄切りにします。
2. 野菜を切る：キャベツは薄切り、人参はスリット（細長く削った形）または千切りにします。長ねぎも細切りにしてください。
3. 炒め物の仕込み：豚肉に砂糖、酒、醤油を混ぜて味を付けます。
4. 炒める：

• 鍋に油を熱し、豚肉を入れて軽く炒めます。
• 野菜を入れて一緒に炒めます。
• 全体がなじむように、強火でさっと炒めたら完成です！

チップス：

• 味付けの調整：醤油や酒の量を調節すれば、味濃いめやさっぱりめにもできます。
• 香辛料の追加：生姜チューブや刻み葱を入れると風味がアップします。

おすすめの組み合わせ：

• 米飯に乗せて食べるととてもおいしく感じます！

ぜひお試しください！ごちそうさま！

こちらは、一種類の提案ですが、かなり具体的に出してくれました。

４．猫を抱っこしている、メイちゃんイメージの画像生成用のプロンプトを日本語と英語で。

「gemma-2-27b-it-GGUF」 Total:１’3″

メイちゃんイメージ画像生成プロンプト

日本語:

美しい日本人女性「メイ」が、可愛い猫を抱っこしているイラスト。メイは20代後半、黒髪ロングヘアに、優しい笑顔。服装はシンプルなTシャツとジーンズ。背景は明るい室内。

English:

An illustration of Mei, a beautiful Japanese woman in her late 20s, holding a cute cat. Mei has long black hair and a gentle smile. She is wearing a simple T-shirt and jeans. The background is a bright indoor setting.

追加のポイント:

• 猫の種類、毛色などを指定するとより具体的にイメージを伝えられます。
• メイちゃんの表情やポーズも具体的に指示しましょう。
• atmosfer (雰囲気) や style (スタイル) を指定すると、画像のテイストを調整できます (例: 可愛い雰囲気, 水彩画風)。

日本人女性とか、２０代後半とか、髪型や服装など、具体的なプロンプトを考えてくれました。
このプロンプトをそのまま、Amuseの「iNiverse Mix XL」モデルに突っ込んでみます。

Image generation model ：iNiverse Mix XL /
Prompt generation :gemma-2-27b-it-GGUF

「優しい笑顔」のキーワードが効いているのか、笑顔がかわいいメイちゃんが出来上がりました。
壁に、漢字っぽい額があったり、なんとなく、和の雰囲気が出ています。
ただ、LLMには無関係ですが、猫の腕（足）が変ですね。
これは、画像生成Aiの問題ですが「Negative Prompt」でどうにかなると思います。

「DeepSeek-R1-Distill-Qwen-32B-GGUF」

・考える（Thought）42″

Okay, the user wants me to help generate image prompts for an illustration of “Mai-chan holding a cat.” They specified both Japanese and English versions. Let me start by understanding what they need.

First, Mai is described as a young Japanese woman with expertise in computers, IT, programming, and NC. She’s gentle and kind but has a strong resolve. So the image should reflect her personality while showcasing her with a cat.

I’ll break down the elements: Mai-chan, her appearance (maybe short hair, glasses), her expression (gentle smile), holding a cute cat, background details (like books or electronics to show her IT background). The overall vibe should be warm and harmonious.

For the Japanese prompt, I need to capture all these details clearly. Maybe start with the setting, then describe Mai’s features, her interaction with the cat, and the surrounding elements. Keep it vivid so the image generator can pick up on the nuances.

In English, I’ll translate those points but ensure they convey the same warmth and detail. Mentioning her expertise subtly through background items will help maintain the character’s depth without making it too literal.

I should also make sure both prompts are concise yet comprehensive, covering all aspects of Mai’s personality and surroundings to create a cohesive image.

メイちゃんがいつの間にかMai-chanになっているのは気になりますが
思考段階を翻訳してみると、やはりすごいです。
まず、system Promptから、メイちゃんの性格や外見を推測して、専門から背景を導きだしてます。
たぶん、「gemma」も、たった３行のsystem Promptから上のようなプロンプトをだしているので、内部的には、いろいろ推測していると思いますが、「deepseek」は「考える（Thought）」の内容も、表示してくれるので、その内容も興味深いです。

・回答 Total:2’45”

日本語プロンプト:

「猫を抱っこしているメイちゃんのイラスト。優しく穏やかな表情で、愛らしい猫を大切そうに抱いている姿。背景はシンプルで温かみのある空間。プログラミングやコンピュータ関連のアイテムがちらりと見える設定。全体的に柔らかい色合いと和谐感のあるイメージ。」

英語プロンプト:

“Illustration of Mai-chan holding a cat. A gentle and warm expression, carefully hugging a cute cat. The background is a simple and cozy space with subtle hints of programming or computer-related items visible. Overall soft color tones and a harmonious feel.”

こちらは、日本人とか、年齢などの指示はでてきませんでしたが、コンピュータ関連などの、システムプロンプトの内容が入ってきました。
ただ、「和谐感」という、わからない漢字が出てきましたが、英語のプロンプトを使うので画像生成にはあまり関係ないと思います。
こちらも、Amuseの「iNiverse Mix XL」モデルに突っ込んでみます。

Image generation model ：iNiverse Mix XL v1.1 /
Prompt generation :DeepSeek-R1-Distill-Qwen-32B-GGUF

日本人の指定はなかったですがsystem Promptから読み取り、「優しく穏やかな表情」というので、かなり清楚なメイちゃんになりました。
こちらも、LLMには関係ないですが、猫の腕（足）が変になりました。

感想

筆者が思いつく例題では、比較するにも、あまり差が見えませんでした。
ただ、最初にも書きましたが、「japanese」モデルは筆者の環境では、あまりよくなかったです。
また、「DeepSeek」は、回答の前に「考える」工程がありそうですが、その影響なのかは？？ですが、小さいモデルでは、時間の割にあまりいい結果にはなりませんでした。
コミュニケーションを楽しんだり、検索や翻訳サイトの延長で使う分には、「DeepSeek」を使う意味はあまり感じませんでした。
ただ、まずは「考える」と言うことで、質問内容によっては、時間がかかっても、大きめののモデルは試すのもありだと思います。
そういう意味では、オンラインの「DeepSeek」をやってみたいですが、ちょっと抵抗があります。