モデル / データセット
snflkd/fluent-korean avatar
snflkd/fluent-korean

fluent-korean: Claude Codeの韓国語出力をoutput-styleで規律する

Claude Code가 명확한 한국어를 구사하게 만드는 output-style 플러그인 | Claude Code output-style for clear, fluent Korean

スター 1,283フォーク 85UnknownMIT
GitHub

ひと目でわかる

これは何?
Claude Codeに韓国語の出力規範をシステムプロンプト側から与えるoutput-styleプラグイン。事後校正ではなく事前規律という設計を選んだ理由と、その代償をREADMEの記述範囲で読み解く。
誰に向いている?
韓国語でClaude Codeに指示を出し、成果物にも韓国語が混ざる開発者には向いている。逆に英語だけで完結する作業や、文体そのものを磨きたい執筆作業には効かない。
商用利用できる?
できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
今もメンテナンスされている?
されています。最後のコミットは 24 日前です。
何の言語で書かれている?
GitHub はこのリポジトリの主な言語を示していません。

回答はプロジェクトの GitHub データ(最終同期:2026年9月15日)と当サイトの分析に基づくもので、法的助言ではありません。

オープンソース詳細解説

どの韓国語が壊れるのか、READMEの主張をそのまま読む

READMEが挙げる症状は具体的だ。助詞と語尾が落ちる、名詞を並べた電報のような文になる、比喩に置き換わった語彙が使われる。英語版の説明ではこれをbroken machine-Koreanと呼んでいる。日本語話者にも覚えのある崩れ方で、要するに文法的な骨格を省略して意味だけを圧縮した出力である。

原因についてREADMEは、トークン使用量を下げコンテキスト制限に対応するために、コーディングエージェントが簡潔に話すよう設定されている点を挙げる。つまりモデルの韓国語能力そのものではなく、エージェント向けの簡潔化指示が韓国語の冗長な形態素を削ってしまうという見立てだ。この見立てが正しいかどうかをこの記事で検証することはできない。ただし対策の方向性はこの診断から素直に導かれている。出力を後から直すのではなく、出力を生成する前の指示に介入する。

対象読者はREADMEに明記されている。韓国語で命令を入力する場合、作業結果物に韓国語が含まれる場合。多段エージェントやハーネスで韓国語のプロンプトと資料をやり取りする構成では、この劣化が段ごとに累積し、意味の損失が作業の完成度低下につながるとREADMEは述べる。

output-styleという選択が意味するもの

このツールは校正器ではない。output-styleとしてシステムプロンプトに追加され、韓国語を正しく使うよう事前に規律する。READMEの表現では「사전에」規律すると書かれている。

この設計は他ツールとの差としてREADME自身が説明している。翻訳調の校正、AI表現の最小化、誤字の除去を求めるならim-not-ai、korean-skills、k-skillのkorean-humanizerを参照せよと、代替を名前付きで挙げている。つまりfluent-koreanは文章を磨く道具ではなく、意味が失われない明確な韓国語表現を目標に据える。美文より確実な伝達、という優先順位がREADMEの冒頭から一貫している。

事前規律には構造上の利点がある。生成された文を書き換える工程がないので、意味を保ったまま語尾を補うという難しい作業が発生しない。同時に欠点もある。指示に従わなければ何も起きない。README自身が「생각보다 원하는 만큼 동작하지 않을 수 있습니다」と書いており、指示が多様になるほど、作業が長くなるほど、Primingを誘発するテキストが多いほど、その傾向が強まると説明している。

2つのバリアントと、選んだ後に必要な一手間

プラグインにはoutput-styleが2つ入っている。fluent-koreanはコーディング指針を維持する版で、コーディング作業に使う。fluent-korean-not-codingはコーディング指針を除去した版で、Claudeが直接コードを変更しない場合に使う。READMEの説明はこの2文にとどまり、両者の差分が具体的にどの行なのかは示されていない。判断したいならplugins/fluent-korean/output-styles/配下のmdを直接開いて本文を比較するのが確実だ。

インストールはClaude Codeを起動して2行を入力する。

/plugin marketplace add snflkd/fluent-korean /plugin install fluent-korean@fluent-korean

その後に/configなどのメニューでoutput-style項目を探し、どちらかを選ぶ。ここで注意点が2つある。output-styleの性質上、configで選択した後は新しいセッションを開始するか/clearを使わなければ変更が適用されない。またREADMEは、ファイル名と設定の大文字小文字に注意せよと書いている。これが原因で設定できないケースが報告されているという。設定が反映されないときは、まずここを疑う価値がある。

毎回選び直すのが面倒なら、settings.jsonまたはsettings.local.jsonのoutputStyle値を変更すれば既定値になる。

Claude Code以外に持ち出す場合の現実的な手順

原理は単純だとREADMEは言う。plugins/fluent-korean/output-styles/のmdファイルから好きなものを選び、本文を適切な場所に挿入する。Claude Code CLI環境であっても、プラグインを入れずにmdファイルを~/.claude/output-styles/またはプロジェクトの.claude/output-styles/に置けばよい。この方法なら後述の細部動作の調整もできる。

環境ごとの適用先はREADMEがいくつか列挙している。ClaudeのWebやデスクトップアプリでチャットやコワークを使う非開発者は、設定から個人別指示に追加する。チャットはプロフィールか一般タブ、コワークは協業タブ、プロジェクト限定ならプロジェクト指示に置く。Claude Desktopアプリ内でClaude Codeを使う場合は、configを入力して出るメニューにoutput-styleを変える項目がないため、CLAUDE.md、settings.json、settings.local.jsonの中から状況に合うものを選んで適用する。

ここでREADMEが繰り返すのは、適用方法は環境によって異なるので、このREADMEをLLMに渡して相談せよという点だ。README自体がインストール案内のガイドとして機能するよう書かれており、LLMが利用者の開発知識レベルを推測し、初心者と見れば詳しく説明し、曖昧なら質問せよと指示している。ドキュメントを人間向けと機械向けの中間に置く珍しい作りである。

細部動作はブロックを貼り足す方式

READMEの後半は、調整用のテキストブロック集になっている。mdファイルをディレクトリに直接置いた場合は本文の末尾に、テキストだけを使っている場合はその指示の末尾に貼り付ける。ただしClaude Code CLIでプラグインとして導入した場合、更新時にファイルが上書きされる可能性があると注意書きがある。調整を蓄積したいなら、プラグインではなくmd配置を選ぶ理由がここにある。

ブロックの例は具体的だ。初心者開発者向けには、過度に現場感のある口語表現を控えさせる(박아넣다、치우다、얹다などが例示される)。敬語なら呼称と語尾、助詞、敬語語彙で目上への待遇を統一させる。低頻度語の抑制なら、辞書にあり意味が明確でも通用しない語彙はむしろ伝達効率を下げるので、実際に通用する語彙を優先させる。

運用上の工夫としてREADMEが挙げるのは、出力直前に指示違反を点検して修正させよというブロックだ。事前規律で漏れた分を最後に拾う二段構えになる。文体に敏感な作業(小説、台本、出題、研究)向けには、具体的な指針が別に存在する産出物にはこの指針を適用せず、適用が曖昧なら利用者に確認するというブロックが用意されている。

トークンと遵守率という2つのコスト

READMEが明示する代償はトークンだ。省略された文成分と形態素を復元するため、メッセージのトークン使用が少し増え、コンテキスト占用量も増える。加えてシステムプロンプトに指針が加わるので、毎セッションわずかにトークンを多く使う。韓国語の正しさと引き換えにコンテキストを消費する取引であり、コンテキストが厳しい作業では逆効果になり得る。

もう一つのコストは遵守率で、こちらは数値が示されていない。READMEは、指示が多様なほど、作業が長いほど、Primingを誘発するテキストが多いほど効きにくくなると述べ、その場合は指針自体を修正するよりハーネスを構成・最適化する方がよいと勧める。メンテナ自身の運用も書かれている。output-styleを基本にしつつ、主要な産出物で文体が守られなければSkillのように使って改善し、ハーネスでは結果を出す前に敵対的検証を行うよう設定しているという。

サブエージェントの扱いも未解決の領域として明記されている。コーディング版にはサブエージェントへ入力されるプロンプトも韓国語ならこのoutput-styleに従わせる条項があり、両版に英語で書くべきものを韓国語で書かないという趣旨の条項もある。ただしこれらが実際にどれだけ守られるかは状況次第で大きく変わるため、必要なら自分で観察して修正せよとREADMEは書いている。

向かない場面と、隣接ツールとの役割分担

このツールが間違った選択になる場面ははっきりしている。第一に、出力が英語で完結する作業。英語で考えるよう指示されたコーディングエージェントに対して、韓国語の形態素を復元させる指針は無駄なコンテキストになる。第二に、文体そのものが成果物である作業。README自身が小説、台本、出題、研究を挙げ、これらには別の指針を適用せず、曖昧なら利用者に確認するブロックを用意している。第三に、コンテキスト余裕が乏しい長時間セッション。トークンが増える方向の介入だからだ。

代替との違いは、READMEが名前を挙げているim-not-ai、korean-skills、k-skillのkorean-humanizerとの対比で理解できる。これらは翻訳調の校正、AI表現の最小化、誤字の除去という方向、つまり生成後のテキストを人間らしく整える方向を取る。fluent-koreanは意味が失われない明確さを目標に、生成前のシステムプロンプト層へ入る。どちらが上という話ではなく、層が違う。既に生成された韓国語文書を整えたいなら後者群、これから生成される韓国語の骨格を崩したくないならfluent-koreanという住み分けになる。

ライセンスはMITとリポジトリ情報に記載されている。指針テキストを他環境へ貼り付ける用途を想定した配布形態を考えると、この条件は採用判断の障害になりにくい。ただし法的な判断はここでは扱わない。

更新コストと、導入前に確認すべきこと

リポジトリの情報ではv1.0.0が2026年7月、v1.0.1が8月18日、v1.0.2が8月21日と、短期間にパッチが続いている。最終pushは2026年8月23日。変更の内容までは与えられた資料からは分からないので、更新が活発かどうかを変更履歴の中身から評価することはできない。

更新コストとしてREADMEが具体的に警告しているのは、プラグインとして導入した場合に更新でファイルが上書きされ得る点だ。細部動作のブロックを追記して運用しているなら、更新のたびに貼り直しが発生する。これを避けたいなら~/.claude/output-styles/または.claude/output-styles/にmdを置く方式を選ぶ。トレードオフは、プラグインの更新通知に乗れなくなることだ。

導入前に確認すべきは3点。自分の環境でoutput-styleの選択メニューが使えるか(Claude Desktopアプリ内のClaude Codeでは使えないとREADMEが明記している)。ファイル名と設定の大文字小文字が合っているか(これで失敗したケースが報告されている)。そして選んだバリアントの指針本文が自分の作業に合うかを、plugins/fluent-korean/output-styles/のmdを開いて確認できるか。READMEは原理文書を「作成中」としてGoogle Docsへのリンクを置いており、なぜモデルが韓国語をうまく書けないのかという説明はまだ完成していない。仕組みを理解した上で採用したい読者にとって、この部分は現時点で空白である。

編集部の結論

韓国語でClaude Codeに指示を出し、成果物にも韓国語が混ざる開発者には向いている。逆に英語だけで完結する作業や、文体そのものを磨きたい執筆作業には効かない。導入前に確認すべきは、自分の環境でoutput-styleの選択UIが使えるかどうかだ。Claude Desktopアプリ内のClaude Codeではconfigにoutput-styleを切り替える項目がないとREADMEが明記しており、settings.jsonかCLAUDE.mdを自分で編集する必要がある。まずplugins/fluent-korean/output-styles/配下のmdを開き、fluent-koreanとfluent-korean-not-codingのどちらが自分の作業に合うかを本文で確かめてから、/plugin marketplace add snflkd/fluent-koreanを実行する順序が無駄がない。

公式情報源

  1. Issues
  2. License: MIT
  3. README
  4. Releases
  5. snflkd/fluent-korean on GitHub
コミュニティノート

コミュニティノート