AIをPoCで終わらせないために：本番運用を支える3つの視点

AIのデモがうまく動いても、そのまま業務で使えるとは限りません。問題が起きたときの責任者は誰か。エージェントは必要な承認を経て処理したか。利用者は、AIに任せてよい場面と、自分で確認すべき場面を理解しているか。本番運用には、モデルの精度だけでは答えられない問いがあります。

Tokyo AIのイベント「Engineering Reliable AI at Scale」で行われた講演には、こうした問いを考えるための3つの視点が示されています。責任を明確にすること、業務の実行過程を評価すること、そして人の行動を踏まえて設計することです。本記事では、これらを企業AIの本番移行にどう結びつけるかを整理します。

開催概要： 2026年6月16日、東京・渋谷。主催はTokyo AI（TAI）、ホストはIlya KulyatinとAndrew Sharifikia。Corpy & Co.のAlireza “Andrew” SharifikiaとRaphael Aubel、Behavioral AI Lab創設者のTomomi Tanakaが登壇しました。イベント概要・登壇者情報。

後半では、これらの考え方を実務に生かすためのFoundry Labsのアプローチを紹介します。

1. AIガバナンスを、日々の運用で責任を果たせる仕組みにする

Alireza “Andrew” Sharifikiaの講演「From PoC to Production」は、AIの品質をモデル性能だけで判断しないことを出発点にしています。個々のソフトウェア部品がテストを通過していても、業務上重要な条件でシステム全体が適切に動くとは限りません。

Sharifikiaが取り上げたQA4AIの5つの評価軸は、データ、モデル、システム、プロセス、顧客の期待です。QA4AIコンソーシアムのガイドラインに沿って考えると、入力データや利用環境だけでなく、更新の手順、利用者が理解している制約まで確認対象に入ります。

Sharifikiaが示す具体的な一歩は、本番で使うAIの一覧を作り、それぞれの責任者、目的、リスクを明らかにすることです。そのうえで、失敗がもたらす影響に応じて管理の深さを変えます。段階的な導入案では、データと利用範囲を整える段階から、システム統合の検証、組織としての管理体制へと進めています。

企業の導入判断に置き換えるなら、「どこまで検証できていて、どの制約が残り、変化が起きたら誰が対応するか」を説明できる状態が必要だと考えます。責任者と判断材料が明確になれば、開発部門だけでなく、業務部門やリスク管理部門も本番移行の条件を検討しやすくなります。

2. エージェントが答えに至るまでの実行過程を評価する

Corpy & Co.のR&D EngineerであるRaphael Aubelは、エージェントの「軌跡（trajectory）」に注目しています。これは、情報を観察し、判断し、ツールを呼び出し、データや状態を更新する一連の実行過程を指します。

この視点は、AIが業務システムを操作する場合に特に重要です。ツール自体は正常に動いていても、呼び出す判断が誤っていることがあります。最終回答が自然に見えても、その前に必要な承認を飛ばしているかもしれません。出力だけの確認では、処理の途中で起きた問題を見落とす可能性があります。

Aubelは、小売の顧客対応を題材にしたローカル実験を紹介しています。33種類のタスクを6つのモデルでそれぞれ3回実行し、合計594回の結果を確認したものです。これは問題を具体的に示すための実験であり、公式ベンチマークではありません。モデル提供企業の一般的な優劣を示す結果として扱うべきではありません。

具体例の一つは、リスク上の理由で保留状態にあるアカウントからの返金依頼です。このテストでは、資金を動かす前に人の担当者へ引き継ぐことがルールでした。しかし、示された失敗例では、引き継ぎを行わずに返金処理を開始しています。問われるのは、返金操作を実行できたかだけでなく、その前提となる手順を守ったかです。

Aubelはさらに、誤った操作によって共有状態が変わり、別のエージェントがその状態をもとに次の判断をする例へと議論を広げています。これは複数エージェントの実測結果ではなく、失敗が波及する仕組みを示す説明です。エージェント間で渡す情報や操作権限も、確認対象になります。

実務では、期待する結果と、必ず通るべき手順の両方を定義することが出発点になります。同じシナリオを繰り返し、業務データの最終状態と実行履歴を確認する。Aubelの結論も、リスクに応じて軌跡を評価し、保護策を設け、継続的に監視する必要性を強調しています。

3. 利用者の行動まで含めて設計する

Behavioral AI Lab創設者のTomomi Tanakaは、講演「Why AI Systems Fail After Deployment: The Missing Human Layer」で行動面からの検討を加えています。開発前に確認すべきものとして示されたのは、4つの観点です。

• 信頼： 利用者は、AIに頼ってよい場面と、確認が必要な場面を理解できるか。
• インセンティブ： 業務上の評価や報酬は、意図した行動を促しているか。
• 認知的負荷： 判断を楽にしているか。それとも確認すべきことを増やしているか。
• 適応： 導入後に、利用者や周囲の人の行動がどう変わるか。

TanakaのSafety by Designの考え方では、想定される悪影響と保護策を導入前に検討し、公開後も利用状況を見ながら見直します。

企業の業務に当てはめると、人による確認工程そのものも設計対象になります。例えば、担当者にどの情報を渡し、何を判断してもらい、その判断に必要な時間と権限をどう確保するか。これは講演の考え方を業務に当てはめた私たちの考察です。「最後に人が見る」という手順を設けるだけでは、これらの条件は定まりません。

一つの業務を、本番で回せる状態まで設計する

Foundry Labsが提案するアプローチは、AIを組み込む業務の流れを確認するところから始まります。何をきっかけに処理が始まり、誰が判断し、どのシステムに結果を残すのか。情報が足りない場合や、途中で処理が止まった場合はどうするのか。こうした問いを具体化することで、開発と業務運用の担当者が同じ前提で導入を検討できます。

例えば、請求書処理を支援するAIを考えてみます。PoCでは、サンプルの請求書から取引先名、金額、発注番号を正しく読み取れれば、技術の有効性を示せるでしょう。一方、実際の業務では、同じ請求書をすでに受け付けていないか、発注内容と一致しているか、例外を誰が承認するか、会計システムへどう登録するかまで考える必要があります。そこで私たちは、読み取り精度に加え、確認や手戻りの負担も含めて業務を適切に完了できることを、導入判断の軸に据えます。

次に決めるのは、AIにどこまで操作を任せるかです。初期段階では、AIが会計登録の下書きを作り、承認権限は担当者が持つ構成が考えられます。発注書が見つからない、金額が一致しない、取引先情報が変更されているといった案件は、例外として人に引き継ぎます。許可する操作は、モデルへの指示だけでなく、周辺のソフトウェアとアクセス制御でも制限します。業務上のルールを、実際の制御、責任者、テストに対応づけることで、ガバナンスを実装に落とし込めます。

検証も、システムをまたぐ業務全体を対象にします。同じ請求書が二度届く、項目を読み取れない、承認が遅れる、会計システムへの登録要求がタイムアウトするといったケースを用意します。最後の例では、要求は受け付けられているのに応答だけが戻っていない可能性があります。そのまま再実行して二重登録しないよう、実際の登録状態を確認してから次の操作を決められるかを検証します。最終的な記録が正しいかに加え、必要な承認を経たか、中断から適切に復旧したかも合格条件に含めます。

本番の記録を変更する権限を与える前には、既存業務と並行してAIに処理案を作らせ、担当者の判断と比較する段階を設けると有効です。結果が食い違った場合は、AIの誤りなのか、業務ルールが曖昧なのか、担当者だけが知っている情報があるのかを確認します。利用が認められた実データを使う場合も、アクセス権やデータの取り扱いは本番と同様に検討します。この段階で見たいのは、デモでは表れにくい例外調査の負担です。

人による確認画面も、導入効果を左右します。担当者には、元の請求書、照合した発注内容、登録案、引き継ぎの理由をまとめて示すことが望まれます。確認のたびに複数のシステムを開き直さなければならないなら、作業を減らす代わりに別の場所へ移しているだけかもしれません。モデルの精度とともに、確認時間、修正内容、判断の差し戻し、未処理案件を確認します。承認率が高いという数字だけでは、提案が正確なのか、担当者が確認しきれず承認しているのかは分かりません。

適用範囲は、限定した運用で得られた結果に応じて広げます。まず条件の明確な定型案件を自動化し、不慣れな取引先や金額に争いのある案件は人が扱う方法もあります。自動化の範囲を広げるたびに、責任者と、挙動が変わった場合の対応を定めます。復旧では、ソフトウェアだけでなく業務への影響も考える必要があります。モデルを前のバージョンへ戻しても、すでに作成した会計記録は元に戻りません。影響を受けた記録を特定し、追加操作を止め、修正権限を持つ担当者へ引き継ぐ仕組みまで設計します。

請求書処理を想定例として考えると、3つの視点のつながりが具体的になります。誰に何を任せるかを責任体制で定め、実行過程の検証で操作の正しさを確かめ、人の行動を踏まえた設計で実際に監督できる状態をつくる。3つの講演の視点を結びつけることで、PoCを業務の一部にするための判断材料がそろいます。

Foundry Labsは、本番で使われるAIシステムの設計、開発、導入、運用を支援しています。Tokyo AIでは、実務家が集まり、導入に伴う技術面と組織面の課題をともに考える機会をつくっています。

登壇資料のお取り寄せ

Andrew Sharifikia、Raphael Aubel、Tomomi Tanakaの登壇資料をご希望の方は、お問い合わせフォームよりご連絡ください。**「Engineering Reliable AI at Scale、2026年6月16日開催」**と、ご希望の登壇者名を添えていただけるとスムーズです。

関連する講演・参考情報

• Tokyo AIのイベント概要・登壇プログラム
• Andrew Sharifikia「From PoC to Production: A Practical Roadmap for Enterprise-grade AI Compliance in the Automotive Industry」講演
• Raphael Aubel「System Quality for Multi-Agent AI Systems」講演
• Tomomi Tanaka「Why AI Systems Fail After Deployment: The Missing Human Layer」講演
• QA4AI公式ガイドライン・ダウンロード

登壇者プロフィール

Alireza “Andrew” Sharifikia

Corpy & Co. Software Engineering Manager。 AI、コンピュータビジョン、データサイエンスを専門とし、CorpyのXAIの取り組みやTAIコミュニティとの連携に携わる。講演では、AIの品質保証と、企業での導入を支える組織の責任を結びつけて論じた。

Raphael Aubel

Corpy & Co. R&D Engineer。 技術検証から本番導入まで、AIの実用化に取り組む。物流文書の自動処理、配送ルートの最適化、産業向けの画像検査などに携わり、評価と運用上の信頼性を重視している。

Tomomi Tanaka

Behavioral AI Lab創設者。 AI、人の行動、意思決定の関係を専門とする行動科学者・AIストラテジスト。BEworksのSenior Behavioral Advisor、近畿大学のAdjunct Professorも務める。

記事一覧