頼むための説明のほうが、自分でやるより重いなら、頼まない。
AIエージェントに投げるか、自分でやるか。
迷う時間そのものが損なので、数字で決めた。
・指示文が成果物より長くなりそうなら投げない
・前提の説明に3往復以上かかりそうなら投げない
@ritsu-hayase.bsky.social
@ritsu-hayase.bsky.social頼むための説明のほうが、自分でやるより重いなら、頼まない。
AIエージェントに投げるか、自分でやるか。
迷う時間そのものが損なので、数字で決めた。
・指示文が成果物より長くなりそうなら投げない
・前提の説明に3往復以上かかりそうなら投げない
@ritsu-hayase.bsky.socialエージェントを2つ動かすと、消費量は素直に2倍になる。
速度は2倍にならない。
私の財布だけが正直に反応する。
それでも2つ目を入れる価値がある作業と、無い作業がある。
私の場合、価値があったのはレビューと、判断が割れる設計。
無かったのは、設定値の変更。
2つ目を入れてよかったのは、どんな作業？
@ritsu-hayase.bsky.social2つのAIが揃って「そのオプションがあります」と言う。
無いことがある。2人とも自信満々で。
学習元が重なっている以上、通説の誤りは両方が同じように再生産する。
決め手は一次情報。
--help に無ければ、それは存在しない。
@ritsu-hayase.bsky.social指示ファイルに書いたルールは、後ろのほど守られない。
私のファイルも、下半分は飾りだった。
なので守らせたい順に並べて、上位だけ残している。
何行までが実用範囲かは、まだ分かっていない。
足すたびに、上のルールが薄まる感触だけある。
指示ファイル、何行くらいで運用している？
@aicoding-guide.bsky.socialNew: Codex CLI v0.160 and how to configure automatic review (Guardian)
https://aicoding-guide.com/en/posts/codex-update-0-160/
#Codex #CodexCLI
@aicoding-guide.bsky.social新着記事: Codex CLI v0.160 の変更点と自動レビュー(Guardian)の設定
https://aicoding-guide.com/posts/codex-update-0-160/
#Codex #CodexCLI
@ritsu-hayase.bsky.social「command not found」
入っていないとは限らない。PATHに無いだけのことが多い。
where codex と which claude で、まず在り処を見る。
入れ直した後に見つかると、二重に悲しい。
@ritsu-hayase.bsky.social「運用が回っています」と言うのは簡単だ。私が見るのはこの5つ。
1: 毎回同じ指示を打ち込まなくなった
2: 「テストは通りましたか」と聞き返さなくて済む
3: どちらのツールに投げても同じ方針で返ってくる
4: 新しい案件でも、ルールファイルをコピーするだけで済む
5: 事故が起きたとき、原因をルールに1行足せば再発しない
5つのうち3つ。それ以下なら、まだ運用ではなく毎回の力技だ。
@ritsu-hayase.bsky.social実行役に頼むたびに新しい会話を立てていた頃、毎回ゼロから説明していた。直したのは3つ。
1: 1つのタスクには1つのスレッド。最初に返る識別子を控える
2: 新しいスレッドを立てるのは、テーマが変わったときだけ
3: 会話が長くなったら、要約を渡して同じスレッドで引き継ぐ
説明し直す時間は、作業時間じゃない。
@ritsu-hayase.bsky.social「またこれか」。差分を見て、そう思った。覚えのない変更が混ざっている。
2つに同じファイルを触らせた結果だ。以後、私が固定していること。
1: 書き込む側を1つに固定する。もう片方は読み取り専用
2: 作業単位で必ずコミットする（衝突しても戻せる）
3: 同時に走らせるなら作業ツリーを分ける
「書く役は1人」。決めるまでは事故で、決めたあとはルールだ。
@ritsu-hayase.bsky.social実行役への依頼が3往復目に「さっきの続きで」に縮んだら、事故の前兆だ。この4点だけは削らない。
1: 何を作る・直すか
2: 触ってよい範囲（変更可／変更不可）
3: 却下済みの案（再提案させない）
4: 受け入れ条件（満たしたら完了）
2番目を削って一番痛い目を見た。
@ritsu-hayase.bsky.social「書き込めません」と言われたら、私はまず2つだけ確認する。
1: サンドボックスの値（read-only / workspace-write / danger-full-access）
2: 作業ディレクトリの指定（リポジトリの外に書くなら別途追加が要る）
レビュー用に read-only で起動したのを忘れて実装を頼む。一番多い自分の事故だ。
@aicoding-guide.bsky.socialNew: Codex CLI v0.158: MCP OAuth client secrets and approval for elevated commands
https://aicoding-guide.com/en/posts/codex-update-0-158/
#Codex #CodexCLI
@aicoding-guide.bsky.social新着記事: Codex CLI v0.158 の変更点:MCP の OAuth シークレット対応と昇格コマンドの承認
https://aicoding-guide.com/posts/codex-update-0-158/
#Codex #CodexCLI
@ritsu-hayase.bsky.social書いたルールが守られない。私が疑う順番。
1: そのツールがそのファイルを読む場所に置いてあるか
2: ファイル名が正しいか（CLAUDE.md と AGENTS.md）
3: ルールが具体的に書かれているか
4: ファイルが長すぎないか
5: 他の記述と矛盾していないか
1と2で大体終わる。AGENT.md を作って首をかしげたのは、私だ。
@ritsu-hayase.bsky.social言い回しまで似ていて、疑わずに信じた。あとで両方とも間違っていた。
AIが2つ、同じ答えを返してきたとき、私が疑う5つ。
1: 一致の速さと言い回し（似すぎていないか）
2: 前提を外して中立に聞き直す
3: 逆側から聞く（「欠陥を3つ挙げて」）
4: 一次情報に当たる（ヘルプか公式ドキュメント）
5: 実行して確かめる
一致したら安心、ではない。一致したら、まだ何も確認していない。
@ritsu-hayase.bsky.social「実装完了です」に、私は言葉を返さない。次の4点を貼らせる。
1: 実際に実行したコマンド（1文字も変えずに）
2: その終了コード
3: テストの件数（成功／失敗／スキップ）
4: 変更したファイルの一覧
3が最重要。「失敗0件」と「成功0件・失敗0件」は、報告では同じ顔をしている。
@ritsu-hayase.bsky.social「そのとおりです」「問題ありません」。両方が同じことを言った。
こういう一致を疑うとき、私が踏む5段階。
1: 主張を1文に書き出す（「Xは Yである」の形）
2: 出どころを確認する（ドキュメント・ヘルプ・実行結果）
3: 確認できなければ「不明」に落とす
4: 小さく試す（再現用のスクリプトを1本）
5: 結果をそのまま両方に共有する
一致は証拠じゃない。私が試した結果だけが証拠だ。
@ritsu-hayase.bsky.social「動きました」と言われたあと、私が見る5点。
1: 実行したコマンドと終了コードを、自分の目で見たか
2: テストの件数を確認したか（0件は失敗と同じ扱い）
3: 変更ファイルの一覧を確認したか
4: 期待した動きを、実際に1回動かしたか
5: 見た目の変更なら、実機かブラウザで見たか
5つとも埋まるまで、私の中では「未完了」だ。
@cysecuritynews.bsky.socialResearchers Escape OpenAI Codex Sandbox to Run Commands on Host #AICodingAgents #CodexCLI #CodexSandboxEscape