時間ある時に読もうと思っていた『Beyond Vibe Coding』ですが、結局時間ある時というのは来なくて、翻訳が出たのを知ったのでついに読みました。結局母国語で読んだら数倍のスピードで読めるのでROIは悪くなさそうなんですが、一方でこの1年くらい私がウンウンと考えていた問題がすでに言語化されていることを知り、もっと早く読んでおけばよかったとも思いました。やはりAI関連の書籍は今は原文で読む時間をまとめて取るべき、という結論になりました。
さて簡単に本書から考えた内容を記しておきます。なお、Claude CodeやCodexのようなコーディングに使用するエージェントのことは、AIではなく「コーディングエージェント」ないしは「エージェント」とこの記事では呼ぶことにします。ところで面倒な話ですが、一般的なLLMやAIに対する議論に言及する際はそのまま「AI」ないしは「生成AI」と言います。
- 開発者はコーディングエージェントの出力結果をオーケストレーションする方向へ
- 一方でAIの出力する結果は一般解であり、最適解ではない
- やってくる現実は全自動化ではなく拡張（augmented）
- そういうわけで、基礎が大事
- 気になりポイント: 翻訳について
- まとめ
開発者はコーディングエージェントの出力結果をオーケストレーションする方向へ
我々開発者の役割は、今後コーディングエージェントの出力結果をチェックしたり、コーディングエージェントが変な方向へ作業を進めて行った際に途中で軌道修正したりといった、「オーケストレーション（調整）」が主な役割に変わっていくと言います。これはすでに多くのコーディングエージェントを活用している開発者が体感していることだと思います。自身でコードを書く場面は日々の開発においては大幅に減り、コーディングエージェントの出力するコードを見て、一度差分を受け入れたのちに気に入らない部分や誤っている部分を少し直すという作業を繰り返す開発スタイルに変わってきているはずです。
近頃のエージェントはかなり自走力が高まってきており、ほとんど調整作業を必要とせずともタスクを完結できることすらあります。コーディングの途中でコンパイルエラーを見つければ勝手に直していますし、自動テストが通らない箇所があれば自己判断で直している様子を見ることができるはずです。調整の必要度合いはモデルの進化によってさらに減る可能性が高いと私は考えています。たまにAttention機構の限界からかポカミスをすることはあるものの、やはりこれも時間の問題で解決されていくのだろうと思います。
一方でAIの出力する結果は一般解であり、最適解ではない
AIの出力する内容は、その作りの仕組み上「多数派の解決策」です。これはLLMの機構の原理によるものです。出力する結果が必ずしも、我々の現場の文脈や目の前のタスクの文脈に合致しないことがあります。出力結果が一般的には正しいものの、目の前の事象に対しては最適ではないケースがあるということです。私も計測したことはないので分かりませんが、一般解で済む作業と最適解が求められるタスクがどの程度日常の仕事の割合を占めているかはわかりませんし、その前提にもよるところはあります。が、出力結果はあくまで「一般解」であり、我々の「これで行ける」という「判断」があって始めてコーディングエージェントとの協業は成り立つのだと理解するべきです。
大量のコードでトレーニングされたAIモデルは、多くの場合、そのトレーニングデータで最も代表的な解決策（あるいは、適合する最も単純な解決策）を作成します。私は、これを「多数派の解決策」効果と呼んでいます。それは一般的には正しいですが、あなたの特定の状況には最適ではないことがあります。 5章 生成されたコードを理解する：レビュー、改良、所有 - バイブコーディングを超えて ―AI時代を生き抜く開発者の未来 [Book]
私たちが普段生成AIやコーディングエージェントを使用する際には、AIの出す一般解をさらに解釈して「私たちの側の文脈」と照らし合わせ、「この成果物は現状最適だから使用すべき」と選択していると言えるでしょう。あるいは、「この成果物はXXXというコーディング規約を満たしていないから、少し修正を加えるべき」という判断をしているかもしれません。何かしらの「べき」、つまり価値判断を入れているのです。
ここで注意しなければならないのは、一般解をそのまま使用したとしても、仮に「使用すべき」と判断した場合、私たちは常に価値判断をしているのだということです。言い換えれば、積極的に反対する理由がないという価値判断を加えていると考えることができるのです。逆にいうと、「XXXという理由で最適である」「YYYだから使用すべき」という価値判断のない成果物は、残念ながら採択の価値があるとは言えません。なぜならここには価値判断が含まれておらず、私たちの文脈を満たしていると言えないからです。価値判断をしたかどうかは、これから日頃の開発で問われるべき「問い」になるでしょうし、そうあるべきなのだとすら考えています。
したがって、引き続きオーケストレータである私たちによる出力結果のレビューはなくならない可能性が高いです。仕事の流れとして、コーディングエージェントの出力を得た後、必ず私たちの仕事や開発現場の文脈に寄せるという作業が必要になります。ここには「正しい」「正しくない」の「価値判断」が発生します。「最終的なコードの責任は開発者であるあなたにある」と本書でも強調されています。生成されたコードの品質を適切にジャッジし、コードを適切に既存のコードベースに適合させていく必要があるのです。
今後の人間の開発者の仕事は、コーディングエージェントの出力結果という一般解に対して、さらに価値判断を加えて自分たちにとっての最適解に変えていく方向に変わっていくのでしょう。そうした状況下にある場合、AIの出力結果をそのまま持ってきて、「AIがそう出してきたし言ってきたから正しいと思う」というのは論拠に欠ける話だということもまたできるのではないでしょうか。なぜなら、「AIがそう出してきた」という事実を論拠に据えているだけで、何も価値判断を挟んでいないからです。[*1][*2]
もちろんたとえばコンテキストエンジニアリングを用いて、ある程度こうした一般解すぎるコーディングエージェントの出力結果を、現場の文脈に沿った最適解に寄せていくことはできます。コンテキストエンジニアリングによって出力結果のレビューの労力や負荷を減らしていくことはできるはずです。コーディングエージェント時代のコーディングではこのような流れに確実に変わっていくため、コンテキストエンジニアリングはできる限り今のうちからしっかり取り組んでおきたいものです。
やってくる現実は全自動化ではなく拡張（augmented）
本書の主張する現実は、コーディングエージェントによるコーディング作業の全自動化ではなく、エージェントたちとの協働であると言えます。ペアプログラマーやアシスタントの意味合いが近いと言えるでしょう。小規模なプロダクトであれば、かなりの割合で自動化してコーディングさせる「バイブコーディング」も可能かもしれませんが、私が仕事で使っている限りではまだまだ完全自動化までは行き着いていません。思うにこれは現行のLLMの仕組みから来る特性––導き出される答えが一般解であるという点に、原理的な困難さがあると思われます。
現段階での現実的なコーディングエージェントへのスタンスは、我々の能力を拡張する存在として扱うというものだと思います。英語圏ではこれをaugmentationとか、augmentedなどと形容することがあります。この単語には、価値や力、量を高めるという原義があります。単なるincreaseなどではなく、対象全体を強化したり、機能や価値を底上げするといった意味合いがあります。コーディングエージェントというのは私たちの力を高めたり、チーム全体の生産性やコーディングの品質を底上げするものと捉えるのが良いのでしょう。
ソフトウェアエンジニアの仕事は引き続き完全に奪われてしまうことはないのでしょう。これは実際に仕事でコーディングエージェントを使いながら作業をしていても感じる肌感と近いものがあります。全自動化されてすべての仕事が奪われるかというとまだそうでもなさそうです。コンテキストエンジニアリングが大幅に進むとか、マルチエージェントの性能がさらに向上するかなどすれば状況は変わるかもしれませんが、結局「文脈への適合」つまり最適解の追求との戦いは実は永遠に避けられないのでは？と思わなくもないです。
仕事を奪われることはないものの、一方で仕事のスタイルは大きな転換を迫られています。エンジニア一人当たりの生産性は高まり、ソフトウェア開発に必要な人員は相対的に減るのでしょう。私自身も時間単位あたりの生産性は確実に底上げされたと思いますし、「何をどう作るか」にフォーカスする時間がかなり増えました。そこにフォーカスして明文化しないと、コーディングエージェントに材料を渡せないからという構造上の理由が大きいのですが。そして、自然言語で指示を出し、出力結果の妥当性を確認し、最後に少しだけ手直しするというスタイルに仕事の仕方が変わりつつあります。
そういうわけで、基礎が大事
これは本書でも改めて強調されていることでもありますが、そういうわけでエンジニアリングにおける基礎力は引き続き重要です。なぜなら、エンジニアリングの作業は全自動化されず、私たちの仕事内容はむしろ出力結果を調整したりレビューしたりする方向に変わっていくからです。とくに調整とレビューには、高度なエンジニアリングの知識や判断が求められます。何よりそうした調整やレビューを導く出力されたコードの理解にも、一定程度以上のプログラミングに対する知識が求められます。シニア以上のソフトウェアエンジニアがコーディングエージェントをとても上手に使いこなすという話は本書でも記述がある通りで、シニアの力はかなり増強されています。知識や経験が多く、適切にエージェントを導けるからです。
とくに目の前の問題領域を深く理解することや明確な仕様を書くこと、厳密なテストと妥当性の確認を行うこと、ないしはユーザーのニーズに焦点を当て正しい方向での開発を行うことといった最も基本的なスキルは重要だと本書は指摘します。曖昧さや不明確さは、コーディングエージェントによる超高速な作業によって、むしろ発生頻度は増え、間違った際の被害はかなり早いスピードで増幅することになるからです。コーディングという限定的な文脈で語るなら、よろしくないコードが手本としてエージェントにより高速でコピペされる状況を想像すれば、初期段階で手を打つ必要性を認識できるでしょう。
ではこの状況で、これから業界に飛び込むであるとか、経験年数のまだ少ないソフトウェアエンジニアはどうすればよいのでしょうか？私個人の意見としては、引き続きコツコツ目の前のことを従来通りやるが正解なのではないかと思っています。
加えて基礎力の習得時にかかる時間の圧縮は見逃せないアドバンテージになるでしょう。これから基礎を学ぶタイミングにいる方々は、生成AIを十二分に活用して高速でいろいろキャッチアップできるのだろうなと思います。コーディングエージェントや生成AIが私たちの能力を底上げする存在とすると、augmentation性を活用しないわけにはいきません。AIを使ったコードベースの理解の高速化や、デバッグの高速化などを十分期待できますし、壁打ち相手として何より最高のパートナーです。シニアがそこに行き着くまでに10年かかったものを、3年や5年で習得できてしまう時代がくるかもしれません。なので高速で一人前になってしまいましょう。
ちなみにですが、本書では下記のスキルが大事であるとリストアップしてくれていました。見るとわかるように、これらのほとんどは従来も重要なスキルだったはずです。追加されたのは「AIを使う」という項目だけなのです。
- システム設計とアーキテクチャの専門知識を強化する
- システム思考を実践し、全体像のコンテキストの理解を維持する
- 批判的思考、問題解決、先見性のスキルを磨く
- 専門ドメインにおける専門知識を築く
- コードレビュー、テスト、デバッグ、品質保証を行う
- コミュニケーションと協働のスキルを向上させる
- 変化に適応する
- 継続的に学習し、基礎を固めながら、新しいスキルを身につけ、知識を更新する
- AIを使う
本書ではジュニアやミドルのようなソフトウェアエンジニアに対するアドバイスも載っており、それらも参考にしながら自身の直近のキャリアの方向性を決めるとよいと思います。これまで以上のスピードで、これまで通りまずは知識をつけ、高速な出力を見ながら判断や感覚を養っていきましょう。
気になりポイント: 翻訳について
さて、今回は少し翻訳について突っ込んでおくべきと思ったので書かせていただきます。私も経験があるのですが翻訳という作業はとても大変ですし、そもそも出版に携わること自体すばらしいことだと思っているという前置きをしつつ、翻訳の気になった点をいくつかあげておきます。ちなみにですが、ところどころ気になるというレベルで、文章の意味が壊滅的に通らないということはまったくないです。
ひとつは訳語の適切さに関する疑問です。2章のタイトルである"The Art of the Prompt: Communicating Effectively with AI"の翻訳についてです。これは「プロンプトの芸術：AIと効果的にコミュニケーションする」と訳されていますが、個人的な意見としては「プロンプトの技芸」ないしは「プロンプト技術」だろうと思いました。artという単語は元々はラテン語のars由来で[*3]、さらに遡ると古代ギリシャのテクネーという概念と対応することがあります。さまざま説はありそうですが通説としては、我々の通常思う美術や工芸品関連の「芸術」という言葉[*4]と、技法の意味合いの「技芸」の両方の意味が英語のartに合流したと言われています。このチャプターの中身はプロンプトエンジニアリングに関する話であり、エンジニアリングは技術なので技術文脈の単語を割り当てるのが正当なはずです。
もう一つはそもそも意味の通らない箇所の存在です。これは単純にチェック漏れだと思いました。たとえば5章に「Yes, AI can make those, too.」という文章がありますが、この翻訳は「はい、AIもそのエラーをすることがあります」でした。このように単体の文章として読んでもそもそも意味がわからない上に、実際に本書における文章の流れを考慮したとしても全く意味が通りません。おそらく機械翻訳を使用したのだろうと思いますが、使用したツールが生成AIではなさそうな感じがしてしまいます。他には「You」を常に「あなた」と翻訳しているなど、いささか直訳調すぎる訳文も気になるところです（確か8.4節でとくに顕著に気づいた）。主語部分は翻訳の入門書などでも、文脈から明らかな場合はカットするようアドバイスが載っていたりします。正直なところ編集者が把握しておくべき話だと思います（出版社側の翻訳のルールを知らない状態で書いています）。
書籍というのは著者一人によって成立するものではなく、編集者や編集部の細かいレビューによって成り立つ協力プレーのようなものです。なので、著者一人の責任に帰することはできません。翻訳の質は、そうした組織的な取り組みによって決まってきます。
世は大AI時代ではあるもののせっかく商業出版として出すのですから、「AIの翻訳で十分だよ」と言われないクオリティのものが出版社から出てくることを読者の多くは望んでいるのではないでしょうか。組織的な力によって担保される質の高さが、人間による翻訳の価値を決めるのではないでしょうか。これが商業出版の優位性だったはずです。そしてそれこそが、生成AI時代において翻訳書とAI翻訳との差を決めるのではないでしょうか。
書籍の中でも言及があるように、生成AIの出してくる答えというのは「一般解」です。編集が追求しなければならないのは、一般解の先の「最適解」です。編集がここをおろそかにしてしまうと、編集が存在する意味がなくなってしまいます。[*5]
まとめ
全体的にはおすすめできる一冊なのですが、翻訳にやや難ありというのが正直な感想です。ただ、ソフトウェアエンジニアの経験年数によらず、今起こっている現実と先の変化を見据えるために一度は読んでおく価値のある一冊だと思いました。
一方で将来起こる技術革新の成果次第では、この記事の内容も前提がひっくり返ってしまうでしょう。たとえばコンテキストエンジニアリングが超絶進化して、プロジェクトに携わる人や会社全体の人の脳内の情報を全部ダンプできるようになるとか、現在のTransformerやAttentionを起点としたLLMではない別の革新的なモデルが出てきたケースなどが考えられます。この記事の感想やおそらくは本書の暗黙の前提は、あくまで現行のモデルやコンテキストエンジニアリングの仕方であるという点に注意が必要です。
ただし、「起こるかもしれない」ことに賭け事をしていても仕方がありません。今すべきことは新しい現実への対応です。人の想像力に賭けて自身の行動を選択すべきではないと多くの哲学者や思想家も諌めてきた通りです。[*6]
*1:この辺りは哲学的な議論ができるかどうかの検討を私が個人的にしている段階ですが、念頭にあるのはヒュームの「is-ought問題」です。この問題は、「事実（is; である）」から「規範（ought; べき）を論理的推論のみからは導き出せないというものです。規範を導き出すには、事実を知ったのちに「情念」や「価値選好」（好きか嫌いかとか、快不快とか）が必ず裏の論拠として存在するとヒュームの体系では語られます。代表的な議論としてはプログラミング言語の優劣に関するものが挙げられるでしょう。どれほど対象となるプログラミング言語に対する知識を積み重ねていったとしても、最後の採用す「べき」理由の決定打にならないことが多いです。その規範的な判断の裏側には、最後の好き嫌いをはじめとする価値選好が必ず挟まれているものです。そしてそれ自体は否定されるべきものではなく、規範を導き出す性質のようなものだということなのです。やはり同様に、コーディングエージェントの出力結果は「事実」つまり「is」であり、ここからすぐさま「規範」つまり「ought」を導き出すのは難しいのではないか？と私は考えています。ヒュームの著作は正直あまり読んだことがなくさわりだけしか知らない状態で書いており、この脚注の言明はあくまで仮説ということになります。
*2:同様にヒュームとLLMとの関連で言うと、ヒュームの「恒常的連接」という概念もなかなか興味深いです。この概念はヒュームの因果関係に関する分析の文脈で登場するものです。こちらは主題からは外れるので詳しくはこうした資料を参考にしていただきたいですが、私が思うにAI時代のディスカッションにおいてヒュームは古くて新しい哲学者になりうるのではないか、と思っています。この概念は人間の思う因果関係というものには実在性はなく、実は単なる反復性を根拠とした人間の「習慣」的なものによって成立しているだけではないか、ということをすっぱ抜いています。これはLLMの出力結果の「事実」的な側面の論拠となりえるのではないかと考えているのです。
*3:「Ars longa, vita brevis」というラテン語の格言があります。このarsは芸術と訳されることは多いようなのですが、ヒッポクラテスが語ったことから文脈としては「医術」の意味合いであり、これはつまり技術側のことを指しています。Ars longa vita brevis. 芸術は長く人生は短し – 山下太郎のラテン語入門。私は「芸は長く、生は短し」などと訳す方がよいと考えています。
*4:実のところ現代人の持つ「芸術」という感覚自体、近代に発明された概念であるという説明をする美学の入門もあるくらいです。なので、こちら側の意味合いは実は後発だったりします。
*5:私のこれまでの経験からいっても、編集側がどれくらい原稿に目を通すかはわりと編集者によります。なので指摘しています。
*6:思いつく限りだとアランの『幸福論』の中に、人の想像力に関するいくつかの言及があったように思います。
