技術と経営の、
共通言語。

大量の文章を学習し、文章の読み取りや作成ができる AI モデル（Claude・GPT・Gemini など）。AI エージェント・RAG・要約・分類など、言葉を扱う業務 AI の中核を担う。

LLM が自ら作業を細かく分け、外部ツールの呼び出し・情報の取得・判断を繰り返しながら目的を達成するシステム。チャットボットと違い、複数の手順にまたがる作業を自分で進める点が特徴である。

本番導入の前に、技術的に実現できるかを小規模に確かめる試作。AI/DX プロジェクトは、PoC の段階で止まってしまうことが少なくない。そうならないよう、Kmetric は着手の時点で「何ができれば PoC は成功か」を文書で取り決めてから進める。

• → PoC で終わらせない — 本番運用に届ける7つの設計原則

顧客に価値を届けられるかを見極めるための、最小限の機能だけを備えたプロダクト。PoC が「技術的に動くか」を確かめるのに対し、MVP は「顧客に使われるか」を確かめる。Kmetric は2週間で MVP を用意して実際の顧客に使ってもらい、本番運用に向けた改善点を早い段階でつかむ。

社内文書・規程・FAQ などをあらかじめ検索しやすい形に整えておき、質問に関係する箇所を探して LLM に渡す仕組み。LLM がもともと学習していない最新の情報や自社固有の情報をもとに、根拠を示しながら回答できるようになる。

• → AI エージェントが効く5つの業務パターン — リサーチ・定型・判断・対話・連携の見極め方
• → 根拠を示す金融 AI 基盤（事例003）

LLM が、あらかじめ用意された機能（検索・計算・データの送信など）を必要に応じて選び、呼び出せるようにする仕組み。RAG が「読む」役割なのに対し、Function Calling は「動かす」役割を担う。AI エージェントが実際に作業を進めるときの土台になる。

LLM が外部のシステム（SaaS・データベース・API など）と連携するための、公開された共通規格。連携の定義を決まった形式で配布できるため、一度作った連携を複数の AI アプリで使い回しやすい。

LLM の回答品質を継続的に測るための、テスト問題一式と自動採点の仕組み。プロンプト（AI への指示文）を変えたときや、モデルを差し替えたときに、品質が落ちていないかを自動で確かめられるようにする。Kmetric は、この仕組みを MVP のリリース時点で整えることを標準にしている。

• → PoC で終わらせない — 本番運用に届ける7つの設計原則

AI の判断を人間が確認し、承認・修正する手順を業務の流れに組み込む設計。すべてを自動化するまでの移行期や、誤った判断がそのまま損害につながる業務（発注・与信・医療など）で採用される。Kmetric も、本番運用へ段階的に移行する際にこの設計をよく取り入れている。

LLM を組み込んだシステムを、本番で安定して動かすための運用の仕組み。動作の監視、回答品質の評価、利用コストの管理、プロンプトの改善を継続して行う。従来の機械学習の運用（MLOps）と違い、モデルそのものの学習は行わない。代わりに、プロンプト、LLM に渡す参照情報、評価指標の変更履歴を管理することが中心になる。

M&A や投資の判断に先立ち、対象会社を調査・評価すること。財務・法務・税務・ビジネス・技術（テクニカル DD）などの領域ごとに並行して行う。買収後のリスクを洗い出し、統合計画の前提を固めるのが目的である。

• → テクニカル DD の進め方と評価観点 — M&A の投資判断で押さえる技術評価の5つの観点

M&A で会社を売る側が、買い手の DD で評価額を下げられないように事前に行う、技術面と組織面の準備。売却の6〜12ヶ月前から始め、ソースコードの整理・属人化の解消・ドキュメントの整備を中心に進める。

• → 売却価格を技術で守る — Exit 前に進める M&A 技術整備の実務ガイド

創業者や投資家が、保有する株式を現金化する局面（M&A による売却・IPO・バイアウトなど）。スタートアップでは、創業から5〜10年後を目安に検討されることが多い。Exit 時の企業の評価額は、技術面の調査結果しだいで減額されることも、上乗せされることもある。

世界の4大会計事務所グループ（Deloitte・PwC・EY・KPMG）の総称。M&A では、財務 DD を中心に多くの案件を担う。テクニカル DD も手がけるが、強みは管理体制（ガバナンス）の評価にある。ソースコードの中身や属人化リスク（特定の人に頼らず開発を続けられるか）まで踏み込んだ分析では、専門ファームに分がある。

• → Big4・専門ファーム・受託会社 — テクニカル DD の発注先の選び方

案件で知り得た情報を、第三者に漏らさないことを約束する契約。一方だけが義務を負う形と、双方が負う形がある。M&A やテクニカル DD では、着手前に締結するのが一般的である。Kmetric は商談の初期段階から NDA の締結に応じる。ソースコードを確認する際は、コードの保管場所（リポジトリ）か、資料共有用のバーチャルデータルーム（VDR）の中だけで作業し、データを外部に持ち出さない。

特定のエンジニアや経営者が抜けると、事業の継続が難しくなるリスク。テクニカル DD では「文書化されていない暗黙知の量」「後任の採用・代替の難しさ」「リードエンジニアへの業務の集中度」から評価する。買収後100日以内に問題になりやすい、代表的な論点である。

ライブラリ・OS・データベースなどの公式サポートが終了した状態。サポートが終わったソフトウェアにはセキュリティ上の修正が提供されないため、テクニカル DD では、システムが使っている外部ソフトウェアのうち EOL のものを最優先で確認する。買い手が評価額を下げる根拠にもなりやすい。

週8〜16時間程度の限られた稼働で、技術戦略・システム全体の設計（アーキテクチャ）・エンジニア採用までを包括的に担う、非常勤の技術責任者。シード〜シリーズ A の企業が、社内 CTO を採用するまでのつなぎとして活用することが多い。相談役にとどまる技術顧問と違い、技術面の判断に責任を負う。

• → フラクショナル CTO がプロダクト価値を引き上げる5つの領域 — Exit に効く技術投資の優先順位

シード期の後、PMF（製品が市場に受け入れられた状態）に届きつつあるスタートアップが実施する、最初の大型の資金調達ラウンド（日本では数億円規模が中心）。この時期に、開発を社内で本格的に担う体制づくりや、社内 CTO の採用を判断することが多い。

クラウド（AWS・GCP・Azure）上に作る、外部から切り離された企業専用の仮想ネットワーク。LLM や社内文書を検索するためのデータベースを自社の VPC の中で動かすと、個人情報や社内データが社外に送られるのを防げる。セキュリティ要件が厳しい案件では、標準的な構成である。

開発者がコードを変更するたびに、テストから本番環境への反映までを自動で行う仕組み。LLM を使うプロダクトでは、この流れに Eval（回答品質の自動評価）を組み込み、プロンプトを変えたときに品質が落ちていないかを毎回確かめる運用が標準的である。

一度のログインで複数のサービスを使えるようにする仕組み（代表的な方式に SAML・OIDC・OAuth がある）。大企業が SaaS を導入する際は、SSO への対応が必須条件になることが多い。AI エージェントを社内の SaaS と連携させる場合も、SSO で設定済みの利用権限を崩さない設計が求められる。