0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

千里の道も0歩でGO。LLM Wiki時代に揺らぐ「つよつよエンジニア」道場

0
Posted at

道場破りAIがやって来るヤァ!ヤァ!ヤァ!

안녕하신게라!パナソニック コネクト株式会社クラウドソリューション部の加賀です。

いい時代になりましたね。Andrej Karpathy氏が「LLM Wiki」というコンセプトをぶち上げました。ナレッジベースの構築と維持をLLMにメンテさせる手法で、何もかもよしなにやってくれる便利さに膝を打つことしきり。使ううち、ふと、気になる点が。

知識の整理も含めLLM Wikiがよしなにやってくれます。過去「つよつよエンジニア」ポエムで、エンジニアのチカラは知識の整理で育つ、と書きました。この整理作業のしんどさから得られるであろう経験値「理解そのものへの経路」までもがセットでよしなに消えてませんこと?
いやいや、そこ人間がやらんかったら、どうやってエンジニアがレベルを上げるんです!?

AIが、仕事ではなく「経験値稼ぎの場」を奪っているのでは。
「つよつよエンジニア」養成道場に、道場破りAIがやって来るヤァ!ヤァ!ヤァ!
戦うのか、逃げるのか、取り込むのか、従属するのか。悩みつつ新シリーズを展開していきます。

本記事から「つよつよエンジニア」続編、 AI時代の「つよつよエンジニア」シリーズ を始めます。だいたい月1ペース(目安、AIの進化次第)を予定してます。

AI時代の「つよつよエンジニア」シリーズ

  • 千里の道も0歩でGO。LLM Wiki時代に揺らぐ「つよつよエンジニア」道場(本記事)
  • 千里のAI馬は常に有れども、伯楽は人にしか無し。「つよつよエンジニア」がこの先生きのこる3戦略
  • 千里の堤もAI蟻の一穴より崩れる。増幅される人間の善意と悪意

(過去分)「つよつよエンジニア」シリーズ

LLM Wiki ってなにやつ

作者のKarpathy氏曰く「いわゆるRAGでしんどいとこを、LLMにWikiとして編集させる」もの。

典型的なRAG(Retrieval-Augmented Generation)は、質問のたびにソースから関連チャンクを集めて回答を組み立てるので、解釈の途中で生まれた知見はチャットが終われば霧散。対してLLM Wikiは、新しいソースが入るたびLLMが既存のWikiへ統合し、エンティティや概念ページを改訂、矛盾はフラグ、参照は張り直し。ビルド済みの知識の差分を編集するので、Wikiが太るほど再利用できる整理済み知識が複利で増えていきます。

氏は「人間はソースを選び、方向を決め、良い問いを立て、意味を考える。面倒な整理や相互参照はLLMの仕事」と役割分担を示し、LLMはingest(取り込み)/query(Q&A)/lint(整合性チェック)の3つだけ。潔い。
トークン効率含めよく出来ていて、筆者も最初は素直に「すこぶる便利やん」と思いました。

レベルを上げて物理で殴れば良いのか?

便利の裏に犠牲あり。

LLM Wikiの仕組みは、RPGで例えるなら、「高レベル前提のクエスト」だけを人間に残した感じだなと思いました。経験値稼ぎである雑魚戦(=ソースを読み、要約し、構造を整える泥臭い作業)はLLMが全部やってくれて、プレイヤーに残るのはボス戦のみ。「どのダンジョンに潜るか」「ボスの弱点はどこか」「ドロップ品の価値は」といった、レベルが上がっている前提のプレイングだけが残っている印象を受けました。高レベルな周回プレイヤーには楽しいのかもしれません。

氏が人間に残した「ソースを選ぶ」「方向を決める」「良い問いを立てる」「意味を考える」は全部、高レベルであること、すなわち、経験値やエスパー力、その領域の濃い事前分布を持っていることを前提としてます。そしてその事前分布こそがLLMに譲り渡した雑魚戦から得て蓄積してきたものです。
経験値の供給源を犠牲に、高レベル前提のクエストだけ残され、ともすればレベル1のままでボス戦をさせられ、演出ではなくそのままゲームオーバー画面を見ることになりかねません。

ゲーム界隈のネタで、レベルを上げて物理で殴れば良いという迷言がありますが、それにならい、レベル1で「Wikiのまとめを読み、レベルを上げて物理で殴ればええやん」って? Yes、やりましょう、気合と根性です。まず10ページを精読、100ページもまだ見渡せます。……が、1,000、1万ページとなると、読むスピードより蓄積スピードが上回りそうです。
リニアに乗った亀を生身で追うアキレスという新ジャンルのゲームでしょうか、もうワケが判りません。経験値稼ぎが不可なゲームで、無理矢理レベル上げても通用するとは思えません。
しかも、Wiki側はLLMが無限に拡張できますが、人間側のレベルアップ速度、つまり認知の帯域には残念ながら、クォータ緩和申請がありません(そんな改造あっても困りますが)。

氏の分業設計には納得なのですが、今後、人類が良い問いを立てるために学ぶ道場はどこに? レベルの低いジュニアエンジニアは、どこで経験値を稼げば?

……これはもしかすると、白旗なのかもしれませんねぇ。

Anthropic社も同じこと感じてたっぽい

この引っかかり、実はAI開発の最前線で働く人も抱えていたようで、Anthropic社が2025年8月に実施した社内調査(自社エンジニア/研究者132名にアンケート、さらに53名に深掘りインタビュー)で "paradox of supervision"(監督のパラドックス) と呼び、AIを効果的に使うには監督が必要、しかし監督に必要なスキルはAI依存で衰える、として公開していました。

この記事の中で印象的な声をいくつか(以下、Anthropic記事より引用・訳は筆者)

  • 自分でデバッグに取り組めば、直接問題と関係ないドキュメントやコードも読むことになる。その過程でシステム全体のメンタルモデルが育つ。Claudeを使うとそこがごっそり飛ぶ。

  • アウトプットを出すのが簡単で速くなればなるほど、何かを本当に学ぶ時間を取ることが難しくなっていく。

  • スキルが錆びること自体より、AIを安全に監督する能力が衰えることのほうが怖い。

AIの当事者ですら半数超が「完全に委任できるのは仕事のうち0〜20%だけ」と答えつつ「スキルが錆びていく怖さ」を語っていました。あるエンジニアは「Claudeが解けると判っていても、たまにあえて頼まない」とも。
最前線でも困惑しながら走った地雷原を、後塵を拝する我々も、わりと気軽に入る形になりそうですね。

同記事は外部研究のMETR (2025)にも触れています。経験豊富なOSS開発者16人を対象に、課題(issue)ごとにAIツール使用可否をランダム割付したランダム化比較試験(RCT)の結果、AIを使うと開発者は「20%速くなった」と感じていたが、実際には19%遅くなっていた、という体感と実態の逆転が起きたというもの。当事者が自分の作業速度すら正しく認識できていなかった、と第三者調査がレポートしています。

念のため断っておくと、この「19%遅い」は熟練者が自分の慣れた大規模リポジトリで作業したという、AIには不利な条件下の数字です。Anthropic調査のほうも自己申告・非匿名で、社会的望ましさバイアスや選択バイアスを自ら注記しています。そのためこの結果をして「だからAIはダメ」と一般化する気はありません。それでも、当事者が自分の速度すら取り違えていた、というのは驚きます。速度すら見誤るのならば、監督するスキルの劣化はもっと気付き難いと思うのです。

……やっぱり素直に白旗を挙げるんですかねぇ。

諦めたらそこで何でしたっけ

逆に、同じAnthropic記事の中で、真逆の意見もありました。

  • 「錆びる」という見方は、コーディングがClaude 3.5以前に戻る前提に乗っている。もう戻らない。

  • スキル劣化なんて心配していない、むしろ学習が加速した。

AIで「道場が消える」のではなく、むしろ「より良い道場」になる、という主張。同記事には「学ぶスピードが上がった」という声や、「ジュニアこそ新技術に一番貪欲だから、未来は楽観的」という声もありました。雑魚戦が消えても、問いを立てて・反論させて・原理を学ぶという新しい練習手段が手に入るのなら、道場は消えてないじゃないか、という事です。

なるほど正論だと思います。AIは使い方次第で、史上最強の家庭教師にもなります。「道場が消える」わけではない。ならば追い返すより、どう手合わせして自分の糧にするかという視点が必要そうです。
しかもその手合わせに作法があるようにも思えます。「AIで学習が加速した」と言うエンジニアは、たいてい「答えがどう見えるべきか」を既に知っている高レベル者です。同記事のあるシニアも、「自分が答えを分かっている場面でAIを使う。その見極める力は、かつて手でコードを書いて地道に身に付けたものだ」と語っていました。
つまり彼らは、道場破りとの立ち合いの型を知っているわけです。「AIで加速する学習」は既に輪郭を持っている人の加速であって、レベル1からの促成栽培ではない。同じ道場破りでも、既に型を持つ者には経験値ボーナス、持たぬ者にはただボコボコにされるボス戦、という残酷な現実が見えてきます。

だとすると、こちらが取るべきスタンスも見えてきます。一本取られないように逃げ回るのではなく、まず受けの型(自分の理解の輪郭)を保ったまま、相手の技を一つずつ受け止めて検証する。道場破りAIを倒して追い返すのでもなく、使い倒して子分にするでもなく、経験値稼ぎのお手伝いをしてもらう。

また、同記事には別のニュアンスの声も並んでいました。

  • アセンブリ言語から高級言語に移ってメモリ管理を手放したのと同じで、レイヤーが一段上がっただけ。

  • ただ、抽象化にはコストもある。高級言語への移行で、多くのエンジニアはメモリの深い理解を失った。

この「コスト」の指摘が、筆者には一番しっくり来ました。高級言語でも、メモリリークやキャッシュミスを疑える人は、アセンブリを知らない人より一段深く問える。アセンブリを「書ける」必要はないが、「わかる」必要は残っている。レイヤーが上がっても、下の層を「わかる」人と「ブラックボックスのまま」の人で、問いの深さに差が出るわけです。

Karpathy氏自身もGistで「片側にLLMエージェント、もう片側にObsidianを開いて、要約を読み、更新を確認し、強調点をLLMに指示する」スタイルを好むと書いています。氏は「1件ずつ取り込んで関与し続ける」やり方を好む一方、「監督を減らしてまとめて取り込むことも出来る、やり方は自由」とも明記していて、全委任を禁じてはいないが手放しも勧めていない

どうやらここらにも、なにやら手掛かりが潜んでいそうです。

  • レイヤーが異なることを認識し、下位のレイヤーで起きていること、上位のレイヤーで起き得ることを想像できるか。
  • Wikiの生成に際し、AIに全てを任せるのではなく、1つずつ人間が見届けていくことで、Wikiの範囲を人間の理解の範疇に置いている。

突き詰めると、「自分の理解の輪郭を保ち、AIの出力を検算する」 こととなり、便利さとは真逆の方向に。
理解の輪郭を保つとは、判っている所と判っていない所の境界を自分で線引きして持ち続けること。
検算するとは、AIに出させた答えを別経路で突き合わせて、合っているかを自分で確かめること。
どちらもセンスではなく、やるかやらないかで決まる行動なので、メニュー化して鍛えられそうです。

と、ここまで読んだ鋭い方は気付いてしまいます。「その輪郭と検算、結局は理解がないと出来ないじゃないか」と。その通りです。検算する力は輪郭に依存していて、理解が痩せた人は「検算そのものが痩せている」ことにさえ気付けなくなる。これこそが"paradox of supervision"そのもので、鍛えるべきメニューが既に高レベル者向けになりつつあります。
だからこそ、順番が大事です。輪郭が痩せてから検算を始めても、もう間に合いません。まだ輪郭がしっかりあるうちに、「線を引いて検算する」習慣化をしておく。これでパラドックスが完全に解けるわけではありませんが、「気付けなくなる前に身体に入れておく」程度の、せめての抵抗にはなりそうです。レベル1で戦うのではなく、せめて今のうちにレベル10くらいになってしまおうということです。

AIを使っていても人間側が経験値稼ぎ出来るのなら、もしかしたらゲームセットにならずに済むのかも。

AI時代の「つよつよエンジニア」道場、追加メニュー

前節で見えた 「輪郭を保つ」と「検算する」 という2つの行動を、個人から組織までの追加メニューとして段階的に並べます。過去のメニューももちろん有効です。

  • 【輪郭】自分の理解/無理解を明示的にトラッキングする
    リスクマップやコンピテンシーマトリクスの発想に近く、判らないことが判っている状態を維持する筋力こそAI時代に一番育てたい筋肉だと睨んでいます。輪郭の線引きを言語化して持ち続けるのが基礎体力です。
  • 【輪郭】LLMにWikiの内容で人間へ問いかけさせる
    Wikiにクエリを投げて終わらせず、人間が答え、LLMが反論し、人間が再考する。「判ったつもりが、いざ聞かれると答えられない」が一番おいしい教材で、輪郭のほつれを毎回その場で炙り出してくれます。痛いが効く、LLMを先生として使うイメージです。
  • 【検算】効率を捨てて自分で雑魚戦に潜る時間を残す
    ingestを全部LLMに任せず、重要なソースは自分で読んでWikiに統合する作業をあえて残す。たとえば「LLMに渡す前に、自分で3行サマリを書いてから投げ、LLMの要約との差分を見る」だけでも、自分の答えとAIの答えを突き合わせる検算になります。月に数本でも生のソースと格闘していれば、レベルが錆びずに済みます。わざと手こずったほうが頭に残る、というのは学習科学でも言われていること(「望ましい困難」と呼ぶそうです)。効率の悪さが、そのまま経験値になります。Anthropicエンジニアの「たまにAIなしでコードを書く」のもアリなんだと。
  • 【検算】Wikiを鵜呑みにせず、誤りも複利で溜まると疑う
    Wikiが太るほど整理済み知識が複利で増える、と冒頭で書きましたが、複利で増えるのは知識だけとは限りません。取り込み順のバイアス、古くなった記述、極端には悪意あるソースによる汚染(lintは矛盾は見ても敵対性は見ない)——誤りもまた複利で溜まります。Karpathy氏のGistのコメント欄でも、まさにこの汚染や陳腐化が論点に挙がっています。「Wikiにそう書いてあった」のを鵜呑みにせず、一次ソースで裏取りする習慣は、検算の経路を太くする訓練そのものです。これは第3回「増幅される人間の善意と悪意」で深掘りします。
  • 【組織】ジュニアの「経験値稼ぎの場」を残す
    オンボーディングや初期タスクに、LLMに聞かずに一次ソースを読んで要約する儀式を意図的に残す。Wikiが整い過ぎているほどジュニアは輪郭を引く練習も検算する練習も出来ません。Anthropic調査では「自分が出す質問の8〜9割がClaudeに行くようになった」「ジュニアが質問しに来る機会が減った(ただし以前より速く答えを得て、より速く学べてはいる)」との声も。聞きに行ったついでに得ていた文脈や暗黙知ごと消える前に、組織の記憶を運ぶ毛細血管を意図して残す動きが要ります。ここで手を抜くと、5年後・10年後に組織を背負うはずだったジュニアが育たない。将来世代にツケを残してしまいます。

追加したメニューとしては、個人で輪郭を引き、検算で確かめ、組織でその通り道を残す。AIが便利になったとしても経験値稼ぎの場を残せるようにしておく。

【コラム】カーナビ依存とLLM Wiki依存、決定的に違うところ

「カーナビに頼ると道を覚えなくなる」は誰もが知っている既知の現象ですが、カーナビの場合は目的地だけは人間が判っている前提があります。LLM Wikiの場合は「どこに行きたいか=何を問うべきか」すら判らなくなり得る点を懸念しています。もしかすると、AIナビならドライバーの気分やバイブス(雰囲気)で目的地を提案できるかもしれません。が、行き先まで決めてもらうのは本末転倒です。いけずやねぇ、エンジン掛ける前に目的地を決めといとくれやす。

おわりに

過去「自分で歩け」と書きましたが、AIによって千里の道も0歩で行ける時代になり、歩く手段が馬だろうが宙船だろうが「行き先はAIに任せるな」と言えそうです。行き先を決めるには、自分の理解の輪郭を持ち、AIの示した道を検算できるかが要点となります。
これからのAI時代に「つよつよエンジニア」として生き残るのは、全部をAIに任せる人でも、全部を自力でやる人でもなく、その二つを手放さず、AIの答えがズレても気付いて修正できる人では無かろうかと。

次回では、道場破りAIをどう乗りこなすか、その手綱の握り方を「この先生きのこる3戦略」で掘り下げたいと思います。
第3回では、Wikiの知識が複利で増えると「誤り」も「悪意」も同じく複利で増えます。整え続ける知識の「千里の堤も、AI蟻の一穴より崩れる」で、増幅されるのは善意か悪意か。

道場破りAIに、戦うのか、逃げるのか、取り込むのか、従属するのか。まだ答えは出せていません。
ただ、AIとどういうスタンスで向き合うのか、という視点は見えてきました。もう少し考えていきたいと思います。


お断り
記事内容は個人の見解であり、所属組織の立場や戦略・意見を代表するものではありません。
あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?