『大工道具の歴史』という本を読みつつ、思ったことをつらつらと述べてみる。この文章は私が酒を飲みつつ音声入力した独り言を、Claudeで文語に修正した後、微調整したものである。
『大工道具の歴史』という本を読んでいる
なぜこの本を読んでいるのかというと、なんとなく道具というものには歴史があると思うし、大工仕事がどこか気になるからだ。なぜ気になるのかと問われると明確には答えにくいのだが、私はソフトウェアのエンジニア、システムのエンジニアではあるものの、その原理をたどっていけば、親が建設業界にいたこともあり、大工のようなものが身近にあったという背景に気がつく。そういう経緯もあって、建設や大工仕事には関心があるのだろう。
私は道具に関心がある
私はソフトウェアを仕事にしているが、その中でも特に自然と関心が向かうのは、道具系のツールを開発するタイプ、プラットフォームを開発するタイプ、あるいは社内システムを開発するタイプである。外向けに何かを売るためのシステムよりも、自分たちの活動を加速させるシステムや、活動の幅を広げるツール、かゆいところに手が届くような、手の延長としての道具を作るほうが好きだと感じている。自分が使うときも、そういうタイプのツールを好んで使っている。
道具と、機械や設備は違う
そういうことを考えながらこの本を読み進めていくと、まだ数ページしか進んでいないにもかかわらず、すでに面白いと感じる箇所がいくつもある。たとえば冒頭のあたりで、道具と機械、あるいは設備を同列に扱うことに関する疑問に関する話が出てくる。これらは何かを達成するための手段という意味でまとめられがちだが、実質的に道具と設備・機械はまったく違うものだ、というのがこの本の主張と見ている。なぜ、違うのかについて著者は様々な角度から論じていて、なるほど確かにその通りだ、と思いながら読んでいる。
道具を使うと対象の理解が深まる
著者の話を聞いていると、道具とは、それを使うことで対象の手触りや質感を確かめられるものであり、その理解の蓄積により設計力が形成されるものだと思えてくる。著者の説明では、たとえばナイフで木材を削っていくと、そのナイフという道具を通して、木材の強度や耐久性、木という素材の意味合いのようなものへの理解が進む。こうした活動が大切だというのである。しかし、最近は対象が木材以外に金属やプラスチックなどに広がってきており、それはそれで寂しいところがある、というようなことも著者は述べていて、なるほど大工とは木材を中心に据えて何かを作っていく人なのだな、と改めて思った。
ソフトウェアエンジニアの道具とエージェント
そしてこうした話に触れていくうちに、私が最近、使っているコーディングエージェントに対して感じていたモヤモヤの半分くらいが、理解できた気がしている。
私とVimというエディタ
私はもともと Vim を使っている人だ。なぜ、 Vim が好きなのかを説明するときに私がよく言っていたのは、応答が速いからだ、応答速度が安定してあるからだ、という話だった。IDE を使った経験もそれなりにあるのだが、IDE は私の想像を超えた振る舞いをする。頼んでもいないのに勝手に動くことがあるように思うし、それが失敗すると止まったり、挙動が不自然になったり、時間がかかったり、ということも経験した。挙句の果てにはアップデートをあるし、知らないうちに少しずつ挙動が変わっていく。これが私は嫌だった。手触りの原因が編集している対象（つまり、ソフトウェア）に起因するのかしているのか、ツールのほうが変化しているのかがわからなくなってしまう。
そんなことを思ってはいたのだが、その理由が今回、この本の主張に一致しているように感じられた。「道具を通して対象の質感や手触りを確かめられることが重要だ」という話によって、自分が感じていたものが言語化できたように思えて、面白いと感じた。
私とコーディングエージェント
そこからさらに考えを進めていくと、コーディングエージェントについても重要なことが見えてくる。コーディングエージェントにはいろいろなものがあるが、設計思想はかなり違っている。
言われたことしかやらない、純粋にツールとして振る舞うものから、システムとして振る舞い、勝手によかれと思っていろいろやろうとするもの、さらには設備的な、自動生産システムに近い動きをするものまで幅があると感じている。
私が欲しいエージェントはどれかといえば、ツールの延長にあるものだ。本当に言われたことだけをやってほしいし、勝手に動いたり挙動が変わったりしてほしくない。
その意味でいうと、Claude Code の設計思想はそれに比較的近いと感じている。ただ、それでもバージョンが上がるたびに動きが少しずつ変わっていくのは嫌だし、中身が見えていないということも大きな引っかかりになっている。最近は少し暴走気味に感じられる。
こうしたことを考えていくと、結局のところ、オープンソースでローカルにインストールして動き、バージョンを固定でき、ローカルLLMで動くコーディングエージェントがあれば、私はそれを自分の道具として使うことができるし、最終的にはそういうところに着地していくように思う。
私のコーディングエージェントの使い方
実際のところ、私はコーディングエージェントを、高速タイピング装置、高速コーディング装置、高速ターミナル制御装置のように使っている。自分の頭の中にあることをやってほしい。それを伝えるための言語として自然言語の出力が早いからエージェントは望ましい。勝手に動いてほしくない。勝手に並列化されるのも嫌で、全部シングルスレッドで動いてほしいと思っている。わからないことがあれば普通にそれを提示してほしいし、頑張って試行錯誤してほしいと思っていない。勝手に計画外のことをやり始めてほしくない。
問題があった時にそれを報告せずに試行錯誤して突破するのは、私からすれば最悪の挙動に感じられる。AIエージェントの強みの一つに、レジリエンスが挙げられることを知っている。目的を提示すれば、環境の変化を吸収しながら計画を調整して目的を達成することだと私は認識しているが、私からすると計画を自然言語で指示して作成され、それの実行管理を担ってくれるだけで十分に感じられる。
道具の進化と対象の理解
『大工道具の歴史』のなかで著者が言っていたことで印象的な話の一つに、昔はナイフで鉛筆を削ることを通して、子供が木という素材と対話し、対象を理解していくプロセスがあった、という話がある。それがいつの間にか手回し式の鉛筆削りになり、自動の鉛筆削りになっていった。これでは子供が木という素材の意味を理解していくことができなくなってしまう、嘆かわしいことだ、というようなことを著者は書いていた。
同じように、コーディングエージェントを使うようになっていくと、ソフトウェアエンジニアもソフトウェア開発の手触りのようなものがわからなくなっていくのではないか、という懸念は、現在もすでに語られているところだと思う。
住宅の建築プロセスから、創造するシステム開発の未来
ただ、この大工道具の話を読んでいくと、なんとかなりそうだな、とも感じてしまうところもある。私たちは仮に木そのものへの理解が失われているが、その代わりプラスチックや鉄という素材をが使われて家が作られていく。
それは確かに木のように調整するようなことはできず、一度使った後の調整もかもしれないが、建築は事前な設計に関する理論が体系化され、デザインパターンが作られ、それぞれの部品が例えば、窓やドア、ユニットバス、システムキッチン、と個別に生産され、現地で組み立てられる方式になることで実質的には問題がなく住宅は建設される流れになっているように見える。まぁ実際のところ、現地で組み立てる人が少なくなっていると言う問題があるだろうが、それはまた別として。
結局のところ、ソフトウェアも現場で調整することを想定せずに、事前に設計したものを部品的に製造して、それを仕入れて組み立てていくと言う方式になっていくのだろう。
その流れはなんとなく予想がつく。一つ一つの機能がコマンドラインツール、呼び出し可能なライブラリ、ミドルウェアでになっていく。そしてそれを修正しにくくする仕組みとして、コンパイルやビルドが行われ、それが修正されるとサポート対象外となっていくように思う。
