このブログ記事は、開発者のコミュニティや職場において人工知能（AI）の話題が過剰になり、本来の目的が見失われている現状を批判的に考察しています。著者は、AIを便利な道具として認めつつも、人々が成果物よりもツールの使用法自体に執着していることに強い違和感を表明しています。かつてはプロダクトの価値を重視していたエンジニアたちが、今や単なるツールの設定や生成プロセスの共有に終始していると警鐘を鳴らしています。さらに、経営層までもが具体的な技術導入に干渉し、本質的ではない指標で開発を評価し始めていることへの不満も綴られています。最終的に、著者は技術そのものへの没頭を控え、他者の役に立つ価値あるものを創造するという本来の姿勢に戻るべきだと主張しています。このように、本ソースは急速なAI普及がもたらしたクリエイティブな対話の停滞に対する個人的な懸念をまとめたものです。
AIブームの影で、私たちが「作る喜び」を忘れかけている理由
1. イントロダクション：AIという「日常」への倦怠感
異端者のように聞こえるリスクを承知であえて言えば、私はAIについて語ることに、いささか飽き飽きしている。
誤解しないでほしい。AIが驚異的なツールであることは十分に理解しているし、私自身も毎日活用している。最近、ウェブスケール（懐かしい響きだ）の複雑なドメインを扱う新たな職務に就いた際も、AIのおかげで、わずか数週間で生産性を「0から1」へと引き上げることができた。ワークフローは劇的に進化したのだ。
しかし、その驚きも今や「ルーチン」になりつつある。技術の変化の速さは認めつつも、日々の会話として、もう語るべきことが尽きてしまった。さらに悪いことに、インターネット上の私のお気に入りの場所——例えばHacker Newsのような、かつては興味深いプロジェクトや解決策で溢れていた場所——が、今や「AI一色」に染まっている。
試しに「Kagi Small Web」を開き、「Next」ボタンを20回ほど押してみてほしい。そこにある投稿の何割がAIに関連したものだろうか。かつての多様な知性は影を潜め、どこを見てもAIの話題ばかりだ。
「雲に向かって叫んでいる老人（old man yells at cloud）」だと思わないでほしい。私が感じているのは、誰もがAIというツールをいじることに執着し、肝心の「何を作るか」という視点が失われつつあることへの、エンジニアとしての危機感なのだ。
2. 「ハンマー」の自慢はやめて、「テーブル」の話をしよう
現在のエンジニアリング文化を見渡すと、奇妙な現象が起きている。道具（AI）そのものについての議論が、本来の目的である「成果物」を完全に覆い隠してしまっている。
この状況は、ある比喩を用いると非常に分かりやすい。
「木工の掲示板に行ったら、誰も作ったテーブルの写真を載せず、使っているハンマーの話ばかりしているようなものだ。しかも、全員が基本的には同じハンマーを同じように使っているだけなのに、互いに大声で同じことを叫び合っているのだ」
今のテック業界は、まさにこの状態に陥っていないだろうか。Claudeのワークフローがどうだとか、OpenClawを使って猫を撫でたりビデオゲームをしたりする時間をいかに捻出したか、といった話ばかりだ。そして、その捻出した時間で、さらに別のAIツールを構成する……。これはもはや、目的と手段が逆転した、空虚で「自己充足的」なループである。
私たちは、同じハンマーの振り方を競い合うことに夢中で、本来作るべき「テーブル」の存在を忘れてはいないだろうか。
3. 「プロダクトエンジニア」から「オートコンプリートの番人」への退行
2023年頃、「プロダクトエンジニア」という言葉が脚光を浴びた。コードそのものに固執するのではなく、エンジニアが届けるべき「プロダクトの価値」に執着すべきだという、極めて健全な考え方だ。私はこの概念を心から支持していた。
しかし、AIの普及によって、私たちはその理想から明らかに「退行」してしまった。
今や、Claudeのターミナルを開きさえすれば、誰でも「AIエンジニア」を自称できる。だが、そこで行われているのはプロダクトの本質的な設計ではない。私たちが執着しているのは、AIという名の「肥大化したオートコンプリート（overgrown auto-complete）」の調整だ。
エンジニアリングの本質は、複雑な問題を解き、価値を届けることにある。しかし今の私たちは、仕事の中で最も「簡単な」部分——コードを書くこと——をさらに簡単にするためのツールに、リソースの大部分を割いている。これは「価値」への執着ではなく、作業効率という名の心地よい麻薬に溺れている状態と言わざるを得ない。
4. マネジメントの誤算：トークン使用量は「行数」の再来か
このツールの熱狂は、ついにマネジメント層にまで波及した。これまでの歴史を振り返れば、これは極めて異例かつ、危うい事態だ。
かつてのマネージャーたちは、データベースの選定やIDE、JavaScriptフレームワークといった「実装の詳細」にはほとんど関心を持っていなかった。彼らが求めていたのは、顧客に提供する「機能」と「価値」だった。だが現在、マネジメントはSDLC（ソフトウェア開発ライフサイクル）の細部に、不器用かつ無計画に足を踏み入れ始めている。
かつて、私たちはDORAメトリクスのような指標を用い、デプロイの頻度や変更失敗率といった「アウトカム（成果）」で生産性を測ってきた。しかし今、多くの組織で「AIをどれだけ使ったか」が個人の目標に組み込まれている。
開発者一人あたりの「トークン使用量」を測定することに、果たして何の意味があるのだろうか。それは、かつて「コードの行数（LoC）」でエンジニアを評価しようとして大失敗した歴史の、質の悪い再放送だ。実装詳細に介入し、ツールの使用量で人を測る行為は、エンジニアの専門性に対する侮辱であり、プロフェッショナルとしての自律性を脅かす退行でしかない。
5. 結論：私たちが本当に作るべきもの
コーディングとは、他のあらゆる工芸（クラフト）と同じく、誰かのために価値のある何かを創り出すための「手段」である。たとえその「誰か」が自分自身であったとしても、そこには作り手としての誇り、すなわち「職人技」が宿るべきだ。
私たちが焦点を戻すべきなのは、「何を使って作ったか」という自慢話ではない。「何を作り、それが誰をどう幸せにしたか」という物語だ。AIはあくまで強力なツールに過ぎず、それ自体が語るべき主役ではない。
ツールについての空虚な議論を一度止め、再び「作る喜び」と、届けたい「価値」について語り合おうではないか。
最後に、あなた自身のプロジェクトを振り返り、問いかけてみてほしい。
「今日あなたが触れたAIは、誰かのための『テーブル』を完成させる助けになりましたか？」
