マイクロサービスを開発する際のデータ構造、
バックエンドAPI定義を支援。
バックエンドの実装はScala2.13,
スマートフォンアプリはFlatterを使用する

田中さんは、中規模SaaS企業でバックエンドアーキテクトを務めるエンジニアだ。

Scala 2.13でマイクロサービスを設計し、FlutterチームにAPIの仕様を渡す。それが彼の毎日だ。

問題は、その「渡す」という行為にある。

「バックエンドで case class を定義したのに、FlutterのDartモデルと微妙にズレてる」
「OpenAPIの定義、誰が最新版を持ってる？」
「このエンドポイント、ページングどうするんでしたっけ？」

こういったSlackのメッセージが、深夜に飛んでくる。設計書を書いた本人が、設計書の解釈を問い合わせられる。

そのたびに田中さんは思う。「自分は何のために、あの仕様書を書いたんだろう」と。

ある日、田中さんはKnowledgeLMに搭載されたマイクロサービス開発支援エージェントを試してみた。

起動して最初に送ったメッセージは、たった6文字だった。

分析を始めて

▶️ 実際の会話シーン

エージェントは止まらなかった。

AIエージェント（マイクロサービス開発支援）：
ありがとうございます。分析を開始します。まず、対象のマイクロサービス群の概要と、現在どのような設計課題や曖昧点を抱えているかを教えていただけますか？たとえば「ドメインモデルの境界が不明確」「FlutterとScala間のAPIデータ契約が安定しない」といった状況があれば、そこから整理を始めます。

田中さんは手元にある**KnowledgeLMの機能仕様書（DDDのアクター一覧・バウンダリコンテキスト・ユースケース一覧）**を、エージェントの「専門知識」として事前に登録していた。

つまり、このAIはすでに「自社プロダクトの設計ルール」を理解した状態で動いている。

ここで少し立ち止まって、この仕組みの凄さを解説しよう。

一般的な生成AIは、「Scalaの設計を手伝って」と聞けば、一般論で答える。教科書的なCats/Circeの使い方、一般的なRESTful設計のベストプラクティス。それはそれで有用だ。

でも、田中さんが本当に欲しいのはそれじゃない。

「自社のKnowledgeLMというプロダクトの、このバウンダリコンテキストに対する、ScalaのADT設計とFlutter向けのDartモデルが欲しい」、という極めて具体的な問いへの回答だ。

KnowledgeLMの専門知識追加（プライベート・バインダ）機能を使えば、それが実現する。

自分が作成したノート（設計書・仕様書・議事録・DBスキーマなど）をバインダにまとめ、エージェントの専門知識として登録する。AIは以後、その知識を前提として回答する。

まるで、自社の設計コンテキストをすべて把握したベテランアーキテクトが、いつでも対話できる状態になるようなものだ。

田中さんとエージェントの会話は続く。

田中さん：
Conversation Context（会話コンテキスト）の設計を整理したい。バックトラック機能の実装に使うScalaのADT定義と、Flutter向けのDartモデルを出してほしい。

AIエージェント（マイクロサービス開発支援）：
承知しました。Conversation Context の バックトラック 機能では、会話スレッドが複数のトラックに分岐する構造が中心になります。以下の方針で進めます。

Scala 2.13 側の ADT 設計（Circe + sealed trait）：

Flutter（Dart）対応モデル（null safety 準拠）：

parentId を Option[TrackId] / String? にすることで、ルートトラック（分岐元）と派生トラックを統一的に扱えます。バックトラック操作時はこの parentId を辿って分岐ツリーを再構築します。
ページングやソート方針も必要であれば続けて設計します。

田中さんは画面を見つめた。

「これ、そのままPRのコメントに貼れる」

ここで紹介した機能を、もう少し丁寧に説明しよう。

専門知識追加（プライベート・バインダ）とは、あなたが積み上げてきた社内知識を、AIエージェントの”記憶”として組み込む機能だ。

設計書・仕様書・議事録・過去のレビューコメント・DBスキーマ──これらをKnowledgeLMの「バインダ」にノートとして保存し、エージェントの専門知識として登録する。

AIはその知識を参照しながら回答する。一般論ではなく、あなたの文脈で答える。

Excelのシートも、MarkdownのREADMEも、PDFの仕様書も対応している。ファイルをアップロードするだけで、AIが読み込む。

▶️ AIエージェント作成シーン

エージェントとの会話から生成されたScalaのケースクラス定義、DartのFromJsonロジック、OpenAPIの雛形。それらをドキュメントに転記し、チームのConfluenceに貼り付けた。

翌日、Flutterエンジニアの山本さんからこんなメッセージが来た。

「田中さん、今日の仕様書めちゃくちゃわかりやすかったです。Dartモデルもそのまま使えました」

その夜、Slackは静かだった。

専門知識追加（プライベート・バインダ）

• Markdownノートや各種ファイル（PDF・Word・Excel・PowerPoint等）をバインダに保存し、AIエージェントの専門知識として登録できる
• データの「性質ラベル」（公式規定・手順・用語定義など）と「データを与える意図」（絶対的なルール・ステップバイステップの実行指示など）を設定することで、AIの回答精度をさらに高められる
• プライベートスコープで自分だけの専門知識を構築でき、情報が外部に漏れない安全な環境で運用できる

情シス責任者の視点

社員が勝手に社外のAIに設計書を貼り付ける「シャドーAI問題」が、根本から解決する。KnowledgeLMはプライベートスコープで知識を管理し、誰が・どのモデルを・いくら使ったかを統計情報として一元把握できる。APIキーはシークレット管理機能で安全に保存される。統制を諦めずに、現場の活用を進められる。

営業現場リーダーの視点

エンジニアが「仕様の説明」に使っていた時間が、「開発」に変わる。会話から設計書の雛形が生まれ、バックエンドとモバイルの認識ずれが起きにくくなる。現場が自分で作れる速さが、そのままプロダクトの前進速度になる。

DX推進メンバーの視点

「エンジニア向けのAIツール」は、他にもある。でも、自社の設計書・仕様書・アーキテクチャルールを食べて動くAIエージェントを、エンジニア自身がノーコードで構築できるプラットフォームは、ほぼない。全社展開のフェーズで「エンジニア部門の定着事例」を作りたいなら、ここから始めるのが最速だ。

あなたのチームの設計コンテキストを、AIが理解したら何が変わるか。

深夜のSlack質問が減る。認識ずれによるリワークが減る。エンジニアが本来集中すべき「思考」に、時間が戻ってくる。

KnowledgeLMのマイクロサービス開発支援エージェントは、自社の知識を専門知識として取り込み、あなたの文脈で動く。それが、汎用AIとの決定的な差だ。

統制が強いほど、活用も広がる。現場は止まらない。