ほぼ完璧な100段階でも失敗する理由

100段階の操作があるブラウザー作業を例として考えます。各段階がほかの段階とは独立に99％の確率で成功すると仮定しましょう。すべてが成功する確率は 0.99^100、約36.6％です。

99％は非常に高く聞こえます。しかし36％はそうではありません。

ブラウザーで一連の処理を完了する作業を扱う議論 は、この計算から限定的な論点を示します。顧客が価値を得るのは作業が完了したときですが、費用と失敗の可能性は各段階で積み重なります。これは仮定に基づく算術であり、特定のブラウザーエージェントや Tajo の同期について公表された成功率ではありません。実際のエラーには相関もあります。ログインが一度失効すれば、その後の複数の操作がまとめて失敗し得ます。

したがって、問うべきことは「モデルの最後のクリックはどれほど正確だったか」ではありません。「利用者が求めた状態は実現したか」です。

重要な単位は一連の処理全体

エージェントが保険ポータルを開き、書類を探してダウンロードし、正しいアカウントの書類か確認する場面を想像してください。99画面を正しく進んでも、100画面目で別のファイルを取得すれば失敗です。成功したクリックが並ぶログは、その結果を直しません。

連携でも区別は同じです。エージェントは API を発見し、フィールドの対応付けを提案し、下書きを保存できます。しかし、そのどれも送信先の連絡先が意図した同意状態になったことを意味しません。承認された操作が実行され、関連する事後条件が確認されて初めて作業は完了します。

これは活動と完了の違いです。活動を数えるのは簡単ですが、完了には定義が必要です。

ファイルの取得なら、依頼と一致するアカウント番号を持つ成果物かもしれません。連絡先の同期なら、正しい識別子、フィールド、許可されたメッセージ送信状態を備えた送信先レコードでしょう。確認すべきなのは利用者が気にかけた対象です。直前の呼び出しに対する正常応答は、呼び出しが戻った証拠にはなります。送信先が意図どおり変わった証拠とは限りません。

Tajo の業務ツール連携ガイドは、ワークフローと各データの正本から考えます。この選択によって最終確認の意味が決まります。二つのシステムが同じフィールドの所有者を主張していれば、書き込みが完璧でも長期的には誤った状態になり得ます。

判断を一つ増やす費用

同じ仮想的な99％という前提なら、独立した判断が10回で全体の成功率は約90.4％、50回で約60.5％、100回で約36.6％です。

全段階の成功確率（％）

独立した段階の数

• 各段階の成功率を99％と仮定

計算値を確認

各段階の成功率が99％で互いに独立し、再試行しないと仮定して計算した全段階の成功確率。エージェントの実測性能ではなく数学的な例です。

段階数	全段階の成功率（％）
0	100.0
10	90.4
25	77.8
50	60.5
75	47.1
100	36.6

曲線が急なのは、掛け算では高い平均値も救済されないからです。判断を一つ増やすたびに、その必要性を示さなければなりません。

だからといって、すべての API 呼び出しを巨大な操作一つにまとめるべきではありません。既知のカーソルでページを取得する、識別子を比較する、承認済みの対応付けに従ってフィールドを書き込むといった呼び出しは決定論的な処理です。レコードごとにモデルが判断し直す必要はありません。一方、新しい提供元のフィールド、変化したエラー文、責任者が不明な依頼には実際の曖昧さがあり、判断を要する場合があります。

実務上は、判断でルールを設計または修復し、安定したルールの適用は通常のコードに任せます。リバース ETL はデータ移動の反復例です。日常的な各行の処理は会話ではなくパイプラインが実行すべきです。エージェントは、そのパイプラインの振る舞いを決める手助けができます。

これは境界であって標語ではありません。提供元がフィールドの意味を変えれば、決定論的なルールは誤った動作を完璧に繰り返します。前提の変化を検知し、その事例を再検討に戻す仕組みが必要です。

大きなツール一つでは解決しない理由

「長い連鎖が失敗するなら、作業全体をツール呼び出し一つにすればよい」という反論はもっともです。結果を確認できる、明確な一連の処理としてツールを定義できるなら有効です。しかし、長く不確かな過程を単に隠すだけなら失敗します。

たとえば syncCustomer() が更新を送った直後に success: true を返すとします。送信先が後から更新を処理するなら、その時点では最終的な連絡先の状態を証明できません。見える段階は減っても、不確実さは減っていません。

よりよいインターフェースは重要な状態を示します。受理、適用、確認、失敗です。それぞれの言葉には証拠が対応しているべきです。影響の小さいプレビューなら、書き込みの受理だけで十分な場合があります。キャンペーンの対象者や同意の変更なら、完了と呼ぶ前に送信先を確認すべきです。

このTajoの提案図では、リクエストの受け付けと更新の適用を、送り先の検証と区別します。最後の確認は保留中です。次に行うことは明確です。送り先に保存された内容を調べます。成功したツール呼び出しをもう一つ数えても、元の問いには答えられません。

Tajoコンセプト図 · サンプルデータ

書き込みが終わっても証拠は必要です

顧客の同期は完了しましたか？

Tajo MCPアプリアクティビティ

書き込みを適用しました。検証は保留中です。

送り先の状態はまだ確認していません。

同期アクティビティ

1. リクエストを受け付けました
2. 更新を適用しました
3. 送り先の確認は保留中です

実行例 · 14:32 UTC

分かっていること

提供元の応答

受け付け済み

書き込み結果

適用済み

送り先からの再読み取り

保留中

元のイベントを見る

呼び出しの成功だけでは最終状態を証明できません。

提案する証拠表示

アクティビティを確認

Tajoのアクティビティ履歴を参考にした提案図です。検証状態を加えていますが、送り先からの再読み取りが実装済みという意味ではありません。

測定方法も変わります。試行回数は費用の診断に役立つなら記録します。途中のエラーは壊れた段階を特定できるなら記録します。しかしワークフローの評価は、確認方法を数値に添えた、検証済みの完了件数で行います。「呼び出しの99％が成功した」という報告では、顧客の仕事が終わったか分かりません。

MCP サーバーの解説は、ツールを通じてアシスタントが別のシステムを呼び出す方法を示します。ツールへのアクセスは始まりにすぎません。契約で問われるのは、その後に残る状態です。

100回の正しいクリックでも、成果が何も残らないことがあります。数えるべきは結果です。