しかし、その到来を待つことなく、世界のセキュリティコミュニティはすでに不可逆な転換点を超えている。2020年代前半、米国標準技術局（NIST）によるPost-Quantum Cryptography（PQC：耐量子計算機暗号）の標準化プロセスが最終段階を迎え、新たな連邦標準（FIPS）として結実しようとしているからだ。これは単なる技術仕様の改定ではない。インターネットの黎明期から現代に至るまで、デジタルの信頼を根底で支えてきたRSA暗号や楕円曲線暗号といった「現代暗号の終焉」と、それに代わる「次世代暗号への移行」という、数十年単位の巨大な地殻変動が始まったことを意味している。GoogleやCloudflareといったテクノロジーの巨人はすでにブラウザやネットワークレベルでの実装実験を繰り返しており、大手クラウドベンダーも水面下で対応を進めている。本稿では、まだ見ぬ脅威であるはずの量子計算機対策が、なぜ今、企業の喫緊の課題として浮上しているのか、そしてPQCへの移行が企業ITの長期戦略にどのような変革を迫るのかを、技術的背景と経営的リスクの両面から詳説する。

「Harvest Now, Decrypt Later」の脅威と標準化の加速

一般に、量子コンピュータによる暗号解読の話題が出ると、多くの経営者やIT責任者は「まだ実用化には時間がかかる」「自分が現役の間は関係ない」と捉えがちである。確かに、Shorのアルゴリズムを用いて現在の公開鍵暗号を現実的な時間で破るために必要な、大規模かつ誤り訂正機能を備えた量子コンピュータの実現は、依然として技術的なハードルが高い。しかし、企業が直面しているリスクの実体は、将来の解読能力そのものではなく、現在のデータが未来の時点で危険に晒されるという時間軸のズレにある。 セキュリティ業界で「Harvest Now, Decrypt Later（今収集し、後で解読する）」と呼ばれる攻撃手法への懸念が、各国の標準化を急がせる最大の要因となっている。攻撃者は、たとえ現時点では暗号を解読できなくとも、ターゲットとする企業の通信データや暗号化されたファイルを今のうちに大量に収集・保存しておくことが可能である。そして、将来的に十分な性能を持つ量子コンピュータが登場した瞬間に、過去に蓄積したデータを一気に解読にかけるのだ。このシナリオにおいて、暗号化通信の安全性は「通信している瞬間」だけでは完結しない。その情報が持つ機密性の保持期間と、暗号技術が破られるまでの期間の競走となる。

たとえば、国家機密に関わる外交文書、知的財産となる新薬の研究データ、あるいは個人の遺伝子情報や長期の金融資産記録などは、10年から数十年という極めて長い期間にわたって機密性を維持する必要がある。もし2030年代あるいは2040年代に量子計算機が実用化されると仮定すれば、今日送信されている長期保存データの多くは、すでに危険水域に入っていると言えるだろう。NISTが選定したCRYSTALS-Kyber（鍵共有方式、標準化名称：ML-KEM）やCRYSTALS-Dilithium（署名方式、標準化名称：ML-DSA）といった新しいアルゴリズムは、こうした「未来の脅威による現在のリスク」を封じ込めるための防波堤である。これらは従来の素因数分解や離散対数問題とは異なる、格子暗号などの数学的難問を安全性の根拠としており、量子計算機による攻撃に耐えうると考えられている。すでにこれらのアルゴリズムはFIPS（連邦情報処理標準）として文書化が進み、TLS（Transport Layer Security）やVPN、電子署名といった社会インフラの深層への組み込みが前提となりつつある。つまり、PQCは遠い未来の技術ではなく、すでに実装フェーズに入った「現代の技術」なのである。

アルゴリズムの「リプレース」を超えたシステム基盤への衝撃

PQCへの移行が企業ITにとって極めて厄介なのは、それが単なるソフトウェアのアップデートや、設定ファイルの書き換え程度では済まない可能性が高いという点にある。かつてDESからAESへ、あるいはSHA-1からSHA-2へと暗号アルゴリズムが移行した際も相応の労力を要したが、今回のPQC移行はそれらとは比較にならないほどシステム基盤への物理的・論理的なインパクトが大きい。 その最大の要因は、鍵サイズと署名データサイズの肥大化である。たとえば、鍵共有メカニズムであるML-KEMは、現在主流の楕円曲線暗号（ECDHなど）と比較して、鍵長や暗号文のサイズが桁違いに大きくなる傾向がある。同様に、電子署名に用いられるML-DSAも、従来のRSAやECDSAに比べて署名サイズが増大する。最新の高性能サーバーや太い帯域を持つバックボーン回線であれば、この程度のオーバーヘッドは許容範囲かもしれない。しかし、リソースが厳しく制限された環境においては、この「重さ」が致命的なボトルネックとなり得る。

具体的に影響が懸念されるのは、IoT（Internet of Things）やOT（Operational Technology）の領域である。工場内のセンサー、自動車の制御ユニット、スマートメーター、あるいは医療用埋め込みデバイスなどは、極めて限られたメモリと計算能力で動作しており、通信帯域も狭い場合が多い。ここにサイズの大きなPQCをそのまま導入しようとすれば、パケット分割による遅延の増大、メモリ不足による動作不安定、あるいはハンドシェイク処理によるバッテリー消費の激増といった問題が顕在化する恐れがある。 さらに、既存のプロトコルやデータフォーマットが、これほど大きな鍵や署名を格納することを想定していないケースも多々ある。X.509証明書にPQCの公開鍵や署名を埋め込んだ結果、証明書のサイズが肥大化し、従来のUDPベースの通信でパケットサイズ制限に抵触したり、古いミドルウェアがバッファオーバーフローを起こしたりするリスクも指摘されている。

また、移行期特有の複雑さとして「ハイブリッド暗号」の運用が挙げられる。PQCのアルゴリズムは比較的新しいため、将来的に未知の脆弱性が見つかる可能性を完全には否定できない。そのため、移行期間中は、長年の実績がある従来の楕円曲線暗号と、新しいPQCアルゴリズムを組み合わせて二重に鍵共有を行う「ハイブリッド方式」が推奨されている。これは安全性における保険としては合理的だが、システム運用側から見れば、管理すべき鍵の種類が増え、処理負荷が増大し、トラブルシューティングが複雑化することを意味する。既存のRSAやECDSAのみに対応したレガシー機器と、PQC対応の最新機器が混在する環境を、セキュリティポリシーの一貫性を保ちながらどう統合管理していくのか。企業は、ネットワーク機器の買い替えサイクルやアプリケーションの改修計画を含めた、長期的なロードマップの策定を迫られることになる。

暗号ライフサイクル管理（CLM）と「クリプト・アジリティ」の確立

このような技術的・運用的な課題を前にして、企業はどのような戦略を持つべきなのか。最も重要な視点は、PQC対応を単なる「20XX年問題」のような期限付きの対処療法として捉えるのではなく、組織全体の「暗号の管理能力（クリプト・アジリティ）」を抜本的に強化する機会と捉えることである。 クリプト・アジリティとは、使用している暗号アルゴリズムに危殆化（安全性が損なわれること）や脆弱性が発見された際に、システム全体への影響を最小限に抑えつつ、迅速かつスムーズに新しい安全なアルゴリズムへ切り替える能力を指す。これまで多くの企業システムでは、暗号アルゴリズムは一度実装されれば、システムが廃棄されるまで塩漬けにされることが一般的であった。アプリケーションのコードの中にハードコードされていたり、ハードウェアチップに焼き付けられていたりして、容易に変更できない構造になっていることが多かったのである。PQCへの移行は、こうした硬直的な構造を打破し、暗号部品をいつでも交換可能な「部品」として疎結合化するアーキテクチャへの転換を促すものである。

具体的な第一歩として求められるのは、自社のシステム資産における暗号依存関係の完全な棚卸しである。これを近年では「CBOM（Cryptography Bill of Materials：暗号部品表）」と呼ぶ動きもある。どのサーバーのどのライブラリで、どのバージョンのOpenSSLが動いているのか。独自開発のアプリケーション内で、どのような暗号関数が呼び出されているのか。外部と接続するVPN装置や、クラウドサービスとのAPI連携において、どの暗号スイートが使われているのか。そして何より、それぞれのシステムで扱われているデータの保存期間はどれくらいなのか。これらを網羅的に可視化しない限り、どこから手をつけるべきかの優先順位すら決めることができない。 特に、情報の「寿命」と暗号の「寿命」のギャップが大きい領域こそが、最優先で対策を講じるべきホットスポットとなる。たとえば、法定保存期間が長い文書管理システムや、製品寿命が20年に及ぶインフラ設備の制御システムなどは、汎用的なIT機器よりもはるかに早い段階でPQC対応、あるいはハイブリッド構成への移行計画を立てる必要があるだろう。逆に、数時間で価値を失う一時的なログデータや、短期間で破棄されるキャッシュデータであれば、直ちにコストをかけてPQCを導入する必要性は低いかもしれない。

結局のところ、Post-Quantum時代におけるセキュリティ戦略とは、来るべき量子コンピュータの脅威に怯えることではなく、自社が守るべき情報の価値と時間軸を再定義し、それを守るための技術基盤を「更新可能な状態」に保ち続けるプロセスそのものであると言える。量子技術の進展速度は、一企業のコントロールを超えた外部要因である。しかし、自社のシステムが古い暗号技術と心中するのか、それとも新しい技術を柔軟に受け入れられる体質に変わるのかは、経営の意思決定にかかっている。PQC標準化という波は、暗号という「見えないインフラ」を経営アジェンダへと押し上げ、静的だったセキュリティ運用を動的でしなやかなものへと進化させるための、強力な触媒として機能しているのである。

対話するAIから「目的を達成するAI」へ

多くの人にとって、LLMとの最初の接点は、ブラウザーやアプリを通じて行うチャット体験でした。質問を投げかけると、自然な文章で答えが返ってくる。その体験の延長線上にあるのがLLMエージェントですが、決定的な違いは「目的達成の主体」として設計されているかどうかという点です。

通常のチャットボットは、ユーザーからのプロンプトに対する一回ごとの応答に最適化されています。それに対してエージェントは、ユーザーが「ゴール」や「やってほしい仕事」を伝えると、その達成のために必要なサブタスクを自分で分解し、外部ツールを呼び出し、途中経過を踏まえて計画を修正しながら、最終的な成果物にたどり着こうとします。人間のアシスタントが、資料の調査からドラフト作成、修正提案まで一連の仕事を回してくれるのに近いイメージです。

ここでポイントになるのは、エージェントが「状態」を持つことです。単発のやり取りではなく、ある程度のスパンで進行するタスクの途中状況、すでに取得した情報、試行錯誤の履歴といったものを踏まえながら、次の行動を選択していきます。対話AIが「高度な検索窓」であるのに比べ、エージェントは「半自律的なプロジェクト・マネージャー」に近い存在だと捉えると分かりやすくなります。

LLMエージェントを構成する基本コンポーネント

LLMエージェントは、単に大規模言語モデルだけで成り立っているわけではありません。大雑把に言えば、頭脳としてのLLMに加えて、現実世界とつなぐためのインターフェースや、記憶・計画の仕組みが組み合わさって動いています。

中核にあるのは当然ながらLLMです。自然言語を理解し、計画を立て、次の行動を文章として生成する役割を担います。しかしLLM単体では、ブラウザーを開いたり、表計算ソフトでデータを処理したり、社内システムから情報を取得したりすることはできません。そこで登場するのがツール呼び出し機能です。LLMが「今このAPIを呼び出すべきだ」「このデータベースを検索すべきだ」と判断したとき、その指示をもとに外部の関数やサービスが実際の処理を実行し、結果をふたたびLLMに返します。

もう一つ重要なのがメモリです。単純なチャットであれば、数ターン分の文脈を保持すれば十分ですが、エージェントは数十分から数時間、場合によってはもっと長いスパンでタスクを追いかけます。そのため、取得した情報や中間成果物を整理して保存し、必要なときに取り出せる仕組みが必要になります。エピソード的な会話履歴を保持する短期メモリ、プロジェクトをまたいで再利用する長期メモリ、ユーザーの好みやワークフローに関する知識を蓄積するプロファイル的メモリなど、いくつかの層に分けて設計されることも増えています。

そして最後に、全体の流れを組み立てるプランニングの機構があります。目標から逆算してタスクを分割し、優先順位をつけ、実行順序を決め、途中で状況が変われば計画を修正する。こうしたプロセスは、人間のプロジェクトマネジメントのごく自然な作法ですが、LLMにとっても同様に重要です。最近のエージェントフレームワークでは、LLMに自分の「思考過程」を言語化させることで、このプランニング能力を引き出す設計がよく用いられています。

RAGや従来の自動化との違いと補完関係

実務の現場では、LLMエージェントは、すでに広がりつつあるRAG（Retrieval-Augmented Generation）や既存のワークフロー自動化ツールとどう関係するのか、という疑問をよく生みます。RAGは、社内文書やナレッジベースから関連情報を検索し、それを踏まえて回答を生成する仕組みです。つまり「どの情報を参照するか」を賢く選べる検索付きのチャットボットだと言えます。

これに対してエージェントは、RAGを含めたさまざまなツールを統合し、「何をすべきか」から考えることができます。例えば、ある製品についての社内ドキュメントを整理して顧客向けの提案書を作るタスクを考えてみましょう。RAG単体であれば、関連資料を探して要約するところまでが主な役割ですが、エージェントはそこからさらに、提案書の構成案を作り、必要な図表を生成し、過去の提案事例を引き合いに出しながら、最終的なドラフトを仕上げるところまでを担えます。その過程では、RAGによる検索や、表計算ソフトの操作、テンプレート管理システムへのアクセスなど、複数のツールが組み合わされていきます。

既存のRPAやワークフロー自動化ツールとの関係も同様です。ルールがはっきり定義され、例外が少ない処理は、従来型の自動化の方が安定して動作します。一方で、入力の揺れや例外処理が多く、人間の判断が必要だった領域こそが、エージェントの出番です。つまり、ルールベースの自動化とLLMエージェントは、競合というより「硬い自動化」と「柔らかい自動化」として補完関係にあると言えます。

現在の限界と、数年先に見えている風景

こうした魅力的な特徴を持つエージェントですが、現時点ではいくつかの本質的な限界も抱えています。第一に、LLM自体の幻覚問題が完全には解決していないことです。エージェントが外部のツールやデータにアクセスすることで、事実ベースの判断は改善しますが、それでもなお、存在しないAPIを「ある」と思い込んだり、仕様を誤解したりするリスクは残ります。第二に、長期のタスクにおける一貫性の維持が難しい点です。セッションをまたぐタスクや、複数の担当者が介在するワークフローの中で、エージェントが「前回の文脈」を適切に再構成できるようにするには、メモリやログ管理のさらなる工夫が不可欠です。

また、責任の所在も重要なテーマです。エージェントが勝手にメールを送り、誤った契約条件を提示してしまったとき、責任は誰が負うのか。現実的には、権限を段階的に制限し、人間による最終確認を必須にするなど、ガバナンスの枠組みを組み合わせて運用する必要があります。

それでも、数年先を見渡すと、エージェントがビジネスや生活のさまざまな場面で「当たり前のインフラ」になっている光景は十分に想像できます。メール返信やスケジュール調整といった個人レベルの作業から、レポート作成、調達業務、顧客対応の一部まで、複数のエージェントが分担しながら裏側で動き続ける世界です。人間は細かい操作から解放され、問いを立て、判断し、方向性を決めることにより多くの時間を割くようになるでしょう。

LLMエージェントとは、単なる「賢いチャットボット」ではなく、情報システムと人間の仕事の関係そのものを組み替えていく存在です。その全体像を理解することは、自分の仕事や組織をどう変えていくかを考える出発点でもあります。

観察・思考・行動のループとしてのエージェント

LLMエージェントを理解するうえで役に立つのが、観察、思考、行動という三つのステップを繰り返す存在だと捉える視点です。エージェントは、まず現在の状況を「観察」します。ここには、ユーザーからの最新の指示、これまでの会話履歴、ツールから返ってきた結果、メモリに保存されている過去の情報などが含まれます。それらを入力として、LLMが「今何が起きているのか」を言語的に再構成します。

次に、その状況を踏まえて「思考」を行います。ゴールは何か、現在の進捗はどこまでか、この先にどんなサブタスクが必要か、どのツールを呼び出すべきか、あるいはユーザーに追加の質問を投げかけるべきかといったことを、LLMが内部で推論します。最近のエージェント設計では、この思考過程そのものを半ば明示的に文章として出力させることで、より良い計画を立てさせる工夫もよく採用されています。

そして最後に「行動」です。ここでは、具体的なAPI呼び出しの指示や、ユーザーへの応答、外部システムへの書き込みといったアクションが選択されます。ツール呼び出しの形式で行動を表現することで、LLMは「このAPIをこういう引数で呼んでほしい」という意図をホスト側に伝えます。実際のAPI呼び出し自体は、LLMの外側にあるランタイムが担い、その結果を再び観察フェーズに戻してループが続きます。

この観察・思考・行動のサイクルが、エージェントの「生命活動」のようなものです。単発の質問応答ではなく、複数回のループを通じて段階的にゴールへ近づいていく姿が、エージェントならではの振る舞いを生み出します。

ツール呼び出しがエージェントに与える「手足」

LLM単体は、テキストの範囲では非常に強力ですが、現実世界のデータやシステムに直接アクセスする能力は持っていません。そこで重要になるのがツール呼び出しの仕組みです。ツールとは、検索エンジンやデータベースクエリ、SaaSのAPI、コード実行環境、メール送信機能など、外部の機能を抽象化したものです。

エージェントにとってツールは、人間で言えば手足や感覚器官に近い存在です。ウェブ検索ツールを使うことで最新の情報を取得でき、社内RAGツールを使うことで自社のナレッジベースにアクセスでき、カレンダーツールを使うことで予定の確認や調整を行えます。LLMは、「今は情報が足りないから検索した方が良い」「この数値は計算が必要だからコード実行ツールを使おう」といった判断を文章として出力し、その意図に応じてツールが発火します。

興味深いのは、ツール呼び出しの設計次第で、エージェントの能力が大きく変わることです。たとえば、あるCRMに対して読み取り専用のAPIツールしか与えられていなければ、エージェントは情報閲覧とレポート作成しかできません。しかし、顧客レコードの更新やメール送信の権限を持つツールを与えれば、フォローアップの自動化やステージ更新など、より攻めの役割を担えるようになります。その反面、誤操作のリスクも高まります。どこまでの権限をどのツールに与えるかは、エージェント設計におけるガバナンスそのものと言えます。

ツールはまた、エージェントの「弱点」を補う役割も果たします。長い数式の計算や、膨大なデータを対象とする集計処理は、LLMに任せるよりも、専用のコード実行環境やデータベースに任せた方が正確で高速です。LLMは、何をどう計算してほしいかを自然言語からSQLやコードに変換し、その結果だけを受け取って次の思考に活かすことで、自身の限界を乗り越えていきます。

メモリとマルチエージェントがもたらす「継続性」と「役割分担」

エージェントが現実的なタスクで力を発揮するためには、記憶の扱いが欠かせません。一回のセッション内での短期的な記憶だけでなく、別の日の会話や過去のプロジェクトから得た知見を活かせるかどうかが、実用性を大きく左右します。

短期メモリは、主に当該タスクに関わる会話履歴や中間結果を保持します。問題は、LLMのコンテキスト長には限界があることで、長期タスクになるとすべてをそのまま詰め込むわけにはいきません。そこで、重要度の高い情報だけを要約して保持したり、トピックごとに分割して外部ストアに保存したりする工夫が必要になります。長期メモリは、ユーザー固有の好みや過去の選好、以前に成功した解決策などをストックし、新しいタスクに対する初期提案の質を高める役割を持ちます。

さらに進んだ設計として、複数のエージェントを役割分担させるマルチエージェント構成があります。一つの巨大なエージェントに何でもかんでも押し込むのではなく、情報収集特化のエージェント、プランニングに特化したエージェント、文章生成に特化したエージェントなどを用意し、それぞれがメッセージをやり取りしながら仕事を進めます。その中心には、全体の進行を管理するオーケストレーターが置かれ、各エージェントの出力を評価しつつ、次に誰に何をさせるかを決めていきます。

このような構造にすることで、システムのモジュール性が高まり、個々のエージェントを独立して改善しやすくなります。一方で、エージェント同士の対話が冗長になってしまったり、責任の所在が分かりにくくなったりする課題もあります。内部構造をどう切り分け、どのレベルまでをユーザーや開発者に見えるようにするかは、今まさに試行錯誤が続いている領域です。

エージェントの内部構造を理解することは、単に技術的な興味を満たすだけではありません。どこで誤りが生まれやすいのか、どの部分に安全装置を入れるべきか、どこを改善すればユーザー体験が向上するのかを見極めるための基盤にもなります。ブラックボックスに見えるエージェントの中で、観察・思考・行動、ツール、メモリ、多数のエージェントたちがどのように協奏しているのか。そのイメージを持つことが、次の一歩の設計につながっていきます。

それが「Agentic AI（エージェンティックAI）」、すなわち自律型エージェントへの進化である。これまで人間が画面を見ながらデータを探し、判断を下し、システムに入力し、結果を記録していた一連の業務プロセスそのものを、AIが連続的かつ自律的に代行する段階へと突入しつつあるのだ。これは単にAIが便利になるという話ではない。AIが人間の「相談相手」から、実務をこなす「同僚」あるいは「部下」としての座席を確保し始めたことを意味しており、企業ITのアーキテクチャや組織内の権限構造そのものに不可逆的な変容を迫るものである。生成AIは文章や画像を生み出すが、Agentic AIは具体的な成果や進捗を生み出す。両者は技術的な系譜としては同じ線上にあるものの、ビジネスや組織に与えるインパクトの質においては、まったく異なる次元の存在と言えるだろう。

「回答者」から「遂行者」へ――主要クラウドが描く業務実行レイヤの覇権

従来型の生成AIとAgentic AIの決定的な違いは、その振る舞いの主目的が「出力」にあるか「行動」にあるかという点にある。これまでのAIは、膨大な知識ベースからもっともらしい回答を生成することに特化していたが、その回答を現実の業務アクションに変換する「ラストワンマイル」の接続は人間が担っていた。メールの文案をAIに作らせても、それをメーラーに貼り付けて送信ボタンを押すのは人間であり、分析コードを書かせても、それを実行環境で走らせるのはエンジニアの役割だった。Agentic AIはこの境界線を踏み越える。ユーザーが抽象的な目標を与えれば、AI自らがタスクを細分化し、外部のAPIやデータベースにアクセスし、必要な情報を取得して判断を下し、手続きを実行し、仮にエラーが出れば別の手段で再試行するという、一連のループを自律的に回すのである。これはもはやツールというよりも、システム全体の上位に位置する「業務実行レイヤ」と呼ぶべき新たな階層の出現である。

この変化を象徴するように、Microsoft、Google、AWSといった主要クラウドベンダーは、こぞって自社のプラットフォームの中核にエージェント機能を据え始めている。MicrosoftはCopilot Studioを通じて、TeamsやOutlookといった日常的なコミュニケーションツールとバックエンドの基幹システムをAIが自由に行き来できる環境を整備しつつある。GoogleはVertex AI Agentsによって、対話型インターフェースから社内システムへのシームレスな接続を実現し、AWSのBedrock Agentsはクラウド上の膨大なリソースと生成AIを直結させることで、高度なタスク実行能力を提供しようとしている。これら三社の動きが示唆するのは、Agentic AIが一部の先進的な企業が試す実験的な技術ではなく、仮想化やコンテナ技術、あるいはゼロトラストセキュリティと同様に、今後の企業ITシステムを構築する上で避けては通れない「標準装備」になりつつあるという事実だ。ベンダー各社は、AIが単に賢いだけでなく、実際に手を動かせる存在になることが次のプラットフォーム競争の主戦場になると確信しているのである。

しかし、機能が提供されることと、それが現場で価値を生むことは同義ではない。エージェントが滑らかにタスクを遂行するためには、AIがアクセスすべきAPIが整備され、権限管理が適切になされ、データの所在が明確化されている必要がある。人間なら「あのファイルの場所を適当に探しておいて」で済むような曖昧な指示も、システム間連携を前提とするAIにとっては致命的な障害となりうる。つまり、Agentic AIの導入とは、単に新しいソフトウェアをインストールすることではなく、AIが動き回れるように社内の情報構造や業務フローを「AIフレンドリー」な形へと再設計する、大規模な整地作業を伴うプロジェクトなのである。

柔軟性と統制のジレンマ――RPAとの決別と「責任」の再設計

Agentic AIの台頭は、これまで業務自動化の主役であったRPA（ロボティック・プロセス・オートメーション）との比較において、その革新性と危険性の両方を浮き彫りにする。RPAは「定型業務の高速な反復」を得意とし、事前に決められた手順を忠実に守ることで価値を発揮してきた。そこには判断の入り込む余地はなく、想定外の事態が起きれば停止することが「正解」とされる世界だった。対してAgentic AIは、目標達成のために手順を自ら生成・選択する「推論」のプロセスを含んでいる。未知の状況に遭遇しても、AIはその時点で最適と思われる行動を選択して処理を継続しようとする。この「止まらずに進み続ける能力」こそがAgentic AIの最大の武器であり、同時に最大の管理リスクでもある。RPAの停止は業務の遅延を招くだけだが、Agentic AIの誤った推論に基づく自律的な処理は、誤発注や誤送信、不適切なデータの書き換えといった実害を、人間が気づかないスピードで拡大させる恐れがあるからだ。

ここで問われるのは、技術的な精度よりもむしろ「ガバナンスの設計」である。AIが自律的に判断して処理を進めた結果、問題が発生した場合、その責任を誰がどう負うのか。AIは責任主体にはなり得ないため、最終的にはそのAIを監督する人間か、あるいはそのような権限を与えた組織の責任となる。従来、人間が業務を行う際には、経験や常識といった暗黙知が安全装置として機能していたが、AIにはそれがない。したがって、Agentic AIを運用するためには、AIがどのような推論を経てその行動に至ったのかを事後的に追跡できる詳細なログ基盤や、AIが越えてはならないガードレールの厳密な定義、そして「どのレベルの確信度であれば実行してよいか」という閾値の設計が不可欠となる。

さらに、この変化はBPM（ビジネス・プロセス・マネジメント）の在り方にも波及する。これまでのBPMは業務の標準化と可視化を目指してきたが、Agentic AIは標準化しきれない「ゆらぎ」のある業務領域にまで自動化の範囲を広げようとする。標準的な処理は従来のシステムやRPAに任せ、例外的な判断が必要な部分は人間が担うというのがこれまでの常識だったが、Agentic AIはその中間領域、すなわち「完全な定型ではないが、ある程度の文脈理解があれば処理できる業務」を浸食していく。結果として、人間が担うべき領域はさらに高度な判断や、倫理的な決定、あるいはAIの挙動を監視・評価するというメタ的な業務へと押し上げられることになる。これは業務の効率化であると同時に、業務プロセスの管理手法そのものが、静的なフロー図の管理から、動的なエージェントの振る舞いの管理へとシフトすることを意味している。

「操作」から「監督」への不可逆な移行――人間から失われる学習機会と新たな技能

Agentic AIが業務プロセスの深部に入り込むにつれて、現場で働く人間に求められるスキルや役割もまた、劇的な変質を遂げることになる。これまでは、新人はまず単純な作業やデータ入力を繰り返すことで業務の流れやデータの意味を肌感覚として理解し、そこから徐々に高度な判断業務へとステップアップしていくのが通例だった。しかし、Agentic AIが単純作業のみならず、ある程度の一連のタスク遂行までを担うようになれば、人間が「手を動かして覚える」という機会は必然的に減少する。最初からAIが作成した成果物のチェックや、例外処理の判断といった、経験を必要とする業務がいきなり求められるようになるのだ。これは「初心者が熟達するための階段」が失われることを意味しており、中長期的には組織内の人材育成システムに深刻な空洞化をもたらすリスクを孕んでいる。

また、人間とAIの関係性は「道具と使用者」から「監督者と実務者」へと変化する。これまでのツールは人間が意図を持って操作する対象だったが、エージェントは人間に代わって操作を行う主体となる。人間はAIが提示した結果やプロセスをレビューし、それが妥当であるかを判定し、承認を与えるゲートキーパーとしての役割を担うことになる。ここで重要になるのは、自ら手を動かすスキル以上に、AIの思考プロセスを逆算して理解する能力や、AIがなぜその結論に至ったのかを解釈し、必要に応じて他者に説明できる「言語化能力」である。AIは作業を代替してくれるが、説明責任までは代替してくれない。むしろ、ブラックボックス化しやすいAIの挙動に対して、なぜその判断が組織として許容されたのかを論理的に説明する責任は、以前にも増して重く人間にのしかかることになる。

さらに、AIが処理を進める速度と量が人間の認知限界を超えたとき、人間は実質的にAIの判断を「盲信」せざるを得ない状況に追い込まれる可能性がある。これを防ぐためには、AIを導入する際、単に自動化率を追うのではなく、「人間が制御可能な範囲でAIを動かす」という勇気ある制約の設定が必要になるかもしれない。技術的には可能であっても、組織の統制能力を超えた自動化は採用しないという経営判断、あるいは「どこで人間が介入するか（ヒューマン・イン・ザ・ループ）」を意図的に設計する思想が求められるのである。

Agentic AIは、過去のITトレンドのように既存の業務を単に便利にするだけの「拡張」ではない。それは業務の主体を人間から機械へと部分的に、しかし確実に移譲していく「断層」のような変化である。企業はこの断層を前にして、システムアーキテクチャの刷新だけでなく、責任の所在、人材の定義、そして「人間は何をすべきか」という根本的な問い直しを迫られている。生成から遂行へ。この静かなる革命は、私たちが慣れ親しんだ仕事の風景を、二度と元には戻らない形で書き換えようとしているのである。

かつて、ファイルサーバのディレクトリ階層を辿り、目当てのファイルを探し当てることが業務の前提であった時代から、全文検索エンジンの登場によってキーワード一つで資料への到達時間が劇的に短縮された時代へと、我々は歩みを進めてきた。しかし、いかに検索技術が高度化し、メタデータによる分類が精緻になったとしても、長らく解消されなかった本質的なボトルネックが存在する。それは、検索によって得られた膨大な情報を人間が読み込み、内容を理解し、必要な部分を抽出して文脈に合わせて再構成するという、極めて属人的かつ高負荷な認知プロセスである。これまで「知的生産」と呼ばれてきた業務の大半は、実はこの情報の探索と加工という準備作業に費やされていたと言っても過言ではない。

生成AIの登場、とりわけRAG（Retrieval-Augmented Generation：検索拡張生成）というアーキテクチャの確立は、この「情報の後処理」を自動化する歴史上初めての技術的特異点である。多くの議論においてRAGは「AIに社内データを参照させて回答させる技術」として矮小化されて語られがちであるが、その本質は単なる機能追加の範疇には収まらない。RAGとは、企業情報の流れを「人間が探して読む」というプル型の構造から、「問いかければ最適な解が生成される」というオンデマンドの合成プロセスへと根本から書き換える、情報基盤の設計思想そのものである。知識はもはや、フォルダの中に静かに眠る保管物ではなく、参照されるたびにAIによって文脈を与えられ、再構築される動的な素材へと変貌を遂げる。この不可逆的な変化を経営視点および現場視点で正しく捉え、情報資産のあり方を再定義できるかどうかが、来るべきAI時代の企業の競争力を決定づける分水嶺となるだろう。

検索の「裏方化」と問われる回答の質──インターフェースからバックエンドへの転換

長きにわたり、検索エンジンはナレッジマネジメントの主役であり、従業員が最初に対峙するインターフェースであった。検索窓にキーワードを打ち込み、表示された十件、二十件のリストの中から確からしいものをクリックし、中身を目視で確認する。この一連のプロセスにおいて、検索エンジンの役割は「目的の文書への最短経路を示すこと」で完結しており、その後の情報の真偽判定や統合はすべてユーザーの脳内に委ねられていた。しかし、RAG環境下において、この構造は劇的に反転する。検索という行為は、エンドユーザーが直接行う作業から、生成AIが回答を作成するために必要な「素材集め」の工程へと、その役割をバックエンドへと移すことになるのである。

これに伴い、検索技術に求められる価値基準も根本的な変質を迫られる。従来の検索システムにおける「正解」とは、ユーザーが求めているキーワードを含んだ文書を漏れなく、かつ上位に表示することであった。そこでは、ドキュメント全体の整合性や、その情報が最新であるか否かの最終判断は人間が行うため、多少のノイズが含まれていることは許容されていた。ところが、RAGにおいては検索結果がそのままAIによる回答生成の原材料となるため、検索の質が直ちに生成物の品質、ひいては企業の意思決定の精度に直結することになる。もし検索フェーズで、矛盾する古い規定や、不正確な記述を含んだドキュメントが抽出されれば、AIはそれらを統合して、極めてもっともらしい嘘、いわゆるハルシネーションを引き起こす原因となる。

したがって、これからの検索技術には、単なるキーワードマッチングを超えた、文脈理解の深度が求められるようになる。ユーザーの質問の意図を汲み取り、「どの資料が最も回答に適しているか」だけでなく、「どの資料を組み合わせれば矛盾のない回答が構成できるか」という、編集者に近い視点での選別能力が不可欠となる。検索はもはや、人間に対して結果を提示する「表示の技術」ではなく、AIに対して最適なコンテキストを供給する「生成の基盤」として再定義される。検索画面というインターフェースが我々の目の前から徐々に姿を消し、チャットボットや対話型UIの背後で黒子として機能するようになったときこそ、真の意味で検索がインフラ化したと言えるのであり、その静かなる交代劇こそが現在進行している変化の実相なのである。

機械可読性が決定づける組織の知能指数──「人間が読む文章」から「AIが解釈するデータ」へ

RAGの実装を単なるITツールの導入プロジェクトとして捉えている企業は、早晩、大きな壁に直面することになるだろう。なぜなら、RAGの本質的な成功要因は、AIモデルの性能や検索エンジンのアルゴリズムといった技術的な側面よりも、むしろ参照元となる社内文書の品質と構造、すなわち「データガバナンス」にあるからである。これまで企業内で作成されてきた文書の多くは、人間が読むことを前提とした「行間を読む」文化の中で育まれてきた。文脈に依存した曖昧な表現、暗黙知として共有されている用語、更新履歴が不明確なまま放置された旧版ファイル、そして作成者しか理解できない独特のフォーマット。これらは人間同士のコミュニケーションであれば、阿吽の呼吸や事後確認によって補完が可能であったが、AIにとっては致命的なノイズとなり、回答の精度を著しく低下させる要因となる。

RAGが正常に機能するためには、ドキュメントそのものが高度に規格化され、機械可読性を備えている必要がある。例えば、文書のタイトルや見出しが論理的な階層構造を持っているか、改訂履歴や有効期限がメタデータとして明確に付与されているか、そして何より、事実と意見が峻別されて記述されているかといった、ドキュメンテーションの作法が厳密に問われることになる。統一されていないフォーマットや、新旧が混在するカオスなフォルダ構成のままAIを導入することは、誤った地図を持たせて航海に出るようなものであり、結果としてAIは誤読を増幅させる装置になり下がるリスクを孕んでいる。

このことは、従業員の「書く」という行為の意味を変容させる。これまでの文書作成は、上司への報告や後任への引継ぎといった「人間への説明責任」を果たすためのものであったが、これからは「AIへの生成責任」を果たすためのコーディングに近い作業へとシフトしていく。文章の質とは、文学的な流麗さや読みやすさではなく、論理的な明快さと構造的な堅牢さによって評価されるようになるだろう。つまり、ナレッジマネジメントの主戦場は、AIツールの選定から、泥臭い文書管理のルール作りや、情報を構造化して残すという組織文化の醸成へと移行する。情報を「残すために書く」のではなく、「AIが正しく扱えるように書く」。このパラダイムシフトに適応できる組織だけが、AIという強力なエンジンを搭載し、組織全体の知能指数を飛躍的に高めることができるのである。

ストック型からフロー型への不可逆な転換──静的な知識管理の崩壊と動的な知の循環

従来のナレッジマネジメント、とりわけFAQ（よくある質問と回答）の運用は、典型的なストック型のモデルであった。想定される質問に対して固定的な回答を用意し、データベースに格納する。利用者はその固定された知識を検索して参照する。このモデルの最大の欠点は、情報の鮮度維持にかかるコストの高さである。業務内容や規定が変更されるたびに、膨大なFAQを手動で更新し続けることは現実的に困難であり、結果として多くの企業で「死んだFAQ」が大量に放置される事態を招いてきた。しかし、RAGの導入は、この静的な知識管理の概念を根底から覆し、知識をフロー型の動的なプロセスへと転換させる力を持っている。

RAG環境下において、「回答」という固定物は存在しない。存在するのは、議事録、設計書、チャットログ、マニュアルといった、日々生成される生の情報の断片だけである。ユーザーが質問を投げかけた瞬間、AIはこれらの断片的な情報源を横断的に検索し、その時点での最新情報を統合して、その場限りの回答を「生成」する。つまり、回答はあらかじめ用意されているものではなく、必要が生じた瞬間にのみ合成されるフロー上の現象となる。これにより、FAQをメンテナンスするという概念自体が過去のものとなり、代わりに重要になるのは、情報の発生源である一次資料を常に最新の状態に保つこと、そして古い情報には適切にアーカイブフラグを立てて参照対象から外すという、情報のライフサイクル管理である。

MicrosoftやGoogle、AWSといった主要クラウドベンダーが、自社のプラットフォームにRAGの機能を標準実装し始めている動きは、この変化が一部の先進企業だけのものではなく、あらゆる企業のデファクトスタンダードになることを示唆している。議事録の修正が即座に全社員のAIアシスタントの回答に反映され、設計変更の通知が瞬時に技術サポートの回答内容を書き換える。このように、情報の入力と出力がタイムラグなく同期する世界では、知識は「溜め込む資産」ではなく、「循環し続ける血液」のような存在となる。ナレッジが循環する速度こそが企業の意思決定スピードとなり、古い知識が自然淘汰されるエコシステムが組織内に構築される。

結論として、RAGという技術の到来は、我々に「保存」から「循環」への意識変革を迫っている。企業の情報資産が未来へと継承される価値を持つかどうかは、どれだけ大量の文書を保存しているかではなく、それらがどれだけAIによって参照されやすく、再利用可能な状態で維持されているかにかかっている。人間は判断と創造に集中し、AIが膨大な過去の集積から現在に必要な解を紡ぎ出す。検索と生成が融合した新しい情報基盤の上で、企業の知的生産活動は、より創造的で、より本質的な領域へと進化を遂げることになるだろう。

クラウドコンピューティングと人工知能の急速な進展は、情報の生成と流通を劇的に加速させた一方で、その情報の「寿命」を皮肉にも不安定なものへと変質させてしまった。かつては物理的な場所を占有することで存在を主張していた記録たちは、今や電気信号の奔流となり、サーバーの更新、クラウドサービスの終了、あるいはファイルフォーマットの非互換化といった極めて技術的かつ契約的な要因によって、瞬時にして無へと帰すリスクを常に孕んでいる。「保存」することと「廃棄」することの境界線がかつてないほど曖昧になりつつある今、私たちはどのようにして文明の証たる“デジタルの記憶”を未来へと継承していくべきなのか。本稿では、その背後にある制度的な不備、技術的な限界、そして文化的な構造の脆弱さを深く掘り下げていく。

クラウドという名の砂上の楼閣――サービスの終了とデータの「蒸発」

クラウドストレージの普及は、私たちに「データはどこか安全な場所に、永続的に存在する」という幻想を抱かせた。しかし現実は、クラウドとはあくまで他人のコンピュータを借りているに過ぎず、そこにあるのは強固な岩盤ではなく、契約という名の不安定な地盤の上に築かれた砂上の楼閣であると言わざるを得ない。その脆さが露呈した象徴的な出来事として記憶に新しいのが、Googleによるサービス終了の事例である。Googleは2022年8月、IoTデバイスのデータ管理プラットフォームであるGoogle Cloud IoT Coreの終了を唐突に発表し、翌2023年8月16日には実際にサービスを完全停止した。これにより、世界中の企業が膨大なIoTログデータの移行対応に追われることとなった。また同時期である2023年の夏には、クラウドストレージ大手のDropboxが、法人向けAdvancedプランで提供していた無制限ストレージの廃止を決定し、容量上限を導入するという方針転換を行った。これにより、無制限の保存容量を前提として長期的なデータアーカイブ戦略を立てていた多くの研究機関やメディア企業は、根本的な計画の見直しを迫られる事態となった。

これらの事例が浮き彫りにしたのは、単なる一企業のサービス変更という次元を超えた、より深刻な構造的問題である。それはすなわち、「データの終わり方」に対する社会的合意や法的なセーフティネットが依然として欠如しているという事実だ。クラウドサービスプロバイダーは一般的に極めて高い可用性と堅牢性を誇るが、その信頼性はあくまで有効な契約期間内においてのみ保証されるものである。契約が終了した瞬間、あるいは事業者が撤退を決めた瞬間、そこに蓄積された膨大なデータは「資産」から「削除対象」へと転落する。特に近年主流となっているSaaS（Software as a Service）形式の業務システムにおいては、サービス提供終了時にデータのエクスポート機能が著しく制限されるケースも散見される。CSV形式での簡易的な出力しか認められず、長年蓄積してきた履歴データ間のリレーションシップや、誰がいつ承認したかといった重要なメタデータが欠落してしまうリスクは、企業のコンプライアンス維持にとって致命的となり得る。

同様の危機は、私たちの社会基盤を支える行政機関においても静かに、しかし確実に進行している。内閣府が実施した令和6年の「地方公共団体における公文書管理の取組に関する調査」によれば、多くの市区町村で文書管理システムの導入自体は進んでいるものの、その保存・廃棄・移管に関する運用ルールは自治体ごとにまちまちであり、統一的な基準が確立されていない現状が明らかになっている。国立公文書館やデジタル庁が公開している資料においても、システム更新時におけるデータ形式の互換性維持や、移行プロセスにおけるメタデータの完全性保持が繰り返し課題として挙げられているが、現場レベルでの解決には至っていない。クラウドの技術的信頼性がいかに向上しようとも、利用規約の変更一つ、あるいは独自のプロプライエタリな仕様の変更一つで、「記録が物理的には存在するが、誰も読むことができない」という状況は容易に生まれ得る。真に永続的な保存を可能にする仕組みを構築するためには、単なるストレージ契約の延長線上で考えるのではなく、社会共通のインフラストラクチャーとしての「デジタルアーカイブ」を再定義する必要があるのだ。

真正性の危機と技術的負債――「読める」ことと「証明できる」ことの乖離

企業活動や公的な記録管理において、単にデータを「保管しておく」ことと、それを長期にわたって「検証可能な状態で維持する」ことの間には、深淵な隔たりが存在する。会計、契約、医療研究、品質管理、安全保証といった多くの業務領域には、法律による厳格な記録保存義務が課されている。しかし、現行の多くの制度は、データを作成した時点での真正性の確保や、物理的な保存期間の規定には注力しているものの、その後の数十年間にわたる技術環境の変化に伴う「継続的な検証可能性」の維持については、十分な解像度でカバーしきれていないのが実情である。デジタルデータは、紙の書類のように書庫に入れて鍵を掛けておけば済むものではない。そこには常に、技術的陳腐化という静かなる脅威が忍び寄っているからだ。

具体的に直面する課題は多岐に渡る。例えば、電子署名に用いられる暗号アルゴリズムは、計算機能力の向上と共に危殆化のリスクに晒され続ける。今日安全とされる署名も、10年後には容易に解読あるいは偽造が可能になっているかもしれない。そのため、定期的に暗号鍵をローテーションし、より強固なアルゴリズムでタイムスタンプを再付与し続けるという、終わりのないメンテナンス作業が不可欠となる。また、ファイルフォーマットの問題も深刻だ。特定のアプリケーションでしか開けない独自形式のデータは、そのソフトウェアのサポート終了と共に「電子のゴミ」となる運命にある。さらに、あるデータが作成されてから現在に至るまで、改ざんされていないことを証明し続ける「チェーン・オブ・カストディ（証跡の連鎖）」の保全も、システムリプレースやクラウドベンダーの変更というイベントが発生するたびに分断される危機に瀕する。データ移行プロジェクトにおいて、コストや工数を優先するあまり、過去の監査ログや詳細な履歴情報を切り捨ててしまい、後年の法的紛争や監査において「当時の完全性」を再現できなくなる悲劇は、決して珍しいことではない。

形式上の保存要件を満たしていたとしても、10年、20年という時間の経過を経た後で、その記録の同一性、完全性、可監査性をどこまで厳密に再構成できるかは、全く別の論点である。ユーザーID体系の変更による作成者の特定不能、外部資料へのハイパーリンク切れによる文脈の喪失、メタデータのマッピングミスによる情報の変質、ログ粒度の差異による追跡可能性の低下など、移行作業の細部に宿る悪魔が、将来の検証手続きの成否を決定づける。また、法定保存期間という「最低限の基準」を満たすだけでは、企業価値の維持という観点からは不十分な場合が多い。新薬開発における研究データ、製造業における品質トレーサビリティ、企業のブランドを形作るデザインアーカイブや歴史的記録などは、法律が定める期間を遥かに超えて、その組織の正当性や価値を証明する資産として機能し続ける。したがって、デジタルデータの保存とは、単にIT部門が処理すべき技術的なタスクではなく、組織の過去と未来をつなぐ経営判断の領域にある重大事なのである。

この課題に対し、現実的なアプローチとしては、冗長化と検証技術の高度な組み合わせが模索されている。マルチクラウドによる地理的・ベンダー的な分散保管や、一度書き込むと消去や変更が不可能なWORM（Write Once Read Many）形式のストレージの活用、そしてブロックチェーン技術などを応用した電子署名の連鎖管理などがその代表例である。これらは単なるバックアップではなく、「誰が、いつ、どの情報にアクセスし、何を操作したか」という完全な監査証跡を、技術的担保をもって未来へ送り届けるための枠組みである。しかし、そこには常にコストとのトレードオフが存在する。例えば、AWS S3 Glacier Flexible Retrievalのようなアーカイブ用ストレージは安価だが、データの取り出しには数時間を要し、より深い階層のDeep Archiveでは最大48時間を要する場合もある。安価な保存手段ほど、いざという時の復元時間と運用負荷が増大するという現実は、長期保存における経済性と安全性のバランスをいかに取るかという、高度なリスクマネジメントを要求している。

一方で、より未来を見据えた先端技術の研究も進んでいる。磁気テープという枯れた技術が見直される一方で、マイクロソフトとワシントン大学の研究チームが進めるDNAストレージのように、生物のDNA分子にデジタル情報を符号化し、極めて高密度かつ数千年単位での保存を可能にする技術の実証実験も行われている。また、国際的な標準化の動きも加速しており、欧州委員会のeArchiving Initiativeは、将来にわたる相互運用性を担保するためのパッケージ仕様を策定し、ISO16363などの国際規格は信頼できるデジタルリポジトリの評価基準を更新し続けている。日本においても国立国会図書館などがこれら国際標準を踏まえた体制構築を進めているが、一般企業レベルでの浸透はまだこれからと言えるだろう。

デジタル遺品とAIによる死者の復活――倫理なき技術進歩への警鐘

デジタル保存の課題は、組織や社会の記録にとどまらず、私たち個人の実存に関わる領域にも深く侵食している。「デジタル遺品」の問題は、その最も身近で切実な例である。SNSの投稿、クラウド上の写真、サブスクリプションサービスの契約、暗号資産など、私たちが生み出したデジタルデータは、肉体が滅びた後もクラウドの海を漂い続ける。Metaの追悼アカウント機能やAppleのDigital Legacy、Googleの不活動アカウントマネージャーなど、プラットフォーマー側も死後処理に備える枠組みを整えつつあるが、それはあくまでサービスごとの個別対応に過ぎない。日本では国民生活センターが2024年に「ID・パスワード不明で故人のサブスクリプションが解約できない」といった相談事例を公表し、デジタル遺品が金銭的・精神的な負担となる実態が浮き彫りになった。現行の個人情報保護法では死者のデータは保護の対象外とされており、遺族がどこまで故人のデジタルプライバシーに介入できるのか、あるいは企業がどこまでデータを保持し続けるべきなのかという判断基準は、法的にも倫理的にも未整備のままである。

さらに、生成AI技術の飛躍的な進化は、この問題に新たな、そしていささかグロテスクな側面をもたらしている。故人の残した大量のテキストデータや音声データ、動画データをAIに学習させることで、その人の思考パターンや口調、声色を再現する「AIレプリカ」あるいは「デジタルクローン」の生成が技術的に可能となったのだ。死者をデジタル空間で蘇らせるこの技術は、遺族の悲嘆を癒やすケアとしての側面を持つ一方で、故人の尊厳をどう守るか、あるいは本人の同意なしに「死後の人格」を生成・利用することが許されるのかという、極めて重い倫理的問いを突きつけている。もし、過去のデータが不完全な形で保存され、それがAIによって歪曲された形で再構成されたとしたら、それは「記憶の継承」と呼べるのだろうか。

こうした混沌の中で、記録を守る「人」の役割もまた、大きな転換期を迎えている。デジタルトランスフォーメーション（DX）の掛け声の下、多くの組織はデータの「利活用」にばかり目を奪われがちであるが、記録を適切に維持・管理できない組織は、将来の監査や訴訟、あるいは説明責任を果たすべき局面において、自らの正当性を主張する立脚点を失うことになる。欧米では「コーポレート・アーキビスト」という専門職が定着しており、ユニリーバやIBM、シーメンスといったグローバル企業では、自社の製品史や広告、法務記録を重要な知的資産として体系的に保存・管理している。日本国内でも社史資料館と統合したデジタルアーカイブの構築が進む例はあるが、まだ一部の先進的な企業に限られているのが現状だ。これからのデータ担当者に求められるのは、単なるシステムの管理者としてのスキルではない。企業の、あるいは個人の、そして社会の記憶を預かり、技術の変遷という荒波からそれを守り抜き、真正な状態で未来へと手渡す「記憶の守り手」としての高い倫理観と専門性なのである。

保存とは、単に過去のデータをHDDにコピーすることではない。それは、膨大な情報の奔流の中から何を残し、何を忘れるかを選択する主体的かつ文化的な行為である。EUで採択されたAI法が高リスクAIに対して厳格なログ保持義務を課したように、データ保存はもはや個別の技術課題ではなく、民主主義社会を維持するための基盤そのものになりつつある。AIとクラウドがどれほど進化しようとも、過去が自動的に、かつ正確に保存される未来は約束されていない。主体的な意志と制度設計がなければ、私たちの記憶はクラウドの向こう側で静かに消滅するか、あるいはAIによって都合よく書き換えられてしまうだろう。未来を設計することと同じだけの情熱とリソースを注ぎ、過去を維持するための強固な社会基盤を築くこと。それこそが、デジタル時代を生きる私たちが直面している最大の課題なのである。