WEBVTT

00:00:00.000 --> 00:00:03.040
コパイロットの性能はプロンプト 次第だと誰もが口を揃えて言います

00:00:03.040 --> 00:00:05.180
それは可愛らしい勘違いですが 間違いです

00:00:05.180 --> 00:00:08.080
このエピソードはマイクロソフト 365コパイロットの熟練ユーザー

00:00:08.080 --> 00:00:08.680
に向けたものです

00:00:08.680 --> 00:00:12.460
業務に直結し時間を短縮できる 高度で再現性の高いプロンプト

00:00:12.460 --> 00:00:13.460
手法に焦点を当てます

00:00:13.460 --> 00:00:16.920
コパイロットはマイクロソフト 365のデータを活用できるため構造

00:00:16.920 --> 00:00:19.800
化されたプロンプトと段階的な クエリによって単なる汎用的な

00:00:19.800 --> 00:00:22.400
文章ではなくビジネスの文脈に 即した結果を得られます

00:00:22.400 --> 00:00:25.760
一般的なユーザーはコパイロット に巨大な質問を投げつけうまく

00:00:25.760 --> 00:00:26.780
いくことを祈るだけです

00:00:26.780 --> 00:00:27.360
プロは?

00:00:27.480 --> 00:00:28.620
プロは反復します

00:00:28.620 --> 00:00:32.120
出力がより正確なものになるまで 段階的に洗練させていくのです

00:00:32.120 --> 00:00:35.620
ここで最初の問題すなわち完璧 なプロンプトという神話が浮上

00:00:35.620 --> 00:00:35.880
します

00:00:35.880 --> 00:00:37.700
完璧なプロンプトの神話です

00:00:37.700 --> 00:00:39.040
想像してみてください

00:00:39.040 --> 00:00:42.560
デスクに座り指を鳴らしてまる でポリシー文書のような巨大で

00:00:42.560 --> 00:00:44.740
まとまりのないプロンプトを入力 する人の姿を

00:00:44.740 --> 00:00:47.560
彼らはエンターキーを押し素晴らしい 回答を待ちます

00:00:47.560 --> 00:00:52.220
ネタバレすると帰ってくるのは 汎用的で時に回りくどく深夜2時

00:00:52.220 --> 00:00:54.960
に課題を流し読みしたインターン が書いたような文章です

00:00:54.960 --> 00:00:58.620
問題はコパイロットの知能では なく一度の巨大なプロンプトで

00:00:58.620 --> 00:01:00.720
完璧さを強制できるという神話 なのです

00:01:00.720 --> 00:01:04.600
多くのプロフェッショナルが記述 詞や就職後書式設定キーワード

00:01:04.600 --> 00:01:06.580
を詰め込めば精度が上がると今 でも信じています

00:01:06.580 --> 00:01:08.100
しかし現実は違います

00:01:08.100 --> 00:01:10.620
文脈は構造化されて初めて役立つ のです

00:01:10.620 --> 00:01:15.440
多くの場合ゴールと必要最小限の 文脈の方が105の情報の羅列を

00:01:15.440 --> 00:01:17.900
はるかに上回ります マイクロソフトはフレームワーク

00:01:17.900 --> 00:01:21.040
を提供しています ゴールを述べ関連する文脈を与え

00:01:21.040 --> 00:01:24.000
トーンや書式を決め必要に応じて ソースを指定することです

00:01:24.000 --> 00:01:27.640
この4項目のシンプルなチェックリスト はあなたのフランケンシュタインプロンプト

00:01:27.640 --> 00:01:29.760
を毎回凌駕します こう考えてみてください

00:01:29.760 --> 00:01:32.540
文脈の追加は目的地を明確にする 場合にのみ有用です

00:01:32.540 --> 00:01:35.140
同筋を混乱させるような文脈追加 はむしろ有害です

00:01:35.140 --> 00:01:39.260
昨日の会議を要約してとコパイロット に伝えるこれは明確な目的地です

00:01:39.260 --> 00:01:43.080
しかしそこに式について触れて 人事に言及してトレンドを含めて

00:01:43.080 --> 00:01:47.060
簡潔かつ親しみやすく過剰書 にしてでも物語調にしてなどとあらゆる

00:01:47.060 --> 00:01:49.200
要素を詰め込み始めるとおめでとう ございます

00:01:49.200 --> 00:01:51.640
矛盾した標識だらけの道を作って しまいました

00:01:51.640 --> 00:01:53.780
出力がチグハグになるのも無理 はありません

00:01:53.780 --> 00:01:55.680
凝った料理の例えすら不要でしょう

00:01:55.680 --> 00:01:58.640
レシピなしでお気に入りの食材 を全て鍋に放り込むことを想像

00:01:58.640 --> 00:02:00.760
してください 一応料理にはなりますが罰ゲーム

00:02:00.760 --> 00:02:02.860
のような味になるはずです それこそが完璧な

00:02:02.860 --> 00:02:04.600
プロンプトという誤解の最も 純粋な形です

00:02:04.600 --> 00:02:07.060
コパイロットが進化を発揮する のは順序です

00:02:07.060 --> 00:02:11.040
まずは明確な指示次に宣伝 マイクロソフト自身もコパイロット

00:02:11.040 --> 00:02:13.820
を対話のパートナーとして扱い フォローアップを行うことを期待

00:02:13.820 --> 00:02:15.580
すべきだとその指針で強調しています

00:02:15.580 --> 00:02:18.440
このシステムは一度のテストで 満点を取るようには設計されていません

00:02:18.440 --> 00:02:20.360
やり取りを重ねるために設計 されているのです

00:02:20.360 --> 00:02:22.120
では実際に試してみましょう

00:02:22.120 --> 00:02:26.000
ステップ1機能の会議を要約して ステップ2今度はマーケティング

00:02:26.000 --> 00:02:29.380
チーム向けに1人1つのアクション アイテムを含む6つの過剰書きに

00:02:29.380 --> 00:02:30.080
成形してください

00:02:30.080 --> 00:02:32.960
その2ステップのアプローチは 過剰なプロンプトよりも常に優れた

00:02:32.960 --> 00:02:33.720
結果をもたらします

00:02:33.720 --> 00:02:35.940
もちろん具体的な指示を出す ことに問題はありません

00:02:35.940 --> 00:02:38.960
リクエストを明確に絞り込み形作る ために必要な背景情報は追加すべき

00:02:38.960 --> 00:02:39.140
です

00:02:39.140 --> 00:02:42.500
しかし1つのプロンプトに10もの 異なる目標を詰め込むと出力

00:02:42.500 --> 00:02:44.180
は平均的なものに収束してしまいます

00:02:44.180 --> 00:02:47.520
機械的に条件を埋めるだけでニュアンス は皆無になります

00:02:47.520 --> 00:02:50.340
順序のない複雑さは明快さを 生み出しません

00:02:50.340 --> 00:02:53.900
それはAIに対してどれが重要か を推測させながら過剰な指示を

00:02:53.900 --> 00:02:55.000
無理やり処理させるようなもの です

00:02:55.000 --> 00:02:56.600
簡単な実験をしてみましょう

00:02:56.600 --> 00:02:58.480
まずシンプルなリクエストを試 します

00:02:58.480 --> 00:03:01.040
昨日の会議の内容をマーケティング チーム向けに分かりやすい言葉

00:03:01.040 --> 00:03:01.660
で要約してください

00:03:01.660 --> 00:03:04.780
次に20もの細かい要件を詰め込んだ 過剰なバージョンと比較して

00:03:04.780 --> 00:03:05.160
みてください

00:03:05.160 --> 00:03:08.320
10回中9回は出力結果に劇的な 違いはありません

00:03:08.320 --> 00:03:11.420
ある一線を超えるとAIに自分の まとまりのないスタイルを模倣

00:03:11.420 --> 00:03:12.520
させているに過ぎなくなります

00:03:12.520 --> 00:03:16.260
ノイズを減らせばシステムがより 鋭く実用的な仕事で答えてくれる

00:03:16.260 --> 00:03:17.100
ことに気づくでしょう

00:03:17.100 --> 00:03:20.940
成果を出しているプロは隠された 裏技のような完璧なプロンプト

00:03:20.940 --> 00:03:21.840
を追い求めてはいません

00:03:21.840 --> 00:03:24.780
彼らはこのシステムが完璧な 文章を魔法のように生み出す精霊

00:03:24.780 --> 00:03:25.680
ではないことを知っています

00:03:25.680 --> 00:03:28.160
これは反復のために調整された ツールなのです

00:03:28.160 --> 00:03:31.220
頭の中にあるものを一度に投げ込んで 祈るのではなくコパイロット

00:03:31.220 --> 00:03:32.240
を一歩ずつ導くのです

00:03:32.240 --> 00:03:33.880
つまり結論はこうです

00:03:33.880 --> 00:03:37.100
過剰なエンジニアリングよりも 反復の方が常に優れています

00:03:37.100 --> 00:03:40.640
完璧なプロンプトなど存在せず あると信じ込むことはあなたの

00:03:40.640 --> 00:03:41.760
足を引っ張るだけです

00:03:41.760 --> 00:03:45.460
試行錯誤するアマチュアと熟練 した操作者を分けるのはもっと

00:03:45.460 --> 00:03:49.320
地に足のついた体系的なプロンプト の積み重ねという手法です

00:03:49.320 --> 00:03:53.380
そしてその手法は皆さんがすでに 知っている別の分野つまりエンジニア

00:03:53.380 --> 00:03:55.780
の秘密兵器である反復とよく似ています

00:03:55.780 --> 00:03:58.320
反復こそがエンジニアの秘密兵器 なのです

00:03:58.320 --> 00:04:01.780
一般的なユーザーは巨大なプロンプト を一度投げるだけで全てが完結

00:04:01.780 --> 00:04:03.140
するという幻想にしがみついて います

00:04:03.140 --> 00:04:04.240
フローは違います

00:04:04.240 --> 00:04:07.520
彼らはタスクを層に分けエンジニア が耐久性のあるものを作るのと

00:04:07.520 --> 00:04:09.700
同じように各段階を確認しながら 進めます

00:04:09.700 --> 00:04:12.720
まずは土台次に骨組みそして細部 という順序です

00:04:12.720 --> 00:04:15.840
全ての指示を一つの段落に詰め込む よりも順序とチェックポイント

00:04:15.840 --> 00:04:16.700
の型が重要です

00:04:16.700 --> 00:04:19.700
単発のプロンプトにおける最大 の間違いは一度に10の問題を

00:04:19.700 --> 00:04:20.780
解決しようとすることです

00:04:20.780 --> 00:04:25.220
鋭いようやく説得力のある物語 埋め込み図表リスク分析そして

00:04:25.220 --> 00:04:28.100
明るく権威あるトーンを一度に 求めればコパイロットはそれら

00:04:28.100 --> 00:04:29.880
全てを同時に処理しようとして 混乱します

00:04:29.880 --> 00:04:33.300
その結果は中途半端な妥協案 が出来上がり要件の半分は満たして

00:04:33.300 --> 00:04:34.900
もどれも満足いく仕上がりには なりません

00:04:34.900 --> 00:04:37.900
10個のことを同時にこなそうとして 結局は凡庸なものになってしまう

00:04:37.900 --> 00:04:38.160
のです

00:04:38.160 --> 00:04:40.800
反復的なプロンプト手法は一度に 一つの目標に集中すること

00:04:40.800 --> 00:04:41.500
でこれを解決します

00:04:41.500 --> 00:04:43.820
ドラフトを作成し見直し洗練 させる

00:04:43.820 --> 00:04:46.140
エンジニアはナプキンに一度 スケッチを書いただけで吊り橋

00:04:46.140 --> 00:04:47.380
の設計を完了させたりはしません

00:04:47.380 --> 00:04:50.340
彼らはモデルを作り付加試験 を行い修正しそしてそれを繰り返す

00:04:50.340 --> 00:04:50.600
のです

00:04:50.600 --> 00:04:52.640
コパイロットも同じリズムでこそ 進化を発揮します

00:04:52.640 --> 00:04:55.540
このプロセスが遅く感じられる のはエンターキーを叩く速さだけ

00:04:55.540 --> 00:04:56.780
で進捗を図る人だけです

00:04:56.780 --> 00:05:00.060
本当に使える成果を重視する人 なら反復作業こそが手戻りを

00:05:00.060 --> 00:05:02.340
防ぎ真の時間短縮につながる ことを知っています

00:05:02.340 --> 00:05:05.720
実際マイクロソフトの公式ドキュメント でもこれが標準的な戦略として

00:05:05.720 --> 00:05:06.400
推奨されています

00:05:06.400 --> 00:05:09.320
彼らはコパイロットを魔法の ように文章を出す自動販売機だ

00:05:09.320 --> 00:05:09.860
とは言っていません

00:05:09.860 --> 00:05:13.160
ガイダンスではやりとりが発生 することを前提とし出力を出発

00:05:13.160 --> 00:05:15.520
点として扱い体系的に磨き上げる よう助言しています

00:05:15.520 --> 00:05:18.780
プロンプトには4つの明確な要素 を含めることさえ推奨しています

00:05:18.780 --> 00:05:22.960
目標の提示背景の共有期待値の 設定そして必要に応じたソース

00:05:22.960 --> 00:05:23.560
の提供です

00:05:23.560 --> 00:05:25.660
プロはこれらをチェックポイント として利用します

00:05:25.660 --> 00:05:28.540
最初の回答が得られたらすぐ に妥当性の確認を行います

00:05:28.540 --> 00:05:32.160
目標に沿っているか背景情報は 正しく反映されているかそうで

00:05:32.160 --> 00:05:34.300
なければ装飾を加える前にまず 修正します

00:05:34.300 --> 00:05:37.000
研修などを受けなくてもすぐに 使える手順を教えましょう

00:05:37.000 --> 00:05:39.180
まずは平易な言葉でドラフトを 作成します

00:05:39.180 --> 00:05:42.200
第4四半期の決算結果を簡潔な 段落で要約させます

00:05:42.200 --> 00:05:43.920
次にフォーマットを指定します

00:05:43.920 --> 00:05:46.800
それを経営人向けのブリーフィング 形式に変換します

00:05:46.800 --> 00:05:49.580
その上で特定の要点を抽出させます

00:05:49.580 --> 00:05:52.860
収益の傾向とアクションアイテム を過剰書きで追加します

00:05:52.860 --> 00:05:55.360
最後に伝達用に調整します

00:05:55.360 --> 00:05:58.740
リーダーシップチーム宛ての 短いメール形式で作成します

00:05:58.740 --> 00:06:00.060
この4ステップです

00:06:00.060 --> 00:06:03.160
各段階で洗練させ用途に合わせて 再構成することで

00:06:03.160 --> 00:06:05.520
コパイロットに無理やり詰め込ませる 必要がなくなります

00:06:05.520 --> 00:06:08.600
このテンプレートは様々なビジネス シーンで使えることに気づくでしょう

00:06:08.600 --> 00:06:10.560
販売実績や製品ロードマップの更新

00:06:10.560 --> 00:06:12.480
顧客アンケート分析などに 置き換えてみてください

00:06:12.480 --> 00:06:16.240
ようやくビジネス形式要点抽出 伝達という順序はそのまま応用

00:06:16.240 --> 00:06:16.520
できます

00:06:16.520 --> 00:06:18.940
これは一言一句暗記するための 台本ではありません

00:06:18.940 --> 00:06:20.400
コパイロットを混乱させるのではなく

00:06:20.400 --> 00:06:22.660
背景的に導くための信頼できる 構造なのです

00:06:22.660 --> 00:06:25.600
素人がほとんど必ず飛ばすステップ それが検証です

00:06:25.600 --> 00:06:28.040
生成されたものをそのまま鵜呑み にしてはいけません

00:06:28.040 --> 00:06:31.580
マイクロソフトもコパイロットからの 回答は必ず確認し検証するよう

00:06:31.580 --> 00:06:32.500
強く促しています

00:06:32.500 --> 00:06:35.220
反復は単にトーンを整えるためだけ のものではありません

00:06:35.220 --> 00:06:38.240
それは事実関係の正確性を担保 するチェックポイントなのです

00:06:38.240 --> 00:06:41.960
各ステップの後でデータの欠落 や曖昧な主張根拠のない自信過剰

00:06:41.960 --> 00:06:43.240
な記述がないかを確認してください

00:06:43.240 --> 00:06:45.660
システムを有能なインターン だと考えましょう

00:06:45.660 --> 00:06:48.780
下調べはしてくれますが最終的な 成果物はあなたが責任を持って

00:06:48.780 --> 00:06:50.320
確認し承認しなければなりません

00:06:50.320 --> 00:06:51.980
反復作業は地味に見えます

00:06:51.980 --> 00:06:55.160
一度の完璧なプロンプトで魔法 を起こすような華やかさはありません

00:06:55.160 --> 00:06:58.080
しかし一貫してよりスマートで 洗練された成果を生み出します

00:06:58.080 --> 00:07:01.600
無駄が省け修正の手間が減り 出力の品質を自分でコントロール

00:07:01.600 --> 00:07:01.900
できます

00:07:01.900 --> 00:07:04.260
エンジニアがせっかちだという 理由でドラフトを飛ばすことは

00:07:04.260 --> 00:07:07.160
ありませんしプロがコパイロット に一度で完璧な回答を期待する

00:07:07.160 --> 00:07:07.740
こともありません

00:07:07.740 --> 00:07:08.920
もうお分かりでしょう

00:07:08.920 --> 00:07:11.660
段階的なプロンプトは高度な テクニックではありません

00:07:11.660 --> 00:07:14.060
コパイロットを正しく使いこなす ための基本なのです

00:07:14.060 --> 00:07:16.100
しかしそれだけではまだ不十分 です

00:07:16.100 --> 00:07:19.440
コパイロットの進化は適切な背景 情報を与え始めた時に発揮され

00:07:19.440 --> 00:07:19.600
ます

00:07:19.600 --> 00:07:22.560
なぜならコパイロットにどの ような背景情報を与えるかによって

00:07:22.560 --> 00:07:25.600
最終的な結果が一般的なもの になるかそれともあなたの世界観

00:07:25.600 --> 00:07:27.240
に完璧に沿ったものになるかが 決まるからです

00:07:27.240 --> 00:07:29.680
背景情報それは秘伝のソース です

00:07:29.680 --> 00:07:33.260
設計図も渡さずに建設業者に12 階建てのオフィスビルを建てて

00:07:33.260 --> 00:07:34.360
くれとは頼まないはずです

00:07:34.360 --> 00:07:37.000
しかしコパイロットを使う際人々 はまさにそれと同じことを常に

00:07:37.000 --> 00:07:37.300
言っています

00:07:37.300 --> 00:07:40.260
下書きを書いてと命じたりレポート を作ってと要求したりします

00:07:40.260 --> 00:07:43.080
そして出てきたものが高校の教科書 のように退屈で魂のない

00:07:43.080 --> 00:07:44.800
ものだと知ると深底等枠する のです

00:07:44.800 --> 00:07:46.760
ai がポイントを外したわけでは ありません

00:07:46.760 --> 00:07:48.520
あなたがポイントを与えなかった のです

00:07:48.520 --> 00:07:51.100
背景情報は装飾ではなく構造その ものです

00:07:51.100 --> 00:07:53.700
それがなければコパイロットは真空 の中で作業しているようなもので

00:07:53.700 --> 00:07:56.740
空を切るハンマーを振り回し戦略 を装ったデジタル版のモチベーション

00:07:56.740 --> 00:07:58.060
ポスターを作成することになって しまいます

00:07:58.060 --> 00:08:01.680
組織のテンプレート社内専門用語 独自の文体基盤となるプロセス

00:08:01.680 --> 00:08:03.820
これらは決してオプションの飾り ではありません

00:08:03.820 --> 00:08:05.240
それらは足場なのです

00:08:05.240 --> 00:08:08.540
それらをそぎ落とせばコパイロット は誰のものでもない一般的な文章

00:08:08.540 --> 00:08:09.600
を生成するだけになります

00:08:09.600 --> 00:08:12.440
ポリシーを書いてやアウトライン を作成してといったデフォルト

00:08:12.440 --> 00:08:15.060
のプロンプトではほとんどの場合 同じようにデフォルトの結果しか

00:08:15.060 --> 00:08:15.460
得られません

00:08:15.460 --> 00:08:19.020
コパイロットが賢くないからでは なくあなたが認識可能なDNAを与えて

00:08:19.020 --> 00:08:19.520
いないからです

00:08:19.520 --> 00:08:22.100
一般的なユーザーは社内用語 を省いてしまうためコパイロット

00:08:22.100 --> 00:08:24.060
は一般的で中立的な言い回し に頼ることになります

00:08:24.060 --> 00:08:26.880
そしてビジネス文書における中立性 はほとんどの場合生命力のない

00:08:26.880 --> 00:08:27.520
ものに読めてしまいます

00:08:27.520 --> 00:08:30.080
プロフェッショナルが真に求 めているのは梅草ではなく整合性

00:08:30.080 --> 00:08:30.280
です

00:08:30.280 --> 00:08:31.620
違いを比較してみましょう

00:08:31.620 --> 00:08:34.280
投げやりなプロンプトだとリモート ワークのポリシーを起訴してと

00:08:34.280 --> 00:08:34.560
なります

00:08:34.560 --> 00:08:38.100
返答は固くありきたりなビジネス の決まり文句で溢れたものになります

00:08:38.100 --> 00:08:40.340
しかし背景情報を加えてみてください

00:08:40.340 --> 00:08:43.520
顧客への迅速な対応柔軟なスケジュール そして全レベルにおけるオーナー

00:08:43.520 --> 00:08:45.640
シップというコアバリューを重視する 中堅コンサルティング企業向けに

00:08:45.640 --> 00:08:47.560
リモートワークのポリシーを起訴してと指示します

00:08:47.560 --> 00:08:49.400
すると突然トーンが変わります

00:08:49.400 --> 00:08:51.800
その下書きはどこかのランダムな テンプレートから取ってきたように

00:08:51.800 --> 00:08:52.220
は聞こえません

00:08:52.220 --> 00:08:54.940
あなたの会社のhrチームが全市販機 に実際に取り組んだもののように

00:08:54.940 --> 00:08:55.300
聞こえます

00:08:55.300 --> 00:08:57.720
秘訣は単語の数ではなくより 鋭い言葉を選ぶことでした

00:08:57.720 --> 00:08:59.660
hrの例で見るとよくわかります

00:08:59.660 --> 00:09:02.840
あるチームは職場のドレスコード を書いてと入力します

00:09:02.840 --> 00:09:07.000
するとコパイロットは90年代の 企業のロビーに貼ってありそうな

00:09:07.000 --> 00:09:09.640
魂のない官僚的な言葉を吐き出します

00:09:09.640 --> 00:09:12.040
別のチームは背景情報を与えます

00:09:12.040 --> 00:09:14.040
ブランドの誠実さカジュアルな プロフェッショナリズムそして

00:09:14.040 --> 00:09:15.880
クライアントに好印象を与える プレゼンテーションを重視する

00:09:15.880 --> 00:09:17.880
私たちのクリエイティブエージェンシー のためのドレスコードを書いて

00:09:17.880 --> 00:09:18.380
と指示します

00:09:18.380 --> 00:09:21.140
aiはあなたの言葉遣いや文化を 反映するようになりました

00:09:21.140 --> 00:09:23.240
システムは同じですが足場が異なり ます

00:09:23.240 --> 00:09:26.020
前者は単なる退屈な規則に聞こえ ましたが後者はまさにあなたの

00:09:26.020 --> 00:09:27.500
会社の手引書から取ってきたように 聞こえました

00:09:27.500 --> 00:09:29.760
ここで人々は物事を複雑に考えすぎて しまいます

00:09:29.760 --> 00:09:32.460
背景情報を含めるには会社の 手引書全体をプロンプトに貼り付ける

00:09:32.460 --> 00:09:33.520
必要があると考えているのです

00:09:33.520 --> 00:09:34.560
それは間違いです

00:09:34.560 --> 00:09:37.220
背景情報の量は重要ではなく 重要なのは妥当性です

00:09:37.220 --> 00:09:40.040
コパイロットにイントラネットの 全てを読み込ませる必要はありません

00:09:40.040 --> 00:09:43.600
あなたの環境を真に定義するいく つかの重要な情報だけで十分です

00:09:43.600 --> 00:09:47.860
3つの企業価値5つの専門用語あるいは 普段使っているテンプレートの構成

00:09:47.860 --> 00:09:48.860
案などがそれに当たります

00:09:48.860 --> 00:09:53.120
プロは職場の雰囲気を決定づける 少数の要素を含めておき残りは

00:09:53.120 --> 00:09:54.300
コパイロットに保管させます

00:09:54.300 --> 00:09:56.460
そのための実用的な方法を紹介 します

00:09:56.460 --> 00:09:59.040
マイクロソフトがすでに統合している 機能を活用することです

00:09:59.040 --> 00:10:01.600
コパイロットはマイクロソフト グラフやコンテキストiQといった

00:10:01.600 --> 00:10:03.380
ツールを通じて社内データを取り 込みます

00:10:03.380 --> 00:10:07.300
精度が必要なら適切なドキュメント や例を参照させ判断の根拠を与

00:10:07.300 --> 00:10:07.680
えてください

00:10:07.680 --> 00:10:10.180
コパイロットに単独で独自の 口調を生み出させようとしない

00:10:10.180 --> 00:10:10.520
でください

00:10:10.520 --> 00:10:12.980
ライブラリの正しい棚へのアクセス 権を与えるのです

00:10:12.980 --> 00:10:16.300
そうすることで出力結果があなたの ビジネスにふさわしいものになります

00:10:16.300 --> 00:10:19.020
もう一つのプロの習慣は再利用 です

00:10:19.020 --> 00:10:22.980
高品質なドラフトを出力する文脈 豊かな優れたプロンプトを作れた

00:10:22.980 --> 00:10:26.020
なら次のプロジェクトでゼロから 作り直す必要はありません

00:10:26.020 --> 00:10:28.580
洗練されたプロンプトを再利用 可能なテンプレートとして保存

00:10:28.580 --> 00:10:30.840
し自分や同僚が繰り返し使える ようにしましょう

00:10:30.840 --> 00:10:33.820
マイクロソフトも効果的なプロンプト の構成を保存共有することを

00:10:33.820 --> 00:10:34.440
推奨しています

00:10:34.440 --> 00:10:37.160
プロはプロンプトを使い回しアマチュア は打ち直します

00:10:37.160 --> 00:10:38.540
その差は歴然です

00:10:38.540 --> 00:10:42.420
文脈があればコパイロットは代筆 するだけの他人ではなく長年会議

00:10:42.420 --> 00:10:44.580
に参加してきた社内の人間のような 口調になります

00:10:44.580 --> 00:10:47.440
そうでなければ決まりきった方通り の回答しか得られません

00:10:47.440 --> 00:10:50.540
新入社員にオンボーディングなし で初日から社内の流儀で流暢に

00:10:50.540 --> 00:10:52.000
話すことを期待する人はいない でしょう

00:10:52.000 --> 00:10:53.420
コパイロットも同じです

00:10:53.420 --> 00:10:55.740
魔法使いではなく同僚として扱う べきです

00:10:55.740 --> 00:10:58.360
反復はプロセスを磨き文脈は 中身を充実させます

00:10:58.360 --> 00:11:01.340
しかしコパイロットの出力を左右 するもう一つの要素があります

00:11:01.340 --> 00:11:03.880
あなた自身も気づいていない かもしれないシグナルのような

00:11:03.880 --> 00:11:04.220
ものです

00:11:04.220 --> 00:11:07.360
同じリクエストでも言い方を変える だけで結果が少し変わるだけで

00:11:07.360 --> 00:11:10.320
なく全く異なる世界へ導かれる 可能性があるからです

00:11:10.320 --> 00:11:12.420
それがトーン隠されたレバー です

00:11:12.420 --> 00:11:15.480
トーン口調は多くの人が活用 できていない隠れたレバーです

00:11:15.480 --> 00:11:19.240
多くの人は内容キーワード要件構造 ばかりに固執し項目を埋める

00:11:19.240 --> 00:11:20.640
ことが品質を保証すると信じています

00:11:20.640 --> 00:11:24.020
しかし秘訣は何を言うかだけでなく どのように尋ねるかにあります

00:11:24.020 --> 00:11:27.700
コパイロットは命令だけでなく表現 の機微も読み取りトーンによって

00:11:27.700 --> 00:11:31.680
役割を判断します厳格な実行者 か創造的なアイデア出し役かあるい

00:11:31.680 --> 00:11:34.420
は協力的なチームメイトか3つの 命令を創造してください

00:11:34.420 --> 00:11:38.960
まず外部監査向けのコンプライアンス 要約を作成せよこれは指示的ディレクティブ

00:11:38.960 --> 00:11:42.860
ですエンジンはルール遵守モード になりホームや財務人事ポリシー

00:11:42.860 --> 00:11:47.360
など逸脱が許されない場面に最適 な安全で標準的な文章を作成します

00:11:47.360 --> 00:11:50.380
次にこのキャンペーンのアイデア を提示するための3つの選択肢を

00:11:50.380 --> 00:11:53.420
ブレインストーミングせよこれは 探索的エクスプロラトリーです

00:11:53.420 --> 00:11:56.440
コパイロットは範囲を広げ様々 なバリエーションを試し創造的な

00:11:56.440 --> 00:11:59.560
アイデアを提案します3つ目に強力 的なチームメイトとして振る舞い

00:11:59.560 --> 00:12:02.900
この草案に対する代替案を提案 してくださいこれが強力的なアプローチ

00:12:02.900 --> 00:12:05.340
です今やシステムはアイデアの パートナーのように振る舞い対話

00:12:05.340 --> 00:12:08.400
を通じてあなたと共に構築を行います 同じツールでもトーンを変えれば

00:12:08.400 --> 00:12:10.920
3つの全く異なる結果が得られ ますこれが驚きに感じられる

00:12:10.920 --> 00:12:13.100
かもしれませんがそうあるべき ではありませんマイクロソフト

00:12:13.100 --> 00:12:15.800
のドキュメントにも言葉のわず かな変化が出力を大きく変える

00:12:15.800 --> 00:12:19.300
とありますこれは欠陥ではなく 機能なのですプロは出力が平坦

00:12:19.300 --> 00:12:22.020
に感じられたときまずトーンを 調整することでこの性質を活用

00:12:22.020 --> 00:12:25.060
しますプロンプと全体を書き直す 前にまずは1単語だけ入れ替えて

00:12:25.060 --> 00:12:29.200
みてください要約してをアドバイス してに変える分析してをブレインストーミング

00:12:29.200 --> 00:12:33.160
してに変える草案を作成してを 協力して作成してに変える生命のない

00:12:33.160 --> 00:12:36.720
要約が急いで書いた会議メモの ように感じられたり味気ない草案が

00:12:36.720 --> 00:12:39.200
生き生きとした売り込み文句に 変わる様子をご覧くださいトーン

00:12:39.200 --> 00:12:43.000
は飾りではなく舵取りなのです 単純な指示よりも比喩の方が理解

00:12:43.000 --> 00:12:46.020
しやすいようですので少し料理 の例に戻りましょうレストラン

00:12:46.020 --> 00:12:49.500
に入りこの料理をレシピ通りに 作れと命じるとしますシェフ

00:12:49.500 --> 00:12:53.420
は機械的に従いますこれが指示 的なアプローチですでは地中海風

00:12:53.420 --> 00:12:56.660
で野菜を多めにと言ってみます シェフはスタイルを解釈します

00:12:56.660 --> 00:12:59.500
これが探索的なアプローチです もし代わりに食材の入った

00:12:59.500 --> 00:13:02.580
カゴを渡して何ができると尋ね たらどうでしょうあなたはキッチン

00:13:02.580 --> 00:13:04.880
にコラボレーションを持ち込んだ ことになりますコパイロットの

00:13:04.880 --> 00:13:07.960
反応もこれと同じですレシピ は存在しますがトーンがシェフ

00:13:07.960 --> 00:13:11.300
の個性を決定づけるのですコパイロット の出力に満足できなかったときに

00:13:11.300 --> 00:13:14.780
試せる簡単な練習があります出力 が平坦に感じても慌てずテキスト

00:13:14.780 --> 00:13:17.840
を自分で編集してくださいただ これを営業チーム向けにすぐに

00:13:17.840 --> 00:13:21.020
実行可能な要点として書き直して と頼むだけですごく些細なこと

00:13:21.020 --> 00:13:25.260
です数秒で済みますがエネルギー の変化は即座に現れます突然退屈

00:13:25.260 --> 00:13:27.980
な段落の代わりにターゲットに 適したスッキリとしたリストが

00:13:27.980 --> 00:13:30.620
得られますこれはコパイロット が賢くなったのではなくあなた

00:13:30.620 --> 00:13:33.740
がその存在に気づいていなかった レバーを引いたのです確かに一般

00:13:33.740 --> 00:13:36.900
的なユーザーはトーンを軽視し がちですそれを命令に付随する

00:13:36.900 --> 00:13:40.120
単なる装飾や見せかけだと思 っているからですプロはスタイル

00:13:40.120 --> 00:13:43.640
こそがペルソナを定義することを 知っていますトーンを設定しなければ

00:13:43.640 --> 00:13:47.640
コパイロットは汎用的なライター モードつまり誰を不快にさせず

00:13:47.640 --> 00:13:51.500
誰にも感銘を与えない単調なインターン として振る舞いますトーンを指定

00:13:51.500 --> 00:13:54.540
することでaiにアイデンティティ を与えられますコンプライアンス

00:13:54.540 --> 00:13:57.280
担当官クリエイティブパートナー 戦略アドバイザーといった具合

00:13:57.280 --> 00:14:00.060
にトーンはコパイロットに対し 何をすべきかだけでなくこの会話

00:14:00.060 --> 00:14:03.580
において何者であるかを伝えます 実を言うとトーンの調整は多くの

00:14:03.580 --> 00:14:07.280
場合最も迅速かつ効率的な改善 ステップです平凡な草案は必ずしも

00:14:07.280 --> 00:14:10.060
内容が間違っていることを意味 しません枠組みが安易だったということ

00:14:10.060 --> 00:14:13.440
を意味するのです読者は後から 修正して退屈さを一つ一つ取り

00:14:13.440 --> 00:14:16.920
除こうと無駄な時間を費やします が最初からトーンを指定すればその

00:14:16.920 --> 00:14:19.840
手間を完全に防げたはずなのです プロはドラフトの後にトーンを

00:14:19.840 --> 00:14:24.000
修正せずドラフトの前に形作る 反復はプロセスに構造を与える

00:14:24.000 --> 00:14:28.520
コンテキストは足場を提供する しかし最終的な成果物に形と個性

00:14:28.520 --> 00:14:31.620
を与えるのはトーンだ トーンを書けば機械的で味気ない

00:14:31.620 --> 00:14:34.740
ものになる トーンを意識的に活用すればコパイロット

00:14:37.280 --> 00:14:42.140
この3つの要素反復コンテキスト トーンがコパイロットを単なる

00:14:42.140 --> 00:14:46.420
文書作成機から賢いパートナー へと変える基本を習得したと思った

00:14:46.420 --> 00:14:51.960
矢先基盤となるモデルがまた変化 するシステムは進化しニュアンス

00:14:51.960 --> 00:14:59.060
記憶力整合性が向上する つまり培った習慣が強みにも弱み

00:14:59.060 --> 00:15:05.880
にもなる gpt 5の登場だ頭脳は強化され ルールはそのまま新世代のモデル

00:15:05.880 --> 00:15:10.680
が登場する処理能力は向上しルール はそのまま技術の飛躍は必要な

00:15:10.680 --> 00:15:14.200
スキルの減少を意味すると人々 は考えるネタバレだがそうではない

00:15:14.200 --> 00:15:18.860
最新のアップデートは指示のニュアンス コンテキストの保持長文作成時

00:15:18.860 --> 00:15:22.800
の推論能力を向上させるだけだ それだけだ聞き取り能力が向上

00:15:22.800 --> 00:15:25.160
するということだ しかしエンジンが賢くなれば

00:15:25.160 --> 00:15:28.520
プロンプトの規律を無視できる と考えるなら進化の意義を吐き違えている

00:15:28.520 --> 00:15:32.320
真のアップグレードとはこれだ 新しいモデルは会話のコンテキスト

00:15:32.320 --> 00:15:36.240
を長く保持するため数回前の やり取りを忘れることなく回想

00:15:36.240 --> 00:15:39.720
的な指示を出せる 微妙な差異を理解する能力も高い

00:15:39.720 --> 00:15:43.680
トーンや役割の指定を求めれば 中途半端な推測ではなく意図した

00:15:43.680 --> 00:15:47.040
通りの結果が得られる また長文でも繰り返しや脱線

00:15:47.040 --> 00:15:51.440
を避け一貫した構成を維持できる これは進歩だが私が言わなかった

00:15:51.440 --> 00:15:54.420
ことに注意してほしい この進化によって巧みなプロンプト

00:15:54.420 --> 00:15:57.520
の必要性が消えるわけではない 広まっている神話は予測通り

00:15:57.520 --> 00:15:59.560
だ モデルが優秀になるほどプロンプト

00:15:59.560 --> 00:16:02.760
は重要でなくなる 間違いだ それは高性能な車を渡され

00:16:02.760 --> 00:16:05.960
自動運転だと勘違いするような ものだ ハンドルを操作する方法は

00:16:05.960 --> 00:16:08.820
知っておく必要がある 基礎ができなければアップグレード

00:16:08.820 --> 00:16:12.680
された機械も救いにはならない あなたのミスをより早くより滑らか

00:16:12.680 --> 00:16:17.040
により自信満々に拡大するだけ だ モデルの改善は責任を軽減する

00:16:17.040 --> 00:16:20.880
のではなく増大させる 反復コンテキストトーンが全て

00:16:20.880 --> 00:16:24.080
を支配するがエラーも拡大する ためリスクはより高くなる

00:16:24.080 --> 00:16:28.020
曖昧で矛盾した指示を与えれば 古いバージョンのように明らかに

00:16:28.020 --> 00:16:31.320
崩壊するわけではない その代わり一見良さそうな洗練

00:16:31.320 --> 00:16:34.580
された無意味な文章を生成する それこそが危険なのだ

00:16:34.580 --> 00:16:39.000
素人はそれを最終項として受け入れる プロは不一致に気づき軌道修正

00:16:39.000 --> 00:16:41.340
する モデルが強力になるほど両者の

00:16:41.340 --> 00:16:43.600
溝は深まる 例を挙げて説明しましょう

00:16:43.600 --> 00:16:45.760
あなたがエグゼクティブレポート を作成しているとします

00:16:45.760 --> 00:16:48.520
古いモデルは往々にして序盤の ポイントを見失っていました

00:16:48.520 --> 00:16:52.340
冒頭で定義した重要な用語を 忘れたり結論で矛盾が生じたり

00:16:52.340 --> 00:16:54.860
したものです 一方で新しいモデルは文脈

00:16:54.860 --> 00:16:57.680
をしっかりと維持します 第一セクションは物語帳の要約

00:16:57.680 --> 00:17:00.760
にして続く第二セクションで グラフとリスク分析を加え内容

00:17:00.760 --> 00:17:03.580
を深めてくれと指示できます システムが論理的に繋がりを

00:17:03.580 --> 00:17:05.940
生み出します 以前の指示を記憶しそれを

00:17:05.940 --> 00:17:08.020
補強するのです レポートは継ぎはぎではなく

00:17:08.020 --> 00:17:11.440
統合されたものとして完成します プロンプト技術から解放された

00:17:11.440 --> 00:17:14.420
ように聞こえますか いいえなぜなら最初の依頼に

00:17:14.420 --> 00:17:17.360
20個の矛盾する指示を詰め込ん でも新しいモデルは目に見えて

00:17:17.360 --> 00:17:19.860
崩壊することはないからです 流暢でプロフェッショナルに聞こえる

00:17:19.860 --> 00:17:23.000
内容を生成し受け取った瞬間 は感心させられますが後でそれが

00:17:23.000 --> 00:17:26.120
的外れだと気づくことになります その表面的な洗練さが根本的な

00:17:26.120 --> 00:17:29.000
ズレを覆い隠してしまうのです 一般的なユーザーはまあいいかと

00:17:29.000 --> 00:17:31.780
そのまま完了にしてしまいます プロは承認する前に検証を

00:17:31.780 --> 00:17:34.060
行います そして検証の重要性はかつてない

00:17:34.060 --> 00:17:36.160
ほど高まっています コパイロットは詳細の根拠となった

00:17:36.160 --> 00:17:39.320
場所を注釈として示すことが できます どのメール会議メモまたは

00:17:39.320 --> 00:17:41.940
ドキュメントがこのセクションを 裏付けているか示してと実際に

00:17:41.940 --> 00:17:44.780
尋ねることができるのです そうすることで単に文章の流暢

00:17:44.780 --> 00:17:48.000
さに関心するだけでなくその根拠 を確認できます これが隠された

00:17:48.000 --> 00:17:50.040
真実です 優れたツールは競争条件を

00:17:50.040 --> 00:17:52.480
均一化するわけではありません むしろ差を広げるのです

00:17:52.480 --> 00:17:55.980
高度なモデルは良い習慣を増幅 し怠慢な習慣に罰を与えます

00:17:55.980 --> 00:17:59.380
すでに反復のやり方を知っている 規律あるプロはより大きなレバレッジ

00:17:59.380 --> 00:18:02.800
を得て崩壊することなく複雑 さを扱いより深く明確な指示を

00:18:02.800 --> 00:18:05.300
通せるようになります 完璧なプロンプトという神話を

00:18:05.300 --> 00:18:08.760
信じ続けるカジュアルなユーザー は質の高い平凡な結果を生み出す

00:18:08.760 --> 00:18:11.160
だけです 言葉は見栄えが良くなりますが中身

00:18:11.160 --> 00:18:14.180
は浅いままです 強力な入力は出力を高め雑な入力

00:18:14.180 --> 00:18:17.060
はゴミを増やすだけです ですからあなたの指針は変わりません

00:18:17.060 --> 00:18:20.600
より研ぎ澄まされるだけです 体系的なプロンプト工程の設計

00:18:20.600 --> 00:18:24.020
文脈の足場作り意図したトーンの 維持こそが唯一の部よりできる

00:18:24.020 --> 00:18:26.080
方法なのです モデルは増幅器であり奇跡

00:18:26.080 --> 00:18:29.340
を起こす魔法使いではありません 鋭い道具として扱えばより綺麗

00:18:29.340 --> 00:18:32.220
に切り出せます 扱いを誤れば華麗に自分を傷つける

00:18:32.220 --> 00:18:34.780
ことになります だからこそ今幻想を追い求める

00:18:34.780 --> 00:18:37.200
のをやめてシステムを構築する ことが不可欠なのです

00:18:37.200 --> 00:18:40.140
反復のためのシステム文脈管理 のためのシステムトーン調整

00:18:40.140 --> 00:18:42.540
のためのシステムです 最新のモデルは構造化された

00:18:42.540 --> 00:18:46.300
指示に対して一貫性のある高品質 な結果で答えます 構造を無視すれば着飾った

00:18:46.300 --> 00:18:49.200
ナンセンスが返ってくるだけです それがあなたが今後心に留めて

00:18:49.200 --> 00:18:51.200
おくべき最後のポイントへの舞台 となります

00:18:51.200 --> 00:18:54.960
プロは神話のような完璧なプロンプト をひねり出すために時間を無駄に

00:18:54.960 --> 00:18:57.340
しません 彼らは反復文脈トーンという

00:18:57.340 --> 00:19:00.080
システムを構築するのです コパイロットの出力を詰め物に

00:19:00.080 --> 00:19:02.880
崩落させるのではなくインテリジェンス へと収束させるための3つのレバー

00:19:02.880 --> 00:19:05.040
です 真実は通列ですがシンプルです

00:19:05.040 --> 00:19:08.760
プロンプトは魔法ではなく練習 なのです 構造が常に勝ります

00:19:08.760 --> 00:19:12.080
では実際に動いてみましょう チャンネル登録をしてコメント

00:19:12.080 --> 00:19:14.560
欄にこれまでで一番難しかった コパイロットへのプロンプト失敗

00:19:14.560 --> 00:19:16.240
談そして小さな成功体験を書いて ください

00:19:16.240 --> 00:19:19.700
そうです書き出してみてください そうすれば上達しますし次に何を

00:19:19.700 --> 00:19:22.840
分析すべきかが見えてきます 規律を選びましょう明石さを選び

00:19:22.840 --> 00:19:24.040
ましょうボタンを押してください