OpenAI プロバイダー
OpenAIは、共有されているOpenAI互換のトランスポートを使用しています。 現在のプリセットでは、gpt-4o、https://api.openai.com/v1、temperature: 0.5、およびmodels-then-chat接続テストがデフォルトで設定されています。正確なフィールドの意味を必要とする場合はこのページを使用し、カテゴリレベルでの選択についてはLLMプロバイダーの概要をご覧ください。
これはObsidian AI知識管理ガイドの一部です。
セットアップ
OpenAI APIキーを作成し、Notemdの設定にOpenAIプロバイダープロファイルを追加します。意図的にOpenAI対応のゲートウェイを指定していない限り、デフォルトのBase URLのままにしておきます。モデルフィールドは一般的な作業ではgpt-4oのままにしてもよく、またはアカウントで呼び出せる別のOpenAIモデルIDに置き換えても構いません。
コスト管理のためにタスク別のモデルを利用しましょう。研究、概念抽出、長文の再構成にはより高性能なモデルを使用し、翻訳、リンク提案、短い要約にはより安価または高速なモデルを利用します。
エンドポイントと認証
| フィールド | 現在のプリセット |
|---|---|
| 転送 | openai-compatible |
| APIキー | 必要です |
| ベース URL | https://api.openai.com/v1 |
| デフォルトモデル | gpt-4o |
| 温度 | 0.5 |
| 接続テスト | /models、次に/chat/completions |
Notemdは、chat/completionsやmodelsを追加する前に、OpenAI互換のベースURLsを正規化します。Base URLには末尾の/chat/completionsを含めないでください。そうしないとパスが重複してしまいます。
モデル検出
OpenAIは、汎用的なOpenAI互換のモデル検出パスを使用しています。設定UIではまず/v1/modelsに問い合わせ、その後軽量なチャットリクエストを使って選択されたモデルを検証します。検出に失敗してもチャットが正常に動作する場合は、ご自身のキーにモデル一覧の権限があるか、またはゲートウェイがモデル一覧をブロックしていないかを確認してください。
推論モデルはプロトコルのエッジケースとして扱われます。Notemdはシステム側のプロンプト内容とユーザー側のプロンプト内容を統合し、別途のsystemロールを拒否するOpenAI推論IDを生成します。また、プロバイダ定義がそれをサポートしている場合にのみreasoningEffortが公開されます。
トラブルシューティング
401または403: キー、プロジェクトへのアクセス権、請求状況、および選択したモデルがそのキーで有効になっているかを確認します。404でのチャット内容:Base URLは通常間違っているか、既に/chat/completionsが含まれています。- ドキュメントにはモデルが記載されているのにセレクターには表示されません。model-listアクセスとchatアクセスは別々の障害ポイントとなっているため、プロバイダープロファイル内で正確なモデルIDを手動でテストしてください。
- 推論モデルがメッセージを拒否しています:OpenAIの推論処理パスで対応されているモデルIDを使用するか、推論機能のないチャットモデルに切り替えてください。
いつ使用するか
最も予測可能なデフォルトのホストパスが必要な場合、/v1/modelsによる検出が重要な場合、またはワークフローがOpenAIの推論モデルのセマンティクスに依存している場合は、OpenAIを使用してください。ルーティングやプライバシー、コスト管理が直接のOpenAI APIの動作よりも重要な場合は、ゲートウェイやローカルプロバイダを利用することを推奨します。
次のステップ
- LLM プロバイダー -- 完全な設定、タスクごとのモデル、および再試行ロジック
- トラブルシューティング – 401/403エラーおよびレート制限エラーの修正