メインコンテンツへスキップ
記事一覧へ戻る
知見リサーチ読了目安 10分-

企業のAIシステムはどこへ向かうのか:ファイル中心の運用から、AIが利用できる情報基盤へ

企業のAI活用は、個別のモデル機能を導入する段階から、情報の構造と出典を保ち、AIを自社の管理下で運用できる情報基盤を整える段階へ移りつつある。

Sandeep Yella

Sandeep Yella

ファウンダー・CEO

企業のAIは、個別のモデル機能を使う段階から、AIが情報を直接扱えるシステムへ移りつつある。重要なのは、単に新しい世代のモデルへ置き換わることではない。人がファイルを読み解くのを待つ仕組みから、情報の意味と根拠を保ち、定められた範囲で推論・操作し、その結果をもとに改善できる仕組みへの転換である。エージェントは、この調整をますます担うようになる。しかし、AIをどこまで安全に自律させられるかは、エージェントを導入したかどうかではなく、その周囲で情報を取り込み、整理し、根拠を残す仕組みの質で決まる。

この見方に立つと、企業が考えるべき問いも変わる。どのモデルが最も高性能かだけではない。情報をどのように取り込み、変換後に何を残し、質問に応じてどの探し方を選び、誰または何に操作を許し、どの段階で誤りが起きたかを特定できるかが問われる。モデルは引き続き重要だが、組織の情報や知識を実務で活用する、より大きな仕組みの一部にすぎない。

これまでは、人がシステム同士をつないでいた

PDF、プレゼンテーション、スプレッドシート、文書が人を経由し、人が読み、検索し、分析し、推論し、書き直して新しいファイルにする流れ。
画像を拡大表示(新しいタブで開きます)
ファイル中心の仕組みでは、ソフトウェアは文書を保存するだけで、文書の意味を読み解き、システム間をつなぐ役割は人が担っていた。

長い間、業務ソフトウェアは、ファイルを作成・保存・送信・編集するために設計されてきた。PDFは報告書を、スプレッドシートは計算を、プレゼンテーションは説明の流れを、メールは前後の文脈を運ぶ。しかし、それらのつながりは、多くの場合、人の頭の中にしかなかった。人が必要な資料を探し、レイアウトを読み、定義を照合し、どれが最新の情報かを判断し、その結果を別のファイルやアプリケーションへ移していた。

言い換えれば、人がシステム同士をつなぐ役割を担っていた。人は曖昧さを補えるため柔軟だったが、この進め方は規模を広げにくく、監査や再現も難しかった。答えが間違っていても、古い添付ファイル、図表の読み違い、明記されていない例外、計算ミスのどこに原因があったのか分からないことがある。どの情報をたどり、どう判断したかも、機械が読める記録としてはほとんど残らない。企業のAIは、人が担ってきたこの流れのうち、どこまでをソフトウェアで表現し、運用できるかを変えようとしている。人の判断をなくすのではない。判断に至るまでの情報処理を見える形にする。

これは、人を機械に置き換える話ではない。人が暗黙に担ってきた情報の受け渡しを、明示的で検証可能な処理へ変える動きである。

AIは、モデル単体ではなくシステム全体で考える

入力データから文書理解、意味表現、保存と索引、知識アクセス、推論、出力とアクションへ進み、全段階をオーケストレーションと評価が横断する7段階の情報パイプライン。
画像を拡大表示(新しいタブで開きます)
AIが情報を直接扱える仕組みでは、元資料の取り込みから操作の実行まで、各段階の処理が見える形になる。

企業のAIシステムは、入力データ、文書の読み取り、意味と関係性の整理、保存と索引、必要な情報の取得、推論、出力と操作という7段階に分けると理解しやすい。段階を分けて考える必要があるのは、答えがもっともらしく見えても、途中のどこかで情報が損なわれている可能性があるからだ。例えば、文書の読み取りで表の階層が失われ、構造化の段階で数値とラベルが離れ、索引から必要な根拠が漏れ、検索で似てはいるが法的には異なる条項を選び、推論で裏付けのない結論を出し、操作では与えられた権限を超えることがある。

必要な情報を取り出す方法も、単純な検索だけでは足りない。質問の種類によって、適切な処理は異なる。正確な文言を探す、意味の近い情報を探す、数値を計算する、関係をたどる、データを変換するなど、それぞれ別の処理である。すべてをベクトル検索だけで処理すると、性質の異なる質問を一つの仕組みに押し込み、どの段階で精度が落ちたのか分からなくなる。

質問によって、必要な情報の探し方は異なる

質問の種類主な処理方法理由
特定の条項を探す完全一致検索またはBM25原文と定義語をそのまま確認できる
類似するリスクを探すベクトル検索表現が異なる文章から、意味の近い情報を探せる
財務指標を計算するSQLまたはコード型を保った値と、再現可能な計算処理を使える
所有関係をたどるグラフ探索会社や人物などの対象と、その関係を保てる
データを整形・変換するコード実行処理内容が明確で、検証可能なロジックを適用できる

処理を計画する機能は、複数の方法を組み合わせ、推論に使う前に結果を並べ替えたり照合したりすることがある。

実務では、検索そのものが計算になりつつある。システムは処理の流れを計画し、完全一致検索と意味検索を使い分け、構造化データへ問い合わせ、関係をたどり、計算を実行し、その結果をまとめて根拠のある文脈を作る。図書館から資料を一冊探すというより、特定の意思決定に必要な根拠を一式そろえる処理である。その根拠の質が、最終的な答えの質を決める。

エージェントは処理を動かすが、土台そのものではない

AIエージェントが目標を分解し、ツールを選び、文脈と記憶を管理し、7段階の情報パイプラインを反復しながら企業システム、データ、モデル、人、業務フローへ接続する構成。
画像を拡大表示(新しいタブで開きます)
エージェントは情報処理の流れやツールを動かすが、その土台となる仕組みを不要にするわけではない。

この仕組みの中で、エージェントは一連の処理を動かす役割を担う。目標を小さな作業に分け、ツールを選び、必要な情報を集め、途中の状態を保持し、結果を確認しながら、続行するか、停止するか、人に確認するかを判断する。ワークフローがあらかじめ定めた手順を進むのに対し、エージェントは与えられた権限とツールの範囲内で、進め方をその都度選べる。Anthropicもこの違いを説明している。自律性を高めるほど柔軟性は増すが、コストや処理時間も増えやすいため、まずは単純で組み合わせやすい仕組みから始めることを勧めている。[1]

したがって、自律性は「あるか、ないか」ではなく、「どこまで任せるか」で考える必要がある。文章の書き換えだけをモデルに任せる仕組みもあれば、検索方法の選択を任せる仕組み、一連の処理の計画と実行まで任せる仕組みもある。任せる範囲が広がるほど、誰が実行したか、何を許可したか、どの操作を行ったか、どこで停止するか、いつ人に判断を戻すかを記録・管理することが重要になる。NISTのエージェント標準化の取り組みは、システム間の連携と安全性を重視している。[2] また、エージェントの識別と権限に関する文書は、識別、認可、監査、否認防止に加え、さまざまなデータやツールへ接続する際のプロンプトインジェクションを課題として挙げている。[3]

コーディングエージェントと単純に比較できない理由

リポジトリ、ソースファイル、ツール、テスト、バージョン管理を持つ構造化された開発環境と、PDF、プレゼンテーション、スプレッドシート、メール、スキャン、データルームに分散した企業知識の対比。
画像を拡大表示(新しいタブで開きます)
開発環境には、自律的なシステムに必要な構造と、結果を確かめるための仕組みの多くが、すでに備わっている。

コーディングエージェントは、AIに広い範囲の作業を任せられる代表例である。しかし、ソフトウェアの開発環境は、AIが情報を直接扱いやすい特別な環境でもある。ファイルには明確な文法と安定した階層があり、必要な箇所を速く正確に検索できる。ツールは同じ入力に同じ結果を返す形で実行でき、テストからすぐに成否が返る。リポジトリの範囲が作業対象を限定し、変更履歴を使って追跡や復元もできる。意味の整理、実行、評価、復旧に必要な仕組みが、すでに開発環境に組み込まれている。

自律エージェントの周囲に、規模、複雑性、境界、コストとレイテンシ、信頼と来歴、制御と機密性、評価という企業知識の制約が配置された図。
画像を拡大表示(新しいタブで開きます)
一方、企業内の情報や知識には、ソフトウェアの開発環境にはない制約や、未解決の問題が残っている。

企業内の情報や知識は、これとは異なる。文書、業務アプリケーション、データベース、データルーム、スキャン画像、メッセージ、専門家との会話など、さまざまな場所に分散している。同じ用語でも部署によって意味が異なり、図表が示す関係はテキストに変換した時点で失われることがある。情報へアクセスできるかどうかも、利用者、情報源、目的、地域、時点によって変わる。要約が完全かどうかを、機械的に判定できるテストもない場合が多い。この環境でAIに広い範囲の作業を任せるには、次の9つの運用上の制約を明確に扱う必要がある。

  • 規模:大量かつ継続的に変化する情報群を、毎回すべて長い文脈に含めて処理するのは現実的ではない。
  • 形式の違い:文章、表、グラフ、スキャン画像、スプレッドシート、業務アプリの記録は、それぞれ異なる形で意味を持っている。
  • 意味の境界:同じ言葉でも、異なる会社や人物、期間、定義、対象範囲を指すことがある。
  • 権限の境界:根拠となる情報へのアクセスやシステム上の操作は、利用者とAIに与えられた権限の範囲に制限する必要がある。
  • コストと処理時間:文書の解析、検索、大量の情報の読み込み、ツールの呼び出し、再試行によって、実行ごとの負荷は変わる。
  • 出所と監査:すべての主張について、根拠となる情報、情報源、処理の履歴、判断の記録を追跡・確認できる必要がある。
  • 管理と機密性:ガバナンス、データの保存場所、アクセスルール、安全な操作範囲を、一連の処理を通して守る必要がある。
  • 誤りが起きた段階の特定:入力、文書の読み取り、情報の構造化、索引、検索、推論、操作のどこで誤りが起きたかを切り分けられる必要がある。
  • 評価:タスク全体だけでなく、例外的な事例、変化するデータ、繰り返し実行した際の品質も検証する必要がある。

これらは、エージェントを使うべきではないという話ではない。エージェントの性能は、情報の設計や運用上の管理と切り離して考えられないということだ。高性能なモデルに多くのツールを与えても、どの情報を根拠にすべきかという曖昧さは解消されず、変換時に失われた関係も元には戻らない。

一つの関係を失うと、その誤りは最後まで引き継がれる

財務のウォーターフォール図を例にすると、この問題がよく分かる。質問は、「2026年度上期の事業利益の増減要因のうち、最も大きなマイナス要因は何か」である。元の図では、最も大きなマイナス要因は「固定費」の▲32である。「価格/MIX」は合計▲1の別項目であり、その内訳として示された「価格▲23」は補足情報にすぎない。[4]

2026年度上期の事業利益ウォーターフォール図。トップレベルの固定費▲32と価格/MIX▲1、価格の構成要素として▲23の注記が示されている。
画像を拡大表示(新しいタブで開きます)
図が持つ階層関係を失うと、内訳の数値を全体の増減要因と取り違える可能性がある。

図を互いに関係のないテキストへ変換すると、検索結果には「価格▲23」だけが返され、「価格/MIX▲1」との親子関係が失われることがある。その場合、推論モデルは▲23をほかの増減要因と同列に比べ、「価格」が最大のマイナス要因だと自信を持って答えるかもしれない。文章が自然で、計算にも矛盾がなくても、情報の構造を失ったことで質問の意味そのものが変わり、答えが誤っている可能性がある。

この誤りは、後続の各段階へそのまま伝わる。元資料は正しくても、変換時に階層が失われ、検索が切り離された数値を返し、推論がそれを同列の項目として扱い、最終的に誤った結果が出力される。最後の段階で推論を増やしても、根拠から消えてしまった関係を確実に復元することはできない。文書の読み取りと、情報の意味や関係を保った構造化は、単なる前処理ではなく、推論システムそのものの一部である。

整った答えが出たからといって、情報処理の流れが正しいとは限らない。数値、条項、主張が元資料で持っていた意味を保つには、それらの関係も一緒に残す必要がある。

処理結果を測り、改善につなげる

7段階の情報パイプラインを全体評価し、失敗を入力元、解析、意味表現、索引、知識アクセス、推論、出力のどこかに特定して改善へ戻す図。
画像を拡大表示(新しいタブで開きます)
最終結果の指標は、タスクが成功したかを示す。各段階に残した根拠は、どこを改善すべきかを示す。

信頼できるシステムは、最終的なタスクの成否を測るだけでなく、失敗の原因を特定できるよう、途中の処理と根拠を記録する。入力データに問題があればデータを整え、文書の読み取りに問題があれば抽出やレイアウト処理を見直し、情報の構造に問題があればデータの項目や関係の持ち方を改善する。検索に問題があれば索引、検索方法の選択、絞り込み、結果の並べ替えを見直す。推論に問題があれば、指示、ツール、検証方法、人への確認手順を改善する。出力に問題があれば、形式の確認と操作範囲の制御を見直す。すべての誤りをプロンプトの問題として扱っていては、継続的な改善はできない。

NISTのAIリスクマネジメントフレームワークは、利用目的と状況の明確化、人による監督の記録、本番に近い条件でのテスト、運用中の監視、安全側に倒れる動作、必要に応じた第三者レビューを求めている。[5] エージェントの評価には、複数回のやり取りをまたいで状態を保持するという難しさも加わる。最終回答だけでなく、そこに至るまでの手順も確認し、コスト、レイテンシ、ツールエラー、反復試行におけるリグレッションも追跡する必要がある。[6]

情報の出所と処理履歴は、各段階を結び付ける役割を果たす。すべての主張を、根拠となる情報源、途中で行った変換、結果を生んだ処理と結びつけたまま残す必要がある。W3CのPROV-Oは、このような情報の出所と処理履歴を、異なるシステム間で表現・交換するための共通モデルを提供している。[7] 企業で利用する場合、この履歴が、結果の確認・訂正、説明責任、必要な部分だけの再利用を支える。

出力は、人が読むだけでなく、次の処理でも使える形へ

最後に変わるのは、出力の形である。現在のAIワークフローでは、PDF、スライド、スプレッドシート、メッセージなど、人が読むための成果物を作ることが多い。次の処理でその成果物を使うには、もう一度解析し直す必要があり、そのたびにコストがかかり、構造を失うリスクも生じる。AIが情報を直接扱えるシステムであれば、人が読む画面と、ソフトウェアが再利用できる構造化データを同時に生成できる。前者は読みやすく操作でき、後者は情報の意味を保ったまま検索でき、アクセス権限に対応した形で再利用できる。情報の意味や出所を毎回作り直すことなく、次の処理へそのまま引き継げる。

企業のAIが向かう先は、単にモデルの自律性を高めることではない。AIに任せる範囲を管理し、根拠を追跡し、誤りが起きた段階を特定し、次の業務でも使える形で情報を残すシステムである。

目指すべきは、処理の流れが明確で、結果を測定できる情報システムである。状況に応じた判断が必要な部分はエージェントが動かし、正確さが重要な部分は、同じ入力に同じ結果を返す仕組みで制御する。この土台があれば、AIに任せる範囲を段階的に広げられる。土台を省けば、もっともらしい出力は作れても、システムが何を知り、何を許され、なぜその根拠を選び、どの段階で誤ったのかを説明することは難しい。

企業向けAIAIエージェント情報アーキテクチャAIガバナンス

よくある質問

企業のAIシステムはどこへ向かうのか

個別のモデル機能を使う段階から、AIが情報を直接扱えるシステムへ移りつつある。文書の読み取り、情報の意味と関係性の整理、必要な情報の取得、推論、権限管理、出所と履歴の記録、操作、評価を、一つの流れとして管理するシステムである。

企業向けのAIエージェントは、なぜコーディングエージェントより難しいのか

コーディングエージェントは通常、明確な文法、検索可能なファイル、同じ入力に同じ結果を返すツール、変更履歴、自動テストがそろった環境で動く。一方、企業内の情報はさまざまな文書やシステムに分散し、情報同士の関係やアクセス権の境界が曖昧で、正解を機械的に判定できないことも多い。そのため、必要な情報の選択、権限管理の徹底、結果の検証がはるかに難しくなる。

AIが情報を直接扱える仕組みとは何か

元資料を、意味と関係性を保ったデータへ変換し、保存・検索できる形に整え、質問に応じた探し方を選び、推論や操作に使う一連の仕組みである。各段階の結果と状態を記録することで、後から評価・改善できる。出力は人が読めるだけでなく、後続のソフトウェアからも再利用できる。

企業はAIエージェントをどのように評価すべきか

本番に近い条件でタスク全体を評価し、失敗を入力、文書の読み取り、情報の構造化、索引、検索、推論、操作の段階ごとに切り分ける。正確性と完全性に加え、権限、安全性、情報の出所と履歴、処理時間、コスト、人への確認手順、繰り返し実行した際の変化も追跡する必要がある。