Cueの音声入力とCodexでコード変更をレビューする

入力方法を選ぶ

別のアプリでレビューの論点に気づいたときは、Cue が役立ちます。仕様書を読んだり、Issue を確認したり、変更後の画面を試したりしているときに、リスクが見つかることがあります。意図した動作と維持すべき条件を一時メモへ音声入力し、文章を確認してから Codex に渡してください。Cue は複数のアプリからレビューの依頼文をまとめるために使えますが、対象の差分はレビュー環境で別途選択する必要があります。

関連するプロジェクト、差分、レビューの問いがすでに Codex に揃っていれば、そのまま続けられます。短い依頼を直接入力するか貼り付け、下で説明するレビュー機能を使ってください。この演習は Cue がなくても行えます。話したり、タスクの外から文脈を集めたりすることでレビューの問いを明確にできるなら、Cue を加える意味があります。レビューの品質は、渡した証拠とレビュアーによる確認に引き続き左右されます。

Cue Dictation で外部アプリに入力する

下の演習では、この方法を使います。Cue はフォーカス中の一時メモや対応するテキスト入力欄に、話した言葉を入力します。文章を確認してから、読み取り専用のレビューを求める依頼文を Codex に明示的に送ってください。Cue のコネクターは不要です。引き渡されるのは自分が提供した資料だけで、他の会話、ファイル、権限は自動で引き継がれません。

Cue 内の Codex コネクターを使う

これは Cue から外部 Agent を利用する別の方法です。先に、その経路の接続、ログイン状態、プロジェクト、権限を確認し、アカウントと課金も確認してください。Codex の選択肢が表示されているだけでは、利用準備が整っているとは限りません。下で説明する Codex アプリのレビューパネルやメニューは、Cue 内のコネクターの操作手順ではありません。

Cue Agent でホスト型モデルを使う

Cue Agent に、提供した資料をレビュー依頼文の下書きにまとめてもらい、元の資料と照合してください。Cue Agent で OpenAI のモデルを選んでも、Codex が起動したり、別の Codex タスクにリポジトリへのアクセス権が付与されたりすることはありません。ホスト型モデルの利用条件と課金は Cue アカウントに基づきます。外部 Agent のアクセス権は別途確認してください。

小さなパッチのレビュー演習を試すには、Dictation のあとに明示的にテキストを渡します。レビューの目的を話し、R-01〜R-03 を記載どおりに添えてください。編集はせず、指摘を出すように依頼します。それぞれの指摘を具体的な式と問題を起こす入力に結び付け、例示の指摘と実際に実行した検証を区別できたら完了です。

リスクに気づいたその場でレビューの問いを記録する

レビューは、問いが1つに絞られているほど対応しやすくなります。「すべてをレビューして」と頼むと、重視したい挙動を見落としたままスタイルの提案ばかりが返ってくることがあります。音声で依頼する場合は、「このパッチはカウント0を表示できるようにするものです。カウントが存在しない場合に従来の空状態ラベルが維持されているか確認してください。まだ何も編集しないでください」のように伝えると効果的です。

1. 仕様書や影響を受ける画面を表示したまま、下書きノートまたは対象タスクの入力欄にフォーカスを合わせます。Cue Settingsに表示されているDictationのショートカットを呼び出し、録音状態を確認してレビューの目的を話し、停止したら処理後に挿入されたテキストを確認します。
2. 正確な識別子はソースからコピーしてそのまま維持してください。送信前に数値、否定表現、ブランチ名の文字起こし内容を確認します。Cue Agentにメモの整理を依頼する場合は、下書きの指示書を要求し、必要な抜粋を明示的に指定してください。
3. Codexで正しいGitプロジェクトを開きます。レビューペインには、Codexの直前の応答だけでなく、自身の編集や他ツールの編集を含むリポジトリの変更が表示されます。レビューを依頼する前に、今回のタスクに含まれる内容を確認してください。
4. 確認済みの指示書を明示的に渡します。これには、テキスト作成欄へのメモの貼り付けや、フォーカスした入力欄への音声入力による追加指示が利用できます。Cueのモデルセレクターは、独立したCodexタスクのランタイム選択やアクセス権付与を行うものではありません。

この手動の手順では、CueとCodexの連携コネクターは不要です。代わりにCue内部の外部Agentを選択する場合は、まずそのルートの接続、サインイン、プロジェクト、権限を確認してください。Codexデスクトップアプリのメニューが備わっている、あるいは過去のチャット履歴が自動的に引き継がれると思い込まないようにしましょう。違いについてはコーディングAgentと連携したCueの利用を参照してください。

指摘を求める前に正確な差分を選択する

Codexアプリについて、OpenAIのコードレビューのドキュメントでは、コンポーザー内の/reviewや、コミットされていない変更またはベースブランチに対するレビューのオプションが説明されています。またレビューペインでは、ステージ済み、未ステージ、コミット、ブランチ、直前のターンのビューが区別されます。これらはCodexアプリのコントロールであり、Cueのコマンドではありません。利用可否はインストールされているバージョンによって異なります。

• 未コミットの作業: ステージ済みおよび未ステージのファイルを検査します。どのファイルがスコープ内であり、既存のどの変更が他のユーザーによるものかをレビュアーに伝えてください。「直前のターン」にリリース予定のすべてが含まれていると決めつけてはなりません。
• ブランチの変更: 見慣れた名前を適当に選ぶのではなく、本来意図されたベースブランチを選択してください。後からレビューを再現可能にする必要がある場合は、ベースとヘッドのコミットIDを記録しておきます。
• 単一コミットまたは提供されたパッチ: コミット名を指定するか、コードを正しく解釈できるよう十分な周辺実装を含めてパッチを添付します。コード片のみを貼り付ける場合は、スニペット限定のレビューであることを明記してください。

カスタマイズしたタスクの場合は、後述の指示書を貼り付け、その正確なスコープに対する読み取り専用レビューを依頼します。組み込みのレビュー機能と自由形式のプロンプトは別の入力経路です。他所で入力した制約がレビューに自動で添付されていると思い込まないでください。レビュータスクのコンテキストを確認しましょう。レビューを実行させるためだけに権限を無効化してはなりません。

実践: 現実的な小さなパッチからデグレードを見つける

この架空の演習では、ごくわずかな差分と動作仕様を提供します。テキストのみの演習としてレビュー可能であり、Codexの実行ログではなく、本番リポジトリへのアクセスも不要です。

ソース R-01 — 仕様: カウント0には0 resultsを表示する必要があります。nullとundefinedは値なしを意味し、No countを表示しなければなりません。正のカウントは引き続き表示される必要があります。その他の入力バリデーションや単数形の文法対応は本タスクの対象外です。

ソース R-02 — result-label.mjsにおける提案差分:

 export function resultLabel(count) {
-  return count ? `${count} results` : 'No count';
+  return count !== null ? `${count} results` : 'No count';
 }

ソース R-03 — パッチ作成者の主張: 「これによりカウント0が修正され、値なしのケースも変更なく維持されます。」この一文はテストが実行された証拠ではなく、検証すべき主張として扱ってください。

次のように依頼します。「R-01に照らし合わせてR-02をレビューしてください。具体的なデグレードごとに、トリガー、変更された式、実際の挙動と期待される挙動、およびそれを実証する最小限の検証方法を提示してください。未解決の疑問点は分けて記載してください。修正の実装は行わないでください。」

指摘の例は次のとおりです。「追加された条件はnullを除外していますが、undefinedを受け入れてしまいます。変更された関数をundefinedで呼び出すとundefined resultsが返されますが、R-01ではNo countが要求されています。該当する変更コードは式count !== nullです。0、null、正のカウントと並んで、undefinedのチェックを追加してください。」この結論は提示されたJavaScriptから導き出されたものであり、Codexが検出またはテストしたという主張ではありません。

この指摘が作り出していない要素に注目してください。影響を受ける顧客数、本番環境の障害、参照されていないリポジトリの行番号、無関係なセキュリティリスクなどです。実際の差分では、検証済みのファイル名と行範囲を含めてください。このスニペットにおいては、存在しないソースの位置をでっち上げるよりも、正確な式名を挙げる方が誠実です。

要点を絞ったレビュー指示書をコピーする

Codexに送信する前に、正確なスコープを含め、角括弧で囲まれた各項目を置き換えてください。

タスク: この変更をレビューしてください。ファイルの変更やレビューの公開は行わないでください。
プロジェクト: [確認済みリポジトリ]
差分スコープ: [未コミットのファイル、またはベース/ヘッドのコミットID]
意図する挙動: [変更が達成すべき内容]
不変条件: [変更してはならない動作]
ソース: [仕様ID、再現手順、該当ファイルまたはパッチ]
優先事項: スタイルの整理ではなく、このスコープ内における正確性とデグレード。
各指摘について以下を返してください:
- 検証済みのファイル/行、または提示された正確な式
- トリガーとなる入力またはユーザー操作
- 実際の結果と期待される結果
- 変更箇所およびその呼び出しパスに基づく根拠
- 最小限の再現手順またはデグレード検証
- 捏造された頻度や重大度を含まない影響と不確実性
疑問点や未検証の仮説は別のセクションに記載してください。
テストが未実行の場合は、その旨を明記してください。提案されたテストコードはテストの実行証拠ではありません。
確認された問題点がない場合は、スコープと残余リスクを述べてください。
修正、コミット、プッシュ、マージ、デプロイは行わないでください。次の指示を待ってください。

指摘を鵜呑みにせず明確な判断へと繋げる

各指摘を該当ソースと照らし合わせて読みます。R-02の場合、変更された関数が依然として0とnullを処理できることを確認し、次いでundefinedをテストします。手を加えていないヘルパーに関する指摘がある場合、パッチがそこにどう到達するのかの説明が必要です。そうでなければ、無関係なバックログの作業である可能性があります。長いレポートが必ずしも有用なレビューとは限りません。

結果を平易な言葉で分類します。

• 確認されたデグレード: 仕様と再現ケースによって裏付けられています。範囲を限定した修正を許可するかどうかを判断し、関連するチェックを再実行します。
• 疑問点: 実際のアプリ内でundefinedがその関数に到達し得るかなど、前提条件の根拠が必要です。レビュアーの確信の強さではなく、呼び出しパスや仕様書に基づいて解決してください。
• スコープ外: 有益なコード整理は別途記録できます。現在のパッチを無断で拡大させるべきではありません。
• 確認された問題なし: レビューしたスコープにおいて実証された指摘はありませんでした。これは正確性の証明でも、テストスイートの完了でも、セキュリティの保証でもありません。

修正を承認する場合は、合意された指摘内容と不変条件を改めて明示します。新しい差分と実際のテスト出力を検査し、変更された動作をレビューしてください。最初のレビューが、その後の編集内容までカバーしているとみなしてはなりません。ローカル環境でテストが通ったとしても、本番環境の成果物に変更が含まれていることの証明にはなりません。

第三者視点のレビューを行うには、パッチ作成者の説明よりも前に、意図する挙動と正確なコードを提示してください。これによりレビュアーは、単に同意するための回答ではなく、検証すべき具体的な仕様を得られます。完全なリグレッションテストの演習が必要な場合は、Claude Code小さな修正のチュートリアルを活用してください。

レビュー結果が曖昧な場合の対処法

議論を起点とするレビューでは、ソースリンク付き録音コンテキストを活用して決定事項とその注意点を残します。非公開ミーティング全体やリポジトリの認証情報ファイルすべてではなく、許可された抜粋のみを渡してください。

Cueで試してみる

設定したショートカットを使用し、Cue Settingsでアクティブなモードを確認してください。利用可能なアプリコンテキストとアクションは、権限、バージョン、アカウントによって異なります。機密性の高い資料を提供する前にプライバシーポリシー (English)をご確認ください。本ガイドは、すべての処理がデバイス内にとどまることを保証するものではありません。

お使いのコンピューター向けCueを入手 · 現在のプラン (English)

サポートが必要な場合や誤りを見つけた場合は、Cueサポートにお問い合わせ (English)いただくか、eli@sophoninc.comまでメールでお知らせください。Cueのバージョン、プラットフォーム、モード、およびマスキング済みの事例を記載してください。パスワード、トークン、非公開ミーティングの資料は送信しないでください。