現在は 2026 年 1 月 23 日、未明です。
残念ながら、Agent は翻訳タスクにおいて、ワンショット LLM の直接翻訳よりも性能が劣ることがわかりました。どうやら、Agent の強みは、単純な単一ステップのタスクではなく、多段階の推論と意思決定を必要とするタスクにあるようです。Agent が使用するトークン数は LLM の 10 倍にもかかわらず、翻訳品質はむしろ低下しており、特に YAML Frontmatter の翻訳ではフォーマットエラーさえ発生しました。
当初は、ワンショット LLM が長文翻訳タスクで最大出力長制限を超える問題を解決するために Agent を利用しようと考えていましたが、それほど単純ではないことがわかりました。そこで、[email protected] バージョンではこの機能をロールバックし、長期的な検討課題としました。
これは、Agent の使用シナリオが通常、膨大な情報量を伴う複雑なタスクであるため、コンテキストの読み書きを可能な限り少なくするように設計され、さらに優先的にファイルを局所的に読み書きすることで、Agent のデータ処理上限を引き上げているからではないかと考えています。このコンテキスト管理戦略により、すべての情報をデフォルトで取り込むことができず、ワンショット LLM のようにコンテキスト情報を十分に活用して翻訳を行うことができないのです。
興味深いことに、一部の少数言語の翻訳タスク（例えば簡体字中国語からインドネシア語など）では、Agent が偶然にも翻訳の無限ループに陥り、安定した翻訳結果に収束できないことがありました。これは、Edit ツールが特定の言語を処理する際に欠陥があり、テキストを正しく置換できないため、無限ループに陥ってしまうのかもしれません。（あまりに節約しすぎるのも問題かもしれません）
二つの解決案を考えています：
- Agents / Sub-Agents フレームワークを使用して翻訳タスクを分解する。例えば、翻訳と校正を行う対抗生成フレームワークなどです。
- Skill を組み立てて Low-level のワンショット LLM API を作成し、Agent 自身が翻訳するのではなく、Agent に翻訳スキルを呼び出させる。
個人的には、第一の案の方が上限が高そうなので、より好ましいと考えています。ただ、OpenCode が複雑な Agent 呼び出しをどの程度サポートしているかはわかりません。
また、CZON の更新履歴は以下の通りです：
- 0.5.0: 翻訳タスクに OpenCode を統合しました。（ただし、大量のファイル翻訳時にパフォーマンス問題が発生したため、後に修正）
- 0.5.1: 国内ネットワークから jsdelivr にアクセスできないために発生していた、フロントエンド静的リソース（tailwindcss）の読み込み失敗問題を修正しました。（ビルド時に CDN ファイルをローカルにダウンロードすることで実現）
- 0.5.2: slug が既に存在する場合、slug を更新しないように変更し、コンテンツの修正による slug の変化を防止しました。（ログファイルのリネームによる過去リンクの無効化を回避）；Agent 翻訳機能をロールバックし、OpenCode 統合による翻訳タスク機能を廃止しました。
