Sapan Pandya氏、シニアソフトウェアエンジニア兼IEEEシニア会員―インタビューシリーズ

Sapan Pandya氏は、ニュージャージー州を拠点とするシニアソフトウェアエンジニアであり、IEEEシニア会員でもあります。堅牢な分散トランザクションシステムにおいて10年以上の経験を有しています。取り組んできた領域は、トランザクションの完全性、ソフトウェアと物理デバイスの連携、本番環境でのトラブルシューティング、規制環境におけるデプロイの検証など多岐にわたります。Stevens Institute of Technologyでコンピューターサイエンスの修士号を取得し、学術的な査読や技術研究にも携わっています。

Pandya氏の研究テーマは、キオスクのサイバーセキュリティ、エッジAI、AIを活用した信頼性エンジニアリングです。また、本番環境での経験を踏まえ、根拠、トランザクションの結果、運用上の説明責任を重視しています。このインタビューでは、冪等性、食い違うトランザクション記録、復旧システムにおける不確実性、そしてAIエージェントがミッションクリティカルなインフラに対応する前に必要となる制御について語ります。実務でのエンジニアリング経験と、文献分析や管理されたテストまたは合成データを用いたテストに基づく研究とを区別しています。

これまで、ソフトウェアの信頼性と分散トランザクションシステムに携わってこられました。そうした経験は、信頼性に対する考え方にどのような影響を与えましたか。また、複雑なシステムの管理にAIを活用することについて、どのような課題がご自身の見方を形作ってきましたか。

私の視点は、「コンポーネントが動作するか」ではなく、「顧客のトランザクションが完了し、その経緯を確認できるか」を問う方向へと変わりました。

キャリアの初期には、アプリケーションの挙動に多くの注意を払っていました。入力を検証し、応答を処理し、インターフェースが想定されたワークフローに従うようにすることが中心でした。その後、システム統合、本番環境でのトラブルシューティング、デプロイの検証へと責任範囲が広がり、個々のコンポーネントだけでなく、システム全体を見る必要が出てきました。

あるサービスの処理が完了していても、別のサービスは確認を待っていることがあります。ソフトウェア上では操作が成功したと記録されていても、物理デバイスが期待どおりの結果を提供できない場合があります。各コンポーネントのテストに合格しただけでは、システム全体のやり取りが正しく動作するとは限りません。

こうした経験から、システム間の境界に特に関心を持つようになりました。各コンポーネントは何を把握しているのか。何を前提としているのか。その前提が成り立たなくなったとき、何が起きるのか。

AIに対する考え方にも、こうした経験が影響しています。エンジニアが根拠を集め、パターンを認識し、障害をより迅速に調査するうえで、AIには大きな価値があります。しかし、何が起きた可能性が高いかを説明することと、実際に何が起きたのかを検証済みの記録として示すことは別です。

問題の調査にかかる労力をAIで減らしつつ、解決に必要な根拠の基準は下げないようにしたいと考えています。

技術的に正しいコードでも、トランザクションが必ず正しい結果になるとは限らないと、これまで強調されてきました。タイムアウトによって失敗したように見えても、実際には完了しているトランザクションの具体例を説明していただけますか。システムが操作を自動で再試行すると、どのような問題が起こり得るでしょうか。また、エンジニアは二重処理をどう防ぐべきですか。

仮に50ドルの支払いを考えてみましょう。アプリケーションがリクエストを送信し、決済サービスは正常に処理を記録しますが、その応答はアプリケーションに届く前に失われます。

支払いがすでに完了しているにもかかわらず、顧客にはタイムアウトが表示されます。アプリケーションが新たな支払いリクエストを送信すると、顧客に再度請求してしまう可能性があります。

タイムアウトから分かるのは、応答が期限内に届かなかったということです。元のトランザクションが成功したかどうかまでは分かりません。

一般的な対策の一つが冪等性です。同じ論理リクエストを繰り返しても、金銭的な処理が重複しないようにします。アプリケーションは再試行の際も同じ操作識別子を保持し、受信側のサービスはそれを新しい購入ではなく、元のリクエストとして認識します。

重要なのは、単に識別子を付けることではありません。サービス側でその識別子を確実に適用し、処理が完了したのか、まだ進行中なのかを区別できるだけの情報を保持する必要があります。識別子を無視する後続処理は、その識別子によって保護できません。

結果が不確かなままの場合、復旧処理では代わりのトランザクションをすぐに作成するのではなく、既存のトランザクションを確認し、関連する記録を照合するべきです。

再試行には上限を設け、自動復旧で結果を確定できない場合の対応も定めておくべきです。顧客に必要なのは、何度も請求されることや処理画面が延々と表示されることではなく、保留中であることが明確に示され、解決につながる手段が用意されていることです。

分散システムでは、データベース、バックエンドサービス、物理キオスクが、同じトランザクションについて食い違う情報を報告することがあります。本番環境でこのような不整合に直面したことはありますか。どのように調査し、解決しましたか。また、食い違う記録の照合にAIが果たせる役割があるとすれば、どのようなものでしょうか。

はい。トランザクションの状態に関する不整合の調査は、本番環境での業務の一部でした。職場での事例には触れずに考え方を説明するため、仮定の例を使います。

一般的なセルフサービス型のレジを考えてみてください。決済サービスには購入が正常に完了したと記録され、プリンターはレシートの印刷ジョブを受け付けたと報告しますが、その後、画面にエラーが表示されます。こうした観測結果は、購入全体が失敗したことを示すのではなく、やり取りの異なる段階を表している可能性があります。

まず、取引識別子と関連するサービスおよび端末の記録を使って、処理の順序を再構成します。次に、それぞれの観測結果から何が分かるのかを明らかにします。プリンターがジョブを受け付けたからといって、レシートが顧客に渡った証拠になるとは限りません。リクエストが受信されたからといって、その金銭的な効果が確定した証拠になるとも限りません。

解決方法は、どの段階で失敗したかによって異なります。出力段階だけに対処すればよい場合、取引全体を繰り返すのは適切でない可能性があります。何が起きたかを入手可能な証拠から確認できない場合は、誰かが調査している間、該当する処理を制御下に置いておくべきです。

根本的な修正では、単に一つの記録を直すだけでなく、なぜ不整合が起き得たのかにも対処する必要があります。

AIは、イベントの相関関係を調べ、不足している情報を特定するのに役立つ可能性があります。それぞれの説明候補と、それを裏付ける証拠を提示するよう求めます。AIには調査の範囲を絞る手助けをさせるべきであり、最も説得力があるように聞こえる説明を選んで、矛盾する記録を解決させるべきではありません。

AIエージェントが本番環境のインシデントを診断する段階から、復旧措置を提案、あるいは実行する段階へと進化するなかで、AIシステムに取引の再試行、取り消し、変更を許可する前に、どのような保護策を整えるべきでしょうか。冪等性キー、取引ログ、照合の仕組みといった決定論的な制御によって、AIがさらなる障害を引き起こすのをどう防げるでしょうか。

措置の提案と、その承認・実行は切り分けるべきです。

AIエージェントが再試行を提案することはあっても、その再試行が許可されるかどうかは、別の制御機構が判断すべきです。その機構は、取引の現在の状態、処理の識別情報、エージェントの権限、その措置が安全となる条件を確認する必要があります。

この確認は、モデルが最初にインシデントを調べた時点だけでなく、措置を実行する時点でも行う必要があります。その間に、別のプロセスが取引を完了している可能性があるためです。

エージェントが利用できるツールも、必要最小限に絞るべきです。取引状況を取得する権限と、支払いを取り消したり、財務記録を変更したりする権限は別物です。望ましい解決策により広いアクセス権が必要だからといって、エージェントが自らの権限を拡大できるようにしてはなりません。

冪等性は、重複した処理による影響を抑えます。ログは、調査に必要な履歴を保持します。照合は、関連する記録間の整合性を確認します。ただし、いずれも単独では、提案された措置が適切であることを判断できません。

また、使用した証拠、推奨内容、承認の判断、実際の結果も記録します。そうすることで、介入後に内容を検証できます。

こうした制御は、モデルの外部にある、テスト可能なソフトウェアによって強制されるべきです。エージェントに慎重に行動するよう指示することは有用な指針ですが、承認の仕組みにはなりません。

AI監視システムが取引の失敗らしき状況を検知し、処理を自動的に取り消すことを推奨するシナリオを考えてみてください。実際には取引が成功していて、確認通知が遅れていただけなら、その介入によって新たな問題が生じる可能性があります。不確実性を認識し、不完全な情報に基づいて是正措置を取らないようにするには、エンジニアリングチームはAI主導の復旧システムをどのように設計すべきでしょうか。

システムには、実質的な「結果不明」の状態が必要です。そうでなければ、情報の欠落を誤った失敗判定に結び付けてしまう可能性が高くなります。

確認通知の遅延は調査すべき理由にはなりますが、取引を自動的に取り消す理由にはなりません。取り消しも、それ自体に影響を伴う別の金融処理です。取り消しには、独立して確認された根拠と適切な承認が必要です。

対応は二つの経路に分けます。調査経路では、状況を取得し、不足しているイベントを収集し、記録を照合して、担当チームに通知できます。金融処理の経路は、その実行条件が満たされるまでブロックしたままにします。

これにより、AIの信頼度スコアが取引の証拠の代わりになるのを防げます。モデルは、不完全な情報を基に組み立てられた説明に対しても、高い確信を示すことがあります。

明確なエスカレーションの基準も必要です。取引を無期限に保留することは、顧客にとって満足できる結果ではありません。未解決の案件には担当者を置き、次の安全な対応を判断するのに十分な情報を持たせるべきです。

したがって、復旧プロセスは、「この取引を変更する根拠はまだ確認できません」と「解決するには、次の対応が必要です」の両方を示せる必要があります。

不確実性を認識しても、それに対処する実践的な手段がシステムに備わっていなければ意味がありません。

自律型AIをめぐる最大の課題の一つは、人間の承認がいつ不可欠なのかを見極めることです。本番環境の復旧において、AIが独立して実行してよいと考える措置はどれで、常に人間の承認を必要とすべきなのはどれでしょうか。金銭取引、規制遵守、顧客の信頼が関わる場合、組織はどのようにしてこうした境界を定めるべきでしょうか。

私は、ある行為が「AI」と呼ばれているかどうかではなく、誤った場合にどのような結果を招くかを基準に境界を定めます。

エージェントが許可された情報だけにアクセスできることを条件に、読み取り専用の調査から始めるのが妥当です。基盤となる取引を変更する権限を与えずに、診断記録を収集し、関連するアラートをまとめ、インシデントの概要を作成できます。

条件が独立して検証され、その影響が限定されている場合には、あらかじめ定めた復旧手順の一部も自動化に適している可能性があります。

提案された対応が承認済みの手順から外れる場合、記録に食い違いがあり金銭的な結果が確定していない場合、あるいはセキュリティ制御やエージェント自身の権限を変更する場合には、人間の承認を必須にすべきです。エージェントが自ら承認してはならない判断です。

だからといって、日常的な金融業務のすべてに人間の承認が必要というわけではありません。確立されたルールに基づく処理と、インシデントの最中にモデルが独自に修正方法を考え出すことは別です。

人間による確認も、実質を伴うものでなければなりません。承認画面には、根拠となる証拠、残る不確実性、予想される影響、選択可能な代替案を表示すべきです。そうした背景を示さず、自信に満ちた文章だけを見せて承認を求めても、保護効果はほとんどありません。

こうした境界は、導入前に合意しておくべきです。自動化システムにどの程度の権限を持たせるべきかを決めるのに、障害発生中は適切なタイミングではありません。

あなたは、フォールトトレラントなバックエンドシステム、可観測性ツール、ソフトウェアサービスと物理ハードウェアの連携に幅広く取り組んできました。インシデントを確実に診断するには、AIエージェントにどのような本番環境のテレメトリや証拠が必要でしょうか。エンジニアリングチームは、AIが生成した有用な提案と、もっともらしく見えても誤っており、障害を悪化させかねない結論とを、どのように見分けられるでしょうか。

まず、関係するシステム全体にわたって顧客の業務を結び付ける証拠から始めます。取引識別子、サービスイベント、永続化された状態の変更、デバイスの応答、通信障害などです。

ソフトウェアのバージョンや設定変更も重要です。リリース後に発生した障害は調査の手掛かりになりますが、発生時期だけで因果関係が証明されるわけではありません。

エージェントは、証拠の限界も理解する必要があります。ログが不完全なこともあれば、記録の到着が遅れることもあり、時刻が一致しない場合もあります。確認応答がないことは、処理が行われなかった証拠と同じではありません。

有用な診断では、観測事実と解釈を分けるべきです。「クライアントにタイムアウトが記録された」は観測事実です。「バックエンドが利用不能だった」は説明であり、裏付けとなる証拠をさらに必要とします。

提案には、その根拠となる記録を示し、未解明の点を説明するとともに、結論を確認または否定するために追加でどのような確認が必要かを明記すべきです。

そのうえでエンジニアは、重大な影響を伴う提案について、エージェントの要約だけに頼らず、元の記録に照らして検証すべきです。長期にわたる、あるいは矛盾を含むイベント履歴を要約が圧縮している場合には、特に重要です。

私が基準とするのは明快です。別のエンジニアが証拠をたどり、妥当な結論に至れるかどうかです。説明がこの検証に耐えられないなら、本番環境の変更に反映させる段階にはありません。

あなたが宝くじ・賭け端末のランサムウェア耐性に関する研究を発表した際、500台の端末を模擬する合成環境を用いて、AI支援型のセキュリティフレームワークを評価しました。最も重要な知見は何でしたか。また、結果を解釈するにあたり、読者はどのような限界を理解しておくべきでしょうか。提案されたアーキテクチャを本番環境に適用する前に、どのような追加検証が必要でしょうか。

私は、検知にとどまらないレジリエンスを検討したいと考えました。つまり、端末環境が攻撃をどのように封じ込め、認識し、何が起きたかを示す証拠を保全しながら復旧できるかです。

その結果生まれたResilient Security Frameworkは、予防的な制御、AIを活用した異常検知、明確に定められた対応・復旧の仕組みを組み合わせています。AIの役割は、不審な挙動の検知に関するものでした。これは、言語モデルのエージェントに金銭取引を独自に変更させる実験ではありません。

評価では、500台の端末を表す合成環境を用い、72時間のシミュレーションを実施しました。ランサムウェア攻撃は挙動を模倣する形で再現しており、実際の端末500台に導入したわけではありません。

本研究で設定したウイルス対策ソフトのみのベースラインと比べると、平均検知時間は52分から31分に、平均復旧時間は120分から56分に短縮されました。

これらは、実験条件下で統合フレームワークを用いて得られた結果です。AIだけによる成果とみなしたり、実運用環境での性能を保証するものとして扱ったりすべきではありません。有用な知見の一つは、検知を早めるだけでは、同程度の復旧改善にはつながらなかったことです。封じ込めと復旧の設計も重要でした。

限界についても理解しておく必要があります。シミュレーションで用いた負荷、ネットワーク条件、攻撃の挙動、ベースラインとなる防御策は、あらゆる運用環境を代表するものではありません。デバイスやアプリケーションが異なれば、新たな検証が必要になります。

本番環境で使用する前に、実環境を反映したハードウェアでのテスト、独立したセキュリティ評価、長期にわたる評価、誤警報や処理オーバーヘッドの慎重な測定が必要だと考えます。

また、正当な取引が行われている状況で復旧プロセスをテストする必要もあります。動作するソフトウェアイメージを復元できても、完了した取引を記録するために必要な情報が失われるなら、それだけでは十分ではありません。

この研究は、さらなるテストの土台となるものです。実際の運用環境で安全に動作することを実証するには、別途検証が必要です。

あなたの見解には、長年の本番システム開発の経験と、ソフトウェアの信頼性やAIを活用したセキュリティに関する学術研究の両方が反映されています。実稼働システムでご自身が実装・運用してきた信頼性を支える仕組みと、研究やシミュレーションテストを通じて検討してきた手法を区別して説明していただけますか。AIを活用した復旧機能のうち、すでに実用段階にあると考えるものと、依然として実験的なものはそれぞれ何でしょうか。

本番環境での業務には、ソフトウェア開発と統合、取引の検証、トラブルシューティング、テスト、リリースの検証が含まれてきました。

論文として発表した研究は私の業務の別の側面であり、それぞれの研究は、明示された手法と限界に基づいて理解する必要があります。

ランサムウェアに関する論文では、提案するセキュリティフレームワークを合成テスト環境で評価しています。エッジAIに関する私の論文は、デバイス上のインテリジェンスと、取引端末への応用の可能性について、文献に基づいて分析したものです。IEEE FeedForwardに掲載された私の記事では、監視、エスカレーション、フォールバック動作などを含む、AIを活用した信頼性アーキテクチャを、制御されたシミュレーションを通じて検証しています。

これらの論文のいずれも、実際の金融取引に対する権限を持つ自律型AIエージェントを私が導入した証拠として受け取るべきではありません。

実用化にあたっては、エンジニアが内容を確認できる支援機能を優先したいと考えています。たとえば、元の記録にひも付いたインシデントの要約、複数のアラート間の相関分析、診断のための確認項目の提案などです。ただし、こうした機能の有用性は、実際に運用する環境で測定する必要があります。

より難しいのは、事前に想定されていなかった状況でモデルが変更内容を選び、実行するような、範囲を限定しない復旧です。その実現には、有用な診断案を提示する場合よりも、はるかに高い水準の根拠が求められます。

本番環境での経験と研究は、互いを補完するものだと考えています。前者によって私が理解している運用上の課題が明確になり、後者では、検証を経て初めて実用に値することが示される手法を探っています。

今後、AIエージェントが異常の検知、障害の診断、分散システム全体にわたる復旧の調整において、さらに高い能力を備えるようになるなかで、自律システムと人間のエンジニアの関係はどのように変化していくとお考えですか。組織がミッションクリティカルな本番インフラに対し、AIにより大きな権限を安心して与えるには、どのような技術的な安全策、運用上の根拠、説明責任の仕組みが必要でしょうか。

AIは、インシデントの全体像をまとめる作業をさらに多く担うようになると考えています。エンジニアは、必要な情報を手作業で集めることに多くの時間を費やす代わりに、有用な時系列、影響を受けたコンポーネント、複数の原因候補、不足している証拠を把握した状態から対応を始められるようになるでしょう。

そうなれば、システムが負う責任や、システムを変更した場合の影響を理解したうえで判断する必要がある業務に、より多くの時間を割けるようになります。

実行権限は段階的に拡大したいと考えています。まずはエージェントをシャドーモードで動作させ、提案を出すだけで、実際の操作は行わせない方法があります。チームは、その提案をレビュー済みの結果と比較し、情報が不足している場合や、矛盾している場合、古くなっている場合に、エージェントがどのように振る舞うかをテストできます。

評価では、誤った介入、問題の見落とし、不必要なエスカレーション、エージェント自身のミスからの復旧も検証すべきです。対応チームを誤った方向に導くのであれば、提案が速く出ても価値はありません。

権限の拡大には、引き続き条件を設ける必要があります。モデルの更新やシステムの大幅な変更によって、以前のテスト結果が無効になる可能性があります。エージェントの挙動が求められる基準を満たさなくなった場合に、チームがその権限を縮小または取り消せる仕組みが必要です。

自動化が進んでも、人間の責任がなくなるわけではありません。運用ルール、変更に必要な根拠、障害を調査するプロセスについて、誰かが責任を負わなければなりません。

エンジニアは情報収集に費やす時間を減らし、自動化された操作を正当化できる条件の設定、テスト、維持に、より多くの時間を使うようになると考えています。

素晴らしいインタビューをありがとうございました。分散トランザクションの信頼性と責任あるAI支援による復旧に関する彼の取り組みを追いたい読者は、Sapan Pandyaに連絡を取ることができます。