構造化ログ
Triggerfishは重大度レベル、ファイルローテーション、設定可能な出力を持つ構造化ログを使用します。 すべてのコンポーネント — ゲートウェイ、オーケストレーター、MCPクライアント、LLMプロバイダー、 ポリシーエンジン — は統一されたロガーを通じてログを記録します。これは、イベントがどこで発生しても 単一の一貫したログストリームを得られることを意味します。
ログレベル
logging.level設定はどれだけの詳細を捕捉するかを制御します：
| 設定値 | 重大度 | ログに記録されるもの |
|---|---|---|
quiet | ERRORのみ | クラッシュと重大な障害 |
normal（デフォルト） | INFOとそれ以上 | 起動、接続、重要なイベント |
verbose | DEBUGとそれ以上 | ツール呼び出し、ポリシー決定、プロバイダーリクエスト |
debug | TRACE（すべて） | 完全なリクエスト/レスポンスペイロード、トークンレベルのストリーミング |
各レベルにはその上のすべてが含まれます。verboseを設定するとDEBUG、INFO、ERRORが得られます。 quietを設定するとエラー以外はすべて無効になります。
設定
triggerfish.yamlでログレベルを設定します：
yaml
logging:
level: normalこれが唯一の必要な設定です。デフォルトはほとんどのユーザーにとって適切です — normalは ログをノイズで溢れさせることなくエージェントが何をしているかを理解するのに十分な情報を捕捉します。
ログ出力
ログは2つの宛先に同時に書き込まれます：
- stderr — systemdサービスとして実行するときの
journalctlキャプチャ用、または開発中の直接ターミナル出力 - ファイル —
~/.triggerfish/logs/triggerfish.log
各ログ行は構造化フォーマットに従います：
[2026-02-17T14:30:45.123Z] [INFO] [gateway] WebSocket client connected
[2026-02-17T14:30:45.456Z] [DEBUG] [orch] Tool call: web_search {query: "deno sqlite"}
[2026-02-17T14:30:46.789Z] [ERROR] [provider] Anthropic API returned 529: overloadedコンポーネントタグ
括弧内のタグはどのサブシステムがログエントリを出力したかを識別します：
| タグ | コンポーネント |
|---|---|
[gateway] | WebSocket制御プレーン |
[orch] | エージェントオーケストレーターとツールディスパッチ |
[mcp] | MCPクライアントとゲートウェイプロキシ |
[provider] | LLMプロバイダー呼び出し |
[policy] | ポリシーエンジンとフック評価 |
[session] | セッションライフサイクルとtaintの変更 |
[channel] | チャンネルアダプター（Telegram、Slackなど） |
[scheduler] | Cronジョブ、トリガー、Webhook |
[memory] | メモリストア操作 |
[browser] | ブラウザ自動化（CDP） |
ファイルローテーション
ログファイルは無制限のディスク使用を防ぐために自動的にローテーションされます：
- ローテーション閾値： ファイルあたり1MB
- 保持ファイル数： 10個のローテーションされたファイル（合計最大約10MB）
- ローテーション確認： 各書き込み時
- 命名：
triggerfish.1.log、triggerfish.2.log、...、triggerfish.10.log
triggerfish.logが1MBに達すると、triggerfish.1.logにリネームされ、前のtriggerfish.1.logは triggerfish.2.logになるというように続きます。最古のファイル（triggerfish.10.log）は削除されます。
ファイア・アンド・フォーゲット書き込み
ファイル書き込みはノンブロッキングです。ロガーはディスク書き込みの完了を待つためにリクエスト処理を 遅延させることはありません。書き込みが失敗した場合 — ディスクがいっぱい、パーミッションエラー、 ファイルがロックされている — エラーはサイレントに飲み込まれます。
これは意図的なものです。ログはアプリケーションをクラッシュさせたりエージェントを遅くしたりするべきでは ありません。ファイル書き込みが失敗した場合、stderrの出力がフォールバックとして機能します。
Log Readツール
log_readツールはエージェントに構造化されたログ履歴への直接アクセスを提供します。エージェントは 会話を離れることなく、最近のログエントリを読み取り、コンポーネントタグや重大度でフィルタリングし、 問題を診断できます。
| パラメーター | タイプ | 必須 | 説明 |
|---|---|---|---|
lines | number | いいえ | 返す最近のログ行数（デフォルト：100） |
level | string | いいえ | 最小重大度フィルター（error、warn、info、debug） |
component | string | いいえ | コンポーネントタグでフィルター（例：gateway、orch、provider） |
エージェントに「今日はどんなエラーが発生しましたか」または「最近のゲートウェイログを見せてください」と
尋ねてください — log_readツールがフィルタリングと取得を処理します。 :::
ログの表示
CLIコマンド
bash
# 最近のログを表示
triggerfish logs
# リアルタイムでストリーミング
triggerfish logs --tail
# 直接ファイルアクセス
cat ~/.triggerfish/logs/triggerfish.logjournalctlで
Triggerfishがsystemdサービスとして実行されている場合、ログはジャーナルにもキャプチャされます：
bash
journalctl --user -u triggerfish -f