トラブルシューティング
ほとんどのNotemdの問題は、4つのカテゴリーに分類されます: APIの根本的な問題、ネットワーク接続の問題、認証エラー(401/403)、そしてレート制限(429)です。 組み込みの接続テスト機能と診断パネルにより、原因を迅速に特定できます。このページでは、よくあるエラーメッセージごとにその原因と解決策を説明しています。ここに記載されていない問題がある場合は、診断結果を添えてGitHub Issuesに報告してください。
これはObsidian AI知識管理ガイドの一部です。
概要
Notemdは外部サービス、つまりLLMプロバイダーや検索APIサービスに依存しているため、ほとんどの問題はプラグイン自体の外側で発生します。設定画面にある診断パネルでは、リクエストURL、レスポンスステータス、エラーボディを含む最後のAPI呼び出しの詳細が構造化されて表示されます。さらに調査を進める前には、必ずまずこちらを確認してください。
動作の仕組み:診断機能
接続テスト
各プロバイダーの設定セクションには**「テスト接続」**ボタンがあります。このボタンをクリックすると、最小限のAPIリクエスト(通常はモデル一覧や短い補完内容)が送信され、成功か具体的なHTTPエラーかが報告されます。これは、APIキーとベースのURLが正しいかを確認する最も迅速な方法です。
診断パネル
設定 --> Notemd --> 診断 には次のように表示されます:
| フィールド | コンテンツ |
|---|---|
| 最後のプロバイダー | 最後に呼び出されたプロバイダはどれですか |
| 最終モデル | 最後に呼ばれたモデルはどれですか |
| 最終ステータス | HTTP ステータスコードまたは転送エラー |
| 最後のエラー | APIからの生のエラーメッセージ |
| 最後のリクエスト URL | 前回のリクエストの全文 URL(APIキーは削除済み) |
| 最終のレスポンスボディ | 応答ボディが切り捨てられました(最初の500文字まで) |
GitHubで問題を報告する際は、診断結果の全内容をコピーしてください。
よくあるエラー
API キーが無効または見つかりません
症状: HTTP 401エラー、または「不正な API キーが指定されました」
原因: APIキーが欠落している、空白を含んでいる、または別のプロバイダに属しています。
修正:
- キーに先頭や末尾のスペースがないことを確認してください
- 選択したプロバイダとキーが一致しているか確認してください(OpenAIキーはAnthropicでは動作しません)。
- アカウントにクレジットがあるか、有効なサブスクリプションが契約されているかを確認してください。
- **「テスト接続」**をクリックして確認してください
ネットワーク/接続エラー
症状: ERR_CONNECTION_REFUSED, ERR_TIMED_OUT, Socket hang up, Network request failed
原因: お使いのマシンから API エンドポイントにアクセスできません。
修正:
- インターネット接続を確認してください。
- プロキシやファイアウォールの背後にいる場合は、APIドメインがブロックされていないことを確認してください
- Ollamaについて:
ollama serveが実行中であることを確認してください(ollama listはモデルを返すはずです) - LMStudioについて:
localhost:1234でサーバーが実行中か確認してください。 - 別のトランスポートを試してみてください。モバイルユーザーは
requestUrlトランスポートが有効になっていることを確認する必要があります。 - 一時的なエラー時の自動再試行のために
enableStableApiCallを有効にします
403 禁止されています
症状: HTTP 403
原因: お使いのAPIキーは有効ですが、要求されているリソースに対するアクセス権限がありません。
修正:
- 一部のモデルでは特別なアクセスが必要です(例えば、Azure経由のGPT-4にはデプロイメント名が必要です)。
- 一部のプロバイダーではプランの階層によってモデルが制限される場合があります。ご自身のアカウントを確認してください。
- 地域によって制限が適用される場合があります(中国の一部プロバイダーは海外のIPアドレスをブロックし、その逆も同様です)。
- モデル名が正しく綴られているか確認してください(例えば、ミニモデルのみが利用可能な場合は
gpt-4oでなくgpt-4o-miniとなっていないか)。
レート制限 (429)
症状: HTTP 429または「レート制限を超過しました」
原因: 短い時間内にリクエストが多すぎる。
修正:
batchConcurrencyを1または2に変換してください。- 再試行する前に数分待ってください。
- ご利用のプランティアについて、プロバイダーのレート制限に関するドキュメントを確認してください。
- バックオフ付きの自動再試行のために
enableStableApiCallを有効にします - より高い制限を持つプロバイダー(DeepSeek、Ollama)に切り替えることを検討してみてください。
モデルが見つかりません。
症状: 「モデルが見つかりません」または HTTP 404
原因: 選択したプロバイダー上にモデル名が存在しません。
修正:
- **「モデル一覧を取得」**をクリックすると、プロバイダで利用可能なすべてのモデルが表示されます
- 一部のモデル名は時間とともに変更されることがあります。プロバイダーのドキュメントで現在の名前を確認してください。
- Ollamaについて:プルされたモデルを確認するには
ollama listを実行してください。ダウンロードされたモデルのみが利用可能です
リンクなし/概念の生成なし
症状: コマンドは実行されますが、出力がありません
原因: LLMから空のレスポンス、または解析不可能なレスポンスが返されました。
修正:
- 実際のLLMレスポンスを確認するために、診断パネルをチェックしてください。
- より高性能なモデルを試してみてください(一部の小規模モデルは構造化された出力に対応しづらい場合があります)。
- そのメモには十分な内容(50語以上)が含まれていることを確認してください。
- 矛盾する指示がないか、カスタムプロンプトを確認してください。
- 一時的に同義語抑制を無効にして、過度にフィルタリングされていないか確認してください。
Doubao エンドポイントIDが欠落しています
症状: ByteDance Doubao プロバイダを使用する際にエラーが発生する
原因: Doubaoはモデル名の代わりにArkエンドポイントID(形式:ep-xxxxxxxx-xxxx-xxxx)が必要です。
修正方法: Volcengineコンソールから取得した実際のエンドポイントIDに、デフォルトのプレースホルダーモデルを置き換えてください。
設定
| 診断設定 | 場所 | 目的 |
|---|---|---|
| 接続テスト | 設定 --> プロバイダセクション | APIキーと接続性を確認します |
| モデル一覧を取得する | 設定 --> プロバイダセクション | どのモデルが利用可能か確認してください |
enableStableApiCall | 設定 --> 詳細設定 | バックオフ付きの再試行を有効にする |
batchConcurrency | 設定 --> バッチ処理 | レート制限を避けるために並行処理を制御する |
問題の報告方法
上記で対応できない問題の場合は:
- 設定 --> Notemd --> 診断を開きます
- 完全な診断出力をコピーしてください
- github.com/Jacobinwwey/obsidian-NotEMD/issuesにGitHub Issueを開きます。
- 含める項目:Obsidianバージョン、Notemdバージョン、プロバイダ、モデル、診断出力、および再現手順
- 共有されているログから API キーを削除してください
次のステップ
- LLM プロバイダー -- プロバイダー設定の完全な参照リファレンス
- バッチ処理 -- 大規模な操作における並行処理と再試行の設定
- カスタムプロンプト -- プロンプトを調整して予期しない LLM の動作を修正する