コーディングモードを廃止した理由：ツール選びはモデル自身に任せる

初期の Agent! には、コーディング、自動化、標準という3つのモードがありました。考え方自体は妥当に思えました。コーディングのタスクに Accessibility ツールは不要ですし、「このボタンをクリックして」というタスクに Xcode は不要です。関係のないものを隠せば、モデルが目にするツール一覧は短くなり、消費するトークンも減り、誤った選択も少なくなるはずでした。

2026年4月7日、コミット 7ea44c0d でこの仕組みは丸ごと削除されました。ここでは、その決め手となったバグと、そこから得られた原則を紹介します。

モードの仕組み

タスクの2ターン目に、ハーネスはユーザーの依頼内容を調べ、2つのキーワードリストと照合していました。build、compile、edit、fix、refactor といった単語はコーディングを意味し、click、button、window、photo、accessibility といった単語は自動化を意味します。そのうえでフラグ（codingModeEnabled または automationModeEnabled）を切り替え、モデルが参照できるツールをそのモードのグループに絞り込んでいました。モデル自身も mode ツールを使ってモードを切り替えることができました。

バグ：コーディングモードで動く Photo Booth

報告はただ「accessibility が壊れている」というものでした。原因をコミットメッセージの言葉を借りて説明すると、自動切り替えが open -a Photo Booth を未知のシグナルとみなし、デフォルトでコーディングモードに切り替えていたのです。コーディングモードでは Auto グループが除外されており、accessibility ツールはまさにその Auto グループに属していました。

つまり、モデルは写真を撮るよう指示されたのに、シャッターボタンを押すために作られた唯一のツールがタスクの途中で消えてしまったのです。モデルは、有能なモデルが残されたツールでやるべきことをしました。シェル経由の osascript にフォールバックしたのです。しかしそれは "Can't get toolbar 1 of window 1." というエラーで失敗し続けました。

モデルにも、accessibility ツールにも問題はありませんでした。ハーネスが意図を読み違え、正解を黙って取り上げてしまったのです。

修正にならない修正

すぐに思いつくパッチは、open -a を自動化のキーワードに追加することでした。コミットメッセージはこれをはっきりと指摘しています。それは「長く続く応急処置の列に、また一枚絆創膏を貼るだけ」だと。キーワードによる意図検出は勝ち目のないゲームです。新しいアプリ、新しい言い回し、新しい言語が増えるたびに新たな穴が生まれ、取りこぼしが起きるたびに最も分かりにくい形で失敗します。つまり、1ターン前にはできていたことが突然モデルにできなくなるのです。

代わりに導入したもの：何もなし

モードの仕組みは丸ごと削除されました。対象は13ファイルで、141行を削除し、39行を追加しました。削除したものは次のとおりです。

• codingModeEnabled と automationModeEnabled のフラグ、およびそれぞれのツールグループリスト
• メインのタスクループとタブタスクの両方にあった、2ターン目の自動切り替え
• プロンプトからツールグループを推測する関数 predictToolGroups()
• Claude および OpenAI 互換サービスにおける、ローカルエンドポイント向けのツール一覧の絞り込み
• サブエージェント用の coding と automation のエイリアス（代わりに実際のグループ名を渡します）

現在、ツールは設定（ToolPreferencesService）でユーザー自身が切り替えたトグルだけによってフィルタリングされます。有効にしたツールはすべて毎ターン利用でき、必要なものはモデルが選びます。

こうした削除作業の丁寧さを示す、小さな点が2つあります。mode ツールはいきなり削除されたわけではありません。"mode switching has been removed" と返すだけの no-op になりました。古い会話をコンテキストに持つモデルがまだ呼び出すかもしれず、未知のツールエラーより明確な回答のほうが優れているからです。また、システムプロンプトのリビジョンは71から72に上がりました。これにより、ディスクに保存されたモードに言及するプロンプトはすべて再同期されます。

結果

"Coding mode auto-enabled" のログが大量に出力されることはなくなりました。タスクの途中でツールが消えることもなくなりました。ターンごとにツール一覧が入れ替わることもなくなりました。

原則

この決定はその後の多くの設計に影響を与えたので、はっきりと述べておく価値があります。

ハーネスが担うべきは安全性の強制であり、意図の推測ではない。

Agent! は、客観的に判断できる部分では厳格です。壊滅的なシェルコマンド、モデルがまだ読んでいないファイルの編集、根拠のない「完了」を拒否します。これらはチェック可能な事実です。一方、タスクにどのツールが必要かは判断の問題であり、その判断はキーワードリストよりもモデルのほうが得意です。ハーネスが判断の問題でモデルを覆すと、静かに、分かりにくい形で失敗します。チェック可能なルールを強制する場合は、理由とともに明確に失敗します。

エージェントを構築していると、選択肢を削ってモデルを「助けたく」なるものです。まずは計測してください。ツール一覧が少し長くなってもコストは数トークンです。ツールが1つ欠けていれば、タスク全体を失いかねません。