GxPの紹介とレガシーシステムの定義

髙田：今日のテーマは、AIによって開発が加速していく中で、企業の価値を支え続けているレガシーシステムと、その保守を抱えている開発チームは今何をするべきかというものです。レガシーシステムと開発チームを進化させる方法として、DevOpsへAIを段階的に浸透させていくやり方をお伝えしていきたいと思います。

まず当社、株式会社GxPについて紹介いたします。GxPはエンタープライズ向けに、データ駆動・AI駆動を軸としたDX・AXを推進し、コンサルティング、AI駆動開発、内製化支援を得意領域として提供しています。構想策定から実装、運用、定着まで一気通貫で伴走するテクノロジーパートナーです。

続いて自己紹介させていただきます。DevEx革新チームでシニアマネージャーをさせていただいています、髙田康宏と申します。普段はシステム開発やITサービスの運用を担当する複数のチームとともに、アーキテクチャ設計やAIを活用した開発プロセスの改善に取り組んでいます。

最初に、今日の結論からお伝えします。本講演でいうAI DevOpsとは、AIに開発を任せることではありません。レガシーを支える開発チームが、AIとナレッジとともに成長を続ける仕組みを作ることだと考えています。生産性向上とは早く作ることだけではなく、価値を生まない時間から価値を生む活動に使える時間へと、時間の使い方を変えることを目指します。

そしてAIは、DevOpsの土台が整っているほど効果を発揮します。この状態をどう作っていくのかを、レガシーシステムの定義、AI導入の始め方、生産性とチームの変化、そしてAIネイティブ開発への取り組みの順で見ていきます。

まずこの講演でいうレガシーシステムの定義を揃えておきます。レガシーというと古い技術、古いフレームワークといったものを思い浮かべる方が多いと思いますが、今日は技術の古さだけでは定義しません。現在もビジネスの価値を生み、機能追加も続いていて、簡単には止められない、運用を続けながら変更責任を伴う既存システムを、この講演では広い意味でのレガシーと捉えます。

• CASE01 ECサイト：今も売上が増え続ける、ビジネス向けECサイト。Java／Spring／JSPで、リリース後10年経過
• CASE02 Webアプリ：少しずつユーザーが増えている、新しいWebアプリ。Next.js／NestJSで、運用制約が増え始める
• CASE03 社内向けデータ収集基盤：各部署・各システムからデータを集める、社内向けデータ収集基盤。SQL・各種スクリプトで、業務判断に使うデータを収集・整形

CASE02のように、新しい技術を使っていても条件に合えば立派なレガシーと言えます。今回は技術の新旧ではなく、価値を支え続けるという役割に注目しています。

コンテキスト不足というAIの壁とDevOpsという土台の重要性

AIが苦手なのは古いコードそのものではありません。主要な課題の一つはコンテキストの不足です。AIはコードを読めますし、コードも重要なコンテキストの一つですが、コード以外の設計や修正された理由、業務ルールといったものがないと、AIはもっともらしいことを出力してきますが、それが正確ではないものとなります。だからこそ、AIに渡せるコンテキストをどう整備できるかが重要な点になります。

そこで効いてくるのがDevOpsのプロセスとツールです。イシュー管理、プルリクエスト、CIや検証環境といったものは人間のための開発基盤ですが、同時にAIがコンテキストを理解するためにも役に立ちます。変更の背景や目的、設計判断、レビューの結果記録、変更を安全に試すための仕組みです。こうしたAI支援は、整ったDevOpsの土台の上で、開発・運用プロセスをより効率的に進めるために活用できます。逆に土台がないと、コンテキストは担当者個人、属人的な経験値に依存します。AI活用も個人レベルで止まることが多くなると思います。まずこのAI DevOps、そのためにDevOpsの土台が整っているか確認から始めることが良さそうです。

この図は、DevOpsにおけるAI利用の段階の全体図を示しています。まず土台としてのDevOps基盤、その上にAI支援が乗ります。調査対応やコード支援といったAIの支援です。AIが整理した知識が循環していき、レガシーを含むシステムが安全に変更できる段階に進みます。その上で最終的に、システムがビジネス目標に貢献できているかにつながっていきます。大事なのは下から層を積み上げることです。この流れをシステム開発運用にどうやって組み込んでいくのか、チームの開発生産性をどう捉えるのかという流れで説明していきたいと思います。

障害対応の調査から始めるAI活用、AIと人の役割分担

レガシーシステムにおけるAI DevOpsの具体的な始め方です。レガシーへのAI導入は、障害や問い合わせ対応を含む日々の調査から始めるのが現実的だと考えています。前提として調査そのものはサービスの価値を守る大切な仕事ですが、障害のたびに過去と同じ原因をゼロから調べる時間は、できれば減らしたいというのは皆さん共通だと思います。

これはレガシーに限った話ではありません。調査対応の中で、埋もれていた知識や過去の設計判断、足りなかったテストといった多くの知識が発見されると思います。それをその場限り、担当者個人の学びにせず、どうやったらチームとAIが使える資産にできるか、その変化を起こしたいと考えています。

障害対応などの調査がAI導入の起点に向いている理由は3つあります。1つ目は根拠があって検証しやすいこと、そういったものがAIが得意なタスクであることです。2つ目は繰り返される、共通化できることです。3つ目はレビューで知識が溜まっていくことです。調査結果をレビューしながら蓄積し、次回の調査や不具合の修正のインプットに使う、チームのナレッジ共有が進みやすいという利点があります。

障害対応にAIを利用する場合、AIには得意なことをやらせて、人間は判断をします。AIはログの要約、情報の検索、回答文書の作成を得意としています。一方で、原因と修正方針の判断など責任を持つのは開発チームが担う必要があります。ここで大切なのは、AIが出力したものを鵜呑みにしないことです。根拠が妥当なのか、影響やリスクを見落としていないか、判断能力をチームとして養い続ける必要があります。

調査結果報告はどのようなプロジェクトでも似たような構成となりますので、例に挙げてみました。スキルでは調査の手順、結果テンプレートを指示しています。AIは手順に従って調査タスクを実行し、テンプレートを埋める形で結果を出力します。これによって、担当者による出力のばらつき、品質のばらつきを抑える効果が期待できます。

この例では最後に振り返りドキュメントを作成する手順を運用しています。振り返りでは、仮説、調査の進め方、レビューの指摘、次回の改善点といったものをAIに出力させています。この結果と振り返り、この2つをプルリクエストでレビューし、チームメンバーで共有することで、ナレッジとしての蓄積がされ、後から役に立たせることができます。

開発チームがAI DevOpsを実践し、レガシーシステムを保守運用していくシーンを、知識のフローとして図にしました。ここではDevOpsの上にAI支援が乗り、知識循環が始まった状態を示しています。障害対応、問い合わせ対応の結果をレビュー済みの調査結果として残し、次の調査や不具合修正でAIが再利用できるようにするという話をしました。この状態ができると、例えば調査で毎回ゼロから調べる時間がぐっと減ります。またAIの利用から、人とAIが参照できる知識循環、この循環が実践できているかどうかが、AI導入の一つの節目だと考えています。

生産性は「時間」で測る、AIネイティブ開発への段階的な挑戦

ここからAI DevOpsの生産性をどう考えるかという話題です。生産性はまず時間で測るのが良いと考えています。ここに挙げているサービス復元時間は、Four Keysなどでも知られていて、既に利用している、記録しているというチームもあるかと思います。これはもっとシンプルに、例えばタスクがクローズするまでの時間、不具合が解消されるまでの時間といった、チームが納得する指標に代替することでもいいと思います。この時間は目標値とするのではなく、サービス復元までの時間が減っていることが見られれば、AI導入の効果が出ている、そういったチームの状態や傾向を捉えるために利用します。

ではAI支援で生まれた空き時間を、生産性向上へ再投資できているかというのが、開発生産性を語る上で考えたい点です。時間を投資する対象として、安全な変更を実現するための改善を挙げています。レガシー側に求められる対応、新しい価値としてのAIネイティブ開発への挑戦、この2つを挙げています。安全に変更ができるようになると、開発チームに自信が生まれます。開発者体験の向上につながり、そこで好循環が生まれると考えています。ここで安全に変更できることと生産性がつながります。

レガシーであってもAIネイティブ開発に挑戦するべきというのが次の話題です。AIエージェントが開発の主担当となるAIネイティブ開発に挑戦していきたいというのは本当によく聞くことですし、すでに実践されている方も多いと思います。ただし、止められないレガシーシステム本体にいきなり全面適用するのは非常にリスクが大きいです。そこで変更影響を限定して結果を検証しやすい領域を段階的に切り出し、AIネイティブ開発に挑戦していく、トライしていくというのを推奨しています。

ただし切り出すといっても、ここは移行に関わる大きな話で、難しい意思決定が必要になる場合があります。業務を止めずに切り出せる範囲はどこにあるのか、切り出した後にそのまま移行するのか、最終的には全て移行するのか、それとも新規を維持するのか、こういった意思決定をした上で方針を決めないと、ただ単に複雑さが増すといったことにもなりかねません。

そういったハードルがあったとしても、ここまでAIを活かしてこれたチームであれば、AIネイティブ開発にトライするという価値は十分にあると考えています。大事なのは、将来の方針を持ちながら試せる場所を見つけて、まずやってみることです。

こちらはAI DevOpsの成熟度モデルを、レガシーシステムでどう使うかという表です。チームの現在地は今どこにいるのか、次にどんな改善を目指さないといけないのか、それを決めるためのものです。

• Lv0（属人的・場当たり対応）：個人が単発相談やコード補完を試す段階。次に目指すのは開発・運用を見える化すること
• Lv1（DevOps最小基盤あり）：Issue要約やPR説明文の下書き、修正案生成を行う段階。次に目指すのは記録品質を揃えること
• Lv2（AIがプロセスに入り始める）：ログ要約や関連Issue検索、影響範囲整理を行う段階。次に目指すのは障害対応をチーム標準化すること
• Lv3（AIとナレッジが結びつく）：過去障害検索や再発防止案、ナレッジ下書きを行う段階。次に目指すのは判断にナレッジを組み込むこと
• Lv4（安全に変更できる）：AIネイティブ開発やE2E・テスト作成、影響範囲チェックを行う段階。次に目指すのは安全な変更を増やすこと
• Lv5（目標達成へ貢献する）：KPI・仮説・検証結果から要求改善を支援する段階

例えば、AIで要約をしている、調査のレポートを作成している、ただし対応結果が知識として循環していない、再利用できていないということであれば、次はナレッジ化、ナレッジの整備、記録の品質の担保が目標になります。その状態で高度な開発エージェントを導入しても、効果が薄いということを示しています。

AI DevOpsが発展すると、AIと人両方に使えるナレッジが溜まっていきます。業務ドメインの理解、仮説検証ループを安全に高速に回せる状態になります。試せる仮説の数が増え、問題修正能力も高まっていきます。その結果としてビジネス目標への貢献が見えてきます。この状態では、目標達成までの時間が生産性の指標になると考えています。

まとめます。AI DevOpsとは、AIに開発を任せることではありません。チームとAIがナレッジとともに成長する仕組みです。レガシーへのAI活用は3つのステップで進みます。1つ目は障害対応の調査からAI活用を始めること、2つ目は時間を生産性の指標に置くこと、3つ目は安全に変更できる領域を作り、AIネイティブ開発を試すことです。得られるものは、開発へのナレッジ、安全に再投資できる時間、仮説検証を安全に早く回す力、そしてAIネイティブ開発の経験です。この3つを段階的に進めることが、レガシーを止めずに進化させる道です。

最後に、私たちがお手伝いできることを紹介して終わります。AIツール導入だけではなく、現在地の診断、AI DevOpsのプロセス設計、コンテキスト基盤の整備、E2Eや品質保証、そしてAIネイティブ開発の挑戦まで一気通貫で支援できます。レガシーを止めずに進化させる、そのためのAI DevOpsを一緒に見つけ始めていければと思います。ここから後半は、既存システムを活かしながら、その周辺で必要となる業務アプリをAIを活用して開発・運用できるプラットフォーム『Retool』の紹介へと移ります。

Retoolとは何か——3つのポイント

石黒：ここから後半のRetoolのパートとなります。

Retoolは端的に申しますと、業務アプリを早く作るだけではなく、本番運用につなげ、継続的に改善していくためのAIネイティブな開発基盤です。今日はAI時代に求められる開発スピードと、企業利用に欠かせない品質やガバナンスをどう両立するかという観点でご紹介したいと思います。

改めまして、株式会社GxPの石黒と申します。GxPはRetoolの国内唯一のオフィシャルパートナーであり、私は日本市場におけるRetoolの事業を牽引しております。当社は2020年から、日本企業のRetoolの導入と活用を支援してきております。本日は単なる製品紹介ではなく、日本の企業がRetoolを開発基盤として活用する際のポイントを、導入や運用の実務目線でご紹介します。

Retoolとは、企業の既存のデータにつながり、業務アプリを素早く作り、企業の管理下で運用するためのAIネイティブな開発基盤です。ポイントは3つあり、この3つを1つの基盤で扱えることになります。1つ目は、既存のデータベースやAPI、SaaS、基幹や分析基盤など、企業がすでに持っていらっしゃるデータ資産につながることです。2つ目は、管理や申請、照会、更新といった業務アプリをRetoolで短期間で形にできることです。3つ目は、権限や監査、環境分離などをアプリごとに後付けすることなく、基盤側で管理できることです。つまりRetoolは、AIでアプリを生成して終わるだけではなく、既存のデータへの接続、アプリ開発、企業としての統制までを一体で支えるプラットフォームとして考えていただければと思います。

Retoolで実現できる3つの領域と、開発基盤として選ばれる理由

Retoolでは大きく3つの領域を1つの基盤で素早く形にできます。1つ目は業務アプリです。既存のデータを使って、ウェブアプリやモバイルアプリの業務画面を高速に構築できます。例えば管理画面や問い合わせ対応の画面、ダッシュボードなんかも該当します。2つ目は業務オートメーションです。Retoolではこちらをワークフローという機能で呼ぶのですが、承認や通知、更新、バッチ処理などをつなぎ、定型業務を自動化できます。業務アプリの画面から人が操作するだけで、バックエンド側の処理まで含めて組み込めることが特徴です。

3つ目はAIエージェントです。社内のデータや業務ツールにつながり、担当者の判断を補助するだけでなく、必要な業務処理の実行まで支援が可能です。Retoolでは、ユーザーが使う業務アプリ、バックエンドで動くワークフロー、AIエージェントによる判断や実行を別々の仕組みに分断せず、1つの基盤として構築・運用することができます。

次に、Retoolがなぜ企業の開発基盤として使えるのか。ここが本日お伝えしたい中心のポイントとなります。今はアプリ単体を素早く作るだけなら選択肢はたくさん増えております。しかし企業で重要なのは、作ったものを使い続けられるかということです。そのためには、既存データへの接続、権限管理、監査や環境分離、本番運用までを含めて考える必要があります。どうしてもAIを活用してPoCで終わってしまっているという話はよく伺います。

Retoolは既存のデータベースやAPI、SaaSに直接つながります。データを別の場所に移すことを前提とせず、今あるデータの資産をそのまま活用できます。もちろんPoCなどのフェーズでRetoolのデータベースを使うことも可能です。

また、基幹システムの外側にある業務画面を簡単に実用化できます。例えば基幹システムに直接手を入れるとなるとコストも時間もかかりますし、現場では毎日使う管理画面や確認画面、更新画面が不足しているというシーンなどに適用できます。さらにシングルサインオンやRBAC、監査ログなど、企業で運用するために必要な権限管理や操作履歴の仕組みもプラットフォームとして備えております。Gitとの連携、環境分離、セルフホストといった本番運用や統制に合わせた拡張も可能です。
※一部機能は契約プランや提供環境によって利用可否が異なります。

Retoolがガードレールとして必要なセキュリティとガバナンスを効かせながら運用できるということです。そのため、小さく始めた業務アプリをPoCでは終わらせず、本番運用につなげ、部門や全社へ広げていきやすくなります。作る速さだけではなく、継続、統制、拡張までを一つの土台で扱える、これがRetoolを単なるアプリ開発ツールではなく開発基盤として見ていただきたい理由です。

ユースケースとAI時代の開発体験

では実際にどのような業務から始めやすいのかという視点で、いくつかのユースケースをご紹介します。Retoolが特に力を発揮するのは、基幹システムそのものを置き換えるということではなく、その外側で現場が毎日使う業務画面の開発です。

• 顧客・在庫・案件を横断して確認・更新する管理画面

• 申請や確認、承認、通知を一つにつなぐアプリ

• 複数のデータベースやSaaSから必要なデータを集める照会の画面やダッシュボード

• Excelやスプレッドシートで属人化している台帳や定型作業を、画面や権限、履歴で標準化するアプリ

さらにそこにAIを加えることで、過去データを参照した判断基準の提示や、担当者の確認後に処理を実行するという仕組みも作れます。重要なのはこれらを別々の製品に分断しないことです。既存データを活かしながら、画面、処理、AIを一連の業務としてつなげられる、ここがRetoolの特徴です。

ここからはAI時代のRetoolの開発体験です。Retoolでアプリを構築するステップとして、まずはPrompt、自然言語や要件定義などのファイルからアプリの最初の形を作ります。ゼロから画面や処理を組み立てる時間をここで大幅に短縮できます。次に、Editです。生成されたものをそのまま使うのではなく、現場のルールや使い勝手に合わせて、できた画面上で修正します。項目を追加する、表示を変える、処理条件を調整する、AIが作った最初のものに対して人が業務知識を反映していく段階です。

そしてExtend、さらに細かな要件はSQLやJavaScript、必要に応じたカスタム実装で拡張ができます。AIで作って終わりではなく、人が確認し、修正し、必要に応じてコードで拡張することが可能です。作ったものはRetool上で確認、修正、拡張し、そのまま本番運用へつなげることができます。つまりAIで初速を上げ、人が業務知識を反映し、高度で細かな要件に対応する、AIで作って終わるのではなく、同じ基盤上で確認・修正・拡張し、そのまま本番運用につなげられることがRetoolの価値だということです。

提供環境と導入実績、GxPの支援体制

提供環境を選べることも特徴の一つで、ユニークな点です。大きく2つの提供環境があり、RetoolがホストするSaaS環境と、お客様のパブリッククラウドに配置するセルフホストの2つです。導入のスピードをSaaSで優先するのか、環境の分離や運用のコントロールをどこまで自社で持つのか、その方針などによって環境を選べるということです。

そのため、セキュリティや運用ポリシーが明確かつ厳格な大企業でも、要件に合わせた導入設計がしやすくなっております。

Retoolは2018年にローンチしたプロダクトですが、すでに日本を含めて世界で1万社以上で利用されています。単に新しい技術を試すだけの実験ツールではなく、多くの企業で業務アプリの開発基盤として選ばれているプラットフォームです。製造、金融、医療、小売、テック企業など様々な業種で利用されています。

日本国内でも、業務アプリ開発や内製化というテーマ、部門業務の効率化などの目的で活用が進んでいます。すでに多くの企業が選んでいるプラットフォームですので、企業の開発基盤として検討する上で、この利用実績は重要な安心材料になるのではないでしょうか。

当社はRetoolの国内唯一の公式パートナーとして、Retoolの導入から定着までを伴走させていただいています。ライセンスを契約すればすぐに使い始めることのできる製品ではありますが、企業の中で本格的に活用していくには、どの業務から始めるのか、誰が作るのか、どのように権限や運用ルールを設計するのかといった整理が非常に重要になります。

よくあるケースとしては、どの部門や業務から始めるのか、PoCで何を確認すべきかを整理し始めます。その後、本番運用を見据えた権限設定や運用ルールというガバナンスをRetoolで整理し、さらにリリース後の改善サイクルをどうしていくかといった、あらゆるフェーズで当社もご支援させていただいております。

GxPは『AIで作る速さを、企業で使い続ける力へ。』をコンセプトに、Retoolの導入から定着までを支援しています。 本日はご清聴誠にありがとうございました。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画はこちら

※動画の視聴にはFindyへのログインが必要です。