Codexの環境を点検して必要な仕組みを選ぶ

全体の中で、今回はここ

前回は架空のログインアプリで繰り返す確認漏れを防ぐ案を作りました。今回は自分の環境にすでに同じ検査や手順がないかを確かめます。

持ち帰るのは変更しない判断、または不足1点を安全に試す計画です。この最終回のあと、その計画を小さな対象で試し、結果を全体図の「3 結果を確かめる」へ戻します。

Step 1：指示を増やして迷いが増える

ログイン画面のレビュー用にSkillを追加したら、既存の指示と完了条件が食い違ったとします。片方は「ビルド成功で完了」、もう片方は「画面で確認」と書いてあります。ビルドはコードを動かせる形に組み立てる処理で、画面を実際に操作する検証とは別です。

ファイル数を増やしても、仕事の流れは整いません。AIが働くための手順・道具・権限設定・検証を組み合わせた仕組みを、ここではHarness（ハーネス）と呼びます。手順を選ぶルーティング、情報の選択、分担、検証、振り返りは、その設計に使える考え方です。

Step 2：ツール名と設計を分ける

pstackはCursorの名前で手順を書き、Claude Code用に違いを読み替える対応表（アダプター）も用意しています。pstack/docs/harness/claude-code.md の冒頭〜Toolsには、道具へ渡す指定値（引数）に関する規則があります。

Never pass a field or value the tool schema rejects.

道具が受け付ける項目と値の決まり（スキーマ）に合わせ、受け付けない指定を渡さない、という意味です。

同ファイルのSubagent fields〜Modelsを見ると、ツール名だけでなく、読み取り専用の指定、作業場所、モデル指定まで変換しています。Cursor-only featuresは対応しない機能を明示しています。

この表はClaude Code用です。Codexでも同じように動くという互換性の証明にはなりません。同じ文章形式のファイルでも、呼び出す道具や許可された操作が違えば同じ手順としては動かないためです。

自分の環境での扱い

仕事場を引っ越すとします。「会議用」と名札の付いた機器でも、新しい部屋でそのまま使えるとは限りません。使う目的と接続先を調べれば、そのまま運べる机、アダプターが要る機器、別の道具に替えられる仕事を分けられます。

アダプターで形が合っても、映像が出るかは接続して確かめます。予定を共有するのが目的なら、紙の予定表を持ち込まず、電子の予定表へ替える選択もあります。名前をそろえることと、同じ仕事ができることは別です。

実際の導入判断を図で見る

図を拡大（別タブ）

実際のpstackでも呼び出す道具だけでなくパスや権限を確認します。ログインの検証に使える既存テストがあれば、それが直接利用の候補です。pstackのコマンドがCodexでそのまま動くという意味ではなく、アダプターで解決できない違いもあります。

Step 3：今ある環境を棚卸しする

まず、対象プロジェクトで読むよう指定された指示ファイル、利用可能なSkill、テスト設定、検証手順を確認します。別プロジェクトの履歴や、パソコンの個人用フォルダー全体を調べる必要はありません。

次に「誰が手順を選ぶか」「何を実行できるか」「何をもって完了とするか」を対応づけます。例えば検証コマンドはあるのに、その結果を最終報告に残す決まりがないなら、検証基盤の新設より報告の不足を補う方が小さな変更です。

ここが核心です。機能がないと決める前に、既存の仕組みで目的を満たせるか確かめます。pstack/skills/principle-subtract-before-you-add/SKILL.md の本文も追加前に削除や簡略化を検討する原則です。

不足が完了報告だけだった場合、次のような項目を既存の手順へ提案できます。これは教材用の記述例で、新しい指示ファイルを作る指示ではありません。

## 完了報告の例
- 対象と、合格と判断する条件
- 実行した確認方法と、その結果
- 結果を確かめられる証拠の場所
- 未確認の範囲と、次に必要な確認

検査が実行できなければ未確認とする。
完了報告と、公開や環境への反映（デプロイ）の承認は分ける。

注意書きより、間違いを表せない形にする

たとえば、同じ1回の送信結果は「成功」と「失敗」のどちらか一方です。これを別々のON/OFFで持つと、両方がONになれます。状態を一つだけ選ぶ型にまとめれば、この矛盾を表せなくできます。非エンジニアでも、AIに「注意を足す以外に、この失敗が起きにくいデータの持ち方はある？」と聞けます。

根拠は状態を型で表す Model the Domain・L9–15 と、型の制約と外部入力の検証を分ける Type System Discipline・L9–12 です。まず改善案として出し、実装前に影響と確かめ方を確認します。

任せる範囲と止まる条件

人の指示を毎回待たず、決めた範囲でAIが作業を進めるのが自律実行です。

LaurenさんのLoops You Can Trustと自律実行ガイド・L9–16は、人が成功例を理解し、各段階で結果を検証して止められることを、自律実行の前提にしています。

例えば「練習用の検索画面だけを変更し、指定した操作を確認する」と範囲を決めます。権限外の操作は実行前に確認し、検証できなければ未確認として報告します。検証の合格と、人による公開の承認も別です。

autonomous-run・L5–11は完了条件、小さな検証、判断の記録を求めます。単なる停滞では別案を試し、本当に進めない場合に報告する設計です。元に戻せない操作を事前に確認する例外はNever Block on the Human・L9–15にあります。Codexの権限や繰り返し実行の仕組みは、環境ごとに別途確かめます。

Step 4：Codexで改善案を1点選ぶ

練習用リポジトリで、機密情報を除いた指示ファイル、テスト設定、検証手順の抜粋を用意します。入力を固定して比較するため、この実験では本文へ貼り付けた範囲だけを使います。

下に貼る「既存環境の資料」だけを読み、開発手順を点検してください。
ファイルの読み書き、コマンド実行、外部アクセスはしないでください。
資料にない動作は未確認とし、設定があることと実行成功を区別してください。

1. 手順選択、情報の取得、権限、検証、改善の役割を既存の仕組みに対応づける。
2. 直接利用、移植、概念のみ応用を区別する。
   Cursorのコマンドやモデル指定がCodexで動くとは仮定しない。
3. 重複や矛盾を根拠とともに示し、改善案を最大1件提案する。
   不足を補う案だけでなく、重複する指示の簡略化案でもよい。
   改善が不要なら「変更なし」と答える。削除や設定変更は実行しない。
4. 提案を試す入力、期待する結果、採用しない条件を示す。

返答は「確認できた事実／未確認事項／提案1件／検証方法」。

既存環境の資料：
［機密情報を除いた同じ資料を、ここに貼る］

比較用の依頼では番号付きの4項目を「開発手順の改善案を提案してください」に替え、資料、制約、出力項目を保ちます。新規チャット2つを同じモデル設定で使い、先の回答を後のチャットへ渡さないでください。

この実験で分かるのは提案の違いまでです。所要時間の短縮や不具合減少は、承認した改善を別の小さな作業で試し、結果を記録してから判断します。

今回持ち帰るもの

自分の練習用リポジトリの資料から、既存の検証、不足1点、試し方をメモに残します。足りていれば追加しません。

架空のログインアプリの例では、検証結果を残す欄がないだけなら、報告方法の変更が候補です。まずは実装を変えず、架空の検証結果を渡して、合格と未確認を区別して報告できるかを比べます。

今日のまとめ

• 点検：新設する前に、今ある指示と検証手順を調べる。
• 区別：直接利用、移植、概念の応用を混同しない。
• 実験：簡略化も含めて改善案を1点選び、承認後に小さく効果を確かめる。

次に実行すること

自分の環境について「変更なし」も含む改善案を1枚にまとめてください。提案を採用するなら、対象、許可する変更、合格条件、戻す条件を決めてから試します。ここまでが講座の区切りです。実装した結果は実行日と条件を添えて別に記録します。

参考

講座内のX投稿は公式の埋め込みです。表示時にXへ通信します。読み込めない場合は、投稿へのリンクから確認できます。