LLM時代の仕事
いちプログラマである僕の視点では、現在の世界はAIに熱狂している。
特にLLMを使ってコードを書かせるばかりか、その先のデバッグまでLLMに任せる時代はもう少し先だと思っていたら早くも登場して世間を沸かせている。
ソードアートオンラインのように「システムコール」と前置すればただの単語予測器にできる範疇以外の事にも手を伸ばせる事はわかっていたが、LLMがこんなに早くその「システムコール」を操ってものを動かせるという直感を持ち合わせていなかったのを恥じるばかりである。少しシリアスにLLMの出力をチューニングしようとした人ならわかると思うが、LLMが真にすごいのは知識を貯めておける事というよりパターンに従うのがとんでもなく上手いと言う事である。
プロンプトチューニングで「あなたは○○の専門家です」などと入れるロールプレイングは出力の品質を大きく改善しない、といった話は有名であるがそういう数あるチューニング手法の中でfew shot learningはホンモノである。すぐ目の前で例示された物をパターンに合わせて模倣することはLLMのベンチマーク種目のひとつなのかと感じさせるほど上手い。ドラクエの攻略本を通読させたLLMの目の前で「システムコール・メラ！」と火球を出して焚き火をつけるデモンストレーションを見せつけさえすれば、即座に「システムコール・イオナズン！」で地図を描き変える応用力がLLMにはある。
AIエージェントと呼ばれるものがMCPコールでやっている事はこれである。コードを書き換えるMCPコールやコンパイルするMCPコールまでは想像できたがエラーメッセージを読んで次の手を打ち始めてしかもそれでおおよそ上手くいくというのは「偉そうなことを言っておきながらプログラマがやってる事もおよそパターンマッチングの連続に過ぎなかったんじゃないの？」という現実を見せつけられたかのような気分である。しかしながら試行錯誤を重ねるエージェントの働き振りを見てもなお、人とAIとの差分はまだまだ考えさせられる物がある。
構造とは理解
現代社会において真に価値あるものは、しばしば高次元に積み重なった「構造」として尊ばれる。空気の振動に過ぎない「音」が、一定の法則（構造）に従って構成されることで意味を持つ「言葉」となり、さらに別の法則によって「文章」を構成する。そして文章は、それ自体とは異なる次元の法則によって「論文」や「小説」といった作品、すなわちより複雑な知的構造物へと昇華される。この構造の積み重ねこそが、知的な営みにおける「力」の根源である。
我々が書くこの文字列も、言ってみれば一次元に並んだ情報の羅列に過ぎない。しかし、その背後には筆者が思い描く論理の構造が潜んでおり、それを読者の頭の中で再構成することを期待して書かれている。この「高次元の構造を伝達する力」こそが、思考の共有と発展を可能にする。
プログラミングのコードも関数とかクラスとか変数とかモジュールとかをルールに従ってコンパイラが認める範囲で記述する必要があり、高品質なソースコードはLLMを学習させる際の教師データの一種として、なんとプログラムを書かせる目的でないLLMにとってすら有用であるという研究成果もある。
物事を記述する際、それが絵であれ文章であれ、その品質は思い描いている構造をどこまで正しく描写できているかに懸かっている。AIが人を描かせた時に指が6本になったり腕が3本生えたりするのは、二次元の情報から三次元の人体構造を正確に「理解」し、描写できていないことの典型例だ。人間の網膜は所詮二次元の情報しか得られないが、そこに時間的・空間的連続性を伴った情報処理が組み合わさることで、脳内には三次元の物体を思い描く力が備わっている。これは、断片的な情報から背後の構造を再構築する能力に他ならない。
文章においても同様である。人が説明した内容を別の語彙で噛み砕いて説明し直せる能力は、「理解」の核心を示す良い基準となる。単なる丸暗記や文法レベルの言い換えでは、真の理解とは言い難い。初対面の人間とでも深い話題で「理解し合えた」「打てば響く」と感じられるのは、自分が説明した概念や問題意識といった「構造物」が、相手に正しく伝わったと感じられた瞬間だ。絵で例えるなら、ある立体物の三面図を見せたときに、相手がその立体物の斜め上から見たスケッチを描いて返してくれたならば、その立体物の構造が伝わったと実感できる。
構造をよく理解したLLMからは6本指を描かない画像生成AIのように高品質なアウトプットが期待できる。それが模倣の力と結びついて、人類に新たな構造を提供する未来は少しずつ近づいている。新たな高次元知的構造物を作り出すのは人類の専売特許であったが、LLMがその高次元な概念を模倣できない理由はない。小説を1本書き上げるのは人類にはひと仕事だがLLMにはただの計算である。
理解とは描写
物事を理解することはその背後にある「構造」を認識することに等しい。そして、この構造の理解を示すシグナルとなるのが「描写」である。LLMを真に賢くするには、ただ大量のテキストを読み込ませるだけでは不十分であって、LLM自身の生成するテキスト情報だけではその内部に閉じた世界観の中で学習の限界に達してしまう。必要なのは、LLMにとってある種「意外」な情報、すなわち、既存の知識体系を揺さぶり、新たな視点や側面を提供する情報である。
しかし、その「意外」さの極地である乱数列がLLMの学習に役立たないのは明らかだ。それは意味や構造を一切持たないからである。では、どんなテキストが有効なのか。それは、多様な概念を多様な角度から描写したテキストに他ならない。人間の網膜が、異なる角度から投影された二次元の情報（描写）を統合することで、脳内で三次元の立体物を構成できるのと同じように、LLMもまた、一つの概念について多角的に描写されたテキストの山を「極上の食事」とすることで、その概念の構造を高次元で"理解"していくのだ。
"理解"とは何かという問いは、古くから多くの哲学者が問い続けてきた難問であり、いまだ合意された完全な答えは存在しない。しかし、外部から観察する限りにおいて、「理解している」と「理解しているように見える」の間の区別は不可能である。LLMにとっての「理解しているように見える」とは、こちらが要求する角度と精度で概念を描写し直してくれることに他ならない。例えば、2次元の画面を通した会話であっても、目の前の相手がこちらの指定する立体を指定した角度で適切に描写して表示してくるならば、画面を通したやりとりに過ぎなくても、その立体に対する深い理解があることを認めざるを得ないだろう。人間もまた、無意識のうちにそのような「描写のやりとり」を会話を通して行うことで、共同で複雑で高次元な物事の輪郭を浮かび上がらせ、相互の理解を深めている。
LLMが多様な描写から構造を"理解"し、それを新たな描写として出力する能力は、まさしく人間の知的活動を模倣し、時に凌駕する可能性を秘めている。この「理解に基づく描写力」が、AI時代における新たな価値創造の起点となる。
デバッグとはバイク修理
さて、AIエージェントによるプログラムのデバッグもまた、ある意味では問題意識であり「構造」である。音はどんなに大きくなっても大きさだけで単語を構成できないのと同じで、エージェントがコンパイラから得るテキスト情報から次の手を得る手段というのは、どんなに長くなってもそれ自体は高度化し得ない。大切なのはその背後にある「構造」の理解である。壊れたコードを直す時、プログラマはそもそもの問題意識の起源からあるべき解決策のスケッチまで、無意識に道筋を立ててその「構造」に沿ってデバッグを行う。しかし、AIエージェントは目の前の問題を解くことだけを考えた「構造のないテキスト生成器」を脱しない限り、コケたユニットテストを削除することでユニットテストが全パス！のような愚行を平気で行う可能性がある。これは単純に、解くべき問題の「構造」への理解が足りないことによる弊害だ。
AWSのKiroなんかは依頼されたタスクに対してまず構造化を試みて段階的に問題を解決しようとする、仕事に必要なのは構造の細分化と細分化され尽くして必要最小限まで削ぎ落とされたコンテキストに対する最良のアウトプットの両輪である。最近の生成AIが手づかみでラーメンを食べるのを止め指を正確に5本で描くようになってきたのと同じように、AIエージェントも与えられるタスクの中から効率的に構造を見つけ出し投入されるコンテキストをその構造に沿って取捨選択して人並みに働くようになるまでにそんなに時間はかからないと見ている。
LLMが動かせる手と出力を得る目、そして考える頭を持っているのであればそこで実施できる人類の究極奥義は科学的実験である。僕の好きな本『禅とオートバイ修理技術』にはいつも重要なことが書いてある。引用する。
だがもし混乱するようなことが出てきたら、そのときは焦らず客観的に見直してみることが肝要である。生じた問題を一つ一つ書きとめるという行為は、混乱した頭をもとの整然とした状態に戻してやることになる。
ノートにはあくまで論理的な記述をする必要があるが、分類するとすれば、それは六つのカテゴリーに分けられる。(1)問題点の記述、(2)原因の仮説、(3)各仮説をテストするための実験、(4)実験結果の予想、(5)実験結果、(6)実験結果から導かれた結論、以上の六つである。これは大学や高校で研究ノートを作るやり方とまったく同じだが、その目的は、単なる見せかけの仕事を行う事ではない。ここでの目的は、失敗を導きかねない誤った考え方を、正確に処理することである。
これはバイク修理中にぶち当たる問題を例に科学の知的手順について説明しているのだが、ここにこそ科学哲学史に跨って言える真理がある。科学とは試行錯誤を書き下す事で誤りに対処するという手続きの積み重ねであり、現在のLLMによる試行錯誤が欠いているピースである。つまり、試行錯誤にも構造があり、その試行錯誤サイクルを回すことととそのサイクル自体の知的欠陥を見つけることの2つを行う必要があるのだが、LLMによる試行錯誤においては経験則によって素早く実験を回してはいるが問題に対して構造的に対処しているようには見えないのである。
さて興味深いのは、試行錯誤は特にプログラミングの文脈に限って言えばコードの書き換えやコンパイルは材料費も物理制約もほぼ存在せず自動で無限に試行錯誤を重ねても良いので力技でサイクルを回すうちに答えに辿り着くこともあるが、オートバイ修理においては例えば常にエンジンを完全に分解したり怪しい部品全交換などはしていられない、(1)の仮説は惰性でいくらでも列挙することはできるが、(3)に相当する実験はどう足掻いても非自明なクリエイティビティが必要となる。なぜなら物理的制約の中で*実行可能*な実験を設計しなくてはならないからだ。オートバイの電気系統が死んでないかを確かめるためにホーンを鳴らしてみる、というのが科学的実験のいち手順として紹介されているが、その実験の良いところはホーンを鳴らすために必要な手順にコストがかからない点である。オートバイの修理屋は無意識的にも問題を切り分けるためにありそうな故障箇所の候補と実験のコストの安さとの兼ね合いから効率的に問題を見つけているのだ。プログラマは例えば思慮深くprintfをコード中に仕込むことで問題の現状を確かめようとするが、今のエージェントは僕の見る限り意識してそういう知的サイクルの中にいるようには見えない。とはいえ時間の問題だろうと思っている。
「最も効果的なデバッグツールは依然として、思慮深く配置された print 文に伴った注意深い考察である」 — Brian Kernighan, Unix for Beginners
もちろんprintfでなくても問題の性質に応じてユニットテストとかデバッガとかトレースといったさまざまなツールが我々プログラマの工具箱にはある。こういう科学的プロトコルに沿った知的構造物との向き合い方についてLLMはいずれ学び、そこに依頼を渡すプログラマのに求められる「思慮深」い仕事というものはさらに高次元なものになる日は近い。
デスクワークとは構造の応用
さて、総合職の仕事というものはよくPDCAサイクルを回すものとされている。Plan Do Check Actionの頭文字を取ったものであり、軽く検索しても時代遅れだとかこれからは○○サイクルだという話などが次々出てくるが、結局のところ、その仕事の仕方が志向しているものは「世の中は思った通りには行かないが、計画と実行結果の差分から学ぶことで次の手が立てられる」という科学的実験手続きのサブセットである。これはすなわち、目標達成に向けた「構造」を設計し、実行し、その結果から「構造」を評価・再構築する営みに他ならない。
典型的な世の中のオフィスワーカーがやっていることは、物理的にはワード・パワポ・エクセル・ブラウザをいじることである。これらは間違いなくMCPの操作対象物となる。さらには、それらが生み出す情報を統合し、上位構造であるPDCAサイクルという雄大な科学的実験の一端もLLMにオフロードされてしまう時、人間が本当にやるべき仕事とは何なのかという問いはじわじわと我々に迫ってきている。
PDCAサイクルがうまく回らない「あるある」事例というのは、大抵Planが悪い。科学実験でいうところの「実行可能」な実験を設計し損ねてPDDDDDDDDD....と終わらなくなるのは、計画段階での「実験設計」に欠陥があることが多い。つまり人間ですら仕事を上手い科学的手続きで回すことは決して自明ではない。しかし、LLMが自動で実行可能な実験を設計してくれるようになる未来はそう遠くないと見ている。
もちろんAIによる提案なんて受け入れないという立場もある。だが人類の産業がより洗練された知恵によって塗り替えられるのは、大局的には変えられない流れだ。大学で科学的手順をきちんと学んでこなくても、逆に知的サイクルの「構造の力」をLLMが人間に押し付ける、あるいは取って代わるようになってからが本番である。人間は、AIが提示する「構造」を理解し、その上でAIには見出せない、あるいはAIには創造できない、より高次元な「構造」を発見・設計することに注力するようになるだろう。デスクワークの未来は、単なる作業の自動化に留まらず、人間が「構造の創造者」としての役割を深める時代となるのだ。
PDCAサイクルというのは一例に過ぎず、さまざまな仕事のフレームワークというものは存在しておりビジネス書を手に取ればさまざまなことが書いてあるが大抵は概念的に応用するのが難しく人類はそれらを自分の仕事に活用するために十分な知的リソースを有していない。
https://www.soumu.go.jp/main_content/000731625.pdf
総務省による「自治体におけるRPA導入ガイドブック」というものが公開されているが、事例を眺めるに日本の地方自治体において機械による自動化の余地は大きい。RPAはGUIの変更に弱いと言う欠点もあったが、オフィススイートやブラウザがMCPサーバで操作されれば細かい差分はLLMの柔軟性によって吸収されることになり、ゆくゆくは窓口で日本語で何か言うだけで必要な決裁資料の束が完成して確認だけを求められるようになるだろう。
ソフトウェアエンジニアリングとは文化
LLMが難しいコードを一瞬で書いてくれて、試行錯誤すらも自動でやってくれるからといって、ソフトウェアエンジニアの仕事が消滅することはない。なぜなら、ソフトウェア開発とは単なるプログラミング作業ではなく、常に変化する世界に対応するための「仮説」を立て、それを検証する壮大な「科学的実験」だからだ。LLMのない時代には、この仮説を検証するための「Do」（実行）のステップがコード記述のボトルネックとなり、全体のサイクルを滞らせていたに過ぎない。もし1ヶ月かかっていたコードが1日で書けるようになったのなら、我々は書くべきコードの量を20倍にすべきなのだ。ボトルネックを解消すれば別の場所にボトルネックが移るものであり、最終的にそれで書くべきコードがなくなってしまったのであればそれは失職しても仕方がない。しかし、人類のアニマルスピリットはさらなる利益を求め、より大きな「仮説検証サイクル」（PDCAサイクル）を回し続けるだろう。仮説の量が20倍にならないのであれば、その「仮説」自体をLLMに依頼して考えてもらっても良い。この陰でこっそりと失職するのは、LLMとうまく付き合う術を得られなかったプログラマだけである。だが気にする事はない。パンチカードを開けるだけが好きでプログラムを書くのが嫌いだった人はパンチカードと共に歴史に消えた。それと同じことが再び起きたに過ぎない。
もっと言うとそもそもソフトウェアエンジニアの仕事はプログラミングだけではないのだ。ここで「Googleのソフトウェアエンジニアリング」という本には繰り返し読み返したい名文がある。
ソフトウェアエンジニアリングとは「時間で積分したプログラミング」とみなせる、というものがある。自分たちのコードを、着想し、導入し、保守し、廃止するまでのライフサイクルを通じて持続可能（sustainable）なものとするためにコードに導入できるのは、どんなプラクティスだろうか。
これはつまり、単なるコード記述という「瞬間的な力」の積み重ねではなく、自分たちのコードを、着想し、導入し、保守し、廃止するまでのライフサイクルを通じて「持続可能な構造」として維持していくために、時間軸で導入できるあらゆる「プラクティス」（習慣や仕組み）の総体、すなわち「文化」そのものを指す。ウェイトリフティングの競技はそれ自体立派なものだが、運送屋の仕事はただ重いものを持ち上げるだけでは終わらない。そこ（持続可能性や全体の流れ）の差分にこそ、我々ソフトウェアエンジニアの食い扶持があるのだ。
今、この世界にはLLMという「瞬間的な力」に対してとんでもない潜在能力を持つ重機が導入されつつある。しかし、現場作業員たる我々がするべき事は、その重機をどう「文化」に組み込み、より大きく、より信頼できるソフトウェアという「構造」を成し遂げるかである。パワーショベルにリフティング競技で負けたからといってしょげている暇はない。
よく大変なプログラマの現場の例として勘定系のCOBOLが槍玉に上がり、それらを書き換えて近代化したいというのは口々に言う一方で、LLMが一発で書き換えたモダンなコードとやらを誰がメンテするのかという疑問に対する回答はない。コードとは書いて終わりではなく、動き続け、柔軟に変更を受け止め続けて初めて「命」が吹き込まれるのである。この「命」を吹き込み、維持する手助けをLLMがしてくれること自体は明らかだ。しかし、結局ビジネスとの接点の隅々まで目配せし、ソフトウェアという「構造」の「血の巡り」を監視し、その持続可能性を担保するのは、人間が構築する「文化」の仕事なのである。直接的な言葉で言い換えると、ソフトウェアエンジニアリングの心得のないビジネス側の人間にどうにかしてシステムの隅々まで納得させ、変化に耐え、書類の耳を揃え、証拠を残し、法令に準拠し、それをシステムに反映させる血の巡りはソフトウェアエンジニアの集団による絶え間ない努力の結果である。それを丸ごとLLMが置き換えるのはまだまだ先の話になるだろう。
まとめ
さて、僕自身長文をつらつら書いて何が言いたいのか自分でも錯乱して来たので早速LLMを召喚してその知的能力をご披露いただこう。Gemini2.5 Proに上の文章の結論をまとめてもらうと以下である。
AIの真価は、知性の本質である「構造」を理解し、創造する能力にあります。
今後、AIがデバッグや業務プロセスといった構造的なタスクを科学的に実行するようになるため、人間の仕事は変化します。
これからの人間の役割は、AIにはできない高次元の「構造」を設計・創造することです。特にソフトウェアエンジニアの仕事は、単なるコーディングから、ソフトウェア全体の持続可能性を担保する「文化」を築くことへとシフトしていくでしょう。
うーん、まだ改善の余地はあるな。
