はじめに
業務の効率化が求められる中、既存プロジェクトの保守対応にAIを活用する取り組みを始めました。実際に導入したAIツール「Cursor」と弊社内で開発しているAIツール「Inherit」を比較し、それぞれの特徴や使い勝手について検証を行いました。本記事では、実際のユースケースを交えながら、両ツールの活用方法と今後の展望についてご紹介します。
活用対象：金融機関向け「持株会管理システム」
今回、AI活用を実施・検証したのは、ある金融機関向けに構築したシステムです。本システムはすでに本番稼働しており、日々の運用の中で定期的な保守対応や小規模な機能改善が求められています。こうした継続的な保守作業に対し、AIを活用することで効率化と品質の両立を図ることを目的としています。
本プロジェクトには、以下のような特徴があります：
- インフラやソースコードはすべて自社で管理
- 開発当初に作成された以下のドキュメントが存在
- 設計書
- DB定義書
- 関連ドキュメント
※ただし、これらの資料は古くなっており、GitリポジトリやGoogle Driveなど複数の場所に分散しています。
こうした背景を踏まえ、AIが過去の仕様や現行コードをもとに開発者の理解を支援し、保守作業の効率化に貢献できるのではないかと考え、実証的な検討を開始しました。
比較実験：CursorとInheritに同一プロンプトで問い合わせてみる
今回使用したAIツールは、コードリーディングや技術理解に優れた「Cursor」と、文書構造や業務視点の整理に強みを持つ「Inherit」です。それぞれに同一のプロンプトを入力し、どのような回答が得られるかを比較・検証しました。
※なお、今回の検証では実際の設計資料やドキュメントをAIに読み込ませることは行っていません。今後の活用に向けた第一ステップとして、ソースコードや設定ファイルなど、現時点で参照可能な情報をもとにプロンプト対話を行っています。今後はドキュメント連携も含め、より実践的な活用に発展させることを視野に入れています。
プロンプト例1：「持株会全体の評価損益を把握したい。その方法を提案してほしい。」
- Cursorの回答
プロンプト例1では持株会全体の評価損益を把握する方法について問い合わせました。「Cursor」は、質問に対して基本的な考え方を整理し、SQLクエリやAPIエンドポイントの実装例を提示した上で、考慮すべきポイントを明確にしてくれました。
- Inheritの回答
一方「Inherit」は、初回に「申し訳ありません」と断りがあり、指示の方法を教えてくれました。具体的なコードを指定するか、ファイルやディレクトリを指定して問い合わせる必要があるとのことなので、続けて対象のAPIについて概要を出してもらい、そのAPIをもとに 明示して欲しい情報を指示しました。
プロンプト例2：「株価更新処理を毎日実施したい。そのために必要なことを教えてほしい。」
- Cursorの回答
まず、実施方針の提案があり、実装内容、データ取得先の選定、データベース設計について提案がありました。追加で、特定のテーブルについて問い合わせをし、必要な情報を整理しました。
- Inheritの回答
自動実行するためのステップを列挙してくれました。そもそも「Inherit」に対するプロンプトとしては大まかだった（適切ではなかった）ので、「Cursor」とは異なる指示をする必要があると判断しました。そこで、特定のステップに対して設計書を作成するように指示を出しました。
プロンプト例3：「会員がサインアップする仕組みと、どんなチェックがかかっているかをまとめてほしい。」
- Cursorの回答
サインアップに関係するAPIについて問い合わせました。「Cursor」はソースコードを基に、仕組み・チェック内容・パラメータについて整理してくれました。
- Inheritの回答
「Inherit」では、概要・リクエスト方法・レスポンスについての回答がありました。具体的な処理というよりは、APIの使用方法が分かる内容になっていました。
まとめ
これらのやりとりを通じて見えてきたのは、各AIツールが得意とする領域に明確な違いがあるという点です。「Cursor」はソースコードに密着した実装レベルでの具体的な提案や解決策に強みがあり、技術的な対応に非常に有効です。一方、「Inherit」は業務フローの整理やドキュメントの構成、内容の分かりやすい説明といった、より上位の視点でのサポートに優れていると感じました。
実務活用の所感と今後の方向性
AIとの対話は単なる一問一答ではなく、初回の回答を起点として追加の質問を重ねながら、段階的に理解を深めていく形式で実施しました。このように会話を積み重ねることで、開発者の思考の流れや疑問に寄り添った回答が得られ、結果としてAIが補助的なドキュメントとして機能する可能性を強く感じています。従来の静的な資料とは異なり、必要に応じて柔軟に情報を引き出せる点が大きな利点です。
現時点では、AIには実際の資料を読み込ませていないため、得られる回答はコードと仮定に基づいたものに限られています。ただし、今後は以下の方針で活用範囲を拡大していく予定です：
- ソースコードをもとに最新の設計資料・仕様をAIと協力して再構築する
- 既存の設計書やDB定義書などをAIに読み込ませ、最新情報との比較・整理を行う
- 業務担当者との認識齟齬を減らすため、AIによる中間ドキュメント生成を取り入れる
特に保守業務では、現場の担当者が開発時の文脈を知らないケースもあるため、AIが過去と現在の橋渡しをしてくれることに大きな期待を寄せています。
今後の展望：AIは“仕様の断絶”を埋める存在になり得るか
今回の検証を通して、AIが「ソースコード」と「業務仕様」のギャップを埋め、保守対応の効率化に貢献できる可能性を強く感じました。「Cursor」と「Inherit」は、それぞれ異なる角度からプロジェクト理解を支援してくれるツールであり、場面に応じて最適な使い方があることも見えてきました。「Cursor」と「Inherit」の特性を把握し、状況に応じて使い分けることで、効率的かつ確実な保守体制を構築できるのではないかと考えています。
とはいえ、今回の検証は、AIに十分な情報（ソースコードや既存資料）を与えずに行った初期段階の試みに過ぎません。本格的な活用には、以下のようなステップが必要です。
今後のアクションとして以下のようなことを検討しています：
- AIにソースコードを読み込ませ、現時点での仕様や処理内容を整理する
- 既存の設計書やドキュメントも順次AIに読み込ませ、差分や重複を整理
- 業務観点で必要な情報を抽出し、保守・運用に活用できる資料へと再構成
- 社内の知見をAIに蓄積・共有する運用フローの設計
こうしたステップを進めることで、AIを“都度使う道具”から“業務に組み込まれた支援者”へと進化させることができると考えています。
ドキュメントと実装のズレを解消し、誰もが迷わず保守や改善に取り組める環境づくりを、AIと共に進めていきたいと思います。
AIエージェントの導入をお考えの方はお気軽にお問い合わせください！
「Inherit」は社内で管理されているソースを元に概要をまとめてくれるAIツールです。弊社のエンジニアが開発しました。今回はslackチャンネルでやり取りができるようにしています。
アイスリーデザインでは、クラウドネイティブ基盤とデザインシステムに、Cursor・Windsurf・Devin などのAI開発エージェントを掛け合わせ、次世代型のモダナイズ開発スタイルを実施しています。
＞ アイスリーデザインのAI駆動開発支援