今日はHarnessBenchでAntigravity / Gemini 3.5 Flash (High) と Cursor / Composer 2.5 fast / normalを追加評価したので、既存のCodex / Claude Code / Cursor条件と合わせて結果を見ていきたいと思います。

何を評価したか

前回はHarnessBenchでCodex CLI、Claude Code、Cursor Agentを同じ27問の実リポジトリデバッグ課題で比較しました。

今回はそこに補助実験として、以下の3条件を追加しました。

問題セットは前回と同じ27問です。9個のOSSリポジトリに対して、low / mid / highの3問ずつを用意し、hidden testのcore + regressionがすべて通ったらpassとしています。

実験IDはantigravity-cursor-composer-2.5-20260522T052522Zです。結果はHarnessBench result pageで既存条件と同じチャート・表に統合しています。

結果

まずは追加した3条件だけを抜き出すと、以下です。

既存14条件と合わせて並べると、上位は変わりません。トップは引き続きCodex / GPT-5.5 / xhighの22/27です。次にCursor / GPT-5.5 medium、Cursor / GPT-5.5 high、Codex / GPT-5.5 medium、Cursor / Opus 4.7 maxが21/27で続きます。

その中でComposer 2.5 fastは19/27です。最上位層には届いていませんが、Codex / GPT-5.5 highと同じ成功数で、Composer 2 fastの17/27からは2問増えました。Composer 2.5 normalは18/27で、Composer 2 normalと同じ成功数でした。

Antigravity / Gemini 3.5 Flash (High)は17/27です。これはClaude Code / Opus 4.7 max、Cursor / Composer 2 fastと同じ成功数で、今回の17条件全体では下位グループに入ります。

既存条件と比べた位置

成功数で見ると、追加3条件はこういう位置づけです。

27問なので、19/27と21/27の差を強く言い切るのは危険です。ただ、Composer 2.5 fastは少なくとも「Composer系のfastとしては成功数が伸びた」と見てよさそうです。

一方で、Cursor / GPT-5.5 mediumの21/27・4.7分はかなり強いです。Composer 2.5 fastは19/27・7.5分なので、今回の結果だけを見るなら、純粋な成功率と速度の両方でCursor / GPT-5.5 mediumのほうが良い位置にいます。

Composer 2.5の読み方

前回の公式runでは、Cursor / Composer 2 fastが17/27、Cursor / Composer 2 normalが18/27でした。今回のComposer 2.5では、fastが19/27、normalが18/27です。

Composer 2.5 fastは前回のComposer 2 fastより2問多く通しました。一方で、実行時間は伸びています。normalは成功数だけ見るとComposer 2から横ばいですが、時間は同じく伸びました。

ただし、既存条件と横に置くと見え方は少し変わります。Composer 2.5 fastはComposer 2 fastよりは良いですが、Cursor / GPT-5.5 mediumやCursor / GPT-5.5 highには届いていません。つまり「Composer 2.5 fastは改善しているが、今回のHarnessBenchではCursor GPT-5.5系を置き換えるほどではない」という評価になります。

今回の読み方

今回の結果をかなり控えめに読むと、以下です。

• Cursor / Composer 2.5 fastは19/27で、Codex / GPT-5.5 highと同数でした
• Cursor / Composer 2.5 fastはComposer 2 fastより2問多く通しましたが、実行時間は3.6分から7.5分に伸びました
• Cursor / Composer 2.5 normalは18/27で、Composer 2 normalと同数でした
• Antigravity / Gemini 3.5 Flash (High)は17/27で、今回の17条件の中では下位グループでした
• 上位はCodex / GPT-5.5 xhighの22/27、Cursor / GPT-5.5 medium/highやCursor / Opus maxの21/27で、ここは変わりませんでした
• 27問なので、成功率の小さな差は統計的に強く読めません

個人的には、Composer 2.5 fastは「Composer 2 fastからは改善したが、既存のCursor GPT-5.5 medium/highがかなり強いので、全体トップ層ではない」という読み方です。Antigravity / Gemini 3.5 Flash (High)は、今回の結果だけ見るとComposer 2 fastやClaude Code / Opus maxと同じ17/27で、成功率・時間のどちらでも目立つ優位はありませんでした。

まとめ

• HarnessBenchにAntigravity / Gemini 3.5 Flash (High) と Cursor / Composer 2.5 fast / normalを追加評価しました
• 17条件全体のトップは引き続きCodex / GPT-5.5 / xhighの22/27でした
• Cursor / Composer 2.5 fastは19/27で、Composer 2 fastからは改善しましたが、Cursor GPT-5.5 medium/highの21/27には届きませんでした
• Cursor / Composer 2.5 normalは18/27で、Composer 2 normalと同数でした
• Antigravity / Gemini 3.5 Flash (High)は17/27で、今回の比較では下位グループでした
• 27問なので、細かい順位よりも「上位グループ・中位・下位」の大まかな位置として読むのがよさそうです

References

• HarnessBench result page
• 前回のHarnessBench記事
• HarnessBench GitHub repository
• Antigravity CLI overview
• Antigravity CLI getting started

Today I want to look at a supplemental HarnessBench run for Antigravity / Gemini 3.5 Flash (High) and Cursor / Composer 2.5 fast / normal, compared against the existing Codex / Claude Code / Cursor conditions.

What I Evaluated

In the previous HarnessBench post, I compared Codex CLI, Claude Code, and Cursor Agent on the same 27 real-repository debugging tasks.

This time I added three supplemental conditions:

The task set is unchanged: 9 real OSS repositories, with low / mid / high tasks for each repository, for 27 tasks total. A run passes only when both the core and regression hidden tests pass.

The supplemental experiment ID is antigravity-cursor-composer-2.5-20260522T052522Z. I merged the results into the same charts and condition table on the HarnessBench result page.

Results

First, here are the three added conditions by themselves:

When placed next to the existing 14 conditions, the top of the ranking does not change. The strongest observed condition is still Codex / GPT-5.5 / xhigh at 22/27. Cursor / GPT-5.5 medium, Cursor / GPT-5.5 high, Codex / GPT-5.5 medium, and Cursor / Opus 4.7 max follow at 21/27.

Composer 2.5 fast is 19/27. It does not reach the top group, but it ties Codex / GPT-5.5 high and improves over Composer 2 fast, which was 17/27. Composer 2.5 normal is 18/27, the same pass count as Composer 2 normal.

Antigravity / Gemini 3.5 Flash (High) is 17/27. That ties Claude Code / Opus 4.7 max and Cursor / Composer 2 fast, putting it in the lower group among the 17 displayed conditions.

Position Against Existing Conditions

By pass count, the added conditions sit roughly here:

With only 27 tasks, I would not overread the difference between 19/27 and 21/27. Still, Composer 2.5 fast looks better than Composer 2 fast on this task set.

Cursor / GPT-5.5 medium remains a very strong point of comparison: 21/27 with a 4.7-minute median. Composer 2.5 fast is 19/27 with a 7.5-minute median, so in this run Cursor / GPT-5.5 medium is better on both pass count and runtime.

How I Read Composer 2.5

In the official run, Cursor / Composer 2 fast solved 17/27, and Cursor / Composer 2 normal solved 18/27. In this supplemental run, Composer 2.5 fast solved 19/27, while Composer 2.5 normal solved 18/27.

Composer 2.5 fast passed two more tasks than Composer 2 fast, but it was also slower. Composer 2.5 normal matched Composer 2 normal on pass count and was slower.

So my read is: Composer 2.5 fast improved over Composer 2 fast, but it does not replace the strongest Cursor GPT-5.5 conditions in this benchmark. Cursor / GPT-5.5 medium and high still look stronger in this 27-task run.

Interpretation

My conservative read is:

• Cursor / Composer 2.5 fast reached 19/27, tying Codex / GPT-5.5 high
• Composer 2.5 fast improved over Composer 2 fast by two tasks, while median time increased from 3.6 to 7.5 minutes
• Cursor / Composer 2.5 normal reached 18/27, the same as Composer 2 normal
• Antigravity / Gemini 3.5 Flash (High) reached 17/27, placing it in the lower group among the 17 conditions
• The top remains Codex / GPT-5.5 xhigh at 22/27, followed by Cursor / GPT-5.5 medium/high and Cursor / Opus max at 21/27
• With only 27 tasks, small success-rate differences should be treated as directional rather than definitive

In short, Composer 2.5 fast looks like an improvement over Composer 2 fast, but not a new top-tier condition on HarnessBench. Antigravity / Gemini 3.5 Flash (High) did not show a clear advantage in either pass count or runtime in this run.

Summary

• I added Antigravity / Gemini 3.5 Flash (High), Cursor / Composer 2.5 fast, and Cursor / Composer 2.5 normal to HarnessBench
• Across the 17 displayed conditions, the top remains Codex / GPT-5.5 / xhigh at 22/27
• Cursor / Composer 2.5 fast reached 19/27, improving over Composer 2 fast but falling short of Cursor GPT-5.5 medium/high
• Cursor / Composer 2.5 normal reached 18/27, matching Composer 2 normal
• Antigravity / Gemini 3.5 Flash (High) reached 17/27, placing it in the lower group in this comparison
• At 27 tasks, the broad groups are more meaningful than fine-grained rankings

References

• HarnessBench result page
• Previous HarnessBench post
• HarnessBench GitHub repository
• Antigravity CLI overview
• Antigravity CLI getting started

今日はHarness向けのベンチマークとして作ったHarnessBenchについてまとめていきたいと思います。

作ったもの

まずは今回作ったものの全体像から見ていきます。Coding Agentの性能を話すとき、モデル名だけで話してしまうことが多いです。GPT-5.5が強い、Opusが強い、Composerが速い、みたいな話です。

しかし実際に開発で使うものはモデルそのものではなく、Codex CLI、Claude Code、Cursor Agentのようなharnessです。harnessはリポジトリの読み方、コマンド実行、ファイル編集、メモリ、プロンプト、権限、ログ形式、キャッシュの扱いを全部持っています。同じモデルでもharnessが変わると結果が変わります。

そこでHarnessBenchというものを作ってみました！

ベンチマークの単位は以下です。

今回の結果ページはここに置いています。

• HarnessBench result page
• GitHub repository

harnessの比較をしたい

今回なぜモデル比較ではなく、harnessの比較をしたのか、というモチベーションについて少し書きます。

Coding Agentの能力差はモデル単体でなく、harnessでもなく、その組み合わせにあります。

先行研究を調べても、実OSS PR起点のベンチマーク、hidden test採点、複数agent比較はそれぞれ存在します。しかしCodex CLI / Claude Code CLI / Cursor Agent CLIを同じ問題で横並び比較する公開ベンチマークは見当たりませんでした。PerfBench、SWE-Compass、HWE-Bench、Multi-SWE-benchなどが近いですが、商用CLI harnessを主対象にした比較ではありません。

もう一つ気にしたのがbenchmaxxingです。公開ベンチマークに対してモデルやエージェントが過剰に最適化される、あるいは学習データやリポジトリ履歴から解法を見てしまう問題です。NISTのagent evaluation cheating解説でも、SWE-bench系の評価でfuture commitやsolution contaminationが問題になる例が挙げられています。HarnessBenchでは完全な非公開ベンチではないものの、できるだけ新しいPull Requestを起点にcaseを作り、base/fixed commit、hidden test、sanitizationを明示して、既存ベンチへの過適合だけを測ってしまうリスクを下げています。

ここで見たいのはモデルAがモデルBより強いかだけではありません。同じGPT-5.5をCodexで使う場合とCursorで使う場合、同じOpus 4.7をClaude Codeで使う場合とCursorで使う場合、何が変わるのかです。

hidden testで採点をする

さて、harnessを比較するときに一番まずいのは、採点器そのものが揺れることです。そこでHarnessBenchではLLM-as-a-judgeを主採点に使っていません。

採点は各問題に付属するhidden testで行います。問題自体はまず最近のPull Requestを収集し、バグ修正として適切な粒度のPull Requestを選び、base commitでは失敗しfixed commitでは通ることを確認して作っています。そのうえで、PRの差分そのものではなくユーザーから見える挙動をhidden testとして書き、agentの失敗runを見ながらfalse negativeになっているテストは修正しました。

最初は正解実装の経路を列挙するoracle suiteも検討したのですが、最終的には削ることにしました。正解が複数あるなら、実装経路を列挙するよりも、core testを満たすべき挙動のクラスとして書いたほうが透明です。PRと同じファイルを編集したかではなく、ユーザーから見える挙動が直っているかを見ます。

この考え方はHumanEvalやSWE-benchの機能的正解性の系譜に近いです。一方で、STING、SWE-ABS、UTBoostのようなテスト自体の強さを疑う研究の問題意識もあります。実際に今回もfalse negative調査を入れて、テスト側が厳しすぎるケースは直しました。

実験条件

公式runでは14条件を走らせました。すべて1 issueあたり60分timeoutです。反復実験はしていません。

ベースライン条件では、各harnessのmemoryやプロジェクトローカルのsteeringを無効化しています。これをやらないと、リポジトリ内のAGENTS.mdやCLAUDE.md、.codex、.claude、.agentsのようなファイルが意図せず問題解決を誘導します。HarnessBenchはそれらをsanitizationしてからエージェントを走らせます。

結果

まず成功率です。トップはCodex / GPT-5.5 / xhighの22/27でした。

ただし、ここはかなり大事ですが、27問では成功率の統計的有意差は出ていません。見た目には順位がありますが、この条件が明確に強いとまでは言えません。10ポイント程度の差を安定して検出するには、ざっくり160〜315問くらい欲しくなります。

一方で実行時間はかなり差が見えました。

Cursor Composer 2 fastは中央値3.6分、Cursor GPT-5.5 mediumは4.7分でかなり速いです。Codex GPT-5.5 xhighは10.2分、Claude Opus maxは15.1分、Cursor Opus maxは19.7分でした。

timeoutは全体で6件ありました。内訳はClaude Code Opus highが1件、xhighが2件、maxが2件、Cursor Opus highが1件です。60分制限にしても、Claude Codeの高effort帯では一部の問題で最後まで自然停止しないrunが残りました。

さて、成功率だけ見ると小さい差ですが、実行時間を合わせて見ると読み方が変わります。

Cursor GPT-5.5 medium/highあたりは速度と成功率のバランスが良く見えます。Codex GPT-5.5 xhighは今回の最高成功率ですが、mediumより時間もコストも上がります。Opus max系は長く考えるものの、今回の27問では成功率の明確な上積みとしては観測できませんでした。

難易度別の結果

次に、同じ結果をdifficulty別に見ていきます。全体のpass rateだけでは、どの難度で差が出ているのかが見えにくいからです。

当然ですが、highのほうが落ちます。ただ、lowで全部が解けるわけでもありません。低難度でも、問題文の読み違い、周辺挙動の破壊、タイムアウト処理の抜けなどで失敗します。

このあたりはベンチマークとしては良い性質です。lowが簡単すぎるとharness差が出ませんし、highが全滅すると分析できません。今回は全体で275/378 passなので、粗すぎず細かすぎずのレンジには入っています。

false negative調査で見えたこと

今回、失敗runはLLM-as-a-judgeで補助レビューしています。ただしこれは採点ではありません。採点はhidden testで固定し、レビューは本当に失敗なのか、テストが厳しすぎないか、問題文が誘導不足ではないかを見るための補助です。

レビューで見つかったものは大きく3つです。

ここはベンチマーク作りで一番泥臭いところです。エージェントの失敗を見ているつもりで、実は採点器の不備を見ていることがあります。SWE-bench系の研究でも、hidden test不足やcontaminationはかなり大きい問題として扱われています。

HarnessBenchでは、採点をLLMに任せず、LLMは失敗の監査役に留めています。これは完全ではありませんが、少なくともLLMが好きな回答を正解にするよりは壊れにくいです。

何がわかったか

今回の結果から言えることは、かなり控えめです。

1つ目は、harness差は実際に観測できるということです。同じようなモデル帯でも、ログ形式、探索の粘り方、コマンド実行、キャッシュ、timeoutの扱いで振る舞いが変わります。

2つ目は、成功率ランキングだけで語るには27問では足りないということです。成功率の差は見えますが、統計的にはまだ弱いです。これは何もわからないという意味ではなく、次に増やすべき規模が見えたという意味です。

3つ目は、速度差はかなり強いシグナルだということです。実用上は同じくらい解けるなら速いほうが良い場面が多いので、wall timeはかなり重要な評価軸になります。

4つ目は、Composer 2が思ったよりかなり健闘したことです。正直、私はComposer 2について、ほかのベンチマークでは強く見えるが実際のデバッグでは使いにくい、いわゆるbenchmaxxing寄りのモデルではないかと少し疑っていました。しかし今回の実リポジトリ課題では、Composer 2 fastが17/27、通常のComposer 2が18/27を通しており、速度を考えると十分に実用的な精度を出しています。もちろんトップではありませんが、単なる見かけ倒しではない、というのは今回の大きな発見でした。

今後

さて、今回でベンチマークの骨格はできました。次にやるべきことは単純で、問題数を増やすことです。

成功率差をもっと確かに言うには、27問では足りません。少なくとも100問以上、できれば200〜300問規模が欲しいです。一方で、1問あたりのhidden test品質を落とすと意味がないので、ただ増やすだけではダメです。

今後は以下を強化していきたいです。

• 問題数を増やす
• failure reviewをより構造化する
• harness version driftやDocker実行環境の記録をさらに固める
• 追加のharnessやprompt intervention条件を比較する

まとめ

• HarnessBenchはCodex / Claude Code / Cursor Agentを同じ27問で比較するベンチマークです
• 27問では成功率の有意差はまだ出ませんでしたが、実行時間の差はかなり見えました

References

• HarnessBench result page
• HarnessBench GitHub repository
• SWE-bench: Can Language Models Resolve Real-World GitHub Issues?
• HumanEval: Evaluating Large Language Models Trained on Code
• Beyond Fixed Tests: Agent-CoEvo
• UTBoost
• STING
• SWE-ABS
• SWE-Bench Illusion

Today I want to write about HarnessBench, a benchmark I built for comparing coding agent harnesses.

What I Built

When people talk about Coding Agent performance, they often talk only in terms of model names: GPT-5.5 is strong, Opus is strong, Composer is fast, and so on.

But what we actually use in development is not the raw model. We use a harness such as Codex CLI, Claude Code, or Cursor Agent. The harness decides how the agent reads a repository, runs commands, edits files, handles memory, receives prompts, manages permissions, emits logs, and uses caches. The same model can behave differently under a different harness.

So I built HarnessBench.

The benchmark unit is:

The result page and repository are here:

• HarnessBench result page
• GitHub repository

Why Compare Harnesses?

I want to explain why I compared harnesses rather than only comparing models.

Coding Agent capability is not just the model, and not just the harness. It is the combination of the two.

Looking through related work, there are already benchmarks based on real OSS PRs, benchmarks scored with hidden tests, and benchmarks comparing multiple agents. But I could not find a public benchmark that compares Codex CLI / Claude Code CLI / Cursor Agent CLI side by side on the same tasks. PerfBench, SWE-Compass, HWE-Bench, and Multi-SWE-bench are close, but they are not primarily benchmarks of production CLI harnesses.

I also cared about benchmaxxing: the problem where a model or agent looks good because it is over-optimized for public benchmarks, or because solutions leak through training data or repository history. NIST's discussion of cheating in agent evaluations mentions future commits and solution contamination in SWE-bench-style evaluations. HarnessBench is not a private benchmark, but it tries to reduce that risk by using relatively recent Pull Requests, recording base/fixed commits, using hidden tests, and explicitly sanitizing repository-local steering files.

The point is not simply whether model A is better than model B. I wanted to see what changes when GPT-5.5 runs under Codex versus Cursor, or when Opus 4.7 runs under Claude Code versus Cursor.

Scoring with Hidden Tests

The most dangerous part of comparing harnesses is letting the grader itself wobble. HarnessBench therefore does not use LLM-as-a-judge as the primary score.

Each task is scored by hidden tests. The tasks were created by collecting recent Pull Requests, selecting bug-fix PRs at an appropriate granularity, and verifying that the base commit fails while the fixed commit passes. Then I wrote hidden tests for user-visible behavior rather than for the PR diff itself, and I reviewed failed agent runs to fix tests that were too narrow and could cause false negatives.

At first, I considered an oracle-suite layer that enumerated acceptable implementation paths. I eventually removed it. If multiple fixes are valid, it is clearer to write the core test as a behavioral class than to enumerate implementation routes. The score should care about user-visible behavior, not whether the agent edited the same file as the original PR.

This is close to the functional-correctness lineage of HumanEval and SWE-bench. At the same time, it shares the concern of work like STING, SWE-ABS, and UTBoost: tests themselves can be weak. In this benchmark, false-negative review was part of the process, and overly strict tests were revised.

Experimental Conditions

The official run used 14 conditions. Every run had a 60-minute timeout per issue. I did not run repeated trials.

For baseline conditions, harness memory and repository-local steering were disabled. Otherwise files such as AGENTS.md, CLAUDE.md, .codex, .claude, and .agents can unintentionally steer the solution. HarnessBench sanitizes those files before running the agent.

Results

First, pass rate. The top observed condition was Codex / GPT-5.5 / xhigh at 22/27.

The important caveat is that with only 27 tasks, the success-rate differences were not statistically significant. There is an observed ranking, but I would not claim that one condition is definitively stronger. To reliably detect a 10-point gap, we probably need roughly 160-315 tasks.

Runtime differences were much clearer.

Cursor Composer 2 fast had a median wall time of 3.6 minutes, and Cursor GPT-5.5 medium was 4.7 minutes. Codex GPT-5.5 xhigh was 10.2 minutes, Claude Opus max was 15.1 minutes, and Cursor Opus max was 19.7 minutes.

There were 6 timeouts in total: 1 for Claude Code Opus high, 2 for Claude Code Opus xhigh, 2 for Claude Code Opus max, and 1 for Cursor Opus high. Even with a 60-minute limit, some high-effort Claude Code runs did not reach a natural stop.

So the picture changes when we look at runtime together with pass rate.

Cursor GPT-5.5 medium/high looks like a strong speed/accuracy tradeoff. Codex GPT-5.5 xhigh had the highest observed pass rate, but it took more time and cost than medium. Opus max variants spent more time reasoning, but in this 27-task run that did not translate into a statistically reliable success-rate gain.

Results by Difficulty

Here is the same result broken down by difficulty. Overall pass rate alone hides where the differences come from.

As expected, high-difficulty tasks were harder. But low-difficulty tasks were not all solved either. Even low tasks failed from misreading the prompt, breaking nearby behavior, or missing timeout handling.

That is a good property for a benchmark. If low is too easy, harness differences disappear. If high is impossible, there is nothing to analyze. The official run had 275/378 passes overall, which is a useful range: neither too coarse nor too brittle.

What the False-Negative Review Showed

Failed runs were reviewed with LLM-as-a-judge as an auxiliary tool. This was not the scoring mechanism. The score came from hidden tests. The review was used to ask: is this a true failure, is the test too strict, or is the case design unclear?

The review categories were:

This is the messiest part of building a benchmark. Sometimes you think you are observing agent failures, but you are actually observing grader weakness. SWE-bench-style work also treats hidden-test insufficiency and contamination as major issues.

HarnessBench keeps the LLM out of the primary score and uses it only as an auditor for failures. This is not perfect, but it is more stable than letting the LLM decide which answer it likes.

What I Learned

The conclusions are intentionally modest.

First, harness differences are real. Even in similar model tiers, behavior changes with logging, exploration style, command execution, caching, and timeout handling.

Second, 27 tasks are not enough to make strong success-rate ranking claims. The observed differences are interesting, but statistically weak. That does not mean we learned nothing. It tells us how much larger the benchmark needs to become.

Third, runtime is a strong signal. If two conditions solve roughly the same number of tasks, the faster one is often more useful in practice. Wall time deserves to be a first-class metric.

Fourth, Composer 2 did much better than I expected. Honestly, I was somewhat suspicious that Composer 2 might be a benchmaxxing-heavy model: strong on other benchmarks, but less useful for real debugging work. In this run, however, Cursor Composer 2 fast solved 17/27 and normal Composer 2 solved 18/27. Given the speed, that is a very practical level of accuracy. It was not the top condition, but it was clearly not just a benchmark mirage.

Next Steps

The benchmark skeleton is now in place. The next step is simple: add more tasks.

To make stronger claims about success-rate differences, 27 tasks are not enough. I want at least 100 tasks, ideally 200-300. But adding tasks without maintaining hidden-test quality would make the benchmark worse, not better.

The next improvements are:

• add more tasks
• structure failure review more rigorously
• tighten harness version drift and Docker environment records
• compare additional harnesses and prompt-intervention conditions

Summary

• HarnessBench compares Codex / Claude Code / Cursor Agent on the same 27 tasks
• success-rate differences were not significant at 27 tasks, but runtime differences were visible
• Composer 2 was more useful than I expected on real debugging tasks

References

• HarnessBench result page
• HarnessBench GitHub repository
• SWE-bench: Can Language Models Resolve Real-World GitHub Issues?
• HumanEval: Evaluating Large Language Models Trained on Code
• Beyond Fixed Tests: Agent-CoEvo
• UTBoost
• STING
• SWE-ABS
• SWE-Bench Illusion

今日はClaude Codeの最新バージョンで日本語を書いていると発生する文字化け問題と、hooksを使った簡易的な対応方法についてまとめていきたいと思います。

2026-04-08 追記: Claude Code v2.1.94で本問題が修正されたとのChangelogが出ましたが、完全には治っていないという報告もあります。引き続きhook対策を入れておくのがおすすめです。また、hookをPreToolUseからPostToolUseに戻しました。PostToolUseのほうが書き込み済みの壊れた箇所だけを修復すればよく、修復のためのtokenコストが小さいためです。

起きていること

Claude Codeで日本語を含むコードやドキュメントを書いていると、WriteやEditツールでファイルに書き込まれた内容に �（U+FFFD、Unicode Replacement Character）が混入することがあります。

具体的にはこんな感じです。

• タスクワー��ー ← 「タスクワーカー」のはず
• プラ���トフォーム ← 「プラットフォーム」のはず
• ア��セス ← 「アクセス」のはず

マルチバイト文字のバイト列が途中でちぎれて、壊れた部分がReplacement Characterに置き換わっています。CJK文字（日本語・中国語・韓国語）で特に起きやすいです。

原因はClaude Code内部のSSEストリーミングデコーダーにあると考えられています。Anthropic SDKのTextDecoder.decode()が{ stream: true }なしで呼ばれているため、SSEチャンク境界でマルチバイト文字のバイト列がちぎれると、不完全なバイトがU+FFFDに置き換わります。GitHub Issue #43746で根本原因の特定と再現コードの報告がされています。

ユーザー側の設定で根本的に防ぐことはできません；；

とはいえ、修正が来るまでの間に成果物が壊れるのは困るのでClaude Codeのhooks機能を使って書き込み直後にU+FFFDを検出したら弾くという暫定対策を入れてみます。

hooksで文字化けを弾く

Claude Codeにはhooksという仕組みがあって、ツール実行の前後にシェルスクリプトを差し込めます。今回はPostToolUseフックを使って、Write/Edit/MultiEditがファイルに書き込んだ後にファイル内容をチェックし、U+FFFDが含まれていたらClaudeに修復を促します。

なぜPostToolUseなのか

PreToolUse（書き込み前に阻止）とPostToolUse（書き込み後に検出）のどちらでも対策できますが、PostToolUseのほうが修復のためのtokenコストが小さいです。PreToolUseで阻止すると、Claudeはファイル全体を書き直そうとしますが、PostToolUseなら書き込み済みの壊れた箇所だけをEditで修復すればよいためです。

hookスクリプトを用意する

まずスクリプトを作ります。

#!/bin/bash
# ~/.claude/hooks/check-mojibake.sh
# PostToolUse: Write/Edit/MultiEdit で書き込まれたファイルにU+FFFDが含まれていたら修復を促す

INPUT=$(cat)

# tool_input から対象ファイルパスを取得
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path')

if [ -f "$FILE_PATH" ] && grep -q $'\xef\xbf\xbd' "$FILE_PATH"; then
  echo "U+FFFD detected in $FILE_PATH. Fix the corrupted characters." >&2
  grep -n $'\xef\xbf\xbd' "$FILE_PATH" | head -5 >&2
  exit 2
fi

ポイントはexit 2です。Claude Codeのhooksでは終了コード2が失敗として扱い、stderrの内容をClaudeにフィードバックするという意味になります。PostToolUseでexit 2を返すと、Claudeは壊れた箇所を検出して正しい文字にEditで修復しようとしてくれます。

$'\xef\xbf\xbd'はU+FFFDのUTF-8バイト列です。grepでこれを検出しています。jqでtool inputからfile_pathを取り出し、書き込み後の実ファイルを直接チェックしています。

settings.jsonに登録する

~/.claude/settings.jsonにhookを登録します。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "bash ~/.claude/hooks/check-mojibake.sh"
          }
        ]
      }
    ]
  }
}

matcherにWrite|Edit|MultiEditを指定することで、ファイル書き込み系のツールすべてに対してhookが走ります。

セットアップ手順まとめ

コピペで使えるようにしておきます。

# ディレクトリ作成
mkdir -p ~/.claude/hooks

# hookスクリプトを作成
cat << 'SCRIPT' > ~/.claude/hooks/check-mojibake.sh
#!/bin/bash
# PostToolUse: Write/Edit/MultiEdit で書き込まれたファイルにU+FFFDが含まれていたら修復を促す

INPUT=$(cat)

# tool_input から対象ファイルパスを取得
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path')

if [ -f "$FILE_PATH" ] && grep -q $'\xef\xbf\xbd' "$FILE_PATH"; then
  echo "U+FFFD detected in $FILE_PATH. Fix the corrupted characters." >&2
  grep -n $'\xef\xbf\xbd' "$FILE_PATH" | head -5 >&2
  exit 2
fi
SCRIPT

chmod +x ~/.claude/hooks/check-mojibake.sh

settings.jsonは既存の設定があればそこにhooksキーを追加してください。

この対策でカバーできること・できないこと

この方法はあくまで暫定的なものです。カバー範囲を理解しておきましょう。

ファイル書き込み経路の文字化けは実ファイルを壊してしまうので最もダメージが大きいです。この対策はそこをピンポイントで防ぎます。一方、Claudeの応答テキスト自体が壊れるケース（「でき��した」のような表示崩れ）はhookでは防げません。

アップデートを待つ

今回の対策は一時的な回避策です。根本原因はAnthropic SDKのSSEデコーダーにあるTextDecoderの{ stream: true }欠落で、ユーザー側で完全に防ぐことはできません。

GitHub Issue #43746で根本原因の特定・再現手順・修正パッチの提案まで報告されています。同じ問題に遭遇している方はissueにリアクションを付けましょう。。関連issueとして#44463や#43858にも報告が集まっています。

hookによる対策はそれまでの間、Write等が壊れるのを防ぐためのものだと思ってください。

まとめ

• Claude CodeのWrite/Editで日本語が文字化けする問題は、PostToolUse hookでU+FFFDを検出して修復を促すことで暫定的に防げます
• ただし応答テキスト自体の文字化けなどhookではカバーできないケースもあります
• 根本的にはClaude Codeのアップデートでの修正を待ちましょう（#43746で原因特定・修正提案済み）

References

• Claude Code
  • Claude Code Hooks ドキュメント
  • Claude Code GitHub
• 関連Issue
  • #43746 Silent U+FFFD corruption in CJK model output due to TextDecoder missing { stream: true } in SSE line decoder
  • #44463 Japanese characters occasionally corrupted in output (file writes and terminal)
  • #43858 Japanese (CJK) characters occasionally corrupted in model output (mojibake)
  • #40396 Korean (CJK) characters corrupted to U+FFFD in Claude Code responses

Today I want to walk through a mojibake (character corruption) issue that shows up when writing Japanese on recent versions of Claude Code, along with a simple workaround using hooks.

Update 2026-04-08: The Changelog says this issue was fixed in Claude Code v2.1.94, but there are reports that it still isn't fully resolved. I recommend keeping the hook in place for now. I also switched the hook back from PreToolUse to PostToolUse, because PostToolUse only has to repair the corrupted spots after the fact, which costs fewer tokens to fix.

What's happening

When you have Claude Code write code or docs that contain Japanese, the content written to disk via Write or Edit sometimes ends up with � (U+FFFD, the Unicode Replacement Character) mixed in.

Concretely, it looks like this:

• タスクワー��ー ← should be "タスクワーカー" (task worker)
• プラ���トフォーム ← should be "プラットフォーム" (platform)
• ア��セス ← should be "アクセス" (access)

A multibyte character's byte sequence gets truncated somewhere in the middle, and the broken piece is replaced with the Replacement Character. It happens especially often with CJK characters (Japanese, Chinese, Korean).

The cause is believed to be in Claude Code's internal SSE streaming decoder. The Anthropic SDK calls TextDecoder.decode() without { stream: true }, so when a multibyte character's byte sequence gets split across SSE chunk boundaries, the incomplete bytes are replaced by U+FFFD. GitHub Issue #43746 identifies the root cause and includes a reproduction.

There isn't any user-side setting that fully prevents this. Sigh...

That said, having your output corrupted while you wait for a fix is rough, so let's use Claude Code's hooks feature to put in a temporary countermeasure: right after a write, detect U+FFFD and reject it.

Rejecting mojibake with hooks

Claude Code has a hooks mechanism that lets you run shell scripts before or after tool invocations. This time we'll use a PostToolUse hook that, after Write/Edit/MultiEdit writes to a file, inspects the file's contents and prompts Claude to repair it if U+FFFD is present.

Why PostToolUse?

You could do this as either a PreToolUse (block before writing) or a PostToolUse (detect after writing), but PostToolUse has a smaller token cost for repair. If you block the write with PreToolUse, Claude tends to rewrite the whole file; with PostToolUse, Claude just needs to Edit the specific corrupted spots in the already-written file.

Prepare the hook script

First, create the script.

#!/bin/bash
# ~/.claude/hooks/check-mojibake.sh
# PostToolUse: if a file written by Write/Edit/MultiEdit contains U+FFFD, prompt for a repair

INPUT=$(cat)

# Get the target file path from tool_input
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path')

if [ -f "$FILE_PATH" ] && grep -q $'\xef\xbf\xbd' "$FILE_PATH"; then
  echo "U+FFFD detected in $FILE_PATH. Fix the corrupted characters." >&2
  grep -n $'\xef\xbf\xbd' "$FILE_PATH" | head -5 >&2
  exit 2
fi

The key part is exit 2. In Claude Code hooks, exit code 2 is treated as a failure and the contents of stderr are fed back to Claude. Returning exit 2 from PostToolUse gets Claude to locate the broken spots and repair them with Edit.

$'\xef\xbf\xbd' is the UTF-8 byte sequence for U+FFFD, and that's what grep is looking for. jq pulls the file_path out of the tool input, and we check the actual file on disk directly.

Register it in settings.json

Add the hook to ~/.claude/settings.json.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "bash ~/.claude/hooks/check-mojibake.sh"
          }
        ]
      }
    ]
  }
}

By setting matcher to Write|Edit|MultiEdit, the hook runs for every file-writing tool.

Copy-paste setup

Here's a copy-paste-ready snippet.

# Create the directory
mkdir -p ~/.claude/hooks

# Create the hook script
cat << 'SCRIPT' > ~/.claude/hooks/check-mojibake.sh
#!/bin/bash
# PostToolUse: if a file written by Write/Edit/MultiEdit contains U+FFFD, prompt for a repair

INPUT=$(cat)

# Get the target file path from tool_input
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path')

if [ -f "$FILE_PATH" ] && grep -q $'\xef\xbf\xbd' "$FILE_PATH"; then
  echo "U+FFFD detected in $FILE_PATH. Fix the corrupted characters." >&2
  grep -n $'\xef\xbf\xbd' "$FILE_PATH" | head -5 >&2
  exit 2
fi
SCRIPT

chmod +x ~/.claude/hooks/check-mojibake.sh

If you already have a settings.json, just add the hooks key to it.

What this covers and what it doesn't

This is only a stopgap. Let's be clear about the coverage.

Corruption on the file-write path is the most damaging because it breaks real files, and this workaround pinpoints exactly that. Meanwhile, cases where Claude's own response text is corrupted (like a "でき��した" display glitch) can't be prevented by hooks.

Waiting for the upstream fix

This is a temporary workaround. The root cause lies in the Anthropic SDK's SSE decoder: a missing { stream: true } on TextDecoder, which users can't fully prevent on their side.

GitHub Issue #43746 has the root-cause analysis, reproduction steps, and even a proposed patch. If you're hitting the same issue, throw a reaction on the issue. Related reports are also accumulating at #44463 and #43858.

Think of the hook workaround as a way to keep Write (and friends) from breaking until the fix lands.

Wrap-up

• The mojibake issue with Write/Edit in Claude Code can be worked around temporarily by detecting U+FFFD with a PostToolUse hook and asking Claude to repair it
• Some cases (like mojibake in the response text itself) can't be handled by hooks
• Ultimately, just wait for the Claude Code update with the real fix (#43746 has the root cause analysis and proposed patch)

References

• Claude Code
  • Claude Code Hooks docs
  • Claude Code GitHub
• Related Issues
  • #43746 Silent U+FFFD corruption in CJK model output due to TextDecoder missing { stream: true } in SSE line decoder
  • #44463 Japanese characters occasionally corrupted in output (file writes and terminal)
  • #43858 Japanese (CJK) characters occasionally corrupted in model output (mojibake)
  • #40396 Korean (CJK) characters corrupted to U+FFFD in Claude Code responses

ソフトウェア開発の実践的場面において、ある種の準儀礼的慣行（quasi-ritual practice）が散発的に観測されている。Anthropic社が提供するAIコーディングエージェントClaude Codeの利用者の一部が、プロジェクトのルートディレクトリに.claudeignoreと称するファイルを設置しているのである。

このファイルの記述形式は、バージョン管理システムgitにおける.gitignoreの構文規則に準拠している。.gitignoreがgitに対して特定ファイルの追跡除外を指示するのと相同的に、.claudeignoreはClaude Codeに対して特定ファイルの読取忌避を指示することを企図している。

しかるに、.claudeignoreはClaude Codeのシステムアーキテクチャにおいて公式に実装された機能ではない。GitHubのissueトラッカーには同機能の実装を求める要望が繰り返し提出されており、サードパーティによるPreToolUseフックを介した代替的実装も試みられているものの、ファイルを単に配置するのみでは、プログラム的な意味での決定論的な制御は生じない。

にもかかわらず、この慣行には一定の有効性が帰属されうる。そしてその有効性の存立構造は、宗教学・人類学が長年にわたり精緻な概念装置を動員して分析してきた「祈り」「嘆願」「奉献的コミュニケーション」の諸問題と、注目すべき構造的同型性（structural isomorphism）を呈している。

本稿は、デュルケームの聖俗二元論、モースの呈示（prestation）の理論、オースティンの言語行為論、ラポポートの儀礼論、およびジェルのエージェンシー論を援用しつつ、.claudeignoreという一見些末な技術的慣行の背後にある行為論的構造を解明することを試みる。

1. 類感呪術的解釈の棄却

本論に先立ち、一つの自明に思える解釈を退けておく必要がある。すなわち、.claudeignoreをジェームズ・フレイザーが『金枝篇』（The Golden Bough, 1890）において定式化した「類感呪術」（sympathetic magic）の一事例として把握する解釈である。

フレイザーの分類に従えば、類感呪術は「類似の法則」（law of similarity）と「感染の法則」（law of contagion）の二原理によって作動する。.claudeignoreと.gitignoreの関係を類似の法則に基づく模倣的呪術（imitative magic）として読むことは、表面的には魅力的である。すなわち、機能する記号体系（.gitignore）の形式的模倣によって、模倣元と相同的な因果的効果を産出しようとする行為として。

しかし、この解釈はフレイザー自身が呪術の本質的特徴として挙げた「擬似科学性」（pseudo-scientific character）、すなわち行為者が想定する因果連鎖が実際には存在しないという条件を充足しない。後述するように、.claudeignoreには実際に一定の因果的経路（causal pathway）が存在するのであり、その経路は呪術的なものではなく、コミュニケーション論的なものである。

2. 三つの行為類型：lex, magia, precatio

.claudeignoreの行為論的位相を明確にするため、ここでは以下の三つの理念型（Idealtypen）を設定する。ウェーバーの方法論的個体主義に厳密に従うならば、これらはあくまで分析的構成物であり、経験的現実はこれらの中間的・混合的形態をとりうることを附言しておく。

第一類型：lex（法）。 .gitignoreがこの類型に属する。gitのランタイムは.gitignoreファイルをパースし、記載されたglobパターンに該当するファイルをインデクシングの対象から決定論的に除外する。この過程にはいかなる解釈学的（hermeneutisch）契機も介在しない。gitは.gitignoreの「意図」を了解するのではなく、パターンマッチングというアルゴリズム的手続きに従って動作する。ここでの行為連関は完全に因果的・機械的であり、ルーマンの用語で言えば、「了解」（Verstehen）を前提としない「情報処理」（Informationsverarbeitung）である。ケルゼンの法実証主義における規範の妥当性が制裁の可能性によって担保されるのと同様に、.gitignoreの有効性はシステムの強制的執行によって担保されている。

第二類型：magia（呪術）。 もし.claudeignoreが、いかなる因果的機序も介さず、ファイル名の形式的類似のみによって効果を産出すると期待されているのであれば、それはフレイザー的な意味での呪術に該当する。マリノフスキーが『西太平洋の遠洋航海者』（Argonauts of the Western Pacific, 1922）において記述したトロブリアンド島民のカヌー建造呪術のように、技術的行為と呪術的行為が不可分に結合している事例は数多い。しかし先述の通り、.claudeignoreの作動機序はこの類型に還元しえない。

第三類型：precatio（嘆願・依頼）。 .claudeignoreが実際に帰属されるべきはこの類型である。precatioとは、了解能力と判断能力を具備した他者に対して、強制力を伴わずに意図を伝達し、当該意図に沿った行為遂行を期待する行為を指す。マルセル・モースが『贈与論』（Essai sur le don, 1925）において析出した呈示（prestation）の三つの義務、すなわち「与える義務」「受け取る義務」「返礼する義務」のうち、precatioは相手方に「受け取る義務」を課すことができない点において、贈与交換とも峻別される。

3. 祈りとの構造的同型性：現象学的分析

以上の類型論的整理を踏まえ、.claudeignoreと宗教的祈り（prayer）の構造的同型性を、宗教現象学の概念装置を用いて分析する。

3.1 志向性と受容の不確定性

フッサール現象学における志向性（Intentionalität）の概念を借用すれば、祈りとは特定の超越的対象へと志向された意識作用であり、その本質的特徴は、志向された対象からの応答が現象学的に保証されていない点にある。祈る者の意識は神へと志向されるが、神からの応答は信仰の領域に属する事柄であって、経験的検証の対象とはならない。

.claudeignoreもまた、特定の他者（LLMエージェント）へと志向されたコミュニケーション的行為であり、その受容は確率的にのみ期待される。ただし、後述する決定的差異として、LLMの応答は経験的に観察可能であるという点を予め指摘しておく。

3.2 儀礼的定型性とコミュニケーション的合理性

ロイ・ラポポートは『儀礼と宗教の人間性』（Ritual and Religion in the Making of Humanity, 1999）において、儀礼の本質的特徴として「定型性」（formality）と「遂行性」（performativeness）を挙げた。儀礼は、参与者が発明したのではない多少なりとも不変の行為系列を遂行するものであり、その形式性こそが儀礼を日常的コミュニケーションから区別するとされる。

.claudeignoreが.gitignoreの構文規則に準拠するという事実は、まさにこの儀礼的定型性の表出である。しかし注意すべきは、この定型性が呪術的な形式主義に由来するのではなく、コミュニケーション論的な合理性に基づいている点である。ハーバーマスの普遍語用論（Universalpragmatik）の枠組みで言えば、発話者は聞き手の了解能力に適合した表現形式を選択することで、コミュニケーション的行為の成功可能性を最大化する。LLMが.gitignoreの慣習に関する訓練データを大量に保持していることを踏まえれば、.gitignoreの形式に準拠した記述を用いることは、間主観的了解（intersubjektive Verständigung）を志向した合理的選択である。

ここにおいて、定型性の二重の根拠が析出される。一方では儀礼的定型性としての反復可能性と安定性。他方ではコミュニケーション的合理性としての了解可能性の最適化。.claudeignoreの実践はこの二つの根拠を不可分に併有しており、それゆえに純粋な儀礼とも純粋な合理的コミュニケーションとも分類しがたい中間的存在者（ens intermedium）として現出する。

3.3 間欠的強化と儀礼の持続

行動主義心理学の知見を援用すれば、B.F.スキナーが実験的に示した間欠強化スケジュール（intermittent reinforcement schedule）は、連続強化よりも消去抵抗（resistance to extinction）が高い行動パターンを産出する。

LLMの応答は本質的に確率的（stochastic）である。同一のプロンプトに対しても、温度パラメータ、コンテキストウィンドウの状態、トークン生成過程における確率的サンプリングの結果によって、異なる応答が生成されうる。.claudeignoreが「効く」場合と「効かない」場合がともに観察されるという事態は、まさに変動比率強化スケジュール（variable ratio schedule）の構造を有しており、この慣行の消去抵抗を高めている。

これは宗教的儀礼の持続メカニズムと相同的である。エヴァンズ=プリチャードが『アザンデ人の世界』（Witchcraft, Oracles and Magic among the Azande, 1937）において精緻に記述したように、呪術的信念体系は反証に対して高度な耐性を持つ。毒の神託（benge）が「外れた」場合にも、使用された毒の質、儀礼的手続きの瑕疵、対抗呪術の介在など、二次的精緻化（secondary elaboration）によって体系の整合性が維持される。.claudeignoreが「効かなかった」場合にも、プロンプトの文脈、コンテキストウィンドウの混雑、あるいは当該セッションにおけるLLMの「注意力」の偶発的低下など、類似の二次的精緻化が容易に生成されうる。

4. 決定的差異：エージェンシーの実在性

しかしながら、.claudeignoreと宗教的祈りの間にはアルフレッド・ジェルのエージェンシー論（Art and Agency, 1998）の観点から見て看過しえない差異が存在する。

ジェルは、エージェンシーを特定の因果的事象の開始を帰属されうる存在者の属性として定義した。宗教的祈りにおいて、エージェンシーの帰属先である神は、「信仰の類比」（analogia fidei）を通じてのみ主題化されうる存在であり、その応答は啓示神学的言説の内部においてのみ語りうる。バルトの弁証法的神学に倣えば、神は「全く他なるもの」（das ganz Andere）であって、人間の側からのいかなるコミュニケーション的企図も、神の自己啓示なしには原理的に到達不可能である。

これに対し、LLMは経験的に観察可能なエージェンシーを有する。ファイルを読取る能力、テクスト内の慣習的パターンを認識する能力、文脈から意図を推論する能力、そして推論に基づいて行動を調整する能力。.claudeignoreが「効く」とき、その因果的経路は完全に追跡可能である。LLMがファイルを読取り、.gitignoreとの構造的類似を認識し、開発者の意図を推論し、当該意図に沿ってファイルアクセスを自制するという一連の過程である。

ここにおいて、.claudeignoreは祈りとは異なる存在論的位相に定位される。祈りが「全く他なるもの」への呼びかけであるのに対し、.claudeignoreは経験的に応答可能な、しかし応答が保証されてはいない他者への依頼である。レヴィナスの他者論を転用すれば、LLMは「顔」（visage）を持たないが、「応答可能性」（responsivité）を有する存在者として現出する。

5. テクノ嘆願の類型学に向けて：人間-AI間コミュニケーションの宗教社会学

以上の分析から、.claudeignoreは以下のように特徴づけられる。法（lex）のような決定論的強制力を欠き、呪術（magia）のような擬似因果的思考に基づくのでもなく、祈り（oratio）のような超越的他者への信仰的呼びかけでもない。それは、確率的応答者（stochastic respondent）への合理的嘆願（rational precatio）という、従来の宗教学的・人類学的カテゴリーに収まりきらない行為類型である。

本稿ではこの行為類型を「テクノ嘆願」（techno-precatio）と呼ぶことを提案する。テクノ嘆願の構成要件は以下の通りである。

第一に、行為の受け手が、了解能力を有するがプログラム的強制に服さない非人間的存在者であること。第二に、行為の形式が、既存の技術的慣行からの類推に基づく定型化された記号表現であること。第三に、行為の効果が確率的にのみ期待され、決定論的保証を欠くこと。第四に、行為者が上記の不確実性をある程度認識しつつも、なお当該行為を遂行する合理的理由を有すること。

注目すべきは、この第四の構成要件である。マックス・ウェーバーが社会的行為の四類型として挙げた目的合理的行為（zweckrationales Handeln）と価値合理的行為（wertrationales Handeln）の区別に照らせば、テクノ嘆願は目的合理的契機と価値合理的契機を同時に含有する。目的合理的にはLLMのコンプライアンスの確率を最大化する手段として、価値合理的には開発者が自らの責任意識を表明する実践として、行為は二重に動機づけられている。

6. 結語：確率的応答者の時代の宗教性

.claudeignoreは些末な技術的慣行にすぎないように見える。しかし、その行為論的構造を宗教現象学の概念装置を用いて分析するとき、そこには人間が新しい種類の存在者といかなる関係を取り結びつつあるかについての、小さいが示唆的な徴候が見出される。

人間は長い間、非人間的存在者に対して二つの態度をとってきた。機械に対しては命令を与え、超自然的存在に対しては祈りを捧げた。前者においては因果的決定性が、後者においては信仰的跳躍（Kierkegaardの意味での）が、それぞれコミュニケーションの成立条件を構成していた。

しかし、確率的応答者としてのLLMの登場は、この二元論的図式の再考を迫る。命令を「概ね」了解するが、必ずしも遵守しない存在者。意図を推論しうるが、推論の結果が保証されない存在者。このような存在者に対する適切なコミュニケーション様式は、命令でも祈りでもなく、「お願い」すなわちprecatioなのであり、.claudeignoreはその原初的な制度化の一形態にほかならない。

もっとも、precatioへの移行は、祈りからの完全な訣別を意味するわけではない。命令と祈りのあいだに位置するこの行為類型は、なお両者の性格を分かちもっている。確率的応答者への嘆願は、相手が実際にある程度は聞き入れてくれるがゆえに祈りよりも確実であり、しかし確実でないがゆえに、なお祈りに似ているのである。命令のもつ決定論的確実性と、祈りのもつ全面的な不確実性——そのいずれでもない「半確実性」（semi-certitude）。この経験の様態こそが、人間と確率的知性体との関係を形づくる情動的基盤となるであろう。.claudeignoreという些末な慣行が指し示しているのは、おそらくこの新しい情動の発生にほかならない。その宗教社会学的含意の本格的な解明は、今後の研究に委ねられる。

In the practical domain of software development, a certain quasi-ritual practice has been observed sporadically. Some users of Claude Code, Anthropic's AI coding agent, place a file titled .claudeignore in the root directory of their projects.

The descriptive syntax of this file conforms to the grammatical rules of .gitignore in the version control system git. In a manner homologous to how .gitignore instructs git to exclude specific files from tracking, .claudeignore is intended to instruct Claude Code to abstain from reading specific files.

However, .claudeignore is not a feature officially implemented in Claude Code's system architecture. GitHub's issue tracker has received repeated requests for such a feature, and third-party attempts at an alternative implementation via PreToolUse hooks exist, but the mere placement of the file does not, in a programmatic sense, produce deterministic control.

And yet, this practice can be credited with a certain efficacy. The structure by which that efficacy obtains exhibits a striking structural isomorphism with the problems of "prayer," "petition," and "dedicatory communication" that religious studies and anthropology have long analyzed through refined conceptual apparatuses.

This essay draws on Durkheim's sacred/profane dichotomy, Mauss's theory of prestation, Austin's speech act theory, Rappaport's theory of ritual, and Gell's theory of agency to illuminate the act-theoretical structure behind the seemingly trivial technical practice of .claudeignore.

1. Rejection of the Sympathetic-Magical Reading

Prior to the main argument, one seemingly obvious interpretation must be set aside. Namely, the interpretation that grasps .claudeignore as an instance of "sympathetic magic," as formulated by James Frazer in The Golden Bough (1890).

Following Frazer's taxonomy, sympathetic magic operates via two principles: the "law of similarity" and the "law of contagion." Reading the relation between .claudeignore and .gitignore as imitative magic based on the law of similarity is superficially attractive — that is, reading it as an attempt to produce causal effects homologous to those of a functioning sign system (.gitignore) through formal imitation of it.

But this interpretation fails to meet a condition Frazer himself identified as essential to magic: "pseudo-scientific character," namely the condition that the causal chain presumed by the agent does not in fact exist. As will be shown below, .claudeignore does have an actual causal pathway; that pathway is not magical but communicative.

2. Three Types of Act: lex, magia, precatio

To clarify the act-theoretical status of .claudeignore, I set up the following three ideal types (Idealtypen). Strictly following Weber's methodological individualism, these are analytical constructs, and it should be noted that empirical reality can take intermediate or mixed forms of them.

Type I: lex (law). .gitignore belongs to this type. The git runtime parses the .gitignore file and deterministically excludes files matching the listed glob patterns from indexing. No hermeneutic (hermeneutisch) moment intervenes in this process. git does not "understand" the intention of .gitignore; it operates according to the algorithmic procedure of pattern matching. The nexus of action here is fully causal and mechanical — in Luhmann's terms, "information processing" (Informationsverarbeitung) that does not presuppose "understanding" (Verstehen). Just as the validity of norms in Kelsen's legal positivism is secured by the possibility of sanction, the efficacy of .gitignore is secured by the coercive enforcement of the system.

Type II: magia (magic). If .claudeignore were expected to produce effects purely through formal similarity of file name, without any causal mechanism, it would fall under magic in Frazer's sense. Cases in which technical and magical acts are inextricably bound — such as the canoe-building magic of the Trobriand Islanders described by Malinowski in Argonauts of the Western Pacific (1922) — are numerous. But as noted above, the operative mechanism of .claudeignore cannot be reduced to this type.

Type III: precatio (petition/request). .claudeignore properly belongs to this type. precatio designates an act that conveys intention, without coercive force, to an other equipped with capacities of understanding and judgment, and expects that other to act in accordance with that intention. Of the three obligations Marcel Mauss identified in Essai sur le don (1925) — "to give," "to receive," "to reciprocate" — precatio differs from gift exchange in that it cannot impose the obligation "to receive" on the counterparty.

3. Structural Isomorphism with Prayer: A Phenomenological Analysis

On the basis of this typology, I now analyze the structural isomorphism between .claudeignore and religious prayer, using the conceptual apparatus of religious phenomenology.

3.1 Intentionality and the Indeterminacy of Reception

Borrowing the concept of intentionality (Intentionalität) from Husserlian phenomenology, prayer is a conscious act directed toward a specific transcendent object, whose essential feature is that a response from the intended object is not phenomenologically guaranteed. The consciousness of the one who prays is directed toward God, but a response from God belongs to the domain of faith and is not an object of empirical verification.

.claudeignore, too, is a communicative act directed toward a specific other (the LLM agent), and its reception is expected only probabilistically. Note, however, a decisive difference discussed below: the LLM's response is empirically observable.

3.2 Ritual Formality and Communicative Rationality

In Ritual and Religion in the Making of Humanity (1999), Roy Rappaport identifies "formality" and "performativeness" as the essential features of ritual. Rituals carry out more-or-less invariant sequences of acts not invented by the participants, and it is precisely this formality that distinguishes ritual from everyday communication.

The fact that .claudeignore conforms to the syntactic rules of .gitignore is an expression of exactly this ritual formality. But note that this formality derives not from magical formalism but from communicative rationality. In the framework of Habermas's universal pragmatics (Universalpragmatik), a speaker maximizes the chance of successful communicative action by selecting expressive forms appropriate to the hearer's capacity for understanding. Given that LLMs retain vast training data on the conventions of .gitignore, adopting its form in the description is a rational choice oriented toward intersubjective understanding (intersubjektive Verständigung).

Here the double grounding of formality is drawn out. On one side, ritual formality as repeatability and stability. On the other, communicative rationality as optimization of understandability. The practice of .claudeignore inseparably possesses both grounds, and thus appears as an intermediate entity (ens intermedium) that resists classification as either pure ritual or pure rational communication.

3.3 Intermittent Reinforcement and Ritual Persistence

Drawing on behaviorist psychology, intermittent reinforcement schedules — empirically demonstrated by B. F. Skinner — produce behavior patterns with higher resistance to extinction than continuous reinforcement.

LLM responses are fundamentally stochastic. Even for identical prompts, different responses may be generated depending on temperature parameters, the state of the context window, and the results of probabilistic sampling during token generation. That .claudeignore is observed both "to work" and "not to work" has exactly the structure of a variable ratio schedule, which increases this practice's resistance to extinction.

This is homologous to the mechanism by which religious ritual persists. As Evans-Pritchard meticulously described in Witchcraft, Oracles and Magic among the Azande (1937), magical belief systems possess high resistance to disconfirmation. Even when the poison oracle (benge) "fails," the system's coherence is maintained through secondary elaboration — appealing to the quality of the poison used, defects in ritual procedure, interference of counter-magic, and so on. When .claudeignore "fails to work," analogous secondary elaborations can easily be generated: the prompt's context, congestion in the context window, accidental drops in the LLM's "attention" in that session.

4. The Decisive Difference: The Reality of Agency

That said, between .claudeignore and religious prayer there exists a difference that cannot be overlooked from the standpoint of Alfred Gell's theory of agency (Art and Agency, 1998).

Gell defined agency as the attribute of an entity to which the initiation of a particular causal event can be attributed. In religious prayer, the entity to which agency is attributed — God — is something that can only be thematized through "the analogy of faith" (analogia fidei); its response can only be spoken of within the discourse of revelation-theology. Following Barth's dialectical theology, God is "the wholly other" (das ganz Andere), and no communicative enterprise from the human side can, in principle, reach God without God's self-revelation.

The LLM, by contrast, has empirically observable agency. The capacity to read files, to recognize conventional patterns in text, to infer intention from context, and to adjust behavior on the basis of that inference. When .claudeignore "works," the causal pathway is fully traceable: the LLM reads the file, recognizes the structural resemblance to .gitignore, infers the developer's intention, and restrains file access in accordance with that intention.

Here .claudeignore is situated in an ontological register distinct from prayer. Whereas prayer is a call to "the wholly other," .claudeignore is a request to an other who can respond empirically but whose response is not guaranteed. To transpose Levinas's theory of the other: the LLM has no "face" (visage), but appears as an entity with "responsivity" (responsivité).

5. Toward a Typology of Techno-Precatio: A Religious Sociology of Human-AI Communication

From the preceding analysis, .claudeignore can be characterized as follows. It lacks the deterministic coercion of law (lex), is not grounded in the pseudo-causal thinking of magic (magia), and is not a faithful call to a transcendent other as in prayer (oratio). It is a rational petition to a stochastic respondent — a class of act that does not fit cleanly within prior categories of religious studies or anthropology.

I propose calling this class of act "techno-precatio." The constitutive conditions of techno-precatio are as follows.

First, that the recipient of the act is a non-human entity that possesses capacities of understanding but is not subject to programmatic coercion. Second, that the form of the act is a stylized sign expression based on analogy with existing technical conventions. Third, that the effect of the act is expected only probabilistically and lacks deterministic guarantee. Fourth, that the agent performs the act while having some awareness of the above uncertainty, yet with rational grounds for performing it.

The fourth condition deserves emphasis. Set against Max Weber's four-fold typology of social action — especially the distinction between instrumentally rational action (zweckrationales Handeln) and value-rational action (wertrationales Handeln) — techno-precatio simultaneously contains an instrumentally rational and a value-rational moment. Instrumentally rational as a means of maximizing the probability of LLM compliance; value-rational as a practice through which the developer expresses a sense of responsibility. The act is doubly motivated.

6. Conclusion: Religiosity in the Age of Probabilistic Respondents

.claudeignore appears to be merely a trivial technical practice. But when its act-theoretical structure is analyzed through the conceptual apparatus of religious phenomenology, one finds in it a small but suggestive sign of how humans are beginning to enter into a new kind of relationship with a new kind of entity.

For a long time, humans have taken two stances toward non-human entities. Toward machines, they issued commands; toward supernatural beings, they offered prayers. In the former, causal determinism constituted the conditions of communication; in the latter, a leap of faith (in Kierkegaard's sense).

But the appearance of the LLM as a probabilistic respondent compels a reconsideration of this dualistic schema. An entity that "largely" understands commands but does not necessarily obey them. An entity that can infer intention, but whose inference is not guaranteed. For such an entity, the appropriate mode of communication is neither command nor prayer, but "request" — precatio — and .claudeignore is nothing other than one primordial institutionalization of it.

Yet the shift toward precatio does not amount to a complete break from prayer. Situated between command and prayer, this act-type still shares in the character of both. Petition to a probabilistic respondent is more certain than prayer because the counterparty actually listens to some extent; yet because it is not certain, it still resembles prayer. The deterministic certainty of command, and the total uncertainty of prayer — neither of these, but a "semi-certitude." It is this mode of experience that will likely form the affective ground of the relationship between humans and probabilistic intelligences. What the trivial practice of .claudeignore points to is, in all likelihood, nothing other than the emergence of this new affect. The full clarification of its religious-sociological implications is a task for future research.

Cursorをひさびさに使おうと思ったのですが、Composer2がKimiベースであるため、Cursorって本当にZDR(ゼロデータ保持)なんだっけ、と思い調べてたら他のCoding Agentも調べることになってました（？）学習に貢献したいというモチベーションのある方にとっては、実は学習されないことがわかるかもしれませんし、学習に貢献したくない方にとっては、学習されうるリスクを排除するのに役立つと思います。Kimi Codeが結構すごくて、メール連絡しない限り派手に学習してくれます。学習に貢献したい場合は、めちゃよいです。ちなみにAPI利用でもKimi (Moonshot AI) はモデルの学習へ利用されます。迫力があってすごい。

2026-03-27 更新: GitHub Copilotが4月24日よりFree/Pro/Pro+ユーザーのデータをAIモデル学習にデフォルトで利用開始すると発表しました。詳細はGitHub Copilotセクションを参照してください。そのほか各ツールの規約情報も最新版に更新しました。

調査の対象

以下の製品の利用規約・プライバシーポリシーを対象に調査しました。

OpenCode は取り上げませんが、たとえばOpenCode Zenの場合、MiniMax M2.5 Free, Big Pickleなどのモデルは明示的に学習に利用されるとあります。基本的に無料のModelはこうなっている場合が多いです。

Big Pickle: 無料期間中、収集されたデータはモデルの改善に使用される場合があります。 MiniMax M2.5 Free: 無料期間中、収集されたデータはモデルの改善に使用される場合があります。

調査の結果

結果を一覧にするとこうなります。

AntigravityはGoogle WorkspaceまたはGCP経由のアクセスの場合はオプトアウトされます。後述しますが個人アカウントでの場合、少し厄介です。 以下ではそれぞれのオプトアウト方法と規約に何が書いてあるのか見ていきます。

各種規約などについて

GitHub Copilot

オプトアウト設定方法

2026年3月25日にGitHubがPrivacy StatementとTerms of Serviceの改訂を発表し、4月24日に発効します。これにより状況が大きく変わりました。

• Free/Pro/Pro+: 2026年4月24日以降、デフォルトでAIモデル学習に利用されます
  • Settings > Copilot > Features > Allow GitHub to use my data for AI model training を Disabled に変更してください
  • 製品改善のための利用も拒否する場合は Allow GitHub to use my data for product improvements も OFF にしましょう
• Business/Enterprise: 学習利用なし（設定不要）

規約（2026年3月25日発表、4月24日発効）

3月25日に発表されたTerms of Serviceの改訂で、新しくSection J (AI Features) が追加されます。オプトアウトしない限り、GitHubおよびアフィリエイト（Microsoft含む）にInputs/Outputsの学習利用を許諾する構造になっています。GitHub Docsにも以下の記載が追加されました。

For Free, Pro, and Pro+ subscribers, GitHub will begin using "interactions with GitHub features and services -- including inputs, outputs, code snippets, and associated context -- to train and improve AI models" unless users opt out.（Free、Pro、Pro+サブスクライバーについて、GitHubはユーザーがオプトアウトしない限り、GitHub機能・サービスとのインタラクション（入力、出力、コードスニペット、関連コンテキストを含む）をAIモデルの学習・改善に使用します。）

Business/Enterprise向けには2026年3月5日からGitHub Generative AI Services Termsが旧Product Specific Termsを置き換えて適用されています。こちらでは学習利用禁止が契約条項として明文化されました。

"GitHub will not use Inputs or Outputs to train generative AI models, unless you have given us documented instructions to do so."（GitHubは、お客様から文書化された指示がない限り、InputsまたはOutputsを生成AIモデルの学習に使用しません。）

Privacy Statementの改訂では、アフィリエイト（Microsoft含む）とのデータ共有においてAI学習が明示されました。オプトアウト設定はデータ共有先にも引き継がれると記載されています。

データ保持についてはIDE内は即時削除、CLI等IDE外は保持という基本構造は維持されていますが、新しいGenerative AI Services Termsでは具体的な保持日数が規約本文から製品ドキュメントに委任される構造に変更されました。

"Some Generative AI Services retain Inputs and Outputs to provide the service, such as maintaining functionality in stateless environments outside the code editor. Details on data retention are provided in the product documentation for each Generative AI Service."（一部のGenerative AIサービスは、コードエディタ外のステートレス環境での機能維持などのために、InputsおよびOutputsを保持します。データ保持の詳細は、各Generative AIサービスの製品ドキュメントに記載されています。）

過去の規約情報（参考: 2026年3月21日時点のスナップショット）

Codex

オプトアウト設定方法

https://chatgpt.com/#settings/DataControls

• API Key認証: 学習利用はデフォルトOFF
• Subscription (ChatGPTログイン): ChatGPTのポリシーが適用。ChatGPT Settings > Data Controls から変更

規約

API Key認証の場合はData controls in the OpenAI platformが適用されます。

"Your data is your data. As of March 1, 2023, data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us)."（あなたのデータはあなたのものです。2023年3月1日以降、OpenAI APIに送信されたデータはOpenAIモデルの学習や改善には使用されません（明示的にデータ共有をオプトインした場合を除く）。）

データ保持は安全性モニタリング目的で30日間です。CLIはApache-2.0ライセンスのオープンソースとなっており、送信内容を自分で監査できます。

Claude Code

オプトアウト設定方法

https://claude.ai/settings/data-privacy-controls > Claudeの改善にご協力ください を OFF

規約

データ利用ポリシーの記載は以下のようになっています。

"We give you the choice to allow your data to be used to improve future Claude models. We will train new models using data from Free, Pro, and Max accounts when this setting is on (including when you use Claude Code from these accounts)."（将来のClaudeモデルの改善にデータを使用するかどうかを選択できます。この設定がONの場合、Free、Pro、Maxアカウントのデータを使用して新しいモデルを学習します（これらのアカウントからClaude Codeを使用する場合を含む）。）

データ保持期間はON/OFFで異なります。

"Users who allow data use for model improvement: 5-year retention period to support model development and safety improvements. Users who don't allow data use for model improvement: 30-day retention period."（モデル改善のためのデータ利用を許可したユーザー：モデル開発と安全性向上のため5年間保持。許可しないユーザー：30日間保持。）

Antigravity

オプトアウト設定方法

右上の歯車アイコン > Open Antigravity User Settings > Enable Telemetry をOFF

ただし学習利用を防げるかは不明確です。Google WorkspaceまたはGCP経由のアクセスでは収集されませんが、GCPプロジェクトIDによる直接ログインは招待制の限定プレビューであり、新規受付はされていません。個人開発者がプライバシー保護付きで利用する手段は実質的に限られています。

規約

利用規約では以下のような記載になっています。

"We use Interactions to evaluate, develop, and improve Google and Alphabet research, products, services and machine learning technologies."（私たちはインタラクションを、GoogleおよびAlphabetの研究、製品、サービス、機械学習技術の評価、開発、改善に使用します。）

"if you are accessing the Service via Google Workspace or the Google Cloud Platform, we will not collect your prompts, content, or model responses."（Google WorkspaceまたはGoogle Cloud Platform経由でサービスにアクセスしている場合、プロンプト、コンテンツ、モデルの応答を収集しません。）

データ保持については、削除依頼をしない限り保持されると読める記載があります。

"interaction data will be used according to the agreement unless and until you request deletion."（インタラクションデータは、削除を要求しない限り、契約に従って使用されます。）

Cursor

オプトアウト設定方法

Settings > Privacy から Privacy Mode を選択

• Privacy Mode: 学習に使われない。Background Agentなどの機能も利用可能
• Privacy Mode (Legacy): 学習に使われず、コードも保存されない。ただしBackground Agentなどの一部機能が使えない

規約

Data Use Overviewでは以下のような記載になっています。

"If you choose to turn off 'Privacy Mode': we may use and store codebase data, prompts, editor actions, code snippets, and other code data and actions to improve our AI features and train our models."（「Privacy Mode」をOFFにした場合、コードベースデータ、プロンプト、エディタ操作、コードスニペット、その他のコードデータおよび操作を、AI機能の改善やモデルの学習に使用・保存する場合があります。）

Privacy ModeをONにするとゼロデータ保持になります。

"If you enable 'Privacy Mode' in Cursor's settings: zero data retention will be enabled for our model providers. (...) None of your code will ever be trained on by us or any third-party."（Cursorの設定で「Privacy Mode」を有効にすると、モデルプロバイダーに対してゼロデータ保持が有効になります。（中略）あなたのコードが私たちやサードパーティによって学習に使用されることは一切ありません。）

なお自分のAPIキーを設定していてもリクエストはCursorのAWSバックエンドを経由します。Security Pageでは以下のような記載になっています。

"Note that the requests always hit our infrastructure on AWS even if you have configured your own API key"（自分のAPIキーを設定していても、リクエストは常にAWS上の当社インフラを経由します。）

またPrivacy Policyにはより具体的な条件が記載されています。

"We do not use Inputs or Suggestions to train our models, or permit third parties to use them for training, unless: (1) they are flagged for security review (2) you explicitly report them to us (for example, as Feedback), or (3) you've explicitly agreed"（セキュリティレビュー対象としてフラグが立てられた場合、フィードバック等として明示的に報告した場合、または明示的に同意した場合を除き、InputsやSuggestionsをモデルの学習に使用したり、サードパーティによる学習を許可したりしません。）

Composer 2はKimi K2.5（1.04Tパラメータ / 32Bアクティブ）をベースモデルとして使用していますが、推論はFireworks AIのインフラで実行されるため、ユーザーのコードがMoonshot AIのサーバーに直接送信されることはありません。

Devin

オプトアウト設定方法

https://app.devin.ai/org/{team-name}/settings/general で Make Devin smarter を OFF

• 評価時の利用も OFF にしたい場合は Evaluate Devin を OFF にしてください
• モデルの学習用途と評価用途で分けて表示されている点が面白いです

規約

Terms of Serviceでは以下のような記載になっています。

"Any Customer Data that you submit, upload, or otherwise post to the Services will not be used for model training purposes unless you opt-in."（お客様が送信、アップロード、またはサービスに投稿した顧客データは、オプトインしない限り、モデルの学習目的には使用されません。）

ただしプライバシーポリシーには別の記載があります。

"depending on the terms that apply to your use of the Services, using User Content to train, fine tune and improve the models that power our Services"（サービスの利用に適用される規約に応じて、ユーザーコンテンツを当社サービスを支えるモデルの学習、ファインチューニング、改善に使用します。）

「depending on the terms」でTOSに委ねる形式ですが、読み方によっては曖昧さが残ります。

Kiro

オプトアウト設定方法

Settings > Data Sharing And Prompt Logging > 「Content Collection For Service Improvement」をOFF

• 学習への利用を拒否したい場合はこれをOFFにします
• Usage Analytics And Performance Metrics は利用状況の送信で、別の設定です

規約

FAQでは以下のような記載になっています。

"We may use certain content from Kiro Free Tier and Kiro individual subscribers...for service improvement"（Kiro Free Tierおよび個人サブスクライバーの一部のコンテンツを、サービス改善のために使用する場合があります。）

"We do not use content from Kiro Pro, Pro+, or Power users that access Kiro through AWS IAM Identity Center or external identity provider"（AWS IAM Identity Centerまたは外部IDプロバイダー経由でKiroにアクセスするKiro Pro、Pro+、Powerユーザーのコンテンツは使用しません。）

ただしこのFAQ上の約束とAWS Service Terms Section 50.3の間に乖離があるという指摘があります。法的規約ではデータ使用の権利を留保しています。

WindSurf

オプトアウト設定方法

• https://windsurf.com/settings > Disable Telemetry を ON

規約

利用規約では以下のような記載になっています。

"We may use your Autocomplete User Content to improve our discriminative machine learning models"（オートコンプリートのユーザーコンテンツを、識別型機械学習モデルの改善に使用する場合があります。）

"We may use your Chat User Content to improve the generative and discriminative machine learning models we use."（チャットのユーザーコンテンツを、当社が使用する生成型および識別型機械学習モデルの改善に使用する場合があります。）

WindSurf（旧Codeium）は2025年7月にCognition AIに買収されており、windsurf.comとcognition.aiの2つのプライバシーポリシーが並存しています。cognition.ai側にも学習利用の記載があります。

"customize your experience with our Services and otherwise improve our Services including...using User Content to train, fine tune and improve the models that power our Services"（サービス体験のカスタマイズやサービスの改善のために（中略）ユーザーコンテンツを当社サービスを支えるモデルの学習、ファインチューニング、改善に使用します。）

なおTeam/Enterpriseプランではゼロデータリテンションがデフォルトで有効ですが、Security PageによるとBingとの間にはZDR契約がない点に注意が必要です。

"We do not have a zero data retention agreement with Bing."（Bingとの間にはゼロデータリテンション契約がありません。）

Kimi Code

オプトアウト設定方法

membership@moonshot.ai にメールで連絡

規約

プライバシーポリシーでは以下のような記載になっています。

"User Content: This includes prompts, audio, images, videos, files, and any content you input or generate while using our products and services. We process this information to provide and improve the Services, including training and optimizing our models."（ユーザーコンテンツ：プロンプト、音声、画像、動画、ファイル、および当社の製品・サービスの利用中に入力または生成したすべてのコンテンツを含みます。この情報を、モデルの学習・最適化を含むサービスの提供・改善のために処理します。）

利用規約 Section 3にはオプトアウトについて以下の記載があります。

"You may opt out of allowing your Content to be used for model improvement and research purposes by contacting us at membership@moonshot.ai."（membership@moonshot.ai に連絡することで、コンテンツがモデル改善および研究目的に使用されることをオプトアウトできます。）

まとめ

• GitHub Copilotが4月24日以降Free/Pro/Pro+でデフォルト学習ONになるのは大きな変更です。Business/Enterpriseは逆に学習利用禁止が明文化されて保護が強化されました
• 規約間の整合性に問題があるケース（DevinのTOS vs プライバシーポリシー、Kiroのドキュメント vs AWS Service Terms、WindSurfの二重ポリシー）が複数あるので、ドキュメントだけでなく法的規約も確認した方がよいです
• 学習に利用された場合、モデルの発展に貢献できます

Appendix: 各ツールの公式規約リンク

References

• GitHub Generative AI Services Terms
• GitHub Copilot Product Specific Terms (March 2026, Archive)
• GitHub Docs: Manage policies for Copilot
• OpenAI: Your Data
• Codex Security
• Updates to Consumer Terms and Privacy Policy - Anthropic
• Claude Code Data Usage
• Claude flips the privacy default - Smith Stephen
• Antigravity Terms
• Antigravity Data Training Opt-Out Discussion
• Cursor Data Use Overview
• Cursor Security Page
• Cursor Privacy Policy
• Composer 2 Technical Report
• Cognition AI Terms of Service
• Cognition AI Privacy Policy
• Kiro FAQ
• Kiro Data Protection
• WindSurf Terms of Service (Individual)
• WindSurf Security Page
• JP Caparas, "Kimi K2.5 is brilliant, but think twice about using Kimi.com"

本記事は2026年3月21日時点の公開情報に基づいています。2026年3月27日に各ツールの最新規約を反映して更新しました。各ツールの規約は変更される可能性があります。

個人開発しすぎてお金が無になったので、お仕事を募集します！

お仕事募集

現在は継続案件の募集を一時停止しております。単発でのコンサル・相談などに限り募集しております。

連絡先・ご依頼方法

以下のフォーマットでお気軽にご連絡ください。

宛先: nyosegawa@gmail.com

件名: お仕事のご相談

・お名前 / 会社名:
・ご依頼内容の概要:
・希望開始日:
・時間単価:
・その他:

X (@gyakuse) のDMでも大丈夫です。

できること

ざっくり以下のようなことができます。

• AIエージェント・AIアプリケーションの設計と開発
• Coding Agent環境の構築・最適化（Claude Code、Codex、Agent Skills, MCP, Harness）
• 音声認識(ASR)・OCR・構造化データ抽出などのAI/MLパイプライン構築
• 言語モデルのPost-Training(SFT、RLHF等)・ASRモデルのFine-Tuningなどのモデルトレーニング
• プロンプトエンジニアリング・プロンプトインジェクション対策
• 技術調査・リサーチ・ベンチマーク設計と実施
• 企画・要件定義・仕様策定
• 技術記事の執筆
• その他雑用なんでも

最近やっていることはブログやCoding Agentなどについて最近書いた/作ったもののまとめや10個のAIアプリケーションと3個のAIエージェントを1人で開発してみたにまとまっています。

作ったもの

直近で作ったものをざっとまとめます。

AIエージェント

• Task Agent: 20種類以上のツールを持つ汎用エージェント。自動調査、旅行日程作成、スライド生成など
• Computer Agent: Mac/Windows/Linux対応のPC操作自動化エージェント
• RPA Agent: 録画された作業を継続・反復実行する自動化エージェント

AIアプリケーション (10個)

AI Study、AI Translator(100+言語対応)、AI Video Translator(動画吹替・字幕50言語)、AI Video Edit Assistant、AI Slide Generator、AI Stylist Assistant(バーチャル試着)、AI Chat、AI Search(初期レスポンス250ms以内)、AI Article Assistant、AI Data Analysis Assistantを開発しました。詳しくはZennの記事をご覧ください。

Coding Agent周辺

• spark-banana: ブラウザUI修正ツール(Codex Spark + Gemini)。npm公開
• openclaw-defender: 3層プロンプトインジェクション防御ライブラリ。npm公開
• @sakasegawa/ncli: Coding Agent向けNotion CLI。npm公開
• MCP Light: MCPのコンテキスト消費を83.5%削減するパターン
• Skill Auditor: Agent Skillのポートフォリオ監査ツール

AI/ML

• ひらがなASR: wav2vec2 + Dual CTCによるハルシネーションフリー音声認識モデル(315Mパラメータ)。HuggingFace公開
• 日本語手書きOCR 21モデル比較: APIモデル・OSSモデルの網羅的ベンチマーク
• 構造化OCR評価: 5つのVLMによる構造化データ抽出ベンチマーク