NTTデータ Codexで障害解析を3日から30分にした中身

3日かかっていた障害解析が、30分になりました。

NTTデータグループがCodexで出したこの数字、率にすると99%以上の短縮なんですが、そのまま会議に持ち込むとだいたい「うちでもできるんですか」で止まります。

止まる理由ははっきりしていて、みんな30分側ばかり見て、3日側を分解していないからです。

3日かかっていた作業の内訳 どこにボトルネックがあったか

公開されているのは、3日と30分という前後の数字だけです。

その間に何があったかの内訳までは出ていません。

だから、ここは自分で割るしかありません。

障害解析という業務を工程に分けると、だいたい4つになります。

事象の確認と再現、該当箇所の特定、原因の究明、対処方針の判断と報告です。

3日という時間が何に溶けているかというと、手を動かしている時間ではないんですよね。

どこを見ればいいか分からないまま探している時間と、その領域に詳しい人の手が空くのを待っている時間です。

数十万行のコードと大量のログを前にして、当たりをつけるところに一番人手がかかる。

しかもここは経験がものを言う工程なので、特定の人に依存しがちです。

それと、3日というのは3日ぶん働いた時間ではありません。

夜間に起きて朝まで止まる、担当者が別案件を抱えている、確認待ちで半日空く。

実時間にはそういう空白がかなり混ざります。

短縮率が大きく出やすい業務でもある、というのは押さえておいたほうがいいです。

この4つに分けてから見ると、30分側で何が起きたのかも見当がつきます。

30分に縮まった理由 Codexが効くのは探す工程

Codexは、リポジトリごとコードを読み込んで、指示された調査や修正を自分で進めるエージェントです。

人間が「このあたりを見て」と範囲を絞ってやる必要がありません。

さきほどの表で圧縮の余地を大と置いた2工程、該当箇所の特定と原因の究明は、どちらも中身は探索です。

たとえば「このエラーが出る経路を全部洗い出して」と投げれば、呼び出し元をたどって候補を並べるところまで進みます。

人が半日かけて当たりをつけていた部分が、片っ端から潰していく作業に置き換わるわけです。

ここで面白いのは、人間が読む速度が上がったわけではないところです。

読む範囲を絞り込む作業そのものが要らなくなった。

速くなったというより、工程が1つ消えたと考えたほうが近いです。

そして30分はゼロになっていません。

対処方針の判断と関係者への説明は、人間側に残っています。

「AIが障害を直した」ではなく「AIが探して、人が決めた」。

この線引きが残っているから、この数字は信用できます。

逆に言えば、探索の比率が小さい業務に同じ構造を持ち込んでも、同じ倍率は出ません。

9,000人規模に配るための土台 ChatGPT Enterpriseの位置づけ

展開は9,000人規模と伝えられています。

自分としては、3日から30分よりこっちの数字のほうが効いていると思ってて。

便利なツールを見つけて自分で使うのと、9,000人が業務で使えるようにするのは、まったく別の仕事なんですよね。

NTTデータグループはChatGPT Enterpriseを基盤に置いた上で、Codexを展開しています。

ChatGPT Enterpriseは、入力したデータが学習に使われない、管理者が誰にどの機能を開放するか制御できる、SSOと監査ログが揃う、という前提のプランです。

つまり情報システム部門と法務が承認できる状態を先に作ってから、その上に道具を載せているわけです。

障害解析で扱うのは、本番のログとソースコードです。

社内で一番外に出したくないデータの部類。

そこにAIを通すには、契約とデータの取り扱いが片付いていないと、現場は怖くて使えません。

順番が逆になるとどうなるか。

現場が良いツールを見つける、情報システム部門に止められる、検証止まりで終わる。

よく見る流れです。

9,000人という数字も、少し補正して読んだほうがいいと思います。

全員が毎日Codexを触るわけではありません。

ただ、使いたくなったときに申請なしですぐ触れるのと、都度稟議を上げるのとでは、現場が試す回数が桁で変わります。

効いているのはそこです。

だから再現価値があるのは「Codexを入れた」より「9,000人が業務データに向けて使える状態を先に作った」のほうです。

ここが決まっていないまま道具だけ配ると、良いものほど早く止まります。

自社で同じ数字を出したいなら最初に測るもの

測るのは30分側ではなく、3日側です。

1. 直近の障害対応を3件選んで、さきほどの4工程に時間を割り振ってみる。ざっくりで構いません。探していた時間と、決めていた時間を分けるのが目的です。
2. 探していた時間の比率を出す。ここが7割を超えているなら、同じ構造の圧縮が効く余地があります。逆に3割しかなくて残りが合意形成に消えているなら、道具では変わりません。そのときのボトルネックは調査ではなく組織側にあります。
3. 本番のログとコードをAIに渡せる状態か、契約と権限を先に確認する。ここが片付かないまま検証を始めると、うまくいった検証ほど本番に出せずに終わります。

そのうえで、99%という倍率はそのまま自社の期待値にしないほうがいいです。

前提も規模も違います。

持ち帰るのは倍率ではなく、工程の分け方のほうです。

ついでに言うと、障害解析が最初の対象に選ばれるのは理にかなっています。

成果が時間で測れる、対象が社内で完結する、失敗しても顧客に直接は当たらない。

AIを業務に入れる最初の一手として、この3つが揃う業務は意外と少ないんですよ。

自社で候補を探すなら、この条件から逆算したほうが早いです。

障害解析はたまたま最初に成果が出た領域であって、構造そのものはどこにでもあります。

探す時間が長くて、最後の判断は人が持つ。

この形をしている業務が自社にいくつあるか。

3日から30分の本当の使いどころは、そこを数え直すきっかけにすることだと思ってます。