IDCは、AIエージェントの普及に伴う「SaaS終焉論」を分析したレポートを公開した。AIはSaaSを代替するのではなくデータモデルを拡張すると指摘し、市場ごとの浸透格差や成果型課金の急増など、本当に起こる構造変化を解説している。
データ基盤チームが、定型の分析依頼への対応フローをAIエージェント前提に組み替えるPoCを紹介。AIに自由にSQLを書かせると結合キーの取り違えや指標定義の揺れで「それっぽい数字」が返るため、集計ロジックはdbtのymlに定義したセマンティックレイヤー（Lightdash）に委ね、AIには仕様書の解釈と言葉と定義の橋渡しだけを任せる構成にした。LightdashはOSS版をAWS上にセルフホストし、REST APIを叩く自作MCPサーバー経由でAIからexplore・チャート作成を操作する。選定理由、セマンティックレイヤーがガードレールになる仕組み、定義が網羅できない部分を補うcustomの口と昇格ループ、現時点の運用状況と展望を述べる。
個人開発の記録ツールにLLMでWikiを書かせる取り組みを半年続けた経験談。RSSリーダーやクリップ、バレットジャーナルなどに溜まった記録を活用するため、全文検索やタグ付けだけでなくLLMによるWiki生成を試したが、最も役立った画面はLLMが生成した文章をそのまま使うものではなかったという内容。
チーム共通の RAG と Web 検索という 2 つの知識の入口を同一 sandbox 上で両立させる方法についての記事。ビルド上の課題、認証の設計、エージェントの信頼境界といった実装上の論点を扱う。
DBやAPIなどの境界で受け取った値を弱い型のまま引き回すと、コードの見通しが悪くなる。境界で「Parse, don't validate」の考え方に従って強い型へ変換し、以降はその型だけを扱うようにすると実装がシンプルになる事例を、AIコーディングエージェント（Opus 5）が指示しないと弱い型を引き回しがちだという経験とともに紹介する。
エージェント型AIがデータを活用するには、人間向けのデータ設計では不十分で、信頼性・文脈・トレーサビリティ・ガバナンス・運用可能性の5属性をデータ層に組み込む必要がある。データ契約と品質、トレーサビリティとガバナンス、コンテキスト層、検索可能から実行可能への4段階で整備するというアーキテクチャ論。
日本郵便が公開する郵便番号CSV「ken_all.csv」は広く使われる一方でパース困難なことで有名。開発者がposutoパッケージを作る過程で直面した問題を解説している。行末の注記が行の並び順に依存する、地名が長いと不自然な位置で複数行に分割される、区切り文字が通常のカンマと異なる、「以下を除く」「一円」といった除外表記や特殊地名の例外処理が必要、ローマ字変換ファイルの品質が低い（cutletの方が優れている）など、フォーマット上の癖と歴史的な複雑さが積み重なっている実例を紹介している。
TOTVSのFabiane Nardon氏が、AIエージェント向けにエンタープライズデータ基盤を設計する手法を解説。決定論的システムと確率的LLMをどう線引きするかを精度・セキュリティ・コストの3軸で説明し、データメッシュとデータプロダクト単位でMCPツールを設計しガバナンスを確保する方法、RDF/OWLによるセマンティックオントロジーでLLMの回答精度を高める事例、Postgres/DuckDBベースの低レイテンシ層をSpark/BigQueryと組み合わせた3層データ基盤アーキテクチャを紹介している。
クラスメソッドのAIデータ分析基盤kaimeiで、社内固有の業務知識を登録する「ビジネスナレッジ」機能を検証。ナレッジ0件では会計年度を一般的な4月始まりと誤って解釈し正解の約2.9倍の金額を回答、出荷遅延では聞くたびに判定基準が変わり結果が841件ぶれた。定義を1行登録すると両題材とも3回とも正解と一致する安定した結果になった。