「Claude Codeに加えて、CodexやCursorも業務で使いたい」「でも、ツールごとに画面も権限の確認方法も費用の見え方も違い、管理しきれない」。AIエージェントを業務で使い始めた企業から、こうした相談を受けることが増えました。
AIエージェントとは、指示を受けて、ファイルの編集やコマンドの実行まで自分で進めるAIのことです。各社から次々と新しい製品が出ています。1つのツールだけに絞ると、値上げや性能の変化に対応しにくくなります。一方で、複数のツールをばらばらに使うと、どの操作を誰が許可したのか、費用がいくらかかったのかを追えなくなります。
この記事では、複数のAIエージェントを1つの社内システムの中で切り替えて使うための設計の考え方と、実際に運用して見つかった問題と対策を紹介します。
題材は、当社アストラルコードが社内で運用している「AI社員」のシステムです。AI社員とは、調査や開発などの仕事を受け持つAIエージェントのことです。ファイルの書き込みやコマンドの実行の前には確認画面を出し、人が承認してから実行するようにしています。当社ではこのAI社員を動かすツールを、Claude Code・Codex CLI・Cursor CLIの3つから選べるように改修しました。方式の検討を始めてから約10時間で、3つのツールが本番環境で使えるようになっています。その過程で実際に起きたことを、具体的に書いていきます。
複数のAIエージェントを使い分けるときに問題になる3つの違い
複数のAIエージェントを1つのシステムで扱うときは、ツールごとの内部のしくみの違いが問題になります。特に、出力の形式、安全のための確認のしくみ、費用やログインの扱いの3点が大きく異なります。ここを把握しないまま統合を始めると、一部の機能がエラーも出さずに動かなくなります。
出力の形式がツールごとに違う
各ツールの出力は形式が違うため、そのままでは同じ画面に表示できません。
AIエージェントは、作業の途中経過（どのファイルを読んだか、どのコマンドを実行したか、何と返答したか）を外部に出力します。この出力の形式が、製品ごとに独自に決められています。たとえばClaude Codeには、途中経過を1行に1件ずつJSON形式で出す「stream-json」という出力方式があります。当社のシステムは、もともとこの形式を読み取って、AI社員が今何をしているかを画面に表示していました。
しかし、CodexやCursorはこの形式では出力しません。同じ「ファイルを読んだ」という出来事でも、データの構造が違います。そのため、当初は「CodexやCursorの出力をClaude Codeの形式に変換すれば、すべての機能が動くのではないか」と考えました。
出力の形式をそろえることは必要です。ただし、次に説明するとおり、出力をそろえるだけでは足りませんでした。
安全のための確認のしくみが根本的に違う
3つの違いの中で最も重要なのが、安全のための確認のしくみの違いです。ツールによって、何をどの単位で止めるかの考え方がまったく異なります。
当社で使った3つのツールを比べると、次のようになります。
- Claude Code：ファイルの書き込みやコマンドの実行など、操作の1つずつに対して事前に確認を入れられます。当社ではこの機能（フック）を使い、操作の前に確認画面を出しています。
- Codex CLI：操作ごとの確認の機能はありません。書き込めるフォルダを制限する「サンドボックス」という機能だけで安全を守ります。最も厳しい設定にしても、作業フォルダの中であれば確認なしで書き込めます。
- Cursor CLI：シェルで実行するコマンドを、中身を区別せずにすべて「Bash」という1つの種類として扱います。そのため、コマンドの内容に応じて許可・不許可を細かく分けることができません。
つまり、Claude Codeで設定した許可のルールを、そのままCodexやCursorに当てはめることはできません。ツールごとに、同じ水準の安全性をどう確保するかを個別に設計する必要があります。業務でAIエージェントを使う以上、ここを曖昧にしたままツールを切り替えられるようにするのは危険です。
費用・ログイン・会話の続きの扱いも違う
3つ目の違いは、運用管理に必要な情報の扱いです。費用、ログイン状態、会話の続きから作業を再開する方法が、ツールごとに異なります。
当社で影響範囲を調べたところ、次のような違いがありました。
- 1回の実行にかかった費用（金額）を返すのはClaude Codeだけで、Codexは費用を返しません。Cursorは、使用したトークン量（AIが処理した文字量の単位）も返しません。
- 前回の会話の続きから作業を再開する方法が、ツールごとに違います。
- ログインの期限が切れていても、はっきりしたエラーが表示されず、AI社員の作業が失敗したまま気づかないケースがありました。実際に、Cursorはログインが半年以上前に切れたままになっていました。
こうした違いを放置すると、費用の集計がずっと0円のままになったり、AI社員が作業に失敗していることに誰も気づかなかったりします。複数のAIエージェントを使い分けるときは、出力の形式だけでなく、安全のための確認と運用管理の情報まで含めて、違いを吸収する設計が必要です。
共通規格ACPで受け取り、変換部分だけを自作する設計
当社が採用したのは、各ツールが対応している共通の通信規格「ACP」で出力を受け取り、社内システムで使う形式に変換する部分だけを自作する方法です。自作する範囲を小さくすることで短期間で実装でき、将来ほかのツールを追加するときの作業も少なくできます。
3つの方式を比較し、ACPで直接つなぐ方式を選んだ
当社は、各ツールに用意されているACP用の部品を使い、ACPで受け取った出力を社内の形式に変換する方式を選びました。ACP（Agent Client Protocol）とは、アプリとAIエージェントのあいだでやり取りするための通信規格です。Claude・Codex・Cursorには、それぞれACPで通信するための部品が用意されています。
比較した方式は次の3つです。
- A．出力を変換するスクリプトを自作する：CodexやCursorの出力を、Claude Codeのstream-json形式に変換するスクリプトを作る方式です。
- B．Vercel AI SDK Harnessesを使う：複数のAIエージェントを同じ書き方で動かせるライブラリを使い、その出力を社内の形式に変換する方式です。
- C．ACPで直接つなぐ：各ツールのACP用部品（claude-agent-acp、codex-acp、Cursorのagent acp）を使い、ACPで受け取った出力を社内の形式に変換する方式です。
Aを選ばなかったのは、出力の形式をそろえても、ほかの機能はそろわないためです。会話の続きからの再開、操作前の確認、AI社員ごとに使えるツールの制限、費用の集計、障害時に別のAIモデルへ切り替える処理、外部サービスとの連携設定などは、ツールごとに別々の実装が必要です。出力だけを変換すると、画面には表示されても、裏側の機能が動かない状態になります。
Bを選ばなかったのは、このライブラリがまだ試験的な段階で、今後の更新で使い方が大きく変わる可能性があったためです。また、外部から切り離した環境で動かすことを前提にしており、手元のフォルダを直接操作する当社の使い方に合いませんでした。さらに、Cursor向けの部分では、操作ごとの承認の機能が十分でないことも分かりました。
Cであれば、各社が自社のツールに合わせて用意した部品をそのまま使えます。自作するのは、ACPから社内の形式への変換と、ツールの起動・操作前の確認の処理だけです。各社の部品に任せる部分と、自社で管理する部分の区別がはっきりするため、ツールが更新されたときの影響も把握しやすくなります。
作り替える前に、今の動きを文書とテストで決めておいた
実装に入る前に、今のシステムがどう動いているかを文書とテストにまとめました。既存の機能を壊さずに作り替えるには、この準備が欠かせません。
当社のシステムには、画面表示、操作前の確認、費用の集計、障害時の自動対応など、日々の運用に必要な機能がすでに多く入っていました。影響範囲を4つの観点に分けて調べたところ、確認画面が二重に表示される問題、会話の続きかどうかの判定、費用の集計、障害時の自動対応、安全に再起動してよいかの判定などが、変更によって壊れやすいと分かりました。さらに、障害対応・別モデルへの切り替え・作業の再開・操作前の確認の4つには、自動テストが1件もありませんでした。
そこで、次の順番で準備を進めました。
- 今の機能を要件の文書にまとめる：最初に作った文書は、関数名や行番号まで含めた14本・合計392項目の細かいものでした。しかし、これではコードを書かない人には読めません。細かい内容は詳細設計の文書に移し、要件の文書には「システムがどう振る舞うか」だけを、1本40行ほどで書き直しました。
- 今の動きを確認するテストを44件作る：36件は成功し、残りの8件は既知の不具合として記録しました。不具合の修正は後回しにし、まずは作り替えの前後で動きが変わっていないことを確認できる状態を作りました。
- 作業を53件のタスクに分ける：1タスクを1ファイルにまとめ、事前に決めておく必要がある方針を6つ整理して、合意を取ってから着手しました。
- 中心の処理を分割する：AI社員を起動する中心の関数は約740行ありました。これを「起動の部分」と「どのツールでも共通の部分」に分け、外から見た動きが変わっていないことをコードレビューで確認しました。
AIエージェントを使った開発は進みが速い分、変更の前に正しい動きを決めておかないと、不具合も同じ速さで増えてしまいます。今の動きを先に文書とテストで固めておいたことが、短期間で本番投入できた理由の1つです。
Claude→Codex→Cursorの順に1つずつ切り替えた
3つのツールは一度に切り替えず、Claude、Codex、Cursorの順に1つずつ追加しました。順番に進めることで、問題が起きたときに原因を見つけやすくなります。
最初は、これまでと同じClaudeを、ACP経由で動かすことから始めました。AIは同じで通信の経路だけを変えたので、問題が出れば、原因は新しく作った変換処理か起動の処理にあると判断できます。この段階では、試運転用のAI社員を1人用意し、そのAI社員で動作を確認してから本番に反映しました。
次にCodexを、最後にCursorを同じ変換処理に追加しました。試運転用のAI社員は、Claude（ACP経由）、Codex、Cursorの順にツールを切り替えながら動作を確認しています。
また、すべての処理を切り替えの対象にはしませんでした。AI社員どうしの会議のように、短い発言が何度も続く処理は、Claudeのまま残しています。CodexやCursorは、起動のたびにログイン確認などで数秒かかるため、短い発言を繰り返す処理には向かないからです。複数のツールを使い分ける仕組みを作るときは、どこまでを切り替えの対象にするかを決めておくことも大切です。
本番投入までに見つかった問題と対策
複数のAIエージェントを1つのシステムで動かすと、ツールを単体で使っているときには起きない問題が出てきます。当社では各段階でコードレビューとセキュリティの観点でのレビューを行い、本番投入までに複数の問題を見つけて修正しました。ここでは、同じようなシステムを作る企業にも当てはまりやすいものを紹介します。
確認を止める範囲が想定より広く、確認なしで動けてしまう問題
1つ目は、確認の一部を止める設計にしたところ、想定よりも広い範囲で確認がされなくなっていた問題です。安全のための確認を変更するときは、その影響がどこまで及ぶかを必ず確認する必要があります。
当初は、ACP経由で動かしているあいだは当社独自の確認を止め、ACP側の確認だけを使う予定でした。同じ操作に対して確認画面が2回出るのを避けるためです。しかしレビューで、確認を止める範囲が、ACPから起動されたすべてのプログラムに及ぶことが分かりました。たとえばAI社員がコマンドを使ってもう1つClaudeを起動すると、その2つ目のClaudeは確認なしで操作できてしまいます。
そこで、ACP経由でも従来どおり当社独自の確認を行い、ACP側の確認もあわせて残す形に変更しました。確認の手間が少し増えるよりも、確認が漏れる危険のほうが大きいと判断したためです。
「常に許可」を押すと、その後のすべての操作が確認なしで通る問題
2つ目は、確認画面で一度「常に許可」を押すと、その後の操作がすべて確認なしで実行されてしまう不具合です。
Codexを追加する段階で、確認画面の「常に許可」を押すと、Codexの操作が種類を問わず許可済みとして記録され、以後は確認が出なくなることが分かりました。「この種類の操作は毎回許可してよい」という意味で押したつもりでも、実際にはCodexのすべての操作が対象になっていたのです。
この不具合はすぐに修正しました。あわせて、Codexには操作ごとの確認の機能がないことを踏まえ、読み取り専用の設定で動かすようにしました。そのうえで、もともとファイルの書き込みとコマンドの実行を許可されているAI社員だけが、Codexを選べるようにしています。ツール自体の確認の機能が弱い場合は、そのツールを使えるAI社員を限定することで安全性を確保しました。
AIが許可設定のファイルを書き換えられてしまう問題
3つ目は、AIエージェントが、自分の操作を制限している許可設定のファイルを書き換えられる状態になっていた問題です。許可設定のファイルが、AIが書き込めるフォルダの中に置かれていると起こります。
Codexでは、作業フォルダの中に、当社独自の確認の設定ファイルが入っていました。Codexは作業フォルダの中なら確認なしで書き込めるため、この設定ファイルも書き換えられてしまいます。そこで、Claudeで動くAI社員を起動する前に毎回この設定ファイルを確認し、変更されていれば元に戻すようにしました。
Cursorでは、さらに影響の大きい問題が見つかりました。Cursorの許可設定のファイルは、すべてのAI社員が共有するフォルダに置かれていました。そのため、1人のAI社員がこのファイルを書き換えると、Cursorで動くすべてのAI社員が、以後ずっと確認なしで操作できる状態になってしまいます。これは、実行のたびに許可の設定を初期値に戻すことで解決しました。
AIエージェントに作業を任せる以上、AIが設定ファイルを書き換えない前提で設計することはできません。設定ファイルは実行のたびに正しい内容に戻す、という方法で守る必要があります。
ログイン切れで、AI社員の作業が失敗していることに気づけない問題
4つ目は、ログインの期限が切れても画面に表示されず、AI社員の作業が失敗していることに気づけなかった問題です。複数のツールを使うと、ログインを管理しなければならないツールも増えます。
Cursorのログイン切れでAI社員の作業が失敗していたことをきっかけに、ツールごとのログイン状態を画面に表示する機能を作りました。ここでもレビューで問題が1つ見つかりました。最初の実装では、AI社員の返答に「unauthorized（認証されていない）」などの言葉が含まれているだけで、ログイン切れと表示していました。そのため、AI社員が認証エラーについて説明しているだけでも、誤ってログイン切れと表示されてしまいます。
そこで判定には、AIの返答の文章を使わず、ツールのプログラム自体が返すエラーだけを使うように変更しました。現在は、Claude・Codex・Cursorのログイン状態と、Cursorのログインの有効期限を画面で確認できます。
解決していない課題も記録し、運用で対応する
最後に、すべての問題が解決したわけではない点も書いておきます。解決できていない課題を把握し、運用のルールで対応することも必要です。
当社では、AI社員が指定されたリポジトリ以外のファイルに書き込めないようにする制限も入れています。しかし、この制限が確実に効くのは、Claudeのファイル編集機能で書き込んだ場合だけです。コマンドを使って書き込んだ場合や、CodexやCursorで動かした場合は、この制限では止められません。
対策として、コマンドの実行そのものをOSの機能で制限するツールを導入することと、書き込み先を厳しく制限する必要があるプロジェクトではCodexやCursorを使わずClaudeで動かすことの2つを組み合わせる方針にしました。また、Cursorは使用量を返さないため、実行記録の画面では使用量が0と表示されるといった既知の制約も、記録として残しています。
複数のAIエージェントを使い分けるうえで大切なのは、すべてのツールを同じように扱えると考えないことです。ツールごとにできること・できないことを把握し、システムで対応できない部分は運用のルールで補えば、安全性を保ったまま使い分けを続けられます。
まとめ
Claude Code・Codex・Cursorなど、複数のAIエージェントを1つの社内システムで使い分けるときのポイントを振り返ります。
- ツールごとに、出力の形式、安全のための確認のしくみ、費用・ログイン・会話の続きの扱いが違う。出力の形式だけをそろえても、ほかの機能はそろわない
- 共通規格ACPで出力を受け取り、社内の形式に変換する部分だけを自作すると、自作の範囲を小さくでき、ツールの追加もしやすい
- 作り替える前に、今の動きを要件の文書とテストで決めておく
- ツールは一度に切り替えず、1つずつ追加する。切り替える必要のない処理は対象から外す
- 確認の範囲、「常に許可」の対象、許可設定ファイルの書き換えなど、複数のツールを組み合わせたときに起きる問題を必ずレビューで確認する
- ログイン状態や既知の制約を画面や記録で確認できるようにし、システムで対応できない部分は運用のルールで補う
AIエージェントの選択肢は今後も増えていきます。特定のツールに頼りきらず、安全に使い分けられる社内システムを持っておくことは、AI活用を長く続けるうえで大きな強みになります。
アストラルコードでは、今回紹介したような社内のAIエージェントの仕組みづくりや、既存業務へのAIエージェントの導入を、要件定義から設計・実装・運用まで支援しています。「複数のAIツールを導入したが管理が追いつかない」「安全性を保ったままAIに作業を任せたい」とお考えの方は、お気軽にご相談ください。
