Rich Hickey氏が定義する「ツール」の本質
2026年10月11日に発表されたRich Hickey氏の LinkedIn の投稿で、彼は「AIはツールではない」という主張を展開しています（Lobsters）。Hickey氏はまず「ツール」という言葉の定義から入ります。
彼の考えるツールとは、「手で持ち、特定の機能を実行するために使われる装置や道具」であり、特に「完全に制御し、操作し、指揮できるもの」と定義しています。彼は具体例としてハンマーやのこぎりを挙げ、これらは使う人が「振るう（wield）」ことで機能すると説明しています。
ツールとは、あなたが振るうものです。それらはあなたのために何かをするのではなく、それらを使ってあなたが何かを行うものです。
Hickey氏が「ツール」を定義する上で重視しているのは、「手で持つこと」による制御とフィードバックの源泉、行為の親密さ、そして力や方向性の伝達、継続的な意図と制御です。ツールの使用は専門知識とスキルを構築し、絶え間ない技術とエネルギーの適用、そして感覚的なフィードバックが、専門知識の構築に不可欠であると指摘します。
LLMは「自動化」であり「ツール」ではないという主張
Hickey氏は、大規模言語モデル（LLM）には、彼が定義するツールの多くの特性が欠けていると述べています。具体的には、LLMは予測可能で信頼性が高く、決定論的で、機能が限定されているといったツールの特性を持たず、制御、感覚フィードバック、意図、親密さ、継続的な指示、専門知識といった要素がLLMの使用には見られないと主張します。
彼によると、LLMは「自動化」であり、人間がコードを書くことを回避するためのものであり、コードを書く責任を放棄することに他なりません。Hickey氏は、LLMの動作を直接指示するのではなく、リクエストを出すとLLMが自律的に動作するため、これはツールを「振るう」こととは異なると説明しています。
| 特性 | ツール | LLM (Hickey氏の定義) |
|---|---|---|
| 制御 | 可能（人が振るう） | 困難（リクエストに応じた自律動作） |
| フィードバック | 直接的 | 間接的、限定的 |
| 予測可能性 | 高い | 低い |
| スキル習得 | 促進する | 阻害する可能性 |
| 本質 | 道具（人が使う） | 自動化（人が回避する） |
あなたはLLMの行動を指示するのではなく、リクエストを出し、それは自律的に動作します。このリクエスト/自動化サイクルは、振るうことでも、制御でも、継続的なものでもなく、フィードバックもありません。
自動化がもたらす学習機会の喪失
Hickey氏は、自動化を利用することの代償として、現実世界に関する真実を学ぶ機会が失われることを強調しています。彼は、ドライブスルーが料理のツールではなく、料理を避けるための自動化であるように、LLMはコードを書くツールではなく、コードを書くことを避けるための自動化だと例えています。
LLMを使うことで、ユーザーは自動人形の「日々の詳細を解明しようと試み」、「それをゲーム化しようと努める」ことになると指摘。Hickey氏は、LLMの「学習」はアルゴリズムの更新一つで無効になる可能性があり、予測不能なロボットのために働くことになると警鐘を鳴らします（Lobsters）。
一方で、Hickey氏の主張に異を唱える意見も存在します。Hacker News では、LLMもまた使いこなすのにスキルが必要な「ツール」であるという見解が示されました（Hacker News (API)）。
ノコギリやノミを例にとり、それらを手にしても良い成果が出るとは限らず、使う人の判断力やフィードバックを解釈する能力が重要であると指摘しています。LLMの予測不能性も課題ではあるものの、使う側の好奇心や判断力が反映される「鏡」のような存在であると評されているのが興味深い点です。
エンジニア目線で見ると：協調の難しさとスキルセットの変化
Rich Hickey氏の「AIはツールではない、自動化だ」という主張は、私自身の開発経験から見ても深く考えさせられるものがあります。特にPythonやTypeScriptでのコーディングにおいて、Claude CodeのようなAIコーディングツールを「ツール」として完全に制御できているかと言われると、Hickey氏の言う「振るう」という感覚とは少し異なるかもしれません。むしろ、私が出した指示に対してAIが自律的にコードを生成し、それを私が修正・調整するという「協調」に近い感覚です。
従来のIDEのコード補完やリンターは、まさにHickey氏の定義する「ツール」に近いと感じます。予測可能で、私がコマンドを打った時にのみ動作し、そのフィードバックも明確です。しかし、LLMによるコード生成は、その予測不能性やブラックボックス性から、私が主導権を握っているというよりは、AIと対話しながら協同作業をしている、という方が実態に近いのではないでしょうか。
これは、エンジニアのスキルセットに大きな変化を要求するものだと感じます。これまではコードを「書く」スキルが重要でしたが、これからはAIに「的確な指示を出す」スキル、生成されたコードの「品質を評価し修正する」スキル、そしてAIの「癖を理解し、うまく付き合う」スキルがより重要になるでしょう。この変化は単に楽をするための「自動化」と捉えるだけでなく、新たな開発パラダイムとして受け入れる必要があると感じます。
既存のテストコードが充実していれば、LLMが生成したコードも比較的安心して導入できるかもしれません。いずれにせよ、AIの特性を理解し、いかに効果的に統合していくかが今後の鍵になると考えます。
