見出し画像

複数AIエージェントを疲れず安全に使うための運用設計

さとけさま

サーベイメモ．


この記事は，Claude Code，Codex，ChatGPT，ローカルLLMを並行して使うときの認知負荷，承認疲れ，コンテキスト管理，Goal mode，サブエージェント，Skills，Hooks，ローカルPCとSSH先の使い分けを整理したものです．

前提として，ここで扱う問題は「同じリポジトリを複数AIに同時編集させる方法」ではありません．むしろ，別々のジャンルの作業を別々のAIに頼んでいるにもかかわらず，人間だけが承認待ち，完了待ち，コンテキスト残量，作業状態を覚え続けることになり，認知負荷が高くなる，という問題です．

ここでの結論は，CLIをたくさん覚えることではありません．視覚的に状態を見たい場合は，Claude Code DesktopとCodex Windows appを中心にして，CLIは補助に回すのが自然です．そのうえで，承認設計，コンテキスト設計，作業環境設計を分けて考えるのが重要です．

1．問題の正体

複数AIを使った日に疲れる理由は，AIが4つあること自体ではありません．本質は，4つのAIがそれぞれ別々の状態を持ち，その状態を人間のワーキングメモリで監視していることです．

たとえば，あるAIはデータ処理中，別のAIはポスター案を出している途中，別のAIはお知らせメール設定の承認待ち，さらに別のAIはローカルLLMの検証中，という状態になります．このとき，人間は次のような判断を同時に抱えることになります．

  • どの作業が今動いているのか．

  • どの作業が承認待ちなのか．

  • どの作業が完了していて，確認すべきなのか．

  • どの作業は今日中に見なくてよいのか．

  • どの承認は安全で，どの承認は危険なのか．

  • どの会話はコンテキストが詰まりかけているのか．

  • どの作業はローカルPCでよく，どの作業はSSH先で行うべきなのか．

したがって，改善の焦点は「AIを減らす」ではなく，「人間が見る状態を減らす」ことです．

理想は，次のような設計です．

  • 状態確認はGUIのsession一覧に寄せる．

  • 承認の粒度はpermission ruleやsandboxで設計する．

  • 長く反復する作業はGoal modeで完了条件を固定する．

  • 調査ログや試行錯誤はサブエージェントに逃がす．

  • 毎回貼る手順はSkillsに逃がす．

  • 通知，整形，危険操作検知はHooksに逃がす．

  • 機密作業はクラウドに広げず，ローカルLLMや隔離環境を別枠で扱う．

2．まずUIの中心を決める

CLI中心に寄せるより，GUI中心のほうが合っています．理由は，モデル名，コンテキスト使用量，承認待ち，完了状態，複数sessionの状態を視覚的に把握したいからです．CLIは強力ですが，基本的には文字とコマンドで状態を確認する道具です．

現実的な中心は2つです．

1つ目はClaude Code Desktopです．Claude Code DesktopのCodeタブは，複数sessionをside barで管理し，作業を並列に進めるためのGUIです．公式ドキュメントでは，Codeタブにside bar，drag-and-drop layout，integrated terminal，file editor，visual diff reviewなどがあり，terminal不要で複数sessionを扱えると説明されています．

2つ目はCodex Windows appです．Codex appは，Codex threadsを並列に扱うdesktop experienceで，worktree，automations，Git機能を備えています．公式ドキュメントでは，1つのCodex app windowで複数projectにまたがるtaskを走らせられると説明されています．

つまり，基本構成は次のように見るとよいです．

  • Claude Code Desktopは，Local，SSH，Remoteをまたいだ対話的なcoding sessionのhubにする．

  • Codex Windows appは，ローカルPCやWSL上の複数project，複数threadのhubにする．

  • ChatGPTは，作業管制メモ，文章，ポスター，方針整理に使う．

  • ローカルLLMは，機密性の高い情報をクラウドに出さないための別枠として扱う．

  • CLIは，GUIが届かない場面，SSH先で軽く作業したい場面，local providerや特殊設定を試す場面に限定する．

3．Claude Code Desktopで複数sessionを扱う

Claude Code Desktopでは，Desktopアプリを複数個起動するというより，1つのClaude DesktopアプリのCodeタブ内で複数sessionを作って並列に扱います．公式ドキュメントでは，各sessionは独立したconversationで，自分のcontextとchangesを持ち，複数sessionを並列に実行できると説明されています．

Windowsでの基本操作は次の通りです．

1．Claude Desktopを開く．

2．上部のCodeタブを開く．

3．左side barの「+ New session」を押す．またはWindowsならCtrl+Nを押す．

4．session開始前にEnvironment，Project folder，Model，Permission modeを選ぶ．

5．作業指示を入力する．

6．別の作業を始めるときは，さらに「+ New session」を押す．

同じGit repositoryで複数sessionを作る場合，Claude Code DesktopはGit worktreeを使ってsessionごとに隔離された作業コピーを作ります．これにより，あるsessionの変更が別のsessionの変更とすぐには衝突しにくくなります．公式ドキュメントでは，worktreeは既定で`<project-root>/.claude/worktrees/`に保存されると説明されています．

分割表示の操作

公式ドキュメント上の操作は，WindowsではCtrlを押しながらside barの別sessionをクリックする，です．これにより，いま開いているsessionの横に2つ目のpaneとして別sessionが開きます．閉じるときはCtrl+\です．

ただし，実際の環境ではCtrl+クリックが複数選択のように見えることがあります．その場合は，session行の三点メニューを開き，「次で開く」から分割表示を選ぶ操作が実用的です．今回の画面では，三点メニュー内の「次で開く」が分割表示への入口でした．

分割表示の運用は，次のように考えると便利です．

  • 左paneに，いま確認したいメイン作業を置く．

  • 右paneに，承認待ち，別sessionの進捗，調査結果を置く．

  • すべてを常時並べるのではなく，必要な2つだけを並べる．

  • 作業が終わったらCtrl+\でpaneを閉じる．

3分割や4分割を常用するより，2分割で十分です．GUIの価値は，たくさん並べることではなく，今見るべきsessionを見失わないことです．

4．Codex Windows appで複数projectと複数threadを扱う

Codex appは，1つのwindowで複数projectのtaskを走らせることを前提にしたアプリです．公式ドキュメントでは，projectは特定directoryでsessionを始める単位であり，複数codebaseをprojectとして追加して切り替えられると説明されています．

Windows版のCodex appは，parallel agent threads，worktrees，automations，Git機能，in-app browser，artifact previews，plugins，skillsをサポートしています．また，native WindowsとしてPowerShellとWindows sandboxで動かすことも，WSL2内で動かすこともできます．

基本操作は次のように考えるとよいです．

1．Codex appを開く．

2．sidebarでprojectを追加する．

3．repoごと，またはmonorepo内の独立したapp/packageごとにprojectを分ける．

4．projectごとにthreadを作る．

5．同じprojectで別作業を並列に走らせたい場合はworktreeを使う．

Codex appのworktreeは，同じGit repository内で複数の独立taskを並列に進めるための機能です．公式ドキュメントでは，worktreeはGit worktreeを使い，Local checkoutとは別のcheckoutを作ることで，複数branchを並列に扱えると説明されています．[^codex_worktrees]

使い分けの考え方は次の通りです．

  • 別repoなら，別projectにする．

  • 同じrepo内の別作業なら，worktree threadにする．

  • monorepo内でsandbox範囲を狭くしたいなら，app/package単位でprojectを分ける．

  • Git管理されていないprojectでは，worktreeではなく直接directoryで動くことに注意する．

5．ローカルPC，WSL，SSH先をどう扱うか

ローカルPCだけでなく，SSHで他のマシンに接続して作業する場合があります．ここは重要です．なぜなら，AIエージェントの設定，Skills，Hooks，memory，permission profileは，どの環境で実行されているかによって実体が変わるからです．

たとえば，Windowsローカル，WSL，SSH先Linux，別のSSH先Linuxでは，home directoryが違います．したがって，`~/.claude/skills`，`~/.claude/agents`，`~/.codex`，`~/.agents/skills`の実体も違います．

共通化したい設定は，なるべくrepo内に置くのが安全です．逆に，個人PCだけ，SSH先だけ，会社PCだけに効かせたい設定はuser-levelに置くのがよいです．

Claude Code Desktopでは，session開始時にEnvironmentとしてLocal，Remote，SSHを選べます．Claude Code DesktopのCode tabは，Localファイルに直接アクセスするinteractive coding assistantとして説明されており，sessionごとにProject folderやModelやPermission modeを選べます．

Codex側では，remote connectionsにより，別deviceや別machineからCodex hostに接続したり，Codex AppをSSH host上のprojectに接続したりできます．公式ドキュメントでは，remote accessは接続先hostのprojects，threads，files，credentials，permissions，plugins，Computer Use，browser setup，local toolsを使うと説明されています．

実務上の第一候補は次のように分けるとよいです．

  • ローカルPCのrepoは，Claude Code DesktopまたはCodex Windows appで扱う．

  • WSL上のrepoは，Codex Windows appのWSL構成か，必要に応じてCLIを使う．

  • SSH先のrepoは，Claude Code DesktopのSSH sessionを第一候補にする．

  • Codex appのSSH接続は，必要に応じて試す．ただしhost側のcredentialsやpermissionsを使うことを理解しておく．

  • GUIでは届かない場面だけCLIを使う．

6．CLIを主役にしなくてよい理由

Claude Code CLIやCodex CLIを複数terminalで起動することはできます．しかし重視しているのは，コマンドを覚えることではなく，モデル名，コンテキスト消費量，承認待ち，完了状態を視覚的に把握することです．

その意味では，CLIは主役にしなくてよいです．CLIは次のような限定用途に向いています．

  • GUIが入っていないSSH先で作業する．

  • 端末だけで素早く1回作業する．

  • ローカルLLMやlocal providerを試す．

  • 設定ファイルやpermission profileを細かく検証する．

  • CodexやClaude Codeのslash commandを使ってstatusやcontextを確認する．

Codex CLIには，`/model`，`/permissions`，`/compact`，`/status`，`/statusline`などのslash commandがあります．公式ドキュメントでは，`/status`でactive model，approval policy，writable roots，current token usageを確認でき，`/statusline`でmodel，context stats，token countersなどのfooter項目を選べると説明されています．

Claude Codeでも，permission modeの切り替えやcontext確認はできますが，GUIで見たい人にとってはDesktopのsession一覧やpane構成を使うほうが自然です．Claude Code公式ドキュメントでは，DesktopやVS Codeではmode selectorを使ってpermission modeを切り替えられると説明されています．

結論として，CLIを覚えないことは不利ではありません．CLIを覚えるより先に，GUIでのsession設計，permission設計，context設計を固めるほうが効果が大きいです．

7．承認ボタンを減らすには，承認を分類する

承認疲れを減らすには，単純に「全部自動承認」にするのではなく，承認を分類します．

まず，自動に寄せてよい操作があります．

  • repo内のファイル読み取り．

  • repo内のファイル編集．

  • `git status`．

  • `git diff`．

  • test実行．

  • lint実行．

  • formatter実行．

  • Python scriptの実行．

  • ログ確認．

次に，確認を残す操作があります．

  • `git commit`．

  • package install．

  • network access．

  • 外部API実行．

  • mail送信．

  • `git push`．

  • deploy．

  • PR作成．

最後に，拒否または強い確認にする操作があります．

  • `.env`の読み取り．

  • 秘密鍵の読み取り．

  • tokenやcredential fileの読み取り．

  • repo外directoryの読み書き．

  • `rm -rf`系．

  • 外部への大量送信．

  • 権限緩和やsecurity設定の変更．

Claude Codeでは，permission ruleとしてallow，ask，denyを設定できます．公式ドキュメントでは，`/permissions`でtool permissionを確認，管理でき，allowは確認なし，askは確認あり，denyは使用禁止として扱われます．また，deny，ask，allowの順に評価され，最初に一致したruleが勝つと説明されています．

Claude Codeのpermission modeには，default，acceptEdits，plan，auto，dontAsk，bypassPermissionsがあります．公式ドキュメントでは，defaultは読み取り中心，acceptEditsはfile editsやcommon filesystem commandsを自動承認，planは読み取り中心の探索，autoはbackground safety checks付きの長い作業向け，bypassPermissionsは隔離containerやVM専用と説明されています．

Codexでは，sandboxとapproval policyを分けて考えます．CodexのAuto presetでは，working directory内の読み取り，編集，command実行は自動で進められますが，workspace外の編集やnetwork accessにはapprovalが必要です．また，defaultの`workspace-write` sandboxではnetwork accessは無効で，必要なら設定で有効化する必要があります．

CodexにはAuto-reviewもあります．Auto-reviewはmanual approvalを完全になくすものではなく，sandbox boundaryで発生する一部のapprovalを別のreviewer agentへ回す機能です．公式ドキュメントでは，Auto-reviewはsandbox boundaryを広げるものではなく，誰がapproval requestをreviewするかを変えるだけだと説明されています．

8．過去の承認履歴からprofileを自動生成できるか

現時点で，Claude CodeやCodexの公式機能として，「過去にYesと答えた承認履歴をもとにpermission profileを自動生成する」機能は明確には見当たりません．ただし，近いことはできます．

Claude Codeでは，Bash commandに対して「Yes，don’t ask again」を選ぶと，project directoryとcommand単位で承認を保存できます．公式ドキュメントでは，Bash commandsは永久的にproject directoryとcommand単位で保存される一方，file modificationの承認はsession終了までと説明されています．

Codexでは，PermissionRequest hookがあります．公式ドキュメントでは，PermissionRequestはCodexがapprovalを求める直前に発火し，hook側がallow，deny，または通常のapproval promptへ戻す判断を返せると説明されています．

つまり，実用上の方向性は次の通りです．

  • 過去履歴から完全自動生成するのではなく，よく許可する操作を手でrule化する．

  • Claude Codeでは`/permissions`と「Yes，don’t ask again」を使う．

  • Codexではpermission profile，sandbox，approval policy，Auto-reviewを組み合わせる．

  • さらに進めるならHookで承認要求をログ化し，後でprofile候補を作る．

さらに，Claude Codeには`/fewer-permission-prompts`というSkillがあります．公式コマンド一覧では，transcriptを走査して，共通して出てくるread-onlyのBash commandやMCP tool callを見つけ，projectの`.claude/settings.json`へ優先度付きallowlistを追加してpermission promptを減らす，と説明されています．これは「過去のYes/No履歴から完全自動で安全profileを生成する」ものではありませんが，少なくとも，実際の利用履歴をもとにread-only操作のallow候補を作る方向にはかなり近い機能です．

使うときは，次の順番が安全です．

  • 数日間，普段どおり作業してtranscriptを蓄積する．

  • `/fewer-permission-prompts`を実行する．

  • 生成または変更された`.claude/settings.json`を確認する．

  • read-onlyに見えても，外部送信やsecret参照につながる操作はallowに入れない．

  • `git push`，deploy，mail送信，package install，credential参照はaskまたはdenyに残す．

最初に作るprofileは保守的でよいです．repo内編集，test，lint，`git diff`までは止めない．push，deploy，mail送信，secret参照，repo外操作は止める．この境界だけでも承認ボタンはかなり減ります．

9．コンテキスト管理の基本

コンテキスト管理では，何をメイン会話に残し，何を外に逃がし，何を毎回読み込ませるかを分けます．

メイン会話に残すべきものは，要件，制約，判断，変更方針，未解決点です．

外に逃がしたいものは，grep結果，長いログ，スタックトレース全文，試行錯誤，探索過程，関係なさそうな候補です．

手順化したいものは，Pythonデータ処理の作法，最終報告形式，レビュー観点，PDFや画像の作成手順，テスト実行手順です．

機械化したいものは，承認待ち通知，formatter，secret参照ブロック，危険コマンド検知，作業終了時のsummary保存です．

Claude Codeのcontext windowは，instructions，読んだファイル，自分の応答，terminalに見えていない内容まで含みます．公式ドキュメントでは，開始前にCLAUDE.md，auto memory，MCP tool names，skill descriptionsなどがcontextに読み込まれ，file readもcontextを増やすと説明されています．

Claude Codeでは，長いsessionでcontextが埋まるとcompactionが行われます．公式ドキュメントでは，`/compact`により会話をstructured summaryに置き換えられ，project-root CLAUDE.mdやauto memoryは再注入され，hooksはcontextではなくcodeとして扱われると説明されています．

Codex CLIにも，`/compact`と`/status`があります．公式ドキュメントでは，`/compact`はvisible conversationを要約してtokenを空けるために使い，`/status`はactive model，approval policy，writable roots，token usageを確認するために使うと説明されています．

重要なのは，compactionがあっても万能ではないことです．compactionは長い会話を要約して続けるための仕組みですが，何を要約に残すべきかは常に完璧ではありません．したがって，長い作業では自然な区切りで「ここまでの決定事項，変更ファイル，未解決点」を明示的に整理するほうが安定します．

10．Goal mode，/goal，長時間自律実行

ここまでの話に，もう1つ大事な機能が加わります．それが，Claude CodeやCodexの`/goal`です．

`/goal`は，単に「目標を書くプロンプト」ではありません．通常のAI作業では，1ターンごとにAIが作業し，結果を返し，人間が「続けて」「次はこれを見て」「まだ終わっていない」と指示する必要があります．Goal modeは，この「続けて」ループを減らすために，最初に完了条件を宣言し，AIが複数ターンにわたってその条件を満たすまで作業を続ける仕組みです．

重要なのは，Goal modeはサブエージェントではない，という点です．サブエージェントは別contextで調査する機能です．一方，Goal modeは現在のsessionやthreadに，持続的な完了条件を与える機能です．したがって，メインsessionのcontextは使い続けます．作業が長くなればcontextは消費され，必要に応じてcompactionやsummaryが重要になります．

Claude Codeの`/goal`

Claude Codeの`/goal`は，Claude Code v2.1.139以降で使えます．公式ドキュメントでは，`/goal`は完了条件を設定し，Claudeが各ターンの後に小さな高速モデルで条件達成を判定し，未達なら次のターンを開始する，と説明されています．条件が達成されるとgoalは自動的にclearされます．

Claude Codeでの基本操作は次の通りです．

/goal all tests in test/auth pass and the lint step is clean

このように，`/goal`に続けて満たしてほしい条件を書きます．Goalがactiveになると，Claudeはその条件をdirectiveとしてすぐに作業を始めます．`/goal`を引数なしで実行すると，現在のgoal，実行時間，評価済みturn数，token spend，evaluatorの直近理由を確認できます．`/goal clear`で途中終了できます．`stop`，`off`，`reset`，`none`，`cancel`もclearのaliasとして扱われます．[^claude_goal_usage]

Claude Codeの`/goal`で特に重要なのは，evaluatorが独自にcommandを実行したりfileを読んだりするわけではないことです．evaluatorは，Claudeが会話中に表面化させた情報を見て，条件が満たされたかを判定します．そのため，「testが通った」と判断させたいなら，Claude自身にtestを実行させ，その結果をconversationに出させる必要があります．公式ドキュメントでも，条件は「1つの測定可能なend state」「どのcheckで証明するか」「途中で守るべきconstraints」を含むとよい，と説明されています．

良いClaude Codeのgoalは，たとえば次のようなものです．

/goal tests/auth 配下のpytestがすべてpassし，ruff checkがcleanで，変更はsrc/authとtests/authに限定されている状態にしてください．各turnで実行した確認を短く報告し，20 turnsを超える場合は止まって未解決点を報告してください．

このgoalには，完了条件，検証方法，変更範囲，長時間化した場合の停止条件が含まれています．Goal conditionは最大4000文字まで書けると説明されているため，短すぎる曖昧なgoalより，制約と確認方法を含むgoalのほうが安定します．

Claude Codeの`/goal`は，session-scopedなprompt-based Stop hookの組み込みショートカットです．つまり，毎回hook設定を書くほどではないが，「このsessionでは条件を満たすまで続けてほしい」というときに使います．公式ドキュメントでは，`/goal`とAuto modeは補完関係にあり，Auto modeはsingle turn内のtool approvalを減らし，`/goal`はturn間の「続けて」を減らす，と説明されています．

この点は，承認疲れの話と直結します．`/goal`だけでは，危険なtool callの承認は減りません．承認ボタンを減らしたいなら，permission modeやallow/ask/deny ruleを設計する必要があります．逆に，permissionを整えたうえで`/goal`を使うと，「testが落ちたので直す」「もう一度testを回す」「別の原因を探す」という反復を人間が逐次促さなくてよくなります．

CodexのGoal mode

CodexにもGoal modeがあります．公式のCodex use caseでは，`/goal`はCodexにdurable objectiveを与え，verifiable stopping conditionに向けてturnをまたいで作業させる機能として説明されています．`/goal <objective>`で設定し，`/goal`で現在のgoalを確認し，`/goal pause`，`/goal resume`，`/goal clear`で制御できます．

Codexでは，Goal modeはCodex app，IDE extension，CLIで使えます．Codex appでは，goalがactiveなときにcomposerの上にprogress rowが表示され，pause，resume，edit，clearをボタンで操作できます．これは，コマンドを覚えたくない人にとってかなり重要です．GUIでgoalの状態を見て，必要ならボタンで止めたり，編集したりできます．

環境によって`/goal`がslash command一覧に出ない場合は，Codexの`config.toml`で次のfeature flagを有効化します．

[features]
goals = true

公式ドキュメントでは，CLIで`codex features enable goals`を実行するか，Codexにそれを実行するよう頼む方法も案内されています．ただし，Codexのchangelogでは，Goal modeはすでにexperimentalではなく，Codex app，IDE extension，CLIで利用可能になったと説明されています．環境差がある場合は，まずアプリやCLIや拡張機能を更新するのがよいです．

CodexのGoal modeでは，goal textがstarting promptであると同時にcompletion criteriaになります．つまり，goalに何を書くかがそのまま作業の方向性と終了判定に影響します．公式ドキュメントでは，specific outcome，measurable target，test criteriaを含めるのがよいと説明されています．また，事前にgoalを定義しづらい場合は，まず`/plan`でCodexにgoalを形にさせてから`/goal`に入る方法も勧められています．

Codexでの良いgoalは，次のような形です．

/goal Complete the weather notification mail setup until the local dry-run command succeeds, no real email is sent, credentials are not read from .env unless explicitly approved, and the final report lists changed files, verification commands, and remaining risks.

日本語で書くなら，次のようにしてもよいです．

/goal お知らせメール設定を，dry-runが成功し，実メール送信が行われず，credentialや.envの参照は明示承認なしでは行わず，最後に変更ファイル，検証コマンド，残リスクを報告する状態まで進めてください．

Codex Cookbookでは，Goalは「背景なしの自律性」ではなく，scopeされたuser-controlled completion contractだと説明されています．結果，検証面，制約，境界，反復方針を定義し，goalはpause，resume，clear，complete，budget stopで制御されます．

Goal modeはどの問題を解くのか

Goal modeが解くのは，「turn間の手動継続」です．たとえば，testを実行し，失敗し，修正し，またtestし，別の失敗を見つけ，また直す，という反復です．これまでは人間が毎回「続けて」と言う必要がありました．`/goal`を使うと，完了条件に照らしてAIが次のturnへ進みます．

一方，Goal modeが解かない問題もあります．

  • 危険操作の承認を自動で安全に分類すること．

  • 不明確な目的を勝手に正しい目的へ変換すること．

  • secretやcredentialの扱いをpermissionなしで安全化すること．

  • main sessionのcontext消費をゼロにすること．

  • 複数repoやSSH先の設定差を吸収すること．

したがって，Goal modeは，permission，sandbox，Hooks，Skills，Subagentsの代替ではありません．むしろ，これらと組み合わせたときに効きます．

Goal modeとコンテキスト

Goal modeは，同じsessionやthreadがturnを重ねるため，メインcontextを消費します．サブエージェントのように調査ログを別contextへ完全に逃がす機能ではありません．長時間走らせるほど，Claude CodeやCodexが読んだファイル，実行結果，判断，修正履歴がcontextに入ります．

そのため，Goal modeを使う場合は，次の設計が重要です．

  • goalの中に，短いprogress logを残すよう書く．

  • 生ログ全文ではなく，失敗原因と次の試行だけを報告させる．

  • 長い調査はread-only subagentに任せ，main agentには要約だけ戻す．

  • 区切りごとに変更ファイル，検証結果，残課題をまとめさせる．

  • hardな長時間作業では，turn数や時間の上限をgoalに含める．

  • contextが詰まってきたら`/compact`やsummaryで継続する．

つまり，Goal modeは「長く走るからcontext不要」ではなく，「長く走るからこそ，contextを汚さない設計が必要」な機能です．

Goal modeと承認

Goal modeは，人間が「続けて」と言う回数を減らします．しかし，tool approvalをすべて消す機能ではありません．Claude Codeの公式ドキュメントでも，Auto modeはtool call承認を減らし，`/goal`はturn間のpromptを減らす，という役割分担で説明されています．

したがって，承認疲れを減らすには，次の組み合わせが現実的です．

  • repo内編集，test，lint，formatter，`git diff`はallow寄りにする．

  • push，deploy，mail送信，network，secret参照はaskまたはdenyに残す．

  • 長い反復作業は`/goal`で進める．

  • goalの中に「実メール送信しない」「pushしない」「credential参照は承認待ちにする」などの境界を書く．

  • Hookやpermission ruleで，本当に止めたい操作を機械的に止める．

この組み合わせにより，人間は「続けて」を押す作業から解放されつつ，危険操作では止まれる状態になります．

Goal modeとSSH，WSL，ローカルPC

Goal modeは，現在のsessionやthreadの環境で動きます．Claude Code DesktopでSSH sessionを開いて`/goal`を使うなら，作業対象はSSH先のprojectです．Codex appでremote projectやWSL projectを開いてGoal modeを使うなら，そのthreadが見ているhostやfilesystemやpermission設定が前提になります．

ここで注意すべきことは，Goal modeの便利さで環境境界を忘れないことです．

  • ローカルPCのgoalなのか，SSH先のgoalなのかを明示する．

  • WSL上のrepoなのか，Windows nativeのrepoなのかを明示する．

  • hostごとに`.claude/settings.json`や`.codex/config.toml`が違うことを意識する．

  • secretやcredentialの場所がhostごとに違うことを意識する．

  • 長時間goalを走らせる前に，作業directoryとbranchを確認する．

Goal modeは「同じsessionで続ける」機能なので，sessionの環境を間違えると，間違った場所で長く正しく進んでしまいます．この点は，通常の1ターン依頼よりも注意が必要です．

`/goal`を使うべき作業，使わないほうがよい作業

使うべき作業は，完了条件が検証できるものです．

  • testがすべて通るまで直す．

  • lintがcleanになるまで修正する．

  • migrationがcompileとcontract testを満たすまで進める．

  • benchmarkが一定値を下回るまで改善する．

  • issue queueを空にする．

  • design docのacceptance criteriaを満たすまで実装する．

  • prototypeがbuild，launch，smoke testまで通る状態にする．

使わないほうがよい作業は，目的が曖昧なものです．

  • なんとなく良くして．

  • いい感じに整理して．

  • とにかく全部直して．

  • このrepoを理解して．

  • 何か改善点を探して全部対応して．

  • secretや外部送信を含む高リスク作業を，安全境界なしで長時間走らせる．

目的が曖昧な場合は，いきなり`/goal`に入らず，まず`/plan`でgoal候補を作らせます．Codexの公式ドキュメントでも，goalを事前に定義しづらい場合は`/plan`で形にしてからGoal modeへ入ることが勧められています．

良いgoalを書く型

実務では，次の型が使いやすいです．

/goal <望む終了状態>を達成してください．
検証方法は<具体的なtest，command，artifact，benchmark>です．
守る制約は<変更範囲，secret，network，push禁止，互換性>です．
各turnでは<短いprogress log，失敗原因，次の試行>だけを報告してください．
<turn数，時間，budget，blocked条件>を超えたら停止し，未解決点と次に人間が判断すべきことを報告してください．

より短く書くなら，次の4点だけでもよいです．

  • 何ができたら完了か．

  • 何で検証するか．

  • 何をしてはいけないか．

  • いつ止まるか．

これは，Codexのbest practicesにある「Goal，Context，Constraints，Done when」とほぼ同じ考え方です．

位置づけ

`/goal`はCLI習得のための機能ではなく，承認待ちとturn間待ちを減らすための機能として見るのがよいです．

Claude Code Desktopでは，GUIのsessionを分割表示しつつ，長く反復する作業だけ`/goal`を使います．Codex Windows appでは，Goal modeのprogress rowを見て，pause，resume，edit，clearをボタンで操作します．通常の細かい相談や文章作成にはGoal modeを使わず，test修正，migration，data processing pipeline，mail設定のdry-run検証のような「終わったかどうかを検証できる作業」に使います．

最初に試すなら，次のような軽いgoalが安全です．

/goal このrepoの現状を壊さず，dry-runだけでデータ処理scriptを実行できる状態にしてください．検証はdry-run commandの成功と出力先fileの存在確認です．credential，.env，network，git pushは使わないでください．10 turns以内に終わらなければ停止し，未解決点を報告してください．

このくらい境界を明確にすれば，Goal modeの便利さを試しつつ，危険操作や長時間暴走を避けやすくなります．

11．サブエージェントとは何か

サブエージェントは，メイン会話とは別のcontextで動く専門agentです．Claude Codeでは，サブエージェントは独自のcontext window，custom system prompt，specific tool access，independent permissionsを持つと説明されています．また，検索結果，ログ，file contentsでメイン会話を溢れさせたくないside taskに使い，サブエージェントが自分のcontextで作業してsummaryだけ返す，とされています．

Codexでもサブエージェントを使えます．公式ドキュメントでは，Codexはspecialized agentsをparallelにspawnし，結果を1つのresponseに集約できると説明されています．Codexのsubagent workflowはdefaultで有効で，subagent activityはCodex appとCLIで表示され，IDE Extensionでの表示は今後対応予定とされています．また，Codexは明示的に頼んだときだけsubagentをspawnし，各subagentがmodelとtool workを行うため，単独agentよりtoken消費は増えます．

サブエージェントは，作業員を増やす機能というより，調査員とレビュアーを分ける機能として使うのが安全です．

良い使い方は次のようなものです．

まずサブエージェントを使って，read-onlyで調査してください．

1. 関連ファイルの探索
2. 既存処理の流れの確認
3. エラーになりそうな箇所のレビュー

各サブエージェントはファイルを編集しないでください．
最後に，main agentが調査結果を統合し，実装方針を1つに絞ってください．

悪い使い方は，複数のサブエージェントに同じファイルを同時編集させることです．これは差分衝突，承認待ち増加，方針の不一致を生みやすいです．

実務上は，次の原則が安全です．

  • サブエージェントはread-only調査から始める．

  • 実装するagentは原則1つにする．

  • サブエージェントの返答は短く制限する．

  • 生ログや全文引用をメイン会話に戻させない．

  • reviewer subagentは編集せず，指摘だけ返す．

  • 同じrepoで並列実装する場合はworktreeを使う．

Claude Codeでは`/agents`からcustom subagentを作成，管理できます．Project用なら`.claude/agents/`，user用なら`~/.claude/agents/`に置きます．Codexでは，custom agentを個人用なら`~/.codex/agents/`，project用なら`.codex/agents/`にTOMLとして置けます．

最初に作るなら，次の2つで十分です．

  • `repo-explorer`：関連ファイル，設定，処理の流れをread-onlyで調べる．

  • `risk-reviewer`：バグ，例外処理不足，security risk，テスト不足をread-onlyで見る．

12．Skillsとは何か

Skillsは，よく使う作業手順をAI側の道具箱に入れる仕組みです．毎回貼っている長いプロンプト，チェックリスト，多段手順をSkill化すると，指示のブレを減らせます．

Claude CodeのSkillsは，`SKILL.md`にinstructionsを書き，Claudeが関連すると判断したとき，または`/skill-name`で明示したときに使います．公式ドキュメントでは，CLAUDE.mdと違ってSkill本文は使われるまで読み込まれないため，長いreference materialのcostは必要になるまでほぼゼロと説明されています．

CodexのSkillsも同じ発想です．公式ドキュメントでは，Skillはtask-specific capabilitiesを与える仕組みで，`SKILL.md`と任意のscripts，references，assetsを含められます．Codexは最初にskillのname，description，file pathだけをcontextに入れ，必要になったときだけfull `SKILL.md`を読み込みます．ただし，利用可能skill一覧もcontextに入るため，skillが多すぎるとdescriptionだけでもcontextを圧迫します．

Skillsに向いているものは次の通りです．

  • 作業終了時の報告形式．

  • Pythonデータ処理の作法．

  • テスト実行と確認手順．

  • コードレビュー観点．

  • 画像やPDFなど成果物作成の手順．

  • 会社や個人の定型的な出力形式．

Skillsに向いていないものは次の通りです．

  • 大量のログ全文．

  • 巨大な仕様書全文．

  • 毎回必ず守らせたい短い安全ルール．

  • 実行結果に応じて強制的に止めたい安全境界．

毎回必ず守らせたい短いルールはCLAUDE.mdやAGENTS.mdへ置くほうがよいです．一方，たまに使う長い手順はSkillに逃がします．そして，判断ではなく機械的に強制したいことはHookにします．

最初に作るSkill候補は次の通りです．

  • `final-report`：完了したこと，変更したファイル，実行した確認，未完了，不確実な点，次に人間が判断すべきことを報告させる．

  • `python-data-processing`：Pythonコードの目的，入力，出力，実行方法，ログ，例外処理，PEP 8，確認方法を固定する．

  • `safe-review`：バグ，security，例外処理，テスト不足，仕様ズレを確認する．

  • `run-and-verify`：実行，確認，結果保存，失敗時の切り分けを固定する．

13．Hooksとは何か

Hooksは，AIにお願いする機能ではありません．特定イベントで外部commandやHTTP endpointやpromptを必ず実行する仕組みです．

Claude CodeのHooksは，Claude Codeがfileを編集した後，taskを終えたとき，input待ちになったときなどにshell commandを自動実行できます．公式ドキュメントでは，HooksはClaude Codeのlifecycleの特定地点で実行されるuser-defined shell commandsであり，LLMが自分で選ぶのではなく，deterministic controlとして使うものだと説明されています．

CodexのHooksでも，PermissionRequestなどのeventに対してscriptを走らせられます．PermissionRequestは，approvalが必要になる直前に発火し，hook側がallow，deny，通常のapprovalへ戻す判断を返せます．

Hooksに向いているものは次の通りです．

  • 承認待ちになったら通知する．

  • 作業終了時にsummaryを保存する．

  • `.env`や秘密鍵を読もうとしたら止める．

  • 危険commandを止める．

  • file編集後にformatterを走らせる．

  • 設定ファイルが変更されたらaudit logを残す．

  • compaction後に短いcontextを再注入する．

Hooksで注意すべきことは，出力をモデルに渡しすぎないことです．Hooksは出力しなければcontext消費が小さいですが，長いログやdiffをstdoutやadditional contextとして返すと，それ自体がcontext汚染になります．

最初のHookは，次の2つだけでよいです．

  • 承認待ち，入力待ちになったらWindows通知を出す．

  • `.env`，秘密鍵，tokenを読もうとしたらブロックする．

次の段階で，formatter，終了summary保存，危険command検知を追加します．

14．CLAUDE.mdとAGENTS.mdの位置づけ

CLAUDE.mdやAGENTS.mdは，毎回読ませたい短いルールを書く場所です．

Claude Codeでは，sessionごとにfresh context windowで始まり，知識を持ち越す手段としてCLAUDE.mdとauto memoryがあります．公式ドキュメントでは，CLAUDE.mdとauto memoryはどちらも各conversationの開始時に読み込まれ，contextとして扱われるが，enforced configurationではないと説明されています．

つまり，CLAUDE.mdに「`.env`を読まないで」と書くことは，Claudeの行動を誘導しますが，安全境界そのものではありません．本当に止めたい場合はpermission ruleやPreToolUse hookを使う必要があります．公式ドキュメントでも，行動をblockするにはPreToolUse hookを使うと説明されています．

使い分けは次の通りです．

  • 毎回必ず守る短いルールはCLAUDE.mdやAGENTS.mdへ．

  • たまに使う長い手順はSkillsへ．

  • 大量調査やログ読みはSubagentへ．

  • 強制したい安全柵や通知はHooksへ．

15．コンテキストへの影響を正しく見る

サブエージェント，Skills，Hooks，CLAUDE.mdやAGENTS.mdは，コンテキストへの効き方が違います．

サブエージェントは，メイン会話のcontextを守るための機能です．サブエージェント自身は別contextで作業し，メイン会話にはsummaryだけ返します．したがって，メイン会話の汚染は少ないですが，総token消費は増えます．

Skillsは，存在するだけならname，description，file path程度の小さな消費です．しかし，呼び出すと本文が読み込まれます．Claude Codeでは，invoked skill bodiesはcompaction後に再注入される場合があり，per-skill capとtotal capがあります． したがって，Skillは短く，重要な指示を上に置くべきです．

Hooksは，基本的にはモデル外で動くためcontextをほとんど消費しません．ただし，HookがClaudeやCodexに長い出力を返すとcontextに入ります．そのため，Hookは短い判断だけ返すか，何も返さない設計にするのが安全です．

CLAUDE.mdやAGENTS.mdは，毎sessionで読み込まれるため，増やしすぎると常時contextを消費します．ここには短い原則だけ置き，長い手順はSkillへ移すのがよいです．

実用上の判断は次の通りです．

  • 「このprojectでは必ず守る」なら，CLAUDE.mdやAGENTS.md．

  • 「この作業をするときだけ必要」ならSkill．

  • 「調べて要約だけ返して」ならSubagent．

  • 「必ず止める，必ず通知する，必ず整形する」ならHook．

16．ローカルLLMと機密情報

機密情報を扱う場合，Claude CodeやCodexをそのままクラウド連携で使うのとは別に，ローカルLLMや隔離環境を用意したくなるのは自然です．

ここで重要なのは，Claude Codeを無理にローカルLLM化しようとする話と，Codex CLIやlocal providerを使う話は別論点だということです．この部分は設定や安全性の設計が重くなるため，この記事では深掘りしません．

ただし，運用上の原則は明確です．

  • 機密性が高い情報は，最初からクラウドAIへ広げない．

  • どの環境でAIが動いているかをsessionごとに明確にする．

  • ローカルPC，WSL，SSH先，local LLMの設定を混同しない．

  • secret参照を止めるpermission ruleやHookを先に入れる．

  • local LLM環境は，便利さより安全境界を先に設計する．

17．おすすめの最小構成

最初に，Claude Code DesktopのCodeタブで複数sessionと分割表示に慣れます．すでに「三点メニュー」から「次で開く」を使って分割表示できることを確認しました．この操作を，承認待ち確認や別sessionの進捗確認に使います．

次に，Codex Windows appで複数projectとworktreeの考え方に慣れます．別repoは別project，同じrepoの並列作業はworktree，というルールにします．

次に，`final-report` Skillを作ります．これにより，どのAIからの報告も同じ形式になります．

次に，`repo-explorer`と`risk-reviewer`のread-only subagentを作ります．最初から実装workerを増やさず，調査員とレビュアーだけを増やします．

次に，承認待ち通知Hookとsecret参照ブロックHookを入れます．承認ボタンを減らすより前に，承認待ちを見逃さない仕組みと，危険操作を止める仕組みを作ります．

最後に，permission ruleを少しずつ緩めます．repo内編集，test，lint，`git diff`は止めない．push，deploy，mail送信，secret参照は止める．

18．実際に使うプロンプト例

普段の作業開始時は，次のような指示で十分です．

まずread-onlyのサブエージェントを使って，関連ファイルと影響範囲を調査してください．
調査結果を統合したあと，実装方針を1つに絞ってください．

実装はmain agentだけが行ってください．
サブエージェントはファイル編集，削除，commit，pushをしないでください．

作業終了時は，以下を報告してください．
1. 完了したこと
2. 変更したファイル
3. 実行した確認
4. 未完了・不確実な点
5. 次に人間が判断すべきこと

レビューだけ頼むときは，次のように明示します．

実装はしないでください．
差分レビューだけしてください．

観点は以下です．
1. 仕様と違う挙動がないか
2. 例外処理が不足していないか
3. secretやcredentialの扱いが危なくないか
4. テスト不足がないか
5. 変更が大きすぎないか

最後に，修正必須，任意改善，問題なし，に分けて報告してください．

Codexでサブエージェントを明示するなら，次のように英語のtrigger phraseを入れると伝わりやすいです．

このbranchをmainと比較してレビューしてください．
spawn one agent per pointで，以下を並列に確認してください．

1. Bugs
2. Security issues
3. Test gaps
4. Maintainability
5. Spec mismatch

各agentはread-onlyで調査し，最後に統合結果だけ返してください．

Claude Codeでサブエージェントを使うなら，次のように言えばよいです．

サブエージェントを使って，このrepoの構造を調査してください．
調査のみで，ファイル編集はしないでください．
最後に，関連ファイルと作業方針だけを要約してください．

Goal modeを使うなら，完了条件，検証方法，制約，停止条件を一緒に書きます．

/goal tests/auth配下のpytestがすべてpassし，ruff checkがcleanで，変更はsrc/authとtests/authに限定されている状態にしてください．credential，.env，network，git pushは使わないでください．各turnでは失敗原因と次の試行だけを短く報告し，20 turns以内に終わらなければ停止して未解決点を報告してください．

Codex appでコマンドを覚えたくない場合でも，composerに`/goal`を書いて開始したあと，active goalのprogress rowに出るpause，resume，edit，clearのボタンで制御できます．

19．permission設定の考え方

Claude Codeでは，最初はacceptEdits寄りの運用が現実的です．ただし，危険操作はdenyやaskに残します．bypassPermissionsは，公式にも隔離containerやVM向けとされているため，通常の業務PCで使うべきではありません．[

考え方としては，次のような設定を目指します．

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(git status *)",
      "Bash(git diff *)",
      "Bash(python *)",
      "Bash(pytest *)",
      "Bash(npm run *)",
      "Bash(pnpm run *)"
    ],
    "ask": [
      "Bash(git commit *)",
      "Bash(git push *)",
      "Bash(curl *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

これはあくまで思想の例です．実際には，project，会社ルール，OS，shell，network policyに合わせて調整が必要です．

Codexでは，まず次のような考え方が現実的です．

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "auto_review"

`workspace-write`で作業directory内は進める．`on-request`で境界を越えると止める．`auto_review`で，eligibleなapproval requestをreviewer agentに寄せる．ただし，Auto-reviewはpermission grantではなくreviewer swapであり，sandbox boundaryは変わりません．

20．フォローしておくべき話題

今後追うべき話題は，新機能の羅列ではなく，AIエージェントを疲れず安全に使うための運用設計です．特に重要なのは次の領域です．

Goal mode，/goal，長時間自律実行

`/goal`は，Claude CodeでもCodexでも，turn間の「続けて」を減らす方向の機能です．ただし，完了条件が曖昧だと長時間迷走しやすく，承認や安全境界を自動で解決するわけでもありません．今後は，Goal mode，Auto mode，permission，Hooks，subagentsをどう組み合わせるかが重要になります．

承認設計，permission，sandbox

承認疲れを減らすには，どの操作を自動化し，どの操作を止めるかを継続的に見直す必要があります．Claude Codeのpermission mode，allow/ask/deny rule，Codexのsandbox，approval policy，Auto-reviewは今後も変わる可能性があります．

コンテキスト管理，compaction，memory

長い作業ほど，contextに何を残すかが成果を左右します．CLAUDE.md，AGENTS.md，auto memory，Skills，subagents，Hooksの役割分担を定期的に見直すべきです．

サブエージェントの分担設計

サブエージェントは，調査，レビュー，検証には強いですが，同時編集には注意が必要です．read-only調査員，risk reviewer，implementation workerの境界を設計することが重要です．

SkillsとPlugins

毎回貼っている手順はSkill化できます．ただし，Skillを増やしすぎると一覧だけでもcontextを圧迫します．短く，役割ごとに分けるのが安全です．

Hooks，通知，ログ，承認履歴

画面を見張らないためには，承認待ち通知や作業終了通知が重要です．さらに，PermissionRequestやPreToolUseで承認要求をログ化すれば，将来的にpermission profile候補を作れます．

MCPと外部ツール連携

MCPでGitHub，Figma，社内ドキュメント，browser，monitoring toolなどにつなげると便利ですが，権限と情報漏えいのリスクも増えます．MCPはpermission設計とセットで追うべきです．

remote，SSH，WSL，worktree

ローカルPC，WSL，SSH先が混ざる場合，設定の置き場所が特に重要です．project-levelに置くか，user-levelに置くかを意識しないと，ある環境では効いているruleが別の環境では効かない，という状態になります．

Evals，traces，品質測定

少し先の話ですが，AI作業の品質を感覚ではなく測る方向も重要です．「この手順なら失敗が減る」「このreviewer subagentは見落としが少ない」という形で，workflow自体を評価できるようにすると，AI運用はかなり安定します．

21．この記事の最終結論

複数AIエージェントを使うときの問題は，AIの性能差だけではありません．本当の問題は，人間が承認，状態監視，コンテキスト管理，安全判断をすべて背負ってしまうことです．

結論は，以下の通りです．

CLI中心に寄せなくてよい．

  • Claude Code DesktopとCodex Windows appをGUI hubにする．

  • Claude Code Desktopでは複数sessionと分割表示を使う．

  • Codex Windows appでは複数projectとworktreeを使う．

  • ローカルPC，WSL，SSH先では設定の置き場所を分けて考える．

  • 承認は全部手動でも全部自動でもなく，safe，ask，denyに分類する．

  • Goal modeは，完了条件が検証できる長い反復作業に使う．

  • サブエージェントは調査とレビューに使う．

  • Skillsは毎回貼る手順を短く再利用する．

  • Hooksは通知，安全柵，自動整形に使う．

  • メイン会話には，判断と方針だけを残す．

最初に導入するなら，次の6点で十分です．

  • Claude Code Desktopの分割表示を普段使いにする．

  • 軽いdry-run作業で`/goal`を試し，goalの型を身につける．

  • `final-report` Skillを作る．

  • `repo-explorer` subagentをread-onlyで作る．

  • `risk-reviewer` subagentをread-onlyで作る．

  • 承認待ち通知Hookとsecret参照ブロックHookを入れる．

ここまで入れると，AIを増やしても，人間が背負う状態管理はかなり減ります．AIエージェントを増やすほど必要になるのは，さらに賢いAIというより，状態，承認，コンテキスト，安全境界を整理する運用設計です．

いいなと思ったら応援しよう！