生成AIは、いよいよ「質問に答えるAI」から「仕事を進めるAI」へ移行し始めている。ChatGPT、Gemini、Claudeのようなチャット型AIは、これまで文章作成、要約、翻訳、調査、アイデア出しなどに使われてきた。しかし現在は、その先にある、自律的な判断・業務遂行が可能な「AIエージェント」が登場し、急速に注目を集めている。

1. 例えると、Chat AIはカーナビ、AIエージェントは自動運転ドライバー

この違いは、自動車で目的地へ向かう場面に例えるとわかりやすい。従来のチャット型AIは、運転手をサポートしてくれるカーナビに近い。目的地を入力すると、道順を教えてくれる。渋滞情報も教えてくれる。別ルートも提案してくれる。しかし、実際にハンドルを握り、アクセルを踏み、交差点で判断するのは人間である。

一方、AIエージェントは、自動運転のドライバーに近い。目的地を伝えると、そこに到達するための手順を考え、必要な情報を確認し、状況に応じて判断しながら、作業を進めていく。もちろん現在のAIエージェントには、完全自動運転と同じように人間の監督や確認が必要である。しかし方向性としては、単に「答えを教えてくれるAI」から、「目的達成に向けて動くAI」へ進化している。

2. プロンプトからコンテキストへ

ここで重要になるのが、「プロンプトからコンテキストへ」という視点である。
これまで生成AI活用では、「よいプロンプトを書く力」が重視されてきた。もちろん、明確な指示を書く力は今でも重要である。しかしAIエージェントの時代には、それだけでは不十分になる。

カーナビであれば、「目的地」を入れればかなり役に立つ。しかし自動運転のドライバーに仕事を任せるなら、目的地だけでは足りない。どのルートを優先するのか。高速道路を使ってよいのか。安全性を優先するのか、到着時間を優先するのか。途中で誰を迎えに行くのか。荷物はあるのか。時間制約はあるのか。どの道を避けるべきなのか。こうした周辺情報がなければ、ドライバーは正しく判断できない。
AIエージェントも同じである。単に「資料を作って」「コードを書いて」「画像を作って」と指示するだけでは、実務で使える成果にはなりにくい。目的、制約条件、参照資料、業務ルール、顧客の状況、評価基準、既存システム、過去の経緯といったコンテキストを与えてはじめて、AIは適切に動ける。

つまり、AI活用の成否は、プロンプト単体ではなく、コンテキスト設計の優劣によって決まり始めている。

3. 各社のAIエージェントは何が違うのか

AIエージェントの実用化は、もともとコーディング支援の領域で先行して進んできた。コード生成、修正、テスト、デバッグのように、目的や成果物が明確で、ツール連携もしやすかったためである。
現在はその流れが、開発者向けにとどまらず、一般ユーザーや業務ユーザーの日常業務へ広がっている。AIエージェントは、コードを書く支援ツールから、調査、資料作成、業務アプリ操作、ワークフロー実行を支援する存在へと拡張されつつある。
ここで混乱しやすいのは、LLMの名称、チャットサービスの名称、エージェント機能の名称が混在している点である。そのため、個々の製品名だけを追うよりも、「モデル」「チャットサービス」「エージェント」を分けて整理すると理解しやすい。

さらに重要なのは、AIエージェントの入口が、もはやチャット画面だけに閉じていない点である。各社はAIエージェントを、デスクトップアプリ、ブラウザ、Officeアプリ、開発環境、CLI、モバイルアプリへと広げている。つまりAIエージェントは、特定のWebサービスではなく、ユーザーが日常的に作業する環境そのものに入り込み始めている。
この変化によって、AIエージェントは単なる質問応答ツールではなく、資料作成、調査、開発、業務アプリ操作、ワークフロー実行を支援する存在になりつつある。だからこそ、どのツールを使うか以上に、AIをどの業務環境に置き、何を任せ、どこまで人間が確認するのかを設計する力が重要になる。

4. GoogleはGeminiだけではない。Gemmaでエッジ・スマホにも広げている

AIエージェントを支える基盤として、GoogleのLLM戦略にも注目しておきたい。Googleは、高性能モデルであるGeminiを展開する一方で、オープンウェイト系のモデルとしてGemmaも提供している。
Gemma 4では、スマートフォン、PC、エッジデバイスなど、ユーザーが必要とする場所でAIを動かすための展開が意識されている。これは、AIエージェントがクラウド上だけで動くものではなく、ローカル環境（業務アプリ、開発環境）など、あらゆる場所に入り込んでいくことを意味している。
なお、このコンテキスト設計の考え方は、文章作成やコード生成だけでなく、画像生成や資料作成にも共通している。たとえば画像を生成する場合でも、単に「かっこいい画像を作って」と指示するだけでは実務で使える成果にはなりにくい。誰に見せるのか、どの媒体で使うのか、ブランドトーンは何か、どのような制約があるのかといった文脈を与えることで、AIの出力品質は大きく変わる。

5. マルチモーダル化により、コンテキスト設計の対象は広がっている

近年のLLMは、文章だけでなく、PDF、画像、音声、動画、スライド、Webページなど、複数の形式の情報を扱えるマルチモーダル化が進んでいる。これにより、AIに与えるコンテキストも、単なるテキストの説明文だけではなく、資料、議事録、動画、音声、画像、スライドといった多様な情報を含むものへ広がっている。

この変化を理解するうえで、NotebookLMのようなツールはわかりやすい例である。PDF、Webサイト、動画、音声、Google Docs、Google Slidesなどをソースとして集約し、それらに基づいて要約、質問応答、論点整理を行える。

重要なのは、NotebookLMという特定のツールそのものではなく、AIに参照させる資料や情報をあらかじめ整理し、信頼できる文脈として用意しておくという考え方である。たとえば、講義資料、社内文書、顧客ヒアリング、議事録、調査レポート、説明動画などを整理しておけば、AIはその資料群を前提にして回答できる。
毎回長いプロンプトを書くのではなく、先に信頼できる資料を整え、AIが参照すべき文脈を用意する。これこそが、コンテキスト設計の実践である。

6. Dify、OpenClaw、Hermes Agentはワークフロー化の方向を示している

Difyのような業務AIアプリ構築基盤から、OpenClawやHermes Agentのような常駐型エージェントまで、AIエージェントは単体のチャットツールから、業務ワークフローの中で動く存在へ移行しつつある。
Difyは、RAG、ワークフロー、エージェント、MCP/API連携を組み合わせ、社内問い合わせ、文書検索、レポート作成などをAIアプリとして構築できる基盤である。業務をよく知る現場担当者が、ノーコード／ローコードでAIアプリを形にしやすい点も特徴である。

また、OpenClawやHermes Agentは、チャット、CLI、Web、ファイル操作、ブラウザ操作、各種ツール連携などを組み合わせ、利用者の指示を起点に複数の作業を連続して進める常駐型エージェントに近い。OpenClawは複数のチャネルやツールを横断して作業を実行する方向、Hermes Agentは記憶やスキルを蓄積しながら手順を再利用・改善していく方向に特徴がある。

これらに共通しているのは、AIを単なるチャットの中に閉じ込めるのではなく、業務プロセスの中で動く存在に変えていく点である。ただし、企業で本格的に活用するには、どのデータを参照させ、どの業務プロセスに組み込み、どこまで自動化し、どこから人間が確認するのかを設計する必要がある。SSO、権限管理、監査ログ、承認フロー、セキュリティまで含めたガバナンス設計が欠かせない。

こうした設計ができれば、AIエージェントの活用は個人の工夫にとどまらず、再現性のある業務プロセスへと発展する。さらに、よく使う手順や判断基準を”スキル”として共有できれば、ベテランの判断の勘所やノウハウも、AIが参照できる形で整理することで、組織内で共有・継承しやすくなる。

今後は、こうしたワークフロー型エージェントを、クラウド上だけでなく、社内のイントラネット内やローカルAI基盤上で動かす構成も現実的になっていく。例えば、NVIDIA DGX Spark™などのローカルAI基盤を活用すれば、機密データを外部に出さずに、社内文書検索、業務自動化、開発支援、レポート生成を実行できる。外部APIへの依存を抑え、機密性やコスト管理の観点でも選択肢を広げられる。

つまり、これらのツールは、AIエージェントが単なるチャットの延長ではなく、業務プロセスそのものを再設計する基盤になりつつあることを示している。

7. これから価値が上がるのは、AIを「現場で使える形にする人材」

AIエージェントの進化は、雇用や職種にも影響を与える。単純に「AIに仕事を奪われる」という話ではない。むしろ、AIを使って一人で大きな成果を出せる人と、AIに置き換えられやすい人との差が広がる。
ここで最近注目されているのが、FDE（Forward Deployed Engineer）方式である。これはパランティア方式（米Palantir社が広めた手法）とも呼ばれ、AIやソフトウェアを開発部門の中だけで作るのではなく、顧客企業の現場に入り込み、業務課題を理解し、データ、AI、システムを組み合わせて、実際に使える形にする職種である。

FDE的な人材に求められるのは、単なるプログラミング力だけではない。顧客業務の理解、データの意味の理解、現場制約の把握、セキュリティ、運用設計、導入後の改善、そして関係者とのコミュニケーションが必要になる。さらに、SaaS、API、既存システム、ツールとの連携を設計するMCP/AI連携の視点も重要になる。
つまり、これから価値を持つのは、AIを「作る人」だけではない。AIを「現場で使える形に翻訳できる人」である。

8. プロンプトを書く時代から、コンテキストを設計する時代へ

AIエージェントの時代に重要なのは、単にAIに詳しいことではない。単にプロンプトがうまいことだけでもない。
重要なのは、AIに何をさせるのかを定義し、必要なコンテキストを整え、業務、学習、創作の中で成果が出る形に設計する力である。

今後も、チャット、開発支援、資料活用、業務ワークフロー、ローカルAI基盤など、さまざまな用途に向けたAIエージェント関連ツールが次々に登場してくるだろう。本稿で取り上げたツールは、そのごく一部に過ぎない。
しかし、どのツールにも共通しているのは、AIにどの文脈を与え、どの作業環境に置き、どこまで任せ、どこから人間が確認するかが成果を左右するという点である。
これからのAI活用は、プロンプトを書く時代から、コンテキストを設計する時代へ移っていく。そして、そのコンテキストを設計できる人材こそが、AIエージェント時代に最も価値を持つ人材になる。
そのためNTTPCでも、全社でAIエージェント活用に向けたPoCを進めている。これは単なる技術検証ではなく、AIを業務プロセスにどう組み込み、現場で成果につなげるかを探る取り組みと位置付けている。

※「Claude」「Anthropic」「Claude Code」は、Anthropic社の商標または登録商標です。
※「GitHub Copilot」はGitHub, Inc.の商標または登録商標です。
※「Google」「Gemini」「Gemma」「NotebookLM」「Google Docs」「Google Slides」「Antigravity」はGoogle LLCの商標または登録商標です。
※「OpenAI」「ChatGPT」はOpenAIの商標または登録商標です。
※「NVIDIA」「NVIDIA DGX Spark」はNVIDIA Corporation の商標または登録商標です。
※「Microsoft」「Microsoft Copilot」「Copilot Studio」はMicrosoft Corporationの商標または登録商標です。
※「Dify」はDify.AI（LangGenius, Inc.）の商標または登録商標です。