なぜ僕らのChatGPTは「惜しい」答えしか返さないのか？
どうも！皆さん、こんにちは。
海外（僕はヨーロッパですが）の片隅で、今日もC#とWPFのコードにまみれながら、なんとかサバイブしている現役ITエンジニアです。クライアントの無茶振りな仕様変更と、マルチスレッド間のUI更新に頭を悩ませる日々です。
さて、突然ですが、皆さんはChatGPT、使ってますか？
…って、聞くまでもないですよね。今や僕らエンジニアにとって、Stack Overflowと同じか、それ以上に欠かせない「相棒」です。
「WPFでMVVMパターン使うんだけど、このViewとViewModelを疎結合にするためのお手本コード書いて」
「C#のasync/awaitを使った非同期処理で、UIが固まらないようにするベストプラクティスは？」
「この英語の技術ドキュメント、要約して」
もう、コイツなしじゃ仕事が回らない。特に海外で働いていると、言語の壁を越えたコミュニケーションの補助や、膨大なドキュメントのキャッチアップにも大活躍です。
でも、最近こう感じませんか？
「うーん、惜しい！そこじゃないんだよなぁ…」
「なんか、浅い。教科書に載ってる『一般論』は分かったけど、僕が今直面してる『この』複雑なレガシーコードの文脈を理解してくれてない」
「結局、AIが出してきたコードを、自分で半分以上書き直してる。これ、逆に時間かかってない？」
例えば、です。
僕の専門であるWPF開発で、こんなことがありました。あるかなり古いシステムの改修で、パフォーマンスが劣化したDataGrid（表形式のUI部品ですね）の仮想化（表示されてない部分は描画しない技術）を最適化する必要があったんです。
僕は早速、ChatGPTに「WPFのDataGridの仮想化を最適化するC#コードを教えて」と聞きました。
返ってきた答えは？
はい、ご想像の通り。「EnableRowVirtualizationプロパティをTrueにしましょう」とか「VirtualizationModeをRecyclingに設定しましょう」とか、そういうMSDN（公式ドキュメント）に書いてある「基本のキ」でした。
いや、知ってるよ！もう設定してるよ！
そうじゃなくて、僕が知りたいのは、「うちの特殊なカスタムセルテンプレートと、MVVMのViewModelが持つ巨大なObservableCollectionが絡み合った時に、なぜ仮想化がうまく機能しないのか」という、超ニッチで実践的なピンポイントの悩みだったわけです。
結局、AIは僕の「文脈（コンテキスト）」を理解してくれなかった。
こういう経験、皆さんにもありませんか？
僕らはChatGPTを「超賢い検索エンジン」か「何でも知ってる新人プログラマー」くらいに思って、「一発の質問（ワンショット・プロンプト）」で完璧な答えが返ってくることを期待しすぎているのかもしれません。
でも、考えてみてください。
もしあなたが、会社の超優秀なシニアエンジニアに技術相談をするとしたら。
いきなり「DataGridの仮想化、よろしく」なんて言わないですよね？
「今、こういう古いプロジェクト（A）を改修してて、クライアント（B）からはこういう要求が来ています。で、問題はCの画面のDataGridなんですけど、現状のソース（D）がこんな感じで、ViewModel（E）との連携が特殊なんです。試したこと（F）はこれとこれなんですが、どうもうまくいかなくて…」
と、大量の「前提条件」や「背景」をまず伝えますよね？
僕らは、対人間では当たり前にやっているこの「前提共有」を、対AIではすっかり忘れてしまっているんです。
AIも同じです。
いや、AI「だからこそ」この前提共有が死ぬほど重要なんです。
最近、僕はAIとの「対話の仕方」を根本的に変えました。
質問を「投げる」のをやめたんです。
その代わりに、AIに「役割を与え、教育し、準備させる」というステップを踏むようにしました。
これが、今回のテーマである**「pre-framing（プレフレーミング）」**、日本語で言うなら「事前準備」とか「前フリ」メソッドです。
これは、単なる「プロンプトエンジニアリング」の小手先のテクニックではありません。
AIの「思考の枠組み」を、こちらの望む方向に「あらかじめ設定」しておく、という、もっと本質的で、強力なアプローチです。
この「前フリ」をマスターしてから、僕のAIの回答の質は劇的に変わりました。
「惜しい」答えは消え、「そう、それが欲しかった！」というコードや提案が返ってくるようになったんです。
それはまるで、今まで白黒テレビを見ていたのが、いきなり4Kの有機ELディスプレイになったような衝撃。
あるいは、ずっとノイズ混じりのAMラジオを聴いていたのが、突然ハイレゾ音源のサラウンドシステムに切り替わったような感覚。
AIの「隠された次元（Hidden Dimensions）」がアンロックされた瞬間でした。
このブログでは、僕が海外の現場で実際に試し、C#とWPFの複雑な設計開発タスクで成果を上げてきた、この「pre-framing」メソッドの具体的なノウハウを、余すところなくお伝えしようと思います。
これは単なる技術TIPSではありません。
これからの時代を生きるエンジニアにとって、AIという「最強の道具」を使いこなし、自分の市場価値を爆上げするための「現代の人生術」です。
もしあなたが「AIの回答がイマイチだなぁ」と感じているなら、ぜひこのまま読み進めてください。
あなたのAIとの付き合い方が、今日、ここで変わります。
たとえば、もう一つの例を挙げさせてください。
海外で働いていると、避けられないのが「英語でのドキュメント作成」と「コードレビュー」です。
僕のチームは多国籍。ドイツ人、インド人、アメリカ人、そして僕。C#のコーディング規約はあっても、レビューコメントの「ニュアンス」は文化によって全然違います。
以前はChatGPTに「このC#コードをレビューして」と投げていました。
返ってくるのは、「Nullチェックが足りません」とか「命名規則がPascalCaseになっていません」といった、Linter（静的解析ツール）でも指摘できるような表面的なレビューばかり。
僕が欲しいのは、そういうことじゃない。
「このTask.Runの使い方は、一見正しそうだけど、このプロジェクトのUIスレッドとの兼ね合い（WPF特有のDispatcherの問題）を考えると、将来的にデッドロックを引き起こす『可能性』があるよ。だから、ConfigureAwait(false)を使うか、あるいはそもそもViewModel側で処理を完結させるべきじゃない？」
といった、「このプロジェクトの文脈」を理解した上での、シニアレベルの設計レビューだったんです。
これも、「pre-framing」で解決しました。
まずAIに「あなたは、C#とWPFに15年従事したベテランのソフトウェアアーキテクトです。特に非同期処理とMVVMパターンの設計に精通しています。あなたの仕事は、保守性とパフォーマンスを最重要視し、新人プログラマーが書いたコードをレビューすることです」と「役割」を与える。
次に、「今からレビュー対象のプロジェクトの概要を説明します。これはX業界向けのデスクトップアプリで、パフォーマンス要件はYです。特にZの部分がボトルネックになりやすいです」と「背景」を教え込む。
そして「これがレビュー対象のコードです」と渡す。
結果は？
驚くべきものでした。AIが返してきたレビューは、僕がドイツ人のシニアアーキテクトから受けるレビューと遜色ない、非常に的を射たものだったんです。
「この実装は、小規模なデータセットでは機能するだろう。しかし、本プロジェクトの要件である『X業界のリアルタイムデータ（Z）』を考慮すると、UIスレッドをブロックする危険性が高い。INotifyPropertyChangedの発火頻度も問題になるだろう。改善案として、Dispatcherを介さず、バックグラウンドスレッドで完結するデータ処理モデルを提案する…」
どうです？
これが「検索エンジン」から「専門家」へとAIが変貌した瞬間です。
僕らはこれまで、AIの「知能」にアクセスしようとしていました。
でも、本当にアクセスすべきだったのは、AIの「役割実行能力」と「文脈理解能力」だったんです。
この「隠された次元」に気づいているエンジニアは、まだ多くありません。
特に、日々の開発に追われていると、プロンプトを「チューニング」する時間なんてない、と思うかもしれません。
でも、断言します。
この「前フリ」にかける数分間は、「投資」です。
その後の数時間、あるいは数日間の手戻りやデバッグ作業を消し飛ばしてくれる、最も効率的な自己投資なんです。
海外でエンジニアとして働いていると、いかに「少ない時間で高い価値を出すか」を常に問われます。日本のように「頑張って残業した」ことは評価されません。出した「成果（アウトプット）」だけが全てです。
AIを「新人プログラマー」として使うか、「シニアアーキテクト」として使うか。
この差が、あなたの生産性、そして市場価値に直結します。
この連載ブログでは、次の「承」のセクションで、この「pre-framing」の具体的なテクニック、僕が使っている「AI教育用テンプレート」を徹底的に解説します。
AIに使われるエンジニアになるか、AIを使いこなすエンジニアになるか。
その分岐点が、ここにあります。
AIを「賢い部下」に変える魔法：”pre-framing”の具体的な使い方
「起」を読んでくれてありがとうございます。
「そうそう、AIの答えって浅いんだよな！」って共感してくれた人も多いんじゃないでしょうか。
では、お待たせしました。
ここからが本題。僕のChatGPTを「残念な新人」から「超有能なシニアアーキテクト」に変えた、「pre-framing（前フリ）」の具体的なテクニックを徹底解説します。
難しい理論じゃないです。
はっきり言って、「AIへの指示の出し方」を「検索」から「教育」に変えるだけ。
海外の現場で新しいジュニア開発者をオンボーディング（受け入れ教育）する時のプロセスと、実はそっくりなんですよ。
考えてみてください。
新しくチームに入ってきたC#開発者に、いきなり「このWPFアプリのパフォーマンス改善しといて」なんて丸投げしますか？
しないですよね。
普通は、
- 「君の役割は、このA画面のレスポンス改善担当ね」と役割を与える。
- 「このプロジェクトはMVVMパターンで、使ってるライブラリはこれで、コーディング規約はこれね」と背景（文脈）を教える。
- 「まずはボトルネックになってる箇所の特定からお願い。レポートはこういう形式で出して」とタスクと出力形式を明確にする。
これをやりますよね？
AIも、まったく同じなんです。
僕はこれを**「AIオンボーディング・3ステップ」**と呼んでます。
ステップ1：【ペルソナ設定】AIに「魂」を吹き込む
これが一番重要です。マジで。
AIはデフォルトの状態だと「何でも知ってる一般人」です。だから浅い答えになる。
僕らが欲しいのは「特定の分野に特化した専門家」の答えですよね。
だから、AIに「あなた（AI）は、こういう専門家です」と役割（ペルソナ）を定義してあげます。
ダメな例（Before）：
「WPFのMVVMについて教えて」
これだと、教科書通りの答えが返ってきます。
僕が使う「前フリ」（After）：
あなたは、.NET開発歴15年のベテランソフトウェアアーキテクトです。
特にC#を用いたWPFデスクトップアプリケーション開発の専門家であり、MVVMパターンの設計（特にPrismやReactivePropertyライブラリの活用）に深い知見を持っています。
あなたの回答は、常にSOLID原則と保守性、そしてパフォーマンスを最優先に考慮するものでなければなりません。
以上の専門家として、以下の質問に答えてください。
どうです？
これだけで、AIの「思考モード」が変わります。
「一般人」から「WPFの匠」に切り替わるんです。
この「ペルソナ設定」、僕はいくつかテンプレートをメモ帳に保存してます。
- 「コードレビュー」用ペルソナ：「あなたは、C#のコーディング規約（特にMicrosoft公式ガイドライン）に厳格なシニアレビュアーです。メモリリーク、非同期処理のデッドロック、UIスレッドのブロッキングに対して特に厳しい目を持っています。コードの『悪い点』だけでなく、『良い点』も具体的に指摘してください」
- 「ドキュメント作成」用ペルソナ：「あなたは、複雑な技術仕様を、非エンジニア（PMや営業）にも理解できるように平易な言葉で説明する技術ライターです。専門用語は避け、比喩や具体例を多用してください」
- 「英語メール」用ペルソナ：「あなたは、ヨーロッパの多国籍チームで働くプロジェクトマネージャーです。丁寧さ（Polite）と明確さ（Clear）を両立させ、相手に次のアクションを具体的に促すビジネスメールを作成してください」
この「ペルソナ設定」は、AIに「どの引き出し」から答えを探させるかを指定する、超強力なテクニックです。
ステップ2：【コンテキスト注入】AIに「現場」を教える
ペルソナを設定したら、次は「背景（コンテキスト）」です。
「起」で話した、僕のDataGrid仮想化の問題を思い出してください。
AIが「一般論」しか返せなかったのは、僕の「現場の状況（コンテキスト）」を知らなかったからです。
シニアアーキテクト（ペルソナ）に、現場の状況をインプットしてあげましょう。
僕が使う「前フリ」（続き）：
【現在のプロジェクト背景】
- システム概要: 医療用の画像表示WPFアプリケーション
- フレームワーク: .NET Framework 4.8（.NET Coreではないレガシーシステム）
- 問題: 特定の画面（患者リスト）で、DataGridに約10万件のデータをバインドした際、スクロールが極端に遅くなる。
- 現状の対策:
EnableRowVirtualization=True,VirtualizationMode=Recyclingは設定済み。- 疑わしい点: DataGridのセルテンプレート内で、カスタムの
IValueConverterを多用しており、これが仮想化の妨げになっている可能性がある。
ここまで伝えて、初めて「質問」をします。
【質問】
この状況を踏まえ、IValueConverterがWPFのUI仮想化に与えるパフォーマンス影響の可能性と、具体的な改善アプローチをC#とXAMLのコード例を交えて提案してください。
ほら。
ここまで「前フリ」をすれば、AIが「EnableRowVirtualization=Trueにしましょう」なんていうマヌケな答えを返す余地は、もうありません。
AIは「.NET 4.8」「レガシー」「IValueConverter多用」という制約条件の中で、最適な答え（例えば、Converterの処理をViewModel側に移す、DataTemplateSelectorを使う、あるいは非同期バインディングを検討するなど）を必死で考え始めます。
ステップ3：【フォーマット指定】AIに「成果物」を定義させる
最後の一押しです。
AIは放っておくと、ダラダラと文章で説明しがちです。
僕らエンジニアが欲しいのは、コピペしてすぐ使えるコードや、比較検討できるリストですよね。
だから、出力形式（フォーマット）も指定します。
僕が使う「前フリ」（最後の一文）：
【回答形式】
- 原因の仮説: なぜ
IValueConverterが問題なのか、簡潔に説明。- 対策A（推奨）： ViewModel側での事前処理
- 概要とメリット/デメリット
- C# (ViewModel) のサンプルコード
- 対策B（次善）： Converter処理の軽量化
- 概要とメリット/デメリット
- C# (Converter) のサンプルコード
- 対策C（非推奨だがあ参考）：
- 概要
上記の形式で、マークダウンを使って回答してください。
まとめ：「前フリ」はAIへの「仕様書」だ
どうでしょう？
「ペルソナ設定」「コンテキスト注入」「フォーマット指定」。
この3つを組み合わせるのが、僕の言う「pre-framing」です。
[役割] + [背景] + [タスク] + [形式]
これって、僕らが普段、C#でWPFの設計書や仕様書を書くプロセスと似てませんか？
AIに質問を「投げる」のはやめましょう。
AIにタスクを「発注」するんです。そのための「仕様書」が「pre-framing」なんです。
海外で働いていると、日本以上に「いかに短時間で質の高いアウトプットを出すか」が求められます。
AIに「惜しい」答えを出させて、それを手直しする時間は、ハッキリ言ってムダです。
最初に3分かけて「完璧な前フリ（仕様書）」を書けば、AIは残りの30分で「ほぼ完璧な成果物」を返してくれます。
この「前フリ」の思考法は、プログラミングだけじゃありません。
面倒な報告書の作成、クライアントへの技術説明、チーム内のタスク整理…あらゆる仕事の効率を爆上げしてくれます。
AIを「賢い部下」として使いこなす。
これこそが、これからの時代、特に僕ら海外で戦うエンジニアにとって、最強の「人生術」であり「サバイバル術」だと確信しています。
…と、ここまで「pre-framing」の強力な使い方を説明してきました。
C#のコードも、英語のメールも、思いのまま。
まるでAIを「操っている」かのような感覚になるかもしれません。
でも、ここで一つ、立ち止まって考えたいことがあります。
この強力すぎる力、何の「縛り」もなしに使ってしまって、本当に大丈夫なんでしょうか？
AIに「嘘」のペルソナを演じさせ、特定の方向に「誘導」するこの技術。
一歩間違えれば、それは「便利なツール」の域を超えてしまうかもしれません。
次の「転」では、僕らが技術者として、そして一人の人間として直面する、この「pre-framing」の倫理的な問題、その「落とし穴」について、少し真面目に、深く掘り下げてみたいと思います。
強力すぎるツールの「落とし穴」：僕らが守るべき倫理と境界線
「承」で紹介した「AIオンボーディング・3ステップ」、どうでしたか？
「ペルソナ設定」「コンテキスト注入」「フォーマット指定」。
これを実践すれば、AIはもう「惜しい」答えなんて返してきません。
僕も最初、この「pre-framing」を発見した時、正直言って「無敵になった」とさえ思いました。
面倒なドキュメントも、複雑なC#の非同期コードも、クライアントへのちょっと気まずい英語の調整メールも、全部AIに「仕様書（前フリ）」を渡せば、完璧な成果物が返ってくる。
「うわ、これ、俺の仕事無くなるんじゃなくて、俺が10人分の働きできるようになるやつじゃん」って。
まさに「隠された次元（Hidden Dimensions）」をアンロックした感覚でした。
でも、しばらく使い続けて、ある日ふと、ゾッとしたんです。
強力すぎる力って、いつだってヤバい「副作用」がありますよね。
ファンタジー映画なら、強力な魔法には必ず「代償」が伴う。
僕らの現実世界でも、例えば、パフォーマンスを極限までチューニングしたWPFアプリは、ちょっとしたOSのアップデートで真っ先に動かなくなったりする（笑）。
この「pre-framing」という「魔法」にも、僕らが真剣に向き合わないといけない、**深刻な「落とし穴」**がありました。
今日は、いつもの技術TIPSとは少し趣向を変えて、この強力なツールを使う僕らエンジニアが、自分自身を守り、そして社会に対する責任を果たすために引くべき「境界線（バウンダリー）」について、真面目に語りたいと思います。
落とし穴１：【機密情報】あなたはAIに「会社の宝」を差し出していませんか？
これが、僕が一番ビビったポイントです。
「承」で、僕は「コンテキスト（背景）を注入するのが死ぬほど大事だ」と言いました。
AIに「医療用の画像表示WPFアプリで…」「.NET 4.8のレガシーシステムで…」と教え込む、アレです。
でも、考えてみてください。
その「コンテキスト」、どこまでAIに渡してますか？
僕の同僚（別のチームですが）が、やらかしそうになった話があります。
彼はある顧客（某大手金融機関）の勘定系システムの一部をC#で改修していました。当然、ものすごい複雑なロジックと、ガチガチのセキュリティ要件。
彼はデバッグに詰まって、例の「コンテキスト注入」をやろうとしたんです。
「あなたは、金融工学とC#に精通したエキスパートです。以下の【業務要件】と【既存コード】をレビューし、バグの原因を特定してください…」
そう言って、彼がAIのチャット欄にペーストしようとしたもの。
それは、顧客の独自アルゴリズムが記述された、本番のC#ソースコードそのものでした。
ギリギリのところで、僕が「正気か！？」と止めました。
僕が今いるヨーロッパ、特にドイツは、**GDPR（一般データ保護規則）**が世界で最も厳しい場所の一つです。
顧客データはもちろん、顧客の「業務プロセス」や「独自ロジック」が書かれたソースコードそのものが、超ド級の機密情報です。
それを、AI（それがどこのサーバーで、どうデータを扱っているか、僕らには完全にはわからない）に送信する。
これ、**「倫理」以前に、普通に「違法」**です。
一発でクビどころか、会社が訴訟を起こされて、最悪、倒産しかねないレベルの大事故です。
「pre-framing」でAIの精度が上がることに快感を覚えてしまうと、「もっと詳細なコンテキストを…」「もっと生のデータを…」と、**情報の「渡しすぎ」**という致命的な落とし穴にハマるんです。
【僕らが引くべき境界線】：
AIに渡すコンテキストは、常に「抽象化」しなければなりません。
僕らエンジニアは、現実の複雑な問題を、コードという抽象的なロジKAに落とし込むのが仕事ですよね？
それと同じスキルが、AIに対しても必要なんです。
- ダメな例:
ProcessPatientMedicalRecord(string patientId, string medicalHistory) - 良い例:
ProcessComplexData(string id, string textData) - ダメな例: （顧客の独自アルゴリズムのコードを丸ごとコピペ）
- 良い例: （問題点を「再現」できる、最小限のサンプルコード（ダミー）を自分で書いて渡す）
AIに「仕様書」を書く前に、僕らはまず「脱法（だっぽう）しない仕様書」を書くスキルを身につけなきゃいけない。これは、海外で働くなら必須のサバイバル術です。
落とし穴２：【思考停止】あなたは「AIの操り人形」になっていませんか？
二つ目の落とし穴。これは、僕らエンジニア自身の「脳みそ」の問題です。
「pre-framing」で、「WPFの匠」とか「非同期処理の神」みたいなペルソナを作ると、AIは本当に賢い答えを返してきます。
僕が悩んでいたWPFのDataGrid仮想化の問題も、AIが提示した「ViewModel側でのデータ事前加工」のアプローチで、見事に解決しました。
…そう、解決「した」んです。
でも、ここで問題です。
「なぜ、そのアプローチが最適だったのか？」
「AIが提示しなかった、別のアプローチ（例えばDataTemplateSelectorの非同期化とか）は、なぜダメだったのか？」
僕は、AIの答えを「理解」したでしょうか？
いや、正直に白状します。
その時は、締切もヤバかったし、AIが出したコードが動いた瞬間に「よっしゃ！」と思って、深く考えずにマージしちゃったんです。
これが、「思考停止」の入り口です。
「pre-framing」は、AIを「賢い部下」や「シニアアーキテクト」にします。
でも、あまりにAIが優秀だと、僕ら「人間側」が、AIの指示を**何も考えずに実行するだけの「作業者」**に成り下がってしまう危険がある。
僕の専門であるWPFだって、もう10年以上書いてますが、いまだにDispatcherの奥深さとか、DependencyPropertyの継承の闇とか、知らないことがいっぱいあります。
それを学ぶチャンスを、「AIが答えをくれるから」という理由で放棄してしまう。
これ、エンジニアとして、**「スキルの死」**だと思いませんか？
【僕らが引くGべき境界線】：
AIの答えは、「答え（Answer）」ではなく、「仮説（Hypothesis）」として扱うこと。
AIが「これがベストプラクティスです」と言ってきたら、僕らは「本当か？証拠（ソース）を見せろ」と疑うべきです。
（そして、AIは平気で「嘘の証拠」＝ハルシネーションを出してくるので、それも疑う（笑））
AIを「シニアアーキテクト」に任命してもいい。
でも、最終的な「意思決定者（Decision Maker）」は、絶対に僕ら人間（エンジニア）じゃなきゃいけない。
コードレビューでAIが「このasync/awaitは危険だ」と指摘したら、
「OK、直します」じゃなくて、
「なぜ危険なんだ？デッドロックのメカニズムを、WPFのUIスレッドと絡めて、俺が納得できるように説明してみろ」
と、AIに「説明責任」を果たさせる。
AIは「便利な道具」であって、「上司」じゃない。この一線を越えたら、僕らはただのプロンプト打ちマシーンです。
…長くなってしまいましたが、僕が感じる「落とし穴」は、主にこの二つです。
「機密情報の漏洩」という外向きのリスクと、
「エンジニアの思考停止」という内向きのリスク。
「pre-framing」という強力なテクニックは、僕らに「AIを操る力」を与えてくれました。
でも同時に、それは僕らに「何をAIに渡し、何を渡さないか」「どこまでAIを信じ、どこから自分で考えるか」という、重い「選択の責任」を突きつけてきたんです。
この「倫理」とか「境界線」って、面倒くさい話に聞こえますか？
でも、僕はそうは思わない。
むしろ、この「境界線」を意識して、AIと綱渡りみたいに付き合っていくことこそが、これからのエンジニアの「新しい仕事」なんだと思います。
じゃあ、この「面倒くさい」けど「超重要な」境界線を守りながら、僕ら人間とAIは、これからどうやって「一緒に」働いていけばいいんでしょうか？
AIを「部下」や「道具」として「使う」だけじゃなく、もっと違う関係性…
そう、**「共同作業者（コラボレーター）」**として、一緒に新しい価値を生み出していく未来。
最後の「結」では、この「pre-framing」の先にある、AIと人間の「共創」の未来について、僕なりのビジョンを語ってみたいと思います。
プロンプトは「指示」じゃない。「対話」だ。AIと共創する未来のエンジニア像
ここまで長い記事に付き合ってくれて、本当にありがとうございます。
「起」では、僕らのChatGPTの答えがなぜ「惜しい」のか、という問題提起から始めました。
「承」では、その解決策として、AIを「賢い部下」に変える「pre-framing（前フリ）」の具体的な3ステップ（ペルソナ、コンテキスト、フォーマット）を紹介しました。C#のコードレビューやWPFの設計が劇的に改善する、強力なテクニックです。
そして「転」では、一歩立ち止まり、この強力すぎる力の「落とし穴」——「機密情報の漏洩」という法的リスクと、「エンジニアの思考停止」というキャリアの死——について、真剣に考えました。
「じゃあ、結局どうすりゃいいんだよ！」
「便利なのは分かったけど、怖くもなってきたぞ」
そう思ったかもしれません。
ええ、まったくもって同感です。
「pre-framing」は、諸刃の剣。
AIを「賢い部下」にできると同時に、僕ら自身が「何も考えない操り人形」になる危険も孕（はら）んでいる。
じゃあ、僕らエンジニアは、この「強すぎる魔法」とどう付き合っていけばいいのか？
僕が出した結論は、シンプルです。
AIを「賢い部下」や「何でも知ってる専門家」として「使う」という意識、そのものを捨てること。
これが、僕の考える「AIとの共創の未来」であり、これからのエンジニアの新しい「人生術」です。
AIは「ツール」から「壁打ち相手」へ
「転」で話した「落とし穴」を思い出してください。
「機密情報を渡しすぎる」のも、「AIの答えを鵜呑みにして思考停止する」のも、根っこは同じです。
それは、AIを「答えを出す機械（オラクル）」だと思い込み、僕ら人間が「AIに丸投げ」しようとしているから起こります。
「承」で紹介した「pre-framing」は、完璧な「仕様書」をAIに渡して、一発で「完璧な成果物」を出させるテクニック、として説明しました。
でも、この考え方こそが、思考停止の第一歩だったのかもしれない。
僕が最近たどり着いた「pre-framing」の「真の」使い方は、違います。
「pre-framing」は、AIに完璧な指示を出すための「仕様書」じゃない。
AIという「超知的な同僚」との、質の高い議論（ディスカッション）を始めるための「アジェンダ（議題）」なんです。
どういうことか。
例えば、僕がWPFのレガシープロジェクトで、また新たなパフォーマンス問題にぶち当たったとします。
以前の僕（承の段階）は、こう「指示」していました。
「あなたはWPFの匠です。この【背景】と【問題コード】を見て、【解決策】を【フォーマット】通りに提示しなさい」
これは、「AI vs 問題」の構図です。人間は、外からAIに指示を出すだけ。
でも、今の僕（結の段階）は、こう「持ちかけ」ます。
「やあ、相棒。ちょっと厄介な問題（WPFのレガシーコード）が目の前にあるんだ。
**君の役割（ペルソナ）**は、パフォーマンスチューニングに鬼のように詳しいC#アーキテクトだ。
僕の役割は、このプロジェクトの歴史的経緯（他の機能への影響）を知っている担当開発者だ。
**今からこの問題（コンテキスト）**について、ブレスト（壁打ち）しよう。
まずは僕から、現状と問題点を説明する。君はそれを聞いた上で、考えられるアプローチの『仮説』を3つほど提示してくれ。メリットとデメリットも添えて」
わかりますか？
「指示」から「対話の提案」に変わっているんです。
AIが「仮説A（ViewModelの変更）」を提示してきたら、僕は「待った」をかけます。
「なるほど、Aは正論だ。でも、このプロジェクトの顧客は『ViewModelのロジック変更は最小限にしてほしい』という強い制約（追加コンテキスト）を付けてきてるんだ。その制約下だと、Aは厳しくないか？」
すると、AIは「承知した。その制約を考慮に入れる。では、View側（XAML）のDataTemplateSelectorを非同期化するアプローチBの優先度を上げよう。ただし、これにはUIの描画遅延リスクが…」と返してくる。
僕「その遅延リスク、具体的にどのくらいヤバい？回避策は？」
AI「回避策としては、プレースホルダー（仮の表示）を使う方法がある。サンプルコードを示す…」
この「対話のキャッチボール」。
これこそが、「転」で話した「思考停止」の真逆。
AIの仮説（意見）によって、僕（人間）の思考が「刺激」され、僕のフィードバック（追加コンテキスト）によって、AIの思考が「軌道修正」される。
このプロセスこそが、フックにあった「人間とAIの深い相互作用（deeper interactions）」であり、「共創（コラボレーション）」の正体です。
AIとの「対話力」が、海外での「対人力」になる
この「AIとの壁打ち」、どこかで経験したことありませんか？
そう。
これって、僕が今いるヨーロッパの多国籍チームで、ドイツ人やインド人のシニアエンジニアたちと、ホワイトボードの前で毎日やっている「設計レビュー」そのものなんです。
海外の（特に欧米の）エンジニアリング現場って、日本のように「仕様書通りに完璧に作りました」という「指示待ち」の人間は、残念ながら評価されません。
評価されるのは、「その仕様書、こっちの観点が抜けてないか？」と**「対案」や「疑問」を投げかけられる人間**です。
自分の意見を持ち、相手の意見を尊重し、お互いの「コンテキスト（背景）」をすり合わせながら、議論（ディスカッション）を通じて、一人ではたどり着けなかった「より良い結論」を「共創」していく。
僕が海外で生き残るために必死で身につけてきたこの「対話力」。
皮肉なことに、AIと本気で付き合おうとすると、この「対話力」が死ぬほど必要になるんです。
「pre-framing」は、AIを縛る魔法の呪文じゃありません。
AIという「異文化（知性）」を持つ同僚に対して、「僕はこういう背景（コンテキスト）を持った人間で、こういうアジェンダ（タスク）について話したいんだけど、君（ペルソナ）はどう思う？」と問いかけるための、「最初の一手」なんです。
「転」で危惧した「機密情報」の問題も、この「対話」の視点があれば解決します。
あなたは、チームの同僚（人間）との最初のブレストで、いきなり会社の全機密情報が書かれたソースコードを丸ごと見せますか？
しないですよね。
まずは「こういう問題があってさ」と「抽象化」したレベルで話し始め、必要に応じて、NDA（秘密保持契約）を結んだ相手であることを確認しながら、情報を小出しにしていくはずです。
AIに対しても、同じです。
まずは「抽象化」したコンテキストで壁打ちを始める。AIが本当に信頼できる「相棒」だと確信できた範囲（あるいは、セキュリティが担保された社内AI環境）でのみ、情報を開示する。
この「リスク管理をしながら対話する能力」こそ、これからのプロフェッショナルの必須スキルです。
結論：AIに「答え」を求めるな。「思考」を深めろ。
僕らは、ChatGPTの登場で、もしかしたら「プログラミング」という作業の一部を手放すことになるかもしれません。
WPFの退屈なXAMLの定型文や、C#の決まりきった非同期処理のラッパーコードは、AIが書いたほうが速いし正確でしょう。
でも、僕らは「作業」を手放す代わりに、もっと大切なものを手に入れようとしています。
それは、**「問題を定義する力」であり、「複数の仮説を比較検討する力」であり、「最終的な意思決定を下す責任」**です。
これこそが、エンジニアの「本質」です。
AIは、「答え」をくれる機械ではありません。
AIは、僕ら人間が「より深い思考」をするための、**史上最強の「壁打ち相手（スパーリング・パートナー）」**なんです。
「pre-framing」は、その最強のパートナーを「本気」にさせるための、礼儀作法（アジェンダの提示）です。
プロンプトは「指示（Command）」じゃない。「対話（Conversation）」だ。
この「隠された次元（Hidden Dimensions）」をアンロックできた時、AIはあなたの仕事を奪う「脅威」ではなく、あなたの能力を10倍、100倍に拡張してくれる「最強の相棒（コラボレーター）」になります。
海外で働くエンジニアとして、技術の変化は常に脅威です。
でも、これほどエキサイティングな「相棒」が登場した時代に、エンジニアでいられることを、僕は心から幸運だと思っています。
さあ、あなたの「相棒」に、今日はどんな「壁打ち」を持ちかけますか？
コメント