グーテン・ターク！ドイツのベルリンでC# / WPFエンジニアとして働いている、ある日本人エンジニアです。
こっちに来て数年、こびりつくような冬の暗さにもようやく慣れてきましたが、開発現場の熱量は日本にいた頃よりもむしろ高く感じています。特にここ数年、僕たちの「武器」は劇的に変わりましたよね。そう、GitHub CopilotやChatGPTといった、いわゆるLLM（大規模言語モデル）の台頭です。
正直に言いましょう。僕も毎日使っています。WPFのややこしいXAMLのバインディングエラーや、「あれ、このLINQの書き方、どっちが効率的だったっけ？」というちょっとした疑問に、彼らは一瞬で答えてくれる。かつてStack Overflowを何時間も彷徨っていた時間は、今や数秒のプロンプト（指示）に置き換わりました。
しかし、最近、ベルリンのカフェで同僚とビールを飲みながら話していて、ふと背筋が寒くなるような感覚に襲われたんです。
「僕たちは、本当に自分でシステムを構築しているんだろうか？」
ブラックボックスの誘惑と、僕たちが失いつつある「コードの手触り」
現在の開発スタイルは、ある種の「ブラックボックス・エンジニアリング」になりつつあります。何か問題が起きればプロンプトを投げ、出てきたコードをコピペし、動けば「ヨシ！」。動かなければ、そのエラーメッセージをまたLLMに食わせる。
これ、めちゃくちゃ効率的に見えますよね。実際、デリバリーの速度は上がったかもしれない。でも、その代償として、僕たちは「システムがなぜ、どのように動いているのか」という**第一原理（First Principles）**への理解を、少しずつ手放してしまっている。そんな危機感です。
特に僕が主戦場にしているWPF（Windows Presentation Foundation）の世界は、見かけによらず泥臭いんです。依存関係プロパティ（Dependency Property）の仕組み、ビジュアルツリーの伝播、Dispatcherによるスレッド制御、そして何よりメモリリークとの戦い。これらは、LLMが提示する「なんとなく動くコード」だけでは解決できない、深い「手触り感」を必要とする領域です。
ある日のこと。複雑なグラフィック描画を含む医療系システムの画面更新が、特定の条件下で数ミリ秒遅延するという問題が発生しました。ジュニアエンジニアが「AIに聞いても、一般的なパフォーマンス改善策しか教えてくれません」と頭を抱えていたんです。
そこで僕がやったのは、プロンプトを打つことではなく、コードを一行ずつ追い、メモリプロファイラでヒープの動きを観察し、描画パイプラインのどの段階でブロッキングが起きているかを特定する「ハードコードされたロジックの解剖」でした。結果として、原因はAIが提案したモダンな手法ではなく、.NETの古い内部挙動に起因するものでした。もしあの時、LLMの回答を盲信して「もっとプロンプトを工夫しよう」なんて方向に行っていたら、今頃まだ解決できていなかったでしょう。
ベルリンの現場で痛感した、LLMに「デバッグ能力」を外注するリスク
ベルリンの朝は、ドロっとした濃いコーヒーから始まります。僕が今いるチームは、ドイツ人、フランス人、インド人、そして日本人の僕といった多国籍な構成。バックグラウンドがバラバラな分、共通言語としての「ロジック」にはみんなめちゃくちゃシビアです。
そんなある日のスプリント後半、僕たちのチームにある「爆弾」が投げ込まれました。開発中のWPFアプリケーションで、特定の操作を繰り返すとUIが数ミリ秒間フリーズし、最悪の場合はクラッシュするという報告。いわゆる「再現性が低い、嫌なタイプのバグ」です。
「AIがこう言ってるから」という危うい免罪符
担当したのは、入社して半年の若手エンジニア、マルクス（仮名）。彼はプロンプト・エンジニアリングの達人で、GitHub Copilotを魔法の杖のように使いこなします。彼が最初に出したプルリクエストを見て、僕は少し嫌な予感がしました。
コードには、非同期処理を司る Task.Run や await があちこちに追加され、一見すると「モダンで正しい」修正に見えました。彼に「なぜここを Task.Run で囲ったの？」と聞くと、彼は自信満々にこう答えました。
「ChatGPTにコードを食わせたら、UIスレッドがブロックされている可能性があるから、別スレッドに逃がせって言われたんだ。実際、僕の手元ではフリーズしなくなったよ」
確かに、彼のローカル環境では動いている。でも、僕はコードの中に、WPFの根本的なルールである「Dispatcher（UIスレッド）」の制御と、マルチスレッド下でのコレクション操作の矛盾を見つけてしまいました。
ブラックボックスが生む「偽の解決」
案の定、QA（品質保証）チームに回すと、高負荷環境でクラッシュが再発。しかも、以前より原因の特定が難しい複雑なエラーになっていました。ここで起きていたのは、「ブラックボックス・エンジニアリング」の典型的な罠です。
- 問題の表層だけを見る：UIが止まる → スレッドを分ければいい。
- LLMに丸投げする：「このコード、どこが重い？」とプロンプトを投げる。
- 理解せず適用する：提案された「もっともらしいコード」をコピペする。
マルクスは、WPFの「スレッド・アフィニティ（特定のオブジェクトは特定のスレッドからしか触れない）」という第一原理を深く理解せず、AIが提示した「対症療法」をそのまま飲んでしまった。その結果、根本原因である「メモリ上のリソース競合」は隠蔽され、代わりにランタイムでランダムに発生するスレッドセーフティの問題という、さらに厄介な怪物を生み出してしまったんです。
海外の、特にここドイツのようなエンジニアの自律性が高い現場では、AIを盲信することは「思考の放棄」とみなされることがあります。テックリードとのコードレビューで、「AIが言ったから」なんて理由は1ミリも通用しません。求められるのは、**「なぜそのライブラリを選んだのか」「なぜこの設計にしたのか」という、自分自身のロジックに基づいた説明責任（Accountability）**です。
あえて「第一原理」に戻る。メンタル・ソブリンティ（精神的主権）という考え方
ベルリンの冬は長くて暗い。午後4時には外が真っ暗になり、冷たい雨が石畳を濡らします。そんな日は、仕事が終わったあとも自宅の書斎にこもって、あえて「効率の悪いこと」をしたくなるんです。最近の僕の密かなブームは、LLMを一切使わずに、C#の言語仕様書や .NET のランタイム（CoreCLR）のソースコードを読み解きながら、ごく小さなライブラリを自作することです。
「第一原理」という地図を持つということ
僕たちがLLMを使ってコードを書くとき、それは「高性能なGPS」に従って見知らぬ街を歩いているようなものです。目的地には最短で着く。でも、その街のどこに裏路地があり、どの角に美味しいパン屋があるのか、地形がどうなっているのかは、全く頭に入りません。GPSが壊れた瞬間、僕たちは迷子になります。
一方で、**第一原理（First Principles）**から理解するというのは、自分の頭の中に「地図」を描く作業です。
WPFエンジニアとして例えるなら、「バインディングが動かない」という現象に対して、「こう書けば動く（とAIが言った）」という答えを知っているのがGPS。対して、「XAMLがパースされ、ターゲットオブジェクトの依存関係プロパティが探索され、BindingExpression が生成されて、PropertyChanged イベントをリッスンする……」という内部の歯車が噛み合う音まで想像できるのが、第一原理による理解です。
メンタル・ソブリンティ（精神的主権）を取り戻す
ここで僕が提唱したいのが、**「メンタル・ソブリンティ（精神的主権）」**という考え方です。これは、自分の思考や判断の最終的な根拠を、外部のツール（AI）ではなく、自分自身の知識と経験の中に保持し続けること。
[Image illustrating the concept of Mental Sovereignty in human-AI collaboration]
プロンプトを投げて返ってきたコードをそのまま使うとき、僕たちは一瞬、神になったような全能感を感じます。でも実際には、そのコードの正しさを判断する基準すらAIに委ねてしまっているなら、それは「主権」を明け渡しているのと同じです。
海外で働いていると、日本以上に「お前は何ができるんだ？」「お前はどう考えるんだ？」と個人の実力を問われます。そのとき、自分の言葉の裏に「自分で考え抜いたロジック」という揺るぎない裏打ちがあるかどうか。それは、声の大きさや英語の流暢さ以上に、エンジニアとしての説得力に直結します。
AIを「賢い部下」にするために。第一原理を握りしめて海外の荒波を渡る
さて、ここまで「プロンプト全盛期の今こそ、あえてハードコードする力を磨こう」という、時代に逆行するかのような話をしてきました。結論から言うと、AIは「最高の部下」にすべきであって、「上司」にしてはいけない、ということです。
AIを「検品」する立場を降りない
海外の現場で「シニア」や「リード」と呼ばれるエンジニアたちを観察していると、一つの共通点に気づきます。彼らは例外なく、AIが吐き出したコードに対して「超・懐疑的」です。
「このコード、動くけど、なんでここでこのロックを取ってるんだ？」 「このLINQの書き方、データが100万件になったら O(n2) で死ぬんじゃないか？」
彼らはプロンプトを打つ前に、自分の頭の中に「正解のプロトタイプ」を持っています。AIに書かせるのは、そのプロトタイプを形にするための「タイピング作業」に過ぎません。これこそが、僕たちが目指すべき姿です。
もしあなたが「AIが書いたコードのどこが悪いのか説明できない」状態にあるなら、それはあなたがAIに使われている証拠です。海外の、特に言葉の壁がある環境では、技術的な正当性をロジックで説明できないことは致命傷になります。
「遠回りの満足感」が、技術的自尊心を育む
エンジニアという職業の最大の報酬は、実は給料ではなく、「自分の手で複雑な問題を解決した！」というあの純粋な達成感ではないでしょうか。
プロンプトを投げて貼り付けるだけの作業を繰り返していると、この達成感はどんどん薄れていきます。自分の仕事が「誰でもできる、代替可能なもの」に思えてきて、心が摩耗していくんです。でも、あえてドキュメントを読み込み、内部構造を理解し、苦労して「自分だけのロジック」を構築したとき。そのコードが、何万人のユーザーに使われてもビクともせずに動き続けているのを見たとき、その「技術的自尊心」は何物にも代えがたいエネルギーになります。
海外を目指すあなたへ。英語力も大事ですが、それ以上に「自分の頭で、第一原理から考える癖」を捨てないでください。「プロンプトを工夫してAIに100点の回答を出させる技術」よりも、**「AIが出した80点の回答を、自分の知識で120点に昇華させる力」**を磨いてください。
その15分間の「遠回り」が、5年後、あなたが世界中のどこにいても必要とされる、強靭なエンジニアへと育ててくれるはずです。
僕もここベルリンで、まだまだ「遠回り」を続けています。AIに答えを聞く前に、システムと直接対話するために。その先にある「知る喜び」を、ぜひあなたも手放さないでください。
Auf Wiedersehen!（また会いましょう！）
コメント