AI駆動開発を本番化するには。Scalar深津氏が語るモダナイゼーションの要点
2026年5月14日に開催された「Kong AI Connectivity Day in Fukuoka」に、株式会社Scalar 代表取締役CEOの深津航氏が登壇。「エンタープライズAIエージェント実装の『最前線』と『落とし穴』」と題し、特別講演を行いました。
本記事では、実プロジェクトで得られたAI駆動開発の知見と、AI時代に企業システムをどのように設計すべきかをレポートします。
目次
AI駆動開発の成果は開発スピードの向上
深津氏が代表取締役を務める株式会社Scalar（以下、Scalar）は、東京と札幌に開発拠点を持ち、さらに東京とサンフランシスコで営業を展開するデータマネジメント領域のソフトウェア企業。「データマネジメントの未来を創る」というビジョンのもと、ScalarDBとScalarDLを主力製品として、複雑化したデータベースシステムの管理やデータ活用を支援しています。
講演で中心的に取り上げられた同社の「ScalarDB」は、マイクロサービスのトランザクションやデータの仮想化で利用される製品です。深津氏は、ScalarDBについて「AIとの親和性が良い」と説明し、メインフレームのモダナイゼーション、SaaSを構築する仕組み、AIを使った開発などで活用されていると述べました。
その中でも深津氏が特に強調したのが、AI駆動開発での活用です。
AI駆動開発とは、AIエージェントや生成AIを開発工程に組み込み、調査、設計、実装、テスト、保守の一部を支援させる開発手法です。深津氏が具体例として紹介したのは、マルチテナント型SaaSシステムで巨大なモノリスをマイクロサービスへ再構築したプロジェクトでした。このシステムは複数の顧客がすでに利用しており、長時間の計画停止が難しい環境。その中で、約1年をかけてインフラを止めずに移行を進めたと言います。
AI駆動開発による成果として、開発スピードの向上も示されました。深津氏は「UIが2人月あたり十数画面、マイクロサービス上でのAPIが3人月で200 APIぐらいで開発できた」と説明しました。また、バージョンアップやパッチ適用については「1人日で完了した」としています。
レガシーモダナイゼーションの事例では、調達システムのリファクタリングにも言及。深津氏は「通常200人月近くかかる調査が2日で終わっている」と述べ、プロトタイプ開発も約1週間で終わっていると紹介しました。
さらに、Scalar社内でのAIの適用実績も開示。現行システム分析から要件定義、設計、開発、テスト、保守・運用まで、幅広いAIの適用領域が示されました。深津氏は、あるプロジェクトでは「すべてプロンプト操作だけでシステムを作ることに成功しました」と語りました。
AIが扱える単位まで小さく分ける設計が必要
次に、深津氏はAI駆動開発の“落とし穴”にも言及しました。AIは万能ではなく、得意なタスクと不得意なタスクがあります。
講演では、Claude Codeを例に、AIが得意な領域として以下が挙げられました。
- パターンが決まっている実装
- 言語やフレームワーク間の翻訳
- リファクタリング
- 可読性の向上 など
ゴールが明確で検証しやすい作業は得意な一方で、新しいライブラリ、ニッチな技術、並列性、パフォーマンスチューニングなどは苦手な領域です。深津氏は、巨大なコード体系ではAIが正しく最適化できないことがあるため、「小さくモノを作ることが重要」と説明しました。
つまりAI駆動開発では、AIにすべてを任せるのではなく、AIが扱いやすい単位へ対象を分割することが前提になります。機能、コード、データの境界を小さく明確にするほど、AIが判断する範囲は限定されるとしました。
また、Claude Codeのモデル別に1モジュールの推奨行数や上限目安も示されました。深津氏は、1回のセッションで作れるコード量について「500〜800行ぐらい」と説明し、コンテキスト使用量についても「65%を超えるとコード品質が下がる」と述べました。
AIに大きすぎる対象を渡すと、品質が不安定になり、修正のたびに別の箇所へ影響が及ぶ可能性も指摘されました。AIを活用するには、AIが扱える単位まで機能やコードを小さく分ける設計が必要です。
開発準備工程がAIの品質を左右する
深津氏がAI駆動開発の実践方法として示したのは、AIにすべてをゼロから作らせるのではなく、最初に部品を用意し、AIに組み立てさせる考え方です。
深津氏は「AIに全部コードを書かせるわけではなく、最初に部品を作り、AIに組み立てを指示することが重要です」と説明しました。
深津氏はこの工程を「開発準備工程」と呼び、製造業における生産準備になぞらえました。開発準備工程とは、AIが実装に入る前に、部品、ルール、責務の境界、品質基準を人が整える工程です。金型を作り、そこに流し込んで組み立てていくように、AIが効率良く、かつ品質を担保しながら実装できる状態を用意する考え方だとしました。
その効果を示す実験として、POSシステムをAI駆動で開発した結果も紹介されています。従来の開発手法では推定1,220時間、開発期間6〜9ヶ月と見込まれるシステムに対し、モジュラーモノリスとして作った場合は約900時間でした。一方、マイクロサービスとして設計した場合は約56時間、開発期間は約3週間に短縮しています。
モジュラーモノリスでは、OrderServiceのような巨大なクラスに責務が集中し、変更のたびに考慮点が増えました。深津氏は、完成手前でAIがコンテキストオーバーを起こし、「指示すればするほど壊れていく状況が起きた」と説明しています。
一方、マイクロサービスでは、ドメインごとに機能を分割し、それぞれの責務を閉じることで、AIが対象範囲を理解しやすくなります。深津氏は「マイクロサービスにして分割してあげると、それぞれの領域内のインターフェースだけを見て修正していく」と述べました。
APIの役割設計でAIが扱う範囲を小さくする
AI駆動開発を安定させるには、マイクロサービスとAPIの役割設計が重要です。深津氏は、マイクロサービス化したアーキテクチャの中で、System APIやProcess APIをAIで部品として作り、その上にKong API Gatewayを配置してBackend for Frontendを作る構成を紹介しました。
資料では、Process APIはビジネスプロセスを担い、データ操作はSystem APIへ依頼する構成が示されました。このように役割を明確に分けることで、AIが実装するときのコンテキストサイズを抑えられます。
深津氏は、KongのAPIマネジメントを活用してAPIモックを作成し、AIエージェントにはそのAPIモックのみにアクセスさせながら開発を進める手法も紹介しました。
AIに対して無制限にシステム全体を触らせるのではなく、OpenAPIによる設計やAPIモックを通じて境界を明確にします。ここでのポイントは、AIの自由度を下げることではありません。AIが判断すべき対象を小さくし、品質とスピードを両立しやすい構造にすることです。
【マイクロサービスとAPIの役割を明確化し、AIが扱うコンテキストを小さくする】
開発プロセスにおける知見の蓄積が品質を向上させる
深津氏は、AIエージェントを用いた開発プロセスとして、設計の確定、実装計画、実装、レビュー、複利化の流れを紹介しました。
最初の「設計の確定」では設計の不明点を洗い出し、実装のゴールを確定させます。続く「実装計画」では、AIが課題を調査し、詳細な実装計画を立てます。深津氏は「計画プロセスにおよそ70〜90%の時間を使います」と説明しました。
計画がぶれなくなった段階で「実装」に入り、AIがコーディングとテストを進めます。その後「レビュー」で成果物を検証し、最後に「複利化」で知見を蓄積します。深津氏は、レビューで得た知見をMarkdownファイルに記録し、次回以降の実装計画フェーズで参照することで同じ失敗を防ぐと述べました。
重要なのは、AIの出力そのものではなく、次回以降に再利用できる形で知見を残すことです。この複利化によって、一度きりの改善で終わらせず、開発を重ねるごとに品質を向上させることにつながります。
Brainstorm、Plan、Work、Review、Compoundで進めるAIエージェント開発プロセス
AIエージェントにはドメインごとに分割したデータ基盤が必要
講演後半では、AIエージェントによるデータ活用の課題も取り上げられました。深津氏は、AIエージェントについて「意外なところでミスが起こる」と説明しました。
例えば、意味の取り違えやデータ品質のばらつきが起きると、ハルシネーションにつながります。深津氏は、システムをマイクロサービスとして分割するのと同じように「データもドメインごとに分割して同じ意味のものをまとめる」ことが必要だと述べました。
ここで重要なのは、データを一箇所に集めれば良いわけではないという点です。深津氏は、見方によって意味が変わるデータを集約するとAIエージェントが混乱すると説明し、「データを一箇所に集めないことがポイント」と語りました。
人間がBIツールで一度に大きなクエリを投げるのとは異なり、AIは段階的に小さなクエリを投げ、上位概念から下位データへ順にアクセスできます。
この特性を持つAIエージェントを活用するには、次の3点が必要だと言います。
- 意味の近いデータをドメインごとにまとめる
- AIがアクセスできる範囲を権限に応じて制御する
- 利用履歴を追跡し、監査できる状態にする
AI時代の運用には全体を把握できる統合基盤が不可欠
AIを前提にした開発や運用では、インフラのあり方も変化します。従来の個別システムが縦割りで構築された環境では、ガバナンスを効かせることやAPIを再利用することが難しくなります。
深津氏は、Kubernetes上にコンテナアプリケーションとして配置する構成を紹介しました。ScalarDBもKong API Gatewayもコンテナとして動作するため、同じ基盤上に配置できます。「Kubernetesのインフラを1つ運用すれば、全アプリケーションを管理できる」と説明しました。
AIを使って高速に開発を進めると、管理対象となるアプリケーションやサービスが増えます。このとき、統合された基盤で全体を見ることができれば、管理者を増やさずに運用できます。
ログや監視の観点では、Kong側でOIDCの情報と連携し、Correlation ID（相関ID）を発行することで、どのコンテナを通じて処理が行われたかを追跡できると紹介しました。ログを集中基盤に集めることで、障害発生時にもAIに問い合わせ、原因の把握や対応につなげられます。
さらに、AIの登場によって脆弱性の発見と対応のスピードも変化しています。深津氏は「今は週に1回はセキュリティスキャンを実行しないとリスクがある状況」と述べ、脆弱性チェックからパッチ作成、テスト、リリース判断までを自動化するパイプラインの取り組みを紹介しました。
【AI時代のインフラでは、デプロイの独立性と統合運用基盤が重要になる】
AI時代の人の役割はAIを活用できる構造を設計すること
講演の最後に、深津氏はAI時代に人が担う役割を整理しました。AI駆動開発では、AIが人間の仕事を単純に置き換えるのではなく、人間の能力を増幅します。
深津氏は「AIは万能ではなく、指示する人の能力を加速させる手段」と述べました。そのため、開発準備工程では、目標とするコードを生成できるようにAIエージェントを育てる必要があります。
AI時代に人間に求められる能力として、以下の視点が挙げられました。
- 機能分解力
- プロンプト設計力
- インターフェイス設計力
- AI適用判断力
- モデリング知識
- AI×DevOpsにおけるガバナンスの統合視点
AIを活用する企業には、AIに何を任せるかだけでなく、AIが安全に、正確に、再現性高く動ける構造をどのように設計するかが問われます。