Claude CodeからREAへ：AI Agentは「コードを書く」から「ソフトウェアを操作する」へ

MCPのツール注釈には、操作が読み取り専用かを示す readOnlyHint があります。この情報はツール選択時の手掛かりになりますが、安全性を保証するものではありません。ツール注釈の説明が示すように、操作の種類を伝える設計と実際の権限管理は分けて考える必要があります。

結論は、Claude CodeからREAへの流れを「コードを書くAgentの置き換え」ではなく、「ソフトウェア上の作業まで実行対象を広げる動き」と捉えることです。操作対象の状態を確認でき、権限と失敗時の復旧方法を定められる仕事から試してください。

Claude CodeなどのコーディングAgentを使い、次の能力範囲を見極めたい開発者向けです。
業務ソフトやデスクトップアプリの自動化を評価するチームにも役立ちます。
実行環境、権限、結果検証を設計する技術責任者は、導入判断の条件を確認できます。

AI Agentの変化は「出力」より実行場所にあります

コーディングAgentの中心的な仕事は、リポジトリを読み、コードを作成・変更し、コマンドやテストで確認することです。一方、ソフトウェア操作型Agentは、画面やツールから現在の状態を読み取り、操作を選び、実行後に結果を確かめる流れを扱います。

違いは、最終出力がコードか画面操作かだけではありません。画面遷移、ログイン状態、データ更新、権限など、ソフトウェアの状態に応じた実行と確認が必要になります。つまり、AI Agentの対象業務が広がる一方で、実行環境と安全策への依存も大きくなります。

Claude Codeが担うコード中心の作業範囲

Claude Codeは、コードベースを参照しながらファイルの確認や編集、コマンド実行を行うコーディング支援ツールです。具体的な利用方法はClaude CodeのCLI使用ガイドで確認できます。機能は同ツールの仕様として捉え、すべてのAI Agentに共通する能力だと一般化しないでください。

たとえば不具合修正では、関連ファイルを探し、変更を加え、テストコマンドを実行して結果を読む、という手順を組めます。ただし、テストが通ることは、業務アプリ上で期待どおりの操作が完了したことと同じではありません。実装の妥当性と、画面上の業務結果は別々に検証する必要があります。

権限を広く与えれば作業が進みやすくなる反面、意図しないコマンドや変更を許す可能性も高まります。Claude Codeの権限設定に関する公式説明を読み、許可する操作と人の確認を要する操作を分けてください。

REAとソフトウェア操作型Agentの位置づけ

REAは、ここではREAプロジェクトの公開説明に記載されたプロジェクトを指します。提供されている参照情報だけで略称の正式な展開や、すべての環境で再現できる機能範囲を断定するのは避けます。REAを一般的なAgentの標準名と見なしたり、特定のデモを安定した本番能力と同一視したりしないことが重要です。

ソフトウェア操作型Agentの考え方は、状態を読む、実行可能な操作を選ぶ、操作を行う、結果を確認する、という循環です。実際にどの画面やツールを扱えるか、どのような環境が必要かは、プロジェクトの説明とREAのインストール手順で個別に確認してください。インストールできることだけでは、業務の完了率や障害時の復旧能力までは分かりません。

ツールが「読み取り専用」と自己申告する注釈は、判断材料であってアクセス制御ではありません。更新や削除を伴う操作は、実行権限と承認手順を別途設計してください。

同じ業務をコード変更と画面操作で比べる

たとえば「顧客管理ツールの入力ミスを直し、修正内容を確認する」仕事を考えます。データを扱うコードの修正なら、コーディングAgentは関連処理を変更してテストを実行できます。画面上のレコードを直すなら、操作型Agentには対象の特定、入力欄の更新、保存後の状態確認が求められます。

後者では、似た名前のレコードを選ぶ、保存に失敗する、画面表示が古いまま残るといった問題を想定しなければなりません。操作の実演が成功しても、条件の異なるデータや画面変更後に同じ結果になるとは限りません。対象を一意に特定できるか、処理後の状態を独立して確かめられるかが、実運用への移行条件です。

AI Agentに任せやすい業務と失敗しやすい境界

向いているのは、手順が決まっており、対象データを見分けやすく、完了状態を確認できる作業です。たとえば定型項目の転記や、決まった画面から情報を取得して報告する処理は、操作ログと結果を照合できるなら候補になります。

反対に、画面構成が頻繁に変わる業務、曖昧な判断を要する承認、取り消しにくい送金・削除・公開などは、無条件に任せるべきではありません。ログイン情報や個人情報に触れる場合は、最小権限、操作記録、停止手順、人による承認を先に用意します。エラー時に同じ操作を繰り返すと二重登録になる処理では、再実行の条件も明文化してください。

導入判断に使う条件分岐と実行環境

まず、次の条件に照らして実行方式を選びます。

• コードの変更が中心で、テストや差分で結果を確かめられるなら、Claude CodeのようなコーディングAgentを候補にします。
• 業務ソフトの画面操作が中心で、対象を明確に特定でき、操作後の状態も確認できるなら、ソフトウェア操作型Agentを小さな範囲で試します。
• 重要データの更新を伴い、誤操作の影響が大きいのに復旧・承認手順がないなら、自動実行は保留し、人の確認を挟みます。
• 再現に特定のOSやデスクトップ環境が必要なら、開発端末だけで評価せず、本番に近い実行環境で権限と失敗時の挙動を確かめます。

REAの公開手順からは導入前に環境要件を確認できますが、それだけで自分の業務に適合するとは判断できません。評価では、対象アプリ、ログイン方法、許可する操作、成功判定、失敗時の停止・復旧方法を記録してください。Mac上の開発や検証環境を検討する場合は、Mac環境の利用案内で利用条件を確認し、実際のワークフローに必要な環境と照合します。

最初から全面自動化する必要はありません。読み取り専用の処理で状態把握を試し、結果を照合できた後に、取り消し可能な更新へ進む方法が安全です。操作対象の変更が大きい場合や、物理機器への接続が必要な場合は、リモート環境より手元の専用端末が適することもあります。

既存の開発端末だけで進めると、実行中の作業との競合や環境差が検証を妨げることがあります。一方で、常時稼働する重い処理や物理接続が前提なら、レンタル環境が最適とは限りません。独立したMac環境で短期検証したい場合は、KvmzenのMac利用情報を確認し、必要なソフトウェア、権限、結果確認の方法が合うかを見てから選んでください。最終判断は「何を操作するか」「どの権限を与えるか」「どの環境で動かすか」「何をもって成功とするか」の順に行うと、コード生成とソフトウェア操作の境界を実務に沿って引けます。