ウイングアーク1stの講演から考える「AI Ready基盤」とデータ・ハーネス設計

企業のAI活用では、ChatGPT、Gemini、Claudeなど、どのモデルを選ぶかに注目が集まりやすい。性能、価格、コンテキスト長、画像理解、コーディング能力は重要であり、特定モデルに全面依存せず、業務ごとに使い分けるマルチモデル構成も現実的な選択肢になっている。

しかし、AI Agent Day 2026 Summerで紹介されたウイングアーク1stの論点は、モデル比較ではない。どれほど高性能なモデルを採用しても、必要なデータが見つからず、指標の定義が部門ごとに異なり、文書の版や権限が管理されず、業務の判断基準が暗黙知のままなら、AIは企業の仕事を理解できない。

必要なのは、AIが正しい情報を必要な範囲で参照し、人間の承認のもとで業務を進め、結果を次の改善へ戻せる状態である。本稿ではこれをAI Ready基盤と呼ぶ。ウイングアーク1stの製品やデモを手掛かりに、IT技術者が設計すべきデータ・コンテキスト・権限・評価の基盤として整理する。

AI導入とAI活用の間には、データと運用の溝がある

生成AIの初期利用では、メールの下書き、要約、翻訳、アイデア出し、会議記録の整理、コード生成が広がる。これは個人の生産性を上げるが、企業固有の売上、顧客対応、製造トラブル、契約条件を理解して継続的に支援することとは別の段階である。

たとえば「商品Aの売上が低下した原因を分析して」とAIへ依頼する場面を考える。同じ商品のデータが、基幹システム、部門Excel、個人フォルダ、BI、代理店CSV、会議資料に散らばり、商品名、商品コード、集計期間、返品の扱いまで異なっていたらどうなるか。

人間でも正本を特定できないデータを、AIが正しく統合してくれるとは限らない。問題は推論性能ではなく、データ定義、出所、鮮度、権限、業務文脈にある。

Gartnerは、コスト上昇、不明確な事業価値、不十分なリスク管理を理由に、2027年末までにエージェント型AIプロジェクトの40%以上が中止されると予測した。Gartnerの発表が示す通り、失敗理由は単に「モデル精度が足りない」ことではない。

エージェントは回答を作るだけでなく、データを検索し、文書を読み、外部システムに接続し、計算を実行し、場合によってはメール送信やCRM更新まで行う。デモから本番へ移すには、データ、目的、権限、コスト、ログ、停止、人間承認、評価を一体で設計する必要がある。

AI Ready基盤を四つの層で考える

AI Readyとは、AIツールを契約済みであることではない。組織全体が、AIを効果的かつ安全に使える準備が整った状態である。次の四層に分けると、欠けている部分を見つけやすい。

層	整えるもの	設計上の問い
データ基盤	構造化・非構造化データ、マスター、メタデータ、品質、権限、更新履歴	何が正本で、誰が意味と品質に責任を持つか
AI・テクノロジー	LLM、RAG、エージェント、MCP、ツール、ワークフロー、ルーティング	どの処理をAIに任せ、どのモデル・ツールを使うか
プロセス・ガバナンス	承認、監査、評価、費用上限、セキュリティ、停止・復旧	AIが何をしてよく、誰が止め、何を記録するか
人材・組織	業務責任者、データオーナー、IT、法務、セキュリティ、教育	改善と責任分界を誰が継続的に担うか

モデルを導入しても、他の三層が欠けていれば、AIは個人向けチャットの域を出ない。逆に、この四層が整えば、モデルが更新されても企業側の資産として残る。

構造化データと非構造化データを、同じ方法で扱わない

従来のデータ活用は、売上金額、商品コード、店舗コード、在庫数、日付といった構造化データを、データウェアハウスとBIで集計・可視化することが中心だった。ウイングアーク1stはDr.SumやMotionBoardを通じ、この領域のデータ分析基盤を提供してきた。

AI時代には、日報、会議議事録、問い合わせ、契約書、メール、FAQ、製造トラブル記録、営業メモなどの非構造化データも、意思決定に使う対象になる。MotionBoardは、生成AI連携による分析支援と、画像・テキストなどを取り込んで構造化する機能を掲げている。MotionBoardの生成AI連携は、BIと生成AIを競合させず、段階的に組み合わせる方向性を示す。

「企業データの8〜9割が非構造化」といった比率は、業界や数え方で変わるため、共通の確定値として扱うべきではない。それでも、重要な業務文脈の多くが文書・メール・会話に埋もれ、従来のBIだけでは十分に使えてこなかったことは確かだ。

非構造化データをAIへ渡す際は、PDFをそのままベクトル化するだけで終わらせない。たとえば製造トラブル報告書なら、発生日、設備、製品、不良内容、原因、暫定対策、恒久対策、対策結果、根拠文書を抽出し、原文と結び付けて保存する。そうして初めて、AIは類似事例を候補として提示し、人間は条件の違いを確認できる。

AI Readyデータは「検索できる」だけでは足りない

AIが扱いやすいデータとは、単にデータベースやベクトルDBに入っているデータではない。少なくとも、次の条件を備えたい。

意味が明確である: 「売上」が出荷・店頭販売、税込・税抜、返品控除前・後のどれかを判別できる。
出所を追跡できる: 回答がどのシステム、文書、版、ページ、日時に基づくかを示せる。
鮮度が分かる: 現在有効な規程・約款・手順と、古い情報を区別できる。
権限がある: 利用者とエージェントが、参照してよいデータだけへ到達できる。
品質を測定できる: 欠損、重複、矛盾、誤記、更新遅延を検出できる。
業務文脈を持つ: 文書を、決定、障害、顧客要求、対策、未解決事項などとして扱える。

これはデータ整備の追加作業ではない。AIの回答品質と説明可能性を決める本体である。

回答の後に生まれたデータを、次の判断へ戻す

AI活用は「データ → AIによる分析 → 人間またはエージェントの行動」で終わらない。営業なら、提案内容、顧客の反応、追加質問、失注理由、成約条件、次回アクション、担当者の所感が新たに生まれる。

この結果を、出所・権限・確定状態を付けて整理し直せば、次の提案や判断に使える。

既存データ
  ↓
AIによる検索・分析・提案
  ↓
人間の判断と業務行動
  ↓
結果・訂正・根拠の記録
  ↓
データの整理・品質確認・権限付与
  ↓
次のAI利用

ここでいう「学習」は、必ずしもLLMを再学習することではない。RAGの情報更新、ナレッジ追加、顧客属性の更新、成功・失敗の記録、評価結果に基づくモデルルーティングの見直しを含む。企業の競争力は、モデル自体よりも、この循環をどれだけ速く安全に回せるかに表れる。

ハーネスエンジニアリングは、AIを業務で走らせる周辺機構の設計である

講演で紹介された「ハーネスエンジニアリング」は、高性能なモデルを実業務で機能させるための周辺機構を設計するという考え方として捉えるとよい。高性能なエンジンだけでは自動車が走れず、ハンドル、ブレーキ、計器、車体、交通ルールが必要なのと同じだ。

AIのハーネスには、次の要素が含まれる。

データ接続とコンテキスト管理
プロンプト、RAG、ツール実行
モデル選択とコスト制御
ID、権限、承認、ポリシー
実行ログ、トレース、評価
失敗時の停止、ロールバック、インシデント対応

このうち、モデル提供者が主に担う領域をインナーハーネス、企業が自社業務に合わせて設計する領域をアウターハーネスと分けて考えられる。

領域	主な内容	企業が担う度合い
インナーハーネス	モデル構造、推論、コンテキスト長、モデルレベルの安全調整、ツール呼び出し能力	原則として直接は変えない
アウターハーネス	データ、RAG、モデルルーター、業務フロー、権限、承認、ログ、評価、費用、復旧	自社業務に合わせて設計する

同じLLMを使っていても企業ごとに成果が違うのは、アウターハーネスが異なるからだ。企業が長期投資すべき対象も、特定のモデル名ではなく、このアウターハーネスである。

軽量なエージェント基盤ほど、台帳と停止手順が要る

最初から巨大なAIプラットフォームを作る必要はない。ウイングアーク1stのdejiren AIは、外部サービスとの連携やノーコードでのAIエージェント構築を掲げている。dejiren AIの公式説明のような軽量な基盤は、最初のユースケースを短期間で検証するために役立つ。

ただし、ノーコードで作れることは、管理が不要という意味ではない。エージェントごとに少なくとも、次を台帳で管理する。

所有者と利用目的
参照・更新するデータと接続先
使用モデルとバージョン
読み取り・書き込み・外部送信の権限
コスト上限、実行回数、タイムアウト
評価結果、承認条件、監査ログ
緊急停止手順と廃止日

野良エージェントを禁止するより、試行から共有運用、本番実行へ昇格させる経路を設計した方が、現場の改善意欲と統制を両立しやすい。

マルチモデル構成は、モデル選択ではなく運用設計である

簡単な分類は小型モデル、高度な推論は大型モデル、画像確認はマルチモーダルモデル、社内文書検索はRAGというように、タスクに応じてモデルを使い分ければ、品質・速度・費用のバランスを取りやすい。

一方で、モデルが増えると、出力傾向、更新時の品質、保持条件、利用可能地域、障害時の挙動、料金体系がばらつく。マルチモデル基盤には、モデルルーターだけでなく、共通の評価セット、モデル変更の検知、費用トレース、データ送信ポリシー、フォールバック時の承認条件が必要になる。

「最適なモデルを自動選択する」と説明するだけでは不十分である。どのデータがどのモデルへ送られ、品質が下がったときに誰が気付き、いつ切り戻すかまでが設計対象だ。

BIと生成AIは、役割を分けて組み合わせる

ウイングアーク1stの講演では、保険問い合わせ、製造トラブル検索、営業接客、帳票処理、BI上の分析といったユースケースが紹介された。これらは技術デモや想定ユースケースを含むため、ただちに本番での精度や投資効果を示すものではない。ただし、実装の役割分担を考える材料にはなる。

たとえばBIと生成AIは、対立する技術ではない。

データベース
  ↓
SQL・ルール処理で確定値を計算
  ↓
BIで定型指標を監視・可視化
  ↓
AIが要点、異常の仮説、関連文書を提示
  ↓
人間が根拠を確認し、追加分析・判断・報告を行う

BIは定義済みの指標を正確に集計・可視化する。生成AIは結果の説明、自然言語による深掘り、非構造化情報の要約、仮説の提示に向く。MotionBoardも、AIによるインサイト分析、自然言語でのチャート変更、非構造化データの取り込みを提供している。MotionBoardの機能説明を見ても、既存のBIを捨てるのではなく、確定計算とAIの解釈を組み合わせる方向である。

同じ原則は、帳票処理にも当てはまる。OCR、形式チェック、マスター照合、金額計算、重複判定、法定保存は、ルールベース処理の方が適切な場合が多い。AIは、自由記述の理解、書類分類、不足項目の説明、異常候補の要約といった曖昧性のある部分に限定する。すべてをLLMに任せないことが、品質と費用を両立させる。

予測と事実、RAGと正式根拠を混同しない

直近数か月のデータから文章で予測を出せても、それが統計的に妥当な予測であるとは限らない。将来予測には、学習期間、季節性、外れ値、検証データ、評価指標、信頼区間、前提条件が必要だ。

安全な分担は、時系列モデルや機械学習モデルで予測値と信頼区間を計算し、LLMには結果・前提・注意点を説明させることにある。LLMがもっともらしい文章を書いたことを、予測モデルの妥当性と取り違えてはいけない。

RAGも同様だ。保険約款、規程、契約書の回答支援では、自然な回答より前に、どの版を正式根拠にするか、商品や契約時期による適用条件をどう絞るか、FAQと正式文書が矛盾した場合に何を優先するかを決める。RAGの完成条件は「検索できた」ではなく、根拠、版、権限、回答不能時の停止を実装できたことである。

MCPは接続の共通化であり、権限設計の代替ではない

MCPは、AIアプリケーションと外部ツール・データソースを共通の方式でつなぐ。接続がしやすくなる一方、検索だけを行うMCPサーバーと、CRM更新やメール送信を行うMCPサーバーのリスクは大きく異なる。

MCPの仕様は、ユーザーデータや管理操作を扱うサーバーでは認可が必要であり、アクセス・トークンの検証を求めている。MCPの認可仕様と認可の解説を確認すると、MCPを採用すること自体が権限管理の完了を意味しないことが分かる。

少なくとも、次を分けて設計したい。

MCPサーバーの運営者と信頼範囲
利用者IDとエージェントID
読み取り、書き込み、削除、外部送信の権限
入力値検証、実行回数、予算、タイムアウト
ツール呼び出し、参照データ、出力の監査ログ
プロンプトインジェクションを含む不正な指示への対策

2026年には、組織のIDプロバイダーからMCPサーバーの利用を集中管理する仕組みも整備され始めている。MCPのEnterprise-Managed Authorization は、接続性と統制を両立する方向性の一例である。

回答履歴ではなく、実行トレースを残す

エージェントの監査で最終回答だけを残しても、問題が起きたとき原因を調べられない。最低限、誰が、どのエージェント・モデル・バージョンを使い、どのデータを参照し、どのツールを呼び、何を更新し、いくら費用がかかり、誰が承認し、成功・失敗したかを関連付けて追跡できるようにする。

エージェントは複数の処理を連続して実行する。そのため、従来のアプリケーションログよりも、依頼からツール呼び出し、承認、外部操作、結果までをつなぐトレースが重要になる。

最初に作るべきは、巨大なプラットフォームではない

AI Ready基盤は、次のような要素から成る。

レイヤー	主な要素
データソース	基幹、CRM、ERP、ファイル、メール、チャット、IoT、帳票
データ管理	ETL/ELT、DWH、データレイク、マスター、カタログ、品質、権限
コンテキスト	文書分割、全文・ベクトル検索、再ランキング、根拠、会話メモリー
AI実行	モデルルーター、エージェント、ワークフロー、MCP、API、キャッシュ、費用制御
ガバナンス	ID、ポリシー、承認、評価、監査、安全フィルター、停止・復旧
利用者接点	BI、メール、チャット、業務アプリ、モバイル、API、バッチ

ただし、初日から全レイヤーを作り込む必要はない。まず一つの業務で、正本データ、最小権限、根拠表示、人間承認、評価・停止手順を実装する。その中で再利用できた部分を、次のユースケースへ基盤として広げていく方が現実的だ。

AI Ready度を確認するチェックリスト

データ

正式なデータソース、指標定義、データ責任者が決まっているか
非構造化文書を分類し、版・有効期限・出所を持たせているか
古い文書・削除文書を検索対象から外せるか
検索時にも元システムのアクセス権限を適用できるか
欠損、重複、矛盾、更新遅延を測定できるか

業務と技術

対象業務、目的、人間の判断点、例外処理を可視化したか
確定計算・ルール処理と、LLMによる生成・解釈を分けたか
RAGの根拠を文書・版・位置まで表示できるか
モデル変更時に同じ評価セットで品質を比較できるか
MCPやAPIの読み取り・書き込み・外部送信を分離したか

ガバナンスと評価

エージェントの所有者、目的、接続先、権限、停止方法を台帳化したか
実行上限、費用上限、タイムアウト、人間承認を設定したか
依頼から外部操作までのトレースを残せるか
正解データ、現行業務との比較、精度・時間・費用・利用者行動を測るか
インシデント時に止め、原因を調べ、復旧できるか

まとめ: AIの性能差より、企業のコンテキスト差が重要になる

この講演の本質は、特定製品を使えばAIエージェントを簡単に作れる、という話だけではない。AIを変えるのはモデルだけでなく、AIへ渡すデータと業務コンテキストである、という点にある。

競合企業も同じLLMを契約できる。しかし、過去の顧客対応、現場の成功・失敗、製造トラブル、意思決定の背景、営業ノウハウ、商品固有の知識、業務手順、社内の判断基準は、その企業にしかない。

AI時代の競争力は、最新モデルを最も早く入れることだけでは生まれない。自社の情報を、見つけられ、意味を理解でき、権限を守って使え、根拠を追跡でき、行動へつなげ、結果を再び知識として蓄積できる状態へ変えることにある。

正確な計算はデータベース、定型処理は従来プログラム、曖昧な文書理解はAI、重要判断は人間が担う。その役割分担をデータ、権限、ワークフロー、ログ、評価として実装したものが、企業のアウターハーネスである。

AI Readyとは、AIを導入済みであることではない。AIが正しい情報を使い、正しい権限で動き、結果を検証しながら改善できる状態である。モデルの更新速度が速くなるほど、企業が長期的に投資すべき対象は、特定モデルではなく、データとアウターハーネスになる。

作成日: 2026年7月23日