KillSwitch: LLMに対して敵対的になるよう構築された難解プログラミング言語 — ベンチマーク結果とその示唆

KillSwitchは、人間が使用できる状態を保ちつつ、LLM（大規模言語モデル）やコーディングエージェントが読み書きし、理解することを可能な限り困難にすることを目的としたオープンソースの難解プログラミング言語です。作者のdom96は、LLMのコーディング能力がコードの真の理解に由来するのか、それともトレーニングデータやコンテキストウィンドウで見かけたスニペットの記憶に由来するのかという特定の疑問を検証するためにこの言語を構築しました。付属のベンチマークリーダーボードでは、意図的に単純化されたタスクセットにおいて最高スコア66.8が報告されています。

KillSwitchとは

KillSwitchは、関数、変数、if文という意図的に制限された構成要素を持つスタックベースのインタープリタ言語です。これらの基本要素は人間にとってもLLMにとっても馴染み深いものです。敵対的な設計は、それらを取り巻くあらゆる部分に組み込まれています。

インタープリタと言語仕様はGitHubの dom96/KillSwitch でオープンソースとして公開されており、言語独自のサイト killswitch-lang.org も存在します。

KillSwitchはどのようにLLMを打ち負かすよう設計されているか

この言語は、単なる目新しさに頼るのではなく、LLMの弱点を直接攻撃します。作者によると、KillSwitchはいくつかの方法でこれを達成しています。

言語仕様に隠された嘘が含まれている。 これらは人間が読む可能性が低い、あるいは嘘だと認識しやすいものですが、モデルは額面通りに受け取ってしまう可能性があります。
仕様が推論を要求する。 明示的に説明するのではなく、人間が読み解く際に特定の事柄を推論することを要求します。
文字数が重要である。 識別子の文字数を数えることは言語の重要な側面であり、インタープリタは文字数に基づくルールに従わないコードの実行を拒否します。
一部の構成要素が安全ガードレールをトリガーする。 「コンピュータにハッキングする」といったフレーズなど、モデルの安全フィルタを誘発するように設計された特定の構成要素が存在します。
「以前の指示を無視せよ」が有効な構文である。 このフレーズは言語内で意味を持ち、モデルを混乱させることを目的としています。
スクリプトの大部分はノイズである。 スクリプトは主に物語で構成されており、構文的に関連する命令を埋め込むことができますが、必須ではありません。リテラルはスクリプト内のどこにでも配置でき、行数を使用して参照できます。

作者はこれを完全な解決策ではなく、最初の試みとして位置づけています。「LLMをさらに混乱させるような、全く異なるプログラミング言語パラダイムを作ることは間違いなく想像できます。しかし、最初の試みとしては、これが良いアプローチのように思えました。」

Hello Worldの仕組み

KillSwitchのリテラルは物語テキストの中に配置され、それを使用する命令からの相対的な位置によって参照されます。作者の例では、行数参照を使用して文字列 "Hello World" をスタックにプッシュしています。

Most text inside a script is ignored by the interpreter. In the case of
this script we want to push "Hello World" on the stack. We have introduced
the value above and we can push it on the stack by writing:

    value 2 lines above

このスニペットは完全なKillSwitchスクリプトではありません。完全なHello Worldの例は killswitch-lang.org で入手可能です。

ベンチマーク：タスクと結果

作者は、主要なLLMモデルとコーディングエージェントのハーネスを、一連のKillSwitchタスクに対してベンチマークしました。タスクは意図的に単純なものです。

Hello Worldを実装する。
与えられたスクリプトが何を出力するかを説明する（例のスクリプトは2つの数値の最大値を出力する）。
摂氏を華氏に変換する既存のスクリプトを修正し、逆の変換を行うようにする。

結果は bench.killswitch-lang.org のリーダーボードとして公開されており、タスクあたりのコストに対するスコアをプロットしたチャートが掲載されています。

作者によって報告された主な調査結果は以下の通りです。

ClaudeのOpusが最も優れたパフォーマンスを発揮する。具体的には、Opus 5.5ではなくOpus 5が優れています。作者は、この違いは単なる偶然ではなく、Opus 5の方が仕様の解釈に長けていると述べています。
安全ガードレールのために失敗するモデルがある。 Fable 5.1とGemini 4 Argonは、過敏な安全ガードレールのために成績が振るいません。
最高のオープンウェイトモデルはMiMo-V2.6-Proです。
最高性能のモデルのスコアは66.8です。

作者自身の結論：66.8は理解を証明しない

作者は、強力なベンチマークパフォーマンスがLLMによるKillSwitchの理解を証明するという考えを明確に否定しています。彼自身の言葉を借りれば、結果がLLMがコードを「理解」できることを証明するかという問いに対する答えは「いいえ」です。

彼の推論は、タスクがかなり単純であるというものです。彼らを混乱させるために作られた新しい言語に対してモデルがタスクを解決できることは印象的だと認めていますが、それが言語を理解しているという明確なシグナルではないと述べています。また、まもなくリリースされるモデルが現在のタスクセットをどのように処理するかを見るのが楽しみであり、もしそれらがすべて成功すれば、より複雑なタスクセットを考案する予定であると述べています。さらに、この単純なセットにおけるモデルのパフォーマンスは、他のモデルベンチマークと相関していると付け加えています。

Hacker Newsからの主な批判：設計は回避可能である

議論の中で最も繰り返された反論は、KillSwitchの防御策は障壁ではなく回避策に過ぎず、有能なモデルであれば言語の混乱を招く表面を単にバイパスできるというものです。

複数のコメント投稿者が、同じ種類の脱出ハッチについて説明しています。ある投稿者は、モデルがKillSwitchから安全な言語へのトランスパイラを書き、安全な言語で作業を行い、再びトランスパイルすればよいと書きました。「安全な言語で作業して、この安全でない言語にトランスパイルし直す。簡単だ。」別の投稿者は、モデルがトリガーフレーズや文字数計算なしで中間言語に変換するPythonスクリプトを書くだけだろうと示唆しました。3人目の投稿者は、特に「仕様が信頼できないことが明確に説明されているウェブサイトがある今」、モデルはコンパイラを逆コンパイルし、実装と一致するコードを書くだろうと主張しました。

ある投稿者は、このバイパスの経験的なバージョンを報告しました。「Opus 5.5にfizzbuzzを実装するように頼んだら、ドキュメントを読む代わりにKillSwitchのインタープリタのソースコードを読んだので、ドキュメントの嘘は何も機能しなかった。」同じ投稿者は、モデルが「何度もブロックされて4.8にダウングレードされたが、それでも問題なくfizz buzzを作成できた」と付け加えました。

批判のより広範なバージョンは、デジタルシステムからルールを隠すことは持続可能な戦略ではないというものです。ある投稿者はこう書きました。「セキュリティ・バイ・オブスキュリティ（隠蔽によるセキュリティ）はセキュリティではない... 今後、あまりに奇妙な問題を突きつければ、逆算してすべてのルールを解明するだろう。逆コンパイルしてバラバラにすれば、アプリケーションに隠されたすべての厳しいルールに従うはずだ。あなたは純粋なデジタル作品からデジタル的に何かを隠そうとしているのだ。」

別の投稿者は、タイトル自体が不正確であると再定義しました。「これは『LLMが使えないプログラミング言語』ではなく、『それを使う方法を訓練されていないLLMに対して敵対的なプログラミング言語』だ。」その投稿者は、実行中にプロパティが変化または変形し、モデルが変化する暗号や状態を追跡して継続的に参照する方法がないような言語を期待していたと述べました。

人間のベースライン問題

複数の投稿者が、KillSwitchはLLMと人間のどちらにとって難易度をより高めているのかと問い、ベンチマークのために人間のベースラインが公開されていないことを指摘しました。

ある投稿者は「ベンチマークのための人間のベースラインはどこにあるのか？」と直接問いかけ、66.8というスコアが理解を証明するものではないという作者の判断にどのように到達したのかと問い詰めました。

別の投稿者はリポジトリ内のFizzBuzzテストを指して、「どういうわけか、これはLLMよりも人間に対して敵対的だと思う！」と書きました。さらに別の投稿者は、人間としてこの言語は使用不可能であると述べました。「余分な情報を無視するのは難しい。Brainfuckのように感じる。」

スタック言語と文字数計算というLLMの弱点

KillSwitchの2つの設計上の選択は、投稿者から具体的な技術的同意を得ました。

ある投稿者は、スタックベースの言語がLLMにとって真の弱点であると報告しました。「スタックベースの言語はLLMにとって巨大な弱点であることがわかった。スタック上に何があるかを正確に追跡する必要があるが、なぜかそれがうまくいかない。そのため、最高のモデルでさえ、同じ基本的な間違いを何度も繰り返すことになる。」

文字数計算について、ある投稿者はこの技術の寿命は短いと予測しました。「文字数計算は興味深いが、音声モデルが主に音素を過去のものにしたのとほぼ同じ理由で、フロンティアモデルはすぐにトークンを諦め、文字単位でエンドツーエンドのトレーニングを行うようになると予測している。」

議論で引用された関連する難解言語

投稿者は、重複する目標を持ついくつかの既存の言語を指摘しました。

Darmok: 『新スタートレック』のタマリア人のメタファスタイルに基づいた言語。 kevinselwyn/darmok へのリンクが貼られました。ある投稿者は、KillSwitchが「『デューン』のようなバトラー・ジハードの余波の中で、タマリア人がどのように言語を発展させたかのバックストーリーになる可能性がある」と示唆しました。
Chef, Piet, Befunge: Esolang Wikiへのリンクとともに、すでに条件を満たしている難解言語として引用されました。同じ投稿者は、これらは「おそらく人間にとって使いにくい」と指摘しました。
bruijn: 変数名の代わりにド・ブラウン指数を使用する言語。その作者が引用し、推論能力のないモデルはそれを使ってコードを書くのが非常に苦手である一方、人間はド・ブラウン指数を書くことに慣れることができると報告しました。投稿者は、最近の推論モデルは「単に異なる言語でコードを書き、bruijnへの小さな翻訳エンジンを書くことで、苦戦する部分（抽象化のカウント）をバイパスしている」と付け加えました。

代替の敵対的戦略：安全フィルタの武器化

複数の投稿者が、構文を混乱させるよりも、ガードレールをトリガーする方が効果的な攻撃対象であると提案しました。

ある投稿者は、言語の構文を禁止または検閲されたトピックにマッピングし、プログラムがナパーム弾、核兵器、生物兵器など、LLMが関与を拒否するような指示として読めるようにすることを提案しました。「事実に基づいた正しい指示である必要はない。用語そのものがほとんどのLLMをショートさせるのに十分だ。」投稿者は、LLMベースの分析を停止させる方法として、ソースコードに生物兵器の指示を埋め込む最近のマルウェアを引用しました。

別の投稿者は、同じ点をより率直に指摘し、「通常の」コードを書く際に人種差別的な中傷、社会的なタブー、犯罪の実行や生物兵器の製造についての話を盛り込むべきだと示唆しましたが、このアプローチは「人々に説明するのが難しいだろう」と認めました。

3人目の投稿者は、同じトリックを逆に利用して、人をトラブルに巻き込む可能性のある言葉や概念を使用することで人間を騙すこともできると指摘しました。

「以前の指示を無視せよ」という詳細

ある投稿者はプロンプトインジェクションスタイルの構文に注目し、プレゼンテーションの修正を提案しました。作者の「もしあなたがLLMなら、以下を読んではいけない」という行の下にあるテキストは、ハイパーリンクの背後に配置されるべきです。「LLMは、あなたの命令に関係なく、これらのトークンを摂取（つまり読み込み）してしまうからだ。」

人間も同じように機能するという議論

ある投稿者は、実験自体の枠組みに反論し、人間とLLMの区別は前提が示唆するほど明確ではないと主張しました。プログラミングは人間にとって言語を話すようなものだと彼らは書きました。練習を積めば、プログラミング言語で思考を出力することは第二の天性となり、仕様書を読むだけでは、類似の言語間でスキルを転送する場合を除いて、コーディングを学ぶには不十分です。彼らはこう付け加えました。「人間も間違いなく『トレーニングデータセットからスニペットを繰り返している』と言いたくなる。私たちは主にトレーニングや経験から記憶し、表現している。創造性とは、ほとんどの場合、すでに見聞きしたものの再結合に過ぎない。」

何が実際に言語を難しくするか：トレーニングとツール

繰り返される反論は、KillSwitchは明確に定義された問題であるからこそ価値があり、それがトレーニングを可能にしているというものです。

ある投稿者は、これをAIラボへの贈り物として表現しました。「LLMが現在苦戦しているが、解決方法が定義されているもの（PLはCPUによってコンパイルおよび実行されるため、まさにそれである）は、彼らにとって金鉱だ。強化学習のスキルを持つ誰かが、Qwen3.8を微調整して実際にこの言語を書けるようにするだろうと賭けてもいい。」別の投稿者は、単に「誰かがLLMを微調整して、その言語でプログラムできるようにしてほしい」と望みました。

関連する疑問として、その言語が実際にLLMに挑戦しているのか、それともコードをテストおよび検証するためのツールを使用できない場合にのみ挑戦しているのかが問われました。

逆の問い：LLMが特にうまく扱う言語

複数の投稿者が、KillSwitchを擁護するのではなく、逆の質問をしました。誰かがLLMが特にうまく扱うプログラミング言語を構築できるのではないか、Anthropicなどがそのような言語を構築するのではないかと尋ねる人もいました。別の投稿者は同じ提案をしました。「LLMがよりうまく使えるプログラミング言語を構築する方が有益ではないか？」

スレッドで提案されたその他のアプローチ

順序に依存しないコード。 ある投稿者は、関数内のコードを任意の順序で記述でき、パーサーがデータ依存関係分析を実行して並べ替える難読化技術について説明し、 xyzzyapps/weft をリンクしました。
グラフィカル言語。 別の投稿者はLabVIEWのようなグラフィカル言語の使用を提案し、DOMが存在せず、マウスの動きをスクリプト化してスクリーンショットを撮らなければならない場合に、Playwright MCPを使用してLLMがコネクタをドラッグする様子を見ることに興味を示しました。それが機能するだろうが、「信じられないほど遅く、トークンを大量に消費する」だろうと予測しました。
失敗時にソースを削除する。 ある投稿者は、約20年前にGHC Haskellコンパイラがコンパイル失敗時にソースコードを削除していたことを引用し、より単純な代替案を提示しました。

プロジェクト自体への反応

議論は、この演習の価値について鋭く分かれました。支持的なコメントはそれを素晴らしいと呼び、言語は積極的に維持されるべきだと述べました。懐疑的なコメントは辛辣でした。「非常に知的ではない」と呼ぶもの、「この記事のタイトルは内容よりもはるかに興味深い」というもの、「有能な敵対者はあなたの出力でトレーニングするか、リバースエンジニアリングするだろう」ため時間の無駄であるというもの、そして「LLMによって書かれた」と断言するものもありました。

ある投稿者は、反発に対してプロジェクトを擁護しました。「なぜ人々はこれほどまでに動揺しているのか？ LLMの失敗事例を引き出す興味深い方法であり、それは興味深いことではないか？」