3. タスクとプロバイダーの使い分け

単一の設定ファイル

myllm-cliは，プロバイダー，モデル，タスクをひとつのconfig.tomlで管理します。既定の場所は~/.config/myllm/config.tomlです。XDG_CONFIG_HOMEが設定されている場合は，$XDG_CONFIG_HOME/myllm/config.tomlを使用します。

設定は四つの領域に分かれます。

セクション	役割
[general]	既定のプロバイダーとOllamaの保持時間
[providers.<name>]	接続先，既定モデル，APIキー
[tasks.<id>]	用途別の指示と，必要に応じた接続先の上書き
[translation]	言語判定を伴う翻訳専用設定

タスクにproviderを書かなければ[general]のdefault_providerを使用します。モデルは，タスクに指定したmodel，選択されたプロバイダーのdefault_modelの順で決まります。

設定項目	優先順位
プロバイダー	タスクのprovider → [general] default_provider
モデル	タスクのmodel → 選択されたプロバイダーのdefault_model

この構造により，多くのタスクは短く記述し，例外だけをタスク側で上書きできます。

OpenAIとAnthropicの設定

OpenAI APIとAnthropic APIを使う場合は，対応するプロバイダーセクションを有効にします。APIキーを設定ファイルへ直接書くこともできますが，誤って共有する危険を減らすため，環境変数名をapi_key_envで指定する方法が適しています。

[providers.openai]
base_url = "https://api.openai.com/v1"
default_model = "YOUR_OPENAI_MODEL_ID"
api_key_env = "MYLLM_OPENAI_API_KEY"

[providers.anthropic]
base_url = "https://api.anthropic.com/v1"
default_model = "YOUR_CLAUDE_MODEL_ID"
api_key_env = "MYLLM_ANTHROPIC_API_KEY"

環境変数は，利用するシェルの設定ファイルなどで定義します。

export MYLLM_OPENAI_API_KEY="sk-..."
export MYLLM_ANTHROPIC_API_KEY="sk-ant-..."

base_urlを変更すると，OpenAI Chat Completions形式と互換性のある別のエンドポイントへ同じアダプターで接続できます。モデルIDは各APIで利用可能な値を指定します。

タスクごとに接続先を選ぶ

既定のプロバイダーをOllamaにしたまま，特定のタスクだけクラウドモデルへ送ることができます。次の例では，日常的な推敲をローカルで処理し，より複雑なレビューだけOpenAI APIへ送ります。

[general]
default_provider = "ollama"

[tasks.polish]
name = "Polish locally"
instruction = '''
Improve the clarity and correctness of the provided text.
Preserve its meaning and return only the revised text.
Use the same language as the original text.
'''

[tasks.review]
name = "Detailed review"
provider = "openai"
model = "YOUR_OPENAI_MODEL_ID"
instruction = '''
Review the provided text for factual gaps, ambiguous claims, and structural problems.
Return a concise list of findings with proposed corrections.
Use the same language as the original text.
'''

myllm polish < draft.txt
myllm review < draft.txt

ローカルのOllamaへ送るタスクでは，設定したbase_urlが手元のOllamaを指している限り，入力をクラウドAPIへ送信しません。OpenAIまたはAnthropicを選択したタスクでは，入力とタスクの指示が各サービスへ送信されます。扱う情報の機密性，必要なモデル性能，応答時間，API利用料を考慮し，タスク単位で接続先を選択できます。

タスクを小さく保つ

タスクは，ひとつの明確な変換に絞ると再利用しやすくなります。たとえば「文章を改善する」と「内容を評価する」では，求める出力が異なります。前者は修正文だけを返し，後者は問題点の一覧を返す別タスクにすると，コマンド名から結果を予測できます。

設定テンプレートには，要約のsummarize，推敲のpolish，平易に説明するexplainなどが含まれます。独自タスクでは，少なくとも次の内容を指示として固定します。

• 目的
  入力に対して何を行うかを記述します。
• 保持条件
  意味，語調，コード，固有名詞など，変更してはいけない要素を指定します。
• 出力形式
  修正文のみ，箇条書き，JSONなど，後段で扱いやすい形式を指定します。
• 出力言語
  入力と同じ言語にするか，特定の言語へ固定するかを指定します。

翻訳を独立させる理由

translateは通常の[tasks]には含めず，[translation]で設定します。翻訳では指示を固定するだけでなく，入力言語を判定し，翻訳先を選ぶ処理が必要だからです。

[translation]
enabled = true
provider = "ollama"
model = "translategemma:12b"
default_source = "en"
default_target = "ja"
fallback_target = "en"

whichlang-cliが利用できる場合は入力言語を自動判定します。上の設定では，英語を検出すると日本語へ，それ以外の言語を検出すると英語へ翻訳します。言語判定を利用できない場合はdefault_sourceを翻訳元とみなします。必要であれば，実行時に翻訳元と翻訳先を上書きできます。

echo "こんにちは" | myllm translate
myllm translate --from en --to fr "Hello"

TranslateGemma向けのプロンプトは，モデルが要求する改行を保つためスクリプト側に実装されています。翻訳スクリプトから発展した機能ですが，通常の名前付きタスクとは異なる処理として分離することで，言語判定と翻訳先の規則を設定できます。導入の背景と元の実装は，TranslateGemmaの記事で説明しています。