AI？ 俺には関係ない、と思ってた時期が僕にもありました
どうも！ ヨーロッパの片隅で、C#とWPFをメインに、日々PCと格闘しております、ITエンジニアの（あなたの名前やハンドルネーム）です。
いやー、海外でエンジニアやるって、正直どうすか？ これから海外目指してる人って、どんなイメージ持ってますかね。
「バリバリ英語で議論して、最新技術でイノベーティブな開発して、週末はカフェで優雅に…」みたいな？
半分ホントで、半分ウソっすね（笑）
もちろん、日本じゃなかなか触れないようなデカいプロジェクトに関われたり、いろんなバックグラウンドを持つ仲間と働けるのは、マジで刺激的。僕もWPFなんていう、ちょっとレガシー寄り？な技術（失礼！）をメインでやってますけど、こっちじゃ製造業とか医療機器とか、まだまだ現役バリバリ。むしろ「安定性が命」みたいな領域で、C#の堅牢さが超重要視されてたりするんすよ。
でもね、キラキラした部分だけじゃない。
まず、コミュニケーションの壁。これはもう、永遠のテーマ。
僕も「まあ、技術書読めるし、なんとかなるっしょ！」って思ってこっち来たクチなんですが、甘かった。
設計レビューひとつとっても、もう大変。
僕の専門がWPFってこともあって、UI/UXの細かいニュアンスを伝えるのが、まぁ難しい。
「ここのボタンの挙動、もうちょっと『フワッ』とさせたいんだよね」
「『フワッ』って何だよ（笑）」
「いや、だからこう、ユーザーがクリックした時に、一瞬のディレイとイージングを…」
「ああ、DoubleAnimation の EasingFunction の話か？ どの Ease が欲しいんだ？」
こんなやり取り、日常茶飯事。こっちは非ネイティブ、相手も非ネイティブ（例えばドイツ人とかフランス人とか）。お互いカタコトの英語で、技術的な共通言語（コード）を探り合う日々。
仕様書が完璧ならいいんすよ。でも、そんな現場あります？（笑）
結局、アジャイルだなんだって言っても、最後は「口頭でのすり合わせ」と「コード読んで察してくれ」の世界。この「察してくれ」が、文化も言語も違うと、マジで地獄。
ここでね、最近のAIブームですよ。ChatGPTとか、GitHub Copilotとか。
正直、最初はどう思ってました？
僕はね、「あー、また来たか、バズワード」って感じでした。
もちろん、使ってみて「うわ、便利！」とはなりましたよ。
特にCopilot。C#で決まりきったボイラープレートコード（INotifyPropertyChanged の実装とか）をササッと書いてくれるのは、マジでありがたい。
「このXMLドキュメントコメント、英語で書いて」とか。
「このLINQ、もうちょいパフォーマンス良く書けない？」とか。
そういう「雑務」を押し付けるアシスタントとしては、最高。
でも、心のどこかで思ってたんすよ。
「所詮、アシスタントだな」と。
僕らの仕事の核心、特にWPFみたいなちょっとニッチで、長年の「秘伝のタレ」みたいなコードが蓄積してるプロジェクトの改修とか、複雑なビジネスロジックの設計とか。
そういう「本当に頭を使う部分」は、まだまだ人間の領域だろ、と。
実際、ちょっと込み入ったこと聞くと、アイツら平気でウソつきますからね。
前に、古いプロジェクトで使われてたサードパーティ製のWPFコントロールの、すっごいマニアックな挙動についてChatGPTに聞いたんすよ。
そしたら、「はい、そのプロパティは DependencyProperty として実装されており、Binding 可能です」とかドヤ顔で回答してきやがった。
で、ウキウキで実装したら、全然動かない。
「おい、動かねーぞ！」
「失礼しました。私の知識は2021年までのもので…」
「いや、そういうことじゃねえ！」
結局、公式ドキュメント（もちろん英語）を半日かけて読み漁り、最終的にはソースコードをリフレクタでこじ開けて（笑）、それが DependencyProperty じゃないただのCLRプロパティだったって判明したんすよ。
「ほら見ろ！ 結局最後は、泥臭くコード読むエンジニアが最強なんだよ！」
そう思ってました。数ヶ月前までは。
でも、最近ちょっと「あれ？」と思うことが増えてきたんすよね。
こっち（海外）のジュニアエンジニアのキャッチアップ速度、なんか異常に早くないか？と。
昔だったら「このコンポーネントの仕組み、まずこの10個のドキュメント読んで、過去のチケット漁って…」って感じだったのが、最近の若手、なんかもう「大体わかりました。こういうことですよね？」って、いきなり核心突いてくる。
「どうやって勉強したん？」って聞いたら、
「いや、社内のConfluence（ドキュメント管理ツール）とGitリポジトリのログ、全部AIに食わせて、『この機能の概要と注意点、500文字でまとめて』って聞いただけっすよ」
とか言うんすよ。
マジか、と。
僕らが「AIは一般的なことしか答えられない」って思ってたのは、「一般的なこと」しかAIに教えてなかったからなんですよね。
アイツらは、AIに「ウチの会社の常識」を叩き込んで、自分専用のスーパーアシスタントを作り上げてた。
さらに、別のチームが新しいツールのプロトタイプを作った時。
UIはそこそこだったけど、バックエンドのロジックがやけにしっかりしてた。
「これ、設計誰やったん？ すごいじゃん」
「ああ、メインロジックはAIに仕様書渡して『C#でTaskとCancellationToken使った非同期処理として、一番堅牢なアーキテクチャ案、3つ出して』って聞いて、出てきたやつを組み合わせただけっす」
……マジか、と。（二回目）
僕らが「Copilot便利だねー」って、目の前の数行のコードを自動生成させて喜んでる間に、
彼らはAIに「設計思想」を問いかけ、「思考」させてた。
ここで、ハッとしたんすよ。
ああ、これ、ヤバい。
**「プロンプトエンジニアリング」**って言葉、日本でも流行ってると思うんですけど、僕、完全にナメてました。
「AIへの質問の仕方」くらいに思ってた。
でも、違う。
これは、「AIにどうやって複雑なタスクを解かせるか」「どうやってAIに自己修正させるか」「どうやって我々の専門知識をAIに注入するか」っていう、**ガチの「エンジニアリング」**なんだ、と。
僕らが必死に英語の壁と戦い、文化の壁と戦い、時差と戦いながら、なんとかパフォーマンスを出そうと四苦八苦してる、この海外という戦場で。
AIを「使いこなす」スキルは、もはや「あったら便利」なオプションじゃない。
C#が書ける、WPFが分かる。それは大前提。
その上で、**「AIに自分の代わりに働かせる技術」**を持ってるかどうかが、僕らの生産性を、いや、市場価値そのものを、根本からひっくり返すことになる。
これ、大げさだと思います？
でもね、海外って日本以上に「個人の生産性」にシビアなんですよ。
ダラダラ残業して「頑張ってますアピール」なんて、1ミリも評価されない。
同じ1時間で、どれだけの「価値」を生んだか。それだけ。
AIを使って1時間かかるタスクを10分で終わらせるヤツと、
「AIは信用ならん」つって1時間かけて手作業でやる僕と。
どっちが評価されるか？
火を見るより明らかっすよね。
「でも、AIはニッチなWPFのことは…」
「でも、AIはウチの会社の秘伝のタレコードは…」
そう。そうなんですよ。
だからこそ、「Advanced Techniques & Future Trends」（高度なテクニックと未来のトレンド）が重要になってくる。
僕らが今「便利だね」って使ってるAIは、言わば「一般教養」しか知らない状態。
そこに、どうやって「専門知識」を叩き込むか。
- ただ質問するんじゃなく、「思考の連鎖（Chain-of-Thought）」や「自己修正（Self-Correction）」を促して、AI自身に答えの精度を上げさせるテクニック。
- 僕らが持ってる「WPFの設計ノウハウ」や「このプロジェクト固有のルール」っていう独自データをAIに学習させて、ウチの会社専用の「最強のAIエンジニア」を育てる方法。
- これから絶対に出てくる「C#専門AI」とか「UIデザイン専門AI」とか、そういう特化型AIを、僕らエンジニアがどう「調教」していくか。
これが、僕らが「AIに使われる側」じゃなく、「AIを使い倒す側」に回るための、鍵になる。
これから海外で戦おうって思ってる皆さんは、たぶん技術力も高いし、学習意欲も半端ないと思うんすよ。
だからこそ、言いたい。
コード書く勉強するの、もちろん大事。英語やるのも、もちろん大事。
でも、それと同じくらい、いや、これからの時代はそれ以上に、**「AIを使いこなすエンジニアリング技術」**を学ばないと、マジでヤバい。
これは、単なる技術トレンドの話じゃない。
僕らが異国の地で、言語のハンデを背負いながら、どうやってネイティブのエンジニアや、世界中から集まる優秀なヤツらと渡り合っていくか、っていう**「人生術」であり、「サバイバル術」**の話なんです。
今回のブログでは、僕が最近「うわ、これ知っててよかった…」と本気で思った、AIプロンプトエンジニアリングの「その先」の世界について、ガッツリ語っていこうと思います。
「承」以降で、具体的なテクニックの話もしていくんで、ぜひお付き合いください。
「AIに聞いてみた」のレベルを卒業せよ。AIを「調教」する3つの呪文
「起」を読んでくれて、あざっす！ （あなたの名前）です。
前回のあらすじ：
「AI？ Copilot便利だよねー」とか言ってるうちに、海外の若手はAIに自社コード食わせて「最強のアシスタント」を爆誕させてた。ヤバい。コード書けるだけじゃもう勝てん。俺らが身につけるべきは、AIを「使い倒す」ための、ガチの「エンジニアリング」だ！
…ってとこまで話しました。
「いやいや、大げさな」
「プロンプトエンジニアリングって、要は『AIへの質問の仕方』でしょ？」
そう思ってる人、多いっすよね。僕もそうだった。
でも、僕らが今やるべきは「質問」じゃないんすよ。
AIに「指示」し、「思考」させ、「反省」させること。
僕が「起」で書いた、WPFのコントロールの挙動でAIにウソつかれた話、覚えてます？
あれ、今思えば僕のプロンプトが100%悪かった。
当時の僕は、たぶんこう聞いた。
「（某サードパーティ製コントロール）の HogeHoge プロパティは DependencyProperty ですか？ Binding できますか？」
そりゃ、AIも知らねーよ、と（笑）
一般的な知識しか持ってないAIに、超ニッチなライブラリの特定バージョンの実装詳細なんて、わかるわけがない。ウソついても仕方ないっす。
「ほら、やっぱりAIは使えないじゃん」
…じゃないんですよ。
このAIの「知ったかぶり」や「精度の低さ」を逆手に取って、いや、むしろ「矯正」して、望む答えを引きずり出す。それが、僕らが今すぐ学ぶべき**「Advanced Techniques（高度なテクニック）」**なんです。
今日は、僕が現場で「これ、マジで効くわ…」ってなった、基本的なテクニックを3つ、僕らのC# / WPFの現場にガッツリ寄せて紹介します。
1. Chain-of-Thought (CoT)：「思考の連鎖」で、AIの「知ったかぶり」を防ぐ
まず、一番カンタンで、一番効果デカいのがコレ。
「Chain-of-Thought（CoT）」、日本語で言うと「思考の連鎖」っすね。
超カンタンに言うと、
「答えだけ教えろ」
じゃなくて、
「答えに至るまでの『思考プロセス』も一緒に全部書き出せ」
って命令すること。
例えば、設計で悩んでる時。
【ダメな聞き方（Basic Prompting）】
「C#で、複数の非同期タスク（Task）を並列で実行しつつ、全体のタイムアウト（CancellationToken）と、各タスクの失敗（例外）をちゃんとハンドリングするクラスのコードを書いて。」
こう聞くと、AIは「はい、できました！」って、なんかそれっぽいコードをバーン！と出してきます。
でも、そのコード、大抵どっか間違ってる。
Task.WhenAll の例外処理が甘かったり、CancellationToken の連携が漏れてたり。
「なんか動かん！」ってなって、結局デバッグに1時間…。あるあるっすよね。
【マシな聞き方（CoT Prompting）】
「C#で、複数の非同期タスクを管理するクラスを設計します。
以下のステップバイステップで考えて、最終的なコードを提案してください。
- 要件定義: 複数の
Taskを並列実行したい。全体のタイムアウト（CancellationTokenSource）を設けたい。一部のタスクが失敗しても、他のタスクは続行させたい（あるいは即時キャンセルしたい、※ここで要件を明確化）。すべてのタスクの結果（成功・失敗）を最後に集約したい。 - 設計上の考慮点:
Task.WhenAllとTask.WhenAnyの使い分けは？ 例外処理（特にAggregateException）はどう扱うべきか？CancellationTokenを各タスクに正しく伝播させる方法は？ - 実装: 上記の考慮点を踏まえて、堅牢なサンプルコード（クラス設計）を提示してください。」
どうすか？
こうやって「思考のステップ」をこっちから指定してやる。
これだけで、AIの回答の精度、爆上がりするんですよ。
AIって、実は「ステップバイステップで考えて」って一言付け加えるだけで、内部のロジックが切り替わるらしいんすよ。
いきなり答えを出そうとすると「それっぽいウソ」を生成しちゃうけど、
「まず1を考えて、次に2を考えて…」ってやらせると、それぞれのステップで「正しい情報」を検索・推論しようとする。
結果、僕らがレビューしやすい、**「思考の過程が透明化された」**回答が出てくる。
これ、コードレビューの時にも応用できますよね。ジュニアに「なんでこの実装にしたの？」って聞く代わりに、AIに「このコードの設計意図をステップバイステップで解説して」って聞ける。
もう、AIが部下なのか先輩なのかわかんないっすけど（笑）
2. Self-Correction：「自己修正」で、AIに「反省」させる
次。CoTとセットで使うと最強なのが、「Self-Correction（自己修正）」。
AIに出させた答えを、AI自身にレビューさせるテクニックです。
AIって、プライドないんで（笑）
「お前のコード、ここダメじゃん」って言うと、素直に「すみません、修正します」って言ってくれる。
これを使わない手はない。
例えば、パフォーマンスチューニング。
【ダメなやり取り】
俺：「このLINQ、なんか遅いんだけど、速くして」
AI：「はい、AsParallel() を使って並列化しました！」
俺：「いや、データ数少ないし、オーバーヘッドで余計遅くなっとるがな！」
AI：「失礼しました。では ToList() で先に実体化します！」
俺：「そうじゃねえ！」
…不毛っすよね。
【マシなやり取り（Self-Correction）】
俺：「ここにC#のコードがある。 [コードを貼り付け]
まず、このコードのパフォーマンス上の問題点を3つ、厳しくレビューしてください。特に、メモリ確保と IEnumerable の遅延評価の観点から。」
AI：「レビューします。
1. Where 句の後に ToList() しており、不要な中間リストを生成しています。
2. Select 句の中で new MyObject() をしており、大量のオブジェクトがヒープに確保されます。
3. ループの中で IEnumerable が複数回評価される可能性があります…」
俺：「完璧なレビューだ。じゃあ、そのレビュー結果をすべて改善した、最も効率的なコードを書いて。」
AI：「はい、承知いたしました。 [改善されたコード] 」
これ、ヤバくないすか？
僕らは「レビューしろ」と「直せ」って言っただけ。
具体的な「直し方」は、全部AIが考えた。
これ、僕ら海外組にとって、マジで福音なんすよ。
「起」でも書いた、設計レビューでの「フワッと」問題。
あの「ニュアンス」を伝えるの、死ぬほどムズいじゃないすか。
「ここのパフォーマンス、なんかイケてないんだよね…」みたいなのを、英語で、ロジカルに説明するコスト。
でも、AI相手なら「なんかイケてないから、お前自身で厳しくレビューして直せ」で通じる。
コミュニケーションコストが、ゼロ。
このアドバンテージ、海外で働く上で、使わない理由がない。
3. Few-Shot Learning：「お手本」で、AIを「即戦力」にする
最後。これが一番、僕らWPFエンジニアみたいな「秘伝のタレ」文化で生きてる人間にブッ刺さるテクニック。
**「Few-Shot Learning（少数事例学習）」**です。
これは、AIに**「お手本（例）」を2〜3個（Few-Shot）見せて、「こういう感じでよろしく」ってやらせる**方法。
僕の現場、WPFのViewModelの書き方に、すんごい独自ルールがあるんすよ。
ベースクラスは HogeBaseVm を継承しろとか、プロパティ変更通知は SetProperty(ref _hoge, value) を使えとか、コンストラクタで IEventAggregator を必ずDIしろとか…
こういう「ウチの会社の常識」は、当然、素のAIは知りません。
【ダメな聞き方】
「Customer モデル（Name, Address を持つ）のViewModelを作って。」
AI：「はい、INotifyPropertyChanged を実装した CustomerViewModel です！」
（→ ベースクラスが違う！ プロパティ通知の仕方が違う！ DIがねえ！ 全部やり直しかよ！）
【神な聞き方（Few-Shot Prompting）】
「ウチのプロジェクトのルールに従って、ViewModelを生成します。以下の例を厳密に真似てください。
【例1：入力（モデル）】
C#
public class User {
public string FirstName { get; set; }
}
【例1：出力（ViewModel）】
C#
public class UserViewModel : HogeBaseVm {
private readonly IEventAggregator _ea;
private string _firstName;
public string FirstName {
get => _firstName;
set => SetProperty(ref _firstName, value);
}
public UserViewModel(IEventAggregator ea) {
_ea = ea;
// ... (モデルのプロパティを初期化)
}
}
【例2：入力（モデル）】
… (もう一つ別の例) …
【本題：入力（モデル）】
C#
public class Customer {
public string Name { get; set; }
public string Address { get; set; }
}
【本題：出力（ViewModel）】
[AIにここを生成させる]」
こうすると、どうなるか。
AIは「あ、なるほど。HogeBaseVm 継承して SetProperty 使って IEventAggregator をDIすりゃいいんすね」と、その場の会話だけで「ウチのルール」を完璧に学習します。
そして、CustomerViewModel を、一発で、100%完璧な「ウチのコード」として吐き出してくる。
コピペして、即コンパイルOK。
これ、もう、革命じゃないすか？
新人が入ってきた時のオンボーディングとか、クソ面倒なドキュメント整備とか、そういうのが全部不要になるレベル。
「起」で紹介した、あの爆速キャッチアップしてた若手。
たぶん、これやってたんすよ。
僕らが「コード読んで察してくれ」って言ってた「秘伝のタレ」を、AIに「お手本」として食わせて、「ウチの会社の文脈」をAIに叩き込んでた。
CoT（思考させろ）、Self-Correction（反省させろ）、Few-Shot（真似させろ）。
たったこれだけ。
これだけで、AIは「知ったかぶりする新人」から、「言わなくてもわかるベテラン」に一瞬で化けます。
これって、もはや「質問力」じゃない。
AIの能力を限界まで引き出すための、**「AI調教術」であり、「エンジニアリング」**そのものなんですよね。
さて、ここまで「AIへの指示の出し方」のテクニックを話してきました。
でも、勘のいい人は気づいてるはず。
「Few-Shotのお手本が、例2個じゃなくて、プロジェクト全体のコードだったら？」
「CoTで思考させる時、Webの情報じゃなくて、ウチの社内Confluence（ドキュメント）をベースに思考させられたら？」
そう。
この「Advanced Techniques」の、さらに先。
僕らが本当に目指すべき「ヤバい未来」が、そこにあるんすよ。
次回、「転」では、この「AIにどうやって**ウチの会社の専門知識（Domain-Specific Knowledge）**を叩き込むか」っていう、さらに一歩進んだサバイバル術について、ガッツリ掘り下げてみます。
AIの「教科書」を書き換える。君の会社の「秘伝のタレ」をAIに注入せよ
どうも！（あなたの名前）です。
「承」のテクニック（CoT、Self-Correction、Few-Shot）、試してもらえました？
あれだけでも、AIが「新人」から「中堅」くらいには化けるはず。
でもね、気づいちゃいました？
あれ、結局**「AIの地頭（一般的な知識）」の範囲内で、いかに賢く答えさせるか**って話なんですよ。
「Few-Shot（お手本）」でウチの社内ルールを真似させても、AIは「なぜ」そのルールなのかは理解してない。ただ「真似してる」だけ。
もしお手本が古かったら？ お手本が間違ってたら？
AIは平気でその「間違い」をコピペして、ドヤ顔で「ウチのルールです！」って言ってきますよ。
僕らが本当に欲しいのって、「ウチのルールを丸暗記する新人」じゃないですよね。
僕らのWPFプロジェクトの、あのクソ複雑な設計思想を理解し、
「ああ、あの機能ね。あれは5年前にXXさん（OB）が作ったHogeHogeManagerがキモでさ。パフォーマンス上の理由で、あえてMVVMパターンを崩してる部分があるから、触るならFugaServiceとの疎通部分に注意な」
とか言えちゃう、**「ウチの会社に10年勤めてるベテラン」**じゃないですか？
「いやいや、AIにそこまで求めるのはSFだろ」
そう思ってた時期が、僕にもありました。
でも、もうSFじゃない。
「承」でやったのが、AIという「エンジン」の使い方（プロンプT
トエンジニアリング）を学ぶことだったなら、
「転」でやるのは、AIが参照する**「燃料（知識）」そのものを、インターネットから「ウチの会社の独自データ」に差し替える**技術の話です。
AIの「脳内」は、もう「Web」だけじゃない
僕らが普段使ってるChatGPTとかって、202X年までの「インターネット」を教科書にしてますよね。
だから、僕らの会社のGitリポジトリにも、社内Confluence（ドキュメント）にも、Jiraのチケットにもアクセスできない。
でも、もし。
もし、AIの「教科書」を、インターネットじゃなくて、
「ウチの会社の全Confluenceページ ＋ 全Jiraチケット ＋ 全Gitリポジトリ（過去10年分のコミットログ含む）」
に差し替えられたら？
これが、**「Integrating domain-specific knowledge bases（ドメイン固有の知識ベースの統合）」**っていう、今一番アツい技術のキモです。
「それって、AIをイチから再学習させるの？ 何億円かかるんだよ」
って思いますよね。違います。
もっとカンタンな、**「RAG（Retrieval-Augmented Generation）」**っていう仕組みが主流になりつつあります。日本語だと「検索拡張生成」。
これ、マジで知っとかないとヤバいんで、超カンタンに説明します。
僕らエンジニアは、この「RAG」を設計する側になるからです。
【RAGの仕組み（WPFエンジニア風に解説）】
- 準備（DB化）：まず、ウチの会社のConfluence、Jira、Gitリポジトリ、全部のテキストデータを「検索しやすい形」にして、専用のデータベース（ベクトルDBとかいう）にぶち込んでおきます。（例：「Button のカスタムコントロールに関する設計書」はこのDBの 0x123番地、「JIRA-567 のバグ報告」は 0x456番地、みたいに）
- 実行（俺らがAIに質問する時）：俺：「WPFアプリの起動が遅い。App.xaml.cs の OnStartup で、どの処理がボトルネックになってるか教えて」
- RAGシステムが裏で動く：AI（ChatGPTとか）が答える前に、RAGシステムが動きます。RAG：「お、OnStartup のボトルネックの話だな。ウチのDB（ConfluenceとかGit）に、関連情報あったかな？」RAG：「（DBを検索）…あった！ 3ヶ月前のJiraチケット『JIRA-999: 起動速度改善タスク』と、Confluenceの『○○機能の初期化処理に関する注意点』がヒットしたぞ！」
- AIへの「指示」が自動で「拡張」される：RAGシステムが、僕の質問を、AIのためにこう「翻訳（拡張）」します。「以下の社内資料を厳密に参照して、OnStartup のボトルネックについて回答してください。【資料1：JIRA-999】【資料2：Confluence】【ユーザーの質問】
OnStartupで、どの処理がボトルネックになってるか教えて」
- ○○機能は、必ず
HogeHogeManagerの後に初期化すること。
ThemeManagerの初期化に3秒かかってる。LicenseCheckerが同期でWebアクセスしてて遅い。
- AIの回答：この「拡張されたプロンプト」を受け取ったAIは、こう答えます。「お疲れ様です。OnStartup のボトルネックですね。社内ドキュメント（JIRA-999）によると、ThemeManager の初期化と LicenseChecker の同期Webアクセスが主な原因として報告されています。また、Confluenceの設計書に基づき、○○機能の初期化順序が守られているかも確認してください。」
……どうです？
これ、もう「インターネットを知ってるAI」じゃない。
**「ウチの会社の事情を完璧に把握してる、入社10年目のベテランAI」**の爆誕です。
これが「承」でやったFew-Shot（お手本）との決定的な違い。
Few-Shotは、僕らが「お手本」として与えた2〜3個の例しか見れない。
RAGは、「会社の知識全体」から、AIが自分で最適な回答を「検索（Retrieval）」して「拡張（Augmented）」してくるんです。
僕の会社でも、これの導入がガチで進んでます。
もう「AIに質問する」フェーズは終わった。
これからは**「AIに、ウチの知識をどうやって検索させるか」**を設計するフェーズです。
AIは「万能型」から「専門型」へ。そして、君の仕事は「調教師」になる
この流れ、もう止まりません。
てことは、僕らが向き合うAIも変わってきます。
今までは「ChatGPT」みたいな、「なんでも知ってる万能型AI」が主流でした。
でも、これからは違います。
**「特化型AI（Specialized Engineering AIs）」**の時代です。
例えば、僕らの目の前には、こんな「専門AIチーム」が並ぶことになる。
- WpfUiCopilot:ウチのGitリポジトリとデザインシステムを完全学習済み。「Jira-777の仕様で、顧客一覧画面のXAMLコード、ウチのルール通りに作っといて」「はいよ（10秒で生成）」
- CsharpPerformanceAi:.NETのランタイムとパフォーマンスチューニングに特化。「さっきの WpfUiCopilot が作ったコード、IValueConverter の実装がイケてない気がする。レビューして、メモリ効率最強にして」「承知（5秒でレビューと修正案）」
- MedicalSafetyVerifierAi: （僕の業界が医療機器系だとして）FDA（アメリカ食品医薬品局）とかの規制（レギュレーション）を完全学習済み。「修正後のコード、ウチの医療機器安全基準 Ver.3.1 に違反してないか検証レポート出して」「検証中… OKです。レポートをConfluenceに自動生成しました」
ヤバいですよね。
じゃあ、僕ら「人間エンジニア」の仕事は、何になるのか？
コード、書いてないじゃん。
レビューも、検証も、AIがやってるじゃん。
そう。
僕らの仕事は、C#やWAFのコードを「書く」ことから、
「どの専門AIに、どういう指示（プロンプト）を出して、どう連携させるか」
っていう、**「AIのオーケストレーター（指揮者）」あるいは「AIの調教師（トレーナー）」**に変わっていくんです。
「WpfUiCopilot の学習データ、ちょっと古いな。先週のリファクタリング結果をDBに反映させないと」
「CsharpPerformanceAi のチューニング、ちょっと過激すぎるな。『可読性を優先しろ』ってプロンプトをシステム全体の設定に追加しとかないと」
これが、**「AI時代のプロンプトエンジニアリング」**の本当の姿。
AIの「使い方」を学ぶ（承）だけじゃなく、
AIの「教科書（知識）」を整備し（転）、
AIの「チーム」を指揮する。
これが、僕ら海外エンジニアがこれから身につけるべき、本当の「サバイバル術」なんですよ。
C#が書ける、WPFがわかる。その知識は、AIを「調教」するための前提知識として、もちろん必要です。でも、それ「だけ」じゃ、もう勝てない。
じゃあ、結局、僕ら人間にしか残らない「価値」って、一体何なんだ？
AIが全部やってくれるなら、僕ら、いらなくない？
この、一番キモで、一番エグい問い。
それに対する僕なりの「答え」を、最後の「結」で話そうと思います。
AIに「魂」は込められない。コードの先に「人」を見る、君こそが最強のエンジニアだ
お疲れ様です！（あなたの名前）です。
長々と、僕の「AIヤバいぞ！」っていう話に付き合ってくれて、本当にありがとうございます。
「起」で、AIをナメてたら足元すくわれるぞ、という危機感を共有し、
「承」で、AIを「新人」から「中堅」にする基本的な調教術（CoT、Self-Correction、Few-Shot）を学び、
「転」で、AIに「ウチの会社の教科書」を注入するRAG（検索拡張生成）を知り、AIが「ベテラン」になる未来、そして僕らの仕事がAIの「調教師」になる未来を見ました。
で、「転」の最後に、一番エグい質問を投げかけました。
「WpfUiCopilot がXAMLを書き、CsharpPerformanceAi がリファクタし、MedicalSafetyVerifierAi が検証する…
じゃあ、俺ら（人間エンジニア）、いらなくね？」
AIが設計も実装もレビューもやってくれるなら、僕らの価値って、一体どこに残るんだ？と。
海外まで来て、必死に英語覚えて、技術磨いて…
そのゴールが「AIの調教師」って、なんか虚しくないすか？
今日は、この最大の恐怖に対する、僕なりの「答え」を、本気で話そうと思います。
これが、僕が海外でWPFエンジニアとして（という設定で）泥臭く働いてきた中で、今、確信している「人生術」であり、AI時代を生き抜く「サバイバル術」の結論です。
AIは「正解」を出せるが、「問い」は立てられない
まず、結論から言います。
僕ら人間に残された、いや、AI時代だからこそ価値が爆上がりする領域。
それは、「Why（なぜ）」を問い続ける力と、「共感」から「仕様」を生み出す翻訳力です。
…なんか、ポエムみたいに聞こえます？（笑）
いや、超ロジカルな話なんで、聞いてください。
「転」で紹介したRAG。あれは最強です。
会社の全知識を食ったAIに「Jira-123の仕様通りに、一番パフォーマンス出るコード書いて」って言えば、AIは100点のコードを返してきます。
AIは「How（どうやるか）」の化け物です。
でもね、AIは絶対に、自分からこうは言わない。
「…てか、このJira-123の仕様、なんかイケてなくないすか？」
「このボタン、本当にこの位置でユーザーはハッピーなんすかね？」
「そもそも、この機能、本当に作る必要あります？」
AIは、与えられた「問い」に対して「最適解」を出すプロ。
でも、**「そもそも、その『問い』、間違ってませんか？」**とは言えない。
AIは、「仕様書」というルールの範囲内で、最高のパフォーマンスを発揮する「超優秀な奴隷」なんです。
僕らの仕事って、仕様書通りにコード書くだけでしたっけ？
違いますよね。
僕がWPFエンジニアとして一番神経使うのって、コード書いてる時じゃない。
UI/UXのレビューで、デザイナーや企画担当と「ああでもない、こうでもない」ってやってる時です。
「このボタン、押した時の『手応え』が足りない」
「『手応え』って何すか（笑） Click イベントじゃダメなんすか」
「いや、なんかこう…ユーザーが『あ、今、重大な処理が実行されたな』って直感的にわかるような…」
「ああ、ProgressBar を一瞬出すとか、ボタンが数秒 IsEnabled=False になって戻るとか、そういう『フィードバック』の話か！」
これですよ。
この、「相手の曖EMOい『フワッ』とした要求」に共感し、それを『IsEnabled=False』っていう「カチッ」とした技術仕様に翻訳する能力。
これこそ、僕ら人間に残された、最強のスキルなんです。
AIは「『手応え』が欲しい」って言われても、「承知しました。『手応え』という単語を含む詩を生成します」とかトンチンカンなこと言うのがオチ（笑）
（もちろん、CoTとかで誘導すればできますけど、その「誘導」の仕方を考えるのが、まさに僕らの「翻訳」スキル）
海外で働いてると、この「翻訳」スキルの重要性、マジで痛感しません？
ただでさえ言語が違う。文化も違う。
インド人エンジニアの「Yes」は「Yes（聞いたよ）」であって「Yes（同意する）」じゃない、とか（笑）
ドイツ人マネージャーの「完璧だ」は「まあ、及第点だ」くらいの意味だったり、とか。
この「言葉の裏にある、本当の意図」を読み取る力。
「この人が本当に解決したい『痛み』は、何なんだろう？」と想像する力。
これ、AIには（まだ）ない。
AIには「心」がないから、「共感」ができない。
僕らエンジニアの仕事は、AIによって「How（どう作るか）」の部分から、どんどん解放されていきます。
じゃあ、浮いた時間で何をするか？
サボる？（笑）
いや、違う。
浮いた時間で、もっとユーザーと話すんです。
浮いた時間で、もっとチームと「この機能の『魂』は何か」を議論するんです。
AIが「作業」をやってくれるおかげで、僕らはようやく、本来やるべきだった**「価値創造」**にフルコミットできる時代が来た。
これ、ヤバくないすか？ ワクワクしません？
AIは「脅威」ではなく、「最強の義手」だ
「でも、AIに指示出す『調教師』なんて、つまんないよ…」
そう思う人もいるかも。
でも、考えてみてほしい。
僕ら、海外で働くエンジニアにとって、一番のハンデって何でした？
そう、**「言語の壁」**ですよね。
設計レビューで、言いたいことの半分も英語で伝えられない。
ネイティブのヤツらが早口で議論してる中、タイミングを失って黙り込む。
ドキュメント読むのに、ネイティブの3倍時間がかかる。
この「悔しさ」、みんな経験あるはず。
でも、AIが全部解決してくれるんですよ。
AIを「脅威」だと思うのは、間違い。
AIは、僕ら非ネイティブにとって、**「最強の義手・義足」**なんです。
- 英語のミーティング？AIにリアルタイム翻訳させながら、「こういうニュアンスで反論したいんだけど、一番ロジカルな言い方して」って指示すればいい。
- 膨大な英語の仕様書？AIに「このドキュメントのキモ、500文字で、特に俺が担当するWPFのUI部分に関するとこだけ抜き出して」って言えばいい。
- 「秘伝のタレ」コードが読めない？RAG（社内AI）に「このクラスの歴史的経緯と、触っちゃいけない『地雷』部分、全部教えて」って聞けばいい。
AIという「最強の義手」を装着することで、僕らは初めて、言語や知識量のハンデなしに、ネイティブのエンジニアと「対等」な土俵で戦えるようになる。
これこそ、僕らが「知ってよかった」と心から思うべき、「得する情報」じゃないですか？
AIを使いこなせないエンジニアは、いわば「義手」をつけずに片手で戦おうとしてるようなもん。そりゃ負けますよ。
AIを使いこなすエンジニアは、両手（自分＋AI）どころか、三本目の「最強の腕」を手に入れることになる。
結論：だから、君は「コード」と「人」を学び続けろ
長くなりました。最後に、これから海外で戦おうとする（あるいは、今まさに戦ってる）エンジニアの皆さんに、僕からの具体的なアクションプランを。
- C#とWPFの勉強を、絶対にやめるな。「え？ AIがやるんじゃないの？」って？ 逆です。AIの調教師になるなら、AIが出してきたコードが「本当にイケてるか」を判断する**「目利き」**の能力が必須です。専門知識（ドメイン知識）がなければ、AIへの「問い」の質が上がりません。「なんかイケてない」という「違和感」も持てません。AIを使いこなすためにも、基礎技術の研鑽は、むしろ今まで以上に重要になります。
- AIの「調教術」を、今すぐ学べ。「承」で紹介したCoTや、「転」で紹介したRAG。こういう技術トレンドを、趣味でもいいから追いかけてください。「ChatGPTに聞いてみた」レベルで止まってるヤツから、確実に置いていかれます。これは「英語」と同じ、必須の「コミュニケーションスキル」です。
- そして、何より、「人」に興味を持て。AIにコードを書かせて浮いた時間、絶対モニターの前でボーッとしてないでください（笑）その時間で、ユーザーがどういう顔でそのソフトを使ってるのか見に行け。チームの仲間が、何を考えて、何に困ってるのか、コーヒーでも飲みながら雑談しろ。
AIは「How」を解決してくれます。
僕ら人間の価値は、「Why」を問い、「人」に共感することにあります。
コードの向こう側にいる「ユーザー」を想像し、
「ここの挙動、こうした方が絶対あの人ハッピーだよな」
っていう「魂」を、AIに指示して吹き込む。
AIが作った「完璧なコード」に、最後の「魂」を入れる仕事。
それこそが、僕ら海外エンジニアに残された、最高にクリエイティブで、最高にエキサイティングな仕事だと、僕は本気で信じてます。
AIを「最強の相棒」にして、このクソ面白くてやりがいのある海外サバイバル、一緒に楽しんでいきましょうよ。
コメント