ハクソク

世界を動かす技術を、日本語で。

自動プログラミング

114日前原文(antirez.com)

概要

  • AI支援によるソフトウェア開発 を「Automatic Programming」と呼称
  • 人間の直感や設計 がAIの出力結果に大きな影響を与える点を強調
  • Vibe coding はAI任せで人間の関与が最小限な手法
  • Automatic Programming は高品質かつ制作者のビジョンに基づく開発
  • AI生成コードの所有権や誇り についての考察

Automatic Programmingとは何か

  • AI支援 を活用したソフトウェア開発プロセスを「Automatic Programming」と定義
  • 近い将来、これは単なる「ソフトウェア開発」の標準手法となる予測
  • 同じ大規模言語モデル（LLM） でも、人間の 直感 や 設計力、 継続的な舵取り によって生成結果が大きく変化
  • AI任せの開発 を「Vibe coding」と区別
    • Vibe codingは 大まかな要件 のみをAIに伝え、AIが即興でコードを生成
    • 人間は基本的に 問題点の報告 や 期待外れの指摘 のみを行う傾向

Vibe codingとAutomatic Programmingの違い

  • Vibe coding ：AI主導で人間の関与がほぼない開発手法
    • 民主化 されたソフトウェア生産の一形態
    • 使いどころはあるが、品質や設計へのこだわりは薄い
  • Automatic Programming ：人間の明確なビジョンや設計が反映される開発手法
    • 高品質 かつ 制作者の意図 を強く反映
    • AIアシスト を受けつつも、要件定義や細部の設計に人間が深く関与

AI生成コードの所有権と誇り

  • LLMの学習データ は人間による集合知の産物
  • AI生成コード は利用者自身の成果物とみなして良い
  • 自分のアウトプット として誇りを持つべき理由
    • Redis の例：技術的には新規性が少なくても、 ビジョンやアイデア が価値を生み出す
    • プログラミングは自動化 されつつあるが、 ビジョンの自動化 はまだ実現していない現状

まとめ

  • Automatic Programming は、AIと人間の協働による新しいソフトウェア開発の形
  • 人間のビジョン や 設計力 が最終的な成果物の質を決定
  • AI生成物の所有権 や誇りを持つことが重要
  • Vibe coding と区別し、意図的な開発を心がける姿勢

Hackerたちの意見

これは典型的な偽の二項対立だね。バイブコーディング、自動コーディング、コーディングは明らかにスペクトラム上にあるし、プロジェクトの中でそのすべての色合いを使えるんだよ。

└

AIは、いろんな方法で演奏できる楽器みたいなもので、スタイルや強度も様々だね。言ってみれば、スペックストラミングって感じかな。

└

要するに: 「ユーザーはLLMの出力を自分のものとして主張すべきだ。理由はこうだ。LLMはツールであり、ツールは使う人のスキルによって使い方が変わる。ツールの出力（LLMを含む）はユーザーのスキルの関数であり、したがってその出力はユーザーに帰属する。」さらに、ツール、特にLLMを積極的かつ意識的に使うべきだ。頭をオフにして出力を無批判に受け入れるべきじゃない。進めながら反復して改善していくべきだと思う。著者がスキルの程度の違いを種類の違いに不適切に変換しているように見えるのには同意するよ。

誰かが「バイブした」とか「クロードが何かをくれた」って言うのを聞くたびに、すごく「初稿」っぽいコードを読むことになるんじゃないかって思っちゃう。コードを送るときにそれを所有する必要があるって話をたくさんする人からもそう感じる。人々は、自分の作品に使ったツールのせいで謝るのをやめるべきだよ。もっと良い作品を作れば、謝る必要もないし、他の人の時間を無駄にすることもない。特に、そういうツールがあってクリーンアップが楽になるはずなのにね（理論上は）！

└

そうだね。それに、彼らは期待値を上げて、より良いバイブコードのアプリを提供するために努力すべきだと思う。自動化も絡むだろうしね。

└

問題は、建築やコードの品質を気にせずにデザインを進められるようになってしまったことだね。

「事前学習は、実際には私たちの共同の贈り物だと思う」って言うけど、多くの影響力のあるオープンソースプログラマーが、自分のコードをこういうモデルの訓練に使ってほしくないって明言してるのに、この表現は良くないと思う。彼らの「贈り物」じゃなくて、無理やり奪われたものだよ。 > 「私はプログラマーで、自動プログラミングを使ってる。こうして生成したコードは俺のものだ。俺のコード、俺の出力、俺の作品。俺も、君も誇りに思っていい。LLMが生成したコードの中には、以前読んだ本や技術ブログの内容をそのままコピーしたものをすぐに認識できるものもあった（例えば、同じ意味、似たようなコメント構造や変数名）。法的に義務がなくても、アイデアやコードの出所をクレジットするのは最低限のことだよ。LLMはコードを完全に自分のものとして洗練させるだけだからね。

└

どんなオープンソースの貢献も、それ以前のものから切り離すことはできないと思う。私たちはみんな巨人の肩の上に立っているからね。すべての開発者は、先人から学び、既存のプロジェクトからパターンやコードを適応させているんだ。

└

「この表現は良くないと思う。多くの影響力のあるオープンソースプログラマーが、自分のコードをこういうモデルの訓練に使ってほしくないって明言してるのに。」それは、創造者たちの運命だよ。カフカは、自分の作品が死後に焼かれることを望んでいたって明言してた。だから、グレゴールの妹とのぎこちないやり取りを読んでいるとき、あなたは文字通り、他人のプライベートな思考を消費していることになる。彼はそれを誰とも共有したくないと言っていたのにね。それでも人々はカフカの「文学への貢献」について話すけど、ほとんどの人はそれを読むべきかどうかすら考えないんだよね。

└

クイックソートを実装するとき、コメントにホーアの名前を書く？

└

この視点が理解できない。プログラマーは他の知的財産の例をバカにすることが多く、中には完全に無視する人もいる。Google対Oracleの裁判を読んだことがあるけど、OracleがGoogleを訴えたのは、配列のインデックスの範囲をチェックするための約9行のコードを盗んだってことだった。AI企業が悪いってことなのかな？これは何兆もの価値を生み出し、情報を民主化する変革的な技術で、すべてはVCマネーによって補助されてる。オープンソースで高尚な目的を持ってると主張する人が、これに反対する理由は何だろう？自分のリポジトリがスターをもらえなくなるから？誰も自分のくだらないスタックオーバーフローの回答を読まなくなるから？ https://en.wikipedia.org/wiki/Google_LLC_v.Oracle_America,....

└

知的財産は絶対的なものじゃなくて、他の財産と同じように収用されることもあるよ。

└

自分のコードを許可されたライセンスのもとで他の人に公開したら、望んでいないことに使われるのは、無理やり奪われることじゃないよ。贈り物には好きに使えるからね。一度コードをフリーソフトウェアとしてリリースしたら、それはもう君のものじゃない。どう使われるかについての君の意見は関係ないよ。

└

影響力のあるオープンソースプログラマーが、自分のコードがこれらのモデルのトレーニングに使われることを望んでいないと明言している人がたくさんいるし、LLMが存在しなかった世界で自分の作品にライセンスを付与している。彼らの「贈り物」ではなく、無理やり奪われたものなんだ。 「フリーオープンソース」ライセンスと公共の場に置くことの間には微妙な法的違いがある。オープンソースライセンスを使用すれば、LLMのトレーニングを禁止することができる（ライセンス法では、他のすべての法律分野とは異なり、ライセンスを受ける者に与えられていないものはすべて禁止されている）。そうすれば、大手企業（MSFT、Meta、OpenAI、Google）を訴えることができる。もし彼らがあなたの条件を違反したことを示せればね。ソフトウェアを公共の場に置くと、どんな使用も公正で、リリース時に発明されていなかったコードやその派生物を利用する方法も含まれる。興味深いことに、GPLは、もしGPLのコードでLLMを事前にトレーニングし、それを使ってコードを生成（Claude Codeなど）した場合、生成されたすべてのコードは—明らかに派生知的財産である—GPLの条件に従ってオープンソースにする必要があることを暗示しているのではないか？（それはライセンサーの精神に沿っているように思える）。これについてはまだどこでも議論されているのを見たことがない。

└

彼らの「贈り物」ではなく、無理やり奪われたものなんだ。そうだね。まさにその通り。そういう場合、開発者として「インターネット」に対する信頼が侵害されたように感じる。実際、もっとひどいことだ。私は本当に信頼していたわけではないけど、こんなに悪いとは思ってもみなかった。

「事前学習は、実際には私たちの共同の贈り物で、多くの人がそれ以外ではできないことを可能にする、まるで私たちがある意味で共同の心でつながっているかのように。」奪われたものは贈り物じゃないよ。とにかく、私の意見では、LLMが生成したコードは、あなたがそれに責任を持っている限り、あなたのものだと思う。PRを見るとき、私はその人の出力を読んでいるんだ。使ったツールに関係なくね。提出者がコードの完全な所有権を持たないときには、対立が生じるかもしれない。だから、その部分ではAntirezに賛成だね。

└

知識は盗まれない。知識をゲートキーピングする人がいる場合に限って盗まれると言えるけど、それは少なくとも疑わしいよね。数学は盗まれるの？もし数学を盗んでその上に自分の知識を築いたとしても、何も所有してないし、自分が盗まれたと主張することもできない。

└

盗まれたものは贈り物じゃない。うん、その発言には本当に反応しちゃった。

業界で30年以上の経験があって、仕事ではスペック駆動開発にかなり力を入れてるんだけど、これはゲームチェンジャーだよ。プログラミングが大好きで、今は一段上のレベル、つまりスペックでプログラムできるようになった。スペックに何時間もかけて、最初にClaude Codeを使ってすべての要件を生成して反復し、Opus 4.5を使って自己レビューを行い、その後GPT-5.2を使ってCoPilotで要件を見直してる。この自己レビューは、適切だと思われるすべての役割や視点を使ってスペックを見直すためのプロンプトなんだ。この自己レビューのプロセスは重要で、本当に要件を磨いてくれる（通常は7〜8回の自己レビューを行う）。要件が磨かれて、ステークホルダーからの質問が解決されたら、再びClaude Codeを使って、非常に詳細で段階的な実装計画を作成するよ。これもすべてスペックの中でね（要件ドキュメントが大きすぎてコンテキストウィンドウを埋める場合は新しいファイルを使う）。その実装計画も同じように、2つのモデルを使って7〜8回の多段階自己レビューを経て、最終的には私のレビューで仕上げる。結果は？ その後、Claude Codeに計画を実装するように指示すれば、だいたい20分で終わるんだ。このプロセスを使って、受け入れテストでの変更なしに大きな機能を提供できたよ。面白いのは、古いものが新しくなるってこと。業界に入ったとき、私は防衛契約の仕事をしていて、F-22の「ブラックボックス」を作るプロジェクトに関わっていた。チームに参加したとき、彼らはすでにスペック作成プロセスに1年取り組んでいて、コードはゼロだったし（確か）スペックのためにさらに1年のスケジュールがあった。3つ目の仕事では、1970年代に書かれたメインフレームホスティングの出版アプリケーションのスペックをまとめたバインダーが入った棚を見つけた。振り返ってみると、アジャイル運動は、私がキャリアの初めに経験したような重いウォーターフォールプロセスに対する反発だったと思う。少なくとも私にとって、AI支援のミニウォーターフォール（「拡張カスケード」？）は、アジャイルの「おっと、そんなこと考えてなかった」から脱却して、より良い品質のソフトウェアを生み出す道のように思える。

└

ウォーターフォールは、以下の条件でうまくいくことがあるよ：1/ 長期的な視点で、会社が何年もかけてプロジェクトを進めることができるって分かってること、そしてそれがこれからもずっと続くってこと。2/ 仕様書とコードを書く人がほぼ同じ人たちであること。アジャイルは、企業が死ぬ前にソフトウェアをリリースできるようにすること（1番目）や、非技術系のビジネスパーソンが（中途半端な）仕様書を書いて、技術者がそれを実装するための「猿の仕事」を期待されるというアンチパターンを解消することに力を入れてた。

└

プログラミングの未来は仕様書だと思ってるから、すでにそういうスタイルでやってるあなたに聞きたいんだけど、学ぶ価値のある公の仕様書で、尊敬しているものはある？過去の世代がジョン・カーマックのクエイクのコードを称賛したように、次の世代は素晴らしい仕様書を祝うと思ってる。

└

そうだね。俺はずっと仕様駆動の開発にハマってる（人間がエージェントだった頃ね）けど、今まで失敗したことはないよ。実際、LLMからの注目度は人間よりも圧倒的に高いしね（笑）。

└

アジャイルは、環境が変わる中で実行可能な要件を見つける問題を解決してくれるよ。もし要件がすでに分かっているなら、アジャイルは必要ないけどね。

└

俺の経験では、そういう一発勝負のプロジェクトは現実とぶつかると生き残らないよ。極めて詳細な仕様があっても、最終的な結果は人々が思い描いていたものとは違うことが多い。人間の頭ではソフトウェアの複雑さや、対処すべきエッジケースを完全に予測することはできないからね。「ああ、このスケジュールされたアラームがすごくうざいとは思わなかった。他のアラームがこれを上書きすると思ってたのに。プロトタイプを作れたのは良かった、紙の上では予測しにくかったから。」君の報告を信じてないわけじゃないけど、もしかしたら君はすごく決定論的な領域で働いてるのかもしれないね。俺はそうじゃないけど。

└

それらを選択肢として見るよりも、作業の異なるモードとして捉える方がいいかもね。時には切り替えるのが役立つこともあるし。古いスタイルのクラシックなウォーターフォールは柔軟性が欠けていて、アジャイルは計画が不足しているけど、同じプロジェクト内で何度も行き来する理由がないとは思わないな。

└

これって「Design by Contract」の新しい名前じゃない？ https://www.goodreads.com/book/show/15182720-design-by-contr... 従属チームの代わりに大規模言語モデルを使ってるってことかな？ c.f., https://se.inf.ethz.ch/~meyer/publications/old/dbc_chapter.p...

└

「新しいファイルを使うのは、要件ドキュメントが大きすぎてコンテキストウィンドウを埋めてしまうから」 要件ドキュメントが大きすぎてコンテキストウィンドウを埋めてしまう場合は、新しいファイルを使う。

└

でも、結果として得られるコードはどうなってるの？ C++のコードをすぐに出力できるけど、その後にリファクタリングするのに10倍の時間をかけなきゃいけないことがわかった。プロジェクトごとの設定ファイルやグローバル設定ファイルで「現代のC++に精通したプロの経験豊富な10倍の開発者、ストラウストラップの再来だ」と何度言っても、同じクソみたいなコードを吐き続けるんだ（手動メモリ管理とかRAIIの代わりにあちこちで、初期化リストの代わりにコンストラクタのボディでフィールドを初期化したり、オブジェクトが常に一貫した状態にあることを保証するための適切なコンストラクタ/デストラクタ設計の代わりに手動の初期化/クリーンアップメソッドを持ってたり、その他のアンチパターンがたくさんあったり）。これはGitHubの平均的なC++コードがこんな感じだから仕方ないと思うけど、結局、あまり賢くないジュニア開発者のために終わりのないコードレビューをする仕事に変わっていく気がしてならないんだよね…。

└

アジャイルは仕様書作成に反対してるわけじゃないよ。仕様書はストーリーのタスクになり得るし、自動テストもそうだよ。どちらも受け入れ基準の成果物になりうる。でも、実際にはそうならなかったんだ。人間の性質として、最小限の努力を求めるからね。AIを使うと、最小限の努力で仕様書ができるから、それが「やるべき最高のこと」になっちゃうんだ。

私はプログラマーで、自動プログラミングを使ってる。こうして生成したコードは私のものだ。私のコード、私の成果、私のプロダクション。私は、あなたも誇りに思えるよ。私は反対だよ。あなたが書いたコードは、使ったモデルとのコラボレーションだよ。こう考えると、あなたはモデルがあなたのためにやった仕事に対してクレジットを取ってることになる。自分一人で書いたコードと、パートナーと一緒に書いたコードには違いがある。オペラの楽譜の作者が、リブレットの作者に大まかな物語の流れを与えたからって、リブレットのクレジットを取るのと同じだよ。自分でやらなかったら、それは自分のものじゃない。私は一般的に、統合された作品や、少なくともコラボレーションを明確に認めて適切にクレジットを与える作品の方が好きだな。

└

平均的なフォーチュン1000の開発者は、プログラミングのときに何個のJavaScriptライブラリを使うんだろう？

└

それに、「モデル」の仕事だけじゃなくて、そのモデルが訓練された人間の仕事も含まれてるから、しばしば違法にね。

└

AIに指示を出すのは、まさに「自分でやる」ってことだよね。ここには他に誰もいないし、このコードはオリジナルで、今ここに存在していなかったら、私がこの機械に指示を出さなかったら存在しなかったんだ。

└

自動補完を使えば使うほど、その境界が曖昧になっていくね。エージェンティックプログラミングは、結局のところ、高度な自動補完で、英語の非常に曖昧なマッチングを行う。だけど、ブロックを書いて、コパイロットに3、4、5の文を完成させてもらうと、本当に自分がコードを書いているのかな？

└

私の言い方だと、プログラミングにおけるAIの支援はサービスであって、ツールじゃない。外部のショップにコードを書いてもらうような感じだね。多くの会社は人間のプログラマーにこれをやってるけど、OpenAIやAnthropicに依頼すると、彼らが提供するコードは機械が書いたものなんだ。

└

反論しようと思ったけど、急に過去の状況を思い出した。プロジェクトマネージャーが、私が書いたコードを自分の成果だと考えて、会社の感謝を誇らしげに受け入れていたことがあったんだ。

1950年代から60年代にかけて、「自動プログラミング」という用語はコンパイラの構築を指していたんだ。アセンブラコードを手で書く代わりに、FORmula TRANslator（FORTRAN）が「魔法のように」数学の式をコードに変換してくれるって感じ。1980年代の「4GL」は、ソフトウェア会社が提供する非常に高水準の言語の時代で、DBアクセスを統合して特定の分野に特化していたんだ。要するに、問題解決に必要なボイラープレートを書くことなく、実際の問題にもっと集中できるってこと。LLM（大規模言語モデル）は、自然言語の仕様からドラフト実装に進むことを可能にしてくれる。運が良ければ、すぐに動いて欲しい結果が得られるけど、たいていはエラーを修正したり、最初の試みを見直してデザインを変更したり、機能を追加したりするために、NLコマンドを使ってコードベースを反復的に修正する必要があるんだ。

おそらく、antirezのようなマスターソフトウェア職人の最後の世代を目撃しているのかもしれない。彼らの熟練が、知的な機械ツールの力を活用してデザインや理解、構築をするのを見るのは美しい。これは、ミケランジェロのような光とイメージの達人がカメラやフォトショップ、プリンターを受け取るようなもの。芸術の飛躍的な向上だよ。でも、ミケランジェロのようなマスターになるためには、手作業で材料を混ぜたり、光を曲げたり調整したりする技術に専念しなきゃいけなかった。反射や、何よりも練習を通じて神経回路をゆっくりと構築していくんだ。それが自然にできるようになるまで。そうなった時、芸術は彼女の心から物理的な世界に流れ出て、体が直感の器となる。antirezのようなマスターは、人間の心には馴染みのない概念を理解しなきゃいけなかった。ビット、バイト、配列、メモリレイアウト、プロセッサ、コンパイラ、インターフェース、抽象化、制約、型、並行性は、脳を鍛えたサバンナには存在しない。自分の認知能力と制約を理解し、コードユニットや抽象の境界をどのレベルで壊すべきかを知る必要があったんだ。最上級では、ソフトウェアがRedisのように美しく、強力で、芸術の中で高められて、よりシンプルになった。まるでピカソが犬を描くように。知的なソフトウェア構築機械は、人間が手作業でできないことをすることができる（同じ時間を与えられれば、人間は死んだり、年を取ったり、飽きたりするからね）。でも、彼らは筆やキャンバスではない。別の方法で機能するから、心はそれをマスターするための別の道を必要とする。これらをマスターするための道は、職人のソフトウェア構築をマスターするための道とは違うんだ。だから、この新しい世代は、職人には不可能なものを作りたいと思っているから、今は想像もできないような別の技術のマスターになっていくんだ。ミケランジェロが現代の写真の達人が持つ光のコントロールのレベルを想像できなかったのと同じように。私はマスターではないけど、手作りのソフトウェア構築に人生を捧げてきたから、新しいツールを受け入れて使うのが楽しみだし、新しい技術を試すのがワクワクする。でも、この新しい世界の不確実性にはちょっと怖さも感じてる。生きているって素晴らしい時代だね。

└

私たちはもしかしたら、antirezのようなマスターソフトウェア職人の最後の世代を目撃しているのかもしれない。人間がトップコンピュータに勝つことを夢見たのが数十年前だというのに、チェスは今でもかつてないほど人気だと聞いたよ。

└

よく言ったね。君はここにいるほとんどの人よりも、物事の行く先がはっきり見えてると思うよ。

└

そうでもないよ。

「antirezのようなマスターは、人間の頭には馴染みのない概念を理解しなきゃいけなかった。ビット、バイト、配列、メモリのレイアウト、プロセッサ、コンパイラ、インターフェース、抽象化、制約、型、並行性は、脳を鍛えたサバンナには存在しないんだ。CRUDダッシュボードを作る以上のことをするなら、これらのことを知っておく必要がある。LLMはコード生成や知識の検索を手伝ってくれるけど、それだけだよ。結局、以前に知っておくべきことは全部知っておいて、AIツールをうまく活用してスピードアップするのが求められるってこと。*これもオプションだけどね。誰もAIについて何も無視して、2022年以前のようにソフトウェアを開発し続けることを妨げるものは何もない。効率の違いなんて、全体的に見れば大したことじゃないし。人々が完璧なソフトウェア仕様書を山のように持っていて、それを実装するのを待っているわけじゃないからね。普通、仕様はプログラムを書いているうちに出てくるものだよ。

Opus 4.5でClaude Codeを試して以来、非常に似た結論に達したよ（技術とツールの大きなパラダイムシフト）。私はそれを「禅コーディング」と呼んでいて、コードベースを禅庭のように扱うんだ。コードベースのメンタルマップを維持して、実装のためにプロンプトを出す前にすべてを仕様化して、すべてのdiffを行ごとにレビューする。AIはシステムデザインを実装するためのツールであって、システムデザイナーそのものではない（少なくとも今はね...）。この二つの概念の違いは重要だよ。専門知識は、何を仕様化するかを知り、出力がデザインから逸脱したときにそれをキャッチすることにある。今の技術は非常に優れているから、慎重にレビューされた仕様は最先端のLLMによって確実に実装される。あいまいなリクエストに対して平凡なコードを生成するLLMでも、システムを深く理解して制約をかける人によって導かれれば、しっかりしたコードを生成するんだ。これが、バイブコーディングと禅コーディングの違いだよ。禅コーダーは自分の技術の達人で、バイブコーダーは楽しんでいるアマチュア。アマチュアで楽しむことに何の問題もないからね。私はAIを使って、あまりコーディングとは言えないいくつかの分野で「バイブコーディング」をしているけど、専門知識がない分野でも楽しめるんだ。そして素晴らしいことに、LLMはどんな分野でも人間の知識の頂点に近づけようとしてくれるから、アマチュアとしてはそれを体験できるのが信じられないほど素晴らしい。

とはいえ、バイブコーディングがあまり理解せずにソフトウェアを作るプロセスなら、自動プログラミングは高品質で、製作者のビジョンに厳密に従ったソフトウェアを作るプロセスで、AIの助けを借りてるんだ。彼はここで完全に正しいと思うし、この記事で彼は未来のソフトウェアエンジニアリングの方向性を「形作った」んじゃないかな（実際にもう起こってるけど）：私たちはコードを書く新しい方法にどんどん近づいてる。今回は本当にね。これがどんどん標準になっていくと思う。昔は建築家がすべての詳細を手描きしてたけど、今は多くの作業がパラメトリックソフトウェアやCAD、BIMに委ねられてる。建築家は「描く量が減った」わけじゃなくて、彼らの仕事の価値が変わったからなんだ。この概念は最近のOpus 4.5や5.2-Codexの登場でよく繰り返してきたけど、ここでantirezがうまく形を整えて、単なるバイブコーディングとは明確に区別したのは良かったと思う。私にとっては、これは根本的に異なるアプローチだからね。