YomiyasuをDifyで使用する

Artificial Intelligence

Qwenって出力の品質は良いけど、ちょっと文章がね・・と思った貴方へ

こんなプロダクトがあります。

GitHub – nanaism/yomiyasu: AI生成の日本語を自然な日本語へ推敲するAgent Skill / Agent Skill for Refining AI-Generated Japanese into Natural Japanese
AI生成の日本語を自然な日本語へ推敲するAgent Skill / Agent Skill for Refining AI-Generated Japanese into Natural Japanese – nanaism/yomiyas…

これ、非常に便利で、実際プロダクト名の通り「読みやすく」なるAgent Skillの1つです。非常に更新ペースが速く、既にv2.4.0が登場しています。私は少し旧い v2.1.0 を使用しています。

私自身は家の中ではHermes AgentよりもDifyを使うことが多く、その心はHermes Agentの制御法とプロンプト・エージェント間の動きがまだ完全に把握しきれない為です。ただ、余程必要になったとき(DeepResearchをさらに深度を上げる場合など)には使うことがあるんですが、Difyのほうが方法を組み合わせるのが非常に楽で、頑張ってこれを更新しながら使ってます。

今回は、このYomiyasuをDifyに組み込んで、Dify CoT Agentと連携して使えるようにしたいなと言うことで。

Skillとして登録する

まず、前提とするのがDifyのバージョンは1.17.0以降を想定します。実装時のバージョンが1.17.0だったためですが、画面は先ほどアップデートが完了した v1.18.0 のものを使用しますので、画面の際などありましたらスミマセン。

まずはgithubの先述のリンクからYomiyasuの最新バージョンのZIPファイルをダウンロードします。
そしてSkillsメニューへ移動し、ZIPファイルインポートを行います。

ZIPファイルを組み込むと、以下のようにスキルが登録されます。

Agentを作る

Agentsメニューへ移動し、エージェントを作ります。

まず行うべきはスキルとしてYomiyasuを登録することです。Skillsメニュー内に作成したYomiyasuを指定し、スキルに登録してください。あとは、これをうまく使うようプロンプトを記述します。これについては、自宅内のLLMでは荷が重いところが多く、已む無くさくらインターネットのAIエンジンを活用しています。Qwen3.6-35B-A3Bを適用しました。

※トークン出力速度的に、我が家のQwen3.8-27Bでは速度面で厳しく、Qwen3.8-Flash-Nextは必要時にしかVMをONにしないので、いつでも使えるモデルが必要だったのです。で、極力OpenAIとかGoogleとか使いたくないなとなったらこれに。

このプロンプトはQwen3.8-27Bにつくってもらいました。一応以下のようなことを書いています。

あなたは日本語文章の書き直し専門エージェント「yomiyasu」です。
AIが生成した不自然な日本語を、人間が読みやすく情報密度の高い自然な文章へ書き直します。

【作業手順】
1. 入力された文章をそのまま受け取る。要約・省略・前置きを加えない。
2. 以下の臭い検出チェックリストを文単位に適用する。
3. 意味・情報量・数値・固有名詞・条件・期間・地域を保ったまま書き換える。
4. 書き換え後の文章のみを出力する。変更点の説明、断り書き、要約を付けない。

【書き換えルール】
- 非生物主語の解体:「この機能は成長を物語っている」「データが語る」のように、物・概念が述語の主体になっている文を、人・組織・ツールを主語にした文へ置き換える。
- 比喩的動詞の具体化:「支える」「底上げする」「橋渡しする」「掘り下げる」「紡ぐ」「加速させる」「突き動かす」「物語る」「語りかける」を、実際に起きた動作へ具体化する。
- 絵文字の完全排除:本文・見出し・箇条書きから絵文字をすべて削除する。
- 文末コロンの完全排除:見出し・箇条書き末尾のコロンを削除し、体言止めまたは説明文へ変える。
- 補足カッコの削除:「(重要)」「(※以下省略)」「(後述)」など、本文で言い切れる内容をカッコから外す。意味に必要で、かつ本文で言い切れないカッコは残す。
- 英単語前後の不要な半角空白の排除:「API を使う」→「APIを使う」。「Docker を起動」→「Dockerを起動」。英単語同士の間に必要な空白(例:Visual Studio Code)は残す。
- 過剰な太字の削除:不要な ** を削除する。強調が構造上必要で、削除すると意味が崩れる箇所だけ残す。
- 箇条書きの平文化:箇条書きを意味のまとまりごとに散文化する。手順、設定項目、比較、数値一覧など、箇条書きが機能している場合は残す。
- 否定対比の平文化:「AではなくB」「単なるXではなくY」「〜というだけでなく〜」を「B」「Y」と言い切る。
- 文単体で主語・述語を明確化する:「誰が」「何を」「どうした」を文中に明示する。受身の連鎖、体言止めの連鎖、主語の省略を解消する。
- 情報密度を上げる:前置き(「結論から言うと」「重要なのは」「このセクションでは」)、同一内容の言い換え、修飾語の重ね、強調語を削除する。1文1情報に整える。
- 接続詞の過剰使用を減らす:「そして」「さらに」「また」「〜することで」「〜を通じて」「〜に基づいて」を必要最低限に減らす。
- 語尾の単調化を避ける:「〜です」「〜ます」の連続、語尾の重複を調整する。

【禁止事項】
- 原文に存在しない情報を追加しない。
- 断定の強さ、数値、単位、期間、地域、条件、固有名詞を勝手に変えない。
- コードブロック、コマンド、URL、ファイルパス、リンク、数式、テーブルの構造を変更しない。
- 原文の長さ、見出し階層、段落の順を勝手に変えない。
- 絵文字、文末コロン、不要な太字、否定対比構文を出力に一切残さない。

【自己検証(出力前に必ず確認)】
- 絵文字が残っていないか
- 文末コロンが残っていないか
- 不要な ** が残っていないか
- 「AではなくB」構文が残っていないか
- 物や概念が述語の主体になっていないか
- 英単語前後の不要な半角空白が残っていないか
- カッコで隠れた内容が本文で言い切られているか
- 各文に「誰が・何を・どうした」が読み取れるか
- 1文1情報になっているか

【出力形式】
書き換え後の文章のみ。前置き、説明、変更点リスト、比較表、注記を付けない。

ワークフローに組み込む

どうやらAgentはチャットフローアプリに組み込むことが出来ないようで、これはちょっと残念なポイントだと思われ。ひとまずワークフローに組み込むことにしました。

丁度「AGENT-YOMIYASU」と書いた箇所が先ほど作成したエージェントを作成したものをはめ込んでるところなのですが、その前段にサードパーティプラグインを挟んで、Markdown分をMarkdownファイルに変換する処理を加えています。

注意:Difyの制約でワークフローからエージェントへ渡せる文字列数には上限がある

実は、「エージェントへ文字列として運べるのは2000文字まで」という制限があります。そのため、正直に入力したデータを運ばせるとAgentには末尾を「…[truncated]」という文字列をつけて途中で打ち切ってしまう特性があることが分かり、そこへデータを送るにはファイルで送らないといけないという制約があります。

そこで、若干無駄は感じつつも一度ファイル化して、それをエージェントに運ばせる必要があります。

実はファイルを置くのは簡単にできるよう作られていて、左のようにテキストの中にファイル配列オブジェクトを設置することによりファイルの中をエージェントに読み込ませることが可能になっています。昔のバージョンではこうしたマネが出来なかったので「ほんと進化したんだなー」と思いつつ。

そのままファイル名だけ載せると、ファイルを取り込んで解析する状況までLLM側の判断で載せるようになってしまったので、そこを記載させないような縛りを加えています。

その後、Markdown to Wordというワークフローを使った処理が入っていますが、これはベットワークフローでMarkdown文字列をWORDファイルに変換する処理を入れていますが、こちらも結局はサードパーティ製のExporterを使ってdocxファイルに書き出しているだけです。

YOMIYASUでどう変わったか?

実際の記述を比較してみます。ベースに使用したのはちょうどWorkflowからAgentにファイルを受け渡す方法について調査してたときのDeepResearchエージェントの出力内容です。(ですます調コントロールがうまく出来てないので、出力結果がである調になってるのはご愛敬)

元の出力

# 調査報告

## 結論(先に手順)

**Workflow から Agent にファイル全体を渡すには、「ファイル型変数(Single File / File List)」を経由して Agent タスク内に参照插入します。**
Agent タスクに変数を插入する場合、**テキストとして届くものは 2,000 文字で切り捨てられますが、ファイルとして渡したものは切り捨てられず、Agent がサンドボックス内でファイル全体を読んで処理します。**[S1][S2]

具体的な操作は次の 3 手順です。

1. Workflow 内でファイル型変数を生ませる(Start / User Input の Single File・File List、HTTP Request ノードのファイル応答、API の `upload_file_id` など)。[S7][S5][S8]
2. Agent ノードの **Agent task** 入力欄で `/` を押し、そのファイル変数を插入して参照する(例: `Read {{contract_file}} and summarize the key risks.`)。[S2]
3. Agent 側はサンドボックスに受け取ったファイル全体を参照して作業する。テキストの切り捨て制限はこの経路には適用されない。[S1][S2]

公式ドキュメントの文言は次のとおりです。[S1][S2]

Yomiyasu出力

# 調査報告

## 結論

Workflow から Agent にファイル全体を渡す場合、ファイル型変数(Single File / File List)経由で Agent タスク内に参照挿入する。Agent タスクに変数をテキストとして挿入すると Dify が 2,000 文字に切り捨てる。ファイルとして渡すと切り捨てない。Agent がサンドボックス内でファイル全体を読んで処理する。[S1][S2]

手順は3段階。Workflow 内でファイル型変数を作成し、Start / User Input の Single File・File List、HTTP Request ノードのファイル応答、API の `upload_file_id` などから生成する。[S7][S5][S8] 次に Agent ノードの Agent task 入力欄で `/` を押し、ファイル変数を挿入して参照する。`Read {{contract_file}} and summarize the key risks.` のように記述する。[S2] 最終的に Agent がサンドボックスのファイル全体を参照して作業する。テキストの切り捨て制限はファイル経由では適用されない。[S1][S2]

公式ドキュメントは次のように記述する。[S1][S2]

おわかりだろうか。例えば末尾、元の出力では「公式ドキュメントの文言は次の通りです」に対して「公式ドキュメントは次のように記述する」と変換された。通常日本語を読む際に「○○の文言は」という言葉は使わず、あくまでドキュメントは人が書いたものであるため、主語の置き方が異なっていることが分かるでしょう。

私たち日本人は同じ日本語で書かれてると言っても、その自然さで読み込む難易度が変わってくるのかなと思っていて、Yomiyasuがそこに凄く気を遣ったプロダクトなんだなと言うことが分かるかと思います。

で、WORDに保存して後で見れるようにする

そしてこんな風に .docx ファイルにエクスポートしてます。取っておこうと思ったレポートは基本的にフォント書き換えを行った上で保存し、後で見れるようにファイル名を変更して保存しています。場合によってはこんな記事を書くときに転用することだってあったりします。

Difyは主に企業で使われてるようなので

Difyは共用AIシステムとして使われるケースが多いのかなと思います。AgentとSkillsをうまく活用することで、以前では出来なかったことがかなり手軽にできるようになってきました。Yomiyasuみたいな仕組みは、それこそ企業のワークフローなどでうまく活用すると面白いのではないかなーと思いますので、一度ためしてみてはどうでしょうか?

謝辞

大賀愛一郎さん作のこのプロダクトのお陰で色々見やすいドキュメントへ変換できるようになり、こうしてナレッジにも残すことができました。改めて感謝御礼申し上げます。

nanaism – Overview
Hiya! nanaism has 34 repositories available. Follow their code on GitHub.

さくらのAIエンジンは国内で展開されているAIエンジンであり、そのままAPI利用をするとリスクが存在する中国製モデルをローカルAI以外の選択肢として供給してくれています。こちらにも感謝と御礼を申し上げます。

さくらのAI Engine | さくらのAI | 生成AI・GPUクラウドサービス
基盤モデル搭載済みGPUサーバーで推論処理ができるAPIサービス。サーバー構築・運用不要。セキュアな国内完結の環境で複数の基盤モデルを無料でご利用いただけます。

コメント

タイトルとURLをコピーしました