2026年9月の代表者挨拶

危なさは、書ける人にしか見えない。

9月になりました。夏の風物詩ともいえるケンサキイカの夜焚きも、少しずつ終わりを迎える頃です。これまで夜の海に船を出しておられた方々は、通称「ブドウイカ」へと、そろりとターゲットを移していく季節でもあります。平素より格別のご高配を賜り、心より御礼申し上げます。

そしてもうひとつ、9月はアオリイカが群れをなすシーズンです。夏のあいだ上がりきっていた水温が落ち着くと、小魚の活性が一気に上がります。それを追ってイカたちの動きも見違えるように変わり、浅場には新子の群れが差してくる──朝夕のわずかな時間に堤防のあちこちで竿が曲がる、一年でいちばん心の浮き立つ時期かもしれません。これからエギングを始めてみようという方にとっても、いちばん間口の広い季節です。

さて今月は、また工場の裏側の話を書かせてください。先月は「AIに書かせても、止めて確かめるのは人」という話をいたしました。今月はその続きです。この1年、いわゆる「バイブコーディング」を現場で使い倒してみて、その強力さと、まったく同じ大きさの危うさを、両方とも体感しました。そして、多くの人が感じているはずの問いに、私も突き当たりました。──AIが出力したコードを、中身を見ないまま、ブラックボックスのまま現場に持ち込んでよいのか。

■ 「こういうものが欲しい」と言うだけで、動いてしまう

バイブコーディングというのは、細かい仕様書を書かずに「こういうものが欲しい」と普通の言葉で伝え、AIに書かせて、動いたものを受け取るという進め方です。この1年、当社でも実際にこのやり方で、現場の小さな道具をいくつも作ってきました。というより、呼吸をするように、道具を生成しています。

まず申し上げておきたいのは、これは本当に強力だということです。以前なら「やりたいが、調べている時間がない」と棚上げにしていたものが、思いついたその日のうちに動く。外注すれば見積もりから始まっていたものが、昼休みのあいだに形になる。私たちのような小さな町工場にとって、これほどありがたい変化はありません。

■ 動くことと、正しいことは別

ところが、この1年でいちばん怖いと感じたのも、まさにその「動いてしまう」という点でした。出てきたものは、たいていちゃんと動きます。画面はきれいに出るし、数字も出る。動いてしまうので、それが良いものなのか危ういものなのか、外からは判断がつかないのです。

数値の丸め方が一箇所だけなんだか違う。想定の外の値が来たときの振る舞いが決まっていない。エラーを黙って握りつぶし、何事もなかったように次へ進む。──こうした箇所は、動いている画面をいくら眺めても見えません。見えるのは、自分でその手のコードを書いて、痛い目に遭ったことのある人だけです。

結局、出てきたコードを全部追わないと安心できません。任せて浮いたはずの時間が、そっくり「読む仕事」として戻ってきます。作る側の敷居は大きく下がったのに、危ないと気づく側の敷居は下がらなかった──この非対称が、この1年でいちばんはっきりしたことです。私たちの現場に置き換えれば、4,000万円のマシニングセンタの前で「動いたからよし」と言うようなもので、それは絶対に許されません。

■ 理想のワークなど、町工場には無い

では使えない道具なのかというと、まったくそんなことはありません。むしろ、私たちの仕事のある場面には、これ以上ないほど噛み合います。ただ、その話をするには、少し遠回りになりますが、町工場の現実からお話しさせてください。

私の場合、NC言語と呼ばれる機械語を、バイブコーディングで生成するという、少々風変りなことを日常的に行っております。NC言語を出力するためのコーディングには、多くの場合、Pythonが自動選択されるのですが、多くの場合、Rubyで置き換えます。それが私の流儀です。（笑）

最近のNC制御の工作機械は、とてつもなく高精度です。理想的な素材、理想的な加工形状、理想的な寸法──それさえ揃っていれば、驚くほどの仕上がりで削り上げてくれます。ところが、私たちの現場にその「理想」が揃っていることは、まずありません。そのへんにあるもので、何とかやっつける必要がある。素材は不均一で、形もサイズもその都度ばらばらです。図面通りの前提そのものが、手元に無いのです。

これを、私は「あるものでやってしまう精神」と呼んでいます。町工場の強みそのものであり、誇りでもあるのですが、プログラムを書く側から見ると、これがとてもやっかいなのです。寸法が毎回違うのですから、数値を決め打ちで並べた手順書は書けません。「この形を、この寸法で削る」ではなく、「目の前のものを測り、その値から削る量を導く」という書き方に組み替えねばならない。つまり、抽象度を相当に高める必要がある。ここが、町工場のプログラムのいちばん難しいところです。

■ 現物合わせと、リバースエンジニアリングには、もってこい

そして、この「現物合わせ」の進め方が、バイブコーディングのやり方と驚くほど似ています。先に完璧な仕様があるのではなく、目の前の現物に寄せながら、削っては当て、当てては削る。とりあえず動くものを出させ、違うところを指して直させ、また当ててみる。仕様が固まりきる前から手を動かせるので、「あるものでやってしまう」現場とは、実によく噛み合うのです。

なにより大きいのは、いちばん難しいこの「抽象度を上げる」という部分を、バイブコーディングがよく補完してくれることです。決め打ちの一本を見せて「寸法が変わっても通るようにしてほしい」と頼むと、どこを変数にすべきかを拾い上げてくる。人が何日もかけて一般化していた仕事の、当たりをつける部分が一気に片づくのです。「あるものでやってしまう」現場に足りなかったのは、まさにこの力でした。

もうひとつ相性が良いのが、リバースエンジニアリングです。中身の分からない仕組みを外から突ついて、どういう理屈で動いているのかを組み立て直していく作業。見慣れない形式のデータや、昔の誰かが書いた長いコードを前にして「これは何をしているのか」を読み解かせる用途では、驚くほど頼りになります。ここは、こちらが元から分かっていない領域ですから、間違いを含んでいても失うものが少ない。当たりさえつけば、あとは人が確かめられます。

身近なところでは、機械メーカーの側が出力してくるNCプログラム。正直に申し上げて、機械メーカーが提供してくれるNCプログラムが私はあまり好きではありません。インデントもなければ、コメントも不親切で、何をしているのかがまるで読み取れないのです。読めないプログラムは、止めて確かめることもできません。そこをAIが補ってくれます。「読みづらいので、インデントとコメントを付けてほしい」と頼めば、そのとおりに仕上げてくる。「抽象度が低すぎるから、サブルーチンに分解してくれ」と言えば、意味のかたまりごとに切り分けてくれる。動きはそのままに、人が読める形へ整えてもらう──この使い方が、いま当社ではいちばん出番が多いかもしれません。

なにより困るのは、そのサブルーチンが、どの変数に副作用を及ぼすのかを、どこにも書いていないことです。呼べば何かが書き換わる。けれど、何が書き換わるのかは、中を全部読むまで分からない。ここもAIに読ませて「この中で書き換えている変数を、頭にコメントで並べてくれ」と頼めば、拾い出してくれます。人が半日かけて追っていた作業です。

実例をひとつ。ワイヤー放電加工機のNCプログラムを、AIにアレンジさせることがよくあります。これが、便利過ぎて、鼻血が出るかと思いました。NCの世界では、同じ「Gコード」と呼ばれていても、機械メーカーごとに書き方の癖──いわば方言があります。この機種ではこう書く、あの機種ではこの指令が要る。人間なら、メーカーごとのマニュアルを引き比べ、現場で覚えていくほかない部分です。

それを、渡したプログラムの書きぶりから読み取ってしまう。どのメーカーの流儀で書かれたものかを察して、その流儀のまま書き足してくるのです。さらに、メーカーのマニュアルそのものを読ませてみると、今度はその機種固有のマクロを、こちらが指示しないうちから使ってきます。「この機械にはこういう命令が用意されている」と読み取って、当たり前の顔で書いてくる。長い年月をかけて現場に溜まってきた暗黙知が、こういう形で引き出せるのかと、正直、震えました。

ただ、そうやって出てきたプログラムを、そのまま機械へ流すことは絶対にありません。デバッグ作業です。必ず実機にかけ、ステップ実行で一行ずつ送りながら、変数の値とワイヤーの動きを目で確かめます。先月書いたM01（オプショナルストップ）の出番です。どれほど見事な出来に見えても、実機でデバッグできる力がなければ、この道具は使えない。というより、使ってはいけないと考えています。正解を出させる道具としてではなく、当たりをつける道具として使えば、めっぽう強い。ただしその当たりを確かめるのは、いつでも人の側です。

■ ブラックボックスにして、よいのか

そこで、冒頭の問いに戻ります。AIが出力したコードを、中身を見ないまま現場に持ち込んでよいのか。正直に申し上げて、持ち込んで良いケースと、そうでないケースを使い分けています。いまのところは「置き場所で分ける」という線を引いています。間違えても後から気づいて直せるところ、失うものが時間だけで済むところは、中身を全部は追わずに使ってみる。逆に、機械が動き、寸法が決まり、材料が減っていく場所──やり直しのきかないところでは、遠回りでも人が全部読む、という具合です。

やっかいなのは、ブラックボックスがAIの書いた部分だけではないことです。いまのソフトウェアは、世界中の誰かが公開した部品──ライブラリをGitHub等から大量に呼び出すことで成り立っています。現に先日も、JavaScriptの世界で大きな騒ぎがありました。（というか、バックドアの件は毎日のように見聞きする気がします）多くのソフトウェアが土台として使っているライブラリが乗っ取られ、インストールしただけで動き出す仕掛けを埋め込まれたうえ、その仕掛けが自分で次のパッケージへと感染を広げていったのです。数時間のうちに数百のパッケージが汚染されるようです。少し前には、通信に割り込んで送金先をすり替える──つまり決済にかかわるところに手を入れる例もあったようです。

AIに「こういうものが欲しい」と頼めば、当然のように便利な部品を選んで組み込んできます。速いのは、その部品を自分で書かずに済ませているからでもある。つまり私たちが受け取っているのは、AIが書いた箱の中で、さらに他人の箱を呼んでいる二重構造です。材料に何が混ざっているか分からないまま削る職人はいません。ソフトウェアでも、同じことだと思っています。

この「他人の箱を信用してよいのか」という問題は、実は新しいものではありません。1990年代の半ば、qmailというメール配送プログラム（実は10年以上前に利用してました）を書いたD. J. Bernstein氏（数学科の大学教授だったらしいです！）は、標準Cライブラリ──言語に最初から付いてくる、誰もが疑わずに使う部品──さえ信用してなかったようです。（もはや凄すぎて、優秀過ぎて、想像を超越しています！超人です！）「私は標準ライブラリをほぼ諦めた」と本人が設計文書に明言し、文字列の扱いやメモリの管理といった、事故のもっとも起きやすい部品を、何年もかけて育てた自作の小さな部品で置き換えたらしいのです。さすがにOSの機能まで作り直したわけではなかったようですが、危ないところを自分の管理下に置く、という一点は徹底していたようです。

qmailを貫いているのは、「信用する対象を、可能な限り減らす」という思想です。部品の自作にとどまらず、プログラムの内部を役割ごとに小さく分け、自分の部品同士でさえ互いを信用しない作りになっています。どれか一つが乗っ取られても、そこから先へは踏み込めない。30年前に、ここまで考え抜いた人がいたわけです。もちろん、ライブラリを片端から自作するやり方を、いまの私たちが真似することはできません。ただ、「信用できないものが混ざる前提で、境界を切っておく」という考え方のほうは、そのまま今日に持ち帰れます。

そして怖いのは、箱が大きすぎると、取り返しがつかなくなることです。中身の分からないものを一つの大きな塊として深く抱え込んでしまうと、何かあったときに切り離せません。ですから、設計の側で手を打っておく必要があります。すなわち、いつでも取り換えられる形にしておくこと。この部分は別のものに差し替えられる、この部品を外しても全体は動く──そういう作りにしておけば、何かあった日に、その箱だけを捨てられます。

そのために要るのが、オブジェクト指向的な設計力です。何を一つのまとまりとして扱い、外からは何を見せ、中身をどこまで隠すのか。境界をどこに引くのか。かつては「きれいな書き方」の話だと思われていたものが、いまや、危ないものを抱え込まないための実務的な必需品になりました。中身をAIが書いてくれる時代だからこそ、その境界を決める力のほうが要るのです。

そして、この線は放っておくと動きます。うまくいく体験が続けば、人はどうしても箱を大きくしたくなる。しかも厄介なことに、危ないと気づく力のほうは、自分で書かなくなった分だけ確実に鈍っていきます。使えば使うほど見抜けなくなる、という性質をこの道具は持っている。ですから線は、道具の側ではなく、人の側で引き直し続けるしかありません。

■ コーディングより、システムエンジニアリング

こうして1年ぶんを振り返って、いちばん印象が変わったのはここです。これから本当に必須になるのは、コーディングそのものよりも、システムエンジニアリングの能力ではないか、ということ。

何を作り、何を作らないのかを決める。どこまでを機械に任せ、どこから先は人が判断するのか、その線を引く。動かなくなったときにどう元へ戻すかを、作る前に用意しておく。データをどこに置き、誰が責任を持つのかを決める。──これらは、いくら賢くなってもAIが代わりに決めてはくれません。決めるには、現場の仕事そのものを知っている必要があるからです。

コードを書く時間が減ったぶん、私たちは設計と、運用と、やめどきの判断に時間を使うようになりました。皮肉なようですが、書く手間が消えたことで、書く前の仕事の重さがはっきり見えてきたのです。

■ 有田町で、全工程を自社で

小さな会社では、作った本人が使い、壊れたら本人が直します。ですから「作れるかどうか」よりも、「自分たちで面倒を見られる範囲かどうか」のほうが、よほど大事な判断になります。動かなくなった日に自力で元へ戻せる規模に留めておく。派手さはありませんが、これが身の丈に合ったDXというものだと考えています。

これはエギづくりとまったく同じ話でもあります。試作は以前よりずっと速く作れるようになりました。けれど、それを海で確かめる工程だけは、どうやっても短縮できません。最後に良し悪しを決めるのは、いつも海です。速く作れるようになったぶんだけ、確かめる時間を厚く取る──それが、私たちの選んだ使い方です。

日本の、佐賀県有田町という小さな地方都市で、設計から金型切削、量産、そして販売まで、エギの全工程を自社で一貫してつくり続けながら──そんなことを考えていた8月でした。世界のどこかの誰かが書いた部品が自分の工場の中で動き、機械の方言をAIが読み解く。その只中で、何を人の手に残しておくべきなのか。答えはまだ半分も出ていませんが、考えることだけはやめずにおこうと思います。

■ 今月、海へ出るもの

9月は、当社にとって新しい色と製品が続く月になります。赤侍メテオグローオレンジは、蓄光の発光時とUV照射時とで表情の変わる橙で、今月の発売を予定しています。岸からのティップランに向けたジェットチェイサー パープルエディションも同じく今月。さらに、ジェットチェイサーの3.0号・3.1号を一般販売として、9月末の出荷を予定しております。

くわえて今年は、エギシャープの「赤侍カラー」が生まれてから15年目にあたります。先月末には、15周年を記念したカラーの画像を公開いたしました。15年ものあいだ選ばれ続けたという事実は、私たちの自信ではなく、使ってくださった方々が出してくださった答えそのものだと受け止めております。

道具がどれだけ賢くなっても、最後に判断するのは人であり、良し悪しを決めるのは海である──そのことを忘れずに、一歩ずつものづくりに励んでまいります。今月も、どうぞよろしくお願いいたします。

令和8年9月
株式会社キーストン
代表取締役　金川 信栄