高度な設定
パワーユーザー向けに、Rephlo はパフォーマンス、AI の挙動、プロンプトキャッシュについてより細かい制御を提供します。基本設定とは異なり、これらの設定はいくつかの場所に分かれています——Space ごとのもの、プロバイダーごとやコマンドごとのもの、アプリ全体のものがあります。このページでは、それぞれの設定がどこにあり、何を行うのかをまとめて説明します。
トークン予算
Default Space Token Budget は Settings → General → Performance にあります。これは、新しい Space ごとの初期トークン上限を設定するもので、データモードと圧縮が関係してくるまでに、その Space がどれだけのドキュメント内容を保持できるかを決めます。
- スライダーの範囲: 5,000〜1,000,000 トークン(入力ボックスでは 1,000 まで下げられます)。
- デフォルト: 100,000 トークン。
- 新規の Space にのみ適用されます。各 Space は後から個別に予算を再設定でき、このデフォルト値を変更しても既存の Space が書き換えられることはありません。
同じセクションにある別の設定 chat browse-window size は、チャットサイドバーに一度に読み込む最近の会話数を制御します(10〜5,000。それより古いチャットは検索から引き続きアクセスできます)。これはデータの上限ではなく、パフォーマンス調整用のつまみです。
圧縮戦略
圧縮(Compaction)は、ドキュメントを要約することで Space のトークン消費を抑えます。これは、Space が 🗜️ Compact データモードに設定されている場合に適用されます(Space ごとのデータモードセレクターで選択します——個別のグローバルトグルはありません)。
- Space を Compact に切り替 えると、現在のファイルを要約するかどうかを尋ねられます。新しく追加したファイルは Space ビューから圧縮できます。要約の作成には credit を消費するため、Rephlo は必ず先に credit コストの確認を求めます——圧縮が無断で実行されることはありません。
- Credit ガード: Space が大きい場合(未圧縮の合計が約 128,000 トークン以上)、Compact は無効化されて圧縮がブロックされ、無料の Smart Search を利用するよう案内されます。単一の大きなファイル(約 50,000 トークン以上)を圧縮する場合は、追加の確認が表示されます。
- 圧縮を行う際、Rephlo は戦略と要約を行うモデルの選択を求めます。選択したモデルは、そのセッションの間は記憶されます。
3 つの戦略は、忠実度とトークン節約量のトレードオフになっています。
| 戦略 | 内容 | 最適な用途 |
|---|---|---|
| Conservative | 最も多くの詳細を保持し、トークン削減量は最小。 | トークン節約よりも精度が重要な場合。 |
| Balanced | 古いドキュメントを要約する——推奨されるバランス型(デフォルト)。 | ほとんどのプロジェクト。 |
| Aggressive | 最新の重要ポイントのみを保持し、削減量は最大だが詳細の損失も大きい。 | 非常に長い資料を小さいコンテキストウィンドウに収めたい場合。 |
Space がどちらのモードを使用していても、Rephlo は Space ごとに未圧縮のトークン合計と圧縮後のトークン合計 の両方を追跡するため、圧縮の効果を確認できます。Smart Search と Compact データの全体像、および圧縮がオンデバイスの検索(RAG)とどのように連携するかについては、データモードと圧縮 をご覧ください。
プロバイダーとモデルの調整
Temperature、最大応答長、コンテキストウィンドウはプロバイダーごと・モデルごとの設定です(コマンドごとの上書きも可能です)——単一のグローバル設定ではありません。これらは LLM Providers タブで設定します。詳しくは プロバイダー と プロバイダーの管理 をご覧ください。
Temperature
応答がどれだけ決定論的か、あるいは創造的かを制御します。デフォルトは 0.7(バランス型)です。
- 0.0〜0.3 — 正確で再現性が高い。コードや事実に適しています。
- 〜0.7 — バランス型。一般的な文章作成に適しています。
- 1.0 以上 — より創造的で多様な応答。ブレインストーミングに適しています。
Max Response Tokens
AI の応答の長さに上限を設け、一文だけで十分なときにエッセイのような長文を書かれないようにします。標準的なデフォルト値は 2,000 前後です。
コンテキストウィンドウの上限
BYOK/クラウドおよび Ollama 系のプロバイダーモデルの場合、これは Add/Edit Model ダイアログの Context Length フィールドに該当します。モデルに送信するテキスト量の上限を設定します。Auto のままにするとプロバイダーのデフォルト値が使用され、有料 API のコストを管理したい場合は手動で上限を設定できます。
オンデバイスモデルはこのフィールドを使用しません——厳選されたオンデバイスカタログではこの設定は無視されます。代わりに、専用の Context Window 設定(Settings → LLM Providers → On-Device の Model Memory カード内)があります: 範囲は 2,048〜262,144 トークン、デフォルトは約 32,768 です。値を大きくすると、より多くの RAM/VRAM を使用し、アクティブなモデルが再読み込みされます。
コマンドごとの上書き設定
個々のコマンドは、プロバイダー、モデル、Temperature、最大トークン数などのグローバル設定を上書きできます。コマンドの実行時には、コマンド自身の設定がグローバルなプロバイダーのデフォルト設定より優先されます。詳しくは 実行ワークフロー をご覧ください。
プロンプトキャッシュ
Rephlo は、対応しているプロバイダーにおいてプロンプトのキャッシュされたプレフィックスを再利用することで、コストとレイテンシを削減できます。キャッシュの設定はプロバイダー設定の中にあります。
- Enable prompt caching — 対応するリクエストでキャッシュを有効にします(デフォルトでオン)。
- Cache TTL — キャッシュエントリの有効期間:
- Ephemeral — 約 5 分。
- Extended — 約 1 時間。
- Cache logging — キャッシュのパフォーマンスに関する詳細な情報を記録します。
キャッシュの読み取りは大幅に割引されます。また、History の詳細ビューでは、リクエストごとのキャッシュ作成トークンとキャッシュ読み取りトークンが表示されるため、節約効果を確認できます。キャッシュは、リクエストにキャッシュ可能なプレフィックスがある場合(例: Space を添付したチャット)にのみ機能します。詳しい挙動については プロンプトキャッシュ をご覧ください。
開発者向けツール
これらはトラブルシューティングのための補助機能であり、日常的に使う設定ではありません。
- Debug Mode — アプリのログファイルへの詳細なロギングを有効にします。プロバイダーとの接続の問題を診断する際に役立ちます。
- Prompt Inspection — プロバイダーに送信された正確な JSON ペイロードを表示します。History の詳細から確認できます。
Environment switching(Production / Staging / Local API のエンドポイント)はデバッグビルドでのみ利用でき、通常のユーザー体験には含まれません。
関連: データモードと圧縮 · プロバイダー · プロンプトキャッシュ · History & Audit