Litmus — 話題のニュースを、深く読み解く。 RSS
AI

答えを教えないAIデバッグツール、公開半日で仕組みが変わった

バグを貼ってもAIが答えを返さず、質問だけを返す「Nietzschian Debugger」。開発者の返答から心理状態を読み、問い方を自動で変える設計に、公開から半日足らずで書き変わっていた。

プログラマーがコードの並んだ画面を見ながら、腑に落ちない表情で考え込んでいる

イメージ写真 記事の内容を撮影したものではありません。Photo by cottonbro studio on Pexels

この記事には Amazon アソシエイトのリンクを含みます。

「このエラー、直して」とAIに貼り付けて、出てきた修正をそのまま当てはめて動くようにする。今のコーディングでは珍しくない光景だ。動けば終わりで、なぜ直ったのかを聞かれても答えられない人は多いはずだ。

そこへ、バグを直さないデバッグツールが公開されて話題になった。「Nietzschian Debugger」というCLIツールで、バグの内容を入力すると、AIは答えを返さず質問だけを返してくる。開発者の返答から「混乱している」「思い込みに逃げている」「心が折れかけている」のどれかを読み取り、問いの角度を変えながら、最後まで答えを渡さない。

2026年10月27日にGitHubで話題になったこのツールを調べていて、妙なことに気づいた。公開から半日足らずの間に、肝心の「モードの切り替え方」そのものが書き変わっていたのだ。このツールは何をしてくれるのか。3つのモードは何を切り替えているのか。そして、その半日に何が起きたのか。

答えずに問い返す仕組み

このツールは何をしてくれるのか。使い方は単純だ。

  1. pip install nietzschian-debugger で導入する
  2. nietzschian debug "バグの内容" と打ち込んで対話を始める

公式READMEに載っている例を見ると、流れがよく分かる。開発者は「ログイン画面が403エラーを返すが、先週より前に登録したユーザーだけで、新規登録者は問題ない」と入力する。ツールは答えを示さず、「登録が先週より前のユーザーと後のユーザーで、レコード自体に何の違いがあるか」と問い返す。開発者は「同じコードパスのはず」と思い込んでいたことに気づき、実際にレコードを見比べる。すると、古いアカウントだけが持つフィールドが見つかる。3回のやり取りで、開発者自身が「有効期限の仕様を変えたとき、既存のログイン状態を無効化し忘れていた」という原因にたどり着く。

READMEの冒頭にはこうある。「このツールはあなたのバグを直さない。あなたを直す」。AIに聞けば直るはずの場面で、あえて直させない設計だ。

この問い返し方には、公式に「3つのモード」があるとされている。何を切り替えているのか。

3つのモードの違い

現行の公式READMEは、3つのモードを次のように説明している。

開発者の状態モードすること
confused(自分が何を言いたいか分からない)socrates曖昧な言葉の定義を執拗に求め、検証できる主張が出るまで問い続ける
avoiding(思い込みに逃げている)nietzsche開発者が一番自信を持っている前提を突き、その根拠の薄さに気づかせる
defeated(心が折れかけている)zarathustraつまずきを成長の材料として捉え直し、投げ出させない

名前の並びから、初心者向け・標準・上級者向けという「厳しさの3段階」を想像しがちだが、表の軸は開発者の状態であって、習熟度ではない。README自身も「どのモードも手加減しない」と明記している。

ではこの3つは、誰がどうやって選ぶのか。

モードは誰が選ぶのか

このツールを紹介したGIGAZINEの記事を読むと、自分の経験年数に合わせてモードを選ぶツールに見える。ところが、現行の公式READMEを確認すると、説明がまるで違う。

  • GIGAZINEの紹介: 「初心者向けで穏やかな質問」「標準モードで厳しく追及」「経験豊富な開発者向けで容赦なく問い詰める」という、習熟度に応じた強度の違い
  • 現行の公式README: デフォルトは「adaptive」、つまり自動切り替え。開発者の返答に表れる持続的な兆候を読んで、ツール自身がモードを変える。--lens オプションで固定もできるが、それは基本の動き方ではない

READMEはこの自動切り替えの理由をこう書いている。「混乱している開発者は、自分がどんな状態にあるかを自己診断できない。だからツールの側が読み取る」。

開発者が自分の状態を申告する前提をやめ、会話の中身からツール側が読み取る方式にしていた、というのが今の設計だ。

この「自動で読む」という設計は、最初からこうだったのだろうか。

半日で変わった設計

npmのレジストリには、このツールの最初の公開版(0.1.0、2026年2月24日公開)の記録が残っている。そのREADMEを確認すると、現行版とはまったく違う設計だったと分かる。

旧版(npm 0.1.0、2026-02-24公開)現行版(PyPI 0.2.0〜0.4.0)
呼び方Intensity(強度)Lens(見方)
選び方--intensity で開発者が明示的に選ぶデフォルトは自動判定(adaptive)。固定も可
socratesの説明Warm, guiding, scaffolded questions。初心者向けconfused(混乱)な状態に効く問い方
nietzscheの説明Direct, confrontational。日常のデバッグで既定avoiding(回避)な状態に効く問い方
対応言語・実行環境Node.js(npm/npx配布)Python 3.10以上(pip配布)

旧版の socrates は「初心者向けの穏やかな質問」、nietzsche は「直接的で対決的、日常使いの既定」としていた。まさにGIGAZINEが紹介した通り、習熟度で選ぶ強度だった。

PyPIの公開履歴を見ると、Python版への書き直しは2026年10月27日16時14分(協定世界時)に始まった。日本時間では10月28日未明1時14分にあたる。そこから同日21時4分(日本時間同日朝6時4分)までの間に、0.2.0から0.4.0まで7回のバージョンが立て続けに公開されていた。GIGAZINEの記事が公開されたのは10月27日20時(日本時間)で、ちょうどこの書き直しの途中にあたる。

自分が読んでいたのは、設計思想そのものが切り替わる現場だったことになる。「どの強さで追及されるか」を選ぶツールから、「今どんな状態かをAIに読ませる」ツールへの切り替わりだ。

では、この「答えを教えない」という約束は、どこまで守られるのか。

答えない約束の限界

READMEは、答えを渡さない仕組みについてもう一段具体的に書いている。「すべての応答は質問の形を取る。答えを渡さないように作られていて、万一漏れたときに備えて、別のAI(model-judge)が各応答を二重にチェックする」。この仕組みには、次のような条件と限界がある。

  • この厳格さが最も強く働くのは、既定のClaudeを使ったときだとREADMEは明記している
  • OpenAIやGemini、ローカルで動くOllamaなど別のモデルにも切り替えられるが、小規模なモデルでは答えが漏れたり質問を重ねすぎたりしがちだという。内蔵のチェック機構も、それを一部しか捕まえられない
  • 「混乱している」「思い込みに逃げている」といった状態を、具体的にどんな発言から判定しているのかは、READMEにもCHANGELOGにも書かれていない。公開されているのは「持続的な兆候に基づいて切り替える」という方針までで、実際の判定はAIモデル自身の読み取りに委ねられている

最後に、今日から何を試せるのか。

今日から試せること

nietzschian demo を使うと、APIキーなしに一通りの流れを体験できる。実際に自分のバグで使うにはAnthropicなどのAPIキーが要るが、ローカルで動くOllamaやLM Studioを使えば無料でも動く。ただし前節で見た「答えを教えない」厳格さは、既定のClaudeを使ったときに最も強く働く設計だ。

まとめ

Nietzschian Debuggerは、バグの内容を入力しても答えを返さず、開発者自身の返答を読んで問いの角度を変え、最後まで答えを渡さないCLIツールだ。3つのモードは経験年数で選ぶ強度ではなく、「混乱」「回避」「心が折れかけ」という開発者の状態に応じてAIが自動で切り替える設計になっている。

この設計は、2026年2月の最初の公開時点では存在しなかった。GIGAZINEが紹介した10月27日夜は、Node.js版からPython版への書き直しがまさに進行していた数時間のただ中だった。記事の説明と現行の挙動が食い違う結果になっている。APIキーなしで試せる nietzschian demo から、まずは覗いてみるとよい。

この記事の先を読む本を探す

特定の本を勧めるものではありません。検索結果から、いまの版と目次を確かめて選んでください。

コメント

気づきや感想をどうぞ

記事への補足や、読んで考えたことをお寄せください。個人情報や、他の人を傷つける内容の投稿はお控えください。

コメントを読み込んでいます…

    ほかの記事

    最新の記事 →