プラットフォーム要件定義 

要件定義 基本から考える 何を解決するための手段としてプラットフォームを定義するのか (私の個人的な視点からの考えです) 業務を効率化 組織を強化 会社の目的を 達成する 

概念では何が近いか（ 引用） データの集積・活用と LLMの連携を含む概念  Data Intelligence データの文脈を AIが理解し、高度なインサイトを生成 する概念  データプラットフォーム LLMとデータを繋ぎ込み、組織全体の基盤となるシス テム構成 Key Components / 主要要素  Data Assets データウェアハウス、データレイク、業 務システム、SaaS、ログなど、企業が 保有するあらゆる構造化・非構造化 データ  Metadata & Catalog データの意味・定義・型・生成元・変換 履歴・利用履歴などを表すメタデータ と、それらを横断的に検索・探索でき るデータカタログ  Governance & Quality 誰がどのデータにアクセスできるの か、どのようなルールで利用・共有・保 管するのか、法規制との整合性確保 といった枠組み 

Phase1 記録と可視化の基盤づくり palantirを例に考えます 

データインテリジェンスについて 

Observability（可観測性） AI Observability / Agent Observabilityなどの言葉で定義され始めている 一般的な言葉では、広義にはなるがLLMOpsというのがある。 

LLMOps データの資産化と性能改善 - 利用状況に合わせて、可用性を 向上させるためのシステム構成 の見直し - ニーズの高いタスクに対する業 務特化のボットを開発する。 Q. ユーザーは、どのよ うなチャット（ビジネスタ スク）をすることが多い か？ Q. チャットの生成速度 は、十分条件に達して いるか？ 問い合わせ 

オントロジーとは 

AI Observability の例(引用) ● Context Relevance: 検索サービスやリトリーバから取得したコンテキストが、ユーザーのクエリに適切かどうかを評価します。 ● Groundedness: 生成された回答が、取得したコンテキストに裏付けられているか（事実に基づいているか）を測定します。 ● Answer Relevance: 生成された回答が、ユーザーの質問にどれだけ関連しているかを評価します（正解ラベルがなくても評価可能）。 ● Correctness: 生成された回答が、与えられた正解（ ground truth）にどれだけ整合しているかを測定します。 ● Coherence: 回答全体が論理的に一貫し、矛盾や飛躍がないかを評価します。 

データ基盤とAIを繋げる 引用 

Phase 02 RAGで扱う候補（コンテキストレイヤー）  扱うデータの候補 ● slack、メール、会議などの会話データ（非構造化データと呼ばれる） ● LLMの使用状況 ● 承認履歴  この辺はどの業務を効率化するか、品質を上げるかというスコープを定義しないと決めることがで きないと判断しました。 

Phase 02 AIによる業務品質の継続的向上  品質劣化・手戻りの削減 文脈不足や属人化に起因する課題を解消し、業務 プロセス全体の安定化を図ります。  AIによる継続的な実行 ● 会議整理・論点抽出 ● レビュー準備の自動化 ● ドラフト作成の支援 

自律学習サイクル - human reflection（実装：langsmith automation rule） - self-reflection 

エージェント基盤のプラットフォーム 承認フローやRAG、自律学習サイクルを回すことができるもの - Dify - Langchain系列　 

具体的な業務 これに関しても、データ同様に、何を効率化するか決めていないため、ここで話しません 

プラットフォームエンジニアリングと社内ツール AppSmith： 社内ウェブツール作成のローコードツール AIエージェントのUIに使える可能性がある DEVELOPMENT ENVIRONMENTSについて プラットフォームエンジニアリングの観点で 説明できそうです。今回は省きます 

現状の承認フロー IDPツールとしてBackstageを 導入しています AppSmithをエージェント基盤の インターフェースとして活用 社内ポータルに統合可能です 

参照資料 パランティア アーキテクチャ図