インドの大手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と業務基盤なしには機能しないで書いた話と同じである。
中堅・中小企業が持ち帰れること
グローバルSI企業の全社導入をそのまま真似することはできない。それでも判断の順番は再現できる。
AIエージェントを検討するなら、最初に選ぶべきは社内で最も面倒で、かつ正解が定義できる業務である。顧客に見せられる派手な業務ではない。そして選んだ業務を、まず自分たちで運用してみる。うまくいった構成だけを次に広げる。
この順番を守れば、AIエージェントの導入は「試したが定着しなかった」という結末を避けられる。逆に、成果指標が決まっていない業務から入ると、精度の議論だけが延々と続く。AIシステム開発全体の進め方についてはAIシステム開発とはで整理している。
自社のどの業務からAIエージェントを差し込むべきかを整理する段階でお困りなら、開発のご相談からお問い合わせいただければ、対象業務の選定と評価基準の設計からご一緒する。
出典: ITC Infotech partners with Google Cloud to drive agentic AI transformation (The Times of India, 2026-07) / ITC Infotech and Google Cloud Join Hands to Scale Enterprise Agentic Transformation and AI Innovation (Google Cloud Press Corner 公式リリース, 2026-07-23)
