😊

Clojure を LLM とコーディングする時の編集問題との使い方

2025/10/26に公開

以下の文章は、10月20日 に始まった ClojureMCP の編集エラー、パフォーマンス、Parinfer の使用に関する Clojurian Slack のスレッドについてまとめたものです。このスレッドは100件以上のコメントが付き、非常に盛んに議論が行われていました。
主にコードの編集（特にカッコ）に関する、ツールとモデルについて議論されています。

 1. カッコ問題解決方法は、ユーザの属性次第
 1.1. フルタイムClojure開発者の場合フルタイムでClojureを書く開発者にとって、カッコ不一致問題は、作業の流れを頻繁に中断する現実の問題ですね。例えば
LLMが生成（構文は正しいが、インデントが間違い）
{:success true
:sent-to final-to
:message-id (.getId result)
:test-mode? test-mode?}
それを、Parinferが「修正」した結果（ロジック破壊）
{:success true}
:sent-to final-to
:message-id (.getId result)
:test-mode? test-mode?
フルタイム開発者に必要なLLMとの協働は、
ゼロに近い編集エラー率
構造的編集の信頼性
REPLドリブン開発との統合
複数のLLMクライアント/モデル対応
といったことでしょう。

 1.2. 時々Clojureを書く開発者の場合Cursiveの開発者Colin Fleming さんのアプローチは、時々Clojureを書く人へのアドバイスになりそうです。
彼のアプローチは以下のようなものでした。
LLMに訓練されたツールを使わせる
Claude hookでparinfer indent modeを実行
ツールのシンプルさを優先
ここから、時々使う開発者に必要なものは、
最小限のセットアップ
優れたUI統合とdiff表示
最新モデルとの相性
と言えるでしょう。

 具体的な実装紹介されていた、「最小限のセットアップ」は以下の通りです。これは、LLMがClojureコードを編集した後に、自動的に括弧のバランスを修正する仕組みだそうです。
Parinfer CLIスクリプト（Node.js）
#!/usr/bin/env node
var fs = require('fs');
var parinfer = require('parinfer');
if (process.argv.length == 3) {
process.stdout.write(
    parinfer.indentMode(fs.readFileSync(process.argv[2]).toString()).text
);
}
以下のことを行います。
Clojureファイルを読み込む
Parinferの「インデントモード」で処理する
インデント（字下げ）から括弧の位置を推測して自動修正

修正後のコードを標準出力に出力

Claude Code Hook設定（JSON）
{
    "hooks": {
        "PostToolUse": [{
        "matcher": "Edit|MultiEdit|Write",
        "hooks": [{
            "type": "command",
            "command": "jq -r '.tool_input.file_path | select(test(\"\\.(clj|cljs|cljc|cljd|bb|edn)$\"))' | xargs -r parinfer-cli"
            }]
        }]
    }
}
以下のことを行います。
トリガー： LLMがEdit/MultiEdit/Writeツールを使用してファイルを編集
ファイル判定：jqコマンドで、編集されたファイルが.cljや.cljsなどのClojureファイルか確認
自動修正： Clojureファイルなら、parinfer-cliを実行して括弧を自動修正
適用： 修正されたコードがファイルに保存される

 1.3. わたしはどっち？といっても、自分がどっちにあたるのか？私にもわかりません。よって、
週に何行のClojureを書くか？
編集エラーに遭遇する頻度は？
どのツールチェーンに投資できるか？
といった質問を用意してみました。これだと私は「フルタイム」の方に当たりそうです。

 2. モデルが重要：選択が結果を左右する
 2.1. モデル間の大きな差slack の 議論が進むにつれ、モデルによって編集能力が大きく異なると意見が飛び交いました。

 GPT-5 / GPT-5-Codex✅ 編集作業全般に優れている
✅ 手動修正がほぼ不要
✅ 会話的な対話に適している
💰 コスト効率が良い

 Claude Sonnet 4.5✅ 以前（3.7、4.0）より大幅に改善
✅ Opus 4.1と同等以上の能力
⚠️ まだ編集ミスが発生する
💰💰 比較的高価

 Gemini 2.5-pro✅ aiderのSEARCH/REPLACE方式で良好
⚠️ diff形式には敏感
⚠️ 編集メカニクスに課題
💡 useSmartEditで改善可能
Clojurian の間では（でも？）、GPT-5 は人気でした。

 2.2. マルチモデルアプローチとはいっても、上記の比較はあくまで編集の話です。Slack の議論の中で、
「編集作業にGemini 2.5-proを使い、コード理解と計画にはGPT-5-codex、非常に深い推論が必要なときだけ高価なClaude Opus 4.1を使う」
というコメントがありました。この開発者は、
タスクごとに最適なモデル
コスト最適化
openrouterで簡単に切り替え
をしているようです。

 2.3. モデル選択のガイドライン何の作業にどのモデルを選択すべきか？というslack の議論に従い表にまとめて見ました。


タスク
推奨モデル
理由


編集作業
GPT-5 / Gemini
エラー率が低い

推論・計画
GPT-5-codex / Claude
深い理解

コードレビュー
GPT-5 / Gemini
多角的視点

複雑な問題解決
Claude Opus 4.1
最高の推論能力

ただし、2025/10/26現在の評価に過ぎませんので、定期的にチェックして行きましょう。

 3. モデル × ツール × インストラクションの組み合わせ
 3.1. 成功の方程式とS式の優位性Backseat Driverの開発者である、Peter Strömberg さんが、モデルとツール、そしてインストラクション（プロンプト）について以下のようにまとめました。

モデル: 編集全般の能力（おそらく決定要因ではない）

編集ツール: 異なるツールが異なるモデル・インストラクションに適合

インストラクション: おそらく最も重要
彼は更に、
ClojureMCP（とBackseat Driver）の編集精度の一部は、適切なインストラクションと構造的編集が、行ベース編集よりもモデルにとってはるかに複雑さが低いことに起因する。
と言っています。
構造的編集というのは、Clojureなら、カッコからカッコまでが編集範囲だ、ということをLLMにシンプルに伝えることができる、という意味です。
例えば、構造的では無い言語では
"15行目から20行目を削除して、以下のコードに置き換えてください"
と伝える必要があることでも、ClojureなどのS式構造を持つ言語に対しては
関数 `calculate-tax` を以下の定義に置き換えてください
と伝えるだけで、どこからどこまでの編集をどのように変更すべきか、をクリアに伝えることができます。これはLLMと人間にとっても非常に「複雑さが低い」のです。

 3.2. エラーファーストでインストラクションする効果的なインストラクションとして、以下のように指示するのが良いというコメントがありました。
## Code Indentation Before Evaluation
Consistent indentation is crucial to help the bracket balancer.

❌ 悪い例
(defn my-function [x]
(+ x 2))

✅ 良い例
(defn my-function [x]
  (+ x 2))
コードを評価する前に、インデントを守れ、ということですね。parinfer と LLM と 人間の協働では、このインストラクションは最強だと思います。

 3.3. 組み合わせの例今まで議論をまとめると、ツール×モデルは以下のようになるようです。
パターン1: ClojureMCP + GPT-5
構造的編集の信頼性
GPT-5の編集能力
ゼロエラー体験
フルタイムClojurian
パターン2: Parinfer Hook + Sonnet 4.5
シンプルなセットアップ
最新モデルの改善を活用
優れたdiff表示
時々Clojurian
パターン3: aider + Gemini + formatter
makefile 作成format:
    npx @chrisoakman/standard-clojure-style fix src test deps.edn

make format を実行
LLMが間違えても、フォーマッターが正しく修正
ローカルで実行するのでトークン消費ナシ
どちらのユーザにおすすめ

 4. 何を優先するか、で決定silver bullet は無いよね、という言葉は Clojure slack でよく見かける表現ですが、ここでの議論もそのようです。自分に合うスタイルを自分で見つけて行くしかありません。
こっちを取ったら、あっちは取れない、といったトレードオフ関係にあるものを並べて行きますので、参考にしてみてください。

 4.1. 信頼性 vs シンプルさClojureMCP：
✅ 実質的にゼロ編集エラー
✅ 構造的編集の信頼性
✅ REPLドリブン開発

❌ セットアップの複雑さ
❌ 追加のClojureプロセス
❌ 時々使う人には過剰
Parinfer Hook:
✅ 最小限のセットアップ
✅ モデルの強みを活かす
✅ 優れたUI統合

❌ まだエラーが発生
❌ 最悪ケースで混乱
❌ モデル依存が高い

 4.2. 出力の読みやすさ vs エラー率出力の「見た目」も選ぶ基準になっているようです。エラー率というのは、LLMの編集操作が失敗する確率のことです。
ClojureMCP出力：
「テキストの壁」
詳細だが読みにくい
エラー率：ほぼゼロ
Wall of Text には笑いました。こういうやつですね。

標準ツール出力：
美しいdiff表示
UI統合が優れている
エラー率：低いが存在

 4.3. コスト vs 能力お金こそパワー 💪🤑
Claude Opus 4.1:    💰💰💰💰 最高の推論
Claude Sonnet 4.5:  💰💰💰   優れたバランス
GPT-5:              💰💰     コスト効率良好
Gemini 2.5-pro:     💰💰     競争力のある価格

 5. 最後にとにかく、自分の答えを見つけるまで、色々試す、それしかないですね。

それぞれのユーザが、それぞれにベストを持つことが当然だ、というClojurian の（いつもの）姿勢がとても好きです。

 6. 参照この記事は2025年10月のClojurians Slackでの実際の議論をもとに書きました。
関連リソース:
ClojureMCP
Backseat Driver
Parinfer
claude-clojure-tool
元の議論スレッド

タスク	推奨モデル	理由
編集作業	GPT-5 / Gemini	エラー率が低い
推論・計画	GPT-5-codex / Claude	深い理解
コードレビュー	GPT-5 / Gemini	多角的視点
複雑な問題解決	Claude Opus 4.1	最高の推論能力

1. カッコ問題解決方法は、ユーザの属性次第

1.1. フルタイムClojure開発者の場合

1.2. 時々Clojureを書く開発者の場合

具体的な実装

1.3. わたしはどっち？

2. モデルが重要：選択が結果を左右する

2.1. モデル間の大きな差

GPT-5 / GPT-5-Codex

Claude Sonnet 4.5

Gemini 2.5-pro

2.2. マルチモデルアプローチ

2.3. モデル選択のガイドライン

3. モデル × ツール × インストラクションの組み合わせ

3.1. 成功の方程式とS式の優位性

3.2. エラーファーストでインストラクションする

3.3. 組み合わせの例

4. 何を優先するか、で決定

4.1. 信頼性 vs シンプルさ

4.2. 出力の読みやすさ vs エラー率

4.3. コスト vs 能力

5. 最後に

6. 参照

Discussion