ITC InfotechがGoogle Cloudと提携し「自社が最初の顧客」に——AIエージェント導入は社内の面倒な業務から始める

インドの大手SI企業 ITC Infotech が Google Cloud と提携し、AIエージェントの全社導入を発表した。この発表で私が注目したのは提携規模ではなく、自社を最初の顧客(customer zero)に据えると明言した点である。AIエージェントを顧客に売る側が、何から手を付けるべきかという問いへの回答になっている。

要点 (事実のみ)

ITC Infotech が Google Cloud との戦略的パートナーシップを2026年7月23日に発表した。Gemini Enterprise を全社導入し、エンタープライズ向けのエージェント型AI変革を推進する。
ITC Infotech は自社を Gemini Enterprise の customer zero(顧客第一号) と位置づける。自社で展開・検証・スケールさせた上で、実装方法論と技術設計図(ブループリント)を顧客に提供する。
自社適用の対象業務として、RFP(提案依頼書)の起案、IT/HRのチケット対応(サービスマネジメント)、請求書監査が挙げられている。ソフトウェア開発領域ではレガシーコードの移行と複雑性の削減も対象。
単発のプロンプト利用ではなく、専用AIエージェントの構築とマルチエージェントのオーケストレーションにより、社内システムとデータソースを横断して複雑な業務を自律実行させる方針。
複数都市に Google Cloud との Joint Center of Excellence を設置し、業界別のAIブループリントを開発する。対象業界は消費財(CPG)、小売、ホスピタリティ、製造。
ITC Infotech CEO の Manas Chakraborty 氏は、エンタープライズ規模での導入実績を持つパートナーを求めていたと述べている。

「自社が最初の顧客」は、売る側の誠実さの問題である

AIエージェントを提供する事業者が自社で使っていない、という状態は珍しくない。デモは動く、提案書も書ける、しかし社内の業務は従来どおり回している。この状態で「御社の業務を自動化します」と言うのは、率直に言って弱い。

ITC Infotech が customer zero を明言したのは、この弱さを構造的に潰す判断だと私は受け取った。自社で回してからでないと、どこで失敗するかを知らないまま顧客に入ることになる。エージェントが権限のないデータを読もうとする、既存システムのAPIが想定と違う、例外処理が業務ルールと噛み合わない——こうした問題は設計段階では見えず、運用してはじめて出る。

受託開発とAIエージェント事業をやっている立場で言えば、この順番は自分たちにも突きつけられている話だ。自社の業務で使っていない構成を顧客に提案するのは、検証していない設計を売ることに等しい。

選んだ業務が「地味な管理業務」であることの意味

customer zero を宣言するだけなら簡単だ。評価すべきは何を対象に選んだかである。

挙がっているのは、RFP起案、IT/HRのチケット対応、請求書監査。いずれも売り物にしにくい、社内の面倒な業務だ。派手なデモになる顧客接点の自動化ではなく、社内の裏側を選んでいる。

これは正しい選び方だと考えている。理由は2つある。

第一に、成否の判定基準がすでに存在する。請求書監査には正解がある。チケットには解決したかどうかがある。RFPには提出できたかどうかがある。AIを入れるとき最も困るのは「良くなったのかどうか分からない」状態だが、これらの業務では最初から測れる。

第二に、失敗しても顧客に迷惑がかからない。社内業務なら、エージェントが間違えても人が拾える。顧客対応の自動化から始めると、精度が出ない期間のコストを顧客が払うことになる。AI PoCの進め方で書いた「PoC止まり」の多くは、この順番を逆にしたことが原因になっている。

先日取り上げた損保ジャパンの機械学習自動化事例でも、自動化されたのは反復のある実験工程で、業務課題をタスクに翻訳する部分は人が担っていた。評価基準が既に定義されている業務から入るという共通点がある。

マルチエージェントを掲げていることへの留保

一方で、マルチエージェントのオーケストレーションを前面に出している点については、私は慎重に見ている。

複数のエージェントを協調させる構成は、うまく動けば強力だが、失敗時の切り分けが一気に難しくなる。どのエージェントの判断が間違ったのか、どこで情報が欠落したのかを追えなければ、改善のループが回らない。自社で先に回すという方針は、まさにこの難しさに自分たちで先にぶつかるという意味でもあり、そこは理にかなっている。

自社で同じ構成を作るとしたら、難所はエージェントの実装ではなく、社内システム側のAPIと権限設計になる。RFP起案ひとつ取っても、過去案件の情報、価格ロジック、承認フローに触る必要があり、それぞれ権限が異なる。エージェントに横断アクセスを持たせる設計は、実装より前に権限モデルの整理が要る。この構造はAIはERPと業務基盤なしには機能しないで書いた話と同じである。