こんにちは。@m_koshikawa です。

2026年3月26日、Claude Code v2.1.84がリリースされました。リリースノートの中にこんな一行を見つけて、思わず声が出ました。

Fixed native terminal cursor not tracking the text input caret, so IME composition (CJK input) now renders inline and screen readers can follow the input position

これ、自分が2026年1月にIssueを出して、フォークまで作って提案した修正だ。

実際の改善の様子は、@oikon48さんのポストで紹介されています。以前は画面の左下に飛んでいたIME変換候補が、入力位置にインライン表示されるようになっています。

この記事では、日常的に使っているツールの「使いにくさ」に気づき、OSSへのフィードバックを通じて改善に至るまでの経緯を書きます。「自分のような一個人の声が、本当に反映されるのか？」という疑問への、ひとつの実体験です。

何が起きていたのか — IME候補ウィンドウが左下に飛ぶ

Claude Codeで日本語を入力しようとすると、IMEの変換候補ウィンドウが入力位置ではなく、画面の左下に表示されていました。

修正前: IME候補がステータスバーの下に飛んでしまう

修正後: カーソル直下にIME候補が表示される

入力するたびに視線を画面の端まで飛ばさなければならず、認知負荷が高い。結果として、多くのCJK（日本語・中国語・韓国語）ユーザーが無意識のうちに英語入力を使うようになっていたのではないか — これは言語の好みの問題ではなく、UX摩擦による無意識の回避行動だと考えました。

原因を特定する

Claude CodeのTUI（ターミナルUI）は、Reactベースのターミナルフレームワーク Ink で構築されています。

問題の根本原因はInkの描画方式にありました。

Inkはターミナルの「実カーソル」を隠し、ANSIエスケープシーケンスで「視覚的なカーソル」を描画します。しかし、IMEはターミナルの実カーソル位置を参照して候補ウィンドウの表示位置を決めます。実カーソルが隠されたまま原点付近にいるため、候補ウィンドウが画面左下に飛んでいたのです。

Issueを出す — 問題報告だけでなく、動くコードで解決策を示す

2026年1月19日、anthropics/claude-code#19207 を起票しました。

ただのバグ報告にはしたくありませんでした。「ここが困っています」と「こうすれば直ります、動くコードがあります」では、受け手の対応速度がまるで違うからです。

やったことは3つです。

1. Inkをフォークして解決策を実装

Inkをフォークし、enableImeCursor オプションを実装しました。

仕組みはこうです。

実カーソルの位置を保存・復元するANSIエスケープシーケンスを使い、レンダリング後にカーソルを入力位置に戻す方式です。

2. Ink上流にもPRを提出

フォークの修正をClaude Code固有にとどめず、vadimdemedes/ink#851 として上流にもPRを出しました。InkベースのすべてのTUIアプリケーションが同じ恩恵を受けられるようにするためです。

3. 関連Issueを紐付けて根本原因を可視化

既に存在していた2つの関連Issueを見つけ、コメントで紐付けました。

#12332 — VSCodeターミナルで日本語IMEテキストが右端に飛ぶ（2025年11月起票）
#14814 — IDE統合ターミナルでIME入力がテキスト入力エリア外に表示される（2025年12月起票）

「これらはすべて同じ根本原因です」と指摘することで、個別のバグ報告が一つの構造的問題として認識されるようにしました。

修正が反映されるまで

Issue起票から修正完了まで、わずか18日。その間に複数の動きが並行して起きていました。

注目すべきは、自分のPR #851が直接マージされたわけではない点です。Ink上流では別の開発者（juniqlim）が useCursor() フックと Synchronized Update Mode という、より包括的なアプローチでPR #866を提出し、そちらがマージされました。PR #866のDescriptionには、自分のPR #851にインスパイアされたと記載されています。

Anthropic側もClaude Code内部で "declared cursor system" という独自の修正を行い、Issue #19207をクローズしました。

自分のコードがそのまま使われたわけではない。しかし、問題定義と解決の方向性が正しかったからこそ、複数のアプローチが同時に動き、18日で解決に至った。

エンジニアはツールの消費者ではない

この経験から感じたことを書きます。

エンジニアは日々、数え切れないツールを使います。エディタ、ターミナル、AIアシスタント。それらを「与えられたもの」として使い続けることもできます。

しかし、「使いにくいな」と感じた瞬間、そこには貢献のチャンスがあります。

大事なのは以下の3つだと考えています。

「問題報告」ではなく「解決策の提案」をする — 「困っています」だけでなく「こうすれば直ります」まで示す。メンテナーの負担を減らし、対応速度が上がる
点ではなく構造で伝える — 個別のバグ報告を紐付けて「これは同じ根本原因です」と示すことで、パッチではなく根本解決が進む
自分のコードが採用されなくても、問題提起に価値がある — PRがマージされなくても、正しい問題定義は他の開発者の解決を加速する

今回の修正は、日本語・中国語・韓国語を使うすべてのClaude Codeユーザーに影響します。自分一人の「使いにくいな」が、結果的に多くの人の体験を改善することにつながりました。

使っているツールに対して常に改善の視点を持つこと。そして、改善提案ができるなら実行すること。それがエンジニアとして世界に価値を届ける、最も直接的な方法のひとつだと思います。