Ollama Mockは、Ollama風の応答を返すテスト用サーバーです。GPUもモデル本体も不要ですが、回答の正しさは評価できません。本記事ではMac上で通常応答、ストリーミング、404・400・503、応答途中の異常を実際に確認しました。
ローカルLLMを使う社内チャットや検索ツールを作るとき、毎回モデルを起動するのは手間です。しかも、正常な回答は試せても「途中で応答が途切れたら画面はどうなるか」「モデル名を間違えたら利用者に何を表示するか」は見落としがちです。ここを先に試せるのが、kinduff氏のOllama Mockです。Ollama本体の公式機能ではなく、独立した開発者のプロジェクトです。
作者のShow HN紹介は2026年10月29日18:17 UTC、日本時間では10月30日3:17。リポジトリの作成日は10月27日ですが、それだけで一般公開の開始時刻は断定できません。この記事は10月30日に確認したコミット257cfdeを対象に、公開直後の使い方を整理します。
何が新しい？ 決まった一文を返すだけのモックではない
モックとは、本物の代役になるテスト用の部品です。たとえば、チャット画面の表示を作る段階なら、本物のLLMの推論を待たずに、代役が返した文章で吹き出しや停止ボタンを確認できます。Ollama MockはHTTPで接続するサーバーなので、接続先URLを差し替えて使う構成を取りやすいのが特徴です。
作者は、質問に応じた文章・JSON・ツール呼び出しなどの形、モデルの読み込み状態、待ち時間、エラーを模擬すると説明しています。対応APIと制約は確認版READMEにまとまっています。すべてのOllamaの挙動と完全一致することを保証するものではありません。
| 確認したいこと | モックを使う場面 | 本物のモデルで残す検査 |
|---|---|---|
| チャットの表示 | 応答を少しずつ受け取り、完了状態へ切り替える | 日本語の自然さ、回答内容、実際の応答時間 |
| エラー処理 | 未導入モデル・不適切なモデル用途・一時的な失敗を返す | 実機固有のメモリ不足や同時実行時の挙動 |
| 構造化データ | JSONを受け取る処理や保存先への受け渡しを組む | 文章から正しい値を抽出できるか |
| 検索・画像入力 | データの形や呼び出し経路を組む | 意味検索の精度、画像の認識精度 |
たとえば社内問い合わせ画面なら、回答の良し悪しを検証する前に「失敗時に再試行できるか」「途中の文を完成した回答として保存していないか」を検査できます。これは導入例であり、特定の社内システムで効果を測定した結果ではありません。
導入条件：Go 1.24以上。モデル料金は不要、ライセンスは要確認
| 項目 | 2026年10月30日の確認内容 |
|---|---|
| 必要なもの | Go 1.24以上。この記事の確認スクリプトはPython 3標準ライブラリのみ |
| GPU・モデル | 不要。モデル名は模擬応答を選ぶための指定で、モデル本体の取得ではない |
| OS | 本記事ではmacOS 27.0.1 / Apple Silicon / Go 1.27.3で確認。Windows・Linuxは未実測 |
| 費用 | ローカル試用で外部LLMのAPI料金は発生しない。Goやソースの初回取得には通信が必要 |
| 日本語 | 日本語の質問を送る用途にも使える接続口だが、生成する内容や日本語品質の評価には使わない |
| 利用条件 | 確認コミットのファイル一覧にLICENSEがなく、GitHubのlicense欄も未設定。会社での採用・改変・再配布の条件は別途確認が必要 |
「公開されたソースがある」ことと「自由に再配布できるライセンスがある」ことは別です。本記事ではオープンソースの利用許諾が確認できたとは扱いません。まず公式のブラウザーデモで雰囲気を確かめ、組織への組み込みは条件確認後に判断するのがよいでしょう。デモに機密情報を入力する必要はありません。
Macで試す：既存のOllamaとは別のポートで起動する
Goが導入済みなら、次の方法で確認版を取得できます。作業用フォルダーに移動してから実行してください。本記事では同じコミットを取得してGoでビルドしました。既定の11434番ポートを避け、11555番だけで待ち受けます。インターネットに公開する設定ではありません。
git clone https://github.com/kinduff/ollama-mockcd ollama-mockgit checkout 257cfde1590ac0eb732ec03ba08bee9230c25e5fgo build -o ollama-mock ./cmd/ollama-mock./ollama-mock -addr 127.0.0.1:11555 \ -models qwen3:8b,nomic-embed-text \ -latency 0 -fixed-time 2026-10-30T00:00:00Zここでqwen3:8bを指定しても、Qwenの重みはダウンロードされません。-latency 0は模擬的な待ち時間を無くす設定です。-fixed-timeは応答中の日時を固定する設定で、試験の日時を表しているわけではありません。実行環境の日時そのものは変更しません。
curl -sS http://127.0.0.1:11555/api/chat \ -H 'Content-Type: application/json' \ -d '{"model":"qwen3:8b","stream":false,"think":false,"messages":[{"role":"user","content":"Explain a retry policy briefly."}]}'成功すると、message.contentにテスト用の文章、doneにtrueが入ります。文章を読んで「賢い」と評価する試験ではありません。アプリに必要なフィールドを受け取れるかを見ます。既存アプリで試す際も、開発用設定だけをこのURLへ向け、最後に本来の接続先へ戻してください。
実測：8項目で正常系と異常系を確かめた
再現用に確認スクリプトをダウンロードできるようにしました。先ほどの専用モックを起動し、保存したファイルを次のように実行します。接続先は127.0.0.1:11555に固定しています。スクリプトはモックの障害設定を置き換えるため、ほかのテストと共用しないでください。
python3 check_ollama_mock.py| 確認項目 | このMacでの結果 |
|---|---|
| モック専用の状態API | /_mock/stateで状態を取得 |
| 通常の応答 | HTTP 200、文章あり、done:true |
| 同じ質問を繰り返す | message.contentが一致 |
| 通常のストリーミング | 最終行のdone:trueを確認 |
| 未導入のモデル名 | HTTP 404 |
| 埋め込み用モデルに文章生成を要求 | HTTP 400 |
| 一時的な障害を注入 | 指定したHTTP 503を受信 |
| 2トークン後の異常を注入 | HTTP 200のままerror行を受信。done:trueなし |
これはOllama Mock自体と教材の動作確認です。読者のアプリの検査が済んだわけではなく、本物のQwenやOllamaと比較した性能試験でもありません。検査では生成文章の一致を確かめました。初回の読み込み状態や時間なども含めた応答全体のバイト一致は、この教材では検証していません。
一番見落としやすい失敗：HTTP 200でも回答は完成していない
ストリーミングは、回答を小分けに送り続ける仕組みです。Ollamaのこの形式では、一行ごとにJSONが届きます。NDJSONと呼ばれる形式で、受け取った行を順番に解釈します。HTTPの開始時点で成功を示す200が返っていても、その後の生成処理で失敗することがあります。
今回の模擬障害でも、HTTP 200の後にerrorを含む行が届き、完了を表すdone:trueはありませんでした。最初のHTTPステータスだけで「成功」と決めると、途中までの文章を完成品として保存してしまう可能性があります。
completed = Falsefor line in response_lines: # 受信した各行を渡す。接続処理は省略。 if not line.strip(): continue chunk = json.loads(line) if "error" in chunk: raise RuntimeError(chunk["error"]) if chunk.get("done") is True: completed = True
if not completed: raise RuntimeError("回答の完了を確認できませんでした")アプリ側では、受信中・完了・失敗・中止を分け、途中の出力には未完了であることを表示します。503を受けたときの再試行も無限に繰り返さず、上限や待ち時間を設けます。ツール実行を伴う処理なら、再試行による二重実行にも注意が必要です。これらは今回の異常応答から考えられる設計上の確認事項です。
モデルの速度・推論能力・日本語の正確さは測れない
モックのtotal_durationなどは模擬値です。-latency 0で待ち時間を無くしても、応答中の時間情報は実時間になりません。これを使って「このMacでQwenが何tokens/s出た」と書くのは誤りです。
同様に、thinkingという項目が出ても実際の推論能力を証明しません。画像は内容を認識するのではなく入力の枚数を扱う仕組みで、埋め込みも実モデルによる意味理解の代わりにはなりません。未知のモデル名では、名前から機能を推定する処理もあります。新モデルの仕様確認に利用しないでください。詳細は実装の説明を参照できます。
日本語の業務文書から正しい担当者名を抽出できるか、検索で必要な資料が上位に出るか、実機でメモリが足りるか、といった検査は本物のモデルを使って別に行います。モックで周辺処理を安定させてから実モデルの評価へ進むと、問題の原因を切り分けやすくなります。
仕事に取り入れるなら、この順番で
- 1利用条件を確認し、開発用の接続先を本番と分ける。最初はこの教材のような専用モックで挙動を確かめる。
- 2自分のアプリをモックへ接続し、通常完了・404・503・途中失敗の画面、ログ、保存データを確認する。教材のPASSだけでアプリの合格とはしない。
- 3CI（変更のたびに自動実行する検査）へ周辺処理のテストを移す。モデルが実行されないことをテスト名やログに残す。
- 4接続先を本物に戻し、日本語の回答品質、ツール選択、検索精度、速度・メモリを少数の固定課題で再確認する。
このアプリのOllama接続処理を読み、通常完了、未導入モデルの404、一時的な503、HTTP 200後のストリーム内error、done:trueなしの終了を扱うテストを提案してください。kinduff/ollama-mockの確認コミットは257cfdeです。モックの専用ポートは127.0.0.1:11555、本番設定は変更しません。UIの状態、途中データの保存、再試行上限、二重実行の防止を別々に確認してください。モックで検証できない回答品質・日本語精度・実機性能は、実モデルで検証する項目として分けてください。テストを実行していないのに成功と報告しないでください。ローカルLLMを選ぶ段階はPumpkinのモデル・実行環境の比較、AIがシェルを使う際の確認はShellfirmのコマンド保護も参照できます。Ollama Mockが受け持つのは、その間にある「アプリが返答や失敗を正しく扱えるか」の検査です。
確認日：2026年10月30日。対象：kinduff/ollama-mock、コミット257cfde1590ac0eb732ec03ba08bee9230c25e5f。一次資料：公式リポジトリ、確認版README、サーバー実装、Native API実装。公式のリリースタグは確認時点ではありません。/api/versionに表示される0.40.6は模擬APIの応答設定で、Ollama Mockのリリース版番号として扱っていません。