CodexのComposer predictionsを使う。提案文と送信を分ける確認手順
公開日 ・更新日
Composer predictionsは、Codexの応答後に次の入力候補を表示し、Tabキーで採用できる機能です。候補は下書きであり、自動的に送信されません。便利さをそのまま自動化と捉えず、提案を読む、必要な部分だけ直す、送信を決めるという三つの段階に分けると、作業の境界を保てます。
使う範囲を先に決める
設定で機能を有効にする前に、どの種類の依頼で使うかを決めます。調査の次に確認したい質問、テスト失敗後の切り分け、レビューで不足している観点など、次の一手を説明しやすい作業から始めます。顧客へ送る文章、公開用の変更、料金や契約に関する判断は、候補が出ても人が確認する範囲に残します。
候補は現在のスレッドの文脈をもとに作られます。別の案件の情報を混ぜたいときは、先に必要な前提を整理してから入力します。前提が変わったのに古い候補をそのまま使うと、依頼の対象や完了条件がずれます。
利用できる環境や対象年齢などの条件は、チームで使う前に管理者が確認します。機能を使えない人へ別の操作を強いるのではなく、通常の入力方法でも同じ確認手順をたどれるようにしておくと、担当者が変わっても作業を止めません。
Tabを押す前に内容を読む
候補が表示されたら、まず対象、動詞、完了条件を読みます。対象ファイルや環境が意図どおりか、読み取りだけでよいのか、編集や外部通信が含まれるのかを確認してください。提案文に具体的なファイル名やコマンドがあっても、必要な範囲へ絞り直してから採用します。
採用後も、送信前に文章を編集できます。質問が曖昧なら一つに分け、変更を頼む場合は対象ファイルと確認方法を明記します。危険な操作、公開、削除、顧客への連絡を含む候補は、そのまま送らず、確認事項へ置き換えます。候補生成そのものと、実際に送るメッセージの利用上限は別に扱われるため、通常の送信と同じように必要性を判断します。
人の確認を記録する
チームで使うなら、候補を採用したか、どこを直したか、送信後に何を確認したかを短く残します。提案どおりに進めなかった例も、次回の停止条件を決める材料になります。作業を止める場合は「送信しない」「変更しない」と明示し、続行する場合は確認済みの対象だけを渡します。
まずは一つの開発作業で、提案と送信を分ける運用を試します。候補が便利でも、最終的な依頼内容と実行範囲を決める責任は人にあります。Codexを社内の作業へ安全に組み込み、確認ルールまで整えたい方は、COZITOへご相談ください。
関連記事
著者: 松井 勇樹