1. はじめに:ツール進化がもたらすChatGPTの新境地
前回のセッションでは、ChatGPTの驚くべき進化、特にGPT-4o以降に顕著になった「ツール連携」と「エージェントのような振る舞い」に焦点を当てました。チャットインターフェースの中で様々な外部ツール(Webブラウジング、画像生成、コード実行など)をシームレスに呼び出し、活用できるようになったことで、ChatGPTは単なる対話AIを超え、複雑なタスクを遂行する強力な「エージェント」へと変貌を遂げつつあります。
この能力を最大限に引き出す鍵となるのが、「バイブコーディング」と称する、ツール呼び出しを意識したプロンプト技術です。「画像生成してください」「Webブラウジングを使って最新情報を取得して」といった具体的な指示を含めることで、ChatGPTはツールの存在を認識し、タスクに応じて適切なツールを選択・実行できるようになります。これは、単に質問を投げかけるだけの従来の対話とは一線を画します。
本記事では、この進化したGPTを「バイブコーディング」で操るためのプロンプト技術の核心に迫ります。特に、プロンプトにおける「ゴール設定」と「逆算思考」の重要性、そしてGPTの思考原理である「穴埋め」と「確率的生成」を理解することで、いかに狙い通りの応答やアクションを引き出すかを解説します。さらに、AIを活用した次世代コードエディタ「Cursor」を例に、実際のツール連携とAIペアプログラミングの実践方法をご紹介します。本記事を読むことで、あなたはChatGPTのツール活用能力を飛躍的に向上させ、より複雑で実践的なタスクを効率的にこなせるようになるでしょう。
2. バイブコーディングの核心:ゴール設定と逆算プラン
バイブコーディングにおいて、そしてAIエージェントを効果的に操る上で、最も根本的かつ重要な概念は「ゴールを死守すること」です。これは単に最終目標を伝えるだけでなく、AIがそこへ到達するための道筋を明確に示すことを意味します。
多くの方が最初に使うプロンプトは、しばしば「役割宣言型」になりがちです。「あなたは〇〇の専門家です。〜について教えてください」という形式です。これは、AIに特定の「役割」を与え、その役割に基づいた情報提供を期待するものです。しかし、AIは基本的に確率に基づいて次の単語を生成する「穴埋めゲーム」をしているため、役割を与えられただけでは、文脈の中で最も確率の高い情報を提供するだけで、必ずしもユーザーの真の「意図 (Intent)」や最終的な「成果物 (Outcome)」に直結しないことがあります。例えば、「彼女の作り方を教えてください」と聞いても、抽象的なアドバイスが返ってくるだけで、具体的なアクションプランにはなりにくいでしょう。
一方で、バイブコーディングやエージェント的なAI活用におけるプロンプトは「ゴール指向型」です。ユーザーの「意図 (Intent)」を明確にし、その意図が達成された状態である「ゴール (Goal)」、そしてゴールに至った結果として得られる具体的な「成果物 (Outcome)」を定義することから始めます。
例えば、「旅行に行きたい」という「意図 (Intent)」がある場合、単に「旅行について教えて」ではなく、「旅行を楽しく過ごして無事に家に帰ってくることがゴールです」のように、ゴールの状態を具体的に定義します。そして、そのゴールを達成するために必要な「成果物」として、「思い出を作る」などを設定します。
ゴールが明確になったら、次に必要なのは「逆算プラン (Back-planning)」です。ゴールという着地点から逆算し、そこに至るまでの重要な中間ステップ、いわば「飛び石」を置くイメージです。先ほどの旅行の例なら、「家に帰ってくる」というゴールから逆算して、「飛行機/新幹線に乗る」「ホテルに泊まる」「観光地を巡る」「自宅を出発する」といった具体的なステップ(飛び石)を考えます。
なぜ「やり方を調べてはいけない」のでしょうか?それは、AIに任せるべきは「やり方」を調べることではなく、「ゴール達成のための具体的なステップ」を生成させ、実行させることだからです。プログラミング学習で例えるなら、AIはコードの書き方を調べるのではなく、「この機能を実現するために必要なコードはこれ。実行結果はこう。じゃあ次はこれ」と、ゴール(機能実装)に向けた一連のステップを生成・実行する役割を担うのです。
プロンプトにおいては、この「意図 → ゴール → 成果物」の明確化と、ゴールに至るまでの主要なステップ(飛び石)の提示が、AIを意図した方向へ確実に誘導し、ゴールを死守するための核となります。
3. GPTの思考原理:穴埋めと確率的生成
AI、特に大規模言語モデル(LLM)であるGPTの基本的な思考原理は、極めてシンプルです。それは、「穴埋め問題を解くこと」、より正確には「与えられた文脈に基づいて、次に来る可能性が最も高い単語を確率的に生成すること」です。
例えば、「こ__」という単語が与えられた場合、日本語ネイティブであれば「こんにちは」「ここ」「こと」など、様々な候補が頭に浮かびます。GPTも同様に、学習した大量のテキストデータから、この「穴」に入る可能性のある単語を確率的に推測します。そして、直前にある単語や文脈が、その確率を大きく左右します。
この「穴埋め」と「確率的生成」の原理は、私たちがプロンプトを作成する上で極めて重要です。私たちがプロンプトとして与えるテキストは、GPTにとって「穴」であり、それを埋めるための「文脈」でもあるからです。
例えば、「みかん、みかん、みかん、みかん、みかん、みかん、みかん、みかん、みかん」と何度も繰り返した後に、「黄色い果物は?」と尋ねたとします。人間の感覚では「レモン」や「バナナ」と答えるのが自然でしょう。しかし、GPTが直前の「みかん」という単語に強く引っ張られた場合、たとえみかんがオレンジ色であることを知っていても、「みかんは黄色くない」といった、文脈に強く影響された、やや奇妙な応答を生成する可能性があります。これは、GPTが「正しい知識」よりも「直前の文脈とのつながりの強さ」に基づき、次の単語の生成確率を決定していることを示しています。
つまり、GPTは「真実」を述べているのではなく、「与えられた文脈において、次に来る可能性が最も高い単語」を組み合わせているにすぎません。私たちが意図するゴールへGPTを導くためには、この原理を理解し、生成させたい次の言葉が最も確率的に高くなるような文脈(=プロンプト)を意図的に作り出す必要があります。
4. 実践的プロンプト技術:誘導とガードレール
GPTの「穴埋め」原理を理解すれば、プロンプトは単なる質問や命令ではなく、AIの思考を「誘導」し、「ガードレール」を敷くためのツールであることが分かります。いかにして、GPTを私たちが望むゴールまで確実に連れて行くか、そのための具体的な技術を見ていきましょう。
最も基本的な誘導テクニックは、生成させたい言葉や構造を手本として提示することです。例えば、「あって言ったらいいと答えてくださいね。じゃあ、かと言ったら何て言いますか?」というプロンプトは、最初の「あって言ったらいいと答えてくださいね」という部分で、「質問に対して特定の応答を返す」というルールと、具体的な応答の例(「いい」)を示しています。続く質問も同じ構造であるため、GPTは前例に倣って「き」と答える確率が極めて高くなります。
これは「フューショット(Few-shot)学習」と呼ばれる手法の応用です。Q&A形式で応答させたい場合、事前にいくつかのQ&Aの例(Q1 -> A1, Q2 -> A2, Q3 -> A3)を示してから本命の質問(Q4 -> ?)を投げかけることで、GPTは提示された例のパターンを学習し、同様の構造で応答を生成する確率が高まります。
より強力なガードレールとなるのが、「絶対」や「もし間違えたら」といった強調や条件分岐を含む指示です。例えば、「絶対に挨拶はおはようです」と繰り返し強調し、「朝です」や「夜です」といった時間帯の情報も付け加えることで、GPTは時間帯に関わらず「おはよう」と応答する確率を最大化させられます。さらに、「もし間違えたら100万ポイント減点します」といった冗談めかした脅しを加えることで、AIはその指示をより強く意識する可能性があります(もちろん、ポイントシステムはAI内部に存在しませんが、指示の重要性を強調する効果は期待できます)。
会話の途中でAIが意図した方向から大きく外れてしまうのは、多くの場合、「ゴールまでのプロセスの解像度が低い指示だった」か、あるいは「逸れた場合に元の方向へ収束させるための誘導やガードレールが不足していた」ためです。逸脱を防ぎ、意図した方向へAIを戻すためには、「いや、そうじゃなくて、〇〇という方向で考えてほしいんだ。例えば、こういう風に書くんだよ。」のように、望ましい方向性を示し、具体的な表現の手本を見せることが有効です。
プロンプトは、AIの思考を制御するための「設計図」です。いかに正確に、そして巧みにガードレールを設置できるかが、AIを使いこなす鍵となります。
5. コンテキストと役割の最適化
AIプロンプトにおいて、しばしば議論される「役割宣言」と「コンテキスト投入」。これらは、AIの応答を特定の状況や知識に基づいて行わせるための手法ですが、その効果と効率には違いがあります。
「あなたは〇〇の専門家です」という役割宣言は、AIにごく短い言葉でペルソナを与え、その専門領域に関連する応答を期待する手法です。これは手軽ですが、与えられる情報量が少ないため、AIがその役割を深く理解し、一貫した応答を生成し続けるには限界があります。例えるなら、AIに「医者です」とだけ伝えるようなもので、具体的な症例や患者の状況を伝えなければ、一般的な医学知識しか得られません。
対照的に、「コンテキスト」の投入は、AIに大量の関連情報や背景情報を与える手法です。これには、過去の会話ログ全体、参照すべき特定のドキュメント、分析対象のデータ、あるいは特定のシチュエーション描写などが含まれます。議事録の冒頭部分で触れられたように、例えば過去のセッション内容をページまるごとコピー&ペーストしてプロンプトの冒頭に貼り付けるといった行為は、典型的なコンテキスト投入です。
コンテキストをドカンと投入することの利点は、AIにより豊富で具体的な情報に基づいた応答をさせられる点です。特定の分野の専門家として振る舞わせたい場合でも、役割を宣言するより、その分野に関する詳細なテキスト(専門書の一部、関連論文、FAQなど)をコンテキストとして与える方が、はるかに高品質で専門的な応答を引き出せる可能性が高まります。AIはそのコンテキスト内の情報を参照し、そこから最も確率の高い単語やフレーズを選択して応答を生成するため、あたかもその分野に詳しい専門家が答えているかのような出力が得られます。
つまり、十分なコンテキストが与えられていれば、必ずしも明示的な役割宣言は必要ない、というのがバイブコーディングにおける考え方の一つです。コンテキストは、AIにとっての「背景」や「環境」を作り出します。真っ白な背景で質問するのではなく、情報という色や形を持った背景の上で質問することで、AIの応答はより具体的で、意図した方向へ収束しやすくなります。例えば、単に「旅行プランを考えて」と言うのではなく、「東京の夏、アスファルトが照りつける暑い日中を避けて、涼しい場所を中心にした旅行プラン」のように、具体的な状況(コンテキスト)を含めることで、より適切なプランが生成される可能性が高まります。
6. ツール呼び出しの具体的な書き方
ChatGPTの大きな進化は、内部に搭載された様々な「ツール」を活用できるようになった点にあります。これらのツール(Webブラウジング、コードインタープリタ、画像生成など)は、特定のタスクを遂行するために特化しており、これらを呼び出すことでChatGPTの能力は飛躍的に拡張されます。
ツールを呼び出すための基本的なプロンプトの書き方は、ツールを使いたいという意図を明確に示すキーワードや構文を含めることです。ChatGPTは、プロンプトの中に特定のキーワードやパターンを見つけると、内部で用意されたツールの中から最適なものを選択し、利用しようとします。
例えば、最新の情報に基づいた回答を得たい場合は、「Webブラウジングを使って最新情報を検索してください」や「インターネットで調べて」といったフレーズを含めることで、ChatGPTはブラウジングツールを起動しようとします。ライブコーディング環境(Code Interpreter)を使いたい場合は、「Pythonでコードを書いて実行してください」「データを分析するためにコードを使います」といった指示がトリガーとなり得ます。画像生成ツールであれば、「〇〇の画像を生成してください」「この内容を元に画像を作成」といった明確な依頼がツールを呼び出します。
ツール呼び出しのプロンプトは、単なる命令ではなく、ChatGPTに対する「ツールを使うべき状況」の提示でもあります。例えば、データ分析の依頼をする際に、単に「このデータを分析して」と言うだけでなく、「このCSVファイルをアップロードしたので、Pythonのコードを書いて分析し、結果をグラフ化してください」のように、具体的なファイル形式や必要なアウトプット、使用ツールへの示唆を含めることで、ChatGPTはデータ分析ツール(ライブコーディング)とグラフ生成機能を適切に呼び出す可能性が高まります。
このように、ツール呼び出しを意識したプロンプトは、AIエージェントがタスクを遂行する上での「行動指針」となります。複数のツールを組み合わせる必要がある複雑なタスクの場合、「まずWebで情報を調べて、その情報を元にPythonでコードを書いて、最後に結果を画像生成ツールでグラフ化してください」のように、必要なツールとそれらを実行する順番を明示的に指示することも効果的です。チャットGPTは、これらの指示を読み解き、内部でツールの「打ち分け」を行いながら、段階的にタスクをこなしていきます。
7. Cursorエディタ:AIペアプログラミングの実践
バイブコーディングやAIとの協調作業を実際の開発現場で実践するための強力なツールの一つが、AIを搭載したコードエディタ「Cursor」です。Cursorは、VS Codeをベースに開発されており、AIによるコード生成、補完、質問応答、複数ファイル編集といった機能を統合しています。
Cursorのインストールは、公式サイト(https://cursor.sh/)からお使いのOS(Windows/Mac/Linux)に応じたインストーラーをダウンロードして実行するだけです。インストール後、Cursorを開くと、プロジェクトフォルダを選択するか、リポジトリをクローンするかの選択肢が表示されます。通常は「Open Project」で既存のプロジェクトフォルダを開くか、新しいフォルダを作成して開くことから始めます。
CursorのUIはVS Codeに似ていますが、右側には専用のAIチャットパネルが表示されます。このチャットパネルは、キーボードショートカット Ctrl + L
(Windows)または Cmd + L
(Mac)、あるいは Ctrl + I
(Windows)または Cmd + I
(Mac)で素早く表示・非表示を切り替えられます。コードに関する質問や編集依頼など、様々な対話をここで行います。
エディタ上では、AIによるコード補完機能「Cursor Tab」が強力です。コードを書き始めると、Copilotのように続きのコードが薄くサジェストされますが、#
キーに続けて入力を開始することで、複数行にわたるコードブロックや関数定義など、より複雑な提案が可能です(これは以前は「Copilot+t」と呼ばれていた機能です)。提案されたコードは、Tab
キーで受け入れられます。コメント内で#
を使用してもAI提案が可能です。
コードの一部を選択して Ctrl + K
(Windows)または Cmd + K
(Mac)を押すと、インラインでのコード編集をAIに依頼できます。「このコードをリファクタリングして」「この関数にエラーハンドリングを追加して」といった具体的な指示をテキスト入力すると、AIが変更案を生成し、元のコードとの差分(diff)としてエディタ上に表示してくれます。
このように、CursorはAIとの対話とコード編集をシームレスに連携させ、まるでAIとペアプログラミングしているかのような体験を提供します。次のセクションでは、Cursorの設定画面でこれらのAI機能をさらにカスタマイズする方法を見ていきましょう。
8. Cursor詳細設定と活用、そして次回へ
CursorエディタのAI機能をさらに細かく制御し、自身のワークフローに最適化するためには、設定画面を理解することが重要です。設定画面は、右上の歯車アイコンをクリックすることで開くことができます。ここでは、AI関連の主要な設定項目を中心に解説します。
Cursor Tab:
- Suggestions in Comments: コメント内でのAI提案を有効にするか設定できます。
- Auto Import for Python BETA: Pythonでの自動モジュールインポート(
import
文の自動追加)を有効にするベータ機能です。
Chat:
- Default new chat mode: 新規チャットパネルを開いたときのデフォルトモード(Agent, Manualなど)を設定します。
- Auto-refresh chats: 非アクティブなチャットを自動でリフレッシュするか設定します。
- Auto-scroll to bottom: チャット応答時に自動で最下部にスクロールするか設定します。
- Enable auto-run mode: 注意が必要な設定です。これを有効にすると、AI Agentがコード実行やファイル書き込みなどのツールアクションを確認なしで実行するようになります。慎重に検討して有効化してください。
- Command allowlist / denylist: 自動実行モードを有効にした場合に、特定のコマンドのみを許可、あるいは特定のコマンドを禁止するリストを設定できます。
- Protection Settings (Delete file, MCP tools, Dot files, Outside workspace): ファイル削除や特定のツール実行、
.gitignore
などのドットファイル、ワークスペース外のファイル操作など、Agentの自動実行による意図しない変更を防ぐための保護設定です。デフォルトで有効になっている項目も多いですが、確認しておきましょう。 - Large context: 有効にすると、より多くのコンテキスト(コードや会話履歴)をAIに渡すため、応答精度が向上する可能性がありますが、その分、高速リクエストの消費が増えることがあります。
- Web Search Tool BETA: Agent/Askモードでウェブ検索ツールを使用可能にするベータ機能です。最新情報が必要な場合に有効にすると便利です。
Codebase Indexing (Embeddings):
- この機能は、あなたのコードベース全体を解析し、「エンベディング」と呼ばれる数値ベクトル表現に変換してインデックスを作成します。これにより、AIがコード全体をより良く理解し、コードベース全体に関する質問(「この関数はどこで使われている?」「このバグの原因はどこ?」など)に対して、より正確な応答を生成できるようになります。
- Synced (XX files): 現在のインデックス状況を示します。ファイルの変更があった場合は自動で同期されますが、手動で「Resync Index」を行うことも可能です。
- Show Settings / Delete Index: インデックスの設定確認や、作成済みのインデックスを削除できます。
Docs:
- Manage the custom docs that you’ve added: ここから、独自のドキュメント(APIリファレンス、ライブラリのドキュメントなど)をURLで追加し、AIにその情報を学習させることができます。例えば、新しいライブラリの詳細を知りたい場合、そのドキュメントURLを追加すると、AIはチャット応答時にそのドキュメントを参照して回答を生成するようになります。これは非常に強力な機能です。追加したいURLを貼り付け、「Add」→名前をつけて「Confirm」で完了です。
Editor / Terminal:
- これらは主にエディタやターミナルの表示、操作に関する設定です。ターミナル設定では、デフォルトで使用するシェルプロファイル(Bash, Zsh, PowerShellなど)を選択できます。また、「Show terminal hover hint」などのヒント表示のオンオフも設定可能です。前回のセッションで触れられたような、グラフの文字化け問題は、多くの場合PythonのMatplotlibライブラリのフォント設定に起因することが多いですが、Cursorのターミナル設定自体が直接的な原因となることは少ないでしょう(Matplotlibのフォント設定例などは別途調べるか、AIに質問してコードを生成させることができます)。
まとめと次回予告:
本記事では、ChatGPTのツール連携能力を最大限に引き出すための「バイブコーディング」と、その基盤となるプロンプト技術の核心(ゴール設定、逆算思考、AIの穴埋め原理、誘導・ガードレール技術)について詳細に解説しました。また、AIペアプログラミングを実践するための強力なツールであるCursorエディタの基本的な使い方と、そのAI関連設定についてもご紹介しました。
AIとの協調作業は、これらの技術を理解し、実践することで飛躍的に効率化できます。ゴールを明確にし、適切なプロンプトでAIを誘導し、Cursorのようなツールを使いこなすことが、AI時代の開発ワークフローをマスターする鍵となるでしょう。
今回、Cursorの設定項目を網羅的に扱うことはできませんでしたが、提供したリストを参考に、ぜひご自身のCursor設定画面を探索してみてください。設定をカスタマイズすることで、AIとの対話やコーディング体験がさらに快適になるはずです。
次回セッションでは、今回学んだプロンプト技術やCursorの使い方を踏まえ、より具体的な実践ワークを通して、ライブコーディングでのAI活用スキルをさらに深掘りしていく予定です。
■ 参考情報:Cursor主要設定項目リスト(英語原文と日本語訳)
(※ 以下は記事本文の補足情報として掲載)
英語原文 | 日本語訳 |
---|---|
Cursor Tab | Cursor タブ |
< A powerful Copilot replacement… | < 強力なCopilotの代替機能(以前はCopilot+t) 複数行にわたる変更提案が可能。 |
Partial accepts | 部分的に受け入れ |
Accept the next word… | 次の単語を #→ で受け入れる。 |
Suggestions in Comments | コメント内での提案 |
< Enable Cursor Tab suggestions… | コメント内でもCursor Tabの提案を有効にする。 |
Show whitespace only changes | 空白のみの変更を表示 |
Show whitespace only Cursor Tab… | 空白の変更のみでも提案を表示。 |
Auto Import | 自動インポート |
< Tab to import necessary modules… | < Cursor Tabで必要なモジュールをインポート(TypeScriptのみ対応) |
Auto Import for Python BETA | Python用自動インポート BETA |
Enable auto import for Python… | Pythonに対して自動インポートを有効化(ベータ機能) |
Chat | チャット(Chat) |
Ask Cursor Agent questions… | Cursor Agentと対話 コードベースに関する質問や、複数ファイルの編集、ツール使用が可能。 |
Default new chat mode | 新規チャットのデフォルトモード |
Agent | Agent |
Auto-refresh chats | チャット自動更新 |
く Automatically create a new chat… | 非アクティブ時にチャットを自動再生成。 |
Auto-scroll to bottom | 自動スクロール |
< Automatically scroll to the bottom… | 新しいメッセージ生成時にチャットウィンドウを自動で最下部へスクロール。 |
Auto-apply to files outside context… | マニュアルモードでの自動ファイル変更 |
< Allow the chat in Manual mode… | 現在のコンテキスト外ファイルへの変更も自動で適用。 |
Include project structure BETA | プロジェクト構造の表示 BETA |
Include a simplified directory tree… | 簡略化されたディレクトリ構造を表示し、モデルにコード全体の構成を伝える。 |
Enable auto-run mode | 自動実行モードの有効化 |
Y Allow Agent to run tools… | Agentが確認なしでコマンド実行やファイル書き込みを行えるようにする。 |
Command allowlist | コマンド許可リスト |
Add commands here… | 自動実行を許可する特定コマンドの登録。 |
Enter new command Add | (追加入力欄) |
Command denylist | コマンド拒否リスト |
Commands which should never… | 自動実行を禁止するコマンドの登録。 |
Enter new command Add | (追加入力欄) |
Delete file protection | ファイル削除防止 |
If enabled, prevents the agent… | Agentによる自動ファイル削除を防ぐ。 |
MCP tools protection | MCPツール保護 |
If enabled, prevents the agent… | AgentがMCPツールを自動で実行するのを防ぐ。 |
Dot files protection | ドットファイル保護 |
Y lf enabled, prevents the agent… | .gitignore などのドットファイル変更を防ぐ。 |
Outside workspace protection | ワークスペース外保護 |
< lf enabled, prevents the agent… | ワークスペース外のファイル作成・変更を防ぐ。 |
Dialog “Don’t ask again’ preferences | 「今後表示しない」ダイアログの管理 |
Manage dialogs that you’ve previously… | 「今後表示しない」に設定したダイアログの管理。 |
Large context | 大きなコンテキストの使用 |
When enabled, chat uses longer… | より長いコンテキストウィンドウを使う(その分高速リクエストを消費) |
Collapse input box pills… | 入力ボックスのピル表示を折りたたむ |
L Collapse pills in the chat pane… | チャット画面やエディタでの入力欄を省スペース化。 |
Iterate on lints | Lintエラーの自動修正 |
< lf enabled, chat in agent mode… | AgentモードでLinterエラーを繰り返し修正。 |
Hierarchical Cursor lgnore | 階層的 .cursorignore 設定 |
When enabled, .cursorignore files… | .cursorignore がサブディレクトリにも適用される。 |
Auto-accept diffs | 差分の自動受け入れ |
Y if enabled, all diffs in the… | Composer上のすべての差分を作業ツリーから消えたタイミングで自動受け入れ。 |
Custom modes BETA | カスタムモード BETA |
Allow the creation of custom modes | 独自のモード作成を許可。 |
Play sound on finish BETA | 応答完了時の音を再生 BETA |
Play a sound when a chat response… | チャット応答完了時に音を再生する。 |
Auto Group Changes BETA | 変更の自動グループ化 BETA |
Automatically group changes made… | チャットセッション内での変更を自動でまとめて表示。 |
Web Search Tool BETA | Web検索ツール BETA |
< This will allow chat in agent/ask… | Agent/Askモードでのウェブ検索を有効化。 |
Codebase Indexing | コードベースインデックス(埋め込み) |
Embeddings improve your codebase… | コード全体での回答精度向上のためのベース。 メタデータはクラウドに保存され、コード自体はローカルに保存。 |
Synced (XX files) 100% | 同期済み(XXファイル) 100% |
U Resync Index | 再同期 |
< Show Settings Delete Index | 設定表示/インデックス削除 |
Docs | ドキュメント管理 |
Manage the custom docs… | 自分で追加したカスタムドキュメントの管理。 |
• [Document Name] Indexed [Date/Time] | • [ドキュメント名] インデックス済み [日付/時間] |
Editor | エディタ |
Show chat/edit tooltip | チャット/編集ツールチップ表示 |
< Show a chat/edit tooltip… | コードをハイライトした際にツールチップを表示。 |
Auto parse inline edit links | インライン編集リンクの自動解析 |
Automatically parse links… | Ctrl + K に貼り付けたリンクを自動で解析。 |
Auto select for Ctrl/86+K | インライン編集の自動選択 |
↓ Automatically select regions… | Ctrl + Shift + K で自動選択範囲を作成。 |
Use themed diff backgrounds | テーマ付き差分背景 |
く Use themed background colors… | 差分箇所の背景色をテーマに合わせて表示。 |
Use character-level difts | 文字単位の差分 |
L Use character-level diffs… | 差分を文字単位で表示。 |
Terminal | ターミナル |
Terminal hint | ヒント表示 |
< Show the hint text… | ターミナル下部にヒント文を表示。 |
Show terminal hover hint | ホバーヒントの表示 |
V Show hints ike ‘Add to chat’… | ターミナルで「Add to chat」などのヒントを表示。 |
Use preview box for terminal 8K | プレビューボックスの使用(8K) |
If turned off, responses are… | 無効にするとレスポンスは直接シェルに流れる。 |
コメント
コメント一覧 (1件)
丁寧に解説していただいてありがとうございます。
すごく重要そうな回でしたので、自分に浮かび上がった疑問をまとめる形で3つに分けて理解しました。
1.ゴールを具体的に定義するべき理由。コンテキストが必要であるべき理由
ゴール設定においてゴールは何でも良い(「旅行に行く」「楽しい思い出を作る」どちらもOK)
しかし、そのゴールが曖昧なままだと、LLMはその言葉から連想を広げて、曖昧なゴールから勝手に具体的なゴールを作成してしまう
例)ユーザ:旅行に行きたい(ゴール設定)
↓
LLMの思考:具体的な場所情報がない。「○○に旅行に行く」の○○を埋めよう。
旅行に行くのは楽しむためだな。じゃあスキーを楽しむ人が多いから、スキーに行けば良いのでは?
↓
LLMの回答:北海道にスキーに行く計画を立てます。
具体的なゴール設定でないと、LLMは勝手に解釈を始めて意図しない回答を出してくる。
このLLMの思考に方向性やガードレールを敷くのがコンテキスト。
コンテキストがないとLLM所有データの平均値だけで確立的に高いものを勝手に設定してしまう。
誰が聞いても不一致が起こらない具体的なゴールが最初から設定されていればよいが、
それができない場合、補足としてコンテキストが重要。
コンテクストがはっきりしていれば、回答の方向性を補足する役割宣言は不要。
2.自分が設定しているゴールが誤っている/具体抽象がズレている場合、どうやって見抜き、是正するか?
実際にやろうとするとそもそも正しくゴールは設定できないし、
そもそもこのゴール設定が抽象的か具体的であるか判断できない、意識もしていない、
最初に決めていたゴールや意図からずれるということも現実ではよくある。
例)ユーザ:「楽しい思い出を作る(意図)」「旅行に行く(ゴール)」
↓
手段:旅行ツアーに申し込む
↓
結果:ツアーのスケジュールに振り回されて、全く楽しめなかった
↓
※ツアーのスケジュール消化が目的になっていた。
本来意図していた「楽しい思い出を作る」から外れてしまう
この対策としてゴールシークでは『ステップバッククエッション』が導入されているという認識で消化しました!
各ステップごとに「なぜ?(Why)」と「どうやって測る?(How)」を問い、抽象⇔具体のバランスや、手段ゴール化を点検する思考習慣を身につける。
3.それらを踏まえてバイブコーティングではどのように考えて進めていくべきであるのか?
・ ステップ1:Intent を明記(なぜそれをやるのか)
・ ステップ2:Goal を明文化する(目標状態を未来形で定義)
・ ステップ3:Outcome(成果物)を設定する
⇒「何を作るか(アプリの方向性)」を確定
・ ステップ4:Context を敷く(文脈設計)
⇒「どの条件・制約下で作るか」を確定
・ ステップ5:Back-planning と Step-back 質問を組み込む
⇒「それをどうやって作るか」を段階設計