自社ソフトに仕事を任せるAIエージェントを組み込む技術選定と費用の考え方

請求管理ソフトを開発・運用する会社が、顧客企業の経理担当者へAI機能を提供する場面を考えます。ここでは開発・運用する会社を「自社」、ソフトを操作する経理担当者を「利用者」と呼びます。「支払期限を過ぎた請求書を調べ、今月の確認用レポートを下書き保存して」と依頼できる機能を作るとします。

従来は利用者が検索条件を設定し、請求書を開き、入金の有無を確認して、集計表へ転記していました。AIに文章で質問できても、回答を読んだあとに利用者が画面を操作するなら、AIが受け持つのは調査や保存の一部にとどまります。

AIエージェントは、依頼と現在の状況を読み、使える操作を選び、その結果を見て次の行動を決めるプログラムです。請求書の検索で候補を見つけ、必要な明細を読み、不足があれば追加で調べ、レポートを保存するところまで進められます。

文章を読み、次の操作を判断するAIの中核がモデルです。操作をプログラムから呼び出す窓口がAPIで、モデルに選ばせる操作を「ツール」と呼びます。モデルが操作名と引数を返す仕組みがツール呼び出しです。たとえば「請求書を読む」というツールに請求書番号を渡せば、自社サーバーがデータを取得し、結果をモデルへ返します。モデル自身がデータベースを直接変更する構成にする必要はありません。

作りたい機能には、既存データを調べて更新するものと、ファイルやコードを作って実行するものがあります。請求管理ソフトの集計は、前者の例です。後者には、分析ソフトで利用者の依頼から集計用コードを作り、実行して結果を返す機能などが考えられます。どちらも自社ソフトの利用者へ提供する機能ですが、再利用する部品が変わります。

既存データを扱う機能では、自社ソフトのAPIを呼び、結果の確認を繰り返す実行ループを作ります。ファイルやコードを扱う機能では、Cursor、Codex、Claude Codeの実行系を組み込み用ライブラリから呼ぶ方法も候補になります。これらはファイルを読み、修正し、テストを実行して、失敗したら直す仕組みと作業環境を持っています。自社ソフトへ呼び出し口を追加すれば、その実行系を再利用できます。

請求管理ソフトの例では、対象期間の請求書を確認し、集計値が正しいと検査できるレポートの下書きを一件保存した状態を、成功一件と数えます。検索や回答だけで終わった依頼は、ここでの成功には含めません。AIが完成させる仕事と、その完成を何で確かめるかを決めると、部品と費用を比較する軸が定まります。次に、自社ソフトの操作を繰り返す実行ループをどう組み立てるかを見ます。

一回のモデル呼び出しで、検索ツールを実行して終える実装なら、検索結果に応じて明細を読み直す段階がありません。実行ループでは、ツールの結果を次のモデル呼び出しへ渡し、必要なら別の操作を選ばせます。単発のチャットにこの繰り返しを実装すれば、エージェントの基本構成になります。

進んだ工程や確認済みの情報は、途中状態として記録します。繰り返しを進める実行ループに、指示、ツール、途中状態、停止条件の管理を加えた実行系は「ハーネス」とも呼ばれます。これをサーバーなどで動かし、処理と状態を保つ土台が実行基盤です。フレームワークやSDKは、実行系を作るための部品、または組み込み済みの実行系を提供します。SDKはソフトへ取り込む開発用ライブラリのことです。

繰り返しを増やせば、費用も応答時間も増えます。計算や書式変換のようにコードで確実にできる部分は、まとめて一つのツールへ入れ、判断が必要な箇所へモデルを使います。工程がすべて決まっている処理は、固定した手順として実装する方が、実行回数を管理しやすくなります。

前節のループが、エラーを次の判断へ渡せるかを確かめます。筆者はAI SDK 7.0.122で、請求書から確認用レポートの下書きを保存する処理を動かしました。請求書は架空のローカルデータで、モデルの返答も固定した模擬モデルです。SDKを通してツールの結果が後続の呼び出しへ届く接続の試験であり、SDK間の性能や、実際のモデルの判断精度、応答速度、費用を比較する試験ではありません。

模擬モデルは、検索のあと、明細を確認する前に保存を要求するよう設定しました。保存ツールは「根拠が未確認」というエラーを返し、次に読むべき明細を示します。ループを続ける設定では、エラーが次のモデル呼び出しへ渡り、明細の確認、再度の保存、完了の応答まで進みました。

三回目のモデル入力に、二回目の保存要求で返された未確認エラーが含まれ、五回目のモデル入力に、四回目に保存した下書き番号が含まれることをコードで検査しました。進む操作は模擬モデルの台本どおりなので、ここで観測したのは判断力の向上ではなく、ツールの結果を次の呼び出しへ渡す接続です。

回数は、モデルへ入力を送り、一つの応答を受け取る処理を一回として数えています。六回は上限で、六回すべてを実行する指定ではありません。一回目は検索、二回目は未確認のまま保存を要求してエラー、三回目は明細確認、四回目は保存を要求して成功、五回目はツールを呼ばない完了の文章を返しました。新しいツール要求がなくなったため、上限に達する前の五回で停止しています。下書きが作られたのは四回目で、五回目にはその保存結果がモデルへ渡っています。

五回のループが終わったあと、追加の境界テストを行いました。保存処理に付けた重複防止用の依頼番号を使い、同じ保存要求を自社ツールへ再送しても、下書きは一件のままでした。また、ログイン中の会社に属さない請求書番号を指定した読み取り要求を、自社ツールが拒否することも確かめました。重複防止と会社の分離は、SDKに期待するだけでなく、自社ツールの側で検査できます。ただし、実サーバーの停止後に再開する試験や、データベースの同時書き込みは行っていません。今回確認したのはループの接続とローカルの操作条件です。

自社の検索、作成、更新をツールとして公開するなら、次の開発用ライブラリが候補です。表の「向く条件」は、公式機能をもとにした筆者の選定案で、性能順位ではありません。ライセンスと機能は2026年9月30日時点で確認しました。

JavaScriptやTypeScriptのWebアプリなら、AI SDKで少数の業務ツールを動かす構成が比較を始めやすいと考えます。すでにCloudflareで動く製品なら、Agents SDKの状態管理を利用する案も並べます。Pythonなら、入出力の検証を重視するPydantic AI、明示した工程の管理を重視するLangGraph、長い作業の文脈管理を重視するDeep Agentsを、必要な機能で絞れます。

AI SDKやLangGraph、OpenAI Agents SDKは、ソースコードを公開し、ライセンスの条件に従って利用や改変ができるオープンソースソフトウェア（OSS）です。ただし公開コードの利用料が不要でも、モデル推論、クラウド実行、保存、運用には費用がかかります。各社の有料ホスティングを契約することと、ライブラリを自社環境で使うことも、別の判断です。

文書やコードを生成し、ファイルを読み直し、実行して確かめる製品では、開発用エージェントの実行系を再利用できます。Cursor、Codex、Claude Codeには、それぞれプログラムから呼ぶ経路があります。自社ソフトは依頼を渡し、途中のイベントと成果物を受け取り、必要な業務ツールを追加します。

自社業務のツールを共通形式で接続する仕様がModel Context Protocol（MCP）です。Claude Agent SDKには、独自関数を同じプロセス内のMCPサーバーとして登録する方法があります。自社の関数を直接ツールとして登録できるSDKなら、最初から外部のMCPサーバーを運用する必要はありません。複数のエージェントへ同じ業務操作を提供するときに、共通接続の利点が出ます。

VercelのHarnessAgentは、既存エージェントを共通の呼び出し方で扱うための部品です。Claude Code、Codex、Cursor、Deep Agentsなどのアダプターがあり、画面やイベント処理を共通化する候補になります。ただし、アダプターによって、標準ツールの承認、ツール制限、出力形式の対応が異なります。同じ窓口に接続できることから、自社が必要とする機能も同じだとは判断できません。

公開コードとサービス条件も分けて確認します。Codexの公開リポジトリはApache-2.0で、Claude Agent SDKのPython側はMITですが、同梱・連携するClaude Codeやサービスの利用にはAnthropicの条件が適用されます。Cursorの公開された接続部品がMITでも、Cursor全体がOSSになるわけではありません。

実行環境の運用を提供者へ任せる選択肢には、AnthropicのClaude Managed Agentsもあります。Claude Agent SDKは自社が起動するプロセスで動かし、Managed AgentsはAnthropicが実行ループを運用します。自社で環境を運用する負担と、従量料金や対応する機能を比べて検討します。

認証と課金には二つの経路があります。Claude Pro／Max、ChatGPTのCodex利用枠、Cursor Proなどの既存契約へログインする経路では、各エージェントの契約者の利用枠を使います。ClaudeやOpenAIのAPIキーを使う経路では、そのAPI契約へ利用量が記録され、従量料金が発生します。自社のサーバーで推論を動かす場合は、どの契約で誰が費用を負担するかを先に決めます。

2026年9月14日にVercelが追加した機能は、Claude Code、Codex、Cursorなどへ保存されたログイン情報を、HarnessAgentから利用するためのものです。HarnessAgentから各エージェントの実行系へ直接接続する設定では、接続先サービスのAPIキーなどを環境変数で指定していれば、その認証を優先します。指定がなければ、HarnessAgentを動かすサーバーや開発用PCに保存された、接続先サービスの既存契約のログイン情報を使います。Vercelが提供するモデル接続の窓口AI Gatewayを経由する設定は、既存契約のログイン情報を読みません。

既存契約へログインする経路を技術的に使えても、その契約で顧客企業へサービスを提供できるかは、提供者の条件で決まります。特にClaudeの個人向け利用枠を自社製品へ転用する場合には、次の制約があります。

エージェントの仕事が長くなると、利用者が画面を閉じる、承認が翌日になる、サーバーが再起動する、といった中断が起こります。会話を保存するだけでは、どの処理が完了し、次に何を実行するかが決まりません。完了した処理と次に行う処理を記録する途中状態を保存し、再開時にそこから続ける実行基盤が必要になります。

Vercelでは、モデルとツールの実行ループをAI SDKのToolLoopAgentで作れます。長い処理にはWorkflowAgentを使います。WorkflowAgentは、Vercelのワークフロー用SDKが提供する保存・再開の基盤上で、エージェントのループを動かす部品です。生成したコードを隔離して実行する必要があれば、Sandboxを加えます。AI Gatewayはモデルへの接続と利用量管理をまとめる窓口です。すべてを一度に導入する必要はなく、自社APIを呼ぶだけなら、まずコード実行用のSandboxを省けます。

Cloudflareでは、利用者や案件ごとに状態と処理を持つDurable Objectsを、Agents SDKの土台にします。Thinkはその上で、会話の保存、ツールループ、応答の逐次表示などを扱います。エージェント内部の中断と回復にはfibers、独立した長い業務手順にはWorkflows、シェルやファイルの操作にはSandboxを使う構成です。fibersは途中情報を保存して回復処理へ渡す仕組みで、任意のJavaScript処理が自動で続行されると考えず、回復時の処理も実装します。

2026年9月18日のCloudflare Agents SDK 0.24.0には、再試行と安定したジョブIDを持つバックグラウンドキューが追加されています。長い仕事の実装に役立つ変更ですが、モデルが正しく判断する能力を直接高めるものとは区別します。

モデルが操作を選ぶ処理、業務ツールを呼ぶ実行ループ、途中状態を保存する処理は、それぞれ役割が異なります。次の図は、保存・再開の部品を組み合わせる設計例です。実行基盤が保存の部品を提供しても、回復時に何をするか、どの会社のデータへアクセスできるかは、自社のコードで決めます。

保存と再開を導入しても、自社データへの変更が一回だけ起きる保証は別に作ります。保存は成功したが、完了を記録する直前に停止した場合、再開時に同じ保存要求が届く可能性があります。自社APIでは同じ依頼番号への応答を保存して再利用し、同じ番号で内容が違う要求は拒否します。承認済みの内容、対象データの版、実行時の権限も再確認すれば、中断中に変わったデータへの誤更新を避けやすくなります。

SDKを変える前に、自社業務で失敗した場所を記録します。請求書の対象を間違える問題、明細を大量に読み込む問題、集計後の確認を忘れる問題では、直す部品が異なります。以下は、業務アプリ向けに試す改善案です。

モデルへの入力や出力の文章量は、文字や単語の断片を数える単位「トークン」で記録します。長い資料を何度も入力すると、この使用量が増えます。

たとえば「支払遅延を集計する」操作なら、ソフトにログインしている会社と操作する人の権限は自社サーバーで確定し、モデルには会社IDを自由入力させません。保存済みの対象を選ぶときは安定した番号を使い、集計はコードで計算します。文脈を減らす際も、入力資料を黙って切り捨てず、取得できた範囲と未取得の範囲を残します。自社ソフトへの特化は、こうした業務の意味と判定条件を実装するところから始められます。

大量の操作を一つずつモデルへ判断させる場合には、コードでまとめて呼ぶ方式も候補です。CloudflareのCode Modeは、モデルが必要なツールを探し、コードで複数の呼び出しを組み立てる仕組みです。ただし、生成コードの実行範囲を限定する必要があります。使う操作が少ない初期段階なら、明確な業務ツールを直接呼ぶ構成の方が比較条件を作りやすいと考えます。

部品を増やすことが、いつも成功率を上げるとは限りません。開発用エージェントの研究は、この前提を確かめる材料になります。2026年9月26日に公開された研究は、QwenとDeepSeek系の十モデルを、mini-SWE-agentとOpenCodeという二つの実行系で動かし、コード修正やリポジトリ制作など三種類の課題群を比較しました。さらに軽量の実行系NanoHarnessを作り、ツール、文脈の圧縮、計画、子エージェントなどを個別に試しています。

部品を追加しない最小構成と比べると、構造化したファイル操作のツールや、課題に特化した子エージェントは、リポジトリ制作課題の評価スコアを両モデルで高めました。たとえばQwen3.7-Maxでは、ツールの追加で4.57ポイント、課題専用の子エージェントで5.91ポイントの上昇です。一方、文脈の圧縮や汎用の子エージェントを単独で加えると、スコアが下がりました。ファイルを作ってテストする課題の結果なので、請求書の検索や保存で同じ差が出るとは限りません。自社でも追加機能を一つずつ変えて測る理由になります。

同年9月8日の研究は、コード修正や競技プログラミングの八十課題を各実行系で共通に使い、Claude Opus 4.8ではClaude Agent SDKとDeep Agents、GPT-5.5ではCodexの実行系とDeep Agentsの正解率を比べました。Claude Opus 4.8とGPT-5.5の両方で、比較した実行系間の平均正解率に明確な優位差は出ませんでした。また、課題の種類による差が報告され、Anthropic側では使用量記録の欠損により請求額の順位が確定していません。費用全体の優劣を決める材料としては、この欠損も考慮する必要があります。これも公開された研究稿です。実行系の評判で自社業務の完了率や費用を決めず、同じ業務条件で比較する必要があります。

エージェントの費用は、全工程のモデル入力と出力、外部ツール、実行環境、状態保存を合計します。入力の最初の一回だけで見積もると、各工程で読み直す会話、資料、操作結果が抜けます。モデルが生成する推論用トークンも、提供者の使用量と課金項目に従って数えます。

たとえば全呼び出しの合計が入力8万トークン、出力8千トークンなら、現行のClaude Sonnet 5.5の標準単価、入力100万あたり2ドル、出力100万あたり10ドルでは0.24ドルです。一万件で2,400ドルになります。これはキャッシュなしの仮定計算で、実測費用ではありません。外部ツール、クラウド実行、失敗後のやり直し、税や為替も含めていません。

同じ入力の繰り返しにはキャッシュが候補です。Sonnet 5.5のキャッシュ読み取りは100万トークンあたり0.20ドルですが、最初の保存には通常入力より高い単価がかかります。利用間隔や対象の変化を見て、実際の使用量から効果を確認します。長い会話の全文を毎回送ることを、安い入力単価だけで正当化しない方がよいでしょう。

実行基盤にも、課金対象の違いがあります。次の表には、実行環境や保存基盤の料金に加え、Claude Managed Agentsの実行料金も載せます。

表のサービスは役割が違うため、単価の小ささだけで横並びの順位を付けられません。自社APIだけを呼ぶ仕事に毎回Sandboxを作る必要があるか、待機中の接続を維持する必要があるか、失敗時に最初から推論をやり直しているかを調べる方が、改善箇所を特定できます。

比較する指標は「全試行の費用÷正しく完了した仕事の数」です。仮に百件の依頼に一件平均0.10ドルを使い、五十件が完成すれば、成功一件あたり0.20ドルです。同じ百件を別の構成で処理し、一件平均0.15ドルで九十件が完成すれば約0.167ドルになります。安い呼び出しが、安く完成する仕事になるとは限りません。有人の修正費は、モデル費用と分けて記録し、運用判断では合計します。

ここからは筆者の提案です。最初の機能は、利用者が完成を確認できる一業務へ絞ります。請求書の集計なら、対象期間の指定から確認用レポートの下書き保存までを一つの仕事にします。送信や削除を追加する段階では、利用者が対象と変更内容を画面で確かめる場所を作ります。

現時点での採用案は次のとおりです。

評価には、正常な依頼に加え、名前が重複する、資料が足りない、古いデータがある、権限がない、途中で操作に失敗する、といったケースを入れます。最初の比較用に三十件の実業務を選び、モデルとデータを固定したまま実行系やツールを変える案を提案します。次に、同じ実行系でモデルを変えます。件数は導入可否を保証する基準ではなく、改善の原因を追うための出発点です。

下書きだけを作る小さな機能でも、利用者の依頼から成果物の保存までを通して測れば、完了率と成功一件あたりの費用が分かります。ツールの修正で改善するのか、文脈管理や保存・再開が必要なのかを確かめてから機能を広げると、次に採用する部品と費用の上限を決められます。