よく人から「Codex でこんなことできる？」と聞かれます。
そして、その後 2、3 分かけて、その「こんなこと」が具体的に何なのかを説明してくれます。つまり、解決したい問題、アプリケーションがすべきこと、良い結果とはどんなものか、といったことです。時には、これまで試したこと、うまくいったこと、いかなかったことを共有してくれます。
そんな時、私は思います。その説明をそのまま Codex に言えばいいのに、と。
その説明全体が、すでにプロンプトなのです。
プロンプトエンジニアリングは死んだ。そして、死んではいない。
もしプロンプトエンジニアリングが、助けを求める前に秘密の言語を学ぶことだとしたら、それはほとんど死んだと言っていいでしょう。特に推論モデルでは、正しい答えを引き出す魔法のキーワードは、通常存在しません。完璧なプロンプトを作ろうと、何時間も空白の画面を見つめ続けるべきではないと思います。
しかし、完全に死んだわけでもありません。なぜなら、明確さは依然として重要だからです。曖昧さは、他の誰にとってもそうであるように、Codex の作業を難しくします。もしこの記事の段落をシャッフルしたり、あなたが理解できない言語に切り替えたりしたら、内容を追うのが難しくなるでしょう。時制でさえ重要です。「これを試した」と「これを試してほしい」は同じではありません。
あなたは実際に何を望んでいますか？ どのようなコンテキストが重要ですか？ Codex が知っておくべき制約は何ですか？ 良い結果とはどのようなものですか？
一緒に仕事をする相手に話すように、Codex に話しかけてください。
私は結果から始めるのが好きです。つまり、私の目標は何か？ ということです。これは、エージェントにおけるより広範な変化でもあります。すべてのステップをスクリプト化し、中間出力ごとに要求する代わりに、達成したいことを説明し、境界を設定し、Codex に道筋を見つける手助けをさせることができます。
乱雑なバージョンをそのまま言う
ほとんどのアイデアは、きれいな仕様書としてやってくるわけではありません。どちらかというと、次のように聞こえます。
「えっと、たくさんのファイルがあるんだ。フォーマットが少しずつ違う。金曜日までにレポートが必要なんだ。データのほとんどはあると思うんだけど、このエクスポートだけちょっと変で…」
それで大丈夫です。そのまま言ってください。
とりとめのない話をすると、Codex により多くのシグナルを与えることになります。磨き上げたプロンプトからは削除したであろう詳細に言及することになります。途中で考えが変わります。「いや、やっぱりそれは違う」と言うでしょう。
考えを変えることで、何が望みでないかが明らかになります。寄り道をすることで、隠れた制約が明らかになるかもしれません。考えを声に出すことは、あなた自身と Codex の両方がタスクを理解するのに役立ちます。
音声入力を使えば、マイクボタンを押して、簡単な説明を話し、文字起こしを確認して、送信するだけです。
お使いの環境で利用可能であれば、ボイスモードはさらに優れています。フォローアップ、割り込み、方向転換、新しい思考の糸を拾うことができます。また、作業の調整にも使用できます。別のタスクを開始したり、既存のタスクを確認したり、何がブロックされているかを尋ねたり、すでに実行中の作業を方向付けたりできます。
正直に言うと、コンピューターに話しかけるのはまだ少し変な感じがします。オフィスでは、DJI のマイクを手に持っています。ヘッドホンにマイクが付いているものでも大丈夫です。
しかし、完璧な書き表し方を見つけられずに、良いアイデアが頭の中に留まってしまうよりはましです。
馬鹿げた質問をする
これにはおなじみのミーム版があります。
「Codex、10 億ドル規模の B2B SaaS を作ってくれ。間違いは許されない。一発で決めてくれ。」
一発で 10 億ドル企業を作れるわけはありません。しかし、その会話から、現実的な何か、つまり、あなたが理解している問題、それを抱えている誰か、そして取る価値のある最初のステップが明らかになるかもしれません。これは昔ながらの良い問題解決法です。複雑な問題を、より小さな達成可能なステップに分解することです。
価値は会話そのものにあります。馬鹿げた質問から、今日実際に出荷できる何かへと導いてくれるかもしれません。
始めるための実用的な方法
アイデアがまだ曖昧なら、Codex にインタビューを依頼してください。
「まだ考えをまとめているところです。一度に一つずつ質問してください。曖昧な点は突っ込んで聞いて、それを具体的なものに変える手助けをしてください。」
あるいは、非常に直接的に尋ねてみましょう。
- 私の盲点は何ですか？
- これを失敗させる要因は何ですか？
- 何を考えすぎていますか？
- 最も小さくて有用なバージョンは何ですか？
- 作業を始める前に、あなたが知っておく必要があることは何ですか？
より構造化された作業が必要な場合、Codex の Plan モードが便利です。明確化のための質問をしたり、選択肢を提示したり、実装前のアプローチを検討したりできます。
しかし、すべてのアイデアをそこから始める必要があるとは思いません。オープンエンドの会話の方が、よりスムーズに進むこともあります。同僚とのすべての会話を、計画と実行に分割したりはしません。まず話しましょう。問題の輪郭を浮かび上がらせましょう。作業に計画が必要になった時点で、計画に移行しましょう。
Codex について Codex に尋ねる
「Codex に話しかける」には、もう一つの意味があります。つまり、Codex 自身について質問することです。
何が見えるか尋ねてください。どのモードが適切か尋ねてください。どのようなツールが利用可能か尋ねてください。どのように作業を検証する予定か尋ねてください。
OpenAI Docs スキルが利用可能であれば、Codex にドキュメントを確認するよう依頼してください。公開されている Codex リポジトリを調べたり、クローンして Codex にその仕組みを説明してもらうこともできます。
Codex が的外れなら、理由を尋ねる
「あなたはこれをやったけど、私が実際に欲しかったのはあれなんだ。どこで間違えたんだろう？」
あなたのリクエストが曖昧だったのかもしれません。AGENTS.md ファイルやスキルが作業を別の方向に導いたのかもしれません。プラグイン、権限、ツールが利用できなかったのかもしれません。Codex が誤った仮定をしたのかもしれません。
何を理解したか、どの指示に従ったか、何が失敗したか、何をより明確にできたかを尋ねてみてください。Codex は、多くの場合、まだ利用可能なコンテキストを使用して、コラボレーション自体を監査するのに役立ちます。
利用可能な場合は、Codex の実行中にメインチャットを中断することなく、/side でサイドチャットを開くことができます。何が完了したか、何が残っているか、何がブロックされているか、どのように支援できるかを尋ねてください。あなたは、基本的にデイリースクラムでの Codex のマネージャーです。
何かを平易な英語で説明してほしい場合は、トランスクリプト内のテキストを選択し、「サイドチャットで質問」を選択してください。
アイデアを頭の中から外に出す
あるロードトリップ中、私はプレゼンテーションについて Codex に話し始めました。それが、このトークとこの記事の構成になりました。大まかなアイデアを話し、何度か考えを変え、そして続けました。
多くの場合、最大の障壁はモデルではありません。それは私たち自身です。アイデアはまだ準備ができていないと思い込んでいます。正しいプロンプトがわかりません。うまく説明できていないのではないかと心配しています。
インターフェースはより良くなるでしょう。そして、Codex との会話がどうあるべきかについてアイデアがあれば、ぜひ聞かせてください。
ただ、Codex に尋ねてみてください。
