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

田中さんは、ある中堅SIerのDX推進室に所属するバックエンドエンジニアだ。

担当しているプロジェクトは、社内業務をマイクロサービス化する大型案件。Scala 2.13でバックエンドを構築し、FlutterでモバイルクライアントのUIを作るという構成だった。

その朝、彼のSlackにメッセージが届いた。

「田中さん、昨日定義したUserResponseのupdatedAtフィールドですが、FlutterのDateTimeとScalaのLocalDateTimeで扱いが違うらしくて…シリアライズがうまくいきません」

あなたにも、こんな経験がないだろうか。

設計書を書いた。レビューも通った。なのに、実装フェーズで「そういう意味じゃなかった」が起きる。

ScalaのCirceがどうエンコードするか。DartのjsonSerializableがどう解釈するか。どちらの担当者も悪意はない。ただ、言語が違えば、型の「常識」が違う。

これは、バグではない。構造的な認識ズレだ。

田中さんのチームでは、この種の手戻りが週に2〜3件発生していた。

その日の午後、田中さんはKnowledgeLMのマイクロサービス開発支援エージェントに、こう入力した。

コード生成をして

エージェントは即座に動いた。

以下は、実際に生成されたコードの一部だ。

【会話引用】

田中：コード生成をして

エージェント：
以下に、KnowledgeLM の Bounded Context「AM（AIエージェント管理コンテキスト）」
に対応する Scala 2.13 コードを生成します。

田中さんは画面を見て、少し止まった。

「……これ、自分が書こうとしていたものと同じだ。いや、もっと整理されている。」

エージェントが生成したのは、型定義だけではなかった。

• ドメインモデル（MetaAgentInfo、Agent、PromptTemplate）
• JPAエンティティ（MetaAgentEntity、AgentEntity）
• Repositoryクラスと検索パラメータ
• アーカイブ・ソフトデリートのライフサイクルメソッド
• 所有者変更時の子エンティティへの伝播ロジック

さらに。コードには日本語のScaladocが丁寧に添えられていた。

▶️ 実際の会話シーン

田中さんが感じた違和感——いや、驚きの正体は何だったか。

エージェントが「なぜそう設計するか」を知っていた、ということだ。

たとえば、AgentDataSourceEntityというクラスを見てほしい。

これは、DDDにおける**境界づけられたコンテキスト（Bounded Context）**の考え方を忠実に実装している。「DSコンテキスト（データソース管理）のドメインオブジェクトに依存してはいけない」という設計判断を、エージェントは自ら下した。

エンジニアが「UUID参照だけ持て」と命令したわけではない。エージェントが、マイクロサービスアーキテクチャの文脈から判断したのだ。

これは、サジェストでもなく、補完でもない。設計パートナーとしての振る舞いだ。

ここで少し立ち止まって、KnowledgeLMの仕組みを説明しておきたい。

「専門知識（固定テキスト）」という機能がある。

これは何か。簡単に言うと——自分たちのチームのコーディング規約、設計ドキュメント、過去のコードサンプル、APIの命名規則。そういった社内固有の知識をテキストとして登録し、AIエージェントに”読ませておく”機能だ。

料理で言えば、「このエージェントには、うちのレシピ本を渡してある」状態になる。

田中さんのチームは、jp.co.kfield.quickbizというフレームワーク固有の規約や、ID[T]という基底クラスの使い方を固定テキストとして登録していた。だからエージェントは、汎用的なJPAの書き方ではなく、このチームの流儀でコードを生成できた。

登録方法は、難しくない。[ 専門知識 ]パネルの[ 追加 ]ボタンを押して、種類に「固定テキスト」を選び、テキストをペーストして保存するだけだ。

▶️ チーム固有のコーディング規約をエージェントに読み込ませるシーン

その日の夕方、田中さんは生成されたコードをベースにFlutterのDartモデルを起こした。

LocalDateTimeはISOフォーマットの文字列として扱い、Dartではjson_serializableに合わせてfromJson/toJsonを実装する。エージェントが生成したScalaのCircceエンコーダーと対応するDartの型を突き合わせると、変換ルールが一目で把握できた。

「前は、ScalaとDartの担当者がそれぞれ実装してから”突き合わせ”をやっていた。今は、ScalaのコードをAIが生成する段階で、Dartとの整合性を意識した設計が出てくる。」

手戻りが起きていた「週2〜3件の認識ズレ」は、この週はゼロだった。

専門知識（固定テキスト）

• コーディング規約・設計方針・サンプルコードを直接テキストとして登録できる
• 登録した知識は、エージェントがコード生成時に参照する”文脈”になる
• ファイルアップロード不要で、コピー＆ペーストだけで即時反映される

情シス責任者の視点

生成したコードの元になった「専門知識」は、KnowledgeLM内に保管される。外部の生成AIサービスに社内の設計ドキュメントやコードが送信される心配がない。誰がどのエージェントをいつ使ったか、統計情報で把握できる。「シャドーAI」のリスクを排除しながら、現場の生産性を落とさない。

営業現場リーダーの視点

（前提：営業支援のSaaSを内製している組織を想定）開発チームの立ち上がりが速くなると、新機能のリリースが早くなる。現場が使うシステムの改善スピードが上がり、顧客対応の質が高まる。エンジニアへの「ちょっとこれ直して」依頼の待ち時間が短くなる実感がある。

DX推進メンバーの視点

チームに特定のエースエンジニアがいなくても、設計品質が一定水準を保てる。専門知識に規約を登録しておけば、新メンバーでも「このチームの流儀」でコードが書ける状態になる。属人化の解消と、全社展開の両方が同時に進む。

田中さんが体験したのは、「AIがコードを書いてくれる便利さ」ではなかった。

設計の意図が、コードという形で正確に伝わる体験だった。

ScalaのADTとDartのnull safetyが、境界を越えて整合する。それを可能にしたのは、エージェントに社内の設計規約という「文脈」を与えたからだ。

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

KnowledgeLMは、そういうツールだ。

あなたのチームのコーディング規約を、今すぐエージェントに読み込ませてみてほしい。