6・7日目　ローカルLLMとAI連携

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen2.5:0.5b

1行目は「インターネットから取ってきたスクリプトを、中身を見ずにその場で実行する」書き方です。手軽ですが、配布元を信用することが前提になります考察のヒント考察のヒント「取ってきたプログラムを中身を見ずに実行する」便利さと、その配布元を信用しなければならないことは引き換えです。ソフトウェアの入手方法の安全性として、考察で触れられます。（中身を確かめたいときは、いったんファイルに保存して読んでから実行する方法もあります）。インストールの途中で、Ollamaがサービスとして登録され、自動で起動します。

WARNING: No NVIDIA/AMD GPU detected. Ollama will run in CPU-only mode. と出るのは正常です。GPUがないのでCPUだけで動く、という知らせです。

2行目の ollama run は、初回はモデルをダウンロード（約400 MB）してから、会話の画面を開きます。

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

>>> の後ろに質問を打って Enter を押すと、答えが少しずつ表示されます。会話を終えるには /bye と打つか、Ctrl+D を押します。

指導書では「WindowsのPowerShellから、curlを使ってUbuntu上のOllama APIにプロンプトを投げる」とあり、実際のコマンドは「結果と考察」に載っています（エビデンス1）。ただし、そのままではつながらない理由が2つあるので、順に確かめます。

(1) まずサーバーの中から試す

curl http://localhost:11434
curl http://localhost:11434/api/generate -d '{
  "model": "qwen2.5:0.5b",
  "prompt": "高専について教えて",
  "stream": false
}'

1行目で Ollama is running と返れば、Ollamaは動いています。2行目で答えのJSONが返れば、APIも使えています。Ubuntuのcurlは、日本語を含むJSONも正しく送れます。-d は「このデータを送る」という指定です。

(2) Windowsから届かない理由

今どこで待ち受けているかは、次のコマンドで分かります。

ss -tln | grep 11434

127.0.0.1:11434 と出れば「自分自身からしか受け付けない」状態です。外から受け付けるようにするには、Ollamaのサービスの設定に環境変数 OLLAMA_HOST を追加します。

sudo systemctl edit ollama

エディタが開いたら、### Anything between here and the comment below will become the contents of the drop-in file という行と、その下の ### Edits below this comment will be discarded という行の間に、次の2行を書いて保存します。

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

sudo systemctl daemon-reload
sudo systemctl restart ollama
ss -tln | grep 11434
sudo ufw allow 11434/tcp

0.0.0.0 は「どの宛先でも受け付ける」という意味です。ss の表示が *:11434 や 0.0.0.0:11434 に変われば成功です。最後にufwで11434番を開けます。この変更は、手順6以降でOpen WebUIのコンテナがOllamaに問い合わせるためにも必要になります（コンテナから見ても、Ollamaは「外」にいるからです）。

(3) Windowsから呼ぶ

指導書の「PowerShell（参考）」の例は、次の理由でそのままでは動きません（このガイドの作成時にWindows 11で確認しました）。

• Windows 11 標準の PowerShell 5.1 では、curl が別のコマンド（Invoke-WebRequest）の別名になっていて、-d を解釈できずにエラーになる。curl.exe と書いて本物のcurlを呼んでも、JSONの中の " が消えてしまう
• PowerShell 7 では curl が動くが、日本語の質問が文字化けした状態で送られる

どちらの版でも確実に動くのは、PowerShellに備わっている Invoke-RestMethod を使う書き方です。

$body = @{ model = "qwen2.5:0.5b"; prompt = "高専について教えて"; stream = $false } | ConvertTo-Json
$res = Invoke-RestMethod -Uri "http://192.168.100.xxx:11434/api/generate" -Method Post -ContentType "application/json; charset=utf-8" -Body ([System.Text.Encoding]::UTF8.GetBytes($body))
$res.response

返ってきたJSON全体を見たいときは $res | ConvertTo-Json とします。CPUだけで動いているので、答えが返るまで数秒〜数十秒かかることがあります。初回はモデルの読み込みがあるので、特に時間がかかります。1エビデンス1の撮影ポイント撮影ポイント　エビデンス1手順2の(3)で Invoke-RestMethod を実行し、$res.response で答えの文章が表示された時点。3行のコマンドと答えが1枚に入るように撮る（指導書の「結果と考察」の最初の確認にあたる）。エビデンス一覧の項目へ移動 ↓

sudo docker network create app-net
sudo mkdir -p /opt/open-webui
sudo mkdir -p /opt/nginx/conf.d

app-net は、Nginxのコンテナと、これから作るOpen WebUIのコンテナを同じ輪に入れるためのDockerネットワークです。同じネットワークに参加したコンテナは、open-webui のようにコンテナの名前で相手を呼べるようになります。別々のcompose.yamlで作るコンテナどうしをつなぐので、Composeの外で先に作っておきます。

sudo nano /opt/nginx/compose.yaml

services:
  nginx:
    image: nginx:stable
    container_name: nginx-proxy
    ports:
      - "80:80"
    volumes:
      - /opt/nginx/html:/usr/share/nginx/html:ro
      - /opt/nginx/conf.d:/etc/nginx/conf.d:ro
      - /opt/nginx/log:/var/log/nginx
    networks:
      - app-net
    restart: unless-stopped
  goaccess:
    image: allinurl/goaccess
    container_name: goaccess-report
    profiles: ["tools"]
    volumes:
      - /opt/nginx/log:/srv/log:ro
      - /opt/nginx/html:/srv/report
    command:
      - --log-format=COMBINED
      - -f
      - /srv/log/access.log
      - -o
      - /srv/report/goaccess-report.html

networks:
  app-net:
    external: true

cd /opt/nginx
sudo docker compose config
sudo docker compose up -d
sudo docker compose ps

ps で nginx-proxy が Up になっていることを確かめます。2エビデンス2の撮影ポイント撮影ポイント　エビデンス2手順4で定義を更新し、/opt/nginx で sudo docker compose up -d のあとに sudo docker compose ps を実行した直後。nginx-proxy の STATUS が Up であることが分かるように撮る（最後の確認コマンドで撮り直してもよい）。エビデンス一覧の項目へ移動 ↓

sudo nano /opt/open-webui/compose.yaml

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    environment:
      - OLLAMA_BASE_URL=http://host.docker.internal:11434
    extra_hosts:
      - "host.docker.internal:host-gateway"
    volumes:
      - open-webui:/app/backend/data
    networks:
      - app-net
    restart: unless-stopped

volumes:
  open-webui:

networks:
  app-net:
    external: true

最後の点は大事な設計です。Open WebUIは ports: を持たないので、Windowsから直接は届きません。入口を受付係のNginx 1か所にまとめることで、管理がしやすくなり、余計な窓口も開きません。考察のヒント考察のヒント入口を1か所にまとめる設計は、管理のしやすさ（設定・ログ・証明書を1か所で扱える）と安全（外に開く窓口が少ない）の両面から評価できます。構成図と合わせて説明すると、「連携の考察」になります。

cd /opt/open-webui
sudo docker compose config
sudo docker compose up -d
sudo docker compose ps
sudo docker compose logs --tail 20

Open WebUIのイメージは数GBあるので、初回のダウンロードには時間がかかります。起動したあとも、初回は準備に数分かかることがあります。logs に Uvicorn running on http://0.0.0.0:8080 のような行が出れば、受付の準備ができています（まだ出ていなければ、しばらく待ってから logs を見直します）。3エビデンス3の撮影ポイント撮影ポイント　エビデンス3手順6で、/opt/open-webui で sudo docker compose ps を実行した直後。open-webui の STATUS が Up になっていることが分かるように撮る（起動直後は health: starting と表示されることがあり、準備ができると healthy に変わる）。エビデンス一覧の項目へ移動 ↓

sudo nano /opt/nginx/conf.d/open-webui.conf
cd /opt/nginx
sudo docker compose exec nginx nginx -t
sudo docker compose exec nginx nginx -s reload

指導書には「location / の中で proxy_pass http://open-webui:8080; を記述し」とだけ書かれています。ファイル全体の例は次のとおりです。

server {
    listen 80;
    server_name _;

    location / {
        proxy_pass http://open-webui:8080;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout 300s;
    }
}

docker compose exec nginx …

動いている nginx のコンテナの中で、続くコマンドを実行する

nginx -t

設定の書式を検査する。syntax is ok と test is successful が出れば問題なし

nginx -s reload

止めずに、新しい設定を読み込み直す

ブラウザで http://192.168.100.xxx/ を開くと、Open WebUIの画面が表示されます。4エビデンス4の撮影ポイント撮影ポイント　エビデンス4手順7で nginx -s reload のあと、ブラウザで http://192.168.100.xxx/ を開き、Open WebUIの画面（初回はアカウント作成の画面、ログイン後はチャットの画面）が表示された時点。URL欄も写るように撮る。エビデンス一覧の項目へ移動 ↓

最後に、自分でAIチャットのWebサイトを組み立てます。指導書の指示は「index.html に入力フォームを作成し（Webフロントエンド）、PHPやPython(Flask)等を用い、Webフォームの入力をOllama APIに転送し、結果を表示する」で、作り方は自由です。

3つの部品の役割

ブラウザから直接OllamaのAPIを呼ばずに、間にバックエンドをはさむのには理由があります。ブラウザには、ほかの場所のAPIを勝手に呼べないようにする仕組み（CORS）があるうえ、Ollamaの住所を外に見せることにもなります。バックエンドがあれば、入力が空でないか確かめたり、使うモデルを固定したりもできます。課題3は、この3つの部品の役割とデータの受け渡しを説明するものです。考察のヒント考察のヒントバックエンドをはさむ理由（ブラウザの制限、住所を隠す、入力の確認、モデルの固定）は、課題3で3つの部品の役割分担を説明するときの根拠になります。各区間で実際に送ったJSONの中身を示すと具体的になります。

作る前に決めること

• バックエンドの言語：指導書は PHP や Python（Flask）を例に挙げている
• どこで動かすか：Ubuntuに直接か、コンテナか。コンテナにして app-net に参加させると、Nginxから名前で取り次げ、ufwの影響も受けない
• どのURLで公開するか：/ はOpen WebUIが使っているので、/chat/ のように別の場所に割り当てる
• Ollamaをどう呼ぶか：コンテナからなら、Open WebUIと同じく host.docker.internal:11434

完成したら、ブラウザで質問を送り、答えが表示された画面を撮ります。5エビデンス5の撮影ポイント撮影ポイント　エビデンス5手順8で自作のAIチャットに質問を送り、答えが表示された時点。質問と答えの両方と、URL欄が写るように撮る。答えが出るまで数十秒かかることがある。エビデンス一覧の項目へ移動 ↓

sudo mkdir -p /opt/chat-app
sudo nano /opt/chat-app/app.py

import json
import os
import urllib.request

from flask import Flask, jsonify, request, send_from_directory

OLLAMA_URL = os.environ.get("OLLAMA_URL", "http://host.docker.internal:11434/api/generate")
MODEL = os.environ.get("MODEL", "qwen2.5:0.5b")

app = Flask(__name__)


@app.get("/")
def index():
    return send_from_directory(".", "index.html")


@app.post("/api/chat")
def chat():
    data = request.get_json(silent=True) or {}
    prompt = str(data.get("prompt", "")).strip()
    if not prompt:
        return jsonify(error="質問が空です"), 400

    body = json.dumps({"model": MODEL, "prompt": prompt, "stream": False}).encode("utf-8")
    req = urllib.request.Request(OLLAMA_URL, data=body,
                                 headers={"Content-Type": "application/json"})
    try:
        with urllib.request.urlopen(req, timeout=300) as res:
            answer = json.load(res).get("response", "")
    except Exception as e:
        return jsonify(error=f"Ollamaに接続できません: {e}"), 502

    return jsonify(answer=answer)


if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000)

sudo nano /opt/chat-app/index.html

<!doctype html>
<html lang="ja">
<head>
  <meta charset="utf-8">
  <title>T3 AI Chat</title>
</head>
<body>
  <h1>T3 AI Chat</h1>
  <form id="form">
    <textarea id="prompt" rows="3" cols="50" placeholder="質問を入力"></textarea><br>
    <button type="submit">送信</button>
  </form>
  <pre id="answer"></pre>
  <script>
    document.getElementById("form").addEventListener("submit", async (e) => {
      e.preventDefault();
      const out = document.getElementById("answer");
      out.textContent = "考え中…";
      const res = await fetch("api/chat", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ prompt: document.getElementById("prompt").value })
      });
      const data = await res.json();
      out.textContent = data.answer ?? data.error;
    });
  </script>
</body>
</html>

sudo nano /opt/chat-app/compose.yaml

services:
  chat-backend:
    image: python:3.12-slim
    container_name: chat-backend
    working_dir: /app
    volumes:
      - /opt/chat-app:/app:ro
    command: sh -c "pip install --no-cache-dir flask && python app.py"
    environment:
      - OLLAMA_URL=http://host.docker.internal:11434/api/generate
      - MODEL=qwen2.5:0.5b
    extra_hosts:
      - "host.docker.internal:host-gateway"
    networks:
      - app-net
    restart: unless-stopped

networks:
  app-net:
    external: true

cd /opt/chat-app
sudo docker compose up -d
sudo docker compose logs --tail 20

location = /chat {
    return 301 /chat/;
}

location /chat/ {
    proxy_pass http://chat-backend:5000/;
    proxy_set_header Host $host;
    proxy_read_timeout 300s;
}