IT

· 約 8 分

50の言葉で読む、企業AIがいま強調していること——役割・デリバリー・技術・Agent統治・評価・契約

企業AIの現場で頻出する約50語を、役割・デリバリー・技術基盤・Agentと統治・評価と検収・商流と契約の六層に整理。FDE周辺の語彙を共有言語として読むためのメモ。

50の言葉で読む、企業AIがいま強調していること

中国語の長図「50個の詞,看懂這個行業在說什麼」(出典メモ:WeChat公式アカウント「背壳的AI」系の用語図)は、企業AIまわりの語彙を六層に並べていた。ここではその骨格を、日本語の現場語感に寄せて要約する。暗記用ではなく、契約と検収が噛み合うための共有言語として読む。

語はだいたい次の六層に落ちる。役割/デリバリー/技術/Agent統治/評価・検収/商流・契約。前半は「できること」、後半は「誰が責任を取るか」に寄っていく。

01 役割と視野——この人は何をする人か

混ぜると、採用も報酬もズレる層。

  • FDE(Forward Deployed Engineer):顧客組織に入り込み、AIシステムを実業務へ埋め込んで結果に責任を持つ前線のデリバリーエンジニア。日本語では「前線展開エンジニア」「駐在デリバリーエンジニア」などと訳される。
  • Solutions Engineer:ソリューション検証とプリセールスの論証が主。「買える」ことを示すが、本番の長期責任は持たない。
  • Sales Engineer:成約に錨を置いた技術支援。KPIは本番投入ではなく受注。
  • AI Engineer:AIアプリケーションそのものを作る。FDEはそれを顧客システムへ嵌め込み、業務指標を動かす側。
  • Agent Engineer:Agentのオーケストレーション、ツール接続、自律実行チェーンが専門。いまのFDEの技術内核に近い。
  • Deployment Strategist:Salesforceなどで使う職名。展開経路の設計と顧客推進が主で、実装比率は相対的に低め。
  • FDE Practice:コンサルやSI内の事業ユニット。方法論・再利用資産・人材パイプラインを持つ。
  • Internal FDE Pod(内部FDE Pod):発注側が自社向けに組む少人数デリバリーユニット(だいたい3〜6人)。

Solutions EngineerとFDEは混同されやすい。差は技術の深さより、本番投入後の結果に責任を持つかにある。

02 デリバリーフロー——発注側がいちばん理解すべき層

  • Discovery:入場後の問題定義。業務結果・タスク・意思決定点・システム・データ・承認ノードを分解する。
  • POC / Pilot:実現可能性の試作・試行。実権限・実トラフィックは載せない。
  • Thin Production Slice:いちばん細いエンドツーエンドの本番スライス。実認証・実データ・監視・テスト・ロールバックを含む。「大きくて網羅的なPOC」の代替。
  • Production-Grade:権限・安定性・オブザーバビリティ・ロールバックまで満たした本番状態。「動く」と「本番級」のあいだに、しばしば2〜3か月の溝がある。
  • Time-to-Production:入場から最初のスライス投入までの時間。人日換算の「デリバリー工数」に代わる評価指標になりつつある。
  • Delivery Pattern:再利用可能なデリバリーパターン(アーキテクチャ/スクリプト/設定の束)。ある大手では90日以内の定着を求める、という話もある。
  • Reference App / Starter App:業種シナリオ向けの参照アプリ。一回きりの案件を、量産の起点に変える。
  • Capability Handover:システムと運用能力を顧客チームへ戻す段階。資産になるか、長期の人海戦術になるかがここで決まる。

成熟度の見分けは簡単で、Thin Production Sliceを実際に切っているか。POC止まりのチームは、人日課金にも止まりやすい。

03 技術基盤——LLMは部品であってソリューションそのものではない

  • LLM:大規模言語モデル。デリバリーの一コンポーネントであり、方案そのものではない。
  • Context Window:一回で扱える情報量。長コンテキストは、文書級・コードベース級タスクの切り方を変えた。
  • RAG(Retrieval-Augmented Generation):企業知識を先に検索し、その結果に基づいて答える。
  • Vector / Embedding:テキストをベクトル化し類似検索する層。RAGの土台。
  • Fine-tuning:企業データで追加学習。多くの案件では、検索とコンテキスト設計より優先度が低い。
  • Context Engineering:モデルが各ステップで「何を見るべきか」を系として組むこと。プロンプト技巧より工学に近い。
  • Ontology:企業のオブジェクト・関係・操作を統一セマンティック層にする。Palantir路線の核概念。
  • Connector:顧客システムとAIアプリをつなぐデータ/アクション通路。いちばん再利用されやすいデリバリー資産。
  • MCP / Function Calling:モデルが外部ツールを標準的に呼ぶためのインタフェース規約。

04 Agentと統治——「作れるか」ではなく「本番に出してよいか」

  • Agent:自律的に計画し、ツールを呼び、多段タスクを実行し、外部状態を変えうるシステム。
  • Agentic Workflow:判断分岐と人手ノードを含む、Agent駆動の業務フロー。固定スクリプトの自動化とは別物。
  • Orchestration:複数Agentの分担と、状態・順序・衝突の管理。
  • Tool Invocation:外部システムへの動作実行。書き込みと読み取りは権限を分ける。
  • Permission Boundary:触れるデータと実行可能な操作を、最小権限で明示する。
  • Human-in-the-Loop:高リスク動作前の強制確認。責任帰属の技術実装。
  • Guardrail:入出力と行動範囲の硬い制約。越境は遮断する。モデルの自制に頼らない。
  • Observability:入出力・所要時間・コスト・失敗理由を残し、障害時に辿れるようにする。
  • Workflow Lineage:ある結果が、どのデータ・どの手順・どの版から出たかを遡る。
  • Audit Trail / Rollback:各動作が監査可能・再現可能・取消可能であること。企業コンプライアンスの前提。

この十語の共通点は、能力ではなく制約を語っていることだ。企業が制約に払う金は、能力に払う金を超え始めている。

05 評価と検収——残金トラブルのほとんどがここに集中する

  • Eval:固定データセットと判定規則で性能を測る。「感覚」の代替。
  • Eval Harness:繰り返し走らせられる評価枠組み。案件と一緒に渡すと複利型の資産になる。
  • Golden Set:業務側が正解を認めたサンプル集。検収の事実基準。
  • Regression Suite:変更のたびに自動再実行し、一箇所直して三箇所壊すのを防ぐ。
  • LLM-as-a-Judge:モデルでモデル出力を採点する。安いが人手抜検と揃える必要があり、単独の検収根拠にはしない。
  • Hallucination Rate:事実根拠のない出力の割合。指定データセット上で定義して初めて意味を持つ。
  • Success Metrics:開始前に決める業務側の結果指標。一部企業はすでに契約文書へ書いている。
  • Acceptance Criteria:本番投入を通す具体条件のリスト。書けなければ、無いのと同じ。

06 商流と契約——チームが資産か消耗品かを決める層

技術語彙だけでは収入構造は解けない。

  • SOW(Statement of Work):範囲・マイルストーン・検収条件を書く契約添付。AI案件でいちばん形骸化しやすい。
  • T&M(Time & Materials/人日制):投入工数課金。リスクは低いが粗利は頭打ちで、再利用と逆インセンティブになりやすい。
  • Milestone-Based:段階成果で支払う。各マイルストーンに判定可能な検収基準が要る。
  • Outcome-Based:業務結果で分ける。上限は高いが、指標が帰属可能・測定可能であることが前提。
  • Delivery Asset Reuse Rate(デリバリー資産再利用率):一回の案件のうち、次の顧客へ移せる資産の割合。規模化できるかの指標。
  • Vendor Lock-in:業務フローとデータが単一ベンダーに縛られる状態。
  • Data / IP Ownership:案件中に生まれたデータ・モデル・フロー資産の所有者。いちばん重要で、いちばん抜けやすい条項。

この50語がまとめて示していること

前半およそ30語はモデル・検索・ツール・展開など能力を語る。後半およそ20語は、誰が権限を出し、誰が検収し、誰が結果を負い、資産は誰のものか——責任を語る。

市場がそう動いている。問題定義・システム変更・結果責任が分かれていた旧来の役割分担は、Agentが実行層に入ると破綻しやすい。なぜなら「いつ・何に・どんな成功条件で触るか」は、すでに業務設計そのものだからだ。

だからこの語彙は暗記カードではない。先に言語を揃え、そのうえで責任を揃えるための道具である。まだ正確に書けない語も同じくらいある——だが書けない語は、だいたい契約の空白と同じ場所にある。

これからどう見るか

情報としての用語集は安い。希少なのは、どの語を契約と検収の核に据えるかという判断だ。ニッチでも深い読者——現場で「Thin Production Slice」と「Acceptance Criteria」を同じ文で使える人——との信頼は複利で効く。一人会社でも、能力のカタログを増やすより、責任の境界を言語化できる方がレバレッジになる。

コメントを書き込む

コメントは管理人が確認のうえ、この記事の「みんなのコメント」に掲載する場合があります(即時には表示されません)。 URL・宣伝・誹謗中傷は掲載されません。

この記事が少しでも参考になりましたら、今後のデータ整理・記事作成・サイト改善の励みになります。
無理のない範囲で、OFUSEから応援いただけますと幸いです。

Blog 一覧へ戻る