AnythingLLM Max Tokens：長い回答が途中で切れる原因と対処法

AnythingLLMの長い回答が文の途中で止まったら、まず Max Tokensによって出力が制限されていないか確認してください。コンテキストウィンドウを広げることと、プロキシのタイムアウトを延ばすことは、同じ問題の代替策ではありません。実際に送信された出力予算、上流APIの finish_reason、条件を一つだけ変えた再テストを使い、元の設定を残しながら調べます。

終了時の証拠から対処を選ぶ

画面に文字が出なくなったこと自体は、原因ではなく症状です。 OpenAI Chat Completionsの定義では、length はリクエストで指定したトークン上限に達したことを表します。stop は自然な終了だけでなく、指定した停止シーケンスによる終了の場合もあります。tool_calls はツール呼び出しへの移行であり、最終回答の完成ではありません。互換APIでは、利用するサーバーの実際の動作も確認してください。

確認できた証拠	優先して調べること	次の操作
上流が finish_reason=length を返し、実際の出力予算も確認できる	出力上限	入力を固定し、対応範囲内の出力予算だけを変更する
サーバーが明示的にコンテキスト超過を報告し、履歴や取得文書を減らすと同じタスクが完了する	コンテキストの圧迫	入力を減らし、モデル本来のウィンドウを確認する。出力枠だけを増やさない
タイムアウト、接続リセット、キャンセルの記録がある、または終了理由が見えないままストリームが終わる	接続、キャンセル、ストリーミング互換性	時刻を照合して終了した層を探す。フィールドがないだけではネットワーク障害と断定できない
stop が返ったが、章や番号付き項目が抜けている	指示、停止シーケンス、内容の完全性	欠落を調べる。正常終了とタスク完了を同一視しない

出力予算は、1回のリクエストで生成できる量を制限します。コンテキストウィンドウは、モデルが処理できるコンテキストの容量です。履歴、システム指示、検索で取得した文書の抜粋も入力に含まれ得ます。AnythingLLMの Generic OpenAIアダプターはそれらを組み立てるため、質問が短くてもリクエスト全体は大きくなります。画面に大きなウィンドウ値を入力しても、サーバー上のモデルの能力は拡張されません。

issue #6703のユーザー報告には、出力上限による切断だったのに、先にリバースプロキシやWebSocketのタイムアウトを調べてしまったという経験があります。出力設定から調べる順序の参考にはなりますが、あなたの環境も同じ原因だと証明するものではありません。

元の設定を残し、実際に使うモデルを確認する

変更する前に、現在の状態を記録してください。 AnythingLLMのバージョン、Desktopかセルフホストか、グローバルのプロバイダー、ワークスペースとチャットで選んだプロバイダーとモデル、agent利用の有無、コンテキストと出力の設定を控えます。スクリーンショットではキーを隠し、実験のために元のワークスペース、会話、索引済み文書を削除しないでください。

SettingsのLLMプロバイダー設定を開き、テストが本当に Generic OpenAI を使っているか確認します。公式設定ガイドは、APIの機能と推論レスポンス形式の両方でOpenAI互換であることを求めています。別のプロバイダーを使うリクエストは、Generic OpenAIを変更しても設定できません。

2026-10-16 に確認した公式UIソースには、次の項目があります。

項目	確認する内容
Base URL、API Key、Selected Model	以前に成功した接続先、対応するキー、正確なモデル識別子。表示名から識別子を推測しない
Model context window	設定上のコンテキスト容量。回答の出力予算とは別物
Max Tokens	生成の出力予算。コンテキスト設定とは分けて確認する

保存後に設定を開き直し、値が残っていることを確認します。閲覧権限のある上流リクエスト記録があれば、実際の model と出力上限フィールドも照合してください。スクリーンショットが証明するのは表示内容であり、サーバーが受け取った内容ではありません。通常チャットとagentも別々に確認します。Desktop v1.16.2の更新履歴には、Generic OpenAIのagentストリームでmax tokensが無視される問題の修正が記載されています。

すでにBetterTokenを利用している場合は、この段階で Chat Completionsの接続ガイドと現在の接続先、キー、モデル設定を照合できます。ただし、これは設定確認のための参照先であり、AnythingLLMの全機能の互換性や出力上限の撤廃を保証するものではありません。

0、パラメーター名、バージョンを混同しない

0 は無制限出力ではありません。 Desktop v1.17.0の更新履歴は、Generic OpenAIで 0 を指定すると、リクエストから max_tokens を省略できると説明しています。その場合も上流の既定値や制限が適用されます。原因を調べる際は、モデルが対応する明示的な正の出力予算を指定した方が比較しやすくなります。

2026-10-16 に確認したアダプターのソースでは、出力値は GENERIC_OPEN_AI_MAX_TOKENS、ウィンドウ値は GENERIC_OPEN_AI_MODEL_TOKEN_LIMIT から取得します。出力フィールドの既定名は max_tokens で、GENERIC_OPEN_AI_MODEL_MAX_TOKEN_KEY により別の名前を指定できます。これは確認したソースの動作であり、すべてのインストール済みバージョンが同じ設定を提供するという意味ではありません。

互換APIのパラメーターを一律に改名しないでください。OpenAIの現行パラメーター定義にある max_completion_tokens は、表示される出力だけでなく推論トークンも予算に含みます。見えている文章が短くても、予算を使い切る場合があるわけです。実際のバックエンドとモデルが受け付けるフィールドを確認し、利用バージョンが対応している場合にだけ該当設定を変更します。

Desktopでは画面から設定し、コピーした例を頼りに .env を編集しないでください。公式設定文書は、その手順をセルフホストまたはDocker向けと明記しています。v1.17.0ではワークスペース設定の保存方法も変わりました。同じ保存ボタンがあると思い込まず、開き直したときの値で保存を確認します。

finish_reasonと実際の使用量を取得する

優先するのは、モデルサービスからAnythingLLMに返されたレスポンスです。 非ストリーミングのChat Completionsなら、choices[0].finish_reason と返された usage を確認します。ストリーミングなら終了理由を持つチャンクを探し、サーバー側の完全な終了シーケンスが届いたか確認してください。最初のチャンクの空値は最終状態ではありません。公式レスポンス定義が判断の基準になります。

Web画面やセルフホストのWeb画面では、ブラウザー開発者ツールのNetworkを開き、ログを保持して1回だけ問題を再現します。該当チャットリクエストの時刻、状態、レスポンスを控えてください。ただし、見ているのは ブラウザーとAnythingLLMの間 であり、モデルサービスの生レスポンスとは限りません。

2026-10-16 に読んだGeneric OpenAIのストリーム処理では、上流に空でない終了理由があると、理由をそのままUIに送る代わりにAnythingLLM独自の close: true メッセージへ変換します。プロバイダーの使用量がない場合には、テキストチャンク数を使う推定もあります。そのため、画面上の終了表示やトークン数だけでは、内容の完成や正確な上限到達を確認できません。

閲覧を許可されたモデルサービスのログやリクエスト詳細から、元の終了理由と使用量を取得します。取得できなければ、管理者にリクエスト時刻と識別子を伝えて調査を依頼してください。Desktop v1.16.2の更新履歴には、ウィンドウ上部のバージョン表示からログとストレージを開く方法があります。ただし、その場所が開けても、そのバージョンが元の終了フィールドを記録するとは限りません。

ストリームの最終使用量は届かない場合もあります。OpenAIの説明では、中断やキャンセルにより最後のusageチャンクを受信できないことがあります。未取得なら「取得できず」と記録し、ゼロとして扱わないでください。アプリ側の推定値を請求データの代わりに使うことも避けます。

元の設定を残した短文・長文テストを行う

まず呼び出し経路を固定し、次に求める出力の長さだけを変えます。 ナレッジ文書を添付していないテスト用ワークスペースを使い、同じプロバイダーとモデルを選びます。システム指示、温度、出力予算、その他の設定を固定し、各テストは別の空のチャットで始めてください。2回目に1回目の履歴を引き継がせず、最初はagentやツールなしの通常チャットで試します。

短い回答のテストA：

プロジェクト文書を管理するための提案を3項目挙げてください。各項目を2–3文で説明し、すべて完了したら最後に [END] を独立した行で書いてください。

長い回答のテストB：

プロジェクト文書を管理するための提案を20項目挙げてください。各項目を2–3文で説明し、すべて完了したら最後に [END] を独立した行で書いてください。

送信したら生成終了まで待ち、停止ボタンを押したり画面を更新したりしないでください。タイムアウトや切断が起きた場合は、連続で再試行せず時刻を記録します。表示された回答全文をローカルの A.txt、B.txt にコピーしてください。リクエスト時刻、実際のモデルと出力予算、終了理由、usageがプロバイダー報告かどうか、最後の番号と [END] の有無も残します。ここでの数字はテストの指示であり、モデルの上限や必ず返る長さではありません。

Aが完了してBが未完了でも、分かるのは長い出力の場面で問題が出ることまでです。まだMax Tokensが原因とは断定できません。 Bが length を返した場合は、Bと同一のプロンプトと他の設定を維持し、出力予算だけをサーバーが許す明示的な大きい値に変えて、空のチャットでCを実行します。C.txt に保存し、20項目すべて、終了マーカー、length 以外の終了が確認できれば、そのケースでは予算変更が有効だったと判断する材料になります。

Bがすでに完了するなら、予算をむやみに増やす必要はありません。同じ実業務のタスクを元の会話と空のチャットで比較し、出力設定は固定します。履歴や取得文書があるときだけ問題が出るなら、コンテキストを調べます。不要になった一時設定は戻し、最初の記録は残してください。有料APIのテストには通常の呼び出し料金が発生する場合があります。

証拠に合う設定だけを修正する

出力上限が確認できたら、予算と送信フィールドを直す

実際の呼び出し経路で使われる予算だけを、モデルの対応範囲内で増やします。画面の値は増えたのに送信内容が変わらない場合は、プロバイダー選択、保存、バージョン、通常チャットとagentの違いを確認してください。サーバーまで届かない出力設定は、コンテキストを増やしても直りません。

コンテキスト超過なら、タスクと出力予算を固定して入力を減らす

最初に、同じ長いタスクを空のチャットで再実行します。その後、取得する文書の抜粋や不要な履歴を一つずつ減らします。サーバーが明示的にコンテキスト上限を報告したら、実際のモデル容量に合うウィンドウを設定してください。大きい数を入力しても拡張にはなりません。明示的なエラーなしに空のチャットで改善しただけなら、コンテキストは引き続き確認すべき仮説です。

接続やストリームの異常なら、切れた層を先に特定する

同じ時間帯のブラウザー、AnythingLLM、上流APIの記録を照合し、キャンセル、タイムアウト、接続終了を探します。上流が完成させたのにブラウザーには一部しか届いていないなら、中間の伝送や表示処理を調べます。上流自体が失敗していれば、そのエラーへの対処を優先します。タイムアウトを変更するのは、ログが該当する層を示してからです。

セルフホストまたはDockerの管理者は、ストリーミングを別の比較として無効化できます。公式設定の GENERIC_OPENAI_STREAMING_DISABLED="true" はGeneric OpenAIだけに作用し、変更後は対象サービスまたはコンテナを再起動します。他の条件を変えず同じ長いプロンプトを実行し、テスト後は元の値に戻して再起動してください。非ストリーミングで成功すれば調査範囲をストリーム関連の経路に絞れますが、プロキシが原因だと確定するわけではありません。Desktopではこの .env 操作を行いません。

修復完了の判断と、まだ失敗する場合の報告

回答が長くなっただけでは修復完了ではありません。 必要な章や番号がそろい、最後の文が完結し、終了マーカーがあることを確認します。元の終了理由と接続ログも合わせて見て、再度切れていないか確かめてください。stop も [END] も内容確認の代わりにはなりません。簡略化したテストだけでなく、元々失敗した実際のタスクも再実行します。

解消しなければ、バージョンと設置方法、通常チャットかagentか、プロバイダーとモデルの識別子、機密を除いた設定、最小プロンプト、A/B/Cの差、時刻、取得できた元の終了理由を管理者に渡します。APIキー、認証ヘッダー、非公開文書の本文は削除し、ないフィールドは「取得できず」と記録してください。次の調査を具体的なリクエストから始められ、またプロキシ設定の推測に戻るのを防げます。